XMLフロンティア探訪
第7回 XMLの新バージョン「Blueberry」解説

XML 1.0が勧告されてから3年。W3Cでは、XML 1.0の後継となる仕様を探る動きに出た。それが「Blueberry」だ。果たして、XML 1.0には欠けている部分があったのか、それとも、早くも時代遅れになったためにバージョンアップが必要なのだろうか。（編集局）

川俣 晶
株式会社ピーデー
2001/11/30

今回の主な内容 XML 1.0に不足はないか？ XMLといったら？ Unicodeは2.0から3.1へ進化していた 要素名などに使える文字は別 使える文字と使えない文字の差 行末を示すコードの悪夢 次々に登場する行末コード DTDは消えていく XMLのバージョンは変わるか？

■XML 1.0に不足はないか？

　あまり大きな話題になっていないが、World Wide Web Consortium（W3C）のサイトに、XML Blueberry Requirementsという文書が公開されている。この文書は、1998年に勧告となったXML 1.0の後継言語には、どのような資質が必要かを述べたもので、Blueberryとは後継言語に与えられたコードネームである。つまり、XML 1.0の後継となる言語の具体的な仕様が出てきたわけではないのだが、具体的な後継言語が必要であるという要求が提出され、実際にそれを開発する作業に着手していることを示している。

　だが、現在のXML 1.0に一体何が欠けているというのだろうか？

　先にここで、明確にしておきたいことがある。最近、「XML」という言葉の意味が拡散している。XML 1.0の仕様そのもののことをXMLと呼んだり、DOMやXSLTなどのXMLの周辺技術まで含めてXMLと呼んだりすることがあるのだ。範囲が広がると、どこまでをXMLと見なすのか境界が怪しくなる。例えばXHTMLもXMLの一部と考えると、「HTMLとXMLの違いは……」などと述べたとき、HTMLの多くの特徴を受け継いだXHTMLが、HTMLではなくXML側の一部となり、区別が判然としなくなる。

■XMLといったら？

　筆者は、XMLといったら、XML 1.0だけを示すものと考える方がよいと考えている。というのは、周辺技術はより革新的な技術が出現したときにも交換可能だが、XML 1.0そのものは、作り直しができない貴重なデータファイルの保存・蓄積に用いられたり、コミュニケーションの基盤に使われるものなので、容易に交換できないからだ。だからこそ、XML 1.0だけは特別な位置付けでなければならない。例えば「素晴らしいAPIを開発してDOMを駆逐してやる」という主張や行動は歓迎されるものであっても、「XMLより優れたメタ言語を作ってXMLを駆逐してやる」という主張は、現実にはあまり歓迎されるものではないだろう。

　だからこそ、XMLを変えるというのは、ほかのXML周辺仕様を変えるのとはまったく違う意味を持つのである。よほど大きな理由がない限り、変更すべきではない性質のものである。2000年10月6日に出たXML 1.0の修正版であるXML 1.0 Second Editionも、XML 1.0の仕様に正誤表を反映させたものでしかなく、機能の追加・変更はしていない。

　にもかかわらず、いま、XMLそのものを変えようとしているBlueberryとはいったい何物なのだろうか。本当に、変更するに値するだけの要請があるといえるのだろうか？

■Unicodeは2.0から3.1へ進化していた

　Blueberryを理解するには、その前にUnicodeについて理解する必要がある。XML 1.0が勧告になった時点では、Unicodeのバージョンは2.0だった。しかし、現在Unicodeは3.1にまでバージョンアップしている。バージョンアップしたということは、収録された文字が増えたということを意味する。

　XML 1.0の勧告によると、XMLにおける文字の定義は以下のようになっている。

[2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */

　上記を一応説明すると、#x9はTAB文字。#xAは改行、#xDは復帰だがどちらも行末の印として使われる場合がある。[#x20-#xD7FF]は16bitの範囲内で利用できる通常の文字である。#xD800から#xDFFFまでが空いているが、これはサロゲートとして使われる領域であり、空きではない（サロゲートの詳細はUnicodeなどの解説書を見ていただきたい）。[#xE000-#xFFFD]も16bitの範囲内で利用できる通常の文字である。そして、[#x10000-#x10FFFF]はサロゲートで表現されるすべての文字である。

　これらを合わせれば、XMLで使える文字とは、Unicode 2.0で定義された文字コード空間から特殊な目的に使われるコードを外したすべて、といってよい。その中には、文字がまだ定義されていない領域も含まれる。Unicode 2.0から3.1へのバージョンアップとは、基本的に、文字がまだ入っていない領域へ文字を割り当てていく作業にほかならないので、XML 1.0は何もしなくてもUnicode 3.1に対応するといえる。

■要素名などに使える文字は別

　ならばBlueberryなど不要なのか、というとそうではない。XML 1.0での文字に関する規定はこれ1つではないためだ。Charで定義された範囲に収まっているということは、データとして記述することができるだけであり、要素名などに使えるわけではないのだ。

　要素名などに使用できる文字は以下のように定義されている。

[4] NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender [5] Name ::= (Letter | '_' | ':') (NameChar)*

　ここに出てくるLetter、Digit、CombiningChar、Extenderは、すべて具体的な文字コードのリストとしてXML 1.0の中に記述されている。具体的にどのコードが該当するかは、XML 1.0を見ていただきたい。これらのリストに含まれる文字は、当然、Unicode 2.0で登録された文字に限られる。Unicode 3.1で拡張された文字は、その当時はまだコードが割り当てられていなかったのだから、ここに書き込めるわけがないのだ。

　その結果、要素名などに使うのにふさわしい文字がUnicode 3.1で新規に登録されたにもかかわらず、XML 1.0ではその文字を要素名などに使うことができない、という問題が生じてしまったのである。

　XML Blueberry Requirementsによれば、以下の言語で問題を起こすという。

• Amharic （アムハラ語。エチオピアの言葉）
• Burmese （ビルマ語）
• Canadian aboriginal languages （カナダ原住民の言語）
• Cherokee （チェロキー語。北米ネイティブアメリカンの一部族の言語）
• Dhivehi （ディベヒ語。モルディブの言葉）
• Hakka Chinese （Bopomofo script）（客家語。注音字母）
• Khmer （クメール語）
• Minnan Chinese （Bopomofo script）（ミン南語。注音字母）
• Mongolian （traditional script）（モンゴル語。キリル文字ではない伝統的な文字）
• Oromo （オロモ語。エチオピア、 ケニアで使われる）
• Syriac （シリア語）
• Tigre （チグレイ語。エリトリアの言語）
• Yi （イー語。中国の言語）

　このリストは、筆者が日本語で注記を入れてみたものだ。手元の小さな英和辞典では半分も載っていなかったため、分からないものはインターネットで検索して探してみた。しかし、筆者はこの手の世界の言語に詳しいわけではないので、もし間違っていたらご教示いただきたい。

■使える文字と使えない文字の差

　さて、これらの言語はUnicode 2.0には収録されていないが、Unicode 3.1には収録されている。つまり、XML文書の本文に書き込むことはできるが、要素名などに使うことはできない。要素名に自国語を使えることのメリットは、日本語の要素名を使ってXML文書を扱ったことのある人ならピンとくるだろう。それがよいかどうかは別の問題として、読んで意味を類推するのが非常に楽なのである。そうすると、たまたまUnicode 2.0の時点で収録された言語だけ、このメリットを甘受できるのは不公平ということになる。

　それに、日本語も無関係とはいえない。日本語と中国語に関しては、文字の追加が行われているので、Unicode 3.1に収録された日本の漢字のすべてが名前文字に使えるわけではないのだ。ある漢字は要素の名前に使えるのに、よく似た別の文字は使えないという理不尽な状況に遭遇するはめになってしまう。

　つまり、Unicodeのバージョンアップに伴う名前文字の見直しは必須の状況なのである。

　しかし、その見直しを行うとXML 1.0勧告に対して非互換な変更を加えることになる。つまり従来のソフトは、新しく追加された名前文字を理解しないので、それを使ったXML文書をエラー扱いにしてしまうのである。

■行末を示すコードの悪夢

　Blueberryで提案されているもう1つの要件は、XMLで使える行末コードについてだ。

　ご存じのとおり行末を示すコードは、環境ごとにさまざまな種類がある。同じシフトJISを使っている場合でも、環境によって行末を示すコードが違っていることはよくある。それどころか、1つの環境の中ですら異なるコードが使い分けられていることもある。

　行末コードとして（シフトJISで）最も基本的なのは、16進コードで#0xaとなる改行（LF：ラインフィード）と、#xdとなる復帰（CR：キャリッジリターン）である。復帰は印字ヘッドを行の先頭に戻し、改行は用紙を1行分送るのが基本的な動作なので、次の行の行頭に印字ヘッドを送りたければ、復帰と改行の両方を送る必要がある。しかし、ファイルの中にテキストを保存する場合、復帰と改行の両方を保存するのは無駄であり、どちらか一方があればよいので、Macintoshのように復帰を使うものもあれば、UNIX系OSのように改行を使うものもある。また、Windows系では復帰＋改行の2文字のままで扱うのが標準的である。

　そのようなわけで、XML 1.0では、復帰、改行、復帰＋改行のどれもを行末を示すコードとして認識することになっている。これでやっと一息かと思いきや、話はこれで終わりではなかったのだ。

　問題は、IBM系のメインフレームで起こった。問題の詳細は、W3CのThe [NEL] Newline Characterというノートで読むことができる。要するに、メインフレームでは行を変えるコードとして、NEL（#x0085）を使用していたのだが、XML 1.0ではそれに配慮していなかったため、メインフレームでは、プレーンテキストとしてXML文書を書いても行末を示すコードがかみ合わずに、うまく処理できないので困ってしまった、ということである。

　やじ馬的な感想としては、いまごろになって何をいい出すのだと思う。何しろ、XMLは1998年に勧告になったというのに、それから3年もたってから、上記のNELに関する文書がノートとして出てきたのだ。いくらなんでも遅すぎる。おそらく、メインフレームの関係者はXMLが自分たちに関係するものだと、当時は想像もしていなかったのだろう。つまり、XMLの応用範囲は多くの人たちの想像以上に広がっているということができるだろう。かつて、UNIX文化と密接に関係して発展してきたインターネット技術が、メインフレームにまで強い影響を及ぼすと、だれが（特にプライド高いといわれるメインフレーマーの人たちが）想像しただろうか。

　とはいえ、問題は問題である。本当にそれが必要であるか、必要だとしてもすでに固まっているXML 1.0を変更するだけの価値があるのか、ほかに解決手段はないのか、という議論はある。しかし、問題提起されたことに意味はある。

■次々に登場する行末コード

　さて、行末を示すコードの問題はこれにとどまらない。ほかにも、「これも行末を示す文字」というものが出てきている。実はUnicodeで復帰、改行、復帰＋改行を使うのは、あまり正統的な方法ではない。Unicodeには、Paragraph Separator（段落区切り：#x2028）と、Line Separator （行区切り：#x2029）というコードがある。少し考えてみれば分かると思うのだが、実は、一口に「改行」といっても、見かけ上の1行を区切るために使われる場合と、段落の区切りに使われる状況がある。2つの目的で同じコードを使っているわけで、ときどきトラブルのもとになる。

　これを解消するために、Unicodeでは、行末と段落末をはっきり区別して、別々のコードを与えてしまおうとした。しかし、この理想主義的な選択は実際にはほとんど使われていない。なぜなら、Unicodeの多数派ユーザーである米国人の多くは、ASCIIコードでテキストを作っておけばUTF-8を扱うソフトにそのまま読ませることができると思っているわけで、ASCIIコードで書けないコードなど使いたいはずがない。その結果、現実に存在する大多数のUnicode関連システムは、従来と同じように、復帰、改行、復帰＋改行のどれかを使っている。実際にXML 1.0では、この3つを行の終わりとして認めている。

　しかし、NELがXMLに公式に認知されるぐらいなら、より正統的なParagraph SeparatorやLine Separatorも認めるべきという意見が出てくるのは当然のことだろう。だが、実際に、この2つを認めたとして、利用されるかどうかは分からない。また、XMLなら、要素で段落や行の範囲を区切ることも多いので、どれほどの利用価値があるかも分からない。しかし、絶対に必要ないといい切ることもできない。これも議論の対象になるのは当然の成り行きだろう。

■DTDは消えていく

　さて、ここまではBlueberryで追加される機能の話だが、Blueberryには含まれない機能もある。それはDTDである。Blueberryには整形式を規定する機能しか入らないもようだ。現実的な話をすれば、DTDが消えて、より新しい世代のスキーマ言語に置き換わっていくのは当然の成り行きといえるだろう。

　一方で、BlueberryとXML Schemaを合体させて、これをXML 2.0と呼ぶべきと主張する人もいるらしいが、これには異論も多いようだ。そもそもXML Schemaが十分に安定した仕様になったという評価が、社会的に下されたとはいい難い。仮にXML Schemaが安心して使えるとしても、本当にXMLとスキーマ言語の仕様を合体させるべきか、という議論も残る。少なくとも現在のBlueberryは、スキーマ言語を合体する方向性は取っていない。

■XMLのバージョンは変わるか？

　Blueberryはまだ、完成された仕様というにはほど遠いものであり、この先何がどうなるか分からない。実際にXML 1.0はすでに安定した仕様なので、もう変えるべきではないという意見も多い。これを突き崩して変更を加えるとなれば、本当に重要度の高い変更だけが行われることになるだろう。Unicodeに新たに加わった文字を名前文字として登録するような行為は、実際にその文字を利用する民族から見れば（たとえ人数が少なくても）極めて重要な問題となるだろう。

　日本語を使う日本人の視点から見ると、Blueberryのインパクトはあまりないかもしれない。Unicode 3.1を見れば日本語で追加された文字も多いが、人名などに使われる漢字が多く、それらを要素名や属性名に使うというケースは少ないだろう。

　むしろ影響が大きいのは、メインフレームのユーザーかもしれない。改行文字にNELが追加されるだけで、少しはXMLの使い勝手が良くなるという人たちが日本にもいるかもしれない。

　BlueberryがXMLの後継言語として登場するとしたら、バージョン1.1のような番号が与えられるかもしれない。XML宣言の中のバージョンは現在version="1.0"と、1.0しか許されていないが、ここに1.1と書くことになるかもしれない。そうすると、XML宣言で、どのバージョンのXML文書であるかが判定可能になる。

　いずれにせよ、BlueberryによってもXMLの本質が変化するわけではない。いま作成しているXML文書がBlueberryで使えなくなるわけでもない。Blueberryの動向はチラチラと横目で見ながら、目の前のXML応用に集中するとよいだろう。

■関連記事

　・W3C/XML Watch 「XMLの改定仕様はブルーベリー」
　・Ask XML Expert 「タグの大文字小文字の区別、使える文字を教えて」

　

「連載 XMLフロンティア探訪」

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