WD-xptr-19980303
WD-xptr-19980303
これは、W3C会員およびその他の利害関係者による検討のためのW3Cワーキングドラフトである。この文書はドラフト文書であって、何時にても他の文書によって更新・置換・廃止される場合がある。W3Cワーキングドラフトを参照資料として用いたり「進行中の作業」以外のものとして引用することは不適切である。現行のW3Cドラフトの一覧は http://www.w3.org/TR で見ることができる。
これはW3C XMLアクティビティ(現状については http://www.w3.org/MarkUp/XML/Activity を見ること)の一部である。XPointer を使うことが予定されている XLink 言語についての情報は http://www.w3.org/TR/WD-xlink を見ること。
XPointer の情報を提供する設計理念についての追加的な背景事情はhttp://www.w3.org/TR/NOTE-xlink-principlesを見ること。
この文書は、XML文書の内部構造へのアドレッシングをサポートする構成概念を仕様化する。特に、明示的なID属性を生み出すか否かを問わず、要素、キャラクタ文字列やXML文書のその他の部分への具体的な参照を提供する。
この文書は、XML文書の内部構造へのアドレッシングをサポートする言語を仕様化する。特に、明示的なID属性を生み出すか否かを問わず、要素、キャラクタ文字列やXML文書のその他の部分への具体的な参照を提供する。
以下は XPointerを支配する設計理念のまとめである。
3つの規格が特に影響力を有している。
その他数多くのリンクシステム、特に Dexter, FRESS, MicroCosm, InterMedia も、この設計に対して情報を与えている。
この文書においては以下の基本的用語が適用される。
ロケータの形式的な文法は、XML仕様書で説明されている単純なEBNF(Extended Backus-Naur Form)ロケーションを使って与えられる。
リソースのためのロケータは、概して、URI (Uniform Resource Identifier) によって与えられる。XPointer は、より正確なサブリソースを指定するために、URI構造と結びついたフラグメント識別子として使うことができる。XMLリソースを指し示すフラグメント識別子はどれも XPointer でなければならない。しかしながら、XML文書でないリソース(たとえばHTML文書やPDF文書)を識別するXMLリソース内のロケータについては、XPointer はロケータの文法や意味を制約しない。
XPointer は、XML文書の要素やその他のマークアップ構造によって定義された樹の上で作用する。
XPointer は、一連のロケーションタームからなり、そのそれぞれが、大抵は先のロケーションタームによって指定されたロケーションとの相対関係で、ロケーションを指定する。それぞれのロケーションタームは(id, child, ancestor などといった)キーワードをもっており、インスタンス数や要素型、属性といったような引数をとることができる。たとえば、child(2,CHAP) というロケーションタームは、CHAP という型である2つ目の子要素を参照する。
XPointer の中心部分は、アドレッシング情報の基本単位であるロケーションタームである。XPointer の中でのロケーションタームの組み合わせは、正確な位置を指定するという効果をもつ。
| XPointer | ||||||||||||||||||||||||||||||||||||
|
多数の XPointer が、要素樹の中の個別のノードを位置づけている。しかしながら、ロケーションタームの中には、より複雑なデータセットを位置づけるものもある。たとえば、文字列マッチはノードの一部分だけを位置づける場合があるし、span ロケーションタームを含んでいる XPointer (スパニング XPointer と呼ばれる)は、要素全体を構成しないサブリソースを参照することができる。
リソースへのトラバーサルの実装はこの仕様書によって制約されないことに注意すること。特に、スパンによって指し示されているリソースを扱うことは、多分高度にアプリケーション依存である。ディスプレイ指向アプリケーションプログラムでは、そうしたトラバーサルは単に指し示されたキャラクタをハイライト化するだけということになろう。しかし、構造指向ビューアは、完全なノードやサブツリーでないサブリソースには興味がないかもしれない。スパンは部分的要素を位置づける場合があるため、要素のセットやリストとして扱えないことに注意すること。
ロケーションタームは、絶対的ターム、相対的ターム、スパンターム、属性ターム、文字列データタームに分類される。絶対的タームは、他のどのサブツリーロケーションへの参照もなしにXML文書内の1つ以上の要素またはロケーションを選択する。相対的タームや文字列データタームは、ロケーションソースと呼ばれる他のロケーションのタームの中でロケーションを指定する。先行するロケーションタームがないならば、ロケーションソースは完全なリソースである。そうでなければ、先行するタームによって指定されるロケーションである(これはその前のロケーションタームとの相対指定である場合もある)。
このセクションにおいて開設されるキーワードは、ロケーションソースの存在に依存しない。これはロケーションタームを設立するために使うことができ、また自己包含的 XPointer としても機能することもできる。
| 絶対的ロケーションターム | ||||||||||||
|
root や origin の後の空括弧は、他のキーワードとの一貫性を図り、また単なる "root" や "origin" という文字列を含む XPointer の曖昧な解釈を避けるためのものである。
XPointer が root() で始まるならば、ロケーションソースは包含リソースのルート要素である。XPointer が先頭の絶対的ロケーションタームを省略すれば(すなわち OtherTerms だけで構成されていれば)、先頭に root() 絶対的ロケーションタームをもつものとみなされる。
origin キーワードは、XPointer がアプリケーションソフトウェアによって、XLink 仕様書で定義されているようにトラバーサルのリクエストに対する応答の中に生成される場合にのみ、後続のロケーションタームのための意味のあるロケーションソースを生み出す。XPointer が origin() で始まるならば、ロケーションソースは、デフォルトのルート要素ではなく、ユーザがトラバーサルを開始した元のサブリソースである。これは XPointer が「次の章」といったような抽象的なな項目を選択できるようにする。
URIも提供され、それがトラバーサルが始められた元のリソースと異なる包含リソースを識別するロケータの中で origin() を使うことはエラーである。
XPointer が id(NAME) で始まるならば、ロケーションソースは、宣言された ID 型をもつ属性と、与えられた Name にマッチする値とを有する包含リソースの中の要素である。
たとえば、id(a27) というロケーションタームは、a27 という値の ID 型として宣言された属性を有する包含リソースの、必然的に一意的な要素を選ぶ。
XML文書が、値が一意的なIDとして働くことを意図されているすべての属性を宣言していなければ、アプリケーションは、ID属性を同じ文字列値を有する他の属性と信頼して区別することができないことに注意すること。XPointer を処理するアプリケーションソフトウェアは、最初に、値がその Name 引数にマッチする宣言済みのIDをもつ要素を位置づけようと試みなければならない。もしそうできないならば、ユーザの選択で、アプリケーションソフトウェアは、求められている値を有する属性をもつ任意の要素を位置づけてもよい。
XPointer が html(NAMEVALUE) で始まるならば、ロケーションソースは、その型が A であり、NAMEVALUE に補われたのと同じ値の NAME で呼ばれる属性を有する最初の要素である。これは、まさに、HTML文書の文脈における "#" フラグメント識別子により果たされる機能である。
このセクションで解説されるキーワードはロケーションソースの存在に依存する。明示的に与えられていなければ、ロケーションソースは包含リソースのルート要素である。これらのロケーションタームは、要素樹を通って上下左右にナビゲートするための機能を提供する。これらのロケーションタームはすべて同じ引数リストを受け付ける。
| 相対的ロケーションターム | ||||||||||||||||||||||||||||||||
|
これらのキーワードのそれぞれが、そこから結果のロケーションソースが選ばれることとなる元の要素またはその他のノード型の列を識別する。キーワードに渡される引数は、その列からどのノードが実際に選ばれるかを決定する。ここにまとめられた各キーワードは、以下のセクションにおいて詳細に解説される。
child
descendant
ancestor
preceding
following
psibling
fsibling
キーワードが省略されれば、それは直前のキーワードと等しいものとして扱われる。XPointer (埋め込まれたものを含む)の最初のロケーションタームからはキーワードが省略されてはならない。たとえば、以下の2つの XPointer は等価である。
child(2,SECTION).(1,SUBSECTION)
|
child(2,SECTION).child(1,SUBSECTION)
|
すべての相対的ロケーションタームは、同じセットの潜在的引数を使って動作する。
| 相対的ロケーションターム引数 | ||||||||||||
|
要素やその他のノード型は、出現数によって選択できる。
| インスタンス | ||||||||
|
正のインスタンス数n については、n番目の候補ロケーションが識別される。負のインスタンス数については、候補ロケーションは(各キーワードに特有の方法で)最後から最初に向かって数えられる。もし all というインスタンス値が与えられていれば、すべての候補ロケーションが選択される。範囲外の数は XPointer を失敗させる。
XMLサブリソースは、数だけでなく特定のノード型によっても選択できる。
| ノード型 | ||||||||||||||||||||||||||||
|
ノード型は、以下の値のうちの一つによって指定してよい。
Name
child(3,DIV1).child(4,DIV2).child(29,P)
|
以下の XPointer は文書内の最後の EXAMPLE 要素を選択する。
descendant(-1,EXAMPLE)
|
#element
NodeType が指定されなければ、#element がデフォルトである。以下の例は5番目の子要素を識別する。
child(5)
|
#pi
string である。
#comment
string である。
#text
string である。
#cdata
string である。
#all
#all は実効的には #element と等価である。
ノード型のうちで、要素は他の型を包含できるが、その他の型は文字列以外のものを包含することができない。そこで、たとえば ancestor ロケーションタームは要素ノード型だけを位置づけ、descendant ロケーションタームは(他のノード型ではない)要素を通って、求める要素または非要素ノード型に至るまで下方にナビゲートする。
可能であるときには、指名された要素型による選択が強く推奨される。これ以上の情報は "3.8 リンクの永続性" を見ること。
以下の例を考えてみよ。
<!DOCTYPE SPEECH [
|
以下の XPointer は、このリソース内部のさまざまなサブリソースを選択する。
id(a27).child(2,DIRECTION)
DIRECTION" 要素を選択する(内容は "To Ros." である)。
id(a27).child(2,#element)
crossing downstage" である)を選択する。
id(a27).child(2,#text)
Fare you well, my load." という2つ目のテキスト領域を選択する。(SPEAKER 要素と DIRECTION 要素との間の改行が最初のテキスト領域である。)
候補要素は、その属性名および値に基づいて選択できる。非要素ノード型は属性をもたず、そのため属性名や値の指定を含むセレクタを決して満足できないことに注意すること。
| 属性 | ||||||||||||||||||||||||||||||||
|
引数 Attr および Val は、候補要素の中からの選択の際に使うための属性名および値を与えるために使われる。
引用符の内部に指定されていれば属性値引数は大文字小文字を区別されるが、そうでなければ区別されない。
それがどの属性名の値であるかにかかわらず、属性値が制約を構成する(さほどあるわけではない)場合には、ロケーションタームの中で属性名を "*" と指定してもよい。
たとえば、以下のロケーションタームは、TARGET という属性が値を有するロケーションソースの最初の子を選択する。
|
以下の XPointer は、N 属性を使って要素を選択する。
|
ロケーションソースの最初では、2 という値をもつ N 属性のある最初の子(要素型は何でもよい)が選択される。その後、同じ属性に 1 という値をもつその要素の最初の子要素が選択される。非要素ノード型は、N 属性をもつことができないから選択されえない。
以下の例は、RESP 属性が指定されないままである FS 要素であるロケーションソースの最初の子を選択する。
child(1,FS,RESP,#IMPLIED)
|
html というキーワードは、属性ベースのアドレッシングのきわめて特定的なインスタンスと同義であり、以下の2つの XPointer は等価であることに注意すること。
html(Sec3.2)
|
root().descendant(1,A,NAME,"Sec3.2")
|
descendant キーワードは、直接または間接にネストされた、ロケーションソース内部のどこかにある指定された型のノードを選択する。
descendant ロケーションタームは、サブ要素樹を下に向かって見てゆき、要求されたノード型で終了する。中間のPIや注釈、テキスト領域のネストされたレベルを通っては下っていかない。合致するノード型の検索は、XMLデータストリームの中で要素の開始タグが発生するのと同じ順序で発生する。ロケーションソースの最初の子がまずテストされ、その後(それが要素テレある場合には)その要素の最初の子が、などとテストされてゆく。形式的な用語では、これは深さ優先のトラバーサルである。
たとえば、以下の XPointer は、ID 属性の値が A23 である要素の内部にある、値が DE である LANG 属性をもった2つ目の TERM を選択する。
id(a23).descendant(2,TERM,LANG,DE)
|
インスタンス数が正であれば、検索は深さ優先で、左から右へと行われる。インスタンス数が負であれば、検索は深さ優先であるが、右から左に行われ、最も右で最も深くにある合致する要素が -1 という番号をつけられるなどする。要素が試験される順序は、遭遇した最初のタグの発生順序に一致する。そこで、以下の例では、文書の最後の NOTE 要素、すなわち最も右の終了タグをもつものを選択する。
|
もし最後の NOTE が他の NOTE の内部にあったならば、サブ要素ではなく包含要素が選ばれる。そちらの方が文書の中で後ろの点まで広がっているからである。
ancestor キーワードは、ロケーションソースの直接の祖先の間から要素を選択する。正のインスタンス数については、ロケーションソースの親から包含リソースのルートへと上向きに数えられる。負のインスタンス数については、ルートから直接の親要素へと下向きに数えられる。ancestor はロケーションソース自身を選択できないことに注意すること。
たとえば、以下の XPointer は、まず、ロケーションソースを適切に包含し、かつ属性 N に 1 という値をもつ最も内側の要素(直近の祖先)を選び、そこから、その祖先を適切に包含する最も小さい DIV 要素を選ぶ。
ancestor(1,#element,N,1).(1,DIV)
|
ancestor のノード型パラメータは、もし補われていれば、#element か特定の要素型名かのどちらかでなければならない。もし現在のロケーションソースが属性であれば、その属性が発生する要素が最初の祖先とみなされる。
preceding キーワードは、ロケーションソースに先行するものの中から指定された型のノードを選択する。選択されてよいノードのセットは、文書全体の中で、ロケーションソースの前で発生または開始するものすべてのセットである。正のインスタンス数については、ロケーションソースから左へと数えられる。負のインスタンス数については、包含リソースのルート要素から右へと数えられる。開始、終了を問わず遭遇した最初の区切り子またはタグが、そのノードの発生と数えられる。
たとえば、以下の XPointer は、a23 という ID をもった要素の前で発生または開始する5番目の要素を指し示す。
|
ロケーションソースの祖先はすべてそのロケーションソースを包含し、潜在的には他の内容も包含するから、祖先はその子孫に「先行」しかつ「後行」する。それゆえ、以下の例はルート要素を選択する(おそらく他のノードの中から)
|
following キーワードは、ロケーションソースに後行するものの中から指定された型のノードを選択する。選択されてよいノードのセットは、文書全体の中で、そのロケーションソースの後で発生または終了するものすべてのセットである。正のインスタンス数については、ロケーションソースから右へと数えられる。負のインスタンス数については、包含リソースのルート要素の終了タグから左へと数えられる。開始、終了を問わず最初に遭遇した区切り子またはタグが、そのノードの発生として数えられる。
たとえば、以下の XPointer は、a23 という ID をもつ要素の後に発生する2番目のPIを指し示す。
id(a23).following(2,#pi)
|
ロケーションソースの祖先はすべてそのロケーションソースを包含し、潜在的に他の内容も包含するから、祖先はその子孫に「先行」しかつ「後行」する。それゆえ、以下の例はルート要素を選択する(おそらく他のノードの中から)。
|
psibling キーワードは、同じ親要素の内部でそのロケーションソースに先行するものの中から指定された型のノードを選択する。同じ親要素によって直接に包含されているノードは、兄弟である。ロケーションソースに先行する兄弟はその年長の兄弟であり、後行する兄弟は年下の兄弟である。
正のインスタンス数については、psibling は、最も近い年上の兄弟から最も年上の兄弟へと左向きに数えられる。負のインスタンス数については、最も年上の兄弟から右向きに数えられる。ロケーションソースが、少なくともインスタンス数の絶対値と同じだけの年上の兄弟をもっていなければ、ロケーションタームは失敗である。
たとえば、この XPointer は、同じ親を共有している限りにおいて、a23 という ID をもつ要素の直前にある要素を指し示す。
id(a23).psibling(1,#element)
|
もしロケーションソースが少なくとも1つの年上の兄弟をもっていれば、以下のロケーションタームはまさに最も年上はまさに最も年上の兄弟を指し示す。
psibling(-1,#element)
|
このロケーションタームは、以下の XPointer と同義である。
1,#element).child(1,#element)
|
all という値を使って、ある要素の年上の兄弟の範囲全体を選択してもよい。たとえば、以下の XPointer は、a32 という ID をもつ要素に先行し、同じ親に包含されている要素のセットを指し示す。
id(a23).psibling(all,#element)
|
fsibling キーワードは、同じ親要素の内部でそのロケーションソースに後行するものの中から指定された型のノードを選択する。同じ親要素に直接に包含されているノードは、兄弟である。ロケーションソースに先行する兄弟はその年上の兄弟であり、後行するものは年下の兄弟である。
正のインスタンス数については、fsibling は最も近い年下の兄弟から最も年下の兄弟へと右向きに数えられる。負のインスタンス数については、最も年下の兄弟から左向きに数えられる。ロケーションソースが少なくともインスタンス数の絶対値と同じだけの年下の兄弟をもっていなければ、ロケーションタームは失敗である。
たとえば、この XPointer は、同じ親を共有する限りにおいて、a23 という ID をもつ要素の直後にある要素を指し示す。
id(a23).fsibling(1,#element)
|
ロケーションソースが少なくとも1つの年下の兄弟をもっていれば、以下のロケーションタームはまさに最も年下の兄弟を指し示す。
fsibling(-1,#element)
|
このロケーションタームは、以下の XPointer と同義である。
ancestor(1,#element).child(-1,#element)
|
all という値を使って、ある要素の年下の兄弟の範囲全体を選択してもよい。たとえば、以下の XPointer は、a23 という ID をもつ要素が続き、同じ親に包含される要素のセットを指し示す。
id(a23).fsibling(all,#element)
|
span キーワードは、その最初の引数によって選択されるデータの開始点で始まって2つ目の引数によって選択されるデータの終了点まで続くサブリソースを位置づける。両方の引数はともに、スパニングロケーションターム自身のロケーションソースとの相対関係で解釈される。2つ目の引数は最初の引数をロケーションソースとして使うのではない。
| スパニングターム | ||||
|
以下は、a23 というIDをもつ要素の1つ目から3つ目までの子を選択するスパニング XPointer の例である。
id(a23).span(child(1),child(3))
|
attr キーワードは、セレクタとして属性名のみをとり、その属性値を返す。
| 属性マッチターム | ||||
|
string キーワードは、ロケーションソース内の文字列の間で1つ以上の文字列またはポジションを選択する。
| 文字列マッチターム | ||||||||||||
|
InstanceOrAll
all という値については、その文字列のすべての発生が、指し示されるリソースの形成に際して候補として使われる。
SkipLit
SkipLit 文字列は、ロケーションソース内の各キャラクタの直前のポジションを識別する。たとえば、x37 というIDをもつ要素が "Thomas" というキャラクタ文字列を包含していると仮定すると、以下の XPointer は3キャラクタ目 ("o") の前のポジションを識別する。
id(x37).string(3,"")
|
Position
end というポジジョン値は、マッチの最後のキャラクタの直後のポジションを選択する。
Length
ロケーションソースがPIまたは注釈であるときは、string は、そのノードの内容上で動作する。しかしながら、PIや注釈の内容は、それ以外の場合にはテキスト内容とみなされない。
たとえば、以下のXPointerは、"Thomas Pynchon" という文字列の3度目の出現の中の "P" という文字 (文字列の最初から8番目)の直前の位置を選択する。
root().string(3,"Thomas Pynchon",8)
|
以下のXPointerは、5番目の感嘆符と、その直後に続く文字とを選択する。
id(a27).string(5,'!',1,1)
|
文字列照合の目的では、「要素のテキスト」とは、カレントのロケーションソースの中にある要素および子孫要素にあるすべてのキャラクタデータを意味する。マークアップキャラクタは無視される。パターン照合は、厳密かつキャラクタごとである。いかなる種類の大文字小文字やスペース、結合キャラクタの標準化も実行されるべきではない。そのため、以下の例だと "Thomas Pynchon" に合致するものはないことになる。合致しそうな最初のものは大文字小文字が違っており、二番目のものは単語を区切るスペースの省略の点で異なる。
<example>thomas pynchon,
|
ほとんどのロケーションタームは、その結果として単一の要素を選択する。たとえば、以下のXPointerは、つぎの1個の要素を選択する。
id(foo).child(1,SEC)
|
そうしたケースは平凡に要素樹内のノードに対応しており、そのようにして一定の実装の単純化を可能にしている。しかしながら、この限界がすべてのロケーションタームにあるわけではない。
string ロケーションタームは、一般に、1個のノードの一部分だけを返す。しかし、合致した内容の中にマークアップがある場合には、複数の要素の一部分が結果に含まれてもかまわない。
string ロケーションタームは、all インスタンス値つきで使われるときは、文字列データのうちの、概して不連続である部分のリストを返す。
all と指定してもよい。これは、すべての候補ノードが結果に含まれることを意味している。そこで、結果は、サブツリーではなく、たぶん非隣接であるノードのベクトルとなる。
これらのケースはそれぞれ、下記で詳細に解説される。
string ロケーションタームは、数個の要素のうちの部分を返してもよい。たとえば、下記の "c" で始まる12文字を指定する string だと、EMPH 要素のテキスト内容全体に加えて、P の内部で EMPH に続いているテキスト部分を返すことになる。
<P>Hello, <EMPH>cruel</EMPH> world.</P>
|
下記に示されたXPointerは、要素の有順序リストを指定する。要素は連続的であってもなくてもよい。前者のケースでは恐らく連続的であり、その次のケースでは恐らく連続的ではない。
id(sec2.1).child(1,list).child(all,list)
|
id(div1).descendant(all,h3)
|
このような要素の不連続的な連なりは、一定の処理シナリオにおけるクエリーの結果を表す、基礎にある同一の抽象型を用いて有益に実装してもかまわない。
以下のスパニングXPointerは、ある節の最後の P 要素から、別の節の最初の P までにあるすべてのものを選択する。
span(id(sec2.1).child(-1,P),id(sec2.2).child(1,P))
|
スパンロケータはXML文書のサブツリーではなく、また、単なる内容データ文字列でもない。そこで、スパニング選択の結果は、一般的に、整形式のXML文書として表記したり、ノードや要素樹からのノードのリストとして表記することができない。これは、一般的に要素のなかには、スパンの中にも外にもなく、実は一部分だけが中にあるものがあるからである。たとえば、上記の例には、sec2.1 というIDをもつ要素の末尾が含まれているが、先頭は含まれていない。このため、スパンをサポートする実装は、スパンを単純に単一のノードや整形式のXMl文書として表現することができないのである。その代わりに、実装は、それらをロケーションの対として、またはその他それ以上に一般なものを表記できる手段により、表現しなければならない。
ノードやノードのベクトルにとって意味をなす処理用意味論のなかには、スパンについて意味をなさないものがあるかもしれない。ブラウザは、あるスパンのキャラクタ内容だけを強調表示することならば簡単にできるが、アウトライン化表示や樹形式表示に適用すべき適切な意味論はないことがある。
ターゲットリソースへのリンクが決して切れないことを保証することは不可能である。リソースを、どれだけ頑強なリンクであっても切れるように変化させることは可能である。最悪の場合、ターゲットリソースの制作者は、ターゲットリソースを書き換えて全く別の主題を論じれば、リンクがIDを用いてリソースを参照している場合であっても、すべてのリソースを無関係なものにすることができるのである。しかしながら、典型的な条件の下では、いくつかのXPointerは合理的な程度に頑強なものとなりうる。
もっとも頑強なロケータは、たいていはIDのみを用いたものであり、これは利用可能なときには好まれるロケータである。しかしながら、すべての要素にIDがあるとは限らず、リンクの作成者には、ターゲットリソースにIDを追加できるほどの制御力がないことが多い。そうした場合には、IDを実際にもっている直近の包含側要素を指し示し、そこから child ロケーションタームを用いて要素樹を下っていくロケータが、好まれるロケータである。この形式は、二つの理由で、相対的に頑強である。
さらに、child といったような相対ロケーションタームが使われているところでは、指名された要素型による選択 (相対ロケーションタームの2番目の引数に Name がある場合) が、二つの理由で、名前の指定のない選択よりも好まれる。
文字列は、それがこの仕様書によって課されている文法的な要求事項を厳守している場合に、XPointerに適合している。これは、URIとの関連において、文字列が、与えられたある瞬間において存在するリソースを実際に指し示していることを要求するものではないので注意すること。
アプリケーションソフトウェアは、それが、XPointerに適合している文字列を、この仕様書によって指定された必須の意味論のすべてに従って解釈し、また、それがサポートすることを選んだオプショナルな意味論のどれについても、それらを指定されたとおりにサポートする場合に、Xpointerに適合する。アプリケーションソフトウェアは、XPointer文字列がどの場所で認識されるかについて、独自の要求事項を定義しても自由である。たとえば、あるXMLアプリケーションプログラムは、XLink要素のロケータ属性の中に出現するときにのみXpointerを認識することとするかもしれないのである。
あるリンクのリソースを属性の値に基づいて指定することは可能である。照合の際に大文字小文字の区別に関して何が正しい挙動であるかを決定することは困難なことである。理想的には、属性値の宣言型が考慮に入れられるべきであるが、それは文書のDTDを取り出して読むことを前提としており、それは多くのXMLアプリケーションでは適切ではないことがある。現行のシステムは、説明は簡単であるけれども、長い目で見れば適していないことが判明するかもしれない。
形式的には、XPointer 機構の操作は、DOMや HyTime 規格 ([ISO/IEC 10744]) に定義されているような抽象的データ構造上の操作として指定される場合がある。そうしたロケータの中のノードごとにSDQLでの対応する表現があり、大半は HyTime ロケーションモジュールにおける直接の等価物もある。
XPointer 言語は、the Text Encoding Initiative guidelines [TEI] に定義された、多様なSGMLベースのハイパーメディアアプリケーションによって利用されている公に利用可能な技術である「拡張ポインタ」を基礎としている。この付録は、XPointer が拡張ポインタとどう違うのかを解説する。主要な相違点は、URI内部に簡単にロケータをパッケージする能力を有し、いくつかのより進んだ機能を省いていることである。
," という文字列により区切られた2つの XPointer を包含してもよい。これは、TEI の FROM, TO 属性の能力を、スパンのための単一のロケータ文法の中に組み合わせる。
origin や root は、それらをありうるIDから区別するため、空引数リストをとる。
PATTERN タームは、リテラルな string マッチングタームで置き換えられる。
SPACE, HyQ, FOREIGN キーワードは省かれている。
これらの変更点はTEIとコミュニケートされており、TEIは以後の見直しにおいてける組み込みのためにそれらを考慮している。
提案中のTEIキーワード ATTR は XPointer に組み込まれている。
著作権 © 1998 W3C(マサチューセッツ工科大学、フランス国立情報処理自動化研究所、慶應義塾大学).すべての権利が留保されている。W3Cの免責(liability), 商標(trademark), 文書利用(document use), ソフトウェア使用許諾(software licensing) 規則が適用される。