Jeremias Maerki <[EMAIL PROTECTED]> wrote: > But I think you have some fears because you know too little of Avalon.
Advertising
Well, thats nearly the core of the problem. Actually, in my case JAXP is the ultimate cause. We started using XSLT in a servlet using JAXP, which defines its own facilities for dealing with problem reports (ErrorListener and such), configuration data and various customizations. After some struggling we successfully plumbed it into the environment. Then there was the task to integrate FOP, which comes with yet another set of interfaces and other stuff to deal with problem reports and configuration data. It was to be expected that it wouldn't be the same as JAXP, but the relevant FOP/Avalon APIs are simply much too different from JAXP and noticable more complex. They may be superior to JAXP, but JAXP came first. If i learned something during some 5+ years of interface design, it is that users get very upset if they think something should follow a common pattern but it doesn't. If they have to do similar things they expect to be able to do it in a similar way. Having to learn new ways is nearly as repugnant to them as paying taxes, even if its obvious there will be a benefit somewhere down the road. It gets worse when developers have to tell their project managers they'll miss a deadline because they have to figure out another way of doing things they've already done in another context. Managers have a tendency to miss or ignore the "another context" part. This adds to the pressure. > We just > want to use a tiny part from Avalon where logging is concerned and an > embedder will not have to learn the Avalon way if he doesn't want to. Note that configuration is also an issue. Note further that files are also parts of an interface, however well hidden. I met a Batik developer at the xml/webservices conference this week, and discussed this problem shortly as it applies to Batik too. I hope some ideas will emerge for converging to a consistent and easy to use interface for various kinds of processors. Regards J.Pietschmann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
