This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Biro D. Botond (botond23@gmail.com) raised the following on public-qt-comments: Is it expected to evaluate the keyspecifier with a new inner focus? From semantic equivalance of E?S and E ! ?S one would expect so – in this case I suggest to mention the postfix lookup in the context changing expressions in 2.1.2 Dynamic context – context item definition. MHK comment: It appears that the current specification for the binary lookup operator does cause S to be evaluated with a focus based on E. It's not clear that this is what we intended, and it's not clear that it has any benefits. On the contrary, it seems to bring back some of the known pitfalls of the focus change in ordinary predicates. For example, one might expect that <xsl:for-each select="1 to 5"> <xsl:copy-of select="$array?(.+1)"/> </xsl:for-each> does the same as <xsl:for-each select="1 to 5"> <xsl:copy-of select="$array(.+1)"/> </xsl:for-each> but as currently specified, this is not the case; it actually raises a type error because "." is bound to the array. Unfortunately, changing this makes it difficult to define binary-? in terms of unary-?. A better approach might be to define the unary expression ?X as equivalent to .?X, and to define $A?(E) as equivalent to for $a in $A, $e in $E return $a($e) provided that $a is a map or array (else type error).
In today's call we agreed to change the description to: for $a in E, $b in S return $a($b) If $a is not a map or array, a type error is raised.
The revised description is inadequate. Consider $emps?fred This is not equivalent to for $e in $emps, $f in fred return $e($f) Rather, it is equivalent to for $e in $emps, $f in "fred" return $e($f) The equivalence also does not work for wildcards ($emps?*). I suggest the following: <quote> The semantics of a Postfix Lookup expression depend on the form of the KeySpecifier, as follows: * If the KeySpecifier is an NCName, IntegerLiteral, or Wildcard ("*"), then the expression E?S is equivalent to E!?S. (That is, the semantics of the postfix lookup operator are defined in terms of the unary lookup operator). * If the KeySpecifier is a ParenthesizedExpr, then the expression E?(S) is equivalent to for $e in E, $s in S return $e($s) Note: the focus for evaluating S is the same as the focus for the PostfixLookup expression itself. </quote>
I agree with Comment 2 but I assume this needs to go back to the WG. Note, editorial bug 27715 can likely close with this bug.
I put this in the spec, with a change log note stating that this change is not yet approved. Leaving reopened, discuss at the face-to-face.
*** Bug 27715 has been marked as a duplicate of this bug. ***
The WG accepted the solution in the current text.