Saxon

Thanks for reporting it. This area underwent considerable redesign in 9.9, and the case of xsl:result-document with no @href attribute was one of the hardest things to get right. It seems we are combining the serialization properties on the (empty) principal output with the properties on the xsl:result-document secondary output, and the former are taking precedence if both are explicitly specified. It's not clear that the properties of the principal output should be considered at all, let alone taking precedence: though there may be a problem here that by the time the xsl:result-document is evaluated, we can't tell which of the serialization properties on the principal output came from the stylesheet, and which came from the API or command line.

It looks as if the problem is specific to running from the command line, which would explain why we didn't catch it in testing.

The Javadoc for the Serializer class suggests that the properties held in the Serializer are those supplied explicitly by the application, and exclude properties defined in the stylesheet. However, this isn't the case when the serializer is created via the transformer, using xslt30Transformer.newSerializer() - which is what the command line code is doing. This initiallizes the serializer with properties from the unnamed output format in the stylesheet, which are subsequently treated as if they were application-supplied, and therefore take precedence over the values supplied when a secondary output destination is created.

Changing the Transform command line to use Processor.newSerializer() rather than Xslt30Transformer.newSerializer() solves this particular problem, but the change needs careful regression testing to ensure that it has no unwelcome side-effects.

Added a further fix in the setOutputProperty method in the class IdentityTransformer to ignore unknown namespaces as we saw regression in the Saxon-HE product.

While debugging I noticed a bug that turns out not to be relevant (and may be symptomless): SerializationProperties.getProperty() should call properties.getProperty() rather than properties.get(). It makes a difference when the Properties object is layered, with an under-layer providing default values.

But this isn't enough, because at the time we call result-document, the Serializer is already initialised with method="text" and that is taking precedence over the new value.

It looks like I tested the patch on the development branch and then applied it incorrectly to the 9.9 branch. On 9.9, the change from transformer.newSerializer() to processor.newSerializer() was made only in the code handling -a invocation, which is not relevant to this test case (though the same change should probably be made there too). Making the same change on the "normal" path (Transform.processFile()) solves the problem.