Re: [digester][review] New Schema supports

[Jeanfrancois Arcand]

Simon Kitching wrote:

Hi,

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?
 

Yes.

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
ContentHandler, 
* 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
 http://java.sun.com/xml/jaxp/properties/schemaSource 
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.

Thanks,

-- Jeanfrancois

Regards,

Simon



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]