JP2007086830A - データ処理装置 - Google Patents

Abstract

【課題】マークアップ言語により構造化されたデータを適切に処理する技術を提供する。
【解決手段】マークアップ言語により構造化されたデータを処理するコンポーネントＡ及びコンポーネントＢは、それぞれ、他のコンポーネントとの間でデータ連携を設定するための定義情報をＸＭＬ文書として有している。ＶＣＤ生成機能は、ＸＭＬ文書を取得すると、そのＸＭＬ文書を編集するためのＧＵＩを自動的に生成する。ユーザは、ＶＣＤ生成機能により生成されたＧＵＩを用いて、パラメータ定義情報を記述するＸＭＬ文書を編集し、コンポーネント間のデータ連携を設定する。
【選択図】図３９

Description

本発明は、データ処理技術に関し、特に、マークアップ言語により記述された文書を処理するためのユーザインタフェイスを生成するデータ処理装置に関する。

ＸＭＬは、ネットワークなどを介して他者とデータを共有するのに適した形式として注目されており、ＸＭＬ文書を作成、表示、編集するためのアプリケーションが開発されている（たとえば、特許文献１参照）。ＸＭＬ文書は、文書型定義などにより定義されたボキャブラリ（タグセット）に基づいて作成されている。
特開２００１−２９０８０４号公報

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

本発明はこうした状況に鑑みてなされたものであり、その目的は、マークアップ言語により構造化されたデータを適切に処理する技術を提供することにある。

上記課題を解決するために、本発明のある態様のデータ処理装置は、マークアップ言語により記述された文書を処理する複数の処理系の間で前記文書に含まれるデータを連携させて処理するための定義情報のデータ構造を取得し、前記データ構造に基づいて、前記定義情報を編集するためのユーザインタフェイス画面を提供するために必要な情報を生成することを特徴とする。

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

本発明によれば、マークアップ言語により構造化されたデータを適切に処理する技術を提供することができる。

（前提技術）
図１は、前提技術に係る文書処理装置２０の構成を示す。文書処理装置２０は、文書内のデータが階層構造を有する複数の構成要素に分類された構造化文書を処理するが、本前提技術では構造化文書の一例としてＸＭＬ文書を処理する例について説明する。文書処理装置２０は、主制御ユニット２２、編集ユニット２４、ＤＯＭユニット３０、ＣＳＳユニット４０、ＨＴＭＬユニット５０、ＳＶＧユニット６０、及び変換部の一例であるＶＣユニット８０を備える。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。

主制御ユニット２２は、プラグインのロードや、コマンド実行のフレームワークを提供する。編集ユニット２４は、ＸＭＬ文書を編集するためのフレームワークを提供する。文書処理装置２０における文書の表示及び編集機能は、プラグインにより実現されており、文書の種別に応じて必要なプラグインが主制御ユニット２２又は編集ユニット２４によりロードされる。主制御ユニット２２又は編集ユニット２４は、処理対象となるＸＭＬ文書の名前空間を参照して、ＸＭＬ文書がいずれのボキャブラリにより記述されているかを判別し、そのボキャブラリに対応した表示又は編集用のプラグインをロードして表示や編集を実行させる。例えば、文書処理装置２０には、ＨＴＭＬ文書の表示及び編集を行うＨＴＭＬユニット５０、ＳＶＧ文書の表示及び編集を行うＳＶＧユニット６０など、ボキャブラリ（タグセット）ごとに表示系及び編集系がプラグインとして実装されており、ＨＴＭＬ文書を編集するときはＨＴＭＬユニット５０が、ＳＶＧ文書を編集するときはＳＶＧユニット６０が、それぞれロードされる。後述するように、ＨＴＭＬとＳＶＧの双方の構成要素を含む複合文書が処理対象となっている場合は、ＨＴＭＬユニット５０とＳＶＧユニット６０の双方がロードされる。

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

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

ＤＯＭユニット３０は、ＤＯＭ提供部３２、ＤＯＭ生成部３４、及び出力部３６を含み、ＸＭＬ文書をデータとして扱うときのアクセス方法を提供するために定められた文書オブジェクトモデル（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）であれば、有効なＸＭＬ文書として処理可能である。この場合、挿入された他のボキャブラリのタグは、定義ファイルによりマッピングされてもよい。例えば、ＸＨＴＭＬ文書中に、「重要」、「最重要」などのタグを使用し、これらのタグで囲まれた部分を強調表示してもよいし、重要度の順にソートして表示してもよい。

図１０に示した編集画面において、ユーザにより文書が編集されると、編集された部分を担当するプラグイン又はＶＣユニット８０がソースツリーを変更する。ソースツリーには、ノードごとにミューテーションイベントのリスナーを登録できるようになっており、通常は、各ノードが属するボキャブラリに対応したプラグインの表示部又はＶＣユニット８０がリスナーとして登録される。ＤＯＭ提供部３２は、ソースツリーが変更されると、変更されたノードから上位の階層へたどって、登録されたリスナーがあれば、そのリスナーへミューテーションイベントを発行する。例えば、図９に示した文書において、＜ｈｔｍｌ＞ノードの下位のノードが変更された場合、＜ｈｔｍｌ＞ノードにリスナーとして登録されたＨＴＭＬユニット５０にミューテーションイベントが通知されるとともに、その上位の＜ｓｖｇ＞ノードにリスナーとして登録されたＳＶＧユニット６０にもミューテーションイベントが通知される。このとき、ＨＴＭＬユニット５０は、変更されたソースツリーを参照して表示を更新する。ＳＶＧユニット６０は、自身のボキャブラリに属するノードが変更されていないので、ミューテーションイベントを無視してもよい。

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

（実施の形態）
実施の形態では、複数のＸＭＬデータやデータ処理機能などのコンポーネントを連携させて、様々な情報分析を支援する技術について提案する。まず、第１の実施の形態において、複数の文書を処理する際に、文書間で、又は文書を処理する処理系の間で、データを連携させる技術を提案する。次に、第２の実施の形態において、ＸＭＬ文書を処理するためのＵＩを、ＸＭＬ文書のスキーマ情報などをもとに自動生成する技術を提案する。更に、第３の実施の形態では、第１の実施の形態における、コンポーネントの連携を設定するためのＵＩを、第２の実施の形態で説明するＵＩ自動生成技術を利用して生成する技術を提案する。

（第１の実施の形態）
ＸＭＬにより意味づけされた多様なデータ、又はデータ処理機能を連携させることにより、様々な情報分析をオンデマンドかつ直感的に行うことが可能となる。この機構を考えるときに、大別して以下の２点を考慮する必要がある。

まず１点目は、情報に対してどうのように意味づけをするかという方法論と、意味づけされた情報を連携する方法論である。これを、ＸＭＬデータアダプテーション機構と呼ぶ。実施の形態において、ＸＭＬデータにどのように意味づけしたものが操作の対象となり、また意味づけされた複数のデータ間の連携方法をどのように定義するかを示す。複数のデータや機能を連携させるとき、それぞれの情報は、通常、複数の構成要素から成る。したがって、それぞれのデータや機能に含まれる各要素間をどのように対応付けるかを指定しなければならないが、本実施の形態では、それを出来るだけ直感的かつ簡単に行える方法を示す。

２点目は、上述した方法を直感的に操作する為のユーザインタフェイス機構である。連携させるデータは、その内容を理解する為に、データをグラフ化する機能などの画面表示を伴う機能と連携させたり、情報を整理する為に、他の様々なデータフィルタなどと連携させる必要がある。本実施の形態では、データ、機能（表示機能、フィルタ機能など）を直感的に操作して情報を発掘する為のＵＩを提案する。

図１１は、本実施の形態に係る文書処理装置の構成を示す。本実施の形態の文書処理装置１００は、図１に示した前提技術の文書処理装置２０の構成に加えて、取得部７０、連携制御部７１、ランチャ制御部７２、レイアウト制御部７３、タイムスライダー制御部７４を備える。

取得部７０は、処理対象となる文書、その文書に対応づけられた定義ファイル、その文書を処理する各種ツールを提供する定義ファイルなどを取得する。ランチャ制御部７２は、取得した文書やツールなどをアイコン化して提示し、ユーザがアイコンをクリックしたり、ドラッグ＆ドロップしたりしたときに該当する文書やツールを起動する。レイアウト制御部７３は、ランチャ制御部７２が提示したランチャから文書が開かれたときに、画面上における文書の表示領域のレイアウトを制御する。連携制御部７１は、複数の文書が開かれたときに、それらの文書の間でデータの連携を制御する。タイムスライダー制御部７４は、文書に時間情報に対応付けられたデータが含まれていたときに、タイムスライダーを提示して時間を指定するためのインタフェイス機能を提供する。

これらの構成のうち、連携制御部７１が、上述したＸＭＬデータアダプテーション機構を担い、ランチャ制御部７２、レイアウト制御部７３、及びタイムスライダー制御部７４が、ユーザインタフェイス機構を担う。

まず、連携制御部７１により実現されるＸＭＬデータアダプテーション機構について説明する。この機構では、情報への意味づけに関して以下の仮定を行っている。

１）情報への意味づけは、情報に対して特定の意味を持ったＸＭＬタグを付与することで行う。また、この機械的処理可能なラベルによる意味づけ以外の意味は対象としない。ここで扱われるＸＭＬタグの名前は、人間がその意味を理解するのに最も適切かつ簡単な言葉で表現されているものとする。例えば、図２１に示した例では、<MFname:name>というＸＭＬタグが付与されており、これは、「名前」という意味づけがなされているといことが直感的に理解される。

２）意味づけフォーマットは、目的を特化した比較的小さな仕様のものが数多く存在する。例えば、住所、商品の情報、気候、イベントなどを表現するものなど、マイクロフォーマットと同様の考え方をする。これらのマイクロフォーマットは、できるだけ一般化され、様々な情報の表現に共通して使われるようになることが望まれる。そして、情報全体の意味は、これらマイクロフォーマットの組み合わせにより表現できるものとする。

３）上記マイクロフォーマット間の関係は、それをより抽象化した概念である上位オントロジーの元で定義する。また、特定目的の為の新たなタグを考える場合、このオントロジーの元で、関係を定義する事が望まれる。例えば、一般的な「金額」などの定義のサブクラスとして、「消費税込みの商品の価格」などといったものの定義を行うと、税抜き・税込みといった情報に対する揺れを除いた正確な処理を行うことができるようになる。

４）上記マイクロフォーマットの組み合わせを考えるときに、図２１の例のように入れ子になる可能性がある。このような構造は、そもそもＸＭＬとして認められ得るかという議論もあるが、文書処理装置２０がこのような入れ子構造を許容して処理可能であるものとする。

上述したデータを処理する機能が、どのようなデータを処理できるのかを示す為に、各機能毎にインターフェイス表現を用意する。インターフェイス表現では、この機能が理解可能なタグの一覧を提示する。ＸＭＬデータアダプテーション機構は、与えようとするデータを表現するタグと処理機能側が受け入れ可能なタグが一致する場合に、データを処理機能に結合する。

ここでのデータの対応付けで最も重要なのは軸を合わせることである。例えば、２次元散布図を表示する機能があるとき、必要なのは（Ｘ軸、Ｙ軸、（補助的な値））というデータ構造であり、データのどの部分がその対応になるかを確定する必要がある。例えば、以下のような手順により対応が確定される。

まず、各軸として受け入れ可能なタグがデータ側にあるかどうかを確認する。例えば、２次元散布図の例では、Ｘ軸とＹ軸に対応づけられるのは数値データであるから、数値を要素値として持つタグ（要素）がデータ側に存在するかどうかを確認する。ここで、各機能に用意されたインターフェイス表現においてデータを機能に対応づけるとき、ユーザが、データのどのブロックを対応づけるかを指定できるようにしてもよい。これにより、対象とするデータを明確にユーザが指定できる。

次に、軸の組み合わせを考え、求める軸の組み合わせを構成する最小のサブツリーが列挙されている構造をデータ側から探す。例えば、Ｘ軸、Ｙ軸、補助的な値の３つの軸に対応づけられる３つのＸＭＬデータのツリー上の位置は、互いに近接している可能性が高いので、サブツリーが最小となるものを最も確からしい組合せとして抽出する。

最後に、求められた軸の組み合わせから、データと機能を対応づける。ここで、オントロジーベースでの意味づけから、より適切なものを選ぶ様にする。各受け入れ要素とデータ側の項目のオントロジー的近さ（意味パスの分かれる近さ）からスコアを生成し、各軸のスコアの合計値が高いものがより適切な対応関係であると推定する。このとき、Ｘ軸とＹ軸が同じ型であるときは、どちらをどちらに対応づけるか選択が必要である。また、サブツリーの中に対応付けが可能なタグ種別が複数あるとき、また、最小ではないが、別のサブツリーの列挙も採用可能である場合など、曖昧性の解消が必要な場合がある。これは、オントロジーから求められる関係では不適切な場合もあるので、インタフェイス表現上での切り替えにより対応変更を行えるようにしてもよい。

インターフェイス表現側で受け入れ可能なタグの一覧は、そのタグと厳密に一致しなければならない場合と、解釈をゆるめて受け取れる場合とがあり、それを指定できるようにしておく。例えば、金額や人数など単位や意味を厳格に指定する場合と、数値ならば何でも良いといった場合などがある。この受け入れの自由度が高い機能は、汎用的な機能ということになる。このタグの一般化によるすりあわせは、各タグの意味づけをするオントロジーを参照して行う。オントロジーとの対応関係や定義が明確でないタグを与えられた場合は、データアダプテーション機構が持つ上位（またはドメイン）オントロジー内でそのタグ名に相当する場所を探して対応付け、そのオントロジーでの解釈に基づいてデータを対応づける。この場合、オントロジーが処理できる単語が十分にあり、またデータ側のタグ名が一般的概念として常識的かつ適切であれば、より高い精度で対応づけされると考えられる。

また、各機能が受け入れ可能なタグとして、タグのデータのデータ型や情報の物理表現などが規定されている場合に、タグ内にあるその他の情報は無視してもよい。例えば、受け入れ可能なタグが<name>であり、それを文字列として処理する場合、データ側に<name><first>Ryouma</first><Family>Sakamoto</Family></name>というタグ構造があった場合は、<name>のデータとして「RyoumaSakamoto」が文字列として受理され、その他のタグは無視される。

データ間の結合には様々な方法が考えられる。また、その方法を実現する為には、具体的な処理プログラムが必要である。本機構では、データ間の結合は、データ同士を直接結合する形はとらず、「データＡ→機能←データＢ」のようにデータを特定の機能で結びつけるようにする。この機能がデータ間の「JOIN」をするのか、「OR」をするのか、絞り込むのかなど様々な処理を規定することになる。

また、全ての機能はデータの入力と出力を持ち、ある機能の出力は別の機能の入力とすることができる。各データおよび機能間の入力部分は、インターフェイス表現とオントロジーに従ってすりあわせが行われ、データからその機能の処理に必要な部分のみが抽出されて利用される。そして、その処理結果としての出力部分は各機能が規定した形で出力される。

本システムにおける基本的な動作機構は、データフロー形式で記述することになる。このシステムは一般的なデータフロープログラミングと同様の考え方で良く、フローの循環や分岐なども問題なく表現できて良い。

次に、ランチャ制御部７２、レイアウト制御部７３、タイムスライダー制御部７４などにより実現されるＵＩ機構について説明する。上記のデータアダプテーション機構を用いて、データ処理（マイニング）を直感的に行うＵＩを以下に示す。

データマイニングＵＩには、例えば、以下の２種類がある。１つは、データや機能コンポーネントをドラッグ＆ドロップなどして、直感的にデータ操作を行う対話操作ビューである。対話操作ビューは、データを対話的に組み合わせる為のデータ処理ステージと、そのステージで組み合わせることができるコンポーネント一覧からなる。もう１つは、より詳細または複雑な動作を記述するためのプログラミングビューである。これは、バッチ処理的な分析処理を記述する場合には有効なビューである。以下、対話操作ビューについてより詳細に説明する。

データマイニングＵＩで扱うコンポーネントには以下のものがある。
１）データ
ドキュメントなど、ＸＭＬで意味記述されたデータである。データ処理ステージにドロップすると基本的な画面表示がなされ、可能であれば編集が受け付けられる。
２）データ視覚化機能
データをグラフや地図など視覚的イメージに変換する機能である。データ処理ステージでは、データを表示又は編集するウィンドウになる。
３）データ加工・変換機能
データを演算などを行い別の形式に変換したり、情報を絞り込んだりする機能である。データ処理ステージでは、データ視覚化機能に対するオーバーレイシートのような位置づけになる。
４）トリガー機能
各機能コンポーネントに対して、補助的なパラメータ操作を行う機能である。典型的な例としては、イテレーション型のデータをアニメーション的に順次フォーカスを与えるようなものが考えられる。
５）外部インターフェイス機能
外部データベースやウェブサービスと連携する機能である。ＵＩ上での基本的扱いは、データと同じ位置づけになる。
６）フロー制御機能
これは、プログラミングビューで使用される機能である。

ここにある機能コンポーネントは、利用の度に個別にパラメータを毎回設定するようにしてもよいし、ある程度頻度の高いパラメータを事前に設定してある「インスタンスコンポーネント」が列挙され、ユーザが用途に合わせてそれを選択するようにしてもよい。

データ処理ステージでのデータ・機能の結合操作は以下のような手順になる。
１）データなどのコンポーネントは、データ処理ステージにドロップすることができる。データ処理ステージでは、カレントコンポーネントに対するフォーカスがある。

２）機能コンポーネントにフォーカスがある場合は、コンポーネント一覧上で、そのコンポーネントが処理可能なデータや組み合わせ可能な機能コンポーネントへの絞り込み（または使えないもののグレーアウト）が行われる。データの場合は、その内容が表示されている場合は、利用可能な部分と利用できない部分が識別可能な形で強調表示されるのが望ましい。データコンポーネントにフォーカスがある場合は、そのデータを受け入れ可能な機能コンポーネントへの絞り込みが行われる。フォーカスがどのコンポーネントにもない場合は、全てのコンポーネントが利用可能となる。ここで、グレーアウトなどが行われるのは、コンポーネント一覧上のもののみであり、データ処理ステージのものは常時利用可能となる。これにより対応関係が自動的に把握できないコンポーネントなども手作業で利用可能にできる。

３）機能コンポーネントの上にデータをドロップすると、そのデータが機能コンポーネントで処理されて機能コンポーネント上に表示される。データの上に機能コンポーネントをドロップすると、データの表示領域が機能コンポーネントの表示領域に置き換えられて、機能処理後の内容が表示される。このとき、データ処理ステージにおいて完全に置き換えられる場合と、データ内での反応部分の表示を置き換える場合がある。また、データの上に機能コンポーネントをドロップする場合は、そのイメージをドキュメントの中に組み込む場合もある。

４）機能コンポーネントに複数のデータを次々とドロップした場合のデータ表示や処理の挙動は、各機能コンポーネントに任される。別のデータとしてオーバーレイしていく場合と、データをマージして１つの大きなデータにしていく場合などが考えられる。

５）今、どの機能とデータが組み合わされているかは、コンポーネントを表示する領域の隅にタグのような形で何が組み合わさっているかが分かるようにする。処理順序などは、このタグの順番を置き換えることで変更することができる。

６）機能コンポーネントへのオーバーレイ型のコンポーネントの場合は、データの表示位置に関する連携を行い、オーバーレイ型のコンポーネントは基本的にオーバーレイしている機能コンポーネントの表示位置指定に従う。オーバーレイをした場合のデータ表示形態は以下の方法がある。ａ）機能コンポーネントにデータを絞り込んで渡しなおす（プリ型）。ｂ）機能コンポーネントのデータ表示を全て消して独自の表示を行う（ラップ型）。ｃ）機能コンポーネントの表示に新たな表示を追加する（ポスト型）。ｄ）機能コンポーネントのパラメタを操作して表示を切り替える（トリガー型）。これらの選択は、重なっているタグの順番やオーバーレイする機能コンポーネント毎の定義に従って決定される。

データ要素間の対応付けは、上述したデータアダプテーション機構により、オントロジーベースでの同一名対応により自動的に行われる。しかし、その自動対応に選択範囲があり、対応関係が望ましくない場合は、以下の操作で対応関係の変更を受け付けてもよい。オントロジーによる概念の近さや上下関係が利用できるので、単に列挙して選択するよりも強弱を付けることが可能である。

１）設定変更が必要な機能コンポーネントのタグを右クリックするなどして、メニューを開き、対応関係の修正を指定する。
２）機能コンポーネント側で求める軸や値のリストを左に表示し、その右側にその対応関係を満たす構造の候補を列挙しておく。利用者は、候補を選択することで対応を切り替えることができる。
３）候補だけでは満足できない場合は、最も近い候補の修正したい要素をクリックするなどして選ぶ。すると、そのデータの該当構造付近を構成するタグのツリーが表示されるので、指定したいタグを選択する。
４）上記の選択は、コンポーネントやデータのスキーマ情報などと共に保存され、次回からは、優先的に採用される対応関係となる。

つづいて、上述したデータマイニングＵＩによりデータや機能などのコンポーネントを連携させる様子を、実施例をもとに説明する。

図１２は、表示画面の例を示す。画面には、デスクトップに似たデータ操作シート７５と、様々なコンポーネントを並べたコンポーネントパレット７６が表示されている。ランチャ制御部７２により提示されるコンポーネントパレット７６には、米国の白地図を挿入する機能を有する白地図ツールのアイコン７７ａ、時間を操作するタイムスライダーインタフェイスを提供する機能を有するタイムスライダーツールのアイコン７７ｂ、複数の文書データを示すアイコン７８が設けられている。

文書を示すアイコン７８は、その文書をＨＴＭＬユニット５０などの処理系により実際に処理して表示した結果を縮小表示したものであってもよい。この場合、アイコン７８上で文書の編集を行えるようにしてもよい。

まず、ユーザが、文書７８ａのアイコンをデータ操作シート７５へドラッグ＆ドロップする。このときの表示画面を図１３に示す。連携制御部７１は、文書データがデータ操作シート７５へドロップされたことを認識し、レイアウト制御部７３に、文書７８ａの表示領域を確保するよう指示するとともに、文書７８ａを表示する処理系を起動し、文書７８ａを表示させる。こうして、レイアウト制御部７３により、文書７８ａの表示領域７９ａが確保され、適切な処理系によりその表示領域７９ａに文書７８ａが表示される。

つづいて、ユーザが、文書７８ａの表示領域７９ａの空白の領域７９ｂに、白地図ツールのアイコン７７ａをドラッグ＆ドロップする。このときの表示画面を図１４に示す。連携制御部７１は、空白の領域７９ｂに白地図表示機能がドロップされたことを認識し、空白の領域に白地図を表示するよう適切な処理系へ指示する。例えば、レイアウト制御部７３により、空白の領域７９ｂに白地図が挿入される。この白地図のデータを格納した文書は、文書７８ａの中に挿入されてもよいし、文書７８ａから参照されてもよい。白地図は、例えばＳＶＧにより記述されており、ＳＶＧユニット６０により表示されてもよい。

ユーザが、渡り鳥の経路情報を記述した文書７８ｂのアイコンをデータ操作シート７５の空白領域にドラッグ＆ドロップする。このときの表示画面を図１５に示す。連携制御部７１は、文書データがデータ操作シート７５へドロップされたことを認識し、レイアウト制御部７３に、文書７８ｂの表示領域を確保するよう指示するとともに、文書７８ｂを表示する処理系を起動し、文書７８ｂを表示させる。こうして、レイアウト制御部７３により、文書７８ｂの表示領域７９ｃが確保され、適切な処理系によりその表示領域７９ｃに文書７８ｂが表示される。この場合、文書７８ｂには、渡り鳥の月別の位置を示す経度データと緯度データが格納されており、この文書７８ｂに対応づけられた定義ファイルが適用されて、文書７８ｂに記述された渡り鳥の経路情報が表形式で表示される。

ユーザが、渡り鳥の経路情報が表示された表示領域７９ｃを、白地図の表示領域７９ｂにドラッグ＆ドロップする。このときの表示画面を図１６に示す。連携制御部７１によりデータと機能の連携が張られ、文書７８ｂの経路データが、文書７８ａの表示領域７９ａに表示された白地図上に表示される。

ここで、白地図を表示した機能コンポーネントは、（緯度、経度、月）の３軸のデータを受け入れて、各月の緯度と経度により特定される地点を線で結んで経路を地図上に表示する機能を有しているものとする。ユーザが、渡り鳥の経路情報が表示された表示領域７９ｃを、白地図の表示領域７９ｂにドロップしたとき、連携制御部７１は、白地図表示コンポーネントから、受け入れ可能なタグに関する情報を取得し、文書７９ｃのデータの中から、（緯度、経度、月）の３軸に対応付けが可能なデータを抽出して、白地図表示コンポーネントに渡す。白地図表示コンポーネントは、（緯度、経度、月）の３軸のデータを受け入れ、それらをもとに経路を地図上に表示する。こうして、渡り鳥の経路が地図上に表示される。白地図表示コンポーネントがＶＣユニット８０により実行される定義ファイルにより実現される場合、文書７８ｂに記述された経度と緯度のデータを直線で結んだ図が表示されるように、文書７８ｂの経路データをＳＶＧにマッピングする定義ファイルが適用されてもよい。この定義ファイルは、文書７９ａに対応づけられた定義ファイルにインクルードされてもよい。

ユーザが、米国の気温情報を記述した文書７８ｃのアイコンをデータ操作シート７５の空白領域にドラッグ＆ドロップする。このときの表示画面を図１７に示す。連携制御部７１は、文書データがデータ操作シート７５へドロップされたことを認識し、レイアウト制御部７３に、文書７８ｃの表示領域を確保するよう指示するとともに、文書７８ｃを表示する処理系を起動し、文書７８ｃを表示させる。こうして、レイアウト制御部７３により、文書７８ｃの表示領域７９ｄが確保され、適切な処理系によりその表示領域７９ｄに文書７８ｃが表示される。この場合、文書７８ｃには、米国の各州の月別平均気温が格納されており、文書７８ｃに対応づけられた定義ファイルが適用されて、文書７８ｃに記述された気温情報が表形式で表示される。

ユーザが、米国の気温情報が表示された表示領域７９ｄを、白地図の表示領域７９ｂにドラッグ＆ドロップする。このときの表示画面を図１８に示す。連携制御部７１により、データと機能の間の連携が張られ、文書７８ｃの気温データが、文書７８ａの表示領域７９ａに表示された白地図上に表示される。

ここで、白地図を表示した機能コンポーネントは、（州名、気温、月）の３軸のデータを受け入れて、ある月の各州の気温を色別に地図上に表示する機能を有しているものとする。ユーザが、各州の気温情報が表示された表示領域７９ｄを、白地図の表示領域７９ｂにドロップしたとき、連携制御部７１は、白地図表示コンポーネントから、受け入れ可能なタグに関する情報を取得し、文書７９ｄのデータの中から、（州名、気温、月）の３軸に対応付けが可能なデータを抽出して、白地図表示コンポーネントに渡す。白地図表示コンポーネントは、（州名、気温、月）の３軸のデータを受け入れ、それらをもとに各州の気温を地図上に表示する。ここで、文書７９ｄにおいては、＜平均気温＞というタグで気温データが記述されていたとしても、白地図表示コンポーネント側が、「気温」というデータとして＜平均気温＞というタグを受け入れ可能に指定していれば、連携制御部７１により適切に連携がとられる。白地図表示コンポーネント側が、オントロジーとして、「気温」という概念のデータを受け入れ可能であると指定していてもよく、この場合は、連携制御部７１が、「気温」という概念に＜平均気温＞というタグが該当することを認識して、適切に連携をとる。こうして、各州の平均気温が地図上に表示される。白地図表示コンポーネントがＶＣユニット８０により実行される定義ファイルにより実現される場合、文書７８ｃに記述された各州の月別平均気温により色分けされた図が表示されるように、米国の白地図の各州の形状を示すＳＶＧデータの色を変更する定義ファイルが適用されてもよい。

ユーザが、タイムスライダーツールのアイコン７７ｂを、文書７８ａの表示領域７９ａにドラッグ＆ドロップする。このときの表示画面を図１９に示す。白地図表示コンポーネントが実現するタイムスライダー制御部７４により、タイムスライダー７９ｅが提示される。

ユーザが、タイムスライダーを移動させると、タイムスライダー制御部７４は、その位置に対応する時間のデータが同期して表示されるように、白地図表示コンポーネントに時間情報を通知する。このときの表示画面を図２０に示す。連携制御部７１によって、「月」のデータが白地図表示コンポーネントに与えられているので、白地図表示コンポーネントは、タイムスライダー制御部７４から通知された月の渡り鳥の位置に鳥の画像を表示させるとともに、その月の各州の平均気温を表示する。図１９においては、６月のデータが表示されていたが、図２０においては、１２月のデータが表示されている。

以上の技術により、複数の文書に含まれるデータを容易に連携させることができるので、柔軟で利便性の高い文書の処理環境を提供することができる。前提技術で説明したように、文書中のデータはＤＯＭとして保持されており、ＤＯＭユニット３０が提供するＡＰＩを利用して外部から参照可能である。そのため、文書間でデータを参照して連携させることができる。さらに、ＤＯＭユニット３０は、ＤＯＭが変更されたときに、ミューテーションイベントにより変更を通知する機能を有しているので、連携制御部７１により連携されたデータが変更された場合にも、適切に表示に反映させることができる。

（第２の実施の形態）
本実施例におけるデータ処理装置は、前提技術で説明したボキャブラリコネクションによりソースツリーとデスティネーションツリーの対応関係を示す定義ファイルを簡易に生成することができる。まず、図２２において本実施例における定義ファイル生成過程を概観したあと、図２３以降において表示態様を中心として説明する。

図２２は、本実施例における定義ファイル生成過程を説明するための模式図である。
データ処理装置は、編集対象となるＸＭＬ文書ファイル（以下、「ソースファイル」とよぶ）と、ソースファイルの要素構造を定義するスキーマファイルを取得する。ここでいうスキーマファイルとは、ＸＭＬ−Ｓｃｈｅｍａ、ＤＴＤ（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」のように、要素名が近いときには、これらの要素同士は、表示位置が近くなるように配列されてもよい。このようにＩＤの配列を初期設定する、最初から配列を作成するよりも、レイアウト作成の省力化を図ることができる。

図３６は、図３５におけるバインディングファイルの編集結果に基づくレイアウトファイル編集画面を示す図である。
レイアウトファイルにおいては、図３５のレイアウト領域の編集内容にしたがって各要素が表示されている。

図３７は、図３６における編集結果に基づいたデスティネーションファイルを表示させたときの画面図である。

図３８も、定義ファイル生成過程を更に説明するための模式図である。
同図について付言すると、バインディングファイルに対するユーザの編集操作によって、バインディングファイルに補完的な情報が付加される。たとえば、要素に関する規則の定義や再定義などである。このバインディングファイルをもとにして、定義ファイルが生成されるが、定義ファイルの代わりに、ＸＳＬＴファイルが生成されてもよい。そのほかにも、ソースファイルとデスティネーションファイル間のデータマッピングを実現するためのオブジェクト、たとえば、Ｊａｖａ（登録商標）のオブジェクトが生成されてもよい。

（第３の実施の形態）
第１の実施の形態において、データ処理機能が持つインタフェイス表現について説明した。また、コンポーネント間でデータ連携を行い、ユーザのデータ分析などを支援するためのデータマイニングＵＩについて説明した。第２の実施の形態において、ＸＭＬ文書の構造に関する情報を取得して、そのＸＭＬ文書を編集するＵＩを生成する技術について説明した。第３の実施の形態では、第２の実施の形態で説明したＵＩの自動生成機能を利用して、第１の実施の形態で説明したＵＩを自動生成する技術について説明する。

図３９は、第３の実施の形態におけるコンポーネント連携設定用ＵＩの生成過程を説明するための模式図である。データ処理機能を有するコンポーネントは、それぞれ、自らが連携する軸として設定される定義情報をＸＭＬデータとして有している。パラメータ定義情報は、例えば、受け入れ可能な、すなわち、連携可能なタグを特定するための情報であってもよいし、実際に連携が張られた先のタグに関する情報であってもよい。第２の実施の形態で説明した文書処理装置は、ＸＭＬ文書又はＸＭＬ文書のスキーマを取得して、そのＸＭＬ文書を編集するためのＵＩを生成する機能を有している。この技術を利用して、パラメータ定義情報を記述するＸＭＬ文書から、そのＸＭＬ文書を編集するためのＵＩを自動生成する。ユーザは、この編集ＵＩを用いて、コンポーネント間の連携に関するパラメータ定義情報を記述するＸＭＬ文書を編集することができる。

この編集ＵＩでは、例えば、コンポーネントＡが連携可能なデータの一覧と、コンポーネントＢが連携可能なデータの一覧が提示され、それらのデータの間で、ドラッグ＆ドロップなどの操作により連携を指定できるようにしてもよい。これにより、コンポーネント間のデータ連携を容易に設定することができるようになり、データマイニングＵＩをより一層便利に活用することができる。

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

実施の形態では、ＸＭＬ文書を処理する例について説明したが、本実施の形態の文書処理装置１００は、他のマークアップ言語、例えば、ＳＧＭＬ、ＨＴＭＬなどで記述された文書も同様に処理可能である。

前提技術に係る文書処理装置の構成を示す図である。 文書処理装置により編集されるＸＭＬ文書の例を示す図である。 図２に示したＸＭＬ文書をＨＴＭＬで記述された表にマッピングする例を示す図である。 図２に示したＸＭＬ文書を図３に示した表にマッピングするための定義ファイルの例を示す図である。 図２に示したＸＭＬ文書を図３に示した表にマッピングするための定義ファイルの例を示す図である。 図２に示したＸＭＬ文書を、図３に示した対応によりＨＴＭＬにマッピングして表示した画面の例を示す図である。 ユーザが定義ファイルを生成するために、定義ファイル生成部がユーザに提示するグラフィカルユーザインターフェースの例を示す図である。 定義ファイル生成部により生成された画面レイアウトの他の例を示す図である。 文書処理装置によるＸＭＬ文書の編集画面の一例を示す図である。 文書処理装置により編集されるＸＭＬ文書の他の例を示す図である。 図９に示した文書を表示した画面の例を示す図である。 第１の実施の形態に係る文書処理装置の構成を示す図である。 表示画面の例を示す図である。 表示画面の例を示す図である。 表示画面の例を示す図である。 表示画面の例を示す図である。 表示画面の例を示す図である。 表示画面の例を示す図である。 表示画面の例を示す図である。 表示画面の例を示す図である。 表示画面の例を示す図である。 ＸＭＬデータに意味づけをした例を示す図である。 第２の実施の形態の実施例における定義ファイル生成過程を説明するための模式図である。 本実施例におけるスキーマファイルを示す図である。 図２３のスキーマファイルに対応するソースファイルを示す図である。 図２３のスキーマファイルと図２４のソースファイルに基づいて生成される定義ファイルを示す図である。 バインディングファイルの編集画面を示す図である。 図２６におけるバインディングファイルの編集結果に基づくレイアウトファイル編集画面を示す図である。 図２７における編集結果に基づいたデスティネーションファイルを表示させたときの画面図である。 バインディングファイルの編集画面の別例を示す図である。 図２９におけるバインディングファイルの編集結果に基づくレイアウトファイル編集画面を示す図である。 図３０における編集結果に基づいたデスティネーションファイルを表示させたときの画面図である。 バインディングファイルの編集画面の更に別例を示す図である。 図３２におけるバインディングファイルの編集結果に基づくレイアウトファイル編集画面を示す図である。 図３３における編集結果に基づいたデスティネーションファイルを表示させたときの画面図である。 バインディングファイルの編集画面の更に別例を示す図である。 図３５におけるバインディングファイルの編集結果に基づくレイアウトファイル編集画面を示す図である。 図３６における編集結果に基づいたデスティネーションファイルを表示させたときの画面図である。 定義ファイル生成過程を更に説明するための模式図である。 第３の実施の形態におけるコンポーネント連携設定ＵＩの生成過程を説明するための模式図である。

符号の説明

２０ 文書処理装置、２２ 主制御ユニット、２４ 編集ユニット、３０ ＤＯＭユニット、３２ ＤＯＭ提供部、３４ ＤＯＭ生成部、３６ 出力部、４０ ＣＳＳユニット、４２ ＣＳＳ解析部、４４ ＣＳＳ提供部、４６ レンダリング部、５０ ＨＴＭＬユニット、５２，６２ 制御部、５４，６４ 編集部、５６，６６ 表示部、６０ ＳＶＧユニット、７０ 取得部、７１ 連携制御部、７２ ランチャ制御部、７３ レイアウト制御部、７４ タイムスライダー制御部、８０ ＶＣユニット、８２ マッピング部、８４ 定義ファイル取得部、８６ 定義ファイル生成部、１００ 文書処理装置。

Claims (1)

1. マークアップ言語により記述された文書を処理する複数の処理系の間で前記文書に含まれるデータを連携させて処理するための定義情報のデータ構造を取得し、前記データ構造に基づいて、前記定義情報を編集するためのユーザインタフェイス画面を提供するために必要な情報を生成することを特徴とするデータ処理装置。