第4回　XML仕様書で使われる言葉の意味

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

川俣 晶
株式会社ピーデー
2002/11/28


■言葉の意味

今回の主な内容 言葉の意味 may、must error､fatal error ユーザーオプション、制約 match、互換性 第2章 文書（Documents）とは XML文書の論理構造と物理構造

　今回も、XML 1.0勧告の第1章に当たる「一般事項（1. Introduction）」を読み取っていこう。今回の中心は、仕様書の中で使われる用語についての定義だ。

　1.2 Terminologyでは、XML 1.0勧告の中で使われるいくつかの言葉の定義が行われている。人間が使う言葉には複数の意味が含まれることもあり、あらかじめ意味を定義しておかないと、読者によって違う意味に受け取られる危険があるためだ。例えば、“error”という言葉は、“誤り”と理解するのは容易だが、受け付けてはならない誤りもあれば、誤りという状態として受け付ける必要がある場合もある。この2つの解釈は、実際にプログラムを書いて実装する場合には、大きな差となる。こういうあいまいさはできるだけ取り除くのが望ましい仕様の書き方である。

1.2 Terminology The terminology used to describe XML documents is defined in the body of this specification. The terms defined in the following list are used in building those definitions and in describing the actions of an XML processor:

　上記を読むと、「XML文書を記述するために使用する用語はこの仕様内で定義される」と書かれている。つまり、この後で定義されている用語は、これらの定義を構築するためと、XMLプロセッサの動作を記述するために使われる。

■may、must

　最初に定義される用語は「may」だ。

may [Definition: Conforming documents and XML processors are permitted to but need not behave as described.]

　mayは、英語でよく使われる単語だが解釈に幅があるため、仕様書などでは定義されたうえで用いられることが多い。mustや、shouldなども定義されたうえで使われることが多い。

　ここで記述されていることは、mayを用いて記述された定義は、それを満たすように実装してもよいし、そうでなくてもよいとしている。どちらでもよければわざわざ定義して使う必要がないと思われるかもしれないが、そうではない。ほかの条件と複合されて記述される際に、mayは重要な意味を持つのである。例えば、

「Comments may appear anywhere in a document outside other markup」
（コメントは、ほかのマーク付けの外ならば、文書のどこに現れてもよい）

というような文章を表現するために使用されている。

must [Definition: Conforming documents and XML processors are required to behave as described; otherwise they are in error. ]

　mustは、その文章に記述されたとおりでなければエラーであることを示すために使われる。文書やXMLプロセッサは、mustを使って記述された文章には必ず従わねばならない。そうしなければ、XML 1.0勧告に適合していると主張することはできない。

■error、fatal error

error [Definition: A violation of the rules of this specification; results are undefined. Conforming software may detect and report an error and may recover from it.]

　errorは、この仕様のルールに対する違反を意味する。結果は定義されない。つまり、この仕様に適合するソフトウェアは、エラーを検出してもよく、それを報告してもよく、そのエラーから回復してもよい。ここでerrorという言葉が定義されているのは、次のfatal errorとのニュアンスの違いを明確化するためだろう。errorは、ある程度利用状況に応じた対応の選択の自由があるが、fatal errorはそうではない。

fatal error [Definition: An error which a conforming XML processor must detect and report to the application. After encountering a fatal error, the processor may continue processing the data to search for further errors and may report such errors to the application. In order to support correction of errors, the processor may make unprocessed data from the document (with intermingled character data and markup) available to the application. Once a fatal error is detected, however, the processor must not continue normal processing (i.e., it must not continue to pass character data and information about the document's logical structure to the application in the normal way).]

　fatal errorとは、この仕様に適合するXMLプロセサが検出するもので、そして、アプリケーションに伝えねばならないエラーであるとしている。ここではmustが使われていて、選択の余地はない。そのように動作しなければXML 1.0勧告に適合しているとはいえない。

　fatal errorに遭遇した後は、ほかのエラーを検出するためにXMLプロセッサは処理を続けてもよく、それらのエラーをアプリケーションに伝えてもよいとしている。ここはmayなので、fatal error発生後の処理は続けても続けなくてもよい。誤りの訂正をサポートするために、XMLプロセッサは、処理していないデータをアプリケーションから利用可能にしてもよい。

　しかし一度fatal errorを検出したら、XMLプロセッサは通常の処理を継続してはいけない。ここはmustなので、fatal error検出後に処理を続ける目的はほかのエラーを確認するために限られ、通常の処理は続けてはならないことを示している。つまり、fatal errorが存在するXML文書をパースするとき、fatal errorが出現する個所以降の要素や属性などの通常の情報を、XMLパーサを利用する側が得られてはならないということである。

　このことは、現在多く使われているWebブラウザがエラーに寛容で、HTMLのエラーがあっても文書をなんとか解釈して表示する、といったことが、XMLのパーサでは許されないことを意味している。これは、WebブラウザごとにHTMLのエラーに対する挙動が違い、これらの互換性を高めるために、メジャーなWebブラウザのエラー発生時の挙動をいちいち調査するといった作業を強いられているWebブラウザ開発者の苦労を反映して、導き出された規定であるともいわれている。

■ユーザーオプション、制約

at user option [Definition: Conforming software may or must (depending on the modal verb in the sentence) behave as described; if it does, it must provide users a means to enable or disable the behavior described.]

　上記は、「ユーザーオプション」について記述してある。ソフトウェアは、仕様書に記述されたとおりに振る舞ってもよい（may）、または振る舞わなくてはならない（must）。記述されたとおりに振る舞う場合は、記述された振る舞いを選択するか拒否するかを、ユーザーオプションとして利用者に提供しなければならない。

validity constraint [Definition: A rule which applies to all valid XML documents. Violations of validity constraints are errors; they must, at user option, be reported by validating XML processors.]

　validity constraint（妥当性制約）とは、すべての「妥当なXML文書」に適用する規則である。対象は、妥当なXML文書に限られ、「整形式のXML文書」には適用されない。

　validity constraintの違反は、errorになる。利用者の任意選択によって（at user option）、検証を行うXMLプロセッサはそれを報告しなければならない（must）。つまり、validity constraint違反を伝えろという選択がされている場合は、XMLパーサはそれを必ず報告しなければならないということである。

well-formedness constraint [Definition: A rule which applies to all well-formed XML documents. Violations of well-formedness constraints are fatal errors.]

　well-formedness constraint（整形式制約）は、すべての整形式のXML文書に適用する規則である。well-formedness constraintへの違反は、fatal errorである。validity constraintと違って、対応に選択の余地はない。validity constraintに違反しても、整形式のXML文書として正しい可能性が残されているので、それを受け付ける意味があるかもしれないが、well-formedness constraintに違反したXML文書は妥当なXML文書としても誤りなので、選択の余地を残す意味はないのだろう。

■match、互換性

match [Definition: (Of strings or names:) Two strings or names being compared must be identical. Characters with multiple possible representations in ISO/IEC 10646 (e.g. characters with both precomposed and base+diacritic forms) match only if they have the same representation in both strings. No case folding is performed. (Of strings and rules in the grammar:) A string matches a grammatical production if it belongs to the language generated by that production. (Of content and content models:) An element matches its declaration when it conforms in the fashion described in the constraint [VC: Element Valid].]

　2つの文字列や名前について、比較して同一であることをmatch（マッチする）という。これは少し悩ましい問題である。というのは、XMLで参照されているISO-10646-1（日本ではJIS X 0221-1）では、複数の表現が可能な文字があるためだ。同じ文字なのに、複数のコードを合成して1文字にする方法と、最初から1つのコードに合成済みの文字の両方が含まれていたりするのである。これは、同じ表現に限ってマッチすると見なすとされている。つまり、同じ文字でも、表現方法が異なっていれば、マッチするとは見なさないということである。大文字と小文字の違いは区別される。

　また、生成規則から生成される言語に属するとき、ある文字列はその生成規則にマッチする、とされている。ある要素は、要素の妥当性という妥当性制約に適合するとき、その宣言にマッチする、とされている。

　これらは言葉にすると難しいが、単にXML 1.0勧告を読み下すだけなら、matchという言葉の雰囲気に従って読むだけでもだいたい意味は分かるだろう。しかし、実際にプログラムに記述する場合は、厳密な意味を考えて悩まねばならない場合があるかもしれない。

for compatibility [Definition: Marks a sentence describing a feature of XML included solely to ensure that XML remains compatible with SGML.]

　for compatibility（互換性のためには）とは、SGMLとの互換性が残ることを保証するためにのみ含まれる機能を記述するときに使われる、とされている。

for interoperability [Definition: Marks a sentence describing a non-binding recommendation included to increase the chances that XML documents can be processed by the existing installed base of SGML processors which predate the WebSGML Adaptations Annex to ISO 8879.]

　for interoperability（相互運用性のためには）とは、拘束力は持たない推奨事項について記述する文を示している。具体的に何を示しているかというと、ISO 8859つまりSGMLの付属書で示されるWebSGMLが出てくる前のSGMLプロセッサで、XML文書を処理できるチャンスを増やすための文章を示している。

　WebSGMLというのは、XMLの流行に対応してSGMLの世界がXMLの世界に歩み寄ったものであるという。WebSGML対応のSGMLプロセッサは、XML文書を処理できるのだろうと思うが、それ以前に作成されたSGMLプロセッサにXML文書を読み込ませる必要性が存在することもあるのだろう。しかし、実際にSGMLプロセッサを使う立場に立つケースは、幅広く使われるようになったXMLの世界の中で、極めてまれなことだと思うので、参考程度に読み流しても、さほど問題はないだろう。

　これで、XML 1.0勧告の「1 Introduction（一般事項）」は終わりである。次からいよいよ、XMLそのものの具体的な定義に踏み込んでいく。

■第2章 文書（Documents）とは

　第2の章は、「2 Documents」と題されている。日本語なら「文書」となる。もちろん、あらゆる文書について記述しているわけではなく、XML文書について記述している。第3の章は論理構造、第4の章は物理構造について記述しているが、第2の章は論理構造や物理構造の定義に必要なより基本的な定義を与える部分と考えるとよいだろう。

　ではさっそく本文を見てみよう。

2 Documents [Definition: A data object is an XML document if it is well-formed, as defined in this specification. A well-formed XML document may in addition be valid if it meets certain further constraints.]

　ここで述べられていることは、“XML Document”（XML文書）という言葉の定義である。ここでは、この仕様書で定義されている“well-formed”(整形式)であるデータオブジェクトがXML文書であるとしている。

　ここで「データオブジェクト」という言葉が出てきたが、すでに述べたとおり、オブジェクトといってもオブジェクト指向プログラミングの話をしているわけではない。もっと一般的なデータの集まりであると考えるとよいだろう。ここで注意すべきことは、整形式とXML文書が定義的にイコールになっていることである。よく、XML文書は、整形式のXML文書と妥当なXML文書に分類できる、などという説明を見掛けるし、筆者もそういってしまうこともあるが、厳密にいえばすべてのXML文書は整形式なので、2つのカテゴリに分けることはできない。

　次を見てみよう。次は、“valid”（妥当）について述べられている。整形式のXML文書は、もし制約条件を満たせば妥当であるといっている。この制約条件は、この仕様書の中で定義されている。つまり、すべてのXML文書は整形式であり、その中で特定の条件を満たすものが妥当なXML文書になるわけである。そのため、すべての妥当なXML文書は、整形式のXML文書としても正しいことになる。

間違った解釈： 整形式なXML文書と、妥当なXML文書は2つに分けられるものではない

正しい解釈： すべてのXML文書は整形式であり、その中で特定の条件を満たすものが妥当なXML文書である

■XML文書の論理構造と物理構造

Each XML document has both a logical and a physical structure. Physically, the document is composed of units called entities. An entity may refer to other entities to cause their inclusion in the document. A document begins in a "root" or document entity. Logically, the document is composed of declarations, elements, comments, character references, and processing instructions, all of which are indicated in the document by explicit markup. The logical and physical structures must nest properly, as described in 4.3.2 Well-Formed Parsed Entities.

　続いての説明に、個々のXML文書には、論理構造と物理構造があると書いている。

XML文書は実体の集まり

しかし、実際には実体を使わず外部のリソースを参照する場合が多い

　その次には、物理的に、文書は“entities(entity)”すなわち“実体”と呼ばれる単位の集まりとして構成されると記述されている。実体というのは、XMLを使っている人にもなじみが薄いかもしれない。例えば、XML宣言と要素と属性の書き方だけ知っていれば、簡単な整形式のXML文書は書けるし、それで十分ならそれ以上のことは必要ない。しかし、本当は実体とはXML文書を構成する重要な単位なのである。とはいえ、実体がどれほどの重要性を持つかというと、実際にはそれほどでもない。というのは、外部のリソースを文書から参照する際に、それを実体宣言して参照するよりも、ハイパーリンクの機構を使って属性などにURIを記述してしまう使い方が多いためだ。

　続いて、文書に取り込むために実体がほかの実体を参照することができる、としている。つまり、実体の中で外部の実体を参照すると、その実体も文書の一部になるわけである。

　次は、文書はルートまたは文書実体で始まる、としている。ルートという言葉は、このあとで、たった1つの最上位の要素であると記述されている。

　文書実体という言葉の内容は、4.8 Document Entityで定義されている。要するに最初に出現する実体ということである。文書はこの2つのどちらかにより開始されると読めるが、もしかしたらほかの解釈もあるかもしれない。というのは、文書が実体の集まりなら、文書は実体から始まるのが当然なので、要素から始まると考えるのは不自然である。とすると、ここでいうルートとは、実体が構成する木構造のルート、つまりルート実体であると解釈する方が自然かもいれない。とすれば、ここでいうルートは文書実体のいい換えであると考えられる。

　論理的に、文書は、宣言、要素、コメント、文字参照、処理命令を構成物として持ち、それらは文書中で明示的なマーク付けによって示すとしている。ここで気になるのは、当然XML文書に含まれているはずのテキストや属性への言及がないことだが、テキストは論理的な構造ではなく、属性は要素の一部なので、特に名前が出てこないのだろう。

　次は、論理構造と物理構造は、厳密に入れ子になっていなければならない、としている。どうすれば正しい入れ子であるかは、4.3.2 Well-Formed Parsed Entitiesで記述されているとおりとしている。Well- Formed Parsed EntitiesはJIS版の仕様書では「整形式の解析対象実体」と訳されており、整形式で記述された解析対象外実体の制約について説明しているのだが、これは連載が進んで、それが出てきたときに詳しく説明しよう。簡単に触れておけば、解析対象実体はXMLの定義によって解釈される実体のことである。もし解釈されなければ整形式かどうかを論じる意味もないので、ある意味で整形式といった時点で解析対象であるのは必然ともいえる。

　さて今回はここまでだが、次回から文書についての詳しい説明に踏み込んでいこう。

　

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

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