- From: <bugzilla@jessica.w3.org>
- Date: Tue, 31 Dec 2013 14:05:47 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24179 David Rudel <drudel@explorelearning.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |drudel@explorelearning.com --- Comment #2 from David Rudel <drudel@explorelearning.com> --- Question: would this be the only violation of the general rule that a variable is in scope within any element that is a following-sibling to the variable's declaration or a descendant of such a following-sibling? It seems that, from a consistency viewpoint, it would be desirable to restructure the xsl:iterate instruction itself so that its syntactic contents are consistent with both the scoping rules and the algorithmic notion that <xsl:on-completion> pertains to the <xsl:iterate> but is not evaluated as part of the loop. This could be done by introducing a <xsl:iterate-loop> element, so that the structure of the xsl:iterate instruction is: <xsl:iterate> <xsl:param/> ... <xsl:param/> <xsl:iterate-loop> .... </xsl:iterate-loop> <xsl:on-completion> ... </xsl:on-completion> </xsl:iterate> Any xsl:next-iteration or xsl:break elements would occur inside the <xsl:iterate-loop> element as tail-position elements. The variables inside <xsl:iterate-loop> would, in this construction, be naturally out-of-scope once <xsl:on-completion> is hit, but the <xsl:param> elements would still be in scope. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 31 December 2013 14:05:48 UTC