僕は、人生のかなりの時間と労力と情熱を文書処理に費やしました。なので、文書処理のことを書いたり話したりしたことはあります。ですが、文書処理の実際のプロジェクトやソフトウェアの話をしたことはありません。守秘義務の問題もありますし、仮に守秘義務に引っかからなくても進行中のプロジェクトについて口にすることはありません。
しかしながら、10年20年も昔の話なら、もはや誰にも迷惑はかからないし、気にする人もいないでしょう。技術的なアイディアで具体性があるものは特許になっているし、抽象的一般的な方法論は、むしろパブリックにすべきものでしょう。
僕がそのテの話をしなかった一番の理由はメンドクサイからです。そして、懐旧談に意味があるとは思えないからです。ごく最近、ふとしたキッカケから、個人的体験を縷々述べることに意味はないが、10年20年前に考えたりやったりしたことを書き残しておくことはまんざら無駄でもない気がしてきました。
あらためて資料を探したり調査をしたりはしません（メンドクサイ）。記憶に基づいて書きます。僕は嘘を書く気はありませんが、勘違いや記憶が薄れていることにより、事実と食い違うことを書いてしまう可能性はあります。もし関係者の方が読んでいたらご指摘ください*1。
これから述べることは、ほとんどは技術的な内容であり、僅かに僕の個人的な（僕以外の人に関係しない）思い出が混じるでしょう。それ以外のことに言及する気はありません。
過去を振り返るとき、当事者意識を再現することは難しく、傍観者・評論家的な語り口になりがちなようです。それで客観的になるかというと、すべての事態は主観を通して記憶されるものであり、技術的内容でさえバイアスを避けようがないことは注意しておきます。
この記事の内容：
シリーズの他の記事：
構造化文書を快適に編集すること
たまたま、次のブログ記事を読みました。
TOAST Meetup!というブログ内の一記事ですが、僕はTOASTが何であるかも知りませんでした。NHN JAPANが提供するゲーム向けクラウドサービスのようです。
上記のブログ記事で、最近のMarkdownパーザーやパーザージェネレータ、Markdownエディタの状況を知ることができました。まったく知らなかったこと（Tree-sitterやLezerのことなど）も書いてありました。一方で、この記事の著者（達？）の問題意識や解決への試みは、既視感と親近感を感じるものでした。「うんうん！ そうそう！ そうだよね、そうなんだよね」とヘッドバンギングの勢いでうなずくほどに。
ここ20年ほどで、コンピュータ／ソフトウェアの技術は見違えるほどに進歩しています。それにも関わらず、僕がちょうど20年前に考え込んでいた問題のうちの幾つかは今でも解決されていないようです（もちろん、解決された問題もあります）。個々の問題ではなくて、問題群全体として浮かび上がる課題・目標は何かというと：
- 構造化文書〈structured document〉に対して快適な対話的編集環境を提供すること
です。
僕達がかつて相手にしていた構造化文書は、XML文書／XHTML文書*2でした。Markdown文書は、それに比べれば簡易軽量な構造化文書です。そうであっても、解決すべき課題はほぼ同じであり、立ちはだかる困難も同種のように思えます（Markdownのほうがより難しくなっている面もあります）。
プロジェクトAliceとプロジェクトBob
僕がかつて関与した2つのプロジェクトを、仮にAとBと呼びましょう -- いや、それでは味気ない、プロジェクトAlice*3とプロジェクトBobにします。
プロジェクトAliceは、おそらく1999年末くらいからなんとなく始まり、2000年には小さなチームが作られました。プロジェクトAliceの目標は前節で示した「構造化文書に対して快適な対話的編集環境を提供すること」です。より端的に言えば「使いやすいXMLエディタを作ること」です。
タグをシンタックスハイライトするといったレベルではまったくダメで、ユーザーにXMLであることを意識させない完全なWYSIWYG〈ウィジウィグ〉エディタです。XMLベースのワープロソフトと言ったほうがいいかも知れません。特定のボキャブラリー〈XMLタグセット〉に対して作り込まれたエディタではなく、任意のボキャブラリーに対応可能な能力が要求されました。
プロジェクトAliceは、前記と後期に分かれます -- 僕の中では分けています。前記は、プロトタイピングのフェーズから製品化のトラックに乗せるところまでです。後期は、ローカルアプリケーションであったAlice（当該のXMLエディタを仮にそう呼びましょう）を分散アプリケーションにすべく構想していた時期です。
後期は期間的にも短く、構想だけで実装した成果物はありません。当時（今でも）分散アプリケーションとしてのXMLエディタに需要があるとは思えないので、いずれにしても頓挫していたでしょう。ただ、前期の段階でも分散化する目論見はあったので、ローカル呼び出し〈LPC〉をリモート呼び出し〈RPC〉に置き換えても通用するような作りにはしていました（実際には、分散化はそう簡単な話じゃないですけどね*4）。
もうひとつのプロジェクトBobは、2010年前後に関わった電子書籍の執筆・出版環境を構築するプロジェクトです。クライアントはブラウザなので、UIとなるアプリケーションはJavaScriptで書くことになります。全体の構造と、クライアント／サーバー間のプロトコル（HTTP上のプロトコル）は僕が設計しましたが、クライアントの実装にはまったくタッチしていません。バックエンドとなるサーバー側だけを見てました。サーバー側処理でも、最終的な組版処理部分も僕の範疇外です。
サーバー側のストレージはファイルシステムをそのまま使いました。原稿となるファイル群は、リビジョン管理システムのリポジトリであるディレクトリにテキストファイルとして置かれるだけです。ただし、プレーンテキストではなく、Wiki構文のファイルです。
Bob（当該の電子出版システムを仮にそう呼びましょう）のユーザーは、HTMLエディタではなくてWikiエディタで原稿を書きます。そのWikiファイルをサーバー側に保存します。プレビューのときは、サーバー側で Wiki構文 → HTML構文 の変換をして送ります。今のような、クライアント（ブラウザ）側でのリアルタイムプレビューではないです。
プロジェクトBobは、全体の枠組みと僕の担当部分は最初から決まっていて、さほどの自由度はなかったので、特段に珍しい技術は使っていません。様々な文書フォーマットのあいだのフォーマット変換（面白くない）はたくさん手掛けました。このとき感じたことは「フォーマットを決めること（例えばEPUB仕様）って意味あるのか？」です。現時点での思いは「フォーマットを決めることにたいした意味はない」です。
プロジェクトAlice、プロジェクトBobにおいて、僕の予測が大幅に外れた事柄があります。
Aliceを分散化の前提で考えていたのは、1990年代に、アポロ社（HP社に吸収された）のNCS〈Network Computing System〉やDCE/RPC〈Distributed Computing Environment/Remote Procedure Call〉に触れる機会があり、企業は分散アプリケーションを必要とするであろうと思っていたからです。こう思っていたのは僕だけではなく、分散環境／分散アプリケーションに賭けていた企業やプロジェクトはことごとく大コケしました。
インターネットがHTTP一色になってしまった後でも、HTTP上にRPCインフラが載るだろうと信じていました。RESTが普及し始めた頃に「あんれー？」となり、SOAPの衰退で「これはダメらしい」と気付きました。2020年の今でも、JSON RPCが多少使われているくらいで、RPCも分散アプリケーションも需要がありません。
プロジェクトBobでは、原稿にWiki構文を採用しています。今なら、Wiki構文はMarkdown一択ですが、2010年前後はWiki構文の群雄割拠時代で、どれにすべきか悩みました。結局、標準Wikiを標榜していたWiki Creoleを採用し、実際にWiki Creoleが標準になるだろうと期待していたのです -- ハイ、残念。Wiki構文の勝者はMarkdownでした。
[/補足]
何が問題であったのか／であるのか？
プロジェクトAlice、プロジェクトBobを通じて、僕達が直面した問題（困難）には次のようなものがあります。
- 終電問題
- ウメボシ問題
- フリカケ問題
- コピペ問題
- カーソル移動問題
- 空白問題
- コメント・PI問題
- 検索とパターンマッチング問題
- エラー告知問題
- 属性編集問題*5
- 構造の曖昧性問題
- ツリー変形と揮発性フラグメント問題
- 疑似要素*6問題
- 表示の更新と構造の同期問題
- プラグイン問題
よく分からない単語が出ていますね。
終電問題は、黎明期のXMLコミュニティのなかではある程度知られていたでしょう。XML文書の妥当性とその維持に関わる問題です（今日はこれ以上説明しませんが）。
ウメボシとフリカケは、Aliceチーム内のジャーゴン〈隠語〉で、複合構造化文書（ハイブリッド文書と呼んでいました）の二種類の形式です。ウメボシ型複合構造化文書とフリカケ型複合構造化文書があり、それらをソフトウェア的にどう実現するか、という問題です。
プレーンテキスト編集ではどうってこと無いことが、構造化文書ではとても難しくなる例があります。コピペ問題、カーソル移動問題、空白問題、コメント・PI問題、検索とパターンマッチング問題は、そのテの問題です。
エラー告知問題から先は雑多な問題群で、後に行くほどソフトウェアの作り方に関わるものです。
これらの問題の難易度はバラバラです。ほぼ解決した問題もあれば、手付かずで何をしていいかも分からない問題もあります。
構造化文書や電子書籍に対する関心や需要には変動があり、潮の干満を何度か繰り返しています。しかし、それが不要だという結論はあり得ないでしょう。そうであるなら、デジタルデータとしての文書を快適に編集することも課題としてあり続けるはずです。今現在、そして将来においても、上に列挙したような問題に突き当たる人はいるでしょう。解決方法を提示することは僕には出来ませんが、多少のヒントくらいは言えるかも知れません。
さて、上記の問題群をすべて詳細に解説することは、僕に残されたエネルギー量ではとても無理です。幾つかを選んで、おおよその状況を語ろうかと思います。とりあえずは、今後の（散発的な）ブログ記事で3回くらいを目標にします。
*1:関与した人間のなかで僕が最年長だったので、当時のメンバーは（不慮の事態が発生してなければ）生きているだろうし、僕より確かな記憶を持っているかも知れません。
*2:XHTML文書はXML文書の一種ですが、特別な地位を占めるのでこういう書き方（「XML文書／XHTML文書」）をしています。
*3:https://residentevil.fandom.com/wiki/Program:_Alice
*4:仮定の話として、そのまま分散アプリケーションへと進んだとして、首尾よく分散化できた自信はないです。
*5:2020-07-27 追加
*6:疑似要素はCSSの用語ですが、CSSの疑似要素より広く、例えばハイライトされた文字列検索結果なども含めて考えます。
