Re: [xsl] Saxon bug in short-circuiting of expressions?

["Michael(tm) Smith" <smith@xxxxxxxxxxxxxxxxxx>]

Michael Kay <mike@xxxxxxxxxxxx> writes:

> Which version of Saxon are you using? The XSLT 2.0 spec differs from XSLT
> 1.0 in this area.

Saxon 6.5.5. (Sorry, I should have mentioned that when I posted.)

> Either way, the "forwards-compatible processing" section of the XSLT 1.0
> spec makes no difference. Your stylesheet is using version="1.0" so
> forwards-compatible processing is not enabled. 

OK

> The relevant provision is in fact XSLT 1.0 section 14.2, which says:
> 
> If the XSLT processor does not have an implementation of an extension
> function of a particular name available, then the function-available
> function must return false for that name. If such an extension function
> occurs in an expression and the extension function is actually called, the
> XSLT processor must signal an error. An XSLT processor must not signal an
> error merely because an expression contains an extension function for which
> no implementation is available.

OK, but I'd think that the section of the XPath spec that says
"The right operand is not evaluated if the left operand evaluates
to false" should result in the hoge() function in the right
operand of the "function-available('hoge') and hoge()" expression
never actually getting called.

> A decision was made to change this rule for XSLT 2.0, which introduces
> compile-time conditionals in the form of the use-when attribute. You can now
> write:
> 
> <xsl:template match="/">
>     <xsl:if use-when="function-available('hoge')"
> test="hoge()">moge</xsl:if>
> </xsl:template>
> 
> If you want to write code that works under both 1.0, and 2.0, use
> version="2.0" in your xsl:stylesheet element, and write:
> 
> <xsl:template match="/">
>     <xsl:if use-when="function-available('hoge')" 
>             test="function-available('hoge') and hoge()">moge</xsl:if>
> </xsl:template>

OK. I was actually concerned not just about how to get this
particular stylesheet to be processed by Saxon, but more about how
this to handle this from an implementation point of view --
whether the Saxon behavior of evaluating the right operand in the
expression in this case is correct and so how my implementation
should also handle it.

> The reason for the change is that XSLT has generally moved to be a stricter
> programming language with stronger error detection and reporting, and less
> of an interpretive scripting language.
> 
> There's also another independent change in XPath 2.0, which is that the
> order of evaluation of the operands of "and" and "or" is no longer
> well-defined, except in backwards compatibility mode. This is to allow
> database products to exploit indexing, for example if you write
> //customer[age>60 and id='123456'] then an index on "id" can be used.

Nice. There's a whole lot I still need to learn about XSLT 2.0.

  --Mike