There is one thing about all this that I am not clear on. What happens when validation is false? All of the discussion seems to assume that validation will be set to true, but that may not be the case. The SAX2 "validation" feature controls the reporting of validity constraint failures, it does not necessarily change the "nature" of the XML processor, and there is nothing in the XML spec that indicates that one should be able to do so. A validating XML processor may be the only processor that you have. Turning off validation just tells the processor not to report validation failures, it does not make the XML processor a non-validating one. Also, turning off validation does not turn off things like attribute value defaulting or normalization. A validating processor must still do those things.
What does JAXP expect an XML processor to do when validation is false if the processor still needs grammar processing information to function properly? Rajiv writes: >Ok I am the spec lead on this one and there is still time to fix this, but >please send comments asap on the proposal. The way it is supposed to work >as of now is that if anyone sets setValidating(true) and doesn't set the >schema language then DTD validation is on. If someone sets >setValidating(true) and also sets the schema language then it will use the >schema if available else will use the DOCTYPE declaration in the document >for validating using DTDs. On Tue, 11 Dec 2001, Edwin Goei wrote: > Elena Litani wrote: > > > > Edwin, > > > > Edwin Goei wrote: > > > Yes, currently, if you use JAXP and turn on validation (and > > > namespaceAware), this also turns on XML Schema validation. I agree with > > > Arnaud, that this probably isn't the best thing to do. I sent some > > > email regarding this issue and how it may be incompatible with future > > > JAXP API specs. I'd vote to change the behavior now before its use gets > > > too entrenched. > > > > Can you clarify? So in the new release of JAXP schema won't be > > automatically turned on? > > Thanks for bringing this up. I was about to myself. Probably, but I'm > not the spec lead. I think these issues need more discussion before > finalizing on the spec. Unfortunately, the spec is on a schedule so > there may not be time. > > > To turn on the schema support user must use > > "http://java.sun.com/xml/jaxp/properties/schemaLanguage"; property? > > If so, how can users specify: > > "My application receives documents that may include different grammars: > > some may include DTD, others may include XML Schemas. I want the parser > > to validate against the DTD if XML document has DTD, otherwise against > > XML Schema"? > > I think we need to discuss the different use cases: > > 1) app wants to validate to DTD as before. If no doctypedecl, then > error. > 2) app wants to validate to XSD. If no XSD association (either using > doc hint or programmatically) then error. > 3) app wants to validate to DTD or XSD, the case you state > 4) app wants to validate to both DTD and XSD. > 5) app wants to validate to RelaxNG > > I've tested with beta3 and read docs. I've tested w/ these instance > docs > A) w/ DTD only, B) w/ XSD only, C) w/ both D) w/ none > > It appears when both DTD and XSD validation is turned on the current > behavior approximates the DTD-or-XSD in the table below. The asterisk > means see comment in text. > > | Validation > Doc | DTD-only | XSD-only | DTD-or-XSD | DTD-and-XSD > ----+----------+----------+-------------+------------ > A | Valid | Valid* | Valid(DTD) | > B | Error | Valid | Valid(XSD) | > C | Valid | Valid | Valid(both) | > D | Error | Error | Error(XSD)* | > > Since XSD validation is on by default, use case #1 does not work for > type B docs, but this is easy to fix by changing the default value. > Case #2 does not work. (See Valid* in table.) Is this not a valid use > case? Case #3 seems to work except that I'd argue that the error should > come from the DTD validator since that is part of the fundamental XML > spec, or maybe both validators. Case #4 is not really supported. Is > there a reason to support use case #4? Are there apps that perhaps want > to use parameter entities and use XSD for validation? Case #5 is for a > future use case to keep in mind. There may be also other issues to > consider for the future like newer versions of XMLSchema. > > Comments welcome. > > -Edwin > > --------------------------------------------------------------------- > 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]
