JP2006139623A - 文書処理装置 - 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）であれば、有効なＸＭＬ文書として処理可能である。この場合、挿入された他のボキャブラリのタグは、定義ファイルによりマッピングされてもよい。例えば、ＸＨＴＭＬ文書中に、「重要」、「最重要」などのタグを使用し、これらのタグで囲まれた部分を強調表示してもよいし、重要度の順にソートして表示してもよい。

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

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

（実施の形態）
実施の形態では、ＸＭＬデータを読み込んだときに文書処理装置において生成されるバイナリデータを保存する技術を提案する。

図１１は、本実施の形態の技術を説明するための図である。文書処理装置１００がＸＭＬファイルを読み込んだとき、ＸＭＬファイルに他のファイルをインクルードしたり、文字コードを変換するなど必要な前処理を行った後、ＸＭＬパーサがファイルの内容をパースして正当性をチェックし、さらに、バリデーションチェックによりＸＭＬの妥当性が確認される。これらのチェックが終了すると、ＤＯＭ生成部１３４によりＤＯＭが生成される。

本実施の形態では、文書処理装置１００は、シリアライズ部３２０を備えており、シリアライズ部３２０によりＤＯＭをシリアライズしてファイルに保存する。シリアライズ部３２０は、例えば、ＪＡＶＡ（登録商標）のシリアライズ機能を用いてＤＯＭをシリアライズしてもよい。文書処理装置１００は、デシリアライズ部３２２も備えており、バイナリファイルを読み込んで、デシリアライズ部３２２によりバイナリデータをデシリアライズしてＤＯＭを生成する機能を有する。

このバイナリファイルは、ＸＭＬファイルのキャッシュとして利用されてもよい。すなわち、ＸＭＬファイルを読み込んでＤＯＭを生成する代わりに、バイナリファイルを読み込んでＤＯＭを生成してもよい。これにより、いったんバイナリファイルを生成して保存しておけば、次回以降、パースなどの前処理を省略し、バイナリファイルを読み込んで直接ＤＯＭを生成することができるので、ＤＯＭを生成するまでの処理時間を短縮することができる。文書処理装置１００は、ＤＯＭをバイナリデータとしてそのまま保存してもよい。すなわち、メモリイメージをそのままコピーしてもよい。これにより、さらに高速にＤＯＭを生成することができる。この場合、シリアライズ部３２０及びデシリアライズ部３２２を設けなくてもよい。

また、ＸＭＬファイルは、テキストデータから構成されるので、テキストエディタなどで開くことにより内容を見ることができるという特徴がある。これに対して、本実施の形態のバイナリファイルのみを保存し、第三者に配布するようにすれば、テキストデータよりは内容の機密性が高まる。また、第三者による内容の改変の防止にもつながる。秘匿性を向上させるために、バイナリデータをスクランブルしたり暗号化したりしてもよい。

ＸＭＬファイルの内容を秘匿するために、ＸＭＬファイルを暗号化するという技術もあるが、この技術によれば、ＸＭＬファイルを開くときに復号化しなければならず、その後に、前処理、パース、バリデーションチェックなどを実行するので、ファイルを開くまでに時間を要する。本実施の形態の技術によれば、バイナリファイルをデシリアライズすればＤＯＭが生成されるので、内容を秘匿しつつ、処理速度も速いという効果が得られる。

ＸＭＬファイルの改変を防止するために、ＸＭＬファイルに署名をつけるという技術も存在するが、この場合、テキストエディタにより内容を見ることができる。本実施の形態の技術によれば、バイナリ化するのでテキストデータよりは機密性が高く、しかも、デシリアライズしなければファイルを開けないので、容易には改竄できないという効果が得られる。

本実施の形態の技術は、特に、定義ファイルの内容を秘匿し、第三者の改竄を防止するために適している。定義ファイルもＸＭＬファイルであるから、上述の方法によりシリアライズしてバイナリファイルとすることができる。独自に開発したボキャブラリを処理可能な定義ファイルや、独自の機能を有する定義ファイルを開発したベンダーが、その定義ファイルを配布する場合、定義ファイルの内容を秘匿し、改竄を防止するために、本実施の形態の技術を用いてバイナリファイルとして配布してもよい。文書処理装置１００で定義ファイルを利用するとき、デシリアライズ部３２２によりデシリアライズして定義ファイルの内容をＤＯＭ化し、ＶＣＤ−ＤＯＭを生成する。この場合、定義ファイルの内容をソース表示する機能を禁止し、定義ファイルの内容を秘匿するようにしてもよい。

定義ファイルをバイナリ化する場合、定義ファイルから生成されるＶＣＤ−ＤＯＭをシリアライズしてもよいし、ＶＣＤ−ＤＯＭから生成されるコネクタファクトリーツリーをシリアライズしてもよい。コネクタファクトリーツリーは、ＶＣＤ（定義ファイル）のテンプレートに記述されたコネクタを生成する主体となるオブジェクトである。また、ＸＭＬ文書ファイルをバイナリ化する場合、ＤＯＭツリーから生成されるビューオブジェクトをシリアライズしてもよい。

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

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

前提技術に係る文書処理装置の構成を示す図である。 文書処理装置により編集されるＸＭＬ文書の例を示す図である。 図２に示したＸＭＬ文書をＨＴＭＬで記述された表にマッピングする例を示す図である。 図２に示したＸＭＬ文書を図３に示した表にマッピングするための定義ファイルの例を示す図である。 図２に示したＸＭＬ文書を、図３に示した対応によりＨＴＭＬにマッピングして表示した画面の例を示す図である。 ユーザが定義ファイルを生成するために、定義ファイル生成部がユーザに提示するグラフィカルユーザインターフェースの例を示す図である。 定義ファイル生成部により生成された画面レイアウトの他の例を示す図である。 文書処理装置によるＸＭＬ文書の編集画面の一例を示す図である。 文書処理装置により編集されるＸＭＬ文書の他の例を示す図である。 図９に示した文書を表示した画面の例を示す図である。 実施の形態の技術を説明するための図である。

符号の説明

１００ 文書処理装置、１１０ 主制御ユニット、１２０ 編集ユニット、１３０ ＤＯＭユニット、１３２ ＤＯＭ提供部、 １３４ ＤＯＭ生成部、１３６ 出力部、１４０ ＣＳＳユニット、１５０ ＨＴＭＬユニット、１６０ ＳＶＧユニット、１８０ ＶＣユニット、１８２ マッピング部、１８４ 定義ファイル取得部、１８６ 定義ファイル生成部、３２０ シリアライズ部、３２２ デシリアライズ部。

Claims (3)

1. ＸＭＬファイルからＤＯＭを生成する手段と、
   前記ＤＯＭをバイナリデータとして保存する保存手段と、
   を備えることを特徴とする文書処理装置。
2. 前記ＤＯＭからバイナリデータの構造体を生成する手段を更に備え、
   前記保存手段は、前記ＤＯＭに代えて前記バイナリデータの構造体を保存することを特徴とする請求項１に記載の文書処理装置。
3. ＸＭＬファイルから生成されたバイナリデータが保存されたファイルを取得する手段と、
   前記ファイルから前記バイナリデータを生成する手段と、
   を備えることを特徴とする文書処理装置。

Images