Saxon » SaxonJS

Here's the key attribute link that I missed in the above.

An important distinction here, as I re-read my post: by "attribute" I mean a characteristic of the musical measure, as opposed to the technical term denoting a property attached to an XML element. Apologies for the confusion this may cause.

A fasinating problem.

It's not immediately clear to me why you are carrying the state forward both using template parameters and using accumulators. I would have thought they were alternatives.

Rather than using sibling recursion over the measures as you are doing, I typically tend to use xsl.iterate. One of the differences is that on each iteration you only need to set the parameters that have changed since last time. With sibling recursion you can achieve the same thing using tunnel parameters. But perhaps that's not such a big deal.

Another thing that might simplify the code is to bundle all the "attributes" into a map, passed as a single parameter (or accumulator value) rather than maintaining a separate parameter for each "attribute".

Another way to maintain state that is often overlooked is to use memo functions. You could implement a recursive function to compute the effective key signature for a measure as the explicit key signature for that measure if present, or the effective key signature of the previous measure otherwise; and if this is implemented as a memo function, it will be effectively stored as implicit state associated with each measure, and will compute in constant time. Not actually very different from accumulators, but a bit more flexible. (However, I need to check the implementation status of memo functions in SaxonJS).

And there's always the old-fashioned way of doing it: run a preprocessing pass over the data that stores the implicit properties of each measure redundantly as explicit properties. and then in a second pass all the properties are now explicit.

Thank you for your reply. I was indeed hoping to pique the interest of the community with what I think is a common issue.

It's not immediately clear to me why you are carrying the state forward both using template parameters and using accumulators. I would have thought they were alternatives.

This may be due to my lack of understanding of the processing model of accumulators. My understanding is that an accumulator rule will be invoked for each matching node, exactly once for each.

In the example of a musical key signature, I use the accumulator to store the key signature for each visited measure - the value will either be a copy of the previous key, or the new key if one is declared in the current measure.

But I don't want to emit a key signature at each measure during the transformation. I just want to emit a key if it has changed from last measure. This is where it gets tricky, as per the rules of music theory. There are actually two cases where the key will change:

• If a new key is explicitly declared as per the accumulator description above
• If a musical loop jumps back to a measure that occurs within a different key signature than before the looping occured

It is to detect the key change that I am carrying around a template parameter. The accumulator gives me the key signature for the current measure, but I could find no mechanism in the accumulator alone that would remember the previously emitted key signature (remembering that it's not necessarily the previous measure in document order).

Thanks for the various suggestions, I will dig into them.