文書処理装置、方法、及びプログラム
【課題】マークアップ言語により記述された文書に含まれるデータを有効に、かつ効率よく利用する技術を提供する。
【解決手段】文書処理装置２０は、ＨＴＭＬ文書を表示／編集するＨＴＭＬユニット５０、ＳＶＧ文書を表示／編集するＳＶＧユニット６０など、ボキャブラリごとに、表示／編集する処理系をプラグインにより実現する。参照枠ユニット７０は、文書内のデータの参照を実現するためのプラグインであり、処理対象となる文書に含まれる特定の構成要素を参照先データとして管理し、参照枠にそのデータを表示する。
【解決手段】文書処理装置２０は、ＨＴＭＬ文書を表示／編集するＨＴＭＬユニット５０、ＳＶＧ文書を表示／編集するＳＶＧユニット６０など、ボキャブラリごとに、表示／編集する処理系をプラグインにより実現する。参照枠ユニット７０は、文書内のデータの参照を実現するためのプラグインであり、処理対象となる文書に含まれる特定の構成要素を参照先データとして管理し、参照枠にそのデータを表示する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、文書処理技術に関し、特に、マークアップ言語により記述された文書を処理する文書処理装置、方法、及びプログラムに関する。
【背景技術】
【０００２】
ＸＭＬは、ネットワークなどを介して他者とデータを共有するのに適した形式として注目されており、ＸＭＬ文書を作成、表示、編集するためのアプリケーションが開発されている（たとえば、特許文献１参照）。ＸＭＬ文書は、文書型定義などにより定義されたボキャブラリ（タグセット）に基づいて作成されている。
【特許文献１】特開２００１−２９０８０４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
従来、マークアップ言語により記述された文書の構成要素を参照する場合、その参照先、参照元のロケーションパスを指定することが一般的である。例えば、ＸＭＬではＸＰａｔｈを使って文書内の構成要素のロケーションパスを指定する。この場合、ＸＰａｔｈの評価時にはツリートラバースを行うが、複雑なＸＭＬ文書の場合、ＸＰａｔｈでのツリートラバースに時間がかかってしまう場合がある。しかしながら、文書のデータの利用においてユーザの利便性を高めるためには、文書の構成要素の参照機能には高い性能が求められる。
【０００４】
本発明はこうした状況を鑑みてなされたものであり、その目的は、マークアップ言語により記述された文書の参照においてユーザの利便性を高めるための技術を提供することにある。
【課題を解決するための手段】
【０００５】
本発明のある態様は、文書処理装置に関する。この文書処理装置は、マークアップ言語により記述された文書を表示するための処理系と、文書に含まれる構成要素を参照先ノードとして登録する要求を受け付けたときに、前記参照先ノードのインスタンスの参照オブジェクトを取得し、処理系において参照先ノードを参照する参照枠ノードを表示する際に、前記参照オブジェクトを処理系に出力するか、または、参照先ノードの内容の少なくとも一部を参照オブジェクトから取得して、取得した情報を処理系に出力する参照枠ユニットと、を備える。
【０００６】
本明細書における「参照オブジェクト」とは、メモリに展開されたインスタンスのメモリ上のアドレスを指し示すポインタ、または、そのアドレスを保持する参照型のオブジェクトを意味する。
【０００７】
前記参照枠ユニットは、参照先ノードを管理し、参照先ノードが処理系により変更された場合には所定の通知先にその変更を通知する参照先管理部と、マークアップ言語により記述された、参照枠ノードに対応するフラグメントを作成し、処理系にそのフラグメントを文書へ挿入させるとともに、参照先ノードが処理系により変更された場合には所定の通知先にその変更を通知する参照枠管理部と、を備えてもよい。
【０００８】
前記フラグメントは、参照先ノードの識別情報が含まれてもよい。または、そのフラグメントには参照先ノードの内容の少なくとも一部が含まれてもよく、参照枠管理部は更に、参照先ノードが処理系により変更された場合には、フラグメントに含まれる参照先ノードの内容を変更してもよい。
【０００９】
前記参照枠ユニットは、参照枠管理部より参照枠ノードが参照する参照先ノードの内容の少なくとも一部を取得して表示装置に表示させる参照枠表示部を更に備えてもよく、また、前記参照枠ユニットは、参照枠管理部より参照枠ノードが参照する参照先ノードのインスタンスの参照オブジェクトを取得して、参照先ノードの内容の少なくとも一部を参照オブジェクトから取得して表示装置に表示させる参照枠表示部を更に備えてもよい。
また、前記参照枠表示部は、取得した参照先ノードの内容の少なくとも一部を、その参照先ノードが属するマークアップ言語により記述された文書を表示するための処理系に表示させてもよい。
【００１０】
本発明のさらに別の態様は、文書処理方法に関する。この文書処理方法は、マークアップ言語により記述された文書に含まれる構成要素を参照先ノードとして登録する要求を受け付けるステップと、参照先ノードのインスタンスの参照オブジェクトを取得するステップと、参照先ノードを参照する参照枠ノードを表示する際に、前記参照先ノードの内容の少なくとも一部を参照オブジェクトから取得するステップと、マークアップ言語により記述された文書を表示するステップと、を備える。
【００１１】
本明細書における「マークアップ言語」は、ＸＭＬのみならず、例えば、ＸＨＴＭＬ、ＳＶＧ、ＭａｔｈＭＬ、ＳＧＭＬ、ＨＴＭＬなどのボキャブラリあってもよく、タグにより文書を構造化して記述するボキャブラリであればよい。複数のボキャブラリによる文書記述を可能とすることにより、データをより有効に活用することができ、ユーザの利便性を向上させることができる。さらに、参照先ノードに係るボキャブラリと、参照枠ノードに係るボキャブラリとは異なるマークアップ言語で記述されてもよい。以下、本明細書では、マークアップ言語により記述された文書のことを「構造化文書」と呼ぶことにする。
【００１２】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、プログラム、システムなどの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１３】
本発明によれば、構造化文書に対する利便性の高い参照機能を提供できる。
【発明を実施するための最良の形態】
【００１４】
まず、本実施の形態に係る文書処理装置の前提技術について述べた後、本発明の特徴を説明する。
【００１５】
（前提技術）
図１は、前提技術に係る文書処理装置２０の構成を示す。文書処理装置２０は、文書内のデータが階層構造を有する複数の構成要素に分類された構造化文書を処理するが、本前提技術では構造化文書の一例としてＸＭＬ文書を処理する例について説明する。文書処理装置２０は、主制御ユニット２２、編集ユニット２４、ＤＯＭユニット３０、ＣＳＳユニット４０、ＨＴＭＬユニット５０、ＳＶＧユニット６０、及び変換部の一例であるＶＣユニット８０を備える。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【００１６】
主制御ユニット２２は、プラグインのロードや、コマンド実行のフレームワークを提供する。編集ユニット２４は、ＸＭＬ文書を編集するためのフレームワークを提供する。文書処理装置２０における文書の表示及び編集機能は、プラグインにより実現されており、文書の種別に応じて必要なプラグインが主制御ユニット２２又は編集ユニット２４によりロードされる。主制御ユニット２２又は編集ユニット２４は、処理対象となるＸＭＬ文書の名前空間を参照して、ＸＭＬ文書がいずれのボキャブラリにより記述されているかを判別し、そのボキャブラリに対応した表示又は編集用のプラグインをロードして表示や編集を実行させる。例えば、文書処理装置２０には、ＨＴＭＬ文書の表示及び編集を行うＨＴＭＬユニット５０、ＳＶＧ文書の表示及び編集を行うＳＶＧユニット６０など、ボキャブラリ（タグセット）ごとに表示系及び編集系がプラグインとして実装されており、ＨＴＭＬ文書を編集するときはＨＴＭＬユニット５０が、ＳＶＧ文書を編集するときはＳＶＧユニット６０が、それぞれロードされる。後述するように、ＨＴＭＬとＳＶＧの双方の構成要素を含む複合文書が処理対象となっている場合は、ＨＴＭＬユニット５０とＳＶＧユニット６０の双方がロードされる。
【００１７】
このような構成によれば、ユーザは、必要な機能のみを選択してインストールし、後から適宜機能を追加又は削除することができるので、プログラムを格納するハードディスクなどの記録媒体の記憶領域を有効に活用することができ、また、プログラム実行時にも、メモリの浪費を防ぐことができる。また、機能拡張性に優れており、開発主体としても、プラグインの形で新たなボキャブラリに対応することが可能なので開発が容易となり、ユーザとしても、プラグインの追加により容易かつ低コストにて機能を追加することができる。
【００１８】
編集ユニット２４は、ユーザインターフェースを介してユーザから編集指示のイベントを受け付け、そのイベントを適切なプラグインなどに通知するともに、イベントの再実行（リドゥ）又は実行の取消（アンドゥ）などの処理を制御する。
【００１９】
ＤＯＭユニット３０は、ＤＯＭ提供部３２、ＤＯＭ生成部３４、及び出力部３６を含み、ＸＭＬ文書をデータとして扱うときのアクセス方法を提供するために定められた文書オブジェクトモデル（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）であれば、有効なＸＭＬ文書として処理可能である。この場合、挿入された他のボキャブラリのタグは、定義ファイルによりマッピングされてもよい。例えば、ＸＨＴＭＬ文書中に、「重要」、「最重要」などのタグを使用し、これらのタグで囲まれた部分を強調表示してもよいし、重要度の順にソートして表示してもよい。
【００４３】
図１０に示した編集画面において、ユーザにより文書が編集されると、編集された部分を担当するプラグイン又はＶＣユニット８０がソースツリーを変更する。ソースツリーには、ノードごとにミューテーションイベントのリスナーを登録できるようになっており、通常は、各ノードが属するボキャブラリに対応したプラグインの表示部又はＶＣユニット８０がリスナーとして登録される。ＤＯＭ提供部３２は、ソースツリーが変更されると、変更されたノードから上位の階層へたどって、登録されたリスナーがあれば、そのリスナーへミューテーションイベントを発行する。例えば、図９に示した文書において、＜ｈｔｍｌ＞ノードの下位のノードが変更された場合、＜ｈｔｍｌ＞ノードにリスナーとして登録されたＨＴＭＬユニット５０にミューテーションイベントが通知されるとともに、その上位の＜ｓｖｇ＞ノードにリスナーとして登録されたＳＶＧユニット６０にもミューテーションイベントが通知される。このとき、ＨＴＭＬユニット５０は、変更されたソースツリーを参照して表示を更新する。ＳＶＧユニット６０は、自身のボキャブラリに属するノードが変更されていないので、ミューテーションイベントを無視してもよい。
【００４４】
編集の内容によっては、ＨＴＭＬユニット５０による表示の更新に伴って、全体のレイアウトが変わる可能性がある。この場合は、画面のレイアウトを管理する構成、例えば最上位のノードの表示を担当するプラグインにより、プラグインごとの表示領域のレイアウトが更新される。例えば、ＨＴＭＬユニット５０による表示領域が以前より大きくなった場合、ＨＴＭＬユニット５０は、まず自身の担当する部分を描画して、表示領域の大きさを決定する。そして、画面のレイアウトを管理する構成に、変更後の表示領域の大きさを通知し、レイアウトの更新を依頼する。画面のレイアウトを管理する構成は、通知を受けて、プラグインごとの表示領域を再レイアウトする。こうして、編集された部分の表示が適切に更新されるとともに、画面全体のレイアウトが更新される。
以上の技術を前提として、以下、本発明の実施の形態を説明する。
【００４５】
（第１の実施形態）
文書処理装置では、参照先のデータと参照元のデータとの整合性を確保する参照機能が提供されることがある。構造化文書の構成要素を参照する場合、その参照先のロケーションパスと参照元のロケーションパスを対応させて管理することが一般的である。ＸＭＬ文書ではＸＰａｔｈを使って文書内の構成要素のロケーションパスを指定する。この場合、参照先が変更されると、例えば、参照先のロケーションパスを指定して、参照先の変更後の値を取得し、さらに、参照元のロケーションパスを指定して参照元にアクセスし、変更後の値に書き換えることになる。しかし、この方法では文書のツリートラバースが発生するため、参照機能を多数利用した場合に、参照先の変更に伴う参照元の追随処理に時間がかかってしまう。とくに、構造化文書が複雑な構造である場合、この傾向は顕著となる。
【００４６】
このような課題を解決するため、本発明の実施の形態に係る文書処理装置は、参照先ノードのインスタンスの参照オブジェクト（以下、「参照先ノードポインタ」と呼ぶ。）をメモリ上に保持し、参照先ノードのインスタンスから参照先ノードの内容の少なくとも一部（以下、「参照先ノードの値」と呼ぶ。）を直接取得可能にする。これにより、ツリートラバースを発生させることなく高速に、参照先ノードの変更に伴う参照元ノードの追随を可能にする。以下、この仕組みに係る参照機能を「参照枠機能」と呼び、参照元ノードとして、構造化文書に挿入されるデータを「参照枠」と呼ぶことにする。
【００４７】
本明細書における「参照先ノード」および「参照枠ノード」は、特に断らない限り、その子孫ノードを含む。つまり図１１のようなＸＨＴＭＬ文書の場合、参照先ノードとして、＜ｈ２＞から＜／ｈ２＞を指定することができる。この場合、参照先ノードの値として「徳島市川内町」が選択されることになる。また、参照枠ノードは、例えば、＜ｒｅｆ−ｆｒａｍｅ＞から＜／ｒｅｆ−ｆｒａｍｅ＞となる。実際には参照枠ノードの値として「徳島市川内町」が表示されることになる。
また、本明細書における「参照先ノードの値」は、特に断らない限り、参照先ノードの内容の少なくとも一部、の意味とする。これは、例えば前述の例で、図１１において参照先ノードとして＜ｈ２＞から＜／ｈ２＞が指定されていた場合、参照先ノードの値とは、ノード名「ｈ２」「ｓｐａｎ」、ノード値「徳島市川内町」、「川内町」等を含む概念であることを意味する。
【００４８】
次に、図１２・図１３・図１４を用いて、参照枠機能のユーザインタフェイスを説明する。図１２は、アプリケーション３０００にて文書作成中のユーザが、参照先文字列３００２を参照する参照枠をキャレット位置３００６に挿入する前の状態を示している。なお既に、参照枠３００４が二箇所に挿入されている。図１３は、図１２のキャレット位置３００６に、参照枠３００４が出力された状態を示している。図１４は、参照先文字列３００２が、「○○○○株式会社」から「△△△△株式会社」に変更された状態を示している。参照先文字列３００２が変更されると、参照枠機能により、参照枠３００４の表示内容もリアルタイムに変更される。
【００４９】
参照枠機能により、繰り返し記述される単語、文節、句、文等の記述において、その記述の労力を省力化するとともに、記述内容の不整合を防止することができるだけでなく、参照枠ノードの参照先ノードへの追随が高速になり、利便性の高い参照機能を提供することができる。
【００５０】
図１５は、本発明の実施の形態に係る文書処理装置２０の機能ブロック図である。本実施の形態の文書処理装置２０は、前提技術として図１に示した文書処理装置２０の構成に加えて、他のデータへの参照枠機能を提供するプラグインである参照枠ユニット７０を更に備える。参照枠ユニット７０は、参照先管理部７２と、参照枠管理部７４と、参照枠表示部７６と、を有する。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【００５１】
参照先管理部７２は、参照先ノードとして登録された要素を管理する。ここでの要素には、参照先ノードポインタが含まれる。例えば、ユーザが参照先ノードの登録をすると、参照先管理部７２は、参照先ノードポインタを取得する。図１６は、参照先管理部７２における管理テーブルの例である。なお、同図では、参照先ノードの識別情報（以下、「参照先ノードＩＤ」と呼ぶ。）と参照先ノードポインタを保持している。参照先ノードＩＤの列には、同図では数字で示しているが、参照先ノードとして登録された構造化文書の構成要素を一意に特定できる情報が格納される。参照先ノードポインタの列は、参照先ノードのインスタンスの参照オブジェクトが格納される。例えばＪａｖａ言語（登録商標）であれば、java.lang.Stringクラスのオブジェクトや、org.w3c.dom.Nodeクラスのオブジェクトが格納される。なお、参照オブジェクトの中身はメモリのアドレスであり、例えば、「０ｘ１２３４ＡＢＣＤＥ」といった値が格納されている。構造化文書の構成要素毎にこのアドレスが一意になることが保証されている場合、例えばＪａｖａ言語（登録商標）やＣ＋＋言語で実装されている場合、には参照先ノードＩＤは必須ではない。また、対応付けを保持する管理テーブルは、Ｃ＋＋言語におけるコンテナクラスや、Ｊａｖａ（登録商標）言語におけるコレクションフレームワークを利用してメモリ上に保持されてもよい。後述する参照枠管理部７４においても同様である。
【００５２】
参照枠管理部７４は、構造化文書に挿入された参照枠ノードが参照する参照先ノードの情報を保持する。ユーザが構造化文書に参照枠の挿入の操作をした場合、参照枠管理部７４は、まず、参照枠ノードのフラグメントを作成する。例えば、前述した図１１のＸＨＴＭＬ文書における＜ｒｅｆ−ｆｒａｍｅ＞から＜／ｒｅｆ−ｆｒａｍｅ＞を作成する。それから、他の適切なコンポーネントにそのフラグメントを文書に挿入させる。例えば、文書がＸＨＴＭＬ文書であった場合には、ＨＴＭＬユニットに作成したフラグメントを挿入させる。参照枠管理部７４が、作成したフラグメントを文書に挿入してもよい。このフラグメントは、例えば、参照枠のボキャブラリを示す名前空間文字列（図１１の例ではｒｅｆ−ｆｒａｍｅノードのｘｍｌｎｓ属性）と、参照先ノードＩＤ（図１１の例ではｔｒａｃｅｒ−ＩＤノードのｖａｌｕｅ属性）を含む。参照枠管理部７４は、参照枠が参照する参照先ノードが何であるかによって、この参照先ノードＩＤを決定する。
【００５３】
参照枠管理部７４は、さらに、メモリ上でリスナＩＤ、参照先ノードＩＤ、参照先ノードポインタとの対応関係を管理する。リスナＩＤは、参照枠管理部７４から参照先ノードの変更通知を受けたいコンポーネント、例えば、後述する参照枠表示部７６、が登録したリスナオブジェクトの識別情報である。また、このリスナＩＤは、リスナオブジェクトのメモリ上のアドレスのポインタ、つまりリスナオブジェクトそのものであってもよい。図１７は、参照枠管理部７４における管理テーブルの例である。この管理テーブルにデータが設定される流れについては後述する。
参照枠表示部７６は、参照枠のボキャブラリを解釈し、参照枠管理部７４から参照先ノードの値を取得して表示装置に表示させる。
【００５４】
次に、図１８・図１９を使用して、ここまで説明した各機能ブロックが、参照枠機能を実現するためにどのように相互作用をしているかを示す。
【００５５】
図１８は、参照枠の設定に係るシーケンス図である。同図では、ユーザが参照枠の挿入を要求し、参照枠が表示されるまでの、各機能ブロックの相互作用を示している。なお、この例での文書はＸＨＴＭＬ文書としている。最初にユーザは、文書の表示を担当しているＨＴＭＬユニット５０に参照枠の挿入を要求する（ステップＳ２）。ＨＴＭＬユニット５０は、参照枠管理部７４に参照先の選択ダイヤログを要求する（ステップＳ４）。参照枠管理部７４は参照先管理部７２に登録されている参照先一覧を要求する（ステップＳ６）。参照先管理部７２は、参照枠管理部７４に参照先一覧を提供する（ステップＳ８）。参照先一覧の提供にあわせて、それぞれの参照先ノードＩＤと参照先ノードポインタが提供される。参照枠管理部７４は、参照先の選択ダイヤログを表示する（ステップＳ１０）。
【００５６】
次に、ユーザは表示された選択ダイヤログから参照先を選択する（ステップＳ１２）。参照枠管理部７４は、前述した参照枠のフラグメントを作成し（ステップＳ１４）、そのフラグメントをＨＴＭＬユニット５０に返す（ステップＳ１６）。ＨＴＭＬユニット５０は、返された参照枠のフラグメントをソースツリーに挿入する（ステップＳ１８）。上記ステップＳ１８の結果、ソースツリーが変更されて、ＤＯＭユニット３０は、前提技術で説明したミューテーションイベントを参照枠管理部７４に通知する（ステップＳ２０）とともに、ＨＴＭＬユニット５０にＸＨＴＭＬボキャブラリを解釈して、画面表示をするように要求する（ステップＳ２４）。
【００５７】
ＤＯＭユニット３０よりミューテーションイベントを通知された参照枠管理部７４は、挿入された参照枠の監視を開始し、参照先管理部７２からの変更通知を待ち受ける（ステップＳ２２）。ここで、監視を開始するに先立って、参照枠管理部７４は、参照先管理部７２に変更通知用のリスナオブジェクトを登録する。それとともに、参照枠管理部７４は、先のステップＳ８で参照先管理部７２より提供された参照先ノードに係る参照先ノードＩＤと参照先ノードポインタを管理テーブルにて保持する。
【００５８】
一方で、ＤＯＭユニット３０からＸＨＴＭＬ文書の画面表示を要求されたＨＴＭＬユニット５０は、前提技術で説明したように表示処理を行う。その中で、参照枠ボキャブラリを検出すると、参照枠表示部７６に参照枠ボキャブラリの表示を要求する（ステップＳ２６）。参照枠表示部７６は、参照先変更の通知を受けるため、参照枠管理部７４に対しリスナオブジェクトを登録する（ステップＳ２８）。このときに、参照枠管理部７４が保持する管理テーブルにリスナＩＤまたはリスナオブジェクトそのものが格納される。また、参照枠表示部７６は、リスナオブジェクトの登録後、参照枠のフラグメントに含まれる参照先ノードＩＤをキーとして表示文字列を要求する（ステップＳ３０）。
【００５９】
参照枠管理部７４は、参照先ノードＩＤと対応付けられた参照先ノードポインタを取得し、その参照先ノードポインタが備えるメソッドを操作して表示文字列を取得する。例えば、ＤＯＭのノードオブジェクトが格納されていた場合、ＤＯＭのＡＰＩ（Application Programming Interface）を利用して、そのノードオブジェクトから表示文字列を取得する。そして、参照枠管理部７４は、参照枠表示部７６に取得した文字列を提供し（ステップＳ３２）、参照枠表示部７６は、構造化文書の参照枠ボキャブラリ部分にその文字列を表示させる（ステップＳ３４）。
【００６０】
図１９は、参照先の値の変更に伴う参照元の値の変更に係るシーケンス図である。同図は、ユーザが参照先を編集し、その編集内容が参照枠に反映されるまでの、各機能ブロックの相互作用を示している。まず、ユーザが参照先ノードまたはその子孫ノードの編集をする（ステップＳ４２）。すると、表示を担当しているＨＴＭＬユニット５０はその編集内容でソースツリーを変更する（ステップＳ４４）。ＤＯＭユニット３０は、参照先として登録されているノードおよびその子孫ノードのミューテーションイベントを参照先管理部７２に通知する（ステップＳ４６）。参照先管理部７２は、参照先ノードＩＤまたは参照先ノードポインタをキーとして、登録されているリスナオブジェクトを介して、参照枠管理部７４に参照先ノードが変更された旨を通知する（ステップＳ４８）。参照枠管理部７４は、キーとして送られてきた参照先ノードＩＤまたは参照先ノードポインタと、保持する管理テーブルから、変更された参照先ノードに対応する参照枠ノードが存在するかを判定する（ステップＳ５０）。
【００６１】
ステップＳ５０において、対応する参照枠ノードが存在した場合、参照枠管理部７４は、参照先ノードＩＤまたは参照先ノードポインタに対応するリスナＩＤを取得する。そして、参照枠管理部７４に登録されているリスナオブジェクトであって、そのリスナＩＤに対応するリスナオブジェクトを介して、参照枠表示部７６に参照先ノードの変更を通知する（ステップＳ５２）。参照枠表示部７６は、ＤＯＭユニット３０に再表示を要求（ステップＳ５４）する。そして図１５のステップＳ２４以降と同様のシーケンスで参照枠が表示される。この場合、参照枠管理部７４は、参照先ノードポインタをもとに参照先ノードのインスタンスから変更後の文字列を取得するため、最終的に参照枠に表示される文字列も変更後の文字列となる。
【００６２】
本発明の第一の特徴は、参照枠ユニット７０が、メモリ上に参照先ノードポインタを保持し、参照先ノードの変更の際には、その参照先ノードポインタをもとに参照先ノードのインスタンスから参照先ノードの値を直接取得することで変更後データを参照枠に表示していることである。上記のシーケンス説明から明らかなように、ＸＰａｔｈを利用した際に生ずるツリートラバースを発生させることもなく、さらに、参照先ノードの変更に伴って参照枠ノードのフラグメントの変更処理も発生させない。結果として、参照枠ノードを参照先ノードに高速に追随させることを可能にしている。更に、ツリートラバースを発生させないことから、ＸＰａｔｈを利用した場合と比べて、参照枠機能の性能がＸＭＬ文書の複雑さには非依存であることも長所である。この特徴により、ユーザが構造化文書の編集等で参照機能を用いる場合の利便性を向上できる。
【００６３】
本発明の第二の特徴は、ボキャブラリ境界を越えて、特定の構成要素を参照表示できることである。シーケンス図において、参照先管理部７２・参照枠管理部７４・参照枠表示部７６のいずれも特定のボキャブラリに依存した処理はない。そのため例えば、スプレッドシートボキャブラリにある総額セルを参照先として登録しておき、ＨＴＭＬ側で参照枠を挿入することで、そのセルを参照可能になる。更にそのセルが変更された場合には、自動的にＨＴＭＬ側の総額セルの表示も変更される。この特徴により、ユーザは文書内のデータを有効に利用できることになる。
【００６４】
さらに本発明では、参照枠ユニット７０内の各サブモジュール間の独立性が高い構成となっている。実施の形態に係る参照先管理部７２と参照枠管理部７４との接点はリスナオブジェクトを介した変更通知に過ぎない。したがって、参照先管理部７２と参照枠管理部７４は、他方を意識することなく機能追加・バグ修正等メンテナンスができるとともに、参照先管理部７２は参照枠管理部７４が存在しなくても動作できる。これにより、他のプラグイン等に対しても参照先一覧を提供できる。同様に、実施の形態に係る参照枠管理部７４と参照枠表示部７６との接点もリスナオブジェクトを介した変更通知に過ぎない。したがって、参照枠管理部７４と参照枠表示部７６は、他方を意識することなく機能追加・バグ修正等メンテナンスができるとともに、参照枠管理部７４は参照枠表示部７６が存在しなくても動作できる。これにより、参照枠管理部７４は、参照枠表示部７６に限定されることなく、他のプラグイン等に対しても参照枠データを提供できる。
【００６５】
（第２の実施形態）
本実施形態と第１の実施形態とは、参照先ノードの値の取得する主体が異なる。
前述の図１９のシーケンス図のステップＳ３０の部分で、参照枠表示部７６は、参照枠管理部に参照先ノードＩＤをキーに参照先ノードポインタを要求する。参照枠管理部７４は、参照先ノードＩＤに対応する参照先ノードポインタを参照枠表示部７６に返す。ここで、前述の参照枠管理部７４と同様に、参照枠表示部７６は、参照先ノードポインタをもとに参照先ノードのインスタンスから参照先ノードの値を直接取得して、その値を参照枠ボキャブラリ部分に表示させる。
【００６６】
（第３の実施形態）
本実施形態と第１の実施形態とは、また、本実施形態と第２の実施形態とは、参照先ノードの値を表示する方法が異なる。
前述の図１９のシーケンス図のステップＳ３４の部分で、参照枠表示部７６は、参照先ノードの値を他のボキャブラリユニットに表示させる。例えば、参照先ノードの値がＳＶＧによって記述された文字列であった場合には、ＳＶＧユニットに参照先ノードの値を表示させ、ＭａｔｈＭＬによって記述された文字列であった場合には、ＭａｔｈＭＬユニットに参照先ノードの値を表示させる。
【００６７】
先の２つの実施形態の場合、参照枠表示部７６が、参照先ノードまたはその子孫のノードが有するテキストノードのテキスト値を表示することを想定していたが、参照先ノードの値をそのボキャブラリに応じて適切に表示するためには、参照枠表示部７６は、参照先ノードの値がとりうる全てのボキャブラリを理解できる必要がある。また参照枠表示部７６が理解できないボキャブラリにより参照先ノードの値が記述されていた場合には、文書のソース又はツリー構造を表示するしかない。
本実施形態によれば、参照先ノードの値のボキャブラリに応じて適切なボキャブラリユニットを選択することで、参照枠表示部７６が理解するボキャブラリの幅を広げる必要なく、参照先ノードの値を適切に表示しやすくなる。なお、適切なボキャブラリユニットの選択は、そのボキャブラリ領域の名前空間の記述で判断することで可能である。参照枠表示部７６は、参照先ノードが、自身が処理できないボキャブラリで記述されていたときに、参照先ノードの処理を他の処理系に委譲する旨を主制御ユニット２２へ通知してもよい。この場合、主制御ユニット２２は、参照先ノードの名前空間や要素名などに基づいて適切な処理系を選択し、その処理系に処理を委譲する。
【００６８】
（第４の実施形態）
第１から第３の実施形態では、参照枠管理部７４が作成する参照枠ノードのフラグメントには、参照先ノードＩＤのみが格納されていた。本実施形態では、参照枠ノードのフラグメントに、参照先ノードのテキスト値または参照先ノード自身など、参照枠の表示に必要な情報を格納する。これにより、参照枠ノードの周囲のノードが編集されるなどして、参照先ノードが編集されていないにもかかわらず参照先ノードを再描画する必要が生じたときに、参照先ノードを参照することなく参照枠ノードを再描画することができるので、高速に表示を更新することができる。第１から第３の実施形態では、参照枠ノードには参照先ノードのＩＤしか格納されていないので、参照先ノードが編集されても参照枠ノードを編集する必要はなかった。しかし本実施形態では、参照枠管理部７４は、参照先ノードが編集されたときに、参照先ノードを参照して参照枠ノードを編集し、追随させる。
【００６９】
いずれの実施形態においても、参照先管理部７２が保持する管理テーブル、参照枠管理部７４が保持する管理テーブル、ともに揮発性のメモリ上に保持される。この場合、本発明の実施の形態に係る文書処理装置２０を終了すれば、メモリ上の管理テーブルは失われる。なお、管理テーブルは不揮発のストレージに保持されてもよく、参照先ノードポインタも参照型のオブジェクトであるので、シリアライズ化しストレージに保持できる。またオブジェクト指向ＤＢ等であれば、オブジェクトのままストレージに保持できる。しかし、一旦メモリ展開されていた構造化文書は、文書処理装置２０の再起動時には、別のメモリ領域に展開されるため、前回の参照先ノードポインタを使うことはできない。言い換えれば、管理テーブルを揮発性のメモリ上に保持していたとしても、または、不揮発性のストレージに保持していたとしても、文書処理装置２０を一旦終了し、再度起動した時に参照枠は無効となってしまう。文書処理装置２０の終了時に、参照枠ノードの値を参照先ノードの値で置き換えるのは一つの解決手段であるが、一旦構造化文書の中に設定された参照枠は、次回起動時にもそのまま参照枠として使えた方がユーザの利便性は高い。
【００７０】
この課題に対し、本発明者は以下の解決手段に想到した。
例えば、図１１の構造化文書で「/html/body/h1」が参照先ノードとして設定され、同文書内の「/html/body/p/ref-frame」が参照枠ノードであったとする。ここで、文書処理装置２０の終了時には、図１５では図示しない永続化処理部が、参照枠ノードの中に参照先ノードのロケーションパス、ここでは「/html/body/h1」、を設定しておく。より簡易的に、「/*[1]/*[2]/*[1]/」などと表現してもよい。再度構造化文書を展開した際に、ノード「ref-frame」は、ＨＴＭＬユニット５０では処理できないため、処理が参照枠ユニット７０に委譲される。このとき、永続化処理部は、参照先ノードとして「/html/body/h1」が登録されていたことを認識する。次に永続化処理部は、その参照先ノードの現在の参照先ノードポインタを取得し、参照先管理部７２に通知する。参照先管理部７２は、通知された参照先ノードポインタをもとに管理テーブルを作成する。参照先ノードＩＤは参照先管理部７２が一意に設定してもよいが、永続化処理部が参照枠ノードから参照先ノードＩＤを取得して参照枠ノードポインタとともに通知してもよい。続いて、参照枠管理部７４は、参照先管理部７２から、参照先ノードポインタと参照先ノードＩＤの通知を受けて、管理テーブルを作成する。なお、参照枠管理部７４が保持する管理テーブルに存在するリスナＩＤの情報は、参照枠表示部７６が最初に参照枠を表示するときに、再度リスナを登録すればよい。
この手段によれば、文書処理装置２０を終了しても、構造化文書に既に挿入されていた参照枠は、構造化文書の再読み込み時に管理テーブルとともに復元ができ、ユーザの利便性を高めることができる。
【００７１】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【図面の簡単な説明】
【００７２】
【図１】本発明の前提技術に係る文書処理装置の構成を示す図である。
【図２】前提技術に係る文書処理装置により処理されるＸＭＬ文書の例を示す図である。
【図３】図２に示したＸＭＬ文書をＨＴＭＬで記述された表にマッピングする例を示す図である。
【図４（ａ）】図２に示したＸＭＬ文書を図３に示した表にマッピングするためのＶＣ定義ファイルの例を示す図である。
【図４（ｂ）】図２に示したＸＭＬ文書を図３に示した表にマッピングするためのＶＣ定義ファイルの例を示す図である。
【図５】図２に示したＸＭＬ文書を図３に示した対応によりＨＴＭＬにマッピングして表示した画面の例を示す図である。
【図６】ＶＣ定義ファイル生成部がユーザに提示するグラフィカルユーザインターフェースの例を示す図である。
【図７】ＶＣ定義ファイル生成部により生成された画面レイアウトの他の例を示す図である。
【図８】文書処理装置によるＸＭＬ文書の編集画面の一例を示す図である。
【図９】前提技術に係る文書処理装置により処理されるＸＭＬ文書の他の例を示す図である。
【図１０】図９に示した文書を表示した画面の例を示す図である。
【図１１】ＸＨＴＭＬ文書の例である。
【図１２】参照枠機能のユーザインタフェイスを説明する図である。
【図１３】参照枠機能のユーザインタフェイスを説明する図である。
【図１４】参照枠機能のユーザインタフェイスを説明する図である。
【図１５】本発明の実施の形態に係る文書処理装置の機能ブロック図である。
【図１６】参照先管理部の管理テーブルの例である。
【図１７】参照枠管理部の管理テーブルの例である。
【図１８】参照枠の設定に係るシーケンス図である。
【図１９】参照先の値の変更に伴う参照枠の値の変更に係るシーケンス図である。
【符号の説明】
【００７３】
２０ 文書処理装置、２２ 主制御ユニット、２４ 編集ユニット、３０ ＤＯＭユニット、３２ ＤＯＭ提供部、３４ ＤＯＭ生成部、３６ 出力部、４０ ＣＳＳユニット、４２ ＣＳＳ解析部、４４ ＣＳＳ提供部、４６ レンダリング部、５０ ＨＴＭＬユニット、５２，６２ 制御部、５４，６４ 編集部、５６，６６ 表示部、６０ ＳＶＧユニット、７０ 参照枠ユニット、７２ 参照先管理部、７４ 参照枠管理部、７６ 参照枠表示部、８０ ＶＣユニット、８２ マッピング部、８４ 定義ファイル取得部、８６ 定義ファイル生成部、３０００ アプリケーション、３００２ 参照先文字列、３００４ 参照枠、３００６ キャレット位置、Ｓ２ 参照枠の挿入、Ｓ４ 参照先の選択ダイヤログを要求、Ｓ６ 参照先一覧の要求、Ｓ８ 参照先一覧の提供、Ｓ１０ 参照先の選択ダイヤログを表示、Ｓ１２ 参照先を選択、Ｓ１４ 参照枠フラグメントの生成、Ｓ１６ 参照枠フラグメントを返す、Ｓ１８ 参照枠フラグメントの挿入、Ｓ２０ ミューテーションイベントの通知、Ｓ２２ 挿入された参照枠の監視開始、Ｓ２４ ＸＨＴＭＬ表示要求、Ｓ２６ 参照枠表示要求、Ｓ２８ リスナ登録、Ｓ３０ 表示文字列要求、Ｓ３２ 表示文字列提供、Ｓ３４ 参照枠の表示、Ｓ４２ 参照先の編集、Ｓ４４ ソースツリーの変更、Ｓ４６ ミューテーションイベントの通知、Ｓ４８ 参照先の変更通知、Ｓ５０ 対応する参照枠の存否の確認、Ｓ５２ 参照先の変更通知、Ｓ５４ 再表示要求。
【技術分野】
【０００１】
本発明は、文書処理技術に関し、特に、マークアップ言語により記述された文書を処理する文書処理装置、方法、及びプログラムに関する。
【背景技術】
【０００２】
ＸＭＬは、ネットワークなどを介して他者とデータを共有するのに適した形式として注目されており、ＸＭＬ文書を作成、表示、編集するためのアプリケーションが開発されている（たとえば、特許文献１参照）。ＸＭＬ文書は、文書型定義などにより定義されたボキャブラリ（タグセット）に基づいて作成されている。
【特許文献１】特開２００１−２９０８０４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
従来、マークアップ言語により記述された文書の構成要素を参照する場合、その参照先、参照元のロケーションパスを指定することが一般的である。例えば、ＸＭＬではＸＰａｔｈを使って文書内の構成要素のロケーションパスを指定する。この場合、ＸＰａｔｈの評価時にはツリートラバースを行うが、複雑なＸＭＬ文書の場合、ＸＰａｔｈでのツリートラバースに時間がかかってしまう場合がある。しかしながら、文書のデータの利用においてユーザの利便性を高めるためには、文書の構成要素の参照機能には高い性能が求められる。
【０００４】
本発明はこうした状況を鑑みてなされたものであり、その目的は、マークアップ言語により記述された文書の参照においてユーザの利便性を高めるための技術を提供することにある。
【課題を解決するための手段】
【０００５】
本発明のある態様は、文書処理装置に関する。この文書処理装置は、マークアップ言語により記述された文書を表示するための処理系と、文書に含まれる構成要素を参照先ノードとして登録する要求を受け付けたときに、前記参照先ノードのインスタンスの参照オブジェクトを取得し、処理系において参照先ノードを参照する参照枠ノードを表示する際に、前記参照オブジェクトを処理系に出力するか、または、参照先ノードの内容の少なくとも一部を参照オブジェクトから取得して、取得した情報を処理系に出力する参照枠ユニットと、を備える。
【０００６】
本明細書における「参照オブジェクト」とは、メモリに展開されたインスタンスのメモリ上のアドレスを指し示すポインタ、または、そのアドレスを保持する参照型のオブジェクトを意味する。
【０００７】
前記参照枠ユニットは、参照先ノードを管理し、参照先ノードが処理系により変更された場合には所定の通知先にその変更を通知する参照先管理部と、マークアップ言語により記述された、参照枠ノードに対応するフラグメントを作成し、処理系にそのフラグメントを文書へ挿入させるとともに、参照先ノードが処理系により変更された場合には所定の通知先にその変更を通知する参照枠管理部と、を備えてもよい。
【０００８】
前記フラグメントは、参照先ノードの識別情報が含まれてもよい。または、そのフラグメントには参照先ノードの内容の少なくとも一部が含まれてもよく、参照枠管理部は更に、参照先ノードが処理系により変更された場合には、フラグメントに含まれる参照先ノードの内容を変更してもよい。
【０００９】
前記参照枠ユニットは、参照枠管理部より参照枠ノードが参照する参照先ノードの内容の少なくとも一部を取得して表示装置に表示させる参照枠表示部を更に備えてもよく、また、前記参照枠ユニットは、参照枠管理部より参照枠ノードが参照する参照先ノードのインスタンスの参照オブジェクトを取得して、参照先ノードの内容の少なくとも一部を参照オブジェクトから取得して表示装置に表示させる参照枠表示部を更に備えてもよい。
また、前記参照枠表示部は、取得した参照先ノードの内容の少なくとも一部を、その参照先ノードが属するマークアップ言語により記述された文書を表示するための処理系に表示させてもよい。
【００１０】
本発明のさらに別の態様は、文書処理方法に関する。この文書処理方法は、マークアップ言語により記述された文書に含まれる構成要素を参照先ノードとして登録する要求を受け付けるステップと、参照先ノードのインスタンスの参照オブジェクトを取得するステップと、参照先ノードを参照する参照枠ノードを表示する際に、前記参照先ノードの内容の少なくとも一部を参照オブジェクトから取得するステップと、マークアップ言語により記述された文書を表示するステップと、を備える。
【００１１】
本明細書における「マークアップ言語」は、ＸＭＬのみならず、例えば、ＸＨＴＭＬ、ＳＶＧ、ＭａｔｈＭＬ、ＳＧＭＬ、ＨＴＭＬなどのボキャブラリあってもよく、タグにより文書を構造化して記述するボキャブラリであればよい。複数のボキャブラリによる文書記述を可能とすることにより、データをより有効に活用することができ、ユーザの利便性を向上させることができる。さらに、参照先ノードに係るボキャブラリと、参照枠ノードに係るボキャブラリとは異なるマークアップ言語で記述されてもよい。以下、本明細書では、マークアップ言語により記述された文書のことを「構造化文書」と呼ぶことにする。
【００１２】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、プログラム、システムなどの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１３】
本発明によれば、構造化文書に対する利便性の高い参照機能を提供できる。
【発明を実施するための最良の形態】
【００１４】
まず、本実施の形態に係る文書処理装置の前提技術について述べた後、本発明の特徴を説明する。
【００１５】
（前提技術）
図１は、前提技術に係る文書処理装置２０の構成を示す。文書処理装置２０は、文書内のデータが階層構造を有する複数の構成要素に分類された構造化文書を処理するが、本前提技術では構造化文書の一例としてＸＭＬ文書を処理する例について説明する。文書処理装置２０は、主制御ユニット２２、編集ユニット２４、ＤＯＭユニット３０、ＣＳＳユニット４０、ＨＴＭＬユニット５０、ＳＶＧユニット６０、及び変換部の一例であるＶＣユニット８０を備える。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【００１６】
主制御ユニット２２は、プラグインのロードや、コマンド実行のフレームワークを提供する。編集ユニット２４は、ＸＭＬ文書を編集するためのフレームワークを提供する。文書処理装置２０における文書の表示及び編集機能は、プラグインにより実現されており、文書の種別に応じて必要なプラグインが主制御ユニット２２又は編集ユニット２４によりロードされる。主制御ユニット２２又は編集ユニット２４は、処理対象となるＸＭＬ文書の名前空間を参照して、ＸＭＬ文書がいずれのボキャブラリにより記述されているかを判別し、そのボキャブラリに対応した表示又は編集用のプラグインをロードして表示や編集を実行させる。例えば、文書処理装置２０には、ＨＴＭＬ文書の表示及び編集を行うＨＴＭＬユニット５０、ＳＶＧ文書の表示及び編集を行うＳＶＧユニット６０など、ボキャブラリ（タグセット）ごとに表示系及び編集系がプラグインとして実装されており、ＨＴＭＬ文書を編集するときはＨＴＭＬユニット５０が、ＳＶＧ文書を編集するときはＳＶＧユニット６０が、それぞれロードされる。後述するように、ＨＴＭＬとＳＶＧの双方の構成要素を含む複合文書が処理対象となっている場合は、ＨＴＭＬユニット５０とＳＶＧユニット６０の双方がロードされる。
【００１７】
このような構成によれば、ユーザは、必要な機能のみを選択してインストールし、後から適宜機能を追加又は削除することができるので、プログラムを格納するハードディスクなどの記録媒体の記憶領域を有効に活用することができ、また、プログラム実行時にも、メモリの浪費を防ぐことができる。また、機能拡張性に優れており、開発主体としても、プラグインの形で新たなボキャブラリに対応することが可能なので開発が容易となり、ユーザとしても、プラグインの追加により容易かつ低コストにて機能を追加することができる。
【００１８】
編集ユニット２４は、ユーザインターフェースを介してユーザから編集指示のイベントを受け付け、そのイベントを適切なプラグインなどに通知するともに、イベントの再実行（リドゥ）又は実行の取消（アンドゥ）などの処理を制御する。
【００１９】
ＤＯＭユニット３０は、ＤＯＭ提供部３２、ＤＯＭ生成部３４、及び出力部３６を含み、ＸＭＬ文書をデータとして扱うときのアクセス方法を提供するために定められた文書オブジェクトモデル（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）であれば、有効なＸＭＬ文書として処理可能である。この場合、挿入された他のボキャブラリのタグは、定義ファイルによりマッピングされてもよい。例えば、ＸＨＴＭＬ文書中に、「重要」、「最重要」などのタグを使用し、これらのタグで囲まれた部分を強調表示してもよいし、重要度の順にソートして表示してもよい。
【００４３】
図１０に示した編集画面において、ユーザにより文書が編集されると、編集された部分を担当するプラグイン又はＶＣユニット８０がソースツリーを変更する。ソースツリーには、ノードごとにミューテーションイベントのリスナーを登録できるようになっており、通常は、各ノードが属するボキャブラリに対応したプラグインの表示部又はＶＣユニット８０がリスナーとして登録される。ＤＯＭ提供部３２は、ソースツリーが変更されると、変更されたノードから上位の階層へたどって、登録されたリスナーがあれば、そのリスナーへミューテーションイベントを発行する。例えば、図９に示した文書において、＜ｈｔｍｌ＞ノードの下位のノードが変更された場合、＜ｈｔｍｌ＞ノードにリスナーとして登録されたＨＴＭＬユニット５０にミューテーションイベントが通知されるとともに、その上位の＜ｓｖｇ＞ノードにリスナーとして登録されたＳＶＧユニット６０にもミューテーションイベントが通知される。このとき、ＨＴＭＬユニット５０は、変更されたソースツリーを参照して表示を更新する。ＳＶＧユニット６０は、自身のボキャブラリに属するノードが変更されていないので、ミューテーションイベントを無視してもよい。
【００４４】
編集の内容によっては、ＨＴＭＬユニット５０による表示の更新に伴って、全体のレイアウトが変わる可能性がある。この場合は、画面のレイアウトを管理する構成、例えば最上位のノードの表示を担当するプラグインにより、プラグインごとの表示領域のレイアウトが更新される。例えば、ＨＴＭＬユニット５０による表示領域が以前より大きくなった場合、ＨＴＭＬユニット５０は、まず自身の担当する部分を描画して、表示領域の大きさを決定する。そして、画面のレイアウトを管理する構成に、変更後の表示領域の大きさを通知し、レイアウトの更新を依頼する。画面のレイアウトを管理する構成は、通知を受けて、プラグインごとの表示領域を再レイアウトする。こうして、編集された部分の表示が適切に更新されるとともに、画面全体のレイアウトが更新される。
以上の技術を前提として、以下、本発明の実施の形態を説明する。
【００４５】
（第１の実施形態）
文書処理装置では、参照先のデータと参照元のデータとの整合性を確保する参照機能が提供されることがある。構造化文書の構成要素を参照する場合、その参照先のロケーションパスと参照元のロケーションパスを対応させて管理することが一般的である。ＸＭＬ文書ではＸＰａｔｈを使って文書内の構成要素のロケーションパスを指定する。この場合、参照先が変更されると、例えば、参照先のロケーションパスを指定して、参照先の変更後の値を取得し、さらに、参照元のロケーションパスを指定して参照元にアクセスし、変更後の値に書き換えることになる。しかし、この方法では文書のツリートラバースが発生するため、参照機能を多数利用した場合に、参照先の変更に伴う参照元の追随処理に時間がかかってしまう。とくに、構造化文書が複雑な構造である場合、この傾向は顕著となる。
【００４６】
このような課題を解決するため、本発明の実施の形態に係る文書処理装置は、参照先ノードのインスタンスの参照オブジェクト（以下、「参照先ノードポインタ」と呼ぶ。）をメモリ上に保持し、参照先ノードのインスタンスから参照先ノードの内容の少なくとも一部（以下、「参照先ノードの値」と呼ぶ。）を直接取得可能にする。これにより、ツリートラバースを発生させることなく高速に、参照先ノードの変更に伴う参照元ノードの追随を可能にする。以下、この仕組みに係る参照機能を「参照枠機能」と呼び、参照元ノードとして、構造化文書に挿入されるデータを「参照枠」と呼ぶことにする。
【００４７】
本明細書における「参照先ノード」および「参照枠ノード」は、特に断らない限り、その子孫ノードを含む。つまり図１１のようなＸＨＴＭＬ文書の場合、参照先ノードとして、＜ｈ２＞から＜／ｈ２＞を指定することができる。この場合、参照先ノードの値として「徳島市川内町」が選択されることになる。また、参照枠ノードは、例えば、＜ｒｅｆ−ｆｒａｍｅ＞から＜／ｒｅｆ−ｆｒａｍｅ＞となる。実際には参照枠ノードの値として「徳島市川内町」が表示されることになる。
また、本明細書における「参照先ノードの値」は、特に断らない限り、参照先ノードの内容の少なくとも一部、の意味とする。これは、例えば前述の例で、図１１において参照先ノードとして＜ｈ２＞から＜／ｈ２＞が指定されていた場合、参照先ノードの値とは、ノード名「ｈ２」「ｓｐａｎ」、ノード値「徳島市川内町」、「川内町」等を含む概念であることを意味する。
【００４８】
次に、図１２・図１３・図１４を用いて、参照枠機能のユーザインタフェイスを説明する。図１２は、アプリケーション３０００にて文書作成中のユーザが、参照先文字列３００２を参照する参照枠をキャレット位置３００６に挿入する前の状態を示している。なお既に、参照枠３００４が二箇所に挿入されている。図１３は、図１２のキャレット位置３００６に、参照枠３００４が出力された状態を示している。図１４は、参照先文字列３００２が、「○○○○株式会社」から「△△△△株式会社」に変更された状態を示している。参照先文字列３００２が変更されると、参照枠機能により、参照枠３００４の表示内容もリアルタイムに変更される。
【００４９】
参照枠機能により、繰り返し記述される単語、文節、句、文等の記述において、その記述の労力を省力化するとともに、記述内容の不整合を防止することができるだけでなく、参照枠ノードの参照先ノードへの追随が高速になり、利便性の高い参照機能を提供することができる。
【００５０】
図１５は、本発明の実施の形態に係る文書処理装置２０の機能ブロック図である。本実施の形態の文書処理装置２０は、前提技術として図１に示した文書処理装置２０の構成に加えて、他のデータへの参照枠機能を提供するプラグインである参照枠ユニット７０を更に備える。参照枠ユニット７０は、参照先管理部７２と、参照枠管理部７４と、参照枠表示部７６と、を有する。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【００５１】
参照先管理部７２は、参照先ノードとして登録された要素を管理する。ここでの要素には、参照先ノードポインタが含まれる。例えば、ユーザが参照先ノードの登録をすると、参照先管理部７２は、参照先ノードポインタを取得する。図１６は、参照先管理部７２における管理テーブルの例である。なお、同図では、参照先ノードの識別情報（以下、「参照先ノードＩＤ」と呼ぶ。）と参照先ノードポインタを保持している。参照先ノードＩＤの列には、同図では数字で示しているが、参照先ノードとして登録された構造化文書の構成要素を一意に特定できる情報が格納される。参照先ノードポインタの列は、参照先ノードのインスタンスの参照オブジェクトが格納される。例えばＪａｖａ言語（登録商標）であれば、java.lang.Stringクラスのオブジェクトや、org.w3c.dom.Nodeクラスのオブジェクトが格納される。なお、参照オブジェクトの中身はメモリのアドレスであり、例えば、「０ｘ１２３４ＡＢＣＤＥ」といった値が格納されている。構造化文書の構成要素毎にこのアドレスが一意になることが保証されている場合、例えばＪａｖａ言語（登録商標）やＣ＋＋言語で実装されている場合、には参照先ノードＩＤは必須ではない。また、対応付けを保持する管理テーブルは、Ｃ＋＋言語におけるコンテナクラスや、Ｊａｖａ（登録商標）言語におけるコレクションフレームワークを利用してメモリ上に保持されてもよい。後述する参照枠管理部７４においても同様である。
【００５２】
参照枠管理部７４は、構造化文書に挿入された参照枠ノードが参照する参照先ノードの情報を保持する。ユーザが構造化文書に参照枠の挿入の操作をした場合、参照枠管理部７４は、まず、参照枠ノードのフラグメントを作成する。例えば、前述した図１１のＸＨＴＭＬ文書における＜ｒｅｆ−ｆｒａｍｅ＞から＜／ｒｅｆ−ｆｒａｍｅ＞を作成する。それから、他の適切なコンポーネントにそのフラグメントを文書に挿入させる。例えば、文書がＸＨＴＭＬ文書であった場合には、ＨＴＭＬユニットに作成したフラグメントを挿入させる。参照枠管理部７４が、作成したフラグメントを文書に挿入してもよい。このフラグメントは、例えば、参照枠のボキャブラリを示す名前空間文字列（図１１の例ではｒｅｆ−ｆｒａｍｅノードのｘｍｌｎｓ属性）と、参照先ノードＩＤ（図１１の例ではｔｒａｃｅｒ−ＩＤノードのｖａｌｕｅ属性）を含む。参照枠管理部７４は、参照枠が参照する参照先ノードが何であるかによって、この参照先ノードＩＤを決定する。
【００５３】
参照枠管理部７４は、さらに、メモリ上でリスナＩＤ、参照先ノードＩＤ、参照先ノードポインタとの対応関係を管理する。リスナＩＤは、参照枠管理部７４から参照先ノードの変更通知を受けたいコンポーネント、例えば、後述する参照枠表示部７６、が登録したリスナオブジェクトの識別情報である。また、このリスナＩＤは、リスナオブジェクトのメモリ上のアドレスのポインタ、つまりリスナオブジェクトそのものであってもよい。図１７は、参照枠管理部７４における管理テーブルの例である。この管理テーブルにデータが設定される流れについては後述する。
参照枠表示部７６は、参照枠のボキャブラリを解釈し、参照枠管理部７４から参照先ノードの値を取得して表示装置に表示させる。
【００５４】
次に、図１８・図１９を使用して、ここまで説明した各機能ブロックが、参照枠機能を実現するためにどのように相互作用をしているかを示す。
【００５５】
図１８は、参照枠の設定に係るシーケンス図である。同図では、ユーザが参照枠の挿入を要求し、参照枠が表示されるまでの、各機能ブロックの相互作用を示している。なお、この例での文書はＸＨＴＭＬ文書としている。最初にユーザは、文書の表示を担当しているＨＴＭＬユニット５０に参照枠の挿入を要求する（ステップＳ２）。ＨＴＭＬユニット５０は、参照枠管理部７４に参照先の選択ダイヤログを要求する（ステップＳ４）。参照枠管理部７４は参照先管理部７２に登録されている参照先一覧を要求する（ステップＳ６）。参照先管理部７２は、参照枠管理部７４に参照先一覧を提供する（ステップＳ８）。参照先一覧の提供にあわせて、それぞれの参照先ノードＩＤと参照先ノードポインタが提供される。参照枠管理部７４は、参照先の選択ダイヤログを表示する（ステップＳ１０）。
【００５６】
次に、ユーザは表示された選択ダイヤログから参照先を選択する（ステップＳ１２）。参照枠管理部７４は、前述した参照枠のフラグメントを作成し（ステップＳ１４）、そのフラグメントをＨＴＭＬユニット５０に返す（ステップＳ１６）。ＨＴＭＬユニット５０は、返された参照枠のフラグメントをソースツリーに挿入する（ステップＳ１８）。上記ステップＳ１８の結果、ソースツリーが変更されて、ＤＯＭユニット３０は、前提技術で説明したミューテーションイベントを参照枠管理部７４に通知する（ステップＳ２０）とともに、ＨＴＭＬユニット５０にＸＨＴＭＬボキャブラリを解釈して、画面表示をするように要求する（ステップＳ２４）。
【００５７】
ＤＯＭユニット３０よりミューテーションイベントを通知された参照枠管理部７４は、挿入された参照枠の監視を開始し、参照先管理部７２からの変更通知を待ち受ける（ステップＳ２２）。ここで、監視を開始するに先立って、参照枠管理部７４は、参照先管理部７２に変更通知用のリスナオブジェクトを登録する。それとともに、参照枠管理部７４は、先のステップＳ８で参照先管理部７２より提供された参照先ノードに係る参照先ノードＩＤと参照先ノードポインタを管理テーブルにて保持する。
【００５８】
一方で、ＤＯＭユニット３０からＸＨＴＭＬ文書の画面表示を要求されたＨＴＭＬユニット５０は、前提技術で説明したように表示処理を行う。その中で、参照枠ボキャブラリを検出すると、参照枠表示部７６に参照枠ボキャブラリの表示を要求する（ステップＳ２６）。参照枠表示部７６は、参照先変更の通知を受けるため、参照枠管理部７４に対しリスナオブジェクトを登録する（ステップＳ２８）。このときに、参照枠管理部７４が保持する管理テーブルにリスナＩＤまたはリスナオブジェクトそのものが格納される。また、参照枠表示部７６は、リスナオブジェクトの登録後、参照枠のフラグメントに含まれる参照先ノードＩＤをキーとして表示文字列を要求する（ステップＳ３０）。
【００５９】
参照枠管理部７４は、参照先ノードＩＤと対応付けられた参照先ノードポインタを取得し、その参照先ノードポインタが備えるメソッドを操作して表示文字列を取得する。例えば、ＤＯＭのノードオブジェクトが格納されていた場合、ＤＯＭのＡＰＩ（Application Programming Interface）を利用して、そのノードオブジェクトから表示文字列を取得する。そして、参照枠管理部７４は、参照枠表示部７６に取得した文字列を提供し（ステップＳ３２）、参照枠表示部７６は、構造化文書の参照枠ボキャブラリ部分にその文字列を表示させる（ステップＳ３４）。
【００６０】
図１９は、参照先の値の変更に伴う参照元の値の変更に係るシーケンス図である。同図は、ユーザが参照先を編集し、その編集内容が参照枠に反映されるまでの、各機能ブロックの相互作用を示している。まず、ユーザが参照先ノードまたはその子孫ノードの編集をする（ステップＳ４２）。すると、表示を担当しているＨＴＭＬユニット５０はその編集内容でソースツリーを変更する（ステップＳ４４）。ＤＯＭユニット３０は、参照先として登録されているノードおよびその子孫ノードのミューテーションイベントを参照先管理部７２に通知する（ステップＳ４６）。参照先管理部７２は、参照先ノードＩＤまたは参照先ノードポインタをキーとして、登録されているリスナオブジェクトを介して、参照枠管理部７４に参照先ノードが変更された旨を通知する（ステップＳ４８）。参照枠管理部７４は、キーとして送られてきた参照先ノードＩＤまたは参照先ノードポインタと、保持する管理テーブルから、変更された参照先ノードに対応する参照枠ノードが存在するかを判定する（ステップＳ５０）。
【００６１】
ステップＳ５０において、対応する参照枠ノードが存在した場合、参照枠管理部７４は、参照先ノードＩＤまたは参照先ノードポインタに対応するリスナＩＤを取得する。そして、参照枠管理部７４に登録されているリスナオブジェクトであって、そのリスナＩＤに対応するリスナオブジェクトを介して、参照枠表示部７６に参照先ノードの変更を通知する（ステップＳ５２）。参照枠表示部７６は、ＤＯＭユニット３０に再表示を要求（ステップＳ５４）する。そして図１５のステップＳ２４以降と同様のシーケンスで参照枠が表示される。この場合、参照枠管理部７４は、参照先ノードポインタをもとに参照先ノードのインスタンスから変更後の文字列を取得するため、最終的に参照枠に表示される文字列も変更後の文字列となる。
【００６２】
本発明の第一の特徴は、参照枠ユニット７０が、メモリ上に参照先ノードポインタを保持し、参照先ノードの変更の際には、その参照先ノードポインタをもとに参照先ノードのインスタンスから参照先ノードの値を直接取得することで変更後データを参照枠に表示していることである。上記のシーケンス説明から明らかなように、ＸＰａｔｈを利用した際に生ずるツリートラバースを発生させることもなく、さらに、参照先ノードの変更に伴って参照枠ノードのフラグメントの変更処理も発生させない。結果として、参照枠ノードを参照先ノードに高速に追随させることを可能にしている。更に、ツリートラバースを発生させないことから、ＸＰａｔｈを利用した場合と比べて、参照枠機能の性能がＸＭＬ文書の複雑さには非依存であることも長所である。この特徴により、ユーザが構造化文書の編集等で参照機能を用いる場合の利便性を向上できる。
【００６３】
本発明の第二の特徴は、ボキャブラリ境界を越えて、特定の構成要素を参照表示できることである。シーケンス図において、参照先管理部７２・参照枠管理部７４・参照枠表示部７６のいずれも特定のボキャブラリに依存した処理はない。そのため例えば、スプレッドシートボキャブラリにある総額セルを参照先として登録しておき、ＨＴＭＬ側で参照枠を挿入することで、そのセルを参照可能になる。更にそのセルが変更された場合には、自動的にＨＴＭＬ側の総額セルの表示も変更される。この特徴により、ユーザは文書内のデータを有効に利用できることになる。
【００６４】
さらに本発明では、参照枠ユニット７０内の各サブモジュール間の独立性が高い構成となっている。実施の形態に係る参照先管理部７２と参照枠管理部７４との接点はリスナオブジェクトを介した変更通知に過ぎない。したがって、参照先管理部７２と参照枠管理部７４は、他方を意識することなく機能追加・バグ修正等メンテナンスができるとともに、参照先管理部７２は参照枠管理部７４が存在しなくても動作できる。これにより、他のプラグイン等に対しても参照先一覧を提供できる。同様に、実施の形態に係る参照枠管理部７４と参照枠表示部７６との接点もリスナオブジェクトを介した変更通知に過ぎない。したがって、参照枠管理部７４と参照枠表示部７６は、他方を意識することなく機能追加・バグ修正等メンテナンスができるとともに、参照枠管理部７４は参照枠表示部７６が存在しなくても動作できる。これにより、参照枠管理部７４は、参照枠表示部７６に限定されることなく、他のプラグイン等に対しても参照枠データを提供できる。
【００６５】
（第２の実施形態）
本実施形態と第１の実施形態とは、参照先ノードの値の取得する主体が異なる。
前述の図１９のシーケンス図のステップＳ３０の部分で、参照枠表示部７６は、参照枠管理部に参照先ノードＩＤをキーに参照先ノードポインタを要求する。参照枠管理部７４は、参照先ノードＩＤに対応する参照先ノードポインタを参照枠表示部７６に返す。ここで、前述の参照枠管理部７４と同様に、参照枠表示部７６は、参照先ノードポインタをもとに参照先ノードのインスタンスから参照先ノードの値を直接取得して、その値を参照枠ボキャブラリ部分に表示させる。
【００６６】
（第３の実施形態）
本実施形態と第１の実施形態とは、また、本実施形態と第２の実施形態とは、参照先ノードの値を表示する方法が異なる。
前述の図１９のシーケンス図のステップＳ３４の部分で、参照枠表示部７６は、参照先ノードの値を他のボキャブラリユニットに表示させる。例えば、参照先ノードの値がＳＶＧによって記述された文字列であった場合には、ＳＶＧユニットに参照先ノードの値を表示させ、ＭａｔｈＭＬによって記述された文字列であった場合には、ＭａｔｈＭＬユニットに参照先ノードの値を表示させる。
【００６７】
先の２つの実施形態の場合、参照枠表示部７６が、参照先ノードまたはその子孫のノードが有するテキストノードのテキスト値を表示することを想定していたが、参照先ノードの値をそのボキャブラリに応じて適切に表示するためには、参照枠表示部７６は、参照先ノードの値がとりうる全てのボキャブラリを理解できる必要がある。また参照枠表示部７６が理解できないボキャブラリにより参照先ノードの値が記述されていた場合には、文書のソース又はツリー構造を表示するしかない。
本実施形態によれば、参照先ノードの値のボキャブラリに応じて適切なボキャブラリユニットを選択することで、参照枠表示部７６が理解するボキャブラリの幅を広げる必要なく、参照先ノードの値を適切に表示しやすくなる。なお、適切なボキャブラリユニットの選択は、そのボキャブラリ領域の名前空間の記述で判断することで可能である。参照枠表示部７６は、参照先ノードが、自身が処理できないボキャブラリで記述されていたときに、参照先ノードの処理を他の処理系に委譲する旨を主制御ユニット２２へ通知してもよい。この場合、主制御ユニット２２は、参照先ノードの名前空間や要素名などに基づいて適切な処理系を選択し、その処理系に処理を委譲する。
【００６８】
（第４の実施形態）
第１から第３の実施形態では、参照枠管理部７４が作成する参照枠ノードのフラグメントには、参照先ノードＩＤのみが格納されていた。本実施形態では、参照枠ノードのフラグメントに、参照先ノードのテキスト値または参照先ノード自身など、参照枠の表示に必要な情報を格納する。これにより、参照枠ノードの周囲のノードが編集されるなどして、参照先ノードが編集されていないにもかかわらず参照先ノードを再描画する必要が生じたときに、参照先ノードを参照することなく参照枠ノードを再描画することができるので、高速に表示を更新することができる。第１から第３の実施形態では、参照枠ノードには参照先ノードのＩＤしか格納されていないので、参照先ノードが編集されても参照枠ノードを編集する必要はなかった。しかし本実施形態では、参照枠管理部７４は、参照先ノードが編集されたときに、参照先ノードを参照して参照枠ノードを編集し、追随させる。
【００６９】
いずれの実施形態においても、参照先管理部７２が保持する管理テーブル、参照枠管理部７４が保持する管理テーブル、ともに揮発性のメモリ上に保持される。この場合、本発明の実施の形態に係る文書処理装置２０を終了すれば、メモリ上の管理テーブルは失われる。なお、管理テーブルは不揮発のストレージに保持されてもよく、参照先ノードポインタも参照型のオブジェクトであるので、シリアライズ化しストレージに保持できる。またオブジェクト指向ＤＢ等であれば、オブジェクトのままストレージに保持できる。しかし、一旦メモリ展開されていた構造化文書は、文書処理装置２０の再起動時には、別のメモリ領域に展開されるため、前回の参照先ノードポインタを使うことはできない。言い換えれば、管理テーブルを揮発性のメモリ上に保持していたとしても、または、不揮発性のストレージに保持していたとしても、文書処理装置２０を一旦終了し、再度起動した時に参照枠は無効となってしまう。文書処理装置２０の終了時に、参照枠ノードの値を参照先ノードの値で置き換えるのは一つの解決手段であるが、一旦構造化文書の中に設定された参照枠は、次回起動時にもそのまま参照枠として使えた方がユーザの利便性は高い。
【００７０】
この課題に対し、本発明者は以下の解決手段に想到した。
例えば、図１１の構造化文書で「/html/body/h1」が参照先ノードとして設定され、同文書内の「/html/body/p/ref-frame」が参照枠ノードであったとする。ここで、文書処理装置２０の終了時には、図１５では図示しない永続化処理部が、参照枠ノードの中に参照先ノードのロケーションパス、ここでは「/html/body/h1」、を設定しておく。より簡易的に、「/*[1]/*[2]/*[1]/」などと表現してもよい。再度構造化文書を展開した際に、ノード「ref-frame」は、ＨＴＭＬユニット５０では処理できないため、処理が参照枠ユニット７０に委譲される。このとき、永続化処理部は、参照先ノードとして「/html/body/h1」が登録されていたことを認識する。次に永続化処理部は、その参照先ノードの現在の参照先ノードポインタを取得し、参照先管理部７２に通知する。参照先管理部７２は、通知された参照先ノードポインタをもとに管理テーブルを作成する。参照先ノードＩＤは参照先管理部７２が一意に設定してもよいが、永続化処理部が参照枠ノードから参照先ノードＩＤを取得して参照枠ノードポインタとともに通知してもよい。続いて、参照枠管理部７４は、参照先管理部７２から、参照先ノードポインタと参照先ノードＩＤの通知を受けて、管理テーブルを作成する。なお、参照枠管理部７４が保持する管理テーブルに存在するリスナＩＤの情報は、参照枠表示部７６が最初に参照枠を表示するときに、再度リスナを登録すればよい。
この手段によれば、文書処理装置２０を終了しても、構造化文書に既に挿入されていた参照枠は、構造化文書の再読み込み時に管理テーブルとともに復元ができ、ユーザの利便性を高めることができる。
【００７１】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【図面の簡単な説明】
【００７２】
【図１】本発明の前提技術に係る文書処理装置の構成を示す図である。
【図２】前提技術に係る文書処理装置により処理されるＸＭＬ文書の例を示す図である。
【図３】図２に示したＸＭＬ文書をＨＴＭＬで記述された表にマッピングする例を示す図である。
【図４（ａ）】図２に示したＸＭＬ文書を図３に示した表にマッピングするためのＶＣ定義ファイルの例を示す図である。
【図４（ｂ）】図２に示したＸＭＬ文書を図３に示した表にマッピングするためのＶＣ定義ファイルの例を示す図である。
【図５】図２に示したＸＭＬ文書を図３に示した対応によりＨＴＭＬにマッピングして表示した画面の例を示す図である。
【図６】ＶＣ定義ファイル生成部がユーザに提示するグラフィカルユーザインターフェースの例を示す図である。
【図７】ＶＣ定義ファイル生成部により生成された画面レイアウトの他の例を示す図である。
【図８】文書処理装置によるＸＭＬ文書の編集画面の一例を示す図である。
【図９】前提技術に係る文書処理装置により処理されるＸＭＬ文書の他の例を示す図である。
【図１０】図９に示した文書を表示した画面の例を示す図である。
【図１１】ＸＨＴＭＬ文書の例である。
【図１２】参照枠機能のユーザインタフェイスを説明する図である。
【図１３】参照枠機能のユーザインタフェイスを説明する図である。
【図１４】参照枠機能のユーザインタフェイスを説明する図である。
【図１５】本発明の実施の形態に係る文書処理装置の機能ブロック図である。
【図１６】参照先管理部の管理テーブルの例である。
【図１７】参照枠管理部の管理テーブルの例である。
【図１８】参照枠の設定に係るシーケンス図である。
【図１９】参照先の値の変更に伴う参照枠の値の変更に係るシーケンス図である。
【符号の説明】
【００７３】
２０ 文書処理装置、２２ 主制御ユニット、２４ 編集ユニット、３０ ＤＯＭユニット、３２ ＤＯＭ提供部、３４ ＤＯＭ生成部、３６ 出力部、４０ ＣＳＳユニット、４２ ＣＳＳ解析部、４４ ＣＳＳ提供部、４６ レンダリング部、５０ ＨＴＭＬユニット、５２，６２ 制御部、５４，６４ 編集部、５６，６６ 表示部、６０ ＳＶＧユニット、７０ 参照枠ユニット、７２ 参照先管理部、７４ 参照枠管理部、７６ 参照枠表示部、８０ ＶＣユニット、８２ マッピング部、８４ 定義ファイル取得部、８６ 定義ファイル生成部、３０００ アプリケーション、３００２ 参照先文字列、３００４ 参照枠、３００６ キャレット位置、Ｓ２ 参照枠の挿入、Ｓ４ 参照先の選択ダイヤログを要求、Ｓ６ 参照先一覧の要求、Ｓ８ 参照先一覧の提供、Ｓ１０ 参照先の選択ダイヤログを表示、Ｓ１２ 参照先を選択、Ｓ１４ 参照枠フラグメントの生成、Ｓ１６ 参照枠フラグメントを返す、Ｓ１８ 参照枠フラグメントの挿入、Ｓ２０ ミューテーションイベントの通知、Ｓ２２ 挿入された参照枠の監視開始、Ｓ２４ ＸＨＴＭＬ表示要求、Ｓ２６ 参照枠表示要求、Ｓ２８ リスナ登録、Ｓ３０ 表示文字列要求、Ｓ３２ 表示文字列提供、Ｓ３４ 参照枠の表示、Ｓ４２ 参照先の編集、Ｓ４４ ソースツリーの変更、Ｓ４６ ミューテーションイベントの通知、Ｓ４８ 参照先の変更通知、Ｓ５０ 対応する参照枠の存否の確認、Ｓ５２ 参照先の変更通知、Ｓ５４ 再表示要求。
【特許請求の範囲】
【請求項１】
マークアップ言語により記述された文書を表示するための処理系と、
前記文書に含まれる構成要素を参照先ノードとして登録する要求を受け付けたときに、前記参照先ノードのインスタンスの参照オブジェクトを取得し、前記処理系において前記参照先ノードを参照する参照枠ノードを表示する際に、前記参照オブジェクトを処理系に出力するか、または、前記参照先ノードの内容の少なくとも一部を前記参照オブジェクトから取得して、取得した情報を処理系に出力する参照枠ユニットと、
を備えることを特徴とする文書処理装置。
【請求項２】
前記参照枠ユニットは、ツリートラバースをすることなく、前記参照オブジェクトを操作することで、参照先ノードのインスタンスから参照先ノードの内容の少なくとも一部を直接取得することを特徴とする請求項１に記載の文書処理装置。
【請求項３】
前記参照枠ユニットは、
前記参照先ノードを管理し、参照先ノードが前記処理系により変更された場合には所定の通知先にその変更を通知する参照先管理部と、
マークアップ言語により記述された、前記参照枠ノードに対応するフラグメントを作成し、前記処理系に前記フラグメントを文書へ挿入させるとともに、前記参照先ノードが前記処理系により変更された場合には所定の通知先にその変更を通知する参照枠管理部と、
を備えることを特徴とする請求項１または２に記載の文書処理装置。
【請求項４】
前記フラグメントには、前記参照先ノードの識別情報が含まれることを特徴とする請求項３に記載の文書処理装置。
【請求項５】
前記フラグメントには、前記参照先ノードの内容の少なくとも一部が含まれ、
前記参照枠管理部は更に、前記参照先ノードが前記処理系により変更された場合には、前記フラグメントに含まれる参照先ノードの内容を変更することを特徴とする請求項３に記載の文書処理装置。
【請求項６】
前記参照枠管理部は、前記参照先管理部の通知先として登録し、前記参照先ノードが変更された場合には、参照先管理部から変更通知を受けることを特徴とする請求項３から５のいずれかに記載の文書処理装置。
【請求項７】
前記参照枠ユニットは、前記参照枠管理部より前記参照枠ノードが参照する参照先ノードの内容の少なくとも一部を取得して表示装置に表示させる参照枠表示部を更に備えることを特徴とする請求項３から６のいずれかに記載の文書処理装置。
【請求項８】
前記参照枠ユニットは、前記参照枠管理部より前記参照枠ノードが参照する参照先ノードのインスタンスの参照オブジェクトを取得して、参照先ノードの内容の少なくとも一部を参照オブジェクトから取得して表示装置に表示させる参照枠表示部を更に備えることを特徴とする請求項３から６のいずれかに記載の文書処理装置。
【請求項９】
前記参照枠表示部は、取得した前記参照先ノードの内容の少なくとも一部を、その参照先ノードが属するマークアップ言語により記述された文書を表示するための処理系に表示させることを特徴とする請求項７または８に記載の文書処理装置。
【請求項１０】
前記参照枠表示部は、前記参照枠管理部の前記通知先として登録し、前記参照先ノードが変更された場合には、参照枠管理部から変更通知を受けることを特徴とする請求項７から９のいずれかに記載の文書処理装置。
【請求項１１】
前記参照先ノードに係るボキャブラリは、前記参照枠ノードに係るボキャブラリとは異なるマークアップ言語により記述されることを特徴とする請求項１から１０のいずれかに記載の文書処理装置。
【請求項１２】
マークアップ言語により記述された文書に含まれる構成要素を参照先ノードとして登録する要求を受け付けるステップと、
前記参照先ノードのインスタンスの参照オブジェクトを取得するステップと、
前記参照先ノードを参照する参照枠ノードを表示する際に、前記参照オブジェクトを処理系に出力するか、または、前記参照先ノードの内容の少なくとも一部を前記参照オブジェクトから取得するステップと、
前記マークアップ言語により記述された文書を表示するステップと、
を備えることを特徴とする文書処理方法。
【請求項１３】
マークアップ言語により記述された文書を表示するための処理機能と、
前記文書に含まれる構成要素を参照先ノードとして登録する要求を受け付けたときに、前記参照先ノードのインスタンスの参照オブジェクトを取得し、前記処理機能において前記参照先ノードを参照する参照枠ノードを表示する際に、前記参照オブジェクトを処理機能に出力するか、または、前記参照先ノードの内容の少なくとも一部を前記参照オブジェクトから取得して、取得した情報を前記処理機能に出力する機能と、
をコンピュータに実現させることを特徴とするコンピュータプログラム。
【請求項１】
マークアップ言語により記述された文書を表示するための処理系と、
前記文書に含まれる構成要素を参照先ノードとして登録する要求を受け付けたときに、前記参照先ノードのインスタンスの参照オブジェクトを取得し、前記処理系において前記参照先ノードを参照する参照枠ノードを表示する際に、前記参照オブジェクトを処理系に出力するか、または、前記参照先ノードの内容の少なくとも一部を前記参照オブジェクトから取得して、取得した情報を処理系に出力する参照枠ユニットと、
を備えることを特徴とする文書処理装置。
【請求項２】
前記参照枠ユニットは、ツリートラバースをすることなく、前記参照オブジェクトを操作することで、参照先ノードのインスタンスから参照先ノードの内容の少なくとも一部を直接取得することを特徴とする請求項１に記載の文書処理装置。
【請求項３】
前記参照枠ユニットは、
前記参照先ノードを管理し、参照先ノードが前記処理系により変更された場合には所定の通知先にその変更を通知する参照先管理部と、
マークアップ言語により記述された、前記参照枠ノードに対応するフラグメントを作成し、前記処理系に前記フラグメントを文書へ挿入させるとともに、前記参照先ノードが前記処理系により変更された場合には所定の通知先にその変更を通知する参照枠管理部と、
を備えることを特徴とする請求項１または２に記載の文書処理装置。
【請求項４】
前記フラグメントには、前記参照先ノードの識別情報が含まれることを特徴とする請求項３に記載の文書処理装置。
【請求項５】
前記フラグメントには、前記参照先ノードの内容の少なくとも一部が含まれ、
前記参照枠管理部は更に、前記参照先ノードが前記処理系により変更された場合には、前記フラグメントに含まれる参照先ノードの内容を変更することを特徴とする請求項３に記載の文書処理装置。
【請求項６】
前記参照枠管理部は、前記参照先管理部の通知先として登録し、前記参照先ノードが変更された場合には、参照先管理部から変更通知を受けることを特徴とする請求項３から５のいずれかに記載の文書処理装置。
【請求項７】
前記参照枠ユニットは、前記参照枠管理部より前記参照枠ノードが参照する参照先ノードの内容の少なくとも一部を取得して表示装置に表示させる参照枠表示部を更に備えることを特徴とする請求項３から６のいずれかに記載の文書処理装置。
【請求項８】
前記参照枠ユニットは、前記参照枠管理部より前記参照枠ノードが参照する参照先ノードのインスタンスの参照オブジェクトを取得して、参照先ノードの内容の少なくとも一部を参照オブジェクトから取得して表示装置に表示させる参照枠表示部を更に備えることを特徴とする請求項３から６のいずれかに記載の文書処理装置。
【請求項９】
前記参照枠表示部は、取得した前記参照先ノードの内容の少なくとも一部を、その参照先ノードが属するマークアップ言語により記述された文書を表示するための処理系に表示させることを特徴とする請求項７または８に記載の文書処理装置。
【請求項１０】
前記参照枠表示部は、前記参照枠管理部の前記通知先として登録し、前記参照先ノードが変更された場合には、参照枠管理部から変更通知を受けることを特徴とする請求項７から９のいずれかに記載の文書処理装置。
【請求項１１】
前記参照先ノードに係るボキャブラリは、前記参照枠ノードに係るボキャブラリとは異なるマークアップ言語により記述されることを特徴とする請求項１から１０のいずれかに記載の文書処理装置。
【請求項１２】
マークアップ言語により記述された文書に含まれる構成要素を参照先ノードとして登録する要求を受け付けるステップと、
前記参照先ノードのインスタンスの参照オブジェクトを取得するステップと、
前記参照先ノードを参照する参照枠ノードを表示する際に、前記参照オブジェクトを処理系に出力するか、または、前記参照先ノードの内容の少なくとも一部を前記参照オブジェクトから取得するステップと、
前記マークアップ言語により記述された文書を表示するステップと、
を備えることを特徴とする文書処理方法。
【請求項１３】
マークアップ言語により記述された文書を表示するための処理機能と、
前記文書に含まれる構成要素を参照先ノードとして登録する要求を受け付けたときに、前記参照先ノードのインスタンスの参照オブジェクトを取得し、前記処理機能において前記参照先ノードを参照する参照枠ノードを表示する際に、前記参照オブジェクトを処理機能に出力するか、または、前記参照先ノードの内容の少なくとも一部を前記参照オブジェクトから取得して、取得した情報を前記処理機能に出力する機能と、
をコンピュータに実現させることを特徴とするコンピュータプログラム。
【図１】
【図２】
【図３】
【図４（ａ）】
【図４（ｂ）】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２】
【図３】
【図４（ａ）】
【図４（ｂ）】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【公開番号】特開２００８−２５７２７７（Ｐ２００８−２５７２７７Ａ）
【公開日】平成２０年１０月２３日（２００８．１０．２３）
【国際特許分類】
【出願番号】特願２００７−７３６８５（Ｐ２００７−７３６８５）
【出願日】平成１９年３月２０日（２００７．３．２０）
【出願人】（３９００２４３５０）株式会社ジャストシステム (123)
【Ｆターム（参考）】
【公開日】平成２０年１０月２３日（２００８．１０．２３）
【国際特許分類】
【出願日】平成１９年３月２０日（２００７．３．２０）
【出願人】（３９００２４３５０）株式会社ジャストシステム (123)
【Ｆターム（参考）】
[ Back to top ]