Lacking of flexibility for inserting additional XSLT steps (in between)

Regarding the batch “fragengruppe_2_evidence”, it all started about a dozen years ago with just one single XSLT stylesheet. It was called with an initial template and used fn:collection() to process the entire source folder.

Over the years, more and more requirements have been added as well as, and new E‑ConsentPro versions were released that had to be supported with the matching version of the XML content. As a result, the original XSLT stylesheet became more and more complex. In addition, some of the new requirements could no longer be sensibly implemented within a single XSLT stylesheet – for example, additional whitespace handling following a transformation performed on the original stylesheet. The simplest way to extend the existing transformation, without having to adjust anything else, was by adding another XSLT stylesheet using @saxon:next-in-chain.

Using @saxon:next-in-chain was an incredibly easy and effective solution, but it also comes with some downsides. Each XSLT stylesheet is orchestrated from the previous one. Inserting an additional stylesheet is inflexible and requires an unrelated XSLT to be changed.

Saxonica has since deprecated @saxon:next-in-chain and suggests using fn:transform() instead. While we are convinced that this function is a suitable replacement for @saxon:next-in-chain, but we have not looked into this simply due to the additional pain points as well as the requested improvements for existing pipelines.