Jeremias Maerki wrote: > from the website I don't quite get the scope of the project. > That might have to be made clearer. Anyway, I didn't want to
Yes, just as soon as it is totally clear to me :-) Right now, it boils down to "here are some things that I think could/should be shared, can anybody think of anything else?" > talk about it just yet, because it's not ready, but recently > I started writing a JAXP-like API for XSL-FO processors (I > called in JAFOP for now). It basically implements the ideas > we came up with in the API discussion over a year ago. In the > next few months I will probably need to integrate several > different FO-processors and want to have a common API for all. > Especially having a uniform API between FOP maintenance > branch and HEAD is important to me because I need to get FOP > 0.20.5 set up for PDF output and I will most probably need > the RTF output of FOP HEAD quite soon (all in the same VM, of > course). Also, the fact that we got 4 OS-FO-processors > screams for a common API so they can be used interchangeably. I think you are thinking API for the application as a whole. My vision for aXSL goes quite a bit deeper than that, trying to get a common API for the modules, IOW breaking the problem down into smaller pieces. My perfect world right now would have me using FOrayFont with RenderX. (That is not to say that FOrayFont is as good as RenderX's font handling -- it is not, yet anyway. But it means that I can get where I need to go more quickly with FOrayFont than I can with RenderX). Even if RenderX didn't subscribe to aXSL, making FOray do so would seem to make it more usable to more people. And it at least gives hope to someone writing a piece that it might be pluggable with some other pieces. There was a thread several weeks ago that had to do with how to standardize extensions between the various applications, and Finn's work on Property binding was an indirect influence here as well. However, the main thing that started me down this path was thinking through the possibility of further modularization within FOray. Right now, for example, FOrayFont is totally independent of anything that looks like XSL-FO processing. But FOrayPDF is highly dependent on FOrayFont as are layout, the renderers, etc. It seemed like a desirable thing to pull out a layer of abstraction that lets FOrayPDF work, for example, with any other conformant Font system, or vice versa. Now, fonts and graphics are pretty easy. I can pull out an abstraction for fonts that has three interfaces, one of which is already written (it may need to get more complex later), and probably do a similar thing with graphics. FOTree is much more complex, and AreaTree has complexities for a different reason. > Can it be that we had the same idea at the same time again? > :-) Of course, having standardized validation messages and > such goes a bit beyond what I imagined, but that's ok. Actually, I don't envision standardized validation messages, although that would be OK. (I suppose you could even handle the multi-lingual aspects of that in a nice way.) I think that the original thread was dealing with how the exceptions should be thrown, and that *would* be a good thing to standardize, but different applications might want to handle them differently. I would characterize the two ideas as different, but very compatible, and thinking along the same general lines. What you have done with JAFOP could easily be a part of aXSL (or vice versa), and I would be glad to have you participate, when the appropriate time comes. Victor Mote
