一太郎Ark1.1 その構造と可能性
このページでは、一太郎Arkを社外の目で評価したレポートを公開します。
一太郎Arkの熱心なファンであり、なぜか開発チームとも知り合いなのである。このソフトウェアを客観的に評価するなんて、とてもできそうにない。だからこの記事は、Arkの技術解説と補足情報を提供するものとなる。Arkに関するテクニカルエッセイと言ったほうがいいも知れない。
Arkをお使いの皆さんは、このソフトウェアをどのようなものとして捉えているだろうか? おそらく、「HTMLファイルを作れる簡易ワープロ」と思っているだろう -- それはまったく正しい。しかし、それがArkの全てではない。広告の文面によれば、「100% Pure Javaアプリケーション」、「複数言語を同時に扱える国際化機能」、「XML対応」などなど。これでもArkの全てではない。少なくとも私の目から見れば、それらは表層的な特徴に過ぎない。
Arkの素晴らしさは、その潜在能力、その可能性にある*1。Arkの構造を理解し、Arkに込められたメッセージを読み解くと、近未来のオーサリング(文書作成)環境のあるべき姿が浮かび上がってくる。いわば、Arkは未来を見せてくれるレンズのようなものなのだ(図1)。そして、Arkをとおして見えてくるビジョンに、私たちは感動をおぼえ、それらが必ず実現できると確信をいだく。不完全で不満足な現在のオーサリング環境に対し、まさに救いの方舟(はこぶね)となるのがArkなのだ。
図1 Arkをとおして未来が見える
図1 Arkをとおして未来が見える
一太郎Arkの内部はこうなっている
Arkの意義を理解するために、その内部構造を眺めてみることにしよう。図2は、Arkの構造を模式的に描いたものである。UI (ユーザーインターフェース)、編集コマンドセット、DOMエンジンが主なモジュールである。ユーザーの操作はUIにより解釈され、編集コマンドを呼び出す。その編集コマンドはDOMエンジンに指令を与えてDOMツリーを変更し、その変更はUIに反映される。これが基本的な流れである。
いや、説明を急ぎすぎた。もう少しゆっくりと見てみよう。
ユーザーがメニューから項目を選んだり、マウスクリックやキータイプを行うと、ユーザーイベントが発生する(図2の(1))。発生したイベントがどんな意味を持つかは、イベント→コマンドの対応表(イベントマップ)を引いて調べる(図2の(2))。例えば、[挿入]-[ブックマーク]というメニュー項目選択は、InsertBookmarkという編集コマンドにマップされるし、リターンキーを押すと、CutUpBlockという編集コマンドが起動される(図2の(3))。
図2を注意深く見ると、イベントマップからUIへの左向き矢印があるのが分かる。ユーザーイベントの一部は編集コマンドではなく、UIコマンドにマップされる。UIコマンドはUIへの操作を引き起こす。例えば、画面のスクロールやツールバーの表示/非表示切り替えなどが、UIコマンドである。
文書の変更を行う編集コマンドは、文書データを管理しているDOMエンジンへの指令に展開される(図2の(4))。DOM (Document Object Model)エンジンとは、ツリー(木)の形をしたデータの管理と操作に専念するソフトウェアモジュールだ。DOMエンジンへの指令は、W3Cで標準化されたAPIが使われる。
DOMエンジン内のDOMツリーが変更されると、ミューテーションイベント(変更通知イベント)が発生し、UI部に伝えられる(図2の(5))。ミューテーションイベントを受けたUIは、適切に画面を変更する(図2の(6))。これにて、ユーザーの思いがArkに反映されるまでのサイクルが完了する。
図2の右下に描かれているストレージマネージャは、ファイルから文書を読み込んだり、文書をファイルに書き出すときに使われる。Ark内部では、文書は単なるテキスト(文字の列)ではなく、ツリーとして管理される。ストレージマネージャは、外部ファイルと内部ツリーの相互変換を行う。
編集コマンドはJavaで書かれたメソッドだが、思いのほか複雑なことをやっていることもある。例えば、リターンキーで起動されるCutUpBlockコマンドは、内部的には、新規ノードの追加と内容の移動(カット&コピー)を行っている(図3)。今までのワープロやテキストエディタのように、改行文字の挿入ではない。
図3 リターンキーが引き起こす操作 (CutUpBlock)
図3 リターンキーが引き起こす操作 (CutUpBlock)
W3Cが定めた標準であるDOM仕様に従えば、図3のようにするのが自然であり、必然でもある。一太郎Arkは、文書フォーマットや処理メカニズムに関して、インターネットの標準仕様に徹底的にこだわっている。例えばCSSフローティングレイアウトに関しては、Internet ExplorerよりもNetscape Navigatorよりも仕様に忠実なレイアウトを実行している。
Ark のパフォーマンスは決して悪くはない。100% Pure Java アプリケーションとしては抜群に高速といっていいだろう。だが、速度のために標準を無視したり、勝手な解釈で変則的な実装(プログラム作り)をしてはいない。「パフォーマンスよりコンフォーマンス (仕様適合性) 」は、Arkチームの合い言葉のひとつだった。
XML 1.0
XML Namespaces
HTML 4.0
XHTML 1.0
CSS Level 1
DOM Level 1
一太郎Arkでは、MVC (Model-View-Controller) と呼ばれるフレームワーク(基本的枠組み、方法論)を採用している*3。図4は、MVCの観点から図2を描き変えたものだ。Modelはデータの操作と管理を集中的に受け持つパート、ViewはModelが保持するデータをユーザーに提示するパート、そしてControllerがユーザー操作を受け取って、適切にModelとViewに指示を与えるパートだ。
図4 一太郎ArkにおけるMVC
図4 一太郎ArkにおけるMVC
MVCでは、ViewとControllerがユーザーインターフェースを構成し、Modelはユーザーインターフェースとは独立になる。このため、同じModelに対して、異なるView/Contorollerを準備することも可能である(ViewとControllerはある程度相互に依存しているので、別々に差し替えることは難しい)。
MVCフレームワークに従って作られているため、一太郎Arkは柔軟で自由な拡張性を備えている。例えば、一体型のArkをネットワーク上に分散化することを考えてみよう。
Model部分を編集サーバとして切り出す。ViewとControllerは編集クライアントとなる。編集コマンド呼び出しやミューテーションイベントの伝達はネットワークを越えて行われる。もちろん、ユーザーごとにView/Controller(ユーザーインターフェース)は異なっていてもかまわない(図5)。
図5 マルチユーザー・リモート編集
図5 マルチユーザー・リモート編集
このようなメカニズムは、ネットワーク上に散在した複数の人々が同一の文書を、対話的に共同執筆する環境や、新しいコミュニケーション基盤を提供するだろう。
一太郎Arkの標準文書フォーマットはXHTMLである。HTML4.0と同一のタグセットと、ユーザー定義タグが使える。(正直に言えば、ユーザー定義タグの機能は不満足なものである。)これは残念ながら、XHTMLの拡張性を十分に利用しているとはいいがたい。近い将来(いつとは言うまい)、一太郎Arkの扱う文書は、XHTMLベースのXMLハイブリッド文書となる(図6)。
XMLハイブリッド文書とは、複数のタグセットが混在したXML文書である。例えば図6のように、全体はXHTML、メタ情報(書誌情報)はDublin Core*4、数式はMathML*5、図形はSVG*6、ハイパーリンクはHTMLリンクよりずっと強力なXLink*7、さらにその他のタイプの文書が埋め込まれているような文書が考えられる。
Arkは、9,800円という廉価なソフトウェアパッケージである。インターネット・イントラネット環境向けのシンプルなワープロとして役に立ば、商品としての使命を果たせるだろう。しかし、Arkの意義は、JavaとXMLの特質を最大限活かした文書環境への第一歩を踏みだした点にある。
現在の一太郎Arkは既に、XML関連仕様のJavaによる実装としては世界でも最高水準のものではあるが、目指す到達点ははるかに遠い。大きな目的に向かって歩むには仲間、協力者が必要なのは当然である。ジャストシステムとArkプロジェクトは、一太郎Ark開発の経験で得られた技術的成果とノウハウを、多くの人々と共有するための準備をはじめている。ノアの方舟(ark)は、たった一家族の人類しか救えなかったが、一太郎Arkは、すべてのコンピュータユーザーを救えるかも知れない。