This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I believe that error XQST0134 should also be acceptable for the following test in test set prod-FunctionCall: <test-case name="function-call-reserved-function-names-018"> <description>Check that reserved function name namespace-node is handled correctly. </description> <created by="Tim Mills" on="2013-01-24"/> <dependency type="spec" value="XQ30+"/> <test> declare default function namespace "http://www.w3.org/2005/xquery-local-functions"; declare function local:namespace-node($arg) { fn:true() }; namespace-node(1) </test> <result> <error code="XPST0003" /> </result> </test-case>
The test of XQ31 says "If the axis name is omitted from an axis step, the default axis is child, with two exceptions: (1) if the NodeTest in an axis step contains an AttributeTest or SchemaAttributeTest then the default axis is attribute; (2) if the NodeTest in an axis step is a NamespaceNodeTest then a static error is raised [err:XQST0134]." Unless I'm mistaken, this test doesn't use a NamespaceNodeTest, so I'm not sure why XQST0134 would be expected.
It's legitimate for an XPath parser to decide that the only thing namespace-node( can possibly be is the beginning of a NamespaceNodeTest, and then to report an error either because a namespace node test can't have an integer between the parens, or because a namespace node test is not allowed in the particular circumstances, e.g. when running XPath 2.0 or XQuery 3.0.
I'm afraid I don't agree. I think you have to perform the look-ahead to differentiate between namespace-node() and namespace-node(1). From your argument, it would seem that you would permit XQST0134 for a syntactically incorrect query such as namespace-node(! One for the WG I suspect.
I don't think there's anything in the spec that says you have to have a syntactically valid parse before you can raise a "semantic" error. For example, as soon as I've read "x:something(" then I know this can only legitimately be the start of a function call, so I'm allowed to check whether "x" is an in-scope prefix before checking that what follows is a syntactically-legitimate continuation of the function call. The spec says "If more than one error is present, or if an error condition comes within the scope of more than one error defined in this specification, then any non-empty subset of these errors may be reported." We very deliberately give implementations freedom in terms of the order of processing when doing static analysis. Here there are (on some interpretation) two errors, a spurious "1" between the parens of a namespace-node test, and use of a namespace-node test in a version of the language where it isn't allowed, and the processor is allowed to report either or both of those.
I take your point, but I'm afraid I can't agree that this test uses a NamespaceNodeTest. At best XQST0134 is confusing, and at worst it is wrong. Perhaps it should be discussed in the WG, but if not, I'll leave it to you to change the expected results.
I think XPST0003 is the correct result and I am not sure about the justification of XQST0134. But since both are static errors and the argument in Comment 4 is at least plausible, I don't think there is much harm allowing both.
I would argue for the widest possible interpretation of the rules here. If a user writes the query processing=instruction() there are two possible interpretations: (a) they are doing a comparison between an element called "processing" and the result of a non-existent function called "instruction" (b) they have mistyped "-" as "=" A processor that reports (b) has probably guessed correctly what the real problem is, and we should certainly not require it to report the error as (a). A well-designed processor reports static errors that correctly guess what the user did wrong. If we encountered namespace-node(1) in a real query, my guess would be that the user has made two errors: they have used namespace-node in a dialect of the language where it isn't allowed, and they have given it a parameter that it doesn't accept. In an ideal world I would want to report both of those errors. The first one is more useful to report, because if they correct the second they still won't have a valid query. The spec allows me, however, to report any subset. I don't think we should be making a hard-and-fast distinction here between syntax errors and semantic errors. From a user perspective, the fact that text(3) is a syntax error while position(3) is a semantic error is not a meaningful distinction: we drew the boundary for our convenience, not for the user's benefit.
I have made the fix of adding the error code XQST0134 to the test case as suggested in comment #0. Please reopen if anyone objects.