2011/03/10、W3Cが EXI を勧告した。 EXI及びW3C勧告がどんなものかはだいたいこの記事に詳しい。
XMLをバイナリ化して効率的に圧縮することで転送速度や処理に必要なメモリ容量を小さくし、モバイルデバイスなどでも扱いやすくした「Efficient XML Interchange」（EXI）を、W3Cが3月10日に勧告しました（記事末にリンクしたEXIワーキンググループチェア 上谷卓己氏のビデオによると「エクシィ」と読むようです。）。
しかしどうもこのEXI、私の目からみると「モバイルデバイスでは」目的を達せない。 なぜそう思ったのかを以下に記録しておく。
背景
まず前提として、私はこの10年ほどモバイル(主に携帯電話)向けにXMLを扱ってきた。 実は以前にもXMLをバイナリで表そうというのは今に始まった考え方ではなく、 WBXMLというものがあって私はそれと向き合ってきた。 しかしまぁ、WBXMLは御世辞にも成功したとは言えないのだが、 それでもモバイルデバイス向けとしては実績もありEXIよりなんぼかマシと考えている。
まず褒めてみよう
とは言えEXI自体には次のようにさまざまな魅力を感じている。
- 仕様が綺麗
- ビットストリームが綺麗(WBXMLはバイトストリーム)
- 構文決定木が美しい
- XMLのイベントパーサにダイレクトに繋がるコード構成
- 機能が豊富
- スキーマを与えることで表現拡張できる
- ベースから圧縮が考えられている
長所が欠点となる
しかしこれらはモバイルに利用する上ですべて欠点であると言い切れる。
実はビットストリームは、プアなモバイルではそれ自体がパフォーマンスを悪化させる。 それはたとえば文字列(バイト配列)を読み取るのにビット操作が必要になることによる。 ビット操作はデータが小さければレジスタ内で収まるが、 それでもちょっとした文字列を取り扱うだけでメモリの読み書きが必要になってしまう。 一方PCに比べてプアなモバイルはメモリが想像以上に遅いので、 読み書きを発生させないことが速度を出す上で非常に重要な原則である。 EXIの実装をイメージするとこの原則に適合しない。
機能が豊富であることも問題だ。 このEXIのパーサ(デコーダ)はまだしもエンコーダはどんな大きさになるというのか。 モバイルにとってメッセージは読むだけでなく書くものでもある。 こんな豊富な機能、使うものだけ実装し動かすとしてもかなりの重量級となるだろう。 もちろんEXIもある程度時間がたてば良い実装は出てくるに違いない。 だがビット操作ベースでは前述の理由により、 メモリもCPUもコードサイズも軽量とはいかない。
XMLの本質的な問題
EXIであるかWBXMLであるか、それ以前にXMLにはモバイルにとって本質的な問題がある。 それは「兄弟ノード や親ノードをたどるコストが高い」ということである。
それはDOMパーサを利用できないから。 DOMパーサであればnextSibilingやparentを見ることで上記の問題は解決できる。 しかしDOMパーサはメモリ食いなのでそもそもモバイルには向かない。
となればEXIが志向したようにイベントパーサしかないのだが、 イベントパーサは兄弟ノードや親ノードをたどるのが非常に苦手である。 親や兄弟ノードをたどる処理は、実際のアプリケーションを 書く上で早晩多用することになる。 よってそのコストが高ければモバイルにとってはアプリ自体が高コストになってしまう。
結局どう思うのか?
EXIはXMLのバイナリ表現としては良くできている。未来の繁栄も予感させる。 しかしモバイルデバイスにとっては彼らが標榜したような幸福な結果はもたらさない。
雑感
仕様を眺めていると、これを考えた人たちはなかなかの学者肌なんではないかと感じる。 そしてXML 1.1を巡る「ボヘミアン」と「貴族」の階級闘争の貴族さまを連想する。 彼らが本当にモバイルや組み込みでXMLを扱ったことがあるならば こんな仕様にはならなかった、そう思えて仕方ないのは私だけだろうか?