第3回　XML仕様が目指す10のゴール

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

川俣 晶
株式会社ピーデー
2002/10/31


■ようやく本文に到達

今回の主な内容 ようやく本文に到達 データオブジェクトのクラスを記述する 解析されるものと解析されないもの XMLプロセッサとそのアプリケーションとは XMLの経緯と目標 XML仕様の10種類のゴール 人間にとって読みやすいこと XMLの設計は厳密で簡潔に 勧告は自由に配布してよい

　これまで、XML勧告を先頭から読み解いて、XMLの目標（第1回）、EBNFの読み方（第2回）などの解説をしてきた。今回からいよいよ、XML勧告の本文の部分を読んでいくことになる。勧告の第1章に当たる、“1 Introduction（一般事項）”を読むことにしよう。

　この部分は、XML勧告の適用範囲、経緯、目標、用語などについて書かれていて、XMLの具体的な構文を定義しているわけではない。しかし、XMLの本質にかかわる部分に踏み込んでいる文章も含まれるので、軽く読み飛ばすべきではない。

　さて、実際の仕様書の文章を順次読んでいくことにしよう。

■データオブジェクトのクラスを記述する

1 Introduction Extensible Markup Language, abbreviated XML, describes a class of data objects called XML documents and partially describes the behavior of computer programs which process them. XML is an application profile or restricted form of SGML, the Standard Generalized Markup Language [ISO 8879]. By construction, XML documents are conforming SGML documents.

　まず、「拡張可能なマーク付け言語（Extensible Markup Language）XMLは、XML文書と呼ばれるデータオブジェクトのクラスを記述する」と書かれている。ここで注意すべきことは、オブジェクトやクラスという用語が出てくるからといって、いわゆるオブジェクト指向プログラミングの話をしているわけではないということである。ここでいうデータオブジェクトは、もっと普遍的なデータを表現する何かのモノと考える必要がある。クラスは、もっと普遍的なモノの性質であると考える方が分かりやすいだろう。つまり、このXML勧告に記述されているものは、XML文書というモノの性質である、と考えるのがよいだろう。

　続いて、「XML文書を処理するコンピュータプログラムの振る舞いの一部についても記述している」と記述されている。これは本文中に、XMLプロセッサはこう動作しなければならない、という記述が含まれていることを意味する。つまり、XML文書を読み込むアプリケーションを開発するプログラマは、XML文書さえ読み込めるプログラムを作ればよいわけではなく、このXML勧告に記述されている仕様の制約を受ける、ということである。

　その次には、「XMLはSGMLの応用プロファイルまたは制限された書式である」「構文的にXML文書は、SGML文書に適合する」と書かれている。しかし、いまとなっては、これらの文章にそれほど大きな意味はないだろう。SGMLとXMLの関係を意識する機会は、ほとんどない。

■解析されるものと解析されないもの

XML documents are made up of storage units called entities, which contain either parsed or unparsed data. Parsed data is made up of characters, some of which form character data, and some of which form markup. Markup encodes a description of the document's storage layout and logical structure. XML provides a mechanism to impose constraints on the storage layout and logical structure

　次に記述されているのは、XML文書の基本的な構造についての説明である。まず、「XML文書は実体（entities）と呼ばれる記憶単位から構成される」ことが記述されている。XML勧告では、具体的にいくつかの種類の実体についての規定が記述されている。通常、実体はコンピュータ上のファイルに対応することが多いが、必ずしもそれが必須要件ではない。例えば、XML文書を高速に扱うために特殊な記憶方式を取って、実体とファイルが1対1で対応しない使い方も考えられるだろう。

　そして「実体には、構文解析されるものと、されないものがある」と続く。構文解析されるものとは、みんながXMLだと思って見ているタグ付けされた文書のことである。例えば、

<天気>晴れ</天気>

のようなものが、構文解析されるものである。これに対して、例えばJPEG画像ファイルや、XMLの構文に従っていないテキストファイルなどは構文解析されない。とはいえ、構文解析されないものを実体として参照する機会は、あまり多くないかもしれない。画像ファイルは実体で指定するよりも、属性にURIを記述するようにして指定する方法がよく使われている。実体参照よりもURIを用いた参照の方が強力であり使い勝手もよいので、この傾向は続くのではないだろうか。

　次は解析されるデータについて書かれている。「解析されるデータは文字によって構成される」、つまり、解析されるデータはすべて文字で記述可能ということであり、テキストエディタで作成、編集が可能であることを示している。これらの文字は、文字データを構成する場合と、マークアップを構成する場合があるとしている。例えば、

<天気>晴れ</天気>

の場合なら、「晴れ」が文字データで、「<天気>」と「</天気>」はマークアップである。文字だけで記述していながら、特定の文字の並びを機能と見なすルールを課すことによって、文字と機能の両方を記述可能にしているわけである。

　次は、「マークアップは文書の記憶レイアウトと論理構造を記述する情報をエンコードしたものである」との記述だ。つまり、XMLにおけるマークアップの役割は、文書の記憶レイアウトと論理構造の記述にあるということである。文書のどの部分にどんな情報が入っているかというレイアウトの問題と、文書の論理構造についての問題を記述することが、マークアップの役割である。

　ここでいう文書の論理構造という言葉は少し悩ましい。論理構造の反対の意味を持つ言葉はおそらく物理構造だと思うが、具体的に何が論理構造で何が物理構造といえるのか。論理構造とは「章」や「見出し」という文書の個々の役割に着目した構造であり、物理構造とは「ページ」や「フォント」といった文書を物理的に構成するモノに着目した構造であるということはできる。しかし実際には、XMLを用いてページやフォントといった情報を記述することもあるわけで、すっきりとは切り分けられない。恐らく、ここで記述されている論理構造とはこのような意味ではないだろう。それよりも、記憶装置にどのように格納するかという具体的な構造ではないもの、と解釈した方が自然かもしれない。つまり、XML文書を記憶装置に保存したときの物理的な配置方法は規定されていないということである。実際、同一のXML文書をUTF-16とUTF-8で保存すると、内容はまったく同じであるにもかかわらず、実際に記憶される内容（ビット列の状態）はまったく異なって見える。ただし、ここはほかの解釈もあり得るかもしれない。

　そして「XMLは、記憶レイアウトと論理構造についての制約条件を記述する機構を提供する」としている。これは、要素や属性の正しい並びの範囲を記述するという意味に受け取ってよい。具体的にはDTDのことを示しているといえるだろう。

■XMLプロセッサとそのアプリケーションとは

　次を読んでいこう。

[Definition: A software module called an XML processor is used to read XML documents and provide access to their content and structure.] [Definition: It is assumed that an XML processor is doing its work on behalf of another module, called the application.] This specification describes the required behavior of an XML processor in terms of how it must read XML data and the information it must provide to the application.

　この1文は2つの用語の定義と、その用語を使った1文からなっている。最初に定義される用語は、XMLプロセッサ（XML processor）である。XMLプロセサと呼ばれるソフトウェアモジュールは、XML文書の読み込みと、その文書の内容と構造へのアクセス手段を提供する。実質的にはXMLパーサと理解してもよいだろう。

　もう1つの用語は、アプリケーション（application）である。XMLプロセッサが、自分を使ってくれると想定するモジュールをアプリケーションと呼ぶ。一般的には、XMLパーサを呼び出して利用するプログラムのことだと思ってもよい。そして、「この仕様は、XMLプロセサに要求される振る舞いを記述している」、と書かれているように、どのようにXMLデータを読み込み、アプリケーションに伝えねばならないかが記述されている。とはいえ、具体的にアプリケーションに伝えるAPIについては、DOM（Documento Object Model）やSAX（Simple API for XML）のように別の仕様となっているので、このXML勧告では具体的なインターフェイスの定義にまでは踏み込まないと理解すべきだ。しかし、インターフェイスを通じて伝えられるべき情報については、この仕様で触れられている。

■XMLの経緯と目標

　次は経緯（Origin）と目標（Goals）である。

1.1 Origin and Goals XML was developed by an XML Working Group (originally known as the SGML Editorial Review Board) formed under the auspices of the World Wide Web Consortium (W3C) in 1996. It was chaired by Jon Bosak of Sun Microsystems with the active participation of an XML Special Interest Group (previously known as the SGML Working Group) also organized by the W3C. The membership of the XML Working Group is given in an appendix. Dan Connolly served as the WG's contact with the W3C.

　ここは特に技術的に難しい話ではないので、JIS規格の日本語訳を引用して説明に代えよう。「1996年にWorld Wide Web Consortium（W3C）の中に設立されたXML作業グループ（以前は、SGML編集レビュー委員会と呼ばれた）がXMLを開発した。この作業グループの議長を、Sun MicrosystemsのJon Bosakが務めた。W3Cが組織し、以前はSGML作業グループと呼ばれたXML SIG（Special Interest Group）も、XMLの制定に活発に参画した。XML作業グループのメンバを附属書Gに示す。Dan Connollyは、作業グループとW3Cとの調整役を務めた。」

　上記に1つだけ補足すると、いまでこそXMLはブームというような状況になり、多くの有力企業がXMLにかかわろうとしているが、それはXML誕生後の状況でしかない。実際にXMLを生み出すプロセスは、異端の少数派によって行われてきたものである。

■XML仕様の10種類のゴール

　この文に続くのが、以下のリストだ。

The design goals for XML are: XML shall be straightforwardly usable over the Internet. XML shall support a wide variety of applications. XML shall be compatible with SGML. It shall be easy to write programs which process XML documents. The number of optional features in XML is to be kept to the absolute minimum, ideally zero. XML documents should be human-legible and reasonably clear. The XML design should be prepared quickly. The design of XML shall be formal and concise. XML documents shall be easy to create. Terseness in XML markup is of minimal importance.

　ここは非常に興味深いので、すべての項目についてコメントしよう。

　1は、「XMLはインターネットでそのまま使えるべきである」としている。これは一見当たり前のようだが、そうではない。SGMLという技術は、もともとはインターネットのための技術として生まれたわけではない。ここではっきりとインターネットにフォーカスを向けるのだという意思表示には大きな意味がある。実際、インターネットで利用することを前提としたことで、XMLはSGMLとは異なる側面を持っている。例えば、仕様が難しいと利用してもらえない、というような考え方は、利用者が特殊な専門家ばかりのSGMLの世界とは違って、さまざまな多くの利用者がいるインターネットを意識しているといえるだろう。

　2は、「XMLは幅広いアプリケーションをサポートする」としている。これは、特定の狭い応用分野だけを目的としていないことを示している。例えば、XMLは企業間電子商取引のために生まれた、といった俗説が間違いであることは、この項目からも明らかだろう。XMLはさまざまな目的に使ってよいものであって、それを狭めてしまうことは、XMLの持つ潜在的な可能性を殺すことである。

　3は、「XMLはSGMLと互換性を持つべきである」としている。これは、いまとなってはあまり大きな意味はないだろう。しかしXMLが生まれる過程では、豊富なXML対応ソフトなどはなく、SGMLを処理するソフトにXML文書を通して使わねばならない状況もあったわけである。そういうときには大いに意味のある項目だったといえる。

　4は、「XML文書を処理するプログラムは容易に記述できる」としている。実際に、XML勧告が出るころには、何種類ものXMLパーサが公開されていた。XML文書を処理するプログラムが容易に記述できることは事実といってよい。しかし、これですら複雑すぎるという苦情が出ており、もっと単純化したいと考える者は多い。複雑高度化することが進歩だと思う人もいるかもしれないが、少なくともソフトウェアの世界ではそれは正しい理解とはいえない。人間が理解できないほど複雑にしても、結局誰にも使えなくなるだけである。それよりも、誰でも理解できるほど単純にした方が、利用者は増える。XMLがこれほど単純でなければ、これほどのブームにはなっていなかっただろう。しかし、世の中には、この事実を理解できない人も少なくはない。仕様を複雑高度化させて結局破たんさせてしまう事例は後を絶たない。さらに、理解していても、政治的な圧力に屈して意味のない機能を多数取り込まざるを得なくなり、仕様を複雑化してしまう事例もあるようだ。

■人間にとって読みやすいこと

　5は、「任意選択の機能は少ない方がよい、理想的にはゼロが望ましい」としている。相互に互換性のない複数のオプションが許されると、読み込むプログラムがどのオプションをサポートしているか、いちいち調べる必要が生じてしまう。もしXML文書を扱う場合に、文書の種類によって何種類ものXMLパーサを使い分ける必要があるとしたら、悪夢である。実際には、XMLには任意選択となっている部分がいくつかあるが、取りあえずUTF-16かUTF-8の文字コードで書いた整形式のXML文書なら、どのXML対応プログラムでも読み込めると期待することができる。これだけでも、かなり面倒が取り除かれているといえるだろう。

　6は、「XML文書は、人間にとって読みやすく、十分に理解しやすいことが望ましい」としている。これは、SGMLをやってきた人、あるいは、UNIX（もしくはそれに関連したツール）でテキストのフィルタ処理でデータを処理してきた人には分かるかもしれないが、リレーショナル・データベースを使ってきた人には分かりにくいかもしれない。普通のデータベースの世界では、高速化、信頼性向上などのために、データは特殊なフォーマットでファイルに格納され、それを人間が直接見てもよく分からない場合が多い。しかし、XMLは効率が悪いとしても、人間が読める方向を選択している。XMLはテキストなので効率が悪いのが弱点だという人もいるが、実際には効率よりも、人間が読みやすいことを重視して目標に掲げているというのが事実だ。効率を重視すべきか、人間が見て分かりやすい方がよいか、これは目的によって異なるもので、一概にどちらが正しいともいえない。ただ、コンピュータの性能向上により、多少の効率の悪さは問題ではなくなってきているので、読みやすさ重視も一理ある選択ではないだろうか？ もっとも、データ量が多く、この程度の性能向上では焼け石に水という分野も多いので、何でもXMLを使えば済むという状況にはなっていないが……。

　7は、「XMLの設計は，速やかに行うことが望ましい」としている。これは、XMLそのものに対する目標というよりも、XML仕様を作成するプロセスに対する要望といえる。どんな仕様であろうと、それが必要とされている時期を外したら何の意味もない。必要なときに必要なものを提供するためには、素早さも必要である。「拙速は巧遅に如（し）かず」という言葉もあるが、完全無欠な優れた仕様を作ろうとして無限に議論を繰り返すことは、徒労に終わることが多い。役に立てば問題が残ってもよい、として先に進める方がよいことも珍しくない。実際、XMLにも問題は含まれているが、XMLがまだ生まれていない状況と比べれば、XMLを利用できるいまの方がずっとマシである。

■XMLの設計は厳密で簡潔に

　8は、「XMLの設計は、厳密で簡潔なものとする」としている。厳密さというものは、コミュニケーションの基盤となる仕様では重要なものである。例えばある仕様に基づいた2つのプログラムが別々に作られたとして、解釈にあいまいさが残ると相互に通信できない恐れがある。そのような危険を少しでも取り除くには、厳密さは重要な要素である。そして、簡潔さは理解しやすく、誤解を入り込みにくくする。これも、確実なコミュニケーションにはプラスの要素である。それだけでなく、簡潔であればすぐに理解することができるので、多くの人が使ってくれる可能性があるというメリットもあるだろう。

　9は、「XML文書は簡単に作成できるべきだ」としている。実際に、わずかな解説と、Windows付属のメモ帳程度のエディタがあれば、簡単なXML文書を作り出すことは難しくない。プログラムからXML文書を生成する場合でも、文法に沿って文字列を出力していくだけでよいので楽なものである。複雑な構造は要求されていないので、少しのルールを飲み込めば、簡単に記述することができる。複雑で大きな専用プログラムが必要だとすれば、こんなに手軽にXMLが普及することはなかっただろう。

　10は、「マーク付けの数を減らすことは重要ではない」としている。

<輸送><発送元>太郎</発送元><発送先>花子</発送先></輸送>

のようなXML文書を見ると、もっと効率よく短く書けると思って方法を考える人もいるが、短くすることがよいとは限らない。仕様の簡潔さと人間が読んだときの分かりやすさなどのためには、無理に短くしない方がよいかもしれない。また、コンピュータの性能向上のおかげで、1文字を削ってデータ量を減らす努力が無意味になってきたということもあるだろう。例えば、SGMLの世界には終了タグの省略という機能もあったが、XMLにはないので、XMLではSGML時代よりもマーク付けは増えているといえるだろう。だが、それでもよいというのがXMLの前提である。

■勧告は自由に配布してよい

　1.1の最後は次のような文で締めくくられる。

This specification, together with associated standards (Unicode and ISO/IEC 10646 for characters, Internet RFC 1766 for language identification tags, ISO 639 for language name codes, and ISO 3166 for country name codes), provides all the information necessary to understand XML Version 1.0 and construct computer programs to process it.

　ここでは、この仕様書を理解するために必要な情報について述べられている。このXML勧告自身が必要であるのはもちろんとして、文字に関しては、UnicodeとISO/IEC 10646を参照する。Unicodeとは、Unicodeの仕様書がUnicodeコンソーシアムのサイトにも掲載されているので、読むことができる。もちろん、中身は英文である。また、ISO/IEC 10646はまさにISO/IEC規格の名前なので、それに該当する規格書、正確にはISO/IEC 10646-1:2000を参照する。日本では、JIS X 0221-1:2001として日本語訳が出ているので、それを入手してもよい。

　次に、言語識別タグについてはIETF RFC 3066、言語コードについてはISO 639、ならびに国名コードについてはISO 3166が参照されていることが示されている。RFC 3066はIETFのサイトにある。ISO 639は日本ではJIS X 0304という規格になっている。ISO 3166はJIS規格がないので、ISO規格を読むしかない。

This version of the XML specification may be distributed freely, as long as all text and legal notices remain intact.

　「このバージョンのXML仕様は、テキストおよび法律上の注意を一切改変しない限り、自由に配布してよい」。つまり、このW3Cにある英文のドキュメントに関しては、そのまま丸ごと自分でコピーして配ってもよいし、自分のWebサイトに掲載してもよい。しかし、この規定は日本語訳のJIS規格にまでは適用されないようで、これほど自由に扱うことはできない。例えば、この連載にJIS規格の全文を転載するようなことはできないそうである（編集注）。このあたりは、制約の多い日本のお役所仕事というものだろう。このような標準仕様は、どんどん使ってもらってこそ、国家の発展に役立つというものである。

編集注：この連載に当たり、JIS規格の転載を経済産業省基準認証政策課に問い合わせたところ、著作権上の制約により転載の許可が得られませんでした。

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

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