Elliotte Rusty Harold wrote:
In my opinion, JSR-173/StAX shouldn't be implemented in the Xerces
parser. It's a very different API that needs its own parsers, tuned
precisely for its model. Xerces is quite bloated as it is. I would
prefer not to have carry around StAX classes I don't want or need just
to use Xerces's excellent SAX parser (and vice versa). I would prefer
any Apache StAX implementation to be a separate project.
It's interesting that you mention this point because
I have put some thought into how to implement this
API efficiently in Xerces. Since XNI is based on a
push model, the conversion from push to pull at the
boundary induces buffering and degrades performance.
To overcome such a deficiency, the parser should
really be implemented as pull internally. However,
then we lose the modularity and configurability of
XNI. And trying to get that same level of modularity
from a purely pull parser greatly complicates the
implementation. Which is precisely why the Java pull
parsers I've reviewed are extreme subsets of full
XML parsers, without even DTD validation.
The only problem I see with your suggestion is what
it means for the application developer. Having a
separate implementation means different feature sets,
possibly different behavior, and different bugs to
deal with.
--
Andy Clark * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
