JAXP: XSLTC transformer swallows empty namespace declaration which is necessary to undeclare default namespace

Langer, Christoph christoph.langer at sap.com
Fri Jul 22 10:38:11 UTC 2016


Hi,

I have a customer reporting the following phenomena which I believe is an issue.

Consider the following xsl:

---------------------XSL---------------------
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
                <xsl:template match="/">
                               <root xmlns="ns1">
                                               <xsl:call-template name="transform"/>
                               </root>
                </xsl:template>
                <xsl:template name="transform">
                <test xmlns=""/>
                </xsl:template>
</xsl:stylesheet>
---------------------End of XSL---------------------


This is the XML snippet where the XSL gets applied (just a dummy):
<?xml version="1.0" encoding="UTF-8"?><aaa></aaa>

The result with the current XSLTC is:
<?xml version="1.0" encoding="UTF-8"?><root xmlns="ns1"><test/></root>
But this would not undeclare the default namespace "ns1" from the element named "root" for the element named "test" which was the intention of the xsl. So I believe it should be:
<?xml version="1.0" encoding="UTF-8"?><root xmlns="ns1"><test xmlns=""/></root>

Looking at the coding I came up with the following: http://cr.openjdk.java.net/~clanger/webrevs/xsltc-namespaceissue/ With that, XSLTC would also emit the namespace attribute for an empty namespace. It works for my example but I'm not sure if it is the right thing to do or if it breaks things at other places and violates specs elsewhere.

Comparing with the Apache Xalan, I can see that the Apache XSLTC matches the JDK XSLTC behavior to suppress the namespace declaration but the interpretative transformer (org.apache.xalan.processor.TransformerFactoryImpl) would emit the namespace attribute.

Please give me some comments before I open a Bug...

Thanks a lot in advance
Christoph



More information about the core-libs-dev mailing list