W3C home > Mailing lists > Public > www-tag@w3.org > October 2002

Re: Sticking another fork in the URI issue

From: Simon St.Laurent <simonstl@simonstl.com>
Date: Sat, 12 Oct 2002 01:59:15 -0400
To: www-tag@w3.org
Message-ID: <r01050300-1015-BD2292E0DDA711D6BF780003937A08C2@[192.168.124.21]>

Paul Prescod writes:
>Simon, I'm not clear that you and Roy have a substantive disagreement.

I'm afraid that we're standing at a boundary that has substantive
implications and which has caused genuine and repeated damage with the
potential to cause much more, even in code.  The interpretation of http
URIs seems in fact to be at the foundations of both "Web Architecture"
per W3C specification and "web architecture" per reality, and the
growing gap between those two areas certainly qualifies as cause for
concern.

>  * You both agree that HTTP URIs (e.g. namespace URIs) that are 404s 
>are bad. In other words, URIs SHOULD be dereferencable.

404s are tolerable, but 404s need to be recognized as an error condition
and not something to be completely ignored in the use of the http URI
scheme for the creation of arbitrary identifiers.  

In the case of other schemes, I'm happy to see that we're getting some
tools for asking questions about URIs from things like DDDDS, but I'm
not willing to make a blanket case that all URIs should be
dereferenceable - I'm only saying that http URIs should identify a
listener as specified by RFC 2616.

> * You both agree that XML parsers should not dereference namespace 
>URIs at runtime.

No, I don't agree with that.  XML processors may very usefully
dereference namespace URIs and even do so at times. 

>In other words, URIs SHOULD be usable as identifiers
>where that makes sense. (I'm pretty sure you aren't against cache
>keys!)

I'd argue that http URIs SHOULD be usable as identifiers but MUST
identify resources which are in fact HTTP listeners.

>I think that you do not agree that HTTP URIs can represent "anything in 
>the world." But as Tim has pointed out, agreement on that is probably 
>irrelevant. It is doubly irrelevant for you, since you do not like RDF 
>and probably do not care if RDF engines get confused about the 
>distinction between cars and documents about cars.

Unfortunately, RDF's use of URIs matters quite a bit to me, as I do
interact with RDF on a regular basis and expect the level of interaction
to grow whatever I may think of RDF's approach to URIs.  If RDF is to be
considered a part of the Web - I don't, but recognize that the W3C
certainly does - then its usage matters for the health of the rest of
the Web.

>Therefore, I think that the thing you disagree about is entirely in the 
>realm of theory and terminology. The systems you and Roy would build 
>based upon your two theories are probably identical. They would make 
>heavy use of HTTP listeners. Those listeners would describe real-world 
>objects in HTML and XML. You would say that the identifier identifies 
>the description. He would say that it identifies the real-world object.

Unfortunately, Roy's usage poisons the common idiom.  It is generally
easier for broader views to encompass narrower views, and to pretend
that there is no substantive difference, than for narrower views to
accept the larger view.  

I'm perfectly happy explaining to my mother that strings which begin
with "http" or even "www" can be typed safely into a Web browser, and
caching isn't particularly mysterious.  I'm even happier talking with
web developers who use URLs and understand how caching works without
ever paying attention to any further notion of URLs as identifiers per
se.  I'm deeply unhappy explaining that the http URIs commonly used in
XML namespaces should be treated just as strings, and that there needn't
be any listener behind it, because then I get to spend three hours of an
eight-hour tutorial attempting to defend this misbegotten logic to a
class full of people who find it clashes violently with their existing
understanding of http URIs.

>As an analogy, I might say that the bits in a purchase order numbers
>represent real-world purchase orders and someone else would say: "the
>computer has no knowledge of real-world purchase orders. All you are
>doing is identifying the database record." Okay, you're both right.
>What practical difference does it make?

None whatsoever, provided that there is an insistence somewhere in the
system that database records represent purchase orders and that purchase
orders are represented by purchase orders.  Remove that insistence,
saying that PO numbers are arbitrary identifiers, and you should remove
that system from your purchasing environment immediately.  Even if false
POs don't show up in the system you've created, they will appear
eventually unless you provide manual insistence.  (They did in fact
appear immediately for XML namespaces, using the http URI scheme in
particular.)

>Let's save our wrath for those who would make identifiers that lack
>listeners and thus cannot answer even the most basic questions: "Who
>are you and what do you know about yourself." That's an architectural
>disagreement that has implications in actual code.

Unfortunately, that's an architectural possibility that is created by
this very disagreement.  As much as I find discussing URIs to be a
complete and utter waste of time, reining in the aspirations of their
creators seems to be necessary to keep more pedestrian understandings
usefully intact. 


-------------
Simon St.Laurent - SSL is my TLA
http://simonstl.com may be my URI
http://monasticxml.org may be my ascetic URI
urn:oid:1.3.6.1.4.1.6320 is another possibility altogether
Received on Saturday, 12 October 2002 01:59:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:12 GMT