Saxon

saxon:transform() is pretty ancient and rather reflects the old XSLT 1.0 processing model where there is always one source document. Have you considered using the standard XSLT 3.0 fn:transform() function instead, which is much more flexible?

Of course we should fix any crash.

One word of caution about chaining transformations in this way: because you're invoking one transformation before the other has finished, it can be heavy on memory use (the internal state of the first transformation, including the source document tree, is there for the duration of the second, even if it is never going to be used again). Piping the results of one transformation to another using SAX-like events, e.g. at the s9api level using one XsltTransformer as the destination of another, is potentially more efficient.

We use the standard XSLT 3.0 fn:transform () function already as much as possible (see example 1), but this function has no parameter to directly write secondary result documents to the filestore. Such documents are accumulated in memory together with the primary output document, after which writing can only begin. This means a considerable memory consumption, especially when it concerns a large number of documents with a large volume. In these specific cases we hope to be able to use the saxon:transform () function so that the secondary output can be serialized directly to the filestore.

Thanks, that's useful feedback.

The specification of result document handling in fn:transform() was a significant challenge because the WG didn't want to define some half-baked side-effect mechanism; delegating the disposal of secondary result documents to a user-written function was a way of basically offloading the problem onto implementors, who presumably already have their own workarounds for handling calls to external functions with side effects.

Thank you for the clarifying background information. I understand that an additional parameter would not be a good solution. Hopefully we can still count on a well-functioning saxon:transform() function in the future.

Small additional question: when using the standard XSLT 3.0 fn:transform() function with the additional option source-location provided by Saxon, we notice a different behavior compared to the stylesheet-location option. The stylesheet-location option seems to use the standard URIResolver; the source-location option not. The documentation doesn't mention any different behavior. What are the rules to correctly use the source-location option?

Sorry for the delay in progressing this.

There were various paths in which the implementation of the call() method was returning null rather than an EmptySequence, which is incorrect. The documentation also needs to be updated to indicate that saxon:transform() can return an empty sequence if the stylesheet generates no principal output.

No problem for the delay. Your support is always appreciated.

The problem is back in version 11.2:

D:\Data\MyProjects\upmb\upm-batch\src\test\resources\saxon\saxon-transform>java -jar D:\Data\MyProjects\upmb\upm-batch\src\test\lib\saxon-ee-11.2.jar -xsl:xsl/batch-with-saxon.xslt -config:config/saxon-config.xml -it !method=text 
Launching remove-past-versions.xslt
	parameter file-names=ptcar region
	parameter purge-date=2019-12-01
	parameter xml-folder=D:/Data/MyProjects/upmb/upm-batch/src/test/resources/saxon/saxon-transform/xml/
java.lang.RuntimeException: Internal error evaluating function shared:transform-with-saxon at line 171 in module file:/D:/Data/MyProjects/upmb/upm-batch/src/test/resources/saxon/saxon-transform/xsl/shared-functions.xslt
	at net.sf.saxon.expr.instruct.UserFunction.call(UserFunction.java:660)
	at net.sf.saxon.expr.UserFunctionCall.callFunction(UserFunctionCall.java:555)
	at net.sf.saxon.expr.UserFunctionCall.evaluateItem(UserFunctionCall.java:487)
	at net.sf.saxon.expr.parser.Evaluator$SingleItem.evaluate(Evaluator.java:179)
	at net.sf.saxon.expr.parser.Evaluator$SingleItem.evaluate(Evaluator.java:167)
	at net.sf.saxon.expr.instruct.WithParam.getSelectValue(WithParam.java:317)
	at net.sf.saxon.expr.instruct.Instruction.assembleParams(Instruction.java:204)
	at net.sf.saxon.expr.instruct.CallTemplate.processLeavingTail(CallTemplate.java:429)
	at net.sf.saxon.expr.instruct.Block.processLeavingTail(Block.java:755)
	at net.sf.saxon.expr.instruct.NamedTemplate.expand(NamedTemplate.java:266)
	at net.sf.saxon.expr.instruct.CallTemplate$CallTemplatePackage.processLeavingTail(CallTemplate.java:561)
	at net.sf.saxon.expr.instruct.CallTemplate.process(CallTemplate.java:386)
	at net.sf.saxon.expr.instruct.CallTemplate.processLeavingTail(CallTemplate.java:446)
	at net.sf.saxon.expr.instruct.Block.processLeavingTail(Block.java:755)
	at net.sf.saxon.expr.instruct.NamedTemplate.expand(NamedTemplate.java:266)
	at net.sf.saxon.trans.XsltController.callTemplate(XsltController.java:873)
	at net.sf.saxon.s9api.Xslt30Transformer.callTemplate(Xslt30Transformer.java:483)
	at net.sf.saxon.Transform.processFile(Transform.java:1380)
	at net.sf.saxon.Transform.doTransform(Transform.java:869)
	at net.sf.saxon.Transform.main(Transform.java:81)

You seem to have introduced a configuration file that's not present in the original repro, so I'm having trouble running this.

The command line option -config:config/saxon-config.xml can even be deleted as it is not needed to reproduce the problem. We hope the solution to this problem will be available soon so that we can switch to Saxon version 11.x.