1

We installed and ran XSpec and configured it to point to our stylesheet resulting in an error:

[ERROR] Cannot execute xsl:result-document while evaluating xsl:variable; SystemID: file:/Users/a/xspec/ce.xslt; Line#: 76; Column#: 114 net.sf.saxon.trans.XPathException: Cannot execute xsl:result-document while evaluating xsl:variable

A similar error has been found by user:wasmachien and a question was raised on xsl:result-document instruction throws error when invoking stylesheet with Calabash

The solution to the error was not given, but it pointed to:

the error was thrown by the XSpec test runner that preceded the transformation step in the pipeline (and tried to wrap the result in a variable!)

We would be helped if we know how to avoid that behaviour.

Edgar Schouten
  • 23
  • 3
  • Is `ce.xslt` your code or XSpec code? Can you show the relevant lines, i.e. at least the template or function containing line 76? – Martin Honnen Nov 20 '20 at 16:47

3 Answers3

1

XSLT is a functional language, so evaluating a variable isn't supposed to have side-effects like creating an output file. The error message means that you're trying to cause such a side-effect. This would be bad news because side-effects prevent many optimisations, so the XSLT spec bans this.

Of course I can see why this is a nuisance. If you have some code that's doing a transformation then you want to be able to capture the result of the code in a variable. But the whole point is that if the code has side-effects, then you can't encapsulate it in this way: in effect, the code is actually producing multiple results.

I don't know whether anyone has worked on making XSpec able to run XSLT transformations using fn:transform(). That would be an ideal solution, because fn:transform allows the target transformation to produce multiple results using xsl:result-document, and it captures all the result documents using a map.

Michael Kay
  • 156,231
  • 11
  • 92
  • 164
  • 1
    The latest XSpec has an experimental feature where it invokes the tested stylesheet using `fn:transform()`. Unfortunately this feature doesn't seem to work when the tested stylesheet uses `xsl:result-document`. Saxon is terminated, saying `java.lang.IllegalStateException: The result sequence has not yet been closed`. Is `xsl:result-document` not allowed to be used when its stylesheet is invoked using `fn:transform()` within `xsl:result-document`? (The new feature calls `fn:transform()` still within `xsl:result-document`.) – AirQuick Nov 21 '20 at 23:21
  • In principle Saxon does allow a stylesheet invoked using fn:transform() to use xsl:result-document, though you may have to choose the right options in fn:transform() for how the result documents are delivered. Try to construct a simple example that demonstrates a failure and raise it as a separate question. – Michael Kay Nov 21 '20 at 23:40
  • 1
    Actually, the IllegalStateException could be a bug, so it would certainly be good to see the conditions that trigger it. – Michael Kay Nov 21 '20 at 23:42
  • 1
    I'll open an issue after narrowing down a repro. – AirQuick Nov 21 '20 at 23:55
  • 1
    Thanks: for reference, https://saxonica.plan.io/issues/4835 – Michael Kay Nov 22 '20 at 00:30
  • 1
    Fix verified on Saxon-HE 10.5. – AirQuick Apr 14 '21 at 16:12
0

Ultimately, the problem here is that XSpec attempts to capture the output of the transformation in a variable so that it can compare the results against what's expected. But you can't have an xsl:result-document in a variable for the reasons Mike describes.

Without an XSpec rewrite to avoid this, you have to twist your stylesheet so that it doesn't attempt to use xsl:result-document within the templates that are being tested (or when they're being tested).

There's some magic along these lines in the tests for https://github.com/docbook/xslTNG/

Norm
  • 866
  • 1
  • 7
  • 16
0

As answered by the others, that is an inherent limitation of the current XSpec implementation. You have to tweak your stylesheet to make it testable.

"High-Level File Structure to Enable Substitution" and "Case 1: Creating Result Documents" in galtm's paper might give you some hint. It's based on Saxon-JS, but many of its strategies are applicable to Saxon Java.

AirQuick
  • 61
  • 3