A proposed solution

In the wake of the discussions on this mailing list, we believe we 
have discovered a simple, consistent interpretation of the namespaces
specification that preserves the integrity of URIs, that clearly
identifies namespace identifiers as actual URIs and yet -- within
reasonable limits -- preserves the correct behavior of existing programs
that have used mere string comparison. We believe this can be accomplished
without radical re-interpretation of the namespaces specification.

The advantage of this interpretation is that it preserves the full
expressive
power of URIs, including relative ones. We recognize that relative URIs are
essential for document writers who often write documents or groups of 
documents that are exposed on a Web server knowing the relative relationship
between those documents but not actually knowing the absolute URI of where
the document or documents will end up on that server. Any person publishing
through an ISP managed Web site has been through the exercise of building a
self-contained group of documents that when published would be moved to the
ISP's Web server. As you know, relative URIs are crucial for making this
operation work.

The proposal meets the following requirements:

   * Namespace names are URIs

   * No two namespace names will appear to be equal
     when more information would reveal them as unequal

   * Existing programs that employ string comparison will
     continue to work in all cases where string comparison
     produces results equal to comparison of absolutized URIs.

Based on the above discussion, the proposal is to clarify the wording 
of this paragraph in the XML NS spec [1] to instead of saying:

[[[Definition: URI references which identify namespaces are considered
identical when they are exactly the same character-for-character. Note
that URI references which are not identical in this sense may in fact be
functionally equivalent. Examples include URI references which differ
only in case, or which are in external entities which have different
effective base URIs.]]]

instead to say:

[[[According to RFC 2396 a URI reference can be either a relative or an
absolute URI. The scheme of an absolute URI identifies the URI space to
which that URI belongs. A URI space is typically defined with a set of
properties concerning uniqueness, normalization rules etc. as well as
one or more default mechanisms for resolving URIs belonging to that URI
space.

Relative URIs are always defined within a context. Typical examples are
relative references within the current document (fragment identifiers)
and relative references between documents at the same or closely related
level of hierarchy in the URI space. Within the same context, relative
links remain internally consistent and can act as unique identifiers
(within that context) without actually being expanded relative to the
context within which they are defined.

An application is responsible for knowing the context within which a
relative link is defined. RFC 2396, section 5, provides several
mechanisms for establishing the proper context within which relative
URIs are defined. An application is also responsible for ensuring that
relative identifiers are not treated as unique identifiers across
contexts as ignorance of context can make distinct identifiers appear
undifferentiated.]]]

This solution formalizes that you shouldn't do what was already a bad
practice, without actually FORCING the change on anyone. That is, anyone
who tries to compare relative URIs without checking (comparing?)
contexts is already asking for trouble. We now have a means to say that
explicitly.

We can now much better explain the risks to our customers, but we don't
put anything in our code that explicitly tries to stop them from doing
what they may be doing now. This is comparable to using "file:///" for
URIs. It's risky because it's meaning can change when a file moves to
another machine (i.e., a new context), but no one is proposing that
"file:///" be forbidden as a URI.

As this proposal has little or no negative impact on our existing customers,
while simultaneously clarifying the original intent of the Namespace 
specification, we fully support and endorse it as a resolution to the
namespace discussion at hand.


David Turner, Henrik Frystyk Nielsen and Andrew Layman(co-editor Namespaces
1.0 Recommendation)

[1] http://www.w3.org/TR/REC-xml-names/

Received on Thursday, 8 June 2000 14:11:55 UTC