[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
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|