特集：「XML 1.1」を分析する
XML 1.1とは何か？ 答えなき迷走の果て Page1
XML 1.1の勧告によって、何が変わり何が変わらないのか、影響を受けるのはだれか、これからのXMLはどのような方向に進むのか、これらの疑問に答えるのが本稿の目的である。（編集部） |
川俣 晶
株式会社ピーデー
2004/4/27
主な内容 XML
1.1が勧告されたが……XML 1.1は1.0とどこが違うのかXML 1.1が生まれるまでの経緯XML 1.1とほかの標準とのかかわり利用者から見たXML
1.1答えなき迷走の果て |
ブームといわれたり、何のために使うものか分からないといわれたり、関係ないものと混同されたり、さまざまな話題を提供してくれた「Extensible Markup Language（XML）」の新しいバージョン、「Extensible Markup Language (XML) 1.1」が2004年2月4日に勧告された。最初のバージョンである1.0が勧告された1998年2月10日から、約6年もの月日が経過した。
6年という歳月は、ドッグイヤーといわれるほど動きが速いインターネットの世界では極めて長い。特に、インターネットの重要な基本技術とされ、W3Cなどの標準化団体が新たに作成するさまざまな言語がXMLをベースに使っているにもかかわらず、6年もの間、動きを止めていたなどということがあり得るのだろうか。
ここでは、なぜ6年間もバージョンアップされなかったのか、そして、なぜバージョンアップせずとも深刻な問題を引き起こさずに使ってこられたのかを意識しつつ、以下の4つの点を考察しよう。
- XML 1.1は1.0とどこが違うのか
- XML 1.1が生まれるまでの経緯
- XML 1.1とほかの標準とのかかわり
- 利用者から見たXML 1.1
XML 1.1は、XML 1.0と比較して、どこが変更されたのだろうか。この問いは、XMLの動向を見守ってきた人であればあるほど、重要な意味を持つ。実際に、次世代のXMLのあるべき姿に対して、さまざまな意見が出ていたが、そのすべてが反映されたわけではないからだ。具体的に、過去にどのような提案があったのかは後で一例を挙げるとして、ここでは実際に変更された個所を確認しよう。
XML 1.1が XML 1.0から変更された主要な点は以下の5つである。
- XML宣言などのバージョンが1.1に変更された
- 名前文字についての制限が大幅に緩和された
- 改行文字として#x85と#x2028が追加された
- C0およびC1制御文字（#x0以外）は、文字参照としてのみ許されるようになった
- 「full normalization」という概念が導入された
以下、それぞれの項目を個別に見ていこう。
| 参照（XML 1.1仕様書より） 1.3 Rationale and list of changes for XML 1.1 |
XML宣言などのバージョンが1.1に変更された
まず、最も分かりやすい変更点は、XML宣言などで表記されるバージョンが1.0から1.1に変更されたことである。例えば、XML宣言は以下のように変化することになる。
| XML 1.0のとき | <?xml version="1.0"?> |
| XML 1.1のとき | <?xml version="1.1"?> |
この変更は、大きな意味を持つ。バージョン番号は固定値なので、これを変更した文書は受け付けられない。例えば、XML 1.0対応のXMLプロセッサは、「version="1.1"」と記述された文書はすべて受け付けない。XML 1.1対応のXMLプロセッサは、XML 1.0の文書を受け付けることが好ましいとされているので、どちらも受け付けるかもしれない。しかし、バージョン番号は安易に書き換えてよいものではない。
これは、安易に異なるバージョンに書き換えても問題なかったHTMLとは違うことに注意が必要である。例えば、HTMLの場合なら、「HTML 3.2」として記述されてきた文書を、HTML 4.01が勧告された時点で、早速「HTML 4.01」として書き換えて使うことができた。仮に文書型宣言を以下のように書き換えたとしよう。
| HTML 3.2のとき | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML
3.2 Final//EN" …… |
| HTML 4.01のとき | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" …… |
このように書き換えても、主要なWebブラウザは（たとえHTML 4.01に対応していなくても）この文書を受け付け、表示してくれる。それは、多くのWebブラウザが、文書型宣言を調べていないか、未知の文書型宣言でもエラー扱いしない実装になっているという事情による。
しかし、これと同じような状況はXMLではあり得ない。XMLプロセッサが、XML宣言のバージョン番号が一致しない文書を受け付けることは期待できない。バージョンが一致しなくてもエラーにしないことが（なし崩し的という印象は受けるが）HTMLの流儀であるなら、バージョンが一致しないとエラーにするのがXMLの流儀である。
このような事情から、XML 1.1の機能を使用したXML文書のXML宣言には、必ずバージョン番号として1.1を書き込まなければならない。また、XML 1.0のXMLプロセッサで処理されねばならない場合は、必ずバージョン番号として1.0を書き込まねばならない。
名前文字についての制限が大幅に緩和された
XML 1.0から1.1への6年間で、XMLが強く依存する文字に関する標準が大きく変化した。Unicodeのバージョンが上がり、収録された文字のバリエーションが増えたのである。XML 1.0が参照するUnicodeのバージョンは2.0であったが、XML 1.1は4.0を参照している（本稿執筆時点での最新は4.0.1）。すでに、メジャーバージョンが2つも上がっているわけである。
念のために付記するなら、XML 1.0はUnicodeが用意したコード空間のほぼすべてを記述可能な文字として含めている。Unicodeが収録する文字が増えるとは、あらかじめ用意されたコード空間の空きに新しい文字を入れていくことにほかならない。そのため、XML 1.0が勧告された時点でまだ割り当てられていなかった文字であっても、それをXML文書に記述することは可能である。それにより、Unicode 2.0には含まれていないが4.0には含まれている珍しい人名漢字などを、XML文書に書き込むことはXML 1.0を使用する場合でも可能である。
ここで問題になるのは、要素名などを記述する際に使用する名前文字である。例えば、アルファベットの「a」は名前文字だが、記号の「+」は名前文字ではない。そのため、名前文字だけからなる名前「alpha」は要素名として正しいが、名前文字ではない名前を含む「a+b+c」という要素名は正しくない。このような区別によって、読み方に悩むような記号の列を要素などの名前として目にすることはなくなる。名前に使用できる文字とそうでない文字を分けることは、XMLに限らず多くの言語で行われている。しかし、このような分類は、個々の文字がどのような役割を持っているか、1つ1つ調べなければ決定できない。つまり、まだ文字が割り当てられていない領域の中で、どこからどこまでが名前文字であるかを確定することはできない。
このような状況から2つの問題が発生する。まず第1に、名前文字として適切な文字であっても、XML 1.0では名前文字として扱われていないものがあること。XML 1.0勧告時点で割り当てられていない文字は判別できないので、やむを得ない。これはXMLをバージョンアップして新しい勧告を行うことで救える。そして第2に、どんなに新しい勧告を行ったとしても、その後に割り当てられる文字については判別できないこと。未来のことは予見できないので、これもやむを得ない。
これらの問題に対処するために、XML 1.1が選択した手段とは、まだ割り当てられていない文字を含め、ほとんどの文字を名前文字扱いとする方法である。つまり、名前文字とそうではない文字を厳密に勧告内で定義することを断念した。これにより、未登録の文字も含め、名前文字として適切な文字をすべて要素などの名前として使うことができるようになった。半面、名前文字として適切ではない文字を名前に使用することも可能となる。例えば、日本語では「。」は文章を区切る記号であって、名前を記述する文字ではない。そのため、以下のような要素を記述しようとしても、XML 1.0ではエラーとなる。
<モーニング娘。/>
しかし、これはXML 1.1ではエラーとはならない。一応、名前文字の使い方に関するガイドラインは、XML 1.1勧告のAppendicesのI「Suggestions for XML Names」に掲載されているが、これはNon-Normative、つまり（規定の一部ではなく）参考文書でしかない。
| 参照（XML 1.1仕様書より） Appendices I Suggestions for XML Names (Non-Normative) |
改行文字として#x85と#x2028が追加された
XML 1.0では、改行として認識される文字は#xD（復帰）、#xA（改行）、そして、#xDと#xAを並べたものの3種類であった。XML 1.1では、以下の文字も改行として認識する。
- #xD #x85の2文字の並び
- #x85
- #x2028
- 直後に#xAまたは#x85が続かないすべての#xD 注
| 注：
記事に誤りがありましたので、以下のように修正しました（2004年10月8日）。 誤）#xA or #x85の直後ではないすべての#xD 正）直後に#xAまたは#x85が続かないすべての#xD |
ここで注意すべきことは、XMLの空白の定義は変化していないことである。これらの追加された改行文字は、すべて改行の正規化によって#xAに置き換えられてから処理される。つまり、XMLプロセッサから解析結果を取り出すときには、これらのどの改行文字を使用したとしても、すべて#xAが取り出され、どれが使われたかは区別できない。応用ソフトの開発者は、XML 1.1対応のプログラムを作成する場合でも、XMLプロセッサから得られる文字列に#x85が含まれているかどうか、心配する必要はないわけである。
さて、追加された#x85とはメインフレームで使用される改行文字「NEL」である。これについては、W3CにNoteとして「The [NEL] Newline Character W3C Note 14 March 2001」という文書がある。
もう1つの#x2028とはParagraph Separator（段落区切り）である。改行文字は、行を変える場合と、段落を変える場合の2つの用途で使われることがあるが、どちらを意図したものか区別できない場合も多い。そこで、Unicode/ISO 10646では、段落区切りと行区切りに異なるコードを割り当てて区別可能にした。しかし、それぞれ#x2028と#x2029というASCIIやシフトJISなどで記述できない特殊なコードであるため、ほとんど使われていない。
C0およびC1制御文字（#x0以外）は、
文字参照としてのみ許されるようになった
C0およびC1制御文字というと難しく聞こえるかもしれないが、コードの番号で見れば分かりやすいだろう。C0制御文字集合は#x0〜#x1fに相当する。XML 1.0では空白文字に当たる#x9、#xA、#xD以外はすべて使用できなかった。しかし、XML 1.1では、#x0を除き、文字参照（ሴのような書式）として記述することが許されるようになった。
C1制御文字集合は#x80〜#x9fに当たる。これに#x7fを加えた領域は、XML 1.0では何の制約もなく使用が許されていた。しかし、XML 1.1では改行文字として追加された#x85を除き、文字参照としてのみ記述可能と変更された。制御文字がXML文書中に平然と出現すると、それがどのような効果を発揮するか分かりにくいので、これは妥当な変更といえるだろう。
これらの変更によっても、#x0の文字としての使用はやはり許されない。そのため、C言語のように、文字列を#x0に相当する文字で区切る方式を使って処理する場合にも安全に処理できる。
「full normalization」という概念が導入された
XML 1.1では、「full normalization（完全正規化）」という概念が導入された。これは、名前、属性値、文字内容を単純にbit単位で比較することで同一か否かを判定できるようにする効能を持つものである。Unicode/ISO
10646は、例えば合成文字など、同じ文字に複数のbit表現が存在する場合があり、単純な比較ができない。これでは不便であるため、文字を正規化する手順を定め、bit単位の比較によって一致判定可能にしたいというニーズが発生したと思われる。（次ページに続く）
| 1/3 | Page2 |
| Index | |
| 特集：「XML 1.1」を分析する XML 1.1とは何か？ 答えなき迷走の果て |
|
 |
Page1 XML 1.1が勧告されたが…… XML 1.1は1.0とどこが違うのか |
| Page2 XML 1.1が生まれるまでの経緯 XML 1.1とほかの標準とのかかわり |
|
| Page3 利用者から見たXML 1.1 答えなき迷走の果て |
|
■関連記事
・やさしく読む「XML 1.0勧告」
・XMLフロンティア探訪
 |
特集：「XML 1.1」を分析する |
- QAフレームワーク：仕様ガイドラインが勧告に昇格 （2005/10/21）
データベースの急速なXML対応に後押しされてか、9月に入って「XQuery」や「XPath」に関係したドラフトが一気に11本も更新された - XML勧告を記述するXMLspecとは何か （2005/10/12）
「XML 1.0勧告」はXMLspec DTDで記述され、XSLTによって生成されている。これはXMLが本当に役立っている具体的な証である - 文字符号化方式にまつわるジレンマ （2005/9/13）
文字符号化方式（UTF-8、シフトJISなど）を自動検出するには、ニワトリと卵の関係にあるジレンマを解消する仕組みが必要となる - XMLキー管理仕様（XKMS 2.0）が勧告に昇格 （2005/8/16）
セキュリティ関連のXML仕様に進展あり。また、日本発の新しいXMLソフトウェアアーキテクチャ「xfy technology」の詳細も紹介する
 |
|
|
|
|
