XML、データ、コード、そして Chimaira

» Permanent link | |

XML guy としての、最近の心境です。

そもそも XML とは何なのか、について考えさせられることが多くなりました。

一つはまつもとゆきひろさんの「私はなぜ XML を愛していないか」という日記です。ここで、まつもとさんはデータ記述言語としての XML の存在意義に疑問を投げかけられています。「XML を愛する人」と自己紹介している身としては、この日記に反論? しておきたかったのですが、考えをうまく文章化することができず、時機を逸してしまいました。

もう一つは檜山さんの一連の記事(Java World の連載および chimaira.org)です。どちらの記事においても、檜山さんは一貫して XML タグ構文とソフトウェアコンポーネントを統合的に取り扱うアーキテクチャ(の土台となるべき議論)について論じられています。

まつもとさんの指摘を一言で言い表すと「XML ってそんなにイイの? 使いやすいの?」となるのではないでしょうか。まつもとさんの側(プログラミング言語設計者、OOP の視点?)から見ると XML は冗長で回りくどくてスマートでなく、しかもデータ型など細かいところに手が届かない中途半端なデータ形式、と思われているようです。

XML は本当に使いやすいのでしょうか。

結論から先に言うと、ある視点からみれば全くそのとおり、使いにくいです。以下では僕が感じていることをもう少し書き綴ってみます。

まつもとさんの日記のコメントでは Relaxer が話題に上っていました。関連した話として、川俣さんが chimaira.org に言及した記事で Relaxer に疑問を投げかけられています。僕は Relaxer を有効活用していますが、Relaxer が XML を扱う最適な処理形態ではないと感じています。Java (あるいはプログラミング言語)の世界のデータモデルに合致したスキーマを利用する限りにおいては Relaxer は有効ですが、XML 特有のモデルが出現したとたん、バインディングが複雑になってしまいます。Relaxer を使っている現場では、ラベルを駆使したスキーマや choice などは使っていないのではないかと想像しますが、どうなのでしょうね。

しかしなぜ Relaxer は人気があるのでしょうか。なぜ人々は Java の世界で閉じずに、あえて RELAX NG(XML)という別の世界に流れるのでしょうか。まず考えられるのは、Relaxer がいろいろな雑誌に紹介記事が載っていて、かつインストールが簡単、比較的安定しているなどマーケティングのうまさとツールとしての出来のよさです。雑誌に書いてあって何か使えそうだ→インストールも簡単だった→いっぱい Java のコードを生成してくれる(感動!)という流れです。

それからもう一つ、実はこれが結構重要だと思いますが、Relaxer を使うと Java オブジェクトの永続化が簡単に行えるということも挙げられるのではないかと感じています。逆に言うと Java ではオブジェクト永続化が難しい、ということです。ツリーで表現できるデータ構造を Java で設計し、アクセッサを用意して、かつ入出力のコードも書き、というようなコーディングを手で一からやっていると、非常に手間がかかります。一般論として、プログラマはデータ構造の設計に集中したいのです。Relaxer を使えば、これが実現できます。すなわち RELAX NG スキーマの設計(=データ構造の設計)に集中すれば、その他の雑多なコードは全てツール(Relaxer)が自動生成してくれるのです。これは特に Java のような堅い言語で威力を発揮するのではないでしょうか。

さらにいうと、その永続化したデータが、Java 以外の言語やツール、たとえば XSLT などからアクセス可能である、というところがシステム設計者にとっても大きなメリットとなっているのではないでしょうか。ここはまさに XML の持つインターオペラビリティの本領発揮というところでしょう。

僕自身は Ruby に関して何も知らないので推測ですが、堅い Java に対して軟らかい Ruby では Relaxer のようなツールがあったとしても Java 版ほど利用されないのではないかと感じ(あくまでも感じるだけ)ます。

さて、ここまでは Java, OOP などの視点で語ってきました。しかし、世の中には別の視点もあります。それは、構造化文書、ハイパーテキスト、などいわゆるボヘミアンの視点です。ボヘミアンにとって一番大切なのは XML の構文とデータモデル(普通は? Infoset、でも檜山さんは DOM のようですね)です。彼らがプログラミング言語に期待するのは、自分の XML データをいかに効率的に扱えるか、処理できるかということです。そのような立場の人間からしてみると、既存のプログラミング言語(というよりは XML 処理ライブラリか)は中途半端で出来が悪く感じます。XML データを処理するコードを書こうとすると、とたんに冗長で回りくどくてスマートでなく、しかも混在内容など細かいところに手が届かない中途半端なプログラムになってしまいます。プログラミングの視点から見れば、そんなデータ形式のほうが悪い、となるのかもしれませんが、ボヘミアンからしてみれば、なんで俺のデータをこのプログラミング言語(ライブラリ)は扱えないのだ、となります。すなわち、興味の対象がコードなのかデータなのか、ということです。

プログラマの視点から見る世界は圧倒的にコード重視の世界でした。プログラムが真ん中にいて、その周りをデータが回っている世界です。ところが、Web 環境ではデータの価値が上がり、相対的にコードの価値が下がりました。データが中心にいて、その周りを複数のコードが回っているような状況です。XML 2004 のキーノートで、Michael Daconta がこれをコペルニクスの天動説と地動説になぞらえていました。

XML をインターオペラビリティのためだけにあると捉える人々は、天動説主義者ではないでしょうか。そしてボヘミアンは地動説主義者であるといえます。

ただ、データを中心に捉える考え方は、別に新しい物ではありません。たとえば Unix でおなじみの行指向のデータはどうでしょうか。Unix で伝統のある行指向のテキストデータは、それを扱う小さいプログラムがたくさん揃っています。そしてそれらをパイプとフィルタで自由自在に結合し、処理することが出来ます。フィルタは cat, sort など基本的なコマンド以外に、適当なスクリプト言語のワンライナー(使い捨て)をその場で作ってしまうことも出来ます。これはまさに行指向のテキスト(データ)の周りを小さいフィルタプログラム(コード)が回っている世界ではないでしょうか。

だいぶ昔、確かユニマガだったと思いますが、ラリーウォールがインタビューで perl の今後を聞かれたときに、これまで行指向のテキストデータが対象だったものを XML のようなツリー構造も対象にしていきたい、というようなことを返答していたと記憶しています。そして今、檜山さんが chimaira アーキテクチャでやろうとしている Janus はまさにこのパイプ&フィルタを XML の世界に拡張しようとする試みです。

XML の本領発揮はこれからではないでしょうか。まだ僕たちには見えていない世界があるようです。

こんな感覚が分散システムのアーキテクチャである REST と相関して自分の中になんともいえないモヤモヤを作っています。ここで述べた見解以外にも、他方では document vs object, rpc vs messaging, そして messaging コミュニティにおいても WS-* スタック vs REST など、問題のドメインは微妙に異なっていても実は課題は同じなのではないかと思えることがたくさんあります。継続して考えていかないといけないですね。