- From: Kay, Michael <Michael.Kay@softwareag.com>
- Date: Mon, 4 Aug 2003 14:53:17 +0200
- To: Svgdeveloper@aol.com, xml-names-editor@w3.org, www-xml-blueberry-comments@w3.org, public-qt-comments@w3.org
- Cc: www-tag@w3.org
- Message-ID: <DFF2AC9E3583D511A21F0008C7E62106073DD01E@daemsg02.software-ag.de>
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"
Received on Monday, 4 August 2003 09:21:57 UTC