Lists Home |
Date Index |
> More or less, yes. But I like to focus on "identifying resources"
> rather than "encoding queries". Think of a query as identifying
> something. For example, this query identifies all resources that
> Google knows about that includes your name.
I do not want to start a new debate but URLs express locations (Uniform
Resource Location). We could as well use URNs (Uniform Resource Name) to
fetch something by name. I agree with the fact the we could use URIs
(Uniform Resource Identifier). However, you do not *concretely* address the
fact that we may want to fetch a document using more or less complex queries
or if you want *Identifier*. Nonetheless, if I want to express something
like the Oracle SQL query how do I do that with a URI. And *No* I cannot
create a query document and store it on the remote server and then call it
with a simple HTTP GET (using a URL). To replace the actual *wrong* practice
of using HTTP POST to formulate complex document queries, we have to propose
something more solid than etherized nomads.
> I think the creation of new URIs is a wonderful side effect (no pun
> intended 8-) of having a single "retrieve" method. Looking at
> PROPFIND again, if the "properties for a resource" were identified by a
> separate URI rather than retrieved via a non-GET method, then we could
> make assertions about the properties, cache them, use XSLT on them, etc.
> All the goodies you get by having a URI.
> The "U" in URI stands for "uniform" (previously "universal"), which
> means that a URI identifies the same "thing" in all contexts. Having
> a single method meaning "show we what you are"/"resolve"/etc.. helps
> ensure that uniformity/universality is maintained.
Now we are on the same wavelength ;-)
Didier PH Martin