Re: Fixed base

Dan Connolly wrote:
> 
> James Clark wrote:
> >
> > [...]  Absolutizing namespace names
> > relative to a fixed based such as "contextdependent:/" satisfies both
> > these requirements.
> [...]
> >  This makes the behaviour of xmlns="" not be an
> > ugly special exception, but just a consequence on the normal rules on
> > resolving relative URIs.
> 
> Not an exception?

I was referring to the special case for the xmlns attribute where an
empty string "undeclares" the default namespace.

> Ugly is a matter of taste... I think making a special case
> for namespace declarations is ugly. I don't see any motivation
> for it (other than the fact that there are
> implementations that don't grok relative URI references
> at all, which I don't find compelling.)

It's undeniable that this proposal treats URI references in namespace
declarations differently from other URI references and I would accept
that this is a minus point of the proposal (in fact the main minus
point).  However, I think there is motivation for it.  The primary
function of URI references in namespace declaration is quite different
from the normal function of URIs.  The main function of a URI reference
in a namespace declaration is to be a name, and the main operation is to
compare it for identity with other namespace names.  In other contexts,
the main function of a URI is to be a locator, and the main operation is
to retrieve a resource.  The normal choice of the resource containing
the URI reference as the base URI works great for resource retrieval
because it allows a collection of resources to be location independent. 
However, it doesn't work well for URI references that are being used
purely as names; it's not helpful for the names of elements to change
when you change the location of a document. Having location-dependent
locators is good; having location-dependent names isn't.

And consider the alternatives:

- absolutize: this does treat URI references in namespace declarations
consistently with URI references elsewhere, but I would suggest it has
little chance of attracting consensus and it has serious backwards
compatibility problems with the Namespaces Rec in that silently changes
the meaning of existing documents

- deprecate: this deprecates relatives URI references only in namespace
declarations, so it is no more consistent than fixed base; it also
creates potential interoperability problems for documents that use
relative URIs despite their being deprecated and it has some backwards
compatibility problems (though less than absolutize) in that it
deprecates a syntax which was perfectly legal according to the Rec

- literal: this ignores the base URI of relative URI references in
namespace names, so it again is inconsistent; I would argue that the
inconsistency here is worse in that a particular URI reference may be
simultaneously treated inconsistently by different layers

James

Received on Wednesday, 21 June 2000 01:13:18 UTC