Re: Swamped (Was:Re: Call the question!)

There were three main proposals on the table. Here's as honest an analysis
as I can come up with; if folks want to contribute or refine points, feel
free -- but you should probably keep them _brief_ and focused on specifics.

Note: If one or more relative URIs are to be associated with the Namespace
Name, to bind it to external references, the Namespace Name itself does not
have to serve this role. This can easily be done with additional
attributes. See the xmlns-binding: proposal, or the schema-location
attributes in the Schema spec, as illustrations.

Also note: If you stick with absolute references throughout -- if you
pretend that Option 1 was accepted -- then all the options yeild the same
results. Their behavior diverges only for those users who insist on using
relative syntax in their namespace names. Computational costs also differ,
with Literal being least expensive and Absolutize being most expensive; the
costs for Absolutize aren't bad on a single document but might be noticable
on a heavily laden server.

--------------------------------------------------------------
OPTION 1: FORBID RELATIVE REFERENCES. Namespace Names are URI References
which must be expressed in absolutized syntax as defined by the RFC.
Essentially, that means that no leading /. or /.. are premitted; the name
_must_ start with a URI Scheme (eg "http://")

+: All names remain stable , permitting reliable namespace-aware document
processing.
+: Since names must be pre-absolutized, they can be compared via a simple
string comparison.
-: It would break those users who have been relying on the fact that
Namespaces 1.0 permitted relative syntax.  The largest member of that user
set does, in fact, admit that they were using Namespace syntax for a
purpose other than that intended -- they were using it only as a binding to
external data, _not_ for namespace-aware processing of the document per se.
-: It is unclear that this is sufficient. Absolute URI syntax does permit
character escapes and _embedded_ /. and /.., and considers URIs which
contain these to be different from URIs which expand them. Users generally
consider http://a/b/./c to be the same as http://a/b/c, since servers
generally access the same entity either way, but the URI spec says that
these are officially different.

^:The wording of the Namespace spec would have to be changed to forbid
relative syntax. If we're willing to give up the option of using #whatever
locator suffixes as part of the names, the easiest solution would be to say
that the name must be a URI rather than a URI Reference.
^: Some of the other specs may need to be rewritten to reflect this
understanding. The DOM would have to perform a syntax check when defining
namespaces, for example, though it would be able to continue to use literal
string comparison when checking them.

--------------------------------------------------------------
OPTION 2: ABSOLUTIZE RELATIVE REFERENCES. Namespace Names are URI
References "writ large". If an author writes a relative URI, applications
see it only in its absolutized form, after being combined with the base URI
in effect at that point in the document. Note that a single document may
have multiple base URIs, due to the use of external entities; the XBASE
proposal raises the same possibility.

+: It would support those users who have been using Namespaces as a way of
binding to external references, relying on the fact that Namespaces 1.0
permitted relative syntax.  Reminder: This usage was explicitly _not_ a
goal of the Namespace spec.
+: It would make namespace names "URI references like any other URI
Reference".
-: Relative names are not stable. As a relative namespace name is moved
from file to file, or as XBASE changes the base URI, the namespace name
would change This makes absolutized relative names highly unsuitable for
namespace-aware document processing, however useful they may be in other
applications; nobody has yet shown how such an application could process
them reliably.
-: It is unclear that this is sufficient. Absolute URI syntax does permit
character escapes and _embedded_ /. and /.., and considers URIs which
contain these to be different from URIs which expand them. Users generally
consider http://a/b/./c to be the same as http://a/b/c, since servers
generally access the same entity either way, but the URI spec says that
these are officially different.

^:The wording of the Namespace spec would have to be changed to indicate
exactly how the normalization occurs, and tell us whether we can pass in a
relative reference for testing or must ask all our questions in terms of
the absolutized name.
^: Some of the other specs (eg DOM) which reference Namespaces would need
to be rewritten to reflect this understanding. Others already have this
behavior.


--------------------------------------------------------------
OPTION 3: TREAT NAMESPACE NAMES AS LITERALS. Namespace Names are just Text
Strings whose value should be expressed in URI Reference form. This is the
behavior intended by the Namespace Working Group.

+: All names remain stable , permitting reliable namespace-aware document
processing.
+: Names can be compared via a simple string comparison.
+: It would support those users who have been using Namespaces as a way of
binding to external references, relying on the fact that Namespaces 1.0
permitted relative syntax; they would retrieve the string and the base URI
and perform the absolutize operation ("absolution"? No, let's not go
there...) in application code.
-: According to one subset of the community, this choice does violence to
the concept of URIs, or at least to the concept that everything in the
network-universe can be named via a URI Reference.

^:The wording of the Namespace spec would have to be cleaned up to clarify
that these are not URIs, but strings in URI syntax.
^: Some of the other specs (eg XPath?) which reference Namespaces would
need to be rewritten to reflect this understanding. Others already have
this behavior.

______________________________________
Joe Kesselman  / IBM Research

Received on Monday, 22 May 2000 16:44:22 UTC