Re: Namespace names: a semi-serious proposal

David Carlisle wrote:

> > And what do you think of the idea that led to this query: using UUID's as the only
> > non-deprecated form of namespace name?
>
> Compare
>
> <stylesheet xmlns="http://www.w3.org/1999/XSL/Transform"/>
>
> <stylesheet xmlns="uuid:ae36ff938865"/>
>
> I think the first one (even with the unfortunate four digits) is
> rather more useful informing a human reader which vocabulary this
> element is from, and also has rather better chance of being correctly
> hand authored.

The problem with the second is that it's partway down the slippery slope.   The problem
with using URL's such as that one is that it's difficult to generalize the rules for
creating them in a safe way.  That's what all the agony here is about, it seems.  It's
like the toy invented by a psychologist to introduce small children to the modern
world: any way you put it together, it is wrong.

Fundamentally, three different functions have been overloaded onto the namespace name:
unique identification, description, and designation of metadata.  The third one was
disclaimed by the namespace spec, but TimBL and others have thought it natural and
necessary nonetheless.   There just does not seem to be a solution that fits all the
data points; the problem is overconstrained.   The answer, I believe, is to separate
the three functions into three different attributes.

I agree that manual transcription of long numbers is vulnerable to error, but that's
what cut and paste is for.

> Namespace names are not just some internal unique identifier that
> can be machine generated and machine recognised (well some may be,
> and for that uuid is fine, but you can't deprecate all readable
> uri schemes, and I'm not sure that you can deprecate the namespace
> names of existing recommendations unless you want to wind the entire
> XML clock back to 1997 and start over.

The whole idea of deprecation, it seems to me, is to say ``You are forgiven, but go and
sin no more''.  The existing recommendation names are safe, in both senses: they don't
have multiple meanings and there's no need to replace them.

Paul Abrahams

Received on Saturday, 27 May 2000 11:47:38 UTC