Saxon

Legacy ID: #4942600 Legacy Poster: Vladimir Nesterovsky (vnesterovsky)

Clearly defined question helped me to find the answer myself. The code is predictably executed being in the "final output state" (http://www.w3.org/TR/xslt20/#dt-final-output-state) only. Moreover xsl:result-document must run in this state only. This exposes one more difference between templates and functions. Thanks anyway.

Legacy ID: #4942866 Legacy Poster: Michael Kay (mhkay)

1. You've answered the question about result-document. 2. <xsl:sequence select="ext:begin-document-pool-scope()"/> ... <xsl:sequence select="ext:end-document-pool-scope()"/> where ext:begin-document-pool-scope(), ext:end-document-pool-scope() are extension functions returning empty sequences; when I can rely on both functions to be executed, provided there are no dynamic errors? The answer is basically: the functions will be executed if the expression is used in a context where the result of the function will affect the contents of a final result tree. (Otherwise, it might be executed, you can't tell.) One qualification is that Saxon doesn't take the method signature into account in deciding this. It treats a method that returns void in the same way as if it returned a string that would need to be output. Michael Kay http://www.saxonica.com/

Legacy ID: #4944063 Legacy Poster: Vladimir Nesterovsky (vnesterovsky)

After checking my code base, I'm curious why saxon never reports "ERR XTDE1480", as I'm having several instances of xsl:result-document inside xsl:function. spec: The instructions in the initial template are evaluated in final output state. An instruction is evaluated in the same output state as its calling instruction, except that xsl:variable, xsl:param, xsl:with-param, xsl:attribute, xsl:comment, xsl:processing-instruction, xsl:namespace, xsl:value-of, xsl:function, xsl:key, xsl:sort, and xsl:message always evaluate the instructions in their contained sequence constructor in temporary output state. [ERR XTDE1480] It is a non-recoverable dynamic error to evaluate the xsl:result-document instruction in temporary output state.

Legacy ID: #4944219 Legacy Poster: Michael Kay (mhkay)

If you post some code then we can try to explain why Saxon is behaving as it is. Michael Kay http://www.saxonica.com/

Legacy ID: #4944249 Legacy Poster: Vladimir Nesterovsky (vnesterovsky)

Code: <xsl:template match="/"> <xsl:sequence select="t:f()"/> </xsl:template> <xsl:function name="t:f"> <xsl:result-document href="test.xml"> <test/> </xsl:result-document> </xsl:function> I understand why Saxon is behaving as it is. I'm question if it's according to the spec, as: 1. xsl:function ... always evaluate the instructions in their contained sequence constructor in temporary output state. 2. it is a non-recoverable dynamic error to evaluate the xsl:result-document instruction in temporary output state. In my opinion the fact that it works creates an impression of false safity.

Legacy ID: #4944290 Legacy Poster: Michael Kay (mhkay)

Thanks. It seems Saxon isn't setting "temporary output state" when calling a function in "push mode", which happens when the results of the function can be written directly to the current output tree - this happens typically when the function call forms the entire content of the select expression of xsl:sequence. This is fairly easy to fix. Slighly harder to fix is the fact that in Saxon-SA, this function call will be "inlined" at compile time, which means that at run-time there won't be a function call at all. To implement the spec correctly the expression tree after inlining will need to include something that changes the context to temporary output state. That will probably have to wait for a new release. Michael Kay http://www.saxonica.com/