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? 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. 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... 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. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
