Fixed base

I've been quite surprised to find that this debate has actually
changed my views.  I now believe the right solution is to absolutize
namespace names relative to a fixed base URI of something like
"contextdependent:/" and then perform a character-for-character
comparison (I'll call this solution "fixed base" for short).  Several
people have already voiced their support for similar proposals:

   http://lists.w3.org/Archives/Public/xml-uri/2000Jun/0347.html
   http://lists.w3.org/Archives/Public/xml-uri/2000Jun/0601.html
   http://lists.w3.org/Archives/Public/xml-uri/2000Jun/0647.html

The effect of "fixed base" is very similar to the "literal" solution;
except for URIs containing "." and ".." it will be the same.  However,
it avoids the key problem of the "literal" approach: with "fixed base"
there's never a case where two URIs are namespace equal but refer to
different resources; thus an application such as RDF that needs to
dereference namespace URIs can be consistently layered on top of
"fixed base".  It also avoids the key problem with the "deprecate"
solution, which is to specify what happens when documents use relative
namespace URIs despite their being deprecated.

The "fixed base" approach might at first seem rather artificial.  But
I think there's a way of looking at it that makes it to me at least
very natural.

Think about an element with no namespace name (ie an element whose
QName has no prefix and which has no applicable default namespace).
To do anything useful with such an element, it needs to be part of a
package that includes semantics provided by for example human readable
documentation or executable code or stylesheets. The element's name is
a label local to the package that serves to associate the element with
the semantics.  The element's name is, in a broad sense, context
dependent.  Now what happens when I compare two element names which
have the same local name and no namespace name?  Suppose I have
document with "bat" elements and a stylesheet with rules for "bat"
elements.  Will the rules match?  Of course they will.  Does it matter
than the document and the stylesheet have different base URIs?  Of
course not.  Is it relevant that the document author might have been
thinking about fruit bats, whilst the stylesheet author might have
been thinking about cricket bats?  Not really.  When you use
context-dependent names, there's an unenforced assumption that you
don't mix names from different contexts.

How is all this relevant to relative namespace names?  I would suggest
that an element with a relative namespace name should be thought of in
a very similar way to an element with no namespace name. All the
observations I've made in the previous paragraph about elements with
no namespace names can be applied to elements with relative namespace
names.  This implies that relative namespace names that are literally
the same should be considered the same namespace name regardless of
the base URI of the document in which they occur.  It also implies
that it doesn't make any sense to resolve a relative namespace name
using the document's normal base URI and then dereference that to get
information about the namespace.  Absolutizing namespace names
relative to a fixed based such as "contextdependent:/" satisfies both
these requirements. Choosing "contextdependent:/" as the fixed base
URI ensures that ".." can be treated in a reasonable away (we will
need to specify how an error at step 6)g) of section 5.2 of RFC 2396
is handled by namespace processors).

It also opens the way to a further simplification. An element with no
namespace name can be treated as having a namespace name of
"contextdependent:/".  This makes the behaviour of xmlns="" not be an
ugly special exception, but just a consequence on the normal rules on
resolving relative URIs.  This gives a very clean data model: every
element, without exception, has an expanded name consisting of an
absolute URI (with an optional fragment identifier) and a local name.

James

Received on Tuesday, 20 June 2000 01:54:02 UTC