Saxon

Also, I discovered that if you add a template like this into the stylesheet, then it also returns the expected result:

  <xsl:template match="/">
    <xsl:result-document>
      <xsl:apply-templates/>
    </xsl:result-document>
  </xsl:template>

Thanks for reporting.

There's some complex logic here designed to enforce the XSLT 2.0 rule: (section 2.4):

An implicit result tree is also created when the result sequence is empty, provided that no xsl:result-document instruction has been evaluated during the course of the transformation. In this situation the implicit result tree will consist of a document node with no children.

This means that the processor handles the principal output differently depending on whether or not there has been a secondary output; if there has, then an empty principal output is discarded (the destination file is not overwritten), but if not, then the principal output file is overwritten whether or not the result is empty.

Now in this case the principal output isn't empty, so this rule shouldn't matter; and in any case you're using an XSLT 3.0 API where the rules are different. But somewhere in here lies the explanation.

We're generating an output pipeline containing an ImplicitResultChecker followed by a SequenceOutputter. The first output to the ImplicitResultChecker is a startElement() event, and the code at ImplicitResultChecker line 104 is generating a startDocument() event. This is apparently a legacy of the fact that in 2.0 the result of a transformation must always be a document node. No corresponding endDocument() event is fired when the transformation completes, with the result that the SequenceOutputter doesn't know things have finished, and doesn't complete getting the constructed output element from its treeBuilder into its result list. The result list is therefore empty when the Controller assembles the transformation result.

The code here is all very delicate, changing anything has a high risk of breaking some other path.

I think the most robust way forward is to avoid creating the ImplicitResultChecker on this path (it's only created if the stylesheet is capable of creating secondary result documents, and we know that the code works if that isn't the case).

Creating the ImplicitResultChecker only if the variable buildTree is set (that is, if the raw result sequence of the transformation is to undergo sequence normalization as defined in the serialization spec) seems to do the trick: on this path, buildTree is false because the application is asking for the result to be delivered as an XdmValue. (Change is in Controller line 2603).

After this change I'm seeing some unit test failure in the s9apitest package. I suspect these are not related to this specific patch but I will investigate before committing the change.