Saxon

Fails when run from command line with:

java.lang.NullPointerException

at com.saxonica.serialize.SerializerFactoryPE.prepareNextStylesheet(SerializerFactoryPE.java:207)

at net.sf.saxon.lib.SerializerFactory.getReceiver(SerializerFactory.java:161)

at net.sf.saxon.s9api.Serializer.getReceiver(Serializer.java:743)

at net.sf.saxon.s9api.Xslt30Transformer.getDestinationReceiver(Xslt30Transformer.java:910)

at net.sf.saxon.s9api.Xslt30Transformer.applyTemplates(Xslt30Transformer.java:551)

at net.sf.saxon.Transform.processFile(Transform.java:1245)

at net.sf.saxon.Transform.doTransform(Transform.java:797)

at net.sf.saxon.Transform.main(Transform.java:78)

Fails when using a s9api Xslt30Processor directly:

saxon:next-in-chain is ignored when using an Xslt30Transformer

Fails when using a s9api XsltProcessor:

output is the output of the first stylesheet, the saxon:next-in-chain attribute is ignored.

Succeeds when using JAXP

(Rather surprisingly, because JAXP uses the s9api Xslt30Transformer underneath).

This is proving quite troublesome as the feature really needs a complete redesign.

One difficulty is that it relies heavily on the transformation destination being a serializer; the logic for looking at the xsl:output parameters is all associated with serialization. This isn't a problem when running from the command line, but if the transformation is invoked via s9api interfaces, serialization is optional. I think I may have to document a constraint here.

I'm focussing at the moment on the use of next-in-chain to handle the primary transformation result; for this case the right place to do the work appears to be in the s9api layer, rather than deeper at the PreparedStylesheet/Controller level which is where it happens at the moment. The downside of this is (a) that this doesn't work so well for secondary output documents, and (b) it will have to be replicated for .NET.

Now tested successfully (in all 4 scenarios) with secondary result documents as well as the principal result.