The accepted interpretation of the spec is, I believe, that the constraint

/* xgs: reserved-function-names */

applies only to function calls, not to function declarations, and therefore it is legal for an unprefixed function declaration to use a reserved function name.

Personally I think this interpretation is open to challenge, because Appendix A.3 says normatively "The following names are not allowed as function names in an unprefixed form" without qualification; but the consensus appears to be that the constraint was only intended to apply to function calls, and if the intent had been otherwise, the contraint would have been linked from the appropriate place in the grammar.

Interesting bug reported by Nicolae and thanks Mike for the clarification. I am assigning this to Tim hoping he can comment and that we can get a ruling on this bug.

I think Mike's said it all in Comment #1.  The difference arises from the change in where the extra-grammatical constraint is applied between XQ10 and XQ30.

I'll request tis to be put on a future WG agenda.

The issue is that the same test cases expect different behavior. E.g. the tests function-decl-reserved-function-names-001 and function-decl-reserved-function-names-002 are exactly the same, testing the function name "attribute", one in XQ10 and the other in XQ30. Yet both specs have "attribute" as a reserved function name. So why do they expect different results?

--

Compare the use of the extra-grammatical constraint in the grammar appendices between the two specifications.  It applies only at FunctionCall in XQ10.

See Bug 8713.

See also bugs 8713 and 20902.

Noted during discussion today that the resolution of bug 20902 represents an official interpretation of the XQuery 1.0 specification, to the effect that the prohibition of reserved function names applies only to their use in function calls, and not to their use in function declarations.

In other words, the WG decided that these test results for XQuery 1.0 are correct. 

(Personal comment: Since XQuery 3.0 introduces an incompatible change, however, it would be understandable if a vendor decides to implement the 3.0 rules in a 1.0 processor...)

(In reply to comment #7)
> See also bugs 8713 and 20902.
> 
> Noted during discussion today that the resolution of bug 20902 represents an
> official interpretation of the XQuery 1.0 specification, to the effect that
> the prohibition of reserved function names applies only to their use in
> function calls, and not to their use in function declarations.
> 
> In other words, the WG decided that these test results for XQuery 1.0 are
> correct. 
> 
> (Personal comment: Since XQuery 3.0 introduces an incompatible change,
> however, it would be understandable if a vendor decides to implement the 3.0
> rules in a 1.0 processor...)

I have a question related to this comment: 
since the test-cases in question are marked with a dependency to "XQ10" is it correct for a XQuery implementattion submitting results for XQuery 3.0 not to run these test-cases?
Meaning that the results for these test-cases *don't* count for XQuery 3.0 conformance ?

My understanding is that for submitting results for XQuery 3.0 only test-cases marked with "XQ10+", "XQ30" and "XQ30+" should matter.

Am I missing something here?

Doesn't "XQ10" dependency stand for XQuery 1.0 test-cases that *may be* incompatible with XQuery 3.0 ?

Because this is not the case since the test-cases mentioned (although marked with "XQ10" dependency) are taken into account when generating XQuery 3.0 conformance reports.

> My understanding is that for submitting results for XQuery 3.0 only
> test-cases marked with "XQ10+", "XQ30" and "XQ30+" should matter.

This is also my understanding.
 
> Am I missing something here?
> 
> Doesn't "XQ10" dependency stand for XQuery 1.0 test-cases that *may be*
> incompatible with XQuery 3.0 ?

Yes, XQ10 tests (without the plus), I think, correspond to incompatibilities with XQuery 3.0 (as in this case).

> Because this is not the case since the test-cases mentioned (although marked
> with "XQ10" dependency) are taken into account when generating XQuery 3.0
> conformance reports.

I can also see these XQ10 tests displayed in the conformance report. Could there be a bug in the XSLT template?

When a test is marked "XQ10", then an XQuery 3.0 processor should not run this test. There will usually be an alternative test marked "XQ30": perhaps with slightly different test syntax or more usually with different result assertions.

Tests marked "XQ10+" should be run both by XQuery 1.0 processors and XQuery 3.0 processors.

(You also have the option, of course, to use this metadata to decide which processor to run, or to decide how to configure your processor prior to running the test. However, in reporting results to W3C, we expect the test submission to contain results for a single language version only.)

(In reply to comment #10)
> When a test is marked "XQ10", then an XQuery 3.0 processor should not run
> this test. There will usually be an alternative test marked "XQ30": perhaps
> with slightly different test syntax or more usually with different result
> assertions.
+1

 
> Tests marked "XQ10+" should be run both by XQuery 1.0 processors and XQuery
> 3.0 processors.
+1

> (You also have the option, of course, to use this metadata to decide which
> processor to run, or to decide how to configure your processor prior to
> running the test. However, in reporting results to W3C, we expect the test
> submission to contain results for a single language version only.)
+1
This would mean that an implementation reporting results for XQuery 3.0 should mark all test-cases with a dependency to "XQ10" as "n/a". 

However, no matter if the test-cases with a dependency on "XQ10" are marked as "fail" or "n/a", the XSL stylesheet should not take them into account when generating results for XQuery 3.0, right?

Now, it seems that there's an error in the XSL stylesheet that causes test-cases marked with "XQ10" dependency to be taken into account when generating report for XQuery 3.0 ...

This is now a bug against the reporting stylesheet.

(In reply to comment #12)

Yes indeed it is a bug in the reporting stylesheet. I have now committed the bug fix to cvs.