Saxon

Between 9.8 and 9.9 there has been a considerable amount of change in the interface between the transformation engine and the Serializer (or more generally, the Destination). The immediate trigger for this was the need to support the item-separator property, but this actually revealed that we were bending things very unnaturally to make raw output, and json and adaptive serialization work. The was also a very inelegant situation where the transformation recognized a Serializer and treated it differently from other kinds of Destination, which meant you couldn't wrap a Saxon Serializer in your own wrapper Destination unless it artifically subclassed Serializer.

So, it's not surprising if this method has changed between 9.8 and 9.9. We've tried hard to minimize the changes at the s9api interface level, but some changes were inevitable.

In fact, though this method in 9.9 appears to be unused within Saxon itself.

The 9.8 version of the method relied on the Serializer (at the time this method is called) knowing about the output properties declared in the stylesheet/query, as well as those set via API on the Serializer itself. There were some paths on which the Serializer was given details of these properties, but other paths where they are not supplied, so the effect was fairly unpredictable. In 9.9 the Serializer never knows about the output properties declared in the query/stylesheet, except transiently during execution of the getReceiver() method (which is now exactly the same for all kinds of Destination: all destinations are told about the output properties, and they can use any of them they want to; in particular, they can use item-separator if they perform sequence normalization).

The answer to your final question is that in 9.9 the Serializer never knows about the output properties from the stylesheet. if you need this information, you could implement a custom Destination, and it will be given the information when Destination.getReceiver() is called.

Michael Kay wrote:

The answer to your final question is that in 9.9 the Serializer never knows about the output properties from the stylesheet. if you need this information, you could implement a custom Destination, and it will be given the information when Destination.getReceiver() is called.

Thanks, I am having success that way when I have a method attribute on the xsl:result-document e.g. <xsl:result-document href="foo.xml" method="xml"><root><root></xsl:result-document>.

However, when the method is defined in an xsl:output e.g. <xsl:output name="xml1" method="xml" indent="yes"/> and the xsl:result-document references that with e.g. xsl:result-document href="result-test-format-1.xml" format="xml1" I get the method property as null although the processor correctly applies the xml method. Is there some way to have the custom Destination read out/know about the used output method if it comes from a referenced xsl:output?

As for

if you need this information, you could implement a custom Destination, and it will be given the information when Destination.getReceiver() is called

it seems on the Java side I can easily write a subclass of the Serializer class as it has a protected constructor a subclass is allowed to call and as it a public method getReceiver (http://saxonica.com/html/documentation/javadoc/net/sf/saxon/s9api/Serializer.html#getReceiver-net.sf.saxon.event.PipelineConfiguration-net.sf.saxon.serialize.SerializationProperties-) I can override in the subclass and read out any output properties coming from the stylesheet (i.e. xsl:result-document).

However, now looking at the .NET APIs now that Saxon 9.9 .NET is out, I am lost, Serializer exists there as well but has no constructor and no getReceiver method I could override.

Is there any way on .NET to "implement a custom Destination" and override getReceiver() to access the information about serialization properties when Destination.getReceiver() is called?

In 9.8 we moved towards making the Saxon.Api classes on .NET a thin wrapper over the corresponding s9api classes on Java, and this process has been largely completed in 9.9. The overall effect is to give much better consistency between the two interfaces, to reduce the amount of code we have to maintain, and to reduce the constant risk of .NET functionality falling behind.

In 9.9 a .NET XmlDestination always has an underlying "Java" Destination. It doesn't have to be written in Java, but it has to implement net.sf.saxon.s9api.Destination.

So I think the answer to your question is that to implement a custom XmlDestination in 9.9 on .NET, you have to implement its functionality as an implementation of net.sf.saxon.s9api.Destination -- most conveniently by extending AbstractDestination, or perhaps extending net.sf.saxon.s9api.Serializer -- and then make your .NET `XmlDestination a trivial wrapper over this.

You could also consider a delegation model: instead of subclassing the Saxon Serializer, delegate to it.