- 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