This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This applies to 19.8.4.21 Streamability of xsl:iterate (http://www.w3.org/TR/xslt-30/#streamability-xsl-iterate). Item 1.d seems to be irrelevant to a grounded posture of the select expression. If it is grounded, so is the select expression in xsl:on-completion. I think this section belongs under the "otherwise" part under item 2. Under 2. Otherwise, there is no mention of xsl:on-completion. But see my previous paragraph. Under 2.b, the text says "the wider of the sweeps of the two operands". But it doesn't say which two operands these are (the seqtor and xsl:on-completion?).
We discussed this in Prague. The on-completion expression has no focus, so it cannot refer to the context -- unless it is lexically within a for-each-group and refers to the current group and/or the current group key. It would be easy enough to specify that references to the current group (and key?) should be impossible within on-completion, just as we do for references to the context item. Note that clause 1.c appears both here and in for-each. It seemed that it might possibly be unnecessary, but on consideration we decided to keep it for generality (i.e. 'just in case'). (Also, if we omitted it, the analysis would never hit xsl:break.) We do need to cover on-completion in rule 2 -- also parameters. In 2.b, the operands do need to be identified (and the number corrected). Should this use the GSR instead of having its own rules? On-completion requires special rules; perhaps a rule of the form "If there is an on-completion, then ... otherwise the GSR applies".
Created attachment 1451 [details] Revised proposal
Sorry, the attachment was attached to the wrong bug (as a result of Bugzilla's irritating habit of moving on to the next bug after you've entered a comment).
I believe rule 1 (for a grounded select expression) is correct. The on-completion construct will normally be grounded, but not inevitably. It can contain a call to current-group(), in which case it will be roaming/free-ranging. It can also (now) contain a reference to a parameter of a containing streamable stylesheet function: <xsl:function name="f" streamable="yes"> <xsl:param name="n"/> <xsl:iterate select="1 to 10"> <xsl:on-completion select="data($n)"/> </xsl:iterate> </xsl:function> So we can't simply ignore the on-completion construct. Rule 2 (for a non-grounded select expression) does need improvement. I think it's simplest to insist for this case that the initializers of any xsl:param children and also the xsl:on-completion construct are grounded and motionless (more specifically, if they aren't, then the xsl:iterate instruction is roaming & free-ranging.) The "two operands" referred to in 2(b) are the select expression and the contained sequence constructor. With these additions/clarifications, I think rule 2 is correct.
The WG agreed with the proposed changes and these have now been applied.