「文書処理：20年前の課題は今でも課題」より：
上記の問題群をすべて詳細に解説することは、僕に残されたエネルギー量ではとても無理です。幾つかを選んで、おおよその状況を語ろうかと思います。とりあえずは、今後の（散発的な）ブログ記事で3回くらいを目標にします。
さて、何から話せばいいのかな？ 僕が語りたいこと／語るべきことは、構造化文書処理における問題点と解決へのヒントなのですけど、実在したプロジェクト／ソフトウェアであるAliceがどんなものであったかを先に述べておいたほうが良さそうですね。
シリーズ最初の記事 兼 リンク集：
この記事の内容：
Aliceのミッションと絶対的要求
実を言うと、プロジェクトAliceがいつ始まったかハッキリしません。それは僕の記憶のせいではなくて、当初は正式なプロジェクトではなかったからです。区切りがいいから2000年スタートとしておきましょう。2000年初頭は、僕とWさんの二人だけで実験と試作をしていて、4月入社新人*1のOさんが加わり三人体制となり、それが長く続きました。（後々、人数が把握できないほどにチームは膨張しましたが。）
2000年の後半くらいには、僕らは「何をどう作るべきか」について、かなりハッキリした見通しを持っていました。その後、基本方針は変えていません。
「何を作るべきかは」はプロジェクトのミッションであり、プロジェクトとして認知された頃（それより前だったかも）には決まっていました。それは、「文書処理：20年前の課題は今でも課題」で述べたとおり「XMLベースのワープロソフト」です。次の二点は絶対に外せない要求です。
- ワープロとしての使い勝手
- 徹底的に柔軟な構造
この要求は、技術的なハードルでもありますが、僕らを余計な悩み・混乱から開放し、心理的な割り切りを促すものでした。
ユーザーは自分が編集している文書がXMLであることを意識しない／できないのです。当然に、「XML文書をソースコードとして編集したい」という要求はハナから無視できます*2。現在のMarkdownエディタがより難しい状況にあると思うのは、「Markdown文書をソースコードとして編集したい」という要求を無視できない点です。文字の並びとしてのMarkdownソースコードと、対応する構造ツリーの両方を一度に扱う必要があります。Aliceは構造ツリーだけを扱えば良かったのです。
当時は、様々な分野の様々な用途にXMLボキャブラリー〈タグセット／属性セット〉が策定され、それが標準として定着すると期待されていました（そうはならなかったけど）。将来登場するであろうボキャブラリーにも対応する必要があります。プラグン方式〈plugin architecture〉にせざるを得ません。「拡張可能〈extensible〉＝プラグ可能〈pluggable〉」です。当時既に、プラグインの手法はほぼ確立されていた*3ので、これはリスキーな選択ではありません。
今「プラグイン方式にせざるを得ない」と言いましたが、上記の2つの要求から、幾つかの「‥‥にせざるを得ない」が帰結します。その帰結は我々にとっては自明になっていました。例えば：
- プラグイン（のソフトウェアコンポネント）は、一緒に動作する他のソフトウェアコンポネントについて何も知らない。それにも関わらず、他のコンポネントとうまく協調して連携プレーで仕事をする必要がある。
この要求は特筆に値すると思うのです*4が、「そりゃそうだ」と受け止められていました。
拘ったところ
目標であるところの「XMLベースのワープロソフト」を「どう作るべきか」は技術的な判断となります。今思えば、純粋に技術的な判断をしたというよりは、趣味的拘りがけっこう入っていたと思います。ともかくも、次のようなモットーと指向（嗜好）で進めようと決めました。
- 標準仕様の遵守
- 分散アプリケーション指向
- メタエディタ機能
標準仕様の遵守
IETFやW3Cの仕様を忠実に実装することに拘っていました。趣味的拘りの面もあったでしょう。が、この方針には実務上の大きなメリットがあります。まず、自分達で仕様を考える必要がない -- 労力が大幅に節約できます。メンバー間のコミュニケーションが楽です。そして、外部とのコミュニケーションも楽なんです。なにしろ「RFC何番を読め」「W3C TRナニナニに書いてあるよ」で済みますから。そして、相互運用性を確保できる可能性も高くなります。
ただ、そうは言っても標準仕様では適切なものが見つからないことはあります。DOM仕様では、カーソル位置や選択範囲をうまく表現できないので独自の方法を使っていました。（DOMレンジ仕様はあったかな？ あったとしてもエディタとしては使いにくい仕様です。）DOMツリーの変更通知イベントの仕様として DOM Mutation events 仕様があります（今では非推奨になっています）。これも使いにくいところ*5は変更・拡張していたと思います*6。
分散アプリケーション指向
誤った予測から、Aliceを分散アプリケーションにするつもりだったことは「文書処理：20年前の課題は今でも課題 // 補足」に書きました。「何年か後には分散アプリケーションの時代が来る」と思っていたわけです*7。僕がビジネス的判断をする立場だったなら、大失策でしたが、ソフトウェアの内部構造を決める上でのモットーとしては悪くなかったと思います。
いずれ分散化する予定なので、一枚岩／密結合にはできません。モジュラー化を促す効果がありました。RPC〈遠隔手続き呼び出し〉経由でアクセスすると思えば、データの具体的なフォーマットや保存形態、ソフトウェアの実装言語や内部構造は必然的に抽象化せざるを得ません。すべてはインターフェイスとなり、インターフェイス以外の情報に依存することはできません。
分散アプリケーション指向は、「時代の空気」でもあった気がします。1990年代に勃興したCORBA（Common Object Request Broker Architecture）は、まだ凋落の兆しを見せてませんでした*8。マイクロソフトもDCOM〈Distributed Component Object Model〉やMS-RPC〈Microsoft Remote Procedure Call〉を出していたくらいです。
我々がヘビーに依存していたDOM仕様のインターフェイスは、IDL〈Interface {Description | Definition} Language〉で記述されています。IDLは分散システムのインターフェイスを書くための言語です。僕にはこの事が、「DOMを分散化せよ」と示唆している（そそのかしている）としか思えませんでした。実際、Distributed DOM、あるいは Distributed Huge DOM が、プロジェクトAlice後期（「プロジェクトAliceとプロジェクトBob」参照）のキーワードのひとつでした。
メタエディタ機能
エディタは文書を編集するソフトウェアです。メタエディタは、エディタを編集するソフトウェアです。これはいったいどういうことでしょうか？
例えば、Javaで実装されたソースコードエディタがあり、そのエディタのJavaソースコードをそのエディタで編集してリコンパイルしたらメタエディタになる？ -- ちょっと違う気がします。でも、自分の編集能力により、自分自身を改変している点ではメタ編集〈meta editing〉していると言えなくもない？（いや、言えない。）
Aliceにおけるメタ編集機能とは、Alice自身やプラグインされたソフトウェアコンポネントの機能性を、DOMツリーとして表現して編集可能とすることです。分かりやすい例では、エディタの設定情報をその場で編集して、編集完了と共に（再起動しないで）反映させることがあります。
単なる設定情報に限らず、ソフトウェアが持つ機能・構造のかなりの部分を、Aliceが編集対象とするデータ＝DOMツリーで表現しようと目論んでいたのです。Java(Aliceの実装言語)のリフレクションAPIと、コネクタと呼ばれていたメカニズム*9を組み合わせれば、なんとかなりそうと思っていました。
ただし、メタ編集機能は、（設定変更などを除けば）ユーザーが使うものではなく開発者向けの機能なので優先順位は低く、実装に力を入れたわけではありません*10。僕が「しゃべっていただけ」に近いです。しゃべるときによく使っていた言葉は「レイフィケーション」です。
- ブログ内 「レイフィケーション」の検索結果
余談ですが、レイフィケーションに関係するよく読まれた記事は：
Aliceは存在したんだぜ
「レイフィケーション」のような、よくわからない言葉を使って能書きをたれることが、いわば僕の仕事だったわけですが、能書きでソフトウェアができるわけはありません。ミッションとして課せられた二項目の要求も、やや趣味的な三項目の方針も、それを実現するのはだいぶ大変です。
無理難題と思える要求／方針／能書きに沿ったソフトウェアは実現され、実際に存在したのです。それはとびっきり優秀なエンジニアがいたからです。プロジェクトAliceは、商業的に成功したとは言い難く、その点ではほろ苦い思い出ですが、当時では（おそらくは現在でも）斬新なデザインのソフトウェアを、若くて抜群の力量を持ったチームと一緒になって作り出せたことは、刺激的で素敵な体験でした*11。
そんなソフトウェアについて、誰も何も記録せず、存在の痕跡も残らないのは寂しすぎる -- ってことも、今僕がこんなことを書いている動機のひとつです。
*1:要確認(苦笑)。
*2:XMLソースコードに近いビューも提供はしてましたが、それはDOMツリーを“ソースコード風”に見せていただけです。
*3:AliceはJavaで実装されていました。起動後に必要なタイミングで、classファイルやjarファイルから必要なクラスをロードすることは特に問題なくできます。
*4:パートナー不可知的〈partner agnostic〉状況とでも言えばいいでしょうか。いずれ詳しく取り上げる機会があるでしょう（たぶん）。
*5:例えば、DOMCharacterDataModifiedイベントでは、1文字の変更でも、変更前のテキスト全体と変更後のテキスト全体が知らされる仕様で、エディタとしては使いにくいです。
*6:変更・拡張の詳細を僕は知りません。Aliceチーム内では、変更・拡張していても「DOM Mutation Events」と呼んでいましたね、紛らわしいけど。
*7:1990年代の重厚な仕様ではなくて、HTTP上の軽いRPCが使われると予想してました。SOAP? ダメでしたね。SOAPの後続も出なかったし。
*8:21世紀に入ってもCORBAは存続してましたが、2000年前後が一番盛り上がっていた時期です。
*9:編集対象であるDOMツリーからの変更通知イベントを聞いて別なデータも変更する、あるいは逆方向の変更をするコンポネントがコネクタです。
*10:あっ、今思い出した。リフレクションAPIで、Aliceの内部を探索できるコマンドラインシェルを作りました。編集しているDOMツリーもシェルで辿れたかも知れません。
*11:陳腐な言い回しであることは承知で書いてるよ。
