[xsl] xsl:script and side-effects

Subject: [xsl] xsl:script and side-effects
From: Joe English <jenglish@xxxxxxxxxxxxx>
Date: Thu, 15 Feb 2001 08:50:55 -0800
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:template match="SOME-ELEMENT">
	<xsl:element name="COUNTER-VALUE"
	    ><xsl:value-of select="my:incrementCounter()"

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:element name="RESULT">
	    <xsl:copy-of select="$x[1]"/>
	    <xsl:copy-of select="$x[4]"/>

and the source document is:


The output will look like:


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


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

Current Thread