Andy Clark wrote:
>
> Edwin Goei wrote:
> > Did you all consider other schema languages? What if someone wanted to
> > use RelaxNG, for example? Not sure what the solution should be,
> > though. The downside to deriving another class is complexity.
>
> That's the whole point of the parser configuration framework
> so that people can do this exact thing (and more). Then you
> simply instantiate an appropriate API generator (DOMParser or
> SAXParser) with the new configuration.
Sorry for sounding ignorant... I was responding to the original question
that Neil posted which I though was: should we continue to derive
SchemaParserConfiguration from StandardParserConfiguration or combine it
with StandardParserConfiguration?
I read your reply as supporting a smart version of the combined
approach. I wanted to highlight the obvious point that this may make it
more difficult to implement other schema languages. It also makes XML
Schema in some way part of the StandardParserConfiguration.
An alternative would be this (current?) inheritance design:
StandardParserConfiguration (for only DTD validation)
|
+-- SchemaParserConfiguration (for XML Schema & DTD)
|
+-- RelaxNGParserConfiguration (for RelaxNG & DTD)
|
+-- XSDRNGSchemaConfiguration (for all above combined)
|
+-- OtherSchemaConfiguration (for other schema language & DTD)
This has the advantage of separating out the schema languages but has
the
downside of more classes. After thinking about it some more, I would
vote for this design.
There is a proposal to extend the JAXP 1.1 spec in a minor way to add
schema validation support. One approach would make the schema language
used for validation orthogonal to controlling validation itself. This
would not be backward compatible with the current behavior of Xerces
1.4.3, but I believe it is a better API design. (Currently, turning on
validation in Xerces 1.4.3 also turns on XML Schema validation.) In
this approach, assuming that namespaceAware is true, turning on
validation does not automatically set the schema language to XML Schema,
but keeps the schema language as DTD. A separate schemaLanguage
property would control which schema language is used for validation. If
this approach is taken, then the JAXP code could select which
*Configuration class to instantiate.
>
> Which leads me to think that maybe we should have a META-INF
> service description for which parser configuration the JAXP
> implementation instantiates. Then people could use Xerces2
> *and* substitute their configuration automatically by adding
> an appropriate Jar file w/ service description *before* the
> Xerces2 jar file.
>
> Thoughts?
See my note above on possible new additions to JAXP 1.1 spec.
-Edwin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
