Problems with accumulators
Investigation of the problem reported on the help forum here:
reveals a number of bugs in the implementation of streamable accumulators.
(1) The accumulator value is not updated when the accumulator rule fires on a text, comment, or processing instruction node.
(2) If both a pre-descent and post-descent function are defined, then two separate accumulators are maintained, both holding the same value. This doesn't lead to incorrect results, but it is grossly inefficient.
(3) There is no check that the "new-value" function defined for the accumulator is motionless
(4) When the accumulator value is saved as the string value of a node (after fixing (1) above), the string value may be held in mutable form, such that when the stream advances, the content of the underlying buffer changes.
#1 Updated by Michael Kay about 3 years ago
- Status changed from New to In Progress
I am committing a patch that fixes the above problems.
It also addresses the issue raised in https://www.w3.org/Bugs/Public/show_bug.cgi?id=23179 - an expression such as string(.) is allowed in the new-value expression, even though it is not motionless according to W3C rules. More precisely, if the accumulator rule pattern can only match text, comment, or processing instruction nodes, then we allow the new-value expression to be consuming rather than requiring it to be motionless. Note that the expression "." cannot be used without an explicit string(.) or data(.), because it is not possible to save a reference to a streamed node.