Leave explicit namespace declarations in output

[rolfl]

From http://stackoverflow.com/questions/10597274/leaving-duplicate-namespace-declarations-with-jdom

I'm trying to read existing xml file, that has duplicated namespace declarations. It is important to me to leave this declarations for further processing. Earlier I was using XERCES implementation of org.w3c.dom api to read such a documents, and all declarations left, but when I started to use JDOM, it started to omit redundant namespace declarations.

Here is the sample xml file:

<?xml version="1.0" encoding="UTF-8"?>
<document xmlns:ns="namespace_uri">
  <element1>...</element1>
  <element2>
    <ns:child>
      text
    </ns:child>
  <element3 xmlns:ns="namespace_uri">
    <ns:child>
      content
    </ns:child>
  </element3>
</document>

I'm building JDOM Document with this code:

SAXBuilder builder = new SAXBuilder();
File inputXml = new File(inputFile);
jdomInDoc = builder.build(inputXml);

Is there any way to force JDOM not to omit redundant namespace declarations?

Thank you in advance for yor answers.

[rolfl]

Right, I have investigated this issue, and decided it is too intrusive to implement.... I cannot keep backward compatibility.

The issues on input handling are:

• SAXHandler needs to be modified to use a different mechanism to track whether a namespace notification is redundant or explicit. This would require SAXHandler to maintain state information about the 'in-scope' namespaces which it currently does not do. Further, the resutls of parsing some documents (with explicit redundant namespaces) will be different to what they used to be in some cases (especially when the redundant namespace is the Element's namespace - which is the exact example given in the issue...
• Other handlers (DOM, StAX, etc.) will need to have similar modification, though it is unlikely that the StAX handlers will support the redundant Namespace declarations at all

As for output handling:

• Format class needs to be modified to allow the setting of a flag to output redundant declarations.
• The NamespaceStack needs to be modified to allow conditional processing of Namespaces
• All the Outputters (XML, SAX, StAX, DOM, etc.) need to be modified to use the new NamespaceStack constructor.

The bottom line is that backward compatibility will be compromised, almost all the input/output classes in JDOM will need to be 'touched' to make it work. The value of the feature is very marginal.

In the balance, it is not appropriate to implement this feature (at this point.... probably not in the 2.x cycle at all ... in other words, don't expect this to change)

[rolfl]

Right, I have investigated this issue, and decided it is too intrusive to implement.... I cannot keep backward compatibility.

The issues on input handling are:

• SAXHandler needs to be modified to use a different mechanism to track whether a namespace notification is redundant or explicit. This would require SAXHandler to maintain state information about the 'in-scope' namespaces which it currently does not do. Further, the resutls of parsing some documents (with explicit redundant namespaces) will be different to what they used to be in some cases (especially when the redundant namespace is the Element's namespace - which is the exact example given in the issue...
• Other handlers (DOM, StAX, etc.) will need to have similar modification, though it is unlikely that the StAX handlers will support the redundant Namespace declarations at all

As for output handling:

• Format class needs to be modified to allow the setting of a flag to output redundant declarations.
• The NamespaceStack needs to be modified to allow conditional processing of Namespaces
• All the Outputters (XML, SAX, StAX, DOM, etc.) need to be modified to use the new NamespaceStack constructor.

The bottom line is that backward compatibility will be compromised, almost all the input/output classes in JDOM will need to be 'touched' to make it work. The value of the feature is very marginal.

In the balance, it is not appropriate to implement this feature (at this point.... probably not in the 2.x cycle at all ... in other words, don't expect this to change)