--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> > But FOP is not XML Commons, and IMO external users
> > should not be directly latching on to non-XSL
> portions
> > (i.e., not fonts or hyphenation, etc., things that
> we
> > are expected to share) of our code that way.  That
> > would limit our ability to
> modify/optimize/simplify
> > the code to provide a solid XSL implementation.
> 
> I'm not sure I understand this paragraph correctly.
> Does that mean that
> you will be against factoring out certain basic
> components from FOP into
> a separate area so they can be more easily reused by
> others and improved
> by people not really seeing through FOP's code
> forrest?
> 

No, what you're suggesting is the way I would propose
it.  In a typical case of reuse, code would be taken
out of FOP, sent to XML Commons or the XML Graphics
components, and imported back into FOP as a library. 
Possible exceptions are those "by definition" classes
that FOP should be exposing, by virtue of the type of
application it is.  As you can tell, I'm fuzzy on
this.  Let's discuss these on a case-by-case basis
after XML Graphics forms.

It's just our FOP infrastructure/internal code that I
wouldn't want users to be directly importing into
their apps:  that code is subject to change, renaming,
removal, etc.  

I judged the two classes in question to be more or
less just an internal implementation of how we were
handling things.  "import
org.apache.fop.apps/tools.DocumentReader" from user
code is not something I would want us to be supporting
in the future.  Supplying identity transform
alternatives is outside the scope of FOP; in the
unlikely event we ever get demand for these two
classes we can send those classes to XML Commons, so
the user can "import org.apache.xml.commons.xxxx"
instead.

Glen

Reply via email to