[Bug 29120] [xslt 3.0] last() in a streamable xsl:merge

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

--- Comment #4 from Michael Kay <mike@saxonica.com> ---
Our streamability rules for xsl:merge currently impose no constraints on what
you can write in xsl:merge-action; this is on the theory that the context item
for xsl:merge-action is grounded (it's a sequence delivered by snapshot()).
Although there's a good case for allowing test="position() eq last()" so one
can detect the last group in the sequence of groups, permitting last() without
restrictions would allow

<xsl:merge-action>
  <xsl:if test="last() = 27186">...</xsl:if>
</xsl:merge-action>

which requires knowledge of the number of groups even when processing the first
group. As I mentioned, Saxon is actually handling this, by reading all the
input twice, but I don't think this comes within our usual definition of
streaming.

The problems are slightly different when it comes to computing a merge key.
Here we are currently allowing

<xsl:merge-source for-each-stream="doc.xml" select="/*/*">
    <xsl:merge-key select="last() - 825"/>

where we can't compute the merge key without knowing the number of items in the
input.

The problems with last() actually go beyond xsl:merge. Consider:

<xsl:for-each select="copy-of(/*/transaction)">
  <xsl:value-of select="last()"/>
</xsl:for-each>

Here last() is allowed because the context posture is grounded. But we have the
same problem, that in effect we have to materialize the entire result of
copy-of(), rather than pipelining it one item at a time. I think this is
consistent with our general approach - we also allow reverse(copy-of(/*/*)) -
so in effect we're saying if you use copy-of on a streamed input sequence, the
system may need to hold the entire result of copy-of in memory. But with
xsl:merge, where we do an implicit snapshot(), holding the entire sequence of
snapshots in memory would destroy the whole point.

I'm not sure whether comment #2 is suggesting that we make use of last() in
these situations a dynamic error. That would be very different from our usual
approach where streamability violations are detected statically.

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

Received on Monday, 28 September 2015 10:42:51 UTC