(57)【要約】  構造化されたデータを適切に処理する技術を提供する。  文書処理装置２０が処理する文書に、データベースシステム７０に格納されたデータに関する条件式が含まれている場合、クエリ生成部７４は、その条件式からデータベースシステム７０に応じたクエリ文を生成する。データベースプラグイン７６は、生成されたクエリ文をデータベースシステム７０へ送信し、データベースシステム７０からクエリ結果を取得する。ビュー生成部７２は、取得したクエリ結果を表示するためのビューを生成する。文書処理装置２０は、生成されたビューを含む文書の表示画面を表示する。
2007081017.tif 000002
【特許請求の範囲】
【請求項１】
マークアップ言語により構造化された文書を処理する文書処理装置であって、  データベースシステムに保持されたデータを前記文書に埋め込むときに、前記データベースシステムに応じたクエリ文を生成するクエリ生成部と、  前記データベースシステムから前記クエリ文の結果を前記マークアップ言語により構造化されたデータの形式で取得したときに、その結果を表示するための画面を生成するビュー生成部と、  を備えることを特徴とする文書処理装置。
【請求項２】
前記クエリ生成部は、前記データベースシステムに保持された、マークアップ言語により構造化されたデータの構造を示す情報を取得して提示し、提示したデータの中から前記文書に埋め込むデータの指定を受け付け、受け付けたデータのクエリ文を生成することを特徴とする請求項１に記載の文書処理装置。
【請求項３】
前記クエリ生成部は、マークアップ言語により構造化されたデータのうち、同種のデータの対応関係を保持した管理サーバから、前記対応関係を取得し、前記データベースシステムに保持された、前記マークアップ言語により構造化されたデータの構造を提示するときに、前記対応関係を識別可能に提示することを特徴とする請求項１又は２に記載の文書処理装置。
【請求項４】
前記クエリ生成部は、前記データベースシステムに保持された、マークアップ言語により構造化されていないデータを、マークアップ言語により構造化されたデータの形式で取得するためのクエリ文を生成可能であることを特徴とする請求項１から３のいずれかに記載の文書処理装置。
【請求項５】
マークアップ言語により構造化された文書を処理する文書処理装置と、  前記文書に利用可能なデータを保持するデータベースシステムと、を備え、  前記文書処理装置は、  前記データベースシステムに保持されたデータを前記文書に埋め込むときに、前記データベースシステムに応じたクエリ文を生成するクエリ生成部と、  前記データベースシステムから前記クエリ文の結果を前記マークアップ言語により構造化されたデータの形式で取得したときに、その結果を表示するためのビューを生成するビュー生成部と、を備えることを特徴とするデータ処理システム。
【請求項６】
前記データベースシステムに保持されたデータ間の対応関係を管理する管理サーバを更に備えることを特徴とする請求項５に記載のデータ処理システム。
【請求項７】
前記データベースシステムは、ＸＭＬデータベース及びリレーショナルデータベースの複合型データベースシステムであることを特徴とする請求項５又は６に記載のデータ処理システム。
【請求項８】
マークアップ言語により構造化された文書を処理する文書処理装置が、データベースシステムに保持されたデータを前記文書に埋め込むときに、前記データベースシステムに応じたクエリ文を生成するステップと、  前記データベースシステムから前記クエリ文の結果を前記マークアップ言語により構造化されたデータの形式で取得したときに、その結果を表示するための画面を生成するステップと、  を備えることを特徴とする文書処理方法。
【請求項９】
コンピュータを、  マークアップ言語により構造化された文書を処理する文書処理装置が、データベースシステムに保持されたデータを前記文書に埋め込むときに、前記データベースシステムに応じたクエリ文を生成する手段、  前記データベースシステムから前記クエリ文の結果を前記マークアップ言語により構造化されたデータの形式で取得したときに、その結果を表示するための画面を生成する手段、  として機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は、データ処理技術に関し、特に、マークアップ言語により構造化された文書を処理する文書処理装置、及びその文書処理装置を利用可能なデータ処理システムに関する。
【背景技術】
【０００２】  近年、企業が扱うさまざまな情報をＸＭＬで標準化する活動が急速に進展してきた。Ｗ３ＣがＸＨＴＭＬやＳＶＧ、ＳＯＡＰやＷＳＤＬ、ＲＤＦやＸ−ＱｕｅｒｙのようなシステムのインフラとなるＸＭＬスキーマを制定し、同時に業界団体と標準化団体が連携して、ＸＢＲＬやｅｂＸＭＬ、ＥＤＩＸＭＬやＵＢＬ、Open Office ＸＭＬやGovernment ＸＭＬなどの実務データのＸＭＬスキーマの標準化を推進している。【特許文献１】特開２００１−２９０８０４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】  このように情報の標準化と部品化が加速する一方で、これを効率的に企業価値に転換するための「活用モデル」の登場が強く求められている。
【課題を解決するための手段】
【０００４】  本発明のある態様は、文書処理装置に関する。この文書処理装置は、マークアップ言語により構造化された文書を処理する文書処理装置であって、データベースシステムに保持されたデータを前記文書に埋め込むときに、前記データベースシステムに応じたクエリ文を生成するクエリ生成部と、前記データベースシステムから前記クエリ文の結果を前記マークアップ言語により構造化されたデータの形式で取得したときに、その結果を表示するためのビューを生成するビュー生成部と、を備えることを特徴とする。【０００５】  前記クエリ生成部は、前記データベースシステムに保持された、マークアップ言語により構造化されたデータの構造を示す情報を取得して提示し、提示したデータの中から前記文書に埋め込むデータの指定を受け付け、受け付けたデータのクエリ文を生成してもよい。【０００６】  前記クエリ生成部は、マークアップ言語により構造化されたデータのうち、同種のデータの対応関係を保持した管理サーバから、前記対応関係を取得し、前記データベースシステムに保持された、前記マークアップ言語により構造化されたデータの構造を提示するときに、前記対応関係を識別可能に提示してもよい。【０００７】  前記クエリ生成部は、前記データベースシステムに保持された、マークアップ言語により構造化されていないデータを、マークアップ言語により構造化されたデータの形式で取得するためのクエリ文を生成可能であってもよい。【０００８】  本発明の別の態様は、データ処理システムに関する。このデータ処理システムは、マークアップ言語により構造化された文書を処理する文書処理装置と、前記文書に利用可能なデータを保持するデータベースシステムと、を備え、前記文書処理装置は、前記データベースシステムに保持されたデータを前記文書に埋め込むときに、前記データベースシステムに応じたクエリ文を生成するクエリ生成部と、前記データベースシステムから前記クエリ文の結果を前記マークアップ言語により構造化されたデータの形式で取得したときに、その結果を表示するためのビューを生成するビュー生成部と、を備えることを特徴とする。【０００９】  データ処理システムは、前記データベースシステムに保持されたデータ間の対応関係を管理する管理サーバを更に備えてもよい。前記データベースシステムは、ＸＭＬデータベース及びリレーショナルデータベースの複合型データベースシステムであってもよい。【００１０】  本発明の更に別の態様は、文書処理方法に関する。この文書処理方法は、マークアップ言語により構造化された文書を処理する文書処理装置が、データベースシステムに保持されたデータを前記文書に埋め込むときに、前記データベースシステムに応じたクエリ文を生成するステップと、前記データベースシステムから前記クエリ文の結果を前記マークアップ言語により構造化されたデータの形式で取得したときに、その結果を表示するための画面を生成するステップと、を備えることを特徴とする。【００１１】  なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システムなどの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１２】  本発明によれば、構造化されたデータを適切に処理する技術を提供することができる。
【図面の簡単な説明】
【００１３】
【図１】前提技術に係る文書処理装置の構成を示す図である。
【図２】処理対象となるＸＭＬ文書の例を示す図である。
【図３】図２に示したＸＭＬ文書をＨＴＭＬで記述された表にマッピングする例を示す図である。
【図４（ａ）】図２に示したＸＭＬ文書を図３に示した表にマッピングするための定義ファイルの例を示す図である。
【図４（ｂ）】図２に示したＸＭＬ文書を図３に示した表にマッピングするための定義ファイルの例を示す図である。
【図５】図２に示した成績管理ボキャブラリで記述されたＸＭＬ文書を、図３に示した対応によりＨＴＭＬにマッピングして表示した画面の例を示す図である。
【図６】ユーザが定義ファイルを生成するために、定義ファイル生成部がユーザに提示するグラフィカルユーザインターフェースの例を示す図である。
【図７】定義ファイル生成部により生成された画面レイアウトの他の例を示す図である。
【図８】文書処理装置によるＸＭＬ文書の編集画面の一例を示す図である。
【図９】文書処理装置により編集されるＸＭＬ文書の他の例を示す図である。
【図１０】図９に示した文書を表示した画面の例を示す図である。
【図１１】本実施例における定義ファイル生成過程を説明するための模式図である。
【図１２】本実施例におけるスキーマファイルを示す図である。
【図１３】図１２のスキーマファイルに対応するソースファイルを示す図である。
【図１４】図１２のスキーマファイルと図１３のソースファイルに基づいて生成される定義ファイルを示す図である。
【図１５】バインディングファイルの編集画面を示す図である。
【図１６】図１５におけるバインディングファイルの編集結果に基づくレイアウトファイル編集画面を示す図である。
【図１７】図１６における編集結果に基づいたデスティネーションファイルを表示させたときの画面図である。
【図１８】バインディングファイルの編集画面の別例を示す図である。
【図１９】図１７におけるバインディングファイルの編集結果に基づくレイアウトファイル編集画面を示す図である。
【図２０】図１８における編集結果に基づいたデスティネーションファイルを表示させたときの画面図である。
【図２１】バインディングファイルの編集画面の更に別例を示す図である。
【図２２】図２１におけるバインディングファイルの編集結果に基づくレイアウトファイル編集画面を示す図である。
【図２３】図２２における編集結果に基づいたデスティネーションファイルを表示させたときの画面図である。
【図２４】バインディングファイルの編集画面の更に別例を示す図である。
【図２５】図２４におけるバインディングファイルの編集結果に基づくレイアウトファイル編集画面を示す図である。
【図２６】図２５における編集結果に基づいたデスティネーションファイルを表示させたときの画面図である。
【図２７】定義ファイル生成過程を更に説明するための模式図である。
【図２８】実施の形態に係るデータ処理システムの構成を示す図である。
【図２９】ＸＭＬＤＢ連携ドキュメントアプリケーションの作成過程を示す図である。
【図３０】ＸＭＬＤＢ連携ドキュメントアプリケーションの利用過程を示す図である。
【符号の説明】
【００１４】  ２０  文書処理装置、２２  主制御ユニット、２４  編集ユニット、３０  ＤＯＭユニット、３２  ＤＯＭ提供部、３４  ＤＯＭ生成部、３６  出力部、４０  ＣＳＳユニット、４２  ＣＳＳ解析部、４４  ＣＳＳ提供部、４６  レンダリング部、５０  ＨＴＭＬユニット、５２，６２  制御部、５４，６４  編集部、５６，６６  表示部、６０  ＳＶＧユニット、７０  データベースシステム、７２  ビュー生成部、７４  クエリ生成部、７６  データベースプラグイン、７８  ボキャブラリ管理サーバ、８０  ＶＣユニット、８２  マッピング部、８４  定義ファイル取得部、８６  定義ファイル生成部。
【発明を実施するための最良の形態】
【００１５】（前提技術）  図１は、前提技術に係る文書処理装置２０の構成を示す。文書処理装置２０は、文書内のデータが階層構造を有する複数の構成要素に分類された構造化文書を処理するが、本前提技術では構造化文書の一例としてＸＭＬ文書を処理する例について説明する。文書処理装置２０は、主制御ユニット２２、編集ユニット２４、ＤＯＭユニット３０、ＣＳＳユニット４０、ＨＴＭＬユニット５０、ＳＶＧユニット６０、及び変換部の一例であるＶＣユニット８０を備える。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。【００１６】  主制御ユニット２２は、プラグインのロードや、コマンド実行のフレームワークを提供する。編集ユニット２４は、ＸＭＬ文書を編集するためのフレームワークを提供する。文書処理装置２０における文書の表示及び編集機能は、プラグインにより実現されており、文書の種別に応じて必要なプラグインが主制御ユニット２２又は編集ユニット２４によりロードされる。主制御ユニット２２又は編集ユニット２４は、処理対象となるＸＭＬ文書の名前空間を参照して、ＸＭＬ文書がいずれのボキャブラリにより記述されているかを判別し、そのボキャブラリに対応した表示又は編集用のプラグインをロードして表示や編集を実行させる。例えば、文書処理装置２０には、ＨＴＭＬ文書の表示及び編集を行うＨＴＭＬユニット５０、ＳＶＧ文書の表示及び編集を行うＳＶＧユニット６０など、ボキャブラリ（タグセット）ごとに表示系及び編集系がプラグインとして実装されており、ＨＴＭＬ文書を編集するときはＨＴＭＬユニット５０が、ＳＶＧ文書を編集するときはＳＶＧユニット６０が、それぞれロードされる。後述するように、ＨＴＭＬとＳＶＧの双方の構成要素を含む複合文書が処理対象となっている場合は、ＨＴＭＬユニット５０とＳＶＧユニット６０の双方がロードされる。【００１７】  このような構成によれば、ユーザは、必要な機能のみを選択してインストールし、後から適宜機能を追加又は削除することができるので、プログラムを格納するハードディスクなどの記録媒体の記憶領域を有効に活用することができ、また、プログラム実行時にも、メモリの浪費を防ぐことができる。また、機能拡張性に優れており、開発主体としても、プラグインの形で新たなボキャブラリに対応することが可能なので開発が容易となり、ユーザとしても、プラグインの追加により容易かつ低コストにて機能を追加することができる。【００１８】  編集ユニット２４は、ユーザインターフェースを介してユーザから編集指示のイベントを受け付け、そのイベントを適切なプラグインなどに通知するともに、イベントの再実行（リドゥ）又は実行の取消（アンドゥ）などの処理を制御する。【００１９】  ＤＯＭユニット３０は、ＤＯＭ提供部３２、ＤＯＭ生成部３４、及び出力部３６を含み、ＸＭＬ文書をデ��タとして扱うときのアクセス方法を提供するために定められた文書オブジェクトモデル（Document Object Model：ＤＯＭ）に準拠した機能を実現する。ＤＯＭ提供部３２は、編集ユニット２４に定義されているインタフェースを満たすＤＯＭの実装である。ＤＯＭ生成部３４は、ＸＭＬ文書からＤＯＭツリーを生成する。後述するように、処理対象となるＸＭＬ文書が、ＶＣユニット８０により他のボキャブラリにマッピングされる場合は、マッピング元のＸＭＬ文書に対応するソースツリーと、マッピング先のＸＭＬ文書に対応するデスティネーションツリーが生成される。出力部３６は、例えば編集終了時に、ＤＯＭツリーをＸＭＬ文書として出力する。【００２０】  ＣＳＳユニット４０は、ＣＳＳ解析部４２、ＣＳＳ提供部４４、及びレンダリング部４６を含み、ＣＳＳに準拠した表示機能を提供する。ＣＳＳ解析部４２は、ＣＳＳの構文を解析するパーサの機能を有する。ＣＳＳ提供部４４は、ＣＳＳオブジェクトの実装であり、ＤＯＭツリーに対してＣＳＳのカスケード処理を行う。レンダリング部４６は、ＣＳＳのレンダリングエンジンであり、ＣＳＳを用いてレイアウトされるＨＴＭＬなどのボキャブラリで記述された文書の表示に用いられる。【００２１】  ＨＴＭＬユニット５０は、ＨＴＭＬにより記述された文書を表示又は編集する。ＳＶＧユニット６０は、ＳＶＧにより記述された文書を表示又は編集する。これらの表示／編集系は、プラグインの形で実現されており、それぞれ、文書を表示する表示部（Canvas）５６、６６、編集指示を含むイベントを送受信する制御部（Editlet）５２、６２、編集コマンドを受けてＤＯＭに対して編集を行う編集部（Zone）５４、６４を備える。制御部５２又は６２が外部からＤＯＭツリーの編集コマンドを受け付けると、編集部５４又は６４がＤＯＭツリーを変更し、表示部５６又は６６が表示を更新する。これらは、ＭＶＣ（Model-View-Controller）と呼ばれるフレームワークに類似する構成をとっており、概ね、表示部５６及び６６が「View」に、制御部５２及び６２が「Controller」に、編集部５４及び６４とＤＯＭの実体が「Model」に、それぞれ対応する。本前提技術の文書処理装置２０では、ＸＭＬ文書をツリー表示形式で編集するだけでなく、それぞれのボキャブラリに応じた編集を可能とする。例えば、ＨＴＭＬユニット５０は、ＨＴＭＬ文書をワードプロセッサに類似した方式で編集するためのユーザインターフェースを提供し、ＳＶＧユニット６０は、ＳＶＧ文書を画像描画ツールに類似した方式で編集するためのユーザインターフェースを提供する。【００２２】  ＶＣユニット８０は、マッピング部８２、定義ファイル取得部８４、及び定義ファイル生成部８６を含み、あるボキャブラリにより記述された文書を、他のボキャブラリにマッピングすることにより、マッピング先のボキャブラリに対応した表示編集用プラグインで文書を表示又は編集するためのフレームワークを提供する。本前提技術では、この機能を、ボキャブラリコネクション（Vocabulary Connection：ＶＣ）と呼ぶ。定義ファイル取得部８４は、マッピングの定義を記述したスクリプトファイルを取得する。この定義ファイルは、ノードごとに、ノード間の対応（コネクション）を記述する。このとき、��ノードの要素値や属性値の編集の可否を指定してもよい。また、ノードの要素値や属性値を用いた演算式を記述してもよい。これらの機能については、後で詳述する。マッピング部８２は、定義ファイル取得部８４が取得したスクリプトファイルを参照して、ＤＯＭ生成部３４にデスティネーションツリーを生成させ、ソースツリーとデスティネーションツリーの対応関係を管理する。定義ファイル生成部８６は、ユーザが定義ファイルを生成するためのグラフィカルユーザインターフェースを提供する。【００２３】  ＶＣユニット８０は、ソースツリーとデスティネーションツリーの間のコネクションを監視し、表示を担当するプラグインにより提供されるユーザインタフェースを介してユーザから編集指示を受け付けると、まずソースツリーの該当するノードを変更する。ＤＯＭユニット３０が、ソースツリーが変更された旨のミューテーションイベントを発行すると、ＶＣユニット８０は、そのミューテーションイベントを受けて、ソースツリーの変更にデスティネーションツリーを同期させるべく、変更されたノードに対応するデスティネーションツリーのノードを変更する。デスティネーションツリーを表示／編集するプラグイン、例えばＨＴＭＬユニット５０は、デスティネーションツリーが変更された旨のミューテーションイベントを受けて、変更されたデスティネーションツリーを参照して表示を更新する。このような構成により、少数のユーザにより利用されるローカルなボキャブラリにより記述された文書であっても、他のメジャーなボキャブラリに変換することで、文書を表示することができるとともに、編集環境が提供される。【００２４】  文書処理装置２０により文書を表示又は編集する動作について説明する。文書処理装置２０が処理対象となる文書を読み込むと、ＤＯＭ生成部３４が、そのＸＭＬ文書からＤＯＭツリーを生成する。また、主制御ユニット２２又は編集ユニット２４は、名前空間を参照して文書を記述しているボキャブラリを判別する。そのボキャブラリに対応したプラグインが文書処理装置２０にインストールされている場合は、そのプラグインをロードして、文書を表示／編集させる。プラグインがインストールされていない場合は、マッピングの定義ファイルが存在するか否かを確認する。定義ファイルが存在する場合、定義ファイル取得部８４が定義ファイルを取得し、その定義に従って、デスティネーションツリーが生成され、マッピング先のボキャブラリに対応するプラグインにより文書が表示／編集される。複数のボキャブラリを含む複合文書である場合は、後述するように、それぞれのボキャブラリに対応したプラグインにより、文書の該当箇所がそれぞれ表示／編集される。定義ファイルが存在しない場合は、文書のソース又はツリー構造を表示し、その表示画面において編集が行われる。【００２５】  図２は、処理対象となるＸＭＬ文書の例を示す。このＸＭＬ文書は、生徒の成績データを管理するために用いられる。ＸＭＬ文書のトップノードである構成要素「成績」は、配下に、生徒ごとに設けられた構成要素「生徒」を複数有する。構成要素「生徒」は、属性値「名前」と、子要素「国語」、「数学」、「理科」、「社会」を有する。属性値「名前」��、生徒の名前を格納する。構成要素「国語」、「数学」、「理科」、「社会」は、それぞれ、国語、数学、理科、社会の成績を格納する。例えば、名前が「Ａ」である生徒の国語の成績は「９０」、数学の成績は「５０」、理科の成績は「７５」、社会の成績は「６０」である。以下、この文書で使用されているボキャブラリ（タグセット）を、「成績管理ボキャブラリ」と呼ぶ。【００２６】  本前提技術の文書処理装置２０は、成績管理ボキャブラリの表示／編集に対応したプラグインを有しないので、この文書をソース表示、ツリー表示以外の方法で表示するためには、前述したＶＣ機能が用いられる。すなわち、成績管理ボキャブラリを、プラグインが用意された別のボキャブラリ、例えば、ＨＴＭＬやＳＶＧなどにマッピングするための定義ファイルを用意する必要がある。ユーザ自身が定義ファイルを作成するためのユーザインターフェースについては後述することにして、ここでは、既に定義ファイルが用意されているとして説明を進める。【００２７】  図３は、図２に示したＸＭＬ文書をＨＴＭＬで記述された表にマッピングする例を示す。図３の例では、成績管理ボキャブラリの「生徒」ノードを、ＨＴＭＬにおける表（「TABLE」ノード）の行（「TR」ノード）に対応づけ、各行の第１列には属性値「名前」を、第２列には「国語」ノードの要素値を、第３列には「数学」ノードの要素値を、第４列には「理科」ノードの要素値を、第５列には「社会」ノードの要素値を、それぞれ対応付ける。これにより、図２に示したＸＭＬ文書を、ＨＴＭＬの表形式で表示することができる。また、これらの属性値及び要素値は、編集可能であることが指定されており、ユーザがＨＴＭＬによる表示画面上で、ＨＴＭＬユニット５０の編集機能により、これらの値を編集することができる。第６列には、国語、数学、理科、社会の成績の加重平均を算出する演算式が指定されており、生徒の成績の平均点が表示される。このように、定義ファイルに演算式を指定可能とすることにより、より柔軟な表示が可能となり、編集時のユーザの利便性を向上させることができる。なお、第６列は、編集不可であることが指定されており、平均点のみを個別に編集することができないようにしている。このように、マッピング定義において、編集の可否を指定可能とすることにより、ユーザの誤操作を防ぐことができる。【００２８】  図４（ａ）及び図４（ｂ）は、図２に示したＸＭＬ文書を図３に示した表にマッピングするための定義ファイルの例を示す。この定義ファイルは、定義ファイル用に定義されたスクリプト言語により記述される。定義ファイルには、コマンドの定義と、表示のテンプレートが記述されている。図４（ａ）（ｂ）の例では、コマンドとして、「生徒の追加」と「生徒の削除」が定義されており、それぞれ、ソースツリーにノード「生徒」を挿入する操作と、ソースツリーからノード「生徒」を削除する操作が対応付けられている。また、テンプレートとして、表の第１行に「名前」、「国語」などの見出しが表示され、第２行以降に、ノード「生徒」の内容が表示されることが記述されている。ノード「生徒」の内容を表示するテンプレート中、「text-of」と記述された項は「編集可能」であることを意味し、「value-of」と記述された項は「編集不可能」であることを意味する。また、ノード「生徒」の内容を表示する行のうち、第６列には、「(src:国語 + src:数学 + src:理科 + src:社会) div 4」という計算式が記述されており、生徒の成績の平均が表示されることを意味する。【００２９】  図５は、図２に示した成績管理ボキャブラリで記述されたＸＭＬ文書を、図３に示した対応によりＨＴＭＬにマッピングして表示した画面の例を示す。表９０の各行には、左から、各生徒の名前、国語の成績、数学の成績、理科の成績、社会の成績、及び平均点が表示されている。ユーザは、この画面上で、ＸＭＬ文書を編集することができる。たとえば、第２行第３列の値を「７０」に変更すると、このノードに対応するソースツリーの要素値、すなわち、生徒「Ｂ」の数学の成績が「７０」に変更される。このとき、ＶＣユニット８０は、デスティネーションツリーをソースツリーに追従させるべく、デスティネーションツリーの該当箇所を変更し、ＨＴＭＬユニット５０が、変更されたデスティネーションツリーに基づいて表示を更新する。したがって、画面上の表においても、生徒「Ｂ」の数学の成績が「７０」に変更され、更に、平均点が「５５」に変更される。【００３０】  図５に示した画面には、図４（ａ）（ｂ）に示した定義ファイルに定義されたように、「生徒の追加」及び「生徒の削除」のコマンドがメニューに表示される。ユーザがこれらのコマンドを選択すると、ソースツリーにおいて、ノード「生徒」が追加又は削除される。このように、本前提技術の文書処理装置２０では、階層構造の末端の構成要素の要素値を編集するのみではなく、階層構造を編集することも可能である。このようなツリー構造の編集機能は、コマンドの形でユーザに提供されてもよい。また、例えば、表の行を追加又は削除するコマンドが、ノード「生徒」を追加又は削除する操作に対応づけられてもよい。また、他のボキャブラリを埋め込むコマンドがユーザに提供されてもよい。この表を入力用テンプレートとして、穴埋め形式で新たな生徒の成績データを追加することもできる。以上のように、ＶＣ機能により、ＨＴＭＬユニット５０の表示／編集機能を利用しつつ、成績管理ボキャブラリで記述された文書を編集することが可能となる。【００３１】  図６は、ユーザが定義ファイルを生成するために、定義ファイル生成部８６がユーザに提示するグラフィカルユーザインタフェースの例を示す。画面左側の領域９１には、マッピング元のＸＭＬ文書がツリー表示されている。画面右側の領域９２には、マッピング先のＸＭＬ文書の画面レイアウトが示されている。この画面レイアウトは、ＨＴＭＬユニット５０により編集可能となっており、ユーザは、画面右側の領域９２において、文書を表示するための画面レイアウトを作成する。そして、例えば、マウスなどのポインティングデバイスにより、画面左側の領域９１に表示されたマッピング元のＸＭＬ文書のノードを、画面右側の領域９２に表示されたＨＴＭＬによる画面レイアウト中へドラッグ＆ドロップ操作を行うことにより、マッピング元のノードと、マッピング先のノードとのコネクションが指定される。例えば、要素「生徒」の子要素である「数学」を、ＨＴＭＬ画面の表���０の第１行第３列にドロップすると、「数学」ノードと、３列目の「ＴＤ」ノードの間にコネクションが張られる。各ノードには、編集の可否が指定できるようになっている。また、表示画面中には、演算式を埋め込むこともできる。画面の編集が終わると、定義ファイル生成部８６は、画面レイアウトとノード間のコネクションを記述した定義ファイルを生成する。【００３２】  ＸＨＴＭＬ、ＭａｔｈＭＬ、ＳＶＧなどの主要なボキャブラリに対応したビューワやエディタは既に開発されているが、図２に示した文書のようなオリジナルなボキャブラリで記述された文書に対応したビューワやエディタを開発するのは現実的でない。しかし、上記のように、他のボキャブラリにマッピングするための定義ファイルを作成すれば、ビューワやエディタを開発しなくても、ＶＣ機能を利用して、オリジナルなボキャブラリで記述された文書を表示・編集することができる。【００３３】  図７は、定義ファイル生成部８６により生成された画面レイアウトの他の例を示す。図７の例では、成績管理ボキャブラリで記述されたＸＭＬ文書を表示するための画面に、表９０と、円グラフ９３が作成されている。この円グラフ９３は、ＳＶＧにより記述される。後述するように、本前提技術の文書処理装置２０は、一つのＸＭＬ文書内に複数のボキャブラリを含む複合文書を処理することができるので、この例のように、ＨＴＭＬで記述された表９０と、ＳＶＧで記述された円グラフ９３とを、一つの画面上に表示することができる。【００３４】  図８は、文書処理装置２０によるＸＭＬ文書の編集画面の一例を示す。図８の例では、一つの画面が複数に分割されており、それぞれの領域において、処理対象となるＸＭＬ文書を異なる複数の表示形式により表示している。領域９４には、文書のソースが表示されており、領域９５には、文書のツリー構造が表示されており、領域９６には、図５に示したＨＴＭＬにより記述された表が表示されている。これらのいずれの画面上においても、文書の編集が可能であり、いずれかの画面上でユーザが編集を行うと、ソースツリーが変更され、それぞれの画面の表示を担当するプラグインが、ソースツリーの変更を反映すべく画面を更新する。具体的には、ソースツリーの変更を通知するミューテーションイベントのリスナーとして、それぞれの編集画面の表示を担当するプラグインの表示部を登録しておき、いずれかのプラグイン又はＶＣユニット８０によりソースツリーが変更されたときに、編集画面を表示中の全ての表示部が、発行されたミューテーションイベントを受け取って画面を更新する。このとき、プラグインがＶＣ機能により表示を行っている場合は、ＶＣユニット８０がソースツリーの変更に追従してデスティネーションツリーを変更した後、変更されたデスティネーションツリーを参照してプラグインの表示部が画面を更新する。【００３５】  例えば、ソース表示及びツリー表示を、専用のプラグインにより実現している場合は、ソース表示用プラグインとツリー表示用プラグインは、デスティネーションツリーを用いず、直接ソースツリーを参照して表示を行う。この場合、いずれかの画面において編集が行われると、ソース表示用プラグインとツリー表示用プラグイ��は、変更されたソースツリーを参照して画面を更新し、領域９６の画面を担当しているＨＴＭＬユニット５０は、ソースツリーの変更に追従して変更されたデスティネーションツリーを参照して画面を更新する。【００３６】  ソース表示及びツリー表示は、ＶＣ機能を利用して実現することもできる。すなわち、ソース、ツリー構造をＨＴＭＬによりレイアウトし、そのＨＴＭＬにＸＭＬ文書をマッピングして、ＨＴＭＬユニット５０により表示してもよい。この場合、ソース形式、ツリー形式、表形式の３つのデスティネーションツリーが生成されることになる。いずれかの画面において編集が行われると、ＶＣユニット８０は、ソースツリーを変更した後、ソース形式、ツリー形式、表形式の３つのデスティネーションツリーをそれぞれ変更し、ＨＴＭＬユニット５０は、それらのデスティネーションツリーを参照して、３つの画面を更新する。【００３７】  このように、一つの画面上に複数の表示形式で文書を表示することにより、ユーザの利便性を向上させることができる。例えば、ユーザは、ソース表示又はツリー表示により文書の階層構造を把握しつつ、表９０などを用いて視覚的に分かりやすい形式で文書を表示し、編集することができる。上記の例では、一つの画面を分割して複数の表示形式による画面を同時に表示したが、一つの画面に一つの表示形式による画面を表示し、表示形式をユーザの指示により切り替え可能としてもよい。この場合、主制御ユニット２２が、ユーザから表示形式の切り替え要求を受け付け、各プラグインに指示して表示を切り替える。【００３８】  図９は、文書処理装置２０により編集されるＸＭＬ文書の他の例を示す。図９に示したＸＭＬ文書では、ＳＶＧ文書の「foreignObject」タグの中にＸＨＴＭＬ文書が埋め込まれており、さらに、ＸＨＴＭＬ文書の中にＭａｔｈＭＬで記述された数式が入っている。このような場合、編集ユニット２４が、名前空間を参照して、適切な表示系に描画作業を振り分ける。図９の例では、編集ユニット２４は、まず、ＳＶＧユニット６０に四角形を描画させ、つづいて、ＨＴＭＬユニット５０にＸＨＴＭＬ文書を描画させる。さらに、図示しないＭａｔｈＭＬユニットに、数式を描画させる。こうして、複数のボキャブラリを包含する複合文書が適切に表示される。表示結果を図１０に示す。【００３９】  文書編集中、カーソル（キャリッジ）の位置に応じて、表示されるメニューを切り替えてもよい。すなわち、カーソルが、ＳＶＧ文書が表示された領域内に存在するときは、ＳＶＧユニット６０が提供するメニュー、又はＳＶＧ文書をマッピングするための定義ファイルに定義されたコマンドを表示し、カーソルが、ＸＨＴＭＬ文書が表示された領域内に存在するときは、ＨＴＭＬユニット５０が提供するメニュー、又はＸＨＴＭＬ文書をマッピングするための定義ファイルに定義されたコマンドを表示する。これにより、編集位置に応じて適切なユーザインターフェースを提供することができる。【００４０】  複合文書において、あるボキャブラリに対応する適切なプラグイン又はマッピング定義ファイルがなかった場合は、そのボキャブラリにより記述された部分は、ソース表示又はツリー表示されてもよい。従来、ある文書に他の文書を埋め込んだ複合文書を開くとき、埋め込まれた文書を表示するアプリケーションがインストールされていないと、その内容を表示することができなかったが、本前提技術では、表示用のアプリケーションが存在しなくても、テキストデータにより構成されたＸＭＬ文書をソース表示又はツリー表示することにより内容を把握することができる。これは、テキストベースであるＸＭＬなどの文書ならではの特徴といえる。【００４１】  データがテキストベースで記述されることの他の利点として、例えば、複合文書中の、あるボキャブラリにより記述される部分において、同一文書内の他のボキャブラリで記述された部分のデータを参照してもよい。また、文書内で検索を実行する時に、ＳＶＧなどの図に埋め込まれた文字列も検索対象とすることができる。【００４２】  あるボキャブラリにより記述された文書内に、他のボキャブラリのタグを用いてもよい。このＸＭＬ文書は、妥当（valid）ではないが、整形式（well-formed）であれば、有効なＸＭＬ文書として処理可能である。この場合、挿入された他のボキャブラリのタグは、定義ファイルによりマッピングされてもよい。例えば、ＸＨＴＭＬ文書中に、「重要」、「最重要」などのタグを使用し、これらのタグで囲まれた部分を強調表示してもよいし、重要度の順にソートして表示してもよい。【００４３】  図１０に示した編集画面において、ユーザにより文書が編集されると、編集された部分を担当するプラグイン又はＶＣユニット８０がソースツリーを変更する。ソースツリーには、ノードごとにミューテーションイベントのリスナーを登録できるようになっており、通常は、各ノードが属するボキャブラリに対応したプラグインの表示部又はＶＣユニット８０がリスナーとして登録される。ＤＯＭ提供部３２は、ソースツリーが変更されると、変更されたノードから上位の階層へたどって、登録されたリスナーがあれば、そのリスナーへミューテーションイベントを発行する。例えば、図９に示した文書において、＜ｈｔｍｌ＞ノードの下位のノードが変更された場合、＜ｈｔｍｌ＞ノードにリスナーとして登録されたＨＴＭＬユニット５０にミューテーションイベントが通知されるとともに、その上位の＜ｓｖｇ＞ノードにリスナーとして登録されたＳＶＧユニット６０にもミューテーションイベントが通知される。このとき、ＨＴＭＬユニット５０は、変更されたソースツリーを参照して表示を更新する。ＳＶＧユニット６０は、自身のボキャブラリに属するノードが変更されていないので、ミューテーションイベントを無視してもよい。【００４４】  編集の内容によっては、ＨＴＭＬユニット５０による表示の更新に伴って、全体のレイアウトが変わる可能性がある。この場合は、画面のレイアウトを管理する構成、例えば最上位のノードの表示を担当するプラグインにより、プラグインごとの表示領域のレイアウトが更新される。例えば、ＨＴＭＬユニット５０による表示領域が以前より大きくなった場合、ＨＴＭＬユニット５０は、まず自身の担当する部分を描画して、表示領域の大きさを決定する。そして、画面のレイアウトを管理する構成に、変更後の表示領域の大きさを通知し、レイアウトの更新を依頼する。画面のレイアウトを管理する構成は、通知を受けて、プラグインごとの表示領域を再レイアウトする。こうして、編集された部分の表示が適切に更新されるとともに、画面全体のレイアウトが更新される。【００４５】  つづいて、後述する実施の形態において、データベースシステムから取得したデータを表示する画面を自動生成する機能の詳細について説明する。ここで説明するデータ処理装置は、データを表示するための定義ファイルを自動生成して、データを表示する画面を生成する。まず、図１１において本実施例における定義ファイル生成過程を概観したあと、図１２以降において表示態様を中心として説明する。【００４６】  図１１は、本実施例における定義ファイル生成過程を説明するための模式図である。  データ処理装置は、編集対象となるＸＭＬ文書ファイル（以下、「ソースファイル」とよぶ）と、ソースファイルの要素構造を定義するスキーマファイルを取得する。ここでいうスキーマファイルとは、ＸＭＬ−Ｓｃｈｅｍａ、ＤＴＤ（Document Type Definition）などの仕様にしたがって記述される。生成物としての定義ファイルは、このソースファイルを編集するために適切な表示レイアウト情報をもつデスティネーションファイルを生成するためのファイルである。デスティネーションファイルは、前提技術で説明したデスティネーションツリーをファイル化したものであるといえる。【００４７】  データ処理装置は、スキーマファイルがあるときには、スキーマファイルからバインディングファイル（Binding File）を生成する。バインディングファイルは、デスティネーションファイルにおける表示レイアウトを編集するために使用される。スキーマファイルがなければ、データ処理装置はソースファイル本体から要素とその構造を抽出してバインディングファイルを生成する。この場合、データ処理装置は、ソースファイルのルート要素からツリートラバース（tree traverse）方式によって子要素を抽出することにより、要素とその構造を抽出する。  更に、バインディングファイルによって、ソースファイルの要素に関する規則を再定義可能である。たとえば、ソースファイルからバインディングファイルを生成する場合において、ソースファイル中の要素Ａは、子要素Ｂを４つ持っているとする。このとき、バインディングファイルには、要素Ａの持ち得る子要素Ｂの数は４個までであるという規則が一応記載される。ユーザはバインディングファイルが提供するメソッドを介して、この要素Ａと子要素Ｂに関する規則を再定義できる。たとえば、要素Ａが持ち得る子要素Ｂの数は、１〜１０までとして定義してもよい。スキーマファイルからバインディングファイルが生成される場合であっても、スキーマファイルにおいて定義されている規則の範囲内において、このような要素に関する規則を再定義できてもよい。  このようにバインディングファイルは、要素に関する規則と、それを定義するための機能も提供する。  なお、以下においては、スキーマファイルからソースファイルの要素構造を示すスキーマ情報を取得するものとして説明する。【００４８】  ユーザは、データ処理装置にてバインディングファイルを編集可能である。バインディングファイルに対して、ユーザはデスティネーションファイルの基本的な表示レイアウ���をＧＵＩ（Graphical User Interface）により設定できる。こうして、バインディングファイルで定義された表示レイアウト情報をスキーマ情報の各要素に適用することによりレイアウトファイルが生成される。レイアウトファイルは、スキーマファイルに含まれていた各要素の具体的な表示レイアウトを示すＨＴＭＬファイルである。なお、レイアウトファイルは、タグによって構造化されるタイプの構造化文書ファイルに限られる必要はなく、表計算アプリケーションやプレゼンテーション用アプリケーションのように表示レイアウト情報を含むファイルであればよい。ユーザはレイアウトファイルそのものを編集することにより、表示レイアウトを更に精緻に編集できる。本実施例においては、バインディングファイルによって、デスティネーションファイルの表示レイアウトの基本設定を行い、レイアウトファイルによってその詳細設定を行う。【００４９】  バインディングファイルに示されていた要素とレイアウトファイルの表示領域との対応関係から、ソースファイルとデスティネーションファイル間のデータ変換形式を定めるためのＸＳＬＴファイルが生成される。最後に、このＸＳＬＴファイルに基づいて、バインディングファイルに対応するソースファイルと、レイアウトファイルに対応するデスティネーションファイルの対応関係を示す定義ファイルが生成される。  以下、ユーザインタフェースを中心としてこれらの処理の流れを説明する。【００５０】  図１２、本実施例におけるスキーマファイルを示す図である。  ここに示すスキーマファイルは、後述の図１３に示すソースファイルがしたがうべき要素構造に関する規則を記述している。また、このスキーマファイルは、ＸＭＬ−Ｓｃｈｅｍａという仕様にしたがって記述されている。  同図においては、たとえば、上から３行目において、「customerList」という名前の要素に関し、そのデータ型は「customerListType」であるとして定義されている。「customerListType」というデータ型は、次行において、「sfa」という名前空間にて「listID」、「totalEstimate」、「totalNumber」、「customer」という４つの子要素を含むとして定義されている。更に、「customer」要素のデータ型は「customerType」であり、その内容も定義されている。また、「customer」要素の個数は０個以上として定義されている。  ソースファイルは、スキーマファイルに示される規則にしたがって記述されなければならない。スキーマファイルはソースファイルに含まれる各要素のデータ型や構造を規定するファイルであるから、ソースファイルそのものよりも要素間の構造に関するルールを理解しやすい。【００５１】  図１３は、図１２のスキーマファイルに対応するソースファイルを示す図である。  このソースファイルにおいては、「customerList」の子要素として、「listID」、「totalNumber」、「totalEstimate」および「cusutomer」が定義されている。また、これらの要素には値が含まれている。「cusutomer」要素は、３つ含まれている。【００５２】  図１４は、図１２のスキーマファイルと図１３のソースファイルに基づいて生成される定義ファイルを示す図である。  同図は定義ファイルの一部を示している。ここに示す定義ファイルにおいては、「sfa:customerList/sfa:listID」や「sfa:customerList/sfa:totalNumber」といった、���ースファイルにおける各要素をＸＨＴＭＬ形式のデスティネーションファイルに変換するためのルールが記述されている。本実施例におけるデータ処理装置は、直感的なユーザインタフェースにてこの定義ファイルを簡易に生成できる。【００５３】  図１５は、バインディングファイルの編集画面を示す図である。  データ処理装置は、スキーマファイルから生成したバインディングファイルを同図に示す所定形式にて画像表示させる。同図下部の領域（以下、「プロパティ領域」）には、スキーマファイルに示されていた各要素がツリー表示されるとともに、そのデータ型なども編集可能に表示される。プロパティ領域において、要素名に付されたチェックボックスにチェックを入れることによってその子要素を展開表示させることができる。このような態様によれば、スキーマファイルに膨大な数の要素が定義されているときであっても、編集対象となる要素だけに表示対象を絞ることができる。【００５４】  データ処理装置は、各要素に対して一意にＩＤを設定する。たとえば、「listID」という要素には「L1」というＩＤが設定されている。ＩＤは、要素名の頭文字の「L」と通し番号の「１」をあわせることにより決定されている。また、データ処理装置は、各要素に対して一意にサンプル値を設定する。「listID」という要素には「2005-G30182」というサンプル値が設定されている。同図中央上部には、これらの要素の表示形式を定義するための領域（以下、「レイアウト領域」）が設けられている。ユーザはレイアウト領域において、各要素のＩＤを配列することにより、レイアウトファイルに反映させることができる。レイアウト領域とレイアウトファイルの関係については図２４以降に関連して詳述する。なお、図１５のプロパティ領域中段において、要素「customer」をテーブル形式で表示させるように表示形式が指定されている。この指定が、次の図１６に示すレイアウトファイルに反映される。【００５５】  図１６は、図１５におけるバインディングファイルの編集結果に基づくレイアウトファイル編集画面を示す図である。  図１５における指定にしたがって、要素「customer」の子要素はテーブル形式で表示されている。たとえば、スキーマファイルの要素「customerList/customer/name」は、レイアウトファイルに示されるテーブルのもっとも左の表示領域に対応している。また、このときの表示形式は、図１５のレイアウト領域における設定が反映される。ユーザは、この編集画面においてレイアウトファイルをいわゆるＷＹＳＩＷＹＧ（What You See Is What You Get）にて編集できる。【００５６】  こうして、スキーマファイルに示される各要素の表示レイアウトがレイアウトファイルとして保存される。データ処理装置は、このようなスキーマファイルの要素とレイアウトファイルの要素の対応関係からＸＳＬＴファイルを生成し、更に、前提技術で説明した定義ファイルを生成する。【００５７】  ユーザは、レイアウトファイルの編集画面において、要素の表示位置をドラッグアンドドロップによって変更できる。すでに定義ファイルが生成された後の編集であれば、データ処理装置は、スキーマファイルの要素とレイアウトファイルの表示位置の対応関係の変化を定義ファイルに反映させなければならない。データ��理装置は、レイアウトファイルにおけるサンプル値とスキーマファイルの要素との対応関係を監視している。このため、レイアウトファイルにおける要素の位置が変更されても、サンプル値の位置に応じて定義ファイルを更新できる。ここでレイアウトファイルに含まれる各表示要素は、サンプル値によって特定される。そのため、ＸＳＬＴファイルを生成するときには、レイアウトファイルにおけるサンプル値をキーとして、対応関係が再定義される。【００５８】  図１７は、図１６における編集結果に基づいたデスティネーションファイルを表示させたときの画面図である。  ソースファイルから定義ファイルにしたがってデスティネーションファイルが生成される。図１６は、このデスティネーションファイルを表示させた画面である。ソースファイルの要素「customer」は３つあったので、図１６のテーブル形式にしたがって３つの「customer」要素が表示されている。ユーザは、図１７の画面を介してソースファイルのデータを編集できる。この仕組みは、前提技術でボキャブラリコネクションとして説明した仕組みである。【００５９】  図１８は、バインディングファイルの編集画面の別例を示す図である。  同図のプロパティ領域中段においては、要素「customer」をリスト形式で表示させるように指定されている点が図１５と異なる。【００６０】  図１９は、図１８におけるバインディングファイルの編集結果に基づくレイアウトファイル編集画面を示す図である。  図１８における表示形式の指定にしたがって、要素「customer」の子要素はリスト形式で表示されている。このように、バインディングファイルにおける表示形式の指定にしたがって、レイアウトファイルも変化する。  同図の場合、スキーマファイルの要素「customerList/customer/name」は、レイアウトファイルに示される各リストの先頭要素に対応している。データ処理装置は、このようなスキーマファイルの要素とレイアウトファイルの要素の対応関係から前提技術で説明した定義ファイルを生成する。【００６１】  図２０は、図１９における編集結果に基づいたデスティネーションファイルを表示させたときの画面図である。  ソースファイルの要素「customer」は３つあったので図１８のリスト形式にしたがって３つの要素「customer」の内容がリスト表示されている。ユーザは、図２０の画面を介してソースファイルを編集できる。【００６２】  図２１は、バインディングファイルの編集画面の更に別例を示す図である。  同図においては、要素「totalNumber」の値を算出するための計算式として「count(N1)」がユーザからの編集操作により設定されている。「N1」はすなわち要素「name」のＩＤであるから、要素「totalNumber」の値は、ソースファイルにおける要素「name」の数である。また、要素「totalEstimate」の値を算出するための計算式として「sum(E1)」が設定されている。「E1」はすなわち要素「estimate」のＩＤであるから、要素「totalEstimate」の値は、ソースファイルにおける要素「estimate」の値の合計値である。このように、バインディングファイルの編集画面においては、長い要素名ではなくＩＤ値によって各要素をシンプルな入力形式にて取り扱うことができる。【００６３】  図２２は、図２１におけるバインディングファイルの編集結果に基づくレイア���トファイル編集画面を示す図である。図２２は図１６とかわるところはない。【００６４】  図２３は、図２２における編集結果に基づいたデスティネーションファイルを表示させたときの画面図である。  「totalNumber」という項目には「３」、すなわち、ソースファイルにおける要素「name」の数が表示されている。同様に、「totalEstimate」という項目には「８０００」、すなわち、ソースファイルにおける要素「estimate」の値を合計値（１０００＋３５００＋３５００＝８０００）が表示されている。【００６５】  図２４は、バインディングファイルの編集画面の更に別例を示す図である。  ここでは、図１２に示したスキーマファイルとは別のスキーマファイルを例にとって説明する。  同図に示すように、ユーザは、レイアウト領域においてＩＤを配列することにより、レイアウトファイルにおける基本的なレイアウトを設定できる。バインディングファイルが表示されるとき、レイアウト領域には、各要素のＩＤが初期設定として配列される。このときの配列は、スキーマファイルにおける要素構造を反映した配列であってもよい。たとえば、親子、あるいは、兄弟の関係にある要素同士は、表示位置が近くなるように配列されてもよい。また、「totalNumber」、「Number」、「subtotalNumber」のように、要素名が近いときには、これらの要素同士は、表示位置が近くなるように配列されてもよい。このようにＩＤの配列を初期設定する、最初から配列を作成するよりも、レイアウト作成の省力化を図ることができる。【００６６】  図２５は、図２４におけるバインディングファイルの編集結果に基づくレイアウトファイル編集画面を示す図である。  レイアウトファイルにおいては、図２４のレイアウト領域の編集内容にしたがって各要素が表示されている。【００６７】  図２６は、図２５における編集結果に基づいたデスティネーションファイルを表示させたときの画面図である。【００６８】  図２７も、定義ファイル生成過程を更に説明するための模式図である。  同図について付言すると、バインディングファイルに対するユーザの編集操作によって、バインディングファイルに補完的な情報が付加される。たとえば、要素に関する規則の定義や再定義などである。このバインディングファイルをもとにして、定義ファイルが生成されるが、定義ファイルの代わりに、ＸＳＬＴファイルが生成されてもよい。そのほかにも、ソースファイルとデスティネーションファイル間のデータマッピングを実現するためのオブジェクト、たとえば、Ｊａｖａ（登録商標）のオブジェクトが生成されてもよい。【００６９】（実施の形態）  図２８は、実施の形態に係るデータ処理システムの構成を示す。本実施の形態では、前提技術で説明した文書処理装置２０と、実施の形態に係るデータベースシステム７０の連携システムが、標準化されたＸＭＬスキーマによって部品化された情報や、これまで企業内で長年蓄積されてきた貴重なデータ資源を自由自在に組み合わせて、より高度な情報化要求に答えられるアプリケーションを簡単に開発できる環境であることを解説する。そして、この環境の登場によって、ビジネスにおける迅速で品質の高い意志決定を行うことを可能にし、また、ネットワーク環境における個人のコンピューテ��ング環境においても、ニーズにあった最適なサービスが即座に提供されうる新たなインフラへと進化できることを解説する。【００７０】  文書処理装置２０は、ＸＭＬによる情報の標準化・部品化を見据えて、様々な形式のＸＭＬボキャブラリをＸＭＬオブジェクトとして自由に無制限に組み合わせてアプリケーションを作成することができるように設計されている。それは、あたかもパレットの上で色を自由に組み合わせキャンバスに自在に絵を描くかのように、目的の情報を組み合わせた高度に統合されたアプリケーションを手に入れることができる。【００７１】  このような環境においては、情報を格納するシステムにも高い能力が求められる。ＸＭＬ形式の情報に対する高いコンピューティングの要求はもとより、従来からＲＤＢに蓄えられたデータ資源も透過的に取り扱い、様々なデータを複合的に取り扱う要求が高まってくる。本実施の形態のデータベースシステム７０は、その内部に蓄積されたＲＤＢ資源とＸＭＬＤＢ資源をＳＱＬとＸ−Ｑｕｅｒｙの双方から自由にアクセスし、いずれの形式のデータとしても入出力可能なハイブリッドな構成となっている。【００７２】  従来の企業情報システムが、基幹系を中心に発展し、処理結果を提供するスタイルが中心であったのに対して、文書処理装置２０を使ったエンタープライズアプリケーションは、情報統合とアプリケーション統合を実現する。アプリケーションの利用者が、情報を自らの意図で処理し、意志決定し、ビジネスを成功に導くシステムとなる。【００７３】  データベースへの問い合わせにＳＱＬ文やＸ−Ｑｕｅｒｙ文を直接プログラミングする必要はない。クエリ生成部がデータベースシステムへの問い合わせをＧＵＩで支援する。また、ボキャブラリ管理サーバのボキャブラリ辞書と連動しているので、氾濫するＸＭＬスキーマやＸＭＬスキーマの異なるＸＭＬデータ間を、無理なく活用していくことが可能になる。【００７４】  システムがいくら自由なデータ処理能力を提供しても、それを簡単にかつ効果的なＧＵＩとして表現できる仕組みが必要である。ビュー生成部は、クエリ結果を解析し、そこから半自動的にクエリ結果を表示するためのデータを生成する。【００７５】  従来のシステム開発と、本実施の形態の文書処理装置２０による開発の違いは、システムアーキテクチャや開発手順が異なるだけではなく、ビジネスの重要な変化に対してＩＴが適切に応えてゆけるかといったテーマに対して最適な解決を提供する。ダイナミックな事業構造の変化に対して、文書処理装置２０により実現されるシステムは、サーバの構成変更を強いることなくクライアントにおける情報統合を実現する。さらに、Ｗｅｂサービスを組み合わせ、ユーザ指向のリッチなアプリケーションをスピーディに提供することが可能になる。【００７６】  これまでのＲＤＢをベースとした情報システムの構築は、データベーススキーマの変更による開発工数の増加を防ぐために、小規模なプロトタイピングを行ってからデータベーススキーマの設計、ミドルウェアの開発、ＧＵＩの開発の手順で進められてきた。設計環境や開発ツールが進化した今日においても、この手順に変わりはない。この従来方法は、各フェーズの作業を確定することで修正のリスクを低減させるが、全体の行程を短縮させることは困難であった。【００７７】  文書処理装置２０とデータベースシステム７０を利用したシステム開発では、ＤＢに固定的なスキーマを構築せずに、ＸＭＬデータそのものがもつ構造情報を利用したプログラム開発が中心である。これにより開発者は情報構造を進化させながら処理プログラムを同時開発していくことができる。この方法は初期開発時の開発工程を短縮するばかりでなく、完成後の様々な変更要求にも柔軟に対応できることを示している。【００７８】  文書処理装置２０は、複数のＸＭＬスキーマを自由に、かつ無制限に組み合わせる開発方法なので、すでにある実用性の高いＸＭＬスキーマを利用しつつ、ユーザが必要とする拡張を加えて短期間に繰り返しシステムの改善を図ることができる。これにより、短期間に非常に少ない工数で開発を終えることができるばかりでなく、繰り返される改善によってニーズにあった本当に使えるシステムを提供することができる。【００７９】  クライアント側からはシングルインターフェイスでデータベースシステム７０の堅牢さに守られた企業内のあらゆるデータ資源を柔軟に扱うことが可能となり、システムの構成や維持がきわめて簡便になる。【００８０】  取り出した情報は、文書処理装置２０でユーザの要求に応じてダイナミックに組み合わせられ、マルチパーパスに自在に業務に最適な情報資産へと価値転換することができる。【００８１】  文書処理装置２０は、複数のＸＭＬボキャブラリをシームレスに複合するためのシンプルかつ強力な仕組みを持ったＸＭＬのハンドリング環境である。データベースシステム７０に格納されている多様なＸＭＬ情報を活用したり、インターネット・イントラネット上の配置先の異なるＸＭＬサービスの情報を統合できる機能を持っている。【００８２】  データベースシステム７０は、ハイブリッド型のＸＭＬＤＢである。これは、従来からあるリレーショナルデータベースのフィールドタイプに加えて「ＸＭＬ型」のフィールドタイプを拡張し、これらの型を１つのテーブル中に混在させて定義し、同一のトランザクション内で扱うことができるようになっている。また、従来からあるＲＤＢ型のテーブルもＸＭＬ形式として読み出すこともできる変換機能も備えている。【００８３】  ボキャブラリ管理サーバ７８は、ＸＭＬタグ間の意味関係を管理・共有するためのサーバプロセスである。異なるＸＭＬボキャブラリ間のタグも管理することができる。ボキャブラリ管理サーバ７８は、データベースシステム７０に格納されたＸＭＬ型のデータに付されたＸＭＬタグのうち、同種のデータの対応関係を保持する。例えば、図２に示した成績管理ボキャブラリの構成要素「生徒」の属性「名前」や、別のボキャブラリのタグ「name」などが、「名前」を格納するＸＭＬタグであるという対応関係を保持する。この対応関係は、後述するように、クエリ生成部７４が提供するＧＵＩにおいて利用される。【００８４】  クエリ生成部７４は、ＸＭＬＤＢおよびＲＤＢに対するクエリ文を対話的に生成するための標準的なＧＵＩである。クエリ生成部７４は、データベースシステム７０に保持された、マークアップ言語により構造化されたデータの構造を示す情報を取得���て提示し、提示したデータの中から文書に埋め込むデータの指定を受け付け、受け付けたデータのクエリ文を生成する。このとき、クエリ生成部７４は、ボキャブラリ管理サーバ７８からＸＭＬタグ間の対応関係を取得し、データベースシステム７０に保持された、ＸＭＬデータの構造を提示するときに、対応関係を識別可能に提示する。これにより、ユーザがタグの意味を事前に把握していなくても、クエリ生成部７４が提供するＧＵＩ上でタグの意味関係を把握することができる。このように、ボキャブラリ管理サーバ７８と連携することで、エンドユーザがＸＭＬＤＢ内にある様々なＸＭＬスキーマを事前に調べることなく、情報を入手することができるようなＧＵＩを提供する。これにより、スキーマの異なるＸＭＬデータを無理なく管理し、活用していくことが可能になる。【００８５】  ビュー生成部７２は、データベースシステム７０から受け取った検索結果を解析し表示用のビューを自動生成する。ビュー生成部７２は、前提技術で説明したように、データベースシステム７０から取得したＸＭＬデータを表示するための定義ファイルを自動生成することにより、表示用のビューを生成してもよい。ＸＭＬデータベースのクエリ結果の構造はクエリの内容によって変化する場合がある。これは、固定的なスキーマしか扱えないシステムでは、ＸＭＬデータベースの能力を十分に生かせないことを意味する。それに対し、本実施の形態の文書処理装置２０では、任意のスキーマに対してビューを自動生成することができるので、スキーマが流動的に変化する場合であっても、適切にデータを表示することができる。クエリ生成部７４は、データベースシステム７０に保持された、従来のフィールドタイプのデータ、すなわちマークアップ言語により構造化されていないデータを、マークアップ言語により構造化されたデータの形式で取得するためのクエリ文を生成可能である。したがって、文書処理装置２０は、ハイブリッド型のデータベースシステム７０に格納された任意のデータを、任意のスキーマにしたがってＸＭＬ形式で取得し、自動的にビューを生成することができる。【００８６】  データベースシステム７０への問い合わせ条件と問い合わせ結果は、データベースプラグイン７６により、データベースシステム７０と接続される。このミドルウェアによって下位のデータベースシステム７０の差異を吸収し、上位のアプリケーションのケーパビリティを確保する。【００８７】  図２９は、ＸＭＬＤＢ連携ドキュメントアプリケーションの作成過程を示す。ＸＭＬＤＢ連携ドキュメントアプリケーションは、文書処理装置２０により作成することができる。文書処理装置２０でボキャブラリコンポーネント（ＨＴＭＬユニットやＳＶＧユニットなど）やビューテンプレートを利用して目的のアプリケーションのひな形を作成する流れの中で、ＸＭＬＤＢ／ＲＤＢ接続が可能な条件記憶型ボキャブラリコンポーネントを貼り付けることで、ＤＢに蓄積したデータソースを利用可能なアプリケーションを構築することができる。【００８８】  目的に応じてレガシーシステムに蓄積されているデータソースを抽出する手法（ノウハウ）を、クエリ生成部７４のＧＵＩを利用することで、ＲＤＢ／ＸＭＬＤＢの��いも含めたＤＢシステムの差違を意識することなく指定することが可能となる。【００８９】  また、生成された条件式はアプリケーションに貼り付けられた条件記憶型ボキャブラリコンポーネントのパラメータ値として記憶される。【００９０】  また、より目的指向で情報を扱うための仕組みとして、タグ管理機能を利用することができる。これによりスキーマ毎のタグ名の違いを意識することなく、タグで管理されている情報本来の意味に重点を置いた条件文の作成ができる。また、このようなタグ管理の定義を企業内で共有することで、アプリケーションを設計する側にとっても、考慮漏れの少ない条件を設計することが容易となる。【００９１】  ＤＢアクセスの結果得られるクエリ結果中のスキーマは、呼び出し側のクエリ文や検索結果によってスキーマは動的に変更されうる。そのような出力結果を自動的に視覚化する機能としてビュー生成部７２が用意されている。【００９２】  また、業務や目的に特化した、より最適な表現を行うための機能として、ビューテンプレートを利用することができる。これにより、抽出したデータを「作成日」と「作成者」を軸にした、マップ形式で表示することも可能となる。このクエリ結果の表現方法についてもＸＭＬアプリケーションに記憶される。【００９３】  こうして生成されたＸＭＬアプリケーションは文書サーバへ登録され、ユーザが必要な時にダウンロードして利用することができる仕組みになっている。【００９４】  図３０は、ＸＭＬＤＢ連携ドキュメントアプリケーションの利用過程を示す。クライアントユーザはクライアント装置の文書処理装置２０を起動し、ＸＭＬアプリケーションの一覧から業務に応じたものを選択する。【００９５】  ＸＭＬアプリケーションが起動すると、ボキャブラリコンポーネントに記憶されている条件式でＲＤＢ／ＸＭＬＤＢにアクセスを行う。得られた最新のクエリ結果にあらかじめ表現形式が指定されている場合はその形式で、設定されていない場合はビュー生成部７２によって自動的に視覚化され、ＸＭＬアプリケーション内に表示される。【００９６】  クエリ結果を表示した状態は、その時点でのスナップショットとして「ドキュメント」保存することができる。もちろん保存したドキュメントはＸＭＬ文書であり、ＸＭＬＤＢに蓄積することで、「既存データを再利用したデータ作成」のサイクルを実現することができる。【００９７】  ドキュメントアプリケーションとして記憶している条件式やクエリ結果の表現方法は、利用者側でも自由に変更することができる。このように変更を加えたものを再びＸＭＬアプリケーションとして文書サーバへ登録することにより、同種の業務アプリケーションの開発工期短縮だけでなく、利用者側の意図をボトムアップ的に反映した業務アプリケーションの構築が可能となる。【００９８】  ダイナミックな事業構造の変化に対して、文書処理装置２０とデータベースシステム７０により実現されるシステムは、クライアントにおける情報統合だけではなく、さまざまなＸＭＬソースと組み合わせ、ユーザ指向のリッチなアプリケーションをスピーディに提供することが可能になる。そして、企業内のユーザが社内の情報資産を活用し、競争力を高めるコラボレーションを実現する環境も提供することができる。データ資源を企業内で最適に利用するためのインフラは、情報資産とアプリケーション資産をユーザが最適に活用するインフラを提供するＸＭＬアプリケーション時代へ進化する。【００９９】  以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【産業上の利用可能性】
【０１００】  本発明は、構造化された文書を処理する文書処理装置に利用可能である。
【図１】
2007081017.tif 000003
【図２】
2007081017.tif 000004
【図３】
2007081017.tif 000005
【図４（ａ）】
2007081017.tif 000006
【図４（ｂ）】
2007081017.tif 000007
【図５】
2007081017.tif 000008
【図６】
2007081017.tif 000009
【図７】
2007081017.tif 000010
【図８】
2007081017.tif 000011
【図９】
2007081017.tif 000012
【図１０】
2007081017.tif 000013
【図１１】
2007081017.tif 000014
【図１２】
2007081017.tif 000015
【図１３】
2007081017.tif 000016
【図１４】
2007081017.tif 000017
【図１５】
2007081017.tif 000018
【図１６】
2007081017.tif 000019
【図１７】
2007081017.tif 000020
【図１８】
2007081017.tif 000021
【図１９】
2007081017.tif 000022
【図２０】
2007081017.tif 000023
【図２１】
2007081017.tif 000024
【図２２】
2007081017.tif 000025
【図２３】
2007081017.tif 000026
【図２４】
2007081017.tif 000027
【図２５】
2007081017.tif 000028
【図２６】
2007081017.tif 000029
【図２７】
2007081017.tif 000030
【図２８】
2007081017.tif 000031
【図２９】
2007081017.tif 000032
【図３０】
2007081017.tif 000033
【国際調査報告】
2007081017.tif 000034
2007081017.tif 000035
2007081017.tif 000036