Simon Kitching wrote:
Looking at this from the user point of view:I'm +1 for Option 3. The problem we have right now only apply when schema is in the picture. So we may ends up with 2 classes, one that contains the actual schema implementation (works with Xerces 2.1 and Crimson (for the dtd parts)), one for Xerces 2.3 and up.
Method setSchemaLocation(someURI) is valid, right? Users should be able to associate a single schema (in some schema language) with the document to be processed.
And setSchemaLocation(someURI) is valid, because (a) the user should be able to specify the language of their schema, and (b) there is a unique and well-known identifying URI for each schema language [well, I damn well hope so].
The problem is simply with the "feature" URI(s) used to communicate this information from the user to the parser.
So I think that neither setSchemaLocation nor setSchemaLanguage should be deprecated or removed; we simply need to find some reasonable way of implementing them.
Option 1:
Just put code like this into Digester.java:
if (isXercesParser(parser))
// enable the schema language specified by the user
// in a xerces-specific manner
else if (isCrimsonParser(parser))
// ...
else if (isSaxonParser(parser))
//
else // try the old JAXP way, ie the current implementation
Option 2: Factor the code out into a single class that holds the pseudo-code above.
PRO: tweaking the parser-setting code doesn't require updating Digester.java; keep "incidental" code out of main Digester code to keep Digester class understandable.
CON: an extra class
Option 3:
Factor the code out into a class per parser-type, possibly a factory class, etc.
PRO: "pure" OO design; adding or changing parser-specific code requires no alterations to non-related code. CON: proliferation of classes.
This is how jaxp compliant parser are supposed to react right now.
At the worst, we cannot recognise the parser, and the default JAXP approach results in an "unrecognised feature" exception being thrown by the parser.
I did 2, but I would have prefferred doing 3 :-). Now in Tomcat I have a lot of "if parser == Xerces then bla bla...." which is ugly and error prone. 1 seems too parser centric and I don't like infinite if statement ;-)
Have I missed something? If not, I would pick (in order) 2, 1, 3. (the main guiding principle being KISS....). This is basically what you have done with Tomcat, no?
Now choosing between 2 and 3, I think 2 will still be available even if we implement 3.
What do you think?
Thanks,
-- Jeanfrancois
See my patch above. The first schema implemenation I've submitted to the digester team was parser-independent, except it only works with Xerces 2.0.1, 2.0.2 and 2.1 (2.2 was completely broken...truss me I spend a fair amount of time finding it was broken :-( ). Xerces 2.3- Xerces 2.5 still suppors schema in a parser-independent way, except validating schema & DTD with the same parser is broken (and the jaxp spec is unclear about that part). If the majority of digester uses 2.1, the we are safe and we should not apply my patch. IMBW, but I think people use at least 2.3....
I agree it should be fixed somehow. You have pointed out a definite bug in the current setup...
Comments?
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]
