第23回　実体宣言の概要と内部実体宣言 Page 1

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

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

■実体宣言の概要

主な内容 --Page 1-- 実体宣言の概要 実体宣言にまつわる問題点 --Page 2-- 実体宣言の定義 実体宣言の生成規則 実体宣言の規定 --Page 3-- 内部実体の定義 内部実体宣言の例

　前回は、「4.1 Character and Entity References（4.1 文字参照および実体参照）」で、文字参照や実体参照について読んだ。文字参照は、文字をコードによって記述するもので、キーボードから直接入力できない文字をXML文書に書き込む場合などに使われる。実体は、文書内容で使用する一般実体とDTDで使用するパラメタ実体に分類できる。一般実体はさらに、XMLの構文に拘束される解析対象実体と、拘束されずに何でも扱える解析対象外実体に分けられる。これらは、役割も使い方も異なるものであり、正しい知識を持ってうまく使い分ける必要がある。そのような実体を参照する手段について読んだわけである。

　さて今回は、その実体を宣言する方法について読み始める。当然、参照する手段があるということは、参照する対象を宣言する方法も存在しなければならない。今回はそのために、「4.2 Entity Declarations（4.2 実体宣言）」を読み始める。実体宣言が宣言する方法として、宣言の内部に内容を書き込む内部実体と、外部に存在するリソースを参照する外部実体がある。今回は、このうちの内部実体の宣言を規定する「4.2.1 Internal Entities（4.2.1 内部実体）」までを読む。

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

■実体宣言にまつわる問題点

　ここまで、実体を参照する方法について読んできたが、もちろん参照するものはどこかで宣言しなければならない。どこにも宣言されていないものを参照するわけにはいかないからである。ここでは、そのための宣言についての規定を読んでいく。

　余談だが、現実には宣言や定義がどこにもなされていないものを参照するような作業が発生して、技術者を悩ませることがある。いずれ機会があればきちんと書いてみたいトピックではあるが、一見簡単そうなXMLが実は人生と同じぐらい深遠である理由の1つがここにある。通常のコンピュータ言語では、参照する際に宣言や定義が存在しない場合は、大抵エラー扱いすることになる。実に単純明快な原則である。

　例えば、プログラム言語で変数に値を格納しようとしたら、変数は宣言されていなければならない。プログラム言語の中には宣言していない変数を書いても動作するものがあるが、これは宣言されていない変数が使われた場合は、その変数があると見なすという形で間接的に宣言されているものである。このようなやり方をしている限り、システムの構造も使い方もシンプルなものになる。そして、XMLの難しさとは、このようなシンプルさが保証されない点にある。

　XMLでは、参照されたものが宣言されているとは限らない。これには、技術的な側面と、人間的／社会的な側面がある。

　技術的な側面とは、妥当性を検証しない場合、XML文書は宣言されていない実体への参照を含むことができるという問題である。XMLプロセサは、このような実体参照をエラーにしない場合がある。もちろん、それはXML勧告に従う正常な動作である。妥当性を検証しない場合、外部サブセットを処理しないことがあり、その場合は実体の宣言は必須の要求ではない（前回の「整形式制約：Entity Declared（実体が宣言されていること）」を参照）。宣言されていない実体をどう解釈するかは、応用プログラム側の問題となり、それを開発するプログラマの課題として残される。素直にエラー扱いにする、と決められればよいが、そうではない場合は、かなりの難題となる。

　もう1つ、人間的／社会的な側面は主にスキーマを記述する場合に遭遇する。簡単な例として、人名を構造に分解して記述するスキーマを作成するケースについて考えてみよう。構造に分解するとは、例えば人名は姓と名から構成されると考えて、以下のように記述することとしよう。

<姓>川俣</姓><名>晶</名>

　このような書き方を実現するスキーマを記述する場合、もし人名の書き方という明確なルールが宣言されていれば、そのルールをスキーマ言語に翻訳するだけで作業は完了する。こう書くと、「ならば簡単だ。いまの日本では名前は姓と名で構成されると決まっているのだから……」と思う人も多いと思うが、話はそんなに簡単には終わらない。

　例えば、ミドルネームを持つ外国人が日本にやって来て、その名前を扱う必要が生じるかもしれない。人名を「姓」＋「名」という構造で考えると、ミドルネームを入れる場所がない。また、いま生きているれっきとした日本人の情報を扱う場合でも、何代か前のご先祖さまの名前まで収めようとすると、姓を持っていない可能性も考えられる。時代や地域の枠を超えると、いろいろな社会的なルールが変わるのは当然のことだが、それはどこか遠くの縁のない話ではなく、しばしばいまのわれわれの眼前に入り込んでくる。そこで問題になるのは、時代や地域の枠を超えて一般的な人名の書き方という明確なルールが存在するかということである。おそらく、それは存在しないだろう。存在しないルールをスキーマに記述することはできない。

　しかし、これでは結論にならない。なぜなら、人名の構造はまったく存在しないわけではなく、いまの日本なら確かに「姓」＋「名」という構造があって、その構造を生かして使いたいニーズが存在するのである。そこから当然のこととして、明確なルールが宣言されていない情報を記述するスキーマを記述する必要性が発生する。そこから先は正解のない世界に突入していくしかない。「姓」＋「名」という構造を持たない人は一切扱わないと割り切って進む方法もある。完ぺきは不可能としても、可能な限りあらゆる名前の構造を調べ、それらをすべて記述可能とする方法もある。進化するスキーマと位置付けて、新しい構造が要求されたらスキーマを変化させるという方法もある。

　いずれにしても、それぞれデメリットを持つ選択であり、どれを使うことが最善であるかは容易には判別しがたい。その判別しがたいものを「正解はないと承知したうえで」判別していかねばならないのがXMLの本質的な難しさの1つといえる。

　話を本筋に戻し、次ページ以降で実体宣言の定義、生成規則、規定を読み進んでいこう。（次ページに続く）

1/3

Index
やさしく読む「XML 1.0勧告」 第23回 実体宣言の概要と内部実体宣言
	Page 1 ・実体宣言の概要 ・実体宣言にまつわる問題点
	Page 2 ・実体宣言の定義 ・実体宣言の生成規則 ・実体宣言の規定
	Page 3 ・内部実体の定義 ・内部実体宣言の例

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

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