commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeanfrancois Arcand <>
Subject Re: [digester][review] New Schema supports
Date Thu, 04 Dec 2003 18:13:06 GMT

Simon Kitching wrote:

>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.
Yes, look at my original proposal ;-) But we want to keep backward 
compatibility, and in order to supports it we need to better implement 
xml schema supports

>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...
No, that's the problem. All the schema validation will fail, and you 
have to bang your head to find why ( took a long time to figure that out 
for Tomcat). Even DTD validation will starts failling...

>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.
Agree, but my patch is trying to help the user (doesn't need to know 
anything about the how to turn schema validation, as he is used with 
DTD). He just need to do: digester.setValidation(true) and that's it.

>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? 
-1 ;-) This class should not contains hacks because Xerces is buggy and 
inconsistent between version.

>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.
That's a valid argument (This is exactly what I did in Tomcat)...but I 
think making life easier for the user is better, and hiding the XML 
schema complexity is a way to explore.


-- Jeanfrancois

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

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

View raw message