Saxon

The problem only arises with mixed content, for example with a document like

<a>xx<b>yy</b></a>

When the TinyTextualElement <b>yy</b> is encountered and the most recent event was a text event, the TinyTreeWalker assumes that we've already emitted the "yy" and that we can now emit the endElement event for </b>, whereas in fact we haven't we've only just emitted the xx.

The answer to this is probably to maintain a queue of events waiting to be output. When next() is called and there are items on the queue, it emits the next item on the queue. When a TinyTextualElement is processed, it should put three events on the queue, for the startElement, text, and endElement.

I wrote a new batch of unit tests for the TinyTreeWalker and discovered a lot more cases that were failing.

Attempted a rewrite, but found it challenging to get it all right.

In principle it's just an inversion of the logic used by TinyElementImpl.copy(), but it seems harder to achieve in pull mode because of all the state that needs to be maintained.

Since TinyTreeWalker is just an optimization anyway, and it's not used on any very important paths, it seems simplest to scrap it and just use the generic TreeWalker instead (this works on all trees. It has its own complexities, being based on a stack of iterators, but it works...).

This exposed one other bug: we get a NullPointerException if getSystemId() is called when the tree walker is in a particular state.