第1回　XMLの仕様書によると、XMLの目標とは……

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

川俣 晶
株式会社ピーデー
2002/9/5


■XML 1.0をみんなで読もう

今回の主な内容 XML 1.0をみんなで読もう XMLの仕様書とは？ 仕様書の名前を読む バージョンと日付と著作権表示 XMLはSGMLのサブセット SGMLについて SGMLの本質は継承された XMLの目標 この文書のステータスは 目次を読む

　そこのあなた！ 間違って難しい記事を開いてしまったと思って立ち去ろうとしたそこのあなた！ あなたは間違ってなどいない。この記事は難しい記事ではないのだ。「XMLの仕様書は読んでみたいが、でも難しそう」と考えるあなたのような人のために書かれたのが、この記事なのである。

　XMLとは、いうまでもなく、いまちょっとはやりの拡張可能なマーク付け言語（Extensible Markup Language）のことである。そしてこの連載で読もうとしているのは、XMLを定義している仕様書そのものだ。しかし、そんなの面倒だ、分かりやすい入門書を読むから必要ない、などと思った人がいると思う。それは正しい判断ではない。仕様書には、どんなに優れた入門書や解説書でも置き換えられない大きな価値がある。それは、仕様書に書かれたことは、常に正しいということだ。後に正誤表が出て訂正される場合もあるが、そうでなければ、仕様書に書かれたことは正しい。仕様書は、正しさの基準になるために記述されるからだ。もし、解説書や入門書と仕様書の間に食い違いがあれば、仕様書の方が正しいのである。

　もちろん、現実の世界は正しいことがいつも通るとは限らない。時として、仕様とは異なる動作のプログラムを作らねばならないこともある。しかし、それでも何が正しいのかを把握しておく必要はある。もちろん、XMLの仕様書を読む理由は仕事上の必要性だけではない。仕様書を読むということは、その仕様を作成した人たちの、より生に近い意見に接するということである。どんな背景があり、何を目的に仕様を作るに至ったのか、その雰囲気が文章の行間からにじみ出てくるのが仕様書というものである。それを読むことで、少しでもその雰囲気に触れれば、より仕様が意図した使い方に沿って使えるようになるだろう。つまり、技術を効率よく、快適に使えるようになるわけである。

　さて、そうはいっても仕様書を読むのは難しいし、そのうえ雰囲気まで読み取れるほど読み込むのは大変という意見もあるだろう。それは一面として正しい。仕様書には独特の書き方があり、それを読むことに慣れていないと、どこから手を付けてよいか分からない場合もあるだろう。だが、その点は心配無用だ。なぜなら、この連載では、筆者が仕様書の文章をすべて解説していくからだ。仕様書が難しくても筆者の解説文で補えば一緒に読んでいくのに十分である。

■XMLの仕様書とは？

　では、XMLの仕様書とはどこにあるのだろうか。XMLはご存じのようにWorld Wide Web Consorium（W3C）によって1998年に勧告されており、XMLの仕様書はW3CのWebサイトで公開されている。つまり、XMLの仕様書はだれでも無料で読むことができるのだ。

　なお、本連載では、2000年10月のXML 1.0勧告の第2版「Extensible Markup Language (XML) 1.0 (Second Edition) W3C Recommendation 6 October 2000」および、この日本語訳である日本工業規格 JIS X 4159:2002 拡張可能なマーク付け言語 (XML)を基にして解説を行う。ただし、日本工業規格の方の仕様書は、残念ながら書籍として入手する必要があるため、だれでも簡単に参照できる、というわけにはいかないようだ。本連載では、W3Cの方を「W3C版」もしくは「英語版」と呼び、JISの方を「JIS版」もしくは「日本語版」と呼ぶことにする。

　では、XMLの仕様書を一緒に読んでいくことにしよう。

XML 1.0第2版のWebページ。今回対象とするのがこのページだ

　

■仕様書の名前を読む

　仕様書の先頭はもちろんタイトルである（仕様書タイトルへのリンク）。本家W3Cの英語版のタイトルはこうなっている。

Extensible Markup Language (XML) 1.0 (Second Edition)

　一方のJIS版は以下のようになっている。

日本工業規格 JIS X 4159:2002 拡張可能なマーク付け言語 (XML) Extensible Markup Language (XML)1.0

　まずW3C版を見てみよう。タイトルは「XML」ではなく、「Extensible Markup Language」であって、その後にカッコ付きでXMLが付記されていることが分かるだろう。つまり、一般にXMLと呼ばれているものの正式名称はExtensible Markup Languageであって、XMLではない。しかし、カッコ付きでもタイトルに登場する以上、XMLも間違った名前というわけではない。XMLを説明するためにXMLという言葉を使ってもよいが、正式なものを要求される場合は、Extensible Markup Languageと書く方がよい。ところで、よくeXtensible Markup Languageと最初の単語のXを大文字に表記する人がいるが、これは間違いである。見てのとおり、Eが大文字になる。それなのに、略称はEMLではなくXMLになるのは不思議なことだが、ともかくそういうものだと思うしかないぐらいXMLという名前は浸透してしまっている。

　JIS版の方は、Extensible Markup Languageを「拡張可能なマーク付け言語」と訳している。これが日本語として分かりやすい名前かどうか異論はあるが、JISにはJISの翻訳の流儀があるため、こうなっている。JISでは英語をそのままカタカナにせず、なるべく日本語にするという方針があるそうで、そのおかげで「マークアップ言語」と書くことは許されず、「マーク付け言語」と書かねばならないらしい。本当ならマークも日本語にしたいところだろうが、そこまでは徹底されていない。というわけで、この記事中でもこの先、「それは片仮名で書いた方が分かりやすいのではないか？」と思われる用語が出てくることがあるが、それはJISの流儀に従ってのことなのである。

　それなら、読みにくいJIS版の日本語訳など使わず、もっとほかの日本語訳を使えばよいではないかと思う人もいると思う。だが、用語に偏りがあるとしても、JIS版は、W3CでXMLの仕様を作成した委員の1人である村田真氏も携わり、チェックしているものである。最も安心感がある日本語版だろうということで、これを採用した。

　さて、JIS版には「JIS X 4159:2002」という番号が振られているが、これはJISつまり日本工業規格の番号であり、W3C版には存在しない、日本独自の番号である。この番号を知っていると、本屋でこの規格書を発注できる。番号の読み方を説明しておこう。最初の「JIS」はよいとして、その次のXは、情報関係を示す符号、4159はXMLに対して与えられた固有の番号である。つまり、JISのXの4159といえば、必ずXMLになる。規格書を買うときは、「XML」や「拡張可能なマーク付け言語」といって発注するよりも、「JISのXの4159」と指定する方が話が早い可能性がある。最後の「:2002」とは、2002年に発行されたことを示す。この手の規格は時代の変化に対応して改訂されるが、どの年度の版かを判定するために、年度表記が付加される。例えば、2005年にこれが改訂されるなら、「:2002」は「:2005」に変化することになる。

■バージョンと日付と著作権表示

　W3C版には、タイトルの下に以下のような表記が付加されている。

W3C Recommendation 6 October 2000 This version: http://www.w3.org/TR/2000/REC-xml-20001006 (XHTML, XML, PDF, XHTML review version with color-coded revision indicators) Latest version: http://www.w3.org/TR/REC-xml Previous versions: http://www.w3.org/TR/2000/WD-xml-2e-20000814 http://www.w3.org/TR/1998/REC-xml-19980210 Editors: Tim Bray, Textuality and Netscape <tbray@textuality.com> Jean Paoli, Microsoft <jeanpa@microsoft.com> C. M. Sperberg-McQueen, University of Illinois at Chicago and Text Encoding Initiative <cmsmcq@uic.edu> Eve Maler, Sun Microsystems, Inc. <eve.maler@east.sun.com> - Second Edition Copyright © 2000 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.

　最初の「W3C Recommendation 6 October 2000」とは、W3C勧告になった日付を示す。新しい仕様かどうかは、この日付で確認できる。JIS版では先ほど説明したように、番号に付加される年度（:2002）で新旧を区別できるが、W3C版は年度だけでなく日付まで入る。おそらく、更新する頻度が「ドッグイヤー」ともいわれるインターネットの標準を扱うW3Cの方が高いためだと思う。

　その下の「This version:」は、この版のオリジナルが置かれている場所を示している。仕様書をダウンロードして読んでいるときでも、このリンクがオリジナルへと戻る道を常に示しているわけである。その下の「Latest version:」は、この仕様の最新版のありかを示している。仮にXMLのバージョン1.1や3rd Editionなどが生まれた場合でも、このリンクをたどれば最新版にたどり着けるはずである。その下の「Previous versions:」は1つ前のバージョンへのリンクを示す。ここでは、Second Editionの最後のドラフトと第一版（First Edition）へのリンクが張られている。めったにないことだが、第1版との相違を確認したい場合に利用できる。

　その下には、「Editors:」という項目があるが、これはこの仕様書を作成した編集担当者の名前を記した部分である。最後の行に「- Second Edition」という表記があるが、これはこの行に記されたEve Malerという人物がSecond Editionの編集を行ったということである。XMLを利用する際は、ここに記されたTim Bray、Jean Paoli、C. M. Sperberg-McQueen、Eve Malerの名前ぐらいは覚えておき、「ありがとう」と心の中で感謝をささげると、ちょっとだけ気持ちがよくなるかもしれない。なお、これが仕様の作成に携わったすべての人たちというわけではない。「Appendix G W3C XML Working Group」や「Appendix H W3C XML Core Group」にも多くの名前が記載されている。彼らの名前をすべて覚える必要はないが、感謝の気持ちを持って悪い理由は何もない。

　その下には、著作権表記がある。「MIT」はMIT Laboratory for Computer Science、「INRIA」はTHE FRENCH NATIONAL INSTITUTE FOR RESEARCH IN COMPUTER SCIENCE AND CONTROL、「Keio」は慶応義塾大学を意味する。W3Cの文書は自由に配布して使うことができるが、それはこれらの著作権者が、そういう自由を定めたから可能になっているものである。決して著作権のない文書ではないことに注意が必要である。

■XMLはSGMLのサブセット

　W3C版には著作権表記の下に「Abstract」（要約）が記述されている（Abstractへのリンク）。日本では要約の意義が分からない人もちらほら見られるが、自分が読む必要のある文書とそうではない文書を素早く区別するには、要約は非常に役に立つものである。日本でも、もっといろいろな文書に要約が付くと分かりやすいのだが、JIS版ではこの部分が削除されてしまっている。

Abstract The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document. Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. XML has been designed for ease of implementation and for interoperability with both SGML and HTML.

　ここでいっていることは、それほど複雑ではない。まず、XMLはSGMLのサブセットであり、XMLの仕様全体がこの文書に記述されていると書かれている。XMLの全貌は、この文書を読めば分かるということであり、XMLを理解するためにSGMLを勉強する必要はないことが分かる。しかし、ここで1つ問題がある。それは、このAbstractに限れば、SGMLが何かを知らずにこの文章を理解することは難しいということだ。さらに、SGMLのほかに言及されているHTMLやWebも理解していないと、この文章は理解できないだろう。

　さすがに、＠ITの読者ならWebとHTMLは分かると思うので、これについて説明することは割愛しよう。だが、SGMLを知らない人は少数派ではないと思うので、これについては説明しよう。

■SGMLについて

　SGMLとは、Standard Generalized Markup Languageの略で、主に文書を記述するためのメタ言語である。ISOやJISの規格にもなった権威ある言語である。ISO 8879-1986 Information processing -- Text and Office Systems -- Standard Generalized Markup Language (SGML)とJIS X 4151-1992 文書記述言語SGMLがこれに当たる。しかし、いまひとつ幅広く普及しなかったのも事実である。

　SGMLは主に文書を扱うメタ言語である。メタ言語とは言語を作る言語である。文書を扱うといえばワープロが頭に浮かぶ読者も多いと思うが、SGMLとワープロはかなりかけ離れた存在である。ワープロがすでにあるのに、なぜSGMLが生まれる必要があったのだろうか？ しかも、わざわざメタ言語などという難しいものを持ち出す必要があったのだろうか？

　その答えは、一部の利用者にとってワープロは必ずしも便利ではないという事実にある。ワープロとは清書装置であって、紙にきれいに印刷できることが最大のポイントになる。最近、紙に印刷せずに電子媒体で文書を保存したり、配布することもニーズとして浮上してきたが、基本は印刷である。

　しかし、印刷のために使用されるプリンタは時代の変化とともに機能が変化していく。例えば、1980年代には文字の大きさは自由に調整できず、大きい文字を表示するにはちょうど横幅が2倍になる倍角文字というものが使われていた。しかし、現在のプリンタはアウトラインフォントを印刷することができ、文字の大きさは2倍に限定されず、どんな大きさも印刷できる。このような変化に伴い、昔の文書ファイルを印刷しようとしても同じ書式指定ではきれいに印刷できない場合がある。また、ニーズの変化に伴いワープロソフトもバージョンアップする。古いワープロソフトの文書ファイルが最新ワープロソフトで開けるかどうか分からないし、開けたとしても、書式が正しく再現できる保証はない。さらに、文書を長期保存するような組織は必然的に膨大な数の文書を扱うことになるが、大量になれば目的の文書を探し出すことが困難になってくる。コンピュータなら検索機能が利用できるが、ワープロソフトの文書ファイルは検索ソフトがうまく検索できない場合があり、また、検索できるとしても、単なる文字列検索ぐらいで、意味と無関係に見た目が似た文字列はすべてヒットしてしまい、なかなか目的の文書を絞り込めない場合がある。

　このような状況に対処するために生まれてきたのがSGMLである。SGMLでは、文書の構造と表現を分離することで、これらの問題に対処しようとした。つまり、倍角文字を指定する代わりに、見出しというタグを付けようということである。タグ付けされた文書ファイルは、単なるテキストファイルなので、時代が変化しても読めなくなる心配はない。最悪でも、単なるテキストファイルとして読めるのである。そして、タグで表記される要素や属性に対応する表現は、時代ごとにスタイルシートを作成して指定すればよい。その時代ごとに標準的な表現手段をスタイルシートで対応づければ、表現方法が変化しても文書ファイルは有意義に活用することができる。さらに、タグ付けにより、検索の精度も上がる。例えば、文書の作成日を示すタグを参照しながら検索すれば、特定の日付に作成された文書ファイルを探すのも容易である。たまたま同じ日付を示す文字列が本文中に入っていても、きちんと区別することができる。このような使い方のメリットを甘受するには、タグの種類は業務やニーズごとに変えていかねばならない。タグが変わるということは、いい換えれば別の言語、フォーマットを使うということである。つまり、業務やニーズごとに言語を作る必要が生じるので、それを手軽に行うために言語を作る言語、つまりメタ言語が必要とされるわけである。

　ここで、注意が必要なのは、インターネットという場を得た現在のわれわれにとって、こういうニーズは特殊なものではなくなってしまったという事実である。つまり、インターネットという場そのものが、古い文書も新しい文書もあり、膨大な数の文書が蓄積され、しかも検索しなければ情報を有意義に活用できない場であるということである。まさに、SGMLの提供する能力と、インターネットユーザーのニーズは合致しているといえる。

　その割にSGMLなんて使われていない、と思うのは早計である。なぜなら、インターネット上で主に使用されているコンテンツ記述言語のHTMLは、SGMLを用いて作られた言語だからだ。その意味で、われわれは大いにSGMLの恩恵を受けているはずなのだ。

　しかし、本当の意味でSGMLの恩恵を受けているかというと、残念ながらそうではない。結局のところ、構造と表現の分離というSGML的な考え方をまったく知らない多数のWebデザイナーが、この2つが分離されていない膨大なHTML文書を作成し続けている。例えば文字のサイズを変更するのに、本来見出しを表現するためのH要素を使った文書が多数あり、見出しの文字だけを検索する機能を実現しても見出し以外の文字を多数検索してしまう状況に陥っている。その結果、現在の検索エンジンは、あらかじめ用意されたSGML的な検索の手掛かりを使わず、さまざまな高度で複雑な工夫を凝らして、検索結果の向上を実現している。本来なら、もっと単純に、より良い検索が実現できたはずなのだが、ひどく無駄な回り道を強要されているのである。

■SGMLの本質は継承された

　さて、SGMLはCALSで利用されたため、電子商取引用言語と思われることもあるが、これはまったくの誤解といえる。SGMLは、文書のための言語であって、電子商取引のために作られた言語ではない。そこから考えれば、XMLが電子商取引用の言語ではないことも明らかだろう。電子商取引にXMLが利用されることがあるにせよ、それはXMLの多くの利用分野の1つが電子商取引であるということでしかない。またXMLがデータベースの内容の交換言語である、というような主張をする人もいるが、このような主張が聞かれるようになったのはXMLが生まれた後であり、データベースの交換言語としてXMLが生まれたということはない。XMLは、もっと複雑でデリケートな問題を解決するために生まれたSGMLの後継言語である。

　ここでSGMLに関して特に注目していただきたいのは、構造と表現の分離と、DTDによって文書の構造を定義するという2点である。この2つは、XMLにも明確に継承されている。サブセットとして一部の機能が削られているとはいえ、本質は継承されているのである。例えば、何かの情報を保存して通信するためにXMLを使うことはできる。しかし、XMLが持っているポテンシャルは単に情報を保存する、通信するだけに限定されるものではない、ということである。

　余談だが、いったいどんな機能がSGMLにあって、XMLにないのだろうか？ 例えば、SGMLでは特定環境に依存する文字を定義して参照する機能がある。SGMLは特定の文字コード系に限定されないので、事実上システム側で用意すれば無制限の種類の文字が使用できる。しかし、開かれたネットワークで通信する場合、どんな文字でも使えることは無制限のコストアップになりかねないので、XMLでは文字はUnicode/ISO 10646に存在するものしか使用できないように制限されている。このためXMLは安価に運用でき、現実のシステムに導入可能となっているのである。SGMLからXMLへの機能の減少は、より安価に現実的に運用可能にするためのものが多い。その意味で、サブセットにするということは、健康のためにダイエットするようなものだといえる。決して、太ったSGMLの方が強力であるとは限らない。筆者は、すでにSGMLを新たに学ぶ必要性は、既存のSGMLシステムに携わる場合を除き、特になくなったと考えている。

■XMLの目標

　さてAbstractの本文に戻ろう。次には、XMLの目標は、任意のSGML文書を、HTMLがWebで行っているように配布、受信、処理できるようにすることだと書かれている。ここは少し表現があいまいかも知れない。SGML文書とXML文書は、定義がイコールにならない場合があり、SGML文書を通信、処理する手段がXMLである、といってしまうと誤解を招く恐れがある。より正確にいえば、ここでいうSGML文書は、XMLの仕様に沿って制限されたサブセットのSGML文書のことであり、それはXML文書と等価であると考えるとよいかもしれない。

　ただし、SGML側にも、XMLと互換性のあるSGMLの亜種を作成するなどの動きがあるので、このあたりの意味は流動的であり悩ましい。取りあえず、SGMLとかかわる必要のない人たちは、SGMLのことは頭から追い出して、XMLのことだけを考える方が分かりやすいかもしれない。

　Abstractの次には、XMLはSGMLやHTMLと容易に相互運用でき、実装できるように設計された、と述べられている。もし、XMLがSGMLの単なるサブセットであれば、相互運用できるのは当たり前といえる。当たり前であるはずのことをわざわざ書いているということは、実は、暗にXMLがSGMLの機能を単純に削ったものではないことを示している。例えば、空要素タグを記述するために、SGMLでは<name>のように記述するがXMLでは、<name/>と記述するといった差異があり、単に仕様書の一部を削っただけのものにはなっていない。さらに、HTMLとなると、もっと話は壮絶になる。要するに、XMLでHTML相当の言語を作成し（つまりXHTMLのこと）、これで記述したコンテンツが、既存のWebブラウザで表示できなければならないということなのである。このような配慮をきちんと検証したうえでXMLは生まれてきたのである。そして、それが成功したことはXHTML文書をHTML対応のWebブラウザで表示できていることが証明している。

■この文書のステータスは

　概要の次にはStatus of this Documentという項目がある（Status of this Documentへのリンク）。ここで述べられていることは、主に手続き的な話なので、W3Cの手続きに興味がある人以外は斜めに読んでも構わないだろう。JIS版にはこの部分の日本語訳は存在しない。

Status of this Document This document has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

　ここでは以下のことが述べられている。W3Cのメンバーなどによって査読され、W3Cの勧告になったということ。ほかの文書から参照できるだけの十分な安定度を持っていること。そして、W3Cの役割は、この仕様を広く知らせ、普及させることであるという。このことが、Webの機能と相互運用性を拡大するという。

（Status of this Documentの続き） This document specifies a syntax created by subsetting an existing, widely used international text processing standard (Standard Generalized Markup Language, ISO 8879:1986(E) as amended and corrected) for use on the World Wide Web. It is a product of the W3C XML Activity, details of which can be found at http://www.w3.org/XML. The English version of this specification is the only normative version. However, for translations of this document, see http://www.w3.org/XML/#trans. A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.

　Status of this Documentの続きである。ここではまず、World Wide Webで使用するためにSGMLのサブセットとして作成された仕様であることが書かれている。そして、W3CのXML活動の成果であるとしている。

　その次は、この仕様は英語版だけが規範となることが示されている。つまり、もし各言語に翻訳された版との間に内容の食い違いがあった場合、英語版の記述が正しいものとされる。これは、場合によっては悩ましい問題を引き起こす可能性がある。例えば、官庁では調達時にJIS規格に従うことがあるが、もし、日本語に翻訳されたJIS版のXML仕様と、W3Cの英語版のXML仕様に食い違いがあった場合、JIS版に従わねば納入を許さない、という主張もあり得るのである。しかし、このような主張がまかり通れば、XMLの相互運用性を損ない、XMLを使うメリットをも殺すことになる。XMLは世界で1つであり、JIS版のXMLはW3C版のXMLと完全に一致するものとして扱う必要がある。もし、何か重大な食い違いが生じた場合は、JIS版の方に正誤表を付けて、一致するように維持しなければならない。これは、ほかの多くの翻訳された国際規格でも同じことが言える。仕様書の解説に戻ると、この段落の最後には、W3Cの勧告の一覧表が得られるURIが紹介されている。

（Status of this Documentの続き） This second edition is not a new version of XML (first published 10 February 1998); it merely incorporates the changes dictated by the first-edition errata (available at http://www.w3.org/XML/xml-19980210-errata) as a convenience to readers. The errata list for this second edition is available at http://www.w3.org/XML/xml-V10-2e-errata.

　この段落では、このsecond editionがXMLの新しい版ではないことを説明している。second editionは、読者の便宜のために最初に公開されたXML 1.0勧告に正誤表を適用したものである。そして、最初の版に対する正誤表、つまりsecond editionに反映済みの正誤表と、second editionに対する正誤表のURIが示されている。すでにsecond editionの間違いも多く発見されていることに注意が必要である。この種の仕様書は、厳密な定義を書き下ろしているから間違いなど入り込むわけがないと思っている人もいるが、実はそうでもない。確かに構文などは、あいまいさを排除した人工言語（この連載で後で取り上げるEBNFなど）で表現できるが、それでは表現できない情報も多く、英語や日本語などの自然言語も多く使われる。自然言語は、あいまいさを含むので、どうしても間違いが入り込むすきが生じる。さらに、人工言語なら間違いは絶対に入らないのかというと、そんなことはない。例えば、プログラム言語も人工言語の一種だが、プログラム言語で記述されたソースコードにバグが入り込むのはよくあることである。

■目次を読む

　次は目次が続いている（Table of Contentsへのリンク）。目次はうっかりすると読み飛ばしてしまいそうだが、いろいろ有益な情報を含んでいる。特に、この仕様書に何が書いてあるのかを、短く要約した文章であると見ることができる。

Table of Contents 1 Introduction     1.1 Origin and Goals     1.2 Terminology 2 Documents     2.1 Well-Formed XML Documents     2.2 Characters     2.3 Common Syntactic Constructs     2.4 Character Data and Markup     2.5 Comments     2.6 Processing Instructions     2.7 CDATA Sections     2.8 Prolog and Document Type Declaration     2.9 Standalone Document Declaration     2.10 White Space Handling     2.11 End-of-Line Handling     2.12 Language Identification 3 Logical Structures     3.1 Start-Tags, End-Tags, and Empty-Element Tags     3.2 Element Type Declarations         3.2.1 Element Content         3.2.2 Mixed Content     3.3 Attribute-List Declarations         3.3.1 Attribute Types         3.3.2 Attribute Defaults         3.3.3 Attribute-Value Normalization     3.4 Conditional Sections 4 Physical Structures     4.1 Character and Entity References     4.2 Entity Declarations         4.2.1 Internal Entities         4.2.2 External Entities     4.3 Parsed Entities         4.3.1 The Text Declaration         4.3.2 Well-Formed Parsed Entities         4.3.3 Character Encoding in Entities     4.4 XML Processor Treatment of Entities and References         4.4.1 Not Recognized         4.4.2 Included         4.4.3 Included If Validating         4.4.4 Forbidden         4.4.5 Included in Literal         4.4.6 Notify         4.4.7 Bypassed         4.4.8 Included as PE     4.5 Construction of Internal Entity Replacement Text     4.6 Predefined Entities     4.7 Notation Declarations     4.8 Document Entity 5 Conformance     5.1 Validating and Non-Validating Processors     5.2 Using XML Processors 6 Notation Appendices A References     A.1 Normative References     A.2 Other References B Character Classes C XML and SGML (Non-Normative) D Expansion of Entity and Character References (Non-Normative) E Deterministic Content Models (Non-Normative) F Autodetection of Character Encodings (Non-Normative)     F.1 Detection Without External Encoding Information     F.2 Priorities in the Presence of External Encoding Information G W3C XML Working Group (Non-Normative) H W3C XML Core Group (Non-Normative) I Production Notes (Non-Normative)

　「1 Introduction」は形式的に存在するものなので、特にこの文書独自の構造というわけではない。しかし、「2 Documents」「3 Logical Structures」「4 Physical Structures」の部分は注目する価値がある。つまり、この仕様書の主要な部分は、文書、論理構造、物理構造という3つの構成要素に分けられるのである。このことはXMLが、ただ単に文字列を開始タグと終了タグで囲めば済むような単純な構造ではないことを示している。初心者向けの解説では、よく開始タグと終了タグで囲むだけ、といった説明が行われるし、筆者もそういうことを書いたことがある。しかしそれは入門者の最初の1歩の敷居を低くするための説明であって、本格的にXMLを使おうとする者は、より深い知識を必要とする。特に、ここで論理構造という大きな項目があることから、文書の見掛けよりも抽象レベルの高い構造があることに気付かねばならない。また、文書と物理構造が別々に説明されていることから、構造の定義と、文書の記述は別個の問題として扱われていることに気付かねばならない。そういうことに目次を見て気付いておけば、実際に本文を読むときに分かりやすくなるはずである。

　さて、残った目次は「5 Conformance」「6 Notation」「Appendices」である。「5 Conformance」はこの仕様が適合する適合性の条件について記述されている。「6 Notation」にはこの仕様書で使用されているEBNFという言語の定義について記されている。「Appendices」には本文に収まらなかったさまざまな情報が並んでいる。

　ここで注意が必要なのが、「6 Notation」である。普通は、先頭から順に読んでいけば仕様は理解できると考えるだろうが、実際には本文で使用されているEBNFの定義が本文の最後の「6 Notation」に記述されているのである。もし、EBNFが読める人なら最初から読んでもよいが、そうでなければ「6 Notation」から読み始めた方がよいかもしれない。

　実際に次回は、「6 Notation」とEBNFに取り組んでみようと考えている。次回へ続く。

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

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