Bug #2310
closedsaxon:next-in-chain extension to xsl:output buggy when xsl:result-document is used
100%
Description
[found in Saxon-PE 9.6.0.4J]
In 9.4 and 9.5 (at least), @saxon:next-in-chain worked fine when the initial transform used xsl:result-document to create one or more result documents in output passed to the next transform in a chain.
With the attached files, saxon -s:input.xml -xsl:transform1-withresultdoc.xsl
produces expected output in the current directory, but complains "No source document has been built by the previous pipeline stage".
Operating on an input directory, e.g. with input.xml copied to a directory In, the command saxon -s:In -o:Out -xsl:transform1-withresultdoc.xsl
writes output to the current directory, not "Out", but reports a transformation failure with "While processing input.xml: No source document has been built by the previous pipeline stage".
(More complex chained transformations may produce other types of buggy behavior. In my actual use case, Transform 2 invokes a character map in its xsl:output element, but Transform 1, which does not use a character map, nevertheless fails with 'SEPM0016: Character map 'specialChar' has not been defined'. The transforms ran without problem under Saxon 9.5.)
Files
Updated by Michael Kay almost 10 years ago
- Category set to Serialization
- Status changed from New to In Progress
- Assignee set to Michael Kay
Sorry for the delay in responding.
The way in which saxon:next-in-chain works has changed significantly in 9.6, and the implementation for principal result documents is rather different from the implementation for xsl:result-document.
For the principal document, the s9api XsltTransformer asks the stylesheet for details of the xsl:output options, and if next-in-chain is present then it sets up the Destination of the transformer to be another transformer. It is this second transformer that is complaining if the first transformation fails to produce a result tree; though as you observe, this is in fact quite legitimate if a secondary result document has been produced. For this one, I'm simply going to remove the message, even though there may be cases where this causes an difficult-to-explain lack of output.
I haven't managed to reproduce the problem with character maps: I created a test and it's working fine, both with and without a result-document instruction.
Updated by David Sewell almost 10 years ago
- File Saxon-chain-example.zip Saxon-chain-example.zip added
I'm not sure how much time it's worth spending on this, given that I can find a workaround (basically, not using saxon:next-in-chain for this particular transformation scenario), but I'm attaching a zipfile containing the code/data environment in which Saxon 9.5 succeeds and Saxon 9.6 fails.
From the directory containing the XSLT, run a transform like
saxon -xsl:Split-publs.xsl -s:In -o:Out
(Split-publs.xsl chainsn Split-publs-2.xsl)
When I try it, Saxon 9.5 succeeds and generates 184 output docs in Out; 9.6 fails with
Error at xsl:if on line 535 of Split-publs.xsl:
SEPM0016: Character map 'specialChar' has not been defined
but the xsl:character-map element is in the chained transform, not Split-publs.xsl. The primary transform runs fine in 9.6 if the saxon:next-in-chain instruction is suppressed.
Apologies in advance for the baroque nature of the XSLT code.
Updated by Michael Kay almost 10 years ago
- Status changed from In Progress to Resolved
Thanks. This was a fairly simple bug: while processing next-in-chain within the first stylesheet, a serializer is created for the second stylesheet to use, and this was being created with the character maps from the first stylesheet instead of the second. Patched in the 9.6 and 9.7 branches.
(As it happens, getting this to work on the 9.7 branch revealed some other bugs, but you don't want to know about those...)
Updated by David Sewell almost 10 years ago
Thanks! I've probably mentioned this before, but Saxon is critical in creating the XML data that runs Founders Online (http://founders.archives.gov/), so this particular bugfix is a help.
David
Updated by O'Neil Delpratt over 9 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in version set to 9.6.0.5
Bug fix applied in the Saxon 9.6.0.5 maintenance release.
Updated by O'Neil Delpratt about 9 years ago
- Sprint/Milestone set to 9.6.0.5
- Applies to branch 9.6 added
- Fix Committed on Branch 9.6 added
- Fixed in Maintenance Release 9.6.0.5 added
Please register to edit this issue