(57)【特許請求の範囲】
【請求項１】
単一のスキーマデータを利用して構造化文書データの妥当性を検証する文書検証装置であって、
第１のバージョンのスキーマに対応するスキーマデータと、前記第１のバージョンのスキーマと第２のバージョンのスキーマとの差分情報と、前記差分情報に対応するバージョン情報と、が記述されている単一のスキーマデータを保持する保持手段と、
構造化文書データを入力する入力手段と、
前記単一のスキーマデータを用いて、スキーマのＤＯＭツリーを生成する第１の生成手段と、
前記構造化文書データに含まれている該構造化文書データのバージョンを示すバージョン情報に応じて、前記第１の生成手段で生成されたＤＯＭツリーと前記スキーマデータに記述されているバージョン情報と該バージョン情報に対応する前記差分情報とを用いて、前記構造化文書データに対応するスキーマのＤＯＭツリーを生成する第２の生成手段と、
前記第２の生成手段で生成されたＤＯＭツリーに基づいて前記構造化文書データの妥当性検証を行う検証手段と、
を備えることを特徴とする文書検証装置。
【請求項２】
前記第１の生成手段は、前記単一のスキーマデータに含まれる全要素のＤＯＭツリーを生成する全要素ツリー生成手段を含み、
前記第２の生成手段は、前記構造化文書データに含まれているバージョン情報に応じて、該構造化文書データの妥当性検証に不要な要素を前記第１の生成手段で生成されたＤＯＭツリーから削除する要素削除手段を含む
ことを特徴とする請求項１に記載の文書検証装置。
【請求項３】
前記要素削除手段は、前記単一のスキーマデータの要素に付された相違種別に応じて、該相違種別と共に付されたバージョンを示す情報と前記構造化文書データに含まれているバージョン情報とに基づいて、不要な要素を前記第１の生成手段で生成されたＤＯＭツリーから削除することを特徴とする請求項２に記載の文書検証装置。
【請求項４】
前記第２の生成手段は、前記単一のスキーマデータに含まれる要素に付された相違種別とバージョンを示す情報とを逐次解析することにより、前記構造化文書データに含まれているバージョン情報に基づくＤＯＭツリーを生成することを特徴とする請求項１に記載の文書検証装置。
【請求項５】
前記相違種別は、要素の追加、要素の削除、要素の名前の変更、要素内容のデータ型の変更の何れかであることを特徴とする請求項３又は４に記載の文書検証装置。
【請求項６】
前記相違種別は、属性の追加、属性の削除、属性の名前の変更、属性値のデータ型の変更の何れかであることを特徴とする請求項３又は４に記載の文書検証装置。
【請求項７】
単一のスキーマデータを利用して構造化文書データの妥当性を検証する文書検証装置の制御方法であって、
第１のバージョンのスキーマに対応するスキーマデータと、前記第１のバージョンのスキーマと第２のバージョンのスキーマとの差分情報と、前記差分情報に対応するバージョン情報と、が記述されている単一のスキーマデータを記憶部に保持する保持工程と、
構造化文書データを入力する入力工程と、
前記単一のスキーマデータを用いて、スキーマのＤＯＭツリーを生成する第１の生成工程と、
前記構造化文書データに含まれている該構造化文書データのバージョンを示すバージョン情報に応じて、前記第１の生成工程で生成されたＤＯＭツリーと前記スキーマデータに記述されているバージョン情報と該バージョン情報に対応する前記差分情報とを用いて、前記構造化文書データに対応するスキーマのＤＯＭツリーを生成する第２の生成工程と、
前記第２の生成工程で生成されたＤＯＭツリーに基づいて前記構造化文書データの妥当性検証を行う検証工程と、
を含むことを特徴とする文書検証装置の制御方法。
【請求項８】
コンピュータを、請求項１乃至６の何れか１項に記載の文書検証装置の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、構造化文書の妥当性（バリデーション）検証技術に関するものである。
【背景技術】
【０００２】
ドキュメントファイルやプログラムのソースコードのバージョンを管理するツールとしてＣＶＳ（Concurrent Versions System）（ｈｔｔｐ：／／ｗｗｗ．ｃｖｓｈｏｍｅ．ｏｒｇ／）があった。これは、前のバージョンのファイルと行単位で追加や削除したデータを解析することによって、バージョン管理しているファイルに前のバージョンとの差分情報を追加していくものである。ユーザがあるバージョン番号のデータが欲しい場合には、そのバージョン番号をＣＶＳサーバに対して指定する。すると、ＣＶＳサーバは、バージョン管理しているファイルを解析することによって、そのバージョン番号に応じたデータを抜き出す。そのように動作することによって、ユーザは指定したバージョンのファイルを取得することができる。バージョンの指定方法はバージョン番号だけでなく、そのファイルを編集した日付でも指定することができる。また、１つのファイルを複数のユーザで編集した場合でもバージョン管理することが可能であり、ネットワーク通信可能なパーソナルコンピュータ（ＰＣ）を用いたドキュメントファイルの共同編集に利用されている。
【０００３】
一方、近年、タグを付けることによってデータを構造的に記述するデータ形式として、構造化文書が注目されている。代表的な構造化文書の規格としてはWorld Wide Web Consortium(W3C)で策定されたExtensible Markup Language (XML) 1.0（ＸＭＬ）やExtensible HyperText Markup Language（ＸＨＴＭＬ）が挙げられる。アプリケーションがタグ付けされた構造化文書のデータを解析する場合には、一般的にＸＭＬパーサを用いて解析する。
【０００４】
このような構造化文書をバージョン管理する技術として、特許文献１には、編集した要素ごとにその編集した時刻を値とする属性をつけることによって、各要素を編集した時刻を管理するものがあった。
【０００５】
また、構造化文書のデータ構造や、要素内容、属性値のデータ型を定義したスキーマを用いることによって、構造化文書がそのスキーマを満たしているかどうか検証するソフトウェアとしてスキーマプロセッサがある。扱う構造化文書をスキーマに対して検証する必要のあるアプリケーションでは、アプリケーションのバージョンアップに伴なって、新たにスキーマファイルを作成する。そのため、扱う構造化文書のデータ構造やデータ型に変更があった場合には、新たにスキーマファイルを作成することによって、バージョンアップした構造化文書の妥当性を検証していた。
【特許文献１】特開平０７−２００３７０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、例えば、バージョンアップを重ねてきたアプリケーションが前のバージョンのアプリケーションで生成されたデータを扱う場合、バージョンに応じたスキーマファイルを用いて検証する必要があった。つまり、従来のスキーマプロセッサを用いて妥当性検証を行うためには、アプリケーションの各バージョンで使用される構造化文書に対するスキーマファイルを保持する必要があった。
【０００７】
例えば、住所録を記述した構造化文書について説明する。図１に示されるバージョン０．１の構造化文書では、個人に割り当てられたＩＤナンバーと名前と住所のデータを記述している。この場合の、バージョン０．１の住所録のスキーマは図２のように表される。なお、これは国際標準化機構（ＩＳＯ）で策定されたスキーマ言語であるＲＥＬＡＸ  ＮＧを用いて記述したものである。
【０００８】
次に、バージョン０．２の構造化文書では、バージョン０．１に対して電話番号に対応するｐｈｏｎｅ要素が追加されたとする。その場合、例えば、構造化文書は図３のように表され、スキーマは図４のように表される。つまり、追加された要素が電話番号（ｐｈｏｎｅ要素）のみであるのにもかかわらず、重複したデータを含んだｖｅｒ０．１とｖｅｒ０．２の２つのスキーマのファイル（スキーマデータ）をそれぞれハードディスクに保存しておかなければならない。
【課題を解決するための手段】
【００１０】
上述の問題点の１つ以上を解決するため、本発明の文書検証装置は以下の構成を備える。すなわち、単一のスキーマデータを利用して構造化文書データの妥当性を検証する文書検証装置において、第１のバージョンのスキーマに対応するスキーマデータと、前記第１のバージョンのスキーマと第２のバージョンのスキーマとの差分情報と、前記差分情報に対応するバージョン情報と、が記述されている単一のスキーマデータを保持する保持手段と、構造化文書データを入力する入力手段と、前記単一のスキーマデータを用いて、スキーマのＤＯＭツリーを生成する第１の生成手段と、前記構造化文書データに含まれている該構造化文書データのバージョンを示すバージョン情報に応じて、前記第１の生成手段で生成されたＤＯＭツリーと前記スキーマデータに記述されているバージョン情報と該バージョン情報に対応する前記差分情報とを用いて、前記構造化文書データに対応するスキーマのＤＯＭツリーを生成する第２の生成手段と、前記第２の生成手段で生成されたＤＯＭツリーに基づいて前記構造化文書データの妥当性検証を行う検証手段と、を備える。
【００１２】
上述の問題点の１つ以上を解決するため、本発明の文書検証装置の制御方法は以下の構成を備える。すなわち、単一のスキーマデータを利用して構造化文書データの妥当性を検証する文書検証装置の制御方法において、第１のバージョンのスキーマに対応するスキーマデータと、前記第１のバージョンのスキーマと第２のバージョンのスキーマとの差分情報と、前記差分情報に対応するバージョン情報と、が記述されている単一のスキーマデータを記憶部に保持する保持工程と、構造化文書データを入力する入力工程と、前記単一のスキーマデータを用いて、スキーマのＤＯＭツリーを生成する第１の生成工程と、前記構造化文書データに含まれている該構造化文書データのバージョンを示すバージョン情報に応じて、前記第１の生成工程で生成されたＤＯＭツリーと前記スキーマデータに記述されているバージョン情報と該バージョン情報に対応する前記差分情報とを用いて、前記構造化文書データに対応するスキーマのＤＯＭツリーを生成する第２の生成工程と、前記第２の生成工程で生成されたＤＯＭツリーに基づいて前記構造化文書データの妥当性検証を行う検証工程と、を含む。
【発明の効果】
【００１３】
本発明によれば、異なるバージョンの構造化文書に対応するスキーマデータを用い、構造化文書の妥当性を効率的に検証可能とする技術を提供することが出来る。
【発明を実施するための最良の形態】
【００１４】
以下に、図面を参照して、この発明の好適な実施の形態を詳しく説明する。なお、以下の実施の形態はあくまで例示であり、本発明の範囲を限定する趣旨のものではない。
【００１５】
（第１実施形態）
ここでは、一般的な情報処理装置（ＰＣ）を用いて、本発明の情報処理（スキーマ生成）および文書検証処理を実現する例について以下に説明する。なお、以下の説明においては、情報処理装置は上述のスキーマ生成機能と文書検証機能との双方を、アプリケーションを実行することにより実現している。
【００１６】
＜装置構成＞
図５は、第１実施形態に係る情報処理装置（ＰＣ）を含むシステムの構成を示す図である。ＰＣ１０１は、ＬＡＮ１０２に接続されている。ＬＡＮ１０２には、デジタルカメラ１０３、プリンタ１０４、ファイルサーバ１０５が接続されている。そして、ＰＣ１０１は、デジタルカメラ１０３、プリンタ１０４およびファイルサーバ１０５において生成あるいは蓄積される各種データの管理を行っている。例えば、ファイルサーバ１０５で蓄積される文書データを管理しているとする。
【００１７】
図６は、第１実施形態に係る情報処理装置（ＰＣ）の内部構成を示すブロック図である。
【００１８】
ＣＰＵ２０１はシステム制御部であり、各種プログラムを実行することにより装置全体を制御する。ＲＯＭ２０２は、ＣＰＵ２０１で実行される制御プログラムや各種固定データを格納するものである。ＲＡＭ２０３は、ＳＲＡＭ、ＤＲＡＭなどで構成され、プログラム制御変数などを一時的に格納するためのものである。また、各種設定パラメータ、各種ワーク用バッファもＲＡＭ２０３に格納される。
【００１９】
記憶部２０４は、文書データや画像データなどの各種データファイルを格納するための大容量の記憶装置である。例えば、ハードディスクドライブ（ＨＤＤ）などで構成される。操作部２０５は、キーボードやマウス、タッチパネルなどの入力装置で構成され、オペレータが各種入力操作を行うためのものである。表示部２０６は、画像を表示することにより各種情報をオペレータに伝えるための機能部である。
【００２０】
ＬＡＮｉ／ｆ２０７は、ＬＡＮ回線２０８（ＬＡＮ１０２）に接続するためのインターフェースである。ＵＳＢｉ／ｆ２０９は、ＵＳＢ回線２１０に接続するためのインターフェースである。
【００２１】
＜構造化文書＞
次に、第１実施形態に係る情報処理装置（ＰＣ）が取り扱う構造化文書データのスキーマデータの構造について説明する。特に、構造化文書がバージョンアップして、データ構造、データ型に変更があった場合のスキーマデータの生成について説明する。
【００２２】
なお、第１実施形態で使用するスキーマ言語としては、ＩＳＯで策定されたＲＥＬＡＸ  ＮＧ（ｈｔｔｐ：／／ｗｗｗ．ｒｅｌａｘｎｇ．ｏｒｇ／ｓｐｅｃ−２００１１２０３．ｈｔｍｌ）を用いるものとする。また、ＲＥＬＡＸ  ＮＧの名前空間は、”ｈｔｔｐ：／／ｒｅｌａｘｎｇ．ｏｒｇ／ｎｓ／ｓｔｒｕｃｔｕｒｅ／１．０”である。
【００２３】
また、ユーザが編集した後の構造化文書のバージョン番号をｖｅｒＮｕｍとする。以下では、ｖｅｒＮｕｍは最初のバージョンを０．１とし、以降０．１ずつバージョン番号が増えていくものとして説明する。つまり、０．１→０．２→０．３のように増えていくものとする。
【００２４】
図７は、ｖｅｒ０．１の構造化文書データ（住所録）に対応するスキーマデータを示す図である。なお、当該スキーマデータに対する構造化文書データは図１のｖｅｒ０．１の住所録データである。
【００２５】
第１実施形態では、図７に示すスキーマデータを基準となるスキーマデータとして利用する。そして、ユーザが構造化文書に対して新しい要素や属性を追加する場合には、その追加した要素や属性に対して、ｖｅｒＮｕｍを値とするｖｅｒ：ａｄｄ属性を追加する。ここで、接頭辞ｖｅｒは、”ｘｍｌｎｓ：ｖｅｒ＝ｈｔｔｐ：／／ｖｅｒｓｉｏｎｉｎｇ．ｏｒｇ”で宣言され、バージョン管理するための名前空間”ｈｔｔｐ：／／ｖｅｒｓｉｏｎｉｎｇ．ｏｒｇ”に対応付けられていると仮定する。
【００２６】
そして、図３のようにｖｅｒ０．２で各ｐｅｒｓｏｎ要素の子要素として、電話番号を表すｐｈｏｎｅ要素が追加されたとする。
【００２７】
図８は、要素の追加したｖｅｒ０．２の構造化文書データ（住所録）に対応するスキーマデータを示す図である。図７のスキーマデータに対し、ｖｅｒ０．１（第１のバージョン）からｖｅｒ０．２（第２のバージョン）への差分情報（ｐｈｏｎｅ要素）が追加されている。また、追加されたｐｈｏｎｅ要素には、０．２を値とするｖｅｒ：ａｄｄ属性を追加している。つまり相違する部分の要素（ｐｈｏｎｅ要素）と相違種別（ａｄｄ）とを検出し追加している。
【００２８】
一方、ｖｅｒ０．２で各ｐｅｒｓｏｎ要素内にあるｉｄ属性が削除されたとする。構造化文書から要素や属性を削除する場合には、その削除する要素や属性のスキーマに対して、ｖｅｒＮｕｍを値とするｖｅｒ：ｄｅｌｅｔｅ属性を追加する。
【００２９】
図９は、属性を削除したｖｅｒ０．２の構造化文書データ（住所録）に対応するスキーマデータを示す図である。そして、ここでは、ｖｅｒ０．２で削除するｉｄ属性のスキーマを定義しているａｔｔｒｉｂｕｔｅ要素に、０．２を値としたｖｅｒ：ｄｅｌｅｔｅ属性を追加している。
【００３０】
また、ｖｅｒ０．２で各ｐｅｒｓｏｎ要素内にあるｎａｍｅ要素の名前（要素名）が変更されたとする。構造化文書における要素や属性の名前を変更する場合には、その名前を変更する要素や属性を定義しているスキーマの子要素に、ｖｅｒ：ｒｅｎａｍｅ要素を追加することによって、変更後の名前を定義する。
【００３１】
図１０は、要素の名前を変更したｖｅｒ０．２の構造化文書データ（住所録）に対応するスキーマデータを示す図である。そして、ここでは、ｎａｍｅ要素の要素名をＮＡＭＥに変更する例を示している。具体的には、ｎａｍｅ要素のスキーマを定義しているｎａｍｅ要素の子要素に、ｖｅｒ：ｒｅｎａｍｅ要素を追加する。そして、属性として、バージョン番号０．２を値とするｎｕｍ属性を記述し、その要素内容にはバージョン０．２の要素名（つまり変更後の要素名）であるＮＡＭＥを記述する。
【００３２】
さらに、ｖｅｒ０．２で各ｐｅｒｓｏｎ要素内にあるｉｄ属性のデータ型が変更されたとする。構造化文書内の要素の属性を変更する場合には、その変更するデータ型のスキーマの子要素に、ｖｅｒ：ｒｅＴｙｐｅ要素を追加することによって、変更後のデータ型を定義する。
【００３３】
図１１は、属性のデータ型を変更したｖｅｒ０．２の構造化文書データ（住所録）に対応するスキーマデータを示す図である。そして、ここでは、ｉｄ属性のデータ型をｕｎｓｉｇｎｅｄＩｎｔに変更した場合を示している。具体的には、ｄａｔａ要素の子要素に、０．２を値とするｎｕｍ属性を持つｖｅｒ：ｒｅＴｙｐｅ要素を追加し、その要素内容には新しいデータ型であるｕｎｓｉｇｎｅｄＩｎｔを記述する。
【００３４】
以上説明したように、バージョンアップによってデータ構造やデータ型に変更のあった場合には、基準となるスキーマデータ（ここではｖｅｒ０．１）に対し差分情報と共にそのバージョン番号をスキーマデータに記述（追記）していく。ここでは２種類のバージョンについて説明したが、上述の処理を昇順に再帰的に行うことにより、Ｎ種類（Ｎは３以上の正整数）のバージョンにも対応可能である。つまり、最初のバージョンのスキーマデータから最後のバージョンのスキーマデータまで順次処理することにより、各々のバージョンに対応するＮ個のスキーマデータから単一のスキーマデータが生成される。
【００３５】
＜装置の動作＞
次に、以上のように生成されたスキーマデータを用いて構造化文書を検証する手順について説明する。なお、第１実施形態では、ＤＯＭパーサを用いることによって、まずスキーマ全体のＤＯＭツリーを生成した後、アプリケーションから指定したバージョン番号に基づいて検証に不要なノードを削除する方法を説明する。
【００３６】
図１２は、複数のバージョンを管理したスキーマデータを例示的に示す図である。具体的には、０．１、０．２、０．３の３つのバージョンを管理したスキーマデータである。
【００３７】
図１５は、構造化文書データを例示的に示す図である。なお、図に示されるように構造化文書データには予めバージョン情報が含まれている。具体的には、を含んだルートのｂｏｏｋ要素において、接頭辞ｖｅｒが”ｘｍｌｎｓ：ｖｅｒ＝ｈｔｔｐ：／／ｖｅｒｓｉｏｎｉｎｇ．ｏｒｇ”で宣言され、ｖｅｒ：ｎｕｍ属性によって、この構造化文書のバージョン番号は０．２であると記述している。
【００３８】
図１３は、構造化文書データに対して妥当性検証を行う手順を示すフローチャートである。なお、以下の各ステップは、ＰＣ１０１のＣＰＵ２０１が構造化文書検証アプリケーションを実行することにより実現される。
【００３９】
ステップＳ２０１では、構造化文書検証アプリケーションを実行開始する。具体的にはＰＣ１０１が操作部２０５を介してユーザから構造化文書検証アプリケーションの実行指示を受け付けることにより実現される。
【００４０】
ステップＳ２０２では、アプリケーションは、スキーマプロセッサに対して、妥当性検証の対象となる構造化文書を指定する。なお、スキーマプロセッサはアプリケーションに組み込まれるよう構成されていてもよいし、アプリケーションから呼び出される外部プログラムとして構成されていてもよい。
【００４１】
ステップＳ２０３では、妥当性検証に使用するスキーマデータを指定する。つまり、上述した複数のバージョン情報を含んだスキーマデータを、例えばユーザからの操作による指定を受け付ける。
【００４２】
ステップＳ２０４では、スキーマプロセッサは構造化文書データを解析する。
【００４３】
ステップＳ２０５では、ステップＳ２０４での解析の結果、構造化文書データがバージョン情報を含んでいるかどうか判定（決定）する（バージョン決定手段）。つまり、図１５に示したようなバージョン情報が含まれているか否かを判定する。含んでいないと判定したならばステップＳ２０７に進み、含んでいると判定した場合はステップＳ２０６に進む。
【００４４】
ステップＳ２０７では、アプリケーションがスキーマプロセッサに対してバージョン番号を指定する。例えば、操作部２０５を介したユーザからバージョン番号の指定を受け付ける。
【００４５】
ステップＳ２０６では、ステップＳ２０５またはステップＳ２０７において指定されたバージョン番号に基づいて、構造化文書データに対応するスキーマのＤＯＭ（Document Object Model）ツリーを生成する。つまり、ステップＳ２０３で指定されたスキーマデータかＤＯＭツリーを生成する。そして、生成したＤＯＭツリーをＲＡＭ２０３に記憶する。なお、ＤＯＭツリーの生成処理の詳細については、図１４を参照して後述する。
【００４６】
ステップＳ２０８では、ステップＳ２０６で生成したＤＯＭツリーに基づいて、ステップＳ２０２で指定された構造化文書の妥当性を検証する。なお、妥当性検証処理の詳細については、図１９を参照して後述する。
【００４７】
ステップＳ２０９では、スキーマプロセッサは、ステップＳ２０８における妥当性検証の結果を、アプリケーションに通知して、終了（ステップＳ２１０）する。
【００４８】
図１４は、ステップＳ２０６に相当するＤＯＭツリー生成の詳細フローチャートである。
【００４９】
ステップＳ３０１では、スキーマプロセッサを実行開始する。前述したように、スキーマプロセッサはアプリケーションに組み込まれるか、または、アプリケーションから呼び出される。
【００５０】
ステップＳ３０２では、ステップＳ２０３で指定されたスキーマデータを読み込みＲＡＭ２０３に記憶する。つまり、図１２に示したスキーマデータを基にＤＯＭを生成し内部メモリに保存する。
【００５１】
ステップＳ３０３では、全ての要素ノードを解析したかどうか判定する。全ての要素ノードを解析していないと判断したならば、解析をしていない要素ノードを１つ選択しステップＳ３１８に進む。解析していない要素ノードが残っている場合はステップＳ３０４に進む。
【００５２】
ステップＳ３０４では、要素ノードにバージョン情報を含んでいるかどうか判定する。要素ノードがバージョン情報を含んでいると判断したならば当該バージョン番号を設定した後ステップＳ３０５に進み、含まないと判断したならばステップＳ３０６に進む。
【００５３】
ステップＳ３０５では、ｖｅｒ：ａｄｄ属性を含んでいるかどうか判定する。ここで、接頭辞ｖｅｒは、”ｘｍｌｎｓ：ｖｅｒ＝ｈｔｔｐ：／／ｖｅｒｓｉｏｎｉｎｇ．ｏｒｇ”によって、バージョン管理するための名前空間を表す接頭辞として宣言してあるものとする。ｖｅｒ：ａｄｄ属性を含まないと判断したならば、ステップＳ３０９に進む。一方、ｖｅｒ：ａｄｄ属性を含んでいると判断したならば、その属性値がアプリケーションがスキーマプロセッサに指定したバージョン番号ｖｅｒＮｕｍ以下の値かどうか判定する（ステップＳ３０７）。そして、属性値がｖｅｒＮｕｍ以下の値ではないと判断したならば、その要素ノード以下をＤＯＭツリーから削除し（ステップＳ３０８）、その後ステップＳ３０３に戻る。一方、属性値がｖｅｒＮｕｍ以下の値であると判断したならば、その要素ノードに関するデータは更新せず、ステップＳ３０３に戻る。
【００５４】
ステップＳ３０９では、ｖｅｒ：ｄｅｌｅｔｅ属性を含むかどうか判定する。ｖｅｒ：ｄｅｌｅｔｅ属性を含まないと判断したならば、ステップＳ３１２に進む。一方、ｖｅｒ：ｄｅｌｅｔｅ属性を含むと判断したならば、その属性値がバージョン番号ｖｅｒＮｕｍ以下の値かどうか判定する（ステップＳ３１０）。そして、属性値がバージョン番号ｖｅｒＮｕｍ以下の値であると判断したならば、その要素ノード以下をＤＯＭツリーから削除し（ステップＳ３１１）、その後ステップＳ３０３に戻る。一方、属性値がバージョン番号ｖｅｒＮｕｍ以下の値ではないと判断したならば、その要素ノードに関するデータは更新せず、ステップＳ３０３に戻る。
【００５５】
ステップＳ３１２では、ｖｅｒ：ｒｅｎａｍｅ要素であるかどうか判定する。ｖｅｒ：ｒｅｎａｍｅ要素でないと判断したならば、ステップＳ３１５に進む。一方、ｖｅｒ：ｒｅｎａｍｅ要素であると判断したならば、ｖｅｒ：ｒｅｎａｍｅ要素の属性ｎｕｍの値がバージョン番号ｖｅｒＮｕｍ以下であるか判定する（ステップＳ３１３）。そして、属性ｎｕｍの値がバージョン番号ｖｅｒＮｕｍ以下であると判断したならば、親のｅｌｅｍｅｎｔ要素に含まれるｎａｍｅ属性の値を、ｖｅｒ：ｒｅｎａｍｅ要素の要素内容で更新し（ステップＳ３１４）、その後ステップＳ３０３に戻る。一方、属性ｎｕｍの値がバージョン番号ｖｅｒＮｕｍ以下ではないと判断したならば、親のｅｌｅｍｅｎｔ要素に含まれるｎａｍｅ属性の値を更新せず、ステップＳ３０３に戻る。
【００５６】
ステップＳ３１５では、ｖｅｒ：ｒｅＴｙｐｅ要素であるかどうか判定する。ｖｅｒ：ｒｅＴｙｐｅ要素でないと判断したならば、ステップＳ３０３に戻る。ｖｅｒ：ｒｅＴｙｐｅ要素であると判断したならば、ｖｅｒ：ｒｅＴｙｐｅ要素の属性ｎｕｍの値がバージョン番号ｖｅｒＮｕｍ以下であるか判定する（ステップＳ３１６）。そして、属性ｎｕｍの値がバージョン番号ｖｅｒＮｕｍ以下であると判断したならば、親のｄａｔａ要素に含まれるｔｙｐｅ属性の値を、ｖｅｒ：ｒｅＴｙｐｅ要素の要素内容で更新し（ステップＳ３１７）、その後ステップＳ３０３に戻る。一方、ｖｅｒ：ｒｅＴｙｐｅ要素の属性ｎｕｍの値がバージョン番号ｖｅｒＮｕｍ以下ではないと判断したならば、親のｄａｔａ要素に含まれるｔｙｐｅ属性の値を更新せず、ステップＳ３０３に戻る。
【００５７】
ステップＳ３０４において、その要素ノードがバージョン情報を含んでいないと判断したならば、バージョン情報を持つ一番近い祖先要素のバージョン情報を設定し（ステップＳ３０６）、その後、上述のステップＳ３０５以降の処理を行う。
【００５８】
例えば、図１２のスキーマにおいて、ｐｅｒｓｏｎ要素のスキーマ＜ｅｌｅｍｅｎｔ  ｎａｍｅ＝”ｐｅｒｓｏｎ”＞については、バージョン情報を含む一番近い祖先要素はｇｒａｍｍａｒ要素である。そのため、ｇｒａｍｍａｒ要素の属性ｖｅｒ：ｎｕｍを用いることによってステップＳ３０５以降の処理を行う。全てのｖｅｒＮｕｍについて、ステップＳ３０５、ステップＳ３０９、ステップＳ３１２、ステップＳ３１５において全てＮＯと判断されるため、ｐｅｒｓｏｎ要素のスキーマのデータは更新されない。
【００５９】
同様に、ｉｄ属性のスキーマの子要素であるｄａｔａ要素については、親のａｔｔｒｉｂｕｔｅ要素の属性ｖｅｒ：ｄｅｌｅｔｅを用いることによってステップＳ３０５以降の処理を行う。
【００６０】
ｖｅｒＮｕｍが０．１、０．２の場合、ステップＳ３０９からステップＳ３１０を処理する。このとき、属性値０．３はｖｅｒＮｕｍ以下ではないので、バージョン０．１、０．２の検証ではｄａｔａ要素のスキーマは更新されることはない。ｖｅｒＮｕｍが０．３の場合、親のａｔｔｒｉｂｕｔｅ要素の処理において、ステップＳ３０９からステップＳ３１０を処理する。このとき、ｖｅｒ：ｄｅｌｅｔｅ属性の値がｖｅｒＮｕｍ以下であると判断されるので、ａｔｔｒｉｂｕｔｅ要素のスキーマ以下全てのノードが削除される。
【００６１】
また、ｐｈｏｎｅ要素のスキーマにおける、値が”ｓｔｒｉｎｇ”のｔｙｐｅ属性を持つｄａｔａ要素については以下の状態になる。具体的には、ｖｅｒＮｕｍが０．１の場合には、ｐｈｏｎｅ要素のスキーマを表すｅｌｅｍｅｎｔ要素を処理する際に、ステップＳ３０８において、値０．２のｖｅｒ：ａｄｄ属性を持つ。そのため、ｐｈｏｎｅ要素以下の全てのノードが削除される。また、ｖｅｒＮｕｍが０．２、０．３の場合には、ｐｈｏｎｅ要素のスキーマを表すｅｌｅｍｅｎｔ要素はＤＯＭツリーから削除されることはない。そのため、その子要素であるｄａｔａ要素は、親のｖｅｒ：ａｄｄ属性を用いることによって、ステップＳ３０７においてｖｅｒ：ａｄｄ属性の値がｖｅｒＮｕｍ以下であると判断される。つまり、子要素ｄａｔａもＤＯＭツリーから削除されることはない。
【００６２】
ステップＳ３０３において、全ての要素ノードを解析したと判断したならば、バージョン管理するための名前空間に属する要素ノード、属性ノードを全てＤＯＭツリーから削除し（ステップＳ３１８）、処理を終了する（ステップＳ３１９）。よって、ステップＳ３１８の処理を行った後は、記述しているスキーマ言語の名前空間ｈｔｔｐ：／／ｒｅｌａｘｎｇ．ｏｒｇ／ｎｓ／ｓｔｒｕｃｔｕｒｅ／１．０  以外の要素、属性はＤＯＭツリーに含まれない状態になる。
【００６３】
このようにして、アプリケーションがバージョン番号０．１、０．２、０．３それぞれを指定した場合、それぞれのＤＯＭツリーを生成する。つまり、スキーマプロセッサは、ｐｅｒｓｏｎ要素を表すスキーマについて、図１６、図１７、図１８に示すようなＤＯＭツリーをそれぞれ生成し、内部メモリに保存する。
【００６４】
図１９は、ステップＳ２０８の妥当性検証の処理手順を詳細に示したフローチャートである。
【００６５】
ステップＳ４０２では、スキーマのＤＯＭツリーの各ノードについて、構造化文書と検証済みであるかどうかを示すフラグを”０”で初期化する。構造化文書と既に検証済みである場合には、このフラグは”１”に値を変更するものとする。ここでは、構造化文書を開始タグ、要素内容、終了タグと順番に解析するＳＡＸ(Simple API for XML)パーサを用いる。そうすることによって、スキーマプロセッサは構造化文書を解析し、その各開始タグ、要素内容、終了タグのデータを先頭から順番に妥当性検証を行うものとする。
【００６６】
ステップＳ４０３では、構造化文書の全てに対して妥当性検証を行ったかどうか判定する。構造化文書の全てのデータについて妥当性検証を行っていないと判断した場合には、未検証のＸＭＬデータを選択しステップＳ４０４に進む。一方、全てのデータについて妥当性検証を行ったと判断した場合にはステップＳ４１１に進む。
【００６７】
ステップＳ４０４では、検証済みのフラグを解析することによって、スキーマのＤＯＭツリーにおいて検証に使用していないノードがあるかどうかを判定する。ある場合はステップＳ４０５に進み、無い場合はステップＳ４１０に進む。
【００６８】
ステップＳ４０５では、まだ検証に使用していないスキーマのノードに、検証対象を遷移させる。
【００６９】
ステップＳ４０６では、ステップＳ４０５において遷移した検証対象のスキーマを解析する。もし、そのスキーマが要素を定義したスキーマの場合、その要素名と、その要素に含まれる属性名と属性値の型情報を解析する。もし、そのスキーマが要素内容を定義したスキーマの場合、その要素内容の型情報を解析する。
【００７０】
ステップＳ４０７では、ステップＳ４０６で解析した情報に基づいて、検証対象のＸＭＬデータが妥当性を判定する。妥当であると判定した場合はステップＳ４０８に進み、非妥当であると判断した場合はステップＳ４０９に進む。
【００７１】
ステップＳ４０８では、検証に使用したスキーマの各ノードに対して、検証に使用済みのフラグ”１”を立てる。その後、ステップＳ４０３に戻る。
【００７２】
ステップＳ４０９では、ステップＳ４０６において解析したスキーマが、順番を問うスキーマであるかどうか解析する。例えば、図１６〜１８に示すスキーマ（ＤＯＭ）において、ｐｅｒｓｏｎ要素の各子要素は順番を問うスキーマである。ｐｅｒｓｏｎ要素の各子要素について、順番を問わない子要素を定義するには、ｉｎｔｅｒｌｅａｖｅ要素を親要素にすることによって定義することができる。順番を問うスキーマであると判断した場合にはステップＳ４１０に進み、順番を問わないと判断した場合はステップＳ４０５に戻り未検証のスキーマのノードに遷移する。
【００７３】
ステップＳ４１０では、現在検証中のＸＭＬデータは、非妥当であると判断し、処理を終了（ステップＳ４１３）する。つまり、スキーマで定義されている情報に無い余分なデータが存在すると判断できるからである。
【００７４】
ステップＳ４１１では、スキーマのＤＯＭツリーの各ノードにおいて、検証済みのフラグが立っているかどうか判定する。全てのノードについてフラグがたっていればステップＳ４１２に進み、そうでなければステップＳ４１０に進む。
【００７５】
ステップＳ４１２では、検証対象の構造化文書が妥当であると判断し、処理を終了（ステップＳ４１３）する。
【００７６】
以上詳細に説明したように、第１実施形態に係る情報処理装置により、スキーマのバージョン管理を単一のファイル（単一のスキーマデータ）内で行うことが可能になる。そのため、バージョンの数に応じた、ファイル数およびファイルサイズが飛躍的に増大を低減することが可能となる。
【００７７】
また、アプリケーションから指定したバージョン番号に基づいて、当該バージョンに対するスキーマのＤＯＭツリーを上述の単一のスキーマデータから生成することができる。そのため、指定したバージョンに特化した妥当性検証を行うことが可能になる。
【００７８】
なお、第１実施形態においては、スキーマ言語としてInternational Organization for Standardization(ISO)で策定されたRELAX NGを用いる場合について説明を行ったが、他のスキーマ言語を利用しても良い。例えば、ＤＴＤ、World Wide Web Consortium(W3C)で策定されたXML Schemaを利用することも出来る。
【００７９】
（第２実施形態）
第２実施形態では、ＳＡＸパーサを用い妥当性検証に使用するスキーマのＤＯＭツリーを生成する方法について説明する。なお、ＳＡＸパーサは、構造化文書を開始タグ、終了タグ、要素内容に分けて逐次解析し解析結果を通知するパーサである。なお、情報処理装置の内部構成は第１実施形態の情報処理装置と同様であるため説明は省略する。
【００８０】
＜装置の動作＞
図２０は、第２実施形態に係るＤＯＭツリー生成の全体フローチャートである。
【００８１】
ステップＳ５０１では、スキーマプロセッサを実行開始する。前述したように、スキーマプロセッサはアプリケーションに組み込まれるか、または、アプリケーションから呼び出される。
【００８２】
ステップＳ５０２では、ｖｅｒ：ａｄｄ、ｖｅｒ：ｄｅｌｅｔｅ、ｖｅｒ：ｒｅｎａｍｅ、ｖｅｒ：ｒｅＴｙｐｅといった差分情報の種類を格納する配列ｔｍｐＩｎｆｏと、バージョン番号を格納する配列ｔｍｐＮｕｍを初期化する。
【００８３】
ステップＳ５０３では、Ｄｏｃｕｍｅｎｔノードだけ持つようにスキーマのＤＯＭツリーを初期化する。以降、妥当性検証に必要なスキーマの各開始タグや要素内容を、ＳＡＸパーサによる解析結果に基づいてステップＳ５０３で初期化したＤＯＭツリーに追加していく。
【００８４】
ステップＳ５０４では、スキーマの全てのデータを解析したかどうか判定する。全てのデータを解析していないと判断したならばステップＳ５０５に進み、全てのデータを解析したと判断したならば処理を終了（ステップＳ５０８）する。
【００８５】
ステップＳ５０５では、ＳＡＸパーサによるデータの解析結果が、開始タグまたは要素内容であるかどうか判定する。開始タグまたは要素内容である場合は図２１を参照して後述する処理（ステップＳ５０６）に進む。一方、開始タグまたは要素内容でない場合はステップＳ５０７に進む。
【００８６】
ステップＳ５０７では、配列ｔｍｐＩｎｆｏ、ｔｍｐＶｅｒの末尾のデータを削除し、ステップＳ５０４に戻る。
【００８７】
なお、ステップＳ５０８の処理を終えた後は、ステップＳ５０３で初期化したＤＯＭツリーは、スキーマプロセッサに指定したバージョン番号に特化した妥当性検証に必要なスキーマのＤＯＭツリーとして構築される。そして、このＤＯＭツリーを利用することにより図１３を参照して説明した妥当性検証を行うことが可能になる。
【００８８】
図２１は、ＤＯＭツリー生成におけるステップＳ５０６に相当する処理の詳細フローチャートである。
【００８９】
ステップＳ６０２では、解析結果のデータがバージョン情報を含むかどうか判定する。もし、バージョン情報を含むと判断したならばステップＳ６０３に進み、含まない場合はステップＳ６０４に進む。
【００９０】
ステップＳ６０４では、配列ｔｍｐＩｎｆｏとｔｍｐＶｅｒの末尾のデータ(ステップＳ６０８で、追加された差分情報の種類)を内部メモリにそれぞれコピーする。ｔｍｐＩｎｆｏとｔｍｐＶｅｒの末尾のデータは、ステップＳ５０７で削除されるので、それらのコピーしたデータを次の解析結果のデータで用いるために、配列ｔｍｐＩｎｆｏとｔｍｐＶｅｒの末尾に追加する。
【００９１】
ステップＳ６０５では、配列ｔｍｐＩｎｆｏとｔｍｐＶｅｒの末尾にコピーしたデータを解析し、その解析結果を用いることによって、ステップＳ６０３以降の処理を行う。
【００９２】
ステップＳ６０３では、ｖｅｒ：ａｄｄ属性を含むかどうか判定する。ｖｅｒ：ａｄｄ属性を含まないと判断したならばステップＳ６１１に進み、含むと判断したならばステップＳ６０６に進む。
【００９３】
ステップＳ６０６では、ｖｅｒ：ａｄｄの属性値がｖｅｒＮｕｍ以下の値であるかどうか判定する。ｖｅｒ：ａｄｄの属性値がｖｅｒＮｕｍ以下の値であると判断したならば、差分情報の種類ｖｅｒ：ａｄｄを配列ｔｍｐＩｎｆｏの末尾に追加する（ステップＳ６０８）。そして、ｖｅｒ：ａｄｄ属性の値であるバージョン番号を配列ｔｍｐＮｕｍの末尾に追加する（ステップＳ６０９）。さらに、解析中の開始タグまたは要素内容をスキーマのＤＯＭに追加する（ステップＳ６１０）。
【００９４】
ステップＳ６０６において、ｖｅｒ：ａｄｄの属性値がｖｅｒＮｕｍ以下の値ではないと判断したならば、現在解析中のデータが開始タグの場合、終了タグまで解析してスキーマのデータを読み飛ばす。また、現在解析中のデータが要素内容の場合、その要素内容を読み飛ばす。つまり、スキーマのＤＯＭツリーには追加しない（ステップＳ６０７）。
【００９５】
ステップＳ６１１では、ｖｅｒ：ｄｅｌｅｔｅ属性を含むかどうか判定する。もし、ｖｅｒ：ｄｅｌｅｔｅ属性を含むと判断したならば、ステップＳ６１２に進み、含まないと判断したならばステップＳ６１７に進む。
【００９６】
ステップＳ６１２では、ｖｅｒ：ｄｅｌｅｔｅの属性値がｖｅｒＮｕｍ以下であるかどうか判定する。ｖｅｒ：ｄｅｌｅｔｅの属性値がｖｅｒＮｕｍ以下ではないと判断したならば、差分情報の種類ｖｅｒ：ｄｅｌｅｔｅを配列ｔｍｐＩｎｆｏの末尾に追加する（ステップＳ６１４）。そして、ｖｅｒ：ｄｅｌｅｔｅ属性の値であるバージョン番号を配列ｔｍｐＮｕｍの末尾に追加する（ステップＳ６１５）。さらに、解析中の開始タグまたは要素内容をスキーマのＤＯＭに追加する（ステップＳ６１６）。
【００９７】
ステップＳ６１２において、ｖｅｒ：ｄｅｌｅｔｅの属性値がｖｅｒＮｕｍ以下の値であると判断したならば、現在解析中のデータが開始タグの場合、終了タグまで解析してスキーマのデータを読み飛ばす。また、現在解析中のデータが要素内容の場合、その要素内容を読み飛ばす。つまり、スキーマのＤＯＭツリーには追加しない（ステップＳ６１３）。
ステップＳ６１７では、ｖｅｒ：ｒｅｎａｍｅ要素であるかどうか判定する。ｖｅｒ：ｒｅｎａｍｅ要素であると判断したならば、ｖｅｒ：ｒｅｎａｍｅ要素に対応する終了タグまで解析し内部メモリに保存する（ステップＳ６１８）。そして、ステップＳ６１８において内部メモリに保存したｖｅｒ：ｒｅｎａｍｅ要素のｎｕｍ属性の値がｖｅｒＮｕｍ以下であるかどうか判定する（ステップＳ６１９）。
【００９８】
もし、ｖｅｒ：ｒｅｎａｍｅ要素のｎｕｍ属性の値がｖｅｒＮｕｍ以下であると判断したならば、まず、ステップＳ６１８において内部メモリに保存したｖｅｒ：ｒｅｎａｍｅ要素とその要素内容をスキーマのＤＯＭツリーに追加する（ステップＳ６２０）。そして、親ノードのｅｌｅｍｅｎｔ要素のｎａｍｅ属性の値をｖｅｒ：ｒｅｎａｍｅ要素の要素内容で更新する（ステップＳ６１２）。さらに、ステップＳ６２０で追加したｖｅｒ：ｒｅｎａｍｅ要素とその要素内容をスキーマのＤＯＭツリーから削除する（ステップＳ６２２）。
【００９９】
ステップＳ６１９において、ｖｅｒ：ｒｅｎａｍｅ要素のｎｕｍ属性の値がｖｅｒＮｕｍ以下ではないと判断したならば、ステップＳ６１８で内部メモリに保存したｖｅｒ：ｒｅｎａｍｅ要素とその要素内容を内部メモリから削除する。
【０１００】
ステップＳ６２３では、ｖｅｒ：ｒｅＴｙｐｅ要素であるかどうか判定する。ｖｅｒ：ｒｅＴｙｐｅ要素であると判断したならば、ｖｅｒ：ｒｅＴｙｐｅ要素に対応する終了タグまで解析し内部メモリに保存する（ステップＳ６２４）。そして、ステップＳ６２４において内部メモリに保存したｖｅｒ：ｒｅＴｙｐｅ要素のｎｕｍ属性の値がｖｅｒＮｕｍ以下であるかどうか判定する（ステップＳ６１９）。
【０１０１】
もし、ｖｅｒ：ｒｅＴｙｐｅ要素のｎｕｍ属性の値がｖｅｒＮｕｍ以下であると判断したならば、まず、ステップＳ６２４において内部メモリに保存したｖｅｒ：ｒｅＴｙｐｅ要素とその要素内容をスキーマのＤＯＭツリーに追加する（ステップＳ６２６）。そして、親ノードのｄａｔａ要素のｔｙｐｅ属性の値をｖｅｒ：ｒｅＴｙｐｅ要素の要素内容で更新する（ステップＳ６２７）。さらに、ステップＳ６２６で追加したｖｅｒ：ｒｅＴｙｐｅ要素とその要素内容をスキーマのＤＯＭツリーから削除する（ステップＳ６２８）。
【０１０２】
ステップＳ６２５において、ｖｅｒ：ｒｅｎａｍｅ要素のｎｕｍ属性の値がｖｅｒＮｕｍ以下ではないと判断したならば、ステップＳ６２４で内部メモリに保存したｖｅｒ：ｒｅＴｙｐｅ要素とその要素内容を内部メモリから削除する。
【０１０３】
以上詳細に説明したように、第２実施形態に係る情報処理装置により、アプリケーションから指定したバージョン番号に基づいて、当該バージョンに対するスキーマのＤＯＭツリーを上述の単一のスキーマデータから生成することができる。つまり、図２０を参照して説明したフローにしたがって、指定したバージョン番号に特化したスキーマのＤＯＭツリーが構築される。
【０１０４】
そのため、構築されたＤＯＭツリーに基づいて、第１実施形態において図１３を参照して説明した妥当性検証を行うことが可能になる。
【０１０５】
（第３実施形態）
第３実施形態では、バージョンアップに伴なって、要素や属性の追加のみを行ったスキーマを用いて、妥当性検証に使用するスキーマのＤＯＭツリーを生成する方法について説明する。なお、情報処理装置の内部構成は第１実施形態の情報処理装置と同様であるため説明は省略する。
【０１０６】
＜スキーマの構成＞
また、バージョンアップに伴なって追加する要素や属性の差分情報を表すスキーマは、ＲＥＬＡＸ  ＮＧのｄｅｆｉｎｅ要素を用いることによって大域的に定義するものとする。そして、ｄｅｆｉｎｅ要素は、追加した際のバージョン番号を値とするｖｅｒ：ａｄｄ属性を含むものとする。なお、最初のバージョンから定義してあるスキーマは、ｖｅｒ：ａｄｄ属性を含まないものとする。
【０１０７】
図２３は、図７に示したＶｅｒ０．１の住所録のスキーマに対しバージョンアップを行ったスキーマを例示的に示す図である。具体的には、ｖｅｒ０．１のスキーマ（図７）に対して、ｖｅｒ０．２ではｐｅｒｓｏｎ要素の子要素としてｐｈｏｎｅ要素を追加している。さらに、ｖｅｒ０．３ではｖｅｒ０．２に対して、ｐｅｒｓｏｎ要素の属性としてｂｉｒｔｈｄａｙ属性を追加している。バージョンアップした際には、ｄｅｆｉｎｅ要素を用いることによって、ｐｈｏｎｅ要素やｂｉｒｔｈｄａｙ属性のスキーマを追加している。
【０１０８】
＜装置の動作＞
図２２は、第３実施形態に係るＤＯＭツリー生成の全体フローチャートである。
【０１０９】
ステップＳ７０２では、図２３のスキーマデータに基づいて、全要素のＤＯＭツリーを生成し内部メモリに保存する（全要素ツリー生成手段）。
【０１１０】
ステップＳ７０３では、ｇｒａｍｍａｒ要素の子要素である全てのｄｅｆｉｎｅ要素を解析したかどうか判定する。全てのｄｅｆｉｎｅ要素を解析したと判断したならば、ステップＳ７０７に進む。そうでなければ、解析していないｄｅｆｉｎｅ要素を選択し、ステップＳ７０４に進む。
【０１１１】
ステップＳ７０４では、ｄｅｆｉｎｅ要素がバージョン情報を含むかどうか判定する。解析中のｄｅｆｉｎｅ要素がバージョン情報を含むと判断したならばステップＳ７０５に進む。含まないと判定した場合はステップＳ７０３に戻る。
【０１１２】
ステップＳ７０５では、ｄｅｆｉｎｅ要素の属性ｖｅｒ：ｎｕｍ属性の値が構造化文書のバージョン番号ｖｅｒＮｕｍ以下かどうか判定する。ｄｅｆｉｎｅ要素の属性ｖｅｒ：ｎｕｍ属性の値が、構造化文書のバージョン番号ｖｅｒＮｕｍ以下ではないと判断したならば、ステップＳ７０６に進む。ｄｅｆｉｎｅ要素の属性ｖｅｒ：ｎｕｍ属性の値が構造化文書のバージョン番号ｖｅｒＮｕｍ以下であると判断したならばステップＳ７０３に戻る。
【０１１３】
ステップＳ７０６では、ｄｅｆｉｎｅ要素以下の全てのノードをスキーマのＤＯＭツリーから削除する（要素削除手段）。その後、ステップＳ７０３に戻る。
【０１１４】
ステップＳ７０７では、全てのｒｅｆ要素について、そのｒｅｆ要素から参照するｄｅｆｉｎｅ要素がない場合には、そのｒｅｆ要素をスキーマのＤＯＭツリーから削除する。
【０１１５】
ステップＳ７０８では、ステップＳ７０７の処理を行ったＤＯＭツリーから全てのバージョン情報を削除する。その後、処理を終了する（ステップＳ７０８）。
【０１１６】
図２４、図２５および図２６は、それぞれｖｅｒ０．１、ｖｅｒ０．２、ｖｅｒ０．３の構造化文書に対して、図２２を参照して説明した処理を行った後のスキーマを示す図である。各図に示されるように、構造化文書の各バージョンに応じて、妥当性検証に不要なｄｅｆｉｎｅ要素はスキーマから削除される。また、ｄｅｆｉｎｅ要素を参照しているｒｅｆ要素も削除される。また、ステップＳ７０９の処理によって、スキーマから全てのバージョン情報が削除される。
【０１１７】
以上詳細に説明したように、第３実施形態に係る情報処理装置により、アプリケーションから指定したバージョン番号に基づいて、当該バージョンに対するスキーマのＤＯＭツリーを上述の単一のスキーマデータから生成することができる。つまり、図２２を参照して説明したフローにしたがって、指定したバージョン番号に特化したスキーマのＤＯＭツリーが構築される。
【０１１８】
そのため、構築されたＤＯＭツリーに基づいて、第１実施形態において図１３を参照して説明した妥当性検証を行うことが可能になる。
【０１１９】
（第４実施形態）
第４実施形態では、更新箇所の差分情報だけを記述したファイルを外部から与えることによって、図１２のようなバージョン管理されたスキーマを自動的に生成する方法（スキーマ作成手段）について説明する。図２７、図２８は、一連の処理手順を示すフローチャートである。
【０１２０】
ステップＳ８０２では、スキーマファイルを解析することによってＤＯＭツリーを生成する。ステップＳ８０３では、図２９に示されるような差分情報のみを記述した差分情報ファイルを解析する。この差分情報ファイルは、更新するバージョン番号と、ＸＰａｔｈ式を用いて記述した更新位置と、追加・削除・名前変更・データ型変更などの更新種別と、その更新内容と、を記述している。なお、ＸＰａｔｈ式とは、World Wide Web Consortium(W3C)で策定されたXML Path Language(XPath)を用いた記述方法である。
【０１２１】
ステップＳ８０４では、差分情報ファイルの各行の内容に基づいて、スキーマのＤＯＭツリーを更新したかどうか判定する。
【０１２２】
もし全ての行の内容に基づいて、スキーマのＤＯＭツリーを更新していないと判断した場合には、ステップＳ８０５において、最初の列についてバージョン番号を解析する。そして、第２列の更新位置を示したＸＰａｔｈ式を解析する（Ｓ８０６）。次に、第３列の更新種別と、第４列の更新内容を解析する（Ｓ８０７）。そして、Ｓ８０５〜Ｓ８０７で解析した情報を基に、スキーマのＤＯＭツリーを更新する（Ｓ８０８）。
【０１２３】
図２８は、Ｓ８０８の処理内容を詳細に示したフローチャートである。
【０１２４】
ステップＳ９０２では、更新種別が”ａｄｄ”であるかどうか判定する。もし更新種別が”ａｄｄ”であると判断したならば、図２９の更新内容である部分スキーマのルート要素であるｅｌｅｍｅｎｔ要素に、バージョン番号を値とするｖｅｒ：ａｄｄ属性を追加する（Ｓ９０３）。そして、Ｓ９０３で更新した部分スキーマを、ＸＰａｔｈ式の指す位置に追加する（Ｓ９０４）。
【０１２５】
図３０は、差分情報の第１行目に基づいて編集したスキーマの内容を示す図である。これは、更新内容の部分スキーマに対してｖｅｒ：ａｄｄ属性を追加し、更新した部分スキーマをＸＰａｔｈ式“／ｂｏｏｋ／ｐｅｒｓｏｎ”の示す位置に子要素として追加したものを示している。
【０１２６】
ステップＳ９０５では、更新種別が“ｒｅｔｙｐｅ”であるかどうか判定する。もし、更新種別が“ｒｅｔｙｐｅ”であると判断したならば、ＸＰａｔｈ式の指す位置からデータ型定義のスキーマを特定する（Ｓ９０６）。そして、データ型定義のスキーマ要素に、ｖｅｒ：ｒｅＴｙｐｅ要素を子要素として追加し（Ｓ９０７）、その要素に対して、バージョン番号を値とするｎｕｍ属性を設定し（Ｓ９０８）、新しいデータ型を要素内容として設定する（Ｓ９０９）（データ型定義変更手段）。
【０１２７】
図２９の例では、第２列の更新種別が”ｒｅｔｙｐｅ”なので、まずＸＰａｔｈ式”／ｂｏｏｋ／ｐｅｒｓｏｎ＠ｉｄ”の位置のｉｄ属性のスキーマに基づいて、このｉｄ属性の値のデータ型を定義するｄａｔａ要素を特定する。そして、そのｄａｔａ要素の子要素としてｖｅｒ：ｒｅＴｙｐｅ要素を追加し、その要素に対して、値が０．２のｎｕｍ属性と、新しいデータ型ｕｎｓｉｇｎｅｄＩｎｔを要素内容として設定する。この一連の処理を、図３０のスキーマに対して実行することにより、図３１に示すスキーマが導出される。
【０１２８】
ステップＳ９１０では、更新種別が“ｄｅｌｅｔｅ”であるかどうか判定する。もし、更新種別が“ｄｅｌｅｔｅ”であると判断したならば、ＸＰａｔｈ式の指す位置に、バージョン番号を値とするｖｅｒ：ｄｅｌｅｔｅ属性を追加する（Ｓ９１１）。図２９の例では、第３列の更新種別が”ｄｅｌｅｔｅ”なので、まずＸＰａｔｈ式”／ｂｏｏｋ／ｐｅｒｓｏｎ＠ｉｄ”の位置のｉｄ属性のスキーマに、０．３を値とするｖｅｒ：ｄｅｌｅｔｅ属性を追加する。この一連の処理を、図３１のスキーマに対して実行することにより、図３２に示すスキーマが導出される。
【０１２９】
Ｓ９１０において、更新種別が”ｄｅｌｅｔｅ”ではないと判断したならば、ＸＰａｔｈ式の指す位置に子要素としてｖｅｒ：ｒｅｎａｍｅ要素を追加する（Ｓ９１２）。そして追加したｖｅｒ：ｒｅｎａｍｅ要素に、バージョン番号を値とするｎｕｍ属性を追加し（Ｓ９１３）、新しい名前を要素内容として設定する（Ｓ９１４）。図２９の例では、第４列の更新種別が“ｒｅｎａｍｅ”なので、まずＸＰａｔｈ式“／ｂｏｏｋ／ｐｅｒｓｏｎ／ｐｈｏｎｅ”の位置の要素に対して、ｖｅｒ：ｒｅｎａｍｅ要素を子要素として追加する。そして追加したｖｅｒ：ｒｅｎａｍｅ要素に、０．３を値とするｎｕｍ属性を追加し、新しい名前“ＰＨＯＮＥ”を要素内容として設定する。この一連の処理を、図３２のスキーマに対して実行することにより、図１２に示すスキーマが導出される。
【０１３０】
以上説明したように、第４実施形態に係る情報処理装置により、更新箇所の差分情報だけを記述したファイルを外部から与えることによって、図１２に示されるようなバージョン管理されたスキーマを自動的に作成することが可能となる。
【０１３１】
（他の実施形態）
以上、本発明の実施形態について詳述したが、本発明は、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１３２】
なお、本発明は、前述した実施形態の機能を実現するプログラムを、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置が、供給されたプログラムコードを読み出して実行することによっても達成される。従って、本発明の機能処理をコンピュータで実現するために、コンピュータにインストールされるプログラムコード自体も本発明の技術的範囲に含まれる。
【０１３３】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【０１３４】
プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク（ＣＤ、ＤＶＤ）、光磁気ディスク、磁気テープ、不揮発性のメモリカード、ＲＯＭなどがある。
【０１３５】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、ホームページから本発明のコンピュータプログラムを供給しても良い。もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明のクレームに含まれるものである。
【０１３６】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布してもよい。そして、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０１３７】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
【０１３８】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現される。
【図面の簡単な説明】
【０１３９】
【図１】バージョン０．１の構造化文書を例示的に示す図である。
【図２】バージョン０．１の構造化文書に対するスキーマを示す図である。
【図３】バージョン０．２の構造化文書を例示的に示す図である。
【図４】バージョン０．２の構造化文書に対するスキーマを示す図である。
【図５】第１実施形態に係る情報処理装置（ＰＣ）を含むシステムの構成を示す図である。
【図６】第１実施形態に係る情報処理装置（ＰＣ）の内部構成を示すブロック図である。
【図７】ｖｅｒ０．１の構造化文書に対応するスキーマを示す図である。
【図８】要素の追加したｖｅｒ０．２の構造化文書に対応するスキーマを示す図である。
【図９】属性を削除したｖｅｒ０．２の構造化文書に対応するスキーマを示す図である。
【図１０】要素の名前を変更したｖｅｒ０．２の構造化文書に対応するスキーマを示す図である。
【図１１】属性のデータ型を変更したｖｅｒ０．２の構造化文書に対応するスキーマを示す図である。
【図１２】複数のバージョンを管理した単一のスキーマデータを例示的に示す図である。
【図１３】構造化文書に対して妥当性検証を行う手順を示すフローチャートである。
【図１４】ＤＯＭツリー生成の詳細フローチャートである。
【図１５】バージョン情報を含むｖｅｒ０．２の構造化文書を示す図である。
【図１６】ｖｅｒ０．１のＤＯＭツリーの一部を示す図である。
【図１７】ｖｅｒ０．２のＤＯＭツリーの一部を示す図である。
【図１８】ｖｅｒ０．３のＤＯＭツリーの一部を示す図である。
【図１９】妥当性検証の処理手順を詳細に示したフローチャートである。
【図２０】第２実施形態に係るＤＯＭツリー生成の全体フローチャートである。
【図２１】ＤＯＭツリー生成における一部処理の詳細フローチャートである。
【図２２】第３実施形態に係るＤＯＭツリー生成の全体フローチャートである。
【図２３】バージョンアップを行ったスキーマを例示的に示す図である。
【図２４】ｖｅｒ０．１のスキーマを示す図である。
【図２５】ｖｅｒ０．２のスキーマを示す図である。
【図２６】ｖｅｒ０．３のスキーマを示す図である。
【図２７】外部から与えた差分情報に基づいて、バージョン管理したスキーマのＤＯＭツリーを作成する手順を示すフローチャートである。
【図２８】Ｓ８０８の詳細な処理手順を示すフローチャートである。
【図２９】外部から与える差分情報ファイルの例を示す図である。
【図３０】外部から与えた差分情報に基づいて、バージョン管理したスキーマを作成する過程における、スキーマの一例を示す図である。
【図３１】外部から与えた差分情報に基づいて、バージョン管理したスキーマを作成する過程における、スキーマの一例を示す図である。
【図３２】外部から与えた差分情報に基づいて、バージョン管理したスキーマを作成する過程における、スキーマの一例を示す図である。
【符号の説明】
【０１４０】
１０１  ＰＣ
１０２  ＬＡＮ
１０３  デジタルカメラ
１０４  プリンタ
１０５  ファイルサーバ
２０１  ＣＰＵ
２０２  ＲＯＭ
２０３  ＲＡＭ
２０４  記憶部（ハードディスク）
２０５  操作部
２０６  表示部
２０７  ＬＡＮ  ｉ／ｆ
２０８  ＬＡＮ回線
２０９  ＵＳＢ  ｉ／ｆ
２１０  ＵＳＢ回線
【図１】
0005339839.tif 000002
【図２】
0005339839.tif 000003
【図３】
0005339839.tif 000004
【図４】
0005339839.tif 000005
【図５】
0005339839.tif 000006
【図６】
0005339839.tif 000007
【図７】
0005339839.tif 000008
【図８】
0005339839.tif 000009
【図９】
0005339839.tif 000010
【図１０】
0005339839.tif 000011
【図１１】
0005339839.tif 000012
【図１２】
0005339839.tif 000013
【図１３】
0005339839.tif 000014
【図１４】
0005339839.tif 000015
【図１５】
0005339839.tif 000016
【図１６】
0005339839.tif 000017
【図１７】
0005339839.tif 000018
【図１８】
0005339839.tif 000019
【図１９】
0005339839.tif 000020
【図２０】
0005339839.tif 000021
【図２１】
0005339839.tif 000022
【図２２】
0005339839.tif 000023
【図２３】
0005339839.tif 000024
【図２４】
0005339839.tif 000025
【図２５】
0005339839.tif 000026
【図２６】
0005339839.tif 000027
【図２７】
0005339839.tif 000028
【図２８】
0005339839.tif 000029
【図２９】
0005339839.tif 000030
【図３０】
0005339839.tif 000031
【図３１】
0005339839.tif 000032
【図３２】
0005339839.tif 000033