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
or by setting the configuration property XSD_VERSION to "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
(but not yet for
xpathDefaultNamespace attribute on
xs:schema is also recognized.
A model group defined with an
<xs:all> compositor may now have arbitrary
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
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
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
has a static item type of
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
attribute must be an XPath expression. The expression is evaluated with no context item, but with the variable
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.