SAXONICA

Saxon Documentation
Full Contents
About Saxon
Changes in this Release
» | Version 9.1 (2008-07-02)
| Version 9.0 (2007-11-03)
Notices
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

# XML Schema 1.1

There is now a configuration flag to enable use of XML Schema 1.1 syntax; if this flag is not set, all new XML Schema 1.1 features will be disabled. The flag can be set using `-xsdversion:1.1` on the command line (of `Query`, `Transform`, or `Validate`), or by calling `configuration.setConfigurationProperty(FeatureKeys.XSD_VERSION, "1.1")`.

Conditional Type Assignment (often called co-constraints) is implemented. Any XPath expression may be used to define the condition, so long as it only accesses the attributes and namespaces of the element in question. Rules on type subsumption not yet implemented.

The xpathDefaultNamespace attribute is supported for both `xs:assert` and `xs:alternative` (but not yet for `xs:field` or `xs:selector`). The `xpathDefaultNamespace` attribute on `xs:schema` is also recognized.

A model group defined with an `<xs:all>` compositor may now have arbitrary `minOccurs` and `maxOccurs` values on the element particles within the group. Much more analysis is now done to determine whether a sequence of choice group is a valid restriction of a type that uses an `xs:all` compositor; some of this will also apply to XSD 1.0 schemas. For example, substitution groups are now taken into account, and the derived type is allowed to have an `xs:choice` content model (each branch of the choice must be a valid restriction of the base content model.)

Element wildcards (`<xs:any>`) are now allowed in an a model group defined using `<xs:all>`.

Local element and attribute declarations can now have a `targetNamespace` attribute, provided that they appear within an `xs:restriction` element that restricts a complex type. This makes it easier to define a restriction of a complex type that has been imported from another namespace, since it is now possible for the restricted type to declare local elements and attributes having the same names as those from the base type.

The reporting of validation errors on `xs:assert` has been improved: if the assertion takes the form `empty(expression)` then the validator will not only report an error if the result of the expression is not empty; it will also identify all the nodes (or atomic values) that were present in the result of the expression, enabling easier detection and correction of the problem. This also works for the expression `not(exp)` provided that `exp` has a static item type of `node()`.

Saxon 9.1 also allows assertions on simple types. The assertion is defined by means of an `xs:assert` element acting as a facet, that is, it is a child element of the `xs:restriction` child of the `xs:simpleType` element. This can be any kind of simple type (atomic, list, or union). The value of the `test` attribute must be an XPath expression. The expression is evaluated with no context item, but with the variable `$value` set to the typed value of the element or attribute. The assertion is satisfied if the effective boolean value of the expression is true. For example, for an atomic type that restricts xs:date, the assertion `<xs:assert test="$value lt current-date()"/>` indicates that the date must be in the past. For a list-valued type, the following assertion indicates that all items in the list must be distinct: `<assert test="count($value) eq count(distinct-values($value))"/>`. The XPath expression is allowed to invoke external Java functions, allowing full procedural validation logic. The XPath expression has access only to the value being validated, it cannot access any nodes in the document. For further details see Assertions on Simple Types.

Next