Updated the test to match the revised input document.

Thanks.

The intent of this test is to

"Test that all functions defined in the F+O 3.0 specification are NOT implemented in a 2.0 processor."

It expects that no "missing-function" elements will be generated.

A missing-element is generate if a function in the 'fn' namespace is _not_ available.


      <xsl:if test="if(@name/starts-with(., 'op')) then function-available(@name, @arity) else not(function-available(@name, @arity))">
            <missing-function name="{@name}" arity="{@arity}"/>
            <xsl:message expand-text="yes">*** Missing function name={@name} arity={@arity}</xsl:message>
        </xsl:if>

For the input line:

   <function name="fn:node-name" arity="0"/>

one would expect an XSLT 2.0 processor to return false for

function-available("fn:node-name", 0)

and therefore this would generate a missing-function element in the output and therefore the assertion 

     <assert>empty(/out/*)</assert>

would fail.

The input data also includes some functions which have been moved from XSLT 2.0 into F&O 3.0 (e.g. format-number).

Thanks for reopening this bug-report. I've fixed as follows:

* Added XSLT 2.0 functions (so that they can be excluded)
* Updated the autogen XSLT file (based on the spec XML)
* Fixed some other minor errors (wrong path) in all three autogen XSLT
* Changed the test to create useful XML output and changed the assertion to match it
* Changed version from 3.0 to 2.0

Running it now against Saxon in 2.0 mode shows that at least my version of Saxon supports the math functions and some newly added constructor functions from XP30.

I believe the list of functions is now comprehensive and correct, but I have not checked them one by one against all three specs (they are generated).

Was resolved > 30 days ago, closing.

This test requires an XSLT 2.0 processor to reject calls on 3.0 functions such as math:sin or fn:has-children.

I can find nothing in the XSLT 2.0 specification that requires this.

Firstly, calls such as math:sin are definitely legal. If the processor chooses to implement an extension function of this name in this namespace, there is nothing in the spec to prevent it.

I thought there might be something to prevent the processor adding extension functions in the FN namespace, but this too appears to be legal.

The spec mandates (in 3.2 Reserved namespaces) that "Reserved namespaces must not be used... in the names of stylesheet-defined objects such as variables and stylesheet functions." But there is nothing to prevent their use for extension functions. This may well be an oversight, but we're dealing here with the spec as written.

(From a practical perspective, my "XSLT 2.0" processor is actually a 3.0 processor running with certain functionality disabled. I have to decide what to disable, and I want to disable only what the 2.0 spec strictly requires me to disable. I don't think it requires me to disable these functions.)

The intent of this test is to check if a 2.0 and 3.0 processor has the "proper" set of functions. From your comment, I think there is no way to test this using the approach used in the test.

I agree that any functions inside unknown non-reserved namespaces of XSLT 2.0 or XPath 2.0 should be considered extension functions.

I remember that I have seen a restriction in XPath 2.0 (or 3.0?) where expansion of functions in the function namespace was not allowed, discussed at some point in the XSLWG with regards to the XSLT function in the XPath function namespace. However, I cannot find this back.

In XSLT 3.0 we have a provision that all possible functions *not* in the XPath reserved namespace are mapped to an error function, to allow backwards compatible processing. It's an edge case, but such backwards compatible processing may lead to different results if different implementations have differing sets of known function signatures.

That said, I think it is preferable to allow processors to have extension functions in the reserved namespaces for precisely the reason you mention in comment#6, last para.

I am not sure it makes sense to maintain this test the way it is written, though it has helped us find gaps and overlap where we accidentally marked certain functions with the wrong version attribute internally.

The stylesheet is marked as 2.0, but uses the "expand-text" attribute.

                <xsl:message expand-text="yes">*** This function should NOT be available in XSLT 2.0 processors: name={@name} arity={@arity}</xsl:message>

As discussed during F2F 2016 in Prague, fixed by removing the expand-text attribute.

Confirmed fixed.  Thanks.