JP2019125035A - 検証プログラム、検証装置および検証方法 - Google Patents

Abstract

【課題】複数のＸＭＬ定義ファイルのＸＭＬスキーマ検証において、高速に検証作業を行う。【解決手段】情報処理装置１００は、複数のタグそれぞれのタグ名または定義値と、符号とを対応づけた符号化辞書１３１を用いて、検証対象の複数のＸＭＬ定義ファイルそれぞれを符号化した符号化ＸＭＬ定義ファイル１３３を生成する。情報処理装置１００は、複数のＸＭＬ定義ファイルに対応したＸＭＬスキーマから、符号化辞書１３１を用いて、スキーマ対応の転置インデックス１３２を生成する。情報処理装置１００は、符号化ＸＭＬ定義ファイル１３３を、スキーマ対応の転置インデックス１３２を用いて検証する。【選択図】図３

Description

本発明は、検証プログラムなどに関する。

ＸＭＬ（Extensible Markup Language）形式のデータとしてＸＭＬ定義ファイルがある。ＸＭＬ定義ファイルは、ユーザの資産として登録されるデータのファイルである。かかるＸＭＬ定義ファイルは、ＸＭＬ定義ファイルの論理的構造を制約する定義が記述されたＸＭＬスキーマを用いて検証される。

従来では、検証対象である複数のＸＭＬ定義ファイルの検証は、以下のように行われる。例えば、検証処理は、検証対象であるＸＭＬ定義ファイルごとの検証の度に、ＸＭＬスキーマを読み込み、ＸＭＬ定義ファイルの検証作業を行う。

特開２００７−３４８２７号公報 特開２０１３−２４６５２２号公報

しかしながら、複数のＸＭＬ定義ファイルのＸＭＬスキーマ検証では、高速に検証作業を行うことができないという問題がある。

ここで、複数のＸＭＬ定義ファイルのＸＭＬスキーマ検証では、高速に検証作業を行うことができないという問題について、図１を参照して説明する。図１は、ＸＭＬ定義ファイルのＸＭＬスキーマ検証の参考例を示す図である。図１に示すように、複数のＸＭＬ定義ファイルをＸＭＬスキーマ検証する場合に、検証処理は、ＸＭＬ定義ファイルごとにＸＭＬスキーマを読み込み、読み込んだＸＭＬスキーマを用いてＸＭＬ定義ファイルの検証作業を行う（ｘ１）。したがって、検証処理は、検証するＸＭＬ定義ファイルの数だけ、ＸＭＬスキーマを読み込み、ＸＭＬ定義ファイルの検証作業を繰り返す必要があるため、ＩＯ負荷およびＣＰＵ負荷が高くなる。この結果、複数のＸＭＬ定義ファイルのＸＭＬスキーマ検証では、高速に検証作業を行うことができない。なお、この後、検証に成功したＸＭＬ定義ファイルは、圧縮され（ｘ２）、圧縮データにより登録される。

１つの側面では、複数のＸＭＬ定義ファイルのＸＭＬスキーマ検証において、高速に検証作業を行うことを目的とする。

第１の案では、検証プログラムは、コンピュータに、複数のタグに関しタグ名または定義値と符号とを対応づけた符号化辞書を用いて、検証対象の複数のＸＭＬ定義ファイルそれぞれを符号化した符号化ＸＭＬ定義ファイルを生成し、前記複数のＸＭＬ定義ファイルに対応したスキーマから、前記符号化辞書を用いて、スキーマ対応インデックスを生成し、前記符号化ＸＭＬ定義ファイルを、前記スキーマ対応インデックスを用いて検証する、処理を実行させる。

一つの態様によれば、複数のＸＭＬ定義ファイルのＸＭＬスキーマ検証において、高速に検証作業を行うことができる。

図１は、ＸＭＬ定義ファイルのＸＭＬスキーマ検証の参考例を示す図である。 図２は、実施例に係るＸＭＬ定義ファイルのＸＭＬスキーマ検証の一例を示す図である。 図３は、実施例に係る情報処理装置の構成を示す機能ブロック図である。 図４は、実施例に係る符号化辞書を説明する図である。 図５は、ＸＭＬスキーマの一例を示す図である。 図６は、実施例に係る転置インデックスのデータ構造の一例を示す図である。 図７は、実施例に係るインデックス生成処理の流れの一例を示す図である。 図８Ａは、実施例に係るスキーマ検証処理の流れの一例を示す図（１）である。 図８Ｂは、実施例に係るスキーマ検証処理の流れの一例を示す図（２）である。 図８Ｃは、実施例に係るスキーマ検証処理の流れの一例を示す図（３）である。 図８Ｄは、実施例に係るスキーマ検証処理の流れの一例を示す図（４）である。 図８Ｅは、実施例に係るスキーマ検証処理の流れの一例を示す図（５）である。 図８Ｆは、実施例に係るスキーマ検証処理の流れの一例を示す図（６）である。 図９は、実施例に係るインデックス生成処理のフローチャートの一例を示す図である。 図１０は、実施例に係るインデックス生成処理の具体例を示す図である。 図１１は、実施例に係るスキーマ検証処理のフローチャートの一例を示す図である。 図１２は、実施例に係る開始タグ処理のフローチャートの一例を示す図である。 図１３は、実施例に係るＸＭＬスキーマ検証の効果の一例を示す図である。 図１４は、コンピュータのハードウェア構成例を示す図である。 図１５は、コンピュータで動作するプログラムの構成例を示す図である。 図１６は、実施形態のシステムにおける装置の構成例を示す図である。

以下に、本願の開示する検証プログラム、検証装置および検証方法の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

［実施例に係るＸＭＬ定義ファイルのＸＭＬスキーマ検証の一例］
図２は、実施例に係るＸＭＬ定義ファイルのＸＭＬスキーマ検証の一例を示す図である。

図２に示すように、ＸＭＬスキーマ検証処理は、複数のタグそれぞれのタグ名または定義値と、符号とを対応づけた符号化辞書を用いて、検証対象の複数のＸＭＬ定義ファイルそれぞれを符号化したうえで統合した符号化ＸＭＬ定義ファイルを生成する（ｙ１）。ＸＭＬスキーマ解析処理は、複数のＸＭＬ定義ファイルに対応したＸＭＬスキーマから、符号化辞書を用いて、ＸＭＬスキーマ対応の転置インデックスを生成する（ｙ２）。

そして、ＸＭＬスキーマ検証処理は、符号化ＸＭＬ定義ファイルを、転置インデックスを用いて検証する（ｙ３）。これにより、ＸＭＬスキーマ検証処理は、検証する符号化ＸＭＬ定義ファイルの数である１回だけ、ＸＭＬスキーマ対応の転置インデックスを読み込み、符号化ＸＭＬ定義ファイルの検証作業を行うことで、高速に検証作業を行うことができる。すなわち、ＸＭＬスキーマ検証処理は、複数のＸＭＬ定義ファイルごとにＸＭＬスキーマを読み込んで検証する場合と比較して、ＩＯ負荷およびＣＰＵ負荷が低くなり、高速に検証作業を行うことができる。

なお、ＸＭＬ定義ファイルとは、タグと定義値が混在したファイルである。タグとは、開始記号‘＜’から始まり、終了記号‘＞’で終わる文字列を指し、開始タグおよび終了タグを含む。例えば、ＸＭＬ定義ファイルのデータは、「＜Ｅｎｄｐｏｉｎｔ＞＜ＳｅｒｖｉｃｅＮａｍｅ＞ｓｅｒ０１＜／ＳｅｒｖｉｃｅＮａｍｅ＞＜／Ｅｎｄｐｏｉｎｔ＞」である。このデータの中で、＜Ｅｎｄｐｏｉｎｔ＞が開始タグであり、＜／Ｅｎｄｐｏｉｎｔ＞が終了タグである。このデータの中で、＜ＳｅｒｖｉｃｅＮａｍｅ＞が開始タグであり、＜／ＳｅｒｖｉｃｅＮａｍｅ＞が終了タグである。このデータの中で、「ｓｅｒ０１」は、開始タグから終了タグまでの要素（element）におけるコンテントであり、実施例ではコンテントというものとする。

［実施例に係る情報処理装置の構成］
図３は、実施例に係る情報処理装置の構成を示す機能ブロック図である。図３に示すように、情報処理装置１００は、解析部１１０、検証部１２０および記憶部１３０を有する。

記憶部１３０は、例えばフラッシュメモリ（Flash Memory）やＦＲＡＭ（登録商標）（Ferroelectric Random Access Memory）などの不揮発性の半導体メモリ素子などの記憶装置に対応する。記憶部１３０は、符号化辞書１３１、転置インデックス１３２および符号化ＸＭＬ定義ファイル１３３を有する。なお、転置インデックス１３２は、スキーマ対応インデックスの一例である。

符号化辞書１３１は、ＸＭＬスキーマおよびＸＭＬ定義ファイルを符号化する際に用いられる辞書である。符号化辞書１３１は、一般的なＸＭＬ定義ファイルやＸＭＬスキーマなどを基にして、ＸＭＬ定義ファイルの中に出現するキーワードや定義値の出現頻度を特定し、出現頻度のより高いキーワードや定義値に対して、より短い符号を割り当てた辞書である。ここでいうキーワードとは、例えば、タグのタグ名のことをいう。定義値には、例えば、コンテント、タグのタイプ、データ型、出現回数などが含まれる。

ここで、符号化辞書１３１を、図４を参照して説明する。図４は、実施例に係る符号化辞書を説明する図である。図４には、符号化辞書１３１の一例として、分類ごとに、バイト数、符号化範囲、詳細分類およびＸＭＬデータの具体例が記載されている。

分類には、高頻度キーワード、低頻度キーワードおよびユーザ定義値が示されている。１つの分類としての高頻度キーワードは、出現頻度の高いキーワードのことをいい、詳細分類で表わされる開始タグや終了タグが一例として挙げられる。１つの分類としての低頻度キーワードは、出現頻度の低いキーワードのことをいい、詳細分類で表わされる選択式の定義値や定義値の省略が一例として挙げられる。１つの分類としてのユーザ定義値は、出現頻度の低いキーワードのことをいい、詳細分類で表わされる任意入力の定義値が一例として挙げられる。

バイト数は、圧縮符号である符号コードのバイト数である。高頻度キーワードに対応するバイト数は、「１」である。低頻度キーワードに対応するバイト数は、「２」である。ユーザ定義値に対応するバイト数は、「２」または「３」である。

符号化範囲は、符号化可能な範囲である。高頻度キーワードに対応する符号化範囲は、「００ｈ〜７Ｆｈ」である。低頻度キーワードに対応する符号化範囲は、「８０００ｈ〜８ＦＦＦｈ」である。ユーザ定義値に対応する符号化範囲は、バイト数が「２」である場合には、「９０００ｈ〜ＥＦＦＦｈ」であり、バイト数が「３」である場合には、「Ｆ０００００ｈ〜ＦＦＦＦＦＦｈ」である。

また、符号化範囲は、予めデータ型と対応付けても良い。例えば、「９０００ｈ〜ＥＦＦＦｈ」のうち「９０００ｈ〜ＡＦＦＦｈ」は、文字列型と対応付けても良い。「９０００ｈ〜ＥＦＦＦｈ」のうち「Ｂ０００ｈ〜ＣＦＦＦｈ」は、数値型と対応付けても良い、「９０００ｈ〜ＥＦＦＦｈ」のうち「Ｄ０００ｈ〜ＥＦＦＦｈ」は、日付型と対応付けても良い。

ＸＭＬデータの具体例には、分類ごとのキーワードや定義値の具体例が表わされる。高頻度キーワードに対応するＸＭＬデータの具体例として、＜Ｓｅｑｕｅｎｃｅ＞、＜／Ｓｅｑｕｅｎｃｅ＞、＜Ｅｎｄｐｏｉｎｔ＞、＜／Ｅｎｄｐｏｉｎｔ＞が挙げられる。低頻度キーワードに対応するＸＭＬデータの具体例として、「ＳｙｎｃＳｅｒｖｉｃｅＣａｌｌ」や省略が挙げられる。ユーザ定義値に対応するＸＭＬデータの具体例として、「ｃａｌｃｔｅｓｔ」や「ｓｏａｐ＿ｓｙｎｃ」が挙げられる。なお、高頻度キーワードおよび低頻度キーワードでは、それぞれの符号化範囲の符号コードとそれぞれのキーワードとが予め割り当てられ、登録されている。ユーザ定義値では、それぞれの符号化範囲の符号コードとそれぞれの定義値が予め割り当てられていない。符号化の際に、定義値が出現されたとき、符号コードが割り当てられ、登録される。

一例として、開始タグの一例である「＜Ｓｅｑｕｅｎｃｅ＞」は、「００ｈ」に割り当てられ、開始タグに対応する終了タグである「＜／Ｓｅｑｕｅｎｃｅ＞」は、「４０ｈ」に割り当てられる。また、開始タグの一例である「＜Ｅｎｄｐｏｉｎｔ＞」は、「０５ｈ」に割り当てられ、開始タグに対応する終了タグである「＜／Ｅｎｄｐｏｉｎｔ＞」は、「４５ｈ」に割り当てられる。なお、実施例では、開始タグの符号は、「００ｈ」〜「３Ｆｈ」であり、開始タグに対応する終了タグは、開始タグの符号に「４０ｈ」を加算して得られる値であるとする。

図３に戻って、転置インデックス１３２は、ＸＭＬスキーマに含まれるタグや定義値の出現位置を格納するためのインデックスである。すなわち、転置インデックス１３２とは、ＸＭＬスキーマに含まれるタグおよび定義値について、オフセット（出現位置）ごとの存否をインデックス化したビットマップのことをいう。

転置インデックス１３２のデータ元である「ＸＭＬスキーマ」は、ＸＭＬ定義ファイルの論理的構造を制約する定義が記述されたファイルのことをいい、ＸＭＬ定義ファイルの論理的構造の妥当性を検証するために用いられるファイルである。言い換えれば、ＸＭＬスキーマには、各タグに対するルールが記述されている。

ここで、ＸＭＬスキーマの一例を、図５を参照して説明する。図５は、ＸＭＬスキーマの一例を示す図である。図５に示すように、ＸＭＬスキーマには、タグに対するルールが記述されている。

例えば、“ｅｌｅｍｅｎｔ ｎａｍｅ”（開始タグのタグ名）が“Ｓｅｑｕｅｎｃｅ”である場合には、さらに、「ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ」のタグが記述されている。「ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ」とは、子要素を持つ要素（複雑型）であることを示す。また、「ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ」は、“Ｓｅｑｕｅｎｃｅ”に関する性質を表す。したがって、“Ｓｅｑｕｅｎｃｅ”と“ｃｏｍｐｌｅｘＴｙｐｅ”とは、別のタグによって表現されているが、ＸＭＬ上同じ意味的な単位といえる。

また、“ｅｌｅｍｅｎｔ ｎａｍｅ”（開始タグのタグ名）が“ＳｅｑｕｅｎｃｅＮａｍｅ”である場合には、出現回数やデータ型の情報が記述されている。出現回数の情報として、最小出現回数と最大出現回数とが記述されている。最小出現回数として１回であることを示す「ｍｉｎＯｃｃｕｒｓ＝“１”」、最大出現回数として１回であることを示す「ｍａｘＯｃｃｕｒｓ＝“１”」が記述されている。つまり、出現回数が１回であることを示す。「ｘｓｄ：ｓｔｒｉｎｇ」とは、文字列型であることを示す。

また、別の“ｅｌｅｍｅｎｔ ｎａｍｅ”（開始タグのタグ名）が“Ｄｅｓｃｒｉｐｔｉｏｎ”である場合には、最小出現回数として０回であることを示す「ｍｉｎＯｃｃｕｒｓ＝“０”」、最大出現回数として１回であることを示す「ｍａｘＯｃｃｕｒｓ＝“１”」が記述されている。つまり、出現回数が０〜１回であることを示す。データ型の情報として「ｘｓｄ：ｓｔｒｉｎｇ」が記述されている。

また、“ｅｌｅｍｅｎｔ ｒｅｆ”（開始タグのタグ名）が“ＳｔｅｐＩｎｆｏｒｍａｔｉｏｎ”である場合には、タグ名として同値である“ＳｔｅｐＩｎｆｏｒｍａｔｉｏｎ”が定義されている箇所に、さらにルールが記述されていることを示す。ここでは、後方に記述された“ｅｌｅｍｅｎｔ ｎａｍｅ＝”ＳｔｅｐＩｎｆｏｒｍａｔｉｏｎ”（開始タグのタグ名）から最後尾の“／ｘｓｄ：ｅｌｅｍｅｎｔ”（終了タグのタグ名）までの情報が“ＳｔｅｐＩｎｆｏｒｍａｔｉｏｎ”のルールとしてさらに記述されている。

ここで、ＸＭＬスキーマの転置インデックス１３２のデータ構造の一例を、図６を参照して説明する。図６は、実施例に係る転置インデックスのデータ構造の一例を示す図である。図６に示すように、転置インデックス１３２のＸ軸はＸＭＬスキーマのオフセット（出現位置）を表し、Ｙ軸はタグ領域およびルール領域を備える。タグ領域には、開始タグおよび終了タグのタグ名とともに符号コードが設定される。タグ領域は、それぞれのタグ名について、ＸＭＬスキーマ内の出現位置に関するインデックスの束の情報である。ルール領域には、定義値とともに符号コードが設定される。ルール領域は、それぞれの定義値について、ＸＭＬスキーマ内の出現位置に関するインデックスの束の情報である。各タグ名、各定義値について、ＸＭＬスキーマ内に出現する出現位置には、出現ビットとしてＯＮすなわち２進数の「１」が設定される。各タグ名、各定義値について、ＸＭＬスキーマ内に出現しない位置には、出現ビットとしてＯＦＦすなわち２進数の「０」が設定される。なお、実施形態において、出現ビットが「０」の場合は、かかる「０」の記述を省略する。

一例として、出現位置が０番目に、タグ名として“Ｓｅｑｕｅｎｃｅ”のビットがＯＮ、すなわち２進数の「１」を示す出現ビットが設定されている。また、定義値として“ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ”のビットがＯＮ、すなわち２進数の「１」を示す出現ビットが設定されている。

図３に戻って、符号化ＸＭＬ定義ファイル１３３は、検証対象の複数のＸＭＬ定義ファイルそれぞれを符号化したうえで統合したファイルである。なお、符号化ＸＭＬ定義ファイル１３３は、後述する検証部１２０の符号化処理部１２２によって生成される。

解析部１１０は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、これらによって種々の処理を実行する。そして、解析部１１０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路の電子回路に対応する。または、解析部１１０は、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等の電子回路に対応する。解析部１１０は、字句解析部１１１、符号化処理部１１２およびインデックス生成部１１３を有する。なお、字句解析部１１１、符号化処理部１１２およびインデックス生成部１１３は、第２の生成部の一例である。

字句解析部１１１は、ＸＭＬスキーマをタグごとに字句解析する。ここでいう字句解析とは、タグが示す文字列を、タグ名または定義値に分割することをいう。例えば、字句解析部１１１は、ＸＭＬスキーマを先頭から順番にタグを読み取る。すなわち、字句解析部１１１は、開始記号‘＜’から始まり、終了記号‘＞’で終わる文字列を示すタグを読み取る。そして、字句解析部１１１は、読み取ったタグを字句解析する。

符号化処理部１１２は、タグ名または定義値を符号化する。例えば、符号化処理部１１２は、字句解析部１１１から出力されるタグ名を、符号化辞書１３１を用いて符号コードに符号化する。また、符号化処理部１１２は、字句解析部１１１から出力される定義値を、符号化辞書１３１を用いて符号コードに符号化する。

インデックス生成部１１３は、ＸＭＬスキーマに含まれるタグおよび定義値それぞれについて、タグおよび定義値それぞれの出現位置を格納するための転置インデックス１３２を生成する。なお、１つの出現位置は、必ずしも１つのタグと対応するわけではなく、複数のタグがあってもＸＭＬ上同じ意味的な単位であれば、複数のタグと対応する。例えば、インデックス生成部１１３は、タグに含まれるタグ名および定義値に対して、ＸＭＬスキーマ内の出現位置に対応する転置インデックス１３２の出現位置にビットを立てる。一例として、インデックス生成部１１３は、タグ名の場合には、タグ領域のタグ名に対して、ＸＭＬスキーマ内の出現位置に対応する転置インデックス１３２の出現位置にＯＮを設定する。インデックス生成部１１３は、定義値の場合には、ルール領域の定義値に対して、ＸＭＬスキーマ内の出現位置に対応する転置インデックス１３２の出現位置にＯＮを設定する。なお、該当するタグ名がタグ領域に無い場合には、インデックス生成部１１３は、タグ領域にタグ名とタグ名に対応する符号コードとを追加し、このタグ名に対応するインデックスを追加したうえで、出現位置にビットを立てれば良い。また、ルール領域については、インデックス生成部１１３は、予め、定義値と定義値に対して割り当てられた符号コードとを追加しておき、出現した際に、出現位置にビットを立てれば良い。

ここで、実施例に係るインデックス生成処理の流れの一例を、図７を参照して説明する。図７は、実施例に係るインデックス生成処理の流れの一例を示す図である。

まず、字句解析部１１１が先頭からタグを読み取ったとする。ここでは、＜ｘｓｄ：ｅｌｅｍｅｎｔ ｎａｍｅ＝“Ｓｅｑｕｅｎｃｅ”＞が読み取られたとする。図７に示すように、インデックス生成部１１３は、読み取られたタグのタグ種別が開始タグ且つ“ｅｌｅｍｅｎｔ”であるので、タグ名に対して、ＸＭＬスキーマ内の出現位置に対応する転置インデックス１３２の出現位置に「１」を設定する（ａ１）。ここでは、タグ領域のタグ名“Ｓｅｑｕｅｎｃｅ”に対して、ＸＭＬスキーマ内の出現位置「０」に対応する転置インデックス１３２の出現位置「０」に出現ビット「１」が設定される。なお、タグ名“Ｓｅｑｕｅｎｃｅ”がタグ領域に無い場合には、インデックス生成部１１３は、タグ領域にタグ名と符号化処理部１１２によってタグ名を符号化した符号コードとを追加したうえで、出現位置に出現ビットを設定すれば良い。

次に、字句解析部１１１が次のタグを読み取ったとする。ここでは、＜ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞が読み取られたとする。インデックス生成部１１３は、読み取られたタグのタグ種別が開始タグ且つ“ｃｏｍｐｌｅｘＴｙｐｅ”であるので、“ｃｏｍｐｌｅｘＴｙｐｅ”に対して、ＸＭＬスキーマ内の出現位置に対応する転置インデックス１３２の出現位置に「１」を設定する（ａ２）。ここでは、タグ領域のタグ名“ｃｏｍｐｌｅｘＴｙｐｅ”に対して、ＸＭＬスキーマ内の出現位置「０」に対応する転置インデックス１３２の出現位置「０」に出現ビット「１」が設定される。なお、タグ名“ｃｏｍｐｌｅｘＴｙｐｅ”がタグ領域に無い場合には、インデックス生成部１１３は、タグ領域にタグ名と符号化処理部１１２によってタグ名を符号化した符号コードとを追加したうえで、出現位置に出現ビットを設定すれば良い。

ここで、タグ名“ｃｏｍｐｌｅｘＴｙｐｅ”の出現位置がタグ名“Ｓｅｑｕｅｎｃｅ”と同じ「０」であるのは、“ｃｏｍｐｌｅｘＴｙｐｅ”と“Ｓｅｑｕｅｎｃｅ”とはＸＭＬ上同じ意味的な単位であるからである。すなわち、“Ｓｅｑｕｅｎｃｅ”と“ｃｏｍｐｌｅｘＴｙｐｅ”とは別のタグによって表現されているが、“ｃｏｍｐｌｅｘＴｙｐｅ”は“Ｓｅｑｕｅｎｃｅ”に関する性質を表すので、ＸＭＬ上同じ意味的な単位となる。したがって、“ｃｏｍｐｌｅｘＴｙｐｅ”と“Ｓｅｑｕｅｎｃｅ”とは、同一の出現位置で表現される。

次に、字句解析部１１１が次のタグを読み取ったとする。ここでは、＜ｘｓｄ：ｅｌｅｍｅｎｔ ｎａｍｅ＝“ＳｅｑｕｅｎｃｅＮａｍｅ”ｍｉｎＯｃｃｕｒｓ＝“１”ｍａｘＯｃｃｕｒｓ＝“１”ｔｙｐｅ＝“ｘｓｄ：ｓｔｒｉｎｇ”／＞が読み取られたとする。インデックス生成部１１３は、読み取られたタグのタグ種別が単独タグ且つ“ｅｌｅｍｅｎｔ ｎａｍｅ”であるので、タグ名に対して、ＸＭＬスキーマ内の出現位置に対応する転置インデックス１３２の出現位置に「１」を設定する（ａ３）。ここでは、タグ領域のタグ名“ＳｅｑｕｅｎｃｅＮａｍｅ”に対して、ＸＭＬスキーマ内の出現位置「１」に対応する転置インデックス１３２の出現位置「１」に出現ビット「１」が設定される。

加えて、インデックス生成部１１３は、タグに含まれる出現回数およびデータ型に対して、転置インデックス１３２の出現位置に「１」を設定する。ここでは、出現回数を示す「ｍｉｎＯｃｃｕｒｓ＝“１”ｍａｘＯｃｃｕｒｓ＝“１”」について、ルール領域の「１回」に対して、ＸＭＬスキーマ内の出現位置「１」に対応する転置インデックス１３２の出現位置「１」に出現ビット「１」が設定される（ａ５）。データ型を示す「“ｘｓｄ：ｓｔｒｉｎｇ”」について、ルール領域の「ｘｓｄ：ｓｔｒｉｎｇ」に対して、ＸＭＬスキーマ内の出現位置「１」に対応する転置インデックス１３２の出現位置「１」に出現ビット「１」が設定される（ａ４）。

なお、次の出現位置に存在するタグに含まれる「ｍｉｎＯｃｃｕｒｓ＝“０”ｍａｘＯｃｃｕｒｓ＝“１”」は、出現回数が０〜１回であることを示すので、ルール領域の「０〜１回」に対する転置インデックス１３２に出現ビット「１」が設定される（ａ６）。

このように、インデックス生成部１１３は、順次読み取られたタグから、符号化辞書１３１を用いて、転置インデックス１３２を生成する。

図３に戻って、検証部１２０は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、これらによって種々の処理を実行する。そして、検証部１２０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路の電子回路に対応する。または、検証部１２０は、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等の電子回路に対応する。検証部１２０は、字句解析部１２１、符号化処理部１２２およびスキーマ検証部１２３を有する。なお、字句解析部１２１および符号化処理部１２２は、第１の生成部の一例である。スキーマ検証部１２３は、検証部の一例である。

字句解析部１２１は、複数のＸＭＬ定義ファイルを字句解析する。ここでいう字句解析とは、複数のＸＭＬ定義ファイルに含まれる文字列を、タグ名または定義値に分割することをいう。そして、字句解析部１２１は、字句解析した結果のタグ名または定義値を、順番に符号化処理部１２２に出力する。

符号化処理部１２２は、タグ名または定義値を符号化する。例えば、符号化処理部１２２は、字句解析部１２１から出力されるタグ名を、符号化辞書１３１を用いて符号コードに符号化する。また、符号化処理部１２２は、字句解析部１２１から出力される定義値を、符号化辞書１３１を用いて符号コードに符号化する。そして、符号化処理部１２２は、複数のＸＭＬ定義ファイルそれぞれを符号化した符号化ＸＭＬ定義ファイル１３３を生成する。

スキーマ検証部１２３は、符号化ＸＭＬ定義ファイル１３３を、転置インデックス１３２を用いて検証する。

例えば、スキーマ検証部１２３は、符号化ＸＭＬ定義ファイル１３３から順次１バイトずつ符号コードを読み取る。スキーマ検証部１２３は、読み取った符号コードのコード種別を判定する。ここでいうコード種別とは、例えば、コードが１バイトのコードであるか、２バイトのコードであるかのコードの種別を表す。スキーマ検証部１２３は、コード種別が１バイトのコード種別であると判定した場合には、さらに、タグ種別が開始タグであるか否かを判定する。なお、符号コードのコード種別が１バイトのコード種別であるか否かは、符号化辞書１３１を参照すれば良い。符号コードのタグ種別が開始タグであるか否かは、開始タグの符号が「００ｈ」〜「３Ｆｈ」であると定義した場合には、符号コードが「００ｈ」〜「３Ｆｈ」であるか否かで判定すれば良い。

スキーマ検証部１２３は、読み取った符号コードのタグ種別が開始タグであると判定した場合には、以下の処理を行う。

スキーマ検証部１２３は、スタックが空である場合には、自己の開始タグに対応する終了タグをスタックの最上位にプッシュする。ここでいう「スタック」とは、ＬＩＦＯ（Last In First Out）のデータ構造で要素を保持し、現に検証中の開始タグに対応する終了タグを保持する。保持された要素に検証すべきルールが紐付けられるものとする。そして、スキーマ検証部１２３は、自己の開始タグがｃｏｍｐｌｅｘＴｙｐｅである場合には、転置インデックス１３２を参照し、自己の開始タグと終了タグとで挟まれた出現ビットが立っている要素（タグ領域のタグおよびルール領域のルール）をスタックの最上位の要素と紐付ける。自己の開始タグがｃｏｍｐｌｅｘＴｙｐｅであり、子要素を持つ要素（複雑型）であるからである。スキーマ検証部１２３は、自己の開始タグがｃｏｍｐｌｅｘＴｙｐｅでない場合には、自己の開始タグのデータ型などのタイプをスタックの最上位の要素と紐付ける。

スキーマ検証部１２３は、スタックが空でない場合には、スタックの最上位の要素のタイプがｃｏｍｐｌｅｘＴｙｐｅであれば、転置インデックス１３２を参照し、自己の開始タグがスタックの最上位の要素より先に出現されているかを判定する。スキーマ検証部１２３は、自己の開始タグがスタックの最上位の要素より先であれば、自己の開始タグの位置は妥当であると判断し、スタックの最上位の要素に紐付けられた要素を使って検証する。スキーマ検証部１２３は、自己の開始タグについて、検証に成功した場合には、スタックの最上位の要素に紐付けられた要素を更新する。一例として、スキーマ検証部１２３は、スタックの最上位の要素に紐付けられた要素のうち検証に成功した要素を削除する。そして、スキーマ検証部１２３は、自己の開始タグに対応する終了タグをスタックの最上位にプッシュする。スキーマ検証部１２３は、自己の開始タグがｃｏｍｐｌｅｘＴｙｐｅである場合には、転置インデックス１３２を参照し、自己の開始タグと終了タグとで挟まれた出現ビットが立っている要素（タグ領域のタグおよびルール領域のルール）をスタックの最上位の要素に紐付ける。自己の開始タグがｃｏｍｐｌｅｘＴｙｐｅであり、子要素を持つ要素（複雑型）であるからである。スキーマ検証部１２３は、自己の開始タグがｃｏｍｐｌｅｘＴｙｐｅでない場合には、自己の開始タグのデータ型などのタイプをスタックの最上位の要素と紐付ける。

スキーマ検証部１２３は、読み取った符号コードのタグ種別が終了タグであると判定した場合には、以下の処理を行う。スキーマ検証部１２３は、自己の終了タグの符号コードとスタックの最上位の要素の符号コードとを照合し、一致していれば、自己の終了タグの位置は妥当であると判断し、スタックの最上位の要素のタイプに基づいて、自己の終了タグを検証する。

スキーマ検証部１２３は、読み取った符号コードのコード種別が２，３バイトのコード種別であると判定した場合には、以下の処理を行う。スキーマ検証部１２３は、符号化ＸＭＬ定義ファイル１３３から残りのバイト数の符号コードを読み取る。スキーマ検証部１２３は、読み取った２，３バイト分の符号コードのタイプがスタックの最上位の要素のタイプと一致していれば、自己の２，３バイトコードの検証は妥当であると判断し、スタックの最上位の要素に紐づくタイプを「検証済み」のステータスに更新する。スキーマ検証部１２３は、読み取った２，３バイト分の符号コードがスタックの最上位の要素のタイプと一致していなければ、自己の２，３バイトコードの検証は異常であると判断する。なお、２，３バイト分の符号コードのタイプは、例えば、符号化辞書１３１の符号化範囲に対応付けられるデータ型により判断されれば良い。

ここで、実施例に係るスキーマ検証処理の流れの一例を、図８Ａ〜図８Ｆを参照して説明する。図８Ａ〜図８Ｆは、実施例に係るスキーマ検証処理の流れの一例を示す図である。なお、図８Ａ〜図８Ｆでは、検証対象の符号化ＸＭＬ定義ファイル１３３には、符号コード群として「０５０６９４Ｄ３４６４５」が設定されているものとする。

図８Ａに示すように、スキーマ検証部１２３が、検証対象の先頭から１バイトを読み取る。ここでは、読み取られた１バイトは「０５ｈ」であるとする。スキーマ検証部１２３は、符号化辞書１３１を参照し、読み取られた１バイトの符号コードが高頻度キーワードであり、１バイトのコード種別であると判定する（ｂ１）。また、スキーマ検証部１２３は、符号化辞書１３１を参照し、読み取られた１バイトの符号コードが「００ｈ」〜「３Ｆｈ」であり、タグ種別が開始タグであると判定する。

スキーマ検証部１２３は、読み取られた１バイトの符号コードのタグ種別が開始タグであるので、以下の処理を行う。スキーマ検証部１２３は、スタックＳにはまだ要素が保持されていない（空である）ので、開始タグに対応する終了タグをスタックＳにプッシュする（ｂ２）。ここでは、読み取られた１バイトの符号コードが「０５ｈ」であるので、スキーマ検証部１２３は、「０５ｈ」に「４０ｈ」を加えた「４５ｈ」を終了タグとしてスタックＳにプッシュする。

スキーマ検証部１２３は、転置インデックス１３２を参照し、自己の開始タグがｃｏｍｐｌｅｘＴｙｐｅであると判定する（ｂ３）。そこで、スキーマ検証部１２３は、自己の開始タグがｃｏｍｐｌｅｘＴｙｐｅであることを、自己の開始タグに対応する終了タグに紐付ける。ここでは、一例として、自己の開始タグ「０５ｈ」がｃｏｍｐｌｅｘＴｙｐｅであることは、スタックＳにプッシュされた終了タグ「４５ｈ」に紐付けられる。

スキーマ検証部１２３は、自己の開始タグがｃｏｍｐｌｅｘＴｙｐｅであるので、転置インデックス１３２を参照し、自己の開始タグと終了タグとで挟まれた範囲をスタックＳの最上位の要素と紐付ける（ｂ４）。すなわち、スキーマ検証部１２３は、自己の開始タグと終了タグとで挟まれた出現ビットが立っている要素（タグ領域のタグおよびルール領域のルール）をスタックＳの最上位の要素と紐付ける。ここでは、タグ領域のタグ「０６ｈ」と、ルール領域の「８１ｈ」および「Ａ２ｈ」とが、開始タグと終了タグとで挟まれた範囲としてスタックＳの最上位の要素「４５ｈ」と紐付けられる。「０６ｈ」は、「ＳｅｒｖｉｃｅＮａｍｅ」のタグの符号コードである。「８１ｈ」は、データ型として「ｘｓｄ：ｓｔｒｉｎｇ」のルールの符号コードである。「Ａ２ｈ」は、出現回数として「１回」のルールの符号コードである。

図８Ｂに示すように、スキーマ検証部１２３は、検証対象から次の１バイトを読み取る。ここでは、読み取られた１バイトは「０６ｈ」であるとする。スキーマ検証部１２３は、符号化辞書１３１を参照し、読み取られた１バイトの符号コードが高頻度キーワードであり、１バイトのコード種別であると判定する（ｂ５）。また、スキーマ検証部１２３は、符号化辞書１３１を参照し、読み取られた１バイトの符号コードが「００ｈ」〜「３Ｆｈ」であり、タグ種別が開始タグであると判定する。

スキーマ検証部１２３は、読み取られた１バイトの符号コードのタグ種別が開始タグであるので、以下の処理を行う。スキーマ検証部１２３は、スタックＳには既に要素が保持され、スタックＳの最上位の要素のタイプがｃｏｍｐｌｅｘＴｙｐｅであるので、自己の開始タグの出現位置とスタックＳの最上位の要素の出現位置とを探索する（ｂ６）。ここでは、自己の開始タグ「０６ｈ」が最上位の要素「４５ｈ」より先に出現しているので、自己の開始タグ「０６ｈ」の検証対象内の位置は妥当であると判断する。

さらに、スキーマ検証部１２３は、自己の開始タグを、スタックＳの最上位の要素に紐付けられた要素を用いて検証する（ｂ７）。ここでは、スタックＳの最上位の要素に紐付けられた要素を用いると、自己の開始タグ「０６ｈ」が「１回」出現できるので、自己の開始タグ「０６ｈ」について、「１回」の出現回数は妥当であると判断する。

そこで、スキーマ検証部１２３は、自己の開始タグについて、スタックＳの最上位の要素に紐付けられた要素を更新する（ｂ８）。ここでは、スタックＳの最上位の要素に紐付けられた要素のうち検証に成功した要素「０６ｈ」の列を更新する。図８ｂに示される例では、検証対象はＡ２ｈ（１回）のみであるので、「０６ｈ」に関する検証はここで終了し、０６ｈの列に関連した要素である「０６ｈ」「８１ｈ」および「Ａ２ｈ」が削除される。

そして、スキーマ検証部１２３は、自己の開始タグに対応する終了タグをスタックＳの最上位にプッシュする。加えて、スキーマ検証部１２３は、自己の開始タグがｃｏｍｐｌｅｘＴｙｐｅでないので、スタックＳの最上位の要素に自己の開始タグのタイプを紐付ける（ｂ９）。ここでは、スキーマ検証部１２３は、自己の開始タグ「０６ｈ」に「４０ｈ」を加えた「４６ｈ」を終了タグとしてスタックＳにプッシュする。スキーマ検証部１２３は、スタックＳの最上位の要素「４６ｈ」に自己の開始タグ「０６ｈ」のタイプとして「８１ｈ」（文字列型）を紐付ける。

図８Ｃに示すように、スキーマ検証部１２３は、検証対象から次の１バイトを読み取る。ここでは、読み取られた１バイトは「９４ｈ」であるとする。スキーマ検証部１２３は、符号化辞書１３１を参照し、読み取られた１バイト「９４ｈ」が２バイトのコード種別であると判定するので、２バイト分を読み込む（ｂ１０−１）。読み取られた２バイトは「９４Ｄ３ｈ」であるとする。

スキーマ検証部１２３は、読み取った２バイトの符号コードのタイプとスタックＳの最上位の要素のタイプとを照合し、一致していれば、自己の２バイトの符号コードの検証は妥当であると判断する（ｂ１０−２）。ここでは、自己の２バイトの符号コード「９４Ｄ３ｈ」のタイプは、符号化辞書１３１から文字列型であることがわかるので、スタックＳの最上位の要素のタイプ「ｘｓｄ：ｓｔｒｉｎｇ」と一致する。したがって、スキーマ検証部１２３は、自己の２バイトの符号コード「９４Ｄ３ｈ」の検証は妥当であると判断する。

そして、スキーマ検証部１２３は、一致していれば、スタックＳの最上位の要素に紐づくタイプを「検証済み」のステータスに変更する（ｂ１１）。

図８Ｄに示すように、スキーマ検証部１２３は、検証対象から次の１バイトを読み取る。ここでは、読み取られた１バイトは「４６ｈ」であるとする。スキーマ検証部１２３は、符号化辞書１３１を参照し、読み取られた１バイトの符号コードが高頻度キーワードであり、１バイトのコード種別であると判定する（ｂ１２）。また、スキーマ検証部１２３は、符号化辞書１３１を参照し、読み取られた１バイトの符号コードが「４０ｈ」〜「７Ｆｈ」であり、タグ種別が終了タグであると判定する。

スキーマ検証部１２３は、自己の終了タグの符号コードとスタックＳの最上位の要素の符号コードとを照合し、一致していれば、スタックＳの最上位の要素のタイプがＣｏｍｐｌｅｘＴｙｐｅか、「検証済み」か、それ以外であるか否かを判定する（ｂ１３）。ここでは、自己の終了タグの符号コードとスタックＳの最上位の要素の符号コードとは共に「４６ｈ」であるので、照合は一致する。そして、スタックＳの最上位の要素のタイプは、ＣｏｍｐｌｅｘＴｙｐｅでなく且つ「検証済み」である。したがって、スキーマ検証部１２３は、自己の終了タグの検証は妥当であると判断する。

スキーマ検証部１２３は、スタックＳの最上位の要素をポップする（ｂ１４）。この結果、スタックＳの最上位の要素（符号コード「４６ｈ」）が削除される。そして、スタックＳの最上位の要素は、符号コード「４５ｈ」となる。

図８Ｅに示すように、スキーマ検証部１２３は、検証対象から次の１バイトを読み取る。ここでは、読み取られた１バイトは「４５ｈ」であるとする。スキーマ検証部１２３は、符号化辞書１３１を参照し、読み取られた１バイトの符号コードが高頻度キーワードであり、１バイトのコード種別であると判定する（ｂ１５）。また、スキーマ検証部１２３は、符号化辞書１３１を参照し、読み取られた１バイトの符号コードが「４０ｈ」〜「７Ｆｈ」であり、タグ種別が終了タグであると判定する。

スキーマ検証部１２３は、自己の終了タグの符号コードとスタックＳの最上位の要素の符号コードとを照合し、一致していれば、スタックＳの最上位の要素のタイプがＣｏｍｐｌｅｘＴｙｐｅか、「検証済み」か、それ以外であるか否かを判定する（ｂ１６）。ここでは、自己の終了タグの符号コードとスタックＳの最上位の要素の符号コードとは共に「４５ｈ」であるので、照合は一致する。そして、スタックＳの最上位の要素のタイプは、ＣｏｍｐｌｅｘＴｙｐｅである。そこで、スキーマ検証部１２３は、スタックＳの最上位の要素にまだ検証が済んでいないルール（未検証のルール）が紐づいているか否かを判定する（ｂ１７）。ここでは、スタックＳの最上位の要素に未検証のルールが紐付いていない。したがって、スキーマ検証部１２３は、自己の終了タグの検証は妥当であると判断する。

スキーマ検証部１２３は、スタックＳの最上位の要素をポップする（ｂ１８）。この結果、スタックＳの最上位の要素（符号コード「４５ｈ」）が削除される。

スキーマ検証部１２３は、この時点で符号化ＸＭＬ定義ファイル１３３の末尾に到達し、スタックＳが空なので、検証に成功したと判定する。

図８Ｆは、図８Ｄに対応した、異常終了となる場合のスキーマ検証処理の流れの一例を示す図である。

図８Ｆに示すように、スキーマ検証部１２３は、検証対象から次の１バイト「４６ｈ」を読み取り、１バイトのコード種別であると判定する（ｂ１２）。また、スキーマ検証部１２３は、符号化辞書１３１を参照し、読み取られた１バイトの符号コードが「４０ｈ」〜「７Ｆｈ」であり、タグ種別が終了タグであると判定する。

スキーマ検証部１２３は、自己の終了タグの符号コードとスタックＳの最上位の要素の符号コードとを照合し、一致していれば、スタックＳの最上位の要素のタイプがＣｏｍｐｌｅｘＴｙｐｅか、「検証済み」か、それ以外であるか否かを判定する（ｂ１３´）。ここでは、自己の終了タグの符号コードとスタックＳの最上位の要素の符号コードとは共に「４６ｈ」であるので、照合は一致する。そして、スタックＳの最上位の要素のタイプは、ＣｏｍｐｌｅｘＴｙｐｅでなく、「検証済み」でなく、それ以外である。したがって、スキーマ検証部１２３は、自己の終了タグの検証は妥当でないと判断する。つまり、スキーマ検証部１２３は、スキーマ検証処理が異常終了であると判定する。

［インデックス生成処理のフローチャート］
図９は、実施例に係るインデックス生成処理のフローチャートの一例を示す図である。なお、以下では、図１０に示されるＸＭＬスキーマ、転置インデックス１３２を適宜用いながら説明する。

図９に示すように、インデックス生成部１１３は、転置インデックス１３２を初期化する（ステップＳ１１）。なお、インデックス生成部１１３は、この時点で、転置インデックス１３２のルール領域の定義値に対して符号コードを割り当てる。

インデックス生成部１１３は、ＸＭＬスキーマファイルを入力する(ステップＳ１２）。インデックス生成部１１３は、ＸＭＬスキーマファイルの末尾に到達するまで、ＸＭＬスキーマファイルからタグを読み取る（ステップＳ１３）。

インデックス生成部１１３は、タグ種別が開始タグか、終了タグか、単独タグかを判定する（ステップＳ１４）。タグ種別が開始タグであると判定した場合には（ステップＳ１４；開始タグ）、インデックス生成部１１３は、タグ種別がｃｏｍｐｌｅｘＴｙｐｅか、ｅｌｅｍｅｎｔか、それ以外かを判定する（ステップＳ１５）。

ステップＳ１５において、タグ種別がｅｌｅｍｅｎｔであると判定した場合には（ステップＳ１５；ｅｌｅｍｅｎｔ）、インデックス生成部１１３は、ｎａｍｅ属性の値を転置インデックス１３２にマークする（ステップＳ１７）。なお、インデックス生成部１１３は、転置インデックス１３２のタグ領域にｎａｍｅ属性の値が存在していなければ、符号化処理部１１２を介して、ｎａｍｅ属性の値に対する開始タグと終了タグとの符号コードを割り当てる。ここでは、図１０において、例えば、＜ｘｓｄ：ｅｌｅｍｅｎｔ ｎａｍｅ＝“Ｓｅｑｕｅｎｃｅ”＞のタグが読み取られた場合には、このタグが開始タグであり、タグ種別がｅｌｅｍｅｎｔであるので、以下の処理が行われる。インデックス生成部１１３は、ｎａｍｅ属性の値「Ｓｅｑｕｅｎｃｅ」に対する開始タグと終了タグとの符号コードを「００ｈ」と「４０ｈ」とに割り当て、タグ領域に追加する。インデックス生成部１１３は、転置インデックス１３２について、出現位置として「０」、符号コードとして「００ｈ」のビットに出現ビット「１」をマークする（ｍ１）。そして、インデックス生成部１１３は、次のタグを読み取るべく、ステップＳ１３に移行する。

ステップＳ１５において、タグ種別がｃｏｍｐｌｅｘＴｙｐｅであると判定した場合には（ステップＳ１５；ｃｏｍｐｌｅｘＴｙｐｅ）、インデックス生成部１１３は、ｃｏｍｐｌｅｘＴｙｐｅであることを転置インデックス１３２にマークする（ステップＳ１６）。ここでは、図１０において、例えば、＜ｘｓｄ：ｃｏｍｐｌｅｘＴｙｐｅ＞のタグが読み取られた場合には、このタグが開始タグであり、タグ種別がｃｏｍｐｌｅｘＴｙｐｅであるので、以下の処理が行われる。インデックス生成部１１３は、転置インデックス１３２について、出現位置として「０」、ｃｏｍｐｌｅｘＴｙｐｅの符号コードとして「８０ｈ」のビットに出現ビット「１」をマークする（ｍ２）。出現位置が“Ｓｅｑｕｅｎｃｅ”と同じ「０」であるのは、“Ｓｅｑｕｅｎｃｅ”と“ｃｏｍｐｌｅｘＴｙｐｅ”とが、別のタグによって表現されているが、ＸＭＬ上同じ意味的な単位だからである。そして、インデックス生成部１１３は、転置インデックス１３２上の出現位置のカーソルを１列進めるべく、ステップＳ２６に移行する。

ステップＳ１５において、タグ種別がそれ以外であると判定した場合には（ステップＳ１５；それ以外）、インデックス生成部１１３は、何もしない。ここでは、図１０において、例えば、＜ｘｓｄ：ｓｅｑｕｅｎｃｅ＞のタグが読み取られた場合には、このタグが開始タグであり、タグ種別がｅｌｅｍｅｎｔでなく、ｃｏｍｐｌｅｘＴｙｐｅでないので、インデックス生成部１１３は、何もしない。そして、インデックス生成部１１３は、次のタグを読み取るべく、ステップＳ１３に移行する。

ステップＳ１４において、タグ種別が単独タグであると判定した場合には（ステップＳ１４；単独タグ）、インデックス生成部１１３は、タグの属性（ＸＭＬの属性と同義、以下、同じ）がｎａｍｅか、ｒｅｆかを判定する（ステップＳ１８）。

ステップＳ１８において、タグの属性がｎａｍｅであると判定した場合には（ステップＳ１８；ｎａｍｅ）、インデックス生成部１１３は、ｅｌｅｍｅｎｔ ｎａｍｅを転置インデックス１３２にマークする（ステップＳ１９）。なお、インデックス生成部１１３は、転置インデックス１３２のタグ領域にｅｌｅｍｅｎｔ ｎａｍｅが存在していなければ、符号化処理部１１２を介して、ｅｌｅｍｅｎｔ ｎａｍｅに対する開始タグと終了タグとの符号コードを割り当てる。ここでは、図１０において、例えば、＜ｘｓｄ：ｅｌｅｍｅｎｔ ｎａｍｅ＝“ＳｅｑｕｅｎｃｅＮａｍｅ” ｍｉｎＯｃｃｕｒｓ＝“１” ｍａｘＯｃｃｕｒｓ＝“１” ｔｙｐｅ＝“ｘｓｄ：ｓｔｒｉｎｇ”／＞のタグが読み取られたとする。かかる場合には、このタグが単独タグであり、タグの属性がｎａｍｅであるので、以下の処理が行われる。インデックス生成部１１３は、ｎａｍｅ属性の値「ＳｅｑｕｅｎｃｅＮａｍｅ」に対する単独タグの符号コード「３０ｈ」を割り当て、タグ領域に追加する。インデックス生成部１１３は、転置インデックス１３２について、出現位置として「１」、符号コードとして「３０ｈ」のビットに出現ビット「１」をマークする（ｍ１）。

さらに、インデックス生成部１１３は、出現回数およびタイプを転置インデックス１３２にマークする（ステップＳ２０）。ここでは、図１０において、タグには、「ｍｉｎＯｃｃｕｒｓ＝“１” ｍａｘＯｃｃｕｒｓ＝“１” ｔｙｐｅ＝“ｘｓｄ：ｓｔｒｉｎｇ”」が含まれている。インデックス生成部１１３は、転置インデックス１３２について、出現位置として「１」、出現回数「１回」の符号コードとして「Ａ２ｈ」のビットに出現ビット「１」をマークする（ｍ５）。インデックス生成部１１３は、転置インデックス１３２について、出現位置として「１」、タイプ「ｘｓｄ：ｓｔｒｉｎｇ」の符号コードとして「８１ｈ」のビットに出現ビット「１」をマークする（ｍ４）。そして、インデックス生成部１１３は、転置インデックス１３２上の出現位置のカーソルを１列進めるべく、ステップＳ２６に移行する。

ステップＳ１８において、タグの属性がｒｅｆであると判定した場合には（ステップＳ１８；ｒｅｆ）、インデックス生成部１１３は、出現回数を転置インデックス１３２にマークする（ステップＳ２１）。ここでは、図１０において、例えば、＜ｘｓｄ：ｅｌｅｍｅｎｔ ｒｅｆ＝“ＳｔｅｐＩｎｆｏｒｍａｔｉｏｎ” ｍｉｎＯｃｃｕｒｓ＝“０” ｍａｘＯｃｃｕｒｓ＝“ｕｎｂｏｕｎｄｅｄ”／＞のタグが読み取られたとする。かかる場合には、このタグが単独タグであり、タグの属性がｒｅｆであるので、以下の処理が行われる。タグには、「ｍｉｎＯｃｃｕｒｓ＝“０” ｍａｘＯｃｃｕｒｓ＝“ｕｎｂｏｕｎｄｅｄ”」が含まれている。インデックス生成部１１３は、転置インデックス１３２について、出現位置として「３」、出現回数「０回以上」の符号コードとして「Ａ０ｈ」のビットに出現ビット「１」をマークする（ｍ６）。

さらに、インデックス生成部１１３は、現在の行を記憶し、同じ定義値がｅｌｅｍｅｎｔ ｎａｍｅで定義されている箇所を探してＸＭＬスキーマファイル内の行に遷移を行う（ステップＳ２２）。ここでは、図１０において、例えば、出現位置がｋの箇所に、定義値として“ＳｔｅｐＩｎｆｏｒｍａｔｉｏｎ”を示す開始タグが発見される。インデックス生成部１１３は、＜ｘｓｄ：ｅｌｅｍｅｎｔ ｎａｍｅ＝“ＳｔｅｐＩｎｆｏｒｍａｔｉｏｎ”＞のタグの箇所に行を移動する。

そして、インデックス生成部１１３は、出現位置がｋの箇所の開始タグから出現位置がｌの箇所の終了タグまでの範囲について、Ｓ１３〜Ｓ２６のループを再帰的に繰り返す（ステップＳ２３）。ステップＳ２２で記憶された遷移元の行に移動する（ステップＳ２３−１）。そして、インデックス生成部１１３は、転置インデックス１３２上の出現位置のカーソルを１列進めるべく、ステップＳ２６に移行する。

ステップＳ１４において、タグ種別が終了タグであると判定した場合には（ステップＳ１４；終了タグ）、インデックス生成部１１３は、タグ種別がｅｌｅｍｅｎｔか、ｅｌｅｍｅｎｔ以外かを判定する（ステップＳ２４）。

ステップＳ２４において、タグ種別がｅｌｅｍｅｎｔであると判定した場合には（ステップＳ２４；ｅｌｅｍｅｎｔ）、インデックス生成部１１３は、終了タグであることを転置インデックス１３２にマークする（ステップＳ２５）。

ここでは、図１０において、一例として、出現位置がｌである箇所で、＜／ｘｓｄ：ｅｌｅｍｅｎｔ＞のタグが読み取られた場合には、このタグが終了タグであり、タグ種別がｅｌｅｍｅｎｔであるので、以下の処理が行われる。インデックス生成部１１３は、転置インデックス１３２について、出現位置として「ｌ」、終了タグの符号コードとして「４１ｈ」のビットに出現ビット「１」をマークする（ｍ７）。そして、ＸＭＬスキーマファイル内の行の位置が呼び出し元（ｒｅｆ）に戻る。

また、別の一例として、出現位置がｎである箇所で、＜／ｘｓｄ：ｅｌｅｍｅｎｔ＞のタグが読み取られた場合には、このタグが終了タグであり、タグ種別がｅｌｅｍｅｎｔであるので、以下の処理が行われる。インデックス生成部１１３は、転置インデックス１３２について、出現位置として「ｎ」、終了タグの符号コードとして「４０ｈ」のビットに出現ビット「１」をマークする（ｍ８）。

そして、インデックス生成部１１３は、転置インデックス１３２上の出現位置のカーソルを１列進めるべく、ステップＳ２６に移行する。

ステップＳ２４において、タグ種別がｅｌｅｍｅｎｔでないと判定した場合には（ステップＳ２４；ｅｌｅｍｅｎｔ以外）、インデックス生成部１１３は、何もしない。ここでは、図１０において、例えば、＜／ｘｓｄ：ｓｅｑｕｅｎｃｅ＞のタグが読み取られた場合には、このタグが終了タグであり、タグ種別がｅｌｅｍｅｎｔでないので、インデックス生成部１１３は、何もしない。そして、インデックス生成部１１３は、次のタグを読み取るべく、ステップＳ１３に移行する。

そして、ステップＳ１３において、インデックス生成部１１３は、ＸＭＬスキーマファイルの末尾に到達すると、インデックス生成処理を終了する。

［スキーマ検証処理のフローチャート］
図１１は、実施例に係るスキーマ検証処理のフローチャートの一例を示す図である。なお、ＸＭＬ定義ファイルは、符号化処理部１２２によって符号化処理され、符号化ＸＭＬ定義ファイル１３３に変換されたものとする。

スキーマ検証部１２３は、空のスタックＳを記憶部１３０に用意する（ステップＳ３１）。符号化ＸＭＬ定義ファイル１３３を受け取ったスキーマ検証部１２３は、符号化ＸＭＬ定義ファイル１３３の末尾に到達するまで、１バイトを読み取る（ステップＳ３２）。

１バイトを読み取ったスキーマ検証部１２３は、読み取った１バイトの符号コードのコード種別を判定する（ステップＳ３３）。コード種別が１バイトのコード種別であると判定した場合には（ステップＳ３３；１バイトコード）、スキーマ検証部１２３は、タグ種別を判定する（ステップＳ３４）。

タグ種別が開始タグであると判定した場合には（ステップＳ３４；開始タグ）、スキーマ検証部１２３は、開始タグ処理を実行する（ステップＳ３５）。なお、開始タグ処理のフローチャートは、後述する。そして、スキーマ検証部１２３は、次の１バイトを読み取るべく、ステップＳ４４を介してステップＳ３２に移行する。

一方、タグ種別が終了タグであると判定した場合には（ステップＳ３４；終了タグ）、スキーマ検証部１２３は、当該終了タグの符号コードとスタックＳの最上位の要素とを比較する（ステップＳ３９）。終了タグの符号コードとスタックＳの最上位の要素とが不一致である場合には（ステップＳ３９；不一致）、スキーマ検証部１２３は、ＸＭＬ定義ファイルが異常であると判断し、スキーマ検証処理を異常終了する。

終了タグの符号コードとスタックＳの最上位の要素とが一致する場合には（ステップＳ３９；一致）、スキーマ検証部１２３は、スタックＳの最上位の要素のタイプを判定する（ステップＳ４０）。最上位のタイプが「検証済み」であると判定した場合には（ステップＳ４０；「検証済み」）、スキーマ検証部１２３は、スタックＳの要素をポップすべく、ステップＳ４２に移行する。

最上位のタイプがｃｏｍｐｌｅｘＴｙｐｅであると判定した場合には（ステップＳ４０；ｃｏｍｐｌｅｘＴｙｐｅ）、スキーマ検証部１２３は、未検証のルールが有るか否かを判定する（ステップＳ４１）。未検証のルールが有ると判定した場合には（ステップＳ４１；有る）、スキーマ検証部１２３は、ＸＭＬ定義ファイルが異常であると判断し、スキーマ検証処理を異常終了する。

一方、未検証のルールが無いと判定した場合には（ステップＳ４１；無い）、スキーマ検証部１２３は、スタックＳの要素をポップすべく、ステップＳ４２に移行する。

最上位のタイプがｃｏｍｐｌｅｘＴｙｐｅでなく、「検証済み」でなく、それ以外である場合には（ステップＳ４０；それ以外）、スキーマ検証部１２３は、ＸＭＬ定義ファイルが異常であると判断し、スキーマ検証処理を異常終了する。

ステップＳ４２において、スキーマ検証部１２３は、スタックＳの最上位の要素をポップする（ステップＳ４２）。そして、スキーマ検証部１２３は、次の１バイトを読み取るべく、ステップＳ４４を介してステップＳ３２に移行する。

ステップＳ３３において、コード種別が２，３バイトのコード種別であると判定した場合には（ステップＳ３３；２，３バイトコード）、スキーマ検証部１２３は、以下の処理を行う（ステップＳ３６）。スキーマ検証部１２３は、２バイトのコード種別ならば、１バイトを追加で読み取る。スキーマ検証部１２３は、３バイトのコード種別ならば、２バイトを追加で読み取る。

そして、スキーマ検証部１２３は、スタックＳの最上位の要素のタイプが非ｃｏｍｐｌｅｘＴｙｐｅ、かつ現符号コードのタイプと一致するか否かを判定する（ステップＳ３７）。一致すると判定した場合には（ステップＳ３７；Ｙｅｓ）、スキーマ検証部１２３は、スタックＳの最上位の要素のタイプを「検証済み」のステータスに更新する（ステップＳ３８）。そして、スキーマ検証部１２３は、次の１バイトを読み取るべく、ステップＳ４４を介してステップＳ３２に移行する。

一方、一致しないと判定した場合には（ステップＳ３７；Ｎｏ）、スキーマ検証部１２３は、ＸＭＬ定義ファイルが異常であると判断し、スキーマ検証処理を異常終了する。

ステップＳ４４の終了後、スキーマ検証部１２３は、スタックＳが空であるか否かを判定する（ステップＳ４３）。スタックＳが空である、すなわちデータが無いと判定した場合には（ステップＳ４３；Ｙｅｓ）、スキーマ検証部１２３は、ＸＭＬ定義ファイルが正常であると判断し、スキーマ検証処理を正常終了する。

一方、スタックＳが空でない、すなわちデータが有ると判定した場合には（ステップＳ４３；Ｎｏ）、スキーマ検証部１２３は、ＸＭＬ定義ファイルが異常であると判断し、スキーマ検証処理を異常終了する。

［開始タグ処理のフローチャート］
図１２は、実施例に係る開始タグ処理のフローチャートの一例を示す図である。

図１２に示すように、開始タグの符号コードを受け付けたスキーマ検証部１２３は、スタックＳが空であるか否かを判定する（ステップＳ５０）。なお、以降では、開始タグの符号コードを開始タグと略記する場合がある。スタックＳが空であると判定した場合には（ステップＳ５０；Ｙｅｓ）、スキーマ検証部１２３は、ステップＳ５６に移行する。

一方、スタックＳが空でないと判定した場合には（ステップＳ５０；Ｎｏ）、スキーマ検証部１２３は、スタックＳの最上位の要素のタイプを判定する（ステップＳ５１）。スタックＳの最上位の要素のタイプがｃｏｍｐｌｅｘＴｙｐｅでないと判定した場合には（ステップＳ５１；非ｃｏｍｐｌｅｘＴｙｐｅ）、スキーマ検証部１２３は、ＸＭＬ定義ファイルが異常であると判断し、スキーマ検証処理を異常終了する。

スタックＳの最上位の要素のタイプがｃｏｍｐｌｅｘＴｙｐｅであると判定した場合には（ステップＳ５１；ｃｏｍｐｌｅｘＴｙｐｅ）、スキーマ検証部１２３は、以下の処理を行う。スキーマ検証部１２３は、転置インデックス１３２上を、自己の開始タグかスタックの最上位の要素が出現するまで走査する(ステップＳ５２)。

スキーマ検証部１２３は、自己の開始タグが先に出現したか否かを判定する（ステップＳ５３）。自己の開始タグが先に出現しないと判定した場合には（ステップＳ５３；Ｎｏ）、スキーマ検証部１２３は、ＸＭＬ定義ファイルが異常であると判断し、スキーマ検証処理を異常終了する。

一方、自己の開始タグが先に出現したと判定した場合には（ステップＳ５３；Ｙｅｓ）、スキーマ検証部１２３は、スタックＳの最上位の要素のルールを用いて検証する（ステップＳ５４Ａ）。検証の結果、スキーマ検証部１２３は、検証がＯＫであるか否かを判定する（ステップＳ５４Ｂ）。検証がＯＫでないと判定した場合には（ステップＳ５４Ｂ；Ｎｏ）、スキーマ検証部１２３は、ＸＭＬ定義ファイルが異常であると判断し、スキーマ検証処理を異常終了する。

一方、検証がＯＫであると判定した場合には（ステップＳ５４Ｂ；Ｙｅｓ）、スキーマ検証部１２３は、スタックＳの最上位の要素に紐付いているルールを更新する（ステップＳ５５）。そして、スキーマ検証部１２３は、ステップＳ５６に移行する。

ステップＳ５６において、スキーマ検証部１２３は、自己の開始タグに対応する終了タグをスタックＳにプッシュする（ステップＳ５６）。そして、スキーマ検証部１２３は、自己の開始タグのタイプを判定する（ステップＳ５７）。自己の開始タグのタイプがｃｏｍｐｌｅｘＴｙｐｅであると判定した場合には（ステップＳ５７；ｃｏｍｐｌｅｘＴｙｐｅ）、スキーマ検証部１２３は、以下の処理を行う。スキーマ検証部１２３は、自己の開始タグから終了タグまでのルール情報を転置インデックス１３２から抽出し、スタックＳの最上位の要素に紐付ける（ステップＳ５８）。そして、スキーマ検証部１２３は、開始タグ処理を終了する。

自己の開始タグのタイプがｃｏｍｐｌｅｘＴｙｐｅでないと判定した場合には（ステップＳ５７；非ｃｏｍｐｌｅｘＴｙｐｅ）、スキーマ検証部１２３は、以下の処理を行う。スキーマ検証部１２３は、スタックＳの最上位の要素に自己の開始タグのタイプを紐付ける（ステップＳ５９）。そして、スキーマ検証部１２３は、開始タグ処理を終了する。

［実施例の効果］
このようにして、上記実施例では、情報処理装置１００が、複数のタグそれぞれのタグ名または定義値と、符号とを対応づけた符号化辞書１３１を用いて、検証対象の複数のＸＭＬ定義ファイルそれぞれを符号化した符号化ＸＭＬ定義ファイル１３３を生成する。情報処理装置１００は、複数のＸＭＬ定義ファイルに対応したＸＭＬスキーマから、符号化辞書１３１を用いて、転置インデックス１３２を生成する。そして、情報処理装置１００は、符号化ＸＭＬ定義ファイル１３３を、転置インデックス１３２を用いて検証する。かかる構成によれば、情報処理装置１００は、検証対象の複数のＸＭＬ定義ファイルごとに、スキーマを読み込み、検証することなく、高速に検証作業を行うことができる。

ここで、実施例に係るＸＭＬスキーマ検証の効果の一例を、図１３を参照して説明する。図１３は、実施例に係るＸＭＬスキーマ検証の効果の一例を示す図である。図１３に示すように、複数のＸＭＬ定義ファイルを圧縮する場合に、参考例の検証処理は、ＸＭＬスキーマ検証を行う際に、圧縮した圧縮ファイルを伸長する。そして、検証処理は、伸長した複数のＸＭＬ定義ファイルごとにＸＭＬスキーマを読み込み、読み込んだＸＭＬスキーマを用いてそれぞれのＸＭＬ定義ファイルの検証作業を行う。したがって、参考例の検証処理は、伸長処理に加えて、ＸＭＬ定義ファイルの数だけＸＭＬスキーマを読み込み、それぞれのＸＭＬ定義ファイルの検証作業を繰り返す必要があるため、高速に検証作業を行うことができない。

これに対して、複数のＸＭＬ定義ファイルを圧縮する場合に、実施例の検証処理は、ＸＭＬスキーマ検証を行う際に、符号化した符号化ＸＭＬ定義ファイル１３３を、ＸＭＬスキーマ対応の符号化した転置インデックス１３２を用いて検証する。したがって、実施例の検証処理は、参考例の検証処理と比較して、ＩＯ負荷およびＣＰＵ負荷が低くなり、高速に検証作業を行うことができる。

また、上記実施例では、情報処理装置１００は、ＸＭＬスキーマに含まれるタグのタグ名および定義値それぞれについて、符号化辞書１３１を用いて、タグ名および定義値それぞれのＸＭＬスキーマ内の出現位置に関する転置インデックス１３２を生成する。かかる構成によれば、情報処理装置１００は、ＸＭＬスキーマに含まれるタグのタグ名および定義値それぞれを符号化し、符号化したタグ名および定義値について、ＸＭＬスキーマ内の出現位置に関する転置インデックス１３２を生成する。この結果、情報処理装置１００は、ＸＭＬ定義ファイルを符号化したまま、転置インデックス１３２を用いて検証作業を行うことができる。

また、上記実施例では、タグの定義値は、データ型および出現回数を含む。これにより、情報処理装置１００は、タグの定義値をタグのルールとして転置インデックス１３２に設定することができ、転置インデックス１３２を用いてＸＭＬ定義ファイルの検証作業を正確に行うことができる。

また、上記実施例では、情報処理装置１００は、符号化ＸＭＬ定義ファイル１３３から検証対象として一纏まりの符号化データを抽出する。情報処理装置１００は、転置インデックス１３２を用いて、抽出した符号化データの開始の符号に対応する第１の出現位置と、開始の符号から得られる終了の符号に対応する第２の出現位置とを抽出する。そして、情報処理装置１００は、第１の出現位置と第２の出現位置との間の転置インデックス１３２のインデックスを用いて、検証対象として抽出された一纏まりの符号化データを検証する。かかる構成によれば、情報処理装置１００は、１回だけ転置インデックス１３２を読み込むと、読み込んだ転置インデックス１３２を用いて複数の一纏まりの符号化データを検証することができ、高速に検証作業を行うことができる。

［その他］
なお、検証部１２０の符号化処理部１２２が、複数のＸＭＬ定義ファイルそれぞれを符号化した符号化ＸＭＬ定義ファイル１３３を生成すると説明した。しかしながら、複数のＸＭＬ定義ファイルそれぞれを符号化した符号化ＸＭＬ定義ファイル１３３を生成する処理は、検証部１２０で行わなくても良く、解析部１１０で行っても良い。また、複数のＸＭＬ定義ファイルそれぞれを符号化した符号化ＸＭＬ定義ファイル１３３を生成する処理は、別の機能部で行っても良い。すなわち、複数のＸＭＬ定義ファイルそれぞれを符号化した符号化ＸＭＬ定義ファイル１３３を生成する処理は、検証する際に行われても良いし、検証する前に予め行われていても良い。

また、図示した装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、装置の分散・統合の具体的態様は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、スキーマ検証部１２３は、コード種別が１バイトコードである場合の検証部と、コード種別が２，３バイトコードである場合の検証部と、コード種別が空である場合の検証部とを分散しても良い。また、スキーマ検証部１２３は、スキーマ検証処理と、開始タグ処理とを分散しても良い。また、解析部１１０は、字句解析部１１１と符号化処理部１１２とを統合しても良い。また、検証部１２０は、字句解析部１２１と符号化処理部１２２とを統合しても良い。また、記憶部１３０を情報処理装置１００の外部装置としてネットワーク経由で接続するようにしても良い。

［情報処理装置のハードウェア構成］
下記に、上述の実施形態に用いられるハードウェア及びソフトウェアについて説明する。図１４は、コンピュータのハードウェア構成例を示す図である。コンピュータ１は、例えば、プロセッサ３０１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）３０２、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）３０３、ドライブ装置３０４、記憶媒体３０５、入力インターフェース（Ｉ／Ｆ）３０６、入力デバイス３０７、出力インターフェース（Ｉ／Ｆ）３０８、出力デバイス３０９、通信インターフェース（Ｉ／Ｆ）３１０、ＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）インターフェース（Ｉ／Ｆ）３１１およびバス３１２などを含む。それぞれのハードウェアはバス３１２を介して接続されている。

ＲＡＭ３０２は読み書き可能なメモリ装置であって、例えば、ＳＲＡＭ（Ｓｔａｔｉｃ ＲＡＭ）やＤＲＡＭ（Ｄｙｎａｍｉｃ ＲＡＭ）などの半導体メモリ、またはＲＡＭでなくてもフラッシュメモリなどが用いられる。ＲＯＭ３０３は、ＰＲＯＭ（Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）なども含む。ドライブ装置３０４は、記憶媒体３０５に記録された情報の読み出しか書き込みかの少なくともいずれか一方を行なう装置である。記憶媒体３０５は、ドライブ装置３０４によって書き込まれた情報を記憶する。記憶媒体３０５は、例えば、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などのフラッシュメモリ、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）、ブルーレイディスクなどの記憶媒体である。また、例えば、コンピュータ１は、複数種類の記憶媒体それぞれについて、ドライブ装置３０４及び記憶媒体３０５を設ける。

入力インターフェース３０６は、入力デバイス３０７と接続されており、入力デバイス３０７から受信した入力信号をプロセッサ３０１に伝達する回路である。出力インターフェース３０８は、出力デバイス３０９と接続されており、出力デバイス３０９に、プロセッサ３０１の指示に応じた出力を実行させる回路である。通信インターフェース３１０はネットワーク３を介した通信の制御を行なう回路である。通信インターフェース３１０は、例えばネットワークインターフェースカード（ＮＩＣ）などである。ＳＡＮインターフェース３１１は、ストレージエリアネットワークによりコンピュータ１と接続された記憶装置との通信の制御を行なう回路である。ＳＡＮインターフェース３１１は、例えばホストバスアダプタ（ＨＢＡ）などである。

入力デバイス３０７は、操作に応じて入力信号を送信する装置である。入力信号は、例えば、キーボードやコンピュータ１の本体に取り付けられたボタンなどのキー装置や、マウスやタッチパネルなどのポインティングデバイスである。出力デバイス３０９は、コンピュータ１の制御に応じて情報を出力する装置である。出力デバイス３０９は、例えば、ディスプレイなどの画像出力装置（表示デバイス）や、スピーカーなどの音声出力装置などである。また、例えば、タッチスクリーンなどの入出力装置が、入力デバイス３０７及び出力デバイス３０９として用いられる。また、入力デバイス３０７及び出力デバイス３０９は、コンピュータ１と一体になっていても良いし、コンピュータ１に含まれず、例えば、コンピュータ１に外部から接続する装置であっても良い。

例えば、プロセッサ３０１は、ＲＯＭ３０３や記憶媒体３０５に記憶されたプログラムをＲＡＭ３０２に読み出し、読み出されたプログラムの手順に従って解析部１１０および検証部１２０の処理を行なう。その際にＲＡＭ３０２はプロセッサ３０１のワークエリアとして用いられる。記憶部１３０の機能は、ＲＯＭ３０３および記憶媒体３０５がプログラムファイル（後述のアプリケーションプログラム２４、ミドルウェア２３およびＯＳ２２など）やデータファイル（例えば、符号化辞書１３１、転置インデックス１３２、符号化ＸＭＬ定義ファイル１３３など）を記憶し、ＲＡＭ３０２がプロセッサ３０１のワークエリアとして用いられることによって実現される。プロセッサ３０１が読み出すプログラムについては、図１５を用いて説明する。

図１５は、コンピュータで動作するプログラムの構成例を示す図である。コンピュータ１において、図１４に示すハードウェア群（ＨＷ）２１（３０１〜３１２）の制御を行なうＯＳ（オペレーティング・システム）２２が動作する。ＯＳ２２に従った手順でプロセッサ３０１が動作して、ハードウェア群（ＨＷ）２１の制御・管理が行なわれることにより、アプリケーションプログラム（ＡＰ）２４やミドルウェア（ＭＷ）２３に従った処理がハードウェア群２１で実行される。さらに、コンピュータ１において、ミドルウェア（ＭＷ）２３またはアプリケーションプログラム（ＡＰ）２４が、ＲＡＭ３０２に読み出されてプロセッサ３０１により実行される。

プロセッサ３０１が、解析機能が呼び出された場合に、ミドルウェア２３またはアプリケーションプログラム２４の少なくとも一部に基づく処理を行なうことにより、（それらの処理をＯＳ２２に基づいてハードウェア群２１を制御して）解析部１１０の機能が実現される。プロセッサ３０１が、検証機能が呼び出された場合に、ミドルウェア２３またはアプリケーションプログラム２４の少なくとも一部に基づく処理を行なうことにより、（それらの処理をＯＳ２２に基づいてハードウェア群２１を制御して）検証部１２０の機能が実現される。解析機能および検証機能は、アプリケーションプログラム２４自体に含まれても良いし、アプリケーションプログラム２４に従って呼び出されることで実行されるミドルウェア２３の一部であっても良い。

図１６は、実施形態のシステムにおける装置の構成例を示す図である。図１６のシステムは、コンピュータ１ａ、コンピュータ１ｂ、基地局２およびネットワーク３を含む。コンピュータ１ａは、無線または有線の少なくとも一方により、コンピュータ１ｂと接続されたネットワーク３に接続している。

図３に示す解析部１１０と検証部１２０とは、図１６に示すコンピュータ１ａとコンピュータ１ｂとのいずれに含まれても良い。コンピュータ１ｂが解析部１１０の機能を含み、コンピュータ１ａが検証部１２０の機能を含んでも良いし、コンピュータ１ａが解析部１１０の機能を含み、コンピュータ１ｂが検証部１２０の機能を含んでも良い。また、コンピュータ１ａとコンピュータ１ｂとの双方が、解析部１１０の機能および検証部１２０の機能を備えても良い。

１００ 情報処理装置
１１０ 解析部
１１１ 字句解析部
１１２ 符号化処理部
１１３ インデックス生成部
１２０ 検証部
１２１ 字句解析部
１２２ 符号化処理部
１２３ スキーマ検証部
１３０ 記憶部
１３１ 符号化辞書
１３２ 転置インデックス
１３３ 符号化ＸＭＬ定義ファイル

Claims (6)

1. コンピュータに、
   複数のタグそれぞれのタグ名または定義値と、符号とを対応づけた符号化辞書を用いて、検証対象の複数のＸＭＬ定義ファイルそれぞれを符号化した符号化ＸＭＬ定義ファイルを生成し、
   前記複数のＸＭＬ定義ファイルに対応したスキーマから、前記符号化辞書を用いて、スキーマ対応インデックスを生成し、
   前記符号化ＸＭＬ定義ファイルを、前記スキーマ対応インデックスを用いて検証する
   処理を実行させる検証プログラム。
2. 前記スキーマ対応インデックスを生成する処理は、前記スキーマに含まれるタグのタグ名および定義値それぞれについて、前記符号化辞書を用いて、前記タグ名および定義値それぞれの前記スキーマ内の出現位置に関するスキーマ対応インデックスを生成する
   処理を実行させる請求項１に記載の検証プログラム。
3. 前記タグの定義値は、データ型および出現回数を含む
   ことを特徴とする請求項１または請求項２に記載の検証プログラム。
4. 前記検証する処理は、
   前記符号化ＸＭＬ定義ファイルから検証対象として一纏まりの符号化データを抽出し、
   前記スキーマ対応インデックスを用いて、抽出した符号化データの開始の符号に対応する第１の出現位置と、前記開始の符号から得られる終了の符号に対応する第２の出現位置とを抽出し、
   前記第１の出現位置と前記第２の出現位置との間の前記スキーマ対応インデックスのインデックスを用いて、前記検証対象として抽出された前記一纏まりの符号化データを検証する
   ことを特徴とする請求項１に記載の検証プログラム。
5. 複数のタグそれぞれのタグ名または定義値と、符号とを対応づけた符号化辞書を用いて、検証対象の複数のＸＭＬ定義ファイルそれぞれを符号化した符号化ＸＭＬ定義ファイルを生成する第１の生成部と、
   前記複数のＸＭＬ定義ファイルに対応したスキーマから、前記符号化辞書を用いて、スキーマ対応インデックスを生成する第２の生成部と、
   前記符号化ＸＭＬ定義ファイルを、前記スキーマ対応インデックスを用いて検証する検証部と、
   を有する検証装置。
6. コンピュータが、
   複数のタグそれぞれのタグ名または定義値と、符号とを対応づけた符号化辞書を用いて、検証対象の複数のＸＭＬ定義ファイルそれぞれを符号化した符号化ＸＭＬ定義ファイルを生成し、
   前記複数のＸＭＬ定義ファイルに対応したスキーマから、前記符号化辞書を用いて、スキーマ対応インデックスを生成し、
   前記符号化ＸＭＬ定義ファイルを、前記スキーマ対応インデックスを用いて検証する
   処理を実行する検証方法。

Images