27536 2014-12-08 16:14:15 +0000 [XP31] Focus for evaluation of keyspecifier in lookup 2015-07-16 14:28:30 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XPath 3.1 Last Call drafts PC All RESOLVED FIXED P2 normal --- 1 mike jonathan.robie jmdyck josh.spiegel public-qt-comments oldest_to_newest 116014 0 mike 2014-12-08 16:14:15 +0000 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). 116068 1 jonathan.robie 2014-12-09 20:29:37 +0000 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. 121775 2 mike 2015-07-06 08:53:36 +0000 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> 121869 3 josh.spiegel 2015-07-08 11:48:04 +0000 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. 122003 4 jonathan.robie 2015-07-13 21:37:54 +0000 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. 122041 5 jonathan.robie 2015-07-14 19:53:33 +0000 *** Bug 27715 has been marked as a duplicate of this bug. *** 122145 6 jonathan.robie 2015-07-16 14:28:30 +0000 The WG accepted the solution in the current text.