Saxon

Legacy ID: #4877774 Legacy Poster: Michael Kay (mhkay)

I don't actually recognize this error message: if the element declaration is really absent from the schema, Saxon reports: Validation error on line 6 column 24 of file:/C:/MyJava/users/holtkamper/test.xml: In content of element <userarea>: No element declaration found for element <ns2:element2> (See http://www.w3.org/TR/xmlschema-1/#cvc-wildcard clause 2) Can you check that you are actually loading Saxon as your schema processor (print the class name of the factory after instantiation). What I get from Saxon with the two schema documents supplied is: Validation error on line 8 column 39 of file:/C:/MyJava/users/holtkamper/test.xml: The content "String!" of element <sub> does not match the required simple type. Cannot convert string "String!" to an integer (See http://www.w3.org/TR/xmlschema-2/#cvc-datatype-valid clause 1) Admittedly I haven't simulated your conditions exactly - I'm running from the command line and with a later development build. But I'd be grateful if you could check it before I investigate further. Michael Kay Saxonica

Legacy ID: #4888989 Legacy Poster: holtkamp (holtkamper)

Well, it turns out you are right, we were not using Saxon as a schema processor all along! After fixing this, the xml-schema files are combined and used properly during the validation process. However, we face two new problems now. 1. We are using an errorHandler as described in the SchemaValidatorHandlerExample.java, this works fine, only the validation process stops after Saxon throws the first exception. This exception is handled properly by the errorHandler: it invokes the fatalError() method. But it seems that this exception is also handed over to the parent application, which catches it and stops the validation process. How can we stop this, the errorHandler does not re-throw the exception or something... The specification of the errorHandler states that the parser is allowed to stop, but continuing the process is preferred in this case http://java.sun.com/javase/6/docs/api/org/xml/sax/ErrorHandler.html In our previous situation (where we used the com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory as a factory), a SEQUENCE of errors were gathered by our errorHandler and handed over to our parent application as intended. 2. We used the error codes as returned by xerces as a key identifier of the error message to be able to translate the error message, for example: cvc-complex-type.3.2.2: Attribute 'type' is not allowed to appear in element 'body'.Attribute 'type' is not allowed to appear in element 'body'. can be used to extract the code, message and assemble a translation: code: cvc-complex-type.3.2.2 message: Attribute 'type' is not allowed to appear in element 'body'. translated-message (Dutch): Attribuut $0 is niet toegestaan in element $1. Is it possible for saxon to return such error-messages including the codes as well?

Legacy ID: #4889151 Legacy Poster: Michael Kay (mhkay)

Saxon's implementation of ValidatorHandler is by default calling the error handler's fatalError() method when a validation error occurs, rather than the error() method. You can change this by setting schemaFactory.setProperty(FeatureKeys.VALIDATION_WARNINGS, Boolean.TRUE); I don't think that the JAXP API documentation says one action is correct and the other is not. Generally, trying to emulate Xerces/Xalan in areas where the JAXP specification says nothing is a losing battle, though they have a nasty habit of tightening up the spec at each release to make it match the Xerces/Xalan behaviour. In this case though I think it probably makes sense if I change the default setting. There's another difference, again not actually covered by the spec, which is that at the end of the document, if there have been one or more validation errors, it appears Xerces exits normally, whereas Saxon (even with the above property set) throws an exception. I'm not proposing to change this. Saxon doesn't include the error code as part of the output of getMessage() on the SAXException. The code is however available to the application: if you call getException() on the SAXException, the underlying exception will generally be an instance of net.sf.saxon.type.ValidationException. This has a number of methods such as getConstraintName(), getConstraintClauseNumber(), or getConstraintReferenceMessage() which refer you to the details of the error. Of course, the same error won't always result in the same constraint reference as Xerces produces, and if you're using these as a key for translation then you need to be aware that there can be many different messages associated with the same code.