SAXONICA

Saxon Documentation
Full Contents
About Saxon
Changes in this Release
| Version 8.9 (2007-02-12)
| Version 8.8 (2006-09-05)
| Version 8.7.3 (2006-06-13)
| Version 8.7.2 (2006-04-19)
| Version 8.7.1 (2006-04-13)
| Version 8.7 (2006-02-24)
| Version 8.6.1 (24 November 2005)
» | Version 8.6 (3 November 2005)
| Version 8.5.1 (26 August 2005)
| Version 8.5 (2 August 2005)
| Version 8.4 (4 April 2005)
| Version 8.3 (11 February 2005)
| Version 8.2 (21 December 2004)
| Version 8.1.1 (8 October 2004)
| Version 8.1 (24 September 2004)
| Version 8.0 (1 June 2004)
Conditions of Use
Using XSLT 2.0
Using XQuery
Handling Source Documents
XML Schema Processing
XPath API for Java
Saxon on .NET
Extensibility
Saxon Extensions
Sample Saxon Applications
The Saxon SQL Extension
XSLT Elements
XPath 2.0 Expression Syntax
Function Library
Standards Conformance

# 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