[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: xsl:script and side-effects (more XSLT 1.1 comment

Subject: RE: xsl:script and side-effects (more XSLT 1.1 comments)
From: "Evan Lenz" <elenz@xxxxxxxxxxx>
Date: Thu, 15 Feb 2001 10:54:18 -0800
element counter in xsl
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: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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.