Details
-
Bug
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
2.7.1
-
None
-
None
Description
At least for this testcase:
<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0" xmlns="http://myco.com" >
<xsl:output method="html"/>
<xsl:template match="/">
<HTML><br/></HTML>
</xsl:template>
</xsl:stylesheet>
XSLTC outputs:
<HTML xmlns="http://myco.com">
<br>
</HTML>
But the correct output is:
<HTML xmlns="http://myco.com">
<br />
</HTML>
The element "br" is in the non-null namespace URI "http://myco.com" due to the default namespace declaration.
See section 16.2 of the XSLT 1.0 recommendation ( http://www.w3.org/TR/xslt#section-HTML-Output-Method ), says:
<<
The html output method should not output an element differently from the xml output method unless the expanded-name of the element has a null namespace URI; an element whose expanded-name has a non-null namespace URI should be output as XML.
>>
The bug seems to be that both the startElement() and endElement() calls on the serializer pass a URI of null. But the serializer seems to take this to mean that the element is in no namespace. This is not what null means on these calls. It means "I don't know what the URI is. The serializer could do a little extra work to figure out the default namespace. Indeed there is code already in the serializer. In SerializerBase there is code like this when determining if the current element is a cdata section:
if ( m_elemContext.m_elementURI == null)
Looks like something similar might save the day for endElement(String name) here.
I must give credit to Erin H. for finding this bug, and for the fix too. Maybe one day she will be a committer, but for now she is a contributor.