We found this Note in 18.1:

The name of the instruction reflects its intended usage, to process an input document using streaming. However, a processor that does not offer the streaming feature must still implement the instruction (without being required to use streamed evaluation or to check its streamability); and processors that do offer the streaming feature are also required to provide a mode of execution in which the construct is evaluated without streaming if it fails the streamability criteria.

Also noted that 19.10 says:

For a non-streaming processor, the processor must evaluate the construct delivering the same results as if execution used streaming, but with no constraints on the evaluation strategy.

It also says: "For a streaming processor, that is, a processor that claims conformance with the streaming feature: ... If a construct is guaranteed-streamable then it must be processed using streaming." 

So perhaps all that is needed is an API switch to say "run as a non-streaming processor"?

So we believe the requirement stated in this bug entry is already satisfied by the spec. A directive with similar effect within the stylesheet itself could be useful, but is not essential to meet the requirement.



Related to this (but not directly relevant...) is the rules for what a streaming processor must do when the construct is not streamable. In 19.10 we say

2(c) Process the stylesheet with streaming if it is able to do so, or signal a static error [see ERR XTSE3430] if it is not able to do so.

It might be useful to permit the processor to fail with a dynamic error if streaming is not possible (i.e. allow it to attempt streaming optimistically, wher e success or failure depends on the nature of the input data). E.g.

2(c) Initiate processing with streaming, raising a static error if it can determine statically that this will not be possible, or a dynamic error if the attempt to use streaming fails dynamically.

We will raise this as a separate issue, and close this one with no action.