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 org.xml.fo & org.xml.fo.helper stuff would go in some vendor-neutral project, and the implementations would simply be part of the vendor package. Does that sound right? 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 org.xml.fo, 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
