XMLパス言語 (XPath) Version 1.0


W3C

XMLパス言語 (XPath)
Version 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. and Brown University) <Steven_DeRose@Brown.edu>

概要

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

この文書の位置づけ

この文書は、W3C会員およびその他の利害関係者によりレビューされ、ディレクターによってW3C勧告(Recommendation)として公布されているものである。この文書は安定的な文書であって、参照素材として利用したり、他の文書から規範的リファレンスとしての引用に利用してもかまわない。勧告を作成する際のW3Cの役割は、仕様に対する注意を引き、その広範な配備を推進することになる。このことは、ウェブの機能と相互運用性とを高める。

この仕様書[原文]の既知のエラーの一覧は 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ワーキンググループとXMLリンキング ワーキンググループとの合同作業であり、そこで、W3Cスタイルアクティビティの一部であり、かつW3C XMLアクティビティの一部である。

目次

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情報セットの割り付け (非規範的)

1 はじめに

XPathは、XSL変形[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]を完全にサポートしている。そこで、ノードの名前は、ローカル部分1個と、ヌルでもよいが名前空間URI1個とからなるペアとしてモデル化される。これは展開名と呼ばれる。データモデルについては、[5 データモデル]で詳しく解説する。

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

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

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

変数バインディングは、変数名から変数値への割り付け関係からなる。変数の値はオブジェクトであり、これは式の値が取りうる型のどれかであってもよく、ここには規定されていない追加型のものであってもかまわない。

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

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

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

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

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

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

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

2 ロケーションパス

ロケーションパスは、言語の中でもっとも一般性を有する文法構造物ではない(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つの部分をもつ。

ロケーションステップの文法は、軸名とノードテストとが二重コロンによって区切られたものに、それぞれ角括弧の中に囲まれた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 軸は、(属性や名前空間ノードを無視すると)1個の文書を分割する。これらは重なり合わず、一緒になってその文書の中にあるノードすべてを包含するのである。
[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 であるノードテストは、そのノードの型([5 データモデル]を見よ。)が主ノード型であり、かつ 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 である引数を1個とることがある。この場合には、その Literal の値に等しい名前をもつ任意の処理命令について真である。

node() というノードテストは、どのようなものであろうと任意の型の任意のノードにつき真である。

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

2.4 述部

軸は、順行軸と逆行軸とのいずれかである。文脈ノード、または文書順において文脈ノードの後にあるノードしか包含しない軸は、順行軸である。文脈ノード、または文書順において文脈ノードの前にあるノードしか包含しない軸は、逆行軸である。そこで、ancestor, ancestor-or-self, preceding, preceding-sibling 軸は逆行軸である。その他の軸はすべて順行軸である。self 軸は、いつでも最大で1個のノードを包含するものであるから、順行軸であろうと逆行軸であろうと違いはない。 軸に対する関係におけるそのノードのメンバーの近接ポジションは、軸が順行軸である場合には文書順に、軸が逆行軸である場合には逆文書順に並べられたノードセットにおけるそのノードのポジションであると定義される。最初のポジションは 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 要素を選択する。前者は、その親の1番目の子 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 要素を返すのである。

/ 演算子および // 演算子は、式や相対ロケーションパスを合成する。式がノードセットに評価されない場合は、エラーである。/ 演算子は、/ がロケーションパスの中で使われるときと同じようにして合成を行う。ロケーションパスにおけるのと同様、///decendant-or-self::node() の短縮形である。

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

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

3.4 ブール値

boolean 型のオブジェクトは、真と偽という2つの値のうち1つをとることができる。

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

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

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

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

註: 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)値や、正および負の無限大、正および負のゼロが含まれる。IEEE 754 規格の鍵となる規則のまとめは、[JLS]Section 4.2.3 を見ること。

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

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

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

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

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

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

註: これは、JavaやECMAScriptの % 演算子と同じものである。
註: これは IEEE 754 剰余演算子と同じものではない。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における1個のキャラクタは、1個の対応するUnicodeスカラー値をもつ1個のUnicode抽象キャラクタに対応する([Unicode]を見よ)。これは、16ビットUnicodeコード値と同じものではない。U+FFFF より大きいUnicodeスカラー値をもつ抽象キャラクタのUnicodeコード化キャラクタ表現は、16ビットUnicodeコード値の対(サロゲートペア)となる。多くのプログラミング言語では、文字列は、16ビットUnicodeコード値の連なりによって表現される。そうした言語でXPathを実装するには、サロゲートペアが単一のXPathキャラクタとして正しく扱われることが保証されるよう注意しなければならない。

註: Unicodeにおいては、別のUnicode抽象キャラクタの連なりからなるにもかかわらず同一のものとして扱われるべき2つの文字列が存在しうる。たとえば、アクセントつきキャラクタは、合成済み形式でも分解形式でも表現されることがある。したがって、XPath式のキャラクタとXML文書のキャラクタとの両方が正典的形式に普通化されているのでない限り、XPath式が予期しない結果を返すことがある。[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 のノード数を返す。

関数: node-set id(object)

id 関数は、その一意的IDによって要素を選択する([5.2.1 一意的ID]を見よ)。id への引数が node-set 型である場合、結果は、引数 node-set のノードのそれぞれの文字列値id を適用した結果の和集合である。id への引数がその他の型である場合、引数は、string 関数を呼び出したかのようにして、文字列に変換される。文字列は、空白で切り分けられたトークンのリストに分割される(空白とは生成規則 S に合致する任意のキャラクタ列である)。結果は、文脈ノードと同じ文書の中にある要素で、リスト内のトークンのどれかに等しい一意的IDをもつものを包含したノードセットである。

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

local-name 関数は、引数 node-set のノードのうち文書順において最初のものの展開名のローカル部分を返す。引数 node-set が空である場合や、最初のノードが展開名をもたない場合には、空文字列が返される。引数が省略された場合、文脈ノードを唯一のメンバーとするノードセットがデフォルトとされる。

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

namespace-uri 関数は、引数 node-set のノードのうち文書順において最初のものの展開名の名前空間URIを返す。引数 node-set が空である場合や、最初のノードが展開名をもたない場合、展開名の名前空間URIがヌルである場合には、空文字列が返される。引数が省略された場合、文脈ノードを唯一のメンバーとするノードセットがデフォルトとされる。

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

関数: string name(node-set?)

name 関数は、引数 node-set のノードのうち文書順において最初のものの展開名を表す QName を包含する文字列を返す。QName は、展開名が表されているノードについて効力を有する名前空間宣言に関して展開名を表すものでなければならない。これはXMLソースの中に出現した QName であるのが典型であろう。ノードについて効力を有する名前空間宣言で、同じ名前空間に複数のプリフィックスを結びつけるものがある場合には、こうである必要はない。もっとも、実装物は、元のプリフィックスについての情報をそのノードの表現に組み込んでもかまわない。この場合、実装物は、返された文字列がXMLソースで使われている QName とつねに同じものであることを保証することができる。引数 node-set が空である場合や、最初のノードが展開名をもたない場合には、空文字列が返される。引数が省略された場合、文脈ノードを唯一のメンバーとするノードセットがデフォルトとされる。

註: 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つ目の引数 string が2つ目の引数 string で始まる場合には真を返し、それ以外の場合には偽を返す。

関数: boolean contains(string, string)

contains 関数は、1つ目の引数 string が2つ目の引数 string を包含している場合には真を返し、それ以外の場合には偽を返す。

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

substring-before 関数は、1つ目の引数 string の中で2つ目の引数 string が最初に出現する箇所の前に来る、1つ目の引数 string の部分文字列を返す。1つ目の引数 string が2つ目の引数 string を包含しない場合には、空文字列を返す。たとえば、 substring-before("1999/04/01","/")1999 を返す。

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

substring-after 関数は、1つ目の引数 string の中で2つ目の引数 string が最初に出現する箇所の後に来る、1つ目の引数 string の部分文字列を返す。1つ目の引数 string が2つ目の引数 string を包含しない場合には、空文字列を返す。たとえば、 substring-after("1999/04/01","/")04/01 を返し、substring-after("1999/04/01","19")99/04/01 を返す。

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

substring 関数は、2つ目の引数で指定された箇所で始まり、3つ目の引数で指定された長さをもつ、1つ目の引数の部分文字列を返す。たとえば、substring("12345",2,3)"234" を返す。3つ目の引数が指定されない場合には、2つ目の引数で指定された箇所で始まり、文字列の末尾まで続く部分文字列を返す。たとえば、substring("12345",2)"2345" を返す。

より厳密にいうと、文字列([3.6 文字列]を見よ。)の中にあるキャラクタはそれぞれ、数値で示されるポジションをもつものとみなされる。1番目のキャラクタのポジションは 1 であり、2番目のキャラクタのポジションは 2 であり、などとなっている。

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

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

関数: number string-length(string?)

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

関数: string normalize-space(string?)

normalize-space 関数は、引数 string を、先頭および末尾の空白を除去し、空白キャラクタが連なった部分をスペース1個で置き換えることにより普通化して返す。空白キャラクタとは、XMLの S 生成規則によって認められているものと同じである。引数が省略された場合には、文脈ノードを文字列に変換したもの、言い換えると、文脈ノードの文字列値がデフォルトとされる。

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

translate 関数は、1つ目の引数 string を、2つ目の引数 string の中にあるキャラクタが出現する箇所を、3つ目の引数 string の中で対応する位置にあるキャラクタで置き換えて返す。たとえば、 translate("bar","abc","ABC")BAr という文字列を返す。(2つ目の引数 string が3つ目の引数 string よりも長いために)2つ目の引数 string の中のキャラクタで、3つ目の引数 string の中で対応する位置にキャラクタがないものがある場合には、そのキャラクタが1つ目の引数 string の中で出現する箇所は除去される。たとえば、translate("--aaa--","abc-","ABC")"AAA" を返す。2つ目の引数 string の中で2回以上出現するキャラクタがある場合、最初に出現するものが置換キャラクタを決定する。3つ目の引数 string が2つ目の引数 string よりも長い場合、余分なキャラクタは無視される。

註: translate 関数は、すべての言語における大文字小文字の変換について十分な解決策であるというわけではない。将来のバージョンのXPathは、大文字小文字の変換のために追加的な関数を用意するかもしれない。

4.3 ブール値関数

関数: boolean boolean(object)

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

関数: boolean not(boolean)

not 関数は、引数が偽である場合に真を返し、そうでない場合には偽を返す。

関数: boolean true()

true 関数は、真を返す。

関数: boolean false()

false 関数は、偽を返す。

関数: boolean lang(string)

lang 関数は、xml:lang 属性によって指定されている文脈ノードの言語が、引数 string によって指定される言語と同じ、あるいはその下位言語であるかどうかにより、真または偽を返す。文脈ノードの言語は、文脈ノードの xml:lang 属性、または文脈ノードに xml:lang 属性がない場合には、文脈ノードの、xml:lang 属性をもつ直近の祖先の値によって決定される。そうした属性がない場合、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 関数は、引数 node-set の各ノードについてそのノードの文字列値を数値に変換した結果の合計を返す。

関数: number floor(number)

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

関数: number ceiling(number)

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

関数: number round(number)

round 関数は、引数に最も近く、かつ整数である数値を返す。そうした数値が2つある場合、正の無限大に近い方が返される。引数がNaNである場合、NaNが返される。引数が正の無限大である場合、正の無限大が返される。引数が負の無限大である場合、負の無限大が返される。引数が正のゼロである場合、正のゼロが返される。引数が負のゼロである場合、負のゼロが返される。引数が 0 未満だが -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は、絶対URIであるべきである。2つの展開名は、同じローカル部分を持ち、かつ、ともにヌル名前空間URIをとるかともに等しい非ヌル名前空間URIをとるかする場合、等しい。

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

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

5.1 ルートノード

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

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

ルートノードには展開名がない。

5.2 要素ノード

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

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

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

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

5.2.1 一意的ID

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

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

5.3 属性ノード

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

註: これはDOMとは異なる。DOMは、属性を生み出す要素を属性の親として扱っていない([DOM]を見よ)。

要素は、属性ノードを共有することは決してない。ある要素ノードがもう一つの要素ノードと同じものでない限り、一方の要素ノードの属性ノードには、他方の要素ノードの属性ノードと同じものがないことになる。

註: = 演算子は、2つのノードが同じ値をもつかどうかをテストするものであって、同じノードであるかどうかをテストするものではない。そこで、2つの異なる要素の属性は、同じノードでないにもかかわらず、= を用いて等しいものとして比較される場合がある。

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

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

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

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

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

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

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

5.4 名前空間ノード

各要素には名前空間ノードのセットが結びつけられている。このセットは、その要素のスコープ内にある各別の名前空間プリフィックス(xml プリフィックスを含む。これはXML名前空間勧告[XML Names]によって黙示的に宣言されている。)につき名前空間ノード1個ずつ、またデフォルト名前空間がその要素のスコープ内にある場合にはそれにつき名前空間ノード1個というものである。要素は、これらの名前空間ノードそれぞれのである。もっとも、名前空間ノードは、その親要素の子ではない。要素は決して、名前空間ノードを共有することはない。ある要素ノードが他の要素ノードと同じノードでない場合、一方の要素ノードの名前空間ノードの中には、他方の要素ノードの名前空間ノードと同じノードであるものはないことになる。これは、要素が、つぎのものについて1個の名前空間ノードをもつということを意味している。

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

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

5.5 処理命令ノード

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

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

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

5.6 注釈ノード

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

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

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

5.7 テキストノード

キャラクタデータは、テキストノードにまとめられる。各テキストノードには、可能な限り多くのキャラクタデータがまとめられる。テキストノードは決して、テキストノードである直前または直後の兄弟をもつことがない。テキストノードの文字列値は、キャラクタデータであテキストノードはつねに、少なくとも1個のデータキャラクタをもつ。

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

註: < キャラクタを含んでいるテキストノードがXMLとして書き出されるとき、< キャラクタは、たとえば &lt; を使ったり、CDATAセクションの中に組み込んだりして、エスケープしなければならない。

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

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

6 適合性

XPathは、主に、他の仕様書で利用できるコンポーネントとするというのが狙いである。したがって、XPathは、XPathの実装の適合性についての判断基準を規定することは、([XPointer][XSLT]といったような)XPathを利用する仕様に頼り、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 Recommendation. http://www.w3.org/TR/1998/REC-xml-19980210 を見よ。
XML Names
World Wide Web Consortium. Namespaces in XML. W3C Recommendation. http://www.w3.org/TR/REC-xml-names を見よ。

A.2 その他の参照資料

Character Model
World Wide Web Consortium. Character Model for the World Wide Web. W3C Working Draft. http://www.w3.org/TR/WD-charmod を見よ。
DOM
World Wide Web Consortium. Document Object Model (DOM) Level 1 Specification. W3C Recommendation. 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 Working Draft. http://www.w3.org/TR/xml-infoset を見よ。
XPointer
World Wide Web Consortium. XML Pointer Language (XPointer). W3C Working Draft. 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 Recommendation. 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 (会員専用) を参考にしてもよい。

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