Saxon

Yes, there is certainly a need for this, and it's needed on the Java version of the s9api interface too.

For some reason I was under the impression we needed to rethink this to make the design thread-safe, but as far as I can see the design on the .NET XsltTransformer looks perfectly sound and I'm not sure why it hasn't been rolled out more widely.

I think that in fact the reason we were holding off doing this was the need to sort out the build-tree issue. The interface as provided on the .net XsltTransformer is fine for the case where xsl:result-document produces XML with build-tree=yes. It's not so clear what should happen where for example the result-document is outputting JSON, and build-tree="no".

The most general kind of Destination is called Destination in the Java interface, and XmlDestination in the .NET interface. The .NET name is unfortunate, Furthermore, both Java and .NET have an XdmDestination class which is something of a misnomer, since it always builds a node tree. There seems to be a need for an additional kind of Destination, perhaps RawDestination, which simply accepts the raw output of the stylesheet as an arbitrary sequence and delivers it as an XdmValue.

The problem then becomes the interaction of the API with things in the stylesheet itself. If the stylesheet says build-tree="yes", and you supply a RawDestination, what should happen? Generally the approach is that the API takes precedence (for example, serialization parameters supplied by the calling application take precedence over those specified in xsl:output). This is consistent with the XSLT spec which says (in §2.3.6)

A result tree may be constructed from the raw result. By default, a result tree is constructed if the build-tree attribute of the unnamed output definition has the effective value yes. An API for invoking transformations may allow this setting to be overridden by the calling application.

Noted also that the .NET implementation of ResultDocumentHandler is not thread-safe.

I have added a ResultDocumentHandler interface to the Java XsltTransformer and Xslt30Transformer (for 9.9)

(On the Java side, for 9.9) I have added a new subclass of Destination called RawDestination, and have improved the logic for deciding when to build a tree based on a combination of the type of Destination supplied, and the serialisation parameters in the query or stylesheet.

As this is now implemented in 9.9 on the Java side, I would like to see it for .NET as well when 9.9 will be released.

Does it help put it on the official agenda to file a feature request for the .NET side?