I'm extremely sorry about not making it clearer that I don't intend to launch a new API discussion for FOP or that I don't want to force anyone to do anything. This JAFOP thing is just a personal project I thought others might be interested in.
Thank you for your suggestions. However, I don't think that EXSLFO would be the right place as it is focused to standardize on the XSL-FO language as such, not necessarily on Java API bindings. It could, on the other side, be launched as a JSR if there is sufficient interest in the community. It also occured to me that the API might be strong enough to accomodate other dialects like SVG. But these are just random synaptic shots. On 27.11.2004 06:36:47 Glen Mazza wrote: > As long as a FOP user is not *required* to use it, (i.e., they can > ignore JAFOP entirely and still call FOP's native JAXP-based API as in > our embed examples), and as long as JAFOP is implemented using our > current API, then I don't think I would have much problem with it. I > don't want us to lose our present JAXP capabilities though--JAXP is a > useful skill for our users to become proficient in, and something I > would like us to continue promoting. > > But your idea -- an interface that allows for run-time swapping of FO > processors (like JAXP allows for Xalan and Saxon to be switched) is not > bad at all. I wish the folks at AH and RX would create such an > interface that we could just implement. Two thoughts come to mind: (1) > perhaps we should try to reactivate that EXSLFO group and move this > topic to them, and (2) you may wish to take a look at the JAXP > specification, if you haven't recently, and see if there are any > issues/ideas/things you perhaps forgot to take into account, etc., with > JAFOP. That spec should show you what needs to be done for a common > interface to be accepted, including things you may have missed. Jeremias Maerki
