Project

Profile

Help

Bug #1890

Problems with accumulators

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

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

100%

Spent time:
-
Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:
Found in version:
9.5
Fixed in version:
9.5.1.3

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.

History

#1 Updated by Michael Kay over 2 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.

#2 Updated by Michael Kay over 2 years ago

  • Status changed from In Progress to Resolved

Resolved as described in earlier response.

#3 Updated by O'Neil Delpratt over 2 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.

Also available in: Atom PDF