XMLリンク言語 (XLink)


W3CWD-xlink-19980303


XMLリンク言語 (XLink)

W3Cワーキングドラフト 1998年3月3日

このバージョン(原文):
http://www.w3.org/TR/1998/WD-xlink-19980303
以前のバージョン:
http://www.w3.org/TR/WD-xml-link-970731
最新のバージョン:
http://www.w3.org/TR/WD-xlink
編集者:
Eve Maler (ArborText) <elm@arbortext.com>
Steve DeRose (Inso Corp. and Brown University) <sderose@eps.inso.com>

この文書の位置づけ

これは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リンク言語 (XLink)

Version 1.0

目次

1. 序論
    1.1 起源と目標
    1.2 既存の規格との関連性
    1.3 用語集
    1.4 表記法
2. ロケータの文法
3. リンクの認識
4. リンク要素
    4.1 リンクに結びつけられる情報
        4.1.1 ロケータ
        4.1.2 リンクの意味論
        4.1.3 リモートリソースの意味論
        4.1.4 ローカルリソースの意味論
    4.2 単純リンク
    4.3 拡張リンク
5. 拡張リンクグループ
6. リンクの挙動
    6.1 "show" 軸
    6.2 "actuate" 軸
    6.3 "show" 軸と "actuate" 軸との組み合わせ
7. 属性再割り付け
8. 適合性

付録

A. 未了の作業
    A.1 タイトルの構造化
B. 参照資料

1. 序論

この文書は、オブジェクト間のリンクを記述するためにXMLリソースに挿入してよい構造を仕様化する。リンクとは、ここで使われている用語としては、2つまたはそれ以上のデータオブジェクトやデータオブジェクトの一部分の間の明示的な関係である。この仕様書は、リンクの存在を主張したりリンクの特性を記述するために使われる文法に関するものである。たとえばある単語と次の単語との関係や、テキスト内のある単語とそのオンライン辞書の見出し語との関係といった黙示的(主張されない)関係は、明らかに重要ではあるが、その射程外にある。

リンクは、XML文書に含まれている要素によって主張される。最も単純なケースは、HTMLの A にとてもよく似ており、これらの特性を有している。

この特性のセットは既に強力であって、明らかにそれ自体で高度に有益かつ効果的であることが証明されているが、これらの設定のそれぞれはハイパーテキストの機能性の範囲を限定してもいる。ここで定義されるリンクモデルは、これらの明確な特性のそれぞれを乗り越えるリンクを作成する手段を提供し、かようにたいてい献身的なハイパーメディアシステムにおいては以前に利用可能であった機能を提供している。

1.1 起源と目標

以下は、XLink を支配する設計理念の要約である。

  1. XLink はインターネット上でそのまままっすぐに利用可能でなければならない。
  2. XLink は広範な種類のリンク利用ドメインやリンクアプリケーションソフトウェアクラスによって利用可能でなければならない。
  3. XLink 表現言語はXMLでなければならない。
  4. XLink の設計は迅速に準備されなければならない。
  5. XLink の設計は形式的かつ簡潔でなければならない。
  6. XLinks は人間がよめるものでなければならない。
  7. XLinks は、関係するリソースが存在する文書の外部にあってもよい。
  8. XLink はリンクの抽象的構造や重要性を表現するものでなければならない。
  9. XLink は実装が可能でなければならない。

1.2 既存の規格との関連性

特に影響力が大きかったのは3つの規格である。

その他のリンクシステムも多数、特に Dexter, FRESS, MicroCosm, InterMedia といったものも、この設計に情報を与えている。

1.3 用語集

以下の基本的用語がこの文書の中で適用される。

要素樹 (element tree)
XML文書内のタグや属性によって指定される適切な構造の表現であり、ISOの DSSSL 規格で定義される「森 (grove)」に基づいている。
行中リンク (inline link)
抽象的には、それ自身のリソースのひとつとして働くリンク。具体的には、リンク要素の内容が参加リソースとして働くリンク。HTMLの A や HyTime の clink、TEI の XREF はすべて行中リンクの例である。
リンク (link)
2つまたはそれ以上のデータオブジェクトまたはデータオブジェクトの一部分の間の明示的な関係。
リンク要素 (linking element)
リンクの存在を主張し、その特性を記述する要素。
ローカルリソース (local resource)
行中リンク要素の内容。リンク要素の内容は、同じリンク要素内の正規のロケータを用いて明示的に指し示すこともできるが、この場合にはローカルではなくリモートとみなされる。
ロケータ (locator)
リンクの一部として提供され、リソースを識別するデータ。
多方向的リンク (multidirectional link)
2つ以上の参加リソースからトラバーサルを開始できるリンク。一方向的リンクをフォローした後で「戻って来」れても、リンクが多方向的であることにはならないことに注意すること。
行外リンク (out-of-line link)
内容がそのリンクの参加リソースとして働かないリンク。そうしたリンクは、拡張リンクグループのような予告を前提としている。この予告はアプリケーションソフトウェアに対してどこでリンクを探せばよいかを示すものである。行外リンクは一般的に、多方向的トラバーサルのサポートと、読みだし専用リソースを外向きのリンクを持てるようにすることとを必須とする。
参加リソース (participating resource)
リンクに属するリソース。すべてのリソースは、あるリンクの潜在的な貢献者である。参加リソースは、ある特定のリンクの実際の貢献者である。
リモートリソース (remote resource)
ロケータを用いて指し示されているリンクの任意の参加リソース。
リソース (resource)
抽象的な意味では、リンクに参加しているアドレス可能なサービスまたは情報の単位である。例としては、ファイル、画像、文書、プログラム、クエリー結果がある。具体的には、あるリンク要素ロケータの利用により到達可能なものである。この用語とその定義はWWWを支配する基本的な仕様書からとられたものであることに注意すること。
サブリソース (sub-resource)
リソースの一部分であり、あるリンクの厳密な目的地として指し示されたもの。一例として、リンクは、文書全体が引き出されて表示されるが、そのある特定の箇所が特定のリンク先データであり、ハイライト化やスクロールなどによる指示といったようなアプリケーションに適した方法で扱われる場合がある。
トラバーサル (traversal)
リンクを使う、すなわちリソースにアクセスする行動。トラバーサルは、ユーザのアクション(たとえばリンク要素の表示された内容上でクリックする)によって開始される場合もあるし、プログラムの制御の下で発生する場合もある。

1.4 表記法

ロケータの形式的文法は、XML仕様書の中に記述されている単純なEBNF (Extended Backus-Naur Form) ロケーションを使って与えられる。

2. ロケータの文法

リソースのロケータは、概して、URI (Uniform Resource Identifier) を用いて提供される。XPointer はURI構造と結びついて、フラグメント識別子やクエリーとして使い、より正確なサブリソースを指定することができる。

これらのRFCが規定する通り、URIは、後に続いたクエリー(先頭に "?" をつけてマークされる)を取り込んでもよく、"#" と フラグメント識別子 とが後ろに続いていてもよい。これには示されたリソースを提供するホストによって解釈されるクエリーがつくが、フラグメント識別子の解釈は示されたリソースのデータ型に依存する。

XML文書や文書の一部分をロケートするために、ロケータ値はURIかフラグメント識別子かのどちらかまたはその両方を含んでもよい。XMLの内部を指し示すフラグメント識別子はすべて XPointer でなければならない。

特殊な文法を使って、ロケータのリソースへのアクセス時に特定の処理モデルの利用を要求してもよい。これはネットワークオペレーションの現実を反映するべく設計されたものであるが、そこではローカルプロセッサとリモートプロセッサとの間の仕事の配布を細かく制御することが望ましい場合もあるし望ましくない場合もある。

ロケータ
[1]  Locator ::= URI
Connector (XPointerName)
URI Connector (XPointerName)
[2]  Connector ::= '#' | '|'
[3]  URI ::= URIchar*

この議論において、指し示されたリソースという用語は、ロケータ全体がロケートするべく働くリソースを指す。以下の規則が適用される。

定義により、URIは任意的なクエリーコンポーネントを含むものであることに注意すること。

URIが(サーバによって解釈されるべき)クエリーを含んでいる場合には、情報提供者やサーバソフトウェアの作成者は、以下のクエリーを使うよう求められる。

クエリー
[4]  Query ::= 'XML-XPTR=' (XPointerName)

3. リンクの認識

リンクの存在はリンク要素によって主張される。リンク要素は、適切な表示や挙動を提供するために、アプリケーションソフトウェアによって安心して認識されなければならない。リンク認識を実現できる方法にはいくつかのものがある。たとえば、要素型名を予約する、属性を予約する、認識の問題を完全にスタイルシートやアプリケーションソフトウェアに委ねてしまう、といったものである。属性を予約することは、ユーザ自身のマークアップ言語設計を与えることと、「リンクである」という重要な構造上の事実を文書内部で明示しておくこととのバランスを提供する。それゆえ、XLink リンク関連要素は、xml:link という名前の指し示される属性の仕様に基づいて認識される。取りうる値は locator, group, document と同様、simpleextended(これらはリンク要素を識別する)である。その開始タグの中でそうした属性が現れるような要素は、この仕様書によって書かれている示された XLink 型の要素として扱われるべきである。たとえば、

<A xml:link="simple" href="http://www.w3.org/">The W3C</A>

注意:関連規格において開発されるべき定義に従い、"7. 属性の再割り付け" で記述されている方法が、予約されている属性の名前の付け替えのために使われてもよい。

xml:linkxml:attributes 属性をリンク要素に結びつけるのに使ってよいメカニズムには2つのものがある。最も単純なのは、開始タグの中に明示的に属性を与えることである。それよりも面倒でない方法は、デフォルト属性値を宣言するためのXMLの機能を使うことである。たとえば、以下の属性リスト宣言は、現在の文書の A 要素のインスタンスすべてが XLink 単純リンクであることを示すことになる。

<!ATTLIST A xml:link CDATA #FIXED "simple">

4. リンク要素

XLink は2タイプのリンク要素を定義する。

どちらの種類のリンクも、さまざまな型の情報を結びつけることができる。

4.1 リンクに結びつけられる情報

以下の情報は、リンクやそのリソースに結びつけることができる。

この情報は、属性やリンク要素の形で供給される。以下の節では、パラメータ実体を使ってこれらの属性をグループ化する。

4.1.1 ロケータ

ロケータ文字列は参加リソースを識別する。リンクは、リモートリソースごとにロケータを供給しなければならない。

ロケータは、href という属性の形をとる。以下はこの属性の宣言例であり、locator.att パラメータ実体の中に包み込まれている。

<!ENTITY % locator.att
  "href          CDATA               #REQUIRED"
>

4.1.2 リンクの意味論

以下の意味論的情報がリンクへ提供できる。

以下は、これらの属性の宣言例であり、link-semantics.att パラメータ実体の中に包み込まれている。

<!ENTITY % link-semantics.att
  "inline        (true|false)        'true'
   role          CDATA               #IMPLIED"
>

単純リンクは異なる機能を有する role と呼ばれる属性をもつから、リンクの意味論について role 属性をとることができない。以下は、単純リンク要素で利用するための simple-link-semantics.att パラメータ実体宣言である。

<!ENTITY % simple-link-semantics.att
  "inline        (true|false)        'true'"
>

4.1.3 リモートリソースの意味論

以下の意味論的情報がリンクのリモートリソースに提供できる。

以下は、これらの属性の宣言例であり、remote-resource-semantics.att パラメータ実体の中に包み込まれている。

<!ENTITY % remote-resource-semantics.att
  "role          CDATA               #IMPLIED
   title         CDATA               #IMPLIED
   show          (embed|replace|new) #IMPLIED
   actuate       (auto|user)         #IMPLIED
   behavior      CDATA               #IMPLIED"
>

4.1.4 ローカルリソースの意味論

リンクが行中リンクである場合、以下の意味論情報がリンクのローカルリソースに提供できる。

以下はこれらの属性の宣言例であり、local-resource-semantics.att パラメータ実体の中に包み込まれている。

<!ENTITY % local-resource-semantics.att
  "content-role  CDATA               #IMPLIED
   content-title CDATA               #IMPLIED"
>

4.2 単純リンク

単純リンクは、基本的なHTMLの A リンクの機能を近似する目的で使うことができるが、量は限られているものの追加的機能をサポートすることもできる。単純リンクはロケータを1つしかもたず、そのため、便宜上、リンク要素とロケータとの機能を単一の要素の中へ組み合わせる。この組み合わせの結果として、単純リンク要素は、ロケータ属性とすべてのリンク・リソース意味論属性との双方を提供する。

以下は、単純リンクの宣言例であり、それがもってよい取りうる XLink 関連の属性のすべてを("4.1 リンクと結びつけられる情報" で与えられたパラメータ実体を使って)示している。単純リンクの xml:link 属性値は simple でなければならない。

<!ELEMENT simple ANY>
<!ATTLIST simple
    xml:link      CDATA               #FIXED "simple"
    %locator.att;
    %remote-resource-semantics.att;
    %local-resource-semantics.att;
    %simple-link-semantics.att;
>

単純リンク要素の内容には何の制約もない。上記の宣言例では、任意の内容モデルや宣言内容が受付可能であることを示す ANY という内容モデルが与えられている。妥当な文書では、XLink にとって重要な要素ごとが、それを支配するDTDにおいて表わされた制約にも適合していなければならない。

以下は単純リンクの例である。

<mylink xml:link="simple" title="Citation"
   href="http://www.xyz.com/xml/foo.xml" show="new"
   content-role="Reference">as discussed in Smith(1997)</mylink>

この例の mylink 要素は、以下の要素および属性リスト宣言を有してもよい。

<!ELEMENT mylink (#PCDATA)>
<!ATTLIST mylink
    xml:link      CDATA               #FIXED "simple"
    href          CDATA               #REQUIRED
    content-role  CDATA               #IMPLIED
>

そんなリンクは一般的ではないけれども、行外単純リンクをもつことは有意義であることに注意すること。こうしたリンクは「一方端型」と呼ばれ、概して、個別の意味論的プロパティをロケーションに結びつけるために使われる。プロパティは、リンク上の属性やリンクの要素型名その他の方法で表わされる場合があり、リンクの完全に独り立ちしたリソースとはみなされない。拡張リンクの方がはるかに広範囲の利用法があるので、ほとんどの行外リンクは拡張リンクである。

4.3 拡張リンク

拡張リンクは、ローカルリソースひとつ(任意的)やリモートリソースひとつだけではなく任意の数のリソースと接続できる点や、拡張リンクの方が単純リンクよりも行外リンクであることが多いという点で、単純リンクと異なっている。

拡張リンクの追加的な能力はつぎのようなことのために要求される。

アプリケーションソフトウェアは、リンクのすべての参加リソースの間のトラバーサルを提供し(この仕様書の射程外の意味論的制約には服する)、それが表示されるときに、(正確にはそれを示す点にマークアップがなくとも)与えられたリソースまたはサブリソースが1つまたはそれ以上のリンクに参加しているという事実を知らせてもよい。

拡張リンクのリンク要素は、ロケータとして働く一連の子要素を含んでいる。(単純リンクが2つを組み合わせるのに対して)拡張リンクは2つ以上のリモートリソースを持つことができるので、各リソースをロケートするために使われる機構からリンク自身を切り離す。

リンク要素自身は、それらの属性を、全体としてのリンクや、あればそのローカルリソースとの関係を維持する。以下は拡張リンクの宣言例である("4.1 リンクに結びつけられる情報" で与えられたパラメータ実体を使っている)。拡張リンクの xml:link 属性値は extended でなければならない。

<!ELEMENT extended ANY>
<!ATTLIST extended
    xml:link      CDATA               #FIXED "extended"
    %link-semantics.att;
    %local-resource-semantics.att;
>

リモートリソースと関連する属性は、対応する被包含ロケータ要素上で表わされる。リモートリソースは各自、全体としてのリンクと関連してそれ自身の意味論を持つことができる。以下はロケータ要素の宣言例であり、それがもってよいすべての取りうる XLink 関連属性を示している("4.1 リンクに結びつけられる情報" で与えられたパラメータ実体を使っている)。ロケータ要素の xml:link 属性値は locator でなければならない。

<!ELEMENT locator ANY>
<!ATTLIST locator
    xml:link      CDATA               #FIXED "locator"
    %locator.att;
    %remote-resource-semantics.att;
>

以下は行外拡張リンクの例である。

<commentary xml:link="extended" inline="false">
   <locator href="smith2.1" role="Essay"/>
   <locator href="jones1.4" role="Rebuttal"/>
   <locator href="robin3.2" role="Comparison"/>
</commentary>

便宜上、ロケータ要素の意味論的属性のデフォルトは、それらを含んでいるリンク要素上で指定できる。そうした属性がロケータ要素から省略された場合には、包含リンク要素上に与えられる値が使われることになる。以下は拡張リンクの宣言例であり("4.1 リンクに結びつけられる情報" で与えられたパラメータ実体を使っている)、リモートリソースの意味論的属性を含めて、それがもってもよいすべての取りうる XLink 関連属性を示している。

<!ELEMENT extended ANY>
<!ATTLIST extended
    xml:link      CDATA               #FIXED "extended"
    %link-semantics.att;
    %local-resource-semantics.att;
    %remote-resource-semantics.att;
>

リンク要素の内容は、概して、ロケータ要素だけからなる。もっとも、ANY としての宣言は、他のどの内容も追加してよいことを示している(妥当な文書では、XLink にとって重要な要素はすべて、それを支配するDTDで表わされた制約に適合していなければならない)。リンク要素の直接の子であるロケータ要素だけが、そのリンク要素によってリンクされるリソースを定義する。

行外拡張リンクについて鍵となる問題は、リンクアプリケーションソフトウェアがそれをどのように処理・発見できるかということである。その参加リソースが出現する文書から完全に分離した文書に保存されているときには特に問題となる。XLink は関連するリンク包含文書を識別する機構を提供しているが、これは "5. 拡張リンクグループ" で論じられる。

5. 拡張リンクグループ

ハイパーリンクつき文書は、一つずつでよりもグループで処理されるのが最良であることがよくある。トラバーサルを始められることを宣伝するためにリソースを強調することが好ましく、同時に行外リンクが複数使われる場合には、これらのリンクを探してリソースがどこにあるかを発見するために他の文書を読むことが、絶対的な要求であることもある。

これらの場合には、特別な種類の拡張リンクである拡張リンクグループ要素を使って、相互リンクされたグループをともに構成する他の文書へのリンクの一覧を保存してもよい。そうした文書はそれぞれ、特別な種類のロケータ要素である拡張リンク文書要素を用いて識別される。

以下は拡張リンクグループや拡張リンク文書要素の宣言例であり、それらが取りうる XLink 関連の属性をすべて示している("4.1 リンクに結びつけられる情報" で与えられたパラメータ実体を使っている)。拡張リンク要素の xml:link 属性値は group でなければならず、拡張リンク文書要素の xml:link 属性値は document でなければならない。

<!ELEMENT group (document*)>
<!ATTLIST group
    xml:link      CDATA               #FIXED "group"
    steps         CDATA               #IMPLIED
>
<!ELEMENT document EMPTY>
<!ATTLIST document
    xml:link      CDATA               #FIXED "document"
    %locator.att;
>

作成者は steps 属性を使って、それ自身の拡張リンクグループを含んでいることが分かっている他の文書をロケートするために拡張リンクグループがアプリケーションソフトウェアを指している状態を処理する助けとしてもよい。無限退行の潜在的可能性があるが、にもかかわらず、いくつかのレベルの拡張リンクグループを処理することが便利であるような状態もある。steps 属性は、拡張リンクグループの処理が何ステップまで着手されるべきかに関し、作成者からリンク処理器へのヒントとして働く数値をもつべきである。これは規範的な効果は有しない。

たとえば、ある文書のグループがすべての行外リンクを含んでいる単一の「ハブ」文書で組織されているとすると、非ハブ文書それぞれが、ハブ文書への参照を1つだけ含んだ拡張リンクグループを含むことにも意味があるかもしれない。この場合には steps について最良の値は 2 ということになろう。

6. リンクの挙動

リンクのフォーマッティングとリンクの挙動とは、分かちがたく関連している。一般に、フォーマッティングには、リンクが存在していることを示すためのフォントや色、アイコンの選択やその他の道具といったような、ユーザアクション前のリンクの外観や扱いも含まれる。挙動は、リンクがトラバースされたときに何が起こるかに焦点をあてる。これには、ウィンドウやページを開いたり閉じたりスクロールさせることや、さまざまなリソースからのデータをさまざまな方法で表示することや、ユーザや文脈情報を認証したりログにとったりすることや、さまざまなプログラムを実行することが含まれる。

XLink は、リンクフォーマッティングを制御するための機構を提供しない。それはスタイルシートの領域の中に入ると考えられるからである。リンクの挙動も、理念的には、リンク型やリソースの役割、ユーザ環境その他の要因に基づく規則によって決定されるべきものである。しかしながら、XLink は、二・三のきわめて一般的な挙動機構を提供する。これらは一般的にリンク型の主要な、あるいは一致した意味論を反映していると考えられるからである。

XLink が提供する機構は、リンク作成者が、トラバーサルのタイミングや効果に関する一定の意図を発信することを可能にする。そうした意図は、showactuate というラベルのついた2つの軸に沿って表わすことができる。これらは機構よりも政策を表わすために使われる。どのリンク処理アプリケーションソフトウェアも、要求された政策を実装するために、ユーザ環境や処理モードに最適な独自の機構を開発することは自由である。

多くの場合で、既存のハイパーテキストソフトウェアが一般に提供する型のトラバーサル挙動の詳細に関してはるかにきめの細かい制御が望ましいであろう。そうしたリンク挙動の細かい制御は、この仕様書の射程外にある。もっとも、behavior 属性が、作成者が詳細な挙動指示を提供する標準的な場所として提供される。アプリケーションソフトウェアはここを調べる場合がある。

6.1 "show" 軸

show 属性は、トラバース先のリソースが表示または処理されるべき文脈に関する政策を表わすために使われる。これがとってよい値は3つの値のうちの1つである。

embed
リンクのトラバーサル時に、表示または処理の目的で、トラバーサルが始まったロケーションにおいてリソース本体に、指し示されたリソースが埋め込まれるべきことを示す。
replace
リンクのトラバーサル時に、表示または処理の目的で、指し示されたリソースがトラバーサルが始まったリソースを置き換えるべきことを示す。
new
リンクのトラバーサル時に、トラバーサルが始まったリソースの文脈に影響を及ぼさずに、指し示されたリソースが新しい文脈で表示または処理されるべきことを示す。

6.2 "actuate" 軸

actuate 属性は、リンクのトラバーサルが何時発生するべきかについての政策を表わすために使われる。これがとってよい値は2つの値のうちの一つである。

auto
同じリンクの他のリソースのどれかが遭遇したときに、問題となっているリソースが引き出され、それが実行されるまでは最初のリソースの表示または処理が完了したとはみなされないことを示す。すべての auto リソースは、指定された順序で引き出される。
user
トラバーサルの明示的・外部的な要求があるまではリソースは表現されるべきではないことを示す。

6.3 "show" 軸と "actuate" 軸との組み合わせ

show 属性と actuate 属性との組み合わせはそれぞれ意義がある。おそらく、もっともはっきりしないのが show="replace"actuate="auto" との組み合わせだろう。これは、あるアンカーが表示されるときに他(他方)はユーザの干渉なしにそれを置き換えるべき、転送型のアプリケーションで使うことができるであろう。XLink は、リンクについては最も一般的な意味論しか提供しないから、転送前の遅延時間やビープ音といったような表現の詳細は、スタイル言語を使ってアプリケーションベースごとに指定できる。

7. 属性の再割り付け

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
        title      CDATA                #IMPLIED
        role       (PRIMARY|SUPPORTING) #IMPLIED
>

これを単純リンクとして使うことが望まれるのであれば、属性の組を再割り付けすることが必要となる。これは内部サブセット内で実現できる。

<!ATTLIST TEXT-BOOK
        xml:link       CDATA            #FIXED "simple"
        xml:attributes CDATA
                       #FIXED "title xl-title role xl-role"
>

そうすると、この文書では、以下のものが単純リンクとして認識されることになるのである。


<TEXT-BOOK title="Compilers: Principles, Techniques, and Tools"
           role="PRIMARY" xl-title="Primary Textbook for the Course"
           xl-role="ONLINE-PURCHASE"
           href="/cgi/auth-search?q="+Aho+Sethi+Ullman"/>

8. 適合性

要素は以下の場合に XLink に適合する。

  1. 要素が xml:link 属性をもち、この属性の値がこの仕様書で定められた属性値のうちの一つである。
  2. かつ、要素と、その属性や内容のすべてが、この仕様書で定められている通り、選んだ xml:link 属性値によって課される文法的制約に従っている。

XLink リンク機構と非 XLink リンク機構とが一つの文書の中で並んで使われる場合があるため、適合性はXML文書全体ではなく個別の要素のレベルで検証されることに注意すること。

アプリケーションが XLink に適合するのは、アプリケーションがこの仕様書で定められたすべての必須の意味論に従って XLink 適合要素を解釈し、またアプリケーションがサポートすることとした任意的な意味論についてはそれを定められた方法でサポートする場合である。


付録

A. 未了の作業

A.1 タイトルの構造化

このドラフトで記述されている単純なタイトル機構は、国際化に協力したり、リンクタイトルにおけるマルチメディアの利用には不充分である。将来のバージョンでは、構造化されたリンクタイトルを利用するための機構が提供されるであろう。

B. 参照資料

XPTR
Eve Maler and Steve DeRose, editors. XML Pointer Language (XPointer) V1.0. ArborText, Inso, and Brown University. Burlington, Seekonk, et al.: World Wide Web Consortium, 1998. (http://www.w3.org/TR/WD-xptr を見ること。1998年3月3日版については拙訳あり。)
ISO/IEC 10744
ISO (International Organization for Standardization). ISO/IEC 10744-1992 (E). Information technology --Hypermedia/Time-based Structuring Language (HyTime). [Geneva]: International Organization for Standardization, 1992. Extended Facilities Annex. [Geneva]: International Organization for Standardization, 1996. (http://www.ornl.gov/sgml/wg8/hytime/html/is10744r.html を見ること。)
IETF RFC 1738
IETF (Internet Engineering Task Force). RFC 1738: Uniform Resource Locators. 1991. (http://www.w3.org/Addressing/rfc1738.txt を見ること。)
IETF RFC 1808
IETF (Internet Engineering Task Force). RFC 1808: Relative Uniform Resource Locators. 1995. (http://www.w3.org/Addressing/rfc1808.txt を見ること)
TEI
C. M. Sperberg-McQueen and Lou Burnard, editors. Guidelines for Electronic Text Encoding and Interchange. Association for Computers and the Humanities (ACH), Association for Computational Linguistics (ACL), and Association for Literary and Linguistic Computing (ALLC). Chicago, Oxford: Text Encoding Initiative, 1994.
CHUM
Steven J. DeRose and David G. Durand. 1995. "The TEI Hypertext Guidelines." In Computing and the Humanities 29(3). Reprinted in Text Encoding Initiative: Background and Context, ed. Nancy Ide and Jean Véronis, ISBN 0-7923-3704-2.

著作権  ©  1998 W3C (マサチューセッツ工科大学, フランス国立情報処理自動化研究所, 慶應義塾大学).すべての権利が留保されている。W3Cの免責 (liability), 商標 (trademark), 文書利用 (document use), ソフトウェア仕様許諾 (software licensing) 規則が適用される。


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