Saxon

Congratulations on the first bug report. It never ceases to amaze me how we spend 3 months running a million tests, and within hours users find something very basic that doesn't work.

There's been a change in the handling of an xsl:result-document instruction with no @href attribute, though we didn't quite predict this consequence. Saxon 9.9 is doing more closely what the spec says it should do, which is to default the @href attribute to the value of the base output URI. When you run from the command line, with no -o option, the base output URI is the current working directory, and writing to that is obviously going to fail.

In previous releases xsl:result-document with no @href attempted to reuse the output stream established for the primary output of the transformation, regardless of whether or not it had a known URI. This strategy doesn't extend well to the wider range of output delivery mechanisms now available for a transformation, in particular the possibility of "raw output".

I'll have another think about how this can be made to work. Meanwhile using -o on the command line should work around the problem.

I have a solution which works, though it needs further thought and further testing.

(1) The s9api layer (AbstractXsltTransformer.getDestinationReceiver()) registers the principal Destination with the XsltController.

(2) ResultDocument, in the case where href="", calls a new method PrincipalOutputGateway.tryToMakeReceiver(). If this returns non-null, we use this receiver rather than calling the result document resolver to get one.

(3) The implementation of PrincipalOutputGateway.tryToMakeReceiver() is: if the principalDestination registered with the XsltController (at (1) above) is a Serializer, then call its repurpose() method to get a new Serializer. Set the new serialization properties on this new Serializer, and call Serializer.getReceiver() to return the Receiver. Otherwise return null.

(4) Serializer.repurpose() is a new method that constructs a new Serializer with the same destination (StreamResult) as the original, with null serialization properties.

The effect of this in user terms is:

(a) at the command line, where output is always to a Serializer, secondary output produced with xsl:result-document href="" goes to the destination that principal output would have gone to, i.e. the destination specified by -o, or in its absence, System.out.

(b) at the s9api level, if the Destination supplied to an XsltTransformer or Xslt30Transformer is a Serializer, then secondary output produced with xsl:result-document href="" goes to the destination that principal output would have gone to.

At the moment the second Serializer is not taking any output properties from the first. We could easily change this but it's probably clearer if we don't.

I'm not comfortable that this solution treats Serializers differently from other kinds of Destination. This violates substitutability, and prevents someone, for example, writing a new Destination class that delegates to a Serializer.

Also, what is the correct behaviour of <xsl:result-document href=""/> when the primary Destination is, say, a DOMDestination or a SAXDestination? I think the effect should be uniform: reuse the primary destination, but with different parameters for serialization and validation.

This suggests that the repurpose() method (is that the best name we can find for it?) should apply to all kinds of Destination, and that the default should be to return the Destination unchanged, except for new serialization and validation parameters being supplied. (This raises obvious question marks about whether the software should ever modify a Destination object supplied by the user: but we already do, so the precedent has been set.)

I think the design can be simplified. Instead of the repurpose() method, we can simply call the Destination.getReceiver() method to get a second Receiver for the same Destination, and we can do this regardless of the kind of Destination

Note also, the code in XsltController contains remnants of a previous attempt to solve this problem using a "ReceiverFactory" class; this design was abandoned and its remnants should be deleted.

Current state - largely working with the exception of a couple of unit tests, for example in the area of saxon:next-in-chain. Some of the failures are apparently a consequence of fixing #3922.