XML Path Language (XPath) 3.1: 日本語訳

Jump to Table of Contents Pop Out Sidebar

W3C

XML Path Language (XPath) 3.1

W3C Recommendation 21 March 2017

This version:
https://www.w3.org/TR/2017/REC-xpath-31-20170321/
Latest version of XPath 3.1:
https://www.w3.org/TR/xpath-31/
Previous versions of XPath 3.1:
https://www.w3.org/TR/2017/PR-xpath-31-20170117/
https://www.w3.org/TR/2016/CR-xpath-31-20161213/
https://www.w3.org/TR/2015/CR-xpath-31-20151217/
https://www.w3.org/TR/2014/CR-xpath-31-20141218/
https://www.w3.org/TR/2014/WD-xpath-31-20141007/
https://www.w3.org/TR/2014/WD-xpath-31-20140424/
Most recent version of XPath 3:
https://www.w3.org/TR/xpath-3/
Most recent version of XPath:
https://www.w3.org/TR/xpath/
Most recent Recommendation of XPath:
https://www.w3.org/TR/2014/REC-xpath-30-20140408/
Editors:
Jonathan Robie, biblicalhumanities.org <jonathan.robie@biblicalhumanities.org>
Michael Dyck, Invited Expert <jmdyck@ibiblio.org>
Josh Spiegel, Oracle Corporation <josh.spiegel@oracle.com>

Please check the errata for any errors or issues reported since publication.

See also translations.

This document is also available in these non-normative formats: XML and Change markings relative to previous edition.


概要

XPath 3.1は式言語であって、[XQuery and XPath Data Model (XDM) 3.1] に定義されたデータ・モデルに適合する値を処理できる。言語の名前「XPath」は、他と比べて最も際立った特徴である、「パス式」に由来する。すなわち、XML木のノードを、階層的に指し示す手段となる式である。データ・モデルには、XMLの木構造をモデル化する手段だけでなく、原子値、函数アイテム、シーケンスも含まれる。XPathのこの版では、XMLだけでなくJSONの処理能力も備えるべく、マップおよび配列をデータ・モデルに組み込んだ。これに伴って、新しい式を言語構文に組み込むとともに、いくつか函数を追加した ([XQuery and XPath Functions and Operators 3.1])。XPath 3.1で新たに加わった、最も重要な機能を示す:

  1. 3.11.1 マップ

  2. 3.11.2 配列

XPath 3.1は [XML Path Language (XPath) Version 3.0] の上位集合である。XPath 3.0以降の変更内容の一覧を「I 改訂履歴」に示す。

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document is governed by the 1 March 2017 W3C Process Document.

This is a Recommendation of the W3C.

This document was published by the W3C XML Query Working Group and the W3C XSLT Working Group, each of which is part of the XML Activity.

This Recommendation specifies XPath version 3.1, a fully compatible extension of XPath version 3.0.

This specification is designed to be referenced normatively from other specifications defining a host language for it; it is not intended to be implemented outside a host language. The implementability of this specification has been tested in the context of its normative inclusion in host languages defined by the XQuery 3.1 and XSLT 3.0 (expected in 2017) specifications; see the XQuery 3.1 implementation report (and, in the future, the WGs expect that there will also be an XSLT 3.0 implementation report) for details.

No substantive changes have been made to this specification since its publication as a Proposed Recommendation.

Please report errors in this document using W3C's public Bugzilla system (instructions can be found at https://www.w3.org/XML/2005/04/qt-bugzilla). If access to that system is not feasible, you may send your comments to the W3C XSLT/XPath/XQuery public comments mailing list, public-qt-comments@w3.org. It will be very helpful if you include the string “[XPath31]” in the subject line of your report, whether made in Bugzilla or in email. Please use multiple Bugzilla entries (or, if necessary, multiple email messages) if you have more than one comment to make. Archives of the comments and responses are available at https://lists.w3.org/Archives/Public/public-qt-comments/.

This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

This document was produced by groups operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures (W3C XML Query Working Group) and a public list of any patent disclosures (W3C XSLT Working Group) made in connection with the deliverables of each group; these pages also include instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.


1 緒言

XPathの主目的は、XML木およびJSON木のノードを指し示すことである。XPathという名前は、XML文書の階層構造を渡り歩くために、パスの記法を使うことに由来する。XMLとは異なる簡潔な構文を採用しているので、URIや、XMLの属性値としても記述しやすい。XPath 3.1ではさらに、JSON木を渡り歩くための、よく似た構文を組み込んだ。

定義: XPath 3.1が処理を施す対象は、XML文書またはJSONオブジェクトの、抽象的な論理構造である。表面的な構文ではない。この論理構造をデータ・モデル (data model) といい、[XQuery and XPath Data Model (XDM) 3.1] で定義している。】

XPathは、【XSL Transformations (XSLT) Version 3.0][XQuery 3.1: An XML Query Language] などといった、ホスト言語に埋め込んで使うものと想定して設計した。[定義: XPathのホスト言語 (host language) とは、XPathを副言語として取り込んだ言語あるいは仕様であって、この言語が、XPathの式を評価する静的文脈や動的文脈の決め方を定義する。】

XPath 3.1はXQuery 3.1の部分集合である。一般に、XPath 3.1とXQuery 3.1のどちらでも構文的に正しく、正常に実行できる式は、どちらの言語でも同じ結果を返す。ただし、この規則には若干の例外がある:

この2つの言語は密接に関連しているので、文法や言語の記述は共通の文書から生成することにして、一貫性を保っている。また、それぞれの仕様の編集者も、密に連携して作業している。

XPath 3.1は次の仕様にも依存し、密接に関連している:

この文書では、XPath 3.1の文法を記述するために、[XML 1.0] と同じ、基本的なEBNF記法を使っている。特に註記する場合を除き (「A.2 字句構造」を参照)、において空白は意味を持たない。構文規則を示す際には、その構文によって記述する機能も説明する。さらに、完全な文法を付録 [A XPath 3.1の文法] に示す。この付録は、規準を定める記述の一部である。

この文書の構文規則では、名前つき記号に下線をつけ、リテラル・テキストは二重引用符で囲んで表す。例として、静的函数呼び出しの構文規則を示す。

[63]    FunctionCall    ::=    EQName ArgumentList /* xgc: reserved-function-names */
/* gn: parens */
[50]    ArgumentList    ::=    "(" (Argument ("," Argument)*)? ")"

この構文規則は次のように読む: 函数呼び出しは、EQNameとそれに続くArgumentListから成る。引数リストは、開き括弧、1つ以上の引数の (カンマ区切り) リストまたは空、閉じ括弧から成る。

この文書では、XPath 3.1の静的意味、動的意味を規準として定義する。この文書で、「註記」と示した例やデータは、説明のために提供するものであって、規準を定めるものではない。

この仕様で示した言語の処理方法に関して、実装定義または実装依存の事項がある。

この仕様で実装定義または実装依存とした事項は、XPathを埋め込むホスト言語の仕様によっても制約されることがありうる。

2 基本事項

XPath 3.1の基本的な構成要素はである。[Unicode] 文字の並びとして記述するが、実際に用いるUnicodeの版は実装定義である。XPath 3.1では各種の式が使え、いずれも、キーワード、記号、オペランドから構築する。式のオペランドは通常、それ自体が別の式でもある。XPath 3.1では一般に、式をいくらでも入れ子にすることができる。

註記:

この仕様では、[Unicode] 文字列の文字集合エンコーディングに関して、何の想定もしない。

XPath 3.1はXMLと同様に、大文字と小文字を区別する。XPath 3.1のキーワードは小文字から成り、予約語ではない。言い替えると、式の中にキーワードと同じ綴りの名前があってもよい。ただし、接頭辞なしの函数名であって、「A.3 函数名として使えない名前」に示すものを除く。

定義: データ・モデルにおいて、 (value) は常にシーケンスである。】 【定義: シーケンス (sequence) は、0個以上のアイテムから成る、順序つきコレクションである。】 【定義: アイテム (item) は、原子値ノード函数DM31のいずれかである。】 【定義: 原子値 (atomic value) は、[XML Schema 1.0] または [XML Schema 1.1] で定義する、原子型 (atomic type) の値空間に属する値である。】 【定義: ノード (node) は、「第6節 ノードDM31」で定義する、いずれかのノードの種類 (node kinds) のインスタンスである。】 各ノードには、一意的なノードID型づけされた値文字列値がある。さらに、一部のノードには名前がある。ノードの型づけされた値は、0個以上の原子値のシーケンスである。ノードの文字列値は、xs:string型の値である。ノードの名前は、xs:QName型の値である。

定義: ちょうど1個のアイテムから成るシーケンスをシングルトン (singleton) と呼ぶ。】 アイテムは、当該アイテムを含むシングルトン・シーケンスと同一と看做す。シーケンスを入れ子にすることはできない。たとえば、1、(2, 3)、( ) という3つの値をまとめてひとつのシーケンスにすると、(1, 2, 3) というシーケンスになる。【定義: アイテムをひとつも含まないシーケンスを空シーケンス (empty sequence) と呼ぶ。】

定義: XDMインスタンス (XDM instance) という語をの同義語として用い、制約のない、アイテムシーケンスを表す。】

要素ノードにはスコープ内名前空間というプロパティーがある。【定義: 要素ノードのスコープ内名前空間 (in-scope namespaces) プロパティーは、名前空間接頭辞をURIに関連づける、名前空間束縛の集合である。】 ある要素について、その名前空間束縛のひとつは、接頭辞が空であっても構わない。この名前空間束縛のURIは、当該要素のスコープ内における既定の名前空間である。

[XML Path Language (XPath) Version 1.0] では、要素ノードのスコープ内名前空間を、名前空間軸に沿って並べた、名前空間ノードのコレクションとして表していた。XPath 2.0以降、名前空間軸は非推奨になり、ホスト言語がこれに対応する必要はなくなった。名前空間軸に対応していないホスト言語は、名前空間束縛をノードの形で表す必要がない。

定義: 展開済みQName (expanded QName) とは、接頭辞、ローカル名、名前空間URIの3つから成る組である。名前空間に属さない名前の場合、名前空間URIも接頭辞も欠落している。既定の名前空間に属する名前の場合、接頭辞は欠落している。】 2つの展開済みQNameを比較する際、接頭辞は無視する。ローカル名の部分は、Unicodeコードポイント照合順序にもとづき一致していなければならない。名前空間URIの部分は、2つとも欠落しているか、またはUnicodeコードポイント照合順序にもとづき一致していなければならない。

XPathの文法で、要素、属性、函数、変数、型、その他の構造の名前を表すQNameを、構文上は、EQNameのインスタンスとして記述する。

[112]    EQName    ::=    QName | URIQualifiedName
[122]    QName    ::=    [http://www.w3.org/TR/REC-xml-names/#NT-QName]Names /* xgc: xml-version */
[123]    NCName    ::=    [http://www.w3.org/TR/REC-xml-names/#NT-NCName]Names /* xgc: xml-version */
[117]    URIQualifiedName    ::=    BracedURILiteral NCName /* ws: explicit */
[118]    BracedURILiteral    ::=    "Q" "{" [^{}]* "}" /* ws: explicit */

EQNameの構文規則によれば、QNameには次の3とおりの書き方がある:

定義: 字句規則上のQName (lexical QName) とは、QNameの字句規則に従う名前のことである。】

URIQualifiedNameの名前空間URIの値は、xs:anyURI型の規則に従い、空白を正規化する (「3.2.17 anyURIXS1-2または「3.3.17 anyURIXS11-2を参照)。EQNameの名前空間URIがhttp://www.w3.org/2000/xmlns/であれば、静的エラー [err:XQST0070] が発生する。

EQNameの例をいくつか示す:

この仕様では、次の名前空間接頭辞で、それぞれ対応する名前空間URIを表している。しかし、すべての式の静的文脈に、以下の名前空間束縛が揃っていなくても構わない。さらに、別の接頭辞で以下の名前空間を表しても、また、以下の接頭辞を別の名前空間に束縛してもよい。

定義: この仕様においてURIは、[RFC3986] で定義されたUniversal Resource Identifierを表す。これは [RFC3987] で拡張され、IRIという名前になった。】 ここでは「URI」という用語を「IRI」に優先して使うことにする。「Base URI」のような、XMLに関する一連の仕様で定義、参照されている概念を表す、新しい名前を導入せずに済ませるためである。

註記:

URIが [RFC3986] および [RFC3987] に従う字句的に有効なものでなくても、多くの場合、処理系がエラーを報告する必要はない。詳しくは「2.4.5 URIリテラル」を参照。

2.1 式の文脈

定義: ある式が与えられたとき、式の文脈 (expression context) とは、その式の評価結果に影響を与えうる一連の情報のことである。】

この情報は、静的文脈動的文脈の2つに分類できる。

2.1.1 静的文脈

定義: 式の静的文脈 (static context) は、式の評価に先立つ、静的解析の際に参照できる情報である。】 この情報を使って、式に静的エラーがないか判断できる。

静的文脈を構成する要素を以下に挙げる。各要素の既定の初期値は、ホスト言語で指定しなければならない。各要素のスコープについては、「C.1 静的文脈の構成要素」を参照。

  • 定義: XPath 1.0互換モード (XPath 1.0 compatibility mode)。この値がtrueであれば、XPath Version 1.0との後方互換性に関する規則を適用する。適用しない場合はfalseとする。】

  • 定義: 静的に既知の名前空間 (statically known namespaces)。接頭辞から名前空間URIへの対応づけで、ある式の静的な処理の際に既知となっている、すべての名前空間を定義したものをいう。】 URIの値は、xs:anyURI型に関する規則に従い、空白類を正規化したものとする (「3.2.17 anyURIXS1-2」または「3.3.17 anyURIXS11-2」を参照)。なお、スコープ内名前空間は要素ノードの動的なプロパティーであって、式の静的なプロパティーである静的に既知の名前空間とは違うことに註意。

  • 定義: 既定の要素/型名前空間 (default element/type namespace)。名前空間URIであるが、欠落DM31している場合もある。欠落していなければ、要素名または型名が現れるべきところに、接頭辞なしのQNameが現れた場合に使う。】 URIの値は、xs:anyURI型に関する規則に従い、空白類を正規化したものとする (「3.2.17 anyURIXS1-2」または「3.3.17 anyURIXS11-2」を参照)。

  • 定義: 既定の函数名前空間 (default function namespace)。名前空間URIであるが、欠落DM31している場合もある。欠落していなければ、函数名が現れるべきところに、接頭辞なしのQNameが現れた場合に使う。】 URIの値は、xs:anyURI型に関する規則に従い、空白類を正規化したものとする (「3.2.17 anyURIXS1-2」または「3.3.17 anyURIXS11-2」を参照)。

  • 定義: スコープ内スキーマ定義 (in-scope schema definitions)。要素宣言、属性宣言、スキーマ型定義で、式の静的解析に際してスコープ内にあるものの総称。】 次の3つに分かれる。

    • 定義: スコープ内スキーマ型 (in-scope schema types)。それぞれのスキーマ型定義は、展開済みQName (名前つき型の場合)、または実装依存の型識別子 (匿名型の場合) で識別する。「2.5.1 定義済みスキーマ型」に示す定義済みスキーマ型を含む。】

    • 定義: スコープ内要素宣言 (in-scope element declarations)。それぞれの要素宣言は、展開済みQName (最上位の要素宣言の場合)、または実装依存の要素識別子 (ローカル要素宣言の場合) で識別する。】 要素の代替グループ関係に関する情報を含む。

      定義: 代替グループ (substitution groups) は、「2.2.2.2 要素の代替グループXS1-1」および「2.2.2.2 要素の代替グループXS11-1」に定義されている。簡単に言うと、ある要素 (ヘッド要素という) に代替可能な代替グループとは、スキーマ検証の結果に影響を与えることなく、ヘッド要素と差し替えられる要素の集合のことである。】

    • 定義: スコープ内属性宣言 (in-scope attribute declarations)。それぞれの属性宣言は、展開済みQName (最上位の属性宣言の場合)、または実装依存の属性識別子 (ローカル属性宣言の場合) で識別する。】

  • 定義: スコープ内変数 (in-scope variables)。これは展開済みQNameから型への対応づけである。式の中で参照できる変数の集合を定義する。展開済みQNameは変数の名前であり、その型は変数の静的な型と同じである。】

    変数を束縛する式があると、当該変数のスコープ内に、当該変数およびその型のスコープ内変数が増える。インライン函数式の本体内では、スコープ内変数函数パラメーターの名前および型で展開する。

  • 定義: 文脈アイテムの静的な型 (context item static type) は、ある式のスコープ内における、文脈アイテムの静的な型を定義する。】

  • 定義: 静的に既知の函数シグニチャー (statically known function signatures) は、展開済みQNameとアリティーの組から、函数シグニチャーDM31への対応づけである。】 この対応づけのエントリーは、静的函数呼び出しあるいは名前つき函数参照されうる函数の集合を定義する。函数はそれぞれ、展開済みQNameとアリティー (パラメーターの個数) の組で、一意的に特定できる。この要素は、静的に既知の函数の、展開済みQNameおよびアリティーが渡されると、該当する函数のシグニチャーDM31を返すという形で、型をはじめ、函数の静的なプロパティーを指定する。

    静的に既知の函数シグニチャーとして、組み込み函数その他、さまざまな出自の函数のシグニチャーがある。展開済みQNameとアリティーの組がまったく同じ函数は、(シグニチャーが一致するとしても) 生じないように実装しなければならない。

  • 定義: 静的に既知の照合順序 (statically known collations) は、URIから照合順序への、実装定義の対応づけである。式を処理する際に援用できる照合順序の名前を定義する。】 【定義: 照合順序 (collation) とは、文字列やURIを比較し、あるいは順序づけるための仕様である。照合順序のより完全な定義は、「5.3 文字列の比較FO31」を参照。】

  • 定義: 既定の照合順序 (default collation) は、静的に既知の照合順序のうち、xs:string型やxs:anyURI型 (およびその派生型) の変数を比較、順序づけする函数や演算子が、明示的に照合順序が指定されていない場合に適用するものである。】

  • 定義: 静的な基底URI (static base URI) とは、相対URI参照を解決するために使う絶対URIである。】 EFの部分式であれば、Eの静的な基底URIは、Fのそれと同じである。XPathの構造で、静的解析の際、相対URI参照の解決を要するものはない。静的な基底URIは動的評価の際に、fn:static-base-uri函数で取得できる。fn:docなどの函数も、動的評価の際、暗黙のうちに静的な基底URIを使う。相対URI参照を解決する手順については「2.4.6 相対URI参照の解決」を参照。

  • 定義: 静的に既知の文書 (statically known documents) は、文字列から型への対応づけである。文字列は資源の絶対URIを表す。この資源は必要に応じ、fn:doc函数で取得できる。この絶対URIに対応する型は、与えられたURIをリテラル引数として渡して呼び出す場合の、fn:doc函数の静的な型である。】 fn:docに渡した引数の文字列リテラルが静的に既知の文書にない場合、fn:doc函数の静的な型document-node()?になる。

    註記:

    静的に既知の文書の目的は、静的な型の情報を与えることであって、どの文書が取得できるか判断するためではない。あるURIが静的に既知の文書に見つからなくても、fn:docでアクセスすることは可能である。

  • 定義: 静的に既知のコレクション (statically known collections) は、文字列から型への対応づけである。文字列は資源の絶対URIを表す。この資源は必要に応じ、fn:collection函数で取得できる。この絶対URIに対応する型は、与えられたURIを引数として渡して呼び出す場合の、fn:collection函数の型 (アイテムのシーケンス) である。】 fn:collectionに渡した引数の文字列リテラルが静的に既知のコレクションにない場合、fn:collection函数の静的な型item()*になる。

    註記:

    静的に既知のコレクションの目的は、静的な型の情報を与えることであって、どのコレクションが取得できるか判断するためではない。あるURIが静的に既知のコレクションに見つからなくても、fn:collectionでアクセスすることは可能である。

  • 定義: 静的に既知の既定のコレクション型 (statically known default collection type) は、引数なしでfn:collection函数を呼び出したときに得られる、アイテムのシーケンスの型である。】 他の型になるよう初期化している実装を除き、静的に既知の既定のコレクション型item()*である。

  • 定義: 静的に既知の十進書式 (statically known decimal formats) は、QNameから十進書式への対応づけである。そのうちのひとつは既定の書式で、可視の名前がないので「無名の十進書式」という。それぞれの書式は、fn:format-number函数で数値を整形する際に用いる。】

    それぞれの十進書式は、一連のプロパティーの集合である。各プロパティーは、fn:format-number函数に渡すピクチャー文字列に現れる、文字の解釈方法を制御し、あるいは、数値の整形結果の中で用いる文字を指定する。

    以下に示すプロパティーは、ピクチャー文字列と整形結果の、両方で使う文字を指定する。いずれの場合も、値は単一の文字である:

    • 定義: decimal-separatorは、数値の整数部分と小数部分の区切り文字を表す。ピクチャー文字列と整形結果の両方に使う。既定値はピリオド文字 (.) である。】

    • 定義: exponent-separatorは、数値の科学表記において、仮数部と指数部の区切り文字を表す。ピクチャー文字列と整形結果の両方に使う。既定値は文字「e」である。】

    • 定義: grouping-separatorは、典型的には1000ごとの、区切り文字を表す。ピクチャー文字列と整形結果の両方に使う。既定値はカンマ文字 (,) である。】

    • 定義: percentは、数値が百分率である旨を示す文字を表す。ピクチャー文字列と整形結果の両方に使う。既定値はパーセント文字 (%) である。】

    • 定義: per-milleは、数値が千分率である旨を示す文字を表す。ピクチャー文字列と整形結果の両方に使う。既定値はUnicodeのパーミル文字 (#x2030) である。】

    • 定義: zero-digitは、ある桁がゼロである旨を示す文字を表す。既定値は、西欧諸言語における数字ゼロ (#x30) である。この文字は、数字 (Unicodeプロパティー・データベースのカテゴリーNd) であって、数値としての値が0であるものでなければならない。これは暗黙に、0から9の値を表す、10個のUnicode文字を定義することにもなる。Unicodeでは10進文字を、連続したブロックに、数値の順で配置することになっているからである。ピクチャー文字列では、この10個の文字をどれでも、必ず数字を埋めるべき桁を表すために使える。整形結果の文字列では、各桁の値 (0~9) を表すために使う。】

    以下のプロパティーは、fn:format-number函数に渡す、ピクチャー文字列で使う文字を指定する。整形結果には現れない。値は単一の文字である:

    • 定義: digitは、ピクチャー文字列で、その桁が空白であってもよい旨を示す文字である。既定値は番号記号文字 (#) である。】

    • 定義: pattern-separatorは、ピクチャー文字列で、正値を表すピクチャーと負値を表すピクチャーを区切る文字である。既定値はセミコロン文字 (;) である。】

    以下のプロパティーは、整形結果に現れる文字または文字列を指定する。ピクチャー文字列には現れない:

    • 定義: infinity は、double値である無限大 (INF) を表す文字列である。既定値は、文字列「Infinity」である。】

    • 定義: NaN は、double値である非数 NaN (not-a-number) を表す文字列である。既定値は、文字列「NaN」である。】

    • 定義: minus-signは、負の数値を表す文字である。既定値は、ハイフン/マイナス文字 (#x2D) である。】

2.1.2 動的文脈

定義: 式の動的文脈 (dynamic context) とは、式の動的評価に必要な情報のことである。】 式の評価が動的文脈欠落DM31部分に依存している場合、動的エラー [err:XPDY0002] が発生する。

動的文脈を構成する要素を以下に挙げる。各要素の意味に関するさらに詳しい規則を、「C.2 動的文脈の構成要素」に示す。

動的文脈は、静的文脈の構成要素すべてと、以下に示す要素とから成る。

定義: 動的文脈の構成要素のうち、最初に示す3つ (文脈アイテム、文脈位置、文脈の大きさ) を、式のフォーカス (focus) という。】 処理系はフォーカスを使って、式がどのアイテムを処理しているかを追跡する。文脈アイテムと文脈位置は、一方が決まればもう一方も分かる。

註記:

フォーカスのいずれかの構成要素が決まれば、通常は文脈の大きさも決まる。しかしストリーム処理 (訳註: 文書を読み込みながら並行して処理すること) の場合、先読みしなければ文脈の大きさは決まらず、したがって未定義となるかも知れない。このような場合、last() のような式からは動的エラーが発生する。

定義: シングルトン・フォーカス (singleton focus) とは、フォーカスのうち、単一のアイテムを参照するものである。シングルトン・アイテムでは、文脈アイテムはその参照されるアイテムであり、文脈位置は1、文脈の大きさも1である。】

いくつかの言語構造、特にパス演算子 E1/E2単純マップ演算子 E1!E2述語 E1[E2] は、部分式を評価するために新たなフォーカスを生成する。このような言語構造では、E1の評価結果であるシーケンスの各アイテムに対して、E2を1回ずつ評価する。このときE2は、それぞれ異なるフォーカスで評価することになる。E2を評価するフォーカスを内部フォーカス (inner focus) と呼ぶ。一方、E1を評価するフォーカスは外部フォーカス (outer focus) と呼ぶ。内部フォーカスはE2の評価にのみ用いる。E1の評価には、元のフォーカスを変更せずに使う。

  • 定義: 文脈アイテム (context item) とは、その時点で処理の対象としているアイテムである。】 【定義: 文脈アイテムがノードである場合、これを文脈ノード (context node) とも呼ぶ。】 単一のドット (.) から成る式は、文脈アイテムを返す。式E1/E2E1[E2]を評価する場合、E1を評価して得られるシーケンス中の各アイテムが、E2を評価する際、内部フォーカスの文脈アイテムになる。

  • 定義: 文脈位置 (context position) は、その時点で処理の対象としているシーケンスにおける、文脈アイテムの位置である。】 文脈アイテムが変われば文脈位置も変わる。フォーカスを定義する際、文脈位置の値は正整数である。式fn:position()は文脈位置を返す。式E1/E2E1[E2]を評価する場合、E2の評価に用いる内部フォーカスにおける文脈位置は、E1を評価して得られたシーケンス中の、文脈アイテムの位置になる。シーケンスの先頭アイテムの位置は常に1である。文脈位置は常に、文脈の大きさ以下の値になる。

  • 定義: 文脈の大きさ (context size) は、その時点で処理の対象としているシーケンス中の、アイテムの個数である。】 値は常に正整数である。式fn:last()は文脈の大きさを返す。式E1/E2E1[E2]を評価する場合、E2の評価に用いる内部フォーカスにおける文脈の大きさは、E1を評価して得られたシーケンス中の、アイテムの個数になる。

  • 定義: 変数値 (variable values) は、展開済みQNameから値への対応づけである。ここには、式の静的文脈スコープ内変数と、同じ展開済みQNamesも含まれる。展開済みQNameは変数の名前であり、その値は変数の動的な値であって、その動的型に関する情報も保持している。】

  • 定義: 名前つき函数 (named functions) は、展開済みQNameとアリティーの組から函数DM31への対応づけである。】 静的に既知の函数シグニチャーの各シグニチャーに対応する函数だけとは限らない (「2.2.4 整合性制約」を参照)。名前つき函数には外部函数もありうる。【定義: 外部函数 (external functions) とは、クエリー環境外に実装した函数である。】 たとえば、実装定義の外部函数を、コア函数ライブラリー (【XQuery and XPath Functions and Operators 3.1] を参照) とは別に提供する実装も考えられる。[定義: 実装定義の函数 (implementation-defined function) とは、実装定義外部函数である。】 【定義: ホスト言語の函数 (host language function) とは、ホスト言語で定義した外部函数である。】

  • 定義: 現在の日時 (current dateTime) は、式の処理中における、実装依存の時点を表し、時間帯の情報も明示的に保持している。その値はfn:current-dateTime函数で取得できる。ある式の実行中、この函数を何度か呼び出しても、常に同じ結果を返す。】

  • 定義: 暗黙の時間帯 (implicit timezone) は、時間帯の情報がない日付、時刻、日時の値に対して、比較演算や算術演算を施す際に用いる時間帯である。xs:dayTimeDuration型であって、その値は実装定義である。時間帯として有効な値の範囲については、「3.2.7.3 TimezonesXS1-2」または「3.3.7 dateTimeXS11-2」を参照。】

  • 定義: 既定の言語 (default language) とは、人が読める形の出力を (たとえばfn:format-datefn:format-integerのような函数で) 生成する際に用いる自然言語で、明示的に指定されていない場合に使うものである。値はxs:language型で定義されている言語コードである。】

  • 定義: 既定の暦 (default calendar) は、人が読める形で日付を (たとえばfn:format-datefn:format-dateTimeのような函数で) 整形する際に用いる暦で、明示的に指定されていない場合に使うものである。値は文字列である。】

  • 定義: 既定の場所 (default place) は、fn:format-datefn:format-dateTimeなどの函数で日時を整形する際、事象が発生した (または発生する) 場所を特定する地理的な場所であって、明示的に指定されない場合に使うものである。時間帯オフセットを常用の時間帯名に変換する場合や、ISO形式の日時を、地理的な場所に依存するローカル表現に変換する場合に使う。この情報の表現方法として、ISO国コード、Olsonの時間帯名などが考えられるが、上記の情報を導き出せるならば、他の表現を使うよう実装してもよい。】

  • 定義: 使用可能な文書 (available documents) は、文字列から文書ノードへの対応づけである。各文字列は、資源の絶対URIを表す。文書ノードは、データ・モデルを使って資源を表した木のルートに当たる。fn:doc函数に当該URIを渡して呼び出すと、文書ノードが返される。】 使用可能な文書の集合は、静的に既知の文書の集合に限定されない。また、空であってもよい。

    使用可能な文書の1つ以上のURIが、同じ文書ノードDに対応づけられる場合、Dのdocument-uriプロパティーは、欠落、または当該URIのいずれかでなければならない。

    註記:

    したがって、文書ノード$Nが与えられたとき、「fn:doc(fn:document-uri($N)) is $N」の評価結果は常にtrueとなる。ただしfn:document-uri($N) が空シーケンスである場合を除く。

  • 定義: 使用可能なテキスト資源 (available text resources) は、文字列からテキスト資源への対応づけである。各文字列は資源の絶対URIを表す。fn:unparsed-text函数に当該URIを渡して呼び出すと、該当する資源が返される。】 使用可能なテキスト資源の集合は、静的に既知の文書の集合に限定されない。また、空であってもよい。

  • 定義: 使用可能なコレクション (available collections) は、文字列からアイテムのシーケンスへの対応づけである。各文字列は資源の絶対URIを表す。アイテムのシーケンスは、fn:collection函数に当該URIを渡して呼び出した結果を表す。】 使用可能なコレクションの集合は、静的に既知のコレクションの集合に限定されない。また、空であってもよい。

    使用可能なコレクションで文字列に対応づけられた文書ノードD、あるいは当該ノードが属する木のルートである文書ノードDについて、そのdocument-uriプロパティーは、欠落、またはあるURIでなければならない。ただし、そのURIをUとすると、使用可能な文書の中に、UからDへの対応づけがあるものとする。

    註記:

    したがって、fn:collection函数で取得した任意の文書ノード (またはこれが属する木のルートである文書ノード) $Nについて、「fn:doc(fn:document-uri($N)) is $N」を評価した結果は常にtrueとなる。ただしfn:document-uri($N) が空シーケンスである場合を除く。したがって、fn:doc函数とfn:collection函数は、その結果に一貫性がなければならない。カタログその他、ユーザーが提供するURIリゾルバーを使って、fn:doc函数に渡すURIの参照を解決をする実装の場合、fn:collection函数もこの仕組みを考慮に入れて実装する必要がある。たとえば、コレクションのURIと文書URIの集合との、対応を管理する実装が考えられる。その場合、fn:doc函数が使うのと同じカタログまたはURIリゾルバーで、URIの参照を解決することになる。

  • 定義: 既定のコレクション (default collection) は、引数なしでfn:collection函数を呼び出した時に返される、アイテムのシーケンスである。】 既定のコレクションの値は、実装によって異なってもよい。

  • 定義: 使用可能なURIコレクション (available URI collections) は、文字列からURIのシーケンスへの対応づけである。文字列は資源の絶対URIを表し、それぞれ独自のURIを持つ、多数の個別資源を集約したものとして解釈する。URIのシーケンスは、fn:uri-collection函数に当該URIを渡して呼び出した結果を表す。】 このシーケンスの各URIが、必ず参照解決できるとは限らない。できたとしても、参照先の資源が特定のメディア型であるとは限らない。

    註記:

    使用可能なコレクションと、使用可能なURIコレクションとの間で、何らかの一貫した関係を管理するよう実装してもよい。たとえば、「fn:uri-collection(X)!fn:doc(.)」と「fn:collection(X)」の結果が、同じになるように実装するのである。ただし、これは必須ではない。fn:uri-collection函数は、XML文書以外の資源にもアクセスできるという意味で、fn:collection函数よりも汎用的である。一方でfn:collection函数は、個別にURIが割り当てられていないノード (たとえば、関係データベースの行に格納された、XML断片に対応するノード) にもアクセスできる。

  • 定義: 既定のURIコレクション (default URI collection) は、引数なしでfn:uri-collection函数を呼び出した時に返される、URIのシーケンスである。】 既定のURIコレクションの値は、実装によって異なってもよい。

  • 定義: 環境変数 (environment variables) は、名前から値への対応づけである。名前も値も文字列である。名前は、実装定義の照合順序により比較し、そのもとで一意であるものとする。環境変数の集合は実装定義であり、空であってもよい。】

    註記:

    実装方法として、POSIXの環境変数 (またはオペレーティング・システムが提供する同等の仕組み) のうち、式を評価する処理に適したものを提供することが考えられる。

2.2 処理モデル

XPath 3.1は、データ・モデル式文脈の観点から定義されている。

Processing                          Model Overview

図1: 処理モデルの概要

図1に処理ステップの概要を示し、以下に各ステップの詳細を述べる。ステップの中には、完全にXPath 3.1の枠外であるものもある。図1ではこれを言語境界線の外側に描き、外部の処理 (external processing) と表示している。外部の処理としては、(a) クエリー対象データを表すXDMインスタンスの生成 (「2.2.1 データ・モデルの生成」を参照)、(b) スキーマのインポート処理 (「2.2.2 スキーマのインポート処理」を参照)、(c) 直列化がある。言語境界内の領域をXPath処理ドメイン (XPath processing domain) といい、その中に静的解析および動的評価フェーズ (「2.2.3 式の処理」を参照) がある。XPath処理ドメインにおける整合性制約については、「2.2.4 整合性制約」で定義する。

2.2.1 データ・モデルの生成

式に与える入力データは、1つ以上のXDMインスタンスとして表さなければならない。この処理はXPath 3.1のドメイン外で実行するので、図1では外部処理ドメインに描いてある。XML文書をXDMインスタンスに変換する処理は、次のステップから成る:

  1. 文書をXMLパーサーで構文解析し、XML情報集合 ([XML Infoset] を参照) を生成する。次いでこの文書を、何らかのスキーマに照らして検証してもよい ([XML Schema 1.0 Part 1] または [XML Schema 1.1 Part 1] を参照)。その結果、スキーマ検証後の情報集合 (Post-Schema Validation Infoset; PSVI) という抽象情報構造が得られる。文書が満たすべきスキーマがなければ、XML情報集合をそのまま保持する (図1のDM1を参照)。

  2. XML情報集合またはPSVIに対して、[XQuery and XPath Data Model (XDM) 3.1] に述べる処理を施し、XDMインスタンスに変換してもよい (図1のDM2を参照)。

上記のステップは、XDMインスタンスを構築する方法の一例である。代わりに、関係データベースからXDMインスタンスを直接合成するなど、他の方法を採用してもよい (図1のDM3を参照)。XPath 3.1はデータ・モデルの観点から定義しており、XDMインスタンスの構築方法には何の制約も課していない。

定義: XDMインスタンスの要素ノードや属性ノードにはそれぞれ、型註釈 (type annotation) がある (「2.7 スキーマ情報DM31」を参照)。ノードの型註釈は、XMLスキーマ型の参照である。】 ノードのtype-nameは、型註釈が参照する型の名前である。XDMインスタンスを検証済みXML文書から構築した場合 (「3.3 PSVIからの構築DM31」を参照)、要素ノードおよび属性ノードの型註釈は、スキーマ検証の結果として得られる。XPath 3.1には、要素ノードや属性ノードの型註釈に、直接アクセスする手段がない。

属性の値は、属性ノードに直接記述する。型が不明の属性ノード (スキーマなしの文書の場合に現れうる) は、型註釈xs:untypedAtomicとする。

要素ノードの値は、その一連の子ノード (テキスト・ノード、他の要素ノードなど) によって表す。要素ノードの型註釈によって、子であるテキスト・ノードの、値の解釈方法が決まる。未検証の要素ノード (スキーマなしの文書に現れうる) の場合、スキーマ型xs:untypedを型註釈とする。検証の結果、部分的に妥当であると判断した要素については、スキーマ型xs:anyTypeを型註釈とする。ある要素ノードの型註釈がxs:untypedであれば、その子孫である要素ノードもすべて、型註釈はxs:untypedである。一方、ある要素ノードの型註釈がxs:anyTypeである場合、子孫である要素ノードに、より具体的な型註釈を与えることもありうる。

2.2.2 スキーマのインポート処理

静的文脈スコープ内スキーマ定義をホスト言語で与える (図1のSI1を参照)。これは整合性制約 (「2.2.4 整合性制約」を参照) を満たさなければならない。

2.2.3 式の処理

XPath 3.1には、静的解析フェーズおよび動的評価フェーズという、2つの処理フェーズが定義されている (図1を参照)。静的解析フェーズでは、静的エラー動的エラー型エラーが発生しうる。動的評価フェーズでは、動的エラーまたは型エラーのみが発生しうる。エラーの種類については「2.3.1 エラーの種類」で定義する。

各フェーズ内では、結果がこの文書に示す仕様に合致している限り、どのような戦略やアルゴリズムで実装してもよい。

2.2.3.1 静的解析フェーズ

定義: 静的解析フェーズ (static analysis phase) の処理は、式それ自身と静的文脈に依存する。(スキーマを除き) 入力データには依存しない。】

静的解析フェーズでは、XPath式を構文解析して演算木という内部表現を生成する (図1のステップSQ1)。構文解析でエラーが見つかった場合、静的エラー [err:XPST0003] を報告する。次に、静的文脈を初期化し (ステップSQ2)、これを使ってスキーマ型名、函数名、名前空間接頭辞、変数名を解決する (ステップSQ4)。演算木に現れているこれらの名前が、静的文脈には見つからなかった場合、静的エラー ([err:XPST0008] または [err:XPST0017]) を報告する (ただし、この規則の例外が「2.5.5.3 要素テスト」および「2.5.5.5 属性テスト」にある)。

次に演算木正規化する。具体的には、原子化を施す、実効ブール値を抜き出すなど、明示的、暗黙的な操作を施す (ステップSQ5)。

静的解析フェーズで、処理系は型解析を実施してもよい。その結果、演算木の式それぞれに、静的型を割り当てることができる。【定義: 式の静的型 (static type) とは、その式の評価結果の型に関して、処理系が静的に推論できる最良の結果である。】 この仕様では、型解析に関する規則も、ある式に割り当てる静的型も定義しない。唯一の制約は、推論により判定した型が、式が返しうるすべての値に合致することである。

静的型を推論する例をいくつか示す:

  • 式「concat(a,b)」について、静的型をxs:stringと推論する。

  • 式「$a = $v」について、静的型をxs:booleanと推論する。

  • 式「$s[exp]」の静的型を、$sの静的型と同じアイテム型、ただし空シーケンスを許容するものとする。$sの静的型が空シーケンスを許容しないとしても、このように推論する。

  • 式「data($x)」の静的型を、$xの静的型の推論結果にもとづいて推論する (明示的にこのような式を記述した場合だけでなく、暗黙の原子化を施すため、処理系が演算木に挿入した場合も含む)。たとえば、$xの型が「element(*, xs:integer)」であれば、data($x)の静的型はxs:integerとなる。

XQuery 1.0およびXPath 2.0については、静的型の推論規則が規準として公開されている ([XQuery 1.0 and XPath 2.0 Formal Semantics])。しかし、より精度よく推論できるよう、この規則を改良してもよい。XQuery 3.1およびXPath 3.1では、静的型の推論規則は全面的に実装依存である。

式はその種類によらず、オペランドの型についてもある要件を課す。たとえば式「substring($a, $b, $c)」において、$aの型はxs:string (または函数呼び出しの規則によりxs:stringに変換される型)、$bおよび$cの型はxs:doubleでなければならない。

静的型検査機能が有効であるとき、推論によって得られた式の静的型が、その式が使われている文脈が要求する型に含まれていない場合、処理系は静的解析中に型エラーを報告しなければならない。たとえば先に挙げた、substringを呼び出す式で、$aの静的型をxs:integerと推論した場合、型エラーになる。xs:anyAtomicTypeと推論した場合も同様である。

静的型検査機能が有効でないときは、推論によって得られた式の静的型が、文脈に要求される型と重ならない (共通部分がない) 場合に限り、処理系は静的解析中に静的エラーを報告してよい。したがって、substringの第1引数について、静的型をxs:integerと推論したのであれば型エラーを報告してよいが、xs:anyAtomicTypeと推論した場合はそうならない。あるいは、静的型検査機能が有効でないとき、型検査をすべて動的評価フェーズまで先送りしてもよい。

2.2.3.2 動的評価フェーズ

定義: 動的評価フェーズ (dynamic evaluation phase) では、式の値を計算する。】 このフェーズは静的解析フェーズが正常に完了した場合に実施する。

動的評価フェーズを実施するのは、静的解析フェーズでエラーが検出されなかった場合に限る。静的型検査機能が有効であるとき、型エラーがあればすべて静的解析中に見つかるので、動的評価フェーズは実施しない。

動的評価フェーズは、評価するべき式の演算木 (ステップDQ1)、入力データ (ステップDQ4)、動的文脈 (ステップDQ5) に依存する。そして動的文脈は、外部環境 (ステップDQ3) および静的文脈 (ステップDQ2) から情報を取り出している。動的評価フェーズでは、新しいデータ・モデル値を生成し (ステップDQ4)、あるいは動的文脈を拡張し (ステップDQ5) てもよい。これはたとえば、値を変数に束縛する、などの方法でおこなう。

定義: 動的型 (dynamic type) は、それぞれの値を計算した時点で決まる型である。ある値の動的型が、それを計算した式の静的型より限定的であってもよい (たとえば、ある式の静的型がxs:integer* (0個以上の整数のシーケンス) であっても、実際に評価してみると、動的型はxs:integer (ちょうど1個の整数) になるかも知れない。】

ある式のオペランドの動的型が、当該オペランドにとって適切でなかった場合、型エラー [err:XPTY0004] が発生する。

静的型検査により、実行前に多くの型エラーを検出できるが、静的解析では見つからなかったエラーが、評価時に発生することもありうる。たとえば、式の中に文字列から整数へのキャストがあり、静的には妥当であったとする。しかし、実行時に渡された文字列の値が、整数に変換できないものであった場合、動的エラーが発生する。同様に、式の中に、静的型xs:untypedAtomicである値の算術演算があったとする。これは静的エラーではない。しかし、実行時に値をnumeric型に変換できなければ、動的エラーが発生する。

静的型検査機能が有効であるとき、ある入力に対しては正常に式を実行できる場合であっても、式の静的解析で型エラーが発生する場合がある。たとえば、要素をパラメーターとして要求する函数が、式の中にあるとする。さらに、静的解析フェーズで、函数パラメーターの静的型を「0個または1個の要素」と推論したとする。これは型エラーであって、実行できない。要素が実際にある入力データを与えれば、函数呼び出しは成功するはずにもかかわらず、である。

2.2.4 整合性制約

XPath 3.1をきちんと定義するためには、入力のXDMインスタンス静的文脈動的文脈が、相互に整合していなければならない。以下に列挙する整合性制約は、XPath 3.1の実装が正しく機能するための前提条件である。この整合性制約を満たすための手段は、この仕様の範囲外である。制約がすべて満たされていない場合、この仕様ではの評価結果を定義しない。

2.3 エラーの処理

2.3.1 エラーの種類

2.2.3 式の処理」で説明したように、XPath 3.1の処理は、静的解析フェーズ (入力データに依存しない) と動的評価フェーズ (入力データに依存する) に分かれている。エラーはどちらのフェーズでも発生しうる。

定義: 静的解析フェーズで検出できるエラーのうちで、型エラーではないものは、静的エラー (static error) である。】 静的エラーの例として構文エラーがある。

定義: 動的エラー (dynamic error) とは、動的評価フェーズで検出するべきエラーであるが、可能ならば静的解析フェーズで検出してもよい。動的エラーの例として、数値のオーバーフローがある。】

定義: 型エラー (type error) は、静的解析フェーズと動的評価フェーズのどちらでも発生しうる。静的解析フェーズで型エラーが発生するのは、式の静的型が、その式が現れた文脈で想定される型と合致しない場合である。動的評価フェーズで型エラーが発生するのは、値の動的型が、その値が現れた文脈で想定される型と合致しない場合である。】

静的解析フェーズの結果は、成功か、またはエラー (型エラー静的エラー、静的に検出できる動的エラー) がいくつか発生するか、である。動的評価フェーズの結果は、結果値、型エラー動的エラーのいずれかである。

複数のエラーが見つかるか、またはこの仕様で定義されている複数のエラーのスコープでエラー条件が満たされている場合、該当するエラーの一部のみを報告してもよい。

静的解析フェーズで、静的型検査機能が有効であり、ある式 (()data(()) を除く) に割り当てた静的型empty-sequence() であった場合、静的エラー [err:XPST0005] が発生する。このような状況になるのは、クエリーが参照する要素または属性がスコープ内スキーマ定義に存在しない場合で、単なる綴り誤りの可能性がある。

静的型検査機能が有効か否かにかかわらず、静的解析フェーズで、あるXPath式を評価すると必ず動的エラーまたは型エラーが発生する旨を検出できる実装の場合、当該エラーを静的解析フェーズで報告してもよい (しなくてもよい)。

XPath式から静的に動的エラーを報告するよう実装してよいのは、たとえば次のように、実行すれば (状況によらず) 必ずエラーになる場合に限る。

error()

次の例には型エラーがあり、その旨を静的に報告できる。エラーがある部分式が実際に評価されるかどうか分からなくても、そうしてよい。

if (empty($arg))
then
  "cat" * 2
else
  0

定義: 静的エラー動的エラー型エラーに加え、静的解析フェーズまたは動的評価フェーズで、警告 (warnings) を出すよう実装してもよい。実際に警告を出す状況、警告の処理方法は、実装定義である。】

この仕様で定義したエラーに加え、仕様の範囲外の理由で、動的エラーを報告するよう実装してもよい。たとえば、各種オブジェクトの個数や大きさに関して、制限がある場合が考えられる。このような制限を超えた場合は、エラー [err:XPDY0130] を報告しなければならない。

2.3.2 エラーの識別と報告

この仕様で定義するエラーは、err:XPYYnnnnという形式のQNameで識別する。ただし:

  • errはXPathおよびXQueryのエラーに関する名前空間「http://www.w3.org/2005/xqt-errors」を表す。この名前空間接頭辞errの束縛は、この文書でも便宜上使っているが、これ自体は規準ではない。

  • XPは、これがXPathのエラーである旨を表す (当初はXQueryで定義され、後にXPathにも追加されたエラーの場合は、代わりにXQを使う)。

  • YYはエラーの分類であり、次のように解釈する:

    • STは静的エラーを表す。

    • DYは動的エラーを表す。

    • TYは型エラーを表す。

  • nnnnは一意的な数値コードである。

註記:

XPathおよびXQueryのエラーに関する名前空間URIが、XPathの版によって変わることは想定していない。ただし、この名前空間の内容を拡張し、エラーの定義を追加することはありうる。

XPath 3.1の処理系がエラー情報を外部環境に報告する方法は実装定義である。

エラーは、そのQNameから導かれるURI参照により、次のように表すこともできる: 名前空間URIがNS、ローカル部分がLPであるエラーは、「NS # LP」という形のURI参照で表現できる。たとえば、QNameがerr:XPST0017であるエラーは、「http://www.w3.org/2005/xqt-errors#XPST0017」と表現できることになる。

註記:

エラーを特定するコードとともに、エラーの場所、エラーを検出した処理フェーズなど、追加の情報を添えて報告するよう実装してもよい。その場合、こういった情報を返すための仕組みは実装定義である。

2.3.3 動的エラーの取り扱い

この文書で別途註記する場合を除き、ある式のいずれかのオペランドから動的エラーが発生すれば、式自体からも動的エラーが発生する。式が有効な値を返すことも、動的エラーになることもありうる場合、値を返すか動的エラーを報告するかは、実装が選択してよい (「 2.3.4 エラーと最適化」を参照)。たとえば論理演算式「expr1 and expr2」は、一方のオペランドがfalseを返し、もう一方が動的エラーになるとき、falseを返すよう実装しても、動的エラーになるよう実装してもよい。

式の複数のオペランドがエラーになる場合、どのエラーを報告するかは、実装が選択してよい。たとえば、式:

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

は、2つの部分式「($x div $y)」および「xs:decimal($z)」のどちらでもエラーが発生しうる。このとき、「+」式がどのエラーを報告するかは、実装が選択してよい。あるオペランドがエラーになったとき、他のオペランドを評価する必要はないが、してもよい。

定義: 動的エラーが発生したとき、エラーを特定するQName以外に、その内容を説明する文字列と、エラー値 (error value) と呼ばれるいくつかの値を報告してもよい。】 アプリケーション定義のエラー・ハンドラーが、エラー値を処理して診断メッセージを生成できるよう、何らかの機構を実装してもよい。ホスト言語がエラー処理機構を提供してもよい。

動的エラーは組み込み函数や演算子で発生することもある。たとえばdiv演算子は、オペランドがxs:decimalの値であって、第2オペランドが0に等しいとき、エラーになる。組み込み函数や演算子で発生するエラーは、[XQuery and XPath Functions and Operators 3.1] に定義されている。

動的エラーは、明示的にfn:error函数を呼び出す、という方法で起こすこともできる。この函数を評価すると常に動的エラーが発生し、値を返すことはない。この函数の定義は「3.1.1 fn:errorFO31」にある。たとえば、エラーを特定するQName、説明文字列、診断値を渡して、次のように函数を呼び出すと、動的エラーが発生する (ただし、接頭辞appは、アプリケーション定義のエラー・コードを収容する名前空間に束縛されているとする):

fn:error(xs:QName("app:err057"), "Unexpected value", fn:string($v))

2.3.4 エラーと最適化

式を評価、最適化する方法は実装によって異なるので、動的エラーの発生に関して、以下に示す事項は実装依存である。

演算子のオペランドを評価する順序は、実装が自由に決めてよい。

場合によっては、式の正式な意味上、必要になるデータすべてにアクセスしなくても、式の結果を求められることがある。たとえば、しぼり込み式の正式な説明によれば、$s[1]の評価は、シーケンス$sのアイテムをすべて調べた後、述語「position()=1」を満たすものをすべて選択することになる。しかし、実際には多くの実装が、シーケンスの先頭アイテムを取り出すだけで評価が終了する、と認識するようになっている。$sが「//book[author eq 'Berners-Lee']」のような式で定義されている場合、大容量の文書全体を走査する必要がないので、処理性能を大幅に改善できる可能性がある。しかしこの戦略を採用すると、式の意味を文字どおりに解釈していれば検出できたであろう動的エラーや型エラーを、検出せずに終わってしまう可能性がある。この例では、入力データのbook要素に子要素authorが複数あれば、エラーが発生することになる。

エラーを見逃す可能性に目をつぶり、データへのアクセスを最適化してもよい範囲を、次の規則で定義する。

Qに、オペランド (部分式) Eがあるとする。一般に、Eの値はシーケンスである。シーケンスを評価する中間段階では、いくつかのアイテムが既知になっており、それ以外は未知である。この段階で、Qの評価結果に、値Vとエラーの、2つの可能性しかないと処理系が判断できたとしよう。このとき処理系は、オペランドEのアイテムをさらに評価することなく、Vを結果として返してよい。この目的で、2つのシーケンスの値は、対になるアイテムどうしがそれぞれ同じであれば、同じ結果を表すと看做す。ただし、2つのノードが同じであるのは、そのIDが同じ場合である。また、2つの値が同じであるのは、2つが等しく、かつ、まったく同じ型の場合である。

この規則には例外がある。処理系がオペランドE (全部または一部) を評価する際には、オペランドEの実際の値が、基数に関する制約に反していないことを確認する必要がある。たとえば式「$e eq 0」は、$eの値が複数のアイテムから成る場合、型エラーになる。値$eの第1アイテムを評価し、0に等しいと判断したとしても、結果は値trueと型エラー (基数に関する制約違反) の、2つの可能性しかないと判断することはできない。$eの値が高々1つのアイテムから成ることを、確認しなければならないのである。

以上の規則は、式のオペランドすべてに、組み合わせを考慮して適用する。したがって、ある式にE1およびE2という2つのオペランドがある場合、それぞれのシーケンスから選んだアイテム対のいくつかが既知になった中間段階で、上記の規則にもとづき結果を判断してよい。

規則は連鎖的に適用される: ABのオペランドであり、BCのオペランドである場合、Cの値をBの一部のアイテムのみで求めて構わないが、さらにそのBの値も、Aの一部のアイテムのみで求めて構わないことになる。

この規則があるため、シーケンスのアイテムをいくつか評価した時点で、さらに評価を続けても (エラーの可能性を除き) 結果には影響がない、と処理系が判断したら、処理を中止しても構わないことになる。たとえば式「S1 = S2」を評価する際、2つのシーケンス中に値が等しいアイテムの組が見つかった時点で、すぐにtrueを返してよい。

やはりこの規則があるため、シーケンスのどのアイテムも式の結果に影響しない場合、当該シーケンスをまったく評価しなくて構わないことになる。ただしこの場合も、基数の検査は省略できない: 空シーケンスが許されない文脈では、実際にオペランドが空シーケンスでないことを確認する必要がある。

例:

  • 次の例で、(インデックスを使うなどの手段で) $expr1の戻り値の中に、値が47であるアイテムが含まれると判断できた場合、some式の結果としてただちにtrueを返してよい。他のアイテムを評価したときエラーが発生しないか確認する必要はない。

    some $x in $expr1 satisfies $x = 47
  • 次の例で、(インデックスを使うなどの手段で) product要素ノードのうち、子要素idの値が47であるものが見つかったら、パス式の結果としてただちに当該ノードを返してよい。他のproductノードを調べたとき、子要素idの値が整数でないなどのため、エラーが発生しないか確認する必要はない。

    //product[id = 47]

最適化その他の理由で、式を別の形式に書き替えるよう実装してもよい。ただし、その範囲を制限する規則がいくつかある:

  • エラーを報告するか否かを除き、書き替えた式の評価結果は、元の式に関してこの仕様で定義している意味に従っていなければならない。

    註記:

    したがって、元の式で例外が発生する状況で結果を返し、あるいは元の式が結果を返す状況で例外を起こるよう実装してもよい。たとえば次のような場合、実際にこのような状況が生じる。(a) 書き替えにより評価順序が変わる場合。エラーが起こる部分式が、式の書き方によって、実際に評価されたり、されなかったりする状況である。(b) 評価の中間結果が、オーバーフローその他、値が所定の範囲外になる場合。

    註記:

    エラーが発生しないとしても、書き替えによって式の結果が変わることはありうる。これは、多くの場合、式の結果にある程度、実装依存または実装定義の要素があるからである。

  • 条件分岐式の場合、選ばれなかった分岐の部分式に関係して動的エラーが発生してはならない。また、選ばれなかった分岐の側から導かれる値を返してはならない。したがって次の例で、文書abc.xmlが存在しない場合に、動的エラーを起こしてはならない。

    if (doc-available('abc.xml')) then doc('abc.xml') else ()

    もちろん条件は、どの分岐を選ぶか判定するために評価する必要がある。条件の評価を迂回するようにクエリーを書き替えてはならない。

  • 先に述べたように、必要な基数の検査を省く形で式を書き替えてはならない。たとえば「string-length(//title)」という式は、文書にtitle要素が複数ある場合、エラーにしなければならない。

  • 式を書き替えた結果、新たに静的エラーが生じ、あるいは逆になくなってはならない。この仕様で、静的エラーは元の式に対して定義されているので、それを残したままで書き替える必要がある。

式の書き替え例をいくつか示す。

  • 式「//part[color eq "Red"]」を考えよう。これを「//part[color = "Red"][color eq "Red"]」と書き替える実装が考えられる。するとこの式は、次のように処理することになる: まず、「=」の述語を処理する。部品 (part) の色 (color) に関するインデックスを調べることにより、「Red」色を含む部品をすべて、迅速に見つけることができる。続いて「eq」の述語を処理する。見つかった各部品について、一色しかないことを確認するのである。結果は次のようになる:

    • 色がちょうど1つで、それがRedである部品を返す。

    • Redだけでなく他の色も使われている部品はエラーになる。

    • 複数の色が使われていても、Redがなければエラーは発生しない。

  • 次の例の式を書いてあるとおりに (すなわち、左から右に) 評価した場合、キャストに関するエラーは生じない。どちらの述語も文脈位置には依存しないので、述語の順序を入れ替え、(インデックスを活用するなど) 処理性能を改善するよう実装してもよい。この順序替えの結果、エラーが生じるようになる可能性がある。

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

    式の書き替えにより、予期しないエラーが生じるのを避けるためには、条件分岐式に、動的エラーを回避するためのテストを記述するとよい。たとえば上記の式は次のようになる:

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

2.4 概念

この節では、XPath 3.1の式を処理するために重要な、いくつかの概念について説明する。

2.4.1 文書順

文書順と呼ばれる順序を、ある式の評価時にアクセス可能な、すべてのノードにわたって定義する。このノード群は、複数のに属するものであってもよい (文書またはその断片)。文書順の定義は「2.4 文書順DM31」にあるが、便宜のため、ここでも同じ定義を繰り返して述べる。文書順は全順序である。ただし、ノードどうしの相対的な順序のいくつかは、実装依存である。【定義: (正式でない定義) 文書順 (document order) は、文書をXML形式に直列化したときに、ノードが現れる順序である。】 【定義: 文書順は安定 (stable) している。すなわち、2つのノード間の相対的な順序が、ある式を評価している間に変わることはない。この順序が実装依存であっても同様である。】 【定義: 文書順の逆であるノード順を、逆文書順 (reverse document order) という。】

ひとつの木の範囲内で、文書順は次の制約を満たす:

  1. ルート・ノードは先頭ノードである。

  2. ノードはいずれも、どのその子や子孫よりも前に現れる。

  3. 名前空間ノードは、これと対応する要素ノードの直後に現れる。名前空間ノードどうしの相対的な順序は、安定しているが実装依存である。

  4. 属性ノードは、これと対応する要素ノードの名前空間ノードの直後に現れる。属性ノードどうしの相対的な順序は、安定しているが実装依存である。

  5. 兄弟ノードどうしの相対的な順序は、その親ノードのchildrenプロパティーに現れる順序である。

  6. 子および子孫は、弟の前に現れる。

異なる木に属するノードどうしの相対的な順序は、安定しているが実装依存である。ただし、次の制約を満たすものとする: ある木T1に属するあるノードが、異なる木T2に属するあるノードよりも前ならば、木T1に属するノードはすべて、木T2に属するどのノードよりも前である。

2.4.2 原子化

XPath 3.1の演算子の中には、その意味が原子化という処理に依存するものがある。ある値を使う文脈で、原子値のシーケンスが必要になった場合、その値に原子化を施す。原子化を施した結果は、原子値のシーケンス、または型エラー [err:FOTY0012]FO31である。【定義: シーケンスの原子化 (atomization) を、fn:data函数を適用した結果と定義する。この函数の定義は「2.4 fn:dataFO31」にある。】

fn:dataの意味を、便宜のため、ここでも繰り返して述べる。fn:dataの結果は原子値のシーケンスで、入力シーケンスの各アイテムに、次の規則を適用して求める:

  • アイテムが原子値であれば、これをそのまま返す。

  • アイテムがノードであれば、その型づけされた値を返す (ノードに型づけされた値がない場合は、型エラー [err:FOTY0012]FO31 が発生する)。

  • アイテムが函数DM31 (配列を除く) またはマップであれば、型エラー [err:FOTY0013]FO31 が発生する。

  • アイテムが配列$aであれば、その原子化を「$a?* ! fn:data(.)」と定義する。これは配列の各要素を原子化することと同等である。

    註記:

    この定義によれば、要素が配列である場合、再帰的に原子化することになる。したがって、配列 [ [1, 2, 3], [4, 5, 6] ] を原子化すると、シーケンス (1, 2, 3, 4, 5, 6) が得られる。

原子化を施すのは、次のような式を処理するときである。

  • 算術演算式

  • 比較演算式

  • 函数呼び出しとその戻り

  • キャスト式

2.4.3 実効ブール値

(以下に示すような) ある状況では、値の実効ブール値を求める必要がある。【定義: ある値の実効ブール値 (effective boolean value) を、その値にfn:boolean函数を適用して得られる結果と定義する。この函数の定義は「7.3.1 fn:booleanFO31」にある。】

fn:booleanの意味を、便宜のため、ここでも繰り返して述べる:

  1. オペランドが空シーケンスであれば、fn:booleanfalseを返す。

  2. オペランドがシーケンスで、その第1アイテムがノードであれば、fn:booleantrueを返す。

  3. オペランドがシングルトン値で、その型がxs:boolean (またはその派生型) であれば、fn:booleanはオペランドの値をそのまま返す。

  4. オペランドがシングルトン値で、その型がxs:stringxs:anyURIxs:untypedAtomicのいずれか (またはその派生型) であれば、fn:booleanは、オペランド値の長さが0のときfalse、そうでなければtrueを返す。

  5. オペランドがシングルトン値で、その型がいずれかのnumeric型 (またはその派生型) であれば、fn:booleanは、オペランド値がNaN、または数として0に等しいときfalse、そうでなければtrueを返す。

  6. 上記以外の場合、fn:booleanは型エラー [err:FORG0006]FO31 になる。

    註記:

    fn:booleanが型エラーになるのは、たとえば、オペランドが函数、マップ、配列の場合である。

次のような式を処理する際には、シーケンスの実効ブール値を暗黙のうちに計算する:

  • 論理演算式 (andor)

  • fn:not函数

  • ある種の述語a[b]など

  • 条件分岐式 (if)

  • 量化式 (someevery)

  • 汎化比較 (XPath 1.0互換モードのとき)

註記:

値をxs:booleanにキャストする際には、実効ブール値の定義を使わないcast式のほか、引数としてxs:boolean型の値を想定する函数に、値を渡す場合が該当する。

2.4.4 入力源

XPath 3.1には一連のアクセス函数群が備わっており、XML文書 (fn:docfn:doc-available)、コレクション (fn:collectionfn:uri-collection)、テキスト・ファイル (fn:unparsed-textfn:unparsed-text-linesfn:unparsed-text-available)、環境変数 (fn:environment-variablefn:available-environment-variables) にアクセスできる。以上の函数の定義は「14.6 外部情報にアクセスするための函数FO31」にある。

式の中から入力データにアクセスする手段として、上記の入力函数のほかに、外部環境が初期化した動的文脈の一部 (変数文脈アイテムなど) を参照する方法がある。

2.4.5 URIリテラル

XPath 3.1では、静的に既知の有効なURIを、BracedURILiteralとして記述できる。波括弧で囲んだ空でないURIリテラルの値が、絶対URIでも相対URIでもない場合、静的エラー [err:XQST0046] になるよう実装してもよい。

註記:

xs:anyURI型は、国際化資源識別子 (IRI、Internationalized Resource Identifier、[RFC3987] に定義) も収容できるよう設計してある。

空白類は、fn:normalize-spaceの空白類正規化規則に従って正規化する。その結果、空白類のみになった場合、対応するURIは空文字列ということになる。

BracedURILiteralやURIリテラルには、パーセント符号化やその復号 ([RFC3986] に定義) を施さない。

2.4.6 相対URI参照の解決

定義: $baseという基底URIに対して、$relで表される相対URIを解決 (resolve a relative URI) するとは、函数の呼び出し「fn:resolve-uri($rel, $base)」と同じように、これを絶対URIに拡張することである。】 静的解析時に用いる基底URIは、静的な基底URIである。動的評価の際、相対URI参照を解決するために使う基底URIは、式の意味に依存する。

基底URIに対して相対URIを解決する (別の言葉で言うと、URIを参照解決する) 際、関連するRFCで定義された、パーセント符号化やその復号を施してもよい。

2.5 型

XPath 3.1の型システムは、[XML Schema 1.0] または [XML Schema 1.1] に基づく。

定義: シーケンス型 (sequence type) は、SequenceTypeの構文で表現できる型である。XPath 3.1の式で、型を参照する必要があるところでは、常にシーケンス型を使う。シーケンス型という言葉が表すように、この構文は、XPath 3.1の値 (常にシーケンス) の型を記述するために用いる。】

定義: スキーマ型 (schema type) は、[XML Schema 1.0] または [XML Schema 1.1] の機構を使って定義される (または、定義できるはずの) 型である (組み込み型を含む)。】 スキーマ型は、要素ノードや属性ノードの型註釈として使うことができる (ただし、xs:NOTATIONxs:anyAtomicTypeなど、インスタンス化できない型を除く。この場合、その派生型を使うことになる)。個々のスキーマ型は、複合型または単純型である。単純型はさらに、リスト型共用型原子型に分類できる (以上の用語の定義は、[XML Schema 1.0] または [XML Schema 1.1] を参照)。

定義: 一般化した原子型 (generalized atomic type) とは、(a) 原子型、または (b) 純共用型のことである。】

定義: 純共用型 (pure union type) とは、XML Schemaの共用型であって、次の制約を満たすものをいう: (1) {variety}unionである、(2) {facets}プロパティーは空である、(3) 共用型の遷移的メンバーのどの型も{variety}listではない、(4) 共用型の遷移的メンバーに、{variety}union、かつ、{facets}プロパティーが空でない、という型のものはない。】

註記:

純共用型の定義では、他の共用型に自明でない制約を施すことにより派生した共用型、メンバーにリスト型を含む共用型を除外している。純共用型には、そのメンバー型のひとつとして定義された原子型のインスタンスがすべて、共用型の有効なインスタンスでもある、という特性がある。

註記:

現行版 (第2版) のXML Schema 1.0には、共用型をそのメンバーのひとつで代替する可能性に関して誤りがある。ある共用型が、他の共用型に制約を施すことにより派生したものである場合、これが安全でないことを見落としているのである。

この問題はXSD 1.1で修正済みであるが、その結果、原子型とラベルづけされた原子値は、明示的に検証しない限り、共用型に代替できるものと看做すことはできなくなった。そこでこの仕様では、いくつかの原子型の共用型として直接定義されている場合に限って、この共用型をアイテム型として扱えることにしている。

一般化した原子型は、シーケンス型スキーマ型という、2つのカテゴリーの共通部分に当たる。xs:integermy:hatsizeのような、一般化した原子型は、シーケンス型であり、かつ、スキーマ型でもある。

2.5.1 定義済みスキーマ型

静的文脈スコープ内スキーマ型は、ホスト言語が定める、定義済みスキーマ型の集合が初期状態である。この集合には、名前空間http://www.w3.org/2001/XMLSchema (この文書では名前空間接頭辞xsで表す) に属するスキーマ型の、一部または全部を含めてよい。この名前空間に属するスキーマ型の定義は [XML Schema 1.0] または [XML Schema 1.1] にあり、これを補う形で、[XQuery and XPath Data Model (XDM) 3.1] にも追加の型が定義されている。[XML Schema 1.0] の型システムを基盤とする実装では、xs:dateTimeStamp型やxs:error型に対応しなくてもよい。

2.7.2 定義済みの型DM31」に定義されているスキーマ型の概要を以下に示す。

  1. 定義: xs:untypedは、未検証の要素ノード、またはskipモードで検証した要素ノードの型註釈として使う。】 xs:untypedから派生した、定義済みのスキーマ型はない。

  2. 定義: xs:untypedAtomicは原子型であって、型づけしていない原子データを表すために使う。たとえば、より限定的な型を割り当てていないテキストが該当する。】 skipモードで検証した属性を、データ・モデルでは、型註釈xs:untypedAtomicである属性ノードとして表す。xs:untypedAtomicから派生した、定義済みのスキーマ型はない。

  3. 定義: xs:dayTimeDurationは、xs:durationに制限を施した派生型である。xs:dayTimeDurationの字句的表現では、日、時、分、秒の要素のみに制限する。】

  4. 定義: xs:yearMonthDurationは、xs:durationに制限を施した派生型である。xs:yearMonthDurationの字句的表現では、年、月の要素のみに制限する。】

  5. 定義: xs:anyAtomicTypeは原子型で、あらゆる原子値を収容できる (逆に原始値以外は収容できない)。基底型はxs:anySimpleTypeで、ここからすべての単純型 (原始型、リスト、共用型など) が派生する。原初的な原子型 (xs:decimalxs:stringなど) はすべて、xs:anyAtomicTypeを基底型とする。】

    註記:

    xs:anyAtomicTypeXDMインスタンスに、実際の値の型として現れることはない。

  6. 定義: xs:errorは値空間のない単純型である。その定義は「3.16.7.3 xs:errorXS11-1」にある。SequenceType (「2.5.4 SequenceTypeの構文」を参照) で、エラーを発生させるために使える。】

xs名前空間のスキーマ型全体の関係を図2に示す。XPath 3.1の型階層に関するより完全な説明が、「1.6 型システムFO31」にある。

Type Hierarchy Diagram

図2: XPath 3.1で用いるスキーマ型の階層

2.5.2 名前空間に依存する型

定義: 名前空間に依存する (namespace-sensitive) 型とは、xs:QNamexs:NOTATIONxs:QNameまたはxs:NOTATIONを制限した派生型、名前空間に依存するアイテム型のリスト型、名前空間に依存する型が遷移的メンバーにある共用型のことである。】

名前空間に依存する値の型を保持しておくためには、値に使われている名前空間接頭辞の意味を定義する、名前空間の束縛がなければならない。そこでXPath 3.1では、名前空間に依存する値に関してのみ発生するエラー条件をいくつか定義している。たとえば、ある値を名前空間に依存する型にキャストしようとしても、その結果に対する名前空間束縛が定まらない場合、型エラー [err:FONS0004]FO31 が発生する。

2.5.3 型づけされた値と文字列値

ノードにはすべて、型づけされた値文字列値がある。ただし、値が欠落DM31しているノードを除く。【定義: ノードの型づけされた値 (typed value) は、函数fn:data (「2.4 fn:dataFO31」を参照) をノードに適用して得られる、原子値のシーケンスである。】 【定義: ノードの文字列値 (string value) は、函数fn:string (「2.3 fn:stringFO31」を参照) をノードに適用して得られる文字列である。】

型づけされた値文字列値を、両方ともノードに格納するよう実装してもよいし、いずれか一方のみ格納しておき、もう一方は必要に応じて求めるようにしてもよい。ノードの文字列値は、型づけされた値の字句的に正しい表現でなければならないが、入力源である文書の文字列表現を保存しておく必要はない。たとえば、ノードの型づけされた値がxs:integer型の30である場合、その文字列値は「30」でも「0030」でもありうる。

ノードの型づけされた値文字列値型註釈は、密接に関連している。XML情報集合またはPSVIからマップして生成したノードの場合、これら3つの関係は、「2.7 スキーマ情報DM31」の規則によって決まる。

便宜のため、各種のノードについて、型づけされた値文字列値の関係を要約して示し、例を挙げる。

  1. テキスト・ノードおよび文書ノードの場合、型づけされた値は文字列値と同じ、xs:untypedAtomic型のインスタンスである。文書ノードの文字列値は、子孫であるテキスト・ノードすべての文字列値を、文書順に連結することにより得られる。

  2. 註釈、名前空間、処理命令の各ノードの場合、型づけされた値は文字列値と同じである。これはxs:string型のインスタンスである。

  3. 型註釈xs:anySimpleTypeまたはxs:untypedAtomicである属性ノードの型づけされた値は、文字列値と同じで、xs:untypedAtomicのインスタンスである。型註釈が上記以外である属性ノードの型づけされた値は、文字列値と型註釈をもとに、字句から値空間へのマッピング ([XML Schema 1.0] または [XML Schema 1.1] Part 2を参照) を使って求められる。

    例: A1が属性で、文字列値が「3.14E-2」、型註釈がxs:doubleであるとする。A1の型づけされた値は、xs:double型の値であって、その字句的表現は3.14E-2となる。

    例: A2が属性で、型註釈はxs:IDREFSであるとする。これはリスト・データ型で、そのアイテムの型は原子データ型xs:IDREFである。文字列値は「bar baz faz」であるとする。このとき、A2の型づけされた値は、3つの原子値から成るシーケンス ("bar", "baz", "faz") であって、各アイテムの型はxs:IDREFである。ノードの型づけされた値を、名前つきリスト型のインスタンスとして扱うことはない。代わりに、ノードの型註釈がリスト型 (たとえばxs:IDREFS) であれば、その型づけされた値を、その元になった一般化した原子型 (たとえばxs:IDREF) のシーケンスとして扱う。

  4. 要素ノードの場合、型づけされた値と文字列値の関係は、ノードの型註釈に依存して次のようになる:

    1. 型註釈がxs:untypedまたはxs:anySimpleType、あるいは内容が混合した複合型 (xs:anyTypeを含む) である場合、型づけされた値は文字列値と等しく、xs:untypedAtomicのインスタンスである。ただし、ノードのnilledプロパティーがtrueであれば、型づけされた値は空シーケンスである。

      例: E1は要素ノードで、型註釈がxs:untyped、文字列値が「1999-05-31」であるとする。E1の型づけされた値はxs:untypedAtomicのインスタンス「1999-05-31」となる。

      例: E2は要素ノードで、型註釈がformula (内容が混合した複合型) であるとする。E2の内容は、文字「H」、subscriptという子要素 (文字列値が「2」)、文字「O」から成るとする。この場合、E2の型づけされた値は「H2O」であって、これはxs:untypedAtomicのインスタンスである。

    2. 型註釈が、単純型、または単純な内容の複合型である場合、ノードの型づけされた値は、その文字列値と型註釈をもとに、スキーマ検証結果と整合するように決める。ただし、ノードのnilledプロパティーがtrueであれば、型づけされた値は空シーケンスである。

      例: E3は要素ノードで、型註釈がcostであるとしよう。これは複合型で、いくつかの属性と、単純な内容型xs:decimalから成る。E3の文字列値は「74.95」とする。このとき、E3の型づけされた値は、74.95というxs:decimalのインスタンスになる。

      例: E4は要素ノードで、型註釈がhatsizelistであるとしよう。これは、xs:integerの派生型である、原子型hatsizeから派生した単純型である。E4の文字列値は「7 8 9」とする。このとき、E4の型づけされた値は、3つの値から成るシーケンス (7, 8, 9) で、各アイテムの型はhatsizeとなる。

      例: E5は要素ノードで型註釈がmy:integer-or-stringであるとしよう。これはxs:integerxs:stringをメンバー型とする共用型である。E5の文字列値は「47」とする。このとき、E5の型づけされた値は47で、xs:integer型になる。E5の内容を検証すると、xs:integerがそのメンバー型になるからである。一般に、ノードの型註釈が共用型の場合、その型づけされた値は、いずれかのメンバー型のインスタンスになる。

      註記:

      ノードの文字列値のみ保存する実装で、あるノードの型註釈が共用型である場合、その型づけされた値を、適切なメンバー型のインスタンスとして導出できるよう実装しなければならない。

    3. あるノードの型註釈が、内容が空の複合型を示している場合、その型づけされた値は空シーケンス、文字列値は長さが0の文字列である。

    4. あるノードの型註釈が、要素のみから成る複合型である場合、その型づけされた値は欠落DM31している。fn:data函数をこのようなノードに適用すると、型エラー [err:FOTY0012]FO31 が発生する。文字列値は、子孫であるテキスト・ノードすべての文字列値を、文書順に連結することにより得られる。

      例: E6は要素ノードで、型註釈がweatherであるとしよう。これは複合型で、その内容の型はelement-onlyであるものとする。さらに、E6にはtemperatureおよびprecipitationという子要素がある。このとき、E6の型づけされた値は欠落DM31しており、fn:data函数をE6に適用するとエラーが発生する。

2.5.4 SequenceTypeの構文

XPath 3.1の式で型を参照する必要がある場合は常に、SequenceTypeの構文を使う。

[79]    SequenceType    ::=    ("empty-sequence" "(" ")")
| (ItemType OccurrenceIndicator?)
[81]    ItemType    ::=    KindTest | ("item" "(" ")") | FunctionTest | MapTest | ArrayTest | AtomicOrUnionType | ParenthesizedItemType
[80]    OccurrenceIndicator    ::=    "?" | "*" | "+" /* xgc: occurrence-indicators */
[82]    AtomicOrUnionType    ::=    EQName
[83]    KindTest    ::=    DocumentTest
| ElementTest
| AttributeTest
| SchemaElementTest
| SchemaAttributeTest
| PITest
| CommentTest
| TextTest
| NamespaceNodeTest
| AnyKindTest
[85]    DocumentTest    ::=    "document-node" "(" (ElementTest | SchemaElementTest)? ")"
[94]    ElementTest    ::=    "element" "(" (ElementNameOrWildcard ("," TypeName "?"?)?)? ")"
[96]    SchemaElementTest    ::=    "schema-element" "(" ElementDeclaration ")"
[97]    ElementDeclaration    ::=    ElementName
[90]    AttributeTest    ::=    "attribute" "(" (AttribNameOrWildcard ("," TypeName)?)? ")"
[92]    SchemaAttributeTest    ::=    "schema-attribute" "(" AttributeDeclaration ")"
[93]    AttributeDeclaration    ::=    AttributeName
[95]    ElementNameOrWildcard    ::=    ElementName | "*"
[99]    ElementName    ::=    EQName
[91]    AttribNameOrWildcard    ::=    AttributeName | "*"
[98]    AttributeName    ::=    EQName
[101]    TypeName    ::=    EQName
[89]    PITest    ::=    "processing-instruction" "(" (NCName | StringLiteral)? ")"
[87]    CommentTest    ::=    "comment" "(" ")"
[88]    NamespaceNodeTest    ::=    "namespace-node" "(" ")"
[86]    TextTest    ::=    "text" "(" ")"
[84]    AnyKindTest    ::=    "node" "(" ")"
[102]    FunctionTest    ::=    AnyFunctionTest
| TypedFunctionTest
[103]    AnyFunctionTest    ::=    "function" "(" "*" ")"
[104]    TypedFunctionTest    ::=    "function" "(" (SequenceType ("," SequenceType)*)? ")" "as" SequenceType
[111]    ParenthesizedItemType    ::=    "(" ItemType ")"
[105]    MapTest    ::=    AnyMapTest | TypedMapTest
[108]    ArrayTest    ::=    AnyArrayTest | TypedArrayTest

特別な型であるempty-sequence()を除き、シーケンス型は、シーケンスに現れる各アイテムの型を制約するアイテム型と、アイテムの数を制約する基数から成る。あらゆる種類のアイテムを許容するアイテム型item()を除き、アイテム型は、ノード型 (例: element())、一般化した原子型 (例: xs:integer)、函数型 (例: function() as item()*) に分類できる。

シーケンス型に現れる字句規則上のQNameには、接頭辞が含まれる。これを、静的に既知の名前空間および (該当する場合) 既定の要素/型名前空間を使って、名前空間URIに展開する。QNameどうしの等価性は、eq演算子で定義する。

要素ノードや属性ノードを表すアイテム型には、そのノードが満たすべき型註釈を、スキーマ型の形で指定してよい。たとえばアイテム型「element(*, us:address)」は、型註釈がus:addressというスキーマ型 (またはその派生型) である、任意の要素ノードを表す。

出現数標識「+」、「*」、「?」は、すぐ前にあるItemTypeを制約する (「制約: occurrence-indicators」を参照)。

XPath 3.1で使われるシーケンス型の例をいくつか示す:

  • xs:date」は、xs:dateという組み込みの原子スキーマ型を表す。

  • attribute()?」は、属性ノードが現れるが、なくてもよいことを表す。

  • element()」は任意の要素ノードを表す。

  • element(po:shipto, po:address)」は、要素ノードであって、名前がpo:shipto、型註釈がpo:address (またはその派生型) であるものを表す。

  • element(*, po:address)」は、任意の名前の要素ノードで、型註釈がpo:address (またはその派生型) であるものを表す。

  • element(customer)」は、customerという名前で、任意の型註釈の要素ノードを表す。

  • schema-element(customer)」は、要素ノードであって、名前がcustomer (またはcustomerをヘッドとする代替グループに属する名前) であり、型註釈が、スコープ内要素宣言customer要素に対して宣言されたスキーマ型に合致するものを表す。

  • node()*」は、任意の種類のノードの、0個以上のシーケンスを表す。

  • item()+」は、1個以上のアイテムから成るシーケンスを表す。

  • function(*)」は任意の函数DM31を表し、アリティーや型にはよらない。

  • function(node()) as xs:string*」は、函数DM31であって、単一のノードを値とする引数を1つ取り、0個以上のxs:string値を返すものを表す。

  • (function(node()) as xs:string)*」は、0個以上の函数DM31から成るシーケンスを表す。ただし、それぞれの函数は、単一のノードを値とする引数を1つ取り、1個のxs:string値を返すものとする。

2.5.5 SequenceTypeの照合

定義: SequenceTypeの照合 (SequenceType matching) では、ある値の動的型を、想定するシーケンス型と比較する。】 たとえばinstance of式は、与えられた値の動的型が指定されたシーケンス型に合致するときtrueを返し、そうでなければfalseを返す。

XPath 3.1の処理系は、XDMインスタンスにおける型註釈の型と、スコープ内スキーマ定義 (ISSD) に現れる型との関係を、判断できるよう実装しなければならない。

定義: 動的型が、想定する型でなく、その派生型であるような値を使うことを、派生型の代用 (subtype substitution) という。】 派生型の代用では、値の実際の型を変更しない。たとえば、xs:decimal値を想定しているところで、xs:integer型の値を代用する場合、値の型はxs:integerのままである。

SequenceTypeの照合の定義には、derives-from(AT, ET) という擬似函数を使う。実際の単純/複合スキーマ型ATと、想定する単純/複合スキーマ型ETを引数とし、ブール値を返すか、または型エラー [err:XPTY0004] を起こす函数である。この函数を、次のように定義する:

  • ETスコープ内スキーマ定義になければ、型エラー [err:XPTY0004] を起こす。

  • 次のいずれかの条件を満たせばtrueを返す:

    • ATETである。

    • ETATの基底型である。

    • ETは純共用型で、ATはそのメンバー型である。

    • derives-from(AT, MT) かつderives-from(MT, ET) であるような型MTが存在する。

  • 上記以外の場合はfalseを返す。

SequenceTypeの照合規則を、例とともに示す (例は説明のために示すのであって、すべての場合を尽くしてはいない)。

2.5.5.1 SequenceTypeと値の照合

OccurrenceIndicatorは、シーケンスに含まれるアイテムの個数を指定する:

  • ?」は0個または1個のアイテムとの合致を表す。

  • *」は0個以上のアイテムとの合致を表す。

  • +」は1個以上のアイテムとの合致を表す。

この規則の帰結として、OccurrenceIndicatorが「*」または「?」であるシーケンス型は、空シーケンスである値と合致する。

2.5.5.2 ItemTypeとアイテムの照合
  • ItemTypeが単なるEQNameである場合、AtomicOrUnionTypeとして解釈する。想定する型AtomicOrUnionTypeが、型ATの原子値と合致するのは、derives-from(AT, AtomicOrUnionType)trueである場合である。

    AtomicOrUnionTypeの名前に接頭辞があれば、静的に既知の名前空間を使って名前空間URIに展開する。接頭辞がなければ、既定の要素/型名前空間を使って名前空間URIに展開する。AtomicOrUnionType展開済みQNameが、スコープ内スキーマ型で、一般化した原子型として定義されていない場合、静的エラー [err:XPST0051] になる。

    例: ItemTypexs:decimal」は、xs:decimal型の任意の値と合致する。さらに、shoesizeが、xs:decimalを制約することにより派生した原子型であるとすれば、shoesize型の任意の値とも合致する。

    例: ItemTypedress-size」は共用型で、数値で表したサイズ (例: 4、6、10、12) をxs:decimal値として扱うほか、所定のxs:strings値 (例: "small"、"medium"、"large") も使えるものとする。するとItemTypedress-size」は、ここに例示したどの値にも合致する。

    註記:

    xs:IDREFSのような非原子型は、この文脈には記述できない。しかし、「xs:IDREF+」のように、出現数標識つきの一般化した原子型で置き換えられることが多い。

  • item()」は、単一のアイテムであれば何とでも合致する。

    例: 「item()」は、原子値1、要素<a/>、函数fn:concat#3などと合致する。

  • node()」は任意のノードと合致する。

  • text()」は任意のテキスト・ノードと合致する。

  • processing-instruction()」は任意の処理命令ノードと合致する。

  • processing-instruction(N)」は、処理命令ノードのうち、PITargetがfn:normalize-space(N) に等しいものと合致する。fn:normalize-space(N) がNCNameの字句空間内になければ、型エラー [err:XPTY0004] が発生する。

    例: 「processing-instruction(xml-stylesheet)」は、PITargetがxml-stylesheetである、任意の処理命令と合致する。

    XPath 1.0との後方互換性を維持するため、処理命令のPITargetは、「processing-instruction("xml-stylesheet")」のように文字列リテラルで表してもよいことになっている。

    指定されたPITargetが構文的に正しいNCNameでなければ、型エラー [err:XPTY0004] が発生する。

  • comment()」は任意の註釈ノードと合致する。

  • namespace-node()」は任意の名前空間ノードと合致する。

  • document-node()」は任意の文書ノードと合致する。

  • document-node(E)」は、文書ノードのうち、ちょうど1個の要素ノードを収容するものと合致する。ほかに註釈ノードや処理命令ノードをいくつか収容していても構わない。ただし、EElementTestまたはSchemaElementTestで、これが要素ノードに合致するものとする (「2.5.5.3 要素テスト」、「2.5.5.4 スキーマ要素テスト」を参照)。

    例: 「document-node(element(book))」は、文書ノードのうち、ちょうど1個の要素ノードを収容し、この要素がElementTest「element(book)」と合致するものと合致する。

  • ParenthesizedItemTypeがアイテムに合致するのは、そのアイテムが、括弧に囲まれたItemTypeと合致する場合である。

  • ItemTypeが、ElementTestSchemaElementTestAttributeTestSchemaAttributeTestFunctionTestのいずれかである場合、以下の各節に述べるアイテムと合致する。

  • ItemTypemap(K, V)」がアイテムMと合致するのは、(a) Mマップであって、(b) Mのエントリーがすべて、キーがKに、値がVに合致する場合である。たとえば「map(xs:integer, element(employee))」は、キーが整数、対応する値がすべてemployee要素であるようなマップと合致する。なお、マップには (シーケンスと同様) 固有の型情報がなく、その各エントリーに型があるだけである。マップに既存のエントリーの型が、新たに追加できるエントリーの型を制約することはない。

    註記:

    その帰結として、「map(K, V)」は空のマップにも合致する。型KおよびVにはよらない。

  • ItemTypemap(*)」は、その内容によらず、任意のマップと合致する。これは「map(xs:anyAtomicType, item()*)」と同等である。

  • ItemTypearray(T)」は、配列であって、要素の型がすべてTであるものと合致する。

  • ItemTypearray(*)」は、その内容によらず、任意の配列と合致する。

2.5.5.3 要素テスト
[94]    ElementTest    ::=    "element" "(" (ElementNameOrWildcard ("," TypeName "?"?)?)? ")"
[95]    ElementNameOrWildcard    ::=    ElementName | "*"
[99]    ElementName    ::=    EQName
[101]    TypeName    ::=    EQName

ElementTestは要素ノードを、その名前や型註釈によって照合する。

ElementTestElementNameおよびTypeNameに接頭辞があれば、静的に既知の名前空間を使って名前空間URIに展開する。接頭辞がなければ、既定の要素/型名前空間を使って名前空間URIに展開する。ElementNameスコープ内要素宣言になくてもよいが、TypeNameスコープ内スキーマ型になければならない [err:XPST0008]。なお、代替グループElementTestの意味に影響を与えない。

ElementTestは次のいずれかの形である:

  1. element()」および「element(*)」は、単一の任意の要素ノードと合致する。名前や型註釈にはよらない。

  2. element(ElementName)」は、要素ノードであって、名前がElementNameであるものと合致する。型註釈やnilledプロパティーにはよらない。

    例: 「element(person)」は、名前がpersonである任意の要素ノードと合致する。

  3. element(ElementName, TypeName)」は、名前がElementNameで、derives-from(AT, TypeName)true、かつ、nilledプロパティーがfalseである要素ノードと合致する。ただし、ATは要素ノードの型註釈である。

    例: 「element(person, surgeon)」は、nillでない要素ノードであって、名前がperson、型註釈がsurgeon (またはその派生型) であるものと合致する。

  4. element(ElementName, TypeName ?)」は、名前がElementNameで、derives-from(AT, TypeName)trueである要素ノードと合致する。ただし、ATは要素ノードの型註釈である。ノードのnilledプロパティーは、trueでもfalseでも構わない。

    例: 「element(person, surgeon?)」は、nillか否かにかかわらず、名前がperson、型註釈がsurgeon (またはその派生型) である要素ノードと合致する。

  5. element(*, TypeName)」は、名前によらず、derives-from(AT, TypeName)true、かつ、nilledプロパティーがfalseである要素ノードと合致する。ただし、ATは要素ノードの型註釈である。

    例: 「element(*, surgeon)」は、nillでない要素ノードであって、名前によらず、型註釈がsurgeon (またはその派生型) であるものと合致する。

  6. element(*,TypeName ?)」は、名前によらず、derives-from(AT, TypeName)trueである要素ノードと合致する。ただし、ATは要素ノードの型註釈である。ノードのnilledプロパティーは、trueでもfalseでも構わない。

    例: 「element(*, surgeon?)」は、nillか否かにかかわらず、名前にもよらず、型註釈がsurgeon (またはその派生型) である要素ノードと合致する。

2.5.5.4 スキーマ要素テスト
[96]    SchemaElementTest    ::=    "schema-element" "(" ElementDeclaration ")"
[97]    ElementDeclaration    ::=    ElementName
[99]    ElementName    ::=    EQName

SchemaElementTestは要素ノードを、スコープ内要素宣言の、対応する要素宣言と照合する。

SchemaElementTestElementNameに接頭辞があれば、静的に既知の名前空間を使って名前空間URIに展開する。接頭辞がなければ、既定の要素/型名前空間を使って名前空間URIに展開する。SchemaElementTestに指定されているElementNameスコープ内要素宣言にない場合、静的エラー [err:XPST0008] が発生する。

SchemaElementTestが候補である要素ノードと合致するのは、次の条件をすべて満たしている場合である:

  1. 次のいずれかが成り立つ:

    1. 候補ノードの名前Nが、指定されたElementNameと合致するか、または

    2. 候補ノードの名前Nが、要素ElementNameの宣言をヘッドとする実代替グループの、メンバーである要素宣言の名前と合致する。

    註記:

    「実代替グループ」(actual substitution group) の定義は [XML Schema 1.1] にある。要素宣言Pが、要素宣言Hの実代替グループに属するとは、PHを直接または間接の代替グループ・ヘッドとし (ただし、Pは抽象型と宣言されていないとする)、かつ、Pが有効にHを代替できる (すなわち、代替を禁じるような制約がない) ことである。

  2. スキーマ要素宣言Nが抽象宣言ではない。

  3. derives-from( AT, ET ) がtrueである。ただし、ATは候補ノードの型註釈、ETは、スキーマ要素宣言Nで宣言されたスキーマ型とする。

  4. スキーマ要素宣言Nがnill化できない場合、候補ノードのnilledプロパティーはfalseである。

例: SchemaElementTestschema-element(customer)」は、次の2つの状況で、候補である要素ノードと合致する:

  1. customerはスコープ内要素宣言の最上位に位置する要素宣言である; 候補ノードの名前はcustomerである; customerの要素宣言が抽象宣言でない; 候補ノードの型註釈が、customer要素宣言のスキーマ型、またはその派生型と同じである; 候補ノードがnill化されていないか、またはcustomerがnill化可能と宣言されている。

  2. customerはスコープ内要素宣言の最上位に位置する要素宣言である; 候補ノードの名前はclientである; clientは、customerの代替グループの実メンバーである (抽象メンバーやブロックされたメンバーではない); 候補ノードの型註釈が、client要素に対して宣言されたスキーマ型、またはその派生型と同じである; 候補ノードがnill化されていないか、またはclientがnill化可能と宣言されている。

2.5.5.5 属性テスト
[90]    AttributeTest    ::=    "attribute" "(" (AttribNameOrWildcard ("," TypeName)?)? ")"
[91]    AttribNameOrWildcard    ::=    AttributeName | "*"
[98]    AttributeName    ::=    EQName
[101]    TypeName    ::=    EQName

AttributeTestは属性ノードを、その名前や型註釈によって照合する。

AttributeTestAttributeNameおよびTypeNameに接頭辞があれば、静的に既知の名前空間を使って名前空間URIに展開する。接頭辞がないAttributeNameには名前空間がないことになるが、接頭辞がないTypeName既定の要素/型名前空間に属する。AttributeNameスコープ内属性宣言になくてもよいが、TypeNameスコープ内スキーマ型になければならない [err:XPST0008]。

AttributeTestは次のいずれかの形である:

  1. attribute()」および「attribute(*)」は、単一の任意の属性ノードと合致する。名前や型註釈にはよらない。

  2. attribute(AttributeName)」は、属性ノードであって、名前がAttributeNameであるものと合致する。型註釈にはよらない。

    例: 「attribute(price)」は、名前がpriceである任意の属性ノードと合致する。

  3. attribute(AttributeName, TypeName)」は、名前がAttributeNameで、derives-from(AT, TypeName)trueである属性ノードと合致する。ただし、ATは属性ノードの型註釈である。

    例: 「attribute(price, currency)」は、名前がprice、型註釈がcurrency (またはその派生型) である属性ノードと合致する。

  4. attribute(*, TypeName)」は、名前によらず、derives-from(AT, TypeName)trueである属性ノードと合致する。ただし、ATは属性ノードの型註釈である。

    例: 「attribute(*, currency)」は、名前によらず、型註釈がcurrency (またはその派生型) である属性ノードと合致する。

2.5.5.6 スキーマ属性テスト
[92]    SchemaAttributeTest    ::=    "schema-attribute" "(" AttributeDeclaration ")"
[93]    AttributeDeclaration    ::=    AttributeName
[98]    AttributeName    ::=    EQName

SchemaAttributeTestは属性ノードを、スコープ内属性宣言の、対応する属性宣言と照合する。

SchemaAttributeTestAttributeNameに接頭辞があれば、静的に既知の名前空間を使って名前空間URIに展開する。接頭辞がなければ、AttributeNameには名前空間がないことになる。SchemaAttributeTestに指定されているAttributeNameスコープ内属性宣言にない場合、静的エラー [err:XPST0008] が発生する。

SchemaAttributeTestが候補である属性ノードと合致するのは、次の条件をどちらも満たしている場合である:

  1. 候補ノードの名前が、指定されたAttributeNameと合致する。

  2. derives-from(AT, ET)trueである。ただし、ATは候補ノードの型註釈、ETは、スコープ内属性宣言にある、属性AttributeNameに対して宣言されたスキーマ型とする。

例: SchemaAttributeTestschema-attribute(color)」が候補である属性ノードと合致するのは、次のような状況である: colorスコープ内属性宣言の最上位に位置する属性宣言である; 候補ノードの名前はcolorである; 候補ノードの型註釈が、color属性宣言のスキーマ型、またはその派生型と同じである。

2.5.5.7 函数テスト
[102]    FunctionTest    ::=    AnyFunctionTest
| TypedFunctionTest
[103]    AnyFunctionTest    ::=    "function" "(" "*" ")"
[104]    TypedFunctionTest    ::=    "function" "(" (SequenceType ("," SequenceType)*)? ")" "as" SequenceType

FunctionTest函数DM31を照合する。さらに、函数シグニチャーDM31を照合することもある。AnyFunctionTestは、函数である任意のアイテムに合致する。TypedFunctionTestがアイテムに合致するのは、これが函数DM31であって、その型シグニチャー (「2.8.1 函数DM31」に定義) がTypedFunctionTest派生型である場合である。

FunctionTestの例をいくつか示す:

  1. function(*)」は任意の函数に合致する。マップや配列も含む。

  2. function(int, int) as int」は、函数DM31であって、そのシグニチャーが「function(int, int) as int」であるものに合致する。

  3. function(xs:anyAtomicType) as item()*」は、シグニチャーが合致する函数のほか、マップにも合致する。

  4. function(xs:integer) as item()*」は、シグニチャーが合致する函数のほか、配列にも合致する。

2.5.5.8 マップ・テスト
[105]    MapTest    ::=    AnyMapTest | TypedMapTest
[106]    AnyMapTest    ::=    "map" "(" "*" ")"
[107]    TypedMapTest    ::=    "map" "(" AtomicOrUnionType "," SequenceType ")"

MapTestmap(*)」は任意のマップに合致する。MapTestmap(X, Y)」は、マップであって、キーがすべてXのインスタンス、値がすべてYのインスタンスであるものと合致する。

例:

キーが整数、値が文字列のマップ$Mが与えられたとする (例: map{0:"no", 1:"yes"})。次の式の評価結果を考えてみよう:

  • $M instance of map(*)」はtrue() を返す

  • $M instance of map(xs:integer, xs:string)」はtrue() を返す

  • $M instance of map(xs:decimal, xs:anyAtomicType)」はtrue() を返す

  • not($M instance of map(xs:int, xs:string))」はtrue() を返す

  • not($M instance of map(xs:integer, xs:token))」はtrue() を返す

シグニチャーにもとづく、函数型の派生に関する規則により、アイテム型「function(A) as item()*」(ただしAは原子型) も、実際に現れるキーの型によらず、任意のマップに合致する。たとえば、キーがすべて文字列であるマップを、要求されている型が「function(xs:integer) as item()*」である箇所で使うことができる。マップの呼び出しを、整数を引数とする函数として扱えば、常に成功し、空シーケンスを返す。

map(K, V) 型のマップを函数として扱う場合、函数シグニチャーは「function(xs:anyAtomicType) as V?」となる。これは常に「function(xs:anyAtomicType) as item()*」の派生型であって、キーや値の、実際の型にはよらない。函数の強制型変換の規則によれば、より限定的な戻り値型の函数 (例: 「function(xs:anyAtomicType) as xs:integer」) が必要な文脈にも、「instance of」演算子の意味で合致するか否かにかかわらず、任意のマップを値として与えることができる。実際にマップを (函数として) 呼び出したとき、その戻り値が、必要な戻り値型のインスタンスでなかった場合に限り、型エラーが発生する。

例:

  • $M instance of function(*)」はtrue() を返す。

  • $M instance of function(xs:anyAtomicType) as item()*」はtrue() を返す。

  • $M instance of function(xs:integer) as item()*」はtrue() を返す。

  • $M instance of function(xs:int) as item()*」はtrue() を返す。

  • $M instance of function(xs:string) as item()*」はtrue() を返す。

  • not($M instance of function(xs:integer) as xs:string)」はtrue() を返す。

註記:

最後の例は驚かれるかも知れないが、函数の強制型変換の仕組みより、必要な型が「function(xs:integer) as xs:string」であるところでは必ず、$Mを使うことができる。

2.5.5.9 配列テスト
[108]    ArrayTest    ::=    AnyArrayTest | TypedArrayTest
[109]    AnyArrayTest    ::=    "array" "(" "*" ")"
[110]    TypedArrayTest    ::=    "array" "(" SequenceType ")"

AnyArrayTestarray(*)」は任意の配列に合致する。TypedArrayTestarray(X)」は、要素がすべてSequenceTypeX」に合致する、任意の配列に合致する。

例:

  • [ 1, 2 ] instance array(*)」はtrue() を返す。

  • [] instance of array(xs:string)」はtrue() を返す。

  • [ "foo" ] instance of array(xs:string)」はtrue() を返す。

  • [ "foo" ] instance of array(xs:integer)」はfalse() を返す。

  • [(1,2),(3,4)] instance of array(xs:integer)」はfalse() を返す。

  • [(1,2),(3,4)] instance of array(xs:integer+)」はtrue() を返す。

配列はほかに、次のようなItemTypesにも合致する:

  • item()

  • function(*)

  • function(xs:integer) as item()*

array(X) 型の配列を函数として扱う場合、函数シグニチャーは「function(xs:integer) as X」となる。これは常に「function(xs:integer) as item()*」の派生型であって、配列要素の、実際の型にはよらない。函数の強制型変換の規則によれば、より限定的な戻り値型の函数 (例: 「function(xs:integer) as xs:integer」) が必要な文脈でも、「instance of」演算子の意味で合致するか否かにかかわらず、任意の配列を値として与えることができる。実際に配列を (函数として) 呼び出した時、その戻り値が、必要な戻り値型のインスタンスでないときに限り、型エラーが発生する。

2.5.6 SequenceTypeの派生関係

2つのシーケンス型が与えられたとき、一方がもう一方の派生型であるか否かを判定できる。【定義: シーケンス型Aがシーケンス型B派生型 (subtype) であるのは、判定擬似函数 subtype(A, B) の結果がtrueである場合である。】 subtype(A, B) がtrueのとき、任意の値Vに対して、(V instance of A) ならば (V instance of B) が従う。

2.5.6.1 判定擬似函数 subtype(A, B)

判定擬似函数 subtype(A, B) は、シーケンス型Aがシーケンス型B派生型か否かを判定する。Aは、empty-sequence()xs:error、またはItemType (Ai) で、その後に出現数標識が続いてもよいものとする。同様にBも、empty-sequence()xs:error、またはItemType (Bi) で、その後に出現数標識が続いてもよいものとする。subtype(A, B) の判定は次の表による。この中で、補助の判定擬似函数 subtype-itemtype(Ai, Bi) (「2.5.6.2 判定擬似函数 subtype-itemtype(Ai, Bi)」で定義) を使う。

Sequence type B
empty-sequence() Bi? Bi* Bi Bi+ xs:error
Sequence type A empty-sequence() true true true false false false
Ai? false subtype-itemtype(Ai, Bi) subtype-itemtype(Ai, Bi) false false false
Ai* false false subtype-itemtype(Ai, Bi) false false false
Ai false subtype-itemtype(Ai, Bi) subtype-itemtype(Ai, Bi) subtype-itemtype(Ai, Bi) subtype-itemtype(Ai, Bi) false
Ai+ false false subtype-itemtype(Ai, Bi) false subtype-itemtype(Ai, Bi) false
xs:error true true true true true true

この表に関して、「xs:error+」は、xs:errorと同じように扱う。「xs:error?」および「xs:error*」は、empty-sequence() と同じように扱う。

2.5.6.2 判定擬似函数 subtype-itemtype(Ai, Bi)

判定擬似函数 subtype-itemtype(Ai, Bi) は、ItemType AiがItemType Bi派生型であるか否かを判定する。AiBiの派生型であるのは、次のいずれかの条件を満たす場合である:

  1. AiBiAtomicOrUnionTypesであり、derives-from(Ai, Bi)trueを返す。

  2. Aiは純共用型であり、Aiの遷移的メンバーである型tそれぞれが、subtype-itemType(t, Bi) を満たす。

  3. Aixs:errorであり、Bi一般化した原子型である。

  4. Biitem() である。

  5. Binode()AiKindTestである。

  6. Bitext()Aitext() である。

  7. Bicomment()Aicomment() である。

  8. Binamespace-node()Ainamespace-node() である。

  9. Biprocessing-instruction() であり、Aiprocessing-instruction() であるか、または任意の名前Nについてprocessing-instruction(N) である。

  10. Biprocessing-instruction(Bn)Aiprocessing-instruction(Bn) である。

  11. Bidocument-node() であり、Aidocument-node() であるか、または任意のElementTest Eについてdocument-node(E) である。

  12. Bidocument-node(Be)Aidocument-node(Ae) であり、かつsubtype-itemtype(Ae, Be) である。

  13. Bielement() またはelement(*) であり、AiElementTestである。

  14. Bielement(Bn) またはelement(Bn, xs:anyType?) であり、An展開済みQNameBn展開済みQNameに等しく、かつ、Aielement(An) であるか、または任意の型Tについてelement(An, T) またはelement(An, T?) である。

  15. Bielement(Bn, Bt) であり、An展開済みQNameBn展開済みQNameに等しく、かつ、Aielement(An, At) で、derives-from(At, Bt)trueを返す。

  16. Bielement(Bn, Bt?) であり、An展開済みQNameBn展開済みQNameに等しく、かつ、Aielement(An, At) またはelement(An, At?) で、derives-from(At, Bt)trueを返す。

  17. Bielement(*, Bt) で、Aielement(*, At) であるかまたは任意の名前Nについてelement(N, At) であり、かつ、derives-from(At, Bt)trueを返す。

  18. Bielement(*, Bt?) で、Aielement(*, At) またはelement(*, At?)、あるいは任意の名前Nについてelement(N, At) またはelement(N, At?) であり、かつ、derives-from(At, Bt)trueを返す。

  19. Bischema-element(Bn)Aischema-element(An) であり、Anの代替グループの実メンバーである要素宣言はすべて、Bnの代替グループの実メンバーでもある。

    註記:

    PQの代替グループのメンバーであっても、代替グループPの要素宣言がすべて、Qの代替グループでもあるとは限らない。たとえば、Qは、拡張により派生した型の要素による代替をブロックするが、Pはそうではない、という状況が考えられる。

  20. Biattribute() またはattribute(*) であり、AiAttributeTestである。

  21. Biattribute(Bn) またはattribute(Bn, xs:anyType) であり、An展開済みQNameBn展開済みQNameに等しく、かつ、Aiattribute(An) であるか、または任意の型Tについてattribute(An, T) である。

  22. Biattribute(Bn, Bt) であり、An展開済みQNameBn展開済みQNameに等しく、Aiattribute(An, At) であり、かつ、derives-from(At, Bt)trueを返す。

  23. Biattribute(*, Bt) であり、Aiattribute(*, At) であるか、または任意の名前Nについてattribute(N, At)であり、かつ、derives-from(At, Bt)trueを返す。

  24. Bischema-attribute(Bn) であり、An展開済みQNameBn展開済みQNameに等しく、Aischema-attribute(An) である。

  25. Bi function(*)AiFunctionTestである。

  26. Biは「function(Ba_1, Ba_2, ... Ba_N) as Br」、Aiは「function(Aa_1, Aa_2, ... Aa_M) as Ar」であって、N (Biのアリティー) がM (Aiのアリティー) に等しく、subtype(Ar, Br) であり、かつ、1からNまでの値Iについて、subtype(Ba_I, Aa_I) である。

    註記:

    函数の戻り値型は共変的、すなわち、この規則は戻り値型について、subtype(Ar, Br)を呼び出すようになっている。一方、函数の引数は反変的、すなわち、この規則は引数についてsubtype(Ba_I, Aa_I)を呼び出すようになっている。

  27. Aimap(K, V) (KVは任意)、Bimap(*)である。

  28. Aimap(Ka, Va)Bimap(Kb, Vb) であって、subtype-itemtype(Ka, Kb) およびsubtype(Va, Vb) が成り立つ。

  29. Aimap(*) (あるいは、推移律により、他の任意のマップ型)、Bifunction(*) である。

  30. Aimap(*) (あるいは、推移律により、他の任意のマップ型)、Biは「function(xs:anyAtomicType) as item()*」である。

  31. Aiarray(X)Biarray(*) である。

  32. Aiarray(X)Biarray(Y) であり、かつ、subtype(X, Y) がtrueである。

  33. Aiarray(*) (あるいは、推移律により、他の任意の配列型)、Bifunction(*) である。

  34. Aiarray(*) (あるいは、推移律により、他の任意の配列型)、Biは「function(xs:integer) as item()*」である。

  35. Aimap(K, V)Biは「function(xs:anyAtomicType) as V?」である。

  36. Aiarray(X)Biは「function(xs:integer) as X」である。

2.5.7 xs:error

xs:errorは値空間が空である。動的型として、あるいは、動的要素/属性型の内容型として現れることはない。これはXML Schemaで、型システムを完備かつ閉にするために定義されたものであり、XPath 3.1でも同様の理由で使えるようにしている。

註記:

xs:errorがインスタンスに現れることはないが、シーケンス型の正しい型名である。シーケンス型としてのxs:errorの用途は、限定的であるものの、いくつか存在する。たとえば、常に動的エラーを起こすエラー処理函数は、値を返すことがないので、戻り値型としてxs:errorはよい選択といえる。

xs:errorはメンバー型のない共用型と定義されており、この事実から、xs:errorの意味を次のように導くことができる:

  • $x instance of xs:error」は、$xの値によらず、常にfalseを返す。

  • $x cast as xs:error」は、$xの値によらず常に失敗し、動的エラー [err:FORG0001]FO31 が発生する。

  • $x cast as xs:error?」は、exists($x) であれば動的エラー [err:FORG0001]FO31 が発生し、empty($x) であれば空シーケンスが得られる。

  • xs:error($x)は「$x cast as xs:error?」と同じ意味になる (前項を参照)。

  • $x castable as xs:error」は、$xの値によらずfalseである。

  • $x treat as xs:error」を評価すると、$xの値によらず、動的エラー [err:XPDY0050] が発生する。静的に失敗することはない。

上記の例はいずれも、$xを実際に評価したと仮定している。クエリーの結果が$xの値に依存しないならば、「2.3.4 エラーと最適化」の規則により、$xの評価を回避し、エラーが発生しないよう実装してよい。

2.6 註釈

[121]    Comment    ::=    "(:" (CommentContents | Comment)* ":)" /* ws: explicit */
/* gn: comments */
[126]    CommentContents    ::=    (Char+ - (Char* ('(:' | ':)') Char*))

註釈は、式の読み手に対し、情報を提供する目的で使う。これは字句解析で扱う構造であって、式の処理には影響を与えない。

註釈は記号「(:」および「:)」で区切られた文字列である。入れ子になってもよい。

註釈は、無視してよい空白類が許される箇所であれば、どこにでも記述できる (「A.2.4.1 既定の空白類処理」を参照)。

註釈の例を次に示す:

(: Houston, we have a problem :)

3 式

この章では、基本的な各種の式についてそれぞれ説明する。式の種類ごとに、たとえばPathExprのような名前があり、その式を定義する構文規則の左辺に現れる。XPath 3.1は「組み立て」型の言語であって、各種の式は、優先度が高い演算子を持つ、他の式を使って定義するようになっている。したがって、演算子の優先度は、構文規則に明示的に表わされている。

この文書で説明する式の順序は、演算子の優先度を反映していない。一般に、簡単な式をまず取り上げ、徐々に複雑な式が現れるように配列してある。完全な構文規則は、付録 [A XPath 3.1の文法] を参照。

XPathの構文上、最上位の記号はXPathである。

[1]    XPath    ::=    Expr
[6]    Expr    ::=    ExprSingle ("," ExprSingle)*
[7]    ExprSingle    ::=    ForExpr
| LetExpr
| QuantifiedExpr
| IfExpr
| OrExpr

XPath 3.1の演算子で最も優先度が低いのはカンマ演算子で、2つのオペランドを結合してシーケンスにする働きがある。構文規則から分かるように、一般の式 (Expr) は、カンマで区切った複数のExprSingleオペランドから成る。ExprSingleという名前が示唆するように、これは最上位のカンマ演算子を含まない式である (ExprSingleという名前にもかかわらず、評価結果が複数のアイテムから成るシーケンスになることもある)。

構文規則では記号ExprSingleを、最上位のカンマが許されない式が現れる箇所で使う。たとえば、函数呼び出しの個々の引数はExprSingleである。カンマは引数どうしを区切るために使うからである。

カンマに次いで優先度の低い式は、ForExprLetExprQuantifiedExprIfExprOrExprである。これについては節を改めて説明する。

3.1 基本式

定義: 基本式 (primary expression) は言語の基本的な要素であって、リテラル、変数参照、文脈アイテム式、函数呼び出しなどがある。また、任意の式を丸括弧で囲んだものも基本式であって、演算子の優先度を制御したい場合に有用である。】 マップおよび配列の構築子については「3.11 マップと配列」で説明する。

[56]    PrimaryExpr    ::=    Literal
| VarRef
| ParenthesizedExpr
| ContextItemExpr
| FunctionCall
| FunctionItemExpr
| MapConstructor
| ArrayConstructor
| UnaryLookup
[66]    FunctionItemExpr    ::=    NamedFunctionRef | InlineFunctionExpr

3.1.1 リテラル

定義: リテラル (literal) は、原子値を直接表現する構文要素である。】 XPath 3.1には、数値リテラルと文字列リテラルの2種類がある。

[57]    Literal    ::=    NumericLiteral | StringLiteral
[58]    NumericLiteral    ::=    IntegerLiteral | DecimalLiteral | DoubleLiteral
[113]    IntegerLiteral    ::=    Digits
[114]    DecimalLiteral    ::=    ("." Digits) | (Digits "." [0-9]*) /* ws: explicit */
[115]    DoubleLiteral    ::=    (("." Digits) | (Digits ("." [0-9]*)?)) [eE] [+-]? Digits /* ws: explicit */
[116]    StringLiteral    ::=    ('"' (EscapeQuot | [^"])* '"') | ("'" (EscapeApos | [^'])* "'") /* ws: explicit */
[119]    EscapeQuot    ::=    '""'
[120]    EscapeApos    ::=    "''"
[125]    Digits    ::=    [0-9]+

数値リテラルのうち、「.」も「e」や「E」も含まないものは、xs:integer型の原子値を表す。「.」を含み、「e」や「E」を含まないものは、xs:decimal型の原子値を表す。「e」または「E」を含むものは、xs:double型の原子値を表す。数値リテラルの値は、xs:untypedAtomicから数値型へのキャスト規則 (「19.2 xs:stringおよびxs:untypedAtomicからのキャストFO31」を参照) に従い、該当する型にキャストすることにより得られる。

註記:

この規則の帰結として、整数リテラルまたは10進リテラルが、実装によって決まる範囲から外れる場合、一般に、動的エラー [err:FOAR0002]FO31 が発生する (他の選択肢もある。「4.2 数値に対する算術演算子FO31」を参照)。

XML Schemaの仕様は、整数値および10進値の大きさに、制限を設ける実装を許容している (ただし18桁未満の制限は不可)。xs:integerの組み込み派生型である、xs:longxs:unsignedLongの全範囲を扱えるのは、この制限が20桁以上の場合に限る。xs:longの最小値 (-9223372036854775808) のような負の値は、技術的にはリテラルでなく単項式であるが、このような値を表現できるように実装してもよい。

文字列リテラルの値はxs:string型の原子値であり、区切り文字 (アポストロフィーまたは引用符) の間にある文字の並びによって決まる。区切り文字がアポストロフィーの場合、リテラル中にある隣り合った2つのアポストロフィーを、単一のアポストロフィーと解釈する。同様に、区切り文字が引用符の場合、リテラル中にある隣り合った2つの引用符を、単一の引用符と解釈する。

リテラル式の例をいくつか示す:

  • "12.5"」は、文字'1'、'2'、'.'、'5'から成る文字列を表す。

  • 12」はxs:integer型の値12を表す。

  • 12.5」はxs:decimal型の値12.5を表す。

  • 125E2」はxs:double型の値12500を表す。

  • "He said, ""I don't like it."""」は文字列を表す。ここには引用符が2つ、アポストロフィーが1つ含まれている。

    註記:

    XPathの式を、XMLの属性内など、引用符に特別な意味がある文脈に埋め込む場合、さらにエスケープ処理が必要になることがある。

xs:boolean値であるtruefalseは、組み込み函数 fn:true() およびfn:false() をそれぞれ呼び出すことにより構築できる。

他の単純型の値は、その型の構築子函数を使って構築できる。XML Schemaの組み込み型に対応する構築子函数は、「18.1 XML Schemaの組み込み原子型の構築子函数FO31」に定義されている。一般に、ある型の構築子函数の名前は、その型の (名前空間を含む) 名前と同じである。以下にいくつか例を示す:

  • xs:integer("12")」は整数値12を返す。

  • xs:date("2001-08-25")」は、型がxs:dateで、値が2001年8月25日を表すアイテムを返す。

  • xs:dayTimeDuration("PT5H")」は、型がxs:dayTimeDurationで、値が5時間という継続期間を表すアイテムを返す。

構築子函数は、リテラル表現がない、特別な値を生成するために使うこともできる。その例をいくつか示す:

  • xs:float("NaN")」は、特別な浮動小数点数値である「非数」を返す。

  • xs:double("INF")」は、特別な倍精度浮動小数点数値である「正の無限大」を返す。

構築子函数は、共用型を含む、単純型すべてについて用意されている。たとえば、my:dtがユーザー定義の共用型で、そのメンバー型がxs:datexs:timexs:dateTimeである場合、式「my:dt("2011-01-10")」は、xs:date型の原子値を生成する。そのための規則は、共用型に関するXML Schemaの検証規則に準じている。すなわち、与えられた文字列をその字句空間内で受理できる、最初のメンバー型を選ぶのである。

各種の型の値は、cast式で構築することもできる。その例を示す:

  • 9 cast as hatsize」は、型がhatsizeである原子値9を返す。

3.1.2 変数参照

[59]    VarRef    ::=    "$" VarName
[60]    VarName    ::=    EQName

定義: 変数参照 (variable reference) は、EQNameの前に「$」記号を置いたものである。】 接頭辞なしの変数参照は、名前空間がない。2つの変数参照を同等と看做すのは、その展開済みQNameが (eq演算子の意味で) 等しい場合である。変数束縛のスコープは、変数を束縛できる式の種類ごとに定義する。

変数参照はすべて、スコープ内変数にある、いずれかの名前と合致しなければならない。

変数束縛にはすべて静的スコープがある。スコープは、変数に対する参照が現れうる位置を規定する。スコープ内にない変数を参照しようとすると、静的エラー [err:XPST0008] が発生する。変数が式の静的文脈内で束縛されている場合、その変数は式全体のスコープ内にある。ただし、当該スコープ内に、同じ名前を使う他の束縛があるため、不可視になる場合を除く。

評価時における変数参照の値は、当該変数が束縛されている値である。

3.1.3 括弧式

[61]    ParenthesizedExpr    ::=    "(" Expr? ")"

丸括弧を使って優先度の規則を変更できる。たとえば、式「(2 + 4) * 5」を評価すると30になる。括弧で囲まれた式 (2 + 4) をまず評価し、その結果に5を掛けるからである。一方、括弧がない式「2 + 4 * 5」を評価すると22になる。乗算演算子が加算演算子に優先するからである。

丸括弧で囲まれた中身が空であれば、空シーケンスを表す (「3.4.1 シーケンスの組み立て」を参照)。

3.1.4 文脈アイテム式

[62]    ContextItemExpr    ::=    "."

文脈アイテム式を評価すると文脈アイテムが得られる。これは、ノードである場合 (例: fn:doc("bib.xml")/books/book[fn:count(./author)>1]) と、原子値や函数である場合 (例: (1 to 100)[. mod 5 eq 0]) がある。

文脈アイテム欠落DM31している場合、文脈アイテム式を評価すると動的エラー [err:XPDY0002] が発生する。

3.1.5 静的函数呼び出し

定義: 組み込み函数 (built-in functions) とは、[XQuery and XPath Functions and Operators 3.1] で、http://www.w3.org/2005/xpath-functionshttp://www.w3.org/2001/XMLSchemahttp://www.w3.org/2005/xpath-functions/mathhttp://www.w3.org/2005/xpath-functions/maphttp://www.w3.org/2005/xpath-functions/arrayの各名前空間に定義している函数である。】 組み込み函数の集合はホスト言語が指定する。静的文脈に函数を追加してもよい。XPath自体には、名前つき函数を宣言する手段がないが、ホスト言語にそのような機構を組み込んでもよい。

[63]    FunctionCall    ::=    EQName ArgumentList /* xgc: reserved-function-names */
/* gn: parens */
[50]    ArgumentList    ::=    "(" (Argument ("," Argument)*)? ")"
[64]    Argument    ::=    ExprSingle | ArgumentPlaceholder
[65]    ArgumentPlaceholder    ::=    "?"

定義: 静的函数呼び出し (static function call) は、EQNameの後に、0個以上の引数のリストを括弧で囲んで記述した形をしている。】 【定義: 函数呼び出しの引数は、引数式 (argument expression) またはArgumentPlaceholder ("?") である。】 静的函数呼び出しのEQNameが、名前空間接頭辞なしの字句規則上のQNameであれば、既定の函数名前空間に属するものと看做す。

静的函数呼び出しの展開済みQNameと引数の個数が、静的文脈における函数シグニチャーの名前とアリティーに合致していない場合、静的エラー [err:XPST0017] が発生する。

定義: 静的または動的函数呼び出しが部分函数適用 (partial function application) であるのは、引数のいくつかがArgumentPlaceholderである場合である。】

函数呼び出しの評価については、「3.1.5.1 静的および動的函数呼び出しの評価」で説明する。

函数呼び出しの引数はカンマで区切ることになっているので、最上位にカンマ演算子を含む引数式は、括弧で囲む必要がある。静的函数呼び出しの具体的な例をいくつか示す:

  • my:three-argument-function(1, 2, 3) は3引数の静的函数呼び出しを表す。

  • my:two-argument-function((1, 2), 3) は2引数の静的函数呼び出しを表す。第1引数は2つの値から成るシーケンスである。

  • my:two-argument-function(1, ()) は2引数の静的函数呼び出しを表す。第2引数は空シーケンスである。

  • my:one-argument-function((1, 2, 3)) は1引数の静的函数呼び出しを表す。引数は3つの値から成るシーケンスである。

  • my:one-argument-function(( )) は1引数の静的函数呼び出しを表す。引数は空シーケンスである。

  • my:zero-argument-function( ) は0引数の静的函数呼び出しを表す。

3.1.5.1 静的および動的函数呼び出しの評価

静的または動的な函数呼び出しFCを、静的文脈SC、動的文脈DCのもとで評価する場合、次のようにして結果を得ることになる:

  1. 定義: ArgumentListに含まれるArgumentの個数をアリティー (arity) という。】

  2. 呼び出しまたは部分適用の対象である函数Fを、次のようにして取得する:

    1. FCが静的函数呼び出しである場合: FCEQNameに対応する展開済みQNameと、FCArgumentListのアリティーにもとづき、該当する函数を、DC名前つき函数の中から検索する。見つかった函数を、以下、Fで表す。

    2. FCが動的函数呼び出しである場合: FCの基底である式を、SCおよびDCのもとで評価する。その結果、単一の函数から成るシーケンスが得られ、そのアリティーがArgumentListのアリティーと同じであれば、この函数を、以下、Fで表す。そうでなければ型エラー [err:XPTY0004] が発生する。

  3. 定義: 引数式DCのもとで評価して得られる値を、引数値 (argument values) という。】 引数を評価する順序は実装依存である。ある引数を評価しなくても函数の本体を評価できるのであれば、当該引数は評価しなくてもよい。

  4. 引数値をそれぞれ、Fのシグニチャーにおける、対応するパラメーター型に変換し、変換済み引数値を得る。この変換は、函数の変換規則を適用しておこなう。

  5. 以降の処理は、FC部分函数適用か否かによって異なる。

    1. FC部分函数適用である場合、函数呼び出しの結果として得られるのは、部分適用済み函数という新しい函数である。【定義: 部分適用済み函数 (partially applied function) とは、部分函数適用の結果として生成される函数である。】 【定義: 部分函数適用で、固定位置 (fixed position) とは、ArgumentListの中で (ArgumentPlaceholderではなく) 引数式が現れる引数/パラメーター位置のことである。】 部分函数適用に、固定位置がないこともありうる。部分適用済み函数には次のような特性がある (「2.8.1 函数DM31」で定義):

      • 名前: 欠落。

      • パラメーター名: Fのパラメーター名のうち、固定位置のそれを除いたもの (したがってこの函数のアリティーは、Fのアリティーから固定位置の個数を引いた値になる)。

      • シグニチャー: Fのシグニチャーのうち、固定位置に当たるパラメーター型を除去したもの。(たとえば型解析により) さらに限定的なシグニチャーを求めることができる実装であれば、そうしてもよい。

      • 実装: Fの実装。これがXPath 3.1の式でなければ、新しい函数の実装に、次のいずれかの方法で、静的文脈および動的文脈を関連づける: Fの実装が既にある文脈に関連づけられていれば、その文脈を用いる。そうでなければSCDCを使う。

      • 非ローカル変数束縛: Fの非ローカル変数束縛に、固定位置それぞれについて、変換済み引数値の対応するパラメーター名に対する束縛を追加したもの。

      例: 匿名函数の部分適用

      次の例で、$fは匿名函数、$paf$fから生成した部分適用済み函数である。

      let $f := function ($seq, $delim) { fn:fold-left($seq, "", fn:concat(?, $delim, ?)) },
          $paf := $f(?, ".")
      return $paf(1 to 5)
      

      $pafも匿名函数である。$delim (訳註: $seqの誤り?) というパラメーターが1つあり、これは$fの対応するパラメーターから取ったものである (他のパラメーターは固定)。$pafの実装は、$fの実装、すなわち「fn:fold-left($seq, "", fn:concat(?, $delim, ?))」である。この実装は、$fにおける元の式のSCおよびDCに関連づけられている。非ローカル変数束縛が、値 "." をパラメーター$delimに対応づける。

      例: 組み込み函数の部分適用

      次の部分函数適用により、シーケンスの平方和を計算する函数が得られる。

      let $sum-of-squares := fn:fold-right(?, 0, function($a, $b) { $a*$a + $b })
      return $sum-of-squares(1 to 3)

      $sum-of-squaresは匿名函数である。$seqというパラメーターが1つあり、これはfn:fold-rightの対応するパラメーターから取ったものである (他の2つのパラメーターは固定)。実装は、組み込みの文脈非依存函数である、fn:fold-rightの実装である。非ローカル変数束縛として、fn:fold-rightの第2パラメーター、第3パラメーターに対応する、固定の変数束縛がある。

      部分函数適用がマップや配列を返すことはない。$Fがマップまたは配列であれば、$F(?)は部分函数適用で函数を返すが、この函数自体はマップでも配列でもない。

      例: マップの部分適用

      次の部分函数適用は、マップを同等の函数に変換する。この函数自体は、マップではない。

      let $a := map {"A": 1, "B": 2}(?)
      return $a("A")
    2. FCが部分函数適用でない場合、呼び出しの意味は、函数Fの「実装」特性による (「2.8.1 函数DM31」を参照):

      註記:

      XPath 3.1はデータ・モデルに関してホスト言語である。XPath 3.1で、実装がホスト言語式であれば、これはXPath 3.1の式である。

      1. Fがマップである場合の評価方法は「3.11.1.2 函数呼び出し構文によるマップの検索」で説明する。Fが配列である場合の評価方法は「3.11.2.2 函数呼び出し構文による配列の検索」で説明する。

      2. Fの実装がXPath 3.1の式 (たとえば、F匿名函数、あるいはその部分適用) である場合:

        1. Fの実装を評価する。この評価に用いる静的文脈は、XPath 3.1の式の静的文脈である。この評価に用いる動的文脈は、FunctionBodyを含むInlineFunctionExprの動的文脈に対し、次の変更を施すことにより得られる:

          • フォーカス (文脈アイテム、文脈位置、文脈の大きさ) は欠落DM31

          • 動的文脈の変数値コンポーネントで、変換済み引数値に、対応するパラメーター名を束縛する。

            その結果、変換済み引数値は、最も限定された動的型になる。この型が、仮パラメーターの型から派生したものであっても、これは成り立つ。たとえば、ある函数のパラメーター$pxs:decimal型である場合、その派生型であるxs:integer型の引数を渡して呼び出すことができる。この函数呼び出しの処理では、函数本体中に現れる$p動的型xs:integerと看做すことになる。

          • Fの非ローカル変数束縛も、変数値に追加する (非ローカル変数の名前は、定義により、パラメーター名と重複しないので、衝突することはない)。

        2. 函数本体を評価して得られた値に函数の変換規則を適用して、Fに宣言された戻り値型に変換する。その結果が、FCを評価した結果になる。

          引数値と同様、函数の戻り値も、その最も限定された型になる。この型は、Fに宣言された戻り値型の派生型であってもよい。たとえば、戻り値型をxs:decimalと宣言している函数が、実際には動的型がxs:integerである値を返すこともありうる。

        例: 派生型と非ローカル変数束縛

        $incrは非ローカル変数で、函数内からアクセスできる。その変数束縛を、函数の変数値に追加したからである。この函数のパラメーター型と戻り値型はどちらもxs:decimalであるが、実際にはより限定された型であるxs:integerになっている。

        let $incr := 1,
            $f := function ($i as xs:decimal) as xs:decimal { $i + $incr }
        return $f(5)                      
        例: 匿名函数で文脈アイテムを使用

        次の例を実行すると、動的エラー [err:XPDY0002] が発生する:

        let $vat := function() { @vat + @price }
        return shop/article/$vat()

        代わりに、文脈アイテムを引数として、匿名函数に渡すようにするとよい:

        let $vat := function($art) { $art/@vat + $art/@price }
        return shop/article/$vat(.)

        あるいは、非ローカル変数束縛として値を参照する、という方法もある:

        let $ctx := shop/article,
        $vat := function() { for $a in $ctx return $a/@vat + $a/@price }
        return $vat()
        
      3. Fの実装がXPath 3.1の式でない (たとえば、F組み込み函数ホスト言語の函数、あるいはその部分適用) 場合:

        • Fの実装を、実装依存の方法で起動する。その際、処理系は、次の情報を参照できるようにする:

          • 変換済みの引数値;

          • Fの非ローカル変数束縛;

          • 静的文脈および動的文脈。Fの実装が、静的文脈や動的文脈に関連づけられていればそれを適用する。そうでなければSCDCを使う。

          上記の情報を使う方法は実装定義である。外部函数を起動するAPIは、静的文脈および動的文脈をどのようにして函数に渡すか、明示する必要がある。[XQuery and XPath Functions and Operators 3.1] では、定義している函数それぞれについて、静的文脈や動的文脈をどのように使うか明示している。ホスト言語は、静的文脈や動的文脈を、提供する函数がどのように使うか明示する必要がある。

        • 結果は、Fの戻り値型のインスタンスか、または動的エラーである。この結果が、FCを評価した結果になる。

        • 組み込み函数で発生するエラーについては、[XQuery and XPath Functions and Operators 3.1] で定義している。

        • ホスト言語依存の函数で発生するエラーは実装定義である。

        例: 組み込み函数

        次の函数呼び出しは、「2.5 fn:base-uriFO31」の函数を呼び出している。SCDCの使い方、発生しうるエラーについては、すべて [XQuery and XPath Functions and Operators 3.1] に定義がある。

        fn:base-uri()
3.1.5.2 函数の変換規則

定義: 函数の変換規則 (function conversion rules) は、引数値を想定する型 (函数パラメーターの型として宣言された型) に変換するために使う。】 想定する型はシーケンス型として表す。函数の変換規則を、次のように、与えられた値に適用する:

  • 静的函数呼び出しで、XPath 1.0互換モードtrueであり、静的函数の引数が想定する型でない場合、引数値Vに対して順次、次の変換を施す:

    1. 想定する型が、単一のアイテム (空であってもよい場合を含む) を指す場合 (例: xs:stringxs:string?xs:untypedAtomicxs:untypedAtomic?node()node()?item()item()?)、V[1] (訳註: シーケンスの先頭要素) でVを置き換える。

    2. 想定する型がxs:stringまたはxs:string?であれば、fn:string(V) で値Vを置き換える。

    3. 想定する型がxs:doubleまたはxs:double?であれば、fn:number(V) で値Vを置き換える。

    註記:

    fn:for-eachやfn:filterといった函数を評価する際、動的函数呼び出し、インライン函数の結果から要求される型への変換、部分函数適用、暗黙の函数呼び出しが起こっても、XPath 1.0互換モードのいかんによる違いはない。

  • 想定する型が一般化した原子型のシーケンス (あるいはこれに出現数標識*+?がついた形) である場合、次の変換を施す:

    1. 与えられた値に原子化を施して、原子値のシーケンスを得る。

    2. 原子値のシーケンスの各アイテムがxs:untypedAtomic型であれば、想定する一般化した原子型にキャストする。アイテムがxs:untypedAtomic型で、想定する型が名前空間に依存する型であれば、型エラー [err:XPTY0117] が発生する。

    3. 原子値のシーケンスの各アイテムが数値型で、「B.1 型の昇格」に示す数値昇格規則により、想定する原子型に昇格できるものは、昇格する。

    4. 原子値のシーケンスの各アイテムがxs:anyURI型で、「B.1 型の昇格」に示すURI昇格規則により、想定する原子型に昇格できるものは、昇格する。

  • 想定する型がTypedFunctionTest (あるいはこれに出現数標識*+?がついた形) である場合、与えられた値の各函数に対し、函数の強制型変換を施す。

    註記:

    XPath 3.1ではマップや配列も函数なので、同様に函数の強制型変換を施す。

  • 上記の変換を施した後、SequenceTypeの照合の規則に照らして、結果の値が想定する型に合致しない場合、型エラー [err:XPTY0004] になる。なお、SequenceTypeの照合の規則によれば、派生型の値を基底型の値で置き換えることは許容される。

3.1.5.3 函数の強制型変換

函数の強制型変換は、函数の変換規則を適用する際、函数DM31に施す変換のひとつである。【定義: 函数の強制型変換 (function coercion) では、函数DM31を、シグニチャーが想定する型に一致する、新しい函数でラップする。これは実質的に、引数および戻り値の型検査を、函数の起動時まで遅延させることに相当する。】

函数の強制型変換は、函数DM31に対する操作のみが定義されている。函数Fと、想定する函数型が与えられたとき、函数の強制型変換を次のように実施する: Fと想定する函数型のアリティーが異なる場合は型エラー [err:XPTY0004] である。そうでなければ、次のような特性の新しい函数を返す (「2.8.1 函数DM31」を参照):

  • 名前: Fの名前。

  • パラメーター名: Fのパラメーター名。

  • シグニチャー: AnnotationsにはFの型註釈と同じものを設定。TypedFunctionTestには想定する型を設定。

  • 実装: 実質的に、この新しい函数のパラメーターを、その順序どおりに渡してFを呼び出す、という形のFunctionBody

  • 非ローカル変数束縛: 空のマッピング。

新しい函数を起動した結果、必然的に型エラーが発生するとすれば、これは函数の強制型変換で起こっていることになる。実際に起こるか否かは実装依存である。

以上の規則の帰結として、次のようになる:

  • 函数の引数および戻り値のSequenceTypeを照合する処理は、当該函数の起動時まで遅延される。

  • 函数の引数および戻り値に適用する変換規則は、直近に強制型変換を施したSequenceTypeによって定義される。ラップされた函数の起動時に、追加で強制型変換規則を適用することもありうる。

  • 函数に関する静的型情報を用いる実装であれば、静的解析フェーズでこれを利用し、函数の引数および戻り値の型を検査できる。

註記:

函数の強制型変換の意味を、函数のラップという形で指定しているが、実際にこれが必要な箇所は、静的型づけにより減らせることが多い。

XPath 3.1ではマップや配列も函数なので、同様に函数の強制型変換を適用する。たとえば次の式を考えてみよう:

let $m := map {
  "Monday" : true(),
  "Wednesday" : true(),
  "Friday" : true(),
  "Saturday" : false(),
  "Sunday" : false()
},
$days := ("Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday")
return fn:filter($days,$m)
      

函数$mのシグニチャーは function(xs:anyAtomicType) as item()* である。fn:filter() 函数を呼び出すと、マップに対して次のようなことが起こる:

  1. マップ$mを、map:get($m,?) と同等の、function ($f) として扱う。

  2. 函数の強制型変換規則に従い、函数の強制型変換を$fに適用する。そのために、function(item()) as xs:booleanというシグニチャーの新しい函数 ($p) で、$fをラップする。

  3. $pを、function(item()) as xs:booleanというSequenceTypeと照合し、これは成功する。

  4. fn:filter()$pを起動する。函数変換規則およびSequenceTypeの照合規則を引数に適用する結果、item() の値 ($a) が得られるか、または型エラーが発生する。

  5. $aを渡して$fを起動する。その結果、xs:boolean型の戻り値、または空シーケンスが得られる。

  6. $pは函数の変換規則およびSequenceTypeの照合規則を、$fから結果として得られたシーケンスに適用する。結果がxs:booleanであれば、SequenceTypeの照合は成功する。空シーケンスであれば ($mにない、"Tuesday" というキーを渡した場合など)、SequenceTypeの照合の結果、型エラー [err:XPTY0004] が発生する。想定する型はxs:booleanであるが、実際には空シーケンスだからである。

次の式を考えてみよう:

let $m := map {
"Monday" : true(),
"Tuesday" : false(),
"Wednesday" : true(),
"Thursday" : false(),
"Friday" : true(),
"Saturday" : false(),
"Sunday" : false()
}
let $days := ("Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday")
return fn:filter($days,$m)
      

この式の結果は、シーケンス ("Monday", "Wednesday", "Friday") になる。

3.1.6 名前つき函数参照

[67]    NamedFunctionRef    ::=    EQName "#" IntegerLiteral /* xgc: reserved-function-names */
[112]    EQName    ::=    QName | URIQualifiedName

定義: 名前つき函数参照 (named function reference) とは、評価すると名前つき函数が得られる式である。得られた函数の名前とアリティーは静的に既知であり、静的文脈にある函数のシグニチャーに対応している。函数が文脈依存であれば、この函数には、名前つき函数参照の静的文脈と、これを評価する動的文脈が関連づけられている。】 【定義: 名前つき函数 (named function) は、式の静的文脈に定義された函数である。特定の名前つき函数を一意に識別するためには、展開済みQNameで表した名前と、アリティーの両方が必要である。】

EQNameが字句規則上のQNameで、名前空間接頭辞がない場合、既定の函数名前空間にあるものと看做す。

名前つき函数参照の展開済みQNameとアリティーが、静的文脈における函数シグニチャーの名前およびアリティーと合致しない場合、静的エラー [err:XPST0017] が発生する。

NamedFunctionRefの値は、展開済みQNameとアリティーを指定し、動的文脈の名前つき函数コンポーネントで検索して得た函数である。

さらに、NamedFunctionRefを評価して得た函数の実装が実装依存であれば、この函数の実装は、このNamedFunctionRef式の静的文脈と、NamedFunctionRefを評価した動的文脈に関連づけられている。

名前つき函数参照の例をいくつか示す:

  • fn:abs#1は、引数を1つ取るfn:abs函数を参照する。

  • fn:concat#5は、引数を5つとるfn:concat函数を参照する。

  • local:myfunc#2は、引数を2つ取る、local:myfuncという函数を参照する。

3.1.7 インライン函数式

[68]    InlineFunctionExpr    ::=    "function" "(" ParamList? ")" ("as" SequenceType)? FunctionBody
[2]    ParamList    ::=    Param ("," Param)*
[3]    Param    ::=    "$" EQName TypeDeclaration?
[78]    TypeDeclaration    ::=    "as" SequenceType
[4]    FunctionBody    ::=    EnclosedExpr

定義: インライン函数式 (inline function expression) は、インライン函数式で直接定義された、匿名函数を生成する。】 インライン函数式は、名前、函数に渡すパラメーターのSequenceTypes、結果のSequenceType、函数の本体を指定する。【定義: 匿名函数 (anonymous function) とは、名前のない函数である。匿名函数は、たとえば、インライン函数式を評価し、あるいは部分函数適用を施すことにより生成する。】

函数パラメーターの宣言が名前だけで、型の指定がない場合に用いる、既定の型はitem()* である。戻り値型の指定がない場合に用いる、既定の戻り値型はitem()* である。

インライン函数式のパラメーターを、函数本体をスコープとする変数と看做す。同じ名前のパラメーターが複数ある場合、静的エラー [err:XQST0039] が発生する。

函数本体の静的文脈は、インライン函数式の場所から継承する。ただし例外として、文脈アイテムの静的型は当初、欠落DM31している。

函数本体のスコープ内の変数には、函数パラメーターを表す変数と、インライン函数式のスコープ内にある変数がある。

註記:

函数本体のスコープ内にある変数は、函数パラメーターの名前と衝突し、不可視になることがある。

インライン函数式の結果として得られるのは単一の函数で、次のような特性がある (「2.8.1 函数DM31」に定義):

  • 名前: 欠落。

  • パラメーター名: InlineFunctionExprParamListに指定されている名前。

  • シグニチャー: InlineFunctionExprSequenceTypeから構築したFunctionTest。(たとえば型解析により) さらに限定的なシグニチャーを求めることができる実装であれば、そうしてもよい。

  • 実装: InlineFunctionExprFunctionBody

  • 非ローカル変数束縛: 非ローカル変数それぞれについて、InlineFunctionExprの動的文脈の変数値コンポーネントにおける値に束縛したもの。

インライン函数式の例をいくつか示す:

  • この例は、引数を取らず、最初の6つの素数から成るシーケンスを返す函数を生成する:

    function() as xs:integer+ { 2, 3, 5, 7, 11, 13 }
  • この例は、xs:double型の2つの引数を取り、その積を返す函数を生成する:

    function($a as xs:double, $b as xs:double) as xs:double { $a * $b }
  • この例は、item()*型の引数をそのまま返す函数を生成する:

    function($a) { $a }
  • この例は、函数のシーケンスを生成する。それぞれの函数は、既定のコレクションから、異なるアイテムを返す:

    collection()/(let $a := . return function() { $a })

3.1.8 波括弧式

[5]    EnclosedExpr    ::=    "{" Expr? "}"

定義: 波括弧式 (enclosed expression) はEnclosedExprの構文に従う式で、波括弧で囲った中に式を置くことができる。】 【定義: 波括弧式において、波括弧で囲まれた式 (空でもよい) を、内容式 (content expression) という。】 内容式を明示的に与えない場合、内容式は () になる。

3.2 後置式

[49]    PostfixExpr    ::=    PrimaryExpr (Predicate | ArgumentList | Lookup)*
[52]    Predicate    ::=    "[" Expr "]"
[50]    ArgumentList    ::=    "(" (Argument ("," Argument)*)? ")"

定義: 式の後に述語を置いたもの (すなわち、E1[E2]) をしぼり込み式 (filter expression) という。E1の値から、E2の述語を満たすアイテムを選んで返す、という働きがある。】 しぼり込み式については「3.2.1 しぼり込み式」で説明する。

式 (生のEQNameを除く) の後に、丸括弧で囲んだ引数リストを置いたもの (すなわち、E1(E2, E3, ...)) を、動的函数呼び出し (dynamic function call) という。E1を評価して函数を得、E2E3...を引数としてこの函数を呼び出す、という働きがある。動的函数呼び出しについては「3.2.2 動的函数呼び出し」で説明する。

3.2.1 しぼり込み式

[49]    PostfixExpr    ::=    PrimaryExpr (Predicate | ArgumentList | Lookup)*
[52]    Predicate    ::=    "[" Expr "]"

しぼり込み式は、基礎となる式の後に述語を置いた形をしている。述語は、角括弧で囲んで記述した式である。基礎となる式の戻り値のアイテムそれぞれについて、述語を適用してしぼり込んだものが、しぼり込み式の結果になる。しぼり込み式が返すアイテムの順序は、基礎となる式の結果の順序と同じである。

註記:

角括弧の前にある式がReverseStepまたはForwardStepである場合、技術的には、しぼり込み式ではなくAxisStepであって、意味に多少の違いがある。「3.3.3 ステップ内の述語」を参照。

しぼり込み式の例をいくつか示す:

  • 変数を介して製品 (products) のシーケンスを受け取り、価格が100よりも高いものを返す。

    $products[price gt 100]
  • 1から100までの整数のうち、5で割り切れるもののリストを返す (to演算子については「3.4.1 シーケンスの組み立て」を参照)。

    (1 to 100)[. mod 5 eq 0]
  • 次の式の結果は整数25になる:

    (21 to 29)[5]
  • 次の例は、変数$ordersのうち、5番目から9番目のアイテムを返す。

    $orders[fn:position() = (5 to 9)]
  • 次の例では、しぼり込み式をパス式ステップとして使っている。変数$bookに束縛された書籍の章および付録のうち、最後のものを返す:

    $book/(chapter | appendix)[fn:last()]

入力シーケンスの各アイテムについて、内部フォーカスを使って述語式を評価する。これを次のように定義する: 文脈アイテムは、述語の対象としてテストしようとしているアイテムである。文脈の大きさは、入力シーケンス中のアイテムの数である。文脈位置は、入力シーケンスにおける、文脈アイテムの位置である。

入力シーケンスの各アイテムについて、述語式の結果をxs:boolean値に型強制する。これを述語真理値という (具体的な求め方については、次の段落を参照)。述語真理値がtrueであるアイテムはそのまま保存し、falseであるアイテムは破棄する。

述語真理値は、以下の規則を順に適用して求める:

  1. しぼり込み式の値が、numeric型またはその派生型である原子値のシングルトンの場合、述語真理値がtrueになるのは、述語式の値が (eq演算子の意味で) 文脈位置に等しい場合であり、そうでなければfalseになる。

  2. そうでなければ、述語真理値は、述語式の実効ブール値である。

3.2.2 動的函数呼び出し

[49]    PostfixExpr    ::=    PrimaryExpr (Predicate | ArgumentList | Lookup)*
[50]    ArgumentList    ::=    "(" (Argument ("," Argument)*)? ")"
[64]    Argument    ::=    ExprSingle | ArgumentPlaceholder
[65]    ArgumentPlaceholder    ::=    "?"

定義: 動的函数呼び出し (dynamic function call) は、基礎となる式 (函数を返す式) と、0個以上の引数 (引数式またはArgumentPlaceholder) のリストを丸括弧で囲んだものから成る。】

動的函数呼び出しは、「3.1.5.1 静的および動的函数呼び出しの評価」に説明しているとおりに評価する。

動的函数呼び出しの例をいくつか示す:

  • この例は、$fの値である函数を、引数2および3を渡して呼び出す:

    $f(2, 3)
  • この例は、シーケンス$fの2番目のアイテムを取り出し、これを函数として、xs:string型の引数を渡して呼び出す:

    $f[2]("Hi there")
  • この例は、引数なしで函数$fを呼び出し、その結果を位置の述語でしぼり込む:

    $f()[2]

3.3 パス式

[36]    PathExpr    ::=    ("/" RelativePathExpr?)
| ("//" RelativePathExpr)
| RelativePathExpr
/* xgc: leading-lone-slash */
[37]    RelativePathExpr    ::=    StepExpr (("/" | "//") StepExpr)*

定義: パス式 (path expression) を使って、XML木の中から、あるノードを見つけることができる。パス式は、1つ以上のステップを、「/」または「//」で区切った形をしている。このほか、先頭に「/」または「//」があってもよい。】 先頭の「/」や「//」は、パス式の先頭に当たるステップの省略表記である (下記参照)。

単一のステップから成るパス式の評価方法については、「3.3.2 ステップ」で説明する。

パス式の先頭にある「/」は、先頭ステップ「(fn:root(self::node()) treat as document-node())/」の省略形である (ただし、パス式全体が「/」だけであれば、省略形を展開した後、末尾の「/」を省く)。この先頭ステップには、文脈ノードが属する木のルート・ノードから、パスを始めるようにする働きがある。文脈アイテムがノードでなければ、型エラー [err:XPTY0020] が発生する。評価時に、文脈ノードのルート・ノードが文書ノードでなければ、動的エラー [err:XPDY0050] が発生する。

パス式の先頭にある「//」は、先頭ステップ「(fn:root(self::node()) treat as document-node())/descendant-or-self::node()/」の省略形である (ただし、「//」自体は有効なパス式でない [err:XPST0003])。この先頭ステップには、文脈ノードが属する木のルート・ノードと、その子孫ノードすべてから成るシーケンスを作り出す働きがある。このノード・シーケンスを、後続のステップに渡すことになる。文脈アイテムがノードでなければ、型エラー [err:XPTY0020] が発生する。評価時に、文脈ノードのルート・ノードが文書ノードでなければ、動的エラー [err:XPDY0050] が発生する。

註記:

ノードの子孫に、属性ノードや名前空間ノードは含まれない。

先頭が「/」または「//」であるパス式は、文脈アイテムが属する木のルートから探索が始まる。これを絶対パス式と呼ぶのが通例である。

3.3.1 相対パス式

[37]    RelativePathExpr    ::=    StepExpr (("/" | "//") StepExpr)*

相対パス式は、文脈ノード (絶対パス式と違い、木に属するどのノードでもよい) から出発して、一連のステップを追うことにより、木に属するノード群を選択するパス式である。

パス式の先頭以外に現れる「//」を、「3.3.5 省略構文」で説明するように展開して、「/」で区切られた一連のステップを得る。この一連のステップを、左から右に評価する。したがって、たとえば「E1/E2/E3/E4」という形のパスは、「((E1/E2)/E3)/E4」として評価することになる。このように、パス式の意味を、二項の「/」演算子を使って定義する (「3.3.1.1 パス演算子 (/)」を参照)。

註記:

3ステップ以上のパスは左から右に評価することになるが、「/」演算子はほとんどの場合結合的であって、右から左に評価しても通常は同じ結果になる。「/」が結合的でない状況として、函数fn:position()fn:last() を使っている場合がある。「A/B/position()」は、1から (A/B) の大きさまでの、整数のシーケンスを返す。一方、「A/(B/position())」は、Bの要素ごとに1から数え直して作ったシーケンスになる。

相対パス式の使用例を以下に示す。

  • child::div1/child::para

    文脈ノードの子要素div1の子要素paraを返す。言い替えると、文脈ノードの孫ノードparaのうち、親がdiv1ノードであるものである。

註記:

パスの各ステップは、後続のステップに対する文脈ノードを返す。したがって、ノード以外のシーケンスを返してもよいのは、パスの最終ステップに限る。

註記:

/」という文字は、完結したパス式としても、「/*」のようにもっと長いパス式の先頭としても使える。さらに「*」は、乗算演算子としても、パス式のワイルドカードとしても使える。そのため、「*」の左側に「/」が現れた場合、構文解析に曖昧さが生じる。これを解決するため、leading-lone-slash制約を導入する。たとえば、「/*」や「/ *」は、ワイルドカードを含む有効なパス式であるが、「/*5」や「/ * 5」は構文エラーになる。演算子の左辺に「/」を使う場合は、「(/) * 5」のように括弧を使わなければならない。同様に、「4 + / * 5」は構文エラーであるが、「4 + (/) * 5」は有効な式である。式「4 + /」も、「/」が演算子の左辺に現れるのではないから有効である。

同様に、式「/ union /*」において、「union」は演算子でなく要素名と解釈する。演算子として扱いたければ「(/) union /*」と書かなければならない。

3.3.1.1 パス演算子 (/)

パス演算子「/」は、木の中でノードを見つける式を構築するために使う。左辺の式は、ノードのシーケンスを返すものでなければならない。演算子は、ノードのシーケンス、またはノード以外のシーケンスを返し、前者の場合、ノードを文書順に整列し、重複を除去する処理も施す。

各演算E1/E2は次のように評価する: まず、式E1を評価する。結果がノードのシーケンスS (あるいは空シーケンス) でなければ型エラー [err:XPTY0019] になる。Sの各ノードについて、当該ノードを内部フォーカスに与え (文脈アイテムとして当該ノード、文脈位置としてそのSにおける位置、文脈の長さとしてSの長さ)、「2.1.2 動的文脈」に説明しているようにE2を評価する。E2を評価して得られるシーケンスをすべて、次のようにして合成する:

  1. E2の評価結果がすべてノードのシーケンス (空であっても可) であれば、そのシーケンスをすべて組み合わせ、ノードのIDをもとに重複を除去する。このノード・シーケンスを文書順に整列し、結果として返す。

  2. E2の評価結果がすべてノード以外のシーケンス (空であっても可) であれば、そのシーケンスをすべて、順に連結して返す。E2の評価により生成された副シーケンス内では、ノードの順序をそのまま保存する。

  3. E2の評価結果にノードとノード以外が混在している場合、型エラー [err:XPTY0018] が発生する。

註記:

パス演算子の意味は、単純マップ演算子を使って次のように定義することもできる (空シーケンスとの合併演算 ($R | ()) には、重複を除去し、文書順に整列するという効果がある):

E1/E2 ::= let $R := E1!E2
  return
    if (every $r in $R satisfies $r instance of node())
    then ($R|())
    else if (every $r in $R satisfies not($r instance of node()))
    then $R
    else error()

3.3.2 ステップ

[38]    StepExpr    ::=    PostfixExpr | AxisStep
[39]    AxisStep    ::=    (ReverseStep | ForwardStep) PredicateList
[40]    ForwardStep    ::=    (ForwardAxis NodeTest) | AbbrevForwardStep
[43]    ReverseStep    ::=    (ReverseAxis NodeTest) | AbbrevReverseStep
[51]    PredicateList    ::=    Predicate*

定義: ステップ (step) はパス式を構成する要素であって、アイテムのシーケンスを生成し、述語があればそれを使ってシーケンスをしぼり込む。ステップの値は、述語を左から右に適用し、すべてを満たしたアイテムから成る。ステップには軸ステップと後置式がある。】 後置式については「3.2 後置式」で説明している。

定義: 軸ステップ (axis step) は、文脈ノードから指定された軸をたどって到達できるノードのシーケンスを返す。ステップは2つの部分から成る。はステップの「移動方向」を表し、ノード・テストは、どのノードを選択するか、種類、名前、型註釈にもとづいて指定する。】 文脈アイテムがノードであれば、軸ステップは0個以上のノードから成るシーケンスを返す。そうでなければ型エラー [err:XPTY0020] が発生する。結果として得られたノード・シーケンスを、文書順に整列して返す。軸ステップは、前向きステップまたは後ろ向きステップと、その後に続く0個以上の述語から成る。

ステップの省略構文では、軸を省略するなど簡潔な記法で記述できる (「3.3.5 省略構文」を参照)。

軸ステップの非省略構文では、軸名とノード・テストを、連続する2つのコロンで区切る。ステップを評価すると、文脈ノードから指定された軸に沿って到達できるノードのうち、ノード・テストに指定された種類、名前、型註釈に合致するものが得られる。たとえばステップchild::paraは、文脈ノードの子であるpara要素を選択する。childは軸の名前、paraはこの軸上で選択するべき要素ノードの名前である。指定可能な軸については「3.3.2.1 軸」で説明する。指定可能なノード・テストについては「3.3.2.2 ノード・テスト」で説明する。ステップの例は「3.3.4 非省略構文」および「3.3.5 省略構文」に示す。

3.3.2.1 軸
[41]    ForwardAxis    ::=    ("child" "::")
| ("descendant" "::")
| ("attribute" "::")
| ("self" "::")
| ("descendant-or-self" "::")
| ("following-sibling" "::")
| ("following" "::")
| ("namespace" "::")
[44]    ReverseAxis    ::=    ("parent" "::")
| ("ancestor" "::")
| ("preceding-sibling" "::")
| ("preceding" "::")
| ("ancestor-or-self" "::")

XPathは文書を横断するためのをすべて定義しているが、ホスト言語はその部分集合を定義してもよい。次の軸が定義されている:

  • child軸には文脈ノードの子が含まれる。これは「5.3 childrenアクセサーDM31」が返すノードである。

    註記:

    子を持つのは文書ノードと要素ノードに限る。文脈ノードがこれ以外のノード、または空の文書ノードや要素ノードであった場合、child軸は空シーケンスになる。文書ノードや要素ノードの子は、要素、処理命令、註釈、テキストの、いずれかのノードである。属性、名前空間、文書の各ノードが、子として現れることはない。

  • descendant軸は、child軸の遷移的閉包として定義する。文脈ノードの子孫 (子、子の子、...) 全体から成る。

  • parent軸には、「5.11 parentアクセサーDM31」が返すシーケンスが含まれる。文脈ノードの親、または、これがなければ空シーケンスを返すアクセサーである。

    註記:

    属性ノードは要素ノードを親として持つことがある。属性ノードが要素ノードの子ではないことと対照的である。

  • ancestor軸は、parent軸の遷移的閉包として定義する。文脈ノードの祖先 (親、親の親、...) 全体から成る。

    註記:

    ancestor軸には、文脈ノードが属する木のルート・ノードも含まれる (文脈ノードがルート・ノードである場合を除く)。

  • following-sibling軸には、文脈ノードの弟が含まれる。文脈ノードの親の子のうち、文書順で、文脈ノードより後にあるノードである。文脈ノードが属性ノードまたは名前空間ノードの場合、following-sibling軸は空である。

  • preceding-sibling軸には、文脈ノードの兄が含まれる。文脈ノードの親の子のうち、文書順で、文脈ノードより前にあるノードである。文脈ノードが属性ノードまたは名前空間ノードの場合、preceding-sibling軸は空である。

  • following軸には、文脈ノードが属する木のルートの子孫のうち、文脈ノードの子孫ではなく、かつ、文書順で文脈ノードより後にあるノードが含まれる。

  • preceding軸には、文脈ノードが属する木のルートの子孫のうち、文脈ノードの祖先ではなく、かつ、文書順で文脈ノードより前にあるノードが含まれる。

  • attribute軸には、文脈ノードの属性が含まれる。これは、「5.11 parentアクセサーDM31」が返すノードでもある (訳註: おそらく「5.1 attributesアクセサー」の誤り)。文脈ノードが要素ノードでなければ、この軸は空になる。

  • self軸には、文脈ノードのみが含まれる。

  • descendant-or-self軸には、文脈ノードとその子孫が含まれる。

  • ancestor-or-self軸には、文脈ノードとその祖先が含まれる。したがって、常にルート・ノードも含まれることになる。

  • namespace軸には文脈ノードの名前空間ノードが含まれる。これは「5.7 namespace-nodesアクセサーDM31」が返すノードでもある。文脈ノードが要素ノードでなければ、この軸は空である。namespace軸は、XPath 2.0以降、非推奨になった。XPath 1.0互換モードtrueであれば、namespace軸に対応しなければならない。XPath 1.0互換モードfalseであれば、namespace軸に対応するか否かは実装定義である。XPath 1.0互換モードfalseのとき、namespace軸に対応しない実装は、これを使おうとしたとき、静的エラー [err:XPST0010] が発生するようにしなければならない。要素のスコープ内名前空間に関する情報を必要とするアプリケーションは、「10.2.6 fn:in-scope-prefixesFO31」および「10.2.5 fn:namespace-uri-for-prefixFO31」の函数を使うべきである。

軸は前向きの軸後ろ向きの軸に分かれる。文脈ノード、または文書順で文脈ノードより後のノードのみから成る軸が、前向きの軸である。文脈ノード、または文書順で文脈ノードより前のノードのみから成る軸が、後ろ向きの軸である。

parentancestorancestor-or-selfprecedingpreceding-siblingは後ろ向きの軸、それ以外は前向きの軸である。ancestordescendantfollowingprecedingselfの各軸で、(属性ノードおよび名前空間ノードを無視すると) 文書を分割できる。すなわち、それぞれに重複はなく、かつ、合併すると文書のノードがすべて含まれることになる。

定義: それぞれの軸には主たるノード種 (principal node kind) がある。要素を含みうる軸の場合、主たるノード種は要素である。そうでなければ、その軸に含まれうるノードの種類が、主たるノード種である。】 したがって次のようになる:

  • 属性軸の主たるノード種は属性である。

  • 名前空間軸の主たるノード種は名前空間である。

  • 上記以外の軸の主たるノード種は要素である。

3.3.2.2 ノード・テスト

定義: ノード・テスト (node test) は、ノードの名前、種類 (要素、属性、テキスト、文書、註釈、処理命令)、型註釈に関する条件である。ノード・テストは、ステップで、軸に含まれるノードのうちどれを選択するかを判断する。】

[46]    NodeTest    ::=    KindTest | NameTest
[47]    NameTest    ::=    EQName | Wildcard
[48]    Wildcard    ::=    "*"
| (NCName ":*")
| ("*:" NCName)
| (BracedURILiteral "*")
/* ws: explicit */
[112]    EQName    ::=    QName | URIQualifiedName

定義: EQNameまたはWildcardのみから成るノード・テストを名前テスト (name test) という。】 EQNameのみから成る名前テストがtrueになるのは、ノードの種類がステップ軸の主たるノード種であり、かつ、ノードの展開済みQNameが、名前テストに指定された展開済みQNameに、(eq演算子の意味で) 等しい場合である。たとえばchild::paraは、文脈ノードの子であるpara要素を選択する。文脈ノードにparaという子がなければ、ノードの空集合を選択することになる。attribute::abc:hrefは、文脈ノードの属性で、QNameがabc:hrefであるものを選択する。文脈ノードにこのような属性がなければ、ノードの空集合を選択することになる。

EQNameが字句規則上のQNameならば、式の文脈の静的に既知の名前空間を使って、これを展開済みQNameに解決する。QNameに接頭辞があり、これに対応する静的に既知の名前空間がない場合、静的エラー [err:XPST0081] が発生する。接頭辞のないQNameは、主たるノード種が要素である軸の名前テストに使った場合、式文脈の既定の要素/型名前空間の名前空間URIを持つ。そうでなければ、名前空間URIはない。

要素ノードの名前が、名前テストの展開済みQNameに合致しない場合、名前テストは満たされないことになる。件の要素をヘッドとする代替グループに属するものであっても、これは同じである。

ノード・テスト「*」は、ステップ軸の主たるノード種と一致する、任意のノードに関してtrueになる。たとえばchild::*は、文脈ノードの子である要素をすべて選択する。attribute::*は、文脈ノードの属性をすべて選択する。

ノード・テストはNCName:*という形になることもある。この場合、接頭辞は字句規則上のQNameと同じように、静的文脈静的に既知の名前空間を使って展開する。静的に既知の名前空間にこの接頭辞が見つからない場合、静的エラー [err:XPST0081] が発生する。ノード・テストは、ステップ軸の主たるノード種に属するノードで、展開済みQNameの名前空間URIが、接頭辞に束縛されている名前空間URIに合致するものが、名前のローカル部分にかかわらずtrueになる。

ノード・テストはBracedURILiteralを使って、Q{http://example.com/msg}*のように記述することもできる。このノード・テストがtrueになるのは、ステップ軸の主たるノード種に属するノードのうち、展開済みQNameが、BracedURILiteralに指定された名前空間URIに合致するものである。名前のローカル部分にはよらない。

ノード・テストは*:NCNameのように記述することもできる。このノード・テストがtrueになるのは、ステップ軸の主たるノード種に属するノードのうち、ローカル名が指定されたNCNameに合致するものである。名前空間にはよらず、また、名前空間がなくてもよい。

定義: ノード・テストのもうひとつの形式である種類テスト (kind test) は、種類、名前、型註釈にもとづいてノードを選択できる。】 種類テストの構文および意味は、「2.5.4 SequenceTypeの構文」および「2.5.5 SequenceTypeの照合」で説明している。種類テストがノード・テストで使われている場合、指定された軸上のノードのうち、種類テストに合致するもののみを選択する。パス式で使える種類テストの例をいくつか示す:

  • node()」は任意のノードと合致する。

  • text()」は任意のテキスト・ノードと合致する。

  • comment()」は任意の註釈ノードと合致する。

  • namespace-node()」は任意の名前空間ノードと合致する。

  • element()」は任意の要素ノードと合致する。

  • schema-element(person)」は、任意の要素ノードであって、名前がperson (またはpersonをヘッドとする代替グループに属する名前)、型註釈が、スコープ内要素宣言personの型として宣言されているもの (またはその派生型であるもの) に合致する。

  • element(person)」は、名前がpersonである任意の要素と合致する。型註釈にはよらない。

  • element(person, surgeon)」は、名前がpersonであるnilでない要素ノードで、型註釈がsurgeon (またはその派生型) であるものと合致する。

  • element(*, surgeon)」は、nilでない任意の要素ノードで、型註釈がsurgeon (またはその派生型) であるものと合致する。名前にはよらない。

  • attribute()」は任意の属性ノードと合致する。

  • attribute(price)」は、名前がpriceである、任意の属性ノードと合致する。型註釈にはよらない。

  • attribute(*, xs:decimal)」は、型註釈がxs:decimal (またはその派生型) である、任意の属性ノードと合致する。名前にはよらない。

  • document-node()」は任意の文書ノードと合致する。

  • document-node(element(book))」は、文書ノードのうち、内容 (子) として単一の要素ノードを含み、それが種類テストelement(book)」を満たすものと合致する。子として0個以上の註釈や処理命令があってもよい。

3.3.3 ステップ内の述語

[39]    AxisStep    ::=    (ReverseStep | ForwardStep) PredicateList
[51]    PredicateList    ::=    Predicate*
[52]    Predicate    ::=    "[" Expr "]"

ステップ内の述語の構文と意味は、しぼり込み式内の述語とよく似ている。唯一の違いは、述語を評価する際に、文脈位置を設定する方法である。

述語内の文脈位置を評価する目的で、入力シーケンスを次のように整列すると考える: すなわち、述語が前向きの軸ステップにあれば文書順、後ろ向きの軸ステップにあれば逆文書順である。ステップ内の述語でなければ元の順序のままである。

述語を含む軸ステップの例をいくつか示す:

  • この例は、文脈ノードの子である、2番目のchapter要素を選択する:

    child::chapter[2]
  • この例は、文脈ノードの子孫のうち、toyという名前の要素で、そのcolor属性の値が "red" であるものを選択する:

    descendant::toy[attribute::color = "red"]
  • この例は、文脈ノードの子のうち、employeeという名前で、その子要素としてsecretaryassistantの両方があるものを選択する:

    child::employee[secretary][assistant]

註記:

後ろ向きの軸を使って選択したノードのシーケンスに対して述語を適用する場合、当該シーケンスの文脈位置を逆文書順に割り当てることが重要である。たとえば「preceding::foo[1]」は、逆文書順で1番目のfoo要素を選択する。この述語が、後ろ向きの軸を使う軸ステップの一部だからである。これに対して「(preceding::foo)[1]」は、文書順で1番目のfoo要素を選択する。括弧で囲まれているため、(preceding::foo)基本式として解析される結果、文脈位置は文書順で割り当てられるからである。同様に、「ancestor::*[1]」は直近の祖先要素を返す。ancestorは後ろ向きの軸だからである。これに対して「(ancestor::*)[1]」は、ルート・ノード (文書順で最初の祖先) を返す。

後ろ向きの軸ステップが文脈位置を逆文書順に割り当てるのは、述語を評価するためだけであって、最終的に得られる結果は常に文書順になる。

3.3.4 非省略構文

この節では、パス式のうち、各ステップに明示的に軸を指定している例を挙げる。この例で使われている構文を、非省略構文という。多くの場合、省略構文を使ってより簡潔に書き直せるが、これについては「3.3.5 省略構文」で説明する。

  • child::para」は、文脈ノードの子であるpara要素を選択する。

  • child::*」は、文脈ノードの子である、すべての要素を選択する。

  • child::text()」は、文脈ノードの子である、すべてのテキスト・ノードを選択する。

  • child::node()」は、文脈ノードの子をすべて選択する。なお、属性ノードは、子ではないので除外する。

  • attribute::name」は、文脈ノードのname属性を選択する。

  • attribute::*」は、文脈ノードの属性をすべて選択する。

  • parent::node()」は、文脈ノードの親を選択する。文脈ノードが属性ノードであれば、当該属性ノードが属する要素ノードを返す。

  • descendant::para」は、文脈ノードの子孫であるpara要素を選択する。

  • ancestor::div」は、文脈ノードの祖先である、divをすべて選択する。

  • ancestor-or-self::div」は、文脈ノードの祖先であるdivを選択する。文脈ノードがdiv要素であれば、これも選択する。

  • descendant-or-self::para」は、文脈ノードの子孫であるpara要素を選択する。文脈ノードがpara要素であれば、これも選択する。

  • self::para」は、文脈ノードがpara要素であればこれを選択し、そうでなければ空シーケンスを返す。

  • child::chapter/descendant::para」は、文脈ノードの子であるchapter要素の、子孫であるpara要素を選択する。

  • child::*/child::para」は、文脈ノードの孫であるpara要素をすべて選択する。

  • /」は、文脈ノードが属する木のルートを選択する。ただし、このルートが文書ノードでない場合は、動的エラーが発生する。

  • /descendant::para」は、文脈ノードと同じ文書に属する、para要素をすべて選択する。

  • /descendant::list/child::member」は、member要素のうち、親がlistであり、文脈ノードと同じ文書に属するものをすべて選択する。

  • child::para[fn:position() = 1]」は、文脈ノードの子であるpara要素のうち、先頭のものを選択する。

  • child::para[fn:position() = fn:last()]」は、文脈ノードの子であるpara要素のうち、末尾のものを選択する。

  • child::para[fn:position() = fn:last()-1]」は、文脈ノードの子であるpara要素のうち、末尾から2番目のものを選択する。

  • child::para[fn:position() > 1]」は、文脈ノードの子であるpara要素のうち、先頭のparaを除いたものを選択する。

  • following-sibling::chapter[fn:position() = 1]」は、文脈ノードのすぐ下の弟であるchapter要素を選択する。

  • preceding-sibling::chapter[fn:position() = 1]」は、文脈ノードのすぐ上の兄であるchapter要素を選択する。

  • /descendant::figure[fn:position() = 42]」は、文脈ノードが属する文書中、42番目のfigure要素を選択する。

  • /child::book/child::chapter[fn:position() = 5]/child::section[fn:position() = 2]」は、文脈ノードが属する文書中、親が文書ノードであるようなbook要素の、5番目のchapterに属する2番目のsectionを選択する。

  • child::para[attribute::type eq "warning"]」は、文脈ノードの子であるpara要素のうち、type属性の値がwarningであるものを選択する。

  • child::para[attribute::type eq 'warning'][fn:position() = 5]」は、文脈ノードの子であるpara要素で、type属性の値がwarningであるもののうち、5番目のものを選択する。

  • child::para[fn:position() = 5][attribute::type eq "warning"]」は、文脈ノードの子であるpara要素の5番目を、そのtype属性の値がwarningであれば選択する。

  • child::chapter[child::title = 'Introduction']」は、文脈ノードの子であるchapter要素のうち、titleという子要素で、その型づけされた値が文字列Introductionに等しいものが、1つ以上あるものを選択する。

  • child::chapter[child::title]」は、文脈ノードの子であるchapter要素で、その子にtitle要素が1つ以上あるものを選択する。

  • child::*[self::chapter or self::appendix]」は、文脈ノードの子である、chapter要素およびappendix要素を選択する。

  • child::*[self::chapter or self::appendix][fn:position() = fn:last()]」は、文脈ノードの子であるchapter要素またはappendix要素で、末尾にあるものを選択する。

3.3.5 省略構文

[42]    AbbrevForwardStep    ::=    "@"? NodeTest
[45]    AbbrevReverseStep    ::=    ".."

省略構文を使うと次のような書き方ができる:

  1. 属性軸「attribute::」は、省略して「@」と書ける。たとえば、パス式「para[@type="warning"]」は「child::para[attribute::type="warning"]」の省略形であって、子要素paraのうち、type属性の値がwarningであるものを選択することになる。

  2. 軸ステップの軸名を省略した場合、その既定値はchildである。ただし2つの例外がある: (1) 軸ステップ中のNodeTestAttributeTestまたはSchemaAttributeTestが含まれていれば、既定の軸はattributeである。(2) 軸ステップのNodeTestNamespaceNodeTestであれば、既定の軸はnamespaceである。名前空間軸に対応していない実装の場合はエラー [err:XQST0134] が発生する。

    註記:

    XPath 2.0以降、名前空間軸は非推奨になったが、XSLTなど、XPathを使う一部の言語で必要になることがある。

    たとえば、パス式「section/para」は「child::section/child::para」の省略形、「section/@id」は「child::section/attribute::id」の省略形である。同様に、「section/attribute(id)」は「child::section/attribute::attribute(id)」の省略形である。この式には、軸の指定とノード・テストの両方が含まれていることになる。

  3. 先頭以外に現れた「//」は、実質的に、「/descendant-or-self::node()/」に置き換えて処理すればよい。たとえば「div1//para」は「child::div1/descendant-or-self::node()/child::para」の省略形なので、子であるdiv1要素の子孫である、para要素をすべて選択することになる。

    註記:

    パス式「//para[1]」は、「/descendant::para[1]」と同じではない。後者は子孫であるpara要素のうち先頭に当たるものを選択する。これに対して前者は、子孫であるpara要素すべてのうち、それぞれの親から見て最初のpara要素であるものを選択する。

  4. ..」というステップは、parent::node()の省略形である。たとえば「../title」は「parent::node()/child::title」の省略形なので、文脈ノードの親から見た、titleという子要素を選択することになる。

    註記:

    式「.」は文脈アイテム式と呼ばれる基本式であって、「3.1.4 文脈アイテム式」で説明している。

省略構文を使うパス式の例をいくつか示す:

  • para」は、文脈ノードの子であるpara要素を選択する。

  • *」は、文脈ノードの子である要素をすべて選択する。

  • text()」は、文脈ノードの子であるテキスト・ノードをすべて選択する。

  • @name」は、文脈ノードのname属性を選択する。

  • @*」は、文脈ノードの属性をすべて選択する。

  • para[1]」は、文脈ノードの子であるpara要素のうち、先頭のものを選択する。

  • para[fn:last()]」は、文脈ノードの子であるpara要素のうち、末尾のものを選択する。

  • */para」は、文脈ノードの孫に当たるpara要素をすべて選択する。

  • /book/chapter[5]/section[2]」は、文脈ノードが属する木の文書ノードを起点として、子であるbook要素の、子であるchapter要素の5番目の、子であるsection要素の2番目を選択する。

  • chapter//para」は、文脈ノードの子であるchapter要素の、子孫に当たるpara要素を選択する。

  • //para」は、ルートである文書ノードの子孫に当たるpara要素をすべて選択する。言い替えると、文脈ノードと同じ文書に属するpara要素をすべて選択する。

  • //@version」は、文脈ノードと同じ文書に属する、version属性ノードをすべて選択する。

  • //list/member」は、文脈ノードと同じ文書に属するmember要素のうち、親がlist要素であるものをすべて選択する。

  • .//para」は、文脈ノードの子孫であるpara要素を選択する。

  • ..」は、文脈ノードの親ノードを選択する。

  • ../@lang」は、文脈ノードの親のlang属性を選択する。

  • para[@type="warning"]」は、文脈ノードの子であるpara要素のうち、type属性の値がwarningであるものを選択する。

  • para[@type="warning"][5]」は、文脈ノードの子であるpara要素のうち、type属性の値がwarningであるものの、5番目の要素を選択する。

  • para[5][@type="warning"]」は、文脈ノードの子である5番目のpara要素を、そのtype属性の値がwarningであった場合に選択する。

  • chapter[title="Introduction"]」は、文脈ノードの子であるchapter要素のうち、title要素を子として持ち、その型づけされた値が文字列Introductionであるものを選択する。

  • chapter[title]」は、文脈ノードの子であるchapter要素のうち、title要素を子として持つものを選択する。

  • employee[@secretary and @assistant]」は、文脈ノードの子であるemployee要素のうち、secretary属性とassistant属性の両方があるものを選択する。

  • book/(chapter|appendix)/section」は、section要素のうち、その親がchapter要素またはappendix要素であって、さらにこれが、文脈ノードの子であるbook要素の子になっているものを選択する。

  • Eがノードのシーケンスを返す式である場合、式「E/.」は、同じノード群を文書順にし、ノードのIDをもとに重複を除去して返す。

3.4 シーケンス式

XPath 3.1には、アイテムから成るシーケンスを組み立て、しぼり込み、組み合わせる演算子が備わっている。シーケンスが入れ子になることはない。たとえば、値1(2, 3)( ) の3つを組み合わせてひとつのシーケンスにすると、(1, 2, 3) になる。

3.4.1 シーケンスの組み立て

[6]    Expr    ::=    ExprSingle ("," ExprSingle)*
[20]    RangeExpr    ::=    AdditiveExpr ( "to" AdditiveExpr )?

定義: シーケンスを組み立てる手段として、カンマ演算子 (comma operator) がある。オペランドをそれぞれ評価して得られる2つのシーケンスを順に連結し、1つのシーケンスにする演算子である。】 中身が空の丸括弧は空シーケンスを表す。

シーケンス中に重複するアイテムがあってもよいが、あるシーケンスを別のシーケンスのアイテムにすることはできない。2つ以上の入力シーケンスを連結して新しいシーケンスを生成すると、このシーケンスには入力シーケンス中のアイテムがすべて含まれ、その長さは入力シーケンスの長さの合計になる。

註記:

構文規則でExprSingleが現れている箇所 (たとえば函数呼び出しの引数) では、最上位のカンマ演算子を含む式をすべて、括弧で囲んで記述しなければならない。

シーケンスを組み立てる式の例をいくつか示す:

  • この式の結果は、5つの整数から成るシーケンスである:

    (10, 1, 2, 3, 4)
  • この式は、長さが1、2、0、2のシーケンス4つを組み合わせ、長さ5の1つのシーケンスを組み立てる。この式の結果は、10、1、2、3、4から成るシーケンスである。

    (10, (1, 2), (), (3, 4))
  • この式の結果は、文脈ノードの子であるsalary要素をすべて並べ、その後にbonus要素を並べたシーケンスである。

    (salary, bonus)
  • $priceが値10.50に束縛されているとすれば、この式の結果は、10.50、10.50から成るシーケンスである。

    ($price, $price)

範囲式を使って、連続する整数のシーケンスを組み立てることができる。to演算子のオペランドは、想定するパラメーター型がxs:integer?である函数の引数と同じように、変換して使う。いずれかのオペランドが空シーケンスであるか、第1オペランドから導いた整数値が、第2オペランドから導いた整数値よりも大きい場合、範囲式の結果は空シーケンスになる。2つのオペランドが同じ整数になるのであれば、範囲式の結果はその整数になる。上記のいずれでもない場合は、2つのオペランド間の整数をすべて、昇順に並べたものになる。

  • この例は、シーケンスを組み立てるオペランドのひとつとして、範囲式を使っている。この式の結果は、10、1、2、3、4から成るシーケンスである。

    (10, 1 to 4)
  • この例は、長さが1で、単一の整数10のみを含むシーケンスを組み立てる。

    10 to 10
  • この例の結果は、長さ0のシーケンスになる。

    15 to 10
  • この例はfn:reverse函数を使って、6つの整数を降順に並べたシーケンスを組み立てる。評価結果は、15、14、13、12、11、10から成るシーケンスである。

    fn:reverse(10 to 15)

3.4.2 ノードから成るシーケンスの組み合わせ

[23]    UnionExpr    ::=    IntersectExceptExpr ( ("union" | "|") IntersectExceptExpr )*
[24]    IntersectExceptExpr    ::=    InstanceofExpr ( ("intersect" | "except") InstanceofExpr )*

XPath 3.1には、ノードのシーケンスを組み合わせる、次のような演算子がある。

  • unionと「|」は同等の演算子である。ノードから成る2つのシーケンスをオペランドとし、少なくとも一方に現れるノードすべてから成るシーケンスを返す。

  • intersect演算子は、ノードから成る2つのシーケンスをオペランドとし、両方に現れるノードすべてから成るシーケンスを返す。

  • except演算子は、ノードから成る2つのシーケンスをオペランドとし、第1オペランドに現れるが第2オペランドには現れない、すべてのノードから成るシーケンスを返す。

上記の演算子はいずれも、結果として得られたシーケンスから、ノードのIDにもとづき重複を除去する。さらに、シーケンスを文書順にして返す。

unionintersectexceptのオペランドにノード以外のアイテムが含まれている場合、型エラー [err:XPTY0004] が発生する。

IntersectExceptExprが3つ以上のInstanceofExprsから成る場合、左から右に結合する。UnionExprについては、オペランドをどのように結合しても同じ結果になる。

シーケンスを組み合わせる式の例をいくつか示す。3つの要素ノード群があると想定し、それぞれ記号名A、B、Cで表すことにしよう。さらに、変数$seq1$seq2$seq3が、ノードから成る次のシーケンスに束縛されているとする。

  • $seq1は (A, B) に束縛

  • $seq2は (A, B) に束縛

  • $seq3は (B, C) に束縛

すると次のようになる:

  • $seq1 union $seq2」を評価するとシーケンス (A, B) が得られる。

  • $seq2 union $seq3」を評価するとシーケンス (A, B, C) が得られる。

  • $seq1 intersect $seq2」を評価するとシーケンス (A, B) が得られる。

  • $seq2 intersect $seq3」を評価するとBのみから成るシーケンスが得られる。

  • $seq1 except $seq2」を評価すると空シーケンスが得られる。

  • $seq2 except $seq3」を評価するとAのみから成るシーケンスが得られる。

ここに挙げたシーケンス演算子のほかに、シーケンスに対して定義された函数がいくつかある。「14 シーケンスを対象とする函数と演算子FO31」を参照。

3.5 算術演算式

XPath 3.1には、加算、減算、乗算、除算、剰余算の算術演算子 (二項および単項) がある。

[21]    AdditiveExpr    ::=    MultiplicativeExpr ( ("+" | "-") MultiplicativeExpr )*
[22]    MultiplicativeExpr    ::=    UnionExpr ( ("*" | "div" | "idiv" | "mod") UnionExpr )*
[30]    UnaryExpr    ::=    ("-" | "+")* ValueExpr
[31]    ValueExpr    ::=    SimpleMapExpr

減算演算子の前に空白を置かないと、直前のトークンの一部と解釈されてしまうことがある。たとえば、「a-b」は名前と解釈されるが、「a - b」や「a -b」と書けば算術演算式になる (空白類の取り扱いについては「A.2.4 空白類に関する規則」を参照)。

AdditiveExprが3つ以上のMultiplicativeExprsから成る場合、左から右に結合する。したがって、

A - B + C - D

((A - B) + C) - D

と同等である。同様に、MultiplicativeExprのオペランドも左から右に結合する。

算術演算式の評価では、まずオペランドを評価する。オペランドを評価する順序は実装依存である。

XPath 1.0互換モードtrueであれば、次の手順を順に適用して各オペランドを評価する。

  1. オペランドに原子化を施す。その結果を原子化済みオペランドと呼ぶ。

  2. 原子化済みオペランドが空シーケンスであれば、算術演算式の結果はxs:double型の値NaNであり、他のオペランドを評価したり、演算子を適用したりする必要はない。ただし、他のオペランドも評価して、エラーが発生するか否か判断するよう実装してもよい。

  3. 原子化済みオペランドが長さ2以上のシーケンスであれば、2番目以降のアイテムを破棄する。

  4. 原子化済みオペランドの型が、xs:booleanxs:stringxs:decimal (xs:integerを含む)、xs:floatxs:untypedAtomicのいずれかであれば、fn:number函数を適用してxs:double型に変換する (fn:numberは、数値に変換できない場合、値NaNを返す)。

XPath 1.0互換モードfalseであれば、次の手順を順に適用して各オペランドを評価する。

  1. オペランドに原子化を施す。その結果を原子化済みオペランドと呼ぶ。

  2. 原子化済みオペランドが空シーケンスであれば、算術演算式の結果は空シーケンスであり、他のオペランドを評価したり、演算子を適用したりする必要はない。ただし、他のオペランドも評価して、エラーが発生するか否か判断してもよい。

  3. 原子化済みオペランドが長さ2以上のシーケンスであれば、型エラー [err:XPTY0004] が発生する。

  4. 原子化済みオペランドの型がxs:untypedAtomicであれば、xs:doubleにキャストする。キャストに失敗した場合は動的エラー [err:FORG0001]FO31 が発生する。

オペランドを評価した後、オペランドの型が、算術演算子を適用できる有効な組み合わせであれば、実際に算術演算式をオペランドに適用して、原子値である結果を得る。そうでなければ、動的エラー (たとえば0除算) が発生する。各種の算術演算子が受理する原子型の組み合わせと、対応する結果型を、「B.2 演算子マッピング」に示す。ここでは演算子函数として、型の組み合わせごとに、演算子の意味 (発生しうる動的エラーを含む) を定義している。演算子函数の定義は [XQuery and XPath Functions and Operators 3.1] に載っている。

評価後のオペランドの型が、「B.2 演算子マッピング」の規則により、演算子が受理する有効な組み合わせでなかった場合、型エラー [err:XPTY0004] が発生する。

XPath 3.1には除算演算子が、dividivの2種類ある。いずれもnumeric型の2つのオペランドを取る。divの意味は「4.2.5 op:numeric-integer-divideFO31」、idivの意味は「4.2.4 op:numeric-divideFO31」に定義されている。

算術演算式の例をいくつか示す:

  • 次の第1の式はxs:decimal型の値-1.5、第2の式はxs:integer型の値-1を返す:

    -3 div 2
    -3 idiv 2
  • date型の値の減算により、xs:dayTimeDuration型の値が得られる:

    $emp/hiredate - $emp/birthdate
  • この例は減算演算子とハイフンの違いを示している:

    $unit-price - $unit-discount
  • 単項演算子は二項演算子 (「!」、「/」、「[]」を除く) よりも優先度が高い。もちろん、括弧を使えば優先度を変更できる。したがって、次の2つの例は意味が異なる:

    -$bellcost + $whistlecost
    -($bellcost + $whistlecost)

註記:

複数の単項算術演算子を連続して並べることも可能である。

3.6 文字列連結式

[19]    StringConcatExpr    ::=    RangeExpr ( "||" RangeExpr )*

文字列連結式を使うと、値の文字列表現を連結できる。In XPath 3.1では、「$a || $b」は「fn:concat($a, $b)」と同等である。次の式を評価すると文字列「concatenate」が得られる:

"con" || "cat" || "enate"

3.7 比較演算式

比較演算式で、2つの値を比較できる。XPath 3.1には3種類の比較演算式があり、それぞれ、値比較、汎化比較、ノード比較と呼ぶ。

[18]    ComparisonExpr    ::=    StringConcatExpr ( (ValueComp
| GeneralComp
| NodeComp) StringConcatExpr )?
[33]    ValueComp    ::=    "eq" | "ne" | "lt" | "le" | "gt" | "ge"
[32]    GeneralComp    ::=    "=" | "!=" | "<" | "<=" | ">" | ">="
[34]    NodeComp    ::=    "is" | "<<" | ">>"

註記:

XPathの式をXML文書内に記述する場合は、特殊文字に関するXMLのエスケープ規則に従う必要がある。したがって、「<」は「&lt;」と書かなければならない。

3.7.1 値比較

値比較の演算子には、eqneltlegtgeがある。値比較は単一の値どうしの比較に用いる。

値比較の評価では、まずオペランドを評価する。オペランドを評価する順序は実装依存である。次の手順を順に適用して、各オペランドを評価する。

  1. 各オペランドに原子化を施す。その結果を原子化済みオペランドと呼ぶ。

  2. 原子化済みオペランドが空シーケンスであれば、値比較の結果は空シーケンスであり、他のオペランドを評価したり、演算子を適用したりする必要はない。ただし、他のオペランドも評価して、エラーが発生するか否か判断してもよい。

  3. 原子化済みオペランドが長さ2以上のシーケンスであれば、型エラー [err:XPTY0004] が発生する。

  4. 原子化済みオペランドの型がxs:untypedAtomicであれば、xs:stringにキャストする。

    註記:

    この規則の目的は、値比較を遷移的にすることである。汎化比較演算子はxs:untypedAtomic型オペランドのキャストに関して、異なる規則に従うことに註意されたい。また、値比較は、遷移的である代償として、型変換で精度が損なわれる可能性がある (たとえば、わずかに異なる2つのxs:integer値が、xs:float値としては等しいとされることがある。xs:floatの精度はxs:integerより低いからである)。

  5. 2つのオペランドが異なるプリミティブ型 (「3.2 プリミティブ・データ型XS2に定義された、19のプリミティブ型) のインスタンスであれば、次のように処理を施す。

    1. 各オペランドがxs:string型またはxs:anyURI型のインスタンスであれば、両方のオペランドをxs:string型にキャストする。

    2. 各オペランドがxs:decimal型またはxs:float型のインスタンスであれば、両方のオペランドをxs:float型にキャストする。

    3. 各オペランドがxs:decimal型、xs:float型、xs:double型のいずれかのインスタンスであれば、両方のオペランドをxs:double型にキャストする。

    4. 上記以外の場合、型エラー [err:XPTY0004] が発生する。

      註記:

      この目的では、xs:integer値のプリミティブ型はxs:decimalであると看做す。

  6. 最後に、オペランドの型が、演算子が受理する有効な組み合わせである場合、実際に演算子をオペランドに適用する。

各種の算術演算子が受理する原子型の組み合わせと、対応する結果型を、「B.2 演算子マッピング」に示す。ここでは演算子函数として、型の組み合わせごとに、演算子の意味を定義している。演算子函数の定義は [XQuery and XPath Functions and Operators 3.1] に載っている。

正式な書き方ではないが、原子化済みオペランドがどちらもちょうど1つの原子値から成るならば、比較の結果がtrueになるのは、第1オペランドの値が第2オペランドの値 (に等しい/に等しくない/より小さい/より小さいか等しい/より大きい/より大きいか等しい) 場合である。そうでなければ結果はfalseになる。

評価後のオペランドの型が、「B.2 演算子マッピング」の規則により、演算子が受理する有効な組み合わせでなかった場合、型エラー [err:XPTY0004] が発生する。

値比較の例をいくつか示す:

  • 次の比較ではまず、式「$book/author」の値であるノードを原子化する。比較結果がtrueになるのは、原子化の結果がxs:stringまたはxs:untypedAtomicのインスタンスで、値が "Kennedy" である場合に限る。原子化の結果が空シーケンスであれば、比較の結果は空シーケンスである。比較の結果が複数の値から成るシーケンスであれば、型エラー [err:XPTY0004] が発生する。

    $book1/author eq "Kennedy"
  • 次の比較結果はtrueになる。原子化の過程で、配列はその要素から成るシーケンスになるからである。

    [ "Kennedy" ] eq "Kennedy"
  • 次のパス式には、重量が100を越えている製品を選ぶための述語がついている。weightという子要素がない製品は、述語の値が空シーケンスになるので、選択されない。この例は、weightが数値型である旨、検証済みであると想定している。

    //product[weight gt 100]
  • 次の比較結果がtrueになるのは、my:hatsizemy:shoesizeがどちらも、numeric型を制限した、ユーザー定義の派生型である場合である。

    my:hatsize(5) eq my:shoesize(5)
  • 次の比較結果はtrueになる。eq演算子は2つのQNameを、名前空間URIとローカル名のコードポイントで比較し、名前空間接頭辞は無視する。

    fn:QName("http://example.com/ns1", "this:color") eq fn:QName("http://example.com/ns1", "that:color")

3.7.2 汎化比較

汎化比較演算子には、=!=<<=>>=がある。汎化比較は存在量化された比較で、任意の長さのシーケンスに適用できる。エラーが発生しなければ、結果は常にtrueまたはfalseである。

XPath 1.0互換モードtrueであれば、汎化比較は、次の規則を順に適用して評価する。

  1. いずれかのオペランドが単一の原子値で、xs:booleanのインスタンスであれば、もう一方のオペランドの実効ブール値を求め、xs:booleanに変換する。

  2. 各オペランドに原子化を施す。その結果、各オペランドは原子値のシーケンスになる。

  3. 比較演算子が<<=>>=のいずれかであれば、両方のオペランド (シーケンス) に属する各アイテムにfn:number函数を適用して、xs:double型に変換する (fn:numberは、数値に変換できない場合、値NaNを返す)。

  4. 比較の結果がtrueになるのは、原子値の組 (一方は第1オペランドのシーケンス、もう一方は第2オペランドのシーケンスから取ったもの) であって、必要な大小関係を満たすものが存在する場合である。そうでなければ比較結果はfalseまたはエラーになる。2つの原子値間の大小関係は、以下の規則を適用して判断する。規則にもとづき呼び出したcast演算子が成功しなかった場合は動的エラー [err:FORG0001]FO31 が発生する。

    1. 2つの原子値のうち少なくとも一方がnumeric型のインスタンスであれば、両方の原子値にfn:number函数を適用してxs:double型に変換する。

    2. 2つの原子値のうち少なくとも一方がxs:string型のインスタンスであるか、または両方の原子値がxs:untypedAtomic型のインスタンスであれば、両方の原子値をxs:string型にキャストする。

    3. いずれかの原子値がxs:untypedAtomic型のインスタンスであり、もう一方の原子値が、xs:stringxs:untypedAtomicnumericの、どの型のインスタンスでもない場合、xs:untypedAtomic型の値を、もう一方の値の動的型にキャストする。

    4. 以上の変換を施した後、2つの原子値を、汎化比較演算子=!=<<=>>=に対応してそれぞれ、値比較演算子eqneltlegtgeを使って比較する。値が必要な大小関係を満たすのは、この値比較の結果がtrueであった場合である。

XPath 1.0互換モードfalseであれば、汎化比較は、次の規則を順に適用して評価する。

  1. 各オペランドに原子化を施す。その結果、各オペランドは原子値のシーケンスになる。

  2. 比較の結果がtrueになるのは、原子値の組 (一方は第1オペランドのシーケンス、もう一方は第2オペランドのシーケンスから取ったもの) であって、必要な大小関係を満たすものが存在する場合である。そうでなければ比較結果はfalseまたはエラーになる。2つの原子値間の大小関係は、以下の規則を適用して判断する。規則にもとづき呼び出したcast演算子が成功しなかった場合は動的エラー [err:FORG0001]FO31 が発生する。

    1. どちらの原子値もxs:untypedAtomicのインスタンスであれば、xs:stringにキャストする。

    2. いずれか一方のみがxs:untypedAtomic型の原子値であれば、もう一方の値の動的型Tに、以下の規則に従ってキャストする。なお、以下の規則で、Vはキャスト対象の値を表す。

      1. Tが数値型またはその派生型であれば、Vをxs:doubleにキャストする。

      2. Tがxs:dayTimeDuration型またはその派生型であれば、Vをxs:dayTimeDurationにキャストする。

      3. Tがxs:yearMonthDuration型またはその派生型であれば、Vをxs:yearMonthDurationにキャストする。

      4. 上記以外の場合、VをTのプリミティブ基底型にキャストする。

      註記:

      時間間隔型について特別な扱いを要するのは、プリミティブ型xs:durationを時間間隔型と比較する際に、エラーが発生するのを避けるためである。

    3. 以上の変換を施した後、2つの原子値を、汎化比較演算子=!=<<=>>=に対応してそれぞれ、値比較演算子eqneltlegtgeを使って比較する。値が必要な大小関係を満たすのは、この値比較の結果がtrueであった場合である。

汎化比較の評価で、いずれかのオペランドがアイテムのシーケンスであった場合、第1オペランドのアイテムと第2オペランドのアイテムの組で、必要な大小関係を満たすものが見つかった時点で、すぐにtrueを返すよう実装してもよい。同様に、いずれかのオペランドを評価し、あるいは2つのオペランドから選んだ組を比較する際に、エラーが発生した時点で、すぐに動的エラーになるよう実装してもよい。この規則があるため、エラーがある状況では、汎化比較の結果は非確定性である。

汎化比較の例をいくつか示す。

  • 次の比較結果がtrueになるのは、$book1の子であるいずれかのauthor要素の型づけされた値が、xs:stringまたはxs:untypedAtomicのインスタンスとして、"Kennedy" である場合である。

    $book1/author = "Kennedy"
  • 次の比較結果はtrueになる。原子化の過程で、配列はその要素から成るシーケンスになるからである。

    [ "Obama", "Nixon", "Kennedy" ] = "Kennedy"
  • 次の例には汎化比較が3つある。1番目と2番目の比較結果はtrue、3番目の比較結果はfalseとなる。これは汎化比較が遷移的でないことを表す例になっている。

    (1, 2) = (2, 3)
    (2, 3) = (3, 4)
    (1, 2) = (3, 4)
  • 次の例には汎化比較が2つあり、いずれもtrueになる。これは =!= が逆の関係ではないことを表す例になっている。

    (1, 2) = (2, 3)
    (1, 2) != (2, 3)
  • 変数$a$b$cは要素ノードに束縛されており、型註釈はxs:untypedAtomic文字列値はそれぞれ「1」、「2」、「2.0」であるとする。すると、($a, $b) = ($c, 3.0)falseを返す。$b$cは文字列として比較するからである。しかし、($a, $b) = ($c, 2.0)trueを返す。$b2.0は数値として比較するからである。

3.7.3 ノード比較

ノード比較は、2つのノードを、そのID、または文書順で比較するために使う。ノード比較の結果は次の規則にもとづいて決まる。

  1. ノード比較のオペランドを実装依存の順序で評価する。

  2. いずれかのオペランドが空シーケンスであれば、比較結果は空シーケンスになる。もう一方のオペランドを評価し、あるいは演算子を適用する必要はない。ただし、もう一方のオペランドも評価して、エラーが発生しないか判定するよう実装してもよい。

  3. 各オペランドは、単一のノード、または空シーケンスでなければならない。そうでなければ型エラー [err:XPTY0004] が発生する。

  4. is演算子による比較結果がtrueになるのは、2つのオペランドが同じノードの場合である。そうでなければfalseになる。ノードのIDの定義は [XQuery and XPath Data Model (XDM) 3.1] を参照。

  5. <<」演算子による比較結果がtrueになるのは、左オペランドが文書順で右オペランドより前にある場合である。そうでなければfalseを返す。

  6. >>」演算子による比較結果がtrueになるのは、左オペランドが文書順で右オペランドより後にある場合である。そうでなければfalseを返す。

ノード比較の例をいくつか示す。

  • 次の比較結果がtrueになるのは、左辺と右辺を評価した結果が、単一の同じノードになる場合である。

    /books/book[isbn="1558604820"] is /books/book[call="QA76.9 C3845"]
  • 次の比較結果がtrueになるのは、左辺で示されるノードが、右辺で示されるノードよりも、文書順で前に現れる場合である。

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

3.8 論理演算式

論理演算式にはand式or式がある。エラーが発生しなければ、値は常にブール値trueまたはfalseである。

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

論理演算式の評価ではまず、各オペランドの実効ブール値を求める (「2.4.3 実効ブール値」を参照)。

and式の値は、オペランドの実効ブール値 (EBV) から、次の表に従って決まる。

AND: EBV2 = true EBV2 = false error in EBV2
EBV1 = true true false error
EBV1 = false false false if XPath 1.0 compatibility mode is true, then false; otherwise either false or error.
error in EBV1 error if XPath 1.0 compatibility mode is true, then error; otherwise either false or error. error

or式の値は、オペランドの実効ブール値 (EBV) から、次の表に従って決まる。

OR: EBV2 = true EBV2 = false error in EBV2
EBV1 = true true true if XPath 1.0 compatibility mode is true, then true; otherwise either true or error.
EBV1 = false true false error
error in EBV1 if XPath 1.0 compatibility mode is true, then error; otherwise either true or error. error error

XPath 1.0互換モードtrueであれば、論理演算式のオペランドを評価する順序は実質的に決まっている。特に、第2オペランドを評価しなくても結果が決まる場合、これを評価することによりエラーが発生することはない。

XPath 1.0互換モードfalseであれば、論理式のオペランドを評価する順序は実装依存である。この場合、先に評価した式の結果がtrueであれば、or式はtrueを返してよい。また、評価の結果、エラーが発生するのであれば、エラーを発生させてよい。同様に、先に評価した式の結果がfalseであれば、and式はfalseを返してよい。また、評価の結果、エラーが発生するのであれば、エラーを発生させてよい。この規則の結果、エラーの有無に関して、以下の例に示すように、論理演算式は非決定性である。

論理演算式の例をいくつか示す。

  • 次の式はtrueを返す。

    1 eq 1 and 2 eq 2
    1 eq 1 or 2 eq 3
  • 次の式は、falseを返すか、または動的エラーが発生する (XPath 1.0 互換モードであれば、結果はfalseでなければならない)。

    1 eq 2 and 3 idiv 0 = 1
  • 次の式は、trueを返すか、または動的エラーが発生する (XPath 1.0 互換モードであれば、結果はtrueでなければならない)。

    1 eq 1 or 3 idiv 0 = 1
  • 次の式は、必ず動的エラーが発生する。

    1 eq 1 and 3 idiv 0 = 1

and式とor式に加え、XPath 3.1にはfn:notという函数がある。これはシーケンス一般をパラメーターとし、ブール値を返す。fn:not函数の定義は [XQuery and XPath Functions and Operators 3.1] にある。fn:not函数はまず、パラメーターを実効ブール値に変換する。そして、実効ブール値がfalseであればtruetrueであればfalseを返す。オペランドの実効ブール値を求める際にエラーが発生した場合、fn:notもその同じエラーになる。

3.9 for式

XPathにはfor式という、反復の仕組みがある。

[8]    ForExpr    ::=    SimpleForClause "return" ExprSingle
[9]    SimpleForClause    ::=    "for" SimpleForBinding ("," SimpleForBinding)*
[10]    SimpleForBinding    ::=    "$" VarName "in" ExprSingle

for式は次のように評価する。

  1. for式に複数の変数が現れる場合はまず、それぞれ1つの変数のみ現れる、入れ子になったfor式に展開する。たとえば、式「for $x in X, $y in Y return $x + $y」を展開すると、「for $x in X return for $y in Y return $x + $y」になる。

  2. 単一変数のfor式で、この変数を範囲変数inキーワードの後にある式の値を束縛シーケンスreturnキーワードの後に来る式をreturn式という。for式の結果は、束縛シーケンスの各アイテムに対して1回ずつ、範囲変数をこのアイテムに束縛し、return式を評価することにより得られる。その結果得られるシーケンスを、束縛シーケンスに現れるアイテムの順に、(カンマ演算子のように) 連結する。

for式を使って入力文書の構成を変える例を示す。次の入力が与えられたとしよう。

<bib>
  <book>
    <title>TCP/IP Illustrated</title>
    <author>Stevens</author>
    <publisher>Addison-Wesley</publisher>
  </book>
  <book>
    <title>Advanced Programming in the Unix Environment</title>
    <author>Stevens</author>
    <publisher>Addison-Wesley</publisher>
  </book>
  <book>
    <title>Data on the Web</title>
    <author>Abiteboul</author>
    <author>Buneman</author>
    <author>Suciu</author>
  </book>
</bib>

次の例は上記の入力文書を、著者名とその著書名のリスト (著者名はそれぞれ1度だけ現れる) に変換する。ここで、文脈アイテムは、入力文書のbib要素であると想定する。

for $a in fn:distinct-values(book/author)
return ((book/author[. = $a])[1], book[author = $a]/title)

上記の式の結果は、次のような要素のシーケンスになる。著者名の後に、その著者による書籍の題名が並ぶ。結果に現れるauthor要素の順序は実装依存である。これはfn:distinct-values函数の意味による結果である。

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

複数の変数が現れるfor式の例を示す。

for $i in (10, 20),
    $j in (1, 2)
return ($i + $j)

この式の結果は、数値のシーケンスとして表すと次のようになる: 11, 12, 21, 22

for式で束縛される変数のスコープは、変数束縛以降に現れるfor式の部分式すべてにわたる。変数が束縛される式は、スコープに含まれない。変数束縛が、同じfor式で先に束縛された、他の変数を参照する例を示す。

for $x in $z, $y in f($x)
return g($x, $y)

註記:

for式のreturn節を評価するためのフォーカスは、for式自身を評価するためのフォーカスと同じである。次の例は、order-itemの集合に属する値の総和を求めるものであるが、これは誤っている。

fn:sum(for $i in order-item return @price * @qty)

代わりに、for節で束縛された値を使って、次のように書かなければならない。

fn:sum(for $i in order-item return $i/@price * $i/@qty)

3.10 let式

XPathでは、変数を宣言し、let式でこれを値に束縛できる。

[11]    LetExpr    ::=    SimpleLetClause "return" ExprSingle
[12]    SimpleLetClause    ::=    "let" SimpleLetBinding ("," SimpleLetBinding)*
[13]    SimpleLetBinding    ::=    "$" VarName ":=" ExprSingle

let式は次のように評価する。

  • let式に複数の変数が現れている場合はまず、それぞれ1つの変数のみ現れる、入れ子になったlet式に展開する。たとえば、式「let $x := 4, $y := 3 return $x + $y」を展開すると、「let $x := 4 return let $y := 3 return $x + $y」になる。

  • 単一変数のlet式で、この変数を範囲変数、「:=」記号の後に来る式の値を束縛シーケンス、returnキーワードの後に来る式をreturn式という。let式の結果は、束縛シーケンスに範囲変数を束縛して、return式を評価することにより得られる。

let式で束縛された変数のスコープは、変数束縛以降に現れるlet式の部分式すべてにわたる。変数が束縛される式は、スコープに含まれない。変数束縛が、同じlet式で先に束縛された、他の変数を参照する例を示す。

let $x := doc('a.xml')/*, $y := $x//*
return $y[@value gt $x/@min]

3.11 マップと配列

最近の多くのプログラミング言語が、キーと値から成る組のコレクションを扱えるようになっており、マップ、辞書、連想配列、ハッシュ表、キーつきリスト、オブジェクト (オブジェクト指向システムでいうオブジェクトとは異なる) などと呼ばれている。XPath 3.1ではこれを「マップ」と呼ぶ。また、最近の多くのプログラミング言語が、値の順序つきリストを扱えるようになっており、配列、ベクトル、シーケンスなどと呼ばれている。XPath 3.1にはシーケンスと配列がある。配列は、シーケンスと違ってアイテムであり、シーケンス中のアイテムとして現れうる。

これまでの版のXPathでは、複合データ構造として、要素の構造とシーケンスしかなかった。XPath 3.1ではマップと配列が付け加わり、軽量のデータ構造として使えるようになった。最適化が容易で、中間処理に使ってもそれほど複雑でない。さらに、XMLとJSONを組み合わせて処理するプログラムも容易に記述できる。

註記:

XPath 3.1の仕様では、マップや配列に関係する構文、特に構築子と検索に着目する。

マップや配列で通常必要となる機能のいくつかは、函数 (「17 マップと配列FO31」を参照) として提供する。JSONを読み込んでマップや配列を生成する、マップや配列をJSONとして直列化する、マップを併合して新しいマップを生成する、マップのエントリーを削除して新しいマップを生成する、マップのキー全体にわたって反復する、配列をシーケンスに変換する、配列を組み合わせて新しい配列にする、さまざまな方法で配列全体にわたって反復する、などといった函数がある。

3.11.1 マップ

定義: マップ (map) はキーの集合を値に対応づける函数であり、したがって、キーと値から成る組のコレクションとして実現する。】 【定義: マップに含まれる、キーと値から成る組それぞれをエントリー (entry) という。】 【定義: あるキーに対応する値を、キーの値 (associated value) という。】

3.11.1.1 マップ構築子

マップはMapConstructorを使って生成する。

[69]    MapConstructor    ::=    "map" "{" (MapConstructorEntry ("," MapConstructorEntry)*)? "}"
[70]    MapConstructorEntry    ::=    MapKeyExpr ":" MapValueExpr
[71]    MapKeyExpr    ::=    ExprSingle
[72]    MapValueExpr    ::=    ExprSingle

註記:

状況によっては、MapConstructorEntryのコロンの前後に空白類を入れないと、意図どおりに構文解析されないことがある。

たとえば「map{a:b}」という式を考えてみよう。これはMapConstructorのEBNFに合致している (「a」がMapKeyExpr、「b」がMapValueExprに合致) が、「最長合致」の規則により、「a:b」はQNameと解釈され、構文エラーになってしまう。式を「map{a :b}」または「map{a: b}」と書き替えれば、これを避け、意図どおりに解析させることができる。

同様に、次の3つの式を考えてみよう。

    map{a:b:c}
    map{a:*:c}
    map{*:b:c}

いずれの場合も、式はEBNFに2とおりの方法で合致する。しかし「最長合致」の規則により、MapKeyExprはそれぞれ「a:b」、「a:*」、「*:b」に、MapValueExprは「c」に合致することになる。そうではなく、MapKeyExprが「a」や「*」に合致するようにしたければ、1つめのコロンの前か後に空白を入れるとよい。

A.2 字句構造」を参照。

この式の値はマップである。引き続き現れるMapKeyExpr式とMapValueExpr式を評価したものが、キーと値の組に対応するエントリーになる。

MapKeyExpr式それぞれを評価し、原子化する。その結果が単一の原子値でなかった場合、型エラー [err:XPTY0004] が発生する。キーの値は、対応するMapValueExprを評価した結果である。MapValueExprを評価した結果がノードであれば、キーの値はそのノード自身であって、同じ値のノードを新たに生成する必要はない。

註記:

XPath 3.1には、あるマップや配列を、値が同じ他のマップや配列と区別する演算子がない。一方、将来の版のXQuery Update Facilityでは、この違いが重要な意味を持つようになり、構築されるデータ・モデルのインスタンスについて明確にする必要が生じるだろう。

既存のある実装 (独自の拡張により更新に対応) では、MapValueExprを評価した結果がマップや配列であった場合、キーの値は、新たに生成した同じ値のマップや配列である。

定義: 2つの原子値K1およびK2同じキー値 (same key value) であるとは、op:same-key(K1, K2)trueを返す場合である (「17.1.1 op:same-keyFO31」)。】 同じキー値である複数のエントリーがあった場合、動的エラー [err:XQDY0137] が発生する。

例:

次の式は、7つのエントリーから成るマップを構築する。

map {
  "Su" : "Sunday",
  "Mo" : "Monday",
  "Tu" : "Tuesday",
  "We" : "Wednesday",
  "Th" : "Thursday",
  "Fr" : "Friday",
  "Sa" : "Saturday"
}

マップは入れ子にすることができ、どのようなXDM値でも収容できる。入れ子になったマップの例を以下に示す。値として、文字列値、数値、配列が現れている。

map {
    "book": map {
        "title": "Data on the Web",
        "year": 2000,
        "author": [
            map {
                "last": "Abiteboul",
                "first": "Serge"
            },
            map {
                "last": "Buneman",
                "first": "Peter"
            },
            map {
                "last": "Suciu",
                "first": "Dan"
            }
        ],
        "publisher": "Morgan Kaufmann Publishers",
        "price": 39.95
    }
}
    
3.11.1.2 函数呼び出し構文によるマップの検索

マップは函数であり、函数呼び出しによって、キーに対応する値を検索できる。$mapがマップ、$keyがキーとすると、「$map($key)」は「map:get($map, $key)」と同等である。この函数の意味は、「17.1.6 map:getFO31」に定義がある。

例:

  • $weekdays("Su") は、キー「Su」に対応するキーの値を返す。

  • $books("Green Eggs and Ham") は、キー「Green Eggs and Ham」に対応するキーの値を返す。

註記:

XPath 3.1には、マップや配列を検索する、より簡潔な構文もある。ワイルドカードが使え、常にマップや配列のシーケンス全体にわたって検索できる。詳しくは「3.11.3 マップおよび配列の検索演算子 ("?")」を参照。

マップの検索は連鎖できる。

例: (以下の例で$bには、前節のbooksマップが束縛されているものとする)

  • 式「$b("book")("title")」は文字列「Data on the Web」を返す。

  • 式「$b("book")("author")」は著者の配列を返す。

  • 式「$b("book")("author")(1)("last")」は文字列「Abiteboul」を返す。

    (この例は、マップの検索に「3.11.2.2 函数呼び出し構文による配列の検索」を組み合わせたもの)

3.11.2 配列

3.11.2.1 配列構築子

定義: 配列 (array) は函数であり、(正の整数で表した) 位置に値を対応づける。】 配列の最初の位置は整数1で表す。【定義: 配列の値をメンバー (member) という。】 型階層において、配列は他と異なる、函数から派生した型に属する。配列に原子化を施すとシーケンスが得られる (原子化を参照)。

配列はArrayConstructorを使って生成する。

[73]    ArrayConstructor    ::=    SquareArrayConstructor | CurlyArrayConstructor
[74]    SquareArrayConstructor    ::=    "[" (ExprSingle ("," ExprSingle)*)? "]"
[75]    CurlyArrayConstructor    ::=    "array" EnclosedExpr

配列のメンバーがノードである場合、そのノードIDは保存される。ArrayConstructorのどちらの形でも、メンバーの式を評価した結果がノードであれば、対応する値はノード自身であって、同じ値のノードを新たに生成する必要はない。メンバーの式を評価した結果がマップまたは配列である場合、その値は、同じ値を持つ新しいマップや配列である。

SquareArrayConstructorは、引数式をカンマで区切った集合として表す。これが返す配列は、各メンバーが、対応する引数式の値を含むものになる。

例:

  • [ 1, 2, 5, 7 ] は、4つのメンバー1257から成る配列を生成する。

  • [ (), (27, 17, 0)] は、2つのメンバーから成る配列を生成する。そのメンバーは、() と、シーケンス (27, 17, 0) である。

  • [ $x, local:items(), <tautology>It is what it is.</tautology> ] は、$xの値、函数呼び出しを評価した結果、tautology要素という、3つのメンバーから成る配列を生成する。

CurlyArrayConstructorは、任意の式を使ってメンバーを生成するために使う。オペランドの式を評価してアイテムのシーケンスを取得し、そのアイテムをメンバーとする配列を生成する。SquareArrayConstructorと違い、CurlyArrayConstructorのカンマは区切り文字でなくカンマ演算子である。

例:

  • array { $x } は、$xが束縛されたシーケンスの、各アイテムをメンバーとする配列を生成する。

  • array { local:items() } は、local:items() を評価して得られるシーケンスの、各アイテムをメンバーとする配列を生成する。

  • array { 1, 2, 5, 7 } は、1257という4つのメンバーから成る配列を生成する。

  • array { (), (27, 17, 0) } は、27170という3つのメンバーから成る配列を生成する。

  • array{ $x, local:items(), <tautology>It is what it is.</tautology> } は、$xが束縛されたアイテム群、それに続いてlocal:items() を評価して得られるアイテム群、続いてtautology要素、というメンバーから成る配列を生成する。

註記:

XPath 3.1には疎配列がない。整数をキーとするマップを使えば、疎配列を表現できる。例: map { 27 : -1, 153 : 17 }

3.11.2.2 函数呼び出し構文による配列の検索

配列は函数であり、函数呼び出しによって、配列の位置に対応する値を検索できる。$arrayが配列、$indexが配列の位置を表す整数とすると、「$array($key)」は「array:get($array, $key)」と同等である。この函数の意味は、「17.3.2 array:getFO31」に定義がある。

例:

  • [ 1, 2, 5, 7 ](4)」を評価すると7が得られる。

  • [ [1, 2, 3], [4, 5, 6]](2)」を評価すると [4, 5, 6] が得られる。

  • [ [1, 2, 3], [4, 5, 6]](2)(2)」を評価すると5が得られる。

  • [ 'a', 123, <name>Robert Johnson</name> ](3)」を評価すると <name>Robert Johnson</name> が得られる。

  • array { (), (27, 17, 0) }(1)」を評価すると27が得られる。

  • array { (), (27, 17, 0) }(2)」を評価すると17が得られる。

  • array { "licorice", "ginger" }(20)」を評価しようとすると動的エラー [err:FOAY0001]FO31 が発生する。

註記:

XPath 3.1には、マップや配列を検索する、より簡潔な構文もある。ワイルドカードが使え、常にマップや配列のシーケンス全体にわたって検索できる。詳しくは「3.11.3 マップおよび配列の検索演算子 ("?")」を参照。

3.11.3 マップおよび配列の検索演算子 ("?")

XPath 3.1にはマップや配列を対象とする検索演算子があり、状況にもよるが、かなり使いやすくなっている。マップのキーとして単純文字列、配列のキーとして整数を用いる場合に簡潔な構文が使え、ワイルドカードにも対応し、マップや配列のシーケンス全体にわたって反復することも可能である。

3.11.3.1 単項の検索
[76]    UnaryLookup    ::=    "?" KeySpecifier
[54]    KeySpecifier    ::=    NCName | IntegerLiteral | ParenthesizedExpr | "*"

単項の検索演算子は、述語に使う (例: $map[?name='Mike']) か、または単純マップ演算子と組み合わせて使う (例: $maps ! ?name='Mike')。後置の検索演算子については「3.11.3.2 後置の検索」を参照。

UnaryLookupは、文脈アイテムから選択した値のシーケンスを返す。文脈アイテムは、マップまたは配列でなければならず、そうでなければ型エラー [err:XPTY0004] になる。

文脈アイテムがマップの場合、次のようになる。

  1. KeySpecifierNCNameであれば、UnaryLookup演算子は「.(KS)」と同等である。ただし、KSNCNameの値とする。

  2. KeySpecifierIntegerLiteralであれば、UnaryLookup演算子は「.(KS)」と同等である。ただし、KSIntegerLiteralの値とする。

  3. KeySpecifierParenthesizedExprであれば、UnaryLookup演算子は次の式と同等である。ただし、KSParenthesizedExprの値とする。

    for $k in fn:data(KS)
    return .($k)  
    
  4. KeySpecifierがワイルドカード (「*」) であれば、UnaryLookupは次の式と同等である。

    for $k in map:keys(.)
    return .($k)
    

    註記:

    map:keys() が返すキーの順序は実装依存である。したがって、結果として得られる値の順序も実装依存である。

文脈アイテムが配列の場合、次のようになる。

  1. KeySpecifierIntegerLiteralであれば、UnaryLookup演算子は「.(KS)」と同等である。ただし、KSIntegerLiteralの値とする。

  2. KeySpecifierNCNameであれば、UnaryLookup演算子は型エラー [err:XPTY0004] になる。

  3. KeySpecifierParenthesizedExprであれば、UnaryLookup演算子は次の式と同等である。ただし、KSParenthesizedExprの値とする。

    for $k in fn:data(KS)
    return .($k)  
    
  4. KeySpecifierがワイルドカード (「*」) であれば、UnaryLookupは次の式と同等である。

    for $k in 1 to array:size(.)
    return .($k)
    

    註記:

    配列のアイテムは、その順序どおりに返される。

例:

  • ?name」は「.("name")」と同等で、マップの検索に当たる。

  • ?2」は「.(2)」と同等で、配列、または整数をキーとするマップの検索に当たる。

  • ?($a)」は「for $k in $a return .($k)」と同等で、配列またはマップのキーを変数で与えることができる。

  • ?(2 to 4)」は「for $k in (2,3,4) return .($k)」と同等で、配列からある値の範囲を取り出す場合に便利な書き方である。

  • ?(3.5)」は、文脈アイテムが配列の場合、型エラーになる。パラメーターは整数でなければならない。

  • ([1,2,3], [1,2,5], [1,2])[?3 = 5]」はエラーになる。シーケンス中のアイテムのひとつに対する「?3」がエラーになるからである。

  • $mが「3.11.1 マップ」で示したweekdaysマップに束縛されているとすると、「$m?*」は値「("Sunday","Monday","Tuesday","Wednesday", "Thursday", "Friday","Saturday")」を、実装依存の順序で返す。

  • [1, 2, 5, 7]?*」を評価すると (1, 2, 5, 7) となる。

  • [[1, 2, 3], [4, 5, 6]]?*」を評価すると ([1, 2, 3], [4, 5, 6]) となる。

3.11.3.2 後置の検索
[53]    Lookup    ::=    "?" KeySpecifier

後置の検索式の意味は、KeySpecifierの形式に応じて次のようになる。

  • KeySpecifierNCNameIntegerLiteralWildcard (「*」) のいずれかであれば、式「E?S」は「E!?S」と同等である (後置の検索演算子の意味を、単項の検索演算子の言葉で定義している)。

  • KeySpecifierParenthesizedExprであれば、式「E?(S)」は次の式と同等である。

    for $e in E, $s in fn:data(S) return $e($s)

    註記:

    Sを評価する際のフォーカスは、Lookup式自身のフォーカスと同じである。

例:

  • map { "first" : "Jenna", "last" : "Scott" }?first を評価すると "Jenna" になる。

  • [4, 5, 6]?2 を評価すると5になる。

  • (map {"first": "Tom"}, map {"first": "Dick"}, map {"first": "Harry"})?first を評価すると、シーケンス ("Tom", "Dick", "Harry") が得られる。

  • ([1,2,3], [4,5,6])?2 を評価すると、シーケンス (2, 5) が得られる。

  • ["a","b"]?3 を評価すると動的エラー [err:FOAY0001]FO31 が発生する。

3.12 条件分岐式

XPath 3.1では、キーワードifthenelseを使って、条件分岐式を記述できる。

[15]    IfExpr    ::=    "if" "(" Expr ")" "then" ExprSingle "else" ExprSingle

キーワードifに続く式をテスト式thenおよびelseに続く式をそれぞれthen式else式と呼ぶ。

条件分岐式の評価ではまず、テスト式の実効ブール値 (「2.4.3 実効ブール値」を参照) を求める。

条件分岐式の値を次のように定義する。すなわち、テスト式の実効ブール値がtrueであれば、then式の値を返し、falseであれば、else式の値を返す。

条件分岐式には、動的エラーの伝搬に関して特別な規則がある。テスト式の実効ブール値がtrueであれば、else式に動的エラーが生じても無視する (エラーとしない)。この場合、else式には外から分かるような効果が何もないので、評価する必要はない。同様に、テスト式の実効ブール値がfalseであれば、then式に動的エラーが生じても無視する。then式を評価する必要はない。

条件分岐式の例をいくつか示す。

  • この例で、テスト式は比較演算式である。

    if ($widget1/unit-cost < $widget2/unit-cost)
      then $widget1
      else $widget2
  • この例のテスト式は、discountedという属性の有無を調べる。値にはよらない。

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

3.13 量化式

量化式は存在命題と全称命題を扱う。量化式の値は常に、trueまたはfalseである。

[14]    QuantifiedExpr    ::=    ("some" | "every") "$" VarName "in" ExprSingle ("," "$" VarName "in" ExprSingle)* "satisfies" ExprSingle

量化式量化子 (キーワードsomeまたはevery) で始まり、その後に変数を束縛するいくつかのin節が続く。その後に、キーワードsatisfiesとテスト式がある。それぞれのin節は、変数を、アイテムのシーケンスを返す式と対応づける。これを、変数をシーケンスに束縛する、という。in節は、対応する変数を束縛するシーケンスに含まれる、変数の組み合わせごとに、変数束縛のタプルを生成する。概念的には、変数束縛の各タブルに対して、テスト式を評価することになる。その結果は、テスト式の実効ブール値 (「2.4.3 実効ブール値」を参照) によって決まる。量化式の値を、次の規則で定義する。

  1. 量化子がsomeの場合、量化式がtrueになるのは、テスト式を評価した実効ブール値trueであるものが、少なくとも1つある場合である。そうでなければ量化式の値はfalseである。この規則の帰結として、in節が生成する束縛タプルが0個の場合、量化式の値はfalseとなる。

  2. 量化式がeveryの場合、量化式がtrueになるのは、テスト式を評価した実効ブール値がすべてtrueの場合である。そうでなければ量化式の値はfalseである。この規則の帰結として、in節が生成する束縛タプルが0個の場合、量化式の値はtrueとなる。

量化式に束縛された変数のスコープは、変数束縛の後に現れる量化式の部分式全体にわたる。ただし、変数が束縛される式そのものは含まれない。

束縛タプルに対してテスト式を評価する順序は実装依存である。量化子がsomeの場合、テスト式の実効ブール値trueであるような束縛タプルがひとつ見つかった時点で、ただちにtrueを返し、テスト式がエラーになるような束縛タプルがひとつ見つかった時点で、ただちに動的エラーとするように実装してもよい。同様に、量化子がeveryの場合、テスト式の実効ブール値falseであるような束縛タプルがひとつ見つかった時点で、ただちにfalseを返し、テスト式がエラーになるような束縛タプルがひとつ見つかった時点で、ただちに動的エラーとするように実装してもよい。この規則の帰結として、量化式の値は、以下の例に示すように、エラーの有無に関して決定性ではない。

量化式の例をいくつか示す。

  • この式がtrueになるのは、part要素すべてにdiscounted属性がある場合である (属性の値にはよらない)。

    every $part in /parts/part satisfies $part/@discounted
  • この式がtrueになるのは、比較演算式を満たすemployee要素が、少なくとも1つある場合である。

    some $emp in /emps/employee satisfies
         ($emp/bonus > 0.25 * $emp/salary)
  • 次の例で、それぞれの量化式は、変数束縛の9つのタプルにわたってテスト式を評価する。シーケンス (1, 2, 3) および (2, 3, 4) のカルテシアン積にもとづく変数束縛である。量化子someで始まる式はtrue、量化子everyで始まる式は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
  • この量化式は、trueを返すか、または型エラーになる。テスト式がtrueを返す変数束縛と、型エラーになる変数束縛があるからである。

    some $x in (1, 2, "cat") satisfies $x * 2 = 4
  • この量化式は、falseを返すか、または型エラーになる。テスト式がfalseを返す変数束縛と、型エラーになる変数束縛があるからである。

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

3.14 SequenceTypeを対象とする式

instance ofcastcastabletreatの各式は、値が指定された型に当てはまるか、指定された型のインスタンスに変換できるか、を調べるために用いる。

3.14.1 instance of

[25]    InstanceofExpr    ::=    TreatExpr ( "instance" "of" SequenceType )?

ブール演算子instance oftrueを返すのは、第1オペランドが、「SequenceTypeの照合」規則に照らして、第2オペランドのSequenceTypeに合致する場合である。そうでなければfalseを返す。いくつか例を挙げる。

  • 5 instance of xs:integer

    この例はtrueを返す。与えられた値が、与えられた型のインスタンスだからである。

  • 5 instance of xs:decimal

    この例はtrueを返す。与えられた値は整数リテラルであり、xs:integerxs:decimalを制限した派生型だからである。

  • (5, 6) instance of xs:integer+

    この例はtrueを返す。与えられたシーケンスには2つの整数から成り、これは指定された型のインスタンスだからである。

  • . instance of element()

    この例は、文脈アイテムが要素ノードならばtrue、文脈アイテムが定まるけれども要素ノードではない場合はfalseを返す。文脈アイテムが欠落DM31している場合は動的エラー [err:XPDY0002] が発生する。

3.14.2 cast

[28]    CastExpr    ::=    ArrowExpr ( "cast" "as" SingleType )?
[77]    SingleType    ::=    SimpleTypeName "?"?

ある値を別のデータ型に変換する必要が生じることがある。この目的で、XPath 3.1にはcast式があり、既存の値にもとづいて、指定した型の値を新たに生成できるようになっている。cast式には、入力式対象型という2つのオペランドがある。入力式の原子値の型を入力型という。SimpleTypeNameは、スコープ内スキーマ型に定義された、単純型の名前でなければならない [err:XQST0052]。さらに、対象型がxs:NOTATIONxs:anySimpleTypexs:anyAtomicTypeであってはならない [err:XPST0080]。出現数標識「?」がついていれば、空シーケンスも許容する。対象型が名前空間接頭辞のない字句規則上のQNameであれば、既定の要素/型名前空間に属するものと看做す。

ノードをxs:QNameにキャストした結果は、意外に思われるかも知れない。キャスト式の静的文脈を使って、この演算の名前空間を束縛するからである。通常は、xs:QNameにキャストするのではなく、fn:QName函数を使うとよい。この函数は名前空間文脈を、QNameが含まれる文書から取得する。

cast式の意味は次のとおりである。

  1. 入力式を評価する。

  2. 第1ステップの結果を原子化する。

  3. 原子化の結果が、複数の原子値から成るシーケンスであれば、型エラー [err:XPTY0004] とする。

  4. 原子化の結果が空シーケンスの場合:

    1. 対象型の後に「?」の指定があれば、cast式の結果は空シーケンスである。

    2. 対象型の後に「?」の指定がなければ、型エラー [err:XPTY0004] とする。

  5. 原子化の結果が単一の原子値であれば、キャスト式の結果は、「19 キャストFO31」に従って、対象型にキャストすることにより得られる。キャストの際、ある型が別の型を制限することにより派生したものかどうか、判断する必要が生じるかも知れない。これを、スコープ内スキーマ定義を検査して判断するように実装しても、データ辞書など、実装依存の機構を使うように実装してもよい。キャスト式の結果は次のいずれかである。

    1. 対象型の値 (リスト型の場合は、そのアイテム型のインスタンスである値のシーケンス)。

    2. 型エラー。元の型から対象型にキャストできない場合 (整数から日付への変換など)。

    3. 動的エラー。入力値を対象型に変換できない場合 (文字列 "three" から整数への変換など)。

3.14.3 castable

[27]    CastableExpr    ::=    CastExpr ( "castable" "as" SingleType )?
[77]    SingleType    ::=    SimpleTypeName "?"?

XPath 3.1には、ある値をある対象型にキャストできるか否か、テストする式がある。SimpleTypeNameは、スコープ内スキーマ型に定義された、単純型の名前でなければならない [err:XQST0052]。さらに、対象型がxs:NOTATIONxs:anySimpleTypexs:anyAtomicTypeであってはならない [err:XPST0080]。出現数標識「?」がついていれば、空シーケンスも許容する。

式「E castable as T」がtrueを返すのは、Eを評価した結果を、cast式で対象型Tにキャストできる場合である。そうでなければfalseを返す。Eを評価したとき動的エラーが発生する、あるいはEの値を原子化できない場合、castable式は全体として失敗する。castable式を述語として用れば、評価時のエラーを回避できる。また、次の例のように、与えられた値の処理に適した型を選択するために使うこともできる。

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

3.14.4 構築子函数

スコープ内スキーマ型の各単純型 (xs:NOTATIONxs:anyAtomicTypexs:anySimpleTypeを除く) には、暗黙に、構築子函数が定義されている。いずれの場合も、構築子函数の名前は、対象型の名前 (名前空間を含む) と同じである。構築子函数のシグニチャーは、構築する型に依存して決まり、「18 構築子函数FO31」に載っている。

定義: ある型の構築子函数 (constructor function) は、他の単純型のインスタンスを、その型に変換するために使う。構築子函数呼び出し T($arg) の意味は、式 (($arg) cast as T?) と同等である。】

構築子函数を使う例をいくつか示す。

  • この例は ("2000-01-01" cast as xs:date?) と同等である。

    xs:date("2000-01-01")
  • この例は (($floatvalue * 0.2E-5) cast as xs:decimal?) と同等である。

    xs:decimal($floatvalue * 0.2E-5)
  • この例は「21日」に相当するxs:dayTimeDurationの値を返し、("P21D" cast as xs:dayTimeDuration?) と同等である。

    xs:dayTimeDuration("P21D")
  • usa:zipcodeスコープ内スキーマ型にあるユーザー定義の原子型であれば、次の式は、式 ("12345" cast as usa:zipcode?) と同等である。

    usa:zipcode("12345")

註記:

名前空間内にない原子型のインスタンスは、URIQualifiedNameを使って、cast式でも構築子函数呼び出しでも構築できる。たとえば次のようになる。

17 cast as Q{}apple
Q{}apple(17)

基底の要素/型名前空間が欠落している場合、QNameの構文も使える。たとえば次のようになる。

17 cast as apple
apple(17)

3.14.5 treat

[26]    TreatExpr    ::=    CastableExpr ( "treat" "as" SequenceType )?

XPath 3.1には、オペランドの静的型を変更する、treatという式がある。

castと同様、treat式も2つのオペランドを取る。式とSequenceTypeである。一方、castとは違って、treatがオペランドの動的型や値を変えることはない。treatの目的は、式の評価時に、想定する動的型になるようにすることである。

expr1 treat as type1」の意味は次のとおりである。

  • 静的解析中:

    treat式の静的型type1である。これにより、type1型のパラメーターを想定した函数の引数として、式を使えることになる。

  • 式の評価中:

    expr1type1に合致する場合、treat式は、「SequenceTypeの照合」規則に従ってexpr1の値を返す。そうでなければ動的エラー [err:XPDY0050] が発生する。expr1の値が返される場合、値に含まれるノードのIDはそのまま保存する。treat式を使えば、式オペランドの値が、実行時、想定する型になることが保証される。

  • 例:

    $myaddress treat as element(*, USAddress)

    $myaddress静的型element(*, Address) であって、element(*, USAddress) より抽象度の高い型であることも考えられる。しかし、実行時、$myaddressの値は、「SequenceTypeの照合」規則に照らして型 element(*, USAddress) に合致しなければならない。そうでなければ動的エラー [err:XPDY0050] が発生してしまう。

3.15 単純マップ演算子 (!)

[35]    SimpleMapExpr    ::=    PathExpr ("!" PathExpr)*

マップ式「S!E」は、Sを評価して得られるシーケンスのアイテムごとに、式Eを評価することを表す。単純マップ演算子「!」は任意のシーケンスに適用でき、そのアイテムの型にはよらない。さらに、ノード、原子値、函数が混在したシーケンスにも適用できる。よく似た「/」演算子と違って、ノードを文書型に整列し、重複を除去する処理はおこなわない。

式「E1!E2」は次のように評価する: まず、式E1を評価してシーケンスSを得る。次いで、Sの各アイテムを内部フォーカスに与え (このアイテムを文脈アイテム、Sにおける位置を文脈位置、Sの長さを文脈の長さとする)、E2をその動的文脈で評価する。E2を評価して得たシーケンスをすべて、次のように連結する: E2のアイテムそれぞれを評価すると、アイテムのシーケンス (または空シーケンス) が得られる。このシーケンスを連結して返す。このシーケンスは、E2のアイテム順や、アイテムを評価して得られたシーケンスにおけるアイテム順を保存する。

単純マップ演算子の機能は「3.3.1.1 3.3.1.1 パス演算子 (/)」に似ている。この2つの演算子の違いを表にまとめておく。

Operator Path operator (E1 / E2) Simple map operator (E1 ! E2)
E1 Any sequence of nodes Any sequence of items
E2 Either a sequence of nodes or a sequence of non-node items A sequence of items
Additional processing Duplicate elimination and document ordering Simple sequence concatenation

単純マップ演算子をパス式と組み合わせて使う例をいくつか示す。

  • child::div1 / child::para / string() ! concat("id-", .)

    文脈ノードの子であるdiv1要素の、さらに子であるpara要素を選択する。すなわち、文脈ノードの孫であるpara要素で、その親がdiv1要素のものである。次に、この孫要素の文字列値を連結し、"id-"を前置した文字列を出力する。

  • $emp ! (@first, @middle, @last)

    要素$empの属性firstmiddlelastの値を、指定された順に並べて返す (ここで「/」演算子を使った場合、属性の順序は不定)。

  • $docs ! ( //employee)

    変数 docs で表される文書全体から従業員をすべて抜き出して返す。それぞれの文書内では文書順になるが、文書どうしの順序はそのまま保存する。

  • avg( //employee / salary ! translate(., '$', '') ! number(.))

    従業員の平均給与額を数値に変換して返す。変換はあらかじめ「$」記号を除去してからおこなう (2つめの「!」を「/」にすることはできない。「/」の左辺オペランドを原子値にすることはできないからである)。

  • fn:string-join((1 to $n)!"*")

    $n個のアスタリスクから成る文字列を返す。

  • $values!(.*.) => fn:sum()

    数値列の二乗和を返す。

  • string-join(ancestor::*!name(), '/')

    要素の祖先の名前を「/」区切りで表したパスを返す。

3.16 矢印演算子 (=>)

[29]    ArrowExpr    ::=    UnaryExpr ( "=>" ArrowFunctionSpecifier ArgumentList )*
[55]    ArrowFunctionSpecifier    ::=    EQName | VarRef | ParenthesizedExpr

定義: 矢印演算子 (arrow operator) は、函数を式の値に適用する。ただし、その値が函数の第1引数になる。】 UUnaryExprFArrowFunctionSpecifier(A, B, C...)ArgumentListとすると、式「U => F(A, B, C...)」は式「F(U, A, B, C...)」と同等である。

この構文は特に、ある値に対して複数の函数を順次適用する場合に有用である。たとえば次の式は、括弧の位置を間違える構文エラーが起こりやすい:

tokenize((normalize-unicode(upper-case($string))),"\s+")

これを次のように書き替えると、照応する括弧が分かりやすくなる。

$string => upper-case() => normalize-unicode() => tokenize("\s+")

4 適合性

この章ではXPath 3.1の処理系の適合性に関する規準を定義する。この章で次の用語は、【RFC2119] で定義された要件レベルを示すために用いるものとする。[定義: MUST (しなければならない) は、当該事項が、絶対に満たすべき、仕様上の要件であることを意味する。】 【定義: MUST NOT (してはならない) は、当該事項が、絶対に避けるべき、仕様上の要件であることを意味する。】 【定義: MAY (してもよい) は、当該事項が真に任意であることを意味する。】

XPathは主として、他の仕様が部品として使うことを意図している。したがって、XPathを利用する仕様 ([XPointer][XSL Transformations (XSLT) Version 3.0] など) に依存する形で、その環境における適合性の規準が決まる。XPathを利用するための、適合性の規準を決めることになる仕様が、本仕様で与える、XPathの構文や意味に関する定義を変えてはならない (MUST NOT)。ただし、一部を抜き出すこと、あるいは互換性を保ちながら拡張することを除く。

ある言語をXPathの拡張として記述する場合、XPathの文法に適合する式はすべて、本仕様に記述しているように挙動しなければならない (MUST)。

4.1 静的型検査機能

定義: 静的型検査機能 (Static Typing Feature) はXPathのオプション機能で、静的な意味の取り扱いに関係する。静的解析フェーズで、型エラーを検出、報告する仕組みの実装を要する。】 XPathを利用する仕様は、静的型検査機能の利用に関して、適合性の規準を指定してもよい (MAY)。

静的型検査機能に対応しない実装であっても、評価すると必然的に動的エラーが発生するXPath式、評価すると必然的に型エラーが発生する式を、静的解析フェーズで判定できるのであれば、静的解析フェーズの間に当該エラーを発生させてもよい (MAY)。このようなエラーを解析時に発生させるか否かは実装依存である。

A XPath 3.1の文法

A.1 EBNF

XPath 3.1の文法記述には、[XML 1.0] と同じ拡張Backus-Naur記法 (Extended Backus-Naur Form、EBNF) を使う。ただし次の点が異なる。

  • 名前付き記号の名前はすべて大文字で始まる。

  • 他の仕様で規定している事項を参照する記法がある。

  • 註記、文法上の特別な制約を、「/*」と「*/」で囲んで記述する。

    • 「xgc:」という接頭辞は文法上の特別な制約 (extra-grammatical constraint) を表す。制約の詳細は「A.1.2 文法上の特別な制約」で説明する。

    • 「ws:」という接頭辞は空白類に関する規則 (whitespace rules) を表す。詳しくは「A.2.4 空白類に関する規則」で説明する。

    • 「gn:」という接頭辞は「Grammar Note」を表し、構文解析の規則を明確にするのが目的である。詳しくは「A.1.3 文法に関する註記」で説明する。これは規準の一部ではない。

この文法の終端記号としては、以下の構文規則に引用符で囲んだ文字列として現れるものと、「A.2.1 終端記号」で定義するものがある。

EBNF記法については「A.1.1 記法」で説明する。

[1]    XPath    ::=    Expr
[2]    ParamList    ::=    Param ("," Param)*
[3]    Param    ::=    "$" EQName TypeDeclaration?
[4]    FunctionBody    ::=    EnclosedExpr
[5]    EnclosedExpr    ::=    "{" Expr? "}"
[6]    Expr    ::=    ExprSingle ("," ExprSingle)*
[7]    ExprSingle    ::=    ForExpr
| LetExpr
| QuantifiedExpr
| IfExpr
| OrExpr
[8]    ForExpr    ::=    SimpleForClause "return" ExprSingle
[9]    SimpleForClause    ::=    "for" SimpleForBinding ("," SimpleForBinding)*
[10]    SimpleForBinding    ::=    "$" VarName "in" ExprSingle
[11]    LetExpr    ::=    SimpleLetClause "return" ExprSingle
[12]    SimpleLetClause    ::=    "let" SimpleLetBinding ("," SimpleLetBinding)*
[13]    SimpleLetBinding    ::=    "$" VarName ":=" ExprSingle
[14]    QuantifiedExpr    ::=    ("some" | "every") "$" VarName "in" ExprSingle ("," "$" VarName "in" ExprSingle)* "satisfies" ExprSingle
[15]    IfExpr    ::=    "if" "(" Expr ")" "then" ExprSingle "else" ExprSingle
[16]    OrExpr    ::=    AndExpr ( "or" AndExpr )*
[17]    AndExpr    ::=    ComparisonExpr ( "and" ComparisonExpr )*
[18]    ComparisonExpr    ::=    StringConcatExpr ( (ValueComp
| GeneralComp
| NodeComp) StringConcatExpr )?
[19]    StringConcatExpr    ::=    RangeExpr ( "||" RangeExpr )*
[20]    RangeExpr    ::=    AdditiveExpr ( "to" AdditiveExpr )?
[21]    AdditiveExpr    ::=    MultiplicativeExpr ( ("+" | "-") MultiplicativeExpr )*
[22]    MultiplicativeExpr    ::=    UnionExpr ( ("*" | "div" | "idiv" | "mod") UnionExpr )*
[23]    UnionExpr    ::=    IntersectExceptExpr ( ("union" | "|") IntersectExceptExpr )*
[24]    IntersectExceptExpr    ::=    InstanceofExpr ( ("intersect" | "except") InstanceofExpr )*
[25]    InstanceofExpr    ::=    TreatExpr ( "instance" "of" SequenceType )?
[26]    TreatExpr    ::=    CastableExpr ( "treat" "as" SequenceType )?
[27]    CastableExpr    ::=    CastExpr ( "castable" "as" SingleType )?
[28]    CastExpr    ::=    ArrowExpr ( "cast" "as" SingleType )?
[29]    ArrowExpr    ::=    UnaryExpr ( "=>" ArrowFunctionSpecifier ArgumentList )*
[30]    UnaryExpr    ::=    ("-" | "+")* ValueExpr
[31]    ValueExpr    ::=    SimpleMapExpr
[32]    GeneralComp    ::=    "=" | "!=" | "<" | "<=" | ">" | ">="
[33]    ValueComp    ::=    "eq" | "ne" | "lt" | "le" | "gt" | "ge"
[34]    NodeComp    ::=    "is" | "<<" | ">>"
[35]    SimpleMapExpr    ::=    PathExpr ("!" PathExpr)*
[36]    PathExpr    ::=    ("/" RelativePathExpr?)
| ("//" RelativePathExpr)
| RelativePathExpr
/* xgc: leading-lone-slash */
[37]    RelativePathExpr    ::=    StepExpr (("/" | "//") StepExpr)*
[38]    StepExpr    ::=    PostfixExpr | AxisStep
[39]    AxisStep    ::=    (ReverseStep | ForwardStep) PredicateList
[40]    ForwardStep    ::=    (ForwardAxis NodeTest) | AbbrevForwardStep
[41]    ForwardAxis    ::=    ("child" "::")
| ("descendant" "::")
| ("attribute" "::")
| ("self" "::")
| ("descendant-or-self" "::")
| ("following-sibling" "::")
| ("following" "::")
| ("namespace" "::")
[42]    AbbrevForwardStep    ::=    "@"? NodeTest
[43]    ReverseStep    ::=    (ReverseAxis NodeTest) | AbbrevReverseStep
[44]    ReverseAxis    ::=    ("parent" "::")
| ("ancestor" "::")
| ("preceding-sibling" "::")
| ("preceding" "::")
| ("ancestor-or-self" "::")
[45]    AbbrevReverseStep    ::=    ".."
[46]    NodeTest    ::=    KindTest | NameTest
[47]    NameTest    ::=    EQName | Wildcard
[48]    Wildcard    ::=    "*"
| (NCName ":*")
| ("*:" NCName)
| (BracedURILiteral "*")
/* ws: explicit */
[49]    PostfixExpr    ::=    PrimaryExpr (Predicate | ArgumentList | Lookup)*
[50]    ArgumentList    ::=    "(" (Argument ("," Argument)*)? ")"
[51]    PredicateList    ::=    Predicate*
[52]    Predicate    ::=    "[" Expr "]"
[53]    Lookup    ::=    "?" KeySpecifier
[54]    KeySpecifier    ::=    NCName | IntegerLiteral | ParenthesizedExpr | "*"
[55]    ArrowFunctionSpecifier    ::=    EQName | VarRef | ParenthesizedExpr
[56]    PrimaryExpr    ::=    Literal
| VarRef
| ParenthesizedExpr
| ContextItemExpr
| FunctionCall
| FunctionItemExpr
| MapConstructor
| ArrayConstructor
| UnaryLookup
[57]    Literal    ::=    NumericLiteral | StringLiteral
[58]    NumericLiteral    ::=    IntegerLiteral | DecimalLiteral | DoubleLiteral
[59]    VarRef    ::=    "$" VarName
[60]    VarName    ::=    EQName
[61]    ParenthesizedExpr    ::=    "(" Expr? ")"
[62]    ContextItemExpr    ::=    "."
[63]    FunctionCall    ::=    EQName ArgumentList /* xgc: reserved-function-names */
/* gn: parens */
[64]    Argument    ::=    ExprSingle | ArgumentPlaceholder
[65]    ArgumentPlaceholder    ::=    "?"
[66]    FunctionItemExpr    ::=    NamedFunctionRef | InlineFunctionExpr
[67]    NamedFunctionRef    ::=    EQName "#" IntegerLiteral /* xgc: reserved-function-names */
[68]    InlineFunctionExpr    ::=    "function" "(" ParamList? ")" ("as" SequenceType)? FunctionBody
[69]    MapConstructor    ::=    "map" "{" (MapConstructorEntry ("," MapConstructorEntry)*)? "}"
[70]    MapConstructorEntry    ::=    MapKeyExpr ":" MapValueExpr
[71]    MapKeyExpr    ::=    ExprSingle
[72]    MapValueExpr    ::=    ExprSingle
[73]    ArrayConstructor    ::=    SquareArrayConstructor | CurlyArrayConstructor
[74]    SquareArrayConstructor    ::=    "[" (ExprSingle ("," ExprSingle)*)? "]"
[75]    CurlyArrayConstructor    ::=    "array" EnclosedExpr
[76]    UnaryLookup    ::=    "?" KeySpecifier
[77]    SingleType    ::=    SimpleTypeName "?"?
[78]    TypeDeclaration    ::=    "as" SequenceType
[79]    SequenceType    ::=    ("empty-sequence" "(" ")")
| (ItemType OccurrenceIndicator?)
[80]    OccurrenceIndicator    ::=    "?" | "*" | "+" /* xgc: occurrence-indicators */
[81]    ItemType    ::=    KindTest | ("item" "(" ")") | FunctionTest | MapTest | ArrayTest | AtomicOrUnionType | ParenthesizedItemType
[82]    AtomicOrUnionType    ::=    EQName
[83]    KindTest    ::=    DocumentTest
| ElementTest
| AttributeTest
| SchemaElementTest
| SchemaAttributeTest
| PITest
| CommentTest
| TextTest
| NamespaceNodeTest
| AnyKindTest
[84]    AnyKindTest    ::=    "node" "(" ")"
[85]    DocumentTest    ::=    "document-node" "(" (ElementTest | SchemaElementTest)? ")"
[86]    TextTest    ::=    "text" "(" ")"
[87]    CommentTest    ::=    "comment" "(" ")"
[88]    NamespaceNodeTest    ::=    "namespace-node" "(" ")"
[89]    PITest    ::=    "processing-instruction" "(" (NCName | StringLiteral)? ")"
[90]    AttributeTest    ::=    "attribute" "(" (AttribNameOrWildcard ("," TypeName)?)? ")"
[91]    AttribNameOrWildcard    ::=    AttributeName | "*"
[92]    SchemaAttributeTest    ::=    "schema-attribute" "(" AttributeDeclaration ")"
[93]    AttributeDeclaration    ::=    AttributeName
[94]    ElementTest    ::=    "element" "(" (ElementNameOrWildcard ("," TypeName "?"?)?)? ")"
[95]    ElementNameOrWildcard    ::=    ElementName | "*"
[96]    SchemaElementTest    ::=    "schema-element" "(" ElementDeclaration ")"
[97]    ElementDeclaration    ::=    ElementName
[98]    AttributeName    ::=    EQName
[99]    ElementName    ::=    EQName
[100]    SimpleTypeName    ::=    TypeName
[101]    TypeName    ::=    EQName
[102]    FunctionTest    ::=    AnyFunctionTest
| TypedFunctionTest
[103]    AnyFunctionTest    ::=    "function" "(" "*" ")"
[104]    TypedFunctionTest    ::=    "function" "(" (SequenceType ("," SequenceType)*)? ")" "as" SequenceType
[105]    MapTest    ::=    AnyMapTest | TypedMapTest
[106]    AnyMapTest    ::=    "map" "(" "*" ")"
[107]    TypedMapTest    ::=    "map" "(" AtomicOrUnionType "," SequenceType ")"
[108]    ArrayTest    ::=    AnyArrayTest | TypedArrayTest
[109]    AnyArrayTest    ::=    "array" "(" "*" ")"
[110]    TypedArrayTest    ::=    "array" "(" SequenceType ")"
[111]    ParenthesizedItemType    ::=    "(" ItemType ")"
[112]    EQName    ::=    QName | URIQualifiedName

A.1.1 記法

定義: 文法の各規則は、次のような形式でひとつの記号 (symbol) を定義する。

symbol ::= expression

定義: 終端記号 (terminal) は、規則の右側に現れる記号、文字列、パターンのうち、主たる文法規則の左側には現れないものである。ただし、終端記号の文法規則の左側には現れてもよい。】 以下の記法を使って、1字以上の文字から成る文字列を、終端記号と照合する規則を記述する。

[a-zA-Z]

角括弧内に示されている範囲の文字に合致する (範囲の左端と右端に当たる文字も含む)。

[abc]

角括弧内に列挙されている、いずれかの文字に合致する。

[^abc]

角括弧内に列挙されているものを除く、いずれかの文字に合致する。

"string"

二重引用符に囲まれている一連の文字に、その順序も含めて合致する。

'string'

一重引用符に囲まれている一連の文字に、その順序も含めて合致する。

[http://www.w3.org/TR/REC-example/#NT-Example]

他の仕様の、指定された参照先の規則を満たす文字列に合致する。

パターン (上記の文字列を含む) を構文記述演算子と組み合わせて、より複雑なパターンを構築し、より複雑な文字列と照合できる。以下の例で、AとBは (副) パターンを表す。

(A)

A をひとまとまりの単位として扱い、ここに例示している記法と組み合わせる。

A?

A または空と合致する。

A B

A の後に B が続くパターンと合致する。この演算子は代替演算子 (|) よりも優先度が高いので、「A B | C D」は「(A B) | (C D)」と同等である。

A | B

A または B のいずれか一方と合致する (両方とは合致しない)。

A - B

A と合致する。ただし、B と合致するものを除く。

A+

1個以上の A から成る文字列と合致する。代替演算子 (|) よりも優先度が高いので、「A+ | B+」は「(A+) | (B+)」と同等である。

A*

0個以上の A から成る文字列と合致する。代替演算子 (|) よりも優先度が高いので、「A* | B*」は「(A*) | (B*)」と同等である。

A.1.2 文法上の特別な制約

EBNFで表した構文規則に付け加える制約について説明する。構文的に正しい文を、正しく解析するために必要な制約である。構文規則では、規則の右側に、/* xgc: <id> */ のような形で示す。

制約: leading-lone-slash

単一のスラッシュは、これだけで完結したパス式とも、この後にRelativePathExprが続くパス式の先頭部分とも解釈できる。状況によっては、スラッシュの次の字句を見ても、この2つの可能性を識別できないことがある。「*」という字句や、「union」のようなキーワードが次に現れたとき、これが演算子か、あるいはNameTestなのか識別できないのである。たとえば「/ * 5」という式は、先読みをしなければ「/ *」だけで完全な式 (/ の子ノード) と解析してしまい、後続の構文解析に失敗する可能性がある。

スラッシュの直後の字句が、RelativePathExprの開始部分と解釈できる場合は、スラッシュを完結したパス式ではなく、PathExprの先頭部分と看做す。

単一のスラッシュを、演算子の左辺として使いたい場合は、括弧を使って「(/) * 5」のように記述しなければならない。これに対し「5 * /」は、括弧がなくても構文的に正しいことになる。

制約: xml-version

XMLおよびXML Namesの版 ([XML 1.0] および [XML Names]、または [XML 1.1] および [XML Names 1.1] を参照) は実装定義である。適用可能な最新の版を、この仕様より新しく公開されたものであっても、可能な限り使うよう推奨する。この仕様のEBNFは、1.0版としか連動していない。また、他の仕様を参照している箇所では、空白類に関する規則について、当該仕様の規則を適用する。この仕様、特に「A.2.4.1 既定の空白類処理」を適用するのではない。したがって「prefix : localname」は、この仕様に関する限り、構文的に正しい字句規則上のQNameではない。XML文書では許容されない記述だからである。同様に、コロンの左側、右側ともに、註釈を記述することはできない。なお、整形式制約など、文法上の特別な制約にも留意する必要がある。

制約: reserved-function-names

接頭辞なしの函数名で、言語のキーワードと同じ綴りのものがあると、構文解析に失敗する可能性がある。たとえば「element(foo)」は、FunctionCallElementTestの両様に解釈できる。したがって、接頭辞なしの函数名として、「A.3 函数名として使えない名前」に載っている名前は使えない。

「if」という名前の函数を呼び出すためには、その名前空間を接頭辞に束縛し、接頭辞つきの形式で、「library:if(foo)」のように記述する必要がある。単に「if(foo)」では呼び出せない。

制約: occurrence-indicators

既述のように、「A XPath 3.1の文法」に示した文法は、出現数標識「+」や「*」の解釈に曖昧さが生じることがある。これを次のように解決する。この演算子はSequenceType式と強く結びついており、他の記号との結合よりも優先度が高い。したがって、シーケンス型の直後に現れる「+」、「*」、「?」は、SequenceType中の最後のItemTypeを束縛する、出現数標識と看做して解析する。

これに従って、「4 treat as item() + - 5」は「(4 treat as item()+) - 5」と解釈する。「+」はOccurrenceIndicator、「-」は減算演算子と看做すのである。「+」を加算演算子と解釈する (これに伴い「-」は単項の負記号と解釈する) よう強制するためには、括弧を使って「(4 treat as item()) + -5」と書けばよい。SequenceTypeとして解釈するべき範囲を括弧で囲めば、想定どおりに解釈されるのである。

function () as xs:string *」は「function () as (xs:string *)」と解釈される。「(function () as xs:string) *」ではない。ただし、括弧を使えばこう解釈するよう強制できる。

この規則の帰結として、構文的に正しく、曖昧さがないように見えるものが、うまく認識されないことも生じる。「4 treat as item() + 5」という記述で、「+」は演算子でなくOccurrenceIndicator」と解釈されるので、構文的に正しい式にならない。

A.1.3 文法に関する註記

この節ではEBNFによる構文規則について、その解釈や、処理系の実装に役立つであろう事項を示す。これは規準の一部ではない。構文規則の右辺にある「/* gn: <id> */」のような記述は、以下の註記を参照している。

註記:

grammar-note: parens

FunctionCallと、EQNameまたはキーワードの後に註釈が続いている記述を識別するためには、先読みが必要である。たとえば「address (: this may be empty :)」という記述は、先読みしないと、「address」という函数の呼び出しと誤認するおそれがある。同様に「for (: whom the bell :) $tolls in 3 return $tolls」という記述でも、キーワード「for」を函数名と誤認しないようにしなければならない。

grammar-note: comments

註釈は、無視してよい空白類が許される箇所であれば、どこにでも記述できる。構文規則の右辺に、Comment記号が明示的に現れることはない (註釈そのものの構文規則を除く)。「A.2.4.1 既定の空白類処理」を参照。

註釈は入れ子にすることができる。ただし、「(:」と「:)」が対になって、外側の註釈の範囲内で完結していなければならない。

註記:

字句解析では通常、入れ子になった註釈を処理するために、「(:」の箇所でカウンターを1増やし、「:)」が見つかるとカウンターを1減らす。これが0になった位置が註釈の末尾になる。

いくつか例を示す。

  • (: commenting out a (: comment :) may be confusing, but often helpful :)」は構文的に正しいCommentである。開始記号と終了記号の対が入れ子になっている。

  • "this is just a string :)"」は構文的に正しい式である。一方、「(: "this is just a string :)" :)」は構文エラーになる。同様に、「"this is another string (:"」は構文的に正しい式であるが、「(: "this is another string (:" :)」は構文エラーである。リテラル中に開始記号や終了記号と合致する文字の並びがあると、想定どおりの対にならないのは、入れ子になった註釈に関する規則の制限事項である。

  • for (: set up loop :) $i in $x return $i」は、註釈を無視すると、構文的に正しい記述である。

  • 5 instance (: strange place for a comment :) of xs:integer」も構文的に正しい。

A.2 字句構造

前節の構文規則に出てくる終端記号について、この節で説明する。

構文規則に現れる、引用符で囲まれた文字列は、終端記号である。

それ以外の終端記号を「A.2.1 終端記号」で定義する。

構文規則の中には、XMLおよびXML Namesの仕様 ([XML 1.0] および [XML Names]、または[XML 1.1] および [XML Names 1.1]) を参照しているものがある。この仕様のどの版を使うか、ホスト言語が選択してもよいが、適用可能な最新の版を、この仕様より新しく公開されたものであっても、可能な限り使うよう推奨する。

ホスト言語は、[XML 1.0] および [XML Names] の字句規則に従うか、[XML 1.1] および [XML Names 1.1] の字句規則に従うかを選択してよい。

字句に切り分ける処理では、EBNFに適合する、できる限り長い字句を用いる。

キーワードはすべて、大文字と小文字を区別する。キーワードは、予約語ではない。したがって、字句規則上のQNameがキーワードと同じ綴りであってもよい (「A.3 函数名として使えない名前」に註記した例外を除く)。

A.2.1 終端記号

[113]    IntegerLiteral    ::=    Digits
[114]    DecimalLiteral    ::=    ("." Digits) | (Digits "." [0-9]*) /* ws: explicit */
[115]    DoubleLiteral    ::=    (("." Digits) | (Digits ("." [0-9]*)?)) [eE] [+-]? Digits /* ws: explicit */
[116]    StringLiteral    ::=    ('"' (EscapeQuot | [^"])* '"') | ("'" (EscapeApos | [^'])* "'") /* ws: explicit */
[117]    URIQualifiedName    ::=    BracedURILiteral NCName /* ws: explicit */
[118]    BracedURILiteral    ::=    "Q" "{" [^{}]* "}" /* ws: explicit */
[119]    EscapeQuot    ::=    '""'
[120]    EscapeApos    ::=    "''"
[121]    Comment    ::=    "(:" (CommentContents | Comment)* ":)" /* ws: explicit */
/* gn: comments */
[122]    QName    ::=    [http://www.w3.org/TR/REC-xml-names/#NT-QName]Names /* xgc: xml-version */
[123]    NCName    ::=    [http://www.w3.org/TR/REC-xml-names/#NT-NCName]Names /* xgc: xml-version */
[124]    Char    ::=    [http://www.w3.org/TR/REC-xml#NT-Char]XML /* xgc: xml-version */

以下の記号は、終端記号の定義にのみ使う。「A.1 EBNF」の構文規則に現れる終端記号ではない。

[125]    Digits    ::=    [0-9]+
[126]    CommentContents    ::=    (Char+ - (Char* ('(:' | ':)') Char*))

A.2.2 終端記号の区切り

XPath 3.1の式は、終端記号記号区切り文字から成る。

終端記号 (もっぱら /* ws: explicit */ で示した構文規則で明示的に使われているものを除く) には、区切りとしての働きがあるものとないものがある。

定義: 区切りとしての働きがある終端記号 (delimiting terminal symbol) として、「!」、「!=」、StringLiteral、「#」、「$」、「(」、「)」、「*」、「*:」、「+」、「,」、「-」、「.」、「..」、「/」、「//」、「:」、「:*」、「::」、「:=」、「<」、「<<」、「<=」、「=」、「=>」、「>」、「>=」、「>>」、「?」、「@」、BracedURILiteral、「[」、「]」、「{」、「|」、「||」、「}」がある。】

定義: 区切りとしての働きがない終端記号 (non-delimiting terminal symbol) として、IntegerLiteralURIQualifiedNameNCNameDecimalLiteralDoubleLiteralQName、「ancestor」、「ancestor-or-self」、「and」、「array」、「as」、「attribute」、「cast」、「castable」、「child」、「comment」、「descendant」、「descendant-or-self」、「div」、「document-node」、「element」、「else」、「empty-sequence」、「eq」、「every」、「except」、「following」、「following-sibling」、「for」、「function」、「ge」、「gt」、「idiv」、「if」、「in」、「instance」、「intersect」、「is」、「item」、「le」、「let」、「lt」、「map」、「mod」、「namespace」、「namespace-node」、「ne」、「node」、「of」、「or」、「parent」、「preceding」、「preceding-sibling」、「processing-instruction」、「return」、「satisfies」、「schema-attribute」、「schema-element」、「self」、「some」、「text」、「then」、「to」、「treat」、「union」がある。】

定義: WhitespaceおよびCommentsは、記号の区切り文字 (symbol separators) として機能する。構文規則の多くの箇所で、明示的には示していないが、2つの終端記号の間に現れてよい。ただし、EBNFで /* ws: explicit */ または /* xgc: xml-version */ と註記している箇所を除く。】

連続する2つの終端記号TおよびU (Tが先) が、以下のいずれかの条件を満たす場合、その間に記号の区切り文字が必要である。

A.2.3 行末の処理

ホスト言語はXPath 3.1処理系に関して、構文解析に先立ち、入力の行区切りをすべて正規化するか否か、する場合は [XML 1.0][XML 1.1] のどちらの規則に従うか、指定しなければならない。

A.2.3.1 XML 1.0の行末処理

[XML 1.0] の処理では、以下に示すものをすべて、単一の「#xA」文字に変換しなければならない。

  1. 連続する2つの文字: 「#xD」「#xA」

  2. 文字「#xD」で、直後が「#xA」でないもの

A.2.3.2 XML 1.1の行末処理

[XML 1.1] の処理では、以下に示すものをすべて、単一の「#xA」文字に変換しなければならない。

  1. 連続する2つの文字: 「#xD」「#xA」

  2. 連続する2つの文字: 「#xD」「#x85」

  3. 単独の文字「#x85」

  4. 単独の文字「#x2028」

  5. 文字「#xD」で、直後が「#xA」でも「#x85」でもないもの

A.2.4 空白類に関する規則

A.2.4.1 既定の空白類処理

定義: 空白類 (whitespace) 文字とは、 [http://www.w3.org/TR/REC-xml/#NT-S] に定義されている文字のことである。】

定義: 無視してよい空白類 (Ignorable whitespace) とは、空白類文字のうち、終端記号の間に現れうるものである。ただし、ws:explicitという註記がついた構文規則の文脈に現れる文字を除く。この場合は、明示的に指定された位置にしか現れ得ない (「A.2.4.2 明示的な空白類処理」を参照)。】 無視してよい空白類は、式の意味に何の影響も及ぼさない。空白類は、XPathの式の、先頭に当たる終端記号の前、末尾に当たる終端記号の後に現れて構わない。また、2つの終端記号の間に現れてもよい。註釈も「空白類」と同じように、隣接する2つの終端記号が1つの終端記号と認識されないように働く。具体的な例を以下に示す。

  • foo- foo」は構文エラーになる。「foo-」が1つのQNameと認識される。

  • foo -foo」は構文的に「foo - foo」と同等で、2つのQNameを減算演算子で区切った形をしている。

  • foo(: This is a comment :)- foo」は構文的に「foo - foo」と同等である。註釈は、隣接する2つの終端記号が1つの終端記号と認識されないように働く。

  • foo-foo」は構文的に、単一のQNameである。「-」はQNameを構成する有効な文字だからである。演算子として使うためには、空白類や括弧を使って、「-」を名前と分けなければならない。

  • 10div 3」は構文エラーになる。

  • 10 div3」も構文エラーである。

  • 10div3」も構文エラーである。

A.2.4.2 明示的な空白類処理

空白類の処理方法が既定の規則と異なる場合は、EBNFの規則として規定し、以下のような記法で表す。この記法が他の規則に引き継がれることはない。すなわち、あるEBNFの規則に /* ws: explicit */ と示してあったとしても、その「子」にあたるEBNFの規則に、自動的に適用されるということはない。

ws: explicit

/* ws: explicit */ という記法は、このEBNFの規則が、S その他を使って、空白類文字が現れてよい箇所を明示的に示していることを表す。「A.2.4.1 既定の空白類処理」に示した規則は適用しない。註釈も、非終端記号Commentで明示的に示した箇所を除き、置くことはできない。

A.3 函数名として使えない名前

以下に示す名前を、接頭辞なしの形で、函数名として使うことはできない。式の構文要素としての使い方を優先する。

  • array

  • attribute

  • comment

  • document-node

  • element

  • empty-sequence

  • function

  • if

  • item

  • map

  • namespace-node

  • node

  • processing-instruction

  • schema-attribute

  • schema-element

  • switch

  • text

  • typeswitch

註記:

XPathではswitchおよびtypeswitchというキーワードを使わないが、XQueryとの互換性を維持するため、函数名として使えないことにしている。

A.4 演算子の優先順位 (Non-Normative)

A.1 EBNF」に示す文法では、演算子の優先順位を構文規則の形で定義している。ここでは参考のため、優先順位の低いものから高いものの順に並べて示す。結合性 (Associativity) の欄は、同じ優先順位の演算子が現れた場合の結合順序を表す。

# Operator Associativity
1 , (comma) either
2 for, let, some, every, if NA
3 or either
4 and either
5 eq, ne, lt, le, gt, ge, =, !=, <, <=, >, >=, is, <<, >> NA
6 || left-to-right
7 to NA
8 +, - (binary) left-to-right
9 *, div, idiv, mod left-to-right
10 union, | either
11 intersect, except left-to-right
12 instance of NA
13 treat as NA
14 castable as NA
15 cast as NA
16 => left-to-right
17 -, + (unary) right-to-left
18 ! left-to-right
19 /, // left-to-right
20 [ ], ? left-to-right
21 ? (unary) NA

「Associativity」欄が「either」であれば、その優先順位の演算子はどのように結合してもよい (すなわち、「(A op B) op C」と「A op (B op C)」は同等)。「NA」であれば、その優先順位の演算子を複数連ねることはできないので、結合性は問題にならない。

註記:

丸括弧を使って演算子の優先順位を変更できる。「A[B]」のような式の角括弧には、2つの役割がある。演算子としての役割 (Aの値の各アイテムに対してBを評価) と、式Bを囲む括弧としての役割である。

B 型の昇格と演算子マッピング

B.1 型の昇格

定義: 状況によっては、原子値をある型から別の型に昇格させることができる。型の昇格 (type promotion) は、函数呼び出し (「3.1.5.1 静的および動的函数呼び出しの評価」を参照) や、数値または文字列をオペランドとする演算子 (「B.2 演算子マッピング」を参照) を評価する際に使う。】 実施可能な型の昇格を以下に示す。

  1. 数値型の昇格:

    1. xs:float型 (またはこれを制限した派生型) の値は、xs:double型に昇格できる。その結果得られるのは、元の値と同じ、xs:double型の値である。

    2. xs:decimal型 (またはこれを制限した派生型) の値は、xs:float型またはxs:double型に昇格できる。昇格は、元の値を昇格後の型に、キャストすることによりおこなう。その結果、精度が損なわれる場合がある。

  2. URI型の昇格: xs:anyURI型 (またはこれを制限した派生型) の値は、xs:string型に昇格できる。昇格は、元の値をxs:string型に、キャストすることによりおこなう。

    註記:

    xs:anyURI型をxs:string型に昇格できるので、既定の照合順序で文字列を比較する函数や演算子を使えば、xs:anyURI型の値も規定の照合順序で比較できる。したがって、文字列、xs:anyURI型の値、あるいはこの2つの型の組み合わせで、順序づけは一貫しており、明確に定義できる。

なお、型の昇格派生型の代用とは、たとえば次のように異なる。

  • xs:float型のパラメーター$pを取る函数は、xs:decimal型の値を渡して呼び出すことができる。これは型の昇格の例である。値を実際に、想定される型に変換することになる。この函数の本体で、「$p instance of xs:decimal」はfalseになる。

  • xs:decimal型のパラメーター$pを取る函数は、xs:integer型の値を渡して呼び出すことができる。これは派生型の代用の例である。値は元の型のままである。この函数の本体で、「$p instance of xs:integer」はtrueになる。

B.2 演算子マッピング

この節で示す演算子マッピングの表は、XPath 3.1の各種演算子を適用できる型の組み合わせをまとめたものである。【定義: 演算子マッピングの表では、演算子とその有効なオペランド型の組み合わせに対して、結果の型と、当該演算子の処理を実装する演算子函数を示す。】 演算子函数の定義は [XQuery and XPath Functions and Operators 3.1] に載っている。演算子を適用した結果、その演算子函数がエラーを起こすことがあり、その定義も [XQuery and XPath Functions and Operators 3.1] に載っている。演算子函数は、オペランドが表に示した型の、単一の原子値である場合について、完全に定義されている。各演算子の定義 (空のシーケンス、長さが2以上のシーケンスを渡した場合の挙動を含む) は、この文書の本文にある。

and演算子、or演算子の定義は、この文書の本文に載っており、演算子マッピングの表には現れない。

演算子マッピングの表に載っている演算子が、ET型のオペランドを要求するとしよう。AT型のオペランドに対して適用できるのは、AT型をET型に、型の昇格および派生型の代用の組み合わせにより変換できる場合である。たとえば、表によると、gt演算子は2つのxs:date型オペランドに適用でき、その戻り値型はxs:booleanである。したがって、xs:dateの2つの派生型 (異なっていてもよい) に対しても適用でき、戻り値型はやはりxs:booleanである。

定義: 型に関して、数値型 (numeric) とは、xs:integerxs:decimalxs:floatxs:doubleのことである。いずれも組み込みの共用型であるxs:numericのメンバー型である。】 オペランドや戻り値の型がnumericである演算子は、数値型それぞれに対応する、4つの演算子を表すと考えてよい。たとえば「+」演算子は、実際には次の4つの演算子を表すことになる。

Operator First operand type Second operand type Result type
+ xs:integer xs:integer xs:integer
+ xs:decimal xs:decimal xs:decimal
+ xs:float xs:float xs:float
+ xs:double xs:double xs:double

数値型の演算子をAT型のオペランドに適用できるのは、AT型を4つの数値型のいずれかに、型の昇格および派生型の代用の組み合わせにより変換できる場合である。演算子の戻り値型が数値型である、という場合、実際の戻り値型は、(xs:integer, xs:decimal, xs:float, xs:double) のうち、オペランドをすべて、派生型の代用および型の昇格により変換できる、最初の型である。たとえば、hatsizexs:integerの派生型、shoesizexs:floatの派生型であるとしよう。すると、hatsize型とshoesize型のオペランドを取る「+」演算子は、xs:float型の値を返す。同様に、hatsize型の2つのオペランドを取る「+」演算子は、xs:integer型の値を返す。

定義: 演算子マッピングの表でGregorianは、xs:gYearMonthxs:gYearxs:gMonthDayxs:gDayxs:gMonthの各型を表す。】 Gregorian型のオペランドを取る二項演算子は、2つのオペランドが同じ型でなければならない (たとえば、一方のオペランドがxs:gDayならば、もう一方もxs:gDay)。

Binary Operators
Operator Type(A) Type(B) Function Result type
A + B numeric numeric op:numeric-add(A, B) numeric
A + B xs:date xs:yearMonthDuration op:add-yearMonthDuration-to-date(A, B) xs:date
A + B xs:yearMonthDuration xs:date op:add-yearMonthDuration-to-date(B, A) xs:date
A + B xs:date xs:dayTimeDuration op:add-dayTimeDuration-to-date(A, B) xs:date
A + B xs:dayTimeDuration xs:date op:add-dayTimeDuration-to-date(B, A) xs:date
A + B xs:time xs:dayTimeDuration op:add-dayTimeDuration-to-time(A, B) xs:time
A + B xs:dayTimeDuration xs:time op:add-dayTimeDuration-to-time(B, A) xs:time
A + B xs:dateTime xs:yearMonthDuration op:add-yearMonthDuration-to-dateTime(A, B) xs:dateTime
A + B xs:yearMonthDuration xs:dateTime op:add-yearMonthDuration-to-dateTime(B, A) xs:dateTime
A + B xs:dateTime xs:dayTimeDuration op:add-dayTimeDuration-to-dateTime(A, B) xs:dateTime
A + B xs:dayTimeDuration xs:dateTime op:add-dayTimeDuration-to-dateTime(B, A) xs:dateTime
A + B xs:yearMonthDuration xs:yearMonthDuration op:add-yearMonthDurations(A, B) xs:yearMonthDuration
A + B xs:dayTimeDuration xs:dayTimeDuration op:add-dayTimeDurations(A, B) xs:dayTimeDuration
A - B numeric numeric op:numeric-subtract(A, B) numeric
A - B xs:date xs:date op:subtract-dates(A, B) xs:dayTimeDuration
A - B xs:date xs:yearMonthDuration op:subtract-yearMonthDuration-from-date(A, B) xs:date
A - B xs:date xs:dayTimeDuration op:subtract-dayTimeDuration-from-date(A, B) xs:date
A - B xs:time xs:time op:subtract-times(A, B) xs:dayTimeDuration
A - B xs:time xs:dayTimeDuration op:subtract-dayTimeDuration-from-time(A, B) xs:time
A - B xs:dateTime xs:dateTime op:subtract-dateTimes(A, B) xs:dayTimeDuration
A - B xs:dateTime xs:yearMonthDuration op:subtract-yearMonthDuration-from-dateTime(A, B) xs:dateTime
A - B xs:dateTime xs:dayTimeDuration op:subtract-dayTimeDuration-from-dateTime(A, B) xs:dateTime
A - B xs:yearMonthDuration xs:yearMonthDuration op:subtract-yearMonthDurations(A, B) xs:yearMonthDuration
A - B xs:dayTimeDuration xs:dayTimeDuration op:subtract-dayTimeDurations(A, B) xs:dayTimeDuration
A * B numeric numeric op:numeric-multiply(A, B) numeric
A * B xs:yearMonthDuration numeric op:multiply-yearMonthDuration(A, B) xs:yearMonthDuration
A * B numeric xs:yearMonthDuration op:multiply-yearMonthDuration(B, A) xs:yearMonthDuration
A * B xs:dayTimeDuration numeric op:multiply-dayTimeDuration(A, B) xs:dayTimeDuration
A * B numeric xs:dayTimeDuration op:multiply-dayTimeDuration(B, A) xs:dayTimeDuration
A idiv B numeric numeric op:numeric-integer-divide(A, B) xs:integer
A div B numeric numeric op:numeric-divide(A, B) numeric; but xs:decimal if both operands are xs:integer
A div B xs:yearMonthDuration numeric op:divide-yearMonthDuration(A, B) xs:yearMonthDuration
A div B xs:dayTimeDuration numeric op:divide-dayTimeDuration(A, B) xs:dayTimeDuration
A div B xs:yearMonthDuration xs:yearMonthDuration op:divide-yearMonthDuration-by-yearMonthDuration (A, B) xs:decimal
A div B xs:dayTimeDuration xs:dayTimeDuration op:divide-dayTimeDuration-by-dayTimeDuration (A, B) xs:decimal
A mod B numeric numeric op:numeric-mod(A, B) numeric
A eq B numeric numeric op:numeric-equal(A, B) xs:boolean
A eq B xs:boolean xs:boolean op:boolean-equal(A, B) xs:boolean
A eq B xs:string xs:string op:numeric-equal(fn:compare(A, B), 0) xs:boolean
A eq B xs:date xs:date op:date-equal(A, B) xs:boolean
A eq B xs:time xs:time op:time-equal(A, B) xs:boolean
A eq B xs:dateTime xs:dateTime op:dateTime-equal(A, B) xs:boolean
A eq B xs:duration xs:duration op:duration-equal(A, B) xs:boolean
A eq B Gregorian Gregorian op:gYear-equal(A, B) etc. xs:boolean
A eq B xs:hexBinary xs:hexBinary op:hexBinary-equal(A, B) xs:boolean
A eq B xs:base64Binary xs:base64Binary op:base64Binary-equal(A, B) xs:boolean
A eq B xs:QName xs:QName op:QName-equal(A, B) xs:boolean
A eq B xs:NOTATION xs:NOTATION op:NOTATION-equal(A, B) xs:boolean
A eq B xs:hexBinary xs:hexBinary op:hexBinary-equal(A, B) xs:boolean
A eq B xs:base64Binary xs:base64Binary op:hexBinary-equal(A, B) xs:boolean
A ne B numeric numeric fn:not(op:numeric-equal(A, B)) xs:boolean
A ne B xs:boolean xs:boolean fn:not(op:boolean-equal(A, B)) xs:boolean
A ne B xs:string xs:string fn:not(op:numeric-equal(fn:compare(A, B), 0)) xs:boolean
A ne B xs:date xs:date fn:not(op:date-equal(A, B)) xs:boolean
A ne B xs:time xs:time fn:not(op:time-equal(A, B)) xs:boolean
A ne B xs:dateTime xs:dateTime fn:not(op:dateTime-equal(A, B)) xs:boolean
A ne B xs:duration xs:duration fn:not(op:duration-equal(A, B)) xs:boolean
A ne B Gregorian Gregorian fn:not(op:gYear-equal(A, B)) etc. xs:boolean
A ne B xs:hexBinary xs:hexBinary fn:not(op:hexBinary-equal(A, B)) xs:boolean
A ne B xs:base64Binary xs:base64Binary fn:not(op:base64Binary-equal(A, B)) xs:boolean
A ne B xs:QName xs:QName fn:not(op:QName-equal(A, B)) xs:boolean
A ne B xs:NOTATION xs:NOTATION fn:not(op:NOTATION-equal(A, B)) xs:boolean
A ne B xs:hexBinary xs:hexBinary fn:not(op:hexBinary-equal(A, B)) xs:boolean
A ne B xs:base64Binary xs:base64Binary fn:not(op:base64Binary-equal(A, B)) xs:boolean
A gt B numeric numeric op:numeric-greater-than(A, B) xs:boolean
A gt B xs:boolean xs:boolean op:boolean-greater-than(A, B) xs:boolean
A gt B xs:string xs:string op:numeric-greater-than(fn:compare(A, B), 0) xs:boolean
A gt B xs:date xs:date op:date-greater-than(A, B) xs:boolean
A gt B xs:time xs:time op:time-greater-than(A, B) xs:boolean
A gt B xs:dateTime xs:dateTime op:dateTime-greater-than(A, B) xs:boolean
A gt B xs:yearMonthDuration xs:yearMonthDuration op:yearMonthDuration-greater-than(A, B) xs:boolean
A gt B xs:dayTimeDuration xs:dayTimeDuration op:dayTimeDuration-greater-than(A, B) xs:boolean
A gt B xs:hexBinary xs:hexBinary op:hexBinary-greater-than(A, B) xs:boolean
A gt B xs:base64Binary xs:base64Binary op:base64Binary-greater-than(A, B) xs:boolean
A lt B numeric numeric op:numeric-less-than(A, B) xs:boolean
A lt B xs:boolean xs:boolean op:boolean-less-than(A, B) xs:boolean
A lt B xs:string xs:string op:numeric-less-than(fn:compare(A, B), 0) xs:boolean
A lt B xs:date xs:date op:date-less-than(A, B) xs:boolean
A lt B xs:time xs:time op:time-less-than(A, B) xs:boolean
A lt B xs:dateTime xs:dateTime op:dateTime-less-than(A, B) xs:boolean
A lt B xs:yearMonthDuration xs:yearMonthDuration op:yearMonthDuration-less-than(A, B) xs:boolean
A lt B xs:dayTimeDuration xs:dayTimeDuration op:dayTimeDuration-less-than(A, B) xs:boolean
A lt B xs:hexBinary xs:hexBinary op:hexBinary-less-than(A, B) xs:boolean
A lt B xs:base64Binary xs:base64Binary op:base64Binary-less-than(A, B) xs:boolean
A ge B numeric numeric op:numeric-greater-than(A, B) or op:numeric-equal(A, B) xs:boolean
A ge B xs:boolean xs:boolean fn:not(op:boolean-less-than(A, B)) xs:boolean
A ge B xs:string xs:string op:numeric-greater-than(fn:compare(A, B), -1) xs:boolean
A ge B xs:date xs:date fn:not(op:date-less-than(A, B)) xs:boolean
A ge B xs:time xs:time fn:not(op:time-less-than(A, B)) xs:boolean
A ge B xs:dateTime xs:dateTime fn:not(op:dateTime-less-than(A, B)) xs:boolean
A ge B xs:yearMonthDuration xs:yearMonthDuration fn:not(op:yearMonthDuration-less-than(A, B)) xs:boolean
A ge B xs:dayTimeDuration xs:dayTimeDuration fn:not(op:dayTimeDuration-less-than(A, B)) xs:boolean
A ge B xs:hexBinary xs:hexBinary fn:not(op:hexBinary-less-than(A, B)) xs:boolean
A ge B xs:base64Binary xs:base64Binary fn:not(op:base64Binary-less-than(A, B)) xs:boolean
A le B numeric numeric op:numeric-less-than(A, B) or op:numeric-equal(A, B) xs:boolean
A le B xs:boolean xs:boolean fn:not(op:boolean-greater-than(A, B)) xs:boolean
A le B xs:string xs:string op:numeric-less-than(fn:compare(A, B), 1) xs:boolean
A le B xs:date xs:date fn:not(op:date-greater-than(A, B)) xs:boolean
A le B xs:time xs:time fn:not(op:time-greater-than(A, B)) xs:boolean
A le B xs:dateTime xs:dateTime fn:not(op:dateTime-greater-than(A, B)) xs:boolean
A le B xs:yearMonthDuration xs:yearMonthDuration fn:not(op:yearMonthDuration-greater-than(A, B)) xs:boolean
A le B xs:dayTimeDuration xs:dayTimeDuration fn:not(op:dayTimeDuration-greater-than(A, B)) xs:boolean
A le B xs:hexBinary xs:hexBinary fn:not(op:hexBinary-greater-than(A, B)) xs:boolean
A le B xs:base64Binary xs:base64Binary fn:not(op:base64Binary-greater-than(A, B)) xs:boolean
Unary Operators
Operator Operand type Function Result type
+ A numeric op:numeric-unary-plus(A) numeric
- A numeric op:numeric-unary-minus(A) numeric

C Context Components

The tables in this section describe the scope (range of applicability) of the various components in a module's static context and dynamic context.

C.1 Static Context Components

The following table describes the components of the static context. For each component, "global" indicates that the value of the component applies throughout an XPath expression, whereas "lexical" indicates that the value of the component applies only within the subexpression in which it is defined.

Static Context Components
Component Scope
XPath 1.0 Compatibility Mode global
Statically known namespaces global
Default element/type namespace global
Default function namespace global
In-scope schema types global
In-scope element declarations global
In-scope attribute declarations global
In-scope variables lexical; for-expressions, let-expressions, and quantified expressions can bind new variables
Context item static type lexical
Statically known function signatures global
Statically known collations global
Default collation global
Base URI global
Statically known documents global
Statically known collections global
Statically known default collection type global

C.2 Dynamic Context Components

The following table describes how values are assigned to the various components of the dynamic context. All these components are initialized by mechanisms defined by the host language. For each component, "global" indicates that the value of the component remains constant throughout evaluation of the XPath expression, whereas "dynamic" indicates that the value of the component can be modified by the evaluation of subexpressions.

Dynamic Context Components
Component Scope
Context item dynamic; changes during evaluation of path expressions and predicates
Context position dynamic; changes during evaluation of path expressions and predicates
Context size dynamic; changes during evaluation of path expressions and predicates
Variable values dynamic; for-expressions, let-expressions, and quantified expressions can bind new variables
Current date and time global; must be initialized
Implicit timezone global; must be initialized
Available documents global; must be initialized
Available collections global; must be initialized
Default collection global; overwriteable by implementation
Available URI collections global; must be initialized
Default URI collection global; overwriteable by implementation

D Implementation-Defined Items

The following items in this specification are implementation-defined:

  1. The version of Unicode that is used to construct expressions.

  2. The statically-known collations.

  3. The implicit timezone.

  4. The circumstances in which warnings are raised, and the ways in which warnings are handled.

  5. The method by which errors are reported to the external processing environment.

  6. Which version of XML and XML Names (e.g. [XML 1.0] and [XML Names] or [XML 1.1] and [XML Names 1.1]) and which version of XML Schema (e.g. [XML Schema 1.0] or [XML Schema 1.1]) is used for the definitions of primitives such as characters and names, and for the definitions of operations such as normalization of line endings and normalization of whitespace in attribute values. It is recommended that the latest applicable version be used (even if it is published later than this specification).

  7. How XDM instances are created from sources other than an Infoset or PSVI.

  8. Whether the implementation supports the namespace axis.

  9. Whether the type system is based on [XML Schema 1.0] or [XML Schema 1.1]. An implementation that has based its type system on XML Schema 1.0 is not required to support the use of the xs:dateTimeStamp constructor or the use of xs:dateTimeStamp or xs:error as TypeName in any expression.

  10. The signatures of functions provided by the implementation or via an implementation-defined API (see 2.1.1 Static Context).

  11. Any environment variables provided by the implementation.

  12. Any rules used for static typing (see 2.2.3.1 Static Analysis Phase).

  13. Any serialization parameters provided by the implementation

  14. What error, if any, is returned if an external function's implementation does not return the declared result type (see 2.2.4 Consistency Constraints).

E References

E.1 Normative References

RFC2119
S. Bradner. Key Words for use in RFCs to Indicate Requirement Levels. IETF RFC 2119. See http://www.ietf.org/rfc/rfc2119.txt.
RFC3986
T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax. IETF RFC 3986. See http://www.ietf.org/rfc/rfc3986.txt.
RFC3987
M. Duerst and M. Suignard. Internationalized Resource Identifiers (IRIs). IETF RFC 3987. See http://www.ietf.org/rfc/rfc3987.txt.
ISO/IEC 10646
ISO (International Organization for Standardization). ISO/IEC 10646:2003. Information technology—Universal Multiple-Octet Coded Character Set (UCS), as, from time to time, amended, replaced by a new edition, or expanded by the addition of new parts. [Geneva]: International Organization for Standardization. (See http://www.iso.org for the latest version.)
Unicode
The Unicode Consortium. The Unicode Standard Reading, Mass.: Addison-Wesley, 2003, as updated from time to time by the publication of new versions. See http://www.unicode.org/standard/versions/ for the latest version and additional information on versions of the standard and of the Unicode Character Database. The version of Unicode to be used is implementation-defined, but implementations are recommended to use the latest Unicode version.
XML 1.0
World Wide Web Consortium. Extensible Markup Language (XML) 1.0. W3C Recommendation. See http://www.w3.org/TR/REC-xml/. The edition of XML 1.0 must be no earlier than the Third Edition; the edition used is implementation-defined, but we recommend that implementations use the latest version.
XML 1.1
World Wide Web Consortium. Extensible Markup Language (XML) 1.1. W3C Recommendation. See http://www.w3.org/TR/xml11/
XML Base
World Wide Web Consortium. XML Base. W3C Recommendation. See http://www.w3.org/TR/xmlbase/
XML Names
World Wide Web Consortium. Namespaces in XML. W3C Recommendation. See http://www.w3.org/TR/REC-xml-names/
XML Names 1.1
World Wide Web Consortium. Namespaces in XML 1.1. W3C Recommendation. See http://www.w3.org/TR/xml-names11/
XML ID
World Wide Web Consortium. xml:id Version 1.0. W3C Recommendation. See http://www.w3.org/TR/xml-id/
XML Schema 1.0
World Wide Web Consortium. XML Schema, Parts 0, 1, and 2 (Second Edition). W3C Recommendation, 28 October 2004. See http://www.w3.org/TR/xmlschema-0/, http://www.w3.org/TR/xmlschema-1/, and http://www.w3.org/TR/xmlschema-2/.
XML Schema 1.1
World Wide Web Consortium. XML Schema, Parts 1, and 2. W3C Recommendation 5 April 2012. See http://www.w3.org/TR/xmlschema11-1/, and http://www.w3.org/TR/xmlschema11-2/.
XQuery and XPath Data Model (XDM) 3.1
XQuery and XPath Data Model (XDM) 3.1, Norman Walsh, John Snelson, Andrew Coleman, Editors. World Wide Web Consortium, 21 March 2017. This version is https://www.w3.org/TR/2017/REC-xpath-datamodel-31-20170321/. The latest version is available at https://www.w3.org/TR/xpath-datamodel-31/.
XQuery and XPath Functions and Operators 3.1
XQuery and XPath Functions and Operators 3.1, Michael Kay, Editor. World Wide Web Consortium, 21 March 2017. This version is https://www.w3.org/TR/2017/REC-xpath-functions-31-20170321/. The latest version is available at https://www.w3.org/TR/xpath-functions-31/.
XSLT and XQuery Serialization 3.1
XSLT and XQuery Serialization 3.1, Andrew Coleman and Michael Sperberg-McQueen, Editors. World Wide Web Consortium, 21 March 2017. This version is https://www.w3.org/TR/2017/REC-xslt-xquery-serialization-31-20170321/. The latest version is available at https://www.w3.org/TR/xslt-xquery-serialization-31/.

E.2 Non-normative References

XQuery 3.1: An XML Query Language
XQuery 3.1: An XML Query Language, Jonathan Robie, Michael Dyck and Josh Spiegel, Editors. World Wide Web Consortium, 21 March 2017. This version is https://www.w3.org/TR/2017/REC-xquery-31-20170321/. The latest version is available at https://www.w3.org/TR/xquery-31/.
XQuery 1.0 and XPath 2.0 Formal Semantics
XQuery 1.0 and XPath 2.0 Formal Semantics (Second Edition), Jérôme Siméon, Denise Draper, Peter Frankhauser, et. al., Editors. World Wide Web Consortium, 14 December 2010. This version is https://www.w3.org/TR/2010/REC-xquery-semantics-20101214/. The latest version is available at https://www.w3.org/TR/xquery-semantics/.
XSL Transformations (XSLT) Version 3.0
XSL Transformations (XSLT) Version 3.0, Michael Kay, Editor. World Wide Web Consortium, 7 February 2017. This version is https://www.w3.org/TR/2017/CR-xslt-30-20170207/. The latest version is available at https://www.w3.org/TR/xslt-30/.
XML Infoset
World Wide Web Consortium. XML Information Set (Second Edition). W3C Recommendation 4 February 2004. See http://www.w3.org/TR/xml-infoset/
XML Path Language (XPath) Version 1.0
XML Path Language (XPath) Version 1.0, James Clark and Steven DeRose, Editors. World Wide Web Consortium, 16 Nov 1999. This version is http://www.w3.org/TR/1999/REC-xpath-19991116. The latest version is available at http://www.w3.org/TR/xpath.
XML Path Language (XPath) Version 2.0
XML Path Language (XPath) 2.0 (Second Edition), Don Chamberlin, Anders Berglund, Scott Boag, et. al., Editors. World Wide Web Consortium, 14 December 2010. This version is https://www.w3.org/TR/2010/REC-xpath20-20101214/. The latest version is available at https://www.w3.org/TR/xpath20/.
XML Path Language (XPath) Version 3.0
XML Path Language (XPath) 3.0, Jonathan Robie, Don Chamberlin, Michael Dyck, John Snelson, Editors. World Wide Web Consortium, 08 April 2014. This version is https://www.w3.org/TR/2014/REC-xpath-30-20140408/. The latest version is available at https://www.w3.org/TR/xpath-30/.
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

E.3 Background Material

Character Model
World Wide Web Consortium. Character Model for the World Wide Web. W3C Working Draft. See http://www.w3.org/TR/charmod/.
XSL Transformations (XSLT) Version 1.0
XSL Transformations (XSLT) Version 1.0, James Clark, Editor. World Wide Web Consortium, 16 Nov 1999. This version is http://www.w3.org/TR/1999/REC-xslt-19991116. The latest version is available at http://www.w3.org/TR/xslt.

F Error Conditions

err:XPST0001

It is a static error if analysis of an expression relies on some component of the static context that is absentDM31 .

err:XPDY0002

It is a dynamic error if evaluation of an expression relies on some part of the dynamic context that is absentDM31 .

err:XPST0003

It is a static error if an expression is not a valid instance of the grammar defined in A.1 EBNF.

err:XPTY0004

It is a type error if, during the static analysis phase, an expression is found to have a static type that is not appropriate for the context in which the expression occurs, or during the dynamic evaluation phase, the dynamic type of a value does not match a required type as specified by the matching rules in 2.5.5 SequenceType Matching.

err:XPST0005

During the analysis phase, it is a static error if the static type assigned to an expression other than the expression () or data(()) is empty-sequence().

err:XPST0008

It is a static error if an expression refers to an element name, attribute name, schema type name, namespace prefix, or variable name that is not defined in the static context, except for an ElementName in an ElementTest or an AttributeName in an AttributeTest.

err:XPST0010

An implementation that does not support the namespace axis must raise a static error if it encounters a reference to the namespace axis and XPath 1.0 compatibility mode is false.

err:XPST0017

It is a static error if the expanded QName and number of arguments in a static function call do not match the name and arity of a function signature in the static context.

err:XPTY0018

It is a type error if the result of a path operator contains both nodes and non-nodes.

err:XPTY0019

It is a type error if E1 in a path expression E1/E2 does not evaluate to a sequence of nodes.

err:XPTY0020

It is a type error if, in an axis step, the context item is not a node.

err:XQST0039

It is a static error for an inline function expression to have more than one parameter with the same name.

err:XQST0046

An implementation MAY raise a static error if the value of a BracedURILiteral is of nonzero length and is neither an absolute URI nor a relative URI.

err:XPDY0050

It is a dynamic error if the dynamic type of the operand of a treat expression does not match the sequence type specified by the treat expression. This error might also be raised by a path expression beginning with "/" or "//" if the context node is not in a tree that is rooted at a document node. This is because a leading "/" or "//" in a path expression is an abbreviation for an initial step that includes the clause treat as document-node().

err:XPST0051

It is a static error if the expanded QName for an AtomicOrUnionType in a SequenceType is not defined in the in-scope schema types as a generalized atomic type.

err:XQST0052

The type named in a cast or castable expression must be the name of a type defined in the in-scope schema types, and the type must be simple.

err:XQST0070

A static error is raised if any of the following conditions is statically detected in any expression:

  • The prefix xml is bound to some namespace URI other than http://www.w3.org/XML/1998/namespace.

  • A prefix other than xml is bound to the namespace URI http://www.w3.org/XML/1998/namespace.

  • The prefix xmlns is bound to any namespace URI.

  • A prefix other than xmlns is bound to the namespace URI http://www.w3.org/2000/xmlns/.

err:XPST0080

It is a static error if the target type of a cast or castable expression is xs:NOTATION, xs:anySimpleType, or xs:anyAtomicType.

err:XPST0081

It is a static error if a QName used in an expression contains a namespace prefix that cannot be expanded into a namespace URI by using the statically known namespaces.

err:XPTY0117

When applying the function conversion rules, if an item is of type xs:untypedAtomic and the expected type is namespace-sensitive, a type error [err:XPTY0117] is raised.

err:XPDY0130

An implementation-dependent limit has been exceeded.

err:XQST0134

The namespace axis is not supported.

err:XQDY0137

No two keys in a map may have the same key value.

G Glossary (Non-Normative)

Gregorian

In the operator mapping tables, the term Gregorian refers to the types xs:gYearMonth, xs:gYear, xs:gMonthDay, xs:gDay, and xs:gMonth.

NaN

NaN is the string used to represent the double value NaN (not-a-number); the default value is the string "NaN"

SequenceType matching

SequenceType matching compares the dynamic type of a value with an expected sequence type.

Static Base URI

Static Base URI. This is an absolute URI, used to resolve relative URI references.

URI

Within this specification, the term URI refers to a Universal Resource Identifier as defined in [RFC3986] and extended in [RFC3987] with the new name IRI.

XDM instance

The term XDM instance is used, synonymously with the term value, to denote an unconstrained sequence of items.

XPath 1.0 compatibility mode

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.

anonymous function

An anonymous function is a function with no name. Anonymous functions may be created, for example, by evaluating an inline function expression or by partial function application.

argument expression

An argument to a function call is either an argument expression or an ArgumentPlaceholder ("?").

argument value

Argument expressions are evaluated with respect to DC, producing argument values.

arity

The number of Arguments in an ArgumentList is its arity.

array

An array is a function that associates a set of positions, represented as positive integer keys, with values.

arrow operator

An arrow operator applies a function to the value of an expression, using the value as the first argument to the function.

associated value

The value associated with a given key is called the associated value of the key.

atomic value

An atomic value is a value in the value space of an atomic type, as defined in [XML Schema 1.0] or [XML Schema 1.1].

atomization

Atomization of a sequence is defined as the result of invoking the fn:data function, as defined in Section 2.4 fn:data FO31.

available documents

Available documents. This is a mapping of strings to document nodes. Each string represents the absolute URI of a resource. The document node is the root of a tree that represents that resource using the data model. The document node is returned by the fn:doc function when applied to that URI.

available item collections

Available collections. This is a mapping of strings to sequences of items. Each string represents the absolute URI of a resource. The sequence of items represents the result of the fn:collection function when that URI is supplied as the argument.

available text resources

Available text resources. This is a mapping of strings to text resources. Each string represents the absolute URI of a resource. The resource is returned by the fn:unparsed-text function when applied to that URI.

available uri collections

Available URI collections. This is a mapping of strings to sequences of URIs. The string represents the absolute URI of a resource which can be interpreted as an aggregation of a number of individual resources each of which has its own URI. The sequence of URIs represents the result of the fn:uri-collection function when that URI is supplied as the argument.

axis step

An axis step returns a sequence of nodes that are reachable from the context node via a specified axis. Such a step has two parts: an axis, which defines the "direction of movement" for the step, and a node test, which selects nodes based on their kind, name, and/or type annotation.

built-in function

The built-in functions are the functions defined in [XQuery and XPath Functions and Operators 3.1] in the http://www.w3.org/2005/xpath-functions, http://www.w3.org/2001/XMLSchema, http://www.w3.org/2005/xpath-functions/math, http://www.w3.org/2005/xpath-functions/map, and http://www.w3.org/2005/xpath-functions/array namespaces.

collation

A collation is a specification of the manner in which strings and URIs are compared and, by extension, ordered. For a more complete definition of collation, see Section 5.3 Comparison of strings FO31.

comma operator

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

constructor function

The constructor function for a given type is used to convert instances of other simple types into the given type. The semantics of the constructor function call T($arg) are defined to be equivalent to the expression (($arg) cast as T?).

content expression

In an enclosed expression, the optional expression enclosed in curly braces is called the content expression.

context item

The context item is the item currently being processed.

context item static type

Context item static type. This component defines the static type of the context item within the scope of a given expression.

context node

When the context item is a node, it can also be referred to as the context node.

context position

The context position is the position of the context item within the sequence of items currently being processed.

context size

The context size is the number of items in the sequence of items currently being processed.

current dateTime

Current dateTime. This information represents an implementation-dependent point in time during the processing of an expression, and includes an explicit timezone. It can be retrieved by the fn:current-dateTime function. If invoked multiple times during the execution of an expression, this function always returns the same result.

data model

XPath 3.1 operates on the abstract, logical structure of an XML document or JSON object, rather than its surface syntax. This logical structure, known as the data model, is defined in [XQuery and XPath Data Model (XDM) 3.1].

decimal-separator

decimal-separator is the character used to separate the integer part of the number from the fractional part, both in the picture string and in the formatted number; the default value is the period character (.)

default URI collection

Default URI collection. This is the sequence of URIs that would result from calling the fn:uri-collection function with no arguments.

default calendar

Default calendar. This is the calendar used when formatting dates in human-readable output (for example, by the functions fn:format-date and fn:format-dateTime) if no other calendar is requested. The value is a string.

default collation

Default collation. This identifies one of the collations in statically known collations as the collation to be used by functions and operators for comparing and ordering values of type xs:string and xs:anyURI (and types derived from them) when no explicit collation is specified.

default collection

Default collection. This is the sequence of items that would result from calling the fn:collection function with no arguments.

default element/type namespace

Default element/type namespace. This is a namespace URI or absentDM31. The namespace URI, if present, is used for any unprefixed QName appearing in a position where an element or type name is expected.

default function namespace

Default function namespace. This is a namespace URI or absentDM31. The namespace URI, if present, is used for any unprefixed QName appearing in a position where a function name is expected.

default language

Default language. This is the natural language used when creating human-readable output (for example, by the functions fn:format-date and fn:format-integer) if no other language is requested. The value is a language code as defined by the type xs:language.

default place

Default place. This is a geographical location used to identify the place where events happened (or will happen) when formatting dates and times using functions such as fn:format-date and fn:format-dateTime, if no other place is specified. It is used when translating timezone offsets to civil timezone names, and when using calendars where the translation from ISO dates/times to a local representation is dependent on geographical location. Possible representations of this information are an ISO country code or an Olson timezone name, but implementations are free to use other representations from which the above information can be derived.

delimiting terminal symbol

The delimiting terminal symbols are: "!", "!=", StringLiteral, "#", "$", "(", ")", "*", "*:", "+", (comma), "-", (dot), "..", "/", "//", (colon), ":*", "::", ":=", "<", "<<", "<=", "=", "=>", ">", ">=", ">>", "?", "@", BracedURILiteral, "[", "]", "{", "|", "||", "}"

digit

digit is a character used in the picture string to represent an optional digit; the default value is the number sign character (#)

document order

Informally, document order is the order in which nodes appear in the XML serialization of a document.

dynamic context

The dynamic context of an expression is defined as information that is needed for the dynamic evaluation of an expression.

dynamic error

A dynamic error is an error that must be detected during the dynamic evaluation phase and may be detected during the static analysis phase. Numeric overflow is an example of a dynamic error.

dynamic evaluation phase

The dynamic evaluation phase is the phase during which the value of an expression is computed.

dynamic function call

A dynamic function call consists of a base expression that returns the function and a parenthesized list of zero or more arguments (argument expressions or ArgumentPlaceholders).

dynamic type

A dynamic type is associated with each value as it is computed. The dynamic type of a value may be more specific than the static type of the expression that computed it (for example, the static type of an expression might be xs:integer*, denoting a sequence of zero or more integers, but at evaluation time its value may have the dynamic type xs:integer, denoting exactly one integer.)

effective boolean value

The effective boolean value of a value is defined as the result of applying the fn:boolean function to the value, as defined in Section 7.3.1 fn:boolean FO31.

empty sequence

A sequence containing zero items is called an empty sequence.

enclosed expression

An enclosed expression is an instance of the EnclosedExpr production, which allows an optional expression within curly braces.

entry

Each key / value pair in a map is called an entry.

environment variables

Environment variables. This is a mapping from names to values. Both the names and the values are strings. The names are compared using an implementation-defined collation, and are unique under this collation. The set of environment variables is implementation-defined and may be empty.

error value

In addition to its identifying QName, a dynamic error may also carry a descriptive string and one or more additional values called error values.

expanded QName

An expanded QName is a triple: its components are a prefix, a local name, and a namespace URI. In the case of a name in no namespace, the namespace URI and prefix are both absent. In the case of a name in the default namespace, the prefix is absent.

exponent-separator

exponent-separator is the character used to separate the mantissa from the exponent in scientific notation both in the picture string and in the formatted number; the default value is the character (e).

expression context

The expression context for a given expression consists of all the information that can affect the result of the expression.

external function

External functions are functions that are implemented outside the query environment.

filter expression

An expression followed by a predicate (that is, E1[E2]) is referred to as a filter expression: its effect is to return those items from the value of E1 that satisfy the predicate in E2.

fixed position

In a partial function application, a fixed position is an argument/parameter position for which the ArgumentList has an argument expression (as opposed to an ArgumentPlaceholder).

focus

The first three components of the dynamic context (context item, context position, and context size) are called the focus of the expression.

function coercion

Function coercion wraps a functionDM31 in a new function with signature the same as the expected type. This effectively delays the checking of the argument and return types until the function is invoked.

function conversion rules

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.

generalized atomic type

A generalized atomic type is a type which is either (a) an atomic type or (b) a pure union type

grouping-separator

grouping-separator is the character typically used as a thousands separator, both in the picture string and in the formatted number; the default value is the comma character (,)

host language function

A host language function is an external function defined by the host language.

host-language

A host language for XPath is a language or specification that incorporates XPath as a sublanguage and that defines how the static and dynamic context for evaluation of XPath expressions are to be established.

ignorable whitespace

Ignorable whitespace consists of any whitespace characters that may occur between terminals, unless these characters occur in the context of a production marked with a ws:explicit annotation, in which case they can occur only where explicitly specified (see A.2.4.2 Explicit Whitespace Handling).

implementation dependent

Implementation-dependent indicates an aspect that may differ between implementations, is not specified by this or any W3C specification, and is not required to be specified by the implementor for any particular implementation.

implementation defined

Implementation-defined indicates an aspect that may differ between implementations, but must be specified by the implementor for each particular implementation.

implementation-defined function

An implementation-defined function is an external function that is implementation-defined

implicit timezone

Implicit timezone. This is the timezone to be used when a date, time, or dateTime value that does not have a timezone is used in a comparison or arithmetic operation. The implicit timezone is an implementation-defined value of type xs:dayTimeDuration. See Section 3.2.7.3 Timezones XS1-2 or Section 3.3.7 dateTime XS11-2 for the range of valid values of a timezone.

in-scope attribute declarations

In-scope attribute declarations. Each attribute declaration is identified either by an expanded QName (for a top-level attribute declaration) or by an implementation-dependent attribute identifier (for a local attribute declaration).

in-scope element declarations

In-scope element declarations. Each element declaration is identified either by an expanded QName (for a top-level element declaration) or by an implementation-dependent element identifier (for a local element declaration).

in-scope namespaces

The in-scope namespaces property of an element node is a set of namespace bindings, each of which associates a namespace prefix with a URI.

in-scope schema definitions

In-scope schema definitions. This is a generic term for all the element declarations, attribute declarations, and schema type definitions that are in scope during static analysis of an expression.

in-scope schema type

In-scope schema types. Each schema type definition is identified either by an expanded QName (for a named type) or by an implementation-dependent type identifier (for an anonymous type). The in-scope schema types include the predefined schema types described in 2.5.1 Predefined Schema Types.

in-scope variables

In-scope variables. This is a mapping from expanded QName to type. It defines the set of variables that are available for reference within an expression. The expanded QName is the name of the variable, and the type is the static type of the variable.

infinity

infinity is the string used to represent the double value infinity (INF); the default value is the string "Infinity"

inline function expression

An inline function expression creates an anonymous function defined directly in the inline function expression.

item

An item is either an atomic value, a node, or a functionDM31.

kind test

An alternative form of a node test called a kind test can select nodes based on their kind, name, and type annotation.

lexical QName

A lexical QName is a name that conforms to the syntax of the QName production

literal

A literal is a direct syntactic representation of an atomic value.

map

A map is a function that associates a set of keys with values, resulting in a collection of key / value pairs.

may

MAY means that an item is truly optional.

member

The values of an array are called its members.

minus-sign

minus-sign is the single character used to mark negative numbers; the default value is the hyphen-minus character (#x2D).

must

MUST means that the item is an absolute requirement of the specification.

must not

MUST NOT means that the item is an absolute prohibition of the specification.

name test

A node test that consists only of an EQName or a Wildcard is called a name test.

named function

A named function is a function defined in the static context for the expression. To uniquely identify a particular named function, both its name as an expanded QName and its arity are required.

named function reference

A named function reference is an expression which evaluates to a named function. The name and arity of the returned function are known statically, and correspond to a function signature present in the static context; if the function is context dependent, then the returned function is associated with the static context of the named function reference and the dynamic context in which it is evaluated.

named functions

Named functions. This is a mapping from (expanded QName, arity) to functionDM31.

namespace-sensitive

The namespace-sensitive types are xs:QName, xs:NOTATION, types derived by restriction from xs:QName or xs:NOTATION, list types that have a namespace-sensitive item type, and union types with a namespace-sensitive type in their transitive membership.

node

A node is an instance of one of the node kinds defined in Section 6 Nodes DM31.

node test

A node test is a condition on the name, kind (element, attribute, text, document, comment, or processing instruction), and/or type annotation of a node. A node test determines which nodes contained by an axis are selected by a step.

non-delimiting terminal symbol

The non-delimiting terminal symbols are: IntegerLiteral, URIQualifiedName, NCName, DecimalLiteral, DoubleLiteral, QName, "ancestor", "ancestor-or-self", "and", "array", "as", "attribute", "cast", "castable", "child", "comment", "descendant", "descendant-or-self", "div", "document-node", "element", "else", "empty-sequence", "eq", "every", "except", "following", "following-sibling", "for", "function", "ge", "gt", "idiv", "if", "in", "instance", "intersect", "is", "item", "le", "let", "lt", "map", "mod", "namespace", "namespace-node", "ne", "node", "of", "or", "parent", "preceding", "preceding-sibling", "processing-instruction", "return", "satisfies", "schema-attribute", "schema-element", "self", "some", "text", "then", "to", "treat", "union"

numeric

When referring to a type, the term numeric denotes the types xs:integer, xs:decimal, xs:float, and xs:double which are all member types of the built-in union type xs:numeric .

operator function

For each operator and valid combination of operand types, the operator mapping tables specify a result type and an operator function that implements the semantics of the operator for the given types.

partial function application

A static or dynamic function call is a partial function application if one or more arguments is an ArgumentPlaceholder.

partially applied function

A partially applied function is a function created by partial function application.

path expression

A path expression can be used to locate nodes within trees. A path expression consists of a series of one or more steps, separated by "/" or "//", and optionally beginning with "/" or "//".

pattern-separator

pattern-separator is a character used to separate positive and negative sub-pictures in a picture string; the default value is the semi-colon character (;)

per-mille

per-mille is the character used both in the picture string and in the formatted number to indicate that the number is written as a per-thousand fraction; the default value is the Unicode per-mille character (#x2030)

percent

percent is the character used both in the picture string and in the formatted number to indicate that the number is written as a per-hundred fraction; the default value is the percent character (%)

primary expression

Primary expressions are the basic primitives of the language. They include literals, variable references, context item expressions, and function calls. A primary expression may also be created by enclosing any expression in parentheses, which is sometimes helpful in controlling the precedence of operators.

principal node kind

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.

pure union type

A pure union type is an XML Schema union type that satisfies the following constraints: (1) {variety} is union, (2) the {facets} property is empty, (3) no type in the transitive membership of the union type has {variety} list, and (4) no type in the transitive membership of the union type is a type with {variety} union having a non-empty {facets} property

resolve

To resolve a relative URI $rel against a base URI $base is to expand it to an absolute URI, as if by calling the function fn:resolve-uri($rel, $base).

reverse document order

The node ordering that is the reverse of document order is called reverse document order.

same key

Two atomic values K1 and K2 have the same key value if op:same-key(K1, K2) returns true, as specified in Section 17.1.1 op:same-key FO31

schema type

A schema type is a type that is (or could be) defined using the facilities of [XML Schema 1.0] or [XML Schema 1.1] (including the built-in types).

sequence

A sequence is an ordered collection of zero or more items.

sequence type

A sequence type is a type that can be expressed using the SequenceType syntax. Sequence types are used whenever it is necessary to refer to a type in an XPath 3.1 expression. The term sequence type suggests that this syntax is used to describe the type of an XPath 3.1 value, which is always a sequence.

singleton

A sequence containing exactly one item is called a singleton.

singleton focus

A singleton focus is a focus that refers to a single item; in a singleton focus, context item is set to the item, context position = 1 and context size = 1.

stable

Document order is stable, which means that the relative order of two nodes will not change during the processing of a given expression, even if this order is implementation-dependent.

static analysis phase

The static analysis phase depends on the expression itself and on the static context. The static analysis phase does not depend on input data (other than schemas).

static context

The static context of an expression is the information that is available during static analysis of the expression, prior to its evaluation.

static error

An error that can be detected during the static analysis phase, and is not a type error, is a static error.

static function call

A static function call consists of an EQName followed by a parenthesized list of zero or more arguments.

static type

The static type of an expression is the best inference that the processor is able to make statically about the type of the result of the expression.

static typing feature

The Static Typing Feature is an optional feature of XPath that provides support for static semantics, and requires implementations to detect and report type errors during the static analysis phase.

statically known collections

Statically known collections. This is a mapping from strings to types. The string represents the absolute URI of a resource that is potentially available using the fn:collection function. The type is the type of the sequence of items that would result from calling the fn:collection function with this URI as its argument.

statically known documents

Statically known documents. This is a mapping from strings to types. The string represents the absolute URI of a resource that is potentially available using the fn:doc function. The type is the static type of a call to fn:doc with the given URI as its literal argument.

statically known collations

Statically known collations. This is an implementation-defined mapping from URI to collation. It defines the names of the collations that are available for use in processing expressions.

statically known decimal formats

Statically known decimal formats. This is a mapping from QNames to decimal formats, with one default format that has no visible name, referred to as the unnamed decimal format. Each format is available for use when formatting numbers using the fn:format-number function.

statically known default collection type

Statically known default collection type. This is the type of the sequence of items that would result from calling the fn:collection function with no arguments.

statically known function signatures

Statically known function signatures. This is a mapping from (expanded QName, arity) to function signatureDM31.

statically known namespaces

Statically known namespaces. This is a mapping from prefix to namespace URI that defines all the namespaces that are known during static processing of a given expression.

step

A step is a part of a path expression that generates a sequence of items and then filters the sequence by zero or more predicates. The value of the step consists of those items that satisfy the predicates, working from left to right. A step may be either an axis step or a postfix expression.

string value

The string value of a node is a string and can be extracted by applying the Section 2.3 fn:string FO31 function to the node.

substitution group

Substitution groups are defined in Section 2.2.2.2 Element Substitution Group XS1-1 and Section 2.2.2.2 Element Substitution Group XS11-1. Informally, the substitution group headed by a given element (called the head element) consists of the set of elements that can be substituted for the head element without affecting the outcome of schema validation.

subtype

A sequence type A is a subtype of a sequence type B if the judgement subtype(A, B) is true.

subtype substitution

The use of a value whose dynamic type is derived from an expected type is known as subtype substitution.

symbol

Each rule in the grammar defines one symbol, using the following format:

symbol ::= expression
symbol separators

Whitespace and Comments function as symbol separators. For the most part, they are not mentioned in the grammar, and may occur between any two terminal symbols mentioned in the grammar, except where that is forbidden by the /* ws: explicit */ annotation in the EBNF, or by the /* xgc: xml-version */ annotation.

terminal

A terminal is a symbol or string or pattern that can appear in the right-hand side of a rule, but never appears on the left-hand side in the main grammar, although it may appear on the left-hand side of a rule in the grammar for terminals.

type annotation

Each element node and attribute node in an XDM instance has a type annotation (described in Section 2.7 Schema Information DM31). The type annotation of a node is a reference to an XML Schema type.

type error

A type error may be raised during the static analysis phase or the dynamic evaluation phase. During the static analysis phase, a type error occurs when the static type of an expression does not match the expected type of the context in which the expression occurs. During the dynamic evaluation phase, a type error occurs when the dynamic type of a value does not match the expected type of the context in which the value occurs.

type promotion

Under certain circumstances, an atomic value can be promoted from one type to another. Type promotion is used in evaluating function calls (see 3.1.5.1 Evaluating Static and Dynamic Function Calls) and operators that accept numeric or string operands (see B.2 Operator Mapping).

typed value

The typed value of a node is a sequence of atomic values and can be extracted by applying the Section 2.4 fn:data FO31 function to the node.

value

In the data model, a value is always a sequence.

variable reference

A variable reference is an EQName preceded by a $-sign.

variable values

Variable values. This is a mapping from expanded QName to value. It contains the same expanded QNames as the in-scope variables in the static context for the expression. The expanded QName is the name of the variable and the value is the dynamic value of the variable, which includes its dynamic type.

warning

In addition to static errors, dynamic errors, and type errors, an XPath 3.1 implementation may raise warnings, either during the static analysis phase or the dynamic evaluation phase. The circumstances in which warnings are raised, and the ways in which warnings are handled, are implementation-defined.

whitespace

A whitespace character is any of the characters defined by [http://www.w3.org/TR/REC-xml/#NT-S].

xs:anyAtomicType

xs:anyAtomicType is an atomic type that includes all atomic values (and no values that are not atomic). Its base type is xs:anySimpleType from which all simple types, including atomic, list, and union types, are derived. All primitive atomic types, such as xs:decimal and xs:string, have xs:anyAtomicType as their base type.

xs:dayTimeDuration

xs:dayTimeDuration is derived by restriction from xs:duration. The lexical representation of xs:dayTimeDuration is restricted to contain only day, hour, minute, and second components.

xs:error

xs:error is a simple type with no value space. It is defined in Section 3.16.7.3 xs:error XS11-1 and can be used in the 2.5.4 SequenceType Syntax to raise errors.

xs:untyped

xs:untyped is used as the type annotation of an element node that has not been validated, or has been validated in skip mode.

xs:untypedAtomic

xs:untypedAtomic is an atomic type that is used to denote untyped atomic data, such as text that has not been assigned a more specific type.

xs:yearMonthDuration

xs:yearMonthDuration is derived by restriction from xs:duration. The lexical representation of xs:yearMonthDuration is restricted to contain only year and month components.

zero-digit

zero-digit is the character used to represent the digit zero; the default value is the Western digit zero (#x30). This character must be a digit (category Nd in the Unicode property database), and it must have the numeric value zero. This property implicitly defines the ten Unicode characters that are used to represent the values 0 to 9: Unicode is organized so that each set of decimal digits forms a contiguous block of characters in numerical sequence. Within the picture string any of these ten character can be used (interchangeably) as a place-holder for a mandatory digit. Within the final result string, these ten characters are used to represent the digits zero to nine.

H Backwards Compatibility (Non-Normative)

H.1 Incompatibilities relative to XPath 3.0

The following names are now reserved, and cannot appear as function names (see A.3 Reserved Function Names):

  • map

  • array

H.2 Incompatibilities relative to XPath 2.0

The following names are now reserved, and cannot appear as function names (see A.3 Reserved Function Names):

  • function

  • namespace-node

  • switch

If U is a union type with T as one of its members, and if E is an element with T as its type annotation, the expression E instance of element(*, U) returns true in both XPath 3.0 and 3.1. In XPath 2.0, it returns false.

Note:

This is not an incompatibility with XPath 3.0. It should be included in XPath 3.0 as an incompatibility with XPath 2.0 but it was discovered after publication.

H.3 Incompatibilities relative to XPath 1.0

This appendix provides a summary of the areas of incompatibility between XPath 3.1 and [XML Path Language (XPath) Version 1.0]. In each of these cases, an XPath 3.1 processor is compatible with an XPath 2.0 processor or an XPath 3.0 processor.

Three separate cases are considered:

  1. Incompatibilities that exist when source documents have no schema, and when running with XPath 1.0 compatibility mode set to true. This specification has been designed to reduce the number of incompatibilities in this situation to an absolute minimum, but some differences remain and are listed individually.

  2. Incompatibilities that arise when XPath 1.0 compatibility mode is set to false. In this case, the number of expressions where compatibility is lost is rather greater.

  3. Incompatibilities that arise when the source document is processed using a schema (whether or not XPath 1.0 compatibility mode is set to true). Processing the document with a schema changes the way that the values of nodes are interpreted, and this can cause an XPath expression to return different results.

H.3.1 Incompatibilities when Compatibility Mode is true

The list below contains all known areas, within the scope of this specification, where an XPath 3.1 processor running with compatibility mode set to true will produce different results from an XPath 1.0 processor evaluating the same expression, assuming that the expression was valid in XPath 1.0, and that the nodes in the source document have no type annotations other than xs:untyped and xs:untypedAtomic.

Incompatibilities in the behavior of individual functions are not listed here, but are included in an appendix of [XQuery and XPath Functions and Operators 3.1].

Since both XPath 1.0 and XPath 3.1 leave some aspects of the specification implementation-defined, there may be incompatibilities in the behavior of a particular implementation that are outside the scope of this specification. Equally, some aspects of the behavior of XPath are defined by the host language.

  1. Consecutive comparison operators such as A < B < C were supported in XPath 1.0, but are not permitted by the XPath 3.1 grammar. In most cases such comparisons in XPath 1.0 did not have the intuitive meaning, so it is unlikely that they have been widely used in practice. If such a construct is found, an XPath 3.1 processor will report a syntax error, and the construct can be rewritten as (A < B) < C

  2. When converting strings to numbers (either explicitly when using the number function, or implicitly say on a function call), certain strings that converted to the special value NaN under XPath 1.0 will convert to values other than NaN under XPath 3.1. These include any number written with a leading + sign, any number in exponential floating point notation (for example 1.0e+9), and the strings INF and -INF.

    Furthermore, the strings Infinity and -Infinity, which were accepted by XPath 1.0 as representations of the floating-point values positive and negative infinity, are no longer recognized. They are converted to NaN when running under XPath 3.1 with compatibility mode set to true, and cause a dynamic error when compatibility mode is set to false.

  3. XPath 3.1 does not allow a token starting with a letter to follow immediately after a numeric literal, without intervening whitespace. For example, 10div 3 was permitted in XPath 1.0, but in XPath 3.1 must be written as 10 div 3.

  4. The namespace axis is deprecated as of XPath 2.0. Implementations may support the namespace axis for backward compatibility with XPath 1.0, but they are not required to do so. (XSLT 2.0 requires that if XPath backwards compatibility mode is supported, then the namespace axis must also be supported; but other host languages may define the conformance rules differently.)

  5. In XPath 1.0, the expression -x|y parsed as -(x|y), and returned the negation of the numeric value of the first node in the union of x and y. In XPath 3.1, this expression parses as (-x)|y. When XPath 1.0 Compatibility Mode is true, this will always cause a type error.

  6. The rules for converting numbers to strings have changed. These may affect the way numbers are displayed in the output of a stylesheet. For numbers whose absolute value is in the range 1E-6 to 1E+6, the result should be the same, but outside this range, scientific format is used for non-integral xs:float and xs:double values.

  7. If one operand in a general comparison is a single atomic value of type xs:boolean, the other operand is converted to xs:boolean when XPath 1.0 compatibility mode is set to true. In XPath 1.0, if neither operand of a comparison operation using the <, <=, > or >= operator was a node set, both operands were converted to numbers. The result of the expression true() > number('0.5') is therefore true in XPath 1.0, but is false in XPath 3.1 even when compatibility mode is set to true.

  8. In XPath 3.1, a type error is raised if the PITarget specified in a SequenceType of form processing-instruction(PITarget) is not a valid NCName. In XPath 1.0, this condition was not treated as an error.

H.3.2 Incompatibilities when Compatibility Mode is false

Even when the setting of the XPath 1.0 compatibility mode is false, many XPath expressions will still produce the same results under XPath 3.1 as under XPath 1.0. The exceptions are described in this section.

In all cases it is assumed that the expression in question was valid under XPath 1.0, that XPath 1.0 compatibility mode is false, and that all elements and attributes are annotated with the types xs:untyped and xs:untypedAtomic respectively.

In the description below, the terms node-set and number are used with their XPath 1.0 meanings, that is, to describe expressions which according to the rules of XPath 1.0 would have generated a node-set or a number respectively.

  1. When a node-set containing more than one node is supplied as an argument to a function or operator that expects a single node or value, the XPath 1.0 rule was that all nodes after the first were discarded. Under XPath 3.1, a type error occurs if there is more than one node. The XPath 1.0 behavior can always be restored by using the predicate [1] to explicitly select the first node in the node-set.

  2. In XPath 1.0, the < and > operators, when applied to two strings, attempted to convert both the strings to numbers and then made a numeric comparison between the results. In XPath 3.1, these operators perform a string comparison using the default collating sequence. (If either value is numeric, however, the results are compatible with XPath 1.0)

  3. When an empty node-set is supplied as an argument to a function or operator that expects a number, the value is no longer converted implicitly to NaN. The XPath 1.0 behavior can always be restored by using the number function to perform an explicit conversion.

  4. More generally, the supplied arguments to a function or operator are no longer implicitly converted to the required type, except in the case where the supplied argument is of type xs:untypedAtomic (which will commonly be the case when a node in a schemaless document is supplied as the argument). For example, the function call substring-before(10 div 3, ".") raises a type error under XPath 3.1, because the arguments to the substring-before function must be strings rather than numbers. The XPath 1.0 behavior can be restored by performing an explicit conversion to the required type using a constructor function or cast.

  5. The rules for comparing a node-set to a boolean have changed. In XPath 1.0, an expression such as $node-set = true() was evaluated by converting the node-set to a boolean and then performing a boolean comparison: so this expression would return true if $node-set was non-empty. In XPath 3.1, this expression is handled in the same way as other comparisons between a sequence and a singleton: it is true if $node-set contains at least one node whose value, after atomization and conversion to a boolean using the casting rules, is true.

    This means that if $node-set is empty, the result under XPath 3.1 will be false regardless of the value of the boolean operand, and regardless of which operator is used. If $node-set is non-empty, then in most cases the comparison with a boolean is likely to fail, giving a dynamic error. But if a node has the value "0", "1", "true", or "false", evaluation of the expression may succeed.

  6. Comparisons of a number to a boolean, a number to a string, or a string to a boolean are not allowed in XPath 3.1: they result in a type error. In XPath 1.0 such comparisons were allowed, and were handled by converting one of the operands to the type of the other. So for example in XPath 1.0 4 = true() was true; 4 = "+4" was false (because the string +4 converts to NaN), and false = "false" was false (because the string "false" converts to the boolean true). In XPath 3.0 all these comparisons are type errors.

  7. Additional numeric types have been introduced, with the effect that arithmetic may now be done as an integer, decimal, or single- or double-precision floating point calculation where previously it was always performed as double-precision floating point. The result of the div operator when dividing two integers is now a value of type decimal rather than double. The expression 10 div 0 raises an error rather than returning positive infinity.

  8. The rules for converting strings to numbers have changed. The implicit conversion that occurs when passing an xs:untypedAtomic value as an argument to a function that expects a number no longer converts unrecognized strings to the value NaN; instead, it reports a dynamic error. This is in addition to the differences that apply when backwards compatibility mode is set to true.

  9. Many operations in XPath 3.1 produce an empty sequence as their result when one of the arguments or operands is an empty sequence. Where the operation expects a string, an empty sequence is usually considered equivalent to a zero-length string, which is compatible with the XPath 1.0 behavior. Where the operation expects a number, however, the result is not the same. For example, if @width returns an empty sequence, then in XPath 1.0 the result of @width+1 was NaN, while with XPath 3.1 it is (). This has the effect that a filter expression such as item[@width+1 != 2] will select items having no width attribute under XPath 1.0, and will not select them under XPath 3.1.

  10. The typed value of a comment node, processing instruction node, or namespace node under XPath 3.1 is of type xs:string, not xs:untypedAtomic. This means that no implicit conversions are applied if the value is used in a context where a number is expected. If a processing-instruction node is used as an operand of an arithmetic operator, for example, XPath 1.0 would attempt to convert the string value of the node to a number (and deliver NaN if unsuccessful), while XPath 3.1 will report a type error.

  11. In XPath 1.0, it was defined that with an expression of the form A and B, B would not be evaluated if A was false. Similarly in the case of A or B, B would not be evaluated if A was true. This is no longer guaranteed with XPath 3.1: the implementation is free to evaluate the two operands in either order or in parallel. This change has been made to give more scope for optimization in situations where XPath expressions are evaluated against large data collections supported by indexes. Implementations may choose to retain backwards compatibility in this area, but they are not obliged to do so.

  12. In XPath 1.0, the expression -x|y parsed as -(x|y), and returned the negation of the numeric value of the first node in the union of x and y. In XPath 3.1, this expression parses as (-x)|y. When XPath 1.0 Compatibility Mode is false, this will cause a type error, except in the situation where x evaluates to an empty sequence. In that situation, XPath 3.1 will return the value of y, whereas XPath 1.0 returned the negation of the numeric value of y.

H.3.3 Incompatibilities when using a Schema

An XPath expression applied to a document that has been processed against a schema will not always give the same results as the same expression applied to the same document in the absence of a schema. Since schema processing had no effect on the result of an XPath 1.0 expression, this may give rise to further incompatibilities. This section gives a few examples of the differences that can arise.

Suppose that the context node is an element node derived from the following markup: <background color="red green blue"/>. In XPath 1.0, the predicate [@color="blue"] would return false. In XPath 3.1, if the color attribute is defined in a schema to be of type xs:NMTOKENS, the same predicate will return true.

Similarly, consider the expression @birth < @death applied to the element <person birth="1901-06-06" death="1991-05-09"/>. With XPath 1.0, this expression would return false, because both attributes are converted to numbers, which returns NaN in each case. With XPath 3.1, in the presence of a schema that annotates these attributes as dates, the expression returns true.

Once schema validation is applied, elements and attributes cannot be used as operands and arguments of expressions that expect a different data type. For example, it is no longer possible to apply the substring function to a date to extract the year component, or to a number to extract the integer part. Similarly, if an attribute is annotated as a boolean then it is not possible to compare it with the strings "true" or "false". All such operations lead to type errors. The remedy when such errors occur is to introduce an explicit conversion, or to do the computation in a different way. For example, substring-after(@temperature, "-") might be rewritten as abs(@temperature).

In the case of an XPath 3.1 implementation that provides the static typing feature, many further type errors will be reported in respect of expressions that worked under XPath 1.0. For example, an expression such as round(../@price) might lead to a static type error because the processor cannot infer statically that ../@price is guaranteed to be numeric.

Schema validation will in many cases perform whitespace normalization on the contents of elements (depending on their type). This will change the result of operations such as the string-length function.

Schema validation augments the data model by adding default values for omitted attributes and empty elements.

I Change Log (Non-Normative)

This appendix lists the changes that have been made to this specification since the publication of XPath 3.0 Recommendation.

I.1 Changes since the Candidate Recommendation of 17 December 2015

I.1.1 Substantive Changes

  1. Added switch expressions to list of conditional expressions in 2.3.4 Errors and Optimization. Resolves Bug 29320.

  2. If the content expression is not provided explicitly, the content expression is (). Previously, no content expression was provided, but the value of the content was specified. This caused problems evaluating functions with empty bodies, and failed to provide a host language expression for the function implementation in the data model.

  3. Partial function application never returns a map or an array. If $F is a map or an array, then $F(?) is a partial function application that returns a function, but the function it returns is not a map nor an array. Resolves action A-640-03.

  4. Added xs:anySimpleType to the list of types that have no contructor function. Resolves Bug 29583.

  5. Added requirement to specify minimum values for some date and time functions. Resolves Bug 29576.

  6. Changed the rules for atomization in lookup in 3.11.3 The Lookup Operator ("?") for Maps and Arrays. Resolves Bug 29622.

  7. Allowed more specific typing of maps, arrays, and functions. Affects 2.5.5.8 Map Test, 2.5.5.9 Array Test, 2.5.6.2 The judgement subtype-itemtype(Ai, Bi) , 3.1.5.1 Evaluating Static and Dynamic Function Calls, and 3.1.7 Inline Function Expressions. Resolves Bug 29586.

  8. Changed 3.11.1.2 Map Lookup using Function Call Syntax to define semantics using only Section 17.1.6 map:get FO31, changed 3.11.2.2 Array Lookup using Function Call Syntax to define semantics using only Section 17.3.2 array:get FO31, thus aligning edge cases and eliminating the possibility of discrepancies creeping in. Resolves Bug 29683.

I.1.2 Editorial Changes

  1. Significantly changed the prose in 3.1.5.1 Evaluating Static and Dynamic Function Calls. Resolves Bug 29277.

  2. Created formal definitions for implementation-defined function and host language function .

  3. Fixed a problem with conditional text in 2.5.6.2 The judgement subtype-itemtype(Ai, Bi) : Bi is function(*), Ai is a FunctionTest. Resolves Bug 29414.

  4. Changed definition of same key, redefining it in terms of Section 17.1.1 op:same-key FO31. Resolves Bug 29362.

  5. Moved definition of enclosed expression to prevent it from disappearing in XPath. Resolves Bug 29382.

  6. Modified 4 Conformance to be more consistent with RFC2119. Resolves Bug 29498.

  7. Deleted erroneous note in 3.11.3.1 Unary Lookup that claimed array?* is equivalent to array:flatten. Resolves Bug 29487.

  8. Provided definitions of implementation-defined function, moved definition of external function , added definition of host language function . Eliminated references to "host programming languages". Clarified wording on external function declarations. Resolves Bug 29509.

  9. Removed a dangling otherwise clause that belonged to the XQuery specification. Resolves Bug 29693.

  10. Made EBNF productions in the document body look the same as those in Appendix A (by adding production annotations to the former), thus eliminating the need to specify which is normative.

  11. Clarified ambiguous wording about comments in A.2.4.2 Explicit Whitespace Handling. Resolves Bug 29700.

I.2 Changes introduced in the Candidate Recommendation of 17 December 2015

I.2.1 Substantive Changes

  1. Significant rewrite of 2.5.7 xs:error. Resolves Bug 29119.

  2. Removed non-normative description of casting rules, referring to the normative definition instead. Resolves Bug 29192.

  3. To allow streaming, context size may be undefined in an XPath implementation, in which case last() raises an error. Resolves Bug 29227.

  4. Clarified semantics of external context item declaration in library modules. Resolves Bug 29246.

  5. In 2.1.1 Static Context, clarified that only function signatures that are present in the static context — not actual function implementations. Resolves Bug 28175.

  6. Changed rules for same key value to improve handling of maps in which keys may or may not have timezones. Resolves Bug 28632 and Bug 28729.

  7. The precedence of the 3.16 Arrow operator (=>) has changed. Resolves Bug 27537.

  8. The error when atomizing a function, map, or array is [err:FOTY0013], not [err:FOTY0012]. Resolves Bug 27610.

  9. Collections can now contain any item. This affects statically known collections, statically known collection type, available collections (formerly known as available node collections, default collection (formerly known as default node collection, 2.2.4 Consistency Constraints, 2.4.4 Input Sources.

  10. Fixed outdated text that restricted constructor functions to atomic or generalized atomic types. Resolves Bug 28915.

  11. Changed the semantics of 3.11.3.2 Postfix Lookup . Resolves Bug 27536, fixing inadequacies in the earlier resolution.

I.2.2 Editorial Changes

  1. Refactored the grammar to use EnclosedExpr consistently.

  2. Added a paragraph clarifying the type of an array as a function. Resolves Bug 29260.

  3. Clarified how function coercion applies to maps and arrays using two examples. Resolves Bug 27059.

  4. Removed nine operators from B.2 Operator Mapping to eliminate redundant specification. Resolves Bug 22456.

  5. Modified 4 Conformance to use the term MUST NOT. Resolves Bug 28023.

  6. Added explicit semantics for NCName in 3.11.3 The Lookup Operator ("?") for Maps and Arrays. Resolves Bug 28701.

  7. Deleted obsolete discussion of named function references and xs:numeric. Resolves Bug 28081.

  8. Removed the unused definition of the initial context item. Resolves Bug 28905.

  9. Significantly changed description of names in 2 Basics. Resolves Bug 28241.

  10. Fixed a number of dangling references to XQuery/XPath 3.0 where 3.1 was intended. Resolves Bug 28782.

  11. Clarified the text in H Backwards Compatibility about SequenceType matching and union types. Resolves Bug 28894.

  12. Renamed Available Resource Collections to Available URI Collections, renamed Available Node Collections to Available Collections, renamed Default Resource Collection to Default URI Collection, renamed Default Node Collection to Default Collection. Resolves Bug 28957.

  13. Clarified the definition of built-in functions. Resolves Bug 28282.

  14. Clarified the text in 3.16 Arrow operator (=>). Resolves Bug 29346.

I.3 Changes introduced in the Candidate Recommendation of 18 December 2014

I.3.1 Substantive Changes

  1. If a value in a map constructor or a member in an array constructor is a map or array, it is copied. If a value in a map constructor or a member in an array constructor is a node, it is not copied. Resolves Bug 26958.

  2. In the definition of numeric, we now state that all numeric types are member types of xs:numeric. Resolves Bug 20631.

  3. Modified rule 14 of 2.5.6.2 The judgement subtype-itemtype(Ai, Bi) . Resolves Bug 27175.

  4. In 3.11.3.1 Unary Lookup, if the context item is not a map or an array, a type error [err:XPTY0004] is raised. If the array index is out of bounds, [err:FOAY0001] is raised. Resolves Bug 27382.

  5. Changed the semantics of 3.11.3.2 Postfix Lookup to for $a in E, $b in S return $a($b). Resolves Bug 27536.

  6. Arrays in element content are flattened, not atomized. Resolves Bug 27463.

  7. 3.16 Arrow operator (=>) is now well defined when the left hand operand is a sequence rather than an item. Partially resolves Bug 27537.

I.3.2 Editorial Changes

  1. Modified the wording used to describe node identity per Bug 27048, comment #2.

  2. Fixed specification gaps in unary lookup. Resolves Bug 27455.

I.4 Changes introduced in prior Working Drafts

  1. Added 3.11.1 Maps and 3.11.2 Arrays. These are the most important new features in XPath 3.1

  2. Clarified error code XQST0134 for XPath implementations that do not support the namespace axis, default axis for namespace-node() in abbreviated syntax. Resolves Bug 26788.

  3. Simplified type conversions for value comparisons and orderspecs, eliminating the concept of lowest common supertype. Resolves Bug 26453.

  4. Modified text of 3.7.2 General Comparisons to clarify that the result of a comparison can be either false or an error. Resolves Bug 26832.

  5. Added 3.11.1.1 Map Constructors and 3.11.1.2 Map Lookup using Function Call Syntax.

  6. Added 3.11.2.1 Array Constructors and 3.11.2.2 Array Lookup using Function Call Syntax.

  7. Defined 2.4.2 Atomization of an array (atomization of a map is an error).

  8. Added 2.5.5.8 Map Test and 2.5.5.9 Array Test to test whether an item is a map or an array respectively.

  9. Added exponent-separator to the static context to support fn:format-number().

  10. Eliminated use of to array functions that are no longer in Functions & and Operators, such as fn:seq(). Changed ay: prefix to array: to match current Functions & and Operators.

  11. Added 3.11.1.2 Map Lookup using Function Call Syntax, replacing the less general map lookup operator from the previous Working Draft.

  12. 3.11.2.2 Array Lookup using Function Call Syntax with negative integer arguments are no longer type errors, they are dynamic errors.

  13. If the keys in a 3.11.1.1 Map Constructors contain both date/time values with a timezone and date/time values with no timezone, a dynamic error is raised.

  14. In maps, keys of type xs:untypedAtomic are no longer converted to xs:string.