(57)【要約】ＤＯＭツリーから変更を伝達する方法である。この方法は、テンプレートにマッチするＤＯＭツリーの部分集合を監視する工程を含む。ＤＯＭツリーの監視された部分集合に変更を加えられる。監視された部分集合における変更を反映するために、ＤＯＭツリーの表現が自動的に更新される。【選択図】図１（ａ）
2008508644.tif 000002
【特許請求の範囲】
【請求項１】
ＤＯＭツリーから変更を伝達する方法であって、
テンプレートにマッチするＤＯＭツリーの部分集合を監視する工程と、
前記ＤＯＭツリーの監視された部分集合に変更を加える工程と、
前記監視された部分集合における変更を反映するために前記ＤＯＭツリーの表現を自動的に更新する工程と、
を備えることを特徴とする方法。
【請求項２】
前記表現は、第２のＤＯＭツリーであることを特徴とする請求項１に記載の方法。
【請求項３】
前記監視する工程は、接続機構によりなされることを特徴とする請求項１に記載の方法。
【請求項４】
ミューテーションイベントリスナーが前記ＤＯＭツリーを注意することを特徴とする請求項１に記載の方法。
【請求項５】
前記ミューテーションイベントは、前記ＤＯＭツリーに変更が生じたときに、ミューテーションイベントを受信することを特徴とする請求項４に記載の方法。
【請求項６】
前記接続機構は、前記ＤＯＭツリーのノードを監視する機能を含むことを特徴とする請求項３に記載の方法。
【請求項７】
前記ミューテーションイベントは、更新が必要な前記表現のノードに更新を送信することを特徴とする請求項５に記載の方法。
【請求項８】
前記ＤＯＭツリーの、監視されるべきそれぞれの部分集合は、前記接続機構において対応するテンプレートを有することを特徴とする請求項１に記載の方法。
【請求項９】
変更を伝達するためのシステムであって、
第１のＤＯＭツリーと、
前記第１のＤＯＭツリーにマップされた表現と、を備え、
前記第１のＤＯＭツリーに対する変更は、前記表現に自動的に伝達されることを特徴とするシステム。
【請求項１０】
前記表現は、第２のＤＯＭツリーであることを特徴とする請求項９に記載のシステム。
【請求項１１】
前記第１のＤＯＭツリーのノードを監視する機能を有する接続機構を更に備えることを特徴とする請求項９に記載のシステム。
【請求項１２】
前記第１のＤＯＭツリーは、ミューテーションイベントリスナーを含むことを特徴とする請求項１１に記載のシステム。
【請求項１３】
前記ミューテーションイベントは、前記第１のＤＯＭツリーに変更が生じたときに、ミューテーションイベントを受信する機能を有することを特徴とする請求項１２に記載のシステム。
【請求項１４】
前記接続機構は、前記第１のＤＯＭツリーのノードを監視する機能を含むことを特徴とする請求項１１に記載のシステム。
【請求項１５】
前記イベントは、更新が必要な前記表現のツリー構造に更新を送信することを特徴とする請求項１２に記載のシステム。
【請求項１６】
前記接続機構は、少なくとも１つのテンプレートを含むことを特徴とする請求項１１に記載のシステム。
【請求項１７】
前記テンプレートは、前記第１のＤＯＭツリーの部分集合にマッチすることが可能であることを特徴とする請求項１６に記載のシステム。
【請求項１８】
前記第１のＤＯＭツリーの、監視されるべきそれぞれの部分集合は、前記接続機構において対応するテンプレートを有することを特徴とする請求項１６に記載のシステム。
【請求項１９】
前記第１のＤＯＭツリーは、ＸＭＬ文書の少なくとも一部を表現することを特徴とする請求項９に記載のシステム。
【請求項２０】
文書のソース表現と、
文書のデスティネーション表現と、を備え、
前記文書の前記ソース表現に対する変更は、前記文書の前記デスティネーション表現に自動的に伝達されることを特徴とする文書管理システム。
【請求項２１】
前記ソース表現は、第１のＤＯＭツリーであることを特徴とする請求項２０に記載のシステム。
【請求項２２】
前記デスティネーション表現は、第２のＤＯＭツリーであることを特徴とする請求項２０に記載のシステム。
【請求項２３】
前記第１のＤＯＭツリーのノードを監視する接続機構を更に備えることを特徴とする請求項２１に記載のシステム。
【請求項２４】
前記第１のＤＯＭツリーは、ミューテーションイベントリスナーを含むことを特徴とする請求項２２に記載のシステム。
【請求項２５】
前記ミューテーションイベントリスナーは、前記第１のＤＯＭツリーに変更が生じたときに、ミューテーションイベントを受信することを特徴とする請求項２４に記載のシステム。
【請求項２６】
前記接続機構は、前記第１のＤＯＭツリーのノードを監視する機能を含むことを特徴とする請求項２２に記載のシステム。
【請求項２７】
前記ミューテーションイベントは、更新が必要な前記第２の表現のノードに更新を送信することを特徴とする請求項２４に記載のシステム。
【請求項２８】
前記接続機構は、少なくとも１つのテンプレートを含むことを特徴とする請求項２２に記載のシステム。
【請求項２９】
前記テンプレートは、前記第１のＤＯＭツリーの部分集合にマッチすることが可能であることを特徴とする請求項２８に記載のシステム。
【請求項３０】
前記第１のノードの、監視されるべきそれぞれの部分集合は、前記接続機構において対応するテンプレートを有することを特徴とする請求項２０に記載のシステム。
【請求項３１】
前記第１のＤＯＭツリーは、ＸＭＬ文書の少なくとも一部を表現することを特徴とする請求項２０に記載のシステム。
【請求項３１】
文書中の変更を伝達する方法をコンピュータに実現させるための命令を備えるコンピュータ読み取り可能な記録媒体を含むコンピュータプログラム製品であって、
前記文書の少なくとも一部のソース表現を生成する命令と、
前記ソース表現に対応するデスティネーション表現を生成する命令と
前記文書の前記ソース表現に対する変更を監視する命令と、
前記文書の前記ソース表現に変更を加える命令と、
前記文書の前記デスティネーション表現に前記変更を自動的に伝達する命令と、
を備えることを特徴とするコンピュータプログラム製品。
【請求項３２】
前記ソース表現は、第１のＤＯＭツリーであることを特徴とする請求項３１に記載のコンピュータプログラム製品。
【請求項３３】
前記デスティネーション表現は、第２のＤＯＭツリーであることを特徴とする請求項３１に記載のコンピュータプログラム製品。
【請求項３４】
前記監視する命令は、接続機構によりなされることを特徴とする請求項３１に記載のコンピュータプログラム製品。
【請求項３５】
ミューテーションイベントリスナーが前記第１のＤＯＭツリーを注意することを特徴とする請求項３１に記載のコンピュータプログラム製品。
【請求項３６】
前記ミューテーションイベントリスナーは、前記第１のＤＯＭツリーに変更が生じたときに、ミューテーションイベントを受信することを特徴とする請求項３５に記載のコンピュータプログラム製品。
【請求項３７】
前記接続機構は、前記第１のＤＯＭツリーのノードを監視する機能を含むことを特徴とする請求項３４に記載のコンピュータプログラム製品。
【請求項３８】
前記ミューテーションイベントは、更新が必要な前記第２の表現のノードに更新を送信することを特徴とする請求項３６に記載のコンピュータプログラム製品。
【請求項３９】
前記第１のノードの、監視されるべきそれぞれの部分集合は、前記接続機構において対応するテンプレートを有することを特徴とする請求項３１に記載のコンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】  本開示は、情報のある形式の表現における変更を、同じ情報の別の形式の表現に自動的に伝達する技術を開示する。とくに、本技術は、ソースＤＯＭツリーにより表現された文書に対する変更を、別の表現に描写されたデスティネーションＤＯＭツリーへ自動的に伝達することに関する。
【背景技術】
【０００２】  この出願は、「文書処理及び文書管理システム」という名称で、２００４年８月２日に出願され、同時継続している米国仮出願（出願番号６０／５９２，３６９）からの優先権を主張する。【０００３】  インターネットの出現により、ユーザによって処理され管理される文書の数が、ほぼ指数関数的に増加してきた。インターネットの核を形成するウェブ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）は、そのような文書データの大きな受け皿となっている。ウェブは、文書に加えて、このような文書の情報検索システムを提供する。これらの文書は、通常、マークアップ言語により記述される。マークアップ言語のシンプルかつポピュラーな例の一つにＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）がある。このような文書は、ウェブの他の位置に格納されている他の文書へのリンクをさらに含む。ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）は、さらに高度でポピュラーなマークアップ言語である。ウェブ文書にアクセスし、閲覧するためのシンプルなブラウザが、Ｊａｖａ（登録商標）のようなオブジェクト指向のプログラミング言語で開発されている。【０００４】  マークアップ言語により記述された文書は、通常、ブラウザや他のアプリケーションの中では、ツリーデータ構造の形で表現される。この構造は、文書を構文解析した結果のツリーに相当する。ＤＯＭ（Ｄｏｃｕｍｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ）は、文書を表現し、操作するために使用される、よく知られたツリーベースのデータ構造モデルである。ＤＯＭは、ＨＴＭＬやＸＭＬ文書などを含む文書を表現するための標準的なオブジェクトのセットを提供する。ＤＯＭは、文書内のコンポーネントを表現するオブジェクトがどのようにつながっているかという標準モデルと、それらのオブジェクトにアクセスしたり操作したりするための標準インタフェイスという、２つの基本的なコンポーネントを含む。【０００５】  アプリケーション開発者は、独自のデータ構造やＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）へのインタフェイスとしてＤＯＭをサポートすることができる。他方、文書を作成するアプリケーション開発者は、彼らのＡＰＩの独自インタフェイスではなく、ＤＯＭの標準インタフェイスを使用することができる。したがって、標準を提供するというその能力により、ＤＯＭは、様々な環境、特にウェブにおいて、文書の相互利用を促進させるために有効である。ＤＯＭのいくつかのバージョンが定義されており、異なるプログラミング環境及びアプリケーションによって使用されている。【０００６】  ＤＯＭツリーは、対応するＤＯＭの内容に基づいた文書の階層的表現である。ＤＯＭツリーは「根（ルート）」、及びルートから発生する１つ以上の「節（ノード）」を含む。ルートが文書全体を表す場合もある。中間のノードは、例えば、テーブル及びそのテーブル中の行及び列のような要素を表すことができる。ＤＯＭツリーの「葉」は、通常、それ以上分解できないテキストや画像のようなデータを表す。ＤＯＭツリーの各ノードは、フォント、サイズ、色、インデントなど、ノードによって表される要素のパラメータを記述する属性に関連付けられてもよい。【０００７】  ＨＴＭＬは、文書を作成するために一般に用いられる言語であるが、フォーマット及びレイアウト用の言語であり、データ記述のための言語ではない。ＨＴＭＬドキュメントを表現するＤＯＭツリーのノードは、ＨＴＭＬのフォーマッティングタグとして予め定義されたエレメントであって、通常、ＨＴＭＬは、データの詳述や、データのタギング／ラベリングのための機能を提供しないので、ＨＴＭＬドキュメント中のデータに対するクエリを定式化することは多くの場合困難である。【０００８】  ネットワーク設計者たちの目指すものは、ウェブ上の文書がソフトウェアアプリケーションによってクエリされたり処理されたりできるようにすることである。表示方法とは無関係で、階層的に構造化された言語であれば、そのようにクエリされ処理されることができる。ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）のようなマークアップ言語は、これらの機能を提供することができる。【０００９】  ＨＴＭＬとは逆に、ＸＭＬのよく知られた利点は、文書の設計者が自由に定義可能な「タグ」を使用して、データ要素にラベルを付けることが可能である点である。このようなデータ要素は、階層的に構造化することができる。さらに、ＸＭＬ文書は、文書内で用いられるタグ及びそれらの相互関係の「文法」を記述した文書型定義を含むことができる。構造化されたＸＭＬ文書の表示方法を定義するために、ＣＳＳ（Ｃａｓｃａｄｉｎｇ  Ｓｔｙｌｅ  Ｓｈｅｅｔ）又はＸＳＬ（ＸＭＬ  Ｓｔｙｌｅ  Ｌａｎｇｕａｇｅ）が使用される。ＤＯＭ、ＨＴＭＬ、ＸＭＬ、ＣＳＳ、ＸＳＬ及び関連する言語の特徴に関する付加的な情報は、ウェブからも得ることができる。（例えば、ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／）【００１０】  Ｘｐａｔｈは、ＸＭＬ文書の部分の位置を指定するために共通のシンタックス及びセマンティクスを提供する。機能性の例として、ＸＭＬ文書に対応するＤＯＭツリーのトラバース（移動）がある。それは、ＸＭＬ文書の様々な表現に関連した文字列、数、及びブーリアン文字の操作のための基本的な機能を提供する。Ｘｐａｔｈは、ＸＭＬ文書の見た目のシンタックス、例えば、テキストとしてみたときに何行目であるとか何文字目であるとかといった文法ではなく、ＤＯＭツリーなどの抽象的・論理的な構造において動作する。Ｘｐａｔｈを使用することにより、例えばＸＭＬ文書のＤＯＭツリー内の階層的構造を通じて場所を指定することができる。アドレシングのための使用の他に、Ｘｐａｔｈは、ＤＯＭツリー中のノードがパターンにマッチするか否かをテストするために使用されるようにも設計されている。【００１１】  ＸＰａｔｈに関する更なる詳細は、ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｘｐａｔｈで得ることができる。【００１２】  ＸＭＬの既知の利点及び特徴により、マークアップ言語（例えばＸＭＬ）で記述された文書を扱うことができ、文書を作成及び修正するためのユーザフレンドリーなインタフェイスを提供することができる、効果的な文書処理システムが求められる。【００１３】  ＸＭＬは、複雑な文書のための、またネットワークなどを介して複数のドキュメントにまたがってデータを共有す���のに特に適した形式である。ＸＭＬ文書を作成、表示、編集するための多くのアプリケーションが開発されている（たとえば、特許文献１参照）。
【特許文献１】特開２００１−２９０８０４号公報
【発明の開示】
【発明が解決しようとする課題】
【００１４】  ボキャブラリは、任意に定義することが許されており、理論上、無限に多くのボキャブラリが存在しうる。これらのボキャブラリの全てに対応して専用の表示・編集環境を提供するのは現実的ではない。従来、専用の編集環境が用意されていないボキャブラリにより記述された文書を編集する場合、テキストデータにより構成された文書のソースを直接テキストエディタなどで編集していた。【００１５】  既存のアプリケーションは、処理・管理できるＸＭＬ文書に大きな制限があったため、幅広く文書を受け入れることができなかった。例えばＸＭＬ文書処理システムの中には、ＸＭＬ文書の中で、文書の内容を表し、表示メソッドとは関係ない文字列を表示することができるものがある。この機能は一見優れているようであるが、実際にはユーザがＸＭＬ文書を直接編集できないという不都合な点も持つ。この問題を解決するために、ＸＭＬ文書処理システムの中には、ＸＭＬの入力を受け付ける画面を特別にデザインするものもある。しかし、画面デザインの柔軟性は限られていた。それらのＸＭＬ文書処理システムにおいては、前述の画面デザインは事前にハードコーディングされている必要があったからである。【００１６】  この制限を考慮して、ＸＳＬＴは標準的なスタイルシート言語の一つとして開発された。このような技術によりユーザはハードコーディングから解放され、ＸＭＬ文書を表示するために適用されるメソッドとも混在可能になった。しかし、ＸＳＬＴを使用しても、特定の形式のＸＭＬ文書の編集はできない場合があった。【００１７】  さらに、それらのＸＭＬ文書処理システムは、「スキーマ」に定義された順序をあてにしている。そのため、一旦スキーマが決定されると、処理システムで処理可能なのは、そのスキーマの構造に最上位から合致するＸＭＬ文書のみであった。換言すると、それらのシステムは過度に制限的で柔軟性を欠いている。
【課題を解決するための手段】
【００１８】  今回開示するシステムは、前述のような制限が無い。完全なＸＭＬ文書の構造は固定的に決定される必要はない。様々な構造が複合したＸＭＬ文書であっても、ＸＭＬ文書をより小さな部分に分割して安全に処理できる。それぞれの小さい部分は、より柔軟性を高めるため、個別に編集モジュールに振り分けられる。加えて、編集モジュールは、プラグインとして提供されるのが望ましい。さらにユーザは、何らのハードコーディングをすることなく柔軟性のある画面デザインを実装できる。いわゆるＷＹＳＩＷＹＧ（Ｗｈａｔ  Ｙｏｕ  Ｓｅｅ  Ｉｓ  Ｗｈａｔ  Ｙｏｕ  Ｇｅｔ）を実現できる。【００１９】  ここで説明されるシステムの構成のうちのいくつかは、ＭＶＣ（Ｍｏｄｅｌ−Ｖｉｅｗ−Ｃｏｎｔｒｏｌｌｅｒ）と呼ばれる、よく知られたＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）パラダイムを用いて説明される。ＭＶＣパラダイムは、アプリケーション又はアプリケーションのインタフェイスの一部を、３つの部分、すなわち、モデル、ビュー、コントローラに分割する。ＭＶＣは、元は、ＧＵＩの世界に、従来の入力、処理、出力の役割を割り当てるために開発された。【００２０】        ［入力］        →      ［処理］        →      ［出力］【００２１】        ［コントローラ］→      ［モデル］      →      ［ビュー］【００２２】  ＭＶＣパラダイムによれば、外界のモデリング、ユーザへの視覚的なフィードバック、及びユーザの入力は、モデル（Ｍ）、ビュー（Ｖ）、及びコントローラ（Ｃ）オブジェクトにより分離されて扱われる。コントローラは、ユーザからのマウスとキーボード入力のような入力を解釈し、これらのユーザアクションを、適切な変更をもたらすためにモデル及び／又はビューに送られるコマンドにマップするように作用する。モデルは、１以上のデータ要素を管理するように作用し、その状態に関するクエリに応答し、状態を変更する指示に応答する。ビューは、ディスプレイの長方形の領域を管理するように作用し、グラフィクスとテキストの組合せによりユーザにデータを提示する機能を有する。【００２３】  同じ情報が２つの異なる形式で同時に表現されることがある。このような場合、第１の表現における変更が、第２の表現へ自動的に伝達されることが望ましい。【００２４】  上述した望ましい特徴のいくつかを実現するために、ＤＯＭツリーから変更を伝達する方法が提供される。この方法は、テンプレートにマッチするＤＯＭツリーの部分集合を監視する工程を含む。ＤＯＭツリーの監視された部分集合に変更を加えられる。監視された部分集合における変更を反映するために、ＤＯＭツリーの表現が自動的に更新される。【００２５】  開示される教示の別の態様は、変更を伝達するためのシステムである。このシステムは、第１のＤＯＭツリーを備える。表現は、第１のＤＯＭツリーにマップされる。第１のＤＯＭツリーに対する変更は、表現に自動的に伝達される。【００２６】  開示される教示の更に別の態様は、文書のソース表現を備える文書管理システムである。文書のデスティネーション表現が設けられる。文書のソース表現に対する変更は、文書のデスティネーション表現に自動的に伝達される。【００２７】  開示さ��る教示の更に別の態様は、この開示の中で説明した技術をコンピュータに実現させるための命令を備えたコンピュータ読み取り可能な記録媒体である。
【発明を実施するための最良の形態】
【００２８】  以下、添付の図面を参照して、発明の典型的な実施例を詳細に記述する。【００２９】  本発明の境界と範囲を定めるのは請求の範囲のみである。説明する実施の形態や実施例、効果は単なる例示であり、本発明を制限するものと考えてはならない。本発明の詳細な説明は説明を意図しており、請求の範囲を制限するものではない。当業者には多くの代替例、改造例や変形例が理解される。【００３０】Ａ．文書処理システムの全体構成
図１（ａ）は、後述するタイプの文書処理システムの基礎として機能する要素の標準的な構成例を示す。構成１０は、通信経路によりメモリ１２に接続されたＣＰＵ又はマイクロプロセッサ１１などの形式のプロセッサを含む。メモリ１２は、現在又は将来に利用可能な任意のＲＯＭ及び／又はＲＡＭの形式であってもよい。通信経路は、典型的にはバスとして設けられる。マウス、キーボード、音声認識システムなどのユーザ入力装置１４及び表示装置１５（又は他のユーザインタフェイス）に対する入出力インタフェイス１６も、プロセッサ１１とメモリ１２の通信のためのバスに接続される。この構成は、スタンドアロンであってもよいし、複数の端末及び１以上のサーバが接続されてネットワーク化された形式であってもよいし、既知のいかなる方式により構成されてもよい。本発明は、これらのコンポーネントの配置、集中又は分散されたアーキテクチャー、あるいは様々なコンポーネントの通信方法により制限されない。【００３１】  さらに、本システム及びここで議論される実施例は、様々な機能性を提供するいくつかのコンポーネント及びサブコンポーネントを含むものとして議論される。これらのコンポーネント及びサブコンポーネントは、注目された機能性を提供するために、ハードウェアとソフトウェアの組合せだけでなく、ハードウェアのみ、ソフトウェアのみによっても実現されうる。さらに、ハードウェア、ソフトウェア、及びそれらの組合せは、汎用の計算装置、専用のハードウェア、又はそれらの組合せにより実現されうる。したがって、コンポーネント又はサブコンポーネントの構成は、コンポーネント又はサブコンポーネントの機能性を提供するための特定のソフトウェアを実行する汎用／専用の計算装置を含む。【００３２】  図１（ｂ）は、文書処理システムの一例の全体のブロック図を示す。このような文書処理システムにおいて文書が生成され編集される。これらの文書は、例えばＸＭＬなど、マークアップ言語の特徴を有する任意の言語により記述されてもよい。また、便宜上、特定のコンポーネント及びサブコンポーネントの用語及び表題を創造した。しかしながら、これらは、この開示の一般的な教示の範囲を制限するために解釈されるべきではない。【００３３】  文書処理システムは、２つの基本的な構成を有するものととらえることができる。第１の構成は、文書処理システムが動作する環境である「実行環境」１０１である。例えば、実行環境は、文書の処理中及び管理中に、ユーザだけでなくシステムも支援する、基本的なユーティリティ及び機能を提供する。第２の構成は、図１（ｃ）に示す、実行環境において走るアプリケーションから構成される「アプリケーション」１０２である。これらのアプリケーションは、文書自身及び文書の様々な表現を含む。【００３４】  １．実行環境
実行環境１０１のキーとなるコンポーネントはＰｒｏｇｒａｍＩｎｖｏｋｅｒ（プログラムインボーカ：プログラム起動部）１０３である。ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３は、文書処理システムを起動するためにアクセスされる基本的なプログラムである。例えば、ユーザが文書処理システムにログオンして開始するとき、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３が実行される。ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３は、例えば、文書処理システムにプラグインとして加えられた機能を読み出して実行させたり、アプリケーションを開始して実行させたり、文書に関連するプロパティを読み出すことができる。ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３の機能はこれらに限定されない。ユーザが実行環境内で実行されるように意図されたアプリケーションを起動したいとき、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３は、そのアプリケーションを見つけ、それを起動して、アプリケーションを実行する。例えばユーザが文書（実行環境ではアプリケーションとして扱われる）を編集したいときには、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３は最初にその文書を発見し、文書を展開し、編集するために必要な機能を実行する。【００３５】  ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３には、プラグインサブシステム１０４、コマンドサブシステム１０５、及びＲｅｓｏｕｒｃｅ（リソース）モジュール１０９などのいくつかのコンポーネントがアタッチされている。これらの構成については、以下に詳述する。【００３６】    ａ）プラグインサブシステム
プラグインサブシステム１０４は、文書処理システムに機能を追加するための高度に柔軟で効率的な構成として使用される。プラグインサブシステム１０４は、また、文書処理システムに存在する機能を修正又は削除するために使用することができる。さらに、種々様々の機能をプラグインサブシステムを使用して追加又は修正することができる。例えば、画面上への文書の描画を支援するように作用するＥｄｉｔｌｅｔ（エディットレット：編集部）機能を追加することもできる。Ｅｄｉｔｌｅｔプラグインは、システムに追加されるボキャブラリの編集も支援する。【００３７】  プラグインサブシステム１０４は、ＳｅｒｖｉｃｅＢｒｏｋｅｒ（サービスブローカ：サービス仲介部）１０４１を含む。ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１は、文書処理システムに加えられるプラグインを管理することにより、文書処理システムに加えられるサービスを仲介する。【００３８】  所望の機能性を実現する個々の機能は、Ｓｅｒｖｉｃｅ（サービス）１０４２の形でシステムに追加される。利用可能なＳｅｒｖｉｃｅ１０４２のタイプは、Ａｐｐｌｉｃａｔｉｏｎ（アプリケーション）Ｓｅｒｖｉｃｅ、ＺｏｎｅＦａｃｔｏｒｙ（ゾーンファクトリ：ゾーン生成部）Ｓｅｒｖｉｃｅ、Ｅｄｉｔｌｅｔ（エディットレット：編集部）Ｓｅｒｖｉｃｅ、ＣｏｍｍａｎｄＦａｃｔｏｒｙ（コマンドファクトリ：コマンド生成部）Ｓｅｒｖｉｃｅ、ＣｏｎｎｅｃｔＸＰａｔｈ（コネクトＸＰａｔｈ：ＸＰａｔｈ管理部）Ｓｅｒｖｉｃｅ、ＣＳＳＣｏｍｐｕｔａｔｉｏｎ（ＣＳＳコンピューテーション：ＣＳＳ計算部）Ｓｅｒｖｉｃｅなどを含むが、これらに限定されない。これらのＳｅｒｖｉｃｅ、及びシステムの他の構成とそれらとの関係は、文書処理システムについてのよりよい理解のために、以下に詳述される。【００３９】  プラグインとＳｅｒｖｉｃｅの関係は以下の通りである。プラグインは、１以上のＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒ（サービスプロバイダ：サービス提供部）を含むことができるユニットである。それぞれのＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒは、それに関連したＳｅｒｖｉｃｅの１以上のクラスを有する。例えば、適切なソフトウェアアプリケーションを有する単一のプラグインを使用することにより、１以上のＳｅｒｖｉｃｅをシステムに追加することができ、これにより、対応する機能をシステムに追加することができる。【００４０】    ｂ）コマンドサブシステム
コマンドサブシステム１０５は、文書の処理に関連したコマンドの形式の命令を実行するために使用される。ユーザは、一連の命令を実行することにより、文書に対する操作を実行することができる。例えば、ユーザは、コマンドの形で命令を発行することにより、文書処理システム中のＸＭＬ文書に対応するＸＭＬのＤＯＭツリーを編集し、ＸＭＬ文書を処理する。これらのコマンドは、キーストローク、マウスクリック、又は他の有効なユーザインタフェイスアクションを使用して入力されてもよい。１つのコマンドにより１以上の命令が実行されることもある。この場合、これらの命令が１つのコマンドにラップ（包含）され、連続して実行される。例えば、ユーザが、誤った単語を正しい単語に置換したいとする。この場合、第１の命令は、文書中の誤った単語を発見することであり、第２の命令は、誤った単語を削除することであり、第３の命令は、正しい単語を挿入することであってもよい。これらの３つの命令が１つのコマンドにラップされてもよい。【００４１】  コマンドは、関連した機能、例えば、後で詳述する「アンドゥ」機能を有してもよい。これらの機能は、オブジェクトを生成するために使用されるいくつかの基本クラスにも割り当てられてもよい。【００４２】  コマンドサブシステム１０５のキーとなるコンポーネントは、選択的にコマンドを与え、実行するように作用するＣｏｍｍａｎｄＩｎｖｏｋｅｒ（コマンドインボーカ：コマンド起動部）１０５１である。図１（ｂ）には、１つのＣｏｍｍａｎｄＩｎｖｏｋｅｒのみが示されているが、１以上のＣｏｍｍａｎｄＩｎｖｏｋｅｒが使用されてもよく、１以上のコマンドが同時に実行されてもよい。ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１は、コマンドを実行するために必要な機能及びクラスを保持する。動作において、実行されるべきＣｏｍｍａｎｄ（コマンド：命令）１０５２は、Ｑｕｅｕｅ（キュー）１０５３に積まれる。ＣｏｍｍａｎｄＩｎｖｏｋｅｒは、連続的に実行するコマンドスレッドを生成する。ＣｏｍｍａｎｄＩｎｖｏｋｅｒ内で既に実行中のＣｏｍｍａｎｄがなければ、ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１により実行されるように意図されたＣｏｍｍａｎｄ１０５２が実行される。ＣｏｍｍａｎｄＩｎｖｏｋｅｒが既にコマンドを実行している場合、新しいＣｏｍｍａｎｄは、Ｑｕｅｕｅ１０５３の最後に積まれる。しかしながら、それぞれのＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１では、一度に１つのＣｏｍｍａｎｄのみが実行される。指定されたＣｏｍｍａｎｄの実行に失敗した場合、ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１は例外処理を実行する。【００４３】  ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１により実行されるＣｏｍｍａｎｄの型は、ＵｎｄｏａｂｌｅＣｏｍｍａｎｄ（取消可能コマンド）１０５４、ＡｓｙｎｃｈｒｏｎｏｕｓＣｏｍｍａｎｄ（非同期コマンド）１０５５、及びＶＣＣｏｍｍａｎｄ（ＶＣコマンド）１０５６を含むが、これらに限定されない。ＵｎｄｏａｂｌｅＣｏｍｍａｎｄ１０５４は、ユーザが望めば、そのＣｏｍｍａｎｄの結果を取り消すことが可能なＣｏｍｍａｎｄである。ＵｎｄｏａｂｌｅＣｏｍｍａｎｄの例として、切り取り、コピー、テキストの挿入、などがある。動作において、ユーザが文書の一部を選択し、その部分に切り取りコマンドを適用するとき、ＵｎｄｏａｂｌｅＣｏｍｍａｎｄを用いることにより、切り取られた部分は、必要であれば、「切り取られていない」ようにすることができる。【００４４】  ＶＣＣｏｍｍａｎｄ１０５６は、ボキャブラリコネクション記述子（Ｖｏｃａｂｕｌａｒｙ  Ｃｏｎｎｅｃｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒ：ＶＣＤ）スクリプトファイルに格納される。これらは、プログラマにより定義されうるユーザ指定のＣｏｍｍａｎｄである。Ｃｏｍｍａｎｄは、例えば、ＸＭＬフラグメントを追加したり、ＸＭＬフラグメントを削除したり、属性を設定したりするための、より抽象的なＣｏｍｍａｎｄの組合せであってもよい。これらのＣｏｍｍａｎｄは、特に、文書の編集に焦点を合わせている。【００４５】  ＡｓｙｎｃｈｒｏｎｏｕｓＣｏｍｍａｎｄ１０５５は、文書のロードや保存など、システムよりのＣｏｍｍａｎｄであり、ＵｎｄｏａｂｌｅＣｏｍｍａｎｄやＶＣＣｏｍｍａｎｄとは別に、非同期的に実行される。ＡｓｙｎｃｈｒｏｎｏｕｓＣｏｍｍａｎｄは、ＵｎｄｏａｂｌｅＣｏｍｍａｎｄではないので、取り消すことはできない。【００４６】  ＡｓｙｎｃｈｒｏｎｏｕｓＣｏｍｍａｎｄｓ１０５５は、ボキャブラリコネクションの下位のレベルに存在する。それらは文書処理システムに対するより特別なコマンドである。ＡｓｙｎｃｈｒｏｎｏｕｓＣｏｍｍａｎｄｓはＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１に直接届けられる。一方で、ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎＣｏｍｍａｎｄｓ１０５６は解釈され、ＡｓｙｎｃｈｒｏｎｏｕｓＣｏｍｍａｎｄｓに変換されたのち、ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１に届けられる。【００４７】    ｃ）リソース
Ｒｅｓｏｕｒｃｅ１０９は、様々なクラスに、いくつかの機能を提供するオブジェクトである。例えば、ストリングリソース、アイコン、及びデフォルトキーバインドは、システムで使用されるＲｅｓｏｕｒｃｅの例である。【００４８】  ２．アプリケーションコンポーネント
文書処理システムの第２の主要な特徴であるアプリケーションコンポーネント１０２は、実行環境１０１において実行される。アプリケーションコンポーネント１０２は、実際の文書と、システム内における文書の様々な論理的、物理的な表現を含む。さらに、アプリケーションコンポーネント１０２は、文書を管理するために使用されるシステムの構成を含む。アプリケーションコンポーネント１０２は、さらに、ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ（ユーザアプリケーション）１０６、アプリケーションコア１０８、ユーザインタフェイス１０７、及びＣｏｒｅＣｏｍｐｏｎｅｎｔ（コアコンポーネント）１１０を含む。【００４９】    ａ）ユーザアプリケーション
ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６は、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３と共にシステム上にロードされる。ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６は、文書と、文書の様々な表現と、文書と対話するために必要なユーザインタフェイスとをつなぐ接着剤となる。例えば、ユーザが、プロジェクトの一部である文書のセットを生成したいとする。これらの文書がロードされると、文書の適切な表現が生成される。ユーザインタフェイス機能は、ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６の一部として追加される。言いかえれば、ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６は、ユーザがプロジェクトの一部を形成する文書と対話することを可能とする文書の表現と、文書の様々な態様とを、共に保持する。一旦ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６が生成されると、ユーザがプロジェクトの一部を形成する文書との対話を望むたびに、ユーザは簡単に実行環境上にＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６をロードすることができる。【００５０】    ｂ）コアコンポーネント
ＣｏｒｅＣｏｍｐｏｎｅｎｔ１１０は、複数のＰａｎｅ（ペイン）の間で文書を共有する方法を提供する。後で詳述するように、Ｐａｎｅは、ＤＯＭツリーを表示し、画面の物理的なレイアウトを扱う。例えば、物理的な画面は、個々の情報の断片を描写する画面内の複数のＰａｎｅからなる。ユーザから画面上に見える文書は、１又はそれ以上のＰａｎｅに出現しうる。また、２つの異なる文書が画面上で２つの異なるＰａｎｅに現れてもよい。【００５１】  図１（ｃ）に示されるように、画面の物理的なレイアウトもツリーの形式になっている。Ｐａｎｅは、ＲｏｏｔＰａｎｅ（ルートペイン）１０８４にもなり得るし、ＳｕｂＰａｎｅ（サブペイン）１０８５にもなり得る。ＲｏｏｔＰａｎｅ１０８４は、Ｐａｎｅのツリーの根に当たるＰａｎｅであり、ＳｕｂＰａｎｅ１０８５は、ＲｏｏｔＰａｎｅ１０８４以外の任意のＰａｎｅである。【００５２】  ＣｏｒｅＣｏｍｐｏｎｅｎｔ１１０は、さらに、フォントを提供し、ツールキットなど、文書のための複数の機能的な操作のソースの役割を果たす。ＣｏｒｅＣｏｍｐｏｎｅｎｔ１１０により実行されるタスクの一例に、複数のＰａｎｅ間におけるマウスカーソルの移動がある。実行されるタスクの他の例として、あるＰａｎｅ中の文書の一部をマークし、それを異なる文書を含む別のＰａｎｅ上にコピーする。【００５３】  ｃ）アプリケーションコア
上述したように、アプリケーションコンポーネント１０２は、システムにより処理され管理される文書から構成される。これは、システム内における文書の様々な論理的及び物理的な表現を含む。アプリケーションコア１０８は、アプリケーションコンポーネント１０２の構成である。その機能は、実際の文書を、それに含まれる全てのデータとともに保持することである。アプリケーションコア１０８は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ（ドキュメントマネージャ：文書管理部）１０８１及びＤｏｃｕｍｅｎｔ（ドキュメント：文書）１０８２自身を含む。【００５４】  ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１の様々な態様を以下に詳述する。ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１は、Ｄｏｃｕｍｅｎｔ１０８２を管理する。ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１は、ＲｏｏｔＰａｎｅ１０８４、ＳｕｂＰａｎｅ１０８５、ＣｌｉｐＢｏａｒｄ（クリップボード）ユーティリティ１０８６、及びＳｎａｐＳｈｏｔ（スナップショット）ユーティリティ１０８７にも接続される。ＣｌｉｐＢｏａｒｄユーティリティ１０８６は、ユーザがクリップボードに加えることを決定した文書の部分を保持する方法を提供する。例えば、ユーザが、文書の一部を切り取り、後で再考するために新規文書にそれを保存することを望んだとする。このような場合、切り取られた部分がＣｌｉｐＢｏａｒｄに追加される。【００５５】  つづいて、ＳｎａｐＳｈｏｔユーティリティ１０８７についても説明する。ＳｎａｐＳｈｏｔユーティリティ１０８７は、アプリケーションがある状態から別の状態まで移行するときに、アプリケーションの現在の状態を記憶することを可能とする。【００５６】  ｄ）ユーザインタフェイス
アプリケーションコンポーネント１０２の別の構成は、ユーザがシステムと物理的に対話する手段を提供するユーザインタフェイス１０７である。例えば、ユーザインタフェイスは、ユーザが文書をアップロードしたり、削除したり、編集したり、管理したりするために使用される。ユーザインタフェイスは、Ｆｒａｍｅ（フレーム）１０７１、ＭｅｎｕＢａｒ（メニューバー）１０７２、ＳｔａｔｕｓＢａｒ（ステータスバー）１０７３、及びＵＲＬＢａｒ（ＵＲＬバー）１０７４を含む。【００５７】  Ｆｒａｍｅ１０７１は、一般に知られているように、物理的な画面のアクティブな領域であると考えてもよい。ＭｅｎｕＢａｒ１０７２は、ユーザに選択を提供するメニューを含む画面領域である。ＳｔａｔｕｓＢａｒ１０７３は、アプリケーションの実行状態を表示する画面領域である。ＵＲＬＢａｒ１０７４は、インターネットをナビゲートするためにＵＲＬアドレスを入力する領域を提供する。【００５８】Ｂ．文書管理及び関連するデータ構造
図２は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１の詳細を示す。これは、文書処理システム内で文書を表現するために用いられるデータ構造及び構成を含む。分かりやすくするために、このサブセクションで説明される構成は、ＭＶＣパラダイムを用いて説明される。【００５９】  ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１は、文書処理システム内にある全ての文書を保持しホストするＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ（ドキュメントコンテナ：文書コンテナ）２０３を含む。ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１にアタッチされたツールキット２０１は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１により使用される様々なツールを提供する。例えば、ＤｏｍＳｅｒｖｉｃｅ（ＤＯＭサービス）は、文書に対応するＤＯＭを生成し、保持し、管理するために必要とされる全ての機能を提供するために、ツールキット２０１により提供されるツールである。ツールキット２０１により提供される別のツールであるＩＯＭａｎａｇｅｒ（入出力管理部）は、システムへの入力及びシステムからの出力を管理する。同様に、ＳｔｒｅａｍＨａｎｄｌｅｒ（ストリームハンドラ）は、ビットストリームによる文書のアップロードを扱うツールである。これらのツールは、図中に特に示さず、参照番号を割り当てないが、ツールキット２０１のコンポーネントを形成する。【００６０】  ＭＶＣパラダイムの表現によれば、モデル（Ｍ）は、文書のＤＯＭツリーモデル２０２を含む。前述したように、全ての文書は、文書処理システムにおいてＤＯＭツリーとして表現される。文書は、また、ＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ２０３の一部を形成する。【００６１】  １．ＤＯＭモデル及びゾーン
ＤＯＭはＷ３Ｃが策定した標準規格であり、Ｎｏｄｅを操作するための標準的なインタフェイスを定義するが、実際には、ボキャブラリごと又はＮｏｄｅごとに特有の操作があるので、これらの操作をＡＰＩとして用意しておくのが好都合である。文書処理システムでは、このような各Ｎｏｄｅに特有のＡＰＩをＦａｃｅｔとして用意し、各Ｎｏｄｅにアタッチする。これにより、ＤＯＭの標準規格に準拠しつつ、有用なＡＰＩを付加することができる。また、ボキャブラリごとに特有のＤＯＭを実装するのではなく、標準的なＤＯＭの実装に、後から特有のＡＰＩを付加するようにすることで、多様なボキャブラリを統一的に処理することができるともに、複数のボキャブラリが任意の組合せで混在した文書を適切に処理することができる。標準的にはＤＯＭはＤＯＭツリー形式で表現される。【００６２】  文書を表現するＤＯＭツリーは、Ｎｏｄｅ（ノード）２０２１を有するツリーである。ＤＯＭツリーの部分集合であるＺｏｎｅ（ゾーン）２０９は、ＤＯＭツリー内の１以上のＮｏｄｅの関連領域を含む。例えば、画面上で文書の一部のみを表示し得るが、この可視化された文書の一部はＺｏｎｅ２０９を用いて表示される。Ｚｏｎｅは、ＺｏｎｅＦａｃｔｏｒｙ（ゾーンファクトリ：ゾーン生成部）２０５と呼ばれるプラグインを用いて、生成され、取り扱われ、処理される。ＺｏｎｅはＤＯＭの一部を表現するが、１以上の「名前空間」を使用してもよい。よく知られているように、名前空間は、名前空間内でユニークな名前の集合である。換言すれば、名前空間内に同じ名前は存在しない。【００６３】  ２．Ｆａｃｅｔ及びＦａｃｅｔとＺｏｎｅとの関係
Ｆａｃｅｔ（ファセット）２０２２は、ＭＶＣパラダイムのモデル（Ｍ）部分内の別の構成である。Ｆａｃｅｔは、ＺｏｎｅにおいてＮｏｄｅを編集するために使用される。Ｆａｃｅｔ２０２２は、Ｚｏｎｅ自身の内容に影響を与えずに実行することができる手続（プロシージャ）を使用して、ＤＯＭへのアクセスを編成する。次に説明するように、これらの手続は、Ｎｏｄｅに関連した重要で有用な操作を実行する。【００６４】  各Ｎｏｄｅ２０２１は、対応するＦａｃｅｔ２０２２を有する。ＤＯＭの中のＮｏｄｅを直接操作する代わりに、操作を実行するためにＦａｃｅｔを使用することによって、ＤＯＭの保全性は保護される。そうでなく、操作がＮｏｄｅ上で直接実行される場合、いくつかのプラグインがＤＯＭを同時に変更することができ、その結果矛盾を引き起こす。【００６５】  ボキャブラリは、名前空間に属するタグ（例えばＸＭＬのタグ）のセットである。上述したように、名前空間は、ユニークな名前（ここではタグ）のセットを有する。ボキャブラリは、ＸＭＬ文書を表現するＤＯＭツリーのサブツリーとして現れる。このサブツリーはＺｏｎｅを含む。特定の例においては、タグセットの境界はＺｏｎｅによって定義される。Ｚｏｎｅ２０９は、ＺｏｎｅＦａｃｔｏｒｙ２０５と呼ばれるＳｅｒｖｉｃｅを利用して生成される。上述したように、Ｚｏｎｅ２０９は、文書を表現するＤＯＭツリーの一部の内部表現である。このような文書の一部へのアクセスを提供するために、論理的な表現が要求される。この論理的表現は、文書が画面上で論理的にどのように表現されるかについてコンピュータに通知する。Ｃａｎｖａｓ（キャンバス）２１０は、Ｚｏｎｅに対応する論理的なレイアウトを提供するように作用するＳｅｒｖｉｃｅである。【００６６】  他方、Ｐａｎｅ２１１は、Ｃａｎｖａｓ２１０により提供される論理的なレイアウトに対応する物理的な画面レイアウトである。実際、ユーザは表示画面上で文字や画像によって文書のレンダリングのみを見る。したがって、文書は、画面上に文字や画像を描画するプロセスにより、画面上に描写されなければならない。文書は、Ｐａｎｅ２１１により提供される物理的なレイアウトに基づいて、Ｃａｎｖａｓ２１０により画面上に描写される。【００６７】  Ｚｏｎｅ２０９に対応するＣａｎｖａｓ２１０は、Ｅｄｉｔｌｅｔ２０６を使用して生成される。文書のＤＯＭは、Ｅｄｉｔｌｅｔ２０６及びＣａｎｖａｓ２１０を使用して編集される。元の文書の完全性を維持するために、Ｅｄｉｔｌｅｔ２０６及びＣａｎｖａｓ２１０は、Ｚｏｎｅ２０９における１以上のＮｏｄｅに対応するＦａｃｅｔを使用する。これらのＳｅｒｖｉｃｅは、Ｚｏｎｅ及びＤＯＭ内のＮｏｄｅを直接操作しない。Ｆａｃｅｔは、Ｃｏｍｍａｎｄ２０７を利用して操作される。【００６８】  ユーザは、一般に、画面上のカーソルを移動させたり、コマンドをタイプしたりすることによって、画面と対話する。画面上の論理的なレイアウトを提供するＣａｎｖａｓ２０１０は、このカーソル操作を受け付ける。Ｃａｎｖａｓ２０１０は、対応するアクションをＦａｃｅｔに実行させることができる。この関係により、カーソルサブシステム２０４は、Ｄｏｃｕｍｅｎ��Ｍａｎａｇｅｒ１０８１に対して、ＭＶＣパラダイムのコントローラ（Ｃ）として機能する。Ｃａｎｖａｓ２０１０は、イベントを扱うタスクも有する。例えば、Ｃａｎｖａｓ２０１０は、マウスクリック、フォーカス移動、及びユーザにより起こされた同様のアクションなどのイベントを扱う。【００６９】  ３．Ｚｏｎｅ、Ｆａｃｅｔ、Ｃａｎｖａｓ及びＰａｎｅの間の関係の概要
文書処理システム内の文書は、少なくとも４つの観点から見ることができる。すなわち、１）文書処理システムにおいて文書の内容及び構造を保持するために用いられるデータ構造、２）文書の保全性に影響を与えずに文書の内容を編集する手段、３）文書の画面上の論理的なレイアウト、４）文書の画面上の物理的なレイアウト、である。Ｚｏｎｅ、Ｆａｃｅｔ、Ｃａｎｖａｓ及びＰａｎｅは、前述の４つの観点に相当する、文書処理システムのコンポーネントをそれぞれ表す。【００７０】  ４．アンドゥサブシステム
上述したように、文書に対するいかなる変更（例えば編集）も取消可能であることが望ましい。例えば、ユーザが編集操作を実行し、次に、その変更の取消を決定したとする。図２に関連して、アンドゥサブシステム２１２は、文書管理部の取消可能なコンポーネントを実現する。ＵｎｄｏＭａｎａｇｅｒ（アンドゥマネージャ：アンドゥ管理部）２１２１は、ユーザによって取り消される可能性のある全ての文書に対する操作を保持する。【００７１】  例えば、ユーザが、文書中の単語を別の単語に置換するコマンドを実行したとする。その後、ユーザは考え直し、元の単語に戻すことを決定したとする。アンドゥサブシステム２１２は、このような操作を支援する。ＵｎｄｏＭａｎａｇｅｒ２１２１は、このようなＵｎｄｏａｂｌｅＥｄｉｔ（アンドゥアブルエディット：取消可能な編集）２１２２の操作を保持する。【００７２】  ５．カーソルサブシステム
前述したように、ＭＶＣのコントローラ部分は、カーソルサブシステム２０４を備えてもよい。カーソルサブシステム２０４は、ユーザから入力を受け付ける。これらの入力は、一般にコマンド及び／又は編集操作の性格を有している。したがって、カーソルサブシステム２０４は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１に関連したＭＶＣパラダイムのコントローラ（Ｃ）部分であると考えることができる。【００７３】  ６．ビュー
前述したように、Ｃａｎｖａｓ２０１０は、画面上に提示されるべき文書の論理的なレイアウトを表す。ＸＨＴＭＬ文書の例では、Ｃａｎｖａｓは、文書が画面上でいかに見えるかを論理的に表現したボックスツリー２０８を含んでもよい。このボックスツリー２０８は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１に関連したＭＶＣパラダイムのビュー（Ｖ）部分に含まれよう。【００７４】Ｃ．ボキャブラリコネクション
文書処理システムの重要な特徴は、ＸＭＬ文書を、他の表現にマップして取り扱うことが可能で、かつ、マップした先の表現を編集すると、その編集が元のＸＭＬ文書に整合性を保ちつつ反映される環境を提供することにある。【００７５】  マークアップ言語により記述された文書、例えばＸＭＬ文書は、文書型定義により定義されたボキャブラリに基づいて作成されている。ボキャブラリは、タグのセットである。ボキャブラリは、任意に定義されてもよいため、無限に多くのボキャブラリが存在しうる。しかしながら、多数の可能なボキャブラリのそれぞれに対して専用の処理／管理環境を提供するのは現実的ではない。ボキャブラリコネクションは、この問題を解決する方法を提供する。【００７６】  例えば、文書は２以上のマークアップ言語により記述されてもよい。文書は、例えば、ＸＨＴＭＬ（ｅＸｔｅｎｓｉｂｌｅ  ＨｙｐｅｒＴｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）、ＳＶＧ（Ｓｃａｌａｂｌｅ  Ｖｅｃｔｏｒ  Ｇｒａｐｈｉｃｓ）、ＭａｔｈＭＬ（Ｍａｔｈｅｍａｔｉｃａｌ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）、その他のマークアップ言語により記述されてもよい。換言すれば、マークアップ言語は、ＸＭＬにおけるボキャブラリやタグセットと同様に見なされてもよい。【００７７】  ボキャブラリは、ボキャブラリプラグインを用いて処理される。文書処理システムにおいてプラグインが利用不可能であるボキャブラリにより記述された文書は、プラグインが利用可能である別のボキャブラリの文書にマッピングすることにより表示される。この特徴により、プラグインが用意されていないボキャブラリの文書も適切に表示することができる。【００７８】  ボキャブラリコネクションは、定義ファイルを取得し、取得した定義ファイルに基づいて２つの異なるボキャブラリの間でマッピングする能力を含む。あるボキャブラリで記述された文書は、別のボキャブラリにマッピングすることができる。このように、ボキャブラリコネクションは、文書がマッピングされるボキャブラリに対応した表示／編集プラグインにより文書を表示し編集することを可能にする。【００７９】  上述したように、各文書は、一般に複数のノードを有するＤＯＭツリーとして文書処理システムにおいて記述される。「定義ファイル」は、それぞれのノードについて、そのノードと他のノードとの対応を記述する。各ノードの要素値及び属性値が編集可能か否かが指定される。ノードの要素値又は属性値を用いた演算式が記述されてもよい。【００８０】  マッピングという特徴を利用して、定義ファイルを適用したデスティネーションＤＯＭツリーが生成される。このように、ソースＤＯＭツリーとデスティネーションＤＯＭツリーの関係が構築され保持される。ボキャブラリコネクションは、ソースＤＯＭツリーとデスティネーションＤＯＭツリーの対応を監視する。ユーザから編集指示を受けると、ボキャブラリコネクションは、ソースＤＯＭツリーの関連したノードを変更する。ソースＤＯＭツリーが変更されたことを示す「ミューテーションイベント」が発行され、デスティネーションＤＯＭツリーがそれに応じて変更される。【００８１】  ボキャブラリコネクションの使用により、少数のユーザのみに知られ��いた比較的マイナーなボキャブラリを、別のメジャーなボキャブラリに変換することができる。したがって、少数のユーザによって利用されるマイナーなボキャブラリであっても、文書を適切に表示し、望ましい編集環境を提供することができる。【００８２】  このように、文書処理システムの一部であるボキャブラリコネクションサブシステムは、文書の複数の表現を可能にする機能を提供する。【００８３】  図３は、ボキャブラリコネクション（ＶＣ：Ｖｏｃａｂｕｌａｒｙ  Ｃｏｎｎｅｃｔｉｏｎ）サブシステム３００を示す。ＶＣサブシステム３００は、同一の文書の２つの代替表現の整合性を維持する方法を提供する。例えば、２つの表現は、同一文書の、２つの異なるボキャブラリによる表現であってもよい。前述したように、一方はソースＤＯＭツリーであってもよく、他方はデスティネーションＤＯＭツリーであってもよい。【００８４】  １．ボキャブラリコネクションサブシステム
ボキャブラリコネクションサブシステム３００の機能は、ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎ３０１と呼ばれるプラグインを使用して、文書処理システムにおいて実現される。文書が表現されるＶｏｃａｂｕｌａｒｙ３０５ごとに、対応するプラグインが要求される。例えば、文書の一部がＨＴＭＬで記述され、残りがＳＶＧで記述されている場合、ＨＴＭＬとＳＶＧに対応するボキャブラリプラグインが要求される。【００８５】  ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎプラグイン３０１は、適切なＶｏｃａｂｕｌａｒｙ３０５の文書に対応した、Ｚｏｎｅ２０９又はＰａｎｅ２１１のための適切なＶＣＣａｎｖａｓ（ボキャブラリコネクションキャンバス）３１０を生成する。ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎ３０１を用いて、ソースＤＯＭツリー内のＺｏｎｅ２０９に対する変更は、変換ルールにより、別のＤＯＭツリー３０６の対応するＺｏｎｅに伝達される。変換ルールは、ボキャブラリコネクション記述子（Ｖｏｃａｂｕｌａｒｙ  Ｃｏｎｎｅｃｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒ：ＶＣＤ）の形式で記述される。このようなソースＤＯＭとデスティネーションＤＯＭの間の変換に対応するそれぞれのＶＣＤファイルについて、対応するＶＣＭａｎａｇｅｒ（ボキャブラリコネクションマネージャ）３０２が生成される。【００８６】  ２．Ｃｏｎｎｅｃｔｏｒ
Ｃｏｎｎｅｃｔｏｒ３０４は、ソースＤＯＭツリーのソースノードと、デスティネーションＤＯＭツリーのデスティネーションノードとを接続する。Ｃｏｎｎｅｃｔｏｒ３０４は、ソースＤＯＭツリー中のソースノード、及びソースノードに対応するソース文書に対する修正（変更）を見るために作用する。そして、対応するデスティネーションＤＯＭツリーのノードを修正する。Ｃｏｎｎｅｃｔｏｒ３０４は、デスティネーションＤＯＭツリーを修正することができる唯一のオブジェクトである。例えば、ユーザは、ソース文書、及び対応するソースＤＯＭツリーに対してのみ修正を行うことができる。その後、Ｃｏｎｎｅｃｔｏｒ３０４がデスティネーションＤＯＭツリーに、対応する修正を行う。【００８７】  Ｃｏｎｎｅｃｔｏｒ３０４は、ツリー構造を形成するために、論理的にリンクされる。Ｃｏｎｎｅｃｔｏｒ３０４により形成されたツリーは、ＣｏｎｎｅｃｔｏｒＴｒｅｅ（コネクタツリー）と呼ばれる。Ｃｏｎｎｅｃｔｏｒ３０４は、ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ（コネクタファクトリ：コネクタ生成部）３０３と呼ばれるＳｅｒｖｉｃｅを用いて生成される。ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３は、ソース文書からＣｏｎｎｅｃｔｏｒ３０４を生成し、それらをリンクしてＣｏｎｎｅｃｔｏｒＴｒｅｅを形成する。ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒ３０２は、ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３を保持する。【００８８】  前述したように、ボキャブラリは名前空間におけるタグのセットである。図示されるように、Ｖｏｃａｂｕｌａｒｙ３０５は、ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎ３０１によって文書に対して生成される。これは、文書ファイルを解析し、ソースＤＯＭとデスティネーションＤＯＭの間の写像のための適切なＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒ３０２を生成することにより行われる。さらに、Ｃｏｎｎｅｃｔｏｒを生成するＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３と、Ｚｏｎｅ２０９を生成するＺｏｎｅＦａｃｔｏｒｙ２０５と、Ｚｏｎｅ内のノードに対応するＣａｎｖａｓを生成するＥｄｉｔｌｅｔ２０６との間の適切な関係が作られる。ユーザがシステムから文書を処分又は削除するとき、対応するＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒ３０２が削除される。【００８９】  Ｖｏｃａｂｕｌａｒｙ３０５は、ＶＣＣａｎｖａｓ３１０を生成する。さらに、Ｃｏｎｎｅｃｔｏｒ３０４及びデスティネーションＤＯＭツリー３０６が対応して生成される。【００９０】  ソースＤＯＭ及びＣａｎｖａｓは、それぞれ、モデル（Ｍ）及びビュー（Ｖ）に対応する。しかしながら、このような表現は、ターゲットのボキャブラリが画面上に描写可能である場合に限って意味がある。描写は、ボキャブラリプラグインにより行われる。ボキャブラリプラグインは、主要なボキャブラリ、例えば、ＸＨＴＭＬ、ＳＶＧ、ＭａｔｈＭＬについて提供される。ボキャブラリプラグインは、ターゲットのボキャブラリに関連して使用される。これらは、ボキャブラリコネクション記述子を用いてボキャブラリ間でマッピングする方法を提供する。【００９１】  このようなマッピングは、ターゲットのボ��ャブラリが、マッピング可能で、画面上に描写される方法が予め定義されたものである場合にのみ意味がある。このようなレンダリング方法は、例えばＸＨＴＭＬなどのように、Ｗ３Ｃなどの組織により定義された標準規格となっている。【００９２】  ボキャブラリコネクションが必要であるとき、ＶＣＣａｎｖａｓが使用される。この場合、ソースのビューを直接生成することができないので、ソースのＣａｎｖａｓは生成されない。この場合、ＶＣＣａｎｖａｓが、ＣｏｎｎｅｃｔｏｒＴｒｅｅを使用して生成される。このＶＣＣａｎｖａｓは、イベントの変換のみを扱い、画面上の文書の描写を援助しない。【００９３】  ３．ＤｅｓｔｉｎａｔｉｏｎＺｏｎｅ、Ｐａｎｅ、及びＣａｎｖａｓ
上述したように、ボキャブラリコネクションサブシステムの目的は、同一の文書の２つの表現を同時に生成し保持することである。第２の表現も、ＤＯＭツリーの形式であり、これはデスティネーションＤＯＭツリーとして既に説明した。第２の表現における文書を見るために、ＤｅｓｔｉｎａｔｉｏｎＺｏｎｅ、Ｃａｎｖａｓ及びＰａｎｅが必要である。【００９４】  ＶＣＣａｎｖａｓが作成されると、対応するＤｅｓｔｉｎａｔｉｏｎＰａｎｅ３０７が生成される。さらに、関連するＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓ３０８と、対応するＢｏｘＴｒｅｅ３０９が生成される。同様に、ＶＣＣａｎｖａｓ３１０も、ソース文書に対するＰａｎｅ２１１及びＺｏｎｅ２０９に関連づけられる。【００９５】  ＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓ３０８は、第２の表現における文書の論理的なレイアウトを提供する。特に、ＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓ３０８は、デスティネーション表現における文書を描写するために、カーソルや選択のようなユーザインタフェイス機能を提供する。ＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓ３０８に生じたイベントは、Ｃｏｎｎｅｃｔｏｒに供給される。ＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓ３０８は、マウスイベント、キーボードイベント、ドラッグアンドドロップイベント、及び文書のデスティネーション（第２）表現のボキャブラリに特有なイベントを、Ｃｏｎｎｅｃｔｏｒ３０４に通知する。【００９６】  ４．ボキャブラリコネクションコマンドサブシステム
ボキャブラリコネクション（ＶＣ）サブシステム３００の要素として、ボキャブラリコネクション（ＶＣ）コマンドサブシステム３１３がある。ボキャブラリコネクションコマンドサブシステム３１３は、ボキャブラリコネクションサブシステム３００に関連した命令の実行のために使用されるＶＣＣｏｍｍａｎｄ（ボキャブラリコネクションコマンド）３１５を生成する。ＶＣＣｏｍｍａｎｄは、内蔵のＣｏｍｍａｎｄＴｅｍｐｌａｔｅ（コマンドテンプレート）３１３１を使用して、及び／又は、スクリプトサブシステム３１４においてスクリプト言語を使用してスクラッチからコマンドを生成することにより、生成することができる。【００９７】  コマンドテンプレートには、例えば、「Ｉｆ」コマンドテンプレート、「Ｗｈｅｎ」コマンドテンプレート、「挿入（Ｉｎｓｅｒｔ）」コマンドテンプレートなどがある。これらのテンプレートは、ＶＣＣｏｍｍａｎｄを作成するために使用される。【００９８】  ５．ＸＰａｔｈサブシステム
ＸＰａｔｈサブシステム３１６は、文書処理システムの重要な構成であり、ボキャブラリコネクションの実現を支援する。Ｃｏｎｎｅｃｔｏｒ３０４は、一般にｘｐａｔｈ情報を含む。上述したように、ボキャブラリコネクションのタスクの１つは、ソースＤＯＭツリーの変化をデスティネーションＤＯＭツリーに反映させることである。ｘｐａｔｈ情報は、変更／修正を監視されるべきソースＤＯＭツリーのサブセットを決定するために用いられる１以上のｘｐａｔｈ表現を含む。【００９９】  ６．ソースＤＯＭツリー、デスティネーションＤＯＭツリー、及びＣｏｎｎｅｃｔｏｒＴｒｅｅの概要
ソースＤＯＭツリーは、別のボキャブラリに変換される前のボキャブラリで文書を表現したＤＯＭツリー又はＺｏｎｅである。ソースＤＯＭツリーのノードは、ソースノードと呼ばれる。【０１００】  それに対して、デスティネーションＤＯＭツリーは、ボキャブラリコネクションに関連して前述したように、同一の文書を、マッピングにより変換された後の異なるボキャブラリで表現したＤＯＭツリー又はＺｏｎｅである。デスティネーションＤＯＭツリーのノードは、デスティネーションノードと呼ばれる。【０１０１】  ＣｏｎｎｅｃｔｏｒＴｒｅｅは、ソースノードとデスティネーションノードの対応を表すＣｏｎｎｅｃｔｏｒに基づく階層的表現である。Ｃｏｎｎｅｃｔｏｒは、ソースノードと、ソース文書になされた修正を監視し、デスティネーションＤＯＭツリーを修正する。Ｃｏｎｎｅｃｔｏｒは、デスティネーションＤＯＭツリーを修正することを許された唯一のオブジェクトである。【０１０２】Ｄ．文書処理システムにおけるイベントフロー
実用のためには、プログラムはユーザからのコマンドに応答しなければならない。イベントは、プログラム上で実行されたユーザアクションを記述し実行する方法である。多くの高級言語、例えばＪａｖａ（登録商標）は、ユーザアクションを記述するイベントに頼っている。従来、プログラムは、ユーザアクションを理解し、それを自身で実行するために、積極的に情報を集める必要があった。これは、例えば、プログラムが自身を初期化した後、ユーザが画面、キーボード、マウスなどでアクションを起こしたときに適切な処理を講じるために、ユーザのアクションを繰り返し確認するループに入ることを意味する。しかしながら、このプロセスは扱いにくい。さらに、それは、ユーザが何かをするのを待つ間、ＣＰＵサイクルを消費してループするプログラムを必要とする。【０１０３】  多くの言語が、異なるパラダイムを採用することにより、これらの問題を解決している。そのうちの一つは、現代の全てのウィンドウシステムの基礎となっている、イベントドリブンプログラミングである。このパラダイムでは、全てのユーザアクションは、「イベント」と呼ばれる抽象的な事象の集合に属する。イベントは、十分詳細に、特定のユーザアクションを記述する。プログラムがユーザにより生成されたイベントを積極的に収集するのではなく、監視すべきイベントが生じたときに、システムがプログラムに通知する。この方法によりユーザとの対話を扱うプログラムは「イベントドリブン」であると言われる。【０１０４】  これは、多くの場合、全てのユーザにより生成されたイベントの基本特性を獲得する「Ｅｖｅｎｔ（イベント）」クラスを使用して扱われる。【０１０５】  文書処理システムは、自身のイベント、及びこれらのイベントを扱う方法を定義して使用する。いくつかの型のイベントが使用される。例えば、マウスイベントは、ユーザのマウスアクションから起こるイベントである。マウスを含むユーザアクションは、Ｃａｎｖａｓ２１０によって、マウスイベントに渡される。このように、Ｃａｎｖａｓは、システムのユーザによる相互作用の最前部にあると言える。必要であれば、最前部にあるＣａｎｖａｓは、そのイベントに関連した内容を子へ渡す。【０１０６】  それに対して、キーストロークイベントは、Ｃａｎｖａｓ２１０から流れる。キーストロークイベントは、即時的なフォーカスを有する。すなわち、それは、いかなる瞬間でも作業に関連する。Ｃａｎｖａｓ２１０上に入力されたキーストロークイベントは、その親に渡される。キー入力は、文字列挿入を扱うことが可能な、異なるイベントによって処理される。文字列の挿入を扱うイベントは、キーボードを使用して文字が挿入されたときに発生する。他の「イベント」は、例えば、ドラッグイベント、ドロップイベント、マウスイベントと同様に扱われる他のイベントを含む。【０１０７】  １．ボキャブラリコネクション外のイベントの取り扱い
イベントは、イベントスレッドを用いて渡される。Ｃａｎｖａｓ２１０は、イベントを受け取ると、その状態を変更する。必要であれば、Ｃｏｍｍａｎｄ１０５２がＣａｎｖａｓ２１０によりＣｏｍｍａｎｄＱｕｅｕｅ１０５３にポストされる。【０１０８】  ２．ボキャブラリコネクション内のイベントの取り扱い
ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎプラグイン３０１を用いて、ＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓの一例であるＸＨＴＭＬＣａｎｖａｓ１１０６は、発生したイベント、例えば、マウスイベント、キーボードイベント、ドラッグアンドドロップイベント、及びボキャブラリに特有のイベントなどを受け取る。これらのイベントは、Ｃｏｎｎｅｃｔｏｒ１１０４に通知される。より詳細には、図１１に図示されるように、ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎプラグイン３０１内のイベントフローは、ＳｏｕｒｃｅＰａｎｅ１１０３、ＶＣＣａｎｖａｓ１１０４、ＤｅｓｔｉｎａｔｉｏｎＰａｎｅ１１０５、ＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓの一例であるＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓ１１０６、デスティネーションＤＯＭツリー及びＣｏｎｎｅｃｔｏｒＴｒｅｅを通過する。【０１０９】Ｅ．ＰｒｏｇｒａｍＩｎｖｏｋｅｒ及びＰｒｏｇｒａｍＩｎｖｏｋｅｒと他の構成との関係
ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３及びそれと他の構成との関係は、図４（ａ）に更に詳細に示される。ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３は、文書処理システムを開始するために実行される実行環境中の基本的なプログラムである。図１（ｂ）に図示されるように、ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６、ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１、ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１、及びＲｅｓｏｕｒｃｅ１０９は、全てＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３に接続される。前述したように、アプリケーション１０２は、実行環境中で実行されるコンポーネントである。同様に、ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１は、システムに様々な機能を加えるプラグインを管理する。他方、ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１は、ユーザにより提供される命令を実行して、コマンドを実行するために使用されるクラス及びファンクションを保持する。【０１１０】  １．プラグイン及びサービス
ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１について、図４（ｂ）を参照して更に詳細に説明する。前述したように、ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１は、システムに様々な機能を追加するプラグイン（及び関連するサービス）を管理する。Ｓｅｒｖｉｃｅ１０４２は、文書処理システムに特徴を追加又は変更可能な最も下の層である。「Ｓｅｒｖｉｃｅ」は、ＳｅｒｖｉｃｅＣａｔｅｇｏｒｙ４０１とＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒ４０２の２つの部分からなる。図４（ｃ）に図示されるように、１つのＳｅｒｖｉｃｅＣａｔｅｇｏｒｙ４０１は、複数の関連するＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒ４０２を持ちうる。それぞれのＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒは、特定のＳｅｒｖｉｃｅＣａｔｅｇｏｒｙの一部または全部を実行するように作用する。ＳｅｒｖｉｃｅＣａｔｅｇｏｒｙ４０１は、他方では、Ｓｅｒｖｉｃｅの型を定義する。【０１１１】  Ｓｅｒｖｉｃｅは、１）文書処理システムに特定の特色を提供する「特色サービス」、２）文書処理システムにより実行されるアプリケーションである「アプリケーションサービス」、３）文書処理システムの全体にわたって必要な特色を提供する「環境サービス」、の３つの型に分類することができる。【０１１２】  Ｓｅｒｖｉｃｅの例は、図４（ｄ）に示される。アプリケーションＳｅｒｖｉｃｅのＣａｔｅｇｏｒｙにおいては、システムユーティリティが対応するＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒの例である。同様に、Ｅｄｉｔｌｅｔ２０６はＣａｔｅｇｏｒｙであり、ＨＴＭＬＥｄｉｔｌｅｔ及びＳＶＧＥｄｉｔｌｅｔは対応するＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒである。ＺｏｎｅＦａｃｔｏｒｙ２０５は、Ｓｅｒｖｉｃｅの別のＣａｔｅｇｏｒｙであり、対応するＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒ（図示せず）を有する。【０１１３】  プラグインは、文書処理システムに機能性を加えると既に説明したが、いくつかのＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒ４０２及びそれらに関連するクラスからなるユニットと見なされてもよい。各プラグインは、宣言ファイルに記述された依存性及びＳｅｒｖｉｃｅＣａｔｅｇｏｒｙ４０１を有する。【０１１４】  ２．ＰｒｏｇｒａｍＩｎｖｏｋｅｒとアプリケーションとの関係
図４（ｅ）は、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３とＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６との関係についての更なる詳細を示す。必要な文書やデータなどは、ストレージからロードされる。必要なプラグインは、全てＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１上にロードされる。ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１は、全てのプラグインを保持し管理する。プラグインは、システムに物理的に追加することができ、又、その機能はストレージからロードすることができる。プラグインの内容がロードされると、ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１は、対応するプラグインを定義する。つづいて、対応するＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６が生成され、実行環境１０１にロードされ、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３にアタッチされる。【０１１５】Ｆ．アプリケーションサービスと環境との関係
図５（ａ）は、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３上にロードしたアプリケーションサービスの構成についての更なる詳細を示す。コマンドサブシステム１０５のコンポーネントであるＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１は、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３内のＣｏｍｍａｎｄ１０５２を起動又は実行する。Ｃｏｍｍａｎｄ１０５２は、文書処理システムにおいて、ＸＭＬなどの文書を処理し、対応するＸＭＬＤＯＭツリーを編集するために用いられる命令である。ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１は、Ｃｏｍｍａｎｄ１０５２を実行するために必要なクラス及びファンクションを保持する。【０１１６】  ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１も、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３内で実行される。ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６は、ユーザインタフェイス１０７及びＣｏｒｅＣｏｍｐｏｎｅｎｔ１１０に接続される。ＣｏｒｅＣｏｍｐｏｎｅｎｔ１１０は、全てのＰａｎｅの間で文書を共有する方法を提供する。ＣｏｒｅＣｏｍｐｏｎｅｎｔ１１０は、さらにフォントを提供し、Ｐａｎｅのためのツールキットの役割を果たす。【０１１７】  図５（ａ）及び図５（ｂ）は、Ｆｒａｍｅ１０７１、ＭｅｎｕＢａｒ１０７２、及びＳｔａｔｕｓＢａｒ１０７３の関係を示す。【０１１８】Ｇ．アプリケーションコア
図６（ａ）は、全ての文書、及び文書の一部及び文書に属するデータを保持するアプリケーションコア１１０についての更なる説明を提供する。ＣｏｒｅＣｏｍｐｏｎｅｎｔ１１０は、Ｄｏｃｕｍｅｎｔ１０８２を管理するＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１にアタッチされる。ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１は、文書処理システムに関連づけられたメモリに格納される全てのＤｏｃｕｍｅｎｔ１０８２の所有者である。【０１１９】  画面上の文書の表示を容易にするために、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１はＲｏｏｔＰａｎｅ１０８４にも接続される。ＣｌｉｐＢｏａｒｄ１０８６、ＳｎａｐＳｈｏｔ１０８７、Ｄｒａｇ＆Ｄｒｏｐ６０１、及びＯｖｅｒｌａｙ６０２の機能も、アプリケーションコアにアタッチされる。【０１２０】  ＳｎａｐＳｈｏｔ１０８７は、図６（ａ）で示したように、アプリケーションの状態を元に戻すために使用される。ユーザがＳｎａｐＳｈｏｔ１０８７を起動したとき、アプリケーションの現状が検知され、格納される。その後、アプリケーションの状態が別の状態に変わるとき、格納された状態の内容は保存される。ＳｎａｐＳｈｏｔは、図６（ｂ）に図示される。動作において、アプリケーションがあるＵＲＬから他へ移動するときに、前に戻る動作及び先に進む動作をシームレスに実行可能とするために、ＳｎａｐＳｈｏｔは以前の状態を記憶する。【０１２１】Ｈ．ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ内における文書の構成
図７（ａ）は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１の更なる説明と、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒにおいて文書が構成され保持される様子を示す。図１（ｂ）に示したように、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１は、Ｄｏｃｕｍｅｎｔ１０８２を管理する。図７（ａ）に示される例において、複数のＤｏｃｕｍｅｎｔのうちの１つはＲｏｏｔＤｏｃｕｍｅｎｔ（ルート文書）７０１であり、残りの文書はＳｕｂＤｏｃｕｍｅｎｔ（サブ文書）７０２である。ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１は、ＲｏｏｔＤｏｃｕｍｅｎｔ７０１に接続され、ＲｏｏｔＤｏｃｕｍｅｎｔ７０１は、全てのＳｕｂＤｏｃｕｍｅｎｔ７０２に接続される。【０１２２】  図２及び図７（ａ）に示すように、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１は、全ての文書１０８２を管理するオブジェクトであるＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ２０３に結合される。ＤＯＭＳｅｒｖｉｃｅ７０３及びＩＯＭａｎａｇｅｒ７０４を含むツールキット２０１（例えばＸＭＬツールキット）の一部を形成するツールも、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１に供給される。再び図７（ａ）を参照して、ＤＯＭＳｅｒｖｉｃｅ７０３は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１により管理される文書に基づいたＤＯＭツリーを生成する。各Ｄｏｃｕｍｅｎｔ７０５は、それがＲｏｏｔＤｏｃｕｍｅｎｔ７０１であってもＳｕｂＤｏｃｕｍｅｎｔ７０２であっても、対応するＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ２０３によって管理される。【０１２３】  図７（ｂ）は、文書Ａ−Ｅが階層的に配置される様子を示す。文書ＡはＲｏｏｔＤｏｃｕｍｅｎｔである。文書Ｂ−Ｄは、文書ＡのＳｕｂＤｏｃｕｍｅｎｔである。文書Ｅは、文書ＤのＳｕｂＤｏｃｕｍｅｎｔである。図７（ｃ）では、これと同じ文書の階層が画面上に表示された例を示す。ＲｏｏｔＤｏｃｕｍｅｎｔである文書Ａは、基本フレームとして表示される。文書ＡのＳｕｂＤｏｃｕｍｅｎｔである文書Ｂ−Ｄは、基本フレームＡの中のサブフレームとして表示される。文書ＤのＳｕｂＤｏｃｕｍｅｎｔである文書Ｅは、サブフレームＤのサブフレームとして画面に表示される。【０１２４】  再び図７（ａ）を参照して、ＵｎｄｏＭａｎａｇｅｒ（アンドゥマネージャ：アンドゥ管理部）７０６及びＵｎｄｏＷｒａｐｐｅｒ（アンドゥラッパー）７０７は、それぞれのＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ２０３に対して生成される。ＵｎｄｏＭａｎａｇｅｒ７０６及びＵｎｄｏＷｒａｐｐｅｒ７０７は、取消可能なコマンドを実行するために使用される。この特徴を使用することにより、編集操作を使用して文書に対して実行された変更を取り消すことができる。ＳｕｂＤｏｃｕｍｅｎｔの変更は、ＲｏｏｔＤｏｃｕｍｅｎｔとも密接な関係を有する。アンドゥ操作は、階層内の他の文書に影響する変更を考慮に入れて、例えば、図１７（ｃ）に示されるような連鎖状の階層における全ての文書の間で整合性が維持されることを保証する。【０１２５】  ＵｎｄｏＷｒａｐｐｅｒ７０７は、ＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ２０３内のＳｕｂＤｏｃｕｍｅｎｔに関連するアンドゥオブジェクトをラップし、それらをＲｏｏｔＤｏｃｕｍｅｎｔに関連するアンドゥオ���ジェクトに結合させる。ＵｎｄｏＷｒａｐｐｅｒ７０７は、ＵｎｄｏａｂｌｅＥｄｉｔＡｃｃｅｐｔｏｒ（アンドゥアブルエディットアクセプタ：アンドゥ可能編集受付部）７０９に利用可能なアンドゥオブジェクトを収集させる。【０１２６】  ＵｎｄｏＭａｎａｇｅｒ７０６及びＵｎｄｏＷｒａｐｐｅｒ７０７は、ＵｎｄｏａｂｌｅＥｄｉｔＡｃｃｅｐｔｏｒ７０８及びＵｎｄｏａｂｌｅＥｄｉｔＳｏｕｒｃｅ（アンドゥアブルエディットソース）７０８に接続される。当業者には理解されるように、Ｄｏｃｕｍｅｎｔ７０５がＵｎｄｏａｂｌｅＥｄｉｔＳｏｕｒｃｅ７０８であってもよく、取消可能な編集オブジェクトのソースであってもよい。【０１２７】Ｉ．アンドゥコマンド及びアンドゥフレームワーク
図８（ａ）及び図８（ｂ）は、アンドゥフレームワーク及びアンドゥコマンドについて更なる詳細を提供する。図８（ａ）に示されるように、ＵｎｄｏＣｏｍｍａｎｄ８０１、ＲｅｄｏＣｏｍｍａｎｄ８０２、及びＵｎｄｏａｂｌｅＥｄｉｔＣｏｍｍａｎｄ８０３は、図１（ｂ）に示したようにＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１に積むことができるコマンドであり、順に実行される。ＵｎｄｏａｂｌｅＥｄｉｔＣｏｍｍａｎｄ８０３は、ＵｎｄｏａｂｌｅＥｄｉｔＳｏｕｒｃｅ７０８及びＵｎｄｏａｂｌｅＥｄｉｔＡｃｃｅｐｔｏｒ７０９に更にアタッチされる。「ｆｏｏ」ＥｄｉｔＣｏｍｍａｎｄ８０３及び「ｂａｒ」ＥｄｉｔＣｏｍｍａｎｄ８０４は、ＵｎｄｏａｂｌｅＥｄｉｔＣｏｍｍａｎｄの例である。【０１２８】  １．ＵｎｄｏａｂｌｅＥｄｉｔＣｏｍｍａｎｄの実行
図８（ｂ）は、ＵｎｄｏａｂｌｅＥｄｉｔＣｏｍｍａｎｄの実行を示す。まず、ユーザが編集コマンドを使用してＤｏｃｕｍｅｎｔ７０５を編集すると仮定する。第１ステップＳ１では、ＵｎｄｏａｂｌｅＥｄｉｔＡｃｃｅｐｔｏｒ７０９が、Ｄｏｃｕｍｅｎｔ７０５のＤＯＭツリーであるＵｎｄｏａｂｌｅＥｄｉｔＳｏｕｒｃｅ７０８にアタッチされる。第２ステップＳ２では、ユーザにより発行されたコマンドに基づいて、Ｄｏｃｕｍｅｎｔ７０５がＤＯＭのＡＰＩを用いて編集される。第３ステップＳ３では、ミューテーションイベントのリスナーが、変更がなされたことを通知される。すなわち、このステップでは、ＤＯＭツリーの全ての変更を監視するリスナーが編集操作を検知する。第４ステップＳ４では、ＵｎｄｏａｂｌｅＥｄｉｔがＵｎｄｏＭａｎａｇｅｒ７０６のオブジェクトとして格納される。第５ステップＳ５では、ＵｎｄｏａｂｌｅＥｄｉｔＡｃｃｅｐｔｏｒ７０９がＵｎｄｏａｂｌｅＥｄｉｔＳｏｕｒｃｅ７０８からデタッチされる。ＵｎｄｏａｂｌｅＥｄｉｔＳｏｕｒｃｅ７０８は、Ｄｏｃｕｍｅｎｔ７０５自身であってもよい。【０１２９】Ｊ．システムへの文書のロードに関する手順
上記のサブセクションでは、システムの様々なコンポーネント及びサブコンポーネントについて説明した。以下、これらのコンポーネントの使用に関する方法論について説明する。図９は、文書処理システムに文書がロードされる様子の概要を示す。それぞれのステップは、図１４−１８において、特定の例に関連して詳述される。【０１３０】  簡単には、文書処理システムは、文書に含まれるデータからなるバイナリデータストリームからＤＯＭを生成する。ＡｐｅｘＮｏｄｅ（エイペックスノード：頂点ノード）が、注目対象でありＺｏｎｅに属する文書の一部のために生成される。つづいて、対応するＰａｎｅが特定される。特定されたＰａｎｅは、ＡｐｅｘＮｏｄｅ及び物理的な画面表面からＺｏｎｅ及びＣａｎｖａｓを生成する。Ｚｏｎｅは、次に、それぞれのノードにＦａｃｅｔを生成し、それらに必要とされる情報を提供する。Ｃａｎｖａｓは、ＤＯＭツリーから、ノードをレンダリングするためのデータ構造を生成する。【０１３１】  図１９（ａ）で示すように、ＳＨＴＭＬやＳＶＧコンテンツの両方で記述された複雑な文書はストレージ９０１からステップ０としてロードされる。その文書のＤＯＭツリー９０２が作成される。ＤＯＭツリー９０２が一つの頂点ノード９０５を有し、そして木が他の枝に降りるように、境界では２方向に分かれる。他のボキャブラリ、例えばＳＶＧの一つの頂点ノードもこれに従う。複雑な文書をこのように表現することは、文書を描写し、最終的に表示する方法を理解するのに有益である。【０１３２】  次に、文書を保持するための、対応するＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ９０３が生成される。ＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ９０３は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ９０４にアタッチされる。ＤＯＭツリーは、ルートノードと、ときには複数のセカンダリノードを含む。【０１３３】  一般に、このような文書は、テキスト及びグラフィクスの双方を含む。したがって、ＤＯＭツリーは、例えば、ＸＨＴＭＬサブツリーだけでなくＳＶＧサブツリーを有してもよい。ＸＨＴＭＬサブツリーは、ＸＨＴＭＬのＡｐｅｘＮｏｄｅ９０５を有する。同様に、ＳＶＧサブツリーは、ＳＶＧのＡｐｅｘＮｏｄｅ９０６を有する。【０１３４】  ステップ１では、ＡｐｅｘＮｏｄｅ９０６が、画面の論理的なレイアウトであるＰａｎｅ９０７にアタッチされる。ステップ２では、Ｐａｎｅ９０７は、ＰａｎｅＯｗｎｅｒ（ペインオーナー：ペインの所有者）９０８であるＣｏｒｅＣｏｍｐｏｎｅｎｔに、ＡｐｅｘＮｏｄｅ９０６のためのＺｏｎｅＦａｃｔｏｒｙを要求する。ステップ３では、ＰａｎｅＯｗｎｅｒ９０８は、ＺｏｎｅＦａｃｔｏｒｙと、ＡｐｅｘＮｏｄｅ９０６のためのＣａｎｖａｓＦａｃｔｏｒｙであるＥｄｉｔｌｅｔとを返す。【０１３５】  ステップ４では、Ｐａｎｅ９０７がＺｏｎｅ９０９を生成する。Ｚｏｎｅ９０９はＰａｎｅ９０７にアタッチされる。ステップ５では、Ｚｏｎｅ９０９がそれぞれのノードに対してＦａｃｅｔを生成し、対応するノードにアタッチする。ステップ６では、Ｐａｎｅ９０７がＣａｎｖａｓ９１０を生成する。Ｃａｎｖａｓ９１０はＰａｎｅ９０７にアタッチされる。Ｃａｎｖａｓ９１０には様々なＣｏｍｍａｎｄが含まれる。ステップ７では、Ｃａｎｖａｓ９１０が文書を画面にレンダリングするためのデータ構造を構築する。ＸＨＴＭＬの場合、これはボックスツリー構造を含む。【０１３６】  １．ＺｏｎｅのＭＶＣ
図９（ｂ）は、ＭＶＣパラダイムを用いてＺｏｎｅの構成の概要を示す。この場合、Ｚｏｎｅ及びＦａｃｅｔは文書に関連した入力であるから、モデル（Ｍ）はＺｏｎｅ及びＦａｃｅｔを含む。Ｃａｎｖａｓと、文書を画面にレンダリングするためのデータ構造体は、ユーザが画面上に見る出力であるから、ビュー（Ｖ）はＣａｎｖａｓ及びデータ構造体に対応する。Ｃｏｍｍａｎｄは、文書とその様々な関係に対して制御操作を実行するので、コントロール（Ｃ）はＣａｎｖａｓに含まれるＣｏｍｍａｎｄを含む。【０１３７】Ｋ．文書の表現
図１０を用いて、文書及びその様々な表現の例について以下に説明する。この例で使用される文書は、テキストと画像の双方を含む。テキストは、ＸＨＴＭＬを用いて表され、画像は、ＳＶＧを用いて表される。図１０は、文書のコンポーネント及び対応するオブジェクトの関係のＭＶＣ表現を詳細に示す。この例において、Ｄｏｃｕｍｅｎｔ１００１は、Ｄｏｃｕｍｅｎｔ１００１を保持するＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ１００２にアタッチされる。文書はＤＯＭツリー１００３により表現される。ＤＯＭツリーは、ＡｐｅｘＮｏｄｅ１００４を含む。【０１３８】  ＡｐｅｘＮｏｄｅは、黒丸で表される。頂点でないノードは、白丸で表される。ノードを編集するために用いられるＦａｃｅｔは、三角形で表され、対応するノードにアタッチされる。文書がテキストと画像を有するので、この文書のＤＯＭツリーは、ＸＨＴＭＬ部分とＳＶＧ部分を含む。ＡｐｅｘＮｏｄｅ１００４は、ＸＨＴＭＬサブツリーの最上のノードである。これは、文書のＸＨＴＭＬ部分の物理的な表現のための最上ＰａｎｅであるＸＨＴＭＬＰａｎｅ１００５にアタッチされる。ＡｐｅｘＮｏｄｅ１００４は、文書のＤＯＭツリーの一部であるＸＨＴＭＬＺｏｎｅ１００６にもアタッチされる。【０１３９】  Ｎｏｄｅ１００４に対応するＦａｃｅｔも、ＸＨＴＭＬＺｏｎｅ１００６にアタッチされる。ＸＨＴＭＬＺｏｎｅ１００６は、ＸＨＴＭＬＰａｎｅ１００５にアタッチされる。ＸＨＴＭＬＥｄｉｔｌｅｔは、文書の論理的な表現であるＸＨＴＭＬＣａｎｖａｓ１００７を生成する。ＸＨＴＭＬＣａｎｖａｓ１００７は、ＸＨＴＭＬＰａｎｅ１００５にアタッチされる。ＸＨＴＭＬＣａｎｖａｓ１００７は、Ｄｏｃｕｍｅｎｔ１００１のＸＨＴＭＬコンポーネントのためのＢｏｘＴｒｅｅ１００９を生成する。文書のＸＨＴＭＬ部分を保持し描画するために必要な様々なＣｏｍｍａｎｄ１００８も、ＸＨＴＭＬＣａｎｖａｓ１００５に追加される。【０１４０】  同様に、文書のＳＶＧサブツリーのＡｐｅｘＮｏｄｅ１０１０は、文書のＳＶＧコンポーネントを表現するＤｏｃｕｍｅｎｔのＤＯＭツリーの一部であるＳＶＧＺｏｎｅ１０１１にアタッチされる。ＡｐｅｘＮｏｄｅ１０１０は、文書のＳＶＧ部分の物理的な表現の最上のＰａｎｅであるＳＶＧＰａｎｅ１０１３にアタッチされる。文書のＳＶＧ部分の論理的な表現を表すＳＶＧＣａｎｖａｓ１０１２は、ＳＶＧＥｄｉｔｌｅｔにより生成され、ＳＶＧＰａｎｅ１０１３にアタッチされる。画面上に文書のＳＶＧ部分をレンダリングするためのデータ構造及びコマンドは、ＳＶＧＣａｎｖａｓにアタッチされる。例えば、このデータ構造は、図示されるように、円、線、長方形などを含んでもよい。【０１４１】  図１０に関連して説明された文書例の表現の一部について、図１１（ａ）、図１１（ｂ）に関連して、前述したＭＶＣパラダイムを用いて更に説明する。図１１（ａ）は、文書１００１のＸＨＴＭＬコンポーネントにおけるＭＶの関係を簡略化して示す。モデルは、Ｄｏｃｕｍｅｎｔ１００１のＸＨＴＭＬコンポーネントのためのＸＨＴＭＬＺｏｎｅ１１０３である。ＸＨＴＭＬＺｏｎｅのツリーには、いくつかのＮｏｄｅ及びそれらに対応するＦａｃｅｔが含ま���る。対応するＸＨＴＭＬＺｏｎｅ及びＰａｎｅは、ＭＶＣパラダイムのモデル（Ｍ）部分の一部である。ＭＶＣパラダイムのビュー（Ｖ）部分は、Ｄｏｃｕｍｅｎｔ１００１のＨＴＭＬコンポーネントの、対応するＸＨＴＭＬＣａｎｖａｓ１１０２及びＢｏｘＴｒｅｅである。文書のＸＨＴＭＬ部分は、Ｃａｎｖａｓと、それに含まれるＣｏｍｍａｎｄを使用して画面に描写される。キーボードやマウス入力などのイベントは、図示されるように、逆方向へ進む。【０１４２】  ＳｏｕｒｃｅＰａｎｅは、更なる機能、すなわち、ＤＯＭの保有者としての役割を有する。図１１（ｂ）は、図１１（ａ）に示したＤｏｃｕｍｅｎｔ１００１のコンポーネントに対するボキャブラリコネクションを提供する。ＤＯＭホルダーとして機能するＳｏｕｒｃｅＰａｎｅ１１０３は、文書のソースＤＯＭツリーを含む。ＣｏｎｎｅｃｔｏｒＴｒｅｅは、ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙにより生成され、デスティネーションＤＯＭの保有者としても機能するＤｅｓｔｉｎａｔｉｏｎＰａｎｅ１１０５を生成する。ＤｅｓｔｉｎａｔｉｏｎＰａｎｅ１１０５は、ＸＨＴＭＬＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓ１１０６としてボックスツリーの形式でレイアウトされる。【０１４３】Ｌ．プラグインサブシステム、ボキャブラリコネクション、及びコネクタの関係
図１２（ａ）−（ｃ）は、それぞれ、プラグインサブシステム、ボキャブラリコネクション、及びＣｏｎｎｅｃｔｏｒに関連する更なる詳細を示す。プラグインサブシステムは、文書処理システムに機能を追加又は交換するために用いられる。プラグインサブシステムは、ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１を含む。図１２（ａ）で示すように、「Ｍｙ  Ｏｗｎ  ＸＭＬ  ｖｏｃａｂｕｌａｒｙ」はＶｃＢａｓｅＰｌｕｇＩｎとして提供され、そのプラグインには、ＭｙＯｗｎＸＭＬＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙＴｒｅｅ及びボキャブラリ（ＺｏｎｅＦａｃｔｏｒｙＢｕｉｌｄｅｒ）を含む。ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１にアタッチされるＺｏｎｅＦａｃｔｏｒｙＳｅｒｖｉｃｅ１２０１は、文書の一部に対するＺｏｎｅを生成する。ＥｄｉｔｌｅｔＳｅｒｖｉｃｅ１２０２も、ＳｅｒｖｉｃｅＢｒｏｋｅｒにアタッチされる。ＥｄｉｔｌｅｔＳｅｒｖｉｃｅ１２０２は、Ｚｏｎｅ中のＮｏｄｅに対応するＣａｎｖａｓを生成する。【０１４４】  ＺｏｎｅＦａｃｔｏｒｙの例は、ＸＨＴＭＬＺｏｎｅ及びＳＶＧＺｏｎｅをそれぞれ生成するＸＨＴＭＬＺｏｎｅＦａｃｔｏｒｙ１２１１及びＳＶＧＺｏｎｅＦａｃｔｏｒｙ１２１２である。文書例に関連して前述したように、文書のテキストコンポーネントは、ＸＨＴＭＬＺｏｎｅを生成することにより表現されてもよいし、画像はＳＶＧＺｏｎｅを用いて表現されてもよい。ＥｄｉｔｌｅｔＳｅｒｖｉｃｅの例は、ＸＨＴＭＬＥｄｉｔｌｅｔ１２２１及びＳＶＧＥｄｉｔｌｅｔ１２２２を含む。【０１４５】  図１２（ｂ）は、ボキャブラリコネクションに関連する更なる詳細を示す。ボキャブラリコネクションは、前述したように、文書処理システムの重要な特徴であり、２つの異なる方法で文書の整合のとれた表現及び表示を可能とする。ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３を保持するＶＣＭａｎａｇｅｒ３０２は、ボキャブラリコネクションサブシステムの一部である。図１２（ｃ）で示すように、ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３は、文書のＣｏｎｎｅｃｔｏｒ３０４を生成する。前述したように、Ｃｏｎｎｅｃｔｏｒは、ソースＤＯＭ中のノードを監視し、２つの表現の間の整合性を維持するために、デスティネーションＤＯＭ中のノードを修正する。【０１４６】  Ｔｅｍｐｌａｔｅ３１７は、いくつかのノードの変換ルールを表す。ボキャブラリコネクション記述子（ＶＣＤ）ファイルは、特定のパス又はルールを満たす要素又は要素の集合を他の要素に変換するいくつかのルールを表すＴｅｍｐｌａｔｅのリストである。Ｔｅｍｐｌａｔｅ３１７及びＣｏｍｍａｎｄＴｅｍｐｌａｔｅ３１３１は、全てＶＣＭａｎａｇｅｒ３０２にアタッチされる。ＶＣＭａｎａｇｅｒは、ＶＣＤファイル中の全てのセクションを管理するオブジェクトである。１つのＶＣＤファイルに対して、１つのＶＣＭａｎａｇｅｒオブジェクトが生成される。【０１４７】  図１２（ｃ）は、Ｃｏｎｎｅｃｔｏｒに関連する更なる詳細を提供する。ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３は、ソース文書からＣｏｎｎｅｃｔｏｒを生成する。ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３は、Ｖｏｃａｂｕｌａｒｙ、Ｔｅｍｐｌａｔｅ、及びＥｌｅｍｅｎｔＴｅｍｐ���ａｔｅにアタッチされ、それぞれ、ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｏｒ、ＴｅｍｐｌａｔｅＣｏｎｎｅｃｔｏｒ、ＥｌｅｍｅｎｔＣｏｎｎｅｃｔｏｒを生成ずる。【０１４８】  ＶＣＭａｎａｇｅｒ３０２は、ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３を保持する。Ｖｏｃａｂｕｌａｒｙを生成するために、対応するＶＣＤファイルが読み込まれる。こうして、ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３が生成される。このＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３は、Ｚｏｎｅを生成するＺｏｎｅＦａｃｔｏｒｙ及びＣａｎｖａｓを生成するＥｄｉｔｌｅｔに関連する。【０１４９】  つづいて、ターゲットボキャブラリのＥｄｉｔｌｅｔＳｅｒｖｉｃｅが、ＶＣＣａｎｖａｓを生成する。ＶＣＣａｎｖａｓも、ソースＤＯＭツリー又はＺｏｎｅにおけるＡｐｅｘＮｏｄｅのＣｏｎｎｅｃｔｏｒを生成する。必要に応じて、子のＣｏｎｎｅｃｔｏｒが再帰的に生成される。ＣｏｎｎｅｃｔｏｒＴｒｅｅは、ＶＣＤファイル中のテンプレートの集合により生成される。【０１５０】  テンプレートは、マークアップ言語の要素を他の要素に変換するためのルールの集合である。例えば、各テンプレートは、ソースＤＯＭツリー又はＺｏｎｅにマッチされる。適切にマッチした場合には、頂点Ｃｏｎｎｅｃｔｏｒが生成される。例えば、テンプレート「Ａ／＊／Ｄ」は、間にどんなノードがあるかに関係なく、ノードＡで始まりノードＤで終わる全ての枝に合致する。同様に、「／／Ｂ」は、ルートからの全ての「Ｂ」ノードに一致する。【０１５１】Ｍ．ＣｏｎｎｅｃｔｏｒＴｒｅｅに関係するＶＣＤファイルの例
特定の文書と関係する処理を説明する例を続ける。ドキュメントタイトルのある「ＭｙＳａｍｐｌｅＸＭＬ」というタイトルの文書が文書処理システムにロードされる。図１３は、「ＭｙＳａｍｐｌｅＸＭＬ」ファイルのための、ＶＣＭａｎａｇｅｒ及びＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙＴｒｅｅを用いたＶＣＤスクリプトの例を示す。スクリプトファイル中のボキャブラリセクション、テンプレートセクションと、ＶＣＭａｎａｇｅｒにおける対応するコンポーネントが示される。タグ「ｖｃｄ：ｖｏｃａｂｕｌａｒｙ」において、属性「ｍａｔｃｈ」は「ｓａｍｐｌｅ：ｒｏｏｔ」、「ｌａｂｅｌ」は「ＭｙＳａｍｐｌｅＸＭＬ」、「ｃａｌｌ−ｔｅｍｐｌａｔｅ」は「ｓａｍｐｌｅ  ｔｅｍｐｌａｔｅ」となっている。【０１５２】  この例では、Ｖｏｃａｂｕｌａｒｙは、「ＭｙＳａｍｐｌｅＸＭＬ」のＶＣＭａｎａｇｅｒにおいて「ｓａｍｐｌｅ：ｒｏｏｔ」として頂点要素を含む。対応するＵＩラベルは、「ＭｙＳａｍｐｌｅＸＭＬ」である。テンプレートセクションにおいて、タグは「ｖｃｄ：ｔｅｍｐｌａｔｅ」であり、名前は「ｓａｍｐｌｅ：ｔｅｍｐｌａｔｅ」である。【０１５３】Ｎ．ファイルがシステムにロードされる方法の詳細な例
図１４−１８は、文書「ＭｙＳａｍｐｌｅＸＭＬ」のロードについての詳細な記述を示す。図１４（ａ）に示されるステップ１では、文書がストレージ１４０５からロードされる。ＤＯＭＳｅｒｖｉｃｅは、ＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ１４０１と対応するＤＯＭツリー及びＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１４０６を生成する。ＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ１４０１は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１４０６にアタッチされる。文書は、ＸＨＴＭＬ及びＭｙＳａｍｐｌｅＸＭＬのサブツリーを含む。ＸＨＴＭＬのＡｐｅｘＮｏｄｅ１４０３は、タグ「ｘｈｔｍｌ：ｈｔｍｌ」が付されたＸＨＴＭＬの最上のノードである。「ＭｙＳａｍｐｌｅＸＭＬ」のＡｐｅｘＮｏｄｅ１４０４は、タグ「ｓａｍｐｌｅ：ｒｏｏｔ」が付された「ＭｙＳａｍｐｌｅＸＭＬ」の最上ノードである。【０１５４】  図１４（ｂ）に示されるステップ２では、ＲｏｏｔＰａｎｅが文書のＸＨＴＭＬＺｏｎｅ、Ｆａｃｅｔ、及びＣａｎｖａｓを生成する。Ｐａｎｅ１４０７、ＸＨＴＭＬＺｏｎｅ１４０８、ＸＨＴＭＬＣａｎｖａｓ１４０９、及びＢｏｘＴｒｅｅ１４１０が、ＡｐｅｘＮｏｄｅ１４０３に対応して生成される。【０１５５】  図１４（ｃ）に示されるステップ３では、ＸＨＴＭＬＺｏｎｅが知らないタグ「ｓａｍｐｌｅ：ｒｏｏｔ」を発見し、ＨＴＭＬＣａｎｖａｓの領域からＳｕｂＰａｎｅを生成する。【０１５６】  図１５に示されるステップ４では、ＳｕｂＰａｎｅが「ｓａｍｐｌｅ：ｒｏｏｔ」を扱うことができ、適切なＺｏｎｅを生成可能なＺｏｎｅＦａｃｔｏｒｙを得る。このＺｏｎｅＦａｃｔｏｒｙは、ＺｏｎｅＦａｃｔｏｒｙを実行可能なＶｏｃａｂｕｌａｒｙ内にある。それは、「ＭｙＳａｍｐｌｅＸＭＬ」のＶｏｃａｂｕｌａｒｙＳｅｃｔｉｏｎの内容を含む。【０１５７】  図１６に示されるステップ５では、「ＭｙＳａｍｐｌｅＸＭＬ」に対応するＶｏｃａｂｕｌａｒｙがＤｅｆａｕｌｔＺｏｎｅ１６０１を生成する。対応するＥｄｉｔｌｅｔが生成され、対応するＣａｎｖａｓを生成するためにＳｕｂＰａｎｅ１５０１が提供される。Ｅｄｉｔｌｅｔは、ＶＣＣａｎｖａｓを生成する。そして、それはＴｅｍｐｌａｔｅＳｅｃｔｉｏｎを呼ぶ。ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙＴｒｅｅも含まれている。ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙＴｒｅｅは、ＣｏｎｎｅｃｔｏｒＴｒｅｅとなる全てのＣｏｎｎｅｃｔｏｒを生成する。文書のＸＨＴＭＬコンテンツに関係するＡｐｅｘＮｏｄｅに対するＢｏｘＴｒｅｅとＸＨＴＭＬＣａｎｖａｓ同様に、ＲｏｏｔＰａｎｅとＸＨＴＭＬＺｏｎｅとの関係も前述の内容からすぐに理解されよう。【０１５８】  図１７（ａ）に示されるステップ６では、ソースＤＯＭツリー間の対応をもとに、各ＣｏｎｎｅｃｔｏｒがデスティネーションＤＯＭオブジェクトを生成する。コネクタのうちのいくつかはｘｐａｔｈ情報を含んでいる。ｘｐａｔｈ情報は、変更／修正を監視する必要のあるソースＤＯＭツリーの部分集合を決定するために使用される１以上のｘｐａｔｈ表現を含む。【０１５９】  図１７（ｂ）に示されるステップ７では、ソース・ＶＣ・ディスティネーションの関係に従って、ボキャブラリは、ソースＤＯＭのペインからデスティネーションＤＯＭツリーのＤｅｓｔｉｎａｔｉｏｎＰａｎｅを作成する。これは、ＳｏｕｒｃｅＰａｎｅに基づいてなされる。デスティネーションツリーのＡｐｅｘＮｏｄｅは、ＤｅｓｔｉｎａｔｉｏｎＰａｎｅ及び対応するＺｏｎｅにアタッチされる。ＤｅｓｔｉｎａｔｉｏｎＰａｎｅは、ＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓを生成し、文書をデスティネーションのフォーマットでレンダリングするためのデータ構造及びコマンドを構築する、自身のＥｄｉｔｌｅｔを提供される。【０１６０】  図１８（ａ）は、対応するソースノードを持たず、デスティネーションツリーにのみ存在するノード上でイベントが発生したときのフローを示す。マウスイベント、キーボードイベントなど、Ｃａｎｖａｓが取得したイベントは、デスティネーションツリーを通過して、ＥｌｅｍｅｎｔＴｅｍｐｌａｔｅＣｏｎｎｅｃｔｏｒに伝達される。ＥｌｅｍｅｎｔＴｅｍｐｌａｔｅＣｏｎｎｅｃｔｏｒは対応するソースノードを持たないので、伝達されたイベントはソースノードに対する編集操作ではない。ＥｌｅｍｅｎｔＴｅｍｐｌａｔｅＣｏｎｎｅｃｔｏｒは、伝達されたイベントがＣｏｍｍａｎｄＴｅｍｐｌａｔｅに記述されたコマンドに合致すれば、それに対応するＡｃｔｉｏｎを実行する。合致するコマンドがなければ、ＥｌｅｍｅｎｔＴｅｍｐｌａｔｅＣｏｎｎｅｃｔｏｒは、伝達されたイベントを無視する。【０１６１】  図１８（ｂ）は、ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒによりソースノードに対応づけられているデスティネーションツリーのノード上でイベントが発生したときのフローを示す。ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒは、ソースＤＯＭツリーのＸＰａｔｈで指定されたノードからテキストノードを取得して、デスティネーションＤＯＭツリーのノードにマッピングする。マウスイベント、キーボードイベントなど、Ｃａｎｖａｓが取得したイベントは、デスティネーションツリーを通過して、ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒに伝達される。ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒは、伝達されたイベントを、対応するソースノードの編集コマンドにマッピングし、Ｑｕｅｕｅ１０５３に積む。編集コマンドは、Ｆａｃｅｔを介して実行されるＤＯＭのＡＰＩコールの集合である。キューに積まれたコマンドが実行されると、ソースノードが編集される。ソースノードが編集されると、ミューテーションイベントが発行され、リスナーとして登録されたＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒにソースノードの変更が通知される。ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒは、ソースノードの変更を、対応するデスティネーションノードに反映させるように、デスティネーションツリーを再構築する。このとき、ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒを含むテンプレートに、「ｆｏｒ  ｅａｃｈ」や「ｆｏｒ  ｌｏｏｐ」などの制御文が含まれている場合、ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙがこの制御文を再評価し、ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒを再構築した後、デスティネーションツリーが再構築される。【０１６２】（変更を伝達する方法の詳細）
ＸＭＬ文書などの文書は、コンピュータアプリケーションにおいて、一般的にはＤＯＭツリーとして保持される。図１０は、ＸＭＬ文書の一部を表現するＤＯＭツリー１００３を含む。ここでは、一例としてＤＯＭツリーを用いて開示される技術について説明するが、本字靴は、ツリー又はグラフとして表現可能な任意の情報について適用可能である。【０１６３】  図２０は、ここで開示される技術を実現するための方法の一例であるボキャブラリコネクションを示す。文書の一部は、ソースＤＯＭツリーとして表現される。ソースＤＯＭツリー２００１は、別の表現に変換する前のＤＯＭツリーである。ソースＤＯＭツリー中のノード２００１１−２００１ｎはソースノードであり、ソースＤＯＭツリー中の要素はソース要素である。【０１６４】  ゾーン（Ｚｏｎｅ）は、プラグインにより処理可能なＤＯＭツリーの一部である。特定のゾーンに対してデスティネーションＤＯＭツリー２００３が生成される。デスティネーションツリーのノード及び要素は、デスティネーションノード及びデスティネーション要素と呼ばれる。【０１６５】  ソースノードとデスティネーションノードは、コネクタを用いて接続される。コネクタツリー２００２は、複数のコネクタのツリーである。コネクタツリーは、コネクタファクトリを用いて生成されてもよい。コネクタは、ｃｏｎｎｅｃｔＸｐａｔｈの機能であるｘｐａｔｈを用いてソースノードを監視する。ｘｐａｔｈは、テンプレートを用いてソースノードを監視する。【０１６６】  例えば、テンプレート「Ａ／＊／Ｄ」は、間のノードが何であるかに関わらず、ノード「Ａ」で始まり、ノード「Ｄ」で終わるツリーの全ての枝を監視する。同様に、「／／Ｂ」は、ルートからの全てのノード「Ｂ」に対応する。【０１６７】  代替の表現は、デスティネーションＤＯＭツリーであってもよい。【０１６８】  ＤＯＭツリーの部分集合は、テンプレートを用いて監視される。ＤＯＭツリーの監視された部分集合が変更される。ＤＯＭツリーの表現は、監視された部分集合における変更を反映するために自動的に更新される。【０１６９】  ｃｏｎｎｅｃｔＸｐａｔｈにより監視されたノードの集合内のノードに変更が生じたとき、ＤＯＭ構造内のミューテーションイベントのリスナーがこれを受信する。ミューテーションイベントリスナーは、ミューテーションイベントを送信する。ｃｏｎｎｅｃｔＸｐａｔｈは、このミューテーションイベントを取得する。ｃｏｎｎｅｃｔＸｐａｔｈは、ミューテーションイベントを評価する。監視されたノードに変更が生じると、値の変更を受信する機能、例えばＶａｌｕｅＣｈａｎｇｅＬｉｓｔｎｅｒｓが通知される。監視されたノードに影響を与える他のノードが存在する場合、これらのノードもリスナーに提供される。ＶａｌｕｅＣｈａｎｇｅＬｉｓｔｅｎｅｒｓは、監視されたノードに対する変更を受信し、それに応じて動作するリスナーである。【０１７０】  図２１は、ｃｏｎｎｅｃｔＸｐａｔｈがＶＣとともに用いられた実施例を示す。ＶＣＤは、ルートからそれぞれの「Ｂ」ノードに対して「ＤＩＶ」セクションを生成するように記述される。この場合、ｃｏｎｎｅｃｔＸｐａｔｈは、テンプレート「／／Ｂ」のパスを充足する��てのノードを監視する。図から分かるように、実際のＤＯＭには、２つの「Ｂ」ノード２０１２、２１０２がある。マッピングされ、画面に表示されるＤＯｍツリーは、２つの「ＤＩＶ」セクションからなる。編集中のＤＯＭに、更に「Ｂ」ノード２１０３が追加される。【０１７１】  ｃｏｎｎｅｃｔＸｐａｔｈの別の実施例は、メニューで用いられる。メニューで用いられない項目はグレイアウトされる。ここで開示されるｃｏｎｎｅｃｔＸｐａｔｈの特徴及び技術が、この特徴を実現する。ｘｐａｔｈ及びテンプレートを用いて監視されるノードは、キャレットの位置である。カーソルの移動が監視される。カーソルが新しい位置へ移動すると、実行可能なコマンドにマップされた位置にあるときにのみ評価が発生する。【０１７２】  一般に、適切なミューテーションイベントのみが実行されるように、文書の特定の部分が監視され、抽出される。【０１７３】  別の実施例は、ＣＳＳセレクタ（ＣＳＳのＷ３Ｃ定義）を用いる。ＣＳＳが変更されると、ＣＳＳの変更によりレンダリングが影響される文書の一部が変更され、その他の部分は全てそのまま変更されない。【０１７４】  更に別の実施例は、関係性データベースの関係に用いられるツリー構造に関する。ツリーは、人々の関係、論文の関連文献、協力構造などを表現するために用いられる。ツリーの構造に変更が生じた場合、内容が変更された全ての文書に変更が伝達される。例えば、変更に対して承認が必要な人に文書が送信されてもよい。【０１７５】  ウェブの関係では、ページの移動及びそれらのリンクを監視することができる。【０１７６】  更に別の実施例では、疾患の副作用や治療法などが監視される。【０１７７】  更に別の実施例では、電子機器の設計図の関係がツリー形式で表現される。ツリーのノードに対する変更が監視され、電子機器を使用する全ての製品に変更が伝達される。【０１７８】  本発明の他の改良や変更は、上記の開示及び教示から当業者には明らかである。したがって、本発明の特定の実施例のみをとくに例示したが、本発明の趣旨及び範囲から逸脱することなく、それらに種々の変更が可能であることは明らかである。
【図面の簡単な説明】
【０１７９】
【図１（ａ）】開示した文書処理システムの典型的な実装の基本となるコンポーネントの標準的な配置を示す図である。
【図１（ｂ）】典型的な文書処理システムの全体的なブロック図である。
【図１（ｃ）】典型的な文書処理システムの全体的なブロック図である。
【図２】「Ｄｏｃｕｍｅｎｔ  Ｍａｎａｇｅｒ」の典型的な実装について詳細を示す図である。
【図３】「Ｖｏｃａｂｕｌａｒｙ  Ｃｏｎｎｅｃｔｉｏｎ」サブシステム３００の典型的な実装について詳細を示す図である。
【図４】図４（ａ）は、「Ｐｒｏｇｒａｍ  Ｉｎｖｏｋｅｒ」及びそれに関連する他のコンポーネントの典型的な実装について詳細を示す図であり、図４（ｂ）は、「Ｓｅｒｖｉｃｅ  Ｂｒｏｋｅｒ」及びそれに関連する他のコンポーネントの典型的な実装について詳細を示す図であり、図４（ｃ）は、「Ｓｅｒｖｉｃｅ」の典型的な実装について詳細を示す図であり、図４（ｄ）は、「Ｓｅｒｖｉｃｅ」の例を示す図であり、図４（ｅ）は、「Ｐｒｏｇｒａｍ  Ｉｎｖｏｋｅｒ」１０３と「ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ」１０６との関係について詳細を示す図である。
【図５】図５（ａ）は、「Ｐｒｏｇｒａｍ  Ｉｎｖｏｋｅｒ」上に展開される「Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｉｃｅ」の構造について詳細を示す図であり、図５（ｂ）は、「Ｆｒａｍｅ」、「ＭｅｎｕＢａｒ」、「ＳｔａｔｕｓＢａｒ」の関係の例を示す図であり、
【図６】図６（ａ）は、「Ａｐｐｌｉｃａｔｉｏｎ  Ｃｏｒｅ」の典型的な実装について詳細を示す図であり、図６（ｂ）は、「Ｓｎａｐ  Ｓｈｏｔ」の典型的な実装について詳細を示す図である。
【図７】図７（ａ）は、「Ａｐｐｌｉｃａｔｉｏｎ  Ｃｏｒｅ」の典型的な実装について詳細を示す図であり、図７（ｂ）は、ＡからＥの「Ｄｏｃｕｍｅｎｔ」の組がどのように階層化されるのかの例を示す図であり、図７（ｃ）は、図７（ｂ）で示した「Ｄｏｃｕｍｅｎｔ」の階層がスクリーン上でどのように見えるのかの例を示す図である。
【図８】「Ｕｎｄｏ  Ｆｒａｍｅｗｏｒｋ」及び「Ｕｎｄｏ  Ｃｏｍｍａｎｄ」の典型的な実装の詳細を示す図である。
【図９】図９（ａ）は、図１（ｂ）、図１（ｃ）で示す文書処理システム内に「Ｄｏｃｕｍｅｎｔ」がどのように展開されるかの全体像を示す図であり、図９（ｂ）は、ＭＶＣパラダイムを使って、「Ｚｏｎｅ」の構造の概要を示す図である。
【図１０】本発明に従って、「Ｄｏｃｕｍｅｎｔ」とその様々な表現の例を示す図である。
【図１１】図１１（ａ）は、図１０で示す「Ｄｏｃｕｍｅｎｔ」のＸＨＴＭＬコンポーネントに対する「ＭＶ」関係の概要を示す図であり、図１１（ｂ）は、図１１（ａ）で示す「Ｄｏｃｕｍｅｎｔ」に対するボキャブラリコネクションを示す図である。
【図１２】プラグインサブシステム、ボキャブラリコネクション、コネクタそれぞれの典型的な実装について詳細を示す図である。
【図１３】ＭｙＳａｍｐｌｅＸＭＬに対して、ボキャブラリコネクションマネージャとコネクタファクトリーツリーを使用するＶＣＤスクリプトの例を示す図である。
【図１４】図１（ｂ）の典型的な文書処理システムの中に、文書例ＭｙＳａｍｐｌｅＸＭＬが展開されるステップ０から３を示した図である。
【図１５】図１（ｂ）の典型的な文書処理システムの中に、文書例ＭｙＳａｍｐｌｅＸＭＬが展開されるステップ４を示した図である。
【図１６】図１（ｂ）の典型的な文書処理システムの中に、文書例ＭｙＳａｍｐｌｅＸＭＬが展開されるステップ５を示した図である。
【図１７】図１（ｂ）の典型的な文書処理システムの中に、文書例ＭｙＳａｍｐｌｅＸＭＬが展開されるステップ６を示した図である。
【図１８】図１（ｂ）の典型的な文書処理システムの中に、文書例ＭｙＳａｍｐｌｅＸＭＬが展開されるステップ７を示した図である。
【図１９】図１９（ａ）は、対応するソースノードを持たず、ディスティネーションツリーのみに依存するノードで発生するイベントのフローを示す図であり、図１９（ｂ）は、「ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒ」によりソースノードと連動するディスティネーションツリーのノードで発生するイベントのフローを示す図である。
【図２０】ボキャブラリコネクションの実施例を示す図である。
【図２１】変更が伝達される例を示す図である。
【符号の説明】
【０１８０】  ２００１  ソースＤＯＭツリー、２００２  コネクタツリー、２００３  デスティネーションＤＯＭツリー、２１０１，２１０２，２１０３  ノード。
【図１（ａ）】
2008508644.tif 000003
【図１（ｂ）】
2008508644.tif 000004
【図１（ｃ）】
2008508644.tif 000005
【図２】
2008508644.tif 000006
【図３】
2008508644.tif 000007
【図４】
2008508644.tif 000008
【図５】
2008508644.tif 000009
【図６】
2008508644.tif 000010
【図７】
2008508644.tif 000011
【図８】
2008508644.tif 000012
【図９】
2008508644.tif 000013
【図１０】
2008508644.tif 000014
【図１１】
2008508644.tif 000015
【図１２】
2008508644.tif 000016
【図１３】
2008508644.tif 000017
【図１４】
2008508644.tif 000018
【図１５】
2008508644.tif 000019
【図１６】
2008508644.tif 000020
【図１７】
2008508644.tif 000021
【図１８】
2008508644.tif 000022
【図１９】
2008508644.tif 000023
【図２０】
2008508644.tif 000024
【図２１】
2008508644.tif 000025
【手続補正書】
【提出日】平成19年9月27日(2007.9.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
文書中の変更を伝達する機能をコンピュータに実現させるためのコンピュータプログラムであって、
前記文書の少なくとも一部のソース表現を生成する機能と、
前記ソース表現に対応するデスティネーション表現を生成する機能と
前記文書の前記ソース表現に対する変更を監視する機能と、
前記文書の前記ソース表現に変更を加える機能と、
前記文書の前記デスティネーション表現に前記変更を自動的に伝達する機能と、
を備えることを特徴とするコンピュータプログラム。
【請求項２】
前記ソース表現は、第１のＤＯＭツリーであることを特徴とする請求項１に記載のコンピュータプログラム。
【請求項３】
前記デスティネーション表現は、第２のＤＯＭツリーであることを特徴とする請求項１又は２に記載のコンピュータプログラム。
【請求項４】
前記監視する機能は、接続機構によりなされることを特徴とする請求項１から３のいずれかに記載のコンピュータプログラム。
【請求項５】
ミューテーションイベントリスナーが前記第１のＤＯＭツリーを監視することを特徴とする請求項１から４のいずれかに記載のコンピュータプログラム。
【請求項６】
前記ミューテーションイベントリスナーは、前記第１のＤＯＭツリーに変更が生じたときに、ミューテーションイベントを受信することを特徴とする請求項５に記載のコンピュータプログラム。
【請求項７】
前記接続機構は、前記第１のＤＯＭツリーのノードを監視する機能を含むことを特徴とする請求項４に記載のコンピュータプログラム。
【請求項８】
前記ミューテーションイベントは、更新が必要な前記第２の表現のノードに更新を送信することを特徴とする請求項６に記載のコンピュータプログラム。
【請求項９】
前記第１のＤＯＭツリーの、監視されるべきそれぞれの部分集合は、前記接続機構において対応するテンプレートを有することを特徴とする請求項４に記載のコンピュータプログラム。
【請求項１０】
前記テンプレートは、前記第１のＤＯＭツリーの部分集合にマッチすることが可能であることを特徴とする請求項９に記載のコンピュータプログラム。
【請求項１１】
文書中の変更を伝達するための装置であって、
前記文書の少なくとも一部のソース表現を生成する手段と、
前記ソース表現に対応するデスティネーション表現を生成する手段と
前記文書の前記ソース表現に対する変更を監視する手段と、
前記文書の前記ソース表現に変更を加える手段と、
前記文書の前記デスティネーション表現に前記変更を自動的に伝達する手段と、
を備えることを特徴とする装置。
【請求項１２】
ＤＯＭツリーから変更を伝達する方法であって、
テンプレートにマッチするＤＯＭツリーの部分集合を監視する工程と、
前記ＤＯＭツリーの監視された部分集合に変更を加える工程と、
前記監視された部分集合における変更を反映するために前記ＤＯＭツリーの表現を自動的に更新する工程と、
を備えることを特徴とする方法。
【請求項１３】
変更を伝達するためのシステムであって、
第１のＤＯＭツリーと、
前記第１のＤＯＭツリーにマップされた表現と、を備え、
前記第１のＤＯＭツリーに対する変更は、前記表現に自動的に伝達されることを特徴とするシステム。
【請求項１４】
文書のソース表現と、
文書のデスティネーション表現と、を備え、
前記文書の前記ソース表現に対する変更は、前記文書の前記デスティネーション表現に自動的に伝達されることを特徴とする文書管理システム。
【手続補正２】
【補正対象書類名】図面
【補正対象項目名】図２０
【補正方法】変更
【補正の内容】
【図２０】
2008508644.tif 000026
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】図２１
【補正方法】変更
【補正の内容】
【図２１】
2008508644.tif 000027
【国際調査報告】
2008508644.tif 000028