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
It is possible at various levels to request a validation report in XML format. This can be requested using the
-reportoption 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:valuevariable within the
A new option for schema processing has been added:
FeatureKeys.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
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.