Let me first quickly introduce myself. The compay I work for, Inventive
Designers, has a product called Scriptura, which is tool to work with XSLT
and XSL-FO. Scriptura consists of a WYSIWYG designer for XSL stylesheets,
and an Engine which does the processing (transformations, PDF generation
etc). It is written in Java. For more info, see
http://www.inventivedesigners.com/products/scriptura.html
We are using FOP right now, but a lot of customers are asking for suppor
tfor other XSL-FO formatters, which we encourage. However, right now we
have to make a module for each of these XSL-FO formatters to access them
using their proper APIs.
We see the need for a uniform (Java?) API to access all (Java?) XSL-FO
formatters, which ideally would become a part of the JAXP (Java APIs for
XML processing).
My opnion is that the Avalonized API does not qualify for a uniform API,
because of too much of the Avalon components would have to become a part of
this uniform API in order for it to be complete.
Do you guys see this Avalonized API as the one an only and best way to
access FOP, or are you interested in having a uniform API as well?
Do you see this uniform API sitting on top of the Avalonized API?
I must admit that I did not completely follow the discussion about the FOP
API, altough I browsed the archives. I couldn't find the final conclusion
on the decision to use the Avalon approach.
Best regards,
-----
Klaas Bals - Project Leader & Technical Designer
Inventive Designers
Direct Phone: +32 - 3 - 8210183
Office Phone: +32 - 3 - 8210170
Office Fax: +32 - 3 - 8210171
Email: [EMAIL PROTECTED]
"J.Pietschmann
" To: [EMAIL PROTECTED]
<j3322ptm@yaho cc:
o.de> Subject: FOP API proposal in FOP wiki
04/02/2003
01:36
Please respond
to fop-dev
Hi all,
I polished the FOP API proposal at
http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization
a bit. Everybody is invited to review and add content. The discussion
points are after the code near the end.
I think real discussion, with arguments and counterarguments, should
take place on the mailing list, and the Wiki should be used as a
whiteboard holding the facts and thoughts worth to remember.
If a discussion point from the wiki seems to be somewhat resolved on
the mailing list discussion, reformulate it and the associated
comments into appropriate sections, like code, DTD, renderer config
or rationales, then delete it and all associated comments rather
than keep it indefinitely in the wiki.
Please bolster arguments for adding stuff with appropriate use
cases, perhaps adding to the usage examples section.
I hope Keiron, Karen and Arved will surface for this discussion.
I'll also post an announcement on cocoon-dev.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
