WD-xlink-19980303
WD-xlink-19980303
これはW3C会員およびその他の利害関係者による検討のためのW3Cワーキングドラフトである。この文書はドラフト文書であり、何時にても他の文書によって更新され、置換され、あるいは廃止される場合がある。W3Cワーキングドラフトを参照資料として用いたり「進行中の作業」以外のものとして引用することは不適切である。現行のW3Cワーキングドラフトの一覧は http://www.w3.org/TR で見ることができる。
この作業はW3C XMLアクティビティの一部である(現状については http://www.w3.org/MarkUp/XML/Activity を見ること)。XLink とともに使われることが予定されている XPointer 言語についての情報は http://www.w3.org/TR/WD-xptr[拙訳あり]を見ること。
XLink に情報を与えた設計理念に関する追加的な背景は http://www.w3.org/TR/NOTE-xlink-principles を見ること。
この文書は、オブジェクト間のリンクを記述するためにXMLリソースに挿入してよい構造を仕様化する。これはXML文法を使って、今日のHTMLの単純な一方向的ハイパーリンクや、より洗練された多端の型設定されたリンクを記述できる構造を作成する。
この文書は、オブジェクト間のリンクを記述するためにXMLリソースに挿入してよい構造を仕様化する。リンクとは、ここで使われている用語としては、2つまたはそれ以上のデータオブジェクトやデータオブジェクトの一部分の間の明示的な関係である。この仕様書は、リンクの存在を主張したりリンクの特性を記述するために使われる文法に関するものである。たとえばある単語と次の単語との関係や、テキスト内のある単語とそのオンライン辞書の見出し語との関係といった黙示的(主張されない)関係は、明らかに重要ではあるが、その射程外にある。
リンクは、XML文書に含まれている要素によって主張される。最も単純なケースは、HTMLの A にとてもよく似ており、これらの特性を有している。
A 要素に似て)その端の一方で表わされる。
A リンクのトラバーサルは、通常は現在のビューを置き換え、場合によっては新しいウィンドウを開くユーザオプションがついている。
この特性のセットは既に強力であって、明らかにそれ自体で高度に有益かつ効果的であることが証明されているが、これらの設定のそれぞれはハイパーテキストの機能性の範囲を限定してもいる。ここで定義されるリンクモデルは、これらの明確な特性のそれぞれを乗り越えるリンクを作成する手段を提供し、かようにたいてい献身的なハイパーメディアシステムにおいては以前に利用可能であった機能を提供している。
以下は、XLink を支配する設計理念の要約である。
特に影響力が大きかったのは3つの規格である。
その他のリンクシステムも多数、特に Dexter, FRESS, MicroCosm, InterMedia といったものも、この設計に情報を与えている。
以下の基本的用語がこの文書の中で適用される。
A や HyTime の clink、TEI の XREF はすべて行中リンクの例である。
ロケータの形式的文法は、XML仕様書の中に記述されている単純なEBNF (Extended Backus-Naur Form) ロケーションを使って与えられる。
リソースのロケータは、概して、URI (Uniform Resource Identifier) を用いて提供される。XPointer はURI構造と結びついて、フラグメント識別子やクエリーとして使い、より正確なサブリソースを指定することができる。
これらのRFCが規定する通り、URIは、後に続いたクエリー(先頭に "?" をつけてマークされる)を取り込んでもよく、"#" と フラグメント識別子 とが後ろに続いていてもよい。これには示されたリソースを提供するホストによって解釈されるクエリーがつくが、フラグメント識別子の解釈は示されたリソースのデータ型に依存する。
XML文書や文書の一部分をロケートするために、ロケータ値はURIかフラグメント識別子かのどちらかまたはその両方を含んでもよい。XMLの内部を指し示すフラグメント識別子はすべて XPointer でなければならない。
特殊な文法を使って、ロケータのリソースへのアクセス時に特定の処理モデルの利用を要求してもよい。これはネットワークオペレーションの現実を反映するべく設計されたものであるが、そこではローカルプロセッサとリモートプロセッサとの間の仕事の配布を細かく制御することが望ましい場合もあるし望ましくない場合もある。
| ロケータ | ||||||||||||||||||||
|
この議論において、指し示されたリソースという用語は、ロケータ全体がロケートするべく働くリソースを指す。以下の規則が適用される。
コネクタの直後に名前が続いている場合には、名前は XPointer "id(Name)" の短縮表記である。すなわち、サブリソースは、値が名前に合致するXML ID 属性を有する包含リソース内の要素である。この短縮表記は、頑強な id アドレスモデルの利用を奨励するためのものである。
#" である場合には、これは、包含リソースが、それを提供するホストから全体として取り出されるべきであるが、サブリソースを抜き出すための XPointer 処理がクライアント上、いわばリンク要素が認識され処理される同じシステム上で実行されるべきだとの意図を示す。
|" であれば、指し示されたリソースへのアクセスのためにどの処理モデルが使われるべきかについて何の意図も示されない。
定義により、URIは任意的なクエリーコンポーネントを含むものであることに注意すること。
URIが(サーバによって解釈されるべき)クエリーを含んでいる場合には、情報提供者やサーバソフトウェアの作成者は、以下のクエリーを使うよう求められる。
| クエリー | ||||
|
リンクの存在はリンク要素によって主張される。リンク要素は、適切な表示や挙動を提供するために、アプリケーションソフトウェアによって安心して認識されなければならない。リンク認識を実現できる方法にはいくつかのものがある。たとえば、要素型名を予約する、属性を予約する、認識の問題を完全にスタイルシートやアプリケーションソフトウェアに委ねてしまう、といったものである。属性を予約することは、ユーザ自身のマークアップ言語設計を与えることと、「リンクである」という重要な構造上の事実を文書内部で明示しておくこととのバランスを提供する。それゆえ、XLink リンク関連要素は、xml:link という名前の指し示される属性の仕様に基づいて認識される。取りうる値は locator, group, document と同様、simple と extended(これらはリンク要素を識別する)である。その開始タグの中でそうした属性が現れるような要素は、この仕様書によって書かれている示された XLink 型の要素として扱われるべきである。たとえば、
<A xml:link="simple" href="http://www.w3.org/">The W3C</A>
|
注意:関連規格において開発されるべき定義に従い、"7. 属性の再割り付け" で記述されている方法が、予約されている属性の名前の付け替えのために使われてもよい。
xml:link や xml:attributes 属性をリンク要素に結びつけるのに使ってよいメカニズムには2つのものがある。最も単純なのは、開始タグの中に明示的に属性を与えることである。それよりも面倒でない方法は、デフォルト属性値を宣言するためのXMLの機能を使うことである。たとえば、以下の属性リスト宣言は、現在の文書の A 要素のインスタンスすべてが XLink 単純リンクであることを示すことになる。
<!ATTLIST A xml:link CDATA #FIXED "simple">
|
XLink は2タイプのリンク要素を定義する。
どちらの種類のリンクも、さまざまな型の情報を結びつけることができる。
以下の情報は、リンクやそのリソースに結びつけることができる。
この情報は、属性やリンク要素の形で供給される。以下の節では、パラメータ実体を使ってこれらの属性をグループ化する。
ロケータ文字列は参加リソースを識別する。リンクは、リモートリソースごとにロケータを供給しなければならない。
ロケータは、href という属性の形をとる。以下はこの属性の宣言例であり、locator.att パラメータ実体の中に包み込まれている。
<!ENTITY % locator.att
|
以下の意味論的情報がリンクへ提供できる。
リンクが行中リンクである場合には、その内容はリンクのローカルリソースとして扱われる(もっとも、リンク要素の内部にあるロケータサブ要素は、ローカルリソースの一部分とみなされない。端名リンク要素機構の一部分である)。リンクが行外リンクであれば、その内容はローカルリソースとして扱われない。リンクはそれぞれ行中リンクか行外リンクかのいずれかである。リンクが行中リンクであるという状態は、inline という属性で示される。true (デフォルト)または false という値をとることができる。
リンクは、作成者とユーザとにとっての重要性という点で、リンクが接続しているデータやその一部分の間の多様な観念上の関連性を表わす。あるリンクは批評であるかもしれないし、他のリンクは支援や背景を追加するものであるかもしれないが、他のリンクはデータオブジェクトについての人口統計学的な情報(その作成者の氏名やバージョン番号など)へや、索引や用語集、要約といったナビゲーションツールへののアクセスを提供する場合もある。リンクが情報の表現に関与している部分を示すために、リンク作成者は任意的にリンクの役割を識別する文字列をつけることができる。この役割は、role という属性で示される。("4.1.3 リモートリソースの意味論" で記述されている通り、リンクに参加しているリソースごとにそれ自身の役割を与えてもよいことに注意すること。)
以下は、これらの属性の宣言例であり、link-semantics.att パラメータ実体の中に包み込まれている。
<!ENTITY % link-semantics.att
|
単純リンクは異なる機能を有する role と呼ばれる属性をもつから、リンクの意味論について role 属性をとることができない。以下は、単純リンク要素で利用するための simple-link-semantics.att パラメータ実体宣言である。
<!ENTITY % simple-link-semantics.att
|
以下の意味論的情報がリンクのリモートリソースに提供できる。
("4.1.2 リンクの意味論" で記述されている通り、全体としてのリンクにそれ自身の役割が与えられてもよいことに注意すること。) リンク作成者は、任意的に、role という属性の中で役割情報を提供することができる。
リンク作成者は、任意的に title という属性の中でタイトル情報を提供することができる。XLink は、アプリケーションソフトウェアがタイトル情報について特定の使い方をすることを要求しない。
リンク作成者は、任意的に show や actuate という属性を使って、リンクのトラバーサル挙動に関する一般的な政策とコミュニケートすることができる。show 属性は new, replace, embed という値の中から1つをとることができる。actuate 属性は auto, user という値の中から1つをとることができる。リンク作成者は、任意的に behavior という属性を使って、トラバーサル挙動についての詳細な指示とコミュニケートすることができる。この属性の内容・書式・意味は制限されない(挙動関連の属性に関する情報については "6. リンクの挙動" を見ること)。
以下は、これらの属性の宣言例であり、remote-resource-semantics.att パラメータ実体の中に包み込まれている。
<!ENTITY % remote-resource-semantics.att
|
リンクが行中リンクである場合、以下の意味論情報がリンクのローカルリソースに提供できる。
("4.1.2 リンクの意味論" に記述されている通り、全体としてのリンクもそれ自身の役割を与えられてよいことに注意すること。) リンク作成者は、任意的に、content-role という属性の中に役割情報を提供することができる。
リンク作成者は、任意的に、content-title という属性の何タイトル情報を提供することができる。XLink は、アプリケーションソフトウェアがタイトル情報について特定の使い方をすることを要求しない。
以下はこれらの属性の宣言例であり、local-resource-semantics.att パラメータ実体の中に包み込まれている。
<!ENTITY % local-resource-semantics.att
|
単純リンクは、基本的なHTMLの A リンクの機能を近似する目的で使うことができるが、量は限られているものの追加的機能をサポートすることもできる。単純リンクはロケータを1つしかもたず、そのため、便宜上、リンク要素とロケータとの機能を単一の要素の中へ組み合わせる。この組み合わせの結果として、単純リンク要素は、ロケータ属性とすべてのリンク・リソース意味論属性との双方を提供する。
以下は、単純リンクの宣言例であり、それがもってよい取りうる XLink 関連の属性のすべてを("4.1 リンクと結びつけられる情報" で与えられたパラメータ実体を使って)示している。単純リンクの xml:link 属性値は simple でなければならない。
<!ELEMENT simple ANY>
|
単純リンク要素の内容には何の制約もない。上記の宣言例では、任意の内容モデルや宣言内容が受付可能であることを示す ANY という内容モデルが与えられている。妥当な文書では、XLink にとって重要な要素ごとが、それを支配するDTDにおいて表わされた制約にも適合していなければならない。
以下は単純リンクの例である。
<mylink xml:link="simple" title="Citation"
|
この例の mylink 要素は、以下の要素および属性リスト宣言を有してもよい。
<!ELEMENT mylink (#PCDATA)>
|
そんなリンクは一般的ではないけれども、行外単純リンクをもつことは有意義であることに注意すること。こうしたリンクは「一方端型」と呼ばれ、概して、個別の意味論的プロパティをロケーションに結びつけるために使われる。プロパティは、リンク上の属性やリンクの要素型名その他の方法で表わされる場合があり、リンクの完全に独り立ちしたリソースとはみなされない。拡張リンクの方がはるかに広範囲の利用法があるので、ほとんどの行外リンクは拡張リンクである。
拡張リンクは、ローカルリソースひとつ(任意的)やリモートリソースひとつだけではなく任意の数のリソースと接続できる点や、拡張リンクの方が単純リンクよりも行外リンクであることが多いという点で、単純リンクと異なっている。
拡張リンクの追加的な能力はつぎのようなことのために要求される。
アプリケーションソフトウェアは、リンクのすべての参加リソースの間のトラバーサルを提供し(この仕様書の射程外の意味論的制約には服する)、それが表示されるときに、(正確にはそれを示す点にマークアップがなくとも)与えられたリソースまたはサブリソースが1つまたはそれ以上のリンクに参加しているという事実を知らせてもよい。
拡張リンクのリンク要素は、ロケータとして働く一連の子要素を含んでいる。(単純リンクが2つを組み合わせるのに対して)拡張リンクは2つ以上のリモートリソースを持つことができるので、各リソースをロケートするために使われる機構からリンク自身を切り離す。
リンク要素自身は、それらの属性を、全体としてのリンクや、あればそのローカルリソースとの関係を維持する。以下は拡張リンクの宣言例である("4.1 リンクに結びつけられる情報" で与えられたパラメータ実体を使っている)。拡張リンクの xml:link 属性値は extended でなければならない。
<!ELEMENT extended ANY>
|
リモートリソースと関連する属性は、対応する被包含ロケータ要素上で表わされる。リモートリソースは各自、全体としてのリンクと関連してそれ自身の意味論を持つことができる。以下はロケータ要素の宣言例であり、それがもってよいすべての取りうる XLink 関連属性を示している("4.1 リンクに結びつけられる情報" で与えられたパラメータ実体を使っている)。ロケータ要素の xml:link 属性値は locator でなければならない。
<!ELEMENT locator ANY>
|
以下は行外拡張リンクの例である。
<commentary xml:link="extended" inline="false">
|
便宜上、ロケータ要素の意味論的属性のデフォルトは、それらを含んでいるリンク要素上で指定できる。そうした属性がロケータ要素から省略された場合には、包含リンク要素上に与えられる値が使われることになる。以下は拡張リンクの宣言例であり("4.1 リンクに結びつけられる情報" で与えられたパラメータ実体を使っている)、リモートリソースの意味論的属性を含めて、それがもってもよいすべての取りうる XLink 関連属性を示している。
<!ELEMENT extended ANY>
|
リンク要素の内容は、概して、ロケータ要素だけからなる。もっとも、ANY としての宣言は、他のどの内容も追加してよいことを示している(妥当な文書では、XLink にとって重要な要素はすべて、それを支配するDTDで表わされた制約に適合していなければならない)。リンク要素の直接の子であるロケータ要素だけが、そのリンク要素によってリンクされるリソースを定義する。
行外拡張リンクについて鍵となる問題は、リンクアプリケーションソフトウェアがそれをどのように処理・発見できるかということである。その参加リソースが出現する文書から完全に分離した文書に保存されているときには特に問題となる。XLink は関連するリンク包含文書を識別する機構を提供しているが、これは "5. 拡張リンクグループ" で論じられる。
ハイパーリンクつき文書は、一つずつでよりもグループで処理されるのが最良であることがよくある。トラバーサルを始められることを宣伝するためにリソースを強調することが好ましく、同時に行外リンクが複数使われる場合には、これらのリンクを探してリソースがどこにあるかを発見するために他の文書を読むことが、絶対的な要求であることもある。
これらの場合には、特別な種類の拡張リンクである拡張リンクグループ要素を使って、相互リンクされたグループをともに構成する他の文書へのリンクの一覧を保存してもよい。そうした文書はそれぞれ、特別な種類のロケータ要素である拡張リンク文書要素を用いて識別される。
以下は拡張リンクグループや拡張リンク文書要素の宣言例であり、それらが取りうる XLink 関連の属性をすべて示している("4.1 リンクに結びつけられる情報" で与えられたパラメータ実体を使っている)。拡張リンク要素の xml:link 属性値は group でなければならず、拡張リンク文書要素の xml:link 属性値は document でなければならない。
<!ELEMENT group (document*)>
|
作成者は steps 属性を使って、それ自身の拡張リンクグループを含んでいることが分かっている他の文書をロケートするために拡張リンクグループがアプリケーションソフトウェアを指している状態を処理する助けとしてもよい。無限退行の潜在的可能性があるが、にもかかわらず、いくつかのレベルの拡張リンクグループを処理することが便利であるような状態もある。steps 属性は、拡張リンクグループの処理が何ステップまで着手されるべきかに関し、作成者からリンク処理器へのヒントとして働く数値をもつべきである。これは規範的な効果は有しない。
たとえば、ある文書のグループがすべての行外リンクを含んでいる単一の「ハブ」文書で組織されているとすると、非ハブ文書それぞれが、ハブ文書への参照を1つだけ含んだ拡張リンクグループを含むことにも意味があるかもしれない。この場合には steps について最良の値は 2 ということになろう。
リンクのフォーマッティングとリンクの挙動とは、分かちがたく関連している。一般に、フォーマッティングには、リンクが存在していることを示すためのフォントや色、アイコンの選択やその他の道具といったような、ユーザアクション前のリンクの外観や扱いも含まれる。挙動は、リンクがトラバースされたときに何が起こるかに焦点をあてる。これには、ウィンドウやページを開いたり閉じたりスクロールさせることや、さまざまなリソースからのデータをさまざまな方法で表示することや、ユーザや文脈情報を認証したりログにとったりすることや、さまざまなプログラムを実行することが含まれる。
XLink は、リンクフォーマッティングを制御するための機構を提供しない。それはスタイルシートの領域の中に入ると考えられるからである。リンクの挙動も、理念的には、リンク型やリソースの役割、ユーザ環境その他の要因に基づく規則によって決定されるべきものである。しかしながら、XLink は、二・三のきわめて一般的な挙動機構を提供する。これらは一般的にリンク型の主要な、あるいは一致した意味論を反映していると考えられるからである。
XLink が提供する機構は、リンク作成者が、トラバーサルのタイミングや効果に関する一定の意図を発信することを可能にする。そうした意図は、show と actuate というラベルのついた2つの軸に沿って表わすことができる。これらは機構よりも政策を表わすために使われる。どのリンク処理アプリケーションソフトウェアも、要求された政策を実装するために、ユーザ環境や処理モードに最適な独自の機構を開発することは自由である。
多くの場合で、既存のハイパーテキストソフトウェアが一般に提供する型のトラバーサル挙動の詳細に関してはるかにきめの細かい制御が望ましいであろう。そうしたリンク挙動の細かい制御は、この仕様書の射程外にある。もっとも、behavior 属性が、作成者が詳細な挙動指示を提供する標準的な場所として提供される。アプリケーションソフトウェアはここを調べる場合がある。
show 属性は、トラバース先のリソースが表示または処理されるべき文脈に関する政策を表わすために使われる。これがとってよい値は3つの値のうちの1つである。
embed
replace
new
actuate 属性は、リンクのトラバーサルが何時発生するべきかについての政策を表わすために使われる。これがとってよい値は2つの値のうちの一つである。
auto
user
show 属性と actuate 属性との組み合わせはそれぞれ意義がある。おそらく、もっともはっきりしないのが show="replace" と actuate="auto" との組み合わせだろう。これは、あるアンカーが表示されるときに他(他方)はユーザの干渉なしにそれを置き換えるべき、転送型のアプリケーションで使うことができるであろう。XLink は、リンクについては最も一般的な意味論しか提供しないから、転送前の遅延時間やビープ音といったような表現の詳細は、スタイル言語を使ってアプリケーションベースごとに指定できる。
XLink は、リンク要素に添付してリンクのさまざまな側面を記述できる数多くの要素を提供し、それぞれがデフォルト名をもっている。XML文書内の既存の要素をリンク要素として使うことが望まれる場合もあるかもしれないが、そうした要素は、この文書内で記述されているものと名前が衝突する属性を既にもっているかもしれない。衝突を避けるため、ユーザが選んだ属性名は、xml:attributes 属性を使ったデフォルト名に割り付けることができる。
この属性は、空白で区切られた名前を偶数個含まなければならず、これらは対として扱われる。それぞれの対では、一つ目の名前がデフォルトの XLink 名前 (role, href, title, show, inline, content-role, content-title, actuate, behavior, steps) の一つでなくてはならない。2つ目の名前は、文書内で認識されるときには、それが一つ目の名前に割り当てられた役割を演じているかのように扱われることになる。たとえば、以下の宣言のあるDTDを考えてみよう。
<!ELEMENT TEXT-BOOK ANY>
|
これを単純リンクとして使うことが望まれるのであれば、属性の組を再割り付けすることが必要となる。これは内部サブセット内で実現できる。
<!ATTLIST TEXT-BOOK
|
そうすると、この文書では、以下のものが単純リンクとして認識されることになるのである。
|
要素は以下の場合に XLink に適合する。
xml:link 属性をもち、この属性の値がこの仕様書で定められた属性値のうちの一つである。
xml:link 属性値によって課される文法的制約に従っている。
XLink リンク機構と非 XLink リンク機構とが一つの文書の中で並んで使われる場合があるため、適合性はXML文書全体ではなく個別の要素のレベルで検証されることに注意すること。
アプリケーションが XLink に適合するのは、アプリケーションがこの仕様書で定められたすべての必須の意味論に従って XLink 適合要素を解釈し、またアプリケーションがサポートすることとした任意的な意味論についてはそれを定められた方法でサポートする場合である。
このドラフトで記述されている単純なタイトル機構は、国際化に協力したり、リンクタイトルにおけるマルチメディアの利用には不充分である。将来のバージョンでは、構造化されたリンクタイトルを利用するための機構が提供されるであろう。
著作権 © 1998 W3C (マサチューセッツ工科大学, フランス国立情報処理自動化研究所, 慶應義塾大学).すべての権利が留保されている。W3Cの免責 (liability), 商標 (trademark), 文書利用 (document use), ソフトウェア仕様許諾 (software licensing) 規則が適用される。