I'd like to make some research this evening (CET) to provide some more
thought-through comments. In the meantime I'd like to point out a few
- Thanks, Jörg, for starting this. I'm in favor of redesigning the API.
- I don't believe we will be able to finalize the API this week. There's
too much to think about.
- I'm not sure if we should change the API in the maintenance branch.
Breaking backwards-compatibility produces and deprecating old
interfaces and classes is not so popular, usually.
- Avalon scares some people. JAXP is a good example of a pretty good API
that is easy to use. I'm strongly for providing a simple API for easy
use that is as similar as possible with JAXP and has as little
dependencies on Avalon as possible (only exception: logging, I think).
On the other side, I'm strongly for using Avalon (what a surprise),
which means that the simple API IMO should be a wrapper around the
Avalon-based API. It should be relatively easy to hide the Avalon
- The simple API will (probably) not have all the possibilities of the
Avalon-based API, to keep things as simple as possible.
- We should gather some more requirements for the API and hold them in a
- We should provide easy integration into Cocoon preferably using some
of their components (resolver, parser factories etc.). Some of them
have been moved to Avalon Excalibur, so we don't have dependecies into
Cocoon, only Avalon. We probably have to work closely with the Cocoon
and Avalon people. This also reduces the common codebase and
maintenance effort and improves stability.
- If we go the two-API-way we have to decide what to provide in the
- I'd like to work more with MIME-types for specifying the output format
instead of subclassing a class for each output format. This may help
to reduce dependencies.
Ok, got to get back to work. More to come...
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Tel. +41 41 317 2020 - Fax +41 41 317 2029
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]