On Tue, 2003-10-07 at 03:09, Jean-Francois Arcand wrote:
> Simon Kitching wrote:
>
> >On Sun, 2003-10-05 at 07:26, Jean-Francois Arcand wrote:
> >
> >Doesn't it really suck that there is no parser-independent way of
> >enabling w3c-standard xml schema support? Is everybody absolutely sure
> >there is no portable way to do this? [NB: I've had a look myself, and
> >this does indeed appear to be the case, though I'm not a JAXP guru].
> >
> I'm not absolutely sure (althrouth the solution I've implemented in
> Tomcat was with the help of the Xerces team). The current
> implementation will works fine with Xerces 2.1 and lower when you wan to
> validation both DTD and schema with the same digester instance. The
> curent implementation contains the "portable way" described in jaxp 1.2
> spec. For a reason I can't explain (I'm not following the Xerces dev
> list), they have changed the way they supports schema & DTD in version
> 2.3 to 2.5. I think the jaxp spec was unclear about validating both DTD
> and scheam with the same parser, and that's why we need to set those
> "unportable" property for now.
Can you describe what "the solution I've implemented in Tomcat" means?
The original "solution" you proposed for Digester was simply to rip out
all support for parser-independent setting of this feature, and force
the user to use parser-specific code. No criticism intended: if JAXP
doesn't provide a parser-independent way of enabling schema validation,
then it doesn't. However I wouldn't call this a "solution". Has
something different been implemented for Tomcat?
You also say "we need to set those unportable property for now". Does
this mean that the existing code might be restored in the near future?
> >>>maybe one solution might be to refactor the setting algorithm into a
> >>>separate class and then have factory methods for each parse type which
> >>>create instances that know how to execute the required configuration.
> >>>
> >>>
> >>+1
> >>
> >>
> >
> >Sounds good to me provided everyone is sure there isn't a
> >parser-independent way to do this.
> >
> >Can this solution be generalised to handle setting of parser-dependent
> >features other than just schema language?
> >
> You can do it actually by calling digester.setFeature or
> digester.setProperty. Is that what you means?
No. Robert is proposing some kind of encapsulation. I'm not entirely
sure what he is implying, but I think it is something like this:
public interface ParserFeatureSetter {
public void enableSchemaValidation();
}
with concrete classes for each different parser implementation, and some
kind of factory to create the correct concrete class.
I'm just thinking what other methods could exist on this interface, ie
what other facilities parsers provide that
If setFeature has a JAXP-defined url for a feature, I consider this
"parser-independent". However in many cases behaviour X is available in
many/all parsers but requires a different feature "uri", requiring the
calling code to be parser-dependent. Adding these common features as
methods on the above interface would allow the calling code to be
parser-independent again.
Robert, if I've misunderstood your suggestion, please let me know.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
