JP4942144B2

JP4942144B2 - 情報処理装置及びその制御方法、プログラム、記憶媒体

Info

Publication number: JP4942144B2
Application number: JP2005362369A
Authority: JP
Inventors: 均内田
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2005-12-15
Filing date: 2005-12-15
Publication date: 2012-05-30
Anticipated expiration: 2025-12-15
Also published as: JP2007164630A

Description

本発明は構造化文書を処理するための情報処理技術に関する。

従来より、ＸＭＬ等の構造化文書をアプリケーションにおいて読み取り、読み取った構造化文書のデータを操作する技術としてＤＯＭやＳＡＸが一般的に知られている。ただし、ＸＭＬは、Extensible Markup Languageの略称である。また、ＤＯＭは、Document Object Model（ドキュメント・オブジェクト・モデル）の略称である。また、ＳＡＸは、Simple API for XMLの略称である。

しかし、これらの技術を利用して、構造化文書の読み取りや操作の処理を有するアプリケーションを、所定のプログラミング言語で実装する場合、開発者は、構造化文書の構造を事前に知っている必要がある。このため、異なる文書構造を持つ構造化文書のデータの読み取りや操作を行うアプリケーションを作成するために、開発者は構造化文書の構造に合わせたＤＯＭやＳＡＸのアプリケーションを作り直さなければならない場合があった。このように、ＤＯＭやＳＡＸを用いた開発は、多くの時間を要することがあった。

上記の問題に鑑み、近年、Sun MicrosystemsのＪＡＸＢや浅海智晴氏のRelaxerなどのデータバインディングツールが開発されている。これらのデータバインディングツールは、スキーマコンパイラを用いることによりXML SchemaやRELAX NGといったスキーマを基にプログラミング言語ＪＡＶＡで記述されたプログラムを自動生成する。自動生成されたＪＡＶＡにより記述されたプログラムを用いることによって、構造化文書をＪＡＶＡのクラスに読み込む処理や構造化文書としてファイルに書き出す処理等の、構造化文書へのアクセスを容易に実行することができる。

ＤＯＭやＳＡＸを利用するアプリケーションをプログラミングする場合、構造化文書の構造に合わせたプログラムを開発する必要があり、プログラムの開発工程数が非常に多くなる。これに対し、データバインディングツールを用いた開発においては、自動生成されるＪＡＶＡのＡＰＩを用いることによりアプリケーションにおいて構造化文書のデータをＪＡＶＡのメンバ変数として指定できる。このため、プログラムの開発工程数を削減することができ、プログラム開発者の負担を減らすことができる。

スキーマ文書を基に自動生成されたＪＡＶＡのプログラムを用いて、構造化文書のデータをアプリケーションにおいて扱うことのできるデータに変換する処理をアンマーシャルと呼ぶ。また、自動生成されたＪＡＶＡのプログラムを用いて、アプリケーションがＪＡＶＡのクラスに格納しているデータを構造化文書のデータとしてファイルに書き出す操作をマーシャルと呼ぶ。

図１はＪＡＶＡで記述されたプログラムに読み込む構造化文書（図１（ｂ））と構造化文書に対応するベクターグラフィックス（図１（ａ））を例示した図である。

図２は図１（ｂ）の構造化文書と妥当な関係にあるスキーマ文書の例として、XML Schemaの記述を例示した図である。

図３、図４は、図２に示したスキーマ文書を入力としてデータバインディングツールＪＡＸＢに含まれるスキーマコンパイラxjc.shを用いて自動生成されたＪＡＶＡで記述されたＡＰＩを例示した図である。図３、図４と図２を比較して明らかなように、ＪＡＸＢのスキーマコンパイラによって自動生成されるＪＡＶＡのクラスの入れ子構造は、その基となるスキーマの入れ子構造と対応関係がある。構造化文書のデータを読み込む処理やＪＡＶＡのクラスに格納されたデータを構造化文書としてファイルに書き出す処理を行うアプリケーションは、自動生成されたＪＡＶＡのＡＰＩを利用することによりアンマーシャルやマーシャルを行うことができる。なお、ＪＡＸＢは、アンマーシャル、マーシャルの処理をする際に、スキーマと構造化文書の妥当性を検証する機能も有している。

データバインディングツールは、例えば、グラフィカルユーザーインターフェースを備えたプログラム開発において利用することができる。例えば、グラフィカルユーザーインターフェースの画面を構造化文書として記述し、構造化文書をＪＡＸＢやRelaxerなどのスキーマコンパイラを用いることによりプログラムの基本部分を自動生成できるようになる。

上記のように、データバインディングツールを用いた開発は、ＤＯＭやＳＡＸを用いてプログラムを実装する場合に比べて、プログラム開発者が直接コーディングするコードが短くなり、アプリケーションの開発効率を上げることが可能となる。また、上記のように、ＪＡＸＢコンパイラによって生成されるＪＡＶＡのＡＰＩに係るプログラムとアプリケーション共通のライブラリとを用いることによりを用いることによりＸＭＬ文書をＪＡＶＡのクラスに変換(マッピング)する。このため、ＪＡＶＡのアプリケーションはＸＭＬの文書構造を知らなくてもＸＭＬのデータをアプリケーションにおいて利用することができる。
特開２００３−２０３０６７号公報

しかし、ＪＡＸＢやRelaxerなど既存のデータバインディングツールは、スキーマ文書をもとにＪＡＶＡのＡＰＩに係るプログラムを自動生成する。このため、ＡＰＩを用いてアンマーシャルやマーシャル処理するアプリケーションにとって不要なデータを処理するためのプログラムがＡＰＩに含まれる場合がある。このような不要なＡＰＩに係るプログラムには、使用しないデータを処理するためのＪＡＶＡクラスや変数、メソッド等のソースコードが含まれる。

また、ＡＰＩをリソースの限られた機器のアプリケーションにおいて使用する場合、アプリケーションにとって不要なデータを操作するプログラムを含むため、多くの記憶容量を必要としてしまう。また、アプリケーションにおいてマーシャルやアンマーシャルする際に、不要なＪＡＶＡのクラスをインスタンス化してしまうことによってＣＰＵの多くの処理時間を必要としてしまう。

本発明は上記問題に鑑みなされたものであり、アプリケーションが低コストで構造化文書へアクセスすることを可能にする技術を提供することを目的とする。

上記目的を達成するため、本発明の一態様による情報処理装置は、第１の構造化文書に基づいて、複数の要素オブジェクトがツリー構造をなす第１のオブジェクトモデルを生成する第１のモデル生成手段と、前記第１の構造化文書の文書構造を定義する第２の構造化文書に基づいて、複数の要素オブジェクトがツリー構造をなす第２のオブジェクトモデルを生成する第２のモデル生成手段と、前記第１のオブジェクトモデルを用いて、前記第２のオブジェクトモデルを再構成する再構成手段と、前記再構成手段により再構成された前記第２のオブジェクトモデルにおける要素オブジェクトの親子関係に従ったクラス構造でクラスファイルを生成するファイル生成手段とを備え、前記再構成手段は、前記第２のオブジェクトモデルを構成する要素オブジェクトそれぞれについて、前記第１のオブジェクトモデルに含まれる要素オブジェクトであるか否かを判定する判定手段と、前記判定手段により前記第２のオブジェクトモデルを構成する要素オブジェクトのうち、前記第１のオブジェクトモデルに含まれる要素オブジェクトでないと判定された要素オブジェクトと、前記第２のオブジェクトモデルのツリー構造において当該要素オブジェクトよりも下位の要素オブジェクトとを削除する削除手段とを備える

本発明によれば、アプリケーションが低コストで構造化文書へアクセスすることを可能にする技術を提供することができる。

以下、添付図面を参照して本発明に係る実施の形態を詳細に説明する。ただし、この実施の形態に記載されている構成要素はあくまでも例示であり、本発明の範囲をそれらのみに限定する趣旨のものではない。

（システム構成）
図５は本実施形態に係る情報処理装置を含むシステムの概要を例示したブロック図である。図５において、スキャナ１０１は、ネットワーク１０２に接続されている。ネットワーク１０２には、携帯機器１０３、クライアントとしてのＰＣ１０４、ネットワークプリンタ１０５、ファイルサーバ１０６が接続されている。

携帯機器１０３は、本実施形態に係る情報処理装置として機能する装置であり、ＰＤＡやデジタルカメラ、携帯電話、ＰＨＳ等により実現される。

スキャナ１０１は、文書を光学的に読み取り画像データを生成する装置である。ＰＣ１０４は、デスクトップＰＣ、ノートブックＰＣ等のコンピュータ装置である。ネットワークプリンタ１０５は、ネットワーク１０２を経由して入力された画像データに基づいて、所定の記録媒体（記録用紙）に画像を形成する装置である。ファイルサーバ１０６は、ファイルを記憶する記憶装置を有し、ネットワーク１０２を介してファイルの入出力や、記憶装置に記憶されたファイルの管理等を行う。

ネットワーク１０２は、典型的には、インターネットであるが、有線／無線を問わず、公衆回線（アナログ回線、ＩＳＤＮ等）やＬＡＮ、ＷＡＮ、無線ＬＡＮ等のデータ送受信可能な回線であれば、どのような構成でもよい。ネットワークを用いた通信プロトコルは、例えば、ＴＣＰ／ＩＰ等を採用することができる。

以下、携帯機器１０３において、ＸＭＬにより記述された画像（ベクターグラフィックス）を表示するアプリケーションを実行する場合について例示的に説明するが、アプリケーションはこれに限られない。また、処理を実行する装置は携帯機器１０３に限られず、例えば、汎用のＰＣやＷＳ等においても実行可能であることは言うまでもない。

（携帯機器１０３の構成）
次に、携帯機器１０３の構成について図６を参照して説明する。図６は図５に例示したシステムにおける、携帯機器１０３の構成を示したブロック図である。

図６において、ＣＰＵ２０１はシステム制御部であり、装置全体の動作を制御する。

ＲＯＭ２０２は、ＣＰＵの制御プログラムや各種固定データを格納する読み出し専用のメモリ装置である。ＲＡＭ２０３は、ＳＲＡＭ、ＤＲＡＭなどで構成され、プログラム制御変数などを格納する書き込み可能なメモリ装置である。また、各種設定パラメータ、各種ワーク用バッファもＲＡＭ２０３に格納されている。

記憶部２０４はハードディスク等で構成される記憶装置であり、文書や画像などのスキャン画像等を格納する。操作パネル２０５はキーボード、タッチパネルなどで構成され、オペレータが各種入力操作を行うために利用される。表示部２０６は、ＬＣＤ、ＬＥＤなどでオペレータに表示通知するディスプレイとして機能する。

ＬＡＮＩ／Ｆ２０７及びＬＡＮＩ／Ｆ２０９は所定のネットワークに接続するためのネットワークインタフェースである。即ち、ＬＡＮＩ／Ｆ２０７は、ＬＡＮ回線２０８に接続するためのインターフェースである。無線ＬＡＮＩ／Ｆ２０９は無線ＬＡＮ回線２１０に接続するためのインターフェースである。

尚、以上の各装置と同等の機能を実現するソフトウェアにより、ハードウェア装置の代替として構成することもできる。

本実施形態では、本実施形態に係るプログラムを動作させる度に、既にプログラムがインストールされている記憶部２０４からＲＡＭ２０３にロードして実行する例を示すがこれに限られない。例えば、所定のメディア（不図示）から本実施形態に係るプログラム及び関連データを直接ＲＡＭ２０３にロードして実行させてもよい。或いは、本実施形態に係るプログラムをＲＯＭ２０２に記録しておき、これをメモリマップの一部をなすように構成し、直接ＣＰＵ２０１で実行することも可能である。

また、本実施形態では、説明の便宜のため、本実施形態に係る情報処理装置（携帯機器１０３）を１つの装置で実現した構成について述べるが、複数の装置にリソースを分散した構成によって実現してもよい。例えば、記憶や演算のリソースを複数の装置に分散した形に構成してもよい。或いは、情報処理装置上で仮想的に実現される構成要素毎にリソースを分散し、並列処理を行うようにしてもよい。

（シナリオ）
例えば、リソースの限られている携帯機器１０３上にベクターグラフィックスを表示する場合、その表示処理においてはＸＭＬのヘッダ情報（例えば、図１の１１１）が不要な場合がある。また、ベクターグラフィックスに高画質の画像が含まれる際、携帯機器のアプリケーションが容量の重い画像データを読み込まないようにすることによってアプリケーションの処理速度が向上する場合が考えられる。後述するように、本実施形態に係る構成は、このような処理が不要なＸＭＬの箇所について処理を行わないように制御する。

本実施形態では、図１の構造化文書に含まれるベクターグラフィックスとしてＳＶＧを用いる。また、構造化文書に含まれるデータのうちベクターグラフィックスに対応する箇所に基づいて、携帯機器１０３の表示部２０６に画像を表示する。図７（ａ）は、構造化文書のベクターグラフィックスに対応する箇所に基づいて表示した画像を例示した図である。図７（ｂ）は、ヘッダ情報等の、携帯機器１０３が画像を表示する際に参照する必要のない部分を除いた、図７（ａ）の画像例に対応する構造化文書の一例であるＸＭＬを例示した図である。図７と図１を比較して明らかなように、図７は、図１におけるデータのうち文字とイメージオブジェクトを携帯機器１０３表示し、ヘッダ情報とベクターグラフィックスにおける図形オブジェクトは表示しない場合を例示している。尚、イメージオブジェクトが高画質で容量が大きい際には、ヘッダ情報と同様に、イメージオブジェクトを読み込まないようにすることもできる。

図８は、図７の構造化文書を携帯機器１０３のアプリケーションに読み込むために利用するＪＡＶＡのＡＰＩの生成する際のコマンドを例示した図である。図８は、図２のスキーマ文書（"schema.xsd"）と図７のベクターグラフィックスを含む構造化文書（"graphics.xml"）を入力としてコンパイルする場合を例示している。図８に示すように、生成するＪＡＶＡのＡＰＩのパッケージ名をコンパイルオプション-pでtest.jaxbとしている。また、コンパイルオプション-dにより、生成するＪＡＶＡのＡＰＩをカレントディレクトリに生成する。スキーマ文書のファイルにはコンパイルオプションとして-schemaを付け、構造化文書のファイルにはコンパイルオプションとして-xmlを付けることによりＪＡＶＡのＡＰＩを生成するものとする。なお、このようなコマンドの規約は一例であり、これに限られないことは明らかである。また、グラフィカルインタフェースを用いてコンパイルに係る指定を受け付けるように構成してもよい。

なお、本実施形態においては、スキーマ文書はそれ自体が構造化文書となっている。即ち、本実施形態では、XML Schemaによりスキーマ文書を記述するが、XML Schema文書はＸＭＬにより記述される。

（ＡＰＩ生成処理）
次に、スキーマ文書と構造化文書からＪＡＶＡのＡＰＩを生成する処理について図９、１０、１１を参照して説明する。図９はＪＡＶＡのＡＰＩを生成する処理の全体の手順を示したフローチャートである。図１０は、図９のステップＳ１０６において実行するＤＯＭ再構成処理の詳細な手順を示したフローチャートである。図１１は図９のステップＳ１０７において実行するＪＡＶＡクラス生成処理の詳細な手順を示したフローチャートである。以下、説明を容易にするために、図８のコンパイルコマンドを実行し、図２に例示したスキーマ文書（"schema.xsd"）と、図７に例示したＸＭＬ文書（"graphics.xml"）に基づいて処理を行う場合を例示的に説明する。

ステップＳ１０１において処理を開始すると、まず、コンパイル時に指定されたスキーマ文書を内部メモリに格納する（ステップＳ１０２）。内部メモリとしては例えばＲＡＭ２０３や記憶部２０４等を使用することができる。次に、ステップＳ１０２と同様に、コンパイル時に指定された構造化文書を内部メモリに格納する（ステップＳ１０３）。

次に、ステップＳ１０４において、スキーマ文書に基づいてＤＯＭを生成する。図１２は図２のスキーマ文書に基づいて生成されたＤＯＭを例示した模式図である。図１２のように、ＤＯＭは要素、内容モデル、属性からなるツリー構造を構成する。例えば、要素オブジェクト（ノード）１２０１は、図２における要素２１１に対応する。同様に、１２０２〜１２１０は２１２〜２２０にそれぞれ対応する。

次に、ステップＳ１０５において、ステップＳ１０４と同様に、構造化文書に基づいてＤＯＭを生成する。図１３は、図７のＸＭＬ文書に基づいて生成されたＤＯＭを例示した模式図である。例えば、要素オブジェクト１３０１は図７（ｂ）の７０１に対応する。同様に、１３０２〜１３０４は７０２〜７０４にそれぞれ対応する。なお、ステップＳ１０４、Ｓ１０５の処理は公知技術を用いて実行することができる。また、生成したＤＯＭに対応するデータはＲＡＭ２０３等に記憶する。

次に、構造化文書をもとに生成されたＤＯＭを用いて、スキーマ文書をもとに生成したＤＯＭを再構成する、ＤＯＭ再構成処理を実行する（ステップＳ１０６）。この処理の詳細について、図１０を参照して説明する。

ＤＯＭ再構成処理を開始すると（ステップＳ２０１）、まず、スキーマ文書のＤＯＭを構成する要素オブジェクトのそれぞれについて、構造化文書のＤＯＭに含まれる要素オブジェクトであるかどうか判定する（ステップＳ２０２）。ただし、この判定は、スキーマ文書のＤＯＭツリーにおいて、最上位ノードから子ノードを辿って順に行う。もし構造化文書のＤＯＭに含まれる要素オブジェクトならば（ステップＳ２０２でＹＥＳ）、ステップＳ２０４において、その要素オブジェクトにフラグ１を付与する。即ち、その要素オブジェクトに関連づけてフラグ１を記憶制御する。構造化文書のＤＯＭに含まれない要素オブジェクトならば（ステップＳ２０２でＮＯ）、要素オブジェクト以下の要素オブジェクトに０を付与する、即ち、その要素オブジェクトに関連づけてフラグ０を記憶制御する（ステップＳ２０３）。

図１４は、図１３の構造化文書のＤＯＭをもとに各オブジェクトにフラグが付与された、図１２のスキーマ文書に対応するＤＯＭを示した模式図である。例えば、スキーマ文書の要素オブジェクト"picture"１２０１については、構造化文書に要素オブジェクト"picture"１３０１が存在するため、フラグ１が付与されている。これに対して、例えば、スキーマ文書の要素オブジェクト"header"１２０２は、これに対応する要素オブジェクトが構造化文書に存在しないため、フラグ０が付与されている。そして、フラグ０が付与された要素オブジェクト"header"１２０２以下の要素オブジェクト"date date型"１２０３、"author string型"１２０４にもフラグ０が付与されている。

次に、スキーマ文書のＤＯＭの要素オブジェクトのそれぞれについてフラグか０であるかどうか判定する（ステップＳ２０５）。もしフラグが０ならば（ステップＳ２０５でＹＥＳ）、ＤＯＭからそのオブジェクト以下のノードを全て削除する（ステップＳ２０６）。即ち、ＲＡＭ２０３等の記憶装置から、フラグ０が付与された要素オブジェクト、及び、そのオブジェクト以下の要素オブジェクトに係るデータを削除する。

図１５は、ステップＳ２０５の処理の結果、図１４に例示したＤＯＭから、フラグ０が付与された要素オブジェクトが削除された、即ち、ＸＭＬ文書に基づいて再構成されたスキーマ文書のＤＯＭを例示した模式図である。

図９の説明に戻る。ステップＳ１０６のＤＯＭ再構成処理を終了すると、ステップＳ１０７において、ステップＳ１０６で再構成されたスキーマ文書のＤＯＭに含まれるオブジェクトの親子関係をもとにＪＡＶＡのクラスを生成するＪＡＶＡクラス生成処理を実行する。ＪＡＶＡクラス生成処理の詳細について図１１を参照して説明する。

ＪＡＶＡクラス生成処理を開始すると（ステップＳ３０１）、ステップＳ３０２へ進む。ステップＳ３０２では、schema要素のオブジェクトを除くＤＯＭの各オブジェクトについて、最上位オブジェクト、即ち、schemaオブジェクトの第一子要素のオブジェクトであるかどうか判定する。図１５の例では、"picture"オブジェクト１５０１がschemaオブジェクトの第一子要素のオブジェクトに該当する。１５０２〜１５０４オブジェクト等はschemaオブジェクトの第一子要素のオブジェクトに該当しない。

ステップＳ３０２において、schemaの第一子要素のオブジェクトならば（ステップＳ３０２でＹＥＳ）オブジェクトの要素名であるＪＡＶＡのルートクラスを生成する（ステップＳ３０４）。もしschemaの第一子要素のオブジェクトではないならば（ステップＳ３０２でＮＯ）、親要素のクラスのインナークラスとなるようにＪＡＶＡのクラスを生成する（ステップＳ３０３）。このようにしてＪＡＶＡクラスを生成することで、ＪＡＶＡのＡＰＩのクラス構造は、スキーマ文書のＤＯＭにおける要素オブジェクトの親子関係と同じ構造になる。なお、クラスの生成はオブジェクトに付随する内容モデル、属性等に基づいて決定されるが、その処理は公知技術を用いて実行することができる。

図９の説明に戻る。次に、ステップＳ１０８で生成されたＪＡＶＡのクラスをファイルに書き出す（ステップＳ１０８）。

以上のように、本実施形態に係る構成においては、アプリケーションに不要な構造化文書のデータを扱うプログラムを含まないＪＡＶＡのＡＰＩを生成することができる。なお、本実施形態においては、コンパイル時に指定する構造化文書は１つであるが、複数の構造化文書を指定する場合も考えられ、その際には複数の構造化文書をデータバインディング可能であるプログラムを生成することができる。ただし、複数の構造化文書を指定する場合は、ＤＯＭ再構成処理（ステップＳ１０６）のステップＳ２０２において、スキーマ文書の要素オブジェクトが指定された複数の構造化文書に対応する複数のＤＯＭのいずれかに含まれるか否かを判定する。即ち、複数のＤＯＭのいずれかに含まれる場合はステップＳ２０４へ進み、いずれにも含まれない場合はステップＳ２０３へ進むように処理を行う。これにより、複数の構造化文書をデータバインディング可能であるプログラムを生成することができる。なお、スキーマ文書の属性オブジェクトにおいても同様のＤＯＭ再構成処理を行う場合がある。例えば、スキーマ文書において、ある属性に関するスキーマの記述は必要ないと判断した場合は、ＤＯＭの木構造から、その属性に関するスキーマの記述を削除するようにしてもよい。

（ＡＰＩの例）
図１６は本実施形態に係る構成による処理により生成されたＡＰＩを例示した図である。ＡＰＩにはコンパイル時に指定された構造化文書に含まれるデータを扱うプログラムのみが含まれる。即ち、ヘッダ情報とベクターグラフィックスに含まれる円と矩形の図形を扱うクラスが削除されたＡＰＩとなっている。そして、携帯機器１０３は図１６のＡＰＩを利用することによりデータバインディング可能となる。

既存のＪＡＸＢコンパイラを用いて図２のスキーマ文書だけからＪＡＶＡのＡＰＩを作成すると、不要な構造化文書のデータを扱うクラスを生成してしまう。これに対し、上記の手法を用いると不要な構造化文書のデータを扱うクラスを生成することなく必要なクラスのみを生成することができる。このため、このようなクラスを用いてデータバインディング可能となり、限られたリソースを持つ携帯機器などにおいてリソースを無駄な処理に割り当てることなく、効率的に処理を実行することができる。

なお、上記の構成では、サンプルとなる構造化文書（図７（ｂ））に基づいて、ステップＳ１０６においてスキーマ文書を再構成する処理を行っているが、これに限られない。例えば、スキーマ文書からＪＡＶＡのＡＰＩを生成する処理を開始するユーザの指示入力において、クラスを生成しないノードの指定を受け付け、この指定に基づいてＤＯＭ再構成処理（ステップＳ１０６）におけるノードの削除を制御するようにしてもよい。

クラスを生成しないノードの指定の受け付けは、例えば、コマンドラインにおいてクラスを生成しない箇所をＸＰａｔｈ形式等により指定可能にすることができる。図１７は、コマンドラインにおいてクラスを生成しない箇所が指定されている様子を例示する図である。図１７では、コンパイルオプション"-remove"でクラスを生成しない箇所"schema/picture/complexType/sequence/header"、"schema/picture/complexType/sequence/svg/complexType/sequence/g"が指定されている。このような指定がなされた場合、本実施形態に係る構成は、図１のフローチャートにおいて、ステップＳ１０３、Ｓ１０５の処理を省略する。また、図１０（ステップＳ１０６）のＪＡＶＡクラス生成処理のステップＳ２０２〜Ｓ２０４において、クラスを生成しない箇所として指定されている箇所にフラグ０を、それ以外の箇所にフラグ１を付与するように処理する。これにより、指定された箇所に対応するクラスを生成しないでクラスファイルを生成することができる。図１７の例では、"schema/picture/complexType/sequence/header"、"schema/picture/complexType/sequence/svg/complexType/sequence/g"が指定されているため、図１４のようにフラグが付与される。このため、図１７の例のコマンドを実行すると、ＤＯＭツリーは図１５のように再構成され、最終的に図１６のようなクラスファイルが生成される。

また、本実施形態に係る構成により生成されたＡＰＩを用いることで、アンマーシャル、マーシャル時に、構造化文書中の不要なデータをＪＡＶＡのクラスに読み込まないようにすることができる。このため、不要なオブジェクトのインスタンス化が必要なくなり、アプリケーションの処理時間や記憶容量を削減することができる。

なお、クラスを生成しないノードの指定の受け付けはコマンドラインによるものに限られない。例えば、スキーマ文書をツリー構造で模式的に表示し、このツリー構造において、クラスを生成しない箇所を選択可能に制御することにより、指定を受け付けるようにしてもよい。

また、上記では、ＸＭＬを使用するプログラムはＪＡＶＡにより記述されているものとしたが、使用するプログラミング言語はＪＡＶＡに限られないことは明らかである。例えば、はＣ言語、Ｃ＋＋言語等を用いる場合においても同様の構成が適用可能である。

また、上記では、ＤＯＭの再構成として、所定の条件に基づいてＤＯＭのノードを削除する構成について述べたがこれに限られない。例えば、基準となるＤＯＭや、ユーザからの指示入力に基づいて、スキーマ文書又は構造化文書に対応するＤＯＭのツリー構造を変更したり、新たなノードを追加して、クラスファイルを生成するように構成してもよい。例えば、指示入力に基づいて、或いは、基準となるＤＯＭと同じ構造になるように、あるノードの子ノードを別のノードの子ノードとなるように再配置するように構成することができる。

また、上記ではスキーマ文書をXML Schemeにより記述した例を示したが、スキーマ言語はXML Schemeに限られないことは言うまでもない。例えば、スキーマ文書をRELAX NGや、或いは、ＸＭＬにより記述してもよい。

＜＜その他の実施形態＞＞
以上、本発明の実施形態例について詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様を取ることが可能である。具体的には、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。

尚、本発明は、前述した実施形態の機能を実現するプログラムを、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。

従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明の技術的範囲に含まれる。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含む。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。

プログラムを供給するための記録媒体としては、例えば、次のものが含まれる。即ち、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）等が含まれる。

その他、プログラムの供給形態としては、次のようなものも考えられる。即ち、クライアント装置のブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明に係るコンピュータプログラム、或いは、圧縮され自動インストール機能を含むファイルをＨＤ等の記録媒体にダウンロードする形態も考えられる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

また、次のような供給形態も考えられる。即ち、まず、本発明に係るプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布する。そして、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報の使用により暗号化されたプログラムを実行してコンピュータにインストールさせて本発明に係る構成を実現する。このような供給形態も可能である。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他次のような実現形態も想定される。即ち、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づいても前述した実施形態の機能が実現される。即ち、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現される。

構造化文書と構造化文書に対応するベクターグラフィックスを例示した図である。スキーマ文書の例を示した図である。自動生成されたＪＡＶＡで記述されたＡＰＩを例示した図である。自動生成されたＪＡＶＡで記述されたＡＰＩを例示した図である。本実施形態に係る情報処理装置を含むシステムの概要を例示したブロック図である。携帯機器の構成を示したブロック図である。構造化文書と構造化文書に対応するベクターグラフィックスを例示した図である。ＪＡＶＡのＡＰＩの生成する際のコマンドを例示した図である。ＪＡＶＡのＡＰＩを生成する処理の全体の手順を示したフローチャートである。ＤＯＭ再構成処理の詳細な手順を示したフローチャートである。ＪＡＶＡクラス生成処理の詳細な手順を示したフローチャートである。スキーマ文書に基づいて生成されたＤＯＭを例示した模式図である。構造化文書に基づいて生成されたＤＯＭを例示した模式図である。各オブジェクトにフラグが付与された、スキーマ文書に対応するＤＯＭを例示した模式図である。ＸＭＬ文書に基づいて再構成されたスキーマ文書のＤＯＭを例示した模式図である。本実施形態に係る構成による処理により生成されたＡＰＩを例示した図である。コマンドラインにおいてクラスを生成しない箇所が指定されている様子を例示する図である。

Claims

第１の構造化文書に基づいて、複数の要素オブジェクトがツリー構造をなす第１のオブジェクトモデルを生成する第１のモデル生成手段と、
前記第１の構造化文書の文書構造を定義する第２の構造化文書に基づいて、複数の要素オブジェクトがツリー構造をなす第２のオブジェクトモデルを生成する第２のモデル生成手段と、
前記第１のオブジェクトモデルを用いて、前記第２のオブジェクトモデルを再構成する再構成手段と、
前記再構成手段により再構成された前記第２のオブジェクトモデルにおける要素オブジェクトの親子関係に従ったクラス構造でクラスファイルを生成するファイル生成手段と
を備え、
前記再構成手段は、
前記第２のオブジェクトモデルを構成する要素オブジェクトそれぞれについて、前記第１のオブジェクトモデルに含まれる要素オブジェクトであるか否かを判定する判定手段と、
前記判定手段により前記第２のオブジェクトモデルを構成する要素オブジェクトのうち、前記第１のオブジェクトモデルに含まれる要素オブジェクトでないと判定された要素オブジェクトと、前記第２のオブジェクトモデルのツリー構造において当該要素オブジェクトよりも下位の要素オブジェクトとを削除する削除手段と
を備えることを特徴とする情報処理装置。
前記第１のオブジェクトモデル及び前記第２のオブジェクトモデルにおけるツリー構造及び要素オブジェクトに対するユーザからの変更指示を入力する指示入力手段
を更に備え、
前記再構成手段は、
前記指示入力手段からの変更指示に基づく変更が行なわれた前記第１のオブジェクトモデル及び前記第２のオブジェクトモデルに基づいて前記再構成を行なう
ことを特徴とする請求項１記載の情報処理装置。
前記第１のモデル生成手段は、
複数の前記第１の構造化文書に基づいて、複数の要素オブジェクトがツリー構造をなす前記第１のオブジェクトモデルを生成する
ことを特徴とする請求項１又は２記載の情報処理装置。
前記第２の構造化文書は、ＸＭＬ、XML Schema、RELAX NGのいずれかにより記述される
ことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
前記クラスファイルは、ＪＡＶＡ（登録商標）、Ｃ言語、Ｃ＋＋言語のいずれかにより記述される
ことを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
前記第１及び第２のオブジェクトモデルはドキュメント・オブジェクト・モデル形式のデータである
ことを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
前記第２の構造化文書は文書のスキーマを示すスキーマ文書である
ことを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
情報処理装置の制御方法であって、
第１のモデル生成手段が、第１の構造化文書に基づいて、複数の要素オブジェクトがツリー構造をなす第１のオブジェクトモデルを生成する工程と、
第２のモデル生成手段が、前記第１の構造化文書の文書構造を定義する第２の構造化文書に基づいて、複数の要素オブジェクトがツリー構造をなす第２のオブジェクトモデルを生成する工程と、
再構成手段が、前記第１のオブジェクトモデルを用いて、前記第２のオブジェクトモデルを再構成する工程と、
ファイル生成手段が、前記再構成手段により再構成された前記第２のオブジェクトモデルにおける要素オブジェクトの親子関係に従ったクラス構造でクラスファイルを生成する工程と
を備え、
前記再構成手段は、
判定手段が、前記第２のオブジェクトモデルを構成する要素オブジェクトそれぞれについて、前記第１のオブジェクトモデルに含まれる要素オブジェクトであるか否かを判定する工程と、
削除手段が、前記判定手段により前記第２のオブジェクトモデルを構成する要素オブジェクトのうち、前記第１のオブジェクトモデルに含まれる要素オブジェクトでないと判定された要素オブジェクトと、前記第２のオブジェクトモデルのツリー構造において当該要素オブジェクトよりも下位の要素オブジェクトとを削除する工程と
を備えることを特徴とする情報処理装置の制御方法。
コンピュータを請求項１乃至７のいずれかに記載の情報処理装置として機能させるためのコンピュータプログラム。
請求項９に記載のコンピュータプログラムを格納したコンピュータで読み取り可能な記憶媒体。