Hi thanks for the quick response from everyone.
> Sounds reasonable to me--I think I should have done the validation > that way to begin with (IIRC =='s are Not Good with Strings anyway yes, I think so as well. Since String.equals() does the == check first anyways there shouldn't be a performance impact. Using intern() by FO internally might or might not be beneficial as mentioned. Upfront cost vs. saving memory and comparison effort. > I am personally pleased that FOP 1.0 is now activatible by directly > instantiating FOTreeBuilder, i.e. one can avoid the apps package > completely. This is because FOTreeBuilder now has all its needed > business logic within it. That was exactly my thinking - I'm planning to embed FOP as well as xsl-docbook. Going through apps.FOP forces me to package stuff that I don't really need since it seems to be designed around running it from the command-line (forcing dependencies to CommandLineOptions and the avalon stuff). So embedding something like the FOTreeBuilder that operates on the xsl level is more intuitive. > but FOTreeBuilder is within FOP's > "black box" and may not be available/could be renamed agreed but for an embedded solution that's a risk I'm willing to take :) It would be nice if the layer below apps.Fop was a public supported API actually. Thanks for considering that change Regards Nils
