This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 3.11.3.1 contains the text If the context item is an array, the UnaryLookup operator is equivalent to the following expression: for $k in 1 to array:size(.) return .($k) This is true only for the wildcard form of the operator, but that is covered later in the section. I believe that the previous statement If the context item is a map, the UnaryLookup operator is equivalent to the following expression: for $k in KS return .($k) is true also when the context item is an array. Using nested lists to make clear the scope of the conditionals in this section would make it much clearer. I would be inclined to structure it as follows, even though this involves duplication: 1. If the context item is a map: 1.1 If KeySpecifier is an NCName: 1.2 If KeySpecifier is an IntegerLiteral: 1.3 If KeySpecifier is a ParenthesizedExpr: 1.4 If KeySpecifier is a wildcard ("*") 2. If the context item is an array: 2.1 If KeySpecifier is an NCName: (always an error) 2.2 If KeySpecifier is an IntegerLiteral: 2.3 If KeySpecifier is a ParenthesizedExpr: 2.4 If KeySpecifier is a wildcard ("*"): 3. Otherwise (error)
In 3.11.13.2 we read The semantics of E?S are equivalent to for $a in E, $b in S return $a($b) , where E is an expression on the left of the postfix ? operator and ?S is the unary lookup operator described in 3.11.3.1 Unary Lookup. This doesn't work. "?S" isn't a unary lookup operator. I think this should be The semantics of E?S are equivalent to for $a in E return $a ! ?S where ?S uses the unary lookup operator described in 3.11.3.1 Unary Lookup
Note also, I believe that if $A is an array, then $A?* has the same result as array:flatten($A); it would be useful to point out this relationship, or even to use it as the normative specification of $A?*
(In reply to Michael Kay from comment #0) > Using nested lists to make clear the scope of the conditionals in this > section would make it much clearer. I would be inclined to structure it as > follows, even though this involves duplication: > > 1. If the context item is a map: > 1.1 If KeySpecifier is an NCName: > 1.2 If KeySpecifier is an IntegerLiteral: > 1.3 If KeySpecifier is a ParenthesizedExpr: > 1.4 If KeySpecifier is a wildcard ("*") > 2. If the context item is an array: > 2.1 If KeySpecifier is an NCName: (always an error) > 2.2 If KeySpecifier is an IntegerLiteral: > 2.3 If KeySpecifier is a ParenthesizedExpr: > 2.4 If KeySpecifier is a wildcard ("*"): > 3. Otherwise (error) That's the approach I took.