Type assignment
Document nodes and element nodes can be explicitly validated against schema definitions with the validate instruction.
| ValidateExpr | ::= | validate SchemaMode? SchemaContext? { Expr } |
| SchemaMode | ::= | lax | strict | skip |
| SchemaContext | ::= | (context SchemaContextLoc) | global |
This includes that the respective type is assigned to the appropriate node, whereby default values for attributes also become effective. Because elements which are generated by element constructors are automatically subject to the validation, as it is defined for the whole query, the main application for validate is to change the validation terms for single nodes (for example to suppress).
However, validate can also be used in order to check whether an input document complies with the expected schema. Based on the validation modi which are introduced by XML Schema for its wildcards (any), XQuery knows the following validation modi:
| Validation mode | Meaning |
|---|---|
| strict | For all element and attribute nodes a schema definition must be known and all element nodes must correspond to it. |
| skip | A validation does not take place; all element nodes get the xdt:untypedAny type, all attribute nodes the xdt:untypedAtomic type. |
| lax | For all element and attribute nodes for which a schema definition is known, validation is done as with "strict", for all the others as with "skip". |
Table: List of the validation modi
As with the sequence types, there is the possibility to put the validation in a context in order to also allow the validation against local definitions. Alternatively, the global context can be indicated, which means that all required schema definitions have to be global definitions. When calling validate, the validation mode can be omitted each time.
In this case, the validation mode of surrounding validate expressions is inherited or, in case there is no such a thing, the validation mode of the total query. In the following example, the validation is explicitly switched off because the constructed element does not comply with the example schema. Without the call of validate, the result of the element construction would be validated against the schema, which would lead to a type error.
validate skip {<Doctor>
<Name>Ernst Miller</Name>
<Competence>emergency doctor</Competence>
</Doctor>}
Type assurance
In a complex XQuery expression it is not always apparent which type an expression has. This is often especially difficult for a XQuery implementation when analysing a XQuery. Therefore, in many cases it is necessary to refrain from a strict type testing when performing a static analysis of a query (which means an analysis without that the query is used on concrete data).
Such a testing is only possible at runtime. XQuery offers the treat as expression in order to improve this situation, but also to give the programmer of XQuery queries some language devices which make his queries more secure.
| TreatExpr | ::= | Expr treat as SequenceType |
With the help of treat as, an assurance via the type of an expression is done. In contrast to a cast, the type of the expression is not changed, but an error is generated, if the expression does not correspond to the indicated type. The following expression generates an error if the $d variable is not bound to an element of the Doctor_T type:
$d treat as element(*, Doctor_T)
Source: "XQuery – Grundlagen und fortgeschrittene Methoden", dpunkt-Verlag, Heidelberg (2004)
| << back | next >> |
