RE: [xsl] xsl:script and side-effects (more XSLT 1.1 comments)

Subject: RE: [xsl] xsl:script and side-effects (more XSLT 1.1 comments)
From: "Evan Lenz" <elenz@xxxxxxxxxxx>
Date: Thu, 15 Feb 2001 10:54:18 -0800
This is exactly the understanding that most people have of xsl:script--that
it provides new functionality. While they are wrong, I think this reinforces
the fact that xsl:script is and will continue to be misunderstood. It does
not look like an extension, and despite the insistence that xsl:script does
not encourage the inclusion of procedural code, it implicitly and undeniably
does. As I said before, the mechanisms are already there for people to hang
themselves on assignment statements; xsl:script just pushes them over the

Evan Lenz
XYZFind Corp.

-----Original Message-----
From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx
[mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx]On Behalf Of Joe English
Sent: Thursday, February 15, 2001 8:51 AM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: [xsl] 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: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:

 XSL-List info and archive:

Current Thread