commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject re: [digester][review] New Schema supports
Date Fri, 05 Dec 2003 11:23:58 GMT

My first thoughts on this patch were that a lot of work has gone into
this - and a lot of code been created.

And all this is just in order to support the existing
Digester.setSchema(...) method which causes Digester to validate the
input XML against a schema while parsing, right?

I'm thinking that it would be better if Digester just didn't try to
support it at all. Instead, why not deprecate the setSchema method? If a
user wants schema validation, they can do any of the following:
* set up the parser themselves with the Digester set as the SAX
* call setProperty on the Digester to directly set the property on the
underlying parser, or
* call getParser on the Digester, then configure it appropriately.

I think that Digester should restrict itself to handling only parser
features which are portable across parsers, and push configuration of
any non-portable features back onto the user. It's a shame that xml
schema validation falls into this category, but Jeanfrancois' patch
shows it clearly does.

Alternatively, if people think this is really Xerces' fault for no
longer supporting the "standard" features 
etc. then why not just throw an exception if the user sets a schema and
the standard features are not supported by the parser? In fact, I
presume this is what currently happens...

Note that the issue of support for multiple parser types in a
"framework" like Digester is quite different from support in an
*application* (like Tomcat for example). The application definitely
needs to support multiple parsers because the user has no way of doing
any parser-specific configuration themselves. Digester is different
because someone is always writing code to integrate Digester into their
app anyway.

If people do see real value in having Digester support cross-parser
configuration for xml schema validation, then I would argue for a much
simpler "hard-wired" solution than this one (as suggested when this was
first discussed). Rather than have Factories etc., why not just
hard-code support for the "quirks" of xerces>2.1 directly into the
Digester class? If the user finds their parser is not supported they do
have a fallback: the options listed at the start of this email. These
options are just as simple as someone writing a separate Factory for
their parser type, and less baggage for Digester to be carrying around.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message