[
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.
- Mike
____________________________________________________________________________
mike j. brown | xml/xslt: http://skew.org/xml/
denver/boulder, colorado, usa | resume: http://skew.org/~mike/resume/
|
