Saxon

I would strongly encourage you to move to the latest Saxon 9.8 maintenance release for any streaming applications, as a very large number of test cases were added in the period since 9.7 release, and in fact it is known that many of those tests cannot be handled by Saxon 9.7.

However, I think this one is an error on your part. You have implicitly declared that the template with match="ab:Worker_Record" is supposed to handle nodes in a streamed input document, but (a) it can't do that, because of the multiple downward selections, and (b) it doesn't need to, because you have "grounded" the node by calling copy-of. So the simplest solution is to change this template rule (and the apply-templates invocation) to use a different, non-streamable, mode.

The bug entry you cite is specific to xsl:call-template, which you are not using.

Some other stylistic comments on your code (I hope you don't mind the additional feedback):

You never need to apply number() to the result of count() as count already returns a number. And you can write count(X) > 0 as exists(X).

I suppose the xsl:value-of is probably just for illustration, but in a real stylesheet you could write @xsl:texttrue</xsl:text>@.

I would personally rewrite this as two template rules:

  true

Hi Michael, Thanks for the feedback. I really appreciate it!
One more question: The example given in burst-mode streaming made me believe once it's in burst-mode using copy-of(.) the code that process this "grounded" node does not need to be streamable and can use any XLST constructs. Does it sound like the code process this "grounded" node still needs to follow streamable rules?

You're right. That is to say, copy-of creates an ordinary in-memory tree and the code that processes the copy doesn't need to satisfy any streamability rules - which means it should go in a non-streamable mode so that Saxon does not apply the streamability rules.