[jdom-interest] SAX Parsers

[David W. Smiley]

Brett McLaughlin wrote:
...
> What? SAX 2 is a core part of JDOM's builders and outputters. And we
> supersede JAXP. In fact, future versions of JAXP will almost certainly
> include support for JDOM, as will the parser that makes its way into the
> JDK, it looks like. So we're right on target there.

So in conclusion, I won't use JAXP for the time being, but maybe once it
supports SAX2.

> > (2) I hoped to use JDom without Xerces.  Since JDom needs SAX2, I downloaded the SAX2
> > library.  http://www.megginson.com/SAX/Java/  However, my app won't run because JDom's
> > SAXBuilder class refers to:
> > org/xml/sax/ext/LexicalHandler
> > which is not in the SAX2 library.
> 
> Even once you get the SAX extensions (where LexicalHandler is), you
> can't use JDOM without a parser. SAX isn't a parser, it's an API, so you
> need a parser from somewhere. Xerces is the best, Project X works as
> well as Oracle V1 and V2.

	My point is that I wanted to use JDom without the Xerces library and I
was unsuccessful.  I understand, of course, that I'll need a parser;
it's just that I wanted to use another parser (Sun's) without having the
Xerces library around because JDom uses a few classes here and there in
Xerces.  This is not absolutely necessary, but I think JDom should not
tie itself to Xerces.  Is this recognized as a problem, and if so, what
is the solution?

> No - that requires users to know more than they need to about SAX, we
> had decided.

In my case I NEED to know about SAX because the default SAX handling
does not handle external entities the way I want it to.  I claim that if
the constructor I proposed is added, users will still not need to know
about SAX since they won't use that constructor.

>Setting an entity resolver, however, is something we will
> let you do, so that solves your problem nicely. We'll also let you set
> an Error Handler.

How will you let me do it then?  I would /really/ prefer my proposed
constructor instead of having the JDom API deal with concepts such as
entity resolvers.

> That's more than JAXP does, btw ;-) And you would
> still have to change system properties to use JAXP in the same way, so
> that doesn't offer you any better alternatives.

Great.

-- David Smiley
   The MITRE Corporation