This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The new XQuery 1.1 WD (published 15 Dec 2009) appears to have some editorial problems in the organization of sections. Section 3.1 is about Primary Expressions. Of the nine kinds of primary expression, seven are described more fully in subsections 3.1.1 to 3.1.7 (the other two, ordered and unordered expressions, are in section 3.9, which is not a problem). But section 3.1.8 describes dynamic function invocations, which are not primary expressions: placing them at this point in the spec, under the heading "Primary Expressions" is therefore misleading. Section 3.2.2 is headed "Predicates" and tries to describe both predicates as used in Axis steps, and predicates as used in filter expressions (which are not introduced until 3.3.2). But this isn't clear, because grammatically the two constructs are now quite separate (and there are semantic differences too). The inclusion of the production for FilterExpr in 3.2.2 is a red herring: this is not what the section is about. Section 3.3.2 is headed "Filter Expressions", which corresponds to the metasymbol FilterExpr. Except that it doesn't any more: the definition of "filter expression" is "A filter expression consists simply of a primary expression followed by zero or more predicates.", which is narrower than the metasymbol FilterExpr, which covers both filtering and dynamic function invocation. The syntax of these two rather separate operations is now so intertwined that it probably makes sense to cover the semantics in one place as well. In fact, the concept of "a primary expression followed by zero or more predicates" really doesn't match anything in the grammar any more. I suggest that we redefine it as being "an expression followed by a [single] predicate", and change the prose accordingly. A related problem is that 3.3.2 starts with two grammar productions (FilterExpr and PredicateList) neither of which references the other. PredicateList doesn't belong here. If we're allowed to write the grammar to match the semantics (which is what I have always done in my books), I would write it as PostfixExpr := PrimaryExpr | FilterExpr | DynamicFunctionInvocation FilterExpr := PostfixExpr '[' ExprSingle ']' DynamicFunctionInvocation := PostfixExpr "(" (ExprSingle ("," ExprSingle)*)? ")" Of course this is problematic because it has to be refactored to turn it into a grammar that can be implemented without lookahead: but it's much clearer to the human reader, and gives much better "hooks" into the prose describing the semantics. I don't know if there is a solution to this problem: perhaps we could present both grammars, assert that they are equivalent, and use the one given here as the basis for describing the semantics. (Note that the current metasymbol DynamicFunctionInvocation represents only the argument list, although the semantic description in 3.1.8 treats it as if it is a complete expression). This approach would allow the structure 3.3.2 Postfix Expressions 3.3.2.1 Filter Expressions 3.3.2.2 Dynamic Function Invocation There's always going to be a bit of messiness because predicates are used both in axis steps and in filter expressions, with slightly different semantics, but we can try harder to minimise the confusion.
After the interesting discussion at the telcon on 12 Jan 2010, I'm inclined to propose the following resolution: Introduce a new section 3.2 Postfix Expressions 3.2 Postfix Expressions [121] PostfixExpr ::= PrimaryExpr (Predicate | ArgumentList)* [123] Predicate ::= "[" Expr "]" [164] ArgumentList ::= "(" (ExprSingle ("," ExprSingle)*)? ")" {productions 121 and 164 are renamed, but otherwise unchanged) {and production 133 can become [133] FunctionCall ::= QName ArgumentList} [Definition: An expression followed by a predicate (that is, E1[E2]) is referred to as a *filter expression*: its effect is to return those items from the value of E1 that satisfy the predicate in E2.] Filter expressions are described in section 3.2.1. [Definition: An expression (other than a raw QName) followed by an argument list in parentheses (that is, E1(E2, E3, ...)) is referred to as a *dynamic function invocation*. Its effect is to evaluate E1 to obtain a function item, and then call the function represented by that function item, with E2, E3,... as arguments.] Dynamic function invocations are described in section 3.2.2. Then move the current section 3.3.2 Filter Expressions to become the new 3.2.1, and move the current 3.1.8 Dynamic Function Invocations to become the new 3.2.2. In the new 3.2.1 Filter Expressions we currently have a single paragraph of text, which should change to: <new> A filter expression consists of a base expression followed by a predicate, which is an expression written in square brackets. The result of the filter expression consists of the items returned by the base expression, filtered by applying the predicate to each item in turn. The ordering of the items returned by a filter expression is the same as their order in the result of the primary expression. </new> Then take in the following text from 3.2.2 Predicates: <moved> For each item in the input sequence, the predicate expression is evaluated using an inner focus, defined as follows: The context item is the item currently being tested against the predicate. The context size is the number of items in the input sequence. The context position is the position of the context item within the input sequence. <but-delete-this>For the purpose of evaluating the context position within a predicate, the input sequence is considered to be sorted as follows: into document order if the predicate is in a forward-axis step, into reverse document order if the predicate is in a reverse-axis step, or in its original order if the predicate is not in a step.</but-delete-this> For each item in the input sequence, the result of the predicate expression is coerced to an xs:boolean value, called the predicate truth value, as described below. Those items for which the predicate truth value is true are retained, and those for which the predicate truth value is false are discarded. The predicate truth value is derived by applying the following rules, in order: If the value of the predicate expression is a singleton atomic value of a numeric type or derived from a numeric type, the predicate truth value is true if the value of the predicate expression is equal (by the eq operator) to the context position, and is false otherwise. [Definition: A predicate whose predicate expression returns a numeric type is called a numeric predicate.] Note: In a region of a query where ordering mode is unordered, the result of a numeric predicate is nondeterministic, as explained in 3.9 Ordered and Unordered Expressions. Otherwise, the predicate truth value is the effective boolean value of the predicate expression. </moved> Retitle 3.2.2 Predicates as "Predicates within Steps". Change the introduction to refer back to 3.2.1: "A predicate within a Step has similar syntax and semantics to a predicate within a Filter Expression (see 3.2.1)." <new>The only difference is in the way the context position is set for evaluation of the predicate. <existing-text>For the purpose of evaluating the context position within a predicate, the input sequence is considered to be sorted as follows: into document order if the predicate is in a forward-axis step, into reverse document order if the predicate is in a reverse-axis step, or in its original order if the predicate is not in a step.</existing-text>