The "NNN validation errors were reported" message.
If a validation episode finds one or more invalidities, then at the end of validation, several things may happen:
(a) A summary message of the form
Error on line 1 column 60 XQDY0027 Two validation errors were reported. First error: ....
(b) An exception may be thrown
(c) When running from the command line, a return code may be returned to the shell.
Which of these actions is appropriate depends on what API was used to invoke validation. In some cases it is under our control, in other case we are expected to conform to the rules of an API such as JAXP. Unfortunately the JAXP API is very unclear on these things.
We addressed some of this in bug #5953, especially the question of the final exception.
Invalidity in general should not be treated as an error. However, when validation is invoked from XSLT or XQuery, any invalidity is a fatal error (and validation can stop as soon as a single error is found). In the JAXP interface, invalidity is reported by a callback to the supplied ErrorHandler, but it's a little vague as to which of its methods should be called: the consensus seems to be to call error().
There doesn't seem to be anything in any of the API specs to justify the final summary message (which is sent to the configuration's Logger, not to the registered ErrorHandler or InvalidityHandler). But perhaps it's useful when running from the command line?
It's worth remembering that many applications just want to confirm that the document is valid. Perhaps the s9api
SchemaValidator should have a simple way of asking that question without fiddling about with InvalidityHandler callbacks?
Updated by Michael Kay 6 months ago
Looking specifically at the s9api SchemaValidator, we say explicitly that
validate() throws an exception if the document is invalid, and that
validateMultiple() does not. I see no reason to change that. What we should change is notifying the summary message to an error reporter.
Let's look first at
validate(). Unit test TestValidator.testValidationReporting confirms that it is outputting the summary message and then throwing the exception. This comes from
ValidatingFilter.reportIfInvalid(). This constructs an exception and throws it. It is caught by
ReceivingContentHandler.endElement() which reports it to the errorReporter and then throws it (wrapped in a SAXException). We can suppress this by marking the exception as "hasBeenReported" in the ValidatingFilter`.
Now let's look at
validateMultiple(). The test
TestValidator.testValidationReporting3 also seems to be doing the right thing now. The validation errors are all reported to the invalidityHandler, and the summary message is not output either as an exception, or as a message to the reporter.
I'm committing these changes.
Please register to edit this issue