[jdom-interest] SAX Parsers

[Brett McLaughlin]

"David W. Smiley" wrote:
> 
> 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?

It isn't a problem, because it doesn't use Xerces specific classes,
ever, except through reflection. You can plug in Project X, and if it
has the SAX classes, you are ready to go.

> 
> > 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.

We don't want to let the user pass in an XMLReader because we lose an
enormous amount of ability to control the output, which is what
guarantees that JDOM behaves. If all you are doing is setting the entity
resolver, what is so bad about setEntityResolver() in SAXBuilder?

-Brett

> 
> > 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

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org