21568 2013-04-03 14:03:50 +0000 Incorrect expected result for FOTS tests function-decl-reserved-function-names-001,function-decl-reserved-function-names-003,... 2013-06-12 15:03:00 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3 & XPath 3 Test Suite Working drafts PC Windows NT RESOLVED FIXED P2 normal --- 1 nbrinza oneil g jmdyck mike spungi public-qt-comments oldest_to_newest 85495 0 nbrinza 2013-04-03 14:03:50 +0000 A number of tests in the FOTS testsuite in the prod-FunctionDecl set have incorrect results. E.g. the function-decl-reserved-function-names-001: declare default function namespace "http://www.w3.org/2005/xquery-local-functions"; declare function attribute() { fn:true()}; local:attribute() expects the result "true()", i.e. it considers the query to be syntactically correct with respect to the XQuery 1.0 specification. Yet the XQuery 1.0 specification, just as 3.0, has a list of reserved function names: http://www.w3.org/TR/xquery/#id-reserved-fn-names , and "attribute" is among them. The lists of tests that have this problem is: function-decl-reserved-function-names-001 function-decl-reserved-function-names-003 function-decl-reserved-function-names-005 function-decl-reserved-function-names-007 function-decl-reserved-function-names-009 function-decl-reserved-function-names-013 function-decl-reserved-function-names-015 function-decl-reserved-function-names-019 function-decl-reserved-function-names-021 function-decl-reserved-function-names-023 function-decl-reserved-function-names-025 function-decl-reserved-function-names-029 function-decl-reserved-function-names-031 85505 1 mike 2013-04-03 15:41:00 +0000 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. 87107 2 oneil 2013-05-01 14:32:48 +0000 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. 87117 3 tim 2013-05-01 18:44:23 +0000 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. 87118 4 nbrinza 2013-05-01 19:03:18 +0000 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? -- 87126 5 tim 2013-05-01 21:26:41 +0000 Compare the use of the extra-grammatical constraint in the grammar appendices between the two specifications. It applies only at FunctionCall in XQ10. 87352 6 jmdyck 2013-05-07 16:21:42 +0000 See Bug 8713. 87363 7 mike 2013-05-07 17:47:21 +0000 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...) 87394 8 spungi 2013-05-07 23:45:54 +0000 (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. 87408 9 g 2013-05-08 07:43:33 +0000 > 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? 87411 10 mike 2013-05-08 08:35:07 +0000 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.) 87413 11 spungi 2013-05-08 08:46:40 +0000 (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 ... 87665 12 mike 2013-05-14 16:53:11 +0000 This is now a bug against the reporting stylesheet. 89165 13 oneil 2013-06-12 15:03:00 +0000 (In reply to comment #12) Yes indeed it is a bug in the reporting stylesheet. I have now committed the bug fix to cvs.