RE: Grounded Consuming Expressions

I agree in principle with this text, I think it properly captures the concerns we have expressed in the bug entries on fn:last, apply-templates, snapshot in xsl:merge etc.

It does not mention the specific situation of xsl:merge, for which I think we have suggested the solution to use the singleton focus, which effectively allows fn:last in this grounded construct (of xsl:merge-action) without restrictions, but will have the effect of always returning 1. I think an additional line or para pointing at this particular exception rule can be beneficial.

In light of this, perhaps it is also a good idea to clearly state that programmers have another way of coding these examples, esp. the ones on last(), places with singleton focus and places where fn:last() if forbidden, as they can be made streamable across processors and without grounding by using a trivial accumulator that counts the nodes.

Also, I think we should emphasize somehow that a processor may more easily detect pipelinability (or: windowed streaming?) if a construct is written such that it only grounds the leaf nodes one at a time, as opposed to the whole stream, something like:

<proposal>
Processors may more easily detect cases where constructs are written such that the actual grounding operates only on a smallest part as possible. For instance, while there is no inherent difference between a/b/c/copy-of(.) and copy-of(a/b/c), processors may more easily be able to detect and optimize the former case.
</proposal>


And:

> In practice, however, users can expect that many simple grounded
> consuming constructs (such as those listed above) will be pipelined in any
> well engineered processor.

I don't think we should judge whether a processor that supports this kind of pipelining is well-engineered or not. Also, a "simple grounded consuming construct" is ambiguous: copy-of(/*) is simple and grounded, but likely to blow up any processor, well-engineered or not.

I propose instead:

<proposal>
In practice, however, users can expect that many grounded consuming constructs that are trivially detectable (such as those listed above) may be pipelined by a processor that supports such pipelining, also known as windowed streaming.
</proposal>

> 
> <xsl:for-each select=“transaction”>
>   <xsl:value-of select=“position(), ‘ of ‘, last()”/>
> </xsl:for-each>

Note that in this and other examples in your text, the quotes have been changed into start/end quotes... 

> <xsl:for-each select=“transaction/copy-of(.)”>
>   <xsl:value-of select=“position(), ‘ of ‘, last()”/>
> </xsl:for-each>

This example won't work here, because it requires either output buffering of the whole loop, or input buffering of the transactions, or both. Something like the following may be a better example:

<xsl:for-each select="transaction/copy-of(.)">
   <t amount="{@amount}" position="{position()}" />
    <xsl:if test="position() = last()">
       <total number-of-transactions="{last()}" />
    </xsl:if>
</xsl:for-each>

>  In this simple example the impact of the call on *last* is easily 
> detected both by the human reader and by the XSLT processor,
>  but there are other cases where the effect is less obvious.

Also, in this snippet, the text "is easily detected" suggests too strongly that every processor will detect this. I propose instead to be a bit more careful here:

<proposal>
In this simple example the impact of the call on *last* may be easily detected both by the human reader and by the XSLT processor, which can decide to apply windowed streaming. But since the construct is grounding, processors may consume all transactions prior to entering the for-each statement on the grounds that if a user writes such a statement, the user essentially tells the processor that he knows the data fits in limited memory. But there are other cases that are less obvious.
</proposal>

Cheers,
Abel

Received on Saturday, 10 October 2015 12:06:07 UTC