Comment as shared by Customer:
When we upgraded from Java 5 to Java 6, something is now inserting 'standalone="no"' into the initial <?xml?> line in XML that is constructed using DOM and pretty-printed using XSLT.
Looks like a direct contradiction of the specification in http://www.w3.org/TR/xslt#output section 16.1: "If the standalone attribute is specified, it should include a standalone document declaration with the same value as the value as the value of the standalone attribute. Otherwise, it should not include a standalone document declaration"
Our code is not specifying the standalone attribute.
com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.setDocumentInfo(), when the document has the default false standalone property, calls _handler.setStandalone("false"). The argument is actually a computation but its result is always the string "false".
The callee is statically an instance of the com.sun.org.apache.xml.internal.serializer.XSLOutputAttributes interface. Its javadoc says its argument is "yes" or (by implication) "no", not "true" or "false".
The implementation of that method is in com.sun.org.apache.xml.internal.serializer.SerializerBase. It has the same javadoc as the interface method, but it actually looks for "yes", "no", or null. If given anything else, it will take it as "no".
So one problem is the caller uses "true"/"false" but the callee expects "yes"/"no". This is less of a problem than it could be because the caller only passes "false" and the callee interprets anything it does not recognize as "no."
Another problem is the caller always calls, but the callee expects to be called only when the property was *not* defaulted.
It is broken in the same way in the latest version, jdk1.6.0_14.
The offending setDocumentInfo() method does not exist in Apache's latest, XAlan 2.7.1. Must be something that Sun added.
Another problem with that method is that if we had called Document.setStandalone(true), expecting to see "standalone='yes'" in the output XML header, setDocumentInfo() would not have called _handler.setStandalone() and so SerializerBase.m_standalone_was_specified would have remained false and the XML header would not have a standalone attribute. The behavior is exactly backwards!
The defective code is only executed when the XSLT source is DOM, not when the source is SAX. That explains why only one of our programs sees the problem.
Why it doesn't fail in JDK 5:
SerializerBase.setStandalone() is the same as in JDK 6, but it is not called. There is no DOM2TO.setDocumentInfo() in jdk 5. In jdk 6 that method exists and is called from DOM2TO.parse(Node).