Saxon » Non-Conformances

This scenario is actually explored in detail in section 19.7 of the spec, see

https://www.w3.org/TR/xslt-30/#grounded-consuming-constructs

I created a variant of the test case (si-group-065) that uses xsl:for-each rather than xsl:apply-templates, This fails in the same way. In principle this case differs because the call on last() is statically detectable.

For the time being I've patched this to produce a regular dynamic error with the message

Saxon streaming restriction: last() cannot be used when consuming a sequence of streamed nodes, even if the items being processed are grounded.

It would be nice if we could recommend some workaround that forces the buffering. An obvious idea is to write select="[current-group()!copy-of()]*?", because array contents are always held in memory. However, this doesn't work. Many such expressions including this one get optimized away. One that doesn't is map{'x':current-group()!copy-of()}?x. The streaming is handled using a BufferingFeed, and although this accumulates the results in memory, it still processes the sequence using the streamed push pipeline, which has no mechanism for evaluating last().

Based on your comments I have tried whether using a variable

            <xsl:for-each-group select="*" group-adjacent="node-name()">
                <xsl:variable name="group" select="current-group()!copy-of()"/>
                <xsl:apply-templates select="$group" mode="add-index"/>
            </xsl:for-each-group>

ensures the buffering and then allows the use of last() and that seems to do the job with Saxon 9.9.1.5.

Thanks for that workaround. I'm mildly surprised that the variable isn't inlined by the optimizer.

I have been doing a number of experiments to find a solution to this problem, without a great deal of success.

I tried introducing an extension function, saxon:materialize(), to force the sequence to be fully evaluated (buffered), but (a) that's not really a solution to the conformance issue, and (b) even if buffered, it's still quite hard to get last() to work correctly because we're still using a ManualIterator and it's not clear at what point we inject the known size of the context sequence.

I tried doing some static detection: we have the ability to detect that the body of for-each depends on last(), and I tried extending this to apply-templates (by examining all the template rules in the target mode); but even if we know the dependency exists, it's hard to make use of this knowledge (for similar reasons: where do we inject the known last position into the manual iterator).

The attempt to tackle this for xsl:apply-templates (by looking at all the template rules in the mode to see if they call last()) fails when JIT template rule compilation is enabled; it requires a global perspective which is not available in this situation.

So I've scrapped this code, which means we now fail test si-group-064.