Finn Bock wrote:

> 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.

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 (I do not have this working). The bottom line is that, if you
conceivably need to see both the beginning and end of the input
simultaneously (which we do), and you are writing so that disk space is the
only constraining factor, you will have to either be prepared to re-parse
the data (Peter's approach) or to serialize what has already been parsed (my
approach). I have never been able to see a third alternative. But I am
always open to new ideas. I rather suspect that the current FOP design is
oriented toward common use-cases rather than a comprehensive treatment that
will handle all cases.

Victor Mote

Reply via email to