xsl:script and side-effects

The introduction of <xsl:script> raises the possibility
that evaluating an XPATH expression may produce side-effects.
Since the XPATH and XSLT Recs are completely silent on
the issue of evaluation order -- as well they should be! --
this can lead to ambiguities.

For example, suppose you have:

    <!-- I don't know ECMAScript, hopefully a Tcl example will be clear -->
    <xsl:script implements-prefix="my" language="tcl">
    	set counter 0
	proc incrementCounter {} { global counter; return [incr counter] }
    </xsl:script>

    <xsl:template match="SOME-ELEMENT">
	<xsl:element name="COUNTER-VALUE"
	    ><xsl:value-of select="my:incrementCounter()"
	/></xsl:element>
    </xsl:template>


It seems intuitive that this will "do the right thing" --
successive <COUNTER-VALUE> elements in the result tree
will contain successive integers -- but AFAICT nothing
in the specifications actually guarantees this.

Things get even more complicated in the presence of
(what used to be called) result tree fragments.
Suppose further you have:

    <xsl:template match="/">
    	<xsl:variable name="x"
	    ><xsl:apply-templates select="//SOME-ELEMENT"
	/></xsl:variable>
	<xsl:element name="RESULT">
	    <xsl:copy-of select="$x[1]"/>
	    <xsl:copy-of select="$x[4]"/>
	</xsl:element>
    </xsl:template>

and the source document is:

    <ROOT>
    <SOME-ELEMENT/>
    <SOME-ELEMENT/>
    <SOME-ELEMENT/>
    <SOME-ELEMENT/>
    <SOME-ELEMENT/>
    </ROOT>

The output will look like:

    <RESULT>
    <COUNTER-VALUE>a</COUNTER-VALUE>
    <COUNTER-VALUE>b</COUNTER-VALUE>
    </RESULT>

but it's not at all clear what 'a' and 'b' will be.
I can think of plausible evaluation strategies which would
yield b=2, 3, 5, or 9, even in this simple case.

The XSLT Rec ought to at least mention this as an issue.

(There is a similar issue with the 'saxon:assign' extension
element, BTW.)


--Joe English

  jenglish@xxxxxxxxxxxxx

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list