The loop can be stopped when we temporary run out of FO tree nodes and restarted again when new nodes has been added. I suppose that the FO tree can then be viewed as a stream of FO nodes.
[Victor]
This model probably works fine if you never need to look ahead, but there
are numerous examples (well discussed in the archives) where one does need
to do that, the most obvious being automatic table layout. Peter's solution
to that is pull parsing, which probably works, but forces an intermingling
of interests that I need to avoid. My solution is to serialize the FOTree as
necessary
Did you notice that if a FOTree (or a fragment of it) is serialized to a preorder sequential representation with end markers, the preorder, postorder and child events can be fired directly from the input stream?
IOW the event based layout can work both of a normal parent/children linked tree and a sequential tree.
The bottom line is that, if you
conceivably need to see both the beginning and end of the input
simultaneously (which we do),
I can see a need for several passes over the same tree fragment, but do we really need to see the beginning and the end at the same time?
The auto table example appears to need 2 or 3 sequential passes over the table subtree (one to find the minimum/maximum column width and one to do the actual layout), but the layout process is still sequential.
regards, finn
