Bug #4315
closedNamed output ignored in 9.9 when using result-document with format attribute
100%
Description
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 9.9.1.1
C:\saxon>java -jar Saxon-HE-9.8.0-1.jar test.xsl -it:main
SAXON HE 9.8.0.1
<?xml version="1.0" encoding="UTF-8"?><test/>
Updated by Michael Kay over 4 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.
Updated by Michael Kay over 4 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.
Updated by Michael Kay over 4 years ago
Changing the Transform command line to use Processor.newSerializer()
rather than Xslt30Transformer.newSerializer()
solves this particular problem, but the change needs careful regression testing to ensure that it has no unwelcome side-effects.
Updated by Michael Kay over 4 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.
Updated by O'Neil Delpratt over 4 years ago
Added a further fix in the setOutputProperty method in the class IdentityTransformer to ignore unknown namespaces as we saw regression in the Saxon-HE product.
Updated by O'Neil Delpratt over 4 years ago
- Status changed from Resolved to Closed
- Fixed in Maintenance Release 9.9.1.6 added
Patch committed to the Saxon 9.9.1.6 maintenance release.
Updated by Michael Kay about 4 years ago
- Status changed from Closed to In Progress
The supplied test case is not working in 9.9.1.6; therefore re-opening.
Updated by Michael Kay about 4 years 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 transformer.newSerializer()
to 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.
Updated by Michael Kay about 4 years ago
- Status changed from In Progress to Resolved
New patch committed.
Updated by O'Neil Delpratt about 4 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.9.1.7 added
- Fixed in Maintenance Release deleted (
9.9.1.6)
Patch applied in the 9.9.1.7 maintenance release.
Please register to edit this issue