John Austin wrote:
I offered (off-line) to look merging the Alt-Design code in to the main branch but I suspect that there are some different directions associated with this. Perhaps this is the reason it has not been done so far. I am still willing to work on this but I don't want to walk in to a firefight.
FWIW, I don't think there is really a firefight. Our discussions are usually at least robust, maybe even rowdy, but AFAICT, there is a large amount of mutual respect. That said, we *are* still trying to sort out some design issues. We currently have three lines of development, and I have made my initial focus an effort to try to get that winnowed down to one as quickly as possible. One of the three is Peter's alt-design. Here is a quick summary, as I understand it (Peter please correct these if wrong -- I'm not trying to misstate your case): 1. improved property handling 2. pull-parsing instead of an FO Tree (but with some data stored in memory) 3. a different layout approach
Re #1: there is general agreement that this can be improved, and performance is only one aspect of this. As you have already found, readability is an issue as well. Now that we have the FO Tree stuff in trunk isolated (kind of), we can begin thinking of the FO Tree as a service or a separate product. IOW, it can have its own API "contract" with the rest of FOP. As long as the API remains constant, we can change the mechanical aspects behind it without breaking anything else. Thus my comments yesterday about changing the API first.
Re #2: this is the one that I don't yet understand. Peter and I had a thread about six months ago that tried to resolve this, and I think he will respond to this when he has time.
That thread was as much (or more) about #3, IIRC. Yes, alt.design uses pull parsing, but it definitely builds a tree, using the Tree and related classes that I wrote when I first became involved. The major difference is not with pull parsing (although it necessitates a different approach for extensions), but with the layout dependencies that I see as unavoidable for property resolution. (See below.)
Re #3: we have now implemented LayoutStrategy, which means that alternative layout systems can at least theoretically be dropped into FOP. See subsequent announcement for more information on this aspect.
And thereby hangs a tale. I started (FOP)life as a believer in the separation of property resolution and layout as sequential stages, as the Rec seems to state very clearly. In the process of trying to code the property resolution, it gradually dawned on me that such separation cannot occur. Going back to the Rec, I found the editors' escape clause. Dialogue with the editors has since confirmed that they were aware of the layout dependency for property resolution.
The question for me was, "Do I kludge around this dependency and introduce back-door methods of solving the layout feedback issues for property resolution, or do I look for a design that is up-front about this?" I was engaged in that search. The process will not be simple and clean, because the problem is not. I'll settle for coherency, robustness and comprehensibility, if I can achieve them.
The real issue for you John is whether #1 can be separated from #2 within the alt-design stuff. I don't know the answer, since properties to me means "FO Tree" and means something else in alt-design. I would personally be very glad to have you look at the whole thing, being confined neither to the status quo nor to Peter's work (but considering both), and make a recommendation. One of the reasons for the FO Tree isolation work was to make issues like this easier to address -- except for the FO Tree API issues (which should be resolved first), you don't have to worry at all about breaking layout or renderers.
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>