We discussed this in Prague and agreed that the issue report identifies a problem needing solution:  the streamability checks for accumulators needs to account for their initializers.

We came to the view that error [ERR XTSE0548] in 6.6.1 should apply to initializing expressions for accumulators; the discussion of posture and sweep of variables in 19.8.4.38 should probably point to 6.6.1 for that variable.  (Note that strictly speaking this error cannot always be detected at compile time for the package in question -- it may not have any streamable initial modes, and the error may arise only when compiling a package which includes it together with some other package which does have public streamable modes.)

Note that the corresponding error for accumulators can, by contrast, be detected in the package (assuming that the streamability of the accumulator and its initializer are in the same package).

Looking at the rules for accumulators, I think it is necessary for the initial-value and the new-value expressions to be both grounded and motionless. We can't have the current value of the accumulator being a streamed node.

Furthermore, to assess the posture and sweep of these expressions, we need to know the context item type and context posture for their evaluation. The context item type for initial-value is document-node(), and for new-value it is the "match type" of the pattern as defined in 19.3. I think we can safely take the context posture for both as "striding".

I'm not convinced that the context item for evaluation of the initial-value of an accumulator should be the initial context item used for global variables, as currently stated. It seems to make much more sense to use the document node of the document for which the accumulator is being evaluated; or perhaps even an absent focus.

Regarding error XTSE0548, we need to rethink this in the light of the separation of initial context item from initial input sequence. Since these can now be different, the remaining error is that the initial context item should not be a streamed node, but that's not really an error in the stylesheet, it's something within the scope of the API.

Considering that accumulators apply to all input documents, I agree that we should not give it the same focus as a global xsl:variable, which only applies to the initial context item. Because such relation (the relation between the initial context node of the stylesheet and the documents the accumulator applies on) does not exist, an absent focus makes sense and follows the rule of Least Surprise.

Consequently, the initial-value should not have a context item type of document-node() (as suggested in para 2 of comment 2), as a possible initial context item that it applies to (provided we do not go for absent focus) is not necessarily a document node.

Concerning the problem that all accumulators apply to all documents, I do think this is something we need to address; for streamed documents it means the implementation really has no choice but to incur the cost of maintaining the accumulator for every streamed document, and there's no way of saying its not needed.

I think a reasonable way to do this would be an attribute

xsl:accumulator/applies-to

whose value is a motionless pattern that is applied to the "document element" (the first element child of the document node). If the pattern does not match, the accumulator does not apply to this document, and any attempt to access its value (once the document element has been read) is a dynamic error.

When we discussed this at today's telcon, we did not discuss comment#4 on preventing the accumulator to run on every document.

I think the proposal of Michael has merit, but I also think it should get a pendant in the xsl:stream instruction. Consider a scenario where you use packages that have xsl:accumulators defined. You may not want to use that functionality and they may be final, which means you cannot override them. In addition, maybe you want to define one accumulator and process the same streaming document twice, but the second time without the accumulator.

For such scenarios, we could add an attribute, say "enable-accumulator" (tokens, defaulting to "*") on xsl:stream. It would be beneficial to have the same ability for non-streaming documents, but I don't know how (on xsl:fork perhaps?)

Current status: the rules restricting the initial-value and new-value expressions are now present in the spec. There is still an open question about defining which documents an accumulator applies to.

For the "outstanding question" mentioned in the previous comment, see a proposal at https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Jun/0014.html (member-only). The WG discussed this proposal and leaned towards the second approach (xsl:accumulator applies-to="pattern"). We accepted this provisionally but will leave the bug open for the moment so people have time to ponder.

Although agreement to the xsl:accumulator/@applies-to proposal was tentative and the bug remains open, it has been written up in the spec.

Upon re-reading my own previous comment, an important use-case not covered with the declarative xsl:accumulator/@applies-to is this:

> Consider a scenario where you use packages that have xsl:accumulators defined. You may not want to use that functionality and they may be final, which means you cannot override them. In addition, maybe you want to define one accumulator and process the same streaming document twice, but the second time without the accumulator.

Which, in retrospect, is an argument for allowing both approaches, they both serve different use-cases in practice.

We resolved to accept the status quo with the @applies-to attribute.