This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24179 - [xslt 3.0] References to local variables within xsl:iterate/xsl:on-completion
Summary: [xslt 3.0] References to local variables within xsl:iterate/xsl:on-completion
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Last Call drafts
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-30 11:12 UTC by Michael Kay
Modified: 2014-02-24 15:55 UTC (History)
2 users (show)

See Also:


Attachments

Description Michael Kay 2013-12-30 11:12:59 UTC
(From a Saxon bug report by David Rudel)

Consider:

<xsl:iterate select="*">
  <xsl:param name="p" select="0"/>
  <xsl:variable name="v" select="$p + number(.)"/>
  <xsl:on-completion select="$v"/>
</xsl:variable>

We say explicitly that xsl:on-completion can make reference to the local parameters of the xsl:iterate instruction, but we say nothing about references to local variables.

Under the scoping rules for local variables, $v is in scope, but what is its value? The obvious answer would be, the value to which it is bound during the final iteration, that is the value computed while processing the last member of the input sequence. But what if the input sequence is empty? It seems that the variable would then be in scope, but having no value, which is a situation without precedent.

The only workable answer to this I can see is to say that $v is out of scope within xsl:on-completion. This is consistent with the rule that there is no context item within xsl:on-completion.
Comment 1 Michael Kay 2013-12-30 12:06:31 UTC
I have added test case iterate-032 to test this situation.
Comment 2 David Rudel 2013-12-31 14:05:47 UTC
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.
Comment 3 Michael Kay 2014-01-01 23:33:36 UTC
It would not be the first exception to this rule; exceptions already exist for xsl:fallback and xsl:catch.
Comment 4 Michael Kay 2014-01-30 18:27:59 UTC
The working group decided (subject to review if there is pushback) to reposition the xsl:on-completion element to come after the xsl:param elements and before the sequence constructor, thus making the variables declared in the sequence constructor out of scope for the on-completion element.
Comment 5 C. M. Sperberg-McQueen 2014-02-10 10:48:06 UTC
The WG discussed this during the ftf meeting in Prague and reconfirmed the tentative decision taken during the call of 30 January 2014.