WO2007105364A1

WO2007105364A1 - 文書処理装置及び文書処理方法

Info

Publication number: WO2007105364A1
Application number: PCT/JP2007/000175
Authority: WO
Inventors: Koji Sasaki
Original assignee: Justsystems Corporation
Priority date: 2006-03-06
Filing date: 2007-03-06
Publication date: 2007-09-20
Also published as: JPWO2007105364A1

Abstract

　画像にアノーテーションをつける。　文書処理装置１００は、文書処理装置２０と、アノーテーションユニット７０と、取得部７８を備える。アノーテーションユニット７０は、アノーテーションを付す画像の領域の設定を受け付ける領域設定受付部７１と、領域に付すアノーテーションの設定を受け付けるアノーテーション設定受付部７２と、設定されたアノーテーションを記録するアノーテーション記録部７３と、設定されたアノーテーションを表示するアノーテーション表示部７４と、設定されたアノーテーションを検索する検索部７５を含む。

Description

明細書

文書処理装置及び文書処理方法

技術分野

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

背景技術

[0002] X M Lは、ネットワークなどを介して他者とデータを共有するのに適した形式として注目されており、 X M L文書を作成、表示、編集するためのアブリケーシヨンが開発されている（たとえば、特許文献 1参照）。 X M L文書は、文書型定義などにより定義されたポキヤブラリ（タグセット）に基づいて作成されている。

特許文献 1 ：特開 2 0 0 1 _ 2 9 0 8 0 4号公報

発明の開示

発明が解決しょうとする課題

[0003] ポキヤブラリは、任意に定義することが許されており、理論上、無限に多くのポキャブラリが存在しうる。これらのポキヤブラリの全てに対応して専用の表示■編集環境を提供するのは現実的ではない。従来、専用の編集環境が用意されていないポキヤブラリにより記述された文書を編集する場合、テキストデータにより構成された文書のソースを直接テキストエディタなどで編集していた。

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

課題を解決するための手段

[0005] 本発明のある態様は、文書処理装置に関する。この文書処理装置は、画像の一部の領域に対してァノーテーションを付けるときに、前記領域の指定を受け付ける領域設定受付部と、前記領域に対するァノーテーシヨンの設定を受け付けるァノーテーシヨン設定受付部と、前記領域を特定するための情報と、受け付けたァノーテーシヨンの設定とを対応づけてファイルに記録するァノーテーシヨン記録部と、を備えることを特徴とする。

[0006] 前記ァノーテーシヨン設定受付部は、複数の領域に対して共通のァノーテーシヨンの設定を受付可能としてもよい。前記ァノーテーシヨン設定受付部は、前記ァノーテーシヨンの種別を受け付けてもよく、前記ァノーテーション記録部は、前記ァノーテーシヨンの種別を特定するための情報を更に前記ファイルに記録してもよい。前記ァノーテーシヨン記録部は、マークアップ言語を用いて前記ァノーテーシヨンを前記ファイルに記録してもよい。前記ァノーテーシヨン記録部は、前記ァノ亍ーシヨンを記述するためのタグセットを用いて前記ァノーテーシヨンを前記ファイルに記録してもよい。文書処理装置は、前記ァノーテーシヨンを記述するためのタグセッ卜の処理方法を記述した定義ファイルを取得する定義ファイル取得部を更に備えてもよく、前記ァノーテーシヨン記録部は、前記定義ファイルに記述されたコマンドにしたがって、前記ファイルに前記ァノーテーシヨンを記述するための要素を記録してもよい。

[0007] 本発明の別の態様は、文書処理方法に関する。この文書処理方法は、画像の一部の領域に対してァノーテーションを付けるときに、前記領域の指定を受け付けるステップと、前記領域に対するァノーテーシヨンの設定を受け付けるステップと、前記領域を特定するための情報と、受け付けたァノーテ一シヨンの設定とを対応づけてファイルに記録するステップと、を備えることを特徴とする。

[0008] 本発明の更に別の態様は、文書処理装置に関する。この文書処理装置は、画像を取得する画像取得部と、前記画像の一部の領域に対して付されたァノ一亍ーシヨンが記録されたファイルを取得するァノーテーシヨン取得部と、前記画像を表示するとともに、前記領域と前記ァノーテーシヨンとの対応を識別可能な形式で前記ァノーテーシヨンを表示するァノーテーシヨン表示部と、を備えることを特徴とする。 [0009] 文書処理装置は、前記ァノーテーシヨンの編集を受け付け、編集された前記ァノーテーシヨンを前記ファイルに記録するァノーテーシヨン記録部を更に備えてもよい。前記ァノーテーシヨン表示部は、ポインティングデバイスのポインタが前記画像の前記領域に入ったときに、その領域に対して付されたァノーテーシヨンを識別可能に表示してもよい。前記ァノーテーシヨン表示部は、前記画像に対して付されたァノーテーシヨンを一覧表示する一覧表示画面を更に表示してもよく、前記一覧表示画面において、あるァノーテ一シヨンが選択されたときに、そのァノーテーシヨンに対応する領域を識別可能に前記画像上に表示してもよい。前記ァノーテーシヨン表示部は、前記ァノーテーシヨンの種別に応じて、前記ァノーテーシヨンをグループ分けして表示してもよい。前記ファイルは、前記ァノ亍ーシヨンを記述するためのタグセットを用いて前記ァノーテーシヨンを記録していてもよい。文書処理装置は、前記ァノーテーシヨンを記述するためのタグセッ卜の処理方法を記述した定義ファイルを取得する定義ファイル取得部を更に備えてもよく、前記ァノーテーシヨン表示部は、前記定義ファイルに記述されたテンプレー卜にしたがって、前記ファイルに記述された前記ァノーテーシヨンを表示してもよい。

[0010] 本発明の更に別の態様は、文書処理方法に関する。この文書処理方法は、画像を取得するステップと、前記画像の一部の領域に対して付されたァノーテーシヨンが記録されたファイルを取得するステップと、前記画像を表示するとともに、前記領域と前記ァノーテーシヨンとの対応を識別可能な形式で前記ァノーテーシヨンを表示するステップと、を備えることを特徴とする。

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

[001 2] 本発明によれば、利便性の高いユーザインタフェイスを提供することがでさる。

図面の簡単な説明 [図 1 ]前提技術に係る文書処理装置の構成を示す図である。

[図 2]処理対象となる X M L文書の例を示す図である。

[図 3]図 2に示した X M L文書を H T M Lで記述された表にマツビングする例を示す図である。

[図 4 (a) ]図 2に示した X M L文書を図 3に示した表にマツビングするための定義ファイルの例を示す図である。

[図 4 (b) ]図 2に示した X M L文書を図 3に示した表にマツビングするための定義ファイルの例を示す図である。

[図 5]図 2に示した成績管理ボキャプラリで記述された X M L文書を、図 3に示した対応により H T M Lにマツビングして表示した画面の例を示す図である。

[図 6]ユーザが定義ファィルを生成するために、定義フアイル生成部がユーザに提示するグラフィカルユーザインターフェースの例を示す図である。

[図 7]定義ファイル生成部により生成された画面レイァゥ卜の他の例を示す図である。

[図 8]文書処理装置による X M L文書の編集画面の一例を示す図である。

[図 9]文書処理装置により編集される X M L文書の他の例を示す図である。

[図 10]図 9に示した文書を表示した画面の例を示す図である。

[図 1 1 (a) ]文書処理システムの基本構成を示す図である。

[図 1 1 (b) ]文書処理システム全体のブロック図を示す図である。

[図 1 1 (G) ]文書処理システム全体のブロック図を示す図である。

[図 12]文書管理部の詳細を示す図である。

[図 13]ボキヤブラリコネクションサブシステムの詳細を示す図である。

[図 14]プログラム起動部と他の構成の関係の詳細を示す図である。

[図 15]プログラム起動部によりロードされたアプリケーションサービスの構造の詳細を示す図である。

[図 16]コアコンポーネン卜の詳細を示す図である。

[図 17]文書管理部の詳細を示す図である。 [図 18]アンドウフレームワークとアンドウコマンドの詳細を示す図である。

[図 19]文書処理システムにおいて文書がロードされる様子を示す図である。

[図 20]文書とその表現の例を示す図である。

[図 21 ]モデルとコントローラの関係を示す図である。

[図 22]プラグインサブシステム、ボキヤブラリコネクション、及びコネクタの詳細を示す図である。

[図 23] V C Dファイルの例を示す図である。

[図 24]文書処理システムにおいて複合文書を口ードする手順を示す図である

[図 25]文書処理システムにおいて複合文書を口ードする手順を示す図である

[図 26]文書処理システムにおいて複合文書を口ードする手順を示す図である

[図 27]文書処理システムにおいて複合文書を口ードする手順を示す図である

[図 28]文書処理システムにおいて複合文書を口ードする手順を示す図である

[図 29]コマンドの流れを示す図である。

[図 30]実施の形態に係る文書処理装置の構成を示す図である。

[図 31 ]ァノーテーシヨンを記録した文書ファイルの例を示す図である。

[図 32]ァノーテーシヨン表示部により表示された画面の例を示す図である。

[図 33]領域設定受付部が領域の設定を受け付ける画面の例を示す図である。

[図 34]ァノーテーション設定受付部がァノーテーションの設定を受け付ける画面の例を示す図である。

[図 35]ァノーテーション表示部が設定されたァノーテーションを表示する画面の例を示す図である。

[図 36]ァノーテーシヨンが設定された領域がフォーカスされたときの画面の例を示す図である。符号の説明

[0014] 20 文書処理装置、 22 主制御ユニット、 24 編集ユニット、 30

DOMユニット、 32 DOM提供部、 34 DOM生成部、 36 出力部、 40 CSSユニット、 42 CSS解析部、 44 CSS提供部、 4 6 レンダリング部、 50 HTMLユニット、 52， 62 制御部、 54 ， 64 編集部、 56， 66 表示部、 60 SVGユニット、 70 ァノ一テーシヨンユニット、 7 1 領域設定受付部、 72 ァノーテーシヨン設定受付部、 73 ァノーテーシヨン記録部、 74 ァノーテーシヨン表示部、 75 検索部、 78 取得部、 80 VCユニット、 82 マッピング部、 84 定義ファイル取得部、 86 定義ファイル生成部、 1 00 文書処発明を実施するための最良の形態

[0015] (前提技術）

図 1は、前提技術に係る文書処理装置 20の構成を示す。文書処理装置 2 0は、文書内のデータが階層構造を有する複数の構成要素に分類された構造化文書を処理するが、本前提技術では構造化文書の一例として XM L文書を処理する例について説明する。文書処理装置 20は、主制御ユニット 22、編集ユニット 24、 DOMユニット 30、 CSSユニット 40、 HTMLュニット 50、 SVGユニット 60、及び変換部の一例である VCユニット 8 0を備える。これらの構成は、ハードウェアコンポーネントでいえば、任意のコンピュータの CP U、メモリ、メモリにロードされたプログラムなどによって実現される力ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウェアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。

[0016] 主制御ユニット 22は、プラグインのロードや、コマンド実行のフレームワークを提供する。編集ユニット 24は、 XM L文書を編集するためのフレームワークを提供する。文書処理装置 20における文書の表示及び編集機能は、プラグインにより実現されており、文書の種別に応じて必要なプラグィンが主制御ュニット 22又は編集ュニット 24によりロードされる。主制御ユニット 22又は編集ュニット 24は、処理対象となる XM L文書の名前空間を参照して、 XM L文書がいずれのボキャプラリにより記述されているかを判別し、そのボキヤブラリに対応した表示又は編集用のプラグインをロードして表示や編集を実行させる。例えば、文書処理装置 20には、 HTML 文書の表示及び編集を行う H TM Lュニット 50、 SVG文書の表示及び編集を行う SVGユニット 60など、ボキヤブラリ（タグセット）ごとに表示系及び編集系がプラグインとして実装されており、 HTML文書を編集するときは HTMLュニット 50力 S VG文書を編集するときは S VGュニット 60力それぞれロードされる。後述するように、 1~1丁1\11_と5 0の双方の構成要素を含む複合文書が処理対象となっている場合は、 HTMLュニット 50と S VGュニット 60の双方がロードされる。

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

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

[0019] DOMユニット 30は、 DOM提供部 32、 D OM生成部 34、及び出力部 36を含み、 XM L文書をデータとして扱うときのアクセス方法を提供するために定められた文書オブジェクトモデル（Document Object Model ： DO M) に準拠した機能を実現する。 001\1提供部32は、編集ユニット 24に定義されているィンタフェースを満たす DOMの実装である。 DOM生成部 34は、 XML文書から DOMツリーを生成する。後述するように、処理対象となる XML文書が、 VCュニット 80により他のボキヤブラリにマツピングされる場合は、マッピング元の X M L文書に対応するソースツリーと、マツビング先の XM L文書に対応するデスティネーションッリーが生成される。出力部 36は、例えば編集終了時に、 DOMツリーを XM L文書として出力する。

[0020] CSSユニット 40は、 CSS解析部 42、 C S S提供部 44、及びレンダリング部 46を含み、 CSSに準拠した表示機能を提供する。 CSS解析部 42は、 CSSの構文を解析するパーザの機能を有する。 CSS提供部 4 4は、 CS Sオブジェクトの実装であり、 DOMツリーに対して CS Sの力スケード処理を行う。レンダリング部 46は、 CS Sのレンダリングェンジンであり、 CSSを用いてレイァゥ卜される H TM Lなどのポキヤブラリで記述された文書の表示に用いられる。

[0021] HTMLユニット 50は、 H T M Lにより記述された文書を表示又は編集する。 SVGユニット 60は、 SVGにより記述された文書を表示又は編集する。これらの表示編集系は、プラグインの形で実現されており、それぞれ、文書を表示する表示部（Canvas) 56、 66、編集指示を含むイベントを送受信する制御部（Editlet) 52、 62、編集コマンドを受けて D OMに対して編集を行う編集部（Zone) 54、 64を備える。制御部 52又は 62 が外部から DOMツリーの編集コマンドを受け付けると、編集部 54又は 6 4が DOMツリーを変更し、表示部 56又は 66が表示を更新する。これらは、 MVC (Model -View-Control ler) と呼ばれるフレームワークに類似する構成をとつており、概ね、表示部 56及び 66が「View」に、制御部 52及び 62力《 Γ Control lerj に、編集部 54及び 64と DOMの実体が「Model」に、それぞれ対応する。本前提技術の文書処理装置 20では、 XML文書をッリ一表示形式で編集するだけでなく、それぞれのボキャプラリに応じた編集を可能とする。例えば、 HTMLユニット 50は、 HTML文書をワードプロセッサに類似した方式で編集するためのユーザインターフェースを提供し、 SVGユニット 60は、 SVG文書を画像描画ツールに類似した方式で編集するためのユーザィンターフェースを提供する。

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

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

[0024] 文書処理装置 2 0により文書を表示又は編集する動作について説明する。

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

[0025] 図 2は、処理対象となる X M L文書の例を示す。この X M L文書は、生徒の成績データを管理するために用いられる。 X M L文書のトップノードである構成要素「成績」は、配下に、生徒ごとに設けられた構成要素「生徒」を複数有する。構成要素「生徒」は、属性値「名前」と、子要素「国語」、「数学」、「理科」、「社会」を有する。属性値「名前」は、生徒の名前を格納する。構成要素「国語」、「数学」、「理科」、「社会」は、それぞれ、国語、数学、理科、社会の成績を格納する。例えば、名前が「A」である生徒の国語の成績は「9 0」、数学の成績は「5 0」、理科の成績は「7 5」、社会の成績は「6 0」である。以下、この文書で使用されているポキヤブラリ（タグセット）を、「成績管理ポキヤブラリ」と呼ぶ。

[0026] 本前提技術の文書処理装置 2 0は、成績管理ポキャプラリの表示編集に対応したプラグインを有しないので、この文書をソース表示、ツリー表示以外の方法で表示するためには、前述した V C機能が用いられる。すなわち、成績管理ボキヤブラリを、プラグインが用意された別のボキヤブラリ、例えば、 H T M Lや S V Gなどにマツビングするための定義ファイルを用意する必要がある。ユーザ自身が定義ファイルを作成するためのユーザインターフエースについては後述することにして、ここでは、既に定義ファイルが用意されているとして説明を進める。

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

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

[0029] 図 5は、図 2に示した成績管理ポキヤブラリで記述された X ML文書を、図 3に示した対応により H TM Lにマツビングして表示した画面の例を示す。表 90の各行には、左から、各生徒の名前、国語の成績、数学の成績、理科の成績、社会の成績、及び平均点が表示されている。ユーザは、この画面上で、 XML文書を編集することができる。たとえば、第 2行第 3列の値を「70」に変更すると、このノードに対応するソースツリーの要素値、すなわち、生徒「B」の数学の成績が「70」に変更される。このとき、 VCュニット 80は、デスティネーションツリーをソースツリーに追従させるベく、デスティネーションツリーの該当箇所を変更し、 HTMLユニット 50が、変更されたデスティネーションツリーに基づいて表示を更新する。したがつて、画面上の表においても、生徒「B」の数学の成績が「70」に変更され、更に、平均点が「55」に変更される。

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

図 6は、ユーザが定義ファイルを生成するために、定義ファイル生成部 8 6がユーザに提示するグラフィカルユーザィンタフヱ一スの例を示す。画面左側の領域 9 1には、マッピング元の X M L文書がツリー表示されている。画面右側の領域 9 2には、マッピング先の X M L文書の画面レイァゥ卜が示されている。この画面レイアウトは、 H T M Lユニット 5 0により編集可能となっており、ユーザは、画面右側の領域 9 2において、文書を表示するための画面レイアウトを作成する。そして、例えば、マウスなどのポインティングデバイスにより、画面左側の領域 9 1に表示されたマッピング元の X M L文書のノードを、画面右側の領域 9 2に表示された H T M Lによる画面レィァゥト中へドラッグ &ドロップ操作を行うことにより、マツビング元のノードと、マッピング先のノードとのコネクションが指定される。例えば、要素「生徒」の子要素である「数学」を、 H T M L画面の表 9 0の第 1行第 3 列にドロップすると、「数学」ノードと、 3列目の「T D」ノードの間にコネクシヨンが張られる。各ノードには、編集の可否が指定できるようになつている。また、表示画面中には、演算式を埋め込むこともできる。画面の編集が終わると、定義ファイル生成部 8 6は、画面レイアウトとノード間のコネクシヨンを記述した定義ファイルを生成する。 [0032] X H T M L , M a t h M L、 S V Gなどの主要なポキヤブラリに対応したビューヮゃエディタは既に開発されているが、図 2に示した文書のようなォリジナルなポキャブラリで記述された文書に対応したビューヮゃエディタを開発するのは現実的でない。しかし、上記のように、他のボキヤブラリにマッビングするための定義ファイルを作成すれば、ビューヮゃエディタを開発しなくても、 V C機能を利用して、オリジナルなボキヤブラリで記述された文書を表示■編集することができる。

[0033] 図 7は、定義ファイル生成部 8 6により生成された画面レイアウトの他の例を示す。図 7の例では、成績管理ボキャプラリで記述された X M L文書を表示するための画面に、表 9 0と、円グラフ 9 3が作成されている。この円グラフ 9 3は、 S V Gにより記述される。後述するように、本前提技術の文書処理装置 2 0は、一つの X M L文書内に複数のボキャプラリを含む複合文書を処理することができるので、この例のように、 H T M Lで記述された表 9 0と、 S V Gで記述された円グラフ 9 3とを、一つの画面上に表示することができる。

[0034] 図 8は、文書処理装置 2 0による X M L文書の編集画面の一例を示す。図 8の例では、一つの画面が複数に分割されており、それぞれの領域において、処理対象となる X M L文書を異なる複数の表示形式により表示している。領域 9 4には、文書のソースが表示されており、領域 9 5には、文書のッリ一構造が表示されており、領域 9 6には、図 5に示した H T M Lにより記述された表が表示されている。これらのいずれの画面上においても、文書の編集が可能であり、いずれかの画面上でユーザが編集を行うと、ソースツリーが変更され、それぞれの画面の表示を担当するプラグインが、ソースツリーの変更を反映すべく画面を更新する。具体的には、ソースツリーの変更を通知するミュー亍ーシヨンィベン卜のリスナーとして、それぞれの編集画面の表示を担当するプラグィンの表示部を登録しておき、いずれかのプラグィン又は V Cュニット 8 0によりソースツリーが変更されたときに、編集画面を表示中の全ての表示部が、発行されたミュー亍ーシヨンィベントを受け取つて画面を更新する。このとき、プラグインが V C機能により表示を行っている場合は、 V Cュニット 8 0がソースツリーの変更に追従してデスティネーシヨンツリーを変更した後、変更されたデスティネーションツリーを参照してプラグィンの表示部が画面を更新する。

[0035] 例えば、ソース表示及びツリー表示を、専用のプラグインにより実現している場合は、ソース表示用プラグインとツリー表示用プラグインは、デス亍イネーシヨンツリーを用いず、直接ソースツリーを参照して表示を行う。この場合、いずれかの画面において編集が行われると、ソース表示用プラグィンとツリー表示用プラグインは、変更されたソースツリーを参照して画面を更新し、領域 9 6の画面を担当している H T M Lユニット 5 0は、ソースッリ一の変更に追従して変更されたデスティネーシヨンッリーを参照して画面を更新する。

[0036] ソース表示及びッリ一表示は、 V C機能を利用して実現することもできる。すなわち、ソース、ツリー構造を H T M Lによりレイアウトし、その H T M Lに X M L文書をマツビングして、 H T M Lュニット 5 0により表示してもよい。この場合、ソース形式、ツリー形式、表形式の 3つのデスティネーシヨンツリーが生成されることになる。いずれかの画面において編集が行われると、 V Cユニット 8 0は、ソースツリーを変更した後、ソース形式、ッリー形式、表形式の 3つのデスティネーションツリーをそれぞれ変更し、 H T M Lユニット 5 0は、それらのデスティネーションツリーを参照して、 3 つの画面を更新する。

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

[0038] 図 9は、文書処理装置 20により編集される X ML文書の他の例を示す。

図 9に示した XM L文書では、 SVG文書の「foreignObject」タグの中に X H TM L文書が埋め込まれており、さらに、 X H TM L文書の中に M a t h MLで記述された数式が入っている。このような場合、編集ユニット 24が、名前空間を参照して、適切な表示系に描画作業を振り分ける。図 9の例では、編集ユニット 24は、まず、 SVGユニット 60に四角形を描画させ、つづいて、 H TM Lユニット 50に X H TM L文書を描画させる。さらに、図示しない Ma t h MLュニッ卜に、数式を描画させる。こうして、複数のボキヤブラリを包含する複合文書が適切に表示される。表示結果を図 1 0に示す。

[0039] 文書編集中、カーソル（キャリッジ）の位置に応じて、表示されるメニュ一を切り替えてもよい。すなわち、カーソルが、 SVG文書が表示された領域内に存在するときは、 SVGユニット 60が提供するメニュー、又は SV G文書をマツビングするための定義ファイルに定義されたコマンドを表示し、カーソルが、 X H TM L文書が表示された領域内に存在するときは、 HT M Lュニット 50が提供するメニュー、又は X H TM L文書をマツビングするための定義ファイルに定義されたコマンドを表示する。これにより、編集位置に応じて適切なユーザインターフェースを提供することができる。

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

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

[0042] あるボキヤブラリにより記述された文書内に、他のボキヤブラリのタグを用いてもよい。この XM L文書は、妥当（val id) ではないが、整形式（wel l -formed) であれば、有効な XM L文書として処理可能である。この場合、揷入された他のボキャプラリのタグは、定義ファイルによりマツビングされてもよい。例えば、 X H TM L文書中に、「重要」、「最重要」などのタグを使用し、これらのタグで囲まれた部分を強調表示してもよいし、重要度の順にソートして表示してもよい。

[0043] 図 1 0に示した編集画面において、ユーザにより文書が編集されると、編集された部分を担当するプラグィン又は V Cュニット 80がソースッリーを変更する。ソースツリーには、ノードごとにミューテーシヨンイベントのリスナーを登録できるようになつており、通常は、各ノードが属するポキヤブラリに対応したプラグインの表示部又は VCュニット 80がリスナーとして登録される。 00!\1提供部32は、ソースツリーが変更されると、変更されたノードから上位の階層へたどって、登録されたリスナーがあれば、そのリスナ一へミューテーシヨンイベントを発行する。例えば、図 9に示した文書において、 < h t m I >ノードの下位のノードが変更された場合、 < h t m I >ノードにリスナーとして登録された H TM Lュニット 50にミュー亍ーシヨンィベン卜が通知されるとともに、その上位の < s V g>ノードにリスナ一として登録された SVGュニット 60にもミュー亍ーシヨンィベン卜が通知される。このとき、 H TM Lユニット 50は、変更されたソースツリーを参照して表示を更新する。 SVGユニット 60は、自身のボキヤブラリに属するノードが変更されていないので、ミュー亍ーシヨンィベントを無視してもよい。

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

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

[0046] A. 概要

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

[0047] マークアップ言語により記述された文書は、通常、ブラウザや他のアプリケーシヨンの中では、ツリーデータ構造の形で表現される。この構造は、文書を構文解析した結果のツリーに相当する。 DOM (Document Object Model ) は、文書を表現し、操作するために使用される、よく知られたツリーべ一スのデータ構造モデルである。 DOMは、 H TM Lや XM L文書などを含む文書を表現するための標準的なオブジェク卜のセットを提供する。 DOMは、文書内のコンポーネントを表現するォブジェク卜がどのようにつながっているかという標準モデルと、それらのオブジェク卜にアクセスしたり操作したりするための標準インタフェイスという、 2つの基本的なコンポーネントを含む。

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

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

[0050] HTMLは、文書を作成するために一般に用いられる言語であるが、フォ一マツト及びレイァゥト用の言語であり、データ記述のための言語ではない。 H TM Lドキュメントを表現する DOMツリーのノードは、 HTMLのフォーマツティングタグとして予め定義されたエレメントであって、通常、 H TMLは、データの詳述や、データのタギングノラべリングのための機能を提供しないので、 HTMLドキュメント中のデータに対するクエリを定式化することは多くの場合困難である。

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

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

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

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

[0055] ここで説明されるシステムの構成のうちのいくつかは、 MVC (Model -Vie w- Control I er) と呼ばれる、よ <矢卩られた GU I (Graphical User Interfac e) パラダイムを用いて説明される。 MVCパラダイムは、アプリケーション又はアプリケーションのインタフェイスの一部を、 3つの部分、すなわち、モデル、ビュー、コントローラに分割する。 MVCは、元は、 GU Iの世界に、従来の入力、処理、出力の役割を割り当てるために開発された。

[入力] → [処理] → [出力]

[コントローラ] → [モデル] → [ビュー]

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

[0057] B. 文書処理システムの全体構成

文書処理システムの実施例は、図 1 1 _29に関連して明らかにされる。 [0058] 図 1 1 ( a ) は、後述するタイプの文書処理システムの基礎として機能する要素の従来の構成例を示す。構成 1 0は、通信経路 1 3によりメモリ 1 2 に接続された C P U又はマイクロプロセッサ 1 1などの形式のプロセッサを含む。メモリ 1 2は、現在又は将来に利用可能な任意の R O M及び又は R A Mの形式であってもよい。通信経路 1 3は、典型的にはバスとして設けられる。マウス、キーボード、音声認識システムなどのユーザ入力装置 1 4及び表示装置 1 5 (又は他のユーザインタフェイス）に対する入出力インタフェイス 1 6も、プロセッサ 1 1 とメモリ 1 2の通信のためのバスに接続される。この構成は、スタンドアロンであってもよいし、複数の端末及び 1以上のサーバが接続されてネットワーク化された形式であってもよいし、既知のいかなる方式により構成されてもよい。本発明は、これらのコンポーネントの配置、集中又は分散されたアーキテクチャー、あるいは様々なコンポーネン卜の通信方法により制限されない。

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

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

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

[0062] 1 . 実行環境

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

[0063] Program l nvoker 1 0 3には、プラグインサブシステム 1 0 4、コマンドサブシステム 1 0 5、及び Resource (リソース）モジュール 1 0 9などのいくつかのコンポーネントがアタッチされている。これらの構成については、以下に詳述する。

[0064] a ) プラグインサブシステム

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

[0065] プラグインサブシステム 1 04は、 ServiceBroker (サービスブローカ：サ一ビス仲介部） 1 041を含む。 ServiceBroker 1 041は、文書処理シス亍ムに加えられるプラグィンを管理することにより、文書処理システムに加えられるサービスを仲介する。

[0066] 所望の機能性を実現する個々の機能は、 Service (サービス） 1 042の形でシステムに追加される。利用可能な Service 1 042のタイプは、 Applicat ion (アプリケーション）サービス、 ZoneFactory (ゾーンファクトリ：ゾーン生成部） Service、 Editlet (エディツトレット：編集部） Service、 Co國 an dFactory (コマンドファクトリ：コマンド生成部） Service、 ConnectXPath ( コネクト X P a t h ： X P a t h管理部） Service CSSComputat i on (CSS コンビユーテーシヨン： CSS計算部） Serviceなどを含むが、これらに限定されない。これらの Service, 及びシステムの他の構成とそれらとの関係は、文書処理システムについてのよりよい理解のために、以下に詳述される。

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

[0068] b) コマンドサブシステム

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

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

[0070] コマンドサブシステム 1 05のキーとなるコンポーネントは、選択的にコマンドを与え、実行するように作用する Co國 andlnvoker (コマンドインボー力：コマンド起動部） 1 05 1である。図 1 1 (b) には、 1つの Command In vokerのみが示されているが、 1以上の Co國 andlnvokerが使用されてもよく、 1以上のコマンドが同時に実行されてもよい。 Co國 andlnvoker 1 05 1は、コマンドを実行するために必要な機能及びクラスを保持する。動作において、実行されるべき Co國 and (コマンド：命令） 1 052は、 Queue (キュー） 1 053に積まれる。 Go國 andlnvokerは、連続的に実行するコマンドスレツドを生成する。 Gommandlnvoker内で既に実行中の Command力《なければ、 Comman dlnvoker 1 051により実行されるように意図された Co國 and 1 052が実行される。 Commandlnvokerが既にコマンドを実行している場合、新しい Command は、 Queuel 053の最後に積まれる。しかしながら、それぞれの Go國 and Inv oker 1 05 1では、一度に 1つの Commandのみが実行される。指定された Gomm andの実行に失敗した場合、 Go國 andlnvoker 1 05 1は例外処理を実行する。 [0071] CommandlnvokeM 05 1により実行される Commandの型は、 Undoab I eComman d (取消可能コマンド） 1 054、 AsynchronousCommand (非同期コマンド） 1 055、及び VCCo國 and (VCコマンド） 1 056を含むが、これらに限定されない。 UndoableCo國 and 1 054は、ユーザが望めば、その Commandの結果を取り消すことが可能な Commandである。 UndoableCo國 andの例として、切り取り、コピー、テキストの挿入、などがある。動作において、ユーザが文書の一部を選択し、その部分に切り取りコマンドを適用するとき、 UndoableC 0國 andを用いることにより、切り取られた部分は、必要であれば、「切り取られていない」ようにすることができる。

[0072] VCCommand 1 056は、ボキヤブラリコネクション記述子（Vocabulary Con nection Descriptor ： V C D) スクリプトファイルに格納される。これらは、プログラマにより定義されうるユーザ指定の Commandである。 Commandは、例えば、 XM Lフラグメントを追加したり、 XM Lフラグメントを削除したり、属性を設定したりするための、より抽象的な Co國 andの組合せであってもよい。これらの Co國 andは、特に、文書の編集に焦点を合わせている。

[0073] AsynchronousCo國 and 1 055は、文書のロードゃ保存など、システムよりの Co國 andであり、 UndoableCo國 andや VCCo國 andとは別に、非同期的に実行される。 AsynchronousCommandは、 Undoab leCommandではなしゝので、取り消すことはできない。

[0074] c) リソース

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

[0075] 2. アプリケーションコンポーネント

文書処理システムの第 2の主要な特徴であるアプリケーションコンポーネント 1 02は、実行環境 1 01において実行される。アプリケーションコンポーネント 1 02は、実際の文書と、システム内における文書の様々な論理的、物理的な表現を含む。さらに、アプリケーションコンポーネント 1 02 は、文書を管理するために使用されるシステムの構成を含む。アプリケーシヨンコンポーネント 1 02は、さらに、 UserAppl ication (ユーザアプリケーシヨン） 1 06、アプリケーションコア 1 08、ユーザインタフェイス 1 0 7、及び CoreComponent (コアコンポーネント） 1 1 0を含む。

[0076] a) ユーザアプリケーション

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

[0077] b) コアコンポーネント

CoreComponent 1 1 0は、複数の Pane (ペイン）の間で文書を共有する方法を提供する。後で詳述するように、 Paneは、 DOMツリーを表示し、画面の物理的なレイアウトを扱う。例えば、物理的な画面は、個々の情報の断片を描写する画面内の複数の Paneからなる。ユーザから画面上に見える文書は、

1又はそれ以上の Paneに出現しうる。また、 2つの異なる文書が画面上で 2 つの異なる Paneに現れてもよい。

[0078] 図 1 1 (c) に示されるように、画面の物理的なレイアウトもツリーの形式になっている。 Paneは、 RootPane (ルートペイン） 1 084にもなり得るし、 SubPane (サブペイン） 1 085にもなり得る。 RootPane 1 084は、 Pa neのツリーの根に当たる Paneであり、 SubPane 1 085は、 RootPane 1 084 以外の任意の Paneである。 [0079] CoreComponent 1 1 0は、さらに、フォントを提供し、ツールキットなど、文書のための複数の機能的な操作のソースの役割を果たす。 CoreComponent 1 1 0により実行されるタスクの一例に、複数の Pane間におけるマウスカーソルの移動がある。実行されるタスクの他の例として、ある Pane中の文書の一部をマークし、それを異なる文書を含む別の Pane上にコピーする。

[0080] c ) アプリケーションコア

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

[0081 ] DocumentManager 1 0 8 1の様々な態様を以下に詳述する。 DocumentManage r 1 0 8 1は、 Document 1 0 8 2を管理する。 DocumentManager 1 0 8 1は、 R ootPane 1 0 8 4、 SubPane 1 0 8 5、 C I i pBoard (クリップボード）ユーティリティ 1 0 8 7、及び Snapshot (スナップショット）ユーティリティ 1 0 8 8にも接続される。 C I i pBoardユーティリティ 1 0 8 7は、ユーザがクリップポードに加えることを決定した文書の部分を保持する方法を提供する。例えば、ユーザが、文書の一部を切り取り、後で再考するために新規文書にそれを保存することを望んだとする。このような場合、切り取られた部分が C l i pB oardに追加される。

[0082] つづいて、 Snapshotユーティリティ 1 0 8 8についても説明する。 SnapSho tユーティリティ 1 0 8 8は、アプリケーションがある状態から別の状態まで移行するときに、アプリケーションの現在の状態を記憶することを可能とする。

[0083] d ) ユーザインタフェイスアプリケーションコンポーネント 1 0 2の別の構成は、ユーザがシステムと物理的に対話する手段を提供するユーザインタフェイス 1 0 7である。例えば、ユーザインタフェイスは、ユーザが文書をアップロードしたり、削除したり、編集したり、管理したりするために使用される。ユーザインタフエイスは、 Frame (フレーム） 1 0 7 1、 MenuBar (メニューバー） 1 0 7 2、 S tatusBar (ステータスバー） 1 0 7 3、及び URLBar ( U R Lバー） 1 0 7 4 を含む。

[0084] Frame 1 0 7 1は、一般に知られているように、物理的な画面のアクティブな領域であるとみなされる。 MenuBar l 0 7 2は、ユーザに選択を提供するメニューを含む画面領域である。 StatusBar l 0 7 3は、アプリケーションの実行状態を表示する画面領域である。 URLBar l 0 7 4は、インターネットをナビゲー卜するために U R Lァドレスを入力する領域を提供する。

[0085] C . 文書管理及び関連するデータ構造

図 1 2は、 DocumentManager 1 0 8 1の詳細を示す。これは、文書処理システム内で文書を表現するために用いられるデータ構造及び構成を含む。分かりやすくするために、このサブセクションで説明される構成は、 M V Cパラダイ厶を用いて説明される。

[0086] DocumentManager 1 0 8 1は、文書処理システム内にある全ての文書を保持しホストする DoGumentConta i ner (ドキュメントコンテナ：文書コンテナ） 2 0 3を含む。 DocumentManager 1 0 8 1にァタツチされたツールキット 2 0 1 は、 DocumentManager 1 0 8 1により使用される様々なツールを提供する。例えば、 DomServ i ce ( D O Mサービス）は、文書に対応する D O Mを生成し、保持し、管理するために必要とされる全ての機能を提供するために、ツールキット 2 0 1により提供されるツールである。ツールキット 2 0 1によリ提供される別のツールである l OManager (入出力管理部）は、システムへの入力及びシステムからの出力を管理する。同様に、 StreamHand l er (ストリームハンドラ）は、ビットストリームによる文書のアップロードを扱うツールである。これらのツールは、図中に特に示さず、参照番号を割り当てないが、ッ一ルキット 201のコンポーネントを形成する。

[0087] MVCパラダイムの表現によれば、モデル（M) は、文書の DOMツリーモデル 202を含む。前述したように、全ての文書は、文書処理システムにおいて DOMツリーとして表現される。文書は、また、 DocumentContainer 2 03の一部を形成する。

[0088] 1. DOMモデル及びゾーン

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

[0089] 2. Facet及び Facetと Zoneとの関係

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

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

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

[0092] ボキヤブラリは、名前空間に属するタグ（例えば XMLのタグ）のセットである。上述したように、名前空間は、ユニークな名前（ここではタグ）のセットを有する。ボキヤブラリは、 XM L文書を表現する DOMツリーのサブツリーとして現れる。このサブツリーは Zoneを含む。特定の例においては、タグセットの境界は Zoneによって定義される。 Zone209は、 ZoneFactory 205と呼ばれる Serviceを利用して生成される。上述したように、 Zone 20 9は、文書を表現する DOMツリーの一部の内部表現である。このような文書の一部へのアクセスを提供するために、論理的な表現が要求される。この論理的表現は、文書が画面上で論理的にどのように表現されるかについてコンピュータに通知する。 Canvas (キャンバス） 21 0は、 Zoneに対応する論理的なレイァゥトを提供するように作用する Serviceである。

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

[0094] Zone209に対応する Ganvas21 0は、 Editlet 206を使用して生成される。文書の DOMは、 Editlet 206及び Canvas 21 0を使用して編集される。元の文書の完全性を維持するために、 Editlet 206及び Canvas 21 0は、 Zone 2 0 9における 1以上の Nodeに対応する Facetを使用する。これらの Serv i ceは、 Zone及び D O M内の Nodeを直接操作しない。 Facetは、 Command 2 0 7 を利用して操作される。

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

[0096] 3 . Zone, Facet, Canvas及び Paneの間の関係の概要

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

[0097] 4 . アンドゥサブシステム

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

[0098] 例えば、ユーザが、文書中の単語を別の単語に置換するコマンドを実行したとする。その後、ユーザは考え直し、元の単語に戻すことを決定したとする。アンドゥサブシステム 21 2は、このような操作を支援する。 UndoManag er 21 21は、このような UndoableEd it (アンドゥアプルエディツト：取消可能な編集） 21 22の操作を保持する。

[0099] 5. カーソルサブシステム

前述したように、 MVCのコントローラ部分は、カーソルサブシステム 2 04を備えてもよい。カーソルサブシステム 204は、ユーザから入力を受け付ける。これらの入力は、一般にコマンド及び又は編集操作の性格を有している。したがって、カーソルサブシステム 204は、 DocumentManager 1 081に関連した MVCパラダイムのコントローラ（C) 部分であると考えることができる。

[0100] 6. ビュー

前述したように、 Canvas 21 0は、画面上に提示されるべき文書の論理的なレイアウトを表す。 XHTML文書の例では、 Canvas21 0は、文書が画面上でいかに見えるかを論理的に表現したボックスツリー 208を含んでもよい。このボックスツリー 208は、 DocumentManager 1 081に関連した M VCパラダイムのビュー（V) 部分に含まれよう。

[0101] D. ポキヤブラリコネクション

文書処理システムの重要な特徴は、 X ML文書を、他の表現にマップして取り扱うことが可能で、かつ、マップした先の表現を編集すると、その編集が元の X ML文書に整合性を保ちつつ反映される環境を提供することにある

[0102] マークアップ言語により記述された文書、例えば XML文書は、文書型定義により定義されたボキヤブラリに基づいて作成されている。ボキヤブラリは、タグのセットである。ボキヤブラリは、任意に定義されてもよいため、無限に多くのボキヤブラリが存在しうる。しかしながら、多数の可能なボキャブラリのそれぞれに対して専用の処理管理環境を提供するのは現実的ではない。ボキヤブラリコネクションは、この問題を解決する方法を提供する [0103] 例えば、文書は 2以上のマークアップ言語により記述されてもよい。文書は、例えば、 X H TM L (extensible HyperText Markup Language) 、 S V G (Scalable Vector Graphics) 、 Ma t h M L (Mathematical Markup Lan guage) 、その他のマークアップ言語により記述されてもよい。換言すれば、マークアップ言語は、 XM Lにおけるボキヤブラリゃタグセッ卜と同様に見なされてもよい。

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

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

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

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

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

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

[0110] 図 1 3は、ボキヤブラリコネクション（VC ： Vocabulary Connection) サブシステム 300を示す。 V Cサブシステム 300は、同一の文書の 2つの代替表現の整合性を維持する方法を提供する。例えば、 2つの表現は、同一文書の、 2つの異なるポキヤブラリによる表現であってもよい。前述したように、一方はソース DOMツリーであってもよく、他方はデスティネーション D O Mッリ一であってもよい。

[0111] 1. ポキヤブラリコネクションサブシステム

ポキャプラリコネクションサブシステム 300の機能は、 VocabularyConne ction301 と呼ばれるプラグインを使用して、文書処理システムにおいて実現される。文書が表現される Vocabulary305ごとに、対応するプラグインが要求される。例えば、文書の一部が HTMLで記述され、残りが SVGで記述されている場合、 H TMLと S VGに対応するボキヤブラリプラグインが要求される。

[0112] 008131||3 001111601^011プラグィン301は、適切な Vocabulary 305の文書に対応した、 Zone209又は Pane21 1のための適切な VGGanvas (ボキヤブラリコネクションキャンバス） 31 0を生成する。 VocabularyConnection 301を用いて、ソース DOMツリー内の Zone209に対する変更は、変換ルールにより、別の DOMツリー 306の対応する Zoneに伝達される。変換ルールは、ポキヤブラリコネクション記述子 (Vocabulary Connection Descr iptor： V C D) の形式で記述される。このようなソース DOMとデスティネーシヨン DOMの間の変換に対応するそれぞれの VC Dファイルについて、対応する VCManager (ボキヤブラリコネクションマネージャ） 302が生成される。

[0113] 2. Connector

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

[0114] Connector 304は、ツリー構造を形成するために、論理的にリンクされる。 Connector 304により形成されたツリーは、 ConnectorTree (コネクタッリー）と呼ばれる。 Connector 304は、 ConnectorFactory (コネクタファクトリ：コネクタ生成部） 303と呼ばれる Serviceを用いて生成される。 Conn ectorFactory 303は、ソース文書から Connector 304を生成し、それらをリンクして ConnectorTreeを形成する。 Vocabu I aryConnect ionManager 302 は、 Connector Factory 303を保持する。

[0115] 前述したように、ボキヤブラリは名前空間におけるタグのセットである。

図示されるように、 Vocabulary 305は、 Vocabu I aryConnect i on301によつて文書に対して生成される。これは、文書ファイルを解析し、ソース DO Mとデスティネーシヨン D O Mの間の写像のための適切な Vocabu I aryConnect ionManager 302を生成することにより行われる。さらに、 Connectorを生成する ConnectorFactory 303と、 Zone 209を生成する ZoneFactorv 205と、 Zone内のノードに対応する Canvasを生成する Ed it let 206との間の適切な関係が作られる。ユーザがシステムから文書を処分又は削除するとき、対応する VocabularyConnectionManager 302が肖 ij除される。

[0116] Vocabulary305は、 VCCanvas3 1 0を生成する。さらに、 Connector 30 4及びデスティネーション DOMツリー 306が対応して生成される。

[0117] ソース DO M及び Canvasは、それぞれ、モデル（M) 及びビュー（V) に対応する。しかしながら、このような表現は、ターゲットのボキヤブラリが画面上に描写可能である場合に限って意味がある。描写は、ボキヤブラリブラグインにより行われる。ボキヤブラリブラグィンは、主要なボキヤブラリ、例えば、 X H TM L、 SVG, Ma t h M Lについて提供される。ボキヤブラリブラグィンは、ターゲットのボキヤブラリに関連して使用される。これらは、ボキヤブラリコネクション記述子を用いてボキヤブラリ間でマッピングする方法を提供する。

[0118] このようなマッピングは、ターゲットのポキヤブラリカマッピング可能で、画面上に描写される方法が予め定義されたものである場合にのみ意味がある。このようなレンダリング方法は、例えば X H TM Lなどのように、 W 3 Cなどの組織により定義された標準規格となっている。

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

[0120] 3. DestinationZone、 Pane, 及び Canvas

上述したように、ボキヤブラリコネクションサブシステムの目的は、同一の文書の 2つの表現を同時に生成し保持することである。第 2の表現も、 D OMツリーの形式であり、これはデスティネーション DOMツリーとして既に説明した。第 2の表現における文書を見るために、 DestinationZone、 Canv as及び Paneが必要である。 [0121] VCCanvasが作成されると、対応する DestinationPane307が生成される。さらに、関連する065 1131^011031^35308と、対応する BoxTr ee 309が生成される。同様に、 VCCanvas3 1 0も、ソース文書に対する Pane 2 1 1及び Z one 209に関連づけられる。

[0122] DestinationGanvas308は、第 2の表現における文書の論理的なレイァゥトを提供する。特に、 DestinationGanvas308は、デスティネーション表現における文書を描写するために、カーソルや選択のようなユーザインタフエイス機能を提供する。 DestinationCanvas308に生じたイベントは、 Connec torに供給される。 DestinationCanvas308は、マウスイベント、キーボードイベント、ドラッグァンドドロップイベント、及び文書のデスティネーシヨン（第 2) 表現のボキヤブラリに特有なイベントを、 Connector 304に通知する。

[0123] 4. ポキヤブラリコネクションコマンドサブシステム

ポキヤブラリコネクション（VC) サブシステム 300の要素として、ポキヤブラリコネクション（VC) コマンドサブシステム 3 1 3がある。ポキャブラリコネクションコマンドサブシステム 3 1 3は、ポキヤブラリコネクシヨンサブシステム 300に関連した命令の実行のために使用される VCCo國 a nd (ポキヤブラリコネクションコマンド） 3 1 5を生成する。 VCCo國 andは、内蔵の Co國 andTemplate (コマンドテンプレート） 3 1 8を使用して、及び又は、スクリプトサブシステム 3 1 4においてスクリプト言語を使用してスクラッチからコマンドを生成することにより、生成することができる。

[0124] コマンドテンプレートには、例えば、「lf」コマンドテンプレート、「Whe n」コマンドテンプレート、「挿入（Insert) 」コマンドテンプレートなどがある。これらのテンプレートは、 VGGo國 andを作成するために使用される。

[0125] 5. XP a t hサブシステム

X P a t hサブシステム 3 1 6は、文書処理システムの重要な構成であり、ボキヤブラリコネクションの実現を支援する。 Connector 304は、一般に xpath情報を含む。上述したように、ボキヤブラリコネクションのタスクの 1 つは、ソース DOMツリーの変化をデスティネーション DOMツリーに反映させることである。 xpath情報は、変更修正を監視されるべきソース DOM ツリーのサブセットを決定するために用いられる 1以上の xpath表現を含む。

[0126] 6. ソース DOMツリー、デスティネーション DOMツリー、及び Connect orTreeの概要

ソース DOMツリーは、別のボキャプラリに変換される前のボキャプラリで文書を表現した D O Mッリ一又は Zoneである。ソース D O Mッリ一のノ一ドは、ソースノードと呼ばれる。

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

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

[0129] E. 文書処理システムにおけるイベントフロー

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

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

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

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

[0133] それに対して、キーストロークイベントは、 Canvas 2 1 0から流れる。キ一ストロークイベントは、即時的なフォーカスを有する。すなわち、それは、いかなる瞬間でも作業に関連する。 Canvas 2 1 0上に入力されたキーストロークイベントは、その親に渡される。キー入力は、文字列挿入を扱うことが可能な、異なるイベントによって処理される。文字列の挿入を扱うィベントは、キーボードを使用して文字が挿入されたときに発生する。他の「ィべント」は、例えば、ドラッグイベント、ドロップイベント、マウスイベントと同様に扱われる他のィベントを含む。 [0134] 1. ポキヤブラリコネクション外のイベントの取り扱い

イベントは、イベントスレッドを用いて渡される。 Canvas2 1 0は、ィべントを受け取ると、その状態を変更する。必要であれば、 Co國 and 1 052が Canvas 2 1 0により GommandQueue 1 053にポストされる。

[0135] 2. ボキヤブラリコネクション内のイベントの取り扱い

VocabularyGonnectionプラワイン 30 1を用しゝて、 Dest i nat i onCanvasi — 例である XHTMLCanvasl 1 06は、発生したイベント、例えば、マウスィベント、キーボードイベント、ドラッグアンドドロップイベント、及びボキヤブラリに特有のイベントなどを受け取る。これらのイベントは、コネクタ 30 4に通知される。より詳細には、図 2 1 (b) に図示されるように、 Vocabul aryGonnectionプラグイン 30 1内のィべン卜フローは、 SourcePane 1 1 03 、 VCCanvas 1 1 04、 Dest i nat ionPane 1 1 05、 DestinationGanvasの一例である Dest i nat ionCanvas 1 1 06、デスティネーション D OMツリー及び Co nnector丁 ree¾r通過する o

[0136] F. Programlnvoker及び Programlnvokerと他の構成との関係

Programlnvoker 1 03及びそれと他の構成との関係は、図 1 4 (a) に更に詳細に示される。 Programlnvoker 1 03は、文書処理システムを開始するために実行される実行環境中の基本的なプログラムである。図 1 1 (b) に図示されるように、 UserAppl i cat ion 1 06、 ServiceBroker 1 04 1、 Comma ndlnvoker 1 05 1、及び Resource 1 09は、全て Programlnvoker 1 03に f妾続される。前述したように、アプリケーション 1 02は、実行環境中で実行されるコンポーネントである。同様に、 ServiceBroker 1 04 1は、システムに様々な機能を加えるプラグインを管理する。他方、 Co國 andlnvoker 1 05 1は、ユーザにより提供される命令を実行して、コマンドを実行するために使用されるクラス及びファンクションを保持する。

[0137] 1. プラグイン及びサービス

ServiceBroker 1 04 1について、図 1 4 (b) を参照して更に詳細に説明する。前述したように、 ServiceBroker 1 04 1は、システムに様々な機能を追加するプラグイン（及び関連するサービス）を管理する。 Service 1 042 は、文書処理システムに特徴を追加又は変更可能な最も下の層である。「Ser vicej は、 $61^10603 6§0「 401 と$61^106卩「0 1€|6「402の2っの咅|5分カヽらなる。図 1 4 (c) に図示されるように、 1っの561^10603 680 401は、複数の関連する ServiceProvider402を持ちうる。それぞれの ServicePro viderは、特定の ServiceCategoryの一部または全部を実行するように作用する。 ServiceGategory401は、他方では、 Serviceの型を定義する。

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

[0139] Serviceの例は、図 1 4 (d) に示される。アプリケーション Serviceの Cat egoryにおいては、システムユーティリティが対応する ServiceProviderの例である。同様に、 Editlet206は Categoryであり、 HTMLEditlet及び SVGEdit letは対応する ServiceProviderである ₀ ZoneFactory 205は、 Serviceの另 ij の Categoryであり、対応する ServiceProvider (図示せず）を有する。

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

[0141] 2. Programlnvokerとアプリケーションとの関係

図 1 4 ( e ) は、 Programlnvoker 1 03と UserAppl ication 1 06との関係についての更なる詳細を示す。必要な文書やデータなどは、ストレージからロードされる。必要なプラグインは、全て ServiceBrokeM 041上にロードされる。 ServiceBroker 1 041は、全てのプラグインを保持し管理する。プラグインは、システムに物理的に追加することができ、又、その機能はストレージからロードすることができる。プラグインの内容がロードされると、 S erviceBroker 1 041は、対応するプラグインを定義する。つづいて、対応する UserAppl ication 1 06が生成され、実行環境 1 0 1にロードされ、 Prog ramlnvoker 1 03にアタッチされる。

[0142] G. アプリケーションサービスと環境との関係

図 1 5 (a) は、 Program Invoker 1 03上にロードしたアプリケーションサービスの構成についての更なる詳細を示す。コマンドサブシステム 1 05 のコン不一ネン卜である Command Invoker 1 05 1は、 Program Invoker 1 03 内の Command 1 052を起動又は実行する。 Command 1 052は、文書処理システムにおいて、 XM Lなどの文書を処理し、対応する XM L DOMツリーを編集するために用いられる命令である。 Co國 and Invoker 1 05 1は、 Comma nd1 052を実行するために必要なクラス及びファンクションを保持する。

[0143] ServiceBroker 1 04 1も、 Program Invoker 1 03内で実行される。 UserAp pi ication 1 06は、ユーザインタフェイス 1 07及び CoreComponent 1 1 0 に接続される。 CoreComponent 1 1 0は、全ての Paneの間で文書を共有する方法を提供する。 CoreComponent 1 1 0は、さらにフォントを提供し、 Paneのためのツールキッ卜の役割を果たす。

[0144] 図 1 5 ( b ) は、 Frame 1 07 1、 MenuBar 1 07 2、及び StatusBar 1 07 3の関係を示す。

[0145] H. アプリケーションコア

図 1 6 (a) は、全ての文書、及び文書の一部及び文書に属するデータを保持するアプリケーションコア 1 08についての更なる説明を提供する。 Cor eComponent 1 1 0は、文書 1 082を管理する DocumentManager 1 08 1にァタツチされる。 DocumentManager 1 08 1は、文書処理システムに関連づけられたメモリに格納される全ての文書 1 082の所有者である。

[0146] 画面上の文書の表示を容易にするために、 DocumentManager 1 08 1は Root Pane 1 084にも接続される。 CI ipBoard 1 087、 SnapShot 1 088、 Drag &Drop60 1、及び Over lay 602の機能も、 CoreComponent 1 1 0にアタッチされる。

[0147] SnapShot 1 088は、アプリケーションの状態を元に戻すために使用される。ユーザが Snapshot 1 088を起動したとき、アプリケーションの現状が検知され、格納される。その後、アプリケーションの状態が別の状態に変わるとき、格納された状態の内容は保存される。 SnapShotl 088は、図 1 6 (b) に図示される。動作において、アプリケーションがある U R Lから他へ移動するときに、前に戻る動作及び先に進む動作をシームレスに実行可能とするために、 SnapShotl 088は以前の状態を記憶する。

[0148] I . DocumentManager内における文書の構成

図 1 7 ( a ) は、 DocumentManager 1 08 1の更なる説明と、 DocumentMana gerにおいて文書が構成され保持される様子を示す。図 1 1 (b) に示したように、 DocumentManager 1 08 1は、文書 1 082を管理する。図 1 7 (a) に示される例において、複数の文書のうちの 1つは RootDocument (ルート文書） 701であり、残りの文書は SubDocument (サブ文書） 702である。 Do cumentManager 1 081は、 RootDocument 701に接され、 RootDocument 7 01は、全ての SubDocument 702に接続される。

[0149] 図 1 2及び図 1 7 (a) に示すように、 DocumentManager 1 08 1は、全ての文書 1 082を管理するォブジェクトである DoGumentContainer 203に結合される。 D0MService703及び lOManager 704を含むツールキット 201 (例えば XM Lツールキット）の一部を形成するツールも、 DocumentManager 1 081に供給される。再び図 1 7 (a) を参照して、 D0MService703は、 DocumentManager 1 081により管理される文書に基づいた D OMツリーを生成する。各 Document 705は、それが RootDocument 701であっても SubDo cument 702であっても、対応する DocumentGonta iner203によって管理される。

[0150] 図 1 7 (b) は、文書 A_Eが階層的に配置される様子を示す。文書 Aは R ootDocumentである。文書 B— Dは、文書 Aの SubDocumentである。文書 Eは、文書 Dの SubDocumentである。図 1 7 (b) の左側は、これと同じ文書の階層が画面上に表示された例を示す。 RootDocumentである文書 Aは、基本フレームとして表示される。文書 Aの SubDocumentである文書 B_Dは、基本フレー厶 Aの中のサブフレームとして表示される。文書 Dの SubDocumentである文書 Eは、サブフレーム Dのサブフレームとして画面に表示される。

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

[0152] UndoWrapper 707は、 DocumentContainer 203内の SubDocumentに関連するアンドゥオブジェクトをラップし、それらを RootDocumentに関連するアンドウオブジェクトに結合させる。 UndoWrapper 707は、 Undoab I eEd itAccept or (アンドウアプルエディットァクセプタ：アンドウ可能編集受付部） 70 9に利用可能なアンドウオブジェク卜の収集を実行する。

[0153] UndoManager 706及び UndoWrapper 707は、 Undoab I eEd i tAcceptor 70 9及び UndoableEditSource (アンドゥァブルエディットソース） 708に接続される。当業者には理解されるように、 Document 705が Undoab I eEd i tSou rce708であってもよく、取消可能な編集オブジェク卜のソースであってもよい。

[0154] J. アンドゥコマンド及びアンドゥフレームワーク

図 1 8 (a) 及び図 1 8 (b) は、アンドゥフレームワーク及びアンドゥコマンドについて更なる詳細を提供する。図 1 8 (a) に示されるように、 U ndoCommand 80 1、 RedoCommand 802、及び UndoableEditGommand803は、図 1 1 (b) に示したように Co國 andlnvokeM 05 1に積むことができるコマンドであり、順に実行される。 UndoableEditCommand803は、 Undoab le EditSource708及び Undoab I eEd i tAcceptor 709に更にァタツチされる。「foo」 EditCommand804及び「bar」 EditCommand805は、 UndoableEditC ommandの例である。

[0155] 1. UndoableEditCo國 andの実行

図 1 8 (b) は、 UndoableEditGommandの実行を示す。まず、ユーザが編集コマンドを使用して Document 705を編集すると仮定する。第 1ステップ S 1では、 UndoableEditAcceptor 709が、 Document 705の D OMツリーでぁる11|^0313|6£(1 501^06708にァタツチされる。第 2ステップ S 2では、ユーザにより発行されたコマンドに基づいて、 Document 705が DOMの A P Iを用いて編集される。第 3ステップ S 3では、ミュー亍ーシヨンィベン卜のリスナーが、変更がなされたことを通知される。すなわち、このステツプでは、 DOMツリーの全ての変更を監視するリスナーが編集操作を検知する。第 4ステップ S 4では、 UndoableEditが UndoManager 706のォブジェクトとして格納される。第 5ステップ S 5では、 UndoableEditAcceptor 709 7b UndoableEditSource708からデタツチされる。 UndoableEditSource70 8は、 Document705自身であってもよい。

[0156] K. システムへの文書のロードに関する手順

上記のサブセクションでは、システムの様々なコンポーネント及びサブコンポーネントについて説明した。以下、これらのコンポーネントの使用に関する方法論について説明する。図 1 9 (a) は、文書処理システムに文書がロードされる様子の概要を示す。それぞれのステップは、図 24— 28において、特定の例に関連して詳述される。

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

[0158] より詳細には、文書はストレージ 90 1からロードされる。文書の DOM ツリー 902が生成される。文書を保持するための、対応する DocumentConta i ner 903が生成される。 DocumentConta iner 903は、 DocumentManager 9 04にアタッチされる。 DOMツリーは、ルートノードと、ときには複数のセカンダリノードを含む。

[0159] 一般に、このような文書は、テキスト及びグラフィクスの双方を含む。したがって、 DOMツリーは、例えば、 X H TM Lサブツリーだけでなく SV Gサブツリーを有してもよい。 X H TM Lサブツリーは、乂1~1丁1\11_の卩6乂 ode905を有する。同様に、 SVGサブツリーは、 S V Gの ApexNode 906 を有する。

[0160] ステップ 1では、 ApexNode906が、画面の論理的なレイァゥトである Pan e907にアタッチされる。ステップ 2では、 Pane907は、 PaneOwner (ぺィンオーナー：ペインの所有者） 908である CoreComponentに、 ApexNode 9 06のための ZoneFactoryを要求する。ステップ 3では、 PaneOwner 908は、 ZoneFactoryと、 ApexNode906のための CanvasFactoryである Editletとを返す。

[0161] ステップ 4では、 Pane907が Zone909を生成する。 Zone909は Pane 907にアタッチされる。ステップ 5では、 Zone909がそれぞれのノードに対して Facetを生成し、対応するノードにアタッチする。ステップ 6では、卩8116907が031^359 1 0を生成する。 Canvas 9 1 0は Pane 907にァタツチされる。 Canvas9 1 0には様々な Commandが含まれる。ステップ 7では、 Ca nvas9 1 0が文書を画面にレンダリングするためのデータ構造を構築する。

X H TM Lの場合、これはボックスツリー構造を含む。

[0162] 1. Zoneの MV C

図 1 9 (b) は、 MVCパラダイムを用いて Zoneの構成の概要を示す。この場合、 Zone及び Facetは文書に関連した入力であるから、モデル（M) は Zo ne及び Facetを含む。 Canvasと、文書を画面にレンダリングするためのデータ構造体は、ユーザが画面上に見る出力であるから、ビュー（V) は Canvas及びデータ構造体に対応する。 Co國 andは、文書とその様々な関係に対して制御操作を実行するので、コントロール（c) は Canvasに含まれる Co國 andを含む

[0163] し文書の表現

図 20を用いて、文書及びその様々な表現の例について以下に説明する。この例で使用される文書は、テキストと画像の双方を含む。テキストは、 X H TM Lを用いて表され、画像は、 SVGを用いて表される。図 20は、文書のコンポーネント及び対応するォブジェク卜の関係の MVC表現を詳細に示す。この例において、 Document 1 00 1は、 Document 1 00 1を保持する D ocumentContainer 1 002にアタッチされる。文書は DOMツリー 1 003 により表現される。 DOMツリーは、 ApexNode 1 004を含む。

[0164] ApexNodeは、黒丸で表される。頂点でないノードは、白丸で表される。ノードを編集するために用いられる Facetは、三角形で表され、対応するノードにアタッチされる。文書がテキストと画像を有するので、この文書の DOM ツリーは、 X H TM L部分と SVG部分を含む。 ApexNode 1 004は、 X H TM Lサブツリーの最上のノードである。これは、文書の X H TM L部分の物理的な表現のための最上 Paneである XHTMLPanel 005にァタツチされる。

ApexNode 1 004は、文書の D OMツリーの一部である XHTMLZone 1 006にもァタツチされる。

[0165] Node 1 004に対応する Facetも、 XHTMLZone 1 006にアタッチされる。 X HTMLZone 1 006は、 XHTMLPanel 005にアタッチされる。 XHTMLEditletは、文書の論理的な表現である XHTMLGanvas 1 007を生成する。 XHTMLGanvas 1 007は、 XHTMLPanel 005にアタッチされる。 XHTMLCanvas 1 007は、 Document 1 00 1の X H TM Lコンポーネン卜のための BoxTree 1 009を生成する。文書の X H TM L部分を保持し描画するために必要な様々な Co國 a nd 1 008も、 XHTMLCanvas 1 007に追加される。

[0166] 同様に、文書の SVGサブツリーの ApexNode 1 0 1 0は、文書の SVGコンポーネントを表現する Document 1 00 1の D OMツリーの一部である SVGZo ne 1 0 1 1にアタッチされる。 ApexNode 1 0 1 0は、文書の SVG部分の物理的な表現の最上の Paneである SVGPanel 0 1 3にアタッチされる。文書の S VG部分の論理的な表現を表す SVGCanvasl 0 1 2は、 SVGEditletにより生成され、 SVGPanel 0 1 3にアタッチされる。画面上に文書の S V G部分をレンダリングするためのデータ構造及びコマンドは、 SVGCan vasにアタッチされる。例えば、このデータ構造は、図示されるように、円、線、長方形などを含んでもよい。

[0167] 図 20に関連して説明された文書例の表現の一部について、図 21 (a) に関連して、前述した MVCパラダイムを用いて更に説明する。図 2 1 (a ) は、文書 1 00 1の X H TM Lコンポーネントにおける MVの関係を簡略ィ匕して示す。モデルは、 Document 1 00 1の X H T M Lコンポーネントのための XHTMLZonel 1 0 1である。 XHTMLZoneのツリーには、いくつかの Node及びそれらに対応する Facetが含まれる。対応する XHTMLZone及び Paneは、 MV Cパラダイムのモデル（M) 部分の一部である。 MVCパラダイムのビュー (V) 部分は、 Document 1 00 1の X H T M Lコンポーネントの、対応する X HTMLCanvas 1 1 02及び BoxTreeである。文書の X H TM L部分は、 Canvasと、それに含まれる Co國 andを使用して画面に描写される。キーボードやマウス入力などのイベントは、図示されるように、逆方向へ進む。

[0168] SourcePaneは、更なる機能、すなわち、 D OMの保有者としての役割を有する。図 2 1 (b) は、図 2 1 (a) に示した Document 1 00 1のコンポ一ネントに対するボキヤブラリコネクションを提供する。 DOMホルダーとして機能する SourcePane 1 1 03は、文書のソース D OMツリーを含む。 Gonne ctorTreeは、 GonnectorFactoryにより生成され、デスティネーション DOM の保有者としても機能する DestinationPane 1 1 05を生成する。 Destinatio nPane 1 1 05は、 XHTMLDest i nat i onCanvas 1 1 06としてボックスツリーの形式でレイァゥ卜される。

[0169] M. プラグインサブシステム、ボキヤブラリコネクション、及びコネクタの関係

図 22 (a) - ( c) は、それぞれ、プラグインサブシステム、ポキヤブラリコネクション、及び Connectorに関連する更なる詳細を示す。プラグインサブシステムは、文書処理システムに機能を追加又は交換するために用いられる。プラグインサブシステムは、 ServiceBroker 1 04 1を含む。 ServiceB roker 1 04 1 ^^^†l¾ZoneFactoryService 1 20 1は、文書の一咅 |5 に対する Zoneを生成する。 EditletService 1 202も、 ServiceBroker 1 04 1にアタッチされる。 EditletService 1 202は、 Zone中の Nodeに対応する C anvasを生成する。

[0170] ZoneFactoryの例は、 XHTMLZone及び SVGZoneをそれぞれ生成する XHTMLZoneF actory 1 2 1 1及び SVGZoneFactory 1 2 1 2である。文書例に関連して前述したように、文書のテキストコンポーネントは、 XHTMLZoneを生成することにより表現されてもよいし、画像は SVGZoneを用いて表現されてもよい。 Editle tServiceの例は、 XHTMLEditlet 1 22 1及び SVGEditlet 1 222を含む。

[0171] 図 22 (b) は、ポキヤブラリコネクションに関連する更なる詳細を示す。ポキヤブラリコネクションは、前述したように、文書処理システムの重要な特徴であり、 2つの異なる方法で文書の整合のとれた表現及び表示を可能とする。 ConnectorFaGtory303を保持する VCManager 302は、ポキヤブラリコネクションサブシステムの一部である。 ConnectorFaGtory303は、文書の Connector 304を生成する。前述したように、 Connectorは、ソース D OM中のノードを監視し、 2つの表現の間の整合性を維持するために、デスティネーション DOM中のノードを修正する。

[0172] Temp late 3 1 7は、いくつかのノードの変換ルールを表す。ボキヤブラリコネクション記述子（VCD) ファイルは、特定のパス又はルールを満たす要素又は要素の集合を他の要素に変換するいくつかのルールを表す Temp I ate のリストである。 Template3 1 7及び GommandTemplate3 1 8は、全て VGMana ger 302にアタッチされる。 VCManagerは、 V C Dファイル中の全てのセクシヨンを管理するオブジェクトである。 1つの VCDファイルに対して、 1 つの VCManagerオブジェク卜が生成される。

[0173] 図 22 (c) は、 Connectorに関連する更なる詳細を提供する。 ConnectorF actory303は、ソース文書から Connectorを生成する。 ConnectorFactory 3 03は、 Vocabulary^ Template^ 及び ElementTemplateにアタッチされ、それぞれ、 Vocabu I aryConnector TemplateConnector ElementGonnectorを生成ずる。

[0174] VCManager 302は、 ConnectorFactory 303を保持する。 Vocabularyを生成するために、対応する V CDファイルが読み込まれる。こうして、 Connect orFactory 303力《生成される。この ConnectorFactory 303は、 Zoneを生成する ZoneFactor y及び Canvasを生成する Ed i 11 etに関連する。

[0175] つづいて、ターゲットボキャブラリの£ 1:161561^106が、 003^33を生成する。 VGGanvasも、ソース D OMツリー又は Zoneにおける ApexNodeの Connect orを生成する。必要に応じて、子の Connectorが再帰的に生成される。 Connec torTreeは、 V C Dファイル中のテンプレー卜の集合により生成される。

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

[0177] N. ConnectorTreeに関係する VCDファイルの例

特定の文書と関係する処理を説明する例を続ける。ドキュメントタイトルのある「MySampleXML」というタイトルの文書が文書処理システムにロードされる。図 23は、「MySamp I eXML」ファイルのための、 VCManager及び Connect orFactoryTreeを用いた V C Dスクリプ卜の例を示す。スクリプトファイル中のボキヤブラリセクシヨン、テンプレートセクションと、 VCManagerにおける対応するコンポーネントが示される。タグ「vcd: vocabu laryj において、属性「matGh」は「sample: rootj 、 Γ label」は「MySamp I eXMLj 、「calト temp latej は「sample templatej となってしゝる。

[0178] この例では、 Vocabularyは、「MySamp I eXMLj の VCManagerにおいて「sampl e: root j として頂点要素を含む。対応する U Iラベルは、「MySamp I eXML」である。テンプレートセクションにおいて、タグは「vcd: templatej であり、名 B'Jは「sample: templatej でめる。

[0179] O. ファイルがシステムにロードされる方法の詳細な例

図 24— 28は、文書「MySamp I eXML」のロードについての詳細な記述を示す。図 24 (a) に示されるステップ 1では、文書がストレージ 1 405カヽらロードされる。 DOMServiceは、 D OMツリー及び DocumentManager 1 406 と対 Ji、する DocumentGontaineM 401を生成する。 DocumentGontaineM 4 01は、 DocumentManager 1 406にアタッチされる。文書は、 XHTML及び MySampleXMLのサブツリーを含む。 X H T M Lの ApexNode 1 403は、タグ rxhtml： html J が付された X H T M Lの最上のノードである。「MySampleXML 」の ApexNodel 404は、タグ「sample: rootj 力《付された「MySamp I eXMLj の最上ノードである。

[0180] 図 24 (b) に示されるステップ 2では、 RootPaneが文書の XHTMLZone、 Fa cet、及び Canvasを生成する。 Panel 407、 XHTMLZone 1 408、 XHTMLCanv as 1 409、及び BoxTreel 41 0が、 ApexNodel 403に対応して生成される。

[0181] 図 24 (c) に示されるステップ 3では、 XHTMLZoneが知らないタグ「samp le:root」を発見し、 XHTMLCanvasの領域から SubPaneを生成する。

[0182] 図 25に示されるステップ 4では、 SubPaneが「sample: root」を扱うことができ、適切な Zoneを生成可能な ZoneFactoryを得る。この ZoneFactoryは、 Z oneFactoryを実行可肯な Vocabulary内にある。それは、「MySamp I eXMLj の Vo cabu I arySect i onの内容を含む c

[0183] 図 26に示されるステップ 5では、「MySampleXML」に対応する Vocabulary カ《06 311 20^1 601を生成する。対応する Ed it letが生成され、対応する C anvasを生成するために SubPane 1 501が提供される。 Editletは、 VGGanvas を生成する。そして、それは TemplateSectionを呼ぶ。 ConnectorFaGtoryTree も含まれてしゝる o ConnectorFaGtoryTreeは、 ConnectorTreeとなる全ての Conn ectorを生成する。

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

[0185] 図 28に示されるステップ 7では、ボキヤブラリは、ソース DOMのペインからデスティネーシヨン D O Mッリ一の Dest i nat i onPaneを作成する。これは、 SourcePaneに基づいてなされる。デスティネーションツリーの ApexNode は、 DestinationPane及び对 j心する Zoneにアタッチされる。 Dest i nat ionPane は、 DestinationCanvasを生成し、文書をデスティネーションのフォーマットでレンダリングするためのデータ構造及びコマンドを構築する、自身の Editl etを提供される。

[0186] 図 29 (a) は、対応するソースノードを持たず、デスティネーションッリーにのみ存在するノード上でィベン卜が発生したときのフローを示す。マウスイベント、キーボードイベントなど、 Canvasが取得したイベントは、デスティネーシヨンッリ一を通過して、 E I ementTemp I ateConnectorに伝達される。 ElementTemplateConnectorは対応するソースノードを持たないので、伝達されたィベントはソースノードに対する編集操作ではない。 ElementTempla teConnectorは、伝達されたィベン卜が CommandTemplateに記述されたコマンドに合致すれば、それに対応する Actionを実行する。合致するコマンドがなければ、 E I ementTemp I ateConnector (i 伝達されたィベン卜を無視する。

[0187] 図 29 (b) は、 TextOfConnectorによリソースノードに対応づけられているデスティネーションツリーのノード上でィベン卜が発生したときのフローを示す。 TextOfConnectorは、ソース DOMツリーの X P a t hで指定されたノードからテキストノードを取得して、デスティネーション DOMツリーのノードにマッピングする。マウスイベント、キーボードイベントなど、 Canva sが取得したイベントは、デスティネーションツリーを通過して、 TextOfConn ectorに伝達される。 TextOf Connectorは、伝達されたイベントを、対応するソースノードの編集コマンドにマッピングし、 Queue 1 0 5 3に積む。編集コマンドは、 Facetを介して実行される D O Mの A P Iコールの集合である。キユーに積まれたコマンドが実行されると、ソースノードが編集される。ソースノードが編集されると、ミュー亍ーシヨンイベントが発行され、リスナーとして登録された TextOfConnectorにソースノードの変更が通知される。 Text Of Connectorは、ソースノードの変更を、対応するデスティネーションノードに反映させるように、デスティネーションツリーを再構築する。このとき、 T extOf Connectorを含むテンプレー卜に、「for eachj や「for l oopj などの制御文が含まれている場合、 ConnectorFactoryがこの制御文を再評価し、 Tex tOf Connectorを再構築した後、デスティネーションツリーが再構築される。

[0188] (実施の形態）

実施の形態では、画像の任意の領域にァノーテーシヨンをつける技術を提案する。すなわち、画像のある範囲又はある領域に対して、注釈やメモなどの新たな情報をメタ情報として付加する、又は関連づける技術を提案する。

[0189] 例えば、ある写真に複数の人物が写っている場合に、それぞれの人物が写つている領域に対して氏名や説明などの情報がメタ情報として提供されれば、よりユーザフレンドリで付加価値の高い情報となる。このメタ情報は、特定のシステムに依存しない形式で提供されるのが好ましい。本実施の形態では、画像の任意の領域に対して設定されたメタ情報を X M Lデータとして記録する。

[0190] 図 3 0は、実施の形態に係る文書処理装置の構成を示す。本実施の形態の文書処理装置 1 0 0は、図 1に示した前提技術の文書処理装置 2 0の構成に加えて、ァノーテーシヨンユニット 7 0及び取得部 7 8を備える。ァノーテーシヨンュニット 7 0は、ァノーテーシヨンを付す画像の領域の設定を受け付ける領域設定受付部 7 1、領域に付すァノーテーシヨンの設定を受け付けるァノーテーシヨン設定受付部 7 2、設定されたァノーテーシヨンを記録するァノーテーシヨン記録部 73、設定されたァノーテーシヨンを表示するァノーテーシヨン表示部 74、設定されたァノーテーシヨンを検索する検索部 75を含む。

[0191] 取得部 78は、ァノーテーシヨンをつける対象となる画像と、ァノーテ一シヨンを記録した文書ファイルと、ァノーテーシヨンを記録した文書フアイルを処理するための定義ファイルとを取得する。本実施の形態では、画像の領域に対して設定されたァノーテーシヨンは、画像に付されたァノーテーシヨンを記述するために用意された専用のタグセット（以下、「画像ァノーテーシヨンボキヤブラリ」という）を用いて、 XM L文書として記録される。画像ァノーテーシヨンボキヤブラリを処理するための処理系は、ハードコードプラグィンなどのモジュールとして用意されてもよいが、本実施の形態では、画像ァノーテーシヨンボキヤブラリの要素を処理する方法が記述された定義ファイルが用意されている。したがって、領域設定受付部 7 1、ァノーテーシヨン設定受付部 72、ァノーテーシヨン記録部 73、ァノーテーション表示部 74の各機能は、定義ファイルと VCュニット 80により実現される。

[0192] 図 31は、ァノーテーシヨンを記録した文書ファイルの例を示す。文書フアイルは、画像ァノーテーシヨンポキヤブラリ「ia」で記述されており、ルート要素「ia:portal」の子要素として「ia:images」要素が設けられており、更にその子要素として、画像の設定情報を格納する「ia:image」要素が設けられている。「ia:image」要素は複数設けられてもよく、その場合、 1つの文書ファイルに複数の画像に対するァノーテーシヨンが記録される。「ia: image j 要素の属性「href」には画像の U R Lが格納され、子要素「ia:title 」には画像のタイトルが格納され、子要素「ia:description」には画像の説明が格納される。また、子要素「ia:parts」には画像の 1以上の領域に対して付されたァノーテーシヨンの情報が格納される。「ia:parts」要素は、 1 以上の子要素「ia:part」を有する。要素「ia:part」は、各領域の設定情報を格納しており、子要素「ia:rectangle」には矩形領域の左上と右下の座標値がそれぞれ属性「x1」、「y1」、「x2」、「y2」として格納され、子要素「ia:descr iptionsj には領域の説明力《格納される。「ia:descr iptionsj 要素は、 1以上の子要素「ia:descr iption」を有しており、それぞれの「ia:de scriptionj 要素には、領域に対して設定されたァノーテーシヨンが格納される。「ia:description」要素は、ァノーテーシヨンの形式を格納する「type 」属性、ァノーテーシヨンのタイトルを格納する「title」属性、ァノーテ一シヨンの主題を格納する「subject」属性を有しており、必要に応じて柔軟にァノーテーシヨンを設定可能としている。ァノーテーシヨンの形式は、テキスト、画像、音声、動画、 XMLデータ、などであってもよい。また、任意の要素名を付けてァノーテーシヨンを設定できるようにしてもよい。画像をァノーテーシヨン情報として設定した場合、さらにその画像にァノーテーシヨンをつけて、ァノーテーシヨンをネストさせてもよい。

[0193] 領域設定受付部 7 1は、取得部 78により取得された画像を表示し、ユーザからァノーテーシヨンの設定要求を受け付けると、ァノーテーシヨンの設定対象となる領域の設定を受け付ける。領域設定受付部 7 1は、例えば、ュ一ザがァノーテーシヨンを設定したい矩形領域の左上の位置でマウスをクリックし、右下方向へドラッグして矩形領域の右下の位置で放したときに、矩形領域の左上と右下の座標を取得し、矩形領域の設定を受け付けてもよい。領域設定受付部 7 1は、矩形以外にも、円、多角形、その他任意の形状の領域の設定を受け付けてもよい。その場合、領域の形状と位置を一意に特定できる情報をユーザから取得する。

[0194] ァノーテーシヨン設定受付部 72は、領域設定受付部 7 1が受け付けた領域に対して付されるァノーテーシヨンの設定を受け付ける。ァノーテーション設定受付部 72は、図 31に示した画像ァノーテーシヨンボキヤブラリの仕様に沿って、ァノーテーシヨンとして設定可能な情報をユーザから受け付ける。ァノーテーシヨン設定受付部 72は、設定可能な情報をフォーム形式でユーザから受け付けてもよいし、ダイァ口グ画面などを提示して対話形式でユーザから受け付けてもよい。また、！~1丁1\11_ュニット50ゃ5 0ュニット 60などの処理系により、表示画面において WYS IWYG編集を受け付けてもよい。

[0195] ァノーテーシヨン設定受付部 72は、複数の領域に対して共通のァノーテーシヨンの設定を受け付けてもよい。例えば、ビルのフロアマップの画像に対して、非常口の位置をァノーテーシヨンする場合に、複数存在する非常口に対して共通のァノーテーシヨンを設定できるようにしてもよい。この場合、領域設定受付部 7 1力複数の領域の設定を連続して受け付けてもよいし、既に設定されたァノーテーシヨンに領域を追加するコマンドを用意してもよい。

[0196] ァノーテーシヨン記録部 73は、領域設定受付部 7 1が受け付けた領域を特定するための情報と、ァノーテーシヨン設定受付部 72が受け付けたァノ一亍ーシヨンの設定情報とを対応付けて記録する。ァノーテーシヨン記録部 73は、図 31に示したように、要素「ia:part」の子要素「ia:rectangle」に矩形領域の座標を、子要素「ia:title」に領域のタイトルを、子要素「ia: descriptionsj に領域に設定されたァノーテーシヨンの情報を、それぞれ対応づけて記録する。

[0197] ァノーテーシヨン表示部 74は、設定されたァノーテーシヨンを表示する。ァノーテーシヨン表示部 74は、定義ファイルに記述されたテンプレートにしたがって画像ァノーテーシヨンポキャプラリの各要素を X H TM Lの要素にマツビングし、マツビングされた X H TM L文書を H TM Lュニット 5 0により表示する。

[0198] 検索部 75は、設定されたァノーテーシヨンを検索する。図 31に示したように、ァノーテーシヨンは XM L形式で記録されるので、テキスト情報として設定されたァノーテーシヨンは簡単に検索することができる。また、画像や音声などの情報がァノーテーシヨンとして設定された場合であっても、キーワードなどを設定しておくことにより、検索が可能である。設定された情報を RSS出力することにより、外部の検索エンジンなどを用いてァノ一亍ーシヨンの検索を可能としてもよい。 [0199] 図 32は、ァノーテーシヨン表示部 74により表示された画面の例を示す。画像ァノーテーシヨンポキヤブラリの処理方法を規定する定義ファイルに記述されたテンプレートにより画面が生成されて表示されている。画面は 3 つのフレームに分割されており、左側のフレームにはァノーテーシヨンの設定対象となる画像の一覧が表示されており、中央のフレームには選択中の画像が表示されており、右側のフレームには選択中の画像に設定されたァノー亍ーシヨンの一覧が表示されている。中央のフレームには、「編集モード」と「表示モード」を切り替えるボタンが用意されており、編集モードでは領域に対してァノーテーシヨンを設定したり、設定されたァノーテーシヨンを編集するための画面が提示され、表示モードでは設定されたァノーテーションを表示する画面が提示される。

[0200] 左側のフレームにおいて、ユーザがマウスで画像をクリックすると、その画像が選択されて中央のフレームに表示される。また、左側のフレームには、対象となる画像を新たに追加するポタンと、画像を削除するポタンが用意されている。ユーザが画像の追加を要求すると、ァノーテーシヨンユニット 70は、画像の指定を受け付け、受け付けた画像を取得部 78により取得するとともに、ソース DOMツリーに「ia:image」要素を追加し、「href」属性にその画像の U R Lを格納する。この後、ソース DOMツリーが変更されたことを示すミューテーシヨンィベン卜が発行され、ァノーテーシヨン表示部 74が表示を更新することにより、追加された画像が表示される。ユーザが画像の削除を要求すると、ァノーテーシヨンユニット 70は、選択された画像に該当する「ia:image」要素をソース DOMツリーから削除する。

[0201] 図 33は、領域設定受付部 7 1が領域の設定を受け付ける画面の例を示す。編集モードにおいて、「新規パーツ」ボタンをユーザがクリックすると、ァノーテーシヨン記録部 73は、ソース DOMツリーの「ia:parts」要素の下に「ia:part」要素を追加する。このとき、図 33に示すように、領域設定受付部 7 1がユーザから矩形領域の選択を受け付け、受け付けた情報をァノ一亍ーシヨン記録部 73が「ia:rectangle」要素に格納する。選択する矩形は他の領域の矩形と重なってもよい。設定された領域には、設定順に番号が振られる。

[0202] 図 34は、ァノーテーシヨン設定受付部 72がァノーテーシヨンの設定を受け付ける画面の例を示す。中央のフレームの画像上には、選択中の領域の矩形が表示されるとともに、矩形の左上に領域の番号が表示されている。中央のフレームの下方には、ァノーテーシヨンを設定するためのフォームが表示されており、それぞれの項目の編集を受け付ける。右側のフレームには設定されたァノーテーシヨンの一覧が表示されており、設定したァノーテーションを画面上で確認することができる。それぞれのァノーテーシヨンには領域の番号が表示されている。

[0203] 中央のフレームには、説明文や画像をァノーテーシヨンとして追加するボタンが設けられており、ユーザがァノーテーシヨンの追加を要求すると、ァノーテーシヨン記録部 73は、ソース DOMツリーの「ia:descr iptionsj 要素の下に「ia:description」要素を追加する。前提技術で説明したように、

「ia:description」要素の要素値や各属性値を「text-of」コネクタを用いて編集可能にマッピングしておけば、ァノーテーシヨン設定受付部 72は、ダィァログなどを提示する必要はなく、表示画面においてィンラインでユーザから編集を受け付けることができる。この場合、ァノーテーシヨン設定受付部 72は、ドラッグ &ドロップなどのマウス操作によるァノーテーシヨン情報の編集を受け付けてもよい。マッピング先のポキヤブラリは、文書処理装置 20が処理可能な任意のタグセットであってよい。例えば、ァノーテーションとして文章を付す場合には、 XHTMLにマッピングすることにより H TMLュニット 50で処理するようにすればよいし、画像や図形などをァノ一亍ーシヨンとして付す場合には、 S VGにマツビングすることにより S V Gユニット 60で処理するようにすればよい。このように、用意された処理系により編集可能な任意の情報をァノーテーシヨンとして付すことができ、かつ、表示画面においてァノーテーシヨンを WY S IWYG編集することができる。 [0204] 図 3 5は、ァノーテーシヨン表示部 7 4が設定されたァノーテーシヨンを表示する画面の例を示す。中央フレームの画像には、矩形が表示されておらず、矩形の中央に領域の番号を示すマークが表示されている。ユーザがマウスポインタをマークに近づけると、ポインタが矩形領域に入ったときにマークを消去し、その領域の矩形とタイトルを表示する。このとき、右側のフレームにおいても、選択中の領域に設定されたァノーテーシヨンが識別可能に表示される。

[0205] 図 3 6は、ァノーテーシヨンが設定された領域がフォーカスされたときの画面の例を示す。マウスポインタが矩形に入ったことにより、領域の矩形とタイトルが表示されている。また、右側のフレームにおいても、該当するァノーテーシヨンの背景色が変更されている。これにより、領域とァノーテ一シヨンの対応関係を分かりやすく表示することができる。逆に、右側のフレー厶においてァノーテーシヨンを選択すると、中央のフレームにおいて対応する領域がフォーカスされる。これにより、双方向の情報検索が可能となり、より分かりやすく利便性の高いィンタフェイスを提供することができる。

[0206] ァノーテーシヨン表示部 7 4は、フォーカスされた領域の輪郭のみを表示してもよいし、全ての領域の輪郭を常時表示してもよい。また、領域の輪郭の表示色、線種、表示タイミングなどを変更可能としてもよい。また、領域の番号を示すマークについても、同様に変更可能としてもよい。ァノーテ一シヨン表示部 7 4は、選択された領域に設定されたァノーテーシヨンを、中央のフレームの画像上に領域の輪郭とともに表示してもよい。

[0207] メタ情報をグループ分けして管理可能としてもよい。この場合、ァノーテーシヨン設定受付部 7 2は、設定するァノーテーシヨンの種別を更に受け付ける。ァノーテーシヨン表示部 7 4は、ァノーテーシヨンの種別に応じて、色や表示態様などを変更し、ァノーテーシヨンの種別を識別可能に表示する。例えば、地図に商店の情報をァノーテーシヨンとして設定する場合に、飲食店は青色、銀行は赤色など、種別に応じて色分けして表示してもよい。これにより、より分かりやすく利便性の高い表示が可能となる。 [0208] ある領域に対するァノーテーシヨンとして画像が設定されており、さらにその画像の領域にァノーテーシヨンが設定されている場合、ァノーテーション表示部 7 4は、領域にマウスポインタが入ったときに、ァノーテーシヨンとして設定されている画像を近傍に表示し、更にその画像に設定されているァノーテーシヨンを選択できるようにしてもよい。このとき、ァノーテーションとして設定されている画像は、例えば 5 0 <½の背景透過画像として表示されてもよい。これにより、より直感的で操作しやすいユーザインタフェイスを実現することができる。

[0209] このような技術は、例えば、アプリケーションのヘルプ画面を作成したり

、仕様書等を作成する場合に利用することができる。また、ニュース記事や日記などのコンテンッに利用することができる。画像の領域とメタ情報の対応を視覚的に分かりやすく提示することができるので、ユーザの利便性を格段に向上させることができる。また、ネットワークなどを介して複数のユーザが画像を介したコミュニケーションを図る手段として、掲示板やチヤットシステムなどにも利用できる。ウェブコンテンツとして画像ァノーテーションポキヤブラリを用いる場合、前提技術で説明したように、本実施の形態の文書処理装置 1 0 0によれば、複数のポキヤブラリで記述された複合文書も適切に処理することができるので、より応用の範囲が広がる。

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

[021 1 ] 実施の形態では、 X M L文書を処理する例について説明したが、本実施の形態の文書処理装置 1 0 0は、他のマークアップ言語、例えば、 S G M L、 H T M Lなどで記述された文書も同様に処理可能である。

産業上の利用可能性

[0212] 本発明は、ァノーテーシヨンを含む文書を処理する文書処理装置に利用可能である。

Claims

請求の範囲

[1 ] 画像の一部の領域に対してァノーテーシヨンを付けるときに、前記領域の指定を受け付ける領域設定受付部と、

前記領域に対するァノーテーシヨンの設定を受け付けるァノーテーシヨン設定受付部と、

前記領域を特定するための情報と、受け付けたァノーテーシヨンの設定とを対応づけてフアイルに記録するァノーテーション記録部と、

を備えることを特徴とする文書処理装置。

[2] 前記ァノーテーシヨン設定受付部は、複数の領域に対して共通のァノーテーションの設定を受付可能とすることを特徴とする請求項 1に記載の文書処理装置。

[3] 前記ァノーテーシヨン設定受付部は、前記ァノーテーシヨンの種別を受け付け、

前記ァノーテーシヨン記録部は、前記ァノーテーシヨンの種別を特定するための情報を更に前記ファイルに記録することを特徴とする請求項 1又は 2 に記載の文書処理装置。

[4] 前記ァノーテーシヨン記録部は、マークアップ言語を用いて前記ァノーテーションを前記ファイルに記録することを特徴とする請求項 1から 3のいずれかに記載の文書処理装置。

[5] 前記ァノーテーシヨン記録部は、前記ァノ亍ーシヨンを記述するためのタグセットを用いて前記ァノ一亍ーションを前記ファィルに記録することを特徵とする請求項 4に記載の文書処理装置。

[6] 前記ァノーテーシヨンを記述するためのタグセッ卜の処理方法を記述した定義ファイルを取得する定義ファイル取得部を更に備え、

前記ァノーテーシヨン記録部は、前記定義ファイルに記述されたコマンドにしたがって、前記ファイルに前記ァノーテーシヨンを記述するための要素を記録することを特徴とする請求項 1から 5のいずれかに記載の文書処理装置。

[7] 画像の一部の領域に対してァノーテーシヨンを付けるときに、前記領域の指定を受け付けるステップと、

前記領域に対するァノーテーシヨンの設定を受け付けるステップと、前記領域を特定するための情報と、受け付けたァノーテーシヨンの設定とを対応づけてファイルに記録するステップと、

を備えることを特徴とする文書処理方法。

[8] 画像の一部の領域に対してァノーテーシヨンを付けるときに、前記領域の指定を受け付ける機能と、

前記領域に対するァノーテーシヨンの設定を受け付ける機能と、前記領域を特定するための情報と、受け付けたァノーテーシヨンの設定とを対応づけてフアイルに記録する機能と、

をコンピュータに実現させることを特徴とする文書処理プログラム。

[9] 画像を取得する画像取得部と、

前記画像の一部の領域に対して付されたァノーテーションが記録されたフアイルを取得するァノーテーシヨン取得部と、

前記画像を表示するとともに、前記領域と前記ァノーテーシヨンとの対応を識別可能な形式で前記ァノーテーシヨンを表示するァノーテーシヨン表示部と、

を備えることを特徴とする文書処理装置。

[10] 前記ァノーテーシヨンの編集を受け付け、編集された前記ァノーテーションを前記ファイルに記録するァノーテーション記録部を更に備えることを特徵とする請求項 9に記載の文書処理装置。

[1 1 ] 前記ァノ一亍ーション表示部は、ボイン亍ィングデバイスのボインタが前記画像の前記領域に入ったときに、その領域に対して付されたァノーテーションを識別可能に表示することを特徴とする請求項 9又は 1 0に記載の文書処理装置。

[12] 前記ァノーテーシヨン表示部は、前記画像に対して付されたァノーテーションを一覧表示する一覧表示画面を更に表示し、前記一覧表示画面において、あるァノーテーシヨンが選択されたときに、そのァノーテーションに対応する領域を識別可能に前記画像上に表示することを特徴とする請求項 9から 1 1のいずれかに記載の文書処理装置。

[13] 前記ァノーテーシヨン表示部は、前記ァノーテーシヨンの種別に応じて、前記ァノーテーションをグループ分けして表示することを特徴とする請求項 9から 1 2のいずれかに記載の文書処理装置。

[14] 前記ファイルは、前記ァノ亍ーシヨンを記述するためのタグセットを用いて前記ァノーテーシヨンを記録していることを特徴とする請求項 9から 1 3 のいずれかに記載の文書処理装置。

[15] 前記ァノーテーシヨンを記述するためのタグセッ卜の処理方法を記述した定義ファイルを取得する定義ファイル取得部を更に備え、

前記ァノーテーシヨン表示部は、前記定義ファイルに記述されたテンプレ一卜にしたがって、前記ファイルに記述された前記ァノーテーシヨンを表示することを特徴とする請求項 1 4に記載の文書処理装置。

[16] 画像を取得するステップと、

前記画像の一部の領域に対して付されたァノーテーションが記録されたフアイルを取得するステップと、

前記画像を表示するとともに、前記領域と前記ァノーテーシヨンとの対応を識別可能な形式で前記ァノーテーシヨンを表示するステップと、

を備えることを特徴とする文書処理方法。

[17] 画像を取得する機能と、

前記画像の一部の領域に対して付されたァノーテーシヨンが記録されたフアイルを取得する機能と、

前記画像を表示するとともに、前記領域と前記ァノーテーシヨンとの対応を識別可能な形式で前記ァノーテーシヨンを表示する機能と、