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
> 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
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.