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