XMLはバイナリ化するか

• Tweet
• ブックマーク

  

  

  はてなブックマーク

  Check

  mixi チェック

  

  Instapaper

  Read it Later

  Read It Later

先日、XMLのバイナリフォーマット仕様EXI (Efficient XML Interchange)がワールド・ワイド・ウェブ・コンソーシアム(W3C)の勧告候補(Candidate Recommendation)になりました。今後、複数の実装による相互運用性の検証を経て、W3Cの国際標準になっていくものと思われます。今回は、このEXIについて考えてみましょう。

XML文書の圧縮

XML文書の圧縮は人気の高いトピックです。XML文書はテキスト形式で、人が見る分には良いのですが、計算機で処理するには一見効率が悪そうです。例えば、年齢を表すのに、コンピュータのメモリ上では1バイトあれば十分ですが、XML文書の要素として<age>51</age>のように表現すると13バイトになったりします。これでは効率が悪そうですね。ですので、XMLの処理をする人ならば、誰でも一度はXML文書の圧縮を考えたことがあるのではないでしょうか。

zipすると...

XML文書には同じ要素名が繰り返し現れますから、文字列としての冗長度が高いです。ですから、たいていの場合、普通のデータ圧縮プログラム、例えばgzipを使えば大幅な圧縮ができます。マイクロソフトのOfficeで使われているOpen XMLでは、文書の内容はXML形式で表現されますが、ファイルに格納される時にはそれをZIP形式で圧縮しています。マイクロソフトによれば、これで75%程度圧縮できるそうです。つまり、元のXMLに比べて1/4に大きさになるわけですね。もちろん、この圧縮率は文書によって全然違うでしょうから、平均的に75%、というのはあまり意味のない数字かもしれません。あくまでも目安、でしょう。

スキーマを使った圧縮

一方、XML文書がXML文書である特質を使うと、より高い圧縮率を得られることもあります。XML文書が、あるスキーマに対して妥当(valid)であることがわかっているときには、そのスキーマをうまく使って圧縮できます。例えば、要素の後に要素が来ることが文法上わかっているのであれば、次に来た要素がであることを明示的に符号化する必要はなくなります。データベースの内容をXML化したような文書など、定型性の高い文書には、特に有効に働く手法でしょう。

文字列の並べ替え

さらに、文字列がXML文書のどこに現われるかによって並べ替えをしてから、通常のデータ圧縮アルゴリズムを適用すると、より高い圧縮率が得られることがあります。例えば、名前空間宣言には似たようURIが出てくることが多いようですから、これらのURIだけを集めて圧縮アルゴリズムで圧縮すれば、似た文字列が繰り返し現れるので圧縮率が高くなります。これはとても強力なアイディアで、うまく文字列の並べ替えをすると、テキストファイルをそのまま圧縮するよりも、XML化してから圧縮したほうが小さくなることがあり得ます。

XML処理の高速化

XMLを圧縮しただけでは、XML処理は必ずしも速くなりません。圧縮したXML文書をパーズするためには、単純には一度伸長してからパーズしなければならないからです。XMLをバイナリ化する理由のもう一つは、XML処理を速くすることです。

XML処理高速化のシンプルなアイディアは、XML文書をSAXイベント（例えば、StartElement、など）の列としてコーディングする方法です。こうすると、XMLプロセッサの語彙解析部分（例えば"<"から">"までを切り出してスタートタグと認識する）がシンプルになって、高速化されます。このようなコーディングは、XML文書を小さくするのにも効果があります。

XMLバイナリ化への批判

XMLのバイナリ化については、過去にも多くの試みがありました。しかし、常について回った批判の一つは、バイナリ化の目的は圧縮や高速化など複数あって、一つのフォーマットだけではすべての要求を満たせない、というものでした。EXIは、圧縮率も高く、処理もそこそこ高速なようです。加えて、いくつかオプションがあって、オプションのON/OFFによって、スピードや圧縮率に最適化することも可能です。

XMLバイナリ化に対するもっと大きな批判は、「そもそもXMLがXMLたる所以は、XMLがテキストであるからだ」という「そもそも論」でしょう。XML1.0がこれだけ普及したのは、XML1.0がきわめて安定した仕様であり、非常に高い相互運用性を持っていたからに他ならないと思います。この、相互運用性に関する議論は確かにその通りであり、バイナリ版を作ることによって相互運用性を損なってはならないと考えます。EXIを導入してしまうと、EXIメッセージはEXIに対応していない処理系では受け取れないことになります。そのことは大きな問題として慎重に考えていかないといけないと思います。

一方、「XMLはテキストエディタで読めなければならない」というテキスト原理主義は、今の時代にはあまりあてはまらないのではないかと思います。XML文書が複雑になるにつれ、いずれにせよ普通のテキストエディタでXML文書を閲覧したり編集したりするのは現実的でなくなってきているからです。そもそもUTF-8をサポートする良いテキストエディタもあまり無いのではないかと思います。私は、XML文書を閲覧するときには、最近はブラウザを使うことにしています。もし、ブラウザがEXIを解釈できるようになれば、XML文書がテキストであるか、バイナリ形式であるかは、あまり違いが無くなってきますよね？

EXI

EXIは上記のような圧縮化、高速化のアイディアを高い次元でうまくバランスさせた仕様のようです。EXIは勧告候補になったので、これから複数の実装が出てきて、相互運用性の検証が行われるはずです。SourceForgeでもEXIの実装があります。

手元にある実装を使って、一つ圧縮の実験をしてみました。もともとのデータは、HTTPサーバーのログで、テキスト形式で928KBありました。これにXMLタグを付けてXMLファイルにしたもののサイズが2.58MBです。EXIで圧縮するとこれが66KBになりました。およそ1/40です。もともとテキスト形式だったので、オリジナルのテキストをそのままgzipにかけると95KBでした。従って、一度XMLにしてからEXIで圧縮すると、元のテキストをそのままgzipしたもののおよそ2/3のサイズになったことになります。これは、前述の文字列再配置の効果が大きかったのでしょう。

今までにもいくつものXMLバイナリ仕様が提案されてきましたが、W3Cの標準になるのは初めてです。XMLが組み込み機器などに広く使われるようになってきていますので、W3Cの標準として相互運用性が確保された形で普及するのは望ましいことなのではないかと、個人的には思います。

終わりに

前回のブログで紹介したヤマハのUSB接続の会議用電話機ですが、個人向けの新しいモデルPJP-10URが発表されたと、ヤマハの馬場さんからお知らせいただきました。発売は1月下旬ということなので、発売されたら是非購入しようと思っています。

それでは皆様、良いお年をお迎えください。