Transferred from internal mailing list:

http://lists.w3.org/Archives/Member/w3c-xsl-wg/2006Aug/0032.html

See also test backwards025.

This test was designed against section J.1.3 rule 6, which states:

"6. It is normally a static error if an XPath expression contains a call to
an unknown function. But when backwards compatible behavior is enabled, this
is a non-recoverable dynamic error, which occurs only if the function call
is actually evaluated."

However, appendix J.1.3 is intended to be a non-normative summary of rules
that appear normatively elsewhere in the specification, and this rule does not appear anywhere else.

The WG considered this on 17 Aug 2006 and decided to make the non-normative rule normative, on the basis that in backwards compatibility mode, we should preserve 1.0 behaviour wherever possible (and there are in fact many stylesheets that rely on this behaviour).

To implement this:

(a) in 3.8, at the end of the paragraph that reads "If an attribute containing an XPath expression is processed with backwards-compatible behavior, then the expression is evaluated with XPath 1.0 compatibility mode set to true. For details of this mode, see Section 2.1.1 Static ContextXP.", add "Furthermore, in such an expression any function call for which no implementation is available (unless it uses the *standard function namespace*) is bound to an error function whose effect when evaluated is to raise a dynamic error (see ERRxxxx). The effect is that with backwards-compatible behavior enabled, calls on *extension functions* that are not available in a particular implementation do not cause an error unless the function call is actually evaluated. For further details, see [Extension Functions]."

(b) add the Note: This might appear to contradict the specification of XPath 2.0, which states that a static error (XPST0017) is raised when an expression contains a call to a function that is not present (with matching name and arity) in the static context. This apparent contradiction is resolved by specifying that the XSLT processor constructs a static context for the expression in which every possible function name and arity (other than names in the *standard function namespace*) is present; when no other implementation of the function is available, the function call is bound to a fallback error function whose run-time effect is to raise a dynamic error.

(c) In section 18.1.1 (Testing Availability of Functions) add before the Notes:

When *backwards compatible behavior* is enabled, the function-available function returns false in respect of a function name and arity for which the only implementation available is the fallback error function that raises a dynamic error whenever it is called. This means that it is possible (as in XSLT 1.0) to use logic such as the following example to test whether a function is available before calling it:

<summary xsl:version="1.0">
  <xsl:choose>
    <xsl:when test="function-available('my:summary')">
      <xsl:value-of select="my:summary()"/>
    </xsl:when>
    <xsl:otherwise>
      <xsl:text>Summary not available</xsl:text>
    </xsl:otherwise>
  </xsl:choose>
</summary>

(d) Make minor editorial changes to the second Note in 18.1.1, as required.

(e) In 18.1.2 (Calling Extension Functions), add a new error code (after the existing error paragraph). 

[ERR XTDE1425] When backwards-compatible behavior is enabled, it is a non-recoverable dynamic error to evaluate an extension function call if no implementation of the extension function is available.

Note: when backwards-compatible behavior is not enabled, this is a static error (see XPST0017).