Within each phase, an implementation is free to use any strategy or algorithm whose result conforms to the specifications in this document.
[Definition: The static analysis phase depends on the expression itself and on the static context. The static analysis phase does not depend on input data (other than schemas).]
During the static analysis phase, the query is typically parsed into an internal representation called the operation tree (step SQ1 in Figure 1). A parse error is raised as a static error [err:XPST0003]. The static context is initialized by the implementation (step SQ2). The static context is then changed and augmented based on information in the prolog (step SQ3). If the Schema Aware Feature is supported, the in-scope schema definitions are populated with information from imported schemas. If the Module Feature is supported, the static context is extended with function declarations and variable declarations from imported modules. The static context is used to resolve schema type names, function names, namespace prefixes, and variable names (step SQ4). If a name of one of these kinds in the operation tree is not found in the static context, a static error ([err:XPST0008] or [err:XPST0017]) is raised (however, see exceptions to this rule in 3.2.7.2 Element Types and 3.2.7.3 Attribute Types.)
The operation tree is then typically normalized by making explicit the implicit operations such as atomization and extraction of effective boolean values (step SQ5).
During the static analysis phase, a processor may perform type analysis. The effect of type analysis is to assign a static type to each expression in the operation tree. [Definition: The static type of an expression is the best inference that the processor is able to make statically about the type of the result of the expression.] This specification does not define the rules for type analysis nor the static types that are assigned to particular expressions: the only constraint is that the inferred type must match all possible values that the expression is capable of returning.
Examples of inferred static types might be:
For the expression concat(a,b) the inferred static type is xs:string
For the expression $a = $v the inferred static type is xs:boolean
For the expression $s[exp] the inferred static type has the same item type as the static type of $s, but a cardinality that allows the empty sequence even if the static type of $s does not allow an empty sequence.
The inferred static type of the expression data($x) (whether written explicitly or inserted into the operation tree in places where atomization is implicit) depends on the inferred static type of $x: for example, if $x has type element(*, xs:integer) then data($x) has static type xs:integer.
In XQuery 1.0 and XPath 2.0, rules for static type inferencing were published normatively in [XQuery 1.0 and XPath 2.0 Formal Semantics], but implementations were allowed to refine these rules to infer a more precise type where possible. In subsequent versions, the rules for static type inferencing are entirely implementation-dependent.
Every kind of expression also imposes requirements on the type of its operands. For example, with the expression substring($a, $b, $c), $a must be of type xs:string (or something that can be converted to xs:string by the function calling rules), while $b and $c must be numeric.
A processor may raise a type error during static analysis if the inferred static type of an expression has no overlap (intersection) with the required type, and cannot be converted to the required type using the coercion rules. For example, given the call fn:upper-case($s), the processor may raise an error if the declared or inferred type of $s is xs:integer, but not if it is xs:anyAtomicType. A processor may raise a type error during static analysis if the inferred static type of an expression has no overlap (intersection) with the required type, and cannot be converted to the required type using the coercion rules. For example, given the call fn:upper-case($s), the processor may raise an error if the declared or inferred type of $s is xs:integer, but not if it is xs:anyAtomicType. A processor may raise a type error during static analysis if the inferred static type of an expression has no overlap (intersection) with the required type, and cannot be converted to the required type using the coercion rules. For example, given the call fn:upper-case($s), the processor may raise an error if the declared or inferred type of $s is xs:integer, but not if it is xs:anyAtomicType.
In addition, type analysis may conclude that an expression is implausible. Implausible expressions may be considered erroneous unless such checks have been disabled. This topic is described further in 2.4.6 Implausible Expressions.In addition, type analysis may conclude that an expression is implausible. Implausible expressions may be considered erroneous unless such checks have been disabled. For example, the expression round(tokenize($input)) is implausible because the required type for fn:round is xs:numeric?, while the static type of tokenize($input) is xs:string*, and these two sequence types are substantively disjoint. This topic is described further in 2.4.6 Implausible Expressions.In addition, type analysis may conclude that an expression is implausibleimplausible. Implausible expressions may be considered erroneous unless such checks have been disabled. For example, the expression round(tokenize($input)) is implausible because the required type for fn:round is xs:numeric?, while the static type of tokenize($input) is xs:string*, and these two sequence types are substantively disjoint. This topic is described further in 2.4.6 Implausible Expressions.
Alternatively, the processor may defer all type checking until the dynamic evaluation phase.