Saxon » SaxonJS

Thank you - I have a work-around in place that seems to solve the problem (in an ugly way): I store all visited URLs in a property in xsl:page() and depending on the presence of a URL, I call the deactivate/reactivate templates.

The call to doc() is still being used, so it would seem that the problem is indeed related to known documents in combination with modifications elsewhere on the page. Good luck - let me know if I can help.

It's not actually a concurrency issue, it's a lazy evaluation issue. There are two instructions here that have side effects: xsl:message and ixsl:set-property, and because these have side effects, the order of evaluation becomes visible.

A sequence constructor is being evaluated using the logic:

(a) for each of the instructions in the sequence, get an iterator;

(b) read off the items delivered by these iterators in turn.

Now, both xsl:message and ixsl:set-property are doing their stuff (producing their side-effect) at the time you get the iterator (stage (a)) rather than at the time you read the iterator (stage (b)), which means that if a sequence constructor contains an xsl:for-each followed by an xsl:message, the xsl:message output will be displayed before the xsl;for-each is evaluated.

This is all legal according to the XSLT 3.0 specification, but very unhelpful. I think the policy we have generally adopted (and although it's not required by the spec, there are things in the XSLT 3.0 streamability analysis that assume it) is that the instructions in a sequence constructor should be evaluated in the order they are written. I think we should change the implementation of sequence constructors to follow that policy.

Thanks for your answer. Well yes, that explains a lot. However, I still do not fully understand how this influences the order of events when a new document is loaded vs. one that has already been loaded. After all, that is what seems to be causing the problem. If it is not concurrency, what is it?

Now that I have a better understanding, I came up with a work-around that seems to be more generally applicable than my earlier one: the call that resets the view to normal (template named "reactivate-tab") is now wrapped inside an xsl:schedule-action with a short wait-amount. This seems to work well.

Do you agree that this might be a feasible way to go?

The whole thing shows once more that side effects are, in the American president's words, "very bad". But now that they are here, I have the feeling that a solution like the one you are describing will certainly remove the counter-intuitive effects that I encountered. After all, my use case (informing the user about a lengthy operation) seems to be very normal.

Wow - my compliments and thanks for offering a look into the internals of Saxon. This feels like an important discovery for the usefulness of Saxon-JS!

Will the fix involve the compiler or just the runtime? In the first case, as I am using the Oxygen-supplied version, I will have to invest in a Saxon Enterprise license. But considering the efforts you are taking, I think that will be money well spent!

Oh yes, the fix is purely in the Saxon-JS runtime. The next release is hopefully not too far away now... (and this was certainly something important to get fixed!)

No problem, indeed this has been very useful to work through. I had previously encountered similar "counter-intuitive effects" (good phrase) when working on our documentation app stylesheets. I knew the issue was something to do with side effects, but had not managed to pin down the problem. Like you I was using xsl:message to try to debug the behaviour, but getting unexpected results. Now it makes sense - previously the xsl:messages were unreliable, since they could in fact appear before a preceding instruction had been evaluated. So much better that we can actually trust the order of the xsl:messages now!!