This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
A co-worker pointed out that section A.4 of XPath 2.0[1] (and equally, of XQuery 1.0) states that "operators are summarized here to make clear the order of their precedence from lowest to highest. Operators that have a lower precedence number cannot be contained by operators with a higher precedence number." The table that follows that statement has entries for the various operators, including binary plus and minus, with a precedence of eight, and parentheses, square brackets and brace brackets, with a precedence of nineteen. Because parentheses have a higher precedence number than binary plus, the only conclusion seems to be that a plus operator cannot be contained in parentheses. Clearly that's false, and some special treatment is needed. Perhaps the third sentence of the first paragraph could be reworded to say "Operators that have a lower precedence number cannot be contained by operators with a higher precedence number, except that any operator can be contained in parentheses, brace brackets and square brackets, and an operator can contain an expression in parentheses, brace brackets or square brackets that contains another operator with lower precedence number than the operator," where the two occurrences of ", brace brackets" only apply to XQuery. (Of course these statements about operators containing operators really should be speaking of expressions containing operators or expressions whose operands contain particular operators, but I didn't want to go too far with the proposed rewording.) Note also that braces appear in the table for XPath, but exist only in XQuery. [1] http://www.w3.org/TR/xpath20/#id-precedence-order
Or we could just remove the "[], (), {}" row from the table.
Well, square brackets are a kind of operator, in that e1[e2] performs an operation, and it's important to know that it binds more tightly than "/", so that e1/e2[e3] means e1/e2[e3] and not (e1/e2)[e3]. By contrast, () and {} are not operators, and really don't belong in this table. But if we really want to spell it out, e1[e2] has a bracketing function as well as being an operator in its own right. Other compound operators such as if/then/else aren't even present in the table. And the sentence "Operators that have a lower precedence number cannot be contained by operators with a higher precedence number." is certainly pretty clumsy (I'd go so far as to say it is meaningless). While still informal, I think it would be much better to say "Unless parentheses are used to change the order of evaluation, operators with a high precedence number are evaluated before operators with a lower precedence number".
I was asked at the XSL WG meeting on 5 Feb to produce a wording proposal to resolve this. Proposal: For XPath and XQuery Appendix A.4: (1) delete the sentence "Operators that have a lower precedence number cannot be contained by operators with a higher precedence number." (2) from the row labelled 19, delete the round and curly braces. (3) Add after the table: "Note: parentheses can be used to override the operator precedence in the usual way. Square brackets in an expression such as A[B] serve two roles: they act as an operator causing B to be evaluated once for each item in the value of A, and they act as parentheses enclosing the expression B. <XQuery-only>Curly braces in an expression such as validate{E} or ordered{E} perform a similar bracketing role to the parentheses in a function call, but with the difference in most cases that E is an Expr rather than ExprSingle, meaning that it can use the comma operator.</XQuery-only>
The WG accepted this today at the face-to-face, I will add it to the XQuery and XPath 2ed.