[jdom-interest] DOMBuilder

[Rosen, Alex]

> What DOM properties are you setting?  What SAX properties do
> you want to set?

I'm not sure what the difference is between these two, but here are the
features we're setting on the Xerces DOM parser:

parser.setFeature("http://xml.org/sax/features/validation", false);
parser.setFeature("http://apache.org/xml/features/continue-after-fatal-error",
false);
parser.setFeature("http://apache.org/xml/features/allow-java-encodings", true);

I don't know the specifics of why we use the second one, but the last one is
the killer. Many XML files we've found (e.g. some of the deployment descriptors
in Sun's PetStore sample app) use the Java encoding names. So we really need to
be able to set this.

> How do you address the concerns I raised?  Specifically, what
> should happen if you set a feature one way that SAXBuilder needs set the
> other way?  My concerns is we've been toggling how we do namespaces by
> changing the namespaces features, without any change to the
> public API. If we exposed the internals we'd lose that encapsulation.

Yup, I know... The problem is that there's no way to distinguish features that
are pretty well guaranteed to be JDOM-safe, now and forever (e.g.
allow-java-encodings) from those that are iffy (e.g. will
continue-after-fatal-error cause problems? dunno.) from those that will
definitely screw up JDOM (e.g. namespace features).

> BTW, remember you can write whatever builder you want.  We
> just provide two by default.

Yup. If this doesn't get changed in JDOM, I'm going to have to go this route.
That's annoying (to have to subclass the builder just to set a parser feature).
But I'm much more concerned about people using DOMBuilder instead, as other
people in my group have done, rather than taking the route you suggest. It is a
terrible waste if we unintentionally encourage people to use DOMBuilder rather
than SAXBuilder, just so they can turn on "allow-java-encodings", for example.

I would solve this problem by listing the common features/properties that are
expected to always be safe, and the ones that are known to be unsafe (or are
likely to be unsafe in the future). All others are use-at-your-own-risk. The
SAXBuilder that takes an XMLReader (or that has setProperty and setFeature)
could be a subclass of the regular SAXBuilder, if that would emphasize the
issue. It's simply a matter of what you think is the lesser of two evils.

In any case, I think SAXBuilder should have a protected getParser() method so
that this is possible to do via a subclass, rather than having to write a whole
new implementation.

--Alex