XML Schema 1.1 implementation

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.