WO2006051964A1

WO2006051964A1 - データ処理システム、データ処理方法、及び管理サーバ

Info

Publication number: WO2006051964A1
Application number: PCT/JP2005/020891
Authority: WO
Inventors: Toshinobu Kano; Norio Oshima
Original assignee: Justsystems Corporation
Priority date: 2004-11-12
Filing date: 2005-11-14
Publication date: 2006-05-18
Also published as: US20080209572A1; EP1816586A1; JPWO2006051964A1

Abstract

　秘匿データの機密性を確保する技術を提供する。　文書管理システム２１は、文書の編集や表示などの処理を行う文書処理装置１００と、文書の分割や合成を管理する文書管理サーバ２３とを含む。文書処理装置１００は、作成したＸＭＬ文書を文書管理サーバ２３に送信し、文書の保存を依頼する。文書管理サーバ２３は、文書処理装置１００から受け取ったＸＭＬ文書を格納する。このとき、ＸＭＬ文書内に秘匿データが含まれている場合は、秘匿データを別ファイルに分割して保存する。文書管理サーバ２３は、文書処理装置１００から、文書管理サーバ２３に保存されているＸＭＬ文書の取得を要求されると、要求元の文書処理装置１００のユーザを認証し、認証レベルに応じて適宜ＸＭＬ文書に秘匿データを合成し、文書処理装置１００に送信する。

Description

明細書

データ処理システム、データ処理方法、及び管理サーバ技術分野

[0001] 本発明は、データ処理技術に関し、特に、データが格納されたファイルを処理するデータ処理システム及びデータ処理方法、及びそのデータ処理システムに利用可能な管理サーバに関する。

背景技術

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

特許文献 1：特開 2001— 290804号公報

発明の開示

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

[0003] XMLは、複数のユーザによりデータを共有するときの共通形式としての利用が期待されて、る。 XMLで記述された文書などのデータがネットワークを介して多くのュ一ザに共有されるようになると、ファイルに含まれる秘匿すべきデータの機密性を適切に管理する必要性が増してくる。

[0004] 本発明はこうした状況に鑑みてなされたものであり、その目的は、データを格納したファイルに含まれる秘匿データの機密性を確保する技術を提供することにある。課題を解決するための手段

[0005] 本発明のある態様は、データ処理システムに関する。このデータ処理システムは、データを処理するデータ処理装置と、前記データが格納されたファイルを管理する管理サーバと、を含み、前記データ処理装置は、秘匿データを含むファイルを前記管理サーバへ送信する送信部と、前記ファイル中の前記秘匿データを前記管理サーバへ通知する通知部と、を含み、前記管理サーバは、ファイルに含まれる秘匿データを抽出する抽出部と、前記抽出部により抽出された秘匿データに対して識別子を発行する発行部と、ファイル中の前記秘匿データを前記識別子に置換する置換部と、前記秘匿データと前記識別子を対応づけて格納する格納部と、を含むことを特徴とする。このような構成によれば、秘匿データの機密性を適切に確保することができる。

[0006] 前記管理サーバは、前記秘匿データを閲覧する権限を有するユーザ力前記ファィルの取得要求を受け付けたときに、前記格納部力前記秘匿データを読み出して前記ファイルに合成する合成部を更に含んでもよい。これにより、閲覧する権限のあるユーザに対しては、秘匿データを提示することができる。前記合成部は、前記ユーザの権限のレベルに応じて、閲覧を許可すべき秘匿データを選択して前記ファイルに合成してもよい。これにより、閲覧が許可されるユーザには秘匿データを開示し、閲覧が禁止されるユーザには秘匿データを開示しな!、ので、秘匿データの機密性を適切に管理することができる。前記格納部は、前記データが格納されたファイルとは異なるフアイノレであってもよ、。

[0007] 本発明の別の態様は、管理サーバに関する。この管理サーバは、データが格納されたファイルから、他のファイルに移動すべきデータを抽出する抽出部と、前記抽出部により抽出されたデータに対して識別子を発行する発行部と、前記ファイル中の前記抽出されたデータを前記識別子に置換する置換部と、前記抽出されたデータと前記識別子とを対応づけて他のファイルに格納する格納部と、を含むことを特徴とする

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

発明の効果

[0009] 本発明によれば、秘匿データの機密性を確保する技術を提供することができる。

図面の簡単な説明

[0010] [図 1]前提技術に係る文書処理装置の構成を示す図である。

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

[図 3]図 2に示した XML文書を HTMLで記述された表にマッピングする例を示す図である。

[図 4(a)]図 2に示した XML文書を図 3に示した表にマッピングするための定義フアイルの例を示す図である。

[図 4(b)]図 2に示した XML文書を図 3に示した表にマッピングするための定義フアイルの例を示す図である。

[図 5]図 2に示した成績管理ボキヤブラリで記述された XML文書を、図 3に示した対応により HTMLにマッピングして表示した画面の例を示す図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[図 18]アンドゥフレームワークとアンドゥコマンドの詳細を示す図である。

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

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

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

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

[図 23]VCDファイルの例を示す図である。 [図 24]文書処理システムにおいて複合文書をロードする手順を示す図である。

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

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

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

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

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

圆 30]実施の形態に係る文書管理システムの構成を示す図である。

圆 31]本実施の形態の文書処理装置の内部構成を示す図である。

[図 32]文書管理サーバの内部構成を示す図である。

[図 33]文書ファイル管理テーブルの内部データの例を示す図である。

[図 34]ユーザデータベースの内部データの例を示す図である。

[図 35]実施の形態の文書管理システムにおいて処理される XML文書の例を示す図である。

[図 36]図 35に示した XML文書を XHTMLにマッピングして表示 Z編集するための定義ファイルの例を示す図である。

[図 37]図 35に示した XML文書に、図 36に示した定義ファイルを適用して表示した画面の例を示す図である。

[図 38]秘匿データがマークアップされた XML文書の例を示す図である。

[図 39]文書ファイル分割部が、図 38に示した XML文書を分割して生成した表フアイルの例を示す図である。

[図 40]文書ファイル分割部が、図 38に示した XML文書を分割して生成した裏フアイルの例を示す図である。

圆 41]文書ファイル分割部が、図 38に示した XML文書を分割して生成した裏フアイルの別の例を示す図である。

[図 42]図 39に示した表ファイルに、図 40に示した裏ファイルを合成するための定義を記述した定義ファイルを示す図である。

[図 43]生成された合成ファイルの表示例を示す図である。

[図 44]生成された合成ファイルの表示例を示す図である。 [図 45]生成された合成ファイルの表示例を示す図である。

[図 46]生成された合成ファイルの表示例を示す図である。

[図 47]文書ファイル分割部が、図 38に示した XML文書を分割して生成した表フアイルの別の例を示す図である。

[図 48]図 47に示した表ファイルに適用される定義ファイルの例を示す図である。

[図 49]図 47に示した表ファイルに、図 48に示した定義ファイルを適用して表示した画面の例を示す図である。

符号の説明

[0011] 20 文書処理装置、 21 文書管理システム、 22 主制御ユニット、 23 文書管理サーノ、 24 編集ユニット、 30 DOMユニット、 32 DOM提供部、 34 DOM生成部、 36 出力部、 40 CSSユニット、 42 CSS解析部、 44 CSS提供部、 46 レンダリング部、 50 HTMLユニット、 52, 62 制御部、 54, 64 編集部、 56, 66 表示部、 60 SVGユニット、 80 VCユニット、 82 マッピング部、 84 定義ファイル取得部、 8 6 定義ファイル生成部、 100 文書処理装置、 3020 文書保存要求受付部、 3022 文書ファイル受信部、 3024 秘匿データ抽出部、 3026 ID発行部、 3028 文書ファイル分割部、 3030 文書取得要求受付部、 3032 ユーザ認証部、 3034 文書ファイル合成部、 3036 文書ファイル送信部、 3040 文書ファイル管理テーブル、 3 050 文書フアイノレ格納部、 3060 ユーザデータベース。

発明を実施するための最良の形態

[0012] (前提技術）

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

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

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

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

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

[0017] CSSユニット 40は、 CSS解析部 42、 CSS提供部 44、及びレンダリング部 46を含み、 CSSに準拠した表示機能を提供する。 CSS解析部 42は、 CSSの構文を解析するバーサの機能を有する。 CSS提供部 44は、 CSSオブジェクトの実装であり、 DOM ツリーに対して CSSのカスケード処理を行う。レンダリング部 46は、 CSSのレンダリングエンジンであり、 CSSを用いてレイアウトされる HTMLなどのボキヤブラリで記述された文書の表示に用いられる。

[0018] HTMLユニット 50は、 HTMLにより記述された文書を表示又は編集する。 SVGュニット 60は、 SVGにより記述された文書を表示又は編集する。これらの表示 Z編集系は、プラグインの形で実現されており、それぞれ、文書を表示する表示部（Canvas) 56、 66、編集指示を含むイベントを送受信する制御部（Editlet) 52、 62、編集コマンドを受けて DOMに対して編集を行う編集部 (Zone) 54、 64を備える。制御部 52又は 62が外部力も DOMツリーの編集コマンドを受け付けると、編集部 54又は 64が DO Mツリーを変更し、表示部 56又は 66が表示を更新する。これらは、 MVC (Model-Vi ew-Controller)と呼ばれるフレームワークに類似する構成をとつており、概ね、表示部 56及び 66が「View」に、制御部 52及び 62が「Controller」に、編集部 54及び 64と D OMの実体が「Model」に、それぞれ対応する。本前提技術の文書処理装置 20では、 XML文書をツリー表示形式で編集するだけでなく、それぞれのボキヤブラリに応じた編集を可能とする。例えば、 HTMLユニット 50は、 HTML文書をワードプロセッサに類似した方式で編集するためのユーザインターフェースを提供し、 SVGユニット 60は、 SVG文書を画像描画ツールに類似した方式で編集するためのユーザインターフエースを提供する。 [0019] VCユニット 80は、マッピング部 82、定義ファイル取得部 84、及び定義ファイル生成部 86を含み、あるボキヤブラリにより記述された文書を、他のボキヤブラリにマツピングすることにより、マッピング先のボキヤブラリに対応した表示編集用プラグインで文書を表示又は編集するためのフレームワークを提供する。本前提技術では、この機能を、ボキヤブラリコネクション（Vocabulary Connection: VC)と呼ぶ。定義ファイル取得部 84は、マッピングの定義を記述したスクリプトファイルを取得する。この定義ファィルは、ノードごとに、ノード間の対応 (コネクション)を記述する。このとき、各ノードの要素値や属性値の編集の可否を指定してもよい。また、ノードの要素値や属性値を用いた演算式を記述してもよい。これらの機能については、後で詳述する。マツピング部 82は、定義ファイル取得部 84が取得したスクリプトファイルを参照して、 DOM生成部 34にデスティネーションツリーを生成させ、ソースツリーとデスティネーションッリ一の対応関係を管理する。定義ファイル生成部 86は、ユーザが定義ファイルを生成するためのグラフィカルユーザインターフェースを提供する。

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

[0021] 文書処理装置 20により文書を表示又は編集する動作について説明する。文書処理装置 20が処理対象となる文書を読み込むと、 DOM生成部 34が、その XML文書力も DOMツリーを生成する。また、主制御ユニット 22又は編集ユニット 24は、名前空間を参照して文書を記述しているボキヤブラリを判別する。そのボキヤブラリに対応したプラグインが文書処理装置 20にインストールされて、る場合は、そのプラグインをロードして、文書を表示/編集させる。プラグインカ Sインストールされていない場合は、マッピングの定義ファイルが存在するか否かを確認する。定義ファイルが存在する場合、定義ファイル取得部 84が定義ファイルを取得し、その定義に従って、デスティネーシヨンツリーが生成され、マッピング先のボキヤブラリに対応するプラグインにより文書が表示 Z編集される。複数のボキヤブラリを含む複合文書である場合は、後述するように、それぞれのボキヤブラリに対応したプラグインにより、文書の該当箇所がそれぞれ表示 Z編集される。定義ファイルが存在しない場合は、文書のソース又はッリー構造を表示し、その表示画面にぉ、て編集が行われる。

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

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

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

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

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

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

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

[0029] XHTML, MathML、 SVGなどの主要なボキヤブラリに対応したビューヮゃエディタは既に開発されて、るが、図 2に示した文書のようなオリジナルなボキヤブラリで記述された文書に対応したビューヮゃエディタを開発するのは現実的でな、。しかし、上記のように、他のボキヤブラリにマッピングするための定義ファイルを作成すれば、ビューヮゃエディタを開発しなくても、 VC機能を利用して、オリジナルなボキヤブラリで記述された文書を表示 ·編集することができる。

[0030] 図 7は、定義ファイル生成部 86により生成された画面レイアウトの他の例を示す。図 7の例では、成績管理ボキヤブラリで記述された XML文書を表示するための画面に、表 90と、円グラフ 93が作成されている。この円グラフ 93は、 SVGにより記述される。後述するように、本前提技術の文書処理装置 20は、一つの XML文書内に複数のボキヤブラリを含む複合文書を処理することができるので、この例のように、 HTMLで記述された表 90と、 SVGで記述された円グラフ 93とを、一つの画面上に表示することができる。

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

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

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

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

[0035] 図 9は、文書処理装置 20により編集される XML文書の他の例を示す。図 9に示した XML文書では、 SVG文書の「foreignObject」タグの中に XHTML文書が埋め込まれており、さら〖こ、 XHTML文書の中に MathMLで記述された数式が入っている。このような場合、編集ユニット 24が、名前空間を参照して、適切な表示系に描画作業を振り分ける。図 9の例では、編集ユニット 24は、まず、 SVGユニット 60に四角形を描画させ、つづいて、 HTMLユニット 50に XHTML文書を描画させる。さらに、図示しない MathMLユニットに、数式を描画させる。こうして、複数のボキヤブラリを包含する複合文書が適切に表示される。表示結果を図 10に示す。

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

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

[0038] データがテキストベースで記述されることの他の利点として、例えば、複合文書中の、あるボキヤブラリにより記述される部分において、同一文書内の他のボキヤブラリで記述された部分のデータを参照してもよい。また、文書内で検索を実行する時に、 S VGなどの図に埋め込まれた文字列も検索対象とすることができる。 [0039] あるボキヤブラリにより記述された文書内に、他のボキヤブラリのタグを用いてもよい。この XML文書は、妥当（valid)ではないが、整形式 (welH rmed)であれば、有効な XML文書として処理可能である。この場合、挿入された他のボキヤブラリのタグは、定義ファイルによりマッピングされてもよい。例えば、 XHTML文書中に、「重要」、「最重要」などのタグを使用し、これらのタグで囲まれた部分を強調表示してもよ、し、重要度の順にソートして表示してもよ、。

[0040] 図 10に示した編集画面において、ユーザにより文書が編集されると、編集された部分を担当するプラグイン又は VCユニット 80がソースツリーを変更する。ソースツリーには、ノードごとにミューテーシヨンイベントのリスナーを登録できるようになっており、通常は、各ノードが属するボキヤブラリに対応したプラグインの表示部又は VCュ-ット 80がリスナーとして登録される。 DOM提供部 32は、ソースツリーが変更されると、変更されたノードから上位の階層へたどって、登録されたリスナーがあれば、そのリスナ一へミューテーシヨンイベントを発行する。例えば、図 9に示した文書において、く html >ノードの下位のノードが変更された場合、く html >ノードにリスナーとして登録された HTMLユニット 50にミューテーシヨンイベントが通知されるとともに、その上位のく svg>ノードにリスナーとして登録された SVGユニット 60にもミューテーシヨンイベントが通知される。このとき、 HTMLユニット 50は、変更されたソースツリーを参照して表示を更新する。 SVGユニット 60は、自身のボキヤブラリに属するノードが変更されて!/、な!/、ので、ミューテーシヨンイベントを無視してもよ！/、。

[0041] 編集の内容によっては、 HTMLユニット 50による表示の更新に伴って、全体のレイアウトが変わる可能性がある。この場合は、画面のレイアウトを管理する構成、例えば最上位のノードの表示を担当するプラグインにより、プラグインごとの表示領域のレイアウトが更新される。例えば、 HTMLユニット 50による表示領域が以前より大きくなつた場合、 HTMLユニット 50は、まず自身の担当する部分を描画して、表示領域の大きさを決定する。そして、画面のレイアウトを管理する構成に、変更後の表示領域の大きさを通知し、レイアウトの更新を依頼する。画面のレイアウトを管理する構成は、通知を受けて、プラグインごとの表示領域を再レイアウトする。こうして、編集された部分の表示が適切に更新されるとともに、画面全体のレイアウトが更新される。 [0042] つづいて、前提技術の文書処理装置 20を実現する機能構成について更に詳細に説明する。以下の説明では、クラス名などを記載する際には、英字をそのまま用いて記載することにする。

[0043] A.概要

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

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

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

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

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

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

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

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

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

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

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

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

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

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

文書処理システムの実施例は、図 11— 29に関連して明らかにされる。

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

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

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

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

[0059] 1.実行環境

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

[0060] Programlnvoker 103には、プラグインサブシステム 104、コマンドサブシステム 105 、及び Resource (リソース）モジュール 109などのいくつかのコンポーネントがアタッチされている。これらの構成については、以下に詳述する。

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

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

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

[0063] 所望の機能性を実現する個々の機能は、 Service (サービス） 1042の形でシステムに追加される。利用可能な Servicel042のタイプは、 Application (アプリケーション）サ一ビス、 ZoneFactory (ゾーンファクトリ：ゾーン生成部） Service, Editlet (エディットレツト：編集部） Service、 CommandFactory (コマンドファクトリ：コマンド生成部） Serviceゝ C onnectXPath (コネクト XPath:XPath管理部） Service、 CSSComputation (CSSコンビユーテーシヨン： CSS計算部） Serviceなどを含む力これらに限定されない。これらの Service,及びシステムの他の構成とそれらとの関係は、文書処理システムについてのよりよい理解のために、以下に詳述される。

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

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

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

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

[0067] コマンドサブシステム 105のキーとなるコンポーネントは、選択的にコマンドを与え、実行するように作用する Commandlnvoker (コマンドインボー力：コマンド起動部） 105 1である。図 11 (b)には、 1つの Commandlnvokerのみが示されているが、 1以上の Co mmandlnvokerが使用されてもよぐ 1以上のコマンドが同時に実行されてもよい。 Com mandlnvokerl051は、コマンドを実行するために必要な機能及びクラスを保持する。動作において、実行されるべき Command (コマンド：命令） 1052は、 Queue (キュー） 1 053に積まれる。 Commandlnvokerは、連続的に実行するコマンドスレッドを生成する。 Commandlnvoker内で既に実行中の Commandがなければ、 Commandlnvoker 1051 により実行されるように意図された Commandl052が実行される。 Commandlnvokerが既にコマンドを実行している場合、新しい Commandは、 Queuel053の最後に積まれる。しかしながら、それぞれの Commandlnvokerl051では、一度に 1つの Commandのみが実行される。指定された Commandの実行に失敗した場合、 CommandlnvokerlO 51は例外処理を実行する。

[0068] Commandlnvoker 1051により実行される Commandの型は、 UndoableCommand (取消可能コマンド） 1054、 AsynchronousCommand (非同期コマンド） 1055、及び VCCo mmand (VCコマンド） 1056を含む力これらに限定されない。 UndoableCommand 10 54は、ユーザが望めば、その Commandの結果を取り消すことが可能な Commandである。 UndoableCommandの例として、切り取り、コピー、テキストの挿入、などがある。動作において、ユーザが文書の一部を選択し、その部分に切り取りコマンドを適用するとき、 UndoableCommandを用いることにより、切り取られた部分は、必要であれば、「切り取られてヽな、」ようにすることができる。 [0069] VCCommandl056は、ボキヤブラリコネクション記述子（Vocabulary Connection De scriptor: VCD)スクリプトファイルに格納される。これらは、プログラマにより定義されうるユーザ指定の Commandである。 Commandは、例えば、 XMLフラグメントを追加したり、 XMLフラグメントを削除したり、属性を設定したりするための、より抽象的な Comm andの組合せであってもよい。これらの Commandは、特に、文書の編集に焦点を合わせている。

[0070] AsynchronousCommandl055は、文書のロードや保存など、システムよりの Comman dであり、 UndoableCommandや VCCommandとは別に、非同期的に実行される。 Async hronousCommandは、 UndoableCommandではないので、取り消すことはできない。

[0071] c)リソース

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

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

文書処理システムの第 2の主要な特徴であるアプリケーションコンポーネント 102は、実行環境 101において実行される。アプリケーションコンポーネント 102は、実際の文書と、システム内における文書の様々な論理的、物理的な表現を含む。さらに、ァプリケーシヨンコンポーネント 102は、文書を管理するために使用されるシステムの構成を含む。アプリケーションコンポーネント 102は、さらに、 UserApplication (ユーザァプリケーシヨン） 106、アプリケーションコア 108、ユーザインタフェイス 107、及び Core Component (コアコンポーネント） 110を含む。

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

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

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

CoreComponentl 10は、複数の Pane (ペイン）の間で文書を共有する方法を提供する。後で詳述するように、 Paneは、 DOMツリーを表示し、画面の物理的なレイアウトを扱う。例えば、物理的な画面は、個々の情報の断片を描写する画面内の複数の Pane 力もなる。ユーザから画面上に見える文書は、 1又はそれ以上の Paneに出現しうる。また、 2つの異なる文書が画面上で 2つの異なる Paneに現れてもよ!、。

[0075] 図 11 (c)に示されるように、画面の物理的なレイアウトもツリーの形式になっている。

Paneは、 RootPane (ルートペイン） 1084にもなり得るし、 SubPane (サブペイン） 1085 にもなり得る。 RootPanel084は、 Paneのツリーの根に当たる Paneであり、 SubPane 10 85は、 RootPanel084以外の任意の Paneである。

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

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

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

[0078] DocumentManagerl081の様々な態様を以下に詳述する。 DocumentManager 108 1は、 Documentl082を管理する。 DocumentManagerl081は、 RootPanel084、 Sub Pane 1085, ClipBoard (クリップボード）ユーティリティ 1087、及び Snapshot (スナップショット）ユーティリティ 1088にも接続される。 ClipBoardユーティリティ 1087は、ユーザがクリップボードに加えることを決定した文書の部分を保持する方法を提供する。例えば、ユーザが、文書の一部を切り取り、後で再考するために新規文書にそれを保存することを望んだとする。このような場合、切り取られた部分力 SClipBoardに追加される。

[0079] つづいて、 Snapshotユーティリティ 1088についても説明する。 Snapshotユーティリティ 1088は、アプリケーションがある状態力も別の状態まで移行するときに、アプリケーシヨンの現在の状態を記憶することを可能とする。

[0080] d)ユーザインタフェイス

アプリケーションコンポーネント 102の別の構成は、ユーザがシステムと物理的に対話する手段を提供するユーザインタフェイス 107である。例えば、ユーザインタフェイスは、ユーザが文書をアップロードしたり、削除したり、編集したり、管理したりするために使用される。ユーザインタフェイスは、 Frame (フレーム） 1071、 MenuBar (メ -ュ一バー） 1072、 StatusBar (ステータスバー） 1073、及び URLBar(URLバー） 1074 を含む。

[0081] Framel071は、一般に知られているように、物理的な画面のアクティブな領域であるとみなされる。 MenuBarl072は、ユーザに選択を提供するメニューを含む画面領域である。 StatusBarl073は、アプリケーションの実行状態を表示する画面領域である。 URLBarl074は、インターネットをナビゲートするために URLアドレスを入力する領域を提供する。

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

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

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

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

[0085] 1. DOMモデノレ及びゾーン

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

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

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

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

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

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

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

[0091] Zone209に対応する Canvas210は、 Editlet206を使用して生成される。文書の DO Mは、 Editlet206及び Canvas210を使用して編集される。元の文書の完全性を維持するために、 Editlet206及び Canvas210は、 Zone209における 1以上の Nodeに対応する Facetを使用する。これらの Serviceは、 Zone及び DOM内の Nodeを直接操作しない。 Facetは、 Command207を利用して操作される。

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

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

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

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

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

[0095] 例えば、ユーザが、文書中の単語を別の単語に置換するコマンドを実行したとする。その後、ユーザは考え直し、元の単語に戻すことを決定したとする。アンドゥサブシステム 212は、このような操作を支援する。 UndoManager2121は、このような Undoabl eEdit (アンドゥアプルエディット：取消可能な編集） 2122の操作を保持する。 [0096] 5.カーソノレサブシステム

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

[0097] 6.ビュー

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

[0098] D.ボキヤブラリコネクション

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

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

[0100] 例えば、文書は 2以上のマークアップ言語により記述されてもよい。文書は、例えば、 XHTML (.extensible HyperText Markup Language)、 ¾ V"G (Scalable Vector Grap hies)、 MathML (Mathematical Markup Language)、その他のマークアップ言語により記述されてもよい。換言すれば、マークアップ言語は、 XMLにおけるボキヤブラリゃタグセットと同様に見なされてもよい。

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

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

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

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

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

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

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

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

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

[0109] VocabularyConnectionプラグイン 301は、適切な Vocabulary305の文書に対応した、 Zone209又は Pane211のための適切な VCCanvas (ボキヤブラリコネクションキャンバス） 310を生成する。 VocabularyConnection301を用いて、ソース DOMツリー内の Zone209に対する変更は、変換ルールにより、別の DOMツリー 306の対応する Zone に伝達される。変換ルールは、ボキヤブラリコネクション記述子（Vocabulary Connecti on Descriptor: VCD)の形式で記述される。このようなソース DOMとデスティネーション DOMの間の変換に対応するそれぞれの VCDファイルにつ!/、て、対応する VCMa nager (ボキヤブラリコネクションマネージャ） 302が生成される。

[0110] 2. Connector

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

[0111] Connector304は、ツリー構造を形成するために、論理的にリンクされる。 Connector 304により形成されたツリーは、 ConnectorTree (コネクタツリー）と呼ばれる。 Connect or304は、 ConnectorFactory (コネクタファクトリ：コネクタ生成部） 303と呼ばれる Servi ceを用いて生成される。 ConnectorFactory303は、ソース文書から Connector304を生成し、それらをリンクして ConnectorTreeを形成する。 VocabularyConnectionManage r302は、 ConnectorFactory303を保持する。

[0112] 前述したように、ボキヤブラリは名前空間におけるタグのセットである。図示されるように、 Vocabulary305は、 VocabularyConnection301によって文書に対して生成される。これは、文書ファイルを解析し、ソース DOMとデスティネーション DOMの間の写像のための適切な VocabularyConnectionManager302を生成することにより行われる。さらに、 Connectorを生成する ConnectorFactory303と、 Zone209を生成する ZoneF actory205と、 Zone内のノードに対応する Canvasを生成する Editlet206との間の適切な関係が作られる。ユーザがシステム力も文書を処分又は削除するとき、対応する Vo cabularyConnectionManager302が肖 lj除される。

[0113] Vocabulary305は、 VCCanvas310を生成する。さらに、 Connector304及びデステイネーシヨン DOMツリー 306が対応して生成される。

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

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

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

[0117] 3. DestinationZone、 Pane、及びし anvas

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

[0118] VCCanvasが作成されると、対応する DestinationPane307が生成される。さらに、関連する DestinationCanvas308と、対応する BoxTree309が生成される。同様に、 VCC anvas310も、ソース文書に対する Pane211及び Zone209に関連づけられる。

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

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

ボキヤブラリコネクション (VC)サブシステム 300の要素として、ボキヤブラリコネクシヨン (VC)コマンドサブシステム 313がある。ボキヤブラリコネクションコマンドサブシステム 313は、ボキヤブラリコネクションサブシステム 300に関連した命令の実行のために使用される VCCommand (ボキヤブラリコネクションコマンド） 315を生成する。 VCCo mmandは、内蔵の CommandTemplate (コマンドテンプレート） 318を使用して、及び Z 又は、スクリプトサブシステム 314においてスクリプト言語を使用してスクラッチカもコマンドを生成することにより、生成することができる。

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

[0122] 5. XPathサブシステム？&1^サブシステム316は、文書処理システムの重要な構成であり、ボキヤブラリコネクシヨンの実現を支援する。 Connector304は、一般に xpath情報を含む。上述したように、ボキヤブラリコネクションのタスクの 1つは、ソース DOMツリーの変化をデステイネーシヨン DOMツリーに反映させることである。 xpath情報は、変更 Z修正を監視されるべきソース DOMツリーのサブセットを決定するために用いられる 1以上の xpath 表現を含む。

[0123] 6.ソース DOMツリー、デスティネーション DOMツリー、及び ConnectorTreeの概要ソース DOMツリーは、別のボキヤブラリに変換される前のボキヤブラリで文書を表現した DOMツリー又は Zoneである。ソース DOMツリーのノードは、ソースノードと呼ばれる。

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

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

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

実用のためには、プログラムはユーザ力のコマンドに応答しなければならない。ィベントは、プログラム上で実行されたユーザアクションを記述し実行する方法である。多くの高級言語、例え «Java (登録商標）は、ユーザアクションを記述するイベントに頼っている。従来、プログラムは、ユーザアクションを理解し、それを自身で実行するために、積極的に情報を集める必要があった。これは、例えば、プログラムが自身を初期化した後、ユーザが画面、キーボード、マウスなどでアクションを起こしたときに適切な処理を講じるために、ユーザのアクションを繰り返し確認するループに入ることを意味する。し力しながら、このプロセスは扱いにくい。さらに、それは、ユーザが何かをするのを待つ間、 CPUサイクルを消費してループするプログラムを必要とする。 [0127] 多くの言語が、異なるパラダイムを採用することにより、これらの問題を解決している。そのうちの一つは、現代の全てのウィンドウシステムの基礎となっている、イベントドリブンプログラミングである。このパラダイムでは、全てのユーザアクションは、「ィベント」と呼ばれる抽象的な事象の集合に属する。イベントは、十分詳細に、特定のユーザアクションを記述する。プログラムがユーザにより生成されたイベントを積極的に収集するのではなぐ監視すべきイベントが生じたときに、システムがプログラムに通知する。この方法によりユーザとの対話を扱うプログラムは「イベントドリブン」であると言われる。

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

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

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

[0131] 1.ボキヤブラリコネクション外のイベントの取り扱い

イベントは、イベントスレッドを用いて渡される。 Canvas210は、イベントを受け取ると、その状態を変更する。必要であれば、 Commandl052力 Canvas210により Comman dQueuel053にポストされる。

[0132] 2.ボキヤブラリコネクション内のイベントの取り扱い VocabularyConnectionプラグイン 301を用いて、 DestinationCanvasの一例である X HTMLCanvasl l06は、発生したイベント、例えば、マウスイベント、キーボードィベント、ドラッグアンドドロップイベント、及びボキヤブラリに特有のイベントなどを受け取る。これらのイベントは、コネクタ 304に通知される。より詳細には、図 21 (b)に図示されるように、 VocabularyConnectionプラグイン 301内のイベントフローは、 SourcePanel lO 3、 Vし Canvas丄 104、 DestinationPanel lOo、 DestinationCanvasの一 f列で fcoDestin ationCanvasl 106、デスティネーション DOMツリー及び ConnectorTreeを通過する。

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

Programlnvokerl03及びそれと他の構成との関係は、図 14 (a)に更に詳細に示される。 Programlnvokerl03は、文書処理システムを開始するために実行される実行環境中の基本的なプログラムである。図 11 (b)及び図 11 (c)に図示されるように、 User Application 106、 ¾erviceBrokerl04l、 Commandlnvokerl051、及び Resourcel09 は、全て Programlnvokerl03に接続される。前述したように、アプリケーション 102は、実行環境中で実行されるコンポーネントである。同様に、 ServiceBrokerl041は、システムに様々な機能をカ卩えるプラグインを管理する。他方、 Commandlnvokerl051は、ユーザにより提供される命令を実行して、コマンドを実行するために使用されるクラス及びファンクションを保持する。

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

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

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

[0136] Serviceの例は、図 14 (d)に示される。アプリケーション Serviceの Categoryにおいては、システムユーティリティが対応する ServiceProviderの例である。同様に、 Editlet20 6は Categoryであり、 HTMLEditlet及び SVGEditletは対応する ServiceProviderである。 ZoneFactory205は、 Serviceの別の Categoryであり、対応する ServiceProvider (図示せず)を有する。

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

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

図 14 (e)は、 Programlnvokerl03と UserApplicationl06との関係についての更なる詳細を示す。必要な文書やデータなどは、ストレージからロードされる。必要なプラグインは、全て ServiceBrokerl041上にロードされる。 ServiceBrokerl041は、全てのプラグインを保持し管理する。プラグインは、システムに物理的に追加することができ、又、その機能はストレージカもロードすることができる。プラグインの内容がロードされると、 ServiceBrokerl041は、対応するプラグインを定義する。つづいて、対応する Us erApplicationl06が生成され、実行環境 101にロードされ、 Programlnvokerl03にァタツチされる。

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

図 15 (a)は、 Programlnvokerl03上にロードしたアプリケーションサービスの構成についての更なる詳細を示す。コマンドサブシステム 105のコンポーネントである Comm andlnvokerl051は、 Programlnvokerl03内の Commandl052を起動又は実行する。 Commandl052は、文書処理システムにおいて、 XMLなどの文書を処理し、対応する XMLDOMツリーを編集するために用いられる命令である。 Commandlnvokerl05 1は、 Commandl052を実行するために必要なクラス及びファンクションを保持する。

[0140] ServiceBrokerl041も、 Programlnvokerl03内で実行される。 UserApplicationl06 は、ユーザインタフェイス 107及び CoreComponentl lOに接続される。 CoreCompone ntl lOは、全ての Paneの間で文書を共有する方法を提供する。 CoreComponentl lO は、さらにフォントを提供し、 Paneのためのツールキットの役割を果たす。

[0141] 図 15 (b)は、 Framel071、 MenuBarl072、及び StatusBarl073の関係を示す。

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

図 16 (a)は、全ての文書、及び文書の一部及び文書に属するデータを保持するァプリケーシヨンコア 108についての更なる説明を提供する。 CoreComponentl lOは、文書 1082を管理する DocumentManagerl081にアタッチされる。 DocumentManager 1081は、文書処理システムに関連づけられたメモリに格納される全ての文書 1082 の所有者である。

[0143] 画面上の文書の表示を容易にするために、 DocumentManagerl081は RootPanel 084にも接続される。 ClipBoardl087、 SnapShotl088、 Drag&Drop601、及び Overla y602の機能も、 CoreComponentl 10にアタッチされる。

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

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

図 17 (a)は、 DocumentManagerl081の更なる説明と、 DocumentManagerにおいて文書が構成され保持される様子を示す。図 11 (b)に示したように、 DocumentManager 1081は、文書 1082を管理する。図 17 (a)に示される例において、複数の文書のうちの 1つは RootDocument (ルート文書） 701であり、残りの文書は SubDocument (サブ文書） 702である。 DocumentManager 1081は、 RootDocument701に接続され、 Root Document701は、全ての SubDocument702に接続される。

[0146] 図 12及び図 17 (a)に示すように、 DocumentManager 1081は、全ての文書 1082を管理するオブジェクトである DocumentContainer203に結合される。 DOMService703 及び IOManager704を含むツールキット 201 (例えば XMLツールキット）の一部を开成するツールも、 DocumentManagerl081に供給される。再び図 17 (a)を参照して、 DOMService703は、 DocumentManagerl081により管理される文書に基づいた DO Mツリーを生成する。各 Document705は、それが RootDocument701であっても SubD ocument702であっても、対応する DocumentContainer203によって管理される。

[0147] 図 17 (b)は、文書 A— Eが階層的に配置される様子を示す。文書 Aは RootDocume ntである。文書 B— Dは、文書 Aの SubDocumentである。文書 Eは、文書 Dの SubDocu mentである。図 17 (b)の左側は、これと同じ文書の階層が画面上に表示された例を示す。 RootDocumentである文書 Aは、基本フレームとして表示される。文書 Aの SubD ocumentである文書 B— Dは、基本フレーム Aの中のサブフレームとして表示される。文書 Dの SubDocumentである文書 Eは、サブフレーム Dのサブフレームとして画面に表示される。

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

[0149] UndoWrapper 707は、 DocumentContainer 203内の SubDocumentに関連するアンドゥオブジェクトをラップし、それらを RootDocumentに関連するアンドゥオブジェクトに結合させる。 UndoWrapper707は、 UndoableEditAcceptor (アンドゥァブルエデイットァクセプタ：アンドゥ可能編集受付部） 709に利用可能なアンドゥオブジェクトの収集を実行する。

[0150] UndoManager706及び UndoWrapper707は、 UndoableEditAcceptor709及び Undo ableEditSource (アンドゥァブルエディットソース） 708〖こ接続される。当業者には理解されるように、 Document705が UndoableEditSource708であってもよぐ取消可能な編集オブジェクトのソースであってもよ、。

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

図 18 (a)及び図 18 (b)は、アンドゥフレームワーク及びアンドゥコマンドについて更なる詳細を提供する。図 18 (a)に示されるように、 UndoCommand801、 RedoComman d802、及び UndoableEditCommand803は、図 11 (b)に示したように Commandlnvoke r 1051に積むことができるコマンドであり、順に実行される。 UndoableEditCommand8 03は、 UndoableEditSource708及び UndoableEditAcceptor709に更にアタッチされる。「foo」 Editし ommand804及び「bar」 Editし ommand805i 、 UndoableEditCommand の例である。

[0152] 1. UndoableEditCommandの実行

図 18 (b)は、 UndoableEditCommandの実行を示す。まず、ユーザが編集コマンドを使用して Document705を編集すると仮定する。第 1ステップ S 1では、 UndoableEditA cceptor709力 Document705の DOMツリーである UndoableEditSource708にァタツチされる。第 2ステップ S2では、ユーザにより発行されたコマンドに基づいて、 Docum ent705が DOMの APIを用いて編集される。第 3ステップ S3では、ミューテーシヨンィベントのリスナー力変更がなされたことを通知される。すなわち、このステップでは、 DOMツリーの全ての変更を監視するリスナーが編集操作を検知する。第 4ステップ S 4では、 UndoableEditが UndoManager706のオブジェクトとして格納される。第 5ステツプ S5では、 UndoableEditAcceptor709が UndoableEditSource708からデタツチされる。 UndoableEditSource708は、 Document705自身であってもよい。

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

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

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

[0155] より詳細には、文書はストレージ 901からロードされる。文書の DOMツリー 902が生成される。文書を保持するための、対応する DocumentContainer903が生成される。 DocumentContainer903は、 DocumentManager904にアタッチされる。 DOMツリーは、ルートノードと、ときには複数のセカンダリノードを含む。

[0156] 一般に、このような文書は、テキスト及びグラフィクスの双方を含む。したがって、 D OMツリーは、例えば、 XHTMLサブツリーだけでなく SVGサブツリーを有してもよい。 XHTMLサブツリーは、 XHTMLの ApexNode905を有する。同様に、 SVGサブッリーは、 SVGの ApexNode906を有する。

[0157] ステップ 1では、 ApexNode906力画面の論理的なレイアウトである Pane907にァタツチされる。ステップ 2では、 Pane907は、 PaneOwner (ペインオーナー：ペインの所有者） 908である CoreComponentに、 ApexNode906のための ZoneFactoryを要求する。ステップ 3では、 PaneOwner908は、 ZoneFactoryと、 ApexNode906のための CanvasF actoryである Editletとを返す。

[0158] ステップ 4では、 Pane907力 one909を生成する。 Zone909は Pane907にアタッチされる。ステップ 5では、 Zone909がそれぞれのノードに対して Facetを生成し、対応するノードにアタッチする。ステップ 6では、 Pane907力 Canvas910を生成する。 Canv as910は Pane907にアタッチされる。 Canvas910には様々な Commandが含まれる。ステツプ 7では、 Canvas910が文書を画面にレンダリングするためのデータ構造を構築する。 XHTMLの場合、これはボックスツリー構造を含む。

[0159] 1. Zoneの MVC

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

[0160] L.文書の表現

図 20を用いて、文書及びその様々な表現の例について以下に説明する。この例で使用される文書は、テキストと画像の双方を含む。テキストは、 XHTMLを用いて表され、画像は、 SVGを用いて表される。図 20は、文書のコンポーネント及び対応するォブジエタトの関係の MVC表現を詳細に示す。この例において、 DocumentlOOlは、 Document 1001を保持する DocumentContainer 1002にアタッチされる。文書は DO Mツリー 1003により表現される。 DOMツリーは、 ApexNodel004を含む。

[0161] ApexNodeは、黒丸で表される。頂点でないノードは、白丸で表される。ノードを編集するために用いられる Facetは、三角形で表され、対応するノードにアタッチされる。文書がテキストと画像を有するので、この文書の DOMツリーは、 XHTML部分と SV G部分を含む。 ApexNodel004は、 XHTMLサブツリーの最上のノードである。これは、文書の XHTML部分の物理的な表現のための最上 Paneである XHTMLPanelO 05にアタッチされる。 ApexNodel004は、文書の DOMツリーの一部である XHTMLZ onel006にもアタッチされる。

[0162] Nodel004に対応する Facetも、 XHTMLZonel006にアタッチされる。 XHTMLZone 1006は、 XHTMLPanel005にアタッチされる。 XHTMLEditletは、文書の論理的な表現である XHTMLCanvasl007を生成する。 XHTMLCanvasl007は、 XHTMLPane 1005にアタッチされる。 XHTMLCanvasl007は、 Document 1001の XHTMLコンポ一ネントのための BoxTreel009を生成する。文書の XHTML部分を保持し描画するために必要な様々な Commandl008も、 XHTMLCanvasl007に追加される。

[0163] 同様に、文書の SVGサブツリーの ApexNodelOlOは、文書の SVGコンポーネントを表現する Document 1001の DOMツリーの一部である SVGZone 1011にアタッチされる。 ApexNodelOlOは、文書の SVG部分の物理的な表現の最上の Paneである SV GPanelO 13にアタッチされる。文書の SVG部分の論理的な表現を表す SVGCanvas 1012は、 SVGEditletにより生成され、 SVGPanel013にアタッチされる。画面上に文書の SVG部分をレンダリングするためのデータ構造及びコマンドは、 SVGCanvasにアタッチされる。例えば、このデータ構造は、図示されるように、円、線、長方形などを含んでもよい。

[0164] 図 20に関連して説明された文書例の表現の一部について、図 21 (a)に関連して、前述した MVCパラダイムを用いて更に説明する。図 21 (a)は、文書 1001の XHTM Lコンポーネントにおける MVの関係を簡略化して示す。モデルは、 DocumentlOOl の XHTMLコンポーネントのための XHTMLZone 1101である。 XHTMLZoneのッリ一には、いくつかの Node及びそれらに対応する Facetが含まれる。対応する XHTMLZon e及び Paneは、 MVCパラダイムのモデル（M)部分の一部である。 MVCパラダイムのビュー（V)部分は、 DocumentlOOlの XHTMLコンポーネントの、対応する XHTML Canvasl 102及び BoxTreeである。文書の XHTML部分は、 Canvasと、それに含まれる Commandを使用して画面に描写される。キーボードやマウス入力などのイベントは、図示されるように、逆方向へ進む。

[0165] SourcePaneは、更なる機能、すなわち、 DOMの保有者としての役割を有する。図 2 1 (b)は、図 21 (a)に示した DocumentlOOlのコンポーネントに対するボキヤブラリコネクシヨンを提供する。 DOMホルダーとして機能する SourcePanel l03は、文書のソース DOMツリーを含む。 ConnectorTreeは、 ConnectorFactoryにより生成され、デスティネーシヨン DOMの保有者としても機能する DestinationPanel 105を生成する。 D estinationPanel 105は、 XHTMLDestinationCanvasl 106としてボックスツリーの形式でレイアウトされる。

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

図 22 (a) - (c)は、それぞれ、プラグインサブシステム、ボキヤブラリコネクション、及び Connectorに関連する更なる詳細を示す。プラグインサブシステムは、文書処理システムに機能を追加又は交換するために用いられる。プラグインサブシステムは、 Ser viceBrokerl041を含む。 ServiceBrokerl041にアタッチされる ZoneFactoryServicel 201は、文書の一部に対する Zoneを生成する。 EditletServicel202も、 ServiceBroke rl041にアタッチされる。 EditletServicel202は、 Zone中の Nodeに対応する Canvasを生成する。

[0167] ZoneFactoryの例は、 XHTMLZone及び SVGZoneをそれぞれ生成する XHTMLZone Factoryl211及び SVGZoneFactoryl 212である。文書例に関連して前述したように、文書のテキストコンポーネントは、 XHTMLZoneを生成することにより表現されてもよ!ヽし、画像は SVGZoneを用いて表現されてもよい。 EditletServiceの例は、 XHTMLEditle U221及び SVGEditletl222を含む。

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

[0169] Template317は、いくつかのノードの変換ノレ一ノレを表す。ボキヤブラリコネクション記述子 (VCD)ファイルは、特定のパス又はルールを満たす要素又は要素の集合を他の要素に変換するいくつかのルールを表す Templateのリストである。 Template317 及び CommandTemplate318は、全て VCManager302にアタッチされる。 VCManager は、 VCDファイル中の全てのセクションを管理するオブジェクトである。 1つの VCDフアイルに対して、 1つの VCManagerオブジェクトが生成される。

[0170] 図 22 (c)は、 Connectorに関連する更なる詳細を提供する。 ConnectorFactory303 は、ノ、 ' ~~ス文善力ら Connectorを生成する。 ConnectorFactory303は、 Vocabulary ^ T emplateゝ及び ElementTemplateにアタッチされ、それぞれ、 VocabularyConnectorゝ T emplateConnector、 Elementし onnector 生成 *f る。

[0171] VCManager302は、 ConnectorFactory303を保持する。 Vocabularyを生成するために、対応する VCDファイルが読み込まれる。こうして、 ConnectorFactory303が生成れる。このし onnectorFactory30dは、 Zoneを生成する ZoneFactory及びし anvasを生成する Editletに関連する。

[0172] つづ!/、て、ターゲットボキヤブラリの EditletServiceが、 VCCanvasを生成する。 VCCa nvasも、ソース DOMツリー又は Zoneにおける ApexNodeの Connectorを生成する。必要に応じて、子の Connectorが再帰的に生成される。 ConnectorTreeは、 VCDフアイル中のテンプレートの集合により生成される。

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

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

特定の文書と関係する処理を説明する例を続ける。ドキュメントタイトルのある「MyS ampleXML」というタイトルの文書が文書処理システムにロードされる。図 23は、「MySa mpleXMLjファイルのための、 VCManager及び ConnectorFactoryTreeを用いた VCD スクリプトの例を示す。スクリプトファイル中のボキヤブラリセクシヨン、テンプレートセクシヨンと、 VCManagerにおける対応するコンポーネントが示される。タグ「vcd:vocabula ry」において、属'性「match_^¾「sample:root」、「label」は「MySampleXML」、「caU— temp late」は sample template となって、る。

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

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

図 24— 28は、文書「MySampleXML」のロードについての詳細な記述を示す。図 24 (a)に示されるステップ 1では、文書がストレージ 1405からロードされる。 DOMService は、 DOMツリー及び DocumentManagerl406と対応する DocumentContainerl401 を生成する。 DocumentContainerl401は、 DocumentManagerl406にアタッチされる。文書は、 XHTML及び MySampleXMLのサブツリーを含む。 XHTMLの ApexNode 1403は、タグ「xhtml:html」が付された XHTMLの最上のノードである。「MySampleX MLJの ApexNodel404は、タグ「sample:root」が付された「MySampleXML」の最上ノードである。

[0177] 図 24 (b)に示されるステップ 2では、 RootPaneが文書の XHTMLZone、 Facet,及び Canvasを生成する。 Panel407、 XHTMLZonel408、 XHTMLCanvasl409、及び Bo xTreel410力 ApexNodel403に対応して生成される。

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

[0179] 図 25に示されるステップ 4では、 SubPaneが「sample:root」を扱うことができ、適切な

Zoneを生成 Γ會な ZoneFactory 得る。この ZoneFactoryi；、 ZoneFactory 行 n丁能な Vocabulary内にある。それは、「MySampleXML」の VocabularySectionの内容を含む。

[0180] 図 26に示されるステップ 5では、「MySampleXML」に対応する Vocabularyが Default Zonel601を生成する。対応する Editletが生成され、対応する Canvasを生成するために SubPanel501が提供される。 Editletは、 VCCanvasを生成する。そして、それは T emplate¾ection 呼ふ。 Connectorractory freet a.3；れて、る。し onnectorFactoryTr eeは、 ConnectorTreeとな全飞の Connectorを生成する。

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

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

[0183] 図 29 (a)は、対応するソースノードを持たず、デスティネーションツリーにのみ存在するノード上でイベントが発生したときのフローを示す。マウスイベント、キーボードィベントなど、 Canvasが取得したイベントは、デスティネーションツリーを通過して、 Elem entTemplateConnectorに izs達れる。 ElementTemplateConnectorは对、す oソ ~~スノードを持たな、ので、伝達されたイベントはソースノードに対する編集操作ではなヽ。 ElementTemplateConnectorは、 1ZS達れたヘントし ommandTemplateに己されたコマンドに合致すれば、それに対応する Actionを実行する。合致するコマンドがなければ、 ElementTemplateConnectorは、伝達されたイベントを無視する。

[0184] 図 29 (b)は、 TextOfConnectorによりソースノードに対応づけられているデステイネーシヨンツリーのノード上でイベントが発生したときのフローを示す。 TextOfConnector は、ソース DOMツリーの XPathで指定されたノード力テキストノードを取得して、デスティネーシヨン DOMツリーのノードにマッピングする。マウスイベント、キーボードィベントなど、 Canvasが取得したイベントは、デスティネーションツリーを通過して、 Text OlConnectorに伝達される。 TextO!Connectorは、伝達されたイベントを、対応するソースノードの編集コマンドにマッピングし、 Queuel053に積む。編集コマンドは、 Face tを介して実行される DOMの APIコールの集合である。キューに積まれたコマンドが実行されると、ソースノードが編集される。ソースノードが編集されると、ミューテーションイベントが発行され、リスナーとして登録された TextOfConnectorにソースノードの変更が通知される。 TextOfConnectorは、ソースノードの変更を、対応するデステイネーシヨンノードに反映させるように、デスティネーションツリーを再構築する。このとき、 TextO!Connectorを含むテンプレートに、「for each」「for loop」などの制御文が含まれている場合、 ConnectorFactoryがこの制御文を再評価し、 TextOfConnectorを再構築した後、デスティネーションツリーが再構築される。

[0185] (実施の形態）

以上の前提技術をもとに、以下実施の形態の詳細について説明する。本実施の形態では、文書を複数のファイルに分割して保存し、文書処理装置が文書を開く際に、分割されてヽるファイルを適宜合成してユーザに提示する技術を提案する。例えば、一部のユーザに対して秘匿すべきデータを含む文書を作成したときに、秘匿すべきデータを別のファイルに分割して保存し、秘匿データの閲覧を許可されたユーザには秘匿データを合成して力も文書を提示し、秘匿データの閲覧を許可されて、なヽユーザには秘匿データを秘したまま文書を提示する。

[0186] 図 30は、本実施の形態に係る文書管理システム 21の構成を示す。文書管理システム 21は、文書の編集や表示などの処理を行う文書処理装置 100と、文書の分割や合成を管理する文書管理サーバ 23とを含む。文書処理装置 100及び文書管理サーバ 23は、ネットワークの一例である LAN25を介して接続されている。文書処理装置 100は、作成した XML文書を文書管理サーバ 23に送信し、文書の保存を依頼する。文書管理サーバ 23は、文書処理装置 100から受け取った XML文書を格納する。このとき、 XML文書内に秘匿データが含まれている場合は、秘匿データを別フアイルに分割して保存する。文書管理サーバ 23は、文書処理装置 100から、文書管理サーバ 23に保存されている XML文書の取得を要求されると、要求元の文書処理装置 100のユーザを認証し、認証レベルに応じて適宜 XML文書に秘匿データを合成し、文書処理装置 100に送信する。

[0187] 図 31は、本実施の形態の文書処理装置 100の内部構成を示す。本実施の形態の文書処理装置 100は、図 1に示した前提技術の文書処理装置 20の構成に加えて、通信部 26を備える。通信部 26は、文書処理装置 100で作成した文書を、 LAN25を介して文書管理サーバ 23に送信する。また、通信部 26は、文書管理サーバ 23に保存された文書を、 LAN25を介して受信する。その他の構成及び動作は前提技術と同様である。

[0188] 図 32は、文書管理サーバ 23の内部構成を示す。文書管理サーバ 23は、主に、通信部 3010、文書保存要求受付部 3020、文書ファイル受信部 3022、秘匿データ抽出部 3024、 ID発行部 3026、文書ファイル分割部 3028、文書取得要求受付部 303 0、ユーザ認証部 3032、文書ファイル合成部 3034、文書ファイル送信部 3036、文書ファイル管理テーブル 3040、文書ファイル格納部 3050、及びユーザデータべ一ス 3060を含む。これらの構成も、ハードウェアのみ、ソフトウェアのみ、またはそれらの糸且合せによって、ろ、ろな形で実現できる。

[0189] 文書保存要求受付部 3020が、文書処理装置 100から文書ファイルの保存要求を受け付けると、文書ファイル受信部 3022が通信部 3010を介して文書処理装置 100 力も文書ファイルを受信する。秘匿データ抽出部 3024は、文書ファイル受信部 302 2が受信した文書ファイル内に含まれる固有名詞などの秘匿データを抽出する。秘匿データは、後述するように、文書内で所定のタグによりマークアップされていてもよいし、秘匿データ抽出部 3024がユーザの文書処理装置 100に対して秘匿データの指定を受け付けるためのインタフェース画面などを提示し、ユーザから秘匿データの指定を受け付けてもよい。前者の場合は、文書に秘匿データを示すタグをつける編集部 54、 64などの構成と、文書ファイル中につけられたタグ力文書ファイル中の秘匿データを文書管理サーバ 23へ通知する通知部として機能し、後者の場合は、インタフェース画面が通知部として機能する。また、秘匿データ抽出部 3024は、秘匿すベきデータの一覧などを保持してもよぐ文書処理装置 100からの通知を受けずに、自身が保持する一覧にリストアップされたデータを秘匿データとして抽出してもよい。 ID 発行部 3026は、秘匿データ抽出部 3024が抽出した秘匿データのそれぞれに対して IDを発行する。この IDは、文書内で秘匿データを一意に識別できればよぐ他の文書の秘匿データの IDと重複してもよ!/、。

[0190] 置換部として機能する文書ファイル分割部 3028は、まず、文書ファイル受信部 30 22が受信した文書ファイル (以下、この文書ファイルを「元ファイル」と呼ぶ）中の秘匿データを、 ID発行部 3026により発行された IDで置き換えて、文書ファイル格納部 30 50に保存する。こうして生成された文書ファイルを、以下、「表ファイル」と呼ぶ。文書ファイル分割部 3028は、さらに、秘匿データと IDとを対応づけて記述したファイルを生成して、文書ファイル格納部 3050に保存する。こうして生成された文書ファイルを、以下、「裏ファイル」と呼ぶ。すなわち、文書ファイル分割部 3028は、元ファイルを、表ファイルと裏ファイルに分割し、文書ファイル格納部 3050にそれぞれ格納する。文書ファイル格納部 3050において、表ファイルは文書処理装置 100からの直接のァクセスを受け付ける領域に格納されてもよいが、裏ファイルは文書処理装置 100から直接アクセスできないように保存される。こうして、文書管理サーバ 23は、文書処理装置 100から保存を要求された元ファイルに含まれる秘匿データを、文書処理装置 10 0からの直接のアクセスを受け付けな、裏ファイルに退避して保存する。文書ファイル分割部 3028は、表ファイルと裏ファイルの対応を管理するために必要な情報を文書ファイル管理テーブル 3040に登録する。

[0191] 文書管理サーバ 23は、文書処理装置 100から、文書ファイル格納部 3050に保存された文書の取得を要求されたとき、要求元の文書処理装置 100のユーザの認証レベル又はアクセス権限に応じて、文書ファイルを適宜合成して提供する。例えば、ァクセス権限の低、ユーザに対しては、秘匿データを秘したままの表ファイルを提供し、アクセス権限の高いユーザに対しては、表ファイルに裏ファイルを合成し、表フアイル中の IDを裏ファイル中の秘匿データに置き換えて提供する。裏ファイルは、文書を取得しょうとするユーザのアクセス権限のレベルに応じて、複数用意されてもよい。例えば、アクセス権限が最も高いユーザに対しては、全ての秘匿データを開示するために、全ての秘匿データと IDの対応を記述した裏ファイルを用意し、アクセス権限が中程度のユーザに対しては、一部の秘匿データのみを開示するために、一部の秘匿データと IDの対応を記述した裏ファイルを用意し、アクセス権限が最も低、ユーザに対しては、全ての秘匿データを開示しないために、裏ファイルを合成しないようにしてもよい。また、裏ファイルに記述される秘匿データのそれぞれにアクセス権限を設定し、裏ファイルを合成するときに、ユーザのアクセス権限に応じて、選択的に秘匿データを表ファイルに合成するようにしてもょ、。

[0192] 文書取得要求受付部 3030が、文書処理装置 100から文書ファイルの取得要求を受け付けると、ユーザ認証部 3032が文書処理装置 100のユーザを認証する。ユーザ認証部 3032は、文書処理装置 100に対して、ユーザ IDとパスワードなどの入力を要求し、受け付けたユーザ IDとパスワードの組を、ユーザデータベース 3060を参照して認証してもよい。ユーザ認証部 3032が、ユーザの認証に成功すると、文書フアイル合成部 3034は、ユーザの認証レベルに応じて、適宜裏ファイルを表ファイルに合成する。文書ファイル合成部 3034は、文書ファイル管理テーブル 3040を参照して、要求された文書の表ファイルと裏ファイルの対応を取得し、文書ファイル格納部 305 0から必要なファイルを読み出して合成する。文書ファイル送信部 3036は、文書ファィル合成部 3034により合成された文書ファイルを、通信部 3010を介して文書処理装置 100へ送信する。

[0193] 図 33は、文書ファイル管理テーブル 3040の内部データの例を示す。文書ファイル管理テーブル 3040には、文書ファイル名欄 3042と、その文書ファイルに合成すベき裏ファイルの情報を格納する対応情報欄 3044とが設けられて、る。ユーザから文書の取得要求を受け付けるときの文書ファイル名として、元ファイルの名前を用いてもよいし、表ファイルの名前を用いてもよぐ元ファイルと表ファイルの名前は異なっていてもよいが、本実施の形態では、元ファイルと表ファイルを同じ名前にしている。すなわち、元ファイルから生成した表ファイルは、元ファイルと同じ名前で文書ファイル格納部 3050に格納され、元ファイルと同じ名前でアクセス可能としている。対応情報欄 3044は、一つの表ファイルに対して用意された裏ファイルの数だけ設けられ、それぞれ、認証レベル欄 3046及び裏ファイル名欄 3048を含む。文書ファイル分割部 3028は、ユーザの認証レベルに応じて、開示する秘匿データを段階的に変更すベき場合は、複数の裏ファイルを生成して保存し、それぞれの裏ファイルと認証レベルとの対応を対応情報欄 3044に登録する。文書ファイル合成部 3034は、ユーザ認証部 3032により認証されたユーザの認証レベルに応じて、合成すべき裏ファイルの名前を文書ファイル管理テーブル 3040から取得し、裏ファイルを文書ファイル格納部 3 050から読み出して表ファイルに合成する。

[0194] 図 34は、ユーザデータベース 3060の内部データの例を示す。ユーザデータべ一ス 3060に ίま、ユーザ ID欄 3062、ノスワード欄 3064、及び認証レべノレ欄 3066力 ^設けられている。ユーザ認証部 3032は、ユーザから受け付けたユーザ IDとパスワードの組が、ユーザデータベース 3060に登録されたものと合致している力否かを認証し、合致していれば、認証レベル欄 3066に登録された認証レベルを取得する。

[0195] 以下、本実施の形態の文書管理システム 21において処理される XML文書の例を具体的に示しつつ、処理の流れをさらに詳細に説明する。

[0196] 図 35は、本実施の形態の文書管理システム 21において処理される XML文書の例を示す。 XML文書「sample.xml」は、メールを記述するためのボキヤブラリ「xmail」を用いて記述されている。ルートノード「xmail」は、子要素として、要素「title」と要素「co mment」を有する。要素「title」のテキストノードにはメールのタイトル力要素「commen t」のテキストノードにはメールの本文が格納される。要素「comment」は、子要素として、名簿リストを格納する要素「list」を有する。要素「list」は、子要素として、要素「lt」と要素「person」を有する。要素「lt」のテキストノードにはリストのタイトルが格納される。要素「per_SOn」は、複数設けられており、それぞれに個人情報が格納される。要素「pe rsonjは、子要素として、名前を格納する要素「name」と、住所を格納する要素「addres s」をそれぞれ有する。

[0197] 図 36は、図 35に示した XML文書を XHTMLにマッピングして表示 Z編集するための定義ファイル「sample.vcd」の例を示す。ルートノード「xmail」に対応するテンプレート 4000には、 XHTMLの基本要素「html」、「head」、「body」などが記述されており、 XHTML文書のタイトルを格納する要素「html/head/title」に、要素「xmail:title」の要素値が代入されている。また、 XHTML文書の本文「body」の先頭に、見出し「hl」として、要素「xmail:title」の要素値が表示される。要素「comment」に対応するテンプレート 4002には、段落」に要素「comment」の要素値を表示することが記述されている。要素「list」に対応するテンプレート 4004には、表「table」の第 1行に、要素「xma ihltjに格納されたリストのタイトルが、第 2行の第 1列に文字列「名前」が、第 2列に文字列「住所」が表示されることが記述されて、る。要素「person」に対応するテンプレート 4006には、各行の第 1列に、要素「xmail:name」に対応するテンプレートが適用され、第 2列に、要素「xmail:address」に対応するテンプレートが適用されることが記述されている。要素「name」に対応するテンプレート 4008には、要素「name」の要素値が表示されることが記述され、要素「address」に対応するテンプレート 410には、要素「a ddresssjの要素値が表示されることが記述されて、る。

[0198] 図 37は、図 35に示した XML文書に、図 36に示した定義ファイルを適用して表示した画面の例を示す。前提技術で説明したように、 XML文書「sample.xml」は、定義ファイル「sample.vcd」を用いて、 VCユニット 80のマッピング部 82により XHTML文書に変換され、 HTMLユニット 50の表示部 56により表示される。

[0199] この画面において、ユーザが、固有名詞である文字列「徳島太郎」、「阿波花子」、「四国三郎」、「徳島県徳島巿川内町平石若松〇〇番地」を選択し、プルダウンメ-ュ一や右クリックメニューなどのユーザインタフェースを用いて、これらのデータを秘匿データに指定したとする。このとき、秘匿データの開示を許可するユーザの認証レべルを指定するためのポップアップメニューなどのユーザインタフェースが提示されてもよい。秘匿データや認証レベルなどの情報は、文書ファイルとは別に文書管理サーバ 23へ通知されてもよいが、本実施の形態では、 XML文書中で秘匿データを特定のタグでマークアップすることにより、文書管理サーバ 23へ秘匿データを通知する。

[0200] 図 38は、秘匿データがマークアップされた XML文書の例を示す。図 38に示した X ML文書「sample.xml」では、秘匿データに指定されたデータが、「secret」タグでマークアップされており、その秘匿データの開示が許可されるユーザの認証レベルが属性値として指定されている。

[0201] 文書処理装置 100が、通信部 26を介して、文書管理サーバ 23にこの XML文書を送信し、文書の保存を要求すると、文書管理サーバ 23では、文書ファイル受信部 30 22が XML文書を取得し、秘匿データ抽出部 3024が秘匿データを抽出する。図 38 に示した XML文書では、構成要素「xmail:secret」に秘匿データが格納されているので、秘匿データ抽出部 3024は、構成要素「xmail:secret」を抽出する。 ID発行部 302 6は、抽出された秘匿データの数だけ IDを発行する。図 38の例では、構成要素「xma il:secret」が 6個あるので、 IDを 6個発行してもよいが、構成要素「xmail:address」に格納された 3個の秘匿データは同一であるから、ここでは 4個の IDを発行する。文書フアイル分割部 3028は、秘匿データを別のファイルに分離して、 XML文書を複数のフアイルに分割する。

[0202] 図 39は、文書ファイル分割部 3028が、図 38に示した XML文書を分割して生成した表ファイルの例を示す。表ファイルでは、元ファイルカゝら秘匿データが除去され、その位置に「xmail」ボキヤブラリの「anonymous」タグが代わりに挿入されており、属性値として秘匿データの IDが格納されている。この表ファイルを取得したユーザは、秘匿データの IDのみを知ることができ、秘匿データの実体を知ることはできな！、。

[0203] 図 40は、文書ファイル分割部 3028が、図 38に示した XML文書を分割して生成した裏フアイノレの例を示す。裏フアイノレ！ "anonymous2.xml」では、「anonymous」ボキヤブラリにより、元ファイルにおいて指定されていた秘匿データの IDと実体が対応付けて記述されている。「anonymous」ボキャブラリの構成要素「item」は、秘匿データの IDを格納する構成要素「serial」と、その IDに対応付けられた秘匿データの実体を格納する構成要素「name」を 1つずつ含む。

[0204] 図 41は、文書ファイル分割部 3028が、図 38に示した XML文書を分割して生成した裏ファイルの別の例を示す。図 40に示した裏ファイルは、認証レベル力「1」のユーザが文書の取得を要求したときに表ファイルに合成されるものであり、図 41に示した裏ファイルは、認証レベルが「2」のユーザが文書の取得を要求したときに合成されるものである。図 40の裏ファイルには、図 38に示した XML文書において、認証レベル「1」が指定された秘匿データのみが記述されている。図 41の裏ファイルには、図 38 に示した XML文書において、認証レベル「1」が指定された秘匿データと認証レベル「2」が指定された秘匿データが記述されて、る。

[0205] 図 42は、図 39に示した表ファイルに、図 40に示した裏ファイルを合成するための定義を記述した定義ファイルの例を示す。定義ファイルには、「anonymous」ボキヤブラリで記述された部分を、裏ファイルを用いて解決すべき旨の情報が記述されて、る。文書ファイル合成部 3034は、この定義ファイルを参照して、表ファイルと裏ファイルを合成する。この定義ファイルには、図 36に示した定義ファイルの内容に比べて、秘匿データの合成などを記述するためのボキヤブラリである「anomymous」ボキヤブラリの名前空間宣言 4012が追加されており、要素「name」のテンプレートが 4014に書き換えられ、同様に、要素「address」のテンプレートが 4016に書き換えられている。

[0206] 文書処理装置 100が、通信部 26を介して、この XML文書の取得を文書管理サーバ 23に要求すると、文書取得要求受付部 3030がその要求を受け付け、ユーザ認証部 3032がユーザデータベース 3060を参照してユーザを認証し、ユーザの認証レべルを判定する。文書ファイル合成部 3034は、ユーザの認証レベルに応じて、文書フアイル管理テーブル 3040から、この文書の表ファイルに合成すべき裏ファイルのファィル名を取得し、文書ファイル格納部 3050から表ファイルと裏ファイルを読み出す。さら〖こ、文書ファイル合成部 3034は、表ファイルに記述されている定義ファイルを文書ファイル格納部 3050から読み出す。文書ファイル合成部 3034は、定義ファイルを参照して、「anonymous」タグの内容を、裏ファイルにより解決して合成する。この例では、「anonymous」タグに、裏ファイルに格納されている秘匿データを代入する。このとき、文書ファイル合成部 3034は、表ファイルに裏ファイルを合成するための定義ファィルを修正して、合成ファイルを処理するための定義ファイルを生成する。文書フアイル送信部 3036は、生成された文書ファイルを文書処理装置 100へ送信する。

[0207] ユーザが認証されなかった場合、又は、ユーザの認証レベルが「0」であった場合は、表ファイルに裏ファイルは合成されない。この場合、文書ファイル合成部 3034は、表ファイルをそのまま合成ファイルとしてもよいし、表ファイル中の秘匿データを示す「 xmail:anonymous」タグを削除し、代わりに秘匿データの ID、又は秘匿データであることを示すアイコンなどの画像を表示するためのタグなどを挿入して、合成ファイルとしてもよい。文書ファイル合成部 3034は、図 42に示した表ファイルに裏ファイルを合成するための定義ファイルから、「anomymous」ボキヤブラリの名前空間宣言 4012を削除し、要素「name」のテンプレート 4014及び要素「address」のテンプレート 4016に、秘匿データの IDやアイコンなどを表示する命令を記述して、合成ファイルを処理するための定義ファイルを生成する。図 43及び図 44は、生成された合成ファイルの表示例を示す。図 43では、秘匿データ力 Dで表示されている。図 44では、秘匿データがアイコンで表示されて、る。

[0208] ユーザの認証レベル力「l」であった場合は、図 39に示した表ファイルに、図 40に示した認証レベルが「1」のユーザのための裏ファイルが合成される。表ファイルの秘匿データのうち、 ID力 0001、 0002、 0003の禾必匿データ ίま裏フアイノレにより解決されて、実際の値が代入される力 IDが 0004の秘匿データは解決されない。図 45及び図 46は、生成された合成ファイルの表示例を示す。図 45では、秘匿データが ID で表示されている。図 46では、秘匿データがアイコンで表示されている。

[0209] ユーザの認証レベルが「2」であった場合は、図 39に示した表ファイルに、図 41に示した裏ファイルが合成される。表ファイルの秘匿データは全て解決されるので、合成ファイルは、図 35に示した元ファイルと同じになる。この合成ファイルは、図 36に示した定義ファイルを適用して、図 37に示したように表示される。

[0210] 図 47は、文書ファイル分割部 3028が、図 38に示した XML文書を分割して生成した表ファイルの別の例を示す。図 47の例では、秘匿データである「xmail:name」要素の要素値の代わりに挿入された「xmail:anonymous」タグがテキストノードを有しており、「匿名 A」などの秘匿データの代替文字列が格納されて！、る。

[0211] 図 48は、図 47に示した表ファイルに適用される定義ファイルの例を示す。「xmail:na me」要素のテンプレート 4018には、「xmail:anonymous」要素にテキストノードがあればその文字列を表示し、テキストノードがなければ「xmail:anonymous」要素の属性値として指定された IDを表示する命令が記述されてヽる。

[0212] 図 49は、図 47に示した表ファイルに、図 48に示した定義ファイルを適用して表示した画面の例を示す。「発明者一覧」の「名前」の欄には、「xmail:anonymous」要素のテキストノードの値、すなわち、「匿名 A」、「匿名 B」、「匿名 C」が表示され、「住所」の欄には、「xmail:anonymous」要素の属性値として指定された ID、すなわち、「0004」力表示されている。

[0213] 以上のように、本実施の形態の技術によれば、文書を構成要素に応じて複数のファィルに分割して保存することにより、重要な情報を適切に秘匿することができる。また、ユーザの権限に応じて秘匿データの開示の許否を適切に制御することができる。

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

[0215] 実施の形態では、 XML文書を処理する例にっ、て説明した力本実施の形態の文書処理装置 100は、他のマークアップ言語、例えば、 SGML, HTMLなどで記述された文書も同様に処理可能である。

産業上の利用可能性

[0216] 本発明は、秘匿データを扱うデータ処理システムに利用することができる。

Claims

請求の範囲

[1] データを処理するデータ処理装置と、

前記データが格納されたファイルを管理する管理サーバと、を含み、

前記データ処理装置は、

秘匿データを含むファイルを前記管理サーバへ送信する送信部と、

前記ファイル中の前記秘匿データを前記管理サーバへ通知する通知部と、を含み前記管理サーバは、

ファイルに含まれる秘匿データを抽出する抽出部と、

前記抽出部により抽出された秘匿データに対して識別子を発行する発行部と、ファイル中の前記秘匿データを前記識別子に置換する置換部と、

前記秘匿データと前記識別子を対応づけて格納する格納部と、を含むことを特徴とするデータ処理システム。

[2] 前記管理サーバは、前記秘匿データを閲覧する権限を有するユーザから前記ファィルの取得要求を受け付けたときに、前記格納部力前記秘匿データを読み出して前記ファイルに合成する合成部を更に含むことを特徴とする請求項 1に記載のデータ処理システム。

[3] 前記合成部は、前記ユーザの権限のレベルに応じて、閲覧を許可すべき秘匿データを選択して前記ファイルに合成することを特徴とする請求項 2に記載のデータ処理システム。

[4] 前記格納部は、前記データが格納されたファイルとは異なるファイルであることを特徴とする請求項 1から 3のいずれかに記載のデータ処理システム。

[5] データが格納されたファイルから、他のファイルに移動すべきデータを抽出する抽出部と、

前記抽出部により抽出されたデータに対して識別子を発行する発行部と、前記ファイル中の前記抽出されたデータを前記識別子に置換する置換部と、前記抽出されたデータと前記識別子とを対応づけて他のファイルに格納する格納部と、を含むことを特徴とする管理サーバ。

[6] データが格納されたファイルから、他のファイルに移動すべきデータを抽出するステップと、

抽出されたデータに対して識別子を発行するステップと、

前記ファイル中の前記抽出されたデータを前記識別子に置換するステップと、前記抽出されたデータと前記識別子とを対応づけて他のファイルに格納するステツプと、

を含むことを特徴とするデータ処理方法。

[7] データが格納されたファイルから、他のファイルに移動すべきデータを抽出する機能と、

抽出されたデータに対して識別子を発行する機能と、

前記ファイル中の前記抽出されたデータを前記識別子に置換する機能と、前記抽出されたデータと前記識別子とを対応づけて他のファイルに格納する機能とをコンピュータに実現させることを特徴とするデータ処理プログラム。