Arved et al,

To clarify further: there are three re-design efforts going on.  Keiron 
& Karen in Java, building on the existing code base.  Arved doing a 
ground-up redesign in Perl (protptyping) and C or C++, as he has 
discussed.  Me, in Java, doing a ground-up.

Do not despair.  If Flannery O'Connor is to be believed, Everything That 
Rises Must Converge.  I believe that these design efforts will, if not 
converge, at least cross-fertilise one another considerably.  You will 
probably have noticed that there is a lot of cross-talk between the 
principals.  At the end of the day, I think that the best ideas will 
shake together in the bottom of the pan.

However, I would hope for more.  I can conceive of no reason why a 
common design will not work in Java, C, C++, Perl or any other language 
of choice.  Implementation details may differ, but the same overall 
design should be realisable in any useful language.  In that sense, I 
disagree with Arved.  I think his work *is* contributing to the redesign 
of FOP.  Obviously, I think mine is too.

So, if you decide to get involved in xslfo-proc, the effort will not be 
wasted in terms of helping bring FOP to completion.

Let me just strongly endorse Arved's comment about the oxymoronic "UML 
design", as in "design by UML".  What a bizarre idea.  It must be 
something consultants do.


Arved Sandstrom wrote:

>Hi, Matt
>Let me clarify. The redesign is what Keiron & Karen (primarily) are working
>on. It is a redesign for FOP.
>What I started last fall is another project, which is intended to produce a
>C/C++ XSL-FO formatter. This is called xslfo-proc, and is on Sourceforge. ...
>I did enough UML design last fall to realise that that was a waste of time.
>So a month ago I started working on a Perl prototype. I uploaded the first
>code yesterday ... I expect
>to have some pretty good layout happening within a month.
>I have no intentions of abandoning FOP, but the redesign for FOP was and is
>critical, and only so many people can usefully do that - two max, IMO. ... I am 
>devoting most of my efforts to
>xslfo-proc - it has a different approach and I hope it complements FOP
>rather than competes with it.
>I'll second one specific comment of Peter's very strongly. I also believe
>that an XSL formatter project that is going to succeed has to tackle the
>whole problem. Formatting is not very modular, in other words. Not
>everything needs to be implemented right away but it sure needs to be
>considered, and a place for everything needs to be built in. The existing
>FOP shows us that retrofitting doesn't work.

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

Reply via email to