Bug 20981 - Why accumulators are not passed to xsl:evaluate?
Why accumulators are not passed to xsl:evaluate?
Status: CLOSED FIXED
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0
Working drafts
PC All
: P2 normal
: ---
Assigned To: Michael Kay
Mailing list for public feedback on specs from XSL and XML Query WGs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-12 16:25 UTC by Florent Georges
Modified: 2013-05-24 14:18 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Florent Georges 2013-02-12 16:25:33 UTC
"10.4 Dynamic XPath Evaluation" <http://www.w3.org/TR/xslt-30/#dynamic-xpath> says that user-defined functions are part of the static context of the XPath expression to evaluate. But it excludes explicitly accumulators.

The reason why it does so is not clear.
Comment 1 Michael Kay 2013-02-14 23:23:35 UTC
I think the rules may be over-restrictive.

In the absence of streaming on the accumulator, the only reason to have restrictions is the possibility of circularity (and dependence on order of evaluation) among multiple accumulators. But I don't think this is in principle different from allowing infinite recursion in ordinary function or template calls. So with an accumulator that specifies streamable="no" we should lift restrictions.

With streaming on, an alternative design might be to say that if an accumulator function is called and the context node is not the current node in a streamed input document, then calling the accumulator function is allowed, but fails dynamically. This might lead to a simpler set of rules.
Comment 2 Michael Kay 2013-02-25 15:41:04 UTC
We've generally had a rule that streamability must be determinable statically. If we relax the rules disallowing dynamic calls on accumulator functions, we lose this property. However, I think it may be worth doing.

Defining the dynamic rules is not entirely trivial, but I think it can be done using the concepts of pre-descent instructions and post-descent instructions in 19.3.3. Something like this:

If an accumulator function is called and the context item is a node in a streamed input document, then a dynamic error occurs if neither of the following conditions is true:

* the function is a pre-descent function and it is being invoked in the course of evaluating a pre-descent instruction in a template rule that matches the context item

* the function is a post-descent function and it is being invoked in the course of evaluating a post-descent instruction in a template rule that matches the context item

I think this approach would allow us to be a bit more flexible about evaluating accumulator functions while processing leaf nodes such as text nodes.

While we are about it, I'm wondering if we need any special rules to prevent a reference to a streamed node appearing in the closure of a context-dependent function item.
Comment 3 Michael Kay 2013-05-16 15:12:43 UTC
See https://lists.w3.org/Archives/Member/w3c-xsl-wg/2013May/0006.html for proposed resolution
Comment 4 Michael Kay 2013-05-23 16:49:07 UTC
Proposal was accepted (with comments/observations).
Comment 5 Michael Kay 2013-05-24 14:18:32 UTC
The proposed changes have been applied.