第25回　外部実体における統一資源識別子（URI）　Page 1

XML 1.0は、1998年にW3Cから勧告として公開された。当然中身は英語で、しかもEBNFと呼ばれる式によって重要な部分が記述してある。この連載では、XML 1.0を深く理解するために、そのXML 1.0勧告の最新版「Extensible Markup Language (XML) 1.0 (Third Edition)」をだれでも分かるように、やさしく読み解きながら解説していくことを目指している。（編集局）

川俣 晶
株式会社ピーデー
2004/9/8

■外部実体の後半

主な内容 --Page 1-- 外部実体の後半 システム識別子の定義 --Page 2-- 統一資源識別子（URI） URIのリダイレクト --Page 3-- URIにおける文字の別扱い 文字の別扱いの手順 --Page 4-- 公開識別子の定義 外部実体宣言の例

　前回は、外部実体の宣言について、「4.2.2 External Entities（4.2.2 外部実体）」のうち、外部実体宣言の生成規則などを読んだ。ここで述べられている外部実体は、前々回に読んだ内部実体と異なり、外部にある実体である。そのため、実体の内容よりも、どのようにして実体を参照するかが問題となる。そのため、内部実体の宣言を規定する「4.2.1 Internal Entities（4.2.1 内部実体）」と比較して、はるかに長いものになっている。そのため、前回だけでは読み終わらなかったのが残念である。

　さて今回は、前回読み切れなかった「4.2.2 External Entities（4.2.2 外部実体）」の残りの部分を読んでいこう。具体的には、URIの取り扱いの方法などについて記述する。XML勧告なのに、なぜURIなのかという疑問を持つ方もいると思うが、外部の実体を参照するためにURIが重要な意味を持っているためである。特に、URIには文字を別扱いする（エンコードする）という問題や、相対URIの基準点がどこにあるか、といった悩ましい問題がいろいろ出てくるため、特にXMLではどのように扱うかを明確しておく価値があるわけだが、これもXML 1.0勧告の一部なのでしっかり確認しておこう。

編集注：この連載では、XML 1.0勧告であるW3Cの「Extensible Markup Language (XML) 1.0 (Third Edition)」（英語）を参照し、その日本語訳として、日本工業規格 JIS X 4159:2002（Second Edition相当。リンク先は該当規格の原案ですが、最終版とほぼ同等の内容です）と追補1として出版予定の原稿（Third Edition対応）を参照しています。本文中のピンクの地の部分は、XML 1.0勧告の原文を示しています。

■システム識別子の定義

　次は、System Identifier（システム識別子）という用語の定義である。

[Definition: The SystemLiteral is called the entity's system identifier. It is meant to be converted to a URI reference (as defined in [IETF RFC 2396], updated by [IETF RFC 2732]), as part of the process of dereferencing it to obtain input for the XML processor to construct the entity's replacement text.] It is an error for a fragment identifier (beginning with a # character) to be part of a system identifier. Unless otherwise provided by information outside the scope of this specification (e.g. a special XML element type defined by a particular DTD, or a processing instruction defined by a particular application specification), relative URIs are relative to the location of the resource within which the entity declaration occurs. This is defined to be the external entity containing the '<' which starts the declaration, at the point when it is parsed as a declaration. A URI might thus be relative to the document entity, to the entity containing the external DTD subset, or to some other external parameter entity. Attempts to retrieve the resource identified by a URI MAY be redirected at the parser level (for example, in an entity resolver) or below (at the protocol level, for example, via an HTTP Location: header). In the absence of additional information outside the scope of this specification within the resource, the base URI of a resource is always the URI of the actual resource returned. In other words, it is the URI of the resource retrieved after all redirection has occurred.

［定義：SystemLiteralを、実体のシステム識別子（system identifier）と呼ぶ。XMLプロセサが、実体の置換テキストを生成するには、入力を必要とするが、入力を得るためにシステム識別子を参照する処理の一部として、統一資源識別子（URI）参照（[IETF RFC 2396]で定義され、[IETF RFC 2732]で改訂された。） に変換してから参照することが意図されている。］ 素片識別子（#文字で始まるもの。）がシステム識別子に含まれることは誤りとする。この規格の適用範囲外の情報（例えば、ある特定のDTDの特別なXML要素または特定の応用プログラムの仕様によって定義された処理命令）によって上書きされない限り、相対的な統一資源識別子（URI）は、その実体の位置、すなわち、その実体宣言が現れる資源に相対的とする。実体宣言が現れる資源とは、この実体宣言を宣言として構文解析した時点で、先頭の'<'を含む外部実体とする。したがって、統一資源識別子（URI）は、文書実体・外部DTDサブセットを含む実体・なんらかの外部パラメタ実体に対して相対的とする。統一資源識別子（URI）によって特定される資源を得ようとするとき、パーサのレベルでリダイレクトされてもよく（例えば、実体リゾルバ）、下位プロトコルのレベル（例えば、HTTPのLocation:ヘッダ）によってリダイレクトされてもよい。この規格の適用範囲外の付加的な情報が資源の中に存在しない限り必ず、リソースの基底統一資源識別子（URI）は実際に返されたリソースの統一資源識別子（URI）とする。言い換えれば、すべてのリダイレクションが起こった後で得られるリソースの統一資源識別子（URI）とする。

　少々長いが、順番に1つずつ読んでいこう。

　まず、最初はSystem Identifierという用語の定義である。原文上ではすべて小文字のsystem identifierという表記になっている。最初の文を読んで、記憶力のよい方は「おや?」と思ったかもしれない。というのは、本連載の第6回で、SystemLiteralは外部識別子（external identifiers）と受け取れる表記があったためである。それにもかかわらず、ここでは「SystemLiteralを、実体のシステム識別子と呼ぶ」と表記している。この部分は、日本語訳では分かりにくいが、原文を注意深く見ると指し示す対象の違いが見えてくる。原文ではSystemLiteralの手前に「The」が付いている。つまり、すべてのSystemLiteralについて言及しているわけではなく、この文脈で出現するSystemLiteralについてのみ言及していると解釈できる。そのため、すべてのSystemLiteralは外部識別子と呼ばれ、同時に、この文脈で参照されているSystemLiteralだけは特に実体のシステム識別子と呼ばれるということである。とはいえ、用語の意味としてはそういう解釈ができるが、XML勧告で生成規則[11] SystemLiteralが参照されるのは、実体のシステム識別子の文脈だけであるように見えるので、区別する実用上の意味はあまりないかもしれない。

　次の文章は、「実体の置換テキストを生成するには、入力を必要とする」という部分から見ていこう。実体の参照を扱うためには、参照される実体の内容を参照の代わりに入れる処理が必要とされる。もちろん、これは外部解析対象実体の話である。同じ外部実体でも解析対象外実体は置換テキストを持たないし、DTD内部に置換テキストの情報をあらかじめ含んでいる内部実体はあらためて特別な入力を必要としない。さて、「入力」とは少し分かりにくいが、一般的にはWebサーバなどに存在するファイルのようなものと考えればよいだろう。そのファイルの内容を入力として受け付けるということである。ファイルよりもっと一般的な用語でいえば、リソース（資源）といってもよいだろう。しかし、この後で統一「資源」識別子（URI）によって参照することを意図していると書いているにもかかわらず、リソース（資源）ではなく入力（input）と書かれているのはなぜだろう。その理由は、この言葉が参照を規定するために使われているのではなく、XMLプロセッサの動作を規定するために使われていることから分かるだろう。参照するための表記の話題であればリソース（資源）という用語を使うことが適切ではあるが、実際に処理を行うプログラムであるXMLプロセッサから見れば外部からやってくる情報は入力（input）ということになる。

　さて文章の後半も見ていこう。後半の主役は統一資源識別子（URI）である。カッコ内で、[IETF RFC 2396]で定義され、[IETF RFC 2732]で改訂されたとRFCの番号を示して表記されているので、統一資源識別子（URI）の詳細を調べる場合はこの番号を活用してRFC本文を入手しよう。さて、ここで重要なポイントは、統一資源識別子（URI）参照に変換してから参照することが意図されている、という部分である。この文章は、また解釈が悩ましい。システム識別子とは、URIを記述すべきものであるのか、それともURIに変換可能であれば何を書いてもよいのか。具体的に変換可能とは、どんな変換について書いたものであるのか。これらの問いに対する答えは、ややあいまいさはあるものの、この後の段落を見ると何となく見えてくる。URIでは使用できる文字の種類に制限があり、それに該当しない文字は別扱い（escape）しなければならない。そして、この後の段落では、別扱いの手順について説明されている。URIの変換とは、別扱いのことであると考えると筋が通って読める。つまり、実体のシステム識別子は、別扱いしなければならない文字を含むURIを記述してもよく、その場合は別扱いの処理を行ってから参照する、ということである。

　ここまでで、System Identifierという用語の定義は終わりとなる。次からは普通の文章である。

　次の文章は、外部解析対象実体の定義を振り返れば当然の要請といえる。そのことの意味を、少し確認しておこう。HTMLでは、「http://www.atmarkit.co.jp/news/#0」というような#文字で始まる素片識別子を使用するのは普通のことである。しかし、これに対してXMLでは同じと見なせない点が2つある。1つは、素片識別子を埋め込む機能が外部解析対象実体には含まれないという点である。HTMLの場合はid属性の値が素片識別子として機能するが、これはHTML勧告でそのように規定されているからで、そのような規定のないXML勧告ではid属性が素片識別子として機能する理由がない。もう1つは、HTMLでの素片識別子の効能が事実上表示位置の指定として機能しているが、XML勧告には表示位置という概念がないことである。つまり、そのような指定を行うことそのものに意味がない。もちろん、XMLを用いて作成された言語（例えばXHTML）には、id属性の値が素片識別子として機能したり、表示位置の指定という機能を持つ場合もあるだろう。しかし、それらはXML勧告のレベルでは規定されず、より上位の言語によって規定されるものである。XML勧告のレベルでは対象外となるものである。

1/4

Index
やさしく読む「XML 1.0勧告」 第25回 外部実体における統一資源識別子（URI）
	Page 1 ・外部実体の後半 ・システム識別子の定義
	Page 2 ・統一資源識別子（URI） ・URIのリダイレクト
	Page 3 ・URIにおける文字の別扱い ・文字の別扱いの手順
	Page 4 ・公開識別子（Public identifier）の定義 ・外部実体宣言の例

連載　やさしく読む「XML 1.0勧告」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）