もう XML 言語を開発するな

Don’t Invent XML Languages by Tim Bray
(Updated: 2006/01/09)


XML の X は「拡張可能(Extensible)」という意味だ。自分の問題に応じて自分の XML 言語を開発できることをウリにしている。でも、僕は過去 2 、3 年の経験から、そうすべきではないことを悟った。本当に必要な時以外はね。今からそれを説明する。そして、もし本当に必要な時がくれば、関連文書のOn XML Language Design を読んで欲しい。

僕は最近ある XML 言語の開発を手伝っていたのだけれど、どうか話半分で聞いて欲しい。僕は言語デザインをメインでやっているわけではないし、僕がもし専門技術でなにか言えることがあるとすれば、それは主としてたくさんの異なる XML 言語のユーザとしてのものだ。ものすごくたくさんだ、実際には。それがポイントなんだ。



簡単でも、おもしろくもない

XML 言語を設計するのはハードだ。つまらないし、政治的だし、時間がかかるし、魅力もないし、イライラする仕事だ。たいてい思っていたよりも時間がかかるし、終わったときにはもっとこうできたとか、もっとすぐにできたはずだとか、あるいは細かいところで大間違いをしでかしたなんて気持ちになることだろう。



成功/失敗 比率

Robin Cover の有益なXML Cover Pages では、知られている XML 言語の役に立つリストが作ってある。現在 600 ほどだ。Robin はこれが包括的なリストだとは言わないだろう。これらは彼のレーダーに引っかかったものだけだ。

リストをながめて、僕はこう問う：このうちいくつが重要なんだろう、と。

リストを見てみてほしい。どう思うだろうか? 重要なのは 600 よりもはるかに少ないんじゃないだろうか。もう一度質問を言い直してみよう：いくつが設計者の目的を果たしただろう、と。同じ答えだろうと思う。

結論は明らかだ。もし新しい XML 言語開発に手を出すなら、かなりの割合でその努力は報われないことになる。

[補足：もちろん、そのリスクを軽くするために、言語のデザインが終わった後、そいつを売り込まなけりゃならない。マーケティングなしで成功することを望むのはどのテクノロジーでも同じだ。僕らの中にもマーケティングや販売が好きなのもいるから、大きなマイナスというわけなじゃないが、それでもこれは他人の仕事だ。]

だからこの種の仕事に着手しないのは理にかなっている。ハードだし、本当に時間を消費するし、それが望んだ結果を生み出さない確率がかなりあるんだ。難しくて、おもしろくなくて、失敗の確率の高いプロジェクトを避けるのは、人生において一般的にはよい教訓だろう。そしてここまでは僕は個人的な時間の消費についてしかしゃべってない。



ソフトウェアの苦痛

もし新しい言語をデザインするなら、ソフトウェア開発において大きな投資をしていることになる。まず第 1 に、検証ソフトが必要だ。スキーマを書くのがすべてだなんて思っちゃいけない。些細でないすべてのソフトはスキーマ言語でチェックできないたくさんの制約がある。そして些細でないすべてのソフトは、相互運用する場合、自動化された検証ソフトが必要になる。第 2 に、人間によって書かれる言語をデザインするなら、オーサリングソフトをどうにかしなけりゃならないだろう。これは、1 からオーサリングソフトを書くか(膨大な費用と時間と苦痛だ)、あるいは XML オーサリングツールをカスタマイズすること--比較的小さな時間とお金と苦痛--を意味する。最後に、メインのソフトの開発だ。新しい言語を作ったり検証する以外に、その言語を使って何かをしないことには言語のデザインなんてしないだろう。誰かがそのソフトを書かなきゃならない。ソフトは高価なんだ。

でも言語を開発しないもっと大事な理由がある。ネット効果から始めよう。



Metcalfe 再び

Bob Metcalfe はイーサネットを開発したとっても頭のいいやつで、主に Metcalfe の法則の提唱者として歴史に名を残すことになるだろう： ネットワークの価値はノードの数の 2 乗にほぼ比例する。

これが関連する法則だ：マークアップ言語の価値は、それを処理できる異なるソフト実装の数の 2 乗にほぼ比例する。僕はこれを理論的に説明することもできるけど、ここでは例を使おう： HTML. RSS. PDF. (Atom、XMPP、ODF はもうすぐ来るんじゃないかな)。納得したかな? HTML はロボットのリンク追跡や人間向きのレンダリングエンジンにも使われる。RSS/Atom フィードは、イベント追跡やニュースをかき集めるのにも使われる。Apple 社は Adobe 社よりも優れた PDF リーダを作ることができる。

もしそれがまだ明らかじゃないと言うのなら、これが僕が ODF のハードコアな味方であり、マイクロソフトのこのネット効果への支持を拒むことにムシャクシャしている理由だ。



機会コスト

XML 言語を開発するのが時間を消費することはもう言ったし(1 年以下で終わったのを見たことがない)、それから君はその言語を使ってなんらかの仕事をするソフトを書く必要があるんだろう。でも、おそらく君は「なんらかの仕事」というのを今欲しいはずだ。そうじゃなけりゃ、そんな問題に取りかかってはいないだろう。何年もかかる言語開発とそれからソフトの実装をするコストを抱える準備はできているか?



5 大主力言語

一番頭がいいのは、検証ソフトもオーサリングソフトもパーサもジェネレータもその他いろんなものも持っている完成したマークアップ言語を使う道を探すことだ。ここでひとつかましてやろう： XHTML、DocBook、ODF、UBL、Atom の 5 大主力言語を使ってやりたいことをできないと確信が持てるまで、自分の言語を作ろうと考えることすらしちゃいけない。


XHTML と Microformats

もし情報を Web を使って人間にわたすなら(それを "Web ページ" だと君が思ってなくてもだ)、XHTML を使わないのはほとんど狂っていると言ってもいい。もちろん、XHTML は文法的に弱いし階層がしっかりしてないし他にも問題はある。でもいいんだ。だって汎用の class 属性があるし知らないマークアップは無視するし、なにも壊すことなしに 8 つの方法で bastardize することができる。Kool Kids はこれを "Microformats" と呼んでいて、実際僕は偶然にも去年の 11 月にひとつ作ってしまった。テンプレートと class 属性を見て欲しい。

もちろん、XHTML を使うなら何百万というすでにあるブラウザにわたすことができるし、人間が読むことができる。もし彼らがそれが何をしているのかを知りたくなったら、「ページのソース(View Source)」でソースを表示させることができる。説得力あるだろう。


DocBook

君が何か XHTML でできるものよりも大きくなったり深くなったりリッチになったりするものを作りたくて、それを印刷や電子書籍や音声で再利用したくて、章や節や付録や参考文献や脚注やそういうのが欲しいとしよう。DocBook がまさにそれだ。DocBook は君が想像できるようなものはすでに含んでいるし、役にたつ仕事をするたくさんのツールも手に入る。


ODF

君がたくさんの流れ作業をしなくちゃらなくて、(構造的ではなくても見た目が)複雑で、いつか印刷されるかもしれなくて、下に署名がしてあるような文書にとりかかりたいとしよう。ODF が君の望むものだ。もっとも Web 向きのアプローチとは言えないが、一方でオーサリングツールはリストの中でも一番人間になじみやすいものだ。


UBL

もし君が請求書とか注文書とかそういうのにとりかかっているなら(そうしない人がいるの?)、なにかを開発しようと考えちゃいけない。たっくさんの頭のいい人たちが何百年をかけて基礎的なものをまとめてくれたし、彼らはよい仕事をした。いますぐ使える状態だ。これ以上探しても無駄だ。


Atom

君のデータがなにかのリストになっているとしよう。株価とか流れ作業のステップとかお菓子の材料とかスポーツの統計とかのことだ。Atom が使えるかもしれないよ。リストの中のものが人間に読めるラベルをもつ必要があったり、タイムスタンプを運ばなきゃならなかったり、他のリストにかき集められるかもしれないのなら、Atom はほぼ間違いなく君が必要なものだ。1 年前に存在していなかったデータフォーマットとしては、バカみたいにたくさんのソフトがこれを処理できる。



マネージャへ

次に技術のスーパースターが部屋にやってきて「X のための XML 言語を開発しなければならない」と言ったときには、5 大主力言語のひとつを使ってそれをできないことを証明させることだ。もし証明されてしまった場合、君は深いため息をついて、数年の仕事の遅れと、何千時間の労働を覚悟するしかないだろうね。