> Shouldn't org.xml.sax.helpers.XMLReaderFactory be deprecated now when we
> have JAXP 1.1?
No. Remember that SAX2 does not depend on JAXP.
Among other things, that means that SAX2 can still be
used (and cleanly bootstrapped) in environments that
don't have (or need) DOM and XSLT support.
- Dave

> SAXParserFactory should be
> deprecated now that we have XMLReaderFactory. Sun jumped the gun on
> JAXP 1.0 and standardized on SAX1 and DOM1, in which classes like
> javax.xml.parsers.SAXParserFactory were actually necessary.
For SAX 1.0, that SAXParserFactory solved one problem: no way
to tell if the parser validated or not. And one annoyance: too many
exception exits from org.xml.sax.helpers.ParserFactory. For SAX2.0,
XMLReaderFactory doesn't have those problems.
SAX2 was almost finalized when the JAXP 1.0 process (belatedly)
completed, based on SAX1. It did seem odd that since JAXP 1.0
was so late, it didn't hold off just a bit longer. IMO that was a symptom
of a "community" process that didn't really reflect the community ... :)
> All the
> SAX parts of javax.xml.parsers are pointless now, and the DOM parts
> will be as soon as DOM3 gets going.
I'm not so sure. Certainly DOM is so extremely late getting any
bootstrapping APIs (and DTD support, and pruning "noise" nodes,
and ...) that a lot of code will use JAXP's more portable APIs.
They're clearly not going away.
- Dave

At 11:36 2002-02-08 -0800, David Brownell wrote:
>For SAX 1.0, that SAXParserFactory solved one problem: no way
>to tell if the parser validated or not. And one annoyance: too many
>exception exits from org.xml.sax.helpers.ParserFactory. For SAX2.0,
>XMLReaderFactory doesn't have those problems.
For SAX 1.0 and SAX 2.0, the JAXP 1.1 SAXParserFactory solves one problem:
give you good pluggability (using JAR services API) instead of clumsy
pluggability (using system properties). However, it seems like SAX 2.0.1
also have good plugability.