Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: URIs harmful (was RE: Article: Keeping pace with
 > Thomas B. Passin wrote: > > A URI is intended to allow you to "identify" something, and that something > > does not have to be a retrievable resource. It can be abstract. A URL is a > > special case that gives you an identifier that does work for retrieving an > > actual resource. > > Just to clarify, > > 'Retrieval' is the wrong word here. 'Access' is better -- The resource may be > too intangible for its representation to be a retrievable entity, and the > primary access method as implied by the scheme may not even facilitate > retrieval (or a meaningful response of any kind) at all. For example, > > URI resource > =========================== ================================= > mailto:mike@s... my email mailbox > news:comp.text.xml a Usenet newsgroup > telnet://telecafe.com:9000/ a telnet session on a chat server > > 1. Accessing the mailto: URI does not give you a copy of my mailbox. In fact, > it gives you nothing. The access method implies SMTP which does involve > responses, but at most you just get an "OK - Accepted for delivery" which is > no guarantee of anything, as any MTA administrator will tell you. > > 2. The URI is just a declaration of the mailbox's identity. One does not need > to feel compelled to send me a letter just because it's a URL. There's no test > for identity other than the characters in the URI. You know "where" it is (or > rather, how to access it), and that info is all you need to identify the box. > Throw that URI into a hypertext anchor, and *then* it becomes prudent to > attempt to facilitate actual access. > > I get the impression, from Len's poetry and Simon's calling my ideas a pile of > nothing, that some are of the opinion that 'retrieval' *is* implicit in a URL > to the extent that you can't even look at a URL without trying to access the > resource at the other end, and they think this access is somehow supposed to > be the true test of a resource's identity. I do not agree at all, though I do > think that exactly how a URL is a subclass of a URI could stand to be > clarified. I think Mike has put a finger here on the problems I have with Len's and Simon's position. If you assume a URL is about retrieval, then as Mike says, a lot of URL spec itself don't make sense. This is in addition to the assertion that I made earlier that if you assume a URL is about location, then a lot of URL spec itself don't make sense. So if URLs are not really about location, and are not really about retrieval (or at least are not really meant to be about either), doesn't this reduce some of the supposed divide between URLs and URIs? Maybe the fact that I consider URLs an identifier is why I've never understood why they are able to launch 3000-message threads. I just don't see that magnitude of problem anywhere. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/li brary/x-think11.html 
|
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
|
|||||||||
