文書処理装置及び文書処理方法
【課題】マークアップ言語により構造化されたデータを適切に処理する技術を提供する。
【解決手段】文書処理装置１００は、文書中のデータを利用して所定の機能を発現するＡＶＣコンポーネントを起動するための要素を文書に挿入する指示を受け付けたときに、ＡＶＣコンポーネントが利用する文書中のデータを設定するＡＶＣプロパティ設定部３００２と、文書にＡＶＣコンポーネントを起動するための要素を挿入する編集部として機能するＡＶＣコンポーネントを備え、ＡＶＣプロパティ設定部３００２は、文書中に繰り返し含まれる要素を取得し、それらの要素又はそれらの子孫の要素に属するノードの中から、ＡＶＣコンポーネントが利用するデータを抽出する。
【解決手段】文書処理装置１００は、文書中のデータを利用して所定の機能を発現するＡＶＣコンポーネントを起動するための要素を文書に挿入する指示を受け付けたときに、ＡＶＣコンポーネントが利用する文書中のデータを設定するＡＶＣプロパティ設定部３００２と、文書にＡＶＣコンポーネントを起動するための要素を挿入する編集部として機能するＡＶＣコンポーネントを備え、ＡＶＣプロパティ設定部３００２は、文書中に繰り返し含まれる要素を取得し、それらの要素又はそれらの子孫の要素に属するノードの中から、ＡＶＣコンポーネントが利用するデータを抽出する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、文書処理技術に関し、特に、マークアップ言語により記述された文書を処理する文書処理装置及び方法に関する。
【背景技術】
【０００２】
近年、インターネットを利用した技術の進歩が目覚ましく、我々は、世界中の様々な情報にアクセスできるようになっている。以前は、ＨＴＭＬで記述されたテキストベースのウェブページが主流であったが、インフラの整備が進んだ現在、ウェブページに画像、音楽、動画を貼り付けるなど、リッチな表現が主流となっている。
【０００３】
さらに、単にウェブページで情報を配信するだけでなく、ウェブページにスクリプトなどを記述して、さまざまな機能を実現できるようになっている。例えば、ＡｃｔｉｖｅＸコントロールとして開発されたアプリケーションを、ＶＢスクリプトで制御することにより、ウェブページ上でも様々なアプリケーションを動作させることができる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、ＡｃｔｉｖｅＸコントロール自体は内部がブラックボックス化されているので、ＡｃｔｉｖｅＸコントロール同士を相互に直接連携させて動作させるようなアプリケーションは実現できない。本発明者は、更に柔軟で拡張性、汎用性の高いアプリケーションの開発環境を提供するために、新たなプログラミング又はスクリプティングの技術思想を想到するに至った。
【０００５】
本発明はこうした状況に鑑みてなされたものであり、その目的は、マークアップ言語により構造化されたデータを適切に処理する技術を提供することにある。
【課題を解決するための手段】
【０００６】
本発明のある態様は、文書処理装置に関する。この文書処理装置は、文書中のデータを利用して所定の機能を発現する処理モジュールを起動するための要素を文書に挿入する指示を受け付けたときに、前記処理モジュールが利用する前記文書中のデータを設定する設定部と、前記文書に前記処理モジュールを起動するための要素を挿入する編集部と、を備え、前記設定部は、前記文書中に繰り返し含まれる要素を取得し、それらの要素又はそれらの子孫の要素に属するノードの中から、前記処理モジュールが利用するデータを抽出することを特徴とする。
【０００７】
前記設定部は、テキストデータが格納されているノードの中から、前記処理モジュールが利用するデータを抽出してもよい。前記設定部は、数値型のテキストデータが格納されているノードの中から、前記処理モジュールが利用するデータを抽出してもよい。
【０００８】
前記設定部は、前記文書中から抽出した前記処理モジュールが利用するデータの候補を提示し、提示した候補の中から前記処理モジュールが利用するデータの選択を受け付けてもよい。前記設定部は、前記繰り返し含まれる要素の親要素から選択されたデータを格納したノードへの相対パスと同じ相対パスを有する複数のノードを抽出して、それらのノードに格納されたデータを提示し、提示した複数のデータの中から前記処理モジュールが利用するデータの選択を受け付けてもよい。
【０００９】
前記設定部は、前記文書を解析することにより、前記繰り返し含まれる要素を自動的に抽出してもよい。
【００１０】
前記編集部は、前記文書中に、前記処理モジュールが利用するデータを指し示すポインタ情報を更に挿入してもよい。前記編集部は、前記処理モジュールを起動するための要素又はその子孫の要素に属するノードに、前記ポインタ情報を格納してもよい。前記設定部は、前記処理モジュールの動作に関するプロパティ情報の設定を受け付けてもよく、前記編集部は、前記プロパティ情報を更に前記処理モジュールを起動するための要素又はその子孫の要素に属するノードに格納してもよい。
【００１１】
前記編集部は、前記処理モジュールが利用するデータを指し示すポインタ情報を格納したファイルを前記文書とは別に生成してもよい。前記設定部は、前記処理モジュールの動作に関するプロパティ情報の設定を受け付けてもよく、前記編集部は、前記プロパティ情報を更に前記ファイルに格納してもよい。
【００１２】
本発明の別の態様は、文書処理方法に関する。この文書処理方法は、文書中のデータを利用して所定の機能を発現する処理モジュールを起動するための要素を文書に挿入する指示を受け付けたときに、前記処理モジュールが利用する前記文書中のデータを設定するステップと、前記文書に前記処理モジュールを起動するための要素を挿入するステップと、を備え、前記設定するステップは、前記文書中に繰り返し含まれる要素を取得し、それらの要素又はそれらの子孫の要素に属するノードの中から、前記処理モジュールが利用するデータを抽出することを特徴とする。
【００１３】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システムなどの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１４】
本発明によれば、マークアップ言語により構造化されたデータを適切に処理する技術を提供することができる。
【発明を実施するための最良の形態】
【００１５】
（前提技術）
図１は、前提技術に係る文書処理装置２０の構成を示す。文書処理装置２０は、文書内のデータが階層構造を有する複数の構成要素に分類された構造化文書を処理するが、本前提技術では構造化文書の一例としてＸＭＬ文書を処理する例について説明する。文書処理装置２０は、主制御ユニット２２、編集ユニット２４、ＤＯＭユニット３０、ＣＳＳユニット４０、ＨＴＭＬユニット５０、ＳＶＧユニット６０、及び変換部の一例であるＶＣユニット８０を備える。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【００１６】
主制御ユニット２２は、プラグインのロードや、コマンド実行のフレームワークを提供する。編集ユニット２４は、ＸＭＬ文書を編集するためのフレームワークを提供する。文書処理装置２０における文書の表示及び編集機能は、プラグインにより実現されており、文書の種別に応じて必要なプラグインが主制御ユニット２２又は編集ユニット２４によりロードされる。主制御ユニット２２又は編集ユニット２４は、処理対象となるＸＭＬ文書の名前空間を参照して、ＸＭＬ文書がいずれのボキャブラリにより記述されているかを判別し、そのボキャブラリに対応した表示又は編集用のプラグインをロードして表示や編集を実行させる。例えば、文書処理装置２０には、ＨＴＭＬ文書の表示及び編集を行うＨＴＭＬユニット５０、ＳＶＧ文書の表示及び編集を行うＳＶＧユニット６０など、ボキャブラリ（タグセット）ごとに表示系及び編集系がプラグインとして実装されており、ＨＴＭＬ文書を編集するときはＨＴＭＬユニット５０が、ＳＶＧ文書を編集するときはＳＶＧユニット６０が、それぞれロードされる。後述するように、ＨＴＭＬとＳＶＧの双方の構成要素を含む複合文書が処理対象となっている場合は、ＨＴＭＬユニット５０とＳＶＧユニット６０の双方がロードされる。
【００１７】
このような構成によれば、ユーザは、必要な機能のみを選択してインストールし、後から適宜機能を追加又は削除することができるので、プログラムを格納するハードディスクなどの記録媒体の記憶領域を有効に活用することができ、また、プログラム実行時にも、メモリの浪費を防ぐことができる。また、機能拡張性に優れており、開発主体としても、プラグインの形で新たなボキャブラリに対応することが可能なので開発が容易となり、ユーザとしても、プラグインの追加により容易かつ低コストにて機能を追加することができる。
【００１８】
編集ユニット２４は、ユーザインターフェースを介してユーザから編集指示のイベントを受け付け、そのイベントを適切なプラグインなどに通知するともに、イベントの再実行（リドゥ）又は実行の取消（アンドゥ）などの処理を制御する。
【００１９】
ＤＯＭユニット３０は、ＤＯＭ提供部３２、ＤＯＭ生成部３４、及び出力部３６を含み、ＸＭＬ文書をデータとして扱うときのアクセス方法を提供するために定められた文書オブジェクトモデル（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、及びElement Templateにアタッチされ、それぞれ、Vocabulary Connector、Template Connector、Element Connectorを生成ずる。
【０１７４】
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」のロードについての詳細な記述を示す。図２４（ａ）に示されるステップ１では、文書がストレージ１４０５からロードされる。DOM Serviceは、ＤＯＭツリー及び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」を発見し、XHTML Canvasの領域からSubPaneを生成する。
【０１８２】
図２５に示されるステップ４では、SubPaneが「sample: root」を扱うことができ、適切なZoneを生成可能なZoneFactoryを得る。このZoneFactoryは、ZoneFactoryを実行可能なVocabulary内にある。それは、「MySampleXML」のVocabulary Sectionの内容を含む。
【０１８３】
図２６に示されるステップ５では、「MySampleXML」に対応するVocabularyがDefaultZone１６０１を生成する。対応するEditletが生成され、対応するCanvasを生成するためにSubPane１５０１が提供される。Editletは、VCCanvasを生成する。そして、それはTemplate Sectionを呼ぶ。ConnectorFactoryTreeも含まれている。ConnectorFactoryTreeは、ConnectorTreeとなる全てのConnectorを生成する。
【０１８４】
図２７に示されるステップ６では、各ConnectorがデスティネーションＤＯＭオブジェクトを生成する。コネクタのうちのいくつかはxpath情報を含んでいる。xpath情報は、変更／修正を監視する必要のあるソースＤＯＭツリーの部分集合を決定するために使用される１以上のxpath表現を含む。
【０１８５】
図２８に示されるステップ７では、ボキャブラリは、ソースＤＯＭのペインからデスティネーションＤＯＭツリーのDestination Paneを作成する。これは、SourcePaneに基づいてなされる。デスティネーションツリーのApexNodeは、Destination Pane及び対応するZoneにアタッチされる。Destination Paneは、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要素に対して処理系を割り当てる際に、処理系を指定するＰＩが記述されている場合は、その処理系を優先的に割り当てる。この機能を利用すれば、ＡＶＣ機能を呼び出すために生成された定義ファイルをＰＩとして指定しておくことにより、ＡＶＣコンポーネントを優先的に割り当て、ＡＶＣ機能を発現させることができる。
【０２４２】
ＡＶＣプロパティ設定部３００２は、ＡＶＣプロパティを設定するときに、処理中の文書に記述された内容を解析して、ＡＶＣプロパティを自動的に設定してもよい。例えば、テーブル表示用ＡＶＣコンポーネント３０１０、チャート表示用ＡＶＣコンポーネント３０２０などのＡＶＣプロパティを設定するときに、文書中に繰り返し含まれる要素を取得し、それらの要素又はそれらの子孫の要素に属するテキストノードの中から数値型のテキストデータが格納されているノードを抽出して、テーブルの行、列、又は見出し、或いは、チャートの各軸又は見出しなどに自動的に設定してもよい。
【０２４３】
テーブル、チャート、グラフなどを生成するとき、ただ１つしか用意されていないデータを対象として生成することはまれで、通常は系列的に用意された複数のデータを対象とすることが多い。したがって、文書中に繰り返し登場する要素を自動的に抽出して候補として提示し、ユーザからデータの選択を受け付けることにより、ユーザがＡＶＣプロパティを設定するときの利便性を大幅に向上させることができる。
【０２４４】
図４２（ａ）（ｂ）は、サンプル文書を示す。図４２に示したサンプル文書では、ＸＨＴＭＬ文書の中に、テーブル用のボキャブラリで記述されたテーブルが挿入されている。図４２に示したサンプル文書では、テーブル用のボキャブラリ「table」の要素「table-column」が５つ、要素「table-row」が７つ設けられており、５列７行の表が表現されている。要素「table-row」のそれぞれは、セルの内容を格納する要素「table-cell」を有しており、行ごとに各セルの内容が記述されている。なお、図４２（ａ）（ｂ）においては、テーブルの各セルのスタイル情報などは省略している。
【０２４５】
図４３は、サンプル文書を表示した画面４０００の例を示す。スプレッドシート用のコンポーネントが、テーブル用のボキャブラリを解釈して、スプレッドシート４０１０を表示している。
【０２４６】
図４４は、サンプル文書にチャートを挿入するときのＡＶＣプロパティ設定画面の例を示す。ＡＶＣプロパティ設定画面４０２０には、文書中に繰り返し含まれる要素、すなわち、テーブル、チャート、グラフなどにおける系列データなどが格納された要素の親要素を指定する繰り返し要素欄４０３０が設けられている。ユーザが、画面左側のツリー画面４０２２において、繰り返し要素の親要素として指定する要素を選択し、繰り返し要素欄４０３０にドラッグ＆ドロップするか、設定ボタンをクリックすると、ＡＶＣプロパティ設定部３００２は、指定された要素を繰り返し要素の親要素として取得する。ＡＶＣプロパティ設定部３００２は、指定された要素の子要素である繰り返し要素、又はそれらの子孫の要素が有するテキストデータの中から、テーブル、チャート、グラフなどにおける系列データや見出しなどを設定する。以下、チャート表示用ＡＶＣコンポーネント３０２０のＡＶＣプロパティを設定する場合を例にとって説明する。
【０２４７】
ＡＶＣプロパティ設定画面４０２０には、更に、チャートの見出しを設定する見出し列欄４０３１、繰り返し要素のうちチャートに適用する範囲を設定する開始行欄４０３２及び終了行欄４０３３、チャートの系列データの一覧を表示する列一覧欄４０３４、各系列データを設定する列ノード欄４０３５、各系列データの見出しを設定する見出し欄４０３６が設けられている。ＡＶＣプロパティ設定部３００２は、これらの項目の他にも、チャートの種別、無効データの処理方法、データラベルの表示、桁区切り、凡例の表示位置、グラフのスタイル、チャートのタイトル、サブタイトル、項目軸、数値軸、表示領域の幅、高さなど、様々なプロパティを設定可能であるが、それらの詳細については省略する。
【０２４８】
ユーザが、ツリー画面４０２２において、チャートの見出しとして指定する要素を選択し、見出し列欄４０３１にドラッグ＆ドロップするか、設定ボタンをクリックすると、ＡＶＣプロパティ設定部３００２は、指定された要素をチャートの見出しとして取得する。ここでは、繰り返し要素の親要素として指定された「table-row」要素の直下にある１番目の「table-cell」要素の属性「string-value」の属性値、すなわち、「平成１４年」、「平成１５年」、「平成１６年」、などの文字列が見出しとして設定されている。
【０２４９】
開始行欄４０３２及び終了行欄４０３３では、繰り返し要素のうち、チャートの系列データとして適用する範囲を明示的に指定することができる。ユーザが、開始行欄４０３２又は終了行欄４０３３のチェックボックスをチェックして数値を入力すると、ＡＶＣプロパティ設定部３００２は、入力された数値を開始行又は終了行として取得する。後述するように、プレビュー画面４０２４においても、チャートの系列データとして適用する範囲を指定することができる。
【０２５０】
列一覧欄４０３４、列ノード欄４０３５、見出し欄４０３６では、チャートの系列データや系列の見出しとして利用するデータを設定することができる。列一覧欄４０３４には、チャートの系列データとして指定されたノードの一覧が表示される。ユーザが自動設定ボタンをクリックすると、ＡＶＣプロパティ設定部３００２は、繰り返し要素の親要素として指定された要素の子要素又はそれらの要素の子孫の要素に属するテキストデータを抽出して、ユーザに提示する。ユーザは、提示されたテキストデータの中から、系列データとして指定するテキストデータを選択することができる。
【０２５１】
図４５は、列ノードを自動設定するための設定画面の例を示す。設定画面４０３７には、ＡＶＣプロパティ設定部３００２により、系列データとして指定可能なテキストノード値又は属性値の一覧が表示されている。図４５の例では、１番目の要素「table-row」の下位にある要素「p」のテキストデータが表示されている。ユーザは、「次へ」ボタンや「前へ」ボタンをクリックすることにより、兄弟の要素「table-row」の下位にあるテキストノード値や属性値を表示させることができる。また、ユーザは、テキストノード値のみを表示するか、属性値のみを表示するか、双方を表示するかを選択することができる。
【０２５２】
ユーザが、一覧表示されたデータの中から系列データとして指定するデータを選択すると、ＡＶＣプロパティ設定部３００２は、繰り返し含まれる要素の親要素から選択されたデータを格納したノードへの相対パスと同じ相対パスを有する複数のノードを抽出して、ノードの数だけ行を生成し、プレビュー画面４０２４のテーブルに、それらのノードに格納されたデータを提示する。
【０２５３】
図４６は、チャート表示用ＡＶＣプロパティが設定された設定画面の例を示す。プレビュー画面４０２４には、設定された系列データが表形式で表示されている。表の第１行には、各系列データの見出しが、第１列には各行の見出しが表示されている。第２行以降、第２列以降には、各系列データの値が表示されている。ユーザは、それぞれの行に設けられたチェックボックスにより、提示された複数のデータの中から、チャートに適用するデータを選択することができる。
【０２５４】
ＡＶＣプロパティ設定部３００２は、文書を解析することにより、繰り返し含まれる要素を自動的に抽出してもよい。例えば、ＸＨＴＭＬの「tr」タグと「td」タグと同様の関係にある要素を自動的に抽出してもよい。図４２（ａ）（ｂ）の例では、複数の要素「table-cell」を有する要素「table-row」が文書に繰り返し登場しているので、要素「table-row」を繰り返し要素の親要素として自動的に抽出してもよい。また、図２の例では、複数の要素「国語」、「数学」、「理科」、「社会」を有する要素「生徒」が文書に繰り返し登場しているので、要素「生徒」を繰り返し要素の親要素として自動的に抽出してもよい。これにより、ユーザが繰り返し要素を指定する手間を軽減し、ユーザの利便性を大幅に向上させることができる。
【０２５５】
ユーザがＡＶＣプロパティの設定を終了すると、ＡＶＣプロパティ設定部３００２は、ＡＶＣコンポーネント、ここではチャート表示用ＡＶＣコンポーネント３０２０に対して、設定したプロパティ情報を通知する。チャート表示用ＡＶＣコンポーネント３０２０は、設定されたプロパティ情報を文書中に挿入する。前述したように、チャート表示用ＡＶＣコンポーネント３０２０は、文書中のチャートの挿入位置に、チャート表示用ＡＶＣコンポーネント３０２０を起動するためのチャート表示用のボキャブラリの要素を挿入し、その要素又はその子孫の要素に属するノードに、チャート表示用ＡＶＣコンポーネント３０２０が利用するデータを指し示すポインタ情報や、チャート表示用ＡＶＣコンポーネント３０２０の動作に関するＡＶＣプロパティ情報を格納する。ＡＶＣプロパティ情報は、前述したように、ＡＶＣプロパティファイルに格納されてもよい。
【０２５６】
図４７は、チャート表示用ＡＶＣコンポーネントによりチャートが表示された画面を示す図である。チャート表示用ＡＶＣコンポーネント３０２０は、設定されたＡＶＣプロパティ情報に基づいて、チャート４０４０を表示する。このような技術により、文書中の他の部分に記述されたデータを参照したチャートなどを容易に文書に埋め込むことができる。ここでは、チャートについて説明したが、テーブルやグラフなどについても同様である。
【０２５７】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【０２５８】
実施の形態では、ＸＭＬ文書を処理する例について説明したが、本実施の形態の文書処理装置１００は、他のマークアップ言語、例えば、ＳＧＭＬ、ＨＴＭＬなどで記述された文書も同様に処理可能である。
【図面の簡単な説明】
【０２５９】
【図１】前提技術に係る文書処理装置の構成を示す図である。
【図２】文書処理装置により編集されるＸＭＬ文書の例を示す図である。
【図３】図２に示したＸＭＬ文書をＨＴＭＬで記述された表にマッピングする例を示す図である。
【図４（ａ）】図２に示したＸＭＬ文書を図３に示した表にマッピングするための定義ファイルの例を示す図である。
【図４（ｂ）】図２に示したＸＭＬ文書を図３に示した表にマッピングするための定義ファイルの例を示す図である。
【図５】図２に示したＸＭＬ文書を、図３に示した対応によりＨＴＭＬにマッピングして表示した画面の例を示す図である。
【図６】ユーザが定義ファイルを生成するために、定義ファイル生成部がユーザに提示するグラフィカルユーザインターフェースの例を示す図である。
【図７】定義ファイル生成部により生成された画面レイアウトの他の例を示す図である。
【図８】文書処理装置によるＸＭＬ文書の編集画面の一例を示す図である。
【図９】文書処理装置により編集されるＸＭＬ文書の他の例を示す図である。
【図１０】図９に示した文書を表示した画面の例を示す図である。
【図１１（ａ）】文書処理システムの基本構成を示す図である。
【図１１（ｂ）】文書処理システム全体のブロック図を示す図である。
【図１１（ｃ）】文書処理システム全体のブロック図を示す図である。
【図１２】文書管理部の詳細を示す図である。
【図１３】ボキャブラリコネクションサブシステムの詳細を示す図である。
【図１４】プログラム起動部と他の構成の関係の詳細を示す図である。
【図１５】プログラム起動部によりロードされたアプリケーションサービスの構造の詳細を示す図である。
【図１６】コアコンポーネントの詳細を示す図である。
【図１７】文書管理部の詳細を示す図である。
【図１８】アンドゥフレームワークとアンドゥコマンドの詳細を示す図である。
【図１９】文書処理システムにおいて文書がロードされる様子を示す図である。
【図２０】文書とその表現の例を示す図である。
【図２１】モデルとコントローラの関係を示す図である。
【図２２】プラグインサブシステム、ボキャブラリコネクション、及びコネクタの詳細を示す図である。
【図２３】ＶＣＤファイルの例を示す図である。
【図２４】文書処理システムにおいて複合文書をロードする手順を示す図である。
【図２５】文書処理システムにおいて複合文書をロードする手順を示す図である。
【図２６】文書処理システムにおいて複合文書をロードする手順を示す図である。
【図２７】文書処理システムにおいて複合文書をロードする手順を示す図である。
【図２８】文書処理システムにおいて複合文書をロードする手順を示す図である。
【図２９】コマンドの流れを示す図である。
【図３０】図３０（ａ）（ｂ）（ｃ）は、処理対象となるＸＭＬ文書のデータ構造の例を示す図である。
【図３１】図３１（ａ）（ｂ）は、ポインタ情報の例を示す図である。
【図３２】図３２（ａ）（ｂ）は、ＤＯＭの変更を通知する仕組みを説明するための図である。
【図３３】第１の実施の形態に係る文書処理装置の構成を示す図である。
【図３４】文書の編集画面の例を示す図である。
【図３５】スケジュール用のビューテンプレートが起動された状態の編集画面を示す図である。
【図３６】第２の実施の形態に係る文書処理装置の構成を示す図である。
【図３７】ＡＶＣコンポーネントのプロパティが挿入されたＸＭＬ文書の例を示す図である。
【図３８】第２の実施の形態に係る文書処理方法の手順を示す図である。
【図３９】ＡＶＣコンポーネントにより表示された画面の例を示す図である。
【図４０】第３の実施の形態に係る文書処理装置の構成を示す図である。
【図４１】第３の実施の形態に係る文書処理方法の手順を示す図である。
【図４２（ａ）】サンプル文書を示す図である。
【図４２（ｂ）】サンプル文書を示す図である。
【図４３】サンプル文書を表示した画面の例を示す図である。
【図４４】サンプル文書にチャートを挿入するときのＡＶＣプロパティ設定画面の例を示す図である。
【図４５】列ノードを自動設定するための設定画面の例を示す図である。
【図４６】チャート表示用ＡＶＣプロパティが設定された設定画面の例を示す図である。
【図４７】チャート表示用ＡＶＣコンポーネントによりチャートが表示された画面を示す図である。
【符号の説明】
【０２６０】
２０ 文書処理装置、２２ 主制御ユニット、２４ 編集ユニット、２７ 概念解決エンジン、２８ 通知部、３０ ＤＯＭユニット、３２ ＤＯＭ提供部、３４ ＤＯＭ生成部、３６ 出力部、４０ ＣＳＳユニット、４２ ＣＳＳ解析部、４４ ＣＳＳ提供部、４６ レンダリング部、５０ ＨＴＭＬユニット、５２，６２ 制御部、５４，６４ 編集部、５６，６６ 表示部、６０ ＳＶＧユニット、７０ ビューテンプレート制御ユニット、７１ 取得部、７２ 提示部、７４ 受付部、７６ 編集部、７８ ビューテンプレート、８０ ＶＣユニット、８２ マッピング部、８４ 定義ファイル取得部、８６ 定義ファイル生成部、１００ 文書処理装置、３０００ ＡＶＣ制御ユニット、３００２ ＡＶＣプロパティ設定部、３００４ ＡＶＣプロパティ生成部、３００６ 定義ファイル生成部、３０１０ テーブル表示用ＡＶＣコンポーネント、３０２０ チャート表示用ＡＶＣコンポーネント、３０３０ ＵＩパーツ表示用ＡＶＣコンポーネント、３０４０ ツリー表示用ＡＶＣコンポーネント。
【技術分野】
【０００１】
本発明は、文書処理技術に関し、特に、マークアップ言語により記述された文書を処理する文書処理装置及び方法に関する。
【背景技術】
【０００２】
近年、インターネットを利用した技術の進歩が目覚ましく、我々は、世界中の様々な情報にアクセスできるようになっている。以前は、ＨＴＭＬで記述されたテキストベースのウェブページが主流であったが、インフラの整備が進んだ現在、ウェブページに画像、音楽、動画を貼り付けるなど、リッチな表現が主流となっている。
【０００３】
さらに、単にウェブページで情報を配信するだけでなく、ウェブページにスクリプトなどを記述して、さまざまな機能を実現できるようになっている。例えば、ＡｃｔｉｖｅＸコントロールとして開発されたアプリケーションを、ＶＢスクリプトで制御することにより、ウェブページ上でも様々なアプリケーションを動作させることができる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、ＡｃｔｉｖｅＸコントロール自体は内部がブラックボックス化されているので、ＡｃｔｉｖｅＸコントロール同士を相互に直接連携させて動作させるようなアプリケーションは実現できない。本発明者は、更に柔軟で拡張性、汎用性の高いアプリケーションの開発環境を提供するために、新たなプログラミング又はスクリプティングの技術思想を想到するに至った。
【０００５】
本発明はこうした状況に鑑みてなされたものであり、その目的は、マークアップ言語により構造化されたデータを適切に処理する技術を提供することにある。
【課題を解決するための手段】
【０００６】
本発明のある態様は、文書処理装置に関する。この文書処理装置は、文書中のデータを利用して所定の機能を発現する処理モジュールを起動するための要素を文書に挿入する指示を受け付けたときに、前記処理モジュールが利用する前記文書中のデータを設定する設定部と、前記文書に前記処理モジュールを起動するための要素を挿入する編集部と、を備え、前記設定部は、前記文書中に繰り返し含まれる要素を取得し、それらの要素又はそれらの子孫の要素に属するノードの中から、前記処理モジュールが利用するデータを抽出することを特徴とする。
【０００７】
前記設定部は、テキストデータが格納されているノードの中から、前記処理モジュールが利用するデータを抽出してもよい。前記設定部は、数値型のテキストデータが格納されているノードの中から、前記処理モジュールが利用するデータを抽出してもよい。
【０００８】
前記設定部は、前記文書中から抽出した前記処理モジュールが利用するデータの候補を提示し、提示した候補の中から前記処理モジュールが利用するデータの選択を受け付けてもよい。前記設定部は、前記繰り返し含まれる要素の親要素から選択されたデータを格納したノードへの相対パスと同じ相対パスを有する複数のノードを抽出して、それらのノードに格納されたデータを提示し、提示した複数のデータの中から前記処理モジュールが利用するデータの選択を受け付けてもよい。
【０００９】
前記設定部は、前記文書を解析することにより、前記繰り返し含まれる要素を自動的に抽出してもよい。
【００１０】
前記編集部は、前記文書中に、前記処理モジュールが利用するデータを指し示すポインタ情報を更に挿入してもよい。前記編集部は、前記処理モジュールを起動するための要素又はその子孫の要素に属するノードに、前記ポインタ情報を格納してもよい。前記設定部は、前記処理モジュールの動作に関するプロパティ情報の設定を受け付けてもよく、前記編集部は、前記プロパティ情報を更に前記処理モジュールを起動するための要素又はその子孫の要素に属するノードに格納してもよい。
【００１１】
前記編集部は、前記処理モジュールが利用するデータを指し示すポインタ情報を格納したファイルを前記文書とは別に生成してもよい。前記設定部は、前記処理モジュールの動作に関するプロパティ情報の設定を受け付けてもよく、前記編集部は、前記プロパティ情報を更に前記ファイルに格納してもよい。
【００１２】
本発明の別の態様は、文書処理方法に関する。この文書処理方法は、文書中のデータを利用して所定の機能を発現する処理モジュールを起動するための要素を文書に挿入する指示を受け付けたときに、前記処理モジュールが利用する前記文書中のデータを設定するステップと、前記文書に前記処理モジュールを起動するための要素を挿入するステップと、を備え、前記設定するステップは、前記文書中に繰り返し含まれる要素を取得し、それらの要素又はそれらの子孫の要素に属するノードの中から、前記処理モジュールが利用するデータを抽出することを特徴とする。
【００１３】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システムなどの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１４】
本発明によれば、マークアップ言語により構造化されたデータを適切に処理する技術を提供することができる。
【発明を実施するための最良の形態】
【００１５】
（前提技術）
図１は、前提技術に係る文書処理装置２０の構成を示す。文書処理装置２０は、文書内のデータが階層構造を有する複数の構成要素に分類された構造化文書を処理するが、本前提技術では構造化文書の一例としてＸＭＬ文書を処理する例について説明する。文書処理装置２０は、主制御ユニット２２、編集ユニット２４、ＤＯＭユニット３０、ＣＳＳユニット４０、ＨＴＭＬユニット５０、ＳＶＧユニット６０、及び変換部の一例であるＶＣユニット８０を備える。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【００１６】
主制御ユニット２２は、プラグインのロードや、コマンド実行のフレームワークを提供する。編集ユニット２４は、ＸＭＬ文書を編集するためのフレームワークを提供する。文書処理装置２０における文書の表示及び編集機能は、プラグインにより実現されており、文書の種別に応じて必要なプラグインが主制御ユニット２２又は編集ユニット２４によりロードされる。主制御ユニット２２又は編集ユニット２４は、処理対象となるＸＭＬ文書の名前空間を参照して、ＸＭＬ文書がいずれのボキャブラリにより記述されているかを判別し、そのボキャブラリに対応した表示又は編集用のプラグインをロードして表示や編集を実行させる。例えば、文書処理装置２０には、ＨＴＭＬ文書の表示及び編集を行うＨＴＭＬユニット５０、ＳＶＧ文書の表示及び編集を行うＳＶＧユニット６０など、ボキャブラリ（タグセット）ごとに表示系及び編集系がプラグインとして実装されており、ＨＴＭＬ文書を編集するときはＨＴＭＬユニット５０が、ＳＶＧ文書を編集するときはＳＶＧユニット６０が、それぞれロードされる。後述するように、ＨＴＭＬとＳＶＧの双方の構成要素を含む複合文書が処理対象となっている場合は、ＨＴＭＬユニット５０とＳＶＧユニット６０の双方がロードされる。
【００１７】
このような構成によれば、ユーザは、必要な機能のみを選択してインストールし、後から適宜機能を追加又は削除することができるので、プログラムを格納するハードディスクなどの記録媒体の記憶領域を有効に活用することができ、また、プログラム実行時にも、メモリの浪費を防ぐことができる。また、機能拡張性に優れており、開発主体としても、プラグインの形で新たなボキャブラリに対応することが可能なので開発が容易となり、ユーザとしても、プラグインの追加により容易かつ低コストにて機能を追加することができる。
【００１８】
編集ユニット２４は、ユーザインターフェースを介してユーザから編集指示のイベントを受け付け、そのイベントを適切なプラグインなどに通知するともに、イベントの再実行（リドゥ）又は実行の取消（アンドゥ）などの処理を制御する。
【００１９】
ＤＯＭユニット３０は、ＤＯＭ提供部３２、ＤＯＭ生成部３４、及び出力部３６を含み、ＸＭＬ文書をデータとして扱うときのアクセス方法を提供するために定められた文書オブジェクトモデル（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、及びElement Templateにアタッチされ、それぞれ、Vocabulary Connector、Template Connector、Element Connectorを生成ずる。
【０１７４】
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」のロードについての詳細な記述を示す。図２４（ａ）に示されるステップ１では、文書がストレージ１４０５からロードされる。DOM Serviceは、ＤＯＭツリー及び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」を発見し、XHTML Canvasの領域からSubPaneを生成する。
【０１８２】
図２５に示されるステップ４では、SubPaneが「sample: root」を扱うことができ、適切なZoneを生成可能なZoneFactoryを得る。このZoneFactoryは、ZoneFactoryを実行可能なVocabulary内にある。それは、「MySampleXML」のVocabulary Sectionの内容を含む。
【０１８３】
図２６に示されるステップ５では、「MySampleXML」に対応するVocabularyがDefaultZone１６０１を生成する。対応するEditletが生成され、対応するCanvasを生成するためにSubPane１５０１が提供される。Editletは、VCCanvasを生成する。そして、それはTemplate Sectionを呼ぶ。ConnectorFactoryTreeも含まれている。ConnectorFactoryTreeは、ConnectorTreeとなる全てのConnectorを生成する。
【０１８４】
図２７に示されるステップ６では、各ConnectorがデスティネーションＤＯＭオブジェクトを生成する。コネクタのうちのいくつかはxpath情報を含んでいる。xpath情報は、変更／修正を監視する必要のあるソースＤＯＭツリーの部分集合を決定するために使用される１以上のxpath表現を含む。
【０１８５】
図２８に示されるステップ７では、ボキャブラリは、ソースＤＯＭのペインからデスティネーションＤＯＭツリーのDestination Paneを作成する。これは、SourcePaneに基づいてなされる。デスティネーションツリーのApexNodeは、Destination Pane及び対応するZoneにアタッチされる。Destination Paneは、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要素に対して処理系を割り当てる際に、処理系を指定するＰＩが記述されている場合は、その処理系を優先的に割り当てる。この機能を利用すれば、ＡＶＣ機能を呼び出すために生成された定義ファイルをＰＩとして指定しておくことにより、ＡＶＣコンポーネントを優先的に割り当て、ＡＶＣ機能を発現させることができる。
【０２４２】
ＡＶＣプロパティ設定部３００２は、ＡＶＣプロパティを設定するときに、処理中の文書に記述された内容を解析して、ＡＶＣプロパティを自動的に設定してもよい。例えば、テーブル表示用ＡＶＣコンポーネント３０１０、チャート表示用ＡＶＣコンポーネント３０２０などのＡＶＣプロパティを設定するときに、文書中に繰り返し含まれる要素を取得し、それらの要素又はそれらの子孫の要素に属するテキストノードの中から数値型のテキストデータが格納されているノードを抽出して、テーブルの行、列、又は見出し、或いは、チャートの各軸又は見出しなどに自動的に設定してもよい。
【０２４３】
テーブル、チャート、グラフなどを生成するとき、ただ１つしか用意されていないデータを対象として生成することはまれで、通常は系列的に用意された複数のデータを対象とすることが多い。したがって、文書中に繰り返し登場する要素を自動的に抽出して候補として提示し、ユーザからデータの選択を受け付けることにより、ユーザがＡＶＣプロパティを設定するときの利便性を大幅に向上させることができる。
【０２４４】
図４２（ａ）（ｂ）は、サンプル文書を示す。図４２に示したサンプル文書では、ＸＨＴＭＬ文書の中に、テーブル用のボキャブラリで記述されたテーブルが挿入されている。図４２に示したサンプル文書では、テーブル用のボキャブラリ「table」の要素「table-column」が５つ、要素「table-row」が７つ設けられており、５列７行の表が表現されている。要素「table-row」のそれぞれは、セルの内容を格納する要素「table-cell」を有しており、行ごとに各セルの内容が記述されている。なお、図４２（ａ）（ｂ）においては、テーブルの各セルのスタイル情報などは省略している。
【０２４５】
図４３は、サンプル文書を表示した画面４０００の例を示す。スプレッドシート用のコンポーネントが、テーブル用のボキャブラリを解釈して、スプレッドシート４０１０を表示している。
【０２４６】
図４４は、サンプル文書にチャートを挿入するときのＡＶＣプロパティ設定画面の例を示す。ＡＶＣプロパティ設定画面４０２０には、文書中に繰り返し含まれる要素、すなわち、テーブル、チャート、グラフなどにおける系列データなどが格納された要素の親要素を指定する繰り返し要素欄４０３０が設けられている。ユーザが、画面左側のツリー画面４０２２において、繰り返し要素の親要素として指定する要素を選択し、繰り返し要素欄４０３０にドラッグ＆ドロップするか、設定ボタンをクリックすると、ＡＶＣプロパティ設定部３００２は、指定された要素を繰り返し要素の親要素として取得する。ＡＶＣプロパティ設定部３００２は、指定された要素の子要素である繰り返し要素、又はそれらの子孫の要素が有するテキストデータの中から、テーブル、チャート、グラフなどにおける系列データや見出しなどを設定する。以下、チャート表示用ＡＶＣコンポーネント３０２０のＡＶＣプロパティを設定する場合を例にとって説明する。
【０２４７】
ＡＶＣプロパティ設定画面４０２０には、更に、チャートの見出しを設定する見出し列欄４０３１、繰り返し要素のうちチャートに適用する範囲を設定する開始行欄４０３２及び終了行欄４０３３、チャートの系列データの一覧を表示する列一覧欄４０３４、各系列データを設定する列ノード欄４０３５、各系列データの見出しを設定する見出し欄４０３６が設けられている。ＡＶＣプロパティ設定部３００２は、これらの項目の他にも、チャートの種別、無効データの処理方法、データラベルの表示、桁区切り、凡例の表示位置、グラフのスタイル、チャートのタイトル、サブタイトル、項目軸、数値軸、表示領域の幅、高さなど、様々なプロパティを設定可能であるが、それらの詳細については省略する。
【０２４８】
ユーザが、ツリー画面４０２２において、チャートの見出しとして指定する要素を選択し、見出し列欄４０３１にドラッグ＆ドロップするか、設定ボタンをクリックすると、ＡＶＣプロパティ設定部３００２は、指定された要素をチャートの見出しとして取得する。ここでは、繰り返し要素の親要素として指定された「table-row」要素の直下にある１番目の「table-cell」要素の属性「string-value」の属性値、すなわち、「平成１４年」、「平成１５年」、「平成１６年」、などの文字列が見出しとして設定されている。
【０２４９】
開始行欄４０３２及び終了行欄４０３３では、繰り返し要素のうち、チャートの系列データとして適用する範囲を明示的に指定することができる。ユーザが、開始行欄４０３２又は終了行欄４０３３のチェックボックスをチェックして数値を入力すると、ＡＶＣプロパティ設定部３００２は、入力された数値を開始行又は終了行として取得する。後述するように、プレビュー画面４０２４においても、チャートの系列データとして適用する範囲を指定することができる。
【０２５０】
列一覧欄４０３４、列ノード欄４０３５、見出し欄４０３６では、チャートの系列データや系列の見出しとして利用するデータを設定することができる。列一覧欄４０３４には、チャートの系列データとして指定されたノードの一覧が表示される。ユーザが自動設定ボタンをクリックすると、ＡＶＣプロパティ設定部３００２は、繰り返し要素の親要素として指定された要素の子要素又はそれらの要素の子孫の要素に属するテキストデータを抽出して、ユーザに提示する。ユーザは、提示されたテキストデータの中から、系列データとして指定するテキストデータを選択することができる。
【０２５１】
図４５は、列ノードを自動設定するための設定画面の例を示す。設定画面４０３７には、ＡＶＣプロパティ設定部３００２により、系列データとして指定可能なテキストノード値又は属性値の一覧が表示されている。図４５の例では、１番目の要素「table-row」の下位にある要素「p」のテキストデータが表示されている。ユーザは、「次へ」ボタンや「前へ」ボタンをクリックすることにより、兄弟の要素「table-row」の下位にあるテキストノード値や属性値を表示させることができる。また、ユーザは、テキストノード値のみを表示するか、属性値のみを表示するか、双方を表示するかを選択することができる。
【０２５２】
ユーザが、一覧表示されたデータの中から系列データとして指定するデータを選択すると、ＡＶＣプロパティ設定部３００２は、繰り返し含まれる要素の親要素から選択されたデータを格納したノードへの相対パスと同じ相対パスを有する複数のノードを抽出して、ノードの数だけ行を生成し、プレビュー画面４０２４のテーブルに、それらのノードに格納されたデータを提示する。
【０２５３】
図４６は、チャート表示用ＡＶＣプロパティが設定された設定画面の例を示す。プレビュー画面４０２４には、設定された系列データが表形式で表示されている。表の第１行には、各系列データの見出しが、第１列には各行の見出しが表示されている。第２行以降、第２列以降には、各系列データの値が表示されている。ユーザは、それぞれの行に設けられたチェックボックスにより、提示された複数のデータの中から、チャートに適用するデータを選択することができる。
【０２５４】
ＡＶＣプロパティ設定部３００２は、文書を解析することにより、繰り返し含まれる要素を自動的に抽出してもよい。例えば、ＸＨＴＭＬの「tr」タグと「td」タグと同様の関係にある要素を自動的に抽出してもよい。図４２（ａ）（ｂ）の例では、複数の要素「table-cell」を有する要素「table-row」が文書に繰り返し登場しているので、要素「table-row」を繰り返し要素の親要素として自動的に抽出してもよい。また、図２の例では、複数の要素「国語」、「数学」、「理科」、「社会」を有する要素「生徒」が文書に繰り返し登場しているので、要素「生徒」を繰り返し要素の親要素として自動的に抽出してもよい。これにより、ユーザが繰り返し要素を指定する手間を軽減し、ユーザの利便性を大幅に向上させることができる。
【０２５５】
ユーザがＡＶＣプロパティの設定を終了すると、ＡＶＣプロパティ設定部３００２は、ＡＶＣコンポーネント、ここではチャート表示用ＡＶＣコンポーネント３０２０に対して、設定したプロパティ情報を通知する。チャート表示用ＡＶＣコンポーネント３０２０は、設定されたプロパティ情報を文書中に挿入する。前述したように、チャート表示用ＡＶＣコンポーネント３０２０は、文書中のチャートの挿入位置に、チャート表示用ＡＶＣコンポーネント３０２０を起動するためのチャート表示用のボキャブラリの要素を挿入し、その要素又はその子孫の要素に属するノードに、チャート表示用ＡＶＣコンポーネント３０２０が利用するデータを指し示すポインタ情報や、チャート表示用ＡＶＣコンポーネント３０２０の動作に関するＡＶＣプロパティ情報を格納する。ＡＶＣプロパティ情報は、前述したように、ＡＶＣプロパティファイルに格納されてもよい。
【０２５６】
図４７は、チャート表示用ＡＶＣコンポーネントによりチャートが表示された画面を示す図である。チャート表示用ＡＶＣコンポーネント３０２０は、設定されたＡＶＣプロパティ情報に基づいて、チャート４０４０を表示する。このような技術により、文書中の他の部分に記述されたデータを参照したチャートなどを容易に文書に埋め込むことができる。ここでは、チャートについて説明したが、テーブルやグラフなどについても同様である。
【０２５７】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【０２５８】
実施の形態では、ＸＭＬ文書を処理する例について説明したが、本実施の形態の文書処理装置１００は、他のマークアップ言語、例えば、ＳＧＭＬ、ＨＴＭＬなどで記述された文書も同様に処理可能である。
【図面の簡単な説明】
【０２５９】
【図１】前提技術に係る文書処理装置の構成を示す図である。
【図２】文書処理装置により編集されるＸＭＬ文書の例を示す図である。
【図３】図２に示したＸＭＬ文書をＨＴＭＬで記述された表にマッピングする例を示す図である。
【図４（ａ）】図２に示したＸＭＬ文書を図３に示した表にマッピングするための定義ファイルの例を示す図である。
【図４（ｂ）】図２に示したＸＭＬ文書を図３に示した表にマッピングするための定義ファイルの例を示す図である。
【図５】図２に示したＸＭＬ文書を、図３に示した対応によりＨＴＭＬにマッピングして表示した画面の例を示す図である。
【図６】ユーザが定義ファイルを生成するために、定義ファイル生成部がユーザに提示するグラフィカルユーザインターフェースの例を示す図である。
【図７】定義ファイル生成部により生成された画面レイアウトの他の例を示す図である。
【図８】文書処理装置によるＸＭＬ文書の編集画面の一例を示す図である。
【図９】文書処理装置により編集されるＸＭＬ文書の他の例を示す図である。
【図１０】図９に示した文書を表示した画面の例を示す図である。
【図１１（ａ）】文書処理システムの基本構成を示す図である。
【図１１（ｂ）】文書処理システム全体のブロック図を示す図である。
【図１１（ｃ）】文書処理システム全体のブロック図を示す図である。
【図１２】文書管理部の詳細を示す図である。
【図１３】ボキャブラリコネクションサブシステムの詳細を示す図である。
【図１４】プログラム起動部と他の構成の関係の詳細を示す図である。
【図１５】プログラム起動部によりロードされたアプリケーションサービスの構造の詳細を示す図である。
【図１６】コアコンポーネントの詳細を示す図である。
【図１７】文書管理部の詳細を示す図である。
【図１８】アンドゥフレームワークとアンドゥコマンドの詳細を示す図である。
【図１９】文書処理システムにおいて文書がロードされる様子を示す図である。
【図２０】文書とその表現の例を示す図である。
【図２１】モデルとコントローラの関係を示す図である。
【図２２】プラグインサブシステム、ボキャブラリコネクション、及びコネクタの詳細を示す図である。
【図２３】ＶＣＤファイルの例を示す図である。
【図２４】文書処理システムにおいて複合文書をロードする手順を示す図である。
【図２５】文書処理システムにおいて複合文書をロードする手順を示す図である。
【図２６】文書処理システムにおいて複合文書をロードする手順を示す図である。
【図２７】文書処理システムにおいて複合文書をロードする手順を示す図である。
【図２８】文書処理システムにおいて複合文書をロードする手順を示す図である。
【図２９】コマンドの流れを示す図である。
【図３０】図３０（ａ）（ｂ）（ｃ）は、処理対象となるＸＭＬ文書のデータ構造の例を示す図である。
【図３１】図３１（ａ）（ｂ）は、ポインタ情報の例を示す図である。
【図３２】図３２（ａ）（ｂ）は、ＤＯＭの変更を通知する仕組みを説明するための図である。
【図３３】第１の実施の形態に係る文書処理装置の構成を示す図である。
【図３４】文書の編集画面の例を示す図である。
【図３５】スケジュール用のビューテンプレートが起動された状態の編集画面を示す図である。
【図３６】第２の実施の形態に係る文書処理装置の構成を示す図である。
【図３７】ＡＶＣコンポーネントのプロパティが挿入されたＸＭＬ文書の例を示す図である。
【図３８】第２の実施の形態に係る文書処理方法の手順を示す図である。
【図３９】ＡＶＣコンポーネントにより表示された画面の例を示す図である。
【図４０】第３の実施の形態に係る文書処理装置の構成を示す図である。
【図４１】第３の実施の形態に係る文書処理方法の手順を示す図である。
【図４２（ａ）】サンプル文書を示す図である。
【図４２（ｂ）】サンプル文書を示す図である。
【図４３】サンプル文書を表示した画面の例を示す図である。
【図４４】サンプル文書にチャートを挿入するときのＡＶＣプロパティ設定画面の例を示す図である。
【図４５】列ノードを自動設定するための設定画面の例を示す図である。
【図４６】チャート表示用ＡＶＣプロパティが設定された設定画面の例を示す図である。
【図４７】チャート表示用ＡＶＣコンポーネントによりチャートが表示された画面を示す図である。
【符号の説明】
【０２６０】
２０ 文書処理装置、２２ 主制御ユニット、２４ 編集ユニット、２７ 概念解決エンジン、２８ 通知部、３０ ＤＯＭユニット、３２ ＤＯＭ提供部、３４ ＤＯＭ生成部、３６ 出力部、４０ ＣＳＳユニット、４２ ＣＳＳ解析部、４４ ＣＳＳ提供部、４６ レンダリング部、５０ ＨＴＭＬユニット、５２，６２ 制御部、５４，６４ 編集部、５６，６６ 表示部、６０ ＳＶＧユニット、７０ ビューテンプレート制御ユニット、７１ 取得部、７２ 提示部、７４ 受付部、７６ 編集部、７８ ビューテンプレート、８０ ＶＣユニット、８２ マッピング部、８４ 定義ファイル取得部、８６ 定義ファイル生成部、１００ 文書処理装置、３０００ ＡＶＣ制御ユニット、３００２ ＡＶＣプロパティ設定部、３００４ ＡＶＣプロパティ生成部、３００６ 定義ファイル生成部、３０１０ テーブル表示用ＡＶＣコンポーネント、３０２０ チャート表示用ＡＶＣコンポーネント、３０３０ ＵＩパーツ表示用ＡＶＣコンポーネント、３０４０ ツリー表示用ＡＶＣコンポーネント。
【特許請求の範囲】
【請求項１】
文書中のデータを利用して所定の機能を発現する処理モジュールを起動するための要素を文書に挿入する指示を受け付けたときに、前記処理モジュールが利用する前記文書中のデータを設定する設定部と、
前記文書に前記処理モジュールを起動するための要素を挿入する編集部と、を備え、
前記設定部は、前記文書中に繰り返し含まれる要素を取得し、それらの要素又はそれらの子孫の要素に属するノードの中から、前記処理モジュールが利用するデータを抽出することを特徴とする文書処理装置。
【請求項２】
前記設定部は、テキストデータが格納されているノードの中から、前記処理モジュールが利用するデータを抽出することを特徴とする請求項１に記載の文書処理装置。
【請求項３】
前記設定部は、数値型のテキストデータが格納されているノードの中から、前記処理モジュールが利用するデータを抽出することを特徴とする請求項２に記載の文書処理装置。
【請求項４】
前記設定部は、前記文書中から抽出した前記処理モジュールが利用するデータの候補を提示し、提示した候補の中から前記処理モジュールが利用するデータの選択を受け付けることを特徴とする請求項１から３のいずれかに記載の文書処理装置。
【請求項５】
前記設定部は、前記繰り返し含まれる要素の親要素から選択されたデータを格納したノードへの相対パスと同じ相対パスを有する複数のノードを抽出して、それらのノードに格納されたデータを提示し、提示した複数のデータの中から前記処理モジュールが利用するデータの選択を受け付けることを特徴とする請求項４に記載の文書処理装置。
【請求項６】
前記設定部は、前記文書を解析することにより、前記繰り返し含まれる要素を自動的に抽出することを特徴とする請求項１から５のいずれかに記載の文書処理装置。
【請求項７】
前記編集部は、前記文書中に、前記処理モジュールが利用するデータを指し示すポインタ情報を更に挿入することを特徴とする請求項１から６のいずれかに記載の文書処理装置。
【請求項８】
前記編集部は、前記処理モジュールを起動するための要素又はその子孫の要素に属するノードに、前記ポインタ情報を格納することを特徴とする請求項７に記載の文書処理装置。
【請求項９】
前記設定部は、前記処理モジュールの動作に関するプロパティ情報の設定を受け付け、
前記編集部は、前記プロパティ情報を更に前記処理モジュールを起動するための要素又はその子孫の要素に属するノードに格納することを特徴とする請求項８に記載の文書処理装置。
【請求項１０】
前記編集部は、前記処理モジュールが利用するデータを指し示すポインタ情報を格納したファイルを前記文書とは別に生成することを特徴とする請求項１から６のいずれかに記載の文書処理装置。
【請求項１１】
前記設定部は、前記処理モジュールの動作に関するプロパティ情報の設定を受け付け、
前記編集部は、前記プロパティ情報を更に前記ファイルに格納することを特徴とする請求項１０に記載の文書処理装置。
【請求項１２】
文書中のデータを利用して所定の機能を発現する処理モジュールを起動するための要素を文書に挿入する指示を受け付けたときに、前記処理モジュールが利用する前記文書中のデータを設定するステップと、
前記文書に前記処理モジュールを起動するための要素を挿入するステップと、を備え、
前記設定するステップは、前記文書中に繰り返し含まれる要素を取得し、それらの要素又はそれらの子孫の要素に属するノードの中から、前記処理モジュールが利用するデータを抽出することを特徴とする文書処理方法。
【請求項１３】
文書中のデータを利用して所定の機能を発現する処理モジュールを起動するための要素を文書に挿入する指示を受け付けたときに、前記処理モジュールが利用する前記文書中のデータを設定する機能と、
前記文書に前記処理モジュールを起動するための要素を挿入する機能と、をコンピュータに実現させ、
前記設定する機能は、前記文書中に繰り返し含まれる要素を取得し、それらの要素又はそれらの子孫の要素に属するノードの中から、前記処理モジュールが利用するデータを抽出することを特徴とするプログラム。
【請求項１】
文書中のデータを利用して所定の機能を発現する処理モジュールを起動するための要素を文書に挿入する指示を受け付けたときに、前記処理モジュールが利用する前記文書中のデータを設定する設定部と、
前記文書に前記処理モジュールを起動するための要素を挿入する編集部と、を備え、
前記設定部は、前記文書中に繰り返し含まれる要素を取得し、それらの要素又はそれらの子孫の要素に属するノードの中から、前記処理モジュールが利用するデータを抽出することを特徴とする文書処理装置。
【請求項２】
前記設定部は、テキストデータが格納されているノードの中から、前記処理モジュールが利用するデータを抽出することを特徴とする請求項１に記載の文書処理装置。
【請求項３】
前記設定部は、数値型のテキストデータが格納されているノードの中から、前記処理モジュールが利用するデータを抽出することを特徴とする請求項２に記載の文書処理装置。
【請求項４】
前記設定部は、前記文書中から抽出した前記処理モジュールが利用するデータの候補を提示し、提示した候補の中から前記処理モジュールが利用するデータの選択を受け付けることを特徴とする請求項１から３のいずれかに記載の文書処理装置。
【請求項５】
前記設定部は、前記繰り返し含まれる要素の親要素から選択されたデータを格納したノードへの相対パスと同じ相対パスを有する複数のノードを抽出して、それらのノードに格納されたデータを提示し、提示した複数のデータの中から前記処理モジュールが利用するデータの選択を受け付けることを特徴とする請求項４に記載の文書処理装置。
【請求項６】
前記設定部は、前記文書を解析することにより、前記繰り返し含まれる要素を自動的に抽出することを特徴とする請求項１から５のいずれかに記載の文書処理装置。
【請求項７】
前記編集部は、前記文書中に、前記処理モジュールが利用するデータを指し示すポインタ情報を更に挿入することを特徴とする請求項１から６のいずれかに記載の文書処理装置。
【請求項８】
前記編集部は、前記処理モジュールを起動するための要素又はその子孫の要素に属するノードに、前記ポインタ情報を格納することを特徴とする請求項７に記載の文書処理装置。
【請求項９】
前記設定部は、前記処理モジュールの動作に関するプロパティ情報の設定を受け付け、
前記編集部は、前記プロパティ情報を更に前記処理モジュールを起動するための要素又はその子孫の要素に属するノードに格納することを特徴とする請求項８に記載の文書処理装置。
【請求項１０】
前記編集部は、前記処理モジュールが利用するデータを指し示すポインタ情報を格納したファイルを前記文書とは別に生成することを特徴とする請求項１から６のいずれかに記載の文書処理装置。
【請求項１１】
前記設定部は、前記処理モジュールの動作に関するプロパティ情報の設定を受け付け、
前記編集部は、前記プロパティ情報を更に前記ファイルに格納することを特徴とする請求項１０に記載の文書処理装置。
【請求項１２】
文書中のデータを利用して所定の機能を発現する処理モジュールを起動するための要素を文書に挿入する指示を受け付けたときに、前記処理モジュールが利用する前記文書中のデータを設定するステップと、
前記文書に前記処理モジュールを起動するための要素を挿入するステップと、を備え、
前記設定するステップは、前記文書中に繰り返し含まれる要素を取得し、それらの要素又はそれらの子孫の要素に属するノードの中から、前記処理モジュールが利用するデータを抽出することを特徴とする文書処理方法。
【請求項１３】
文書中のデータを利用して所定の機能を発現する処理モジュールを起動するための要素を文書に挿入する指示を受け付けたときに、前記処理モジュールが利用する前記文書中のデータを設定する機能と、
前記文書に前記処理モジュールを起動するための要素を挿入する機能と、をコンピュータに実現させ、
前記設定する機能は、前記文書中に繰り返し含まれる要素を取得し、それらの要素又はそれらの子孫の要素に属するノードの中から、前記処理モジュールが利用するデータを抽出することを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４（ａ）】
【図４（ｂ）】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１（ａ）】
【図１１（ｂ）】
【図１１（ｃ）】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２（ａ）】
【図４２（ｂ）】
【図３４】
【図３５】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【図２】
【図３】
【図４（ａ）】
【図４（ｂ）】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１（ａ）】
【図１１（ｂ）】
【図１１（ｃ）】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２（ａ）】
【図４２（ｂ）】
【図３４】
【図３５】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【公開番号】特開２００８−２２５９０９（Ｐ２００８−２２５９０９Ａ）
【公開日】平成２０年９月２５日（２００８．９．２５）
【国際特許分類】
【出願番号】特願２００７−６３９６２（Ｐ２００７−６３９６２）
【出願日】平成１９年３月１３日（２００７．３．１３）
【出願人】（３９００２４３５０）株式会社ジャストシステム (123)
【Ｆターム（参考）】
【公開日】平成２０年９月２５日（２００８．９．２５）
【国際特許分類】
【出願日】平成１９年３月１３日（２００７．３．１３）
【出願人】（３９００２４３５０）株式会社ジャストシステム (123)
【Ｆターム（参考）】
[ Back to top ]