# Schema Processing

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.

Next