文書のある表現における変更を別の表現に反映させるための文書処理及び管理方法
少なくともルート要素及び宣言を有する新規のＸＭＬ文書を生成する方法である。この方法は、ルート要素を有する新規のＸＭＬファイルのための少なくとも１つのＸＭＬテンプレートを備える新規フラグメントＸＭＬ文書をストレージから検索する工程を含む。少なくとも１つのＸＭＬテンプレートが選択され、選択されたＸＭＬテンプレートがＸＭＬ文書を生成するために用いられる。ユーザ及びプログラマのインタフェースや、この方法を実現可能な装置及びシステムの構造も提供される。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、情報のある形式の表現における変更を、同じ情報の別の形式の表現に自動的に伝達する技術を開示する。とくに、本技術は、ソースＤＯＭツリーにより表現された文書に対する変更を、別の表現に描写されたデスティネーションＤＯＭツリーへ自動的に伝達することに関する。
【背景技術】
【０００２】
この出願は、「文書処理及び文書管理システム」という名称で、２００４年８月２日に出願され、同時継続している米国仮出願（出願番号６０／５９２，３６９）からの優先権を主張する。
【０００３】
インターネットの出現により、ユーザによって処理され管理される文書の数が、ほぼ指数関数的に増加してきた。インターネットの核を形成するウェブ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）は、そのような文書データの大きな受け皿となっている。ウェブは、文書に加えて、このような文書の情報検索システムを提供する。これらの文書は、通常、マークアップ言語により記述される。マークアップ言語のシンプルかつポピュラーな例の一つにＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）がある。このような文書は、ウェブの他の位置に格納されている他の文書へのリンクをさらに含む。ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）は、さらに高度でポピュラーなマークアップ言語である。ウェブ文書にアクセスし、閲覧するためのシンプルなブラウザが、Ｊａｖａ（登録商標）のようなオブジェクト指向のプログラミング言語で開発されている。
【０００４】
マークアップ言語により記述された文書は、通常、ブラウザや他のアプリケーションの中では、ツリーデータ構造の形で表現される。この構造は、文書を構文解析した結果のツリーに相当する。ＤＯＭ（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）は、文書を表現し、操作するために使用される、よく知られたツリーベースのデータ構造モデルである。ＤＯＭは、ＨＴＭＬやＸＭＬ文書などを含む文書を表現するための標準的なオブジェクトのセットを提供する。ＤＯＭは、文書内のコンポーネントを表現するオブジェクトがどのようにつながっているかという標準モデルと、それらのオブジェクトにアクセスしたり操作したりするための標準インタフェイスという、２つの基本的なコンポーネントを含む。
【０００５】
アプリケーション開発者は、独自のデータ構造やＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）へのインタフェイスとしてＤＯＭをサポートすることができる。他方、文書を作成するアプリケーション開発者は、彼らのＡＰＩの独自インタフェイスではなく、ＤＯＭの標準インタフェイスを使用することができる。したがって、標準を提供するというその能力により、ＤＯＭは、様々な環境、特にウェブにおいて、文書の相互利用を促進させるために有効である。ＤＯＭのいくつかのバージョンが定義されており、異なるプログラミング環境及びアプリケーションによって使用されている。
【０００６】
ＤＯＭツリーは、対応するＤＯＭの内容に基づいた文書の階層的表現である。ＤＯＭツリーは「根（ルート）」、及びルートから発生する１つ以上の「節（ノード）」を含む。ルートが文書全体を表す場合もある。中間のノードは、例えば、テーブル及びそのテーブル中の行及び列のような要素を表すことができる。ＤＯＭツリーの「葉」は、通常、それ以上分解できないテキストや画像のようなデータを表す。ＤＯＭツリーの各ノードは、フォント、サイズ、色、インデントなど、ノードによって表される要素のパラメータを記述する属性に関連付けられてもよい。
【０００７】
ＨＴＭＬは、文書を作成するために一般に用いられる言語であるが、フォーマット及びレイアウト用の言語であり、データ記述のための言語ではない。ＨＴＭＬドキュメントを表現するＤＯＭツリーのノードは、ＨＴＭＬのフォーマッティングタグとして予め定義されたエレメントであって、通常、ＨＴＭＬは、データの詳述や、データのタギング／ラベリングのための機能を提供しないので、ＨＴＭＬドキュメント中のデータに対するクエリを定式化することは多くの場合困難である。
【０００８】
ネットワーク設計者たちの目指すものは、ウェブ上の文書がソフトウェアアプリケーションによってクエリされたり処理されたりできるようにすることである。表示方法とは無関係で、階層的に構造化された言語であれば、そのようにクエリされ処理されることができる。ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）のようなマークアップ言語は、これらの機能を提供することができる。
【０００９】
ＨＴＭＬとは逆に、ＸＭＬのよく知られた利点は、文書の設計者が自由に定義可能な「タグ」を使用して、データ要素にラベルを付けることが可能である点である。このようなデータ要素は、階層的に構造化することができる。さらに、ＸＭＬ文書は、文書内で用いられるタグ及びそれらの相互関係の「文法」を記述した文書型定義を含むことができる。構造化されたＸＭＬ文書の表示方法を定義するために、ＣＳＳ（Ｃａｓｃａｄｉｎｇ Ｓｔｙｌｅ Ｓｈｅｅｔ）又はＸＳＬ（ＸＭＬ Ｓｔｙｌｅ Ｌａｎｇｕａｇｅ）が使用される。ＤＯＭ、ＨＴＭＬ、ＸＭＬ、ＣＳＳ、ＸＳＬ及び関連する言語の特徴に関する付加的な情報は、ウェブからも得ることができる。（例えば、ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／）
【００１０】
Ｘｐａｔｈは、ＸＭＬ文書の部分の位置を指定するために共通のシンタックス及びセマンティクスを提供する。機能性の例として、ＸＭＬ文書に対応するＤＯＭツリーのトラバース（移動）がある。それは、ＸＭＬ文書の様々な表現に関連した文字列、数、及びブーリアン文字の操作のための基本的な機能を提供する。Ｘｐａｔｈは、ＸＭＬ文書の見た目のシンタックス、例えば、テキストとしてみたときに何行目であるとか何文字目であるとかといった文法ではなく、ＤＯＭツリーなどの抽象的・論理的な構造において動作する。Ｘｐａｔｈを使用することにより、例えばＸＭＬ文書のＤＯＭツリー内の階層的構造を通じて場所を指定することができる。アドレシングのための使用の他に、Ｘｐａｔｈは、ＤＯＭツリー中のノードがパターンにマッチするか否かをテストするために使用されるようにも設計されている。
【００１１】
ＸＰａｔｈに関する更なる詳細は、ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｘｐａｔｈで得ることができる。
【００１２】
ＸＭＬの既知の利点及び特徴により、マークアップ言語（例えばＸＭＬ）で記述された文書を扱うことができ、文書を作成及び修正するためのユーザフレンドリーなインタフェイスを提供することができる、効果的な文書処理システムが求められる。
【００１３】
ＸＭＬは、複雑な文書のための、またネットワークなどを介して複数のドキュメントにまたがってデータを共有するのに特に適した形式である。ＸＭＬ文書を作成、表示、編集するための多くのアプリケーションが開発されている（たとえば、特許文献１参照）。
【特許文献１】特開２００１−２９０８０４号公報
【発明の開示】
【発明が解決しようとする課題】
【００１４】
ボキャブラリは、任意に定義することが許されており、理論上、無限に多くのボキャブラリが存在しうる。これらのボキャブラリの全てに対応して専用の表示・編集環境を提供するのは現実的ではない。従来、専用の編集環境が用意されていないボキャブラリにより記述された文書を編集する場合、テキストデータにより構成された文書のソースを直接テキストエディタなどで編集していた。
【００１５】
既存のアプリケーションは、処理・管理できるＸＭＬ文書に大きな制限があったため、幅広く文書を受け入れることができなかった。例えばＸＭＬ文書処理システムの中には、ＸＭＬ文書の中で、文書の内容を表し、表示メソッドとは関係ない文字列を表示することができるものがある。この機能は一見優れているようであるが、実際にはユーザがＸＭＬ文書を直接編集できないという不都合な点も持つ。この問題を解決するために、ＸＭＬ文書処理システムの中には、ＸＭＬの入力を受け付ける画面を特別にデザインするものもある。しかし、画面デザインの柔軟性は限られていた。それらのＸＭＬ文書処理システムにおいては、前述の画面デザインは事前にハードコーディングされている必要があったからである。
【００１６】
この制限を考慮して、ＸＳＬＴは標準的なスタイルシート言語の一つとして開発された。このような技術によりユーザはハードコーディングから解放され、ＸＭＬ文書を表示するために適用されるメソッドとも混在可能になった。しかし、ＸＳＬＴを使用しても、特定の形式のＸＭＬ文書の編集はできない場合があった。
【００１７】
さらに、それらのＸＭＬ文書処理システムは、「スキーマ」に定義された順序をあてにしている。そのため、一旦スキーマが決定されると、処理システムで処理可能なのは、そのスキーマの構造に最上位から合致するＸＭＬ文書のみであった。換言すると、それらのシステムは過度に制限的で柔軟性を欠いている。
【課題を解決するための手段】
【００１８】
今回開示するシステムは、前述のような制限が無い。完全なＸＭＬ文書の構造は固定的に決定される必要はない。様々な構造が複合したＸＭＬ文書であっても、ＸＭＬ文書をより小さな部分に分割して安全に処理できる。それぞれの小さい部分は、より柔軟性を高めるため、個別に編集モジュールに振り分けられる。加えて、編集モジュールは、プラグインとして提供されるのが望ましい。さらにユーザは、何らのハードコーディングをすることなく柔軟性のある画面デザインを実装できる。いわゆるＷＹＳＩＷＹＧ（Ｗｈａｔ Ｙｏｕ Ｓｅｅ Ｉｓ Ｗｈａｔ Ｙｏｕ Ｇｅｔ）を実現できる。
【００１９】
ここで説明されるシステムの構成のうちのいくつかは、ＭＶＣ（Ｍｏｄｅｌ−Ｖｉｅｗ−Ｃｏｎｔｒｏｌｌｅｒ）と呼ばれる、よく知られたＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）パラダイムを用いて説明される。ＭＶＣパラダイムは、アプリケーション又はアプリケーションのインタフェイスの一部を、３つの部分、すなわち、モデル、ビュー、コントローラに分割する。ＭＶＣは、元は、ＧＵＩの世界に、従来の入力、処理、出力の役割を割り当てるために開発された。
【００２０】
［入力］ → ［処理］ → ［出力］
【００２１】
［コントローラ］→ ［モデル］ → ［ビュー］
【００２２】
ＭＶＣパラダイムによれば、外界のモデリング、ユーザへの視覚的なフィードバック、及びユーザの入力は、モデル（Ｍ）、ビュー（Ｖ）、及びコントローラ（Ｃ）オブジェクトにより分離されて扱われる。コントローラは、ユーザからのマウスとキーボード入力のような入力を解釈し、これらのユーザアクションを、適切な変更をもたらすためにモデル及び／又はビューに送られるコマンドにマップするように作用する。モデルは、１以上のデータ要素を管理するように作用し、その状態に関するクエリに応答し、状態を変更する指示に応答する。ビューは、ディスプレイの長方形の領域を管理するように作用し、グラフィクスとテキストの組合せによりユーザにデータを提示する機能を有する。
【００２３】
ワードプロセッサなどの標準的な文書生成アプリケーションでは、ユーザは文書を生成又は編集するときに、特定の動作を実行し、後で取り消したいことがある。このように、ユーザの動作を取り消すような避けられない必要性が予期されるので、「逆」操作が定義される必要がある。従来、逆操作の定義はプログラマ自身により生成されていた。広く行われている技術として、「取消可能な」操作が別の「取消可能な」操作を結合され、結合された取消可能な操作が実現される。しかし、プログラマによる介入のための要求は、高価でかつ非効率的である。逆操作をプログラムするためにプログラマを必要としない、取消可能なコマンドの定義が望まれる。
【００２４】
この目的の達成は、文書を生成するときに生じる様々な操作の取消は、適用される編集環境によって異なるという事実により阻害される。例えば、テキストエディタは、文字入力ごとに取消操作を有する。しかし、ＸＭＬのＤＯＭ編集環境においては、最小の取消可能な単位はＤＯＭの変更であるから、操作の取消は注意深く取り扱われる必要がある。しかし、ＤＯＭ変更を単位とした取消操作の実行は、ユーザにとっては無益で意味が無く、ＸＭＬ文書全体の不整合を生じさせる可能性もある。
【００２５】
したがって、ＸＭＬ環境では、ＤＯＭに対する取消操作を意味のある粒度で行う必要がある。１つの方法は、ＤＯＭにアクセスするメソッドを提供する文書モデルを提供し、全ての取消操作をメソッドベースで行うことである。このようなメソッドベースの方法は、任意のＤＯＭ操作をシームレスに取消可能とするが、ＤＯＭと相互作用するプログラマ独自の方法を記述することができないという不利益が生じる。全ての相互作用は定義済みのメソッドを通じて行われる必要がある。さらに、このメソッドを追加するためには、文書のモデル全体が変更される必要がある。
【００２６】
このように、逆操作を簡易に定義し、プログラマにより逆操作をプログラムする必要のない取消可能なコマンドを提供可能とする方法及び構成が必要である。
【００２７】
本発明のある態様は、ＤＯＭにより表現されたＸＭＬ文書の取消を提供する方法である。この方法は、前記ＤＯＭの変更を検知する工程と、前記ＤＯＭにおける検知された変更に対応する編集命令を生成する工程と、コマンドにより前記編集命令を検知する工程と、複数の検知された前記編集命令を収集する工程と、収集された前記編集命令を登録する工程と、を備える。
【発明を実施するための最良の形態】
【００２８】
以下、添付の図面を参照して、発明の典型的な実施例を詳細に記述する。
【００２９】
本発明の境界と範囲を定めるのは請求の範囲のみである。説明する実施の形態や実施例、効果は単なる例示であり、本発明を制限するものと考えてはならない。本発明の詳細な説明は説明を意図しており、請求の範囲を制限するものではない。当業者には多くの代替例、改造例や変形例が理解される。
【００３０】
Ａ．文書処理システムの全体構成
図１（ａ）は、後述するタイプの文書処理システムの基礎として機能する要素の標準的な構成例を示す。構成１０は、通信経路によりメモリ１２に接続されたＣＰＵ又はマイクロプロセッサ１１などの形式のプロセッサを含む。メモリ１２は、現在又は将来に利用可能な任意のＲＯＭ及び／又はＲＡＭの形式であってもよい。通信経路は、典型的にはバスとして設けられる。マウス、キーボード、音声認識システムなどのユーザ入力装置１４及び表示装置１５（又は他のユーザインタフェイス）に対する入出力インタフェイス１６も、プロセッサ１１とメモリ１２の通信のためのバスに接続される。この構成は、スタンドアロンであってもよいし、複数の端末及び１以上のサーバが接続されてネットワーク化された形式であってもよいし、既知のいかなる方式により構成されてもよい。本発明は、これらのコンポーネントの配置、集中又は分散されたアーキテクチャー、あるいは様々なコンポーネントの通信方法により制限されない。
【００３１】
さらに、本システム及びここで議論される実施例は、様々な機能性を提供するいくつかのコンポーネント及びサブコンポーネントを含むものとして議論される。これらのコンポーネント及びサブコンポーネントは、注目された機能性を提供するために、ハードウェアとソフトウェアの組合せだけでなく、ハードウェアのみ、ソフトウェアのみによっても実現されうる。さらに、ハードウェア、ソフトウェア、及びそれらの組合せは、汎用の計算装置、専用のハードウェア、又はそれらの組合せにより実現されうる。したがって、コンポーネント又はサブコンポーネントの構成は、コンポーネント又はサブコンポーネントの機能性を提供するための特定のソフトウェアを実行する汎用／専用の計算装置を含む。
【００３２】
図１（ｂ）は、文書処理システムの一例の全体のブロック図を示す。このような文書処理システムにおいて文書が生成され編集される。これらの文書は、例えばＸＭＬなど、マークアップ言語の特徴を有する任意の言語により記述されてもよい。また、便宜上、特定のコンポーネント及びサブコンポーネントの用語及び表題を創造した。しかしながら、これらは、この開示の一般的な教示の範囲を制限するために解釈されるべきではない。
【００３３】
文書処理システムは、２つの基本的な構成を有するものととらえることができる。第１の構成は、文書処理システムが動作する環境である「実行環境」１０１である。例えば、実行環境は、文書の処理中及び管理中に、ユーザだけでなくシステムも支援する、基本的なユーティリティ及び機能を提供する。第２の構成は、図１（ｃ）に示す、実行環境において走るアプリケーションから構成される「アプリケーション」１０２である。これらのアプリケーションは、文書自身及び文書の様々な表現を含む。
【００３４】
１．実行環境
実行環境１０１のキーとなるコンポーネントはＰｒｏｇｒａｍＩｎｖｏｋｅｒ（プログラムインボーカ：プログラム起動部）１０３である。ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３は、文書処理システムを起動するためにアクセスされる基本的なプログラムである。例えば、ユーザが文書処理システムにログオンして開始するとき、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３が実行される。ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３は、例えば、文書処理システムにプラグインとして加えられた機能を読み出して実行させたり、アプリケーションを開始して実行させたり、文書に関連するプロパティを読み出すことができる。ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３の機能はこれらに限定されない。ユーザが実行環境内で実行されるように意図されたアプリケーションを起動したいとき、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３は、そのアプリケーションを見つけ、それを起動して、アプリケーションを実行する。例えばユーザが文書（実行環境ではアプリケーションとして扱われる）を編集したいときには、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３は最初にその文書を発見し、文書を展開し、編集するために必要な機能を実行する。
【００３５】
ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３には、プラグインサブシステム１０４、コマンドサブシステム１０５、及びＲｅｓｏｕｒｃｅ（リソース）モジュール１０９などのいくつかのコンポーネントがアタッチされている。これらの構成については、以下に詳述する。
【００３６】
ａ）プラグインサブシステム
プラグインサブシステム１０４は、文書処理システムに機能を追加するための高度に柔軟で効率的な構成として使用される。プラグインサブシステム１０４は、また、文書処理システムに存在する機能を修正又は削除するために使用することができる。さらに、種々様々の機能をプラグインサブシステムを使用して追加又は修正することができる。例えば、画面上への文書の描画を支援するように作用するＥｄｉｔｌｅｔ（エディットレット：編集部）機能を追加することもできる。Ｅｄｉｔｌｅｔプラグインは、システムに追加されるボキャブラリの編集も支援する。
【００３７】
プラグインサブシステム１０４は、ＳｅｒｖｉｃｅＢｒｏｋｅｒ（サービスブローカ：サービス仲介部）１０４１を含む。ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１は、文書処理システムに加えられるプラグインを管理することにより、文書処理システムに加えられるサービスを仲介する。
【００３８】
所望の機能性を実現する個々の機能は、Ｓｅｒｖｉｃｅ（サービス）１０４２の形でシステムに追加される。利用可能なＳｅｒｖｉｃｅ１０４２のタイプは、Ａｐｐｌｉｃａｔｉｏｎ（アプリケーション）Ｓｅｒｖｉｃｅ、ＺｏｎｅＦａｃｔｏｒｙ（ゾーンファクトリ：ゾーン生成部）Ｓｅｒｖｉｃｅ、Ｅｄｉｔｌｅｔ（エディットレット：編集部）Ｓｅｒｖｉｃｅ、ＣｏｍｍａｎｄＦａｃｔｏｒｙ（コマンドファクトリ：コマンド生成部）Ｓｅｒｖｉｃｅ、ＣｏｎｎｅｃｔＸＰａｔｈ（コネクトＸＰａｔｈ：ＸＰａｔｈ管理部）Ｓｅｒｖｉｃｅ、ＣＳＳＣｏｍｐｕｔａｔｉｏｎ（ＣＳＳコンピューテーション：ＣＳＳ計算部）Ｓｅｒｖｉｃｅなどを含むが、これらに限定されない。これらのＳｅｒｖｉｃｅ、及びシステムの他の構成とそれらとの関係は、文書処理システムについてのよりよい理解のために、以下に詳述される。
【００３９】
プラグインとＳｅｒｖｉｃｅの関係は以下の通りである。プラグインは、１以上のＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒ（サービスプロバイダ：サービス提供部）を含むことができるユニットである。それぞれのＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒは、それに関連したＳｅｒｖｉｃｅの１以上のクラスを有する。例えば、適切なソフトウェアアプリケーションを有する単一のプラグインを使用することにより、１以上のＳｅｒｖｉｃｅをシステムに追加することができ、これにより、対応する機能をシステムに追加することができる。
【００４０】
ｂ）コマンドサブシステム
コマンドサブシステム１０５は、文書の処理に関連したコマンドの形式の命令を実行するために使用される。ユーザは、一連の命令を実行することにより、文書に対する操作を実行することができる。例えば、ユーザは、コマンドの形で命令を発行することにより、文書処理システム中のＸＭＬ文書に対応するＸＭＬのＤＯＭツリーを編集し、ＸＭＬ文書を処理する。これらのコマンドは、キーストローク、マウスクリック、又は他の有効なユーザインタフェイスアクションを使用して入力されてもよい。１つのコマンドにより１以上の命令が実行されることもある。この場合、これらの命令が１つのコマンドにラップ（包含）され、連続して実行される。例えば、ユーザが、誤った単語を正しい単語に置換したいとする。この場合、第１の命令は、文書中の誤った単語を発見することであり、第２の命令は、誤った単語を削除することであり、第３の命令は、正しい単語を挿入することであってもよい。これらの３つの命令が１つのコマンドにラップされてもよい。
【００４１】
コマンドは、関連した機能、例えば、後で詳述する「アンドゥ」機能を有してもよい。これらの機能は、オブジェクトを生成するために使用されるいくつかの基本クラスにも割り当てられてもよい。
【００４２】
コマンドサブシステム１０５のキーとなるコンポーネントは、選択的にコマンドを与え、実行するように作用するＣｏｍｍａｎｄＩｎｖｏｋｅｒ（コマンドインボーカ：コマンド起動部）１０５１である。図１（ｂ）には、１つのＣｏｍｍａｎｄＩｎｖｏｋｅｒのみが示されているが、１以上のＣｏｍｍａｎｄＩｎｖｏｋｅｒが使用されてもよく、１以上のコマンドが同時に実行されてもよい。ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１は、コマンドを実行するために必要な機能及びクラスを保持する。動作において、実行されるべきＣｏｍｍａｎｄ（コマンド：命令）１０５２は、Ｑｕｅｕｅ（キュー）１０５３に積まれる。ＣｏｍｍａｎｄＩｎｖｏｋｅｒは、連続的に実行するコマンドスレッドを生成する。ＣｏｍｍａｎｄＩｎｖｏｋｅｒ内で既に実行中のＣｏｍｍａｎｄがなければ、ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１により実行されるように意図されたＣｏｍｍａｎｄ１０５２が実行される。ＣｏｍｍａｎｄＩｎｖｏｋｅｒが既にコマンドを実行している場合、新しいＣｏｍｍａｎｄは、Ｑｕｅｕｅ１０５３の最後に積まれる。しかしながら、それぞれのＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１では、一度に１つのＣｏｍｍａｎｄのみが実行される。指定されたＣｏｍｍａｎｄの実行に失敗した場合、ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１は例外処理を実行する。
【００４３】
ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１により実行されるＣｏｍｍａｎｄの型は、ＵｎｄｏａｂｌｅＣｏｍｍａｎｄ（取消可能コマンド）１０５４、ＡｓｙｎｃｈｒｏｎｏｕｓＣｏｍｍａｎｄ（非同期コマンド）１０５５、及びＶＣＣｏｍｍａｎｄ（ＶＣコマンド）１０５６を含むが、これらに限定されない。ＵｎｄｏａｂｌｅＣｏｍｍａｎｄ１０５４は、ユーザが望めば、そのＣｏｍｍａｎｄの結果を取り消すことが可能なＣｏｍｍａｎｄである。ＵｎｄｏａｂｌｅＣｏｍｍａｎｄの例として、切り取り、コピー、テキストの挿入、などがある。動作において、ユーザが文書の一部を選択し、その部分に切り取りコマンドを適用するとき、ＵｎｄｏａｂｌｅＣｏｍｍａｎｄを用いることにより、切り取られた部分は、必要であれば、「切り取られていない」ようにすることができる。
【００４４】
ＶＣＣｏｍｍａｎｄ１０５６は、ボキャブラリコネクション記述子（Ｖｏｃａｂｕｌａｒｙ Ｃｏｎｎｅｃｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒ：ＶＣＤ）スクリプトファイルに格納される。これらは、プログラマにより定義されうるユーザ指定のＣｏｍｍａｎｄである。Ｃｏｍｍａｎｄは、例えば、ＸＭＬフラグメントを追加したり、ＸＭＬフラグメントを削除したり、属性を設定したりするための、より抽象的なＣｏｍｍａｎｄの組合せであってもよい。これらのＣｏｍｍａｎｄは、特に、文書の編集に焦点を合わせている。
【００４５】
ＡｓｙｎｃｈｒｏｎｏｕｓＣｏｍｍａｎｄ１０５５は、文書のロードや保存など、システムよりのＣｏｍｍａｎｄであり、ＵｎｄｏａｂｌｅＣｏｍｍａｎｄやＶＣＣｏｍｍａｎｄとは別に、非同期的に実行される。ＡｓｙｎｃｈｒｏｎｏｕｓＣｏｍｍａｎｄは、ＵｎｄｏａｂｌｅＣｏｍｍａｎｄではないので、取り消すことはできない。
【００４６】
ＡｓｙｎｃｈｒｏｎｏｕｓＣｏｍｍａｎｄｓ１０５５は、ボキャブラリコネクションの下位のレベルに存在する。それらは文書処理システムに対するより特別なコマンドである。ＡｓｙｎｃｈｒｏｎｏｕｓＣｏｍｍａｎｄｓはＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１に直接届けられる。一方で、ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎＣｏｍｍａｎｄｓ１０５６は解釈され、ＡｓｙｎｃｈｒｏｎｏｕｓＣｏｍｍａｎｄｓに変換されたのち、ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１に届けられる。
【００４７】
ｃ）リソース
Ｒｅｓｏｕｒｃｅ１０９は、様々なクラスに、いくつかの機能を提供するオブジェクトである。例えば、ストリングリソース、アイコン、及びデフォルトキーバインドは、システムで使用されるＲｅｓｏｕｒｃｅの例である。
【００４８】
２．アプリケーションコンポーネント
文書処理システムの第２の主要な特徴であるアプリケーションコンポーネント１０２は、実行環境１０１において実行される。アプリケーションコンポーネント１０２は、実際の文書と、システム内における文書の様々な論理的、物理的な表現を含む。さらに、アプリケーションコンポーネント１０２は、文書を管理するために使用されるシステムの構成を含む。アプリケーションコンポーネント１０２は、さらに、ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ（ユーザアプリケーション）１０６、アプリケーションコア１０８、ユーザインタフェイス１０７、及びＣｏｒｅＣｏｍｐｏｎｅｎｔ（コアコンポーネント）１１０を含む。
【００４９】
ａ）ユーザアプリケーション
ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６は、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３と共にシステム上にロードされる。ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６は、文書と、文書の様々な表現と、文書と対話するために必要なユーザインタフェイスとをつなぐ接着剤となる。例えば、ユーザが、プロジェクトの一部である文書のセットを生成したいとする。これらの文書がロードされると、文書の適切な表現が生成される。ユーザインタフェイス機能は、ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６の一部として追加される。言いかえれば、ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６は、ユーザがプロジェクトの一部を形成する文書と対話することを可能とする文書の表現と、文書の様々な態様とを、共に保持する。一旦ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６が生成されると、ユーザがプロジェクトの一部を形成する文書との対話を望むたびに、ユーザは簡単に実行環境上にＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６をロードすることができる。
【００５０】
ｂ）コアコンポーネント
ＣｏｒｅＣｏｍｐｏｎｅｎｔ１１０は、複数のＰａｎｅ（ペイン）の間で文書を共有する方法を提供する。後で詳述するように、Ｐａｎｅは、ＤＯＭツリーを表示し、画面の物理的なレイアウトを扱う。例えば、物理的な画面は、個々の情報の断片を描写する画面内の複数のＰａｎｅからなる。ユーザから画面上に見える文書は、１又はそれ以上のＰａｎｅに出現しうる。また、２つの異なる文書が画面上で２つの異なるＰａｎｅに現れてもよい。
【００５１】
図１（ｃ）に示されるように、画面の物理的なレイアウトもツリーの形式になっている。Ｐａｎｅは、ＲｏｏｔＰａｎｅ（ルートペイン）１０８４にもなり得るし、ＳｕｂＰａｎｅ（サブペイン）１０８５にもなり得る。ＲｏｏｔＰａｎｅ１０８４は、Ｐａｎｅのツリーの根に当たるＰａｎｅであり、ＳｕｂＰａｎｅ１０８５は、ＲｏｏｔＰａｎｅ１０８４以外の任意のＰａｎｅである。
【００５２】
ＣｏｒｅＣｏｍｐｏｎｅｎｔ１１０は、さらに、フォントを提供し、ツールキットなど、文書のための複数の機能的な操作のソースの役割を果たす。ＣｏｒｅＣｏｍｐｏｎｅｎｔ１１０により実行されるタスクの一例に、複数のＰａｎｅ間におけるマウスカーソルの移動がある。実行されるタスクの他の例として、あるＰａｎｅ中の文書の一部をマークし、それを異なる文書を含む別のＰａｎｅ上にコピーする。
【００５３】
ｃ）アプリケーションコア
上述したように、アプリケーションコンポーネント１０２は、システムにより処理され管理される文書から構成される。これは、システム内における文書の様々な論理的及び物理的な表現を含む。アプリケーションコア１０８は、アプリケーションコンポーネント１０２の構成である。その機能は、実際の文書を、それに含まれる全てのデータとともに保持することである。アプリケーションコア１０８は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ（ドキュメントマネージャ：文書管理部）１０８１及びＤｏｃｕｍｅｎｔ（ドキュメント：文書）１０８２自身を含む。
【００５４】
ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１の様々な態様を以下に詳述する。ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１は、Ｄｏｃｕｍｅｎｔ１０８２を管理する。ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１は、ＲｏｏｔＰａｎｅ１０８４、ＳｕｂＰａｎｅ１０８５、ＣｌｉｐＢｏａｒｄ（クリップボード）ユーティリティ１０８６、及びＳｎａｐＳｈｏｔ（スナップショット）ユーティリティ１０８７にも接続される。ＣｌｉｐＢｏａｒｄユーティリティ１０８６は、ユーザがクリップボードに加えることを決定した文書の部分を保持する方法を提供する。例えば、ユーザが、文書の一部を切り取り、後で再考するために新規文書にそれを保存することを望んだとする。このような場合、切り取られた部分がＣｌｉｐＢｏａｒｄに追加される。
【００５５】
つづいて、ＳｎａｐＳｈｏｔユーティリティ１０８７についても説明する。ＳｎａｐＳｈｏｔユーティリティ１０８７は、アプリケーションがある状態から別の状態まで移行するときに、アプリケーションの現在の状態を記憶することを可能とする。
【００５６】
ｄ）ユーザインタフェイス
アプリケーションコンポーネント１０２の別の構成は、ユーザがシステムと物理的に対話する手段を提供するユーザインタフェイス１０７である。例えば、ユーザインタフェイスは、ユーザが文書をアップロードしたり、削除したり、編集したり、管理したりするために使用される。ユーザインタフェイスは、Ｆｒａｍｅ（フレーム）１０７１、ＭｅｎｕＢａｒ（メニューバー）１０７２、ＳｔａｔｕｓＢａｒ（ステータスバー）１０７３、及びＵＲＬＢａｒ（ＵＲＬバー）１０７４を含む。
【００５７】
Ｆｒａｍｅ１０７１は、一般に知られているように、物理的な画面のアクティブな領域であると考えてもよい。ＭｅｎｕＢａｒ１０７２は、ユーザに選択を提供するメニューを含む画面領域である。ＳｔａｔｕｓＢａｒ１０７３は、アプリケーションの実行状態を表示する画面領域である。ＵＲＬＢａｒ１０７４は、インターネットをナビゲートするためにＵＲＬアドレスを入力する領域を提供する。
【００５８】
Ｂ．文書管理及び関連するデータ構造
図２は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１の詳細を示す。これは、文書処理システム内で文書を表現するために用いられるデータ構造及び構成を含む。分かりやすくするために、このサブセクションで説明される構成は、ＭＶＣパラダイムを用いて説明される。
【００５９】
ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１は、文書処理システム内にある全ての文書を保持しホストするＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ（ドキュメントコンテナ：文書コンテナ）２０３を含む。ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１にアタッチされたツールキット２０１は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１により使用される様々なツールを提供する。例えば、ＤｏｍＳｅｒｖｉｃｅ（ＤＯＭサービス）は、文書に対応するＤＯＭを生成し、保持し、管理するために必要とされる全ての機能を提供するために、ツールキット２０１により提供されるツールである。ツールキット２０１により提供される別のツールであるＩＯＭａｎａｇｅｒ（入出力管理部）は、システムへの入力及びシステムからの出力を管理する。同様に、ＳｔｒｅａｍＨａｎｄｌｅｒ（ストリームハンドラ）は、ビットストリームによる文書のアップロードを扱うツールである。これらのツールは、図中に特に示さず、参照番号を割り当てないが、ツールキット２０１のコンポーネントを形成する。
【００６０】
ＭＶＣパラダイムの表現によれば、モデル（Ｍ）は、文書のＤＯＭツリーモデル２０２を含む。前述したように、全ての文書は、文書処理システムにおいてＤＯＭツリーとして表現される。文書は、また、ＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ２０３の一部を形成する。
【００６１】
１．ＤＯＭモデル及びゾーン
ＤＯＭはＷ３Ｃが策定した標準規格であり、Ｎｏｄｅを操作するための標準的なインタフェイスを定義するが、実際には、ボキャブラリごと又はＮｏｄｅごとに特有の操作があるので、これらの操作をＡＰＩとして用意しておくのが好都合である。文書処理システムでは、このような各Ｎｏｄｅに特有のＡＰＩをＦａｃｅｔとして用意し、各Ｎｏｄｅにアタッチする。これにより、ＤＯＭの標準規格に準拠しつつ、有用なＡＰＩを付加することができる。また、ボキャブラリごとに特有のＤＯＭを実装するのではなく、標準的なＤＯＭの実装に、後から特有のＡＰＩを付加するようにすることで、多様なボキャブラリを統一的に処理することができるともに、複数のボキャブラリが任意の組合せで混在した文書を適切に処理することができる。標準的にはＤＯＭはＤＯＭツリー形式で表現される。
【００６２】
文書を表現するＤＯＭツリーは、Ｎｏｄｅ（ノード）２０２１を有するツリーである。ＤＯＭツリーの部分集合であるＺｏｎｅ（ゾーン）２０９は、ＤＯＭツリー内の１以上のＮｏｄｅの関連領域を含む。例えば、画面上で文書の一部のみを表示し得るが、この可視化された文書の一部はＺｏｎｅ２０９を用いて表示される。Ｚｏｎｅは、ＺｏｎｅＦａｃｔｏｒｙ（ゾーンファクトリ：ゾーン生成部）２０５と呼ばれるプラグインを用いて、生成され、取り扱われ、処理される。ＺｏｎｅはＤＯＭの一部を表現するが、１以上の「名前空間」を使用してもよい。よく知られているように、名前空間は、名前空間内でユニークな名前の集合である。換言すれば、名前空間内に同じ名前は存在しない。
【００６３】
２．Ｆａｃｅｔ及びＦａｃｅｔとＺｏｎｅとの関係
Ｆａｃｅｔ（ファセット）２０２２は、ＭＶＣパラダイムのモデル（Ｍ）部分内の別の構成である。Ｆａｃｅｔは、ＺｏｎｅにおいてＮｏｄｅを編集するために使用される。Ｆａｃｅｔ２０２２は、Ｚｏｎｅ自身の内容に影響を与えずに実行することができる手続（プロシージャ）を使用して、ＤＯＭへのアクセスを編成する。次に説明するように、これらの手続は、Ｎｏｄｅに関連した重要で有用な操作を実行する。
【００６４】
各Ｎｏｄｅ２０２１は、対応するＦａｃｅｔ２０２２を有する。ＤＯＭの中のＮｏｄｅを直接操作する代わりに、操作を実行するためにＦａｃｅｔを使用することによって、ＤＯＭの保全性は保護される。そうでなく、操作がＮｏｄｅ上で直接実行される場合、いくつかのプラグインがＤＯＭを同時に変更することができ、その結果矛盾を引き起こす。
【００６５】
ボキャブラリは、名前空間に属するタグ（例えばＸＭＬのタグ）のセットである。上述したように、名前空間は、ユニークな名前（ここではタグ）のセットを有する。ボキャブラリは、ＸＭＬ文書を表現するＤＯＭツリーのサブツリーとして現れる。このサブツリーはＺｏｎｅを含む。特定の例においては、タグセットの境界はＺｏｎｅによって定義される。Ｚｏｎｅ２０９は、ＺｏｎｅＦａｃｔｏｒｙ２０５と呼ばれるＳｅｒｖｉｃｅを利用して生成される。上述したように、Ｚｏｎｅ２０９は、文書を表現するＤＯＭツリーの一部の内部表現である。このような文書の一部へのアクセスを提供するために、論理的な表現が要求される。この論理的表現は、文書が画面上で論理的にどのように表現されるかについてコンピュータに通知する。Ｃａｎｖａｓ（キャンバス）２１０は、Ｚｏｎｅに対応する論理的なレイアウトを提供するように作用するＳｅｒｖｉｃｅである。
【００６６】
他方、Ｐａｎｅ２１１は、Ｃａｎｖａｓ２１０により提供される論理的なレイアウトに対応する物理的な画面レイアウトである。実際、ユーザは表示画面上で文字や画像によって文書のレンダリングのみを見る。したがって、文書は、画面上に文字や画像を描画するプロセスにより、画面上に描写されなければならない。文書は、Ｐａｎｅ２１１により提供される物理的なレイアウトに基づいて、Ｃａｎｖａｓ２１０により画面上に描写される。
【００６７】
Ｚｏｎｅ２０９に対応するＣａｎｖａｓ２１０は、Ｅｄｉｔｌｅｔ２０６を使用して生成される。文書のＤＯＭは、Ｅｄｉｔｌｅｔ２０６及びＣａｎｖａｓ２１０を使用して編集される。元の文書の完全性を維持するために、Ｅｄｉｔｌｅｔ２０６及びＣａｎｖａｓ２１０は、Ｚｏｎｅ２０９における１以上のＮｏｄｅに対応するＦａｃｅｔを使用する。これらのＳｅｒｖｉｃｅは、Ｚｏｎｅ及びＤＯＭ内のＮｏｄｅを直接操作しない。Ｆａｃｅｔは、Ｃｏｍｍａｎｄ２０７を利用して操作される。
【００６８】
ユーザは、一般に、画面上のカーソルを移動させたり、コマンドをタイプしたりすることによって、画面と対話する。画面上の論理的なレイアウトを提供するＣａｎｖａｓ２０１０は、このカーソル操作を受け付ける。Ｃａｎｖａｓ２０１０は、対応するアクションをＦａｃｅｔに実行させることができる。この関係により、カーソルサブシステム２０４は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１に対して、ＭＶＣパラダイムのコントローラ（Ｃ）として機能する。Ｃａｎｖａｓ２０１０は、イベントを扱うタスクも有する。例えば、Ｃａｎｖａｓ２０１０は、マウスクリック、フォーカス移動、及びユーザにより起こされた同様のアクションなどのイベントを扱う。
【００６９】
３．Ｚｏｎｅ、Ｆａｃｅｔ、Ｃａｎｖａｓ及びＰａｎｅの間の関係の概要
文書処理システム内の文書は、少なくとも４つの観点から見ることができる。すなわち、１）文書処理システムにおいて文書の内容及び構造を保持するために用いられるデータ構造、２）文書の保全性に影響を与えずに文書の内容を編集する手段、３）文書の画面上の論理的なレイアウト、４）文書の画面上の物理的なレイアウト、である。Ｚｏｎｅ、Ｆａｃｅｔ、Ｃａｎｖａｓ及びＰａｎｅは、前述の４つの観点に相当する、文書処理システムのコンポーネントをそれぞれ表す。
【００７０】
４．アンドゥサブシステム
上述したように、文書に対するいかなる変更（例えば編集）も取消可能であることが望ましい。例えば、ユーザが編集操作を実行し、次に、その変更の取消を決定したとする。図２に関連して、アンドゥサブシステム２１２は、文書管理部の取消可能なコンポーネントを実現する。ＵｎｄｏＭａｎａｇｅｒ（アンドゥマネージャ：アンドゥ管理部）２１２１は、ユーザによって取り消される可能性のある全ての文書に対する操作を保持する。
【００７１】
例えば、ユーザが、文書中の単語を別の単語に置換するコマンドを実行したとする。その後、ユーザは考え直し、元の単語に戻すことを決定したとする。アンドゥサブシステム２１２は、このような操作を支援する。ＵｎｄｏＭａｎａｇｅｒ２１２１は、このようなＵｎｄｏａｂｌｅＥｄｉｔ（アンドゥアブルエディット：取消可能な編集）２１２２の操作を保持する。
【００７２】
５．カーソルサブシステム
前述したように、ＭＶＣのコントローラ部分は、カーソルサブシステム２０４を備えてもよい。カーソルサブシステム２０４は、ユーザから入力を受け付ける。これらの入力は、一般にコマンド及び／又は編集操作の性格を有している。したがって、カーソルサブシステム２０４は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１に関連したＭＶＣパラダイムのコントローラ（Ｃ）部分であると考えることができる。
【００７３】
６．ビュー
前述したように、Ｃａｎｖａｓ２０１０は、画面上に提示されるべき文書の論理的なレイアウトを表す。ＸＨＴＭＬ文書の例では、Ｃａｎｖａｓは、文書が画面上でいかに見えるかを論理的に表現したボックスツリー２０８を含んでもよい。このボックスツリー２０８は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１に関連したＭＶＣパラダイムのビュー（Ｖ）部分に含まれよう。
【００７４】
Ｃ．ボキャブラリコネクション
文書処理システムの重要な特徴は、ＸＭＬ文書を、他の表現にマップして取り扱うことが可能で、かつ、マップした先の表現を編集すると、その編集が元のＸＭＬ文書に整合性を保ちつつ反映される環境を提供することにある。
【００７５】
マークアップ言語により記述された文書、例えばＸＭＬ文書は、文書型定義により定義されたボキャブラリに基づいて作成されている。ボキャブラリは、タグのセットである。ボキャブラリは、任意に定義されてもよいため、無限に多くのボキャブラリが存在しうる。しかしながら、多数の可能なボキャブラリのそれぞれに対して専用の処理／管理環境を提供するのは現実的ではない。ボキャブラリコネクションは、この問題を解決する方法を提供する。
【００７６】
例えば、文書は２以上のマークアップ言語により記述されてもよい。文書は、例えば、ＸＨＴＭＬ（ｅＸｔｅｎｓｉｂｌｅ ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）、ＳＶＧ（Ｓｃａｌａｂｌｅ Ｖｅｃｔｏｒ Ｇｒａｐｈｉｃｓ）、ＭａｔｈＭＬ（Ｍａｔｈｅｍａｔｉｃａｌ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）、その他のマークアップ言語により記述されてもよい。換言すれば、マークアップ言語は、ＸＭＬにおけるボキャブラリやタグセットと同様に見なされてもよい。
【００７７】
ボキャブラリは、ボキャブラリプラグインを用いて処理される。文書処理システムにおいてプラグインが利用不可能であるボキャブラリにより記述された文書は、プラグインが利用可能である別のボキャブラリの文書にマッピングすることにより表示される。この特徴により、プラグインが用意されていないボキャブラリの文書も適切に表示することができる。
【００７８】
ボキャブラリコネクションは、定義ファイルを取得し、取得した定義ファイルに基づいて２つの異なるボキャブラリの間でマッピングする能力を含む。あるボキャブラリで記述された文書は、別のボキャブラリにマッピングすることができる。このように、ボキャブラリコネクションは、文書がマッピングされるボキャブラリに対応した表示／編集プラグインにより文書を表示し編集することを可能にする。
【００７９】
上述したように、各文書は、一般に複数のノードを有するＤＯＭツリーとして文書処理システムにおいて記述される。「定義ファイル」は、それぞれのノードについて、そのノードと他のノードとの対応を記述する。各ノードの要素値及び属性値が編集可能か否かが指定される。ノードの要素値又は属性値を用いた演算式が記述されてもよい。
【００８０】
マッピングという特徴を利用して、定義ファイルを適用したデスティネーションＤＯＭツリーが生成される。このように、ソースＤＯＭツリーとデスティネーションＤＯＭツリーの関係が構築され保持される。ボキャブラリコネクションは、ソースＤＯＭツリーとデスティネーションＤＯＭツリーの対応を監視する。ユーザから編集指示を受けると、ボキャブラリコネクションは、ソースＤＯＭツリーの関連したノードを変更する。ソースＤＯＭツリーが変更されたことを示す「ミューテーションイベント」が発行され、デスティネーションＤＯＭツリーがそれに応じて変更される。
【００８１】
ボキャブラリコネクションの使用により、少数のユーザのみに知られていた比較的マイナーなボキャブラリを、別のメジャーなボキャブラリに変換することができる。したがって、少数のユーザによって利用されるマイナーなボキャブラリであっても、文書を適切に表示し、望ましい編集環境を提供することができる。
【００８２】
このように、文書処理システムの一部であるボキャブラリコネクションサブシステムは、文書の複数の表現を可能にする機能を提供する。
【００８３】
図３は、ボキャブラリコネクション（ＶＣ：Ｖｏｃａｂｕｌａｒｙ Ｃｏｎｎｅｃｔｉｏｎ）サブシステム３００を示す。ＶＣサブシステム３００は、同一の文書の２つの代替表現の整合性を維持する方法を提供する。例えば、２つの表現は、同一文書の、２つの異なるボキャブラリによる表現であってもよい。前述したように、一方はソースＤＯＭツリーであってもよく、他方はデスティネーションＤＯＭツリーであってもよい。
【００８４】
１．ボキャブラリコネクションサブシステム
ボキャブラリコネクションサブシステム３００の機能は、ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎ３０１と呼ばれるプラグインを使用して、文書処理システムにおいて実現される。文書が表現されるＶｏｃａｂｕｌａｒｙ３０５ごとに、対応するプラグインが要求される。例えば、文書の一部がＨＴＭＬで記述され、残りがＳＶＧで記述されている場合、ＨＴＭＬとＳＶＧに対応するボキャブラリプラグインが要求される。
【００８５】
ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎプラグイン３０１は、適切なＶｏｃａｂｕｌａｒｙ３０５の文書に対応した、Ｚｏｎｅ２０９又はＰａｎｅ２１１のための適切なＶＣＣａｎｖａｓ（ボキャブラリコネクションキャンバス）３１０を生成する。ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎ３０１を用いて、ソースＤＯＭツリー内のＺｏｎｅ２０９に対する変更は、変換ルールにより、別のＤＯＭツリー３０６の対応するＺｏｎｅに伝達される。変換ルールは、ボキャブラリコネクション記述子（Ｖｏｃａｂｕｌａｒｙ Ｃｏｎｎｅｃｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒ：ＶＣＤ）の形式で記述される。このようなソースＤＯＭとデスティネーションＤＯＭの間の変換に対応するそれぞれのＶＣＤファイルについて、対応するＶＣＭａｎａｇｅｒ（ボキャブラリコネクションマネージャ）３０２が生成される。
【００８６】
２．Ｃｏｎｎｅｃｔｏｒ
Ｃｏｎｎｅｃｔｏｒ３０４は、ソースＤＯＭツリーのソースノードと、デスティネーションＤＯＭツリーのデスティネーションノードとを接続する。Ｃｏｎｎｅｃｔｏｒ３０４は、ソースＤＯＭツリー中のソースノード、及びソースノードに対応するソース文書に対する修正（変更）を見るために作用する。そして、対応するデスティネーションＤＯＭツリーのノードを修正する。Ｃｏｎｎｅｃｔｏｒ３０４は、デスティネーションＤＯＭツリーを修正することができる唯一のオブジェクトである。例えば、ユーザは、ソース文書、及び対応するソースＤＯＭツリーに対してのみ修正を行うことができる。その後、Ｃｏｎｎｅｃｔｏｒ３０４がデスティネーションＤＯＭツリーに、対応する修正を行う。
【００８７】
Ｃｏｎｎｅｃｔｏｒ３０４は、ツリー構造を形成するために、論理的にリンクされる。Ｃｏｎｎｅｃｔｏｒ３０４により形成されたツリーは、ＣｏｎｎｅｃｔｏｒＴｒｅｅ（コネクタツリー）と呼ばれる。Ｃｏｎｎｅｃｔｏｒ３０４は、ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ（コネクタファクトリ：コネクタ生成部）３０３と呼ばれるＳｅｒｖｉｃｅを用いて生成される。ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３は、ソース文書からＣｏｎｎｅｃｔｏｒ３０４を生成し、それらをリンクしてＣｏｎｎｅｃｔｏｒＴｒｅｅを形成する。ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒ３０２は、ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３を保持する。
【００８８】
前述したように、ボキャブラリは名前空間におけるタグのセットである。図示されるように、Ｖｏｃａｂｕｌａｒｙ３０５は、ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎ３０１によって文書に対して生成される。これは、文書ファイルを解析し、ソースＤＯＭとデスティネーションＤＯＭの間の写像のための適切なＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒ３０２を生成することにより行われる。さらに、Ｃｏｎｎｅｃｔｏｒを生成するＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３と、Ｚｏｎｅ２０９を生成するＺｏｎｅＦａｃｔｏｒｙ２０５と、Ｚｏｎｅ内のノードに対応するＣａｎｖａｓを生成するＥｄｉｔｌｅｔ２０６との間の適切な関係が作られる。ユーザがシステムから文書を処分又は削除するとき、対応するＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒ３０２が削除される。
【００８９】
Ｖｏｃａｂｕｌａｒｙ３０５は、ＶＣＣａｎｖａｓ３１０を生成する。さらに、Ｃｏｎｎｅｃｔｏｒ３０４及びデスティネーションＤＯＭツリー３０６が対応して生成される。
【００９０】
ソースＤＯＭ及びＣａｎｖａｓは、それぞれ、モデル（Ｍ）及びビュー（Ｖ）に対応する。しかしながら、このような表現は、ターゲットのボキャブラリが画面上に描写可能である場合に限って意味がある。描写は、ボキャブラリプラグインにより行われる。ボキャブラリプラグインは、主要なボキャブラリ、例えば、ＸＨＴＭＬ、ＳＶＧ、ＭａｔｈＭＬについて提供される。ボキャブラリプラグインは、ターゲットのボキャブラリに関連して使用される。これらは、ボキャブラリコネクション記述子を用いてボキャブラリ間でマッピングする方法を提供する。
【００９１】
このようなマッピングは、ターゲットのボキャブラリが、マッピング可能で、画面上に描写される方法が予め定義されたものである場合にのみ意味がある。このようなレンダリング方法は、例えばＸＨＴＭＬなどのように、Ｗ３Ｃなどの組織により定義された標準規格となっている。
【００９２】
ボキャブラリコネクションが必要であるとき、ＶＣＣａｎｖａｓが使用される。この場合、ソースのビューを直接生成することができないので、ソースのＣａｎｖａｓは生成されない。この場合、ＶＣＣａｎｖａｓが、ＣｏｎｎｅｃｔｏｒＴｒｅｅを使用して生成される。このＶＣＣａｎｖａｓは、イベントの変換のみを扱い、画面上の文書の描写を援助しない。
【００９３】
３．ＤｅｓｔｉｎａｔｉｏｎＺｏｎｅ、Ｐａｎｅ、及びＣａｎｖａｓ
上述したように、ボキャブラリコネクションサブシステムの目的は、同一の文書の２つの表現を同時に生成し保持することである。第２の表現も、ＤＯＭツリーの形式であり、これはデスティネーションＤＯＭツリーとして既に説明した。第２の表現における文書を見るために、ＤｅｓｔｉｎａｔｉｏｎＺｏｎｅ、Ｃａｎｖａｓ及びＰａｎｅが必要である。
【００９４】
ＶＣＣａｎｖａｓが作成されると、対応するＤｅｓｔｉｎａｔｉｏｎＰａｎｅ３０７が生成される。さらに、関連するＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓ３０８と、対応するＢｏｘＴｒｅｅ３０９が生成される。同様に、ＶＣＣａｎｖａｓ３１０も、ソース文書に対するＰａｎｅ２１１及びＺｏｎｅ２０９に関連づけられる。
【００９５】
ＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓ３０８は、第２の表現における文書の論理的なレイアウトを提供する。特に、ＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓ３０８は、デスティネーション表現における文書を描写するために、カーソルや選択のようなユーザインタフェイス機能を提供する。ＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓ３０８に生じたイベントは、Ｃｏｎｎｅｃｔｏｒに供給される。ＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓ３０８は、マウスイベント、キーボードイベント、ドラッグアンドドロップイベント、及び文書のデスティネーション（第２）表現のボキャブラリに特有なイベントを、Ｃｏｎｎｅｃｔｏｒ３０４に通知する。
【００９６】
４．ボキャブラリコネクションコマンドサブシステム
ボキャブラリコネクション（ＶＣ）サブシステム３００の要素として、ボキャブラリコネクション（ＶＣ）コマンドサブシステム３１３がある。ボキャブラリコネクションコマンドサブシステム３１３は、ボキャブラリコネクションサブシステム３００に関連した命令の実行のために使用されるＶＣＣｏｍｍａｎｄ（ボキャブラリコネクションコマンド）３１５を生成する。ＶＣＣｏｍｍａｎｄは、内蔵のＣｏｍｍａｎｄＴｅｍｐｌａｔｅ（コマンドテンプレート）３１３１を使用して、及び／又は、スクリプトサブシステム３１４においてスクリプト言語を使用してスクラッチからコマンドを生成することにより、生成することができる。
【００９７】
コマンドテンプレートには、例えば、「Ｉｆ」コマンドテンプレート、「Ｗｈｅｎ」コマンドテンプレート、「挿入（Ｉｎｓｅｒｔ）」コマンドテンプレートなどがある。これらのテンプレートは、ＶＣＣｏｍｍａｎｄを作成するために使用される。
【００９８】
５．ＸＰａｔｈサブシステム
ＸＰａｔｈサブシステム３１６は、文書処理システムの重要な構成であり、ボキャブラリコネクションの実現を支援する。Ｃｏｎｎｅｃｔｏｒ３０４は、一般にｘｐａｔｈ情報を含む。上述したように、ボキャブラリコネクションのタスクの１つは、ソースＤＯＭツリーの変化をデスティネーションＤＯＭツリーに反映させることである。ｘｐａｔｈ情報は、変更／修正を監視されるべきソースＤＯＭツリーのサブセットを決定するために用いられる１以上のｘｐａｔｈ表現を含む。
【００９９】
６．ソースＤＯＭツリー、デスティネーションＤＯＭツリー、及びＣｏｎｎｅｃｔｏｒＴｒｅｅの概要
ソースＤＯＭツリーは、別のボキャブラリに変換される前のボキャブラリで文書を表現したＤＯＭツリー又はＺｏｎｅである。ソースＤＯＭツリーのノードは、ソースノードと呼ばれる。
【０１００】
それに対して、デスティネーションＤＯＭツリーは、ボキャブラリコネクションに関連して前述したように、同一の文書を、マッピングにより変換された後の異なるボキャブラリで表現したＤＯＭツリー又はＺｏｎｅである。デスティネーションＤＯＭツリーのノードは、デスティネーションノードと呼ばれる。
【０１０１】
ＣｏｎｎｅｃｔｏｒＴｒｅｅは、ソースノードとデスティネーションノードの対応を表すＣｏｎｎｅｃｔｏｒに基づく階層的表現である。Ｃｏｎｎｅｃｔｏｒは、ソースノードと、ソース文書になされた修正を監視し、デスティネーションＤＯＭツリーを修正する。Ｃｏｎｎｅｃｔｏｒは、デスティネーションＤＯＭツリーを修正することを許された唯一のオブジェクトである。
【０１０２】
Ｄ．文書処理システムにおけるイベントフロー
実用のためには、プログラムはユーザからのコマンドに応答しなければならない。イベントは、プログラム上で実行されたユーザアクションを記述し実行する方法である。多くの高級言語、例えばＪａｖａ（登録商標）は、ユーザアクションを記述するイベントに頼っている。従来、プログラムは、ユーザアクションを理解し、それを自身で実行するために、積極的に情報を集める必要があった。これは、例えば、プログラムが自身を初期化した後、ユーザが画面、キーボード、マウスなどでアクションを起こしたときに適切な処理を講じるために、ユーザのアクションを繰り返し確認するループに入ることを意味する。しかしながら、このプロセスは扱いにくい。さらに、それは、ユーザが何かをするのを待つ間、ＣＰＵサイクルを消費してループするプログラムを必要とする。
【０１０３】
多くの言語が、異なるパラダイムを採用することにより、これらの問題を解決している。そのうちの一つは、現代の全てのウィンドウシステムの基礎となっている、イベントドリブンプログラミングである。このパラダイムでは、全てのユーザアクションは、「イベント」と呼ばれる抽象的な事象の集合に属する。イベントは、十分詳細に、特定のユーザアクションを記述する。プログラムがユーザにより生成されたイベントを積極的に収集するのではなく、監視すべきイベントが生じたときに、システムがプログラムに通知する。この方法によりユーザとの対話を扱うプログラムは「イベントドリブン」であると言われる。
【０１０４】
これは、多くの場合、全てのユーザにより生成されたイベントの基本特性を獲得する「Ｅｖｅｎｔ（イベント）」クラスを使用して扱われる。
【０１０５】
文書処理システムは、自身のイベント、及びこれらのイベントを扱う方法を定義して使用する。いくつかの型のイベントが使用される。例えば、マウスイベントは、ユーザのマウスアクションから起こるイベントである。マウスを含むユーザアクションは、Ｃａｎｖａｓ２１０によって、マウスイベントに渡される。このように、Ｃａｎｖａｓは、システムのユーザによる相互作用の最前部にあると言える。必要であれば、最前部にあるＣａｎｖａｓは、そのイベントに関連した内容を子へ渡す。
【０１０６】
それに対して、キーストロークイベントは、Ｃａｎｖａｓ２１０から流れる。キーストロークイベントは、即時的なフォーカスを有する。すなわち、それは、いかなる瞬間でも作業に関連する。Ｃａｎｖａｓ２１０上に入力されたキーストロークイベントは、その親に渡される。キー入力は、文字列挿入を扱うことが可能な、異なるイベントによって処理される。文字列の挿入を扱うイベントは、キーボードを使用して文字が挿入されたときに発生する。他の「イベント」は、例えば、ドラッグイベント、ドロップイベント、マウスイベントと同様に扱われる他のイベントを含む。
【０１０７】
１．ボキャブラリコネクション外のイベントの取り扱い
イベントは、イベントスレッドを用いて渡される。Ｃａｎｖａｓ２１０は、イベントを受け取ると、その状態を変更する。必要であれば、Ｃｏｍｍａｎｄ１０５２がＣａｎｖａｓ２１０によりＣｏｍｍａｎｄＱｕｅｕｅ１０５３にポストされる。
【０１０８】
２．ボキャブラリコネクション内のイベントの取り扱い
ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎプラグイン３０１を用いて、ＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓの一例であるＸＨＴＭＬＣａｎｖａｓ１１０６は、発生したイベント、例えば、マウスイベント、キーボードイベント、ドラッグアンドドロップイベント、及びボキャブラリに特有のイベントなどを受け取る。これらのイベントは、Ｃｏｎｎｅｃｔｏｒ１１０４に通知される。より詳細には、図１１に図示されるように、ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎプラグイン３０１内のイベントフローは、ＳｏｕｒｃｅＰａｎｅ１１０３、ＶＣＣａｎｖａｓ１１０４、ＤｅｓｔｉｎａｔｉｏｎＰａｎｅ１１０５、ＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓの一例であるＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓ１１０６、デスティネーションＤＯＭツリー及びＣｏｎｎｅｃｔｏｒＴｒｅｅを通過する。
【０１０９】
Ｅ．ＰｒｏｇｒａｍＩｎｖｏｋｅｒ及びＰｒｏｇｒａｍＩｎｖｏｋｅｒと他の構成との関係
ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３及びそれと他の構成との関係は、図４（ａ）に更に詳細に示される。ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３は、文書処理システムを開始するために実行される実行環境中の基本的なプログラムである。図１（ｂ）に図示されるように、ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６、ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１、ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１、及びＲｅｓｏｕｒｃｅ１０９は、全てＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３に接続される。前述したように、アプリケーション１０２は、実行環境中で実行されるコンポーネントである。同様に、ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１は、システムに様々な機能を加えるプラグインを管理する。他方、ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１は、ユーザにより提供される命令を実行して、コマンドを実行するために使用されるクラス及びファンクションを保持する。
【０１１０】
１．プラグイン及びサービス
ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１について、図４（ｂ）を参照して更に詳細に説明する。前述したように、ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１は、システムに様々な機能を追加するプラグイン（及び関連するサービス）を管理する。Ｓｅｒｖｉｃｅ１０４２は、文書処理システムに特徴を追加又は変更可能な最も下の層である。「Ｓｅｒｖｉｃｅ」は、ＳｅｒｖｉｃｅＣａｔｅｇｏｒｙ４０１とＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒ４０２の２つの部分からなる。図４（ｃ）に図示されるように、１つのＳｅｒｖｉｃｅＣａｔｅｇｏｒｙ４０１は、複数の関連するＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒ４０２を持ちうる。それぞれのＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒは、特定のＳｅｒｖｉｃｅＣａｔｅｇｏｒｙの一部または全部を実行するように作用する。ＳｅｒｖｉｃｅＣａｔｅｇｏｒｙ４０１は、他方では、Ｓｅｒｖｉｃｅの型を定義する。
【０１１１】
Ｓｅｒｖｉｃｅは、１）文書処理システムに特定の特色を提供する「特色サービス」、２）文書処理システムにより実行されるアプリケーションである「アプリケーションサービス」、３）文書処理システムの全体にわたって必要な特色を提供する「環境サービス」、の３つの型に分類することができる。
【０１１２】
Ｓｅｒｖｉｃｅの例は、図４（ｄ）に示される。アプリケーションＳｅｒｖｉｃｅのＣａｔｅｇｏｒｙにおいては、システムユーティリティが対応するＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒの例である。同様に、Ｅｄｉｔｌｅｔ２０６はＣａｔｅｇｏｒｙであり、ＨＴＭＬＥｄｉｔｌｅｔ及びＳＶＧＥｄｉｔｌｅｔは対応するＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒである。ＺｏｎｅＦａｃｔｏｒｙ２０５は、Ｓｅｒｖｉｃｅの別のＣａｔｅｇｏｒｙであり、対応するＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒ（図示せず）を有する。
【０１１３】
プラグインは、文書処理システムに機能性を加えると既に説明したが、いくつかのＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒ４０２及びそれらに関連するクラスからなるユニットと見なされてもよい。各プラグインは、宣言ファイルに記述された依存性及びＳｅｒｖｉｃｅＣａｔｅｇｏｒｙ４０１を有する。
【０１１４】
２．ＰｒｏｇｒａｍＩｎｖｏｋｅｒとアプリケーションとの関係
図４（ｅ）は、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３とＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６との関係についての更なる詳細を示す。必要な文書やデータなどは、ストレージからロードされる。必要なプラグインは、全てＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１上にロードされる。ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１は、全てのプラグインを保持し管理する。プラグインは、システムに物理的に追加することができ、又、その機能はストレージからロードすることができる。プラグインの内容がロードされると、ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１は、対応するプラグインを定義する。つづいて、対応するＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６が生成され、実行環境１０１にロードされ、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３にアタッチされる。
【０１１５】
Ｆ．アプリケーションサービスと環境との関係
図５（ａ）は、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３上にロードしたアプリケーションサービスの構成についての更なる詳細を示す。コマンドサブシステム１０５のコンポーネントであるＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１は、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３内のＣｏｍｍａｎｄ１０５２を起動又は実行する。Ｃｏｍｍａｎｄ１０５２は、文書処理システムにおいて、ＸＭＬなどの文書を処理し、対応するＸＭＬＤＯＭツリーを編集するために用いられる命令である。ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１は、Ｃｏｍｍａｎｄ１０５２を実行するために必要なクラス及びファンクションを保持する。
【０１１６】
ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１も、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３内で実行される。ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６は、ユーザインタフェイス１０７及びＣｏｒｅＣｏｍｐｏｎｅｎｔ１１０に接続される。ＣｏｒｅＣｏｍｐｏｎｅｎｔ１１０は、全てのＰａｎｅの間で文書を共有する方法を提供する。ＣｏｒｅＣｏｍｐｏｎｅｎｔ１１０は、さらにフォントを提供し、Ｐａｎｅのためのツールキットの役割を果たす。
【０１１７】
図５（ａ）及び図５（ｂ）は、Ｆｒａｍｅ１０７１、ＭｅｎｕＢａｒ１０７２、及びＳｔａｔｕｓＢａｒ１０７３の関係を示す。
【０１１８】
Ｇ．アプリケーションコア
図６（ａ）は、全ての文書、及び文書の一部及び文書に属するデータを保持するアプリケーションコア１１０についての更なる説明を提供する。ＣｏｒｅＣｏｍｐｏｎｅｎｔ１１０は、Ｄｏｃｕｍｅｎｔ１０８２を管理するＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１にアタッチされる。ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１は、文書処理システムに関連づけられたメモリに格納される全てのＤｏｃｕｍｅｎｔ１０８２の所有者である。
【０１１９】
画面上の文書の表示を容易にするために、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１はＲｏｏｔＰａｎｅ１０８４にも接続される。ＣｌｉｐＢｏａｒｄ１０８６、ＳｎａｐＳｈｏｔ１０８７、Ｄｒａｇ＆Ｄｒｏｐ６０１、及びＯｖｅｒｌａｙ６０２の機能も、アプリケーションコアにアタッチされる。
【０１２０】
ＳｎａｐＳｈｏｔ１０８７は、図６（ａ）で示したように、アプリケーションの状態を元に戻すために使用される。ユーザがＳｎａｐＳｈｏｔ１０８７を起動したとき、アプリケーションの現状が検知され、格納される。その後、アプリケーションの状態が別の状態に変わるとき、格納された状態の内容は保存される。ＳｎａｐＳｈｏｔは、図６（ｂ）に図示される。動作において、アプリケーションがあるＵＲＬから他へ移動するときに、前に戻る動作及び先に進む動作をシームレスに実行可能とするために、ＳｎａｐＳｈｏｔは以前の状態を記憶する。
【０１２１】
Ｈ．ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ内における文書の構成
図７（ａ）は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１の更なる説明と、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒにおいて文書が構成され保持される様子を示す。図１（ｂ）に示したように、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１は、Ｄｏｃｕｍｅｎｔ１０８２を管理する。図７（ａ）に示される例において、複数のＤｏｃｕｍｅｎｔのうちの１つはＲｏｏｔＤｏｃｕｍｅｎｔ（ルート文書）７０１であり、残りの文書はＳｕｂＤｏｃｕｍｅｎｔ（サブ文書）７０２である。ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１は、ＲｏｏｔＤｏｃｕｍｅｎｔ７０１に接続され、ＲｏｏｔＤｏｃｕｍｅｎｔ７０１は、全てのＳｕｂＤｏｃｕｍｅｎｔ７０２に接続される。
【０１２２】
図２及び図７（ａ）に示すように、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１は、全ての文書１０８２を管理するオブジェクトであるＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ２０３に結合される。ＤＯＭＳｅｒｖｉｃｅ７０３及びＩＯＭａｎａｇｅｒ７０４を含むツールキット２０１（例えばＸＭＬツールキット）の一部を形成するツールも、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１に供給される。再び図７（ａ）を参照して、ＤＯＭＳｅｒｖｉｃｅ７０３は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１により管理される文書に基づいたＤＯＭツリーを生成する。各Ｄｏｃｕｍｅｎｔ７０５は、それがＲｏｏｔＤｏｃｕｍｅｎｔ７０１であってもＳｕｂＤｏｃｕｍｅｎｔ７０２であっても、対応するＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ２０３によって管理される。
【０１２３】
図７（ｂ）は、文書Ａ−Ｅが階層的に配置される様子を示す。文書ＡはＲｏｏｔＤｏｃｕｍｅｎｔである。文書Ｂ−Ｄは、文書ＡのＳｕｂＤｏｃｕｍｅｎｔである。文書Ｅは、文書ＤのＳｕｂＤｏｃｕｍｅｎｔである。図７（ｃ）では、これと同じ文書の階層が画面上に表示された例を示す。ＲｏｏｔＤｏｃｕｍｅｎｔである文書Ａは、基本フレームとして表示される。文書ＡのＳｕｂＤｏｃｕｍｅｎｔである文書Ｂ−Ｄは、基本フレームＡの中のサブフレームとして表示される。文書ＤのＳｕｂＤｏｃｕｍｅｎｔである文書Ｅは、サブフレームＤのサブフレームとして画面に表示される。
【０１２４】
再び図７（ａ）を参照して、ＵｎｄｏＭａｎａｇｅｒ（アンドゥマネージャ：アンドゥ管理部）７０６及びＵｎｄｏＷｒａｐｐｅｒ（アンドゥラッパー）７０７は、それぞれのＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ２０３に対して生成される。ＵｎｄｏＭａｎａｇｅｒ７０６及びＵｎｄｏＷｒａｐｐｅｒ７０７は、取消可能なコマンドを実行するために使用される。この特徴を使用することにより、編集操作を使用して文書に対して実行された変更を取り消すことができる。ＳｕｂＤｏｃｕｍｅｎｔの変更は、ＲｏｏｔＤｏｃｕｍｅｎｔとも密接な関係を有する。アンドゥ操作は、階層内の他の文書に影響する変更を考慮に入れて、例えば、図１７（ｃ）に示されるような連鎖状の階層における全ての文書の間で整合性が維持されることを保証する。
【０１２５】
ＵｎｄｏＷｒａｐｐｅｒ７０７は、ＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ２０３内のＳｕｂＤｏｃｕｍｅｎｔに関連するアンドゥオブジェクトをラップし、それらをＲｏｏｔＤｏｃｕｍｅｎｔに関連するアンドゥオブジェクトに結合させる。ＵｎｄｏＷｒａｐｐｅｒ７０７は、ＵｎｄｏａｂｌｅＥｄｉｔＡｃｃｅｐｔｏｒ（アンドゥアブルエディットアクセプタ：アンドゥ可能編集受付部）７０９に利用可能なアンドゥオブジェクトを収集させる。
【０１２６】
ＵｎｄｏＭａｎａｇｅｒ７０６及びＵｎｄｏＷｒａｐｐｅｒ７０７は、ＵｎｄｏａｂｌｅＥｄｉｔＡｃｃｅｐｔｏｒ７０８及びＵｎｄｏａｂｌｅＥｄｉｔＳｏｕｒｃｅ（アンドゥアブルエディットソース）７０８に接続される。当業者には理解されるように、Ｄｏｃｕｍｅｎｔ７０５がＵｎｄｏａｂｌｅＥｄｉｔＳｏｕｒｃｅ７０８であってもよく、取消可能な編集オブジェクトのソースであってもよい。
【０１２７】
Ｉ．アンドゥコマンド及びアンドゥフレームワーク
図８（ａ）及び図８（ｂ）は、アンドゥフレームワーク及びアンドゥコマンドについて更なる詳細を提供する。図８（ａ）に示されるように、ＵｎｄｏＣｏｍｍａｎｄ８０１、ＲｅｄｏＣｏｍｍａｎｄ８０２、及びＵｎｄｏａｂｌｅＥｄｉｔＣｏｍｍａｎｄ８０３は、図１（ｂ）に示したようにＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１に積むことができるコマンドであり、順に実行される。ＵｎｄｏａｂｌｅＥｄｉｔＣｏｍｍａｎｄ８０３は、ＵｎｄｏａｂｌｅＥｄｉｔＳｏｕｒｃｅ７０８及びＵｎｄｏａｂｌｅＥｄｉｔＡｃｃｅｐｔｏｒ７０９に更にアタッチされる。「ｆｏｏ」ＥｄｉｔＣｏｍｍａｎｄ８０３及び「ｂａｒ」ＥｄｉｔＣｏｍｍａｎｄ８０４は、ＵｎｄｏａｂｌｅＥｄｉｔＣｏｍｍａｎｄの例である。
【０１２８】
１．ＵｎｄｏａｂｌｅＥｄｉｔＣｏｍｍａｎｄの実行
図８（ｂ）は、ＵｎｄｏａｂｌｅＥｄｉｔＣｏｍｍａｎｄの実行を示す。まず、ユーザが編集コマンドを使用してＤｏｃｕｍｅｎｔ７０５を編集すると仮定する。第１ステップＳ１では、ＵｎｄｏａｂｌｅＥｄｉｔＡｃｃｅｐｔｏｒ７０９が、Ｄｏｃｕｍｅｎｔ７０５のＤＯＭツリーであるＵｎｄｏａｂｌｅＥｄｉｔＳｏｕｒｃｅ７０８にアタッチされる。第２ステップＳ２では、ユーザにより発行されたコマンドに基づいて、Ｄｏｃｕｍｅｎｔ７０５がＤＯＭのＡＰＩを用いて編集される。第３ステップＳ３では、ミューテーションイベントのリスナーが、変更がなされたことを通知される。すなわち、このステップでは、ＤＯＭツリーの全ての変更を監視するリスナーが編集操作を検知する。第４ステップＳ４では、ＵｎｄｏａｂｌｅＥｄｉｔがＵｎｄｏＭａｎａｇｅｒ７０６のオブジェクトとして格納される。第５ステップＳ５では、ＵｎｄｏａｂｌｅＥｄｉｔＡｃｃｅｐｔｏｒ７０９がＵｎｄｏａｂｌｅＥｄｉｔＳｏｕｒｃｅ７０８からデタッチされる。ＵｎｄｏａｂｌｅＥｄｉｔＳｏｕｒｃｅ７０８は、Ｄｏｃｕｍｅｎｔ７０５自身であってもよい。
【０１２９】
Ｊ．システムへの文書のロードに関する手順
上記のサブセクションでは、システムの様々なコンポーネント及びサブコンポーネントについて説明した。以下、これらのコンポーネントの使用に関する方法論について説明する。図９は、文書処理システムに文書がロードされる様子の概要を示す。それぞれのステンプは、図１４−１８において、特定の例に関連して詳述される。
【０１３０】
簡単には、文書処理システムは、文書に含まれるデータからなるバイナリデータストリームからＤＯＭを生成する。ＡｐｅｘＮｏｄｅ（エイペックスノード：頂点ノード）が、注目対象でありＺｏｎｅに属する文書の一部のために生成される。つづいて、対応するＰａｎｅが特定される。特定されたＰａｎｅは、ＡｐｅｘＮｏｄｅ及び物理的な画面表面からＺｏｎｅ及びＣａｎｖａｓを生成する。Ｚｏｎｅは、次に、それぞれのノードにＦａｃｅｔを生成し、それらに必要とされる情報を提供する。Ｃａｎｖａｓは、ＤＯＭツリーから、ノードをレンダリングするためのデータ構造を生成する。
【０１３１】
図１９（ａ）で示すように、ＳＨＴＭＬやＳＶＧコンテンツの両方で記述された複雑な文書はストレージ９０１からステップ０としてロードされる。その文書のＤＯＭツリー９０２が作成される。ＤＯＭツリー９０２が一つの頂点ノード９０５を有し、そして木が他の枝に降りるように、境界では２方向に分かれる。他のボキャブラリ、例えばＳＶＧの一つの頂点ノードもこれに従う。複雑な文書をこのように表現することは、文書を描写し、最終的に表示する方法を理解するのに有益である。
【０１３２】
次に、文書を保持するための、対応するＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ９０３が生成される。ＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ９０３は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ９０４にアタッチされる。ＤＯＭツリーは、ルートノードと、ときには複数のセカンダリノードを含む。
【０１３３】
一般に、このような文書は、テキスト及びグラフィクスの双方を含む。したがって、ＤＯＭツリーは、例えば、ＸＨＴＭＬサブツリーだけでなくＳＶＧサブツリーを有してもよい。ＸＨＴＭＬサブツリーは、ＸＨＴＭＬのＡｐｅｘＮｏｄｅ９０５を有する。同様に、ＳＶＧサブツリーは、ＳＶＧのＡｐｅｘＮｏｄｅ９０６を有する。
【０１３４】
ステップ１では、ＡｐｅｘＮｏｄｅ９０６が、画面の論理的なレイアウトであるＰａｎｅ９０７にアタッチされる。ステップ２では、Ｐａｎｅ９０７は、ＰａｎｅＯｗｎｅｒ（ペインオーナー：ペインの所有者）９０８であるＣｏｒｅＣｏｍｐｏｎｅｎｔに、ＡｐｅｘＮｏｄｅ９０６のためのＺｏｎｅＦａｃｔｏｒｙを要求する。ステップ３では、ＰａｎｅＯｗｎｅｒ９０８は、ＺｏｎｅＦａｃｔｏｒｙと、ＡｐｅｘＮｏｄｅ９０６のためのＣａｎｖａｓＦａｃｔｏｒｙであるＥｄｉｔｌｅｔとを返す。
【０１３５】
ステップ４では、Ｐａｎｅ９０７がＺｏｎｅ９０９を生成する。Ｚｏｎｅ９０９はＰａｎｅ９０７にアタッチされる。ステップ５では、Ｚｏｎｅ９０９がそれぞれのノードに対してＦａｃｅｔを生成し、対応するノードにアタッチする。ステップ６では、Ｐａｎｅ９０７がＣａｎｖａｓ９１０を生成する。Ｃａｎｖａｓ９１０はＰａｎｅ９０７にアタッチされる。Ｃａｎｖａｓ９１０には様々なＣｏｍｍａｎｄが含まれる。ステップ７では、Ｃａｎｖａｓ９１０が文書を画面にレンダリングするためのデータ構造を構築する。ＸＨＴＭＬの場合、これはボックスツリー構造を含む。
【０１３６】
１．ＺｏｎｅのＭＶＣ
図９（ｂ）は、ＭＶＣパラダイムを用いてＺｏｎｅの構成の概要を示す。この場合、Ｚｏｎｅ及びＦａｃｅｔは文書に関連した入力であるから、モデル（Ｍ）はＺｏｎｅ及びＦａｃｅｔを含む。Ｃａｎｖａｓと、文書を画面にレンダリングするためのデータ構造体は、ユーザが画面上に見る出力であるから、ビュー（Ｖ）はＣａｎｖａｓ及びデータ構造体に対応する。Ｃｏｍｍａｎｄは、文書とその様々な関係に対して制御操作を実行するので、コントロール（Ｃ）はＣａｎｖａｓに含まれるＣｏｍｍａｎｄを含む。
【０１３７】
Ｋ．文書の表現
図１０を用いて、文書及びその様々な表現の例について以下に説明する。この例で使用される文書は、テキストと画像の双方を含む。テキストは、ＸＨＴＭＬを用いて表され、画像は、ＳＶＧを用いて表される。図１０は、文書のコンポーネント及び対応するオブジェクトの関係のＭＶＣ表現を詳細に示す。この例において、Ｄｏｃｕｍｅｎｔ１００１は、Ｄｏｃｕｍｅｎｔ１００１を保持するＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ１００２にアタッチされる。文書はＤＯＭツリー１００３により表現される。ＤＯＭツリーは、ＡｐｅｘＮｏｄｅ１００４を含む。
【０１３８】
ＡｐｅｘＮｏｄｅは、黒丸で表される。頂点でないノードは、白丸で表される。ノードを編集するために用いられるＦａｃｅｔは、三角形で表され、対応するノードにアタッチされる。文書がテキストと画像を有するので、この文書のＤＯＭツリーは、ＸＨＴＭＬ部分とＳＶＧ部分を含む。ＡｐｅｘＮｏｄｅ１００４は、ＸＨＴＭＬサブツリーの最上のノードである。これは、文書のＸＨＴＭＬ部分の物理的な表現のための最上ＰａｎｅであるＸＨＴＭＬＰａｎｅ１００５にアタッチされる。ＡｐｅｘＮｏｄｅ１００４は、文書のＤＯＭツリーの一部であるＸＨＴＭＬＺｏｎｅ１００６にもアタッチされる。
【０１３９】
Ｎｏｄｅ１００４に対応するＦａｃｅｔも、ＸＨＴＭＬＺｏｎｅ１００６にアタッチされる。ＸＨＴＭＬＺｏｎｅ１００６は、ＸＨＴＭＬＰａｎｅ１００５にアタッチされる。ＸＨＴＭＬＥｄｉｔｌｅｔは、文書の論理的な表現であるＸＨＴＭＬＣａｎｖａｓ１００７を生成する。ＸＨＴＭＬＣａｎｖａｓ１００７は、ＸＨＴＭＬＰａｎｅ１００５にアタッチされる。ＸＨＴＭＬＣａｎｖａｓ１００７は、Ｄｏｃｕｍｅｎｔ１００１のＸＨＴＭＬコンポーネントのためのＢｏｘＴｒｅｅ１００９を生成する。文書のＸＨＴＭＬ部分を保持し描画するために必要な様々なＣｏｍｍａｎｄ１００８も、ＸＨＴＭＬＣａｎｖａｓ１００５に追加される。
【０１４０】
同様に、文書のＳＶＧサブツリーのＡｐｅｘＮｏｄｅ１０１０は、文書のＳＶＧコンポーネントを表現するＤｏｃｕｍｅｎｔのＤＯＭツリーの一部であるＳＶＧＺｏｎｅ１０１１にアタッチされる。ＡｐｅｘＮｏｄｅ１０１０は、文書のＳＶＧ部分の物理的な表現の最上のＰａｎｅであるＳＶＧＰａｎｅ１０１３にアタッチされる。文書のＳＶＧ部分の論理的な表現を表すＳＶＧＣａｎｖａｓ１０１２は、ＳＶＧＥｄｉｔｌｅｔにより生成され、ＳＶＧＰａｎｅ１０１３にアタッチされる。画面上に文書のＳＶＧ部分をレンダリングするためのデータ構造及びコマンドは、ＳＶＧＣａｎｖａｓにアタッチされる。例えば、このデータ構造は、図示されるように、円、線、長方形などを含んでもよい。
【０１４１】
図１０に関連して説明された文書例の表現の一部について、図１１（ａ）、図１１（ｂ）に関連して、前述したＭＶＣパラダイムを用いて更に説明する。図１１（ａ）は、文書１００１のＸＨＴＭＬコンポーネントにおけるＭＶの関係を簡略化して示す。モデルは、Ｄｏｃｕｍｅｎｔ１００１のＸＨＴＭＬコンポーネントのためのＸＨＴＭＬＺｏｎｅ１１０３である。ＸＨＴＭＬＺｏｎｅのツリーには、いくつかのＮｏｄｅ及びそれらに対応するＦａｃｅｔが含まれる。対応するＸＨＴＭＬＺｏｎｅ及びＰａｎｅは、ＭＶＣパラダイムのモデル（Ｍ）部分の一部である。ＭＶＣパラダイムのビュー（Ｖ）部分は、Ｄｏｃｕｍｅｎｔ１００１のＨＴＭＬコンポーネントの、対応するＸＨＴＭＬＣａｎｖａｓ１１０２及びＢｏｘＴｒｅｅである。文書のＸＨＴＭＬ部分は、Ｃａｎｖａｓと、それに含まれるＣｏｍｍａｎｄを使用して画面に描写される。キーボードやマウス入力などのイベントは、図示されるように、逆方向へ進む。
【０１４２】
ＳｏｕｒｃｅＰａｎｅは、更なる機能、すなわち、ＤＯＭの保有者としての役割を有する。図１１（ｂ）は、図１１（ａ）に示したＤｏｃｕｍｅｎｔ１００１のコンポーネントに対するボキャブラリコネクションを提供する。ＤＯＭホルダーとして機能するＳｏｕｒｃｅＰａｎｅ１１０３は、文書のソースＤＯＭツリーを含む。ＣｏｎｎｅｃｔｏｒＴｒｅｅは、ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙにより生成され、デスティネーションＤＯＭの保有者としても機能するＤｅｓｔｉｎａｔｉｏｎＰａｎｅ１１０５を生成する。ＤｅｓｔｉｎａｔｉｏｎＰａｎｅ１１０５は、ＸＨＴＭＬＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓ１１０６としてボックスツリーの形式でレイアウトされる。
【０１４３】
Ｌ．プラグインサブシステム、ボキャブラリコネクション、及びコネクタの関係
図１２（ａ）−（ｃ）は、それぞれ、プラグインサブシステム、ボキャブラリコネクション、及びＣｏｎｎｅｃｔｏｒに関連する更なる詳細を示す。プラグインサブシステムは、文書処理システムに機能を追加又は交換するために用いられる。プラグインサブシステムは、ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１を含む。図１２（ａ）で示すように、「Ｍｙ Ｏｗｎ ＸＭＬ ｖｏｃａｂｕｌａｒｙ」はＶｃＢａｓｅＰｌｕｇＩｎとして提供され、そのプラグインには、Ｍｙ Ｏｗｎ ＸＭＬ ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙＴｒｅｅ及びボキャブラリ（ＺｏｎｅＦａｃｔｏｒｙＢｕｉｌｄｅｒ）を含む。ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１にアタッチされるＺｏｎｅＦａｃｔｏｒｙＳｅｒｖｉｃｅ１２０１は、文書の一部に対するＺｏｎｅを生成する。ＥｄｉｔｌｅｔＳｅｒｖｉｃｅ１２０２も、ＳｅｒｖｉｃｅＢｒｏｋｅｒにアタッチされる。ＥｄｉｔｌｅｔＳｅｒｖｉｃｅ１２０２は、Ｚｏｎｅ中のＮｏｄｅに対応するＣａｎｖａｓを生成する。
【０１４４】
ＺｏｎｅＦａｃｔｏｒｙの例は、ＸＨＴＭＬＺｏｎｅ及びＳＶＧＺｏｎｅをそれぞれ生成するＸＨＴＭＬＺｏｎｅＦａｃｔｏｒｙ１２１１及びＳＶＧＺｏｎｅＦａｃｔｏｒｙ１２１２である。文書例に関連して前述したように、文書のテキストコンポーネントは、ＸＨＴＭＬＺｏｎｅを生成することにより表現されてもよいし、画像はＳＶＧＺｏｎｅを用いて表現されてもよい。ＥｄｉｔｌｅｔＳｅｒｖｉｃｅの例は、ＸＨＴＭＬＥｄｉｔｌｅｔ１２２１及びＳＶＧＥｄｉｔｌｅｔ１２２２を含む。
【０１４５】
図１２（ｂ）は、ボキャブラリコネクションに関連する更なる詳細を示す。ボキャブラリコネクションは、前述したように、文書処理システムの重要な特徴であり、２つの異なる方法で文書の整合のとれた表現及び表示を可能とする。ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３を保持するＶＣＭａｎａｇｅｒ３０２は、ボキャブラリコネクションサブシステムの一部である。図１２（ｃ）で示すように、ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３は、文書のＣｏｎｎｅｃｔｏｒ３０４を生成する。前述したように、Ｃｏｎｎｅｃｔｏｒは、ソースＤＯＭ中のノードを監視し、２つの表現の間の整合性を維持するために、デスティネーションＤＯＭ中のノードを修正する。
【０１４６】
Ｔｅｍｐｌａｔｅ３１７は、いくつかのノードの変換ルールを表す。ボキャブラリコネクション記述子（ＶＣＤ）ファイルは、特定のパス又はルールを満たす要素又は要素の集合を他の要素に変換するいくつかのルールを表すＴｅｍｐｌａｔｅのリストである。Ｔｅｍｐｌａｔｅ３１７及びＣｏｍｍａｎｄＴｅｍｐｌａｔｅ３１３１は、全てＶＣＭａｎａｇｅｒ３０２にアタッチされる。ＶＣＭａｎａｇｅｒは、ＶＣＤファイル中の全てのセクションを管理するオブジェクトである。１つのＶＣＤファイルに対して、１つのＶＣＭａｎａｇｅｒオブジェクトが生成される。
【０１４７】
図１２（ｃ）は、Ｃｏｎｎｅｃｔｏｒに関連する更なる詳細を提供する。ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３は、ソース文書からＣｏｎｎｅｃｔｏｒを生成する。ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３は、Ｖｏｃａｂｕｌａｒｙ、Ｔｅｍｐｌａｔｅ、及びＥｌｅｍｅｎｔＴｅｍｐｌａｔｅにアタッチされ、それぞれ、ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｏｒ、ＴｅｍｐｌａｔｅＣｏｎｎｅｃｔｏｒ、ＥｌｅｍｅｎｔＣｏｎｎｅｃｔｏｒを生成ずる。
【０１４８】
ＶＣＭａｎａｇｅｒ３０２は、ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３を保持する。Ｖｏｃａｂｕｌａｒｙを生成するために、対応するＶＣＤファイルが読み込まれる。こうして、ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３が生成される。このＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３は、Ｚｏｎｅを生成するＺｏｎｅＦａｃｔｏｒｙ及びＣａｎｖａｓを生成するＥｄｉｔｌｅｔに関連する。
【０１４９】
つづいて、ターゲットボキャブラリのＥｄｉｔｌｅｔＳｅｒｖｉｃｅが、ＶＣＣａｎｖａｓを生成する。ＶＣＣａｎｖａｓも、ソースＤＯＭツリー又はＺｏｎｅにおけるＡｐｅｘＮｏｄｅのＣｏｎｎｅｃｔｏｒを生成する。必要に応じて、子のＣｏｎｎｅｃｔｏｒが再帰的に生成される。ＣｏｎｎｅｃｔｏｒＴｒｅｅは、ＶＣＤファイル中のテンプレートの集合により生成される。
【０１５０】
テンプレートは、マークアップ言語の要素を他の要素に変換するためのルールの集合である。例えば、各テンプレートは、ソースＤＯＭツリー又はＺｏｎｅにマッチされる。適切にマッチした場合には、頂点Ｃｏｎｎｅｃｔｏｒが生成される。例えば、テンプレート「Ａ／＊／Ｄ」は、間にどんなノードがあるかに関係なく、ノードＡで始まりノードＤで終わる全ての枝に合致する。同様に、「／／Ｂ」は、ルートからの全ての「Ｂ」ノードに一致する。
【０１５１】
Ｍ．ＣｏｎｎｅｃｔｏｒＴｒｅｅに関係するＶＣＤファイルの例
特定の文書と関係する処理を説明する例を続ける。ドキュメントタイトルのある「ＭｙＳａｍｐｌｅＸＭＬ」というタイトルの文書が文書処理システムにロードされる。図１３は、「ＭｙＳａｍｐｌｅＸＭＬ」ファイルのための、ＶＣＭａｎａｇｅｒ及びＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙＴｒｅｅを用いたＶＣＤスクリプトの例を示す。スクリプトファイル中のボキャブラリセクション、テンプレートセクションと、ＶＣＭａｎａｇｅｒにおける対応するコンポーネントが示される。タグ「ｖｃｄ：ｖｏｃａｂｕｌａｒｙ」において、属性「ｍａｔｃｈ」は「ｓａｍｐｌｅ：ｒｏｏｔ」、「ｌａｂｅｌ」は「ＭｙＳａｍｐｌｅＸＭＬ」、「ｃａｌｌ−ｔｅｍｐｌａｔｅ」は「ｓａｍｐｌｅ ｔｅｍｐｌａｔｅ」となっている。
【０１５２】
この例では、Ｖｏｃａｂｕｌａｒｙは、「ＭｙＳａｍｐｌｅＸＭＬ」のＶＣＭａｎａｇｅｒにおいて「ｓａｍｐｌｅ：ｒｏｏｔ」として頂点要素を含む。対応するＵＩラベルは、「ＭｙＳａｍｐｌｅＸＭＬ」である。テンプレートセクションにおいて、タグは「ｖｃｄ：ｔｅｍｐｌａｔｅ」であり、名前は「ｓａｍｐｌｅ：ｔｅｍｐｌａｔｅ」である。
【０１５３】
Ｎ．ファイルがシステムにロードされる方法の詳細な例
図１４−１８は、文書「ＭｙＳａｍｐｌｅＸＭＬ」のロードについての詳細な記述を示す。図１４（ａ）に示されるステップ１では、文書がストレージ１４０５からロードされる。ＤＯＭＳｅｒｖｉｃｅは、ＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ１４０１と対応するＤＯＭツリー及びＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１４０６を生成する。ＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ１４０１は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１４０６にアタッチされる。文書は、ＸＨＴＭＬ及びＭｙＳａｍｐｌｅＸＭＬのサブツリーを含む。ＸＨＴＭＬのＡｐｅｘＮｏｄｅ１４０３は、タグ「ｘｈｔｍｌ：ｈｔｍｌ」が付されたＸＨＴＭＬの最上のノードである。「ＭｙＳａｍｐｌｅＸＭＬ」のＡｐｅｘＮｏｄｅ１４０４は、タグ「ｓａｍｐｌｅ：ｒｏｏｔ」が付された「ＭｙＳａｍｐｌｅＸＭＬ」の最上ノードである。
【０１５４】
図１４（ｂ）に示されるステップ２では、ＲｏｏｔＰａｎｅが文書のＸＨＴＭＬＺｏｎｅ、Ｆａｃｅｔ、及びＣａｎｖａｓを生成する。Ｐａｎｅ１４０７、ＸＨＴＭＬＺｏｎｅ１４０８、ＸＨＴＭＬＣａｎｖａｓ１４０９、及びＢｏｘＴｒｅｅ１４１０が、ＡｐｅｘＮｏｄｅ１４０３に対応して生成される。
【０１５５】
図１４（ｃ）に示されるステップ３では、ＸＨＴＭＬＺｏｎｅが知らないタグ「ｓａｍｐｌｅ：ｒｏｏｔ」を発見し、ＨＴＭＬＣａｎｖａｓの領域からＳｕｂＰａｎｅを生成する。
【０１５６】
図１５に示されるステップ４では、ＳｕｂＰａｎｅが「ｓａｍｐｌｅ：ｒｏｏｔ」を扱うことができ、適切なＺｏｎｅを生成可能なＺｏｎｅＦａｃｔｏｒｙを得る。このＺｏｎｅＦａｃｔｏｒｙは、ＺｏｎｅＦａｃｔｏｒｙを実行可能なＶｏｃａｂｕｌａｒｙ内にある。それは、「ＭｙＳａｍｐｌｅＸＭＬ」のＶｏｃａｂｕｌａｒｙＳｅｃｔｉｏｎの内容を含む。
【０１５７】
図１６に示されるステップ５では、「ＭｙＳａｍｐｌｅＸＭＬ」に対応するＶｏｃａｂｕｌａｒｙがＤｅｆａｕｌｔＺｏｎｅ１６０１を生成する。対応するＥｄｉｔｌｅｔが生成され、対応するＣａｎｖａｓを生成するためにＳｕｂＰａｎｅ１５０１が提供される。Ｅｄｉｔｌｅｔは、ＶＣＣａｎｖａｓを生成する。そして、それはＴｅｍｐｌａｔｅＳｅｃｔｉｏｎを呼ぶ。ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙＴｒｅｅも含まれている。ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙＴｒｅｅは、ＣｏｎｎｅｃｔｏｒＴｒｅｅとなる全てのＣｏｎｎｅｃｔｏｒを生成する。文書のＸＨＴＭＬコンテンツに関係するＡｐｅｘＮｏｄｅに対するＢｏｘＴｒｅｅとＸＨＴＭＬＣａｎｖａｓ同様に、ＲｏｏｔＰａｎｅとＸＨＴＭＬＺｏｎｅとの関係も前述の内容からすぐに理解されよう。
【０１５８】
図１７（ａ）に示されるステップ６では、ソースＤＯＭツリー間の対応をもとに、各ＣｏｎｎｅｃｔｏｒがデスティネーションＤＯＭオブジェクトを生成する。コネクタのうちのいくつかはｘｐａｔｈ情報を含んでいる。ｘｐａｔｈ情報は、変更／修正を監視する必要のあるソースＤＯＭツリーの部分集合を決定するために使用される１以上のｘｐａｔｈ表現を含む。
【０１５９】
図１７（ｂ）に示されるステップ７では、ソース・ＶＣ・ディスティネーションの関係に従って、ボキャブラリは、ソースＤＯＭのペインからデスティネーションＤＯＭツリーのＤｅｓｔｉｎａｔｉｏｎＰａｎｅを作成する。これは、ＳｏｕｒｃｅＰａｎｅに基づいてなされる。デスティネーションツリーのＡｐｅｘＮｏｄｅは、ＤｅｓｔｉｎａｔｉｏｎＰａｎｅ及び対応するＺｏｎｅにアタッチされる。ＤｅｓｔｉｎａｔｉｏｎＰａｎｅは、ＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓを生成し、文書をデスティネーションのフォーマットでレンダリングするためのデータ構造及びコマンドを構築する、自身のＥｄｉｔｌｅｔを提供される。
【０１６０】
図１８（ａ）は、対応するソースノードを持たず、デスティネーションツリーにのみ存在するノード上でイベントが発生したときのフローを示す。マウスイベント、キーボードイベントなど、Ｃａｎｖａｓが取得したイベントは、デスティネーションツリーを通過して、ＥｌｅｍｅｎｔＴｅｍｐｌａｔｅＣｏｎｎｅｃｔｏｒに伝達される。ＥｌｅｍｅｎｔＴｅｍｐｌａｔｅＣｏｎｎｅｃｔｏｒは対応するソースノードを持たないので、伝達されたイベントはソースノードに対する編集操作ではない。ＥｌｅｍｅｎｔＴｅｍｐｌａｔｅＣｏｎｎｅｃｔｏｒは、伝達されたイベントがＣｏｍｍａｎｄＴｅｍｐｌａｔｅに記述されたコマンドに合致すれば、それに対応するＡｃｔｉｏｎを実行する。合致するコマンドがなければ、ＥｌｅｍｅｎｔＴｅｍｐｌａｔｅＣｏｎｎｅｃｔｏｒは、伝達されたイベントを無視する。
【０１６１】
図１８（ｂ）は、ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒによりソースノードに対応づけられているデスティネーションツリーのノード上でイベントが発生したときのフローを示す。ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒは、ソースＤＯＭツリーのＸＰａｔｈで指定されたノードからテキストノードを取得して、デスティネーションＤＯＭツリーのノードにマッピングする。マウスイベント、キーボードイベントなど、Ｃａｎｖａｓが取得したイベントは、デスティネーションツリーを通過して、ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒに伝達される。ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒは、伝達されたイベントを、対応するソースノードの編集コマンドにマッピングし、Ｑｕｅｕｅ１０５３に積む。編集コマンドは、Ｆａｃｅｔを介して実行されるＤＯＭのＡＰＩコールの集合である。キューに積まれたコマンドが実行されると、ソースノードが編集される。ソースノードが編集されると、ミューテーションイベントが発行され、リスナーとして登録されたＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒにソースノードの変更が通知される。ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒは、ソースノードの変更を、対応するデスティネーションノードに反映させるように、デスティネーションツリーを再構築する。このとき、ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒを含むテンプレートに、「ｆｏｒ ｅａｃｈ」や「ｆｏｒ ｌｏｏｐ」などの制御文が含まれている場合、ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙがこの制御文を再評価し、ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒを再構築した後、デスティネーションツリーが再構築される。
【０１６２】
（取消操作の詳細）
本発明は、ＸＭＬなどのマークアップ言語を用いて用意された文書における変更を、プログラマがコマンドを直接取り消す操作を実装したり、ＤＯＭ構造を自身で編集し全ての変更を監視可能に設けたりするよりも、効率的な方式で取り消す機能に関する。
【０１６３】
開示された文書処理／管理システムにおいて取消機能を提供するための効率的な方法及び構成の必要性により、図８（ａ）及び図８（ｂ）に関連して既に説明した第１の方法が導かれた。ユーザにより発行されたコマンドに対応する文書７０５の編集は、ミューテーションイベント及びＤＯＭに対する変更として監視され、取消可能な編集として識別されて、後のアクセスのためにアンドゥ管理部７０６に格納される。別の方法も、ＤＯＭツリーを監視し、ＤＯＭツリー自身を、取消可能なコマンドにより受信される取消可能な編集を発行し、蓄積及び後のアクセスのためにアンドゥ管理部に送信するオブジェクトとして用いることにより実現される。いずれの場合も、ＤＯＭツリーとして文書を表現することに関連して２つの方法を説明したが、開示された技術はツリー又はグラフとして表現可能な任意の情報に適用可能であるから、本発明はＤＯＭツリー構造の使用に限られない。
【０１６４】
取消操作を実現するための最初の方法に関連して、図７（ａ）、８（ａ）、８（ｂ）、及び１１（ｂ）に関連して既に説明したように、図３に示したｃｏｎｎｅｃｔＸｐａｔｈの機能であるＸｐａｔｈを用いて、コネクタがソースノードを監視する。Ｘｐａｔｈは、テンプレートマッチングプロセスにおいてテンプレートを用いてソースノードを監視する。任意の種類のテンプレートマッチングがソースＤＯＭツリーのノードの部分集合を監視するための用いられてもよい。実際の例において、ＤＯＭツリーの部分集合は、ＤＯＭツリーの部分集合を監視し、部分集合がテンプレートにマッチするか否かを判定する基本的なテンプレート方式を用いて監視されてもよい。監視されたＤＯＭツリーの部分集合における任意の変更が検出されると、監視された部分集合における変更を反映するために、ＤＯＭツリーの表現が自動的に更新される。例えば、ＤＯＭに対する変更を監視することに関連して既に説明したように、テンプレート「Ａ／＊／Ｄ」は、間のノードが何であるかに関わらず、ノード「Ａ」で始まり、ノード「Ｄ」で終わるツリーの全ての枝を監視する。同様に、「／／Ｂ」は、ルートからの全てのノード「Ｂ」に対応する。
【０１６５】
ｃｏｎｎｅｃｔＸｐａｔｈにより監視されたノードの集合内のノードに変更が生じたとき、ＤＯＭ構造内の変更イベントのリスナーがこれを受信する。ミューテーションイベントリスナーは、変更イベントを識別すると、「ミューテーションイベント」通知を送信する。ｃｏｎｎｅｃｔＸｐａｔ（図１７参照）ｈは、このミューテーションイベントを取得する。ｃｏｎｎｅｃｔＸｐａｔｈは、ミューテーションイベントを評価する。監視されたノードに変更が生じると、値の変更を受信する１以上の機能が通知される。監視されたノードに影響を与える他のノードが存在する場合、これらのノードもリスナーに提供される。
【０１６６】
図１９（ａ）は、ｃｏｎｎｅｃｔＸｐａｔｈがＶＣとともに用いられた、変更ベースの取消操作の実装例を示す。編集される文書は、ＤＯＭ１９１０により表現される。ＤＯＭ１９１０は、ノードＡを頂点ノードとする複数のリンクされたノードＡ、Ｂ、Ｃ、Ｄ、及びＥを有する。編集の結果、波線により示されるように、別のノードＢがノードＡに追加される。ＶＣＤはルートからそれぞれの元の「Ｂ」ノードの表現を生成するように記述されている。この場合、この場合、ｃｏｎｎｅｃｔＸｐａｔｈは、テンプレート「／／Ｂ」のパスを充足する全てのノードを監視する。図から分かるように、実際のＤＯＭには、２つの「Ｂ」ノード１９０１、１９０２がある。第３の「Ｂ」ノード１９０３が編集されたＤＯＭに追加される。ｃｏｎｎｅｃｔＸｐａｔｈ１９０５はＤＯＭに対するこの変更１９０４をピックアップし、新規に生成された「Ｂ」ノードにマップする。ミューテーションイベント１９０４も、取消編集オブジェクトを生成し登録するために、アンドゥ管理部１９４０に提供される。
【０１６７】
必要であれば、適切なミューテーションイベントのみが実行されるように、文書の特定の部分が監視され、抽出される。
【０１６８】
図１９（ｂ）は、ＤＯＭの変更が取消可能な編集の生成及び保存をもたらす別の方式の概略的表現である。図１（ｂ）において、コマンドシステム１０５に関連して既に説明したように、本発明によれば、ＤＯＭに対する操作は、ユーザが定義可能なＤＯＭ操作である「コマンド」にカプセル化される。コマンドが実行されると、ＤＯＭはなされた変更のそれぞれについて「取消可能な編集」を発行し、ＵｎｄｏａｂｌｅＣｏｍｍａｎｄサービスは「取消可能な編集」を検出して、対応する取消操作を生成する。実行が終わると、まとめられた取消可能な編集が取消のためにアンドゥ管理部に登録される。
【０１６９】
再び図１９（ｂ）を参照して、ノードＡを頂点ノードとする複数のリンクされたノードＡ、Ｂ、Ｃ、Ｄ、及びＥを有するＤＯＭ１９１０のツリー状の表現が設けられる。ノードＡにつながる波線により示されるようにノードＢを変更する編集の結果、変更を指示した複数のＵｎｄｏａｂｌｅＣｏｍｍａｎｄ１９２０のうちの１つが変更の実行を検知し、ＵｎｄｏａｂｌｅＥｄｉｔ１９３０を生成させる。ＵｎｄｏａｂｌｅＥｄｉｔ１９３０は、与えられた変更を取り消す必要が生じたときのアクセスのために、アンドゥ管理部１９３０（図２のＵｎｄｏＭａｎａｇｅｒ２１２１に対応する）に格納される。編集は、文書のテキスト、図、チャート、画像、又は音楽及び映像要素のいずれであってもよい。
【０１７０】
図２０及び２１は、複合取消編集操作の図解及びチャート形式の流れをそれぞれ提供する。アンドゥプロセス２０００、２１００によれば、第１のフローステップ２１１０において、１以上のインスタンス２０１１、２０１２において発行された種々のコマンドのいすれかによるＤＯＭ２００５の操作又は変更ＤＯＭ２００５の変更のトリガとなる。ＤＯＭの操作は、このようなコマンド、例えば、図７（ａ）、８（ａ）、及び８（ｂ）におけるＵｎｄｏａｂｌｅＥｄｉｔＡｃｃｅｐｔｏｒ７０８に対応するＵｎｄｏａｂｌｅＣｏｍｍａｎｄ２０３０を介して発行されなければならない。このような変更は、ステップ２１２０において、ＤＯＭ２００５による１以上のＵｎｄｏａｂｌｅＥｄｉｔ２０２５、２０２６などの生成をもたらす。それぞれのＵｎｄｏａｂｌｅＥｄｉｔ２０２５、２０２６などは、ＵｎｄｏａｂｌｅＣｏｍｍａｎｄプロセス２０３０によりピックアップされる１以上の取消可能な編集オブジェクトに関連付けられ、ステップ２１３０において、発行されたコマンドの実行が終了するまで収集される。編集は細かい粒度で発行され、ＤＯＭに対する意味のある操作の集合を形成するように収集されなければならないので、複数の取消可能な編集オブジェクトの収集が必要である。図７（ａ）に関連して、この収集操作はＵｎｄｏＷｒａｐｐｅｒ７０７により実行される。収集された又はラップされた取消可能な編集オブジェクトは、ステップ２１４０に示されるように、アンドゥ管理部２０４０（図７（ａ）では７０６）に登録される。
【０１７１】
複数のＵｎｄｏａｂｌｅＥｄｉｔＣｏｍｍａｎｄが存在するとき、与えられた文書のために集められた「複合編集」２０５０がある。この場合、実行が完了すると、ＵｎｄｏａｂｌｅＣｏｍｍａｎｄ２０３０の１以上のＵｎｄｏａｂｌｅＥｄｉｔの集合がアンドゥ管理部５６０に登録される。
【０１７２】
ＵｎｄｏａｂｌｅＣｏｍｍａｎｄプロセスの実施例は、図２２−３２に示される複合文書の複合編集に関連した一連のスクリーンショットの形式で提供される。スクリーンショットは、複合文書に対するいくつかの編集を通じて、本発明の実施の形態に係る取消操作の流れを示す。文書自体は、画面上に表示されるＸＨＴＭＬ部分とＳＶＧ部分の組合せである。画面は、既知のＪａｖａ（登録商標）−Ｅｃｌｉｐｓｅプラットフォームに基づく。
【０１７３】
図２２に示した取消操作は、ＸＨＴＭＬ部分２２１０、ＳＶＧ部分２２２０、及び別のＸＨＴＭＬ部分２２３０を有する複合文書２２００の編集を含む。前述の説明に基づいて、編集操作は文書を表現するモデルであるＤＯＭの操作により実現されることが理解されよう。ＤＯＭに対する変更はＤＯＭにより発行され、アンドゥ管理部２０４０に収集され格納される変更及び／又は取消可能な編集を検知することにより監視される。ユーザにより入力される一連の編集コマンドとして、ＤＯＭが変更され、アンドゥ管理部のエントリが蓄積される。以前のエントリは上書き又は破壊されない。さらに、ＤＯＭが操作されると、文書のモデルとしてのＤＯＭの現バージョンが、文書の現在編集されたバージョンの表示を画面に描画するために用いられる。前述したように、ボックス方式を用いることにより、レンダリングのスピードを向上させることができる。同じ又はリンクされた文書の複数のＸＭＬコンテンツの間のリンクに基づいて、リンクされた全ての表示要素に編集が反映される。同様に、編集が逆戻り又は取り消されると、取消可能な編集オブジェクトを取得するためにアンドゥ管理部２０４０にアクセスし、ＤＯＭの変更により編集が逆戻りされる。後述するように、ＤＯＭの描画により編集の逆戻りが示される。
【０１７４】
図２３に関連して、「第１の編集」２３１０がＸＨＴＭＬ部分２１１０において文書２２００になされ、「第２の編集」２２２０がＳＶＧ部分２２２０になされる。その後、「第３の編集」２３３０がＸＨＴＭＬ部分２２１０になされる。本発明は、取消機能を確立し、処理する機能を有し、図２３の例に示したように、「第３の編集」２３３０、「第２の編集」２３２０、及び「第１の編集」２３１０に対するシームレスな取消操作を実現する。
【０１７５】
図２４は、ユーザの画面に表示された第１の編集２３１０、第２の編集２３２０、及び第３の編集２３３０と、ソースコーリスト２４００の対応するエントリ２４１０、２４２０、及び２４３０を並列して示す。
【０１７６】
上述したように、取消操作は、それぞれの取消編集をアンドゥオブジェクトとして格納又は登録したアンドゥ管理部２０４０にアクセスすることにより実行される。アンドゥオブジェクトの取得により、文書のモデルとしてのＤＯＭに更なる操作が行われ、実行された編集を逆に勧めることによりＤＯＭが元に戻される。後述するように、編集が元に戻されたことが、画面上にＤＯＭをレンダリングすることにより示される。こうして、図２５に示すように、入力時において最後の編集であった「第３の編集」から「取消」が開始され、追加されたＸＨＴＭＬの編集の最後の文字から取り消しが始まる。図示するように、最後の編集の最後の文字は「ｔ」であり、図の２５１０に文字「ｔ」が取り消された状態が示される。取消操作は、ＸＨＴＭＬアプリケーションに対して、編集が完了するまで文字毎に続行される。つづいて、取消操作は、用いられたアプリケーション（ＸＨＴＭＬ、ＳＶＧ、ＭＡＴＨＭＬなど）にかかわらず、最後から２番目に入力された編集へ続く。
【０１７７】
例によれば、最後から２番目の編集は「第２の編集」２３２０であったので、取消処理により「第３の編集」が削除されると、次の取消操作は第２の編集にうつり、図２６に示すように、その全体が削除されるまで続けられる。第２の編集は１つの操作により追加されたので、１つの取消操作で削除可能である。第１の編集２３１０はまだ残っている。
【０１７８】
図２７に示すように、更なる取消操作は「第１の編集」２３１０にうつり、本発明の一形態によれば、ＸＨＴＭＬによる入力は文字毎に扱われるので、２７１０で示される文字「ｔ」の削除から開始される。文書のＸＨＴＭＬ部分において、取消操作を目的とした文字毎の取扱が望ましいが、単語毎、文毎など、必要であれば他のルールに変更可能であることは明らかである。
【０１７９】
取消操作が完了し、第１、第２、及び第３の編集の全てが取り消されると、図２８に示した画面となる。
【０１８０】
図２９は、コマンドベースの取消操作を示す。この「ｄａｉｌｙ−ｒｅｐｏｒｔ２．ｖｃｄ」において、コマンド「ａｄｄ−ｒｅｐｏｒｔ」が定義される。このコマンドを実行すると、レポートが追加される。その他のコマンド、例えば、「レポートの削除」、「画像の削除」、「新規ＳＶＧ」、「テーブル挿入」などが定義されてもよい。コマンドの実行は、編集の準備、実行（図１０に関連して説明した方式で図２の「Ｆａｃｅｔ」２０２２サービスを用いて）、登録を含む。コマンドが実行され登録されると、取消操作が可能となる。取消操作は、コマンド全体を取り消す効果を有する。ユーザに提示されるコマンド自体を図３０に示す。
【０１８１】
タグ「ｄｉａｒｙ：ｒｅｐｏｒｔ」及びその子が図３１において追加される。この画面から取消操作を実行すると、図３２にようになる。１つの取消操作でコマンド自体を取り消すことができる。
【０１８２】
上記の説明から、ＤＯＭの監視が変更の監視によるものであっても、取消編集コマンドの識別によるものであっても、後続の逆戻りのために取消イベントオブジェクトの収集及び登録をもたらす。検知、識別、及び登録は、イベントベースで行われてもよいし、ボックスツリー方式を用いてイベントを収集することにより行われてもよい。後者の場合、複数のイベントが単一のボックスに発生するので、変更されたがまだ描画されていないボックスの内容を識別する「ダーティーフラグ」技術が用いられてもよい。こうして、描画は、異なるスレッドを用いた並列的な実行により、文書に対する関連した複数の変更が完了するまで、適切な期間延期される。
【０１８３】
さらに、開示された取消技術により、プログラマは、コマンドを用いる所定のテンプレートを参照するだけで取消操作のためのコマンドを用意することができる。この方式では、Ｊａｖａ（登録商標）言語の抽象クラスとして編集操作を実装可能である。
【０１８４】
本発明の他の改良や変更は、上記の開示及び教示から当業者には明らかである。したがって、本発明の特定の実施例のみをとくに例示したが、本発明の趣旨及び範囲から逸脱することなく、それらに種々の変更が可能であることは明らかである。
【図面の簡単な説明】
【０１８５】
【図１（ａ）】開示した文書処理システムの典型的な実装の基本となるコンポーネントの標準的な配置を示す図である。
【図１（ｂ）】典型的な文書処理システムの全体的なブロック図である。
【図１（ｃ）】典型的な文書処理システムの全体的なブロック図である。
【図２】「Ｄｏｃｕｍｅｎｔ Ｍａｎａｇｅｒ」の典型的な実装について詳細を示す図である。
【図３】「Ｖｏｃａｂｕｌａｒｙ Ｃｏｎｎｅｃｔｉｏｎ」サブシステム３００の典型的な実装について詳細を示す図である。
【図４】図４（ａ）は、「Ｐｒｏｇｒａｍ Ｉｎｖｏｋｅｒ」及びそれに関連する他のコンポーネントの典型的な実装について詳細を示す図であり、図４（ｂ）は、「Ｓｅｒｖｉｃｅ Ｂｒｏｋｅｒ」及びそれに関連する他のコンポーネントの典型的な実装について詳細を示す図であり、図４（ｃ）は、「Ｓｅｒｖｉｃｅ」の典型的な実装について詳細を示す図であり、図４（ｄ）は、「Ｓｅｒｖｉｃｅ」の例を示す図であり、図４（ｅ）は、「Ｐｒｏｇｒａｍ Ｉｎｖｏｋｅｒ」１０３と「Ｕｓｅｒ Ａｐｐｌｉｃａｔｉｏｎ」１０６との関係について詳細を示す図である。
【図５】図５（ａ）は、「Ｐｒｏｇｒａｍ Ｉｎｖｏｋｅｒ」上に展開される「Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ」の構造について詳細を示す図であり、図５（ｂ）は、「Ｆｒａｍｅ」、「ＭｅｎｕＢａｒ」、「ＳｔａｔｕｓＢａｒ」の関係の例を示す図であり、
【図６】図６（ａ）は、「Ａｐｐｌｉｃａｔｉｏｎ Ｃｏｒｅ」の典型的な実装について詳細を示す図であり、図６（ｂ）は、「Ｓｎａｐ Ｓｈｏｔ」の典型的な実装について詳細を示す図である。
【図７】図７（ａ）は、「Ａｐｐｌｉｃａｔｉｏｎ Ｃｏｒｅ」の典型的な実装について詳細を示す図であり、図７（ｂ）は、ＡからＥの「Ｄｏｃｕｍｅｎｔ」の組がどのように階層化されるのかの例を示す図であり、図７（ｃ）は、図７（ｂ）で示した「Ｄｏｃｕｍｅｎｔ」の階層がスクリーン上でどのように見えるのかの例を示す図である。
【図８】「Ｕｎｄｏ Ｆｒａｍｅｗｏｒｋ」及び「Ｕｎｄｏ Ｃｏｍｍａｎｄ」の典型的な実装の詳細を示す図である。
【図９】図９（ａ）は、図１（ｂ）、図１（ｃ）で示す文書処理システム内に「Ｄｏｃｕｍｅｎｔ」がどのように展開されるかの全体像を示す図であり、図９（ｂ）は、ＭＶＣパラダイムを使って、「Ｚｏｎｅ」の構造の概要を示す図である。
【図１０】本発明に従って、「Ｄｏｃｕｍｅｎｔ」とその様々な表現の例を示す図である。
【図１１】図１１（ａ）は、図１０で示す「Ｄｏｃｕｍｅｎｔ」のＸＨＴＭＬコンポーネントに対する「ＭＶ」関係の概要を示す図であり、図１１（ｂ）は、図１１（ａ）で示す「Ｄｏｃｕｍｅｎｔ」に対するボキャブラリコネクションを示す図である。
【図１２】プラグインサブシステム、ボキャブラリコネクション、コネクタそれぞれの典型的な実装について詳細を示す図である。
【図１３】ＭｙＳａｍｐｌｅＸＭＬに対して、ボキャブラリコネクションマネージャとコネクタファクトリーツリーを使用するＶＣＤスクリプトの例を示す図である。
【図１４】図１（ｂ）の典型的な文書処理システムの中に、文書例ＭＹＳａｍｐｌｅＸＭＬが展開されるステップ０から３を示した図である。
【図１５】図１（ｂ）の典型的な文書処理システムの中に、文書例ＭｙＳａｍｐｌｅＸＭＬが展開されるステップ４を示した図である。
【図１６】図１（ｂ）の典型的な文書処理システムの中に、文書例ＭｙＳａｍｐｌｅＸＭＬが展開されるステップ５を示した図である。
【図１７（ａ）】図１（ｂ）の典型的な文書処理システムの中に、文書例ＭｙＳａｍｐｌｅＸＭＬが展開されるステップ６を示した図である。
【図１７（ｂ）】図１（ｂ）の典型的な文書処理システムの中に、文書例ＭｙＳａｍｐｌｅＸＭＬが展開されるステップ７を示した図である。
【図１８】図１８（ａ）は、対応するソースノードを持たず、ディスティネーションツリーのみに依存するノードで発生するイベントのフローを示す図であり、図１８（ｂ）は、「ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒ」によりソースノードと連動するディスティネーションツリーのノードで発生するイベントのフローを示す図である。
【図１９（ａ）】ＤＯＭの変更が取消可能コマンドの生成及び保存をもたらす様子を概略的に示す図である。
【図１９（ｂ）】ＤＯＭの変更が取消可能コマンドの生成及び保存をもたらす様子を概略的に示す図である。
【図２０】ＤＯＭの変更が複合的な編集をもたらす様子を概略的に示す図である。
【図２１】図２０でなされた変更により表現される手順を示すフローチャートである。
【図２２】ＸＨＴＭＬ及びＳＶＧコンテンツを有する複合文書を処理における取消操作の流れの第１のスクリーンショットを示す図である。
【図２３】第１から第３の編集を行った図２２の文書のスクリーンショットを示す図である。
【図２４】ソースコードを付した図２２の文書のスクリーンショットを示す図である。
【図２５】ＸＨＴＭＬの第３の編集を文字ごとに取り消す操作のスクリーンショットを示す図である。
【図２６】第３（ＸＨＴＭＬ）及び第２（ＳＶＧ）の編集の取消操作のスクリーンショットを示す図である。
【図２７】残りの第１の編集の取消操作のスクリーンショットを示す図である。
【図２８】全ての編集が実行されていない状態のスクリーンショットを示す図である。
【図２９】コマンドベースの取消操作のスクリーンショットを示す図である。
【図３０】図２９のコマンド自体のスクリーンショットを示す図である。
【図３１】「ｄｉａｒｙ：ｒｅｐｏｒｔ」要素が追加された状態のスクリーンショットを示す図である。
【図３２】取消操作の結果のスクリーンショットを示す図である。
【符号の説明】
【０１８６】
【技術分野】
【０００１】
本開示は、情報のある形式の表現における変更を、同じ情報の別の形式の表現に自動的に伝達する技術を開示する。とくに、本技術は、ソースＤＯＭツリーにより表現された文書に対する変更を、別の表現に描写されたデスティネーションＤＯＭツリーへ自動的に伝達することに関する。
【背景技術】
【０００２】
この出願は、「文書処理及び文書管理システム」という名称で、２００４年８月２日に出願され、同時継続している米国仮出願（出願番号６０／５９２，３６９）からの優先権を主張する。
【０００３】
インターネットの出現により、ユーザによって処理され管理される文書の数が、ほぼ指数関数的に増加してきた。インターネットの核を形成するウェブ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）は、そのような文書データの大きな受け皿となっている。ウェブは、文書に加えて、このような文書の情報検索システムを提供する。これらの文書は、通常、マークアップ言語により記述される。マークアップ言語のシンプルかつポピュラーな例の一つにＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）がある。このような文書は、ウェブの他の位置に格納されている他の文書へのリンクをさらに含む。ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）は、さらに高度でポピュラーなマークアップ言語である。ウェブ文書にアクセスし、閲覧するためのシンプルなブラウザが、Ｊａｖａ（登録商標）のようなオブジェクト指向のプログラミング言語で開発されている。
【０００４】
マークアップ言語により記述された文書は、通常、ブラウザや他のアプリケーションの中では、ツリーデータ構造の形で表現される。この構造は、文書を構文解析した結果のツリーに相当する。ＤＯＭ（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）は、文書を表現し、操作するために使用される、よく知られたツリーベースのデータ構造モデルである。ＤＯＭは、ＨＴＭＬやＸＭＬ文書などを含む文書を表現するための標準的なオブジェクトのセットを提供する。ＤＯＭは、文書内のコンポーネントを表現するオブジェクトがどのようにつながっているかという標準モデルと、それらのオブジェクトにアクセスしたり操作したりするための標準インタフェイスという、２つの基本的なコンポーネントを含む。
【０００５】
アプリケーション開発者は、独自のデータ構造やＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）へのインタフェイスとしてＤＯＭをサポートすることができる。他方、文書を作成するアプリケーション開発者は、彼らのＡＰＩの独自インタフェイスではなく、ＤＯＭの標準インタフェイスを使用することができる。したがって、標準を提供するというその能力により、ＤＯＭは、様々な環境、特にウェブにおいて、文書の相互利用を促進させるために有効である。ＤＯＭのいくつかのバージョンが定義されており、異なるプログラミング環境及びアプリケーションによって使用されている。
【０００６】
ＤＯＭツリーは、対応するＤＯＭの内容に基づいた文書の階層的表現である。ＤＯＭツリーは「根（ルート）」、及びルートから発生する１つ以上の「節（ノード）」を含む。ルートが文書全体を表す場合もある。中間のノードは、例えば、テーブル及びそのテーブル中の行及び列のような要素を表すことができる。ＤＯＭツリーの「葉」は、通常、それ以上分解できないテキストや画像のようなデータを表す。ＤＯＭツリーの各ノードは、フォント、サイズ、色、インデントなど、ノードによって表される要素のパラメータを記述する属性に関連付けられてもよい。
【０００７】
ＨＴＭＬは、文書を作成するために一般に用いられる言語であるが、フォーマット及びレイアウト用の言語であり、データ記述のための言語ではない。ＨＴＭＬドキュメントを表現するＤＯＭツリーのノードは、ＨＴＭＬのフォーマッティングタグとして予め定義されたエレメントであって、通常、ＨＴＭＬは、データの詳述や、データのタギング／ラベリングのための機能を提供しないので、ＨＴＭＬドキュメント中のデータに対するクエリを定式化することは多くの場合困難である。
【０００８】
ネットワーク設計者たちの目指すものは、ウェブ上の文書がソフトウェアアプリケーションによってクエリされたり処理されたりできるようにすることである。表示方法とは無関係で、階層的に構造化された言語であれば、そのようにクエリされ処理されることができる。ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）のようなマークアップ言語は、これらの機能を提供することができる。
【０００９】
ＨＴＭＬとは逆に、ＸＭＬのよく知られた利点は、文書の設計者が自由に定義可能な「タグ」を使用して、データ要素にラベルを付けることが可能である点である。このようなデータ要素は、階層的に構造化することができる。さらに、ＸＭＬ文書は、文書内で用いられるタグ及びそれらの相互関係の「文法」を記述した文書型定義を含むことができる。構造化されたＸＭＬ文書の表示方法を定義するために、ＣＳＳ（Ｃａｓｃａｄｉｎｇ Ｓｔｙｌｅ Ｓｈｅｅｔ）又はＸＳＬ（ＸＭＬ Ｓｔｙｌｅ Ｌａｎｇｕａｇｅ）が使用される。ＤＯＭ、ＨＴＭＬ、ＸＭＬ、ＣＳＳ、ＸＳＬ及び関連する言語の特徴に関する付加的な情報は、ウェブからも得ることができる。（例えば、ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／）
【００１０】
Ｘｐａｔｈは、ＸＭＬ文書の部分の位置を指定するために共通のシンタックス及びセマンティクスを提供する。機能性の例として、ＸＭＬ文書に対応するＤＯＭツリーのトラバース（移動）がある。それは、ＸＭＬ文書の様々な表現に関連した文字列、数、及びブーリアン文字の操作のための基本的な機能を提供する。Ｘｐａｔｈは、ＸＭＬ文書の見た目のシンタックス、例えば、テキストとしてみたときに何行目であるとか何文字目であるとかといった文法ではなく、ＤＯＭツリーなどの抽象的・論理的な構造において動作する。Ｘｐａｔｈを使用することにより、例えばＸＭＬ文書のＤＯＭツリー内の階層的構造を通じて場所を指定することができる。アドレシングのための使用の他に、Ｘｐａｔｈは、ＤＯＭツリー中のノードがパターンにマッチするか否かをテストするために使用されるようにも設計されている。
【００１１】
ＸＰａｔｈに関する更なる詳細は、ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｘｐａｔｈで得ることができる。
【００１２】
ＸＭＬの既知の利点及び特徴により、マークアップ言語（例えばＸＭＬ）で記述された文書を扱うことができ、文書を作成及び修正するためのユーザフレンドリーなインタフェイスを提供することができる、効果的な文書処理システムが求められる。
【００１３】
ＸＭＬは、複雑な文書のための、またネットワークなどを介して複数のドキュメントにまたがってデータを共有するのに特に適した形式である。ＸＭＬ文書を作成、表示、編集するための多くのアプリケーションが開発されている（たとえば、特許文献１参照）。
【特許文献１】特開２００１−２９０８０４号公報
【発明の開示】
【発明が解決しようとする課題】
【００１４】
ボキャブラリは、任意に定義することが許されており、理論上、無限に多くのボキャブラリが存在しうる。これらのボキャブラリの全てに対応して専用の表示・編集環境を提供するのは現実的ではない。従来、専用の編集環境が用意されていないボキャブラリにより記述された文書を編集する場合、テキストデータにより構成された文書のソースを直接テキストエディタなどで編集していた。
【００１５】
既存のアプリケーションは、処理・管理できるＸＭＬ文書に大きな制限があったため、幅広く文書を受け入れることができなかった。例えばＸＭＬ文書処理システムの中には、ＸＭＬ文書の中で、文書の内容を表し、表示メソッドとは関係ない文字列を表示することができるものがある。この機能は一見優れているようであるが、実際にはユーザがＸＭＬ文書を直接編集できないという不都合な点も持つ。この問題を解決するために、ＸＭＬ文書処理システムの中には、ＸＭＬの入力を受け付ける画面を特別にデザインするものもある。しかし、画面デザインの柔軟性は限られていた。それらのＸＭＬ文書処理システムにおいては、前述の画面デザインは事前にハードコーディングされている必要があったからである。
【００１６】
この制限を考慮して、ＸＳＬＴは標準的なスタイルシート言語の一つとして開発された。このような技術によりユーザはハードコーディングから解放され、ＸＭＬ文書を表示するために適用されるメソッドとも混在可能になった。しかし、ＸＳＬＴを使用しても、特定の形式のＸＭＬ文書の編集はできない場合があった。
【００１７】
さらに、それらのＸＭＬ文書処理システムは、「スキーマ」に定義された順序をあてにしている。そのため、一旦スキーマが決定されると、処理システムで処理可能なのは、そのスキーマの構造に最上位から合致するＸＭＬ文書のみであった。換言すると、それらのシステムは過度に制限的で柔軟性を欠いている。
【課題を解決するための手段】
【００１８】
今回開示するシステムは、前述のような制限が無い。完全なＸＭＬ文書の構造は固定的に決定される必要はない。様々な構造が複合したＸＭＬ文書であっても、ＸＭＬ文書をより小さな部分に分割して安全に処理できる。それぞれの小さい部分は、より柔軟性を高めるため、個別に編集モジュールに振り分けられる。加えて、編集モジュールは、プラグインとして提供されるのが望ましい。さらにユーザは、何らのハードコーディングをすることなく柔軟性のある画面デザインを実装できる。いわゆるＷＹＳＩＷＹＧ（Ｗｈａｔ Ｙｏｕ Ｓｅｅ Ｉｓ Ｗｈａｔ Ｙｏｕ Ｇｅｔ）を実現できる。
【００１９】
ここで説明されるシステムの構成のうちのいくつかは、ＭＶＣ（Ｍｏｄｅｌ−Ｖｉｅｗ−Ｃｏｎｔｒｏｌｌｅｒ）と呼ばれる、よく知られたＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）パラダイムを用いて説明される。ＭＶＣパラダイムは、アプリケーション又はアプリケーションのインタフェイスの一部を、３つの部分、すなわち、モデル、ビュー、コントローラに分割する。ＭＶＣは、元は、ＧＵＩの世界に、従来の入力、処理、出力の役割を割り当てるために開発された。
【００２０】
［入力］ → ［処理］ → ［出力］
【００２１】
［コントローラ］→ ［モデル］ → ［ビュー］
【００２２】
ＭＶＣパラダイムによれば、外界のモデリング、ユーザへの視覚的なフィードバック、及びユーザの入力は、モデル（Ｍ）、ビュー（Ｖ）、及びコントローラ（Ｃ）オブジェクトにより分離されて扱われる。コントローラは、ユーザからのマウスとキーボード入力のような入力を解釈し、これらのユーザアクションを、適切な変更をもたらすためにモデル及び／又はビューに送られるコマンドにマップするように作用する。モデルは、１以上のデータ要素を管理するように作用し、その状態に関するクエリに応答し、状態を変更する指示に応答する。ビューは、ディスプレイの長方形の領域を管理するように作用し、グラフィクスとテキストの組合せによりユーザにデータを提示する機能を有する。
【００２３】
ワードプロセッサなどの標準的な文書生成アプリケーションでは、ユーザは文書を生成又は編集するときに、特定の動作を実行し、後で取り消したいことがある。このように、ユーザの動作を取り消すような避けられない必要性が予期されるので、「逆」操作が定義される必要がある。従来、逆操作の定義はプログラマ自身により生成されていた。広く行われている技術として、「取消可能な」操作が別の「取消可能な」操作を結合され、結合された取消可能な操作が実現される。しかし、プログラマによる介入のための要求は、高価でかつ非効率的である。逆操作をプログラムするためにプログラマを必要としない、取消可能なコマンドの定義が望まれる。
【００２４】
この目的の達成は、文書を生成するときに生じる様々な操作の取消は、適用される編集環境によって異なるという事実により阻害される。例えば、テキストエディタは、文字入力ごとに取消操作を有する。しかし、ＸＭＬのＤＯＭ編集環境においては、最小の取消可能な単位はＤＯＭの変更であるから、操作の取消は注意深く取り扱われる必要がある。しかし、ＤＯＭ変更を単位とした取消操作の実行は、ユーザにとっては無益で意味が無く、ＸＭＬ文書全体の不整合を生じさせる可能性もある。
【００２５】
したがって、ＸＭＬ環境では、ＤＯＭに対する取消操作を意味のある粒度で行う必要がある。１つの方法は、ＤＯＭにアクセスするメソッドを提供する文書モデルを提供し、全ての取消操作をメソッドベースで行うことである。このようなメソッドベースの方法は、任意のＤＯＭ操作をシームレスに取消可能とするが、ＤＯＭと相互作用するプログラマ独自の方法を記述することができないという不利益が生じる。全ての相互作用は定義済みのメソッドを通じて行われる必要がある。さらに、このメソッドを追加するためには、文書のモデル全体が変更される必要がある。
【００２６】
このように、逆操作を簡易に定義し、プログラマにより逆操作をプログラムする必要のない取消可能なコマンドを提供可能とする方法及び構成が必要である。
【００２７】
本発明のある態様は、ＤＯＭにより表現されたＸＭＬ文書の取消を提供する方法である。この方法は、前記ＤＯＭの変更を検知する工程と、前記ＤＯＭにおける検知された変更に対応する編集命令を生成する工程と、コマンドにより前記編集命令を検知する工程と、複数の検知された前記編集命令を収集する工程と、収集された前記編集命令を登録する工程と、を備える。
【発明を実施するための最良の形態】
【００２８】
以下、添付の図面を参照して、発明の典型的な実施例を詳細に記述する。
【００２９】
本発明の境界と範囲を定めるのは請求の範囲のみである。説明する実施の形態や実施例、効果は単なる例示であり、本発明を制限するものと考えてはならない。本発明の詳細な説明は説明を意図しており、請求の範囲を制限するものではない。当業者には多くの代替例、改造例や変形例が理解される。
【００３０】
Ａ．文書処理システムの全体構成
図１（ａ）は、後述するタイプの文書処理システムの基礎として機能する要素の標準的な構成例を示す。構成１０は、通信経路によりメモリ１２に接続されたＣＰＵ又はマイクロプロセッサ１１などの形式のプロセッサを含む。メモリ１２は、現在又は将来に利用可能な任意のＲＯＭ及び／又はＲＡＭの形式であってもよい。通信経路は、典型的にはバスとして設けられる。マウス、キーボード、音声認識システムなどのユーザ入力装置１４及び表示装置１５（又は他のユーザインタフェイス）に対する入出力インタフェイス１６も、プロセッサ１１とメモリ１２の通信のためのバスに接続される。この構成は、スタンドアロンであってもよいし、複数の端末及び１以上のサーバが接続されてネットワーク化された形式であってもよいし、既知のいかなる方式により構成されてもよい。本発明は、これらのコンポーネントの配置、集中又は分散されたアーキテクチャー、あるいは様々なコンポーネントの通信方法により制限されない。
【００３１】
さらに、本システム及びここで議論される実施例は、様々な機能性を提供するいくつかのコンポーネント及びサブコンポーネントを含むものとして議論される。これらのコンポーネント及びサブコンポーネントは、注目された機能性を提供するために、ハードウェアとソフトウェアの組合せだけでなく、ハードウェアのみ、ソフトウェアのみによっても実現されうる。さらに、ハードウェア、ソフトウェア、及びそれらの組合せは、汎用の計算装置、専用のハードウェア、又はそれらの組合せにより実現されうる。したがって、コンポーネント又はサブコンポーネントの構成は、コンポーネント又はサブコンポーネントの機能性を提供するための特定のソフトウェアを実行する汎用／専用の計算装置を含む。
【００３２】
図１（ｂ）は、文書処理システムの一例の全体のブロック図を示す。このような文書処理システムにおいて文書が生成され編集される。これらの文書は、例えばＸＭＬなど、マークアップ言語の特徴を有する任意の言語により記述されてもよい。また、便宜上、特定のコンポーネント及びサブコンポーネントの用語及び表題を創造した。しかしながら、これらは、この開示の一般的な教示の範囲を制限するために解釈されるべきではない。
【００３３】
文書処理システムは、２つの基本的な構成を有するものととらえることができる。第１の構成は、文書処理システムが動作する環境である「実行環境」１０１である。例えば、実行環境は、文書の処理中及び管理中に、ユーザだけでなくシステムも支援する、基本的なユーティリティ及び機能を提供する。第２の構成は、図１（ｃ）に示す、実行環境において走るアプリケーションから構成される「アプリケーション」１０２である。これらのアプリケーションは、文書自身及び文書の様々な表現を含む。
【００３４】
１．実行環境
実行環境１０１のキーとなるコンポーネントはＰｒｏｇｒａｍＩｎｖｏｋｅｒ（プログラムインボーカ：プログラム起動部）１０３である。ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３は、文書処理システムを起動するためにアクセスされる基本的なプログラムである。例えば、ユーザが文書処理システムにログオンして開始するとき、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３が実行される。ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３は、例えば、文書処理システムにプラグインとして加えられた機能を読み出して実行させたり、アプリケーションを開始して実行させたり、文書に関連するプロパティを読み出すことができる。ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３の機能はこれらに限定されない。ユーザが実行環境内で実行されるように意図されたアプリケーションを起動したいとき、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３は、そのアプリケーションを見つけ、それを起動して、アプリケーションを実行する。例えばユーザが文書（実行環境ではアプリケーションとして扱われる）を編集したいときには、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３は最初にその文書を発見し、文書を展開し、編集するために必要な機能を実行する。
【００３５】
ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３には、プラグインサブシステム１０４、コマンドサブシステム１０５、及びＲｅｓｏｕｒｃｅ（リソース）モジュール１０９などのいくつかのコンポーネントがアタッチされている。これらの構成については、以下に詳述する。
【００３６】
ａ）プラグインサブシステム
プラグインサブシステム１０４は、文書処理システムに機能を追加するための高度に柔軟で効率的な構成として使用される。プラグインサブシステム１０４は、また、文書処理システムに存在する機能を修正又は削除するために使用することができる。さらに、種々様々の機能をプラグインサブシステムを使用して追加又は修正することができる。例えば、画面上への文書の描画を支援するように作用するＥｄｉｔｌｅｔ（エディットレット：編集部）機能を追加することもできる。Ｅｄｉｔｌｅｔプラグインは、システムに追加されるボキャブラリの編集も支援する。
【００３７】
プラグインサブシステム１０４は、ＳｅｒｖｉｃｅＢｒｏｋｅｒ（サービスブローカ：サービス仲介部）１０４１を含む。ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１は、文書処理システムに加えられるプラグインを管理することにより、文書処理システムに加えられるサービスを仲介する。
【００３８】
所望の機能性を実現する個々の機能は、Ｓｅｒｖｉｃｅ（サービス）１０４２の形でシステムに追加される。利用可能なＳｅｒｖｉｃｅ１０４２のタイプは、Ａｐｐｌｉｃａｔｉｏｎ（アプリケーション）Ｓｅｒｖｉｃｅ、ＺｏｎｅＦａｃｔｏｒｙ（ゾーンファクトリ：ゾーン生成部）Ｓｅｒｖｉｃｅ、Ｅｄｉｔｌｅｔ（エディットレット：編集部）Ｓｅｒｖｉｃｅ、ＣｏｍｍａｎｄＦａｃｔｏｒｙ（コマンドファクトリ：コマンド生成部）Ｓｅｒｖｉｃｅ、ＣｏｎｎｅｃｔＸＰａｔｈ（コネクトＸＰａｔｈ：ＸＰａｔｈ管理部）Ｓｅｒｖｉｃｅ、ＣＳＳＣｏｍｐｕｔａｔｉｏｎ（ＣＳＳコンピューテーション：ＣＳＳ計算部）Ｓｅｒｖｉｃｅなどを含むが、これらに限定されない。これらのＳｅｒｖｉｃｅ、及びシステムの他の構成とそれらとの関係は、文書処理システムについてのよりよい理解のために、以下に詳述される。
【００３９】
プラグインとＳｅｒｖｉｃｅの関係は以下の通りである。プラグインは、１以上のＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒ（サービスプロバイダ：サービス提供部）を含むことができるユニットである。それぞれのＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒは、それに関連したＳｅｒｖｉｃｅの１以上のクラスを有する。例えば、適切なソフトウェアアプリケーションを有する単一のプラグインを使用することにより、１以上のＳｅｒｖｉｃｅをシステムに追加することができ、これにより、対応する機能をシステムに追加することができる。
【００４０】
ｂ）コマンドサブシステム
コマンドサブシステム１０５は、文書の処理に関連したコマンドの形式の命令を実行するために使用される。ユーザは、一連の命令を実行することにより、文書に対する操作を実行することができる。例えば、ユーザは、コマンドの形で命令を発行することにより、文書処理システム中のＸＭＬ文書に対応するＸＭＬのＤＯＭツリーを編集し、ＸＭＬ文書を処理する。これらのコマンドは、キーストローク、マウスクリック、又は他の有効なユーザインタフェイスアクションを使用して入力されてもよい。１つのコマンドにより１以上の命令が実行されることもある。この場合、これらの命令が１つのコマンドにラップ（包含）され、連続して実行される。例えば、ユーザが、誤った単語を正しい単語に置換したいとする。この場合、第１の命令は、文書中の誤った単語を発見することであり、第２の命令は、誤った単語を削除することであり、第３の命令は、正しい単語を挿入することであってもよい。これらの３つの命令が１つのコマンドにラップされてもよい。
【００４１】
コマンドは、関連した機能、例えば、後で詳述する「アンドゥ」機能を有してもよい。これらの機能は、オブジェクトを生成するために使用されるいくつかの基本クラスにも割り当てられてもよい。
【００４２】
コマンドサブシステム１０５のキーとなるコンポーネントは、選択的にコマンドを与え、実行するように作用するＣｏｍｍａｎｄＩｎｖｏｋｅｒ（コマンドインボーカ：コマンド起動部）１０５１である。図１（ｂ）には、１つのＣｏｍｍａｎｄＩｎｖｏｋｅｒのみが示されているが、１以上のＣｏｍｍａｎｄＩｎｖｏｋｅｒが使用されてもよく、１以上のコマンドが同時に実行されてもよい。ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１は、コマンドを実行するために必要な機能及びクラスを保持する。動作において、実行されるべきＣｏｍｍａｎｄ（コマンド：命令）１０５２は、Ｑｕｅｕｅ（キュー）１０５３に積まれる。ＣｏｍｍａｎｄＩｎｖｏｋｅｒは、連続的に実行するコマンドスレッドを生成する。ＣｏｍｍａｎｄＩｎｖｏｋｅｒ内で既に実行中のＣｏｍｍａｎｄがなければ、ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１により実行されるように意図されたＣｏｍｍａｎｄ１０５２が実行される。ＣｏｍｍａｎｄＩｎｖｏｋｅｒが既にコマンドを実行している場合、新しいＣｏｍｍａｎｄは、Ｑｕｅｕｅ１０５３の最後に積まれる。しかしながら、それぞれのＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１では、一度に１つのＣｏｍｍａｎｄのみが実行される。指定されたＣｏｍｍａｎｄの実行に失敗した場合、ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１は例外処理を実行する。
【００４３】
ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１により実行されるＣｏｍｍａｎｄの型は、ＵｎｄｏａｂｌｅＣｏｍｍａｎｄ（取消可能コマンド）１０５４、ＡｓｙｎｃｈｒｏｎｏｕｓＣｏｍｍａｎｄ（非同期コマンド）１０５５、及びＶＣＣｏｍｍａｎｄ（ＶＣコマンド）１０５６を含むが、これらに限定されない。ＵｎｄｏａｂｌｅＣｏｍｍａｎｄ１０５４は、ユーザが望めば、そのＣｏｍｍａｎｄの結果を取り消すことが可能なＣｏｍｍａｎｄである。ＵｎｄｏａｂｌｅＣｏｍｍａｎｄの例として、切り取り、コピー、テキストの挿入、などがある。動作において、ユーザが文書の一部を選択し、その部分に切り取りコマンドを適用するとき、ＵｎｄｏａｂｌｅＣｏｍｍａｎｄを用いることにより、切り取られた部分は、必要であれば、「切り取られていない」ようにすることができる。
【００４４】
ＶＣＣｏｍｍａｎｄ１０５６は、ボキャブラリコネクション記述子（Ｖｏｃａｂｕｌａｒｙ Ｃｏｎｎｅｃｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒ：ＶＣＤ）スクリプトファイルに格納される。これらは、プログラマにより定義されうるユーザ指定のＣｏｍｍａｎｄである。Ｃｏｍｍａｎｄは、例えば、ＸＭＬフラグメントを追加したり、ＸＭＬフラグメントを削除したり、属性を設定したりするための、より抽象的なＣｏｍｍａｎｄの組合せであってもよい。これらのＣｏｍｍａｎｄは、特に、文書の編集に焦点を合わせている。
【００４５】
ＡｓｙｎｃｈｒｏｎｏｕｓＣｏｍｍａｎｄ１０５５は、文書のロードや保存など、システムよりのＣｏｍｍａｎｄであり、ＵｎｄｏａｂｌｅＣｏｍｍａｎｄやＶＣＣｏｍｍａｎｄとは別に、非同期的に実行される。ＡｓｙｎｃｈｒｏｎｏｕｓＣｏｍｍａｎｄは、ＵｎｄｏａｂｌｅＣｏｍｍａｎｄではないので、取り消すことはできない。
【００４６】
ＡｓｙｎｃｈｒｏｎｏｕｓＣｏｍｍａｎｄｓ１０５５は、ボキャブラリコネクションの下位のレベルに存在する。それらは文書処理システムに対するより特別なコマンドである。ＡｓｙｎｃｈｒｏｎｏｕｓＣｏｍｍａｎｄｓはＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１に直接届けられる。一方で、ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎＣｏｍｍａｎｄｓ１０５６は解釈され、ＡｓｙｎｃｈｒｏｎｏｕｓＣｏｍｍａｎｄｓに変換されたのち、ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１に届けられる。
【００４７】
ｃ）リソース
Ｒｅｓｏｕｒｃｅ１０９は、様々なクラスに、いくつかの機能を提供するオブジェクトである。例えば、ストリングリソース、アイコン、及びデフォルトキーバインドは、システムで使用されるＲｅｓｏｕｒｃｅの例である。
【００４８】
２．アプリケーションコンポーネント
文書処理システムの第２の主要な特徴であるアプリケーションコンポーネント１０２は、実行環境１０１において実行される。アプリケーションコンポーネント１０２は、実際の文書と、システム内における文書の様々な論理的、物理的な表現を含む。さらに、アプリケーションコンポーネント１０２は、文書を管理するために使用されるシステムの構成を含む。アプリケーションコンポーネント１０２は、さらに、ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ（ユーザアプリケーション）１０６、アプリケーションコア１０８、ユーザインタフェイス１０７、及びＣｏｒｅＣｏｍｐｏｎｅｎｔ（コアコンポーネント）１１０を含む。
【００４９】
ａ）ユーザアプリケーション
ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６は、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３と共にシステム上にロードされる。ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６は、文書と、文書の様々な表現と、文書と対話するために必要なユーザインタフェイスとをつなぐ接着剤となる。例えば、ユーザが、プロジェクトの一部である文書のセットを生成したいとする。これらの文書がロードされると、文書の適切な表現が生成される。ユーザインタフェイス機能は、ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６の一部として追加される。言いかえれば、ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６は、ユーザがプロジェクトの一部を形成する文書と対話することを可能とする文書の表現と、文書の様々な態様とを、共に保持する。一旦ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６が生成されると、ユーザがプロジェクトの一部を形成する文書との対話を望むたびに、ユーザは簡単に実行環境上にＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６をロードすることができる。
【００５０】
ｂ）コアコンポーネント
ＣｏｒｅＣｏｍｐｏｎｅｎｔ１１０は、複数のＰａｎｅ（ペイン）の間で文書を共有する方法を提供する。後で詳述するように、Ｐａｎｅは、ＤＯＭツリーを表示し、画面の物理的なレイアウトを扱う。例えば、物理的な画面は、個々の情報の断片を描写する画面内の複数のＰａｎｅからなる。ユーザから画面上に見える文書は、１又はそれ以上のＰａｎｅに出現しうる。また、２つの異なる文書が画面上で２つの異なるＰａｎｅに現れてもよい。
【００５１】
図１（ｃ）に示されるように、画面の物理的なレイアウトもツリーの形式になっている。Ｐａｎｅは、ＲｏｏｔＰａｎｅ（ルートペイン）１０８４にもなり得るし、ＳｕｂＰａｎｅ（サブペイン）１０８５にもなり得る。ＲｏｏｔＰａｎｅ１０８４は、Ｐａｎｅのツリーの根に当たるＰａｎｅであり、ＳｕｂＰａｎｅ１０８５は、ＲｏｏｔＰａｎｅ１０８４以外の任意のＰａｎｅである。
【００５２】
ＣｏｒｅＣｏｍｐｏｎｅｎｔ１１０は、さらに、フォントを提供し、ツールキットなど、文書のための複数の機能的な操作のソースの役割を果たす。ＣｏｒｅＣｏｍｐｏｎｅｎｔ１１０により実行されるタスクの一例に、複数のＰａｎｅ間におけるマウスカーソルの移動がある。実行されるタスクの他の例として、あるＰａｎｅ中の文書の一部をマークし、それを異なる文書を含む別のＰａｎｅ上にコピーする。
【００５３】
ｃ）アプリケーションコア
上述したように、アプリケーションコンポーネント１０２は、システムにより処理され管理される文書から構成される。これは、システム内における文書の様々な論理的及び物理的な表現を含む。アプリケーションコア１０８は、アプリケーションコンポーネント１０２の構成である。その機能は、実際の文書を、それに含まれる全てのデータとともに保持することである。アプリケーションコア１０８は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ（ドキュメントマネージャ：文書管理部）１０８１及びＤｏｃｕｍｅｎｔ（ドキュメント：文書）１０８２自身を含む。
【００５４】
ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１の様々な態様を以下に詳述する。ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１は、Ｄｏｃｕｍｅｎｔ１０８２を管理する。ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１は、ＲｏｏｔＰａｎｅ１０８４、ＳｕｂＰａｎｅ１０８５、ＣｌｉｐＢｏａｒｄ（クリップボード）ユーティリティ１０８６、及びＳｎａｐＳｈｏｔ（スナップショット）ユーティリティ１０８７にも接続される。ＣｌｉｐＢｏａｒｄユーティリティ１０８６は、ユーザがクリップボードに加えることを決定した文書の部分を保持する方法を提供する。例えば、ユーザが、文書の一部を切り取り、後で再考するために新規文書にそれを保存することを望んだとする。このような場合、切り取られた部分がＣｌｉｐＢｏａｒｄに追加される。
【００５５】
つづいて、ＳｎａｐＳｈｏｔユーティリティ１０８７についても説明する。ＳｎａｐＳｈｏｔユーティリティ１０８７は、アプリケーションがある状態から別の状態まで移行するときに、アプリケーションの現在の状態を記憶することを可能とする。
【００５６】
ｄ）ユーザインタフェイス
アプリケーションコンポーネント１０２の別の構成は、ユーザがシステムと物理的に対話する手段を提供するユーザインタフェイス１０７である。例えば、ユーザインタフェイスは、ユーザが文書をアップロードしたり、削除したり、編集したり、管理したりするために使用される。ユーザインタフェイスは、Ｆｒａｍｅ（フレーム）１０７１、ＭｅｎｕＢａｒ（メニューバー）１０７２、ＳｔａｔｕｓＢａｒ（ステータスバー）１０７３、及びＵＲＬＢａｒ（ＵＲＬバー）１０７４を含む。
【００５７】
Ｆｒａｍｅ１０７１は、一般に知られているように、物理的な画面のアクティブな領域であると考えてもよい。ＭｅｎｕＢａｒ１０７２は、ユーザに選択を提供するメニューを含む画面領域である。ＳｔａｔｕｓＢａｒ１０７３は、アプリケーションの実行状態を表示する画面領域である。ＵＲＬＢａｒ１０７４は、インターネットをナビゲートするためにＵＲＬアドレスを入力する領域を提供する。
【００５８】
Ｂ．文書管理及び関連するデータ構造
図２は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１の詳細を示す。これは、文書処理システム内で文書を表現するために用いられるデータ構造及び構成を含む。分かりやすくするために、このサブセクションで説明される構成は、ＭＶＣパラダイムを用いて説明される。
【００５９】
ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１は、文書処理システム内にある全ての文書を保持しホストするＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ（ドキュメントコンテナ：文書コンテナ）２０３を含む。ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１にアタッチされたツールキット２０１は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１により使用される様々なツールを提供する。例えば、ＤｏｍＳｅｒｖｉｃｅ（ＤＯＭサービス）は、文書に対応するＤＯＭを生成し、保持し、管理するために必要とされる全ての機能を提供するために、ツールキット２０１により提供されるツールである。ツールキット２０１により提供される別のツールであるＩＯＭａｎａｇｅｒ（入出力管理部）は、システムへの入力及びシステムからの出力を管理する。同様に、ＳｔｒｅａｍＨａｎｄｌｅｒ（ストリームハンドラ）は、ビットストリームによる文書のアップロードを扱うツールである。これらのツールは、図中に特に示さず、参照番号を割り当てないが、ツールキット２０１のコンポーネントを形成する。
【００６０】
ＭＶＣパラダイムの表現によれば、モデル（Ｍ）は、文書のＤＯＭツリーモデル２０２を含む。前述したように、全ての文書は、文書処理システムにおいてＤＯＭツリーとして表現される。文書は、また、ＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ２０３の一部を形成する。
【００６１】
１．ＤＯＭモデル及びゾーン
ＤＯＭはＷ３Ｃが策定した標準規格であり、Ｎｏｄｅを操作するための標準的なインタフェイスを定義するが、実際には、ボキャブラリごと又はＮｏｄｅごとに特有の操作があるので、これらの操作をＡＰＩとして用意しておくのが好都合である。文書処理システムでは、このような各Ｎｏｄｅに特有のＡＰＩをＦａｃｅｔとして用意し、各Ｎｏｄｅにアタッチする。これにより、ＤＯＭの標準規格に準拠しつつ、有用なＡＰＩを付加することができる。また、ボキャブラリごとに特有のＤＯＭを実装するのではなく、標準的なＤＯＭの実装に、後から特有のＡＰＩを付加するようにすることで、多様なボキャブラリを統一的に処理することができるともに、複数のボキャブラリが任意の組合せで混在した文書を適切に処理することができる。標準的にはＤＯＭはＤＯＭツリー形式で表現される。
【００６２】
文書を表現するＤＯＭツリーは、Ｎｏｄｅ（ノード）２０２１を有するツリーである。ＤＯＭツリーの部分集合であるＺｏｎｅ（ゾーン）２０９は、ＤＯＭツリー内の１以上のＮｏｄｅの関連領域を含む。例えば、画面上で文書の一部のみを表示し得るが、この可視化された文書の一部はＺｏｎｅ２０９を用いて表示される。Ｚｏｎｅは、ＺｏｎｅＦａｃｔｏｒｙ（ゾーンファクトリ：ゾーン生成部）２０５と呼ばれるプラグインを用いて、生成され、取り扱われ、処理される。ＺｏｎｅはＤＯＭの一部を表現するが、１以上の「名前空間」を使用してもよい。よく知られているように、名前空間は、名前空間内でユニークな名前の集合である。換言すれば、名前空間内に同じ名前は存在しない。
【００６３】
２．Ｆａｃｅｔ及びＦａｃｅｔとＺｏｎｅとの関係
Ｆａｃｅｔ（ファセット）２０２２は、ＭＶＣパラダイムのモデル（Ｍ）部分内の別の構成である。Ｆａｃｅｔは、ＺｏｎｅにおいてＮｏｄｅを編集するために使用される。Ｆａｃｅｔ２０２２は、Ｚｏｎｅ自身の内容に影響を与えずに実行することができる手続（プロシージャ）を使用して、ＤＯＭへのアクセスを編成する。次に説明するように、これらの手続は、Ｎｏｄｅに関連した重要で有用な操作を実行する。
【００６４】
各Ｎｏｄｅ２０２１は、対応するＦａｃｅｔ２０２２を有する。ＤＯＭの中のＮｏｄｅを直接操作する代わりに、操作を実行するためにＦａｃｅｔを使用することによって、ＤＯＭの保全性は保護される。そうでなく、操作がＮｏｄｅ上で直接実行される場合、いくつかのプラグインがＤＯＭを同時に変更することができ、その結果矛盾を引き起こす。
【００６５】
ボキャブラリは、名前空間に属するタグ（例えばＸＭＬのタグ）のセットである。上述したように、名前空間は、ユニークな名前（ここではタグ）のセットを有する。ボキャブラリは、ＸＭＬ文書を表現するＤＯＭツリーのサブツリーとして現れる。このサブツリーはＺｏｎｅを含む。特定の例においては、タグセットの境界はＺｏｎｅによって定義される。Ｚｏｎｅ２０９は、ＺｏｎｅＦａｃｔｏｒｙ２０５と呼ばれるＳｅｒｖｉｃｅを利用して生成される。上述したように、Ｚｏｎｅ２０９は、文書を表現するＤＯＭツリーの一部の内部表現である。このような文書の一部へのアクセスを提供するために、論理的な表現が要求される。この論理的表現は、文書が画面上で論理的にどのように表現されるかについてコンピュータに通知する。Ｃａｎｖａｓ（キャンバス）２１０は、Ｚｏｎｅに対応する論理的なレイアウトを提供するように作用するＳｅｒｖｉｃｅである。
【００６６】
他方、Ｐａｎｅ２１１は、Ｃａｎｖａｓ２１０により提供される論理的なレイアウトに対応する物理的な画面レイアウトである。実際、ユーザは表示画面上で文字や画像によって文書のレンダリングのみを見る。したがって、文書は、画面上に文字や画像を描画するプロセスにより、画面上に描写されなければならない。文書は、Ｐａｎｅ２１１により提供される物理的なレイアウトに基づいて、Ｃａｎｖａｓ２１０により画面上に描写される。
【００６７】
Ｚｏｎｅ２０９に対応するＣａｎｖａｓ２１０は、Ｅｄｉｔｌｅｔ２０６を使用して生成される。文書のＤＯＭは、Ｅｄｉｔｌｅｔ２０６及びＣａｎｖａｓ２１０を使用して編集される。元の文書の完全性を維持するために、Ｅｄｉｔｌｅｔ２０６及びＣａｎｖａｓ２１０は、Ｚｏｎｅ２０９における１以上のＮｏｄｅに対応するＦａｃｅｔを使用する。これらのＳｅｒｖｉｃｅは、Ｚｏｎｅ及びＤＯＭ内のＮｏｄｅを直接操作しない。Ｆａｃｅｔは、Ｃｏｍｍａｎｄ２０７を利用して操作される。
【００６８】
ユーザは、一般に、画面上のカーソルを移動させたり、コマンドをタイプしたりすることによって、画面と対話する。画面上の論理的なレイアウトを提供するＣａｎｖａｓ２０１０は、このカーソル操作を受け付ける。Ｃａｎｖａｓ２０１０は、対応するアクションをＦａｃｅｔに実行させることができる。この関係により、カーソルサブシステム２０４は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１に対して、ＭＶＣパラダイムのコントローラ（Ｃ）として機能する。Ｃａｎｖａｓ２０１０は、イベントを扱うタスクも有する。例えば、Ｃａｎｖａｓ２０１０は、マウスクリック、フォーカス移動、及びユーザにより起こされた同様のアクションなどのイベントを扱う。
【００６９】
３．Ｚｏｎｅ、Ｆａｃｅｔ、Ｃａｎｖａｓ及びＰａｎｅの間の関係の概要
文書処理システム内の文書は、少なくとも４つの観点から見ることができる。すなわち、１）文書処理システムにおいて文書の内容及び構造を保持するために用いられるデータ構造、２）文書の保全性に影響を与えずに文書の内容を編集する手段、３）文書の画面上の論理的なレイアウト、４）文書の画面上の物理的なレイアウト、である。Ｚｏｎｅ、Ｆａｃｅｔ、Ｃａｎｖａｓ及びＰａｎｅは、前述の４つの観点に相当する、文書処理システムのコンポーネントをそれぞれ表す。
【００７０】
４．アンドゥサブシステム
上述したように、文書に対するいかなる変更（例えば編集）も取消可能であることが望ましい。例えば、ユーザが編集操作を実行し、次に、その変更の取消を決定したとする。図２に関連して、アンドゥサブシステム２１２は、文書管理部の取消可能なコンポーネントを実現する。ＵｎｄｏＭａｎａｇｅｒ（アンドゥマネージャ：アンドゥ管理部）２１２１は、ユーザによって取り消される可能性のある全ての文書に対する操作を保持する。
【００７１】
例えば、ユーザが、文書中の単語を別の単語に置換するコマンドを実行したとする。その後、ユーザは考え直し、元の単語に戻すことを決定したとする。アンドゥサブシステム２１２は、このような操作を支援する。ＵｎｄｏＭａｎａｇｅｒ２１２１は、このようなＵｎｄｏａｂｌｅＥｄｉｔ（アンドゥアブルエディット：取消可能な編集）２１２２の操作を保持する。
【００７２】
５．カーソルサブシステム
前述したように、ＭＶＣのコントローラ部分は、カーソルサブシステム２０４を備えてもよい。カーソルサブシステム２０４は、ユーザから入力を受け付ける。これらの入力は、一般にコマンド及び／又は編集操作の性格を有している。したがって、カーソルサブシステム２０４は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１に関連したＭＶＣパラダイムのコントローラ（Ｃ）部分であると考えることができる。
【００７３】
６．ビュー
前述したように、Ｃａｎｖａｓ２０１０は、画面上に提示されるべき文書の論理的なレイアウトを表す。ＸＨＴＭＬ文書の例では、Ｃａｎｖａｓは、文書が画面上でいかに見えるかを論理的に表現したボックスツリー２０８を含んでもよい。このボックスツリー２０８は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１に関連したＭＶＣパラダイムのビュー（Ｖ）部分に含まれよう。
【００７４】
Ｃ．ボキャブラリコネクション
文書処理システムの重要な特徴は、ＸＭＬ文書を、他の表現にマップして取り扱うことが可能で、かつ、マップした先の表現を編集すると、その編集が元のＸＭＬ文書に整合性を保ちつつ反映される環境を提供することにある。
【００７５】
マークアップ言語により記述された文書、例えばＸＭＬ文書は、文書型定義により定義されたボキャブラリに基づいて作成されている。ボキャブラリは、タグのセットである。ボキャブラリは、任意に定義されてもよいため、無限に多くのボキャブラリが存在しうる。しかしながら、多数の可能なボキャブラリのそれぞれに対して専用の処理／管理環境を提供するのは現実的ではない。ボキャブラリコネクションは、この問題を解決する方法を提供する。
【００７６】
例えば、文書は２以上のマークアップ言語により記述されてもよい。文書は、例えば、ＸＨＴＭＬ（ｅＸｔｅｎｓｉｂｌｅ ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）、ＳＶＧ（Ｓｃａｌａｂｌｅ Ｖｅｃｔｏｒ Ｇｒａｐｈｉｃｓ）、ＭａｔｈＭＬ（Ｍａｔｈｅｍａｔｉｃａｌ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）、その他のマークアップ言語により記述されてもよい。換言すれば、マークアップ言語は、ＸＭＬにおけるボキャブラリやタグセットと同様に見なされてもよい。
【００７７】
ボキャブラリは、ボキャブラリプラグインを用いて処理される。文書処理システムにおいてプラグインが利用不可能であるボキャブラリにより記述された文書は、プラグインが利用可能である別のボキャブラリの文書にマッピングすることにより表示される。この特徴により、プラグインが用意されていないボキャブラリの文書も適切に表示することができる。
【００７８】
ボキャブラリコネクションは、定義ファイルを取得し、取得した定義ファイルに基づいて２つの異なるボキャブラリの間でマッピングする能力を含む。あるボキャブラリで記述された文書は、別のボキャブラリにマッピングすることができる。このように、ボキャブラリコネクションは、文書がマッピングされるボキャブラリに対応した表示／編集プラグインにより文書を表示し編集することを可能にする。
【００７９】
上述したように、各文書は、一般に複数のノードを有するＤＯＭツリーとして文書処理システムにおいて記述される。「定義ファイル」は、それぞれのノードについて、そのノードと他のノードとの対応を記述する。各ノードの要素値及び属性値が編集可能か否かが指定される。ノードの要素値又は属性値を用いた演算式が記述されてもよい。
【００８０】
マッピングという特徴を利用して、定義ファイルを適用したデスティネーションＤＯＭツリーが生成される。このように、ソースＤＯＭツリーとデスティネーションＤＯＭツリーの関係が構築され保持される。ボキャブラリコネクションは、ソースＤＯＭツリーとデスティネーションＤＯＭツリーの対応を監視する。ユーザから編集指示を受けると、ボキャブラリコネクションは、ソースＤＯＭツリーの関連したノードを変更する。ソースＤＯＭツリーが変更されたことを示す「ミューテーションイベント」が発行され、デスティネーションＤＯＭツリーがそれに応じて変更される。
【００８１】
ボキャブラリコネクションの使用により、少数のユーザのみに知られていた比較的マイナーなボキャブラリを、別のメジャーなボキャブラリに変換することができる。したがって、少数のユーザによって利用されるマイナーなボキャブラリであっても、文書を適切に表示し、望ましい編集環境を提供することができる。
【００８２】
このように、文書処理システムの一部であるボキャブラリコネクションサブシステムは、文書の複数の表現を可能にする機能を提供する。
【００８３】
図３は、ボキャブラリコネクション（ＶＣ：Ｖｏｃａｂｕｌａｒｙ Ｃｏｎｎｅｃｔｉｏｎ）サブシステム３００を示す。ＶＣサブシステム３００は、同一の文書の２つの代替表現の整合性を維持する方法を提供する。例えば、２つの表現は、同一文書の、２つの異なるボキャブラリによる表現であってもよい。前述したように、一方はソースＤＯＭツリーであってもよく、他方はデスティネーションＤＯＭツリーであってもよい。
【００８４】
１．ボキャブラリコネクションサブシステム
ボキャブラリコネクションサブシステム３００の機能は、ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎ３０１と呼ばれるプラグインを使用して、文書処理システムにおいて実現される。文書が表現されるＶｏｃａｂｕｌａｒｙ３０５ごとに、対応するプラグインが要求される。例えば、文書の一部がＨＴＭＬで記述され、残りがＳＶＧで記述されている場合、ＨＴＭＬとＳＶＧに対応するボキャブラリプラグインが要求される。
【００８５】
ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎプラグイン３０１は、適切なＶｏｃａｂｕｌａｒｙ３０５の文書に対応した、Ｚｏｎｅ２０９又はＰａｎｅ２１１のための適切なＶＣＣａｎｖａｓ（ボキャブラリコネクションキャンバス）３１０を生成する。ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎ３０１を用いて、ソースＤＯＭツリー内のＺｏｎｅ２０９に対する変更は、変換ルールにより、別のＤＯＭツリー３０６の対応するＺｏｎｅに伝達される。変換ルールは、ボキャブラリコネクション記述子（Ｖｏｃａｂｕｌａｒｙ Ｃｏｎｎｅｃｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒ：ＶＣＤ）の形式で記述される。このようなソースＤＯＭとデスティネーションＤＯＭの間の変換に対応するそれぞれのＶＣＤファイルについて、対応するＶＣＭａｎａｇｅｒ（ボキャブラリコネクションマネージャ）３０２が生成される。
【００８６】
２．Ｃｏｎｎｅｃｔｏｒ
Ｃｏｎｎｅｃｔｏｒ３０４は、ソースＤＯＭツリーのソースノードと、デスティネーションＤＯＭツリーのデスティネーションノードとを接続する。Ｃｏｎｎｅｃｔｏｒ３０４は、ソースＤＯＭツリー中のソースノード、及びソースノードに対応するソース文書に対する修正（変更）を見るために作用する。そして、対応するデスティネーションＤＯＭツリーのノードを修正する。Ｃｏｎｎｅｃｔｏｒ３０４は、デスティネーションＤＯＭツリーを修正することができる唯一のオブジェクトである。例えば、ユーザは、ソース文書、及び対応するソースＤＯＭツリーに対してのみ修正を行うことができる。その後、Ｃｏｎｎｅｃｔｏｒ３０４がデスティネーションＤＯＭツリーに、対応する修正を行う。
【００８７】
Ｃｏｎｎｅｃｔｏｒ３０４は、ツリー構造を形成するために、論理的にリンクされる。Ｃｏｎｎｅｃｔｏｒ３０４により形成されたツリーは、ＣｏｎｎｅｃｔｏｒＴｒｅｅ（コネクタツリー）と呼ばれる。Ｃｏｎｎｅｃｔｏｒ３０４は、ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ（コネクタファクトリ：コネクタ生成部）３０３と呼ばれるＳｅｒｖｉｃｅを用いて生成される。ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３は、ソース文書からＣｏｎｎｅｃｔｏｒ３０４を生成し、それらをリンクしてＣｏｎｎｅｃｔｏｒＴｒｅｅを形成する。ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒ３０２は、ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３を保持する。
【００８８】
前述したように、ボキャブラリは名前空間におけるタグのセットである。図示されるように、Ｖｏｃａｂｕｌａｒｙ３０５は、ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎ３０１によって文書に対して生成される。これは、文書ファイルを解析し、ソースＤＯＭとデスティネーションＤＯＭの間の写像のための適切なＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒ３０２を生成することにより行われる。さらに、Ｃｏｎｎｅｃｔｏｒを生成するＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３と、Ｚｏｎｅ２０９を生成するＺｏｎｅＦａｃｔｏｒｙ２０５と、Ｚｏｎｅ内のノードに対応するＣａｎｖａｓを生成するＥｄｉｔｌｅｔ２０６との間の適切な関係が作られる。ユーザがシステムから文書を処分又は削除するとき、対応するＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒ３０２が削除される。
【００８９】
Ｖｏｃａｂｕｌａｒｙ３０５は、ＶＣＣａｎｖａｓ３１０を生成する。さらに、Ｃｏｎｎｅｃｔｏｒ３０４及びデスティネーションＤＯＭツリー３０６が対応して生成される。
【００９０】
ソースＤＯＭ及びＣａｎｖａｓは、それぞれ、モデル（Ｍ）及びビュー（Ｖ）に対応する。しかしながら、このような表現は、ターゲットのボキャブラリが画面上に描写可能である場合に限って意味がある。描写は、ボキャブラリプラグインにより行われる。ボキャブラリプラグインは、主要なボキャブラリ、例えば、ＸＨＴＭＬ、ＳＶＧ、ＭａｔｈＭＬについて提供される。ボキャブラリプラグインは、ターゲットのボキャブラリに関連して使用される。これらは、ボキャブラリコネクション記述子を用いてボキャブラリ間でマッピングする方法を提供する。
【００９１】
このようなマッピングは、ターゲットのボキャブラリが、マッピング可能で、画面上に描写される方法が予め定義されたものである場合にのみ意味がある。このようなレンダリング方法は、例えばＸＨＴＭＬなどのように、Ｗ３Ｃなどの組織により定義された標準規格となっている。
【００９２】
ボキャブラリコネクションが必要であるとき、ＶＣＣａｎｖａｓが使用される。この場合、ソースのビューを直接生成することができないので、ソースのＣａｎｖａｓは生成されない。この場合、ＶＣＣａｎｖａｓが、ＣｏｎｎｅｃｔｏｒＴｒｅｅを使用して生成される。このＶＣＣａｎｖａｓは、イベントの変換のみを扱い、画面上の文書の描写を援助しない。
【００９３】
３．ＤｅｓｔｉｎａｔｉｏｎＺｏｎｅ、Ｐａｎｅ、及びＣａｎｖａｓ
上述したように、ボキャブラリコネクションサブシステムの目的は、同一の文書の２つの表現を同時に生成し保持することである。第２の表現も、ＤＯＭツリーの形式であり、これはデスティネーションＤＯＭツリーとして既に説明した。第２の表現における文書を見るために、ＤｅｓｔｉｎａｔｉｏｎＺｏｎｅ、Ｃａｎｖａｓ及びＰａｎｅが必要である。
【００９４】
ＶＣＣａｎｖａｓが作成されると、対応するＤｅｓｔｉｎａｔｉｏｎＰａｎｅ３０７が生成される。さらに、関連するＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓ３０８と、対応するＢｏｘＴｒｅｅ３０９が生成される。同様に、ＶＣＣａｎｖａｓ３１０も、ソース文書に対するＰａｎｅ２１１及びＺｏｎｅ２０９に関連づけられる。
【００９５】
ＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓ３０８は、第２の表現における文書の論理的なレイアウトを提供する。特に、ＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓ３０８は、デスティネーション表現における文書を描写するために、カーソルや選択のようなユーザインタフェイス機能を提供する。ＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓ３０８に生じたイベントは、Ｃｏｎｎｅｃｔｏｒに供給される。ＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓ３０８は、マウスイベント、キーボードイベント、ドラッグアンドドロップイベント、及び文書のデスティネーション（第２）表現のボキャブラリに特有なイベントを、Ｃｏｎｎｅｃｔｏｒ３０４に通知する。
【００９６】
４．ボキャブラリコネクションコマンドサブシステム
ボキャブラリコネクション（ＶＣ）サブシステム３００の要素として、ボキャブラリコネクション（ＶＣ）コマンドサブシステム３１３がある。ボキャブラリコネクションコマンドサブシステム３１３は、ボキャブラリコネクションサブシステム３００に関連した命令の実行のために使用されるＶＣＣｏｍｍａｎｄ（ボキャブラリコネクションコマンド）３１５を生成する。ＶＣＣｏｍｍａｎｄは、内蔵のＣｏｍｍａｎｄＴｅｍｐｌａｔｅ（コマンドテンプレート）３１３１を使用して、及び／又は、スクリプトサブシステム３１４においてスクリプト言語を使用してスクラッチからコマンドを生成することにより、生成することができる。
【００９７】
コマンドテンプレートには、例えば、「Ｉｆ」コマンドテンプレート、「Ｗｈｅｎ」コマンドテンプレート、「挿入（Ｉｎｓｅｒｔ）」コマンドテンプレートなどがある。これらのテンプレートは、ＶＣＣｏｍｍａｎｄを作成するために使用される。
【００９８】
５．ＸＰａｔｈサブシステム
ＸＰａｔｈサブシステム３１６は、文書処理システムの重要な構成であり、ボキャブラリコネクションの実現を支援する。Ｃｏｎｎｅｃｔｏｒ３０４は、一般にｘｐａｔｈ情報を含む。上述したように、ボキャブラリコネクションのタスクの１つは、ソースＤＯＭツリーの変化をデスティネーションＤＯＭツリーに反映させることである。ｘｐａｔｈ情報は、変更／修正を監視されるべきソースＤＯＭツリーのサブセットを決定するために用いられる１以上のｘｐａｔｈ表現を含む。
【００９９】
６．ソースＤＯＭツリー、デスティネーションＤＯＭツリー、及びＣｏｎｎｅｃｔｏｒＴｒｅｅの概要
ソースＤＯＭツリーは、別のボキャブラリに変換される前のボキャブラリで文書を表現したＤＯＭツリー又はＺｏｎｅである。ソースＤＯＭツリーのノードは、ソースノードと呼ばれる。
【０１００】
それに対して、デスティネーションＤＯＭツリーは、ボキャブラリコネクションに関連して前述したように、同一の文書を、マッピングにより変換された後の異なるボキャブラリで表現したＤＯＭツリー又はＺｏｎｅである。デスティネーションＤＯＭツリーのノードは、デスティネーションノードと呼ばれる。
【０１０１】
ＣｏｎｎｅｃｔｏｒＴｒｅｅは、ソースノードとデスティネーションノードの対応を表すＣｏｎｎｅｃｔｏｒに基づく階層的表現である。Ｃｏｎｎｅｃｔｏｒは、ソースノードと、ソース文書になされた修正を監視し、デスティネーションＤＯＭツリーを修正する。Ｃｏｎｎｅｃｔｏｒは、デスティネーションＤＯＭツリーを修正することを許された唯一のオブジェクトである。
【０１０２】
Ｄ．文書処理システムにおけるイベントフロー
実用のためには、プログラムはユーザからのコマンドに応答しなければならない。イベントは、プログラム上で実行されたユーザアクションを記述し実行する方法である。多くの高級言語、例えばＪａｖａ（登録商標）は、ユーザアクションを記述するイベントに頼っている。従来、プログラムは、ユーザアクションを理解し、それを自身で実行するために、積極的に情報を集める必要があった。これは、例えば、プログラムが自身を初期化した後、ユーザが画面、キーボード、マウスなどでアクションを起こしたときに適切な処理を講じるために、ユーザのアクションを繰り返し確認するループに入ることを意味する。しかしながら、このプロセスは扱いにくい。さらに、それは、ユーザが何かをするのを待つ間、ＣＰＵサイクルを消費してループするプログラムを必要とする。
【０１０３】
多くの言語が、異なるパラダイムを採用することにより、これらの問題を解決している。そのうちの一つは、現代の全てのウィンドウシステムの基礎となっている、イベントドリブンプログラミングである。このパラダイムでは、全てのユーザアクションは、「イベント」と呼ばれる抽象的な事象の集合に属する。イベントは、十分詳細に、特定のユーザアクションを記述する。プログラムがユーザにより生成されたイベントを積極的に収集するのではなく、監視すべきイベントが生じたときに、システムがプログラムに通知する。この方法によりユーザとの対話を扱うプログラムは「イベントドリブン」であると言われる。
【０１０４】
これは、多くの場合、全てのユーザにより生成されたイベントの基本特性を獲得する「Ｅｖｅｎｔ（イベント）」クラスを使用して扱われる。
【０１０５】
文書処理システムは、自身のイベント、及びこれらのイベントを扱う方法を定義して使用する。いくつかの型のイベントが使用される。例えば、マウスイベントは、ユーザのマウスアクションから起こるイベントである。マウスを含むユーザアクションは、Ｃａｎｖａｓ２１０によって、マウスイベントに渡される。このように、Ｃａｎｖａｓは、システムのユーザによる相互作用の最前部にあると言える。必要であれば、最前部にあるＣａｎｖａｓは、そのイベントに関連した内容を子へ渡す。
【０１０６】
それに対して、キーストロークイベントは、Ｃａｎｖａｓ２１０から流れる。キーストロークイベントは、即時的なフォーカスを有する。すなわち、それは、いかなる瞬間でも作業に関連する。Ｃａｎｖａｓ２１０上に入力されたキーストロークイベントは、その親に渡される。キー入力は、文字列挿入を扱うことが可能な、異なるイベントによって処理される。文字列の挿入を扱うイベントは、キーボードを使用して文字が挿入されたときに発生する。他の「イベント」は、例えば、ドラッグイベント、ドロップイベント、マウスイベントと同様に扱われる他のイベントを含む。
【０１０７】
１．ボキャブラリコネクション外のイベントの取り扱い
イベントは、イベントスレッドを用いて渡される。Ｃａｎｖａｓ２１０は、イベントを受け取ると、その状態を変更する。必要であれば、Ｃｏｍｍａｎｄ１０５２がＣａｎｖａｓ２１０によりＣｏｍｍａｎｄＱｕｅｕｅ１０５３にポストされる。
【０１０８】
２．ボキャブラリコネクション内のイベントの取り扱い
ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎプラグイン３０１を用いて、ＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓの一例であるＸＨＴＭＬＣａｎｖａｓ１１０６は、発生したイベント、例えば、マウスイベント、キーボードイベント、ドラッグアンドドロップイベント、及びボキャブラリに特有のイベントなどを受け取る。これらのイベントは、Ｃｏｎｎｅｃｔｏｒ１１０４に通知される。より詳細には、図１１に図示されるように、ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｉｏｎプラグイン３０１内のイベントフローは、ＳｏｕｒｃｅＰａｎｅ１１０３、ＶＣＣａｎｖａｓ１１０４、ＤｅｓｔｉｎａｔｉｏｎＰａｎｅ１１０５、ＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓの一例であるＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓ１１０６、デスティネーションＤＯＭツリー及びＣｏｎｎｅｃｔｏｒＴｒｅｅを通過する。
【０１０９】
Ｅ．ＰｒｏｇｒａｍＩｎｖｏｋｅｒ及びＰｒｏｇｒａｍＩｎｖｏｋｅｒと他の構成との関係
ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３及びそれと他の構成との関係は、図４（ａ）に更に詳細に示される。ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３は、文書処理システムを開始するために実行される実行環境中の基本的なプログラムである。図１（ｂ）に図示されるように、ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６、ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１、ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１、及びＲｅｓｏｕｒｃｅ１０９は、全てＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３に接続される。前述したように、アプリケーション１０２は、実行環境中で実行されるコンポーネントである。同様に、ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１は、システムに様々な機能を加えるプラグインを管理する。他方、ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１は、ユーザにより提供される命令を実行して、コマンドを実行するために使用されるクラス及びファンクションを保持する。
【０１１０】
１．プラグイン及びサービス
ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１について、図４（ｂ）を参照して更に詳細に説明する。前述したように、ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１は、システムに様々な機能を追加するプラグイン（及び関連するサービス）を管理する。Ｓｅｒｖｉｃｅ１０４２は、文書処理システムに特徴を追加又は変更可能な最も下の層である。「Ｓｅｒｖｉｃｅ」は、ＳｅｒｖｉｃｅＣａｔｅｇｏｒｙ４０１とＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒ４０２の２つの部分からなる。図４（ｃ）に図示されるように、１つのＳｅｒｖｉｃｅＣａｔｅｇｏｒｙ４０１は、複数の関連するＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒ４０２を持ちうる。それぞれのＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒは、特定のＳｅｒｖｉｃｅＣａｔｅｇｏｒｙの一部または全部を実行するように作用する。ＳｅｒｖｉｃｅＣａｔｅｇｏｒｙ４０１は、他方では、Ｓｅｒｖｉｃｅの型を定義する。
【０１１１】
Ｓｅｒｖｉｃｅは、１）文書処理システムに特定の特色を提供する「特色サービス」、２）文書処理システムにより実行されるアプリケーションである「アプリケーションサービス」、３）文書処理システムの全体にわたって必要な特色を提供する「環境サービス」、の３つの型に分類することができる。
【０１１２】
Ｓｅｒｖｉｃｅの例は、図４（ｄ）に示される。アプリケーションＳｅｒｖｉｃｅのＣａｔｅｇｏｒｙにおいては、システムユーティリティが対応するＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒの例である。同様に、Ｅｄｉｔｌｅｔ２０６はＣａｔｅｇｏｒｙであり、ＨＴＭＬＥｄｉｔｌｅｔ及びＳＶＧＥｄｉｔｌｅｔは対応するＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒである。ＺｏｎｅＦａｃｔｏｒｙ２０５は、Ｓｅｒｖｉｃｅの別のＣａｔｅｇｏｒｙであり、対応するＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒ（図示せず）を有する。
【０１１３】
プラグインは、文書処理システムに機能性を加えると既に説明したが、いくつかのＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒ４０２及びそれらに関連するクラスからなるユニットと見なされてもよい。各プラグインは、宣言ファイルに記述された依存性及びＳｅｒｖｉｃｅＣａｔｅｇｏｒｙ４０１を有する。
【０１１４】
２．ＰｒｏｇｒａｍＩｎｖｏｋｅｒとアプリケーションとの関係
図４（ｅ）は、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３とＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６との関係についての更なる詳細を示す。必要な文書やデータなどは、ストレージからロードされる。必要なプラグインは、全てＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１上にロードされる。ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１は、全てのプラグインを保持し管理する。プラグインは、システムに物理的に追加することができ、又、その機能はストレージからロードすることができる。プラグインの内容がロードされると、ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１は、対応するプラグインを定義する。つづいて、対応するＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６が生成され、実行環境１０１にロードされ、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３にアタッチされる。
【０１１５】
Ｆ．アプリケーションサービスと環境との関係
図５（ａ）は、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３上にロードしたアプリケーションサービスの構成についての更なる詳細を示す。コマンドサブシステム１０５のコンポーネントであるＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１は、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３内のＣｏｍｍａｎｄ１０５２を起動又は実行する。Ｃｏｍｍａｎｄ１０５２は、文書処理システムにおいて、ＸＭＬなどの文書を処理し、対応するＸＭＬＤＯＭツリーを編集するために用いられる命令である。ＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１は、Ｃｏｍｍａｎｄ１０５２を実行するために必要なクラス及びファンクションを保持する。
【０１１６】
ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１も、ＰｒｏｇｒａｍＩｎｖｏｋｅｒ１０３内で実行される。ＵｓｅｒＡｐｐｌｉｃａｔｉｏｎ１０６は、ユーザインタフェイス１０７及びＣｏｒｅＣｏｍｐｏｎｅｎｔ１１０に接続される。ＣｏｒｅＣｏｍｐｏｎｅｎｔ１１０は、全てのＰａｎｅの間で文書を共有する方法を提供する。ＣｏｒｅＣｏｍｐｏｎｅｎｔ１１０は、さらにフォントを提供し、Ｐａｎｅのためのツールキットの役割を果たす。
【０１１７】
図５（ａ）及び図５（ｂ）は、Ｆｒａｍｅ１０７１、ＭｅｎｕＢａｒ１０７２、及びＳｔａｔｕｓＢａｒ１０７３の関係を示す。
【０１１８】
Ｇ．アプリケーションコア
図６（ａ）は、全ての文書、及び文書の一部及び文書に属するデータを保持するアプリケーションコア１１０についての更なる説明を提供する。ＣｏｒｅＣｏｍｐｏｎｅｎｔ１１０は、Ｄｏｃｕｍｅｎｔ１０８２を管理するＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１にアタッチされる。ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１は、文書処理システムに関連づけられたメモリに格納される全てのＤｏｃｕｍｅｎｔ１０８２の所有者である。
【０１１９】
画面上の文書の表示を容易にするために、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１はＲｏｏｔＰａｎｅ１０８４にも接続される。ＣｌｉｐＢｏａｒｄ１０８６、ＳｎａｐＳｈｏｔ１０８７、Ｄｒａｇ＆Ｄｒｏｐ６０１、及びＯｖｅｒｌａｙ６０２の機能も、アプリケーションコアにアタッチされる。
【０１２０】
ＳｎａｐＳｈｏｔ１０８７は、図６（ａ）で示したように、アプリケーションの状態を元に戻すために使用される。ユーザがＳｎａｐＳｈｏｔ１０８７を起動したとき、アプリケーションの現状が検知され、格納される。その後、アプリケーションの状態が別の状態に変わるとき、格納された状態の内容は保存される。ＳｎａｐＳｈｏｔは、図６（ｂ）に図示される。動作において、アプリケーションがあるＵＲＬから他へ移動するときに、前に戻る動作及び先に進む動作をシームレスに実行可能とするために、ＳｎａｐＳｈｏｔは以前の状態を記憶する。
【０１２１】
Ｈ．ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ内における文書の構成
図７（ａ）は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１の更なる説明と、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒにおいて文書が構成され保持される様子を示す。図１（ｂ）に示したように、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１は、Ｄｏｃｕｍｅｎｔ１０８２を管理する。図７（ａ）に示される例において、複数のＤｏｃｕｍｅｎｔのうちの１つはＲｏｏｔＤｏｃｕｍｅｎｔ（ルート文書）７０１であり、残りの文書はＳｕｂＤｏｃｕｍｅｎｔ（サブ文書）７０２である。ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１は、ＲｏｏｔＤｏｃｕｍｅｎｔ７０１に接続され、ＲｏｏｔＤｏｃｕｍｅｎｔ７０１は、全てのＳｕｂＤｏｃｕｍｅｎｔ７０２に接続される。
【０１２２】
図２及び図７（ａ）に示すように、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１は、全ての文書１０８２を管理するオブジェクトであるＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ２０３に結合される。ＤＯＭＳｅｒｖｉｃｅ７０３及びＩＯＭａｎａｇｅｒ７０４を含むツールキット２０１（例えばＸＭＬツールキット）の一部を形成するツールも、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１に供給される。再び図７（ａ）を参照して、ＤＯＭＳｅｒｖｉｃｅ７０３は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１０８１により管理される文書に基づいたＤＯＭツリーを生成する。各Ｄｏｃｕｍｅｎｔ７０５は、それがＲｏｏｔＤｏｃｕｍｅｎｔ７０１であってもＳｕｂＤｏｃｕｍｅｎｔ７０２であっても、対応するＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ２０３によって管理される。
【０１２３】
図７（ｂ）は、文書Ａ−Ｅが階層的に配置される様子を示す。文書ＡはＲｏｏｔＤｏｃｕｍｅｎｔである。文書Ｂ−Ｄは、文書ＡのＳｕｂＤｏｃｕｍｅｎｔである。文書Ｅは、文書ＤのＳｕｂＤｏｃｕｍｅｎｔである。図７（ｃ）では、これと同じ文書の階層が画面上に表示された例を示す。ＲｏｏｔＤｏｃｕｍｅｎｔである文書Ａは、基本フレームとして表示される。文書ＡのＳｕｂＤｏｃｕｍｅｎｔである文書Ｂ−Ｄは、基本フレームＡの中のサブフレームとして表示される。文書ＤのＳｕｂＤｏｃｕｍｅｎｔである文書Ｅは、サブフレームＤのサブフレームとして画面に表示される。
【０１２４】
再び図７（ａ）を参照して、ＵｎｄｏＭａｎａｇｅｒ（アンドゥマネージャ：アンドゥ管理部）７０６及びＵｎｄｏＷｒａｐｐｅｒ（アンドゥラッパー）７０７は、それぞれのＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ２０３に対して生成される。ＵｎｄｏＭａｎａｇｅｒ７０６及びＵｎｄｏＷｒａｐｐｅｒ７０７は、取消可能なコマンドを実行するために使用される。この特徴を使用することにより、編集操作を使用して文書に対して実行された変更を取り消すことができる。ＳｕｂＤｏｃｕｍｅｎｔの変更は、ＲｏｏｔＤｏｃｕｍｅｎｔとも密接な関係を有する。アンドゥ操作は、階層内の他の文書に影響する変更を考慮に入れて、例えば、図１７（ｃ）に示されるような連鎖状の階層における全ての文書の間で整合性が維持されることを保証する。
【０１２５】
ＵｎｄｏＷｒａｐｐｅｒ７０７は、ＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ２０３内のＳｕｂＤｏｃｕｍｅｎｔに関連するアンドゥオブジェクトをラップし、それらをＲｏｏｔＤｏｃｕｍｅｎｔに関連するアンドゥオブジェクトに結合させる。ＵｎｄｏＷｒａｐｐｅｒ７０７は、ＵｎｄｏａｂｌｅＥｄｉｔＡｃｃｅｐｔｏｒ（アンドゥアブルエディットアクセプタ：アンドゥ可能編集受付部）７０９に利用可能なアンドゥオブジェクトを収集させる。
【０１２６】
ＵｎｄｏＭａｎａｇｅｒ７０６及びＵｎｄｏＷｒａｐｐｅｒ７０７は、ＵｎｄｏａｂｌｅＥｄｉｔＡｃｃｅｐｔｏｒ７０８及びＵｎｄｏａｂｌｅＥｄｉｔＳｏｕｒｃｅ（アンドゥアブルエディットソース）７０８に接続される。当業者には理解されるように、Ｄｏｃｕｍｅｎｔ７０５がＵｎｄｏａｂｌｅＥｄｉｔＳｏｕｒｃｅ７０８であってもよく、取消可能な編集オブジェクトのソースであってもよい。
【０１２７】
Ｉ．アンドゥコマンド及びアンドゥフレームワーク
図８（ａ）及び図８（ｂ）は、アンドゥフレームワーク及びアンドゥコマンドについて更なる詳細を提供する。図８（ａ）に示されるように、ＵｎｄｏＣｏｍｍａｎｄ８０１、ＲｅｄｏＣｏｍｍａｎｄ８０２、及びＵｎｄｏａｂｌｅＥｄｉｔＣｏｍｍａｎｄ８０３は、図１（ｂ）に示したようにＣｏｍｍａｎｄＩｎｖｏｋｅｒ１０５１に積むことができるコマンドであり、順に実行される。ＵｎｄｏａｂｌｅＥｄｉｔＣｏｍｍａｎｄ８０３は、ＵｎｄｏａｂｌｅＥｄｉｔＳｏｕｒｃｅ７０８及びＵｎｄｏａｂｌｅＥｄｉｔＡｃｃｅｐｔｏｒ７０９に更にアタッチされる。「ｆｏｏ」ＥｄｉｔＣｏｍｍａｎｄ８０３及び「ｂａｒ」ＥｄｉｔＣｏｍｍａｎｄ８０４は、ＵｎｄｏａｂｌｅＥｄｉｔＣｏｍｍａｎｄの例である。
【０１２８】
１．ＵｎｄｏａｂｌｅＥｄｉｔＣｏｍｍａｎｄの実行
図８（ｂ）は、ＵｎｄｏａｂｌｅＥｄｉｔＣｏｍｍａｎｄの実行を示す。まず、ユーザが編集コマンドを使用してＤｏｃｕｍｅｎｔ７０５を編集すると仮定する。第１ステップＳ１では、ＵｎｄｏａｂｌｅＥｄｉｔＡｃｃｅｐｔｏｒ７０９が、Ｄｏｃｕｍｅｎｔ７０５のＤＯＭツリーであるＵｎｄｏａｂｌｅＥｄｉｔＳｏｕｒｃｅ７０８にアタッチされる。第２ステップＳ２では、ユーザにより発行されたコマンドに基づいて、Ｄｏｃｕｍｅｎｔ７０５がＤＯＭのＡＰＩを用いて編集される。第３ステップＳ３では、ミューテーションイベントのリスナーが、変更がなされたことを通知される。すなわち、このステップでは、ＤＯＭツリーの全ての変更を監視するリスナーが編集操作を検知する。第４ステップＳ４では、ＵｎｄｏａｂｌｅＥｄｉｔがＵｎｄｏＭａｎａｇｅｒ７０６のオブジェクトとして格納される。第５ステップＳ５では、ＵｎｄｏａｂｌｅＥｄｉｔＡｃｃｅｐｔｏｒ７０９がＵｎｄｏａｂｌｅＥｄｉｔＳｏｕｒｃｅ７０８からデタッチされる。ＵｎｄｏａｂｌｅＥｄｉｔＳｏｕｒｃｅ７０８は、Ｄｏｃｕｍｅｎｔ７０５自身であってもよい。
【０１２９】
Ｊ．システムへの文書のロードに関する手順
上記のサブセクションでは、システムの様々なコンポーネント及びサブコンポーネントについて説明した。以下、これらのコンポーネントの使用に関する方法論について説明する。図９は、文書処理システムに文書がロードされる様子の概要を示す。それぞれのステンプは、図１４−１８において、特定の例に関連して詳述される。
【０１３０】
簡単には、文書処理システムは、文書に含まれるデータからなるバイナリデータストリームからＤＯＭを生成する。ＡｐｅｘＮｏｄｅ（エイペックスノード：頂点ノード）が、注目対象でありＺｏｎｅに属する文書の一部のために生成される。つづいて、対応するＰａｎｅが特定される。特定されたＰａｎｅは、ＡｐｅｘＮｏｄｅ及び物理的な画面表面からＺｏｎｅ及びＣａｎｖａｓを生成する。Ｚｏｎｅは、次に、それぞれのノードにＦａｃｅｔを生成し、それらに必要とされる情報を提供する。Ｃａｎｖａｓは、ＤＯＭツリーから、ノードをレンダリングするためのデータ構造を生成する。
【０１３１】
図１９（ａ）で示すように、ＳＨＴＭＬやＳＶＧコンテンツの両方で記述された複雑な文書はストレージ９０１からステップ０としてロードされる。その文書のＤＯＭツリー９０２が作成される。ＤＯＭツリー９０２が一つの頂点ノード９０５を有し、そして木が他の枝に降りるように、境界では２方向に分かれる。他のボキャブラリ、例えばＳＶＧの一つの頂点ノードもこれに従う。複雑な文書をこのように表現することは、文書を描写し、最終的に表示する方法を理解するのに有益である。
【０１３２】
次に、文書を保持するための、対応するＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ９０３が生成される。ＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ９０３は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ９０４にアタッチされる。ＤＯＭツリーは、ルートノードと、ときには複数のセカンダリノードを含む。
【０１３３】
一般に、このような文書は、テキスト及びグラフィクスの双方を含む。したがって、ＤＯＭツリーは、例えば、ＸＨＴＭＬサブツリーだけでなくＳＶＧサブツリーを有してもよい。ＸＨＴＭＬサブツリーは、ＸＨＴＭＬのＡｐｅｘＮｏｄｅ９０５を有する。同様に、ＳＶＧサブツリーは、ＳＶＧのＡｐｅｘＮｏｄｅ９０６を有する。
【０１３４】
ステップ１では、ＡｐｅｘＮｏｄｅ９０６が、画面の論理的なレイアウトであるＰａｎｅ９０７にアタッチされる。ステップ２では、Ｐａｎｅ９０７は、ＰａｎｅＯｗｎｅｒ（ペインオーナー：ペインの所有者）９０８であるＣｏｒｅＣｏｍｐｏｎｅｎｔに、ＡｐｅｘＮｏｄｅ９０６のためのＺｏｎｅＦａｃｔｏｒｙを要求する。ステップ３では、ＰａｎｅＯｗｎｅｒ９０８は、ＺｏｎｅＦａｃｔｏｒｙと、ＡｐｅｘＮｏｄｅ９０６のためのＣａｎｖａｓＦａｃｔｏｒｙであるＥｄｉｔｌｅｔとを返す。
【０１３５】
ステップ４では、Ｐａｎｅ９０７がＺｏｎｅ９０９を生成する。Ｚｏｎｅ９０９はＰａｎｅ９０７にアタッチされる。ステップ５では、Ｚｏｎｅ９０９がそれぞれのノードに対してＦａｃｅｔを生成し、対応するノードにアタッチする。ステップ６では、Ｐａｎｅ９０７がＣａｎｖａｓ９１０を生成する。Ｃａｎｖａｓ９１０はＰａｎｅ９０７にアタッチされる。Ｃａｎｖａｓ９１０には様々なＣｏｍｍａｎｄが含まれる。ステップ７では、Ｃａｎｖａｓ９１０が文書を画面にレンダリングするためのデータ構造を構築する。ＸＨＴＭＬの場合、これはボックスツリー構造を含む。
【０１３６】
１．ＺｏｎｅのＭＶＣ
図９（ｂ）は、ＭＶＣパラダイムを用いてＺｏｎｅの構成の概要を示す。この場合、Ｚｏｎｅ及びＦａｃｅｔは文書に関連した入力であるから、モデル（Ｍ）はＺｏｎｅ及びＦａｃｅｔを含む。Ｃａｎｖａｓと、文書を画面にレンダリングするためのデータ構造体は、ユーザが画面上に見る出力であるから、ビュー（Ｖ）はＣａｎｖａｓ及びデータ構造体に対応する。Ｃｏｍｍａｎｄは、文書とその様々な関係に対して制御操作を実行するので、コントロール（Ｃ）はＣａｎｖａｓに含まれるＣｏｍｍａｎｄを含む。
【０１３７】
Ｋ．文書の表現
図１０を用いて、文書及びその様々な表現の例について以下に説明する。この例で使用される文書は、テキストと画像の双方を含む。テキストは、ＸＨＴＭＬを用いて表され、画像は、ＳＶＧを用いて表される。図１０は、文書のコンポーネント及び対応するオブジェクトの関係のＭＶＣ表現を詳細に示す。この例において、Ｄｏｃｕｍｅｎｔ１００１は、Ｄｏｃｕｍｅｎｔ１００１を保持するＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ１００２にアタッチされる。文書はＤＯＭツリー１００３により表現される。ＤＯＭツリーは、ＡｐｅｘＮｏｄｅ１００４を含む。
【０１３８】
ＡｐｅｘＮｏｄｅは、黒丸で表される。頂点でないノードは、白丸で表される。ノードを編集するために用いられるＦａｃｅｔは、三角形で表され、対応するノードにアタッチされる。文書がテキストと画像を有するので、この文書のＤＯＭツリーは、ＸＨＴＭＬ部分とＳＶＧ部分を含む。ＡｐｅｘＮｏｄｅ１００４は、ＸＨＴＭＬサブツリーの最上のノードである。これは、文書のＸＨＴＭＬ部分の物理的な表現のための最上ＰａｎｅであるＸＨＴＭＬＰａｎｅ１００５にアタッチされる。ＡｐｅｘＮｏｄｅ１００４は、文書のＤＯＭツリーの一部であるＸＨＴＭＬＺｏｎｅ１００６にもアタッチされる。
【０１３９】
Ｎｏｄｅ１００４に対応するＦａｃｅｔも、ＸＨＴＭＬＺｏｎｅ１００６にアタッチされる。ＸＨＴＭＬＺｏｎｅ１００６は、ＸＨＴＭＬＰａｎｅ１００５にアタッチされる。ＸＨＴＭＬＥｄｉｔｌｅｔは、文書の論理的な表現であるＸＨＴＭＬＣａｎｖａｓ１００７を生成する。ＸＨＴＭＬＣａｎｖａｓ１００７は、ＸＨＴＭＬＰａｎｅ１００５にアタッチされる。ＸＨＴＭＬＣａｎｖａｓ１００７は、Ｄｏｃｕｍｅｎｔ１００１のＸＨＴＭＬコンポーネントのためのＢｏｘＴｒｅｅ１００９を生成する。文書のＸＨＴＭＬ部分を保持し描画するために必要な様々なＣｏｍｍａｎｄ１００８も、ＸＨＴＭＬＣａｎｖａｓ１００５に追加される。
【０１４０】
同様に、文書のＳＶＧサブツリーのＡｐｅｘＮｏｄｅ１０１０は、文書のＳＶＧコンポーネントを表現するＤｏｃｕｍｅｎｔのＤＯＭツリーの一部であるＳＶＧＺｏｎｅ１０１１にアタッチされる。ＡｐｅｘＮｏｄｅ１０１０は、文書のＳＶＧ部分の物理的な表現の最上のＰａｎｅであるＳＶＧＰａｎｅ１０１３にアタッチされる。文書のＳＶＧ部分の論理的な表現を表すＳＶＧＣａｎｖａｓ１０１２は、ＳＶＧＥｄｉｔｌｅｔにより生成され、ＳＶＧＰａｎｅ１０１３にアタッチされる。画面上に文書のＳＶＧ部分をレンダリングするためのデータ構造及びコマンドは、ＳＶＧＣａｎｖａｓにアタッチされる。例えば、このデータ構造は、図示されるように、円、線、長方形などを含んでもよい。
【０１４１】
図１０に関連して説明された文書例の表現の一部について、図１１（ａ）、図１１（ｂ）に関連して、前述したＭＶＣパラダイムを用いて更に説明する。図１１（ａ）は、文書１００１のＸＨＴＭＬコンポーネントにおけるＭＶの関係を簡略化して示す。モデルは、Ｄｏｃｕｍｅｎｔ１００１のＸＨＴＭＬコンポーネントのためのＸＨＴＭＬＺｏｎｅ１１０３である。ＸＨＴＭＬＺｏｎｅのツリーには、いくつかのＮｏｄｅ及びそれらに対応するＦａｃｅｔが含まれる。対応するＸＨＴＭＬＺｏｎｅ及びＰａｎｅは、ＭＶＣパラダイムのモデル（Ｍ）部分の一部である。ＭＶＣパラダイムのビュー（Ｖ）部分は、Ｄｏｃｕｍｅｎｔ１００１のＨＴＭＬコンポーネントの、対応するＸＨＴＭＬＣａｎｖａｓ１１０２及びＢｏｘＴｒｅｅである。文書のＸＨＴＭＬ部分は、Ｃａｎｖａｓと、それに含まれるＣｏｍｍａｎｄを使用して画面に描写される。キーボードやマウス入力などのイベントは、図示されるように、逆方向へ進む。
【０１４２】
ＳｏｕｒｃｅＰａｎｅは、更なる機能、すなわち、ＤＯＭの保有者としての役割を有する。図１１（ｂ）は、図１１（ａ）に示したＤｏｃｕｍｅｎｔ１００１のコンポーネントに対するボキャブラリコネクションを提供する。ＤＯＭホルダーとして機能するＳｏｕｒｃｅＰａｎｅ１１０３は、文書のソースＤＯＭツリーを含む。ＣｏｎｎｅｃｔｏｒＴｒｅｅは、ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙにより生成され、デスティネーションＤＯＭの保有者としても機能するＤｅｓｔｉｎａｔｉｏｎＰａｎｅ１１０５を生成する。ＤｅｓｔｉｎａｔｉｏｎＰａｎｅ１１０５は、ＸＨＴＭＬＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓ１１０６としてボックスツリーの形式でレイアウトされる。
【０１４３】
Ｌ．プラグインサブシステム、ボキャブラリコネクション、及びコネクタの関係
図１２（ａ）−（ｃ）は、それぞれ、プラグインサブシステム、ボキャブラリコネクション、及びＣｏｎｎｅｃｔｏｒに関連する更なる詳細を示す。プラグインサブシステムは、文書処理システムに機能を追加又は交換するために用いられる。プラグインサブシステムは、ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１を含む。図１２（ａ）で示すように、「Ｍｙ Ｏｗｎ ＸＭＬ ｖｏｃａｂｕｌａｒｙ」はＶｃＢａｓｅＰｌｕｇＩｎとして提供され、そのプラグインには、Ｍｙ Ｏｗｎ ＸＭＬ ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙＴｒｅｅ及びボキャブラリ（ＺｏｎｅＦａｃｔｏｒｙＢｕｉｌｄｅｒ）を含む。ＳｅｒｖｉｃｅＢｒｏｋｅｒ１０４１にアタッチされるＺｏｎｅＦａｃｔｏｒｙＳｅｒｖｉｃｅ１２０１は、文書の一部に対するＺｏｎｅを生成する。ＥｄｉｔｌｅｔＳｅｒｖｉｃｅ１２０２も、ＳｅｒｖｉｃｅＢｒｏｋｅｒにアタッチされる。ＥｄｉｔｌｅｔＳｅｒｖｉｃｅ１２０２は、Ｚｏｎｅ中のＮｏｄｅに対応するＣａｎｖａｓを生成する。
【０１４４】
ＺｏｎｅＦａｃｔｏｒｙの例は、ＸＨＴＭＬＺｏｎｅ及びＳＶＧＺｏｎｅをそれぞれ生成するＸＨＴＭＬＺｏｎｅＦａｃｔｏｒｙ１２１１及びＳＶＧＺｏｎｅＦａｃｔｏｒｙ１２１２である。文書例に関連して前述したように、文書のテキストコンポーネントは、ＸＨＴＭＬＺｏｎｅを生成することにより表現されてもよいし、画像はＳＶＧＺｏｎｅを用いて表現されてもよい。ＥｄｉｔｌｅｔＳｅｒｖｉｃｅの例は、ＸＨＴＭＬＥｄｉｔｌｅｔ１２２１及びＳＶＧＥｄｉｔｌｅｔ１２２２を含む。
【０１４５】
図１２（ｂ）は、ボキャブラリコネクションに関連する更なる詳細を示す。ボキャブラリコネクションは、前述したように、文書処理システムの重要な特徴であり、２つの異なる方法で文書の整合のとれた表現及び表示を可能とする。ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３を保持するＶＣＭａｎａｇｅｒ３０２は、ボキャブラリコネクションサブシステムの一部である。図１２（ｃ）で示すように、ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３は、文書のＣｏｎｎｅｃｔｏｒ３０４を生成する。前述したように、Ｃｏｎｎｅｃｔｏｒは、ソースＤＯＭ中のノードを監視し、２つの表現の間の整合性を維持するために、デスティネーションＤＯＭ中のノードを修正する。
【０１４６】
Ｔｅｍｐｌａｔｅ３１７は、いくつかのノードの変換ルールを表す。ボキャブラリコネクション記述子（ＶＣＤ）ファイルは、特定のパス又はルールを満たす要素又は要素の集合を他の要素に変換するいくつかのルールを表すＴｅｍｐｌａｔｅのリストである。Ｔｅｍｐｌａｔｅ３１７及びＣｏｍｍａｎｄＴｅｍｐｌａｔｅ３１３１は、全てＶＣＭａｎａｇｅｒ３０２にアタッチされる。ＶＣＭａｎａｇｅｒは、ＶＣＤファイル中の全てのセクションを管理するオブジェクトである。１つのＶＣＤファイルに対して、１つのＶＣＭａｎａｇｅｒオブジェクトが生成される。
【０１４７】
図１２（ｃ）は、Ｃｏｎｎｅｃｔｏｒに関連する更なる詳細を提供する。ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３は、ソース文書からＣｏｎｎｅｃｔｏｒを生成する。ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３は、Ｖｏｃａｂｕｌａｒｙ、Ｔｅｍｐｌａｔｅ、及びＥｌｅｍｅｎｔＴｅｍｐｌａｔｅにアタッチされ、それぞれ、ＶｏｃａｂｕｌａｒｙＣｏｎｎｅｃｔｏｒ、ＴｅｍｐｌａｔｅＣｏｎｎｅｃｔｏｒ、ＥｌｅｍｅｎｔＣｏｎｎｅｃｔｏｒを生成ずる。
【０１４８】
ＶＣＭａｎａｇｅｒ３０２は、ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３を保持する。Ｖｏｃａｂｕｌａｒｙを生成するために、対応するＶＣＤファイルが読み込まれる。こうして、ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３が生成される。このＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙ３０３は、Ｚｏｎｅを生成するＺｏｎｅＦａｃｔｏｒｙ及びＣａｎｖａｓを生成するＥｄｉｔｌｅｔに関連する。
【０１４９】
つづいて、ターゲットボキャブラリのＥｄｉｔｌｅｔＳｅｒｖｉｃｅが、ＶＣＣａｎｖａｓを生成する。ＶＣＣａｎｖａｓも、ソースＤＯＭツリー又はＺｏｎｅにおけるＡｐｅｘＮｏｄｅのＣｏｎｎｅｃｔｏｒを生成する。必要に応じて、子のＣｏｎｎｅｃｔｏｒが再帰的に生成される。ＣｏｎｎｅｃｔｏｒＴｒｅｅは、ＶＣＤファイル中のテンプレートの集合により生成される。
【０１５０】
テンプレートは、マークアップ言語の要素を他の要素に変換するためのルールの集合である。例えば、各テンプレートは、ソースＤＯＭツリー又はＺｏｎｅにマッチされる。適切にマッチした場合には、頂点Ｃｏｎｎｅｃｔｏｒが生成される。例えば、テンプレート「Ａ／＊／Ｄ」は、間にどんなノードがあるかに関係なく、ノードＡで始まりノードＤで終わる全ての枝に合致する。同様に、「／／Ｂ」は、ルートからの全ての「Ｂ」ノードに一致する。
【０１５１】
Ｍ．ＣｏｎｎｅｃｔｏｒＴｒｅｅに関係するＶＣＤファイルの例
特定の文書と関係する処理を説明する例を続ける。ドキュメントタイトルのある「ＭｙＳａｍｐｌｅＸＭＬ」というタイトルの文書が文書処理システムにロードされる。図１３は、「ＭｙＳａｍｐｌｅＸＭＬ」ファイルのための、ＶＣＭａｎａｇｅｒ及びＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙＴｒｅｅを用いたＶＣＤスクリプトの例を示す。スクリプトファイル中のボキャブラリセクション、テンプレートセクションと、ＶＣＭａｎａｇｅｒにおける対応するコンポーネントが示される。タグ「ｖｃｄ：ｖｏｃａｂｕｌａｒｙ」において、属性「ｍａｔｃｈ」は「ｓａｍｐｌｅ：ｒｏｏｔ」、「ｌａｂｅｌ」は「ＭｙＳａｍｐｌｅＸＭＬ」、「ｃａｌｌ−ｔｅｍｐｌａｔｅ」は「ｓａｍｐｌｅ ｔｅｍｐｌａｔｅ」となっている。
【０１５２】
この例では、Ｖｏｃａｂｕｌａｒｙは、「ＭｙＳａｍｐｌｅＸＭＬ」のＶＣＭａｎａｇｅｒにおいて「ｓａｍｐｌｅ：ｒｏｏｔ」として頂点要素を含む。対応するＵＩラベルは、「ＭｙＳａｍｐｌｅＸＭＬ」である。テンプレートセクションにおいて、タグは「ｖｃｄ：ｔｅｍｐｌａｔｅ」であり、名前は「ｓａｍｐｌｅ：ｔｅｍｐｌａｔｅ」である。
【０１５３】
Ｎ．ファイルがシステムにロードされる方法の詳細な例
図１４−１８は、文書「ＭｙＳａｍｐｌｅＸＭＬ」のロードについての詳細な記述を示す。図１４（ａ）に示されるステップ１では、文書がストレージ１４０５からロードされる。ＤＯＭＳｅｒｖｉｃｅは、ＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ１４０１と対応するＤＯＭツリー及びＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１４０６を生成する。ＤｏｃｕｍｅｎｔＣｏｎｔａｉｎｅｒ１４０１は、ＤｏｃｕｍｅｎｔＭａｎａｇｅｒ１４０６にアタッチされる。文書は、ＸＨＴＭＬ及びＭｙＳａｍｐｌｅＸＭＬのサブツリーを含む。ＸＨＴＭＬのＡｐｅｘＮｏｄｅ１４０３は、タグ「ｘｈｔｍｌ：ｈｔｍｌ」が付されたＸＨＴＭＬの最上のノードである。「ＭｙＳａｍｐｌｅＸＭＬ」のＡｐｅｘＮｏｄｅ１４０４は、タグ「ｓａｍｐｌｅ：ｒｏｏｔ」が付された「ＭｙＳａｍｐｌｅＸＭＬ」の最上ノードである。
【０１５４】
図１４（ｂ）に示されるステップ２では、ＲｏｏｔＰａｎｅが文書のＸＨＴＭＬＺｏｎｅ、Ｆａｃｅｔ、及びＣａｎｖａｓを生成する。Ｐａｎｅ１４０７、ＸＨＴＭＬＺｏｎｅ１４０８、ＸＨＴＭＬＣａｎｖａｓ１４０９、及びＢｏｘＴｒｅｅ１４１０が、ＡｐｅｘＮｏｄｅ１４０３に対応して生成される。
【０１５５】
図１４（ｃ）に示されるステップ３では、ＸＨＴＭＬＺｏｎｅが知らないタグ「ｓａｍｐｌｅ：ｒｏｏｔ」を発見し、ＨＴＭＬＣａｎｖａｓの領域からＳｕｂＰａｎｅを生成する。
【０１５６】
図１５に示されるステップ４では、ＳｕｂＰａｎｅが「ｓａｍｐｌｅ：ｒｏｏｔ」を扱うことができ、適切なＺｏｎｅを生成可能なＺｏｎｅＦａｃｔｏｒｙを得る。このＺｏｎｅＦａｃｔｏｒｙは、ＺｏｎｅＦａｃｔｏｒｙを実行可能なＶｏｃａｂｕｌａｒｙ内にある。それは、「ＭｙＳａｍｐｌｅＸＭＬ」のＶｏｃａｂｕｌａｒｙＳｅｃｔｉｏｎの内容を含む。
【０１５７】
図１６に示されるステップ５では、「ＭｙＳａｍｐｌｅＸＭＬ」に対応するＶｏｃａｂｕｌａｒｙがＤｅｆａｕｌｔＺｏｎｅ１６０１を生成する。対応するＥｄｉｔｌｅｔが生成され、対応するＣａｎｖａｓを生成するためにＳｕｂＰａｎｅ１５０１が提供される。Ｅｄｉｔｌｅｔは、ＶＣＣａｎｖａｓを生成する。そして、それはＴｅｍｐｌａｔｅＳｅｃｔｉｏｎを呼ぶ。ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙＴｒｅｅも含まれている。ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙＴｒｅｅは、ＣｏｎｎｅｃｔｏｒＴｒｅｅとなる全てのＣｏｎｎｅｃｔｏｒを生成する。文書のＸＨＴＭＬコンテンツに関係するＡｐｅｘＮｏｄｅに対するＢｏｘＴｒｅｅとＸＨＴＭＬＣａｎｖａｓ同様に、ＲｏｏｔＰａｎｅとＸＨＴＭＬＺｏｎｅとの関係も前述の内容からすぐに理解されよう。
【０１５８】
図１７（ａ）に示されるステップ６では、ソースＤＯＭツリー間の対応をもとに、各ＣｏｎｎｅｃｔｏｒがデスティネーションＤＯＭオブジェクトを生成する。コネクタのうちのいくつかはｘｐａｔｈ情報を含んでいる。ｘｐａｔｈ情報は、変更／修正を監視する必要のあるソースＤＯＭツリーの部分集合を決定するために使用される１以上のｘｐａｔｈ表現を含む。
【０１５９】
図１７（ｂ）に示されるステップ７では、ソース・ＶＣ・ディスティネーションの関係に従って、ボキャブラリは、ソースＤＯＭのペインからデスティネーションＤＯＭツリーのＤｅｓｔｉｎａｔｉｏｎＰａｎｅを作成する。これは、ＳｏｕｒｃｅＰａｎｅに基づいてなされる。デスティネーションツリーのＡｐｅｘＮｏｄｅは、ＤｅｓｔｉｎａｔｉｏｎＰａｎｅ及び対応するＺｏｎｅにアタッチされる。ＤｅｓｔｉｎａｔｉｏｎＰａｎｅは、ＤｅｓｔｉｎａｔｉｏｎＣａｎｖａｓを生成し、文書をデスティネーションのフォーマットでレンダリングするためのデータ構造及びコマンドを構築する、自身のＥｄｉｔｌｅｔを提供される。
【０１６０】
図１８（ａ）は、対応するソースノードを持たず、デスティネーションツリーにのみ存在するノード上でイベントが発生したときのフローを示す。マウスイベント、キーボードイベントなど、Ｃａｎｖａｓが取得したイベントは、デスティネーションツリーを通過して、ＥｌｅｍｅｎｔＴｅｍｐｌａｔｅＣｏｎｎｅｃｔｏｒに伝達される。ＥｌｅｍｅｎｔＴｅｍｐｌａｔｅＣｏｎｎｅｃｔｏｒは対応するソースノードを持たないので、伝達されたイベントはソースノードに対する編集操作ではない。ＥｌｅｍｅｎｔＴｅｍｐｌａｔｅＣｏｎｎｅｃｔｏｒは、伝達されたイベントがＣｏｍｍａｎｄＴｅｍｐｌａｔｅに記述されたコマンドに合致すれば、それに対応するＡｃｔｉｏｎを実行する。合致するコマンドがなければ、ＥｌｅｍｅｎｔＴｅｍｐｌａｔｅＣｏｎｎｅｃｔｏｒは、伝達されたイベントを無視する。
【０１６１】
図１８（ｂ）は、ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒによりソースノードに対応づけられているデスティネーションツリーのノード上でイベントが発生したときのフローを示す。ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒは、ソースＤＯＭツリーのＸＰａｔｈで指定されたノードからテキストノードを取得して、デスティネーションＤＯＭツリーのノードにマッピングする。マウスイベント、キーボードイベントなど、Ｃａｎｖａｓが取得したイベントは、デスティネーションツリーを通過して、ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒに伝達される。ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒは、伝達されたイベントを、対応するソースノードの編集コマンドにマッピングし、Ｑｕｅｕｅ１０５３に積む。編集コマンドは、Ｆａｃｅｔを介して実行されるＤＯＭのＡＰＩコールの集合である。キューに積まれたコマンドが実行されると、ソースノードが編集される。ソースノードが編集されると、ミューテーションイベントが発行され、リスナーとして登録されたＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒにソースノードの変更が通知される。ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒは、ソースノードの変更を、対応するデスティネーションノードに反映させるように、デスティネーションツリーを再構築する。このとき、ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒを含むテンプレートに、「ｆｏｒ ｅａｃｈ」や「ｆｏｒ ｌｏｏｐ」などの制御文が含まれている場合、ＣｏｎｎｅｃｔｏｒＦａｃｔｏｒｙがこの制御文を再評価し、ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒを再構築した後、デスティネーションツリーが再構築される。
【０１６２】
（取消操作の詳細）
本発明は、ＸＭＬなどのマークアップ言語を用いて用意された文書における変更を、プログラマがコマンドを直接取り消す操作を実装したり、ＤＯＭ構造を自身で編集し全ての変更を監視可能に設けたりするよりも、効率的な方式で取り消す機能に関する。
【０１６３】
開示された文書処理／管理システムにおいて取消機能を提供するための効率的な方法及び構成の必要性により、図８（ａ）及び図８（ｂ）に関連して既に説明した第１の方法が導かれた。ユーザにより発行されたコマンドに対応する文書７０５の編集は、ミューテーションイベント及びＤＯＭに対する変更として監視され、取消可能な編集として識別されて、後のアクセスのためにアンドゥ管理部７０６に格納される。別の方法も、ＤＯＭツリーを監視し、ＤＯＭツリー自身を、取消可能なコマンドにより受信される取消可能な編集を発行し、蓄積及び後のアクセスのためにアンドゥ管理部に送信するオブジェクトとして用いることにより実現される。いずれの場合も、ＤＯＭツリーとして文書を表現することに関連して２つの方法を説明したが、開示された技術はツリー又はグラフとして表現可能な任意の情報に適用可能であるから、本発明はＤＯＭツリー構造の使用に限られない。
【０１６４】
取消操作を実現するための最初の方法に関連して、図７（ａ）、８（ａ）、８（ｂ）、及び１１（ｂ）に関連して既に説明したように、図３に示したｃｏｎｎｅｃｔＸｐａｔｈの機能であるＸｐａｔｈを用いて、コネクタがソースノードを監視する。Ｘｐａｔｈは、テンプレートマッチングプロセスにおいてテンプレートを用いてソースノードを監視する。任意の種類のテンプレートマッチングがソースＤＯＭツリーのノードの部分集合を監視するための用いられてもよい。実際の例において、ＤＯＭツリーの部分集合は、ＤＯＭツリーの部分集合を監視し、部分集合がテンプレートにマッチするか否かを判定する基本的なテンプレート方式を用いて監視されてもよい。監視されたＤＯＭツリーの部分集合における任意の変更が検出されると、監視された部分集合における変更を反映するために、ＤＯＭツリーの表現が自動的に更新される。例えば、ＤＯＭに対する変更を監視することに関連して既に説明したように、テンプレート「Ａ／＊／Ｄ」は、間のノードが何であるかに関わらず、ノード「Ａ」で始まり、ノード「Ｄ」で終わるツリーの全ての枝を監視する。同様に、「／／Ｂ」は、ルートからの全てのノード「Ｂ」に対応する。
【０１６５】
ｃｏｎｎｅｃｔＸｐａｔｈにより監視されたノードの集合内のノードに変更が生じたとき、ＤＯＭ構造内の変更イベントのリスナーがこれを受信する。ミューテーションイベントリスナーは、変更イベントを識別すると、「ミューテーションイベント」通知を送信する。ｃｏｎｎｅｃｔＸｐａｔ（図１７参照）ｈは、このミューテーションイベントを取得する。ｃｏｎｎｅｃｔＸｐａｔｈは、ミューテーションイベントを評価する。監視されたノードに変更が生じると、値の変更を受信する１以上の機能が通知される。監視されたノードに影響を与える他のノードが存在する場合、これらのノードもリスナーに提供される。
【０１６６】
図１９（ａ）は、ｃｏｎｎｅｃｔＸｐａｔｈがＶＣとともに用いられた、変更ベースの取消操作の実装例を示す。編集される文書は、ＤＯＭ１９１０により表現される。ＤＯＭ１９１０は、ノードＡを頂点ノードとする複数のリンクされたノードＡ、Ｂ、Ｃ、Ｄ、及びＥを有する。編集の結果、波線により示されるように、別のノードＢがノードＡに追加される。ＶＣＤはルートからそれぞれの元の「Ｂ」ノードの表現を生成するように記述されている。この場合、この場合、ｃｏｎｎｅｃｔＸｐａｔｈは、テンプレート「／／Ｂ」のパスを充足する全てのノードを監視する。図から分かるように、実際のＤＯＭには、２つの「Ｂ」ノード１９０１、１９０２がある。第３の「Ｂ」ノード１９０３が編集されたＤＯＭに追加される。ｃｏｎｎｅｃｔＸｐａｔｈ１９０５はＤＯＭに対するこの変更１９０４をピックアップし、新規に生成された「Ｂ」ノードにマップする。ミューテーションイベント１９０４も、取消編集オブジェクトを生成し登録するために、アンドゥ管理部１９４０に提供される。
【０１６７】
必要であれば、適切なミューテーションイベントのみが実行されるように、文書の特定の部分が監視され、抽出される。
【０１６８】
図１９（ｂ）は、ＤＯＭの変更が取消可能な編集の生成及び保存をもたらす別の方式の概略的表現である。図１（ｂ）において、コマンドシステム１０５に関連して既に説明したように、本発明によれば、ＤＯＭに対する操作は、ユーザが定義可能なＤＯＭ操作である「コマンド」にカプセル化される。コマンドが実行されると、ＤＯＭはなされた変更のそれぞれについて「取消可能な編集」を発行し、ＵｎｄｏａｂｌｅＣｏｍｍａｎｄサービスは「取消可能な編集」を検出して、対応する取消操作を生成する。実行が終わると、まとめられた取消可能な編集が取消のためにアンドゥ管理部に登録される。
【０１６９】
再び図１９（ｂ）を参照して、ノードＡを頂点ノードとする複数のリンクされたノードＡ、Ｂ、Ｃ、Ｄ、及びＥを有するＤＯＭ１９１０のツリー状の表現が設けられる。ノードＡにつながる波線により示されるようにノードＢを変更する編集の結果、変更を指示した複数のＵｎｄｏａｂｌｅＣｏｍｍａｎｄ１９２０のうちの１つが変更の実行を検知し、ＵｎｄｏａｂｌｅＥｄｉｔ１９３０を生成させる。ＵｎｄｏａｂｌｅＥｄｉｔ１９３０は、与えられた変更を取り消す必要が生じたときのアクセスのために、アンドゥ管理部１９３０（図２のＵｎｄｏＭａｎａｇｅｒ２１２１に対応する）に格納される。編集は、文書のテキスト、図、チャート、画像、又は音楽及び映像要素のいずれであってもよい。
【０１７０】
図２０及び２１は、複合取消編集操作の図解及びチャート形式の流れをそれぞれ提供する。アンドゥプロセス２０００、２１００によれば、第１のフローステップ２１１０において、１以上のインスタンス２０１１、２０１２において発行された種々のコマンドのいすれかによるＤＯＭ２００５の操作又は変更ＤＯＭ２００５の変更のトリガとなる。ＤＯＭの操作は、このようなコマンド、例えば、図７（ａ）、８（ａ）、及び８（ｂ）におけるＵｎｄｏａｂｌｅＥｄｉｔＡｃｃｅｐｔｏｒ７０８に対応するＵｎｄｏａｂｌｅＣｏｍｍａｎｄ２０３０を介して発行されなければならない。このような変更は、ステップ２１２０において、ＤＯＭ２００５による１以上のＵｎｄｏａｂｌｅＥｄｉｔ２０２５、２０２６などの生成をもたらす。それぞれのＵｎｄｏａｂｌｅＥｄｉｔ２０２５、２０２６などは、ＵｎｄｏａｂｌｅＣｏｍｍａｎｄプロセス２０３０によりピックアップされる１以上の取消可能な編集オブジェクトに関連付けられ、ステップ２１３０において、発行されたコマンドの実行が終了するまで収集される。編集は細かい粒度で発行され、ＤＯＭに対する意味のある操作の集合を形成するように収集されなければならないので、複数の取消可能な編集オブジェクトの収集が必要である。図７（ａ）に関連して、この収集操作はＵｎｄｏＷｒａｐｐｅｒ７０７により実行される。収集された又はラップされた取消可能な編集オブジェクトは、ステップ２１４０に示されるように、アンドゥ管理部２０４０（図７（ａ）では７０６）に登録される。
【０１７１】
複数のＵｎｄｏａｂｌｅＥｄｉｔＣｏｍｍａｎｄが存在するとき、与えられた文書のために集められた「複合編集」２０５０がある。この場合、実行が完了すると、ＵｎｄｏａｂｌｅＣｏｍｍａｎｄ２０３０の１以上のＵｎｄｏａｂｌｅＥｄｉｔの集合がアンドゥ管理部５６０に登録される。
【０１７２】
ＵｎｄｏａｂｌｅＣｏｍｍａｎｄプロセスの実施例は、図２２−３２に示される複合文書の複合編集に関連した一連のスクリーンショットの形式で提供される。スクリーンショットは、複合文書に対するいくつかの編集を通じて、本発明の実施の形態に係る取消操作の流れを示す。文書自体は、画面上に表示されるＸＨＴＭＬ部分とＳＶＧ部分の組合せである。画面は、既知のＪａｖａ（登録商標）−Ｅｃｌｉｐｓｅプラットフォームに基づく。
【０１７３】
図２２に示した取消操作は、ＸＨＴＭＬ部分２２１０、ＳＶＧ部分２２２０、及び別のＸＨＴＭＬ部分２２３０を有する複合文書２２００の編集を含む。前述の説明に基づいて、編集操作は文書を表現するモデルであるＤＯＭの操作により実現されることが理解されよう。ＤＯＭに対する変更はＤＯＭにより発行され、アンドゥ管理部２０４０に収集され格納される変更及び／又は取消可能な編集を検知することにより監視される。ユーザにより入力される一連の編集コマンドとして、ＤＯＭが変更され、アンドゥ管理部のエントリが蓄積される。以前のエントリは上書き又は破壊されない。さらに、ＤＯＭが操作されると、文書のモデルとしてのＤＯＭの現バージョンが、文書の現在編集されたバージョンの表示を画面に描画するために用いられる。前述したように、ボックス方式を用いることにより、レンダリングのスピードを向上させることができる。同じ又はリンクされた文書の複数のＸＭＬコンテンツの間のリンクに基づいて、リンクされた全ての表示要素に編集が反映される。同様に、編集が逆戻り又は取り消されると、取消可能な編集オブジェクトを取得するためにアンドゥ管理部２０４０にアクセスし、ＤＯＭの変更により編集が逆戻りされる。後述するように、ＤＯＭの描画により編集の逆戻りが示される。
【０１７４】
図２３に関連して、「第１の編集」２３１０がＸＨＴＭＬ部分２１１０において文書２２００になされ、「第２の編集」２２２０がＳＶＧ部分２２２０になされる。その後、「第３の編集」２３３０がＸＨＴＭＬ部分２２１０になされる。本発明は、取消機能を確立し、処理する機能を有し、図２３の例に示したように、「第３の編集」２３３０、「第２の編集」２３２０、及び「第１の編集」２３１０に対するシームレスな取消操作を実現する。
【０１７５】
図２４は、ユーザの画面に表示された第１の編集２３１０、第２の編集２３２０、及び第３の編集２３３０と、ソースコーリスト２４００の対応するエントリ２４１０、２４２０、及び２４３０を並列して示す。
【０１７６】
上述したように、取消操作は、それぞれの取消編集をアンドゥオブジェクトとして格納又は登録したアンドゥ管理部２０４０にアクセスすることにより実行される。アンドゥオブジェクトの取得により、文書のモデルとしてのＤＯＭに更なる操作が行われ、実行された編集を逆に勧めることによりＤＯＭが元に戻される。後述するように、編集が元に戻されたことが、画面上にＤＯＭをレンダリングすることにより示される。こうして、図２５に示すように、入力時において最後の編集であった「第３の編集」から「取消」が開始され、追加されたＸＨＴＭＬの編集の最後の文字から取り消しが始まる。図示するように、最後の編集の最後の文字は「ｔ」であり、図の２５１０に文字「ｔ」が取り消された状態が示される。取消操作は、ＸＨＴＭＬアプリケーションに対して、編集が完了するまで文字毎に続行される。つづいて、取消操作は、用いられたアプリケーション（ＸＨＴＭＬ、ＳＶＧ、ＭＡＴＨＭＬなど）にかかわらず、最後から２番目に入力された編集へ続く。
【０１７７】
例によれば、最後から２番目の編集は「第２の編集」２３２０であったので、取消処理により「第３の編集」が削除されると、次の取消操作は第２の編集にうつり、図２６に示すように、その全体が削除されるまで続けられる。第２の編集は１つの操作により追加されたので、１つの取消操作で削除可能である。第１の編集２３１０はまだ残っている。
【０１７８】
図２７に示すように、更なる取消操作は「第１の編集」２３１０にうつり、本発明の一形態によれば、ＸＨＴＭＬによる入力は文字毎に扱われるので、２７１０で示される文字「ｔ」の削除から開始される。文書のＸＨＴＭＬ部分において、取消操作を目的とした文字毎の取扱が望ましいが、単語毎、文毎など、必要であれば他のルールに変更可能であることは明らかである。
【０１７９】
取消操作が完了し、第１、第２、及び第３の編集の全てが取り消されると、図２８に示した画面となる。
【０１８０】
図２９は、コマンドベースの取消操作を示す。この「ｄａｉｌｙ−ｒｅｐｏｒｔ２．ｖｃｄ」において、コマンド「ａｄｄ−ｒｅｐｏｒｔ」が定義される。このコマンドを実行すると、レポートが追加される。その他のコマンド、例えば、「レポートの削除」、「画像の削除」、「新規ＳＶＧ」、「テーブル挿入」などが定義されてもよい。コマンドの実行は、編集の準備、実行（図１０に関連して説明した方式で図２の「Ｆａｃｅｔ」２０２２サービスを用いて）、登録を含む。コマンドが実行され登録されると、取消操作が可能となる。取消操作は、コマンド全体を取り消す効果を有する。ユーザに提示されるコマンド自体を図３０に示す。
【０１８１】
タグ「ｄｉａｒｙ：ｒｅｐｏｒｔ」及びその子が図３１において追加される。この画面から取消操作を実行すると、図３２にようになる。１つの取消操作でコマンド自体を取り消すことができる。
【０１８２】
上記の説明から、ＤＯＭの監視が変更の監視によるものであっても、取消編集コマンドの識別によるものであっても、後続の逆戻りのために取消イベントオブジェクトの収集及び登録をもたらす。検知、識別、及び登録は、イベントベースで行われてもよいし、ボックスツリー方式を用いてイベントを収集することにより行われてもよい。後者の場合、複数のイベントが単一のボックスに発生するので、変更されたがまだ描画されていないボックスの内容を識別する「ダーティーフラグ」技術が用いられてもよい。こうして、描画は、異なるスレッドを用いた並列的な実行により、文書に対する関連した複数の変更が完了するまで、適切な期間延期される。
【０１８３】
さらに、開示された取消技術により、プログラマは、コマンドを用いる所定のテンプレートを参照するだけで取消操作のためのコマンドを用意することができる。この方式では、Ｊａｖａ（登録商標）言語の抽象クラスとして編集操作を実装可能である。
【０１８４】
本発明の他の改良や変更は、上記の開示及び教示から当業者には明らかである。したがって、本発明の特定の実施例のみをとくに例示したが、本発明の趣旨及び範囲から逸脱することなく、それらに種々の変更が可能であることは明らかである。
【図面の簡単な説明】
【０１８５】
【図１（ａ）】開示した文書処理システムの典型的な実装の基本となるコンポーネントの標準的な配置を示す図である。
【図１（ｂ）】典型的な文書処理システムの全体的なブロック図である。
【図１（ｃ）】典型的な文書処理システムの全体的なブロック図である。
【図２】「Ｄｏｃｕｍｅｎｔ Ｍａｎａｇｅｒ」の典型的な実装について詳細を示す図である。
【図３】「Ｖｏｃａｂｕｌａｒｙ Ｃｏｎｎｅｃｔｉｏｎ」サブシステム３００の典型的な実装について詳細を示す図である。
【図４】図４（ａ）は、「Ｐｒｏｇｒａｍ Ｉｎｖｏｋｅｒ」及びそれに関連する他のコンポーネントの典型的な実装について詳細を示す図であり、図４（ｂ）は、「Ｓｅｒｖｉｃｅ Ｂｒｏｋｅｒ」及びそれに関連する他のコンポーネントの典型的な実装について詳細を示す図であり、図４（ｃ）は、「Ｓｅｒｖｉｃｅ」の典型的な実装について詳細を示す図であり、図４（ｄ）は、「Ｓｅｒｖｉｃｅ」の例を示す図であり、図４（ｅ）は、「Ｐｒｏｇｒａｍ Ｉｎｖｏｋｅｒ」１０３と「Ｕｓｅｒ Ａｐｐｌｉｃａｔｉｏｎ」１０６との関係について詳細を示す図である。
【図５】図５（ａ）は、「Ｐｒｏｇｒａｍ Ｉｎｖｏｋｅｒ」上に展開される「Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ」の構造について詳細を示す図であり、図５（ｂ）は、「Ｆｒａｍｅ」、「ＭｅｎｕＢａｒ」、「ＳｔａｔｕｓＢａｒ」の関係の例を示す図であり、
【図６】図６（ａ）は、「Ａｐｐｌｉｃａｔｉｏｎ Ｃｏｒｅ」の典型的な実装について詳細を示す図であり、図６（ｂ）は、「Ｓｎａｐ Ｓｈｏｔ」の典型的な実装について詳細を示す図である。
【図７】図７（ａ）は、「Ａｐｐｌｉｃａｔｉｏｎ Ｃｏｒｅ」の典型的な実装について詳細を示す図であり、図７（ｂ）は、ＡからＥの「Ｄｏｃｕｍｅｎｔ」の組がどのように階層化されるのかの例を示す図であり、図７（ｃ）は、図７（ｂ）で示した「Ｄｏｃｕｍｅｎｔ」の階層がスクリーン上でどのように見えるのかの例を示す図である。
【図８】「Ｕｎｄｏ Ｆｒａｍｅｗｏｒｋ」及び「Ｕｎｄｏ Ｃｏｍｍａｎｄ」の典型的な実装の詳細を示す図である。
【図９】図９（ａ）は、図１（ｂ）、図１（ｃ）で示す文書処理システム内に「Ｄｏｃｕｍｅｎｔ」がどのように展開されるかの全体像を示す図であり、図９（ｂ）は、ＭＶＣパラダイムを使って、「Ｚｏｎｅ」の構造の概要を示す図である。
【図１０】本発明に従って、「Ｄｏｃｕｍｅｎｔ」とその様々な表現の例を示す図である。
【図１１】図１１（ａ）は、図１０で示す「Ｄｏｃｕｍｅｎｔ」のＸＨＴＭＬコンポーネントに対する「ＭＶ」関係の概要を示す図であり、図１１（ｂ）は、図１１（ａ）で示す「Ｄｏｃｕｍｅｎｔ」に対するボキャブラリコネクションを示す図である。
【図１２】プラグインサブシステム、ボキャブラリコネクション、コネクタそれぞれの典型的な実装について詳細を示す図である。
【図１３】ＭｙＳａｍｐｌｅＸＭＬに対して、ボキャブラリコネクションマネージャとコネクタファクトリーツリーを使用するＶＣＤスクリプトの例を示す図である。
【図１４】図１（ｂ）の典型的な文書処理システムの中に、文書例ＭＹＳａｍｐｌｅＸＭＬが展開されるステップ０から３を示した図である。
【図１５】図１（ｂ）の典型的な文書処理システムの中に、文書例ＭｙＳａｍｐｌｅＸＭＬが展開されるステップ４を示した図である。
【図１６】図１（ｂ）の典型的な文書処理システムの中に、文書例ＭｙＳａｍｐｌｅＸＭＬが展開されるステップ５を示した図である。
【図１７（ａ）】図１（ｂ）の典型的な文書処理システムの中に、文書例ＭｙＳａｍｐｌｅＸＭＬが展開されるステップ６を示した図である。
【図１７（ｂ）】図１（ｂ）の典型的な文書処理システムの中に、文書例ＭｙＳａｍｐｌｅＸＭＬが展開されるステップ７を示した図である。
【図１８】図１８（ａ）は、対応するソースノードを持たず、ディスティネーションツリーのみに依存するノードで発生するイベントのフローを示す図であり、図１８（ｂ）は、「ＴｅｘｔＯｆＣｏｎｎｅｃｔｏｒ」によりソースノードと連動するディスティネーションツリーのノードで発生するイベントのフローを示す図である。
【図１９（ａ）】ＤＯＭの変更が取消可能コマンドの生成及び保存をもたらす様子を概略的に示す図である。
【図１９（ｂ）】ＤＯＭの変更が取消可能コマンドの生成及び保存をもたらす様子を概略的に示す図である。
【図２０】ＤＯＭの変更が複合的な編集をもたらす様子を概略的に示す図である。
【図２１】図２０でなされた変更により表現される手順を示すフローチャートである。
【図２２】ＸＨＴＭＬ及びＳＶＧコンテンツを有する複合文書を処理における取消操作の流れの第１のスクリーンショットを示す図である。
【図２３】第１から第３の編集を行った図２２の文書のスクリーンショットを示す図である。
【図２４】ソースコードを付した図２２の文書のスクリーンショットを示す図である。
【図２５】ＸＨＴＭＬの第３の編集を文字ごとに取り消す操作のスクリーンショットを示す図である。
【図２６】第３（ＸＨＴＭＬ）及び第２（ＳＶＧ）の編集の取消操作のスクリーンショットを示す図である。
【図２７】残りの第１の編集の取消操作のスクリーンショットを示す図である。
【図２８】全ての編集が実行されていない状態のスクリーンショットを示す図である。
【図２９】コマンドベースの取消操作のスクリーンショットを示す図である。
【図３０】図２９のコマンド自体のスクリーンショットを示す図である。
【図３１】「ｄｉａｒｙ：ｒｅｐｏｒｔ」要素が追加された状態のスクリーンショットを示す図である。
【図３２】取消操作の結果のスクリーンショットを示す図である。
【符号の説明】
【０１８６】
【特許請求の範囲】
【請求項１】
ＤＯＭにより表現されたＸＭＬ文書の取消を提供する方法であって、
前記ＤＯＭの変更を検知する工程と、
前記ＤＯＭにおける検知された変更に対応する編集命令を生成する工程と、
コマンドにより前記編集命令を検知する工程と、
複数の検知された前記編集命令を収集する工程と、
収集された前記編集命令を登録する工程と、
を備えることを特徴とする方法。
【請求項２】
前記検知する工程は、前記ＤＯＭにおける複数の変更を検知する工程を含み、
前記生成する工程は、前記ＤＯＭにおけるそれぞれの変更に対する編集命令を生成する工程を含み、
前記検知する工程は、コマンドが複数の編集命令を検知する工程を含み、
前記登録する工程は、前記複数の編集命令を前記コマンドとともに登録する工程を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記ＤＯＭに対する前記複数の変更の少なくとも２つは、異なるアプリケーションによることを特徴とする請求項２に記載の方法。
【請求項４】
前記アプリケーションの少なくとも１つは、ＸＨＴＭＬ及びＳＶＧの少なくとも１つであることを特徴とする請求項３に記載の方法。
【請求項５】
登録された前記命令の少なくとも１つを取得する工程と、
前記ＤＯＭの対応する部分を再構築するために前記取得した編集命令を適用する工程と、
を更に備えることを特徴とする請求項１に記載の方法。
【請求項６】
前記取得する工程は、複数の登録された命令を取得する工程を含み、
前記適用する工程は、前記ＤＯＭの対応する部分を再構築するために前記複数の命令を適用する工程を含むことを特徴とする請求項５に記載の方法。
【請求項７】
前記複数の登録された命令は、単一のコマンドに関することを特徴とする請求項６に記載の方法。
【請求項８】
前記複数の登録された命令は、複数のコマンドに関することを特徴とする請求項６に記載の方法。
【請求項９】
前記複数の登録された命令は、それらが生成された順序とは逆に適用されることを特徴とする請求項６に記載の方法。
【請求項１０】
前記アプリケーションの少なくとも１つはＸＨＴＭＬアプリケーションであり、
前記複数の登録された命令は、前記ＸＨＴＭＬアプリケーションにおける個々の文字に関することを特徴とする請求項４に記載の方法。
【請求項１１】
前記登録された編集命令の少なくとも１つにアクセスする工程と、
前記登録された編集命令を用いて編集の取消を指示する工程と、
を更に備えることを特徴とする請求項１に記載の方法。
【請求項１２】
ＤＯＭにより表現されたＸＭＬ文書の取消を提供する方法であって、
前記ＤＯＭの変更を検知する工程と、
前記ＤＯＭにおける検知された変更に対応する変更イベントを生成する工程と、
検知された前記変更イベントを収集し、対応する編集命令を生成する工程と、
生成された編集命令を登録する工程と、
を備えることを特徴とする方法。
【請求項１３】
前記登録された編集命令の少なくとも１つにアクセスする工程と、
前記登録された編集命令を用いて編集の取消を指示する工程と、
を更に備えることを特徴とする請求項１２に記載の方法。
【請求項１４】
ＤＯＭにより表現されたＸＭＬ文書の取消を提供する機能を有する文書管理システムであって、
前記ＤＯＭの変更を検知する手段と、
前記ＤＯＭにおける検知された変更に対応する編集命令を生成する手段と、
コマンドにより前記編集命令を検知する手段と、
複数の検知された前記編集命令を収集する手段と、
前記コマンド及び収集された前記編集命令を登録する手段と、
を備えることを特徴とする文書管理システム。
【請求項１５】
前記検知する手段は、前記ＤＯＭにおける複数の変更を検知する機能を含み、
前記生成する手段は、前記ＤＯＭにおけるそれぞれの変更に対する編集命令を生成する機能を含み、
前記検知する手段は、複数の編集命令を検知する機能を含むコマンドを有し、
前記登録する手段は、前記複数の編集命令を前記コマンドとともに登録する機能を含むことを特徴とする請求項１４に記載の文書管理システム。
【請求項１６】
前記ＤＯＭに対する前記複数の変更の少なくとも２つは、異なるアプリケーションによることを特徴とする請求項１５に記載の文書管理システム。
【請求項１７】
前記アプリケーションの少なくとも１つは、ＸＨＴＭＬ及びＳＶＧの少なくとも１つであることを特徴とする請求項１６に記載の文書管理システム。
【請求項１８】
登録された前記命令の少なくとも１つを取得する手段と、
前記ＤＯＭの対応する部分を再構築するために前記取得した編集命令を適用する手段と、
を更に備えることを特徴とする請求項１４に記載の文書管理システム。
【請求項１９】
前記取得する手段は、複数の登録された命令を取得する機能を含み、
前記適用する手段は、前記ＤＯＭの対応する部分を再構築するために前記複数の命令を適用する機能を含むことを特徴とする請求項１８に記載の文書管理システム。
【請求項２０】
前記複数の登録された命令は、単一のコマンドに関することを特徴とする請求項１９に記載の文書管理システム。
【請求項２１】
前記複数の登録された命令は、複数のコマンドに関することを特徴とする請求項１９に記載の文書管理システム。
【請求項２２】
前記複数の登録された命令は、それらが生成された順序とは逆に適用されることを特徴とする請求項１９に記載の文書管理システム。
【請求項２３】
前記アプリケーションの少なくとも１つはＸＨＴＭＬアプリケーションであり、
前記複数の登録された命令は、前記ＸＨＴＭＬアプリケーションにおける個々の文字に関することを特徴とする請求項１７に記載の文書管理システム。
【請求項２４】
ＤＯＭにより表現されたＸＭＬ文書の取消を提供する機能を有する文書管理システムであって、
前記ＤＯＭの変更を検知する手段と、
前記ＤＯＭにおける検知された変更に対応する変更イベントを生成する手段と、
前記変更イベントに基づいて編集命令を生成する手段と、
前記コマンド及び複数の検知された編集命令を登録する手段と、
を備えることを特徴とする文書管理システム。
【請求項２５】
ＤＯＭにより表現されたＸＭＬ文書の取消を提供する機能を有し、プロセッサと、メモリと、ディスプレーと、操作入力手段と、を有する装置であって、
前記ＤＯＭの変更を検知する手段と、
前記ＤＯＭにおける検知された変更に対応する編集命令を生成する手段と、
コマンドにより前記編集命令を検知する手段と、
前記コマンド及び検知された前記編集命令を登録する手段と、
を備えることを特徴とする装置。
【請求項２６】
前記検知する手段は、前記ＤＯＭにおける複数の変更を検知する機能を含み、
前記生成する手段は、前記ＤＯＭにおけるそれぞれの変更に対する編集命令を生成する機能を含み、
前記検知する手段は、複数の編集命令を検知する機能を含むコマンドを有し、
前記登録する手段は、前記複数の編集命令を前記コマンドとともに登録する機能を含むことを特徴とする請求項２５に記載の装置。
【請求項２７】
前記ＤＯＭに対する前記複数の変更の少なくとも２つは、異なるアプリケーションによることを特徴とする請求項２６に記載の装置。
【請求項２８】
前記アプリケーションの少なくとも１つは、ＸＨＴＭＬ及びＳＶＧの少なくとも１つであることを特徴とする請求項２７に記載の装置。
【請求項２９】
登録された前記命令の少なくとも１つを取得する手段と、
前記ＤＯＭの対応する部分を再構築するために前記取得した編集命令を適用する手段と、
を更に備えることを特徴とする請求項２５に記載の装置。
【請求項３０】
前記取得する手段は、複数の登録された命令を取得する機能を含み、
前記適用する手段は、前記ＤＯＭの対応する部分を再構築するために前記複数の命令を適用する機能を含むことを特徴とする請求項２９に記載の装置。
【請求項３１】
前記複数の登録された命令は、単一のコマンドに関することを特徴とする請求項３０に記載の装置。
【請求項３２】
前記複数の登録された命令は、複数のコマンドに関することを特徴とする請求項３０に記載の装置。
【請求項３３】
前記複数の登録された命令は、それらが生成された順序とは逆に適用されることを特徴とする請求項３０に記載の装置。
【請求項３４】
前記アプリケーションの少なくとも１つはＸＨＴＭＬアプリケーションであり、
前記複数の登録された命令は、前記ＸＨＴＭＬアプリケーションにおける個々の文字に関することを特徴とする請求項２８に記載の装置。
【請求項３５】
ＤＯＭにより表現されたＸＭＬ文書の取消を提供する機能を有し、プロセッサと、メモリと、ディスプレーと、操作入力手段と、を有する装置であって、
前記ＤＯＭの変更を検知する手段と、
前記ＤＯＭにおける検知された変更に対応する変更イベントを生成する手段と、
前記変更イベントに基づいて編集命令を生成する手段と、
前記コマンド及び複数の検知された編集命令を登録する手段と、
を備えることを特徴とする装置。
【請求項３６】
ＸＭＬ文書を編集し、前記文書の編集を取り消す機能を有するプログラムを提供するためのユーザインタフェースであって、
少なくとも１つの編集可能部分を備える編集可能なＸＭＬ文書の表示と、
ＤＯＭの変更を生成し、表示されたＸＭＬ文書を編集し、コマンド及び編集命令を格納させる、前記編集可能なＸＭＬ文書に対するユーザ入力と、
前記コマンド及び編集命令を取得するために取消コマンドを選択するための前記ユーザ入力と、
を備えることを特徴とするユーザインタフェース。
【請求項３７】
前記ユーザ入力は、表示された編集中のＸＭＬ文書の取消を制御する機能を有することを特徴とする請求項３６に記載のユーザインタフェース。
【請求項３８】
ユーザに、マークアップ言語文書を編集し、前記文書の編集を取り消す機能を有するプログラムを提供するためのプログラマインタフェースであって、
所定のコマンドのための複数の所定のテンプレートを有するストレージと、
ＤＯＭに対する変更を監視し、複数のマークアップ言語アプリケーションに反映させるためのテンプレートをプログラムが定義することを可能とするためにコードを表示するための表示と、
ユーザが、前記複数のテンプレートにアクセスし、取消操作を実装することを可能とするためのユーザインタフェースと、
を備えることを特徴とするプログラマインタフェース。
【請求項３９】
ＤＯＭにより表現されたＸＭＬ文書の取消を提供する方法をコンピュータに実現させるためのプログラムが記録された記録媒体であって、
前記ＤＯＭにおける検知された変更に対応する編集命令を生成する工程と、
コマンドにより前記編集命令を検知する工程と、
複数の検知された前記編集命令を収集する工程と、
収集された前記編集命令を登録する工程と、
を備えることを特徴とする記録媒体。
【請求項４０】
前記検知する工程は、前記ＤＯＭにおける複数の変更を検知する工程を含み、
前記生成する工程は、前記ＤＯＭにおけるそれぞれの変更に対する編集命令を生成する工程を含み、
前記検知する工程は、コマンドが複数の編集命令を検知する工程を含み、
前記登録する工程は、前記複数の編集命令を前記コマンドとともに登録する工程を含むことを特徴とする請求項３９に記載の記録媒体。
【請求項４１】
前記ＤＯＭに対する前記複数の変更の少なくとも２つは、異なるアプリケーションによることを特徴とする請求項４０に記載の記録媒体。
【請求項４２】
前記アプリケーションの少なくとも１つは、ＸＨＴＭＬ及びＳＶＧの少なくとも１つであることを特徴とする請求項４１に記載の記録媒体。
【請求項４３】
登録された前記命令の少なくとも１つを取得する工程と、
前記ＤＯＭの対応する部分を再構築するために前記取得した編集命令を適用する工程と、
を更に備えることを特徴とする請求項３９に記載の記録媒体。
【請求項４４】
前記取得する工程は、複数の登録された命令を取得する工程を含み、
前記適用する工程は、前記ＤＯＭの対応する部分を再構築するために前記複数の命令を適用する工程を含むことを特徴とする請求項４３に記載の記録媒体。
【請求項４５】
前記複数の登録された命令は、単一のコマンドに関することを特徴とする請求項４４に記載の記録媒体。
【請求項４６】
前記複数の登録された命令は、それらが生成された順序とは逆に適用されることを特徴とする請求項４４に記載の記録媒体。
【請求項４７】
前記アプリケーションの少なくとも１つはＸＨＴＭＬアプリケーションであり、
前記複数の登録された命令は、前記ＸＨＴＭＬアプリケーションにおける個々の文字に関することを特徴とする請求項４６に記載の記録媒体。
【請求項４８】
前記登録された編集命令の少なくとも１つにアクセスする工程と、
前記登録された編集命令を用いて編集の取消を指示する工程と、
を更に備えることを特徴とする請求項３９に記載の記録媒体。
【請求項４９】
ＤＯＭにより表現されたＸＭＬ文書の取消を提供する方法をコンピュータに実現させるためのプログラムが記録された記録媒体であって、
前記ＤＯＭにおける変更を検知する工程と、
前記ＤＯＭにおける検知された変更に対応する変更イベントを生成する工程と、
検知された前記変更イベントを収集し、対応する編集命令を生成する工程と、
生成された編集命令を登録する工程と、
を備えることを特徴とする記録媒体。
【請求項５０】
前記登録された編集命令の少なくとも１つにアクセスする工程と、
前記登録された編集命令を用いて編集の取消を指示する工程と、
を更に備えることを特徴とする請求項４９に記載の記録媒体。
【請求項１】
ＤＯＭにより表現されたＸＭＬ文書の取消を提供する方法であって、
前記ＤＯＭの変更を検知する工程と、
前記ＤＯＭにおける検知された変更に対応する編集命令を生成する工程と、
コマンドにより前記編集命令を検知する工程と、
複数の検知された前記編集命令を収集する工程と、
収集された前記編集命令を登録する工程と、
を備えることを特徴とする方法。
【請求項２】
前記検知する工程は、前記ＤＯＭにおける複数の変更を検知する工程を含み、
前記生成する工程は、前記ＤＯＭにおけるそれぞれの変更に対する編集命令を生成する工程を含み、
前記検知する工程は、コマンドが複数の編集命令を検知する工程を含み、
前記登録する工程は、前記複数の編集命令を前記コマンドとともに登録する工程を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記ＤＯＭに対する前記複数の変更の少なくとも２つは、異なるアプリケーションによることを特徴とする請求項２に記載の方法。
【請求項４】
前記アプリケーションの少なくとも１つは、ＸＨＴＭＬ及びＳＶＧの少なくとも１つであることを特徴とする請求項３に記載の方法。
【請求項５】
登録された前記命令の少なくとも１つを取得する工程と、
前記ＤＯＭの対応する部分を再構築するために前記取得した編集命令を適用する工程と、
を更に備えることを特徴とする請求項１に記載の方法。
【請求項６】
前記取得する工程は、複数の登録された命令を取得する工程を含み、
前記適用する工程は、前記ＤＯＭの対応する部分を再構築するために前記複数の命令を適用する工程を含むことを特徴とする請求項５に記載の方法。
【請求項７】
前記複数の登録された命令は、単一のコマンドに関することを特徴とする請求項６に記載の方法。
【請求項８】
前記複数の登録された命令は、複数のコマンドに関することを特徴とする請求項６に記載の方法。
【請求項９】
前記複数の登録された命令は、それらが生成された順序とは逆に適用されることを特徴とする請求項６に記載の方法。
【請求項１０】
前記アプリケーションの少なくとも１つはＸＨＴＭＬアプリケーションであり、
前記複数の登録された命令は、前記ＸＨＴＭＬアプリケーションにおける個々の文字に関することを特徴とする請求項４に記載の方法。
【請求項１１】
前記登録された編集命令の少なくとも１つにアクセスする工程と、
前記登録された編集命令を用いて編集の取消を指示する工程と、
を更に備えることを特徴とする請求項１に記載の方法。
【請求項１２】
ＤＯＭにより表現されたＸＭＬ文書の取消を提供する方法であって、
前記ＤＯＭの変更を検知する工程と、
前記ＤＯＭにおける検知された変更に対応する変更イベントを生成する工程と、
検知された前記変更イベントを収集し、対応する編集命令を生成する工程と、
生成された編集命令を登録する工程と、
を備えることを特徴とする方法。
【請求項１３】
前記登録された編集命令の少なくとも１つにアクセスする工程と、
前記登録された編集命令を用いて編集の取消を指示する工程と、
を更に備えることを特徴とする請求項１２に記載の方法。
【請求項１４】
ＤＯＭにより表現されたＸＭＬ文書の取消を提供する機能を有する文書管理システムであって、
前記ＤＯＭの変更を検知する手段と、
前記ＤＯＭにおける検知された変更に対応する編集命令を生成する手段と、
コマンドにより前記編集命令を検知する手段と、
複数の検知された前記編集命令を収集する手段と、
前記コマンド及び収集された前記編集命令を登録する手段と、
を備えることを特徴とする文書管理システム。
【請求項１５】
前記検知する手段は、前記ＤＯＭにおける複数の変更を検知する機能を含み、
前記生成する手段は、前記ＤＯＭにおけるそれぞれの変更に対する編集命令を生成する機能を含み、
前記検知する手段は、複数の編集命令を検知する機能を含むコマンドを有し、
前記登録する手段は、前記複数の編集命令を前記コマンドとともに登録する機能を含むことを特徴とする請求項１４に記載の文書管理システム。
【請求項１６】
前記ＤＯＭに対する前記複数の変更の少なくとも２つは、異なるアプリケーションによることを特徴とする請求項１５に記載の文書管理システム。
【請求項１７】
前記アプリケーションの少なくとも１つは、ＸＨＴＭＬ及びＳＶＧの少なくとも１つであることを特徴とする請求項１６に記載の文書管理システム。
【請求項１８】
登録された前記命令の少なくとも１つを取得する手段と、
前記ＤＯＭの対応する部分を再構築するために前記取得した編集命令を適用する手段と、
を更に備えることを特徴とする請求項１４に記載の文書管理システム。
【請求項１９】
前記取得する手段は、複数の登録された命令を取得する機能を含み、
前記適用する手段は、前記ＤＯＭの対応する部分を再構築するために前記複数の命令を適用する機能を含むことを特徴とする請求項１８に記載の文書管理システム。
【請求項２０】
前記複数の登録された命令は、単一のコマンドに関することを特徴とする請求項１９に記載の文書管理システム。
【請求項２１】
前記複数の登録された命令は、複数のコマンドに関することを特徴とする請求項１９に記載の文書管理システム。
【請求項２２】
前記複数の登録された命令は、それらが生成された順序とは逆に適用されることを特徴とする請求項１９に記載の文書管理システム。
【請求項２３】
前記アプリケーションの少なくとも１つはＸＨＴＭＬアプリケーションであり、
前記複数の登録された命令は、前記ＸＨＴＭＬアプリケーションにおける個々の文字に関することを特徴とする請求項１７に記載の文書管理システム。
【請求項２４】
ＤＯＭにより表現されたＸＭＬ文書の取消を提供する機能を有する文書管理システムであって、
前記ＤＯＭの変更を検知する手段と、
前記ＤＯＭにおける検知された変更に対応する変更イベントを生成する手段と、
前記変更イベントに基づいて編集命令を生成する手段と、
前記コマンド及び複数の検知された編集命令を登録する手段と、
を備えることを特徴とする文書管理システム。
【請求項２５】
ＤＯＭにより表現されたＸＭＬ文書の取消を提供する機能を有し、プロセッサと、メモリと、ディスプレーと、操作入力手段と、を有する装置であって、
前記ＤＯＭの変更を検知する手段と、
前記ＤＯＭにおける検知された変更に対応する編集命令を生成する手段と、
コマンドにより前記編集命令を検知する手段と、
前記コマンド及び検知された前記編集命令を登録する手段と、
を備えることを特徴とする装置。
【請求項２６】
前記検知する手段は、前記ＤＯＭにおける複数の変更を検知する機能を含み、
前記生成する手段は、前記ＤＯＭにおけるそれぞれの変更に対する編集命令を生成する機能を含み、
前記検知する手段は、複数の編集命令を検知する機能を含むコマンドを有し、
前記登録する手段は、前記複数の編集命令を前記コマンドとともに登録する機能を含むことを特徴とする請求項２５に記載の装置。
【請求項２７】
前記ＤＯＭに対する前記複数の変更の少なくとも２つは、異なるアプリケーションによることを特徴とする請求項２６に記載の装置。
【請求項２８】
前記アプリケーションの少なくとも１つは、ＸＨＴＭＬ及びＳＶＧの少なくとも１つであることを特徴とする請求項２７に記載の装置。
【請求項２９】
登録された前記命令の少なくとも１つを取得する手段と、
前記ＤＯＭの対応する部分を再構築するために前記取得した編集命令を適用する手段と、
を更に備えることを特徴とする請求項２５に記載の装置。
【請求項３０】
前記取得する手段は、複数の登録された命令を取得する機能を含み、
前記適用する手段は、前記ＤＯＭの対応する部分を再構築するために前記複数の命令を適用する機能を含むことを特徴とする請求項２９に記載の装置。
【請求項３１】
前記複数の登録された命令は、単一のコマンドに関することを特徴とする請求項３０に記載の装置。
【請求項３２】
前記複数の登録された命令は、複数のコマンドに関することを特徴とする請求項３０に記載の装置。
【請求項３３】
前記複数の登録された命令は、それらが生成された順序とは逆に適用されることを特徴とする請求項３０に記載の装置。
【請求項３４】
前記アプリケーションの少なくとも１つはＸＨＴＭＬアプリケーションであり、
前記複数の登録された命令は、前記ＸＨＴＭＬアプリケーションにおける個々の文字に関することを特徴とする請求項２８に記載の装置。
【請求項３５】
ＤＯＭにより表現されたＸＭＬ文書の取消を提供する機能を有し、プロセッサと、メモリと、ディスプレーと、操作入力手段と、を有する装置であって、
前記ＤＯＭの変更を検知する手段と、
前記ＤＯＭにおける検知された変更に対応する変更イベントを生成する手段と、
前記変更イベントに基づいて編集命令を生成する手段と、
前記コマンド及び複数の検知された編集命令を登録する手段と、
を備えることを特徴とする装置。
【請求項３６】
ＸＭＬ文書を編集し、前記文書の編集を取り消す機能を有するプログラムを提供するためのユーザインタフェースであって、
少なくとも１つの編集可能部分を備える編集可能なＸＭＬ文書の表示と、
ＤＯＭの変更を生成し、表示されたＸＭＬ文書を編集し、コマンド及び編集命令を格納させる、前記編集可能なＸＭＬ文書に対するユーザ入力と、
前記コマンド及び編集命令を取得するために取消コマンドを選択するための前記ユーザ入力と、
を備えることを特徴とするユーザインタフェース。
【請求項３７】
前記ユーザ入力は、表示された編集中のＸＭＬ文書の取消を制御する機能を有することを特徴とする請求項３６に記載のユーザインタフェース。
【請求項３８】
ユーザに、マークアップ言語文書を編集し、前記文書の編集を取り消す機能を有するプログラムを提供するためのプログラマインタフェースであって、
所定のコマンドのための複数の所定のテンプレートを有するストレージと、
ＤＯＭに対する変更を監視し、複数のマークアップ言語アプリケーションに反映させるためのテンプレートをプログラムが定義することを可能とするためにコードを表示するための表示と、
ユーザが、前記複数のテンプレートにアクセスし、取消操作を実装することを可能とするためのユーザインタフェースと、
を備えることを特徴とするプログラマインタフェース。
【請求項３９】
ＤＯＭにより表現されたＸＭＬ文書の取消を提供する方法をコンピュータに実現させるためのプログラムが記録された記録媒体であって、
前記ＤＯＭにおける検知された変更に対応する編集命令を生成する工程と、
コマンドにより前記編集命令を検知する工程と、
複数の検知された前記編集命令を収集する工程と、
収集された前記編集命令を登録する工程と、
を備えることを特徴とする記録媒体。
【請求項４０】
前記検知する工程は、前記ＤＯＭにおける複数の変更を検知する工程を含み、
前記生成する工程は、前記ＤＯＭにおけるそれぞれの変更に対する編集命令を生成する工程を含み、
前記検知する工程は、コマンドが複数の編集命令を検知する工程を含み、
前記登録する工程は、前記複数の編集命令を前記コマンドとともに登録する工程を含むことを特徴とする請求項３９に記載の記録媒体。
【請求項４１】
前記ＤＯＭに対する前記複数の変更の少なくとも２つは、異なるアプリケーションによることを特徴とする請求項４０に記載の記録媒体。
【請求項４２】
前記アプリケーションの少なくとも１つは、ＸＨＴＭＬ及びＳＶＧの少なくとも１つであることを特徴とする請求項４１に記載の記録媒体。
【請求項４３】
登録された前記命令の少なくとも１つを取得する工程と、
前記ＤＯＭの対応する部分を再構築するために前記取得した編集命令を適用する工程と、
を更に備えることを特徴とする請求項３９に記載の記録媒体。
【請求項４４】
前記取得する工程は、複数の登録された命令を取得する工程を含み、
前記適用する工程は、前記ＤＯＭの対応する部分を再構築するために前記複数の命令を適用する工程を含むことを特徴とする請求項４３に記載の記録媒体。
【請求項４５】
前記複数の登録された命令は、単一のコマンドに関することを特徴とする請求項４４に記載の記録媒体。
【請求項４６】
前記複数の登録された命令は、それらが生成された順序とは逆に適用されることを特徴とする請求項４４に記載の記録媒体。
【請求項４７】
前記アプリケーションの少なくとも１つはＸＨＴＭＬアプリケーションであり、
前記複数の登録された命令は、前記ＸＨＴＭＬアプリケーションにおける個々の文字に関することを特徴とする請求項４６に記載の記録媒体。
【請求項４８】
前記登録された編集命令の少なくとも１つにアクセスする工程と、
前記登録された編集命令を用いて編集の取消を指示する工程と、
を更に備えることを特徴とする請求項３９に記載の記録媒体。
【請求項４９】
ＤＯＭにより表現されたＸＭＬ文書の取消を提供する方法をコンピュータに実現させるためのプログラムが記録された記録媒体であって、
前記ＤＯＭにおける変更を検知する工程と、
前記ＤＯＭにおける検知された変更に対応する変更イベントを生成する工程と、
検知された前記変更イベントを収集し、対応する編集命令を生成する工程と、
生成された編集命令を登録する工程と、
を備えることを特徴とする記録媒体。
【請求項５０】
前記登録された編集命令の少なくとも１つにアクセスする工程と、
前記登録された編集命令を用いて編集の取消を指示する工程と、
を更に備えることを特徴とする請求項４９に記載の記録媒体。
【図１（ａ）】
【図１（ｂ）】
【図１（ｃ）】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７（ａ）】
【図１７（ｂ）】
【図１８】
【図１９（ａ）】
【図１９（ｂ）】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図１（ｂ）】
【図１（ｃ）】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７（ａ）】
【図１７（ｂ）】
【図１８】
【図１９（ａ）】
【図１９（ｂ）】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【公表番号】特表２００８−５０９４７７（Ｐ２００８−５０９４７７Ａ）
【公表日】平成２０年３月２７日（２００８．３．２７）
【国際特許分類】
【出願番号】特願２００７−５２４９３６（Ｐ２００７−５２４９３６）
【出願日】平成１７年８月２日（２００５．８．２）
【国際出願番号】ＰＣＴ／ＵＳ２００５／０２７５２８
【国際公開番号】ＷＯ２００６／０４１５５４
【国際公開日】平成１８年４月２０日（２００６．４．２０）
【出願人】（３９００２４３５０）株式会社ジャストシステム (123)
【Ｆターム（参考）】
【公表日】平成２０年３月２７日（２００８．３．２７）
【国際特許分類】
【出願日】平成１７年８月２日（２００５．８．２）
【国際出願番号】ＰＣＴ／ＵＳ２００５／０２７５２８
【国際公開番号】ＷＯ２００６／０４１５５４
【国際公開日】平成１８年４月２０日（２００６．４．２０）
【出願人】（３９００２４３５０）株式会社ジャストシステム (123)
【Ｆターム（参考）】
[ Back to top ]