Jeremias Maerki wrote:

> I've talked about it before, so in case anybody is interested 
> I've uploaded the Javadocs [1] for a general XSL-FO 
> processing API I've been working on during the last few 
> weeks. It's basically my API proposal that is (or rather was) 
> on the Wiki. I've called it JAFOP (Java API for XSL-FO 
> processing) for now. But naming can change... The 
> implementations for FOP maintenance branch and FOP HEAD 
> already work for simple use cases. No fancy stuff, yet (no 
> events, no userconfig.xml...). 


> If there's enough interest I can put the source code for the 
> API plus implementations on my website (or to a SF project or 
> somewhere else).
> I believe this common API could be interesting in the 
> following months when FOP HEAD advances. It can be used to 
> easily switch implementations or during development/testing. 
> And I've got a few additional ideas. As time allows...
> It might also be interesting to have implementations for 
> Foray, Defoe, XEP and maybe even ol' JFOR. I hope the design 
> is flexible enough to accomodate all Java implementations.

Hi Jeremias:

I looked at the doc, and I think this is all pretty useful. I'd like to
spend some more time on it later, and I think I will probably write a FOray
implementation after I get 0.2 released. Here are some preliminary thoughts:

1. How do you anticipate deploying this? It looks like the user is aware of
which implementation he is using, and therefore knows or can find the
class(es) that implement the interface(s). So it looks like your
& stuff would go in some vendor-neutral project, and the
implementations would simply be part of the vendor package. Does that sound

2. One thing that I really like about your idea is that, if done properly,
the implementation classes almost become self-documenting tutorials on the
API for the specific implementation. If jafop exposes a general API for what
is needed to process an FO document, then the innards of the implementation
show how to use the API for the specific implementation.

3. There is more going on here than I anticipated. In, there are
four interfaces that a vendor needs to implement. I am not sure what
FOPEventListener is supposed to do. Of the other three, it looks like two of
them exist to handle variations in input. I *think* that these could be
boiled down to just one interface, and that the input variations could be
handled with overloaded methods or some other way. However, I sure could be
missing something.

4. If you think aXSL is an appropriate home for the vendor-neutral pieces of
this, that would make some sense to me. As we have previously discussed,
jafop is a subset of what aXSL is supposed to eventually handle. Vendors
using the "app" or "jafop" or whatever part of aXSL would be free to ignore
the other parts of it, if and when they appear.

5. I know when I see the substring "FOP" in the vendor-neutral part of this
stuff, that it is being used in a vendor-neutral way. However, since the
general term "FO Processor" has already been taken by a specific
implementation, it may be good to find some variation, not only for
political reasons, but practical as well (cuts down on confusion). Maybe
something as simple as PFO, or maybe the aXSL name can help here.

I think you have done a good thing here.

Victor Mote

Reply via email to