XMLパス言語 (XPath) Version 1.0


W3C

XMLパス言語 (XPath) Version 1.0

W3C勧告案 1999年10月8日

このバージョン[原文]:
http://www.w3.org/TR/1999/PR-xpath-19991008
(XML形式またはHTML形式で利用可能)
最新のバージョン:
http://www.w3.org/TR/xpath
以前のバージョン:
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. and Brown University) <Steven_DeRose@Brown.edu>

概要

XPathは、XML文書の一部分をアドレッシングするための言語であり、XSLTとXPointerとの両方で利用されるよう設計されている。

この文書の位置づけ

これはW3C会員及びその他の利害関係者によるレビューのためのW3C勧告案である。詳細なコメントを www-xpath-comments@w3.org へ1999年11月5日までにお送りいただきたい。コメントのアーカイブが利用可能である。W3C会員は、W3Cスタッフにしか見えないよう、正式コメントを w3c-xslt-review@w3.org へ送ってもかまわない。

この仕様書は、1999年8月13日付けの最終案内ワーキングドラフトに手を入れたものである。XMLリンクワーキンググループおよびXSLワーキンググループは、この仕様書に対するこれ以上の本質的な変更は予定しておらず、勧告案レビュー期間の間はこの仕様書をテストするための活発な実装を奨励する。

勧告案としての公表は、W3C会員組織による保証という意味合いを含むものではない。これはまだドラフト(草稿)文書であって、何時にても他の文書によって更新され、置換され、又は廃止されることがある。W3C勧告案を「進行中の作業」意外のものとして引用することは不適切である。

この仕様書は、XSLワーキンググループとXMLリンクワーキンググループとの合同作業であり、そのためスタイルアクティビティXMLアクティビティとの一部分である。

この仕様書は英語版が唯一の規範的バージョンである。もっとも、この文書の翻訳を探すのであれば、http://www.w3.org/Style/XSL/translations.html を見ること。

目次

1 序論
2 ロケーションパス
    2.1 ロケーションステップ
    2.2
    2.3 ノードテスト
    2.4 述部
    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情報セットの割り付け (非規範的)
C 以前の公開ワーキングドラフトからの変更点 (非規範的)

1 序論

XPathは、XSLT[XSLT]とXPointer[XPointer]との間で共有されている機能について共通の文法と意味論とを用意しようという努力の成果である。XPathの第一次的な目的は、XML[XML]文書の一部分をアドレッシングすることにある。この第一次的な目的を支えるため、XPathは、文字列や数値、ブール値を操作するための基本的な装置も用意する。XPathは、URIやXML属性値の内部でXPathを利用しやすくするため、コンパクトな非XML文法を利用する。XPathは、XML文書の抽象的、論理的構造に作用する。XPathは、URLのように、XML文書の階層的構造を通じた指図のためにパス表記法を利用するところから、その名が付けられている。

アドレッシングのための利用に加えて、XPathは、照合(あるノードがあるパターンに合致するか否かのテスト)のために使うことのできる自然なサブセットをもつようにも設計されている。このXPathの使い方はXSLTで解説される。

XPathは、XML文書をノード樹としてモデル化する。ノードには、要素ノードや属性ノード、テキストノードを含め、いろいろな型のものがある。XPathは、各ノード型の文字列値の計算方法を定義する。ノード型によっては名前もとるものがある。XPathは、XML名前空間[XML Names]を完全にサポートする。そこで、ノードの名前は、ローカル部分と、ヌルであってもかまわないが名前空間URIとからなる対としてモデル化される。これは展開名と呼ばれる。データモデルについては[5 データモデル]で詳細に解説する。

XPathにおける主たる文法構造物は式(expression)である。式とは、生成規則 Expr に合致するものである。式は評価されてオブジェクトを生み出す。このオブジェクトは、以下の4つの基本型のうちのひとつをとる。

式の評価は、文脈との関係で発生する。XSLTやXPointerは、それぞれXSLTやXPointerで使われているXPath式についての文脈をどのように決定するかを規定している。文脈は、つぎのものからなる。

文脈ポジションはつねに文脈サイズ以下である。

変数バインディングは、変数名から変数値への割り付け関係からなる。変数の値はオブジェクトであり、式の値としてとりうる型のうち任意の型をとることができるし、またここに規定されていない追加の型のものをとることもできる。

関数ライブラリは、関数名から関数への割り付け関係からなる。各関数は、0個以上の引数をとり、1個の結果を返す。この文書は、すべてのXPath実装物がサポートしなければならないコア関数ライブラリを定義する([4 コア関数ライブラリ]を見よ)。コア関数ライブラリにある関数については、引数や結果は4つの基本型のものである。XSLTもXPointerもともに、追加の関数を定義してXPathを拡張する。これらの関数の中には、4つの基本型に作用するものもあるし、XSLTやXPointerが定義した追加のデータ型に作用するものもある。

名前空間宣言は、プリフィックスから名前空間URIへの割り付け関係からなる。

部分式を評価するのに使われる変数バインディングや関数ライブラリ、名前空間宣言は、包含側の式を評価するのに使われるものとつねに同じである。部分式を評価するのに使われる文脈ノードや文脈ポジション、文脈サイズは、ときとして、包含側の式を評価するのに使われるものと異なる。何種類かの式は、文脈ノードを変更する。文脈ポジションや文脈サイズは、述部だけが変更する([2.4 述部]を見よ)。ある種類の式の評価について解説するときには、部分式の評価で文脈ノードや文脈ポジション、文脈サイズが変化する場合にはつねに明言することとする。文脈ノードや文脈ポジション、文脈サイズについて何も言わない場合には、その種類の式の部分式の評価では、それらは変更されないままである。

XPath式がXML属性の中に出現することがよくある。このセクションで規定する文法は、XML 1.0 通常化(normalization)後の属性値に適用される。そのため、たとえば、文法で < というキャラクタが使われている場合には、これはXMLソースの中に < という形で出現してはならず、たとえば &lt; として入れることにより、XML 1.0 規則に従ってクオートされなければならない。式の内部では、リテラル文字列は単引用符または二重引用符で区切られるが、これはXML属性を区切るのにも使われる。XMLプロセッサが式の中の引用符を属性値の終端として解釈することを避けるため、引用符はキャラクタ参照(&quot; または &apos;)として入れることができる。これに代えて、XML属性が二重引用符で区切られている場合には式が単引用符を使うことが可能であり、またその逆も可能である。

重要な種類の式のひとつがロケーションパスである。ロケーションパスは、文脈ノードに対する相対関係において、ノードのセットを選択する。ロケーションパスである式を評価した結果は、そのロケーションパスによって選択されるノードを包含するノードセットである。ロケーションパスは、ノードのセットをフィルタリングするために使われる式を再帰的に包含することができる。ロケーションパスとは、生成規則 LocationPath に合致するものである。

以下の文法において、中間生成規則 QName および NCName[XML Names]で定義され、また S[XML]で定義される。文法は、[XML]と同じEBNF表記法を利用する。(ただし、文法記号はつねに頭文字が大文字である。)

式は、まずキャラクタ文字列をトークンへと解析し、その後結果のトークン列を解析することにより、解析される。トークンの間では空白を自由に使うことができる。トークン化処理については[3.7 レキシカルな構造物]で解説する。

2 ロケーションパス

ロケーションパスは、言語の中で最も一般的な文法的構造物というわけではない(LocationPathExpr の特殊ケースである。)が、最も重要な構造物であるから、まず最初に解説することとする。

ロケーションパスはどれも、素直であるが少しばかり面倒なシンタックスを使って表記することができる。よくあるケースを簡潔に表記できるようにする省略文法も数多くある。このセクションは、非省略文法を使ってロケーションパスの意味論を説明することとする。省略文法は、その後で、それがどのように非省略文法へと展開されるかを示すことにより説明することになる([2.5 省略文法]を見よ)。

こちらは、非省略文法を使ったロケーションパスの例である。

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

相対ロケーションパスは、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つの部分がある。

ロケーションステップの文法は、軸名とノードテストとが二重コロンによって分けられたものに、それぞれ角括弧の中に式が入ったものが0個以上続くというものである。たとえば child::para[position()=1] では、child が軸の名前であり、para がノードテストであり、[position()=1] が述部である。

ロケーションステップによって選択されるノードセットは、軸とノードテストとから初期ノードセットを生成し、その後にそのノードセットを述部のそれぞれにより順次フィルタリングした結果として生まれるノードセットである。

初期ノードセットは、文脈ノードとの関連性が軸によって指定され、かつノード型および展開名がノードテストによって指定されているノードからなる。たとえば、descendant::para というロケーションステップは、文脈ノードの子孫 para 要素を選択する。descendant は、初期ノードセットにある各ノードが文脈の子孫でなければならないことを指定する。para は、初期ノードセットにある各ノードが para と名付けられた要素でなければならないことを指定する。利用可能な軸は[2.2 軸]で解説する。利用可能なノードテストは[2.3 ノードテスト]で解説する。ノードテストの中には、意味が軸によって異なるものもある。

初期ノードセットは、最初の述部によってフィルタリングされて、新しいノードセットを生成する。この新しいノードセットがその後2番目の述部を使ってフィルタリングされ、などとなっていく。軸は、各述部の式がどのように評価されるかに影響を及ぼすので、述部の意味論は軸に対する関係で定義される。[2.4 述部]を見ること。

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

2.2 軸

以下の軸が利用可能である。

ancestor, descendant, following, preceding, self 軸は(属性ノードや名前空間ノードを除いて)文書を分割することに注意してほしい。これらは重なり合わず、一緒にすると文書内のノードすべてを包含するのである。

[6]    AxisName    ::=    'ancestor'
| 'ancestor-or-self'
| 'attribute'
| 'child'
| 'descendant'
| 'descendant-or-self'
| 'following'
| 'following-sibling'
| 'namespace'
| 'parent'
| 'preceding'
| 'preceding-sibling'
| 'self'

2.3 ノードテスト

どの軸にも主ノード型がある。軸が要素を包含できる場合には、主ノード型は element である。そうではない場合には、軸が包含できるノードの型が主ノード型である。そこで、

QName であるノードテストは、そのノードが主ノード型であって、QName によって指定された展開名に等しい展開名をもつ場合には、かつ、もつ場合にのみ、真である。たとえば、child::para は、文脈ノードの子 para 要素を選択する。文脈ノードが子 para をもたない場合には、空のノードセットを選択することになる。attribute::href は、文脈ノードの href 属性を選択する。文脈ノードが href 属性をもたない場合には、空のノードセットを選択することになる。

ノードテストの中にある QName は、式の文脈からの名前空間宣言を使って展開名に展開される。これは、xmlns で宣言されたデフォルト名前空間が使われてない場合を除いた、開始タグおよび終了タグにある要素型名について展開がなされるのと同じである。QName がプリフィックスをとらない場合には、名前空間URIはヌルである(これは属性名が展開されるのと同じである)。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 述部

軸は、順行軸(forward axis)か逆行軸(reverse axis)かのいずれかである。文脈ノード、または文書順において文脈ノードの後にあるノードだけしか包含しない軸は、順行軸である。文脈ノード、または文書順において文脈ノードの前にあるノードだけしか含まない軸は、逆行軸である。そこで、ancestor 軸、ancestor-or-self 軸、preceding 軸、preceding-sibling 軸は逆行軸である。その他の軸はすべて順行軸である。self 軸はつねに最大で1個のノードしか包含しないから、順行軸であろうと逆行軸であろうと差異は生じない。軸についてノードセットのメンバーの近接度ポジション(proximity position)は、軸が順行軸である場合には文書順で、逆行軸である場合には逆文書順で並べたノードセットにおけるそのノードの位置であると定義される。最初のポジションは 1 である。

述部は、軸についてノードセットをフィルタリングして、新しいノードセットを生み出す。フィルタリングされるべきノードセットにあるノードごとに、PredicateExpr が、そのノードセットのノード数を文脈サイズとし、軸についてノードセットにおけるノードの近接度ポジションを文脈ポジションとして評価される。PredicateExpr がそのノードについて真と評価された場合には、そのノードは新しいノードセットに組み込まれる。そうでない場合には組み込まれない。

PredicateExpr は、Expr を評価してその結果をブール値に変換することにより、評価される。結果が数値である場合には、その結果は、数値が文脈ポジションに等しい場合には真に変換され、それ以外の場合には偽に変換されることになる。結果が数値でない場合には、結果は、boolean 関数を呼び出した場合のように変換されることになる。そこで、para[3] というロケーションパスは para[position()=3] と等価である。

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

2.5 省略文法

こちらは、省略文法を使ったロケーションパスの例である。

最も重要な省略は、child:: がロケーションステップから省くことができることである。実効的には、child はデフォルト軸である。たとえば、div/para というロケーションパスは、child::div/child::para の短縮形である。

属性にも省略形がある。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//paradiv/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 を使って式評価文脈の関数ライブラリにある関数を特定し、Argument(引数)のそれぞれを評価し、各引数を関数が要求する型に変換し、最後に関数を呼び出してそれに変換後の引数を渡すことにより、評価される。引数の数が誤っている場合や、引数が要求されている型に変換できない場合は、エラーである。FunctionCall 式の結果が、その関数によって返される結果である。

引数は、string 関数を呼び出した場合のように、文字列型に変換される。引数は、number 関数を呼び出した場合のように、数値型に変換される。引数は、boolean 関数を呼び出した場合のように、ブール値型に変換される。ノードセット型でない引数は、ノードセット型に変換できない。

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

3.3 ノードセット

ロケーションパスは、式として使うことができる。式は、そのパスによって選択されるノードのセットを返す。

| 演算子は、その被演算子の和集合を計算する。被演算子はノードセットでなければならない。

Predicate は、ロケーションパスで使われるのと同じように、式をフィルタリングするのに使われる。フィルタリングされるべき式がノードセットと評価されない場合は、エラーである。Predicate は、child 軸について、ノードセットをフィルタリングする。

註: Predicate の意味は、どの軸が適用されるかにより決定的に左右される。たとえば preceding::foo[1] は、[1] という述部に適用される軸が preceding 軸であるから、逆文書順における1番目の foo を返す。対照的に、(preceding::foo)[1] は、[1] という述部に適用される軸が child 軸であるから、文書順における1番目の 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個の値のうち1個をとることができる。

or 式は、各被演算子を評価して、その値を boolean 関数を呼び出した場合のようにブール値に変換することにより、評価される。いずれかの値が真である場合には結果は真であり、そうでない場合には偽である。左側の被演算子が真である場合には、右側の被演算子は評価されない。

and 式は、各被演算子を評価して、その値を boolean 関数を呼び出した場合のようにブール値に変換することにより、評価される。両方の値が真である場合には結果は真であり、そうでない場合には偽である。左側の被演算子が偽である場合には、右側の被演算子は評価されない。

(ただの RelationalExpr ではない) EqualityExpr または(ただの AdditiveExpr ではない)は、2つの被演算子を評価して帰結されるオブジェクトを比較することにより、評価される。結果のオブジェクトの比較は、以下の3段落で定義される。第一に、ノードセットが関わる比較が、ノードセットが関わらない比較を用いて定義される。これは、=, !=, <=, <, >=, > について統一的に定義される。第二に、ノードセットが関わらない比較が、=!= とについて定義される。第三に、ノードセットが関わらない比較が、<=, <, >=, > について定義される。

比較されるべきオブジェクトがともにノードセットである場合には、 二つのノードの文字列値に関して比較を実行した結果が真であるようなノードが、一つ目のノードセットと二つ目のノードセットとの中にあるときに、かつあるときにのみ、比較は真ということになる。比較されるべきオブジェクトの一方がノードセットであり他方が数値である場合には、比較対照の数値と、number 関数を使ってそのノードの文字列値を数値に変換した結果とについて比較を実行した結果が真になるようなノードがノードセットの中にあるときに、かつあるときにのみ、比較は真ということになる。比較されるべきオブジェクトの一方がノードセットであり他方が文字列である場合には、ノードの文字列値と他方の文字列との比較を実行した結果が真になるようなノードがノードセットの中にあるときに、かつあるときにのみ、比較は真ということになる。比較されるべきオブジェクトの一方がノードセットであり他方がブール値である場合には、ブール値と、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 に従って比較することにより、オブジェクトが比較される。< 比較は、一つ目の数値が二つ目の数値より小さい場合に、かつその場合にのみ、真ということになる。<= 比較は、一つ目の数値が二つ目の数値よりも小さいか等しい場合に、かつその場合にのみ、真ということになる。> 比較は、一つ目の数値が二つ目の数値よりも大きい場合に、かつその場合にのみ、真ということになる。>= 比較は、一つ目の数値が二つ目の数値よりも大きいか等しい場合に、かつその場合にのみ、真ということになる。

註: XPath式がXML文書の中に出現するとき、どの < 演算子および <= 演算子も、XML 1.0 規則に従って、たとえば &lt;&lt;= を使ってクオートされなければならない。以下の例では、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]をとることができる。これは、特殊な NaN ("Not-a-Number") 値、正および負の無限大、正および負のゼロを含む。IEEE 754 規格の鍵となる規則のまとめについては [JLS]Section 4.2.3 を見ること。

数値演算子は、被演算子を、number 関数を呼び出した場合のように数値に変換する。

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

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

註: XMLは名前の中の - を認めるから、- 演算子は概して空白に先行される必要がある。たとえば、foo-bar は、foo-bar という名前の子要素を包含するノードセットと評価される。foo - bar は、1番目の子 foo 要素の文字列値を数値に変換した結果と、1番目の子 bar を数値に変換した結果との差を評価する。

div 演算子は、IEEE 754 に従って、浮動小数点除算を実行する。

mod 演算子は、打ち切り除算(trancating division)の剰余を返す。たとえば、

註: これは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 文字列

文字列は0個以上のキャラクタの連なりからなる。ここでキャラクタとは、XML勧告[XML]と同様に定義される。そのためXPath内の単一キャラクタは、単一の対応するUnicodeスカラー値をもつ単一のUnicode抽象キャラクタに対応する([Unicode]を見よ)。これは、16ビットUnicode値と同じものではない。U+FFFFより大きいUnicodeスカラー値をもつ抽象キャラクタのUnicodeコードキャラクタ表現は、16ビットUnicodeコード値の対である(サロゲートペア)。多くのプログラミング言語では、文字列は16ビットUnicodeコード値の連なりにより表現される。そうした言語によるXPathの実装物は、サロゲートペアが正しく単一のXPathキャラクタとして確実に扱われるよう注意しなければならない。

註: 異なるUnicode抽象キャラクタ列からなるにもかかわらず同一のものとして扱われるべき2つの文字列が存在することが、Unicodeにおいては可能である。たとえば、アクセントつきキャラクタのなかには、合成済み形式でも分解形式でも表現してよいものがある。したがって、XPath式は、XPath式とXML文書との両方のキャラクタが正典的形式(canoical form)に普通化されているのでない限り、予期しない結果を返す場合がある。[Character Model]を見ること。

3.7 レキシカルな構造物

トークン化の際には、つねにできるだけ長いトークンが返される。

読みやすくするため、文法によって明示的に許容されていない場合であっても、空白を式の中で使ってもかまわない。ExprWhitespace は、任意の ExprToken の前または後のパターンの内部で自由に追加してよい。

以下の特殊なトークン化規則は、ExprToken 文法の曖昧さを取り除くために適用されなければならないものである。

式レキシカルな構造物
[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実装物が、式を評価するのに使われる関数ライブラリのなかにつねに組み込まなければならない関数を解説する。

関数ライブラリにある各関数は、関数プロトタイプを使って規定される。これは、返り値型、関数名、引数の型を与えるものである。引数型に疑問符が続いている場合には、その引数はオプションである。それ以外の場合は、引数は必須である。

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がヌルである場合には、空文字列が返される。引数が省略された場合には、文脈ノードを唯一のメンバーとするノードセットがデフォルトとされる。

註: namespace-uri 関数によって返される文字列は、要素ノードや属性ノードを除いては、空ということになる。

関数: string name(node-set?)

name 関数は、引数ノードセット中の文書順において最初のノードの展開名を表現するQNameを包含する文字列を返す。QName は、展開名が表現対象とされているノードに効力を有する名前空間宣言との関係における展開名を表現するものでなければならない。概して、これは、XMLソースの中に出現した QName ということになる。これは、同じ名前空間に複数のプリフィックスが結びつけられているノードに効力を有する名前空間宣言がある場合には、そのようになる必要はない。もっとも、実装物は、そのノードの表現において元のプリフィックスについての情報を組み込んでもかまわない。この場合には、実装物は、返された文字列が、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 関数は、1つ目の引数文字列のうち、2つ目の引数文字列が最初に出現するところよりも前にある部分文字列を返すが、1つ目の引数文字列が2つ目の引数文字列を包含しない場合には空文字列を返す。たとえば、substring-before("1999/04/01","/")1999 を返す。

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

substring-after 関数は、1つ目の引数文字列のうち、2つ目の引数文字列が最初に出現するところよりも後にある部分文字列を返すが、1つ目の引数文字列が2つ目の引数文字列を包含しない場合には空文字列を返す。たとえば、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 であり、などとなっていく。

註: これはJavaやECMAScriptとは異なる。そちらでは、String.substring メソッドは、最初のキャラクタのポジションを 0 として扱う。

返される部分文字列は、そのキャラクタのポジションが2つ目の引数の丸め値以上であり、また3つ目の引数が指定されている場合には、2つ目の引数の丸め値と3つ目の引数の丸め値との合計よりも小さいキャラクタを包含する。上記で使われる比較や加算は、標準的な IEEE 754 規則に従う。丸めは、round 関数を呼び出した場合のように行われる。以下の例は、さまざまな異常なケースを説明したものである。

関数: number string-length(string?)

string-length は、文字列内のキャラクタ数を返す([3.6 文字列]を見よ)。引数が省略された場合には、文脈ノードを文字列に変換したもの、言い換えると文脈ノードの文字列値がデフォルトとされる。

関数: string normalize-space(string?)

normalize-space 関数は、先頭及び末尾の空白を剥がし、空白キャラクタの連なりを単一のスペースで置き換えることにより空白を普通化した引数文字列を返す。空白キャラクタは、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つ目の引数文字列の中で1つのキャラクタが2回以上出現する場合には、最初に出現したものが置換キャラクタを決定する。3つ目の引数文字列が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("en") ならば、文脈ノードがこれら5つの要素のどれかであるならば真を返すことになる。

<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 関数は、その要素により使われている言語中立的フォーマットが Number についてのXPathシンタックスと一貫するものでない限り、使うことができない。

関数: number sum(node-set)

sum 関数は、引数ノードセット内の各ノードについてノードの文字列値を数値に変換した結果の合計を返す。

関数: number floor(number)

floor 関数は、引数よりも大きくなく、かつ整数である最も大きい(正の無限大に近い)数値を返す。

関数: number ceiling(number)

ceiling 関数は、引数よりも小さくなく、かつ整数である最も小さい(負の無限大に近い)数値を返す。

関数: number round(number)

round 関数は、引数に最も近く、かつ整数である数値を返す。そうした数値が2つある場合には、正の無限大に近い方が返される。引数が NaN である場合には、NaN が返される。引数が正の無限大である場合には、正の無限大が返される。引数が負の無限大である場合には、負の無限大が返される。引数が正のゼロである場合には、正のゼロが返される。引数が負のゼロである場合には、負のゼロが返される。引数がゼロより小さいが -0.5 以上である場合には、負のゼロが返される。

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

5 データモデル

XPathは、樹としてのXML文書に作用する。このセクションでは、XPathがどのようにしてXML文書を樹としてモデル化するかを解説する。このモデルはもっぱら概念的なものであって、何ら特定の実装を強制するものではない。XML情報セット[XML Infoset]に対するこのモデルの関連性は、[B XML情報セットの割り付け]で解説される。

XPathが作用するXML文書は、XML名前空間勧告[XML Names]に適合していなければならない。

樹はノードを包含する。ノードには7つの型がある。

ノード型ごとに、その型のノードについて文字列値を決定する方法がある。あるノード型では、文字列値はノードの一部分である。他のノード型では、文字列値は子孫ノードの文字列値から計算されるものもある。

註: 要素ノードやルートノードについては、ノードの文字列値は、DOMの nodeValue メソッド([DOM]を見よ。)によって返される文字列と同じものではない。

ノード型の中には展開名ももつものがある。これは、ローカル部分と名前空間URIとの対からなる。ローカル部分は文字列である。名前空間URIは、ヌルか文字列かのいずれかである。XML文書において指定される名前空間URIは、[RFC2396]で定義されているURI参照であることができる。これは、フラグメント識別子をとることができ、また相対形式であることができるという意味である。相対URIは、名前空間処理の間に絶対URIに解釈されるべきである。データモデルにおけるノードの展開名の名前空間URIは、絶対形式であるべきである。二つの展開名は、同じローカル部分をもち、かつともにヌル名前空間URIをもつかともに等しい非ヌル名前空間URIをもつ場合に、等しい。

文書順という整序があり、これは、一般実体の展開の後の文書のXML表現の中において出現する各ノードのXML表現の最初のキャラクタが出現する順序に対応して、文書内のすべてのノードについて定義される。そこで、ルートノードは最初のノードということになる。要素ノードは、その子より先に出現する。そこで、文書順は、(実体展開後の)XMLにおける開始タグの出現順序に要素ノードを整序する。要素の属性ノードおよび名前空間ノードは、その要素の子より先に出現する。名前空間ノードは、属性ノードより先に出現するものと定義される。名前空間ノードの相対的順序は実装依存である。属性ノードの相対的順序は実装依存である。逆文書順とは、文書順を逆にしたものである。

ルートノードおよび要素ノードは、有順序の子ノードリストをもつ。ノードは決して子を共有することがない。あるノードが他のノードと異なる場合には、一方のノードの子はどれも他方のノードの子と同じノードとならないことになる。ルートノード以外のノードは、ノードごとにちょうど1個のをもつ。これは要素ノードかルートノードかのいずれかである。ルートノードまたは要素ノードは、その子ノードのそれぞれの親である。ノードの子孫とは、そのノードの子、およびそのノードの子の子孫である。

5.1 ルートノード

ルートノードは、樹のルート(根)である。ルートノードは、樹のノードとして以外は出現しない。文書要素の要素ノードは、ルートノードの子である。またルートノードは、プロローグ部や文書要素の末尾の後に出現する処理命令や注釈をあらす子処理命令ノードや子注釈ノードをとる。

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

ルートノードは展開名をもたない。

5.2 要素ノード

文書内の要素ごとに1個の要素ノードがある。要素ノードは、XML名前空間勧告[XML Names]に従って、タグ内に指定されている要素の QName を展開することにより計算される展開名をもつ 要素の展開名の名前空間URIは、QName がプリフィックスをもたず、かつ適用可能なデフォルト名前空間がない場合には、ヌルということになる。

註: [XML Names]の Appendix A.3 の表記法では、展開名のローカル部分は ExpEType 要素の type 属性に一致する。展開名の名前空間URIは、ExpEType 要素の ns 属性に一致し、ExpEType 要素の ns 属性が省略されている場合にはヌルである。

要素ノードの子は、その内容をあらわす要素ノードや注釈ノード、処理命令ノード、テキストノードである。内部実体、外部実体双方に対する実体参照は、展開される。キャラクタ参照は、解釈される。

要素ノードの文字列値は、その要素ノードの子孫テキストノードすべての文字列値を文書順に結合したものである。

5.2.1 一意的ID

要素ノードは、一意的な識別子(ID)を1個とってもかまわない。これは、DTDにおいて ID 型として宣言された属性の値である。一つの文書内の二つ要素が同じ一意的IDをとってはならない。XMLプロセッサが、同じ一意的IDを有するものとして文書内の二つの要素をレポートした場合(これは文書が妥当でない場合にのみ起こりうる。)には、文書順において2番目の要素は一意的IDをもたないものとして扱われなければならない。

註: 文書がDTDをもたない場合には、文書内のどの要素も一意的IDをもたないことになる。

5.3 属性ノード

それぞれの要素ノードには、属性ノードのセットが結びつけられている。要素は、これらの属性ノードそれぞれのである。もっとも、属性ノードはその親要素の子ではない。

註: これはDOMと異なっている。DOMは、属性を帯同している要素を、その属性の親として扱わない([DOM]を見よ)。

要素は、決して属性ノードを共有しない。ある要素ノードが他の要素ノードと異なる場合には、一方のノードの属性ノードはどれも、他方の要素ノードの属性ノードと同じものとならないことになる。

デフォルトされた属性は、指定のある属性と同じものとして扱われる。ある属性がDTDの中の要素型について宣言されているが、デフォルトが #IMPLIED として宣言されており、属性が要素上で指定されていない場合には、その要素の属性セットにはその属性のノードは包含されない。

xml:langxml:space といったようないくつかの属性は、他の子孫要素上で同じ属性のインスタンスを用いて上書きされない限りはその属性を帯同する要素の子孫である要素すべてに適用される意味論をもつ。もっとも、これは、属性ノードが樹の中で出現する場所に影響を及ぼさない。要素は、その要素の開始タグまたは空要素タグで明示的に指定された属性、またはDTDでデフォルト値つきで明示的に宣言された属性についてのみ、属性ノードをもつ。

属性ノードは、展開名文字列値とをもつ。展開名は、XML名前空間勧告[XML Names]に従って、XML文書のタグの中で指定された QName を展開することにより計算される。属性名の名前空間URIは、その属性の QName がプリフィックスをもたない場合には、ヌルということになる。

註: [XML Names]の Appendix A.3 の表記法では、展開名のローカル部分は ExpAName 要素の name 属性に対応する。展開名の名前空間URIは ExpAName 要素の ns 属性に対応し、ExpAName 要素の ns 属性が省略された場合にはヌルである。

属性ノードは文字列値をもつ。文字列値は、XML勧告[XML]によって規定された普通化済み値である。普通化済み値がゼロ長文字列である属性は、特別に扱われない。文字列値がゼロ長文字列である属性ノードとなるのである。

註: デフォルト属性が外部DTDや外部パラメータ実体の中で宣言されることがありうる。XML勧告は、XMLプロセッサが妥当性検証を行うものでない限り、外部DTDや外部パラメータを読むことを要求していない。外部DTDまたは外部パラメータ実体で宣言されたデフォルト属性値をXPath樹が含んでいることを前提とするスタイルシートは、妥当性検証を行わないいくつかのXMLプロセッサでは動作しない場合がある。

名前空間を宣言する属性([XML Names]を見よ。)に対応する属性ノードはない。

5.4 名前空間ノード

各要素は、その要素のスコープ内にある異なる名前空間プリフィックスごとに1個、デフォルト名前空間が要素のスコープ内にある場合にはそれについて1個の名前空間ノードのセットを結びつけられている。要素は、これらの名前空間ノードのそれぞれのである。もっとも、名前空間ノードはその親要素の子ではない。要素は、決して名前空間ノードを共有しない。ある要素ノードが他の要素ノードと同じでない場合には、一方の要素ノードの名前空間ノードはどれも、他方の要素のノードの名前空間ノードと同じものではないことになる。これは、要素が、つぎのものについて1個ずつの名前空間ノードをもつという意味である。

名前空間ノードは展開名をもつ。ローカル部分は、名前空間プリフィックスである(これは、名前空間ノードがデフォルト名前空間のものである場合には空である)。名前空間URIは、つねにヌルである。

名前空間ノードの文字列値は、名前空間プリフィックスが結びつけられている名前空間URIである。これが相対形式である場合には、展開名の名前空間のように展開解釈しれなければならない。

5.5 処理命令ノード

文書型宣言の内部に出現する処理命令を除き、処理命令ごとに1個の処理命令ノードがある。

処理命令は展開名をもつ。ローカル部分は、処理命令のターゲットである。名前空間URIはヌルである。処理命令ノードの文字列値は、処理命令のうち、ターゲットおよび任意の空白に続く部分である。終端の ?> は含まない。

註: XML宣言は、処理命令ではない。したがって、XML宣言に対応する処理命令ノードはない。

5.6 注釈ノード

文書型宣言の内部に出現する注釈を除き、注釈ごとに1個の注釈ノードがある。

注釈の文字列値は、開始 <!-- や終了 --> を含まない注釈の内容である。

注釈ノードは展開名をもたない。

5.7 テキストノード

キャラクタデータはテキストノードにまとめられる。できるだけ大量のキャラクタデータがそれぞれのテキストノードへとまとめられる。テキストノードは、テキストノードである兄弟を直前または直後にもつことがない。テキストノードの文字列値は、キャラクタデータである。テキストノードはつねに、少なくとも1個のキャラクタデータをもつ。

CDATA部の中にあるキャラクタはそれぞれが、キャラクタデータとして扱われる。そこで、ソース文書内の <![CDATA[<]]> は、&lt; と同じく扱われる。ともに、樹の中のテキストノードでは単一の < キャラクタとなることになる。そこで、CDATA部は、あたかも <![CDATA[]]> とが除去され、<& の出現箇所ごとがそれぞれ &lt;&amp; で置き換えられた場合のように扱われる。

註: < キャラクタを包含するテキストノードがXMLとして書き出されるとき、< キャラクタは、たとえば &lt; を使い、またはそれをCDATA部に組み込んで、エスケープしなければならない。

注釈や処理命令、属性値の内部のキャラクタは、テキストノードを生み出さない。外部実体の行末は、XML勧告[XML]で規定されるとおり #xA に普通化される。

テキストノードは展開名をもたない。

6 適合性

XPathは、主としてその他の仕様書で使うことができる組み立て部品のつもりのものである。したがって、XPathは、XPathの実装物の適合性の判断基準を規定は([XPointer][XSLT]といったような)仕様書に依存し、独立のXPathの実装物についての適合性判断基準は定義しない。


A 参考資料

A.1 規範的な参考資料

IEEE 754
Institute of Electrical and Electronics Engineers. IEEE Standard for Binary Floating-Point Arithmetic. ANSI/IEEE Std 754-1985.
RFC2396
T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax. IETF RFC 2396. http://www.ietf.org/rfc/rfc2396.txt を見よ。
XML
World Wide Web Consortium. Extensible Markup Language (XML) 1.0. W3C勧告. http://www.w3.org/TR/1998/REC-xml-19980210 を見よ。
XML Names
World Wide Web Consortium. Namespaces in XML. W3C勧告. http://www.w3.org/TR/REC-xml-names を見よ。

A.2 その他の参考資料

Character Model
World Wide Web Consortium. Character Model for the World Wide Web. W3Cワーキングドラフト. http://www.w3.org/TR/WD-charmod を見よ。
DOM
World Wide Web Consortium. Document Object Model (DOM) Level 1 Specification. W3C勧告. http://www.w3.org/TR/REC-DOM-Level-1 を見よ。
JLS
J. Gosling, B. Joy, and G. Steele. The Java Language Specification.http://java.sun.com/docs/books/jls/index.html を見よ。
ISO/IEC 10646
ISO (International Organization for Standardization). ISO/IEC 10646-1:1993, Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. International Standard. http://www.iso.ch/cate/d18741.html を見よ。
TEI
C.M. Sperberg-McQueen, L. Burnard Guidelines for Electronic Text Encoding and Interchange. http://etext.virginia.edu/TEI.html を見よ。
Unicode
Unicode Consortium. The Unicode Standard. http://www.unicode.org/unicode/standard/standard.html を見よ。
XML Infoset
World Wide Web Consortium. XML Information Set. W3Cワーキングドラフト. http://www.w3.org/TR/xml-infoset を見よ。
XPointer
World Wide Web Consortium. XML Pointer Language (XPointer). W3Cワーキングドラフト. http://www.w3.org/TR/WD-xptr を見よ。
XQL
J. Robie, J. Lapp, D. Schach. XML Query Language (XQL). http://www.w3.org/TandS/QL/QL98/pp/xql.html を見よ。
XSLT
World Wide Web Consortium. XSL Transformations (XSLT). W3C勧告案.http://www.w3.org/TR/xslt を見よ。

B XML情報セットの割り付け (非規範的)

XPathデータモデル内のノードは、以下のようにして、XML情報セット[XML Infoset]によって提供される情報項目から引き出すことができる。

註: 新しいバージョンのXML情報セットのワーキングドラフトは5月17日版を置き換えることになるが、XPathのこのバージョンの準備が完了した時点では完成に近く、XPathのこのバージョンのリリースと同時または直後にリリースされるものと思われる。割り付けは、この新しいバージョンのXML情報セットドラフトについて与えられる。新しいバージョンのXML情報セットワーキングドラフトがまだリリースされていない場合、W3Cメンバーは内部的なワーキンググループ版 http://www.w3.org/XML/Group/1999/09/WD-xml-infoset-19990915.html (メンバー専用)を参考にしてもかまわない。

C 以前の公開ワーキングドラフトからの変更点 (非規範的)


どら猫本舗 (webmaster@doraneko.org)