This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Consider an xsl:accumulator with streamable="no". Then, when you encounter accumulator-before or accumulator-after calling that accumulator, the description of streamability[1] points to the GSR and to 18.2.7 [2], Streamability of Accumulators. Under that section we say the following: "Specifying streamable="yes" on an xsl:accumulator element declares an intent that the accumulator should be guaranteed streamable according to these criteria." In other words, we don't explicitly disallow the use of accumulators that have streamable="no". This prevents static analysis of accumulators based on their streamable attribute. [1] http://www.w3.org/TR/xslt-30/#streamability-fn-accumulator-after [2] http://www.w3.org/TR/xslt-30/#streamability-of-accumulators
We discussed this (together with bug 24650 and bug 24651) at the Prague face to face. On reflection, some WG members suggested that our problem is that accumulators are not bound to specific inputs; the spec seems to suggest that every accumulator is evaluated for every node of every input tree. Should streamable inputs and accumulators go together, and unstreamable likewise? (That seems to raise trouble for the notion that 'streaming processing' is just an optimization, and that stylesheets have the same semantics either way.) The xsl:stream instruction could have attributes which specify which accumulators are relevant. But for doc() (etc.) this approach seems to be unavailable. Perhaps we could have a function wrapping doc() and returns the same document with (as a side effect) accumulators activated. Perhaps a pattern at the accumulator level that activates it for (a) a URI that matches the pattern or (b) a node that matches the pattern. At this point, we discovered that error XTDE3370 already does say that non-streaming accumulators are inaccessible when the context items is a streaming node. More hyperlinking may help make error 3370 more visible.
*** Bug 22201 has been marked as a duplicate of this bug. ***
We concluded that the status quo is that if you call accumulator-before or accumulator-after specifying a non-streamable accumulator at a point where the context item is a node is a streamed document, you get a dynamic error. This error is currently defined as XTDE3370. So there is no problem. (We did identify a couple of related issues: see the minutes).
A "related issue" mentioned in the previous comment is the question whether a construct can only be guaranteed streamable if it is declared streamable. For example, is <xsl:template match="*"/> guaranteed streamable if the mode is not declared streamable? We found that we were inconsistent on this question (though in a sense it is academic, since we are only interested in whether something is g-streamable if it is also d-streamable). We decided that being declared streamable should be a precondition for being guaranteed-streamable, and message https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Jul/0005.html (member only) describes the changes needed to achieve this.