JPWO2008015787A1 - 文書処理装置及び文書処理方法 - Google Patents

Abstract

文書処理装置１００は、文書中のデータを処理して所定の機能を発現するための汎用的な部品として利用可能な処理モジュールであるテーブル表示用ＡＶＣコンポーネント３０１０、チャート表示用ＡＶＣコンポーネント３０２０、ＵＩパーツ表示用ＡＶＣコンポーネント３０３０、ツリー表示用ＡＶＣコンポーネント３０４０を備える。ＡＶＣコンポーネント切替部３０５０は、同一のデータに対して異なる複数のＡＶＣコンポーネントを切り替えて適用可能とする。

Description

本発明は、文書処理技術に関し、特に、マークアップ言語により記述された文書を処理する文書処理装置及び方法に関する。

ＸＭＬは、ネットワークなどを介して他者とデータを共有するのに適した形式として注目されており、ＸＭＬ文書を作成、表示、編集するためのアプリケーションが開発されている（たとえば、特許文献１参照）。
特開２００１−２９０８０４号公報

ボキャブラリは、任意に定義することが許されており、理論上、無限に多くのボキャブラリが存在しうる。これらのボキャブラリの全てに対応して専用の表示・編集環境を提供するのは現実的ではない。従来、専用の編集環境が用意されていないボキャブラリにより記述された文書を編集する場合、テキストデータにより構成された文書のソースを直接テキストエディタなどで編集していたが、本出願人は、任意のボキャブラリで記述されたＸＭＬ文書を編集可能な環境の開発に成功した。そして、更に利便性の高いＸＭＬ文書の処理技術の開発を目指している。

本発明はこうした状況に鑑みてなされたものであり、その目的は、マークアップ言語により記述された文書を処理する際の、ユーザの利便性を向上させる技術を提供することにある。

本発明のある態様は、文書処理装置に関する。この文書処理装置は、文書中のデータを処理して所定の機能を発現するための汎用的な部品として利用可能な複数の処理モジュールと、同一の前記データに対して異なる複数の前記処理モジュールを切り替えて適用可能とする切替部と、を備えることを特徴とする。

前記文書は、マークアップ言語により記述され、前記処理モジュールが処理可能なタグセットの構成要素を含んでもよく、前記構成要素を処理するために、その構成要素が属するタグセットを処理可能な前記処理モジュールが起動されてもよい。

前記切替部は、前記処理モジュールを切り替えるときに、前記構成要素を、切替元の処理モジュールが処理可能なタグセットの構成要素から、切替先の処理モジュールが処理可能なタグセットの構成要素に書き換えてもよい。

文書処理装置は、前記処理モジュールの動作に必要なパラメータの設定を受け付けるプロパティ設定部を更に備えてもよく、前記プロパティ設定部は、受け付けた前記パラメータを、前記構成要素又はその子孫の構成要素の要素値又は属性値として前記文書に記述してもよい。

前記プロパティ設定部は、前記処理モジュールを切り替えるときに、切替元の処理モジュールと切替先の処理モジュールとの間で共通に使用されるパラメータの設定を、切替元の処理モジュールから切替先の処理モジュールへ継承させて自動的に設定してもよい。

前記プロパティ設定部は、前記処理モジュールが処理する前記文書中のデータの型の設定を受け付けてもよい。前記プロパティ設定部は、前記処理モジュールが前記文書中のデータを画面に表示する際に、そのデータのラベルとして表示するテキストデータの設定を受け付け、前記データのラベルとして表示するテキストデータがユーザから設定されない場合は、そのデータの要素名をラベルとして設定してもよい。

本発明の別の態様は、文書処理方法に関する。この文書処理方法は、文書中のデータを処理して所定の機能を発現するための汎用的な部品として利用可能な複数の処理モジュールのうちいずれかを前記文書中のデータに適用するステップと、別の前記処理モジュールを、同一の前記文書中のデータに対して切り替えて適用するステップと、を含むことを特徴とする。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システムなどの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、マークアップ言語により構造化されたデータを適切に処理する技術を提供することができる。

前提技術に係る文書処理装置の構成を示す図である。 文書処理装置により編集されるＸＭＬ文書の例を示す図である。 図２に示したＸＭＬ文書をＨＴＭＬで記述された表にマッピングする例を示す図である。 図２に示したＸＭＬ文書を図３に示した表にマッピングするための定義ファイルの例を示す図である。 図２に示したＸＭＬ文書を図３に示した表にマッピングするための定義ファイルの例を示す図である。 図２に示したＸＭＬ文書を、図３に示した対応によりＨＴＭＬにマッピングして表示した画面の例を示す図である。 ユーザが定義ファイルを生成するために、定義ファイル生成部がユーザに提示するグラフィカルユーザインターフェースの例を示す図である。 定義ファイル生成部により生成された画面レイアウトの他の例を示す図である。 文書処理装置によるＸＭＬ文書の編集画面の一例を示す図である。 文書処理装置により編集されるＸＭＬ文書の他の例を示す図である。 図９に示した文書を表示した画面の例を示す図である。 文書処理システムの基本構成を示す図である。 文書処理システム全体のブロック図を示す図である。 文書処理システム全体のブロック図を示す図である。 文書管理部の詳細を示す図である。 ボキャブラリコネクションサブシステムの詳細を示す図である。 プログラム起動部と他の構成の関係の詳細を示す図である。 プログラム起動部によりロードされたアプリケーションサービスの構造の詳細を示す図である。 コアコンポーネントの詳細を示す図である。 文書管理部の詳細を示す図である。 アンドゥフレームワークとアンドゥコマンドの詳細を示す図である。 文書処理システムにおいて文書がロードされる様子を示す図である。 文書とその表現の例を示す図である。 モデルとコントローラの関係を示す図である。 プラグインサブシステム、ボキャブラリコネクション、及びコネクタの詳細を示す図である。 ＶＣＤファイルの例を示す図である。 文書処理システムにおいて複合文書をロードする手順を示す図である。 文書処理システムにおいて複合文書をロードする手順を示す図である。 文書処理システムにおいて複合文書をロードする手順を示す図である。 文書処理システムにおいて複合文書をロードする手順を示す図である。 文書処理システムにおいて複合文書をロードする手順を示す図である。 コマンドの流れを示す図である。 図３０（ａ）（ｂ）（ｃ）は、処理対象となるＸＭＬ文書のデータ構造の例を示す図である。 図３１（ａ）（ｂ）は、ポインタ情報の例を示す図である。 図３２（ａ）（ｂ）は、ＤＯＭの変更を通知する仕組みを説明するための図である。 第１の実施の形態に係る文書処理装置の構成を示す図である。 文書の編集画面の例を示す図である。 スケジュール用のビューテンプレートが起動された状態の編集画面を示す図である。 第２の実施の形態に係る文書処理装置の構成を示す図である。 ＡＶＣコンポーネントのプロパティが挿入されたＸＭＬ文書の例を示す図である。 第２の実施の形態に係る文書処理方法の手順を示す図である。 ＡＶＣコンポーネントにより表示された画面の例を示す図である。 第３の実施の形態に係る文書処理装置の構成を示す図である。 第３の実施の形態に係る文書処理方法の手順を示す図である。 第４の実施の形態に係る文書処理装置の構成を示す図である。 テーブル表示用ＡＶＣコンポーネントのＡＶＣプロパティが挿入された文書の例を示す図である。 図４３に示した文書に記述されたＡＶＣプロパティの内容を示す図である。 図４３に示した文書に記述されたＡＶＣプロパティの内容を示す図である。 図４３に示した文書を表示した画面の例を示す図である。 ＡＶＣコンポーネントにより生成されたビューの領域でマウスを右クリックしたときに表示されるメニューを示す図である。 ＡＶＣコンポーネント切替部により表示されたダイアログ画面の例を示す図である。 ＡＶＣプロパティ設定部により表示されたＡＶＣプロパティの設定画面の例を示す図である。 ＡＶＣプロパティ設定部により表示されたＡＶＣプロパティの設定画面の例を示す図である。 ＡＶＣプロパティ設定部により表示されたＡＶＣプロパティの設定画面の例を示す図である。 ＡＶＣプロパティ設定部により表示されたＡＶＣプロパティの設定画面の例を示す図である。 ＡＶＣプロパティ設定部により表示されたＡＶＣプロパティの設定画面の例を示す図である。 チャート表示用ＡＶＣコンポーネントに切り替えたときの表示画面の例を示す図である。 図４３に示した文書が、ＡＶＣコンポーネントを切り替えることにより変更された様子を示す図である。 図５５に示した文書に記述されたＡＶＣプロパティの内容を示す図である。 図５５に示した文書に記述されたＡＶＣプロパティの内容を示す図である。 図５５に示した文書に記述されたＡＶＣプロパティの内容を示す図である。 図５５に示した文書に記述されたＡＶＣプロパティの内容を示す図である。 図４９に示した散布図のデータを設定するための画面において、Ｙ軸のデータを変更したときの画面を示す図である。 Ｙ軸のデータのデータ型を変更したときの画面を示す図である。

符号の説明

２０ 文書処理装置、２２ 主制御ユニット、２４ 編集ユニット、２７ 概念解決エンジン、２８ 通知部、３０ ＤＯＭユニット、３２ ＤＯＭ提供部、３４ ＤＯＭ生成部、３６ 出力部、４０ ＣＳＳユニット、４２ ＣＳＳ解析部、４４ ＣＳＳ提供部、４６ レンダリング部、５０ ＨＴＭＬユニット、５２，６２ 制御部、５４，６４ 編集部、５６，６６ 表示部、６０ ＳＶＧユニット、７０ ビューテンプレート制御ユニット、７１ 取得部、７２ 提示部、７４ 受付部、７６ 編集部、７８ ビューテンプレート、８０ ＶＣユニット、８２ マッピング部、８４ 定義ファイル取得部、８６ 定義ファイル生成部、１００ 文書処理装置、３０００ ＡＶＣ制御ユニット、３００２ ＡＶＣプロパティ設定部、３００４ ＡＶＣプロパティ生成部、３００６ 定義ファイル生成部、３０１０ テーブル表示用ＡＶＣコンポーネント、３０２０ チャート表示用ＡＶＣコンポーネント、３０３０ ＵＩパーツ表示用ＡＶＣコンポーネント、３０４０ ツリー表示用ＡＶＣコンポーネント、３０５０ ＡＶＣコンポーネント切替部。

（前提技術）
図１は、前提技術に係る文書処理装置２０の構成を示す。文書処理装置２０は、文書内のデータが階層構造を有する複数の構成要素に分類された構造化文書を処理するが、本前提技術では構造化文書の一例としてＸＭＬ文書を処理する例について説明する。文書処理装置２０は、主制御ユニット２２、編集ユニット２４、ＤＯＭユニット３０、ＣＳＳユニット４０、ＨＴＭＬユニット５０、ＳＶＧユニット６０、及び変換部の一例であるＶＣユニット８０を備える。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。

主制御ユニット２２は、プラグインのロードや、コマンド実行のフレームワークを提供する。編集ユニット２４は、ＸＭＬ文書を編集するためのフレームワークを提供する。文書処理装置２０における文書の表示及び編集機能は、プラグインにより実現されており、文書の種別に応じて必要なプラグインが主制御ユニット２２又は編集ユニット２４によりロードされる。主制御ユニット２２又は編集ユニット２４は、処理対象となるＸＭＬ文書の名前空間を参照して、ＸＭＬ文書がいずれのボキャブラリにより記述されているかを判別し、そのボキャブラリに対応した表示又は編集用のプラグインをロードして表示や編集を実行させる。例えば、文書処理装置２０には、ＨＴＭＬ文書の表示及び編集を行うＨＴＭＬユニット５０、ＳＶＧ文書の表示及び編集を行うＳＶＧユニット６０など、ボキャブラリ（タグセット）ごとに表示系及び編集系がプラグインとして実装されており、ＨＴＭＬ文書を編集するときはＨＴＭＬユニット５０が、ＳＶＧ文書を編集するときはＳＶＧユニット６０が、それぞれロードされる。後述するように、ＨＴＭＬとＳＶＧの双方の構成要素を含む複合文書が処理対象となっている場合は、ＨＴＭＬユニット５０とＳＶＧユニット６０の双方がロードされる。

このような構成によれば、ユーザは、必要な機能のみを選択してインストールし、後から適宜機能を追加又は削除することができるので、プログラムを格納するハードディスクなどの記録媒体の記憶領域を有効に活用することができ、また、プログラム実行時にも、メモリの浪費を防ぐことができる。また、機能拡張性に優れており、開発主体としても、プラグインの形で新たなボキャブラリに対応することが可能なので開発が容易となり、ユーザとしても、プラグインの追加により容易かつ低コストにて機能を追加することができる。

編集ユニット２４は、ユーザインターフェースを介してユーザから編集指示のイベントを受け付け、そのイベントを適切なプラグインなどに通知するともに、イベントの再実行（リドゥ）又は実行の取消（アンドゥ）などの処理を制御する。

ＤＯＭユニット３０は、ＤＯＭ提供部３２、ＤＯＭ生成部３４、及び出力部３６を含み、ＸＭＬ文書をデータとして扱うときのアクセス方法を提供するために定められた文書オブジェクトモデル（Document Object Model：ＤＯＭ）に準拠した機能を実現する。ＤＯＭ提供部３２は、編集ユニット２４に定義されているインタフェースを満たすＤＯＭの実装である。ＤＯＭ生成部３４は、ＸＭＬ文書からＤＯＭツリーを生成する。後述するように、処理対象となるＸＭＬ文書が、ＶＣユニット８０により他のボキャブラリにマッピングされる場合は、マッピング元のＸＭＬ文書に対応するソースツリーと、マッピング先のＸＭＬ文書に対応するデスティネーションツリーが生成される。出力部３６は、例えば編集終了時に、ＤＯＭツリーをＸＭＬ文書として出力する。

ＣＳＳユニット４０は、ＣＳＳ解析部４２、ＣＳＳ提供部４４、及びレンダリング部４６を含み、ＣＳＳに準拠した表示機能を提供する。ＣＳＳ解析部４２は、ＣＳＳの構文を解析するパーサの機能を有する。ＣＳＳ提供部４４は、ＣＳＳオブジェクトの実装であり、ＤＯＭツリーに対してＣＳＳのカスケード処理を行う。レンダリング部４６は、ＣＳＳのレンダリングエンジンであり、ＣＳＳを用いてレイアウトされるＨＴＭＬなどのボキャブラリで記述された文書の表示に用いられる。

ＨＴＭＬユニット５０は、ＨＴＭＬにより記述された文書を表示又は編集する。ＳＶＧユニット６０は、ＳＶＧにより記述された文書を表示又は編集する。これらの表示／編集系は、プラグインの形で実現されており、それぞれ、文書を表示する表示部（Canvas）５６、６６、編集指示を含むイベントを送受信する制御部（Editlet）５２、６２、編集コマンドを受けてＤＯＭに対して編集を行う編集部（Zone）５４、６４を備える。制御部５２又は６２が外部からＤＯＭツリーの編集コマンドを受け付けると、編集部５４又は６４がＤＯＭツリーを変更し、表示部５６又は６６が表示を更新する。これらは、ＭＶＣ（Model-View-Controller）と呼ばれるフレームワークに類似する構成をとっており、概ね、表示部５６及び６６が「View」に、制御部５２及び６２が「Controller」に、編集部５４及び６４とＤＯＭの実体が「Model」に、それぞれ対応する。本前提技術の文書処理装置２０では、ＸＭＬ文書をツリー表示形式で編集するだけでなく、それぞれのボキャブラリに応じた編集を可能とする。例えば、ＨＴＭＬユニット５０は、ＨＴＭＬ文書をワードプロセッサに類似した方式で編集するためのユーザインターフェースを提供し、ＳＶＧユニット６０は、ＳＶＧ文書を画像描画ツールに類似した方式で編集するためのユーザインターフェースを提供する。

ＶＣユニット８０は、マッピング部８２、定義ファイル取得部８４、及び定義ファイル生成部８６を含み、あるボキャブラリにより記述された文書を、他のボキャブラリにマッピングすることにより、マッピング先のボキャブラリに対応した表示編集用プラグインで文書を表示又は編集するためのフレームワークを提供する。本前提技術では、この機能を、ボキャブラリコネクション（Vocabulary Connection：ＶＣ）と呼ぶ。定義ファイル取得部８４は、マッピングの定義を記述したスクリプトファイルを取得する。この定義ファイルは、ノードごとに、ノード間の対応（コネクション）を記述する。このとき、各ノードの要素値や属性値の編集の可否を指定してもよい。また、ノードの要素値や属性値を用いた演算式を記述してもよい。これらの機能については、後で詳述する。マッピング部８２は、定義ファイル取得部８４が取得したスクリプトファイルを参照して、ＤＯＭ生成部３４にデスティネーションツリーを生成させ、ソースツリーとデスティネーションツリーの対応関係を管理する。定義ファイル生成部８６は、ユーザが定義ファイルを生成するためのグラフィカルユーザインターフェースを提供する。

ＶＣユニット８０は、ソースツリーとデスティネーションツリーの間のコネクションを監視し、表示を担当するプラグインにより提供されるユーザインタフェースを介してユーザから編集指示を受け付けると、まずソースツリーの該当するノードを変更する。ＤＯＭユニット３０が、ソースツリーが変更された旨のミューテーションイベントを発行すると、ＶＣユニット８０は、そのミューテーションイベントを受けて、ソースツリーの変更にデスティネーションツリーを同期させるべく、変更されたノードに対応するデスティネーションツリーのノードを変更する。デスティネーションツリーを表示／編集するプラグイン、例えばＨＴＭＬユニット５０は、デスティネーションツリーが変更された旨のミューテーションイベントを受けて、変更されたデスティネーションツリーを参照して表示を更新する。このような構成により、少数のユーザにより利用されるローカルなボキャブラリにより記述された文書であっても、他のメジャーなボキャブラリに変換することで、文書を表示することができるとともに、編集環境が提供される。

文書処理装置２０により文書を表示又は編集する動作について説明する。文書処理装置２０が処理対象となる文書を読み込むと、ＤＯＭ生成部３４が、そのＸＭＬ文書からＤＯＭツリーを生成する。また、主制御ユニット２２又は編集ユニット２４は、名前空間を参照して文書を記述しているボキャブラリを判別する。そのボキャブラリに対応したプラグインが文書処理装置２０にインストールされている場合は、そのプラグインをロードして、文書を表示／編集させる。プラグインがインストールされていない場合は、マッピングの定義ファイルが存在するか否かを確認する。定義ファイルが存在する場合、定義ファイル取得部８４が定義ファイルを取得し、その定義に従って、デスティネーションツリーが生成され、マッピング先のボキャブラリに対応するプラグインにより文書が表示／編集される。複数のボキャブラリを含む複合文書である場合は、後述するように、それぞれのボキャブラリに対応したプラグインにより、文書の該当箇所がそれぞれ表示／編集される。定義ファイルが存在しない場合は、文書のソース又はツリー構造を表示し、その表示画面において編集が行われる。

図２は、処理対象となるＸＭＬ文書の例を示す。このＸＭＬ文書は、生徒の成績データを管理するために用いられる。ＸＭＬ文書のトップノードである構成要素「成績」は、配下に、生徒ごとに設けられた構成要素「生徒」を複数有する。構成要素「生徒」は、属性値「名前」と、子要素「国語」、「数学」、「理科」、「社会」を有する。属性値「名前」は、生徒の名前を格納する。構成要素「国語」、「数学」、「理科」、「社会」は、それぞれ、国語、数学、理科、社会の成績を格納する。例えば、名前が「Ａ」である生徒の国語の成績は「９０」、数学の成績は「５０」、理科の成績は「７５」、社会の成績は「６０」である。以下、この文書で使用されているボキャブラリ（タグセット）を、「成績管理ボキャブラリ」と呼ぶ。

本前提技術の文書処理装置２０は、成績管理ボキャブラリの表示／編集に対応したプラグインを有しないので、この文書をソース表示、ツリー表示以外の方法で表示するためには、前述したＶＣ機能が用いられる。すなわち、成績管理ボキャブラリを、プラグインが用意された別のボキャブラリ、例えば、ＨＴＭＬやＳＶＧなどにマッピングするための定義ファイルを用意する必要がある。ユーザ自身が定義ファイルを作成するためのユーザインターフェースについては後述することにして、ここでは、既に定義ファイルが用意されているとして説明を進める。

図３は、図２に示したＸＭＬ文書をＨＴＭＬで記述された表にマッピングする例を示す。図３の例では、成績管理ボキャブラリの「生徒」ノードを、ＨＴＭＬにおける表（「TABLE」ノード）の行（「TR」ノード）に対応づけ、各行の第１列には属性値「名前」を、第２列には「国語」ノードの要素値を、第３列には「数学」ノードの要素値を、第４列には「理科」ノードの要素値を、第５列には「社会」ノードの要素値を、それぞれ対応付ける。これにより、図２に示したＸＭＬ文書を、ＨＴＭＬの表形式で表示することができる。また、これらの属性値及び要素値は、編集可能であることが指定されており、ユーザがＨＴＭＬによる表示画面上で、ＨＴＭＬユニット５０の編集機能により、これらの値を編集することができる。第６列には、国語、数学、理科、社会の成績の加重平均を算出する演算式が指定されており、生徒の成績の平均点が表示される。このように、定義ファイルに演算式を指定可能とすることにより、より柔軟な表示が可能となり、編集時のユーザの利便性を向上させることができる。なお、第６列は、編集不可であることが指定されており、平均点のみを個別に編集することができないようにしている。このように、マッピング定義において、編集の可否を指定可能とすることにより、ユーザの誤操作を防ぐことができる。

図４（ａ）及び図４（ｂ）は、図２に示したＸＭＬ文書を図３に示した表にマッピングするための定義ファイルの例を示す。この定義ファイルは、定義ファイル用に定義されたスクリプト言語により記述される。定義ファイルには、コマンドの定義と、表示のテンプレートが記述されている。図４（ａ）（ｂ）の例では、コマンドとして、「生徒の追加」と「生徒の削除」が定義されており、それぞれ、ソースツリーにノード「生徒」を挿入する操作と、ソースツリーからノード「生徒」を削除する操作が対応付けられている。また、テンプレートとして、表の第１行に「名前」、「国語」などの見出しが表示され、第２行以降に、ノード「生徒」の内容が表示されることが記述されている。ノード「生徒」の内容を表示するテンプレート中、「text-of」と記述された項は「編集可能」であることを意味し、「value-of」と記述された項は「編集不可能」であることを意味する。また、ノード「生徒」の内容を表示する行のうち、第６列には、「(src:国語 + src:数学 + src:理科 + src:社会) div 4」という計算式が記述されており、生徒の成績の平均が表示されることを意味する。

図５は、図２に示した成績管理ボキャブラリで記述されたＸＭＬ文書を、図３に示した対応によりＨＴＭＬにマッピングして表示した画面の例を示す。表９０の各行には、左から、各生徒の名前、国語の成績、数学の成績、理科の成績、社会の成績、及び平均点が表示されている。ユーザは、この画面上で、ＸＭＬ文書を編集することができる。たとえば、第２行第３列の値を「７０」に変更すると、このノードに対応するソースツリーの要素値、すなわち、生徒「Ｂ」の数学の成績が「７０」に変更される。このとき、ＶＣユニット８０は、デスティネーションツリーをソースツリーに追従させるべく、デスティネーションツリーの該当箇所を変更し、ＨＴＭＬユニット５０が、変更されたデスティネーションツリーに基づいて表示を更新する。したがって、画面上の表においても、生徒「Ｂ」の数学の成績が「７０」に変更され、更に、平均点が「５５」に変更される。

図５に示した画面には、図４（ａ）（ｂ）に示した定義ファイルに定義されたように、「生徒の追加」及び「生徒の削除」のコマンドがメニューに表示される。ユーザがこれらのコマンドを選択すると、ソースツリーにおいて、ノード「生徒」が追加又は削除される。このように、本前提技術の文書処理装置２０では、階層構造の末端の構成要素の要素値を編集するのみではなく、階層構造を編集することも可能である。このようなツリー構造の編集機能は、コマンドの形でユーザに提供されてもよい。また、例えば、表の行を追加又は削除するコマンドが、ノード「生徒」を追加又は削除する操作に対応づけられてもよい。また、他のボキャブラリを埋め込むコマンドがユーザに提供されてもよい。この表を入力用テンプレートとして、穴埋め形式で新たな生徒の成績データを追加することもできる。以上のように、ＶＣ機能により、ＨＴＭＬユニット５０の表示／編集機能を利用しつつ、成績管理ボキャブラリで記述された文書を編集することが可能となる。

図６は、ユーザが定義ファイルを生成するために、定義ファイル生成部８６がユーザに提示するグラフィカルユーザインタフェースの例を示す。画面左側の領域９１には、マッピング元のＸＭＬ文書がツリー表示されている。画面右側の領域９２には、マッピング先のＸＭＬ文書の画面レイアウトが示されている。この画面レイアウトは、ＨＴＭＬユニット５０により編集可能となっており、ユーザは、画面右側の領域９２において、文書を表示するための画面レイアウトを作成する。そして、例えば、マウスなどのポインティングデバイスにより、画面左側の領域９１に表示されたマッピング元のＸＭＬ文書のノードを、画面右側の領域９２に表示されたＨＴＭＬによる画面レイアウト中へドラッグ＆ドロップ操作を行うことにより、マッピング元のノードと、マッピング先のノードとのコネクションが指定される。例えば、要素「生徒」の子要素である「数学」を、ＨＴＭＬ画面の表９０の第１行第３列にドロップすると、「数学」ノードと、３列目の「ＴＤ」ノードの間にコネクションが張られる。各ノードには、編集の可否が指定できるようになっている。また、表示画面中には、演算式を埋め込むこともできる。画面の編集が終わると、定義ファイル生成部８６は、画面レイアウトとノード間のコネクションを記述した定義ファイルを生成する。

ＸＨＴＭＬ、ＭａｔｈＭＬ、ＳＶＧなどの主要なボキャブラリに対応したビューワやエディタは既に開発されているが、図２に示した文書のようなオリジナルなボキャブラリで記述された文書に対応したビューワやエディタを開発するのは現実的でない。しかし、上記のように、他のボキャブラリにマッピングするための定義ファイルを作成すれば、ビューワやエディタを開発しなくても、ＶＣ機能を利用して、オリジナルなボキャブラリで記述された文書を表示・編集することができる。

図７は、定義ファイル生成部８６により生成された画面レイアウトの他の例を示す。図７の例では、成績管理ボキャブラリで記述されたＸＭＬ文書を表示するための画面に、表９０と、円グラフ９３が作成されている。この円グラフ９３は、ＳＶＧにより記述される。後述するように、本前提技術の文書処理装置２０は、一つのＸＭＬ文書内に複数のボキャブラリを含む複合文書を処理することができるので、この例のように、ＨＴＭＬで記述された表９０と、ＳＶＧで記述された円グラフ９３とを、一つの画面上に表示することができる。

図８は、文書処理装置２０によるＸＭＬ文書の編集画面の一例を示す。図８の例では、一つの画面が複数に分割されており、それぞれの領域において、処理対象となるＸＭＬ文書を異なる複数の表示形式により表示している。領域９４には、文書のソースが表示されており、領域９５には、文書のツリー構造が表示されており、領域９６には、図５に示したＨＴＭＬにより記述された表が表示されている。これらのいずれの画面上においても、文書の編集が可能であり、いずれかの画面上でユーザが編集を行うと、ソースツリーが変更され、それぞれの画面の表示を担当するプラグインが、ソースツリーの変更を反映すべく画面を更新する。具体的には、ソースツリーの変更を通知するミューテーションイベントのリスナーとして、それぞれの編集画面の表示を担当するプラグインの表示部を登録しておき、いずれかのプラグイン又はＶＣユニット８０によりソースツリーが変更されたときに、編集画面を表示中の全ての表示部が、発行されたミューテーションイベントを受け取って画面を更新する。このとき、プラグインがＶＣ機能により表示を行っている場合は、ＶＣユニット８０がソースツリーの変更に追従してデスティネーションツリーを変更した後、変更されたデスティネーションツリーを参照してプラグインの表示部が画面を更新する。

例えば、ソース表示及びツリー表示を、専用のプラグインにより実現している場合は、ソース表示用プラグインとツリー表示用プラグインは、デスティネーションツリーを用いず、直接ソースツリーを参照して表示を行う。この場合、いずれかの画面において編集が行われると、ソース表示用プラグインとツリー表示用プラグインは、変更されたソースツリーを参照して画面を更新し、領域９６の画面を担当しているＨＴＭＬユニット５０は、ソースツリーの変更に追従して変更されたデスティネーションツリーを参照して画面を更新する。

ソース表示及びツリー表示は、ＶＣ機能を利用して実現することもできる。すなわち、ソース、ツリー構造をＨＴＭＬによりレイアウトし、そのＨＴＭＬにＸＭＬ文書をマッピングして、ＨＴＭＬユニット５０により表示してもよい。この場合、ソース形式、ツリー形式、表形式の３つのデスティネーションツリーが生成されることになる。いずれかの画面において編集が行われると、ＶＣユニット８０は、ソースツリーを変更した後、ソース形式、ツリー形式、表形式の３つのデスティネーションツリーをそれぞれ変更し、ＨＴＭＬユニット５０は、それらのデスティネーションツリーを参照して、３つの画面を更新する。

このように、一つの画面上に複数の表示形式で文書を表示することにより、ユーザの利便性を向上させることができる。例えば、ユーザは、ソース表示又はツリー表示により文書の階層構造を把握しつつ、表９０などを用いて視覚的に分かりやすい形式で文書を表示し、編集することができる。上記の例では、一つの画面を分割して複数の表示形式による画面を同時に表示したが、一つの画面に一つの表示形式による画面を表示し、表示形式をユーザの指示により切り替え可能としてもよい。この場合、主制御ユニット２２が、ユーザから表示形式の切り替え要求を受け付け、各プラグインに指示して表示を切り替える。

図９は、文書処理装置２０により編集されるＸＭＬ文書の他の例を示す。図９に示したＸＭＬ文書では、ＳＶＧ文書の「foreignObject」タグの中にＸＨＴＭＬ文書が埋め込まれており、さらに、ＸＨＴＭＬ文書の中にＭａｔｈＭＬで記述された数式が入っている。このような場合、編集ユニット２４が、名前空間を参照して、適切な表示系に描画作業を振り分ける。図９の例では、編集ユニット２４は、まず、ＳＶＧユニット６０に四角形を描画させ、つづいて、ＨＴＭＬユニット５０にＸＨＴＭＬ文書を描画させる。さらに、図示しないＭａｔｈＭＬユニットに、数式を描画させる。こうして、複数のボキャブラリを包含する複合文書が適切に表示される。表示結果を図１０に示す。

文書編集中、カーソル（キャリッジ）の位置に応じて、表示されるメニューを切り替えてもよい。すなわち、カーソルが、ＳＶＧ文書が表示された領域内に存在するときは、ＳＶＧユニット６０が提供するメニュー、又はＳＶＧ文書をマッピングするための定義ファイルに定義されたコマンドを表示し、カーソルが、ＸＨＴＭＬ文書が表示された領域内に存在するときは、ＨＴＭＬユニット５０が提供するメニュー、又はＸＨＴＭＬ文書をマッピングするための定義ファイルに定義されたコマンドを表示する。これにより、編集位置に応じて適切なユーザインターフェースを提供することができる。

複合文書において、あるボキャブラリに対応する適切なプラグイン又はマッピング定義ファイルがなかった場合は、そのボキャブラリにより記述された部分は、ソース表示又はツリー表示されてもよい。従来、ある文書に他の文書を埋め込んだ複合文書を開くとき、埋め込まれた文書を表示するアプリケーションがインストールされていないと、その内容を表示することができなかったが、本前提技術では、表示用のアプリケーションが存在しなくても、テキストデータにより構成されたＸＭＬ文書をソース表示又はツリー表示することにより内容を把握することができる。これは、テキストベースであるＸＭＬなどの文書ならではの特徴といえる。

データがテキストベースで記述されることの他の利点として、例えば、複合文書中の、あるボキャブラリにより記述される部分において、同一文書内の他のボキャブラリで記述された部分のデータを参照してもよい。また、文書内で検索を実行する時に、ＳＶＧなどの図に埋め込まれた文字列も検索対象とすることができる。

あるボキャブラリにより記述された文書内に、他のボキャブラリのタグを用いてもよい。このＸＭＬ文書は、妥当（valid）ではないが、整形式（well-formed）であれば、有効なＸＭＬ文書として処理可能である。この場合、挿入された他のボキャブラリのタグは、定義ファイルによりマッピングされてもよい。例えば、ＸＨＴＭＬ文書中に、「重要」、「最重要」などのタグを使用し、これらのタグで囲まれた部分を強調表示してもよいし、重要度の順にソートして表示してもよい。

図１０に示した編集画面において、ユーザにより文書が編集されると、編集された部分を担当するプラグイン又はＶＣユニット８０がソースツリーを変更する。ソースツリーには、ノードごとにミューテーションイベントのリスナーを登録できるようになっており、通常は、各ノードが属するボキャブラリに対応したプラグインの表示部又はＶＣユニット８０がリスナーとして登録される。ＤＯＭ提供部３２は、ソースツリーが変更されると、変更されたノードから上位の階層へたどって、登録されたリスナーがあれば、そのリスナーへミューテーションイベントを発行する。例えば、図９に示した文書において、＜ｈｔｍｌ＞ノードの下位のノードが変更された場合、＜ｈｔｍｌ＞ノードにリスナーとして登録されたＨＴＭＬユニット５０にミューテーションイベントが通知されるとともに、その上位の＜ｓｖｇ＞ノードにリスナーとして登録されたＳＶＧユニット６０にもミューテーションイベントが通知される。このとき、ＨＴＭＬユニット５０は、変更されたソースツリーを参照して表示を更新する。ＳＶＧユニット６０は、自身のボキャブラリに属するノードが変更されていないので、ミューテーションイベントを無視してもよい。

編集の内容によっては、ＨＴＭＬユニット５０による表示の更新に伴って、全体のレイアウトが変わる可能性がある。この場合は、画面のレイアウトを管理する構成、例えば最上位のノードの表示を担当するプラグインにより、プラグインごとの表示領域のレイアウトが更新される。例えば、ＨＴＭＬユニット５０による表示領域が以前より大きくなった場合、ＨＴＭＬユニット５０は、まず自身の担当する部分を描画して、表示領域の大きさを決定する。そして、画面のレイアウトを管理する構成に、変更後の表示領域の大きさを通知し、レイアウトの更新を依頼する。画面のレイアウトを管理する構成は、通知を受けて、プラグインごとの表示領域を再レイアウトする。こうして、編集された部分の表示が適切に更新されるとともに、画面全体のレイアウトが更新される。

つづいて、前提技術の文書処理装置２０を実現する機能構成について更に詳細に説明する。以下の説明では、クラス名などを記載する際には、英字をそのまま用いて記載することにする。

Ａ．概要
インターネットの出現により、ユーザによって処理され管理される文書の数が、ほぼ指数関数的に増加してきた。インターネットの核を形成するウェブ（World Wide Web）は、そのような文書データの大きな受け皿となっている。ウェブは、文書に加えて、このような文書の情報検索システムを提供する。これらの文書は、通常、マークアップ言語により記述される。マークアップ言語のシンプルかつポピュラーな例の一つにＨＴＭＬ（HyperText Markup Language）がある。このような文書は、ウェブの他の位置に格納されている他の文書へのリンクをさらに含む。ＸＭＬ（eXtensible Markup Language）は、さらに高度でポピュラーなマークアップ言語である。ウェブ文書にアクセスし、閲覧するためのシンプルなブラウザが、Ｊａｖａ（登録商標）のようなオブジェクト指向のプログラミング言語で開発されている。

マークアップ言語により記述された文書は、通常、ブラウザや他のアプリケーションの中では、ツリーデータ構造の形で表現される。この構造は、文書を構文解析した結果のツリーに相当する。ＤＯＭ（Document Object Model）は、文書を表現し、操作するために使用される、よく知られたツリーベースのデータ構造モデルである。ＤＯＭは、ＨＴＭＬやＸＭＬ文書などを含む文書を表現するための標準的なオブジェクトのセットを提供する。ＤＯＭは、文書内のコンポーネントを表現するオブジェクトがどのようにつながっているかという標準モデルと、それらのオブジェクトにアクセスしたり操作したりするための標準インタフェイスという、２つの基本的なコンポーネントを含む。

アプリケーション開発者は、独自のデータ構造やＡＰＩ（Application Program Interface）へのインタフェイスとしてＤＯＭをサポートすることができる。他方、文書を作成するアプリケーション開発者は、彼らのＡＰＩの独自インタフェイスではなく、ＤＯＭの標準インタフェイスを使用することができる。したがって、標準を提供するというその能力により、ＤＯＭは、様々な環境、特にウェブにおいて、文書の相互利用を促進させるために有効である。ＤＯＭのいくつかのバージョンが定義されており、異なるプログラミング環境及びアプリケーションによって使用されている。

ＤＯＭツリーは、対応するＤＯＭの内容に基づいた文書の階層的表現である。ＤＯＭツリーは「根（ルート）」、及びルートから発生する１つ以上の「節（ノード）」を含む。ルートが文書全体を表す場合もある。中間のノードは、例えば、テーブル及びそのテーブル中の行及び列のような要素を表すことができる。ＤＯＭツリーの「葉」は、通常、それ以上分解できないテキストや画像のようなデータを表す。ＤＯＭツリーの各ノードは、フォント、サイズ、色、インデントなど、ノードによって表される要素のパラメータを記述する属性に関連付けられてもよい。

ＨＴＭＬは、文書を作成するために一般に用いられる言語であるが、フォーマット及びレイアウト用の言語であり、データ記述のための言語ではない。ＨＴＭＬドキュメントを表現するＤＯＭツリーのノードは、ＨＴＭＬのフォーマッティングタグとして予め定義されたエレメントであって、通常、ＨＴＭＬは、データの詳述や、データのタギング／ラベリングのための機能を提供しないので、ＨＴＭＬドキュメント中のデータに対するクエリを定式化することは多くの場合困難である。

ネットワーク設計者たちの目指すものは、ウェブ上の文書がソフトウェアアプリケーションによってクエリされたり処理されたりできるようにすることである。表示方法とは無関係で、階層的に構造化された言語であれば、そのようにクエリされ処理されることができる。ＸＭＬ（eXtensible Markup Language）のようなマークアップ言語は、これらの特徴を提供することができる。

ＨＴＭＬとは逆に、ＸＭＬのよく知られた利点は、文書の設計者が自由に定義可能な「タグ」を使用して、データ要素にラベルを付けることが可能である点である。このようなデータ要素は、階層的に構造化することができる。さらに、ＸＭＬ文書は、文書内で用いられるタグ及びそれらの相互関係の「文法」を記述した文書型定義を含むことができる。構造化されたＸＭＬ文書の表示方法を定義するために、ＣＳＳ（Cascading Style Sheet）又はＸＳＬ（XML Style Language）が使用される。ＤＯＭ、ＨＴＭＬ、ＸＭＬ、ＣＳＳ、ＸＳＬ及び関連する言語の特徴に関する付加的な情報は、ウェブからも得ることができる。（例えば、http://www.w3.org/TR/）

Ｘｐａｔｈは、ＸＭＬ文書の部分の位置を指定するために共通のシンタックス及びセマンティクスを提供する。機能性の例として、ＸＭＬ文書に対応するＤＯＭツリーのトラバース（移動）がある。それは、ＸＭＬ文書の様々な表現に関連した文字列、数、及びブーリアン文字の操作のための基本的な機能を提供する。Ｘｐａｔｈは、ＸＭＬ文書の見た目のシンタックス、例えば、テキストとしてみたときに何行目であるとか何文字目であるとかといった文法ではなく、ＤＯＭツリーなどの抽象的・論理的な構造において動作する。Ｘｐａｔｈを使用することにより、例えばＸＭＬ文書のＤＯＭツリー内の階層的構造を通じて場所を指定することができる。アドレシングのための使用の他に、Ｘｐａｔｈは、ＤＯＭツリー中のノードがパターンにマッチするか否かをテストするために使用されるようにも設計されている。ＸＰａｔｈに関する更なる詳細は、http://www.w3.org/TR/xpathで得ることができる。

ＸＭＬの既知の利点及び特徴により、マークアップ言語（例えばＸＭＬ）で記述された文書を扱うことができ、文書を作成及び修正するためのユーザフレンドリーなインタフェイスを提供することができる、効果的な文書処理システムが求められる。

ここで説明されるシステムの構成のうちのいくつかは、ＭＶＣ（Model-View-Controller）と呼ばれる、よく知られたＧＵＩ（Graphical User Interface）パラダイムを用いて説明される。ＭＶＣパラダイムは、アプリケーション又はアプリケーションのインタフェイスの一部を、３つの部分、すなわち、モデル、ビュー、コントローラに分割する。ＭＶＣは、元は、ＧＵＩの世界に、従来の入力、処理、出力の役割を割り当てるために開発された。
［入力］ → ［処理］ → ［出力］
［コントローラ］→ ［モデル］ → ［ビュー］

ＭＶＣパラダイムによれば、外界のモデリング、ユーザへの視覚的なフィードバック、及びユーザの入力は、モデル（Ｍ）、ビュー（Ｖ）、及びコントローラ（Ｃ）オブジェクトにより分離されて扱われる。コントローラは、ユーザからのマウスとキーボード入力のような入力を解釈し、これらのユーザアクションを、適切な変更をもたらすためにモデル及び／又はビューに送られるコマンドにマップするように作用する。モデルは、１以上のデータ要素を管理するように作用し、その状態に関するクエリに応答し、状態を変更する指示に応答する。ビューは、ディスプレイの長方形の領域を管理するように作用し、グラフィクスとテキストの組合せによりユーザにデータを提示する機能を有する。

Ｂ．文書処理システムの全体構成
文書処理システムの実施例は、図１１−２９に関連して明らかにされる。

図１１（ａ）は、後述するタイプの文書処理システムの基礎として機能する要素の従来の構成例を示す。構成１０は、通信経路１３によりメモリ１２に接続されたＣＰＵ又はマイクロプロセッサ１１などの形式のプロセッサを含む。メモリ１２は、現在又は将来に利用可能な任意のＲＯＭ及び／又はＲＡＭの形式であってもよい。通信経路１３は、典型的にはバスとして設けられる。マウス、キーボード、音声認識システムなどのユーザ入力装置１４及び表示装置１５（又は他のユーザインタフェイス）に対する入出力インタフェイス１６も、プロセッサ１１とメモリ１２の通信のためのバスに接続される。この構成は、スタンドアロンであってもよいし、複数の端末及び１以上のサーバが接続されてネットワーク化された形式であってもよいし、既知のいかなる方式により構成されてもよい。本発明は、これらのコンポーネントの配置、集中又は分散されたアーキテクチャー、あるいは様々なコンポーネントの通信方法により制限されない。

さらに、本システム及びここで議論される実施例は、様々な機能性を提供するいくつかのコンポーネント及びサブコンポーネントを含むものとして議論される。これらのコンポーネント及びサブコンポーネントは、注目された機能性を提供するために、ハードウェアとソフトウェアの組合せだけでなく、ハードウェアのみ、ソフトウェアのみによっても実現されうる。さらに、ハードウェア、ソフトウェア、及びそれらの組合せは、汎用の計算装置、専用のハードウェア、又はそれらの組合せにより実現されうる。したがって、コンポーネント又はサブコンポーネントの構成は、コンポーネント又はサブコンポーネントの機能性を提供するための特定のソフトウェアを実行する汎用／専用の計算装置を含む。

図１１（ｂ）は、文書処理システムの一例の全体のブロック図を示す。このような文書処理システムにおいて文書が生成され編集される。これらの文書は、例えばＸＭＬなど、マークアップ言語の特徴を有する任意の言語により記述されてもよい。また、便宜上、特定のコンポーネント及びサブコンポーネントの用語及び表題を創造した。しかしながら、これらは、この開示の一般的な教示の範囲を制限するために解釈されるべきではない。

文書処理システムは、２つの基本的な構成を有するものととらえることができる。第１の構成は、文書処理システムが動作する環境である「実行環境」１０１である。例えば、実行環境は、文書の処理中及び管理中に、ユーザだけでなくシステムも支援する、基本的なユーティリティ及び機能を提供する。第２の構成は、実行環境において走るアプリケーションから構成される「アプリケーション」１０２である。これらのアプリケーションは、文書自身及び文書の様々な表現を含む。

１．実行環境
実行環境１０１のキーとなるコンポーネントはProgramInvoker（プログラムインボーカ：プログラム起動部）１０３である。ProgramInvoker１０３は、文書処理システムを起動するためにアクセスされる基本的なプログラムである。例えば、ユーザが文書処理システムにログオンして開始するとき、ProgramInvoker１０３が実行される。ProgramInvoker１０３は、例えば、文書処理システムにプラグインとして加えられた機能を読み出して実行させたり、アプリケーションを開始して実行させたり、文書に関連するプロパティを読み出すことができる。ProgramInvoker１０３の機能はこれらに限定されない。ユーザが実行環境内で実行されるように意図されたアプリケーションを起動したいとき、ProgramInvoker１０３は、そのアプリケーションを見つけ、それを起動して、アプリケーションを実行する。

ProgramInvoker１０３には、プラグインサブシステム１０４、コマンドサブシステム１０５、及びResource（リソース）モジュール１０９などのいくつかのコンポーネントがアタッチされている。これらの構成については、以下に詳述する。

ａ）プラグインサブシステム
プラグインサブシステム１０４は、文書処理システムに機能を追加するための高度に柔軟で効率的な構成として使用される。プラグインサブシステム１０４は、また、文書処理システムに存在する機能を修正又は削除するために使用することができる。さらに、種々様々の機能をプラグインサブシステムを使用して追加又は修正することができる。例えば、画面上への文書の描画を支援するように作用するEditlet（エディットレット：編集部）機能を追加することもできる。Editletプラグインは、システムに追加されるボキャブラリの編集も支援する。

プラグインサブシステム１０４は、ServiceBroker（サービスブローカ：サービス仲介部）１０４１を含む。ServiceBroker１０４１は、文書処理システムに加えられるプラグインを管理することにより、文書処理システムに加えられるサービスを仲介する。

所望の機能性を実現する個々の機能は、Service（サービス）１０４２の形でシステムに追加される。利用可能なService１０４２のタイプは、Application（アプリケーション）サービス、ZoneFactory（ゾーンファクトリ：ゾーン生成部）Service、Editlet（エディットレット：編集部）Service、CommandFactory（コマンドファクトリ：コマンド生成部）Service、ConnectXPath（コネクトＸＰａｔｈ：ＸＰａｔｈ管理部）Service、CSSComputation（ＣＳＳコンピューテーション：ＣＳＳ計算部）Serviceなどを含むが、これらに限定されない。これらのService、及びシステムの他の構成とそれらとの関係は、文書処理システムについてのよりよい理解のために、以下に詳述される。

プラグインとServiceの関係は以下の通りである。プラグインは、１以上のServiceProvider（サービスプロバイダ：サービス提供部）を含むことができるユニットである。それぞれのServiceProviderは、それに関連したServiceの１以上のクラスを有する。例えば、適切なソフトウェアアプリケーションを有する単一のプラグインを使用することにより、１以上のServiceをシステムに追加することができ、これにより、対応する機能をシステムに追加することができる。

ｂ）コマンドサブシステム
コマンドサブシステム１０５は、文書の処理に関連したコマンドの形式の命令を実行するために使用される。ユーザは、一連の命令を実行することにより、文書に対する操作を実行することができる。例えば、ユーザは、コマンドの形で命令を発行することにより、文書処理システム中のＸＭＬ文書に対応するＸＭＬのＤＯＭツリーを編集し、ＸＭＬ文書を処理する。これらのコマンドは、キーストローク、マウスクリック、又は他の有効なユーザインタフェイスアクションを使用して入力されてもよい。１つのコマンドにより１以上の命令が実行されることもある。この場合、これらの命令が１つのコマンドにラップ（包含）され、連続して実行される。例えば、ユーザが、誤った単語を正しい単語に置換したいとする。この場合、第１の命令は、文書中の誤った単語を発見することであり、第２の命令は、誤った単語を削除することであり、第３の命令は、正しい単語を挿入することであってもよい。これらの３つの命令が１つのコマンドにラップされてもよい。

コマンドは、関連した機能、例えば、後で詳述する「アンドゥ」機能を有してもよい。これらの機能は、オブジェクトを生成するために使用されるいくつかの基本クラスにも割り当てられてもよい。

コマンドサブシステム１０５のキーとなるコンポーネントは、選択的にコマンドを与え、実行するように作用するCommandInvoker（コマンドインボーカ：コマンド起動部）１０５１である。図１１（ｂ）には、１つのCommandInvokerのみが示されているが、１以上のCommandInvokerが使用されてもよく、１以上のコマンドが同時に実行されてもよい。CommandInvoker１０５１は、コマンドを実行するために必要な機能及びクラスを保持する。動作において、実行されるべきCommand（コマンド：命令）１０５２は、Queue（キュー）１０５３に積まれる。CommandInvokerは、連続的に実行するコマンドスレッドを生成する。CommandInvoker内で既に実行中のCommandがなければ、CommandInvoker１０５１により実行されるように意図されたCommand１０５２が実行される。CommandInvokerが既にコマンドを実行している場合、新しいCommandは、Queue１０５３の最後に積まれる。しかしながら、それぞれのCommandInvoker１０５１では、一度に１つのCommandのみが実行される。指定されたCommandの実行に失敗した場合、CommandInvoker１０５１は例外処理を実行する。

CommandInvoker１０５１により実行されるCommandの型は、UndoableCommand（取消可能コマンド）１０５４、AsynchronousCommand（非同期コマンド）１０５５、及びVCCommand（ＶＣコマンド）１０５６を含むが、これらに限定されない。UndoableCommand１０５４は、ユーザが望めば、そのCommandの結果を取り消すことが可能なCommandである。UndoableCommandの例として、切り取り、コピー、テキストの挿入、などがある。動作において、ユーザが文書の一部を選択し、その部分に切り取りコマンドを適用するとき、UndoableCommandを用いることにより、切り取られた部分は、必要であれば、「切り取られていない」ようにすることができる。

VCCommand１０５６は、ボキャブラリコネクション記述子（Vocabulary Connection Descriptor：ＶＣＤ）スクリプトファイルに格納される。これらは、プログラマにより定義されうるユーザ指定のCommandである。Commandは、例えば、ＸＭＬフラグメントを追加したり、ＸＭＬフラグメントを削除したり、属性を設定したりするための、より抽象的なCommandの組合せであってもよい。これらのCommandは、特に、文書の編集に焦点を合わせている。

AsynchronousCommand１０５５は、文書のロードや保存など、システムよりのCommandであり、UndoableCommandやVCCommandとは別に、非同期的に実行される。AsynchronousCommandは、UndoableCommandではないので、取り消すことはできない。

ｃ）リソース
Resource１０９は、様々なクラスに、いくつかの機能を提供するオブジェクトである。例えば、ストリングリソース、アイコン、及びデフォルトキーバインドは、システムで使用されるResourceの例である。

２．アプリケーションコンポーネント
文書処理システムの第２の主要な特徴であるアプリケーションコンポーネント１０２は、実行環境１０１において実行される。アプリケーションコンポーネント１０２は、実際の文書と、システム内における文書の様々な論理的、物理的な表現を含む。さらに、アプリケーションコンポーネント１０２は、文書を管理するために使用されるシステムの構成を含む。アプリケーションコンポーネント１０２は、さらに、UserApplication（ユーザアプリケーション）１０６、アプリケーションコア１０８、ユーザインタフェイス１０７、及びCoreComponent（コアコンポーネント）１１０を含む。

ａ）ユーザアプリケーション
UserApplication１０６は、ProgramInvoker１０３と共にシステム上にロードされる。UserApplication１０６は、文書と、文書の様々な表現と、文書と対話するために必要なユーザインタフェイスとをつなぐ接着剤となる。例えば、ユーザが、プロジェクトの一部である文書のセットを生成したいとする。これらの文書がロードされると、文書の適切な表現が生成される。ユーザインタフェイス機能は、UserApplication１０６の一部として追加される。言いかえれば、UserApplication１０６は、ユーザがプロジェクトの一部を形成する文書と対話することを可能とする文書の表現と、文書の様々な態様とを、共に保持する。一旦UserApplication１０６が生成されると、ユーザがプロジェクトの一部を形成する文書との対話を望むたびに、ユーザは簡単に実行環境上にUserApplication１０６をロードすることができる。

ｂ）コアコンポーネント
CoreComponent１１０は、複数のPane（ペイン）の間で文書を共有する方法を提供する。後で詳述するように、Paneは、ＤＯＭツリーを表示し、画面の物理的なレイアウトを扱う。例えば、物理的な画面は、個々の情報の断片を描写する画面内の複数のPaneからなる。ユーザから画面上に見える文書は、１又はそれ以上のPaneに出現しうる。また、２つの異なる文書が画面上で２つの異なるPaneに現れてもよい。

図１１（ｃ）に示されるように、画面の物理的なレイアウトもツリーの形式になっている。Paneは、RootPane（ルートペイン）１０８４にもなり得るし、SubPane（サブペイン）１０８５にもなり得る。RootPane１０８４は、Paneのツリーの根に当たるPaneであり、SubPane１０８５は、RootPane１０８４以外の任意のPaneである。

CoreComponent１１０は、さらに、フォントを提供し、ツールキットなど、文書のための複数の機能的な操作のソースの役割を果たす。CoreComponent１１０により実行されるタスクの一例に、複数のPane間におけるマウスカーソルの移動がある。実行されるタスクの他の例として、あるPane中の文書の一部をマークし、それを異なる文書を含む別のPane上にコピーする。

ｃ）アプリケーションコア
上述したように、アプリケーションコンポーネント１０２は、システムにより処理され管理される文書から構成される。これは、システム内における文書の様々な論理的及び物理的な表現を含む。アプリケーションコア１０８は、アプリケーションコンポーネント１０２の構成である。その機能は、実際の文書を、それに含まれる全てのデータとともに保持することである。アプリケーションコア１０８は、DocumentManager（ドキュメントマネージャ：文書管理部）１０８１及びDocument（ドキュメント：文書）１０８２自身を含む。

DocumentManager１０８１の様々な態様を以下に詳述する。DocumentManager１０８１は、Document１０８２を管理する。DocumentManager１０８１は、RootPane１０８４、SubPane１０８５、ClipBoard（クリップボード）ユーティリティ１０８７、及びSnapShot（スナップショット）ユーティリティ１０８８にも接続される。ClipBoardユーティリティ１０８７は、ユーザがクリップボードに加えることを決定した文書の部分を保持する方法を提供する。例えば、ユーザが、文書の一部を切り取り、後で再考するために新規文書にそれを保存することを望んだとする。このような場合、切り取られた部分がClipBoardに追加される。

つづいて、SnapShotユーティリティ１０８８についても説明する。SnapShotユーティリティ１０８８は、アプリケーションがある状態から別の状態まで移行するときに、アプリケーションの現在の状態を記憶することを可能とする。

ｄ）ユーザインタフェイス
アプリケーションコンポーネント１０２の別の構成は、ユーザがシステムと物理的に対話する手段を提供するユーザインタフェイス１０７である。例えば、ユーザインタフェイスは、ユーザが文書をアップロードしたり、削除したり、編集したり、管理したりするために使用される。ユーザインタフェイスは、Frame（フレーム）１０７１、MenuBar（メニューバー）１０７２、StatusBar（ステータスバー）１０７３、及びURLBar（ＵＲＬバー）１０７４を含む。

Frame１０７１は、一般に知られているように、物理的な画面のアクティブな領域であるとみなされる。MenuBar１０７２は、ユーザに選択を提供するメニューを含む画面領域である。StatusBar１０７３は、アプリケーションの実行状態を表示する画面領域である。URLBar１０７４は、インターネットをナビゲートするためにＵＲＬアドレスを入力する領域を提供する。

Ｃ．文書管理及び関連するデータ構造
図１２は、DocumentManager１０８１の詳細を示す。これは、文書処理システム内で文書を表現するために用いられるデータ構造及び構成を含む。分かりやすくするために、このサブセクションで説明される構成は、ＭＶＣパラダイムを用いて説明される。

DocumentManager１０８１は、文書処理システム内にある全ての文書を保持しホストするDocumentContainer（ドキュメントコンテナ：文書コンテナ）２０３を含む。DocumentManager１０８１にアタッチされたツールキット２０１は、DocumentManager１０８１により使用される様々なツールを提供する。例えば、DomService（ＤＯＭサービス）は、文書に対応するＤＯＭを生成し、保持し、管理するために必要とされる全ての機能を提供するために、ツールキット２０１により提供されるツールである。ツールキット２０１により提供される別のツールであるIOManager（入出力管理部）は、システムへの入力及びシステムからの出力を管理する。同様に、StreamHandler（ストリームハンドラ）は、ビットストリームによる文書のアップロードを扱うツールである。これらのツールは、図中に特に示さず、参照番号を割り当てないが、ツールキット２０１のコンポーネントを形成する。

ＭＶＣパラダイムの表現によれば、モデル（Ｍ）は、文書のＤＯＭツリーモデル２０２を含む。前述したように、全ての文書は、文書処理システムにおいてＤＯＭツリーとして表現される。文書は、また、DocumentContainer２０３の一部を形成する。

１．ＤＯＭモデル及びゾーン
文書を表現するＤＯＭツリーは、Node（ノード）２０２１を有するツリーである。ＤＯＭツリーの部分集合であるZone（ゾーン）２０９は、ＤＯＭツリー内の１以上のNodeの関連領域を含む。例えば、画面上で文書の一部のみを表示し得るが、この可視化された文書の一部はZone２０９を用いて表示される。Zoneは、ZoneFactory（ゾーンファクトリ：ゾーン生成部）２０５と呼ばれるプラグインを用いて、生成され、取り扱われ、処理される。ZoneはＤＯＭの一部を表現するが、１以上の「名前空間」を使用してもよい。よく知られているように、名前空間は、名前空間内でユニークな名前の集合である。換言すれば、名前空間内に同じ名前は存在しない。

２．Facet及びFacetとZoneとの関係
Facet（ファセット）２０２２は、ＭＶＣパラダイムのモデル（Ｍ）部分内の別の構成である。Facetは、ZoneにおいてNodeを編集するために使用される。Facet２０２２は、Zone自身の内容に影響を与えずに実行することができる手続（プロシージャ）を使用して、ＤＯＭへのアクセスを編成する。次に説明するように、これらの手続は、Nodeに関連した重要で有用な操作を実行する。

各Nodeは、対応するFacetを有する。ＤＯＭの中のNodeを直接操作する代わりに、操作を実行するためにFacetを使用することによって、ＤＯＭの保全性は保護される。操作がNode上で直接実行される場合、いくつかのプラグインがＤＯＭを同時に変更することができ、その結果矛盾を引き起こす。

Ｗ３Ｃが策定したＤＯＭの標準規格は、Nodeを操作するための標準的なインタフェイスを定義するが、実際には、ボキャブラリごと又はNodeごとに特有の操作があるので、これらの操作をＡＰＩとして用意しておくのが好都合である。文書処理システムでは、このような各Nodeに特有のＡＰＩをFacetとして用意し、各Nodeにアタッチする。これにより、ＤＯＭの標準規格に準拠しつつ、有用なＡＰＩを付加することができる。また、ボキャブラリごとに特有のＤＯＭを実装するのではなく、標準的なＤＯＭの実装に、後から特有のＡＰＩを付加するようにすることで、多様なボキャブラリを統一的に処理することができるともに、複数のボキャブラリが任意の組合せで混在した文書を適切に処理することができる。

ボキャブラリは、名前空間に属するタグ（例えばＸＭＬのタグ）のセットである。上述したように、名前空間は、ユニークな名前（ここではタグ）のセットを有する。ボキャブラリは、ＸＭＬ文書を表現するＤＯＭツリーのサブツリーとして現れる。このサブツリーはZoneを含む。特定の例においては、タグセットの境界はZoneによって定義される。Zone２０９は、ZoneFactory２０５と呼ばれるServiceを利用して生成される。上述したように、Zone２０９は、文書を表現するＤＯＭツリーの一部の内部表現である。このような文書の一部へのアクセスを提供するために、論理的な表現が要求される。この論理的表現は、文書が画面上で論理的にどのように表現されるかについてコンピュータに通知する。Canvas（キャンバス）２１０は、Zoneに対応する論理的なレイアウトを提供するように作用するServiceである。

他方、Pane２１１は、Canvas２１０により提供される論理的なレイアウトに対応する物理的な画面レイアウトである。実際、ユーザは表示画面上で文字や画像によって文書のレンダリングのみを見る。したがって、文書は、画面上に文字や画像を描画するプロセスにより、画面上に描写されなければならない。文書は、Pane２１１により提供される物理的なレイアウトに基づいて、Canvas２１０により画面上に描写される。

Zone２０９に対応するCanvas２１０は、Editlet２０６を使用して生成される。文書のＤＯＭは、Editlet２０６及びCanvas２１０を使用して編集される。元の文書の完全性を維持するために、Editlet２０６及びCanvas２１０は、Zone２０９における１以上のNodeに対応するFacetを使用する。これらのServiceは、Zone及びＤＯＭ内のNodeを直接操作しない。Facetは、Command２０７を利用して操作される。

ユーザは、一般に、画面上のカーソルを移動させたり、コマンドをタイプしたりすることによって、画面と対話する。画面上の論理的なレイアウトを提供するCanvas２１０は、このカーソル操作を受け付ける。Canvas２１０は、対応するアクションをFacetに実行させることができる。この関係により、カーソルサブシステム２０４は、DocumentManager１０８１に対して、ＭＶＣパラダイムのコントローラ（Ｃ）として機能する。Canvas２１０は、イベントを扱うタスクも有する。例えば、Canvas２１０は、マウスクリック、フォーカス移動、及びユーザにより起こされた同様のアクションなどのイベントを扱う。

３．Zone、Facet、Canvas及びPaneの間の関係の概要
文書処理システム内の文書は、少なくとも４つの観点から見ることができる。すなわち、１）文書処理システムにおいて文書の内容及び構造を保持するために用いられるデータ構造、２）文書の保全性に影響を与えずに文書の内容を編集する手段、３）文書の画面上の論理的なレイアウト、４）文書の画面上の物理的なレイアウト、である。Zone、Facet、Canvas及びPaneは、前述の４つの観点に相当する、文書処理システムのコンポーネントをそれぞれ表す。

４．アンドゥサブシステム
上述したように、文書に対するいかなる変更（例えば編集）も取消可能であることが望ましい。例えば、ユーザが編集操作を実行し、次に、その変更の取消を決定したとする。図１２に関連して、アンドゥサブシステム２１２は、文書管理部の取消可能なコンポーネントを実現する。UndoManager（アンドゥマネージャ：アンドゥ管理部）２１２１は、ユーザによって取り消される可能性のある全ての文書に対する操作を保持する。

例えば、ユーザが、文書中の単語を別の単語に置換するコマンドを実行したとする。その後、ユーザは考え直し、元の単語に戻すことを決定したとする。アンドゥサブシステム２１２は、このような操作を支援する。UndoManager２１２１は、このようなUndoableEdit（アンドゥアブルエディット：取消可能な編集）２１２２の操作を保持する。

５．カーソルサブシステム
前述したように、ＭＶＣのコントローラ部分は、カーソルサブシステム２０４を備えてもよい。カーソルサブシステム２０４は、ユーザから入力を受け付ける。これらの入力は、一般にコマンド及び／又は編集操作の性格を有している。したがって、カーソルサブシステム２０４は、DocumentManager１０８１に関連したＭＶＣパラダイムのコントローラ（Ｃ）部分であると考えることができる。

６．ビュー
前述したように、Canvas２１０は、画面上に提示されるべき文書の論理的なレイアウトを表す。ＸＨＴＭＬ文書の例では、Canvas２１０は、文書が画面上でいかに見えるかを論理的に表現したボックスツリー２０８を含んでもよい。このボックスツリー２０８は、DocumentManager１０８１に関連したＭＶＣパラダイムのビュー（Ｖ）部分に含まれよう。

Ｄ．ボキャブラリコネクション
文書処理システムの重要な特徴は、ＸＭＬ文書を、他の表現にマップして取り扱うことが可能で、かつ、マップした先の表現を編集すると、その編集が元のＸＭＬ文書に整合性を保ちつつ反映される環境を提供することにある。

マークアップ言語により記述された文書、例えばＸＭＬ文書は、文書型定義により定義されたボキャブラリに基づいて作成されている。ボキャブラリは、タグのセットである。ボキャブラリは、任意に定義されてもよいため、無限に多くのボキャブラリが存在しうる。しかしながら、多数の可能なボキャブラリのそれぞれに対して専用の処理／管理環境を提供するのは現実的ではない。ボキャブラリコネクションは、この問題を解決する方法を提供する。

例えば、文書は２以上のマークアップ言語により記述されてもよい。文書は、例えば、ＸＨＴＭＬ（eXtensible HyperText Markup Language）、ＳＶＧ（Scalable Vector Graphics）、ＭａｔｈＭＬ（Mathematical Markup Language）、その他のマークアップ言語により記述されてもよい。換言すれば、マークアップ言語は、ＸＭＬにおけるボキャブラリやタグセットと同様に見なされてもよい。

ボキャブラリは、ボキャブラリプラグインを用いて処理される。文書処理システムにおいてプラグインが利用不可能であるボキャブラリにより記述された文書は、プラグインが利用可能である別のボキャブラリの文書にマッピングすることにより表示される。この特徴により、プラグインが用意されていないボキャブラリの文書も適切に表示することができる。

ボキャブラリコネクションは、定義ファイルを取得し、取得した定義ファイルに基づいて２つの異なるボキャブラリの間でマッピングする能力を含む。あるボキャブラリで記述された文書は、別のボキャブラリにマッピングすることができる。このように、ボキャブラリコネクションは、文書がマッピングされるボキャブラリに対応した表示／編集プラグインにより文書を表示し編集することを可能にする。

上述したように、各文書は、一般に複数のノードを有するＤＯＭツリーとして文書処理システムにおいて記述される。「定義ファイル」は、それぞれのノードについて、そのノードと他のノードとの対応を記述する。各ノードの要素値及び属性値が編集可能か否かが指定される。ノードの要素値又は属性値を用いた演算式が記述されてもよい。

マッピングという特徴を利用して、定義ファイルを適用したデスティネーションＤＯＭツリーが生成される。このように、ソースＤＯＭツリーとデスティネーションＤＯＭツリーの関係が構築され保持される。ボキャブラリコネクションは、ソースＤＯＭツリーとデスティネーションＤＯＭツリーの対応を監視する。ユーザから編集指示を受けると、ボキャブラリコネクションは、ソースＤＯＭツリーの関連したノードを変更する。ソースＤＯＭツリーが変更されたことを示す「ミューテーションイベント」が発行され、デスティネーションＤＯＭツリーがそれに応じて変更される。

ボキャブラリコネクションの使用により、少数のユーザのみに知られていた比較的マイナーなボキャブラリを、別のメジャーなボキャブラリに変換することができる。したがって、少数のユーザによって利用されるマイナーなボキャブラリであっても、文書を適切に表示し、望ましい編集環境を提供することができる。

このように、文書処理システムの一部であるボキャブラリコネクションサブシステムは、文書の複数の表現を可能にする機能を提供する。

図１３は、ボキャブラリコネクション（ＶＣ：Vocabulary Connection）サブシステム３００を示す。ＶＣサブシステム３００は、同一の文書の２つの代替表現の整合性を維持する方法を提供する。例えば、２つの表現は、同一文書の、２つの異なるボキャブラリによる表現であってもよい。前述したように、一方はソースＤＯＭツリーであってもよく、他方はデスティネーションＤＯＭツリーであってもよい。

１．ボキャブラリコネクションサブシステム
ボキャブラリコネクションサブシステム３００の機能は、VocabularyConnection３０１と呼ばれるプラグインを使用して、文書処理システムにおいて実現される。文書が表現されるVocabulary３０５ごとに、対応するプラグインが要求される。例えば、文書の一部がＨＴＭＬで記述され、残りがＳＶＧで記述されている場合、ＨＴＭＬとＳＶＧに対応するボキャブラリプラグインが要求される。

VocabularyConnectionプラグイン３０１は、適切なVocabulary３０５の文書に対応した、Zone２０９又はPane２１１のための適切なVCCanvas（ボキャブラリコネクションキャンバス）３１０を生成する。VocabularyConnection３０１を用いて、ソースＤＯＭツリー内のZone２０９に対する変更は、変換ルールにより、別のＤＯＭツリー３０６の対応するZoneに伝達される。変換ルールは、ボキャブラリコネクション記述子（Vocabulary Connection Descriptor：ＶＣＤ）の形式で記述される。このようなソースＤＯＭとデスティネーションＤＯＭの間の変換に対応するそれぞれのＶＣＤファイルについて、対応するVCManager（ボキャブラリコネクションマネージャ）３０２が生成される。

２．Connector
Connector３０４は、ソースＤＯＭツリーのソースノードと、デスティネーションＤＯＭツリーのデスティネーションノードとを接続する。Connector３０４は、ソースＤＯＭツリー中のソースノード、及びソースノードに対応するソース文書に対する修正（変更）を見るために作用する。そして、対応するデスティネーションＤＯＭツリーのノードを修正する。Connector３０４は、デスティネーションＤＯＭツリーを修正することができる唯一のオブジェクトである。例えば、ユーザは、ソース文書、及び対応するソースＤＯＭツリーに対してのみ修正を行うことができる。その後、Connector３０４がデスティネーションＤＯＭツリーに、対応する修正を行う。

Connector３０４は、ツリー構造を形成するために、論理的にリンクされる。Connector３０４により形成されたツリーは、ConnectorTree（コネクタツリー）と呼ばれる。Connector３０４は、ConnectorFactory（コネクタファクトリ：コネクタ生成部）３０３と呼ばれるServiceを用いて生成される。ConnectorFactory３０３は、ソース文書からConnector３０４を生成し、それらをリンクしてConnectorTreeを形成する。VocabularyConnectionManager３０２は、ConnectorFactory３０３を保持する。

前述したように、ボキャブラリは名前空間におけるタグのセットである。図示されるように、Vocabulary３０５は、VocabularyConnection３０１によって文書に対して生成される。これは、文書ファイルを解析し、ソースＤＯＭとデスティネーションＤＯＭの間の写像のための適切なVocabularyConnectionManager３０２を生成することにより行われる。さらに、Connectorを生成するConnectorFactory３０３と、Zone２０９を生成するZoneFactory２０５と、Zone内のノードに対応するCanvasを生成するEditlet２０６との間の適切な関係が作られる。ユーザがシステムから文書を処分又は削除するとき、対応するVocabularyConnectionManager３０２が削除される。

Vocabulary３０５は、VCCanvas３１０を生成する。さらに、Connector３０４及びデスティネーションＤＯＭツリー３０６が対応して生成される。

ソースＤＯＭ及びCanvasは、それぞれ、モデル（Ｍ）及びビュー（Ｖ）に対応する。しかしながら、このような表現は、ターゲットのボキャブラリが画面上に描写可能である場合に限って意味がある。描写は、ボキャブラリプラグインにより行われる。ボキャブラリプラグインは、主要なボキャブラリ、例えば、ＸＨＴＭＬ、ＳＶＧ、ＭａｔｈＭＬについて提供される。ボキャブラリプラグインは、ターゲットのボキャブラリに関連して使用される。これらは、ボキャブラリコネクション記述子を用いてボキャブラリ間でマッピングする方法を提供する。

このようなマッピングは、ターゲットのボキャブラリが、マッピング可能で、画面上に描写される方法が予め定義されたものである場合にのみ意味がある。このようなレンダリング方法は、例えばＸＨＴＭＬなどのように、Ｗ３Ｃなどの組織により定義された標準規格となっている。

ボキャブラリコネクションが必要であるとき、VCCanvasが使用される。この場合、ソースのビューを直接生成することができないので、ソースのCanvasは生成されない。この場合、VCCanvasが、ConnectorTreeを使用して生成される。このVCCanvasは、イベントの変換のみを扱い、画面上の文書の描写を援助しない。

３．DestinationZone、Pane、及びCanvas
上述したように、ボキャブラリコネクションサブシステムの目的は、同一の文書の２つの表現を同時に生成し保持することである。第２の表現も、ＤＯＭツリーの形式であり、これはデスティネーションＤＯＭツリーとして既に説明した。第２の表現における文書を見るために、DestinationZone、Canvas及びPaneが必要である。

VCCanvasが作成されると、対応するDestinationPane３０７が生成される。さらに、関連するDestinationCanvas３０８と、対応するBoxTree３０９が生成される。同様に、VCCanvas３１０も、ソース文書に対するPane２１１及びZone２０９に関連づけられる。

DestinationCanvas３０８は、第２の表現における文書の論理的なレイアウトを提供する。特に、DestinationCanvas３０８は、デスティネーション表現における文書を描写するために、カーソルや選択のようなユーザインタフェイス機能を提供する。DestinationCanvas３０８に生じたイベントは、Connectorに供給される。DestinationCanvas３０８は、マウスイベント、キーボードイベント、ドラッグアンドドロップイベント、及び文書のデスティネーション（第２）表現のボキャブラリに特有なイベントを、Connector３０４に通知する。

４．ボキャブラリコネクションコマンドサブシステム
ボキャブラリコネクション（ＶＣ）サブシステム３００の要素として、ボキャブラリコネクション（ＶＣ）コマンドサブシステム３１３がある。ボキャブラリコネクションコマンドサブシステム３１３は、ボキャブラリコネクションサブシステム３００に関連した命令の実行のために使用されるVCCommand（ボキャブラリコネクションコマンド）３１５を生成する。VCCommandは、内蔵のCommandTemplate（コマンドテンプレート）３１８を使用して、及び／又は、スクリプトサブシステム３１４においてスクリプト言語を使用してスクラッチからコマンドを生成することにより、生成することができる。

コマンドテンプレートには、例えば、「If」コマンドテンプレート、「When」コマンドテンプレート、「挿入（Insert）」コマンドテンプレートなどがある。これらのテンプレートは、VCCommandを作成するために使用される。

５．ＸＰａｔｈサブシステム
ＸＰａｔｈサブシステム３１６は、文書処理システムの重要な構成であり、ボキャブラリコネクションの実現を支援する。Connector３０４は、一般にxpath情報を含む。上述したように、ボキャブラリコネクションのタスクの１つは、ソースＤＯＭツリーの変化をデスティネーションＤＯＭツリーに反映させることである。xpath情報は、変更／修正を監視されるべきソースＤＯＭツリーのサブセットを決定するために用いられる１以上のxpath表現を含む。

６．ソースＤＯＭツリー、デスティネーションＤＯＭツリー、及びConnectorTreeの概要
ソースＤＯＭツリーは、別のボキャブラリに変換される前のボキャブラリで文書を表現したＤＯＭツリー又はZoneである。ソースＤＯＭツリーのノードは、ソースノードと呼ばれる。

それに対して、デスティネーションＤＯＭツリーは、ボキャブラリコネクションに関連して前述したように、同一の文書を、マッピングにより変換された後の異なるボキャブラリで表現したＤＯＭツリー又はZoneである。デスティネーションＤＯＭツリーのノードは、デスティネーションノードと呼ばれる。

ConnectorTreeは、ソースノードとデスティネーションノードの対応を表すConnectorに基づく階層的表現である。Connectorは、ソースノードと、ソース文書になされた修正を監視し、デスティネーションＤＯＭツリーを修正する。Connectorは、デスティネーションＤＯＭツリーを修正することを許された唯一のオブジェクトである。

Ｅ．文書処理システムにおけるイベントフロー
実用のためには、プログラムはユーザからのコマンドに応答しなければならない。イベントは、プログラム上で実行されたユーザアクションを記述し実行する方法である。多くの高級言語、例えばＪａｖａ（登録商標）は、ユーザアクションを記述するイベントに頼っている。従来、プログラムは、ユーザアクションを理解し、それを自身で実行するために、積極的に情報を集める必要があった。これは、例えば、プログラムが自身を初期化した後、ユーザが画面、キーボード、マウスなどでアクションを起こしたときに適切な処理を講じるために、ユーザのアクションを繰り返し確認するループに入ることを意味する。しかしながら、このプロセスは扱いにくい。さらに、それは、ユーザが何かをするのを待つ間、ＣＰＵサイクルを消費してループするプログラムを必要とする。

多くの言語が、異なるパラダイムを採用することにより、これらの問題を解決している。そのうちの一つは、現代の全てのウィンドウシステムの基礎となっている、イベントドリブンプログラミングである。このパラダイムでは、全てのユーザアクションは、「イベント」と呼ばれる抽象的な事象の集合に属する。イベントは、十分詳細に、特定のユーザアクションを記述する。プログラムがユーザにより生成されたイベントを積極的に収集するのではなく、監視すべきイベントが生じたときに、システムがプログラムに通知する。この方法によりユーザとの対話を扱うプログラムは「イベントドリブン」であると言われる。

これは、多くの場合、全てのユーザにより生成されたイベントの基本特性を獲得する「Event（イベント）」クラスを使用して扱われる。

文書処理システムは、自身のイベント、及びこれらのイベントを扱う方法を定義して使用する。いくつかの型のイベントが使用される。例えば、マウスイベントは、ユーザのマウスアクションから起こるイベントである。マウスを含むユーザアクションは、Canvas２１０によって、マウスイベントに渡される。このように、Canvasは、システムのユーザによる相互作用の最前部にあると言える。必要であれば、最前部にあるCanvasは、そのイベントに関連した内容を子へ渡す。

それに対して、キーストロークイベントは、Canvas２１０から流れる。キーストロークイベントは、即時的なフォーカスを有する。すなわち、それは、いかなる瞬間でも作業に関連する。Canvas２１０上に入力されたキーストロークイベントは、その親に渡される。キー入力は、文字列挿入を扱うことが可能な、異なるイベントによって処理される。文字列の挿入を扱うイベントは、キーボードを使用して文字が挿入されたときに発生する。他の「イベント」は、例えば、ドラッグイベント、ドロップイベント、マウスイベントと同様に扱われる他のイベントを含む。

１．ボキャブラリコネクション外のイベントの取り扱い
イベントは、イベントスレッドを用いて渡される。Canvas２１０は、イベントを受け取ると、その状態を変更する。必要であれば、Command１０５２がCanvas２１０によりCommandQueue１０５３にポストされる。

２．ボキャブラリコネクション内のイベントの取り扱い
VocabularyConnectionプラグイン３０１を用いて、DestinationCanvasの一例であるXHTMLCanvas１１０６は、発生したイベント、例えば、マウスイベント、キーボードイベント、ドラッグアンドドロップイベント、及びボキャブラリに特有のイベントなどを受け取る。これらのイベントは、コネクタ３０４に通知される。より詳細には、図２１（ｂ）に図示されるように、VocabularyConnectionプラグイン３０１内のイベントフローは、SourcePane１１０３、VCCanvas１１０４、DestinationPane１１０５、DestinationCanvasの一例であるDestinationCanvas１１０６、デスティネーションＤＯＭツリー及びConnectorTreeを通過する。

Ｆ．ProgramInvoker及びProgramInvokerと他の構成との関係
ProgramInvoker１０３及びそれと他の構成との関係は、図１４（ａ）に更に詳細に示される。ProgramInvoker１０３は、文書処理システムを開始するために実行される実行環境中の基本的なプログラムである。図１１（ｂ）及び図１１（ｃ）に図示されるように、UserApplication１０６、ServiceBroker１０４１、CommandInvoker１０５１、及びResource１０９は、全てProgramInvoker１０３に接続される。前述したように、アプリケーション１０２は、実行環境中で実行されるコンポーネントである。同様に、ServiceBroker１０４１は、システムに様々な機能を加えるプラグインを管理する。他方、CommandInvoker１０５１は、ユーザにより提供される命令を実行して、コマンドを実行するために使用されるクラス及びファンクションを保持する。

１．プラグイン及びサービス
ServiceBroker１０４１について、図１４（ｂ）を参照して更に詳細に説明する。前述したように、ServiceBroker１０４１は、システムに様々な機能を追加するプラグイン（及び関連するサービス）を管理する。Service１０４２は、文書処理システムに特徴を追加又は変更可能な最も下の層である。「Service」は、ServiceCategory４０１とServiceProvider４０２の２つの部分からなる。図１４（ｃ）に図示されるように、１つのServiceCategory４０１は、複数の関連するServiceProvider４０２を持ちうる。それぞれのServiceProviderは、特定のServiceCategoryの一部または全部を実行するように作用する。ServiceCategory４０１は、他方では、Serviceの型を定義する。

Serviceは、１）文書処理システムに特定の特色を提供する「特色サービス」、２）文書処理システムにより実行されるアプリケーションである「アプリケーションサービス」、３）文書処理システムの全体にわたって必要な特色を提供する「環境サービス」、の３つの型に分類することができる。

Serviceの例は、図１４（ｄ）に示される。アプリケーションServiceのCategoryにおいては、システムユーティリティが対応するServiceProviderの例である。同様に、Editlet２０６はCategoryであり、HTMLEditlet及びSVGEditletは対応するServiceProviderである。ZoneFactory２０５は、Serviceの別のCategoryであり、対応するServiceProvider（図示せず）を有する。

プラグインは、文書処理システムに機能性を加えると既に説明したが、いくつかのServiceProvider４０２及びそれらに関連するクラスからなるユニットと見なされてもよい。各プラグインは、宣言ファイルに記述された依存性及びServiceCategory４０１を有する。

２．ProgramInvokerとアプリケーションとの関係
図１４（ｅ）は、ProgramInvoker１０３とUserApplication１０６との関係についての更なる詳細を示す。必要な文書やデータなどは、ストレージからロードされる。必要なプラグインは、全てServiceBroker１０４１上にロードされる。ServiceBroker１０４１は、全てのプラグインを保持し管理する。プラグインは、システムに物理的に追加することができ、又、その機能はストレージからロードすることができる。プラグインの内容がロードされると、ServiceBroker１０４１は、対応するプラグインを定義する。つづいて、対応するUserApplication１０６が生成され、実行環境１０１にロードされ、ProgramInvoker１０３にアタッチされる。

Ｇ．アプリケーションサービスと環境との関係
図１５（ａ）は、ProgramInvoker１０３上にロードしたアプリケーションサービスの構成についての更なる詳細を示す。コマンドサブシステム１０５のコンポーネントであるCommandInvoker１０５１は、ProgramInvoker１０３内のCommand１０５２を起動又は実行する。Command１０５２は、文書処理システムにおいて、ＸＭＬなどの文書を処理し、対応するＸＭＬＤＯＭツリーを編集するために用いられる命令である。CommandInvoker１０５１は、Command１０５２を実行するために必要なクラス及びファンクションを保持する。

ServiceBroker１０４１も、ProgramInvoker１０３内で実行される。UserApplication１０６は、ユーザインタフェイス１０７及びCoreComponent１１０に接続される。CoreComponent１１０は、全てのPaneの間で文書を共有する方法を提供する。CoreComponent１１０は、さらにフォントを提供し、Paneのためのツールキットの役割を果たす。

図１５（ｂ）は、Frame１０７１、MenuBar１０７２、及びStatusBar１０７３の関係を示す。

Ｈ．アプリケーションコア
図１６（ａ）は、全ての文書、及び文書の一部及び文書に属するデータを保持するアプリケーションコア１０８についての更なる説明を提供する。CoreComponent１１０は、文書１０８２を管理するDocumentManager１０８１にアタッチされる。DocumentManager１０８１は、文書処理システムに関連づけられたメモリに格納される全ての文書１０８２の所有者である。

画面上の文書の表示を容易にするために、DocumentManager１０８１はRootPane１０８４にも接続される。ClipBoard１０８７、SnapShot１０８８、Drag&Drop６０１、及びOverlay６０２の機能も、CoreComponent１１０にアタッチされる。

SnapShot１０８８は、アプリケーションの状態を元に戻すために使用される。ユーザがSnapShot１０８８を起動したとき、アプリケーションの現状が検知され、格納される。その後、アプリケーションの状態が別の状態に変わるとき、格納された状態の内容は保存される。SnapShot１０８８は、図１６（ｂ）に図示される。動作において、アプリケーションがあるＵＲＬから他へ移動するときに、前に戻る動作及び先に進む動作をシームレスに実行可能とするために、SnapShot１０８８は以前の状態を記憶する。

Ｉ．DocumentManager内における文書の構成
図１７（ａ）は、DocumentManager１０８１の更なる説明と、DocumentManagerにおいて文書が構成され保持される様子を示す。図１１（ｂ）に示したように、DocumentManager１０８１は、文書１０８２を管理する。図１７（ａ）に示される例において、複数の文書のうちの１つはRootDocument（ルート文書）７０１であり、残りの文書はSubDocument（サブ文書）７０２である。DocumentManager１０８１は、RootDocument７０１に接続され、RootDocument７０１は、全てのSubDocument７０２に接続される。

図１２及び図１７（ａ）に示すように、DocumentManager１０８１は、全ての文書１０８２を管理するオブジェクトであるDocumentContainer２０３に結合される。DOMService７０３及びIOManager７０４を含むツールキット２０１（例えばＸＭＬツールキット）の一部を形成するツールも、DocumentManager１０８１に供給される。再び図１７（ａ）を参照して、DOMService７０３は、DocumentManager１０８１により管理される文書に基づいたＤＯＭツリーを生成する。各Document７０５は、それがRootDocument７０１であってもSubDocument７０２であっても、対応するDocumentContainer２０３によって管理される。

図１７（ｂ）は、文書Ａ−Ｅが階層的に配置される様子を示す。文書ＡはRootDocumentである。文書Ｂ−Ｄは、文書ＡのSubDocumentである。文書Ｅは、文書ＤのSubDocumentである。図１７（ｂ）の左側は、これと同じ文書の階層が画面上に表示された例を示す。RootDocumentである文書Ａは、基本フレームとして表示される。文書ＡのSubDocumentである文書Ｂ−Ｄは、基本フレームＡの中のサブフレームとして表示される。文書ＤのSubDocumentである文書Ｅは、サブフレームＤのサブフレームとして画面に表示される。

再び図１７（ａ）を参照して、UndoManager（アンドゥマネージャ：アンドゥ管理部）７０６及びUndoWrapper（アンドゥラッパー）７０７は、それぞれのDocumentContainer２０３に対して生成される。UndoManager７０６及びUndoWrapper７０７は、取消可能なコマンドを実行するために使用される。この特徴を使用することにより、編集操作を使用して文書に対して実行された変更を取り消すことができる。SubDocumentの変更は、RootDocumentとも密接な関係を有する。アンドゥ操作は、階層内の他の文書に影響する変更を考慮に入れて、例えば、図１７（ｂ）に示されるような連鎖状の階層における全ての文書の間で整合性が維持されることを保証する。

UndoWrapper７０７は、DocumentContainer２０３内のSubDocumentに関連するアンドゥオブジェクトをラップし、それらをRootDocumentに関連するアンドゥオブジェクトに結合させる。UndoWrapper７０７は、UndoableEditAcceptor（アンドゥアブルエディットアクセプタ：アンドゥ可能編集受付部）７０９に利用可能なアンドゥオブジェクトの収集を実行する。

UndoManager７０６及びUndoWrapper７０７は、UndoableEditAcceptor７０９及びUndoableEditSource（アンドゥアブルエディットソース）７０８に接続される。当業者には理解されるように、Document７０５がUndoableEditSource７０８であってもよく、取消可能な編集オブジェクトのソースであってもよい。

Ｊ．アンドゥコマンド及びアンドゥフレームワーク
図１８（ａ）及び図１８（ｂ）は、アンドゥフレームワーク及びアンドゥコマンドについて更なる詳細を提供する。図１８（ａ）に示されるように、UndoCommand８０１、RedoCommand８０２、及びUndoableEditCommand８０３は、図１１（ｂ）に示したようにCommandInvoker１０５１に積むことができるコマンドであり、順に実行される。UndoableEditCommand８０３は、UndoableEditSource７０８及びUndoableEditAcceptor７０９に更にアタッチされる。「foo」EditCommand８０４及び「bar」EditCommand８０５は、UndoableEditCommandの例である。

１．UndoableEditCommandの実行
図１８（ｂ）は、UndoableEditCommandの実行を示す。まず、ユーザが編集コマンドを使用してDocument７０５を編集すると仮定する。第１ステップＳ１では、UndoableEditAcceptor７０９が、Document７０５のＤＯＭツリーであるUndoableEditSource７０８にアタッチされる。第２ステップＳ２では、ユーザにより発行されたコマンドに基づいて、Document７０５がＤＯＭのＡＰＩを用いて編集される。第３ステップＳ３では、ミューテーションイベントのリスナーが、変更がなされたことを通知される。すなわち、このステップでは、ＤＯＭツリーの全ての変更を監視するリスナーが編集操作を検知する。第４ステップＳ４では、UndoableEditがUndoManager７０６のオブジェクトとして格納される。第５ステップＳ５では、UndoableEditAcceptor７０９がUndoableEditSource７０８からデタッチされる。UndoableEditSource７０８は、Document７０５自身であってもよい。

Ｋ．システムへの文書のロードに関する手順
上記のサブセクションでは、システムの様々なコンポーネント及びサブコンポーネントについて説明した。以下、これらのコンポーネントの使用に関する方法論について説明する。図１９（ａ）は、文書処理システムに文書がロードされる様子の概要を示す。それぞれのステップは、図２４−２８において、特定の例に関連して詳述される。

簡単には、文書処理システムは、文書に含まれるデータからなるバイナリデータストリームからＤＯＭを生成する。ApexNode（エイペックスノード：頂点ノード）が、注目対象でありZoneに属する文書の一部のために生成される。つづいて、対応するPaneが同定される。同定されたPaneは、ApexNode及び物理的な画面表面からZone及びCanvasを生成する。Zoneは、次に、それぞれのノードにFacetを生成し、それらに必要とされる情報を提供する。Canvasは、ＤＯＭツリーから、ノードをレンダリングするためのデータ構造を生成する。

より詳細には、文書はストレージ９０１からロードされる。文書のＤＯＭツリー９０２が生成される。文書を保持するための、対応するDocumentContainer９０３が生成される。DocumentContainer９０３は、DocumentManager９０４にアタッチされる。ＤＯＭツリーは、ルートノードと、ときには複数のセカンダリノードを含む。

一般に、このような文書は、テキスト及びグラフィクスの双方を含む。したがって、ＤＯＭツリーは、例えば、ＸＨＴＭＬサブツリーだけでなくＳＶＧサブツリーを有してもよい。ＸＨＴＭＬサブツリーは、ＸＨＴＭＬのApexNode９０５を有する。同様に、ＳＶＧサブツリーは、ＳＶＧのApexNode９０６を有する。

ステップ１では、ApexNode９０６が、画面の論理的なレイアウトであるPane９０７にアタッチされる。ステップ２では、Pane９０７は、PaneOwner（ペインオーナー：ペインの所有者）９０８であるCoreComponentに、ApexNode９０６のためのZoneFactoryを要求する。ステップ３では、PaneOwner９０８は、ZoneFactoryと、ApexNode９０６のためのCanvasFactoryであるEditletとを返す。

ステップ４では、Pane９０７がZone９０９を生成する。Zone９０９はPane９０７にアタッチされる。ステップ５では、Zone９０９がそれぞれのノードに対してFacetを生成し、対応するノードにアタッチする。ステップ６では、Pane９０７がCanvas９１０を生成する。Canvas９１０はPane９０７にアタッチされる。Canvas９１０には様々なCommandが含まれる。ステップ７では、Canvas９１０が文書を画面にレンダリングするためのデータ構造を構築する。ＸＨＴＭＬの場合、これはボックスツリー構造を含む。

１．ZoneのＭＶＣ
図１９（ｂ）は、ＭＶＣパラダイムを用いてZoneの構成の概要を示す。この場合、Zone及びFacetは文書に関連した入力であるから、モデル（Ｍ）はZone及びFacetを含む。Canvasと、文書を画面にレンダリングするためのデータ構造体は、ユーザが画面上に見る出力であるから、ビュー（Ｖ）はCanvas及びデータ構造体に対応する。Commandは、文書とその様々な関係に対して制御操作を実行するので、コントロール（Ｃ）はCanvasに含まれるCommandを含む。

Ｌ．文書の表現
図２０を用いて、文書及びその様々な表現の例について以下に説明する。この例で使用される文書は、テキストと画像の双方を含む。テキストは、ＸＨＴＭＬを用いて表され、画像は、ＳＶＧを用いて表される。図２０は、文書のコンポーネント及び対応するオブジェクトの関係のＭＶＣ表現を詳細に示す。この例において、Document１００１は、Document１００１を保持するDocumentContainer１００２にアタッチされる。文書はＤＯＭツリー１００３により表現される。ＤＯＭツリーは、ApexNode１００４を含む。

ApexNodeは、黒丸で表される。頂点でないノードは、白丸で表される。ノードを編集するために用いられるFacetは、三角形で表され、対応するノードにアタッチされる。文書がテキストと画像を有するので、この文書のＤＯＭツリーは、ＸＨＴＭＬ部分とＳＶＧ部分を含む。ApexNode１００４は、ＸＨＴＭＬサブツリーの最上のノードである。これは、文書のＸＨＴＭＬ部分の物理的な表現のための最上PaneであるXHTMLPane１００５にアタッチされる。ApexNode１００４は、文書のＤＯＭツリーの一部であるXHTMLZone１００６にもアタッチされる。

Node１００４に対応するFacetも、XHTMLZone１００６にアタッチされる。XHTMLZone１００６は、XHTMLPane１００５にアタッチされる。XHTMLEditletは、文書の論理的な表現であるXHTMLCanvas１００７を生成する。XHTMLCanvas１００７は、XHTMLPane１００５にアタッチされる。XHTMLCanvas１００７は、Document１００１のＸＨＴＭＬコンポーネントのためのBoxTree１００９を生成する。文書のＸＨＴＭＬ部分を保持し描画するために必要な様々なCommand１００８も、XHTMLCanvas１００７に追加される。

同様に、文書のＳＶＧサブツリーのApexNode１０１０は、文書のＳＶＧコンポーネントを表現するDocument１００１のＤＯＭツリーの一部であるSVGZone１０１１にアタッチされる。ApexNode１０１０は、文書のＳＶＧ部分の物理的な表現の最上のPaneであるSVGPane１０１３にアタッチされる。文書のＳＶＧ部分の論理的な表現を表すSVGCanvas１０１２は、SVGEditletにより生成され、SVGPane１０１３にアタッチされる。画面上に文書のＳＶＧ部分をレンダリングするためのデータ構造及びコマンドは、SVGCanvasにアタッチされる。例えば、このデータ構造は、図示されるように、円、線、長方形などを含んでもよい。

図２０に関連して説明された文書例の表現の一部について、図２１（ａ）に関連して、前述したＭＶＣパラダイムを用いて更に説明する。図２１（ａ）は、文書１００１のＸＨＴＭＬコンポーネントにおけるＭＶの関係を簡略化して示す。モデルは、Document１００１のＸＨＴＭＬコンポーネントのためのXHTMLZone１１０１である。XHTMLZoneのツリーには、いくつかのNode及びそれらに対応するFacetが含まれる。対応するXHTMLZone及びPaneは、ＭＶＣパラダイムのモデル（Ｍ）部分の一部である。ＭＶＣパラダイムのビュー（Ｖ）部分は、Document１００１のＸＨＴＭＬコンポーネントの、対応するXHTMLCanvas１１０２及びBoxTreeである。文書のＸＨＴＭＬ部分は、Canvasと、それに含まれるCommandを使用して画面に描写される。キーボードやマウス入力などのイベントは、図示されるように、逆方向へ進む。

SourcePaneは、更なる機能、すなわち、ＤＯＭの保有者としての役割を有する。図２１（ｂ）は、図２１（ａ）に示したDocument１００１のコンポーネントに対するボキャブラリコネクションを提供する。ＤＯＭホルダーとして機能するSourcePane１１０３は、文書のソースＤＯＭツリーを含む。ConnectorTreeは、ConnectorFactoryにより生成され、デスティネーションＤＯＭの保有者としても機能するDestinationPane１１０５を生成する。DestinationPane１１０５は、XHTMLDestinationCanvas１１０６としてボックスツリーの形式でレイアウトされる。

Ｍ．プラグインサブシステム、ボキャブラリコネクション、及びコネクタの関係
図２２（ａ）−（ｃ）は、それぞれ、プラグインサブシステム、ボキャブラリコネクション、及びConnectorに関連する更なる詳細を示す。プラグインサブシステムは、文書処理システムに機能を追加又は交換するために用いられる。プラグインサブシステムは、ServiceBroker１０４１を含む。ServiceBroker１０４１にアタッチされるZoneFactoryService１２０１は、文書の一部に対するZoneを生成する。EditletService１２０２も、ServiceBroker１０４１にアタッチされる。EditletService１２０２は、Zone中のNodeに対応するCanvasを生成する。

ZoneFactoryの例は、XHTMLZone及びSVGZoneをそれぞれ生成するXHTMLZoneFactory１２１１及びSVGZoneFactory１２１２である。文書例に関連して前述したように、文書のテキストコンポーネントは、XHTMLZoneを生成することにより表現されてもよいし、画像はSVGZoneを用いて表現されてもよい。EditletServiceの例は、XHTMLEditlet１２２１及びSVGEditlet１２２２を含む。

図２２（ｂ）は、ボキャブラリコネクションに関連する更なる詳細を示す。ボキャブラリコネクションは、前述したように、文書処理システムの重要な特徴であり、２つの異なる方法で文書の整合のとれた表現及び表示を可能とする。ConnectorFactory３０３を保持するVCManager３０２は、ボキャブラリコネクションサブシステムの一部である。ConnectorFactory３０３は、文書のConnector３０４を生成する。前述したように、Connectorは、ソースＤＯＭ中のノードを監視し、２つの表現の間の整合性を維持するために、デスティネーションＤＯＭ中のノードを修正する。

Template３１７は、いくつかのノードの変換ルールを表す。ボキャブラリコネクション記述子（ＶＣＤ）ファイルは、特定のパス又はルールを満たす要素又は要素の集合を他の要素に変換するいくつかのルールを表すTemplateのリストである。Template３１７及びCommandTemplate３１８は、全てVCManager３０２にアタッチされる。VCManagerは、ＶＣＤファイル中の全てのセクションを管理するオブジェクトである。１つのＶＣＤファイルに対して、１つのVCManagerオブジェクトが生成される。

図２２（ｃ）は、Connectorに関連する更なる詳細を提供する。ConnectorFactory３０３は、ソース文書からConnectorを生成する。ConnectorFactory３０３は、Vocabulary、Template、及びElementTemplateにアタッチされ、それぞれ、VocabularyConnector、TemplateConnector、ElementConnectorを生成ずる。

VCManager３０２は、ConnectorFactory３０３を保持する。Vocabularyを生成するために、対応するＶＣＤファイルが読み込まれる。こうして、ConnectorFactory３０３が生成される。このConnectorFactory３０３は、Zoneを生成するZoneFactory及びCanvasを生成するEditletに関連する。

つづいて、ターゲットボキャブラリのEditletServiceが、VCCanvasを生成する。VCCanvasも、ソースＤＯＭツリー又はZoneにおけるApexNodeのConnectorを生成する。必要に応じて、子のConnectorが再帰的に生成される。ConnectorTreeは、ＶＣＤファイル中のテンプレートの集合により生成される。

テンプレートは、マークアップ言語の要素を他の要素に変換するためのルールの集合である。例えば、各テンプレートは、ソースＤＯＭツリー又はZoneにマッチされる。適切にマッチした場合には、頂点Connectorが生成される。例えば、テンプレート「A/*/D」は、間にどんなノードがあるかに関係なく、ノードＡで始まりノードＤで終わる全ての枝に合致する。同様に、「//B」は、ルートからの全ての「B」ノードに一致する。

Ｎ．ConnectorTreeに関係するＶＣＤファイルの例
特定の文書と関係する処理を説明する例を続ける。ドキュメントタイトルのある「MySampleXML」というタイトルの文書が文書処理システムにロードされる。図２３は、「MySampleXML」ファイルのための、VCManager及びConnectorFactoryTreeを用いたＶＣＤスクリプトの例を示す。スクリプトファイル中のボキャブラリセクション、テンプレートセクションと、VCManagerにおける対応するコンポーネントが示される。タグ「vcd:vocabulary」において、属性「match」は「sample:root」、「label」は「MySampleXML」、「call-template」は「sample template」となっている。

この例では、Vocabularyは、「MySampleXML」のVCManagerにおいて「sample:root」として頂点要素を含む。対応するＵＩラベルは、「MySampleXML」である。テンプレートセクションにおいて、タグは「vcd:template」であり、名前は「sample:template」である。

Ｏ．ファイルがシステムにロードされる方法の詳細な例
図２４−２８は、文書「MySampleXML」のロードについての詳細な記述を示す。図２４（ａ）に示されるステップ１では、文書がストレージ１４０５からロードされる。DOMServiceは、ＤＯＭツリー及びDocumentManager１４０６と対応するDocumentContainer１４０１を生成する。DocumentContainer１４０１は、DocumentManager１４０６にアタッチされる。文書は、ＸＨＴＭＬ及びMySampleXMLのサブツリーを含む。ＸＨＴＭＬのApexNode１４０３は、タグ「xhtml:html」が付されたＸＨＴＭＬの最上のノードである。「MySampleXML」のApexNode１４０４は、タグ「sample:root」が付された「MySampleXML」の最上ノードである。

図２４（ｂ）に示されるステップ２では、RootPaneが文書のXHTMLZone、Facet、及びCanvasを生成する。Pane１４０７、XHTMLZone１４０８、XHTMLCanvas１４０９、及びBoxTree１４１０が、ApexNode１４０３に対応して生成される。

図２４（ｃ）に示されるステップ３では、XHTMLZoneが知らないタグ「sample:root」を発見し、XHTMLCanvasの領域からSubPaneを生成する。

図２５に示されるステップ４では、SubPaneが「sample:root」を扱うことができ、適切なZoneを生成可能なZoneFactoryを得る。このZoneFactoryは、ZoneFactoryを実行可能なVocabulary内にある。それは、「MySampleXML」のVocabularySectionの内容を含む。

図２６に示されるステップ５では、「MySampleXML」に対応するVocabularyがDefaultZone１６０１を生成する。対応するEditletが生成され、対応するCanvasを生成するためにSubPane１５０１が提供される。Editletは、VCCanvasを生成する。そして、それはTemplateSectionを呼ぶ。ConnectorFactoryTreeも含まれている。ConnectorFactoryTreeは、ConnectorTreeとなる全てのConnectorを生成する。

図２７に示されるステップ６では、各ConnectorがデスティネーションＤＯＭオブジェクトを生成する。コネクタのうちのいくつかはxpath情報を含んでいる。xpath情報は、変更／修正を監視する必要のあるソースＤＯＭツリーの部分集合を決定するために使用される１以上のxpath表現を含む。

図２８に示されるステップ７では、ボキャブラリは、ソースＤＯＭのペインからデスティネーションＤＯＭツリーのDestinationPaneを作成する。これは、SourcePaneに基づいてなされる。デスティネーションツリーのApexNodeは、DestinationPane及び対応するZoneにアタッチされる。DestinationPaneは、DestinationCanvasを生成し、文書をデスティネーションのフォーマットでレンダリングするためのデータ構造及びコマンドを構築する、自身のEditletを提供される。

図２９（ａ）は、対応するソースノードを持たず、デスティネーションツリーにのみ存在するノード上でイベントが発生したときのフローを示す。マウスイベント、キーボードイベントなど、Canvasが取得したイベントは、デスティネーションツリーを通過して、ElementTemplateConnectorに伝達される。ElementTemplateConnectorは対応するソースノードを持たないので、伝達されたイベントはソースノードに対する編集操作ではない。ElementTemplateConnectorは、伝達されたイベントがCommandTemplateに記述されたコマンドに合致すれば、それに対応するActionを実行する。合致するコマンドがなければ、ElementTemplateConnectorは、伝達されたイベントを無視する。

図２９（ｂ）は、TextOfConnectorによりソースノードに対応づけられているデスティネーションツリーのノード上でイベントが発生したときのフローを示す。TextOfConnectorは、ソースＤＯＭツリーのＸＰａｔｈで指定されたノードからテキストノードを取得して、デスティネーションＤＯＭツリーのノードにマッピングする。マウスイベント、キーボードイベントなど、Canvasが取得したイベントは、デスティネーションツリーを通過して、TextOfConnectorに伝達される。TextOfConnectorは、伝達されたイベントを、対応するソースノードの編集コマンドにマッピングし、Queue１０５３に積む。編集コマンドは、Facetを介して実行されるＤＯＭのＡＰＩコールの集合である。キューに積まれたコマンドが実行されると、ソースノードが編集される。ソースノードが編集されると、ミューテーションイベントが発行され、リスナーとして登録されたTextOfConnectorにソースノードの変更が通知される。TextOfConnectorは、ソースノードの変更を、対応するデスティネーションノードに反映させるように、デスティネーションツリーを再構築する。このとき、TextOfConnectorを含むテンプレートに、「for each」や「for loop」などの制御文が含まれている場合、ConnectorFactoryがこの制御文を再評価し、TextOfConnectorを再構築した後、デスティネーションツリーが再構築される。

（第１の実施の形態）
第１の実施の形態では、新たなＸＭＬの利用技術を提案する。さらに、新たなプログラミングパラダイムを提案する。

前述したように、ウェブページの作成者は、ＶＢスクリプトを用いてＡｃｔｉｖｅＸコントロールを制御し、さまざまな機能を有するウェブページを作成することができるようになっている。しかし、ＡｃｔｉｖｅＸコントロール自体は内部がブラックボックス化されており、ＡｃｔｉｖｅＸコントロールの機能を自由にカスタマイズしたり、複数のＡｃｔｉｖｅＸコントロール同士を直接連携して動作させたりすることはできない。

本発明者は、前提技術で説明したＸＭＬの処理技術が、このような課題を解決するのに適した技術であることに気づいた。従来の一般的なアプリケーションは、自身の動作に必要なデータを独自に定めたバイナリフォーマットで保持しているため、外部からの参照を可能とするＡＰＩが特別に用意されていない限り、内部のデータを外部から参照して利用することはできなかった。しかし、アプリケーションが利用するデータをＸＭＬの形式で保持することにより、前提技術で説明した技術を利用して、他のアプリケーションからも容易にデータを参照することが可能となる。すなわち、前提技術の文書処理装置２０はＸＭＬ文書をＤＯＭの形式で保持するので、ＤＯＭが標準的に提供するＡＰＩを用いて外部から自由にデータにアクセスすることができる。このような「ホワイトボックス」とも言うべき技術を利用して、より柔軟性の高いプログラミングパラダイムを構築できる。本発明者は、前提技術で説明したＸＭＬの処理技術を更に進め、後述するような新たなＸＭＬの利用技術を想到した。

ここで、ＸＭＬ文書のデータ構造と、そのＸＭＬ文書の処理技術の関係について説明する。図３０（ａ）（ｂ）（ｃ）は、処理対象となるＸＭＬ文書のデータ構造の例を示す。最も単純な例としては、図３０（ａ）に示すように、単一のボキャブラリで記述されたＸＭＬ文書がある。このＸＭＬ文書の処理系は、例えば、ＸＨＴＭＬで記述されたウェブページを表示するブラウザのように、特定のボキャブラリで記述されたＸＭＬ文書を処理できればよい。

これに対し、本出願人は、前提技術で説明したように、図３０（ｂ）に示すような、あるボキャブラリの構成要素（図中、白丸で示す）と、別のボキャブラリの構成要素（図中、黒丸で示す）とが混在したＸＭＬ文書を適切に処理可能な文書処理装置を開発した。前提技術の文書処理装置２０では、さまざまなＸＭＬボキャブラリを組み合わせたＸＭＬ複合文書に対し、起動部の一例である主制御ユニット２２により各フラグメントごとに適切な処理系が呼び出され、処理を分担してビューを構築し、ユーザの編集操作にあわせてＸＭＬ複合文書を編集することができる。これらの処理系は、Ｊａｖａ（登録商標）などにより開発されたハードコードプラグイン（例えば、ＨＴＭＬユニット５０やＳＶＧユニット６０）の場合もあるし、定義ファイルに記述されＶＣユニット８０により実行されるスクリプトベースの場合もある。ＸＨＴＭＬなどのメジャーボキャブラリならばハードコードプラグインが用意されているし、ユーザのプライベートボキャブラリなら定義ファイルで記述することになるだろう。このような技術により、例えば図３０（ｂ）に示す例において、ＸＨＴＭＬ（白丸の構成要素）で記述された文書に、グラフ表示用のボキャブラリ（黒丸の構成要素）で記述された部分文書を挿入し、ＸＨＴＭＬ文書の画面にグラフを配置することが可能である。

ここで、ＸＭＬフラグメントと処理系の関係に着目してみる。処理系はＸＭＬフラグメントに呼び出され、ＸＭＬの内容をもとにビューを構築する。そして、ユーザのおこすＵＩイベントを取得して、ＸＭＬを編集する。これは、見方を変えれば、特定のボキャブラリに対する表示と編集を担当する処理系を、そのボキャブラリのＸＭＬフラグメントを引数にして呼び出していると捉えることができる。

本発明者は、このようなフレームワークを利用して、もっと自由で柔軟な処理系の実行環境を提供できることに気づいた。すなわち、処理系は、あるＸＭＬを表示・編集するだけにとどまらず、もっと自由に、さまざまな処理を行ってもよい。例えば、ＸＭＬフラグメント中のデータをもとに、Web Service APIを通じてサーバにアクセスしてもよいし、要約や翻訳などの自然言語処理を行ってもよい。ＸＭＬフラグメントは処理系を起動するときの引数でもあるが、同時に動作中に利用するヒープメモリの役割も果たすことになる。このように考えると、前提技術の文書処理装置２０は、ＸＭＬ文書中にプロシージャ（処理系）を起動するための「タグ」をおき、引数をアトリビュート（属性）として指示したり、タグで囲まれたテキスト部分を操作対象としてプロシージャが実行されるという、ユニークなプログラムの実行環境であることがわかる。

本実施の形態では、新たなＸＭＬ文書のデータ構造として、図３０（ｃ）に示すようなデータ構造を提案する。図３０（ｃ）において、斜線を付した構成要素２５は、文書中の他のデータ２６へのポインタ情報を有している。この構成要素２５が属するボキャブラリを担当する処理系は、ポインタ情報により指し示されたデータ２６を参照して動作する。例えば、前述したように、ＸＨＴＭＬ文書中にグラフを挿入するときに、図３０（ｂ）のようにグラフのデータの実体をグラフ表示用ボキャブラリで記述するのではなく、ＸＨＴＭＬ文書中に記述された他のデータを参照してグラフを生成する。このようなデータ構造とすることにより、文書中の他のデータ、又は、他文書のデータを参照して動作するアプリケーションを構築することができる。

文書処理装置は、文書に含まれる構成要素の名前空間を参照して、適切な処理系を起動する。したがって、図３０（ｃ）の例では、斜線を示した構成要素２５は、グラフ表示用の処理系を起動する機能を有している。そして、起動された処理系は、その構成要素２５の配下に存在する構成要素を処理するのではなく、その構成要素２５が有するポインタ情報により指し示されたデータ２６を参照して動作する。この構成要素２５は、文書におけるグラフの配置位置を示す「アンカー」の機能も有している。構成要素２５が有するポインタ情報は、構成要素２５の属性として指定されてもよいし、構成要素２５自身又はその配下の構成要素の要素値として指定されてもよい。構成要素２５を含むＸＭＬフラグメントに、処理系の動作に必要なパラメータ情報などを記述しておいてもよい。

このような技術により、処理系は、自分の担当するフラグメントの外側のデータについても、自分自身の動作を調節する引数にしたり、ヒープ領域として利用することが可能になる。つまり、フラグメント部分にはｘｐａｔｈ式などで参照位置だけを記入し、実際の値はそのｘｐａｔｈ式の先にあるというモデルである。これは、例えて言うならば関数の引数にポインタを渡していると言うことと等価である。

上述した技術を、プログラミングパラダイムの観点から考察すると、文書中の任意の場所のデータを参照して動作することが可能なアプリケーションランタイム環境が提供されることになる。さらに、上述したように、文書中のデータはＤＯＭのＡＰＩを利用して任意のアプリケーションから参照可能であるので、ＤＯＭとして保持された文書中のデータを共有メモリとして利用可能な新しいプログラミング環境が提供される。文書には、アプリケーションを起動するための構成要素２５が記述され、その構成要素２５を契機として起動されたアプリケーションが、その構成要素２５が有するポインタ情報を参照して、文書の他のデータ２６を共有メモリとして利用する。このように、文書とアプリケーションが協働してシームレスに動作するような、新しいプログラミングパラダイムが実現される。

文書処理装置２０は、ＤＯＭが変更されたときに、ミューテーションイベントにより変更を通知する機能を有しているので、グラフ表示用の処理系が参照しているデータ２６が、他の処理系により変更されたとしても、グラフ表示用の処理系に変更を通知することにより、適切に変更を反映させることができる。このように、複数のアプリケーションが同一のデータを参照して動作している場合であっても、適切にデータの連携が図られるので、容易に複数のアプリケーションを連携して動作させることができる。複数の処理系が同じポインタを参照して動作することは、言ってみれば、ＸＭＬ文書をシェアードメモリとした処理系の連携である。

従来のスプレッドシートアプリケーションでは、セルの中に計算式を記入することで計算プロシージャを起動することができた。また、グラフを埋め込む場合には、参照するセルの範囲を指定し、そのセル内のデータを使ってグラフを生成するのが一般的である。本実施の形態の技術は、このモデルをＸＭＬ複合文書に持ち込み、ＸＭＬならではの特徴を盛り込んだものといえる。

スプレッドシートアプリケーションを使い、集計機能やグラフによる表示機能を持たせた「機能的な」文書を作れば、ユーザはこの文書を利用してデータを入力したり、再計算をしたり、結果をシミュレートしながらオペレーションをこなすことができる。本実施の形態の文書処理装置でも同様に、上述した技術を利用してさまざまなプロシージャ（処理系）を連携させ、さまざまな目的に特化した「機能的な」ＸＭＬ複合文書を作ることができる。しかも、スプレッドシートアプリケーションとは違い、透過的で拡張性に富む、オープンなＸＭＬ技術に基づいたプラットフォームを実現することができる。ユーザは、これらの機能的なＸＭＬ文書を使っていろいろなオペレーションをこなすことができる。

図３１（ａ）（ｂ）は、ポインタ情報の例を示す。図３１（ａ）は、ポインタ情報がｘｐａｔｈ式で記述される場合の例を示す。この例では、処理系が参照すべきデータ２６の位置を示すポインタ情報は、ｘｐａｔｈ式で記述されている。処理系は、このｘｐａｔｈ式により、自身が参照すべきデータ２６の位置を知ることができる。

図３１（ｂ）は、ポインタ情報が概念情報で与えられる場合の例を示す。構成要素２５は、要素値又は属性値として、処理系が参照すべきデータ２６の位置を概念的に示す、明確に規格化された概念情報を含んでいる。「明確に規定化された概念情報」は、例えば、オントロジー技術に基づいた概念情報であってもよい。この場合、この概念情報を解釈して現実のデータを特定するために、概念解決エンジン２７が設けられる。概念解決エンジン２７は、概念情報を取得して、その概念情報を例えばタグ名に変換する。概念情報として「重要データ」が指定されている場合は、概念解決エンジン２７は、例えば、＜重要＞、＜important＞、＜社外秘＞などのタグ名を返す。これにより、処理系は、文書中の＜重要＞などのタグが付されたデータを参照すべきことが分かる。概念解決エンジン２７に解決を依頼するときに、どのような情報が必要かを指定してもよい。例えば、「重要データ」という概念が指定されているときに、英語のタグ名に変換するよう依頼すると、概念解決エンジン２７は、＜important＞、＜secret＞などのタグ名を返してもよい。

構成要素２５を含むＸＭＬフラグメントに、処理系の動作に必要なパラメータ情報を記述しておく場合に、パラメータ情報の一つとして、ポインタ情報が指し示す先のデータについての、明確に規定化された意味的な型情報を記述してもよい。「明確に規定化された意味的な型情報」は、例えば、オントロジー技術に基づいた意味的な型情報であってもよい。例えば、ポインタ情報として「重要」という概念が指定されていた場合、意味的な型情報として「経営的に」「営業的に」などの情報が指定されてもよい。また、ポインタ情報として「金額」という概念が指定されていた場合、意味的な型情報として「売上金」「希望小売価格」「借入金」などの情報が指定されてもよい。これにより、処理系は、セマンティックな型の整合性をチェックすることができる。

従来のプログラミング言語では、型にセマンティックな意味を持たせることはできない。例えば、数値型である「ｉｎｔ」型の場合、代入される数値が整数であるか否かという整合性のチェックは可能であるが、代入される数値の意味的な整合性をチェックすることはできない。このため、例えば人月計算をする処理において、誤って人と月を加算したり、人と人を乗算してしまったりしても、プログラミング言語としては意味的な間違いを認識することはできない。これに対して、本実施の形態の技術によれば、同じ金額であっても「売上金」なのか「借入金」なのか、あるいは「１円単位」なのか「千ドル単位」なのか、「人数」なのか「年月」なのか、などのセマンティックな整合性の確認が可能となる。処理系が意味的な型の整合性を確認するときには、例えば、概念解決エンジン２７を利用して、参照するデータのタグ名が、指定された意味的な型情報に整合しているか否かをチェックするようにしてもよい。

オントロジー技術を利用してデータに意味的な型情報を与える技術は、新しいプログラミング技術として汎用的に利用可能である。このように、セマンティックな技術思想を含むプログラミング技術を、従来のプログラミング技術と対比して、「セマンティックプログラミング」と呼ぶ。

ここで、セマンティックプログラミング技術の一例として、前提技術で説明したＤＯＭユニット３０によるミューテーションイベントの拡張について説明する。ＤＯＭが変更されたとき、そのＤＯＭに「明確に規格化された意味的な型情報」が含まれていれば、その型情報を参照している処理系にミューテーションイベントが発行される。逆の表現をすると、処理系は自分が変更を監視したいＤＯＭを直接指定するだけでなく、「明確に規格化された意味的な型情報」でも間接的に指定することができる。

図３２（ａ）（ｂ）は、ＤＯＭの変更を通知する仕組みを説明するための図である。図３２（ａ）は、前提技術の文書処理装置２０におけるミューテーションイベントの仕組みを示す。処理系２９は、変更を監視すべきノードをｘｐａｔｈ式などで指定し、ミューテーションイベントのリスナーとして登録する。ＤＯＭユニット３０は、ＤＯＭが変更されると、登録されたリスナーに対してミューテーションイベントを発行する。

図３２（ｂ）は、本実施の形態で新たに提案するミューテーションイベントの仕組みを示す。文書処理装置２０に、ミューテーションイベントの通知を仲介する通知部２８を新たに設ける。通知部２８は、処理系２９から監視すべきノードの指定を受け付ける。ＤＯＭユニット３０は、ＤＯＭが変更されると、通知部２８にその旨を通知する。通知部２８は、ＤＯＭユニット３０からＤＯＭの変更を通知されると、変更されたノードを監視している処理系２９に対してミューテーションイベントを発行する。

通知部２８は、処理系２９が監視すべきノードをｘｐａｔｈ式により受け付けてもよいが、より柔軟で汎用性の高いプログラミング環境を提供するために、明確に規格化された概念情報による指定を受け付けてもよい。この場合、通知部２８は、ＤＯＭユニット３０からＤＯＭの変更を通知されると、そのノードのタグ名などを概念解決エンジン２７に送り、概念解決エンジン２７から、そのタグ名に対応する概念情報を取得する。通知部２８は、取得した概念情報を登録している処理系２９に対してミューテーションイベントを発行する。これにより、処理系２９は、例えば「重要な情報」が変更されたときに通知するよう通知部２８に依頼することができる。通知部２８は、ＤＯＭユニット３０からミューテーションイベントを受けたときに、変更されたノードが「重要な情報」に該当するか否かを概念解決エンジン２７を用いて判定し、該当していれば処理系２９にＤＯＭの変更を通知する。

このようなセマンティックプログラミング技術により、より柔軟で汎用性の高いプログラムを容易に開発することができる。

つづいて、図３０（ｃ）に示したデータ構造を利用して、様々な機能を有する文書を編集する技術について説明する。

構成要素２５が属する名前空間のボキャブラリの処理系、すなわち、構成要素２５により起動される処理系は、カスタマイズ可能なアプリケーションの部品として提供されてもよい。以下、この処理系を、文書のビューを構成する部品の意味で、「ビューテンプレート」と呼ぶ。ビューテンプレートは、スクリプトベースの定義ファイルとして提供されてもよいし、ハードコードプラグインとして提供されてもよい。ビューテンプレートの機能を利用するためには、文書中にビューテンプレートのアンカーとなる構成要素２５を記述し、その構成要素２５に、処理系が参照すべきデータを指し示すポインタ情報を記述するとともに、その他、処理系が必要とする情報を記述しておけばよい。ビューテンプレートを汎用的に利用可能とするために、ポインタ情報を、明確に規格化された概念情報として指定可能な環境が提供されるのが好ましい。また、算術演算、論理演算、自然言語処理、その他の任意の演算を組み合わせた条件式などを用いて、参照すべきデータを指定可能としてもよい。

図３３は、実施の形態に係る文書処理装置の構成を示す。本実施の形態の文書処理装置１００は、図１に示した前提技術の文書処理装置２０の構成に加えて、ビューテンプレート制御ユニット７０、取得部７１、及びビューテンプレート７８を備える。ビューテンプレート制御ユニット７０は、提示部７２、受付部７４、及び編集部７６を含む。

取得部７１は、処理対象となる文書を取得する。ビューテンプレート７８は、前述したように、文書に含まれるデータを利用して所定の機能を発現する処理系であり、文書の編集画面の構成部品である。

提示部７２は、文書処理装置１００において利用可能なビューテンプレート７８をユーザに提示する。提示部７２は、文書処理装置１００にインストールされているビューテンプレート７８の一覧を表示画面に提示してもよいし、編集中の文書の内容に応じて、利用可能なビューテンプレート７８を選択して提示してもよい。例えば、ＳＶＧ文書を編集中の場合は、ＳＶＧ文書の中に挿入可能なビューテンプレート７８を選択して提示してもよい。

受付部７４は、ユーザから、文書にビューテンプレート７８を付加する指示を受け付ける。受付部７４は、提示部７２が提示したビューテンプレート７８の一覧画面に表示されたビューテンプレート７８のアイコンをユーザが編集中の文書の表示画面上にドラッグ＆ドロップしたときに、その位置にビューテンプレート７８を挿入する指示を受け付けてもよい。

編集部７６は、受付部７４がビューテンプレート７８の挿入指示を受け付けたときに、文書中の挿入を指示された位置に、そのビューテンプレート７８を起動するための構成要素（タグ）を挿入する。このとき、編集部７６は、ビューテンプレート７８が動作に利用するデータの範囲を受け付けるための画面を提示して、ユーザからデータの指定を受け付けてもよい。また、編集部７６は、ビューテンプレート７８が動作に利用するデータの範囲を自動的に判定してもよい。編集部７６は、ビューテンプレート７８が動作に利用するデータのポインタ情報を文書中に記述する。編集部７６は、さらに、ビューテンプレート７８の動作に必要なパラメータなどを、ユーザから受け付けて、または自動的に判定して、文書に記述してもよい。

編集部７６がビューテンプレート７８を起動するための構成要素を文書中に追加すると、主制御ユニット２２により、その構成要素を処理する処理系、すなわちビューテンプレート７８が起動され、ビューテンプレート７８が提供するビューが文書の編集画面上に表示される。以降、ビューテンプレート７８が提供する機能が文書の編集画面において利用可能となる。

図３４は、文書の編集画面の例を示す。文書の編集画面９７には、提示部７２によりビューテンプレートパレット９８が表示されている。編集中の文書には、個人のスケジュール、ＴｏＤｏ、電子メールなどの情報が格納されているが、図３４に示した編集画面９７では、それらの情報にビューが与えられていないので、表示されていない。

ここで、ユーザが、ビューテンプレートパレット９８の中から、スケジュールを表示するためのビューテンプレート７８を選択して、編集画面上にドラッグ＆ドロップすると、受付部７４によりこの要求が受け付けられ、編集部７６により文書の所定位置にスケジュール表示用のビューテンプレート７８を起動するための構成要素が挿入される。このとき、編集部７６は、この構成要素の属性値として、文書中のスケジュール情報が格納された部分のポインタ情報を記述する。

図３５は、スケジュール用のビューテンプレート７８が起動された状態の編集画面を示す。編集部７６により、スケジュール用のビューテンプレート７８を起動するための構成要素が文書に挿入されると、起動部の一例である主制御ユニット２２により、その構成要素を処理するビューテンプレート７８、すなわちスケジュール用のビューテンプレート７８が起動され、ポインタ情報で指し示された部分に記述されているスケジュール情報９９が表形式で表示される。

このように、本実施の形態の技術によれば、汎用的に用意された様々な機能を有するビューテンプレート７８を文書に付加することができ、機能的な文書を容易に構築することができる。

（第２の実施の形態）
第１の実施の形態で説明した、汎用的に用意された文書処理機能を提供する技術について更に説明する。第１の実施の形態において「ビューテンプレート」と呼んでいた機能を、本実施の形態では、汎用的なＶＣ機能を提供する処理系（コンポーネント）という意味で、ＡＶＣ（Adaptive Vocabulary Component）と呼ぶ。

図３６は、本実施の形態に係る文書処理装置の構成を示す。本実施の形態の文書処理装置１００は、図３３に示した第１の実施の形態の文書処理装置１００のビューテンプレート制御ユニット７０及びビューテンプレート７８に代えて、ＡＶＣ制御ユニット３０００を備える。ＡＶＣ制御ユニット３０００は、ＡＶＣ機能を提供する処理系であるテーブル表示用ＡＶＣコンポーネント３０１０、チャート表示用ＡＶＣコンポーネント３０２０、ＵＩパーツ表示用ＡＶＣコンポーネント３０３０、ツリー表示用ＡＶＣコンポーネント３０４０と、それらのＡＶＣコンポーネントの動作に必要なプロパティ情報を設定するＡＶＣプロパティ設定部３００２とを含む。

図３７は、ＡＶＣコンポーネントのプロパティが挿入されたＸＭＬ文書の例を示す。このＸＭＬ文書は、単語帳のデータを記述するためのボキャブラリ「doc」で記述されている。ルート要素「doc」の子要素である要素「page」は、単語帳のページを示しており、ページ数に応じて複数設けられる。それぞれの要素「page」は、英語表記を格納する要素「english」と、日本語表記を格納する要素「japanese」とを含む。

図３７の例では、この単語帳をテーブル形式で表示するために、テーブル表示用ＡＶＣコンポーネント３０１０の動作に必要なプロパティ情報を記述したＡＶＣプロパティ３０１２が挿入されている。ＡＶＣプロパティ３０１２は、テーブル表示用ＡＶＣコンポーネント３０１０が処理可能な、テーブル表示用のボキャブラリ「tbl」で記述されている。ＡＶＣプロパティ３０１２には、「tbl」ボキャブラリと、「doc」ボキャブラリとの対応が、ＡＶＣプロパティを記述するためのボキャブラリ「avc」を用いて記述されている。以下、元のＸＭＬ文書を記述しているボキャブラリ、ここでは「doc」を「ホストボキャブラリ」といい、挿入されたＡＶＣプロパティを記述するボキャブラリ、ここでは「tbl」を「ゲストボキャブラリ」又は「ＡＶＣボキャブラリ」という。

図３７の例では、テーブルの各列のデータを格納する要素「column」は、２つの「property」要素を子要素に持つ。１つ目の要素「property」には、「label-transfer1」というパラメータが、ホストボキャブラリの要素「english」を参照するというプロパティ情報が記録されている。２つ目の要素「property」には、「label-transfer2」というパラメータが、ホストボキャブラリの要素「japanese」を参照するというプロパティ情報が記録されている。テーブル表示用ＡＶＣコンポーネント３０１０は、このプロパティ情報を参照して、テーブルの各列に、ホストボキャブラリの要素「english」と「japanese」の値を代入して表示する。このようにして、任意の文書のデータを、テーブル表示用ＡＶＣコンポーネント３０１０などの汎用的な機能を有する処理系に渡して処理させることが可能となる。

図３８は、本実施の形態に係る文書処理方法の手順を示す。ユーザが、ＡＶＣコンポーネントにより提供されるビューの挿入を指示すると（Ｓ１０）、ホストボキャブラリの処理系は、挿入を指示されたＡＶＣコンポーネントのＡＶＣプロパティのテンプレートをソースＤＯＭの指示された位置に挿入する（Ｓ１２）。この機能は、文書処理装置２０の主制御ユニット２２が担当してもよいし、ＡＶＣ制御ユニット３０００が担当してもよい。メニューやコマンドなどが選択されたことによりＡＶＣコンポーネントの挿入指示を受け付けてもよいし、ＡＶＣコンポーネントを示すアイコンなどが文書の表示画面の挿入位置にドロップされたことによりＡＶＣコンポーネントの挿入指示を受け付けてもよい。ホストボキャブラリのスキーマを参照して、指示された位置にＡＶＣプロパティを挿入可能か否かを判断し、スキーマに反する場合は挿入を受け付けないようにしてもよい。

ソースＤＯＭが変更されると、ＤＯＭユニット３０によりミューテーションイベントが発行され（Ｓ１４）、ミューテーションイベントを受けたホストボキャブラリの処理系は、文書を再表示する（Ｓ１６）。このとき、挿入されたＡＶＣプロパティは、ホストボキャブラリの処理系が処理できないボキャブラリで記述されているので、ホストボキャブラリの処理系は主制御ユニット２２に処理の委譲を依頼し、主制御ユニット２２は、ＡＶＣプロパティを処理可能な処理系として、ＡＶＣコンポーネントを選択して処理を指示する（Ｓ１８）。図３７に示した例では、ＡＶＣプロパティ３０１２は、ＡＶＣボキャブラリ「tbl」で記述されているので、テーブル表示用ＡＶＣコンポーネント３０１０が選択される。処理を委譲されたＡＶＣコンポーネントは、ＡＶＣプロパティを処理して表示するが、ここでは、テンプレートが挿入されているだけで、プロパティ値の実体が設定されていないので、ＡＶＣコンポーネントは、ＡＶＣプロパティを設定するために、ＡＶＣプロパティ設定部３００２を呼び出す（Ｓ２０）。

ＡＶＣプロパティ設定部３００２は、ＡＶＣコンポーネントに、ＡＶＣプロパティの設定を受け付けるためのダイアログ画面を提示するよう要求する（Ｓ２２）。このダイアログ画面は、ＡＶＣコンポーネントが共通に利用可能なライブラリとして用意されており、ＡＶＣコンポーネントは、設定を要するプロパティ情報を表示したダイアログ画面を生成してユーザに提示する（Ｓ２４）。このダイアログ画面には、例えば、設定すべきプロパティ情報の一覧と、表示される画面のプレビューと、ＡＶＣコンポーネントが参照可能なデータ、すなわち、文書に含まれる要素や属性の一覧とが提示されてもよい。ユーザが、文書に含まれる要素の一覧の中から、例えばテーブルの列、行、ラベルなどに設定する要素を選択して、プロパティ情報の一覧画面にドラッグ＆ドロップすることにより、対応を設定できるようにしてもよい。

ユーザがダイアログ画面を利用してプロパティ情報を設定すると（Ｓ２６）、ＡＶＣコンポーネントは、プロパティの設定情報を受け付け、ソースＤＯＭ中に挿入されているＡＶＣプロパティの対応するノードに、設定されたプロパティ値を書き込む（Ｓ２８）。ソースＤＯＭが変更されると、ＤＯＭユニット３０によりミューテーションイベントが発行され（Ｓ３０）、ＡＶＣプロパティの処理系であるＡＶＣコンポーネント自身がミューテーションイベントを受けてＡＶＣプロパティを処理する（Ｓ３２）。こうして、ＡＶＣプロパティに設定された情報を利用して、ＡＶＣコンポーネントの機能が発現され、ユーザの所望の表示がなされる（Ｓ３４）。表示される画面の例を図３９に示す。

ＡＶＣプロパティが挿入されたＸＭＬ文書を開いたときも同様に、下記のような手順により図３９に示した画面が表示される。まず、主制御ユニット２２により、ルート要素に対して処理系がディスパッチされ、ホストボキャブラリが処理される。ホストボキャブラリの処理系は、挿入されているＡＶＣボキャブラリを処理できないので、ＡＶＣボキャブラリで記述された部分に対してペインを割り当てて、その処理を他の処理系に委譲する。主制御ユニット２２は、ＡＶＣボキャブラリの処理系としてＡＶＣコンポーネントを選択し、選択されたＡＶＣコンポーネントが、ＡＶＣプロパティを参照してビューを生成する。こうして、図３９に示した表示画面が得られる。

（第３の実施の形態）
第２の実施の形態では、ＸＭＬ文書にＡＶＣプロパティを挿入し、ＡＶＣプロパティの処理系としてＡＶＣコンポーネントを起動させてＡＶＣ機能を発現させた。本実施の形態では、ＸＭＬ文書にＡＶＣプロパティを挿入することなく、ＡＶＣ機能を発現させる技術を説明する。

図４０は、本実施の形態に係る文書処理装置の構成を示す。本実施の形態の文書処理装置１００は、図３６に示した第２の実施の形態の文書処理装置１００の構成に加えて、ＡＶＣプロパティ設定部３００２が、ＡＶＣプロパティ生成部３００４及び定義ファイル生成部３００６を更に含む。その他の構成及び動作は、第２の実施の形態と同様である。

ＡＶＣプロパティ設定部３００２がＡＶＣコンポーネントの動作に必要なプロパティ情報の設定をユーザから受け付けると、ＡＶＣプロパティ生成部３００４は、図３７に示したようにソース文書にＡＶＣプロパティ３０１２を挿入するのではなく、ソース文書とは別のファイルとして、ＡＶＣプロパティ３０１２を格納したＡＶＣプロパティファイルを生成する。定義ファイル生成部３００６は、ＡＶＣプロパティファイルを読み込むためのモジュールを生成する。ここでは、ＶＣ機能を利用したスクリプトベースの定義ファイルを生成する。

図４１は、本実施の形態に係る文書処理方法の手順を示す。ユーザが、文書全体又はあるゾーンの処理系を、そのゾーンの構成要素が属するタグセットを処理する第１の処理系から、第２の処理系の一例であるＡＶＣコンポーネントに切り替えるよう指示すると（Ｓ５０）、ＡＶＣプロパティ設定部３００２は、文書処理装置１００に登録され利用可能となっているＡＶＣコンポーネントのリストを取得してユーザに提示し、ユーザが利用するＡＶＣコンポーネントの選択を受け付ける（Ｓ５２）。ＡＶＣプロパティ設定部３００２が、利用するＡＶＣコンポーネントの選択を受け付けると（Ｓ５４）、そのＡＶＣコンポーネントの動作に必要なパラメータの設定を受け付けるために、ＡＶＣプロパティ生成部３００４は、選択されたＡＶＣコンポーネントのＡＶＣプロパティをインスタンス化し（Ｓ５６）、設定ダイアログ画面を提示するようＡＶＣコンポーネントに要求する（Ｓ５８）。要求されたＡＶＣコンポーネントは、共通ライブラリを利用して設定ダイアログを生成し、ユーザに提示する（Ｓ６０）。

ユーザがダイアログ画面を利用してプロパティ情報を設定すると（Ｓ６２）、ＡＶＣプロパティ生成部３００４によりＡＶＣプロパティファイルが生成される。ここで、ＡＶＣコンポーネントは、定義ファイルの登録ダイアログ画面を提示するよう定義ファイル生成部３００６に依頼する（Ｓ６４）。定義ファイル生成部３００６は、定義ファイルの登録名をユーザに問い合わせ（Ｓ６６）、ユーザから定義ファイルの名称を受け付けると（Ｓ６８）、ソース文書又は指定されたゾーンのApex要素の処理系として呼び出される定義ファイルを生成して、文書処理装置１００が利用可能に登録する（Ｓ７０）。この定義ファイルは、ＡＶＣプロパティファイルを読み込む命令を含むともに、読み込んだＡＶＣプロパティの処理を他の適切な処理系、すなわち、ＡＶＣコンポーネントに委譲する命令を含む。

ＡＶＣプロパティ設定部３００２は、ＡＶＣプロパティファイルの生成と、定義ファイルの生成が終了すると、生成した定義ファイルへ処理系を切り替える（Ｓ７２）。この定義ファイルにより、ＡＶＣプロパティファイルが読み込まれ、ＡＶＣコンポーネントに処理が委譲される。処理を委譲されたＡＶＣコンポーネントは、利用するデータを特定するための情報を格納したＡＶＣプロパティファイルを参照して、文書に含まれるデータの中からＡＶＣコンポーネントが利用するデータを特定し、特定されたデータを利用して所定の機能を発現し、ビューを生成して表示する（Ｓ７４）。こうして、ＡＶＣプロパティに設定された情報を利用して、ＡＶＣコンポーネントの機能が発現され、ユーザの所望の表示がなされる。

このような技術により、ソース文書にプロパティ情報などを挿入することなく、ＡＶＣ機能を実現することができる。したがって、ソース文書を記述するボキャブラリによらず、ソース文書のバリデーションを保ちつつ、ＡＶＣ機能を利用して新たなビューを追加することができる。また、生成した定義ファイルを保存して別の文書に適用することで、定義ファイルを再利用し、複数の文書に対してＡＶＣ機能を利用することができる。

ソース文書に、適用すべき処理系を指定する命令をＰＩとして記述するようにしてもよい。これにより、文書のバリデーションに影響を与えずに、処理系を指定することができる。処理系が切り替わるゾーンごとに、処理系を指定するＰＩを記述してもよい。主制御ユニット２２は、Apex要素に対して処理系を割り当てる際に、処理系を指定するＰＩが記述されている場合は、その処理系を優先的に割り当てる。この機能を利用すれば、ＡＶＣ機能を呼び出すために生成された定義ファイルをＰＩとして指定しておくことにより、ＡＶＣコンポーネントを優先的に割り当て、ＡＶＣ機能を発現させることができる。

（第４の実施の形態）
図４２は、本実施の形態に係る文書処理装置の構成を示す。本実施の形態の文書処理装置１００は、図３６に示した第２の実施の形態の文書処理装置１００の構成に加えて、ＡＶＣコンポーネント切替部３０５０を更に含む。ＡＶＣコンポーネント切替部３０５０は、文書に適用するＡＶＣコンポーネントを、複数のＡＶＣコンポーネント３０１０〜３０４０のいずれに切り替えるかをユーザから受け付け、選択されたＡＶＣコンポーネントを文書に適用させる。これにより、ユーザは、同一の文書に対して複数のＡＶＣコンポーネントを切り替えて適用させ、様々な機能を有するＡＶＣコンポーネントにより多角的に文書を処理させることができる。その他の構成及び動作は、第２の実施の形態と同様である。

図４３は、テーブル表示用ＡＶＣコンポーネント３０１０のＡＶＣプロパティが挿入された文書の例を示す。このＸＭＬ文書は、ＸＨＴＭＬ文書の「body」要素の下位に、コンピュータのスペックを記述するためのボキャブラリ「ns1」で記述されたデータと、テーブル表示用ＡＶＣコンポーネント３０１０を起動させるためのアンカーとなる要素３０２５と、ボキャブラリ「ns1」で記述されたデータをテーブル表示用ＡＶＣコンポーネント３０１０で処理させるために必要なパラメータを含むＡＶＣプロパティ３０１２を含む。ボキャブラリ「ns1」のルート要素「root」の子要素「pc」は、複数繰り返して設けられ、それぞれ、コンピュータに搭載されたＣＰＵのクロック周波数を格納する要素「cpu」と、メモリの容量を格納する要素「memory」と、ハードディスクドライブ（ＨＤＤ）の容量を格納する要素「hdd」と、値段を格納する要素「price」とを含む。要素３０２５は、テーブル表示用ＡＶＣコンポーネント３０１０を起動させるためにテーブル表示用ＡＶＣコンポーネント３０１０が処理を担当するボキャブラリである「avc-datagrid」で記述される。このボキャブラリのルート要素「datagrid」は、属性として、ＡＶＣコンポーネントの名称、バージョン番号、起動時にダイアログを開くか否かを示す情報を有する。ＡＶＣプロパティ３０１２は、図４３では省略しており、図４４及び図４５に詳細を示す。

図４４は、図４３に示した文書に記述されたＡＶＣプロパティ３０１２の内容を示す。ＡＶＣプロパティ３０１２には、テーブル表示用ＡＶＣコンポーネントが参照するプロパティ情報として、繰り返し要素が「/html/body/p/root/pc」であること、見出し行の表示／非表示、行番号列の表示／非表示、表示領域の幅、表示領域の高さ、集計行の表示／非表示、集計行の表示形式、集計行の桁区切り、集計行の小数部表示桁数、集計列の表示／非表示、集計列の表示形式、集計列の桁区切り、集計列の小数部表示桁数、集計列の幅が記述される。

図４５は、図４３に示した文書に記述されたＡＶＣプロパティ３０１２の内容を示す。ボキャブラリ「avc-datagrid」の要素「column」は、テーブルの列に関するプロパティ情報として、列ノードが繰り返し要素として指定されている「/html/body/p/root/pc」の下位の要素「cpu」のテキストノードであること、列の見出し、データ型、データ型が「文字列」である場合の最大文字数、データ型が「数値」である場合の表示形式、桁区切り、小数部表示桁数、データ型が「日時」である場合の日時形式、列の幅、型不一致の表示／非表示を記述した要素を含む。他の列についても同様にプロパティ情報が記述される。

図４６は、図４３に示した文書を表示した画面の例を示す。図４３に示した文書に記述された要素３０２５の処理モジュールとして起動されたテーブル表示用ＡＶＣコンポーネント３０１０は、ＡＶＣプロパティ３０１２を参照して、文書に記述されたコンピュータのスペックに関するデータをテーブル表示する。なお、図４５において、列の見出しを格納するプロパティ情報は、<avc:property name="title" type="title" checked="false" inheritable="true" />と記述されており、見出しが設定されておらず、空要素となっている。このとき、テーブル表示用ＡＶＣコンポーネント３０１０は、この列のデータとして指定された要素の要素名を見出しとして表示する。したがって、図４６では、テーブルの第２列の見出しとして、その列のデータとして指定された要素の要素名「cpu」が表示されている。

図４７は、ＡＶＣコンポーネントにより生成されたビューの領域でマウスを右クリックしたときに表示されるメニューを示す。ここで、ユーザが「設定」を選択すると、ＡＶＣプロパティ設定部３００２が、テーブル表示用ＡＶＣコンポーネント３０１０が参照するＡＶＣプロパティ３０１２を設定するためのダイアログ画面を表示する。「切替」を選択すると、ＡＶＣコンポーネント切替部３０５０が、ＡＶＣコンポーネントを切り替えるためのダイアログ画面を表示する。

図４８は、ＡＶＣコンポーネント切替部３０５０により表示されたダイアログ画面の例を示す。ＡＶＣコンポーネント切替部３０５０は、文書処理装置１００が利用可能なＡＶＣコンポーネントの一覧を取得して表示し、ユーザから切替先のＡＶＣコンポーネントの選択を受け付ける。文書処理装置１００にＡＶＣコンポーネントを新たにインストールすると、切替先のＡＶＣコンポーネントを増やすことができる。ここでは、散布図形式で表示するチャート表示用ＡＶＣコンポーネント３０２０が選択されたものとする。

ＡＶＣコンポーネント切替部３０５０は、切替先のＡＶＣコンポーネントを受け付けると、後述するように、ソースＤＯＭ中のＡＶＣコンポーネントを起動するためのアンカーとなる要素３０２５を、元のＡＶＣコンポーネントが処理可能なボキャブラリの要素から、切替先のＡＶＣコンポーネントが処理可能なボキャブラリの要素に書き換える。ソースＤＯＭを書き換えると、ミューテーションイベントにより変更が処理系に通知されるが、このとき、新たに書き換えられた要素３０２５の処理系として、切替先のＡＶＣコンポーネント、ここではチャート表示用ＡＶＣコンポーネント３０２０が起動される。起動されたチャート表示用ＡＶＣコンポーネント３０２０は、ＡＶＣプロパティの設定を受け付けるために、ＡＶＣプロパティ設定部３００２を呼び出す。

図４９は、ＡＶＣプロパティ設定部３００２により表示されたＡＶＣプロパティの設定画面の例を示す。図４９は、散布図のデータを設定するための画面を示す。散布図においては、Ｘ軸、Ｙ軸の他に、系列、要素ラベルを指定できるようになっている。ここで、１点のみを散布図に表示してもあまり意味がないので、繰り返し要素を指定し、その要素に含まれるデータをＸ軸、Ｙ軸、系列、要素ラベルに指定可能とする。

このとき、繰り返し要素は、切り替える前のＡＶＣコンポーネントであるテーブル表示用ＡＶＣコンポーネント３０１０において、「/html/body/p/root/pc」と指定されていたので、デフォルトではこの設定を継承し、自動的に同じ要素を繰り返し要素に設定する。また、テーブル表示用ＡＶＣコンポーネント３０１０においては、列のデータとして指定されていた、「cpu」、「memory」、「hdd」、「price」のテキストノードを、デフォルトでは自動的にＸ軸、Ｙ軸、系列、要素ラベルのデータとして自動的に設定する。これにより、ＡＶＣコンポーネントを切り替えても、同様のプロパティ情報を自動的に継承することにより、ユーザによる設定の手間を軽減することができる。データの指定を変更する場合は、左側に表示されている文書の要素のツリー構造の中からデータを選択し、「設定」をクリックするか、ドラッグアンドドロップすればよい。右下に、表示画面のプレビューが表示される。

図５０は、ＡＶＣプロパティ設定部３００２により表示されたＡＶＣプロパティの設定画面の例を示す。図５０は、Ｘ軸として指定されたデータのオプションを設定するための画面を示し、Ｘ軸として指定されたデータの見出し、データ型、表示項目、データ型が「文字列」である場合の最大文字数、不正なデータの表示／非表示が設定できるようになっている。Ｙ軸に関しても同様である。データ型として、デフォルトでは「文字列」が選択されているが、データが数値である場合には、「数値」や「日時」を指定することも可能である。データ型が「文字列」の場合は、同じ文字列ごとにグループ化されて散布図上にアイコンが表示される。データ型が「数値」又は「日時」である場合は、その軸を数直線として散布図が表示される。ここでは、Ｘ軸に要素「cpu」が文字列として、Ｙ軸に要素「memory」が文字列として指定されているので、Ｘ軸には要素「cpu」のテキストノードが「2.2 ghz」、「2.8 ghz」、「3.0 ghz」の３種類、Ｙ軸には要素「memory」のテキストノードが「512 mb」、「1 gb」の２種類に分類されてアイコンが表示される。

図５１は、ＡＶＣプロパティ設定部３００２により表示されたＡＶＣプロパティの設定画面の例を示す。図５１は、系列として指定されたデータのオプションを設定するための画面を示し、系列として指定されたデータのデータ型、表示項目、データ型が「文字列」である場合の最大文字数、凡例の表示／非表示が設定できるようになっている。散布図上において、同じ文字列、数値、又は日時ごとに異なるアイコンが表示される。ここでは、系列に要素「hdd」が文字列として指定されているので、要素「hdd」のテキストノードの文字列ごとに３種類のアイコンが表示される。

図５２は、ＡＶＣプロパティ設定部３００２により表示されたＡＶＣプロパティの設定画面の例を示す。図５２は、要素ラベルとして指定されたデータのオプションを設定するための画面を示し、要素ラベルとして指定されたデータの最大文字数が設定できるようになっている。散布図上において、指定されたデータがアイコンの近傍にラベルとして表示される。ここでは、要素ラベルとして要素「price」のテキストノードが指定されているので、要素「pc」に対応する各アイコンの近傍に、その要素「pc」に含まれる要素「price」のテキストノードの文字列がラベルとして表示される。

図５３は、ＡＶＣプロパティ設定部３００２により表示されたＡＶＣプロパティの設定画面の例を示す。図５３は、散布図の表示領域のプロパティ情報を設定するための画面を示し、表示領域の幅、高さが設定できるようになっている。

図５４は、チャート表示用ＡＶＣコンポーネント３０２０に切り替えたときの表示画面の例を示す。図４６においては、テーブル表示用ＡＶＣコンポーネント３０１０が適用されて文書中のデータがテーブル表示されていたが、チャート表示用ＡＶＣコンポーネント３０２０に切り替えることにより、同じデータが散布図として表示されている。このように、同じ文書に対して複数のＡＶＣコンポーネントを切り替えて適用することを可能とすることにより、汎用的に用意された様々な機能を利用して文書を多角的に処理することができる。

図５５は、図４３に示した文書が、ＡＶＣコンポーネントを切り替えることにより変更された様子を示す。前述したように、ＡＶＣコンポーネント切替部３０５０がＡＶＣコンポーネントを切り替えるときに、ＡＶＣコンポーネントを起動するためのアンカーとなる要素３０２５を、テーブル表示用ＡＶＣコンポーネント３０１０が処理可能なボキャブラリである「avc-datagrid」の要素から、チャート表示用ＡＶＣコンポーネント３０２０が処理可能なボキャブラリである「avc-xychart」の要素に書き換える。

図５６は、図５５に示した文書に記述されたＡＶＣプロパティ３０１２の内容を示す。ＡＶＣプロパティ３０１２には、チャート表示用ＡＶＣコンポーネント３０２０が参照するプロパティ情報として、繰り返し要素が「/html/body/p/root/pc」であること、表示領域の幅、表示領域の高さが記述される。これらのプロパティ情報は、図４４に示したテーブル表示用ＡＶＣコンポーネント３０１０のＡＶＣプロパティ３０１２にも記述されていたものであり、ＡＶＣプロパティを記述するためのボキャブラリを用いて同じデータ構造で記述される。このように、共通のスキーマを用いてＡＶＣプロパティ３０１２を記述することで、ある文書に対して、一度いずれかのＡＶＣコンポーネントを適用させてＡＶＣプロパティ３０１２を設定しておけば、ＡＶＣコンポーネントを切り替えるときにＡＶＣコンポーネント間で設定を引き継ぐことができ、ユーザの設定の手間を軽減させることができる。また、半自動的にＡＶＣコンポーネントを適用させたビューを生成することができる。ＡＶＣコンポーネントを新たに開発する際には、共通のスキーマを用いたＡＶＣプロパティ３０１２を参照して動作するようにし、他のＡＶＣコンポーネントと共通の設定は継承できるようにすることが望ましい。

図５７は、図５５に示した文書に記述されたＡＶＣプロパティ３０１２の内容を示す。ボキャブラリ「avc-xychart」の要素「axis」は、Ｘ軸に関するプロパティ情報として、軸のデータが繰り返し要素として指定されている「/html/body/p/root/pc」の下位の要素「cpu」のテキストノードであること、軸の見出し、データ型、データ型が「数値」である場合の最小値、最大値、主目盛幅、副目盛幅、データ型が「日時」である場合の最小値、最大値、主目盛幅、副目盛幅、日付のみのデータの扱い方、データ型が「文字列」である場合の表示項目、最大文字数、不正なデータの表示／非表示を記述した要素を含む。Ｙ軸についても同様にプロパティ情報が記述される。

図５８は、図５５に示した文書に記述されたＡＶＣプロパティ３０１２の内容を示す。ボキャブラリ「avc-xychart」の要素「series」は、系列に関するプロパティ情報として、系列のデータが繰り返し要素として指定されている「/html/body/p/root/pc」の下位の要素「hdd」のテキストノードであること、データ型、データ型が「数値」である場合の最小値、最大値、目盛幅、データ型が「日時」である場合の最小値、最大値、目盛幅、日付のみのデータの扱い方、データ型が「文字列」である場合の表示項目、最大文字数、凡例の表示／非表示を記述した要素を含む。

図５９は、図５５に示した文書に記述されたＡＶＣプロパティ３０１２の内容を示す。ボキャブラリ「avc-xychart」の要素「objectlabel」は、要素ラベルに関するプロパティ情報として、要素ラベルのデータが繰り返し要素として指定されている「/html/body/p/root/pc」の下位の要素「price」のテキストノードであること、最大文字数を記述した要素を含む。

図６０は、図４９に示した散布図のデータを設定するための画面において、Ｙ軸のデータを変更したときの画面を示す。要素「price」のテキストノードをＹ軸のデータ領域にドラッグアンドドロップすると、要素「price」のテキストノードが新たにＹ軸のデータに指定される。画面右下には、Ｙ軸が「price」に変更された散布図のプレビューが表示されている。このように、チャート表示用ＡＶＣコンポーネント３０２０は、文書中に繰り返し存在する任意の要素のデータを軸に設定し、散布図を作成することができる。

図６１は、Ｙ軸のデータのデータ型を変更したときの画面を示す。要素「price」のテキストノードには、コンピュータの値段が数値として格納されているので、「文字列」意外に「数値」のデータ型が許される。そこで、Ｙ軸のデータ型を「数値」に変更し、最小値を「０」に設定すると、画面右下に表示されているように、Ｙ軸が０を始点とする数直線に変わり、数直線上に各コンピュータの値段がプロットされる。

このように、ユーザがデータの型を指定できるようにすることで、同じ文書に異なるビューを与えることができる。例えば、テーブル表示用ＡＶＣコンポーネント３０１０においても、チャート表示用ＡＶＣコンポーネント３０２０においても、データを文字列として扱うのか数値として扱うのかによって、ソートしたりマッピングしたりした結果が変わる。ユーザ自身がデータの型を指定可能とすることで、柔軟で汎用性の高い機能を提供することができる。また、自身が作成したボキャブラリではないボキャブラリで記述されたデータに対しても、ユーザが独自にデータ型を与えることができる。そのボキャブラリにＤＴＤやＸＭＬ Ｓｃｈｅｍａなどのスキーマが存在していたとしても、ＡＶＣコンポーネント上では別のデータ型を与えることができ、データを柔軟に処理させることができる。

以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

実施の形態では、ＸＭＬ文書を処理する例について説明したが、本実施の形態の文書処理装置１００は、他のマークアップ言語、例えば、ＳＧＭＬ、ＨＴＭＬなどで記述された文書も同様に処理可能である。

本発明は、マークアップ言語により構造化されたデータを処理する文書処理装置に利用可能である。

Claims (9)

1. 文書中のデータを処理して所定の機能を発現するための汎用的な部品として利用可能な複数の処理モジュールと、
   同一の前記データに対して異なる複数の前記処理モジュールを切り替えて適用可能とする切替部と、
   を備えることを特徴とする文書処理装置。
2. 前記文書は、マークアップ言語により記述され、前記処理モジュールが処理可能なタグセットの構成要素を含み、
   前記構成要素を処理するために、その構成要素が属するタグセットを処理可能な前記処理モジュールが起動されることを特徴とする請求項１に記載の文書処理装置。
3. 前記切替部は、前記処理モジュールを切り替えるときに、前記構成要素を、切替元の処理モジュールが処理可能なタグセットの構成要素から、切替先の処理モジュールが処理可能なタグセットの構成要素に書き換えることを特徴とする請求項２に記載の文書処理装置。
4. 前記処理モジュールの動作に必要なパラメータの設定を受け付けるプロパティ設定部を更に備え、
   前記プロパティ設定部は、受け付けた前記パラメータを、前記構成要素又はその子孫の構成要素の要素値又は属性値として前記文書に記述することを特徴とする請求項２又は３に記載の文書処理装置。
5. 前記プロパティ設定部は、前記処理モジュールを切り替えるときに、切替元の処理モジュールと切替先の処理モジュールとの間で共通に使用されるパラメータの設定を、切替元の処理モジュールから切替先の処理モジュールへ継承させて自動的に設定することを特徴とする請求項４に記載の文書処理装置。
6. 前記プロパティ設定部は、前記処理モジュールが処理する前記文書中のデータの型の設定を受け付けることを特徴とする請求項４又は５に記載の文書処理装置。
7. 前記プロパティ設定部は、前記処理モジュールが前記文書中のデータを画面に表示する際に、そのデータのラベルとして表示するテキストデータの設定を受け付け、前記データのラベルとして表示するテキストデータがユーザから設定されない場合は、そのデータの要素名をラベルとして設定することを特徴とする請求項４から６のいずれかに記載の文書処理装置。
8. 文書中のデータを処理して所定の機能を発現するための汎用的な部品として利用可能な複数の処理モジュールのうちいずれかを前記文書中のデータに適用するステップと、
   別の前記処理モジュールを、同一の前記文書中のデータに対して切り替えて適用するステップと、
   を含むことを特徴とする文書処理装方法。
9. 文書中のデータを処理して所定の機能を発現するための汎用的な部品として利用可能な複数の処理モジュールと、
   同一の前記データに対して異なる複数の前記処理モジュールを切り替えて適用可能とする機能と、
   をコンピュータに実行させることを特徴とするプログラム。