[Bug 24125] [xslt 3.0] intrinsically unstreamable functions

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24125

C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cmsmcq@blackmesatech.com

--- Comment #3 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> ---
The WG discussed this during the ftf meeting in Prague.

Among other things, we considered the two examples

  <xsl:for-each select="copy-of(.//emp)">...</xsl:for-each>

and

  <xsl:for-each select=".//emp/copy-of()">...</xsl:for-each>

At first glance, the first of these seems to invite materialization of the
entire sequence and the second not.  But on further examination, we realized
(with MK's help) that in fact a really naive processor would materialize both
sequences completely, and a processor that does pipelined or lazy evaluation
would materialize neither.  Adding reverse() around either of them makes it
necessary to materialize the entire sequence in either case.

ABr suggested perhaps adding a pipeline=yes|no attribute to xsl:variable, to
signal that at most one member of the sequence needs to be materialized at a
time.  (There was some confusion over whether it would then be illegal to say
reverse($v) or not.  In the end, we didn't reach a firm consensus either way on
labeling the variables.)

We did seem to have consensus that the spec should have a note warning users
that memory requirements for user-controlled storage will be higher when entire
sequences must be materialized (as when reverse() and xsl:sort are used) than
when they can be pipelined.  We may also want a note saying explicitly that
implementations of the streaming feature are (informally) expected to use
pipelined or lazy evaluation.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 10 February 2014 09:38:54 UTC