- From: <bugzilla@jessica.w3.org>
- Date: Thu, 03 Nov 2016 17:40:20 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29482 --- Comment #5 from Michael Kay <mike@saxonica.com> --- The definition of higher-order operand is effectively: [An operand O of a construct C is higher-order if the semantics of C potentially require O to be evaluated more than once during a single evaluation of C.] More specifically, O is a higher-order operand of C if any of the following conditions is true: (1) The context item for evaluation of O is different from the context item for evaluation of C. (2) C is an instruction and O is a pattern (as with the from and count attributes of xsl:number, and the group-starting-with and group-ending-with attributes of xsl:for-each-group). (3) C is an XPath for, some, or every expression and O is the expression in its return or satisfies clause. (4) C is an inline function declaration and O is the expression in its body. I think the "]" here is misplaced (we used to have markup restrictions that prevented multi-paragraph definitions). The real test as to whether something is higher order is the conditions (1) to (4). In this example, the body of xsl:copy satisfies condition (1) even though it is only evaluated once. So if we want to make this example streamable then we have to change the rules, and the question is how we should change them. I think my preference is NOT to make this guaranteed streamable: (a) it complicates the spec; (b) complicates my implementation; (c) I think it's not easy to convince ourselves that we aren't opening up lots of unintended consequences if we make a change here. As regards the examples in comment #4, my reading of the spec is that the "more specifically" rules take precedence; the rule "C is an XPath for, some, or every expression and O is the expression in its return or satisfies clause." applies whether or not the controlling expression can actually deliver multiple items. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 3 November 2016 17:40:27 UTC