第24回　外部実体の諸問題を理解する　Page 1

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

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

■外部実体の概要

主な内容 --Page 1-- 外部実体の概要 定義されないものへの参照 --Page 2-- 外部実体の定義 外部実体宣言の生成規則（ExternalID） 外部実体宣言の生成規則（NDataDecl） 妥当性制約：Notation Declared

　前回「実体宣言の概要と内部実体宣言」は、実体を宣言する方法について読み始めた。XML 1.0勧告の「4.2 Entity Declarations（4.2 実体宣言）」で、宣言の内部に内容を書き込む内部実体と、外部に存在するリソースを参照する外部実体があることを確認し、このうちの内部実体の宣言を規定する「4.2.1 Internal Entities（4.2.1 内部実体）」までを読んだ。

　さて今回は、外部実体の宣言について読んでいこう。具体的には「4.2.2 External Entities（4.2.2 外部実体）」を読んでいく。ここでは、実体は外部にあるものなので、実体の内容よりも、どのようにして実体を参照するかが問題となる。そのためには、URIなどが使用されるが、URIには文字を別扱いする（エンコードする）という問題や、相対URIの基準点がどこにあるか、といった悩ましい問題がいろいろ出てくる。そのため、内部実体の宣言を規定する「4.2.1 Internal Entities（4.2.1 内部実体）」と比較して、はるかに長いものになっているが、これも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勧告の原文を示しています。

■定義されないものへの参照

　前回、余談として定義されないものへの参照という話題を書いた。これが一部で好評であったが、それに若干の補足を付け加える。

　前回述べたのは、XMLでは定義されないものを参照する場合があるという話であった。技術的には、定義されていない実体への参照が生じることがあり、人間的／社会的な側面としては、例えば時代や地域を超えて通用する人名の構造の定義は存在しないだろうと述べた。しかし、定義されないものを参照するというニーズはあり、そこにXMLを使う難しさと深遠があるといえる。

　さて、感想の中で、少々面食らったのは、「身近な話題で良かった」という感想である。確かに、人名を例に出したので身近な話題という印象が残るかもしれないが、筆者が意図したのは抽象的で分かりにくい話題である。もうちょっと、身近なようでいて身近ではない部分について触れておこう。

　例えば、XMLを用いてスキーマを設計する場合に、人名の構造を意識する必要が生じることがあることはすでに述べた。しかし、通常のシステム開発でデータベースを設計する場合にも、人名について意識する場合がある。もし、両者が同じようなものであるなら、人名の構造について悩むことはXML固有の問題ではないことになる。これまで、多くのシステム開発が行われてきた中で、データベース設計者が悩んできたことと、同様の問題が繰り返されただけのことである。

　しかし、実際にはこの2つは同じとは見なせない。なぜなら、データベースを設計することと、XMLでスキーマを記述することは、（同じ場合もあるが、多くの場合）異なる性質を持った作業であるからだ。データベースの設計とは、システムの設計の一部となる。システムとは、ハードとソフトを含み、要求された仕事をこなすために必要な一式である。そこで、データベースの正しさは、実際に運用してみることで明らかになる。すでに既存のデータがある場合は、それをデータベースに格納して試用してみれば、データベース設計が正しいか否かが明らかになる。もし、設計時に意図しなかったデータを扱う必要が生じた場合は、データベースの設計を変更し、既存のデータベースを新しい設計に従って変換することで運用を続けることができる。

　さて、XMLでスキーマを記述する場合、具体的なシステムの一部でのみ使用されるローカルなスキーマとすれば事情はデータベースの設計と大差ない。ところが、あえてXMLが選択される場合には、そうではないケースも多いのである。

　例えば、XMLが選択される典型的なパターンには、不特定多数のシステム間の情報交換に利用する場合であるとか、情報をシステムの世代を超えて保存したい場合などがある。これらの場合、具体的に特定の1つのシステムに限定されない広範囲での利用が想定される。そのような状況では、特定の1つのシステムでうまく機能したとしても、それがスキーマの正しさを保証してはくれないのである。

　もし、設計時に意図しなかったデータを扱う必要が生じた場合でも、安易にスキーマを変更することはできない。不特定多数のシステムでスキーマを共有しているとすれば、それらのシステムが持っているすべてのデータを同時に変換しなければならないが、それは極めて難しい。また、改変されてはならない性質を持つデータであれば、変換という行為そのものが許されないことになる。新旧スキーマを併用して運用するという方法もあるが、それはシステムの複雑さ、コストアップを招く。また、旧スキーマにしか対応していないシステムがあれば、データを処理するシステムがどのスキーマに対応しているか確認することも必要とされる。いずれにしても、仮にスキーマの変更が可能だとして、それは特定システムのデータベース設計の変更と比較して、極めてコスト高の対応となる。

　では、具体的に人名を扱う場合について考えてみよう。データベースを設計する場合は、既存の顧客データベースの名前をすべて扱えればOK、というような基準を設けることはできるだろう。しかし、XMLのスキーマを記述する場合は、それができないことがある。既存の顧客の名前が記述できればよい、という条件でスキーマを作成する場合でも、不特定多数の組織が持っているすべての既存顧客の名前を検証用のデータとして入手することは、個人情報保護などの観点から難しいだろう。その結果、スキーマ作成後、実際に既存顧客の名前を入力しようとしたら、ミドルネームを入れる場所がなくて困った、というような不整合が発覚することもあるだろう。このような問題を未然に防ぐには、時代や地域に特定されない人名の定義を基に、スキーマの中で人名の構造を宣言すればよい。しかし、そのような定義がそもそもこの世に存在しなければ、そのような解決策は取れないことになる。

　このようなことから分かるとおり、データベースの設計とXMLのスキーマの設計には、かなりの違いがある。もちろん、データベースの設計は単純で、変更も簡単にできると思うのは間違いである。きちんとしたデータベースを設計することは知識と経験を持つベテランが取り組んですら一筋縄ではいかないものである。そして、運用が始まった後でデータベースの設計を変更することも、現実的には困難だろう。しかし、XMLのスキーマの設計は、それと比較してすらはるかに難しい問題となる可能性を秘めているのである。そのような点に、XMLには人生と同じだけの奥行きがあると感じることは、あながち間違いではないと思う。

　そして、だれもが当たり前に使っていながら明確な定義が存在しないものは、人名のほかにもたくさんある。それらの多くは、実利用上のニーズから、当然の要求としてXML文書に記述することが求められる。明確な定義はないがスキーマを書かねばならない事態は、決して珍しいものではない。しかも、スキーマが実利用上十分であるか検証できるとは限らない。これに対処するセンスを磨くことが、究極的にXML技術者に求められることになるのではないかと思う。

　もちろん、だからといって過剰に恐れを抱く必要はない。定義がないものは定義がないのだから、だれがやっても正解にたどり着くことはできない。正解にたどり着こうとすることよりも、うまい妥協点を見いだすことができれば十分である。怖いのは、定義できないものについて、努力すれば定義できると思い込んで無限に時間を費やすことだけである。

　次ページでは外部実体の定義と生成規則、妥当性制約について読んでいこう。（次ページへ続く）

1/2

Index
やさしく読む「XML 1.0勧告」 第24回 外部実体の諸問題を理解する
	Page 1 ・外部実体の概要 ・定義されないものへの参照
	Page 2 ・外部実体の定義 ・外部実体宣言の生成規則（ExternalID） ・外部実体宣言の生成規則（NDataDecl） ・妥当性制約：Notation Declared

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

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