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

["Evan Lenz" <elenz@xxxxxxxxxxx>]

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
ledge.

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: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


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