Bug #2875
closedInconsistency between Saxon 9.6 and Saxon 9.7 in output directory with xsl:result-document and @saxon:next-in-chain
0%
Description
This may be related to the behavior I reported in 9.6 in Issue 2310 a while ago, but in this case I have a transformation scenario that was working in all versions of Saxon through 9.6 but breaks in 9.7. Given chained transformations via <xsl:output @saxon:next-in-chain="">, when the final transformation is using xsl:result-document with an @href containing a relative URI, Saxon 9.7 is not resolving the URI relative to the input document but relative to the stylesheet.
I am attaching a simple transformation scenario that will illustrate the different behavior--see the README file.
In my real-world case, I have a more complex sequence of chained transformations, where the final one is producing a run-time error in 9.7:
Error in xsl:result-document/@href on line 29 column 84 of 99-99-save.xsl:
Invalid relative URI syntax: URI is not absolute
Invalid relative URI syntax
I have various workarounds but thought I should submit this report so you can decide whether it's worth addressing.
Files
Updated by David Sewell over 8 years ago
For what it's worth, it looks like my best workaround is to use XSLT 3 and then use a pseudo-relative URI along the lines of
<xsl:result-document href="{concat('file://', fn:environment-variable('PWD'), '/../output/', $filename)}"/>
as $PWD equates to the current working directory when Saxon is invoked. The result document gets written to the desired place for both 9.6 and 9.7.
Updated by Michael Kay over 8 years ago
One clarification about the spec: the href attribute of xsl:result-document in a downstream chained stylesheet should be resolved relative to the base output URI of the transformation, which is not necessarily the same as either the source document base URI nor the stylesheet base URI.
Updated by Michael Kay over 8 years ago
- Status changed from New to In Progress
Firstly, let's look at what happens without next-in-chain. If my stylesheet does:
<xsl:template match="/">
<xsl:result-document href="out.xml">
<one/>
</xsl:result-document>
</xsl:template>
and I invoke it with:
-xsl:test.xsl -s:test.xml -o:outdir/dummy.xml
then both 9.6 and 9.7 correctly write the output to outdir/out.xml
and produce the message
Writing to file:/Users/zzzz/Desktop/temp/outdir/out.xml
If I now add
<xsl:output saxon:next-in-chain="test2.xsl"/>
where test2.xsl does
<xsl:template match="/">
<xsl:result-document href="out2.xml" saxon:next-in-chain="test2.xsl">
<two><xsl:copy-of select="."/></two>
</xsl:result-document>
</xsl:template>
then 9.6 produces the two messages
Writing to file:/Users/zzzz/Desktop/temp/out.xml
Writing to file:/Users/zzzz/Desktop/temp/out2.xml
while 9.7 produces the two messages
Writing to file:/Users/zzzz/Desktop/temp/outdir/out.xml
Writing to file:/Users/zzzz/Desktop/temp/out2.xml
I believe the correct action according to the spec is to write to:
file:/Users/zzzz/Desktop/temp/outdir/out2.xml
and neither release is doing that.
The key statement in the documentation is: "The output of the second stylesheet will be directed to the destination that would have been used for the first stylesheet if no saxon:next-in-chain attribute were present." This means the base output URI for the second transformation should be the same as the base output URI of the first.
Updated by Michael Kay over 8 years ago
OK: a simplified test. The first stylesheeet uses <xsl:result-document href="out.xml"/>
. The second just writes to the principal output destination. The invocation uses -o:outdir/dummy.xml.
Saxon 9.6 is writing to out.xml, Saxon 9.7 is writing to outdir/out.xml. I think Saxon 9.7 is clearly correct according to the documentation, and 9.6 is wrong.
Updated by David Sewell over 8 years ago
OK, thanks for investigating. We'll need to keep that in mind and check our legacy code for consistency and portability then.
Updated by Michael Kay about 8 years ago
- Status changed from In Progress to Closed
Closing this as it's not clear that there is a bug here.
Please register to edit this issue