[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: URIs and Names on the Web
[Didier PH Martin] > > I personally think that using URLs for everything is a kind of reasoning > that could receive the same kind of counter-argument as using HTTP to > tunnel SOAP requests. It's using something indented for a certain usage > for an other one. Many people have said that an HTTP url is specifically for retrieving a resource via HTTP. But the RFCs do not exactly say this. Here are some quotes from RFC 2396 that bear on the point: (1) "An identifier is an object that can act as a reference to something that has identity" (2) "Having identified a resource, a system may perform a variety of operations on the resource, as might be characterized by such words as `access', `update', `replace', or `find attributes'." (3) "A URI can be further classified as a locator, a name, or both." (4) "Although many URL schemes are named after protocols, this does not imply that the only way to access the URL's resource is via the named protocol. Gateways, proxies, caches, and name resolution services might be used to access some resources, independent of the protocol of their origin..." (5) "A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., "today's weather report for Los Angeles"), and a collection of other resources. Not all resources are network "retrievable"; e.g., human beings, corporations, and bound books in a library can also be considered resources." (1) says that a URI is a reference to something that "has an identity". (5) clarifies that a thing with an identity need not be retrievable over a network. (2) says that the identification function is primary, and actual operations on the identified resource are secondary so far as the function of a URI is concerned. (3) says that some URIs can be both an identifier and a locator. This seems to make an http: URL a candidate for (3)-hood (i.e., "both"). (4) tells us that it an http: resource can be accessed some other way than by using HTTP, which decouples the http: scheme from HTTP, at least to a degree. When I put these all together, I think the least that we can say is that the RFC is compatible with using the http: scheme to identify non-network-retrievable resources. This puts the question squarely into the social or psychological domain - is it a good idea, given some people's expectations? I realize that all of these points have been made earlier in these threads, one way or another. I am just looking at what support the RFC(s) have for them. Cheers, Tom P
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|