Re: Namespace names and URIs

Great summary, Tim.

The key point, for me, is 
> The namespace name, to serve its intended purpose, should have the 
> characteristics of uniqueness and persistence. 


Since TimBL asked me to clarify my assertion that Absolutized namespace
names seemed to conflict with the intended behavior of Namespaces,
here's a summary of the issue.


The namespace URI becomes part of the name of the Element or Attribute
-- just as if it were written into that name. The {nsuri}localname
notation which is sometimes used in discussing namespaces illustrates
that. Outside of syntax and convenience, there really isn't a lot of
difference between
	<bar:foo xmlns:bar="http://freds.xml.language"/>
and
	<freds.xml.language-foo/>
... namespaces just provide a set of convenient shorthands so you don't
have to type the elongated names every time in order to avoid
collisions. They may _also_, eventually, refer to something in the
outside world -- but that's very much a secondary behavior, as
namespaces are currently defined.

If I move a document containing the non-namespace version to a different
directory or server, or whatever, I do _not_ expect the element's name
to change. My program -- or whatever else binds the element to its
semantics -- should recognize this as a "foo" element defined in Fred's
language.

But if I relocate a document containing the namespaced version, I expect
exactly the same result. My program needs to have a simple, reliable
mechanism which permits it to determine that this is or isn't the name
Fred defined. Otherwise, the semantics of the document will be broken
when it is relocated.

I honestly can't see how to write such a test if a single namespace
URIRef resolves to different values in different contexts. Hence, I
don't believe that an absolutized value is a practical interpretation
for a Namespace Name, however useful it may be for other purposes.


That leaves us with two workable choices, as far as I can see: 

1) Update the Namespace spec to forbid Namespace Names containing those
portions of the URI Reference string which are sensitive to the base
address... essentially, require that all namespace names are absolute.
This prevents the namespace name from ever being used to perform a
relative retrieval, and breaks some existing practice (though one can
argue that said practice should never have begun). And some folks have
pointed out that Absolute may not be enough; when users think of two
URIRefs as being "the same", what they usually mean is that they're the
same after Canonicalizing (converting character escapes, dealing with
/.. even if it isn't at the start of the URIRef, etc.)

2) Leave the namespace spec as it stands, and treat the strings as
literals... leaving absolutization as a step to be performed explicitly
if and when someone really wants the absolute form. Folks should still
be encouraged to define their namespaces in terms of absolute URIRefs...
but this approach leaves room for existing practice.



Architecturally, I favor (1), with the eventual addition of a seperate
set of attributes to bind namespaces to relative URIRefs if/when that
becomes desirable (for the "semantic web", for namespace-to-schema
association, etc.)

But as a practical matter of software engineering, recognizing that
there is a body of existing practice (even if I disagree with it), I
consider (2) the best compromise available. It accomplishes all the
goals of the Namespace spec, and minimizes the impact of this
clarification-of-intent.


-- 
------------------------------------------------------
Joe Kesselman, http://www.lovesong.com/people/keshlam/
Opinions expressed are solely those of the author

Received on Wednesday, 17 May 2000 12:01:04 UTC