A bit late to react but I'm not 100% happy with moving the two classes into apps. I was a bit surprised at the time you introduced the DOM example because the same functionality could be provided via JAXP: Using a DOMSource and a SAXResult with an identity transformer. The examples were meant to show best practices by using widely known APIs. FOP's direct support for DOM predates JAXP and, today, is presented to our users as a convenience only (my opinion). On the other side, the two classes are perfectly usable and useful stand-alone outside of FOP.
In the end I don't see what is gained by moving these two classes around and by reducing their visibility. 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. On 04.07.2004 22:23:17 Glen Mazza wrote: > Team, > > We allow--and have for many years--for input > processing of FO documents in the form of DOM trees. > Several months back I created an example [1] of a > "Hello World" FO document to show how this > functionality might be used. > > The (well-written) classes which provide this > functionality, tools.DocumentReader and > tools.DocumentInputSource [2], date to March 2001 when > it was factored out of code in Apps.Driver. The > original code in Driver that provided this > functionality predates 2000, when original author > James Tauber was coding FOP [3]. > > But does anyone generate FO documents via DOM Trees > anymore? This style of coding appears to come from > the days that SAX wasn't as well known as DOM. The > example I gave would be very cumbersome and > hard-to-maintain for any non-trivial sized FO > document. Although one potential use could be reading > an FO file into a DOM Tree, navigating the tree, and > manipulating its values, it would appear the standard > today in these cases would be to just use xsl:param > and setParameter() as here [4]. > > If this style of coding is obsolete, I would like to > remove this functionality from our API in HEAD--we can > return it back fairly easily if we start getting hate > mail as FOP 1.0 solidifies and gets more use. In > addition to removing the two classes above, it would > also allow me to simplify/streamline apps.Driver a bit > more, and I can also remove my example given on the > Embed page. Jeremias Maerki
