Named output ignored in 9.9 when using result-document with format attribute
When using <xsl:result document> with a format-attribute that refers to an xsl:output attribute, this seems to be ignored in 9.9.
<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="3.0"> <xsl:output method="text"/> <xsl:output name="xml" method="xml"/> <xsl:template name="main"> <xsl:result-document format="xml"> <xsl:message> <xsl:value-of select="system-property('xsl:product-name')"/> <xsl:text> </xsl:text> <xsl:value-of select="system-property('xsl:product-version')"/> </xsl:message> <test/> </xsl:result-document> </xsl:template> </xsl:stylesheet>
Produces different outputs for following versions:
C:\saxon>java -jar saxon9he.jar test.xsl -it:main SAXON HE 184.108.40.206 C:\saxon>java -jar Saxon-HE-9.8.0-1.jar test.xsl -it:main SAXON HE 220.127.116.11 <?xml version="1.0" encoding="UTF-8"?><test/>
#1 Updated by Michael Kay about 2 years ago
Thanks for reporting it. This area underwent considerable redesign in 9.9, and the case of xsl:result-document with no @href attribute was one of the hardest things to get right. It seems we are combining the serialization properties on the (empty) principal output with the properties on the xsl:result-document secondary output, and the former are taking precedence if both are explicitly specified. It's not clear that the properties of the principal output should be considered at all, let alone taking precedence: though there may be a problem here that by the time the xsl:result-document is evaluated, we can't tell which of the serialization properties on the principal output came from the stylesheet, and which came from the API or command line.
#2 Updated by Michael Kay about 2 years ago
It looks as if the problem is specific to running from the command line, which would explain why we didn't catch it in testing.
The Javadoc for the Serializer class suggests that the properties held in the Serializer are those supplied explicitly by the application, and exclude properties defined in the stylesheet. However, this isn't the case when the serializer is created via the transformer, using xslt30Transformer.newSerializer() - which is what the command line code is doing. This initiallizes the serializer with properties from the unnamed output format in the stylesheet, which are subsequently treated as if they were application-supplied, and therefore take precedence over the values supplied when a secondary output destination is created.
#4 Updated by Michael Kay about 2 years ago
- Category set to Serialization
- Status changed from New to Resolved
- Assignee set to Michael Kay
- Priority changed from Low to Normal
- Applies to branch 9.9, trunk added
- Fix Committed on Branch 9.9, trunk added
I have satisfied myself that this change is OK. Added some command-line unit tests.
#8 Updated by Michael Kay over 1 year ago
While debugging I noticed a bug that turns out not to be relevant (and may be symptomless):
SerializationProperties.getProperty() should call
properties.getProperty() rather than
properties.get(). It makes a difference when the
Properties object is layered, with an under-layer providing default values.
But this isn't enough, because at the time we call result-document, the Serializer is already initialised with method="text" and that is taking precedence over the new value.
It looks like I tested the patch on the development branch and then applied it incorrectly to the 9.9 branch. On 9.9, the change from
processor.newSerializer() was made only in the code handling -a invocation, which is not relevant to this test case (though the same change should probably be made there too). Making the same change on the "normal" path (
Transform.processFile()) solves the problem.
Please register to edit this issue