John Austin wrote:

> I am critical of what I percieve to be a pathological growth of objects
> (and search times). If those problems are corrected, there are plenty of
> resources left to do a few extra parses.
> How often will you encounter expressions this complex ? Rarely.
> If they become common (and someone will do that!), we can call THAT a
> pathalogical development and <smirk>blame the victim</smirk>.

I tend to agree with all of this, at least in terms of which end of the
spectrum we should favor.

> >  I suppose that the best way would be to
> > have your cake and eat it too -- store integers where possible,
> and create
> > objects where not possible, and teach everything how to tell
> the difference.
> > (Here is a half-baked idea that I don't want to even think
> about pursuing
> > for a while -- PropertyStrategy. With the API I have proposed, one could
> > conceivably store the Properties one of several ways, and have the user
> > select which one they want based on performance needs).
> As Peter knows, I have been reading the code. I shall attempt the
> XSL-FO Spec soon. I understand the spec defines the behavior of
> the program in terms of fully parsed/expanded trees. This
> implies that objects must exist even if they will never be used
> after the parser moves past their end-points. Optimization anyone?

This doesn't sound right to me. I think you may have misunderstood
something, but you'll need to be more specific for me to tell.

> What I infer of the Tree structures in your discussion and Peter's
> code suggests to me that FOP creates a DOM-ish view of the document
> in one or more trees. This is a mis-match with the SAX parser that
> is in there somewhere.

FOP's design on the SAX/DOM issue was a difficult issue for me to grasp, and
when I did, I documented it here:

There is no mismatch at all. The input we work with is a tree. Therefore a
tree-like structure is absolutely necessary to represent it. I am pretty
sure from past discussions with Peter that he employs a tree-like structure
as part of this pull-parsing. So, if it is important for FOP to use a
tree-like structure to represent its input, the only issue is whether to use
DOM or some home-grown structure. Since a home-grown structure is much
lighter and more flexible for our needs (AFAIK, adding business logic to a
DOM would be impossible), the only question is what standard way should the
home-grown structure be built. SAX provides a much lighter-weight way of
building our home-grown structure than anything else that I have seen.

Now, if you can figure out how to digest an FO document without building a
tree that represents a page-sequence object, I hope you'll share it with the
rest of us. That could be a breakthrough indeed.

Victor Mote

Reply via email to