Re: URIs quack like a duck

On Mon, May 29, 2000 at 04:32:29PM -0400, Paul W. Abrahams wrote:
> Michael Mealling wrote:
> > 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.

Not replaced. Just renamed. The group that was attempting to standardize
URLs at the time was having these same discussions as we're having
now and the realization came upon os that that a) they didn't just
locate, they were general identifiers and b) that the U should be
Uniform instead of Universal because you had URIs that didn't
have meaning universally (i.e. news: makes no sense in many cases without your
nntp server being defined).

> > 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.  

I never said it had to. Some URIs locate, others name. It really
depends on what your after...


> 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.

According to the data scheme, it locates the package it contains. I.e.
it is self locating.... (yea, I know...fun with semantics). The point
of my missive is that, if you want location then use a scheme that
enables it. If you need naming and specifically _don't_ want location
then pick one that enables that....

> > 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.

I never said that they all must locate something. URIs identify. That's
all. Some schemes act more like names. Others act more like locators.
_YOU_ decied in your own application which one to use....

> > 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?  

You can decide this for everyone....

> 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''):

Just because something is a URI doesn't mean you have to resolve it
for it to be used as a disambiguator....

> 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.

Sure. But as long as you don't prohibit it then someone else can come along
and build on top of that a new infrastructure that uses them as more
than identifiers. That doesn't mean that they still aren't use as
identifiers....

> 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.

hehe.... Just becase one group couln't make a decision we're going to 
all run away screaming?

> 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.

Sure. But just because _ALL_ naamespaces aren't guaranteed to be
resolvable doesn't mean that a new abstraction layer can't require
it of some limited subset/function....

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

But are you willing to deny that function from some other system
that may mandate it for some limited set of namespaces?
Just because you think something doesn't make sense for your
set of applications doesn't mean someone else can't find a use for it.
I.e. for a lot of people eating sushi is just as appealing as
eating a tractor. But would you make it impossible for people to eas sushi?

> > 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.

But at what layer? At the transport layer the IP address has absolutely
zero meaning other than some string usec by the application to
turn into a MAC address....

> > 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.

Ahhh! You want to make it ILLEGAL to dereference a namespace to 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.

Way back in '92 we proposed a few changes to URI schemes that would have
mitigatd some of today's headaches. (The '//' to mention one in particular).
The reason we didn't was because of hte installed base of about 150 web 
servers. The 'backward compatibility argument' doesn't hold much
water with me... How many applications actually depend on this change?
If it isn't in the hundreds of thousands then I don't really care....

> 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

Not compliant with the scheme but I get the idea. Its a poor man's FPI.

> 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.

That may be what you want to use. Are you going to deny me the ability
to use what I want to use? That's what this is all about. I could really
care less what you want to do. I'm much more interested in what you
want to make it illegal for me to do....

> 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.

Does urn:isbn:1-56592-487-9 name or locate?

Before you answer that be aware that there is a standardized process for
taking that URN, looking it up in an authoritative database and getting
the exact location of an electronic copy of the resource it names.
Now, does it name or does it locate?

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  michaelm@netsol.com

Received on Monday, 29 May 2000 17:49:29 UTC