--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Using
> a DOMSource and a SAXResult with an identity
> transformer. 

Do we already have an example for this one?  I'm not
sure of what you mean--are you saying that Manuel can
continue doing exactly what he's doing (slurping a FO
file into a DOM Tree, manipulating the tree by adding
RDBMS values to it, then sending the DOM Tree off to
FOP to be published) with what you mention above?

Also, under the hood, do you suspect that the identity
transformer is the same thing as our two classes?  I'm
far from an expert at this.

> On the
> other side, the two
> classes are perfectly usable and useful stand-alone
> outside of FOP.

I would guess those two classes are a dime a dozen,
probably in 100 articles and books.  But a non-FOP
user can always take the source code and incorporate
them in his/her program.

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.

> In the end I don't see what is gained by moving
> these two classes around
> and by reducing their visibility. 

My thinking:

We can get rid of them in the future, without worrying
about backwards compatibility.

We can move, rename, merge, modify them without
worrying about external use.

Fewer moving parts and fewer access paths means fewer
bugs and less confusion both on the FOP-USER list as
well as with developers.

Also, we're placing them precisely in the package, and
the only package, in which they're being called.  This
makes the packages less dependent on each other. 

But the visibility is actually less important to me
than the location.  If it would make you more
comfortable, I'm willing to make them public, but I
would prefer them to stay in apps.  (We can also wait
first until we get hate mail--exposing them is very
simple--but if we never get such mail we know they are
no longer needed.)

> It's simply a fact
> that many people
> still work with a DOM and I know a few programmers
> who are very hard to
> talk into adopting a different style of dealing with
> XML.

They won't need to--we will happily continue to be
supporting DOM Trees within FOP. Moving them to apps
also shows their first-class ranking alongside
XSLTInputHandler and FOInputHandler.


Reply via email to