Michael Kay <mike(_at_)saxonica(_dot_)com> 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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--