W3C

XML Path Language (XPath) 2.0

W3C Working Draft 15 November 2002

This version:
http://www.w3.org/TR/2002/WD-xpath20-20021115
Latest version:
http://www.w3.org/TR/xpath20/
Previous versions:
http://www.w3.org/TR/2002/WD-xpath20-20020816/
http://www.w3.org/TR/2002/WD-xpath20-20020430/
http://www.w3.org/TR/2001/WD-xpath20-20011220/
Editors:
Anders Berglund (XSL WG), IBM Research <alrb@us.ibm.com>
Scott Boag (XSL WG), IBM Research <scott_boag@us.ibm.com>
Don Chamberlin (XML Query WG), IBM Almaden Research Center <chamberlin@almaden.ibm.com>
Mary F. Fernandez (XML Query WG), AT&T Labs <mff@research.att.com>
Michael Kay (XSL WG), Software AG <Michael.Kay@softwareag.com>
Jonathan Robie (XML Query WG), DataDirect Technologies <jonathan.robie@datadirect-technologies.com>
Jérôme Siméon (XML Query WG), Bell Labs, Lucent Technologies <simeon@research.bell-labs.com>

Abstract

XPath is a language for addressing parts of an XML document.

Status of this Document

This is a public W3C Working Draft for review by W3C Members and other interested parties. This section describes the status of this document at the time of its publication. It is a draft document and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress." A list of current public W3C technical reports can be found at http://www.w3.org/TR/.

This document is the result of joint work by the XSL and XML Query Working Groups, which are jointly responsible for XPath 2.0, a language derived from both XPath 1.0 and XQuery. The XPath 2.0 and XQuery 1.0 Working Drafts are generated from a common source. These languages are closely related, sharing much of the same expression syntax and semantics, and much of the text found in the two Working Drafts is identical.

This version of the document contains a new approach to backward compatibility with XPath Version 1.0, and new, more liberal rules for casting values to target types. Rules for matching values to types are now based strictly on type and element names rather than on structural subsumption. Several small changes have been made to the grammar in order to eliminate the need for reserved keywords. More detailed material has been included on error handling and optimization. A complete list of changes can be found in H Revision Log. Public feedback is invited on the open issues listed in this document, in particular on Issues 327 and 335.

This document is a work in progress. It contains many open issues, and should not be considered to be fully stable. Vendors who wish to create preview implementations based on this document do so at their own risk. While this document reflects the general consensus of the working groups, there are still controversial areas that may be subject to change.

Public comments on this document and its open issues are welcome. Comments should be sent to the W3C XPath/XQuery mailing list, public-qt-comments@w3.org (archived at http://lists.w3.org/Archives/Public/public-qt-comments/).

XPath 2.0 has been defined jointly by the XML Query Working Group (part of the XML Activity) and the XSL Working Group (part of the Style Activity).

Patent disclosures relevant to this specification may be found on the XSL Working Group's patent disclosure page at http://www.w3.org/Style/XSL/Disclosures.

Table of Contents

1 Introduction
2 Basics
    2.1 Expression Context
        2.1.1 Static Context
        2.1.2 Evaluation Context
    2.2 Input Functions
    2.3 Expression Processing
        2.3.1 Document Order
        2.3.2 Typed Value and String Value
    2.4 Types
        2.4.1 Type Checking
        2.4.2 SequenceType
            2.4.2.1 SequenceType Matching
        2.4.3 Type Conversions
            2.4.3.1 Atomization
            2.4.3.2 Effective Boolean Value
    2.5 Variable Bindings
    2.6 Errors and Conformance
        2.6.1 Errors
        2.6.2 Conformance
            2.6.2.1 Basic XPath
            2.6.2.2 Schema Import Feature
            2.6.2.3 Static Typing Feature
        2.6.3 Handling Dynamic Errors
        2.6.4 Errors and Optimization
3 Expressions
    3.1 Primary Expressions
        3.1.1 Literals
        3.1.2 Variables
        3.1.3 Parenthesized Expressions
        3.1.4 Function Calls
        3.1.5 Comments
    3.2 Path Expressions
        3.2.1 Steps
            3.2.1.1 Axes
            3.2.1.2 Node Tests
        3.2.2 Predicates
        3.2.3 Unabbreviated Syntax
        3.2.4 Abbreviated Syntax
    3.3 Sequence Expressions
        3.3.1 Constructing Sequences
        3.3.2 Combining Sequences
    3.4 Arithmetic Expressions
    3.5 Comparison Expressions
        3.5.1 Value Comparisons
        3.5.2 General Comparisons
        3.5.3 Node Comparisons
        3.5.4 Order Comparisons
    3.6 Logical Expressions
    3.7 For Expressions
    3.8 Conditional Expressions
    3.9 Quantified Expressions
    3.10 Expressions on SequenceTypes
        3.10.1 Instance Of
        3.10.2 Cast
        3.10.3 Castable
        3.10.4 Constructor Functions
        3.10.5 Treat
    3.11 Validate Expressions

Appendices

A Grammar
    A.1 Lexical structure
        A.1.1 Syntactic Constructs
        A.1.2 Lexical Rules
    A.2 BNF
    A.3 Reserved Function Names
    A.4 Precedence Order
B Type Promotion and Operator Mapping
    B.1 Type Promotion
    B.2 Operator Mapping
C References
    C.1 Normative References
    C.2 Non-normative References
    C.3 Background References
    C.4 Informative Material
D Glossary
E Conformance
F Backwards Compatibility with XPath 1.0 (Non-Normative)
G XPath 2.0 and XQuery 1.0 Issues (Non-Normative)
H Revision Log (Non-Normative)
    H.1 15 Nov 2002


1 Introduction

The primary purpose of XPath is to address parts of an [XML] document. XPath uses a compact, non-XML syntax to facilitate use of XPath within URIs and XML attribute values. XPath operates on the abstract, logical structure of an XML document, rather than its surface syntax. This logical structure is known as the data model, and is described in the [XQuery 1.0 and XPath 2.0 Data Model] document. XPath gets its name from its use of a path notation as in URLs for navigating through the hierarchical structure of an XML document.

XPath is designed to be embedded in a host language such as [XSLT 2.0] or [XQuery]. XPath has a natural subset that can be used for matching (testing whether or not a node matches a pattern); this use of XPath is described in [XSLT 2.0].

XQuery Version 1.0 is an extension of XPath Version 2.0. Any expression that is syntactically valid and executes successfully in both XPath 2.0 and XQuery 1.0 will return the same result in both languages. Since these languages are so closely related, their grammars and language descriptions are generated from a common source to ensure consistency, and the editors of these specifications work together closely.

XPath also depends on and is closely related to the following specifications:

This document specifies a grammar for XPath, using the same Basic EBNF notation used in [XML], except that grammar symbols always have initial capital letters. Unless otherwise noted (see A.1 Lexical structure), whitespace is not significant in the grammar. Grammar productions are introduced together with the features that they describe, and a complete grammar is also presented in the appendix [A Grammar].

In the grammar productions in this document, nonterminal symbols are underlined and literal text is enclosed in double quotes. Angle brackets are used to enclose tokens that must be recognized by using lexical look-ahead, as described in A.1 Lexical structure. For example, the following production describes the syntax of a function call:

[61]   FunctionCall   ::=   <QName "("> (Expr ("," Expr)*)? ")"

The production should be read as follows: A function call consists of a QName followed by an open-parenthesis (these tokens must be recognized together using lexical lookahead.) The open-parenthesis is followed by an optional argument list. The argument list (if present) consists of one or more expressions, separated by commas. The optional argument list is followed by a close-parenthesis.

[Ed. Note: A future version of this document will include links between terms (in bold font) and their definitions.]

2 Basics

The basic building block of XPath is the expression. The language provides several kinds of expressions which may be constructed from keywords, symbols, and operands. In general, the operands of an expression are other expressions. XPath is a functional language which allows various kinds of expressions to be nested with full generality. It is also a strongly-typed language in which the operands of various expressions, operators, and functions must conform to designated types.

Like XML, XPath is a case-sensitive language. All keywords in XPath use lower-case characters.

The value of an expression is always a sequence, which is an ordered collection of zero or more items. An item is either an atomic value or a node. An atomic value is a value in the value space of an XML Schema atomic type, as defined in [XML Schema] (that is, a simple type that is not a list type or a union type). A node conforms to one of the seven node kinds described in [XQuery 1.0 and XPath 2.0 Data Model]. Each node has a unique node identity. Some kinds of nodes have typed values, string values, and names, which can be extracted from the node. The typed value of a node is a sequence of zero or more atomic values. The string value of a node is a value of type xs:string. The name of a node is a value of type xs:QName.

A sequence containing exactly one item is called a singleton sequence. An item is identical to a singleton sequence containing that item. Sequences are never nested--for example, combining the values 1, (2, 3), and ( ) into a single sequence results in the sequence (1, 2, 3). A sequence containing zero items is called an empty sequence.

In this document, the namespace prefixes xs: and xsi: are considered to be bound to the XML Schema namespaces http://www.w3.org/2001/XMLSchema and http://www.w3.org/2001/XMLSchema-instance, respectively (as described in [XML Schema]), and the prefix fn: is considered to be bound to the namespace of XPath/XQuery functions, http://www.w3.org/2002/11/xquery-functions (described in [XQuery 1.0 and XPath 2.0 Functions and Operators]). In some cases, where the meaning is clear and namespaces are not important to the discussion, built-in XML Schema typenames such as integer and string are used without a namespace prefix. Also, this document assumes that the default function namespace is set to the namespace of XPath/XQuery functions, so function names appearing without a namespace prefix can be assumed to be in this namespace.

2.1 Expression Context

The expression context for a given expression consists of all the information that can affect the result of the expression. This information is organized into two categories called the static context and the evaluation context.

This section describes the context information used by XPath expressions, including the functions in the core function library. Other functions, outside the core function library, may require additional context information.

2.1.1 Static Context

The static context of an expression is the information that is available during static analysis of the expression, prior to its evaluation. This information can be used to decide whether the expression contains a static error.

XPath requires the information in the static context to be provided by the language environment in which the expression is being processed. Static context consists of the following components:

  • XPath 1.0 compatibility mode. This value is true if rules for backward compatibility with XPath Version 1.0 are in effect; otherwise it is false.

  • In-scope namespaces. This is a set of (prefix, URI) pairs. The in-scope namespaces are used for resolving prefixes used in QNames within the expression.

  • Default namespace for element and type names. This is a namespace URI. This namespace is used for any unprefixed QName appearing in a position where an element or type name is expected.

  • Default namespace for function names. This is a namespace URI. This namespace is used for any unprefixed QName appearing as the function name in a function call.

  • In-scope schema definitions. This is a set of (QName, type definition) pairs. It defines the set of types that are available for reference within the expression. It includes the built-in schema types and all globally-declared types in imported schemas. It may also include types declared in schemas associated with documents retrieved by input functions, as described in 2.2 Input Functions.

    Ed. Note: The importing of type definitions from input documents is still under discussion. The idea that the static context should be affected by run-time functions in an implementation-defined way remains controversial (see Issue 307.)

  • In-scope variables. This is a set of (QName, type) pairs. It defines the set of variables that have been declared and are available for reference within the expression. The QName represents the name of the variable, and the type represents its static data type.

  • In-scope functions. This part of the static context defines the set of functions that are available to be called from within an expression. Each function is uniquely identified by its QName and its arity (number of parameters). The static context maps QName and arity into a function signature, which specifies the static types of the function parameters and function result.

    For each atomic type in the in-scope schema definitions, there is a constructor function in the in-scope functions. Constructor functions are discussed in 3.10.4 Constructor Functions.

  • In-scope collations. This is a set of (URI, collation) pairs. It defines the names of the collations that are available for use in function calls that take a collation name as an argument. A collation may be regarded as an object that supports two functions: a function that given a set of strings, returns a sequence containing those strings in sorted order; and a function that given two strings, returns true if they are considered equal, and false if not.

  • Default collation. This is a collation. This collation is used by string comparison functions when no explicit collation is specified.

  • Base URI. This is an absolute URI, used by the fn:document function when resolving the relative URI of a document to be loaded, if no explicit base URI is supplied in the function call.

2.1.2 Evaluation Context

The evaluation context of an expression is defined as information that is available at the time the expression is evaluated. The evaluation context consists of all the components of the static context, and the additional components listed below.

The first three components of the dynamic context (context item, context position, and context size) are called the focus of the expression. The focus enables the processor to keep track of which nodes are being processed by the expression.

The focus for the outermost expression is supplied by the environment in which the expression is evaluated. Certain language constructs, notably the path expression E1/E2 and the predicate expression E1[E2], create a new focus for the evaluation of a sub-expression. In these constructs, E2 is evaluated once for each item in the sequence that results from evaluating E1. Each time E2 is evaluated, it is evaluated with a different focus. The focus for evaluating E2 is referred to below as the inner focus, while the focus for evaluating E1 is referred to as the outer focus. The inner focus exists only while E2 is being evaluated. When this evaluation is complete, evaluation of the containing expression continues with its original focus unchanged.

  • The context item is the item currently being processed. An item is either an atomic value or a node. When the context item is a node, it can also be referred to as the context node. The context item is returned by the expression ".". When an expression E1/E2 or E1[E2] is evaluated, each item in the sequence obtained by evaluating E1 becomes the context item in the inner focus for an evaluation of E2.

  • The context position is the position of the context item within the sequence of items currently being processed. It changes whenever the context item changes. Its value is always an integer greater than zero. The context position is returned by the expression fn:position(). When an expression E1/E2 or E1[E2] is evaluated, the context position in the inner focus for an evaluation of E2 is the position of the context item in the sequence obtained by evaluating E1. The position of the first item in a sequence is always 1 (one). The context position is always less than or equal to the context size.

  • The context size is the number of items in the sequence of items currently being processed. Its value is always an integer greater than zero. The context size is returned by the expression last(). When an expression E1/E2 or E1[E2] is evaluated, the context size in the inner focus for an evaluation of E2 is the number of items in the sequence obtained by evaluating E1.

  • Dynamic variables. This is a set of (QName, type, value) triples. It contains the same QNames as the in-scope variables in the static context for the expression. Each QName is associated with the dynamic type and value of the corresponding variable. The dynamic type associated with the value of a variable may be more specific than the static type associated with the same variable. The value of a variable is, in general, a sequence.

    The dynamic types and values of variables are provided by the host language environment in which an XPath expression is being evaluated.

  • Current date and time. This information represents an implementation-defined point in time during processing of a query or transformation. It can be retrieved by the fn:current-date, fn:current-time, and fn:current-dateTime functions. If invoked multiple times during the execution of a query or transformation, these functions always returns a consistent result.

  • Implicit timezone. This is the timezone to be used when a date, time, or dateTime value that does not have a timezone is used in a comparison or in any other operation. This value is an instance of dayTimeDuration that is implementation-defined. See [ISO 8601] for the range of legal values of a timezone.

  • Input sequence. The input sequence is sequence of nodes that can be accessed by the input function. It might be thought of as an "implicit input". The content of the input sequence is determined in an implementation-defined way.

2.2 Input Functions

XPath has a set of functions that provide access to input data. These functions are of particular importance because they provide a way in which an expression can reference a document or a collection of documents. The input functions are described informally here, and in more detail in [XQuery 1.0 and XPath 2.0 Functions and Operators].

The input sequence is a part of the evaluation context for an expression. The way in which nodes are assigned to the input sequence is implementation-defined. For example, one implementation might provide a fixed mapping from a directory system to the input sequence, another implementation might provide a graphical user interface that allows users to choose a data source for the input sequence, and a third implementation might support UNIX-style pipes, allowing the output of one query to become the input sequence for another query.

The input functions supported by XPath are as follows:

  • The fn:input function, which takes no parameters, returns the input sequence. For example, the expression fn:input()//customer returns all the customer elements that are descendants of nodes in the input sequence. If no input sequence has been bound, the fn:input function raises a dynamic error.

  • The fn:collection function returns the nodes found in a collection. A collection may be any sequence of nodes. A collection is identified by a string, which must be a valid URI. For example, the expression fn:collection("http://example.org")//customer identifies all the customer elements that are descendants of nodes found in the collection whose URI is http://example.org.

  • The fn:document function, when its first argument is a string containing a single URI that refers to an XML document, converts that document to a Data Model representation and returns its document node. The fn:document function can also be used to address multiple documents or document fragments; see [XQuery 1.0 and XPath 2.0 Functions and Operators] for details.

If a given input function is invoked repeatedly with the same arguments during the scope of a single query or transformation, each invocation returns the same result.

The input functions described in this section provide access to input documents or document fragments. If these documents or document fragments are associated with schemas, the type definitions contained in these schemas may be added to the in-scope schema definitions, in an implementation-defined way.

Ed. Note: The importing of type definitions from input documents is still under discussion. The idea that the static context should be affected by run-time functions in an implementation-defined way remains controversial (see Issue 307).

2.3 Expression Processing

XPath is defined in terms of the [XQuery 1.0 and XPath 2.0 Data Model] (referred to in this document simply as the Data Model), which represents information in the form of nodes and atomic values. Before an XPath expression can be processed, the input documents to be operated on by the expression must be represented in the Data Model. For example, an XML document can be converted to the Data Model by the following steps:

  1. The document can be parsed using an XML parser.

  2. The parsed document can be validated against one or more schemas. This process, which is described in [XML Schema], results in an abstract information structure called the Post-Schema Validation Infoset (PSVI). If a document has no associated schema, it can be validated against a permissive default schema that accepts any well-formed document.

  3. The PSVI can be transformed into the Data Model by a process described in [XQuery 1.0 and XPath 2.0 Data Model].

The above steps provide an example of how a Data Model instance might be constructed. A Data Model instance might also be synthesized directly from a relational database, or constructed in some other way. XPath is defined in terms of operations on the Data Model, but it does not place any constraints on how the input Data Model instance is constructed.

Each element or attribute node in the Data Model has an annotation that indicates its dynamic type. If the Data Model was derived from an input XML document, the dynamic types of the elements and attributes are derived from schema validation. The dynamic type of an element or attribute indicates its range of values--for example, an attribute named version might have the dynamic type xs:decimal, indicating that it contains a decimal value.

The value of an attribute is represented directly within the attribute node. An attribute node whose type is unknown (such as might occur in a schemaless document) is annotated with the dynamic type xs:anySimpleType.

The value of an element is represented by the children of the element node, which may include text nodes and other element nodes. The dynamic type of an element node indicates how the values in its child text nodes are to be interpreted. An element whose type is unknown (such as might occur in a schemaless document) is annotated with the type xs:anyType.

Atomic values in the Data Model also carry dynamic type annotations. An atomic value of unknown type is annotated with the type xs:anySimpleType. Under certain circumstances (such as during processing of an arithmetic operator), an atomic value of xs:anySimpleType may be cast into a more specific type (such as xs:double).

This document provides a description of how each kind of expression is processed. For each expression, the operands and result are instances of the Data Model. The details of transforming XML documents into the Data Model are described in [XQuery 1.0 and XPath 2.0 Data Model]. Rules for serialization of a Data Model instance in the form of an XML document remain to be specified.

The terms document order, typed value, and string value are described here because they are of particular importance for the processing of expressions.

2.3.1 Document Order

Document order defines a total ordering among all the nodes seen by the language processor. Informally, document order corresponds to a depth-first, left-to-right traversal of the nodes in the Data Model.

Within a given document, the document node is the first node, followed by element nodes, text nodes, comment nodes, and processing instruction nodes in the order of their representation in the XML form of the document (after expansion of entities). Element nodes occur before their children, and the children of an element node occur before its following siblings. The namespace nodes of an element immediately follow the element node, in implementation-defined order. The attribute nodes of an element immediately follow its namespace nodes, and are also in implementation-defined order.

The relative order of nodes in distinct documents is implementation-defined but stable within a given query or transformation. In other words, given two distinct documents A and B, if a node in document A is before a node in document B, then every node in document A is before every node in document B. The relative order among free-floating nodes (those not in a document) is implementation-defined.

2.3.2 Typed Value and String Value

Element, attribute, and text nodes have a typed value and a string value that can be extracted by calling the data function and the string function, respectively. The typed value of a node is a sequence of atomic values, and the string value of a node is a string. Element and attribute nodes also have a type annotation, which is a QName that is defined in the in-scope schema definitions.

The typed value and string value for each kind of node are defined by the dm:typed-value and dm:string-value accessors in [XQuery 1.0 and XPath 2.0 Data Model]. Specifically:

  1. The typed value of a text node is the same as its string value, as an instance of xs:anySimpleType.

  2. If the type annotation of an attribute node is xs:anySimpleType, its typed value is equal to its string value, as an instance of xs:anySimpleType. Otherwise, its typed value is derived from its string value and type annotation in a way that is consistent with schema validation, as described in [XQuery 1.0 and XPath 2.0 Data Model].

    • Example: A2 is a validated attribute with type annotation IDREFS, which is a list type derived from IDREF. Its string value is "bar baz faz". The typed value of A2 is a sequence of three atomic values ("bar", "baz", "faz"), each of type IDREF.

  3. If the type annotation of an element node is xs:anyType, its typed value is equal to its string value, as an instance of xs:anySimpleType. Otherwise, its typed value is derived from its string value and type annotation in a way that is consistent with schema validation, as described in [XQuery 1.0 and XPath 2.0 Data Model]. If the type annotation of an element denotes a type with complex content (i.e., a type that permits subelements), its typed value is undefined, and the data function raises an error when applied to such an element.

    • Example: E2 is a validated element node with the type annotation hatsizelist, which is a type whose content is defined as a sequence of items of type hatsize, which in turn is derived from xs:integer. The string value of E2 is "7 8 9". The typed value of E2 is a sequence of three values (7, 8, 9), each of type hatsize.

    • Example: E3 is a validated element node with the type annotation weather, which is a complex type that permits subelements. The string value of E3 is "hot". Even though E3 does not happen to contain any subelements, its typed value is undefined because its type permits subelements.

2.4 Types

XPath is a strongly typed language with a type system based on [XML Schema]. The built-in types of XPath include the built-in atomic types of [XML Schema] (such as xs:integer and xs:string), and the following special derived types: fn:dayTimeDuration and fn:yearMonthDuration (described in [XQuery 1.0 and XPath 2.0 Functions and Operators]). Additional type definitions may be imported from the language environment via the in-scope schema definitions.

When the type of a value is not appropriate for the context in which it is used, a type error is raised. A type error may be detected and reported during the analysis phase or during the evaluation phase, as described in 2.4.1 Type Checking.

The XPath type system is formally defined in [XQuery 1.0 Formal Semantics]. This section presents a summary of types from a user's perspective.

2.4.1 Type Checking

XPath defines two phases of processing called the analysis phase and the evaluation phase.

The analysis phase depends on the query expression itself and on the static context. The analysis phase does not depend on any input data. The purpose of type-checking during the analysis phase is to provide early detection of type errors and to compute the type of a query result.

During the analysis phase, each expression is assigned a static type. In some cases, the static type is derived from the lexical form of the expression; for example, the static type of the literal 5 is xs:integer. In other cases, the static type of an expression is inferred according to rules based on the static types of its operands; for example, the static type of the expression size < 5 is xs:boolean. The static type of an expression may be either a named type or a structural description--for example, xs:boolean? denotes an optional occurrence of the xs:boolean type. The rules for inferring the static types of various expressions are described in [XQuery 1.0 Formal Semantics]. During the analysis phase, if an operand of an expression is found to have a static type that is not appropriate for that operand, a type error is raised. If static type checking raises no errors and assigns a static type T to an expression, then execution of the expression on valid input data is guaranteed either to produce a value of type T or to raise a dynamic error.

The evaluation phase is performed only after successful completion of the analysis phase. The evaluation phase depends on input data, on the expression being evaluated, and on the evaluation context. During the evaluation phase, a dynamic type is associated with each value as it is computed. The dynamic type of a value may be either a structural type (such as "sequence of integers") or a named type. The dynamic type of a value may be more specific than the static type of the expression that computed it (for example, the static type of an expression might be "zero or more integers or strings," but at run time its value may have the dynamic type "integer.") If an operand of an expression is found to have a dynamic type that is not appropriate for that operand, a type error is raised.

It is possible for static analysis of an expression to raise a type error, even though the expression might evaluate successfully on some valid input data. For example, an expression might contain a function that requires an element as its parameter, and the analysis phase might infer the static type of the function parameter to be an optional element. In this case, a type error would result, even though the function call would be successful for input data in which the optional element is present.

It is also possible for an expression to raise a dynamic error, even though analysis of the expression raised no static error. For example, an expression may contain a cast of a string into an integer, which is statically valid. However, if the actual value of the string at run time cannot be cast into an integer, a dynamic error will result. Similarly, an expression may apply an arithmetic operator to a value extracted from a schemaless document. This is not a static error, but at run time, if the value cannot be successfully cast to a numeric type, a dynamic error will be raised.

During the analysis phase, it may be desirable for an implementation to issue a warning if the static type assigned to an expression other than () is empty, indicating that the expression can never return a nonempty value. This can catch cases in which a query references an element or attribute that is not present, possibly due to a misspelling or misunderstanding. We suggest a warning rather than requiring an error because there are some situations in which a correct expression may have the type empty.

2.4.2 SequenceType

When it is necessary to refer to a type in an XPath expression, the syntax shown below is used. This syntax production is called "SequenceType", since it describes the type of an XPath value, which is a sequence.

[66]   SequenceType   ::=   (ItemType OccurrenceIndicator) |  "empty"
[67]   ItemType   ::=   (("element" |  "attribute") ElemOrAttrType?)
|  "node"
|  "processing-instruction"
|  "comment"
|  "text"
|  "document"
|  "item"
|  AtomicType
|  "untyped"
|  <"atomic" "value">
[68]   ElemOrAttrType   ::=   (QName (SchemaType |  SchemaContext?)) |  SchemaType
[69]   SchemaType   ::=   <"of" "type"> QName
[62]   SchemaContext   ::=   "context" SchemaGlobalContext ("/" SchemaContextStep)*
[63]   SchemaGlobalContext   ::=   QName |  <"type" QName>
[64]   SchemaContextStep   ::=   QName
[70]   AtomicType   ::=   QName
[71]   OccurrenceIndicator   ::=   ("*" |  "+" |  "?")?

Here are some examples of SequenceTypes that might be used in XPath expressions:

  • xs:date refers to the built-in Schema type date

  • attribute? refers to an optional attribute

  • element refers to any element

  • element office:letter refers to an element that has a specific name and that has been validated as conforming to the schema definition for that name

  • element of type po:address+ refers to one or more elements that have been validated as conforming to the schema definition of the given type

  • node* refers to a sequence of zero or more nodes of any type

  • item* refers to a sequence of zero or more nodes or atomic values

2.4.2.1 SequenceType Matching

During processing of a query, it is sometimes necessary to determine whether a given value matches a type that was declared using the SequenceType syntax. This process is known as SequenceType matching. For example, an instance of expression returns true if a given value matches a given type, or false if it does not.

SequenceType matching between a given value and a given SequenceType is performed as follows:

If the SequenceType is empty, the match succeeds only if the value is an empty sequence. If the SequenceType is an ItemType with no OccurrenceIndicator, the match succeeds only if the value contains precisely one item and that item matches the ItemType (see below). If the SequenceType contains an ItemType and an OccurrenceIndicator, the match succeeds only if the number of items in the value matches the OccurrenceIndicator and each of these items matches the ItemType. As a consequence of these rules, a value that is an empty sequence matches any SequenceType whose occurrence indicator is * or ?.

An OccurrenceIndicator indicates the number of items in a sequence, as follows:

  • ? indicates zero or one items

  • * indicates zero or more items

  • + indicates one or more items

The process of matching a given item against a given ItemType is performed as follows (remember that an item may be a node or an atomic value):

  1. The ItemType item matches any item. For example, item matches the atomic value 1 or the element <a/>.

  2. The following ItemTypes match atomic values:

    1. atomic value matches any atomic value.

    2. A named atomic type matches a value if the dynamic type of the value is the same as the named atomic type or is derived from the named atomic type by restriction. For example, the ItemType xs:decimal matches the value 12.34 (a decimal literal); it also matches a value whose dynamic type is shoesize, if shoesize is an atomic type derived from xs:decimal.

    3. untyped matches an atomic value whose most specific type is xs:anySimpleType.

  3. The following ItemTypes match nodes:

    1. node matches any node.

    2. text matches any text node.

    3. processing-instruction matches any processing instruction node.

    4. comment matches any comment node.

    5. document matches any document node.

    6. element matches an element node. Optionally, element may be followed by ElemOrAttrType, which places further constraints on the node (see below).

    7. attribute matches an attribute node. Optionally, attribute may be followed by ElemOrAttrType, which places further constraints on the node (see below).

An ElemOrAttrType may be used to place a constraint on the name or type of an element or attribute, as follows:

  1. One form of ElemOrAttrType, denoted by the phrase "of type", specifies the required type of the element or attribute node. The required type must be the QName of a simple or complex type that is found in the in-scope schema definitions. The match is successful only if the given element or attribute has a type annotation that is the same as the required type or is known (in the in-scope schema definitions) to be derived from the required type. For example, element of type Employee matches an element node that has been validated and has received the type annotation Employee. Similarly, attribute of type xs:integer matches an attribute node that has been validated and has received the type annotation xs:integer.

  2. Another form of ElemOrAttrType is simply a QName, which is interpreted as the required name of the element or attribute. The QName must be an element or attribute name that is found in the in-scope schema definitions. The match is successful only if the name of the given element or attribute is equal to the required name or is known (in the in-scope schema definitions) to be derived from the required name, and if the element or attribute has been validated.

    The constraint that an element must have a required name is considered to be satisfied if the element has been validated and found to be a member of a substitution group whose head element has the required name. Substitution groups are described in [XML Schema].

  3. The above two forms of ElemOrAttrType may be combined to specify both the required name and the required type of an element or attribute node, as in element person of type Employee or attribute color of type xs:integer. This form might be used, for example, to specify a required type that is more specific than the schema type associated with the required name.

In some cases, the required name of an element or attribute node may be locally declared (that is, declared inside a complex type in some schema.) In this case, the ElemOrAttrType may specify the SchemaContext in which the required name is to be interpreted. For example, element shippingAddress in invoice/customer matches an element node that conforms to the schema definition of the element name shippingAddress, as it would be interpreted inside a customer element that is inside an invoice element. The first QName in the SchemaContext must be found in the in-scope schema definitions.

2.4.3 Type Conversions

Some expressions do not require their operands to exactly match the expected type. For example, function parameters and returns expect a value of a particular type, but automatically perform certain type conversions, such as extraction of atomic values from nodes, promotion of numeric values, and implicit casting of untyped values. The conversion rules for function parameters and returns are discussed in 3.1.4 Function Calls. Other operators that provide special conversion rules include arithmetic operators, which are discussed in 3.4 Arithmetic Expressions, and value comparisons, which are discussed in 3.5.1 Value Comparisons.

2.4.3.1 Atomization

Type conversions sometimes depend on a process called atomization, which is used when a sequence of atomic values is required. The result of atomization is either a sequence of atomic values or a type error. Atomization of a sequence is defined as follows:

  • If every item in the input sequence is either an atomic value or a node whose typed value is a sequence of atomic values, then the result of atomization is the concatenated sequence of these atomic values.

  • Otherwise, atomization raises a type error.

Atomization may be used in processing the following types of expressions:

  • Arithmetic expressions

  • Comparison expressions

  • Function calls and returns

  • Cast expressions

2.4.3.2 Effective Boolean Value

If a sequence of items is encountered where a boolean value is expected, it is necessary to find its effective boolean value. The effective boolean value of a sequence is defined as the result of invoking the fn:boolean function on the sequence, as defined in [XQuery 1.0 and XPath 2.0 Functions and Operators].

The semantics of fn:boolean are repeated here for convenience. fn:boolean returns false if its operand is any of the following:

  • An empty sequence.

  • The boolean value false.

  • An empty string ("").

  • A numeric value that is equal to zero.

  • The double or float value NaN.

Otherwise, fn:boolean returns true.

The effective boolean value of a sequence may be computed during processing of the following types of expressions:

  • Logical expressions (and, or)

  • The fn:not function

  • Conditional expressions (if)

  • Quantified expressions (some, every)

2.5 Variable Bindings

Ed. Note: This section is still under review by the working group.

Certain kinds of expressions introduce named variables and bind them to values. For example, the following expression binds the variable $i successively to the values 1, 2, and 3, and uses each of these bindings to evaluate the nested expression $i * 2:

for $i in (1, 2, 3)
return $i * 2

In XPath, the kinds of expressions that can bind variables are for expressions (3.7 For Expressions) and quantified expressions (3.9 Quantified Expressions).

Expressions that bind variables can be nested, and an inner expression can contain references to variables bound in an outer expression. More formally, the rules for binding variables and for referring to bound variables in XPath are as follows:

  • The innermost expression that contains the defining occurrence of a variable name is called the containing expression for that variable. The expression that establishes the value to which a variable is bound is called the binding expression for that variable. A variable is in scope (and may thus be referenced) within any subexpression of its containing expression, with the following exceptions:

    • Its binding expression

    • Any expression that textually precedes its binding expression

  • Variables that share the same containing expression must have different names.

  • If two or more variables with the same name are in scope within the same expression, any variable reference with that name is interpreted as a reference to the variable that has the smallest containing expression.

  • The name of a variable is a QName, and variable names match if their expanded-QNames are the same--that is, if they have the same namespace and the same local name.

2.6 Errors and Conformance

2.6.1 Errors

As described in 2.4.1 Type Checking, XPath defines an analysis phase, which does not depend on input data, and an evaluation phase, which does depend on input data.

The result of the analysis phase is either success or one or more type errors and/or static errors. Type errors reported by the analysis phase occur when the static type of an expression is not correct for the context in which it appears. Static errors are non-type-related errors such as syntax errors. The means by which errors are reported during the analysis phase is implementation-defined.

The result of the evaluation phase is either a result value, a type error, or a dynamic error. Type errors are raised during the evaluation phase when the dynamic type of an expression is not correct for the context in which it appears. Dynamic errors are non-type-related errors such as numeric overflow. If evaluation of an expression yields a value (that is, it does not raise an error), the value must be the value specified by the dynamic semantics defined in [XQuery 1.0 Formal Semantics].

If an implementation can determine by static analysis that an expression will necessarily raise a dynamic error (for example, because it attempts to construct a decimal value from a constrant string that is not in the lexical space of xs:decimal), the implementation is allowed to report this error during the analysis phase (as well as during the evaluation phase).

[XQuery 1.0 Formal Semantics] defines the set of static, dynamic, and type errors. In addition to these errors, an XPath implementation may raise implementation-defined warnings, either during the analysis phase or the evaluation phase. The way in which warnings are raised and handled is implementation-defined.

In addition to the errors defined in this specification, an implementation may specify a list of resource-related limitations, such as maximum numbers or sizes of various objects. These limitations, and the consequences of exceeding them, are implementation-defined.

2.6.2 Conformance

XPath defines a basic conformance level named Basic XPath, and two optional features called the Schema Import Feature and the Static Typing Feature. A conforming implementation must satisfy the requirements of Basic XPath, and may also provide either or both of the optional features.

2.6.2.1 Basic XPath

A conforming Basic XPath implementation must implement the full XPath language, subject to the following limitations:

  1. In a Basic XPath implementation, the in-scope schema definitions consist of a fixed set of 48 predefined type definitions. These include the 44 built-in datatypes defined in [XML Schema], plus four additional types: fn:yearMonthDuration, fn:dayTimeDuration, xs:anySimpleType, and xs:anyType.

  2. A mapping from a Post-Schema Validation Infoset (PSVI) to the Data Model is specified in [XQuery 1.0 and XPath 2.0 Data Model]. In a Basic XPath implementation, this mapping maps each datatype that is not one of the 48 predefined types listed above into its nearest supertype that belongs to this list. As a result of this mapping, all complex types are mapped into xs:anyType. (Of course, mapping from a PSVI is only one way in which a Data Model instance might be constructed--other ways are also possible.)

  3. If any SequenceType contains an AtomicType that is not one of the 48 predefined types listed above, a Basic XPath implementation raises a static error.

  4. If any SequenceType contains an ElemOrAttrType, a Basic XPath implementation raises a static error.

  5. If the processing of an expression depends on the type of some value, and that type is not one of the 48 predefined types listed above, a Basic XPath implementation raises a dynamic error.

  6. A Basic XPath implementation is not required to raise type errors during the analysis phase. If an expression contains one or more non-type-related static errors, then a Basic XPath implementation must raise at least one of these static errors during the analysis phase. If the analysis phase is successful but one or more dynamic errors are encountered during the evaluation phase, then a Basic XPath implementation must raise at least one of these dynamic errors.

2.6.2.2 Schema Import Feature

The Schema Import Feature removes the limitations specified by Rules 1 through 5 of Basic XPath.

2.6.2.3 Static Typing Feature

The Static Typing Feature removes the limitation specified by Rule 6 of Basic XPath. An implementation that includes this feature is required to detect type errors during the analysis phase. If an expression contains one or more static errors or type errors, then a Static Typing implementation must raise at least one of these errors during the analysis phase.

Ed. Note: The Working Group is currently discussing the relationships among the various XPath features (for example, if an expression executes successfully on an implementation with Feature A, will it also execute successfully on an implementation with Feature B?). The Working Group is also discussing the issue of "type soundness" (that is, if the Static Typing Feature is implemented and a given expression raises no type errors during the analysis phase, what guarantees can be made about its behavior during the evaluation phase?). The editors expect to include more material on these issues in a future version of this document. (See Issue 308.)

2.6.3 Handling Dynamic Errors

Except as noted in this document, if any operand of an expression raises a dynamic error, the expression also raises a dynamic error. If an expression can validly return a value or raise a dynamic error, the implementation may choose to return the value or raise the dynamic error. For example, the logical expression expr1 and expr2 may return the value false if either operand returns false, or may raise a dynamic error if either operand raises a dynamic error.

If more than one operand of an expression may raise an error, the implementation may choose which error is raised by the expression. For example, in this expression:

($x div $y) + xs:decimal($z)

both ($x div $y) and xs:decimal($z) may raise an error. The implementation may choose which error is raised by the "+" expression. Once one operand raises an error, the implementation is not required, but is permitted, to evaluate any other operands.

A dynamic error carries an error value, which may be a single item or an empty sequence. For example, an error value might be an integer, a string, a QName, or an element. An implementation may provide a mechanism whereby an application-defined error handler can process error values and produce diagnostics; in the absence of such an error handler, the string-value of the error value may be used directly as an error message.

A dynamic error may be raised by a built-in function or operator. For example, the input function raises an error if the input sequence is not defined in the evaluation context.

An error can be raised explicitly by calling the fn:error function, which only raises an error and never returns a value. The fn:error function takes an optional item as its parameter, which is used as the error value. For example, the following function call raises a dynamic error whose error value is a string:

fn:error(fn:concat("Unexpected value ", $v))

2.6.4 Errors and Optimization

Because different implementations may choose to evaluate or optimize an expression in different ways, the detection and reporting of dynamic errors is implementation dependent.

When an implementation is able to evaluate an expression without evaluating some subexpression, the implementation is never required to evaluate that subexpression solely to determine whether it raises a dynamic error. For example, if a function parameter is never used in the body of the function, an implementation may choose whether to evaluate the expression bound to that parameter in a function call.

In some cases, an optimizer may be able to achieve substantial performance improvements by rearranging an expression so that the underlying operations such as projection, restriction, and sorting are performed in a different order than that specified in [XQuery 1.0 Formal Semantics]. In such cases, dynamic errors may occur that could not have occurred if the expression were evaluated as written. For example, consider the following expression:

$N[@x castable as xs:date]
      [xs:date(@x) gt xs:date("2000-01-01")]

This expression cannot fail with a casting error if it is evaluated exactly as written. An implementation is permitted, however, to reorder the predicates to achieve better performance (for example, by taking advantage of an index). This reordering could cause the above expression to fail. However, an expression must not be rearranged in a way that causes it to return a non-error result that is different from the result defined by [XQuery 1.0 Formal Semantics].

To avoid unexpected errors caused by reordering of expressions, tests that are designed to prevent dynamic errors should be expressed using conditional expressions, as in the following example:

$N[if (@x castable as xs:date)
   then xs:date(@x) gt xs:date("2000-01-01")
   else false()]

In the case of a conditional expression, the implementation is required not to evaluate the then branch if the condition is false, and not to evaluate the else branch if the condition is true. Conditional expressions are the only kinds of expressions that provide guaranteed conditions under which a particular subexpression will not be evaluated.

3 Expressions

This section introduces each of the basic kinds of XPath expression. Each kind of expression has a name such as PathExpr, which is introduced on the left side of the grammar production that defines the expression. Since XPath is a composable language, each kind of expression is defined in terms of other expressions whose operators have a higher precedence. In this way, the precedence of operators is represented explicitly in the grammar.

The simplest kinds of expressions are introduced first, followed by more complex expressions. This order of presentation does not conform to the order of operator precedence. The complete grammar is presented in the appendix [A Grammar].

The highest-level symbol in the XPath grammar is ExprSequence, which is defined in 3.3.1 Constructing Sequences. The highest-level operator (that is, the kind of expression whose operators have lowest precedence) is OrExpr, which is defined in 3.6 Logical Expressions.

[13]   XPath   ::=   ExprSequence?
[15]   Expr   ::=   OrExpr

3.1 Primary Expressions

Primary expressions are the basic primitives of the language. They include literals, variables, function calls, and the use of parentheses to control precedence of operators.

[42]   PrimaryExpr   ::=   Literal |  FunctionCall |  ("$" VarName) |  ParenthesizedExpr
[10]   VarName   ::=   QName

3.1.1 Literals

A literal is a direct syntactic representation of an atomic value. XPath supports two kinds of literals: string literals and numeric literals.

[59]   Literal   ::=   NumericLiteral |  StringLiteral
[58]   NumericLiteral   ::=   IntegerLiteral |  DecimalLiteral |  DoubleLiteral
[1]   IntegerLiteral   ::=   Digits
[2]   DecimalLiteral   ::=   ("." Digits) |  (Digits "." [0-9]*)
[3]   DoubleLiteral   ::=   (("." Digits) |  (Digits ("." [0-9]*)?)) ("e" | "E") ("+" | "-")? Digits
[4]   StringLiteral
(ws: significant)
   ::=   ('"' (('"' '"') |  [^"])* '"') |  ("'" (("'" "'") |  [^'])* "'")

The value of a string literal is a singleton sequence containing an item whose primitive type is xs:string and whose value is the string denoted by the characters between the delimiting quotation marks. If the literal is delimited by single quotes, two adjacent single quote characters within the literal are interpreted as one single quote character. Similarly, if the literal is delimited by double quotes, two adjacent double quote characters within the literal are interpreted as one double quote character.

If a string literal is used inside the value of an attribute, the quote characters used to delimit the literal should be different from the quote characters that are used to delimit the attribute.

The value of a numeric literal containing no "." and no e or E character is a singleton sequence containing an item whose type is xs:integer and whose value is obtained by parsing the numeric literal according to the rules of the xs:integer datatype. The value of a numeric literal containing "." but no e or E character is a singleton sequence containing an item whose primitive type is xs:decimal and whose value is obtained by parsing the numeric literal according to the rules of the xs:decimal datatype. The value of a numeric literal containing an e or E character is a singleton sequence containing an item whose primitive type is xs:double and whose value is obtained by parsing the numeric literal according to the rules of the xs:double datatype.

Here are some examples of literal expressions:

  • "12.5" denotes the string containing the characters '1', '2', '.', and '5'.

  • 12 denotes the integer value twelve.

  • 12.5 denotes the decimal value twelve and one half.

  • 125E2 denotes the double value twelve thousand, five hundred.

The boolean values true and false can be represented by calls to the built-in functions fn:true() and fn:false(), respectively.

Values of other XML Schema built-in types can be constructed by calling the constructor for the given type. The constructors for XML Schema built-in types are defined in [XQuery 1.0 and XPath 2.0 Functions and Operators]. In general, the name of a constructor function for a given type is the same as the name of the type (including its namespace). For example:

  • xs:integer("12") returns the integer value twelve.

  • xs:date("2001-08-25") returns an item whose type is xs:date and whose value represents the date 25th August 2001.

  • fn:dayTimeDuration("PT5H") returns an item whose type is fn:dayTimeDuration and whose value represents a duration of five hours.

It is also possible to construct values of various types by using a cast expression. For example:

  • cast as hatsize(9) returns an item whose primitive value is the integer 9 and whose type is the user-defined type hatsize, derived from xs:integer.

3.1.2 Variables

A variable evaluates to the value to which its name is bound in the evaluation context. An expression containing an unbound variable raises a static error.

In XPath, the kinds of expressions that can bind variables are for expressions (3.7 For Expressions) and quantified expressions (3.9 Quantified Expressions). Variables can also be bound in the host language environment, outside the scope of an XPath expression.

3.1.3 Parenthesized Expressions

[60]   ParenthesizedExpr   ::=   "(" ExprSequence? ")"

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.

3.1.4 Function Calls

A function call consists of a QName followed by a parenthesized list of zero or more expressions, called arguments. The QName and number of arguments must match the name and arity of an in-scope function in the static context (see 2.1 Expression Context); otherwise, a static error is raised.

[61]   FunctionCall   ::=   <QName "("> (Expr ("," Expr)*)? ")"

A function call is evaluated as follows:

  1. Each argument expression is evaluated, producing an argument value.

  2. Each argument value is converted by applying the function conversion rules listed below.

  3. The function is executed using the converted argument values. The result is a value of the function's declared return type.

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 SequenceType. The function conversion rules are applied to a given value as follows:

  • If XPath 1.0 compatibility mode is true, then one of the following conversions is applied:

    1. If the expected type is a string, optional string, or derived from a string or optional string, then the given value V is effectively replaced by fn:string(fn:subsequence(V, 1, 1)).

    2. If the expected type is a numeric, optional numeric, or derived from a numeric or optional numeric, then the given value V is effectively replaced by fn:number(fn:subsequence(V, 1, 1)).

    3. If the expected type is a (possibly optional) node or item, then the given value V is effectively replaced by fn:subsequence(V, 1, 1).

    4. Otherwise, the given value is unchanged.

  • If the expected type is a sequence of an atomic type (possibly with an occurrence indicator *, +, or ?), the following conversions are applied:

    1. Atomization is applied to the given value, resulting in a sequence of atomic values.

    2. Each item in the atomic sequence that is of type xs:anySimpleType is cast to the required atomic type.

    3. For each numeric item in the atomic sequence that can be promoted to the expected atomic type using the promotion rules in B.1 Type Promotion, the promotion is done.

  • If, after the above conversions, the resulting value does not match the expected type according to the rules for SequenceType Matching, a type error is raised. Note that the rules for SequenceType Matching permit a value of a derived type to be substituted for a value of its base type.

A core library of functions is defined in [XQuery 1.0 and XPath 2.0 Functions and Operators]. Functions in this library may be invoked without a namespace prefix by assigning the default function namespace to the namespace of the function library.

The comma operator in XPath serves two purposes: it separates the arguments in a function call, and it separates items in an expression that constructs a sequence (see 3.3.1 Constructing Sequences). To distinguish these two uses, parentheses can be used to delimit the individual arguments of a function call. Here are some illustrative examples of function calls:

  • three-argument-function(1, 2, 3) denotes a function call with three arguments.

  • two-argument-function((1, 2), 3) denotes a function call with two arguments, the first of which is a sequence of two values.

  • two-argument-function(1, ()) denotes a function call with two arguments, the second of which is an empty sequence.

  • one-argument-function((1, 2, 3)) denotes a function call with one argument that is a sequence of three values.

  • one-argument-function(( )) denotes a function call with one argument that is an empty sequence.

  • zero-argument-function( ) denotes a function call with zero arguments.

3.1.5 Comments

XPath comments can be used to provide informative annotation. These comments are lexical constructs only, and do not affect the processing of an expression.

[5]   ExprComment   ::=   "{--" [^}]* "--}"

Comments may be used anywhere that ignorable whitespace is allowed, . See A.1 Lexical structure for the exact lexical states where comments are recognized.

The following is an example of a comment:

{-- Houston, we have a problem --}

Ed. Note: The EBNF should disallow "--}" within the comment, rather than "}".

3.2 Path Expressions

A path expression can be used to locate nodes within a tree. Because the XPath grammar is organized around the precedence of operators, the syntax for PathExpr also includes PrimaryExpr. In common usage, the term path expression denotes a PathExpr that is not simply a PrimaryExpr.

[31]   PathExpr   ::=   ("/" RelativePathExpr?) |  ("//" RelativePathExpr) |  RelativePathExpr
[32]   RelativePathExpr   ::=   StepExpr (("/" |  "//") StepExpr)*

A path expression consists of a series of one or more steps, separated by "/", and optionally beginning with "/" or "//". An initial "/" or "//" is an abbreviation for one or more initial steps that are implicitly added to the beginning of the path expression, as described below.

A path expression consisting of a single step is evaluated as described in 3.2.1 Steps.

In a path expression consisting of two or more steps, each occurrence of // is expanded as described in 3.2.4 Abbreviated Syntax, leaving a sequence of steps separated by /. This sequence of steps is then evaluated from left to right. Each operation E1/E2 is evaluated as follows: Expression E1 is evaluated, and if the result is not a sequence of nodes, a dynamic error is raised. The resulting sequence of nodes is sorted in document order, and duplicates are eliminated based on node identity. Each node resulting from the evaluation of E1 then serves in turn to provide an inner focus for an evaluation of E2, as described in 2.1.2 Evaluation Context. Each evaluation of E2 must result in a sequence of nodes; otherwise, a dynamic error is raised. The sequences of nodes resulting from all the evaluations of E2 are merged, eliminating duplicate nodes based on node identity and sorting the results in document order.

As an example of a path expression, child::div1/child::para selects the para element children of the div1 element children of the context node, or, in other words, the para element grandchildren of the context node that have div1 parents.

A "/" at the beginning of a path expression is an abbreviation for the initial step fn:root(self::node()). The effect of this initial step is to begin the path at the root node that contains the context node. If the context item is not a node, a dynamic error is raised.

A "//" at the beginning of a path expression is an abbreviation for the initial steps fn:root(self::node())/descendant-or-self::node(). The effect of these initial steps is to establish an initial node sequence that contains all nodes in the same hierarchy as the context node. This node sequence is then filtered by subsequent steps in the path expression. If the context item is not a node, a dynamic error is raised.

3.2.1 Steps

[33]   StepExpr   ::=   (ForwardStep |  ReverseStep |  PrimaryExpr) Predicates
[53]   ForwardStep   ::=   (ForwardAxis NodeTest) |  AbbreviatedForwardStep
[54]   ReverseStep   ::=   (ReverseAxis NodeTest) |  AbbreviatedReverseStep

A step generates a sequence of items and then filters the sequence by zero or more predicates. The value of the step consists of those items that satisfy the predicates. Predicates are described in 3.2.2 Predicates.

A step may consist of a primary expression (described in 3.1 Primary Expressions), a forward step, or a reverse step. A forward or reverse step always returns a sequence of nodes. A forward or reverse step might be thought of as beginning at the context node and navigating to those nodes that are reachable from the context node via a specified axis. Such a step has two parts: an axis, which defines the "direction of movement" for the step, and a node test, which specifies the node kind and/or name of the nodes to be selected by the step.

In the abbreviated syntax for a step, the axis can be omitted and other shorthand notations can be used as described in 3.2.4 Abbreviated Syntax.

The unabbreviated syntax for a forward or reverse step consists of the axis name and node test separated by a double colon. The result of the step consists of the nodes reachable from the context node via the specified axis that have the node kind and/or name specified by the node test. For example, the step child::para selects the para element children of the context node: child is the name of the axis, and para is the name of the element nodes to be selected on this axis. The available axes are described in 3.2.1.1 Axes. The available node tests are described in 3.2.1.2 Node Tests. Examples of steps are provided in 3.2.3 Unabbreviated Syntax and 3.2.4 Abbreviated Syntax.

3.2.1.1 Axes
[43]   ForwardAxis   ::=   <"child" "::">
|  <"descendant" "::">
|  <"attribute" "::">
|  <"self" "::">
|  <"descendant-or-self" "::">
|  <"following-sibling" "::">
|  <"following" "::">
|  <"namespace" "::">
[44]   ReverseAxis   ::=   <"parent" "::">
|  <"ancestor" "::">
|  <"preceding-sibling" "::">
|  <"preceding" "::">
|  <"ancestor-or-self" "::">

XPath defines a set of full set of axes for traversing documents, but a host language may define a subset of these axes. The following axes are defined:

  • the child axis contains the children of the context node

  • the descendant axis contains the descendants of the context node; a descendant is a child or a child of a child and so on; thus the descendant axis never contains attribute or namespace nodes

  • the parent axis contains the parent of the context node, if there is one

  • the ancestor axis contains the ancestors of the context node; the ancestors of the context node consist of the parent of context node and the parent's parent and so on; thus, the ancestor axis will always include the root node, unless the context node is the root node

  • the following-sibling axis contains all the following siblings of the context node; if the context node is an attribute node or namespace node, the following-sibling axis is empty

  • the preceding-sibling axis contains all the preceding siblings of the context node; if the context node is an attribute node or namespace node, the preceding-sibling axis is empty

  • the following axis contains all nodes, in the same document or document fragment as the context node, that are after the context node in document order, excluding any descendants and excluding attribute nodes and namespace nodes

  • the preceding axis contains all nodes, in the same document or document fragment as the context node, that are before the context node in document order, excluding any ancestors and excluding attribute nodes and namespace nodes

  • the attribute axis contains the attributes of the context node; the axis will be empty unless the context node is an element

  • the self axis contains just the context node itself

  • the descendant-or-self axis contains the context node and the descendants of the context node

  • the ancestor-or-self axis contains the context node and the ancestors of the context node; thus, the ancestor-or-self axis will always include the root node

  • the namespace axis contains the namespace nodes of the context node; this axis is empty unless the context node is an element node. The namespace axis is deprecated in XPath 2.0. Implementations may support the namespace axis for backward compatibility with XPath 1.0, but they are not required to do so. An implementation that does not support the namespace axis must raise a static error if it is used. Applications needing information about the namespaces of an element should use the functions fn:get-in-scope-namespaces and fn:get-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.

In XPath, 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.

In a sequence of nodes selected by a step, the context positions of the nodes are determined in a way that depends on the axis. If the axis is a forward axis, context positions are assigned to the nodes in document order. If the axis is a reverse axis, context positions are assigned to the nodes in reverse document order. In either case, the first context position is 1.

3.2.1.2 Node Tests

A node test is a condition that must be true for each node selected by a step. The condition may be based on the kind of the node (element, attribute, text, document, comment, processing instruction, or namespace) or on the name of the node.

[45]   NodeTest   ::=   KindTest |  NameTest
[46]   NameTest   ::=   QName |  Wildcard
[47]   Wildcard   ::=   "*" |  <NCName ":" "*"> |  <"*" ":" NCName>
[48]   KindTest   ::=   ProcessingInstructionTest
|  CommentTest
|  TextTest
|  AnyKindTest
[49]   ProcessingInstructionTest   ::=   <"processing-instruction" "("> StringLiteral? ")"
[50]   CommentTest   ::=   <"comment" "("> ")"
[51]   TextTest   ::=   <"text" "("> ")"
[52]   AnyKindTest   ::=   <"node" "("> ")"

Every axis has a principal node kind. If an axis can contain elements, then the principal node kind is element; otherwise, it is the kind of nodes that the axis can contain. Thus:

  • For the attribute axis, the principal node kind is attribute.

  • For the namespace axis, the principal node kind is namespace.

  • For all other axes, the principal node kind is element.

A node test that consists of a QName is called a name test. A name test is true if and only if the kind of the node is the principal node kind and the expanded-QName of the node is equal to the expanded-QName specified by the name test. For example, child::para selects the para element children of the context node; if the context node has no para children, it selects an empty set of nodes. attribute::abc:href selects the attribute of the context node with the QName abc:href; if the context node has no such attribute, it selects an empty set of nodes.

A QName in a name test is expanded into an expanded-QName using the in-scope namespaces in the expression context. An unprefixed QName used as a name test has the namespaceURI associated with the default element namespace in the expression context. It is a static error if the QName has a prefix that does not correspond to any in-scope namespace.

A name test is not satisfied by an element node whose name does not match the QName of the name test, even if it is in a substitution group whose head is the named element.

A node test * is true for any node of the principal node kind. For example, child::* will select all element children of the context node, and attribute::* will select all attributes of the context node.

A node test can have the form NCName:*. In this case, the prefix is expanded in the same way as with a QName, using the context namespace declarations. It is a static error if there is no namespace declaration for the prefix in the expression context. The node test will be true for any node of the principal node kind whose expanded-QName has the namespace URI to which the prefix expands, regardless of the local part of the name.

A node test can also have the form *:NCName. In this case, the node test is true for any node of the principal node kind whose local name matches the given NCName, regardless of its namespace.

The node test text() is true for any text node. For example, child::text() will select the text node children of the context node. Similarly, the node test comment() is true for any comment node, and the node test processing-instruction() is true for any processing instruction. The processing-instruction() test may have an argument that is a StringLiteral; in this case, it is true for any processing instruction whose target application is equal to the value of the StringLiteral.

A node test node() is true for any node whatsoever.

Note:

In order to be consistent with QName in XML, whitespace is not allowed in the Wildcard production. For instance "prefix:*" is allowed, but "prefix : *" is not allowed.

3.2.2 Predicates

[57]   Predicates   ::=   ("[" Expr "]")*

A predicate consists of an expression, called a predicate expression, enclosed in square brackets. A predicate serves to filter a sequence, retaining some items and discarding others. For each item in the sequence to be filtered, the predicate expression is evaluated using an inner focus derived from that item, as described in 2.1.2 Evaluation Context. The result of the predicate expression is coerced to a 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:

  1. If the value of the predicate expression is an atomic value of a numeric type, the predicate truth value is true if and only if the value of the predicate expression is equal to the context position.

  2. Otherwise, the predicate truth value is the Effective Boolean Value of the predicate expression.

Here are some examples of steps that contain predicates:

  • This example selects the second chapter element that is a child of the context node:

    child::chapter[2]
  • This example selects all the descendants of the context node whose name is "toy" and whose color attribute has the value "red":

    descendant::toy[attribute::color = "red"]
  • This example selects all the employee children of the context node that have a secretary subelement:

    child::employee[secretary]

A predicate can also be used with a primary expression that is not a forward or reverse step, as illustrated in the following example:

  • List all the integers from 1 to 100 that are divisible by 5. (See 3.3.1 Constructing Sequences for an explanation of the to operator.)

    (1 to 100)[. mod 5 eq 0]

3.2.3 Unabbreviated Syntax

This section provides a number of examples of path expressions in which the axis is explicitly specified in each step. The syntax used in these examples is called the unabbreviated syntax. In many common cases, it is possible to write path expressions more concisely using an abbreviated syntax, as explained in 3.2.4 Abbreviated Syntax.

  • child::para selects the para element children of the context node

  • child::* selects all element children of the context node

  • child::text() selects all text node children of the context node

  • child::node() selects all the children of the context node, whatever their node type

  • attribute::name selects the name attribute of the context node

  • attribute::* selects all the attributes of the context node

  • descendant::para selects the para element descendants of the context node

  • ancestor::div selects all div ancestors of the context node

  • ancestor-or-self::div selects the div ancestors of the context node and, if the context node is a div element, the context node as well

  • descendant-or-self::para selects the para element descendants of the context node and, if the context node is a para element, the context node as well

  • self::para selects the context node if it is a para element, and otherwise selects nothing

  • child::chapter/descendant::para selects the para element descendants of the chapter element children of the context node

  • child::*/child::para selects all para grandchildren of the context node

  • / selects the root of the node hierarchy that contains the context node

  • /descendant::para selects all the para elements in the same document as the context node

  • /descendant::list/child::member selects all the member elements that have a list parent and that are in the same document as the context node

  • child::para[fn:position() = 1] selects the first para child of the context node

  • child::para[fn:position() = fn:last()] selects the last para child of the context node

  • child::para[fn:position() = fn:last()-1] selects the last but one para child of the context node

  • child::para[fn:position() > 1] selects all the para children of the context node other than the first para child of the context node

  • following-sibling::chapter[fn:position() = 1]selects the next chapter sibling of the context node

  • preceding-sibling::chapter[fn:position() = 1]selects the previous chapter sibling of the context node

  • /descendant::figure[fn:position() = 42] selects the forty-second figure element in the document

  • /child::doc/child::chapter[fn:position() = 5]/child::section[fn:position() = 2]selects the second section of the fifth chapter of the doc document element

  • child::para[attribute::type="warning"]selects all para children of the context node that have a type attribute with value warning

  • child::para[attribute::type='warning'][fn:position() = 5]selects the fifth para child of the context node that has a type attribute with value warning

  • child::para[fn:position() = 5][attribute::type="warning"]selects the fifth para child of the context node if that child has a type attribute with value warning

  • child::chapter[child::title='Introduction']selects the chapter children of the context node that have one or more title children with string-value equal to Introduction

  • child::chapter[child::title] selects the chapter children of the context node that have one or more title children

  • child::*[self::chapter or self::appendix] selects the chapter and appendix children of the context node

  • child::*[self::chapter or self::appendix][fn:position() = fn:last()] selects the last chapter or appendix child of the context node

3.2.4 Abbreviated Syntax

[55]   AbbreviatedForwardStep   ::=   "." |  ("@" NameTest) |  NodeTest
[56]   AbbreviatedReverseStep   ::=   ".."

The abbreviated syntax permits the following abbreviations:

  1. The most important abbreviation is that child:: can be omitted from a step. In effect, child is the default axis. For example, a path expression section/para is short for child::section/child::para.

  2. There is also an abbreviation for attributes: 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.

  3. // is short for /descendant-or-self::node()/. For example, //para is short for /descendant-or-self::node()/child::para and so will select any para element in the document (even a para element that is a document element will be selected by //para since the document element node is a child of the root node); div1//para is short for div1/descendant-or-self::node()/child::para and so will select all para descendants of div1 children.

    Note that the path expression //para[1] does not mean the same as the path expression /descendant::para[1]. The latter selects the first descendant para element; the former selects all descendant para elements that are the first para children of their parents.

  4. A step consisting of . returns the context item. This is particularly useful in conjunction with //. For example, the path expression .//para returns all para descendant elements of the context node.

  5. A step consisting of .. is short for parent::node(). For example, ../title is short for parent::node()/child::title and so will select the title children of the parent of the context node.

Here are some examples of path expressions that use the abbreviated syntax:

  • para selects the para element children of the context node

  • * selects all element children of the context node

  • text() selects all text node children of the context node

  • @name selects the name attribute of the context node

  • @* selects all the attributes of the context node

  • para[1] selects the first para child of the context node

  • para[fn:last()] selects the last para child of the context node

  • */para selects all para grandchildren of the context node

  • /doc/chapter[5]/section[2] selects the second section of the fifth chapter of the doc

  • chapter//para selects the para element descendants of the chapter element children of the context node

  • //para selects all the para descendants of the document root and thus selects all para elements 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

  • . selects the context item

  • .//para selects the para element descendants of the context node

  • .. selects the parent of the context node

  • ../@lang selects the lang attribute of the parent of the context node

  • para[@type="warning"] selects all para children of the context node that have a type attribute with value warning

  • para[@type="warning"][5] selects the fifth para child of the context node that has a typeattribute with value warning

  • para[5][@type="warning"] selects the fifth para child of the context node if that child has a type attribute with value warning

  • chapter[title="Introduction"] selects the chapter children of the context node that have one or more title children with string-value equal to Introduction

  • chapter[title] selects the chapter children of the context node that have one or more title children

  • employee[@secretary and @assistant] selects all the employee children of the context node that have both a secretary attribute and an assistant attribute

  • book/(chapter|appendix)/section selects every section element that has a parent that is either a chapter or an appendix element, that in turn is a child of a book element that is a child of the context node.

  • book/fn:id(publisher)/name returns the same result as fn:id(book/publisher)/name.

3.3 Sequence Expressions

XPath supports operators to construct and combine sequences. A sequence is an ordered collection of zero or more items. An item may be an atomic value or a node. An item is identical to a sequence of length one containing that item. Sequences are never nested--for example, combining the values 1, (2, 3), and ( ) into a single sequence results in the sequence (1, 2, 3).

3.3.1 Constructing Sequences

[14]   ExprSequence   ::=   Expr ("," Expr)*
[24]   RangeExpr   ::=   AdditiveExpr ( "to"  AdditiveExpr )?

One way to construct a sequence is by using the comma operator, which evaluates each of its operands and concatenates the resulting values, in order, into a single result sequence.

An ExprSequence is not an expression in its own right, and in general it must be enclosed in parentheses when used in a context where an expression is expected. However, the parentheses may be omitted if the ExprSequence occurs at the top level of an XPath expression. Empty parentheses can be used to denote an empty sequence.

A sequence may contain duplicate values or nodes, but a sequence is never an item in another sequence. When a new sequence is created by concatenating two or more input sequences, the new sequence contains all the items of the input sequences and its length is the sum of the lengths of the input sequences.

Here are some examples of expressions that construct sequences:

  • This expression is a sequence of five integers:

    (10, 1, 2, 3, 4)
  • This expression constructs one sequence from the sequences 10, (1, 2), the empty sequence (), and (3, 4):

    (10, (1, 2), (), (3, 4))

    It evaluates to the sequence:

    10, 1, 2, 3, 4

  • This expression contains all salary children of the context node followed by all bonus children:

    (salary, bonus)
  • Assuming that $price is bound to the value 10.50, this expression:

    ($price, $price)

    evaluates to the sequence

    10.50, 10.50

A RangeExpr can be used to construct a sequence of consecutive integers. The to operator takes two operands, both of which have a required type of integer. A sequence is constructed containing the two integer operands and every integer between the two operands. If the first operand is less than the second, the sequence is in increasing order, otherwise it is in decreasing order.

  • This example uses a range expression as one operand in constructing a sequence:

    (10, 1 to 4)

    It evaluates to the sequence:

    10, 1, 2, 3, 4

  • This example constructs a sequence of length one:

    10 to 10

    It evaluates to a sequence consisting of the single integer 10.

3.3.2 Combining Sequences

[28]   UnionExpr   ::=   IntersectExceptExpr ( ("union" |  "|")  IntersectExceptExpr )*
[29]   IntersectExceptExpr   ::=   ValueExpr ( ("intersect" |  "except")  ValueExpr )*

XPath provides several operators for combining sequences of nodes. The union and | operators are equivalent. They take two node sequences as operands and return a sequence containing all the nodes that occur in either of the operands. The intersect operator takes two node sequences as operands and returns a sequence containing all the nodes that occur in both operands. The except operator takes two node sequences as operands and returns a sequence containing all the nodes that occur in the first operand but not in the second operand. All of these operators return their result sequences in document order without duplicates based on node identity. If an operand of union, intersect, or except contains an item that is not a node, a dynamic error is raised.

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 $seq1 is bound to a sequence containing A and B, $seq2 is also bound to a sequence containing A and B, and $seq3 is bound to a sequence containing B and C. Then:

  • $seq1 union $seq1 evaluates to a sequence containing A and B.

  • $seq2 union $seq3 evaluates to a sequence containing A, B, and C.

  • $seq1 intersect $seq1 evaluates to a sequence containing A and B.

  • $seq2 intersect $seq3 evaluates to a sequence containing B only.

  • $seq1 except $seq2 evaluates to the empty sequence.

  • $seq2 except $seq3 evaluates to a sequence containing A only.

In addition to the sequence operators described here,[XQuery 1.0 and XPath 2.0 Functions and Operators] includes functions for indexed access to items or sub-sequences of a sequence, for indexed insertion or removal of items in a sequence, and for removing duplicate values or nodes from a sequence.

3.4 Arithmetic Expressions

XPath provides arithmetic operators for addition, subtraction, multiplication, division, and modulus, in their usual binary and unary forms.

[25]   AdditiveExpr   ::=   MultiplicativeExpr ( ("+" |  "-")  MultiplicativeExpr )*
[26]   MultiplicativeExpr   ::=   UnaryExpr ( ("*" |  "div" |  "idiv" |  "mod")  UnaryExpr )*
[27]   UnaryExpr   ::=   ("-" |  "+")* UnionExpr
[30]   ValueExpr   ::=   ValidateExpr |  CastExpr |  TreatExpr |  PathExpr

The binary 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 will be interpreted as an arithmetic operation.

An arithmetic expression is evaluated by applying the following rules, in order, until an error is raised or a value is computed:

  1. Atomization is applied to each operand. If the resulting value is not an empty sequence or a single atomic value, then a type error is raised.

  2. If either operand is an empty sequence, the result of the operation is an empty sequence.

  3. If XPath 1.0 compatibility mode is true, and an operand is not of a numeric type, then that operand is converted according to the rules in 3.1.4 Function Calls as if it were a function argument with the expected type xs:double.

  4. If an operand has the most specific type xs:anySimpleType, it is cast to xs:double. If the cast fails, a type error is raised.

  5. If the operand type(s) are valid for the given operator, the operator is applied to the operand(s), resulting in an atomic value or a dynamic error (for example, an error might result from dividing by zero.) The combinations of atomic types that are accepted by the various arithmetic operators, and their respective result types, are listed in B.2 Operator Mapping together with the functions in [XQuery 1.0 and XPath 2.0 Functions and Operators] that define the semantics of the operation for each type. If the operand type(s) are not valid for the given operator, a type error is raised.

XPath supports two division operators named div and idiv. The div operator accepts operands of any numeric types. The result of the div operator is the least common type of its operands; however, if both operands are of type xs:integer, div returns a result of type xs:double. The idiv operator, on the other hand, requires its operands to be of type xs:integer and returns a result of type xs:integer, rounded toward zero.

Here are some examples of arithmetic expressions:

  • The first expression below returns -1.5E0, and the second expressions returns -1:

    -3 div 2
    -3 idiv 2
  • Subtraction of two date values results in a value of type fn:dayTimeDuration:

    $emp/hiredate - $emp/birthdate
  • This example illustrates the difference between a subtraction operator and a hyphen:

    $unit-price - $unit-discount
  • Unary operators have higher precedence than binary operators, subject of course to the use of parentheses:

    -($bellcost + $whistlecost)

3.5 Comparison Expressions

Comparison expressions allow two values to be compared. XPath provides four kinds of comparison expressions, called value comparisons, general comparisons, node comparisons, and order comparisons.

[23]   ComparisonExpr   ::=   RangeExpr ( (ValueComp
|  GeneralComp
|  NodeComp
|  OrderComp)  RangeExpr )?
[39]   ValueComp   ::=   "eq" |  "ne" |  "lt" |  "le" |  "gt" |  "ge"
[38]   GeneralComp   ::=   "=" |  "!=" |  "<" |  "<=" |  ">" |  ">="
[40]   NodeComp   ::=   "is" |  "isnot"
[41]   OrderComp   ::=   "<<" |  ">>"

When an XPath expression is written within an XML document, the XML escaping rules for special characters must be followed; thus "<" must be written as "&lt;".

3.5.1 Value Comparisons

Value comparisons are intended for comparing single values. The result of a value comparison is defined by applying the following rules, in order:

  1. Atomization is applied to each operand. If the result is not an empty sequence or a single atomic value, a type error is raised.

  2. If either operand is an empty sequence, the result is an empty sequence.

  3. If either operand has the most specific type xs:anySimpleType, that operand is cast to a required type, which is determined as follows:

    • If the type of the other operand is numeric, the required type is xs:double.

    • If the most specific type of the other operand is xs:anySimpleType, the required type is xs:string.

    • Otherwise, the required type is the type of the other operand.

    If the cast fails, a dynamic error is raised.

  4. The result of the comparison is true if the value of the first operand is (equal, not equal, less than, less than or equal, greater than, greater than or equal) to the value of the second operand; otherwise the result of the comparison is false. B.2 Operator Mapping describes which combinations of atomic types are comparable, and how comparisons are performed on values of various types. If the value of the first operand is not comparable with the value of the second operand, a type error is raised.

Here are some examples of value comparisons:

  • The following comparison is true only if $book1 has a single author subelement and its value is "Kennedy":

    $book1/author eq "Kennedy"
  • The following comparison is true if hatsize and shoesize are both user-defined types that are derived by restriction from a primitive numeric type:

    hatsize(5) eq shoesize(5)

Ed. Note: The current definitions of the value comparison operators are not transitive. For example, anySimpleType('1') lt integer(2) is true and integer(2) lt anySimpleType('03') is true, but anySimpleType('1') lt anySimpleType('03') is false. It is not possible to preserve all of the following properties: (a) age > 21 is compared in the numeric domain when age is untyped; (b) city = county is compared in the string domain when both sides are untyped; (c) value comparisons are transitive; and (d) general comparisons are defined by adding existential quantifiers to value comparisons. The current design gives up property (c). This issue is still under discussion.

3.5.2 General Comparisons

Each of the value comparison operators has a corresponding general comparison operator that is defined by adding existential semantics to the value comparison operator. The operands of a general comparison may be sequences of any length. The result of a general comparison is always true or false.

The correspondence between value comparison and general comparison operators is shown in the following table:

Value ComparisonGeneral Comparison
eq=
ne!=
lt<
le<=
gt>
ge>=

For each value comparison operator VC, the corresponding general comparison operator GC is defined as follows:

A GC B is true for sequences A and B if the value comparison a VC b is true for some item a in A and some item b in B.

Furthermore, if XPath 1.0 compatibility mode is true, then A GC B is true if, for some item a in A and some item b in B, one of the following conditions hold:

  • a is numeric, and a VC fn:number(b) is true

  • b is numeric, and fn:number(a) VC b is true

Otherwise, A GC B is false.

When evaluating a general comparison in which either operand is a sequence of items, an implementation may return true as soon as it finds an item in the first operand and an item in the second operand for which the underlying value comparison is true. Similarly, a general comparison may raise a dynamic error as soon as it encounters an item in either operand that raises an error. As a result of these rules, the result of a general comparison is not deterministic in the presence of errors.

Here is an example of a general comparison:

  • The following comparison is true if the value of any author subelement of $book1 has the string value "Kennedy":

    $book1/author = "Kennedy"

3.5.3 Node Comparisons

The result of a node comparison is defined by applying the following rules, in order:

  1. Each operand must be either a single node or an empty sequence; otherwise a type error is raised.

  2. If either operand is an empty sequence, the result of the comparison is an empty sequence.

  3. A comparison with the is operator is true if the two operands are nodes that have the same identity; otherwise it is false. A comparison with the isnot operator is true if the two operands are nodes that have different identities; otherwise it is false. See [XQuery 1.0 and XPath 2.0 Data Model] for a discussion of node identity.

Use of the is operator is illustrated below.

  • The following comparison is true only if the left and right sides each evaluate to exactly the same single node:

    //book[isbn="1558604820"] is //book[call="QA76.9 C3845"]

3.5.4 Order Comparisons

The result of an order comparison is defined by applying the following rules, in order:

  1. Both operands must be either a single node or an empty sequence; otherwise a type error is raised.

  2. If either operand is an empty sequence, the result of the comparison is an empty sequence.

  3. A comparison with the << operator returns true if the first operand node is earlier than the second operand node in document order; otherwise it returns false.

  4. A comparison with the >> operator returns true if the first operand node is later than the second operand node in document order; otherwise it returns false.

Here is an example of an order comparison:

  • The following comparison is true only if the node identified by the left side occurs before the node identified by the right side in document order:

    //purchase[parcel="28-451"] << //sale[parcel="33-870"]

3.6 Logical Expressions

A logical expression is either an and-expression or an or-expression. If a logical expression does not raise an error, its value is always one of the boolean values true or false.

[16]   OrExpr   ::=   AndExpr ( "or"  AndExpr )*
[17]   AndExpr   ::=   ForExpr ( "and"  ForExpr )*

The first step in evaluating a logical expression is to find the effective boolean value of each of its operands (see 2.4.3.2 Effective Boolean Value).

The value of an and-expression is determined by the effective boolean values (EBV's) of its operands. If an error is raised during computation of one of the effective boolean values, an and-expression may raise a dynamic error, as shown in the following table:

AND:EBV2 = trueEBV2 = falseerror in EBV2
EBV1 = truetruefalseerror
EBV1 = falsefalsefalsefalse or error
error in EBV1 errorfalse or errorerror

The value of an or-expression is determined by the effective boolean values (EBV's) of its operands. If an error is raised during computation of one of the effective boolean values, an or-expression may raise a dynamic error, as shown in the following table:

OR:EBV2 = trueEBV2 = falseerror in EBV2
EBV1 = truetruetruetrue or error
EBV1 = falsetruefalseerror
error in EBV1true or errorerrorerror

The order in which the operands of a logical expression are evaluated is implementation-dependent. The tables above are defined in such a way that an or-expression can return true if the first expression evaluated is true, and it can raise an error if evaluation of the first expression raises an error. Similarly, an and-expression can return false if the first expression evaluated is false, and it can raise an error if evaluation of the first expression raises an error. As a result of these rules, a logical expression is not deterministic in the presence of errors, as illustrated in the examples below.

Here are some examples of logical expressions:

  • The following expressions return true:

    1 eq 1 and 2 eq 2
    1 eq 1 or 2 eq 3
  • The following expression may return either false or raise a dynamic error:

    1 eq 2 and 3 idiv 0 = 1
  • The following expression may return either true or raise a dynamic error:

    1 eq 1 or 3 idiv 0 = 1
  • The following expression must raise a dynamic error:

    1 eq 1 and 3 idiv 0 = 1

In addition to and- and or-expressions, XPath provides a function named not that takes a general sequence as parameter and returns a boolean value. The not function reduces its parameter to an effective boolean value. It then returns true if the effective boolean value of its parameter is false, and false if the effective boolean value of its parameter is true. If an error is encountered in finding the effective boolean value of its operand, not raises a dynamic error. The not function is described in [XQuery 1.0 and XPath 2.0 Functions and Operators].

3.7 For Expressions

XPath provides an iteration facility called a for expression.

[18]   ForExpr   ::=   (SimpleForClause "return")* QuantifiedExpr
[34]   SimpleForClause   ::=   <"for" "$"> VarName "in" Expr ("," "$" VarName "in" Expr)*

A for expression is evaluated as follows:

  1. If the 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.

  2. In a single-variable for expression, the variable is called the range variable, the value of the expression that follows the in keyword is called the input 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 input sequence, with the range variable bound to that item. The resulting sequences are concatenated in the order of the items in the input 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 Unix Programming</title>
    <author>Stevens</author>
    <publisher>Addison-Wesley</publisher>
  </book>
  <book>
    <title>Data on the Web</title>
    <author>Abiteboul</author>
    <author>Buneman</author>
    <author>Suciu</author>
  </book>
</bib>

The following 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 distinct-values(//author)
return ($a,
        for $b in //book[author = $a]
        return $b/title)

The result of the above expression consists of the following sequence of elements. Note that the authors appear in the order of their appearance in the input document.

<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

3.8 Conditional Expressions

XPath supports a conditional expression based on the keywords if, then, and else.

[20]   IfExpr   ::=   (<"if" "("> Expr ")" "then" Expr "else")* InstanceofExpr

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.2 Effective Boolean Value.

The value of a conditional expression is defined as follows: If the effective boolean value of the test expression is true, the value of the then-expression is returned. If the effective boolean value of the test expression is false, the value of the else-expression is returned.

Conditional expressions have a special rule for propagating dynamic errors. If the effective value of the test expression is true, the conditional expression ignores (does not raise) any dynamic errors encountered in the else-expression. In this case, since the else-expression can have no observable effect, it need not be evaluated. Similarly, if the effective value of the test expression is false, the conditional expression ignores any dynamic errors encountered in the then-expression, and the then-expression need not be evaluated.

Here are some examples of conditional expressions:

  • In this example, the test expression is a comparison expression:

    if ($widget1/unit-cost < $widget2/unit-cost) 
      then $widget1
      else $widget2
  • In this example, the test expression tests for the existence of an attribute named discounted, independently of its value:

    if ($part/@discounted) 
      then $part/wholesale 
      else $part/retail

3.9 Quantified Expressions

Quantified expressions support existential and universal quantification. The value of a quantified expression is always true or false.

[19]   QuantifiedExpr   ::=   ((<"some" "$"> |  <"every" "$">) VarName "in" Expr ("," "$" VarName "in" Expr)* "satisfies")* IfExpr

A quantified expression begins with a quantifier, which is the keyword some or every, followed by one or more in-clauses that are used to bind variables, followed by the keyword satisfies and a test expression. Each in-clause associates a variable with an expression that returns a sequence of values. As in the case of a for-clause in a For expression, the in-clauses generate tuples of variable bindings, using values drawn from the Cartesian product of the sequences returned by the binding expressions. Conceptually, the test expression is evaluated for each tuple of variable bindings. Results depend on the effective boolean values of the test expressions, as defined in 2.4.3.2 Effective Boolean Value. The value of the quantified expression is defined by the following rules:

  1. If the quantifier is some, the quantified expression is true if at least one evaluation of the test expression has the effective boolean value true; otherwise the quantified expression is false. This rule implies that, if the in-clauses generate zero binding tuples, the value of the quantified expression is false.

  2. If the quantifier is every, the quantified expression is true if every evaluation of the test expression has the effective boolean value true; otherwise the quantified expression is false. This rule implies that, if the in-clauses generate zero binding tuples, the value of the quantified expression is true.

The order in which test expressions are evaluated for the various binding tuples is implementation-defined. If the quantifier is some, an implementation may return true as soon as it finds one binding tuple for which the test expression has an effective Boolean value of true, and it may raise a dynamic error as soon as it finds one binding tuple for which the test expression raises an error. Similarly, if the quantifier is every, an implementation may return false as soon as it finds one binding tuple for which the test expression has an effective Boolean value of false, and it may raise a dynamic error as soon as it finds one binding tuple for which the test expression raises an error. As a result of these rules, the value of a quantified expression is not deterministic in the presence of errors, as illustrated in the examples below.

Here are some examples of quantified expressions:

  • This expression is true if every part element has a discounted attribute (regardless of the values of these attributes):

    every $part in //part satisfies $part/@discounted
  • This expression is true if at least one employee element satisfies the given comparison expression:

    some $emp in //employee satisfies ($emp/bonus > 0.25 * $emp/salary)
  • In the following examples, each quantified expression evaluates its test expression over nine tuples of variable bindings, formed from the Cartesian product of the sequences (1, 2, 3) and (2, 3, 4). The expression beginning with some evaluates to true, and the expression beginning with every evaluates to false.

    some $x in (1, 2, 3), $y in (2, 3, 4) 
         satisfies $x + $y = 4
    every $x in (1, 2, 3), $y in (2, 3, 4) 
         satisfies $x + $y = 4
  • This quantified expression may either return true or raise a dynamic error, since its test expression returns true for one variable binding and raises an error for another:

    some $x in (1, 2, "cat") satisfies $x * 2 = 4
  • This quantified expression may either return false or raise a dynamic error, since its test expression returns false for one variable binding and raises an error for another:

    every $x in (1, 2, "cat") satisfies $x * 2 = 4

3.10 Expressions on SequenceTypes

In addition to their use in function parameters, SequenceTypes occur explicitly in instance of, cast, castable, and treat expressions.

3.10.1 Instance Of

[21]   InstanceofExpr   ::=   CastableExpr ( <"instance" "of"> SequenceType )?

The boolean operator instance of returns true if the value of its first operand matches the type named in its second operand, according to the rules for SequenceType Matching; otherwise it returns false. For example:

  • 5 instance of xs:integer

    This example returns true because the given value is an instance of the given type.

  • 5 instance of xs:decimal

    This example returns true because the given value is an integer literal, and xs:integer is derived by restriction from xs:decimal.

  • . instance of element

    This example returns true if the context item is an element node.

3.10.2 Cast

[36]   CastExpr   ::=   <"cast" "as"> SingleType ParenthesizedExpr
[65]   SingleType   ::=   AtomicType "?"?

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 a named atomic type, represented by a QName, optionally followed by the occurrence indicator ? if an empty sequence is permitted. The semantics of the cast expression are as follows:

  1. Atomization is performed on the input expression.

  2. If the result of atomization is a sequence of more than one atomic value, a type error is raised.

  3. If the result of atomization is an empty sequence:

    1. If ? is specified after the target type, the result of the cast expression is an empty sequence.

    2. If ? is not specified after the target type, a type error is raised.

  4. If the result of atomization is a single atomic value, the result of the cast expression depends on the input type and the target type. In general, the cast expression attempts to create a new value of the target type based on the input value. Only certain combinations of input type and target type are supported. The rules are listed below. For the purpose of these rules, we use the terms subtype and supertype in the following sense: if type B is derived from type A by restriction, then B is a subtype of A, and A is a supertype of B.

    1. cast is supported for the combinations of input type and target type listed in [XQuery 1.0 and XPath 2.0 Functions and Operators]. For each of these combinations, both the input type and the target type are built-in schema types. For example, a value of type xs:string can be cast into the type xs:decimal. For each of these built-in combinations, the semantics of casting are specified in [XQuery 1.0 and XPath 2.0 Functions and Operators].

    2. cast is supported if the input type is a derived atomic type and the target type is a supertype of the input type. In this case, the input value is mapped unchanged into the value space of the target type. For example, if shoesize is derived by restriction from xs:integer, a value of type shoesize can be cast into the type xs:integer.

    3. cast is supported if the target type is a derived atomic type and the input type is xs:string, xs:anySimpleType, or a supertype of the target type. If the input type is xs:string or xs:anySimpleType, its string value must be in the lexical space of the target type, and it is converted to the target type using the schema-defined rules for the target type. If the input type is a supertype of the target type, its value is mapped unchanged into the value space of the target type, and it is checked for conformance to all the facets of the target type (checking of a "pattern" facet may require generating a canonical lexical representation of the input value.)

    4. If a primitive type P1 can be cast into a primitive type P2, then any subtype of P1 can be cast into any subtype of P2, provided that the facets of the target type are satisfied. First the input value is cast to P1 using rule (b) above. Next, the value of type P1 is cast to the type P2, using rule (a) above. Finally, the value of type P2 is cast to the target type, using rule (c) above.

    5. For any combination of input type and target type that is not in the above list, a cast expression raises a static error.

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. This includes the case when any facet of the target type is not satisfied. For example, cast as xs:integer($x) raises a dynamic error if the type of $x is xs:decimal and its value is 4.99 because this value cannot be represented with zero fractional digits.

3.10.3 Castable

[22]   CastableExpr   ::=   ComparisonExpr ( <"castable" "as"> SingleType )?

XPath provides a form of a predicate that tests whether a given value is castable into a given target type. The expression V castable as T returns true if the value V can be successfully cast into the target type T; otherwise it returns false. The castable predicate can be used to avoid errors at evaluation time. It can also be used to select an appropriate type for processing of a given value, as illustrated in the following example:

if ($x castable as hatsize)
then cast as hatsize($x)
else if ($x castable as IQ)
then cast as IQ($x)
else cast as string($x)

3.10.4 Constructor Functions

Constructor functions provide an alternative syntax for casting.

For every built-in type T that is defined in [XML Schema], as well as the duration subtypes fn:dayTimeDuration and fn:yearMonthDuration, a built-in constructor function is provided. The signature of the built-in constructor function for type T is as follows:

T($x as item) as T

The constructor function for type T accepts any single item (either a node or an atomic value) as input, and returns a value of type T (or raises a dynamic error). Its semantics are exactly the same as a cast expression with target type T. The built-in constructor functions are described in more detail in [XQuery 1.0 and XPath 2.0 Functions and Operators]. The following are examples of built-in constructor functions:

  • This example is equivalent to cast as xs:date("2000-01-01").

    xs:date("2000-01-01")
  • This example is equivalent to cast as xs:decimal($floatvalue * 0.2E-5).

    xs:decimal($floatvalue * 0.2E-5)
  • This example returns a dayTimeDuration value equal to 21 days. It is equivalent to cast as fn:dayTimeDuration("P21D").

    fn:dayTimeDuration("P21D")

For each user-defined atomic type T in the in-scope schema definitions, a constructor function is effectively defined. Like the built-in constructor functions, the constructor functions for user-defined types have the same name as the type, accept any item as input, and have semantics identical to a cast expression with the user-defined type as target type. For example, if usa:zipcode is a user-defined atomic type in the in-scope schema definitions, then the expression usa:zipcode("12345") is equivalent to the expression cast as usa:zipcode("12345").

If the argument to any constructor function is a literal value, the result of the function may be computed statically, and an error encountered in this process may be reported as a static error.

3.10.5 Treat

[37]   TreatExpr   ::=   <"treat" "as"> SequenceType ParenthesizedExpr

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 type at evaluation time.

The semantics of treat as type1 (expr2) are as follows:

  • During static analysis (if the Static Typing Feature is implemented):

    type1 must be a subtype of the static type of expr2, using the definition of subtype in [XQuery 1.0 Formal Semantics]--otherwise, a type error is raised. The static type of the treat expression is type1. This enables the expression to be used as an argument of a function that requires a parameter of type1.

  • During expression evaluation (at "run-time"):

    If expr2 matches type1, using the SequenceType Matching rules in 2.4.2 SequenceType, the treat expression returns the value of expr2; otherwise, it raises a dynamic error. If the value of expr2 is returned, its identity is preserved. The treat expression ensures that the value of its expression operand conforms to the expected type at run-time.

  • Example:

    treat as element of type USAddress ($myaddress)

    The static type of $myaddress may be element of type Address, a less specific type than element of type USAddress. However, at run-time, the value of $myaddress must match the type element of type USAddress using SequenceType Matching rules; otherwise a dynamic error is raised.

3.11 Validate Expressions

[35]   ValidateExpr   ::=   (<"validate" "{"> |  (<"validate" "context"> SchemaGlobalContext ("/" SchemaContextStep)* "{")) Expr "}"

Ed. Note: Curly braces in this syntax may cause problems if this expression is embedded in XSLT--see Issue 267.)

A validate expression validates its argument with respect to the in-scope schema definitions, using the schema validation process described in [XML Schema]. The argument of a validate expression may be any sequence of elements. Validation replaces element and attribute nodes with new nodes that have their own identity and that contain type annotations and defaults created by the validation process. If a hierarchy of nodes is validated by a validate expression, the hierarchical relationship among these nodes will be preserved among the nodes created by the validation process.

The following example validates the value that is bound to a variable:

validate { $x }

The validate expression invokes the full schema validation process, except that identity constraints, as defined in section 3.11.4 of [XML Schema] Part 1, are not applied. All facets of simple types are checked, and default values are supplied as defined in the XML Schema specification.

Validating an expression is equivalent to the following steps:

  1. The value of the expression is converted from the Data Model to an XML Information Set (see [XML Infoset].) This step is equivalent to serializing the value of the expression in XML form and then parsing it to produce an Information Set.

  2. The Information Set produced in the previous step is validated according to the rules in [XML Schema], using the in-scope schema definitions. The result of this step is a Post-Schema Validation Infoset (PSVI). If the validation process is not successful, a type error is raised.

  3. The PSVI produced in the previous step is converted back into the Data Model by the mapping described in [XQuery 1.0 and XPath 2.0 Data Model].

A validate expression may contain a SchemaContext that is used in validating locally declared elements and attributes. When a schema context is supplied, all element QNames are interpreted as they would be if found in that context in an XML document. If the schema context begins with a QName, the QName is interpreted as the name of a globally declared element; however, if the schema context begins with the keyword type, the first QName is interpreted as the name of a globally declared type. The steps inside the schema context trace a path relative to the globally declared element or type, as illustrated in the following examples, which are based on schemas defined in [XML Schema], Part 0:

  • Suppose that $x is bound to a shipTo element. Then validate context po:purchaseOrder {$x} validates the value of $x in the context of the global element declaration po:purchaseOrder.

  • Suppose that $y is bound to a productName element. Then validate context po:purchaseOrder/items/item {$y} validates the value of $y in the context of an item element, inside an items element, inside the global element declaration po:purchaseOrder.

  • Suppose that $z is bound to a zip element. Then validate context type po:USAddress {$z} validates the value of $z in the context of the global type declaration po:USAddress.

If no context is specified, all top-level names in the material to be validated are treated as global names.

A XPath Grammar

A.1 Lexical structure

A character is an atomic unit of text as specified by ISO/IEC 10646 [ISO/IEC 10646] (see also [ISO/IEC 10646-2000]). Legal characters are those allowed in the [XML] recommendation.

A lexical pattern is a rule that describes how a sequence of characters can match a grammar unit. A lexeme is the smallest meaningful unit in the grammar that has syntactic interpretation. A token is a symbol that matches lexemes, and is the output of the lexical analyzer. A token symbol is the symbolic name given to that token. A single token may be composed of one or more lexemes. If there is more than one lexeme, they may be separated by whitespace or punctuation. For instance, a token AxisDescendantOrSelf might have two lexemes, "descendant-or-self" and "::".

PatternLexeme(s)Token Names (for example)
"or""or"Or
"=""="Equals
(Prefix ':')? LocalPart"p"QName
":"
"foo"
<"descendant-or-self" "::">"descendant-or-self"AxisDescendantOrSelf
"::"

When patterns are simple string matches, the strings are embedded directly into the BNF. In other cases, token symbols are used when the pattern is a more complex regular expression (the major cases of these are NCName, QName, and Number and String literals). It is up to an implementation to decide on the exact tokenization strategy, which may be different depending on the parser construction. For example, an implementation may decide that a token named For is composed of only "for", or may decide that it is composed of ("for" "$"). In the first case the implementation may decide to use lexical lookahead to distinguish the "for" lexeme from a QName that has the lexeme "for". In the second case, the implementation may decide to combine the two lexemes into a single "long" token. In either case, the end grammatical result will be the same. In the BNF, the notation "< ... >" is used to indicate and delimit a sequence of lexemes that must be recognized using lexical lookahead or some equivalent means.

This grammar implies lexical states, which are lexical constraints on the tokenization process based on grammatical positioning. The exact structure of these states is left to the implementation, but the normative rules for calculating these states are given in the A.1.2 Lexical Rules section.

When tokenizing, the longest possible match that is valid in the current lexical state is prefered .

For readability, Whitespace may be used in most expressions even though not explicitly notated in the BNF. Whitespace may be freely added between lexemes, except a few cases where whitespace is needed to disambiguate the token. For instance, in XML, "-" is a valid character in an element or attribute name. When used as an operator after the characters of a name, it must be separated from the name, e.g. by using whitespace or parentheses.

Special whitespace notation is specified with the BNF productions, when it is different from the default rules. "ws: explicit" means that where whitespace is allowed must be explicitly notated in the BNF. "ws: significant" means that whitespace is significant as value content.

All keywords are case sensitive.

A.1.1 Syntactic Constructs

A.1.2 Lexical Rules

The lexical contexts and transitions between lexical contexts is described in terms of a series of states and transitions between those states.

As discussed above, there are various strategies that can be used by an implementation to disambiguate token symbol choices. Among the choices are lexical look-ahead and look-behind, a two-pass lexical evaluation, and a single recursive descent lexical evaluation and parse. This specification does not dictate what strategy to use. An implementation need not follow this approach in implementing lexer rules, but does need to conform to the results. For instance, instead of using a state automaton, an implementation might use lexical look-behind, or might use a full context-free-grammar parse, or it might make extensive use of parser lookahead (and use a more ambiguous token strategy).

The tables below define the complete lexical rules for XPath. Each table corresponds to a lexical state in which the tokens listed are recognized only in that state. When a given token is recognized in the given state, the transition to the next state is given. In some cases, a transition will "push" the current state or a specific state onto an abstract stack, and will later restore that state by a "pop" when another lexical event occurs.

The lexical states have in many cases close connection to the parser productions. However, just because a token is recognized in a certain lexical state, does not mean it will be legal in the parser state.

The #ANY State

This state is for patterns that can be recognized in any state.

PatternTransition To State
WhitespaceChar
Nmstart
Nmchar
Digits
(maintain current state)

The DEFAULT State

This state is for patterns that occur at the beginning of an expression.

PatternTransition To State
"?"
"["
"+"
"-"
"("
<"text" "(">
<"comment" "(">
<"node" "(">
<"processing-instruction" "(">
<"if" "(">
<QName "(">
<"validate" "context">
DEFAULT
"{"
<"validate" "{">
DEFAULT
pushState(DEFAULT)
DEFAULT
pushState(DEFAULT)
"]"
IntegerLiteral
DecimalLiteral
DoubleLiteral
<"type" QName>
"*"
<NCName ":" "*">
<"*" ":" NCName>
"."
".."
")"
StringLiteral
OPERATOR
<"of" "type">
"/"
"//"
<"child" "::">
<"descendant" "::">
<"parent" "::">
<"attribute" "::">
<"self" "::">
<"descendant-or-self" "::">
<"ancestor" "::">
<"following-sibling" "::">
<"preceding-sibling" "::">
<"following" "::">
<"preceding" "::">
<"namespace" "::">
<"ancestor-or-self" "::">
"@"
QNAME
<"cast" "as">
<"treat" "as">
ITEMTYPE
"$"
<"for" "$">
<"some" "$">
<"every" "$">
VARNAME
","
resetParenStateOrSwitch(DEFAULT)
ExprComment
(maintain state)
"}"
popState

The OPERATOR State

This state is for patterns that are defined for operators.

PatternTransition To State
"/"
"//"
"div"
"idiv"
"mod"
"and"
"or"
"*"
"return"
"then"
"else"
"to"
"union"
"intersect"
"except"
"="
"is"
"!="
"isnot"
"<="
">="
"<"
">"
"|"
"<<"
">>"
"eq"
"ne"
"gt"
"ge"
"lt"
"le"
"in"
"context"
"satisfies"
"?"
"["
"+"
"-"
"("
"item"
"node"
"document"
"comment"
"text"
DEFAULT
"{"
<"validate" "{">
DEFAULT
pushState(DEFAULT)
"]"
IntegerLiteral
DecimalLiteral
DoubleLiteral
<NCName ":" "*">
<"*" ":" NCName>
"."
".."
")"
StringLiteral
OPERATOR
<"of" "type">
QNAME
<"instance" "of">
<"castable" "as">
ITEMTYPE
"$"
<"for" "$">
<"some" "$">
<"every" "$">
VARNAME
","
resetParenStateOrSwitch(DEFAULT)
ExprComment
(maintain state)
"}"
popState

The QNAME State

When a qualified name is expected, and it is required to remove ambiguity from patterns that look like keywords, this state is used.

PatternTransition To State
"("
<"text" "(">
<"comment" "(">
<"node" "(">
<"processing-instruction" "(">
DEFAULT
"*"
<NCName ":" "*">
<"*" ":" NCName>
"."
".."
")"
OPERATOR
"/"
"//"
<"child" "::">
<"descendant" "::">
<"parent" "::">
<"attribute" "::">
<"self" "::">
<"descendant-or-self" "::">
<"ancestor" "::">
<"following-sibling" "::">
<"preceding-sibling" "::">
<"following" "::">
<"preceding" "::">
<"namespace" "::">
<"ancestor-or-self" "::">
"@"
QNAME
"$"
VARNAME
","
resetParenStateOrSwitch(DEFAULT)
ExprComment
(maintain state)

The ITEMTYPE State

This state distinguishes tokens that can occur only inside the ItemType production.

PatternTransition To State
"attribute"
"element"
"node"
"document"
"comment"
"text"
"processing-instruction"
"item"
"untyped"
<"atomic" "value">
AtomicType
"empty"
DEFAULT
"{"
<"validate" "{">
DEFAULT
pushState(DEFAULT)
<NCName ":" "*">
<"*" ":" NCName>
"."
".."
")"
OPERATOR
"$"
VARNAME
ExprComment
(maintain state)

The VARNAME State

This state differentiates variable names from qualified names. This allows only the pattern of a QName to be recognized when otherwise ambiguities could occur.

PatternTransition To State
VarName
OPERATOR
ExprComment
(maintain state)

Ed. Note: Note that the "validate" keyword can not be easily distinguished at lexical evaluation time from a QName whose value is "validate". This should be fixed in the future.

A.2 BNF

The following grammar uses the same Basic EBNF notation as [XML], except that grammar symbols always have initial capital letters. The EBNF contains the lexemes embedded in the productions.

Note:

Note that the Semicolon character is reserved for future use.

NON-TERMINALS

[13]   XPath   ::=   ExprSequence?
[14]   ExprSequence   ::=   Expr ("," Expr)*
[15]   Expr   ::=   OrExpr
[16]   OrExpr   ::=   AndExpr ( "or"  AndExpr )*
[17]   AndExpr   ::=   ForExpr ( "and"  ForExpr )*
[18]   ForExpr   ::=   (SimpleForClause "return")* QuantifiedExpr
[19]   QuantifiedExpr   ::=   ((<"some" "$"> |  <"every" "$">) VarName "in" Expr ("," "$" VarName "in" Expr)* "satisfies")* IfExpr
[20]   IfExpr   ::=   (<"if" "("> Expr ")" "then" Expr "else")* InstanceofExpr
[21]   InstanceofExpr   ::=   CastableExpr ( <"instance" "of"> SequenceType )?
[22]   CastableExpr   ::=   ComparisonExpr ( <"castable" "as"> SingleType )?
[23]   ComparisonExpr   ::=   RangeExpr ( (ValueComp
|  GeneralComp
|  NodeComp
|  OrderComp)  RangeExpr )?
[24]   RangeExpr   ::=   AdditiveExpr ( "to"  AdditiveExpr )?
[25]   AdditiveExpr   ::=   MultiplicativeExpr ( ("+" |  "-")  MultiplicativeExpr )*
[26]   MultiplicativeExpr   ::=   UnaryExpr ( ("*" |  "div" |  "idiv" |  "mod")  UnaryExpr )*
[27]   UnaryExpr   ::=   ("-" |  "+")* UnionExpr
[28]   UnionExpr   ::=   IntersectExceptExpr ( ("union" |  "|")  IntersectExceptExpr )*
[29]   IntersectExceptExpr   ::=   ValueExpr ( ("intersect" |  "except")  ValueExpr )*
[30]   ValueExpr   ::=   ValidateExpr |  CastExpr |  TreatExpr |  PathExpr
[31]   PathExpr   ::=   ("/" RelativePathExpr?) |  ("//" RelativePathExpr) |  RelativePathExpr
[32]   RelativePathExpr   ::=   StepExpr (("/" |  "//") StepExpr)*
[33]   StepExpr   ::=   (ForwardStep |  ReverseStep |  PrimaryExpr) Predicates
[34]   SimpleForClause   ::=   <"for" "$"> VarName "in" Expr ("," "$" VarName "in" Expr)*
[35]   ValidateExpr   ::=   (<"validate" "{"> |  (<"validate" "context"> SchemaGlobalContext ("/" SchemaContextStep)* "{")) Expr "}"
[36]   CastExpr   ::=   <"cast" "as"> SingleType ParenthesizedExpr
[37]   TreatExpr   ::=   <"treat" "as"> SequenceType ParenthesizedExpr
[38]   GeneralComp   ::=   "=" |  "!=" |  "<" |  "<=" |  ">" |  ">="
[39]   ValueComp   ::=   "eq" |  "ne" |  "lt" |  "le" |  "gt" |  "ge"
[40]   NodeComp   ::=   "is" |  "isnot"
[41]   OrderComp   ::=   "<<" |  ">>"
[42]   PrimaryExpr   ::=   Literal |  FunctionCall |  ("$" VarName) |  ParenthesizedExpr
[43]   ForwardAxis   ::=   <"child" "::">
|  <"descendant" "::">
|  <"attribute" "::">
|  <"self" "::">
|  <"descendant-or-self" "::">
|  <"following-sibling" "::">
|  <"following" "::">
|  <"namespace" "::">
[44]   ReverseAxis   ::=   <"parent" "::">
|  <"ancestor" "::">
|  <"preceding-sibling" "::">
|  <"preceding" "::">
|  <"ancestor-or-self" "::">
[45]   NodeTest   ::=   KindTest |  NameTest
[46]   NameTest   ::=   QName |  Wildcard
[47]   Wildcard   ::=   "*" |  <NCName ":" "*"> |  <"*" ":" NCName>
[48]   KindTest   ::=   ProcessingInstructionTest
|  CommentTest
|  TextTest
|  AnyKindTest
[49]   ProcessingInstructionTest   ::=   <"processing-instruction" "("> StringLiteral? ")"
[50]   CommentTest   ::=   <"comment" "("> ")"
[51]   TextTest   ::=   <"text" "("> ")"
[52]   AnyKindTest   ::=   <"node" "("> ")"
[53]   ForwardStep   ::=   (ForwardAxis NodeTest) |  AbbreviatedForwardStep
[54]   ReverseStep   ::=   (ReverseAxis NodeTest) |  AbbreviatedReverseStep
[55]   AbbreviatedForwardStep   ::=   "." |  ("@" NameTest) |  NodeTest
[56]   AbbreviatedReverseStep   ::=   ".."
[57]   Predicates   ::=   ("[" Expr "]")*
[58]   NumericLiteral   ::=   IntegerLiteral |  DecimalLiteral |  DoubleLiteral
[59]   Literal   ::=   NumericLiteral |  StringLiteral
[60]   ParenthesizedExpr   ::=   "(" ExprSequence? ")"
[61]   FunctionCall   ::=   <QName "("> (Expr ("," Expr)*)? ")"
[62]   SchemaContext   ::=   "context" SchemaGlobalContext ("/" SchemaContextStep)*
[63]   SchemaGlobalContext   ::=   QName |  <"type" QName>
[64]   SchemaContextStep   ::=   QName
[65]   SingleType   ::=   AtomicType "?"?
[66]   SequenceType   ::=   (ItemType OccurrenceIndicator) |  "empty"
[67]   ItemType   ::=   (("element" |  "attribute") ElemOrAttrType?)
|  "node"
|  "processing-instruction"
|  "comment"
|  "text"
|  "document"
|  "item"
|  AtomicType
|  "untyped"
|  <"atomic" "value">
[68]   ElemOrAttrType   ::=   (QName (SchemaType |  SchemaContext?)) |  SchemaType
[69]   SchemaType   ::=   <"of" "type"> QName
[70]   AtomicType   ::=   QName
[71]   OccurrenceIndicator   ::=   ("*" |  "+" |  "?")?

A.3 Reserved Function Names

The following is a list of names that may not be used as user function names, in an unprefixed form.

  • if

  • typeswitch

  • item

  • node

  • element

  • attribute

  • comment

  • text

  • processing-instruction

  • id

  • key

A.4 Precedence Order

In all cases the grammar defines built-in precedence. In the cases where a number of statements are a choice at the same production level, the expressions are always evaluated from left to right.

B Type Promotion and Operator Mapping

B.1 Type Promotion

Under certain circumstances, an atomic value can be promoted from one type to another. Type promotion is used in function calls (see 3.1.4 Function Calls) and in processing of operators that accept numeric operands (listed in the tables below). The following type promotions are permitted:

  1. A value of type xs:float (or any type derived by restriction from xs:float) can be promoted to the type xs:double. The result is the xs:double value that is the same as the original value.

  2. A value of type xs:decimal (or any type derived by restriction from xs:decimal) can be promoted to either of the types xs:float or xs:double. The result is the value of the target type that is closest to the original value.

Note that promotion is different from subtype substitution. For example:

  • A function that expects a parameter $p of type xs:float can be invoked with a value of type xs:decimal. This is an example of promotion. The value is actually converted to the expected type. Within the body of the function, $p instance of xs:decimal returns false.

  • A function that expects a parameter $p of type xs:decimal can be invoked with a value of type xs:integer. This is an example of subtype substitution. The value retains its original type. Within the body of the function, $p instance of xs:integer returns true.

B.2 Operator Mapping

The tables in this section list the combinations of types for which the various operators of XPath are defined. For each valid combination of types, the table indicates the function(s) that are used to implement the operator and the type of the result. Definitions of the functions can be found in [XQuery 1.0 and XPath 2.0 Functions and Operators]. Note that in some cases the function does not implement the full semantics of the given operator. For a complete description 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.

Operators listed in the tables may be validly applied to operands whose types are derived by restriction from the listed operand types. For example, a table entry indicates that the gt operator may be applied to two xs:date operands, returning xs:boolean. Therefore, the gt operator may also be applied to two (possibly different) subtypes of xs:date, also returning xs:boolean.

In the operator tables, the term numeric refers to the types xs:integer, xs:decimal, xs:float, and xs:double. An operator whose operands and result are designated as numeric might be thought of as representing four operators, one for each of the numeric types. For example, the numeric + operator might be thought of as representing the following four operators:

OperatorFirst operand typeSecond operand typeResult type
+xs:integerxs:integerxs:integer
+xs:decimalxs:decimalxs:decimal
+xs:floatxs:floatxs:float
+xs:doublexs:doublexs:double

A numeric operator accepts operands of the four numeric types and any type that is derived by restriction from one of the four numeric types. If the result type of an operator is listed as numeric, it means "the first numeric type, in promotion order, into which all operands can be converted by subtype substitution and promotion." As an example, suppose that the type hatsize is derived from xs:integer and the type shoesize is derived from xs:float. Then if the + operator is invoked with operands of type hatsize and shoesize, it returns a result of type xs:float. Similarly, if + is invoked with two operands of type shoesize it returns a result of type xs:integer.

In the following tables, the term Gregorian refers to the types xs:gYearMonth, xs:gYear, xs:gMonthDay, xs:gDay, and xs:gMonth. For binary operators that accept two Gregorian-type operands, both operands must have the same type (for example, if one operand is of type xs:gDay, the other operand must be of type xs:gDay.)

Binary Operators
OperatorType(A)Type(B)FunctionResult type
A + Bnumericnumericop:numeric-add(A, B)numeric
A + Bxs:datefn:yearMonthDurationop:add-yearMonthDuration-to-date(A, B)xs:date
A + Bfn:yearMonthDurationxs:dateop:add-yearMonthDuration-to-date(B, A)xs:date
A + Bxs:datefn:dayTimeDurationop:add-dayTimeDuration-to-date(A, B)xs:date
A + Bfn:dayTimeDurationxs:dateop:add-dayTimeDuration-to-date(B, A)xs:date
A + Bxs:timefn:dayTimeDurationop:add-dayTimeDuration-to-time(A, B)xs:time
A + Bfn:dayTimeDurationxs:timeop:add-dayTimeDuration-to-time(B, A)xs:time
A + Bxs:datetimefn:yearMonthDurationop:add-yearMonthDuration-to-dateTime(A, B)xs:dateTime
A + Bfn:yearMonthDurationxs:datetimeop:add-yearMonthDuration-to-dateTime(B, A)xs:dateTime
A + Bxs:datetimefn:dayTimeDurationop:add-dayTimeDuration-to-dateTime(A, B)xs:dateTime
A + Bfn:dayTimeDurationxs:datetimeop:add-dayTimeDuration-to-dateTime(B, A)xs:dateTime
A + Bfn:yearMonthDurationfn:yearMonthDurationop:add-yearMonthDurations(A, B)fn:yearMonthDuration
A + Bfn:dayTimeDurationfn:dayTimeDurationop:add-dayTimeDurations(A, B)fn:dayTimeDuration
A - Bnumericnumericop:numeric-subtract(A, B)numeric
A - Bxs:datexs:dateop:subtract-dates(A, B)fn:dayTimeDuration
A - Bxs:datefn:yearMonthDurationop:subtract-yearMonthDuration-from-date(A, B)xs:date
A - Bxs:datefn:dayTimeDurationop:subtract-dayTimeDuration-from-date(A, B)xs:date
A - Bxs:timexs:timeop:subtract-times(A, B)fn:dayTimeDuration
A - Bxs:timefn:dayTimeDurationop:subtract-dayTimeDuration-from-time(A, B)xs:time
A - Bxs:datetimexs:datetimefn:subtract-dateTimes-yielding-dayTimeDuration(A, B)fn:dayTimeDuration
A - Bxs:datetimefn:yearMonthDurationop:subtract-yearMonthDuration-from-dateTime(A, B)xs:dateTime
A - Bxs:datetimefn:dayTimeDurationop:subtract-dayTimeDuration-from-dateTime(A, B)xs:dateTime
A - Bfn:yearMonthDurationfn:yearMonthDurationop:subtract-yearMonthDurations(A, B)fn:yearMonthDuration
A - Bfn:dayTimeDurationfn:dayTimeDurationop:subtract-dayTimeDurations(A, B)fn:dayTimeDuration
A * Bnumericnumericop:numeric-multiply(A, B)numeric
A * Bfn:yearMonthDurationxs:decimalop:multiply-yearMonthDuration(A, B)fn:yearMonthDuration
A * Bxs:decimalfn:yearMonthDurationop:multiply-yearMonthDuration(B, A)fn:yearMonthDuration
A * Bfn:dayTimeDurationxs:decimalop:multiply-dayTimeDuration(A, B)fn:dayTimeDuration
A * Bxs:decimalfn:dayTimeDurationop:multiply-dayTimeDuration(B, A)fn:dayTimeDuration
A idiv Bxs:integerxs:integerop:integer-div(A, B)xs:integer
A div Bnumericnumericop:numeric-divide(A, B)numeric; but xs:double if both operands are xs:integer
A div Bfn:yearMonthDurationxs:decimalop:divide-yearMonthDuration(A, B)fn:yearMonthDuration
A div Bfn:dayTimeDurationxs:decimalop:divide-dayTimeDuration(A, B)fn:dayTimeDuration
A mod Bnumericnumericop:numeric-mod(A, B)numeric
A eq Bnumericnumericop:numeric-equal(A, B)xs:boolean
A eq Bxs:booleanxs:booleanop:boolean-equal(A, B)xs:boolean
A eq Bxs:stringxs:stringop:numeric-equal(fn:compare(A, B), 1)xs:boolean
A eq Bxs:datexs:dateop:date-equal(A, B)xs:boolean
A eq Bxs:timexs:timeop:time-equal(A, B)xs:boolean
A eq Bxs:dateTimexs:dateTimeop:datetime-equal(A, B)xs:boolean
A eq Bfn:yearMonthDurationfn:yearMonthDurationop:yearMonthDuration-equal(A, B)xs:boolean
A eq Bfn:dayTimeDurationfn:dayTimeDurationop:dayTimeDuration-equal(A, B)xs:boolean
A eq BGregorianGregorianop:gYear-equal(A, B) etc.xs:boolean
A eq Bxs:hexBinaryxs:hexBinaryop:hex-binary-equal(A, B)xs:boolean
A eq Bxs:base64Binaryxs:base64Binaryop:base64-binary-equal(A, B)xs:boolean
A eq Bxs:anyURIxs:anyURIop:anyURI-equal(A, B)xs:boolean
A eq Bxs:QNamexs:QNameop:QName-equal(A, B)xs:boolean
A eq Bxs:NOTATIONxs:NOTATIONop:NOTATION-equal(A, B)xs:boolean
A ne Bnumericnumericfn:not(op:numeric-equal(A, B))xs:boolean
A ne Bxs:booleanxs:booleanfn:not(op:boolean-equal(A, B))xs:boolean
A ne Bxs:stringxs:stringfn:not(op:numeric-equal(fn:compare(A, B), 1))xs:boolean
A ne Bxs:datexs:datefn:not(op:date-equal(A, B))xs:boolean
A ne Bxs:timexs:timefn:not(op:time-equal(A, B))xs:boolean
A ne Bxs:dateTimexs:dateTimefn:not(op:datetime-equal(A, B))xs:boolean
A ne Bfn:yearMonthDurationfn:yearMonthDurationfn:not(op:yearMonthDuration-equal(A, B))xs:boolean
A ne Bfn:dayTimeDurationfn:dayTimeDurationfn:not(op:dayTimeDuration-equal(A, B)xs:boolean
A ne BGregorianGregorianfn:not(op:gYear-equal(A, B)) etc.xs:boolean
A ne Bxs:hexBinaryxs:hexBinaryfn:not(op:hex-binary-equal(A, B))xs:boolean
A ne Bxs:base64Binaryxs:base64Binaryfn:not(op:base64-binary-equal(A, B))xs:boolean
A ne Bxs:anyURIxs:anyURIfn:not(op:anyURI-equal(A, B))xs:boolean
A ne Bxs:QNamexs:QNamefn:not(op:QName-equal(A, B))xs:boolean
A ne Bxs:NOTATIONxs:NOTATIONxs:not(op:NOTATION-equal(A, B))xs:boolean
A gt Bnumericnumericop:numeric-greater-than(A, B)xs:boolean
A gt Bxs:booleanxs:booleanop:boolean-greater-than(A, B)xs:boolean
A gt Bxs:stringxs:stringop:numeric-greater-than(fn:compare(A, B), 0)xs:boolean
A gt Bxs:datexs:dateop:date-greater-than(A, B)xs:boolean
A gt Bxs:timexs:timeop:time-greater-than(A, B)xs:boolean
A gt Bxs:dateTimexs:dateTimeop:datetime-greater-than(A, B)xs:boolean
A gt Bfn:yearMonthDurationfn:yearMonthDurationop:yearMonthDuration-greater-than(A, B)xs:boolean
A gt Bfn:dayTimeDurationfn:dayTimeDurationop:dayTimeDuration-greater-than(A, B)xs:boolean
A lt Bnumericnumericop:numeric-less-than(A, B)xs:boolean
A lt Bxs:booleanxs:booleanop:boolean-less-than(A, B)xs:boolean
A lt Bxs:stringxs:stringop:numeric-less-than(fn:compare(A, B), 0)xs:boolean
A lt Bxs:datexs:dateop:date-less-than(A, B)xs:boolean
A lt Bxs:timexs:timeop:time-less-than(A, B)xs:boolean
A lt Bxs:dateTimexs:dateTimeop:datetime-less-than(A, B)xs:boolean
A lt Bfn:yearMonthDurationfn:yearMonthDurationop:yearMonthDuration-less-than(A, B)xs:boolean
A lt Bfn:dayTimeDurationfn:dayTimeDurationop:dayTimeDuration-less-than(A, B)xs:boolean
A ge Bnumericnumericop:numeric-less-than(B, A)xs:boolean
A ge Bxs:stringxs:stringop:numeric-greater-than(fn:compare(A, B), -1)xs:boolean
A ge Bxs:datexs:dateop:date-less-than(B, A)xs:boolean
A ge Bxs:timexs:timeop:time-less-than(B, A)xs:boolean
A ge Bxs:dateTimexs:dateTimeop:datetime-less-than(B, A)xs:boolean
A ge Bfn:yearMonthDurationfn:yearMonthDurationop:yearMonthDuration-less-than(B, A)xs:boolean
A ge Bfn:dayTimeDurationfn:dayTimeDurationop:dayTimeDuration-less-than(B, A)xs:boolean
A le Bnumericnumericop:numeric-greater-than(B, A)xs:boolean
A le Bxs:stringxs:stringop:numeric-less-than(fn:compare(A, B), 1)xs:boolean
A le Bxs:datexs:dateop:date-greater-than(B, A)xs:boolean
A le Bxs:timexs:timeop:time-greater-than(B, A)xs:boolean
A le Bxs:dateTimexs:dateTimeop:datetime-greater-than(B, A)xs:boolean
A le Bfn:yearMonthDurationfn:yearMonthDurationop:yearMonthDuration-greater-than(B, A)xs:boolean
A le Bfn:dayTimeDurationfn:dayTimeDurationop:dayTimeDuration-greater-than(B, A)xs:boolean
A is Bnodenodeop:node-equal(A, B)xs:boolean
A isnot Bnodenodefn:not(op:node-equal(A, B))xs:boolean
A << Bnodenodeop:node-before(A, B)xs:boolean
A >> Bnodenodeop:node-after(A, B)xs:boolean
A union Bnode*node*op:union(A, B)node*
A | Bnode*node*op:union(A, B)node*
A intersect Bnode*node*op:intersect(A, B)node*
A except Bnode*node*op:except(A, B)node*
A to Bxs:decimalxs:decimalop:to(A, B)xs:integer+
A , Bitem*item*op:concatenate(A, B)item*
Unary Operators
OperatorOperand typeFunctionResult type
+ Anumericop:numeric-unary-plus(A)numeric
- Anumericop:numeric-unary-minus(A)numeric

C References

C.1 Normative References

ISO/IEC 10646
ISO (International Organization for Standardization). ISO/IEC 10646-1993 (E). Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. [Geneva]: International Organization for Standardization, 1993 (plus amendments AM 1 through AM 7).
ISO/IEC 10646-2000
ISO (International Organization for Standardization). ISO/IEC 10646-1:2000. Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. [Geneva]: International Organization for Standardization, 2000.
Unicode
The Unicode Consortium. The Unicode Standard, Version 2.0. Reading, Mass.: Addison-Wesley Developers Press, 1996.
Unicode3
The Unicode Consortium. The Unicode Standard, Version 3.0. Reading, Mass.: Addison-Wesley Developers Press, 2000. ISBN 0-201-61633-5.
XML
World Wide Web Consortium. Extensible Markup Language (XML) 1.0. W3C Recommendation. See http://www.w3.org/TR/2000/REC-xml-20001006
XML Names
World Wide Web Consortium. Namespaces in XML. W3C Recommendation. See http://www.w3.org/TR/REC-xml-names/
XML Schema
World Wide Web Consortium. XML Schema, Parts 0, 1, and 2. W3C Recommendation, 2 May 2001. See http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/ , http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ , and http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/.
XQuery 1.0 and XPath 2.0 Data Model
World Wide Web Consortium. XQuery 1.0 and XPath 2.0 Data Model. W3C Working Draft, 30 April 2002. See http://www.w3.org/TR/query-datamodel/.
XQuery 1.0 and XPath 2.0 Functions and Operators
World Wide Web Consortium. XQuery 1.0 and XPath 2.0 Functions and Operators W3C Working Draft, 15 November 2002. See http://www.w3.org/TR/xquery-operators/
XQuery 1.0 Formal Semantics
World Wide Web Consortium. XQuery 1.0 Formal Semantics. W3C Working Draft, 15 November 2002. See http://www.w3.org/TR/query-semantics/.

C.2 Non-normative References

ISO 8601
International Organization for Standardization (ISO). Representations of Dates and Times, 2000-08-03. Available from http://www.iso.ch/
XPath 2.0 Requirements
World Wide Web Consortium. XPath Requirements Version 2.0. W3C Working Draft 14 February 2001. See http://www.w3.org/TR/xpath20req.
XQuery
World Wide Web Consortium. XQuery 1.0: An XML Query Language. W3C Working Draft, 15 November 2002. See http://www.w3.org/TR/xquery/
XQueryX 1.0
World Wide Web Consortium. XQueryX, Version 1.0. W3C Working Draft, 7 June 2001. See http://www.w3.org/TR/xqueryx [Ed. Note: As of the date of this publication, XQueryX has not incorporated recent language changes; it will be made consistent with this document in its next edition.]
XSLT 2.0
World Wide Web Consortium. XSL Transformations (XSLT) 2.0. W3C Working Draft. See http://www.w3.org/TR/xslt20/

C.3 Background References

Lorel
Serge Abiteboul, Dallan Quass, Jason McHugh, Jennifer Widom, and Janet L. Wiener. The Lorel Query Language for Semistructured Data. International Journal on Digital Libraries, 1(1):68-88, April 1997. See "http://www-db.stanford.edu/~widom/pubs.html
ODMG
Rick Cattell et al. The Object Database Standard: ODMG-93, Release 1.2. Morgan Kaufmann Publishers, San Francisco, 1996.
Quilt
Don Chamberlin, Jonathan Robie, and Daniela Florescu. Quilt: an XML Query Language for Heterogeneous Data Sources. In Lecture Notes in Computer Science, Springer-Verlag, Dec. 2000. Also available at http://www.almaden.ibm.com/cs/people/chamberlin/quilt_lncs.pdf. See also http://www.almaden.ibm.com/cs/people/chamberlin/quilt.html.
SQL
International Organization for Standardization (ISO). Information Technology-Database Language SQL. Standard No. ISO/IEC 9075:1999. (Available from American National Standards Institute, New York, NY 10036, (212) 642-4900.)
XML-QL
Alin Deutsch, Mary Fernandez, Daniela Florescu, Alon Levy, and Dan Suciu. A Query Language for XML. See http://www.research.att.com/~mff/files/final.html
XPath 1.0
World Wide Web Consortium. XML Path Language (XPath) Version 1.0. W3C Recommendation, Nov. 16, 1999. See http://www.w3.org/TR/xpath.html
XQL
J. Robie, J. Lapp, D. Schach. XML Query Language (XQL). See http://www.w3.org/TandS/QL/QL98/pp/xql.html.
YATL
S. Cluet, S. Jacqmin, and J. Simeon. The New YATL: Design and Specifications. Technical Report, INRIA, 1999.

C.4 Informative Material

Character Model
World Wide Web Consortium. Character Model for the World Wide Web. W3C Working Draft. See http://www.w3.org/TR/charmod/
RFC2396
T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax. IETF RFC 2396. See http://www.ietf.org/rfc/rfc2396.txt.
XML Infoset
World Wide Web Consortium. XML Information Set. W3C Recommendation 24 October 2001. See http://www.w3.org/TR/xml-infoset/
XPointer
World Wide Web Consortium. XML Pointer Language (XPointer). W3C Last Call Working Draft 8 January 2001. See http://www.w3.org/TR/WD-xptr
XSLT 1.0
World Wide Web Consortium. XSL Transformations (XSLT) 1.0. W3C Recommendation. See http://www.w3.org/TR/xslt

D Glossary

Ed. Note: To be done.

E Conformance

XPath 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.

F Backwards Compatibility with XPath 1.0 (Non-Normative)

This section provides a summary of the main areas of incompatibility between XPath 2.0 and [XPath 1.0]. Many of these are areas where the specification still has open issues outstanding, so this list should not be taken as final. It is the intention of the working group to review all known incompatibilities before final publication.

The list given here assumes (a) that the source document is processed in the absence of a schema, and (b) that XPath compatibility mode is true.

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 respecively.

G XPath 2.0 and XQuery 1.0 Issues (Non-Normative)

Values for Status has the following meaning:

resolved: a decision has been finalized and the document updated to reflect the decision.

decided: recommendations and decision(s) has been made by one or more of the following: a task-force, XPath WG, or XQuery WG.

draft: a proposal has been developed for possible future inclusion in a published document.

active: issue is actively being discussed.

unassigned: discussion of issue deferred.

subsumed: issue has been subsumed by another issue.

(parameters used: kwSort: cluster, kwFull: brief, kwDate: 00000000).


NumClPrClusterStatusLocusDescriptionResponsible
2931activexquery Cdata and CharRef Semantics
3231activexpath Should "unordered" be included in XPath?
96o-1(in)equality-operatorsdecidedxpath Normalized Equality
3281cdata sectionactivexquery What does CDATA section constructor construct?
257D1collectionsdecidedxpath Does collection() always return same result?
3331conformanceactivexpath Optional Features vs. Conformance Levels
238o-1consistencyactivexpath Consistency: tradeoff between interoperability and efficiency
239o-1consistencyactivexpath Consistency: bracketing of nested expressions
240o-1consistencyactivexpath Consistency: parenthesizing test expressions
2522consistencyactivexquery "sort by" rather than "sortby" for consistency?
2881constructor-expractivexquery Element Constructor Attribute Order
289T1constructor-expractivexquery Attribute Value Construction from Elements
2901constructor-expractivexquery Element Attribute Constructor Name Type
291T1constructor-expractivexquery Element Construction anySimpleType Sequence Content
2921constructor-expractivexquery Element Construction Sequence vs Multi-expr
2861constructor-exprdecidedxquery Element Construction vs Streaming
145o-1constructor-exprunassignedxquery Copy and Reference Semantics
3291constructorsactivexquery Duplicate attribute constructors
258D2documentsdecidedxpath Identity of Document Nodes
3361editorialactiveall Markup in documents for errors
3371editorialactiveall Add markup in documents for errors
99o-1errorunassignedxquery TRY/CATCH and error()Dana
3392errorsactivexquery Error type for attributes constructed too late
3401errorsactivexpath How to identify errors?
160o-2execution-modelactivexquery Naive Implementation Strategy
3171extensionsactivexquery XQuery Extension Mechanisms
2721external-functionsactivexpath External Functions
2731external-objectsactivexpath External Objects
3351formal-semanticsactivexpath XPath/XQuery's current semantics greatly interferes with optimization
2652FTTF-xml:langactivexpath-fulltext How do we determine the xml:lang for a node if it inherits xml:lang from a higher-level node?
2662FTTF-xml:langactivexpath-fulltext Do we support the sublanguage portion of xml:lang?
3271functionsactivexpath Evaluate unused function parameters?
124o-1functionsunassignedxquery External Functions
157o-1functionsunassignedxquery Function Libraries
223o-1functions externalactivexquery We need a way to declare external functions
342o-1grammaractivexquery Prolog syntax
168o-1groupbyunassignedxquery GROUPBY
2951lexical-representationactivexquery Lexical Representation of Atomic Values
151o-1literal-XMLunassignedxquery Cutting and pasting XML into XQuery
74o-1module-semanticsactivexquery Module syntax
75o-1module-semanticsunassignedxquery Importing Modules
79o-1module-syntaxunassignedxquery Encoding
228o-2namespace functionsactivexpath Should we keep the default function namespace, and the xf: namespace?
219o-1namespacesactivexquery Context: namespaces
3191namespacesactivexquery Namespace definitions and in-scope namespaces
3431namespacesactivexpath Do functions in the null namespace clash with functions in the default namespace?
2472namespacesdecidedxpath What does default namespace(s) affect?
187o-1operatorsactivexfo Operations supported on date/time types
5o-2reserved-wordsactivexpath Reserved words
123o-1serializationactivexquery Linearization/Serialization
2442serializationactivexquery CDATA sections and serialization
2423sortactivexquery Sortby on partially ordered values?
3001sortactivexquery Should sorting of untyped data be prohibited?
155o-1sortdecidedxquery Sorting by Non-exposed Data
2433sortdecidedxpath Provide an example of sorting "disappearing"
2512sortdecidedxquery Sorting "input to loop", not the result
3181sortdecidedxquery Add 'order by' clause to FLWR?
235o-1syntaxactivexpath Need parenthesis in conditional expression?
237o-1syntaxactivexquery Need parenthesis in type switch expression?
2462syntaxactivexquery Nested XQuery comments allowed?
3411syntaxactivexpath Problems with SequenceType
144o-1syntaxdecidedxquery Escaping Quotes and Apostrophes
2671syntaxdecidedxpath Syntax problems with "validate"
208o-1syntax curly braceactivexquery Multiple curly braces allowed?xquery
2452syntax curly braceactivexquery Are {} in text evaluated?
232o-1syntax operators dateactivexpath Use "+" and "-" on dates and durations?
213o-1syntax quotesactivexpath How to get quotes etc in string literals?
2612syntax quotesactivexquery Quoting rules in nested expressions in attribute value construction
206T2typesactivexpath Typing support in XPath
224T2typesactivexquery Why do we want to allow optional returns and DataType?
297T1typesactivexpath Should XPath have "type binding" in variable?
306T1typesactivexpath PSVI to Data Model mapping part of normative text?
307T1typesactivexpath Schema Types from input documents?
308T1typesactivexpath Type Soundness
310T1typesactivexquery Are the children of a newly constructed element typed?
312T1typesactivexquery What to do about list types?
313T1typesactivexquery What to do about union types?
314T1typesactivexquery Partial support for SCHEMA IMPORT in Basic XQuery?
316T1typesactivexpath Is AnySimpleType = AnySimpleType*?
320T1typesactivexquery Should different conformance levels give the same result for the same query and data?
325T1typesactivexpath Refering to element that is not in the in-scope schema def.
326T1typesactivexpath Semantics of element foo of type T
330T1typesactivexquery Should "some" do type filtering?
331T1typesactivexpath Static vs. dynamic dispatch for arithmetics
3321typesactivexpath Schema Import, Static Typing: what is interoperable?
43T1type-semanticsactivexquery Defining Behavior for Well Formed, DTD, and Schema Documents
48T3type-semanticsactivealgebra CASE not a subtype
271T1type-semanticsactivexpath Type compatibility of heterogeneous union types
284T1type-semanticsactivexpath Static Named Typing
294T1type-semanticsactivexquery Should all elements and attributes have type annotations?
334T1type-semanticsactivexpath How are documents for which validation has failed processed?
47T2type-semanticsdecidedxquery Subtype Substitutability
279T1type-semanticsdecidedxpath Should there be a lightweight cast?
56T3type-syntaxactivexquery Human-Readable Syntax for Types
164o-1updatesunassignedxquery UpdatesJonathan
3211validateactivexquery Is validate strict or lax?
3221validateactivexquery "validate" strict/lax override?
2502variablesactivexquery Declaring Variables in Prolog
2641variablesactivexpath Shadowing of Variables
3241variablesactivexquery How can variables be bound external to XQuery itself?
2991whitespaceactivexquery Does character reference to whitespace change whitespace handling?
3111whitespaceactivexquery Whitespace and Attribute Constructors
3381whitespaceactivexquery Handling of whitespace and character references
191o-1whitespacedecidedxquery Whitespace handling in element constructors
130o-1xquery-alignmentactivealgebra Algebra MappingJerome
152o-1xqueryxactivexqueryx XML-based Syntax

5. xpath-issue-reserved-words: Reserved words

Locus: xpath Cluster: reserved-words Priority: o-2 Status: active
Originator: XQuery
Reserved words

Description

XPath 1.0 has no reserved words. The current XQuery spec attempts to avoid reserved words but the result is that the XQuery grammar relies heavily on lexing tricks that make it difficult to document and difficult to extend. There is currently a substantial feeling in the XQuery group that the language should have some reserved words, which would be an incompatible change from XPath 1.0.

XSL WG Position: Exceptionally strong feeling that requiring element names that match a reserved word to be escaped is utterly unacceptable. If reserved words are required they must start with an escape character so they cannot conflict with element names. Attempt to maintain grammar and revisit this issue as necessary. We recognize that there is a problem but solutions are all distasteful.

Interactions and Input

43. xquery-define-schema-variants: Defining Behavior for Well Formed, DTD, and Schema Documents

Issue Class: T Locus: xquery Cluster: type-semantics Priority: 1 Status: active
Originator: Don Chamberlin
Defining Behavior for Well Formed, DTD, and Schema Documents

Description

We should specify the behavior of XQuery for well formed XML, XML validated by a schema, and XML validated by a DTD.

Proposed Resolution

The mapping of a DTD validated or well formed document still needs to be defined in the Data Model.

47. xquery-subtype-substitutability: Subtype Substitutability

Issue Class: T Locus: xquery Cluster: type-semantics Priority: 2 Status: decided
Originator: XQuery Editors
Subtype Substitutability

Description

Should XQuery 1.0 support subtype substitutability for function parameters?

If subtype substitutability is not supported in XQuery Version 1, the motivation for TYPESWITCH is weakened and the decision to support TYPESWITCH should be revisited.

Interactions and Input

[link to member only information] Michael Rys:

I think this is still an open issue given some semantic issues that we
found between named subtype substitutability and derivation by
extension. I will send mail on this issue this week,

Actual Resolution

Addressed by the "Named Typing" proposal.

Decision by: xpath-tf on 2002-05-07 ([link to member only information] )

Decision by: xquery on 2002-05-22 ([link to member only information] )

Decision by: xsl on 2002-06-27 ([link to member only information] )

Accepting text in 2002-04-30 public draft.

48. xquery-typeswitch-case-not-subtype: CASE not a subtype

Issue Class: T Locus: algebra Cluster: type-semantics Priority: 3 Status: active
Originator: XML Query
CASE not a subtype

Description

If the types in the CASE branches are not subtypes of the TYPESWITCH, is this an error, or are these branches simply never executed? If the latter, should we require a warning?

56. xquery-type-syntax: Human-Readable Syntax for Types

Issue Class: T Locus: xquery Cluster: type-syntax Priority: 3 Status: active
Originator: Algebra Editors
Human-Readable Syntax for Types

Description

The Algebra has a syntax for declaring types. Up to now, XQuery uses XML Schema for declaring types. Is this sufficient? Some important questions:

  1. Are type names sufficient, or does XQuery really need its own syntax for declaring types?
  2. Would Normalized Universal Names (derived from MSL) be sufficient for type names?
  3. How will type names be bound to definitions?

74. xquery-module-syntax: Module syntax

Locus: xquery Cluster: module-semantics Priority: o-1 Status: active
Originator: XQuery Editors
Module syntax

Description

The definition and syntax of a query module are still under discussion in the working group. The specifications in this section are pending approval by the working group.

Future versions of the language may support other forms of query modules, such as update statements and view definitions.

75. xquery-import: Importing Modules

Locus: xquery Cluster: module-semantics Priority: o-1 Status: unassigned
Originator: XQuery Editors
Importing Modules

Description

The means by which a query module gains access to the functions defined an an external function library remains to be defined.

Should xmlns only be respected for construction, Xquery expressions but not functions, or also functions?

79. xquery-encoding: Encoding

Locus: xquery Cluster: module-syntax Priority: o-1 Status: unassigned
Originator: Jonathan Robie
Encoding

Description

Does XQuery need a way to specify the encoding of a query? For instance, should the prolog allow statements like the following?

ENCODING utf-16

96. xquery-normalized-equality: Normalized Equality

Locus: xpath Cluster: (in)equality-operators Priority: o-1 Status: decided
Originator: Mary Fernandez
Normalized Equality

Description

When elements are compared, are comments and PIs considered in the comparison? How is whitespace handled? Do we need to allow more than one way to handle these in comparisons?

Actual Resolution

Decision by: xquery on 2002-09-04 ([link to member only information] )

Decision by: xsl on 2002-10-03 ([link to member only information] )The XSL WG is not agreeable to blessing this.

"When elements are compared, are comments and PIs considered in the comparison?": NO

"How is whitespace handled?": This depends on the whitespace in the instance as per the data model.

"Do we need to allow more than one way to handle these in comparisons?": NO, not in XPath 2.0/XQuery 1.0.

99. xquery-try-catch-error: TRY/CATCH and error()

Locus: xquery Cluster: error Priority: o-1 Status: unassigned
Assigned to: Dana Originator: XQuery Editors
TRY/CATCH and error()

Description

We believe the following approach to error handling would be very useful - (1) introduce TRY <expression> CATCH <expression>, similar to try/catch in OO languages. Instead of having "throw" to throw objects, use error(<expression>), bind the result of the expression to the variable $err, and allow $err to be used in the CATCH clause.

Proposed Resolution

Dana Florescu has been assigned the task of writing a proposal for this.

123. null-serialization: Linearization/Serialization

Locus: xquery Cluster: serialization Priority: o-1 Status: active
Originator: XQuery
Linearization/Serialization

Description

When an empty element is linearized, should it get xsi:nil="True"? Option 8A: Yes. Option 8B: No. Option 8C: Only if it is declared to have required content and to be "nilable".

124. xquery-external-functions: External Functions

Locus: xquery Cluster: functions Priority: o-1 Status: unassigned
Originator: XQuery Editors
External Functions

Description

An extensibility mechanism needs to be defined that permits XQuery to access a library of functions written in some other programming language such as Java.

Some sources of information: the definition of external functions in SQL, the implementation of external functions in Kweelt.

130. algebra-mapping: Algebra Mapping

Locus: algebra Cluster: xquery-alignment Priority: o-1 Status: active
Assigned to: Jerome Originator: XQuery Editors
Algebra Mapping

Description

The algebra mapping is incomplete and out of date.

Proposed Resolution

Jerome has created a new version of the mapping, with help from Mary, Dana and Mugur.

144. xquery-escaping-quotes-and-apostrophes: Escaping Quotes and Apostrophes

Locus: xquery Cluster: syntax Priority: o-1 Status: decided
Originator: XML Query
Escaping Quotes and Apostrophes

Description

In attribute constructors and string constructors, XQuery uses quotes or apostrophes as delimiters. How are these characters escaped when they occur within strings that are created by one of these constructors?

Interactions and Input

[link to member only information] Michael Rys:

I asked a member of my team to check for a resolution that he can live
with. He said he has not found it and currently works on constructing
examples that shows the open issue.

Proposed Resolution

I propose that we use double-delimiters within a string literal, e.g. 'I don''t', and unlike most of my syntactic ideas, this proposal seemed to recieve general support.

Actual Resolution

Decision by: xpath-tf on 2002-04-30 ([link to member only information] )

Decision by: xquery on 2002-05-22 ([link to member only information] )

Decision by: xsl on 2002-06-27 ([link to member only information] )

Syntax in current draft has this, but explanatory text need to be added.

145. xquery-copy-reference: Copy and Reference Semantics

Locus: xquery Cluster: constructor-expr Priority: o-1 Status: unassigned
Originator: XQuery Editors
Copy and Reference Semantics

Description

Copy and reference semantics must be defined properly for updates to work. This must be coordinated with the algebra team.

151. xquery-cut-and-paste-xml: Cutting and pasting XML into XQuery

Locus: xquery Cluster: literal-XML Priority: o-1 Status: unassigned
Originator: XQuery Editors
Cutting and pasting XML into XQuery

Description

A variety of XML constructs can not be cut and paste into XQuery, including the internal subset, entities, notations, etc. Should we attempt to ameliorate this?

152. xquery-abql: XML-based Syntax

Locus: xqueryx Cluster: xqueryx Priority: o-1 Status: active
Originator: XML Query WG
XML-based Syntax

Description

XQuery needs an XML representation that reflects the structure of an XQuery query. Drafts of such a representation have been prepared, but it is not yet ready for publication.

155. xquery-phantom-sortby: Sorting by Non-exposed Data

Locus: xquery Cluster: sort Priority: o-1 Status: decided
Originator: Michael Rys
Sorting by Non-exposed Data

Description

Should we make it easier to sort by data that is not exposed in the result? Although the current language allows this, it is difficult to define complex sort orders in which some items are not exposed in the result and others are computed in the expression that is sorted. Is there a more convenient syntax for this that would be useful in XQuery?

Interactions and Input

Proposed Resolution

Here is an example:

FOR $e IN //employee
WHERE ...
RETURN
  <newe>$e/name</newe>
SORTBY
  -- Now I would like to sort by salary but cannot.

Instead, the query would have to be written as

FOR $e IN (FOR $x IN //employee RETURN $x SORTBY employee/salary/data())
WHERE ...
RETURN
  <newe>$e/name</newe>

Which seems awkward.

The question is of course how we can integrate the SORTBY in an other
way.

For example, could we say

FOR $e IN //employee
WHERE ...
SORTBY $e/salary/data()
RETURN
   <newe>$e/name</newe>

?

Best regards
Michael

Actual Resolution

Decision by: xquery on 2002-09-18 ([link to member only information] )

Decision by: xsl on 2002-10-10 ([link to member only information] )Confirming that there are no concerns for the resolution of this XQuery only issue.

Resolved by the adoption of the proposal to add "orderby" to the FLWR expression and to drop the previous "sortby" syntax/

157. xquery-function-library: Function Libraries

Locus: xquery Cluster: functions Priority: o-1 Status: unassigned
Originator: XQuery Editors
Function Libraries

Description

XQuery needs a mechanism to allow function definitions to be shared by multiple queries. The XQuery grammar allows function definitions to occur without a query expression.

We must provide a way for queries to access functions in libraries. For instance, we might add an IMPORT statement to XQuery, with the URI of the functions to be imported. It must be possible to specify either that (1) local definitions replace the imported definitions, or (2) imported definitions replace the local ones.

160. xquery-naive-implementation: Naive Implementation Strategy

Locus: xquery Cluster: execution-model Priority: o-2 Status: active
Originator: Marton Nagy
Naive Implementation Strategy

Description

Marton Nagy has suggested that it would be helpful to describe a naive implementation strategy for XQuery.

A naive XQuery implementation might parse the query, map it to Algebra syntax, and pass it to an Algebra implementation to request type checking from the algebra, returning an error if there were static type errors. A naive implementation might then request query execution from the algebra, get the results from the algebra and return it to the user.

Alternatively, the implementation might have its own algebra for execution, or it might generate statements in a specific implementation language such as XPath or SQL.We expect a wide variety of implementation approaches to be used in practice.

164. xquery-updates: Updates

Locus: xquery Cluster: updates Priority: o-1 Status: unassigned
Assigned to: Jonathan Originator: XQuery Editors
Updates

Description

We believe that a syntax for update would be extremely useful, allowing inserts, updates, and deletion. This might best be added as a non-normative appendix to the syntax proposal, since the algebra is not designed for defining this portion of the language.

168. xquery-groupby: GROUPBY

Locus: xquery Cluster: groupby Priority: o-1 Status: unassigned
Originator: XML Query
GROUPBY

Description

Does XQuery need an explicit GROUPBY expression? This would not add expressive power, but would be convenient, and may be easier to optimize.

187. date-time-operators: Operations supported on date/time types

Locus: xfo Cluster: operators Priority: o-1 Status: active
Originator: XPath Editors
Operations supported on date/time types

Description

What arithmetic operations should be supported on date/time types?

Issue is for material in sec 2.5. in Working Draft 2001-11-28.

Actual Resolution

Decision by: xquery on 2002-02-06 ([link to member only information] )

Locus should be Functiond and Operators

191. whitespace-in-element-constructors: Whitespace handling in element constructors

Locus: xquery Cluster: whitespace Priority: o-1 Status: decided
Originator: XPath Editors
Whitespace handling in element constructors

Description

How is whitespace handled in element constructors?

Issue is for material in sec 2.8. in Working Draft 2001-11-28.

Interactions and Input

[link to member only information] Michael Kay:

The XQuery WG requested information from XSL WG
as to how we currently deal with whitespace, in the hope that we can provide
an off-the-shelf solution to the problem.

In response to the action, here's a description of what XSLT does.

The stylesheet is an XML document. In constructing its infoset, all
processing instructions, comments, and whitespace-only text nodes are
discarded. (To be absolutely precise, PIs and comments are discarded; then
adjacent text nodes are merged; then whitespace-only text nodes are removed
from the tree). Whitespace text nodes are retained however, in two
circumstances: (a) if the whitespace text node is a child of an <xsl:text>
element, and (b) if an ancestor element specifies xml:space="preserve".

Certain elements in the stylesheet (for example, xsl:element) contain a
"content constructor". A content constructor is a sequence of XSLT
instructions, literal result elements, and literal text nodes. In evaluating
a content constructor, XSLT instructions do whatever the semantics of the
particular instruction say, while literal result elements and literal text
nodes are copied to the result tree.

The effect of this is that a whitespace-only text node in the stylesheet is
copied to the result tree only if either (a) it appears immediately inside
<xsl:text>, or (b) it is within the scope of an xml:space="preserve"
attribute.

Whitespace that is adjacent to non-white text in a literal text node is
copied to the result tree.

The effect of these rules is as follows:

=======================================
<a>  </a>
generates an empty element:
<a/>
=======================================
<a xml-space="preserve">  </a>
generates:
<a xml-space="preserve">  </a>
=======================================
<a><xsl:text>  </xsl:text></a>
generates:
<a>  </a>
=======================================
<a>
  <b/>
<a>
generates:
<a><b/></a>
=======================================
<a>Some text
  <b/>
</a>
generates:
<a>Some text
  <b/></a>
=======================================

There are other complications with whitespace. Whitespace in the result tree
can come from the source document as well as from the stylesheet; XSLT
provides control over whether whitespace-only text nodes in the source
document are significant or not. Whitespace can also be generated in the
output during serialization, if the xsl:output option indent="yes" is
specified.

Also of course the XSLT rules apply in addition to the XML rules. XML for
example normalizes line endings and normalizes whitespace (but not 

character references) in attribute values. This happens outside XSLT's
control. Whitespace character references such as   are treated
differently from literal whitespace by the XML processor, but are treated
identically to literal whitespace by the XSLT processor.

It's fair to say that these rules create a fair bit of confusion. It usually
doesn't matter for generating HTML, because whitespace in HTML is rarely
significant. For generating text files, it can be quite tricky. However, the
rules are well-defined and a user who understands the rules can always get
the required output.

What should XQuery do? I'd suggest mimicking these rules as closely as
possible, if only because users then only have to learn one set of confusing
rules rather than two. I can't think of any obvious improvements that would
make the system less confusing. Where the user wants to explicitly output
whitespace, of course, <a>{'  '}</a> provides a suitable alternative to
XSLT's <xsl:text> instruction.

This analogy would suggest that <a>  {'x'}  </a> should output <a>x</a>,
while <a>z {'x'} y</a> should output <a>z x y</a>: that is, the characters
between <a> and "{" are ignored if they consist entirely of whitespace, but
are all significant if any of them is non-whitespace. <a> </a> should output
<a/>, as should <a> </a>. This is only a suggestion, of course, the
decision is entirely for XQuery to make.

Mike Kay

Actual Resolution

Decision by: xquery on 2002-09-11 ([link to member only information] )

Decided: Resolve this by adopting the whitespace proposal.

206. xpath-datatype-support: Typing support in XPath

Issue Class: T Locus: xpath Cluster: types Priority: 2 Status: active
Originator: Mike Kay
Typing support in XPath

Description

Which of these type productions (CAST, TREAT, ASSERT, TYPESWITCH...) belong in XPath? (ie common to XQuery and XPath)

The list is now (2002-10): CAST, TREAT, VALIDATE, INSTANCE OF, types on variable bindings, TYPESWITCH.

208. multiple-curly-braces: Multiple curly braces allowed?

Locus: xquery Cluster: syntax curly brace Priority: o-1 Status: active
Assigned to: xquery Originator: Phil Wadler
Multiple curly braces allowed?

Description

Can you have multiple matching curly braces inside an attribute value? How is it evaluated? What is the associated typing? Note that the BNF permits this.

Actual Resolution

Decision by: xsl on 2002-10-18 ([link to member only information] )Joint f2f

Decision by: xquery on 2002-10-18 ([link to member only information] )Joint f2f

Can you have multiple matching curly braces inside an attribute value?

Braces for text must be escaped. <e a="{{{{}}"/>

Nesting is no problem:

<e a="{{{{{text{true()}}}}"/>

How is it evaluated?

With a parser.

What is the associated typing?

Not a syntax issue.

213. syntax-special-characters: How to get quotes etc in string literals?

Locus: xpath Cluster: syntax quotes Priority: o-1 Status: active
Originator: Andrew Eisenberg
How to get quotes etc in string literals?

Description

How do you get strings such as single and double quote to be allowed in character strings?

      <name>Ben &amp; Jerry&apos;s</name>
  

eg should doubling a quote escape it?

It would seem that we need to allow these CharRef's in string literals as well.

Interactions and Input

[link to member only information] Andrew Eisenberg:

XPath TF Meeting #91 suggested closing issue 213.

Issue 213 has the title "syntax-special-characters: How to get quotes etc
in string literals?" Perhaps we have focused on the quotes, and not the
"etc."

I might want to construct an element as follows (where ™ represents
the trademark symbol "?"):

   <company name='Ben & Jerry's ™'> ... </company>


To write this as a ComputedElementConstructor, I would have to write to
following:

   element company
   {
      attribute name { 'Ben & Jerry''s ', xf:codepoints-to-string(8482) }
      ...
   }

To pass this string as an argument to a function I'd have to write the
following:

   f (xf:concat ('Ben & Jerry''s ', xf:codepoints-to-string(8482)))


It's rather jarring to allow CharRef in ElementContent and
AttributeValueContent, but not in string literals. I suggest that we add
CharRef to the content of a string literal.

                                          -- Andrew

Actual Resolution

Decision by: xpath-tf on 2002-10-16 ([link to member only information] )

Decision by: xsl on 2002-10-31 ([link to member only information] )

The XPath TF believes that it is fixed as far as XPath is concerned. Doubled quotes are allowed. CharRef is a query-specific problem, and is subsumed by other issues.

219. namespaces-context: Context: namespaces

Locus: xquery Cluster: namespaces Priority: o-1 Status: active
Originator: Michael Rys
Context: namespaces

Description

XQuery must specify how namespaces are handled in the context.

Note that:

1. An unprefixed element name used as a nametest in a query has the namespaceURI associated with the default element namespace from the context.

Note: we may decide that this is the same as the default namespace of the in-scope namespaces, but this is not certain.

2. An unprefixed attribute has a null namespaceURI

223. external-function-definition: We need a way to declare external functions

Locus: xquery Cluster: functions external Priority: o-1 Status: active
Originator: Michael Rys
We need a way to declare external functions

Description

Should we allow external functions to be defined using a syntax like this?

       [71a] ExternalFnDef ::= {"define" S "external" S "function"}
            QName "(" ParamList? ")" ("returns" Datatype)?
  

Interactions and Input

224. function-return-datatype: Why do we want to allow optional returns and DataType?

Issue Class: T Locus: xquery Cluster: types Priority: 2 Status: active
Originator: Michael Rys
Why do we want to allow optional returns and DataType?

Description

Would we prefer a syntax that requires explicit declaration of a general type when a function is to be loosely typed, rather than use the current syntax in which the type is omitted when the function is untyped.

228. default-namespace-functions: Should we keep the default function namespace, and the xf: namespace?

Locus: xpath Cluster: namespace functions Priority: o-2 Status: active
Originator: Scott Boag
Should we keep the default function namespace, and the xf: namespace?

Description

The question was raised of whether the Query WG and F&O TF have 1) a good rationale for putting built-in functions in a namespace, and 2) a consistent story about how this will relate to default namespace declarations and user-defined functions.

It would seem odd to have to have all user defined functions put in the FandO namespace if a namespace is not declared for it. If you do not do that, then user defined functions that don't require a prefix will not match the QName.

And, if there is not a good rational that provides user benifits, then it seems like we are going through a lot of additional complexity for little or no benefit.

Interactions and Input

[link to member only information] Kristoffer Rose:

232. operators-on-date: Use "+" and "-" on dates and durations?

Locus: xpath Cluster: syntax operators date Priority: o-1 Status: active
Originator: Phil Wadler
Use "+" and "-" on dates and durations?

Description

Should we use the operators + - on dates and durations, when addition of dates is not associative or commutative?

235. parenthesis-conditional-expression: Need parenthesis in conditional expression?

Locus: xpath Cluster: syntax Priority: o-1 Status: active
Originator: Phil Wadler
Need parenthesis in conditional expression?

Description

Now that we have keywords, do we need parentheses in the conditional expression?

Actual Resolution

Decision by: xpath-tf on 2002-10-16 ([link to member only information] )

Decision by: xsl on 2002-10-31 ([link to member only information] )

Recommendation to drop the "then".

Subsequently some problems and differing views were expressed. The discussions will continue.

237. parenthesis-type-switch-expression: Need parenthesis in type switch expression?

Locus: xquery Cluster: syntax Priority: o-1 Status: active
Originator: Phil Wadler
Need parenthesis in type switch expression?

Description

Now that we have keywords, do we need parentheses in the type switch expression?

238. consistency-tradeoffs: Consistency: tradeoff between interoperability and efficiency

Locus: xpath Cluster: consistency Priority: o-1 Status: active
Originator: Phil Wadler
Consistency: tradeoff between interoperability and efficiency

Description

Consistent tradeoff between interoperability and efficiency. There are a number of places where XQuery must choose between pinning down precise behaviour or offering flexibility to the implementor. These include whether order in "for" expressions is significant, whether sorting is stable, whether order is significant for duplicate elimination, whether order is significant when finding the union, merge, except of sequences of values, and the like. We should have a consistent policy for making these choices.

239. consistency-bracketing: Consistency: bracketing of nested expressions

Locus: xpath Cluster: consistency Priority: o-1 Status: active
Originator: Phil Wadler
Consistency: bracketing of nested expressions

Description

Consistent bracketing of nested expressions. Some nested expressions are surrounded by parentheses (treat, cast, assert), some nested expressions are surrounded by braces (element construction, function body), and some nested expressions are not bracketed (for expression, conditional expression). We should have a consistent policy for bracketing of nested expressions.

240. consistency-parenthesizing-test-expressions: Consistency: parenthesizing test expressions

Locus: xpath Cluster: consistency Priority: o-1 Status: active
Originator: Phil Wadler
Consistency: parenthesizing test expressions

Description

Consistent parenthesizing of test expressions. Some test expressions are surrounded by parentheses (conditional, type switch) and some are not (where). We should have a consistent policy for parenthesizing of test expressions.

242. sortby-partial-order: Sortby on partially ordered values?

Locus: xquery Cluster: sort Priority: 3 Status: active
Originator: Michael Rys
Sortby on partially ordered values?

Description

I was unable to find the semantics of what happens of sortby tries to order based on a base type that only has partial order (e.g., Duration). Can we explicitly disallow this?

243. sort-disappearing: Provide an example of sorting "disappearing"

Locus: xpath Cluster: sort Priority: 3 Status: decided
Originator: Michael Rys
Provide an example of sorting "disappearing"

Description

Provide an example of

   (employee sortby data(salary))/name
  

Actual Resolution

Decision by: xquery on 2002-09-11 ([link to member only information] )

Decision by: xsl on 2002-10-10 ([link to member only information] )

Decided to leave this to editorial discretion.

244. cdata-serialization: CDATA sections and serialization

Locus: xquery Cluster: serialization Priority: 2 Status: active
Originator: Michael Rys
CDATA sections and serialization

Description

What are the semantics of CDATA sections in XQuery? Are they preserved in the data model for serialization?

245. curly-braces-in-text: Are {} in text evaluated?

Locus: xquery Cluster: syntax curly brace Priority: 2 Status: active
Originator: Michael Rys
Are {} in text evaluated?

Description

In attribute definitions, "{a}" will be interpreted as expression a returning the value for the attribute. Is this also the case for texts in general (inside an element construction)?

Actual Resolution

Decision by: xsl on 2002-10-18 ([link to member only information] )Joint f2f

Decision by: xquery on 2002-10-18 ([link to member only information] )Joint f2f

Yes it will be evaluated, for example in:

<a>this is {@color} text</a>

246. nested-comments: Nested XQuery comments allowed?

Locus: xquery Cluster: syntax Priority: 2 Status: active
Originator: Michael Rys
Nested XQuery comments allowed?

Description

Nested XQuery comments allowed?

247. namespace-default-affecting: What does default namespace(s) affect?

Locus: xpath Cluster: namespaces Priority: 2 Status: decided
Originator: XPath TF
What does default namespace(s) affect?

Description

What is effect of default namespace declarations on unprefixed QNames that may occur in element constructors, attribute constructors, and name tests (or anywhere else).

In XPath 1.0, in-scope namespace decls effect prefixed QNames, but default namespace decl does not effect unprefixed names in a name test. In XSLT 2.0, we introduced multiple default namespace decls :one for constructed elements, one for names in xpath expressions.

Actual Resolution

Decision by: xquery on 2002-09-11 ([link to member only information] )

Decided to accept status quo:

- default element namespace defines a namespace URI that is associated with unprefixed names of elements and types.

- default function namespace defines a namespace URI that is associated with unprefixed names of functions.

250. declaring-variables-in-prolog: Declaring Variables in Prolog

Locus: xquery Cluster: variables Priority: 2 Status: active
Originator: Jonathan Robie
Declaring Variables in Prolog

Description

Functions in a function library often need to access the same variables. For instance, a function library that manipulates a grammar may need to use the following variables in many functions:

$grammar := document("xpath-grammar.xml")/g:grammar
$target := "xquery"

One possible syntax for this is:

'define' ''variable' varname ':=' expr

The above production would occur only in the prolog.

251. sort-by: Sorting "input to loop", not the result

Locus: xquery Cluster: sort Priority: 2 Status: decided
Originator: Phil Wadler
Sorting "input to loop", not the result

Description

Consider this query:

   for $x in /books/book, $y in /reviews/review
   where $x/isbn = $y/isbn
   return <newbook>{ $x/title, $x/author, $y/reviewer }</newbook>
   sortby isbn

This is an error, since isbn doesn't appear in newbook. (The static type system would catch this error.) What you have to write is

   for $z in
     for $x in book, $y in review
     where $x/isbn = $y/isbn
     return <dummy>{ $x/title, $x/author, $y/reviewer, $x/isbn }</dummy>
     sortby isbn
   return <newbook>{ $z/title, $z/author, $z/reviewer }</newbook>

This is painful.

I think that XQuery should support this syntax, or something similar:

   for $x in book, $y in review
   where $x/isbn = $y/isbn
   sortby $x/isbn
   return <newbook>{ $x/title, $x/author, $y/reviewer }</newbook>

Our plate is full with more important matters just now, but I hope we could fix this before we finalize XQuery.

Actual Resolution

Decision by: xquery on 2002-09-18 ([link to member only information] )

Decision by: xsl on 2002-10-10 ([link to member only information] )Confirming that there are no concerns for the resolution of this XQuery only issue.

Resolved by the adoption of the proposal to add "orderby" to the FLWR expression and to drop the previous "sortby" syntax.

252. sortby-name: "sort by" rather than "sortby" for consistency?

Locus: xquery Cluster: consistency Priority: 2 Status: active
Originator: Phil Wadler
"sort by" rather than "sortby" for consistency?

Description

By the way, why is it "sortby"? Since we changed "instanceof" to "instance of", shouldn't we change "sortby" to "sort by"?

257. collection-always-return-same: Does collection() always return same result?

Issue Class: D Locus: xpath Cluster: collections Priority: 1 Status: decided
Originator: XPath TF
Does collection() always return same result?

Description

Does collection() always return same result for the same URI? The same within the scope of a query/transformation? Are the nodes in the sequence identical?

Actual Resolution

Decision by: xpath-tf on 2002-10-16 ([link to member only information] )

Decision by: xquery on 2002-10-23 ([link to member only information] )

Decision by: xsl on 2002-10-31 ([link to member only information] )

It should return the same answer every time. Applies also to input(). We should use the same language as we use for document() and for current-dateTime().

258. document-nodes-identity: Identity of Document Nodes

Issue Class: D Locus: xpath Cluster: documents Priority: 2 Status: decided
Originator: Jonathan Robie
Identity of Document Nodes

Description

Consider the following query:

        if (document("foo.com") == document("foo.com"))
                then <yep/>
                else <nope/>

I would like the following output:

        <yep/>

I think we can achieve this if we say that the URI of a resource is used as its identity. However, one resource can be identified by more than one URI. Suppose that "foo.com/here/there/hi.xml" and "file://c:/temp/limerick-tei.xml" refer to the same resource. What does the following return?

if (document("foo.com/here/there/hi.xml") ==
document("file://c:/temp/limerick-tei.xml"))
        then <yep/>
        else <nope/>

Should we simply use the URI of the parameter to establish identity and say that the two do not match? Should we make the result implementation-dependent?

Actual Resolution

Decision by: xpath-tf on 2002-10-16 ([link to member only information] )

Decision by: xquery on 2002-10-23 ([link to member only information] )

Decision by: xsl on 2002-10-31 ([link to member only information] )

This is already covered by the existing spec, but we may want to review the language as part of the actions for issue 257.

261. attribute-constructor-quoting-rules: Quoting rules in nested expressions in attribute value construction

Locus: xquery Cluster: syntax quotes Priority: 2 Status: active
Originator: Michael Rys
Quoting rules in nested expressions in attribute value construction

Description

We currently say that in a constant string in XQuery, I can do any of the following three to escape quotes (please correct if I am wrong):

A. XQuery rule (works both in XQuery only and XQuery in XML embedding): quotes and double quotes are doubled if they are enclosed inside their own kind.

E.g.,

Lexical              Value in datamodel
'"'                  "
''''                 '
""""                 "
'""'                 ""

B. XML rules (work only in XQuery in XML embedding since XML parser will work:

B1. Use ' when string delimiter is " and viceversa. This of course does not preserve data fidelity, so if the difference between them is important, you will need to use B2.

B2. Entitize

I assume that I cannot do just B, but that I have to use B to get A. E.g., <a foo="&quot;"/> in an XML document is not a valid XQuery and I have to write <a foo="&quot;&quot;"/>

The problem that I have is that I do not know what the rules are for nesting quotes inside XQuery expressions:

What are the rules for:

<foo bar="{fnc1(<baz goo="{fnc2("string arg")}"/>)}"/>

Do I have to double and then triple? Does {} mean that the outside "" become inconsequential?

264. variables-shadowing: Shadowing of Variables

Locus: xpath Cluster: variables Priority: 1 Status: active
Originator: Michael Kay
Shadowing of Variables

Description

XSLT does not allow a local variable to be declared if there is already a local variable in scope with the same name. For example, the following is disallowed:

<xsl:variable name="i" select="0"/>
<xsl:for-each select="item">
  <xsl:variable name="i" select="$i + 1"/>
  <a><xsl:value-of select="$i"/></a>
</xsl:for-each>

This restriction has proved with experience to be a good thing, because users writing a construct such as the one above have almost invariably misunderstood the way variables work in a declarative language; if the construct were allowed, it would not give them the results they expect.

The equivalent XQuery expression is currently allowed:

let $i := 0
for $x in item
   let $i := $i + 1
   return <a>{$i}</a>

XPath 2.0 has no "let" expression, but it can include variable declarations, and these are allowed to shadow each other.

For XSLT users, it seems inconsistent that there should be different rules in XSLT and in XPath. The XSLT 1.0 rule, which makes variable shadowing an error, has proved useful in practice and we recommend that it should be adopted also for XPath 2.0 and XQuery 1.0.

Interactions and Input

265. lang-inheritance: How do we determine the xml:lang for a node if it inherits xml:lang from a higher-level node?

Locus: xpath-fulltext Cluster: FTTF-xml:lang Priority: 2 Status: active
Originator: FTTF
How do we determine the xml:lang for a node if it inherits xml:lang from a higher-level node?

Description

How do we determine the xml:lang for a node if it inherits xml:lang from a higher-level node?

266. lang-sublanguage-support: Do we support the sublanguage portion of xml:lang?

Locus: xpath-fulltext Cluster: FTTF-xml:lang Priority: 2 Status: active
Originator: FTTF
Do we support the sublanguage portion of xml:lang?

Description

Do we support the sublanguage portion of xml:lang? If so, how?

267. validate-syntax-problem: Syntax problems with "validate"

Locus: xpath Cluster: syntax Priority: 1 Status: decided
Originator: XPath TF
Syntax problems with "validate"

Description

If "validate" is in XPath the "{}" in the syntax conflicts with the current use in XPath. It needs to change to use "()" instead.

Actual Resolution

Decision by: x-editors on 2002-10-02 ([link to member only information] )

Scott: We can close this because {} does not create a problem.

Decision by: xsl on 2002-10-18 ([link to member only information] )Joint f2f

Decision by: xquery on 2002-10-18 ([link to member only information] )Joint f2f

It has been confirmed that there are no problems, example:

<e a="{(validate {bookdoc})/title}"/>

271. heterogenous-union-types-compatibility: Type compatibility of heterogeneous union types

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: active
Originator: XQuery WG
Type compatibility of heterogeneous union types

Description

Currently the formal semantics maps arithmetic and comparison operations that have union types as (at least of one of) their argument types to a runtime type switch. This has serious unwanted consequences for "algebraization" of queries and optimization and leads to some surprising static typing results.

Should we make non-promotable union types on such operations a type error instead?

272. external-functions: External Functions

Locus: xpath Cluster: external-functions Priority: 1 Status: active
Originator: Michael Kay
External Functions

Description

The ability to call external functions is an established feature of XSLT 1.0, and is retained in XSLT 2.0. The facility is widely used, and some significant libraries of external functions have been developed by third parties. We made an attempt to standardize language bindings for external functions in the XSLT 1.1 working draft, but this proved highly controversial and has been dropped. The facility remains, however, even though the binding mechanisms remain implementation-defined.

The XPath 2.0 specification continues to tolerate external functions, though it doesn't really acknowledge their existence properly. All we say is that the repertoire of functions that can be called is part of the context.

The issue is: should the function function-available() function be transferred from XSLT to XPath?

This function tests whether a named function is available, and returns true if it is, and false if it isn't. A typical call is:

if  (function-available('my:debug')) then my:debug('Hi!') else ()

This has two implications:

(a) a call on my:debug must not be a static error if the function is not available

(b) the names of functions (and the in-scope namespaces needed to resolve their QNames) must be available at run-time.

Logically the function-available() function has no dependencies on XSLT so it should be transferred to XPath.

273. external-objests: External Objects

Locus: xpath Cluster: external-objects Priority: 1 Status: active
Originator: Michael Kay
External Objects

Description

Part of the strength of external functions is that they can return objects that are outside the scope of the XPath type system. For example, a function library for performing SQL database access may have a function sql:connect() that returns an object representing a database connection. This object may be passed as an argument to calls on other functions in the SQL function library.

The way this is handled in XPath 1.0 is that the XPath specification defines four data-types, and explicitly leaves the host language free to define additional data types. We could probably live with a similar solution for XPath 2.0, but it's a fudge, and I think we ought to try and do better.

Note that the only things you can do with an external object (under the XSLT 1.0 rules) are to assign it to a variable, or pass it as the argument to another function. In practice I think implementations also allow external objects to have additional behavior, for example they might allow conversion to a string when used in a context where a string is required. I think we should leave such behavior implementation-defined rather than saying that it is always an error.

The question arises as to where external objects should fit into the type hierarchy. Should they be a top-level thing at the same level as "sequence", or should they be one level down, along with "node" and "atomic value"? I think it makes most sense to preserve the principle "everything is a sequence", which means that there are now three kinds of item: nodes, atomic values, and external objects.

Handling this rigorously sounds like quite a pervasive change to the spec, but I don't think it's as bad as it seems. I don't think we should add any language features to support external objects, with the possible exception of a keyword "external" in the type syntax so that one can test for it using "instance of". Functions and operators that work on any sequence (for example, count) should treat an external object like any other item in the sequence. Operations that expect nodes will fail if presented with an external object; operations that expect atomic values will also fail, except that implementations may define fallback conversions from external objects to atomic values.

279. xpath-lightweight-cast: Should there be a lightweight cast?

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: decided
Originator: Jonathan Robie
Should there be a lightweight cast?

Description

Should there be any provision for a lightweight cast that does not observe facets? Phil Wadler has suggested that 'validate' be used whenever full schema validation is desired, and 'cast' be used as a lightweight validation, which can be used for either simple or complex types, but which does not supply defaults, enforce facets, or check integrity constraints. It may be easier to optimize through cast than through validate, but supporting both constructs may confuse users due to their similarity. He suggests the following syntax for these expressions:

('cast'|'validate') as SequenceType ()
('cast'|'validate') 'in' ContextExpr { Expr }

Actual Resolution

Decision by: xquery on 2002-09-11 ([link to member only information] )

Decision by: xsl on 2002-10-10 ([link to member only information] )

Decided to reject this proposal. Cast checks all facets.

284. xquery-static-named-typing: Static Named Typing

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: active
Originator: Jonathan Robie
Static Named Typing

Description

The typing must be covered by a static interpretation. If the Formal Semantics encounters difficulties in producing the static semantics, we may need to change the dynamic semantics.

286. element-construction-vs-streaming: Element Construction vs Streaming

Locus: xquery Cluster: constructor-expr Priority: 1 Status: decided
Originator: Michael Rys
Element Construction vs Streaming

Description

The element construction rules in 2.8 make efficient streaming of element construction difficult/impossible. For example, we execute the following expression on a stream and serialize the result in a streaming processing (such as XSLT like applications):

<foo>{"foo", "bar", if (expr) then "baz" else <baz/>}</foo>

If expr is true, then this is serialized:

<foo>foo bar baz</foo>

If expr is false, then this is serialized: <foo>foobar<baz/></foo>

The implementation must cache up the "foo" and "bar" strings, just in case a sub-element node is constructed. If not, then I must insert a space between "foo" and "bar". This seems to contradict one of our explicit use scenarios in the XML Query Requirements (section 2.5).

Interactions and Input

Actual Resolution

Decision by: xquery on 2002-09-04 ([link to member only information] )

This issue has been addressed by the recent changes to the element constructor.

288. element-constructor-attribute-order: Element Constructor Attribute Order

Locus: xquery Cluster: constructor-expr Priority: 1 Status: active
Originator: Michael Rys
Element Constructor Attribute Order

Description

Unlike XSLT, attributes seem to be allowed anywhere which makes streaming implementations impossible. XSLT has the following rule:

"The following are all errors:

* Adding an attribute to an element after children have been added to it; implementations may either signal the error or ignore the attribute."

Example:

let $e := expr
return <a>{<b/>, ($e/@* | $e/*)</a>

XSLT would consider this an error. XQuery does not. This makes streaming impossible (see #element-construction-vs-streaming). Note that while the above query can easily be rewritten, there are cases (e.g. function calls) where the rewrite is not possible.

Interactions and Input

Proposed Resolution

XQuery should allow implementations to disallow attribute nodes that are specified after the first child node in the sequence. It should not allow disregarding them.

289. attribute-value-construction-from-elements: Attribute Value Construction from Elements

Issue Class: T Locus: xquery Cluster: constructor-expr Priority: 1 Status: active
Originator: Michael Rys
Attribute Value Construction from Elements

Description

What does XQuery do if assigning a list of element nodes to an attribute if the type of the attribute is not a list type?

Example:

<book isbn="{$i/booknum}" />:

This query implicitly gets rewritten to: <book isbn="{data($i/booknum)}" />

What happens if there are more than one booknum elements and ISBN is untyped or not a list type?

290. element-attribute-constructor-name-type: Element Attribute Constructor Name Type

Locus: xquery Cluster: constructor-expr Priority: 1 Status: active
Originator: Michael Rys
Element Attribute Constructor Name Type

Description

Does the name expression on dynamically computed names in element/attribute constructors be of type QName without implicit cast from string, QName with implicit cast from string, or string?

Proposed Resolution

If the name is constructed by an expression, the expected type is xs:QName. Xs:string is in general implicitly cast to xs:QName (and xs:anyURI).

291. element-construction-anySimpleType-sequence-content: Element Construction anySimpleType Sequence Content

Issue Class: T Locus: xquery Cluster: constructor-expr Priority: 1 Status: active
Originator: Michael Rys
Element Construction anySimpleType Sequence Content

Description

The current element construction treats sequences of anySimpleType values different from other simple typed values. This seems inconsistent. The document should make it clear why there is a difference. If there is a reason, is the reason good enough?

292. element-construction-sequence-vs-multi-expr: Element Construction Sequence vs Multi-expr

Locus: xquery Cluster: constructor-expr Priority: 1 Status: active
Originator: Michael Rys
Element Construction Sequence vs Multi-expr

Description

Which element construction rules cover

<e>{1, 2}</e>
vs
<e>{1}{2}</e>

293. cdata-charref-semantics: Cdata and CharRef Semantics

Locus: xquery Cluster: Priority: 1 Status: active
Originator: Michael Rys
Cdata and CharRef Semantics

Description

The data model cannot represent CDATA or CharRef, since the Information Set looses this information.

Proposed Resolution

The XQuery document should make it clear that:

1. CDATA sections and CharRefs inside XQueries that are not embedded inside XML (which is what the XQuery document only talks about), are syntactic helps to write queries that otherwise would need entitization (in the case if CDATA sections) or a unicode input device (CharRefs).

2. Implementations can chose to use this information as serialization hints to preserve the CDATA and entitization.

294. type-annotations-on-all-elems-attrs: Should all elements and attributes have type annotations?

Issue Class: T Locus: xquery Cluster: type-semantics Priority: 1 Status: active
Originator: Philip Wadler
Should all elements and attributes have type annotations?

Description

Should all elements and attributes have type annotations? In particular, should a newly-constructed element or attribute have a generic type annotation such as "anyType", rather than the current proposal in which it has no type annotation at all? (This is largely a cosmetic issue, about whether "anyType" should be denoted by an explicit annotation or by the absence of an annotation.)

Interactions and Input

295. lexical-representation-of-atomic-values: Lexical Representation of Atomic Values

Locus: xquery Cluster: lexical-representation Priority: 1 Status: active
Originator: xquery/xsl f2f
Lexical Representation of Atomic Values

Description

The wording in section 2.8.3 needs to be aligned with Data model and F&O; 'lexical representation' needs to be defined differently and be consistent in XQuery, Datamodel, F&O. It probably needs to be string value (canonical value of integer in W3C Schema has a "." so not appropriate [or we need to have our own definition of the canonical value...]).

297. binding: Should XPath have "type binding" in variable?

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: active
Originator: XQuery Editors
Should XPath have "type binding" in variable?

Description

The 2002-06-24 grammar introduces the "binding" production. "assert" is removed from both XQuery and XPath. "binding" currently requires reserved words. Should "binding" be in XPath?

Several reasons NOT to include it in XPath:

- grammar

- semantics don't match function call semantics

- rarely useful

- reads oddly for range variables if (some integer $x in (1,2,"fred") satisfies $x=1)

- biggest of all, users are asking us to simplify. We will get a very adverse reaction if we make "for" expressions more complicated.

But it is worrying to have such a big split between XPath and XQuery.

299. character-reference-whitespace: Does character reference to whitespace change whitespace handling?

Locus: xquery Cluster: whitespace Priority: 1 Status: active
Originator: XPath TF
Does character reference to whitespace change whitespace handling?

Description

In the whitespce proposal the treatment of whitespace character reference is different than treatment of literal whitespace (for "compatibility with XSLT/XPath 1.0") and this does not seem to align with XML parsing.

300. sorting-untyped-data: Should sorting of untyped data be prohibited?

Locus: xquery Cluster: sort Priority: 1 Status: active
Originator: XPath TF
Should sorting of untyped data be prohibited?

Description

Should sorting of untyped data be prohibited? This would catch some user errors.

306. PSVI-Data-Model-mapping-normative: PSVI to Data Model mapping part of normative text?

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: active
Originator: Don Chamberlin
PSVI to Data Model mapping part of normative text?

Description

Should the mapping from PSVI to Query Data Model be part of the normative language specification? (The mapping is affected by the presence or absence of the Schema Import Feature).

307. schema-types-from-input-documents: Schema Types from input documents?

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: active
Originator: Don Chamberlin
Schema Types from input documents?

Description

During the analysis phase, in-scope schema definitions are derived from schemas named in Schema Import clauses.

Should there be additional in-scope schema definitions that are part of the static context? Should there be another set of in-scope schema definitions that are part of the dynamic context? What would that do to static typing? Would this interfere with interoperability?

In particular:

1. Should an environment be allowed to statically predefine schema definitions for a query? This would allow queries on fixed collections or known message types to provide strong type information without forcing users to explicitly import the corresponding schemas.

2. How does type information found dynamically in queried documents affect the query environment?

Does data() dynamically use the type information found in the instances that are queried, even when the types have not been declared in imported schemas? Note that Basic XQuery does not work properly if this is not true, since it must be able to discover the types of elements without importing their definition.

May an instance contain types that have not been imported into the static environment? If we say it may not, then schema imports are needed to query any document that contains types that are not predefined in XQuery.

May documents that are queried have different definitions for the same names? Note that solutions that dynamically load type information from a document into the in-scope schema definitions may try to introduce all such definitions into the static environment, which should cause an error according to our current rules.

Proposed Resolution

If we want Basic XQuery to be able to query documents that have types that are not predefined, then data() must be able to use type information from instances. But if we want to be able to query validated documents that have different schemas this information must not be added to the static environment (or else we must find a way to add more than one schema definition for a given name to the static environment, or say that the static environment is dynamic, or....).

My tentative conclusions:

1. The in-scope schema definitions should be determined statically.

2. data() and many operators must be able to utilize the type information found in a document.

3. As a matter of convenience, it should be possible to import the schemas associated with a single document or with all documents in a collection. For instance, a syntax like the following may be useful:

import schema from collection
"jdbc:datadirect:sqlserver://localhost:1433;database='airports'"

or

import schema from document
"file:///C:/projects/query/requirements/xml-spec.xsd"

4. Implementations should be allowed to implicitly import schemas into the environment before executing a query, using any of the approved ways above.

308. type-soundness: Type Soundness

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: active
Originator: Don Chamberlin
Type Soundness

Description

The Static Typing Feature is claimed to have a property called "type soundness." However, Dana says she has counterexamples to the claim of type soundness as described in this section (Section 2.4.2.3). (At least sequence type matching breaks TYPE SOUNDNESS so what else breaks it?) We need to examine the claim and make sure it is stated correctly.

310. type-annotations-child-of-element: Are the children of a newly constructed element typed?

Issue Class: T Locus: xquery Cluster: types Priority: 1 Status: active
Originator: Dana F
Are the children of a newly constructed element typed?

Description

What happens with the type annotation of the children of a newly constructed element? Type annotation kept or given xs:anyType.

311. whitespace-attribute-constructors: Whitespace and Attribute Constructors

Locus: xquery Cluster: whitespace Priority: 1 Status: active
Originator:
Whitespace and Attribute Constructors

Description

Whitespace in an XSLT attribute value template is significant insofar as it survives the XML rules for normalization of attributes. This means that CRLF combinations and tabs are normalized to x20 spaces, unless they are written as XML character references. I think it's an open question whether XQuery wants to emulate the XML attribute normalization rules.

In XSLT,

<foo bar="
   {'x'}
"/>

will produce the result <foo bar=" x "/>

while <foo bar=" "/> produces an element containing an attribute whose value is a single CR character.

If XQuery wants to reproduce this behavior exactly, then it's going to have to reproduce the XML treatment of whitespace as well as the XSLT treatment.

But whether it does so or not, I think Mary is right that

<foo bar=" {'x'} "/>

should produce lt;foo bar=" x "/> and not <foo bar="x"/>. There is a difference between element and attribute constructors: attributes have quotes around them, and this sets a different expectation.

312. list-types: What to do about list types?

Issue Class: T Locus: xquery Cluster: types Priority: 1 Status: active
Originator: XQuery WG
What to do about list types?

Description

Merged section on errors and conformance: What to do about list types?

313. union-types: What to do about union types?

Issue Class: T Locus: xquery Cluster: types Priority: 1 Status: active
Originator: XQuery WG
What to do about union types?

Description

Merged section on errors and conformance: What to do about union types?

314. schema-import-basic-xquery: Partial support for SCHEMA IMPORT in Basic XQuery?

Issue Class: T Locus: xquery Cluster: types Priority: 1 Status: active
Originator: XQuery WG
Partial support for SCHEMA IMPORT in Basic XQuery?

Description

Merged section on errors and conformance: Partial support for SCHEMA IMPORT in Basic XQuery?

316. cardinality-typed-comparison: Is AnySimpleType = AnySimpleType*?

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: active
Originator: Michael Rys
Is AnySimpleType = AnySimpleType*?

Description

Given the following function:

define function foo(xs:anySimpleType $x) returns xs:anySimpleType {$x}

and the untyped data

<a a="1"/><a a="2"/><a a="3"/>

should the following be a (static or dyamic) type error or should it work?

foo(/a/@a)

If it should work, what should the following query return?

count(data(<e>1 2</e>))
count(data(<a b="1 2"/>/@b))

Should it be 1 or 2?

Proposed Resolution

anySimpleType is the base type of all the *primitive* XML Schema datatypes.

List and union types are *generated* (my word, Schema uses the word *derived*) from primitive types and thus, not included in anySimpleType. See the extract from the XML Schema datatypes spec below.

"[Definition:] There exists a conceptual datatype, whose name is anySimpleType, that is the simple version of the ur-type definition from [XML Schema Part 1: Structures]. anySimpleType can be considered as the *base type* of all *primitive* types. The *value space* of anySimpleType can be considered to be the *union* of the *value space*s of all *primitive* datatypes."

Thus, the function call above should result in a (static or dynamic, depending on typing conformance) type error.

The count expressions would always return 1.

317. extension-mechanism: XQuery Extension Mechanisms

Locus: xquery Cluster: extensions Priority: 1 Status: active
Originator: Andrew Eisenberg
XQuery Extension Mechanisms

Description

Issue: XQuery has not determined what extension mechanisms might be supported. XQuery may support the following:

  • implementation-defined extensions to the XQuery grammar
  • an XQuery-flagger that identifies extensions to XQuery 1.0
  • implementation-defined extensions to the functions that are available to
  • an XQuery author. The author would be required to explicitly declare the
  • namespaces of any extension functions that are used

Interactions and Input

318. sort-in-FLWR: Add 'order by' clause to FLWR?

Locus: xquery Cluster: sort Priority: 1 Status: decided
Originator: Jonathan Robie
Add 'order by' clause to FLWR?

Description

Four issues were raised in a proposal to restructure sorting in XQuery [1]:

1. Should we add an 'order by' clause to FLWR?

The following syntax has been proposed:

FLWRExpr ::= (ForClause |  LetClause)+ SortClause? WhereClause?
"return"  Expr
OrderClause ::=  "order by" stable? SortSpecList
SortSpecList ::= Expr SortModifier ("," SortSpecList)?
SortModifier ::= ("ascending" |  "descending")? ("empty" "greatest"
|  "empty" "least")?

The OrderClause sorts the tuple stream based on the conditions specified in the SortSpecList.

In the status quo, 'sortby' is a standalone postfix expression. FLWR is used to iterate, and 'sortby' is used to sort. This causes certain difficulties, because iteration and sorting are not distinct, unrelated operations - in general, the order in which the output sequence is ordered determines the best order to choose when iterating over the input.

When sorting data created with element constructors, it can sometimes be quite tricky to determine the original source of data in a constructed element. The more complex the expressions that construct the element, the more tricky this becomes. It is also tricky to iterate in an order determined by data that is not returned in a generated sequence.

If we add this clause, should a FLWOR expression that contains an OrderClause but no ForClause result in a semantic error, since there is no tuple stream to sort?

2. If we add an 'order by' clause, should we keep the sortby() expression, or remove it from our language?

Keeping it is convenient for some expressions. Removing it leaves us with a simpler language, and does not require us to explain to our users why we have two ways of doing the same thing.

3. How should we formalize 'order by' - or should we formalize it in Version 1.0?

The most straightforward way to formalize 'order by' is to use tuples, which do not exist in our Data Model, and these would cause significant change to our Formal Semantics. However, the semantics of 'order by' are straightforward.

Our options seem to be:

3.a. Ensure that we know how it would be formalized using tuples, but postpone including this in the Formal Semantics until after Version 1.

3.b. Refuse to add the feature unless it can be formalized with our current Data Model.

3.c. Restrict the feature to functionality easily formalized with our current Data Model.

I believe there was significant enthusiasm for 3.a. in today's telcon.

4. Is the 'order by' clause part of the XPath spec, or is it only in XQuery?

Jonathan

[1] http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Jul/0177.html

Interactions and Input

Actual Resolution

Decision by: xpath-tf on 2002-10-16 ([link to member only information] )

'order by' has been added.

319. namespace-definitions-and-validate: Namespace definitions and in-scope namespaces

Locus: xquery Cluster: namespaces Priority: 1 Status: active
Originator: XPath TF
Namespace definitions and in-scope namespaces

Description

Addition of namespaces in the query prolog to the in-scope namespaces; how is this information carried through to provide input to validation?

Additional aspecs are:

(a) the whole question of how the namesapce context is affected by namespace declarations in element constructors

(b) the general notion (in XQuery, specifically), that the static context can vary for different parts of a query

(c) what information gets through to act as input to validation

320. types-conformancelevels-same-results: Should different conformance levels give the same result for the same query and data?

Issue Class: T Locus: xquery Cluster: types Priority: 1 Status: active
Originator: Anders Berglund
Should different conformance levels give the same result for the same query and data?

Description

Are different conformance levels going to give the same results? Is it possible to get different results for the same query? The principle should be that you either get the same result or a failure. Currently this isn't the case.

Interactions and Input

[link to member only information] Anders Berglund:

[link to member only information] Kristoffer Rose:

321. validate-lax-strict: Is validate strict or lax?

Locus: xquery Cluster: validate Priority: 1 Status: active
Originator: XSL/XQuery joint
Is validate strict or lax?

Description

Does "validate" do strict or lax validation?

322. validate-lax-strict-override: "validate" strict/lax override?

Locus: xquery Cluster: validate Priority: 1 Status: active
Originator: XSL/XQuery joint
"validate" strict/lax override?

Description

Should the user should be able to override which type (strict/lax) of validation "validate" does?

323. unordered-in-xpath: Should "unordered" be included in XPath?

Locus: xpath Cluster: Priority: 1 Status: active
Originator: XSL/XQuery joint
Should "unordered" be included in XPath?

Description

Should "unordered" keyword be included in XPath? It does cause problems with the grammar (keyword issue).

324. variables-external: How can variables be bound external to XQuery itself?

Locus: xquery Cluster: variables Priority: 1 Status: active
Originator: XSL/XQuery joint
How can variables be bound external to XQuery itself?

Description

How can variables be bound external to XQuery itself (e.g. like parameters to the query)?

325. element-def-not-in-in-scope: Refering to element that is not in the in-scope schema def.

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: active
Originator: XQuery
Refering to element that is not in the in-scope schema def.

Description

In recent discussions on the type system and when reviewing the documents I noticed that many people interpret

element foo

differently than the spec indicates it needs to be interpreted. This seems to indicate that we have a problem.

The semantics that people expect seems to be:

element foo is the same as element foo of type xs:anyType and matches all elements with the given name (regardless where or whether the element was declared in the schema).

attribute foo is the same as attribute foo of type xs:anySimpleType and matches all attributes with the given name regardless where or whether it was declared in the schema).

However our spec [1] says:

Another form of ElemOrAttrType is simply a QName, which is interpreted as the required name of the element or attribute. The QName must be an element or attribute name that is found in the in-scope schema definitions. The match is successful only if the given element or attribute has the required name and also conforms to the schema definition for the required name. This can be verified in either of the following ways:

If the schema definition for the required name has a named type, the given element or attribute must have a type annotation that is the same as that named type or is known (in the in-scope schema definitions) to be derived from that named type. For example, suppose that a schema declares the element named location to have the type State. Then the SequenceType element location will match a given element only if its name is location and its type annotation is State or some named type that is derived from State.

If the schema definition for the required name has an anonymous (unnamed) type definition, the actual content of the given element or attribute must structurally comply with this type definition. For example, suppose that a schema declares the element named shippingAddress to have an anonymous complex type consisting of a street element followed by a city element. Then the SequenceType element shippingAddress will match a given element only if its name is shippingAddress and its content is a street element followed by a city element.

The constraint that an element must have a required name is considered to be satisfied if the element has been validated and found to be a member of a substitution group whose head element has the required name. Substitution groups are described in [XML Schema].

which seems to indicate that this is not the case.

I would like to open an issue on this. I think even if people do not want to use schema types, they may still want to restrict the argument type of a function to an element with a given name.

In addition, many people are surprised to see the SchemaContext in the SequenceType production for other usages than for validate in ...

While there is a use case, I wonder whether this needs to be a required feature for XQuery V1 given the leap in complexity. Maybe it would be useful to solve the above problem by saying that you have to use

element foo in /

to force the name to be in the in-scope schema definition? This would mean that / becomes allowed in the SchemaGlobalContext production.

326. require-type-definition: Semantics of element foo of type T

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: active
Originator: XQuery
Semantics of element foo of type T

Description

When using the form 'element foo of type T', should 'foo' be a globally declared element in the in-scope schema or not? Should there be constraints on which type T is allowed? The language document assumes foo is globally declared and T is a restriction of the type of foo. The formal semantics does not make that assumption.

327. functions-parameter-evaluation: Evaluate unused function parameters?

Locus: xpath Cluster: functions Priority: 1 Status: active
Originator: XSL/XQuery joint
Evaluate unused function parameters?

Description

Is an implementation obligated to evaluate all its parameters (and raise any errors doing so) even when they're not needed in the function body?

Actual Resolution

Decision by: xpath-tf on 2002-10-29 ([link to member only information] )as part of Agendum 1.

There is no need to evaluate "non needed" expressions.

Decision by: xquery on 2002-10-30 ([link to member only information] )accepting text for next publication, but keep issue active.

Decision by: xsl on 2002-10-31 ([link to member only information] )accepting text for next publication, but keep issue active.

328. cdata-section: What does CDATA section constructor construct?

Locus: xquery Cluster: cdata section Priority: 1 Status: active
Originator: Michael Kay
What does CDATA section constructor construct?

Description

Section 3.7.5 describes CDATA section constructor, but these cannot be represented in the data model.

329. duplicate-attribute-constructors: Duplicate attribute constructors

Locus: xquery Cluster: constructors Priority: 1 Status: active
Originator: Michael Kay
Duplicate attribute constructors

Description

If there are multiple constructors for the same attribute on an element; which one is taken or is it an error?

330. some-filter-on-type: Should "some" do type filtering?

Issue Class: T Locus: xquery Cluster: types Priority: 1 Status: active
Originator: Michael Kay
Should "some" do type filtering?

Description

Currently "some" doesn't do any filtering, which seems unnatural. We could change the some behaviour to actually do the type filtering.

It is easy to imagine that "some hatsize $h in $seq satisfies $h=3" ignores items in $seq that are not hatsizes. Currently, of course, it causes an error if the sequence might contains things other than hatsizes.

331. static-dynamic-dispatch: Static vs. dynamic dispatch for arithmetics

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: active
Originator: Dana Florescu
Static vs. dynamic dispatch for arithmetics

Description

The current XPath/XQuery specification, as well as the Formal semantics document, mandate that the specific arithmetic operation to be executed depends on the runtime type of the arguments. For example, the addition of two variables $x and $y will be executed as an integer addition if the dynamic types of the two values are both subtypes of integer, and does not depend on the static type of the variables $x and $y (which may be decimal).

Implementing this semantics requires a runtime dispatch plus an runtime interaction with the type system for subtype testing. This can be very costly. Moreover, this semantics can prohibit other useful compile time optimizations like index utilization.

We may allow implementations to use either a static or dynamic dispatch for arithmetic operations in order to improve performance.

332. schema-import-static-typing-interoperable-results: Schema Import, Static Typing: what is interoperable?

Locus: xpath Cluster: types Priority: 1 Status: active
Originator: XPath TF
Schema Import, Static Typing: what is interoperable?

Description

What interoperability is expected for queries that are executed with and without Schema Import? Does the current text reflect the desired goals?

What interoperability is expected for queries that are executed with and without Static Typing? Does the current text reflect the desired goals?

Interactions and Input

[link to member only information] Phil Wadler:

333. optional-features-vs-conformance-levels: Optional Features vs. Conformance Levels

Locus: xpath Cluster: conformance Priority: 1 Status: active
Originator: XPath TF
Optional Features vs. Conformance Levels

Description

Should "Schema Import" and "Static Typing" be independent, optional features or should there be a layer of conformance levels? For XQuery the latter might be "Basic XQuery", "Basic XQuery" + "Schema Import", and "Basic XQuery" + "Schema Import" + "Static Typing".

Interactions and Input

334. xquery-failed-validation: How are documents for which validation has failed processed?

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: active
Originator: Jonathan Robie
How are documents for which validation has failed processed?

Description

What is the result of a failed validation? Can you inspect the result to detect this? Do you just get anySimpleType and anyType?

Interactions and Input

335. semantics-interfering-with-optimization: XPath/XQuery's current semantics greatly interferes with optimization

Locus: xpath Cluster: formal-semantics Priority: 1 Status: active
Originator: Michael Rys
XPath/XQuery's current semantics greatly interferes with optimization

Description

Current semantics basically defines the semantics by mapping FLWRs and path expression to go top-down. Errors are normative. Problem is that we can not apply many optimizations. Simple query rewrites such as pushing or pulling filters, etc. Like to be able to push predicates down and evaluate them. Potentially the predicate might raise an error you would not have gotten if you processed top down. Want to allow implementations to do bottom up evaluations.

Suggested resolution:

The formal semantics defines dynamic evaluation in terms of a naive, top-down reduction of a core expression to a data-model value. Implementations may choose alternative evaluation strategies, which, for example, may reduce a core expression bottom-up. If an evaluation of a core expression yields a value (i.e., it does not raise an error), the value must be the same value as would be produced by the dynamic semantics defined in this document. The evaluation of a core expression may raise an error that may not be raised by the dynamic semantics as defined in this document.

Actual Resolution

Decision by: xpath-tf on 2002-10-29 ([link to member only information] )as part of Agendum 1.

Expressions, with the exception of "if", may be reordered and thus some errors may be raised that using another evaluation strategy may not have occurred.

Decision by: xquery on 2002-10-30 ([link to member only information] )accepting text for next publication, but keep issue active.

Decision by: xsl on 2002-10-31 ([link to member only information] )accepting text for next publication, but keep issue active.

336. error-decide-on-markup: Markup in documents for errors

Locus: all Cluster: editorial Priority: 1 Status: active
Originator: XPath TF
Markup in documents for errors

Description

The editors need to agree on the markup to be used for errors in the documents. Some markup is currently used in the XSLT spec.

337. error-add-markup: Add markup in documents for errors

Locus: all Cluster: editorial Priority: 1 Status: active
Originator: XPath TF
Add markup in documents for errors

Description

The markup for errors to be added to the documents.

338. whitespace-character-reference: Handling of whitespace and character references

Locus: xquery Cluster: whitespace Priority: 1 Status: active
Originator: Michael Kay
Handling of whitespace and character references

Description

The effect of CharRef in Element or Attribute content is underspecified. For example, if the value of the CharRef is whitespace, does it behave like whitespace in Element or Attribute content, or does it behave like ordinary characters? Either way, it is hard to make it behave exactly like the XML construct that it mimics: in XML, a character reference such as suppresses certain effects such as whitespace normalization. It is not clear whether such normalization happens in XQuery.

Interactions and Input

339. element-attribute-construction-order: Error type for attributes constructed too late

Locus: xquery Cluster: errors Priority: 2 Status: active
Originator: Don Chamberlin
Error type for attributes constructed too late

Description

What kind of error should be raised by an element constructor in which an attribute is encountered after other element content?

340. errors-unique-identification: How to identify errors?

Locus: xpath Cluster: errors Priority: 1 Status: active
Originator: XPath TF
How to identify errors?

Description

How should we allocate codes or identifiers to errors defined in the spec? We shoud not use "explanatory sentences" as these are not appropriate for I18N reasons.

341. SequenceType-problems: Problems with SequenceType

Locus: xpath Cluster: syntax Priority: 1 Status: active
Originator: Michael Kay
Problems with SequenceType

Description

Using the "instance of SequenceType" construct within a predicate of a path expression, or in an XSLT match pattern, is very unwieldy: the verbose English-like syntax of a SequenceType does not go well with the terse syntax of path expressions, leading to inelegant constructs like

select="//*[.instance of element of type address]"

Interactions and Input

[link to member only information] Michael Kay:

342. grammar-prolog-problems: Prolog syntax

Locus: xquery Cluster: grammar Priority: o-1 Status: active
Originator: Scott Boag
Prolog syntax

Description

The prolog productions require special handling, but there is no special prolog state. Right now prolog productions must be distinguished by compound keywords such as &lt;"declare" "namespace">. We either need to make sure we're happy with this, or make some sort of prolog container.

343. namespaces-functions: Do functions in the null namespace clash with functions in the default namespace?

Locus: xpath Cluster: namespaces Priority: 1 Status: active
Originator: XPath TF
Do functions in the null namespace clash with functions in the default namespace?

Description

If you define the DFN (default function namespace) to be the null namespace, which you must do if you are going to call functions in this namespace, can you still use unprefixed names to refer to functions in the built-in namespace?

H Revision Log (Non-Normative)

H.1 15 Nov 2002

  • Backward compatibility with XPath Version 1.0 is now handled in a different way; fallback conversions have been eliminated, and an "XPath Version 1 Compatibility Mode" has been introduced that affects the semantics of certain functions and operators.

  • New and more liberal rules have been adopted for casting, allowing (for example) a value of a derived atomic type to be cast into another derived atomic type as long as the two types have a common supertype.

  • Every atomic type, including user-defined atomic types, now has a constructor function with the same name as the type and with semantics equivalent to a cast expression with the atomic type as the target type.

  • A new form of predicate called castable can now be used to determine if a given value can be cast into a given target type without raising an error.

  • Certain grammar changes have been made in order to eliminate the need for reserved keywords. For example, the keyword as is now used in function signatures, and the keyword context is used in validate expressions. For the same reason, the unordered keyword has been replaced by a function named fn:unordered.

  • Rules for SequenceType Matching are now based purely on names of types and elements rather than on structural subsumption.

  • Variables may now be added to the static and dynamic context by the environment external to the query or transformation.

  • New material has been added describing how errors are handled and how optimizers are allowed certain flexibility in evaluating an expression.

  • The process of numeric promotion is clearly distinguished from the process of subtype substitution. It is also clarified that, when a function is invoked with an argument that is a subtype of the expected type, that argument retains its most specific type in the body of the function.

  • The predefined namespace prefix xsd: is deleted, and the predefined namespace prefix fn: is added. The prefix fn: is used to refer to the namespace of the built-in function library.