| SAXONICA |
Saxon now makes consistency checks to ensure that that the schema used to validate a source document is the same as the schema used to compile a stylesheet or query. In particular, once a loaded schema has been used to validate a source document, or to compile a stylesheet or query, further changes to the definitions in that schema are prevented. The check is implemented at the namespace level. Specifically, once a schema namespace has been "sealed" by virtue of being used for validation or query/stylesheet compilation, this prevents three operations: adding elements to the substitution group of an element in that namespace; deriving a complex type by extension from a type in that namespace, and using xs:redefine to modify definitions in that namespace. The scope for these consistency checks is a Configuration; changes in a different Configuration are always possible.
The checks do not currently handle validated documents saved to disk in PTree format: here it remains the user's responsibility to ensure that the schema used when building the document is the same as the schema loaded when it is used.
Saxon was not previously making the check defined in Schema Part 1, section 4.2.2, Schema Representation Constraint: Redefinition Constraints and Semantics, clause 7.2.2, which states that when an attribute group is redefined (using <xs:redefine>) and contains no self-reference, the new definition must be a valid restriction of the old. This check is now in place.
Similarly, Saxon was not previously making the check defined in Schema Part 1, section 4.2.2, Schema Representation Constraint: Redefinition Constraints and Semantics, clause 6.2.2, which states that when a named model group is redefined (using <xs:redefine>) and contains no self-reference, the new definition must be a valid restriction of the old. This check is now in place.
Attributes in the xsi namespace (xsi:type, xsi:nil, etc) are now given
their correct type annotations when a document is validated. In the case of xsi:schemaLocation this
is an anonymous type representing a list of xs:anyURI values.
If the content model for an element includes an <xs:any> wildcard with processContents="lax",
and an instance of that element contains a child element with an xsi:type attribute, Saxon was
failing to validate the child element against the type specified in its xsi:type. This has now
been fixed.
In evaluating an xs:key constraint, Saxon now reports an error if a value defined in such
a constraint is validated against an element declaration specifying nillable="true".
Saxon now allows an xs:keyRef constraint to reference an xs:key in an imported
namespace.
There have been considerable improvements (bug fixes) in the handling of xsi:type, especially
when it appears on the outermost element subjected to a validate{} expression in XQuery or the equivalent
in XSLT.
