この文書は、W3CのXML Path Language (XPath) の翻訳です。正式な版は、W3Cのサイトにある英語版であり、この翻訳ではありません。この翻訳は原文と技術的に等価なことを意図していますが、翻訳上の誤りが存在する可能性があります。

原文はつぎのURLで参照することができます。 http://www.w3.org/TR/1999/REC-xpath-19991116

翻訳責任:インフォテリア株式会社 最終更新日:2000年5月23日(更新履歴)
この翻訳に関するコメントは dev_request@infoteria.co.jp まで

W3C

XML Path Language (XPath)
バージョン 1.0

W3C 勧告 1999 年 11 月 16 日

このバージョン:
http://www.w3.org/TR/1999/REC-xpath-19991116
(XML 版 または HTML 版)
最新のバージョン:
http://www.w3.org/TR/xpath
以前のバージョン:
http://www.w3.org/TR/1999/PR-xpath-19991008
http://www.w3.org/1999/08/WD-xpath-19990813
http://www.w3.org/1999/07/WD-xpath-19990709
http://www.w3.org/TR/1999/WD-xslt-19990421
編者:
James Clark <jjc@jclark.com>
Steve DeRose (Inso Corp. および Brown University) <Steven_DeRose@Brown.edu>

要約

XPath は、XML ドキュメントの一部をアドレッシングするための言語であり、XSLT および XPointer で使用するように設計されている。

この文書の状態

この文書は、W3C のメンバおよびその他の関係者が評価し、W3C 勧告として担当の責任者が承認したものである。 今後変更される可能性はなく、他の文書において参考資料として使用したり、あるいは基準となる参考文献として引用することができる。 勧告の策定にあたって W3C が担う役割は、この仕様を広く普及させることにある。 これにより Web の機能性と相互運用性を向上させることができる。

この仕様に関する正誤表は http://www.w3.org/1999/11/REC-xpath-19991116-errata で参照することができる。

この仕様に関するコメントの宛先は www-xpath-comments@w3.org である。なお、コメントのアーカイブも利用できる。

この仕様の基準となるバージョンは英語版のみであるが、翻訳版を http://www.w3.org/Style/XSL/translations.html で参照することができる。

W3C 勧告の一覧、およびその他の技術文書は http://www.w3.org/TR で入手できる。

この仕様は XSL 作業グループ (XSL Working Group) と XML Linking 作業グループ (XML Linking Working Group) との共同作業であり、W3C のスタイルに関する活動 (W3C Style activity) および XML に関する活動 (W3C XML activity) の一部でもある。

目次

1 一般事項
2 ロケーションパス
    2.1 ロケーションステップ
    2.2 基準点(Axes)
    2.3 ノードテスト
    2.4 述語(Predicates)
    2.5 省略シンタックス
3
    3.1 基本
    3.2 関数呼び出し
    3.3 ノード集合
    3.4 ブール
    3.5
    3.6 文字列
    3.7 字句構造
4 コア関数ライブラリ
    4.1 ノード集合関数
    4.2 文字列関数
    4.3 ブール関数
    4.4 数値関数
5 データモデル
    5.1 ルートノード
    5.2 エレメントノード
        5.2.1 ユニーク ID 
    5.3 アトリビュートノード
    5.4 ネームスペースノード
    5.5 プロセッシングインストラクションノード
    5.6 コメントノード
    5.7 テキストノード
6 適合性

付録

A 参考文献
    A.1 基準となる参考文献
    A.2 その他の参考文献
B XML Information Setとのマッピング (規定外)

1 一般事項

XPath は、XSL Transformations [XSLT] と XPointer[XPointer] との間で共有する機能に、共通のシンタックスとセマンティクスを盛り込もうという試みの成果である。 XPath の第一の目的は、XML[XML] ドキュメントの一部をアドレッシングすることである。 これをサポートするために、XPath では文字列や数値、ブール値 (boolean) を操作するための基本的な機能も提供している。 URI や XML アトリビュート値の中で XPath を利用しやすくするために、XPath は XML を使用せずに定義されたコンパクトなシンタックスを使用している。 XPath は XML ドキュメントの表面的なシンタックスというよりは、XMLドキュメントの抽象的論理的な構造をもとに機能する。 XPath という名前は、XML ドキュメントの階層構造をナビゲートする際に、URL と同様のパスノテーションを利用するところから付けられている。

アドレッシングの機能に加えて、XPath は、そのサブセットがマッチング (あるノードがあるパターンに一致するかどうかのテスト) に流用できるように設計されている。XPath のこのような使用方法については XSLT に記載されている。

XPath では、ノードのツリーとして XML ドキュメントを扱う。 エレメントノードやアトリビュートノード、テキストノードなど、ノードにはさまざまな型がある。 XPath ではこれらのノード型のそれぞれについて、文字列値を計算する方法を定義している。ノードの型によっては名前を持つものもある。 XPath は XML ネームスペース [XML Names] を完全にサポートしている。 従ってノードの名前はローカルパートと、null の場合もあるネームスペース URI を組み合わせたものである。これは 展開された名前と呼ばれる。 データモデルについては [5 データモデル] でその詳細を説明している。

XPath の主な構文構造は式である。 式は Exprプロダクション に該当する。 式は評価され、オブジェクトを生成する。このオブジェクトは、以下の4つの基本型のうちのいずれかになる。

式はコンテキストと関連して評価される。 XSLT と XPointer では、使用する XPath 式でのコンテキストの決定方法を規定している。 コンテキストは以下のもので構成される。

コンテキストポジションの値は、常にコンテキストサイズの値以下となる。

変数のバインディングは変数名から変数値へのマッピングである。 変数の値は1つのオブジェクトであり、式の値として使用できるいずれかの型を持つ。また、ここでは規定されていない追加の型でもかまわない。

関数ライブラリは関数名から関数へのマッピングである。 各関数はゼロ個以上の引数を取り、1つの結果を返す。 この文書では、XPath を実装する際に常にサポートしなければならない (must) コア関数ライブラリを定義する ([4 コア関数ライブラリ] 参照)。 コア関数ライブラリに含める関数の場合、引数や結果は4つの基本型のいずれかになる。 XSLT と XPointer はどちらも、追加の関数を定義して XPath を拡張している。これらの関数の中には、4つの基本型をもとに機能するものもあれば、XSLT や XPointer で定義した追加のデータ型をもとに機能するものもある。

ネームスペース宣言は、プレフィックスからネームスペース URI へのマッピングである。

部分式の評価に使用する変数のバインディングや関数ライブラリ、ネームスペース宣言は、その部分式を含む式の評価に使用するものと常に同じである。 ただし、部分式の評価に使用するコンテキストノードやコンテキストポジション、コンテキストサイズは、その部分式を含む式の評価に使用するものとは異なる場合がある。 いくつかの種類の式はコンテキストノードを変更する。述語だけがコンテキストポジションやコンテキストサイズを変更する ([2.4 述語] 参照)。 式の評価について記述する際には、コンテキストノードやコンテキストポジション、コンテキストサイズが部分式の評価において変化するかどうかは常に明示的に記述されている。コンテキストノードやコンテキストポジション、コンテキストサイズに関して何も記述されていない場合は、その式を部分式として評価する場合には、それらは変更されない。

XPath 式は XML のアトリビュートで記述することが多い。 この項で規定する文法は、XML 1.0 で正規化した後のアトリビュート値に適用される。 そのため、たとえば文法で < という文字を使用する場合、XML ソース内に < と記述してはならない (must)。この場合 XML 1.0 のルールに従ってクオートしなければならない (must)。たとえば &lt; というように記述する。 式の内部では、リテラル文字列は一重引用符または二重引用符で区切られるが、これらは XML アトリビュートを区切るためにも用いられる。 式の中に引用符があると、XML プロセッサはアトリビュート値の記述が終了したものと判断してしまうことがある。これを避けるために、引用符をキャラクターリファレンス (&quot; または &apos;) を使用して入力することができる。 あるいは XML アトリビュートを二重引用符で区切るのであれば式では一重引用符を用いるようにもできるし、逆にアトリビュートを一重引用符で区切り、式を二重引用符で区切ることもできる。

ロケーションパスは重要な式の1つである。 ロケーションパスはコンテキストノードに関係するノードの集合を選択する。 ロケーションパスを評価した結果は、そのロケーションパスによって選択されたノードを含むノード集合となる。 ロケーションパスでは、式を繰り返し記述してノード集合にフィルタをかけることが可能である。 ロケーションパスは LocationPathプロダクション に該当する。

以降に示す文法では、非終端の QNameNCName[XML Names] で定義され、S[XML] で定義される。 この文法では [XML] と同じ EBNF ノテーションを使用する(文法記号の最初の文字が常に大文字になることだけ異なる)。

式のパースは、まず最初にパース対象の文字列をトークンに分割し、次にその結果の一連のトークンをパースするかたちで行われる。 空白はトークンの間で自由に使うことができる。 トークン化のプロセスは [3.7 字句構造] で説明する。

2 ロケーションパス

ロケーションパスは、XPath で特に一般的な文法上のきまりではない (LocationPathExpr の特殊なケースである) が、最も重要であるためまず最初に説明する。

すべてのロケーションパスは、単純だが冗長なシンタックスを利用し表現することができる。 一般的な表現をより簡潔に表現することができる構文的省略も多く存在する。 この項ではまず、省略しないシンタックスを使用したロケーションパスのセマンティクスについて説明する。 その後で、省略シンタックスをどのように省略しないシンタックスに展開するのかを説明する ([2.5 省略シンタックス] 参照)。

以下の例は、省略しないシンタックスを使用したロケーションパスである。

ロケーションパスには相対ロケーションパスと絶対ロケーションパスの2種類がある。

相対ロケーションパスは / で区切られた1つ以上のロケーションステップを並べたものである。この相対ロケーションパス内の各ステップは、左から右に結合される。それぞれのステップは、コンテキストノードに対して相対的なノードの集合を順次選択する。各ステップの最初のシーケンスは、次のような方法で後続のステップと結合される。各ステップの最初のシーケンスでは、コンテキストノードに対して相対的にノードの集合を選択する。そして、その集合内の各ノードが、後続のステップのコンテキストノードとして使用される。後続のステップで特定されるノードの集合は1つに結合される。この結合されたノード集合が、結合されたステップによって特定されるノード集合となる。たとえば child::div/child::para はコンテキストノードが持つ div という名前の子エレメントの para という名前の子エレメントを選択する。言いかえれば div という名前の親エレメントを持つ para という名前の孫エレメントを選択する。

絶対ロケーションパスは / とその後に続く相対ロケーションパス (相対ロケーションパスはなくてもかまわない) を組み合わせたものである。/ はコンテキストノードを含むドキュメントのルートノードを意味する。相対ロケーションパスを後に続けた場合は、そのロケーションパスはノードの集合を選択する。このノードの集合は、コンテキストノードを含むドキュメントのルートノードに対して相対的な相対ロケーションパスを使用して選択される。

ロケーションパス
[1]   LocationPath   ::=   RelativeLocationPath
| AbsoluteLocationPath
[2]   AbsoluteLocationPath   ::=   '/' RelativeLocationPath?
| AbbreviatedAbsoluteLocationPath
[3]   RelativeLocationPath   ::=   Step
| RelativeLocationPath '/' Step
| AbbreviatedRelativeLocationPath

2.1 ロケーションステップ

ロケーションステップは次のような3つの部分からなる。

ロケーションステップのシンタックスでは、基準点名とノードテストとが二重コロンで区切られ、その後に角括弧で囲まれた式がゼロ個以上続く。 たとえば child::para[position()=1] では、child が基準点の名前、para がノードテスト、[position()=1] が述語である。

ロケーションステップを使用して選択するノード集合は、まずは基準点とノードテストから最初のノード集合を生成し、次にその最初のノード集合に対して述語を使って順次フィルタをかけたものである。

この最初のノード集合は、コンテキストノードとの間に基準点で指定された関係を持ち、なおかつノードテストで指定したノード型と展開された名前を持つ複数のノードである。たとえばロケーションステップ descendant::para は、コンテキストノードの para という名前の子孫エレメントを選択する。この descendant は最初のノード集合内の各ノードがコンテキストノードの子孫でなければならない (must) ことを指定し、para は最初のノード集合内の各ノードが para という名前のエレメントでなければならない (must) ことを指定する。どのような基準点を使用できるのかについては [2.2 基準点] で説明する。またノードテストについては [2.3 ノードテスト] で説明する。ノードテストには、基準点により意味が異なるものがある。

1つめの述語で最初のノード集合をフィルタリングして新しいノード集合を生成し、このノード集合がさらに2つめの述語でフィルタリングされる、という処理が続く。このようにして残ったものが、最終的にそのロケーションステップを使用して選別したノード集合になる。各述語内の式がどのように評価されるかは基準点に左右される。そのため述語のセマンティクスは、基準点と関連して定義される。[2.4 述語] 参照。

ロケーションステップ
[4]   Step   ::=   AxisSpecifier NodeTest Predicate*
| AbbreviatedStep
[5]   AxisSpecifier   ::=   AxisName '::'
| AbbreviatedAxisSpecifier

2.2 基準点

次のような基準点を利用することができる。

注: 一つのドキュメントは (アトリビュートノードとネームスペースノードは除いて) ancestor および descendantfollowingprecedingself の基準点によって分割される。 つまり、これらの基準点には重なる部分はなく、全て一緒にするとドキュメント内のすべてのノードを指定することになる。
基準点
[6]   AxisName   ::=   'ancestor'
| 'ancestor-or-self'
| 'attribute'
| 'child'
| 'descendant'
| 'descendant-or-self'
| 'following'
| 'following-sibling'
| 'namespace'
| 'parent'
| 'preceding'
| 'preceding-sibling'
| 'self'

2.3 ノードテスト

どの基準点にも主ノード型がある。基準点がエレメントを選択する場合、主ノード型はエレメントである。それ以外は基準点に使えるノードの型が主ノード型になる。 従って、

QName のノードテストは、ノードの型 ([5 データモデル] 参照) が主ノード型で、なおかつ QName で指定する展開された名前と同じ展開された名前を持つときだけ真になる。 たとえば child::para は、コンテキストノードの para という名前の子エレメントを選択する。コンテキストノードに para という名前の子エレメントがない場合には空のノード集合を選択する。 attribute::href はコンテキストノードの href という名前のアトリビュートを選択する。コンテキストノードに href という名前のアトリビュートがない場合には、空のノード集合を選択する。

ノードテストで使用する QName は、式のコンテキストにおけるネームスペース宣言を使用して、展開された名前に展開される。 これはスタートタグやエンドタグ内のエレメント型の名前を展開するのと同じ方法である。ただし、xmlns で宣言されたデフォルトネームスペースは使用しない。つまり、QName にプレフィックスがない場合、ネームスペース URI は null になる (アトリビュート名の展開と同じ方法)。QName にプレフィックスがあり、式のコンテキスト内にそのプレフィックスのネームスペース宣言がない場合はエラーとなる。

ノードテスト * は、主ノード型のノードであればどのノードでも真となる。たとえば child::* はコンテキストノードのすべての子エレメントを選択し、attribute::* はコンテキストノードのすべてのアトリビュートを選択する。

ノードテストは NCName:* の形式を取ることができる。この場合プレフィックスは、コンテキストのネームスペース宣言を使用して QName と同じ方法で展開される。このプレフィックスのネームスペース宣言が式のコンテキスト内にない場合はエラーとなる。このノードテストは、主ノード型のノードの中で、そのプレフィックスを展開したネームスペース URI を展開された名前に持つノードがあれば、そのローカルパートにかかわらず真になる。

ノードテスト text() は、どのテキストノードでも真になる。 たとえば child::text() はコンテキストノードの子テキストノードを選択する。同様に、ノードテスト comment() もすべてのコメントノードで真になり、ノードテスト processing-instruction() もあらゆるプロセッシングインストラクションで真になる。この processing-instruction() テストは Literal という引数を取る場合がある。この場合は、Literal の値と同じ名前を持つあらゆるプロセッシングインストラクションで真になる。

ノードテスト node() は、どのような型のノードでも真になる。

[7]   NodeTest   ::=   NameTest
| NodeType '(' ')'
| 'processing-instruction' '(' Literal ')'

2.4 述語

基準点はフォワード基準点またはリバース基準点のいずれかである。 フォワード基準点はコンテキストノード、もしくはドキュメント順でコンテキストノードの後にあるノードだけを選択する。リバース基準点はコンテキストノード、もしくはドキュメント順でコンテキストノードの前にあるノードだけを対象と選択する。従って ancestor や ancestor-or-self、preceding、preceding-sibling などの基準点はリバース基準点であり、それ以外はすべてフォワード基準点となる。self 基準点は常に、多くても1つのノードしか含まないため、フォワード基準点でもリバース基準点でも同じである。 基準点に関するノード集合のメンバの近接位置 (proximity position) は、フォワード基準点の場合にはドキュメント順の、そしてリバース基準点の場合はドキュメント順とは逆の順序のノード集合内でのそのノードの位置と定義される。 最初の位置は1である。

述語は基準点をもとにしてノード集合にフィルタをかけて、新しいノード集合を作り出す。 フィルタリングの対象となるノード集合内の各ノードをコンテキストノードとして PredicateExpr を評価する。評価する際にはノード集合内のノード数をコンテキストサイズとして、さらにその基準点におけるノード集合内のノードの近接位置をコンテキスト位置として使用する。PredicateExpr をノードで評価した結果が真となる場合のみ、そのノードは新しいノード集合に入り、偽の場合は入らない。

PredicateExprExpr を評価した結果をブール値に変換して評価する。 結果が数値の場合、それがコンテキスト位置と同じであれば真、それ以外は偽に変換される。結果が数値以外の場合は、その結果はboolean 関数を呼び出す場合と同じように変換される。 従って para[3] というロケーションパスは para[position()=3] と同じである。

述語
[8]   Predicate   ::=   '[' PredicateExpr ']'
[9]   PredicateExpr   ::=   Expr

2.5 省略シンタックス

以下の例は、省略シンタックスを使用したロケーションパスである。

省略シンタックスで最も重要なのは、ロケーションステップから child:: を省略できることである。 事実上、child はデフォルトの基準点である。 たとえばロケーションパス div/parachild::div/child::para の省略形である。

また、attribute 基準点にも省略形がある。 attribute::@ に省略することができる。 たとえばロケーションパス para[@type="warning"]child::para[attribute::type="warning"] の省略形であり、type という名前のアトリビュートに warning という値を持つ para という名前の子エレメントを選択する。

///descendant-or-self::node()/ の省略形である。 たとえば //para/descendant-or-self::node()/child::para の省略形であり、ドキュメント内のあらゆる para という名前のエレメントを選択する。 (//para は、ドキュメントエレメントである para という名前のエレメントも選択する。ドキュメントエレメントノードはルートノードの子だからである) div//parachild::div/descendant-or-self::node()/child::para の省略形であり、 div という名前の子エレメントの para という名前の子孫エレメントをすべて選択する。

注: ロケーションパス //para[1] はロケーションパス /descendant::para[1]同じではない。 後者は、最初の para という名前の子孫エレメントを選択する。前者は、そのエレメントの親からみると最初の para という名前の子エレメントになる para という名前の子孫エレメントをすべて選択する。

ロケーションステップ .self::node() の省略形である。 この省略形は // と併用すると有効である。 たとえばロケーションパス .//para は、

self::node()/descendant-or-self::node()/child::para

の省略形であり、コンテキストノードの para という名前の子孫エレメントをすべて選択する。

同様に、ロケーションステップ ..parent::node() の省略形である。 たとえば ../titleparent::node()/child::title の省略形であり、コンテキストノードの親からみた title という子エレメントを選択する。

省略
[10]   AbbreviatedAbsoluteLocationPath   ::=   '//' RelativeLocationPath
[11]   AbbreviatedRelativeLocationPath   ::=   RelativeLocationPath '//' Step
[12]   AbbreviatedStep   ::=   '.'
| '..'
[13]   AbbreviatedAxisSpecifier   ::=   '@'?

3 式

3.1 基本

VariableReference は、コンテキストにおける変数のバインディングの集合の中で、その変数名がバインドされている値として評価される。 式のコンテキストにおける変数のバインディングの集合で、その変数名がどの値にもバインドされていない場合はエラーとなる。

グループ化には括弧を使用する。

[14]   Expr   ::=   OrExpr
[15]   PrimaryExpr   ::=   VariableReference
| '(' Expr ')'
| Literal
| Number
| FunctionCall

3.2 関数呼び出し

FunctionCall 式は、FunctionName を使用してその式が評価されるコンテキストの関数ライブラリ内の関数を特定し、各引数を評価してそれを関数が必要とする型に変換し、最終的に関数を呼び出し、変換した引数をその関数に渡して評価する。引数の数が違っている場合や、必要な型に引数を変換できない場合はエラーとなる。その関数が返した結果が、FunctionCall 式の結果になる。

ある引数は string 関数を呼び出したときのように文字列型に変換される。 また別の引数は number 関数を呼び出したときのように数値型に変換される。 boolean 関数を呼び出したときのようにブール型に変換される引数もある。 ノード集合型でない引数はノード集合には変換できない。

[16]   FunctionCall   ::=   FunctionName '(' ( Argument ( ',' Argument )* )? ')'
[17]   Argument   ::=   Expr

3.3 ノード集合

ロケーションパスは式として使用することができる。 この式は、パスが選択するノードの集合を返す。

| 演算子はオペランドを結合するときに使用するもので、この場合のオペランドはノード集合でなければならない (must)。

式にフィルタをかけるにはロケーションパスと同じ方法で述語を使用する。 フィルタをかける式を評価した結果がノード集合でない場合はエラーとなる。 述語は、child 基準点をもとにしてノード集合にフィルタをかける。

注: 述語 の意味は、適用する基準点によって大きく変わる。 たとえば preceding::foo[1] は、[1] という述語を適用する基準点が preceding 基準点であるため、逆のドキュメント順で最初の foo エレメントを返す。 対照的に、 (preceding::foo)[1] は、 [1] という述語を適用する基準点が child 基準点であるため、ドキュメント順で最初の foo エレメントを返す。

/ 演算子と // 演算子は、式と相対ロケーションパスを組み合わせる。 式がノード集合に評価されない場合はエラーとなる。 / 演算子は、/ をロケーションパスで使用するときと同じように組み合わせを行う。 ロケーションパスの場合と同様に、///descendant-or-self::node()/ の省略形である。

ノード集合に変換できる型のオブジェクトはない。

[18]   UnionExpr   ::=   PathExpr
| UnionExpr '|' PathExpr
[19]   PathExpr   ::=   LocationPath
| FilterExpr
| FilterExpr '/' RelativeLocationPath
| FilterExpr '//' RelativeLocationPath
[20]   FilterExpr   ::=   PrimaryExpr
| FilterExpr Predicate

3.4 ブール

ブール値型のオブジェクトは、真と偽との2つの値のどちらかを取ることができる。

or 式は、まずは各オペランドを評価し、その値を boolean 関数を呼び出したときのようにブール値に変換して評価する。 どちらかの値が真である場合は結果は真となり、それ以外は偽になる。 左側のオペランドを真と評価した場合は、右側のオペランドは評価しない。

and 式でも、まずは各オペランドを評価し、その値を boolean 関数を呼び出したときのようにブール値に変換して評価する。 両方の値が真である場合に結果が真となり、それ以外は偽になる。 左側のオペランドを偽と評価した場合は、右側のオペランドは評価しない。

EqualityExpr (単なる RelationalExpr ではない) または RelationalExpr (単なる AdditiveExpr ではない) は、2つのオペランドを評価した結果のオブジェクトを比較して評価する。 結果のオブジェクトの比較は、以下の3つのグループに分けて、定義される。 第一に、ノード集合を含まない比較に対して,ノード集合を含む比較が、定義される。これは =!=<=<>= および >に対して統一的に定義される。 2番目に、ノード集合が関係しない =!= の比較が定義される。 3番目に、ノード集合が関係しない <=<>= および > の比較が定義される。

比較するオブジェクトが両方ともノード集合の場合は、1番目のノード集合内のノードと2番目のノード集合内のノードの文字列値を比較して、結果が真になるようなノードが両方のノード集合内にある場合のみ、比較結果は真になる。 比較するオブジェクトの1つがノード集合でもう1つが数値の場合は、number 関数を使用してノードの文字列値を数値に変換したものと比較対象の数値を比較して、結果が真になるようなノードがノード集合内にある場合のみ、比較結果は真になる。 比較するオブジェクトの1つがノード集合でもう1つが文字列の場合は、ノードの文字列値と比較対象の文字列を比較して、結果が真になるようなノードがノード集合内にある場合のみ、比較結果は真になる。 比較するオブジェクトの1つがノード集合でもう1つがブール値の場合には、boolean 関数を使用してノード集合をブール値に変換したものと比較対象のブール値を比較し、その結果が真になる場合のみ、比較結果は真になる。

比較するオブジェクトがどちらもノード集合ではなく、さらに演算子が = または != の場合には、以下のようにしてオブジェクトを共通の型に変換してから比較する。 比較するオブジェクトの少なくとも1つがブール値である場合は、各オブジェクトを boolean 関数を使用したときのようにブール値に変換する。 それ以外で、比較するオブジェクトの少なくとも1つが数値の場合は、各オブジェクトを number 関数を使用したときのように数値に変換する。 上記以外の場合では、比較するそれぞれのオブジェクトを string 関数を使用したときのように文字列に変換する。 = 比較は、オブジェクトが等しい場合のみ真になる。!= 比較は、オブジェクトが等しくない場合のみ真になる。 数値は、IEEE 754 [IEEE 754] に従って等しいかどうかを比較する。 2つのブール値は、共に真または共に偽の場合に等しくなる。 2つの文字列は、それらが同じ並びの UCS 文字列の場合のみ等しくなる。

注: $x がノード集合にバインドされている場合は、 $x="foo"not($x!="foo") と同じにはならない。 前者は $x 内の いずれかのノードが foo という文字列値を持つ場合のみ真になり、後者は $x 内のすべて のノードが foo という文字列値を持つ場合のみ真になる。

比較するオブジェクトがどちらもノード集合ではなく、演算子が <= または <>=> の場合には、両方のオブジェクトを数値に変換し、その数値を IEEE 754 に従って比較することでオブジェクトの比較を行う。 < による比較は、1番目の数値が2番目の数値より小さい場合のみ真になる。 <= による比較は、1番目の数値が2番目の数値以下の場合のみ真になる。 > による比較は、1番目の数値が2番目の数値より大きい場合のみ真になる。 >= による比較は、1番目の数値が2番目の数値以上の場合のみ真になる。

注: XPath 式を XML ドキュメント内で使用する場合には、 < 演算子や <= 演算子はすべて XML 1.0 のルールに従い、たとえば &lt;&lt;= を使用してクオートしなければならない (must)。 次の例では、test という名前のアトリビュートの値が XPath 式になっている。
<xsl:if test="@value &lt; 10">...</xsl:if>
[21]   OrExpr   ::=   AndExpr
| OrExpr 'or' AndExpr
[22]   AndExpr   ::=   EqualityExpr
| AndExpr 'and' EqualityExpr
[23]   EqualityExpr   ::=   RelationalExpr
| EqualityExpr '=' RelationalExpr
| EqualityExpr '!=' RelationalExpr
[24]   RelationalExpr   ::=   AdditiveExpr
| RelationalExpr '<' AdditiveExpr
| RelationalExpr '>' AdditiveExpr
| RelationalExpr '<=' AdditiveExpr
| RelationalExpr '>=' AdditiveExpr
注: 上記の文法では、その効果の優先順位は以下のようになる (優先順位の低いほうからの順)。 演算子はすべて左から結合される。 たとえば 3 > 2 > 1(3 > 2) > 1 と等しく、偽である。

3.5 数

数は浮動小数点数を表す。 数は、倍精度 64 ビット形式の IEEE 754 の値 [IEEE 754] を取ることができる。 これには、特別な "Not-a-Number" (NaN) 値、正の無限大と負の無限大、そして正のゼロや負のゼロも含まれる。 IEEE 754 標準における主なルールの概要については、[JLS]Section 4.2.3 を参照。

数値演算子は number 関数を呼び出したときのように、オペランドを数に変換する。

+ 演算子は加算を実行する。

- 演算子は減算を実行する。

注: XML では名前に - を使用できるため、- 演算子の前には通常、空白を入れる必要がある。 たとえば foo-bar は、 foo-bar という名前の子エレメントを含むノード集合になる。foo - bar は、最初の foo 子エレメントの文字列値を数値に変換した結果と、最初の bar 子エレメントの文字列値を数値に変換した結果との差になる。

div 演算子は IEEE 754 に基づいた浮動小数点の割り算を実行する。

mod 演算子は、割り算の結果を切り捨てて余りを返す。 以下は mod 演算子の例である。

注: これは Java や ECMAScript の % 演算子と同じである。
注: 割り算の結果を丸めて余りを返す IEEE 754 の仕様とは異なる。
数値式
[25]   AdditiveExpr   ::=   MultiplicativeExpr
| AdditiveExpr '+' MultiplicativeExpr
| AdditiveExpr '-' MultiplicativeExpr
[26]   MultiplicativeExpr   ::=   UnaryExpr
| MultiplicativeExpr MultiplyOperator UnaryExpr
| MultiplicativeExpr 'div' UnaryExpr
| MultiplicativeExpr 'mod' UnaryExpr
[27]   UnaryExpr   ::=   UnionExpr
| '-' UnaryExpr

3.6 文字列

文字列はゼロ個以上の文字の並びである。ここでいう文字の定義は XML 勧告 [XML] と同じである。 従って XPath 内の1つの文字は、1つの Unicode 抽象文字 (対応する Unicode スカラー値を1つ持つ) に相当する ([Unicode] 参照)。これは 16 ビット Unicode のコード値と同じではない。 なぜなら、U+FFFF より大きい Unicode スカラー値を持つ抽象文字の Unicode コード文字表現は、16 ビット Unicode コード値をペアにしたものだからである (サロゲートペア)。 多くのプログラミング言語では、文字列は 16 ビットの Unicode コード値を並べて表現する。従ってそのような言語で XPath を実装する際には、このサロゲートペアが XPath 文字の1文字として正しく扱われるように注意しなければならない (must)。

注: Unicode では、異なる Unicode 抽象文字列であるにもかかわらず、同一のものとして扱わなければいけない2つの文字列が存在することができる。 たとえばアクセント付き文字は、あらかじめ合成した形と分離した形のどちらの形式で表現可能なものがある。 従って XPath 式と XML ドキュメントの両方の文字が基準形 (canonical form) に正規化されていないと、XPath 式は予期しない結果を返すことがある。[Character Model] 参照。

3.7 字句構造

トークン化では、常に可能な限り長いトークンを返す。

文法で明示的に許されていなくても、読みやすくするために式の中で空白を使用することができ、 パターン内で ExprWhitespaceExprToken の前後に自由に追加することができる。

ExprToken 文法の曖昧さをなくすため、次のような特別なトークン化ルールを、ここに記載した順序で適用する必要がある (must)。

式の字句構造
[28]   ExprToken   ::=   '(' | ')' | '[' | ']' | '.' | '..' | '@' | ',' | '::'
| NameTest
| NodeType
| Operator
| FunctionName
| AxisName
| Literal
| Number
| VariableReference
[29]   Literal   ::=   '"' [^"]* '"'
| "'" [^']* "'"
[30]   Number   ::=   Digits ('.' Digits?)?
| '.' Digits
[31]   Digits   ::=   [0-9]+
[32]   Operator   ::=   OperatorName
| MultiplyOperator
| '/' | '//' | '|' | '+' | '-' | '=' | '!=' | '<' | '<=' | '>' | '>='
[33]   OperatorName   ::=   'and' | 'or' | 'mod' | 'div'
[34]   MultiplyOperator   ::=   '*'
[35]   FunctionName   ::=    QName - NodeType
[36]   VariableReference   ::=   '$' QName
[37]   NameTest   ::=   '*'
| NCName ':' '*'
| QName
[38]   NodeType   ::=   'comment'
| 'text'
| 'processing-instruction'
| 'node'
[39]   ExprWhitespace   ::=   S

4 コア関数ライブラリ

この項では、XPath を実装する際に、式を評価するための関数ライブラリに必ず含む必要のある (must)関数について説明する。

関数ライブラリ内のそれぞれの関数は関数プロトタイプを使用して定義する。このプロトタイプには関数が返す値の型や関数の名前、引数の型などが含まれる。 引数の型に疑問符が付いている場合は、その引数はオプションである。疑問符がない場合は必須となる。

4.1 ノード集合関数

関数: number last()

last 関数は、式を評価しているコンテキストのコンテキストサイズに等しい数値を返す。

関数: number position()

position 関数は、式を評価しているコンテキストのコンテキスト位置に等しい数値を返す。

関数: number count(node-set)

count 関数は引数に指定したノード集合に含まれるノード数を返す。

関数: node-set id(object)

id 関数はユニーク ID によりエレメントを選択する。 ([5.2.1 ユニーク ID] 参照) id 関数の引数の型がノード集合の場合、引数に指定したノード集合内の各ノードが持つ文字列値id を適用した結果の和集合が結果になる。 id 関数の引数がその他の型の場合は、string 関数を呼び出したときのように、引数を文字列に変換する。この文字列を空白で区切られたトークンのリストに分割する。 (空白は、Sプロダクションに一致する任意の文字列である) 結果は、コンテキストノードと同じドキュメント内で、このリスト内のトークンのいずれかに等しいユニーク ID のエレメントを持つノード集合になる。

関数: string local-name(node-set?)

local-name 関数は引数に指定したノード集合内のノードのうち、ドキュメント順展開された名前の最初のノードのローカルパートを返す。 引数に指定したノード集合が空であるか、あるいは最初のノードが展開された名前を持たない場合は空の文字列を返す。 引数を省略した場合は、コンテキストノードを唯一のメンバに持つノード集合をデフォルトとして使用する。

関数: string namespace-uri(node-set?)

namespace-uri 関数は引数に指定したノード集合内のノードのうち、ドキュメント順で最初のノードの展開された名前のネームスペース URI を返す。 引数に指定したノード集合が空の場合、あるいは最初のノードが展開された名前を持たない場合、または展開された名前のネームスペース URI が null の場合は空の文字列を返す。 引数を省略した場合は、コンテキストノードを唯一のメンバに持つノード集合をデフォルトとして使用する。

注: namespace-uri 関数が返す文字列は、エレメントノードとアトリビュートノード以外は空になる。

関数: string name(node-set?)

name 関数は引数に指定したノード集合内のノードのうち、ドキュメント順で最初のノードの展開された名前を表現する QName を持つ文字列を返す。 この QName は、名前を展開しようとしているノードに対して有効なネームスペース宣言をもとに、展開されなければならない (must)。 これは通常、XML ソースで使用する QName になる。 またこれは、同一のネームスペースに対して複数のプレフィックスを関連付けるネームスペース宣言が、そのノードに対して有効な場合にはあてはまらない。 ただし実装する際には、ノードの表現にオリジナルのプレフィックスに関する情報を含めることができる。このようなかたちで実装すると、name 関数が返す文字列は必ず、XML ソースで使用する QName と同じものになる。 引数に指定したノード集合が空であるか、あるいは最初のノードが展開された名前を持たない場合は空の文字列を返す。 引数を省略した場合は、コンテキストノードを唯一のメンバに持つノード集合をデフォルトとして使用する。

注: エレメントノードとアトリビュートノードを除き、name 関数が返す文字列は local-name 関数が返す文字列と同じである。

4.2 文字列関数

関数: string string(object?)

string 関数は、以下のようにオブジェクトを文字列に変換する。

引数を省略した場合は、コンテキストノードを唯一のメンバに持つノード集合をデフォルトとして使用する。

注: string 関数は、ユーザに表示することを目的として数値を文字列に変換するものではない。 この目的では、[XSLT]format-number 関数と xsl:number エレメントを使用する。

関数: string concat(string, string, string*)

concat 関数は引数を連結して返す。

関数: boolean starts-with(string, string)

starts-with 関数は、1番目の引数に指定した文字列が2番目の引数に指定した文字列で始まっている場合に真を返し、それ以外は偽を返す。

関数: boolean contains(string, string)

contains 関数は、1番目の引数に指定した文字列が2番目の引数に指定した文字列を含んでいる場合に真を返し、それ以外は偽を返す。

関数: string substring-before(string, string)

substring-before 関数は、2番目の引数に指定した文字列が1番目の引数に指定した文字列内で最初に見つかった場合に、その文字列よりも前にある文字列 (サブストリング) を返す。2番目の引数に指定した文字列が1番目の引数に指定した文字列内に含まれていない場合は、空の文字列を返す。 たとえば substring-before("1999/04/01","/")1999 を返す。

関数: string substring-after(string, string)

substring-after 関数は、2番目の引数に指定した文字列が1番目の引数に指定した文字列内で最初に見つかった場合に、その文字列よりも後にある文字列 (サブストリング) を返す。2番目の引数に指定した文字列が1番目の引数に指定した文字列内に含まれていない場合は、空の文字列を返す。 たとえば substring-after("1999/04/01","/")04/01 を返し、 substring-after("1999/04/01","19")99/04/01 を返す。

関数: string substring(string, number, number?)

substring 関数は、1番目の引数に指定した文字列のうち、2番目の引数に指定した位置から始まる文字列 (サブストリング) を、3番目の引数で指定した長さだけ返す。 たとえば substring("12345",2,3)"234" を返す。 3番目の引数を指定しないと、2番目の引数に指定した位置から最後までの文字列 (サブストリング) を返す。 たとえば substring("12345",2)"2345" を返す。

より厳密に言うと、文字列内の各文字は ([3.6 文字列] 参照) 数値としての位置を持っていると見なす。 つまり最初の文字の位置は1で、2番目の文字の位置は2であり、以下同様に続く。

注: これは String.substring メソッドで最初の文字の位置を0として扱う Java や ECMAScript とは異なる。

返す文字列 (サブストリング) の文字数については次のようになる。まずその開始位置は、2番目の引数を丸めた値以上となる。また3番目の引数を指定した場合は、2番目の引数を丸めた値と3番目の引数を丸めた値の合計よりも小さい文字数になる。ここで使用する比較や加算は、標準の IEEE 754 のルールに従う。丸めについては、 round 関数を呼び出した場合と同様とする。 以下は、さまざまな特殊な例である。

関数: number string-length(string?)

string-length 関数は文字列内の文字数を返す ([3.6 文字列] 参照)。 引数を省略した場合は、文字列に変換したコンテキストノード、言いかえればコンテキストノードの文字列値をデフォルトとして使用する。

関数: string normalize-space(string?)

normalize-space 関数は、引数に指定した文字列の空白文字を正規化して返す。つまり前後の空白文字を取り除き、連続する空白文字を1つの空白文字に置き換える。 空白文字は、XMLの S プロダクションで使用できるものと同じである。 引数を省略した場合は、文字列に変換したコンテキストノード、言いかえればコンテキストノードの文字列値をデフォルトとして使用する。

関数: string translate(string, string, string)

translate 関数は、1番目の引数に指定した文字列内に2番目の引数に指定した文字列内の文字があった場合、その文字を3番目の引数に指定した文字列内の対応する位置の文字で置き換えて返す。 たとえば translate("bar","abc","ABC")BAr を返す。 2番目の引数に指定した文字列が3番目の引数に指定した文字列よりも長いために、2番目の引数に指定した文字列内の文字に対応する文字が3番目の引数に指定した文字列内に存在しない場合は、1番目の引数に指定した文字列内の対応する文字を削除する。 たとえば translate("--aaa--","abc-","ABC")"AAA" を返す。 2番目の文字列内に同じ文字が複数ある場合には、最初の文字を使用して置き換えが行われる。 3番目の引数に指定した文字列が2番目の引数に指定した文字列よりも長い場合には、2番目の引数に指定した文字列よりも長い部分の文字は無効となる。

注: この translate 関数は、すべての言語で大文字と小文字の変換に使えるような十分なソリューションとはいえない。 XPath の今後のバージョンでは、大文字と小文字の変換に使用できる関数を追加することも考えられる。

4.3 ブール関数

関数: boolean boolean(object)

boolean 関数は、以下のように引数をブール値に変換する。

関数: boolean not(boolean)

not 関数は、引数が偽の場合に真を、それ以外は偽を返す。

関数: boolean true()

true 関数は真を返す。

関数: boolean false()

false 関数は偽を返す。

関数: boolean lang(string)

lang 関数は、コンテキストノードの xml:lang という名前のアトリビュートで指定したコンテキストノードの言語が引数に指定したものと同じ言語であるか、または引数に指定した言語のサブ言語であるかにより、真または偽を返す。 コンテキストノードの言語は、コンテキストノードの xml:lang という名前のアトリビュートの値で決まる。あるいは、コンテキストノードが xml:lang という名前のアトリビュートを持たない場合は、コンテキストノードに最も近い祖先エレメントが持つ xml:lang という名前のアトリビュートの値で決まる。 そのようなアトリビュートがない場合は、lang 関数は偽を返す。 そのようなアトリビュートがある場合、lang 関数は大文字と小文字を区別せずに比較して、アトリビュート値と引数が等しい場合は真を返す。またアトリビュート値が - で始まるサフィックスを持つ場合は、そのサフィックスは考慮せず、そして大文字と小文字を区別することなく比較して、アトリビュート値が引数に等しい場合にも真を返す。 たとえばコンテキストノードが以下の5つのエレメントのいずれかの場合に、lang("en") は真を返す。

<para xml:lang="en"/>
<div xml:lang="en"><para/></div>
<para xml:lang="EN"/>
<para xml:lang="en-us"/>

4.4 数値関数

関数: number number(object?)

number 関数は、以下のように引数を数値に変換する。

引数を省略した場合は、コンテキストノードを唯一のメンバに持つノード集合をデフォルトとして使用する。

注: number 関数は、そのエレメントが言語的にニュートラルな形式で数値データを表現する型 (通常はユーザに表示するために言語特有の形式に変換する) でなければ、XML ドキュメント内のエレメント内にある数値データの変換に使ってはならない。 さらに、エレメントで使用する言語的にニュートラルな形式が Number の XPath シンタックスと一貫性を持つものでない 限りは、number 関数を使用することはできない。

関数: number sum(node-set)

sum 関数は、引数に指定したノード集合内の各ノードの文字列値を数値に変換し、それを合計した値を返す。

関数: number floor(number)

floor 関数は、引数に指定した数値よりも大きくない範囲で、最も大きい (最も正の無限大に近い) 整数を返す。

関数: number ceiling(number)

ceiling 関数は、引数に指定した数値よりも小さくない範囲で、最も小さい (最も負の無限大に近い) 整数を返す。

関数: number round(number)

round 関数は、引数に指定した値に最も近い整数を返す。 そのような数値が二つ存在する場合は、正の無限大に近い方の数値を返す。 引数が NaN の場合には NaN を返す。 引数が正の無限大の場合には正の無限大を返す。 引数が負の無限大の場合には負の無限大を返す。 引数が正のゼロの場合には正のゼロを返す。 引数が負のゼロの場合には負のゼロを返す。 引数がゼロより小さいが、-0.5 以上の場合には負のゼロを返す。

注: この最後の二つのケースでは、 round 関数を呼び出した結果は、 0.5 を加えてから floor 関数を呼び出した結果と同じにはならない。

5 データモデル

XPath は XML ドキュメントをツリーとして扱う。 この項では、XPath が XML ドキュメントをどのようにツリーとしてモデル化するのかを説明する。 このモデルは概念的なものでしかなく、特に何かを実装しなければいけないというわけではない。 このモデルと XML Information Set [XML Infoset] との関係については、[B XML 情報セットのマッピング] で説明する。

XPath が扱う XML ドキュメントは、XML Namespaces Recommendation [XML Names] に準拠していなければならない (must)。

ツリーはノードを持ち、ノードには以下の7つの種類がある。

ノード型にはすべて、その型のノードの文字列値を決定する方法がある。 文字列値がそのノードの一部となるノード型もあれば、文字列値を子孫ノードの文字列値から計算するノード型もある。

注: エレメントノードやルートノードの場合、ノードの文字列値は、DOM の nodeValue メソッド ([DOM] 参照) が返す文字列と同じではない。

また、ノード型には展開された名前を持つものもある。展開された名前はローカルパートとネームスペース URI からなる。 ローカルパートは文字列である。 ネームスペース URI は null または文字列のどちらかである。 XML のドキュメントで指定するネームスペース URI には、[RFC2396] で定義する URI リファレンスが使える。つまりフラグメント識別子を持ち、相対形式で使用できる。 ネームスペースを処理するときには、相対 URI を絶対 URI に解決する必要がある。 つまり、データモデル内のノードが持つ展開された名前のネームスペース URI は絶対形式でなければいけない。 同じローカルパートを持ち、なおかつ両方が null のネームスペース URI を持つ場合に2つの展開された名前は等しくなる。あるいは同じローカルパートを持ち、なおかつ両方が null でない同じネームスペース URI を持つ場合にも2つの展開された名前は等しくなる。

ドキュメント内のすべてのノードで定義するドキュメント順という順序付けがある。これは一般エンティティの展開後に、ドキュメントの XML 表現において各ノードの XML 表現の最初の文字が現れる順序を表したものである。 従ってルートノードが最初のノードになる。 エレメントノードは、それ自身の子よりも先になる。 このようにドキュメント順は、(エンティティを展開した後で) XML 内でエレメントノードのスタートタグを記述する順序に従ってエレメントノードを順序付けしたものである。 エレメントのアトリビュートノードとネームスペースノードは、そのエレメントの子ノードよりも先になる。 ネームスペースノードはアトリビュートノードよりも先になるように定義する。 ネームスペースノードの相対的な順序は、実装により異なる。 アトリビュートノードの相対的な順序も実装によって異なる。 逆ドキュメント順ドキュメント順を逆にしたものである。

ルートノードとエレメントノードは、子ノードを順序付けたリストを持つ。 ノードが子ノードを共有することはない。 従って異なる2つのノードがある場合、片方のノードの子ノードはすべて、もう1つのノードの子ノードとは異なる。 ルートノードを除くすべてのノードは、必ず親ノードを1つ持つ。親ノードになるのはルートノードかエレメントノードのどちらかである。 ルートノードまたはエレメントノードは、それぞれが持つ個々の子ノードからみると親ノードになる。 ノードの子孫ノードとは、そのノードの子ノード、および子ノードの子孫ノードになる。

5.1 ルートノード

ルートノードはツリーのルートである。 ルートノードはツリーのルート以外にはならない。 ドキュメントエレメントのエレメントノードは、ルートノードの子ノードになる。 またルートノードは、プロローグ部分およびドキュメントエレメントの終了後の部分のプロセッシングインストラクションとコメントに対して、子ノードのプロセッシングインストラクションノードや子のコメントノードを持つ。

ルートノードの文字列値 は、ルートノードのすべての子孫テキストノード文字列値をドキュメント順に連結したものである。

ルートノードは展開された名前を持たない。

5.2 エレメントノード

ドキュメント内のエレメントはすべて、エレメントノードを持つ。 エレメントノードは展開された名前を持つ。その名前は XML Namespaces Recommendation [XML Names] に従って、タグ内に指定したエレメントの QName を展開して得られる。 エレメントの展開された名前が持つネームスペース URI は、QName にプレフィックスがなく、なおかつ適用できるデフォルトのネームスペースもない場合には null になる。

注: [XML Names] の付録 A.3 のノテーションでは、展開された名前のローカルパートは ExpEType という名前のエレメントの type という名前のアトリビュートに該当する。展開された名前のネームスペース URI は ExpEType という名前のエレメントの ns という名前のアトリビュートに該当し、 ExpEType という名前のエレメントの ns という名前のアトリビュートを省略した場合には null になる。

エレメントノードの子ノードは、その内容のエレメントノードやコメントノード、プロセッシングインストラクションノード、テキストノードである。 内部エンティティや外部エンティティへのエンティティリファレンスは展開される。 また、キャラクターリファレンスは解決される。

エレメントノードの文字列値は、エレメントノードのすべての 子孫テキストノード文字列値をドキュメント順に連結したものである。

5.2.1 ユニーク ID

エレメントノードはユニークな識別子 (ID) を持つ場合がある。 これは DTD 内で ID 型として宣言したアトリビュートの値である。 同じドキュメント内で2つのエレメントが同一のユニーク ID を持つことはできない。 XML プロセッサが、1つのドキュメント内に同一のユニーク ID を持つエレメントが2つある (これはドキュメントが無効である場合にのみ起こりうる) ことを報告した場合には、ドキュメント順で2番目のエレメントはユニーク ID を持たないものとして扱われなければならない (must)。

注: ドキュメントが DTD を持っていない場合には、そのドキュメント内にユニーク ID を持つエレメントはない。

5.3 アトリビュートノード

エレメントノードはそれぞれ、関連するアトリビュートノードの集合を持つ。それぞれのエレメントは、各アトリビュートノードの親ノードになる。ただしアトリビュートノードは、その親エレメントの子ノードにはならない。

注: これは DOM とは異なる。DOM では、アトリビュートを持つエレメントをそのアトリビュートの親ノードとしては扱わない([DOM] 参照)。

エレメントがアトリビュートを共有することはない。 従って異なる2つのエレメントノードがある場合、片方のエレメントノードのアトリビュートノードはすべて、もう1つのエレメントノードのアトリビュートノードとは異なる。

注: = 演算子は2つのノードが同じ値を持つかどうかをテストするためのものであり、それらが同じノードかどうかをテストするものではない。 従って同じノードでなくても、= 演算子を使用して2つの異なるエレメントが同じかどうかを比較することができる。

デフォルト値を使用して宣言されたアトリビュートは、アトリビュートを指定した場合と同様に扱われる。 DTD 内でエレメント型にアトリビュートを宣言しても、デフォルトを #IMPLIED と宣言し、なおかつそのエレメントにアトリビュートを指定しなければ、そのエレメントのアトリビュート集合にアトリビュートのノードは含まれない。

xml:langxml:space などのいくつかのアトリビュートは、別の子孫エレメントにある同じ名前のアトリビュートによってオーバーライドされる場合を除き、そのアトリビュートを持つエレメントのすべての子孫エレメントに適用される。 ただしこれは、ツリー内でのアトリビュートノードの位置に影響を与えるものではない。 なぜなら、エレメントはそのエレメントのスタートタグまたは空エレメントタグで明示的に指定したアトリビュートについてのみアトリビュートノードを持ち、また、DTD においてデフォルト値を使用して明示的に宣言したアトリビュートについてのみアトリビュートノードを持つためである。

アトリビュートノードは展開された名前文字列値を持つ。 展開された名前は XML Namespaces Recommendation [XML Names] に従って、XML ドキュメントのタグ内に指定した QName を展開して得る。 アトリビュートの QName にプレフィックスがない場合、そのアトリビュートの名前のネームスペース URI は null になる。

注: [XML Names] の付録 A.3 のノテーションでは、展開された名前のローカルパートは ExpAName という名前のエレメントの name という名前のアトリビュートに該当する。展開された名前のネームスペース URI は ExpAName という名前のエレメントの ns という名前のアトリビュートに該当し、 ExpAName という名前のエレメントの ns という名前のアトリビュートを省略した場合は null になる。

アトリビュートノードは文字列値を持つ。 この文字列値は、XML Recommendation [XML] で規定された方法で正規化した値である。 正規化した結果が長さゼロの文字列になるアトリビュートを特別に扱うことはない。 それは、結果として文字列値に長さゼロの文字列を持つアトリビュートノードになっただけである。

注: デフォルトのアトリビュートを外部 DTD や外部のパラメータエンティティで宣言することができる。 XML Recommendation では、妥当性の検証を行わない XML プロセッサの場合、外部 DTD または外部のパラメータを読むことは要求していない。 妥当性の検証を行わない XML プロセッサでは、外部 DTD または外部のパラメータエンティティで宣言したデフォルトのアトリビュート値を XPath ツリーで持つことを前提とするようなスタイルシート、またはその他の機能は使えない場合がある。

ネームスペースを宣言するアトリビュートに該当するアトリビュートノードはない ([XML Names] 参照)。

5.4 ネームスペースノード

エレメントはそれぞれ、関連するネームスペースノードの集合を持つ。エレメントのスコープ内にある個々のネームスペースプレフィックスに1つずつ (XML Namespaces Recommendation [XML Names] で暗黙的に宣言する xml プレフィックスも含む)、そしてデフォルトネームスペースがエレメントのスコープ内にある場合には、デフォルトネームスペースに対して1つある。 エレメントはこれらの各ネームスペースノードの親ノードになる。ただしネームスペースノードは、その親エレメントの子ノードにはならない。 エレメントがネームスペースノードを共有することはない。 従って異なる2つのエレメントノードがある場合、片方のエレメントノードのネームスペースノードはすべて、もう1つのエレメントノードのネームスペースノードとは異なる。 エレメントはつまり、次のようなものに対してネームスペースノードを持つことになる。

ネームスペースノードは展開された名前を持ち、 ローカルパートはネームスペースプレフィックスになる。 (デフォルトネームスペース用のネームスペースノードの場合は空になる) ネームスペース URI は常に null になる。

ネームスペースノードの文字列値は、ネームスペースプレフィックスにバインドされているネームスペース URI である。そのネームスペース URI が相対形式の場合には、展開された名前のネームスペース URI と同様に解決されなければならない (must)。

5.5 プロセッシングインストラクションノード

ドキュメント型宣言内に記述するものを除き、すべてのプロセッシングインストラクションはプロセッシングインストラクションノードを持つ。

プロセッシングインストラクションは展開された名前を持ち、 ローカルパートはプロセッシングインストラクションのターゲットになる。ネームスペース URI は null になる。 プロセッシングインストラクションノードの文字列値は、プロセッシングインストラクションのうちのターゲットと空白に続く部分になる。 最後の ?> はこの文字列値には含まれない。

注: XML 宣言はプロセッシングインストラクションではない。 従って XML 宣言に該当するプロセッシングインストラクションノードはない。

5.6 コメントノード

ドキュメント型宣言内に記述するコメントを除き、すべてのコメントはコメントノードを持つ。

コメントの文字列値はコメントのコンテンツである。最初の <!-- または終りの --> は含まない。

コメントノードは展開された名前を持たない。

5.7 テキストノード

文字データはテキストノードにグループ化する。 可能な限り多くの文字データを各テキストノードにグループ化する。 つまり、テキストノードは、テキストノードである兄弟をその直前または直後に持つことはない。 テキストノードの文字列値は文字データである。 テキストノードは常に少なくとも1文字のデータを持つ。

CDATA セクション内の各文字は文字データとして扱われる。 従って、ソースドキュメント内の <![CDATA[<]]>&lt; と同様の扱いとなる。 両方とも、ツリー内のテキストノードでは1つの < 文字になる。 つまり CDATA セクションは、<![CDATA[]]> を削除し、すべての <& をそれぞれ &lt;&amp; で置き換えたような扱いとなる。

注: < 文字を持つテキストノードを XML として書き出す場合は、たとえば &lt; を使用するか、あるいは < 文字を CDATA セクションに含めることで < 文字をエスケープしなければならない (must)。

コメントやプロセッシングインストラクション、アトリビュート値の内部にある文字はテキストノードを生成しない。 外部エンティティの行末は、XML Recommendation [XML] に規定されているように #xA に正規化される。

テキストノードは展開された名前を持たない。

6 適合性

XPath は、主に他の仕様において利用できるコンポーネントとして位置づけられたものである。 従って XPath では、XPath を使う仕様 ([XPointer][XSLT] など) に依存するかたちで実装に際しての適合性基準が決まるため、XPath