RE: XSLT 2.0 - One namespace URI, two collections of names

I don't think there's anything in the XML namespace definition that says the
collection of names must be immutable, and more than a document on the web
that's identified by a URI must be immutable.
 
I know there's been a lot of discussion in architectural circles about how
best to manage the evolution of a vocabulary, but I believe that the path
we've chosen in XSLT 2.0 is completely workable, and is not in violation of
any specifications or recommended practice. The fact that a version
attribute was introduced in XSLT 1.0 gave a clear signal that the XSLT
namespace was expected to evolve with time.
 
Michael Kay

-----Original Message-----
From: Svgdeveloper@aol.com [mailto:Svgdeveloper@aol.com] 
Sent: 24 October 2002 19:18
To: public-qt-comments@w3.org
Subject: XSLT 2.0 - One namespace URI, two collections of names


I apologise if this issue has already been raised on list. I have a vague
recollection of seeing some discussion of this issue but don't recall where.

In the Namespaces in XML Recommendation the following definition is given:
"An XML namespace is a collection of names, identified by a URI reference".

In XSLT 1.0 we have the namespace URI http://www.w3.org/1999/XSL/Transform
associated with the collection of element type names enumerated in the XSLT
1.0 Recommendation.

In XSLT 2.0 we have the same namespace URI associated with a non-identical
collection of element type names.

So, on the surface at least, XSLT (2.0) is not consistent with the
Namespaces in XML Recommendation.

I appreciate that an XSLT processor will, in all likelihood, use the
xsl:version attribute to resolve the ambiguity. However, it seems to me that
succeeding versions of many XML application languages are likely to provide
successive distinct collections of element type names, associated apparently
with the same namespace URI.

Perhaps this is an issue for the TAG, rather than being an issue specific to
XSLT 2.0.

Andrew Watt