Uploaded image for project: 'Xerces2-J'
  1. Xerces2-J
  2. XERCESJ-1586

lookupNamespaceURI may return unexpected result when looking up default namespace

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Open
    • Minor
    • Resolution: Unresolved
    • 2.9.1, 2.11.0
    • None
    • DOM (Level 3 Core)
    • 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 )

      { ==> change its value to use this empty namespace. }

      // 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.

      Attachments

        Activity

          People

            Unassigned Unassigned
            veithen Andreas Veithen
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated: