This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I'm having some second thoughts about this error: [ERR XTDE1480] It is a non-recoverable dynamic error to evaluate the xsl:result-document instruction in temporary output state. The ability to easily access result trees is going to make it very tempting to deal with some sorts of customizations by simply putting all the "normal" results in a variable and then transforming that variable. (Think next-match or apply-imports.) But XTDE1480 means that if any "normal" result constructs an output document along the way (as the DocBook stylesheets can for "long descriptions" of figures and tables per the WAI guidelines), then that technique is going to fail. In fact, for the current DocBook stylesheets it's even worse than that since the body of a figure or table is passed as a parameter right now and so fails even in the simplest case. I appreciate that result documents created in a variable or other temporary context might be unpredictable but I would much prefer that unpredictability to what we have today. The workaround (and I will have to workaround this problem) will be to put all the result-document content in the primary result tree (wrapped in <magic:wraper> elements or something) and then post process the result to write them out. In other words, it will force me to always process every tree twice. That's going to be potentially expensive.
I'm sympathetic to the reuqirement, but I think we need to find a way to do it cleanly. There are three possible problems if we simply remove the restriction: (a) the processor might decide that it doesn't need to evaluate the variable, and the result document then won't be written out. (b) the processor might decide to evaluate the variable more than once, and the xsl:result-document instruction will then fail saying two output files with the same URI have been written (c) the processor might decide that it only needs to evaluate the variable partially, for example it might avoid evaluating a subtree that is never accessed. As with (a) this may cause the result document not to be written, but in ways that the user will find very hard to debug. I think a potential solution is to add an attribute writes-result-document="yes|no" to xsl:variable. If the value is yes, then the processor is constrained to evaluate the variable as if it were itself a final result tree (that is, to evaluate it in final output mode), and then assign this "final result tree" to the variable; it's also constrained to only evaluate the variable once. It may be tricky to formalize the semantics of this, but it sounds like a feasible hack. Michael Kay
The working group spent some time looking for a solution to this usability problem, and failed to come up with a mechanism that didn't compromise the side-effect-free nature of the language. The problem is therefore closed with the resolution WONTFIX.