- From: Michael Kay <mike@saxonica.com>
- Date: Fri, 16 Oct 2015 12:44:23 +0100
- To: Public XSLWG <public-xsl-wg@w3.org>
I’ve been writing up the consensus we reached on use of last() with grounded consuming sequences (i.e. that it may cause buffering), and I wondered if a different solution might be better, along the following lines: * In any focus-changing construct (§19.3), if the controlling operand is [grounded and] consuming, then the focus that is established for the controlled operands has an absent context size. When last() is evaluated with such a focus, it throws XPDY0002. (There’s a discussion going on in XQ about whether to turn this into a type error or static error; pragmatically, we could simply say that if the error can be detected statically then it can be reported statically.) For example: <xsl:for-each select=“/*/transaction/copy-of()”> <xsl:value-of select=“last()”/> </xsl:for-each> throws an error. I put “[grounded and]” in brackets because it actually applies to all consuming sequences. But for consuming sequences that aren’t grounded we have existing rules that prevent the use of last(). * For avoidance of doubt, this also applies to xsl:merge-action: if any of the merge sources has streamable=“yes” then the body is evaluated with a focus whose context size is absent, so you can use position() but not last(). This means that if you want to use last() with such a construct, you have to put the sequence in a variable first. Or in the case of xsl:merge, you have to set streamable=“no”. <xsl:variable name=“transaction-list” select=“/*/transaction/copy-of()”/> <xsl:for-each select=“$transaction-list"> <xsl:value-of select=“last()”/> </xsl:for-each> It would be nice to do this without also preventing (position() = last()), but attempting that would make the idea too complicated. Sorry, I know it’s late in the day to be raising this idea. The basic difference with this proposal is that using last() in such circumstances will usually give you either a static error or a dynamic error when processing the first item, rather than an “out-of-memory” error when the sequence becomes too big to handle. Michael Kay Saxonica
Received on Friday, 16 October 2015 11:44:50 UTC