Edwin Goei wrote:
>Glenn Marcy wrote:
>>
>> 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?
>
>I would say that the setValidation() method in JAXP refers to the
>definition of "validating" and "non-validating" processors in the XML
>REC. I believe, the SAX validation feature does also.
While you might like to say that, it would be wrong. There is nothing
in the XML spec that supports a notion of configuring an XML processor
to be "validating" or "non-validating". Section 5.1 states:
Conforming XML processors fall into two classes: validating and
non-validating.
There is nothing in the spec that mentions a processor being both.
Xerces is a validating processor. Also in Section 5.1 it states:
[Definition: Validating processors must, at user option, report
violations of the constraints expressed by the declarations in the
DTD, and failures to fulfill the validity constraints given in this
specification.]
The SAX validation feature is that option. The description of that
feature states:
validation controls whether the parser is reporting all
validity errors; if true, all external entities
will be read.
And the original description from the previous home of SAX:
http://xml.org/sax/features/validation
true: Report all validation errors (implies external-general-entities
and external-parameter-entities).
false: Do not report validation errors.
access: (parsing) read-only; (not parsing) read/write
All of these are clearly indicating that they control "reporting" of
validation errors, as supported by the XML spec. None of them say
anything about validating vs. non-validating processors, which is
also not mentioned in the XML spec.
>BTW, I'd like to more clearly state what I believe is a problem...
>
>The XML REC says that when a "validating processor" parses an instance
>doc w/o a doctypedecl, an error should be reported. SAX specifies that
>turning on the SAX validation feature causes the parser to be a
>"validating processor" (or throw an exception). Therefore the parser is
>required to report an error. However, currently in Xerces, XMLSchema
>validation is turned on by default, so if the instance doc does not
>contain a doctypedecl but instead contains a pointer to an XSD, then no
>error will be reported as required by the XML REC. Therefore, I believe
>this behavior is not XML REC conformant in this case.
>
>An easy fix for this would be to turn off XMLSchema validation by
>default.
You are correct to a point. As I just explained, the SAX feature does
not have anything to do with causing a parser to decide if it is a
validating one or not, it just controls error reporting. Otherwise,
you are correct, any XML document that does not have a <!DOCTYPE>
declaration is an invalid XML document w.r.t. the XML specification.
If the SAX validation feature is set to true then a conforming XML
processor is required to report that the document is invalid, and
it does not matter if there is a schema or not. The XML spec does
not have anything to do with schema. If you are a conforming
validating XML processor that is reporting validation errors then
you must have a DOCTYPE or an error will be reported. Any other
behavior is not conforming w.r.t. the XML spec.
As far as I can see, you cannot have validation set to true when
using schema validation and not expect to see validation errors
relating to the lack of a DTD grammar from a conforming validating
XML processor. This is obviously a significant problem.
>Glenn Marcy wrote:
>>
>> What does JAXP expect an XML processor to do when validation is false
>> if the processor still needs grammar processing information to function
>> properly?
>
>Not sure I understand this question. What is an example of "the
>processor still needs grammer processing information to function
>properly" when validation is false?
Setting validation to false will suppress reporting of validation
failures. Since you would not want to see such errors when validating
against a schema you must set validation to false. Therefore, there
still needs to be some feature to control the behavior of the schema
processor w.r.t. error reporting and infoset augmentations. You
cannot ursurp the feature that is already defined by the XML spec
to control reporting of DTD grammar related validation errors.
Regards,
Glenn
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
