On Sat, Jul 10, 2004 at 06:16:37PM -0700, Glen Mazza wrote: > 1.) Drop the apps.Driver class and incorporate its > remaining code into apps.Fop. > > Reason: "Fop" appears to be a better self-documenting > class name within user's embedded code. It's also a > neat name for a product. User's code would move from > looking like this:
> 2.) Shall we roll the dice? I wonder if we should go > 100% JAXP for 1.0, i.e. coding just like this [1] for > SAXSources and [2] for DOMSources, and removing the > older methods from Driver where one would be using > XSLTInputHandler. We're currently that way with [2] > (As of yesterday ;), the question is should we go that > way with [1] now? I am positive to both ideas. > --- "J.Pietschmann" <[EMAIL PROTECTED]> wrote: > > Have another look at the API proposals in the old > > Wiki. > > > > > http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization > > > > Well, a bit too expansive for my (personal) tastes, at > least for 1.0--but to be candid, much of it I still > don't understand. Regardless, the resources we have > for 1.0 IMO should be focusing on other areas > (fo's/layout/renderers) at this time. Perhaps another > reason for my recommendation for a "spartan" API > similar to what we now have for 0.20.5. > > Our inputs I see for 1.0: > > --XSL FO document (or xml/xslt) > --preferred render type > --FOUserAgent and UserConfiguration, whatever portions > of functionality/coding in each. > > That should be enough for us in 1.0, no? Those more > elaborate API goals appear best discussed post-1.0, > presumably once more vital parts of the system have > been addressed. > > More thoughts, anyone? Simon, what would you be > comfortable with API-wise in 1.0? I agree with these priorities. Such a FOP would perhaps not have a better API than the maintenance code, but it would be an implementation of the redesign and thus end the unfortunate split between maintenance and development. I have not yet had the time to read Jörg's proposals, but I think I would have the same conclusion: move it forward until there is more time. Perhaps it is indeed wise, as Glen concluded, to leave the API much as it is, in view of the fact that we do not yet have a final view on it. However we do it, we will go through two phases: implement the new layout, and implement a new API, and there will be a time between the two. I think moving to JAXP now is desirable, for all the reasons one follows a standard API. Note that the Xalan and other people call the javax.xml.transform part TrAX. AFAIK, javax.xml.parsers is also in JAXP. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
