XML仕様書の構造と読み方：XMLを学ぼう（最終回）

この連載「XMLを学ぼう」も今回でちょうど1年となり、最終回となる。これまでXMLの仕様について解説を続けてきたが、今回はそれらの最後のまとめを行うとともに、連載の中で取り上げていなかった幾つかの小トピックについても触れる。

» 2001年04月28日 00時00分公開

[川俣晶，株式会社ピーデー]

XMLの仕様について考える

　さて、XMLの仕様とは、W3Cから公開されているExtensible Markup Language (XML) 1.0のことを意味する。しかし、現在利用されているXMLでは名前空間が不可欠な機能であるため、名前空間に関する仕様を定めるNamespaces in XMLもXMLの仕様の一部と考えられる。名前空間も仕様のうちと考えるなら、名前空間を明示的に扱えるスキーマ言語が必要とされるが、DTDはその機能を欠いている。そこで、DTDに代わる新しいスキーマ言語（XML SchemaやRELAX）もXMLの仕様の一部と見なしたいところだ。しかしスキーマ言語においては今後の主流がどうなるのか、状況が不透明であるため、この連載の範囲からは外していた。RELAXのISOにおける標準化が進み、XML Schemaが勧告となり、さらに業界の主流が確定すれば、そういったものがXMLの仕様の事実上の一部として利用されていくだろう。だが、ここではDTD以外のスキーマ言語そのものは解説の範囲外とする。

■では、XMLの仕様に含まれる項目とは？

　では、XMLの仕様に含まれる具体的な項目とは何だろうか。大きく分けると、XML文書の情報本体を記述するための規定、外部実体を記述するための規定、DTDを記述するための規定の3つに分かれる。

　手っ取り早くXMLに入門したい場合には、最初の、XML文書の情報本体を記述するための規定だけを学べばよい。つまり、XML宣言と要素、属性の書き方が分かれば、とりあえずXML文書を書いてみることができる。これだけでも立派なXML文書（整形式のXML文書）として成立する。

　だが、不特定多数者間でXML文書による情報交換を行うようになると、異常なXML文書を拒絶するすべを持たないようでは、実用的とはいえない。そこで、DTDの知識が必要となってくる。しかしすでに述べたように、DTDは近い将来、もっと新しいスキーマ言語と置き換えられていき、要素や属性の並び方の妥当性をチェックするためにDTDを利用することは、今後減っていくと予想される。だが、そのことは、DTDを学ばなくてよいということを意味しない。なぜなら、DTDにはスキーマ言語としての側面のほかに、一種のマクロ定義や外部参照の機能も含まれる。つまり、実体に関する定義は、本質的な意味でのスキーマ言語の役割とはやや異なるものだということだ。実際に、整形式のXML文書とはDTDを一切扱わない文書を意味するわけではなく、DTDの中でも実体は処理されるのである。

　以下は合法的な整形式(well-formed)のXML文書の一例である。

　<?xml version="1.0"?>
　<!DOCTYPE doc [
　<!ENTITY myname "寿限無、寿限無……">
　]>
　<doc>私の名前は&myname;です。</doc>

　このことから分かるとおり、妥当なXML文書（DTDによる検証が行われるXML文書）だけでなく、整形式のXML文書（DTDによる検証を行わないXML文書）であっても、実体を使用することは可能であるし、実体を宣言するためにはDTDの構文を使用する。そのため、スキーマ言語としてのDTDは使わないと決まっている場合でも、DTDをまったく知らずには済まされない。

　以上をまとめて、XML仕様の中に含まれる機能を分類すると、以下のようになる。

XML文書の情報本体を記述するための規定
外部実体を記述するための規定
実体に関するDTDを記述するための規定
要素や属性に関するDTDを記述するための規定

DTDと新しいスキーマ言語

　新しいスキーマ言語では、実体の宣言に関してどのような方針を取っているのだろうか？ DTDを置き換えるためのスキーマ言語であれば、DTDの持つすべての機能を持っていることが当たり前のように思えるかもしれない。だが、それは正しい認識ではない。なぜなら、スキーマの処理を必要としない整形式のXML文書に関しては、スキーマ言語の種類に関係なく有効でなければならないためだ。つまり、どんなXML処理ソフトであろうと、少なくとも整形式のXML文書で利用される可能性のあるDTDの機能は実装されているはずであり、XML 1.0がXML 1.0であり続ける限り、それが変化することはないのである。

　逆に、新しいスキーマ言語がどのような機能を規定しようと、それは既存のXML処理ソフトで有効になるわけではない。ということは、新しいスキーマ言語が置き換えるのは、前述の4つの機能のうち、要素や属性に関するDTDを記述するための規定だけであり、実体に関するDTDを記述するための規定に関しては、新しいスキーマ言語が生まれたとしても、DTDの機能が使われ続けることになる。少なくとも、XMLがXML 1.0としてこれまでのXML処理ソフトとの互換を保ったまま進む限り、この事実が変化することはないだろう。

XML 1.0の設計目標

　XML 1.0勧告では、最初にXMLの設計目標が掲げられている。XMLの全体像を一通り見たいま、これをあらためて熟読する価値がある。以下にそれを引用する。

XMLは、インターネット上でそのまま使用できる
XMLは、広範囲のアプリケーションを支援する
XMLは、SGMLと互換性を持つ
XML文書を処理するプログラムは容易に書ける
XMLでは、オプションの機能はできるだけ少なくし、理想的には1つも存在しない
XML文書は、人間にとって読みやすく、十分に理解しやすい
XMLの設計は、すみやかに行う
XMLの設計は、厳密で、しかも簡潔なものとする
XML文書は、容易に作成できる
XMLでは、マーク付けの数を減らすことは重要ではない

　1番目の「XMLは、インターネット上でそのまま使用できる」は特にいうことは何もない。2番目の「XMLは、広範囲のアプリケーションを支援する」は、XML自身が利用範囲を限定するような態度を取っていないことを意味する。XMLとは別個の技術を持ちだして、XMLを使うならこれを一緒に使うべき、という主張は多い（例：XMLとJava、XMLとCORBAなどなど）。しかし、XMLは特定の技術とだけ親密になることを意図しているわけではない。つまり、「XMLなら○○を一緒に使うべき」というのは「○○側の片想い」といえるし、逆にいえば、片想いとしなければXMLの理想は実現できない。

　3番目の「XMLは、SGMLと互換性を持つ」は歴史的経緯としての制約といえるが、今後は意識することは少なくなっていくだろう。4番目「XML文書を処理するプログラムは容易に書ける」は、プログラマーとしてはうれしい目標だろう。5番目「XMLでは、オプションの機能はできるだけ少なくし、理想的には1つも存在しない」は、オプションがなければ（つまり全機能が常に利用可能と分かっていれば）とても扱いやすくなることから、納得いく目標といえる。しかし現実には、XMLには実装してもしなくてもよい機能が存在する。例えば、シフトJISなどの従来型の文字コードでXML文書を処理することは、禁止されてはいないが、すべてのXML処理ソフトで利用可能とは限らない。6番目「XML文書は、人間にとって読みやすく、十分に理解しやすい」は、XML文書そのものを見てもある程度内容が理解できることから達成されていることが分かるだろう。

　7番目「XMLの設計は、すみやかに行う」は、極めてスピーディにXML 1.0勧告が出たことから達成されているが、なかなか勧告にならないXML関連の多くの仕様には当てはまっていない。8番目「XMLの設計は、厳密で、しかも簡潔なものとする」については、XMLの仕様は決して大きくはなく、簡潔にまとまったことは事実である。しかし、多くの誤りが発見され、かなりの正誤表が出され、それを反映した2nd Editionまで出たことから、厳密さにはやや難があったといえるかもしれない。だが、この点は改善が進んでいるので、将来的には問題ないだろう。9番目「XML文書は、容易に作成できる」は、とりあえず最小限のXML文書の書き方が分かるという意味では実に容易なものである。しかし、実体も含めて完全に把握するのはちょっと面倒かもしれない。10番目「XMLでは、マーク付けの数を減らすことは重要ではない」は、重要な特徴といえる。XML文書は、ファイルが大きくなりすぎるから出来が悪いとか、圧縮方法を考えるべきだといった批判がある。しかし、そもそも効率などという項目はXMLにおいては設計目標に入っていないのである。つまり、効率よりも、簡単に使えることが重要と考えられているのである。この点を見誤ったXML批判は建設的ではない。効率が悪いことだけを攻撃するのではなく、分かりやすさも含めて総合的に判断しなければならない。

要素や属性の名前に使える「名前文字」

　要素や属性の名前に使用できる「名前文字」には、仮名や漢字も含まれる。では、実際に使用できる文字のバリエーションの範囲はどこからどこまでなのか。日本語に存在する文字の中で使用できる文字の一覧表はXML日本語プロファイルにも掲載されているが、厳密な定義は、当然のことながらXML 1.0勧告に記述されている。「[5] Name」の定義と、「付属書B. 文字クラス(Appendices B Character Classes)」を参照することで理解できる。さらに厳密には、ここに掲載されている文字コード表はUnicodeの仕様上の規定から導かれるものなのだが、ここではそこまでは踏み込まないでおく。

■名前文字を理解する

　まず理解する必要があるのは、名前文字では最初の1文字と、2文字目以降では、扱いが変わるという点である。最初の1文字は、以下のいずれかである。

Letterと名付けられたグループに属する文字
アンダースコア記号（'_'）
コロン記号（':'）（注：名前空間と併用時には、名前空間接頭辞との区切り文字）

　Letterと名付けられたグループはさらに、「付属書B. 文字クラス」の中で、BaseCharと名付けられたグループとIdeographicと名付けられたグループからなることが分かる。これらのグループのどの文字でも使ってよい。そして、BaseCharとIdeographicに属する文字の種類は、具体的にUnicodeのコードの範囲としてずらりと記述されている。例えば、BaseCharの定義の先頭は[#x0041-#x005A] となっているが、これはUnicodeのU+0041からU+005Aまでが該当するという定義を示している。この範囲は、アルファベットの大文字のAからZまでに相当する。基本的に、Unicodeのコードがどのような文字に対応するかを知るには、Unicodeの規格書を見る必要がある。オンラインでも、Unicodeコンソーシアムが文字表を公開しているのだが、そのままではうまく閲覧できないようだ。手っ取り早くは、Windows 2000などに付属の文字コード表で、文字セットをUnicodeを指定したうえで、文字を選択して下部に表示されるU+XXXXという表示を読み取るという方法がある。

　さて、2文字目以降は以下のように使用できる文字が増える。

Letterと名付けられたグループに属する文字
Digitと名付けられたグループに属する文字
ピリオド記号（'.'）
マイナス記号（'-'）
アンダースコア記号（'_'）
コロン記号（':'）（注:名前空間と併用時には名前空間接頭辞との区切り文字）
CombiningCharと名付けられたグループに属する文字
Extenderと名付けられたグループに属する文字

　ここで注目すべきは、Digitという名前のグループである。これは数字に関する文字のグループである。つまり、数字から始まる名前を要素や属性の名前として使うことはできないが、2文字目以降なら利用してよい。つまり、<ゼロテスター>は良くても、<0テスター>は許されない。また、<ゾイド新世紀スラッシュ0>と<ゾイド新世紀スラッシュゼロ>はどちらも許される（余談だが、スラッシュ記号は名前文字ではないので、<ゾイド新世紀/ゼロ>はできないのはいうまでもない）。

　念のために付け加えるなら、Digitに属している文字は0～9だけではない。各言語で数字を記述するために使用される文字も、Digitに属している。そのため、これらの文字も数字扱いされるのだが、漢数字である一、二、三……あるいは、壱、弐、参……などはDigitの中には含まれていない。これらは漢字としてIdeographicに含まれるので、DigitではなくLetterの一部となる。そのため、<一等賞>は利用できるが、<1等賞>は不可である。

文字コードの自動判定

　XML 1.0勧告の「付属書F. 文字符号化方式の自動検出（Appendices F Autodetection of Character Encodings）」は、厳密にいうと仕様の規定の一部ではなく、参考のために書かれたものにすぎない。ここに書かれているのは、文字符号化方式（文字コード系）の自動判定ルールである。この判定ルールは実装してもよいし、実装しなくても勧告に反するわけではない。だが、自動判定機能を実装する際の1つの目安になるため、実際に利用される機会は多いだろう。

　実は、この部分は、XML 1.0がSecond Editionになる際に多くの変更が行われており、同一とは言い難い部分がある。これは、もともとルールに不備があり、それが修正されたことによる。一部は、筆者が開発した漢字コード変換ツールtconvのXML自動判定機能を実装する際に気付いたことを、村田真さんにレポートしていただいたものである。しかし、ルールに差異があることから、完全に同等に動作しない状況も考えられる。

　この自動判定ルールは、細かく分けると2つある。1つはUnicodeのBOM(Byte Order Mark)を使用する方法。もう1つは、XML文書の最初は“<?xml”で始まるという条件を利用したものである。前者は、当然ながら、Unicodeのエンコーディング（UTF-8, UTF-16など）にしか適用できない。後者は、XML宣言が付いていないXML文書には適用できない。そのため、UTF-8やUTF-16以外のXML文書にはXML宣言を付けることが必須となる。

　しかし、自動判定というものはすべてのケースにおいて完璧に判定できるわけではなく、できれば使わない方がよい。だが、どうしても使う場合は、Second Editionのルールを実装したXML処理ソフトの方がベターである。

XMLのバージョンアップの可能性

　XMLは、バージョン1.0のまま安定していた。正誤表を反映したSecond Editionがあるとはいえ、本質にかかわる大変更が行われたわけではない。しかし、最近になって、改行文字のコードに関して不備があるという指摘がなされ、議論が行われている。改行文字は空白文字の一種であり、もし追加されれば、既存のすべてのXML処理ソフトが影響を受ける。つまり、この議論の行方次第では、非互換度の大きな修正がXMLの仕様に対して行われる可能性がある。その結果が、正誤表の訂正程度で済むか、それとも、XML仕様書のバージョンアップになるのかは分からない。

　しかし、少なくともいまのXML 1.0勧告に沿って作成したXML文書が利用できなくなるということは考えにくい。また、追加提案のある改行文字といっても、かなり特殊なニーズでしか使われないコードなので、変更されてもそれほど大きな影響を受けることはないだろう。

1年間の連載のまとめ

　最後に、連載全体を読み終えた皆さんがこれから直面するであろう状況について触れておこう。

　連載の最初の話題に戻るが、XMLはメタ言語である。メタ言語とは言語を作る言語である。つまり、XMLの利用者には、「自ら言語を作る立場のユーザー」と、「すでにXMLによって作られた言語のユーザー」の2種類が考えられる。後者の立場の者は、XMLのユーザーであるという自覚を持たないかもしれない。例えば、XMLで作られたXHTMLの利用者は、自分のことをXHTMLの利用者だと思い、決してXMLの利用者だとは思わないかもしれない。そのため、本質的な意味でXMLを使うということは、XMLを用いて新しい言語を作り出すことをいう。

■言語を作るときの最大の問題は……

　では、XMLで新しい言語を作るというのは容易なことなのだろうか？　既存の言語の使える部分を集めて、本当に足りない機能を付け加えるだけなら、それほど手間のかかる仕事ではないだろう。そのために、名前空間という機能が存在するのである。しかし、手間がかからないというのは、あくまで、DTDなどのスキーマ言語を書く手間の問題でしかない。書く前の段階、つまり仕様を決定するプロセスに大きな困難がつきまとうことが多い。その理由は、XMLで作られる言語の多くが、技術的な内容ではなく、ビジネスや社会のルールにかかわる内容を記述するために生み出される点にある。

　ビジネスや社会のルールは、厳密に割り切れるものではない。技術的に最善だからという理由で決定しようとしても、理解を得られないことも多い。だが、過去の慣習をそのままXML上で表現しようとしても、効率が悪かったり、最悪の場合、矛盾して記述不能に陥る場合もある。さらに、BtoBなど外部とのコミュニケーションが不可欠な応用分野であれば、社内の慣習よりも外部の標準に適合させる必要が生じる場合もある。もしかしたら、XMLを利用する者たちが次に戦う相手は、最新技術でもネットワークでもなく、慣習を変えたくないという組織の持つ保守性ということになるかもしれない。

　これは、「慣習は常に悪である」、という意味ではない。どんな慣習にせよ、それが成立した時点では、何らかの必然性が存在したはずである。しかし、時間が経過するとともに、必然性が変質してしまい、慣習だけが残っている場合も多い。また、XML出現以前は十分な必然性といえたものが、XMLのある社会の中では必然とはいえなくなるケースもあるだろう。XMLの利用は組織の秩序に敵対するものではなく、組織の秩序を、実情に即して立て直すために行われるべきといえる。

　だが、XMLはブームだから採用しろ、といったのでは、一過性のブームなどに組織の未来を任せることはできないと、反論されてしまうだろう。XMLを使うことが、本当に組織のためになることを、きちんと説明することができなければ説得はできない。そのためには、付け焼き刃の怪しげな知識では不十分である。基礎からきちんとXMLを理解することも、また大切なことではないだろうか？