Oleg Tkachenko wrote:

> I think we should separate fo tree itself from the process of its
> building. fo
> tree structure is required and I agree with Keiron - it's not a
> DOM, it's just
> tree representation and I cherish the idea to make it an
> effectively small
> structure like saxon's internal tree. But any interim buffers should be
> avoided as much as it's possible (well, Piter's buffer seems not
> to be a burden).

This is probably a philosophical difference. It seems to me that the area
tree is built on the foundation of the fo tree, and that if we only get a
brief glimpse of the fo tree as it goes by, not only does our foundation
disappear, but we end up putting all of that weight into the superstructure,
which tends to make the whole thing collapse.

> > To conclude, if I were designing this system from scratch,
> based on what I
> > know right now, I would:
> > 1. Use DOM for both the fo tree & the area tree.
> Bad idea, I believe. DOM is heaviweight versatile representation of xml
> document (recall entities, pi's etc nodes), while we need effective and
> lightweight structure to hold fo/area tree information. DOM has a lot of
> synchronization stuff, while our trees are almost read-only actually.
> Ahh stop, probably you didn't mean w3c DOM?

You and Keiron are right -- this is a classic example of using an
implementation where an interface would be much better. When I say DOM, what
I should say is "some randomly-accessible view of the entire tree."
Certainly, if there is a lighter-weight alternative than DOM that works for
the task at hand, that is better.

Victor Mote

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to