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 <A HREF="http://www.w3.org/1999/XSL/Transform">
http://www.w3.org/1999/XSL/Transform</A> 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"