Assertions on Complex Types
XSD 1.1 supports the definition of assertions on both simple and complex types.
Assertions enable cross-validation of different elements or attributes within a complex type. For example, specifying:<xs:assert test="xs:date(@date-of-birth) lt xs:date(@date-of-death)"/>
will cause a run-time validation error if an instance document is validated in which the relevant condition does not hold.
Saxon allows any XPath 2.0 expression to be used in the
This includes expressions that call Java or .NET extension functions. Support for XPath 3.0 or 3.1
can be configured using the configuration property
For assertions on complex types, the context node supplied to the expression is the
element being validated. The element being validated is presented as type
xs:anyType, but its attributes and children, because they have already
been validated, are annotated with their respective types. The static context for the
expression comes from the containing schema document: any namespace prefixes used in the
expression must be declared using namespace declarations in the schema in the usual way.
The default namespace for elements and types may be set using the
xpathDefaultNamespace attribute either on the element containing the
XPath expression, or on the
xs:schema element. It is not possible to use
any variables or user-defined functions within the expression.
For the purpose of generating diagnostics, Saxon recognizes an assertion of the form
empty(expr) specially. For example, if you are validating an XSLT
stylesheet, you might write on the top-level complex type
test="empty(if (@version='1.0') then xsl:variable[@as] else ())"/>. If you
use this form of assertion, the validator will not only report that the assertion is
false for the top-level element, it will also report the location of all the
xsl:variable elements that caused the assertion to be false. This also
not(expr) provided that
expr has a static item type
Another aid to diagnostics is the
saxon:message attribute: if present on
xs:assert element, this provides a message to be output when the
assertion is not satisfied: see saxon:message.
The XPath expression is evaluated against a temporary document that contains the subtree rooted at this element: more specifically, the subtree contains a document node with this element as its only child. Validation succeeds if the effective boolean value (EBV) of the expression is true, and fails if the EBV is false or if an error occurs during the evaluation.
If a complex type is derived by extension or by restriction, then the assertions supplied on the base type must be satisfied as well as those supplied on the type itself.
Note that when assertions are defined on a complex type, the subtree representing an element with that type will be built in memory. It is therefore advisable to exercise care when applying this facility to elements that have very large subtrees.
For assertions on simple types,
<xs:assertion> is treated as a facet.
It may be applied to any variety of type, that is to a type derived by restriction from
an atomic type, a list type, or a union type. The value against which the assertion is
being tested is available to the expression as the value of variable
$value; this will be typed as an instance of the base type (the type being
restricted). There is no context node. The variable
$value is also
available in the same way for complex types with simple content.