Please
refer
to
the
errata
for
this
document,
which
may
include
some
normative
corrections.
See
also
translations
.
This
document
is
also
available
in
these
non-normative
formats:
XML
and
Recent
revisions
.
Change
markings
relative
to
first
edition
.
Copyright
© 2007
© 2009
W3C
®
(
MIT
,
ERCIM
,
Keio
),
All
Rights
Reserved.
W3C
liability
,
trademark
and
document
use
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.
XQuery 1.1 is an extended version of the XQuery 1.0 Recommendation published on 23 January 2007. A list of changes made since XQuery 1.0 can be found in K Revision Log . Here are some of the new features in XQuery 1.1:
group
by
clause
in
FLWOR
Expressions
(
3.8.7
Group
By
Clause
).
tumbling
window
and
sliding
window
in
FLWOR
Expressions
(
3.8.4
Window
Clause
).
count
clause
in
FLWOR
Expressions
(
3.8.6
Count
Clause
).
allowing
empty
in
3.8.2
For
Clause
,
for
functionality
similar
to
outer
joins
in
SQL.
try
/
catch
expressions
(
3.13
Try/Catch
Expressions
).
Dynamic function invocation ( 3.1.8 Dynamic Function Invocation ).
Inline functions ( 3.1.7 Inline Functions ).
Private functions ( 4.17 Function Declaration ).
Nondeterministic functions ( 4.17 Function Declaration )
Switch expressions ( 3.11 Switch Expression )
Computed namespace constructors ( 3.7.3.7 Computed Namespace Constructors ).
Output declarations ( 2.2.4 Serialization ).
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
one
document
in
a
set
of
eight
seven
documents
that
have
are
being
progressed
to
Recommendation
together
(XQuery
1.0,
1.1,
XQueryX
1.0,
1.1,
XSLT
2.0,
2.1,
Data
Model,
Model
1.1,
Functions
and
Operators,
Formal
Semantics,
Serialization,
Operators
1.1,
Serialization
1.1,
XPath
2.0).
2.1).
This
is
a
Recommendation
Working
Draft
of
as
described
in
the
W3C.
Process
Document
.
It
has
been
developed
by
the
W3C
XML
Query
Working
Group
,
which
is
part
of
the
XML
Activity
.
The
Working
Group
expects
to
advance
this
specification
to
Recommendation
Status.
This
document
has
A
considerable
number
of
changes
have
been
reviewed
by
W3C
Members,
by
software
developers,
and
by
other
W3C
groups
and
interested
parties,
and
is
endorsed
by
the
Director
as
a
W3C
Recommendation.
It
is
a
stable
made
to
this
document
and
may
be
used
as
reference
material
or
cited
from
another
document.
W3C's
role
in
making
since
publication
of
the
Recommendation
is
previous
Working
Draft.
Among
the
most
notable
of
those
changes
are:
the
addition
of
higher-order
functions
to
draw
attention
the
language;
the
addition
of
private
functions
to
the
specification
and
language;
changes
to
promote
its
widespread
deployment.
This
enhances
the
functionality
context
item
declaration,
the
ability
to
specify
the
types
of
external
variables,
and
interoperability
the
addition
of
a
new
switch
expression
analogous
to
the
Web.
existing
typeswitch
expressions
(but
for
values).
The WG requests priority feedback on the question of whether the grouping variables in the post-grouping tuple should contain the grouping key for a grouping variable in a pre-grouping tuple, which is atomized, rather than the value of the grouping variable in a pre-grouping tuple. See 3.8.7 Group By Clause .
No implementation report currently exists. However, a Test Suite for XQuery 1.1 is under development.
This
document
incorporates
minor
changes
made
against
the
Proposed
Recommendation
previous
publication
of
21
November
2006;
please
see
the
public
disposition
Working
Draft
of
comments
for
details.
03
December
2008.
Changes
to
this
document
since
the
Proposed
Recommendation
previous
publication
of
the
Working
Draft
are
detailed
in
the
J
K
Revision
Log
.
Please
report
errors
in
this
document
using
W3C's
public
Bugzilla
system
(instructions
can
be
found
at
http://www.w3.org/XML/2005/04/qt-bugzilla
).
If
access
to
that
system
is
not
feasible,
you
may
send
your
comments
to
the
W3C
XSLT/XPath/XQuery
public
comments
mailing
list,
public-qt-comments@w3.org
.
It
will
be
very
helpful
if
you
include
the
string
“[
XQuery
]”
“[XQuery11]”
in
the
subject
line
of
your
report,
whether
made
in
Bugzilla
or
in
email.
Each
Please
use
multiple
Bugzilla
entry
and
entries
(or,
if
necessary,
multiple
email
message
should
contain
only
messages)
if
you
have
more
than
one
error
report.
comment
to
make.
Archives
of
the
comments
and
responses
are
available
at
http://lists.w3.org/Archives/Public/public-qt-comments/
.
Publication as a Working Draft does not 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.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .
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
Model
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
Consistency
Constraints
2.3
Error
Handling
2.3.1
Kinds
of
Errors
2.3.2
Identifying
and
Reporting
Errors
2.3.3
Handling
Dynamic
Errors
2.3.4
Errors
and
Optimization
2.4
Concepts
2.4.1
Document
Order
2.4.2
Atomization
2.4.3
Effective
Boolean
Value
2.4.4
Input
Sources
2.4.5
URI
Literals
2.5
Types
2.5.1
Predefined
Schema
Types
2.5.2
Typed
Value
and
String
Value
2.5.3
SequenceType
Syntax
2.5.4
SequenceType
Matching
2.5.4.1
Matching
a
SequenceType
and
a
Value
2.5.4.2
Matching
an
ItemType
and
an
Item
2.5.4.3
Element
Test
2.5.4.4
Schema
Element
Test
2.5.4.5
Attribute
Test
2.5.4.6
Schema
Attribute
Test
2.5.5
SequenceType
Subtype
Relationships
2.5.5.1
The
SequenceType
Subtype
Judgement
2.5.5.2
The
ItemType
Subtype
Judgement
2.6
Comments
3
Expressions
3.1
Primary
Expressions
3.1.1
Literals
3.1.2
Variable
References
3.1.3
Parenthesized
Expressions
3.1.4
Context
Item
Expression
3.1.5
Function
Calls
3.1.5.1
Function
Item
Coercion
3.1.6
Literal
Function
Items
3.1.7
Inline
Functions
3.1.8
Dynamic
Function
Invocation
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
Filter
Expressions
3.3.3
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
Attributes
3.7.1.3
Content
3.7.1.4
Boundary
Whitespace
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
In-scope
Namespaces
of
a
Constructed
Element
3.8
FLWOR
Expressions
3.8.1
Variable
Bindings
3.8.2
For
and
Clause
3.8.3
Let
Clause
3.8.4
Window
Clause
3.8.4.1
Tumbling
Windows
3.8.4.2
Sliding
Windows
3.8.4.3
Effects
of
Window
Clauses
on
the
Tuple
Stream
3.8.2
3.8.5
Where
Clause
3.8.3
3.8.6
Count
Clause
3.8.7
Group
By
Clause
3.8.8
Order
By
and
Return
Clauses
Clause
3.8.4
Example
3.8.9
Return
Clause
3.9
Ordered
and
Unordered
Expressions
3.10
Conditional
Expressions
3.11
Switch
Expression
3.12
Quantified
Expressions
3.12
3.13
Try/Catch
Expressions
3.14
Expressions
on
SequenceTypes
3.12.1
3.14.1
Instance
Of
3.12.2
3.14.2
Typeswitch
3.12.3
3.14.3
Cast
3.12.4
3.14.4
Castable
3.12.5
3.14.5
Constructor
Functions
3.12.6
3.14.6
Treat
3.13
3.15
Validate
Expressions
3.14
3.16
Extension
Expressions
4
Modules
and
Prologs
4.1
Version
Declaration
4.2
Module
Declaration
4.3
Boundary-space
Declaration
4.4
Default
Collation
Declaration
4.5
Base
URI
Declaration
4.6
Construction
Declaration
4.7
Ordering
Mode
Declaration
4.8
Empty
Order
Declaration
4.9
Copy-Namespaces
Declaration
4.10
Decimal-Format
Declaration
4.11
Schema
Import
4.11
4.12
Module
Import
4.12
4.13
Namespace
Declaration
4.13
4.14
Default
Namespace
Declaration
4.14
4.15
Variable
Declaration
4.15
4.16
Context
Item
Declaration
4.17
Function
Declaration
4.16
4.18
Option
Declaration
5
Conformance
5.1
Minimal
Conformance
5.2
Optional
Features
5.2.1
Schema
Import
Feature
5.2.2
Schema
Validation
Feature
5.2.3
Static
Typing
Feature
5.2.3.1
Static
Typing
Extensions
5.2.4
Full
Axis
Feature
5.2.5
Module
Feature
5.2.6
5.2.5
Serialization
Feature
5.3
Data
Model
Conformance
5.4
Syntax
Extensions
A
XQuery
1.1
Grammar
A.1
EBNF
A.1.1
Notation
A.1.2
Extra-grammatical
Constraints
A.1.3
Grammar
Notes
A.2
Lexical
structure
A.2.1
Terminal
Symbols
A.2.2
Terminal
Delimitation
A.2.3
End-of-Line
Handling
A.2.3.1
XML
1.0
End-of-Line
Handling
A.2.3.2
XML
1.1
End-of-Line
Handling
A.2.4
Whitespace
Rules
A.2.4.1
Default
Whitespace
Handling
A.2.4.2
Explicit
Whitespace
Handling
A.3
Reserved
Function
Names
A.4
Precedence
Order
(Non-Normative)
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
Implementation-Defined
Items
E
References
E.1
Normative
References
E.2
Non-normative
References
E.3
Background
Material
F
Error
Conditions
G
The
application/xquery
Media
Type
G.1
Introduction
G.2
Registration
of
MIME
Media
Type
application/xquery
G.2.1
Interoperability
Considerations
G.2.2
Applications
Using
this
Media
Type
G.2.3
File
Extensions
G.2.4
Intended
Usage
G.2.5
Author/Change
Controller
G.3
Encoding
Considerations
G.4
Recognizing
XQuery
Files
G.5
Charset
Default
Rules
G.6
Security
Considerations
H
Glossary
(Non-Normative)
I
Example
Applications
(Non-Normative)
I.1
Joins
I.2
Grouping
I.3
Queries
on
Sequence
I.4
I.3
Recursive
Transformations
I.5
I.4
Selecting
Distinct
Combinations
J
Guidance
for
Handling
of
Modules
(Non-Normative)
J.1
Module
URIs
J.2
Multiple
Modules
with
the
same
Module
URI
J.3
Location
URIs
J.4
Cycles
K
Revision
Log
(Non-Normative)
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
[XQuery
1.1
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
non-XML
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
[XML
Path
Language
(XPath)
Version
1.0]
,
XQL
[XQL]
,
XML-QL
[XML-QL]
,
SQL
[SQL]
,
and
OQL
[ODMG]
.
[
Definition
:
XQuery
1.1
operates
on
the
abstract,
logical
structure
of
an
XML
document,
rather
than
its
surface
syntax.
This
logical
structure,
known
as
the
data
model
,
is
defined
in
[XQuery/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
.]
XQuery
Version
1.0
1.1
is
an
extension
of
XPath
Version
2.0.
Any
2.1.
In
general,
any
expression
that
is
syntactically
valid
and
executes
successfully
in
both
XPath
2.0
2.1
and
XQuery
1.0
1.1
will
return
the
same
result
in
both
languages.
Since
There
are
a
few
exceptions
to
this
rule:
Because
XQuery
expands
predefined
entity
references
and
character
references
and
XPath
does
not,
expressions
containing
these
produce
different
results
in
the
two
languages.
For
instance,
the
value
of
the
string
literal
"&"
is
&
in
XQuery,
and
&
in
XPath.
(XPath
is
often
embedded
in
other
languages,
which
may
expand
predefined
entity
references
or
character
references
before
the
XPath
expression
is
evaluated.)
If XPath 1.0 compatibility mode is enabled, XPath behaves differently from XQuery in a number of ways, which are discussed in [XML Path Language (XPath) 2.1] .
Because 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 1.1 also depends on and is closely related to the following specifications:
[XQuery/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
defines
the
data
model
that
underlies
all
XQuery
1.1
expressions.
[XQuery
1.0
and
XPath
2.0
Formal
Semantics]
defines
the
static
semantics
of
XQuery
and
also
contains
a
formal
but
non-normative
description
of
the
dynamic
semantics
that
may
be
useful
for
implementors
and
others
who
require
a
formal
definition.
The
type
system
of
XQuery
1.1
is
based
on
[XML
Schema]
.
The
built-in
function
library
and
the
operators
supported
by
XQuery
1.1
are
defined
in
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
.
One
requirement
in
[XML
Query
1.0
[XQuery
1.1
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]
1.1]
.
[ Definition : An XQuery 1.1 Processor processes a query according to the XQuery 1.1 specification.]
[ Definition : An XQuery 1.0 Processor processes a query according to the XQuery 1.0 specification.]
This
document
specifies
a
grammar
for
XQuery,
XQuery
1.1,
using
the
same
basic
EBNF
notation
used
in
[XML
1.0]
.
Unless
otherwise
noted
(see
A.2
Lexical
structure
),
whitespace
is
not
significant
in
queries
.
Grammar
productions
are
introduced
together
with
the
features
that
they
describe,
and
a
complete
grammar
is
also
presented
in
the
appendix
[
A
XQuery
1.1
Grammar
].
The
appendix
is
the
normative
version.
In the grammar productions in this document, named symbols are underlined and literal text is enclosed in double quotes. For example, the following production describes the syntax of a function call:
|
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.
This document normatively defines the static and dynamic semantics of XQuery 1.1. In this document, examples and material labeled as "Note" are provided for explanatory purposes and are not normative.
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.]
The basic building block of XQuery 1.1 is the expression , which is a string of [Unicode] characters (the version of Unicode to be used is implementation-defined .) 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. XQuery 1.1 allows expressions to be nested with full generality. (However, unlike a pure functional language, it does not allow variable substitution if the variable declaration contains construction of new nodes.)
Note:
This specification contains no assumptions or requirements regarding the character set encoding of strings of [Unicode] characters.
Like XML, XQuery 1.1 is a case-sensitive language. Keywords in XQuery 1.1 use lower-case characters and are not reserved—that is, names in XQuery 1.1 expressions are allowed to be the same as language keywords, except for certain unprefixed function-names listed in A.3 Reserved Function Names .
[
Definition
:
In
the
data
model
,
a
value
is
always
a
sequence
.]
[
Definition
:
A
sequence
is
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
atomic
type
,
as
defined
in
[XML
Schema]
.]
[
Definition
:
A
node
is
an
instance
of
one
of
the
node
kinds
defined
in
[XQuery/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
.]
Each
node
has
a
unique
node
identity
,
a
typed
value
,
and
a
string
value
.
In
addition,
some
nodes
have
a
name
.
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
:
In
certain
situations
a
value
is
said
to
be
undefined
(for
example,
the
value
of
the
context
item,
or
the
typed
value
of
an
element
node).
This
term
indicates
that
the
property
in
question
has
no
value
and
that
any
attempt
to
use
its
value
results
in
an
error.]
[ Definition : A sequence containing exactly one item is called a singleton .] 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 .]
[ Definition : The term XDM instance is used, synonymously with the term value , to denote an unconstrained sequence of nodes and/or atomic values in the data model .]
Names
in
XQuery
1.1
are
called
QNames
,
and
conform
to
the
syntax
in
[XML
Names]
.
[
Definition
:
Lexically,
a
QName
consists
of
an
optional
namespace
prefix
and
a
local
name.
If
the
namespace
prefix
is
present,
it
is
separated
from
the
local
name
by
a
colon.]
A
lexical
QName
can
be
converted
into
an
expanded
QName
by
resolving
its
namespace
prefix
to
a
namespace
URI,
using
the
statically
known
namespaces
[
err:XPST0081
].
[
Definition
:
An
expanded
QName
consists
of
an
optional
namespace
URI
and
a
local
name.
An
expanded
QName
also
retains
its
original
namespace
prefix
(if
any),
to
facilitate
casting
the
expanded
QName
into
a
string.]
The
namespace
URI
value
is
whitespace
normalized
according
to
the
rules
for
the
xs:anyURI
type
in
[XML
Schema]
.
Two
expanded
QNames
are
equal
if
their
namespace
URIs
are
equal
and
their
local
names
are
equal
(even
if
their
namespace
prefixes
are
not
equal).
Namespace
URIs
and
local
names
are
compared
on
a
codepoint
basis,
without
further
normalization.
Certain namespace prefixes are predeclared by XQuery and bound to fixed namespace URIs. These namespace 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/2005/xpath-functions
local
=
http://www.w3.org/2005/xquery-local-functions
(see
4.15
4.17
Function
Declaration
.)
output
=
http://www.w3.org/2009/xquery-serialization
(see
2.2.4
Serialization
.)
In
addition
to
the
prefixes
in
the
above
list,
this
document
uses
the
prefix
err
to
represent
the
namespace
URI
http://www.w3.org/2005/xqt-errors
(see
2.3.2
Identifying
and
Reporting
Errors
).
This
namespace
prefix
is
not
predeclared
and
its
use
in
this
document
is
not
normative.
Element nodes have a property called in-scope namespaces . [ Definition : The in-scope namespaces property of an element node is a set of namespace bindings , each of which associates a namespace prefix with a URI, thus defining the set of namespace prefixes that are available for interpreting QNames within the scope of the element. For a given element, one namespace binding may have an empty prefix; the URI of this namespace binding is the default namespace within the scope of the element.]
Note:
In
[XPath
[XML
Path
Language
(XPath)
Version
1.0]
,
the
in-scope
namespaces
of
an
element
node
are
represented
by
a
collection
of
namespace
nodes
arranged
on
a
namespace
axis
,
which
is
optional
and
deprecated
in
[XPath
2.0]
[XML
Path
Language
(XPath)
2.1]
.
XQuery
does
not
support
the
namespace
axis
and
does
not
represent
namespace
bindings
in
the
form
of
nodes.
However,
where
other
specifications
such
as
[XSLT
2.0
and
XQuery
1.0
Serialization]
Serialization
1.1]
refer
to
namespace
nodes,
these
nodes
may
be
synthesized
from
the
in-scope
namespaces
of
an
element
node
by
interpreting
each
namespace
binding
as
a
namespace
node.
[ Definition : Within this specification, the term URI refers to a Universal Resource Identifier as defined in [RFC3986] and extended in [RFC3987] with the new name IRI .] The term URI has been retained in preference to IRI to avoid introducing new names for concepts such as "Base URI" that are defined or referenced across the whole family of XML specifications.
[ 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 dynamic context .
[ 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 . If analysis of an expression relies on some component of the static context that has not been assigned a value, a static error is raised [ err:XPST0001 ].
The individual components of the static context are summarized below. Rules governing the scope and initialization of these components can be found in C.1 Static Context Components .
[
Definition
:
XPath
1.0
compatibility
mode.
This
component
must
be
set
by
all
host
languages
that
include
XPath
2.0
2.1
as
a
subset,
indicating
whether
rules
for
compatibility
with
XPath
1.0
are
in
effect.
XQuery
sets
the
value
of
this
component
to
false
.
]
[
Definition
:
Statically
known
namespaces.
This
is
a
set
of
(prefix,
URI)
pairs
that
define
all
the
namespaces
that
are
known
during
static
processing
of
a
given
expression.]
The
URI
value
is
whitespace
normalized
according
to
the
rules
for
the
xs:anyURI
type
in
[XML
Schema]
.
Note
the
difference
between
in-scope
namespaces
,
which
is
a
dynamic
property
of
an
element
node,
and
statically
known
namespaces
,
which
is
a
static
property
of
an
expression.
Some namespaces are predefined; additional namespaces can be added to the statically known namespaces by namespace declarations in a Prolog and by namespace declaration attributes in direct element constructors .
[
Definition
:
Default
element/type
namespace.
This
is
a
namespace
URI
or
"none".
The
namespace
URI,
if
present,
is
used
for
any
unprefixed
QName
appearing
in
a
position
where
an
element
or
type
name
is
expected.]
The
URI
value
is
whitespace
normalized
according
to
the
rules
for
the
xs:anyURI
type
in
[XML
Schema]
.
[
Definition
:
Default
function
namespace.
This
is
a
namespace
URI
or
"none".
The
namespace
URI,
if
present,
is
used
for
any
unprefixed
QName
appearing
in
a
position
where
a
function
name
is
expected.]
The
URI
value
is
whitespace
normalized
according
to
the
rules
for
the
xs:anyURI
type
in
[XML
Schema]
.
[ Definition : In-scope schema definitions. This is a generic term for all the element declarations, attribute declarations, and schema type definitions that are in scope during processing of an expression.] It includes the following three parts:
[ Definition : In-scope schema types. Each schema type definition is identified either by an expanded QName (for a named type ) or by an implementation-dependent type identifier (for an anonymous type ). The in-scope schema types include the predefined schema types described in 2.5.1 Predefined Schema Types . If the Schema Import Feature is supported, in-scope schema types also include all type definitions found in imported schemas. ]
[ Definition : In-scope element declarations. Each element declaration is identified either by an expanded QName (for a top-level element declaration) or by an implementation-dependent element identifier (for a local element declaration). 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 element's substitution group affiliation.
[ Definition : Substitution groups are defined in [XML Schema] Part 1, Section 2.2.2.2. Informally, the substitution group headed by a given element (called the head element ) consists of the set of elements that can be substituted for the head element without affecting the outcome of schema validation.]
[ Definition : In-scope attribute declarations. Each attribute declaration is identified either by an expanded 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 (expanded QName, type) pairs. It defines the set of variables that are available for reference within an expression. The expanded QName is the name of the variable, and the type is the static type of the variable.]
Variable
declarations
in
a
Prolog
are
added
to
in-scope
variables
.
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
of
the
function
parameters
.
The
static
type
of
a
variable
may
be
either
be
declared
in
a
query
or
(if
the
Static
Typing
Feature
is
enabled)
inferred
by
static
type
inference
rules
as
described
discussed
in
[XQuery
1.0
and
XPath
2.0
Formal
Semantics]
5.2.3
Static
Typing
Feature
.
[ Definition : Context item static type. This component defines the static type of the context item within the scope of a given expression.]
[ Definition : Function signatures. This component defines 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 addition to the name and arity, each function signature specifies the static types of the function parameters and result.
The
function
signatures
include
the
signatures
of
constructor
functions
,
which
are
discussed
in
3.12.5
3.14.5
Constructor
Functions
.
[
Definition
:
Statically
known
collations.
This
is
an
implementation-defined
set
of
(URI,
collation)
pairs.
It
defines
the
names
of
the
collations
that
are
available
for
use
in
processing
queries
and
expressions.]
[
Definition
:
A
collation
is
a
specification
of
the
manner
in
which
strings
and
URIs
are
compared
and,
by
extension,
ordered.
For
a
more
complete
definition
of
collation,
see
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
.]
[
Definition
:
Default
collation.
This
identifies
one
of
the
collations
in
statically
known
collations
as
the
collation
to
be
used
by
functions
and
operators
for
comparing
and
ordering
values
of
type
xs:string
and
xs:anyURI
(and
types
derived
from
them)
when
no
explicit
collation
is
specified.]
[
Definition
:
Construction
mode.
The
construction
mode
governs
the
behavior
of
element
and
document
node
constructors.
If
construction
mode
is
preserve
,
the
type
of
a
constructed
element
node
is
xs:anyType
,
and
all
attribute
and
element
nodes
copied
during
node
construction
retain
their
original
types.
If
construction
mode
is
strip
,
the
type
of
a
constructed
element
node
is
xs:untyped
;
all
element
nodes
copied
during
node
construction
receive
the
type
xs:untyped
,
and
all
attribute
nodes
copied
during
node
construction
receive
the
type
xs:untypedAtomic
.]
[
Definition
:
Ordering
mode.
Ordering
mode,
which
has
the
value
ordered
or
unordered
,
affects
the
ordering
of
the
result
sequence
returned
by
certain
path
expressions
,
FLWOR
expressions,
and
union
,
intersect
,
and
except
expressions,
and
FLWOR
expressions
that
have
no
order
by
clause.]
expressions.]
Details
are
provided
in
the
descriptions
of
these
expressions.
[
Definition
:
Default
order
for
empty
sequences.
This
component
controls
the
processing
of
empty
sequences
and
NaN
values
as
ordering
keys
in
an
order
by
clause
in
a
FLWOR
expression,
as
described
in
3.8.3
3.8.8
Order
By
and
Return
Clauses
Clause
.]
Its
value
may
be
greatest
or
least
.
[
Definition
:
Boundary-space
policy.
This
component
controls
the
processing
of
boundary
whitespace
by
direct
element
constructors
,
as
described
in
3.7.1.4
Boundary
Whitespace
.]
Its
value
may
be
preserve
or
strip
.
[
Definition
:
Copy-namespaces
mode.
This
component
controls
the
namespace
bindings
that
are
assigned
when
an
existing
element
node
is
copied
by
an
element
constructor,
as
described
in
3.7.1
Direct
Element
Constructors
.
Its
value
consists
of
two
parts:
preserve
or
no-preserve
,
and
inherit
or
no-inherit
.]
[
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.)]
The
URI
value
is
whitespace
normalized
according
to
the
rules
for
the
xs:anyURI
type
in
[XML
Schema]
.
[
Definition
:
Statically
known
documents.
This
is
a
mapping
from
strings
onto
types.
The
string
represents
the
absolute
URI
of
a
resource
that
is
potentially
available
using
the
fn:doc
function.
The
type
is
the
static
type
of
a
call
to
fn:doc
with
the
given
URI
as
its
literal
argument.
]
If
the
argument
to
fn:doc
is
a
string
literal
that
is
not
present
in
statically
known
documents
,
then
the
static
type
of
fn:doc
is
document-node()?
.
Note:
The
purpose
of
the
statically
known
documents
is
to
provide
static
type
information,
not
to
determine
which
documents
are
available.
A
URI
need
not
be
found
in
the
statically
known
documents
to
be
accessed
using
fn:doc
.
[
Definition
:
Statically
known
collections.
This
is
a
mapping
from
strings
onto
types.
The
string
represents
the
absolute
URI
of
a
resource
that
is
potentially
available
using
the
fn:collection
function.
The
type
is
the
type
of
the
sequence
of
nodes
that
would
result
from
calling
the
fn:collection
function
with
this
URI
as
its
argument.]
If
the
argument
to
fn:collection
is
a
string
literal
that
is
not
present
in
statically
known
collections
,
then
the
static
type
of
fn:collection
is
node()*
.
Note:
The
purpose
of
the
statically
known
collections
is
to
provide
static
type
information,
not
to
determine
which
collections
are
available.
A
URI
need
not
be
found
in
the
statically
known
collections
to
be
accessed
using
fn:collection
.
[
Definition
:
Statically
known
default
collection
type.
This
is
the
type
of
the
sequence
of
nodes
that
would
result
from
calling
the
fn:collection
function
with
no
arguments.]
Unless
initialized
to
some
other
value
by
an
implementation,
the
value
of
statically
known
default
collection
type
is
node()*
.
[
Definition
:
Statically
known
decimal
formats.
This
is
the
set
of
known
decimal
formats.
Each
format
is
used
for
serializing
decimal
numbers
using
fn:format-number()
.]
Each
format
is
identified
by
a
QName,
except
for
the
default
format,
which
has
no
visible
name.
Each
format
contains
the
properties
described
in
the
following
paragraphs.
The
following
properties
control
the
interpretation
of
characters
in
the
picture
string
supplied
to
the
fn:format-number
function,
and
also
specify
characters
that
may
appear
in
the
result
of
formatting
the
number.
In
each
case
the
value
must
be
a
single
character
(see
[
err:XQST0100
]):
[ Definition : decimal-separator specifies the character used for the decimal-separator-sign; the default value is the period character (.)]
[ Definition : grouping-separator specifies the character used for the grouping-sign, which is typically used as a thousands separator; the default value is the comma character (,)]
[ Definition : percent-sign specifies the character used for the percent-sign; the default value is the percent character (%)]
[ Definition : per-mille-sign specifies the character used for the per-mille-sign; the default value is the Unicode per-mille character (#x2030)]
[ Definition : zero-digit specifies the character used for the digit-zero-sign; the default value is the digit zero (0). This character must be a digit (category Nd in the Unicode property database), and it must have the numeric value zero. This attribute implicitly defines the Unicode character that is used to represent each of the values 0 to 9 in the final result string: Unicode is organized so that each set of decimal digits forms a contiguous block of characters in numerical sequence.]
The following attributes control the interpretation of characters in the picture string supplied to the format-number function. In each case the value must be a single character (see [ err:XQST0100 ]).
[ Definition : digit-sign specifies the character used for the digit-sign in the picture string; the default value is the number sign character (#)]
[ Definition : pattern-separator-sign specifies the character used for the pattern-separator-sign, which separates positive and negative sub-pictures in a picture string; the default value is the semi-colon character (;)]
The following attributes specify characters or strings that may appear in the result of formatting the number:
[ Definition : infinity specifies the string used for the infinity-symbol; the default value is the string Infinity]
[ Definition : NaN specifies the string used for the NaN-symbol, which is used to represent the value NaN (not-a-number); the default value is the string NaN]
[ Definition : minus-sign specifies the character used for the minus-symbol; the default value is the hyphen-minus character (-, #x2D). The value must be a single character.]
[ Definition : The dynamic context of an expression is defined as information that is available at the time the expression is evaluated.] If evaluation of an expression relies on some part of the dynamic context that has not been assigned a value, a dynamic error is raised [ err:XPDY0002 ].
The individual components of the dynamic context are summarized below. Further rules governing the semantics of these components can be 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 dynamic context (context item, context position, and context size) are called the focus of the expression. ] The focus enables the processor to keep track of which items are being processed by the expression.
Certain
language
constructs,
notably
the
path
expression
E1/E2
and
the
predicate
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.
An
item
is
either
an
atomic
value
or
a
node.][
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
an
expression
consisting
of
a
single
dot
(
.
).
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.]
It
changes
whenever
the
context
item
changes.
When
the
focus
is
defined,
the
value
of
the
context
position
is
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.]
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 : Variable values . This is a set of (expanded QName, value) pairs. It contains the same expanded QNames as the in-scope variables in the static context for the expression. The expanded QName is the name of the variable and the value is the dynamic value of the variable, which includes its dynamic type .]
[ Definition : Function implementations . Each function in function signatures has a function implementation that enables the function to map instances of its parameter types into an instance of its result type. For a user-defined function , the function implementation is an XQuery expression. For a built-in function or external function , the function implementation is implementation-dependent . ]
[
Definition
:
Current
dateTime.
This
information
represents
an
implementation-dependent
point
in
time
during
the
processing
of
a
query
,
and
includes
an
explicit
timezone.
It
can
be
retrieved
by
the
fn:current-dateTime
function.
If
invoked
multiple
times
during
the
execution
of
a
query
,
this
function
always
returns
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
arithmetic
operation.
The
implicit
timezone
is
an
implementation-defined
value
of
type
xs:dayTimeDuration
.
See
[XML
Schema]
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
of
a
resource.
The
document
node
is
the
root
of
a
tree
that
represents
that
resource
using
the
data
model
.
The
document
node
is
returned
by
the
fn:doc
function
when
applied
to
that
URI.]
The
set
of
available
documents
is
not
limited
to
the
set
of
statically
known
documents
,
and
it
may
be
empty.
If
there
are
one
or
more
URIs
in
available
documents
that
map
to
a
document
node
D
,
then
the
document-uri
property
of
D
must
either
be
absent,
or
must
be
one
of
these
URIs.
Note:
This
means
that
given
a
document
node
$N
,
the
result
of
fn:doc(fn:document-uri($N))
is
$N
will
always
be
True,
unless
fn:document-uri($N)
is
an
empty
sequence.
[
Definition
:
Available
collections.
This
is
a
mapping
of
strings
onto
sequences
of
nodes.
The
string
represents
the
absolute
URI
of
a
resource.
The
sequence
of
nodes
represents
the
result
of
the
fn:collection
function
when
that
URI
is
supplied
as
the
argument.
]
The
set
of
available
collections
is
not
limited
to
the
set
of
statically
known
collections
,
and
it
may
be
empty.
For
every
document
node
D
that
is
in
the
target
of
a
mapping
in
available
collections
,
or
that
is
the
root
of
a
tree
containing
such
a
node,
the
document-uri
property
of
D
must
either
be
absent,
or
must
be
a
URI
U
such
that
available
documents
contains
a
mapping
from
U
to
D
."
Note:
This
means
that
for
any
document
node
$N
retrieved
using
the
fn:collection
function,
either
directly
or
by
navigating
to
the
root
of
a
node
that
was
returned,
the
result
of
fn:doc(fn:document-uri($N))
is
$N
will
always
be
True,
unless
fn:document-uri($N)
is
an
empty
sequence.
This
implies
a
requirement
for
the
fn:doc
and
fn:collection
functions
to
be
consistent
in
their
effect.
If
the
implementation
uses
catalogs
or
user-supplied
URI
resolvers
to
dereference
URIs
supplied
to
the
fn:doc
function,
the
implementation
of
the
fn:collection
function
must
take
these
mechanisms
into
account.
For
example,
an
implementation
might
achieve
this
by
mapping
the
collection
URI
to
a
set
of
document
URIs,
which
are
then
resolved
using
the
same
catalog
or
URI
resolver
that
is
used
by
the
fn:doc
function.
[
Definition
:
Default
collection.
This
is
the
sequence
of
nodes
that
would
result
from
calling
the
fn:collection
function
with
no
arguments.]
The
value
of
default
collection
may
be
initialized
by
the
implementation.
XQuery 1.1 is defined in terms of the data model and the expression context .
Figure 1: Processing Model Overview
Figure
1
provides
a
schematic
overview
of
the
processing
steps
that
are
discussed
in
detail
below.
Some
of
these
steps
are
completely
outside
the
domain
of
XQuery;
XQuery
1.1;
in
Figure
1,
these
are
depicted
outside
the
line
that
represents
the
boundaries
of
the
language,
an
area
labeled
external
processing
.
The
external
processing
domain
includes
generation
of
an
XDM
instance
that
represents
the
data
to
be
queried
(see
2.2.1
Data
Model
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
includes
the
static
analysis
and
dynamic
evaluation
phases
(see
2.2.3
Expression
Processing
).
Consistency
constraints
on
the
query
processing
domain
are
defined
in
2.2.5
Consistency
Constraints
.
Before
a
query
can
be
processed,
its
input
data
must
be
represented
as
an
XDM
instance
.
This
process
occurs
outside
the
domain
of
XQuery,
XQuery
1.1,
which
is
why
Figure
1
represents
it
in
the
external
processing
domain.
Here
are
some
steps
by
which
an
XML
document
might
be
converted
to
an
XDM
instance
:
A document may be parsed using an XML parser that generates an XML Information Set (see [XML Infoset] ). The parsed document may then be validated against one or more schemas. This process, which is described in [XML Schema] , results in an abstract information structure called the Post-Schema Validation Infoset (PSVI). If a document has no associated schema, its Information Set is preserved. (See DM1 in Fig. 1.)
The
Information
Set
or
PSVI
may
be
transformed
into
an
XDM
instance
by
a
process
described
in
[XQuery/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
.
(See
DM2
in
Fig.
1.)
The above steps provide an example of how an XDM instance might be constructed. An XDM instance might also be synthesized directly from a relational database, or constructed in some other way (see DM3 in Fig. 1.) XQuery 1.1 is defined in terms of the data model , but it does not place any constraints on how XDM instances are constructed.
[
Definition
:
Each
element
node
and
attribute
node
in
an
XDM
instance
has
a
type
annotation
(referred
to
in
[XQuery/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
as
its
type-name
property.)
The
type
annotation
of
a
node
is
a
schema
type
that
describes
the
relationship
between
the
string
value
of
the
node
and
its
typed
value
.]
If
the
XDM
instance
was
derived
from
a
validated
XML
document
as
described
in
Section
3.3
Construction
from
a
PSVI
DM
,
the
type
annotations
of
the
element
and
attribute
nodes
are
derived
from
schema
validation.
XQuery
1.1
does
not
provide
a
way
to
directly
access
the
type
annotation
of
an
element
or
attribute
node.
The
value
of
an
attribute
is
represented
directly
within
the
attribute
node.
An
attribute
node
whose
type
is
unknown
(such
as
might
occur
in
a
schemaless
document)
is
given
the
type
annotation
xs:untypedAtomic
.
The
value
of
an
element
is
represented
by
the
children
of
the
element
node,
which
may
include
text
nodes
and
other
element
nodes.
The
type
annotation
of
an
element
node
indicates
how
the
values
in
its
child
text
nodes
are
to
be
interpreted.
An
element
that
has
not
been
validated
(such
as
might
occur
in
a
schemaless
document)
is
annotated
with
the
schema
type
xs:untyped
.
An
element
that
has
been
validated
and
found
to
be
partially
valid
is
annotated
with
the
schema
type
xs:anyType
.
If
an
element
node
is
annotated
as
xs:untyped
,
all
its
descendant
element
nodes
are
also
annotated
as
xs:untyped
.
However,
if
an
element
node
is
annotated
as
xs:anyType
,
some
of
its
descendant
element
nodes
may
have
a
more
specific
type
annotation
.
The
in-scope
schema
definitions
in
the
static
context
may
be
extracted
from
actual
XML
schemas
as
described
in
[XQuery
1.0
and
XPath
2.0
Formal
Semantics]
(see
step
SI1
in
Figure
1)
or
may
be
generated
by
some
other
mechanism
(see
step
SI2
in
Figure
1).
In
either
case,
the
result
must
satisfy
the
consistency
constraints
defined
in
2.2.5
Consistency
Constraints
.
XQuery 1.1 defines two phases of processing called the static analysis phase and the dynamic evaluation phase (see Fig. 1). During the static analysis phase, static errors , dynamic errors , or type errors may be raised. During the dynamic evaluation phase, only dynamic errors or type errors may be raised. These kinds of errors are defined in 2.3.1 Kinds of Errors .
Within each phase, an implementation is free to use any strategy or algorithm whose result conforms to the specifications in this document.
[ Definition : The static analysis phase depends on the expression itself and on the static context . The static analysis phase does not depend on input data (other than schemas).]
During the static analysis phase, the query is parsed into an internal representation called the operation tree (step SQ1 in Figure 1). A parse error is raised as a static error [ err:XPST0003 ]. The static context is initialized by the implementation (step SQ2). The static context is then changed and augmented based on information in the prolog (step SQ3). If the Schema Import Feature is supported, the in-scope schema definitions are populated with information from imported schemas. If the Module Feature is supported, the static context is extended with function declarations and variable declarations from imported modules. The static context is used to resolve schema type names, function names, namespace prefixes, and variable names (step SQ4). If a name of one of these kinds in the operation tree is not found in the static context , a static error ([ err:XPST0008 ] or [ err:XPST0017 ]) is raised (however, see exceptions to this rule in 2.5.4.3 Element Test and 2.5.4.5 Attribute Test .)
The
operation
tree
is
then
normalized
by
making
explicit
the
implicit
operations
such
as
atomization
and
extraction
of
Effective
Boolean
Values
(step
SQ5).
The
normalization
process
is
described
in
[XQuery
1.0
and
XPath
2.0
Formal
Semantics]
.
Each
expression
During
the
static
analysis
phase
,
an
XQuery
processor
may
perform
type
analysis.
The
effect
of
type
analysis
is
then
assigned
to
assign
a
static
type
(step
SQ6).
to
each
expression
in
the
operation
tree.
[
Definition
:
The
static
type
of
an
expression
is
a
the
best
inference
that
the
processor
is
able
to
make
statically
about
the
type
such
that,
when
of
the
result
of
the
expression.]
This
specification
does
not
define
the
rules
for
type
analysis
nor
the
static
types
that
are
assigned
to
particular
expressions:
the
only
constraint
is
that
the
inferred
type
must
match
all
possible
values
that
the
expression
is
evaluated,
capable
of
returning.
Examples of inferred static types might be:
For
the
resulting
value
will
always
conform
to
expression
concat(a,b)
the
inferred
static
type.]
If
type
is
xs:string
For
the
Static
Typing
Feature
expression
$a
=
$v
the
inferred
static
type
is
supported,
xs:boolean
For
the
expression
$s[exp]
the
inferred
static
types
type
has
the
same
item
type
as
the
static
type
of
various
expressions
are
$s
,
but
a
cardinality
that
allows
the
empty
sequence
even
if
the
static
type
of
$s
does
not
allow
an
empty
sequence.
The
inferred
according
to
static
type
of
the
expression
data($x)
(whether
written
explicitly
or
inserted
into
the
operation
tree
in
places
where
atomization
is
implicit)
depends
on
the
inferred
static
type
of
$x
:
for
example,
if
$x
has
type
element(*,
xs:integer)
then
data($x)
has
static
type
xs:integer
.
In
XQuery
1.0,
rules
described
for
static
type
inferencing
were
published
normatively
in
[XQuery
1.0
and
XPath
2.0
Formal
Semantics]
.
If
the
Static
Typing
Feature
is
not
supported,
,
but
implementations
were
allowed
to
refine
these
rules
to
infer
a
more
precise
type
where
possible.
With
XQuery
1.1,
the
static
types
that
are
assigned
rules
are
implementation-dependent
.
entirely
implementation-defined.
During
Every
kind
of
expression
also
imposes
requirements
on
the
static
analysis
phase
,
if
type
of
its
operands.
For
example,
with
the
expression
substring($a,
$b,
$c)
,
$a
must
be
of
type
xs:string
(or
something
that
can
be
converted
to
xs:string
by
the
function
calling
rules),
while
$b
and
$c
must
be
of
type
xs:double
.
If
the
Static
Typing
Feature
is
in
effect
and
effect,
an
operand
XQuery
processor
must
signal
a
type
error
during
static
analysis
if
the
inferred
static
type
of
an
expression
is
found
to
have
a
static
not
subsumed
by
the
required
type
that
of
the
context
where
the
expression
is
not
appropriate
for
that
operand,
used.
For
example,
the
call
of
substring
above
would
cause
a
type
error
is
raised
[
err:XPTY0004
].
If
static
type
checking
raises
no
errors
and
assigns
a
if
the
inferred
static
type
T
to
an
expression,
then
execution
of
the
expression
on
valid
input
data
$a
is
guaranteed
either
to
produce
xs:integer
;
equally,
a
value
of
type
T
or
to
raise
a
dynamic
error
.
would
be
reported
during
static
analysis
if
the
inferred
static
type
is
xs:anyAtomicType
.
The
purpose
of
If
the
Static
Typing
Feature
is
to
provide
early
detection
of
not
in
effect,
a
processor
may
signal
a
type
errors
and
to
infer
error
during
static
analysis
only
if
the
inferred
static
type
information
that
of
an
expression
has
no
overlap
(intersection)
with
the
required
type:
so
for
the
first
argument
of
substring,
the
processor
may
be
useful
report
an
error
if
the
inferred
type
is
xs:integer
,
but
not
if
it
is
xs:anyAtomicType
.
Alternatively,
if
the
Static
Typing
Feature
is
not
in
optimizing
effect,
the
processor
may
defer
all
type
checking
until
the
dynamic
evaluation
of
an
expression.
phase.
[ Definition : The dynamic evaluation phase is the phase during which the value of an expression is computed.] It occurs after completion of the static analysis phase .
The dynamic evaluation phase can occur only if no errors were detected during the static analysis phase . If the Static Typing Feature is in effect, all type errors are detected during static analysis and serve to inhibit the dynamic evaluation phase.
The dynamic evaluation phase depends on the operation tree of the expression being evaluated (step DQ1), on the input data (step DQ4), and on the dynamic context (step DQ5), which in turn draws information from the external environment (step DQ3) and the static context (step DQ2). The dynamic evaluation phase may create new data-model values (step DQ4) and it may extend the dynamic context (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
more
specific
than
the
static
type
of
the
expression
that
computed
it
(for
example,
the
static
type
of
an
expression
might
be
xs:integer*
,
denoting
a
sequence
of
zero
or
more
integers,
but
at
evaluation
time
its
value
may
have
the
dynamic
type
xs:integer
,
denoting
exactly
one
integer.)]
If an operand of an expression is found to have a dynamic type that is not appropriate for that operand, a type error is raised [ err:XPTY0004 ].
Even
though
static
typing
can
catch
many
type
errors
before
an
expression
is
executed,
it
is
possible
for
an
expression
to
raise
an
error
during
evaluation
that
was
not
detected
by
static
analysis.
For
example,
an
expression
may
contain
a
cast
of
a
string
into
an
integer,
which
is
statically
valid.
However,
if
the
actual
value
of
the
string
at
run
time
cannot
be
cast
into
an
integer,
a
dynamic
error
will
result.
Similarly,
an
expression
may
apply
an
arithmetic
operator
to
a
value
whose
static
type
is
xs:untypedAtomic
.
This
is
not
a
static
error
,
but
at
run
time,
if
the
value
cannot
be
successfully
cast
to
a
numeric
type,
a
dynamic
error
will
be
raised.
When the Static Typing Feature is in effect, it is also possible for static analysis of an expression to raise a type error , even though execution of the expression on certain inputs would be successful. For example, an expression might contain a function that requires an element as its parameter, and the static analysis phase might infer the static type of the function parameter to be an optional element. This case is treated as a type error and inhibits evaluation, even though the function call would have been successful for input data in which the optional element is present.
[
Definition
:
Serialization
is
the
process
of
converting
an
XDM
instance
into
a
sequence
of
octets
(step
DM4
in
Figure
1.)
]
The
general
framework
for
serialization
is
described
in
[XSLT
2.0
and
XQuery
1.0
Serialization]
Serialization
1.1]
.
An XQuery implementation is not required to provide a serialization interface. For example, an implementation may only provide a DOM interface (see [Document Object Model] ) or an interface based on an event stream. In these cases, serialization would be outside of the scope of this specification.
[XSLT
2.0
and
XQuery
1.0
Serialization]
Serialization
1.1]
defines
a
set
of
serialization
parameters
that
govern
the
serialization
process.
If
an
XQuery
implementation
provides
a
serialization
interface,
it
may
support
(and
may
expose
to
users)
any
of
the
serialization
parameters
listed
(with
default
values)
in
C.3
Serialization
Parameters
.
[
Definition
:
An
output
declaration
is
an
option
declaration
in
the
predeclared
namespace
associated
with
the
output
prefix;
it
is
used
to
declare
an
output
parameter
for
serializing
the
output
of
the
query.]
When
the
application
requests
serialization
of
the
output,
the
processor
may
use
these
parameters
to
control
the
way
in
which
the
serialization
takes
place.
Processors
may
also
allow
external
mechanisms
for
specifying
serialization
parameters,
which
may
or
may
not
override
serialization
parameters
specified
in
the
query
prolog.
declare option output:method "xml"; declare option output:encoding "iso-8859-1"; declare option output:indent "yes";
An
output
declaration
may
appear
only
in
a
main
module;
it
is
a
static
error
[
err:XQST0108
]
if
an
output
declaration
appears
in
a
library
module
.
It
is
a
static
error
[
err:XQST0110
]
if
the
same
serialization
parameter
is
declared
more
than
once.
It
is
a
static
error
[
err:XQST0109
]
if
the
local
name
of
an
output
declaration
in
the
http://www.w3.org/2009/xquery-serialization
namespace
is
not
one
of
the
serialization
parameter
names
listed
in
C.3
Serialization
Parameters
.
The
default
value
for
the
method
parameter
is
"xml".
An
XQuery
implementation
may
define
additional
implementation-defined
serialization
parameters
in
its
own
namespaces.
A
serialization
parameter
that
provides
is
not
applicable
to
the
chosen
output
method
must
be
ignored,
except
that
if
its
value
is
not
a
valid
value
for
that
parameter,
the
error
may
be
reported.
A
processor
that
is
performing
serialization
interface
must
support
some
combination
report
a
serialization
error
if
the
values
of
any
serialization
parameters
(other
than
any
that
are
ignored
under
the
previous
paragraph)
are
incorrect.
A processor that is not performing serialization may report errors if any serialization parameters are incorrect, or may ignore such parameters.
Specifying
serialization
parameters
in
which
method
=
"xml"
and
version
=
"1.0"
.
a
query
does
not
by
itself
demand
that
the
output
be
serialized.
It
merely
defines
the
desired
form
of
the
serialized
output
for
use
in
situations
where
the
processor
has
been
asked
to
perform
serialization.
Note:
The data model permits an element node to have fewer in-scope namespaces than its parent. Correct serialization of such an element node would require "undeclaration" of namespaces, which is a feature of [XML Names 1.1] . An implementation that does not support [XML Names 1.1] is permitted to serialize such an element without "undeclaration" of namespaces, which effectively causes the element to inherit the in-scope namespaces of its parent.
In order for XQuery 1.1 to be well defined, the input XDM instance , the static context , and the dynamic context must be mutually consistent. The consistency constraints listed below are prerequisites for correct functioning of an XQuery 1.1 implementation. Enforcement of these consistency constraints is beyond the scope of this specification. This specification does not define the result of a query under any condition in which one or more of these constraints is not satisfied.
Some of the consistency constraints use the term data model schema . [ Definition : For a given node in an XDM instance , the data model schema is defined as the schema from which the type annotation of that node was derived.] For a node that was constructed by some process other than schema validation, the data model schema consists simply of the schema type definition that is represented by the type annotation of the node.
For every node that has a type annotation, if that type annotation is found in the in-scope schema definitions (ISSD), then its definition in the ISSD must be equivalent to its definition in the data model schema . Furthermore, all types that are derived by extension from the given type in the data model schema must also be known by equivalent definitions in the ISSD.
For every element name EN that is found both in an XDM instance and in the in-scope schema definitions (ISSD), all elements that are known in the data model schema to be in the substitution group headed by EN must also be known in the ISSD to be in the substitution group headed by EN .
Every element name, attribute name, or schema type name referenced in in-scope variables or function signatures must be in the in-scope schema definitions , unless it is an element name referenced as part of an ElementTest or an attribute name referenced as part of an AttributeTest .
Any reference to a global element, attribute, or type name in the in-scope schema definitions must have a corresponding element, attribute or type definition in the in-scope schema definitions .
For each mapping of a string to a document node in available documents , if there exists a mapping of the same string to a document type in statically known documents , the document node must match the document type, using the matching rules in 2.5.4 SequenceType Matching .
For each mapping of a string to a sequence of nodes in available collections , if there exists a mapping of the same string to a type in statically known collections , the sequence of nodes must match the type, using the matching rules in 2.5.4 SequenceType Matching .
The sequence of nodes in the default collection must match the statically known default collection type , using the matching rules in 2.5.4 SequenceType Matching .
The value of the context item must match the context item static type , using the matching rules in 2.5.4 SequenceType Matching .
For each (variable, type) pair in in-scope variables and the corresponding (variable, value) pair in variable values such that the variable names are equal, the value must match the type, using the matching rules in 2.5.4 SequenceType Matching .
For
each
variable
declared
as
external
:
If
the
variable
declaration
includes
a
declared
type,
the
external
environment
must
provide
a
value
for
the
variable
that
matches
the
declared
type,
using
the
matching
rules
in
2.5.4
SequenceType
Matching
.
If
the
variable
declaration
does
not
include
a
declared
type,
the
external
environment
must
provide
a
type
and
a
matching
value,
using
the
same
matching
rules.
For each function declared as external: the function implementation must either return a value that matches the declared result type, using the matching rules in 2.5.4 SequenceType Matching , or raise an implementation-defined error.
For a given query, define a participating ISSD as the in-scope schema definitions of a module that is used in evaluating the query. If two participating ISSDs contain a definition for the same schema type, element name, or attribute name, the definitions must be equivalent in both ISSDs. Furthermore, if two participating ISSDs each contain a definition of a schema type T , the set of types derived by extension from T must be equivalent in both ISSDs. Also, if two participating ISSDs each contain a definition of an element name E , the substitution group headed by E must be equivalent in both ISSDs.
In
the
statically
known
namespaces
,
the
prefix
xml
must
not
be
bound
to
any
namespace
URI
other
than
http://www.w3.org/XML/1998/namespace
,
and
no
prefix
other
than
xml
may
be
bound
to
this
namespace
URI.
As described in 2.2.3 Expression Processing , XQuery 1.1 defines a static analysis phase , which does not depend on input data, and a dynamic evaluation phase , which does depend on input data. Errors may be raised during each phase.
[ Definition : A static error is an error that must be detected during the static analysis phase. A syntax error is an example of a static error .]
[ Definition : A dynamic error is an error that must be detected during the dynamic evaluation phase and may be detected during the static analysis phase. Numeric overflow is an example of a dynamic error. ]
[ Definition : A type error may be raised during the static analysis phase or the dynamic evaluation phase. During the static analysis phase, a type error occurs when the static type of an expression does not match the expected type of the context in which the expression occurs. During the dynamic evaluation phase, a type error occurs when the dynamic type of a value does not match the expected type of the context in which the value occurs.]
The outcome of the static analysis phase is either success or one or more type errors , static errors , or statically-detected dynamic errors . The result of the dynamic evaluation phase is either a result value, a type error , or a dynamic error .
If more than one error is present, or if an error condition comes within the scope of more than one error defined in this specification, then any non-empty subset of these errors may be reported.
During
the
static
analysis
phase
,
if
the
Static
Typing
Feature
is
in
effect
and
the
static
type
assigned
to
an
expression
other
than
()
or
data(())
is
empty-sequence()
,
a
static
error
is
raised
[
err:XPST0005
].
This
catches
cases
in
which
a
query
refers
to
an
element
or
attribute
that
is
not
present
in
the
in-scope
schema
definitions
,
possibly
because
of
a
spelling
error.
Independently
of
whether
the
Static
Typing
Feature
is
in
effect,
if
an
implementation
can
determine
during
the
static
analysis
phase
that
an
expression,
if
evaluated,
would
necessarily
raise
a
type
error
or
a
dynamic
error
,
the
implementation
may
(but
is
not
required
to)
report
that
error
during
the
static
analysis
phase
.
However,
the
fn:error()
function
must
not
be
evaluated
during
the
static
analysis
phase
.
[ Definition : In addition to static errors , dynamic errors , and type errors , an XQuery 1.1 implementation may raise warnings , either during the static analysis phase or the dynamic 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 for a reason beyond the scope of this specification. For example, limitations may exist on the maximum numbers or sizes of various objects. Any such limitations, and the consequences of exceeding them, are implementation-dependent .
The
errors
defined
in
this
specification
are
identified
by
QNames
that
have
the
form
err:XXYYnnnn
,
where:
err
denotes
the
namespace
for
XPath
and
XQuery
errors,
http://www.w3.org/2005/xqt-errors
.
This
binding
of
the
namespace
prefix
err
is
used
for
convenience
in
this
document,
and
is
not
normative.
XX
denotes
the
language
in
which
the
error
is
defined,
using
the
following
encoding:
XP
denotes
an
error
defined
by
XPath.
Such
an
error
may
also
occur
XQuery
since
XQuery
includes
XPath
as
a
subset.
XQ
denotes
an
error
defined
by
XQuery.
YY
denotes
the
error
category,
using
the
following
encoding:
ST
denotes
a
static
error.
DY
denotes
a
dynamic
error.
TY
denotes
a
type
error.
nnnn
is
a
unique
numeric
code.
Note:
The namespace URI for XPath and XQuery errors is not expected to change from one version of XQuery 1.1 to another. However, the contents of this namespace may be extended to include additional error definitions.
The method by which an XQuery 1.1 processor reports error information to the external environment is implementation-defined .
An
error
can
be
represented
by
a
URI
reference
that
is
derived
from
the
error
QName
as
follows:
an
error
with
namespace
URI
NS
and
local
part
LP
can
be
represented
as
the
URI
reference
NS
#
LP
.
.
For
example,
an
error
whose
QName
is
err:XPST0017
could
be
represented
as
http://www.w3.org/2005/xqt-errors#XPST0017
.
Note:
Along with a code identifying an error, implementations may wish to return additional information, such as the location of the error or the processing phase in which it was detected. If an implementation chooses to do so, then the mechanism that it uses to return this information is implementation-defined .
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.
[ Definition : In addition to its identifying QName, a dynamic error may also carry a descriptive string and one or more additional values called error values .] An implementation may provide a mechanism whereby an application-defined error handler can process error values and produce diagnostic messages.
A
dynamic
error
may
be
raised
by
a
built-in
function
or
operator.
For
example,
the
div
operator
raises
an
error
if
its
operands
are
xs:decimal
values
and
its
second
operand
is
equal
to
zero.
Errors
raised
by
built-in
functions
and
operators
are
defined
in
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
.
A
dynamic
error
can
also
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]
Operators
1.1]
.
For
example,
the
following
function
call
raises
a
dynamic
error,
providing
a
QName
that
identifies
the
error,
a
descriptive
string,
and
a
diagnostic
value
(assuming
that
the
prefix
app
is
bound
to
a
namespace
containing
application-defined
error
codes):
fn:error(xs:QName("app:err057"), "Unexpected value", fn:string($v))
Because different implementations may choose to evaluate or optimize an expression in different ways, certain aspects of the detection and reporting of dynamic errors are implementation-dependent , as described in this section.
An implementation is always free to evaluate the operands of an operator in any order.
In
some
cases,
a
processor
can
determine
the
result
of
an
expression
without
accessing
all
the
data
that
would
be
implied
by
the
formal
expression
semantics.
For
example,
the
formal
description
of
filter
expressions
suggests
that
$s[1]
should
be
evaluated
by
examining
all
the
items
in
sequence
$s
,
and
selecting
all
those
that
satisfy
the
predicate
position()=1
.
In
practice,
many
implementations
will
recognize
that
they
can
evaluate
this
expression
by
taking
the
first
item
in
the
sequence
and
then
exiting.
If
$s
is
defined
by
an
expression
such
as
//book[author
eq
'Berners-Lee']
,
then
this
strategy
may
avoid
a
complete
scan
of
a
large
document
and
may
therefore
greatly
improve
performance.
However,
a
consequence
of
this
strategy
is
that
a
dynamic
error
or
type
error
that
would
be
detected
if
the
expression
semantics
were
followed
literally
might
not
be
detected
at
all
if
the
evaluation
exits
early.
In
this
example,
such
an
error
might
occur
if
there
is
a
book
element
in
the
input
data
with
more
than
one
author
subelement.
The extent to which a processor may optimize its access to data, at the cost of not detecting errors, is defined by the following rules.
Consider an expression Q that has an operand (sub-expression) E . In general the value of E is a sequence. At an intermediate stage during evaluation of the sequence, some of its items will be known and others will be unknown. If, at such an intermediate stage of evaluation, a processor is able to establish that there are only two possible outcomes of evaluating Q , namely the value V or an error, then the processor may deliver the result V without evaluating further items in the operand E . For this purpose, two values are considered to represent the same outcome if their items are pairwise the same, where nodes are the same if they have the same identity, and values are the same if they are equal and have exactly the same type.
There
is
an
exception
to
this
rule:
If
a
processor
evaluates
an
operand
E
(wholly
or
in
part),
then
it
is
required
to
establish
that
the
actual
value
of
the
operand
E
does
not
violate
any
constraints
on
its
cardinality.
For
example,
the
expression
$e
eq
0
results
in
a
type
error
if
the
value
of
$e
contains
two
or
more
items.
A
processor
is
not
allowed
to
decide,
after
evaluating
the
first
item
in
the
value
of
$e
and
finding
it
equal
to
zero,
that
the
only
possible
outcomes
are
the
value
true
or
a
type
error
caused
by
the
cardinality
violation.
It
must
establish
that
the
value
of
$e
contains
no
more
than
one
item.
These rules apply to all the operands of an expression considered in combination: thus if an expression has two operands E1 and E2 , it may be evaluated using any samples of the respective sequences that satisfy the above rules.
The rules cascade: if A is an operand of B and B is an operand of C , then the processor needs to evaluate only a sufficient sample of B to determine the value of C , and needs to evaluate only a sufficient sample of A to determine this sample of B .
The
effect
of
these
rules
is
that
the
processor
is
free
to
stop
examining
further
items
in
a
sequence
as
soon
as
it
can
establish
that
further
items
would
not
affect
the
result
except
possibly
by
causing
an
error.
For
example,
the
processor
may
return
true
as
the
result
of
the
expression
S1
=
S2
as
soon
as
it
finds
a
pair
of
equal
values
from
the
two
sequences.
Another consequence of these rules is that where none of the items in a sequence contributes to the result of an expression, the processor is not obliged to evaluate any part of the sequence. Again, however, the processor cannot dispense with a required cardinality check: if an empty sequence is not permitted in the relevant context, then the processor must ensure that the operand is not an empty sequence.
Examples:
If
an
implementation
can
find
(for
example,
by
using
an
index)
that
at
least
one
item
returned
by
$expr1
in
the
following
example
has
the
value
47
,
it
is
allowed
to
return
true
as
the
result
of
the
some
expression,
without
searching
for
another
item
returned
by
$expr1
that
would
raise
an
error
if
it
were
evaluated.
some $x in $expr1 satisfies $x = 47
In
the
following
example,
if
an
implementation
can
find
(for
example,
by
using
an
index)
the
product
element-nodes
that
have
an
id
child
with
the
value
47
,
it
is
allowed
to
return
these
nodes
as
the
result
of
the
path
expression
,
without
searching
for
another
product
node
that
would
raise
an
error
because
it
has
an
id
child
whose
value
is
not
an
integer.
//product[id = 47]
For
a
variety
of
reasons,
including
optimization,
implementations
are
free
to
may
rewrite
expressions
into
equivalent
expressions.
a
different
form.
There
are
a
number
of
rules
that
limit
the
extent
of
this
freedom:
Other
than
the
raising
or
not
raising
of
errors,
the
result
of
evaluating
an
equivalent
a
rewritten
expression
must
conform
to
the
semantics
defined
in
this
specification
for
the
original
expression.
Note:
This allows an implementation to return a result in cases where the original expression would have raised an error, or to raise an error in cases where the original expression would have returned a result. The main cases where this is likely to arise in practice are (a) where a rewrite changes the order of evaluation, such that a subexpression causing an error is evaluated when the expression is written one way and is not evaluated when the expression is written a different way, and (b) where intermediate results of the evaluation cause overflow or other out-of-range conditions.
Note:
This
rule
does
not
mean
that
the
result
of
the
expression
will
always
be
the
same
in
non-error
cases
as
if
it
had
not
been
rewritten,
because
there
are
many
cases
where
the
result
of
evaluating
an
expression
is
to
some
degree
implementation-dependent
or
implementation-defined
.
Conditional
and
typeswitch
expressions
must
not
raise
a
dynamic
error
in
respect
of
subexpressions
occurring
in
a
branch
that
is
not
selected,
and
must
not
return
the
value
delivered
by
a
branch
unless
that
branch
is
selected.
Thus,
the
following
example
must
not
raise
a
dynamic
error
if
the
document
abc.xml
does
not
exist:
if (doc-available('abc.xml')) then doc('abc.xml') else ()
As
stated
earlier,
an
expression
must
not
be
rewritten
to
dispense
with
a
required
cardinality
check:
for
example,
string-length(//title)
must
raise
an
error
if
the
document
contains
more
than
one
title
element.
Expressions must not be rewritten in such a way as to create or remove static errors. For example, there is a rule that in casting a string to a QName the operand must be a string literal. This rule applies to the original expression and not to any rewritten form of the expression.
Expression rewrite is illustrated by the following examples.
Consider
the
expression
//part[color
eq
"Red"]
.
An
implementation
might
choose
to
rewrite
this
expression
as
//part[color
=
"Red"][color
eq
"Red"]
.
The
implementation
might
then
process
the
expression
as
follows:
First
process
the
"
=
"
predicate
by
probing
an
index
on
parts
by
color
to
quickly
find
all
the
parts
that
have
a
Red
color;
then
process
the
"
eq
"
predicate
by
checking
each
of
these
parts
to
make
sure
it
has
only
a
single
color.
The
result
would
be
as
follows:
Parts that have exactly one color that is Red are returned.
If some part has color Red together with some other color, an error is raised.
The existence of some part that has no color Red but has multiple non-Red colors does not trigger an error.
The expression in the following example cannot raise a casting error if it is evaluated exactly as written (i.e., left to right). Since neither predicate depends on the context position, an implementation might choose to reorder the predicates to achieve better performance (for example, by taking advantage of an index). This reordering could 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
expression
rewrite,
tests
that
are
designed
to
prevent
dynamic
errors
should
be
expressed
using
conditional
or
typeswitch
expressions.
Conditional
and
typeswitch
expressions
raise
only
dynamic
errors
that
occur
in
the
branch
that
is
actually
selected.
Thus,
unlike
the
previous
For
example,
the
following
example
cannot
raise
a
dynamic
error
if
@x
is
not
castable
into
an
xs:date
:
above
expression
can
be
written
as
follows:
$N[if (@x castable as xs:date) then xs:date(@x) gt xs:date("2000-01-01") else false()]
This section explains some concepts that are important to the processing of XQuery 1.1 expressions.
An
ordering
called
document
order
is
defined
among
all
the
nodes
accessible
during
processing
of
a
given
query
,
which
may
consist
of
one
or
more
trees
(documents
or
fragments).
Document
order
is
defined
in
[XQuery/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
,
and
its
definition
is
repeated
here
for
convenience.
[
Definition
:
The
node
ordering
that
is
the
reverse
of
document
order
is
called
reverse
document
order
.]
Document order is a total ordering, although the relative order of some nodes is implementation-dependent . [ Definition : Informally, document order is the order in which nodes appear in the XML serialization of a document.] [ Definition : Document order is stable , which means that the relative order of two nodes will not change during the processing of a given query , even if this order is implementation-dependent .]
Within a tree, document order satisfies the following constraints:
The root node is the first node.
Every node occurs before all of its children and descendants.
Attribute nodes immediately follow the element node with which they are associated. The relative order of attribute nodes is stable but implementation-dependent .
The
relative
order
of
siblings
is
the
order
in
which
they
occur
in
the
children
property
of
their
parent
node.
Children and descendants occur before following siblings.
The relative order of nodes in distinct trees is stable but implementation-dependent , subject to the following constraint: If any node in a given tree T1 is before any node in a different tree T2, then all nodes in tree T1 are before all nodes in tree T2.
The
semantics
of
some
XQuery
1.1
operators
depend
on
a
process
called
atomization
.
Atomization
is
applied
to
a
value
when
the
value
is
used
in
a
context
in
which
a
sequence
of
atomic
values
is
required.
The
result
of
atomization
is
either
a
sequence
of
atomic
values
or
a
type
error
[err:FOTY0012].
[
Definition
:
Atomization
of
a
sequence
is
defined
as
the
result
of
invoking
the
fn:data
function
on
the
sequence,
as
defined
in
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
.]
The
semantics
of
fn:data
are
repeated
here
for
convenience.
The
result
of
fn:data
is
the
sequence
of
atomic
values
produced
by
applying
the
following
rules
to
each
item
in
the
input
sequence:
If the item is an atomic value, it is returned.
If the item is a node, its typed value is returned (err:FOTY0012 is raised if the node has no typed value.)
If the item is a function item DM11 [err:FOTY0012] is raised.
Atomization is used in processing the following types of expressions:
Arithmetic expressions
Comparison expressions
Function calls and returns
Cast expressions
Constructor expressions for various kinds of nodes
order
by
clauses
in
FLWOR
expressions
group
by
clauses
in
FLWOR
expressions
Switch expressions
Under
certain
circumstances
(listed
below),
it
is
necessary
to
find
the
effective
boolean
value
of
a
value.
[
Definition
:
The
effective
boolean
value
of
a
value
is
defined
as
the
result
of
applying
the
fn:boolean
function
to
the
value,
as
defined
in
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
.]
The
dynamic
semantics
of
fn:boolean
are
repeated
here
for
convenience:
If
its
operand
is
an
empty
sequence,
fn:boolean
returns
false
.
If
its
operand
is
a
sequence
whose
first
item
is
a
node,
fn:boolean
returns
true
.
If
its
operand
is
a
singleton
value
of
type
xs:boolean
or
derived
from
xs:boolean
,
fn:boolean
returns
the
value
of
its
operand
unchanged.
If
its
operand
is
a
singleton
value
of
type
xs:string
,
xs:anyURI
,
xs:untypedAtomic
,
or
a
type
derived
from
one
of
these,
fn:boolean
returns
false
if
the
operand
value
has
zero
length;
otherwise
it
returns
true
.
If
its
operand
is
a
singleton
value
of
any
numeric
type
or
derived
from
a
numeric
type,
fn:boolean
returns
false
if
the
operand
value
is
NaN
or
is
numerically
equal
to
zero;
otherwise
it
returns
true
.
In
all
other
cases,
fn:boolean
raises
a
type
error
[err:FORG0006].
Note:
The
static
semantics
of
fn:boolean
are
defined
in
Section
7.2.4
The
fn:boolean
function
FS
.
Note:
The
effective
boolean
value
of
a
sequence
that
contains
at
least
one
node
and
at
least
one
atomic
value
may
be
nondeterministic
in
regions
of
a
query
where
ordering
mode
is
unordered
.
The effective boolean value of a sequence is computed implicitly during processing of the following types of expressions:
Logical
expressions
(
and
,
or
)
The
fn:not
function
The
where
clause
of
a
FLWOR
expression
Certain
types
of
predicates
,
such
as
a[b]
Conditional
expressions
(
if
)
Quantified
expressions
(
some
,
every
)
Note:
The
definition
of
effective
boolean
value
is
not
used
when
casting
a
value
to
the
type
xs:boolean
,
for
example
in
a
cast
expression
or
when
passing
a
value
to
a
function
whose
expected
parameter
is
of
type
xs:boolean
.
XQuery
1.1
has
a
set
of
functions
that
provide
access
to
input
data.
These
functions
are
of
particular
importance
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]
Operators
1.1]
.
An expression can access input data either by calling one of the input functions or by referencing some part of the dynamic context that is initialized by the external environment, such as a variable or context item .
The input functions supported by XQuery 1.1 are as follows:
The
fn:doc
function
takes
a
string
containing
a
URI.
If
that
URI
is
associated
with
a
document
in
available
documents
,
fn:doc
returns
a
document
node
whose
content
is
the
data
model
representation
of
the
given
document;
otherwise
it
raises
a
dynamic
error
(see
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
for
details).
The
fn:collection
function
with
one
argument
takes
a
string
containing
a
URI.
If
that
URI
is
associated
with
a
collection
in
available
collections
,
fn:collection
returns
the
data
model
representation
of
that
collection;
otherwise
it
raises
a
dynamic
error
(see
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
for
details).
A
collection
may
be
any
sequence
of
nodes.
For
example,
the
expression
fn:collection("http://example.org")//customer
identifies
all
the
customer
elements
that
are
descendants
of
nodes
found
in
the
collection
whose
URI
is
http://example.org
.
The
fn:collection
function
with
zero
arguments
returns
the
default
collection
,
an
implementation-dependent
sequence
of
nodes.
In certain places in the XQuery grammar, a statically known valid URI is required. These places are denoted by the grammatical symbol URILiteral . For example, URILiterals are used to specify namespaces and collations, both of which must be statically known.
|
URILiteral
|
::= |
StringLiteral
|
Syntactically,
a
URILiteral
is
identical
to
a
StringLiteral
:
a
sequence
of
zero
or
more
characters
enclosed
in
single
or
double
quotes.
However,
an
implementation
MAY
may
raise
a
static
error
[
err:XQST0046
]
if
the
value
of
a
URILiteral
is
of
nonzero
length
and
is
not
in
the
lexical
space
of
xs:anyURI
.
As
in
a
string
literal,
any
predefined
entity
reference
(such
as
&
),
character
reference
(such
as
•
),
or
EscapeQuot
or
EscapeApos
(for
example,
""
)
is
replaced
by
its
appropriate
expansion.
Certain
characters,
notably
the
ampersand,
can
only
be
represented
using
a
predefined
entity
reference
or
a
character
reference
.
The
URILiteral
is
subjected
to
whitespace
normalization
as
defined
for
the
xs:anyURI
type
in
[XML
Schema]
:
this
means
that
leading
and
trailing
whitespace
is
removed,
and
any
other
sequence
of
whitespace
characters
is
replaced
by
a
single
space
(#x20)
character.
Whitespace
normalization
is
done
after
the
expansion
of
character
references
,
so
writing
a
newline
(for
example)
as


does
not
prevent
its
being
normalized
to
a
space
character.
The URILiteral is not automatically subjected to percent-encoding or decoding as defined in [RFC3986] . Any process that attempts to resolve the URI against a base URI, or to dereference the URI, may however apply percent-encoding or decoding as defined in the relevant RFCs.
Note:
The
xs:anyURI
type
is
designed
to
anticipate
the
introduction
of
Internationalized
Resource
Identifiers
(IRI's)
as
defined
in
[RFC3987]
.
The following is an example of a valid URILiteral:
"http://www.w3.org/2005/xpath-functions/collation/codepoint"
The
type
system
of
XQuery
1.1
is
based
on
[XML
Schema]
,
and
is
formally
defined
in
[XQuery
1.0
and
XPath
2.0
Formal
Semantics]
.
[ Definition : A sequence type is a type that can be expressed using the SequenceType syntax. Sequence types are used whenever it is necessary to refer to a type in an XQuery 1.1 expression. The term sequence type suggests that this syntax is used to describe the type of an XQuery 1.1 value, which is always a sequence.]
[
Definition
:
A
schema
type
is
a
type
that
is
(or
could
be)
defined
using
the
facilities
of
[XML
Schema]
(including
the
built-in
types
of
[XML
Schema]
).]
A
schema
type
can
be
used
as
a
type
annotation
on
an
element
or
attribute
node
(unless
it
is
a
non-instantiable
type
such
as
xs:NOTATION
or
xs:anyAtomicType
,
in
which
case
its
derived
types
can
be
so
used).
Every
schema
type
is
either
a
complex
type
or
a
simple
type
;
simple
types
are
further
subdivided
into
list
types
,
union
types
,
and
atomic
types
(see
[XML
Schema]
for
definitions
and
explanations
of
these
terms.)
Atomic
types
represent
the
intersection
between
the
categories
of
sequence
type
and
schema
type
.
An
atomic
type,
such
as
xs:integer
or
my:hatsize
,
is
both
a
sequence
type
and
a
schema
type
.
The
in-scope
schema
types
in
the
static
context
are
initialized
with
certain
predefined
schema
types,
including
the
built-in
schema
types
in
the
namespace
http://www.w3.org/2001/XMLSchema
,
which
has
the
predefined
namespace
prefix
xs
.
The
schema
types
in
this
namespace
are
defined
in
[XML
Schema]
and
augmented
by
additional
types
defined
in
[XQuery/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
.
Element
and
attribute
declarations
in
the
xs
namespace
are
not
implicitly
included
in
the
static
context.
The
schema
types
defined
in
[XQuery/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
are
summarized
below.
[
Definition
:
xs:untyped
is
used
as
the
type
annotation
of
an
element
node
that
has
not
been
validated,
or
has
been
validated
in
skip
mode.]
No
predefined
schema
types
are
derived
from
xs:untyped
.
[
Definition
:
xs:untypedAtomic
is
an
atomic
type
that
is
used
to
denote
untyped
atomic
data,
such
as
text
that
has
not
been
assigned
a
more
specific
type.]
An
attribute
that
has
been
validated
in
skip
mode
is
represented
in
the
data
model
by
an
attribute
node
with
the
type
annotation
xs:untypedAtomic
.
No
predefined
schema
types
are
derived
from
xs:untypedAtomic
.
[
Definition
:
xs:dayTimeDuration
is
derived
by
restriction
from
xs:duration
.
The
lexical
representation
of
xs:dayTimeDuration
is
restricted
to
contain
only
day,
hour,
minute,
and
second
components.]
[
Definition
:
xs:yearMonthDuration
is
derived
by
restriction
from
xs:duration
.
The
lexical
representation
of
xs:yearMonthDuration
is
restricted
to
contain
only
year
and
month
components.]
[
Definition
:
xs:anyAtomicType
is
an
atomic
type
that
includes
all
atomic
values
(and
no
values
that
are
not
atomic).
Its
base
type
is
xs:anySimpleType
from
which
all
simple
types,
including
atomic,
list,
and
union
types,
are
derived.
All
primitive
atomic
types,
such
as
and
xs:integer
,
xs:string
,
xs:decimal
,
have
xs:untypedAtomic
xs:string
xs:anyAtomicType
as
their
base
type.]
Note:
xs:anyAtomicType
will
not
appear
as
the
type
of
an
actual
value
in
an
XDM
instance
.
The
relationships
among
the
schema
types
in
the
xs
namespace
are
illustrated
in
Figure
2.
A
more
complete
description
of
the
XQuery
1.1
type
hierarchy
can
be
found
in
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
.
Figure 2: Hierarchy of Schema Types used in XQuery 1.1.
Every
node
has
a
typed
value
and
a
string
value
.
[
Definition
:
The
typed
value
of
a
node
is
a
sequence
of
atomic
values
and
can
be
extracted
by
applying
the
fn:data
function
to
the
node.]
[
Definition
:
The
string
value
of
a
node
is
a
string
and
can
be
extracted
by
applying
the
fn:string
function
to
the
node.]
Definitions
of
fn:data
and
fn:string
can
be
found
in
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
.
An
implementation
may
store
both
the
typed
value
and
the
string
value
of
a
node,
or
it
may
store
only
one
of
these
and
derive
the
other
as
needed.
The
string
value
of
a
node
must
be
a
valid
lexical
representation
of
the
typed
value
of
the
node,
but
the
node
is
not
required
to
preserve
the
string
representation
from
the
original
source
document.
For
example,
if
the
typed
value
of
a
node
is
the
xs:integer
value
30
,
its
string
value
might
be
"
30
"
or
"
0030
".
The typed value , string value , and type annotation of a node are closely related, and are defined by rules found in the following locations:
If
the
node
was
created
by
mapping
from
an
Infoset
or
PSVI,
see
rules
in
[XQuery/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
.
If the node was created by an XQuery node constructor, see rules in 3.7.1 Direct Element Constructors , 3.7.3.1 Computed Element Constructors , or 3.7.3.2 Computed Attribute Constructors .
If
the
node
was
created
by
a
validate
expression,
see
rules
in
3.13
3.15
Validate
Expressions
.
As a convenience to the reader, the relationship between typed value and string value for various kinds of nodes is summarized and illustrated by examples below.
For
text
and
document
nodes,
the
typed
value
of
the
node
is
the
same
as
its
string
value,
as
an
instance
of
the
type
xs:untypedAtomic
.
The
string
value
of
a
document
node
is
formed
by
concatenating
the
string
values
of
all
its
descendant
text
nodes,
in
document
order
.
The
typed
value
of
a
comment
or
processing
instruction
node
is
the
same
as
its
string
value.
It
is
an
instance
of
the
type
xs:string
.
The
typed
value
of
an
attribute
node
with
the
type
annotation
xs:anySimpleType
or
xs:untypedAtomic
is
the
same
as
its
string
value,
as
an
instance
of
xs:untypedAtomic
.
The
typed
value
of
an
attribute
node
with
any
other
type
annotation
is
derived
from
its
string
value
and
type
annotation
using
the
lexical-to-value-space
mapping
defined
in
[XML
Schema]
Part
2
for
the
relevant
type.
Example:
A1
is
an
attribute
having
string
value
"3.14E-2"
and
type
annotation
xs:double
.
The
typed
value
of
A1
is
the
xs:double
value
whose
lexical
representation
is
3.14E-2
.
Example:
A2
is
an
attribute
with
type
annotation
xs:IDREFS
,
which
is
a
list
datatype
whose
item
type
is
the
atomic
datatype
xs:IDREF
.
Its
string
value
is
"
bar
baz
faz
".
The
typed
value
of
A2
is
a
sequence
of
three
atomic
values
("
bar
",
"
baz
",
"
faz
"),
each
of
type
xs:IDREF
.
The
typed
value
of
a
node
is
never
treated
as
an
instance
of
a
named
list
type.
Instead,
if
the
type
annotation
of
a
node
is
a
list
type
(such
as
xs:IDREFS
),
its
typed
value
is
treated
as
a
sequence
of
the
atomic
type
from
which
it
is
derived
(such
as
xs:IDREF
).
For an element node, the relationship between typed value and string value depends on the node's type annotation , as follows:
If
the
type
annotation
is
xs:untyped
or
xs:anySimpleType
or
denotes
a
complex
type
with
mixed
content
(including
xs:anyType
),
then
the
typed
value
of
the
node
is
equal
to
its
string
value,
as
an
instance
of
xs:untypedAtomic
.
However,
if
the
nilled
property
of
the
node
is
true
,
then
its
typed
value
is
the
empty
sequence.
Example:
E1
is
an
element
node
having
type
annotation
xs:untyped
and
string
value
"
1999-05-31
".
The
typed
value
of
E1
is
"
1999-05-31
",
as
an
instance
of
xs:untypedAtomic
.
Example:
E2
is
an
element
node
with
the
type
annotation
formula
,
which
is
a
complex
type
with
mixed
content.
The
content
of
E2
consists
of
the
character
"
H
",
a
child
element
named
subscript
with
string
value
"
2
",
and
the
character
"
O
".
The
typed
value
of
E2
is
"
H2O
"
as
an
instance
of
xs:untypedAtomic
.
If
the
type
annotation
denotes
a
simple
type
or
a
complex
type
with
simple
content,
then
the
typed
value
of
the
node
is
derived
from
its
string
value
and
its
type
annotation
in
a
way
that
is
consistent
with
schema
validation.
However,
if
the
nilled
property
of
the
node
is
true
,
then
its
typed
value
is
the
empty
sequence.
Example:
E3
is
an
element
node
with
the
type
annotation
cost
,
which
is
a
complex
type
that
has
several
attributes
and
a
simple
content
type
of
xs:decimal
.
The
string
value
of
E3
is
"
74.95
".
The
typed
value
of
E3
is
74.95
,
as
an
instance
of
xs:decimal
.
Example:
E4
is
an
element
node
with
the
type
annotation
hatsizelist
,
which
is
a
simple
type
derived
from
the
atomic
type
hatsize
,
which
in
turn
is
derived
from
xs:integer
.
The
string
value
of
E4
is
"
7
8
9
".
The
typed
value
of
E4
is
a
sequence
of
three
values
(
7
,
8
,
9
),
each
of
type
hatsize
.
Example:
E5
is
an
element
node
with
the
type
annotation
my:integer-or-string
which
is
a
union
type
with
member
types
xs:integer
and
xs:string
.
The
string
value
of
E5
is
"
47
".
The
typed
value
of
E5
is
47
as
an
xs:integer
,
since
xs:integer
is
the
member
type
that
validated
the
content
of
E5.
In
general,
when
the
type
annotation
of
a
node
is
a
union
type,
the
typed
value
of
the
node
will
be
an
instance
of
one
of
the
member
types
of
the
union.
Note:
If an implementation stores only the string value of a node, and the type annotation of the node is a union type, the implementation must be able to deliver the typed value of the node as an instance of the appropriate member type.
If the type annotation denotes a complex type with empty content, then the typed value of the node is the empty sequence and its string value is the zero-length string.
If
the
type
annotation
denotes
a
complex
type
with
element-only
content,
then
the
typed
value
of
the
node
is
undefined.
The
fn:data
function
raises
a
type
error
[err:FOTY0012]
when
applied
to
such
a
node.
The
string
value
of
such
a
node
is
equal
to
the
concatenated
string
values
of
all
its
text
node
descendants,
in
document
order.
Example:
E6
is
an
element
node
with
the
type
annotation
weather
,
which
is
a
complex
type
whose
content
type
specifies
element-only
.
E6
has
two
child
elements
named
temperature
and
precipitation
.
The
typed
value
of
E6
is
undefined,
and
the
fn:data
function
applied
to
E6
raises
an
error.
Whenever it is necessary to refer to a type in an XQuery 1.1 expression, the SequenceType syntax is used.
|
SequenceType
|
::= |
("empty-sequence"
"("
")")
|
|
ItemType
|
::= |
KindTest
|
("item"
"("
")")
|
FunctionTest
|
AtomicType
|
ParenthesizedItemType
|
|
OccurrenceIndicator
|
::= |
"?"
|
"*"
|
"+"
|
|
AtomicType
|
::= |
QName
|
|
KindTest
|
::= |
DocumentTest
|
|
DocumentTest
|
::= |
"document-node"
"("
(
ElementTest
|
SchemaElementTest
)?
")"
|
|
ElementTest
|
::= |
"element"
"("
(
ElementNameOrWildcard
(","
TypeName
"?"?)?)?
")"
|
|
SchemaElementTest
|
::= |
"schema-element"
"("
ElementDeclaration
")"
|
|
ElementDeclaration
|
::= |
ElementName
|
|
AttributeTest
|
::= |
"attribute"
"("
(
AttribNameOrWildcard
(","
TypeName
)?)?
")"
|
|
SchemaAttributeTest
|
::= |
"schema-attribute"
"("
AttributeDeclaration
")"
|
|
AttributeDeclaration
|
::= |
AttributeName
|
|
ElementNameOrWildcard
|
::= |
ElementName
|
"*"
|
|
ElementName
|
::= |
QName
|
|
AttribNameOrWildcard
|
::= |
AttributeName
|
"*"
|
|
AttributeName
|
::= |
QName
|
|
TypeName
|
::= |
QName
|
|
PITest
|
::= |
"processing-instruction"
"("
(
NCName
|
StringLiteral
)?
")"
|
|
CommentTest
|
::= |
"comment"
"("
")"
|
[174] |
TextTest
|
::= |
|
|
AnyKindTest
|
::= |
"node"
"("
")"
|
[189] |
FunctionTest
| ::= |
AnyFunctionTest
|
[190] |
AnyFunctionTest
|
::= |
|
|
TypedFunctionTest
|
::= |
"function"
"("
(
SequenceType
(","
SequenceType
)*)?
")"
"as"
SequenceType
|
[192] |
ParenthesizedItemType
|
::= |
|
With
the
exception
of
the
special
type
empty-sequence()
,
a
sequence
type
consists
of
an
item
type
that
constrains
the
type
of
each
item
in
the
sequence,
and
a
cardinality
that
constrains
the
number
of
items
in
the
sequence.
Apart
from
the
item
type
item()
,
which
permits
any
kind
of
item,
item
types
divide
into
node
types
(such
as
element()
)
and
),
atomic
types
(such
as
xs:integer
).
)
and
function
types
(such
as
function()
as
item()*).
Item
types
representing
element
and
attribute
nodes
may
specify
the
required
type
annotations
of
those
nodes,
in
the
form
of
a
schema
type
.
Thus
the
item
type
element(*,
us:address)
denotes
any
element
node
whose
type
annotation
is
(or
is
derived
from)
the
schema
type
named
us:address
.
It is permitted to use parentheses to enclose item types, in order to resolve ambiguities that could arise from the OccurrenceIndicator of a SequenceType .
Here are some examples of sequence types that might be used in XQuery 1.1 expressions:
xs:date
refers
to
the
built-in
atomic
schema
type
named
xs:date
attribute()?
refers
to
an
optional
attribute
node
element()
refers
to
any
element
node
element(po:shipto,
po:address)
refers
to
an
element
node
that
has
the
name
po:shipto
and
has
the
type
annotation
po:address
(or
a
schema
type
derived
from
po:address
)
element(*,
po:address)
refers
to
an
element
node
of
any
name
that
has
the
type
annotation
po:address
(or
a
type
derived
from
po:address
)
element(customer)
refers
to
an
element
node
named
customer
with
any
type
annotation
schema-element(customer)
refers
to
an
element
node
whose
name
is
customer
(or
is
in
the
substitution
group
headed
by
customer
)
and
whose
type
annotation
matches
the
schema
type
declared
for
a
customer
element
in
the
in-scope
element
declarations
node()*
refers
to
a
sequence
of
zero
or
more
nodes
of
any
kind
item()+
refers
to
a
sequence
of
one
or
more
nodes
or
atomic
values
function(*)
refers
to
any
function
item
DM11
,
regardless
of
arity
or
type
function(node())
as
xs:string*
refers
to
a
function
item
DM11
that
takes
a
single
argument
whose
value
is
a
single
node,
and
returns
a
sequence
of
zero
or
more
xs:string
values
(function(node())
as
xs:string)*
refers
to
a
sequence
of
zero
or
more
function
items
DM11
,
each
of
which
takes
a
single
argument
whose
value
is
a
single
node,
and
returns
as
its
result
a
single
xs:string
value
[
Definition
:
During
evaluation
of
an
expression,
it
is
sometimes
necessary
to
determine
whether
a
value
with
a
known
dynamic
type
"matches"
an
expected
sequence
type
.
This
process
is
known
as
SequenceType
matching
.]
For
example,
an
instance
of
expression
returns
true
if
the
dynamic
type
of
a
given
value
matches
a
given
sequence
type
,
or
false
if
it
does
not.
QNames
appearing
in
a
sequence
type
have
their
prefixes
expanded
to
namespace
URIs
by
means
of
the
statically
known
namespaces
and
(where
applicable)
the
default
element/type
namespace
.
An
unprefixed
attribute
QName
is
in
no
namespace.
Equality
of
QNames
is
defined
by
the
eq
operator.
The
rules
for
SequenceType
matching
compare
the
dynamic
type
of
a
value
with
an
expected
sequence
type
.
These
rules
are
a
subset
of
the
formal
rules
that
match
a
value
with
an
expected
type
defined
in
[XQuery
1.0
and
XPath
2.0
Formal
Semantics]
,
because
the
Formal
Semantics
must
be
able
to
match
values
against
types
that
are
not
expressible
using
the
SequenceType
syntax.
Some
of
the
rules
for
SequenceType
matching
require
determining
whether
a
given
schema
type
encountered
as
a
type
annotation
in
an
instance
document
is
the
same
as
or
derived
from
an
expected
schema
type.
The
given
This
determination
is
done
by
reference
to
a
schema
type
may
be
"known"
(defined
in
S
(that
is,
a
set
of
schema
components).
This
schema
S
is
the
union
of:
the
in-scope
schema
definitions
),
or
"unknown"
(not
defined
in
the
in-scope
static
context
of
the
query
module
potentially,
the
schema
definitions
).
An
unknown
used
for
validating
the
instance
document;
whether
a
processor
adds
this
schema
to
S
is
implementation-defined
.
potentially, further schema components that have been made available to the processor in an implementation-defined way.
A
type
might
error
[
err:XPTY0004
]
may
be
encountered,
for
example,
raised
if
this
union
does
not
constitute
a
source
document
has
been
validated
using
a
valid
schema
that
was
not
imported
into
(for
example,
if
there
are
conflicts
between
types
present
in
the
static
context
.
In
this
case,
an
implementation
is
allowed
(but
is
not
required)
to
provide
an
implementation-dependent
mechanism
and
types
used
dynamically
for
determining
whether
validating
instances.)
Whether
the
unknown
schema
type
used
to
validate
the
instance
document
is
derived
from
in
S
is
implementation-defined.
Whether
the
expected
schema
type.
For
example,
an
implementation
might
maintain
a
data
dictionary
containing
information
about
type
hierarchies.
provides
further
schema
components
in
S
is
also
implementation-defined.
[
Definition
:
The
use
of
a
value
whose
dynamic
type
is
derived
from
an
expected
type
is
known
as
subtype
substitution
.]
Subtype
substitution
does
not
change
the
actual
type
of
a
value.
For
example,
if
an
xs:integer
value
is
used
where
an
xs:decimal
value
is
expected,
the
value
retains
its
type
as
xs:integer
.
The
definition
of
SequenceType
matching
relies
on
a
pseudo-function
named
derives-from(
AT
,
AT,
ET
)
,
which
takes
an
actual
simple
or
complex
schema
type
AT
and
an
expected
simple
or
complex
schema
type
ET
,
,
and
either
returns
a
boolean
value
or
raises
a
type
error
[
err:XPTY0004
].
The
pseudo-function
derives-from
is
defined
below
and
This
function
is
defined
formally
in
[XQuery
1.0
and
XPath
2.0
Formal
Semantics]
.
as
follows:
derives-from(
AT
,
ET
)
returns
true
if
ET
is
raises
a
known
type
and
any
of
the
following
three
conditions
is
true:
error
[err:XPTY0004]
if
either
AT
is
a
schema
type
found
in
the
in-scope
schema
definitions
,
and
is
the
same
as
ET
or
is
derived
by
restriction
or
extension
from
ET
AT
is
a
schema
type
not
found
present
in
the
in-scope
schema
definitions
,
and
an
implementation-dependent
mechanism
is
able
to
determine
that
AT
is
derived
by
restriction
from
ET
There
exists
some
schema
type
IT
such
that
derives-from(
IT,
ET
)
and
derives-from(
AT,
IT
S
)
are
true.
derives-from(
AT
,
ET
)
returns
false
if
true
ET
AT
is
a
known
type
and
either
the
first
ET
are
both
present
in
S
,
and
third
if
one
or
the
second
and
third
more
of
the
following
three
conditions
are
is
true:
AT
is
a
schema
type
found
in
the
in-scope
schema
definitions
,
and
is
not
the
same
type
as
ET
,
and
AT
is
not
derived
by
restriction
or
extension
from
ET
Note:
Some
members
of
the
XML
Query
Working
Group
believe
that
matching
types
derived
by
restriction
should
be
required,
but
extension
from
AT
ET
is
a
schema
type
should
be
implementation-defined,
others
believe
matching
types
derived
by
extension
from
ET
should
be
required
of
all
implementations.
Some implementations that do static analysis may do optimizations that would be invalidated by allowing dynamically encountered types derived by extension from ET .
If
these
implementations
do
not
found
in
add
such
types
to
S
,
they
will
not
encounter
such
types.
Some
implementers
argue
that
they
would
like
the
in-scope
freedom
to
use
dynamic
schema
definitions
,
and
an
implementation-dependent
mechanism
is
information
in
queries,
but
still
want
to
be
able
to
determine
optimize
statically.
Some
Working
Group
members
suggest
that
AT
it
is
not
derived
by
restriction
a
clearer
model
to
either
use
all
schema
information
from
dynamically
encountered
schemas,
including
derivation
by
extension,
or
not
place
it
in
ET
S
.
The XML Query Working Group has not reached consensus on this question, and we welcome feedback.
No
S
contains
some
schema
type
IT
exists
such
that
derives-from(
IT,
IT
,
ET
)
and
derives-from(
AT,
AT
,
IT
)
are
true.
Otherwise,
derives-from(
AT
,
ET
)
raises
a
type
error
[
err:XPTY0004
]
if:
ET
is
an
unknown
type,
or
AT
is
an
unknown
type,
and
the
implementation
is
not
able
to
determine
whether
AT
is
derived
by
restriction
from
ET
.
returns
false
The rules for SequenceType matching are given below, with examples (the examples are for purposes of illustration, and do not cover all possible cases).
The
sequence
type
empty-sequence()
matches
a
value
that
is
the
empty
sequence.
An ItemType with no OccurrenceIndicator matches any value that contains exactly one item if the ItemType matches that item (see 2.5.4.2 Matching an ItemType and an Item ).
An ItemType with an OccurrenceIndicator matches a value if the number of items in the value matches the OccurrenceIndicator and the ItemType matches each of the items in the value.
An OccurrenceIndicator specifies the number of items in a sequence, as follows:
?
matches
zero
or
one
items
*
matches
zero
or
more
items
+
matches
one
or
more
items
As
a
consequence
of
these
rules,
any
sequence
type
whose
OccurrenceIndicator
is
*
or
?
matches
a
value
that
is
an
empty
sequence.
An
ItemType
consisting
simply
of
a
QName
is
interpreted
as
an
AtomicType
.
An
AtomicType
AtomicType
matches
an
atomic
value
whose
actual
type
is
AT
if
derives-from(
AT,
AtomicType
)
is
true
.
If
a
QName
that
is
used
as
an
AtomicType
is
not
defined
as
an
atomic
type
in
the
in-scope
schema
types
,
a
static
error
is
raised
[
err:XPST0051
].
Example:
The
AtomicType
xs: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
.
Note:
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
any
single
item.
Example:
item()
matches
the
atomic
value
1
or
the
element
<a/>
.
node()
matches
any
node.
function(*)
matches
any
function
item
DM11
.
text()
matches
any
text
node.
processing-instruction()
matches
any
processing-instruction
node.
processing-instruction(
N
)
matches
any
processing-instruction
node
whose
name
(called
its
"PITarget"
in
XML)
PITarget
is
equal
to
N
,
where
N
fn:normalize-space(N)
.
If
fn:normalize-space(N)
is
an
NCName.
not
in
the
lexical
space
of
NCName,
a
type
error
is
raised
[
err:XPTY0004
]
Example:
processing-instruction(xml-stylesheet)
matches
any
processing
instruction
whose
PITarget
is
xml-stylesheet
.
For
backward
compatibility
with
XPath
1.0,
the
PITarget
of
a
processing
instruction
may
also
be
expressed
as
a
string
literal,
as
in
this
example:
processing-instruction("xml-stylesheet")
.
If the specified PITarget is not a syntactically valid NCName, a type error is raised [ err:XPTY0004 ].
comment()
matches
any
comment
node.
namespace-node()
matches
any
namespace
node.
document-node()
matches
any
document
node.
document-node(
E
)
matches
any
document
node
that
contains
exactly
one
element
node,
optionally
accompanied
by
one
or
more
comment
and
processing
instruction
nodes,
if
E
is
an
ElementTest
or
SchemaElementTest
that
matches
the
element
node
(see
2.5.4.3
Element
Test
and
2.5.4.4
Schema
Element
Test
).
Example:
document-node(element(book))
matches
a
document
node
containing
exactly
one
element
node
that
is
matched
by
the
ElementTest
element(book)
.
A TypedFunctionTest matches an item if it is a function item DM11 , and the function item's type signature (as defined in Section 2.7 Function Items DM11 ) is a subtype of the TypedFunctionTest .
An
ItemType
that
is
an
ElementTest
,
SchemaElementTest
,
AttributeTest
,
or
SchemaAttributeTest
matches
an
element
or
attribute
node
item
as
described
in
the
following
sections.
An ElementTest is used to match an element node by its name and/or type annotation . An ElementTest may take any of the following forms. In these forms, ElementName need not be present in the in-scope element declarations , but TypeName must be present in the in-scope schema types [ err:XPST0008 ]. Note that substitution groups do not affect the semantics of ElementTest .
element()
and
element(*)
match
any
single
element
node,
regardless
of
its
name
or
type
annotation.
element(
ElementName
)
matches
any
element
node
whose
name
is
ElementName
,
regardless
of
its
type
annotation
or
nilled
property.
Example:
element(person)
matches
any
element
node
whose
name
is
person
.
element(
ElementName
,
TypeName
)
matches
an
element
node
whose
name
is
ElementName
if
derives-from(
AT
,
TypeName
)
is
true
,
where
AT
is
the
type
annotation
of
the
element
node,
and
the
nilled
property
of
the
node
is
false
.
Example:
element(person,
surgeon)
matches
a
non-nilled
element
node
whose
name
is
person
and
whose
type
annotation
is
surgeon
(or
is
derived
from
surgeon
).
element(
ElementName
,
TypeName
?)
matches
an
element
node
whose
name
is
ElementName
if
derives-from(
AT
,
TypeName
)
is
true
,
where
AT
is
the
type
annotation
of
the
element
node.
The
nilled
property
of
the
node
may
be
either
true
or
false
.
Example:
element(person,
surgeon?)
matches
a
nilled
or
non-nilled
element
node
whose
name
is
person
and
whose
type
annotation
is
surgeon
(or
is
derived
from
surgeon
).
element(*,
TypeName
)
matches
an
element
node
regardless
of
its
name,
if
derives-from(
AT
,
TypeName
)
is
true
,
where
AT
is
the
type
annotation
of
the
element
node,
and
the
nilled
property
of
the
node
is
false
.
Example:
element(*,
surgeon)
matches
any
non-nilled
element
node
whose
type
annotation
is
surgeon
(or
is
derived
from
surgeon
),
regardless
of
its
name.
element(*,
TypeName
?)
matches
an
element
node
regardless
of
its
name,
if
derives-from(
AT
,
TypeName
)
is
true
,
where
AT
is
the
type
annotation
of
the
element
node.
The
nilled
property
of
the
node
may
be
either
true
or
false
.
Example:
element(*,
surgeon?)
matches
any
nilled
or
non-nilled
element
node
whose
type
annotation
is
surgeon
(or
is
derived
from
surgeon
),
regardless
of
its
name.
A SchemaElementTest matches an element node against a corresponding element declaration found in the in-scope element declarations . It takes the following form:
schema-element(
ElementName
)
If the ElementName specified in the SchemaElementTest is not found in the in-scope element declarations , a static error is raised [ err:XPST0008 ].
A SchemaElementTest matches a candidate element node if all three of the following conditions are satisfied:
The name of the candidate node matches the specified ElementName or matches the name of an element in a substitution group headed by an element named ElementName .
derives-from(
AT,
ET
)
is
true
,
where
AT
is
the
type
annotation
of
the
candidate
node
and
ET
is
the
schema
type
declared
for
element
ElementName
in
the
in-scope
element
declarations
.
If
the
element
declaration
for
ElementName
in
the
in-scope
element
declarations
is
not
nillable
,
then
the
nilled
property
of
the
candidate
node
is
false
.
Example:
The
SchemaElementTest
schema-element(customer)
matches
a
candidate
element
node
if
customer
is
a
top-level
element
declaration
in
the
in-scope
element
declarations
,
the
name
of
the
candidate
node
is
customer
or
is
in
a
substitution
group
headed
by
customer
,
the
type
annotation
of
the
candidate
node
is
the
same
as
or
derived
from
the
schema
type
declared
for
the
customer
element,
and
either
the
candidate
node
is
not
nilled
or
customer
is
declared
to
be
nillable
.
An AttributeTest is used to match an attribute node by its name and/or type annotation . An AttributeTest any take any of the following forms. In these forms, AttributeName need not be present in the in-scope attribute declarations , but TypeName must be present in the in-scope schema types [ err:XPST0008 ].
attribute()
and
attribute(*)
match
any
single
attribute
node,
regardless
of
its
name
or
type
annotation.
attribute(
AttributeName
)
matches
any
attribute
node
whose
name
is
AttributeName
,
regardless
of
its
type
annotation.
Example:
attribute(price)
matches
any
attribute
node
whose
name
is
price
.
attribute(
AttributeName
,
TypeName
)
matches
an
attribute
node
whose
name
is
AttributeName
if
derives-from(
AT
,
TypeName
)
is
true
,
where
AT
is
the
type
annotation
of
the
attribute
node.
Example:
attribute(price,
currency)
matches
an
attribute
node
whose
name
is
price
and
whose
type
annotation
is
currency
(or
is
derived
from
currency
).
attribute(*,
TypeName
)
matches
an
attribute
node
regardless
of
its
name,
if
derives-from(
AT
,
TypeName
)
is
true
,
where
AT
is
the
type
annotation
of
the
attribute
node.
Example:
attribute(*,
currency)
matches
any
attribute
node
whose
type
annotation
is
currency
(or
is
derived
from
currency
),
regardless
of
its
name.
A SchemaAttributeTest matches an attribute node against a corresponding attribute declaration found in the in-scope attribute declarations . It takes the following form:
schema-attribute(
AttributeName
)
If the AttributeName specified in the SchemaAttributeTest is not found in the in-scope attribute declarations , a static error is raised [ err:XPST0008 ].
A SchemaAttributeTest matches a candidate attribute node if both of the following conditions are satisfied:
The name of the candidate node matches the specified AttributeName .
derives-from(
AT,
ET
)
is
true
,
where
AT
is
the
type
annotation
of
the
candidate
node
and
ET
is
the
schema
type
declared
for
attribute
AttributeName
in
the
in-scope
attribute
declarations
.
Example:
The
SchemaAttributeTest
schema-attribute(color)
matches
a
candidate
attribute
node
if
color
is
a
top-level
attribute
declaration
in
the
in-scope
attribute
declarations
,
the
name
of
the
candidate
node
is
color
,
and
the
type
annotation
of
the
candidate
node
is
the
same
as
or
derived
from
the
schema
type
declared
for
the
color
attribute.
Given
two
sequence
types
,
it
is
possible
to
determine
if
one
is
a
subtype
of
the
other.
[
Definition
:
A
sequence
type
A
is
a
subtype
of
a
sequence
type
B
if
and
only
if,
for
every
value
V
,
if
V
matches
A
according
to
the
rules
of
SequenceType
matching
,
then
V
also
matches
B
.]
The
subtype
relationship
can
be
computed
using
the
subtype(A,
B)
,
subtype-itemtype(Ai,
Bi)
,
and
derives-from(AT,
ET)
judgements.
The
judgement
subtype(A,
B)
determines
if
the
sequence
type
A
is
a
subtype
of
the
sequence
type
B
.
A
can
either
be
empty-sequence()
or
an
ItemType
,
Ai
,
possibly
followed
by
an
occurrence
indicator.
Similarly
B
can
either
be
empty-sequence()
or
an
ItemType
,
Bi
,
possibly
followed
by
an
occurrence
indicator.
The
result
of
the
subtype(A,
B)
judgement
can
be
determined
from
the
table
below,
which
makes
use
of
the
auxiliary
judgement
subtype-itemtype(Ai,
Bi)
defined
in
2.5.5.2
The
ItemType
Subtype
Judgement
.
Sequence
type
B
| ||||||
---|---|---|---|---|---|---|
empty-sequence()
|
Bi?
|
Bi*
|
Bi
|
Bi+
| ||
Sequence
type
A
|
empty-sequence()
| true | true | true | false | false |
Ai?
| false |
subtype-itemtype(Ai,
Bi)
|
subtype-itemtype(Ai,
Bi)
| false | false | |
Ai*
| false | false |
subtype-itemtype(Ai,
Bi)
| false | false | |
Ai
| false |
subtype-itemtype(Ai,
Bi)
|
subtype-itemtype(Ai,
Bi)
|
subtype-itemtype(Ai,
Bi)
|
subtype-itemtype(Ai,
Bi)
| |
Ai+
| false | false |
subtype-itemtype(Ai,
Bi)
| false |
subtype-itemtype(Ai,
Bi)
|
The
judgement
subtype-itemtype(Ai,
Bi)
determines
if
the
ItemType
Ai
is
a
subtype
of
the
ItemType
Bi
.
Ai
is
a
subtype
of
Bi
if
and
only
if
at
least
one
of
the
following
conditions
applies:
Ai
and
Bi
are
AtomicTypes
,
and
derives-from(Ai,
Bi)
returns
true.
Bi
is
item()
.
Bi
is
node()
,
and
Ai
is
a
KindTest
.
Bi
is
function(*)
,
and
Ai
is
a
FunctionTest
.
Bi
is
text()
and
Ai
is
also
text()
.
Bi
is
comment()
and
Ai
is
also
comment()
.
Bi
is
namespace-node()
and
Ai
is
also
namespace-node()
.
Bi
is
processing-instruction()
and
Ai
is
either
processing-instruction()
or
processing-instruction(N)
for
any
name
N..
Bi
is
processing-instruction(Bn)
,
and
Ai
is
also
processing-instruction(Bn)
.
Bi
is
document-node()
and
Ai
is
either
document-node()
or
document-node(E)
for
any
ElementTest
E.
Bi
is
document-node(Be)
and
Ai
is
document-node(Ae)
,
and
subtype-itemtype(Ae,
Be)
.
Bi
is
either
element()
or
element(*)
,
and
Ai
is
an
ElementTest
.
Bi
is
either
element(Bn)
or
element(Bn,
xs:anyType)
,
and
Ai
is
either
element(Bn)
,
or
element(Bn,
T)
for
any
type
T.
Bi
is
element(Bn,
Bt)
,
Ai
is
element(Bn,
At)
,
and
derives-from(At,
Bt)
returns
true.
Bi
is
element(Bn,
Bt?)
,
Ai
is
either
element(Bn,
At)
,
or
element(Bn,
At?)
,
and
derives-from(At,
Bt)
returns
true.
Bi
is
element(*,
Bt)
,
Ai
is
either
element(*,
At)
,
or
element(N,
At)
for
any
name
N,
and
derives-from(At,
Bt)
returns
true.
Bi
is
element(*,
Bt?)
,
Ai
is
either
element(*,
At)
,
element(*,
At?)
,
element(N,
At)
,
or
element(N,
At?)
for
any
name
N,
and
derives-from(At,
Bt)
returns
true.
Bi
is
schema-element(Bn)
,
Ai
is
schema-element(An)
,
and
either
the
expanded
QName
An
equals
the
expanded
QName
Bn
or
the
element
declaration
named
An
is
in
the
substitution
group
of
the
element
declaration
named
Bn
.
Bi
is
either
attribute()
or
attribute(*)
,
and
Ai
is
an
AttributeTest
.
Bi
is
either
attribute(Bn)
or
attribute(Bn,
xs:anyType)
,
and
Ai
is
either
attribute(Bn)
,
or
attribute(Bn,
T)
for
any
type
T.
Bi
is
attribute(Bn,
Bt)
,
Ai
is
attribute(Bn,
At)
,
and
derives-from(At,
Bt)
returns
true.
Bi
is
attribute(*,
Bt)
,
Ai
is
either
attribute(*,
At)
,
or
attribute(N,
At)
for
any
name
N,
and
derives-from(At,
Bt)
returns
true.
Bi
is
schema-attribute(Bn)
and
Ai
is
also
schema-attribute(Bn)
.
Bi
is
function(Ba_1,
Ba_2,
...
Ba_N)
as
Br
,
Ai
is
function(Aa_1,
Aa_2,
...
Aa_M)
as
Ar
,
N
(arity
of
Bi)
equals
M
(arity
of
Ai),
subtype(Ar,
Br)
,
and
for
values
of
I
between
1
and
N
,
subtype(Ba_I,
Aa_I)
.
|
Comment
|
::= |
"(:"
(
CommentContents
|
Comment
)*
":)"
|
|
CommentContents
|
::= |
(
Char
+
-
(Char*
('(:'
|
':)')
Char*))
|
Comments
may
be
used
to
provide
informative
annotation
for
a
query,
either
in
the
Prolog
or
in
the
Query
Body
.
.
Comments
are
lexical
constructs
only,
and
do
not
affect
query
processing.
Comments
are
strings,
delimited
by
the
symbols
(:
and
:)
.
Comments
may
be
nested.
A comment may be used anywhere ignorable whitespace is allowed (see A.2.4.1 Default Whitespace Handling ).
The following is an example of a comment:
(: Houston, we have a problem :)
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
1.1
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 1.1 Grammar ].
[ Definition : A query consists of one or more modules .] 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 .
|
Expr
|
::= |
ExprSingle
(","
ExprSingle
)*
|
|
ExprSingle
|
::= |
FLWORExpr
|
The XQuery 1.1 operator that has lowest precedence is the comma operator , which is used to combine two operands to form a sequence. As shown in the grammar, a general expression ( Expr ) can consist of multiple ExprSingle operands, separated by commas. 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, context item expressions, constructors, and function calls. A primary expression may also be created by enclosing any expression in parentheses, which is sometimes helpful in controlling the precedence of operators.] Constructors are described in 3.7 Constructors .
|
PrimaryExpr
|
::= |
Literal
|
[161] |
FunctionItemExpr
| ::= |
LiteralFunctionItem
|
InlineFunction
|
[ Definition : A literal is a direct syntactic representation of an atomic value.] XQuery 1.1 supports two kinds of literals: numeric literals and string literals.
|
Literal
|
::= |
NumericLiteral
|
StringLiteral
|
|
NumericLiteral
|
::= |
IntegerLiteral
|
DecimalLiteral
|
DoubleLiteral
|
|
IntegerLiteral
|
::= |
Digits
|
|
DecimalLiteral
|
::= |
("."
Digits
)
|
(
Digits
"."
[0-9]*)
|
|
DoubleLiteral
|
::= |
(("."
Digits
)
|
(
Digits
("."
[0-9]*)?))
[eE]
[+-]?
Digits
|
|
StringLiteral
|
::= |
('"'
(
PredefinedEntityRef
|
CharRef
|
EscapeQuot
|
[^"&])*
'"')
|
("'"
(
PredefinedEntityRef
|
CharRef
|
EscapeApos
|
[^'&])*
"'")
|
|
PredefinedEntityRef
|
::= |
"&"
("lt"
|
"gt"
|
"amp"
|
"quot"
|
"apos")
";"
|
|
Digits
|
::= |
[0-9]+
|
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
.
The
value
of
the
numeric
literal
is
determined
by
casting
it
to
the
appropriate
type
according
to
the
rules
for
casting
from
xs:untypedAtomic
to
a
numeric
type
as
specified
in
Section
17.1.1
Casting
from
xs:string
and
xs:untypedAtomic
FO
.
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.
A string literal may contain a predefined entity reference . [ Definition : A predefined entity reference 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
.
[
Definition
:
A
character
reference
is
an
XML-style
reference
to
a
[Unicode]
character,
identified
by
its
decimal
or
hexadecimal
code
point.]
codepoint.]
For
example,
the
Euro
symbol
(€)
can
be
represented
by
the
character
reference
€
.
Character
references
are
normatively
defined
in
Section
4.1
of
the
XML
specification
(it
is
implementation-defined
whether
the
rules
in
[XML
1.0]
or
[XML
1.1]
apply.)
A
static
error
[
err:XQST0090
]
is
raised
if
a
character
reference
does
not
identify
a
valid
character
in
the
version
of
XML
that
is
in
use.
Here are some examples of literal expressions:
"12.5"
denotes
the
string
containing
the
characters
'1',
'2',
'.',
and
'5'.
12
denotes
the
xs:integer
value
twelve.
12.5
denotes
the
xs:decimal
value
twelve
and
one
half.
125E2
denotes
the
xs: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
xs:string
value
"
Ben
&
Jerry's
".
"€99.50"
denotes
the
xs:string
value
"
€99.50
".
The
xs:boolean
values
true
and
false
can
be
represented
by
calls
to
the
built-in
functions
fn:true()
and
fn:false()
,
respectively.
Values
of
other
atomic
types
can
be
constructed
by
calling
the
constructor
function
for
the
given
type.
The
constructor
functions
for
XML
Schema
built-in
types
are
defined
in
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
.
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.
xs:dayTimeDuration("PT5H")
returns
an
item
whose
type
is
xs:dayTimeDuration
and
whose
value
represents
a
duration
of
five
hours.
Constructor functions can also be used to create special values that have no literal representation, as in the following examples:
xs:float("NaN")
returns
the
special
floating-point
value,
"Not
a
Number."
xs:double("INF")
returns
the
special
double-precision
value,
"positive
infinity."
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
.
|
VarRef
|
::= |
"$"
VarName
|
|
VarName
|
::= |
QName
|
[ Definition : 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 statically known 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.
The in-scope variables may be augmented by implementation-defined variables.
A
variable
may
be
bound
by
an
XQuery
1.1
expression.
The
kinds
of
expressions
that
can
bind
variables
are
FLWOR
expressions
(
3.8
FLWOR
Expressions
),
quantified
expressions
(
3.11
3.12
Quantified
Expressions
),
and
typeswitch
expressions
(
3.12.2
3.14.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:XPST0008 ] 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.
A
reference
to
a
variable
that
was
declared
external
,
but
was
not
bound
to
a
value
by
the
external
environment,
raises
a
dynamic
error
[
err:XPDY0002
].
If a variable reference matches two or more variable 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.
|
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 .
|
ContextItemExpr
|
::= |
"."
|
A
context
item
expression
evaluates
to
the
context
item
,
which
may
be
either
a
node
(as
in
the
expression
fn:doc("bib.xml")/books/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:XPDY0002 ].
[
Definition
:
The
built-in
functions
supported
by
XQuery
1.1
are
defined
in
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
.]
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
.
|
FunctionCall
|
::= |
QName
"("
(
ExprSingle
(","
ExprSingle
)*)?
")"
|
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 a function signature in the static context , a static error is raised [ err:XPST0017 ].
A function call is evaluated as follows:
Argument expressions are 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
either
an
instance
of
the
function's
declared
return
type
or
a
dynamic
error.
Errors
raised
by
built-in
functions
are
defined
in
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
.
If the function is a user-declared function that has a body, 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
type
may
be
derived
from
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
derived
from
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
.
During evaluation of a function body, the static context and dynamic context for expression evaluation are defined by the module in which the function is declared, which is not necessarily the same as the module in which the function is called. For example, the variables in scope while evaluating a function body are defined by in-scope variables of the module that declares the function rather than the module in which the function is called. During evaluation of a function body, the focus (context item, context position, and context size) is undefined, except where it is defined by some expression inside the function body.
If the function is a user-declared external function, its function implementation is invoked with the converted argument values. The result is either a value of the declared type or an implementation-defined error (see 2.2.5 Consistency Constraints ).
[ Definition : 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 sequence type . 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
xs:untypedAtomic
is
cast
to
the
expected
atomic
type.
For
built-in
functions
where
the
expected
type
is
specified
as
numeric
,
arguments
of
type
xs:untypedAtomic
are
cast
to
xs:double
.
For each numeric item in the atomic sequence that can be promoted to the expected atomic type using numeric promotion as described in B.1 Type Promotion , the promotion is done.
For
each
item
of
type
xs:anyURI
in
the
atomic
sequence
that
can
be
promoted
to
the
expected
atomic
type
using
URI
promotion
as
described
in
B.1
Type
Promotion
,
the
promotion
is
done.
If
the
expected
type
is
a
TypedFunctionTest
(possibly
with
an
occurrence
indicator
*
,
+
,
or
?
),
function
item
coercion
is
applied
to
each
function
item
in
the
given
value.
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:XPTY0004 ]. If the function call takes place in a module other than the module in which the function is defined, this rule must be satisfied in both the module where the function is called and the module where the function is defined (the test is repeated because the two modules may have different in-scope schema definitions .) Note that the rules for SequenceType Matching permit a value of a derived type to be substituted 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.
Function item coercion is a transformation applied to function items DM11 during application of the function conversion rules . [ Definition : Function item coercion wraps a function item DM11 in a new inline function with signature the same as the expected type. This effectively delays the checking of the argument and return types until the function item is invoked.]
Function
item
coercion
is
only
defined
to
operate
on
function
items
DM11
.
Given
a
function
item,
$function
,
function
item
coercion
returns
a
new
function
item
with
the
following
properties
(as
defined
in
Section
2.7
Function
Items
DM11
):
An empty set of variable values.
The
name
of
$function
.
A function signature DM11 equal to the expected type for the function argument or return type.
A
new
function,
whose
result
is
calculated
by
invoking
$function
with
the
arguments
that
were
specified
at
the
new
function's
invocation.
If the result of invoking the new function item would necessarily result in a type error, that error may be raised during function coercion. It is implementation dependent whether this happens or not.
These rules have the following consequences:
SequenceType matching of the function item's arguments and result are delayed until that function item is invoked.
The function conversion rules applied to the function item's arguments and result are defined by the SequenceType it has most recently been coerced to. Additional function conversion rules could apply when the wrapped function item is invoked.
If an implementation has static type information about a function item, that can be used to type check the function item's argument and return types during static analysis.
For instance, consider the following query:
declare function local:filter($s as item()*, $p as function(xs:string) as xs:boolean) as item()* { $s[$p(.)] }; let $f := function($a) { starts-with($a, "E") } return local:filter(("Ethel", "Enid", "Gertrude"), $f)
The
function
item
$f
has
a
static
type
of
function(item()*)
as
item()*
.
When
the
local:filter()
function
is
called,
the
following
occurs
to
the
function
item:
The
function
conversion
rules
result
in
applying
function
coercion
to
$function
,
wrapping
$f
in
a
new
inline
function
($p)
with
the
signature
function(xs:string)
as
xs:boolean
.
$p
is
matched
against
the
SequenceType
of
function(xs:string)
as
xs:boolean
,
and
succeeds.
When
$p
is
invoked
inside
the
predicate,
function
conversion
and
SequenceType
matching
rules
are
applied
to
the
context
item
argument,
resulting
in
a
xs:string
value
or
a
type
error.
$f
is
invoked
with
the
xs:string
,
which
returns
a
xs:boolean
.
$p
applies
function
conversion
rules
to
the
result
sequence
from
$f,
which
already
matches
its
declared
return
type
of
xs:boolean
.
The
xs:boolean
is
returned
as
the
result
of
$p.
Note:
Although the semantics of function item coercion are specified in terms of wrapping the function items, static typing will often be able to reduce the number of places where this is actually necessary.
[162] |
LiteralFunctionItem
| ::= |
QName
"#"
IntegerLiteral
|
[ Definition : A literal function item creates a function item DM11 that represents a named function .] [ Definition : A named function is a function defined in the static context for the query. To uniquely identify a particular named function, both its name as a QName and its arity are required.]
If the QName in the literal function item has no namespace prefix, it is considered to be in the default function namespace.
If the expanded QName and arity in a literal function item do not match the name and arity of a function signature in the static context, a static error is raised [ err:XPST0017 ].
The result of a literal function item is a single function item with the following properties (as defined in Section 2.7 Function Items DM11 ):
An empty set of variable values.
The name specified in the literal function item.
The function signature DM11 of the function from the static context that matches the name and arity given.
The function from the static context that matches the name and arity given.
Certain functions in the [XQuery and XPath Functions and Operators 1.1] specification are defined to be polymorphic. These are denoted as accepting parameters of "numeric" type, or returning "numeric" type. Here "numeric" is a pseudonym for the four primitive numeric types xs:decimal, xs:integer, xs:float, and xs:double. The functions in question are:
fn:abs()
fn:ceiling()
fn:floor()
fn:round()
fn:round-half-to-even()
For the purposes of literal function items, these functions are regarded as taking arguments and producing results of type xs:anyAtomicType, with a type error raised at runtime if the argument value provided is not of the correct numeric type.
Note:
The above way of modeling polymorphic functions is semantically backwards compatible with XQuery 1.0. An implementation that supports static typing can choose to model the types of these functions more accurately if desired.
The following are examples of some literal function item expressions:
fn:abs#1
references
the
fn:abs
function
which
takes
a
single
argument.
fn:concat#5
references
the
fn:concat
function
which
takes
5
arguments.
local:myfunc#2
references
a
function
named
local:myfunc
which
takes
2
arguments.
[163] |
InlineFunction
| ::= |
"function"
"("
ParamList
?
")"
("as"
SequenceType
)?
EnclosedExpr
|
[ Definition : An inline function expression creates a function item DM11 that represents an anonymous function defined directly in the inline function expression itself.] An inline function specifies the names and SequenceTypes of the parameters to the function, the SequenceType of the result, and the body of the function.
If a function parameter is declared using a name but no type, its default type is item()*. If the result type 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 a static error [ err:XQST0039 ] for a function declaration to have more than one parameter with the same name.
The static context for the function body is inherited from the location of the inline function expression, with the exception of the static type of the context item which is initially undefined.
The variables in scope for the function body include all variables representing the function parameters, as well as all variables that are in scope for the inline function expression.
Note:
Function parameter names can mask variables that would otherwise be in scope for the function body.
The result of an inline function is a single function item with the following properties (as defined in Section 2.7 Function Items DM11 ):
The set of variable values for any variables referenced by the inline function's body.
An absent name.
The function signature DM11 of the inline function.
The inline function itself.
The following are examples of some inline functions:
This example creates an inline function that takes no arguments and returns a sequence of the first 6 primes:
function() as xs:integer+ { 2, 3, 5, 7, 11, 13 }
This example creates an inline function that takes two xs:double arguments and returns their product:
function($a as xs:double, $b as xs:double) as xs:double { $a * $b }
This example creates an inline function that returns its item()* argument:
function($a) { $a }
This example creates an inline function that returns the xs:integer value 7, i.e.: the value of the variable $a from the scope of the inline function expression:
let $a := 7 return let $f := function() { $a } return let $a := 8 return $f()
[121] |
FilterExpr
| ::= |
PrimaryExpr
(
Predicate
|
DynamicFunctionInvocation
)*
|
[164] |
DynamicFunctionInvocation
| ::= |
"("
(
ExprSingle
(","
ExprSingle
)*)?
")"
|
[ Definition : A dynamic function invocation invokes DM11 a function item DM11 , calling the function it represents.] A dynamic function invocation consists of an expression that returns the function item and a parenthesized list of zero or more arguments.
If the function item expression does not return a sequence consisting of a single function item with the same arity as the number of specified arguments, a type error is raised [ err:XPTY0004 ].
A dynamic function invocation is evaluated as follows:
Argument values are calculated for the function item using rules 1 and 2 for evaluation of a function call as defined in 3.1.5 Function Calls .
The set of variable values from the function item's closure are added to the dynamic context with a scope of the invocation of the function.
The function from the function item is evaluated using the argument values according to rules 3 - 5 for evaluation of a function call as defined in 3.1.5 Function Calls .
Note:
These rules are derived from the rules for function calls defined in 3.1.5 Function Calls except for the addition of a rule to deal with the use of the variable values from the closure.
The following are examples of some dynamic function invocations:
This example invokes the function item contained in $f, passing the arguments 2 and 3:
$f(2, 3)
This example fetches the second item from sequence $f, treats it as a function item and invokes it, passing a xs:string argument:
$f[2]("Hi there")
This example invokes the function item $f passing no arguments, and filters the result with a positional predicate:
$f()[2]
|
PathExpr
|
::= |
("/"
RelativePathExpr
?)
|
|
RelativePathExpr
|
::= |
StepExpr
(("/"
|
"//")
StepExpr
)*
|
[
Definition
:
A
path
expression
can
be
used
to
locate
nodes
within
trees.
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 .
A
"
/
"
at
the
beginning
of
a
path
expression
is
an
abbreviation
for
the
initial
step
(however,
if
the
"
fn:root(self::node())
(fn:root(self::node())
treat
as
document-node()/
document-node())
/
/
"
is
the
entire
path
expression,
the
trailing
"
/
"
is
omitted
from
the
expansion.)
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:XPTY0020
].
At
evaluation
time,
if
the
root
node
above
the
context
node
is
not
a
document
node,
a
dynamic
error
is
raised
[
err:XPDY0050
].
A
"
//
"
at
the
beginning
of
a
path
expression
is
an
abbreviation
for
the
initial
steps
(however,
"
fn:root(self::node())
(fn:root(self::node())
treat
as
document-node()/descendant-or-self::node()/
document-node())
/descendant-or-self::node()/
//
"
by
itself
is
not
a
valid
path
expression
[
err:XPST0003
].)
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
from
this
root.
This
node
sequence
is
used
as
the
input
to
subsequent
steps
in
the
path
expression.
If
the
context
item
is
not
a
node,
a
type
error
is
raised
[
err:XPTY0020
].
At
evaluation
time,
if
the
root
node
above
the
context
node
is
not
a
document
node,
a
dynamic
error
is
raised
[
err:XPDY0050
].
Note:
The descendants of a node do not include attribute nodes .
Each
non-initial
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
(possibly
empty)
sequence
of
nodes,
a
type
error
is
raised
[
err:XPTY0019
].
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
.
The
sequences
resulting
from
all
the
evaluations
of
E2
are
combined
as
follows:
If
every
evaluation
of
E2
returns
a
(possibly
empty)
sequence
of
nodes,
these
sequences
are
combined,
and
duplicate
nodes
are
eliminated
based
on
node
identity.
If
ordering
mode
is
ordered
,
the
resulting
node
sequence
is
returned
in
document
order
;
otherwise
it
is
returned
in
implementation-dependent
order.
If
every
evaluation
of
E2
returns
a
(possibly
empty)
sequence
of
atomic
values,
non-nodes,
these
sequences
are
concatenated
and
returned.
If
ordering
mode
is
ordered
,
the
returned
sequence
preserves
the
orderings
within
and
among
the
subsequences
generated
by
the
evaluations
of
E2
;
otherwise
the
order
of
the
returned
sequence
is
implementation-dependent
.
If
the
multiple
evaluations
of
E2
return
at
least
one
node
and
at
least
one
atomic
value,
non-node,
a
type
error
is
raised
[
err:XPTY0018
].
Note:
Since
each
step
in
a
path
provides
context
nodes
for
the
following
step,
in
effect,
only
the
last
step
in
a
path
is
allowed
to
return
a
sequence
of
atomic
values.
non-nodes.
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.
Note:
The
"
/
"
character
can
be
used
either
as
a
complete
path
expression
or
as
the
beginning
of
a
longer
path
expression
such
as
"
/*
".
Also,
"
*
"
is
both
the
multiply
operator
and
a
wildcard
in
path
expressions.
This
can
cause
parsing
difficulties
when
"
/
"
appears
on
the
left
hand
side
of
"
*
".
This
is
resolved
using
the
leading-lone-slash
constraint.
For
example,
"
/*
"
and
"
/
*
"
are
valid
path
expressions
containing
wildcards,
but
"
/*5
"
and
"
/
*
5
"
raise
syntax
errors.
Parentheses
must
be
used
when
"
/
"
is
used
on
the
left
hand
side
of
an
operator,
as
in
"
(/)
*
5
".
Similarly,
"
4
+
/
*
5
"
raises
a
syntax
error,
but
"
4
+
(/)
*
5
"
is
a
valid
expression.
The
expression
"
4
+
/
"
is
also
valid,
because
/
does
not
occur
on
the
left
hand
side
of
the
operator.
|
StepExpr
|
::= |
FilterExpr
|
AxisStep
|
|
AxisStep
|
::= |
(
ReverseStep
|
ForwardStep
)
PredicateList
|
|
ForwardStep
|
::= |
(
ForwardAxis
NodeTest
)
|
AbbrevForwardStep
|
|
ReverseStep
|
::= |
(
ReverseAxis
NodeTest
)
|
AbbrevReverseStep
|
|
PredicateList
|
::= |
Predicate
*
|
[ Definition : A step is a part of a path expression that 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, working from left to right. A step may be either an axis step or a filter expression .] Filter expressions are described in 3.3.2 Filter Expressions .
[
Definition
:
An
axis
step
returns
a
sequence
of
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
annotation
.]
If
the
context
item
is
a
node,
an
axis
step
returns
a
sequence
of
zero
or
more
nodes;
otherwise,
a
type
error
is
raised
[
err:XPTY0020
].
If
ordering
mode
is
ordered
,
the
resulting
node
sequence
is
returned
in
document
order
;
otherwise
it
is
returned
in
implementation-dependent
order.
An
axis
step
may
be
either
a
forward
step
or
a
reverse
step
,
followed
by
zero
or
more
predicates
.
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
annotation
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
.
XQuery
supports
the
following
axes
(subject
to
limitations
as
described
in
5.2.4
Full
Axis
Feature
):
axes:
The
child
axis
contains
the
children
of
the
context
node,
which
are
the
nodes
returned
by
the
dm:children
accessor
in
[XQuery/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
.
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 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/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
,
which
returns
the
parent
of
the
context
node,
or
an
empty
sequence
if
the
context
node
has
no
parent
Note:
An attribute node may have an element node as its parent, even though the attribute node is not a child of the element node.
the
ancestor
axis
is
defined
as
the
transitive
closure
of
the
parent
axis;
it
contains
the
ancestors
of
the
context
node
(the
parent,
the
parent
of
the
parent,
and
so
on)
Note:
The ancestor axis includes the root node of the tree in which the context node is found, unless the context node is the root node.
the
following-sibling
axis
contains
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,
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,
the
preceding-sibling
axis
is
empty
the
following
axis
contains
all
nodes
that
are
descendants
of
the
root
of
the
tree
in
which
the
context
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
node
is
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/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
;
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
nodes):
they
do
not
overlap
and
together
they
contain
all
the
nodes
in
the
document.
[ Definition : 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.
[ Definition : 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, or processing instruction), the name of the node, or (in the case of element, attribute, and document nodes), the type annotation of the node.
|
NodeTest
|
::= |
KindTest
|
NameTest
|
|
NameTest
|
::= |
QName
|
Wildcard
|
|
Wildcard
|
::= |
"*"
|
[
Definition
:
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
for
the
step
axis
and
the
expanded
QName
of
the
node
is
equal
(as
defined
by
the
eq
operator)
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 resolved into an expanded QName using the statically known namespaces in the expression context. It is a static error [ err:XPST0081 ] if the QName has a prefix that does not correspond to any statically known namespace. An unprefixed QName, when used as a name test on an axis whose principal node kind is element, has the namespace URI of 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 expanded 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
of
the
step
axis.
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
statically
known
namespaces
in
the
static
context
.
If
the
prefix
is
not
found
in
the
statically
known
namespaces,
a
static
error
is
raised
[
err:XPST0081
].
The
node
test
is
true
for
any
node
of
the
principal
node
kind
of
the
step
axis
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
of
the
step
axis
whose
local
name
matches
the
given
NCName,
regardless
of
its
namespace
or
lack
of
a
namespace.
[ Definition : An alternative form of a node test called a kind test can select nodes based on their kind, name, and type annotation .] The syntax and semantics of a kind test are described in 2.5.3 SequenceType Syntax and 2.5.4 SequenceType Matching . When a kind test is used in a node test , only those nodes on the designated axis that match the kind test are selected. Shown below are several examples of kind tests that might be used in path expressions:
node()
matches
any
node.
text()
matches
any
text
node.
comment()
matches
any
comment
node.
namespace-node()
matches
any
namespace
node.
element()
matches
any
element
node.
schema-element(person)
matches
any
element
node
whose
name
is
person
(or
is
in
the
substitution
group
headed
by
person
),
and
whose
type
annotation
is
the
same
as
(or
is
derived
from)
the
declared
type
of
the
person
element
in
the
in-scope
element
declarations
.
element(person)
matches
any
element
node
whose
name
is
person
,
regardless
of
its
type
annotation.
element(person,
surgeon)
matches
any
non-nilled
element
node
whose
name
is
person
,
and
whose
type
annotation
is
surgeon
or
is
derived
from
surgeon
.
element(*,
surgeon)
matches
any
non-nilled
element
node
whose
type
annotation
is
surgeon
(or
is
derived
from
surgeon
),
regardless
of
its
name.
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
(or
is
derived
from
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
kind
test
element(book)
,
interleaved
with
zero
or
more
comments
and
processing
instructions.
|
FilterExpr
|
::= |
PrimaryExpr
(
Predicate
|
DynamicFunctionInvocation
)*
|
[123] |
Predicate
|
::= |
"["
Expr
"]"
|
[ Definition : 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.] In the case of multiple adjacent predicates, the predicates are applied from left to right, and the result of applying each predicate serves as the input sequence for the following predicate.
For each item in the input sequence, the predicate expression is evaluated using an inner focus , defined as follows: The context item is the item currently being tested against the predicate. The context size is the number of items in the input sequence. The context position is the position of the context item within the input sequence. For the purpose of evaluating the context position within a predicate, the input sequence is considered to be sorted as follows: into document order if the predicate is in a forward-axis step, into reverse document order if the predicate is in a reverse-axis step, or in its original order if the predicate is not in a step.
For
each
item
in
the
input
sequence,
the
result
of
the
predicate
expression
is
coerced
to
an
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
a
singleton
atomic
value
of
a
numeric
type
or
derived
from
a
numeric
type,
the
predicate
truth
value
is
true
if
the
value
of
the
predicate
expression
is
equal
(by
the
eq
operator)
to
the
context
position
,
and
is
false
otherwise.
[
Definition
:
A
predicate
whose
predicate
expression
returns
a
numeric
type
is
called
a
numeric
predicate
.]
Note:
In
a
region
of
a
query
where
ordering
mode
is
unordered
,
the
result
of
a
numeric
predicate
is
nondeterministic,
as
explained
in
3.9
Ordered
and
Unordered
Expressions
.
Otherwise, the predicate truth value is the effective boolean value of 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
that
are
elements
named
"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
both
a
secretary
child
element
and
an
assistant
child
element:
child::employee[secretary][assistant]
Note:
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
qualifying
foo
element
in
reverse
document
order
,
because
the
predicate
is
part
of
an
axis
step
using
a
reverse
axis.
By
contrast,
(preceding::foo)[1]
returns
the
first
qualifying
foo
element
in
document
order
,
because
the
parentheses
cause
(preceding::foo)
to
be
parsed
as
a
primary
expression
in
which
context
positions
are
assigned
in
document
order.
Similarly,
ancestor::*[1]
returns
the
nearest
ancestor
element,
because
the
ancestor
axis
is
a
reverse
axis,
whereas
(ancestor::*)[1]
returns
the
root
element
(first
ancestor
in
document
order).
The fact that a reverse-axis step assigns context positions in reverse document order for the purpose of evaluating predicates does not alter the fact that the final result of the step (when in ordered mode) is always in document order.
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.
Note
that
no
attribute
nodes
are
returned,
because
attributes
are
not
children.
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
returns
an
empty
sequence
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
tree
that
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
eq
"warning"]
selects
all
para
children
of
the
context
node
that
have
a
type
attribute
with
value
warning
child::para[attribute::type
eq
'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
eq
"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
value
is
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
|
AbbrevForwardStep
|
::= |
"@"?
NodeTest
|
|
AbbrevReverseStep
|
::= |
".."
|
The abbreviated syntax permits the following abbreviations:
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
.
If
the
axis
name
is
omitted
from
an
axis
step
,
the
default
axis
is
child
unless
the
axis
step
contains
an
AttributeTest
or
SchemaAttributeTest
;
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
is
an
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
.
Each
non-initial
occurrence
of
//
is
effectively
replaced
by
/descendant-or-self::node()/
during
processing
of
a
path
expression.
For
example,
div1//para
is
short
for
child::div1/descendant-or-self::node()/child::para
and
so
will
select
all
para
descendants
of
div1
children.
Note:
The
path
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
respective
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
value
is
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
1.1
supports
operators
to
construct,
filter,
and
combine
sequences
of
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)
.
|
Expr
|
::= |
ExprSingle
(","
ExprSingle
)*
|
|
RangeExpr
|
::= |
AdditiveExpr
(
"to"
AdditiveExpr
)?
|
[ Definition : One way to construct a sequence is by using the comma operator , which evaluates each of its operands and concatenates the resulting sequences, in order, into a single result sequence.] Empty parentheses can be used to denote an empty sequence.
A sequence may contain duplicate atomic 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.
Note:
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.
Here are some examples of expressions that construct sequences:
The result of this 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
a
single
sequence
of
length
five.
The
result
of
this
expression
is
the
sequence
10,
1,
2,
3,
4
.
(10, (1, 2), (), (3, 4))
The
result
of
this
expression
is
a
sequence
containing
all
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
expression
is
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?
.
If
either
operand
is
an
empty
sequence,
or
if
the
integer
derived
from
the
first
operand
is
greater
than
the
integer
derived
from
the
second
operand,
the
result
of
the
range
expression
is
an
empty
sequence.
If
the
two
operands
convert
to
the
same
integer,
the
result
of
the
range
expression
is
that
integer.
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
sequence
10,
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 is a 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
the
sequence
15,
14,
13,
12,
11,
10
.
fn:reverse(10 to 15)
|
FilterExpr
|
::= |
PrimaryExpr
|
|
PredicateList
|
::= |
Predicate
*
|
[ Definition : A filter expression consists simply of a primary expression followed by zero or more predicates . The result of the filter expression consists of the items returned by the primary expression, filtered by applying each predicate in turn, working from left to right.] If no predicates are specified, the result is simply the result of the primary expression. The ordering of the items returned by a filter expression 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.
Here are some examples of filter expressions:
Given a sequence of products in a variable, return only those products whose price is greater than 100.
$products[price gt 100]
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]
The
following
example
returns
the
fifth
through
ninth
items
in
the
sequence
bound
to
variable
$orders
.
$orders[fn:position() = (5 to 9)]
The
following
example
illustrates
the
use
of
a
filter
expression
as
a
step
in
a
path
expression
.
It
returns
the
last
chapter
or
appendix
within
the
book
bound
to
variable
$book
:
$book/(chapter | appendix)[fn:last()]
The
following
example
also
illustrates
the
use
of
a
filter
expression
as
a
step
in
a
path
expression
.
It
returns
the
element
node
within
the
specified
document
whose
ID
value
is
tiger
:
fn:doc("zoo.xml")/fn:id('tiger')
|
UnionExpr
|
::= |
IntersectExceptExpr
(
("union"
|
"|")
IntersectExceptExpr
)*
|
|
IntersectExceptExpr
|
::= |
InstanceofExpr
(
("intersect"
|
"except")
InstanceofExpr
)*
|
XQuery 1.1 provides the following 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
these
operators
eliminate
duplicate
nodes
from
their
result
sequences
based
on
node
identity.
If
ordering
mode
is
ordered
,
the
resulting
sequence
is
returned
in
document
order
;
otherwise
it
is
returned
in
implementation-dependent
order.
If
an
operand
of
union
,
intersect
,
or
except
contains
an
item
that
is
not
a
node,
a
type
error
is
raised
[
err:XPTY0004
].
If an IntersectExceptExpr contains more than two InstanceofExprs, they are grouped from left to right. With a UnionExpr, it makes no difference how operands are grouped, the results are the same.
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]
Operators
1.1]
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
items
from
a
sequence.
XQuery 1.1 provides arithmetic operators for addition, subtraction, multiplication, division, and modulus, in their usual binary and unary forms.
|
AdditiveExpr
|
::= |
MultiplicativeExpr
(
("+"
|
"-")
MultiplicativeExpr
)*
|
|
MultiplicativeExpr
|
::= |
UnionExpr
(
("*"
|
"div"
|
"idiv"
|
"mod")
UnionExpr
)*
|
|
UnaryExpr
|
::= |
("-"
|
"+")*
ValueExpr
|
|
ValueExpr
|
::= |
ValidateExpr
|
PathExpr
|
ExtensionExpr
|
A
subtraction
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
expressions.
(See
A.2.4
Whitespace
Rules
for
further
details
on
whitespace
handling.)
If an AdditiveExpr contains more than two MultiplicativeExprs, they are grouped from left to right. So, for instance,
A - B + C - D
is equivalent to
((A - B) + C) - D
Similarly, the operands of a MultiplicativeExpr are grouped from left to right.
The first step in evaluating an arithmetic expression is to evaluate its operands. The order in which the operands are evaluated is implementation-dependent .
Each operand is evaluated by applying the following steps, in order:
Atomization is applied to the operand. The result of this operation is called the atomized operand .
If the atomized operand is an empty sequence, the result of the arithmetic expression is an empty sequence, and the implementation need not evaluate the other operand or apply the operator. However, an implementation may choose to evaluate the other operand in order to determine whether it raises an error.
If the atomized operand is a sequence of length greater than one, a type error is raised [ err:XPTY0004 ].
If
the
atomized
operand
is
of
type
xs:untypedAtomic
,
it
is
cast
to
xs:double
.
If
the
cast
fails,
a
dynamic
error
is
raised.
[err:FORG0001]
After
evaluation
of
the
operands,
if
the
types
of
the
operands
are
a
valid
combination
for
the
given
arithmetic
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
operator
functions
that
define
the
semantics
of
the
operator
for
each
type
combination,
including
the
dynamic
errors
that
can
be
raised
by
the
operator.
The
definitions
of
the
operator
functions
are
found
in
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
.
If the types of the operands, after evaluation, are not a valid combination for the given operator, according to the rules in B.2 Operator Mapping , a type error is raised [ err:XPTY0004 ].
XQuery
1.1
supports
two
division
operators
named
div
and
idiv
.
Each
of
these
operators
accepts
two
operands
of
any
numeric
type.
As
described
in
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
,
$arg1
idiv
$arg2
is
equivalent
to
($arg1
div
$arg2)
cast
as
xs:integer?
except
for
error
cases.
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
xs: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)
Note:
Multiple
consecutive
unary
arithmetic
operators
are
permitted
by
XQuery
1.1
for
compatibility
with
[XPath
[XML
Path
Language
(XPath)
Version
1.0]
.
Comparison expressions allow two values to be compared. XQuery 1.1 provides three kinds of comparison expressions, called value comparisons, general comparisons, and node comparisons.
|
ComparisonExpr
|
::= |
RangeExpr
(
(
ValueComp
|
|
ValueComp
|
::= |
"eq"
|
"ne"
|
"lt"
|
"le"
|
"gt"
|
"ge"
|
|
GeneralComp
|
::= |
"="
|
"!="
|
"<"
|
"<="
|
">"
|
">="
|
|
NodeComp
|
::= |
"is"
|
"<<"
|
">>"
|
The
value
comparison
operators
are
eq
,
ne
,
lt
,
le
,
gt
,
and
ge
.
Value
comparisons
are
used
for
comparing
single
values.
The first step in evaluating a value comparison is to evaluate its operands. The order in which the operands are evaluated is implementation-dependent . Each operand is evaluated by applying the following steps, in order:
Atomization is applied to the operand. The result of this operation is called the atomized operand .
If the atomized operand is an empty sequence, the result of the value comparison is an empty sequence, and the implementation need not evaluate the other operand or apply the operator. However, an implementation may choose to evaluate the other operand in order to determine whether it raises an error.
If the atomized operand is a sequence of length greater than one, a type error is raised [ err:XPTY0004 ].
If
the
atomized
operand
is
of
type
xs:untypedAtomic
,
it
is
cast
to
xs:string
.
Note:
The
purpose
of
this
rule
is
to
make
value
comparisons
transitive.
Users
should
be
aware
that
the
general
comparison
operators
have
a
different
rule
for
casting
of
xs:untypedAtomic
operands.
Users
should
also
be
aware
that
transitivity
of
value
comparisons
may
be
compromised
by
loss
of
precision
during
type
conversion
(for
example,
two
xs:integer
values
that
differ
slightly
may
both
be
considered
equal
to
the
same
xs:float
value
because
xs:float
has
less
precision
than
xs:integer
).
Next,
if
possible,
the
two
operands
are
converted
to
their
least
common
type
by
a
combination
of
type
promotion
and
subtype
substitution
.
For
example,
if
the
operands
are
of
type
hatsize
(derived
from
xs:integer
)
and
shoesize
(derived
from
xs:float
),
their
least
common
type
is
xs:float
.
Finally,
if
the
types
of
the
operands
are
a
valid
combination
for
the
given
operator,
the
operator
is
applied
to
the
operands.
The
combinations
of
atomic
types
that
are
accepted
by
the
various
value
comparison
operators,
and
their
respective
result
types,
are
listed
in
B.2
Operator
Mapping
together
with
the
operator
functions
that
define
the
semantics
of
the
operator
for
each
type
combination.
The
definitions
of
the
operator
functions
are
found
in
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
.
Informally,
if
both
atomized
operands
consist
of
exactly
one
atomic
value,
then
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
.
If the types of the operands, after evaluation, are not a valid combination for the given operator, according to the rules in B.2 Operator Mapping , a type error is raised [ err:XPTY0004 ].
Here are some examples of value comparisons:
The
following
comparison
atomizes
the
node(s)
that
are
returned
by
the
expression
$book/author
.
The
comparison
is
true
only
if
the
result
of
atomization
is
the
value
"Kennedy"
as
an
instance
of
xs:string
or
xs:untypedAtomic
.
If
the
result
of
atomization
is
an
empty
sequence,
the
result
of
the
comparison
is
an
empty
sequence.
If
the
result
of
atomization
is
a
sequence
containing
more
than
one
value,
a
type
error
is
raised
[
err:XPTY0004
].
$book1/author eq "Kennedy"
The
following
path
expression
contains
a
predicate
that
selects
products
whose
weight
is
greater
than
100.
For
any
product
that
does
not
have
a
weight
subelement,
the
value
of
the
predicate
is
the
empty
sequence,
and
the
product
is
not
selected.
This
example
assumes
that
weight
is
a
validated
element
with
a
numeric
type.
//product[weight gt 100]
The following comparisons are true because, in each case, 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
following
comparison
is
true.
The
eq
operator
compares
two
QNames
by
performing
codepoint-comparisons
of
their
namespace
URIs
and
their
local
names,
ignoring
their
namespace
prefixes.
fn:QName("http://example.com/ns1", "this:color") eq fn:QName("http://example.com/ns1", "that:color")
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
.
A general comparison is evaluated by applying the following rules, in order:
Atomization is applied to each operand. After atomization, each operand is a sequence of atomic values.
The
result
of
the
comparison
is
true
if
and
only
if
there
is
a
pair
of
atomic
values,
one
in
the
first
operand
sequence
and
the
other
in
the
second
operand
sequence,
that
have
the
required
magnitude
relationship
.
Otherwise
the
result
of
the
comparison
is
false
.
The
magnitude
relationship
between
two
atomic
values
is
determined
by
applying
the
following
rules.
If
a
cast
operation
called
for
by
these
rules
is
not
successful,
a
dynamic
error
is
raised.
[err:FORG0001]
Note:
The
purpose
of
these
rules
is
to
preserve
compatibility
with
XPath
1.0,
in
which
(for
example)
x
<
17
is
a
numeric
comparison
if
x
is
an
untyped
value.
Users
should
be
aware
that
the
value
comparison
operators
have
different
rules
for
casting
of
xs:untypedAtomic
operands.
If
one
of
the
both
atomic
values
is
an
instance
are
instances
of
xs:untypedAtomic
,
then
the
and
the
other
is
an
instance
of
a
numeric
type,
xs:untypedAtomic
value
is
values
are
cast
to
the
type
.
xs:double
xs:string
If
exactly
one
of
the
atomic
values
is
an
instance
of
xs:untypedAtomic
,
it
is
cast
to
a
type
depending
on
the
other
value's
dynamic
type
T
according
to
the
following
rules,
in
which
V
denotes
the
value
to
be
cast:
and
If
T
is
an
instance
of
a
numeric
type
or
is
derived
from
a
numeric
type,
then
V
is
cast
to
.xs:untypedAtomic
xs:double
If
T
is
xs:dayTimeDuration
or
is
derived
from
,
then
xs:string
xs:dayTimeDuration
the
xs:untypedAtomic
value
(or
values)
V
is
(are)
cast
to
the
type
.
xs:string
xs:dayTimeDuration
If
one
of
the
atomic
values
T
is
an
instance
of
xs:untypedAtomic
xs:yearMonthDuration
and
the
other
or
is
not
an
instance
of
xs:string
,
derived
from
,
xs:untypedAtomic
xs:yearMonthDuration
or
any
numeric
type,
then
the
V
is
cast
to
.xs:untypedAtomic
value
xs:yearMonthDuration
In
all
other
cases,
V
is
cast
to
the
dynamic
primitive
base
type
of
T.
Note:
The
special
treatment
of
the
other
value.
duration
types
is
required
to
avoid
errors
that
may
arise
when
comparing
the
primitive
type
xs:duration
with
any
duration
type.
After
performing
the
conversions
described
above,
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
and
only
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
that
have
the
required
magnitude
relationship
.
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
or
xs: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)
The
following
example
contains
two
general
comparisons,
both
of
which
are
true
.
This
example
illustrates
the
fact
that
the
=
and
!=
operators
are
not
inverses
of
each
other.
(1, 2) = (2, 3) (1, 2) != (2, 3)
Suppose
that
$a
,
$b
,
and
$c
are
bound
to
element
nodes
with
type
annotation
xs: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 the following rules:
The operands of a node comparison are evaluated in implementation-dependent order.
If either operand is an empty sequence, the result of the comparison is an empty sequence, and the implementation need not evaluate the other operand or apply the operator. However, an implementation may choose to evaluate the other operand in order to determine whether it raises an error.
Each operand must be either a single node or an empty sequence; otherwise a type error is raised [ err:XPTY0004 ].
A
comparison
with
the
is
operator
is
true
if
the
two
operand
nodes
have
the
same
identity,
and
are
thus
the
same
node;
otherwise
it
is
false
.
See
[XQuery/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
for
a
definition
of
node
identity.
A
comparison
with
the
<<
operator
returns
true
if
the
left
operand
node
precedes
the
right
operand
node
in
document
order
;
otherwise
it
returns
false
.
A
comparison
with
the
>>
operator
returns
true
if
the
left
operand
node
follows
the
right
operand
node
in
document
order
;
otherwise
it
returns
false
.
Here are some examples of node comparisons:
The following comparison is true only if the left and right sides each evaluate to exactly the same single node:
/books/book[isbn="1558604820"] is /books/book[call="QA76.9 C3845"]
The following comparison 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:
/transactions/purchase[parcel="28-451"] << /transactions/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
.
|
OrExpr
|
::= |
AndExpr
(
"or"
AndExpr
)*
|
|
AndExpr
|
::= |
ComparisonExpr
(
"and"
ComparisonExpr
)*
|
The first step in evaluating a logical expression is to find the effective boolean value of each of its operands (see 2.4.3 Effective Boolean Value ).
The value of an and-expression is determined by the effective boolean values (EBV's) of its operands, as shown in the following table:
AND: |
EBV
2
=
true
|
EBV
2
=
false
|
error in EBV 2 |
EBV
1
=
true
|
true
|
false
|
error |
EBV
1
=
false
|
false
|
false
|
either
false
or
error
|
error in EBV 1 | error |
either
false
or
error
|
error |
The value of an or-expression is determined by the effective boolean values (EBV's) of its operands, as shown in the following table:
OR: |
EBV
2
=
true
|
EBV
2
=
false
|
error in EBV 2 |
EBV
1
=
true
|
true
|
true
|
either
true
or
error
|
EBV
1
=
false
|
true
|
false
|
error |
error in EBV 1 |
either
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
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
1.1
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]
Operators
1.1]
.
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
the
same
error.
XQuery provides constructors that can create XML structures within a query. Constructors are provided for element, attribute, document, text, comment, and processing instruction nodes. Two kinds of constructors are provided: direct constructors , which use an XML-like notation, and computed constructors , which use a notation based on enclosed expressions.
|
Constructor
|
::= |
DirectConstructor
|
|
DirectConstructor
|
::= |
DirElemConstructor
|
|
DirElemConstructor
|
::= |
"<"
QName
DirAttributeList
("/>"
|
(">"
DirElemContent
*
"</"
QName
S
?
">"))
|
|
DirElemContent
|
::= |
DirectConstructor
|
|
ElementContentChar
|
::= |
Char
-
[{}<&]
|
|
CommonContent
|
::= |
PredefinedEntityRef
|
CharRef
|
"{{"
|
"}}"
|
EnclosedExpr
|
|
CDataSection
|
::= |
"<![CDATA["
CDataSectionContents
"]]>"
|
|
CDataSectionContents
|
::= |
(
Char
*
-
(Char*
']]>'
Char*))
|
|
DirAttributeList
|
::= |
(
S
(
QName
S
?
"="
S
?
DirAttributeValue
)?)*
|
|
DirAttributeValue
|
::= |
('"'
(
EscapeQuot
|
QuotAttrValueContent
)*
'"')
|
|
QuotAttrValueContent
|
::= |
QuotAttrContentChar
|
|
AposAttrValueContent
|
::= |
AposAttrContentChar
|
|
QuotAttrContentChar
|
::= |
Char
-
["{}<&]
|
|
AposAttrContentChar
|
::= |
Char
-
['{}<&]
|
|
EscapeQuot
|
::= |
'""'
|
|
EscapeApos
|
::= |
"''"
|
|
EnclosedExpr
|
::= |
"{"
Expr
"}"
|
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
element
node.
[
Definition
:
A
direct
element
constructor
is
a
form
of
element
constructor
in
which
the
name
of
the
constructed
element
is
a
constant.]
Direct
element
constructors
are
based
on
standard
XML
notation.
For
example,
the
following
expression
is
a
direct
element
constructor
that
creates
a
book
element
containing
an
attribute
and
some
nested
elements:
<book isbn="isbn-0060229357"> <title>Harold and the Purple Crayon</title> <author> <first>Crockett</first> <last>Johnson</last> </author> </book>
If
the
element
name
in
a
direct
element
constructor
has
a
namespace
prefix,
the
namespace
prefix
is
resolved
to
a
namespace
URI
using
the
statically
known
namespaces
.
If
the
element
name
has
no
namespace
prefix,
it
is
implicitly
qualified
by
the
default
element/type
namespace
.
Note
that
both
the
statically
known
namespaces
and
the
default
element/type
namespace
may
be
affected
by
namespace
declaration
attributes
found
inside
the
element
constructor.
The
namespace
prefix
of
the
element
name
is
retained
after
expansion
of
the
QName,
as
described
in
[XQuery/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
.
The
resulting
expanded
QName
becomes
the
node-name
property
of
the
constructed
element
node.
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, as illustrated by the following example:
<example> <p> Here is a query. </p> <eg> $b/title </eg> <p> Here is the result of the query. </p> <eg>{ $b/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> $b/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
"
}
".)
Alternatively,
the
character
references
{
and
}
can
be
used
to
denote
curly
brace
characters.
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:XPST0003
].
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 are copies of existing nodes.
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. However, note that namespace declaration attributes (see 3.7.1.2 Namespace Declaration Attributes ) do not create attribute nodes.
If
an
attribute
name
has
a
namespace
prefix,
the
prefix
is
resolved
to
a
namespace
URI
using
the
statically
known
namespaces
.
If
the
attribute
name
has
no
namespace
prefix,
the
attribute
is
in
no
namespace.
Note
that
the
statically
known
namespaces
used
in
resolving
an
attribute
name
may
be
affected
by
namespace
declaration
attributes
that
are
found
inside
the
same
element
constructor.
The
namespace
prefix
of
the
attribute
name
is
retained
after
expansion
of
the
QName,
as
described
in
[XQuery/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
.
The
resulting
expanded
QName
becomes
the
node-name
property
of
the
constructed
attribute
node.
If
the
attributes
in
a
direct
element
constructor
do
not
have
distinct
expanded
QNames
as
their
respective
node-name
properties,
a
static
error
is
raised
[
err:XQST0040
].
Conceptually, an attribute (other than a namespace declaration attribute) in a direct element constructor is processed by the following steps:
Each
consecutive
sequence
of
literal
characters
in
the
attribute
content
is
treated
as
a
string
containing
those
characters.
characters,
with
the
following
exceptions:
Each
occurrence
of
two
consecutive
{
characters
is
replaced
by
a
single
{
character.
Each
occurrence
of
two
consecutive
}
characters
is
replaced
by
a
single
}
character.
Each
occurrence
of
two
consecutive
"
characters
is
replaced
by
a
single
"
character.
Each
occurrence
of
two
consecutive
'
characters
is
replaced
by
a
single
'
character.
Attribute value normalization is then applied to normalize whitespace and expand character references and predefined entity references . An XQuery processor that supports XML 1.0 uses the rules for attribute value normalization in Section 3.3.3 of [XML 1.0] ; an XQuery processor that supports XML 1.1 uses the rules for attribute value normalization in Section 3.3.3 of [XML 1.1] . In either case, the normalization rules are applied as though the type of the attribute were CDATA (leading and trailing whitespace characters are not stripped.) The choice between XML 1.0 and XML 1.1 rules is implementation-defined .
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.
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
property
of
the
attribute
node.
The
attribute
node
is
given
a
type
annotation
(
type-name
property)
of
xs:untypedAtomic
(this
type
annotation
may
change
if
the
parent
element
is
validated).
The
typed-value
property
of
the
attribute
node
is
the
same
as
its
string-value
,
as
an
instance
of
xs:untypedAtomic
.
The
parent
property
of
the
attribute
node
is
set
to
the
element
node
constructed
by
the
direct
element
constructor
that
contains
this
attribute.
If
the
attribute
name
is
xml:id
,
then
xml:id
processing
is
performed
as
defined
in
[XML
ID]
.
This
ensures
that
the
attribute
has
the
type
xs:ID
and
that
its
value
is
properly
normalized.
If
an
error
is
encountered
during
xml:id
processing,
an
implementation
MAY
may
raise
a
dynamic
error
[
err:XQDY0091
].
If
the
attribute
name
is
xml:id
,
the
is-id
property
of
the
resulting
attribute
node
is
set
to
true
;
otherwise
the
is-id
property
is
set
to
false
.
The
is-idrefs
property
of
the
attribute
node
is
unconditionally
set
to
false
.
Example:
<shoe size="7"/>
The
string
value
of
the
size
attribute
is
"
7
".
Example:
<shoe size="{7}"/>
The
string
value
of
the
size
attribute
is
"
7
".
Example:
<shoe size="{()}"/>
The
string
value
of
the
size
attribute
is
the
zero-length
string.
Example:
<chapter ref="[{1, 5 to 7, 9}]"/>
The
string
value
of
the
ref
attribute
is
"
[1
5
6
7
9]
".
Example:
<shoe size="As big as {$hat/@size}"/>
The
string
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 of a constructed element and its attributes may be QNames that include namespace prefixes . Namespace prefixes can be bound to namespaces in the Prolog or by namespace declaration attributes . It is a static error to use a namespace prefix that has not been bound to a namespace [ err:XPST0081 ].
[
Definition
:
A
namespace
declaration
attribute
is
used
inside
a
direct
element
constructor.
Its
purpose
is
to
bind
a
namespace
prefix
or
to
set
the
default
element/type
namespace
for
the
constructed
element
node,
including
its
attributes.]
Syntactically,
a
namespace
declaration
attribute
has
the
form
of
an
attribute
with
namespace
prefix
xmlns
,
or
with
name
xmlns
and
no
namespace
prefix.
The
value
of
a
namespace
declaration
attribute
must
be
a
URILiteral
;
otherwise
a
static
error
is
raised
[
err:XQST0022
].
All
the
namespace
declaration
attributes
of
a
given
element
must
have
distinct
names
[
err:XQST0071
].
Each
namespace
declaration
attribute
is
processed
as
follows:
The
local
part
value
of
the
namespace
declaration
attribute
name
(a
DirAttributeValue
)
is
interpreted
processed
as
follows.
If
the
DirAttributeValue
contains
an
EnclosedExpr
,
a
namespace
prefix
static
error
is
raised
[
err:XQST0022
].
Otherwise,
it
is
processed
as
described
in
rule
1
of
3.7.1.1
Attributes
.
An
implementation
MAY
raise
a
static
error
[
err:XQST0046
]
if
the
resulting
value
is
of
nonzero
length
and
is
not
in
the
lexical
space
of
xs:anyURI
.
The
resulting
value
is
used
as
the
namespace
URI
in
the
following
rules.
If
the
prefix
of
the
attribute
name
is
xmlns
,
then
the
local
part
of
the
attribute
name
is
interpreted
as
a
namespace
URI.
prefix.
This
prefix
and
the
namespace
URI
are
added
to
the
statically
known
namespaces
of
the
constructor
expression
(overriding
any
existing
binding
of
the
given
prefix),
and
are
also
added
as
a
namespace
binding
to
the
in-scope
namespaces
of
the
constructed
element.
If
the
namespace
URI
is
a
zero-length
string
and
the
implementation
supports
[XML
Names
1.1]
,
any
existing
namespace
binding
for
the
given
prefix
is
removed
from
the
in-scope
namespaces
of
the
constructed
element
and
from
the
statically
known
namespaces
of
the
constructor
expression.
If
the
namespace
URI
is
a
zero-length
string
and
the
implementation
does
not
support
[XML
Names
1.1]
,
a
static
error
is
raised
[
err:XQST0085
].
It
is
implementation-defined
whether
an
implementation
supports
[XML
Names]
or
[XML
Names
1.1]
.
If
the
name
of
the
namespace
declaration
attribute
is
xmlns
with
no
prefix,
then
the
value
of
the
attribute
is
interpreted
as
a
namespace
URI.
This
URI
specifies
the
default
element/type
namespace
of
the
constructor
expression
(overriding
any
existing
default),
and
is
added
(with
no
prefix)
to
the
in-scope
namespaces
of
the
constructed
element
(overriding
any
existing
namespace
binding
with
no
prefix).
If
the
namespace
URI
is
a
zero-length
string,
the
default
element/type
namespace
of
the
constructor
expression
is
set
to
"none,"
and
any
no-prefix
namespace
binding
is
removed
from
the
in-scope
namespaces
of
the
constructed
element.
It
is
a
static
error
[
err:XQST0070
]
if
a
namespace
declaration
attribute
binds
a
namespace
URI
attempts
to
do
any
of
the
following:
Bind
the
predefined
prefix
to
some
namespace
URI
other
than
xmlns
.
It
is
also
a
static
error
[
err:XQST0070
]
if
a
namespace
declaration
attribute
binds
a
xml
http://www.w3.org/XML/1998/namespace
.
to
the
prefix
xml
,
or
binds
Bind
a
prefix
other
than
xml
to
the
namespace
URI
http://www.w3.org/XML/1998/namespace
.
Bind
the
prefix
xmlns
to
any
namespace
URI.
Bind
a
prefix
to
the
namespace
URI
http://www.w3.org/2000/xmlns/
.
A namespace declaration attribute does not cause an attribute node to be created.
The following examples illustrate namespace declaration attributes:
In
this
element
constructor,
a
namespace
declaration
attribute
is
used
to
set
the
default
element/type
namespace
to
http://example.org/animals
:
<cat xmlns = "http://example.org/animals"> <breed>Persian</breed> </cat>
In
this
element
constructor,
namespace
declaration
attributes
are
used
to
bind
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 text characters (parsed as ElementContentChar ), nested direct constructors, CdataSections , character and predefined entity references , 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:
If
the
boundary-space
policy
in
the
static
context
is
strip
,
boundary
whitespace
is
identified
and
deleted
(see
3.7.1.4
Boundary
Whitespace
for
a
definition
of
boundary
whitespace.)
Predefined
entity
references
and
character
references
are
expanded
into
their
referenced
strings,
as
described
in
3.1.1
Literals
.
Characters
inside
a
CDataSection
,
including
special
characters
such
as
<
and
&
,
are
treated
as
literal
characters
rather
than
as
markup
characters
(except
for
the
sequence
]]>
,
which
terminates
the
CDataSection).
Each consecutive sequence of literal characters evaluates to a single text node containing the characters.
Each nested direct constructor is evaluated according to the rules in 3.7.1 Direct Element Constructors or 3.7.2 Other Direct Constructors , resulting in a new element, comment, or processing instruction node. Then:
The
parent
property
of
the
resulting
node
is
then
set
to
the
newly
constructed
element
node.
The
base-uri
property
of
the
resulting
node,
and
of
each
of
its
descendants,
is
set
to
be
the
same
as
that
of
its
new
parent,
unless
it
(the
child
node)
has
an
xml:base
attribute,
in
which
case
its
base-uri
property
is
set
to
the
value
of
that
attribute,
resolved
(if
it
is
relative)
against
the
base-uri
property
of
its
new
parent
node.
Enclosed expressions are evaluated as follows:
If an enclosed expression returns a function item DM11 , a type error is raised [ err:XQTY0105 ].
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 space character inserted between adjacent values.
Note:
The insertion of blank characters between adjacent values applies even if one or both of the values is a zero-length string.
For each node returned by an enclosed expression, a new copy is made of the given node and all nodes that have the given node as an ancestor, collectively referred to as copied nodes . The properties of the copied nodes are as follows:
Each copied node receives a new node identity.
The
parent
,
children
,
and
attributes
properties
of
the
copied
nodes
are
set
so
as
to
preserve
their
inter-node
relationships.
For
the
topmost
node
(the
node
directly
returned
by
the
enclosed
expression),
the
parent
property
is
set
to
the
node
constructed
by
this
constructor.
If
construction
mode
in
the
static
context
is
strip
:
If
the
copied
node
is
an
element
node,
its
type-name
property
is
set
to
xs:untyped
.
Its
nilled
,
is-id
,
and
is-idrefs
properties
are
set
to
false
.
If
the
copied
node
is
an
attribute
node,
its
type-name
property
is
set
to
xs:untypedAtomic
.
Its
is-idrefs
property
is
set
to
false
.
Its
is-id
property
is
set
to
true
if
the
qualified
name
of
the
attribute
node
is
xml:id
;
otherwise
it
is
set
to
false
.
The
string-value
of
each
copied
element
and
attribute
node
remains
unchanged,
and
its
typed-value
becomes
equal
to
its
string-value
as
an
instance
of
xs:untypedAtomic
.
Note:
Implementations that store only the typed value of a node are required at this point to convert the typed value to a string form.
On
the
other
hand,
if
construction
mode
in
the
static
context
is
preserve
,
the
type-name
,
nilled
,
string-value
,
typed-value
,
is-id
,
and
is-idrefs
properties
of
the
copied
nodes
are
preserved.
The
in-scope-namespaces
property
of
a
copied
element
node
is
determined
by
the
following
rules.
In
applying
these
rules,
the
default
namespace
or
absence
of
a
default
namespace
is
treated
like
any
other
namespace
binding:
If
copy-namespaces
mode
specifies
preserve
,
all
in-scope-namespaces
of
the
original
element
are
retained
in
the
new
copy.
If
copy-namespaces
mode
specifies
no-preserve
,
the
new
copy
retains
only
those
in-scope
namespaces
of
the
original
element
that
are
used
in
the
names
of
the
element
and
its
attributes.
It
is
a
type
error
If
copy-namespaces
mode
specifies
inherit
,
the
copied
node
inherits
all
the
in-scope
namespaces
of
the
constructed
node,
augmented
and
overridden
by
the
in-scope
namespaces
of
the
original
element
that
were
preserved
by
the
preceding
rule.
If
copy-namespaces
mode
specifies
no-inherit
,
the
copied
node
does
not
inherit
any
in-scope
namespaces
from
the
constructed
node.
An
enclosed
expression
in
the
content
of
an
element
constructor
may
cause
one
or
more
existing
nodes
to
be
copied.
Type
error
[
err:XQTY0086
]
is
raised
in
this
case
if
the
following
cases:
An
element
node
is
copied,
and
the
typed
value
of
the
copied
element
node
or
of
any
one
of
its
attributes
is
namespace-sensitive
,
and
construction
mode
is
preserve
,
and
copy-namespaces
mode
is
no-preserve
.
An
attribute
node
is
copied
but
its
parent
element
node
is
not
copied,
and
the
typed
value
of
the
copied
attribute
node
is
namespace-sensitive
.
,
and
construction
mode
is
preserve
.
[
Definition
:
A
value
is
namespace-sensitive
if
it
includes
an
item
whose
dynamic
type
is
xs:QName
or
xs:NOTATION
or
is
derived
by
restriction
from
xs:QName
or
xs:NOTATION
.]
Note:
Error
The
rationale
for
error
[
err:XQTY0086
]
can
occur
only
if
construction
mode
is
preserve
,
since
otherwise
the
typed
value
of
the
copied
node
as
follows:
It
is
never
namespace-sensitive.
If
copy-namespaces
mode
specifies
inherit
,
the
copied
node
inherits
all
the
in-scope
namespaces
of
the
constructed
node,
augmented
and
overridden
by
not
possible
to
preserve
the
in-scope
namespaces
type
of
a
QName
without
also
preserving
the
original
element
namespace
binding
that
were
preserved
by
the
preceding
rule.
If
copy-namespaces
mode
specifies
no-inherit
,
defines
the
copied
node
does
not
inherit
any
in-scope
namespaces
from
prefix
of
the
constructed
node.
QName.
When
an
element
or
processing
instruction
node
is
copied,
its
base-uri
property
is
set
to
be
the
same
as
that
of
its
new
parent,
with
the
following
exception:
if
a
copied
element
node
has
an
xml:base
attribute,
its
base-uri
property
is
set
to
the
value
of
that
attribute,
resolved
(if
it
is
relative)
against
the
base-uri
property
of
the
new
parent
node.
All other properties of the copied nodes are preserved.
If the content sequence contains a document node, the document node is replaced in the content sequence by its children.
Adjacent text nodes in the content sequence are merged into a single text node by concatenating their contents, with no intervening blanks. After concatenation, any text node whose content is a zero-length string is deleted from the content sequence.
If the content sequence contains an attribute node or a namespace node following a node that is not an attribute node or a namespace node, a type error is raised [ err:XQTY0024 ].
The properties of the newly constructed element node are determined as follows:
node-name
is
the
expanded
QName
resulting
from
resolving
the
element
name
in
the
start
tag,
including
its
original
namespace
prefix
(if
any),
as
described
in
3.7.1
Direct
Element
Constructors
.
parent
is
set
to
empty.
attributes
consist
of
all
the
attributes
specified
in
the
start
tag
as
described
in
3.7.1.1
Attributes
,
together
with
all
the
attribute
nodes
in
the
content
sequence,
in
implementation-dependent
order.
Note
that
the
parent
property
of
each
of
these
attribute
nodes
has
been
set
to
the
newly
constructed
element
node.
If
two
or
more
attributes
have
the
same
node-name
,
a
dynamic
error
is
raised
[
err:XQDY0025
].
If
an
attribute
named
xml:space
has
a
value
other
than
preserve
or
default
,
a
dynamic
error
MAY
may
be
raised
[
err:XQDY0092
].
children
consist
of
all
the
element,
text,
comment,
and
processing
instruction
nodes
in
the
content
sequence.
Note
that
the
parent
property
of
each
of
these
nodes
has
been
set
to
the
newly
constructed
element
node.
base-uri
is
set
to
the
following
value:
If
the
constructed
node
has
an
attribute
named
xml:base
,
then
the
value
of
this
attribute,
resolved
if
it
is
relative
against
the
base
URI
in
the
static
context
.
The
value
of
the
xml:base
attribute
is
normalized
as
described
in
[XML
Base]
.
Otherwise, the value of the base URI in the static context .
in-scope-namespaces
consist
of
all
the
namespace
bindings
resulting
from
namespace
declaration
attributes
as
described
in
3.7.1.2
Namespace
Declaration
Attributes
,
and
possibly
additional
namespace
bindings
as
described
in
3.7.4
In-scope
Namespaces
of
a
Constructed
Element
.
The
nilled
property
is
false
.
The
string-value
property
is
equal
to
the
concatenated
contents
of
the
text-node
descendants
in
document
order.
If
there
are
no
text-node
descendants,
the
string-value
property
is
a
zero-length
string.
The
typed-value
property
is
equal
to
the
string-value
property,
as
an
instance
of
xs:untypedAtomic
.
If
construction
mode
in
the
static
context
is
strip
,
the
type-name
property
is
xs:untyped
.
On
the
other
hand,
if
construction
mode
is
preserve
,
the
type-name
property
is
xs:anyType
.
The
is-id
and
is-idrefs
properties
are
set
to
false
.
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
the
content
of
the
constructed
element.
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>
[
Definition
:
Boundary
whitespace
is
a
sequence
of
consecutive
whitespace
characters
within
the
content
of
a
direct
element
constructor
,
that
is
delimited
at
each
end
either
by
the
start
or
end
of
the
content,
or
by
a
DirectConstructor
,
or
by
an
EnclosedExpr
.
For
this
purpose,
characters
generated
by
character
references
such
as
 
or
by
CdataSections
are
not
considered
to
be
whitespace
characters.]
The
boundary-space
policy
in
the
static
context
controls
whether
boundary
whitespace
is
preserved
by
element
constructors.
If
boundary-space
policy
is
strip
,
boundary
whitespace
is
not
considered
significant
and
is
discarded.
On
the
other
hand,
if
boundary-space
policy
is
preserve
,
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
will
be
stripped
away
by
the
element
constructor
if
boundary-space
policy
is
strip
.
Example:
<a> {"abc"} </a>
If
boundary-space
policy
is
strip
,
this
example
is
equivalent
to
<a>abc</a>
.
However,
if
boundary-space
policy
is
preserve
,
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>
.
Example:
<a> {"abc"}</a>
This
example
is
equivalent
to
<a> abc</a>
,
regardless
of
the
boundary-space
policy,
because
the
space
generated
by
the
character
reference
is
not
treated
as
a
whitespace
character.
Example:
<a>{" "}</a>
This example constructs an element containing two space characters, regardless of the boundary-space policy, because whitespace inside an enclosed expression is never considered to be boundary whitespace.
Note:
Element
constructors
treat
attributes
named
xml:space
as
ordinary
attributes.
An
xml:space
attribute
does
not
affect
the
handling
of
whitespace
by
an
element
constructor.
XQuery allows an expression to generate a processing instruction node or a comment node. This can be accomplished by using a direct processing instruction constructor or a direct comment constructor . In each case, the syntax of the constructor expression is based on the syntax of a similar construct in XML.
|
DirPIConstructor
|
::= |
"<?"
PITarget
(
S
DirPIContents
)?
"?>"
|
|
DirPIContents
|
::= |
(
Char
*
-
(Char*
'?>'
Char*))
|
|
DirCommentConstructor
|
::= |
"<!--"
DirCommentContents
"-->"
|
|
DirCommentContents
|
::= |
((
Char
-
'-')
|
('-'
(
Char
-
'-')))*
|
A
direct
processing
instruction
constructor
creates
a
processing
instruction
node
whose
target
property
is
PITarget
and
whose
content
property
is
DirPIContents
.
The
base-uri
property
of
the
node
is
empty.
The
parent
property
of
the
node
is
empty.
The
PITarget
of
a
processing
instruction
may
must
not
consist
of
the
characters
"XML"
in
any
combination
of
upper
and
lower
case.
The
DirPIContents
of
a
processing
instruction
may
must
not
contain
the
string
"
?>
".
The following example illustrates a direct processing instruction constructor:
<?format role="output" ?>
A
direct
comment
constructor
creates
a
comment
node
whose
content
property
is
DirCommentContents
.
Its
parent
property
is
empty.
The
DirCommentContents
of
a
comment
may
must
not
contain
two
consecutive
hyphens
or
end
with
a
hyphen.
These
rules
are
syntactically
enforced
by
the
grammar
shown
above.
The following example illustrates a direct comment constructor:
<!-- Tags are ignored in the following section -->
|
ComputedConstructor
|
::= |
CompDocConstructor
|
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
,
or
comment
,
or
namespace
.
For those kinds of nodes that have names (element, attribute, and processing instruction nodes), the keyword that specifies the node kind is followed by the name of the node to be created. This name may be specified either as a QName or as an expression enclosed in braces. [ Definition : When an expression is used to specify the name of a constructed node, that expression is called the name expression of the constructor.]
[ Definition : The final part of a computed constructor is an expression enclosed in braces, called the content expression of the constructor, 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" } } }
|
CompElemConstructor
|
::= |
"element"
(
QName
|
("{"
Expr
"}"))
"{"
ContentExpr
?
"}"
|
|
ContentExpr
|
::= |
Expr
|
[ Definition : A computed element constructor creates an element node, allowing both the name and the content of the node to be computed.]
If
the
keyword
element
is
followed
by
a
QName,
it
is
expanded
using
the
statically
known
namespaces
,
and
the
resulting
expanded
QName
is
used
as
the
node-name
property
of
the
constructed
element
node.
If
expansion
of
the
QName
is
not
successful,
a
static
error
is
raised
[
err:XPST0081
].
If
the
keyword
element
is
followed
by
a
name
expression
,
the
name
expression
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
xs:untypedAtomic
,
a
type
error
is
raised
[
err:XPTY0004
].
If
the
atomized
value
of
the
name
expression
is
of
type
xs:QName
,
that
expanded
QName
is
used
as
the
node-name
property
of
the
constructed
element,
retaining
the
prefix
part
of
the
QName.
If
the
atomized
value
of
the
name
expression
is
of
type
xs:string
or
xs:untypedAtomic
,
that
value
is
converted
to
an
expanded
QName
.
If
the
string
value
contains
a
namespace
prefix,
that
prefix
is
resolved
to
a
namespace
URI
using
the
statically
known
namespaces
.
If
the
string
value
contains
no
namespace
prefix,
it
is
treated
as
a
local
name
in
the
default
element/type
namespace
.
The
resulting
expanded
QName
is
used
as
the
node-name
property
of
the
constructed
element,
retaining
the
prefix
part
of
the
QName.
If
conversion
of
the
atomized
name
expression
to
an
expanded
QName
is
not
successful,
a
dynamic
error
is
raised
[
err:XQDY0074
].
A static error is raised [ERROR 0044 NOT FOUND] if the node-name of the constructed element node has any of the following properties:
Its
namespace
prefix
is
xmlns
.
It
has
no
namespace
prefix
and
its
local
name
is
xmlns
.
Its
namespace
URI
is
http://www.w3.org/2000/xmlns/
.
Its
namespace
prefix
is
xml
and
its
namespace
URI
is
not
http://www.w3.org/XML/1998/namespace
.
Its
namespace
prefix
is
other
than
xml
and
its
namespace
URI
is
http://www.w3.org/XML/1998/namespace
.
The content expression of a computed element constructor (if present) is processed in exactly the same way as an enclosed expression in the content of a direct element constructor , as described in Step 1e of 3.7.1.3 Content . The result of processing the content expression is a sequence of nodes called the content sequence . If the content expression is absent, the content sequence is an empty sequence.
Processing of the computed element constructor proceeds as follows:
If the content sequence contains a document node, the document node is replaced in the content sequence by its children.
Adjacent text nodes in the content sequence are merged into a single text node by concatenating their contents, with no intervening blanks. After concatenation, any text node whose content is a zero-length string is deleted from the content sequence.
If
the
content
sequence
contains
a
document
node,
the
document
node
is
replaced
in
the
content
sequence
by
its
children.
If
the
content
sequence
contains
an
attribute
node
or
a
namespace
node
following
a
node
that
is
not
an
attribute
node
or
a
namespace
node,
a
type
error
is
raised
[
err:XQTY0024
].
The properties of the newly constructed element node are determined as follows:
node-name
is
the
expanded
QName
resulting
from
processing
the
specified
QName
or
name
expression
,
as
described
above.
parent
is
empty.
attributes
consist
of
all
the
attribute
nodes
in
the
content
sequence,
in
implementation-dependent
order.
Note
that
the
parent
property
of
each
of
these
attribute
nodes
has
been
set
to
the
newly
constructed
element
node.
If
two
or
more
attributes
have
the
same
node-name
,
a
dynamic
error
is
raised
[
err:XQDY0025
].
If
an
attribute
named
xml:space
has
a
value
other
than
preserve
or
default
,
a
dynamic
error
MAY
may
be
raised
[
err:XQDY0092
].
children
consist
of
all
the
element,
text,
comment,
and
processing
instruction
nodes
in
the
content
sequence.
Note
that
the
parent
property
of
each
of
these
nodes
has
been
set
to
the
newly
constructed
element
node.
base-uri
is
set
to
the
following
value:
If
the
constructed
node
has
an
attribute
named
xml:base
,
then
the
value
of
this
attribute,
resolved
if
it
is
relative
against
the
base
URI
in
the
static
context
.
The
value
of
the
xml:base
attribute
is
normalized
as
described
in
[XML
Base]
.
Otherwise, the value of the base URI in the static context .
in-scope-namespaces
are
computed
as
described
in
3.7.4
In-scope
Namespaces
of
a
Constructed
Element
.
The
nilled
property
is
false
.
The
string-value
property
is
equal
to
the
concatenated
contents
of
the
text-node
descendants
in
document
order.
The
typed-value
property
is
equal
to
the
string-value
property,
as
an
instance
of
xs:untypedAtomic
.
If
construction
mode
in
the
static
context
is
strip
,
the
type-name
property
is
xs:untyped
.
On
the
other
hand,
if
construction
mode
is
preserve
,
the
type-name
property
is
xs:anyType
.
The
is-id
and
is-idrefs
properties
are
set
to
false
.
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
dictionary
element
containing
a
sequence
of
entry
elements,
each
of
which
encodes
translations
for
a
specific
word.
Here
is
an
example
entry
that
encodes
the
German
and
Italian
variants
of
the
word
"address":
<entry word="address"> <variant xml:lang="de">Adresse</variant> <variant xml:lang="it">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 {$dict/entry[@word=name($e)]/variant[@xml:lang="it"]} {$e/@*, $e/node()}
The result of this expression is as follows:
<indirizzo>123 Roosevelt Ave. Flushing, NY 11368</indirizzo>
Note:
As
in
the
previous
example,
if
the
Static
Typing
Feature
is
in
effect,
the
enclosed
expression
that
computes
the
element
name
in
the
above
computed
element
constructor
must
be
wrapped
in
a
call
to
the
fn:exactly-one
function
in
order
to
avoid
a
static
type
error.
Additional
examples
of
computed
element
constructors
can
be
found
in
I.4
I.3
Recursive
Transformations
.
|
CompAttrConstructor
|
::= |
"attribute"
(
QName
|
("{"
Expr
"}"))
"{"
Expr
?
"}"
|
A computed attribute constructor creates a new attribute node, with its own node identity.
If
the
keyword
attribute
is
followed
by
a
QName,
that
QName
is
expanded
using
the
statically
known
namespaces
,
and
the
resulting
expanded
QName
(including
its
prefix)
is
used
as
the
node-name
property
of
the
constructed
attribute
node.
If
expansion
of
the
QName
is
not
successful,
a
static
error
is
raised
[
err:XPST0081
].
If
the
keyword
attribute
is
followed
by
a
name
expression
,
the
name
expression
is
processed
as
follows:
Atomization
is
applied
to
the
result
of
the
name
expression
.
If
the
result
of
atomization
is
not
a
single
atomic
value
of
type
xs:QName
,
xs:string
,
or
xs:untypedAtomic
,
a
type
error
is
raised
[
err:XPTY0004
].
If
the
atomized
value
of
the
name
expression
is
of
type
xs:QName
:
,
If the expanded QName returned by the atomized name expression has a namespace URI but has no prefix, it is given an implementation-dependent prefix.
Note:
This step is necessary because attributes have no default namespace. Therefore any attribute name that has a namespace URI must also have a prefix.
The
resulting
expanded
QName
(including
its
prefix)
is
used
as
the
node-name
property
of
the
constructed
attribute
node.
If
the
atomized
value
of
the
name
expression
is
of
type
xs:string
or
xs:untypedAtomic
,
that
value
is
converted
to
an
expanded
QName
.
If
the
string
value
contains
a
namespace
prefix,
that
prefix
is
resolved
to
a
namespace
URI
using
the
statically
known
namespaces
.
If
the
string
value
contains
no
namespace
prefix,
it
is
treated
as
a
local
name
in
no
namespace.
The
resulting
expanded
QName
(including
its
prefix)
is
used
as
the
node-name
property
of
the
constructed
attribute.
If
conversion
of
the
atomized
name
expression
to
an
expanded
QName
is
not
successful,
a
dynamic
error
is
raised
[
err:XQDY0074
].
The
A
static
error
is
raised
[ERROR
0044
NOT
FOUND]
if
the
node-name
property
of
the
constructed
attribute
(an
expanded
QName
)
node
has
any
of
the
following
properties:
Its
namespace
prefix
is
checked
as
follows:
If
xmlns
.
It
has
no
namespace
prefix
and
its
local
name
is
xmlns
.
Its
namespace
URI
part
is
http://www.w3.org/2000/xmlns/
.
(corresponding
to
Its
namespace
prefix
is
xmlns
xml
)
or
if
it
and
its
namespace
URI
is
in
no
not
http://www.w3.org/XML/1998/namespace
.
Its
namespace
prefix
is
other
than
xml
and
its
local
name
namespace
URI
is
.
xmlns
,
a
dynamic
error
[
err:XQDY0044
]
is
raised.
http://www.w3.org/XML/1998/namespace
The content expression of a computed attribute constructor is processed as follows:
Atomization is applied to the result of the content expression , converting it to a sequence of atomic values. (If the content expression is absent, the result of this step is an empty sequence.)
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.
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
string-value
property
of
the
new
attribute
node.
The
type
annotation
(
type-name
property)
of
the
new
attribute
node
is
xs:untypedAtomic
.
The
typed-value
property
of
the
attribute
node
is
the
same
as
its
string-value
,
as
an
instance
of
xs:untypedAtomic
.
The
parent
property
of
the
attribute
node
is
set
to
empty.
If
the
attribute
name
is
xml:id
,
then
xml:id
processing
is
performed
as
defined
in
[XML
ID]
.
This
ensures
that
the
attribute
node
has
the
type
xs:ID
and
that
its
value
is
properly
normalized.
If
an
error
is
encountered
during
xml:id
processing,
an
implementation
MAY
may
raise
a
dynamic
error
[
err:XQDY0091
].
If
the
attribute
name
is
xml:id
,
the
is-id
property
of
the
resulting
attribute
node
is
set
to
true
;
otherwise
the
is-id
property
is
set
to
false
.
The
is-idrefs
property
of
the
attribute
node
is
unconditionally
set
to
false
.
If
the
attribute
name
is
xml:space
and
the
attribute
value
is
other
than
preserve
or
default
,
a
dynamic
error
MAY
be
raised
[
err:XQDY0092
].
Example:
attribute size {4 + 3}
The
string
value
of
the
size
attribute
is
"
7
"
and
its
type
is
xs:untypedAtomic
.
Example:
attribute { if ($sex = "M") then "husband" else "wife" }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
string
value
is
"
Hello
1
2
3
Goodbye
".
|
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")/bib/book/author} </author-list>}}
The content expression of a document node constructor is processed in exactly the same way as an enclosed expression in the content of a direct element constructor , as described in Step 1e of 3.7.1.3 Content . The result of processing the content expression is a sequence of nodes called the content sequence . Processing of the document node constructor then proceeds as follows:
If the content sequence contains a document node, the document node is replaced in the content sequence by its children.
Adjacent text nodes in the content sequence are merged into a single text node by concatenating their contents, with no intervening blanks. After concatenation, any text node whose content is a zero-length string is deleted from the content sequence.
If
the
content
sequence
contains
a
document
an
attribute
node,
the
document
node
a
type
error
is
replaced
in
the
content
sequence
by
its
children.
raised
[
err:XPTY0004
].
If
the
content
sequence
contains
an
attribute
a
namespace
node,
a
type
error
is
raised
[
err:XPTY0004
].
The properties of the newly constructed document node are determined as follows:
base-uri
is
taken
from
base
URI
in
the
static
context
.
If
no
base
URI
is
defined
in
the
static
context,
the
base-uri
property
is
empty.
children
consist
of
all
the
element,
text,
comment,
and
processing
instruction
nodes
in
the
content
sequence.
Note
that
the
parent
property
of
each
of
these
nodes
has
been
set
to
the
newly
constructed
document
node.
The
unparsed-entities
and
document-uri
properties
are
empty.
The
string-value
property
is
equal
to
the
concatenated
contents
of
the
text-node
descendants
in
document
order.
The
typed-value
property
is
equal
to
the
string-value
property,
as
an
instance
of
xs:untypedAtomic
.
No validation is performed on the constructed document node. 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.
|
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
property
of
the
constructed
text
node.
The
parent
property
of
the
constructed
text
node
is
set
to
empty.
Note:
It is possible for a text node constructor to construct a text node containing a zero-length string. However, if used in the content of a constructed element or document node, such a text node will be deleted or merged with another text node.
The following example illustrates a text node constructor:
text {"Hello"}
|
CompPIConstructor
|
::= |
"processing-instruction"
(
NCName
|
("{"
Expr
"}"))
"{"
Expr
?
"}"
|
A computed processing instruction constructor ( CompPIConstructor ) constructs a new processing instruction node with its own node identity.
If
the
keyword
processing-instruction
is
followed
by
an
NCName,
that
NCName
is
used
as
the
target
property
of
the
constructed
node.
If
the
keyword
processing-instruction
is
followed
by
a
name
expression
,
the
name
expression
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:NCName
,
xs:string
,
or
xs:untypedAtomic
,
a
type
error
is
raised
[
err:XPTY0004
].
If
the
atomized
value
of
the
name
expression
is
of
type
xs:string
or
xs:untypedAtomic
,
that
value
is
cast
to
the
type
xs:NCName
.
If
the
value
cannot
be
cast
to
xs:NCName
,
a
dynamic
error
is
raised
[
err:XQDY0041
].
The
resulting
NCName
is
then
used
as
the
target
property
of
the
newly
constructed
processing
instruction
node.
However,
a
dynamic
error
is
raised
if
the
NCName
is
equal
to
"
XML
"
(in
any
combination
of
upper
and
lower
case)
[
err:XQDY0064
].
The content expression of a computed processing instruction 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 content expression is absent, the result of this step is an empty sequence.)
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.
If
any
of
the
resulting
strings
contains
the
string
"
?>
",
a
dynamic
error
[
err:XQDY0026
]
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.
Leading
whitespace
is
removed
from
the
resulting
string.
The
resulting
string
then
becomes
the
content
property
of
the
constructed
processing
instruction
node.
The remaining properties of the new processing instruction node are determined as follows:
The
parent
property
is
empty.
The
base-uri
property
is
empty.
The following example illustrates a computed processing instruction constructor:
let $target := "audio-output", $content := "beep" return processing-instruction {$target} {$content}
The processing instruction node constructed by this example might be serialized as follows:
<?audio-output beep?>
|
CompCommentConstructor
|
::= |
"comment"
"{"
Expr
"}"
|
A computed comment constructor ( CompCommentConstructor ) 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
property
of
the
constructed
comment
node.
It is a dynamic error [ err:XQDY0072 ] if the result of the content expression of a computed comment constructor contains two adjacent hyphens or ends with a hyphen.
The
parent
property
of
the
constructed
comment
node
is
set
to
empty.
The following example illustrates a computed comment constructor:
let $homebase := "Houston" return comment {fn:concat($homebase, ", we have a problem.")}
The comment node constructed by this example might be serialized as follows:
<!--Houston, we have a problem.-->
[154] |
CompNamespaceConstructor
| ::= |
"namespace"
(
Prefix
|
("{"
PrefixExpr
"}"))
"{"
URIExpr
?
"}"
|
[156] |
PrefixExpr
| ::= |
Expr
|
[157] |
URIExpr
| ::= |
Expr
|
A computed namespace constructor creates a new namespace node, with its own node identity. The parent of the newly created namespace node is empty.
If
the
constructor
specifies
a
Prefix
,
it
is
used
as
the
prefix
for
the
namespace
node.
If
the
constructor
specifies
a
PrefixExpr
,
the
prefix
expression
is
evaluated
as
follows:
Atomization is applied to the result of the name expression .
If
the
result
of
atomization
is
a
single
atomic
value
of
type
xs:NCName
,
xs:string
,
or
xs:untypedAtomic
,
it
is
used
as
the
prefix
property
of
the
newly
constructed
namespace
node.
If
the
result
is
the
empty
sequence
or
an
empty
string,
the
prefix
property
of
the
newly
constructed
namespace
node
is
empty.
For
any
other
result,
a
type
error
is
raised
[
err:XPTY0004
].
The
URIExpr
is
evaluated,
and
the
result
is
cast
to
xs:anyURI
to
create
the
URI
property
for
the
newly
created
node.
An
error
[
err:XQDY0101
]
is
raised
if
the
namespace
URI
in
a
computed
namespace
constructor
is
bound
to
the
predefined
prefix
xmlns
,
or
if
a
namespace
URI
other
than
http://www.w3.org/XML/1998/namespace
is
bound
to
the
prefix
xml
,
or
if
the
prefix
xml
is
bound
to
a
namespace
URI
other
than
http://www.w3.org/XML/1998/namespace.
By itself, a computed namespace constructor has no effect on in-scope namespaces, but if an element constructor's content sequence contains a namespace node, the namespace binding it represents is added to the elements in-scope namespaces.
A computed namespace constructor has no effect on the statically known namespaces.
Note:
The newly created namespace node has all properties defined for a namespace node in the data model. Like all nodes, it has identity. Like all nodes which do not share a common parent, the relative order of these nodes is implementation dependent. As defined in the data model, the name of the node is the prefix, and the string value of the node is the URI.
Examples:
A computed namespace constructor with a prefix:
namespace a {"http://a.example.com" }
A computed namespace constructor with a prefix expression:
namespace {"a"} {"http://a.example.com" }
A computed namespace constructor with an empty prefix:
namespace { "" } {"http://a.example.com" }
Computed namespace constructors are generally used to add to the in-scope namespaces of elements created with element constructors:
<form> { namespace a {"http://a.example.com" }, attribute { xs:QName("a:id") } { "a-12-XE-45" }, element { xs:QName("a:field")} { "Sample data" } } </form>
Computed namespace constructors have no effect on the statically known namespaces. If the prefix a is not already defined in the statically known namespaces, the following expression results in a static error [ err:XPST0081 ].
<a:form> { namespace a { "http://a.example.com" } } </a:form>
An
element
node
constructed
by
a
direct
or
computed
element
constructor
has
an
in-scope
namespaces
property
that
consists
of
a
set
of
namespace
bindings
.
The
in-scope
namespaces
of
an
element
node
may
affect
the
way
the
node
is
serialized
(see
2.2.4
Serialization
),
and
may
also
affect
the
behavior
of
certain
functions
that
operate
on
nodes,
such
as
fn:name
.
Note
the
difference
between
in-scope
namespaces
,
which
is
a
dynamic
property
of
an
element
node,
and
statically
known
namespaces
,
which
is
a
static
property
of
an
expression.
Also
note
that
one
of
the
namespace
bindings
in
the
in-scope
namespaces
may
have
no
prefix
(denoting
the
default
namespace
for
the
given
element).
The
in-scope
namespaces
of
a
constructed
element
node
consist
of
the
following
namespace
bindings:
A namespace binding is created for each namespace declared in the current element constructor by a namespace declaration attribute .
A namespace binding is created for each namespace node in the context sequence of the current element constructor.
A namespace binding is created for each namespace that is declared in a namespace declaration attribute of an enclosing direct element constructor and not overridden by the current element constructor or an intermediate constructor.
A
namespace
binding
is
always
created
to
bind
the
prefix
xml
to
the
namespace
URI
http://www.w3.org/XML/1998/namespace
.
For each namespace used in the name of the constructed element or in the names of its attributes, a namespace binding must exist. If a namespace binding does not already exist for one of these namespaces, a new namespace binding is created for it. If the name of the node includes a prefix, that prefix is used in the namespace binding; if the name has no prefix, then a binding is created for the empty prefix. If this would result in a conflict, because it would require two different bindings of the same prefix, then the prefix used in the node name is changed to an arbitrary implementation-dependent prefix that does not cause such a conflict, and a namespace binding is created for this new prefix.
Note:
Copy-namespaces mode does not affect the namespace bindings of a newly constructed element node. It applies only to existing nodes that are copied by a constructor expression.
In an element constructor, if two or more namespace bindings in the in-scope bindings would have the same prefix, then an error is raised if they have different URIs [ err:XQTY0102 ]; if they would have the same prefix and URI, duplicate bindings are ignored.
The following query serves as an example:
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"/>
The
in-scope
namespaces
of
the
resulting
p:a
element
consists
of
the
following
namespace
bindings
:
p
=
"http://example.com/ns/p"
q
=
"http://example.com/ns/q"
r
=
"http://example.com/ns/r"
xml
=
"http://www.w3.org/XML/1998/namespace"
The
namespace
bindings
for
p
and
q
are
added
to
the
result
element
because
their
respective
namespaces
are
used
in
the
names
of
the
element
and
its
attributes.
The
namespace
binding
r="http://example.com/ns/r"
is
added
to
the
in-scope
namespaces
of
the
constructed
element
because
it
is
defined
by
a
namespace
declaration
attribute
,
even
though
it
is
not
used
in
a
name.
No
namespace
binding
corresponding
to
f="http://example.com/ns/f"
is
created,
because
the
namespace
prefix
f
appears
only
in
the
query
prolog
and
is
not
used
in
an
element
or
attribute
name
of
the
constructed
node.
This
namespace
binding
does
not
appear
in
the
query
result,
even
though
it
is
present
in
the
statically
known
namespaces
and
is
available
for
use
during
processing
of
the
query.
Note
that
the
following
constructed
element,
if
nested
within
a
validate
expression,
cannot
be
validated:
<p xsi:type="xs:integer">3</p>
The
constructed
element
will
have
namespace
bindings
for
the
prefixes
xsi
(because
it
is
used
in
a
name)
and
xml
(because
it
is
defined
for
every
constructed
element
node).
During
validation
of
the
constructed
element,
the
validator
will
be
unable
to
interpret
the
namespace
prefix
xs
because
it
is
has
no
namespace
binding.
Validation
of
this
constructed
element
could
be
made
possible
by
providing
a
namespace
declaration
attribute
,
as
in
the
following
example:
<p xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:integer">3</p>
XQuery
provides
a
feature
versatile
expression
called
a
FLWOR
expression
that
supports
iteration
and
binding
of
variables
to
intermediate
results.
This
kind
of
may
contain
multiple
clauses.
The
FLWOR
expression
is
often
useful
can
be
used
for
computing
joins
between
two
or
more
documents
many
purposes,
including
iterating
over
sequences,
joining
multiple
documents,
and
for
restructuring
data.
performing
grouping
and
aggregation.
The
name
FLWOR,
pronounced
"flower",
is
suggested
by
the
keywords
for
,
let
,
where
,
order
by
,
and
return
,
which
introduce
some
of
the
clauses
used
in
FLWOR
expressions
(but
this
is
not
a
complete
list
of
such
clauses.)
.
The complete syntax of a FLWOR expression is shown here, and relevant parts of the syntax are repeated in subsequent sections of this document.
|
FLWORExpr
|
::= |
InitialClause
IntermediateClause
*
ReturnClause
|
[43] |
InitialClause
|
::= |
|
[44] |
IntermediateClause
| ::= |
InitialClause
|
WhereClause
|
|
ForClause
|
::= |
"for"
ForBinding
(","
ForBinding
)*
|
[46] |
ForBinding
|
::= |
|
[49] |
LetClause
| ::= |
"let"
LetBinding
(","
LetBinding
)*
|
[50] |
LetBinding
| ::= |
"$"
VarName
TypeDeclaration
?
|
|
TypeDeclaration
|
::= |
"as"
SequenceType
|
[47] |
AllowingEmpty
|
::= |
|
[48] |
PositionalVar
| ::= |
"at"
"$"
VarName
|
[51] |
WindowClause
| ::= |
"for"
(
TumblingWindowClause
|
SlidingWindowClause
)
|
[52] |
TumblingWindowClause
| ::= |
"tumbling"
"window"
"$"
VarName
TypeDeclaration
?
|
[53] |
SlidingWindowClause
| ::= |
"sliding"
"window"
"$"
VarName
TypeDeclaration
?
|
|
WindowStartCondition
|
::= |
"start"
WindowVars
"when"
ExprSingle
|
[55] |
WindowEndCondition
|
::= |
|
|
WindowVars
|
::= |
("$"
CurrentItem
)?
PositionalVar
?
("previous"
"$"
PreviousItem
)?
("next"
"$"
NextItem
)?
|
[57] |
CurrentItem
|
::= |
|
|
PreviousItem
|
::= |
QName
|
[59] |
NextItem
| ::= |
QName
|
[60] |
CountClause
| ::= |
"count"
"$"
VarName
|
[61] |
WhereClause
|
::= |
"where"
ExprSingle
|
|
GroupByClause
| ::= |
"group"
"by"
GroupingSpecList
|
[63] |
GroupingSpecList
| ::= |
GroupingSpec
(","
GroupingSpec
)*
|
|
GroupingSpec
|
::= |
"$"
VarName
("collation"
URILiteral
)?
|
[65] |
OrderByClause
|
::= |
(("order"
"by")
|
("stable"
"order"
"by"))
OrderSpecList
|
|
OrderSpecList
|
::= |
OrderSpec
(","
OrderSpec
)*
|
|
OrderSpec
|
::= |
ExprSingle
OrderModifier
|
|
OrderModifier
|
::= |
("ascending"
|
"descending")?
("empty"
("greatest"
|
"least"))?
("collation"
URILiteral
)?
|
[69] |
|
::= |
|
The
semantics
of
FLWOR
expression
generate
expressions
are
based
on
a
concept
called
a
tuple
stream
.
[
Definition
:
A
tuple
stream
is
an
ordered
sequence
of
zero
or
more
tuples
.]
[
Definition
:
A
tuple
is
a
set
of
bound
zero
or
more
named
variables,
called
the
each
of
which
is
bound
to
a
value
that
is
an
XDM
instance
.]
Each
tuple
stream
.
The
optional
where
clause
serves
to
filter
is
homogeneous
in
the
tuple
stream,
retaining
some
sense
that
all
its
tuples
contain
variables
with
the
same
names
and
discarding
others.
the
same
static
types
.
The
optional
following
example
illustrates
a
tuple
stream
consisting
of
four
tuples,
each
containing
three
variables
named
,order
by
clause
can
be
used
to
reorder
$x
$y
,
and
$z
:
($x = 1003, $y = "Fred", $z = <age>21</age>) ($x = 1017, $y = "Mary", $z = <age>35</age>) ($x = 1020, $y = "Bill", $z = <age>18</age>) ($x = 1024, $y = "John", $z = <age>29</age>)
Note:
In
this
section,
tuple
streams
are
represented
as
shown
in
the
above
example.
Each
tuple
stream.
The
return
clause
constructs
is
on
a
separate
line
and
is
enclosed
in
parentheses,
and
the
result
variable
bindings
inside
each
tuple
are
separated
by
commas.
This
notation
does
not
represent
XQuery
syntax,
but
is
simply
a
representation
of
a
tuple
stream
for
the
purpose
of
defining
the
semantics
of
FLWOR
expressions.
Tuples
and
tuple
streams
are
not
part
of
the
data
model
.
They
exist
only
as
conceptual
intermediate
results
during
the
processing
of
a
FLWOR
expression.
The
return
A
FLWOR
expression
consists
of
an
initial
clause,
zero
or
more
intermediate
clauses,
and
a
final
clause.
Conceptually,
the
initial
clause
is
evaluated
once
for
every
generates
a
tuple
in
stream.
Each
intermediate
clause
takes
the
tuple
stream,
after
filtering
stream
generated
by
the
where
clause,
using
the
variable
bindings
previous
clause
as
input
and
generates
a
(possibly
different)
tuple
stream
as
output.
The
final
clause
takes
a
tuple
stream
as
input
and,
for
each
tuple
in
this
tuple
stream,
generates
an
XDM
instance
;
the
respective
tuples.
The
final
result
of
the
FLWOR
expression
is
an
ordered
sequence
containing
the
results
ordered
concatenation
of
these
evaluations,
concatenated
as
if
by
the
comma
operator
XDM
instances
.
The
following
example
of
initial
clause
in
a
FLWOR
expression
includes
all
of
the
possible
clauses.
The
may
be
a
for
,
clause
iterates
over
all
the
departments
in
an
input
document,
binding
the
variable
,$d
let
window
,
or
count
to
each
department
number
in
turn.
For
each
binding
of
clause.
Intermediate
clauses
may
be
,
$d
for
the
let
,
window
,
count
,
where
,
group
by
,
or
order
by
clauses.
These
intermediate
clauses
may
be
repeated
as
many
times
as
desired,
in
any
order.
The
final
clause
binds
variable
of
the
FLWOR
expression
must
be
a
$e
return
to
all
clause.
The
semantics
of
the
employees
various
clauses
are
described
in
the
given
department,
selected
from
another
input
document.
following
sections.
The
result
of
the
following
clauses
in
FLWOR
expressions
bind
values
to
variables:
for
,
and
let
,
clauses
is
a
tuple
stream
in
which
each
tuple
contains
a
pair
of
bindings
for
,
and
$d
window
$e
(
$d
count
is
bound
to
(in
addition,
a
department
number
and
clause
changes
the
values
of
variables
that
were
previously
bound.)
In
each
case,
binding
of
variables
is
$e
group
by
bound
to
governed
by
the
following
rules:
The
scope
of
a
set
bound
variable
includes
all
subexpressions
of
employees
in
the
containing
FLWOR
that
department).
appear
after
the
variable
binding.
The
where
clause
filters
scope
does
not
include
the
tuple
stream
by
keeping
only
those
binding-pairs
that
represent
departments
having
at
least
ten
employees.
expression
to
which
the
variable
is
bound.
The
following
code
fragment,
containing
two
clauses,
illustrates
how
variable
bindings
may
reference
variables
that
were
bound
in
earlier
clauses,
or
in
earlier
bindings
in
the
same
clause:
order
by
let
let $x := 47, $y := f($x) let $z := g($x, $y)
A
given
variable
may
be
bound
more
than
once
in
a
FLWOR
expression,
or
even
within
one
clause
orders
of
a
FLWOR
expression.
In
such
a
case,
each
new
binding
occludes
the
surviving
tuples
previous
one,
which
becomes
inaccessible
in
descending
order
the
remainder
of
the
FLWOR
expression.
[
Definition
:
A
variable
binding
may
be
accompanied
by
a
type
declaration
,
which
consists
of
the
average
salary
keyword
as
followed
by
the
static
type
of
the
employees
variable,
declared
using
the
syntax
in
2.5.3
SequenceType
Syntax
.]
At
run
time,
if
the
department.
The
value
bound
to
the
variable
does
not
match
the
declared
type
according
to
the
rules
for
SequenceType
matching
,
a
type
error
is
raised
[
err:XPTY0004
].
For
example,
the
following
clause
return
let
constructs
raises
a
new
type
error
because
the
variable
big-dept
$salary
element
for
each
surviving
tuple,
containing
has
a
type
declaration
that
is
not
satisfied
by
the
department
number,
headcount,
and
average
salary.
value
that
is
bound
to
it:
<span class= "parse-test">for $d in fn:doc("depts.xml")/depts/deptno let $e := fn:doc("emps.xml")/emps/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>let $salary as xs:decimal := "cat"
[
Definition
:
In
a
for
clause
or
window
clause,
when
an
expression
is
preceded
by
the
keyword
in
,
the
value
of
that
expression
is
called
a
binding
sequence
.]
The
for
and
window
clauses
iterate
over
their
binding
sequences,
producing
multiple
bindings
for
one
or
more
variables.
Details
on
how
binding
sequences
are
used
in
a
FLWOR
expression
for
and
window
clauses
are
described
in
more
detail
below.
the
following
sections.
[45] |
ForClause
| ::= |
"for"
ForBinding
(","
ForBinding
)*
|
[46] |
ForBinding
| ::= |
"$"
VarName
TypeDeclaration
?
AllowingEmpty
?
PositionalVar
?
"in"
ExprSingle
|
[166] |
TypeDeclaration
| ::= |
"as"
SequenceType
|
[47] |
AllowingEmpty
| ::= |
"allowing"
"empty"
|
[48] |
PositionalVar
| ::= |
"at"
"$"
VarName
|
The
purpose
of
the
A
for
and
clause
is
used
for
iteration.
Each
variable
in
a
let
for
clauses
in
clause
iterates
over
a
FLWOR
expression
sequence
and
is
bound
in
turn
to
produce
a
tuple
stream
each
item
in
which
the
sequence.
If
a
for
clause
contains
multiple
variables,
it
is
semantically
equivalent
to
multiple
for
clauses,
each
tuple
consists
of
containing
one
or
more
bound
variables.
of
the
variables
in
the
original
for
clause.
Example:
The
simplest
example
clause
for $x in $expr1, $y in $expr2
is semantically equivalent to:
for $x in $expr1 for $y in $expr2
In
the
remainder
of
this
section,
we
define
the
semantics
of
a
for
clause
contains
one
containing
a
single
variable
and
an
associated
expression.
[
Definition
:
The
value
of
the
expression
associated
with
a
variable
in
a
(following
the
keyword
for
in
clause
)
whose
value
is
called
the
binding
sequence
for
that
variable.]
The
variable.
If
a
single-variable
for
clause
iterates
over
is
the
items
initial
clause
in
the
a
FLWOR
expression,
it
iterates
over
its
binding
sequence,
sequence
,
binding
the
variable
to
each
item
in
turn.
The
resulting
sequence
of
variable
bindings
becomes
the
initial
tuple
stream
that
serves
as
input
to
the
next
clause
of
the
FLWOR
expression.
If
ordering
mode
is
ordered
,
the
resulting
sequence
order
of
variable
bindings
is
ordered
according
to
tuples
in
the
tuple
stream
preserves
the
order
of
values
in
the
binding
sequence;
sequence
;
otherwise
the
ordering
order
of
the
variable
bindings
tuple
stream
is
implementation-dependent
.
A
If
the
binding
sequence
contains
no
items,
the
output
tuple
stream
depends
on
whether
for
allowing
empty
clause
may
also
contain
multiple
variables,
each
with
is
specified.
If
allowing
empty
is
specified,
the
output
tuple
stream
consists
of
one
tuple
in
which
the
variable
is
bound
to
an
associated
expression
whose
value
empty
sequence.
If
allowing
empty
is
not
specified,
the
binding
sequence
output
tuple
stream
consists
of
zero
tuples.
The
following
examples
illustrates
tuple
streams
that
are
generated
by
initial
for
clauses:
Initial clause:
for $x in (100, 200, 300)
or (equivalently):
for $x allowing empty in (100, 200, 300)
Output tuple stream:
($x = 100) ($x = 200) ($x = 300)
Initial clause:
for $x in ()
Output tuple stream contains no tuples.
Initial clause:
for $x allowing empty in ()
Output tuple stream:
($x = ())
[
Definition
:
A
positional
variable
is
a
variable
that
variable.
In
this
case,
is
preceded
by
the
keyword
at
.]
A
positional
variable
may
be
associated
with
a
variable
that
is
bound
in
a
for
clause
iterates
each
clause.
In
this
case,
as
the
main
variable
iterates
over
the
items
in
its
binding
sequence.
The
resulting
sequence
,
the
positional
variable
iterates
over
the
integers
that
represent
the
ordinal
numbers
of
these
items
in
the
binding
sequence
,
starting
with
one.
Each
tuple
in
the
output
tuple
stream
contains
one
tuple
bindings
for
each
combination
of
values
in
both
the
respective
binding
sequences.
main
variable
and
the
positional
variable.
If
ordering
mode
the
binding
sequence
is
empty
and
is
specified,
the
ordered
,
allowing
empty
order
of
positional
variable
in
the
output
tuple
stream
is
determined
primarily
by
bound
to
the
order
integer
zero.
Positional
variables
always
have
the
implied
type
xs:integer
.
The
expanded
QName
of
a
positional
variable
must
be
distinct
from
the
expanded
QName
of
the
main
variable
with
which
it
is
associated
[
err:XQST0089
].
The following examples illustrate how a positional variable would have affected the results of the previous examples that generated tuples:
Initial clause:
for $x at $i in (100, 200, 300)
Output tuple stream:
($x = 100, $i = 1) ($x = 200, $i = 2) ($x = 300, $i = 3)
Initial clause:
for $x allowing empty at $i in ()
Output tuple stream:
($x = (), $i = 0)
If
a
single-variable
for
clause
is
an
intermediate
clause
in
a
FLWOR
expression,
its
binding
sequence
is
evaluated
for
each
input
tuple,
given
the
bindings
in
that
input
tuple.
Each
input
tuple
generates
zero
or
more
tuples
in
the
output
tuple
stream.
Each
of
these
output
tuples
consists
of
the
leftmost
variable,
and
secondarily
by
original
variable
bindings
of
the
input
tuple
plus
a
binding
sequences
of
the
other
variables,
working
from
left
new
variable
to
right.
Otherwise,
the
ordering
one
of
the
variable
bindings
is
implementation-dependent
items
in
its
binding
sequence
.
Note:
A
let
clause
may
also
contain
one
or
more
variables,
Although
the
binding
sequence
is
conceptually
evaluated
independently
for
each
with
input
tuple,
an
associated
expression.
Unlike
optimized
implementation
may
sometimes
be
able
to
avoid
re-evaluating
the
binding
sequence
if
it
can
show
that
the
variables
that
the
binding
sequence
depends
on
have
the
same
values
as
in
a
previous
evaluation.
For
a
given
input
tuple,
if
the
binding
sequence
for
the
new
variable
in
the
for
clause,
however,
a
clause
contains
no
items,
the
result
depends
on
whether
let
allowing
empty
clause
binds
each
is
specified.
If
allowing
empty
is
specified,
the
input
tuple
generates
one
output
tuple,
with
the
original
variable
bindings
plus
a
binding
of
the
new
variable
to
an
empty
sequence.
If
allowing
empty
is
not
specified,
the
result
of
its
associated
expression,
without
iteration.
The
input
tuple
generates
zero
output
tuples
(it
is
not
represented
in
the
output
tuple
stream.)
If
the
new
variable
bindings
generated
introduced
by
a
let
for
clauses
are
added
to
clause
has
an
associated
positional
variable
,
the
binding
output
tuples
generated
by
the
for
clauses.
If
there
are
no
clause
also
contain
bindings
for
clauses,
the
positional
variable
.
In
this
case,
as
the
new
variable
is
bound
to
each
item
in
its
binding
sequence
,
the
positional
variable
is
bound
to
the
ordinal
position
of
that
item
within
the
binding
sequence
,
starting
with
one.
Note
that,
since
the
positional
variable
represents
a
position
within
a
binding
sequence
,
the
output
tuples
corresponding
to
each
input
tuple
are
independently
numbered,
starting
with
one.
For
a
given
input
tuple,
if
the
binding
sequence
is
empty
and
let
allowing
empty
clauses
generate
one
tuple
containing
all
is
specified,
the
positional
variable
bindings.
in
the
output
tuple
is
bound
to
the
integer
zero.
Although
for
and
If
ordering
mode
is
,
the
let
clauses
both
bind
variables,
ordered
manner
tuples
in
the
output
tuple
stream
are
ordered
primarily
by
the
order
of
the
input
tuples
from
which
variables
they
are
bound
is
quite
different,
as
illustrated
derived,
and
secondarily
by
the
following
examples.
order
of
the
binding
sequence
for
the
new
variable;
otherwise
the
order
of
the
output
tuple
stream
is
implementation-dependent
.
The
first
example
uses
a
following
examples
illustrates
the
effects
of
intermediate
let
for
clause:
clauses:
Input tuple stream:
<span class= "parse-test">let $s := (<one/>, <two/>, <three/>) return <out>{$s}</out>($x = 1) ($x = 2) ($x = 3) ($x = 4)
The
variable
Intermediate
clause:
$s
for
for $y in ($x to 3)
Output
tuple
stream
(assuming
ordering
mode
is
bound
to
the
result
of
the
expression
):
(<one/>,
<two/>,
<three/>)
.
Since
ordered
($x = 1, $y = 1) ($x = 1, $y = 2) ($x = 1, $y = 3) ($x = 2, $y = 2) ($x = 2, $y = 3) ($x = 3, $y = 3)
Note:
In
this
example,
there
are
is
no
output
tuple
that
corresponds
to
the
input
tuple
for
($x
=
4)
clauses,
because,
when
the
clause
let
for
generates
one
tuple
that
contains
is
evaluated
with
the
bindings
in
this
input
tuple,
the
resulting
binding
of
$s
.
The
sequence
for
return
$y
clause
is
invoked
for
this
tuple,
creating
empty.
This
example
shows
how
the
following
output:
previous
example
would
have
been
affected
by
a
positional
variable
(assuming
the
same
input
tuple
stream):
<out> <one/> <two/> <three/> </out>for $y at $j in ($x to 3)
The
next
example
Output
tuple
stream
(assuming
ordering
mode
is
a
similar
query
that
contains
a
for
clause
instead
of
a
let
ordered
clause:
):
<span class= "parse-test">for $s in (<one/>, <two/>, <three/>) return <out>{$s}</out>($x = 1, $y = 1, $j = 1) ($x = 1, $y = 2, $j = 2) ($x = 1, $y = 3, $j = 3) ($x = 2, $y = 2, $j = 1) ($x = 2, $y = 3, $j = 2) ($x = 3, $y = 3, $j = 1)
In
this
example,
This
example
shows
how
the
variable
previous
example
would
have
been
affected
by
.
Note
that
$s
allowing
empty
allowing
empty
iterates
over
causes
the
given
expression.
If
ordering
mode
is
ordered
,
input
tuple
$s
($x
=
4)
is
first
bound
to
be
represented
in
the
output
tuple
stream,
even
though
the
binding
sequence
for
contains
no
items
for
this
input
tuple.
This
example
illustrates
that
<one/>
,
then
to
$y
in
a
<two/>
,
and
finally
to
allowing
empty
clause
serves
a
purpose
similar
to
that
of
<three/>
.
One
tuple
is
generated
for
each
these
bindings,
and
an
"outer
join"
in
a
relational
database
query.
(Assume
the
same
input
tuple
stream
as
in
the
previous
example.)
for $y allowing empty at $j in ($x to 3)
Output
tuple
stream
(assuming
ordering
mode
is
return
ordered
clause
is
invoked
for
each
tuple,
creating
the
following
output:
):
<out> <one/> </out> <out> <two/> </out> <out> <three/> </out>($x = 1, $y = 1, $j = 1) ($x = 1, $y = 2, $j = 2) ($x = 1, $y = 3, $j = 3) ($x = 2, $y = 2, $j = 1) ($x = 2, $y = 3, $j = 2) ($x = 3, $y = 3, $j = 1) ($x = 4, $y = (), $j = 0)
The
following
This
example
illustrates
shows
how
binding
tuples
are
generated
by
a
for
clause
that
contains
multiple
binds
two
variables
when
ordering
mode
is
semantically
equivalent
to
two
clauses
that
bind
one
variable
each.
We
assume
that
this
ordered
.
for
for
clause
occurs
at
the
beginning
of
a
FLWOR
expression.
It
is
equivalent
to
an
initial
single-variable
for
clause
that
provides
an
input
tuple
stream
to
an
intermediate
single-variable
for
clause.
for $i in (1, 2), $j in (3, 4)for $x in (1, 2, 3, 4), $y in ($x to 3)
The
Output
tuple
stream
generated
by
the
above
(assuming
ordering
mode
is
for
ordered
clause
is
as
follows:
):
($i = 1, $j = 3) ($i = 1, $j = 4) ($i = 2, $j = 3) ($i = 2, $j = 4)($x = 1, $y = 1) ($x = 1, $y = 2) ($x = 1, $y = 3) ($x = 2, $y = 2) ($x = 2, $y = 3) ($x = 3, $y = 3)
If
In
the
above
examples,
if
ordering
mode
were
had
been
unordered
,
the
for
clause
in
the
above
example
output
tuple
streams
would
generate
have
consisted
of
the
same
tuple
stream
tuples,
with
the
same
values
for
the
positional
variables
,
but
the
order
ordering
of
the
tuples
would
be
have
been
implementation-dependent
.
A
for
clause
may
contain
one
or
more
type
declarations
,
identified
by
the
keyword
as
.
The
scope
semantics
of
type
declarations
are
defined
in
3.8.1
Variable
Bindings
.
[49] |
LetClause
| ::= |
"let"
LetBinding
(","
LetBinding
)*
|
[50] |
LetBinding
| ::= |
"$"
VarName
TypeDeclaration
?
":="
ExprSingle
|
[166] |
TypeDeclaration
| ::= |
"as"
SequenceType
|
The
purpose
of
a
let
clause
is
to
bind
values
to
one
or
more
variables.
Each
variable
is
bound
in
to
the
result
of
evaluating
an
expression.
If
a
for
let
or
clause
contains
multiple
variables,
it
is
semantically
equivalent
to
multiple
let
clauses,
each
containing
a
single
variable.
For
example,
the
clause
comprises
all
subexpressions
let $x := $expr1, $y := $expr2
is semantically equivalent to the following sequence of clauses:
let $x := $expr1 let $y := $expr2
In
the
remainder
of
this
section,
we
define
the
semantics
of
a
let
clause
containing
FLWOR
a
single
variable
V
and
an
associated
expression
that
appear
after
E
.
If
a
single-variable
let
clause
is
the
variable
binding.
The
scope
does
not
include
initial
clause
in
a
FLWOR
expression,
it
simply
binds
the
expression
variable
V
to
which
the
variable
is
bound.
result
of
the
expression
E
.
The
following
example
illustrates
how
bindings
in
result
of
the
for
let
and
clause
is
a
tuple
stream
consisting
of
one
tuple
with
a
single
binding
that
binds
V
to
the
result
of
E
.
This
tuple
stream
serves
as
input
to
the
next
clause
in
the
FLWOR
expression.
If
a
single-variable
let
clauses
may
reference
variables
that
were
bound
clause
is
an
intermediate
clause
in
earlier
clauses,
or
a
FLWOR
expression,
it
adds
a
new
binding
for
variable
V
to
each
tuple
in
earlier
the
input
tuple
stream.
For
each
input
tuple,
the
value
bound
to
V
is
the
result
of
evaluating
expression
E
,
given
the
bindings
that
are
already
present
in
that
input
tuple.
The
resulting
tuples
become
the
same
clause
output
tuple
stream
of
the
FLWOR
expression:
let
clause.
The
for
and
number
of
tuples
in
the
output
tuple
stream
of
an
intermediate
let
clauses
of
a
given
FLWOR
expression
may
bind
clause
is
the
same
variable
name
as
the
number
of
tuples
in
the
input
tuple
stream.
The
number
of
bindings
in
the
output
tuples
is
one
more
than
once.
In
the
number
of
bindings
in
the
input
tuples,
unless
the
input
tuples
already
contain
bindings
for
V
;
in
this
case,
each
the
new
binding
for
V
occludes
(replaces)
the
previous
one,
which
becomes
inaccessible
in
earlier
binding
for
V
,
and
the
remainder
number
of
the
FLWOR
expression.
bindings
is
unchanged.
Each
variable
bound
A
let
clause
may
contain
one
or
more
type
declarations
,
identified
by
the
keyword
as
.
The
semantics
of
type
declarations
are
defined
in
3.8.1
Variable
Bindings
.
The
following
code
fragment
illustrates
how
a
for
or
clause
and
a
let
clause
may
have
can
be
used
together.
The
for
clause
produces
an
optional
type
declaration
,
which
is
initial
tuple
stream
containing
a
type
declared
using
binding
for
variable
$d
to
each
department
number
found
in
a
given
input
document.
The
let
clause
adds
an
additional
binding
to
each
tuple,
binding
variable
$e
to
a
sequence
of
employees
whose
department
number
matches
the
syntax
value
of
$d
in
that
tuple.
for $d in fn:doc("depts.xml")/depts/deptno let $e := fn:doc("emps.xml")/emps/emp[deptno eq $d]
[51] |
WindowClause
| ::= |
"for"
(
TumblingWindowClause
|
SlidingWindowClause
)
|
[52] |
TumblingWindowClause
| ::= |
"tumbling"
"window"
"$"
VarName
TypeDeclaration
?
"in"
ExprSingle
WindowStartCondition
WindowEndCondition
?
|
[53] |
SlidingWindowClause
| ::= |
"sliding"
"window"
"$"
VarName
TypeDeclaration
?
"in"
ExprSingle
WindowStartCondition
WindowEndCondition
|
[54] |
WindowStartCondition
| ::= |
"start"
WindowVars
"when"
ExprSingle
|
[55] |
WindowEndCondition
| ::= |
"only"?
"end"
WindowVars
"when"
ExprSingle
|
[56] |
WindowVars
| ::= |
("$"
CurrentItem
)?
PositionalVar
?
("previous"
"$"
PreviousItem
)?
("next"
"$"
NextItem
)?
|
[57] |
CurrentItem
| ::= |
QName
|
[48] |
PositionalVar
| ::= |
"at"
"$"
VarName
|
[58] |
PreviousItem
| ::= |
QName
|
[59] |
NextItem
| ::= |
QName
|
Like
a
for
clause,
a
window
clause
iterates
over
its
binding
sequence
and
generates
a
sequence
of
tuples.
In
the
type
case
of
a
value
window
clause,
each
tuple
represents
a
window.
[
Definition
:
A
window
is
a
sequence
of
consecutive
items
drawn
from
the
binding
sequence
.]
Each
window
is
represented
by
at
least
one
and
at
most
nine
bound
variables.
The
variables
have
user-specified
names,
but
their
roles
are
as
follows:
Window-variable:
Bound
to
the
variable
does
not
match
sequence
of
items
from
the
declared
binding
sequence
that
comprise
the
window.
Start-item: (Optional) Bound to the first item in the window.
Start-item-position:
(Optional)
Bound
to
the
ordinal
position
of
the
first
window
item
in
the
binding
sequence
.
Start-item-position
is
a
positional
variable
.
Its
type
according
is
xs:integer
,
and
its
expanded
QName
must
be
distinct
from
the
expanded
QName
of
start-item
[
err:XQST0089
].
Start-previous-item:
(Optional)
Bound
to
the
rules
for
SequenceType
matching
,
item
in
the
binding
sequence
that
precedes
the
first
item
in
the
window
(empty
sequence
if
none).
Start-next-item: (Optional) Bound to the item in the binding sequence that follows the first item in the window (empty sequence if none).
End-item: (Optional) Bound to the last item in the window.
End-item-position:
(Optional)
Bound
to
the
ordinal
position
of
the
last
window
item
in
the
binding
sequence
.
End-item-position
is
a
positional
variable
.
Its
type
is
xs:integer
,
and
its
expanded
QName
must
be
distinct
from
the
expanded
QName
of
end-item
[
err:XQST0089
].
End-previous-item: (Optional) Bound to the item in the binding sequence that precedes the last item in the window (empty sequence if none).
End-next-item: (Optional) Bound to the item in the binding sequence that follows the last item in the window (empty sequence if none).
All
variables
in
a
window
clause
must
have
distinct
names;
otherwise
a
static
error
is
raised
[
err:XPTY0004
err:XQST0103
].
For
example,
the
The
following
expression
raises
is
an
example
of
a
type
error
because
window
clause
that
binds
nine
variables
to
the
variable
roles
listed
above.
In
this
example,
the
variables
are
named
,$salary
$w
$s
,
$spos
,
$sprev
,
$snext
,
$e
,
$epos
,
$eprev
,
and
$enext
has
respectively.
A
window
clause
always
binds
the
window
variable,
but
typically
binds
only
a
type
declaration
that
subset
of
the
other
variables.
for tumbling window $w in (2, 4, 6, 8, 10) start $s at $spos previous $sprev next $snext when true() end $e at $epos previous $eprev next $enext when true()
Windows
are
created
by
iterating
over
the
items
in
the
binding
sequence
,
in
order,
identifying
the
start
item
and
the
end
item
of
each
window
by
evaluating
the
WindowStartCondition
and
the
WindowEndCondition
.
Each
of
these
conditions
is
not
satisfied
by
if
the
effective
boolean
value
of
the
expression
following
the
when
keyword
is
true
.
The
start
item
of
the
window
is
an
item
that
satisfies
the
WindowStartCondition
(see
3.8.4.1
Tumbling
Windows
and
3.8.4.2
Sliding
Windows
for
a
more
complete
explanation.)
The
end
item
of
the
window
is
the
first
item
in
the
binding
sequence
,
beginning
with
the
start
item,
that
satisfies
the
WindowEndCondition
(again,
see
3.8.4.1
Tumbling
Windows
and
3.8.4.2
Sliding
Windows
for
more
details.)
Each
window
contains
its
start
item,
its
end
item,
and
all
items
that
occur
between
them
in
the
binding
sequence
.
If
the
end
item
is
the
start
item,
then
the
window
contains
only
one
item.
If
a
start
item
is
identified,
but
no
following
item
in
the
binding
sequence
satisfies
the
WindowEndCondition
,
then
the
only
keyword
determines
whether
a
window
is
generated:
if
only
end
is
specified,
then
no
window
is
generated;
otherwise,
the
end
item
is
set
to
the
last
item
in
the
binding
sequence
and
a
window
is
generated.
In
the
above
example,
the
WindowStartCondition
and
WindowEndCondition
are
both
true()
,
which
causes
each
tuple
in
the
binding
sequence
to
be
in
a
separate
window.
Typically,
the
WindowStartCondition
and
WindowEndCondition
are
expressed
in
terms
of
bound
variables.
For
example,
the
following
WindowStartCondition
might
be
used
to
start
a
new
window
for
every
item
in
the
variable:
binding
sequence
that
is
larger
than
both
the
previous
item
and
the
following
item:
let $salary as xs:decimal := "cat" return $salary * 2start $s previous $sprev next $snext when $s > $sprev and $s > $snext
Each
variable
The
scoping
rules
for
the
variables
bound
in
by
a
clause
for
window
may
have
an
associated
positional
variable
are
as
follows:
In
the
when
-expression
of
the
WindowStartCondition
,
the
following
variables
(identified
here
by
their
roles)
are
in
scope
(if
bound):
start-item,
start-item-position,
start-previous-item,
start-next-item.
In
the
when
-expression
of
the
WindowEndCondition
,
the
following
variables
(identified
here
by
their
roles)
are
in
scope
(if
bound):
start-item,
start-item-position,
start-previous-item,
start-next-item,
end-item,
end-item-position,
end-previous-item,
end-next-item.
In
the
clauses
of
the
FLWOR
expression
that
is
bound
at
follow
the
same
time.
The
name
window
clause,
all
nine
of
the
positional
variable
is
preceded
variables
bound
by
the
window
clause
(including
window-variable
)
are
in
scope
(if
bound).
In
a
window
clause,
the
keyword
or
at
.
The
positional
variable
always
has
an
implied
type
tumbling
sliding
determines
the
way
in
which
the
starting
item
of
each
window
is
identified,
as
explained
in
the
following
sections.
If
the
window
type
is
,
then
windows
never
overlap.
The
search
for
the
start
of
the
first
window
begins
at
the
beginning
of
the
binding
sequence
.
After
each
window
is
generated,
the
search
for
the
start
of
the
next
window
begins
with
the
item
in
the
binding
sequence
that
occurs
after
the
ending
item
of
the
last
generated
window.
Thus,
no
item
that
occurs
in
one
window
can
occur
in
another
window
drawn
from
the
same
binding
sequence
.
In
a
xs:integer
.
As
tumbling
variable
iterates
over
tumbling
window
clause,
the
end
clause
is
optional;
if
it
is
omitted,
the
start
clause
is
applied
to
identify
all
potential
starting
items
in
its
the
binding
sequence
,
its
positional
variable
iterates
over
the
integers
and
a
window
is
constructed
for
each
starting
item,
including
all
items
from
that
represent
starting
item
up
to
the
ordinal
positions
item
before
the
next
window's
starting
item,
or
the
end
of
those
the
binding
sequence
,
whichever
comes
first.
The following examples illustrate the use of tumbling windows.
Show non-overlapping windows of three items.
for tumbling window $w in (2, 4, 6, 8, 10, 12, 14) start at $s when fn:true() only end at $e when $e - $s eq 2 return <window>{ $w }</window>
Result of the above query:
<window>2 4 6</window> <window>8 10 12</window>
Show averages of non-overlapping three-item windows.
for tumbling window $w in (2, 4, 6, 8, 10, 12, 14) start at $s when fn:true() only end at $e when $e - $s eq 2 return avg($w)
Result of the above query:
4 10
Show first and last items in each window of three items.
for tumbling window $w in (2, 4, 6, 8, 10, 12, 14) start $first at $s when fn:true() only end $last at $e when $e - $s eq 2 return <window>{ $first, $last }</window>
Result
of
the
binding
sequence,
above
query:
<window>2 6</window> <window>8 12</window>
Show
non-overlapping
windows
of
up
to
three
items
(illustrates
end
clause
without
the
only
keyword).
for tumbling window $w in (2, 4, 6, 8, 10, 12, 14) start at $s when fn:true() end at $e when $e - $s eq 2 return <window>{ $w }</window>
Result of the above query:
<window>2 4 6</window> <window>8 10 12</window> <window>14</window>
Show
non-overlapping
windows
of
up
to
three
items
(illustrates
use
of
start
without
explicit
end
).
for tumbling window $w in (2, 4, 6, 8, 10, 12, 14) start at $s when $s mod 3 = 1 return <window>{ $w }</window>
Result of the above query:
<window>2 4 6</window> <window>8 10 12</window> <window>14</window>
Show
non-overlapping
sequences
starting
with
1.
The
expanded
QName
a
number
divisible
by
3.
for tumbling window $w in (2, 4, 6, 8, 10, 12, 14) start $first when $first mod 3 = 0 return <window>{ $w }</window>
Result of the above query:
<window>6 8 10</window> <window>12 14</window>
If
the
window
type
is
sliding
window
,
then
windows
may
overlap.
Every
item
in
the
binding
sequence
that
satisfies
the
WindowStartCondition
is
the
starting
item
of
a
positional
variable
must
new
window.
Thus,
a
given
item
may
be
distinct
found
in
multiple
windows
drawn
from
the
expanded
QName
same
binding
sequence
.
The following examples illustrate the use of sliding windows.
Show windows of three items.
for sliding window $w in (2, 4, 6, 8, 10, 12, 14) start at $s when fn:true() only end at $e when $e - $s eq 2 return <window>{ $w }</window>
Result
of
the
variable
with
which
it
is
associated
[
err:XQST0089
].
above
query:
<window>2 4 6</window> <window>4 6 8</window> <window>6 8 10</window> <window>8 10 12</window> <window>10 12 14</window>
Positional
variables
are
illustrated
by
Show
moving
averages
of
three
items.
for sliding window $w in (2, 4, 6, 8, 10, 12, 14) start at $s when fn:true() only end at $e when $e - $s eq 2 return avg($w)
Result
of
the
following
above
query:
4 6 8 10 12
Show
overlapping
windows
of
up
to
three
items
(illustrates
for
end
clause:
clause
without
the
only
keyword).
for $car at $i in ("Ford", "Chevy"), $pet at $j in ("Cat", "Dog")for sliding window $w in (2, 4, 6, 8, 10, 12, 14) start at $s when fn:true() end at $e when $e - $s eq 2 return <window>{ $w }</window>
Result of the above query:
<window>2 4 6</window> <window>4 6 8</window> <window>6 8 10</window> <window>8 10 12</window> <window>10 12 14</window> <window>12 14</window> <window>14</window>
The
effects
of
a
window
clause
on
the
tuple
stream
are
similar
to
the
effects
of
a
for
clause.
As
described
in
3.8.4
Window
Clause
,
a
window
clause
generates
zero
or
more
windows,
each
of
which
is
represented
by
at
least
one
and
at
most
nine
bound
variables.
If
the
window
clause
is
the
initial
clause
in
a
FLWOR
expression,
the
bound
variables
that
describe
each
window
become
an
output
tuple.
These
tuples
form
the
initial
tuple
stream
that
serves
as
input
to
the
next
clause
of
the
FLWOR
expression.
If
ordering
mode
is
ordered
,
the
order
of
tuples
in
the
tuple
stream
generated
by
is
the
above
order
in
which
their
start
items
appear
in
the
binding
sequence
;
otherwise
the
order
of
the
tuple
stream
is
implementation-dependent
.
The
cardinality
of
the
tuple
stream
is
equal
to
the
number
of
windows.
If
a
clause
is
for
window
as
follows:
($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")
an
intermediate
clause
in
a
FLWOR
expression,
each
input
tuple
generates
zero
or
more
output
tuples,
each
consisting
of
the
original
bound
variables
of
the
input
tuple
plus
the
new
bound
variables
that
represent
one
of
the
generated
windows.
For
each
tuple
T
in
the
input
tuple
stream,
the
output
tuple
stream
will
contain
N
T
tuples,
where
N
T
is
the
number
of
windows
generated
by
the
window
clause,
given
the
bindings
in
the
input
tuple
T
.
Input
tuples
for
which
no
windows
are
generated
are
not
represented
in
the
output
tuple
stream.
If
ordering
mode
is
ordered
,
the
order
of
tuples
in
the
output
stream
is
determined
primarily
by
the
order
of
the
input
tuples
from
which
they
were
derived,
and
secondarily
by
the
order
in
which
their
start
items
appear
in
the
binding
sequence
.
If
ordering
mode
is
unordered
,
the
order
of
tuples
in
the
tuple
output
stream
is
implementation-dependent
.
In
addition,
if
The
following
example
illustrates
a
clause
for
window
contains
subexpressions
that
is
the
initial
clause
in
a
FLWOR
expression.
The
example
is
based
on
input
data
that
consists
of
a
sequence
of
closing
stock
prices
for
a
specific
company.
For
this
example
we
assume
the
following
input
data
(assume
that
the
price
elements
have
a
validated
type
of
xs:decimal
):
<stock> <closing> <date>2008-01-01</date> <price>105</price> </closing <closing> <date>2008-01-02</date> <price>101</price> </closing <closing> <date>2008-01-03</date> <price>102</price> </closing <closing> <date>2008-01-04</date> <price>103</price> </closing <closing> <date>2008-01-05</date> <price>102</price> </closing <closing> <date>2008-01-06</date> <price>104</price> </closing </stock>
A
user
wishes
to
find
"run-ups,"
which
are
affected
by
ordering
mode
,
defined
as
sequences
of
dates
that
begin
with
a
"low"
and
end
with
a
"high"
price
(that
is,
the
association
stock
price
begins
to
rise
on
the
first
day
of
positional
the
run-up,
and
continues
to
rise
or
remain
even
through
the
last
day
of
the
run-up.)
The
following
query
uses
a
tumbling
window
to
find
run-ups
in
the
input
data:
for tumbling window $w in //closing start $first next $second when $first/price < $second/price end $last next $beyond when $last/price > $beyond/price return <run-up> <start-date>{fn:data($first/date)}</start-date> <start-price>{fn:data($first/price)}</start-price> <end-date>{fn:data($last/date)}</end-date> <end-price>{fn:data($last/price)}</end-price> </run-up>
For
our
sample
input
data,
this
tumbling
window
clause
generates
a
tuple
stream
consisting
of
two
tuples,
each
representing
a
window
and
containing
five
bound
variables
named
$w
,
$first
,
$second
,
$last
,
and
$beyond
.
The
return
clause
is
evaluated
for
each
of
these
tuples,
generating
the
following
query
result:
<run-up> <start-date>2008-01-02</start-date> <start-price>101</start-price> <end-date>2008-01-04</start-date> <end-price>103</end-price> </run-up> <run-up> <start-date>2008-01-05</start-date> <start-price>102</start-price> <end-date>2008-01-06</start-date> <end-price>104</end-price> </run-up>
The
following
example
illustrates
a
window
clause
that
is
an
intermediate
clause
in
a
FLWOR
expression.
In
this
example,
the
input
data
contains
closing
stock
prices
for
several
different
companies,
each
identified
by
a
three-letter
symbol.
We
assume
the
following
input
data
(again
assuming
that
the
type
of
the
price
element
is
xs:decimal
):
<stocks> <closing> <symbol>ABC</symbol> <date>2008-01-01</date> <price>105</price> </closing> <closing> <symbol>DEF</symbol> <date>2008-01-01</date> <price>057</price> </closing> <closing> <symbol>ABC</symbol> <date>2008-01-02</date> <price>101</price> </closing> <closing> <symbol>DEF</symbol> <date>2008-01-02</date> <price>054</price> </closing> <closing> <symbol>ABC</symbol> <date>2008-01-03</date> <price>102</price> </closing> <closing> <symbol>DEF</symbol> <date>2008-01-03</date> <price>056</price> </closing> <closing> <symbol>ABC</symbol> <date>2008-01-04</date> <price>103</price> </closing> <closing> <symbol>DEF</symbol> <date>2008-01-04</date> <price>052</price> </closing> <closing> <symbol>ABC</symbol> <date>2008-01-05</date> <price>101</price> </closing> <closing> <symbol>DEF</symbol> <date>2008-01-05</date> <price>055</price> </closing> <closing> <symbol>ABC</symbol> <date>2008-01-06</date> <price>104</price> </closing> <closing> <symbol>DEF</symbol> <date>2008-01-06</date> <price>059</price> </closing> </stocks>
As
in
the
previous
example,
we
want
to
find
"run-ups,"
which
are
defined
as
sequences
of
dates
that
begin
with
items
returned
a
"low"
and
end
with
a
"high"
price
for
a
specific
company.
In
this
example,
however,
the
input
data
consists
of
stock
prices
for
multiple
companies.
Therefore
it
is
necessary
to
isolate
the
stock
prices
of
each
company
before
forming
windows.
This
can
be
accomplished
by
these
subexpressions
an
initial
for
and
let
clause,
followed
by
a
window
clause,
as
follows:
for $symbol in fn:distinct-values(//symbol) let $closings := //closing[symbol = $symbol] for tumbling window $w in $closings start $first next $second when $first/price < $second/price end $last next $beyond when $last/price > $beyond/price return <run-up symbol="{$symbol}"> <start-date>{fn:data($first/date)}</start-date> <start-price>{fn:data($first/price)}</start-price> <end-date>{fn:data($last/date)}</end-date> <end-price>{fn:data($last/price)}</end-price> </run-up>
Note:
In
the
above
example,
the
for
and
let
clauses
could
be
rewritten
as
follows:
for $closings in //closing let $symbol := $closings/symbol group by $symbol
The
group
by
clause
is
implementation-dependent
if
ordering
mode
described
in
3.8.7
Group
By
Clause
.
The
for
and
let
clauses
in
this
query
generate
an
initial
tuple
stream
consisting
of
two
tuples.
In
the
first
tuple,
$symbol
is
bound
to
"ABC"
and
is
bound
to
the
sequence
of
unordered
$closings
closing
elements
for
company
ABC.
In
the
second
tuple,
$symbol
is
bound
to
"DEF"
and
$closings
is
bound
to
the
sequence
of
closing
elements
for
company
DEF.
The
window
clause
operates
on
this
initial
tuple
stream,
generating
two
windows
for
the
first
tuple
and
two
windows
for
the
second
tuple.
The
result
is
a
tuple
stream
consisting
of
four
tuples,
each
with
the
following
bound
variables:
$symbol
,
$closings
,
$w
,
$first
,
$second
,
$last
,
and
$beyond
.
The
return
clause
is
then
evaluated
for
each
of
these
tuples,
generating
the
following
query
result:
<run-up symbol="ABC"> <start-date>2008-01-02</start-date> <start-price>101</start-price> <end-date>2008-01-04</start-date> <end-price>103</end-price> </run-up> <run-up symbol="ABC"> <start-date>2008-01-05</start-date> <start-price>101</start-price> <end-date>2008-01-06</start-date> <end-price>104</end-price> </run-up> <run-up symbol="DEF"> <start-date>2008-01-02</start-date> <start-price>54</start-price> <end-date>2008-01-03</start-date> <end-price>56</end-price> </run-up> <run-up symbol="DEF"> <start-date>2008-01-04</start-date> <start-price>52</start-price> <end-date>2008-01-06</start-date> <end-price>59</end-price> </run-up>
[61] |
WhereClause
| ::= |
"where"
ExprSingle
|
The
optional
A
where
clause
serves
as
a
filter
for
the
tuples
of
variable
bindings
generated
by
the
for
and
let
clauses.
in
its
input
tuple
stream.
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
,
output
tuple
stream;
otherwise
the
tuple
is
discarded.
The
effective
boolean
value
Examples:
This
example
illustrates
the
effect
of
an
expression
is
defined
in
a
where
clause
on
a
tuple
stream:
Input tuple stream:
($a = 5, $b = 11) ($a = 91, $b = 42) ($a = 17, $b = 30) ($a = 85, $b = 63)
.
where
clause:
where $a > $b
Output tuple stream:
($a = 91, $b = 42) ($a = 85, $b = 63)
The
following
expression
query
illustrates
how
a
where
clause
might
be
applied
to
used
with
a
positional
variable
in
order
to
perform
sampling
on
an
input
sequence.
This
expression
approximates
the
average
value
in
a
sequence
by
sampling
The
query
returns
one
value
out
of
each
one
hundred
input
values.
<span class= "parse-test">fn:avg(for $x at $i in $inputvalues"parse-test">for $x at $i in $inputvalues where $i mod 100 = 0return $x)return $x
[60] |
CountClause
| ::= |
"count"
"$"
VarName
|
The
purpose
of
a
clause
is
to
enhance
the
tuple
stream
with
a
new
variable
that
is
bound,
in
each
tuple,
to
the
ordinal
position
of
that
tuple
in
the
tuple
stream.
The
name
of
the
new
variable
is
specified
in
the
return
count
count
clause.
The
output
tuple
stream
of
a
FLWOR
expression
count
clause
is
evaluated
once
for
the
same
as
its
input
tuple
stream,
with
each
tuple
enhanced
by
one
additional
variable
that
is
bound
to
the
ordinal
position
of
that
tuple
in
the
tuple
stream.
However,
if
the
name
of
the
new
variable
is
the
same
as
the
name
of
an
existing
variable
in
the
input
tuple
stream,
the
new
variable
occludes
(replaces)
the
existing
variable
of
the
same
name,
and
the
results
number
of
bound
variables
in
each
tuple
is
unchanged.
The
following
examples
illustrate
uses
of
these
evaluations
are
concatenated,
as
if
by
the
comma
operator
,
count
clause:
This
example
illustrates
the
effect
of
a
count
clause
on
an
input
tuple
stream:
Input tuple stream:
($name = "Bob", $age = 21) ($name = "Carol", $age = 19) ($name = "Ted", $age = 20) ($name = "Alice", $age = 22)
count
clause:
count $counter
Output tuple stream:
($name = "Bob", $age = 21, $counter = 1) ($name = "Carol", $age = 19, $counter = 2) ($name = "Ted", $age = 20, $counter = 3) ($name = "Alice", $age = 22, $counter = 4)
This
example
illustrates
how
a
counter
might
be
used
to
form
filter
the
result
of
a
query.
The
query
ranks
products
in
order
by
decreasing
sales,
and
returns
the
FLWOR
expression.
three
products
with
the
highest
sales.
Assume
that
the
variable
$products
is
bound
to
a
sequence
of
product
elements,
each
of
which
has
name
and
sales
child-elements.
for $p in $products order by $p/sales descending count $rank where $rank <= 3 return <product rank="{$rank}"> {$p/name, $p/sales} </product>
If
no
The
result
of
this
query
has
the
following
structure:
<product rank="1"> <name>Toaster</name> <sales>968</sales> </product> <product rank="2"> <name>Blender</name> <sales>520</sales> </product> <product rank="3"> <name>Can Opener</name> <sales>475</sales> </product>
[62] |
| ::= |
"group"
"by"
GroupingSpecList
|
[63] |
GroupingSpecList
| ::= |
GroupingSpec
(","
GroupingSpec
)*
|
[64] |
GroupingSpec
| ::= |
"$"
VarName
("collation"
URILiteral
)?
|
A
group
by
clause
is
present,
the
order
generates
an
output
tuple
stream
in
which
each
tuple
represents
a
group
of
tuples
from
the
input
tuple
stream.
We
will
refer
to
the
tuples
in
the
input
tuple
stream
as
pre-grouping
tuples
,
and
the
tuples
in
the
output
tuple
stream
as
post-grouping
tuples
.
The
post-grouping
tuples
have
exactly
the
same
variable-names
as
the
pre-grouping
tuples.
The
number
of
post-grouping
tuples
is
determined
by
less
than
or
equal
to
the
number
of
pre-grouping
tuples.
The
group
by
clause
assigns
each
pre-grouping
tuple
to
a
group,
and
generates
one
post-grouping
tuple
for
each
group.
Subsequent
clauses
in
the
FLWOR
expression
see
only
the
variable
bindings
in
the
post-grouping
tuples;
they
no
longer
have
access
to
the
variable
bindings
in
the
pre-grouping
tuples.
[
Definition
:
A
group
by
clause
consists
of
the
keywords
group
by
followed
by
one
or
more
variables
called
grouping
variables
.]
The
name
of
each
grouping
variable
must
be
equal
(by
the
eq
operator
on
expanded
QNames)
to
the
name
of
a
bound
variable
in
the
input
tuple
stream;
otherwise
a
static
error
is
raised
[
err:XQST0094
].
[ Definition : Equivalence of two atomic values V1 and V2 is defined by the following equivalence rules:
|
]
The process of group formation proceeds as follows:
[ Definition : The atomized value of a grouping variable is called a grouping key .] For each pre-grouping tuple, the grouping keys are created by atomizing the values of the grouping variables . If the resulting value for any grouping variable consists of more than one item, a dynamic error is raised [ err:XQDY0095 ].
The input tuple stream is partitioned into groups of tuples whose grouping keys are equivalent. Two tuples T1 and T2 are in the same group if and only if, for each grouping variable GV , the atomized value of GV in T1 is equivalent to the atomized value of GV in T2 .
Each group of tuples produced by the above process results in one post-grouping tuple. The pre-grouping tuples from which the group is derived have equivalent grouping keys , but these keys are not necessarily identical (for example, the strings "Frog" and "frog" might be equivalent according to the collation in use.) In the post-grouping tuple, each grouping variable is bound to the value of one of the original grouping variables. The choice of which grouping variable is chosen is implementation-dependent .
Editorial note | |
Some
members
of
the
XQuery
Working
Group
would
prefer
that
the
grouping
variables
in
the
post-grouping
tuple
contain
the
grouping
key
for
a
|
In
either
case,
the
resulting
post-grouping
tuple
generated
for
a
given
group,
each
non-grouping
variable
is
bound
to
a
sequence
containing
the
concatenated
values
of
that
variable
in
all
the
pre-grouping
tuples
that
were
assigned
to
that
group.
If
ordering
mode
is
ordered
,
the
values
derived
from
individual
tuples
are
concatenated
in
a
way
that
preserves
the
order
determines
of
the
pre-grouping
tuple
stream;
otherwise
the
ordering
of
these
values
is
implementation-dependent
.
Note:
This behavior may be surprising to SQL programmers, since SQL reduces the equivalent of a non-grouping variable to one representative value. Consider the following query:
let $x := 64000 for $c in //customer let $d := $c/department where $c/salary > $x group by $d return <department name="{$d}"> Number of employees earning more than ${$x} is {count($c)} </department>
If there are three qualifying customers in the sales department this evaluates to:
<department name="sales"> Number of employees earning more than $64000 64000 64000 is 3 </department>
In
XQuery,
each
group
is
a
sequence
of
items
that
match
the
group
by
criteria—in
a
tree-structured
language
like
XQuery,
this
is
convenient,
because
further
structures
can
be
built
based
on
the
items
in
this
sequence.
Because
there
are
three
items
in
the
group,
$x
evaluates
to
a
sequence
of
three
items.
To
reduce
this
to
one
item,
use
fn:distinct-values()
:
let $x := 64000 for $c in //customer let $d := $c/department where $c/salary > $x group by $d return <department name="{$d}"> Number of employees earning more than ${distinct-values($x)} is {count($c)} </department>
Note:
In general, the static type of a variable in a post-grouping tuple is different from the static type of the variable with the same name in the pre-grouping tuples.
The order in which tuples appear in the post-grouping tuple stream is implementation-dependent .
Note:
An
clause
can
be
used
to
impose
a
value-based
ordering
on
the
post-grouping
tuple
stream.
Similarly,
if
it
is
return
order
by
evaluated,
once
for
each
tuple,
using
desired
to
impose
a
value-based
ordering
within
a
group
(i.e.,
on
the
sequence
of
items
bound
to
a
non-grouping
variable),
this
can
be
accomplished
by
a
nested
FLWOR
expression
that
iterates
over
these
items
and
applies
an
order
by
clause.
In
some
cases,
a
value-based
ordering
within
groups
can
be
accomplished
by
applying
an
order
by
clause
on
a
non-grouping
variable
bindings
before
applying
the
group
by
clause.
A
group
by
clause
rebinds
all
the
variables
in
the
respective
input
tuple
stream.
The
scopes
of
these
variables
are
not
affected
by
the
group
by
clause,
but
in
post-grouping
tuples
the
values
of
the
variables
represent
group
properties
rather
than
properties
of
individual
pre-grouping
tuples.
Note
Examples:
This
example
illustrates
the
effect
of
a
group
by
clause
on
a
tuple
stream.
Input tuple stream:
($storeno = <storeno>S101</storeno>, $itemno = <itemno>P78395</itemno>) ($storeno = <storeno>S102</storeno>, $itemno = <itemno>P94738</itemno>) ($storeno = <storeno>S101</storeno>, $itemno = <itemno>P41653</itemno>) ($storeno = <storeno>S102</storeno>, $itemno = <itemno>P70421</itemno>)
group
by
clause:
group by $storeno
Output tuple stream:
($storeno = <storeno>S101</storeno>, $itemno = (<itemno>P78395</itemno>, <itemno>P41653<itemno>)) ($storeno = <storeno>S102</storeno>, $itemno = (<itemno>P94738</itemno>, <itemno>P70421</itemno>))
This
example
and
the
ones
that
ordering
mode
follow
are
based
on
two
separate
sequences
of
elements,
named
$sales
and
$products
.
We
assume
that
the
variable
$sales
is
bound
to
a
sequence
of
elements
with
the
following
structure:
<sales> <storeno>S101</storeno> <itemno>P78395</itemno> <qty>125</qty> </sales>
We
also
assume
that
the
variable
$products
is
bound
to
a
sequence
of
elements
with
the
following
structure:
<product> <itemno>P78395</itemno> <price>25.00</price> <category>Men's Wear</category> </product>
The
simplest
kind
of
grouping
query
has
no
effect
a
single
grouping
variable
.
The
query
in
this
example
finds
the
total
quantity
of
items
sold
by
each
store:
for $s in $sales let $storeno := $s/storeno group by $storeno return <store number="{$storeno}" total-qty="{sum($s/qty)}"/>
The result of this query is a sequence of elements with the following structure:
<store number="S101" total-qty="1550" /> <store number="S102" total-qty="2125" />
In a more realistic example, a user might be interested in the total revenue generated by each store for each product category. Revenue depends on both the quantity sold of various items and the price of each item. The following query joins the two input sequences and groups the resulting tuples by two grouping variables :
for $s in $sales, $p in $products[itemno = $s/itemno] let $storeno := $s/storeno, $category := $p/category, $revenue := $s/qty * $p/price group by $storeno, $category return <summary storeno="{$storeno}" category="{$category}" revenue="{sum($revenue)}"/>
The result of this query is a sequence of elements with the following structure:
<summary storeno="S101" category="Men's Wear" revenue="10185"/> <summary storeno="S101" category="Stationery" revenue="4520"/> <summary storeno="S102" category="Men's Wear" revenue="9750"/> <summary storeno="S102" category="Appliances" revenue="22650"/> <summary storeno="S102" category="Jewelry" revenue="30750"/>
The result of the previous example was a "flat" list of elements. A user might prefer the query result to be presented in the form of a hierarchical report, grouped primarily by store (in order by store number) and secondarily by product category. Within each store, the user might want to see only those product categories whose total revenue exceeds $10,000, presented in descending order by their total revenue. This report is generated by the following query:
for $s1 in $sales let $storeno := $s1/storeno group by $storeno order by $storeno return <store storeno="{$storeno}"> {for $s2 in $s1, $p in $products[itemno = $s2/itemno] let $category := $p/category, $revenue := $s2/qty * $p/price group by $category let $group-revenue := sum($revenue) where $group-revenue > 10000 order by $group-revenue descending return <category name="{$category}" revenue="{$group-revenue}"/> } </store>
The result of this example query has the following structure:
<store storeno="S101"> <category name="Men's Wear" revenue="10185"/> </store> <store storeno="S102"> <category name="Jewelry" revenue="30750"/> <category name="Appliances" revenue="22650"/> </store>
When
writing
a
query
that
includes
a
group
by
clause,
it
is
important
to
remember
that,
in
each
post-grouping
tuple,
each
grouping
variable
is
bound
to
a
single
atomic
value
(a
grouping
key
),
and
all
other
variables
are
bound
to
sequences
of
items
derived
from
all
the
pre-grouping
tuples
from
which
the
group
was
formed.
The
following
example
illustrates
how
to
avoid
a
possible
pitfall
in
writing
grouping
queries.
let $high-price := 1000 for $p in $products[price > $high-price] let $category := $p/category group by $category return <category name="{$category}"> {fn:count($p)} products have price greater than {$high-price}. </category>
If three products in the "Men's Wear" category have prices greater than 1000, the result of this query might look (in part) like this:
<category name="Men's Wear"> 3 products have price greater than 1000 1000 1000. </category>
The
repetition
of
"1000"
in
this
query
result
is
due
to
the
fact
that
$high-price
is
not
a
grouping
variable
.
One
way
to
avoid
this
repetition
is
to
move
the
binding
of
$high-price
to
an
outer-level
FLWOR
expression
if
expression,
as
follows:
let $high-price := 1000 return for $p in $products[price > $high-price] let $category := $p/category group by $category return <category name="{$category}"> {fn:count($p)} products have price greater than {$high-price}. </category>
The result of the revised query might contain the following element:
<category name="Men's Wear"> 3 products have price greater than 1000. </category>
[65] |
OrderByClause
| ::= |
(("order"
"by")
|
("stable"
"order"
"by"))
OrderSpecList
|
[66] |
OrderSpecList
| ::= |
OrderSpec
(","
OrderSpec
)*
|
[67] |
OrderSpec
| ::= |
ExprSingle
OrderModifier
|
[68] |
OrderModifier
| ::= |
("ascending"
|
"descending")?
("empty"
("greatest"
|
"least"))?
("collation"
URILiteral
)?
|
The
purpose
of
an
order
by
clause
is
present,
since
to
impose
a
value-based
ordering
on
the
tuples
in
the
tuple
stream.
The
output
tuple
stream
of
the
order
by
takes
precedence
over
ordering
mode
.
clause
contains
the
same
tuples
as
its
input
tuple
stream,
but
the
tuples
may
be
in
a
different
order.
An
order
by
clause
contains
one
or
more
ordering
specifications,
called
orderspecs
,
as
shown
in
the
grammar
above.
grammar.
For
each
tuple
in
the
input
tuple
stream,
after
filtering
by
the
where
clause,
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
an
orderspec
specifies
a
collation
,
that
collation
is
used
in
comparing
values
of
type
xs:string
,
xs:anyURI
,
or
types
derived
from
them
(otherwise,
the
default
collation
is
used).
used
in
comparing
values
of
these
types).
If
an
orderspec
specifies
a
collation
by
a
relative
URI,
that
relative
URI
is
resolved
to
an
absolute
URI
using
the
base
URI
in
the
static
context
.
If
an
orderspec
specifies
a
collation
that
is
not
found
in
statically
known
collations
,
an
error
is
raised
[
err:XQST0076
].
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:XPTY0004 ].
If
the
value
of
an
orderspec
has
the
dynamic
type
xs:untypedAtomic
(such
as
character
data
in
a
schemaless
document),
it
is
cast
to
the
type
xs:string
.
Note:
Consistently treating untyped values as strings enables the sorting process to begin without complete knowledge of the types of all the values to be sorted.
All
the
non-empty
orderspec
values
must
be
convertible
to
a
common
type
by
subtype
substitution
and/or
type
promotion
.
The
ordering
is
performed
in
the
least
common
type
that
has
a
gt
operator.
If
two
or
more
non-empty
orderspec
values
are
not
convertible
to
a
common
type
that
has
a
gt
operator,
a
type
error
is
raised
[
err:XPTY0004
].
Example:
The
orderspec
values
include
a
value
of
type
hatsize
,
which
is
derived
from
xs:integer
,
and
a
value
of
type
shoesize
,
which
is
derived
from
xs:decimal
.
The
least
common
type
reachable
by
subtype
substitution
and
type
promotion
is
xs:decimal
.
Example:
The
orderspec
values
include
a
value
of
type
xs:string
and
a
value
of
type
xs:anyURI
.
The
least
common
type
reachable
by
subtype
substitution
and
type
promotion
is
xs:string
.
When
two
orderspec
values
are
compared
to
determine
For
the
purpose
of
determining
their
relative
position
in
the
ordering
sequence,
the
greater-than
relationship
between
two
orderspec
values
W
and
V
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:
rules
are
applied
in
order:
If
V
is
an
empty
sequence
and
W
is
not
an
empty
sequence.
sequence,
then
W
greater-than
V
is
true.
If
V
is
NaN
and
W
is
neither
,
NaN
nor
an
empty
sequence.
No
collation
is
specified,
and
sequence,
then
W
gt
greater-than
V
is
true.
A
If
a
specific
collation
C
is
specified,
and
V
and
W
are
both
of
type
xs:string
or
are
convertible
to
xs:string
by
subtype
substitution
and/or
type
promotion
,
then:
If
fn:compare(V,
W,
C)
is
less
than
zero.
zero,
then
W
greater-than
V
is
true;
otherwise
W
greater-than
V
is
false.
If none of the above rules apply, then:
If
W
gt
V
is
true,
then
W
greater-than
V
is
true;
otherwise
W
greater-than
V
is
false.
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:
rules
are
applied
in
order:
If
W
is
an
empty
sequence
and
V
is
not
an
empty
sequence.
sequence,
then
W
greater-than
V
is
true.
If
W
is
NaN
and
V
is
neither
,
NaN
nor
an
empty
sequence.
No
collation
is
specified,
and
sequence,
then
W
gt
greater-than
V
is
true.
A
If
a
specific
collation
C
is
specified,
and
V
and
W
are
both
of
type
xs:string
or
are
convertible
to
xs:string
by
subtype
substitution
and/or
type
promotion
,
then:
If
fn:compare(V,
W,
C)
is
less
than
zero.
zero,
then
W
greater-than
V
is
true;
otherwise
W
greater-than
V
is
false.
If none of the above rules apply, then:
If
W
gt
V
is
true,
then
W
greater-than
V
is
true;
otherwise
W
greater-than
V
is
false.
When
the
orderspec
specifies
neither
empty
least
nor
empty
greatest
,
the
default
order
for
empty
sequences
in
the
static
context
determines
whether
the
rules
for
empty
least
or
empty
greatest
are
used.
If T1 and T2 are two tuples in the input 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
output
tuple
stream;
otherwise,
T2
precedes
T1
in
the
output
tuple
stream.
If
V2
is
greater-than
V1:
V1
:
If
the
orderspec
specifies
descending
,
then
T2
precedes
T1
in
the
output
tuple
stream;
otherwise,
T1
precedes
T2
in
the
output
tuple
stream.
If
neither
V1
nor
V2
is
greater-than
the
other
for
any
pair
of
orderspecs
for
tuples
T1
and
T2,
T2
,
the
following
rules
apply.
If
stable
is
specified,
the
original
order
of
T1
and
T2
is
preserved
in
the
output
tuple
stream.
If
stable
is
not
specified,
the
order
of
T1
and
T2
in
the
output
tuple
stream
is
implementation-dependent
.
Note:
If
two
orderspecs
return
the
special
floating-point
values
positive
and
negative
zero,
neither
of
these
values
is
greater-than
the
other,
since
+0.0
gt
-0.0
and
-0.0
gt
+0.0
are
both
false
.
An
Examples:
This
example
illustrates
the
effect
of
an
order
by
clause
makes
it
easy
on
a
tuple
stream.
The
keyword
stable
indicates
that,
when
two
tuples
have
equal
sort
keys,
their
order
in
the
input
tuple
stream
is
preserved.
Input tuple stream:
($license = "PFQ519", $make = "Ford", $value = 16500) ($license = "HAJ865", $make = "Honda", $value = 22750) ($license = "NKV473", $make = "Ford", $value = 21650) ($license = "RCM922", $make = "Dodge", $value = 11400) ($license = "ZBX240", $make = "Ford", $value = 16500) ($license = "KLM030", $make = "Dodge", $value = () )
order
by
clause:
stable order by $make, $value descending empty least
Output tuple stream:
($license = "RCM922", $make = "Dodge", $value = 11400) ($license = "KLM030", $make = "Dodge", $value = () ) ($license = "NKV473", $make = "Ford", $value = 21650) ($license = "PFQ519", $make = "Ford", $value = 16500) ($license = "ZBX240", $make = "Ford", $value = 16500) ($license = "HAJ865", $make = "Honda", $value = 22750)
The
following
example
shows
how
an
order
by
clause
can
be
used
to
sort
the
result
of
a
FLWOR
expression,
query,
even
if
the
sort
key
is
not
included
in
the
result
of
the
expression.
For
example,
the
following
expression
query
result.
This
query
returns
employee
names
in
descending
order
by
salary,
without
returning
the
actual
salaries:
<span class= "parse-test">for $e in $employeesfor $e in $employees order by $e/salary descendingreturn $e/namereturn $e/name
Note:
Since
the
order
by
clause
in
a
FLWOR
expression
is
the
only
facility
provided
by
XQuery
for
specifying
a
value
ordering,
a
FLWOR
expression
must
be
used
in
some
queries
where
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:
<span class= "parse-test">for $b in $books/book[price < 100]for $b in $books/book[price < 100] order by $b/titlereturn $breturn $b
[69] |
ReturnClause
| ::= |
"return"
ExprSingle
|
The
return
clause
is
the
final
clause
of
a
FLWOR
expression.
The
return
clause
is
evaluated
once
for
each
tuple
in
its
input
tuple
stream,
using
the
variable
bindings
in
the
respective
tuples,
in
the
order
in
which
these
tuples
appear
in
the
input
tuple
stream.
The
results
of
these
evaluations
are
concatenated,
as
if
by
the
comma
operator
,
to
form
the
result
of
the
FLWOR
expression.
The
following
example
illustrates
a
FLWOR
expression
containing
several
clauses.
The
for
clause
iterates
over
all
the
departments
in
an
input
document
named
,
binding
the
variable
order
by
depts.xml
$d
to
each
department
in
turn.
For
each
binding
of
$d
,
the
let
clause
that
uses
several
options.
It
causes
binds
variable
$e
to
all
the
employees
in
the
given
department,
selected
from
another
input
document
named
emps.xml
(the
relationship
between
employees
and
departments
is
represented
by
matching
their
deptno
values).
Each
tuple
in
the
resulting
tuple
stream
contains
a
collection
pair
of
books
bindings
for
$d
and
$e
(
$d
is
bound
to
be
sorted
a
department
and
$e
is
bound
to
a
set
of
employees
in
primary
that
department).
The
where
clause
filters
the
tuple
stream,
retaining
only
those
tuples
that
represent
departments
having
at
least
ten
employees.
The
order
by
clause
orders
the
surviving
tuples
in
title,
and
secondary
descending
order
by
price.
A
specific
collation
is
specified
the
average
salary
of
the
employees
in
the
department.
The
return
clause
constructs
a
new
big-dept
element
for
each
surviving
tuple,
containing
the
title
ordering,
department
number,
headcount,
and
average
salary.
for $d in fn:doc("depts.xml")//dept let $e := fn:doc("emps.xml")//emp[deptno eq $d/deptno] where fn:count($e) >= 10 order by fn:avg($e/salary) descending return <big-dept> { $d/deptno, <headcount>{fn:count($e)}</headcount>, <avgsal>{fn:avg($e/salary)}</avgsal> } </big-dept>
Notes:
The
order
in
which
items
appear
in
the
ordering
by
price,
books
with
no
price
are
specified
to
occur
last
(as
though
they
have
result
of
a
FLWOR
expression
depends
on
the
least
possible
price).
Whenever
two
books
with
ordering
of
the
same
title
and
price
occur,
input
tuple
stream
to
the
keyword
stable
return
indicates
that
their
input
clause,
which
in
turn
is
influenced
by
order
by
clauses
and
by
ordering
mode
.
For
example,
consider
the
following
query,
which
is
preserved.
based
on
the
same
two
input
documents
as
the
previous
example:
<span class= "parse-test">for $b in $books/book stable order by $b/title collation "http://www.example.org/collations/fr-ca", $b/price descending empty least return $bfor $d in fn:doc("depts.xml")//dept order by $d/deptno for $e in fn:doc("emps.xml")//emp[deptno eq $d/deptno] return <assignment> {$d/deptno, $e/name} </assignment>
The
result
of
this
query
is
a
sequence
of
assignment
elements,
each
containing
a
deptno
element
and
a
name
element.
The
sequence
will
be
ordered
primarily
by
the
deptno
values
because
of
the
order
by
clause.
If
ordering
mode
is
ordered
,
subsequences
of
assignment
elements
with
equal
deptno
values
will
be
ordered
by
the
document
order
of
their
name
elements
within
the
emps.xml
document;
otherwise
the
ordering
of
these
subsequences
will
be
implementation-dependent
.
Parentheses
are
helpful
in
return
clauses
that
contain
comma
operators,
since
FLWOR
expressions
have
a
higher
precedence
than
the
comma
operator.
For
instance,
example,
the
following
query
raises
an
error
because
after
the
comma,
$j
is
no
longer
within
the
FLWOR
expression,
and
is
an
undefined
variable:
let $i := 5, $j := 20 * $i return $i, $j
Parentheses
can
be
used
to
bring
$j
into
the
return
clause
of
the
FLWOR
expression,
as
the
programmer
probably
intended:
let $i := 5, $j := 20 * $i return ($i, $j)
|
OrderedExpr
|
::= |
"ordered"
"{"
Expr
"}"
|
|
UnorderedExpr
|
::= |
"unordered"
"{"
Expr
"}"
|
The
purpose
of
ordered
and
unordered
expressions
is
to
set
the
ordering
mode
in
the
static
context
to
ordered
or
unordered
for
a
certain
region
in
a
query.
The
specified
ordering
mode
applies
to
the
expression
nested
inside
the
curly
braces.
For
expressions
where
the
ordering
of
the
result
is
not
significant,
a
performance
advantage
may
be
realized
by
setting
the
ordering
mode
to
unordered
,
thereby
granting
the
system
flexibility
to
return
the
result
in
the
order
that
it
finds
most
efficient.
Ordering
mode
affects
the
behavior
of
path
expressions
that
include
a
"
/
"
or
"
//
"
operator
or
an
axis
step
;
union
,
intersect
,
and
except
expressions;
the
fn:id
and
fn:idref
functions;
and
certain
clauses
within
a
FLWOR
expressions
that
have
no
order
by
clause.
expression.
If
ordering
mode
is
ordered
,
node
sequences
returned
by
path
expressions,
union
,
intersect
,
and
except
expressions,
and
the
fn:id
and
fn:idref
functions
are
in
document
order
;
otherwise
the
order
of
these
return
sequences
is
implementation-dependent
.
The
effect
of
ordering
mode
on
FLWOR
expressions
is
described
in
3.8
FLWOR
Expressions
3.8.2
For
Clause
,
3.8.4.3
Effects
of
Window
Clauses
on
the
Tuple
Stream
,
and
3.8.7
Group
By
Clause
.
Ordering
mode
has
no
effect
on
duplicate
elimination.
Note:
In
a
region
of
a
query
where
ordering
mode
is
unordered
,
the
result
of
an
expression
may
be
nondeterministic
if
the
expression
invokes
certain
functions
that
are
affected
by
the
ordering
of
node
sequences.
These
functions
include
fn:position
,
fn:last
,
fn:index-of
,
fn:insert-before
,
fn:remove
,
fn:reverse
,
and
fn:subsequence
.
Also,
within
a
path
expression
in
an
unordered
region,
numeric
predicates
are
nondeterministic.
For
example,
in
an
ordered
region,
the
path
expression
(//a/b)[5]
will
return
the
fifth
qualifying
b
-element
in
document
order
.
In
an
unordered
region,
the
same
expression
will
return
an
implementation-dependent
qualifying
b
-element.
Note:
The
fn:id
and
fn:idref
functions
are
described
in
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
as
returning
their
results
in
document
order
.
Since
ordering
mode
is
a
feature
of
XQuery,
relaxation
of
the
ordering
requirement
for
function
results
when
ordering
mode
is
unordered
is
a
feature
of
XQuery
rather
than
of
the
functions
themselves.
The
use
of
an
unordered
expression
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
an
unordered
expression
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
unordered
expression
gives
the
query
evaluator
freedom
to
make
these
kinds
of
optimizations.
unordered {unordered { for $p in fn:doc("parts.xml")/parts/part[color = "Red"], $s in fn:doc("suppliers.xml")/suppliers/supplier where $p/suppno = $s/suppno return <ps> { $p/partno, $s/suppno } </ps>}}
In
addition
to
ordered
and
unordered
expressions,
XQuery
provides
a
function
named
fn:unordered
that
operates
on
any
sequence
of
items
and
returns
the
same
sequence
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
relaxes
ordering
only
for
the
sequence
that
is
its
immediate
operand,
whereas
an
unordered
expression
sets
the
ordering
mode
for
its
operand
expression
and
all
nested
expressions.
XQuery
1.1
supports
a
conditional
expression
based
on
the
keywords
if
,
then
,
and
else
.
|
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.4.3 Effective 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
[71] |
SwitchExpr
| ::= |
"switch"
"("
Expr
")"
SwitchCaseClause
+
"default"
"return"
ExprSingle
|
[72] |
SwitchCaseClause
| ::= |
("case"
SwitchCaseOperand
)+
"return"
ExprSingle
|
The switch expression chooses one of several expressions to evaluate based on the input value.
In
a
switch
expression,
the
switch
keyword
is
followed
by
an
expression
enclosed
in
parentheses,
called
the
switch
operand
expression
.
This
is
the
expression
whose
value
is
being
compared.
The
remainder
of
the
switch
expression
consists
of
one
or
more
case
clauses,
with
one
or
more
case
operand
expressions
each,
and
a
default
clause.
The first step in evaluating a switch expression is to apply atomization to the value of the switch operand expression. If the result is a sequence of length greater than one, a type error is raised [ err:XPTY0004 ]. If the atomized operand is of type xs:untypedAtomic, it is cast to xs:string.
[ Definition : The effective case in a switch expression is the first case clause in which the value of the switch operand expression is equivalent to the value of a case operand, as defined in equivalence of two atomic values , or the default clause if no such case clause exists.] The value of the switch expression is the value of the return expression in the effective case.
A special rule applies to propagation of dynamic errors by switch expressions. The case clauses of a switch expression do not raise any dynamic errors except in the effective case. Dynamic errors raised in the operand expressions of the switch or the case clauses are propagated. An implementation must not raise errors in the operand expressions of case clauses that occur after the effective case.
The following example shows how a switch expression might be used:
switch ($animal) case "Cow" return "Moo" case "Cat" return "Meow" case "Duck" return "Quack" default return "What's that odd noise?"
Quantified
expressions
support
existential
and
universal
quantification.
The
value
of
a
quantified
expression
is
always
true
or
false
.
|
QuantifiedExpr
|
::= |
("some"
|
"every")
"$"
VarName
TypeDeclaration
?
"in"
ExprSingle
(","
"$"
VarName
TypeDeclaration
?
"in"
ExprSingle
)*
"satisfies"
ExprSingle
|
|
TypeDeclaration
|
::= |
"as"
SequenceType
|
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
items,
called
the
binding
sequence
for
that
variable.
The
in-clauses
generate
tuples
of
variable
bindings,
including
a
tuple
for
each
combination
of
items
in
the
binding
sequences
of
the
respective
variables.
Conceptually,
the
test
expression
is
evaluated
for
each
tuple
of
variable
bindings.
Results
depend
on
the
effective
boolean
value
of
the
test
expressions,
as
defined
in
2.4.3
Effective
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 . 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:XPTY0004 ].
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 /parts/part satisfies $part/@discounted
This
expression
is
true
if
at
least
one
employee
element
satisfies
the
given
comparison
expression:
some $emp in /emps/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
.
<span class= "parse-test">some $x in (1, 2, 3), $y in (2, 3, 4) satisfies $x + $y = 4some $x in (1, 2, 3), $y in (2, 3, 4) satisfies $x + $y = 4
<span class= "parse-test">every $x in (1, 2, 3), $y in (2, 3, 4) satisfies $x + $y = 4every $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
static
analysis
phase
.
Otherwise,
the
expression
may
either
return
true
or
raise
a
type
error
during
the
dynamic
evaluation
phase
.
some $x as xs:integer in (1, 2, "cat") satisfies $x * 2 = 4
The
try/catch
expression
provides
error
handling
for
dynamic
errors
and
type
errors
raised
during
dynamic
evaluation,
including
errors
raised
by
the
XQuery
implementation
and
errors
explicitly
raised
in
a
query
using
the
fn:error()
function.
[77] |
TryCatchExpr
| ::= |
TryClause
CatchClause
+
|
[78] |
TryClause
| ::= |
"try"
"{"
TryTargetExpr
"}"
|
[79] |
TryTargetExpr
| ::= |
Expr
|
[80] |
CatchClause
| ::= |
"catch"
CatchErrorList
CatchVars
?
"{"
Expr
"}"
|
[81] |
CatchErrorList
| ::= |
NameTest
("|"
NameTest
)*
|
[82] |
CatchVars
| ::= |
"("
CatchErrorCode
(","
CatchErrorDesc
(","
CatchErrorVal
)?)?
")"
|
[83] |
CatchErrorCode
| ::= |
"$"
VarName
|
[84] |
CatchErrorDesc
| ::= |
"$"
VarName
|
[85] |
CatchErrorVal
| ::= |
"$"
VarName
|
A
try/catch
expression
catches
dynamic
errors
and
type
errors
raised
during
dynamic
evaluation
for
expressions
that
are
lexically
contained
within
the
try
clause.
If
the
target
expression
does
not
raise
a
dynamic
error
or
a
type
error,
the
result
of
the
try/catch
expression
is
the
result
of
the
target
expression.
If
the
target
expression
raises
a
dynamic
error
or
a
type
error,
the
result
of
the
try/catch
expression
is
obtained
by
evaluating
the
first
catch
clause
that
"matches"
the
error
value,
as
described
below.
A
catch
clause
with
one
or
more
NameTests
matches
any
error
whose
error
code
matches
one
of
these
NameTests.
For
instance,
if
the
error
code
is
err:FOER0000
,
then
it
matches
a
catch
clause
whose
ErrorList
is
err:FOER0000
|
err:FOER0001
.
Wildcards
may
be
used
in
NameTests;
thus,
the
error
code
err:FOER0000
also
matches
a
catch
clause
whose
ErrorList
is
err:*
or
*:FOER0000
or
*
.
If
an
error
is
matched,
the
optional
variables
in
the
catch
clause
are
bound,
in
order,
to
the
error's
code,
description,
and
value.
These
variables
are
then
in
scope
in
the
catch
clause.
The
types
of
these
variables
match
the
types
of
the
corresponding
parameters
in
the
error()
function:
ErrorCode
has
type
xs:QName
,
ErrorDescr
has
type
xs:string?
,
and
ErrorVal
has
type
item()*
.
If
no
catch
clause
matches
an
error,
the
try/catch
expression
raises
that
error.
If
an
error
is
raised
in
a
catch
clause,
the
try/catch
expression
raises
that
error.
If
an
error
found
in
a
try
clause
can
be
detected
statically,
an
implementation
is
free
to
raise
a
static
error.
Static
errors
are
not
caught
by
the
try/catch
expression.
If
a
function
call
occurs
within
a
try
clause,
errors
raised
by
evaluating
the
corresponding
function
are
caught
by
the
try/catch
expression.
If
a
variable
reference
is
used
in
a
try
clause,
errors
raised
by
binding
a
value
to
the
variable
are
not
caught
unless
the
binding
expression
occurs
within
the
try
clause.
Note:
The presence of a try/catch expression does not prevent an implementation from using a lazy evaluation strategy, nor does it prevent an optimizer performing expression rewrites. However, if the evaluation of an expression inside a try/catch is rewritten or deferred in this way, it must take its try/catch context with it. Similarly, expressions that were written outside the try/catch expression may be evaluated inside the try/catch, but only if they retain their original try/catch behavior. The presence of a try/catch does not change the rules that allow the processor to evaluate expressions in such a way that may avoid the detection of some errors.
Here are some examples of try/catch expressions.
A try/catch expression without a CatchErrorList catches any error:
try { $x cast as xs:integer } catch * { 0 }
The
CatchErrorList
in
this
try/catch
expression
specifies
that
only
err:FORG0001
is
caught:
try { $x cast as xs:integer } catch err:FORG0001 { 0 }
The
CatchErrorList
in
this
try/catch
expression
specifies
that
errors
err:FORG0001
and
err:XPTY0004
are
caught:
try { $x cast as xs:integer } catch err:FORG0001 | err:XPTY0004 { 0 }
Note:
In
some
implementations,
err:XPTY0004
is
detected
during
static
evaluation;
it
can
only
be
caught
if
it
is
raised
during
dynamic
evaluation.
This try/catch expression shows how to bind variables to the error code, error description, and error value. Since the CatchErrorList is a wildcard, it catches any error:
try { fn:error(fn:QName('http://www.w3.org/2005/xqt-errors', 'err:FOER0000')) } catch * ($errcode, $errdesc, $errval) { $errcode, $errdesc }
Errors
raised
by
using
the
result
of
a
try/catch
expression
are
not
caught,
since
they
are
outside
the
scope
of
the
try
expression.
declare function local:thrice($x as xs:integer) as xs:integer { 3*$x }; local:thrice(try { "oops" } catch * { 3 } )
In this example, the try block succeeds, returning the string "oops", which is not a valid argument to the function.
In
addition
to
their
use
in
function
parameters
and
results,
sequence
types
are
used
in
instance
of
,
typeswitch
,
cast
,
castable
,
and
treat
expressions.
|
InstanceofExpr
|
::= |
TreatExpr
(
"instance"
"of"
SequenceType
)?
|
The
boolean
operator
instance
of
returns
true
if
the
value
of
its
first
operand
matches
the
SequenceType
in
its
second
operand,
according
to
the
rules
for
SequenceType
matching
;
otherwise
it
returns
false
.
For
example:
5
instance
of
xs:integer
This
example
returns
true
because
the
given
value
is
an
instance
of
the
given
type.
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
an
element
rather
than
an
integer.
(5,
6)
instance
of
xs:integer+
This
example
returns
true
because
the
given
sequence
contains
two
integers,
and
is
a
valid
instance
of
the
specified
type.
.
instance
of
element()
This
example
returns
true
if
the
context
item
is
an
element
node
or
false
if
the
context
item
is
defined
but
is
not
an
element
node.
If
the
context
item
is
undefined,
a
dynamic
error
is
raised
[
err:XPDY0002
].
|
TypeswitchExpr
|
::= |
"typeswitch"
"("
Expr
")"
CaseClause
+
"default"
("$"
VarName
)?
"return"
ExprSingle
|
|
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.
[
Definition
:
The
effective
case
in
a
typeswitch
expression
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
does
not
match
any
SequenceType
named
in
a
case
clause,
the
value
of
the
typeswitch
expression
is
the
value
of
the
return
expression
in
the
default
clause.
In
a
case
or
default
clause,
if
the
value
to
be
returned
depends
on
the
value
of
the
operand
expression,
the
clause
must
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.
Inside
a
case
clause,
the
static
type
of
the
variable
is
the
SequenceType
named
in
the
case
clause.
Inside
a
default
clause,
the
static
type
of
the
variable
is
the
same
as
the
static
type
of
the
operand
expression.
If
the
value
to
be
returned
by
a
case
or
default
clause
does
not
depend
on
the
value
of
the
operand
expression,
the
clause
need
not
specify
a
variable.
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.
A
special
rule
applies
to
propagation
of
dynamic
errors
by
typeswitch
expressions.
A
typeswitch
expression
ignores
(does
not
raise)
any
dynamic
errors
encountered
in
case
clauses
other
than
the
effective
case
.
Dynamic
errors
encountered
in
the
default
clause
are
raised
only
if
there
is
no
effective
case
.
The
following
example
shows
how
a
typeswitch
expression
might
be
used
to
process
an
expression
in
a
way
that
depends
on
its
dynamic
type
.
<span class= "parse-test">typeswitch($customer/billing-address)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/prefecturedefault return "unknown"default return "unknown"
|
CastExpr
|
::= |
UnaryExpr
(
"cast"
"as"
SingleType
)?
|
|
SingleType
|
::= |
AtomicType
"?"?
|
Occasionally
it
is
necessary
to
convert
a
value
to
a
specific
datatype.
For
this
purpose,
XQuery
1.1
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
an
atomic
type
that
is
in
the
in-scope
schema
types
[
err:XPST0051
].
In
addition,
the
target
type
cannot
be
xs:NOTATION
or
xs:anyAtomicType
[
err:XPST0080
].
The
optional
occurrence
indicator
"
?
"
denotes
that
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:XPTY0004 ].
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:XPTY0004
].
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
of
the
rules
are
listed
below—
the
below—the
normative
definition
of
these
rules
is
given
in
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
.
For
the
purpose
of
these
rules,
an
implementation
may
determine
that
one
type
is
derived
by
restriction
from
another
type
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
Section
17.1
Casting
from
primitive
types
to
primitive
types
FO
.
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
schema
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]
Operators
1.1]
.
If
the
target
type
of
a
cast
expression
is
xs:QName
,
or
is
a
type
that
is
derived
from
xs:QName
or
xs:NOTATION
,
and
if
the
base
type
of
the
input
is
not
the
same
as
the
base
type
of
the
target
type,
then
the
input
expression
must
be
a
string
literal
[
err:XPTY0004
].
Note:
The reason for this rule is that construction of an instance of one of these target types from a string requires knowledge about namespace bindings. If the input expression is a non-literal string, it might be derived from an input document whose namespace bindings are different from the statically known namespaces .
cast
is
supported
if
the
input
type
is
a
non-primitive
atomic
type
that
is
derived
by
restriction
from
the
target
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
schema
type
xs:integer
.
cast
is
supported
if
the
target
type
is
a
non-primitive
atomic
type
and
the
input
type
is
xs:string
or
xs: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
(as
defined
in
[XML
Schema]
);
a
dynamic
error
[err:FORG0001]
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:FORG0001]
is
raised
if
type.
If
the
resulting
input
value
does
not
fails
to
satisfy
all
the
facets
some
facet
of
the
target
type.
type,
a
dynamic
error
may
be
raised
as
specified
in
[XQuery
and
XPath
Functions
and
Operators
1.1]
.
cast
is
supported
if
the
target
type
is
a
non-primitive
atomic
type
that
is
derived
by
restriction
from
the
input
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 type derived by restriction from P1 can be cast into any type derived by restriction from 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:XPTY0004
].
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:FORG0001]
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
.
|
CastableExpr
|
::= |
CastExpr
(
"castable"
"as"
SingleType
)?
|
|
SingleType
|
::= |
AtomicType
"?"?
|
XQuery
1.1
provides
an
expression
that
tests
whether
a
given
value
is
castable
into
a
given
target
type.
The
target
type
must
be
an
atomic
type
that
is
in
the
in-scope
schema
types
[
err:XPST0051
].
In
addition,
the
target
type
cannot
be
xs:NOTATION
or
xs:anyAtomicType
[
err:XPST0080
].
The
optional
occurrence
indicator
"
?
"
denotes
that
an
empty
sequence
is
permitted.
The
expression
returns
V
E
castable
as
T
true
if
the
value
result
of
evaluating
can
be
successfully
cast
into
the
target
type
V
E
T
by
using
a
cast
expression;
otherwise
it
returns
false
.
If
evaluation
of
E
fails
with
a
dynamic
error,
the
castable
expression
as
a
whole
fails.
The
castable
expression
can
be
used
as
a
predicate
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
Note:
If
the
target
type
of
a
castable
expression
is
xs:QName
,
or
is
a
type
that
is
derived
from
xs:QName
or
xs:NOTATION
,
and
the
input
argument
of
the
expression
is
of
type
xs:string
but
it
is
not
a
literal
string,
the
result
of
the
castable
expression
is
false
.
For
every
atomic
type
in
the
in-scope
schema
types
(except
xs:NOTATION
and
xs:anyAtomicType
,
which
are
not
instantiable),
a
constructor
function
is
implicitly
defined.
In
each
case,
the
name
of
the
constructor
function
is
the
same
as
the
name
of
its
target
type
(including
namespace).
The
signature
of
the
constructor
function
for
type
T
is
as
follows:
T($arg as xs:anyAtomicType?) as T?
[
Definition
:
The
constructor
function
for
a
given
type
is
used
to
convert
instances
of
other
atomic
types
into
the
given
type.
The
semantics
of
the
constructor
function
call
T($arg)
are
defined
to
be
equivalent
to
the
expression
(($arg)
cast
as
T?)
.]
The
constructor
functions
for
xs:QName
and
for
types
derived
from
xs:QName
and
xs:NOTATION
require
their
arguments
to
be
string
literals
or
to
have
a
base
type
that
is
the
same
as
the
base
type
of
the
target
type;
otherwise
a
type
error
[
err:XPTY0004
]
is
raised.
This
rule
is
consistent
with
the
semantics
of
cast
expressions
for
these
types,
as
defined
in
3.12.3
3.14.3
Cast
.
The following examples illustrate the use of 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
xs:dayTimeDuration
value
equal
to
21
days.
It
is
equivalent
to
("P21D"
cast
as
xs:dayTimeDuration?)
.
xs:dayTimeDuration("P21D")
If
usa:zipcode
is
a
user-defined
atomic
type
in
the
in-scope
schema
types
,
then
the
following
expression
is
equivalent
to
the
expression
("12345"
cast
as
usa:zipcode?)
.
usa:zipcode("12345")
Note:
An instance of an atomic type that is not in a namespace can be constructed in either of the following ways:
By
using
a
cast
expression,
if
the
default
element/type
namespace
is
"none".
(See
4.13
4.14
Default
Namespace
Declaration
for
how
to
undeclare
the
default
element/type
namespace
).
17 cast as apple
By
using
a
constructor
function,
if
the
default
function
namespace
is
"none".
(See
4.13
4.14
Default
Namespace
Declaration
for
how
to
undeclare
the
default
function
namespace
).
apple(17)
|
TreatExpr
|
::= |
CastableExpr
(
"treat"
"as"
SequenceType
)?
|
XQuery
1.1
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
dynamic
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
rules
for
SequenceType
matching
,
the
treat
expression
returns
the
value
of
expr1
;
otherwise,
it
raises
a
dynamic
error
[
err:XPDY0050
].
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
rules
for
SequenceType
matching
;
otherwise
a
dynamic
error
is
raised
[
err:XPDY0050
].
|
ValidateExpr
|
::= |
"validate"
(
ValidationMode
|
|
ValidationMode
|
::= |
"lax"
|
"strict"
|
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
defined
in
[XML
Schema]
.
If
the
operand
of
a
validate
expression
does
not
evaluate
to
exactly
one
document
or
element
node,
a
type
error
is
raised
[
err:XQTY0030
].
In
this
specification,
the
node
that
is
the
operand
of
a
validate
expression
is
called
the
operand
node
.
A
validate
expression
returns
a
new
node
with
its
own
identity
and
with
no
parent.
The
new
node
and
its
descendants
are
given
type
annotations
that
are
generated
by
applying
a
validation
process
to
the
operand
node.
In
some
cases,
default
values
may
also
be
generated
by
the
validation
process.
A
validate
expression
may
optionally
specify
a
validation
mode
.
The
default
validation
mode
is
strict
.
A
validate
expression
may
optionally
specify
a
TypeName
.
This
type
name
must
be
found
in
the
in-scope
schema
definitions
;
if
it
is
not,
a
static
error
is
raised
[
err:XQST0104
].
If
the
type
name
is
unprefixed,
it
is
interpreted
as
a
name
in
the
default
namespace
for
elements
and
types.
The
result
of
a
validate
expression
is
defined
by
the
following
rules.
If the operand node is a document node, its children must consist of exactly one element node and zero or more comment and processing instruction nodes, in any order; otherwise, a dynamic error [ err:XQDY0061 ] is raised.
The
operand
node
is
converted
to
an
XML
Information
Set
(
[XML
Infoset]
)
according
to
the
"Infoset
Mapping"
rules
defined
in
[XQuery/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
.
Note
that
this
process
discards
any
existing
type
annotations
.
If a type name is provided, schema-validity assessment is carried out according to the rules defined in [XML Schema] , section 3.3.4 "Element Declaration Validation Rules", clauses 1.2 and 2, using this type definition as the "processor-stipulated type definition" for validation.
Validity assessment is carried out on the root element information item of the resulting Infoset, using the in-scope schema definitions as the effective schema. The process of validation applies recursively to contained elements and attributes to the extent required by the effective schema. During validity assessment, the following special rules are in effect:
If
validation
mode
is
strict
,
then
there
must
be
a
top-level
element
declaration
in
the
in-scope
element
declarations
that
matches
the
root
element
information
item
in
the
Infoset,
and
schema-validity
assessment
is
carried
out
using
that
declaration
in
accordance
with
item
2
of
[XML
Schema]
Part
1,
section
5.2,
"Assessing
Schema-Validity."
If
there
is
no
such
element
declaration,
a
dynamic
error
is
raised
[
err:XQDY0084
].
If
validation
mode
is
lax
,
then
schema-validity
assessment
is
carried
out
in
accordance
with
item
3
of
[XML
Schema]
Part
1,
section
5.2,
"Assessing
Schema-Validity."
If
validation
mode
is
lax
and
the
root
element
information
item
has
neither
a
top-level
element
declaration
nor
an
xsi:type
attribute,
[XML
Schema]
defines
the
recursive
checking
of
children
and
attributes
as
optional.
During
processing
of
an
XQuery
validate
expression,
this
recursive
checking
is
required.
If
the
operand
node
is
an
element
node,
the
validation
rules
named
"Validation
Root
Valid
(ID/IDREF)"
and
"Identity-constraint
Satisfied"
are
is
not
applied.
This
means
that
document-level
constraints
relating
to
uniqueness
and
referential
integrity
are
not
enforced.
There
is
no
check
that
the
document
contains
unparsed
entities
whose
names
match
the
values
of
nodes
of
type
xs:ENTITY
or
xs:ENTITIES
.
There
is
no
check
that
the
document
contains
notations
whose
names
match
the
values
of
nodes
of
type
xs:NOTATION
.
Note:
Validity
assessment
is
affected
by
the
presence
or
absence
of
xsi:type
attributes
on
the
elements
being
validated,
and
may
generate
new
information
items
such
as
default
attributes.
The
next
step
depends
on
validation
mode
and
on
the
validity
property
of
the
root
element
information
item
in
the
PSVI
that
results
from
the
validation
process.
If
the
validity
property
of
the
root
element
information
item
is
valid
,
or
if
validation
mode
is
(for
any
validation
mode
),
lax
and
the
validity
property
of
the
root
element
information
item
is
notKnown
,
the
PSVI
is
converted
back
into
an
XDM
instance
as
described
in
[XQuery/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
Section
3.3,
"Construction
from
a
PSVI".
The
resulting
node
(a
new
node
of
the
same
kind
as
the
operand
node)
is
returned
as
the
result
of
the
validate
expression.
Otherwise, a dynamic error is raised [ err:XQDY0027 ].
Note:
The
effect
of
these
rules
is
as
follows:
If
validation
mode
is
strict
,
the
validated
element
must
have
a
top-level
element
declaration
in
the
effective
schema,
and
must
conform
to
this
declaration.
If
validation
mode
is
lax
,
the
validated
element
must
conform
to
its
top-level
element
declaration
if
such
a
declaration
exists
in
the
effective
schema.
If
validation
mode
is
lax
and
there
is
no
top-level
element
declaration
for
the
element,
and
the
element
has
an
xsi:type
attribute,
then
the
xsi:type
attribute
must
name
a
top-level
type
definition
in
the
effective
schema,
and
the
element
must
conform
to
that
type.
The
validated
element
corresponds
either
to
the
operand
node
or
(if
the
operand
node
is
a
document
node)
to
its
element
child.
Note:
During
conversion
of
the
PSVI
into
an
XDM
instance
after
validation,
any
element
information
items
whose
validity
property
is
notKnown
are
converted
into
element
nodes
with
type
annotation
xs:anyType
,
and
any
attribute
information
items
whose
validity
property
is
notKnown
are
converted
into
attribute
nodes
with
type
annotation
xs:untypedAtomic
,
as
described
in
Section
3.3.1.1
Element
and
Attribute
Node
Type
Names
DM
.
[ Definition : An extension expression is an expression whose semantics are implementation-defined .] Typically a particular extension will be recognized by some implementations and not by others. The syntax is designed so that extension expressions can be successfully parsed by all implementations, and so that fallback behavior can be defined for implementations that do not recognize a particular extension.
|
ExtensionExpr
|
::= |
Pragma
+
"{"
Expr
?
"}"
|
|
Pragma
|
::= |
"(#"
S
?
QName
(
S
PragmaContents
)?
"#)"
|
|
PragmaContents
|
::= |
(
Char
*
-
(Char*
'#)'
Char*))
|
An
extension
expression
consists
of
one
or
more
pragmas
,
followed
by
an
expression
enclosed
in
curly
braces.
[
Definition
:
A
pragma
is
denoted
by
the
delimiters
(#
and
#)
,
and
consists
of
an
identifying
QName
followed
by
implementation-defined
content.]
The
content
of
a
pragma
may
consist
of
any
string
of
characters
that
does
not
contain
the
ending
delimiter
#)
.
The
QName
of
a
pragma
must
resolve
to
a
namespace
URI
and
local
name,
using
the
statically
known
namespaces
[
err:XPST0081
].
Note:
Since there is no default namespace for pragmas, a pragma QName must include a namespace prefix.
Each implementation recognizes an implementation-defined set of namespace URIs used to denote pragmas.
If the namespace part of a pragma QName is not recognized by the implementation as a pragma namespace, then the pragma is ignored. If all the pragmas in an ExtensionExpr are ignored, then the value of the ExtensionExpr is the value of the expression enclosed in curly braces; if this expression is absent, then a static error is raised [ err:XQST0079 ].
If an implementation recognizes the namespace of one or more pragmas in an ExtensionExpr , then the value of the ExtensionExpr , including its error behavior, is implementation-defined . For example, an implementation that recognizes the namespace of a pragma QName, but does not recognize the local part of the QName, might choose either to raise an error or to ignore the pragma.
It is a static error [ err:XQST0013 ] if an implementation recognizes a pragma but determines that its content is invalid.
If an implementation recognizes a pragma, it must report any static errors in the following expression even if it will not evaluate that expression (however, static type errors are raised only if the Static Typing Feature is in effect.)
Note:
The following examples illustrate three ways in which extension expressions might be used.
A pragma can be used to furnish a hint for how to evaluate the following expression, without actually changing the result. For example:
declare namespace exq = "http://example.org/XQueryImplementation"; (# exq:use-index #) { $bib/book/author[name='Berners-Lee'] }
An
implementation
that
recognizes
the
exq:use-index
pragma
might
use
an
index
to
evaluate
the
expression
that
follows.
An
implementation
that
does
not
recognize
this
pragma
would
evaluate
the
expression
in
its
normal
way.
A
pragma
might
be
used
to
modify
the
semantics
of
the
following
expression
in
ways
that
would
not
(in
the
absence
of
the
pragma)
be
conformant
with
this
specification.
For
example,
a
pragma
might
be
used
to
permit
comparison
of
xs:duration
values
using
implementation-defined
semantics
(this
would
normally
be
an
error).
Such
changes
to
the
language
semantics
must
be
scoped
to
the
expression
contained
within
the
curly
braces
following
the
pragma.
A pragma might contain syntactic constructs that are evaluated in place of the following expression. In this case, the following expression itself (if it is present) provides a fallback for use by implementations that do not recognize the pragma. For example:
declare namespace exq = "http://example.org/XQueryImplementation"; for $x in (# exq:distinct //city by @country #) { //city[not(@country = preceding::city/@country)] } return f:show-city($x)
Here
an
implementation
that
recognizes
the
pragma
will
return
the
result
of
evaluating
the
proprietary
syntax
exq:distinct
//city
by
@country
,
while
an
implementation
that
does
not
recognize
the
pragma
will
instead
return
the
result
of
the
expression
//city[not(@country
=
preceding::city/@country)]
.
If
no
fallback
expression
is
required,
or
if
none
is
feasible,
then
the
expression
between
the
curly
braces
may
be
omitted,
in
which
case
implementations
that
do
not
recognize
the
pragma
will
raise
a
static
error
.
[1] |
Module
|
::= |
VersionDecl
?
(
LibraryModule
|
MainModule
)
|
[3] |
MainModule
|
::= |
Prolog
QueryBody
|
[4] |
LibraryModule
|
::= |
ModuleDecl
Prolog
|
[6] |
Prolog
|
::= |
((
DefaultNamespaceDecl
|
Setter
|
NamespaceDecl
|
Import
)
Separator
)*
((
VarDecl
|
ContextItemDecl
|
FunctionDecl
|
OptionDecl
)
Separator
)*
|
[7] |
Setter
|
::= |
BoundarySpaceDecl
|
DefaultCollationDecl
|
BaseURIDecl
|
ConstructionDecl
|
OrderingModeDecl
|
EmptyOrderDecl
|
CopyNamespacesDecl
|
DecimalFormatDecl
|
[8] |
Import
|
::= |
SchemaImport
|
ModuleImport
|
[9] |
Separator
|
::= |
";"
|
|
QueryBody
|
::= |
Expr
|
A query can be assembled from one or more fragments called modules . [ Definition : A module is a fragment of XQuery code that conforms to the Module grammar and can independently undergo the static analysis phase described in 2.2.3 Expression Processing . Each module is either a main module or a library module .]
[ Definition : A main module consists of a Prolog followed by a Query Body .] A query has exactly 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 does not contain a Query Body is called a library module . A library module consists of a module declaration followed by a Prolog .] A library module cannot be evaluated directly; instead, it provides function and variable declarations that can be imported into other modules.
The XQuery syntax does not allow a module to contain both a module declaration and a Query Body .
[ Definition : A Prolog is a series of declarations and imports that define the processing environment for the module that contains the Prolog.] Each declaration or import is followed by a semicolon. A Prolog is organized into two parts.
The first part of the Prolog consists of setters, imports, namespace declarations, and default namespace declarations. [ Definition : Setters are declarations that set the value of some property that affects query processing, such as construction mode, ordering mode, or default collation.] Namespace declarations and default namespace declarations affect the interpretation of QNames within the query. Imports are used to import definitions from schemas and modules. [ Definition : Each imported schema or module is identified by its target namespace , which is the namespace of the objects (such as elements or functions) that are defined by the schema or module.]
The second part of the Prolog consists of declarations of variables, functions, and options. These declarations appear at the end of the Prolog because they may be affected by declarations and imports in the first part of the Prolog.
[ Definition : The Query Body , if present, consists of an expression that defines the result of the query.] Evaluation of expressions is described in 3 Expressions . A module can be evaluated only if it has a Query Body.
[2] |
VersionDecl
|
::= |
"xquery"
|
[
Definition
:
Any
module
may
contain
a
A
version
declaration
.
If
present,
the
version
declaration
occurs
at
the
beginning
of
the
module
and
identifies
can
identify
the
applicable
XQuery
syntax
and
semantics
for
the
a
module
.]
,
as
well
as
its
encoding.]
The
version
number
"1.0"
indicates
a
requirement
that
the
module
must
be
processed
by
an
implementation
XQuery
1.0
processor
;
the
version
number
"1.1"
indicates
a
requirement
that
supports
the
module
must
be
processed
by
an
XQuery
Version
1.0.
1.1
processor
.
If
the
version
declaration
is
not
present,
present
or
the
version
is
presumed
to
be
"1.0".
An
not
included
in
the
declaration,
an
XQuery
implementation
1.1
processor
assumes
a
version
of
"1.1".
If
an
XQuery
1.1
processor
processes
a
module
labeled
with
a
version
of
"1.0",
it
must
either
raise
a
static
error
[
err:XQST0031
]
when
processing
a
],
or
attempt
to
process
the
module
labeled
with
a
version
that
the
implementation
does
not
support.
It
is
the
intent
of
the
an
XQuery
working
group
to
give
later
versions
of
this
specification
numbers
1.0
processor.
If
any
version
number
other
than
"1.0",
but
this
intent
does
not
indicate
1.1
or
1.0
is
encountered,
a
commitment
to
produce
any
future
versions
of
XQuery,
nor
if
any
are
produced,
to
use
any
particular
numbering
scheme.
static
error
[
err:XQST0031
]
is
raised.
[
Definition
:
If
present,
a
version
declaration
may
optionally
include
an
encoding
declaration
.
The
value
of
the
string
literal
following
the
keyword
encoding
is
an
encoding
name,
and
must
conform
to
the
definition
of
EncName
specified
in
[XML
1.0]
[
err:XQST0087
].
The
purpose
of
an
encoding
declaration
is
to
allow
the
writer
of
a
query
to
provide
a
string
that
indicates
how
the
query
is
encoded,
such
as
"
UTF-8
",
"
UTF-16
",
or
"
US-ASCII
".]
Since
the
encoding
of
a
query
may
change
as
the
query
moves
from
one
environment
to
another,
there
can
be
no
guarantee
that
the
encoding
declaration
is
correct.
The handling of an encoding declaration is implementation-dependent . If an implementation has a priori knowledge of the encoding of a query, it may use this knowledge and disregard the encoding declaration. The semantics of a query are not affected by the presence or absence of an encoding declaration.
If a version declaration is present, no Comment may occur before the end of the version declaration. If such a Comment is present, the result is implementation-dependent .
Note:
The effect of a Comment before the end of a version declaration is implementation-dependent because it may suppress query processing by interfering with detection of the encoding declaration.
The following examples illustrate version declarations:
xquery version "1.0";
xquery version "1.0" encoding "utf-8";
[5] |
ModuleDecl
|
::= |
"module"
"namespace"
NCName
"="
URILiteral
Separator
|
[
Definition
:
A
module
declaration
serves
to
identify
a
module
as
a
library
module
.
A
module
declaration
begins
with
the
keyword
module
and
contains
a
namespace
prefix
and
a
URILiteral
.]
The
URILiteral
must
be
of
nonzero
length
[
err:XQST0088
].
The
URILiteral
identifies
the
target
namespace
of
the
library
module,
which
is
the
namespace
for
all
variables
and
functions
exported
by
the
library
module.
The
name
of
every
variable
and
function
declared
in
a
library
module
must
have
a
namespace
URI
that
is
the
same
as
the
target
namespace
of
the
module;
otherwise
a
static
error
is
raised
[
err:XQST0048
].
In
the
statically
known
namespaces
of
the
library
module,
the
namespace
prefix
specified
in
the
module
declaration
is
bound
to
the
module's
target
namespace.
The
namespace
prefix
specified
in
a
module
declaration
must
not
be
xml
or
xmlns
[
err:XQST0070
],
and
must
not
be
the
same
as
any
namespace
prefix
bound
in
the
same
module
by
a
schema
import
,
by
a
namespace
declaration
,
or
by
a
module
import
with
a
different
target
namespace
[
err:XQST0033
].
Any module may import one or more library modules by means of a module import that specifies the target namespace of the library modules to be imported. When a module imports one or more library modules, the variables and functions declared in the imported modules are added to the static context and (where applicable) to the dynamic context of the importing module.
The following is an example of a module declaration:
module namespace math = "http://example.org/math-functions";
[11] |
BoundarySpaceDecl
|
::= |
"declare"
"boundary-space"
("preserve"
|
"strip")
|
[
Definition
:
A
boundary-space
declaration
sets
the
boundary-space
policy
in
the
static
context
,
overriding
any
implementation-defined
default.
Boundary-space
policy
controls
whether
boundary
whitespace
is
preserved
by
element
constructors
during
processing
of
the
query.]
If
boundary-space
policy
is
preserve
,
boundary
whitespace
is
preserved.
If
boundary-space
policy
is
strip
,
boundary
whitespace
is
stripped
(deleted).
A
further
discussion
of
whitespace
in
constructed
elements
can
be
found
in
3.7.1.4
Boundary
Whitespace
.
The following example illustrates a boundary-space declaration:
declare boundary-space preserve;
If a Prolog contains more than one boundary-space declaration, a static error is raised [ err:XQST0068 ].
|
DefaultCollationDecl
|
::= |
"declare"
"default"
"collation"
URILiteral
|
[
Definition
:
A
default
collation
declaration
sets
the
value
of
the
default
collation
in
the
static
context
,
overriding
any
implementation-defined
default.]
The
default
collation
is
the
collation
that
is
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.
If
neither
the
implementation
nor
the
Prolog
specifies
a
default
collation,
the
Unicode
codepoint
collation
(
http://www.w3.org/2005/xpath-functions/collation/codepoint
)
is
used.
The following example illustrates a default collation declaration:
declare default collation "http://example.org/languages/Icelandic";
If a default collation declaration specifies a collation by a relative URI, that relative URI is resolved to an absolute URI using the base URI in the static context . If a Prolog contains more than one default collation declaration, or the value specified by a default collation declaration (after resolution of a relative URI, if necessary) is not present in statically known collations , a static error is raised [ err:XQST0038 ].
|
BaseURIDecl
|
::= |
"declare"
"base-uri"
URILiteral
|
[
Definition
:
A
base
URI
declaration
specifies
the
base
URI
property
of
the
static
context
.
The
base
URI
property
is
used
when
resolving
relative
URIs
within
a
module
.]
For
example,
the
fn:doc
function
resolves
a
relative
URI
using
the
base
URI
of
the
calling
module.
The following is an example of a base URI declaration:
declare base-uri "http://example.org";
If a Prolog contains more than one base URI declaration, a static error is raised [ err:XQST0032 ].
In
the
terminology
of
[RFC3986]
Section
5.1,
the
URILiteral
of
the
base
URI
declaration
is
considered
to
be
a
"base
URI
embedded
in
content".
If
no
base
URI
declaration
is
present,
the
base
URI
in
the
static
context
is
established
according
to
the
principles
outlined
in
[RFC3986]
Section
5.1—that
is,
it
defaults
first
to
the
base
URI
of
the
encapsulating
entity,
then
to
the
URI
used
to
retrieve
the
entity,
and
finally
to
an
implementation-defined
default.
If
the
URILiteral
in
the
base
URI
declaration
is
a
relative
URI,
then
it
is
made
absolute
by
resolving
it
with
respect
to
this
same
hierarchy.
For
example,
if
the
URILiteral
in
the
base
URI
declaration
is
../data/
,
and
the
query
is
contained
in
a
file
whose
URI
is
file:///C:/temp/queries/query.xq
,
then
the
base
URI
in
the
static
context
is
file:///C:/temp/data/
.
It
is
not
intrinsically
an
error
if
this
process
fails
to
establish
an
absolute
base
URI;
however,
the
base
URI
in
the
static
context
is
then
undefined,
and
undefined
[
err:XPST0001
].
When
the
base
URI
in
the
static
context
is
undefined
,
any
attempt
to
use
its
value
may
to
resolve
a
relative
URI
reference
will
result
in
an
error
[
err:XPST0001
].
When
the
base
URI
of
a
constructed
node
is
taken
from
the
base
URI
in
the
static
context
and
the
latter
is
undefined
,
then
the
base-uri
property
of
the
constructed
node
is
empty.
|
ConstructionDecl
|
::= |
"declare"
"construction"
("strip"
|
"preserve")
|
[
Definition
:
A
construction
declaration
sets
the
construction
mode
in
the
static
context
,
overriding
any
implementation-defined
default.]
The
construction
mode
governs
the
behavior
of
element
and
document
node
constructors.
If
construction
mode
is
preserve
,
the
type
of
a
constructed
element
node
is
xs:anyType
,
and
all
attribute
and
element
nodes
copied
during
node
construction
retain
their
original
types.
If
construction
mode
is
strip
,
the
type
of
a
constructed
element
node
is
xs:untyped
;
all
element
nodes
copied
during
node
construction
receive
the
type
xs:untyped
,
and
all
attribute
nodes
copied
during
node
construction
receive
the
type
xs:untypedAtomic
.
The following example illustrates a construction declaration:
declare construction strip;
If a Prolog specifies more than one construction declaration, a static error is raised [ err:XQST0067 ].
[14] |
OrderingModeDecl
|
::= |
"declare"
"ordering"
("ordered"
|
"unordered")
|
[
Definition
:
An
ordering
mode
declaration
sets
the
ordering
mode
in
the
static
context
,
overriding
any
implementation-defined
default.]
This
ordering
mode
applies
to
all
expressions
in
a
module
(including
both
the
Prolog
and
the
Query
Body
,
if
any),
unless
overridden
by
an
ordered
or
unordered
expression.
Ordering
mode
affects
the
behavior
of
path
expressions
that
include
a
"
/
"
or
"
//
"
operator
or
an
axis
step
;
union
,
intersect
,
and
except
expressions;
and
FLWOR
expressions
that
have
no
order
by
clause.
If
ordering
mode
is
ordered
,
node
sequences
returned
by
path,
union
,
intersect
,
and
except
expressions
are
in
document
order
;
otherwise
the
order
of
these
return
sequences
is
implementation-dependent
.
The
effect
of
ordering
mode
on
FLWOR
expressions
is
described
in
3.8
FLWOR
Expressions
.
The following example illustrates an ordering mode declaration:
declare ordering unordered;
If a Prolog contains more than one ordering mode declaration, a static error is raised [ err:XQST0065 ].
[15] |
EmptyOrderDecl
|
::= |
"declare"
"default"
"order"
"empty"
("greatest"
|
"least")
|
[
Definition
:
An
empty
order
declaration
sets
the
default
order
for
empty
sequences
in
the
static
context,
overriding
any
implementation-defined
default.
This
declaration
controls
the
processing
of
empty
sequences
and
NaN
values
as
ordering
keys
in
an
order
by
clause
in
a
FLWOR
expression.]
An
individual
order
by
clause
may
override
the
default
order
for
empty
sequences
by
specifying
empty
greatest
or
empty
least
.
The following example illustrates an empty order declaration:
declare default order empty least;
If a Prolog contains more than one empty order declaration, a static error is raised [ err:XQST0069 ].
Note:
It
is
important
to
distinguish
an
empty
order
declaration
from
an
ordering
mode
declaration
.
An
empty
order
declaration
applies
only
when
an
order
by
clause
is
present,
and
specifies
how
empty
sequences
are
treated
by
the
order
by
clause
(unless
overridden).
An
ordering
mode
declaration
,
on
the
other
hand,
applies
only
in
the
absence
of
an
order
by
clause.
[16] |
CopyNamespacesDecl
|
::= |
"declare"
"copy-namespaces"
PreserveMode
","
InheritMode
|
|
PreserveMode
|
::= |
"preserve"
|
"no-preserve"
|
|
InheritMode
|
::= |
"inherit"
|
"no-inherit"
|
[ Definition : A copy-namespaces declaration sets the value of copy-namespaces mode in the static context , overriding any implementation-defined default. Copy-namespaces mode controls the namespace bindings that are assigned when an existing element node is copied by an element constructor or document constructor.] Handling of namespace bindings by element constructors is described in 3.7.1 Direct Element Constructors .
The following example illustrates a copy-namespaces declaration:
declare copy-namespaces preserve, no-inherit;
If a Prolog contains more than one copy-namespaces declaration, a static error is raised [ err:XQST0055 ].
|
DecimalFormatDecl
|
::= |
"declare"
(("decimal-format"
QName
)
|
("default"
"decimal-format"))
(
DFPropertyName
"="
StringLiteral
)*
|
[18] |
DFPropertyName
| ::= |
"decimal-separator"
|
"grouping-separator"
|
"infinity"
|
"minus-sign"
|
"NaN"
|
"percent"
|
"per-mille"
|
"zero-digit"
|
"digit"
|
"pattern-separator"
|
[
Definition
:
A
decimal-format
declaration
defines
statically
known
decimal
formats
,
which
define
the
properties
used
to
format
numbers
using
the
fn:format-number()
function],
as
described
in
[XQuery
and
XPath
Functions
and
Operators
1.1]
.
It is a static error for a query prolog to contain two decimal formats with the same name, or to contain two default decimal formats. [ err:XQST0096 ]. It is a static error for a decimal-format to specify a value that is not legal for a given property, as described in statically known decimal formats [ err:XQST0097 ]. It is a static error if, for any named or unnamed decimal format, the properties representing characters used in a picture string do not each have distinct values. These properties are decimal-separator-sign , grouping-separator , percent-sign , per-mille-sign , zero-digit , digit-sign , and pattern-separator-sign [ err:XQST0098 ].
[23] |
SchemaImport
|
::= |
"import"
"schema"
SchemaPrefix
?
URILiteral
("at"
URILiteral
(","
URILiteral
)*)?
|
|
SchemaPrefix
|
::= |
("namespace"
NCName
"=")
|
("default"
"element"
"namespace")
|
[
Definition
:
A
schema
import
imports
the
element
declarations,
attribute
declarations,
and
type
definitions
from
a
schema
into
the
in-scope
schema
definitions
.]
.
For
each
user-defined
atomic
type
in
the
schema,
schema
import
also
adds
a
corresponding
constructor
function
.
]
The
schema
to
be
imported
is
identified
by
its
target
namespace
.
The
schema
import
may
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
schema
import
may
also
provide
optional
hints
for
locating
the
schema.
The
namespace
prefix
specified
in
a
schema
import
must
not
be
xml
or
xmlns
[
err:XQST0070
],
and
must
not
be
the
same
as
any
namespace
prefix
bound
in
the
same
module
by
another
schema
import,
a
module
import
,
a
namespace
declaration
,
or
a
module
declaration
[
err:XQST0033
].
The
first
URILiteral
in
a
schema
import
specifies
the
target
namespace
of
the
schema
to
be
imported.
The
URILiterals
that
follow
the
at
keyword
are
optional
location
hints,
and
can
be
interpreted
or
disregarded
in
an
implementation-dependent
way.
Multiple
location
hints
might
be
used
to
indicate
more
than
one
possible
place
to
look
for
the
schema
or
multiple
physical
resources
to
be
assembled
to
form
the
schema.
A
schema
import
that
specifies
a
zero-length
string
as
target
namespace
is
considered
to
import
a
schema
that
has
no
target
namespace.
Such
a
schema
import
may
must
not
bind
a
namespace
prefix
[
err:XQST0057
],
but
it
may
set
the
default
element/type
namespace
to
a
zero-length
string
(representing
"no
namespace"),
thus
enabling
the
definitions
in
the
imported
namespace
to
be
referenced.
If
the
default
element/type
namespace
is
not
set
to
"no
namespace",
there
is
no
way
to
reference
the
definitions
in
an
imported
schema
that
has
no
target
namespace.
It
is
a
static
error
[
err:XQST0058
]
if
more
than
one
schema
import
in
the
same
Prolog
specifies
the
same
target
namespace.
It
is
a
static
error
[
err:XQST0059
]
if
the
implementation
is
not
able
to
process
a
schema
import
by
finding
a
valid
schema
with
the
specified
target
namespace.
It
is
a
static
error
[
err:XQST0035
]
if
multiple
imported
schemas,
or
multiple
physical
resources
within
one
schema,
contain
definitions
for
the
same
name
in
the
same
symbol
space
(for
example,
two
definitions
for
the
same
element
name,
even
if
the
definitions
are
consistent).
However,
it
is
not
an
error
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
schema
types.
It is a static error [ err:XQST0012 ] if the set of definitions contained in all schemas imported by a Prolog do not satisfy the conditions for schema validity specified in Sections 3 and 5 of [XML Schema] Part 1--i.e., each definition must be valid, complete, and unique.
The
following
example
imports
a
schema,
specifying
both
its
target
namespace
and
its
location,
and
binding
the
prefix
soap
to
the
target
namespace:
import schema namespace soap="http://www.w3.org/2003/05/soap-envelope" at "http://www.w3.org/2003/05/soap-envelope/";
The following example imports a schema by specifying only its target namespace, and makes it the default element/type namespace:
import schema default element namespace "http://example.org/abc";
The following example imports a schema that has no target namespace, providing a location hint, and sets the default element/type namespace to "no namespace" so that the definitions in the imported schema can be referenced:
import schema default element namespace "" at "http://example.org/xyz.xsd";
The following example imports a schema that has no target namespace and sets the default element/type namespace to "no namespace". Since no location hint is provided, it is up to the implementation to find the schema to be imported.
import schema default element namespace "";
|
ModuleImport
|
::= |
"import"
"module"
("namespace"
NCName
"=")?
URILiteral
("at"
URILiteral
(","
URILiteral
)*)?
|
[
Definition
:
A
module
import
imports
the
function
variable
declarations
and
variable
public
function
declarations
from
one
or
more
library
modules
into
the
function
signatures
and
in-scope
variables
of
the
importing
module
.]
Each
module
import
names
a
target
namespace
and
imports
an
implementation-defined
set
of
modules
that
share
this
target
namespace.
The
module
import
may
bind
a
namespace
prefix
to
the
target
namespace,
and
it
may
provide
optional
hints
for
locating
the
modules
to
be
imported.
The
namespace
prefix
specified
in
a
module
import
must
not
be
xml
or
xmlns
[
err:XQST0070
],
and
must
not
be
the
same
as
any
namespace
prefix
bound
in
the
same
module
by
another
module
import,
a
schema
import
,
a
namespace
declaration
,
or
a
module
declaration
with
a
different
target
namespace
[
err:XQST0033
].
The
first
URILiteral
in
a
module
import
must
be
of
nonzero
length
[
err:XQST0088
],
and
specifies
the
target
namespace
of
the
modules
to
be
imported.
The
URILiterals
that
follow
the
at
keyword
are
optional
location
hints,
and
can
be
interpreted
or
disregarded
in
an
implementation-defined
way.
It
is
a
static
error
[
err:XQST0047
]
if
more
than
one
module
import
in
a
Prolog
specifies
the
same
target
namespace.
It
is
a
static
error
[
err:XQST0059
]
if
the
implementation
is
not
able
to
process
a
module
import
by
finding
a
valid
module
definition
with
the
specified
target
namespace.
It
is
a
static
error
if
the
expanded
QName
and
arity
of
a
function
declared
in
an
imported
module
are
respectively
equal
to
the
expanded
QName
and
arity
of
a
function
declared
in
the
importing
module
or
in
another
imported
module
(even
if
the
declarations
are
consistent)
[
err:XQST0034
].
It
is
a
static
error
if
the
expanded
QName
of
a
variable
declared
in
an
imported
module
is
equal
(as
defined
by
the
eq
operator)
to
the
expanded
QName
of
a
variable
declared
in
the
importing
module
or
in
another
imported
module
(even
if
the
declarations
are
consistent)
[
err:XQST0049
].
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 modules, such as in-scope schema definitions or statically known 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.
A
module
may
import
its
own
target
namespace
(this
is
interpreted
as
importing
an
implementation-defined
set
of
other
modules
that
share
its
target
namespace.)
However,
it
is
a
static
error
[
err:XQST0073
]
if
the
graph
of
module
imports
contains
a
cycle
(that
is,
if
there
exists
a
sequence
of
modules
M
1
...
M
n
such
that
each
M
i
imports
M
i+1
and
M
n
imports
M
1
),
unless
all
the
modules
in
the
cycle
share
a
common
namespace.
It
is
a
static
error
[
err:XQST0036
]
to
import
a
module
if
the
importing
module's
in-scope
schema
types
definitions
of
the
importing
module
do
not
include
definitions
for
all
of
the
following:
An
in-scope
schema
type
names
for
each
type-name
that
appear
appears:
in
the
declarations
type
of
variables
a
variable
that
is
declared
in
the
imported
module
and
functions
(whether
referenced
in
an
argument
type
the
importing
module,
OR
in
a
parameter-type
or
return
type)
result-type
of
a
function
that
are
present
is
declared
in
the
imported
module
and
are
referenced
in
the
importing
module.
An
in-scope
element
declaration
for
each
element-name
EN
such
that:
schema-element(EN)
appears
in
the
declared
type
of
a
variable
in
the
imported
module,
and
that
variable
is
referenced
in
the
importing
module,
OR
schema-element(EN)
appears
in
a
parameter-type
or
result-type
of
a
function
declared
in
the
imported
module,
and
that
function
is
referenced
in
the
importing
module.
An
in-scope
attribute
declaration
for
each
attribute-name
AN
such
that:
schema-attribute(AN)
appears
in
the
declared
type
of
a
variable
in
the
imported
module,
and
that
variable
is
referenced
in
the
importing
module,
OR
schema-attribute(AN)
appears
in
a
parameter-type
or
result-type
of
a
function
declared
in
the
imported
module,
and
that
function
is
referenced
in
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
geometry
,
and
declares
a
function
with
the
following
function
signature
:
math:area($t
as
geometry: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
definition
of
the
type
geometry:triangle
used
in
the
signature
of
the
area
function.
[
Definition
:
A
module
M
1
directly
depends
on
another
module
M
2
(different
from
M
1
)
if
a
variable
or
function
declared
in
M
1
depends
on
a
variable
or
function
declared
in
M
2
.]
It
is
a
static
error
[
err:XQST0093
]
to
import
a
module
M
1
if
there
exists
a
sequence
of
modules
M
1
...
M
i
...
M
1
such
that
each
module
directly
depends
on
the
next
module
in
the
sequence
(informally,
if
M
1
depends
on
itself
through
some
chain
of
module
dependencies.)
The
following
example
illustrates
a
module
import:
import module namespace math = "http://example.org/math-functions";import module namespace math = "http://example.org/math-functions";
[10] |
NamespaceDecl
|
::= |
"declare"
"namespace"
NCName
"="
URILiteral
|
[ Definition : A namespace declaration declares a namespace prefix and associates it with a namespace URI, adding the (prefix, URI) pair to the set of statically known namespaces .] The namespace declaration is in scope throughout the query in which it is declared, unless it is overridden by a namespace declaration attribute in a direct element constructor .
If
the
URILiteral
part
of
a
namespace
declaration
is
a
zero-length
string,
any
existing
namespace
binding
for
the
given
prefix
is
removed
from
the
statically
known
namespaces
.
This
feature
provides
a
way
to
remove
predeclared
namespace
prefixes
such
as
local
.
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
.
The
namespace
prefix
specified
in
a
namespace
declaration
must
not
be
xml
or
xmlns
[
err:XQST0070
],
and
].
The
namespace
URI
specified
in
a
namespace
declaration
must
not
be
http://www.w3.org/XML/1998/namespace
or
http://www.w3.org/2000/xmlns/
[
err:XQST0070
].
The
namespace
prefix
specified
in
a
namespace
declaration
must
not
be
the
same
as
any
namespace
prefix
bound
in
the
same
module
by
a
module
import
,
schema
import
,
module
declaration
,
or
another
namespace
declaration
[
err:XQST0033
].
It is a static error [ err:XPST0081 ] if an expression contains a QName with a namespace prefix that is not in the statically known namespaces .
XQuery
has
several
predeclared
namespace
prefixes
that
are
present
in
the
statically
known
namespaces
before
each
query
is
processed.
These
prefixes
may
be
used
without
an
explicit
declaration.
They
may
be
overridden
by
namespace
declarations
in
a
Prolog
or
by
namespace
declaration
attributes
on
constructed
elements
(however,
the
prefix
xml
may
must
not
be
redeclared,
and
no
other
prefix
may
be
bound
to
the
namespace
URI
associated
with
the
prefix
xml
[
err:XQST0070
]).
The
predeclared
namespace
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/2005/xpath-functions
local
=
http://www.w3.org/2005/xquery-local-functions
(see
4.15
4.17
Function
Declaration
.)
Additional predeclared namespace prefixes may be added to the statically known namespaces by an implementation.
When element or attribute names are compared, they are considered identical if the local parts and namespace URIs match on a codepoint basis. 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 xmlns:foo = "http://example.org"> Lentils </foo:bing>
[12] |
DefaultNamespaceDecl
|
::= |
"declare"
"default"
("element"
|
"function")
"namespace"
URILiteral
|
Default namespace declarations can be used in a Prolog to facilitate the use of unprefixed QNames. The following kinds of default namespace declarations are supported:
A default element/type namespace declaration declares a namespace URI that is associated with unprefixed names of elements and types. This declaration is recorded as the default element/type namespace in the static context . A Prolog may contain at most one default element/type namespace declaration [ err:XQST0066 ]. If the URILiteral in a default element/type namespace declaration is a zero-length string, the default element/type namespace is undeclared (set to "none"), and unprefixed names of elements and types are considered to be 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";
A default element/type namespace declaration may be overridden by a namespace declaration attribute in a direct element constructor .
If no default element/type namespace declaration is present, unprefixed element and type names are in no namespace (however, an implementation may define a different default as specified in C.1 Static Context Components .)
A default function namespace declaration declares a namespace URI that is associated with unprefixed function names in function calls and function declarations. This declaration is recorded as the default function namespace in the static context . A Prolog may contain at most one default function namespace declaration [ err:XQST0066 ]. If the StringLiteral in a default function namespace declaration is a zero-length string, the default function namespace is undeclared (set to "none"). In that case, any functions that are associated with a namespace can be called only by using an explicit namespace prefix.
If
no
default
function
namespace
declaration
is
present,
the
default
function
namespace
is
the
namespace
of
XPath/XQuery
functions,
http://www.w3.org/2005/xpath-functions
(however,
an
implementation
may
define
a
different
default
as
specified
in
C.1
Static
Context
Components
.)
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 , can be invoked without specifying a namespace prefix. 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:XPST0017 ].
Note:
Only constructor functions can be in no namespace.
Unprefixed attribute names and variable names are in no namespace.
Note:
Some details in this section are yet to be worked out.
|
VarDecl
|
::= |
"declare"
"variable"
"$"
|
|
VarName
|
::= |
QName
|
|
TypeDeclaration
|
::= |
"as"
SequenceType
|
[27] |
VarValue
| ::= |
ExprSingle
|
[28] |
VarDefaultValue
| ::= |
ExprSingle
|
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
variable
values
.
If
Note:
A 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.
During
static
analysis,
a
variable
declaration
causes
a
pair
(expanded
QName
N,
type
T)
to
be
added
to
the
in-scope
variables
.
The
expanded
QName
of
N
is
the
variable
VarName
.
If
N
is
equal
(as
defined
by
the
eq
operator)
to
the
name
expanded
QName
of
another
variable
in
in-scope
variables
,
variables,
a
static
error
is
raised
[
err:XQST0049
].
If
a
All
variable
declaration
includes
names
declared
in
a
type,
that
type
library
module
must
(when
expanded)
be
in
the
target
namespace
of
the
library
module
[
err:XQST0048
].
When
a
library
module
is
imported,
variables
declared
in
the
imported
module
are
added
to
the
static
context
as
the
type
in-scope
variables
of
the
variable.
If
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
variable
declaration
includes
an
expression
but
not
an
explicit
type,
the
main
module.
The
type
of
the
variable
T
is
inferred
from
static
analysis
of
as
follows:
If
TypeDeclaration
is
present,
then
the
expression
SequenceType
in
the
TypeDeclaration
;
otherwise
If
the
Static
Typing
Feature
is
in
effect
and
VarValue
is
added
to
present,
then
the
static
context
.
If
a
variable
declaration
includes
both
a
type
and
an
expression,
the
value
returned
by
inferred
from
static
analysis
of
the
expression
must
match
the
declared
type
according
to
VarValue
;
Note:
Type
inference
might
not
be
computable
until
after
the
rules
check
for
SequenceType
matching
;
otherwise
a
type
error
circular
dependencies,
described
below,
is
raised
[
err:XPTY0004
].
complete.
Otherwise,
item()*
.
[
Definition
:
If
a
variable
declaration
includes
an
expression,
expression
(
VarValue
or
VarDefaultValue
),
the
expression
is
called
an
initializing
expression
.]
The
initializing
expression
for
a
given
variable
must
be
evaluated
before
the
evaluation
of
any
expression
that
references
the
variable.
expression.
The
static
context
for
an
initializing
expression
includes
all
functions
that
are
declared
or
imported
anywhere
in
the
Prolog
,
but
it
includes
only
those
variables
functions,
variables,
and
namespaces
that
are
declared
or
imported
earlier
anywhere
in
the
Prolog
Prolog,
other
than
the
variable
that
is
being
initialized.
declared.]
[
Definition
:
A
variable
An
expression
depends
on
a
variable
$x
E
$y
V
or
a
function
if
any
of
the
following
is
true:
|
]
If
the
initializer
of
a
variable
V
depends
on
itself,
V
,
a
static
error
is
raised,
a
static
error
is
raised
[
err:XQST0054
].
If
the
During
query
evaluation,
each
variable
declaration
includes
causes
a
pair
(expanded
QName
N,
value
V)
to
be
added
to
the
keyword
Prolog
variable
values
.
The
expanded
QName
N
is
the
VarName
.
The
value
V
is
as
follows:
If
VarValue
is
specified,
then
V
is
the
result
of
evaluating
VarValue
as
described
below.
If
external
is
specified,
then:
,
if
a
value
must
be
is
provided
for
the
variable
by
the
external
environment
before
the
query
can
be
evaluated.
If
an
environment,
then
V
is
that
value.
The
means
by
which
typed
values
of
external
variable
declaration
also
includes
a
declared
type,
the
value
variables
are
provided
by
the
external
environment
must
match
the
declared
type
according
to
the
rules
for
SequenceType
matching
(see
2.2.5
Consistency
Constraints
).
If
an
external
variable
declaration
does
not
include
a
declared
type,
the
type
and
a
matching
is
implementation-defined.
if
no
value
must
be
is
provided
for
the
variable
by
the
external
environment
at
evaluation
time.
The
static
type
of
such
a
variable
is
considered
to
be
environment,
and
is
specified,
then
V
is
the
result
of
evaluating
item()*
.
Any
reference
to
a
variable
that
was
declared
VarDefaultValue
as
described
below.
external
,
but
was
not
bound
to
a
VarDefaultValue
If
no
value
is
provided
for
the
variable
by
the
external
environment,
raises
and
VarDefaultValue
is
not
specified,
then
a
dynamic
error
is
raised
[
err:XPDY0002
].
All
variable
names
declared
in
a
library
module
must
(when
expanded)
be
in
It
is
implementation-dependent
whether
this
error
is
raised
if
the
target
namespace
evaluation
of
the
library
module
query
does
not
reference
the
value
of
the
variable.
In
all
cases
the
value
V
must
match
the
type
T
according
to
the
rules
for
SequenceType
matching;
otherwise
a
type
error
is
raised
[
err:XQST0048
err:XPTY0004
].
When
a
library
module
If
VarValue
or
VarDefaultValue
is
imported,
variables
declared
in
evaluated,
the
imported
module
are
added
to
dynamic
context
for
the
in-scope
variables
evaluation
is
as
follows:
The
variable
values
contain
the
values
of
all
variables
present
in
the
importing
module.
static
context.
Note:
Variable
names
that
have
no
namespace
prefix
are
in
no
namespace.
Variable
declarations
that
have
no
namespace
prefix
may
appear
only
in
A
cyclic
dependency
between
variables
is
a
main
module.
static
error,
so
it
is
always
possible
to
evaluate
all
the
variables
that
V
depends
on
before
evaluating
V.)
The
term
variable
declaration
always
refers
to
a
declaration
function
implementations
contains
the
implementation
of
a
variable
each
function
present
in
a
Prolog
.
The
binding
the
static
context
All
other
properties
of
a
variable
to
a
value
in
a
query
expression,
such
as
a
FLWOR
expression,
is
known
as
a
variable
binding
,
the
dynamic
context,
including
the
context
item,
position,
and
does
not
make
size,
are
the
variable
visible
to
an
importing
same
as
for
the
evaluation
of
the
QueryBody
of
the
main
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
item()*
.
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;
The following declaration, which might appear in a library module, declares a variable whose name includes a namespace prefix:
declare variable $math:pi as xs:double := 3.14159E0;
This
is
an
example
of
an
external
variable
declaration
that
provides
a
VarDefaultValue
:
declare variable $x as xs:integer external := 47;
[29] |
ContextItemDecl
| ::= |
"declare"
"context"
"item"
("as"
ItemType
)?
((":="
VarValue
)
|
("external"
(":="
VarDefaultValue
)?))
|
A context item declaration allows a query to specify the static type , value, or default value for the initial context item.
When
a
context
item
declaration
appears
in
a
library
module,
neither
VarValue
nor
VarDefaultValue
may
be
specified.
Such
a
context
item
declaration
serves
only
to
declare
the
expected
type
of
the
context
item.
In every module that does not contain a context item declaration, the effect is as if the declaration
declare context item as item() external;
appeared in that module.
During
static
analysis,
the
context
item
declaration
has
the
effect
of
setting
the
context
item
static
type
in
the
static
context.
The
context
item
static
type
is
set
to
ItemType
if
specified,
or
to
item()
otherwise.
If a module contains more than one context item declaration, a static error is raised [ err:XQST0099 ].
The static context for an initializing expression includes all functions, variables, and namespaces that are declared or imported anywhere in the Prolog.
[
Definition
:
An
expression
E
depends
on
the
context
item
if
any
of
the
following
is
true:
|
]
If the initializer of the context item depends on the context item, a static error is raised [ err:XQST0107 ].
During
query
evaluation,
the
context
item
in
the
dynamic
context
for
the
evaluation
of
the
QueryBody
in
the
main
module,
and
for
the
initializing
expression
of
every
variable
declaration
in
every
module,
is
set
as
follows:
If
VarValue
is
specified,
then
the
result
of
evaluating
VarValue
as
described
below.
If
external
is
specified,
then:
if a value is provided for the context item by the external environment, then that value.
The means by which an external value is provided by the external environment is implementation-defined.
if
no
value
is
provided
for
the
context
item
by
the
external
environment,
and
VarDefaultValue
is
specified,
then
the
result
of
evaluating
VarDefaultValue
as
described
below.
if
no
value
is
provided
for
the
context
item
by
the
external
environment,
and
VarDefaultValue
is
not
specified,
then
the
context
item
is
undefined
,
and
a
dynamic
error
is
raised
[
err:XPDY0002
]
if
the
context
item
is
referenced
in
the
query.
In
all
cases
where
the
context
item
has
a
value,
that
value
must
match
the
type
T
according
to
the
rules
for
SequenceType
matching;
otherwise
a
type
error
is
raised
[
err:XPTY0004
].
If
more
than
one
module
contains
a
context
item
declaration,
the
context
item
must
match
the
type
declared
in
each
one.
If
VarValue
or
VarDefaultValue
is
evaluated,
the
dynamic
context
for
the
evaluation
is
as
follows:
The variable values contains the values of all variables present in the static context
The context item, position, and size are undefined
Function implementations includes an implementation of each function present in the static context of the expression
All
other
properties
of
the
dynamic
context
are
the
same
as
for
the
evaluation
of
the
QueryBody
of
the
main
module.
Here are some examples of context item declarations.
Declare the type of the context item:
declare namespace env="http://www.w3.org/2003/05/soap-envelope"; declare context item as element(env:Envelope) external;
Declare a default context item, which is a system log in a default location. If the system log is in a different location, it can be specified in the external environment:
declare context item as element(sys:log) external := doc("/var/xlogs/sysevent.xml");
Declare the context item to always point to a particular collection:
declare context item := collection("docs");
In
addition
to
the
built-in
functions
described
in
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
,
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.5
Types
.
A
function
declaration
causes
the
declared
function
to
be
added
to
the
function
signatures
of
the
module
in
which
it
appears.
|
FunctionDecl
|
::= |
"declare"
FunctionOptions
"function"
QName
"("
ParamList
?
")"
("as"
SequenceType
)?
(
|
|
FunctionOptions
| ::= |
(
PrivateOption
|
DeterministicOption
)*
|
|
PrivateOption
|
::= |
"private"
|
"public"
|
[34] |
DeterministicOption
| ::= |
"deterministic"
|
"nondeterministic"
|
[35] |
ParamList
| ::= |
Param
(","
Param
)*
|
|
Param
|
::= |
"$"
QName
TypeDeclaration
?
|
|
FunctionBody
| ::= |
EnclosedExpr
|
|
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
User
defined
functions
are
functions
that
contain
a
function
body
that
defines
how
,
which
provides
the
result
implementation
of
the
function
is
computed
from
its
parameters.].
as
an
XQuery
expression.]
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
functions,
variables,
and
namespaces
that
are
declared
or
imported
earlier
anywhere
in
the
Prolog
than
,
including
the
function
that
is
being
defined.
declared.
[
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]
Operators
1.1]
.
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.
A function declaration may specify (via FunctionOptions ) that the function has certain properties, as described below. It is a static error [ err:XQST0106 ] if a FunctionOptions contains more than one PrivateOption or more than one DeterministicOption .
A function declaration may specify that a function is private or public (which is the default). [ Definition : A private function is hidden from module import , which can not import it into the function signatures of another module. ] [ Definition : A public function is accessible to module import , which can import it into the function signatures of another module. ]
A function declaration may specify that an external function is deterministic (which is the default) or nondeterministic. [ Definition : A deterministic function is a function that always evaluates to the same result if it is invoked with the same arguments.] [ Definition : A nondeterministic function is a function that is not guaranteed to always return the same result when it is invoked with the same arguments.]. An XQuery processor can use static analysis to determine whether a user-defined function is deterministic (the syntax of function declarations does not allow a user-defined function to be declared deterministic or nondeterministic).
When
rewriting
expressions
into
equivalent
expressions,
as
described
in
2.3.4
Errors
and
Optimization
,
a
conforming
XQuery
implementation
must
ensure
that
each
run-time
invocation
of
a
nondeterministic
function
in
the
original
expression
results
in
exactly
one
run-time
invocation
of
the
function
in
the
rewritten
expression.
For
instance,
suppose
the
random()
function
is
declared
to
be
nondeterministic:
declare nondeterministic function my:random( ) as xs:integer external;
Given the above declaration, this expression:
let $r := my:random( ) return if ($r > 0 and $r < 10) then "Yes" else "No"
must not be rewritten as
if (my:random( ) > 0 and my:random( ) < 10) then "Yes" else "No"
Similarly, this expression:
for $i in 1 to 10 return my:random( )
must not be rewritten as
let $r := my:random( ) return for $i in 1 to 10 return $r
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/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
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.
These
additional
types,
if
defined,
are
considered
to
be
derived
by
restriction
from
xs:anyAtomicType
.
Every user-defined function must be in a namespace--that is, every declared function name must (when expanded) have a non-null namespace URI [ err:XQST0060 ]. If the function name in a function declaration has no namespace prefix, it is considered to be in the default function namespace . Every function name declared in a library module must (when expanded) be in the target namespace of the library module [ err:XQST0048 ]. It is a static error [ err:XQST0045 ] if the function name in a function declaration (when expanded) is in any of the following namespaces:
http://www.w3.org/XML/1998/namespace
http://www.w3.org/2001/XMLSchema
http://www.w3.org/2001/XMLSchema-instance
http://www.w3.org/2005/xpath-functions
It
is
a
static
error
[
err:XQST0034
]
if
the
expanded
QName
and
arity
(number
of
arguments)
of
the
declared
function
are
equal
(as
defined
by
the
eq
operator)
to
the
expanded
QName
and
arity
of
another
function
in
function
signatures
.
In
order
to
allow
main
modules
to
declare
functions
for
local
use
within
the
module
without
defining
a
new
namespace,
XQuery
predefines
the
namespace
prefix
local
to
the
namespace
http://www.w3.org/2005/xquery-local-functions
.
It
is
suggested
(but
not
required)
that
this
namespace
be
used
for
defining
local
functions.
If
a
function
parameter
is
declared
using
a
name
but
no
type,
its
default
type
is
item()*
.
If
the
result
type
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:XQST0039 ] 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 sequence type .
The
following
example
illustrates
the
declaration
and
use
of
a
local
function
that
accepts
a
sequence
of
employee
elements,
summarizes
them
by
department,
and
returns
a
sequence
of
dept
elements.
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—that
is,
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
the
default
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"))
Since a constructor function is effectively declared for every user-defined atomic type in the in-scope schema types , a static error [ err:XQST0034 ] is raised if the Prolog attempts to declare a single-parameter function with the same expanded QName as any of these types.
[
Definition
:
An
expression
E
depends
on
a
function
if
any
of
the
following
is
true:
|
]
[ Definition : An option declaration declares an option that affects the behavior of a particular implementation. Each option consists of an identifying QName and a StringLiteral.]
[13] |
OptionDecl
|
::= |
"declare"
"option"
QName
StringLiteral
|
Typically, a particular option will be recognized by some implementations and not by others. The syntax is designed so that option declarations can be successfully parsed by all implementations.
The QName of an option must resolve to a namespace URI and local name, using the statically known namespaces [ err:XPST0081 ].
Note:
There is no default namespace for options.
Each implementation recognizes an implementation-defined set of namespace URIs used to denote option declarations.
If the namespace part of the QName is not a namespace recognized by the implementation as one used to denote option declarations, then the option declaration is ignored.
Otherwise, the effect of the option declaration, including its error behavior, is implementation-defined . For example, if the local part of the QName is not recognized, or if the StringLiteral does not conform to the rules defined by the implementation for the particular option declaration, the implementation may choose whether to report an error, ignore the option declaration, or take some other action.
Implementations may impose rules on where particular option declarations may appear relative to variable declarations and function declarations, and the interpretation of an option declaration may depend on its position.
An
option
declaration
must
not
be
used
to
change
the
syntax
accepted
by
the
processor,
or
to
suppress
the
detection
of
static
errors.
errors
.
However,
it
may
be
used
without
restriction
to
modify
the
semantics
of
the
query.
The
scope
of
the
option
declaration
is
implementation-defined
—for
example,
an
option
declaration
might
apply
to
the
whole
query,
to
the
current
module,
or
to
the
immediately
following
function
declaration.
The following examples illustrate several possible uses for option declarations:
This
option
declaration
might
be
used
to
set
a
serialization
parameter:
declare namespace exq = "http://example.org/XQueryImplementation";
declare option exq:output "encoding = iso-8859-1";
This
option
declaration
might
be
used
to
specify
how
comments
in
source
documents
returned
by
the
fn:doc()
function
should
be
handled:
declare option exq:strip-comments "true";
This option declaration might be used to associate a namespace used in function names with a Java class:
declare namespace math = "http://example.org/MathLibrary"; declare option exq:java-class "math = java.lang.Math";
Note:
The XQuery Working Group has not yet determined conformance criteria for XQuery 1.1; in particular, we have not decided which of the new features of XQuery 1.1 are optional. This section currently contains the conformance criteria for XQuery 1.0, with two modifications: (1) support for all axes is now required, (2) conformance criteria for syntax extensions are given.
This section defines the conformance criteria for an XQuery processor. In this section, the following terms are used to indicate the requirement levels defined in [RFC 2119] . [ Definition : MUST means that the item is an absolute requirement of the specification.] [ Definition : MAY means that an item is truly optional.] [ Definition : SHOULD means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.]
An XQuery processor that claims to conform to this specification MUST include a claim of Minimal Conformance as defined in 5.1 Minimal Conformance . In addition to a claim of Minimal Conformance, it MAY claim conformance to one or more optional features defined in 5.2 Optional Features .
Minimal Conformance to this specification MUST include all of the following items:
Support for everything specified in this document except those features specified in 5.2 Optional Features to be optional. If an implementation does not provide a given optional feature, it MUST implement any requirements specified in 5.2 Optional Features for implementations that do not provide that feature.
A definition of every item specified to be implementation-defined , unless that item is part of an optional feature that is not supported by the implementation. A list of implementation-defined items can be found in D Implementation-Defined Items .
Note:
Implementations are not required to define items specified to be implementation-dependent .
Support
for
[XQuery/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
,
as
specified
in
5.3
Data
Model
Conformance
.
Support
for
all
functions
defined
in
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
.
[ Definition : The Schema Import Feature permits the query Prolog to contain a schema import .]
If an XQuery implementation does not support the Schema Import Feature, it MUST raise a static error [ err:XQST0009 ] if it encounters a schema import.
Note:
If an implementation does not support the Schema Import Feature, the in-scope schema types consist only of built-in and implementation-defined schema type definitions, as described in C.1 Static Context Components .
[
Definition
:
The
Schema
Validation
Feature
permits
a
query
to
contain
a
validate
expression
(see
3.13
3.15
Validate
Expressions
.)]
If
an
XQuery
implementation
does
not
support
the
Schema
Validation
Feature,
it
MUST
raise
a
static
error
[
err:XQST0075
]
if
it
encounters
a
validate
expression.
[
Definition
:
The
Static
Typing
Feature
provides
support
for
the
static
semantics
defined
in
[XQuery
1.0
and
XPath
2.0
Formal
Semantics]
,
and
requires
implementations
to
detect
and
report
all
type
errors
during
the
static
analysis
phase
.]
If
an
implementation
does
not
support
supports
the
Static
Typing
Feature
,
but
can
nevertheless
determine
during
the
static
analysis
phase
that
an
expression,
if
evaluated,
will
necessarily
raise
a
type
error
at
run
time,
the
implementation
MAY
then
it
MUST
raise
that
report
an
error
during
the
static
analysis
phase.
The
choice
whenever
the
inferred
static
type
of
whether
to
raise
such
an
error
at
analysis
time
expression
is
implementation
dependent
.
Note:
An
implementation
that
does
not
support
subsumed
by
the
Static
Typing
Feature
is
not
required
to
raise
type
errors
during
for
the
static
analysis
phase;
however,
context
in
which
it
MUST
detect
and
raise
non-type-related
static
errors
during
the
static
analysis
phase.
appears.
In
some
cases,
the
static
typing
rules
defined
in
[XQuery
1.0
and
XPath
2.0
Formal
Semantics]
are
If
an
implementation
does
not
very
precise
(see,
for
example,
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
that
implements
the
Static
Typing
Feature
,
then
it
MAY
also
provide
one
or
more
static
typing
extensions
.
[
Definition
:
A
static
typing
extension
is
an
implementation-defined
type
inference
rule
that
infers
a
more
precise
static
report
type
than
that
inferred
by
errors
during
the
type
inference
rules
static
analysis
phase
only
in
[XQuery
1.0
and
XPath
2.0
Formal
Semantics]
.]
See
Section
6.1.1
Static
Typing
Extensions
FS
for
a
formal
definition
of
cases
where
the
constraints
on
inferred
static
typing
extensions.
5.2.4
Full
Axis
Feature
[
Definition
:
The
following
axes
are
designated
as
optional
axes
:
ancestor
,
ancestor-or-self
,
following
,
following-sibling
,
preceding
,
type
and
preceding-sibling
.]
[
Definition
:
A
conforming
XQuery
implementation
that
supports
the
Full
Axis
Feature
MUST
support
all
the
optional
axes
.]
Conforming
XQuery
implementations
that
do
not
support
required
type
have
an
empty
intersection
(that
is,
where
evaluation
of
the
Full
Axis
Feature
expression
is
guaranteed
to
fail).
It
MAY
support
one
defer
some
or
more
optional
axes;
it
is
implementation-defined
which
optional
axes
are
supported
by
such
implementations.
A
conforming
implementation
that
encounters
a
reference
to
an
optional
axis
that
it
does
not
support
MUST
raise
a
static
error
[
err:XPST0010
].
Note:
XQuery
does
not
recognize
all
type
checking
until
the
namespace
axis
(defined
by
XPath
1.0
and
deprecated
by
XPath
2.0).
dynamic
evaluation
phase.
[ Definition : A conforming XQuery implementation that supports the Module Feature allows a query Prolog to contain a Module Import and allows library modules to be created.]
A conforming implementation that does not support the Module Feature MUST raise a static error [ err:XQST0016 ] if it encounters a module declaration or a module import . Since a module declaration is required in a library module , the Module Feature is required in order to create a library module .
Note:
In the absence of the Module Feature, each query consists of a single main module .
[ Definition : A conforming XQuery implementation that supports the Serialization Feature MUST provide means for serializing the result of a query, as specified in 2.2.4 Serialization .]
A conforming XQuery implementation that supports the Serialization Feature MUST conform to C.3 Serialization Parameters . The means by which serialization is invoked is implementation-defined .
If
an
error
is
raised
during
the
serialization
process
as
specified
in
[XSLT
2.0
and
XQuery
1.0
Serialization]
Serialization
1.1]
,
an
conforming
XQuery
implementation
MUST
report
the
error
to
the
calling
environment.
Note:
Not all implementations need to serialize. For instance, an implementation might provide results via an XML API instead of producing a textual representation.
All
XQuery
implementations
process
data
represented
in
the
data
model
as
specified
in
[XQuery/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
.
The
data
model
specification
relies
on
languages
such
as
XQuery
to
specify
conformance
criteria
for
the
data
model
in
their
respective
environments,
and
suggests
that
the
following
issues
should
be
considered:
Support for normative construction from an infoset. A conforming implementation MAY choose to claim conformance to Section 3.2 Construction from an Infoset DM , which defines a normative way to construct an XDM instance from an XML document that is merely well-formed or is governed by a DTD.
Support for normative construction from a PSVI. A conforming implementation MAY choose to claim conformance to Section 3.3 Construction from a PSVI DM , which defines a normative way to construct an XDM instance from an XML document that is governed by a W3C XML Schema.
Support
for
XML
1.0
and
XML
1.1.
The
[XQuery/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
supports
either
[XML
1.0]
or
[XML
1.1]
.
In
XQuery,
the
choice
of
which
XML
version
to
support
is
implementation-defined
.
At
the
time
of
writing
there
is
no
published
version
of
XML
Schema
that
references
the
XML
1.1
specifications.
This
means
that
datatypes
such
as
xs:NCName
and
xs:ID
are
constrained
by
the
XML
1.0
rules.
It
is
recommended
that
an
XQuery
1.0
processor
should
implement
the
rules
defined
by
later
versions
of
XML
Schema
as
they
become
available.
Note:
For suggestions on processing XML 1.1 documents, see [XML 1.1 and Schema 1.0] .
Ranges of data values. In XQuery, the following limits are implementation-defined :
For
the
xs:decimal
type,
the
maximum
number
of
decimal
digits
(
totalDigits
facet)
(must
be
at
least
18).
For
the
types
xs:date
,
xs:time
,
xs:dateTime
,
xs:gYear
,
and
xs:gYearMonth
:
the
maximum
value
of
the
year
component
and
the
maximum
number
of
fractional
second
digits
(must
be
at
least
3).
For
the
xs:duration
type
:
the
maximum
absolute
values
of
the
years,
months,
days,
hours,
minutes,
and
seconds
components.
For
the
xs:yearMonthDuration
type:
the
maximum
absolute
value,
expressed
as
an
integer
number
of
months.
For
the
xs:dayTimeDuration
type:
the
maximum
absolute
value,
expressed
as
a
decimal
number
of
seconds.
For
the
types
xs:string
,
xs:hexBinary
,
xs:base64Binary
,
xs:QName
,
xs:anyURI
,
xs:NOTATION
,
and
types
derived
from
them:
limitations
(if
any)
imposed
by
the
implementation
on
lengths
of
values.
The
limits
listed
above
need
not
be
fixed,
but
may
depend
on
environmental
factors
such
as
system
resources.
For
example,
the
length
of
a
value
of
type
xs:string
may
be
limited
by
available
memory.
Any syntactic extensions to XQuery are implementation-defined . The effect of syntactic extensions, including their error behavior, is implementation-defined . Syntactic extensions may be used without restriction to modify the semantics of a XQuery expression.
The grammar of XQuery 1.1 uses the same simple Extended Backus-Naur Form (EBNF) notation as [XML 1.0] with the following minor differences.
All named symbols have a name that begins with an uppercase letter.
It adds a notation for referring to productions in external specs.
Comments or extra-grammatical constraints on grammar productions are between '/*' and '*/' symbols.
A 'xgc:' prefix is an extra-grammatical constraint, the details of which are explained in A.1.2 Extra-grammatical Constraints
A 'ws:' prefix explains the whitespace rules for the production, the details of which are explained in A.2.4 Whitespace Rules
A 'gn:' prefix means a 'Grammar Note', and is meant as a clarification for parsing rules, and is explained in A.1.3 Grammar Notes . These notes are not normative.
The terminal symbols for this grammar include the quoted strings used in the production rules below, and the terminal symbols defined in section A.2.1 Terminal Symbols .
The EBNF notation is described in more detail in A.1.1 Notation .
To increase readability, the EBNF in the main body of this document omits some of these notational features. This appendix is the normative version of the EBNF.
[1] |
Module
|
::= |
VersionDecl
?
(
LibraryModule
|
MainModule
)
|
|
[2] |
VersionDecl
|
::= |
"xquery"
|
|
[3] |
MainModule
|
::= |
Prolog
QueryBody
|
|
[4] |
LibraryModule
|
::= |
ModuleDecl
Prolog
|
|
[5] |
ModuleDecl
|
::= |
"module"
"namespace"
NCName
"="
URILiteral
Separator
|
|
[6] |
Prolog
|
::= |
((
DefaultNamespaceDecl
|
Setter
|
NamespaceDecl
|
Import
)
Separator
)*
((
VarDecl
|
ContextItemDecl
|
FunctionDecl
|
OptionDecl
)
Separator
)*
|
|
[7] |
Setter
|
::= |
BoundarySpaceDecl
|
DefaultCollationDecl
|
BaseURIDecl
|
ConstructionDecl
|
OrderingModeDecl
|
EmptyOrderDecl
|
CopyNamespacesDecl
|
DecimalFormatDecl
|
|
[8] |
Import
|
::= |
SchemaImport
|
ModuleImport
|
|
[9] |
Separator
|
::= |
";"
|
|
[10] |
NamespaceDecl
|
::= |
"declare"
"namespace"
NCName
"="
URILiteral
|
|
[11] |
BoundarySpaceDecl
|
::= |
"declare"
"boundary-space"
("preserve"
|
"strip")
|
|
[12] |
DefaultNamespaceDecl
|
::= |
"declare"
"default"
("element"
|
"function")
"namespace"
URILiteral
|
|
[13] |
OptionDecl
|
::= |
"declare"
"option"
QName
StringLiteral
|
|
[14] |
OrderingModeDecl
|
::= |
"declare"
"ordering"
("ordered"
|
"unordered")
|
|
[15] |
EmptyOrderDecl
|
::= |
"declare"
"default"
"order"
"empty"
("greatest"
|
"least")
|
|
[16] |
CopyNamespacesDecl
|
::= |
"declare"
"copy-namespaces"
PreserveMode
","
InheritMode
|
|
[17] |
DecimalFormatDecl
|
::= |
"declare"
(("decimal-format"
QName
)
|
("default"
"decimal-format"))
(
DFPropertyName
"="
StringLiteral
)*
| |
[18] |
DFPropertyName
|
::= |
|
|
|
PreserveMode
| ::= |
"preserve"
|
"no-preserve"
| |
|
InheritMode
|
::= |
"inherit"
|
"no-inherit"
|
|
|
DefaultCollationDecl
|
::= |
"declare"
"default"
"collation"
URILiteral
|
|
|
BaseURIDecl
|
::= |
"declare"
"base-uri"
URILiteral
|
|
|
SchemaImport
|
::= |
"import"
"schema"
SchemaPrefix
?
URILiteral
("at"
URILiteral
(","
URILiteral
)*)?
|
|
|
SchemaPrefix
|
::= |
("namespace"
NCName
"=")
|
("default"
"element"
"namespace")
|
|
|
ModuleImport
|
::= |
"import"
"module"
("namespace"
NCName
"=")?
URILiteral
("at"
URILiteral
(","
URILiteral
)*)?
|
|
|
VarDecl
|
::= |
"declare"
"variable"
"$"
|
|
|
VarValue
|
::= |
ExprSingle
|
|
[28] |
VarDefaultValue
| ::= |
ExprSingle
| |
[29] |
ContextItemDecl
| ::= |
"declare"
"context"
"item"
("as"
ItemType
)?
((":="
VarValue
)
|
("external"
(":="
VarDefaultValue
)?))
| |
[30] |
ConstructionDecl
|
::= |
"declare"
"construction"
("strip"
|
"preserve")
|
|
|
FunctionDecl
|
::= |
"declare"
FunctionOptions
"function"
QName
"("
ParamList
?
")"
("as"
SequenceType
)?
(
|
|
|
FunctionOptions
| ::= |
(
PrivateOption
|
DeterministicOption
)*
| |
[33] |
PrivateOption
| ::= |
"private"
|
"public"
| |
|
DeterministicOption
|
::= |
"deterministic"
|
"nondeterministic"
|
|
[35] |
ParamList
| ::= |
Param
(","
Param
)*
|
|
|
Param
|
::= |
"$"
QName
TypeDeclaration
?
|
|
|
FunctionBody
| ::= |
EnclosedExpr
|
|
[38] |
EnclosedExpr
|
::= |
"{"
Expr
"}"
|
|
|
QueryBody
|
::= |
Expr
|
|
|
Expr
|
::= |
ExprSingle
(","
ExprSingle
)*
|
|
|
ExprSingle
|
::= |
FLWORExpr
|
|
|
FLWORExpr
|
::= |
InitialClause
IntermediateClause
*
ReturnClause
|
|
[43] |
InitialClause
|
::= |
| |
[44] |
IntermediateClause
| ::= |
InitialClause
|
WhereClause
|
|
|
ForClause
|
::= |
"for"
| |
|
ForBinding
| ::= |
"$"
VarName
TypeDeclaration
?
AllowingEmpty
?
PositionalVar
?
"in"
ExprSingle
|
|
|
AllowingEmpty
| ::= |
"allowing"
"empty"
| |
|
PositionalVar
|
::= |
"at"
"$"
VarName
|
|
|
LetClause
|
::= |
"let"
LetBinding
(","
LetBinding
)*
| |
[50] |
LetBinding
|
::= |
|
|
[51] |
WindowClause
| ::= |
"for"
(
TumblingWindowClause
|
SlidingWindowClause
)
| |
[52] |
TumblingWindowClause
| ::= |
"tumbling"
"window"
"$"
VarName
TypeDeclaration
?
|
|
|
SlidingWindowClause
| ::= |
"sliding"
"window"
"$"
VarName
TypeDeclaration
?
"in"
ExprSingle
WindowStartCondition
WindowEndCondition
| |
|
WindowStartCondition
| ::= |
"start"
WindowVars
"when"
ExprSingle
| |
[55] |
WindowEndCondition
| ::= |
"only"?
"end"
WindowVars
"when"
ExprSingle
| |
[56] |
WindowVars
| ::= |
("$"
CurrentItem
)?
PositionalVar
?
("previous"
"$"
PreviousItem
)?
("next"
"$"
NextItem
)?
| |
[57] |
CurrentItem
| ::= |
QName
| |
[58] |
PreviousItem
| ::= |
QName
| |
[59] |
NextItem
| ::= |
QName
| |
[60] |
CountClause
| ::= |
"count"
"$"
VarName
| |
[61] |
WhereClause
|
::= |
"where"
ExprSingle
|
|
|
GroupByClause
| ::= |
"group"
"by"
GroupingSpecList
| |
[63] |
GroupingSpecList
| ::= |
GroupingSpec
(","
GroupingSpec
)*
| |
[64] |
GroupingSpec
| ::= |
"$"
VarName
("collation"
URILiteral
)?
| |
|
OrderByClause
|
::= |
(("order"
"by")
|
("stable"
"order"
"by"))
OrderSpecList
|
|
|
OrderSpecList
|
::= |
OrderSpec
(","
OrderSpec
)*
|
|
|
OrderSpec
|
::= |
ExprSingle
OrderModifier
|
|
|
OrderModifier
|
::= |
("ascending"
|
"descending")?
("empty"
("greatest"
|
"least"))?
("collation"
URILiteral
)?
|
|
|
ReturnClause
| ::= |
"return"
ExprSingle
| |
|
QuantifiedExpr
|
::= |
("some"
|
"every")
"$"
VarName
TypeDeclaration
?
"in"
ExprSingle
(","
"$"
VarName
TypeDeclaration
?
"in"
ExprSingle
)*
"satisfies"
ExprSingle
|
|
|
SwitchExpr
|
::= |
"switch"
"("
Expr
")"
SwitchCaseClause
+
"default"
"return"
ExprSingle
|
|
[72] |
SwitchCaseClause
| ::= |
("case"
SwitchCaseOperand
)+
"return"
ExprSingle
| |
[73] |
SwitchCaseOperand
| ::= |
ExprSingle
| |
[74] |
TypeswitchExpr
|
::= |
"typeswitch"
"("
Expr
")"
CaseClause
+
"default"
("$"
VarName
)?
"return"
ExprSingle
|
|
|
CaseClause
|
::= |
"case"
("$"
VarName
"as")?
SequenceType
"return"
ExprSingle
|
|
|
IfExpr
|
::= |
"if"
"("
Expr
")"
"then"
ExprSingle
"else"
ExprSingle
|
|
|
TryCatchExpr
|
::= |
TryClause
CatchClause
+
| |
[78] |
TryClause
|
::= |
"try"
"{"
TryTargetExpr
"}"
|
|
[79] |
TryTargetExpr
| ::= |
Expr
| |
[80] |
CatchClause
| ::= |
"catch"
CatchErrorList
CatchVars
?
"{"
Expr
"}"
| |
[81] |
CatchErrorList
| ::= |
NameTest
("|"
NameTest
)*
| |
[82] |
CatchVars
| ::= |
"("
CatchErrorCode
(","
CatchErrorDesc
(","
CatchErrorVal
)?)?
")"
| |
[83] |
CatchErrorCode
| ::= |
"$"
VarName
| |
[84] |
CatchErrorDesc
| ::= |
"$"
VarName
| |
[85] |
CatchErrorVal
| ::= |
"$"
VarName
| |
[86] |
OrExpr
| ::= |
AndExpr
(
"or"
AndExpr
)*
|
|
|
AndExpr
|
::= |
ComparisonExpr
(
"and"
ComparisonExpr
)*
|
|
|
ComparisonExpr
|
::= |
RangeExpr
(
(
ValueComp
|
|
|
RangeExpr
|
::= |
AdditiveExpr
(
"to"
AdditiveExpr
)?
|
|
|
AdditiveExpr
|
::= |
MultiplicativeExpr
(
("+"
|
"-")
MultiplicativeExpr
)*
|
|
|
MultiplicativeExpr
|
::= |
UnionExpr
(
("*"
|
"div"
|
"idiv"
|
"mod")
UnionExpr
)*
|
|
|
UnionExpr
|
::= |
IntersectExceptExpr
(
("union"
|
"|")
IntersectExceptExpr
)*
|
|
|
IntersectExceptExpr
|
::= |
InstanceofExpr
(
("intersect"
|
"except")
InstanceofExpr
)*
|
|
|
InstanceofExpr
|
::= |
TreatExpr
(
"instance"
"of"
SequenceType
)?
|
|
|
TreatExpr
|
::= |
CastableExpr
(
"treat"
"as"
SequenceType
)?
|
|
|
CastableExpr
|
::= |
CastExpr
(
"castable"
"as"
SingleType
)?
|
|
|
CastExpr
|
::= |
UnaryExpr
(
"cast"
"as"
SingleType
)?
|
|
|
UnaryExpr
|
::= |
("-"
|
"+")*
ValueExpr
|
|
|
ValueExpr
|
::= |
ValidateExpr
|
PathExpr
|
ExtensionExpr
|
|
|
GeneralComp
|
::= |
"="
|
"!="
|
"<"
|
"<="
|
">"
|
">="
|
|
|
ValueComp
|
::= |
"eq"
|
"ne"
|
"lt"
|
"le"
|
"gt"
|
"ge"
|
|
|
NodeComp
|
::= |
"is"
|
"<<"
|
">>"
|
|
|
ValidateExpr
|
::= |
"validate"
(
ValidationMode
|
|
|
ValidationMode
|
::= |
"lax"
|
"strict"
|
|
|
ExtensionExpr
|
::= |
Pragma
+
"{"
Expr
?
"}"
|
|
|
Pragma
|
::= |
"(#"
S
?
QName
(
S
PragmaContents
)?
"#)"
|
/* ws: explicit XQ */ |
|
PragmaContents
|
::= |
(
Char
*
-
(Char*
'#)'
Char*))
|
|
|
PathExpr
|
::= |
("/"
RelativePathExpr
?)
|
/*
|
|
RelativePathExpr
|
::= |
StepExpr
(("/"
|
"//")
StepExpr
)*
|
|
|
StepExpr
|
::= |
FilterExpr
|
AxisStep
|
|
|
AxisStep
|
::= |
(
ReverseStep
|
ForwardStep
)
PredicateList
|
|
|
ForwardStep
|
::= |
(
ForwardAxis
NodeTest
)
|
AbbrevForwardStep
|
|
|
ForwardAxis
|
::= |
("child"
"::")
|
|
|
AbbrevForwardStep
|
::= |
"@"?
NodeTest
|
|
|
ReverseStep
|
::= |
(
ReverseAxis
NodeTest
)
|
AbbrevReverseStep
|
|
|
ReverseAxis
|
::= |
("parent"
"::")
|
|
|
AbbrevReverseStep
|
::= |
".."
|
|
|
NodeTest
|
::= |
KindTest
|
NameTest
|
|
|
NameTest
|
::= |
QName
|
Wildcard
|
|
|
Wildcard
|
::= |
"*"
|
/* ws: explicit XQ */ |
|
FilterExpr
|
::= |
PrimaryExpr
|
|
|
PredicateList
|
::= |
Predicate
*
|
|
|
Predicate
|
::= |
"["
Expr
"]"
|
|
|
PrimaryExpr
|
::= |
Literal
|
|
|
Literal
|
::= |
NumericLiteral
|
StringLiteral
|
|
|
NumericLiteral
|
::= |
IntegerLiteral
|
DecimalLiteral
|
DoubleLiteral
|
|
|
VarRef
|
::= |
"$"
VarName
|
|
|
VarName
|
::= |
QName
|
|
|
ParenthesizedExpr
|
::= |
"("
Expr
?
")"
|
|
|
ContextItemExpr
|
::= |
"."
|
|
|
OrderedExpr
|
::= |
"ordered"
"{"
Expr
"}"
|
|
|
UnorderedExpr
|
::= |
"unordered"
"{"
Expr
"}"
|
|
|
FunctionCall
|
::= |
QName
"("
(
ExprSingle
(","
ExprSingle
)*)?
")"
|
/*
|
/* gn: parens XQ */ | ||||
|
Constructor
|
::= |
DirectConstructor
|
|
|
DirectConstructor
|
::= |
DirElemConstructor
|
|
|
DirElemConstructor
|
::= |
"<"
QName
DirAttributeList
("/>"
|
(">"
DirElemContent
*
"</"
QName
S
?
">"))
|
/* ws: explicit XQ */ |
|
DirAttributeList
|
::= |
(
S
(
QName
S
?
"="
S
?
DirAttributeValue
)?)*
|
/* ws: explicit XQ */ |
|
DirAttributeValue
|
::= |
('"'
(
EscapeQuot
|
QuotAttrValueContent
)*
'"')
|
/* ws: explicit XQ */ |
|
QuotAttrValueContent
|
::= |
QuotAttrContentChar
|
|
|
AposAttrValueContent
|
::= |
AposAttrContentChar
|
|
|
DirElemContent
|
::= |
DirectConstructor
|
|
|
CommonContent
|
::= |
PredefinedEntityRef
|
CharRef
|
"{{"
|
"}}"
|
EnclosedExpr
|
|
|
DirCommentConstructor
|
::= |
"<!--"
DirCommentContents
"-->"
|
/* ws: explicit XQ */ |
|
DirCommentContents
|
::= |
((
Char
-
'-')
|
('-'
(
Char
-
'-')))*
|
/* ws: explicit XQ */ |
|
DirPIConstructor
|
::= |
"<?"
PITarget
(
S
DirPIContents
)?
"?>"
|
/* ws: explicit XQ */ |
|
DirPIContents
|
::= |
(
Char
*
-
(Char*
'?>'
Char*))
|
/* ws: explicit XQ */ |
|
CDataSection
|
::= |
"<![CDATA["
CDataSectionContents
"]]>"
|
/* ws: explicit XQ */ |
|
CDataSectionContents
|
::= |
(
Char
*
-
(Char*
']]>'
Char*))
|
/* ws: explicit XQ */ |
|
ComputedConstructor
|
::= |
CompDocConstructor
|
|
|
CompDocConstructor
|
::= |
"document"
"{"
Expr
"}"
|
|
|
CompElemConstructor
|
::= |
"element"
(
QName
|
("{"
Expr
"}"))
"{"
ContentExpr
?
"}"
|
|
|
ContentExpr
|
::= |
Expr
|
|
|
CompAttrConstructor
|
::= |
"attribute"
(
QName
|
("{"
Expr
"}"))
"{"
Expr
?
"}"
|
|
|
CompNamespaceConstructor
|
::= |
"namespace"
(
Prefix
|
("{"
PrefixExpr
"}"))
"{"
URIExpr
?
"}"
| |
[155] |
Prefix
|
::= |
| |
[156] |
PrefixExpr
| ::= |
Expr
|
|
|
URIExpr
|
::= |
Expr
|
|
[158] |
CompTextConstructor
|
::= |
|
|
|
CompCommentConstructor
|
::= |
"comment"
"{"
Expr
"}"
|
|
[160] |
CompPIConstructor
|
::= |
"processing-instruction"
(
NCName
|
("{"
Expr
"}"))
"{"
Expr
?
"}"
|
|
|
FunctionItemExpr
| ::= |
|
|
[162] |
LiteralFunctionItem
|
::= |
|
|
|
InlineFunction
|
::= |
"function"
"("
ParamList
?
")"
("as"
SequenceType
)?
EnclosedExpr
| |
[164] |
DynamicFunctionInvocation
|
::= |
|
|
[165] |
SingleType
| ::= |
AtomicType
"?"?
|
|
|
TypeDeclaration
|
::= |
"as"
SequenceType
|
|
[167] |
SequenceType
|
::= |
("empty-sequence"
"("
")")
|
|
|
OccurrenceIndicator
|
::= |
"?"
|
"*"
|
"+"
|
/*
|
|
ItemType
|
::= |
KindTest
|
("item"
"("
")")
|
FunctionTest
|
AtomicType
|
ParenthesizedItemType
|
|
|
AtomicType
|
::= |
QName
|
|
|
KindTest
|
::= |
DocumentTest
|
|
|
AnyKindTest
|
::= |
"node"
"("
")"
|
|
|
DocumentTest
|
::= |
"document-node"
"("
(
ElementTest
|
SchemaElementTest
)?
")"
|
|
|
TextTest
|
::= |
"text"
"("
")"
|
|
|
CommentTest
|
::= |
"comment"
"("
")"
|
|
|
NamespaceNodeTest
| ::= |
"namespace-node"
"("
")"
| |
|
PITest
|
::= |
"processing-instruction"
"("
(
NCName
|
StringLiteral
)?
")"
|
|
|
AttributeTest
|
::= |
"attribute"
"("
(
AttribNameOrWildcard
(","
TypeName
)?)?
")"
|
|
|
AttribNameOrWildcard
|
::= |
AttributeName
|
"*"
|
|
|
SchemaAttributeTest
|
::= |
"schema-attribute"
"("
AttributeDeclaration
")"
|
|
|
AttributeDeclaration
|
::= |
AttributeName
|
|
|
ElementTest
|
::= |
"element"
"("
(
ElementNameOrWildcard
(","
TypeName
"?"?)?)?
")"
|
|
|
ElementNameOrWildcard
|
::= |
ElementName
|
"*"
|
|
|
SchemaElementTest
|
::= |
"schema-element"
"("
ElementDeclaration
")"
|
|
|
ElementDeclaration
|
::= |
ElementName
|
|
|
AttributeName
|
::= |
QName
|
|
|
ElementName
|
::= |
QName
|
|
[188] |
TypeName
|
::= |
QName
|
|
|
FunctionTest
|
::= |
AnyFunctionTest
|
|
[190] |
AnyFunctionTest
|
::= |
"function"
"("
"*"
")"
|
|
[191] |
TypedFunctionTest
| ::= |
"function"
"("
(
SequenceType
(","
SequenceType
)*)?
")"
"as"
SequenceType
|
|
|
ParenthesizedItemType
|
::= |
"("
ItemType
")"
| |
[193] |
URILiteral
|
::= |
StringLiteral
|
The following definitions will be helpful in defining precisely this exposition.
[ Definition : Each rule in the grammar defines one symbol , using the following format:
symbol ::= expression
]
[ Definition : A terminal is a symbol or string or pattern that can appear in the right-hand side of a rule, but never appears on the left hand side in the main grammar, although it may appear on the left-hand side of a rule in the grammar for terminals.] The following constructs are used to match strings of one or more characters in a terminal:
matches any Char with a value in the range(s) indicated (inclusive).
matches any Char with a value among the characters enumerated. Enumerations and ranges can be mixed in one set of brackets.
matches any Char with a value not among the characters given. Enumerations and ranges of forbidden values can be mixed in one set of brackets.
matches the sequence of characters that appear inside the double quotes.
matches the sequence of characters that appear inside the single quotes.
matches any string matched by the production defined in the external specification as per the provided reference.
Patterns (including the above constructs) can be combined with grammatical operators to form more complex patterns, matching more complex sets of character strings. In the examples that follow, A and B represent (sub-)patterns.
A
is
treated
as
a
unit
and
may
be
combined
as
described
in
this
list.
matches
A
or
nothing;
optional
A
.
matches
A
followed
by
B
.
This
operator
has
higher
precedence
than
alternation;
thus
A
B
|
C
D
is
identical
to
(A
B)
|
(C
D)
.
matches
A
or
B
but
not
both.
matches
any
string
that
matches
A
but
does
not
match
B
.
matches
one
or
more
occurrences
of
A
.
Concatenation
has
higher
precedence
than
alternation;
thus
A+
|
B+
is
identical
to
(A+)
|
(B+)
.
matches
zero
or
more
occurrences
of
A
.
Concatenation
has
higher
precedence
than
alternation;
thus
A*
|
B*
is
identical
to
(A*)
|
(B*)
This section contains constraints on the EBNF productions, which are required to parse legal sentences. The notes below are referenced from the right side of the production, with the notation: /* xgc: <id> */ .
Constraint: leading-lone-slash
A
single
slash
may
appear
either
as
a
complete
path
expression
or
as
the
first
part
of
a
path
expression
in
which
it
is
followed
by
a
RelativePathExpr
,
which
can
take
.
In
some
cases,
the
form
of
next
token
after
the
slash
is
insufficient
to
allow
a
parser
to
distinguish
these
two
possibilities:
the
*
token
and
keywords
like
union
could
be
either
an
operator
or
a
NameTest
("*"
,
and
the
<
token
could
be
either
an
operator
or
the
start
of
a
QName).
In
contexts
where
operators
like
"*",
"union",
etc.,
can
occur,
parsers
may
have
difficulty
distinguishing
operators
from
NameTests.
DirectConstructor
.
For
example,
without
lookahead
the
first
part
of
the
expression
"/
/
*
is
easily
taken
to
be
a
complete
expression,
5",
for
example
5
"/
*",
/
*
,
which
has
a
very
different
interpretation
(the
child
nodes
of
"/").
/
).
To
Therefore
to
reduce
the
need
for
lookahead,
therefore,
if
the
token
immediately
following
a
slash
is
"*"
or
can
form
the
start
of
a
keyword,
RelativePathExpr
,
then
the
slash
must
be
the
beginning,
but
not
the
entirety,
beginning
of
a
PathExpr
(and
the
following
token
must
be
a
NameTest
,
not
an
operator).
the
entirety
of
it.
A
single
slash
may
be
used
as
the
left-hand
argument
of
an
operator
by
parenthesizing
it:
(/)
*
5
.
The
expression
5
*
/
,
on
the
other
hand,
is
legal
without
parentheses.
An
implementation's
choice
to
support
the
[XML
1.0]
and
[XML
Names]
,
or
[XML
1.1]
and
[XML
Names
1.1]
lexical
specification
determines
the
external
document
from
which
to
obtain
the
definition
for
this
production.
The
EBNF
only
has
references
to
the
1.0
versions.
In
some
cases,
the
XML
1.0
and
XML
1.1
definitions
may
be
exactly
the
same.
Also
please
note
that
these
external
productions
follow
the
whitespace
rules
of
their
respective
specifications,
and
not
the
rules
of
this
specification,
in
particular
A.2.4.1
Default
Whitespace
Handling
.
Thus
prefix
:
localname
is
not
a
valid
QName
for
purposes
of
this
specification,
just
as
it
is
not
permitted
in
a
XML
document.
Also,
comments
are
not
permissible
on
either
side
of
the
colon.
Also
extra-grammatical
constraints
such
as
well-formedness
constraints
must
be
taken
into
account.
Constraint: reserved-function-names
Unprefixed
function
names
spelled
the
same
way
as
language
keywords
could
make
the
language
harder
to
recognize.
For
instance,
if(foo)
could
be
taken
either
as
a
FunctionCall
or
as
the
beginning
of
an
IfExpr
.
Therefore
it
is
not
legal
syntax
for
a
user
to
invoke
functions
with
unprefixed
names
which
match
any
of
the
names
in
A.3
Reserved
Function
Names
.
A function named "if" can be called by binding its namespace to a prefix and using the prefixed form: "library:if(foo)" instead of "if(foo)".
Constraint: occurrence-indicators
As
written,
the
grammar
in
A
XQuery
1.1
Grammar
is
ambiguous
for
some
forms
using
the
'+'
and
'*'
Kleene
operators.
The
ambiguity
is
resolved
as
follows:
these
operators
are
tightly
bound
to
the
SequenceType
expression,
and
have
higher
precedence
than
other
uses
of
these
symbols.
Any
occurrence
of
'+'
and
'*',
as
well
as
'?',
following
a
sequence
type
is
assumed
to
be
an
occurrence
indicator.
That
is,
a
"+",
"*",
or
"?"
immediately
following
an
ItemType
must
be
an
OccurrenceIndicator
.
Thus,
4
treat
as
item()
+
-
5
must
be
interpreted
as
(4
treat
as
item()+)
-
5
,
taking
the
'+'
as
an
OccurrenceIndicator
and
the
'-'
as
a
subtraction
operator.
To
force
the
interpretation
of
"+"
as
an
addition
operator
(and
the
corresponding
interpretation
of
the
"-"
as
a
unary
minus),
parentheses
may
be
used:
the
form
(4
treat
as
item())
+
-5
surrounds
the
SequenceType
expression
with
parentheses
and
leads
to
the
desired
interpretation.
This rule has as a consequence that certain forms which would otherwise be legal and unambiguous are not recognized: in "4 treat as item() + 5", the "+" is taken as an OccurrenceIndicator , and not as an operator, which means this is not a legal expression.
This section contains general notes on the EBNF productions, which may be helpful in understanding how to interpret and implement the EBNF. These notes are not normative. The notes below are referenced from the right side of the production, with the notation: /* gn: <id> */ .
Note:
Look-ahead
is
required
to
distinguish
FunctionCall
from
a
QName
or
keyword
followed
by
a
Pragma
or
Comment
.
For
example:
address
(:
this
may
be
empty
:)
may
be
mistaken
for
a
call
to
a
function
named
"address"
unless
this
lookahead
is
employed.
Another
example
is
for
(:
whom
the
bell
:)
$tolls
in
3
return
$tolls
,
where
the
keyword
"for"
must
not
be
mistaken
for
a
function
name.
Comments
are
allowed
everywhere
that
ignorable
whitespace
is
allowed,
and
the
Comment
symbol
does
not
explicity
explicitly
appear
on
the
right-hand
side
of
the
grammar
(except
in
its
own
production).
See
A.2.4.1
Default
Whitespace
Handling
.
Note
that
comments
are
not
allowed
in
direct
constructor
content,
though
they
are
allowed
in
nested
EnclosedExprs
.
A comment can contain nested comments, as long as all "(:" and ":)" patterns are balanced, no matter where they occur within the outer comment.
Note:
Lexical analysis may typically handle nested comments by incrementing a counter for each "(:" pattern, and decrementing the counter for each ":)" pattern. The comment does not terminate until the counter is back to zero.
Some illustrative examples:
(:
commenting
out
a
(:
comment
:)
may
be
confusing,
but
often
helpful
:)
is
a
legal
Comment,
since
balanced
nesting
of
comments
is
allowed.
"this
is
just
a
string
:)"
is
a
legal
expression.
However,
(:
"this
is
just
a
string
:)"
:)
will
cause
a
syntax
error.
Likewise,
"this
is
another
string
(:"
is
a
legal
expression,
but
(:
"this
is
another
string
(:"
:)
will
cause
a
syntax
error.
It
is
a
limitation
of
nested
comments
that
literal
content
can
cause
unbalanced
nesting
of
comments.
for
(:
set
up
loop
:)
$i
in
$x
return
$i
is
syntactically
legal,
ignoring
the
comment.
5
instance
(:
strange
place
for
a
comment
:)
of
xs:integer
is
also
syntactically
legal.
<eg
(:
an
example:)>{$i//title}</eg>
is
not
syntactically
legal.
<eg>
(:
an
example:)
</eg>
is
syntactically
legal,
but
the
characters
that
look
like
a
comment
are
in
fact
literal
element
content.
The terminal symbols assumed by the grammar above are described in this section.
Quoted strings appearing in production rules are terminal symbols.
Other terminal symbols are defined in A.2.1 Terminal Symbols .
It is implementation-defined whether the lexical rules of [XML 1.0] and [XML Names] are followed, or alternatively, the lexical rules of [XML 1.1] and [XML Names 1.1] are followed. Implementations that support the full [XML 1.1] character set SHOULD , for purposes of interoperability, provide a mode that follows only the [XML 1.0] and [XML Names] lexical rules.
When tokenizing, the longest possible match that is valid in the current context is used.
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 .
|
IntegerLiteral
|
::= |
Digits
|
|
|
DecimalLiteral
|
::= |
("."
Digits
)
|
(
Digits
"."
[0-9]*)
|
/* ws: explicit XQ */ |
|
DoubleLiteral
|
::= |
(("."
Digits
)
|
(
Digits
("."
[0-9]*)?))
[eE]
[+-]?
Digits
|
/* ws: explicit XQ */ |
|
StringLiteral
|
::= |
('"'
(
PredefinedEntityRef
|
CharRef
|
EscapeQuot
|
[^"&])*
'"')
|
("'"
(
PredefinedEntityRef
|
CharRef
|
EscapeApos
|
[^'&])*
"'")
|
/* ws: explicit XQ */ |
|
PredefinedEntityRef
|
::= |
"&"
("lt"
|
"gt"
|
"amp"
|
"quot"
|
"apos")
";"
|
/* ws: explicit XQ */ |
|
EscapeQuot
|
::= |
'""'
|
|
|
EscapeApos
|
::= |
"''"
|
|
|
ElementContentChar
|
::= |
Char
-
[{}<&]
|
|
|
QuotAttrContentChar
|
::= |
Char
-
["{}<&]
|
|
|
AposAttrContentChar
|
::= |
Char
-
['{}<&]
|
|
|
Comment
|
::= |
"(:"
(
CommentContents
|
Comment
)*
":)"
|
/* ws: explicit XQ */ |
/* gn: comments XQ */ | ||||
|
PITarget
|
::= |
[http://www.w3.org/TR/REC-xml#NT-PITarget]
XML
|
/*
|
|
CharRef
|
::= |
[http://www.w3.org/TR/REC-xml#NT-CharRef]
XML
|
/*
|
|
QName
|
::= |
[http://www.w3.org/TR/REC-xml-names/#NT-QName]
Names
|
/*
|
|
NCName
|
::= |
[http://www.w3.org/TR/REC-xml-names/#NT-NCName]
Names
|
/*
|
|
S
|
::= |
[http://www.w3.org/TR/REC-xml#NT-S]
XML
|
/*
|
|
Char
|
::= |
[http://www.w3.org/TR/REC-xml#NT-Char]
XML
|
/*
|
The following symbols are used only in the definition of terminal symbols; they are not terminal symbols in the grammar of A.1 EBNF .
|
Digits
|
::= |
[0-9]+
|
|
CommentContents
|
::= |
(
Char
+
-
(Char*
('(:'
|
':)')
Char*))
|
XQuery
1.0
1.1
expressions
consist
of
terminal
symbols
and
symbol
separators
.
Terminal symbols that are not used exclusively in /* ws: explicit */ productions are of two kinds: delimiting and non-delimiting.
[ Definition : The delimiting terminal symbols are: S , "-", (comma), (semi-colon), (colon), "::", ":=", "!=", "?", "?>", "/", "//", "/>", (dot), "..", StringLiteral , "(", "(#", ")", "[", "]", "]]>", "{", "}", "@", "$", "*", "#", "#)", "+", "<", "<!--", "<![CDATA[", "<?", "</", "<<", "<=", "=", ">", "-->", ">=", ">>", "|"]
[
Definition
:
The
non-delimiting
terminal
symbols
are:
IntegerLiteral
,
NCName
,
QName
,
DecimalLiteral
,
DoubleLiteral
,
"allowing",
"ancestor",
"ancestor-or-self",
"and",
"as",
"ascending",
"at",
"attribute",
"base-uri",
"boundary-space",
"by",
"case",
"cast",
"castable",
"catch",
"child",
"collation",
"comment",
"construction",
"context",
"copy-namespaces",
"count",
"decimal-format",
"decimal-separator",
"declare",
"default",
"descendant",
"descendant-or-self",
"descending",
"deterministic",
"digit",
"div",
"document",
"document-node",
"element",
"else",
"empty",
"empty-sequence",
"encoding",
"end",
"eq",
"every",
"except",
"external",
"following",
"following-sibling",
"for",
"function",
"ge",
"greatest",
"group",
"grouping-separator",
"gt",
"idiv",
"if",
"import",
"in",
"infinity",
"inherit",
"instance",
"intersect",
"is",
"item",
"lax",
"le",
"least",
"let",
"lt",
"minus-sign",
"mod",
"module",
"namespace",
"namespace-node",
"NaN",
"ne",
"next",
"node",
"no-inherit",
"nondeterministic",
"no-preserve",
"of",
"only",
"option",
"or",
"order",
"ordered",
"ordering",
"parent",
"pattern-separator",
"percent",
"per-mille",
"preceding",
"preceding-sibling",
"preserve",
"previous",
"private",
"processing-instruction",
"public",
"return",
"satisfies",
"schema",
"schema-attribute",
"schema-element",
"self",
"sliding",
"some",
"stable",
"start",
"strict",
"strip",
"switch",
"text",
"then",
"to",
"treat",
"try",
"tumbling",
"typeswitch",
"union",
"unordered",
"validate",
"variable",
"version",
"when",
"where",
"xquery"]
"window",
"xquery",
"zero-digit"]
[
Definition
:
Whitespace
and
Comments
function
as
symbol
separators
.
For
the
most
part,
they
are
not
mentioned
in
the
grammar,
and
may
occur
between
any
two
terminal
symbols
mentioned
in
the
grammar,
except
where
that
is
forbidden
by
the
/*
ws:
explicit
*/
annotation
in
the
EBNF,
or
by
the
/*
xgs:
xgc:
xml-version
*/
annotation.
]
annotation.]
It is customary to separate consecutive terminal symbols by whitespace and Comments , but this is required only when otherwise two non-delimiting symbols would be adjacent to each other. There are two exceptions to this, that of "." and "-", which do require a symbol separator if they follow a QName or NCName. Also, "." requires a separator if it precedes or follows a numeric literal.
The XQuery 1.1 processor must behave as if it normalized all line breaks on input, before parsing. The normalization should be done according to the choice to support either [XML 1.0] or [XML 1.1] lexical processing.
For [XML 1.0] processing, all of the following must be translated to a single #xA character:
the two-character sequence #xD #xA
any #xD character that is not immediately followed by #xA.
For [XML 1.1] processing, all of the following must be translated to a single #xA character:
the two-character sequence #xD #xA
the two-character sequence #xD #x85
the single character #x85
the single character #x2028
any #xD character that is not immediately followed by #xA or #x85.
The characters #x85 and #x2028 cannot be reliably recognized and translated until the VersionDecl declaration (if present) has been read.
[ Definition : A whitespace character is any of the characters defined by [http://www.w3.org/TR/REC-xml#NT-S] .]
[ Definition : Ignorable whitespace consists of any whitespace characters that may occur between terminals , unless these characters occur in the context of a production marked with a ws:explicit annotation, in which case they can occur only where explicitly specified (see A.2.4.2 Explicit Whitespace Handling ).] Ignorable whitespace characters are not significant to the semantics of an expression. Whitespace is allowed before the first terminal and after the last terminal of a module. Whitespace is allowed between any two terminals . Comments may also act as "whitespace" to prevent two adjacent terminals from being recognized as one. Some illustrative examples are as follows:
foo-
foo
results
in
a
syntax
error.
"foo-"
would
be
recognized
as
a
QName.
foo
-foo
is
syntactically
equivalent
to
foo
-
foo
,
two
QNames
separated
by
a
subtraction
operator.
foo(:
This
is
a
comment
:)-
foo
is
syntactically
equivalent
to
foo
-
foo
.
This
is
because
the
comment
prevents
the
two
adjacent
terminals
from
being
recognized
as
one.
foo-foo
is
syntactically
equivalent
to
single
QName.
This
is
because
"-"
is
a
valid
character
in
a
QName.
When
used
as
an
operator
after
the
characters
of
a
name,
the
"-"
must
be
separated
from
the
name,
e.g.
by
using
whitespace
or
parentheses.
10div
3
results
in
a
syntax
error.
10
div3
also
results
in
a
syntax
error.
10div3
also
results
in
a
syntax
error.
Explicit whitespace notation is specified with the EBNF productions, when it is different from the default rules, using the notation shown below. This notation is not inherited. In other words, if an EBNF rule is marked as /* ws: explicit */, the notation does not automatically apply to all the 'child' EBNF productions of that rule.
/*
ws:
explicit
*/
means
that
the
EBNF
notation
explicitly
notates,
with
S
or
otherwise,
where
whitespace
characters
are
allowed.
In
productions
with
the
/*
ws:
explicit
*/
annotation,
A.2.4.1
Default
Whitespace
Handling
does
not
apply.
Comments
are
also
not
allowed
in
these
productions.
For example, whitespace is not freely allowed by the direct constructor productions, but is specified explicitly in the grammar, in order to be more consistent with XML.
The following names are not allowed as function names in an unprefixed form because expression syntax takes precedence.
attribute
comment
document-node
element
empty-sequence
if
item
node
processing-instruction
schema-attribute
schema-element
text
function
typeswitch
The
grammar
in
A.1
EBNF
normatively
defines
built-in
precedence
among
the
operators
of
XQuery.
These
operators
are
summarized
here
to
make
clear
the
order
of
their
precedence
from
lowest
to
highest.
Operators
that
have
a
lower
precedence
number
cannot
be
contained
by
operators
with
a
higher
precedence
number.
The
associativity
column
indicates
the
order
in
which
operators
of
equal
precedence
in
an
expression
are
applied.
# | Operator | Associativity |
---|---|---|
1 | , (comma) |
|
|
|
|
|
or |
|
|
and |
|
|
eq,
ne,
lt,
le,
gt,
ge
,
=,
!=,
<,
<=,
>,
>=
,
|
|
|
to |
|
|
+, - (binary) | left-to-right |
|
*, div, idiv, mod | left-to-right |
|
union, | |
|
|
intersect, except | left-to-right |
|
instance of |
|
|
treat as |
|
|
castable as |
|
|
cast as |
|
|
|
right-to-left |
|
/, // | left-to-right |
|
[
]
|
left-to-right |
In
the
"Associativity"
column,
"either"
indicates
that
all
the
operators
at
that
level
have
the
associative
property
(i.e.,
(A
op
B)
op
C
is
equivalent
to
A
op
(B
op
C)
),
so
their
associativity
is
inconsequential.
"NA"
(not
applicable)
indicates
that
the
EBNF
does
not
allow
an
expression
that
directly
contains
multiple
operators
from
that
precedence
level,
so
the
question
of
their
associativity
does
not
arise.
Note:
Parentheses can be used to override the operator precedence in the usual way. Square brackets in an expression such as A[B] serve two roles: they act as an operator causing B to be evaluated once for each item in the value of A, and they act as parentheses enclosing the expression B.
Curly braces in an expression such as validate{E} or ordered{E} perform a similar bracketing role to the parentheses in a function call, but with the difference in most cases that E is an Expr rather than ExprSingle, meaning that it can use the comma operator.
[
Definition
:
Under
certain
circumstances,
an
atomic
value
can
be
promoted
from
one
type
to
another.
Type
promotion
is
used
in
evaluating
function
calls
(see
3.1.5
Function
Calls
)
,
,
order
by
clauses
(see
3.8.3
3.8.8
Order
By
and
Return
Clauses
Clause
),
and
operators
that
accept
numeric
or
string
operands
(see
B.2
Operator
Mapping
).]
The
following
type
promotions
are
permitted:
Numeric type promotion:
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.
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.
This
kind
of
promotion
may
cause
loss
of
precision.
URI
type
promotion:
A
value
of
type
xs:anyURI
(or
any
type
derived
by
restriction
from
xs:anyURI
)
can
be
promoted
to
the
type
xs:string
.
The
result
of
this
promotion
is
created
by
casting
the
original
value
to
the
type
xs:string
.
Note:
Since
xs:anyURI
values
can
be
promoted
to
xs:string
,
functions
and
operators
that
compare
strings
using
the
default
collation
also
compare
xs:anyURI
values
using
the
default
collation
.
This
ensures
that
orderings
that
include
strings,
xs:anyURI
values,
or
any
combination
of
the
two
types
are
consistent
and
well-defined.
Note that type 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
type
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
operator
mapping
tables
in
this
section
list
the
combinations
of
types
for
which
the
various
operators
of
XQuery
1.1
are
defined.
[
Definition
:
For
each
operator
and
valid
combination
of
operand
types,
the
operator
mapping
tables
specify
a
result
type
and
an
operator
function
that
implements
the
semantics
of
the
operator
for
the
given
types.]
The
definitions
of
the
operator
functions
are
given
in
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
.
The
result
of
an
operator
may
be
the
raising
of
an
error
by
its
operator
function,
as
defined
in
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
.
In
some
cases,
the
operator
function
does
not
implement
the
full
semantics
of
a
given
operator.
For
the
definition
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.
The
and
and
or
operators
are
defined
directly
in
the
main
body
of
this
document,
and
do
not
occur
in
the
operator
mapping
tables.
If
an
operator
in
the
operator
mapping
tables
expects
an
operand
of
type
ET
,
that
operator
can
be
applied
to
an
operand
of
type
AT
if
type
AT
can
be
converted
to
type
ET
by
a
combination
of
type
promotion
and
subtype
substitution
.
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
.
[
Definition
:
When
referring
to
a
type,
the
term
numeric
denotes
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
may
be
validly
applied
to
an
operand
of
type
AT
if
type
AT
can
be
converted
to
any
of
the
four
numeric
types
by
a
combination
of
type
promotion
and
subtype
substitution
.
If
the
result
type
of
an
operator
is
listed
as
numeric,
it
means
"the
first
type
in
the
ordered
list
(xs:integer,
xs:decimal,
xs:float,
xs:double)
into
which
all
operands
can
be
converted
by
subtype
substitution
and
type
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
.
[
Definition
:
In
the
operator
mapping
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 | Type(A) | Type(B) | Function | Result type |
---|---|---|---|---|
A + B | numeric | numeric | op:numeric-add(A, B) | numeric |
A + B | xs:date | xs:yearMonthDuration | op:add-yearMonthDuration-to-date(A, B) | xs:date |
A + B | xs:yearMonthDuration | xs:date | op:add-yearMonthDuration-to-date(B, A) | xs:date |
A + B | xs:date | xs:dayTimeDuration | op:add-dayTimeDuration-to-date(A, B) | xs:date |
A + B | xs:dayTimeDuration | xs:date | op:add-dayTimeDuration-to-date(B, A) | xs:date |
A + B | xs:time | xs:dayTimeDuration | op:add-dayTimeDuration-to-time(A, B) | xs:time |
A + B | xs:dayTimeDuration | xs:time | op:add-dayTimeDuration-to-time(B, A) | xs:time |
A + B | xs:dateTime | xs:yearMonthDuration | op:add-yearMonthDuration-to-dateTime(A, B) | xs:dateTime |
A + B | xs:yearMonthDuration | xs:dateTime | op:add-yearMonthDuration-to-dateTime(B, A) | xs:dateTime |
A + B | xs:dateTime | xs:dayTimeDuration | op:add-dayTimeDuration-to-dateTime(A, B) | xs:dateTime |
A + B | xs:dayTimeDuration | xs:dateTime | op:add-dayTimeDuration-to-dateTime(B, A) | xs:dateTime |
A + B | xs:yearMonthDuration | xs:yearMonthDuration | op:add-yearMonthDurations(A, B) | xs:yearMonthDuration |
A + B | xs:dayTimeDuration | xs:dayTimeDuration | op:add-dayTimeDurations(A, B) | xs:dayTimeDuration |
A - B | numeric | numeric | op:numeric-subtract(A, B) | numeric |
A - B | xs:date | xs:date | op:subtract-dates(A, B) | xs:dayTimeDuration |
A - B | xs:date | xs:yearMonthDuration | op:subtract-yearMonthDuration-from-date(A, B) | xs:date |
A - B | xs:date | xs:dayTimeDuration | op:subtract-dayTimeDuration-from-date(A, B) | xs:date |
A - B | xs:time | xs:time | op:subtract-times(A, B) | xs:dayTimeDuration |
A - B | xs:time | xs:dayTimeDuration | op:subtract-dayTimeDuration-from-time(A, B) | xs:time |
A - B | xs:dateTime | xs:dateTime | op:subtract-dateTimes(A, B) | xs:dayTimeDuration |
A - B | xs:dateTime | xs:yearMonthDuration | op:subtract-yearMonthDuration-from-dateTime(A, B) | xs:dateTime |
A - B | xs:dateTime | xs:dayTimeDuration | op:subtract-dayTimeDuration-from-dateTime(A, B) | xs:dateTime |
A - B | xs:yearMonthDuration | xs:yearMonthDuration | op:subtract-yearMonthDurations(A, B) | xs:yearMonthDuration |
A - B | xs:dayTimeDuration | xs:dayTimeDuration | op:subtract-dayTimeDurations(A, B) | xs:dayTimeDuration |
A * B | numeric | numeric | op:numeric-multiply(A, B) | numeric |
A * B | xs:yearMonthDuration | numeric | op:multiply-yearMonthDuration(A, B) | xs:yearMonthDuration |
A * B | numeric | xs:yearMonthDuration | op:multiply-yearMonthDuration(B, A) | xs:yearMonthDuration |
A * B | xs:dayTimeDuration | numeric | op:multiply-dayTimeDuration(A, B) | xs:dayTimeDuration |
A * B | numeric | xs:dayTimeDuration | op:multiply-dayTimeDuration(B, A) | xs:dayTimeDuration |
A idiv B | numeric | numeric | op:numeric-integer-divide(A, B) | xs:integer |
A div B | numeric | numeric | op:numeric-divide(A, B) | numeric; but xs:decimal if both operands are xs:integer |
A div B | xs:yearMonthDuration | numeric | op:divide-yearMonthDuration(A, B) | xs:yearMonthDuration |
A div B | xs:dayTimeDuration | numeric | op:divide-dayTimeDuration(A, B) | xs:dayTimeDuration |
A div B | xs:yearMonthDuration | xs:yearMonthDuration | op:divide-yearMonthDuration-by-yearMonthDuration (A, B) | xs:decimal |
A div B | xs:dayTimeDuration | xs:dayTimeDuration | op:divide-dayTimeDuration-by-dayTimeDuration (A, B) | xs:decimal |
A mod B | numeric | numeric | op:numeric-mod(A, B) | numeric |
A eq B | numeric | numeric | op:numeric-equal(A, B) | xs:boolean |
A eq B | xs:boolean | xs:boolean | op:boolean-equal(A, B) | xs:boolean |
A eq B | xs:string | xs:string | op:numeric-equal(fn:compare(A, B), 0) | xs:boolean |
A eq B | xs:date | xs:date | op:date-equal(A, B) | xs:boolean |
A eq B | xs:time | xs:time | op:time-equal(A, B) | xs:boolean |
A eq B | xs:dateTime | xs:dateTime | op:dateTime-equal(A, B) | xs:boolean |
A eq B | xs:duration | xs:duration | op:duration-equal(A, B) | xs:boolean |
A eq B | Gregorian | Gregorian | op:gYear-equal(A, B) etc. | xs:boolean |
A eq B | xs:hexBinary | xs:hexBinary |
|
xs:boolean |
A eq B | xs:base64Binary | xs:base64Binary |
|
xs:boolean |
A eq B | xs:anyURI | xs:anyURI | op:numeric-equal(fn:compare(A, B), 0) | xs:boolean |
A eq B | xs:QName | xs:QName | op:QName-equal(A, B) | xs:boolean |
A eq B | xs:NOTATION | xs:NOTATION | op:NOTATION-equal(A, B) | xs:boolean |
A ne B | numeric | numeric | fn:not(op:numeric-equal(A, B)) | xs:boolean |
A ne B | xs:boolean | xs:boolean | fn:not(op:boolean-equal(A, B)) | xs:boolean |
A ne B | xs:string | xs:string | fn:not(op:numeric-equal(fn:compare(A, B), 0)) | xs:boolean |
A ne B | xs:date | xs:date | fn:not(op:date-equal(A, B)) | xs:boolean |
A ne B | xs:time | xs:time | fn:not(op:time-equal(A, B)) | xs:boolean |
A ne B | xs:dateTime | xs:dateTime | fn:not(op:dateTime-equal(A, B)) | xs:boolean |
A ne B | xs:duration | xs:duration | fn:not(op:duration-equal(A, B)) | xs:boolean |
A ne B | Gregorian | Gregorian | fn:not(op:gYear-equal(A, B)) etc. | xs:boolean |
A ne B | xs:hexBinary | xs:hexBinary |
|
xs:boolean |
A ne B | xs:base64Binary | xs:base64Binary |
|
xs:boolean |
A ne B | xs:anyURI | xs:anyURI | fn:not(op:numeric-equal(fn:compare(A, B), 0)) | xs:boolean |
A ne B | xs:QName | xs:QName | fn:not(op:QName-equal(A, B)) | xs:boolean |
A ne B | xs:NOTATION | xs:NOTATION | fn:not(op:NOTATION-equal(A, B)) | xs:boolean |
A gt B | numeric | numeric | op:numeric-greater-than(A, B) | xs:boolean |
A gt B | xs:boolean | xs:boolean | op:boolean-greater-than(A, B) | xs:boolean |
A gt B | xs:string | xs:string | op:numeric-greater-than(fn:compare(A, B), 0) | xs:boolean |
A gt B | xs:date | xs:date | op:date-greater-than(A, B) | xs:boolean |
A gt B | xs:time | xs:time | op:time-greater-than(A, B) | xs:boolean |
A gt B | xs:dateTime | xs:dateTime | op:dateTime-greater-than(A, B) | xs:boolean |
A gt B | xs:yearMonthDuration | xs:yearMonthDuration | op:yearMonthDuration-greater-than(A, B) | xs:boolean |
A gt B | xs:dayTimeDuration | xs:dayTimeDuration | op:dayTimeDuration-greater-than(A, B) | xs:boolean |
A gt B | xs:anyURI | xs:anyURI | op:numeric-greater-than(fn:compare(A, B), 0) | xs:boolean |
A lt B | numeric | numeric | op:numeric-less-than(A, B) | xs:boolean |
A lt B | xs:boolean | xs:boolean | op:boolean-less-than(A, B) | xs:boolean |
A lt B | xs:string | xs:string | op:numeric-less-than(fn:compare(A, B), 0) | xs:boolean |
A lt B | xs:date | xs:date | op:date-less-than(A, B) | xs:boolean |
A lt B | xs:time | xs:time | op:time-less-than(A, B) | xs:boolean |
A lt B | xs:dateTime | xs:dateTime | op:dateTime-less-than(A, B) | xs:boolean |
A lt B | xs:yearMonthDuration | xs:yearMonthDuration | op:yearMonthDuration-less-than(A, B) | xs:boolean |
A lt B | xs:dayTimeDuration | xs:dayTimeDuration | op:dayTimeDuration-less-than(A, B) | xs:boolean |
A lt B | xs:anyURI | xs:anyURI | op:numeric-less-than(fn:compare(A, B), 0) | xs:boolean |
A ge B | numeric | numeric | op:numeric-greater-than(A, B) or op:numeric-equal(A, B) | xs:boolean |
A ge B | xs:boolean | xs:boolean | fn:not(op:boolean-less-than(A, B)) | xs:boolean |
A ge B | xs:string | xs:string | op:numeric-greater-than(fn:compare(A, B), -1) | xs:boolean |
A ge B | xs:date | xs:date | fn:not(op:date-less-than(A, B)) | xs:boolean |
A ge B | xs:time | xs:time | fn:not(op:time-less-than(A, B)) | xs:boolean |
A ge B | xs:dateTime | xs:dateTime | fn:not(op:dateTime-less-than(A, B)) | xs:boolean |
A ge B | xs:yearMonthDuration | xs:yearMonthDuration | fn:not(op:yearMonthDuration-less-than(A, B)) | xs:boolean |
A ge B | xs:dayTimeDuration | xs:dayTimeDuration | fn:not(op:dayTimeDuration-less-than(A, B)) | xs:boolean |
A ge B | xs:anyURI | xs:anyURI | op:numeric-greater-than(fn:compare(A, B), -1) | xs:boolean |
A le B | numeric | numeric | op:numeric-less-than(A, B) or op:numeric-equal(A, B) | xs:boolean |
A le B | xs:boolean | xs:boolean | fn:not(op:boolean-greater-than(A, B)) | xs:boolean |
A le B | xs:string | xs:string | op:numeric-less-than(fn:compare(A, B), 1) | xs:boolean |
A le B | xs:date | xs:date | fn:not(op:date-greater-than(A, B)) | xs:boolean |
A le B | xs:time | xs:time | fn:not(op:time-greater-than(A, B)) | xs:boolean |
A le B | xs:dateTime | xs:dateTime | fn:not(op:dateTime-greater-than(A, B)) | xs:boolean |
A le B | xs:yearMonthDuration | xs:yearMonthDuration | fn:not(op:yearMonthDuration-greater-than(A, B)) | xs:boolean |
A le B | xs:dayTimeDuration | xs:dayTimeDuration | fn:not(op:dayTimeDuration-greater-than(A, B)) | xs:boolean |
A le B | xs:anyURI | xs:anyURI | op:numeric-less-than(fn:compare(A, B), 1) | xs:boolean |
A is B | node() | node() | op:is-same-node(A, B) | xs:boolean |
A << B | node() | node() | op:node-before(A, B) | xs:boolean |
A >> B | node() | node() | op:node-after(A, B) | xs:boolean |
A union B | node()* | node()* | op:union(A, B) | node()* |
A | B | node()* | node()* | op:union(A, B) | node()* |
A intersect B | node()* | node()* | op:intersect(A, B) | node()* |
A except B | node()* | node()* | op:except(A, B) | node()* |
A to B | xs:integer | xs:integer | op:to(A, B) | xs:integer* |
A , B | item()* | item()* | op:concatenate(A, B) | item()* |
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 initial value: This is the initial 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 initial value of the component by a different, implementation-defined value and/or to augment the default initial value by additional implementation-defined 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 globally, throughout all the modules used in a query. "Module" indicates that the component applies throughout a module . "Lexical" indicates that the component applies within the expression in which it is defined (equivalent to "module" if the component is declared in a Prolog .)
Consistency Rules: Indicates rules that must be observed in assigning values to the component. Additional consistency rules may be found in 2.2.5 Consistency Constraints .
Component | Default initial value | Can be overwritten or augmented by implementation? | Can be overwritten or augmented by a query? | Scope | Consistency rules |
---|---|---|---|---|---|
XPath 1.0 Compatibility Mode |
false
|
no | no | global |
Must
be
false
.
|
Statically known namespaces |
fn
,
xml
,
xs
,
xsi
,
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 | module | None. |
In-scope schema types |
built-in
types
in
xs
|
augmentable | augmentable by schema import in prolog | module | Only one definition per global or local type. |
In-scope element declarations | none | augmentable | augmentable by schema import in prolog | module | Only one definition per global or local element name. |
In-scope attribute declarations | none | augmentable | augmentable by schema import in prolog | module | 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. |
Context item static type |
none
|
overwriteable |
|
lexical | None. |
Function signatures |
functions
in
fn
namespace,
and
constructors
for
built-in
atomic
types
|
augmentable |
augmentable
by
module
import
and
by
function
declaration
in
|
module | Each function must have a unique expanded QName and number of arguments. |
Statically known collations | only the default collation | augmentable | no | module | Each URI uniquely identifies a collation. |
Default collation | Unicode codepoint collation | overwriteable | overwriteable by prolog | module | None. |
Construction mode |
preserve
|
overwriteable | overwriteable by prolog | module |
Value
must
be
preserve
or
strip
.
|
Ordering mode |
ordered
|
overwriteable | overwriteable by prolog or expression | lexical |
Value
must
be
ordered
or
unordered
.
|
Default order for empty sequences | implementation-defined | overwriteable | overwriteable by prolog | module |
Value
must
be
greatest
or
least
.
|
Boundary-space policy |
strip
|
overwriteable | overwriteable by prolog | module |
Value
must
be
preserve
or
strip
.
|
Copy-namespaces mode |
inherit,
preserve
|
overwriteable | overwriteable by prolog | module |
Value
consists
of
inherit
or
no-inherit
,
and
preserve
or
no-preserve
.
|
Base URI | See rules in 4.5 Base URI Declaration | overwriteable | overwriteable by prolog | module | Value must be a valid lexical representation of the type xs:anyURI. |
Statically known documents | none | augmentable | no | module | None. |
Statically known collections | none | augmentable | no | module | None. |
Statically known default collection type |
node()*
|
overwriteable | no | module | None. |
The following table describes the components of the dynamic context . The following aspects of each component are described:
Default initial value: This is the initial 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 initial value of the component by a different implementation-defined value and/or to augment the default initial value by additional implementation-defined 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
globally,
throughout
all
the
modules
used
in
a
query,
and
remains
constant
during
evaluation
of
a
query.
"Dynamic"
indicates
that
evalation
evaluation
of
an
expression
may
influence
the
value
of
the
component
for
that
expression
and
for
nested
expressions.
Consistency Rules: Indicates rules that must be observed in assigning values to the component. Additional consistency rules may be found in 2.2.5 Consistency Constraints .
Component | Default initial 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 - initial value may be overwritten with a context item declaration. | dynamic | None |
Context position | none | overwriteable | overwritten during evaluation of path expressions and predicates | dynamic | If context item is defined, context position must be >0 and <= context size; else context position is undefined. |
Context size | none | overwriteable | overwritten during evaluation of path expressions and predicates | dynamic | If context item is defined, context size must be >0; else context size is undefined. |
Variable values | none | augmentable | overwriteable and augmentable by prolog and by variable-binding expressions | dynamic | Names and values must be consistent with in-scope variables. |
Function implementations |
functions
in
fn
namespace,
and
constructors
for
built-in
atomic
types
|
augmentable |
augmentable
by
module
import
and
by
function
declaration
in
|
global | Must be consistent with function signatures |
Current dateTime | none | must be initialized by implementation | no | global | Must include a timezone. Remains constant during evaluation of a query. |
Implicit timezone | none | must be initialized by implementation | no | global | Remains constant during evaluation of a query. |
Available documents | none | must be initialized by implementation | no | global | None |
Available collections | none | must be initialized by implementation | no | global | None |
Default collection | none | overwriteable | no | global | None |
The
following
table
specifies
default
values
for
the
parameters
that
control
the
process
of
serializing
an
XDM
instance
into
XML
notation
(
method
=
"xml"
).
The
meanings
of
the
various
parameters
are
defined
in
[XSLT
2.0
and
XQuery
1.0
Serialization]
Serialization
1.1]
.
For
each
parameter,
an
XQuery
implementation
may
(but
is
not
required
to)
provide
a
means
whereby
allow
a
user
can
query
to
override
the
default
value.
value
with
an
option
declaration,
as
discussed
in
2.2.4
Serialization
.
Parameter | Default Value |
---|---|
byte-order-mark | implementation-defined |
cdata-section-elements | empty |
doctype-public | (none) |
doctype-system | (none) |
encoding | implementation-defined choice between "utf-8" and "utf-16" |
escape-uri-attributes | (not applicable when method = xml) |
include-content-type | (not applicable when method = xml) |
indent | no |
media-type | implementation-defined |
method | xml |
normalization-form | implementation-defined |
omit-xml-declaration | implementation-defined |
standalone | implementation-defined |
undeclare-prefixes | no |
use-character-maps | empty |
version | implementation-defined |
The following items in this specification are implementation-defined :
The version of Unicode that is used to construct expressions.
The implicit timezone .
The circumstances in which warnings are raised, and the ways in which warnings are handled.
The method by which errors are reported to the external processing environment.
Whether the implementation is based on the rules of [XML 1.0] and [XML Names] or the rules of [XML 1.1] and [XML Names 1.1] . One of these sets of rules must be applied consistently by all aspects of the implementation. If the implementation is based on the rules of [XML 1.0] , the edition used must be at least Third Edition; the edition used is implementation-defined , but we recommend that implementations use the latest version.
Any components of the static context or dynamic context that are overwritten or augmented by the implementation.
The
default
handling
of
empty
sequences
returned
by
an
ordering
key
(sortspec)
(orderspec)
in
an
order
by
clause
(
empty
least
or
empty
greatest
).
The names and semantics of any extension expressions ( pragmas ) recognized by the implementation.
The names and semantics of any option declarations recognized by the implementation.
Protocols (if any) by which parameters can be passed to an external function, and the result of the function can returned to the invoking query.
The process by which the specific modules to be imported by a module import are identified, if the Module Feature is supported (includes processing of location hints, if any.)
The means by which serialization is invoked, if the Serialization Feature is supported.
The
default
values
for
the
byte-order-mark
,
encoding
,
media-type
,
normalization-form
,
omit-xml-declaration
,
standalone
,
and
version
parameters,
if
the
Serialization
Feature
is
supported.
The result of an unsuccessful call to an external function (for example, if the function implementation cannot be found or does not return a value of the declared type).
Limits on ranges of values for various data types, as enumerated in 5.3 Data Model Conformance .
Syntactic extensions to XQuery, including both their syntax and semantics, as discussed in 5.4 Syntax Extensions .
Note:
Additional
implementation-defined
items
are
listed
in
[XQuery/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
and
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
.
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 .
It is a type error if, during the static analysis phase , an expression is found to have a static type that is not appropriate for the context in which the expression occurs, or during the dynamic evaluation phase , the dynamic type of a value does not match a required type as specified by the matching rules in 2.5.4 SequenceType Matching .
During
the
analysis
phase,
it
is
a
static
error
if
the
static
type
assigned
to
an
expression
other
than
the
expression
()
or
data(())
is
empty-sequence()
.
(Not currently used.)
(Not currently used.)
It is a static error if an expression refers to an element name, attribute name, schema type name, namespace prefix, or variable name that is not defined in the static context , except for an ElementName in an ElementTest or an AttributeName in an AttributeTest .
An implementation that does not support the Schema Import Feature must raise a static error if a Prolog contains a schema import.
An implementation must raise a static error if it encounters a reference to an axis that it does not support.
It is a static error if the set of definitions contained in all schemas imported by a Prolog do not satisfy the conditions for schema validity specified in Sections 3 and 5 of [XML Schema] Part 1--i.e., each definition must be valid, complete, and unique.
It is a static error if an implementation recognizes a pragma but determines that its content is invalid.
(Not currently used.)
(Not currently used.)
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 a function signature in the static context .
It
is
a
type
error
if
the
result
of
the
last
step
in
a
path
expression
contains
both
nodes
and
atomic
values.
non-nodes.
It is a type error if the result of a step (other than the last step) in a path expression contains an atomic value.
It is a type error if, in an axis step, the context item is not a node.
(Not currently used.)
It is a static error if the value of a namespace declaration attribute is not a URILiteral .
(Not currently used.)
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.
It is a dynamic error if any attribute of a constructed element does not have a name that is distinct from the names of all other attributes of the constructed element.
It
is
a
dynamic
error
if
the
result
of
the
content
expression
of
a
computed
processing
instruction
constructor
contains
the
string
"
?>
".
In
a
validate
expression,
it
is
a
dynamic
error
if
the
root
element
information
item
in
the
PSVI
resulting
from
validation
does
not
have
the
expected
validity
property:
valid
if
validation
mode
is
strict
,
or
either
valid
or
notKnown
if
validation
mode
is
lax
.
(Not currently used.)
(Not currently used.)
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 a Prolog contains more than one base URI declaration .
It is a static error if a module contains multiple bindings for the same namespace prefix.
It
is
a
static
error
if
multiple
functions
declared
or
imported
by
a
module
have
the
same
number
of
arguments
and
their
expanded
QNames
are
equal
(as
defined
by
the
eq
operator).
It is a static error to import two schema components that both define the same name in the same symbol space and in the same scope.
It
is
a
static
error
to
import
a
module
if
the
importing
module's
in-scope
schema
types
definitions
of
the
importing
module
do
not
include
definitions
for
all
of
the
following:
An
in-scope
schema
type
names
for
each
type-name
that
appear
appears:
in
the
declarations
type
of
variables
a
variable
that
is
declared
in
the
imported
module
and
functions
(whether
referenced
in
an
argument
type
the
importing
module,
OR
in
a
parameter-type
or
return
type)
result-type
of
a
function
that
are
present
is
declared
in
the
imported
module
and
are
referenced
in
the
importing
module.
An
in-scope
element
declaration
for
each
element-name
EN
such
that:
schema-element(EN)
appears
in
the
declared
type
of
a
variable
in
the
imported
module,
and
that
variable
is
referenced
in
the
importing
module,
OR
schema-element(EN)
appears
in
a
parameter-type
or
result-type
of
a
function
declared
in
the
imported
module,
and
that
function
is
referenced
in
the
importing
module.
An
in-scope
attribute
declaration
for
each
attribute-name
AN
such
that:
schema-attribute(AN)
appears
in
the
declared
type
of
a
variable
in
the
imported
module,
and
that
variable
is
referenced
in
the
importing
module,
OR
schema-attribute(AN)
appears
in
a
parameter-type
or
result-type
of
a
function
declared
in
the
imported
module,
and
that
function
is
referenced
in
the
importing
module.
(Not currently used.)
It is a static error if a Prolog contains more than one default collation declaration , or the value specified by a default collation declaration is not present in statically known collations .
It is a static error for a function declaration to have more than one parameter with the same name.
It is a static error if the attributes specified by a direct element constructor do not have distinct expanded QNames.
It
is
a
dynamic
error
if
the
value
of
the
name
expression
in
a
computed
processing
instruction
constructor
cannot
be
cast
to
the
type
xs:NCName
.
(Not currently used.)
(Not currently used.)
It
is
a
dynamic
static
error
if
the
node-name
property
of
the
a
node
constructed
by
a
computed
attribute
constructor
is
in
has
any
of
the
namespace
http://www.w3.org/2000/xmlns/
(corresponding
to
following
properties:
Its
namespace
prefix
is
xmlns
.
),
or
is
in
It
has
no
namespace
prefix
and
has
its
local
name
is
xmlns
.
Its
namespace
URI
is
http://www.w3.org/2000/xmlns/
.
Its
namespace
prefix
is
xml
and
its
namespace
URI
is
not
http://www.w3.org/XML/1998/namespace
.
Its
namespace
prefix
is
other
than
xml
and
its
namespace
URI
is
http://www.w3.org/XML/1998/namespace
.
It
is
a
static
error
if
the
function
name
in
a
function
declaration
is
in
one
of
the
following
namespaces:
http://www.w3.org/XML/1998/namespace,
http://www.w3.org/2001/XMLSchema,
http://www.w3.org/2001/XMLSchema-instance,
http://www.w3.org/2005/xpath-functions
.
An
implementation
MAY
raise
a
static
error
if
the
value
of
a
URILiteral
is
of
nonzero
length
and
is
not
in
the
lexical
space
of
xs:anyURI
.
It is a static error if multiple module imports in the same Prolog specify the same target namespace.
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
two
or
more
variables
declared
or
imported
by
a
module
have
equal
expanded
QNames
(as
defined
by
the
eq
operator.)
It
is
a
dynamic
error
if
the
dynamic
type
of
the
operand
of
a
treat
expression
does
not
match
the
sequence
type
specified
by
the
treat
expression.
This
error
might
also
be
raised
by
a
path
expression
beginning
with
"
/
"
or
"
//
"
if
the
context
node
is
not
in
a
tree
that
is
rooted
at
a
document
node.
This
is
because
a
leading
"
/
"
or
"
//
"
in
a
path
expression
is
an
abbreviation
for
an
initial
step
that
includes
the
clause
treat
as
document-node()
.
It is a static error if a QName that is used as an AtomicType in a SequenceType is not defined in the in-scope schema types as an atomic type.
(Not currently used.)
(Not currently used.)
It is a static error if a variable depends on itself.
It is a static error if a Prolog contains more than one copy-namespaces declaration .
(Not currently used.)
It is a static error if a schema import binds a namespace prefix but does not specify a target namespace other than a zero-length string.
It is a static error if multiple schema imports specify the same target namespace.
It is a static error if an implementation is unable to process a schema or module import by finding a schema or module with the specified target namespace.
It is a static error if the name of a function in a function declaration is not in a namespace (expanded QName has a null namespace URI).
It is a dynamic error if the operand of a validate expression is a document node whose children do not consist of exactly one element node and zero or more comment and processing instruction nodes, in any order.
(Not currently used.)
(Not currently used.)
It is a dynamic error if the value of the name expression in a computed processing instruction constructor is equal to "XML" (in any combination of upper and lower case).
A static error is raised if a Prolog contains more than one ordering mode declaration .
A static error is raised if a Prolog contains more than one default element/type namespace declaration, or more than one default function namespace declaration.
A static error is raised if a Prolog contains more than one construction declaration .
A static error is raised if a Prolog contains more than one boundary-space declaration .
A static error is raised if a Prolog contains more than one empty order declaration .
A
static
error
is
raised
if
a
namespace
URI
is
bound
to
one
of
the
predefined
prefix
prefixes
xml
or
xmlns
appears
in
a
namespace
declaration,
or
if
,
a
any
of
the
following
conditions
is
statically
detected
in
any
expression
or
declaration:
The
prefix
xml
is
bound
to
some
namespace
URI
other
than
http://www.w3.org/XML/1998/namespace
.
A
prefix
other
than
xml
is
bound
to
the
prefix
namespace
URI
.xml
,
or
if
the
http://www.w3.org/XML/1998/namespace
The
prefix
is
bound
to
xml
xmlns
a
any
namespace
URI
URI.
A
prefix
other
than
is
bound
to
the
namespace
URI
http://www.w3.org/XML/1998/namespace
xmlns
http://www.w3.org/2000/xmlns/
.
A static error is raised if the namespace declaration attributes of a direct element constructor do not have distinct names.
It is a dynamic error if the result of the content expression of a computed comment constructor contains two adjacent hyphens or ends with a hyphen.
It
is
a
static
error
if
the
graph
of
module
imports
contains
a
cycle
(that
is,
if
there
exists
a
sequence
of
modules
M
1
...
M
n
such
that
each
M
i
imports
M
i+1
and
M
n
imports
M
1
),
unless
all
the
modules
in
the
cycle
share
a
common
namespace.
(Not
currently
used.)
It is a dynamic error if the value of the name expression in a computed element or attribute constructor cannot be converted to an expanded QName (for example, because it contains a namespace prefix not found in statically known namespaces .)
An
implementation
that
does
not
support
the
Validation
Feature
must
raise
a
static
error
if
it
encounters
a
validate
expression.
It
is
a
static
error
if
a
collation
subclause
in
an
order
by
clause
of
a
FLWOR
expression
does
not
identify
a
collation
that
is
present
in
statically
known
collations
.
(Not currently used.)
(Not currently used.)
It is a static error if an extension expression contains neither a pragma that is recognized by the implementation nor an expression enclosed in curly braces.
It
is
a
static
error
if
the
target
type
of
a
cast
or
castable
expression
is
xs:NOTATION
or
xs:anyAtomicType
.
It is a static error if a QName used in a query contains a namespace prefix that cannot be expanded into a namespace URI by using the statically known namespaces .
(Not currently used.)
(Not currently used.)
It
is
a
dynamic
error
if
the
element
validated
by
a
validate
statement
does
not
have
a
top-level
element
declaration
in
the
in-scope
element
declarations
,
if
validation
mode
is
strict
.
It is a static error if the namespace URI in a namespace declaration attribute is a zero-length string, and the implementation does not support [XML Names 1.1] .
It
is
a
type
error
if
the
typed
value
of
a
copied
element
or
attribute
node
is
namespace-sensitive
when
construction
mode
is
preserve
and
copy-namespaces
mode
is
no-preserve
.
It
is
a
static
error
if
the
encoding
specified
in
a
Version
Declaration
does
not
conform
to
the
definition
of
EncName
specified
in
[XML
1.0]
.
It is a static error if the literal that specifies the target namespace in a module import or a module declaration is of zero length.
It
is
a
static
error
if
a
variable
bound
in
a
for
or
window
clause
of
a
FLWOR
expression,
and
its
associated
positional
variable,
do
not
have
distinct
names
(expanded
QNames).
It is a static error if a character reference does not identify a valid character in the version of XML that is in use.
An
implementation
MAY
raise
a
dynamic
error
if
an
xml:id
error,
as
defined
in
[XML
ID]
,
is
encountered
during
construction
of
an
attribute
named
xml:id
.
An
implementation
MAY
raise
a
dynamic
error
if
a
constructed
attribute
named
xml:space
has
a
value
other
than
preserve
or
default
.
It
In
the
group
by
clause
of
a
FLWOR
expression,
it
is
a
static
error
if
the
name
of
a
grouping
variable
is
not
equal
(by
the
eq
operator
on
expanded
QNames)
to
import
the
name
of
a
module
M
1
variable
that
is
bound
by
a
for
or
let
clause
that
precedes
the
group
by
clause.
In
the
group
by
clause
of
a
FLWOR
expression,
it
is
a
dynamic
error
if
there
exists
the
value
bound
to
a
grouping
variable
consists
of
a
sequence
of
modules
M
1
...
M
i
...
M
1
such
more
than
one
item.
It is a dynamic error the node-name of a node constructed by a computed element constructor has any of the following properties:
Its
namespace
prefix
is
xmlns
.
Its
namespace
URI
is
http://www.w3.org/2000/xmlns/
.
Its
namespace
prefix
is
xml
and
its
namespace
URI
is
not
http://www.w3.org/XML/1998/namespace
.
Its
namespace
prefix
is
other
than
xml
and
its
namespace
URI
is
http://www.w3.org/XML/1998/namespace
.
It is a static error for a decimal-format to specify a value that is not legal for a given property, as described in statically known decimal formats
It
is
a
static
error
if,
for
any
named
or
unnamed
decimal
format,
the
properties
representing
characters
used
in
a
picture
string
do
not
each
module
directly
depends
have
distinct
values.
These
properties
are
decimal-separator-sign
,
grouping-separator
,
percent-sign
,
per-mille-sign
,
zero-digit
,
digit-sign
,
and
pattern-separator-sign
.
A
ContextItemDecl
must
not
occur
after
an
expression
that
relies
on
the
next
module
initial
context
item,
and
no
query
may
contain
more
than
one
ContextItemDecl.
It is a static error if any of the following decimal format properties is not a single character.
An
error
is
raised
if
the
namespace
URI
in
a
computed
namespace
constructor
is
bound
to
the
predefined
prefix
xmlns
,
or
if
a
namespace
URI
other
than
http://www.w3.org/XML/1998/namespace
is
bound
to
the
prefix
xml
,
or
if
the
prefix
xml
is
bound
to
a
namespace
URI
other
than
http://www.w3.org/XML/1998/namespace.
In an element constructor, if two or more namespace bindings in the in-scope bindings would have the same prefix, then an error is raised if they have different URIs; if they would have the same prefix and URI, duplicate bindings are ignored.
All
variables
in
a
window
clause
must
have
distinct
names.
A
TypeName
that
is
specified
in
a
validate
expression
must
be
found
in
the
in-scope
schema
definitions
It
is
a
type
error
if
the
content
sequence
(informally,
in
an
element
constructor
contains
a
function
item.
It
is
a
static
error
if
M
1
a
FunctionOptions
contains
more
than
one
PrivateOption
or
more
than
one
DeterministicOption
.
It
is
a
static
error
if
the
initializer
of
the
context
item
depends
on
itself
through
some
chain
of
the
context
item.
It
is
a
static
error
if
an
output
declaration
occurs
in
a
library
module
dependencies.)
.
It
is
a
static
error
if
the
local
name
of
an
output
declaration
in
the
http://www.w3.org/2009/xquery-serialization
namespace
is
not
one
of
the
serialization
parameter
names
listed
in
C.3
Serialization
Parameters
.
It is a static error if the same serialization parameter is used more than once in an output declaration .
application/xquery
Media
Type
This Appendix specifies the media type for XQuery Version 1.0. XQuery is a language for querying over collections of data from XML data sources, as specified in the main body of this document. This media type is being submitted to the IESG (Internet Engineering Steering Group) for review, approval, and registration with IANA (Internet Assigned Numbers Authority.)
This
document,
found
at
http://www.w3.org/TR/xquery/
,
,
together
with
its
normative
references,
defines
the
language
XQuery
Version
1.0.
This
Appendix
provides
information
about
the
application/xquery
media
type,
which
is
intended
to
be
used
for
transmitting
queries
written
in
the
XQuery
language.
This document was prepared by members of the W3C XML Query Working Group. Please send comments to public-qt-comments@w3.org, a public mailing list with archives at http://lists.w3.org/Archives/Public/public-qt-comments .
application/xquery
MIME
media
type
name:
application
MIME
subtype
name:
xquery
Required parameters: none
Optional parameters: none
The
syntax
of
XQuery
is
expressed
in
Unicode
but
may
be
written
with
any
Unicode-compatible
character
encoding,
including
UTF-8
or
UTF-16,
or
transported
as
US-ASCII
or
Latin-1
ISO-8859-1
with
Unicode
characters
outside
the
range
of
the
given
encoding
represented
using
an
XML-style
ෝ
syntax.
The public XQuery Web page lists more than two dozen implementations of the XQuery language, both proprietary and open source.
This new media type is being registered to allow for deployment of XQuery on the World Wide Web.
The
most
common
file
extensions
in
use
for
XQuery
are
.xq
and
.xquery
.
The
appropriate
Macintosh
file
type
code
is
TEXT
.
For use with transports that are not 8-bit clean, quoted-printable encoding is recommended since the XQuery syntax itself uses the US-ASCII-compatible subset of Unicode.
An XQuery document may contain an encoding declaration as part of its version declaration :
xquery version "1.0" encoding "utf-8";
An
XQuery
file
may
have
the
string
xquery
version
"V.V"
near
the
beginning
of
the
document,
where
"V.V"
is
a
version
number.
Currently
the
version
number,
if
present,
must
be
"1.0"
.
XQuery documents use the Unicode character set and, by default, the UTF-8 encoding.
Queries
written
in
XQuery
may
cause
arbitrary
URIs
or
IRIs
to
be
dereferenced.
Therefore,
the
security
issues
of
[RFC3987]
Section
8
should
be
considered.
In
addition,
the
contents
of
resources
identified
by
file:
URIs
can
in
some
cases
be
accessed,
processed
and
returned
as
results.
XQuery
expressions
can
invoke
any
of
the
functions
defined
in
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
.
For
example,
the
fn:doc()
and
fn:doc-available()
functions
allow
local
filesystem
probes
as
well
as
access
to
any
URI-defined
resource
accessible
from
the
system
evaluating
the
XQuery
expression.
XQuery is a full declarative programming language, and supports user-defined functions, external function libraries (modules) referenced by URI, and system-specific "native" functions.
Arbitrary recursion is possible, as is arbitrarily large memory usage, and implementations may place limits on CPU and memory usage, as well as restricting access to system-defined functions.
The XML Query Working group is working on a facility to allow XQuery expressions to create and update persistent data. Untrusted queries should not be given write access to data.
Furthermore,
because
the
XQuery
language
permits
extensions,
it
is
possible
that
application/xquery
may
describe
content
that
has
security
implications
beyond
those
described
here.
An atomic value is a value in the value space of an atomic type , as defined in [XML Schema] .
Atomization
of
a
sequence
is
defined
as
the
result
of
invoking
the
fn:data
function
on
the
sequence,
as
defined
in
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
.
Available
collections.
This
is
a
mapping
of
strings
onto
sequences
of
nodes.
The
string
represents
the
absolute
URI
of
a
resource.
The
sequence
of
nodes
represents
the
result
of
the
fn:collection
function
when
that
URI
is
supplied
as
the
argument.
Available
documents.
This
is
a
mapping
of
strings
onto
document
nodes.
The
string
represents
the
absolute
URI
of
a
resource.
The
document
node
is
the
root
of
a
tree
that
represents
that
resource
using
the
data
model
.
The
document
node
is
returned
by
the
fn:doc
function
when
applied
to
that
URI.
An axis step returns a sequence of 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 annotation .
Base
URI.
This
is
an
absolute
URI,
used
when
necessary
in
the
resolution
of
relative
URIs
(for
example,
by
the
fn:resolve-uri
function.)
A base URI declaration specifies the base URI property of the static context . The base URI property is used when resolving relative URIs within a module .
The
value
of
the
expression
associated
with
a
variable
in
In
a
for
clause
or
window
clause,
when
an
expression
is
called
preceded
by
the
keyword
in
,
the
value
of
that
expression
is
called
a
binding
sequence
for
that
variable.
.
A boundary-space declaration sets the boundary-space policy in the static context , overriding any implementation-defined default. Boundary-space policy controls whether boundary whitespace is preserved by element constructors during processing of the query.
Boundary-space policy. This component controls the processing of boundary whitespace by direct element constructors , as described in 3.7.1.4 Boundary Whitespace .
Boundary
whitespace
is
a
sequence
of
consecutive
whitespace
characters
within
the
content
of
a
direct
element
constructor
,
that
is
delimited
at
each
end
either
by
the
start
or
end
of
the
content,
or
by
a
DirectConstructor
,
or
by
an
EnclosedExpr
.
For
this
purpose,
characters
generated
by
character
references
such
as
 
or
by
CdataSections
are
not
considered
to
be
whitespace
characters.
The
built-in
functions
supported
by
XQuery
1.1
are
defined
in
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
.
A
character
reference
is
an
XML-style
reference
to
a
[Unicode]
character,
identified
by
its
decimal
or
hexadecimal
code
point.
codepoint.
A
collation
is
a
specification
of
the
manner
in
which
strings
and
URIs
are
compared
and,
by
extension,
ordered.
For
a
more
complete
definition
of
collation,
see
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
.
One way to construct a sequence is by using the comma operator , which evaluates each of its operands and concatenates the resulting sequences, in order, into a single result sequence.
A computed element constructor creates an element node, allowing both the name and the content of the node to be computed.
A construction declaration sets the construction mode in the static context , overriding any implementation-defined default.
Construction
mode.
The
construction
mode
governs
the
behavior
of
element
and
document
node
constructors.
If
construction
mode
is
preserve
,
the
type
of
a
constructed
element
node
is
xs:anyType
,
and
all
attribute
and
element
nodes
copied
during
node
construction
retain
their
original
types.
If
construction
mode
is
strip
,
the
type
of
a
constructed
element
node
is
xs:untyped
;
all
element
nodes
copied
during
node
construction
receive
the
type
xs:untyped
,
and
all
attribute
nodes
copied
during
node
construction
receive
the
type
xs:untypedAtomic
.
The
constructor
function
for
a
given
type
is
used
to
convert
instances
of
other
atomic
types
into
the
given
type.
The
semantics
of
the
constructor
function
call
T($arg)
are
defined
to
be
equivalent
to
the
expression
(($arg)
cast
as
T?)
.
The final part of a computed constructor is an expression enclosed in braces, called the content expression of the constructor, that generates the content of the node.
The context item is the item currently being processed. An item is either an atomic value or a node.
Context item static type. This component defines the static type of the context item within the scope of a given expression.
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.
The context size is the number of items in the sequence of items currently being processed.
A copy-namespaces declaration sets the value of copy-namespaces mode in the static context , overriding any implementation-defined default. Copy-namespaces mode controls the namespace bindings that are assigned when an existing element node is copied by an element constructor or document constructor.
Copy-namespaces
mode.
This
component
controls
the
namespace
bindings
that
are
assigned
when
an
existing
element
node
is
copied
by
an
element
constructor,
as
described
in
3.7.1
Direct
Element
Constructors
.
Its
value
consists
of
two
parts:
preserve
or
no-preserve
,
and
inherit
or
no-inherit
.
Current
dateTime.
This
information
represents
an
implementation-dependent
point
in
time
during
the
processing
of
a
query
,
and
includes
an
explicit
timezone.
It
can
be
retrieved
by
the
fn:current-dateTime
function.
If
invoked
multiple
times
during
the
execution
of
a
query
,
this
function
always
returns
the
same
result.
XQuery
1.1
operates
on
the
abstract,
logical
structure
of
an
XML
document,
rather
than
its
surface
syntax.
This
logical
structure,
known
as
the
data
model
,
is
defined
in
[XQuery/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
.
For a given node in an XDM instance , the data model schema is defined as the schema from which the type annotation of that node was derived.
A
decimal-format
declaration
defines
statically
known
decimal
formats
,
which
define
the
properties
used
to
format
numbers
using
the
fn:format-number()
function
decimal-separator specifies the character used for the decimal-separator-sign; the default value is the period character (.)
Default
collation.
This
identifies
one
of
the
collations
in
statically
known
collations
as
the
collation
to
be
used
by
functions
and
operators
for
comparing
and
ordering
values
of
type
xs:string
and
xs:anyURI
(and
types
derived
from
them)
when
no
explicit
collation
is
specified.
A default collation declaration sets the value of the default collation in the static context , overriding any implementation-defined default.
Default
collection.
This
is
the
sequence
of
nodes
that
would
result
from
calling
the
fn:collection
function
with
no
arguments.
Default element/type namespace. This is a namespace URI or "none". The namespace URI, if present, 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 or "none". The namespace URI, if present, is used for any unprefixed QName appearing in a position where a function name is expected.
Default
order
for
empty
sequences.
This
component
controls
the
processing
of
empty
sequences
and
NaN
values
as
ordering
keys
in
an
order
by
clause
in
a
FLWOR
expression,
as
described
in
3.8.3
3.8.8
Order
By
and
Return
Clauses
Clause
.
The delimiting terminal symbols are: S , "-", (comma), (semi-colon), (colon), "::", ":=", "!=", "?", "?>", "/", "//", "/>", (dot), "..", StringLiteral , "(", "(#", ")", "[", "]", "]]>", "{", "}", "@", "$", "*", "#", "#)", "+", "<", "<!--", "<![CDATA[", "<?", "</", "<<", "<=", "=", ">", "-->", ">=", ">>", "|"
An
expression
E
depends
on
a
function
if
any
of
the
following
is
true:
|
An
expression
E
depends
on
a
variable
V
if
any
of
the
following
is
true:
|
A deterministic function is a function that always evaluates to the same result if it is invoked with the same arguments.
digit-sign specifies the character used for the digit-sign in the picture string; the default value is the number sign character (#)
A direct element constructor is a form of element constructor in which the name of the constructed element is a constant.
Informally, document order is the order in which nodes appear in the XML serialization of a document.
The dynamic context of an expression is defined as information that is available at the time the expression is evaluated.
A dynamic error is an error that must be detected during the dynamic evaluation phase and may be detected during the static analysis phase. Numeric overflow is an example of a dynamic error.
The dynamic evaluation phase is the phase during which the value of an expression is computed.
A dynamic function invocation invokes DM11 a function item DM11 , calling the function it represents.
A
dynamic
type
is
associated
with
each
value
as
it
is
computed.
The
dynamic
type
of
a
value
may
be
more
specific
than
the
static
type
of
the
expression
that
computed
it
(for
example,
the
static
type
of
an
expression
might
be
xs:integer*
,
denoting
a
sequence
of
zero
or
more
integers,
but
at
evaluation
time
its
value
may
have
the
dynamic
type
xs:integer
,
denoting
exactly
one
integer.)
The
effective
boolean
value
of
a
value
is
defined
as
the
result
of
applying
the
fn:boolean
function
to
the
value,
as
defined
in
[XQuery
1.0
and
XPath
2.0
Functions
and
Operators]
Operators
1.1]
.
The effective case in a switch expression is the first case clause in which the value of the switch operand expression is equivalent to the value of a case operand, as defined in equivalence of two atomic values , or the default clause if no such case clause exists.
The
effective
case
in
a
typeswitch
expression
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
.
An
empty
order
declaration
sets
the
default
order
for
empty
sequences
in
the
static
context,
overriding
any
implementation-defined
default.
This
declaration
controls
the
processing
of
empty
sequences
and
NaN
values
as
ordering
keys
in
an
order
by
clause
in
a
FLWOR
expression.
A sequence containing zero items is called an empty sequence .
If
present,
a
version
declaration
may
optionally
include
an
encoding
declaration
.
The
value
of
the
string
literal
following
the
keyword
encoding
is
an
encoding
name,
and
must
conform
to
the
definition
of
EncName
specified
in
[XML
1.0]
[
err:XQST0087
].
The
purpose
of
an
encoding
declaration
is
to
allow
the
writer
of
a
query
to
provide
a
string
that
indicates
how
the
query
is
encoded,
such
as
"
UTF-8
",
"
UTF-16
",
or
"
US-ASCII
".
Equivalence of two atomic values V1 and V2 is defined by the following equivalence rules:
|
In addition to its identifying QName, a dynamic error may also carry a descriptive string and one or more additional values called error values .
An expanded QName consists of an optional namespace URI and a local name. An expanded QName also retains its original namespace prefix (if any), to facilitate casting the expanded QName into a string.
The expression context for a given expression consists of all the information that can affect the result of the expression.
An
expression
E
depends
on
the
context
item
if
any
of
the
following
is
true:
|
An extension expression is an expression whose semantics are implementation-defined .
External functions are functions that are implemented outside the query environment.
A filter expression consists simply of a primary expression followed by zero or more predicates . The result of the filter expression consists of the items returned by the primary expression, filtered by applying each predicate in turn, working from left to right.
The first three components of the dynamic context (context item, context position, and context size) are called the focus of the expression.
A
function
f1
The
depends
function
conversion
rules
on
a
variable
$y
are
used
to
convert
an
argument
value
or
a
function
f2
if
a
reference
return
value
to
its
expected
type;
that
is,
to
$y
or
f2
appears
in
the
body
declared
type
of
f1
,
or
if
there
exists
a
variable
$z
or
a
the
function
f3
such
that
f1
depends
on
$z
or
f3
and
$z
or
f3
depends
on
$y
parameter
or
f2
.
return.
Function implementations . Each function in function signatures has a function implementation that enables the function to map instances of its parameter types into an instance of its result type. For a user-defined function , the function implementation is an XQuery expression. For a built-in function or external function , the function implementation is implementation-dependent .
Function item coercion wraps a function item DM11 in a new inline function with signature the same as the expected type. This effectively delays the checking of the argument and return types until the function item is invoked.
Function signatures. This component defines 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
the
operator
mapping
tables,
the
term
Gregorian
refers
to
the
types
xs:gYearMonth
,
xs:gYear
,
xs:gMonthDay
,
xs:gDay
,
and
xs:gMonth
.
The atomized value of a grouping variable is called a grouping key .
grouping-separator specifies the character used for the grouping-sign, which is typically used as a thousands separator; the default value is the comma character (,)
A
group
by
clause
consists
of
the
keywords
group
by
followed
by
one
or
more
variables
called
grouping
variables
.
Ignorable whitespace consists of any whitespace characters that may occur between terminals , unless these characters occur in the context of a production marked with a ws:explicit annotation, in which case they can occur only where explicitly specified (see A.2.4.2 Explicit Whitespace Handling ).
Implementation-defined indicates an aspect that may differ between implementations, but must be specified by the implementor for each particular implementation.
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.
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
arithmetic
operation.
The
implicit
timezone
is
an
implementation-defined
value
of
type
xs:dayTimeDuration
.
See
[XML
Schema]
for
the
range
of
legal
values
of
a
timezone.
infinity specifies the string used for the infinity-symbol; the default value is the string Infinity
If
a
variable
declaration
includes
an
expression,
expression
(
VarValue
or
VarDefaultValue
),
the
expression
is
called
an
initializing
expression.
The
static
context
for
an
initializing
expression
.
includes
all
functions,
variables,
and
namespaces
that
are
declared
or
imported
anywhere
in
the
Prolog,
other
than
the
variable
being
declared.
An inline function expression creates a function item DM11 that represents an anonymous function defined directly in the inline function expression itself.
In-scope attribute declarations. Each attribute declaration is identified either by an expanded 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 element declarations. Each element declaration is identified either by an expanded QName (for a top-level element declaration) or by an implementation-dependent element identifier (for a local element declaration). If the Schema Import Feature is supported, in-scope element declarations include all element declarations found in imported schemas.
The in-scope namespaces property of an element node is a set of namespace bindings , each of which associates a namespace prefix with a URI, thus defining the set of namespace prefixes that are available for interpreting QNames within the scope of the element. For a given element, one namespace binding may have an empty prefix; the URI of this namespace binding is the default namespace within the scope of the element.
In-scope schema definitions. This is a generic term for all the element declarations, attribute declarations, and schema type definitions that are in scope during processing of an expression.
In-scope schema types. Each schema type definition is identified either by an expanded QName (for a named type ) or by an implementation-dependent type identifier (for an anonymous type ). The in-scope schema types include the predefined schema types described in 2.5.1 Predefined Schema Types . If the Schema Import Feature is supported, in-scope schema types also include all type definitions found in imported schemas.
In-scope variables. This is a set of (expanded QName, type) pairs. It defines the set of variables that are available for reference within an expression. The expanded QName is the name of the variable, and the type is the static type of the variable.
An item is either an atomic value or a node .
An alternative form of a node test called a kind test can select nodes based on their kind, name, and type annotation .
A module that does not contain a Query Body is called a library module . A library module consists of a module declaration followed by a Prolog .
A literal is a direct syntactic representation of an atomic value.
A literal function item creates a function item DM11 that represents a named function .
A main module consists of a Prolog followed by a Query Body .
MAY means that an item is truly optional.
minus-sign specifies the character used for the minus-symbol; the default value is the hyphen-minus character (-, #x2D). The value must be a single character.
A module is a fragment of XQuery code that conforms to the Module grammar and can independently undergo the static analysis phase described in 2.2.3 Expression Processing . Each module is either a main module or a library module .
A
module
declaration
serves
to
identify
a
module
as
a
library
module
.
A
module
declaration
begins
with
the
keyword
module
and
contains
a
namespace
prefix
and
a
URILiteral
.
A conforming XQuery implementation that supports the Module Feature allows a query Prolog to contain a Module Import and allows library modules to be created.
A
module
import
imports
the
function
variable
declarations
and
variable
public
function
declarations
from
one
or
more
library
modules
into
the
function
signatures
and
in-scope
variables
of
the
importing
module
.
MUST means that the item is an absolute requirement of the specification.
A named function is a function defined in the static context for the query. To uniquely identify a particular named function, both its name as a QName and its arity are required.
When an expression is used to specify the name of a constructed node, that expression is called the name expression of the constructor.
A namespace declaration declares a namespace prefix and associates it with a namespace URI, adding the (prefix, URI) pair to the set of statically known namespaces .
A namespace declaration attribute is used inside a direct element constructor. Its purpose is to bind a namespace prefix or to set the default element/type namespace for the constructed element node, including its attributes.
A
value
is
namespace-sensitive
if
it
includes
an
item
whose
dynamic
type
is
xs:QName
or
xs:NOTATION
or
is
derived
by
restriction
from
xs:QName
or
xs:NOTATION
.
A node test that consists only of a QName or a Wildcard is called a name test .
NaN specifies the string used for the NaN-symbol, which is used to represent the value NaN (not-a-number); the default value is the string NaN
A
node
is
an
instance
of
one
of
the
node
kinds
defined
in
[XQuery/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
.
A node test is a condition that must be true for each node selected by a step .
The
non-delimiting
terminal
symbols
are:
IntegerLiteral
,
NCName
,
QName
,
DecimalLiteral
,
DoubleLiteral
,
"allowing",
"ancestor",
"ancestor-or-self",
"and",
"as",
"ascending",
"at",
"attribute",
"base-uri",
"boundary-space",
"by",
"case",
"cast",
"castable",
"catch",
"child",
"collation",
"comment",
"construction",
"context",
"copy-namespaces",
"count",
"decimal-format",
"decimal-separator",
"declare",
"default",
"descendant",
"descendant-or-self",
"descending",
"deterministic",
"digit",
"div",
"document",
"document-node",
"element",
"else",
"empty",
"empty-sequence",
"encoding",
"end",
"eq",
"every",
"except",
"external",
"following",
"following-sibling",
"for",
"function",
"ge",
"greatest",
"group",
"grouping-separator",
"gt",
"idiv",
"if",
"import",
"in",
"infinity",
"inherit",
"instance",
"intersect",
"is",
"item",
"lax",
"le",
"least",
"let",
"lt",
"minus-sign",
"mod",
"module",
"namespace",
"namespace-node",
"NaN",
"ne",
"next",
"node",
"no-inherit",
"nondeterministic",
"no-preserve",
"of",
"only",
"option",
"or",
"order",
"ordered",
"ordering",
"parent",
"pattern-separator",
"percent",
"per-mille",
"preceding",
"preceding-sibling",
"preserve",
"previous",
"private",
"processing-instruction",
"public",
"return",
"satisfies",
"schema",
"schema-attribute",
"schema-element",
"self",
"sliding",
"some",
"stable",
"start",
"strict",
"strip",
"switch",
"text",
"then",
"to",
"treat",
"try",
"tumbling",
"typeswitch",
"union",
"unordered",
"validate",
"variable",
"version",
"when",
"where",
"xquery"
"window",
"xquery",
"zero-digit"
A nondeterministic function is a function that is not guaranteed to always return the same result when it is invoked with the same arguments.
When
referring
to
a
type,
the
term
numeric
denotes
the
types
xs:integer
,
xs:decimal
,
xs:float
,
and
xs:double
.
A predicate whose predicate expression returns a numeric type is called a numeric predicate .
For each operator and valid combination of operand types, the operator mapping tables specify a result type and an operator function that implements the semantics of the operator for the given types.
An option declaration declares an option that affects the behavior of a particular implementation. Each option consists of an identifying QName and a StringLiteral.
Ordering
mode.
Ordering
mode,
which
has
the
value
ordered
or
unordered
,
affects
the
ordering
of
the
result
sequence
returned
by
certain
path
expressions
,
FLWOR
expressions,
and
union
,
intersect
,
and
except
expressions,
and
FLWOR
expressions
that
have
no
order
by
clause.
expressions.
An ordering mode declaration sets the ordering mode in the static context , overriding any implementation-defined default.
An
output
declaration
is
an
option
declaration
in
the
predeclared
namespace
associated
with
the
output
prefix;
it
is
used
to
declare
an
output
parameter
for
serializing
the
output
of
the
query.
A
path
expression
can
be
used
to
locate
nodes
within
trees.
A
path
expression
consists
of
a
series
of
one
or
more
steps
,
separated
by
"
/
"
or
"
//
",
and
optionally
beginning
with
"
/
"
or
"
//
".
pattern-separator-sign specifies the character used for the pattern-separator-sign, which separates positive and negative sub-pictures in a picture string; the default value is the semi-colon character (;)
percent-sign specifies the character used for the percent-sign; the default value is the percent character (%)
per-mille-sign specifies the character used for the per-mille-sign; the default value is the Unicode per-mille character (#x2030)
A
positional
variable
is
a
variable
that
is
preceded
by
the
keyword
at
.
A
pragma
is
denoted
by
the
delimiters
(#
and
#)
,
and
consists
of
an
identifying
QName
followed
by
implementation-defined
content.
A predefined entity reference is a short sequence of characters, beginning with an ampersand, that represents a single character that might otherwise have syntactic significance.
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.
Primary expressions are the basic primitives of the language. They include literals, variable references, context item expressions, constructors, and function calls. A primary expression may also be created by enclosing any expression in parentheses, which is sometimes helpful in controlling the precedence of operators.
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.
A private function is hidden from module import , which can not import it into the function signatures of another module.
A Prolog is a series of declarations and imports that define the processing environment for the module that contains the Prolog.
A public function is accessible to module import , which can import it into the function signatures of another module.
Lexically, a QName consists of an optional namespace prefix and a local name. If the namespace prefix is present, it is separated from the local name by a colon.
A query consists of one or more modules .
The Query Body , if present, consists of an expression that defines the result of the query.
The node ordering that is the reverse of document order is called reverse document order .
A schema import imports the element declarations, attribute declarations, and type definitions from a schema into the in-scope schema definitions . For each user-defined atomic type in the schema, schema import also adds a corresponding constructor function .
The Schema Import Feature permits the query Prolog to contain a schema import .
A schema type is a type that is (or could be) defined using the facilities of [XML Schema] (including the built-in types of [XML Schema] ).
The
Schema
Validation
Feature
permits
a
query
to
contain
a
validate
expression
(see
3.13
3.15
Validate
Expressions
.)
A sequence is an ordered collection of zero or more items .
A sequence type is a type that can be expressed using the SequenceType syntax. Sequence types are used whenever it is necessary to refer to a type in an XQuery 1.1 expression. The term sequence type suggests that this syntax is used to describe the type of an XQuery 1.1 value, which is always a sequence.
During evaluation of an expression, it is sometimes necessary to determine whether a value with a known dynamic type "matches" an expected sequence type . This process is known as SequenceType matching .
Serialization is the process of converting an XDM instance into a sequence of octets (step DM4 in Figure 1.)
A conforming XQuery implementation that supports the Serialization Feature MUST provide means for serializing the result of a query, as specified in 2.2.4 Serialization .
Setters are declarations that set the value of some property that affects query processing, such as construction mode, ordering mode, or default collation.
SHOULD means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
A sequence containing exactly one item is called a singleton .
Document order is stable , which means that the relative order of two nodes will not change during the processing of a given query , even if this order is implementation-dependent .
Statically known collations. This is an implementation-defined set of (URI, collation) pairs. It defines the names of the collations that are available for use in processing queries and expressions.
Statically
known
collections.
This
is
a
mapping
from
strings
onto
types.
The
string
represents
the
absolute
URI
of
a
resource
that
is
potentially
available
using
the
fn:collection
function.
The
type
is
the
type
of
the
sequence
of
nodes
that
would
result
from
calling
the
fn:collection
function
with
this
URI
as
its
argument.
Statically
known
decimal
formats.
This
is
the
set
of
known
decimal
formats.
Each
format
is
used
for
serializing
decimal
numbers
using
fn:format-number()
.
Statically
known
default
collection
type.
This
is
the
type
of
the
sequence
of
nodes
that
would
result
from
calling
the
fn:collection
function
with
no
arguments.
Statically
known
documents.
This
is
a
mapping
from
strings
onto
types.
The
string
represents
the
absolute
URI
of
a
resource
that
is
potentially
available
using
the
fn:doc
function.
The
type
is
the
static
type
of
a
call
to
fn:doc
with
the
given
URI
as
its
literal
argument.
Statically known namespaces. This is a set of (prefix, URI) pairs that define all the namespaces that are known during static processing of a given expression.
The static analysis phase depends on the expression itself and on the static context . The static analysis phase does not depend on input data (other than schemas).
The static context of an expression is the information that is available during static analysis of the expression, prior to its evaluation.
A static error is an error that must be detected during the static analysis phase. A syntax error is an example of a static error .
The
static
type
of
an
expression
is
a
type
such
that,
when
the
expression
is
evaluated,
best
inference
that
the
resulting
value
will
always
conform
processor
is
able
to
make
statically
about
the
static
type.
static
typing
extension
A
static
typing
extension
is
an
implementation-defined
type
inference
rule
that
infers
a
more
precise
static
type
than
that
inferred
by
of
the
type
inference
rules
in
[XQuery
1.0
and
XPath
2.0
Formal
Semantics]
.
result
of
the
expression.
The
Static
Typing
Feature
provides
support
for
the
static
semantics
defined
in
[XQuery
1.0
and
XPath
2.0
Formal
Semantics]
,
and
requires
implementations
to
detect
and
report
all
type
errors
during
the
static
analysis
phase
.
A step is a part of a path expression that 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, working from left to right. A step may be either an axis step or a filter expression .
The
string
value
of
a
node
is
a
string
and
can
be
extracted
by
applying
the
fn:string
function
to
the
node.
Substitution groups are defined in [XML Schema] Part 1, Section 2.2.2.2. Informally, the substitution group headed by a given element (called the head element ) consists of the set of elements that can be substituted for the head element without affecting the outcome of schema validation.
A
sequence
type
A
is
a
subtype
of
a
sequence
type
B
if
and
only
if,
for
every
value
V
,
if
V
matches
A
according
to
the
rules
of
SequenceType
matching
,
then
V
also
matches
B
.
The use of a value whose dynamic type is derived from an expected type is known as subtype substitution .
Each rule in the grammar defines one symbol , using the following format:
symbol ::= expression
Whitespace
and
Comments
function
as
symbol
separators
.
For
the
most
part,
they
are
not
mentioned
in
the
grammar,
and
may
occur
between
any
two
terminal
symbols
mentioned
in
the
grammar,
except
where
that
is
forbidden
by
the
/*
ws:
explicit
*/
annotation
in
the
EBNF,
or
by
the
/*
xgs:
xgc:
xml-version
*/
annotation.
Each imported schema or module is identified by its target namespace , which is the namespace of the objects (such as elements or functions) that are defined by the schema or module.
A terminal is a symbol or string or pattern that can appear in the right-hand side of a rule, but never appears on the left hand side in the main grammar, although it may appear on the left-hand side of a rule in the grammar for terminals.
A tuple is a set of zero or more named variables, each of which is bound to a value that is an XDM instance .
A tuple stream is an ordered sequence of zero or more tuples .
Each
element
node
and
attribute
node
in
an
XDM
instance
has
a
type
annotation
(referred
to
in
[XQuery/XPath
[XQuery
and
XPath
Data
Model
(XDM)]
(XDM)
1.1]
as
its
type-name
property.)
The
type
annotation
of
a
node
is
a
schema
type
that
describes
the
relationship
between
the
string
value
of
the
node
and
its
typed
value
.
A
variable
binding
may
be
accompanied
by
a
type
declaration
,
which
consists
of
the
keyword
as
followed
by
the
static
type
of
the
variable,
declared
using
the
syntax
in
2.5.3
SequenceType
Syntax
.
The
typed
value
of
a
node
is
a
sequence
of
atomic
values
and
can
be
extracted
by
applying
the
fn:data
function
to
the
node.
A type error may be raised during the static analysis phase or the dynamic evaluation phase. During the static analysis phase, a type error occurs when the static type of an expression does not match the expected type of the context in which the expression occurs. During the dynamic evaluation phase, a type error occurs when the dynamic type of a value does not match the expected type of the context in which the value occurs.
Under
certain
circumstances,
an
atomic
value
can
be
promoted
from
one
type
to
another.
Type
promotion
is
used
in
evaluating
function
calls
(see
3.1.5
Function
Calls
)
,
,
order
by
clauses
(see
3.8.3
3.8.8
Order
By
and
Return
Clauses
Clause
),
and
operators
that
accept
numeric
or
string
operands
(see
B.2
Operator
Mapping
).
In certain situations a value is said to be undefined (for example, the value of the context item, or the typed value of an element node). This term indicates that the property in question has no value and that any attempt to use its value results in an error.
Within this specification, the term URI refers to a Universal Resource Identifier as defined in [RFC3986] and extended in [RFC3987] with the new name IRI .
For
a
user-defined
function
,
the
function
declaration
includes
an
expression
called
the
User
defined
functions
are
functions
that
contain
a
function
body
that
defines
how
,
which
provides
the
result
implementation
of
the
function
is
computed
from
its
parameters.
as
an
XQuery
expression.
In the data model , a value is always a sequence .
A variable reference is a QName preceded by a $-sign.
Variable values . This is a set of (expanded QName, value) pairs. It contains the same expanded QNames as the in-scope variables in the static context for the expression. The expanded QName is the name of the variable and the value is the dynamic value of the variable, which includes its dynamic type .
Any
module
may
contain
a
A
version
declaration
.
If
present,
the
version
declaration
occurs
at
the
beginning
of
the
module
and
identifies
can
identify
the
applicable
XQuery
syntax
and
semantics
for
the
a
module
.
,
as
well
as
its
encoding.
In addition to static errors , dynamic errors , and type errors , an XQuery 1.1 implementation may raise warnings , either during the static analysis phase or the dynamic evaluation phase . The circumstances in which warnings are raised, and the ways in which warnings are handled, are implementation-defined .
A whitespace character is any of the characters defined by [http://www.w3.org/TR/REC-xml#NT-S] .
A window is a sequence of consecutive items drawn from the binding sequence .
The term XDM instance is used, synonymously with the term value , to denote an unconstrained sequence of nodes and/or atomic values in the data model .
XPath
1.0
compatibility
mode.
This
component
must
be
set
by
all
host
languages
that
include
XPath
2.0
2.1
as
a
subset,
indicating
whether
rules
for
compatibility
with
XPath
1.0
are
in
effect.
XQuery
sets
the
value
of
this
component
to
false
.
An XQuery 1.0 Processor processes a query according to the XQuery 1.0 specification.
An XQuery 1.1 Processor processes a query according to the XQuery 1.1 specification.
xs:anyAtomicType
is
an
atomic
type
that
includes
all
atomic
values
(and
no
values
that
are
not
atomic).
Its
base
type
is
xs:anySimpleType
from
which
all
simple
types,
including
atomic,
list,
and
union
types,
are
derived.
All
primitive
atomic
types,
such
as
and
xs:integer
,
xs:string
,
xs:decimal
,
have
xs:untypedAtomic
xs:string
xs:anyAtomicType
as
their
base
type.
xs:dayTimeDuration
is
derived
by
restriction
from
xs:duration
.
The
lexical
representation
of
xs:dayTimeDuration
is
restricted
to
contain
only
day,
hour,
minute,
and
second
components.
xs:untyped
is
used
as
the
type
annotation
of
an
element
node
that
has
not
been
validated,
or
has
been
validated
in
skip
mode.
xs:untypedAtomic
is
an
atomic
type
that
is
used
to
denote
untyped
atomic
data,
such
as
text
that
has
not
been
assigned
a
more
specific
type.
xs:yearMonthDuration
is
derived
by
restriction
from
xs:duration
.
The
lexical
representation
of
xs:yearMonthDuration
is
restricted
to
contain
only
year
and
month
components.
zero-digit specifies the character used for the digit-zero-sign; the default value is the digit zero (0). This character must be a digit (category Nd in the Unicode property database), and it must have the numeric value zero. This attribute implicitly defines the Unicode character that is used to represent each of the values 0 to 9 in the final result string: Unicode is organized so that each set of decimal digits forms a contiguous block of characters in numerical sequence.
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 distinct combinations of values.
Note:
This section needs to be rewritten in light of the new features of XQuery 1.1, which can significantly simplify some of these queries.
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")/items/item, $p in fn:doc("parts.xml")/parts/part[partno = $i/partno], $s in fn:doc("suppliers.xml")/suppliers /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")/suppliers/supplier order by $s/suppname return <supplier> { $s/suppname, for $i in fn:doc("catalog.xml")/items/item [suppno = $s/suppno], $p in fn:doc("parts.xml")/parts/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")/suppliers/supplier order by $s/suppname return <supplier> { $s/suppname, for $i in fn:doc("catalog.xml")/items/item [suppno = $s/suppno], $p in fn:doc("parts.xml")/parts/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")/parts/part where fn:empty(fn:doc("catalog.xml")/items/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.
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 := /report/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 := /report/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 /report/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
(note
that
the
element
constructor
in
case
$e
generates
attributes
before
child
elements):
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/@* except $e/@color, (: attr -> attr :) $e/size, (: elem -> attr :) $e/@color, (: attr -> elem :) $e/node() except $e/size ) (: elem -> elem :) 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"))
It
is
sometimes
necessary
to
search
through
a
set
of
data
to
find
all
the
distinct
combinations
of
a
given
list
of
properties.
For
example,
an
input
data
set
might
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
the
distinct
combinations
of
product
,
size
,
and
color
that
occur
together
in
an
order
.
The
following
query
returns
this
list,
enclosing
each
distinct
combination
in
a
new
element
named
option
:
for $p in fn:distinct-values(/orders/order/product), $s in fn:distinct-values(/orders/order/size), $c in fn:distinct-values(/orders/order/color) order by $p, $s, $c return if (fn:exists(/orders/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 ()
This
log
records
changes
specification
gives
considerable
flexibility
to
implementations
in
the
way
that
have
been
modules
are
implemented,
in
particular,
in
the
way
that
module
URIs
and
their
location
URIs
are
interpreted.
This
flexibility
is
intentional,
because
XQuery
implementations
are
designed
to
operate
in
a
wide
variety
of
environments,
and
some
of
those
environments
impose
constraints.
Nevertheless,
in
the
interests
of
interoperability,
the
Working
Group
hopes
that
it
will
be
useful
to
offer
some
suggestions
for
how
implementations
might
choose
to
interpret
the
specification,
in
the
absence
of
implementation
factors
that
make
a
different
interpretation
necessary.
Generally, Module URIs should be treated in the same way as other namespace URIs.
Query authors should use a string that is a legal absolute IRI. Implementors should accept any string of Unicode characters. Module URIs should be compared using the Unicode codepoint collation rather than any concept of semantic equivalence.
Implementations may provide mechanisms allowing the module URI to be used as input to a process that delivers the module as a resource, for example a catalog, module repository, or URI resolver. For interoperability, such mechanisms should not prevent the user from choosing an arbitrary URI for naming a module.
Similarly, implementations may perform syntactic transformations on the module URI to obtain the names of related resources, for example to implement a convention relating the name or location of compiled code to the module URI; but again, such mechanisms should not prevent the user from choosing an arbitrary module URI.
As with other namespace URIs, common practice is often to use module URIs whose scheme is "http" and whose authority part uses a DNS domain name under the control of the user.
The specifications allow, and some users might consider it good practice, for the module URI of a function library to be the same as the namespace URI of the XML vocabulary manipulated by the functions in that library.
The specifications allow several different modules with the same Module URI to participate in a query.
Although other interpretations are possible, it is suggested that in such cases implementations should require the names of global variables and functions to be unique within the query as a whole: that is, if two modules with the same module URI participate in a query, the names of their global variables and functions should not overlap.
If one module contains an "import module" declaration for the module URI M, then all global variables and functions declared in participating modules whose module URI is M should be accessible in the importing module, regardless whether the participation of the imported module was directly due to this "import module" declaration.
There should only be one instance of a global variable with any given name. For example, if a global variable V is initialized using an element constructor, then there should only be one instance of this element, even if the module in which V is declared is imported by several other modules.
(A different approach to this might be used in an environment where a group of modules can be compiled as a unit; in such cases a module used within the compiled unit might be considered distinct from an instance of the same module imported from elsewhere in the query.)
The term "location URIs" is used here to refer to the URIs in the "at" clause of an "import module" declaration.
Products
should
(by
default
or
at
user
option)
take
account
of
all
the
location
URIs
in
an
"import
module"
declaration,
treating
each
location
URI
as
a
reference
to
a
module
with
the
specified
module
URI.
Location
URIs
should
be
made
absolute
with
respect
to
the
static
base
URI
of
the
query
module
containing
the
"import
module"
declaration
where
they
appear.
The
mapping
from
location
URIs
to
module
source
code
or
compiled
code
MAY
be
done
in
any
way
convenient
to
the
implementation.
If
possible
given
the
product's
architecture,
security
requirements,
etc,
the
product
should
allow
this
document
since
to
fetch
the
Proposed
Recommendation
Draft
source
code
of
21
November
2006.
the
module
to
use
the
standard
web
mechanisms
for
dereferencing
URIs
in
standard
schemes
such
as
the
"http"
URI
scheme.
When the same absolutized location URI is used more than once, either in the same "import module" declaration or in different "import module" declarations within the same query, a single copy of the resource containing the module should be loaded. When different absolutized location URIs are used, each should result in a single module being loaded, unless the implementation is able to determine that the different URIs are references to the same resource. No error due to duplicate variable or functions names should arise from the same module being imported more than once, so long as the absolute location URI is the same in each case.
By default, implementations should report a static error if a location URI cannot be resolved. However, this is not intended to disallow recovery strategies being used if appropriate.
26 Oct 2009
Added support for higher order functions.
Rules
preventing
multiple
bindings
Applied
all
XQuery
2ed
errata.
Eliminated BindingExpression production - see http://www.w3.org/Bugs/Public/show_bug.cgi?id=6921.
Fixed two typos in Binary Operators table - see http://www.w3.org/Bugs/Public/show_bug.cgi?id=7048
Changed
syntax
of
outer
for,
which
now
uses
the
AllowingEmpty
production
in
the
for
clause.
Changed
definition
of
derives-from()
-
see
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6513.
Added support for private functions. Decided at meeting 381 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2008Oct/0152.html).
Changed
introductory
text
on
the
relationship
between
XQuery
and
XPath
to
list
the
cases
where
a
namespace
prefix
within
syntactically
valid
query
can
return
different
results
in
the
two
languages
-
see
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7163.
Added
note
to
illustrate
the
difference
between
grouping
in
SQL,
which
reduces
the
equivalent
of
a
module
have
been
clarified.
non-grouping
variable
to
one
representative
value,
and
grouping
in
XQuery,
which
binds
each
non-grouping
variable
to
a
sequence
containing
the
concatenated
values
of
that
variable
in
all
the
pre-grouping
tuples
that
were
assigned
to
that
group.
See
http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2008Jun/0200.html.
This
change
closes
Bugzilla
entry
3951.
Sections
affected:
Changed
conformance
section
to
make
full-axis
support
mandatory.
Added
note
saying
the
Working
Group
has
not
yet
decided
which
XQuery
1.1
features
are
optional.
Decided
8
Sep
2009.
Fixed
discussion
of
output
declarations
in
4.2
Module
Declaration
2.2.4
Serialization
,
.
Predeclared
the
output
namespace.
Corrects
errors
in
December
Working
Draft
-
see
http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2008Jun/0015.html.
Removed obsolete Latin-1, using ISO-8859-1 instead. See http://www.w3.org/Bugs/Public/show_bug.cgi?id=7797.
Modified context item declarations - see http://www.w3.org/Bugs/Public/show_bug.cgi?id=6272.
Modified variable declarations - see http://lists.w3.org/Archives/Member/w3c-xsl-query/2009May/0036.html.
13 Nov 2008
Unique names for windowing variables. In a FLWOR, all nine of the variables bound by a window clause must have distinct names. Requires a new error code. Decided in Telcon 376, 9/9/08.
Definition of Internal Functions. Adopt improvements in definition of internal functions, function body, as proposed in http://www.w3.org/Bugs/Public/show_bug.cgi?id=6133.
XQuery 1.1: Module imports. M.Kay proposal for relaxing constraints on module imports, in Query/2007Oct/0038. Some concerns relating to formal semantics, to be addressed later along with many other concerns about the future of the FS document. Approved in Telcon 373, 7/8/08.
Atomization in grouping clauses. In a group-by clause, the grouping variables should be bound to the pre-atomization values of the grouping keys. Requires change to explanation and example in group-by section. Editor is also instructed to insert an editor's note requesting public feedback on this (pre-atomization vs. post-atomization) issue. Decided in Telcon 376, 9/9/08. http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2008Sep/0033.html
Try/catch catches type errors raised during dynamic evaluation. Decided at XML Query WG Face-To-Face Meeting #381 http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2008Oct/0152.html
Incorporated Mike Kay's feedback on the validate expression found here: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2008Oct/0127.html.
Added properties for format decimal to the static context, adopted other changes suggested by John Snelson in http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2008Oct/0111.html
24 Oct 2008
Adopted John Snelson proposal relating to number formatting as specified here: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2008Jun/0111.html Adds "format declaration" to query prolog (impacts XQuery grammar). Approved in F2F at Edinburgh, week of 6/23/08.
Implement Snelson proposal on XQuery version declarations found at http://www.w3.org/Bugs/Public/show_bug.cgi?id=5804#c1. Change the definition so that an XQuery 1.1 processor must also provide an XQuery 1.0 processor (which it uses if there's an XQuery 1.0 declaration). (Changes item i.) Change to iii - remove the part that allows an XQuery 1.1 processor to reject a module with an XQuery 1.0 declaration.
Adopted Jonathan Robie proposal for Context item declaration: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2008Jun/0157.html
Adopted Robie Computed namespace constructor: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2008Jun/0179.html Raises an error if the parent of a computed namespace constructor is a document node (add this to 3.7.3.3, Document Node Constructors, Rule 3.) Also add a new node-kind: "namespace-node()" to node tests. Decided in F2F at Edinburgh, week of 6/23/08.
In a FLWOR, the count clause should be accepted as intermediate clause only (not initial clause). Requires change to grammar and draft document. Snelson was not present, will be given a chance to object. Decided in Telcon 376, 9/9/08.
3 Oct 2008
Added Robie try/catch proposal from Query/2008Jun/0170. Group approved the proposal, with minor revisions, to be added to XQuery 1.1. Text and examples relating to updates and/or scripting should be changed to non-normative notes (or deleted) since XQuery 1.1 does not include updates or scripting. Approved in F2F at Edinburgh, week of 6/23/08.
Adopted Michael Kay proposal to extend the "validate" expression to add optional ("as" typename)? following ValidationMode. As now, the operand expression must return exactly one document or element node. Approved in F2F at Oracle, week of 3/31/08. Resolves Bug 5472.
Adopted Don Chamberlin proposal for nondeterministic functions in Query/2008Mar/0084, as amended: Allow keywords on external function decls only. Support both "deterministic" and "nondeterministic". Default is nondeterministic. The compiler infers the property of internal functions by static analysis. Approved in F2F at Oracle, week of 3/31/08.
Adopted Don Chamberlin proposal on Defaults for external variables in Query/2008Mar/0092, as amended: Change "default" to ":=". Approved in F2F at Oracle, week of 3/31/08.
3 Sept 2008
Adopted Snelson proposal for simplified FLWOR syntax: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2008May/0043.html Decided in F2F at Edinburgh, week of 6/23/08.
Adopted Snelson proposal to add "count" clause to FLWOR: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2008Jun/0112.html Note: this proposal REVERSES the previous decision (Query/2008Mar/0080, 3/31/08) to add "at" to the return clause. Decided in F2F at Edinburgh, week of 6/23/08.
Adopted Don Chamberlin Outer For proposal in Query/2008Mar/0095, as amended: change keyword "ofor" to "outer" "for". Concern that this proposal provides no support for full outer join. People encouraged to submit new proposals for full outer join. Decided in F2F at Oracle, week of 3/31/08. (Note: this change was removed when we accepted the "allowing empty" syntax)
Add Note to group-by section on unexpected replication of LET-bindings after grouping (see Michael Kay comment in Query/2008Jun/0200). Advise users to use a separate FLWOR to bind the expression, and a nested FLWOR for grouping, like this: let $x := 47 return for $e in //emps group by $d := $e/dept return f($d, $x) Action on A-373-06 on DC to add this note. Decided in Telcon 373, 7/8/08.
28 May 2008
Added
4.11
Module
Import
3.8.7
Group
By
Clause
,
to
FLWOR
Expression.
Added
4.12
Namespace
Declaration
3.8.4
Window
Clause
,
and
error
code
XQST0033.
to
FLWOR
Expression.