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

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.

On 04.11.2004 22:58:39 Victor Mote wrote:
> Finn Bock wrote:
> > Do you mean that the 3 different processors should ideally 
> > report the same validation errors in the same manner? That 
> > can only happen after someone standardize a SAFO API (Simple 
> > API for FO parsing). Until then all implementation will throw 
> > different exceptions, which is fine by me.
> I actually toyed with this idea about two weeks ago. IIRC, the SAFO name is
> already taken, but at the time I registered the domain, and I
> finally went ahead yesterday and opened up a SourceForge project for it.
> There isn't much content there now, and I doubt that anyone wants to spend
> much time on it ATM, but we have a place to talk about such things for those
> who are interested -- I think Joerg at least will appreciate it being
> somewhere else, and I know there are others who are not interested as well.
> It deals with more than just parsing and exceptions, but those are (or could
> be) parts of it. Here is the website:
> If FOP is interested, you are welcome to send a delegate, who will
> automatically become a committer. Also, Peter West is welcome to be a
> committer -- if we can accommodate his design, we'll sure try. I'll
> eventually invite the commercial developers too, if it looks like there is
> anything here that helps.

Jeremias Maerki

Reply via email to