Re: URIs quack like a duck

Michael Mealling wrote:

> On Mon, May 29, 2000 at 11:46:23AM -0400, Paul W. Abrahams wrote:
> > Tim Berners-Lee wrote:
> > > Liam said:
> > > >All of these problems stem from using a URI as a name for something
> > > >instead of idenftifying the location for something.
> > >
> > > No no no no no.  An HTTP URI  is a name, and there is a lookup function
> > > for it.  There are not rules against reuse imposed globally, but there are
> > > as many levels of indirection as you like available.
> > >
> > > Please stop refering to it as a location....!
> >
> > The problem is that if it looks like a duck and quacks like a duck, it's
> > hard to prevent people from imposing duckish expectations on it.  URIs
> > create those expectations.
>
> Hehe.... I've been doing various sides of this discussion since '92.
> Over the past decade the various incantations of the URL/URI/URN
> working groups in the IETF have learned a bit about this stuff and
> you're both making some fundamental mistakes.

You know lots of history, Michael.  What was it that motivated the switch from URLs
to URIs?  As I read RFC2396, URLs are obsolete, having been replaced entirely by
URIs.

> As Tim and others have said repeatedly, any identifier has
> aspects of naming and location. Sometimes which ever is prevelant
> depends on some aspects of the name (non-reassignability, global-uniqueness,
> etc). But more often than not, it actually has more to do with
> how you end up using it.

It's a stretch to say that the URI uuid:28a4fe98034 (or an identifier using some
other scheme that dispenses unique integers) locates anything.  And coming back to
Clark Evans's suggestion of a "data:" scheme, does "data:Michael_Mealling" locate
anything, even you?  The whole point of "data:" is that it doesn't.

> Take domain-names for example, at the various network layers a domain-name
> is very much a 'name' whereas an IP address is very much a locator.
> Go one level down into the ethernet transport layer and an IP address
> becomes a name and your MAC address becomes a locator. Going up
> into the application layer, a domain-name becomes much more like
> an address while something like a URI becomes a name.
>
> Any URI can be _used_ as a name or a locator. Its not a function of
> the URI. Its a function of the use to which its put. Does that
> mean that some URIs have more applicability to certain functions, yes.

URI's are a tent with many camels (or whatever the metaphor is).  There are lots of
schemes, and there can be lots more.  Your example involves resources that exist on
the Web.  But once you move away from schemes that refer to such resources, the
argument that they locate something becomes at least weak and at most entirely
untenable.

> But that's indicative of any addressing/naming mechanism.
>
> The XML Namespaces spec's job is to define what _functions_ it is
> going to use a URI for. If its stricly for locating and you don't need
> any naming qualities then an HTTP URI is just fine. If you really
> want aspects of naming then you want something like a URN or MID
> or even a GUID (which doesn't have a URI scheme but that's trivial
> enough to fix). But _all_ of those are valid URI schemes.

Valid, yes.  Wisely chosen?  I'm not so sure.  Ron Bourret's Namespace FAQ seems
pretty emphatic about namespace URIs not pointing to anything (though there's just
a little wiggle room in the phrase ``not guaranteed to''):

<snip>

12) SECTION 12: XML NAMESPACE URIs

12.1) What is an XML namespace URI?

An XML namespace URI is a URI that uniquely identifies the namespace. URIs are used
because they are widely understood and well documented.
Because people may only allocate URIs under their control, it is easy to ensure
that no two XML namespaces are identified by the same URI.

12.2) What does an XML namespace URI point to?

An XML namespace URI is simply an identifier. It is not guaranteed to point to
anything and, in general, it is a bad idea to assume that it does. This
point causes a lot of confusion, so we'll repeat it here:

   XML NAMESPACE URIs ARE JUST IDENTIFIERS. THEY
   ARE NOT GUARANTEED TO POINT TO ANYTHING.

An early version of the W3C's XML Schemas used XML namespace URIs to point to an
XML Schema document containing the definitions of the element
types and attributes named in the namespace. However, this proved very
controversial and the idea has been withdrawn.

12.3) Can I resolve an XML namespace URI?

Yes.

You can also eat a tractor, but that doesn't mean it's a good idea. XML namespace
URIs are not guaranteed to point to anything, so there is generally no
reason to resolve them. Furthermore, there is nothing in the processing of XML
namespaces that requires you to resolve an XML namespace URI.

</snip>

Using namespace URIs actually to locate things seems to me to be like, to use Ron's
picturesque image, eating a tractor.  Bon appetit!

> It comes down to this: you can take an IP address and do some
> simple permutation of it to turn it into a domain-name (which
> is what DNS reverse lookups do). In this case, is an IP address
> a name or a locator? Neither, its simply an identifier. Its up
> to the purpose you use it for to determine which it is: name or address.

An IP address quacks (silently, perhaps, if it's invalid).  When you see one you
expect some network interface to be on the other end, and you expect that network
interface to throw bits at you if you poke it.

> IMNSHO, in the xml namespaces quandry you want naming. In some

> cases you may want some resolution process to allow you to go find
> some resource that represents the name, but that isn't always
> required. Disambiguation being the only function needed.

Once you start using names that look as though they locate interesting resources,
they quack like a duck, i.e., they seem to be locating those resources even if
their only purpose is disambiguation.   I surmise it's that appearance that led to
the XPath definition of expanded names that assumes absolutization.  Absolutization
is pointless for identifiers that don't locate anything.

Michael, I realize that there are existing namespace names that are embedded in
existing specs.  Moreover, the Microsoft implementation seems to use namespace
names to locate schemas.  It would be most unwise even to attempt to outlaw these.

But future usage is a different matter.  To offer an example of what might be done,
I would (not retroactively, I emphasize) use the URI

    data:XSLT_Transformations_1.0

as the URI for the XSLT namespace.  In other words, instead of using an http scheme
based on a Web location, I'd use a data scheme based on the printed title of the
defining document.

There'd be more of an argument for allowing future usage to employ URIs that
actually locate resources if the xmlns attribute were the only possible one to
serve that purpose.   But it isn't.  We could have an xmlnsmetadata:foo attribute,
for example (don't take that execrable name too seriously).  It would be far
cleaner to separate the concerns of disambiguation and location of resources,
assigning those distinct concerns to distinct attributes.

Paul Abrahams

Received on Monday, 29 May 2000 16:32:40 UTC