[jdom-interest] SAX Parsers
David W. Smiley
dsmiley at mitre.org
Thu Jul 20 08:52:46 PDT 2000
Brett McLaughlin wrote:
> > 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.
ProjectX is not SAX2, so I am not ready to go. I basically had to wrap
it in a dummy "Parser" class that came with SAX2 for bridging to SAX1
APIs to SAX2.
I thought that I could use ProjectX (implicitly through the default
behavior of JAXP) going through SAXBuilder. I chose SAXBuilder as
opposed to DOMBuilder because (1) I figure it is more efficient since it
would not go through the org.w3c.dom layer, and (2) I needed to disable
external entity resolving which is a SAX concept
[sorry if that paragraph is confusing, try reading slower]
So, if I want to use JDom's SAXBuilder with ProjectX without Xerces with
SAX2 and disable external entity resolving, I can't. This is my grand
problem. Since it looks like this won't be surmountable any time soon I
guess I'll go with Xerces.
> > > 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.
Bummer, ah well. Maybe you could configure the XMLReader passed in?
>If all you are doing is setting the entity
> resolver, what is so bad about setEntityResolver() in SAXBuilder?
Okay. So where is this mystery method? It is not in my distribution of
THANKS for these prompt responses.
-- David Smiley
The MITRE Corporation
More information about the jdom-interest