[Bug 28130] [xslt 3.0] xsl:merge and accumulators

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28130

Abel Braaksma <abel.braaksma@xs4all.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |abel.braaksma@xs4all.nl

--- Comment #1 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
I think this touches on a potentially larger issue with surprising effects when
using accumulators. Assume an accumulator that counts para elements (+1 on each
para):

<xsl:template match="para">
   <xsl:value-of select="accumulator-before('para')" />
</xsl:template>

<xsl:template match="/">
    <xsl:apply-templates select="//para" />
    <xsl:apply-templates select="//para/copy-of(.)" />
</xsl:template>

The first apply-templates will give 1 2 3 4 etc, the second will result in 1 1
1 1 etc. This may not (necessarily) be what users would expect.

The same problem arises with xsl:copy, xsl:copy-of, fn:snapshot etc. But
another reading of this outcome could be: learn to understand semantics of
copying, this is by design.

I think that the problem is related, or similar to, whether a copy action would
copy inherited namespaces or not.

I can think of several ways forward:

1. Force inheritance of accumulator values (this may also force early
evaluation of accumulators) when copying, as suggested above.

2. Make inheritance of accumulator values optional, similar to
xsl:copy/@copy-namespaces (an option that is, btw, absent in fn:copy-of and
fn:snapshot), defaulting to NO, except for xsl:merge's implicit snapshot, where
it defaults to YES.

3. Special-case the xsl:merge situation. Since it is an *implicit* fn:snapshot,
we can define the implicit snapshot to retain the accumulator values. After
all, in streaming, early evaluation of accumulators is always required anyway.
This result would then be grounded as it is now, but will have the accumulator
values as if it was not grounded. Whether this is easy to define spec-wise, I
do not know.

4. As any of the previous options, but only available with streaming. This
makes sense, because early evaluation is not possible in that case, a processor
*must* evaluate all required accumulators, so there would not be a performance
hit. The big drawback in this scenario is that the outcome of a streaming and
non-streaming version of the stylesheet would be different.

5. Live with it: in that case, accumulators make no sense with xsl:merge, which
means we would drop an important use-case, as it is far from trivial to
maintain state between node visits in another way while merging.

Maybe there is a more elegant solution than any of the above. If not, my
preferences are with option 2, 1, 3, in that order.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 13 March 2015 16:58:10 UTC