XML Schema 1.0 implementation

The way in which validation errors are reported has changed:

• At the most primitive API level, the listener for validation errors no longer requires them to be reported as Java exceptions. Java exceptions are expensive, and the need to report each error in the form of an exception adds significantly to execution costs in the case where a large number of errors are expected. (For compatibility, however, it is still possible to use the JAXP ErrorListener interface.)

• It is possible at various levels to request a validation report in XML format. This can be requested using the -report option on the command line, or via settings in the s9api validation API. In addition, this becomes the default way validation errors are reported when validation is initiated from XSLT or XQuery within a try/catch block. In this situation (whether or not the catch clause is actually written to catch validation errors), all validation errors are recorded as part of an XML document, which is available to the application as the value of the $err:value variable within the catch clause.

A new option for schema processing has been added: IMPLICIT_SCHEMA_IMPORTS This disables the rule that it is not permitted for a schema document A to contain a reference to a schema component in namespace N unless document A contains an <xs:import> declaration for namespace N. Although the XSD specification imposes this rule, there are schemas in common use that do not conform to the rule, for example where A includes B and B imports N, but A does not import N directly.

The use of schema component models (compiled schemas in XML format) has been significantly expanded (though the format has not changed and existing SCM files are still accepted). SCM files are now accepted by most interfaces that accept a source schema, for example xsi:schemaLocation in a source document, and xsl:import-schema in a stylesheet. SCM files can now contain an embedded license key, allowing them to be used for validating source documents on a Saxon-EE configuration that does not have its own license.

Changes have been made to treat references to missing schema components, where possible, as a warning rather than an error, unless the missing component is actually used for validation. This implements a rule that is clearly stated in the XSD 1.0 and XSD 1.1 specifications, though many implementations ignore it. Saxon does not allow all references to be unresolved (for example, if a type is present then its base type must also be present), but common cases are handled, such as a reference in a complex type to an element that has not been declared.