W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2015

[Bug 29161] [XSLT30] setting the context size with xsl:apply-templates during streaming

From: <bugzilla@jessica.w3.org>
Date: Wed, 30 Sep 2015 09:14:40 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29161-523-rk4qDCYOO3@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29161

--- Comment #1 from Michael Kay <mike@saxonica.com> ---
For case (2) where the template is declared streamable, it can't use last() so
I don't think there's a problem. It doesn't matter that we specify what the
context size is, given that there's no way of writing code that depends on its
value.

Case (1) - and this also applies to 29153 - is indeed a problem. In a sense we
could regard it as a "pipelining" problem rather than a "streaming" problem, in
that any use of last() is going to break pipelined evaluation of constructs
like filter expressions and thereby increase the use of memory. I think this is
probably the best way to tackle it. 

Essentially, if an expression is grounded and consuming, then the processor may
or may not need to store the entire result of the expression in memory, and
using last() increases the likelihood that it will need to be stored in memory.
The same applies to other non-pipelinable operations such as reverse(). Users
need to be aware of this but we do not explicitly prohibit these constructs.

I'm less comfortable about doing the same with xsl:merge but at this stage of
the game perhaps it's the simplest answer: we should simply issue a health
warning against use of last(), but not reject it statically as non-streamable.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 30 September 2015 09:14:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 September 2015 09:14:42 UTC