Project

Profile

Help

Bug #1890

closed

Problems with accumulators

Added by Michael Kay over 10 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Streaming
Sprint/Milestone:
-
Start date:
2013-09-06
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:
Platforms:

Description

Investigation of the problem reported on the help forum here:

https://saxonica.plan.io/boards/3/topics/5778?r=5779

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.

Actions #1

Updated by Michael Kay over 10 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.

Actions #2

Updated by Michael Kay over 10 years ago

  • Status changed from In Progress to Resolved

Resolved as described in earlier response.

Actions #3

Updated by O'Neil Delpratt over 10 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in version set to 9.5.1.3

Big fix applied in the Saxon 9.5.1.3 maintenance release.

Please register to edit this issue

Also available in: Atom PDF