[
Lists Home |
Date Index |
Thread Index
]
> 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@skew.org 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
|
