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 30152 - [XSLT30] Copying accumulator values clarification (moved from test bug)
Summary: [XSLT30] Copying accumulator values clarification (moved from test bug)
Status: NEW
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Recommendation
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: 2017-07-19 15:21 UTC by Michael Kay
Modified: 2019-02-26 01:32 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Kay 2017-07-19 15:21:56 UTC
In test accumulator-063 et seq I attempted to create some tests for the rules regarding copying of accumulator values in ยง18.2.10. For example -063 has the code:

  <xsl:template match="b">
    <xsl:variable name="x">
      <xsl:copy-of select="." copy-accumulators="yes"/>
    </xsl:variable>
    <xsl:for-each select="$x/*">
      <b-acc>{accumulator-before('f:elementNr')}</b-acc>
    </xsl:for-each>
  </xsl:template>

Looking at this again, I don't think this has the intended effect. xsl:copy creates a copy of the b element with copied accumulator values, but this element is then attached to a document node constructed for the variable $x, and this (under rule 11 of Constructing Complex Content) does not copy the accumulator values to the new documnt node.

Although this might seem surprising, the alternative would be worse: consider

    <xsl:variable name="x">
      <a/>
      <xsl:copy-of select="." copy-accumulators="yes"/>
      <b/>
    </xsl:variable>

and ask what the accumulator value should be for element b.

I will rewrite the tests accordingly.

Since I misunderstood the effect of the spec here, others might also do so, and a word of explanation in an erratum might not go amiss.
Comment 1 Abel Braaksma 2017-08-18 20:05:26 UTC
> and this (under rule 11 of Constructing Complex Content) does not copy 
Of the top of my head, that sounds correct, as the data model does not allow for accumulators. So constructing complex content should not need to maintain a copy of accumulators.

But I have to admit this is rather difficult to understand (the way copying of accumulators works), and I second the idea of an erratum for bugs like these.
Comment 2 Abel Braaksma 2019-02-26 01:32:35 UTC
(In reply to Michael Kay from comment #0)
> Since I misunderstood the effect of the spec here, others might also do so,
> and a word of explanation in an erratum might not go amiss.

I've repurposed this bug as a spec bug so that we can address this concern.