RE: ACTION 2016-05-26-001: ABr to raise an issue analogous to 29499, addressing accumulators.

Raising this bug caused a discussion between Michael Kay and me which led to a new insight.

The way the rules are currently written, a global context item can only be accessed with motionless expressions in global variables. This was done at the time on the assumption that often the global context item is the same as the initial match selection (as was the default in XSLT 2.0), and reading ahead and at the same time processing the same stream is equal to more than one downward selection, which we know is not allowed in streaming.

The wrong assumption we made all the time is that the global context item and the initial match selection are connected, or the same. While in fact they are, from a spec perspective, totally different input entities.

Result: you can only ever read the root node with a non-consuming expression (for instance, ask for the document uri). This is a very narrow use-case and the rules are complex and led to a lot of discussion for getting it right (see bug 29499). Furthermore, a workaround for this use-case exists with accumulators.

The proposal in the discussion in issue 29670 (see comment #3 by Michael and comment #4) is therefore to drop streamability of the global context item completely. This will simplify API design, simplify rules in the spec.

An alternative solution is to do the opposite. Allow consuming global variables. That can work if approached in the same way as forking or maps, which also allow multiple downward selections. It also works because we now know that the initial match selection and the global context item are distinct entities. Even if they are the same document, the forking will take care of properly consuming the input tree.

The problem with this approach is that upon use of such global variable, potentially the whole (streaming) global context item must be consumed. While this is the responsibility of the programmer, this may lead to side effects (because we cannot determine when a global variable is evaluated), more so if the stream is, for instance, a live stream and happens to be the same as the initial match selection.

I therefore favor the first solution, where we drop this capability for reasons mentioned above and in the issue (esp. comment#3 by Michael Kay and comment#4 by me). It seems to me the proper thing to do and we lose little or no functionality, which I hope is enough ground to do this at CR stage.

Cheers,
Abel


> From: Abel Braaksma [mailto:abel.braaksma@xs4all.nl] 
> Sent: Friday, May 27, 2016 11:56 AM
> To: Public XSLWG
> Subject: ACTION 2016-05-26-001: ABr to raise an issue analogous to 29499, addressing accumulators.

> Action item done, see bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=29670.

Received on Wednesday, 1 June 2016 02:21:57 UTC