xml-dev - Re: URI concerns continue

[Lee Anne Phillips <leeanne@leeanne.com>]

I agree the URI's are built on quicksand for the most part, once you leave 
the shaky ground provided by URLs, which have their own problems. The whole 
concept of "authorities" presumes an exactitude in the world that simply 
doesn't exist in any real sense. Even URL's can be (and have been) 
subverted. The authority of URL's depends entirely on the goodwill and 
skill of all (or almost all) participants in the DNS scheme of things.

It's a lot like driving. Laws don't make driving safe any more than pinted 
lines on the road make it so; the totality of the safe and skillful 
behaviors of almost all of the other drivers on the road makes it a 
relatively safe activity for most of us.

While it may be true that having a naming authority "guarantees" 
uniqueness, many of the examples chosen leave one with no reasonable way to 
determine that fact or to find out what a resource is in reality. ISBN's, 
for example, used to identify certain books in international trade, cannot 
be turned into book names or even verified without subscribing to the 
Bowker service which originated them. In addition, the naming authority for 
these numbers is distributed, with relegation going to countries and firms 
whose implementation of the rules may be different from those in the USA 
and whose filing system consists of a cluttered cardboard box in the corner 
of an office. There is, in fact, no possible way to do a "simple database 
lookup" of a random ISBN number. And of course, many books have no ISBN 
number at all, so it's quite possible to have a need to describe a 
particular book without an ISBN number available to guarantee uniqueness. 
There are no naming schemes available which cover every book, and many 
books are covered by several. Any particular scheme one chooses will leave 
others out in the cold for the simple reason that there is not now and 
never will be a universal encyclopedia of human knowledge..

Pablo Picasso is an easy example, the ultimate naming authority for his 
paintings, so URN:Picasso:Guernica would be at least theoretically valid, 
but doing a lookup in the Picasso database is quite plainly difficult. This 
is why experts on art make big bucks deciding whether a painting belongs in 
the Picasso database or not. Disambiguation is precisely what they do but 
your average site is probably not going to want to pay their authentication 
fees in order to disambiguate every odd reference to this particular 
painting. Most of us take it on faith that the painting the guide points to 
as Guernica by Picasso is in fact that same, even if it's hanging in Fred's 
High-Class Art Museum and Gallery of Little Rock, Arkansas. From the 
proliferation of silly ideas on the Web, it's quite clear that faith and 
gullibility will play an important part in the sum total of information one 
sees on the Internet.

Most of the bodies proposed as naming authorities for URI's are 
subscription services and either refuse to allow random requests gratis or 
have no machine-readable form at all. Has anyone addressed the issue of 
what earthly good a naming authority is if it exists only in paper form 
and/or only by subscription? While this might be seen as an issue of 
choosing wisely, in many cases the "unwise" choice is the only realistic 
choice. Are users going to respond well to a browser that says, in effect, 
"Please deposit US$25 to continue?" The reason URL's are so popular as 
identifiers, despite their uncertainty and lack of persistence, is that DNS 
guarantees that they are free for anyone to use. The minute you step away 
from the Commons that URL's represent, however, you run into fences, No 
Trespassing signs, and toll roads. It's rather difficult to legally get 
anywhere without unlimited funds.

So many of the naive URI schemes one sees as exemplary of non-URL instances 
of URI's really only cohere or seem plausible when one doesn't know very 
much about the problem space. In the absence of certainty, or at least 
certainty we can all afford, most of us will be stumbling around with 
half-baked ideas and guesses on the Internet, just as we do in real life.

So URI's are being used for all sorts of purposes, including setting 
internal program switches, which have nothing to do with the specification 
which rather loosely defines them. And if a manufacturer, say Microsoft, 
takes over the meaning of a URI belonging to another body, say W3C, in such 
a way that the original owner has no further control of it, in what sense 
is the original authority still authorized? Embrace and extend would seem a 
misnomer, in this instance; more correct might be embrace and digest.

At 07:08 AM 7/11/00, Simon St.Laurent wrote:
>At 09:41 AM 7/11/00 -0400, Michael Mealling wrote:
> >Just because you have an incorrect perception of the use of something
> >doesn't mean that everyone else is wrong. URIs identify Resources
> >in the abstract. That is their definition. You don't get to
> >redefine that simply because your experience is limited to the
> >http scheme and some counter-productive, SGML-ish, bifurcation of
> >public vs system identifiers.
>
>Thanks, Michael.  It's always nice to be told that I'm wrong.  Of course,
>since I'm calling URIs a quicksand foundation, I suppose I should expect
>some irritated responses.
>
>My experience is not limited to the http scheme, I'm afraid, though I think
>I may have a better understanding of the public expectations surrounding
>that scheme than some wise fellows.
>
> >Any identifier can use be used to retrieve something. Its called a
> >database lookup. You can do lots of things with an identifier: use it
> >as a key to a database, use it to disambiguate something are two of the
> >most important.  Those two functions are not mutally exclusive or
> >incompatible,
>
>They are, however, severely underspecified, and the current uses of URIs in
>XML specifications set no such expectations for those features.  As we've
>found, even simple comparison is lacking in RFC 2396.
>
> >> Does your placement of schemas at namespace URIs make you a hijacker?  I'd
> >> say it very well might.
> >
> >If he has the assignment authority over that identifier used in that
>namespace
> >then no he isn't....
>
>He's making additional claims about the usage of those URIs which are not
>in the specification.  If I was in a bad mood, I'd call it 'embrace and
>extend'.
>
> >If you choose to name your namespace badly or in such a way as to make
> >it difficult for someone to learn about your namespace then that's your
> >problem (or your intent). Its not the problem of xml namespaces or URIs....
>
>The specifications leave open an astounding number of ways to use these
>things badly.  It's the problem of the namespace specification's failure to
>limit and define the tools provided by RFC 2396, which itself does very
>little defining.
>
> >> >In some cases, the abstraction is a static entity body.
> >> >http://www.ietf.org/rfc/rfc2396.txt is such an example.
> >> >But this is not the general rule -- it is a special case.
> >>
> >> It's not even the general rule that there is an entity body.  In fact, I'm
> >> not sure that there is a general rule beyond the existence of the syntax.
> >
> >The general rule is defined based on the scheme. But you know that
> >all schemes identify some Resource. Its up to you to pick a URI that
> >makes sense for what you're trying to do. If you pick badly then
> >its your fault. Don't blame the infrastructure for giving you the
> >freedom to cause problems for yourself...
>
>I'd suggest that the builders of infrastructure would be wise to stop
>building on quicksand and then blaming the unlucky victims.
>
> >> This doesn't seem like an appropriate foundation for the kinds of
> >> non-retrieval tasks URIs are being asked to do in various (namespace,
> >> schema, XLink) XML contexts.
> >
> >Why not? You just want a name right? urn:oid:1.3.6.1.4.1.5 sounds
> >like it covers the bases to me...
>
>I agree.  Perhaps Namespaces in XML should have used URNs only.
>
>Simon St.Laurent
>XML Elements of Style / XML: A Primer, 2nd Ed.
>http://www.simonstl.com - XML essays and books