XML Namespaces

DOM Level 2 and 3 support XML namespaces [XML Namespaces] by augmenting several interfaces of the DOM Level 1 Core to allow creating and manipulating elements and attributes associated to a namespace.

When [XML 1.1] is in use (see DomDocument::getXmlVersion() ), DOM Level 3 also supports [XML Namespaces 1.1].

As far as the DOM is concerned, special attributes used for declaring XML namespaces are still exposed and can be manipulated just like any other attribute. However, nodes are permanently bound to namespace URIs as they get created. Consequently, moving a node within a document, using the DOM, in no case results in a change of its namespace prefix or namespace URI. Similarly, creating a node with a namespace prefix and namespace URI, or changing the namespace prefix of a node, does not result in any addition, removal, or modification of any special attributes for declaring the appropriate XML namespaces. Namespace validation is not enforced; the DOM application is responsible. In particular, since the mapping between prefixes and namespace URIs is not enforced, in general, the resulting document cannot be serialized naively. For example, applications may have to declare every namespace in use when serializing a document.

In general, the DOM implementation (and higher) doesn’t perform any URI normalization or canonicalization. The URIs given to the DOM are assumed to be valid (e.g., characters such as white spaces are properly escaped), and no lexical checking is performed. Absolute URI references are treated as strings and compared literally. How relative namespace URI references are treated is undefined. To ensure interoperability only absolute namespace URI references (i.e., URI references beginning with a scheme name and a colon) should be used. Applications should use the value null as the namespaceURI parameter for methods if they wish to have no namespace. In programming languages where empty strings can be differentiated from null, empty strings, when given as a namespace URI, are converted to null. This is true even though the DOM does no lexical checking of URIs.

Note:
DomElement::setAttributeNS() with null as first argument, puts the attribute in the per-element-type partitions as defined in XML Namespace Partitions in [XML Namespaces].

In the DOM, all namespace declaration attributes are by definition bound to the namespace URI: "http://www.w3.org/2000/xmlns/". These are the attributes whose namespace prefix or qualified name is "xmlns" as introduced in [XML Namespaces 1.1].

In a document with no namespaces, the child list of an DomEntityReference node is always the same as that of the corresponding DomEntity. This is not true in a document where an entity contains unbound namespace prefixes. In such a case, the descendants of the corresponding EntityReference nodes may be bound to different namespace URIs, depending on where the entity references are. Also, because, in the DOM, nodes always remain bound to the same namespace URI, moving such DomEntityReference nodes can lead to documents that cannot be serialized. This is also true when the DOM Level 1 method DomDocument::createEntityReference() is used to create entity references that correspond to such entities, since the descendants of the returned DomEntityReference are unbound. While DOM Level 3 does have support for the resolution of namespace prefixes, use of such entities and entity references should be avoided or used with extreme care.

The "NS" methods, such as DomDocument::createElementNS() and DomDocument::createAttributeNS(), are meant to be used by namespace aware applications. Simple applications that do not use namespaces can use the DOM Level 1 methods, such as DomDocument::createElement() and DomDocument::createAttribute(). Elements and attributes created in this way do not have any namespace prefix, namespace URI, or local name.

Note:
DOM Level 1 methods are namespace ignorant. Therefore, while it is safe to use these methods when not dealing with namespaces, using them and the new ones at the same time should be avoided. DOM Level 1 methods solely identify attribute nodes by their DomNode::getNodeName(). On the contrary, the DOM Level 2 methods related to namespaces, identify attribute nodes by their DomNode::getNamespaceURI() and DomNode::getLocalName(). Because of this fundamental difference, mixing both sets of methods can lead to unpredictable results. In particular, using DomElement::setAttributeNS(), an element may have two attributes (or more) that have the same DomNode::getNodeName(), but different DomNode::getNamespaceURI(). Calling DomElement::getAttribute(name) with that nodeName could then return any of those attributes. The result depends on the implementation. Similarly, using DomElement::setAttributeNode(), one can set two attributes (or more) that have different DomNode::getNodeName() but the same DomNode::getPrefix() and DomNode::getNamespaceURI(). In this case DomElement.getAttributeNodeNS(namespaceURI, localName) will return either attribute, in an implementation dependent manner. The only guarantee in such cases is that all methods that access a named item by its nodeName will access the same item, and all methods which access a node by its URI and local name will access the same node. For instance, DomElement::setAttribute() and DomElement::setAttributeNS() affect the node that DomElement::getAttribute() and DomElement::getAttributeNS(), respectively, return.

Generated on Fri May 30 11:15:05 2008 for XMLDOM by  doxygen 1.5.2