Saxon » SaxonJS

I have reproduced the problem and am re-familiarising myself with the code in this area.

The error originates from line 367 of parseFast.js. It is looking for an accumulator with name Q{}total-items, but the index of accumulator names in the static context is empty.

I am suspicious about line 176 in xpath.xsl which initializes the $accumulators tunnel variable with a reference to ex:accumulator (on the child axis). All other references to top-level components in this template rule use either .//ex:function or ./*:co/ex:function.

No, I've checked: the package element does have ex:accumulator as a direct child, the accumulator element exists and has the right @name value.

And at line 179 the $accumulators variable has the correct value {"Q{}total-items":"FM k[1AS ] v[1ADI ] "}.

I note that the call on accumulator-after() succeeds if we convert <xsl:variable name="total-items-count"> to be a local variable rather than a global variable.

So I think that the problem might be that at xpath.xsl#196 when processing global variables, we aren't passing the tunnel parameter $accumulators through.

This seems to fix it. Solution: in the binding of variable $typed-globals at xpath.xsl#196, add:

<xsl:with-param name="accumulators" tunnel="true" select="$accumulators"
                            use-when="not($COMPILE_GLOBAL)"/>

Note in passing: the code here is over-complex because it includes multiple options for configuring the compiler, as a results of experiments to improve performance. We ought to decide which of these options we are actually using, and get rid of the code for the paths that are dormant.

A couple of observations:

(a) you may be able to work around the problem by moving the accumulator-after call so it is not in a global variable, or by changing the argument to accumulator-after so it is not a string literal (e.g use a global parameter)

(b) It's probably rather inefficient to use an accumulator like this, if you only want the value at the end of the document. That's because the current accumulator value will potentially be stored on every node in the tree. Computing it conventionally using template rules with a special mode, or using xsl:iterate or fn:fold-left(), would probably perform better.

Added test case accumulator-090.

Hello Mike and Saxonians,

Deeper background/tldr: we installed the offending code into our pipeline as a replacement for earlier code that addressed functional requirements (wrt pipeline internals) that we were also splitting out and refactoring as we worked (under a deadline IIRC). So despite its being a significant performance improvement over what it replaced, I am not surprised to hear there are alternatives we can try as well to make it even better. Yet we do feel bound to report bugs we (think we) find -- and AJ being new to our team, we decided to assign this one to him.

So adding to AJ's thanks, we will definitely be looking at the proposed alternatives. Maybe xsl:iterate is the first obvious thing to try.

Please keep reporting them! My commentary wasn't based on any thought no-one should be doing this, but more on thinking "why is it that no-one has found this bug before? What are they doing that other people aren't doing?"

Now we have solid alternatives and in the meantime we have also found a bug in applying this approach to the problem it is supposed to solve -- so good work all around, if exposing subtle bugs counts as good work. We will post again with more edge cases if we find any. With thanks for responsiveness and looking forward to the repair (since we are not done with accumulators even if we won't be doing quite this) - Cheers, Wendell.