 error handling and conformance. It contains a new grammar in which the precedence of operators is explicitly represented. It introduces two new operators (
unordered and
idiv), and deletes four operators (
assert,
precedes,
follows, and
=>). It also describes changes to the detailed semantics of
cast expressions and other operators, as summarized in H Revision).
Patent disclosures relevant to this specification may be found on the XSL Working Group's patent disclosure page at.
1 Introduction
2 Basics
2.1 Expression Context
2.1.1 Static Context
2.1.2 Evaluation Context
2.2 Input Functions
2.3 Expression Processing
2.3.1 Document Order
2.3.2 Typed Value and String Value
2.4 Types
2.4.1 Type Checking
2.4.2 SequenceType
2.4.3 Type Conversions
2.4.3.1 Atomization
2.4.3.2 Effective Boolean Value
2.4.3.3 Fallback Conversions
2.5 Errors and Conformance
2.5.1 Errors
2.5.2 Conformance
2.5.2.1 Basic XPath
2.5.2.2 Schema Import Feature
2.5.2.3 Static Typing Feature
2.5.3 Handling Dynamic Errors
3 Expressions
3.1 Primary Expressions
3.1.1 Literals
3.1.2 Variables
3.1.3 Parenthesized Expressions
3.1.4 Function Calls
3.1.5 Comments
3.2 Path Expressions
3.2.1 Steps
3.2.1.1 Axes
3.2.1.2 Node Tests
3.2.2 Predicates
3.2.3 Unabbreviated Syntax
3.2.4 Abbreviated Syntax
3.3 Sequence Expressions
3.3.1 Constructing Sequences
3.3.2 Combining Sequences
3.4 Arithmetic Expressions
3.5 Comparison Expressions
3.5.1 Value Comparisons
3.5.2 General Comparisons
3.5.3 Node Comparisons
3.5.4 Order Comparisons
3.6 Logical Expressions
3.7 For Expressions
3.8 Conditional Expressions
3.9 Quantified Expressions
3.10 Expressions on SequenceTypes
3.10.1 Instance Of
3.10.2 Cast and Treat
3.11 Validate Expressions
A Grammar
A.1 Lexical structure
A.1.1 Syntactic Constructs
A.1.2 Lexical Rules
A.2 BNF
A.3 Precedence Order 16 Aug 2002
H.2 10 Apr 2002
H.3.
The library of functions and operators supported by XPath is defined in [XQuery 1.0 and XPath 2.0 Functions and Operators].
This document specifies a grammar for XPath, using the same Basic EBNF notation used in [XML], except that grammar symbols always have initial capital letters. Unless otherwise noted, whitespace is not significant in the grammar. Grammar productions are introduced together with the features that they describe, and a complete grammar is also presented in the appendix [A Grammar].
In the grammar productions in this document, nonterminal symbols are underlined and literal text is enclosed in double quotes. Angle brackets are used to enclose tokens that must be recognized by using lexical look-ahead, as described in A.1 Lexical structure. For example, the following production describes the syntax of a function call:
The production should be read as follows: A function call consists of a QName followed by an open-parenthesis (these tokens must be recognized together using lexical lookahead.) The open-parenthesis is followed by an optional argument list. The argument list (if present) consists of one or more expressions, separated by commas. The optional argument list is followed by a close-parenthesis.
.
The value of an expression is always a sequence, which]. Each node has a unique node identity. type exception is treated as an error.. It may also include types declared in schemas associated with documents retrieved by input functions, as described in 2.2 Input Functions.
Ed. Note: The importing of type definitions from input documents is still under discussion. The idea that the static context should be affected by run-time functions in an implementation-defined way remains controversial (see Issue 307.)
In-scope variables. This is a set of (QName, type) pairs. It defines the set of variables that have been declared and are available for reference within the expression. The QName represents the name of the variable, and the type represents its static data type.
In-scope functions. This part of the static context defines the set of functions that are available to be called from within an expression. Each function is uniquely identified by its QName and its arity (number of parameters). The static context maps QName and arity into a function signature, which three components of the dynamic context (context item, context position, and context size) predicate expression, or
E1
xf, or
E1[E2] is evaluated, the context size in the inner focus for an
evaluation of
E2 is the number of items in the sequence obtained by evaluating
E1. the value
an implementation-defined point in time during processing of a query or transformation. It can be retrieved by the
xf:current-date,
xf:current-time, and
xf:current-dateTime functions. If invoked multiple times during the execution of a query or transformation,
these functions always returns a consistent result.
Implicit timezone. This is the timezone to be used when a date, time, or dateTime value that does not have a timezone is used in a comparison or in any other operation. This value is an instance of dayTimeDuration that is implementation-defined. See [ISO 8601] for the range of legal values of a timezone.
Input sequence. The input sequence is sequence of nodes that can be accessed by the
input function. It might be thought of as an "implicit input". The content of the input sequence is determined in an implementation-defined way.
XPath has three functions that provide access to input data. These functions are of particular importance because they provide a-defined., which takes no parameters, returns the input
sequence. For example, the expression
input()//customer returns
all the
customer elements that are descendants of
nodes in the input sequence. If no input sequence has been bound,
the
input function raises a dynamic error..
The input functions described in this section provide access to input documents or document fragments. If these documents or document fragments are associated with schemas, the type definitions contained in these schemas may be added to the in-scope schema definitions, in an implementation-defined way.
Ed. Note: The importing of type definitions from input documents is still under discussion. The idea that the static context should be affected by run-time functions in an implementation-defined way remains controversial (see Issue 307).
XPath is defined in terms of the [XQuery 1.0 and XPath 2.0 Data Model] (referred to in this document simply as the Data Model), which represents information in the form of nodes and atomic values. has an annotation that indicates its dynamic type. If the Data Model was derived from an input XML document, the dynamic types of the elements and attributes are derived from schema validation. The dynamic type of an element or attribute indicates its range of values--for example, an attribute named
version might have the dynamic type
xs:decimal, indicating that it contains a decimal value.
The value of an attribute is represented directly within the attribute node. An attribute node whose type is unknown (such as might occur in a schemaless document) is annotated with the dynamic type
xs:anySimpleType.
The value of an element is represented by the children of the element node, which may include text nodes and other element nodes. The dynamic type of an element node indicates how the values in its child text nodes are to be interpreted. An element whose type is unknown (such as might occur in a schemaless document) is annotated with the type
xs:anyType.
Atomic values in the Data Model also carry dynamic description of how each kind of expression.
The terms document order, typed value, and string value are described here because they are of particular importance for the processing of expressions.
Document order defines a total ordering among all the nodes seen by the language processor. Within a given document, the document node is the first node, followed by element nodes, text nodes, comment nodes, and processing instruction nodes in the order of their representation in the XML form of the document (after expansion of entities). Element nodes occur before their children. The namespace nodes of an element immediately follow the element node, in implementation-defined order. The attribute nodes of an element immediately follow its namespace nodes, and are also in implementation-defined order.
The relative order of nodes in distinct documents is implementation-defined but stable within a given query or transformation. In other words, given two distinct documents A and B, if a node in document A is before a node in document B, then every node in document A is before every node in document B. The relative order among free-floating nodes (those not in a document) is implementation-defined.
Element, attribute, and text nodes have a typed value and a string value that can be extracted by calling the
data function and the
string function, respectively. The typed value of a node is a sequence of atomic values, and the string value of a node is a string. Element and attribute nodes also have a type annotation, which is a QName that is defined in the in-scope schema definitions.
The typed value and string value for each kind of node are defined by the
dm:typed-value and
dm:string-value accessors in [XQuery 1.0 and XPath 2.0 Data Model]. Specifically:
The typed value of a text node is the same as its string value, as an instance of
xs:anySimpleType.
If the type annotation of an attribute node is
xs:anySimple].
Example: A2 is a validated attribute with type annotation
IDREFS, which is a list type derived from
IDREF. Its string value is "
bar baz faz". The typed value of A2 is a sequence of three atomic values ("
bar", "
baz", "
faz"), each of type
IDREF.
If the type annotation of an element node is
xs:any]. If the type annotation of an element denotes a type with complex content (i.e., a type that permits subelements), its typed value is undefined, and the
data function raises an error when applied to such an element.
Example: E2 is a validated element node with the type annotation
hatsizelist, which is a complex type whose content is defined as a sequence of items of type
hatsize, which in turn is derived from
xs:integer. The string value of E2 is "
7 8 9". The typed value of E2 is a sequence of three values (
7,
8,
9), each of type
hatsize.
Example: E3 is a validated element node with the type annotation
weather, which is a complex type that permits subelements. The string value of E3 is "
hot". Even though E3 does not happen to contain any subelements, its typed value is undefined because its type permits subelements.f:dayTimeDuration and
xf exception is raised. Languages that are based on XPath 2.0 may handle type exceptions with either a
strict or a
flexible policy, as described in 2.4.3.3 Fallback Conversions.
Like XML Schema, XPath distinguishes named types from anonymous types. The set of named types includes all the built-in types and all user-defined simple or complex types for which the type declaration contains a name. For example, named types may defines two phases of processing called the analysis phase and the evaluation phase.
The analysis phase depends on the query expression itself and on the static context. The analysis phase does not depend on any input data. The purpose of type-checking during the analysis phase is to provide early detection of type errors and to compute the type of a query result.
During the analysis phase, type error is raised. If static type checking raises no errors and assigns a static type T to an expression, then execution of the expression on valid input data is guaranteed to produce either a value of type T or to raise a dynamic type error.
The evaluation phase is performed only after successful completion of the analysis phase. The evaluation phase depends on input data, on the expression being evaluated, and on the evaluation context. During the evaluation phase, a dynamic type is associated with each value as it is computed. The dynamic type of a value may be either a structural type (such as "sequence of integers") or a named type..
It is possible for analysis of an expression to raise a static type error, even though the expression might evaluate successfully on some valid input data. For example, an expression might contain a function that requires an element as its parameter, and the analysis phase might infer the static type of the function parameter to be an optional element. In this case, a static type error would result, even though the function call would be successful for input data in which the optional element is present.
It is also possible for an expression to raise a dynamic error, even though analysis of the expression raised no static error. For example, an expression may contain a cast of a string into an integer, which is statically valid. However, if the actual value of the string at run time cannot be cast into an integer, a dynamic error will result. Similarly, an expression may apply an arithmetic operator to a value extracted from a schemaless document. This is not a static error, but at run time, if the value cannot be successfully cast to a numeric type, a dynamic error will be raised.
If an implementation can determine by static analysis that an expression will necessarily raise a dynamic error (for example, because it attempts to construct a decimal value from a constrant string that is not a valid decimal value), the implementation is allowed to report this error during the analysis phase (as well as during the evaluation phase). that has a specific name and that has been validated as conforming to the schema definition for that name
element of type
po:address+ refers to one or more elements that have been validated as conforming to the schema definition atomic value
1 or the element
 an atomic type derived from
xs:decimal.
untyped constraint that an element must have a required name is considered to be satisfied if the element has been validated and found to be a member of a substitution group whose head element has the required name. Substitution groups are described in [XML Schema].
The above two forms of ElemOrAttrType may be combined to specify both the required name and the required type of an element or attribute node, as in
element person of type Employee or
attribute color of type xs:integer. This form might be used, for example, to specify a required type that is more specific than the schema type associated with the required name. 3.1.4 Function Calls. Other operators that provide special conversion rules include arithmetic operators, which are discussed in 3.4 Arithmetic Expressions, and value comparisons, which are discussed in 3.
Atomization may be used in processing the following types of expressions:
Arithmetic expressions
Comparison expressions
Function calls and returns
Cast expressions
If a sequence of items is encountered where a boolean value is expected, it is necessary to find its effective boolean value. The effective boolean value of a sequence is defined as follows:
If the sequence is empty, its effective boolean value is
false.
If the sequence contains a single atomic value of type
xs:boolean, this value is the effective boolean value of the sequence.
If the sequence contains at least one node, its effective
boolean value is
true.
In any other case, a type exception is raised.
The effective boolean value of a sequence may be computed during the processing of the following types of expressions:
Logical expressions (
and,
or)
The
xf:not function
Conditional expressions (
if)
Quantified expressions (
some,
every)
The action taken when a type exception is
raised depends on the language environment in which the XPath expression is
being evaluated. A language environment may choose either a
strict or a
flexible type exception policy. If the policy is
strict, a type exception is treated as
a dynamic, a dynamic, a dynamic error is.
Ed. Note: This section has been approved by the XML Query Working Group but is still being discussed by the XSLT Working Group. Some changes in XPath syntax and/or semantics may result from these discussions.
As described in 2.4.1 Type Checking, XPath defines an analysis phase, which does not depend on input data, and an evaluation phase, which does depend on input data.
The result of the analysis phase is either success or one or more static errors. Some static errors are static type errors, which occur when the static type of an expression is not correct for the context in which it appears. The term static errors also includes non-type-related errors such as syntax errors. The means by which static errors are reported is implementation-defined.
The result of the evaluation phase is either a result value or a dynamic error. Some dynamic errors are dynamic type errors, which occur when the dynamic type of an expression is not correct for the context in which it appears. The term dynamic errors also includes non-type-related dynamic errors such as numeric overflow. If an implementation returns a value, the value must conform to the dynamic rules defined in [XQuery 1.0 Formal Semantics].
[XQuery 1.0 Formal Semantics] defines the set of static and dynamic errors. In addition to these errors, an XPath implementation may raise implementation-defined warnings, either during the analysis phase or the evaluation phase. The way in which warnings are raised and handled is implementation-defined.
X
implementation, the in-scope schema
definitions consist of a fixed set of 48 predefined type definitions. These
include the 44 built-in datatypes defined in [XML Schema], plus four
additional types:
xf:yearMonthDuration,
xf:dayTimeDuration,
xs:anySimpleType, and
xs:anyType.
A mapping from a Post-Schema Validation Infoset (PSVI) to the Query Data Model is specified in [XQuery 1.0 and XPath 2.0 Data Model]. In a Basic XPath implementation, this mapping maps each datatype that is not one of the 48 predefined types listed above into its nearest supertype that belongs to this list. As a result of this mapping, all complex types are mapped into
xs:anyType. (Of course, mapping from a PSVI is only one way in which a Query Data Model instance might be constructed--other ways are also possible.)
If any SequenceType contains an AtomicType that is not one of the 48 predefined types listed above, a Basic X static. An implementation that includes this feature is required to detect static type errors. If an expression contains one or more static errors, including static type errors, then a Static Typing implementation must raise at least one of these static errors during the analysis phase.
Ed. Note: The Working Group is currently discussing the relationships among the various XPath features (for example, if an expression executes successfully on an implementation with Feature A, will it also execute successfully on an implementation with Feature B?). The Working Group is also discussing the issue of "type soundness" (that is, if the Static Typing Feature is implemented and a given expression raises no static errors, what guarantees can be made about its behavior during the evaluation phase?). The editors expect to include more material on these issues in a future version of this document. (See Issue 308.)
Except as noted in this document, if any operand of an expression
raises a dynamic error, the expression also raises a dynamic error.
If an expression can validly return a value or raise a dynamic
error, the implementation may choose to return the value or raise
the dynamic error. For example, the logical expression
expr1 and expr2 may return the value
false
if either operand returns
false,
or may raise a dynamic error if either operand raises a dynamic
error.
If more than one operand of an expression may raise an error, the implementation may choose which error is raised by the expression. For example, in this expression:
($x div $y) + xsd:decimal($z)
both
($x div $y) and
xsd:decimal($z) may
raise an error. The
implementation may choose which error is raised by the "
+"
expression. Once one operand raises an error, the implementation is
not required, but is permitted, to evaluate any other operands.
A dynamic error carries an error value, which may be a single item or an empty sequence. For example, an error value might be an integer, a string, a QName, or an element. An implementation may provide a mechanism whereby an application-defined error handler can process error values and produce diagnostics; in the absence of such an error handler, the string-value of the error value may be used directly as an error message.
A dynamic error may be raised by a built-in
function or operator. For example,
the
input function raises an error if the input
sequence is not
defined in the evaluation context.
An error can be raised explicitly by calling the
xf:error function,
which only raises an error and never returns a value.
The
xf:error function takes an optional item as its parameter, which is used as the error value. For example, the following function call raises a dynamic error
whose error value is a string:
xf:error(xf:concat("Unexpected value ", $v))
This section introduces each of the basic kinds of XPath simplest kinds of expressions are introduced first, followed by more complex expressions. This order of presentation does not conform to the order of operator precedence. The complete grammar is presented in the appendix [A Grammar].
The highest-level kind of expression is.. If the literal is delimited by single quotes, two adjacent single quote characters within the literal are interpreted as one single quote character. Similarly, if the literal is delimited by double quotes, two adjacent double quote characters within the literal are interpreted as one double quote character.
If a string literal is used inside the value of an attribute, the quote characters used to delimit the literal should be different from the quote characters that are used to delimit the attribute..
The boolean values
true and
false can be represented by calls to the built-in functions
xf:true() and
xf:false(), respectively.
Values of other XML Schema built-in types can be constructed by calling the constructor for the given type. The constructors for XML Schema built-in types are defined in [XQuery 1.0 and XPath 2.0 Functions and Operators]. In general, the name of a constructor function for a given type is the same as the name of the type (including its namespace). For example:
xs:integer("12") returns the integer value twelve.
xs:date("2001-08-25") returns an item whose type is
xs:date and whose value represents the date 25th August 2001.
xf:dayTimeDuration("PT5H") returns an item whose type is
xf:dayTimeDuration and whose value represents a duration of five hours.
It is also possible to construct values of various types by using a
cast expression. For example:
cast as
hatsize(9) returns an item whose primitive value is the integer 9 and
whose type is the user-defined type
hatsize, derived from
xs:integer.
A variable evaluates to the value to which its name is bound in the evaluation context. An expression containing an unbound variable raises a static error. Variables can be bound by clauses in for expressions and quantified expressions. 3.3.1 Constructing Sequences.
A function call consists of a QName followed by a parenthesized list of zero or more expressions, called arguments. The QName and number of arguments must match the name and arity of an in-scope function in the static context (see 2.1 Expression Context); raises a dynamic type error. If the atomic value has a type that can be promoted
to the required type using the promotion rules in B.1 Type Promotion,
the promotion is done.
If the required type is a sequence or optional occurrence of AtomicType:
If the given value contains any nodes, these nodes are replaced by their typed values. Each item is converted to the required AtomicType using the conversion rule for AtomicType.
If the required type is any other SequenceType, or if no required type is declared:
No conversion is performed.
If the Static Typing Feature is implemented, and the static type of a (converted) function argument or result, as inferred by the static type inference rules in [XQuery 1.0 Formal Semantics], is not a subtype of the required type, a static type error is raised. If the Static Typing Feature is not implemented, and the dynamic type of a (converted) function argument or result does not match the required type according to the rules for SequenceType Matching, a dynamic type error is raised. 3.3.1 Constructing Sequences). To distinguish these two uses, parentheses can be used to delimit the individual arguments of a function call. Here are some illustrative examples of function calls:.
one-argument-function(( )) denotes a function call with one argument that is an empty sequence.
zero-argument-function( ) denotes a function call with zero arguments.
XPath comments can be used to provide informative annotation. These comments are lexical constructs only, and do not affect the processing of an expression.
Comments may be used before and after major tokens within expressions . grammar is organized around the precedence of operators, the syntax for PathExpr also includes PrimaryExpr. In common usage, the term path expression denotes a PathExpr that is not simply a PrimaryExpr.
A path expression consists of a series of one or more steps, separated by "
/", and optionally beginning with "
/" or "
//". An initial "
/" or "
//" is an abbreviation for one or more initial steps that are implicitly added to the beginning of the path expression, as described below.
A path expression consisting of a single step is evaluated as described in 3.2.1 Steps.
In a path expression consisting of two or more steps, each occurrence of
// is expanded as described in 3.2.4 Abbreviated Syntax, leaving a sequence of steps separated by
/. This sequence of steps is then evaluated from left to right. Each operation
E1/E2 is evaluated as follows: Expression
E1 is evaluated, and if the result is not a sequence of nodes, a dynamic error is raised. The resulting sequence of nodes is sorted in document order, and duplicates are eliminated based on node identity. Each node resulting from the evaluation of
E1 then serves in turn to provide an inner focus for an evaluation of
E2, as described in 2.1.2 Evaluation Context. Each evaluation of
E2 must result in a sequence of nodes; otherwise, a dynamic error is raised. The sequences of nodes resulting from all the evaluations of
E2 are merged, eliminating duplicate nodes based on node identity and sorting the results in document
order.
As an example of a path expression,
child::div1/child::para selects the
para element children of the
div1 element children of the context node, or, in other words, the
para element grandchildren of the context node that have
div1 parents.
A "
/" at the beginning of a path expression is an abbreviation for the initial step
xf:root(self::node()). The effect of this initial step is to begin the path at the root node that contains the context node. If the context item is not a node, a dynamic error is raised.
A "
//" at the beginning of a path expression is an abbreviation for the initial steps
xf:root(self::node())/descendant-or-self:node(). The effect of these initial steps is to establish an initial node sequence that contains all nodes in the same hierarchy as the context node. This node sequence is then filtered by subsequent steps in the path expression. If the context item is not a node, a dynamic error is raised.
A step generates a sequence of items and then filters the sequence by zero or more predicates. The value of the step consists of those items that satisfy the predicates. Predicates are described in 3.2.2 Predicates.
A step may consist of a primary expression (described in 3.1 Primary Expressions), a forward step, or a reverse step. A forward or reverse step always returns a sequence of nodes. A forward or reverse step might be thought of as beginning at the context node and navigating to those nodes that are reachable from the context node via a specified axis. Such a step has two parts: an axis, which defines the "direction of movement" for the step, and a node test, which specifies the node kind and/or name of the nodes to be selected by the step.
In the abbreviated syntax for a step, the axis can be omitted and other shorthand notations can be used as described in 3.2.4 Abbreviated Syntax.
The unabbreviated syntax for a forward or reverse step consists of the axis name
and node test separated by a double colon. The result of the step consists of the nodes
reachable from the context node via the specified axis that have the node kind
and/or name specified by the node test. For example, the
step
child::para selects the
para element children of the context node:
child is the name of the axis, and
para is the name of the element nodes to be selected on this axis. The available axes are described in 3.2.1.1 Axes. The
available node tests are described in 3.2.1.2 Node Tests. Examples of
steps are provided in 3.2.3 Unabbreviated Syntax and 3.2 or document fragment as the context node, that
are after the context node in document order, excluding any descendants and
excluding attribute nodes and namespace nodes
the
preceding axis contains all nodes, in the same document or document fragment a static a static.
Note:
In order to be consistent with QName in XML, whitespace is not allowed in the Wildcard production. For instance "prefix:*" is allowed, but "prefix : *" is not allowed.
A predicate consists of an expression, called a predicate
expression, enclosed in square brackets. A predicate serves to filter a sequence, retaining some items and discarding others. For each item in the sequence to be filtered, the predicate expression is evaluated using an
inner focus derived from that item, as described in
2.1.2 Evaluation Context. The result of the predicate expression is
coerced to a Boolean value, called the predicate truth value, as
described below. Those items, the predicate truth value is
true. The predicate truth value in this case does not depend on
the content of the node(s). predicate can also be used with a primary expression that is not a forward or reverse step, as illustrated in the following example:
List all the integers from 1 to 100 that are divisible by 5. (See 3.3.1 Constructing Sequences for an explanation of the
to operator.)
(1 to 100)[. mod 5 eq 0] 3.2 root of the node hierarchy that contains the context node
/descendant::para selects all the
para elements in the same document as the context node
/descendant::list/child::member selects all
the
member elements that have an
list parent and that are in the same document as the context node
child::para[xf:position() = 1] selects the first
para child of the context node
child::para[xf:position() = xf:last()] selects the last
para child of the context node
child::para[xf:position() = xf:last()-1] selects the last but one
para child of the context node
child::para[xf:position() > 1] selects all the
para children of the context node other than the first
para child of the context node
following-sibling::chapter[xf:position() = 1]selects the next
chapter sibling of the context node
preceding-sibling::chapter[xf:position() = 1]selects the previous
chapter sibling of the context node
/descendant::figure[xf:position() = 42] selects the forty-second
figure element in the document
/child::doc/child::chapter[xf:position() = 5]/child::section[xf:position() = 2]selects the
second
section of the fifth
chapter of the
doc document element
child::para[attribute::type="warning"]selects
all
para children of the context node that have a
type attribute with value
warning
child::para[attribute::type='warning'][xf:position() = 5]selects the fifth
para child of the context node that has a
type attribute with value
warning
child::para[xf][xf:position() = xf
. returns the context item. This is particularly useful in conjunction with
//. For example, the path
expression
.//para returns[xf by using the comma operator, which evaluates each of its operands and concatenates the resulting values, in order, into a single result sequence.
An ExprSequence is not an expression in its own right, and in general it must be enclosed in parentheses when used in a context where an expression is expected. Empty parentheses can be used to denote an empty as one operand in constructing a sequence:
(10, 1 to 4)
It evaluates to the sequence:
10, 1, 2, 3, 4
This example constructs a sequence of length one:
10 to 10
It evaluates to a sequence consisting of the single integer
10. on node identity. If an operand
of
union,
intersect, or
except contains an item that is not a node, a dynamic error is whitespace if it could otherwise be interpreted as part of the previous token. For example,
a-b will be interpreted as a name, but
a - b will be interpreted as an arithmetic operation.
An arithmetic expression is evaluated by applying the following rules, in order, until an error is raised, a dynamic error is a dynamic.
XPath supports two division operators named
div and
idiv. The
div operator accepts operands of any numeric types. The result of the
div operator is the least common type of its operands; however, if both operands are of type
xs:integer,
div returns a result of type
xs:double. The
idiv operator, on the other hand, requires its operands to be of type
xs:integer and returns a result of type
xs:integer, rounded toward zero.
Here are some examples of arithmetic expressions:
The first expression below returns
-1.5E0, and the second expressions returns
-1:
-3 div 2 -3 idiv 2
Subtraction of two date values results in a value of type
x.
When an XPath expression is written within an XML document, the XML escaping rules for special characters must be followed; thus "
<" must be written as "
<"., a dynamic error is"
Ed. Note: The current definitions of the value comparison operators are not transitive. The Working Group is discussing making value comparisons transitive by removing some implicit casts from value comparisons and adding them to general comparisons.:
Each operand must be either a single node or an empty sequence; otherwise a dynamic error is a dynamic error is raised.
If either operand is an empty sequence, the result of the comparison is an empty sequence.
A comparison with the
<< operator returns
true if the first operand node is earlier than the second operand node in
document order; otherwise it returns
false.
A comparison with the
>> operator returns
true if the first operand node is later than the second operand node in
document order;. If a logical expression does not raise an error, its value is always one
of the boolean values
true or
false.
The first step in evaluating a logical expression is to find the effective boolean value of each of its operands (see 2.4.3.2 Effective Boolean Value).
The value of an and-expression is determined by the effective boolean values (EBV's) of its operands. If an error is raised during computation of one of the effective boolean values, an and-expression may raise a dynamic error, as shown in the following table:
The value of an or-expression is determined by the effective boolean values (EBV's) of its operands. If an error is raised during computation of one of the effective boolean values, an or-expression may raise a dynamic error, as shown in the following table:
The order in which the operands of a logical expression are evaluated is implementation-dependent. The tables above are defined in such a way that an or-expression can return:
1 eq 1 and 2 eq 2
1 eq 1 or 2 eq 3
The following expression may return either
false or raise a dynamic error:
1 eq 2 and 3 idiv 0 = 1
The following expression may return either
true or raise a dynamic error:
1 eq 1 or 3 idiv 0 = 1
The following expression must raise a dynamic error:
1 eq 1 and 3 idiv 0 = 1
In addition to and- and or-expressions, XPath provides a function named
not that takes a general sequence as parameter and returns a boolean value.
The
not function reduces its parameter to an effective boolean value. It then
returns
true if the effective boolean value of its parameter is
false, and
false if the effective boolean value of its parameter
is
true. If an error is encountered in finding the effective boolean value of its operand,
not raises a dynamic error. The
not function is described in [XQuery 1.0 and XPath 2.0 Functions and Operators].[author = $a] return $b/title)
The result of the above expression consists of the following the then-expression and else-expression, respectively.
The first step in processing a conditional expression is to find the effective boolean value of the test expression, as defined in 2.4.3.2 Effective Boolean Value. in the then-expression, and the then-expression need not be evaluated. For.4.3.2 Effective Boolean Value. raise a dynamic error as soon as it finds one binding tuple for
which the test expression raises an error. Similarly, if the quantifier is
every, an implementation may return
false as soon as it finds one binding tuple for which the test expression has
an effective Boolean value of
false, and it may raise a dynamic error as soon as it finds one binding tuple for
which the test expression raises either return
true or raise a dynamic error, since its test expression returns
true for one variable binding
and raises an error for another:
some $x in (1, 2, "cat") satisfies $x * 2 = 4
This quantified expression may either return
false or raise a dynamic error, since its test expression returns
false for one variable binding and raises an error for another:
every $x in (1, 2, "cat") satisfies $x * 2 = 4
In addition to their use in function parameters, SequenceTypes occur explicitly in
instance of,
cast, and
treat expressions.
The boolean
operator
instance of
returns
true if the value of its first operand matches the type named in its second
operand, according to the rules for SequenceType Matching; otherwise it returns
false. For example:
5 instance of xs:integer
This example returns
true because the given value is an instance of the given type.
. instance of element
This example returns
true if the context item is an element node. has the same lexical representation as the input value. The type of the input value is called the input type.
cast is supported only for certain combinations of input type and target type, as listed below. For the purpose of these rules, we use the terms subtype and supertype in the following sense: if type B is derived from type A by restriction, then B is a subtype of A, and A is a supertype of B.
cast is supported for the combinations of input type and target type listed in [XQuery 1.0 and XPath 2.0 Functions and Operators]. For each of these combinations, both the input type and the target type are built-in schema types. For example, a value of type
xs:string can be cast into the type
xs:decimal.
For every built-in type T that is defined in [XML Schema], a constructor function is provided whose name is the same as T and whose semantics are the same as a cast expression with target type T. For example, the function call
xs:decimal($stringvalue) is equivalent to the expression
cast as xs:decimal($stringvalue). If the argument to a constructor function is a literal, the result of the function may be computed statically, and an error encountered in this process may be reported as a static error. Constructor functions are described in more detail in [XQuery 1.0 and XPath 2.0 Functions and Operators].
cast is supported if the input type is a derived atomic type and the target type is a supertype of the input type. For example, if
shoesize is derived by restriction from
xs:integer, a value of type
shoesize can be cast into the type
xs:integer.
cast is supported if the target type is a derived atomic type and the input type is
xs:string,
xs:anySimpleType, or a supertype of the target type. If the input type is
xs:string or
xs:anySimpleType, its string value must be in the lexical space of the target type, and it is converted to the target type using the schema-defined rules for the target type. If the input type is a supertype of the target type, its value is mapped unchanged into the value space of the target type, and it is checked for conformance to all the facets of the target type (checking of a "pattern" facet may require generating a canonical lexical representation of the input value.)
For any combination of input type and target type that is not in the above list, a
cast expression raises a static error.
If it is not possible to cast the input value into the value space of the target type, a dynamic error is raised. This includes the case when any facet of the target type is not satisfied. For example,
cast as xs:integer($x) raises a dynamic error if the type of
$x is
xs:decimal and its value is
4.99 because this value cannot be represented with zero fractional digits.
In addition to
cast, XPath provides a type-checking expression called
treat, which takes two operands: an expression and a SequenceType. Unlike
cast, however,
treat does not change the type or value of its operand. Instead, the purpose of
treat is to ensure that an expression has an expected type at run-time.
The semantics of
treat as type1 (expr2) are as follows:
During static analysis (if the Static Typing Feature is implemented):
type1 must be a subtype of the static type of
expr2, using the definition of subtype in [XQuery 1.0 Formal Semantics]--otherwise, a static type 2.4.2 SequenceType, the
treat expression returns the value of
expr2; otherwise, it raises a dynamic error. a dynamic error is hierarchy of nodes is validated by a
validate expression, the hierarchical relationship among these nodes will be preserved among the nodes created by the validation process. steps:
The value of the expression is converted from the Data Model to an XML Information Set (see [XML Infoset].) This step is equivalent to serializing the value of the expression in XML form and then parsing it to produce an Information Set.
The Information Set produced in the previous step is validated according to the rules in [XML Schema], using the in-scope schema definitions. The result of this step is a Post-Schema Validation Infoset (PSVI). If the validation process is not successful, a dynamic type error is raised.
The PSVI produced in the previous step is converted back into the Data Model by the mapping described in [XQuery 1.0 and XPath 2.0 Data Model]., as long as these characters are legal XML characters as defined in the [XML] recommendation.
A lexical pattern is a rule that describes how a sequence of characters can match a grammar unit. A lexeme is the smallest meaningful unit in the grammar that has syntactic interpretation. A token is a symbol that matches lexemes, and is the output of the lexical analyzer. A token symbol is the symbolic name given to that token. A single token may be composed of one or more lexemes. If there is more than one lexeme, they may be separated by whitespace or punctuation. For instance, the token AxisDescendantOrSelf has two lexemes, "descendant-or-self" and "::".
When patterns are simple string matches, the strings are embedded directly into the BNF. In other cases, token symbols are used when the pattern is a more complex regular expression (the major cases of these are NCName, QName, and Number and String literals). It is up to an implementation to decide on the exact tokenization strategy, which may be different depending on the parser construction. For instance, an implementation may decide that a token named
For is composed of only "for", or may decide that it is composed of ("for" "("). In the first case the implementation may decide to use lexical lookahead to distinguish the "for" lexeme from a QName that has the lexeme "for". In the second case, the implementation may decide to combine the two lexemes into a single "long" token. In either case, the end grammatical result will be the same. Lexemes that must be described by lexical lookahead are delimited with the tokens that it must look ahead to, in order to be recoginized, by "<" and ">".
This grammar implies lexical states, which are lexical constraints on the tokenization process based on grammatical positioning. The exact structure of these states is left to the implementation, but the normative rules for calculating these states are given in the A.1.2 Lexical Rules section.
When tokenizing, the longest possible match that is valid in the current lexical state is prefered .
For readability, Whitespace may be used in most expressions even though not explicitly allowed by the grammar: Whitespace may be freely added between lexemes, except a few cases where whitespace is needed to disambiguate the token. For instance, in XML, "-" is a valid character in an element or attribute name. When used as an operator after the characters of a name, it must be separated from the name, e.g. by using whitespace or parentheses.
All keywords are case sensitive.
Ed. Note: Since currently ExprComments are specified at the lexical level, I leave it as an editorial issue as to how to describe this, or whether to constrain where ExprComments are allowed so they can be described by the BNF. (I would be in favor of this. -sb)
Character Classes
The following basic tokens are defined in [XML].
Identifiers
The following identifier components are defined in [XML Names].
String Literals and Numbers
Comments are lexical constructs only, and do not affect the processing of an expression. [Ed. Note: Need to expand on where, exactly, comments are allowed.]
Defined Tokens
The following is a list of defined tokens for the XPath grammar.
As discussed above, there are various strategies that can be used by an implementation to disambiguate token symbol choices. Among the choices are lexical look-ahead and look-behind, a two-pass lexical evaluation, and a single recursive descent lexical evaluation and parse. This specification does not dictate what strategy to use. However, this section does describe normative rules with which these decisions must conform to.
The lexical contexts and transitions between lexical contexts is described in terms of a series of states and transitions between those states. An implementation need not follow this approach in implementing lexer rules, but does need to conform to the results. For instance, instead of using a state automata, an implementation might use lexecal look-behind, or might use a full context-free-grammar parse, or it might make extensive use of parser lookahead (and use a more ambiguous token strategy).
The tables below define the complete lexical rules for XPath. Each table corresponds to a lexical state in which the tokens listed are recognized only in that state. When a given token is recognized in the given state, the transition to the next state is given. In some cases, a transition will "push" the current state or a specific state onto an abstract stack, and will later restore that state by a "pop" when another lexical event occurs. [Ed. Note:
pushParenState(...),
popParenState(...), and
resetParenStateOrSwitch(...) are left unexplained for now. Briefly, these are used to maintain the
ITEMTYPE state within a function definition in XQuery, since it is hard to distinguish lexically between a function call and a function definition. Since the lexical state mechanism is shared between XPath and XQuery, these are used in the XPath tables also, even though they are not strictly needed.]
The lexical states have in many cases close connection to the parser productions. However, just because a token is recognized in a certain lexical state, does not mean it will be legal in the parser state.
This state is for patterns that can be recognized in any state.
This state is for patterns that occur at the beginning of an expression.
This state is for patterns that are defined for operators.
When a qualified name is expected, and it is required to remove ambiguity from patterns that look like keywords, this state is used.
This state.
The following grammar uses the same Basic EBNF notation as [XML], except that grammar symbols always have initial capital letters. The EBNF contains the lexemes embedded in the productions.
Note:
Note that the Semicolon character is reserved for future use.
Under certain circumstances, an atomic value can be promoted from
one type to another. The promotion rules listed below are used in
basic type conversions (see 2.4.3 Type Conversions) and
during processing of arithmetic expressions (see 3.4 Arithmetic Expressions) and value comparisons (see 3. The result is the
xs:float value that is closest to the original value.
A value of type
xs:float can be promoted to the
type
xs:double. The result is the
xs:double value that is the same as the original value.
A value of a derived
type can be promoted to its base type. The result is the base-type value that is the same as the original value. a zero-length string, as it did in XPath 1.0.
Consecutive comparison operators such as
A < B < C were supported in XPath 1.0, but are not supported in XPath 2.0..
Backward compatibility issues affecting individual functions in the core function library are described in [XQuery 1.0 and XPath 2.0 Functions and Operators]. the 3-valued logic functions be part of the XPath function library? Note that they can be implemented as user functions (not as efficient as a "native" implementation). We may want to include the user definition as an example.] .
Decision by: xpath-tf on 2002-05-07 ([link to member only information] )
Decision by: xquery on 2002-05-22 ([link to member only information] )
Decision by: xsl on 2002-06-27 ([link to member only information] )
Addressed by the "Named Typing" proposal.
Accepting text in 2002-04-30 public draft.] .
Jonathan and Don to present a potential consensus proposal at the f2f (This should be a very short proposal). Note: Perhaps we should seriously consider writing the conformance section for the next set of publications.
We should specify the behavior of XQuery for well formed XML, XML validated by a schema, and XML validated by a DTD.
The mapping of a DTD validated or well formed document still needs to be defined in the Data Model.] .
Some aspects addressed by the "Named Typing" proposal.
The Data Model work still needs to be done.
Open questions: What is the result of a failed validation? Can you inspect the result?
Does the definition of a type include both element-names and element-contents (as in the Formal Semantics document), or only element-contents (as in XML Schema)?.
Decision by: xpath-tf on 2002-04-30 ([link to member only information] )
Decision by: xquery on 2002-05-22 ([link to member only information] )
Decision by: xsl on 2002-06-27 ([link to member only information] )
Mike: We dealt with by saying that there is only one function and the use typeswitch semantics., but needs more?
Decision by: xsl on 2002-06-27 ([link to member only information] )
Decision by: xquery on 2002-07-17 ([link to member only information] )
The issue is "dead", in the sense that the April draft contains text that everyone is happy with.?
Do we need an identity-based equality operator? Please justify your answer with sample queries. Note that XPath gets along without it.
Cf. Should we use is and isnot instead of == and !==.
The '==' operator is already defined in the F&O document and used in XQuery use cases.
Decision by: xpath-tf on 2002-04-30 ([link to member only information] )
Decision by: xquery on 2002-05-22 ([link to member only information] )
Decision by: xsl on 2002-06-27 ([link to member only information] )
The '==' is in the document and usecases.
Note that it has been decided to change "==" to "is"..
Decision by: xpath-tf on 2002-04-30 ([link to member only information] ) Verifying that text is in current draft.
Decision by: xquery on 2002-05-22 ([link to member only information] )Independent verification.
What should happen if a function expecting one element is invoked on a sequence of more than one element?
It's an error.
Text is in Working Draft 2001-11-28 sec 2.1.2, paragraph 6, item 1.1.
Decision by: xpath-tf on 2002-04-30 ([link to member only information] ) Verifying that text is in current draft.
Decision by: xquery on 2002-05-22 ([link to member only information] )Independent verification.
How should the current node be passed to a function in a path-step?
Using dot notation (".").
Text is in Working Draft 2001-11-28 sec 2.1.1.2, paragraph 4.
Decision by: xpath-tf on 2002-04-30 ([link to member only information] ) Verifying that text is in current draft.
Decision by: xquery on 2002-05-22 ([link to member only information] )Independent verification..
Should leading minus/plus be treated as unary operators or as part of a numeric literal? Or should both be supported?
Decision by: xsl on 2002-06-27 ([link to member only information] )
Decision by: xquery on 2002-07-17 ([link to member only information] )
The issue is "dead", in the sense that the April draft contains text that everyone is happy with..
Decision by: xpath-tf on 2002-04-30 ([link to member only information] )
Decision by: xquery on 2002-05-22 ([link to member only information] )
Decision by: xsl on 2002-06-27 ([link to member only information] )
Done at grammar level.
An extensibility mechanism needs to be defined that permits XQuery to access a library of functions written in some other programming language such as Java.
Some sources of information: the definition of external functions in SQL, the implementation of external functions in Kweelt..
Decision by: xpath-tf on 2002-04-30 ([link to member only information] )
Decision by: xquery on 2002-05-22 ([link to member only information] )
Decision by: xsl on 2002-06-27 ([link to member only information] )
Section "Accessors" has been added to F&O., that it does only id/idref.
Decision by: xpath-tf on 2002-05-07 ([link to member only information] ) Verifying that the text that the text is in the draft. Note: there is also a proposal on the table to remove => entirely.
Decision by: xquery on 2002-05-16 ([link to member only information] )
We will keep the dereference operator.
Decision by: xquery on 2002-05-22 ([link to member only information] )
The XML Query WG revisited issue 134 and decided to close the issue by removing => completely. This was not unanimous decision.
Decision by: xsl on 2002-05-23 ([link to member only information] )The XSL WG agrees with the change to remove =>..
Decision by: xpath-tf on 2002-04-30 ([link to member only information] )
Decision by: xquery on 2002-05-22 ([link to member only information] )
Decision by: xsl on 2002-06-27 ([link to member only information] )
Syntax in current draft has this, but explanatory text need to be added.
Can a query construct an entire XML document? What restrictions are there, eg on the internal subset, processing instructions or comments on the root level?
The constructor we propose does nothing except create a document node, and is very simple. The documents constructed in this way can be validated, fed to functions that save them or send them as messages, or used in any other way that document nodes may be used in XQuery. Currently, we can construct any node in our data model except for the document node. For instance, we have the following constructors for element and attribute nodes: [66] ComputedElementConstructor ::= "element" (QName | EnclosedExpr) "{" ExprSequence? "}" [67] ComputedAttributeConstructor ::= "attribute" (QName | EnclosedExpr) "{" ExprSequence? "}" We propose an analogous syntax for document nodes, except that there is no need to create the QName for a document node, which does not have one: DocumentNode ::= 'document' '{' ExprSequence '}' A document node constructor creates a document node. It does nothing else. It does not associate the document node with a schema or DTD, specify a file name for it, validate the instance, assign file permissions, or shine shoes. Appendix: Interesting things that are not part of document node construction Here are many things people want to do with documents. None of these are part of document node construction, but all of these things benefit from document nodes. 1. Validating a node Once created, a document may be validated, eg: let $d := document { <?xml version="1.0"?> <greeting>Hello, world!</greeting> } return validate($d) 2. Saving a node to the file system This is best done using a function that specifies the URI, and any other parameters that the system may need. The signature for such a function may look like this: save-document( document $docnode, anyURI $name, element file-params? $p) The file-params element could be used to store information on file permissions, etc. Appendix: Issues Issue: How should schemas be imported for validating a document using the document node? Consider the following example: <stylesheet xmlns="" xmlns: I think this is no different from validating an element node. A root element may identify namespace prefixes. Names must be defined in the in-scope schema definitions before they can be used for validation. With or without the document node, a schema location may be specified on an element. Implementations should be free to use this location to locate a schema or to ignore it, as in XML Schema. Issue: Should we allow a DOCTYPE in a document constructor? Consider the following example: let $d := document { <?xml version="1.0"?> <!DOCTYPE greeting SYSTEM "hello.dtd"> <greeting>Hello, world!</greeting> } return validate($d) If a DOCTYPE is specified, should it be used, as it would be by most XML processors?
Decision by: xquery on 2002-05-16 ([link to member only information] )
Cotton: Any objections to adopting this proposal as written by Jonathan? One objection by Michael Rys. Proposal is adopted with one objection.)
Cf. Accessing Element Data
The proposal by Michael Rys in [link to member only information: Proposal to close issue expr[nodes]] treats not()/not3() differently from all other functions that take a boolean formal argument.
Cf. Implicit conversion of node-sets to boolean for comparisons.
Lexical structure and typed form of text nodes discussed in datamodel. No analogous discussion in the XPath document on that there are two ways to access information, as typed content or as nodes. This also needs to be discussed in conjunction with construction.
Need to extend languages to test for instance-of comments, pis, etc.
Decision by: xsl on 2002-06-27 ([link to member only information] )
Decision by: xquery on 2002-07-17 ([link to member only information] )
The issue is "dead", in the sense that the April draft contains text that everyone is happy with.
Should we do explicit casts rather than type conversion, like for example Python? This would result in e.g. forceing the user to tag a string everytime...
Cf. Support for UnknownSimpleType.
Decision by: xsl on 2002-06-27 ([link to member only information] )
Decision by: xquery on 2002-07-17 ([link to member only information] )
The issue is "dead", in the sense that the April draft contains text that everyone is happy with.
What is the type of a newly constructed element?
Issue is for material in sec 2.8. in Working Draft 2001-11-28.
Cf. Is the QName denoting type information optional or required?
Cf. Should all elements and attributes have type annotations?
Addressed by the "Named Typing" proposal..
Should XQuery support the import of locally declared types from schemas?. [!]
Should variable names be QNames or NCNames? Note that XPath 1.0 uses QNames, and it may be helpful to disambiguate variable names from different modules.
Decision by: xsl on 2002-06-27 ([link to member only information] )
Decision by: xquery on 2002-07-17 ([link to member only information] )
The issue is "dead", in the sense that the April draft contains text that everyone is happy with. in SequenceType production.
Decision by: xpath-tf on 2002-04-30 ([link to member only information] ) Verifying that text is in current draft.
Decision by: xquery on 2002-05-22 ([link to member only information] )Independent verification.
Is Datatype the right name for production [54] (Draft 2001-11-28)? It may be confused with XML Schema Type 2.
Decision by: xsl on 2002-06-27 ([link to member only information] )
Decision by: xquery on 2002-07-17 ([link to member only information] )
The issue is "dead", in the sense that the April draft contains text that everyone is happy with..
The current definition of context documents may be difficult to implement in an efficient manner. Should this definition be simplified? Is this definition needed at all?
The definition of context document has been removed. we allow external functions to be defined using a syntax like this?
[71a] ExternalFnDef ::= {"define" S "external" S "function"} QName "(" ParamList? ")" ("returns" Datatype)?.
Do we need both << and precedes?
Decision by: xpath-tf on 2002-07-29 ([link to member only information] )
Decision by: xsl on 2002-07-30 ([link to member only information] )(joint meeting)
Decision by: xquery on 2002-07-30 ([link to member only information] )(joint meeting)
"precedes" and "follows" operators deleted.
Is "/" and the context document adequate for multiple documents?
Cf. Mapping Input Context
Access is provided to multiple documents using a different mechanism, specifically the input() and collection() functions.] )
Decision by: xquery on 2002-05-22 ([link to member only information] )Reaffirming the XPath TF telcon 2002-04-30 view.
Decision by: xsl on 2002-06-27 (.
At the XPath TF telcon 2002-04-30 it was noted that the current documents do not reflect the resolution, as recorded in our issues list. The documents need to be modified accordingly.: XQuery Section 2.13 cast does data extraction.
Decision by: xpath-tf on 2002-04-30 ([link to member only information] ) Verifying that text is in current draft.
Decision by: xquery on 2002-05-22 ([link to member only information] )Independent verification..
Is the QName that denotes type information in an element or attribute optional or required?.) current Working Drafts are inconsistent in their definition of a leading slash in a path expresion. A consistent definition needs to be developed.
Leading "/" on a path expression means "root(self::node())": the root node of the tree containing the context item. Note that self::node() (and therefore leading "/") raises a dynamic error if the context item is not a node..
Should we (or ask schema to) add Schema type names for sequences of homogeneous types?
If we add them now and Schema decide to add them later these would be different as the namespace for the type would be different...
Must Basic XQuery support the SQL/XML mappings? One of the original purposes for Basic XQuery was support for mapping relational data, but the SQL/XML mappings would not be allowed as data in the current definition of Basic XQuery, because they contain (a) user-derived simple types, and (b) named complex types, which would result in type annotations in our data model. Since SQL/XML is the only proposed standard for relational mappings, do we need to ensure that we support it in Basic XQuery?
The Data Model document defines mappings from the PSV Infoset. If we decide it is essential to query arbitrary XML documents with Basic XQuery, should we define interoperable mappings that would create a representation that has no named types other than built-in XML Schema types? For instance, we might state Basic XQuery implementations map user-derived types to the nearest built-in type, do not create type annotations for named complex.
What should be the type of an error value? Section 2.4.3 says that it can be one item. Some people think it should be more flexible (any sequence of items), and other people think it should be less flexible (an item of a particular type). Some people think it should be an element with a well-defined structure.:
Cf. Schema Import, Static Typing: what is interoperable?
Cf. Optional Features vs. Conformance Levels:
Cf. Should different conformance levels give the same result for the same query and data?
Cf. Optional Features vs. Conformance Levels
Should "Schema Import" and "Static Typing" be independent, optional features or should there be a layer of conformance levels? For XQuery the latter might be "Basic XQuery", "Basic XQuery" + "Schema Import", and "Basic XQuery" + "Schema Import" + "Static Typing".