Cart
|
[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: The output of evaluating an XSLT transform is the
 > On 16/04/2010 20:33, Costello, Roger L. wrote: >> In an <xsl:choose> element the first <xsl:when> element must be evaluated before the following <xsl:when> elements and the <xsl:otherwise> element, if present. >> >> <xsl:choose> >> <xsl:when test="evaluate me first"> >> ... >> </xsl:when> >> <xsl:when test="evaluate me second (if the first test failed)"> >> ... >> </xsl:when> >> </xsl:choose> >> > I don't think there is any assurance that thing swill be evaluated in that order. In particular if you use the same expression in two places in the stylesheet the system might not evaluate it twice, just use the results. XSLT2 makes it clear you can get type errors from any branch in any order, (which is why you need to use use-when rather than xsl;choose to make branching code that avoids run time errors (eg if it needs to detect processor extensions). so you need to be very precise in what you mean by evaluate. Even for dynamic run time behaviour you only have assurance that errors in later branches won't be flagged and that the results won't be used, you don;t get assurance that they won;t be executed. Note this is true even though the spec says "The content of the first, and only the first, xsl:when element that is satisfied is evaluated," as the system can do any kind of internal re-arrangement it wants of the external behaviour is the same. eg this warning in 2.9 Because different implementations may optimize execution of the stylesheet in different ways, the detection of dynamic errors is to some degree implementation-dependent. In cases where an implementation is able to produce the final result trees without evaluating a particular construct, the implementation is never required to evaluate that construct solely in order to determine whether doing so causes a dynamic error. For example, if a variable is declared but never referenced, an implementation may choose whether or not to evaluate the variable declaration, which means that if evaluating the variable declaration causes a dynamic error, some implementations will signal this error and others will not. > > > >> >> EXAMPLE #2 >> >> -- need another example -- >> >> >> EXAMPLES OF SEQUENTIAL ORDERING DUE TO LOGICAL DEPENDENCIES OF CONSTRUCTS IN THE XSLT CODE >> >> EXAMPLE #1 >> >> A variable can be used only _after_ it's been initialized, e.g., >> >> <xsl:variable name="number" select="ex:Square(4)" /> >> >> <xsl:value-of select="$number" /> >> >> The <xsl:value-of> element must be evaluated only _after_ the <xsl:variable> element has been evaluated. >> > well yes, >> >> EXAMPLE #2 >> >> In this example the sum() function must be evaluated before the multiplication occurs: >> >> <xsl:value-of select="sum(Cost) * 1.2" /> >> > Not necessarily, in general, it can start evaluating the multiplication, evaluate the right hand side (which is a literal in your example but could be more complicated) and only then evaluate the sum for the left hand argument, or perhaps the rhs evaluated to 0 so it might not bother evaluating the sum at all. > >> >> Are there other factors which cause sequential ordering of execution? >> > why do you care how the processor works internally? >> /Roger >> >> >> > David 
|
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
|
