xml editor
- Products
- Downloads
- Register
- Shop
- Resources
- Support
- Company
| Resources |
| xml editor | |||
| ||||
Comments may be used to provide informative annotation for an expression. Comments are lexical constructs only, and do not affect expression processing. Comments are strings, delimited by the symbols 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 :) 3 ExpressionsThis section discusses each of the basic kinds of expression. Each kind of expression has a name such as 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 XPath Grammar]. The highest-level symbol in the XPath grammar is XPath.
The XPath 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 ForExpr, QuantifiedExpr, IfExpr, and OrExpr. Each of these expressions is described in a separate section of this document. |
|
[Definition:] A literal is a direct syntactic representation of an atomic value. XPath supports two kinds of literals: numeric literals and string literals.
|
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 xdt:untypedAtomic
to a numeric type as specified in .
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.
Here are some examples of literal expressions:
data server software 
"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.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]. In general, the name of a constructor function for a given type is the same as the name of the type (including its namespace). For example:
xs:integer("12") returns the integer value twelve.xs:date("2001-08-25") returns an item whose type is xs:date and whose value represents the date 25th August 2001.xdt:dayTimeDuration("PT5H") returns an item whose type is xdt:dayTimeDuration and whose value represents a duration of five hours.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.
|
[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:
for expressions (3.7 For Expressions) and quantified expressions (3.9 Quantified Expressions).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.
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.
|
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.
|
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 XPath are defined in [XQuery 1.0 and XPath 2.0 Functions and Operators].Additional functions may be provided in the ·static context·. XPath per se does not provide a way to declare functions, but a host language may provide such a mechanism.
|
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:
The function conversion rules are used to convert an argument value to its expected type; that is, to the declared type of the function parameter. The expected type is expressed as a ·sequence type·. The function conversion rules are applied to a given value as follows:
true and an
argument is not of the expected type, then the
following conversions are
applied sequentially to the argument value V:xs:string, xs:string?, xdt:untypedAtomic, xdt:untypedAtomic?, node(), node()?, item(), item()?), then the value V is effectively replaced by V[1].xs:string or xs:string?,
then the value V is effectively
replaced by
fn:string(V).xs:double or xs:double?, then the value V is effectively replaced by
fn:number(V).*,
+, or ?), the following
conversions are applied:xdt:untypedAtomic is cast to the expected
atomic type. For ·built-in functions· where the expected type is specified as ·numeric·, arguments of type xdt:untypedAtomic are cast to xs:double.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.Since the arguments of a function call are separated by commas, any argument expression that contains a top-level ·comma operator· must be enclosed in parentheses. Here are some illustrative examples of function calls:
my:three-argument-function(1,
2, 3) denotes a function call with three arguments.my:two-argument-function((1,
2), 3) denotes a function call with two arguments, the first of which is a
sequence of two values.my:two-argument-function(1,
()) denotes a function call with two arguments, the second of which is an
empty sequence.my:one-argument-function((1, 2,
3)) denotes a function call with one argument that is a sequence of three
values. my:one-argument-function(( )) denotes a function call with one argument that is an empty sequence.my:zero-argument-function( ) denotes a function call with zero arguments.
3.2 Path Expressions
|
[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 fn:root(self::node()) treat as
document-node()/ (however, if the
"/" 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
fn:root(self::node()) treat as
document-node()/descendant-or-self::node()/ (however, "//" 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].
.
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:
E2 returns a (possibly empty) sequence of
nodes, these sequences are combined, and duplicate nodes are eliminated
based on node identity. The resulting node sequence is returned in ·document
order·.E2 returns a (possibly empty) sequence of
atomic values, these sequences are concatenated, in order, and returned. E2 return at least
one node and at least one atomic value, a ·type
error· is raised
[err:XPTY0018].
.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.
/" 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.
|
[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. 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]. . The resulting node sequence is returned in ·document 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.
XPath defines a full set of axes for traversing documents, but a host language may define a subset of these axes. The following axes are defined:
child axis
contains the children of the context
node, which are the nodes returned by
the dm:children accessor
in [XQuery/XPath Data Model (XDM)]. 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)parent
axis contains the sequence
returned by the
dm:parent
accessor in [XQuery/XPath Data Model (XDM)], which returns
the parent of the context
node, or an empty sequence
if the context node has no
parentancestor 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)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 or namespace node, the
following-sibling axis is
emptypreceding-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 or namespace node, the
preceding-sibling axis is
emptyfollowing 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·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·attribute axis
contains the attributes of the context node,
which are the nodes returned by the
dm:attributes accessor in
[XQuery/XPath Data Model (XDM)]; the axis will be
empty unless the context node is an
elementself axis contains just the context node itselfdescendant-or-self axis contains the context node and the descendants of the context
nodeancestor-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 nodenamespace axis
contains the namespace nodes of the
context node, which are the nodes
returned by the
dm:namespace-nodes accessor in
[XQuery/XPath Data Model (XDM)]; this axis
is empty unless the context node is an
element node. The
namespace axis is
deprecated in XPath 2.0. If ·XPath 1.0
compatibility mode· is true, the namespace axis must be supported. If ·XPath 1.0
compatibility mode· is false, then support for the
namespace axis is
·implementation-defined·. An implementation
that does not support the
namespace axis when ·XPath 1.0
compatibility mode· is false must raise
a ·static
error·
[err:XPST0010].
if it is
used. Applications needing information
about the ·in-scope namespaces· of an element
should use the functions
fn:in-scope-prefixes
and
fn:namespace-uri-for-prefix
defined in [XQuery 1.0 and XPath 2.0 Functions and Operators].Axes can be categorized as forward axes and reverse axes. An axis that only ever contains the context node or nodes that are after the context node in ·document order· is a forward axis. An axis that only ever contains the context node or nodes that are before the context node in ·document order· is a reverse axis.
The parent, ancestor, ancestor-or-self, preceding, and preceding-sibling axes are reverse axes; all other axes are forward axes. The ancestor, descendant, following, preceding and self axes partition a document (ignoring attribute and namespace nodes):
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:
In a sequence of nodes selected by an axis step, each node is assigned a context position that corresponds to its position in the sequence. If the axis is a forward axis, context positions are assigned to the nodes in ·document order·, starting with 1. If the axis is a reverse axis, context positions are assigned to the nodes in ·reverse document order·, starting with 1. This makes it possible to select a node from the sequence by specifying its position.
child::para[1] selects the
first para element that is a child of the context node.
[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.
|
[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 (on a codepoint basis) 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:XPST0008]. 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:XPST0008].
.
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.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.
|
[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. For each item in the sequence to be filtered, the predicate expression is evaluated using an
inner focus derived from that item, as described in
2.1.2 Dynamic Context. The result of the predicate expression is
coerced to a xs:boolean value, called the predicate truth value, as
described below. Those items for which the predicate truth value is true are retained, and those for which the predicate truth value is false are discarded.
The predicate truth value is derived by applying the following rules, in order:
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.Here are some examples of ·axis steps· that contain predicates:
chapter element that is a child
of the context node:child::chapter[2]
"toy" and whose color
attribute has the value "red":descendant::toy[attribute::color = "red"]
employee children of the context node
that have both a secretary child element and an assistant child element:child::employee[secretary][assistant]
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).
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 nodechild::* selects all element children of the context nodechild::text() selects all text node children of the context nodechild::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 nodeattribute::* selects all the attributes of the context nodeparent::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 nodeancestor::div selects all div ancestors of the context nodeancestor-or-self::div selects the div ancestors of the context node and, if the context node is a div element, the context node as welldescendant-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 wellself::para selects the context node if it is a para element, and otherwise returns an empty sequencechild::chapter/descendant::para selects the para element
descendants of the chapter element children of the context nodechild::*/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 nodechild::para[fn:position() = 1] selects the first para child of the context nodechild::para[fn:position() = fn:last()] selects the last para child of the context nodechild::para[fn:position() = fn:last()-1] selects the last but one para child of the context nodechild::para[fn:position() > 1] selects all the para children of the context node other than the first para child of the context nodefollowing-sibling::chapter[fn:position() = 1]selects the next chapter sibling of the context nodepreceding-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 nodechild::para[attribute::type eq "warning"]selects
all para children of the context node that have a type attribute with value warningchild::para[attribute::type eq 'warning'][fn:position() = 5]selects the fifth para child of the context node that has a type attribute with value warningchild::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 warningchild::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 Introductionchild::chapter[child::title] selects the chapter children of the context node that have one or more title childrenchild::*[self::chapter or self::appendix]
selects the chapter and appendix children of the context nodechild::*[self::chapter or
self::appendix][fn:position() = fn:last()] selects the
last chapter or appendix child of the context node
|
The abbreviated syntax permits the following abbreviations:
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.child unless the axis step contains an AttributeTest; in that case, the default axis is attribute. For example, the path expression section/para is an abbreviation for child::section/child::para, and the path expression section/@id 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·.// 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.//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... 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.., 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 nodetext() 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 nodepara[1] selects the first para child of the context nodepara[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 nodechapter//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 nodepara[@type="warning"] selects all para children of the context node that have a type attribute with value warningpara[@type="warning"][5] selects the fifth para child of the context node that has a type attribute with value warningpara[5][@type="warning"] selects the fifth para child of the context node if that child has a type attribute with value warningchapter[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 Introductionchapter[title] selects the chapter children of the context node that have one or more title childrenemployee[@secretary and @assistant] selects all
the employee children of the context node that have both a secretary attribute and
an assistant attributebook/(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.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. 3.3 Sequence ExpressionsXPath 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).
|
[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.
Here are some examples of expressions that construct sequences:
(10, 1, 2, 3, 4)
10, 1, 2, 3, 4.(10, (1, 2), (), (3, 4))
salary children of the context node followed by all bonus children.(salary, bonus)
$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.
10, 1, 2, 3, 4.(10, 1 to 4)
10.10 to 10
15 to 10
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)
|
[Definition:] A filter expression consists simply of a primary expression followed by zero or more ·predicates·. The result of the filter expression consists of all the items returned by the primary expression for which all the predicates are true. If no predicates are specified, the result is simply the result of the primary expression. 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:
$products[price gt 100]
to operator.)(1 to 100)[. mod 5 eq 0]
(21 to 29)[5]
$book:$book/(chapter | appendix)[fn:last()]
tiger:fn:doc("zoo.xml")/fn:id('tiger')
|
XPath provides the following operators for combining sequences of nodes:
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.intersect operator takes two node sequences as operands and returns a sequence
containing all the nodes that occur in both operands.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. The resulting sequence is returned in ·document order·.
If an operand
of union, intersect, or except contains an item that is not a node, a ·type error· is raised
[err:XPTY0004].
.
Here are some examples of expressions that combine sequences. Assume the existence of three element nodes that we will refer to by symbolic names A, B, and C. Assume that the variables $seq1, $seq2 and $seq3 are bound to the following sequences of these nodes:
$seq1 is bound to (A, B)$seq2 is bound to (A, B)$seq3 is bound to (B, C)Then:
$seq1 union $seq2 evaluates to the sequence (A, B). $seq2 union $seq3 evaluates to the sequence (A, B, C). $seq1 intersect $seq2 evaluates to the sequence (A, B). $seq2 intersect $seq3 evaluates to the sequence containing B only.$seq1 except $seq2 evaluates to the empty sequence.$seq2 except $seq3 evaluates to the sequence containing A only.In addition to the sequence operators described here, [XQuery 1.0 and XPath 2.0 Functions and Operators] includes functions for indexed access to items or sub-sequences of a sequence, for indexed insertion or removal of items in a sequence, and for removing duplicate items from a sequence.
3.4 Arithmetic ExpressionsXPath provides arithmetic operators for addition, subtraction, multiplication, division, and modulus, in their usual binary and unary forms.
|
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.)
The first step in evaluating an arithmetic expression is to evaluate its operands. The order in which the operands are evaluated is ·implementation-dependent·.
If ·XPath 1.0 compatibility mode· is true, each operand is evaluated by applying the following steps, in order:
xs:double value NaN, 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.xs:boolean, xs:string,
xs:decimal (including xs:integer), xs:float, or xdt:untypedAtomic, then it
is converted to the type xs:double by applying the fn:number function. (Note that fn:number returns the value NaN if its operand cannot be converted to a number.)If ·XPath 1.0 compatibility mode· is false, each operand is evaluated by applying the following steps, in order:
xdt: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].
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]. .
XPath 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], $arg1 idiv $arg2 is equivalent to ($arg1 div $arg2) cast as xs:integer? except for error cases.
Here are some examples of arithmetic expressions:
xs:decimal value -1.5, and the second expression returns the xs:integer value -1:-3 div 2 -3 idiv 2
xdt:dayTimeDuration:$emp/hiredate - $emp/birthdate
$unit-price - $unit-discount
-$bellcost + $whistlecost -($bellcost + $whistlecost)
3.5 Comparison ExpressionsComparison expressions allow two values to be compared. XPath provides three kinds of comparison expressions, called value comparisons, general comparisons, and node comparisons.
|
<" must be written as
"<".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:
xdt:untypedAtomic, it is cast to xs:string.xdt: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).After evaluation of the operands, 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].
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:
$book/author. The comparison is true only if the result of atomization is the value "Kennedy" as an instance of xs:string or xdt: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"
weight subelement, the value of the predicate is the empty sequence, and the product is not selected://product[weight gt 100]
my:hatsize and my:shoesize are both user-defined types that are derived by restriction from a primitive ·numeric· type:my:hatsize(5) eq my:shoesize(5)
The general comparison operators are =, !=, <, <=, >, and >=. General comparisons are existentially quantified comparisons that may be applied to operand sequences of any length. The result of a general comparison that does not raise an error is
always true or false.
If ·XPath 1.0 compatibility mode· is true, a general comparison is evaluated by applying the following rules, in order:
xs:boolean, then the other operand is converted to xs:boolean by taking its
·effective boolean value·.<, <=, >, or >=, then each item in both of the
operand sequences is converted to the type xs:double by applying the
fn:number function. (Note that fn:number returns the value NaN if its operand cannot be converted to a number.)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]xs:double by
applying the fn:number function.xs:string,
or if both atomic values are instances of xdt:untypedAtomic, then both
atomic values are cast to the type xs:string.xdt:untypedAtomic and the other is not an instance of xs:string, xdt:untypedAtomic, or any ·numeric· type, then the xdt:untypedAtomic value is
cast to the ·dynamic type· of the other value.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.If ·XPath 1.0 compatibility mode· is false, a general comparison is evaluated by applying the following rules, in order:
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]xdt:untypedAtomic and the other is an instance of a ·numeric· type, then the xdt:untypedAtomic value is cast to the type xs:double.xdt:untypedAtomic and the other is an instance of xdt:untypedAtomic or xs:string, then the xdt:untypedAtomic value (or values) is (are) cast to the type xs:string.xdt:untypedAtomic and the other is not an instance of xs:string, xdt:untypedAtomic, or any ·numeric· type, then the xdt:untypedAtomic value is
cast to the ·dynamic type· of the other value.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:
author subelement of $book1 is "Kennedy" as an instance of xs:string or xdt:untypedAtomic:$book1/author = "Kennedy"
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)
true. This example illustrates the fact that the = and != operators are not inverses of each other.(1, 2) = (2, 3) (1, 2) != (2, 3)
$a, $b, and $c are bound to element nodes with type annotation xdt:untypedAtomic, with ·string values· "1", "2", and "2.0" respectively. Then ($a, $b) = ($c, 3.0) returns false, because $b and $c are compared as strings. However, ($a, $b) = ($c, 2.0) returns true, because $b and 2.0 are compared as numbers.Node comparisons are used to compare two nodes, by their identity or by their ·document order·. The result of a node comparison is defined by the following rules:
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 Data Model (XDM)] for a definition of node identity.<< operator returns true if the left operand node precedes the right operand node in
·document order·; otherwise it returns false.>> 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:
/books/book[isbn="1558604820"] is /books/book[call="QA76.9 C3845"]
/transactions/purchase[parcel="28-451"] << /transactions/sale[parcel="33-870"]
3.6 Logical ExpressionsA 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.
|
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: | EBV2 =
true | EBV2 = false | error in EBV2 |
EBV1 =
true | true | false | error |
EBV1
= false | false | false | if ·XPath 1.0 compatibility mode· is true, then false; otherwise either false or error. |
| error in EBV1 | error | if ·XPath 1.0 compatibility mode· is true, then error; otherwise 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: | EBV2 =
true | EBV2 = false | error in EBV2 |
EBV1 =
true | true | true | if ·XPath 1.0 compatibility mode· is true, then true; otherwise either true or error. |
EBV1 =
false | true | false | error |
| error in EBV1 | if ·XPath 1.0 compatibility mode· is true, then error; otherwise either true or error. | error | error |
If ·XPath 1.0 compatibility mode· is true, the order in which the operands of a logical expression are evaluated is effectively prescribed. Specifically, it is defined that when there is no
need to evaluate the second operand in order to determine the result, then
no error can occur as a result of evaluating the second operand.
If ·XPath 1.0 compatibility mode· is false, the
order in which the operands of a logical expression are evaluated is
·implementation-dependent·. In this case, 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:
true:1 eq 1 and 2 eq 2
1 eq 1 or 2 eq 3
false or raise a ·dynamic error· (in ·XPath 1.0 compatibility mode·, the result must be false):1 eq 2 and 3 idiv 0 = 1
true or raise a
·dynamic error· (in ·XPath 1.0 compatibility mode·, the result must be true):1 eq 1 or 3 idiv 0 = 1
1 eq 1 and 3 idiv 0 = 1
In addition to and- and or-expressions, XPath provides a
function named fn:not that takes a general sequence as
parameter and returns a boolean value. The fn:not function
is defined in [XQuery 1.0 and XPath 2.0 Functions and Operators]. The
fn:not function reduces its parameter to an ·effective boolean value·. It then returns
true if the effective boolean value of its parameter is
false, and false if the effective boolean
value of its parameter is true. If an error is
encountered in finding the effective boolean value of its operand,
fn:not raises the same error.
3.7 For ExpressionsXPath provides an iteration facility called a for expression.
|
A for expression is evaluated as follows:
for expression uses multiple variables, it is first expanded to a set of nested for expressions, each of which uses only one variable. For example, the expression
for $x in X, $y in Y return $x + $y
is expanded to
for $x in X return
for $y in Y return $x + $y.for expression, the variable is called the range variable, the value of the expression that follows the in keyword is called the binding sequence, and the expression that follows the return keyword is called the return expression. The result of the for expression is obtained by evaluating the return expression once for each item in the binding sequence, with the range variable bound to that item. The resulting sequences are concatenated (as if by the ·comma operator·) in the order of the items in the binding sequence from which they were derived.
The following example illustrates the use of a for expression in restructuring an input document. The example is based on the following
input:
<bib>
<book>
<title>TCP/IP Illustrated</title>
<author>Stevens</author>
<publisher>Addison-Wesley</publisher>
</book>
<book>
<title>Advanced Programming
in the Unix Environment</title>
<author>Stevens</author>
<publisher>Addison-Wesley</publisher>
</book>
<book>
<title>Data on the Web</title>
<author>Abiteboul</author>
<author>Buneman</author>
<author>Suciu</author>
</book>
</bib>The following example transforms the input document into a list in
which each author's name appears only once, followed by a list of
titles of books written by that author. This example assumes that the
context item is the bib element in the input
document.
for $a in fn:distinct-values(/bib/book/author)
return (/bib/book/author[. = $a], /bib/book[author = $a]/title)The result of the above
expression consists of the following sequence of elements. The
titles of books written by a given author are listed after the
name of the author.
The ordering of author elements in the result is ·implementation-dependent· due to the semantics of the fn:distinct-values function.
<author>Stevens</author> <title>TCP/IP Illustrated</title> <title>Advanced Programming in the Unix environment</title> <author>Abiteboul</author> <title>Data on the Web</title> <author>Buneman</author> <title>Data on the Web</title> <author>Suciu</author> <title>Data on the Web</title>
The following example illustrates a for expression containing more than one variable:
for $i in (10, 20),
$j in (1, 2)
return ($i + $j)The result of the above expression, expressed as a sequence of numbers, is as follows: 11, 12, 21, 22
The scope of a variable bound in a for expression comprises all subexpressions of the for expression
that appear after the variable binding. The scope does not
include the expression to which the variable is bound. The following example illustrates how a variable binding may reference another variable bound earlier in the same for expression:
for $x in $z, $y in f($x)
return g($x, $y)return clause of a for expression
is the same as the focus for evaluation of the for expression itself. The
following example, which attempts to find the total value of a set of
order-items, is therefore incorrect:
fn:sum(for $i in order-item return @price * @qty)
fn:sum(for $i in order-item
return $i/@price * $i/@qty)for clause: 3.8 Conditional ExpressionsXPath supports a conditional expression based on the keywords if, then, and else.
|
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:
if ($widget1/unit-cost < $widget2/unit-cost) then $widget1 else $widget2
discounted, independently of its value:if ($part/@discounted) then $part/wholesale else $part/retail
3.9 Quantified ExpressionsQuantified expressions support existential and universal quantification. The
value of a quantified expression is always true or false.
|
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:
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.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.
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:
true if every part element has a discounted attribute (regardless of the values of these attributes):every $part in /parts/part satisfies $part/@discounted
true if at least
one employee element satisfies the given comparison expression:some $emp in /emps/employee satisfies
($emp/bonus > 0.25 * $emp/salary)(1, 2, 3) and (2, 3, 4). The expression beginning with some evaluates to true, and the expression beginning with every evaluates to false.some $x in (1, 2, 3), $y in (2, 3, 4)
satisfies $x + $y = 4every $x in (1, 2, 3), $y in (2, 3, 4)
satisfies $x + $y = 4true 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
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
3.10 Expressions on SequenceTypes·sequence types· are used in instance of, cast, castable, and treat expressions.
|
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:integerThis example returns true because the given value is an instance of the given type.5 instance of xs:decimalThis example returns true because the given value is an integer literal, and xs:integer is derived by restriction from xs:decimal.(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].
.
|
Occasionally
it is necessary to convert a value to a specific datatype. For this
purpose, XPath 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· and is not xs:NOTATION or xdt:anyAtomicType, optionally
followed by the occurrence indicator "?" to denote that an empty
sequence is permitted
[err:XPST0080].
. 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:
? is specified after the target type, the result of the
cast expression is an empty sequence.? is not specified after the target type, a ·type error· is raised
[err:XPTY0004].
.cast is supported for the combinations of
input type and target type listed in . 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].If the target type of a cast expression is xs:QName, or is a type that is derived from xs:QName or xs:NOTATION, the input expression must be a string literal; otherwise a ·static error·
[err:XPST0083].
is raised.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 xdt:untypedAtomic. The
input value is first converted to a value in the lexical space of the
target type by applying the whitespace normalization rules for the
target type (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 the resulting value does not satisfy all the facets of
the target type.cast is supported if
the target type is a non-primitive atomic type 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·.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·.
|
XPath
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· and is not xs:NOTATION or xdt:anyAtomicType, optionally
followed by the occurrence indicator "?" to denote that an empty
sequence is permitted
[err:XPST0080].
. The expression V castable
as T returns true if the value V can
be successfully cast into the target type T by using a
cast expression; otherwise it returns
false. The castable 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
For every atomic type in the ·in-scope schema types· (except xs:NOTATION and xdt: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 xdt: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 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; otherwise a static error
[err:XPST0083].
is raised. This rule is consistent with the semantics of cast expressions for these types, as defined in 3.10.2 Cast.
The following examples illustrate the use of constructor functions:
("2000-01-01" cast as
xs:date?).xs:date("2000-01-01")(($floatvalue * 0.2E-5) cast as xs:decimal?).xs:decimal($floatvalue * 0.2E-5)
xdt:dayTimeDuration value equal to 21 days. It is
equivalent to ("P21D" cast as xdt:dayTimeDuration?).xdt:dayTimeDuration("P21D")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")cast expression, if the ·default element/type
namespace· is "none". 17 cast as apple
apple(17)
|
XPath 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:
treat expression is type1. This enables the
expression to be used as an argument of a function that requires a
parameter of type1.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.$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].
.A.1 EBNFThe grammar of XPath uses the same simple Extended Backus-Naur Form (EBNF) notation as [XML 1.0] with the following minor differences.
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.
|
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:
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.A or nothing; optional A.A followed by B. This operator has higher precedence than alternation; thus A B | C D is identical to (A B) | (C D).A or B but not both.A but does not match B.A. Concatenation has higher precedence than alternation; thus A+ | B+ is identical to (A+) | (B+).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> */.
(/) * 5. The expression 5 *
/, on the other hand, is legal without parentheses.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.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)".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> */.
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.(: 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. A.2 Lexical structureThe 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.
A host language may choose 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.
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.
|
The following symbols are used only in the definition of terminal symbols; they are not terminal symbols in the grammar of A.1 EBNF.
|
XPath 2.0 expressions consist of terminal symbols and ·symbol separators·.
Terminal symbols are of two kinds: delimiting and non-delimiting.
[Definition:] The delimiting terminal symbols are: ",", "$", "(", ")", "=", "!=", "<=", ">", ">=", "<<", ">>", "::", "@", "..", "*", "[", "]", ".", "?", "-", "+", "<", Comment, "/", "//", ":"
[Definition:] The non-delimiting terminal symbols are: "return", "for", "in", "some", "every", "satisfies", "if", "then", "else", "eq", "ne", "lt", "le", "gt", "ge", "is", "child", "descendant", "attribute", "self", "descendant-or-self", "following-sibling", "following", "namespace", "parent", "ancestor", "preceding-sibling", "preceding", "ancestor-or-self", "empty-sequence", "item", "node", "document-node", "text", "comment", "processing-instruction", "schema-attribute", "element", "schema-element", IntegerLiteral, DecimalLiteral, DoubleLiteral, StringLiteral, "external", EscapeQuot, EscapeApos, QName, NCName, Char, Digits
[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: xml-version */ 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.
The XPath 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:
For [XML 1.1] processing, all of the following must be translated to a single #xA character:
[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.
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. A.3 Reserved Function NamesThe following names are not allowed as function names in an unprefixed form because expression syntax takes precedence.
attributecommentdocument-nodeelementempty-sequenceifitemnodeprocessing-instructionschema-attributeschema-elementtexttypeswitchtypeswitch is not used in XPath, it is considered a reserved function name for compatibility with XQuery. A.4 Precedence OrderThe grammar in A.1 EBNF normatively defines built-in precedence among the operators of XPath. 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) | left-to-right |
| 3 | for, some, every, if | left-to-right |
| 4 | or | left-to-right |
| 5 | and | left-to-right |
| 6 | eq, ne, lt, le, gt, ge, =, !=, <, <=, >, >=, is, <<, >> | left-to-right |
| 7 | to | left-to-right |
| 8 | +, - | left-to-right |
| 9 | *, div, idiv, mod | left-to-right |
| 10 | union, | | left-to-right |
| 11 | intersect, except | left-to-right |
| 12 | instance of | left-to-right |
| 13 | treat | left-to-right |
| 14 | castable | left-to-right |
| 15 | cast | left-to-right |
| 16 | -(unary), +(unary) | right-to-left |
| 17 | ?, *(OccurrenceIndicator), +(OccurrenceIndicator) | left-to-right |
| 18 | /, // | left-to-right |
| 19 | [ ], ( ), {} | left-to-right |
B.1 Type Promotion[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) and operators that accept numeric or string operands (see B.2 Operator Mapping). The following type promotions are permitted:
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.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.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.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:
$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.$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. B.2 Operator MappingThe operator mapping tables in this section list the combinations of types for which the various operators of XPath 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]. 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]. 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.
Any operator listed in the operator mapping tables may be validly
applied to an operand of type AT if the table calls for
an operand of type ET and
type-matches(ET, AT) is
true (see 2.5.4 SequenceType Matching). For
example, a table entry indicates that the gt operator may
be applied to two xs:date operands, returning
xs:boolean. Therefore, the gt operator may
also be applied to two (possibly different) subtypes of
xs:date, also returning xs:boolean.
[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-matches(ET, AT) is true where ET is any of the four numeric types. 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 | xdt:yearMonthDuration | op:add-yearMonthDuration-to-date(A, B) | xs:date |
| A + B | xdt:yearMonthDuration | xs:date | op:add-yearMonthDuration-to-date(B, A) | xs:date |
| A + B | xs:date | xdt:dayTimeDuration | op:add-dayTimeDuration-to-date(A, B) | xs:date |
| A + B | xdt:dayTimeDuration | xs:date | op:add-dayTimeDuration-to-date(B, A) | xs:date |
| A + B | xs:time | xdt:dayTimeDuration | op:add-dayTimeDuration-to-time(A, B) | xs:time |
| A + B | xdt:dayTimeDuration | xs:time | op:add-dayTimeDuration-to-time(B, A) | xs:time |
| A + B | xs:dateTime | xdt:yearMonthDuration | op:add-yearMonthDuration-to-dateTime(A, B) | xs:dateTime |
| A + B | xdt:yearMonthDuration | xs:dateTime | op:add-yearMonthDuration-to-dateTime(B, A) | xs:dateTime |
| A + B | xs:dateTime | xdt:dayTimeDuration | op:add-dayTimeDuration-to-dateTime(A, B) | xs:dateTime |
| A + B | xdt:dayTimeDuration | xs:dateTime | op:add-dayTimeDuration-to-dateTime(B, A) | xs:dateTime |
| A + B | xdt:yearMonthDuration | xdt:yearMonthDuration | op:add-yearMonthDurations(A, B) | xdt:yearMonthDuration |
| A + B | xdt:dayTimeDuration | xdt:dayTimeDuration | op:add-dayTimeDurations(A, B) | xdt:dayTimeDuration |
| A - B | numeric | numeric | op:numeric-subtract(A, B) | numeric |
| A - B | xs:date | xs:date | op:subtract-dates(A, B) | xdt:dayTimeDuration |
| A - B | xs:date | xdt:yearMonthDuration | op:subtract-yearMonthDuration-from-date(A, B) | xs:date |
| A - B | xs:date | xdt:dayTimeDuration | op:subtract-dayTimeDuration-from-date(A, B) | xs:date |
| A - B | xs:time | xs:time | op:subtract-times(A, B) | xdt:dayTimeDuration |
| A - B | xs:time | xdt:dayTimeDuration | op:subtract-dayTimeDuration-from-time(A, B) | xs:time |
| A - B | xs:dateTime | xs:dateTime | op:subtract-dateTimes(A, B) | xdt:dayTimeDuration |
| A - B | xs:dateTime | xdt:yearMonthDuration | op:subtract-yearMonthDuration-from-dateTime(A, B) | xs:dateTime |
| A - B | xs:dateTime | xdt:dayTimeDuration | op:subtract-dayTimeDuration-from-dateTime(A, B) | xs:dateTime |
| A - B | xdt:yearMonthDuration | xdt:yearMonthDuration | op:subtract-yearMonthDurations(A, B) | xdt:yearMonthDuration |
| A - B | xdt:dayTimeDuration | xdt:dayTimeDuration | op:subtract-dayTimeDurations(A, B) | xdt:dayTimeDuration |
| A * B | numeric | numeric | op:numeric-multiply(A, B) | numeric |
| A * B | xdt:yearMonthDuration | numeric | op:multiply-yearMonthDuration(A, B) | xdt:yearMonthDuration |
| A * B | numeric | xdt:yearMonthDuration | op:multiply-yearMonthDuration(B, A) | xdt:yearMonthDuration |
| A * B | xdt:dayTimeDuration | numeric | op:multiply-dayTimeDuration(A, B) | xdt:dayTimeDuration |
| A * B | numeric | xdt:dayTimeDuration | op:multiply-dayTimeDuration(B, A) | xdt: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 | xdt:yearMonthDuration | numeric | op:divide-yearMonthDuration(A, B) | xdt:yearMonthDuration |
| A div B | xdt:dayTimeDuration | numeric | op:divide-dayTimeDuration(A, B) | xdt:dayTimeDuration |
| A div B | xdt:yearMonthDuration | xdt:yearMonthDuration | op:divide-yearMonthDuration-by-yearMonthDuration (A, B) | xs:decimal |
| A div B | xdt:dayTimeDuration | xdt: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 | xdt:yearMonthDuration | xdt:yearMonthDuration | op:yearMonthDuration-equal(A, B) | xs:boolean |
| A eq B | xdt:dayTimeDuration | xdt:dayTimeDuration | op:dayTimeDuration-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 | op:hex-binary-equal(A, B) | xs:boolean |
| A eq B | xs:base64Binary | xs:base64Binary | op:base64-binary-equal(A, B) | 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 | xdt:yearMonthDuration | xdt:yearMonthDuration | fn:not(op:yearMonthDuration-equal(A, B)) | xs:boolean |
| A ne B | xdt:dayTimeDuration | xdt:dayTimeDuration | fn:not(op:dayTimeDuration-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 | fn:not(op:hex-binary-equal(A, B)) | xs:boolean |
| A ne B | xs:base64Binary | xs:base64Binary | fn:not(op:base64-binary-equal(A, B)) | 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 | xdt:yearMonthDuration | xdt:yearMonthDuration | op:yearMonthDuration-greater-than(A, B) | xs:boolean |
| A gt B | xdt:dayTimeDuration | xdt:dayTimeDuration | op:dayTimeDuration-greater-than(A, B) | 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 | xdt:yearMonthDuration | xdt:yearMonthDuration | op:yearMonthDuration-less-than(A, B) | xs:boolean |
| A lt B | xdt:dayTimeDuration | xdt:dayTimeDuration | op:dayTimeDuration-less-than(A, B) | 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 | xdt:yearMonthDuration | xdt:yearMonthDuration | fn:not(op:yearMonthDuration-less-than(A, B)) | xs:boolean |
| A ge B | xdt:dayTimeDuration | xdt:dayTimeDuration | fn:not(op:dayTimeDuration-less-than(A, B)) | 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 | xdt:yearMonthDuration | xdt:yearMonthDuration | fn:not(op:yearMonthDuration-greater-than(A, B)) | xs:boolean |
| A le B | xdt:dayTimeDuration | xdt:dayTimeDuration | fn:not(op:dayTimeDuration-greater-than(A, B)) | 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 the scope (range of applicability) of the various components in the static context and dynamic context.
C.1 Static Context
ComponentsThe following table describes the components of the static context. For each component, "global" indicates that the value of the component applies throughout an XPath expression, whereas "lexical" indicates that the value of the component applies only within the subexpression in which it is defined.
| Component | Scope |
|---|---|
| XPath 1.0 Compatibility Mode | global |
| Statically known namespaces | global |
| Default element/type namespace | global |
| Default function namespace | global |
| In-scope schema types | global |
| In-scope element declarations | global |
| In-scope attribute declarations | global |
| In-scope variables | lexical; for-expressions and quantified expressions can bind new variables |
| Context item static type | lexical |
| Function signatures | global |
| Statically known collations | global |
| Default collation | global |
| Base URI | global |
| Statically known documents | global |
| Statically known collections | global |
| Statically known default collection type | global |
C.2 Dynamic Context ComponentsThe following table describes how values are assigned to the various components of the dynamic context. All these components are initialized by mechanisms defined by the host language. For each component, "global" indicates that the value of the component remains constant throughout evaluation of the XPath expression, whereas "dynamic" indicates that the value of the component can be modified by the evaluation of subexpressions.
| Component | Scope |
|---|---|
| Context item | dynamic; changes during evaluation of path expressions and predicates |
| Context position | dynamic; changes during evaluation of path expressions and predicates |
| Context size | dynamic; changes during evaluation of path expressions and predicates |
| Variable values | dynamic; for-expressions and quantified expressions can bind new variables |
| Current date and time | global; must be initialized by implementation |
| Implicit timezone | global; must be initialized by implementation |
| Available documents | global; must be initialized by implementation |
| Available collections | global; must be initialized by implementation |
| Default collection | global; overwriteable by implementation |
The following items in this specification are ·implementation-defined·:
E.1 Normative References E.2 Non-normative References E.3 Background MaterialXPath is intended primarily as a component that can be used by other specifications. Therefore, XPath relies on specifications that use it (such as [XPointer] and [XSLT 2.0]) to specify conformance criteria for XPath in their respective environments. Specifications that set conformance criteria for their use of XPath must not change the syntactic or semantic definitions of XPath as given in this specification, except by subsetting and/or compatible extensions.
[Definition:] The Static Typing Feature is an optional feature of XPath that provides support for the static semantics defined in [XQuery 1.0 and XPath 2.0 Formal Semantics], and requires implementations to detect and report ·type errors· during the ·static analysis phase·. Specifications that use XPath may specify conformance criteria for use of the Static Typing Feature.
If an implementation does not support the ·Static Typing Feature·, but can nevertheless determine during the static analysis phase that an expression will necessarily raise a type error if evaluated at run time, the implementation may raise that error during the static analysis phase. The choice of whether to raise such an error at analysis time is ·implementation dependent·.
In some cases, the static typing rules defined in [XQuery 1.0 and XPath 2.0 Formal Semantics] are 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· 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 type than that inferred by the type inference rules in [XQuery 1.0 and XPath 2.0 Formal Semantics]. See for a formal definition of the constraints on static typing extensions.
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 within an ElementTest or an AttributeTest.
An implementation must raise a ·static error· if it encounters a reference to an axis that it does not support.
It is an error (the host language environment may define this error as either a ·static error· or a ·dynamic 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.
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 ·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.
The target type of a cast or castable expression must be an atomic type that is in the ·in-scope schema types· and is not xs:NOTATION or xdt:anyAtomicType, optionally followed by the occurrence indicator "?"; otherwise a ·static
error· is raised.
It is a ·static error· if a QName used in an expression contains a namespace prefix that cannot be expanded into a namespace URI by using the ·statically known namespaces·.
It is a ·static
error·
if the target type of a cast expression or constructor function is xs:QName or a type derived from xs:QName or xs:NOTATION, and the argument of the cast expression or constructor function is not a string literal.
This appendix provides a summary of the areas of incompatibility between XPath 2.0 and [XPath 1.0].
Three separate cases are considered:
I.1 Incompatibilities when Compatibility Mode is trueThe list below contains all known areas, within the scope of this specification, where
an XPath 2.0 processor running with compatibility mode set to true will produce different
results from an XPath 1.0 processor evaluating the same expression, assuming that the expression
was valid in XPath 1.0, and that the nodes in the source document have no type annotations other than
xdt:untyped and xdt:untypedAtomic.
Incompatibilities in the behavior of individual functions are not listed here, but are included in an appendix of [XQuery 1.0 and XPath 2.0 Functions and Operators].
Since both XPath 1.0 and XPath 2.0 leave some aspects of the specification implementation-defined, there may be incompatiblities in the behavior of a particular implementation that are outside the scope of this specification. Equally, some aspects of the behavior of XPath are defined by the host language.
A < B < C were
supported in XPath 1.0, but are not permitted by the XPath 2.0 grammar. In most cases such
comparisons in XPath 1.0 did not have the intuitive meaning, so it is unlikely that
they have been widely used in practice. If such a construct is found, an XPath 2.0 processor
will report a syntax error, and the construct can be rewritten as (A < B) < Cnumber function,
or implicitly say on a function call), certain strings that converted to the special value NaN
under XPath 1.0 will convert to values other than NaN under XPath 2.0. These include
any number written with a leading + sign, any number in exponential floating point
notation (for example 1.0e+9), and the strings INF and -INF.10div 3 was permitted in XPath 1.0,
but in XPath 2.0 must be written as 10 div 3. I.2 Incompatibilities when Compatibility Mode is falseEven when the setting of the XPath 1.0 compatibility mode is false, many XPath expressions will still produce the same results under XPath 2.0 as under XPath 1.0. The exceptions are described in this section.
In all cases it is assumed that the expression
in question was valid under XPath 1.0, that XPath 1.0 compatibility mode is false, and that all elements
and attributes are annotated with the types xdt:untyped and xdt:untypedAtomic
respectively.
In the description below, the terms node-set and number are used with their XPath 1.0 meanings, that is, to describe expressions which according to the rules of XPath 1.0 would have generated a node-set or a number respectively.
[1] to
explicitly select the first node in the node-set.< and > operators, when applied
to two strings, attempted to convert both the strings to numbers and then made a numeric
comparison between the results. In XPath 2.0, these operators perform a string comparison using the
default collating sequence. (If either value is numeric, however, the results are compatible
with XPath 1.0)number
function to perform an explicit conversion.xdt:untypedAtomic
(which will commonly be the case when a node in a schemaless document is supplied as the argument).
For example, the function call substring-before(10 div 3, ".") raises a type error under XPath 2.0, because the arguments
to the substring-before function must be strings rather than numbers. The XPath 1.0 behavior can be
restored by performing an explicit conversion to the required type using a constructor function
or cast.$node-set = true() was evaluated by converting the
node-set to a boolean and then performing a boolean comparison: so this expression would return true
if $node-set was non-empty. In XPath 2.0, this expression is handled in
the same way as other comparisons between a sequence and a singleton: it is true if
$node-set contains at least one node whose value, after atomization and conversion
to a boolean using the casting rules, is true.This means that if $node-set is empty, the result under XPath 2.0
will be false regardless of
the value of the boolean operand, and regardless of which operator is used.
If $node-set is non-empty, then in most cases the comparison with a boolean is
likely to fail, giving a dynamic error. But if a node has the value "0",
"1", "true", or "false", evaluation of the expression may succeed.4 = true() was true; 4 = "+4" was false (because
the string +4 converts to NaN), and false = "false" was
false (because the string "false" converts to the boolean true).
In XPath 2.0 all these comparisons are type errors.div operator when dividing two integers is now a value
of type decimal rather than double. The expression 10 div 0 raises an
error rather than returning positive infinity.xs:float and xs:double values.Infinity and -Infinity are no longer recognized as representations
of positive and negative infinity. Note also that while the number function
continues to convert all unrecognized strings to NaN, operations that cast a string
to a number react to such strings with a dynamic error.@width returns an empty sequence, then
in XPath 1.0 the result of @width+1 was NaN, while with XPath 2.0
it is (). This has the effect that a filter expression such as item[@width+1 != 2]
will select items having no width attribute under XPath 1.0, and will not select them
under XPath 2.0.xs:string, not xdt:untypedAtomic. This means that no implicit conversions
are applied if the value is used in a context where a number is expected. If a processing-instruction node is used as an operand of
an arithmetic operator, for example, XPath 1.0 would attempt to convert the string value of the node to a number (and deliver
NaN if unsuccessful), while XPath 2.0 will report a type error.A and
B,
B would not be evaluated if A was false. Similarly in the case of A or
B, B would not be evaluated if A was true. This is no longer
guaranteed with XPath 2.0: the implementation is free to evaluate the two
operands in either order or in parallel. This change has been made to give
more scope for optimization in situations where XPath expressions are
evaluated against large data collections supported by indexes. Implementations
may choose to retain backwards compatibility in this area, but they are not
obliged to do so. I.3 Incompatibilities when using a SchemaAn XPath expression applied to a document that has been processed against a schema will not always give the same results as the same expression applied to the same document in the absence of a schema. Since schema processing had no effect on the result of an XPath 1.0 expression, this may give rise to further incompatibilities. This section gives a few examples of the differences that can arise.
Suppose that the context node is an element node derived from
the following markup: <background color="red green blue"/>.
In XPath 1.0, the predicate [@color="blue"] would return false.
In XPath 2.0, if the color attribute is defined in a schema
to be of type xs:NMTOKENS, the same predicate will return true.
Similarly, consider the expression @birth < @death applied to the
element <person birth="1901-06-06" death="1991-05-09"/>. With XPath 1.0, this
expression would return false, because both attributes are converted to numbers, which returns
NaN in each case. With XPath 2.0, in the presence of a schema that annotates these
attributes as dates, the expression returns true.
Once schema validation is applied, elements and attributes cannot be used as operands and arguments
of expressions that expect a different data type. For example, it is no longer possible to apply the substring
function to a date to extract the year component, or to a number to extract the integer part. Similarly, if an attribute is
annotated as a boolean then it is not possible to compare it with the strings "true" or "false".
All such operations lead to type errors. The remedy when such errors occur is to introduce an explicit conversion, or
to do the computation in a different way. For example, substring-after(@temperature, "-") might be
rewritten as abs(@temperature).
In the case of an XPath 2.0 implementation that provides the static typing feature, many further type errors will
be reported in respect of expressions that worked under XPath 1.0. For example, an expression such as
round(../@price) might lead to a static type error because the processor cannot infer statically that
../@price is guaranteed to be numeric.
Schema validation will in many cases perform whitespace normalization on the contents of elements (depending on their type).
This will change the result of operations such as the string-length function.
Schema validation augments the data model by adding default values for omitted attributes and empty elements.
This log records the changes that have been made to this document since the Last Call Draft of 04 April 2005.
J.1 7 July 2005eq and ne are now defined for the xs:duration type.void is changed to empty-sequence.fn:subtract-dateTimes-yielding-dayTimeDuration becomes op:subtract-dateTimes
and fn:subtract-dates-yielding-dayTimeDuration becomes op:subtract-dates
(affects operator mapping table). J.2 15 September 2005xdt:untypedAtomic into the appropriate numeric type. This change defines overflow and underflow behavior for numeric literals. J.3 03 November 2005 (CR Draft)| XML Editor | XML Author | WYSIWYG Editors | Schema Editor | XSD Documentation | XSL/XSLT Editor | XQuery | XML Databases | SVN Client © 2002-2011 SyncRO Soft Ltd. All rights reserved. | Sitemap | Terms of Use | Privacy Policy | This website was created & generated with <oXygen/>® XML Editor | ||