W3C home > Mailing lists > Public > public-xsl-wg@w3.org > March 2016

RE: Sequences with mixed posture

From: Abel Braaksma <abel.braaksma@xs4all.nl>
Date: Wed, 2 Mar 2016 18:18:36 +0100
To: "'Michael Kay'" <mhk@mhk.me.uk>, "'Public XSLWG'" <public-xsl-wg@w3.org>
Message-ID: <12f901d174a7$8faaf040$af00d0c0$@xs4all.nl>
This is an interesting case, to say the least. In general, I think we can solve it without doing much to the current text (i.e., a Note perhaps, but no need to change the rules) because the variable reference will only ever be allowed to contain a copy of nodes. As such it is not possible that the streamed nodes overlap (have the same root) as the unstreamed nodes (the one in the $variable).

Since the order of nodes not sharing the same root is implementation defined (not between themselves, of course, but from one set to another), no additional ordering is required and it becomes streamable.

However, there is one case where this does potentially not work: when used inside a streamable function. Here you can write something like:

<xsl:for-each select="$var/x">
    <xsl:sequence select="$var/z | ./y" />

But I believe we have disallowed such constructs: the streaming parameter is not allowed to appear inside a higher-order operand. Since xsl:for-each changes focus, it is a higher-order operand and the above is considered non-streamable per the current rules (and rightly so).


> -----Original Message-----
> From: Michael Kay [mailto:mhk@mhk.me.uk]
> Sent: Sunday, February 28, 2016 4:09 PM
> To: Public XSLWG
> Subject: Fwd: Sequences with mixed posture
> >
> >>
> >> So I'm inclined to the approach which involves minimum change to the
> spec: mixed-posture expressions such as ((/books/book, $moreBooks) /
> title) are guaranteed streamable, and we just have to put the burden on
> implementors to make it happen.
> >
> > I've implemented this solution in Saxon, at least for this test case.
> >
> > For information, the logic is essentially:
> >
> > (a) for simplicity, streamed nodes always come before unstreamed nodes
> in document order. Relative order across different trees is implementation-
> dependent, so we're allowed to do that.
> >
> > (b) if there's a sort-into-doc-order node on the expression tree (after
> optimisation), and the operand is striding, then we provide a streamed
> implementation of this expression which operates as follows: if an item
> arrives that is a streamed node, then emit it immediately in the result; if an
> item arrives that is grounded, then save it in a buffer. On completion, sort
> the buffer containing grounded nodes into document order, and then emit
> them in order to the result.
> >
> > Michael Kay
> > Saxonica
Received on Wednesday, 2 March 2016 17:19:21 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 17:19:22 UTC