Copyright © 2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
This document contains requirements on the development of Namespaces in XML version 1.1, which is intended to have a single new feature - the ability to undeclare namespaces. In addition, all errata of version 1.0 will be incorporated.
This is a W3C Working Draft produced as a deliverable of the XML Core WG according to its charter and the current XML Activity process. A list of current W3C working drafts and notes can be found at http://www.w3.org/TR.
This document is a work in progress representing the current consensus of the W3C XML Core Working Group. It is published for review by W3C members and other interested parties. Publication as a Working Draft does not imply endorsement by the W3C membership. Comments should be sent to www-xml-blueberry-comments@w3.org, which is an automatically and archived email list.
Namespaces in XML 1.1 is intended to have a single new feature - the ability to undeclare namespaces. In addition, all [Namespaces in XML 1.0 errata] will be incorporated. The Core Working Group is currently evaluating potential errata which it expects to publish and include in Namespaces in XML 1.1.
[Namespaces in XML 1.0] has the ability to undeclare the default namespace, but doesn't provide a facility to undeclare namespaces with prefixes. An obvious syntax for such functionality would be an empty namespace attribute value (xmlns:prefix=""
). This omission has had adverse consequences on infoset manipulations and serializers.
For example, [XInclude 1.0] allows information items to be added to an element as children. These information items come from another document, and may have fewer in-scope namespaces than their parent. There is no mechanism for accurately serializing this situation. If the infoset is naively serialized and reparsed, the children will end up with additional namespace information items which serve no useful purpose. Even worse, the inability to roundtrip an infoset through XML accurately prevents accurate canonicalization, and the security features based upon it ([XML Digital Signatures], [XML Encryption]).
Transmission of XML in a [SOAP] envelope has similar problems. A piece of XML placed within the SOAP envelope for transmission, and extracted at the other end, will have additional namespace information items that have "bled through" from the envelope.
[XQuery] and the [XPath 2.0 and XQuery 1.0 Data Model] increase the likelihood that large data sets will be exposed as XML documents. In a gigabyte database modeled as a single XML document, it is likely that leaf nodes in the data will have a large number of namespace nodes, many of which are relevant only higher up in the hierarchy.
It is the view of the [XML Core Working Group] that [XML 1.1] provides an opportunity to correct this omission. The version declaration version="1.1"
provides a versioning marker that can also serve to indicate Namespaces in XML 1.1.
The XML 1.0 goals listed in section 1.1 of the XML Recommendation are reaffirmed.
Namespaces in XML 1.1 must be a superset of Namespaces in XML 1.0 in both functionality and syntax.
Namespaces in XML 1.1 will correspond to XML 1.1.
Namespaces in XML 1.1 must be prepared quickly.
Namespaces in XML 1.1 must be advanced to Recommendation concurrently with XML 1.1.
The changes required for Namespaces in XML 1.0 processors to also process Namespaces in XML 1.1 must be as few and as small as possible.
The Namespaces in XML 1.1 specification must incorporate all published errata to Namespaces in XML 1.0.
In creating Namespaces in XML 1.1, the working group should not consider any revisions to Namespaces in XML 1.0 except those needed to accomplish these requirements.