RE: Inherent Namespace Ambiguities - A Serious Fundamental Proble m?

Clearly, schemas evolve over time, and clearly, the set of XML
specifications, considered as a whole, does not yet address the question of
schema evolution.
 
Your note really seems to be about schema evolution rather than namespace
evolution. Namespace evolution is a trivial problem: the set of names in a
namespace can grow over time but it cannot shrink. The real concern is the
evolving semantics of those names, which is a schema problem and not a
namespace problem.
 
I'm not a serious fundamentalist, I'm an engineer. I think the design of
XSLT 2.0, which relies on a combination of namespace mechanisms and a
version attribute, meets the practical engineering requirements. Can you
point to a practical user requirement which the solution does not meet?
 
Michael Kay

-----Original Message-----
From: Svgdeveloper@aol.com [mailto:Svgdeveloper@aol.com] 
Sent: 02 August 2003 11:24
To: xml-names-editor@w3.org; www-xml-blueberry-comments@w3.org;
public-qt-comments@w3.org
Cc: www-tag@w3.org
Subject: Inherent Namespace Ambiguities - A Serious Fundamental Problem?


It seems to me that, at a fundamental level, there is a problem with the
Namespaces in XML 1.0 Recommendation and the Namespaces in XML 1.1
specification. There is no mechanism defined to allow for change of any type
in the names (or their implied characteristics) in a namespace. It is as if
the WG had overlooked the inevitability of change of names and their
characteristics over time. This becomes a substantive problem when different
versions of a namespace-aware specification are defined.

This problem affects, for example, XPath 2.0 and XSLT 2.0, if I understand
the problem correctly, and will also affect all other namespace-aware
specifications as they move beyond version 1.0.

The problem is ironic since it was a purpose of the Namespaces in XML
Recommendation to disambiguate element and attribute names.

As an example, let's consider the name "apply-templates" in the XSLT
Namespace. Is it unambiguously identified by the URI
http://www.w3.org/1999/XSL/Transform? My view is that it is not.

One aspect of the problem is that the name "apply-templates" in the XSLT
Namespace identifies two entities with different characteristics, thus
creating a new dimension of ambiguity. 

In XSLT 1.0 the name "apply-templates" implies, among other things, the
characterisitic of not having an associated version attribute or an
associated xpath-default-namespace attribute. In XSLT 2.0 the identical
(same??) name implies the presence of both associated attributes. Similar
considerations apply to other XSLT elements.

Thus the namespace URI alone is insufficient to unambiguously identify an
element type name and its associated characteristics. Having one name
allegedly in the same namespace but with two different sets of
characteristics seems to me to be a recipe for problems.

Another difficulty arising from the same fundamental problem is deciding
whether or not a name is present in or is absent from the XSLT namespace.
Take the name "analyze-string" as an example. Is it in the namespace
http://www.w3.org/1999/XSL/Transform <http://www.w3.org/1999/XSL/Transform>
or not? The namespace URI is insufficient to remove that fundamental
ambiguity.

XSLT 2.0 and XPath 2.0 attempt to sidestep the issue by indicating that a
version attribute provides unambiguous clarity. That may or may not be the
case. 

However, the XSLT 2.0 specification also claims conformance with Namespaces
in XML 1.0 where only the namespace URI is designated as the means to
disambiguate names.

It seems to me that it is not possible for XSLT 2.0 to claim conformance
with Namespaces in XML 1.0 while at the same time using a disambiguating
mechanism which circumvents the namespace URI as the disambiguating
mechanism.

It seems to me that either the Namespaces in XML specifications need to be
changed to reflect the inadequacy of the namespace URI alone as a sufficient
disambiguating mechanism or the XSLT 2.0 specification (and other
namespace-aware specifications above version 1.0) need to indicate that they
are using a disambiguating mechanism not defined in the Namespaces in XML
specifications.

Since I believe this is one of several issues related to the characteristics
of XML namespaces which need review and that it impacts several XML
technologies I am copying this to the TAG.

Andrew Watt
"XHTML 2.0 - the W3C leading the Web to its full potential ... to implement
yesterday's technology tomorrow"