W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2015

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

From: <bugzilla@jessica.w3.org>
Date: Mon, 28 Sep 2015 10:42:48 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29120-523-35nNEI0q9w@http.www.w3.org/Bugs/Public/>

--- 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:if test="last() = 27186">...</xsl:if>

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

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

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

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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:56 UTC