The presentation of this document has been augmented to identify changes from a previous version. Three kinds of changes are highlighted: new, added text, changed text, and deleted text.
Copyright © 2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
XML is a versatile markup language, capable of labeling the information content of diverse data sources including structured and semi-structured documents, relational databases, and object repositories. A query language that uses the structure of XML intelligently can express queries across all these kinds of data, whether physically stored in XML or viewed as XML via middleware. This specification describes a query language called XQuery, which is designed to be broadly applicable across many types of XML data sources.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a public W3C Working Draft for review by W3C Members and other interested parties. Publication as a Working Draft doesnot imply endorsement by the W3C Membership.This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
XQuery1.0 has been defined jointlyby the XML Query Working Groupand theXSLWorking Group (bothpart of the XML Activity).The XPath 2.0 and XQuery 1.0 Working Drafts are generated from a common source. These languages are closely related, sharing much of the same expression syntax and semantics, and much of the text found in the two Working Drafts is identical.
This version contains severalchanges. The section entitled "SequenceType Matching" has been rewritten and includes new material on handlingof unrecognizedtypes. A new concrete type, xdt:untypedAny
,has been introduced, and the isnot
comparison operatorhas been removed. Rules for static and dynamicimplementations have beenclarified. A complete
list of changes can be found in I Revision
Log.
XQueryIssue 152, concerningan XML syntax for XQuery, has been resolved.The XML Query WorkingGroup plans to issue anXQueryXWorking Draft in the nearfuture toreflect this issue's resolution.
Thisis a LastCallWorking Draft.Comments on this document are dueon 15 February 2004. Comments should be sent to the W3C mailing list public-qt-comments@w3.org (archived at http://lists.w3.org/Archives/Public/public-qt-comments/)with [XQuery]at the beginningof the subject field.
Patent disclosures relevant to this specification may be found on the XML Query Working Group's patent disclosure page at http://www.w3.org/2002/08/xmlquery-IPR-statements and the XSL Working Group's patent disclosure page at http://www.w3.org/Style/XSL/Disclosures.
1 Introduction
2 Basics
2.1 Expression Context
2.1.1 Static Context
2.1.2 Dynamic Context
2.2 Processing
Model
2.2.1 Data
The Modelfn:input Generation
2.2.2 Schema Import
Processing
2.2.3 Expression
Processing
2.2.3.1 Static Analysis Phase
2.2.3.2 Dynamic Evaluation Phase
2.2.4 Serialization
2.2.5 Consistencyis Constraints
2.3 Documents
2.3.1 Documentxs:decimal. Order
2.3.2 Atomization
2.3.3 Effectiveprovides Boolean Value
2.3.4 Input SourcesTypes
2.4 Types
2.4.1 Predefined Types
2.4.2 Typedtwo Value and String Value
2.4.3 SequenceType Syntax
2.4.4 SequenceType Matching
2.4.4.1 Matching a SequenceType and a Value
2.4.4.2 Matchingas an ItemType and an
Item
2.4.4.3 Matchingits an ElementTest and an
Elementor Node
2.4.4.4 Matching an AttributeTest and an Attribute
Node
2.5 Error Handling
2.5.1 Kinds
Some expressions do not require their operands to exactly match the expected type. For example, function parameters and returns expect a value of
a particular type, but automatically perform certain type conversions,
such as extraction of Errors
2.5.2 Handling Dynamic Errors
2.5.3 Errors and
Optimization
2.6 Optional
Features
2.6.1 Schema Import Feature
2.6.2 Static Typing Feature
2.6.3 Full Axis Feature
2.6.4 Module FeatureExtensions
2.6.5 Pragmas
2.6.6 Must-Understand Extensions
2.6.6.1 XQuery Flagger
2.6.7 Static Typing Extensions
2.6.7.1 XQuery Static Flagger
3 Expressions
3.1 Primary Expressions
3.1.1 Literals
3.1.2 Variable ReferencesVariables
3.1.3 Parenthesized Expressions
3.1.4 Context Item Expression
3.1.5 Function Calls
3.1.6 XQuery 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 Node 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.6 Logical Expressions
3.7 Constructors
3.7.1 Direct Element Constructors
3.7.1.1 Attributes
3.7.1.2 Namespace Declaration AttributesNamespaces
3.7.1.3 Content
3.7.1.4 Whitespace in Element Content
3.7.1.5 Type of a Constructed
Element
3.7.2 Other Direct Constructors
3.7.3 Computed
Constructors
3.7.3.1 Computed Element
Constructors
3.7.3.2 Computed Attribute
Constructors
3.7.3.3 Document Node Constructors
3.7.3.4 Text Node Constructors
3.7.3.5 Computed Processing Instruction Constructors
3.7.3.6 Computed Comment Constructors
3.7.3.7 Computed Namespace Constructors
3.7.4 Namespace Nodes on Constructed Elements
3.8 FLWOR Expressions
3.8.1 For and Let Clauses
3.8.2 Where Clause
3.8.3 Order By and Return Clauses
3.8.4 Example
3.9 Unordered Expressions
3.10 Conditional Expressions
3.11 Quantified Expressions
3.12 Expressions on SequenceTypes
3.12.1 Instance Of
3.12.2 Typeswitch
3.12.3 Cast
3.12.4 Castable
3.12.5 Constructor
Functions
3.12.6 Treat
3.13 Validate Expressions
4 Modules and Prologs
4.1 Version Declaration
4.2 Module Declaration
4.3 BaseXQuery URI Declaration
4.4 Namespace Declaration
4.5 Default Namespace Declaration
4.6 Schema Import
4.7 Module Import
4.8 Variable Declaration
4.9 Validation Declaration
4.10 Xmlspace Declaration
4.11 Default Collation Declaration
4.12 Function Declaration
A XQuery Grammar
A.1 EBNF
A.1.1 Grammar Notes
A.2 Lexical structure
A.2.1 White Space Rules
A.2.2 Lexical Rules
A.3 Reserved Function Names
A.4 Precedence Order
B Type Promotion and Operator Mapping
B.1 Type Promotion
B.2 Operator Mapping
C Context Components
C.1 Static Context Components
C.2 Dynamic Context Components
C.3 Serialization Parameters
D References
D.1 Normative References
D.2 Non-normative References
D.3 Non-normative Background References
D.4 Non-normative Informative Material
E Glossary
F SummaryTo of Error Conditions
G Example Applications (Non-Normative)
G.1 Joins
G.2 Grouping
G.3 Queries on Sequence
G.4 Recursive Transformations
G.5 Selecting Distinct Combinations
H XPath 2.0elements and XQuery 1.0 Issues (Non-Normative)
I Revision
Log (Non-Normative)
I.1 12 November 2003
As increasing amounts of information are stored, exchanged, and presented using XML, the ability to intelligently query XML data sources becomes increasingly important. One of the great strengths of XML is its flexibility in representing many different kinds of information from diverse sources. To exploit this flexibility, an XML query language must provide features for retrieving and interpreting information from these diverse sources.
XQuery is designed to meet the requirements identified by the W3C XML Query Working Group [XML Query 1.0 Requirements] and the use cases in [XML Query Use Cases]. It is designed to be a language in which queries are concise and easily understood. It is also flexible enough to query a broad spectrum of XML information sources, including both databases and documents. The Query Working Group has identified a requirement for both a human-readable query syntax and an XML-based query syntax. XQuery is designed to meet the first of these requirements. XQuery is derived from an XML query language called Quilt [Quilt], which in turn borrowed features from several other languages, including XPath 1.0 [XPath 1.0], XQL [XQL], XML-QL [XML-QL], SQL [SQL], and OQL [ODMG].
[Definition: XQuery operates on the abstract, logical structure of an XML document, rather than its surface syntax. This logical structure is known as the data model, which is defined in the [XQuery 1.0 and XPath 2.0 Data Model] document.]
XQuery Version 1.0 is an extension of XPath Version 2.0. Any expression that is syntactically valid and executes successfully in both XPath 2.0 and XQuery 1.0 will return the same result in both languages. Since these languages are so closely related, their grammars and language descriptions are generated from a common source to ensure consistency, and the editors of these specifications work together closely.
XQuery also depends on and is closely related to the following specifications:
[XQuery 1.0 and XPath 2.0 Data Model]defines the datamodel that underliesall XQuery expressions.
[XQuery 1.0 and XPath 2.0 Formal Semantics]defines the static semantics of XQuery and alsocontains a formal but non-normative description of thedynamic semantics that may beuseful for implementors and others who require a formaldefinition.
The type system of XQuery is based on [XML Schema].
The default functionlibrary and the operators supported by XQuery are defined in [XQuery 1.0 and XPath 2.0 Functions and Operators].
One requirement in [XML Query 1.0 Requirements] is that an XML query language have both a human-readable syntax and an XML-based syntax. The XML-based syntax for XQuery is described in [XQueryX 1.0].
Editorial note | |
The current edition of [XQueryX 1.0] has not incorporated recent language changes; it will be made consistent with this document in its next edition. |
This document specifies a grammar for XQuery, using the same Basic EBNF notation used in [XML 1.0], except that grammar symbols always have initial capital letters. Unless otherwise noted (see A.2 Lexical structure), 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 XQuery Grammar]. The appendix should be regarded as the normative version.
In the grammar productions in this document, nonterminal symbols are underlined and literal text is enclosed in double quotes. Certain productions (including the productions that define DecimalLiteral, DoubleLiteral, and StringLiteral) employ a regular-expression notation. The following example production describes the syntax of a function call:
[97] | FunctionCall | ::= | QName "(" (ExprSingle ("," ExprSingle)*)? ")" |
The production should be read as follows: A function call consists of a QName followed by an open-parenthesis. 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.
Certain aspects of language processing are described in this specification as implementation-defined or implementation-dependent.
[Definition: Implementation-defined indicates an aspect that may differ between implementations, but must be specified by the implementor for each particular implementation.]
[Definition: Implementation-dependent indicates an aspect that may differ between implementations, is not specified by this or any W3C specification, and is not required to be specified by the implementor for any particular implementation.]
Thisdocument normatively definesthe dynamic semantics of XQuery. The static semantics of XQuery are normatively defined in [XQuery 1.0 and XPath 2.0 Formal Semantics]. In this document, examples andmaterial labeled as "Note" are provided forexplanatory purposes and are not normative.
The basic building block of XQuery is the expression, which is a string of Unicode characters.The language provides several kinds of expressions which may be constructed from keywords, symbols, and operands. In general, the operands of an expression are other expressions. [Definition: XQuery is a functional language, which meansthat expressions can be nested with full generality. (However, unlike a pure functional language, it does not allow variable substitutability if the variable declaration contains construction of new nodes.)] [Definition: XQuery is also a strongly-typed language in which the operands of various expressions, operators, and functions must conform to the expected types.]
Like XML, XQuery is a case-sensitive language. Keywordsin XQuery use lower-case characters and are not reserved—that is, names in XQuery expressions are allowed to be the same as language keywords—except for the list of reserved function-names in A.3 Reserved Function Names.
The value of an expression is always a
sequence. [Definition: A
sequenceis an ordered collection of zero or more
items.]
[Definition: An
item is either an atomic value or a node.]
[Definition: An atomic
value is a value in the value space of an XML Schema atomic
type, as defined in [XML Schema] (that is, a simple type that is
not a list type or a union type).]
[Definition: A node is an instance of one of the
seven node kinds defined in [XQuery 1.0 and XPath 2.0 Data Model].]
Each node has a unique node identity. Some
kinds of nodes have typed values, string values, and names, which can be
extracted from the node. The typed value of a node is a sequence
of zero or more atomic values. The string value of a node is a
value of type xs:string
. The name of a node is a value of type xs:QName
.
[Definition: A sequence containing exactly one item is called a singleton sequence.] An item is identical to a singleton sequence containing that item. Sequences are never nested—for example, combining the values 1, (2, 3), and ( ) into a single sequence results in the sequence (1, 2, 3). [Definition: A sequence containing zero items is called an empty sequence.]
Namesin XQuery conformto thesyntax in [XML Names].This document uses the following predefinednamespace prefixes:
xs = http://www.w3.org/2001/XMLSchema
xsi= http://www.w3.org/2001/XMLSchema-instance
fn = http://www.w3.org/2003/11/xpath-functions
xdt= http://www.w3.org/2003/11/xpath-datatypes
local = http://www.w3.org/2003/11/xquery-local-functions
(see4.12 Function Declaration.)
In some
cases, where the meaning is clear and namespaces are not
important to the discussion, built-in XML Schema typenames
such as integer
and string
are used
without a namespace prefix.
[Definition: The expression context for a given expression consists of all the information that can affect the result of the expression.] This information is organized into two categories called the static context and the dynamiccontext.
[Definition: The static context of an expression is the information that is available during static analysis of the expression, prior to its evaluation.] This information can be used to decide whether the expression contains a static error. Ifanalysis of an expressionrelies onsome component of the static context that has not been assigned a value,a static erroris raised.[err:XP0001]
Theindividual components of the staticcontextare summarized below. Furtherrules governing the semantics of these components can be found in C.1 Static Context Components.
[Definition: XPath1.0 compatibility
mode.This
componentmust be set byall host languages
thatinclude XPath 2.0 asa subset,
indicatingwhether rules for compatibility
withXPath 1.0 are in effect.
XQuerysetsthe value of this component to
false
.
]
[Definition: In-scope namespaces. This is a set of (prefix, URI) pairs. The in-scope namespaces are used for resolving prefixes used in QNames within the expression.]
Somenamespaces are predefined; additional namespaces canbe defined by Prologs, bynamespacedeclaration attributes, and bycomputednamespace constructors.
[Definition: Default element/type namespace. This is a namespace URI. This namespace is used for any unprefixed QName appearing in a position where an element or type name is expected.] The initial default element/type namespace may be provided by the external environment or by a declaration in the Prolog of a module.
[Definition: Default function namespace. This is a namespace URI. This namespace URI is used for any unprefixed QName appearing as the function name in a function call. The initial default function namespace may be provided by the external environment or by a declaration in the Prolog of a module.]
[Definition: In-scope schema definitions. This is a generic term for all the element, attribute, and type definitions that are in scope during processing of an expression.] It includes the following three parts:
[Definition: In-scope type definitions. Each named type definition is identified either by a QName(for a namedtype) orbyan implementation-dependenttype identifier(for an anonymous type).Thein-scope type definitions includethe predefined types as described in 2.4.1 Predefined Types. If the Schema Import Feature is supported, in-scope type definitions also include all type definitions found in imported schemas. ]
[Definition: In-scope element declarations. Each element declaration is identified either by a QName (for a top-level element declaration)or by an implementation-dependentelement identifier (for a local elementdeclaration). If the Schema Import Feature is supported, in-scope element declarations include all element declarations found in imported schemas. An element declaration includes information about the substitution groups to which this element belongs.]
[Definition: In-scope attribute declarations. Each attribute declaration is identified either by a QName (for a top-level attribute declaration)or by an implementation-dependent attribute identifier (for a local attribute declaration). If the Schema Import Feature is supported, in-scope attribute declarations include all attribute declarations found in imported schemas.]
[Definition: In-scope variables. This is a set of (QName, type) pairs. It defines the set of variables that are available for reference within an expression. The QName is the name of the variable, and the type isthe static typeof the variable.]
Variabledeclarations
inthe Prologof a module are added to the in-scope variables
of the module.An expression that binds a variable (such as a
let
, for
,
some
,or every
expression)extends the
in-scope variables of its subexpressions with the new bound variable
and its type. Within a function
declaration,the in-scope variables are extended by the names
and types ofthe functionparameters.
[Definition: In-scope functions. This componentdefines the set of functions that are available to be called from within an expression. Each function is uniquely identified by its expanded QName and its arity (number of parameters).] [Definition: Eachfunction has a function signaturethat specifies the nameof the function and the statictypesofits parameters and its result.]
Thein-scope functionsinclude constructor functions,which are discussed in 3.12.5 Constructor Functions.
[Definition: In-scope collations. This is a set of (URI, collation) pairs. It defines the names of the collations that are available for use in function calls that take a collation name as an argument.] A collation may be regarded as an object that supports two functions: a function that given a set of strings, returns a sequence containing those strings in sorted order; and a function that given two strings, returns true if they are considered equal, and false if not.
[Definition: Default collation. This collation is used by string comparison functions and operators when no explicit collation is specified.] For exceptions to this rule, see 4.11 Default Collation Declaration.
[Definition: Validation mode. The
validationmode specifies the mode in which
validation is performed by element constructors
and by validate
expressions. ] Its value isone of
strict
, lax
, or
skip
. Theinitial validation
mode may be provided by the environment
externalto a query orby thevalidation
declarationin the Prolog of a module. If no
validation mode is specified in either of
these ways,the initial validation mode is
lax
.
Thevalidationmode
forasubexpression is inherited from the
containing expression. A
validate
expression that
specifiesa mode changes the validation mode
ofits subexpressions tothe specified
mode.
[Definition: Validation
context.An expression'svalidation
context determines the context in which
elements constructed by the expression are
validated.]Its value is either
global
or a context path that
starts withthe name of a top-level element
declaration ortop-level type definition in the
in-scope schema
definitions.
The default validation context of a module is
global
.
The validation
context for a subexpression is inherited from
thecontaining expression. An element
constructor extends the validation
context of its subexpressions with the name
of the constructed element, anda
validate
expression that
specifies a context redefines the validation
context of its
subexpressions.
[Definition: XMLSpace
policy. This policy, declared in the
Prolog, controls the processing of whitespace
by element constructors.] Its value may be preserve
or strip
.
[Definition: Base URI. This is an absolute URI, used when necessary in the resolution of relative URIs (for example, by the fn:resolve-uri
function.)]
[Definition: Statically-known documents. This is a mapping
from strings onto types. The string representsthe absolute URI of a
resource that is potentially available using the fn:doc
function. Thetypeis the type of the document node that would result
from calling the fn:doc
function with thisURI as its
argument.]
Ifthe argument to fn:doc
is not a
stringliteral that is present in statically-known documents, thenthe
static typeof
fn:doc
is document-node()?
.
Note:
Thepurpose of the statically known
documentsis to provide type information,not to determine
whichdocuments are available. A URI need not be foundin the
statically known documents to be accessed using
fn:doc
.
[Definition: Statically-knowncollections.This is a
mappingfromstringsontotypes. Thestring represents the absolute
URIof a resourcethat is potentially available using the
fn:collection
function. Thetype is thetype of the
sequence of nodes that wouldresultfrom calling the
fn:collection
function with thisURI as its
argument.]If the argument to
fn:collection
is not a string literal that ispresent in
statically-known collections, then
the statictypeof
fn:collection
is node()?
.
Note:
The purpose of the statically known
collectionsis to provide type information, not to determine
whichcollections are available.A URI need not be found in the
statically known collections tobe accessed using
fn:collection
.
[Definition: The dynamic context ofan expression is definedas information that is available at the time the expression is evaluated.] If evaluation of an expression relies on some part of the dynamiccontext that has not been assigned a value, a dynamic error is raised.[err:XP0002]
The individual components of the dynamic context are summarized below. Further rules governing the semantics of these components canbe found in C.2 Dynamic Context Components.
The dynamic context consists of all the components of the static context, and the additional components listed below.
[Definition: The first three components of the dynamiccontext (context item, context position, and context size) are called the focus of the expression. ] The focus enables the processor to keep track of which nodes are being processed by the expression.
Certain language constructs, notably the path
expression E1/E2
and the predicate
expression E1[E2]
, create a new focus
for the evaluation of a sub-expression. In these constructs, E2
is evaluated once for each item in the
sequence that results from evaluating E1
. Each time E2
is evaluated, it is evaluated with a
different focus. The focus for evaluating E2
is referred to below as the inner
focus, while the focus for evaluating E1
is referred to as the outer
focus. The inner focus exists only while E2
is being evaluated. When this evaluation
is complete, evaluation of the containing expression continues with
its original focus unchanged.
[Definition: The context item
is the item currently being processed in a path
expression. An item is
either an atomic value or a node.][Definition: When the context item is a
node, it can also be referred to as the context
node.] The context item is returned by the expression
".
". When an expression E1/E2
or E1[E2]
is evaluated, each item in the
sequence obtained by evaluating E1
becomes the context item in the inner focus for an evaluation of E2
.
[Definition: The context
position is the position of the context item within the
sequence of items currently being processed in apath
expression. ]It changes whenever the context item
changes. Its value is always an integer greater than zero. The context
position is returned by the expression fn:position()
. When an expression E1/E2
or E1[E2]
is evaluated, the context position in
the inner focus for an evaluation of E2
is the position of the context item in the sequence obtained by
evaluating E1
. The position of the
first item in a sequence is always 1 (one). The context position is
always less than or equal to the context size.
[Definition: The context
size is the number of items in the sequence of items currently
being processed in a path expression.]Its value is always an
integer greater than zero. The context size is returned by the
expression fn:last()
. When an expression
E1/E2
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
.
[Definition: Dynamic variables. This is a set of (QName, value) pairs. It contains the same QNames as the in-scope variables in the static context for the expression. TheQName is thename of the variable and the value isthe dynamic value of the variable.]
[Definition: Functionimplementations.Each function inin-scopefunctionshas a function implementation that enables the functionto map instances of its parameter types into an instance of its result type. Fora user-defined function,the function implementation isan XQuery expression.For an external function,the function implementation is implementation-dependent.]
[Definition: Current date and time. This information represents
an implementation-dependent point in time during processing of a query or transformation. It can be retrieved by the fn:current-date
, fn:current-time
, and fn:current-dateTime
functions. If invoked multiple times during the execution of a query or transformation,
these functions always return the same result.]
[Definition: 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
xdt:dayTimeDuration
that is
implementation-defined . See [ISO 8601] for the range of legal values
of a timezone.]
[Definition: Available
documents. This is a mapping of
strings onto document nodes. The string
represents the absolute URI ofa
resource. The document node is theroot of a treethat represents that resource using the data model. The document node is returnedby the fn:doc
function when applied to that URI.]The set of available
documentsis not constrained by the set of statically-known
documents,andit may be
empty.
[Definition: Available
collections.This is a mapping of
strings onto sequences of nodes. Thestring
representsthe absolute URI of a
resource.The sequence of nodes represents
theresult of the fn:collection
functionwhen that URI is supplied as the
argument.]The set of available
collectionsisnot constrained by the set ofstatically-known
collections, and it may be empty.
XQuery is defined in terms ofthe data model andin terms of the expression context.
Figure 1: ProcessingModel Overview
Figure 1 providesa schematic overviewof the processing steps that arediscussed in detail below. Some of these steps are completely outsidethe domain ofXQuery; in Figure 1,these are depicted outsidethe line that represents the boundaries of the language, an arealabeled the externalprocessingdomain.The external processing domainincludes generation of thedata model(see 2.2.1 Data The Modelfn:input Generation),schema import processing (see 2.2.2 Schema Import Processing)and serialization(see 2.2.4 Serialization).The area inside the boundaries of the language is known as the query processing domain, which includesthe static analysisand dynamic evaluation phases(see 2.2.3 Expression Processing). Consistencyconstraints on the query processingdomain are defined in 2.2.5 Consistencyis Constraints.
Beforean expression can be processed, the input documents to be accessed by the expression must be represented inthe datamodel.This process occurs outside the domainof XQuery, which is why Figure 1 represents it in the external processing domain. Here are some steps by which anXML documentmight be converted to the data model:
A documentmay be parsed usingan XML parser that generatesan XMLInformation Set(see [XML Infoset]).The parsed document may then be validated against one ormore schemas. This process, which is described in [XML Schema],results in an abstract informationstructure called the Post-SchemaValidation Infoset(PSVI).If a document hasno associated schema, its Information Setis preserved. (See DM1 in Fig. 1.)
The InformationSet or PSVI may be transformed into the data model bya process described in [XQuery 1.0 and XPath 2.0 Data Model].(See DM2 in Fig. 1.)
Theabove steps provide an example of how a document in the datamodelmight be constructed. A document or fragment might alsobe synthesized directly from a relational database, or constructed in some other way (see DM3 inFig. 1.) XQuery is defined in terms ofoperations on the datamodel, butit does not place any constraints on how documents and instances in the datamodel are constructed.
Eachatomicvalue, element node, and attribute node in thedatamodelis annotated with its dynamictype.The dynamic type
specifiesa range of values—for example,an attribute named
version
might have the dynamic type
xs:decimal
,indicating that it contains a decimal
value.For example, if the data
modelwas derived from an input XML document,the dynamic
typesof the elements and attributes are derived from schema
validation.
The valueof an attribute is represented directly within the
attribute node. An attribute node whose type is unknown (such as might
occurin a schemaless document) is annotated with the dynamic type
xdt:untypedAtomic
.
Thevalue of an element is represented by the children ofthe
elementnode, which may include text nodes and other element
nodes. Thedynamic type of an elementnode indicateshow thevalues in
itschild text nodes are to be interpreted. An element whose type is
unknown (such as mightoccur in a schemaless document) is annotated
withthe typexdt:untypedAny
.
Anatomicvalue of unknown type is annotated with the type
xdt:untypedAtomic
.
The in-scope schemadefinitions inthe staticcontext maybe extracted from actualXML Schemata as described in [XQuery 1.0 and XPath 2.0 Formal Semantics](see step SI1 in Figure 1) or may be generatedby some other mechanism (see step SI2 in Figure 1). In either case, the result must satisfy the consistency constraints definedin 2.2.5 Consistencyis Constraints.
XQuerydefines two phases of processing called thestatic analysis phase and the dynamic evaluation phase (see Fig. 1).Animplementation is free touse any strategy or algorithm whose resultconforms to these specifications.
[Definition: The static analysis phasedepends on the expression itself and onthe staticcontext.The staticanalysis phasedoes notdepend on inputdata (other than schemas).]
During the static analysis phase, the queryis parsed into an internal representation called the operation tree (step SQ1 in Figure 1). A parse error is raised as a static error.[err:XP0003] The static context isinitialized by the implementation (step SQ2). Thestaticcontextis then changed and augmented based on informationin the prolog (step SQ3). If the Schema Import Feature is supported, the in-scope schema definitions are populated with information from imported schemata. The static contextis used to resolve type names, function names, namespace prefixes and variable names. Ifa namein the operationtreeis not found in the staticcontext,a staticerror[err:XP0008]is raised (step SQ4).
Theoperationtreeis then normalizedby making explicit the implicit operations suchas atomization, typepromotionand extraction of EffectiveBoolean Values(step SQ5). The normalization processis described in [XQuery 1.0 and XPath 2.0 Formal Semantics].
If the StaticTyping Featureis supported, each expression is assigned a static type (step SQ6).
[Definition: The statictypeof an expression may be either a named type or a structural description—for example, xs:boolean?
denotes an optional occurrence of the xs:boolean
type. The rules for inferring the static types of various expressions are describedin [XQuery 1.0 and XPath 2.0 Formal Semantics].]
In some cases, the static typeis derived from the lexicalform of the expression; forexample, the statictypeof the literal 5
is xs:integer
.In other cases, the statictypeof an expressionis inferred according to rules based on the static types of its operands; for example,the statictypeof the expression 5 + 1.2
is xs:decimal
.
During the staticanalysis phase, ifthe StaticTyping Feature is in effect andan operand of an expression is found to have a static type that is not appropriate for that operand, atype error israised.[err:XP0004] If static type checkingraises no errors and assigns a statictypeT to an expression, then executionof the expression on valid input data is guaranteedeither to produce a value of type T or to raise a dynamicerror.
During the static
analysisphase,if theStaticTyping Feature is in effect andthe statictype assigned to an expression other than ()
is empty
, a staticerroris raised.[err:XP0005]This catchescases in which a query refers toan element or attribute that is not present in the in-scopeschema definitions,possibly because of a spelling error.
Thepurpose of type-checking during the staticanalysis phaseis to provide early detection oftype errors and to infer type information that may be useful in optimizing the evaluation of an expression.
[Definition: The dynamic evaluation phase occurs after completionof the staticanalysis phase. Duringthe dynamicevaluation phase, the value of the queryis computed.]
Thedynamic evaluation phase can occur only if no errors were detected during the staticanalysis phase.If the Static Typing Feature isin effect, all typeerrorsare detected during static analysis and serve to inhibit the dynamic evaluation phase. If the StaticTyping Featureis not in effect, an implementation isallowed to raise type-related warningsduring the staticanalysis phase,but it must proceed with the dynamic evaluation phase despite these warnings. In this case, type errorsmust be detected and raised during the dynamic evaluation phase.
Thedynamic evaluation phase depends on the operation treeof theexpression being evaluated (step DQ1), on the input data(step DQ4), andon the dynamiccontext(step DQ5), which in turn draws information from theexternal environment (step DQ3) andthe staticcontext(step DQ2). Execution of the evaluation phasemay createnewdata-modelvalues(step DQ4)andit may extend the dynamiccontext(step DQ5)—for example, by binding values to variables.
[Definition: A dynamic type is associated with each value as it is computed. The dynamic type of a value may be either a structural description (such as "sequence of integers") or a named type.]The dynamic typeof a value may be more specificthan the statictypeof the expression that computed it (for example, the statictypeof an expression might be "zero or more integers or strings," but at evaluation time its valuemay have the dynamic type "integer.")
If an operandof an expression is found tohave a dynamictypethat is not appropriate for that operand, a type error is raised.[err:XP0006]
Even thoughstatic typing can catch many type errors before an expression is executed, it is possible foran expression to raise an error during evaluation that wasnot detected by static analysis. Forexample, an expression may contain a cast of a string into an integer, whichis statically valid. However, if the actual valueof the string at run time cannot be cast into aninteger, a dynamicerrorwill result. Similarly,an expression may apply an arithmetic operator to a value whose statictypeis xdt:untypedAtomic
. This is nota staticerror,but at run time, if the value cannot be successfully cast to a numeric type, a dynamicerrorwill be raised.
Whenthe Static Typing Feature isin effect, it is also possible for staticanalysis of an expressionto raise a typeerror,even though executionofthe expression on certain inputs wouldbe successful. For example, an expression mightcontain a function that requires anelement as its parameter, and the static analysis phase might infer the statictypeof the function parameter to be an optional element. This case is treated as a typeerrorand inhibits evaluation, even thoughthe function call would have been successfulforinput data in which the optional element is present.
[Definition: Serializationis the processof convertinga set of nodes from the datamodelinto a sequenceof octets (step DM4 in Figure 1.) ]The general frameworkfor serialization ofthe datamodelis described in [XSLT 2.0 and XQuery 1.0 Serialization].
AnXQuery implementationis not required to provide a serialization interface. For example, an implementation may only provide aDOM interfaceor an interfacebased on an event stream. In these cases, serialization wouldbe done outside of the scope of this specification.
[XSLT 2.0 and XQuery 1.0 Serialization]
definesa set of serializationparametersthat govern the
serializationprocess. If anXQuery implementation provides a serialization interface, it must supportthe "xml
"value of the methodparameter. Inaddition, the serialization interface may support (and may expose to users)any of theserialization parameters listed (with default values) in C.3 Serialization Parameters.
Inorder for XQuery to be well defined,the datamodel,the staticcontext,and the dynamiccontextmust be mutually consistent. The consistency constraints listed below areprerequisites for correct functioning of an XQueryimplementation. Enforcement ofthese consistency constraintsis beyond the scope of this specification.
Someof the consistency constraints use theterm datamodel schema.[Definition: Fora given node in the datamodel,the data model schemais defined as the schema from which the type annotation ofthat node was derived.]For anode that was constructed by some processother thanschema validation, the datamodel schema consists simplyof the type definition thatis represented by the type annotationof thenode.
For every data model node that has a type annotation other than xs:anyType
, if that type annotation is found in the in-scopeschema definitions(ISSD), then itsdefinitionin theISSD must be the same as its definition in the datamodel schema.Furthermore,alltypes that are derivedby extension from the given type in the datamodel schemamust also beknown by equivalent definitions inthe ISSD.
Forevery element name EN thatis found both in a data model node and inthe in-scopeschema definitions(ISSD), all elements that are known in the datamodel schemato be inthe same substitution group as ENmust also be known in the ISSD tobe in the same substitution group as EN.
Every item type (i.e., every element, attribute,or type name) referenced in in-scopevariablesor in-scopefunctionsmust be in the in-scopeschema definitions.
For each mapping of a string to a documentnodein available documents,if there exists a mapping of thesame string to adocument type in statically-knowndocuments,the documentnode must match the document type, using the matching rules in 2.4.4 SequenceType Matching.
For each mapping of a string to a sequence of nodes in available collections, if there existsa mapping of thesame string to a type in statically-knowncollections,the sequence of nodes must match the type, usingthe matching rules in 2.4.4 SequenceType Matching.
Thedynamicvariablesin thedynamiccontextand the in-scopevariablesin the staticcontextmust correspondas follows:
Allvariables defined in in-scope variables must be defined in dynamic variables.
For each (variable, type) pair in in-scopevariablesand the corresponding (variable, value) pair in dynamic variables such thatthe variable names areequal, the value must matchthe type, using the matching rules in 2.4.4 SequenceType Matching.
XQueryis generally used to process documents.The representation of a documentis normatively defined in [XQuery 1.0 and XPath 2.0 Data Model].Thefunctions used toaccess documents and collections are normatively defined in[XQuery 1.0 and XPath 2.0 Functions and Operators].Because documents are centrally importantin XQuery processing, we provide a summary of some key conceptshere.
Anordering called documentorderis definedamong all the nodes used during a given query or transformation, which may consistof one or more trees (documents or fragments). Document orderis defined in [XQuery 1.0 and XPath 2.0 Data Model], and its definition is repeated here for convenience.
Document order is a total ordering, although the relative order ofsome nodes is implementation-dependent. Informally,document order is the order returnedby an in-order, depth-first traversal ofthe data model. Document order is stable,which meansthat the relative orderof two nodes willnot changeduring the processing of a given query or transformation, even if thisorder is implementation-dependent.
Within a tree, document order satisfies thefollowingconstraints:
Theroot node is the first node.
The relative order of siblings isdetermined by their order in the XML representation of the tree. A node N1 occurs beforea node N2in document order if and only if the startof N1 occurs before the start of N2 inthe XML representation.
Namespace nodes immediately follow the element node with whichthey are associated. The relative order of namespace nodes is stable but implementation-dependent.
Attributenodes immediately follow the namespace nodes of the element with which they areassociated. The relative order of attributenodes is stable but implementation-dependent.
Element nodes occur before their children; children occur beforefollowing-siblings.
Therelative orderof nodes in distinct trees is stable but implementation-dependent, subjectto thefollowing constraint: If any node in treeT1 isbefore anynode in tree T2, then all nodes in treeT1 are before all nodes in treeT2.
The semanticsof some
XQueryoperators depend on a process called atomization. [Definition: Atomization is
applied to a value when the value is used in a context in which a
sequenceof atomic values is required. The result of atomization is
eithera sequence of atomic valuesor a type error. Atomization of a sequenceis defined as the resultof invoking the fn:data
function
onthe sequence, as definedin [XQuery 1.0 and XPath 2.0 Functions and Operators].]
The semantics of
fn:data
are repeated here for convenience. The result of
fn:data
is the sequence of atomic valuesproduced by
applyingthe following rules to each item in the input
sequence:
Ifthe item is an atomic value, it is returned.
Ifthe item is a node, its typed value is returned.
Atomization is usedin processingthe following typesof expressions:
Arithmeticexpressions
Comparisonexpressions
Functioncalls and returns
Castexpressions
Computedelement and attribute constructors.
Undercertain circumstances (listedbelow), it is necessary to find
the effective booleanvalue of a
value.[Definition: The
effective boolean value of a value is defined as the result
ofapplying the fn:boolean
function to the value, as
defined in [XQuery 1.0 and XPath 2.0 Functions and Operators].]
The semanticsof fn:boolean
are repeated here for convenience. fn:boolean
returns false
if its operandis any of the following:
Anempty sequence
Theboolean value false
Azero-length value oftype xs:string
or xdt:untypedAtomic
Anumeric value that is equal to zero
Thexs:double
or xs:float
value NaN
Otherwise,fn:boolean
returns true
.
Theeffective boolean value ofa sequence is computed implicitly during processing of the following types of expressions:
Logicalexpressions (and
,or
)
Thefn:not
function
Thewhere
clause of a FLWOR expression
Certaintypes of predicates, suchas a[b]
Conditionalexpressions (if
)
Quantifiedexpressions (some
,every
)
Note:
Note that the definition of effective boolean value is not used when casting a value to the type xs:boolean
.
XQuery has a set of functions that provide access to input data. These functions are of particularimportance because they provide a way in which an expression can reference a document or a collection of documents. The input functions are described informally here; they are defined in [XQuery 1.0 and XPath 2.0 Functions and Operators].
An expression can access input documents either by calling one ofthe input functions or by referencing somepart of the expressioncontext that is initialized by the external environment,such as a variable ora context item.
Theinput functions supported by XQuery are asfollows:
The fn:doc
function takes a stringcontaining a URI that refers to an
XML document, and returns a document node whose contentis the data model representation of the given document.
The fn:collection
function takes a string containing a URI, and returns the data model representation of the collection identified by the URI.A collectionmay be
any sequence of nodes. For example, the expression
fn:collection("http://example.org")//customer
identifies allthe
customer
elements that are
descendants of nodes foundin the collection whose URI is
http://example.org
.
If a given input function is invoked repeatedly with arguments that resolve to the same absolute URI during the scope of a single query or transformation, each invocation returns the same result.
XQuery is a strongly typed language with a type system based on [XML Schema]. The XQuery type system is formally defined in [XQuery 1.0 and XPath 2.0 Formal Semantics].
Thein-scopetype
definitionsin the staticcontext
areinitialized with certainpredefined types,
includingthe built-in types of [XML Schema]. These built-in types are in the
namespace
http://www.w3.org/2001/XMLSchema
,
which has the predefined namespace prefix
xs
. Some examples of built-in schema
types include xs:integer
,
xs:string
, and
xs:date
. Elementand attribute
definitionsin the xs
namespace are
notimplicitly included in the static context.
In addition, thepredefined types of XQuery include
the typesdefined in the namespace http://www.w3.org/2003/11/xpath-datatypes
, which has the predefined namespace prefix xdt
. The types in this namespace are defined in [XQuery 1.0 and XPath 2.0 Functions and Operators] and are summarized below.
xdt:anyAtomicType
is
an abstract type that includes all atomic values (and no values that
are not atomic). It is a subtype of xs:anySimpleType
,
which is the base type for all simple types, including atomic, list,
and union types. All specific atomic types such as
xs:integer
, xs:string
, and
xdt:untypedAtomic
, are subtypes of
xdt:anyAtomicType
.
xdt:untypedAny
is a concrete type used to denote the dynamic type of an element node that has not been assigned a more specific type. It has no subtypes. An element that has been validated inskip
mode, or that has a PSVI type property of xs:anyType
, is represented in the Data Model by an element node with the type xdt:untypedAny
.
xdt:untypedAtomic
is a concrete type used to denoteuntyped atomic data, such as text that has not been assigneda more specific type. It has no
subtypes.An attributethat has been validated in skip
mode, or that has a PSVI property of xs:anySimpleType
, is represented in the Data Model by an attribute node with the type xdt:untypedAtomic
.
xdt:dayTimeDuration
is a
concrete subtype of xs:duration
whose lexical representation
contains only day, hour, minute, and second
components.
xdt:yearMonthDuration
is a
concrete subtype of xs:duration
whose lexical representation is
restricted to contain only year and month
components.
The relationships among the types inthe xs
and xdt
namespaces are illustrated in Figure 2. The abstract types, represented byovals in thefigure, may be assigned to an expression during the static analysis phase if no more specific type can be inferred for the expression. During the dynamic evaluation
phase, each node or valuein the data model is assigneda concrete type, representedby one of thetypeslisted in therectangular boxes in
Figure 2. A more complete descriptionof the XQuerytype hierarchycan be found in[XQuery 1.0 and XPath 2.0 Functions and Operators].
Figure 2: Summary of XQuery Type Hierarchy
Inthe data model, every node
has a typed value and a string value.
The typed value of a node is a sequence of atomic values
andcanbe extracted by applying the fn:data
function to
thenode. Thetyped value for eachkind of node is defined bythe
dm:typed-value
accessor in [XQuery 1.0 and XPath 2.0 Data Model].
Thestring
valueof a node is a string and
can be extracted by applying the fn:string
functiontothe node.
Thestring valuefor each kind ofnode
is defined by the
dm:string-value
accessor in [XQuery 1.0 and XPath 2.0 Data Model].
Element and attribute nodes have a type annotation,which
represents(in an implementation-dependent way)the dynamic(run-time) typeof the
node. In the [XQuery 1.0 and XPath 2.0 Data Model],type annotation is
definedby the dm:type
accessor; however,XQuery does
notprovide a way todirectly access the type annotation of an element
orattribute node.
Therelationship between the typed value andthe string value for various kindsof nodes is described and illustrated by examples below.
For text, document,
and namespacenodes, the typed value of the node isthe sameas its
string value, as an instance of the typexdt:untypedAtomic
. (The
string value of a document node is formed by concatenating the string
valuesof all its descendant textnodes, in document
order.)
Thetyped value of a commentor processing instruction node is the same as its string value. It is an instanceof the type xs:string
.
Thetyped value of an attribute node with
thetype annotation xdt:untypedAtomic
is the same as its
string value, asan instance of xdt:untypedAtomic
.The
typedvalue of an attribute node with any other type annotation is
derived from its string value and type annotation in a way that is
consistentwith schema validation.
Example:A1 is an attribute
havingstring value "3.14E-2"
and type annotation
xs:double
. Thetyped value of A1 is the
xs:double
value whose lexical representation is
3.14E-2
.
Example: A2is an attribute with type
annotation xs:IDREFS
, which isa list datatype derived
fromthe atomic datatype xs:IDREF
.Its string value is
"bar baz faz
". The typedvalue of A2is a sequence of
threeatomic values ("bar
","baz
",
"faz
"),eachof type xs:IDREF
. The typed
valueof a node is never treated as an instance of a named list
type. Instead, ifthe typeannotationof a node is a listtype (such
asxs:IDREFS
),its typed value is treated as a sequence
of the atomic type from which it is derived (such as
xs:IDREF
).
Foran element node, the relationshipbetween typed value and string value depends on the node'stype annotation, as follows:
Ifthe type annotation is xdt:untypedAtomic
,or
denotesa complex type with mixed content, then the typed value of the
node is equal to its string value, as an instance of
xdt:untypedAtomic
.
Note:
Since xs:untypedAny
is a complex type with mixed
content,this rule applies to elements whose type is
xs:untypedAny
.
Example:E1 is an element node
havingtype annotation xdt:untypedAny
and string value
"1999-05-31
".The typed value of E1 is
"1999-05-31
",as an instance of
xdt:untypedAtomic
.
Example: E2is an elementnode
with the type annotation formula
,which is a complex type
with mixed content. Thecontent of E2 consists of the character
"H
",a child element named subscript
with
stringvalue "2
",and the character "O
".The
typedvalue of E2 is "H2O
" asan instance of
xdt:untypedAtomic
.
Ifthe type annotationdenotes a simple type ora complex type with simple content,then the typed valueof the node is derived from itsstring value and its type annotation in a waythat is consistent with schema validation.
Example:E3 is an element node with the type
annotationcost
,which is a complex type that has several
attributesand a simple content type of xs:decimal
.The
stringvalue of E3 is "74.95
".The typed value ofE3 is
74.95
, as an instance of
xs:decimal
.
Example: E4 is an element node with the
typeannotation hatsizelist
,which is a simple type
derivedfrom the atomic type hatsize
,which in turn is
derivedfrom xs:integer
.The string value of E4is
"7 8 9
".The typed value of E4 is a sequence of three
values(7
,8
,9
),each of type
hatsize
.
If the type annotation denotesa complex type with empty content, then the typed value of the nodeis the empty sequence.
Ifthe type annotation
denotesa complex type with element-only content, then the typedvalue
of the node is undefined. The fn:data
function raises a
type error [err:XP0007]when applied to such a node.
Example: E5 isan
element node with the type annotation weather
,which is a
complex type whose contenttype specifies
element-only
.E5 has two child elements named
temperature
and precipitation
.The typed
valueof E5 is undefined,and the fn:data
function
appliedto E5 raises an error.
[Definition: When it is necessary to refer to a type in an XQuery expression, the SequenceTypesyntax is used. The name SequenceTypesuggests that this syntax is used todescribe the type of an XQuery value, which is always a sequence.]
[125] | SequenceType | ::= | (ItemType OccurrenceIndicator?) |
[144] | OccurrenceIndicator | ::= | "?" | "*" | "+" |
[127] | ItemType | ::= | AtomicType | KindTest | ("item" "(" ")") |
[126] | AtomicType | ::= | QName |
[128] | KindTest | ::= | DocumentTest |
[137] | PITest | ::= | "processing-instruction" "(" (NCName | StringLiteral)? ")" |
[139] | CommentTest | ::= | "comment" "(" ")" |
[140] | TextTest | ::= | "text" "(" ")" |
[141] | AnyKindTest | ::= | "node" "(" ")" |
[138] | DocumentTest | ::= | "document-node" "(" ElementTest? ")" |
[129] | ElementTest | ::= | "element" "(" ((SchemaContextPath ElementName) |
[130] | AttributeTest | ::= | "attribute" "(" ((SchemaContextPath AttributeName) |
[131] | ElementName | ::= | QName |
[132] | AttributeName | ::= | QName |
[133] | TypeName | ::= | QName |
[134] | ElementNameOrWildcard | ::= | ElementName | "*" |
[135] | AttribNameOrWildcard | ::= | AttributeName | "*" |
[136] | TypeNameOrWildcard | ::= | TypeName | "*" |
[142] | SchemaContextPath | ::= | SchemaGlobalContext "/" (SchemaContextStep "/")* |
[14] | SchemaGlobalContext | ::= | QName | SchemaGlobalTypeName |
[15] | SchemaContextStep | ::= | QName |
[13] | SchemaGlobalTypeName | ::= | "type" "(" QName ")" |
QNames appearing in a SequenceType have their prefixes expanded to namespace URIs by means of the in-scope namespaces and the default element/type namespace. It is a static error [err:XP0008] to use a TypeName in an ElementTest or AttributeTestif that name is not found in the in-scope type definitions. Itis a static error [err:XP0008] to use an ElementName in an ElementTest if that name is not found inthe in-scope element definitions unlessa TypeNameOrWildcard is specified. Itis a static error[err:XP0008]to use a (SchemaContextPathElementName) pair in an ElementTest if the ElementName can not be located from the in-scope element definitionsusing the SchemaContextPath. Itis a static error [err:XP0008] to use an AttributeNamein an AttributeTest if that name is not found in the in-scope attribute definitions unless a TypeNameOrWildcard is specified. It is a static error [err:XP0008] to use a (SchemaContextPath AttributeName) pairin an AttributeTest if the AttributeName can not be located from the in-scope attribute definitions usingthe SchemaContextPath. Ifa QName that is used as an AtomicTypeis not defined as an atomic typein the in-scope type definitions, a static error is raised. [err:XP0051]
Here are some examples of SequenceTypes that might be used in XQuery expressions:
xs:date
refers to the built-in Schema type date
attribute()?
refers to an optional attribute
element()
refers to any element
element(po:shipto, po:address)
refers to an element that has the name po:shipto
(or is in the substitution group of that element), and has the type annotation po:address
(or a subtype of that type)
element(po:shipto, *)
refers to an element named po:shipto
(or in the substitution group of po:shipto
), with no restrictions on its type
element(*, po:address)
refers to an element of any name that has the type annotation po:address
(or a subtype of po:address
). If the keyword nillable
were used following po:address
, that would indicate that the element may have empty content and the attribute xsi:nil="true"
, even though the declaration of the type po:address
has required content.
node()*
refers to a sequence of zero or more nodes of any type
item()+
refers to a sequence of one or more nodes or atomic values
[Definition: During evaluation of an expression, it is sometimes necessary to determine whether a value with a known type "matches" an expected type, expressed inthe SequenceType syntax. This process is known as SequenceType matching.] For example, an instance of
expression returns true
if the actual type of a given value matches a given type, or false
if
it does not.
Note:
Inthisspecification, the word "type", when usedwithout modification, represents a type that can be expressedusing the SequenceType production. When we refer specifically to W3C XML Schema simple or complex types, appropriate modifiers are used to make this clear.
The rules forSequenceType
matching compare the actual type of a value with an expected
type. These rules are a subset of the static typing rules defined in
[XQuery 1.0 and XPath 2.0 Formal Semantics], which compare the static type
ofan expression withthe expected type of the context in which the
expressionis used. Thestatic typing rules area superset of the
SequenceType
matching rules because the statictype of an expression is
typicallymore generalthan the dynamictype of the value produced by
evaluating the expression. For example, the static type of the
expressionif (expr) then "true" else 0
is
xs:string | xs:integer
, as described in [XQuery 1.0 and XPath 2.0 Formal Semantics]. However, if expr
evaluates to true
, thenthe dynamic type of this
expression is xs:string
.
Some ofthe rules for SequenceType matchingrequire matchingof simple or complex types to determine whether a given type is the same asor derived from an expected type. These types may be "known" types, which are definedin the in-scopeschema definitions,or "unknown" types, which are not defined inthe in-scope schemadefinitions. Anunknown type might be encountered, forexample, if the module in which the given type is encountered does not import the schema in whichthe given type isdefined. In this case, an implementation is allowed (but is not required) to provide an implementation-dependent mechanismfor determining whether the unknown type iscompatible with the expected type. Forexample, an implementation might maintain a data dictionary containing information about type hierarchies.
We define theprocess of matching simple or complex types using a
pseudo-function named type-matches(
ET,
AT)
that takes an expectedsimple or complex
typeETand an actual simpleor complextype
AT,and either returns a boolean value or raises a
type error. [err:XP0004][err:XP0006] This pseudo-function
type-matches
is definedas follows:
type-matches(
ET, AT)
returns true
if:
AT is a known type, and is the same as ET,or is derived by one or more steps of restriction or extension from ET, or
AT is anunknown type, and an implementation-dependent mechanism is able to determine that AT is derived by restriction from ET.
type-matches(
ET,
AT)
returns false
if:
AT is a known type, and is not the same as ET, and is not derivedby one or more steps of restriction or extension from ET, or
AT is an unknowntype, and an implementation-dependent mechanism is able to determine that AT is not derived by restriction from ET.
type-matches(
ET,
AT)
raisesa typeerror [err:XP0004][err:XP0006]
if:
ET is an unknown type, or
AT is an unknown type, and the implementation is not able to determinewhether AT is derived by restriction from ET.
Note:
The type-matches
pseudo-function can notbe
written as a real XQuery function, because types are not valid
functionparameters.
The rules forSequenceType matchingare given below, with examples (the examples are for purposes of illustration, and do not cover all possible cases).
The SequenceTypeempty()
matches avalue thatis the empty sequence.
AnItemType with no OccurrenceIndicator matches any value that contains exactly one item ifthe ItemType matches that item(see 2.4.4.2 Matchingas an ItemType and an Item).
An ItemType with an OccurrenceIndicator matches a value if the numberof itemsin the value matches the OccurrenceIndicator and the ItemType matches eachof the items in the value.
An OccurrenceIndicator specifiesthe number of items in asequence, as follows:
?
matches zero or one items
*
matches zero or more items
+
matches one or more items
As a consequenceof these rules, any SequenceType whose
OccurrenceIndicator is *
or ?
matchesa
value that is an empty sequence.
AnItemType consisting simply of aQName is
interpreted as an AtomicType.An AtomicType
AtomicType matchesan atomic value whose actual type is
ATif type-matches(
AtomicType,
AT)
is true
.
Example:The
AtomicTypexs:decimal
matches the value
12.34
(a decimal literal). xs:decimal
also
matches a value whose type is shoesize
, if
shoesize
is an atomic type derived by restriction from
xs:decimal
.
A named atomic type may be a generic type such as
xdt:anyAtomicType
. Note that the names of non-atomic
types such as xs:IDREFS
are not accepted in this context,
but can often be replaced by an atomic type with an occurrence
indicator, such as
xs:IDREF*
.
item()
matches
anysingle item.
Example:item()
matches the atomic
value1
or the element
<a/>
.
node()
matches any node.
text()
matches any
text node.
processing-instruction()
matches any processing-instruction
node.
processing-instruction(
N)
matches any processing-instructionnode whose name (called its
"PITarget" in XML) is equal to N, where N is
an NCName.
Example:
processing-instruction(xml-stylesheet)
matches any
processing instruction whose PITargetis
xml-stylesheet
.
For backward compatibility with
XPath 1.0,the PITarget of a
processing instruction mayalso be expressed as a
string literal, as in this example:
processing-instruction("xml-stylesheet")
.
comment()
matches any comment node.
document-node()
matches any document
node.
document-node(
E)
matches any document node that contains zero or more comments and
processinginstructions and contains exactlyone element node,if
E is an ElementTest that matches the elementnode (see
2.4.4.3 Matchingits an ElementTest and an
Elementor Node).
Example:
document-node(element(book))
matches any document node
containing zero or more comments and processinginstructions and
exactly one element node that ismatched by the ElementTest
element(book)
.
An ItemType that is an ElementTest or AttributeTestmatches an element or attributenode as described in the following sections.
[Definition: An ElementTest isused to match an elementnode by its nameand/or type.]
In thefollowing rules, ElementNameand
TypeNameare names that match the corresponding
productionsin the grammar, where TypeNameis optionally
followedby the keyword nillable
. The pair
SchemaContextPathElementNamerepresentsa path that
matchesthe corresponding productions in the grammar. Note that the
SchemaContextPathElementNamepair is just one path; for
instance,the path hospital/staff/person
is an example of
such a pair, where hospital/staff/
is the
SchemaContextPath andperson
is the
ElementName. Two QNames "match" if their expanded forms
(URIsand localnames) are identical.
AnElementTestmay take one of the following forms:
element()
,
element(*)
,and element(*,*)
match any
singleelementnode, regardlessof its name or
type.
element(
ElementName,
TypeName)
matches a given element node
if:
the name of the element node matches ElementName or matchesthe name of an element in a substitution group headed by anelement with the name ElementName, and:
type-matches(
TypeName,
AT)
is true
, where AT is
the type of the given element node. However, ifthe given element node
hasthe nilled
property, then this rule is satisfied only
ifTypeName is followed by the keyword
nillable
.
Forthis form, thereis no requirement that ElementName be defined inthe in-scope element declarations.
Example: element(person, surgeon)
matches an
non-nilledelement node whose name is person
and whose
typeannotation is surgeon
.
Example:element(person,surgeon nillable)
matches an
element node whose name is person
and whose type
annotation is surgeon
, and permits the element node to
have the nilled
property.
element(
ElementName)
matches anelement node if:
the name of the element node matchesElementName or matchesthe name of an element in a substitution group headed by an element with the name ElementName, and:
type-matches(
ST,
AT)
is true
,where STis
the simpleor complextype of element ElementNameinthe in-scopeelement declarations,and
ATis the type of the given element node. However, if the
given element node has thenilled
property, then this
ruleis satisfied onlyif STincludes the
nillable
option.
Example:
element(person)
matches an element node whose name is
person
and whose type matches the type of the top-level
person
element declaration in the in-scope element
declarations.
element(
ElementName,
*)
matches anelement node of any type if the name of the
element matches ElementName or matchesthe name of an
element in a substitution group headed by anelement with the name
ElementName.
For this form, there is no requirement that ElementNamebe defined in the in-scopeelement declarations.
Example:element(person,
*)
matches any element node whose name is person
,
regardless of its type.
element(*,
TypeName)
matches a given element
noderegardless of its name, if
type-matches(
TypeName,AT)
is
true
,where AT isthe type ofthe given
elementnode. However, if the given element node has the
nilled
property, then thisrule is satisfiedonly if
TypeNameis followed by thekeyword
nillable
.
Example: element(*,surgeon)
matchesany non-nilled element node whose type annotation is
surgeon
, regardless of its name.
Example:
element(*,surgeon nillable)
matches any element node
whose type annotation is surgeon
, regardless of its name,
andpermits the element to have the nilled
property.
element(
SchemaContextPath
ElementName)
matches agiven element node
if:
thename of the given element node matches the ElementName,and:
type-matches(
ST,
AT)
is true
,where
ST
isthe typeof the elementdeclaration thatwould be
associatedwith an element named ElementNamein
thecontext identified by
SchemaContextPath. (This may be eithera locally
declaredelement or atop-level element.)
However, ifthe given element node hasthe
nilled
property, then this rule is satisfied
onlyif STincludes the nillable
option.If SchemaContextPathand ElementNametogether do not identify a valid schema path in the in-scopeschema definitions,a staticerror is raised.[err:XP0055]
Example:element(hospital/staff/person)
matches an
element node whose name is person
andwhose type
matchesthe typeof the elementidentifiedby the schema path
hospital/staff/person
.
Example: element(type(schedule)/person)
matches an
elementnode whose name is person
and whose type
matchesthe typeof a person
element within the named
type schedule
.
[Definition: An AttributeTest is used to match an attribute node by its name and/or type.]
Inthe following rules, AttributeNameand
TypeNameare names that match the corresponding
productionsinthe grammar.
Thepair SchemaContextPathAttributeNamerepresents a
paththat matches the corresponding productions in the grammar. Note
thatthe SchemaContextPathAttributeNamepair is just one
path;for instance, the path catalog/product/price
is an
exampleof such a pair, where catalog/product/
is the
SchemaContextPath and price
is the
AttributeName. Two QNames "match" if their expanded forms
(URIs and local names)are identical.
AnAttributeTest maytake one of the following forms:
attribute()
,attribute(*)
,and
attribute(*,*)
match any single attribute node,
regardlessofits nameor type.
attribute(
AttributeName,
TypeName)
matches a given attribute node
if:
the name of the given attribute node matches AttributeName, and:
type-matches(
TypeName,
AT)
is true
, where AT is
the type annotation of the given attribute
node.
For this form,there is norequirement that AttributeName be defined in the in-scopeattribute declarations.
Example:attribute(price,currency)
matches an
attribute node whose name is price
and whose type
annotation is
currency
.
attribute(
AttributeName)
matches a given attribute node if:
the name of the given attribute node matchesAttributeName, and:
type-matches(
ST,
AT)
is true
,where STis
the simpleor complextype of attribute AttributeNameinthe
in-scopeattribute declarations,
andATis the type of the given attribute
node.
Example:attribute(price)
matchesan attribute node whose name is price
and whose
type annotation matchesthe top-level attributedeclaration for a
price
attribute.
attribute(
AttributeName,
*)
matches anattribute node of any type if the name of the
node matchesAttributeName.
For this form, there is no requirement that AttributeNamebe defined in the in-scope attribute declarations.
Example:
attribute(price,*)
matches any attribute node whose name
is price
, regardless of its type
annotation.
attribute(*,
TypeName)
matches a given attribute
node if type-matches(
TypeName,
AT)
is true
, whereATis
thetype annotationof the given attribute node.
Example:
attribute(*,currency)
matches any attribute node whose
type annotation is currency
, regardless of its
name.
attribute(
SchemaContextPath
AttributeName)
matches a given attribute node
if:
the name of the given attribute node matchesthe AttributeName, and:
type-matches(
ST,
AT)
is true
,where ST
isthe type of the attribute declaration that would be
associatedwith an attribute named AttributeName
inthe context identified by
SchemaContextPath.(This may be either a locally
declared attributeor a top-level
attribute.)
Example: attribute(catalog/product/price)
matchesan
attribute node whose name is price
and whosetype matches
the type of the attributeidentified by the schema path
catalog/product/price
.
Example:
attribute(type(plan)/price)
matchesan attribute node
whosename is price
and whose type matches the typeof a
price
attribute within the globally defined type
plan
.
Asdescribed in 2.2.3 Expression Processing,XQuery definesan analysisphase,which does not depend on input data,and anevaluationphase,which doesdepend oninput data. Errorsmay be raised during each phase.
[Definition: Astatic erroris an errorthat mustbe detected during the analysis phase. A syntax error is anexampleof a staticerror. Themeans by which staticerrorsare reportedduring the analysisphase is implementation-defined. ]
[Definition: A dynamic erroris anerror that mustbe detected during the evaluation phase and may be detected duringthe analysisphase. Numericoverflow is an example of a dynamic error. ]
[Definition: Atype errormay be raised during the analysisorevaluation phase. Duringthe analysis phase, a typeerroroccurs whenthe statictypeof anexpression does not match the expected type of the contextin whichthe expressionoccurs. Duringthe evaluationphase, a typeerroroccurs whenthe dynamictype of a value does not matchthe expectedtypeof the context in which thevalue occurs. ]
The outcome of the analysis phase is either success or one or more type errors and/or static errors. The result of the evaluation phase is either a result value, a type error, or a dynamic error.
If anyexpression (at any level) canbe evaluated during the
analysisphase (because all its explicitoperands are known and it hasnodependencies on the dynamic context), then any error in performing
thisevaluation may be reported as a static error. However, the
fn:error()
function must notbe evaluated during the
analysis phase. For example,an implementation isallowed (but not
required)to treat the following expression as a staticerror, because
it callsa constructor function with a constant string that is not in
the lexical space of the target type:
xs:date("Next Tuesday")
In addition to staticerrors,dynamicerrors,and type errors, an XQuery implementation may raise warnings, either during the analysis phase or the evaluation phase. The circumstances in which warnings are raised, and the ways in which warnings are handled, are implementation-defined.
In addition to the errors defined in this specification, an implementation may raise a dynamic error if insufficient resources are available for processing a given expression. For example, an implementation may specify limitations on the maximum numbers or sizes of various objects. These limitations, and the consequences of exceeding them, are implementation-dependent.
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 raises an error, the implementation may choose which error is raised by the expression. For example, in this expression:
($x div $y) + xs:decimal($z)
both the sub-expressions ($x div $y)
and xs: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.[Definition: Anerrorvalue isa single item or the 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 stringvalue 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 div
operator raises an error if itssecond operand
equalszero.
An error can be raised explicitly by calling the
fn:error
function, which only raises an error and never
returns a value. This function is defined in [XQuery 1.0 and XPath 2.0 Functions and Operators].
The fn:error
function
takes an optional item as its parameter, which is the error value.For example, the following
function call raises a dynamic
error
whose error value is a string:
fn:error(fn:concat("Unexpected value ", fn:string($v)))
Because different implementations may choose to evaluate or optimize an expression in different ways, the detection and reporting of dynamic errors is implementation-dependent.
When an implementation is able to evaluate an expression without evaluating some subexpression, the implementation is never required to evaluate that subexpression solely to determine whether it raises a dynamic error.For example, if a function parameter is never used in the body of the function, an implementation may choose whether to evaluate the expression bound to that parameter in a function call.
Similarly, in evaluating an expression,an implementationisnot required tosearch for data whose only possible effect on the result would be to raisean error, as illustratedin the following examples.
Ifan implementation canfind (for example, by usingan index)that at
leastone item returned by $expr1
in the following examplehas the value 47
,it is allowedto
return true
asthe resultof the some
expression,without searching for
anotheritem returned by$expr1
that wouldraise an error because it is
not an integer.
some $x in $expr1 satisfies $x = 47
In
the following example, ifanimplementation can find (for example, byusing anindex) the product
element-nodes that have an id
child with the value47
, itis allowed to returnthese nodes asthe resultof the pathexpression, without searching for another product
nodethat
wouldraise an error becauseit has anid
child whose value is not an integer.
//product[id = 47]
Insome cases, an optimizer may be able to achieve substantial performanceimprovements by rearranging an expression so that the underlyingoperations are performed in a differentorder than that inwhich they are written.Insuch cases, errors may be raised that would not have been raisedif the expression were evaluated as written. However, an expression must notbe rearrangedin a way that changes its result value in the absenceof errors.
Theexpressioninthefollowing examplecannot raise a castingerror if itis evaluated exactlyas written(i.e., left toright). An implementation is permitted,however, to reorder the predicatesto achieve better performance(for example, by taking advantage of anindex). This reorderingcould cause the expression to raise an error.
$N[@x castable as xs:date][xs:date(@x) gt xs:date("2000-01-01")]
To
avoid unexpected errors caused by reordering of expressions,
teststhat aredesigned to prevent dynamic errors should be expressed
using conditionalor
typeswitch
expressions. Conditional andtypeswitch
expressions raiseonly dynamic errors that occur in the branchthat is actually selected.
Unlikethe previous example, the following example cannot raise a dynamic error if@x
is not castable into an xs:date
.
$N[if (@x castable as xs:date) then xs:date(@x) gt xs:date("2000-01-01") else false()]
XQuery definesseveral optional features,which are described in this section.
[Definition: If the Schema Import Feature is supported, aPrologmay contain a schemaimport.Definitions fromthe importedschema are addedto the in-scope schema definitions.]If more than one schema is imported, the definitions contained in these schemas are collected into a single pool of definitions. This pool of definitions must satisfy the conditions for schema validity set out in Sections 3 and 5 of [XML Schema] Part 1. In brief, the definitions must be valid, they must be complete, and they must be unique—that is, the pool of definitions must not contain two or more schema components with the same name and target namespace. If any of these conditions is violated, a static error israised.[err:XQ0012]
If an XQuery implementation that does not support the Schema Import Feature encounters a schema import, it raises a static error.[err:XQ0009] In such an implementation, the in-scope type definitions consist only of predefined type definitions, as described in C.1 Static Context Components.
[Definition: An XQuery implementationthat does not support the Static Typing Feature is not required to raise typeerrors during the staticanalysis phase.]However, non-type-relatedstaticerrorsmust be detected and raised during the static analysis phase.
An XQuery implementation that doesnot support the FullAxis Featureraises a staticerror[err:XQ0010]if anyof the following axes are encountered ina path expression:
ancestor ancestor-or-self following following-sibling preceding preceding-sibling
AnXQuery implementation that supports the Full Axis Feature must recognize the axes on the above list (however, XQuery doesnot recognize the namespace
axis defined by XPath).
An XQuery implementation that does not supportthe Module Featureraises a static error[err:XQ0016]ifitencountersa moduledeclarationor a moduleimport.Since a moduledeclarationis required in a librarymodule,the Module Feature is required in order to create a librarymodule.In the absenceof this feature, each query consists of a single main module.
[Definition: A pragma may be used to provide additional information to an XQuery implementation.] The use of a pragma does not negate the requirement to support normal XQuery functionality in the absence of the pragma.
[1] | Pragma | ::= | "(::" "pragma" QName PragmaContents* "::)" | /* gn: parens */ |
[5] | PragmaContents | ::= | Char |
The QName is any QName that contains an explicit namespace prefix. PragmaContents may consist of any sequence of characters that does not include the sequence "::)
". Pragmas may be used
anywhere that ignorable whitespace is allowed.See A.2 Lexical structure for the exact lexical states where pragmas are
recognized. A pragma is identified by its
QName.
If an implementation does not support a pragma, then that pragma shall be ignored. If an implementation does support a pragma and the implementation determines that the PragmaContents are invalid, then a static error is raised.[err:XQ0013] Otherwise, the effect of the pragma on the result of the Query is implementation-defined.
The following example shows how a pragma might be used:
declare namespace exq = "http://example.org/XQueryImplementation";
(:: pragma exq:timeout 1000 ::)
fn:count($doc//author)
An implementation that supports the exq:timeout
pragma might raise a
dynamic error if it is unable to count the authors within 1000 seconds. An
implementation that does not support this pragma would execute as long as
necessary to count the authors.
[Definition: An implementation may extend XQuery functionality by supporting must-understand extensions. A must-understand extension may be used anywhere that ignorable whitespace is allowed.]
[2] | MUExtension | ::= | "(::" "extension" QName ExtensionContents* "::)" | /* gn: parens */ |
[6] | ExtensionContents | ::= | Char |
The QName is any QName that
contains an explicit namespace prefix. ExtensionContents may consist of any sequence of characters that does not include the sequence "::)
". See A.2 Lexical structure for the
exact lexical states where these extensions are recognized. A must-understand
extension is identified by its QName.
If an implementation does not support a must-understand extension, then a static error is raised.[err:XQ0014] If an implementation does support a must-understand extension and the implementation determines that the ExtensionContents are invalid, then a static error is raised. Otherwise, the effect of the must-understand extension on the result of the Query is implementation-defined.
The following example shows how a must-understand extension might be used:
declare namespace exq = "http://example.org/XQueryImplementation";
for $e in fn:doc("employees.xml")//employee
order by $e/lastname (:: extension exq:RightToLeft ::)
return $e
An implementation that supports the exq:RightToLeft
extension might order the last names by examining characters from right to
left instead of from left to right. An implementation that does not support this
extension would raise a static error.
[Definition: An XQuery Flagger is a facility that is provided by an implementation that is able to identify queries that contain must-understand extensions.If an implementation supports must-understand extensions, then an XQuery Flagger must be provided.] The XQuery Flagger is disabled by default; the mechanism by which the XQuery Flagger is enabled is implementation-defined.Ifthe XQuery Flagger isenabled, a static error [err:XQ0015]is raisedif the querycontains a must-understand extension.
An XQuery Flagger is provided to assist programmers in producing queries that are portable among multiple conforming XQuery implementations.
The following example illustrates how an XQuery Flagger might be used:
xquery RightToLeft.xquery -Flagger=on
If RightToLeft.xquery
contains a must-understand extension such as exq:RightToLeft
, then this XQuery invocation will result in a static error.If the XQuery Flagger was not enabled and the implementation supports exq:RightToLeft
, then this query might execute without error.
In some cases, the static typing rules defined in [XQuery 1.0 and XPath 2.0 Formal Semantics]
are not very precise (see, for instance, the type inference rules for the
ancestor axes—parent, ancestor, and ancestor-or-self—and for the
function fn:root
). Some implementations may wish to support more precise
static typing rules.
A conforming implementation may provide a static typing extension. [Definition: A static typing extension is a type inference rule that infers a more precise static type than that inferred by the type inference rules in [XQuery 1.0 and XPath 2.0 Formal Semantics].] That is, given an expression E, and its static type T inferred by the type inference rules in [XQuery 1.0 and XPath 2.0 Formal Semantics], an implementation may infer a static type T1 for E such that T1 is a subtype of T (that is, all instances of T1 are also instances of T).
[Definition: An XQuery Static Flagger is a facility that is able to identify queries that require a static typing extension.] If an implementation supports static typing extensions, then it must also provide an XQuery Static Flagger. The XQuery Static Flagger is disabled by default; the mechanism by which it is enabled is implementation-defined. When enabled, the XQuery Static Flagger must raise a static error during the static analysis phase wherever a type error is called for by the rules in [XQuery 1.0 and XPath 2.0 Formal Semantics]. The purpose of an XQuery Static Flagger is to assist programmers in producing queries that are portable among multiple conforming XQuery implementations.
The following example illustrates how an XQuery Static Flagger might be used:
xquery abc.xquery -StaticFlagger=on
If abc.xquery
contains a type error according to the static semantic rules in [XQuery 1.0 and XPath 2.0 Formal Semantics], then this XQuery invocation will result in a static error. If the XQuery Static Flagger was not enabled and the implementation supports a static typing extension, then this query might execute without error.
This section discusses each of the basic kinds of expression. Each kind of expression has a name such as PathExpr
, which is introduced on the left side of the grammar production that defines the expression. Since XQuery is a composable language, each kind of expression is defined in terms of other expressions whose operators have a higher precedence. In this way, the precedence of operators is represented explicitly in the grammar.
The order in which expressions are discussed in this document does not reflect the order of operator precedence. In general, this document introduces the simplest kinds of expressions first, followed by more complex expressions. For the complete grammar, see Appendix [A XQuery Grammar].
[40] | Expr | ::= | ExprSingle ("," ExprSingle)* |
[41] | ExprSingle | ::= | FLWORExpr |
A query may consist of one or more modules, as described in 4 Modules and Prologs. If a query is executable, one of its modules has a Query Body containing an expression whose value is the result of the query. An expression is represented in the XQuery grammar by the symbol Expr.
The XQuery operator that has lowest precedence is the comma operator (describedin 3.3.1 Constructing Sequences), which is used to concatenate two operands to form a sequence. As shown in the grammar, a general expression (Expr) can consist of two operands (ExprSingle) separated by a comma. The name ExprSingle denotes an expression that does not contain a top-level comma operator (despite its name, an ExprSingle may evaluate to a sequence containing more than one item.)
The symbol ExprSingle is used in various places in the grammar where an expression is not allowed to contain a top-level comma. For example, each of the arguments of a function call must be an ExprSingle, because commas are used to separate the arguments of a function call.
After the comma, the expressions that have next lowest precedence are FLWORExpr, QuantifiedExpr, TypeswitchExpr, IfExpr, and OrExpr. Each of these expressions is described in a separate section of this document.
[Definition: Primary expressions are the basic primitives of the language. They include literals, variable references, contextitem expressions,constructors, and function calls. Aprimary expression may also be created by enclosing any expression in parentheses, which is sometimes helpful in controllingthe precedence of operators.] Constructors are described in 3.7 Constructors.
[75] | PrimaryExpr | ::= | Literal | VarRef | ParenthesizedExpr| ContextItemExpr| FunctionCall | Constructor |
[Definition: A literal is a direct syntactic representation of an atomic value.] XQuery supports two kinds of literals: numeric literals and string literals.
[94] | Literal | ::= | NumericLiteral | StringLiteral | |
[95] | NumericLiteral | ::= | IntegerLiteral | DecimalLiteral | DoubleLiteral | |
[7] | IntegerLiteral | ::= | Digits | |
[8] | DecimalLiteral | ::= | ("." Digits) | (Digits "." [0-9]*) | /* ws: explicit */ |
[9] | DoubleLiteral | ::= | (("." Digits) | (Digits ("." [0-9]*)?)) ("e" | "E") ("+" | "-")? Digits | /* ws: explicit */ |
[10] | StringLiteral | ::= | ('"' (PredefinedEntityRef | CharRef | ('"' '"') | [^"&])* '"') | ("'" (PredefinedEntityRef | CharRef | ("'" "'") | [^'&])* "'") | /* ws: significant */ |
[22] | PredefinedEntityRef | ::= | "&" ("lt" | "gt" | "amp" | "quot" | "apos") ";" | /* ws: explicit */ |
[24] | CharRef | ::= | "&#" (Digits | ("x" HexDigits)) ";" | /* ws: explicit */ |
[24a] | Digits | ::= | [0-9]+ | |
[24b] | HexDigits | ::= | ([0-9] | [a-f] | [A-F])+ |
The value of a numeric literal containing no ".
" and no e
or E
character is an atomic value of type xs:integer
. The value of a numeric literal containing ".
" but no e
or E
character is an atomic value of type xs:decimal
. The value of a numeric literal containing an e
or E
character is an atomic value of type xs:double
. Values of numeric literals are interpreted according to the rules in[XML Schema].
The value of a string literal is an atomic value whose type is xs:string
and whose value is the string denoted by the characters between the
delimiting apostrophes or quotation marks. If the literal is delimited by apostrophes, two adjacent apostrophes within the literal are interpreted as a single apostrophe. Similarly, if the literal is delimited by quotation marks, two adjacent quotation marks within the literal are interpreted as one quotation mark.
Note:
If a string literal is used in an XQuery expression contained within the value of an XML attribute, the characters used to delimit the literal must be different from the characters that are used to delimit the attribute. (See 3.7.1.1 Attributes for examples of expressions used in attribute values.)
A string literal may contain a predefined entity reference, which is a short sequence of characters, beginning with an ampersand, that represents a single character that might otherwise have syntactic significance. Each predefined entity reference is replaced by the character it represents when the string literal is processed. The predefined entity references recognized by XQuery are as follows:
Entity Reference | Character Represented |
< | < |
> | > |
& | & |
" | " |
' | ' |
A string literal may also contain a character reference, which is an XML-style reference to a Unicode character, identified by its decimal or hexadecimal code point. For example, the Euro symbol (€) can be represented by the character reference €
.
Here are some examples of literal expressions:
"12.5"
denotes the string containing the characters '1', '2', '.', and
'5'.
12
denotes the integer value twelve.
12.5
denotes the decimal value twelve and one half.
125E2
denotes the double value twelve thousand, five hundred.
"He said, ""I don't like it."""
denotes a string containing two quotation marks and one apostrophe.
"Ben & Jerry's"
denotes the string "Ben & Jerry's
".
"€99.50"
denotes the string "€99.50
".
The boolean values true
and false
can be represented by calls to the built-in functions fn:true()
and fn:false()
, respectively.
Values of other atomictypes 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.
xdt:dayTimeDuration("PT5H")
returns an item whose type is xdt: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:
9 cast as
hatsize
returns the atomic value 9
whose type is hatsize
.
A variable reference is a QName preceded by a $-sign. Two variable references are equivalent if their local names are the same and their namespace prefixes are bound to the same namespace URI in the in-scope namespaces. An unprefixed variable reference is in no namespace.
Every variable reference must match a name in the in-scope variables, which include variables from the following sources:
A variable may be declared in a Prolog, in the current module or an imported module. See 4 Modules and Prologs for a discussion of modules and Prologs.
A variable may be added to the in-scope variables by the host language environment.
A variable may be bound by an XQuery expression. The kinds of expressions that can bind variables are FLWOR expressions (3.8 FLWOR Expressions), quantified expressions (3.11 Quantified Expressions), and typeswitch
expressions (3.12.2 Typeswitch). Function calls also bind values to the formal parameters of functions before executing the function body.
Every variable binding has a static scope. The scope defines where references to the variable can validly occur. It is a static error [err:XP0008] to reference a variable that is not in scope. If a variable is bound in the static context for an expression, that variable is in scope for the entire expression.
If a variable reference matches two or more bindings that are in scope, then the reference is taken as referring to the inner binding, that is, the one whose scope is smaller. At evaluation time, the value of a variable reference is the value of the expression to which the relevant variable is bound. The scope of a variable binding is defined separately for each kind of expression that can bind variables.
[96] | ParenthesizedExpr | ::= | "(" Expr? ")" |
Parentheses may be used to enforce a particular evaluation order in
expressions that contain multiple operators. For example, the expression (2 + 4)
* 5
evaluates to thirty, since the parenthesized expression (2 + 4)
is evaluated first and its result is multiplied by five. Without
parentheses, the expression 2 + 4 * 5
evaluates to twenty-two, because the multiplication operator has higher
precedence than the addition operator.
Empty parentheses are used to denote an empty sequence, as described in 3.3.1 Constructing Sequences.
[74] | ContextItemExpr | ::= | "." |
A context item expression evaluates to
the context item, which may be either a node (as in the
expression
fn:doc("bib.xml")//book[fn:count(./author)>1]
)
or an atomic value (as in the expression (1 to
100)[. mod 5 eq 0]
).
If the context item is undefined, a context item expression raises a dynamic error.[err:XP0002]
A function call consists of a QName followed by a parenthesized list of zero or more expressions, called arguments. If the QName in the function call has no namespace prefix, it is considered to be in the default function namespace.
If the expanded QName and number of arguments in a function call do not match the name and arity of an in-scope function in the static context, a static error is raised.[err:XP0017]
[97] | FunctionCall | ::= | QName "(" (ExprSingle ("," ExprSingle)*)? ")" |
XQuery allows functions to be called. A core library of functions is defined in [XQuery 1.0 and XPath 2.0 Functions and Operators]. Additional functions may be declared in a Prolog, imported from a library module, or provided by the external environment as part of the static context. For details on processing function names that have no namespace prefix, see 4.5 Default Namespace Declaration.
A function call is evaluated as follows:
Argument expressionsare evaluated, producing argument values. The order of argument evaluation is implementation-dependent and a function need not evaluate an argument if the function can evaluate its body without evaluating that argument.
Each argument value is converted by applying the function conversion rules listed below.
If the function is a built-in function, it is evaluated using the converted argument values. The result is a value of the function's declared return type.
If the function is a user-declared function, the converted argument values are bound to the formal parameters of the function, and the function body is evaluated. The value returned by the function body is then converted to the declared return type of the function by applying the function conversion rules.
When a converted argument
value is bound to a function parameter, the argument
value retains its most specific dynamic type, even
though this may be a subtype of the type of the
formal parameter. For example, a function with a
parameter $p
of type
xs:decimal
can be invoked with an
argument of type xs:integer
, which is
derived from xs:decimal
. During the
processing of this function invocation, the dynamic
type of $p
inside the body of the
function is considered to be
xs:integer
. Similarly, the value
returned by a function retains its most specific
type, which may be a subtype of the declared return
type of the function. For example, a function that
has a declared return type of
xs:decimal
may in fact return a value
of dynamic type xs:integer
.
A function does not inherit a focus (context item, context position, and context size) from the environment of the function call. During evaluation of a function body, the focus is undefined, except where it is defined by the action of some expression inside the function body. It is a staticerror [err:XP0018] for an expression to depend on the focus when the focus is undefined.
The function conversion rules are used to convert an argument value or a return value to its expected type; that is, to the declared type of the function parameter or return. The expected type is expressed as a SequenceType. The function conversion rules are applied to a given value as follows:
If the
expected type is a sequence of an atomic type
(possibly with an occurrence indicator *
,
+
, or ?
), the following
conversions are applied:
Atomization is applied to the given value, resulting in a sequence of atomic values.
Each item in the atomic
sequence that is of type
xdt:untypedAtomic
is cast to the expected
atomic type.
For each numeric item in the atomic sequence that can be promoted to the expected atomic type using the promotion rules in B.1 Type Promotion, the promotion is done.
If, after the above conversions, the resulting value does not match the expected type according to the rules for SequenceType Matching, a type error is raised. [err:XP0004][err:XP0006] Ifthe function call takes place in a module other thanthe module in which the function is defined, this rulemust be satisfied inboth the module where the functionis calledand the module where the function isdefined(the test is repeatedbecausethe two modulesmay have different in-scopeschema definitions.) Notethat the rulesforSequenceType Matchingpermit a value of a derived type to besubstituted for a value of its base type.
Since the arguments of a function call are separated by commas, any argument expression that contains a top-level comma operator must be enclosed in parentheses. Here are some illustrative examples of function calls:
my:three-argument-function(1,
2, 3)
denotes a function call with three arguments.
my:two-argument-function((1,
2), 3)
denotes a function call with two arguments, the first of which is a
sequence of two values.
my:two-argument-function(1,
())
denotes a function call with two arguments, the second of which is an
empty sequence.
my:one-argument-function((1, 2,
3))
denotes a function call with one argument that is a sequence of three
values.
my:one-argument-function(( ))
denotes a function call with one argument that is an empty sequence.
my:zero-argument-function( )
denotes a function call with zero arguments.
[3] | ExprComment | ::= | "(:" (ExprCommentContent | ExprComment)* ":)" | /* gn: comments */ |
[4] | ExprCommentContent | ::= | Char | /* gn: parens */ |
XQuery comments can be used to provide informative annotation. These comments are
lexical constructs only, and do not affect the processing of an expression. Comments are delimited by the symbols (:
and :)
. Comments may be nested.
Comments may be used anywhere ignorable whitespace is allowed.See A.2 Lexical structure for the exact lexical states where comments are recognized.
The following is an example of a comment:
(: Houston, we have a problem :)
A path expression can be used to locate nodes within trees.
[69] | PathExpr | ::= | ("/" RelativePathExpr?) | /* gn: leading-lone-slash */ |
[69a] | RelativePathExpr | ::= | StepExpr (("/" | "//") StepExpr)* |
A path expression consists of a series of one or more
steps, separated by "/
" or
"//
", 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.
Each
occurrence of //
in a path expression 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 typeerror is raised.[err:XP0019] 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 Dynamic Context. Each evaluation
of E2
must result in a (possibly empty) sequence of nodes;
otherwise, a type
error is raised.[err:XP0019] The
sequences of nodes resulting from all the evaluations of
E2
are combined, eliminating duplicate nodes based
on node identity and sorting the result 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 fn:root(self::node()) treat as
document-node()
(this is true even if the
"/
" is the entire pathexpression). The effect
of this initial step is to begin the path at the root node of
the tree that contains the context node. If the context item
is not a node, a type
error is raised.[err:XP0020] At
evaluation time, if the root node above the context node is
not a document node, a dynamic error is
raised.[err:XP0050]
The "/
" character is used, with different
meanings, both as an operator or an operand. This causes
lexical difficulties when it appears in leading position in
an expression. For instance, "/*
" is an
expression with a wildcard, and "/*5
" is a parse
error. In general, it is best to use parentheses when
"/
" is used as the first operand of an operator,
e.g. (/) * 5
.
A "//
" at the beginning of a path expression
is an abbreviation for the initial steps
fn:root(self::node()) treat as
document-node()/descendant-or-self::node()
. The
effect of these initial steps is to establish an initial node
sequence that contains the root of the tree in which the
context node is found, plus all nodes descended fromthis
root.
This node sequence is used as the input tosubsequent steps
in the path expression. If the context item is not a node, a
type error is
raised.[err:XP0020] At evaluation time, if the
root node above the context node is not a document node, a
dynamic error is
raised.[err:XP0050]
Note:
The descendants of a node do not include attribute nodes or namespace nodes.
[71] | StepExpr | ::= | AxisStep | FilterStep |
[72] | AxisStep | ::= | (ForwardStep | ReverseStep) Predicates |
[73] | FilterStep | ::= | PrimaryExpr Predicates |
[85] | ForwardStep | ::= | (ForwardAxis NodeTest) | AbbrevForwardStep |
[86] | ReverseStep | ::= | (ReverseAxis NodeTest) | AbbrevReverseStep |
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. XQuery provides two kinds of steps, called filter steps and axis steps.
A filter step consists simply of a primary expression followed by zero or more predicates. The result of the filter step consists of all the items returned by the primary expression for which all the predicates are true. If no predicates are specified, the result is simply the result of the primary expression. This result may contain nodes, atomic values, or any combination of these. The ordering of the items returned by a filter step is the same as their order in the result of the primary expression. Context positions are assigned to items based on their ordinal position in the result sequence. The first context position is 1.
The result of an axis step is always a sequence of zero or more nodes, and these nodes are always returned in document order. An axis step may be either a forward step or a reverse step, followed by zero or more predicates. An axis 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 selects nodes based on their kind, name, and/or type. If the context item is not a node, a type error is raised.[err:XP0020]
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 an axis 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, name,
and/or type 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.4 Abbreviated Syntax.
[89] | ForwardAxis | ::= | ("child" "::") |
[90] | ReverseAxis | ::= | "parent" "::" |
XQuery supports the following axes (subject to limitations as described in 2.6.3 Full Axis Feature):
The child
axis
contains the children of the context
node, which are the nodes returned by
the dm:children
accessor
in [XQuery 1.0 and XPath 2.0 Data Model].
Note:
Only document nodes and element nodes have children. If the context node is any other kind of node, or if the context node is an empty document or element node, then the child axis is an empty sequence. The children of a document node or element node may be element, processing instruction, comment, or text nodes. Attribute, namespace, and document nodes can never appear as children.
the descendant
axis is defined as the transitive closure of
the child axis; it contains the descendants
of the context node (the children, the children of the children, and so on)
the parent
axis contains the sequence
returned by the
dm:parent
accessor in [XQuery 1.0 and XPath 2.0 Data Model], which returns
the parent of the context
node, or an empty sequence
if the context node has no
parent
the
ancestor
axis is
defined asthe transitive
closureof the parent axis; it
contains theancestors of the
contextnode (theparent, the
parent of the parent, and so
on)
Note:
The ancestor axis includesthe root node of the tree in which the context node is found, unless the context node is the root node.
the following-sibling
axiscontains the context node's following
siblings, those children of the context
node's parent that occur after the context
node in document order; if the context node
is an
attribute node or namespace node, the
following-sibling
axis is
empty
the preceding-sibling
axis contains the context node's preceding
siblings, those children of the context
node's parent that occur before the context
node in document order; if the context node
is an attribute node or namespace node, the
following-sibling
axis is
empty
the following
axis
contains all nodes that are
descendants of the root of the tree in
which thecontext node is found, are
not descendants of the context node,
and occur after the context node in
document order
the preceding
axis
contains all nodes that are
descendants of the root of the tree in
which the context nodeis found, are
not ancestors of the context node, and
occur before the context node in
document order
the attribute
axis
contains the attributes of the context node,
which are the nodes returned by the
dm:attributes
accessor in
[XQuery 1.0 and XPath 2.0 Data Model];the axis will be
empty unless the context node is an
element
the self
axis contains just the context node itself
the descendant-or-self
axis contains the context node and the descendants of the context
node
the ancestor-or-self
axis contains the context node and the ancestors of the context node;
thus, the ancestor-or-self axis will always include the root node
Axes can be categorized as forward axes and reverse axes. An axis that only ever contains the context node or nodes that are after the context node in document order is a forward axis. An axis that only ever contains the context node or nodes that are before the context node in document order is a reverse axis.
The parent
,ancestor
,ancestor-or-self
, preceding
,and preceding-sibling
axes are reverse axes; all other axes are forward axes. The ancestor
, descendant
,following
, preceding
and self
axes partition a document (ignoring attribute and namespace nodes):
theydo not overlap and together they contain all the nodes in thedocument.
In a sequence of nodes selected by an axis step, each nodeis assigned a context position that corresponds to its position in the sequence. If the axis is a forward axis, context positions are assigned to the nodes in document order, starting with 1. If the axis is areverse axis, context positions are assigned to the nodes in reverse document order, starting with 1. This makes it possible to select a node from the sequence by specifying its position.
Note:
One example of an expression that uses the
context position is a numeric predicate. The
expression child::para[1]
selects the
first paragraph that is a child of the context node.
A node test is a condition that must be true for each node selected by a step. The condition may be based on the kind of the node (element, attribute, text, document, comment, processing instruction, or namespace), the name of the node, or (in the case of element, attribute, and document nodes), the type of the node.
[91] | NodeTest | ::= | KindTest | NameTest | |
[92] | NameTest | ::= | QName | Wildcard | |
[93] | Wildcard | ::= | "*" | /* ws: explicit */ |
Every axis has a principal node kind. If an axis can contain elements, then the principal node kind is element; otherwise, it is the kind of nodes that the axis can contain. Thus:
For the attribute axis, the principal node kind is attribute.
For all other axes, the principal node kind is element.
A node test that consists only of a QName or a
Wildcard is called a name test. A name
test is true if and only if the kind of
the node is the principal node kind and the
expanded-QName of the node is equal to the expanded-QName specified by the name test. For
example, child::para
selects the para
element children of
the context node; if the context node has no
para
children, it selects an empty set
of nodes. attribute::abc:href
selects
the attribute of the context node with the QName
abc:href
; if the context node has no
such attribute, it selects an empty set of
nodes.
A QName in a name test is expanded into an expanded-QName using the in-scope namespaces in the expression context. It is a static error [err:XP0008] if the QName has a prefix that does not correspond to any in-scope namespace. An unprefixed QName, when used as a name test on an axis whose principal node kind is element, has the namespace URIof the default element/type namespace in the expression context; otherwise, it has no namespace URI.
A name test is not satisfied by an element node whose name does not match the QName of the name test, even if it is in a substitution group whose head is the named element.
A node test *
is true for any node of the principal node kind. For example, child::*
will select all element children of the context node, and attribute::*
will select all attributes of the context node.
A node test can have the form
NCName:*
. In this case, the prefix is
expanded in the same way as with a QName, using the
in-scope
namespaces in the static context.If
the prefix is not found in the in-scope namespaces,
a static
error is raised.[err:XP0008]
The node test is true for any node of the principal
node kind whose expanded-QName has the namespace URI
to which the prefix is bound, regardless of the
local part of the name.
A node test can also
have the form *:NCName
. In this case,
the node test is true for any node of the principal node kind whose local name matches the given NCName,
regardless of its namespace.
An alternative form of a node test is called a KindTest, which can select nodes based on their kind, name, and type annotation. The syntax and semantics of a KindTest are described in 2.4 Types. When a KindTest is used in a node test, only those nodes on the designated axis that match the KindTest are selected. Shown below are several examples of KindTests that might be used in path expressions:
node()
matches any
node.
text()
matches
any text
node.
comment()
matches any comment
node.
element()
matches any element
node.
element(person)
matches any element node whose name is
person
(or is in the substitution group
headed by person
), and whose type
annotation conforms to the top-level element
declaration for a person
element.
element(person,
*)
matches any element node whose name is
person
(or is in the substitution group
headed by person
), without any
restriction on type
annotation.
element(person,
surgeon)
matches any element node whose name
is person
(or is in the substitution
group headed by person
), and whose type
annotation is
surgeon
.
element(*,
surgeon)
matches any element node whose type
annotation is surgeon
, regardless of
its
name.
element(hospital/staff/person)
matches any element node whose name and type
annotation conform to the schema declaration of a
person
element in a staff
element in a hospital
element whose
declaration is a top-level element
declaration.
attribute()
matches any
attribute node.
attribute(price, *)
matches
any attribute whose name is price
,
regardless of its type
annotation.
attribute(*,
xs:decimal)
matches any attribute whose type
annotation is xs:decimal
, regardless of
its
name.
document-node()
matches any document
node.
document-node(element(book))
matches any document node whose content consists of
a single element node that satisfies the KindTest
element(book)
, mixed with zero or more
comments and processing
instructions.
[77] | Predicates | ::= | ("[" Expr "]")* |
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 Dynamic Context. The result of the predicate expression is
coerced to a xs:boolean
value, called the predicate truth value, as
described below. Those items for which the predicate truth value is true
are retained, and those for which the predicate truth value is false
are discarded.
The predicate truth value is derived by applying the following rules, in order:
If the value of the predicate expression is an atomic value of a
numeric type, the predicate truth value is true
if the value of the predicate expression is equal to the context position, and is false
otherwise.
Otherwise, the predicate truth value is the effectiveboolean valueof the predicate expression.
Here are some examples of axis steps that contain predicates:
This example selects the second chapter
element that is a child
of the context node:
child::chapter[2]
This example selects all the descendants of the
context node thatare elementsnamed
"toy"
and whose color
attribute has the value "red"
:
descendant::toy[attribute::color = "red"]
This example selects all the employee
children of the context node
that have a secretary
child element:
child::employee[secretary]
When using predicates with a sequence of nodes selected using a
reverse axis, it is important to remember that the the
context positions for such a sequence are assigned in reverse
document order. For example, preceding::foo[1]
returns the first foo
element in reverse document order, because the
axis that applies to the [1]
predicate is the preceding
axis. By
contrast, (preceding::foo)[1]
returns the first foo
element in document order, because the axis that applies to the [1]
predicate is the child
axis. Similarly, ancestor::*[1]
returns the nearest ancestor element, because the ancestor
axis is a
reverse axis.
Here are some examples of filter steps that contain predicates:
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]
The result of the following expression is the integer 25:
(21 to 29)[5]
This section provides a number of examples of path expressions in which the axis is explicitly specified in each step. The syntax used in these examples is called the unabbreviated syntax. In many common cases, it is possible to write path expressions more concisely using an abbreviated syntax, as explained in 3.2.4 Abbreviated Syntax.
child::para
selects
the para
element children of the context node
child::*
selects all element children of the context node
child::text()
selects all text node children of the context node
child::node()
selects all the children of the context node, whatever their node
type
attribute::name
selects the name
attribute of the context node
attribute::*
selects all the attributes of the context node
parent::node()
selects the parent of the context node. If the context node is an attribute node, this expression returns the element node (if any) to which the attribute node is attached.
descendant::para
selects the para
element descendants of the context node
ancestor::div
selects all div
ancestors of the context node
ancestor-or-self::div
selects the div
ancestors of the context node and, if the context node is a div
element, the context node as well
descendant-or-self::para
selects the para
element descendants of the context node and, if the context node is a para
element, the context node as well
self::para
selects the context node if it is a para
element, and otherwise selects nothing
child::chapter/descendant::para
selects the para
element
descendants of the chapter
element children of the context node
child::*/child::para
selects all para
grandchildren of the context node
/
selects the root of the treethat contains the context node, but raises a dynamic error if this root is not a document 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 a list
parent and that are in the same document as the context node
child::para[fn:position() = 1]
selects the first para
child of the context node
child::para[fn:position() = fn:last()]
selects the last para
child of the context node
child::para[fn:position() = fn:last()-1]
selects the last but one para
child of the context node
child::para[fn:position() > 1]
selects all the para
children of the context node other than the first para
child of the context node
following-sibling::chapter[fn:position() = 1]
selects the next chapter
sibling of the context node
preceding-sibling::chapter[fn:position() = 1]
selects the previous chapter
sibling of the context node
/descendant::figure[fn:position() = 42]
selects the forty-second figure
element in the document containing the context node
/child::book/child::chapter[fn:position() = 5]/child::section[fn:position() = 2]
selects the
second section
of the fifth chapter
of the book
whose parent is the document node that contains the context node
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'][fn:position() = 5]
selects the fifth para
child of the context node that has a type
attribute with value warning
child::para[fn:position() = 5][attribute::type="warning"]
selects the fifth para
child of the context node if that child has a type
attribute with value warning
child::chapter[child::title='Introduction']
selects
the chapter
children of the context node that have one or
more title
children whose typed valueis equal to the
string Introduction
child::chapter[child::title]
selects the chapter
children of the context node that have one or more title
children
child::*[self::chapter or self::appendix]
selects the chapter
and appendix
children of the context node
child::*[self::chapter or
self::appendix][fn:position() = fn:last()]
selects the
last chapter
or appendix
child of the context node
[87] | AbbrevForwardStep | ::= | "@"?NodeTest |
[88] | AbbrevReverseStep | ::= | ".." |
The abbreviated syntax permits the following abbreviations:
The most important abbreviation is that the axis name can be omitted from an axis step. If the axis name is omitted from an axis step, the default axis is child
unless the axis step contains an AttributeTest; in that case, the default axis is attribute
. For example, the path expression section/para
is an abbreviation for child::section/child::para
, and the path expression section/@id
isan abbreviation for child::section/attribute::id
. Similarly, section/attribute(id)
is an abbreviation for child::section/attribute::attribute(id)
. Note that the latter expression contains both an axis specification and a node test.
There is also an abbreviation for
the attribute axis: attribute::
can be
abbreviated by @
. For example, a path expression para[@type="warning"]
is short
for child::para[attribute::type="warning"]
and
so selects para
children with a type
attribute with value
equal to warning
.
//
is effectively replaced by /descendant-or-self::node()/
during processing of a path expression. For example, //para
is an abbreviation for /descendant-or-self::node()/child::para
and so will select any para
element in the document (even a para
element that is a document element will be selected
by //para
since
the document element node is a child of the root node); div1//para
is
short for child::div1/descendant-or-self::node()/child::para
and so will select all para
descendants of div1
children.
Note:
Thepath expression //para[1]
does not mean the same as the path
expression /descendant::para[1]
. The latter selects the first descendant para
element; the former
selects all descendant para
elements that are the first para
children of their parents.
A step consisting
of ..
is short
for parent::node()
. For example, ../title
is short for parent::node()/child::title
and so will select the title
children of the parent of the context node.
Note:
The expression .
, known as a context item
expression, is a primary expression,
and is described in 3.1.4 Context Item Expression.
Here are some examples of path expressions that use the abbreviated syntax:
para
selects the para
element children of the context node
*
selects all element children of the context node
text()
selects all text node children of the context node
@name
selects
the name
attribute of the context node
@*
selects all the attributes of the context node
para[1]
selects the first para
child of the context node
para[fn:last()]
selects the last para
child of the context node
*/para
selects
all para
grandchildren of the context node
/book/chapter[5]/section[2]
selects the
second section
of the fifth chapter
of the book
whose parent is the document node that contains the context node
chapter//para
selects the para
element descendants of the chapter
element children of the context node
//para
selects all
the para
descendants of the root document node and thus selects all para
elements in the same document as the context node
//@version
selects all the version
attribute nodes that are in the same document as the context node
//list/member
selects all the member
elements in the same document as the context node that have a list
parent
.//para
selects
the para
element descendants of the context node
..
selects the parent of the context node
../@lang
selects
the lang
attribute of the parent of the context node
para[@type="warning"]
selects all para
children of the context node that have a type
attribute with value warning
para[@type="warning"][5]
selects the fifth para
child of the context node that has a type
attribute with value warning
para[5][@type="warning"]
selects the fifth para
child of the context node if that child has a type
attribute with value warning
chapter[title="Introduction"]
selects the chapter
children of the context node that have one
or more title
children whose typed valueis equal to the string Introduction
chapter[title]
selects the chapter
children of the context node that have one or more title
children
employee[@secretary and @assistant]
selects all
the employee
children of the context node that have both a secretary
attribute and
an assistant
attribute
book/(chapter|appendix)/section
selects
every section
element that has a parent that is either a chapter
or an appendix
element, that in turn is a child of a book
element that is a child of the context node.
If E
is any expression that returns a sequence of nodes, then the expression E/.
returns the same nodes in document order, with duplicates eliminated based on node identity.
XQuery supports operators to construct and combine sequencesof items. Sequences are never nested—for example, combining the values 1, (2, 3), and ( ) into a single sequence results in the sequence (1, 2, 3).
[40] | Expr | ::= | ExprSingle ("," ExprSingle)* |
[62] | RangeExpr | ::= | AdditiveExpr ( "to" AdditiveExpr )? |
One way to construct a sequence is by using the comma operator, which evaluates each of its operands and concatenates the resulting values, in order, into a single result sequence.
A sequence may contain duplicate values or nodes, but a sequence is never an item in another sequence. When a new sequence is created by concatenating two or more input sequences, the new sequence contains all the items of the input sequences and its length is the sum of the lengths of the input sequences.
In places where the grammar calls for ExprSingle, such as the arguments of a function call, any expression that contains a top-level comma operator must be enclosed in parentheses. Empty parentheses can be used to denote an empty sequence.
Here are some examples of expressions that construct sequences:
The result ofthis expression is a sequence of five integers:
(10, 1, 2, 3, 4)
This expression combines four sequences of length one, two, zero, and two, respectively, into asingle sequence of length five. Theresult of this expressionis the sequence10, 1, 2, 3, 4
.
(10, (1, 2), (), (3, 4))
The result of thisexpression is a sequence containingall salary
children of the context node followed by all bonus
children.
(salary, bonus)
Assuming that $price
is bound to
the value 10.50
, the result of this expressionis the sequence
10.50, 10.50
.
($price, $price)
A range expression can be used to construct a sequence of consecutive
integers. Each of the operands of the to
operator is
converted as though it was an argument of a function with the expected
parameter type xs:integer
.
A typeerror[err:XP0006]is raised if either
operand cannot be converted to a single integer.
If the integer derived from the first operand is greater than the integer derived fromthe second operand, the result ofthe range expression is an empty sequence. Otherwise, the result is a sequence containing the two integer operands and
every integer between the two operands, in increasing order.
This example uses a range expression as one operand in constructing a sequence. It evaluates to the sequence10, 1, 2, 3, 4
.
(10, 1 to 4)
This example constructs a sequence of length one containing the single integer 10
.
10 to 10
The result of this example isa sequence of length zero.
15 to 10
This example uses the fn:reverse
function to construct a sequence of six integers in decreasing order. It evaluates to thesequence 15, 14, 13, 12, 11, 10
.
fn:reverse(10 to 15)
[66] | UnionExpr | ::= | IntersectExceptExpr ( ("union" | "|") IntersectExceptExpr )* |
[67] | IntersectExceptExpr | ::= | ValueExpr ( ("intersect" | "except") ValueExpr )* |
[68] | ValueExpr | ::= | ValidateExpr | PathExpr |
XQuery provides several operators for combining sequences of
nodes. The union
and |
operators are equivalent. They take two node sequences as operands and
return a sequence containing all the nodes that occur in either of the
operands. The intersect
operator takes two node sequences as operands and returns a sequence
containing all the nodes that occur in both operands.
The except
operator takes two node sequences as operands and returns a sequence
containing all the nodes that occur in the first operand but not in the second
operand. All of these operators return their result sequences in document order
without duplicates based on node identity. If an operand
of union
, intersect
, or except
contains an item that is not a node, a type error is raised.[err:XP0006]
Here are some examples of expressions that combine sequences. Assume the existence of three element nodes that we will refer to by symbolic names A, B, and C. Assume that the variables $seq1
, $seq2
and $seq3
are bound to the following sequences of these nodes:
$seq1
is bound to (A,B)
$seq2
is bound to (A, B)
$seq3
is bound to (B,C)
Then:
$seq1 union $seq2
evaluates to the sequence (A,B).
$seq2 union $seq3
evaluates to the sequence (A,B, C).
$seq1 intersect $seq2
evaluates to the sequence (A,B).
$seq2 intersect $seq3
evaluates to the sequence containing B only.
$seq1 except $seq2
evaluates to the empty sequence.
$seq2 except $seq3
evaluates to the sequence containing A only.
In addition to the sequence operators described here,[XQuery 1.0 and XPath 2.0 Functions and Operators] includes functions for indexed access to items or sub-sequences of a sequence, for indexed insertion or removal of items in a sequence, and for removing duplicate values or nodes from a sequence.
XQuery provides arithmetic operators for addition, subtraction, multiplication, division, and modulus, in their usual binary and unary forms.
[63] | AdditiveExpr | ::= | MultiplicativeExpr ( ("+" | "-") MultiplicativeExpr )* |
[64] | MultiplicativeExpr | ::= | UnaryExpr ( ("*" | "div" | "idiv" | "mod") UnaryExpr )* |
[65] | UnaryExpr | ::= | ("-" | "+")* UnionExpr |
Asubtraction operator must be preceded by 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
and a -b
will be interpreted as arithmetic operations.
An arithmetic expression is evaluated by applying the following rules, in order, until an error is raised or a value is computed:
Atomization is applied to each operand.
If either operand is now an empty sequence, the result of the operation is an empty sequence.
If either operand is now a sequence of length greater than one, a type error is raised.[err:XP0006]
If either operand is
now of type xdt:untypedAtomic
, it is cast to the default
type for the given operator. The default type for the
idiv
operator is xs:integer
; the default
type for all other arithmetic operators is xs:double
. If
the cast fails, a dynamic
error is raised.[err:XP0021]
If the operand types are now valid for the given operator, the operator is applied to the operands, resulting in an atomic value or a dynamic error (for example, an error might result from dividing by zero.) The combinations of atomic types that are accepted by the various arithmetic operators, and their respective result types, are listed in B.2 Operator Mapping together with the functions in [XQuery 1.0 and XPath 2.0 Functions and Operators] that define the semantics of the operation for each type.
If the operand types are still not valid for the given operator, a type error is raised.
XQuery supports two division operators named div
and idiv
. Wheninvoked with two integer operands,div
returns a value of type xs:decimal
,but idiv
returns a value of type xs:integer
.
Here are some examples of arithmetic expressions:
The first expression below returns the xs:decimal
value -1.5
, and the second expression returns the xs:integer
value -1
:
-3 div 2 -3 idiv 2
Subtraction of two date values results in a value of type xdt:dayTimeDuration
:
$emp/hiredate - $emp/birthdate
This example illustrates the difference between a subtraction operator and a hyphen:
$unit-price - $unit-discount
Unary operators have higher precedence than binary operators, subject of course to the use of parentheses. Therefore, the following two examples have different meanings:
-$bellcost + $whistlecost
-($bellcost + $whistlecost)
Comparison expressions allow two values to be compared. XQuery provides three kinds of comparison expressions, called value comparisons, general comparisons, and node comparisons.
[61] | ComparisonExpr | ::= | RangeExpr ( (ValueComp | |
[83] | ValueComp | ::= | "eq" | "ne" | "lt" | "le" | "gt" | "ge" | |
[82] | GeneralComp | ::= | "=" | "!=" | "<" | "<=" | ">" | ">=" | /* gn: lt */ |
[84] | NodeComp | ::= | "is" | "<<" | ">>" |
The value comparison operators are eq
, ne
, lt
, le
, gt
, and ge
. Value comparisons are used for comparing single values. The result of a
value comparison is defined by applying the following rules, in order:
Atomization is applied to each operand. If the result, called an atomized operand, does not contain exactly one atomic value, a type error is raised.[err:XP0004][err:XP0006]
Any atomized operand that has the dynamic type xdt:untypedAtomic
is cast to the type xs:string
.
The result of the comparison is true
if the value of the first operand is (equal, not equal, less than, less
than or equal, greater than, greater than or equal) to the value of the second
operand; otherwise the result of the comparison is false
. B.2 Operator Mapping defines which combinations of atomic types
are comparable, and how the comparison operators are mapped into supporting functions.
If the value of the first atomized operand is not comparable with the value of the
second atomized operand, a type error is raised.[err:XP0004][err:XP0006]
Here are some examples of value comparisons:
The following comparison is true only if $book1
has exactly one author
subelement and its typed value is "Kennedy" as an instance of xs:string
or xdt:untypedAtomic
. If $book1
does not have exactly one author
subelement, a type error is raised.[err:XP0004][err:XP0006]
$book1/author eq "Kennedy"
The following comparisons are true because, in eachcase, the two constructed nodes have the same value after atomization, even though they have different identities and/or names:
<a>5</a> eq <a>5</a>
<a>5</a> eq <b>5</b>
The following comparison is true if my:hatsize
and my:shoesize
are both user-defined types that are derived by restriction from a primitive numeric type:
my:hatsize(5) eq my:shoesize(5)
The general comparison operators are =
, !=
, <
, <=
, >
, and >=
. General comparisons are existentially quantified comparisons that may be applied to operand sequences of any length. The result of a general comparison that does not raise an error is
always true
or false
.
Atomization is applied to each operand of a general comparison. The result of the comparison is true
if and only if there is a pair of atomic values, one belonging to the result of atomization of the first operand and the other belonging to the result of atomization of the second operand, that have the required magnitude relationship. Otherwise the result of the general comparison is false
.
The magnitude relationship between two atomic values is determined as follows:
If either atomic value has the dynamic type xdt:untypedAtomic
, that value is cast to a required type, which is determined as follows:
If the dynamic type of the other atomic value is a numeric type, the required type is xs:double
.
If the dynamic type of the other atomic value is xdt:untypedAtomic
, the required type is xs:string
.
Otherwise, the required type is the dynamic type of the other atomic value.
If the cast to the required type fails, a dynamic error is raised.[err:XP0021]
After any necessary
casting, the atomic values are compared using one of the value
comparison operators eq
, ne
,
lt
, le
, gt
, or ge
,
depending on whether the general comparison operator was
=
, !=
, <
,
<=
, >
, or >=
. The
values have the required magnitude relationship if the
result of this value comparison is true
.
When evaluating a general comparison in which either operand is a sequence of items, an implementation may return true
as soon as it finds an item in the first operand and an item in the second operand for which the underlying value comparison is true
. Similarly, a general comparison may raise a dynamic error as soon as it encounters an error in evaluating either operand, or in comparing a pair of items from the two operands. As a result of these rules, the result of a general comparison is not deterministic in the presence of errors.
Here are some examples of general comparisons:
The following comparison is true if the typed value of any
author
subelement of $book1
is "Kennedy" as an instance of xs:string
orxdt:untypedAtomic
:
$book1/author = "Kennedy"
The following example contains three general comparisons. The value of the first two comparisons is true
, and the value of the third comparison is false
. This example illustrates the fact that general comparisons are not transitive.
(1, 2) = (2, 3) (2, 3) = (3, 4) (1, 2) = (3, 4)
Suppose that $a
, $b
, and $c
are bound to element nodes with type annotation xdt:untypedAtomic
, with string values "1
", "2
", and "2.0
" respectively. Then ($a, $b) = ($c, 3.0)
returns false
, because $b
and $c
are compared as strings. However, ($a, $b) = ($c, 2.0)
returns true
, because $b
and 2.0
are compared as numbers.
Node comparisons are used to compare two nodes, by their identity or by their document order. The result of a node comparison is defined by applying the following rules, in order:
Each operand must be either a single node or an empty sequence; otherwise a type error is raised.[err:XP0004][err:XP0006]
If either operand is an empty sequence, the result of the comparison is an empty sequence.
A comparison with the is
operator is true
if the two operands have the same identity,and are thusthe same node; otherwise
it
is false
. See [XQuery 1.0 and XPath 2.0 Data Model] for a definition of node identity.
A comparison with the <<
operator returnstrue
if the firstoperand node precedesthe secondoperand node indocumentorder; otherwise it returnsfalse
.
A comparison with the >>
operator returns true
if the first operand node followsthe second operand node in
document order; otherwise it returns false
.
Hereare some examplesof node comparisons:
Thefollowing comparison is true only ifthe left and right sides eachevaluate to exactly the same single node:
//book[isbn="1558604820"] is //book[call="QA76.9 C3845"]
The followingcomparison is false because each constructed node has its own identity:
<a>5</a> is <a>5</a>
The following comparison is true only if the node identified by the left side occurs before the node identified by the right side in document order:
//purchase[parcel="28-451"] << //sale[parcel="33-870"]
A logical expression is either an and-expression or
an or-expression. If a logical expression does not raise an error, its value is always one
of the boolean values true
or false
.
[55] | OrExpr | ::= | AndExpr ( "or" AndExpr )* |
[56] | AndExpr | ::= | InstanceofExpr ( "and" InstanceofExpr )* |
The first step in evaluating a logical expression is to find the effective boolean value of each of its operands (see 2.3.3 Effectiveprovides 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:
AND: | EBV2 = true | EBV2 = false | error in EBV2 |
EBV1 = true | true | false | error |
EBV1 = false | false | false | false or error |
error in EBV1 | error | false or error | error |
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:
OR: | EBV2 = true | EBV2 = false | error in EBV2 |
EBV1 = true | true | true | true or error |
EBV1 = false | true | false | error |
error in EBV1 | true or error | error | error |
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 true
if the first
expression evaluated is true, and it can raise an error if evaluation
of the first expression raises an error. Similarly, an and-expression
can return false
if the first expression evaluated is
false, and it can raise an error if evaluation of the first expression
raises an error. As a result of these rules, a logical expression is
not deterministic in the presence of errors, as described in 2.5.3 Errors and
Optimization. This is illustrated in the examples
below.
Here are some examples of logical expressions:
The following expressions return
true
:
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, XQuery provides a
function named fn:not
that takes a general sequence as
parameter and returns a boolean value. The fn:not
function
is defined in [XQuery 1.0 and XPath 2.0 Functions and Operators]. The
fn: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,
fn:not
raises thesame dynamicerror.
XQuery provides constructors that can create XML structures within a query. Constructors are provided for every kind of node in the datamodel([XQuery 1.0 and XPath 2.0 Data Model]).Two kinds of constructors are provided: directconstructors,which use an XML-likenotation,and computed constructors,which use a notationbased on enclosed expressions.
This section contains a conceptual description of the semantics of various kinds of constructor expressions. An XQuery implementation is free to use any implementation technique that produces the same result as the processing steps described in this section.
An element constructor creates an XML element. If the name,
attributes, and content of the element are all constants, the element
constructor is based on standard XML notation and is called a direct element constructor. For example, the following expression is a direct element constructor
that creates a book
element containing attributes, subelements, and text:
<book isbn="isbn-0060229357"> <title>Harold and the Purple Crayon</title> <author> <first>Crockett</first> <last>Johnson</last> </author> </book>
Unqualified element names used in a direct element constructor are implicitly qualified by the default namespace for element names. In a direct element constructor, the name used in the end tag must exactly match the name used in the corresponding start tag, including its prefix or absence of a prefix.
In a direct element constructor, curly braces { } delimit enclosed expressions, distinguishing them from literal text. Enclosed expressions are evaluated and replaced by their value, whereas material outside curly braces is simply treated as literal text, as illustrated by the following example:
<example> <p> Here is a query. </p> <eg> $i//title </eg> <p> Here is the result of the query. </p> <eg>{ $i//title }</eg> </example>
The above query might generate the following result (whitespace has been added for readability to this result and other result examples in this document):
<example> <p> Here is a query. </p> <eg> $i//title </eg> <p> Here is the result of the query. </p> <eg><title>Harold and the Purple Crayon</title></eg> </example>
Since XQuery uses curly braces to denote enclosed expressions, some
convention is needed to denote a curly brace used as an ordinary character. For
this purpose, a pair of identical curly brace characters within the content of an element or attribute are interpreted by XQuery as a single curly brace
character (that is, the pair "{{
" represents the
character "{
" and the pair "}}
" represents
the character "}
".) A single left curly brace
("{
") is interpreted as the beginning delimiter for an
enclosed expression. A single right curly brace ("}
")
without a matching left curly brace is treated as a static error.[err:XP0003]
The result of an element constructor is a new element node, with its own node identity. All the attribute and descendant nodes of the new element node are also new nodes with their own identities, even if they arecopies of existing nodes.
The Base URI of a constructed element node is taken from the static context. The Base URIs of the copied descendant nodes are also taken from the static context rather than by preserving their original Base URIs.
The start tag of a direct element constructor may contain one or more attributes. As in XML, each attribute is specified by a name and a value. In a direct element constructor, the name of each attribute is specified by a constant QName, and the value of the attribute is specified by a string of characters enclosed in single or double quotes. As in the main content of the element constructor, an attribute value may contain expressions enclosed in curly braces, which are evaluated and replaced by their value during processing of the element constructor.
Each attribute in a direct element constructor creates a new attribute node, with its own node identity, whose parent is the constructed element node. (Exception: namespace declaration attributes (see 3.7.1.2 Namespace Declaration AttributesNamespaces) do not create attribute nodes.) All the attribute nodes generated by an element constructor must have distinct names.
Conceptually, an attribute (other than a namespace declaration attribute) in a direct element constructor is processed by the following steps:
Predefined entity references and character references in the attribute content are expanded into their referenced strings, as described in 3.1.1 Literals.
Each consecutive sequence of literal characters in the attribute content is treated as a string containing those characters. Whitespace in attribute content is normalized according to the rules for "Attribute Value Normalization" in [XML 1.0] (each whitespace character is replaced by a space (#x20) character.)
Each enclosed expression is converted to a string as follows:
Atomization is applied to the value of the enclosed expression, converting it to a sequence of atomic values.
If the result of atomization is an empty sequence, the result is the zero-length string. Otherwise, each atomic value in the atomized sequence is cast into a string. If any of these atomic values cannot be cast into a string, a dynamic error [err:XQ0052] is raised.
The individual strings resulting from the previous step are merged into a single string by concatenating them with a single space character between each pair.
Adjacent strings resulting from the above steps are concatenated with no intervening blanks. The resulting string becomes the string value of the attribute node.
Example:
<shoe size="7"/>
The value of the size
attribute is "7
".
Example:
<shoe size="{7}"/>
The value of the size
attribute is "7
".
Example:
<shoe size="{()}"/>
The value of the size
attribute is the zero-length string.
Example:
<chapter ref="[{1, 5 to 7, 9}]"/>
The value of the ref
attribute is "[1 5 6 7 9]
".
Example:
<shoe size="As big as {$hat/@size}"/>
The value of the size
attribute is the
string "As big as
", concatenated with the string value of the
node denoted by the expression
$hat/@size
.
The names used inside an element constructor may be qualified names that include namespace prefixes. Namespace prefixes can be bound to namespaces in the Prolog, by namespace declaration attributes, or by computed namespace constructors. It is a static error to use a namespace prefix that has not been bound to a namespace.[err:XP0008]
A
namespace declaration attribute is used inside a direct element constructor, and serves to add a namespace to the in-scopenamespaces for the constructed element,or to specify the default element/type namespace within the scope of the constructed element. A namespace declaration attribute always has the name
xmlns
or a QName with the prefix
xmlns
. If the value of a namespace declaration attribute is not a literal string, a static error is raised.[err:XQ0022] A namespace declaration attribute does not cause an attribute node to be created. Namespace declaration attributes are discussed further in 4.4 Namespace Declaration and 4.5 Default Namespace Declaration. The following element constructor illustrates the use of namespace declaration attributes that define the namespace prefixes metric
and english
:
<box xmlns:metric = "http://example.org/metric/units" xmlns:english = "http://example.org/english/units"> <height> <metric:meters>3</metric:meters> </height> <width> <english:feet>6</english:feet> </width> <depth> <english:inches>18</english:inches> </depth> </box>
The part of a direct element constructor between the start tag and the end tag is called the content of the element constructor. This content may consist of literal text characters, nested element constructors, and expressions enclosed in curly braces. In general, the value of an enclosed expression may be any sequence of nodes and/or atomic values. Enclosed expressions can be used in the content of an element constructor to compute both the content and the attributes of the constructed node.
Conceptually, the content of an element constructor is processed as follows:
The content is evaluated to produce a sequence of nodes called the content sequence, as follows:
Predefined entity references and character references are expanded into their referenced strings, as described in 3.1.1 Literals.
Each consecutive sequence of
literal characters evaluates to a single text node containing the
characters. However, if the sequence consists entirely of
boundary whitespace as defined in 3.7.1.4 Whitespace in Element Content and the Prolog does not specify xmlspace =
preserve
, then no text node is generated.
Each nested element constructor is evaluated according to the rules in this section, resulting in a new element node.
Enclosed expressions are evaluated as follows: For each node returned by an enclosed expression, a new deep copy of the node is constructed, including all its children, attributes, and namespace nodes (if any). Each copied node has a new node identity. Copied element nodes are given the type annotation xs:anyType
, and copied attribute nodes are given the type annotation xs:anySimpleType
. For each adjacent sequence of one or more atomic values returned by an enclosed expression, a new text node is constructed, containing the result of casting each atomic value to a string, with a single blank character inserted between adjacent values. If any of these atomic values cannot be cast into a string, a dynamic error [err:XQ0052] is raised.
If the content sequence contains a document node, a type error is raised.[err:XQ0023]
If the content sequence contains an attribute node following a node that is not an attribute node, a type error is raised.[err:XQ0024] Attribute nodes occurring at the beginning of the content sequence become attributes of the new element node. If two or more attributes of the new element node have the same name, a dynamicerror is raised.[err:XQ0025]
Adjacent text nodes in the content sequence are coalesced into a single text node by concatenating their contents, with no intervening blanks.
The resulting sequence of nodes becomes the children and attributes of the new element node in the datamodelrepresentation.
The new element node is automatically validated, as described in 3.7.1.5 Type of a Constructed Element.
Example:
<a>{1}</a>
The constructed element node has one child, a text node containing the value "1
".
Example:
<a>{1, 2, 3}</a>
The constructed element node has one child, a text node containing the value "1 2 3
".
Example:
<c>{1}{2}{3}</c>
The constructed element node has one child, a text node containing the value "123
".
Example:
<b>{1, "2", "3"}</b>
The constructed element node has one child, a text node containing the value "1 2 3
".
Example:
<fact>I saw 8 cats.</fact>
The constructed element node has one child, a text node containing the value "I saw 8 cats.
".
Example:
<fact>I saw {5 + 3} cats.</fact>
The constructed element node has one child, a text node containing the value "I saw 8 cats.
".
Example:
<fact>I saw <howmany>{5 + 3}</howmany> cats.</fact>
The constructed element node has three children: a text node containing "I saw
", a child element node named howmany
, and a text node containing " cats.
". The child element node in turn has a single text node child containing the value "8
".
In a direct element constructor, whitespace characters may appear in element content. In some cases, enclosed expressions and/or nested elements may be separated only by whitespace characters. For
example, in the expression below, the end-tag
</title>
and the start-tag <author>
are separated by a newline character and four space
characters:
<book isbn="isbn-0060229357"> <title>Harold and the Purple Crayon</title> <author> <first>Crockett</first> <last>Johnson</last> </author> </book>
We will refer to whitespace characters that occur by
themselves in the boundaries between tags and/or enclosed
expressions, as in the above example, as boundary
whitespace. The Prolog contains a declaration called
xmlspace
that controls whether boundary whitespace is
preserved by element constructors. If xmlspace
is not
declared in the prolog or is declared as xmlspace =
strip
, boundary whitespace is not considered significant and
is discarded. On the other hand, if xmlspace =
preserve
is declared in the prolog, boundary whitespace is
considered significant and is
preserved.
Example:
<cat>
<breed>{$b}</breed>
<color>{$c}</color>
</cat>
The constructed
cat
element node has two child element nodes named
breed
and color
. Whitespace surrounding
the child elements has been stripped away by the element
constructor (assuming that the Prolog did not specify
xmlspace =
preserve
.)
Example:
<a> {"abc"} </a>
If
xmlspace
is not declared or is declared as
xmlspace = strip
, this example is equivalent to <a>abc</a>
. However, if
xmlspace = preserve
is declared, this example is
equivalent to <a> abc </a>
.
Example:
<a> z {"abc"}</a>
Since the
whitespace surrounding the z
is not boundary
whitespace, it is always preserved. This example is equivalent to
<a> z abc</a>
.
For
the purpose of the above rule, whitespace characters generated by
character references such as  
or by CDATA sections are not
considered to be boundary whitespace, and are always
preserved. Similarly, whitespace characters that are adjacent to a character reference or a CDATA section are always preserved.
Example:
<a> {"abc"}</a>
This
example is equivalent to <a> abc</a>
, regardless
of the declaration of
xmlspace
.
It is important to remember that whitespace generated by an enclosed expression is never considered to be boundary whitespace, and is always preserved.
Example:
<a>{" "}</a>
This example is
equivalent to <a> </a>
,
regardless of the declaration of
xmlspace
.
A direct element constructor automatically validates the newly constructed element, using the schema validation process described in [XML Schema]. The validation process results in a type annotation for the element node and for its attribute and descendant nodes. The validation process may also result in adding additional attributes, with default values, to the constructed element. Validation is performed using the validation mode and validation context from the static context of the element constructor, according to the following rules:
If validation mode =
skip
, no validation is attempted. The constructed
element node is given a type annotation of xdt:untypedAny
,
and each of its attributes is given a type annotation of
xdt:untypedAtomic
.
If validation
mode = strict
, the in-scope element
declarations are searched for an element declaration whose
unique name matches the name of the constructed element, as
interpreted in the validation context of the element
constructor. If no such element declaration is found, adynamicerror [err:XQ0026]
is raised (if the name of the constructed element is known
statically, this can be a static
error). If such an element declaration is found, the newly constructed element is serialized, using the process defined in [XSLT 2.0 and XQuery 1.0 Serialization]. Theserialized element is treated as the content of a synthetic XML document, which is parsed,resulting in anXMLinformation set([XML Infoset]).This information setis validated according to the rules for "Assessing Schema-Validity"in [XML Schema], using a schema defined by the in-scopeschema definitions,and omitting checks for uniqueness and reference constraints. In the resulting Post-Schema Validation Infoset(PSVI), if the [validity] property of the topmost element information item is valid
, this information item is converted back into thedatamodel,using the mappingdescribed in [XQuery 1.0 and XPath 2.0 Data Model];otherwise, a typeerror is raised.[err:XQ0027]
If validation mode = lax
,
the in-scope element declarations are searched for an
element declaration that matches the name of the constructed
element, as interpreted in the validation context of
the element constructor. If such an element declaration is found,
the constructed element is processed as though validation mode =
strict
; otherwise it is processed as though validation
mode = skip
.
A direct element constructor adds the name of the constructed element to the validation context for expressions that are nested inside the element constructor. This process is illustrated by the following example:
<customer> <hat>{7}</hat> <shoe>{"8"}</shoe> </customer>
If <customer>
is the
outermost element constructor in the query, it is validated with a
global validation context. However, it adds the name of the
constructed element to the validation context for nested
expressions, causing <hat>
and
<shoe>
to be validated with the validation
context /customer
.
It is important to understand
that the type annotation of a constructed element may be different
from the type of the expression from which the element was
constructed. In the above example, the hat
element was
constructed from an expression of type xs:integer
, and
the shoe
element was constructed from an expression of
type xs:string
. If validation mode =
skip
, then after validation the hat
and
shoe
elements will both have a type annotation of
xdt:untypedAny
. However, if validation mode =
strict
, then after validation the hat
and
shoe
elements will have type annotations that are
derived from their element declarations—possibly schema-defined
types such as hatsize
and
shoesize
.
The validation process for a
constructed element may be affected by the presence of an
xsi:type
attribute. For example, the following
constructed element has an attribute that causes it to be validated
as an integer:
<a xsi:type="xs:integer">47</a>
XQuery allows a query to generate a processing instruction, an XML comment, or a CDATA section directly in the query result. In each case, this is accomplished by using a constructor expression whose syntax is based on the syntax of the equivalent construct in XML.
[106] | CdataSection | ::= | "<![CDATA[" Char* "]]>" | /* ws: significant */ |
[107] | XmlPI | ::= | "<?" PITarget Char* "?>" | /* ws: explicit */ |
[18] | PITarget | ::= | NCName | |
[108] | XmlComment | ::= | "<!--" Char* "-->" | /* ws: significant */ |
Each of the above constructors is terminated by the first occurrence of its ending delimiter. In other words, the content of a processing instruction may not contain the string "?>
", the content of an XML comment may not contain the string "-->
", and the content of a CDATA section may not contain the string "]]>
" .
The following example illustrates a constructed processing instruction:
<?format role="output" ?>
The following example illustrates a constructed XML comment:
<!-- Tags are ignored in the following section -->
Note that an XML comment constructor actually constructs a comment node in the data model. An XQuery comment, on the other hand, (see 3.1.6 XQuery Comments) is simply a comment used in documenting a query, and is not evaluated. Consider the following example.
(: This is an XQuery comment :) <!-- This is an XML comment -->
The result of evaluating the above expression is as follows.
<!-- This is an XML comment -->
The following example illustrates a constructed CDATA section:
<![CDATA[ <address>123 Roosevelt Ave. Flushing, NY 11368</address> ]]>
A CDATA section constructor constructs a text node whose content is the same as the content of the constructor. When this text node
becomes a child of an element node, it is merged with adjacent text
nodes in the normal way. A CDATA section constructor may be useful because it removes the need to escape special characters such as "<
" and "&
" within the scope of the CDATA section.
An implementation may choose to serialize text that was constructed using a CDATA section constructor by means of a CDATA section in the serialized output, but it is not obliged to do so. The fact that a CDATA section was used to construct the text is not visible in the data model.
[81] | ComputedConstructor | ::= | CompElemConstructor |
An alternative way to create nodes is by
using a computed constructor. A
computed constructor begins with a keyword that identifies the type
of node to be created: element
,
attribute
, document
, text
,processing-instruction
,comment
, or namespace
.
Forthose kinds of nodes that have names (element, attribute, processing instruction, and namespace nodes), the keyword that specifies the nodekind is followed by the name of the node to be created. This namemay be specified either as a QName or (except for namespace nodes) asan expression enclosed in braces, called the name expression, that returns a string ora QName.
The final part of a computed constructor is an expression enclosed in braces, called the content expression, that generates the content of the node.
The following example illustrates the use of computed element and attribute constructors in a simple case where the names of the constructed nodes are constants. This example generates exactly the same result as the first example in 3.7.1 Direct Element Constructors:
element book {
attribute isbn {"isbn-0060229357" },
element title { "Harold and the Purple Crayon"},
element author {
element first { "Crockett" },
element last {"Johnson" }
}
}
The name expression of a computed element constructor is processed as follows:
Atomizationis applied to the value of the name expression. If the result of atomizationis nota single atomic value of type xs:QName
,xs:string
,orxdt:untypedAtomic
,a type
erroris raised.[err:XP0004][err:XP0006]
Ifthe atomized value of the nameexpressionis of type
xs:QName
,that valueis used as the name of the constructed
element.
If the atomizedvalue of the name expression is of type xs:string
or xdt:untypedAtomic
,that valueis cast to the type xs:QName
using the rulesin [XQuery 1.0 and XPath 2.0 Functions and Operators]. The resulting value is used asthe name ofthe constructed element. A dynamicerroris
raisedif the cast is not successful.[err:XP0021]
The content expression of a computed element constructor is processed as follows:
For each node returned
by the content expression, a new deep copy of the node is
constructed, including all its children, attributes, and namespace
nodes (if any). Each copied node has a new node identity. Copied
element nodes are given the type annotation
xs:anyType
, and copied attribute nodes are given the
type annotation xs:anySimpleType
. For each adjacent
sequence of one or more atomic values returned by the content
expression, a new text node is constructed, containing the result
of casting each atomic value to a string, with a single blank
character inserted between adjacent values. If any of these atomic values cannot be cast into a string, a dynamic error [err:XQ0052] is raised. The resulting sequence
of nodes is called the content
sequence. Any sequence of adjacent text nodes in the content sequence is merged into a single text node.
If the content sequence contains a document node, a type error is raised.[err:XQ0023]
If the content sequence contains a namespace node following a node that is not a namespace node, a type error is raised.[err:XQ0040] Namespace nodes occurring in the content sequence are attached to the constructed elementnode.
If the content sequence contains an attribute node following a node that is not an attribute node or a namespace node, a type error is raised.[err:XQ0024] Attribute nodes occurring in the content sequence become attributes of the new element node. If two or more of these attribute nodes have the same name, an error is raised.[err:XQ0025]
Element, text, comment, and processing instruction nodes in the content sequence become the children of the constructed element node.
The Base URI of a constructed element node is taken from the static context. The Base URIs of the copied descendant nodes are also taken from the static context rather than by preserving their original Base URIs.
A computed
element constructor automatically validates the constructed node,
using the validation mode and validation
context from its static context, as described
in 3.7.1.5 Type of a Constructed
Element. If the name of the
constructed element is specified by a constant QName, this QName is
added to the validation context for nested
expressions. On the other hand, if the name of the constructed
element is specified by a name expression, the
validation context for nested expressions is set to
global
.
A computed element constructor might be
used to make a modified copy of an existing element. For example,
if the variable $e
is bound to an element with numeric
content, the following constructor might be used to create a new
element with the same name and attributes as $e
and
with numeric content equal to twice the value of
$e
:
element {fn:node-name($e)}
{$e/@*, 2 * fn:data($e)}
In this example, if $e
is
bound by the expression let $e := <length
units="inches">{5}</length>
, then the result of the
example expression is the element <length
units="inches">10</length>
.
Note:
The static type of the expression fn:node-name($e)
is xs:QName?
, denoting zero or one QName. Therefore, if the Static Typing Feature is in effect, the above example raises a static type error, since the name expression in a computed element constructor is required to return exactly one string or QName. In order to avoid the static type error, the name expression fn:node-name($e)
could be rewritten as fn:exactly-one(fn:node-name($e))
. If the Static Typing Feature is not in effect, the example can be successfully evaluated as written, provided that $e
is bound to exactly one element node with numeric content.
One important
purpose of computed constructors is to allow the name of a node to
be computed. We will illustrate this feature by an expression that
translates the name of an element from one language to
another. Suppose that the variable $dict
is bound to a
sequence of entries in a translation dictionary. Here is an example
entry:
<entry word="address"> <variant lang="German">Adresse</variant> <variant lang="Italian">indirizzo</variant> </entry>
Suppose further that the variable $e
is bound to the following element:
<address>123 Roosevelt Ave. Flushing, NY 11368</address>
Then the following expression generates a new element in which the name of $e
has been translated into Italian and the content of $e
(including its attributes, if any) has been preserved. The first enclosed expression after the element
keyword generates the name of the element, and the second enclosed
expression generates the content and attributes:
element
{fn:data($dict/entry[word=name($e)]/variant[lang="Italian"])}
{$e/@*, $e/*}
The result of this expression is as follows:
<indirizzo>123 Roosevelt Ave. Flushing, NY 11368</indirizzo>
Note:
As in the previous example, ifthe Static Typing Feature is in effect, the enclosed expression that computes the element name in the above computed element constructor must be wrapped in acall to the fn:exactly-one
function in order to avoid a static type error.
Additionalexamples of computed element constructors can be found in G.4 Recursive Transformations.
The name expression of a computed attribute constructor is processed as follows:
Atomization is applied to the value of the name expression. If the result of atomization is not a single atomic value of type xs:QName
, xs:string
, or xdt:untypedAtomic
, a type
error is raised.[err:XP0004][err:XP0006]
If the atomized value of the name expression isof type
xs:QName
,that value is used as the name of the constructed
attribute.
If the atomized value of the name expression is of type xs:string
or xdt:untypedAtomic
,that value is cast to the type xs:QName
usingthe rules in [XQuery 1.0 and XPath 2.0 Functions and Operators]. The resulting valueis used as the name of the constructed attribute. Adynamic error is
raised ifthe castis not successful.[err:XP0021] In addition,a dynamicerror israised if the URI part of the resultingQName is http://www.w3.org/TR/REC-xml-names
.[err:XQ0044]
The content expression of a computed attribute constructor is processed as follows:
Atomization is applied to the value of the content expression, converting it to a sequence of atomic values.
If the result of atomization is an empty sequence, the value of the attribute is the zero-length string. Otherwise, each atomic value in the atomized sequence is cast into a string. If any of these atomic values cannot be cast into a string, a dynamic error [err:XQ0052] is raised.
The individual strings resulting from the previous step are merged into a single string by concatenating them with a single space character between each pair. The resulting stringis the string value of the attribute.
A computed attribute constructor does not perform any automatic validation of the constructed attribute. However, if the computed attribute constructor is inside an element constructor, the attribute will be validated during validation of its parent element. The type annotation of an unvalidated attribute node is xdt:untypedAtomic
.
Example:
attribute size {4 + 3}
The value of the size
attribute is "7
".
Example:
attribute { if ($sex = "M") then "husband" else "wife" } { <a>Hello</a>, 1 to 3, <b>Goodbye</b> }
The name of the constructed attribute is either husband
or wife
. Its value is "Hello 1 2 3 Goodbye
".
An attribute generated by a computed attribute constructor must not be a namespace declaration attribute—that is, its name must not be xmlns
or a QName with prefix xmlns
.
[99] | CompDocConstructor | ::= | "document" "{" Expr "}" |
All document node constructors are computed constructors. The result of a document node constructor is a new document node, with its own node identity.
A document node constructor is useful when the result of a query is to be a document in its own right. The following example illustrates a query that returns an XML document containing a root element named author-list
:
document
{
<author-list>
{fn:doc("bib.xml")//book/author}
</author-list>
}
The content expression of a document node constructor is processed as follows:
For each
node returned by the content expression, a new deep copy of the
node is constructed, including its children, attributes, and
namespace nodes (if any). Each copied node has a new node
identity. Copied element nodes are given the type annotation
xs:anyType
, and copied attribute nodes are given the
type annotation xs:anySimpleType
. For each adjacent
sequence of one or more atomic values returned by the content
expression, a new text node is constructed, containing the result
of casting each atomic value to a string, with a single blank
character inserted between adjacent values. The resulting sequence
of nodes is called the content
sequence.
If the content sequence contains a document, attribute,or namespace node, a type error is raised.[err:XQ0028]
The resulting sequence of nodes becomes the children of the new document node.
The base URI of a constructed document node is taken from the static context.
No schema validation is performed on the constructed document. The [XML 1.0] rules that govern the structure of an XML document (for example, the document node must have exactly one child that is an element node) are not enforced by the XQuery document node constructor.
[105] | CompTextConstructor | ::= | "text" "{" Expr? "}" |
All text node constructors are computed constructors. The result of a text node constructor is a new text node, with its own node identity.
The content expression of a text node constructor is processed as follows:
Atomization is applied to the value of the content expression, converting it to a sequence of atomic values.
If the result of atomization is an empty sequence, no text node is constructed. Otherwise, each atomic value in the atomized sequence is cast into a string.
The individual strings resulting from the previous step are merged into a single string by concatenating them with a single space character between each pair. The resulting string becomes the content of the constructed text node.
The following example illustrates a text node constructor:
text {"Hello"}
[103] | CompXmlPI | ::= | (("processing-instruction" NCName "{") | ("processing-instruction" "{" Expr "}" "{")) Expr? "}" |
A computed processing instruction constructor (CompXmlPI) constructs a newprocessing instruction node with its own node identity. The name expressionof a computed processing instruction constructoris processed as follows:
If the name expression returnsan expanded QName: If the URI part of the QName is empty, the local part of the QName is used as the name (target) of the processing instruction; otherwise a dynamic error is raised.[err:XQ0041]
If the name expression returns a string, that string is cast to a QName, which is then treated as in the previous item. If the cast fails, a dynamic error is raised.[err:XP0021]
If the name expression does not return a QName or a string, a type error is raised.[err:XP0004][err:XP0006]
The content expression of a computed processinginstruction constructor is processed as follows:
Atomization is applied to the value of the content expression, converting it to asequence of atomic values.
If the result of atomization is an empty sequence, it is replaced by a zero-length string. Otherwise, each atomic value in the atomized sequence is cast into a string.
The individual strings resulting from the previous step are merged into a single string by concatenating them with a single space character between each pair. The resulting string becomes the content of the constructed processing instruction.
The following query contains an example of a computed processing instruction constructor. The result of the query is a processing instruction node.
let $target := "audio-output", $content := "beep" return processing-instruction {$target} {$content}
[104] | CompXmlComment | ::= | "comment" "{"Expr"}" |
Acomputedcomment constructor (CompXMLComment) constructs a new comment node with its own node identity. The content expression of a computed comment constructor is processed as follows:
Atomization is applied to the value of the content expression, converting it to a sequence of atomic values.
If the result of atomization is an empty sequence, it is replaced by a zero-length string. Otherwise, each atomic value in the atomized sequence is cast into a string.
The individual strings resulting from the previous step are merged into a single string by concatenating them with a single space character between each pair. The resulting string becomes the content of the constructed comment.
The following query contains an example of a computed comment constructor. The result of the query is a comment node.
let $homebase := "Houston" return comment {fn:concat($homebase, ", we have a problem.")}
[101] | CompNSConstructor | ::= | |
("namespace" NCName "{")Expr "}" |
A computed namespace constructor (CompNSConstructor) constructs a newnamespace node with its own node identity. The immediately enclosing expression of the computed namespace constructor must be a computed element constructor; otherwise a static erroris raised.[err:XQ0042] The constructed namespace node is attached to the element node constructedby the enclosing expression.
A constructed namespace nodeis the dynamic equivalent of a namespace declaration attribute. It binds a namespace prefix represented as NCName in the syntax) to a URI and adds the namespace prefix to the in-scope namespaces for its enclosing element.
The contentexpressionof a computed namespace constructor is processed as follows:
Atomization isapplied to the value of the content expression, converting it to a sequence of atomic values.
If the result of atomization is an empty sequence, it is replaced by a zero-length string. Otherwise, each atomic value in the atomized sequence is cast into a string.
The individualstrings resulting from the previous step are merged into a single string by concatenating them with a single space character between each pair.The resulting string becomes the content (URI) of the constructed namespace node.
The following query contains an example of a computed namespace constructor, properly nested withina computed element constructor. At evaluation time, the computed namespace constructor constructs a namespace node with prefix myns
and binds it to one of two possible URIs. This namespace node is then available for use in processing namespace prefixes in the content of the xsi:type
attribute.
element {$ename} { namespace myns {if $version eq 1 then "http://example.org/v1" else "http://example.org/v2"}, attribute xsi:type {"myns:invoice"}, $content }
When an element node is constructed by either adirect or computed element constructor, some namespace nodes may be attached tothe constructed element. These namespace nodes may affect the way the element is serialized (see 2.2.4 Serialization). Namespace nodes may also affect the behavior of certain functions that operate on nodes, such as fn:name
.
Note:
The resolution of namespace prefixes during processing ofa query expression is governed by the in-scope namespaces of the expression, not by namespace nodes.
When anelement isconstructed bya direct or computed element constructor, the namespace nodes that are attached to the elementnode are listed below. These namespace nodes are attached to the element node before any validation takes place.
A namespace nodeis created corresponding to each namespace declared in a namespace declaration
attribute of this (or any enclosing) direct element constructor, each computed namespace within this (or any enclosing) computed
element constructor, and the xml
namespace. These
namespace nodes use the same prefixes and URIs as the namespace
declarations from which they arederived (the prefix becomes the name of the
namespace node, and the URI becomes the string value of the namespace node).
A namespacenode is created corresponding to any namespace used in the name of the element or in the names of its attributes.However, a namespace node need not be created if there is already a namespace node fora given namespace URI on a given element. The string value of the created namespace node is the namespace URI of theelement or attributename. The name of the namespace node (which represents the namespace prefix) is implementation-dependent; it must not conflict with the name of any other namespace node for the same element.
Note:
Implementations may in many cases be able to choose a namespace prefix that is familiar to the user, suchas a prefix that is associated with the corresponding namespace URI in either the source document or the query.In some cases, for example to avoid duplicate declarations of the same prefix, an arbitrary choice must be made.
Where a namespace node is created to declare the namespace URI usedin an element name, the namespace prefix can be null (that is, the default namespacecan be used) providedthis does not clashwith an existing declaration of the default namespace on the same element. A namespace node createdto declare the namespace URI of an attribute namecannot use a null prefix, because attributes never use the default namespace URI.
The following query serves as anexample:
declare namespace p="http://example.com/ns/p"; declare namespace q="http://example.com/ns/q"; declare namespace f="http://example.com/ns/f"; <p:a q:b="{f:func(2)}" xmlns:r="http://example.com/ns/r"/>
Theresulting p
element will have four namespace nodes, correspondingto
the following namespaces:
NS0="http://example.com/ns/p"
NS1="http://example.com/ns/q"
r="http://example.com/ns/r"
xml="http://www.w3.org/XML/1998/namespace"
HereNS0
and NS1
represent namespace prefixes. These
namespace nodes are addedto the result element because their respective namespaces
are used in the names of the element and its attributes; the namespace
prefixes are therefore implementation-dependent. The implementation might use the
prefixes p
and q
respectively, but it is not required to do so.
The namespace node r="http://example.com/ns/r"
is attached to the constructedelement, even though it is not actually used, because it is defined by a namespace declaration attribute.
No namespace node correspondingto f="http://example.com/ns/f"
is constructed, becausethe namespace prefix f
appears onlyin the query prologand is not usedin an elementorattribute name of the constructed node. This namespace binding does notappear in the query result, even though it is presentin the in-scopenamespacesand is available for use during processing of the query.
Note thatthe following element constructor will fail with a validation error:
<p xsi:type="xs:integer">3</p>
The constructed element will have namespace nodes corresponding to theprefixes xsi
(because it is used in a name) and xml
(because it is attached to every constructed element node). During validation of the constructed element,the validator will be unable to interpret the namespace prefix xs
because it is not defined in any namespace node.
XQuery provides a feature called a FLWOR expression that supports iteration and binding of variables to intermediate results. This
kind of expression is often useful for computing joins between two or more
documents and for restructuring data. The name FLWOR,
pronounced "flower", is suggested by the keywords for
, let
, where
, order by
, and return
.
[42] | FLWORExpr | ::= | (ForClause | LetClause)+ WhereClause? OrderByClause? "return" ExprSingle |
[43] | ForClause | ::= | "for" "$" VarName TypeDeclaration? PositionalVar? "in" ExprSingle ("," "$" VarName TypeDeclaration? PositionalVar? "in" ExprSingle)* |
[45] | LetClause | ::= | "let" "$" VarName TypeDeclaration? ":=" ExprSingle ("," "$" VarName TypeDeclaration? ":=" ExprSingle)* |
[123] | TypeDeclaration | ::= | "as" SequenceType |
[44] | PositionalVar | ::= | "at" "$" VarName |
[46] | WhereClause | ::= | "where" Expr |
[47] | OrderByClause | ::= | ("order" "by" | "stable" "order" "by") OrderSpecList |
[48] | OrderSpecList | ::= | OrderSpec ("," OrderSpec)* |
[49] | OrderSpec | ::= | ExprSingle OrderModifier |
[50] | OrderModifier | ::= | ("ascending" | "descending")? (("empty" "greatest") | ("empty" "least"))? ("collation" StringLiteral)? |
The for
and let
clauses in a FLWOR expression generate a sequence of tuples of bound variables, called the tuple stream. The where
clause serves to filter the tuple stream, retaining some tuples and discarding others. The order by
clause imposes an ordering on the tuple stream. The return
clause constructs the result of the FLWOR expression. The return
clause is evaluated once for every tuple in the tuple stream, after filtering by the where
clause, using the variable bindings in the respective tuples. The result of the FLWOR
expression is an ordered sequence containing the concatenated results of these
evaluations.
The following example of a FLWOR expression includes all of the possible clauses. The for
clause iterates over all the departments in an input document, binding the variable $d
to each department number in turn. For each binding of $d
, the let
clause binds variable $e
to all the employees in the given department, selected from another input document. The result of the for
and let
clauses is a tuple stream in which each tuple contains a pair of bindings for $d
and $e
($d
is bound to a department number and $e
is bound to a set of employees in that department). The where
clause filters the tuple stream by keeping only those binding-pairs that represent departments having at least ten employees. The order by
clause orders the surviving tuples in descending order by the average salary of the employees in the department. The return
clause constructs a new big-dept
element for each surviving tuple, containing the department number, headcount, and average salary.
for $d in fn:doc("depts.xml")//deptno
let $e := fn:doc("emps.xml")//emp[deptno = $d]
where fn:count($e) >= 10
order by fn:avg($e/salary) descending
return
<big-dept>
{
$d,
<headcount>{fn:count($e)}</headcount>,
<avgsal>{fn:avg($e/salary)}</avgsal>
}
</big-dept>
The clauses in a FLWOR expression are described in more detail below.
The purpose of the for
and let
clauses in a FLWOR expression is to produce a tuple stream in which each tuple consists of one or more bound variables.
The simplest example of a for
clause contains one variable and an associated expression. It evaluates the expression and iterates over the items in the resulting sequence, binding the variable to each item in turn.
A for
clause may also contain multiple variables, each with an associated expression. In this case, the for
clause iterates each variable over the items that result from evaluating its expression. The resulting tuple stream contains one tuple for each combination of values in the Cartesian product of the sequences resulting from evaluating the given expressions. The order of the tuples in the tuple stream is determined by the order of the given expressions, as illustrated in the examples below.
A let
clause may also contain one or more variables, each with an associated expression. Unlike a for
clause, however, a let
clause binds each variable to the result of its associated expression, without iteration. The variable bindings generated by let
clauses are added to the binding tuples generated by the for
clauses. If there are no for
clauses, the let
clauses generate one tuple containing all the variable bindings.
Although for
and let
clauses both bind variables, the manner in which variables are bound is quite
different, as illustrated by the following examples. The first example uses a let
clause:
let $s := (<one/>, <two/>, <three/>)
return <out>{$s}</out>
The variable $s
is bound to the result of the expression (<one/>,
<two/>, <three/>)
. Since there are no for
clauses, the let
clause generates one tuple that contains the binding of $s
.
The return
clause is invoked for this tuple, creating the following output:
<out> <one/> <two/> <three/> </out>
The next example is a similar query that contains a for
clause instead of a let
clause:
for $s in (<one/>, <two/>, <three/>)
return <out>{$s}</out>
In this example, the variable $s
iterates over the given expression; first it is bound to <one/>
, then to <two/>
, and finally to <three/>
. One tuple is generated for each of these bindings, and the return
clause is invoked for each tuple, creating the following output:
<out> <one/> </out> <out> <two/> </out> <out> <three/> </out>
The following example illustrates how binding tuples are generated by a for
clause that contains multiple variables. Note that the order of the tuple stream is determined primarily by the order of the sequence bound to the leftmost variable, and secondarily by sequences bound to other variables, working from left to right.
for $i in (1, 2), $j in (3, 4)
The tuple stream generated by the above for
clause is as follows (the order is
significant):
($i = 1, $j = 3) ($i = 1, $j = 4) ($i = 2, $j = 3) ($i = 2, $j = 4)
The scope of a variable bound in a for
or let
clause comprises all subexpressions of the containing FLWOR expression
that appear after the variable binding. The scope does not
include the expression to which the variable is bound. The following example illustrates how for
and let
clauses may reference variables that were bound in earlier clauses in the same FLWOR expression:
for $x in $w
let $y := f($x)
for $z in g($x, $y)
return h($x, $y, $z)
Each variable bound in a
for
or let
clause may have an optional
type declaration, which is a type declared using the
syntax in 2.4 Types. If the type of a value bound to the variable does not match the declared type according to the rules for SequenceType Matching, a type error is raised.[err:XP0004][err:XP0006] For example, the following expression raises a type error because the variable $salary
has a type declaration that is not satisfied by the value that is bound to the variable:
let $salary as xs:decimal := "cat"
return $salary * 2
Each variable bound in a for
clause may have an associated positional variable that is bound at the same time. The name of the positional variable is preceded by the keyword at
. The positional variable always has an implied type of xs:integer
. As a variable iterates over the items in a sequence, its positional variable iterates over the ordinal numbers of these items, starting with 1. Positional variables are illustrated by the following for
clause:
for $car at $i in ("Ford", "Chevy"), $pet at $j in ("Cat", "Dog")
The tuple stream generated by the above for
clause is as follows (the order is significant):
($i = 1, $car = "Ford", $j = 1, $pet = "Cat") ($i = 1, $car = "Ford", $j = 2, $pet = "Dog") ($i = 2, $car = "Chevy", $j = 1, $pet = "Cat") ($i = 2, $car = "Chevy", $j = 2, $pet = "Dog")
The optional where
clause serves as a filter for the tuples of variable bindings
generated by the for
and let
clauses. The expression in the where
clause, called the where-expression, is evaluated once for
each of these tuples. If the effective boolean value of the
where-expression is true
, the tuple is retained and its variable bindings are used in an
execution of the return
clause. If the effective boolean value of the where-expression is false
, the tuple is discarded. The effective boolean value of an expression is defined in 2.3.3 Effectiveprovides Boolean Value.
The following expression illustrates how a where
clause might be applied to a positional variable in order to perform sampling on an input sequence. This expression approximates the average value in a sequence by sampling one value out of each one hundred input values.
fn:avg(for $x at $i in $inputvalues
where $i mod 100 = 0
return $x)
The return
clause of a FLWOR expression is evaluated once for each tuple in the tuple stream, and the results of these evaluations are concatenated to form the result of the FLWOR expression. If no order by
clause is present, the order of the tuple stream is determined by the orderings of the sequences returned by the expressions in the for
clauses. If an order by
clause is present, it determines the order of the tuple stream. The order of the tuple stream, in turn, determines the order in which the return clause is evaluated using the variable bindings in the respective tuples.
An order by
clause contains one or more ordering specifications, called orderspecs, as shown in the grammar above. For each tuple in the tuple stream, the orderspecs are evaluated, using the variable bindings in that tuple. The relative order of two tuples is determined by comparing the values of their orderspecs, working from left to right until a pair of unequal values is encountered. If the values to be compared are strings, the orderspec may indicate the collation to be used (if no collation is specified, the default collation is used.)
The process of evaluating and comparing the orderspecs is based on the following rules:
Atomization is applied to the result of the expression in each orderspec. If the result of atomization is neither a single atomic value nor an empty sequence, a type error is raised.[err:XP0004][err:XP0006]
If the value of an orderspec has the dynamic type xdt:untypedAtomic
(such as character
data in a schemaless document), it is cast to the type xs:string
.
Each orderspec must return values of the same type for all tuples in the tuple stream, and this type must be a (possibly optional) atomic type for which the gt
operator is defined—otherwise, a typeerror is raised.[err:XP0004][err:XP0006]
When two orderspec values are compared to determine their relative position in the ordering sequence, the greater-than relationship is defined as follows:
When the orderspec specifies empty least
, a value W is considered to be greater than a value V if one of the following is true:
V is an empty sequence and W is not an empty sequence.
V is NaN
, and W is neither NaN
nor an empty sequence.
No collation is specified, and W gt
V is true.
A specific collation C is specified, and fn:compare(V, W, C)
is less than zero.
When the orderspec specifies empty greatest
, a value W is considered to be greater than a value V if one of the following is true:
W is an empty sequence and V is not an empty sequence.
W is NaN
, and V is neither NaN
nor an empty sequence.
No collation is specified, and W gt
V is true.
A specific collation C is specified, and fn:compare(V, W, C)
is less than zero.
When the orderspec specifies neither empty least
nor empty greatest
, it is implementation-defined whether the rules for empty least
or empty greatest
are used.
If T1 and T2 are two tuples in the tuple stream, and V1 and V2 are the first pair of values encountered when evaluating their orderspecs from left to right for which one value is greater than the other (as defined above), then:
If V1 is greater than V2: If the orderspec specifies descending
, then T1 precedes T2 in the tuple stream; otherwise, T2 precedes T1 in the tuple stream.
If V2 is greater than V1: If the orderspec specifies descending
, then T2 precedes T1 in the tuple stream; otherwise, T1 precedes T2 in the tuple stream.
If neither V1 nor V2 is greater than the other for any pair of orderspecs for tuples T1 and T2, then:
If stable
is specified, the original order of T1 and T2 is preserved in the tuple stream.
If stable
is not specified, the order of T1 and T2 in the tuple stream is implementation-dependent.
An order by
clause makes it easy to sort the result of a FLWOR expression, even if the sort key is not included in the result of the expression. For example, the following expression returns employee names in descending order by salary, without returning the actual salaries:
for $e in $employees order by $e/salary return $e/name
The order by
clause is the only facility provided by XQuery for specifying an order other than document order. Therefore, every query in which an order other than document order is required must contain a FLWOR expression, even though iteration would not otherwise be necessary. For example, a list of books with price less than 100 might be obtained by a simple path expression such as $books//book[price < 100]
. But if these books are to be returned in alphabetic order by title, the query must be expressed as follows:
for $b in $books//book[price < 100]
order by $b/title
return $b
The following example illustrates an order by
clause that uses several options. It causes a collection of books to be sorted in primary order by title, and in secondary descending order by price. A specific collation is specified for the title ordering, and in the ordering by price, books with no price are specified to occur last (as though they have the least possible price). Whenever two books with the same title and price occur, the keyword stable
indicates that their input order is preserved.
for $b in $books//book
stable order by $b/title collation "eng-us",
$b/price descending empty least
return $b
The following example illustrates how FLWOR expressions can be nested, and how ordering can be specified at multiple levels of an element hierarchy. The example query inverts a document hierarchy to transform a bibliography into an author list. The input bibliography is a list of books in which each book contains a list of authors. The example is based on the following input:
<bib> <book> <title>TCP/IP Illustrated</title> <author>Stevens</author> <publisher>Addison-Wesley</publisher> </book> <book> <title>Advanced Unix Programming</title> <author>Stevens</author> <publisher>Addison-Wesley</publisher> </book> <book> <title>Data on the Web</title> <author>Abiteboul</author> <author>Buneman</author> <author>Suciu</author> </book> </bib>
The following query transforms the input document into a list in which each author's name appears only once, followed by a list of titles of books written by that author. The fn:distinct-values
function is used to eliminate duplicates (by value) from a list of author nodes. The author list, and the lists of books published by each author, are returned in alphabetic order using the default collation.
<authlist>
{
for $a in fn:distinct-values($books)//author
order by $a
return
<author>
<name>
{ $a/text() }
</name>
<books>
{
for $b in $books//book[author = $a]
order by $b/title
return $b/title
}
</books>
</author>
}
</authlist>
The result of the above expression is as follows:
<authlist> <author> <name>Abiteboul</name> <books> <title>Data on the Web</title> </books> </author> <author> <name>Buneman</name> <books> <title>Data on the Web</title> </books> </author> <author> <name>Stevens</name> <books> <title>TCP/IP Illustrated</title> <title>Advanced Unix Programming</title> </books> </author> <author> <name>Suciu</name> <books> <title>Data on the Web</title> </books> </author> </authlist>
In general, XQuery expressions return sequences that have a well-defined order. For example, the result of an axis step in a path expression is always returned in document order. Similarly, the result of a FLWOR expression is ordered by its order by
clause and/or the expressions in its for
clauses. However, in some expressions, the order of the result may not be significant to the user. In such an expression, one ordering may be much more efficient to materialize than another, and a significant performance advantage may be realized by allowing the system to materialize the results of the expression in the order it finds most efficient. XQuery provides a function named fn:unordered
for this purpose.
The fn:unordered
function takes any sequence of items as its argument, and returns the same sequence of items in a nondeterministic order. A call to the fn:unordered
function may be thought of as giving permission for the argument expression to be materialized in whatever order the system finds most efficient. The fn:unordered
function may be applied to the result of a query or to a subexpression inside a query.
The use of the fn:unordered
function is illustrated by the following example, which joins together two documents named parts.xml
and suppliers.xml
. The example returns the part numbers of red parts, paired with the supplier numbers of suppliers who supply these parts. If the fn:unordered
function were not used, the resulting list of (part number, supplier number) pairs would be required to have an ordering that is controlled primarily by the document order of parts.xml
and secondarily by the document order of suppliers.xml
. However, this might not be the most efficient way to process the query if the ordering of the result is not important. An XQuery implementation might be able to process the query more efficiently by using an index to find the red parts, or by using suppliers.xml
rather than parts.xml
to control the primary ordering of the result. The fn:unordered
function gives the query evaluator freedom to make these kinds of optimizations.
fn:unordered(
for $p in fn:doc("parts.xml")//part[color = "Red"],
$s in fn:doc("suppliers.xml")//supplier
where $p/suppno = $s/suppno
return
<ps>
{ $p/partno, $s/suppno }
</ps>
)
XQuery supports a conditional expression based on the keywords if
, then
, and else
.
[54] | IfExpr | ::= | "if" "(" Expr ")" "then" ExprSingle "else" ExprSingle |
The expression following the if
keyword is called the test expression, and the expressions
following the then
and else
keywords are called 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.3.3 Effectiveprovides Boolean Value.
The value of a conditional expression is defined as follows: If the
effective boolean value of the test expression is true
, the value of the then-expression is returned. If the
effective boolean value of the test expression is false
,
the value of the else-expression is returned.
Conditional expressions have a special rule for propagating dynamic errors.If the effective value of the test expression is true
, the conditional expression ignores (does not raise) any dynamic errors encountered in the else-expression. In this case, since the else-expression can have no observable effect, it need not be evaluated. Similarly, if the effective value of the test expression is false
, the conditional expression ignores any dynamic errors encountered in the then-expression, and the then-expression need not be evaluated.
Here are some examples of conditional expressions:
In this example, the test expression is a comparison expression:
if ($widget1/unit-cost < $widget2/unit-cost) then $widget1 else $widget2
In this example, the test expression tests for the existence of an attribute
named discounted
, independently of its value:
if ($part/@discounted) then $part/wholesale else $part/retail
Quantified expressions support existential and universal quantification. The
value of a quantified expression is always true
or false
.
[51] | QuantifiedExpr | ::= | (("some" "$") | ("every" "$")) VarName TypeDeclaration? "in" ExprSingle ("," "$" VarName TypeDeclaration? "in" ExprSingle)* "satisfies" ExprSingle |
A quantified expression begins with
a quantifier, which is the keyword some
or every
, followed by one or more in-clauses that are used to bind variables,
followed by the keyword satisfies
and a test expression. Each in-clause associates a variable with an
expression that returns a sequence of values. The in-clauses generate tuples of variable bindings, using
values drawn from the Cartesian product of the sequences returned by the
binding expressions. Conceptually, the test expression is evaluated for each
tuple of variable bindings. Results depend on the effective boolean values of the test expressions, as defined in 2.3.3 Effectiveprovides Boolean Value. The value of the quantified expression is defined
by the following rules:
If the quantifier is some
, the quantified expression is true
if at least one evaluation of the test expression has the effective
boolean value true
; otherwise the quantified expression is false
. This rule implies that, if the in-clauses generate zero binding
tuples, the value of the quantified expression is false
.
If the quantifier is every
, the quantified expression is true
if every evaluation of the test expression has the effective
boolean value true
; otherwise the quantified expression is false
. This rule implies that, if the in-clauses generate zero binding
tuples, the value of the quantified
expression is true
.
The scope of a variable bound in a quantified expression comprises all subexpressions of the quantified expression that appear after the variable binding. The scope does not include the expression to which the variable is bound.
Each variable bound in an in-clause of a quantified expression may have an optional type declaration, which is a datatype declared using the syntax in 2.4 Types. If the type of a value bound to the variable does not match the declared type according to the rules for SequenceType Matching, a type error is raised.[err:XP0004][err:XP0006]
The order in which test expressions are evaluated for the various binding
tuples is implementation-dependent.If the quantifier
is some
, an implementation may
return true
as soon as it finds one binding tuple for which the test expression has
an effective boolean value of true
, and it may 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 an error. As a result of these rules, the
value of a quantified expression is not deterministic in the presence of
errors, as illustrated in the examples below.
Here are some examples of quantified expressions:
This expression is true
if every part
element has a discounted
attribute (regardless of the values of these attributes):
every $part in //part satisfies $part/@discounted
This expression is true
if at least
one employee
element satisfies the given comparison expression:
some $emp in //employee satisfies ($emp/bonus > 0.25 * $emp/salary)
In the following examples, each quantified expression evaluates its test
expression over nine tuples of variable bindings, formed from the Cartesian
product of the sequences (1, 2, 3)
and (2, 3, 4)
. The expression beginning with some
evaluates to true
, and the expression beginning with every
evaluates to false
.
some $x in (1, 2, 3), $y in (2, 3, 4)
satisfies $x + $y = 4
every $x in (1, 2, 3), $y in (2, 3, 4)
satisfies $x + $y = 4
This quantified expression may either return true
or raise a type error,since its test expression returns true
for one variable binding
and raises a type error for another:
some $x in (1, 2, "cat") satisfies $x * 2 = 4
This quantified expression may either return false
or raise a type error,since its test expression returns false
for one variable binding and raises a type error for another:
every $x in (1, 2, "cat") satisfies $x * 2 = 4
This quantified expression contains a type declaration that is not satisfied by every item in the test expression. If the Static Typing Feature is implemented, this expression raises a type error during the analysis phase. Otherwise, the expression may either return true
or raise a type error during the evaluation phase.
some $x as xs:integer in (1, 2, "cat") satisfies $x * 2 = 4
In addition to their use in function parameters and results, SequenceTypes are used in instance of
, typeswitch
, cast
, castable
, and treat
expressions.
[57] | InstanceofExpr | ::= | TreatExpr ( "instance" "of" SequenceType )? |
The boolean
operator instance of
returns true
if the value of its first operand matches
the SequenceTypein 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.
5 instance of xs:decimal
This example returns true
because the given value is an integer literal, and xs:integer
is derived by restriction from xs:decimal
.
<a>{5}</a> instance of xs:integer
This example returns false
because the given value is not an integer; instead, it is an element containing an integer.
<a>{5}</a> instance of element(*, xs:integer)
This example returns true
if validation ofthe constructed element is successful and, after validation, the type annotation ATof the constructed element satisfies type-matches(xs:integer,
AT)
as described in 2.4.4 SequenceType Matching.
. instance of element()
This example returns true
if the context item is an element node. If the context item is undefined, a dynamic error is raised.[err:XP0002]
[52] | TypeswitchExpr | ::= | "typeswitch" "(" Expr ")" CaseClause+ "default" ("$" VarName)? "return" ExprSingle |
[53] | CaseClause | ::= | "case" ("$" VarName "as")? SequenceType "return" ExprSingle |
The typeswitch expression chooses one of several expressions to evaluate based on the dynamic type of an input value.
In a typeswitch
expression, the typeswitch
keyword is followed by an expression enclosed in parentheses, called
the operand expression. This is the expression whose type is being
tested. The
remainder of the typeswitch
expression consists of one or more case
clauses and a default
clause.
Each case
clause specifies a SequenceType followed by a return
expression. The effective case is the first case
clause such that the value of the operand expression matches the SequenceType in the case
clause, using the rules of SequenceType Matching. The value of the typeswitch
expression is the value of the return
expression in the effective case. If the value of the operand
expression is not a value of any type named in a case
clause, the value of the typeswitch
expression is the value of the return
expression in the default
clause.
A case
or default
clause may optionally specify a variable name. Within the return
expression of the case
or default
clause, this variable name is bound to the value of the operand expression, and its static type is considered to be the SequenceType named in the case
or default
clause. If the return
expression does not depend on the value of the operand expression, the variable may be omitted from the case
or default
clause.
The scope of a variable binding in a case
or default
clause comprises that clause. It is not an error for more than one case
or default
clause in the same typeswitch
expression to bind variables
with the same name.
The following example shows how a typeswitch
expression might
be used to process an expression in a way that depends on its dynamic type.
typeswitch($customer/billing-address)
case $a as element(*, USAddress) return $a/state
case $a as element(*, CanadaAddress) return $a/province
case $a as element(*, JapanAddress) return $a/prefecture
default return "unknown"
[60] | CastExpr | ::= | ComparisonExpr ( "cast" "as" SingleType )? |
[124] | SingleType | ::= | AtomicType "?"? |
Occasionally
it is necessary to convert a value to a specific datatype. For this
purpose, XQuery provides a cast
expression that
creates a new value of a specific type based on an existing value. A
cast
expression takes two operands: an input
expression and a target type. The type of the
input expression is called the input type. The target
type must be a named atomic type, represented by a QName, optionally
followed by the occurrence indicator ?
if an empty
sequence is permitted. If the target type has no namespace prefix, it
is considered to be in the default element/type
namespace. The semantics of the cast
expression
are as follows:
Atomization is performed on the input expression.
If the result of atomization is a sequence of more than one atomic value, a type error is raised.[err:XP0004][err:XP0006]
If the result of atomization is an empty sequence:
If
?
is specified after the target type, the result of the
cast
expression is an empty sequence.
If ?
is not specified after the target type, a type error is raised.[err:XP0004][err:XP0006]
If the result of atomization is a single atomic value, the result of the cast expression depends on the input type and the target type. In general, the cast expression attempts to create a new value of the target type based on the input value. Only certain combinations of input type and target type are supported. A summary ofthe rules are listed below— the normative definitionof these rules is given in [XQuery 1.0 and XPath 2.0 Functions and Operators]. 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. An implementation may determine that one type is a subtype of another either by examining the in-scope schema definitions or by using an alternative, implementation-dependent mechanism such as a data dictionary.
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 primitive schema types. For
example, a value of type xs:string
can be cast into the
type xs:decimal
. For each of these built-in combinations,
the semantics of casting are specified in [XQuery 1.0 and XPath 2.0 Functions and Operators].
cast
is
supported if the input type is a non-primitive atomic type and the target
type is a supertype of the input type. In this case, the input value
is mapped into the value space of the target type, unchanged except
for its 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 non-primitive atomic type and the
input
type is xs:string
or xdt:untypedAtomic
. The
input value is first converted to a value in the lexical space of the
target type by applying the whitespace normalization rules for the
target type; a dynamic error [err:XP0029]
is raised if the resulting lexical value does not satisfy the pattern
facet of the target type. The lexical value is then converted to the
value space of the target type using the schema-defined rules for the
target type; a dynamic error[err:XP0029]
is raised if the resulting value does not satisfy all the facets of
the target type.
cast
is supported if
the target type is a non-primitive atomic type and the input type is a
supertype of the target type. The input value must satisfy all the
facets of the target type (in the case of the pattern facet, this is
checked by generating a string representation of the input value,
using the rules for casting to xs:string
). The
resulting
value is the same as the input value, but with a different dynamic
type.
If a primitive type P1 can be cast into a primitive type P2, then any subtype of P1 can be cast into any subtype of P2, provided that the facets of the target type are satisfied. First the input value is cast to P1 using rule (b) above. Next, the value of type P1 is cast to the type P2, using rule (a) above. Finally, the value of type P2 is cast to the target type, using rule (d) above.
For any combination of input
type and target type that is not in the above list, a
cast
expression raises a type error.[err:XP0004][err:XP0006]
If casting from the input type to the target type is supported but nevertheless it is not possible to cast the input value into the value space of the target type, a dynamic error is raised.[err:XP0021] This includes the case when any facet of the target type is not satisfied. For example, the expression "2003-02-31" cast as xs:date
would raise a dynamic error.
[59] | CastableExpr | ::= | CastExpr ( "castable" "as" SingleType )? |
XQuery
provides a form of Boolean expression that tests whether a given value
is castable into a given target type. The expression V castable
as T
returns true
if the value V
can
be successfully cast into the target type T
by using a
cast
expression; otherwise it returns
false
. The castable
predicate can be used to
avoid errors at evaluation time. It can also be used to select an
appropriate type for processing of a given value, as illustrated in
the following example:
if ($x castable as hatsize)
then $x cast as hatsize
else if ($x castable as IQ)
then $x cast as IQ
else $x cast as xs:string
Constructor functions provide an alternative syntax for casting.
Abuilt-in constructorfunction is provided for each atomic type in thestatic context. The signature of the built-in constructor function for type T is as follows:
T($x as item) as T
The constructor function for type
T accepts any single item (either a node or an atomic
value) as input, and returns a value of type T (or raises
a dynamic error).Its
semantics are exactly the same as a cast
expression with
target type T. The built-in constructor functions are
defined in [XQuery 1.0 and XPath 2.0 Functions and Operators]. The following are
examples of built-in constructor functions:
This
example is equivalent to "2000-01-01" cast as
xs:date
.
xs:date("2000-01-01")
This
example is equivalent to
($floatvalue * 0.2E-5) cast as xs:decimal
.
xs:decimal($floatvalue *
0.2E-5)
This example returns a
xdt:dayTimeDuration
value equal to 21 days. It is
equivalent to "P21D" cast as xdt:dayTimeDuration
.
xdt:dayTimeDuration("P21D")
For each user-defined named atomic type
definition T in the in-scope
type definitions thatis in a namespace, aconstructor
function is defined. Like the built-in constructor
functions, the constructor functions for user-defined types have the
same name (including namespace) as the type, accept any item as input,
and have semantics identical to a cast
expression with
the user-defined type as target type. For example, if
usa:zipcode
is a user-defined atomic type
in the in-scope type definitions, then the
expression usa:zipcode("12345")
is equivalent to the
expression "12345" cast as
usa:zipcode
.
User-defined atomic types that are not in a
namespace do not haveimplicit constructor functions. To constructan
instance of such a type, it is necessary to use acast
expression. For example, if the user-defined type apple
isderived from xs:integer
but is not in a namespace, an
instance of this type can be constructed as follows:
17 cast as apple
[58] | TreatExpr | ::= | CastableExpr ( "treat" "as" SequenceType )? |
XQuery provides an
expression called treat
that can be used to modify the
static type of its
operand.
Like cast
, the treat
expression takes two operands: an expression and a SequenceType. Unlike
cast
, however, treat
does not change the
dynamic type or value of its operand. Instead, the purpose of
treat
is to ensure that an expression has an expected
type at evaluation time.
The semantics of expr1
treat as
type1
are as
follows:
During static analysis:
The
static type of the
treat
expression is type1
. This enables the
expression to be used as an argument of a function that requires a
parameter of type1
.
During expression evaluation:
If expr1
matches type1
,
using the SequenceType Matching rules in 2.4 Types,
the treat
expression returns the value of
expr1
; otherwise, it raises a dynamic error.[err:XP0006]
If the value of expr1
is returned, its identity is
preserved. The treat
expression ensures that the value of
its expression operand conforms to the expected type at
run-time.
Example:
$myaddress treat as element(*, USAddress)
The
static type of
$myaddress
may be element(*, Address)
, a
less specific type than element(*, USAddress)
. However,
at run-time, the value of $myaddress
must match the type
element(*, USAddress)
using SequenceType Matching rules;
otherwise a dynamic error is
raised.[err:XP0050]
[78] | ValidateExpr | ::= | "validate"SchemaMode? SchemaContext? "{" Expr "}" | /* gn: validate */ |
[12] | SchemaMode | ::= | "lax" | "strict" | "skip" | |
[79] | SchemaContext | ::= | ("context" SchemaContextLoc) | "global" | |
[143] | SchemaContextLoc | ::= | (SchemaContextPath? QName) | SchemaGlobalTypeName | |
[142] | SchemaContextPath | ::= | SchemaGlobalContext "/" (SchemaContextStep "/")* | |
[14] | SchemaGlobalContext | ::= | QName | SchemaGlobalTypeName | |
[13] | SchemaGlobalTypeName | ::= | "type" "(" QName ")" | |
[15] | SchemaContextStep | ::= | QName |
A validate
expression can be used to validate a document node or an element node with respect to the in-scope schema definitions, using the schema validation process described in [XML Schema]. If the operand of a validate
expression does not evaluate to exactly one document or element node (called the sourcenode), a type error is raised.[err:XQ0030]
In the result of the validate
expression, the source node and all its descendantsare replaced by new nodes that have their own identity and contain type annotations and default values generated by the validation process.
The result of a validate
expression is equivalent to
the following steps:
The source node is serialized, using the process defined in [XSLT 2.0 and XQuery 1.0 Serialization].
Theserialized source node isconverted to an XML information set([XML Infoset]) as follows:
Ifthe source node is adocument node, its serialized form is an XMLdocument. This document is parsed, resulting in an XMLinformation set.In this information set, the document information item corresponds tothe source node of the validate
expression.
Ifthe source nodeis an element node, its serialized form is treated asthe content of a synthetic XML document.This document is parsed, resulting in an XML information set. In this information set, the topmost element information item corresponds to the source node of the validate
expression.
The information set produced in the previous step is validated according to the rules for "Assessing Schema-Validity" in [XML Schema], using a schema defined by the in-scope schema definitions. If the source node is a document node, the validation process includes checking of uniqueness and reference constraints. If the source node is an element node, checks of uniqueness and reference constraints are omitted. The result of this step is a Post-Schema Validation Infoset (PSVI). If the [validity] property of the topmost element information item in this PSVIis not valid
,a type error is raised.[err:XQ0027]
In thePSVI produced in the previous step, the information item that corresponds to the source nodeis converted back into the datamodel,using the mapping described in [XQuery 1.0 and XPath 2.0 Data Model].
A validate
expression may specify a validation
mode, which may have one of the following three
values:
strict
requires that each
element to be validated must be present in the in-scope element declarations, and that
the content of each element must conform to its
definition.
skip
indicates that no
validation is to be attempted. In this mode, each element node is
given the type annotation xdt:untypedAny
, and each attribute
node is given the type annotation
xdt:untypedAtomic
.
lax
behaves like strict
for elements that are present in the
in-scope element declarations,
and like skip
for elements that are not
present.
If no validation mode is specified for a
validate
expression, the expression uses the validation
mode in its static
context. If a validation mode is specified, that validation
mode is made effective in the static
context for nested expressions.
A
validate
expression may also contain a validation
context that affects the interpretation of element names. If
the validation context is global
, all top-level element
names in the material to be validated are checked against top-level
in-scope schema
definitions . Alternatively, the validation context may
specify that the validated material is to
be interpreted within the context of a givenschema path, as illustrated by the
following examples, which are based on schemas defined in [XML Schema], Part 0:
Suppose that $x
is bound to a
shipTo
element. Then validate strict context
po:purchaseOrder {$x}
validates the value of $x
in
strict
mode, in the context of the top-level element
declaration po:purchaseOrder
.
Suppose
that $y
is bound to a productName
element. Then validate context
po:purchaseOrder/items/item {$y}
validates the value of
$y
in the context of the schemapath po:purchaseOrder/items/item
.
Suppose
that $z
is bound to a zip
element. Then
validate context type(po:USAddress)
{$z}
validates the value of $z
in the context of
the type po:USAddress
.
If no validation context is specified for a validate
expression, the expression uses the validation context in its static context. If a validation
context is specified, that validation context is made effective in the
static context for nested
expressions.
Since each element constructor
automatically performs validation on the constructed element, it is
rarely necessary to use an explicit validate
expression. Typically, an explicit validate
expression is
used to enclose an element constructor if the user wishes to specify a
validation mode or validation context that
is different from that of the static
context, thus affecting the behavior of the element
constructor and its nested expressions. For example, the following
expression constructs an element named zip
and specifies
that it must be validated in strict
mode and in the
context of the type named po:Address
:
validate strict context type(po:Address)
{ <zip>90952</zip> }
[30] | Module | ::= | VersionDecl? (MainModule | LibraryModule) |
[31] | MainModule | ::= | Prolog QueryBody |
[32] | LibraryModule | ::= | ModuleDecl Prolog |
[34] | Prolog | ::= | ((NamespaceDecl |
[34a] | Separator | ::= | ";" |
[34b] | QueryBody | ::= | Expr |
[Definition: A module is a fragment of XQuery code that can independently undergo the analysis phase described in 2.2.3 Expression Processing]. [Definition: A module that contains a Prolog followed by a Query Body is called a main module.] A query hasexactly one main module. In a main module, the Query Body can be evaluated, and its value is the result of the query. [Definition: A module that contains a module declaration followed by a Prolog is called a library module.] A library module cannot be evaluated directly; instead, it provides function and variable declarations that can be imported into other modules. No module may contain both a module declaration and a Query Body.
[Definition: APrologis a series of declarations and imports that create the environment for queryprocessing.] Each declaration or import is followed by a semicolon. A Prolog may includeimports ofschemasand modules, and declarations of namespaces, variables, functions, and various processing options. Declarations and imports may be specified in any order,except that variabledeclarations must avoid circular definitions as described in 4.8 Variable Declaration.
[Definition: TheQueryBody,if present, consistsof an expression that defines the result of the query.]Evaluation of expressions isdescribed in 3 Expressions.A module can be evaluated only if it has a Query Body.
[36] | VersionDecl | ::= | "xquery" "version" StringLiteral Separator |
Anymodule may containa version declaration. If present, the version declaration occurs at the beginning of the module, and identifies the applicable XQuery syntax and semantics fora module. Theversion number "1.0" indicates the requirement that the querymust be processed by an XQuery Version 1.0 processor. Ifthe version declaration is not present,the version ispresumed to be "1.0". An XQuery implementation mustraise a staticerror[err:XQ0031]when processing a querylabeledwith aversion thatthe implementation does not support. It is theintent of the XQuery working group to give later versions of this specification numbers other than "1.0", but thisintent does not indicate a commitment to produce any future versions of XQuery, norif any are produced, to useanyparticular numbering scheme.
Thefollowing is anexampleof a version declaration:
xquery version "1.0";
[33] | ModuleDecl | ::= | "module" "namespace" NCName "=" StringLiteral Separator |
[Definition: Amodule declaration serves to identifya module as a librarymodule.A moduledeclaration consists of the keyword module
followed by a namespace prefix and a string literal which must contain a valid URI.[err:XQ0046]][Definition: TheURI identifiesthe target namespaceof the module,which is the namespace for all variables and functions exported by the module.]The names of all variables and functions declared in a library module must be explicitlyqualified by the target namespace prefix.[err:XQ0048]
Any modulemayimport a library module by means of a module importthat specifies the target namespace of the library module to be imported.When amodule imports one or more library modules, the variables and functionsdeclaredintheimportedmodules are added to the staticcontextand (where applicable)to the dynamiccontextof the importing module.
Thefollowing is an example of a module declaration:
module namespace math = "http://example.org/math-functions";
[117] | BaseURIDecl | ::= | "declare""base-uri" StringLiteral |
Abase URIdeclaration specifies the
baseURIproperty of the static context, which
isusedwhen resolving relative URIs withina
module. A
static error [err:XQ0032]israised if more than one base URIdeclaration
is found in a query prolog. A
staticerror[err:XQ0046]is raised if the string literal in a base URIdeclaration does not contain a validURI. Note that the fn:doc
functionresolves a relative URI using the base URI of the
callingmodule.
The following is an example of a base URIdeclaration:
declare base-uri "http://example.org";
[118] | NamespaceDecl | ::= | "declare" "namespace" NCName "=" StringLiteral |
A namespace declaration declares a namespace prefix and associates it with a namespace URI, adding the (prefix, URI) pair to the set of in-scope namespaces. The string literal used in a namespace declaration must be a valid URI [err:XQ0046],and may not be a zero-length string.[err:XQ0053] The namespace declaration is in scope throughout the query in which it is declared, unless it is overridden by a namespace declaration attribute in an element constructor.
The following query illustrates a namespace declaration:
declare namespace foo = "http://example.org";
<foo:bar> Lentils </foo:bar>
In the query result, the newly created node is in the namespace
associated with the namespace URI http://example.org
.
Multiple declarations of the same namespace prefix in the Prolog result in a static error.[err:XQ0033]However, a declaration of a namespace in the Prolog can override a prefix that has been predeclared in the static context.
It is a static error [err:XP0008] to use a QName with a namespace prefix that has not been declared.
In an element constructor, a namespace declaration attribute can be used to bind a prefix to
a namespace, adding a (prefix, URI) pair to the set of in-scope
namespaces for the element in which it occurs and for nested expressions. The binding of a prefix by a namespace declaration attribute overrides any binding of the same prefix by a higher-level element or by the Prolog. The value of a namespace declaration attribute must be a valid URI. [err:XQ0046] In the Data Model, a namespace declaration attribute generates a namespace node rather than an attribute node. Namespace nodes are not retrieved by queries that return the attributes of an element.
The
following query illustrates a namespace declaration attribute that binds the prefix foo
within the scope of a constructed element:
<foo:bar xmlns:foo="http://example.org">{ //foo:bing }</foo:bar>
When element or attribute names are compared, they are considered identical if the local part and namespace URI match. Namespace prefixes need not be identical for two names to match, as illustrated by the following example:
declare namespace xx = "http://example.org";
let $i := <foo:bar xmlns:foo = "http://example.org">
<foo:bing> Lentils </foo:bing>
</foo:bar>
return $i/xx:bing
Although the namespace prefixes xx
and foo
differ, both are bound to the namespace URI "http://example.org"
. Since xx:bing
and foo:bing
have the same local name and the same namespace URI, they match. The
output of the above query is as follows.
<foo:bing> Lentils </foo:bing>
XQuery has several predeclared namespace prefixes that are present in the in-scope namespaces before each query is processed. These prefixes may be used without an explicit declaration. Theymay be overridden by namespace declarations in the Prolog or by namespace declaration attributes on constructed elements (except for the prefix xml
, which may not be redeclared.) The predeclarednamespace prefixes are as follows:
xml = http://www.w3.org/XML/1998/namespace
xs = http://www.w3.org/2001/XMLSchema
xsi = http://www.w3.org/2001/XMLSchema-instance
fn = http://www.w3.org/2003/11/xpath-functions
xdt = http://www.w3.org/2003/11/xpath-datatypes
local = http://www.w3.org/2003/11/xquery-local-functions
(see 4.12 Function Declaration.)
Additional predeclared namespace prefixes may be added to the in-scope namespaces by an implementation.
The namespace prefix xmlns
also has a special significance (it identifies a namespace declaration attribute), and it may not be redeclared.
[119] | DefaultNamespaceDecl | ::= | (("declare" "default" "element")| ("declare" "default" "function")) "namespace" StringLiteral |
Default namespace declarations can be used in a Prolog to facilitate the use of unprefixed QNames. The string literal used in a default namespace declaration must be a valid URI [err:XQ0046],and may be a zero-length string.[err:XQ0046] The following kinds of default namespace declarations are supported:
Declaration of a default element/type namespace declares a namespace URI that is associated with unprefixed names of elements and types. If no default element/type namespace is declared, unqualified names of elements and types are in no namespace. The following example illustrates the declaration of a default namespace for elements and types:
declare default element namespace "http://example.org/names";
If a
direct element constructor includes an attribute
named xmlns
, it is considered to be a
namespace declaration attribute that specifies a
new default element/type namespace within the
scope of the constructed element and its descendants. For
example, within the scope of the following constructed
element, the default element/type namespace is
http://example.org/altnames
.
<abc xmlns="http://example.org/altnames">Content goes here.</abc>
A Prolog may contain a
declaration for a default function
namespace. If no default
function namespace is declared,the default function namespace is the namespace of XPath/XQuery functions,
http://www.w3.org/2003/11/xpath-functions
. The
following example illustrates the declaration of a default
function namespace:
declare default function namespace "http://example.org/math-functions";
The effect of declaring a default function namespace is that all functions in the default function namespace, including implicitly-declared constructor functions, are aliased with a name that has the original local name, but no namespace URI. The function may then be called using either its original name or its alias—that is, the namespace prefix becomes optional. When a function call uses a function name with no prefix, the local name of the function must match a function (including implicitly-declared constructor functions) in the default function namespace.[err:XP0017]
Unqualified attribute names and variable names are in no namespace.
[146] | SchemaImport | ::= | "import" "schema" SchemaPrefix? StringLiteral ("at" StringLiteral)? |
[147] | SchemaPrefix | ::= | ("namespace" NCName "=") | ("default" "element" "namespace") |
[Definition: A schema import imports the element, attribute, and type definitions from a named schema into the in-scope schema definitions.] The string literals in a schema import must be valid URIs. [err:XQ0046] The schema import specifies the target namespace of the schema to be imported, and optionally the location of the schema. A schema import may also bind a namespace prefix to the target namespace of the imported schema, or may declare that target namespace to be the default element/type namespace. The optional location indication can be disregarded by an implementation if it has another way to locate the given schema.
It is not an error for a query to import the same target namespace more than once. This may be done in order to provide more than one schema location hint when schema components are located in more than one schema document. Every schema component must be imported only once by the implementation. For instance, an implementation might combine all schema imports for a given target namespace, making a list of all location hints, and assemble the schema documents found in those locations. Since an implementation is not required to use the schema location hints, another conforming implementation might combine all schema imports for a given target namespace, ignore the hints altogether, and search a data dictionary for the definitions associated with the namespace.
The following example imports the schema for an XHTML document,
specifying both its target namespace and its location, and binding the
prefix xhtml
to this namespace:
import schema namespace xhtml="http://www.w3.org/1999/xhtml"
at "http://example.org/xhtml/xhtml.xsd";
The following example imports a schema by specifying only its target namespace, and makes it the default element/type namespace for the query:
import schema default element namespace "http://example.org/abc";
It is a static error [err:XQ0035] to import two schemas that both define the same name in
the same symbol space and in the same scope. For instance, a query may not
import two schemas that include top-level element declarations for two elements
with the same expanded name. However, it is not an error for a module to import the schema with target namespace http://www.w3.org/2001/XMLSchema
(predeclared prefix xs
), even though the built-in types defined in this schema are implicitly included in the in-scope type definitions.
Note:
XQuery 1.0 supports querying of DTD-validated documents only if the Static Typing Feature is not enabled. Since XQuery 1.0 does not provide a means for importing Document Type Definitions (DTDs), implementations supporting the Static Typing Feature level are not required to recognize or support type information in DTDs.
If static typing of queries that access DTD-validated documents is required, the DTD should be converted to an XML Schema and the resulting schema should be imported into the query. We request public comment on this restriction.
[37] | ModuleImport | ::= | "import" "module" ("namespace" NCName "=")? StringLiteral ("at" StringLiteral)? |
[Definition: A module import imports the function
declarations and variable declarations from the Prolog of a
library module into the in-scope
functions and in-scope variables of the importing module.] The module import identifies the module to be imported by its target namespace, and may also specify its location by
using an at
clause. Implementations may locate modules in any manner that
is convenient, and are free to ignore the specified location if they have
another way to find a module. By means of an optional namespace
clause, a module import may bind a namespace prefix to the target namespace of the imported
module. It is a static error if a module import does not identify an available module to be imported.[err:XQ0047]
Each module has its own static context. A module import imports only functions and variable declarations; it does not import other objects from the imported module, such as its in-scope schema definitions or in-scope namespaces. Module imports are not transitive—that is, importing a module provides access only to function and variable declarations contained directly in the imported module. For example, if module A imports module B, and module B imports module C, module A does not have access to the functions and variables declared in module C. Two modules may import each other.
It is a type error [err:XQ0036] to import a module if the importing module's in-scope type definitions do not include definitions for the type names that appear in variable declarations, function parameters, or function returns found in the imported module. It is a static error [err:XQ0037] to import a module that contains function declarations or variable declarations whose names are already declared in the static context of the importing module.
To illustrate the above rules, suppose that a certain schema defines a type named triangle
. Suppose that a library module imports the schema, binds its target namespace to the prefix geo
, and declares a function with the function signature math:area($t as geo:triangle) as xs:double
. If a query wishes to use this function, it must import both the library module and the schema on which it is based. Importing the library module alone would not provide access to the type definition on which the area
function is declared.
The following example illustrates a module import:
import module namespace math = "http://example.org/math-functions";
[38] | VarDecl | ::= | "declare""variable" "$" VarName TypeDeclaration? (("{" Expr "}") | "external") |
[20] | VarName | ::= | QName |
[123] | TypeDeclaration | ::= | "as" SequenceType |
A variable declaration adds the static type of a variable to the in-scope variables, and may also add a value for the variable to the dynamicvariables. If the expanded QName of the variable is the same as that of another variable in in-scope variables, a static error is raised.[err:XQ0049]
If a variable declaration includes a type, that type is added to the static context as the type of the variable. If a variable declaration includes an expression but not an explicit type, the static type of the variable is inferred from the static type of the expression. If a variable declaration includes both a type and an expression, the static type of the expression must be compatible with the declared static type; otherwise a type error is raised.[err:XP0004]
[Definition: If a variable declaration includes an expression, the expression is called an initializing expression.] Initializing expressions are evaluated at the beginningof the dynamic evaluation phase. The static context for an initializing expression includes all functions that aredeclared or imported anywhere in the Prolog, but it includes only those variables that are declared or importedearlier in the Prolog than the variable that is being initialized.If an initializing expression cannot be evaluated because of a circularity (for example, it depends on a function that in turn depends on the value of the variable that is being initialized), a dynamic error israised.[err:XQ0054]
If the variable declaration
includes the keyword external
, a value must be
provided for the variable by the external environment before
the query can be evaluated. If the value provided by the
external environment is not compatible with the declared type
of the variable, a type error is raised.[err:XP0006]
If a variable declaration contains neither a type nor an expression, the type and value of the variable must both be provided by the external environment at evaluation time. The static type of such a variable is considered to be xs:anyType
.
A variable may appear in the expression part of a variable declaration only if that variable is declared or imported earlier in the Prolog than the declarationin which it is used.
All variable names declared in a library module must be explicitly qualified by thenamespace prefix of the module's target namespace.[err:XQ0048]When a library module is imported, variables declared in the imported module are added to the in-scope variables of the importing module.
Variable names that have no namespace prefix are in no namespace. Variable declarations that have no namespace prefix may appear only in a main module.
The term variable declaration always refers to a declaration of a variable in a Prolog. The binding of a variable to a value in a query expression, such as a FLWOR expression, is known as a variable binding, and does not make the variable visible to an importing module.
Here are some examples of variable declarations:
The following declaration
specifies both the type and the value of a variable. This
declaration causes the type xs:integer
to be
associated with variable $x
in the static context, and the
value 7
to be associated with variable
$x
in the dynamic
context.
declare variable $x as xs:integer {7};
The following declaration specifies a
value but not a type. The static type of the variable is
inferred from the static type of its value. In this case, the
variable $x
has a static type of
xs:decimal
, inferred from its value which is
7.5.
declare variable $x {7.5};
The
following declaration specifies a type but not a value. The
keyword external
indicates that the value of the
variable will be provided by the external environment. At
evaluation time, if the variable $x
in the
dynamic context
does not have a value of type xs:integer
, a type
error is raised.
declare variable $x as xs:integer external;
The following declaration
specifies neither a type nor a value. It simply declares that
the query depends on the existence of a variable named
$x
, whose type and value will be provided by the
external environment. During query analysis, the type of
$x
is considered to be
xs:anyType
. During query evaluation, the
dynamic context must include a type and a value for $x
, and its value must be compatible with its type.
declare variable $x external;
[145] | ValidationDecl | ::= | "declare" "validation" SchemaMode |
[145a] | SchemaMode | ::= | "lax" | "strict" | "skip" |
The validation declaration in the
Prolog sets the validation
mode in the static
context to strict
, lax
,
or skip
. This establishes a default validation mode for the
query. The default validation context for the query is always set to global
. The default validation mode and validation context can be overridden by validate
expressions within the body of the query. The significance of validation mode and validation context are described in 3.13 Validate Expressions.
The following example illustrates a validation declaration:
declare validation strict;
[115] | XMLSpaceDecl | ::= | "declare" "xmlspace" ("preserve" | "strip") |
The xmlspace declaration in a Prolog controls whether boundary whitespace is preserved by element and attribute constructors during execution of the query, as described in 3.7.1.4 Whitespace in Element Content. If xmlspace preserve
is specified, boundary whitespace is preserved. If xmlspace strip
is specified or if no xmlspace declaration is present, boundary whitespace is stripped (deleted).
The following example illustrates an xmlspace declaration:
declare xmlspace preserve;
[116] | DefaultCollationDecl | ::= | "declare" "default" "collation" StringLiteral |
A Prolog may declare a default
collation, which is the name of the collation to be
used by functions and operators that require a collation
if no other collation is specified. For example, the
gt
operator on strings is defined by a call to
the fn:compare
function, which takes an optional
collation parameter. Since the gt
operator does
not specify a collation, the fn:compare
function
implements gt
by using the default collation
specified in the Prolog. The default collation is identified
by a literal string which mustcontain a valid URI. [err:XQ0046]
If a Prolog
specifiesno default collation, the Unicode codepoint collation
(http://www.w3.org/2003/11/xpath-functions/collation/codepoint
)
isused unless the implementation provides a different default collation.
The default collation applies to all functions that require acollation, except the following functions: fn:contains
,fn:starts-with
,fn:ends-with
, fn:substring-before
, andfn:substring-after
.If one of these functions is called without an explicit collation parameter, it usesthe Unicode codepoint collation ratherthan the default collation.
The following example illustrates a default collationdeclaration:
declare default collation "http://example.org/languages/Icelandic";
If a Prolog specifies more than one default collation, or the value specified does not identify a collation known to the implementation, a static error is raised.[err:XQ0038]
In addition to the built-in functions described in [XQuery 1.0 and XPath 2.0 Functions and Operators], XQuery allows users to declare functions of their own. A function declaration specifies the name of the function, the names and datatypes of the parameters, and the datatype of the result. All datatypes are specified using the syntax described in 2.4 Types. A function declarationcauses the declaredfunction tobe added to the in-scopefunctionsof the module in which itappears.
[120] | FunctionDecl | ::= | "declare" "function" QName "(" ParamList? (")" | (")" "as" SequenceType)) (EnclosedExpr | "external") | /* gn: parens */ |
[121] | ParamList | ::= | Param ("," Param)* | |
[122] | Param | ::= | "$" VarName TypeDeclaration? | |
[123] | TypeDeclaration | ::= | "as" SequenceType |
A function declaration specifies whether a function is user-defined or external. [Definition: For a user-defined function, the function declaration includes an expression called the function body that defines how the result of the function is computed from its parameters.]. The static context for a function body includes all functions that are declared or imported anywhere in the Prolog, but it includes only those variables that are declared or imported earlier in the Prolog than the function that is being defined.
[Definition: External functions are functions that are implemented outside the query environment.] For example, an XQuery implementation might provide a set of external functions in addition to the core function library described in [XQuery 1.0 and XPath 2.0 Functions and Operators]. External functions are identified by the keyword external
. The purpose of a function declaration for an external function is to declare the datatypes of the function parameters and result, for use in type checking of the query that contains or imports the function declaration.
An XQuery implementation may provide a facility whereby external functions can be implemented using a host programming language, but it is not required to do so. If such a facility is provided, the protocols by which parameters are passed to an external function, and the result of the function is returned to the invoking query, are implementation-defined.An XQuery implementation may augment the type system of [XQuery 1.0 and XPath 2.0 Data Model] with additional types that are designed to facilitate exchange of data with host programming languages, or it may provide mechanisms for the user to define such types. For example, a type might be provided that encapsulates an object returned by an external function, such as an SQL database connection.
The declared function name in a function declaration mustbe a QName with a non-empty namespace prefix. If the namespace prefix of a declared function name is empty, a staticerroris raised.[err:XQ0045] Ifthe expanded QNameof the function is the sameas that ofanother function in in-scope functions, a static error is raised.[err:XQ0034]
Inorder to allow main modules to declarefunctions for local use within the module without defining a new namespace, XQuery predefines the namespace prefix local
to the namespace http://www.w3.org/2003/11/xquery-local-functions
, and reserves this namespace for use in defining local functions. It is a static error if the declared name in a function declaration uses one of the predefined namespace prefixes other than local
.[err:XQ0045]
If a function parameter is declared using a name but no type, its default type is item*
. If the resulttype is omitted from a function declaration, its default result type is item*
.
The parameters of a function declaration are considered to be variables whose scope is the function body. It is an static error [err:XQ0039] for a function declaration to have more than one parameter with the same name. The type of a function parameter can be any type that can be expressed as a SequenceType (see 2.4 Types).
The following example illustrates the declaration and use of a local function that
accepts a sequence of valid employee
elements (as
defined in the in-scope element declarations), summarizes them by department, and returns a sequence of valid dept
elements (again, as defined in the in-scope element declarations).
Using a function, prepare a summary of employees that are located in Denver.
declare function local:summary($emps as element(employee)*) as element(dept)* { for $d in fn:distinct-values($emps/deptno) let $e := $emps[deptno = $d] return <dept> <deptno>{$d}</deptno> <headcount> {fn:count($e)} </headcount> <payroll> {fn:sum($e/salary)} </payroll> </dept> }; local:summary(fn:doc("acme_corp.xml")//employee[location = "Denver"])
Rules for converting function arguments to their declared parameter types, and for converting the result of a function to its declared result type, are described in 3.1.5 Function Calls
A function declaration may be recursive—thatis, it may reference itself.Mutually recursive functions, whose bodies reference each other,
are also allowed. The following example declares a recursive function that
computes the maximum depth of a node hierarchy, and calls the function to
find the maximum depth of a particular document. In its declaration, the
user-declared function local:depth
calls the built-in functions empty
and max
, which are in thedefault function namespace.
Find the maximum depth of the document named partlist.xml
.
declare function local:depth($e as node()) as xs:integer { (: A node with no children has depth 1 :) (: Otherwise, add 1 to max depth of children :) if (fn:empty($e/*)) then 1 else fn:max(for $c in $e/* return local:depth($c)) + 1 }; local:depth(fn:doc("partlist.xml"))
In XQuery 1.0, user-declared functions may not be overloaded. A user-declared function is uniquely identified by its expanded QName.However, some of the built-in functions in the XQuery core library are
overloaded—for example, the fn:string
function can be
called with either zero arguments or one argument.
Since a constructor function is effectively declared for every user-defined atomic type in the in-scope type definitions, a static error [err:XQ0034] is raised if the Prolog attempts to declare a function with the same expanded QNameas any of these types.
Note:
If a future version of XQuery supports overloading of user-declared functions, an ambiguity may arise between a function that takes a node as parameter and a function with the same name that takes an atomic value as parameter (since a function call automatically extracts the atomic value of a node when necessary). The designers of such a future version of XQuery can avoid this ambiguity by writing suitable rules to govern function overloading. Nevertheless, users who are concerned about this possibility may choose to explicitly extract atomic values from nodes when calling functions that expect atomic values.
The following grammar uses the same Basic Extended Backus-Naur Form (EBNF) notation as [XML 1.0], except that grammar symbols always have initial capital letters. The notation "< ... >" is used to indicate a grouping of terminals that together may help disambiguate the individual symbols. To help readability, this "< ... >" notation is absent in the EBNF in the main body of this document. This appendix should be regarded as the normative version of the EBNF.
Comments on grammar productions are between '/*' and '*/' symbols - please note that these comments are normative.A 'gn:' prefix means a 'Grammar Note', and is meant as a clarificationfor parsing rules, and is explained in A.1.1 Grammar Notes. A 'ws:' prefix explains the white space rules for the production, the details of which are explained in A.2.1 White Space Rules
[30] | Module | ::= | VersionDecl? (MainModule | LibraryModule) | |
[31] | MainModule | ::= | Prolog QueryBody | |
[32] | LibraryModule | ::= | ModuleDecl Prolog | |
[33] | ModuleDecl | ::= | <"module" "namespace"> NCName "=" StringLiteral Separator | |
[33a] | Prolog | ::= | ((NamespaceDecl | |
[33b] | Separator | ::= | ";" | |
[33c] | VersionDecl | ::= | ||
<"xquery" "version" StringLiteral> Separator | ||||
[33d] | ModuleImport | ::= | <"import" "module"> ("namespace" NCName "=")? StringLiteral <"at" StringLiteral>? | |
[38] | VarDecl | ::= | <"declare""variable" "$"> VarName TypeDeclaration? (("{" Expr "}") | "external") | |
[39] | QueryBody | ::= | Expr | |
[40] | Expr | ::= | ExprSingle ("," ExprSingle)* | |
[41] | ExprSingle | ::= | FLWORExpr | |
[42] | FLWORExpr | ::= | (ForClause | LetClause)+ WhereClause? OrderByClause? "return" ExprSingle | |
[43] | ForClause | ::= | <"for" "$"> VarName TypeDeclaration? PositionalVar? "in" ExprSingle ("," "$" VarName TypeDeclaration? PositionalVar? "in" ExprSingle)* | |
[44] | PositionalVar | ::= | "at" "$" VarName | |
[45] | LetClause | ::= | <"let" "$"> VarName TypeDeclaration? ":=" ExprSingle ("," "$" VarName TypeDeclaration? ":=" ExprSingle)* | |
[46] | WhereClause | ::= | "where" Expr | |
[47] | OrderByClause | ::= | (<"order" "by"> | <"stable" "order" "by">) OrderSpecList | |
[48] | OrderSpecList | ::= | OrderSpec ("," OrderSpec)* | |
[49] | OrderSpec | ::= | ExprSingle OrderModifier | |
[50] | OrderModifier | ::= | ("ascending" | "descending")? (<"empty" "greatest"> | <"empty" "least">)? ("collation" StringLiteral)? | |
[51] | QuantifiedExpr | ::= | (<"some" "$"> | <"every" "$">) VarName TypeDeclaration? "in" ExprSingle ("," "$" VarName TypeDeclaration? "in" ExprSingle)* "satisfies" ExprSingle | |
[52] | TypeswitchExpr | ::= | <"typeswitch" "("> Expr ")" CaseClause+ "default" ("$" VarName)? "return" ExprSingle | |
[53] | CaseClause | ::= | "case" ("$" VarName "as")? SequenceType "return" ExprSingle | |
[54] | IfExpr | ::= | <"if" "("> Expr ")" "then" ExprSingle "else" ExprSingle | |
[55] | OrExpr | ::= | AndExpr ( "or" AndExpr )* | |
[56] | AndExpr | ::= | InstanceofExpr ( "and" InstanceofExpr )* | |
[57] | InstanceofExpr | ::= | TreatExpr ( <"instance" "of"> SequenceType )? | |
[58] | TreatExpr | ::= | CastableExpr ( <"treat" "as"> SequenceType )? | |
[59] | CastableExpr | ::= | CastExpr ( <"castable" "as"> SingleType )? | |
[60] | CastExpr | ::= | ComparisonExpr ( <"cast" "as"> SingleType )? | |
[61] | ComparisonExpr | ::= | RangeExpr ( (ValueComp | |
[62] | RangeExpr | ::= | AdditiveExpr ( "to" AdditiveExpr )? | |
[63] | AdditiveExpr | ::= | MultiplicativeExpr ( ("+" | "-") MultiplicativeExpr )* | |
[64] | MultiplicativeExpr | ::= | UnaryExpr ( ("*" | "div" | "idiv" | "mod") UnaryExpr )* | |
[65] | UnaryExpr | ::= | ("-" | "+")* UnionExpr | |
[66] | UnionExpr | ::= | IntersectExceptExpr ( ("union" | "|") IntersectExceptExpr )* | |
[67] | IntersectExceptExpr | ::= | ValueExpr ( ("intersect" | "except") ValueExpr )* | |
[68] | ValueExpr | ::= | ValidateExpr | PathExpr | |
[69] | PathExpr | ::= | ("/" RelativePathExpr?) | /* gn: leading-lone-slash */ |
[69a] | RelativePathExpr | ::= | StepExpr (("/" | "//") StepExpr)* | |
[71] | StepExpr | ::= | AxisStep | FilterStep | |
[72] | AxisStep | ::= | (ForwardStep | ReverseStep) Predicates | |
[73] | FilterStep | ::= | PrimaryExpr Predicates | |
[73a] | ContextItemExpr | ::= | "." | |
[75] | PrimaryExpr | ::= | Literal | VarRef | ParenthesizedExpr| ContextItemExpr| FunctionCall | Constructor | |
[75a] | VarRef | ::= | "$" VarName | |
[77] | Predicates | ::= | ("[" Expr "]")* | |
[78] | ValidateExpr | ::= | (<"validate" "{"> | (<"validate" "global"> "{") | (<"validate" "context"> SchemaContextLoc "{") | (<"validate" SchemaMode> SchemaContext? "{")) Expr "}" | /* gn: validate */ |
[78a] | SchemaContext | ::= | ("context" SchemaContextLoc) | "global" | |
[80] | Constructor | ::= | DirElemConstructor | |
[80a] | ComputedConstructor | ::= | CompElemConstructor | |
[80b] | GeneralComp | ::= | "=" | "!=" | "<" | "<=" | ">" | ">=" | /* gn: lt */ |
[80c] | ValueComp | ::= | "eq" | "ne" | "lt" | "le" | "gt" | "ge" | |
[84] | NodeComp | ::= | "is" | "<<" | ">>" | |
[85] | ForwardStep | ::= | (ForwardAxis NodeTest) | AbbrevForwardStep | |
[86] | ReverseStep | ::= | (ReverseAxis NodeTest) | AbbrevReverseStep | |
[87] | AbbrevForwardStep | ::= | "@"? NodeTest | |
[88] | AbbrevReverseStep | ::= | ".." | |
[89] | ForwardAxis | ::= | <"child" "::"> | |
[90] | ReverseAxis | ::= | <"parent" "::"> | |
[91] | NodeTest | ::= | KindTest | NameTest | |
[92] | NameTest | ::= | QName | Wildcard | |
[93] | Wildcard | ::= | "*" | /* ws: explicit */ |
[94] | Literal | ::= | NumericLiteral | StringLiteral | |
[95] | NumericLiteral | ::= | IntegerLiteral | DecimalLiteral | DoubleLiteral | |
[96] | ParenthesizedExpr | ::= | "(" Expr? ")" | |
[97] | FunctionCall | ::= | <QName "("> (ExprSingle ("," ExprSingle)*)? ")" | |
[98] | DirElemConstructor | ::= | "<" QName AttributeList ("/>" | (">" ElementContent* "</" QName S? ">")) | /* ws: explicit */ |
/* gn: lt */ | ||||
[99] | CompDocConstructor | ::= | <"document" "{"> Expr "}" | |
[100] | CompElemConstructor | ::= | (<"element" QName "{"> | (<"element" "{"> Expr "}" "{")) Expr? "}" | |
[100a] | CompNSConstructor | ::= | <"namespace" NCName "{"> Expr "}" | |
[100b] | CompAttrConstructor | ::= | ||
(<"attribute" QName "{"> | (<"attribute" "{"> Expr "}" "{")) Expr? "}" | ||||
[100c] | CompXmlPI | ::= | (<"processing-instruction" NCName "{"> | (<"processing-instruction" "{"> Expr "}" "{")) Expr? "}" | |
[100d] | CompXmlComment | ::= | <"comment" "{"> Expr "}" | |
[100e] | CompTextConstructor | ::= | ||
<"text" "{"> Expr? "}" | ||||
[106] | CdataSection | ::= | "<![CDATA[" Char* "]]>" | /* ws: significant */ |
[107] | XmlPI | ::= | "<?" PITarget Char* "?>" | /* ws: explicit */ |
[108] | XmlComment | ::= | "<!--" Char* "-->" | /* ws: significant */ |
[109] | ElementContent | ::= | ElementContentChar | /* ws: significant */ |
[110] | AttributeList | ::= | (S (QName S? "=" S? AttributeValue)?)* | /* ws: explicit */ |
[111] | AttributeValue | ::= | ('"' (EscapeQuot | QuotAttrValueContent)* '"') | /* ws: significant */ |
[111a] | QuotAttrValueContent | ::= | QuotAttContentChar | /* ws: significant */ |
[111b] | AposAttrValueContent | ::= | AposAttContentChar | /* ws: significant */ |
[114] | EnclosedExpr | ::= | "{" Expr "}" | |
[115] | XMLSpaceDecl | ::= | <"declare" "xmlspace"> ("preserve" | "strip") | |
[116] | DefaultCollationDecl | ::= | <"declare" "default" "collation"> StringLiteral | |
[116a] | BaseURIDecl | ::= | <"declare""base-uri"> StringLiteral | |
[118] | NamespaceDecl | ::= | <"declare" "namespace"> NCName "=" StringLiteral | |
[119] | DefaultNamespaceDecl | ::= | (<"declare" "default""element"> | <"declare" "default" "function">) "namespace" StringLiteral | |
[120] | FunctionDecl | ::= | <"declare" "function"> <QName "("> ParamList? (")" | (<")" "as"> SequenceType)) (EnclosedExpr | "external") | /* gn: parens */ |
[121] | ParamList | ::= | Param ("," Param)* | |
[122] | Param | ::= | "$" VarName TypeDeclaration? | |
[123] | TypeDeclaration | ::= | "as" SequenceType | |
[124] | SingleType | ::= | AtomicType "?"? | |
[125] | SequenceType | ::= | (ItemType OccurrenceIndicator?) | |
[126] | AtomicType | ::= | QName | |
[127] | ItemType | ::= | AtomicType | KindTest | <"item" "(" ")"> | |
[128] | KindTest | ::= | DocumentTest | |
[129] | ElementTest | ::= | <"element" "("> ((SchemaContextPath ElementName) | |
[130] | AttributeTest | ::= | <"attribute" "("> ((SchemaContextPath AttributeName) | |
[130a] | ElementName | ::= | QName | |
[130b] | AttributeName | ::= | QName | |
[130c] | TypeName | ::= | QName | |
[130d] | ElementNameOrWildcard | ::= | ElementName | "*" | |
[130e] | AttribNameOrWildcard | ::= | AttributeName | "*" | |
[130f] | TypeNameOrWildcard | ::= | ||
TypeName | "*" | ||||
[130g] | PITest | ::= | <"processing-instruction" "("> (NCName | StringLiteral)? ")" | |
[138] | DocumentTest | ::= | <"document-node" "("> ElementTest? ")" | |
[139] | CommentTest | ::= | <"comment" "("> ")" | |
[140] | TextTest | ::= | <"text" "("> ")" | |
[141] | AnyKindTest | ::= | <"node" "("> ")" | |
[142] | SchemaContextPath | ::= | <SchemaGlobalContext "/"> <SchemaContextStep "/">* | |
[143] | SchemaContextLoc | ::= | (SchemaContextPath? QName) | SchemaGlobalTypeName | |
[144] | OccurrenceIndicator | ::= | "?" | "*" | "+" | |
[145] | ValidationDecl | ::= | <"declare""validation"> SchemaMode | |
[146] | SchemaImport | ::= | <"import" "schema"> SchemaPrefix? StringLiteral <"at" StringLiteral>? | |
[147] | SchemaPrefix | ::= | ("namespace" NCName "=") | (<"default" "element"> "namespace") |
This section contains general notes on the EBNF productions, which may be helpful in understanding how to create a parser based on this EBNF, how to read the EBNF, and generally call out issues with the syntax. The notes below are referenced from the right side of the production, with the notation: /* gn: <id> */.
A look-ahead of one character is required to distinguish function patterns from a QName followed by a comment. For example: address (: this may be empty :)
may be mistaken for a call to a function named "address" unless this lookahead is employed.
Token disambiguation of the overloaded "<" pattern is defined in terms of positional lexical states. The "<" comparison operator can not occur in the same places as a "<" tag open pattern. The "<" comparison operator can only occur in the OPERATOR state and the "<" tag open pattern can only occur in the DEFAULT and the ELEMENT_CONTENT states. (These states are only a specification tool, and do not mandate an implementation strategy for this same effect.)
The ValidateExpr in the exposition, which does not use the "< ... >" token grouping, presents the production in a much simplified, and understandable, form. The ValidateExpr presented in the appendix is technically correct, but structurally hard to understand, because of limitations of the "< ... >" token grouping.
The "/" presents an issue because it occurs both in a leading position and an operator position in expressions. Thus, expressions such as "/ * 5" can easily be confused with the path expression "/*". Therefore, a stand-alone slash, in a leading position, that is followed by an operator, will need to be parenthesized in order to stand alone, as in "(/) * 5". "5 * /", on the other hand, is fine.
Expression comments are allowed inside expressions everywhere that ignorable white space is allowed. Note that expression comments are not allowed in constructor content.
The general rules for [XML 1.1] vs. [XML 1.0], as described in the A.2 Lexical structure section, should be applied to this production.
It is implementation-definedwhether legal characters in an XQuery expression are those characters allowed in [XML 1.0] or the larger set of characters allowed in [XML 1.1].
When patterns are simple string matches, the strings are embedded directly into the EBNF. In other cases, named terminals are used.
It is up to an implementation to decide on the exact tokenization strategy, which may be different depending on the parser construction. In the EBNF, the notation "< ... >" is used to indicate a grouping of terminals that together may help disambiguate the individual symbols.
This document uses lexical states to assist with terminal symbol recognition. The states specify lexical constraints and transitions based on grammatical positioning. The rules for calculating these states are given in the A.2.2 Lexical Rules section. The specification of these states in this document does not imply any tokenization strategy on the part of implementations.
When tokenizing, the longest possible match that is valid in the current lexical state is preferred .
All keywords are case sensitive. Keywords are not reserved—that is, any QName may duplicate a keyword except as noted in A.3 Reserved Function Names.
For readability, whitespace may be used in most expressions even though not explicitly notated in the EBNF. White space is tolerated before the first token and after the last token. White space isoptional between terminals, except a few cases where white space 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 white spaceor parentheses.
Special white spacenotation is specified with the EBNF productions, when it is different from the default rules, as follows.
"ws: explicit" means that the EBNF notation explicitly notates where white space is allowed, and whitespace isotherwise not allowed.
"ws: significant" means that white spaceis significant as value content.
For XQuery, White spaceis not freely allowed in the non-computed Constructor productions, but is specified explicitly in the grammar, in order to be more consistent with XML. The lexical states where white spacemust have explicit specification are as follows: START_TAG, END_TAG, ELEMENT_CONTENT, XML_COMMENT, PROCESSING_INSTRUCTION, PROCESSING_INSTRUCTION_CONTENT, CDATA_SECTION, QUOT_ATTRIBUTE_CONTENT, and APOS_ATTRIBUTE_CONTENT.
Forotherusage of white space, one or more white space characters are required to separate "words".Zero or more white space characters may optionally be used around punctuation and non-word symbols.
The lexical contexts and transitions between lexical contexts is described in terms of a series of states and transitions between those states.
The tables below define the complete lexical rules for XQuery. Each table corresponds to a lexical state and shows that the tokens listed are recognized when 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.
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 current EBNF production.
Note:
There is no requirement for a lexer/parser to be implemented in terms of lexical states—these are only a declarative way to specify the behavior. The only requirement is to produce results that are consistent with the results of these tables.
This state is for patterns that occur at the beginning of an expression or subexpression.
Pattern | Transition To State | ||
---|---|---|---|
DecimalLiteral, "..", ".", DoubleLiteral, IntegerLiteral, <NCName ":" "*">, QName,<"stable" "order" "by">, "]", ")", <"*" ":" NCName>, "*", StringLiteral, <"declare" "validation"> |
| ||
<"declare" "default" "collation">, <"declare""collation" "namespace">, <"declare" "base-uri">, <"module" "namespace"> |
| ||
| |||
"$", <"for" "$">, <"let" "$">, <"some" "$">, <"every" "$"> |
| ||
| |||
<")" "as"> |
| ||
| |||
| |||
"<!--" |
| ||
"<?" |
| ||
"<![CDATA[" |
| ||
"<" |
| ||
<"declare" "xmlspace"> |
| ||
"}" |
| ||
| |||
<"validate" "context">, <"validate" SchemaMode> |
| ||
<"element" "{">, <"attribute" "{"> |
| ||
<"attribute" QName "{">, <"namespace" NCName "{">, <"element" QName "{">, <"document" "{">, <"text" "{">, <"processing-instruction" "{">, <"processing-instruction" NCName "{">, <"comment" "{"> |
| ||
<"declare" "function"> |
| ||
"(:" |
| ||
"(::" |
| ||
|
This state is for patterns that are defined for operators.
Pattern | Transition To State | ||
---|---|---|---|
<"declare" "function"> |
| ||
| |||
| |||
<"declare" "default" "collation"> |
| ||
| |||
| |||
| |||
| |||
"}" |
| ||
"$", <"for" "$">, <"let" "$">, <"some" "$">, <"every" "$"> |
| ||
"(:" |
| ||
"(::" |
| ||
"]", IntegerLiteral, DecimalLiteral, DoubleLiteral, <"typeswitch" "(">, <"stable" "order" "by">, "collation", ")", "ascending", "descending", <"empty" "greatest">, <"empty" "least">, StringLiteral, "default", QName, <NCName ":" "*">, <"*" ":" NCName>, ".", ".." |
|
This state occurs inside of a namespace declaration, and is needed to recognize a NCName that is to be used as the prefix, as opposed to allowing a QName to occur. (Otherwise, the difference between NCName and QName are ambiguous.)
Pattern | Transition To State | ||
---|---|---|---|
StringLiteral |
| ||
"(:" |
| ||
"(::" |
| ||
"=", NCName |
|
This state occurs at places where the keyword "namespace" is expected, which would otherwise be ambiguous compared to a QName. QNames can not occur in this state.
Pattern | Transition To State | ||
---|---|---|---|
StringLiteral, <"at" StringLiteral> |
| ||
"namespace" |
| ||
"(:" |
| ||
"(::" |
| ||
|
This state occurs at places where the keywords "preserve" and "strip" is expected to support "declare xmlspace". QNames can not occur in this state.
Pattern | Transition To State |
---|
This state distinguishes tokens that can occur only inside the ItemType production.
Pattern | Transition To State | ||
---|---|---|---|
"$" |
| ||
<"empty" "(" ")"> |
| ||
"(:" |
| ||
"(::" |
| ||
| |||
<"processing-instruction" "("> |
| ||
QName, <"item" "(" ")"> |
|
Pattern | Transition To State | ||
---|---|---|---|
"{" |
| ||
<SchemaGlobalContext "/">, SchemaGlobalTypeName |
| ||
")" |
| ||
"*", QName |
| ||
<"element" "("> |
| ||
"@", "context", "global", StringLiteral |
|
Pattern | Transition To State | |
---|---|---|
")" |
| |
NCName, StringLiteral |
|
Pattern | Transition To State | |
---|---|---|
")" |
| |
"," |
| |
"{" |
| |
"nillable" |
|
Pattern | Transition To State | ||
---|---|---|---|
NotOccurrenceIndicator |
| ||
"?", "*", "+" |
|
This state distinguishes the SchemaContextStep from the SchemaGlobalContext.
Pattern | Transition To State | |
---|---|---|
<SchemaContextStep "/">, "@" |
| |
"{" |
| |
QName |
|
This state differentiates variable names from qualified names. This allows only the pattern of a QName to be recognized when otherwise ambiguities could occur.
Pattern | Transition To State | ||
---|---|---|---|
VarName |
| ||
"(:" |
| ||
"(::" |
|
This state allows attributes in the native XML syntax, and marks the beginning of an element construction. Element constructors also push the current state, popping it at the conclusion of an end tag. In the START_TAG state, the string ">" is recognized as a token which is associated with the transition to the original state.
Pattern | Transition To State | ||
---|---|---|---|
"/>" |
| ||
">" |
| ||
'"' |
| ||
"'" |
| ||
"{" |
| ||
S, QName, "=" |
|
This state allows XML-like content, without these characters being misinterpreted as expressions. The character "{" marks a transition to the DEFAULT state, i.e. the start of an embedded expression, and the "}" character pops back to the ELEMENT_CONTENT state. To allow curly braces to be used as character content, a double left or right curly brace is interpreted as a single curly brace character. The string "</" is interpreted as the beginning of an end tag, which is associated with a transition to the END_TAG state.
Pattern | Transition To State | ||
---|---|---|---|
"</" |
| ||
"{" |
| ||
"<!--" |
| ||
"<?" |
| ||
"<![CDATA[" |
| ||
"<" |
| ||
PredefinedEntityRef, CharRef, "{{", "}}", ElementContentChar |
|
The "<--" token marks the beginning of an XML Comment, and the "-->" token marks the end. This allows no special interpretation of other characters in this state.
Pattern | Transition To State | |
---|---|---|
"-->" |
| |
|
The "(:" token marks the beginning of an expression Comment, and the ":)" token marks the end. This allows no special interpretation of other characters in this state.
Pattern | Transition To State | ||
---|---|---|---|
":)", "::)" |
| ||
"(:" |
| ||
"(::" |
| ||
ExprCommentContent, PragmaContents, ExtensionContents |
|
The "(::" token marks the beginning of an expression extension, which must be followed by a keyword.
Pattern | Transition To State | |
---|---|---|
QName |
| |
"pragma", "extension" |
|
In this state, only lexemes that are legal in a processing instruction name are recognized.
Pattern | Transition To State | |
---|---|---|
PITarget |
|
In this state, only characters are that are legal in processing instruction content are recognized.
Pattern | Transition To State | |
---|---|---|
"?>" |
| |
Char |
|
In this state, only lexemes that are legal in a CDATA section are recognized.
Pattern | Transition To State | |
---|---|---|
"]]>" |
| |
Char |
|
This state allows content legal for attributes. The character "{" marks a transition to the DEFAULT state, i.e. the start of an embedded expression, and the "}" character pops back to the original state. To allow curly braces to be used as character content, a double left or right curly brace is interpreted as a single curly brace character. This state is the same as APOS_ATTRIBUTE_CONTENT, except that apostrophes are allowed without escaping, and an unescaped quote marks the end of the state.
Pattern | Transition To State | ||
---|---|---|---|
'"' |
| ||
"{" |
| ||
EscapeQuot, PredefinedEntityRef, CharRef, "{{", "}}", QuotAttContentChar |
|
This state is the same as QUOT_ATTRIBUTE_CONTENT, except that quotes are allowed, and an unescaped apostrophe marks the end of the state.
Pattern | Transition To State | ||
---|---|---|---|
"'" |
| ||
"{" |
| ||
EscapeApos, PredefinedEntityRef, CharRef, "{{", "}}", AposAttContentChar |
|
Under certain circumstances, an atomic value can be promoted from one type to another. Type promotion is used in function calls (see 3.1.5 Function Calls) and in processing of operators that accept numeric operands (listed in the tables below). The following type promotions are permitted:
A value of type xs:float
(or any type
derived by restriction from 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. This kind of promotion may cause loss of
precision.
A value of type xs:decimal
(or any type derived
by restriction from xs:decimal
) can be promoted to either
of the types xs:float
or xs:double
. The
result of this promotion is created by casting the original value to
the required type.
Note that promotion is different from subtype substitution. For example:
A function that expects a parameter $p
of type xs:float
can be invoked with a value of type xs:decimal
. This is an example of promotion. The value is actually converted to the expected type. Within the body of the function, $p instance of xs:decimal
returns false
.
A function that expects a parameter $p
of type xs:decimal
can be invoked with a value of type xs:integer
. This is an example of subtype substitution. The value retains its original type. Within the body of the function, $p instance of xs:integer
returns true
.
The tables in this section list the
combinations of types for which the various operators of XQuery
are defined in terms of functions that are defined in [XQuery 1.0 and XPath 2.0 Functions and Operators]. The and
and
or
operators are defined directly in the main body of
this document, and do not occur in thistable. For each valid
combination of types, the table indicates the function(s) that are
used to implement the operator and the type of the result. Note that in some cases the function does not implement the full semantics of the given operator. For thedefinition of each operator (including
its
behavior for empty sequences or sequences of length greater than
one),
see the descriptive material in the main part of this
document.
Any operatorlisted in the tables may be validly
applied to an operand of type ATif the table calls for
anoperand of type ET and
type-matches(
ET, AT)
is
true
(see2.4.4 SequenceType Matching). For
example, a table entry indicates that the gt
operator may
be applied to two xs:date
operands, returning
xs:boolean
. Therefore, the gt
operator may
also be applied to two (possibly different) subtypes of
xs:date
, also returning xs:boolean
.
In
the operator tables, the term numeric refers to the types
xs:integer
, xs:decimal
,
xs:float
, and xs:double
. An operator whose
operands and result are designated as numeric might be
thought of as representing four operators, one for each of the numeric
types. For example, the numeric +
operator might be
thought of as representing the following four operators:
Operator | First operand type | Second operand type | Result type |
+ | xs:integer | xs:integer | xs:integer |
+ | xs:decimal | xs:decimal | xs:decimal |
+ | xs:float | xs:float | xs:float |
+ | xs:double | xs:double | xs:double |
A numeric operator maybe validly applied to an operand of type AT if type-matches(
ET, AT)
is true where ETis any of the four numeric types. If the result type of an operator is listed as numeric, it means "the first typein the ordered list (xs:integer,xs:decimal, xs:float, xs:double)
into which all operands can be converted by subtype substitution and promotion." As an example, suppose that the type hatsize
is derived from xs:integer
and the type shoesize
is derived from xs:float
. Then if the +
operator is invoked with operands of type hatsize
and shoesize
, it returns a result of type xs:float
. Similarly, if +
is invoked with two operands of type hatsize
it returns a result of type xs:integer
.
In the following tables,
the term Gregorian refers to the types
xs:gYearMonth
, xs:gYear
,
xs:gMonthDay
, xs:gDay
, and
xs:gMonth
. For binary operators that accept two
Gregorian-type operands, both operands must have the same type (for
example, if one operand is of type xs:gDay
, the other
operand must be of type xs:gDay
.)
Operator | Operand type | Function | Result type |
---|---|---|---|
+ A | numeric | op:numeric-unary-plus(A) | numeric |
- A | numeric | op:numeric-unary-minus(A) | numeric |
The tables in this section describe how values are assigned to the various components of the static context and dynamic context, and to the parameters that control the serialization process.
The following table describes the components of the static context. The following aspects of each component are described:
Default value: This is the value of the component if it is not overridden or augmented by the implementation or by a query.
Can be overwritten or augmented by implementation: Indicates whether an XQuery implementation is allowed to replace the default value of the component by a different value and/or to augment the default value by additional values.
Can be overwritten or augmented by a query: Indicates whether a query is allowed to replace and/or augment the initial value provided by default or by the implementation. If so, indicates how this is accomplished (for example, by a declaration in the prolog).
Scope: Indicates where the component is applicable. "Global" indicates that the component applies throughout a module. "Lexical" indicates that the component applies within the expression in which it is defined (same as "global" if the component is declared in the prolog of a module.)
Consistency Rules: Indicates rules that must be observed in assigning values to the component. If any consistency rule is violated, a static error is raised. Additional consistency rules may be found in 2.2.5 Consistencyis Constraints.
Component | Default predefined value | Can be overwritten or augmented by implementation? | Can be overwritten or augmented by a query? | Scope | Consistency rules |
---|---|---|---|---|---|
XPath 1.0 Compatability Mode | false | no | no | global | Must be false. |
In-scope namespaces | fn, xml, xs, xsi, xdt, local | overwriteable and augmentable (except for xml) | overwriteable and augmentable by prolog or element constructor | lexical | Only one namespace can be assigned to a given prefix per lexical scope. |
Default element/type namespace | no namespace | overwriteable | overwriteable by prolog or element constructor | lexical | Only one default namespace per lexical scope. |
Default function namespace | fn | overwriteable (not recommended) | overwriteable by prolog | global | Only one declaration per prolog. |
In-scope type definitions | Built-in types in xs, xdt | augmentable | augmentable by schema import in prolog | global | Only one definition per global or local type. |
In-scope element declarations | none | augmentable | augmentable by schema import in prolog | global | Only one definition per global or local element name. |
In-scope attribute declarations | none | augmentable | augmentable by schema import in prolog | global | Only one definition per global or local attribute name. |
In-scope variables | none | augmentable | overwriteable and augmentable by prolog and by variable-binding expressions | lexical | Only one definition per variable per lexical scope. |
In-scope functions | Functions in fn namespace, and constructors for built-in atomic types | augmentable | augmentable by module import and by function declaration in prolog | global | Only one user-declared function with a given name; only one built-in function with a given name and argument cardinality. |
In-scope collations | only the default collation | augmentable | no | global | Each URI uniquely identifies a collation. |
Default collation | Unicode codepoint collation | overwriteable | overwriteable by prolog | global | Only one default collation. |
Validation mode | lax | overwriteable | overwriteable by prolog or validate expression | lexical | Only one validation mode per lexical scope. |
Validation context | global | no | overwriteable by validate expression | lexical | Only one validation context per lexical scope. |
XMLSpace policy | strip | overwriteable | overwriteable by prolog | global | Only one XMLSpace declaration per prolog. |
Base URI | none | overwriteable | overwriteable by prolog | global | Only one base-uri declaration per prolog. |
Statically-known documents | none | augmentable | no | global | None |
Statically-known collections | none | augmentable | no | global | None |
The following table describes the components of the dynamic context. The following aspects of each component are described:
Default value: This is the value of the component if it is not overridden or augmented by the implementation or by a query.
Can be overwritten or augmented by implementation: Indicates whether an XQuery implementation is allowed to replace the default value of the component by a different value and/or to augment the default value by additional values.
Can be overwritten or augmented by a query: Indicates whether a query is allowed to replace and/or augment the initial value provided by default or by the implementation. If so, indicates how this is accomplished.
Scope: Indicates where the component is applicable. "Global" indicates that the component applies throughout a module. "Dynamic" indicates that the value of the component can be influenced by the evaluation of expressions within a query.
Consistency Rules: Indicates rules that must be observed in assigning values to the component. Additional consistency rules may be found in 2.2.5 Consistencyis Constraints.
Component | Default predefined value | Can be overwritten or augmented by implementation? | Can be overwritten or augmented by a query? | Scope | Consistency rules |
---|---|---|---|---|---|
Context item | none | overwriteable | overwritten during evaluation of path expressions and predicates | dynamic | none |
Context position | none | overwriteable | overwritten during evaluation of path expressions and predicates | dynamic | Must be consistent with context item and context size |
Context size | none | overwriteable | overwritten during evaluation of path expressions and predicates | dynamic | Must be consistent with context item |
Dynamic variables | none | augmentable | overwriteable and augmentable by prolog and by variable-binding expressions | dynamic | Names and values must be consistent with in-scope variables. |
Current date and time | none | Must be initialized by implementation | no | global | Remains constant during evaluation of a query. |
Implicit timezone | none | overwriteable | no | global | Remains constant during evaluation of a query. |
Available documents | none | augmentable | no | global | None |
Available collections | none | augmentable | no | global | None |
The following table specifies default values for the parameters that control the process of serializing the Data Model into XML notation. The meanings of the various parameters are defined in [XSLT 2.0 and XQuery 1.0 Serialization]. For each parameter, an XQuery implementation may (but is not required to) provide a means whereby a user can override the default value.
Parameter | Default Value |
---|---|
encoding | implementation-defined |
cdata-section-elements | empty |
doctype-system | empty |
doctype-public | empty |
escape-uri-attributes | no |
indent | no |
media-type | implementation-defined |
normalize-unicode | implementation-defined |
omit-xml-declaration | yes |
standalone | yes |
character-map | empty |
version | 1.0 |
Editorial note | |
As of the date of this publication, XQueryX has not incorporated recent language changes; it will be made consistent with this document in its next edition. |
An atomic value is a value in the value space of an XML Schema atomic type, as defined in [XML Schema] (that is, a simple type that is not a list type or a union type).
Atomization is
applied to a value when the value is used in a context in which a
sequenceof atomic values is required. The result of atomization is
eithera sequence of atomic valuesor a type error. Atomization of a sequenceis defined as the resultof invoking the fn:data
function
onthe sequence, as definedin [XQuery 1.0 and XPath 2.0 Functions and Operators].
An AttributeTest is used to match an attribute node by its name and/or type.
Available
collections.This is a mapping of
strings onto sequences of nodes. Thestring
representsthe absolute URI of a
resource.The sequence of nodes represents
theresult of the fn:collection
functionwhen that URI is supplied as the
argument.
Available
documents. This is a mapping of
strings onto document nodes. The string
represents the absolute URI ofa
resource. The document node is theroot of a treethat represents that resource using the data model. The document node is returnedby the fn:doc
function when applied to that URI.
Base URI. This is an absolute URI, used when necessary in the resolution of relative URIs (for example, by the fn:resolve-uri
function.)
The context item is the item currently being processed in a path expression. An item is either an atomic value or a node.
When the context item is a node, it can also be referred to as the context node.
The context position is the position of the context item within the sequence of items currently being processed in apath expression.
The context size is the number of items in the sequence of items currently being processed in a path expression.
Current date and time. This information represents
an implementation-dependent point in time during processing of a query or transformation. It can be retrieved by the fn:current-date
, fn:current-time
, and fn:current-dateTime
functions. If invoked multiple times during the execution of a query or transformation,
these functions always return the same result.
XQuery operates on the abstract, logical structure of an XML document, rather than its surface syntax. This logical structure is known as the data model, which is defined in the [XQuery 1.0 and XPath 2.0 Data Model] document.
Fora given node in the datamodel,the data model schemais defined as the schema from which the type annotation ofthat node was derived.
Default collation. This collation is used by string comparison functions and operators when no explicit collation is specified.
Default element/type namespace. This is a namespace URI. This namespace is used for any unprefixed QName appearing in a position where an element or type name is expected.
Default function namespace. This is a namespace URI. This namespace URI is used for any unprefixed QName appearing as the function name in a function call. The initial default function namespace may be provided by the external environment or by a declaration in the Prolog of a module.
The dynamic context ofan expression is definedas information that is available at the time the expression is evaluated.
A dynamic erroris anerror that mustbe detected during the evaluation phase and may be detected duringthe analysisphase. Numericoverflow is an example of a dynamic error.
The dynamic evaluation phase occurs after completionof the staticanalysis phase. Duringthe dynamicevaluation phase, the value of the queryis computed.
A dynamic type is associated with each value as it is computed. The dynamic type of a value may be either a structural description (such as "sequence of integers") or a named type.
Dynamic variables. This is a set of (QName, value) pairs. It contains the same QNames as the in-scope variables in the static context for the expression. TheQName is thename of the variable and the value isthe dynamic value of the variable.
The
effective boolean value of a value is defined as the result
ofapplying the fn:boolean
function to the value, as
defined in [XQuery 1.0 and XPath 2.0 Functions and Operators].
An ElementTest isused to match an elementnode by its nameand/or type.
A sequence containing zero items is called an empty sequence.
Anerrorvalue isa single item or the empty sequence.
The expression context for a given expression consists of all the information that can affect the result of the expression.
External functions are functions that are implemented outside the query environment.
The first three components of the dynamiccontext (context item, context position, and context size) are called the focus of the expression.
Functionimplementations.Each function inin-scopefunctionshas a function implementation that enables the functionto map instances of its parameter types into an instance of its result type. Fora user-defined function,the function implementation isan XQuery expression.For an external function,the function implementation is implementation-dependent.
Eachfunction has a function signaturethat specifies the nameof the function and the statictypesofits parameters and its result.
XQuery is a functional language, which meansthat expressions can be nested with full generality. (However, unlike a pure functional language, it does not allow variable substitutability if the variable declaration contains construction of new nodes.)
Implementation-dependent indicates an aspect that may differ between implementations, is not specified by this or any W3C specification, and is not required to be specified by the implementor for any particular implementation.
Implementation-defined indicates an aspect that may differ between implementations, but must be specified by the implementor for each particular implementation.
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
xdt:dayTimeDuration
that is
implementation-defined . See [ISO 8601] for the range of legal values
of a timezone.
In-scope attribute declarations. Each attribute declaration is identified either by a QName (for a top-level attribute declaration)or by an implementation-dependent attribute identifier (for a local attribute declaration). If the Schema Import Feature is supported, in-scope attribute declarations include all attribute declarations found in imported schemas.
In-scope collations. This is a set of (URI, collation) pairs. It defines the names of the collations that are available for use in function calls that take a collation name as an argument.
In-scope element declarations. Each element declaration is identified either by a QName (for a top-level element declaration)or by an implementation-dependentelement identifier (for a local elementdeclaration). If the Schema Import Feature is supported, in-scope element declarations include all element declarations found in imported schemas. An element declaration includes information about the substitution groups to which this element belongs.
In-scope functions. This componentdefines the set of functions that are available to be called from within an expression. Each function is uniquely identified by its expanded QName and its arity (number of parameters).
In-scope namespaces. This is a set of (prefix, URI) pairs. The in-scope namespaces are used for resolving prefixes used in QNames within the expression.
In-scope schema definitions. This is a generic term for all the element, attribute, and type definitions that are in scope during processing of an expression.
In-scope type definitions. Each named type definition is identified either by a QName(for a namedtype) orbyan implementation-dependenttype identifier(for an anonymous type).Thein-scope type definitions includethe predefined types as described in 2.4.1 Predefined Types. If the Schema Import Feature is supported, in-scope type definitions also include all type definitions found in imported schemas.
In-scope variables. This is a set of (QName, type) pairs. It defines the set of variables that are available for reference within an expression. The QName is the name of the variable, and the type isthe static typeof the variable.
If a variable declaration includes an expression, the expression is called an initializing expression.
An item is either an atomic value or a node.
A module that contains a module declaration followed by a Prolog is called a library module.
A literal is a direct syntactic representation of an atomic value.
A module that contains a Prolog followed by a Query Body is called a main module.
A module is a fragment of XQuery code that can independently undergo the analysis phase described in 2.2.3 Expression Processing
Amodule declaration serves to identifya module as a librarymodule.A moduledeclaration consists of the keyword module
followed by a namespace prefix and a string literal which must contain a valid URI.[err:XQ0046]
A module import imports the function declarations and variable declarations from the Prolog of a library module into the in-scope functions and in-scope variables of the importing module.
An implementation may extend XQuery functionality by supporting must-understand extensions. A must-understand extension may be used anywhere that ignorable whitespace is allowed.
A node is an instance of one of the seven node kinds defined in [XQuery 1.0 and XPath 2.0 Data Model].
A pragma may be used to provide additional information to an XQuery implementation.
Primary expressions are the basic primitives of the language. They include literals, variable references, contextitem expressions,constructors, and function calls. Aprimary expression may also be created by enclosing any expression in parentheses, which is sometimes helpful in controllingthe precedence of operators.
APrologis a series of declarations and imports that create the environment for queryprocessing.
TheQueryBody,if present, consistsof an expression that defines the result of the query.
A schema import imports the element, attribute, and type definitions from a named schema into the in-scope schema definitions.
If the Schema Import Feature is supported, aPrologmay contain a schemaimport.Definitions fromthe importedschema are addedto the in-scope schema definitions.
A sequenceis an ordered collection of zero or more items.
When it is necessary to refer to a type in an XQuery expression, the SequenceTypesyntax is used. The name SequenceTypesuggests that this syntax is used todescribe the type of an XQuery value, which is always a sequence.
During evaluation of an expression, it is sometimes necessary to determine whether a value with a known type "matches" an expected type, expressed inthe SequenceType syntax. This process is known as SequenceType matching.
Serializationis the processof convertinga set of nodes from the datamodelinto a sequenceof octets (step DM4 in Figure 1.)
A sequence containing exactly one item is called a singleton sequence.
The static analysis phasedepends on the expression itself and onthe staticcontext.The staticanalysis phasedoes notdepend on inputdata (other than schemas).
The static context of an expression is the information that is available during static analysis of the expression, prior to its evaluation.
Astatic erroris an errorthat mustbe detected during the analysis phase. A syntax error is anexampleof a staticerror. Themeans by which staticerrorsare reportedduring the analysisphase is implementation-defined.
The statictypeof an expression may be either a named type or a structural description—for example, xs:boolean?
denotes an optional occurrence of the xs:boolean
type. The rules for inferring the static types of various expressions are describedin [XQuery 1.0 and XPath 2.0 Formal Semantics].
A static typing extension is a type inference rule that infers a more precise static type than that inferred by the type inference rules in [XQuery 1.0 and XPath 2.0 Formal Semantics].
An XQuery implementationthat does not support the Static Typing Feature is not required to raise typeerrors during the staticanalysis phase.
Statically-knowncollections.This is a
mappingfromstringsontotypes. Thestring represents the absolute
URIof a resourcethat is potentially available using the
fn:collection
function. Thetype is thetype of the
sequence of nodes that wouldresultfrom calling the
fn:collection
function with thisURI as its
argument.
Statically-known documents. This is a mapping
from strings onto types. The string representsthe absolute URI of a
resource that is potentially available using the fn:doc
function. Thetypeis the type of the document node that would result
from calling the fn:doc
function with thisURI as its
argument.
XQuery is also a strongly-typed language in which the operands of various expressions, operators, and functions must conform to the expected types.
TheURI identifiesthe target namespaceof the module,which is the namespace for all variables and functions exported by the module.
Atype errormay be raised during the analysisorevaluation phase. Duringthe analysis phase, a typeerroroccurs whenthe statictypeof anexpression does not match the expected type of the contextin whichthe expressionoccurs. Duringthe evaluationphase, a typeerroroccurs whenthe dynamictype of a value does not matchthe expectedtypeof the context in which thevalue occurs.
For a user-defined function, the function declaration includes an expression called the function body that defines how the result of the function is computed from its parameters.
Validation mode. The
validationmode specifies the mode in which
validation is performed by element constructors
and by validate
expressions.
Validation context.An expression'svalidation context determines the context in which elements constructed by the expression are validated.
XMLSpace policy. This policy, declared in the Prolog, controls the processing of whitespace by element constructors.
XPath1.0 compatibility
mode.This
componentmust be set byall host languages
thatinclude XPath 2.0 asa subset,
indicatingwhether rules for compatibility
withXPath 1.0 are in effect.
XQuerysetsthe value of this component to
false
.
An XQuery Flagger is a facility that is provided by an implementation that is able to identify queries that contain must-understand extensions.If an implementation supports must-understand extensions, then an XQuery Flagger must be provided.
An XQuery Static Flagger is a facility that is able to identify queries that require a static typing extension.
It is a static error if analysis of an expression relies on some component of the static context that has not been assigned a value.
It is a dynamic error if evaluation of an expression relies on some part of the dynamic context that has not been assigned a value.
It is a static error if an expression is not a valid instance of the grammar defined in A.1 EBNF.
During the analysis phase, it is a type error if the static typing feature is in effect and an expression is found to have a static type that is not appropriate for the context in which the expression occurs.
During the analysis phase,
it is a type error
if the static typing feature is in effect
and the static type assigned to an
expression other than the expression ()
is the empty type.
During the evaluation phase, it is a type error if a value does not match a required type as specified by the matching rules in 2.4.4 SequenceType Matching.
It is a type error if the
fn:data
function is applied to a node
whose type annotation denotes a complex type with non-mixed complex content.
It is a static error if an expression refers to a type name, function name, namespace prefix, or variable name that is not defined in the static context.
An implementation that does not support the Schema Import Feature may raise a static error if a prolog contains a schema import.
An implementation that does not support the Full Axis Feature may raise a static error if a path expression references an unsupported axis (ancestor, ancestor-or-self, following, following-sibling, preceding, or preceding-sibling).
If the Schema Import Feature is in effect, it is a static error if the set of definitions contained in all imported schemas do not satisfy the conditions for schema validity specified in Sections 3 and 5 of [XML Schema] Part 1. In particular, the definitions must be valid, they must be complete, and they must be unique -- that is, the pool of definitions must not contain two or more schema components with the same name and target namespace.
It is a static error if an implementation supports a pragma and the implementation determines that the PragmaContents are invalid.
It is a static error if an implementation does not support a must-understand extension or an implementation does support a must-understand extension and the implementation determines that the ExtensionContents are invalid.
It is a static error if the XQuery Flagger is enabled and the query contains a must-understand extension.
An implementation that does not support the Module Feature raises a static error if it encounters a module declaration or a module import.
It is a static error if the expanded QName and number of arguments in a function call do not match the name and arity of an in-scope function in the static context.
It is a static error for an expression to depend on the focus when the focus is undefined.
It is a type error if the result of a step expression (StepExpr) is not a sequence of nodes.
It is a type error if in an axis expression, the context item is not a node.
It is a dynamic error if a value in a cast expression cannot be cast to the required type.
It is a static error if the value of a namespace declaration attribute is not a literal string.
It is a type error if the content sequence in an element constructor contains a document node.
It is a type error if the content sequence in an element constructor contains an attribute node following a node that is not an attribute node or a namespace node.
It is a dynamic error if two or more attribute values in the content sequence of an element constructor have the same name.
In an element-constructor expression,
it is a dynamic error if
the validation mode is strict
and
the in-scope element
declarations do not contain an element declaration whose
unique name matches the name of the constructed element.
In an element-constructor or validate expression, it is a dynamic error if validation fails.
It is a type error if the content sequence in a document constructor contains a document, attribute, or namespace node.
It is a dynamic error in a cast expression if the input value does not satisfy the facets of the target type.
It is a type error
if the argument of a validate
expression does not
evaluate to exactly one document or element node.
It is a static error if the version number specified in a version declaration is not supported by the implementation.
A static error is raised if the query prolog contains multiple declarations for the base URI.
It is a static error if the query prolog contains multiple declarations for the same namespace prefix.
It is a static error if more than one function declared or imported by a module has the same expanded QName.
It is a static error to import two schemas that both define the same name in the same symbol space and in the same scope.
It is a type error to import a module if the importing module's in-scope type definitions do not include definitions for the type names that appear in variable declarations, function parameters, or function returns found in the imported module.
It is a static error to import a module that contains function declarations or variable declarations whose names are already declared in the static context of the importing module.
It is a static error if a query prolog specifies more than one default collation, or value specified does not identify a collation known to the implementation.
It is an static error for a function declaration to have more than one parameter with the same name.
It is a type error if the content sequence in an element constructor contains a namespace node node following a node that is not a namespace node.
It is a dynamic error if the name expression in a computed processing instruction or computed namespace constructor returns a QName whose URI part is not empty.
It is a static error if the enclosing expression of a computed namespace constructor is not a computed element constructor.
It is a dynamic error if two or more computed namespace constructors within the same computed element constructor attempt to bind the same namespace prefix.
It is a dynamic error
if the name expression of a computed attribute constructor returns a QName that is in the namespace http://www.w3.org/TR/REC-xml-names
(corresponding to namespace prefix xmlns
).
It is a static error
if the declared function name in a function declaration has no namespace prefix or has one of the predefined namespace prefixes other than local
.
It is a static error
if a string that is required to contain a valid URI does not contain a valid lexical form according to the definition of xs:anyURI
in [XML Schema].
It is a static error if the target URI (and location hint, if present) in a module import do not identify an available module.
It is a static error if a function or variable declared in a library module is not in the target namespace of the library module.
It is a static error if more than one variable declared or imported by a module has the same expanded QName.
It is a dynamic error
if dynamic type of the operand of a treat
expression does not match the type specified by the treat
expression.
It is a static error if a QName that is used as an AtomicType in a SequenceType is not defined in the in-scope type definitions as an atomic type.
It is a dynamic error
if the content of an element or attribute constructor includes an atomic value that cannot be cast into a string, such as a value of type xs:QName
or xs:NOTATION
.
It is a static error if the string literal used in a namespace declaration to specify a URI is a zero-length string.
It is a dynamic error if the initializing expression in a variable declaration cannot be executed because of a circularity (for example, the expression depends on a function that in turn depends on the value of the initialized variable).
It is a static error if an ElementTest specifies a schema path that is not found in the in-scope schema definitions.
This section contains examples of several important classes of queries that can be expressed using XQuery. The applications described here include joins across multiple data sources, grouping and aggregation, queries based on sequential relationships, recursive transformations, and selection of distinctcombinations of values.
Joins, which combine data from multiple sources into a single result, are a very important type of query. In this section we will illustrate how several types of joins can be expressed in XQuery. We will base our examples on the following three documents:
A document named
parts.xml
that
contains many
part
elements;
each part
element in turn
contains
partno
and
description
subelements.
A document named
suppliers.xml
that
contains many
supplier
elements; each
supplier
element in turn
contains
suppno
and
suppname
subelements.
A document named
catalog.xml
that
contains information
about the
relationships between
suppliers and
parts. The catalog
document contains many
item
elements,
each of which in turn
contains
partno
,
suppno
, and
price
subelements.
A conventional ("inner") join returns information from two or more related sources, as illustrated by the following example, which combines information from three documents. The example generates a "descriptive catalog" derived from the catalog document, but containing part descriptions instead of part numbers and supplier names instead of supplier numbers. The new catalog is ordered alphabetically by part description and secondarily by supplier name.
<descriptive-catalog>
{
for $i in fn:doc("catalog.xml")//item,
$p in fn:doc("parts.xml")//part[partno = $i/partno],
$s in fn:doc("suppliers.xml")//supplier[suppno = $i/suppno]
order by $p/description, $s/suppname
return
<item>
{
$p/description,
$s/suppname,
$i/price
}
</item>
}
</descriptive-catalog>
The previous query returns information only about parts that have suppliers and suppliers that have parts. An outer join is a join that preserves information from one or more of the participating sources, including elements that have no matching element in the other source. For example, a left outer join between suppliers and parts might return information about suppliers that have no matching parts.
The following query demonstrates a left outer join. It returns names of all the suppliers in alphabetic order, including those that supply no parts. In the result, each supplier element contains the descriptions of all the parts it supplies, in alphabetic order.
for $s in fn:doc("suppliers.xml")//supplier
order by $s/suppname
return
<supplier>
{
$s/suppname,
for $i in fn:doc("catalog.xml")//item
[suppno = $s/suppno],
$p in fn:doc("parts.xml")//part
[partno = $i/pno]
order by $p/description
return $p/description
}
</supplier>
The previous query preserves information about
suppliers that supply no parts. Another type of join,
called a full outer join, might be used
to preserve information about both suppliers that
supply no parts and parts that have no supplier. The
result of a full outer join can be structured in any
of several ways. The following query generates a list
of supplier
elements, each containing
nested part
elements for the parts that
it supplies (if any), followed by a list of
part
elements for the parts that have no
supplier. This might be thought of as a
"supplier-centered" full outer join. Other forms of
outer join queries are also possible.
<master-list>
{
for $s in fn:doc("suppliers.xml")//supplier
order by $s/suppname
return
<supplier>
{
$s/suppname,
for $i in fn:doc("catalog.xml")//item
[suppno = $s/suppno],
$p in fn:doc("parts.xml")//part
[partno = $i/partno]
order by $p/description
return
<part>
{
$p/description,
$i/price
}
</part>
}
</supplier>
,
(: parts that have no supplier :)
<orphan-parts>
{ for $p in fn:doc("parts.xml")//part
where fn:empty(fn:doc("catalog.xml")//item
[partno = $p/partno] )
order by $p/description
return $p/description
}
</orphan-parts>
}
</master-list>
The previous query uses an element constructor to
enclose its output inside a master-list
element. The concatenation operator (",") is used to
combine the two main parts of the query. The result is
an ordered sequence of supplier
elements
followed by an orphan-parts
element that
contains descriptions of all the parts that have no
supplier.
Many queries
involve forming data into groups and
applying some aggregation function
such as fn:count
or
fn:avg
to each group. The
following example shows how such a
query might be expressed in XQuery,
using the catalog document defined in
the previous section.
This query finds the part number and average price for parts that have at least 3 suppliers.
for $pn in fn:distinct-values(fn:doc("catalog.xml")//partno)
let $i := fn:doc("catalog.xml")//item[partno = $pn]
where fn:count($i) >= 3
order by $pn
return
<well-supplied-item>
<partno> {$p} </partno>
<avgprice> {fn:avg($i/price)} </avgprice>
</well-supplied-item>
The fn:distinct-values
function
in this query eliminates duplicate
part numbers from the set of all part
numbers in the catalog document. The
result of fn:distinct-values
is a
sequence in which order is not
significant.
Note that $pn
, bound by a
for clause, represents an individual
part number, whereas $i
, bound by a
let clause, represents a set of items
which serves as argument to the
aggregate functions
fn:count($i)
and
fn:avg($i/price)
. The query
uses an element constructor to enclose
each part number and average price in
a containing element called
well-supplied-item
.
The method illustrated above generalizes easily to grouping by more than one data value. For example, consider a census document containing a sequence of person
elements, each with subelements named state
, job
, and income
. A census analyst might need to prepare a report listing the average income
for each combination of state
and job
. This report might be produced using the following query:
for $s in fn:distinct-values(fn:doc("census.xml")//state),
$j in fn:distinct-values(fn:doc("census.xml")//job)
let $p := fn:doc("census.xml")//person[state = $s and job = $j]
order by $s, $j
return
if (fn:exists($p)) then
<group>
<state> {$s} </state>
<job> {$j} </job>
<avgincome> {fn:avg($p/income)} </avgincome>
</group>
else ()
The if-then-else
expression in the above example prevents generation of groups that contain no data. For example, the census data may contain some persons who live in Nebraska, and some persons whose job is Deep Sea Fisherman, but no persons who live in Nebraska and have the job of Deep Sea Fisherman. If output groups are desired for all possible combinations of states and jobs, the if-then-else
expression can be omitted from the query. In this case, the output may include "empty" groups such as the following:
<group> <state>Nebraska</state> <job>Deep Sea Fisherman</state> <avgincome/> </group>
XQuery uses the
<<
and >>
operators to compare nodes based on document
order. Although these operators are quite simple, they
can be used to express complex queries for XML
documents in which sequence is meaningful. The first
two queries in this section involve a surgical report
that contains procedure
,
incision
, instrument
,
action
, and anesthesia
elements.
The following query returns all the
action
elements that occur between the
first and second incision
elements inside
the first procedure. The original document order
among these nodes is preserved in the result of the
query.
let $proc := //procedure[1]
for $i in $proc//action
where $i >> ($proc//incision)[1]
and $i << ($proc//incision)[2]
return $i
It is worth noting here that document order is
defined in such a way that a node is considered to
precede its descendants in document order. In the
surgical report, an action
is never part
of an incision
, but an
instrument
is. Since the
>>
operator is based on document
order, the predicate $i >>
($proc//incision)[1]
is true for any
instrument
element that is a descendant
of the first incision
element in the
first procedure.
For some queries, it may be
helpful to define a function that can test whether a
node precedes another node without being its
ancestor. The following function returns
true
if its first operand precedes its
second operand but is not an ancestor of its second
operand; otherwise it returns false
:
declare function local:precedes($a as node(), $b as node())
as boolean
{
$a << $b
and
fn:empty($a//node() intersect $b)
};
Similarly, a local:follows
function could be written:
declare function local:follows($a as node(), $b as node())
as boolean
{
$a >> $b
and
fn:empty($b//node() intersect $a)
};
Using the local:precedes
function, we can write a
query that finds instrument
elements between the first
two incisions, excluding from the query result any
instrument
that is a descendant of the first
incision
:
let $proc := //procedure[1]
for $i in $proc//instrument
where local:precedes(($proc//incision)[1], $i)
and local:precedes($i, ($proc//incision)[2])
return $i
The following query reports incisions for which no prior anesthesia
was recorded in the surgical report. Since an anesthesia
is never part of an incision
, we can use
<<
instead of the less-efficient
local:precedes
function:
for $proc in //procedure
where some $i in $proc//incision satisfies
fn:empty($proc//anesthesia[. << $i])
return $proc
In some documents, particular sequences
of elements may indicate a logical hierarchy.
This is most commonly true of HTML. The following
query returns the introduction of an XHTML document,
wrapping it in a div
element. In this example, we
assume that an h2
element containing the text
"Introduction" marks the beginning of the introduction,
and the introduction continues until the next h2
or h1
element, or the end of the document, whichever
comes first.
let $intro := //h2[text()="Introduction"],
$next-h := //(h1|h2)[. >> $intro][1]
return
<div>
{
$intro,
if (fn:empty($next-h))
then //node()[. >> $intro]
else //node()[. >> $intro and . << $next-h]
}
</div>
Note that the above query makes explicit the hierarchy that was implicit in the
original document. In this example, we assume that the h2
element containing the text "Introduction" has no subelements.
Occasionally it is necessary to scan over a hierarchy of elements, applying some transformation at each level of the hierarchy. In XQuery this can be accomplished by defining a recursive function. In this section we will present two examples of such recursive functions.
Suppose that we need to compute a table of contents for a given document by scanning over the document, retaining only elements named section
or title
, and preserving the hierarchical relationships among these elements. For each section
, we retain subelements named section
or title
; but for each title
, we retain the full content of the element. This might be accomplished by the following recursive function:
declare function local:sections-and-titles($n as node()) as node()? { if (fn:local-name($n) = "section") then element { fn:local-name($n) } { for $c in $n/* return local:sections-and-titles($c) } else if (fn:local-name($n) = "title") then $n else ( ) };
The "skeleton" of a given document, containing only its sections and titles, can then be obtained by invoking the local:sections-and-titles
function on the root node of the document, as follows:
local:sections-and-titles(fn:doc("cookbook.xml"))
As another example of a recursive transformation, suppose that we wish to scan over a document, transforming every attribute named color
to an element named color
, and every element named size
to an attribute named size
. This can be accomplished by the following recursive function:
declare function local:swizzle($n as node()) as node() { typeswitch($n) case $a as attribute(color, *) return element color { fn:string($a) } case $es as element(size, *) return attribute size { fn:string($es) } case $e as element() return element { fn:local-name($e) } { for $c in $e/(* | @*) return local:swizzle($c) } case $d as document-node() return document { for $c in $d/* return local:swizzle($c) } default return $n };
The transformation can be applied to a whole document by invoking the local:swizzle
function on the root node of the document, as follows:
local:swizzle(fn:doc("plans.xml"))
Itis sometimesnecessary tosearch through a set of data tofind all thedistinct combinations ofa given listof properties. For example, an input data setmight consist of a large set of order
elements, each of which has the same basic structure, as illustrated by the following example:
<order> <date>2003-10-15</date> <product>Dress Shirt</product> <size>M</size> <color>Blue</color> <supplier>Fashion Trends</supplier> <quantity>50</quantity> </order>
From this data set, a user might wish to find all thedistinct combinations of product
,size
,and color
that occurtogether in an order
.Thefollowing query returns this list, enclosingeach distinct combination in a new element namedoption
:
for $p in fn:distinct-values(//product), $s in fn:distinct-values(//size), $c in fn:distinct-values(//color) order by $p, $s, $c return if (fn:exists(//order[product eq $p and size eq $s and color eq $c])) then <option> <product>{$p}</product> <size>{$s}</size> <color>{$c}</color> </option> else ()
TheXPath 2.0 and XQuery 1.0 Issues List thatrecords pre-Last Call issues can be found athttp://www.w3.org/XML/2003/11/xpath-xquery-issues.
The section entitled "SequenceType Matching" hasbeen rewritten and includesnew material on handling of unrecognized types. An implementation is allowed (butis not required) to providean implementation-dependant mechanism for determining whether an unknown type is compatible with an expected type.
A new concrete type, xdt:untypedAny
,has been introduced and usedas the type annotation of a skip-validated elementnode. A new figure has been added toillustrate the relationships among the generic types such as xdt:untypedAny
and xdt:untypedAtomic
.
The isnot
comparison operator has been removed, andthe sections titled "Node Comparisons" and "Order Comparisons" have been merged.
Somematerialhas been reorganized, notably in the "Types" and "Documents" (formerly"Important Concepts") sections.
Thesection on Optional Features hasbeen reorganized, and twonew optional features have been added: theModule Feature and Static Typing Extensions. Static Typing Extensions permit an implementation to infer moreprecise static types than those specifiedin the Formal Semantics document.
The sequence construction expression Mto N
has been modified toreturn an empty sequence if M> N
.
A VersionDeclaration, ifpresent, must come before a Module Declarationin a Prolog.
Castingan instance of xs:QName
into xs:string
is nolonger supported.As a result, certain operations that dependon casting values to strings (such as validation and serialization) may raise errors.
Typed values of comments and processing instructionsare nowconsidered to have type xs:string
(formerly xdt:untypedAtomic
).
Thedifference between static anddynamic implementation is clarified.If the static typing feature isineffect, type errorsmust be detected during the static analysis phase and serve toinhibit theevaluation phase. If the static typing feature isnot in effect, an implementation may raise type-related warningsduring the staticanalysis phase, but these warnings do not serve to inhibit the evaluation phase.
Several smallgrammar changes have been made.Ina TypeswitchExpr, a CaseClausenowuses ExprSingle rather than Expr.An"@" symbol is nolonger used in a KindTest where the attributeaxis is explicitly identified.See the BNF grammar for details.
Validation of an element node is now defined byserializing the node and parsingthe resulting string rather than bya direct mapping from the Data Model to the XML Infoset.
The name expression of a computed constructor now performs atomization and accepts values oftype xdt:untypedAtomic
.
TheProlog section clarifies that forward references tofunctions (references to functions declared later inthe Prolog) are permitted, but forward referencesto variables (references to variables declared laterin the Prolog) are not permitted.