- From: <bugzilla@jessica.w3.org>
- Date: Fri, 13 Mar 2015 16:58:03 +0000
- To: public-qt-comments@w3.org
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