[
Lists Home |
Date Index |
Thread Index
]
I realise I'm coming in at the end of a long, long thread, but for what it's
worth I reckon the URI is the best thing since sliced bread.
Saying that it is an established practice to treat http://blah as a URL is
IMHO a complete red herring. This meaning only really has validity when an
agent is around to do the dereferencing - if a see
http://www.big-red-buses.com written in an advertisement on the back of a
bus, can it really be said to be a URL? In reality the common usage of this
kind of syntax is actually as an identifier, which is commonly interpreted
by appropriate agents (human or machine) as a URL. Not the same thing at
all.
There is an algorithm for resolving URLs, like there is an algorithm for
delivering emails or even snail mail letters. But someone's address can
exist without having a postal service - or would it be better to use
different syntax there? Maybe my address book entries should be prefixed :
[do not deliver to] John Smith, No.7, The Mews...
to prevent the book disappearing in the hands of a dutiful postal agent.
The talk of an 'expectation' is a major misrepresentation. Ok, under normal
circumstances the agent will see http:// in HTML and behave appropriately.
But the machine agent runs the algorithm, not the human - a reasonable
argument for the identifiers in HTML href attributes always being
dereferenceable, but that's all. The user may enter
http://www.big-red-buses.com into the addresss bar of their browser only to
find that it doesn't get anything - but it might actually be a traditional
URL, and the site's down. If anything the use of URLs by humans like this
just demonstrates how primitive most of today's web technology is. If this
really is an expectation here, it's a pretty low one, not that far from
expecting the user to use IP addresses instead.
In any case, under what circumstances are the user's expectations liable to
be cheated? I for one wouldn't be too disappointed if I copied and pasted a
namespace declaration into the address bar of a browser and didn't get
anything that made any sense.
The fact that the URI may also be that of a deferenceable URL is a bonus, an
agent can potentially get more information through this route, and
recommendations are probably a good idea here on what should be at the other
end (the RDF usage where a formal RDF Schema and/or a human-language
description is usually found is probably a good start).
The bottom line is that allowing http://blah etc. syntax to be treated as a
non-deferenceable URI doesn't break anything, insisting that it should
always be dereferenceable breaks the web - every site must be available
24/7.
Just another €0.02 for the retirement fund.
Cheers,
Danny.
---
Danny Ayers
<stuff> http://www.isacat.net </stuff>
Idea maps for the Semantic Web
http://www.isacat.net/ideagraph
>-----Original Message-----
>From: Thomas B. Passin [mailto:tpassin@comcast.net]
>Sent: 24 July 2002 01:40
>To: xml-dev@lists.xml.org
>Subject: Re: [xml-dev] URIs harmful
>
>
>[Mike Brown]
>
>> Thomas B. Passin wrote:
>> > It would probably have been better if the W3C had said that,
>if you want
>to
>> > have a pure identifier that is not intended to give network access to a
>> > resource, then use the w3c-ndi: scheme ("W3C Non-dereferenceable
>Identifer")
>> > or some such, and to have issued an RFC that specified exactly those
>> > semantics.
>>
>> "Non-dereferenceable identifier" would be an oxymoron, according to some,
>> and depending on the definition of dereference, I would agree! :)
>>
>
>:-) Could be, Mike, but I bet everyone reading it knows just what I
>intended! Call it what you will, a special scheme for these things could
>make sense.
>
>Cheers,
>
>Tom P
>
>
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://lists.xml.org/ob/adm.pl>
>
|
