This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 20843 - [XT3TS] function-1902
Summary: [XT3TS] function-1902
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 Test Suite (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Abel Braaksma
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2013-02-01 11:09 UTC by Tim Mills
Modified: 2016-02-18 13:49 UTC (History)
2 users (show)

See Also:


Description Tim Mills 2013-02-01 11:09:10 UTC
This test looks up function names, such as fn:nilled, but 'fn' is not an in-scope namespace prefix.
Comment 1 Michael Kay 2013-02-04 22:52:56 UTC
Updated the test to match the revised input document.
Comment 2 Tim Mills 2013-02-05 16:59:55 UTC
Comment 3 Tim Mills 2015-03-23 16:07:36 UTC
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>

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 


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).
Comment 4 Abel Braaksma 2015-03-31 01:28:01 UTC
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).
Comment 5 Abel Braaksma 2015-05-06 21:21:49 UTC
Was resolved > 30 days ago, closing.
Comment 6 Michael Kay 2015-07-30 19:16:51 UTC
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.)
Comment 7 Abel Braaksma 2015-08-06 00:15:36 UTC
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.
Comment 8 Tim Mills 2015-10-22 14:34:21 UTC
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>
Comment 9 Abel Braaksma 2016-02-16 13:58:02 UTC
As discussed during F2F 2016 in Prague, fixed by removing the expand-text attribute.
Comment 10 Tim Mills 2016-02-18 13:49:37 UTC
Confirmed fixed.  Thanks.