Details
-
Bug
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
2.9.1, 2.11.0
-
None
-
None
Description
Consider the following XML document:
<root xmlns="urn:test"><child xmlns=""/></root>
Assume that the document is constructed programmatically without explicitly adding the namespace declarations:
Document document = DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();
Element root = document.createElementNS("urn:test", "root");
document.appendChild(root);
Element child = document.createElementNS(null, "child");
root.appendChild(child);
The expectation is that when looking up the default namespace on the child element, the result is null. However, this is not the case, as demonstrated by the following code:
System.out.println("uri=" + child.lookupNamespaceURI(null));
In fact, the output is:
uri=urn:test
Moreover, the result changes after normalizing the document:
document.normalizeDocument();
System.out.println("uri=" + child.lookupNamespaceURI(null));
The output with Xerces 2.9.1 is now (Note that the result is still not correct because one would expect uri=null, but this has been fixed in recent Xerces versions; see XERCESJ-1394):
uri=
The reason is that normalizeDocument adds xmlns="" to the child node (as expected).
Actually, the behavior of lookupNamespaceURI shown here strictly conforms to the DOM Level 3 Core specification, as described in appendix B.4. That is because of the namespace != null condition in the following part of the pseudo code:
if ( Element's namespace != null and Element's prefix == prefix )
{ // Note: prefix could be "null" in this case we are looking for default namespace return (Element's namespace); }However, if one strictly follows the specification, then normalizeDocument should also not add xmlns="" to the child element. In fact, the action taken by normalizeDocument to fixup the namespace of that element is described by the following part of the pseudo code in appendix B.1:
// Element has no pseudo-prefix
if ( there's a conflicting local default namespace declaration
already present )
// NOTE that this may break other nodes within this Element's
// subtree, if they're already using the default namespaces.
// They will be repaired when we reach them.
Since there is no conflicting local default namespace declaration on the child element, according to the specification, nothing should be done. This is obviously not what one wants in this case, and Xerces ignores that aspect of the specification. However, for consistency, Xerces should then also ignore the namespace != null condition in appendix B.4.