JP2010026857A - スキーマ変換装置、プログラム及びスキーマ生成方法 - Google Patents

Abstract

【課題】 制約条件の厳しいスキーマを効率よく生成すること。
【解決手段】 探索部１２３は、サンプルデータ記憶領域１１４に記憶されているサンプルデータを探索し、各々の要素を特定する。そして、制限候補情報更新部１２４は、特定した要素を妥当と判断することのできる最も厳しい制約条件を求め、制限候補として制限候補情報記憶領域１１５に記憶する。スキーマ変換部１２５は、制限候補情報記憶領域１１５に記憶されている制限候補のうち、設定情報記憶領域１１２に記憶されている設定情報で、制限が許可されているものを特定して、オリジナルスキーマに適用して、変換後スキーマを生成する。
【選択図】図１

Description

本発明は、スキーマ文書を生成する技術に関する。

構造化文書を記述するための代表的な言語にＸＭＬ（Extensible Markup Language）があり、ＸＭＬで記述された構造化文書をＸＭＬ文書という。

ＸＭＬ文書が満たすべき制約条件は、通常、スキーマ文書によって定義される。そして、ＸＭＬ文書がスキーマ文書で定義された制約条件を満たしていることを確認する処理を、スキーマ検証という。スキーマ検証において、ＸＭＬ文書が、スキーマ文書の持つ制約条件を満たしている場合に、ＸＭＬ文書はスキーマ文書に対して妥当である、と判断される。

一般的にスキーマ文書を設計する際には、複数のシステムで共通的に利用するために汎用性を持たせたり、将来の変更に耐えられるように拡張性を持たせたりすることが多い。このように汎用性や拡張性を考慮して設計されたスキーマ文書は、特定のシステムにとっては制約条件が緩すぎることがある。

そこで、汎用性や拡張性を持つスキーマ文書を、特定のシステムに適した形に変更してから使用することがある。このようなスキーマ文書の変更を支援するための技術として、例えば特許文献１がある。特許文献１では、スキーマ文書を解析し、スキーマ文書の持つ制約条件をより厳しいものに変更できる場合、ユーザに変更の候補を提示する技術が開示されている。

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

特許文献１に記載の技術は、スキーマ文書に含まれる情報を基に制約条件の変更候補を決定するため、スキーマ文書に含まれる情報だけでは情報量が少なく、的確な変更候補を提示できない場合がある。

従って、特許文献１に記載の技術では、提示された変更候補をユーザが確認し、変更するかどうかを判断しなければならない場面が多くなり、ユーザに大きな負担がかかる。

そこで、本発明は、制約条件の厳しいスキーマを効率よく生成することを目的とする。

以上の課題を解決するため、本発明は、オリジナルスキーマに含まれる制約条件を、サンプルデータを妥当と判断することのできる最も厳しい制約条件に変換することで、より制約の厳しいスキーマ文書を生成する。

例えば、本発明は、スキーマ文書を生成するスキーマ変換装置であって、サンプルデータに含まれる要素を妥当と判断可能な最も厳しい制約条件を変換候補として、当該要素毎に取得する処理と、前記要素に対応する要素宣言をオリジナルスキーマより特定し、特定した要素宣言の要素内容における前記要素に対する制約条件を、前記変換候補として取得した制約条件に変換することで、前記スキーマ文書を生成する処理と、を行う制御部を備えること、を特徴とする。

以上のように、本発明によれば、制約条件の厳しいスキーマを効率よく生成することができる。

図１は、本発明の第一の実施形態であるスキーマ変換装置１００の概略図である。

スキーマ変換装置１００は、記憶部１１０と、制御部１２０と、入力部１３０と、出力部１４０と、通信部１５０と、を備える。

記憶部１１０は、スキーマリポジトリ記憶領域１１１と、設定情報記憶領域１１２と、オリジナルスキーマ記憶領域１１３と、サンプルデータ記憶領域１１４と、制限候補情報記憶領域１１５と、変換後スキーマ記憶領域１１６と、を備える。

スキーマリポジトリ記憶領域１１１には、スキーマ変換装置１００で使用するスキーマ文書を管理する情報と、当該スキーマ文書と、が記憶される。

例えば、本実施形態においては、図２（スキーマ文書管理テーブル１１１ａの概略図）に示すようなスキーマ文書管理テーブル１１１ａと、当該スキーマ文書管理テーブル１１１ａで管理されているスキーマ文書（図示せず）と、がスキーマリポジトリ記憶領域１１１に記憶される。

図２に示すように、スキーマ文書管理テーブル１１１ａは、ＩＤ欄１１１ｂと、対象名前空間ＵＲＩ欄１１１ｃと、ロケーション欄１１１ｄと、を備える。

ＩＤ欄１１１ｂには、各々のレコードで管理される各々のスキーマ文書を一意に識別するための識別情報（ＩＤ）が格納される。

対象名前空間ＵＲＩ欄１１１ｃには、スキーマリポジトリ記憶領域１１１に記憶されているスキーマ文書の対象名前空間ＵＲＩ（Uniform Resource Identifiers）を特定する情報が格納される。

ロケーション欄１１１ｄには、スキーマリポジトリ記憶領域１１１に記憶されているスキーマ文書の所在を特定する情報が格納される。このような所在については、例えば、ファイルシステムにおけるパスやＵＲＬ（Uniform Resource Locator）を用いて記述することができる。

図１に戻り、設定情報記憶領域１１２には、オリジナルスキーマに対して、制約条件の変更を許可する項目を特定する情報が記憶される。

例えば、本実施形態においては、図３（設定情報テーブル１１２ａの概略図）に示すような設定情報テーブル１１２ａが設定情報記憶領域１１２に記憶される。

設定情報テーブル１１２ａは、ＩＤ欄１１２ｂと、要素宣言ＩＤ欄１１２ｃと、制約条件の種別欄１１２ｄと、を有する。

ＩＤ欄１１２ｂには、各々のレコードで特定される項目を一意に識別するための識別情報（ＩＤ）が格納される。

要素宣言ＩＤ欄１１２ｃには、要素宣言を一意に識別するための識別情報である要素宣言ＩＤが格納される。ここで、後述のように、本実施形態におけるオリジナルスキーマ１１３ａでは、全ての要素宣言が異なるｎａｍｅ属性の値を持つため、ｎａｍｅ属性の値を要素宣言ＩＤとして用いているが、このような態様に限定されるわけではなく、例えば、ＸＰａｔｈ等により特定することも可能である。

制約条件の種別欄１１２ｄには、制限しようとする制約条件の種別を特定する情報が格納される。

図１に戻り、オリジナルスキーマ記憶領域１１３には、スキーマ変換装置１００で変換の対象となるスキーマであるオリジナルスキーマが記憶される。

例えば、本実施形態においては、図４（オリジナルスキーマ１１３ａの概略図）に示すようなオリジナルスキーマ１１３ａがオリジナルスキーマ記憶領域１１３に記憶される。

なお、図４の向かって左端の数字は、行数を示すためのメモリであり、オリジナルスキーマ１１３ａを構成するものではない。

ここで、オリジナルスキーマ１１３ａは、スキーマ変換装置１００のオペレータが作成したものを、入力部１３０等を介して入力を受け付けてもよいし、業界標準などで定められたスキーマ文書を取得して利用してもよい。

また、オリジナルスキーマは、Ｗｅｂサービスのインターフェースを記述したＷＳＤＬ（Web Services Description Language）の内部に記述されていたり、ＷＳＤＬから参照されたりしていることもある。

さらに、オリジナルスキーマはスキーマリポジトリ記憶領域１１１から取得してもよい。

サンプルデータ記憶領域１１４には、オリジナルスキーマを変換する際に使用するサンプルデータが記憶される。

例えば、本実施形態においては、図５（サンプルデータ１１４ａの概略図）に示すようなサンプルデータ１１４ａがサンプルデータ記憶領域１１４に記憶される。

なお、図５の向かって左端の数字は、行数を示すためのメモリであり、サンプルデータ１１４ａを構成するものではない。

ここで、サンプルデータ１１４ａは、例えば、開発時のテストデータなどを利用してもよい。

なお、サンプルデータの数については、任意に設定可能である。

図１に戻り、制限候補情報記憶領域１１５には、各々のオリジナルスキーマに対して、サンプルデータから取得された、より厳しい制限を課す項目と、制約条件と、を特定する情報が記憶される。

例えば、本実施形態においては、図６（第一制限候補テーブル１１５ａの概略図）に示すような第一制限候補テーブル１１５ａと、図７（第二制限候補テーブル１１５ｇの概略図）に示すような第二制限候補テーブル１１５ｇと、がオリジナルスキーマ毎に制限候補情報記憶領域１１５に記憶される。

ここで、第一制限候補テーブル１１５ａには、要素のテキストデータを制限するための制約条件を特定する情報が格納され、第二制限候補テーブル１１５ｇには、要素の子要素を制限するための制約条件を特定するための情報が格納される。

なお、第一制限候補テーブル１１５ａ及び第二制限候補テーブル１１５ｇは、初期状態においては、情報は格納されておらず、後述する制限候補情報更新部１２４がサンプルデータ及びオリジナルスキーマの解析を行うことにより情報が格納される。

図６に示すように、第一制限候補テーブル１１５ａは、ＩＤ欄１１５ｂと、要素宣言ＩＤ欄１１５ｃと、制約条件の種別欄１１５ｄと、制約条件の候補欄１１５ｅと、を有する。

ＩＤ欄１１５ｂには、各々のレコードで特定される項目及び制約条件を識別するための識別情報（ＩＤ）が格納される。

要素宣言ＩＤ欄１１５ｃには、要素宣言を一意に識別するための識別情報である要素宣言ＩＤが格納される。

制約条件の種別欄１１５ｄには、制限しようとする制約条件の種別を特定する情報が格納される。

制約条件の候補欄１１５ｅには、制限しようとする制約条件の候補を特定する情報が格納される。

図７に示すように、第二制限候補テーブル１１５ｇは、ＩＤ欄１１５ｈと、要素宣言ＩＤ欄１１５ｉと、制約条件の種別欄１１５ｋと、制約条件の候補欄１１５ｌと、を有する。

ＩＤ欄１１５ｈには、各々のレコードで特定される項目及び制約条件を識別するための識別情報（ＩＤ）が格納される。

要素宣言ＩＤ欄１１５ｉには、要素宣言を一意に識別するための識別情報である要素宣言ＩＤが格納される。

パーティクルＩＤ欄１１５ｊには、要素宣言ＩＤ欄１１５ｉで特定される要素宣言内のパーティクルであって、制限しようとするパーティクルを一意に識別するための識別情報であるパーティクルＩＤが格納される。

ここで、パーティクルとは、要素宣言の内容モデルの構成要素のことであり、具体的にはｓｅｑｕｅｎｃｅ要素、ｃｈｏｉｃｅ要素、ｅｌｅｍｅｎｔ要素、ａｎｙ要素等がパーティクルに含まれる。

制約条件の種別欄１１５ｋには、制限しようとする制約条件の種別を特定する情報が格納される。

制約条件の候補欄１１５ｌには、制限しようとする制約条件の候補を特定する情報が格納される。

図１に戻り、変換後スキーマ記憶領域１１６には、オリジナルスキーマ１１３ａを後述したスキーマ変換部１２５で変換した変換後スキーマが記憶される。

例えば、本実施形態においては、図８（変換後スキーマ１１６ａの概略図）に示すような変換後スキーマ１１６ａが変換後スキーマ記憶領域１１６に記憶される。

なお、図８の向かって左端の数字は、行数を示すためのメモリであり、変換後スキーマ１１６ａを構成するものではない。

図１に戻り、制御部１２０は、全体制御部１２１と、スキーマ検証部１２２と、探索部１２３と、制限候補情報更新部１２４と、スキーマ変換部１２５と、を備える。

全体制御部１２１は、スキーマ変換装置１００における処理の全体を制御する。

特に、本実施形態においては、全体制御部１２１は、スキーマリポジトリ記憶領域１１１、設定情報記憶領域１１２、オリジナルスキーマ記憶領域１１３、サンプルデータ記憶領域１１４に記憶する情報の管理を行う。例えば、入力部１３０や通信部１５０を介して、これらの記憶領域に記憶する情報を取得し、取得した情報を各々の対応する記憶領域に記憶等する処理を行う。

スキーマ検証部１２２は、検証対象となっているＸＭＬ文書が、スキーマ文書に対して妥当か否かを検証する。

特に、本実施形態においては、スキーマ検証部１２２は、サンプルデータ記憶領域１１４に記憶されているサンプルデータ１１４ａが、オリジナルスキーマ記憶領域１１３に記憶されているオリジナルスキーマ１１３ａに対して妥当か否かの検証を行う。

探索部１２３は、探索の対象となるＸＭＬ文書（サンプルデータ１１４ａ）を探索し、当該ＸＭＬ文書（サンプルデータ１１４ａ）に記述されている各々の要素を特定する。

ここで、本実施形態においては、探索部１２３は、探索の対象となるＸＭＬ文書（サンプルデータ１１４ａ）を深さ優先で探索し、帰りがけ順で要素を特定して、当該帰りがけ順で特定した要素に含まれる情報を制限候補情報更新部１２４に出力する。

制限候補情報更新部１２４は、探索部１２３より取得した要素より、当該要素に対応する要素宣言に含まれる情報をオリジナルスキーマ１１３ａから抽出して、当該要素に含まれる情報が妥当と判断されるように、より厳しい制約条件があるか否かを判断して、より厳しい制約条件のうち最も厳しい制約条件を制限候補として制限候補情報記憶領域１１５に記憶する処理を行う。

スキーマ変換部１２５は、制限候補情報記憶領域１１５に記憶されている制限候補が、設定情報記憶領域１１２に記憶されている設定情報で制限が許可されているものか否かを判断し、制限が許可されている制限候補をオリジナルスキーマ１１３ａに適用することで、スキーマの変換を行い、変換後スキーマを生成する。

なお、このようにして生成された変換後スキーマは、変換後スキーマ記憶領域１１６に記憶される。

入力部１３０は、情報の入力を受け付ける。

出力部１４０は、情報を出力する。

通信部１５０は、ネットワーク（図示せず）を介して情報を送受信する。

以上に記載したスキーマ変換装置１００は、例えば、図９（コンピュータ２００の概略図）に示すような、ＣＰＵ（Central Processing Unit）９０１と、メモリ９０２と、ＨＤＤ（Hard Disk Drive）等の外部記憶装置９０３と、ＣＤ−ＲＯＭ（Compact Disk Read Only Memory）やＤＶＤ−ＲＯＭ（Digital Versatile Disk Read Only Memory）等の可搬性を有する記憶媒体９０４に対して情報を読み書きする読書装置９０５と、キーボードやマウスなどの入力装置９０６と、ディスプレイなどの出力装置９０７と、通信ネットワークに接続するためのＮＩＣ（Network Interface Card）等の通信装置９０８と、を備えた一般的なコンピュータ９００で実現できる。

例えば、記憶部１１０は、ＣＰＵ９０１がメモリ９０２又は外部記憶装置９０３を利用することにより実現可能であり、制御部１２０は、外部記憶装置９０３に記憶されている所定のプログラムをメモリ９０２にロードしてＣＰＵ９０１で実行することで実現可能であり、入力部１３０は、ＣＰＵ９０１が入力装置９０６を利用することで実現可能であり、出力部１４０は、ＣＰＵ９０１が出力装置９０７を利用することで実現可能であり、通信部１５０は、ＣＰＵ９０１が通信装置９０８を利用することで実現可能である。

この所定のプログラムは、読書装置９０５を介して記憶媒体９０４から、あるいは、通信装置９０８を介してネットワークから、外部記憶装置９０３にダウンロードされ、それから、メモリ９０２上にロードされてＣＰＵ９０１により実行されるようにしてもよい。また、読書装置９０５を介して記憶媒体９０４から、あるいは、通信装置９０８を介してネットワークから、メモリ９０２上に直接ロードされ、ＣＰＵ９０１により実行されるようにしてもよい。

図１０は、スキーマ変換装置１００における全体の処理を示すフローチャートである。

まず、全体制御部１２１は、オリジナルスキーマ記憶領域１１３に記憶されているオリジナルスキーマ及びサンプルデータ記憶領域１１４に記憶されているサンプルデータを取得する（Ｓ１０）。ここで、オリジナルスキーマに使用するサンプルデータが複数ある場合には、ステップＳ１０において複数のサンプルデータを取得する。

次に、全体制御部１２１は、ステップＳ１０で取得したサンプルデータからステップＳ１４の制限候補の探索を未だ行っていないサンプルデータを一つ抽出して、スキーマ検証部１２２に入力するとともに（Ｓ１１）、ステップＳ１０で取得したオリジナルスキーマをスキーマ検証部１２２に入力する。

次に、スキーマ検証部１２２は、ステップＳ１１で入力されたサンプルデータが、入力されたスキーマに対して妥当か否かを判断する（Ｓ１２）。ここで、スキーマ検証部１２２での処理は、一般的なＸＭＬパーサなどで実現されているものと同様である。

そして、サンプルデータがスキーマに対して妥当ではない場合には（ステップＳ１２でＮｏ）ステップＳ１３に進み、サンプルデータがスキーマに対して妥当である場合には（ステップＳ１２でＹｅｓ）ステップＳ１４に進む。

ステップＳ１３では、スキーマ検証部１２２は、予め定められたエラーメッセージを出力部１４０に表示し、処理を終了する。

一方、ステップＳ１４では、スキーマ検証部１２２は、全体制御部１２１より入力されたサンプルデータとオリジナルスキーマとを探索部１２３及び制限候補情報更新部１２４に入力して、探索部１２３及び制限候補情報更新部１２４は、制限候補情報を更新する処理を行う。なお、ステップＳ１４での処理の詳細は、後述する。

次に、全体制御部１２１は、ステップＳ１０で取得したサンプルデータのうち、ステップＳ１４の制限候補の探索を未だ行っていないサンプルデータがあるか否かを判断し（Ｓ１５）、ある場合には（ステップＳ１５でＹｅｓ）ステップＳ１１に戻り処理を繰り返し、ない場合には（ステップＳ１５でＮｏ）ステップＳ１６に進む。

ステップＳ１６では、制限候補情報更新部１２４は、設定情報記憶領域１１２に記憶されている設定情報を取得して、制限候補情報記憶領域１１５に記憶されている制限候補のうち、設定情報において制限が許可されていないものを削除することで、制限候補の更新を行う。

具体的には、制限候補情報更新部１２４は、設定情報記憶領域１１２に記憶されている設定情報テーブル１１２ａを取得して、制限候補情報記憶領域１１５に記憶されている第一制限候補テーブル１１５ａ及び第二制限候補テーブル１１５ｇの各々のレコードのうち、制限候補テーブル１１２ａで制限が許可されていないものを削除する。

ここで、制限候補テーブル１１２ａでは、ＩＤ欄１１２ｂが「１」のレコードにおいて、要素宣言ＩＤ欄１１２ｃが「Ｔｅｌｅｐｈｏｎｅ」で、制約条件の種別欄１１２ｄが「基底型」のレコードについては、制約条件の制限を許可していることを示している。

また、制限候補テーブル１１２ａでは、ＩＤ欄１１２ｂが「２」のレコードにおいて、要素宣言ＩＤ欄１１２ｃが「Ｔｅｌｅｐｈｏｎｅ」で、制約条件の種別欄１１２ｄが「値の長さ」のレコードについては、制約条件の制限を許可していることを示している。

また、制限候補テーブル１１２ａでは、ＩＤ欄１１２ｂが「３」のレコードにおいて、要素宣言ＩＤ欄１１２ｃが「＊」で、これは、任意の要素であることを示しており、制約条件の種別欄１１２ｄが「出現パーティクル」のレコードについては、制約条件の制限を許可していることを示している。

また、制限候補テーブル１１２ａでは、ＩＤ欄１１２ｂが「４」のレコードにおいて、要素宣言ＩＤ欄１１２ｃが任意の要素であり、制約条件の種別欄１１２ｄが「出現回数」のレコードについては、制約条件の制限を許可していることを示している。

また、制限候補テーブル１１２ａでは、ＩＤ欄１１２ｂが「５」のレコードにおいて、要素宣言ＩＤ欄１１２ｃが任意の要素であり、制約条件の種別欄１１２ｄが「出現要素」のレコードについては、制約条件の制限を許可していることを示している。

従って、第一制限候補テーブル１１５ａのＩＤ欄１１５ｂが「１，２，５〜１０」のレコードは削除され、第二制限候補テーブル１１５ｇのレコードは削除しないことで、これらの制限候補情報を更新する。

そして、スキーマ変換部１２５は、ステップＳ１６で更新された制限候補を用いてオリジナルスキーマを変換して、変換後スキーマを生成する（Ｓ１７）。

まず、図６の第一制限候補テーブル１１５ａのＩＤ欄１１５ｂが「３」及び「４」で識別されるレコードの制限について説明する。

この制限により、図４に示すオリジナルスキーマ１１３ａの３２行目のｅｌｅｍｅｎｔ要素が、図８に示す変換後スキーマ１１６ａの３１行目〜３７行目のｅｌｅｍｅｎｔ要素に変換される。

ここで、変換後スキーマ１１６ａの３３行目のｒｅｓｔｒｉｃｔｉｏｎ要素は、ｂａｓｅ属性の値で指定したデータ型を基底として制限することを表す。ｂａｓｅ属性の値には、第一制限候補テーブル１１５ａの制約条件の候補欄１１５ｅに登録されている「ＮＣＮａｍｅ」を格納する。

また、変換後スキーマ１１６ａの３４行目のｌｅｎｇｔｈ要素は、このデータ型がｖａｌｕｅ属性の値で指定した長さの値のみを許すことを表す。ｖａｌｕｅ属性の値には、第一制限候補テーブル１１５ａの制約条件の候補欄１１５ｅに登録されている「１２」を格納する。

これらの変換により、オリジナルスキーマ１１３ａのＴｅｌｅｐｈｏｎｅ要素の要素宣言は、ｓｔｒｉｎｇのデータ型であったが、変換後スキーマではＮＣＮａｍｅ基底型とするデータ型になるため、制約条件が厳しくなる。また、オリジナルスキーマ１１３ａでは値の長さの制限がなかったが、変換後スキーマ１１６ａでは値の長さが「１２」に限定されるため、制約条件が厳しくなる。

次に、図７に示した第二制限候補テーブル１１５ｇのＩＤ欄１１５ｈが「１」で識別されるレコードの制限について説明する。

この変換により、オリジナルスキーマ１１３ａの１５〜１８行目のｃｈｏｉｃｅ要素が、変換後スキーマ１１６ａの１７行目のｅｌｅｍｅｎｔ要素に変換される。

これにより、オリジナルスキーマ１１３ａでは、Ｔｅｌｅｐｈｏｎｅ要素とＥｍａｉｌ要素のどちらの要素の出現も許可していたが、変換後スキーマ１１６ａではＴｅｌｅｐｈｏｎｅ要素の出現だけを許しＥｍａｉｌ要素の出現を禁止することができるため、制約条件が厳しくなる。

次に、図７に示した第二制限候補テーブル１１５ｇのＩＤ欄１１５ｈが「２」及び「３」で識別されるレコードの制限について説明する。

この変換により、オリジナルスキーマ１１３ａの２７行目のａｎｙ要素が、変換後スキーマ１１６ａの２６行目のｅｌｅｍｅｎｔ要素に変換される。

これにより、オリジナルスキーマ１１３ａでは任意の要素の出現が許可されていたが、変換後スキーマ１１６ａではＤｉｓｃｏｕｎｔ要素の出現だけを許すようになる。また、オリジナルスキーマ１１３ａでは最大の出現回数の制限がなかったが、変換後スキーマでは最大出現回数を１回に制限することができるようになり、制約条件が厳しくなる。

次に、図７に示した第二制限候補テーブル１１５ｇのＩＤ欄１１５ｈが「４」で識別されるレコードの制限について説明する。

この変換により、オリジナルスキーマ１１３ａの０７行目のｅｌｅｍｅｎｔ要素が、変換後スキーマ１１６ａの０９行目のｅｌｅｍｅｎｔ要素に変換される。

これにより、オリジナルスキーマ１１３ａでは最大の出現回数の制限がなかったが、変換後スキーマでは最大出現回数を２回に制限することができるようになり、制約条件が厳しくなる。

図１１は、図１０のステップＳ１４に示す制限候補情報を更新する処理を示すフローチャートである。

まず、スキーマ変換装置１００の探索部１２３は、探索の対象となっているサンプルデータから、要素を探索し、後述するステップＳ２１〜ステップＳ２４の調査を未だ行っていない要素Ｅを一つ抽出する（Ｓ２０）。

ここで、本実施形態においては、探索部１２３は、深さ優先でサンプルデータの探索を行い、帰りがけ順に要素Ｅを抽出して後述する処理を行う。

例えば、探索の対象となっているサンプルデータが、図５に示すサンプルデータ１１４ａである場合には、探索部１２３は、深さ優先でサンプルデータ１１４ａの探索を行い、サンプルデータ１１４ａに含まれる各要素を以下のような順番で要素Ｅとして抽出する。

（１）ＣｕｓｔｏｍｅｒＮａｍｅ要素（０４行目）、（２）Ｔｅｌｅｐｈｏｎｅ要素（０５行目）、（３）ＣｕｓｔｏｍｅｒＩｎｆｏ要素（０３〜０６行目）、（４）ＰｒｏｄｕｃｔＮａｍｅ要素（０８行目）、（５）Ｑｕａｎｔｉｔｙ要素（０９行目）、（６）ＰｕｒｃｈａｓｅＩｎｆｏ要素（０７〜１０行目）、（７）ＰｒｏｄｕｃｔＮａｍｅ要素（１２行目）、（８）Ｑｕａｎｔｉｔｙ要素（１３行目）、（９）Ｄｉｓｃｏｕｎｔ要素（１４行目）、（１０）ＰｕｒｃｈａｓｅＩｎｆｏ要素（１１〜１５行目）、（１１）ＰｕｒｃｈａｓｅＯｒｄｅｒ要素（０１〜１６行目）。

次に、制限候補情報更新部１２４は、要素Ｅに対応する要素宣言Ｄをオリジナルスキーマより取得する（Ｓ２１）。ここで、要素宣言Ｄを取得する処理については、図１２を用いて詳細に説明する。

次に、制限候補情報更新部１２４は、ステップＳ２１で取得した要素宣言Ｄに、子要素の定義が含まれるか否かを判定する（Ｓ２２）。ここで、要素宣言Ｄに子要素の定義が含まれるか否かは、要素宣言Ｄが「ｅｌｅｍｅｎｔ」要素を子要素内に有するか否かにより判断する。

そして、子要素の定義がない場合には（ステップＳ２２でＮｏ）ステップＳ２３に進み、子要素の定義がある場合には（ステップＳ２２でＹｅｓ）ステップＳ２４に進む。

ステップＳ２３では、制限候補情報更新部１２４は、テキストデータの制約条件の制限候補情報を更新する。なお、この処理の詳細については、図１５を用いて詳細に説明する。

一方、ステップＳ２４では、制限候補情報更新部１２４は、子要素の制約条件の制限候補情報を更新する。なお、この処理の詳細については、図１６を用いて詳細に説明する。

そして、制限候補情報更新部１２４は、ステップＳ２１〜ステップＳ２４に示す調査を行っていない要素があるか否かを判断して（Ｓ２５）、このような要素がある場合には（ステップＳ２５でＹｅｓ）ステップＳ２０に戻り処理を繰り返し、このような要素がない場合には（ステップＳ２５でＮｏ）処理を終了する。

図１２は、図１１におけるステップＳ２１の要素Ｅに対応する要素宣言Ｄのデータを取得する処理を示すフローチャートである。

まず、スキーマ変換装置１００の制限候補情報更新部１２４は、要素Ｅの名前空間と、オリジナルスキーマの対象名前空間と、が同じか否かを判断する（Ｓ３０）。

例えば、サンプルデータが図５に示すサンプルデータ１１４ａであり、オリジナルスキーマが図４に示すオリジナルスキーマ１１３ａである場合には、ＣｕｓｔｏｍｅｒＮａｍｅ要素（０４行目）、Ｔｅｌｅｐｈｏｎｅ要素（０５行目）、ＣｕｓｔｏｍｅｒＩｎｆｏ要素（０３〜０６行目）、ＰｒｏｄｕｃｔＮａｍｅ要素（０８行目）、Ｑｕａｎｔｉｔｙ要素（０９行目）、ＰｕｒｃｈａｓｅＩｎｆｏ要素（０７〜１０行目）、ＰｒｏｄｕｃｔＮａｍｅ要素（１２行目）、Ｑｕａｎｔｉｔｙ要素（１３行目）、ＰｕｒｃｈａｓｅＩｎｆｏ要素（１１〜１５行目）、および、ＰｕｒｃｈａｓｅＯｒｄｅｒ要素（０１〜１６行目）の名前空間ＵＲＩ「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｏｒｇ／ｏｒｄｅｒ」であり、オリジナルスキーマ１１３ａの対象名前空間ＵＲＩは「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｏｒｇ／ｏｒｄｅｒ」であり、これらは一致するため、ステップＳ３１に進む。一方、Ｄｉｓｃｏｕｎｔ要素（１４行目）の名前空間ＵＲＩは、「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｅｘｔ」であり、オリジナルスキーマ１１３ａの対象名前空間ＵＲＩは「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｏｒｇ／ｏｒｄｅｒ」であり、これらは一致しないため、ステップＳ３６に進む。

ステップＳ３１では、制限候補情報更新部１２４は、要素Ｅに対応した要素宣言が、オリジナルスキーマ内に存在するか否かを判断する（Ｓ３１）。そして、このような要素宣言がオリジナルスキーマ内に存在する場合には（ステップＳ３１でＹｅｓ）ステップＳ３３に進み、このような要素宣言がオリジナルスキーマ内に存在しない場合には（ステップＳ３１でＮｏ）ステップＳ３２に進む。

ステップＳ３２では、制限候補情報更新部１２４は、要素Ｅに対応した要素宣言が、インクルード先のスキーマ内に存在するか否かを判断する。そして、このような要素宣言がインクルード先のスキーマ内に存在する場合には（ステップＳ３２でＹｅｓ）ステップＳ３３に進み、このような要素宣言がインクルード先のスキーマ内に存在しない場合には（ステップＳ３２でＮｏ）ステップＳ３４に進む。

ステップＳ３３では、オリジナルスキーマ内又はインクルード先のスキーマ内に存在する要素宣言を、要素Ｅに対応した要素宣言Ｄとして取得して、処理を終了する。

例えば、サンプルデータが図５に示すサンプルデータ１１４ａであり、オリジナルスキーマが図４に示すオリジナルスキーマ１１３ａである場合には、サンプルデータ１１４ａのＣｕｓｔｏｍｅｒＮａｍｅ要素（０４行目）に対してはオリジナルスキーマ１１３ａの３１行目を、サンプルデータ１１４ａのＴｅｌｅｐｈｏｎｅ要素（０５行目）に対してはオリジナルスキーマ１１３ａの３２行目を、サンプルデータ１１４ａのＣｕｓｔｏｍｅｒＩｎｆｏ要素（０３〜０６行目）に対してはオリジナルスキーマ１１３ａの１１行目から２１行目までを、サンプルデータ１１４ａのＰｒｏｄｕｃｔＮａｍｅ要素（０８行目）に対してはオリジナルスキーマ１１３ａの３４行目を、サンプルデータ１１４ａのＱｕａｎｔｉｔｙ要素（０９行目）に対してはオリジナルスキーマ１１３ａの３５行目を、サンプルデータ１１４ａのＰｕｒｃｈａｓｅＩｎｆｏ要素（０７〜１０行目）に対してはオリジナルスキーマ１１３ａの２２行目から３０行目までを、サンプルデータ１１４ａのＰｒｏｄｕｃｔＮａｍｅ要素（１２行目）に対してはオリジナルスキーマ１１３ａの３４行目を、サンプルデータ１１４ａのＱｕａｎｔｉｔｙ要素（１３行目）に対してはオリジナルスキーマ１１３ａの３５行目を、サンプルデータ１１４ａのＰｕｒｃｈａｓｅＩｎｆｏ要素（１１〜１５行目）に対してはオリジナルスキーマ１１３ａの２２行目から３０行目までを、および、サンプルデータ１１４ａのＰｕｒｃｈａｓｅＯｒｄｅｒ要素（０１〜１６行目）に対してはオリジナルスキーマ１１３ａの０３行目から１０行目までを、要素宣言Ｄとして取得する。

一方、ステップＳ３４では、制限候補情報更新部１２４は、要素Ｅに対応した要素宣言が、スキーマリポジトリ記憶領域１１１に記憶されているスキーマ文書内に存在するか否かを判断する。

具体的には、制限候補情報更新部１２４は、要素Ｅの名前空間ＵＲＩと一致する対象名前空間ＵＲＩを有するスキーマ文書が格納されているレコードをスキーマリポジトリテーブル１１１ａの対象名前空間ＵＲＩ欄１１１ｃより特定し、特定したレコードのロケーション欄１１１ｄに格納されているロケーションで示されるスキーマ文書内を検索することで、要素Ｅに対応した要素宣言があるかないかを判断する。

そして、このような要素宣言がある場合には（ステップＳ３４でＹｅｓ）ステップＳ３５に進み、このような要素宣言がない場合には（ステップＳ３４でＮｏ）ステップＳ３６に進む。

ステップＳ３５では、制限候補情報更新部１２４は、発見した要素宣言を要素宣言Ｄとして取得するとともに、発見した要素宣言が含まれるスキーマ文書をオリジナルスキーマにインクルードする。

一方、ステップＳ３６では、制限候補情報更新部１２４は、予め定められたエラーメッセージを出力部１４０に出力して、処理を終了する。なお、ステップＳ３６で出力するエラーメッセージには、対応する要素宣言を有しない要素Ｅを特定する情報が含まれていることが望ましい。

次に、ステップＳ３７では、オリジナルスキーマにインポートされているスキーマ文書内に、要素Ｅに対応する要素宣言があるか否かを判断する。このような要素宣言がある場合には（ステップＳ３７でＹｅｓ）ステップＳ３８に進み、ない場合には（ステップＳ３７でＮｏ）ステップＳ３９に進む。

なお、インポートとは名前空間の異なるスキーマ文書を取り込むことを言い、ＸＭＬ Ｓｃｈｅｍａではｉｍｐｏｒｔ要素を用いてインポートを実現することができる。

例えば、サンプルデータ１１４ａのＤｉｓｃｏｕｎｔ要素は、オリジナルスキーマ１１３ａと名前空間が異なるため、当該Ｄｉｓｃｏｕｎｔ要素が要素Ｅとなっている場合には、ステップＳ３７での処理となるが、オリジナルスキーマ１１３ａでは、インポートを行っていないため、ステップＳ３９に進むこととなる。

ステップＳ３９では、制限候補情報更新部１２４は、要素Ｅに対応した要素宣言が、スキーマリポジトリ記憶領域１１１に記憶されているスキーマ文書内に存在するか否かを判断する。

具体的には、制限候補情報更新部１２４は、要素Ｅの名前空間ＵＲＩと一致する対象名前空間ＵＲＩを有するスキーマ文書が格納されているレコードをスキーマリポジトリテーブル１１１ａの対象名前空間ＵＲＩ欄１１１ｃより特定し、特定したレコードのロケーション欄１１１ｄに格納されているロケーションで示されるスキーマ文書内を検索することで、要素Ｅに対応した要素宣言があるかないかを判断する。

例えば、サンプルデータ１１４ａのＤｉｓｃｏｕｎｔ要素の名前空間ＵＲＩである「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｅｘｔ」は、図２に示すスキーマリポジトリテーブル１１１ａのＩＤ欄１１ｂが「３」のレコードの対象名前空間ＵＲＩ欄１１１ｃと一致するため、このレコードのロケーション１１１ｄで特定されるロケーションに記憶されているスキーマ文書を検索する。

そして、このような要素宣言がある場合には（ステップＳ３９でＹｅｓ）ステップＳ４０に進み、このような要素宣言がない場合には（ステップＳ３９でＮｏ）ステップＳ４１に進む。

ステップＳ４０では、制限候補情報更新部１２４は、発見した要素宣言を要素宣言Ｄとして取得するとともに、発見した要素宣言が含まれるスキーマ文書をオリジナルスキーマにインポートする。

例えば、サンプルデータ１１４ａのＤｉｓｃｏｕｎｔ要素が要素Ｅである場合であって、ステップＳ３９で発見されたスキーマ文書が、図１３（スキーマ１６０の概略図）に示すスキーマ１６０であるときには、スキーマ１６０の０４行目に対応する要素宣言があるため、この０４行目の要素宣言を要素宣言Ｄとして取得するとともに、スキーマ１６０をオリジナルスキーマ１１３ａにインポートする。例えば、図１４（ｉｍｐｏｒｔ要素１６１の概略図）に示すようなｉｍｐｏｒｔ要素１６１をオリジナルスキーマ１１３ａに追加する。

また、オリジナルスキーマ１１３ａの０２行目のｎａｍｅｓｐａｃｅ属性の値には、図２に示すスキーマリポジトリテーブル１１１ａのＩＤ欄１１ｂが「３」のレコードの対象名前空間ＵＲＩ欄１１１ｃに格納されている値を追加し、０３行目のｓｃｈｅｍａＬｏｃａｔｉｏｎ属性の値には、図２に示すスキーマリポジトリテーブル１１１ａのＩＤ欄１１１ｂが「３」のレコードのロケーション欄１１１ｄに格納されている値を追加する。

一方、ステップＳ４１では、制限候補情報更新部１２４は、予め定められたエラーメッセージを出力部１４０に出力して、処理を終了する。なお、ステップＳ４１で出力するエラーメッセージには、対応する要素宣言を有しない要素Ｅを特定する情報が含まれていることが望ましい。

図１５は、図１１のステップＳ２３のテキストデータの制限候補情報を更新する処理を示すフローチャートである。

まず、制限候補情報更新部１２４は、要素Ｅの要素内容をサンプルデータより取得する（Ｓ５０）。

次に、制限候補情報更新部１２４は、制限候補情報記憶領域１１５に記憶されている第一制限候補テーブル１１５ａに要素宣言Ｄの情報があるか否かを判断する（Ｓ５１）。このような情報がない場合には（ステップＳ５１でＮｏ）ステップＳ５２に進み、このような情報がある場合には（ステップＳ５１でＹｅｓ）ステップＳ５５に進む。

ステップＳ５２では、制限候補情報更新部１２４は、ステップＳ５０で取得した要素内容Ｃを妥当と判断することのできる制約条件のうち、最も厳しいデータ型を求める（Ｓ５２）。

例えば、ＸＭＬ Ｓｃｈｅｍａでは、ビルトイン型と呼ばれる様々なデータ型を規定している。これらのデータ型には、例えば文字列を表すＳｔｒｉｎｇや、復帰文字、改行、タブを含まない文字列を表すｎｏｒｍａｌｉｚｅｄＳｔｒｉｎｇなどがある。これらのデータ型には包含関係がある。例えば、ｎｏｒｍａｌｉｚｅｄＳｔｒｉｎｇはＳｔｒｉｎｇを制限することで定義されたデータ型であり、Ｓｔｒｉｎｇに比べｎｏｒｍａｌｉｚｅｄＳｔｒｉｎｇの方が、制約条件がより厳しい。このようにして、データの包含関係から制約条件の厳しさを比較することができる。

従って、スキーマ変換装置１００のオペレータは、このようなデータ型の包含関係を考慮して、データ型における制約条件の厳しさの序列を予め定めておき、制限候補情報更新部１２４に設定しておくことで、ステップＳ５２での判定が可能となる。

なお、本実施形態では、ＸＭＬ Ｓｃｈｅｍａで規定しているビルトイン型の中から制約条件の厳しいデータ型を求める処理を説明したが、他の方法により制約条件の厳しいデータ型を求めてもよい。例えば、本発明の利用者が独自に定義したデータ型の中から制約条件の厳しいデータ型を求めてもよい。例えば、Ａ〜Ｚの文字と数字から構成される文字列のデータ型などを定義してもよい。また、データ型の派生により包含関係を判断するのではなく、独自の判断方法を定義して使用してもよい。

次に、制限候補情報更新部１２４は、第一制限候補テーブル１１５ａに新たなレコードを追加して、ステップＳ５２で求めたデータ型の他、必要な情報を格納する（Ｓ５３）。

具体的には、制限候補情報更新部１２４は、追加したレコードにおいて、ＩＤ欄１１５ｂには、上方のレコードから連番となるようにＩＤの値を格納し、要素宣言ＩＤ欄１１５ｃには、要素宣言Ｄを識別することのできる識別情報（本実施形態では、要素宣言Ｄのｎａｍｅ属性の値）を格納し、制約条件の種別欄１１５ｄには、「基底型」を示す情報を格納し、制約条件の候補欄１１５ｅには、ステップＳ５２で求めたデータ型を示す情報を格納する。

次に、制限候補情報更新部１２４は、ステップＳ５０で取得した要素内容Ｃの値の長さを求め、第一制限候補テーブル１１５ａに新たなレコードを追加して、求めた値の長さの他、必要な情報を格納する（Ｓ５４）。

具体的には、制限候補情報更新部１２４は、追加したレコードにおいて、ＩＤ欄１１５ｂには、上方のレコードから連番となるようにＩＤの値を格納し、要素宣言ＩＤ欄１１５ｃには、要素宣言Ｄを識別することのできる識別情報（本実施形態では、要素宣言Ｄのｎａｍｅ属性の値）を格納し、制約条件の種別欄１１５ｄには、「値の長さ」を示す情報を格納し、制約条件の候補欄１１５ｅには、求めた値の長さを示す情報を格納する。

一方、ステップＳ５５では、制限候補情報更新部１２４は、ステップＳ５０で取得した要素内容Ｃを妥当と判断することのできる制約条件のうち、最も厳しいデータ型を求め、第一制限候補テーブル１１５ａの要素宣言Ｄに対応するレコードであって、制約条件の種別欄１１５ｄが「基底型」のレコードの制約条件の候補欄１１５ｅに格納されているデータ型と、求めたデータ型と、の両方を包含することのできる最も厳しいデータ型を求め、当該レコードの制約条件の候補欄１１５ｅの値と入れ替えることで、第一制限候補テーブル１１５ａを更新する（Ｓ５５）。

次に、制限候補情報更新部１２４は、ステップＳ５０で取得した要素内容Ｃの値の長さを求め、第一制限候補テーブル１１５ａの要素宣言Ｄに対応するレコードであって、制約条件の種別欄１１５ｄが「値の長さ」のレコードの制約条件の候補欄１１５ｅに格納されている値の長さと、求めた値の長さと、の両方を含む値の長さの範囲を求め、当該レコードの制約条件の候補欄１１５ｅの値と入れ替えることで、第一制限候補テーブル１１５ａを更新する（Ｓ５６）。

以上に記載した図１５のフローチャートにおける処理を、図４に示すオリジナルスキーマ１１３ａ及び図５に示すサンプルデータ１１４ａに基づいて、具体的に説明する。ここで、第一制限候補テーブル１１５ａは初期状態であって、制限候補情報を格納するレコードは設けられていないものとして説明する。

まず、制限候補情報更新部１２４は、要素Ｅがサンプルデータ１１４ａの０４行目のＣｕｓｔｏｍｅｒＮａｍｅ要素である場合には、当該ＣｕｓｔｏｍｅｒＮａｍｅ要素の要素内容である「ｊｏｈｎ」を取得する（Ｓ５０）。

次に、制限候補情報更新部１２４は、第一制限候補テーブル１１５ａの要素宣言ＩＤ欄１１５ｃにＣｕｓｔｏｍｅｒＮａｍｅ要素宣言の情報があるか判定する（Ｓ５１）。第一制限候補テーブル１１５ａは、初期状態ではレコードを持たないためＣｕｓｔｏｍｅｒＮａｍｅ要素宣言の情報はないものとする。

次に、制限候補情報更新部１２４は、ステップＳ５０で取得した要素内容である「ｊｏｈｎ」が含まれるなるべく制約条件の厳しいデータ型を求める。本実施形態では、制限候補情報更新部１２４は、ＸＭＬ Ｓｃｈｅｍａのビルトイン型からなるべく制約条件の厳しいデータ型を求めることでＮＣＮａｍｅのデータ型が求まる。ここで、ＮＣＮａｍｅのデータ型は、ｎｏｒｍａｌｉｚｅｄＳｔｒｉｎｇのデータ型を、さらに複数回派生させたデータ型あり、コロン「:」を含まないという特徴を持つ。

次に、制限候補情報更新部１２４は、第一制限候補テーブル１１５ａに新たなレコードを追加して、ＩＤ欄１１５ｂには「１」の値を、要素宣言ＩＤにはＣｕｓｔｏｍｅｒＮａｍｅ要素の要素宣言ＩＤである「ＣｕｓｔｏｍｅｒＮａｍｅ」を格納し、制約条件の種別欄１１５ｄには、「基底型」を格納し、制約条件の候補欄１１５ｅには、ステップＳ５２で求めた「ＮＣＮａｍｅ」を格納する（Ｓ５３）。

次に、制限候補情報更新部１２４は、要素内容であるｊｏｈｎの値の長さである４を求め、第一制限候補テーブル１１５ａに新たなレコードを追加して、ＩＤ欄１１５ｂには「２」の値を、要素宣言ＩＤにはＣｕｓｔｏｍｅｒＮａｍｅ要素の要素宣言ＩＤである「ＣｕｓｔｏｍｅｒＮａｍｅ」を格納し、制約条件の種別欄１１５ｄには、「基底型」を格納し、制約条件の候補欄１１５ｅには、求めた「２」の値を格納する（Ｓ５４）。

以上の処理を行うことで、第一制限候補テーブル１１５ａにＩＤ欄１１５ｂが「１」及び「２」で識別されるレコードが追加される。

次に、制限候補情報更新部１２４は、要素Ｅがサンプルデータ１１４ａの０５行目のＴｅｌｅｐｈｏｎｅ要素である場合には、上述の０４行目のＣｕｓｔｏｍｅｒＮａｍｅ要素の場合と同様の処理を行い、第一制限候補テーブル１１５ａにＩＤ「３」及び「４」で識別されるレコードが追加される。

サンプルデータ１１４ａにおける次の要素はＣｕｓｔｏｍｅｒＩｎｆｏ要素であるが、この要素に対する処理は図１６で説明する。

次に、制限候補情報更新部１２４は、要素Ｅがサンプルデータ１１４ａの０８行目のＰｒｏｄｕｃｔＮａｍｅ要素である場合、および、Ｑｕａｎｔｉｔｙ要素である場合には、上述のＣｕｓｔｏｍｅｒＮａｍｅ要素の場合と同様の処理を行い、第一制限候補テーブル１１５ａにＩＤ「５」〜「８」で識別されるレコードが追加される。但し、図６に示した第一制限候補テーブル１１５ａでは、ＩＤ「６」に示すレコードの制約条件の候補欄１１５ｅには「８〜９」の値が格納されているが、要素Ｅがサンプルデータ１１４ａの０８行目のＰｒｏｄｕｃｔＮａｍｅ要素である場合は、要素内容「ＬａｐｔｏｐＰＣ」の値の長さに対応する「８」の値が格納され、また、ＩＤ「８」に示すレコードの制約条件の候補欄１１５ｅには「１〜２」の値が格納されているが、要素Ｅがサンプルデータ１１４ａの０９行目のＱｕａｎｔｉｔｙ要素である場合は、要素内容「１」の値の長さに対応する「１」の値が格納される。

サンプルデータ１１４ａにおける次の要素はＰｕｒｃｈａｓｅＩｎｆｏ要素であるが、この要素に対する処理は図１６で説明する。

次に、制限候補情報更新部１２４は、要素Ｅがサンプルデータ１１４ａの１２行目のＰｒｏｄｕｃｔＮａｍｅ要素である場合には、当該ＰｒｏｄｕｃｔＮａｍｅ要素の要素内容である「ＵＳＢＭｅｍｏｒｙ」を取得する（Ｓ５０）。

次に、制限候補情報更新部１２４は、第一制限候補テーブル１１５ａの要素宣言ＩＤ欄１１５ｃにＰｒｏｄｕｃｔＮａｍｅ要素宣言の情報があるか判定する（Ｓ５１）。ここで、上述の処理により、第一制限候補テーブル１１５ａには、ＩＤ欄１１５ｂが「５」及び「６」のレコードにおける要素宣言ＩＤ欄１１５ｃに「ＰｒｏｄｕｃｔＮａｍｅ」が格納されているため、ステップＳ５５に進む。

ステップＳ５５では、制限候補情報更新部１２４は、処理中の要素の要素内容を含む制約条件の厳しいデータ型と、既に第一制限候補テーブル１１５ａに格納されているデータ型の両方を含むデータ型のうち最も厳しい制限となるものを求める。

ここでは、処理中のＰｒｏｄｕｃｔＮａｍｅ要素の要素内容であるＵＳＢＭｅｍｏｒｙを含む制約条件の厳しいデータ型はＮＣＮａｍｅであり、既に第一制限候補テーブル１１５ａに登録されているＰｒｏｄｕｃｔＮａｍｅ要素宣言のデータ型はＮＣＮａｍｅであるため、両方のデータ型を含むデータ型もＮＣＮａｍｅとなる。

次に、制限候補情報更新部１２４は、処理中の要素の要素内容「ＵＳＢＭｅｍｏｒｙ」の値の長さ「９」を取得し、既に第一制限候補テーブル１１５ａに格納されている値の長さ「８」の両方を満たす値の長さの範囲「８〜９」を求め、第一制限候補テーブル１１５ａの要素宣言ＩＤ欄１１５ｃに「ＰｒｏｄｕｃｔＮａｍｅ」、制約条件の種別１１５ｄに「値の長さ」、が格納されているレコードの制約条件の候補欄１１５ｅの値を「８〜９」に更新する（Ｓ５６）。

以上の処理を行うことで、第一制限候補テーブル１１５ａのＩＤ欄１１５ｂが「５」及び「６」で識別されるレコードの更新が行われる。

次に、制約候補情報更新部１２４は、要素Ｅがサンプルデータ１１４ａの１３行目のＱｕａｎｔｉｔｙ要素である場合の処理を行うが、この処理は、要素Ｅがサンプルデータ１１４ａの１２行目のＰｒｏｄｕｃｔＮａｍｅ要素である場合の処理と同様であるため、説明を省略する。

次に、制限候補情報更新部１２４は、要素Ｅがサンプルデータ１１４ａの１４行目のＤｉｓｃｏｕｎｔ要素である場合には、上述の０４行目のＣｕｓｔｏｍｅｒＮａｍｅ要素の場合と同様の処理を行い、第一制限候補テーブル１１５ａにＩＤ「９」及び「１０」で識別されるレコードが追加される。

サンプルデータ１１４ａにおける次の要素はＰｕｒｃｈａｓｅＩｎｆｏ要素であり、その次は、ＰｕｒｃｈａｓｅＯｒｄｅｒ要素であるが、これらの要素に対する処理は図１６で説明する。

図１６は、図１１のステップＳ２４の子要素の制限候補情報を更新する処理を示すフローチャートである。

まず、制限候補情報更新部１２４は、サンプルデータ１１４ａより、要素Ｅの子要素のリストＬを取得する（Ｓ６０）。例えば、制限候補情報更新部１２４は、要素Ｅの子要素の要素名をカンマ（，）で区切って羅列することにより、リストＬを取得する。

次に、制限候補情報更新部１２４は、制限候補情報記憶領域１１５に記憶されている第二制限候補テーブル１１５ｇに、要素宣言Ｄの情報があるか否かを判断する（Ｓ６１）。このような情報がない場合には（ステップＳ６１でＮｏ）ステップＳ６２に進み、このような情報がある場合には（ステップＳ６１でＹｅｓ）ステップＳ７０に進む。

ステップＳ６２では、制限候補情報更新部１２４は、オリジナルスキーマ１１３ａにおける要素宣言Ｄの子要素内に、ｃｈｏｉｃｅ要素があるか否かを判断する。そして、このようなｃｈｏｉｃｅ要素がある場合には（ステップＳ６２でＹｅｓ）ステップＳ６３に進み、ない場合には（ステップＳ６２でＮｏ）ステップＳ６５に進む。

ステップＳ６３では、制限候補情報更新部１２４は、オリジナルスキーマ１１３ａより、要素宣言Ｄにおけるｃｈｏｉｃｅ要素の子要素のパーティクルを取得する。

次に、制限候補情報更新部１２４は、ステップＳ６３で取得したパーティクルのうち、サンプルデータ１１４ａの要素Ｅの子要素として選択されているものを特定し、第二制限候補テーブル１１５ｇに新たなレコードを追加して、特定した子要素を示す情報とともに、必要な情報を追加したレコードに格納する（Ｓ６４）。

具体的には、制限候補情報更新部１２４は、追加したレコードにおいて、ＩＤ欄１１５ｈには、上方のレコードから連番となるようにＩＤの値を格納し、要素宣言ＩＤ欄１１５ｉには、要素宣言Ｄのｎａｍｅ属性の値を示す情報を格納し、パーティクルＩＤ欄１１５ｊには、「ｃｈｏｉｃｅ」を示す情報を格納し、制約条件の種別欄１１５ｋには、「出現パーティクル」を示す情報を格納し、制約条件の候補欄１１５ｅには、ステップＳ６４で特定した子要素を示す情報を格納する。

次に、制限候補情報更新部１２４は、オリジナルスキーマ１１３ａにおける要素宣言Ｄの子要素内に、出現回数が固定でないパーティクルがあるか否かを判断する（Ｓ６５）。そして、このようなパーティクルがある場合には（ステップＳ６５でＹｅｓ）ステップＳ６６に進み、ない場合には（ステップＳ６５でＮｏ）ステップＳ６８に進む。

ここで、ＸＭＬ Ｓｃｈｅｍａでは、各パーティクルはｍｉｎＯｃｃｕｒｓ属性とｍａｘＯｃｃｕｒｓ属性を持つことができる。ｍｉｎＯｃｃｕｒｓ属性はパーティクルの最小出現回数を表し、ｍａｘＯｃｃｕｒｓ属性はパーティクルの最大出現回数を表す。

また、ｍｉｎＯｃｃｕｒｓ属性を省略した場合は、パーティクルの最小出現回数が１回であることを表す。ｍａｘＯｃｃｕｒｓ属性を省略した場合は、パーティクルの最大出現回数が１回であることを表す。

さらに、ｍａｘＯｃｃｕｒｓ属性の値がｕｎｂｏｕｎｄｅｄの場合、最大出現回数の制限がないことを表す。

従って、要素宣言Ｄにおけるパーティクルにおいて、ｍｉｎＯｃｃｕｒｓ属性で特定される値よりもｍａｘＯｃｃｕｒｓ属性で特定される値が大きい場合、ｍｉｎＯｃｃｕｒｓ属性が省略されており、ｍａｘＯｃｃｕｒｓ属性で特定される値が「２」以上である場合、または、ｍａｘＯｃｃｕｒｓ属性の値がｕｎｂｏｕｎｄｅｄの場合は、出現回数が固定でないパーティクルであると判断できる。

ステップＳ６６では、制限候補情報更新部１２４は、オリジナルスキーマ１１３ａより、要素宣言Ｄにおける出現回数が固定でないパーティクルを取得する。

次に、制限候補情報更新部１２４は、ステップＳ６６で取得したパーティクルの出現回数を、サンプルデータ１１４ａの要素Ｅの子要素から特定し、第二制限候補テーブル１１５ｇに新たなレコードを追加して、特定した出現回数を示す情報とともに、必要な情報を追加したレコードに格納する（Ｓ６７）。

具体的には、制限候補情報更新部１２４は、追加したレコードにおいて、ＩＤ欄１１５ｈには、上方のレコードから連番となるようにＩＤの値を格納し、要素宣言ＩＤ欄１１５ｉには、要素宣言Ｄのｎａｍｅ属性の値を示す情報を格納し、パーティクルＩＤ欄１１５ｊには、出現回数が固定でないパーティクルを示す情報（ここでは、当該パーティクルの要素名）を格納し、制約条件の種別欄１１５ｋには、「出現回数」を示す情報を格納し、制約条件の候補欄１１５ｅには、ステップＳ６７で特定した出現回数を示す情報を格納する。

次に、制限候補情報更新部１２４は、オリジナルスキーマ１１３ａにおける要素宣言Ｄの子要素内に、ａｎｙ要素があるか否かを判断する（Ｓ６８）。そして、ａｎｙ要素がある場合には（ステップＳ６８でＹｅｓ）ステップＳ６９に進み、ない場合には（ステップＳ６８でＮｏ）処理を終了する。

ステップＳ６９では、制限候補情報更新部１２４は、ステップＳ６０で取得したリストＬにおいて、ａｎｙ要素に対応する子要素の出現回数と、当該子要素を示す情報と、を特定し、第二制限候補テーブル１１５ｇに新たなレコードを二つ追加して、特定した出現回数を示す情報と、特定した子要素を示す情報と、を必要な情報とともに追加したレコードの各々に格納する。

具体的には、制限候補情報更新部１２４は、追加したレコードにおいて、ＩＤ欄１１５ｈには、上方のレコードから連番となるようにＩＤの値を格納し、パーティクルＩＤ欄１１５ｊには、「ａｎｙ」を示す情報を格納し、制約条件の種別欄１１５ｋには、「出現回数」を示す情報を格納し、制約条件の候補欄１１５ｅには、ステップＳ６９で特定した出現回数を特定する情報を格納する。

また、制限候補情報更新部１２４は、追加したレコードにおいて、ＩＤ欄１１５ｈには、上方のレコードから連番となるようにＩＤの値を格納し、要素宣言ＩＤ欄１１５ｉには、要素宣言Ｄのｎａｍｅ属性の値を示す情報を格納し、パーティクルＩＤ欄１１５ｊには、「ａｎｙ」を示す情報を格納し、制約条件の種別欄１１５ｋには、「出現要素」を示す情報を格納し、制約条件の候補欄１１５ｅには、ステップＳ６９で特定した子要素を示す情報（ここでは、子要素名）を格納する。ここで、出現する子要素が複数ある場合には、子要素の要素名をカンマ（，）で区切る等により、各々の子要素を識別可能に格納する。

一方、ステップＳ７０では、制限候補情報更新部１２４は、オリジナルスキーマ１１３ａにおける要素宣言Ｄの子要素内に、ｃｈｏｉｃｅ要素があるか否かを判断する。そして、このようなｃｈｏｉｃｅ要素がある場合には（ステップＳ７０でＹｅｓ）ステップＳ７１に進み、ない場合には（ステップＳ７０でＮｏ）ステップＳ７３に進む。

ステップＳ７１では、制限候補情報更新部１２４は、オリジナルスキーマ１１３ａより、要素宣言Ｄにおけるｃｈｏｉｃｅ要素の子要素のパーティクルを取得する。

次に、制限候補情報更新部１２４は、ステップＳ７１で取得したパーティクルのうち、サンプルデータ１１４ａの要素Ｅの子要素として選択されているものを特定し、第二制限候補テーブル１１５ｇの対応するレコードに、特定した子要素を示す情報を追加等する（Ｓ７２）。

具体的には、制限候補情報更新部１２４は、第二制限候補テーブル１１５ｇの要素宣言ＩＤ欄に要素宣言Ｄのｎａｍｅ属性の値を示す情報が格納され、パーティクルＩＤ欄１１５ｊにｃｈｏｉｃｅを示す情報が格納されているレコードにおいて、制約条件の候補欄１１５ｅに、ステップＳ７２で特定した子要素を示す情報が未だ格納されていない場合には、当該子要素を示す情報を格納する。

次に、制限候補情報更新部１２４は、オリジナルスキーマ１１３ａにおける要素宣言Ｄの子要素内に、出現回数が固定でないパーティクルがあるか否かを判断する（Ｓ７３）。そして、このようなパーティクルがある場合には（ステップＳ７３でＹｅｓ）ステップＳ７４に進み、ない場合には（ステップＳ７３でＮｏ）ステップＳ７６に進む。

ステップＳ７４では、制限候補情報更新部１２４は、オリジナルスキーマ１１３ａより、要素宣言Ｄにおける出現回数が固定でないパーティクルを取得する。

次に、制限候補情報更新部１２４は、ステップＳ７４で取得したパーティクルの出現回数を、サンプルデータ１１４ａの要素Ｅの子要素から特定し、第二制限候補テーブル１１５ｇの対応するレコードに、特定した出現回数を示す情報を追加等する（Ｓ７５）。

具体的には、制限候補情報更新部１２４は、第二制限候補テーブル１１５ｇにおいて、要素宣言ＩＤ欄１１５ｉに要素宣言Ｄのｎａｍｅ属性の値を示す情報が格納され、パーティクルＩＤ欄１１５ｊに出現回数が固定でないパーティクルを示す情報が格納されているレコードの制約条件の候補欄１１５ｅに格納されている数値に、ステップＳ７４で特定した数値を加算する。

次に、制限候補情報更新部１２４は、オリジナルスキーマ１１３ａにおける要素宣言Ｄの子要素内に、ａｎｙ要素があるか否かを判断する（Ｓ７６）。そして、ａｎｙ要素がある場合には（ステップＳ７６でＹｅｓ）ステップＳ７７に進み、ない場合には（ステップＳ７６でＮｏ）処理を終了する。

ステップＳ７６では、制限候補情報更新部１２４は、ステップＳ６０で取得したリストＬにおいて、ａｎｙ要素に対応する子要素の出現回数と、当該子要素を示す情報と、を特定し、第二制限候補テーブル１１５ｇの対応する二つのレコードを選択して、特定した出現回数を示す情報と、特定した子要素を示す情報と、を追加等する。

具体的には、制限候補情報更新部１２４は、第二制限候補テーブル１１５ｇにおいて、要素宣言ＩＤ欄１１５ｉに要素宣言Ｄのｎａｍｅ属性の値を示す情報が格納され、パーティクルＩＤ欄１１５ｊに「ａｎｙ」を示す情報が格納され、制約条件の種別欄１１５ｋに「出現回数」を示す情報が格納されているレコードを選択し、制約条件の候補欄１１５ｅに格納されている数値に、ステップＳ７６で特定した出現回数を加算する。

また、制限候補情報更新部１２４は、第二制限候補テーブル１１５ｇにおいて、要素宣言ＩＤ欄１１５ｉに要素宣言Ｄのｎａｍｅ属性の値を示す情報が格納され、パーティクルＩＤ欄１１５ｊに「ａｎｙ」を示す情報が格納され、制約条件の種別欄１１５ｋに「出現要素」を示す情報が格納されているレコードを選択し、制約条件の候補欄１１５ｅに、ステップＳ７７で特定した子要素を示す情報が格納されていない場合には、当該子要素を示す情報を追加する。

以上に記載した図１６のフローチャートにおける処理を、図４に示すオリジナルスキーマ１１３ａ及び図５に示すサンプルデータ１１４ａに基づいて、具体的に説明する。ここで、第二制限候補テーブル１１５ｇは初期状態であって、制限候補情報を格納するレコードは設けられていないものとして説明する。

まず、要素Ｅがサンプルデータ１１４ａの０３行目から０６行目までのＣｕｓｔｏｍｅｒＩｎｆｏ要素である場合には、制限候補情報更新部１２４は、ＣｕｓｔｏｍｅｒＩｎｆｏ要素の子要素を特定し、リストＬを取得する（Ｓ６０）。ここで、ＣｕｓｔｏｍｅｒＩｎｆｏ要素は０４行目のＣｕｓｔｏｍｅｒＮａｍｅ要素と、０５行目のＴｅｌｅｐｈｏｎｅ要素と、の２つの子要素を持つため、リストＬとして、［ＣｕｓｔｏｍｅｒＮａｍｅ，Ｔｅｌｅｐｈｏｎｅ］を取得する。子要素のリストＬは、子要素の要素名をカンマ（，）で区切ることで各々の子要素を識別している。

次に、制限候補情報更新部１２４は、第二制限候補テーブル１１５ｇにＣｕｓｔｏｍｅｒＩｎｆｏ要素宣言のレコードがあるか判定する（Ｓ６１）。第二制限候補テーブル１１５ｇは、初期状態ではレコードを持たないためＣｕｓｔｏｍｅｒＩｎｆｏ要素のレコードはない。そのため、ステップＳ６２に進む。

次に、制限候補情報更新部１２４は、ＣｕｓｔｏｍｅｒＩｎｆｏ要素宣言内にｃｈｏｉｃｅ要素があるか否かを判定する（Ｓ６２）。

ここで、オリジナルスキーマ１１３ａには、１５行目から１８行目までにｃｈｏｉｃｅ要素があるため、ステップＳ６３に進む。

ステップＳ６３では、制限候補情報更新部１２４は、オリジナルスキーマ１１３ａよりｃｈｏｉｃｅ要素（１５行目から１８行目）を取得する。

ここで、取得したｃｈｏｉｃｅ要素の子要素には、１６行目のｅｌｅｍｅｎｔ要素（＜ｅｌｅｍｅｎｔ ｒｅｆ＝“Ｔｅｌｅｐｈｏｎｅ”＞）と１７行目のｅｌｅｍｅｎｔ要素（＜ｅｌｅｍｅｎｔ ｒｅｆ＝“Ｅｍａｉｌ”＞）の２つのパーティクルが存在する。これは、ＸＭＬ文書の対応する箇所にＴｅｌｅｐｈｏｎｅ要素かＥｍａｉｌ要素のどちらかが出現しなくてはならないという制約条件を表す。

次に、制限候補情報更新部１２４は、ステップＳ７１で取得したｃｈｏｉｃｅ要素の子要素のパーティクルのうち、サンプルデータ１１４ａにおいて選択されたものを特定し、第二制限候補テーブル１１５ｇに格納する（Ｓ７２）。

具体的には、制限候補情報更新部１２４は、ステップＳ６０で取得したＣｕｓｔｏｍｅｒＩｎｆｏ要素の子要素のリストＬ［ＣｕｓｔｏｍｅｒＮａｍｅ，Ｔｅｌｅｐｈｏｎｅ］から、ｃｈｏｉｃｅ要素の子要素のパーティクルであるＴｅｌｅｐｈｏｎｅ要素とＥｍａｉｌ要素のうち、Ｔｅｌｅｐｈｏｎｅ要素の方が出現していることが分かる。よって、サンプルデータ１１４ａにおいて選択されたのは１６行目のｅｌｅｍｅｎｔ要素（＜ｅｌｅｍｅｎｔ ｒｅｆ＝“Ｔｅｌｅｐｈｏｎｅ”＞）であることが分かる。ここで、本ｅｌｅｍｅｎｔ要素のパーティクルＩＤを「Ｔｅｌｅｐｈｏｎｅ」とする。

そして、制限候補情報更新部１２４は、第二制限候補テーブル１１５ｇに新たなレコードを追加して、ＩＤ欄１１５ｈには、上方のレコードから連番となるようにＩＤの値を格納し、要素宣言ＩＤ欄１１５ｉには、処理対象となっているＣｕｓｔｏｍｅｒＩｎｆｏ要素の要素宣言ＩＤである「ＣｕｓｔｏｍｅｒＩｎｆｏ」を格納し、パーティクルＩＤ欄１１５ｊには、処理対象となっているｃｈｏｉｃｅ要素のパーティクルＩＤである「ｃｈｏｉｃｅ」を格納し、制約条件の種別欄１１５ｋには「出現パーティクル」を格納し、制約条件の候補欄１１５ｌには、サンプルデータ１１４ａにおいて選択されたパーティクルのパーティクルＩＤである「Ｔｅｌｅｐｈｏｎｅ」を格納する。

次に、制限候補情報更新部１２４は、ＣｕｓｔｏｍｅｒＩｎｆｏ要素宣言内に、出現回数が固定でないパーティクルがあるか否かを判定する（Ｓ６５）。

ここで、ＣｕｓｔｏｍｅｒＩｎｆｏ要素宣言内に含まれるパーティクルは、全てｍｉｎＯｃｃｕｒｓ属性及びｍａｘＯｃｃｕｒｓ属性を省略しているため、出現回数が１回に固定されており、出現回数が固定でないパーティクルは存在しない。従って、ステップＳ６８に進む。

次に、制限候補情報更新部１２４は、ＣｕｓｔｏｍｅｒＩｎｆｏ要素宣言内に、ａｎｙ要素があるか否かを判定する（Ｓ６８）。ここで、ＣｕｓｔｏｍｅｒＩｎｆｏ要素宣言内にａｎｙ要素は存在しないため、制限候補情報更新部１２４は、ＣｕｓｔｏｍｅｒＩｎｆｏ要素に対する制限候補情報の更新処理を終了する。

次に、要素Ｅがサンプルデータ１１４ａの０７行目から１０行目までのＰｕｒｃｈａｓｅＩｎｆｏ要素である場合には、制限候補情報更新部１２４は、ＰｕｒｃｈａｓｅＩｎｆｏ要素の子要素を特定し、リストＬを取得する（Ｓ６０）。ここで、ＰｕｒｃｈａｓｅＩｎｆｏ要素の子要素のリストＬは、［ＰｒｏｄｕｃｔＮａｍｅ，Ｑｕａｎｔｉｔｙ］となる。

次に、制限候補情報更新部１２４は、第二制限候補テーブル１１５ｇにＰｕｒｃｈａｓｅＩｎｆｏ要素宣言に対応する情報があるか判定する（Ｓ６１）。ここでは、第二制限候補テーブル１１５ｇには、ＰｕｒｃｈａｓｅＩｎｆｏ要素宣言の情報はないものとする。そのため、ステップＳ６２に進む。

次に、制限候補情報更新部１２４は、ＰｕｒｃｈａｓｅＩｎｆｏ要素宣言内に、ｃｈｏｉｃｅ要素があるか否かを判定する（Ｓ６２）。ここで、オリジナルスキーマ１１３ａのＰｕｒｃｈａｓｅＩｎｆｏ要素宣言（２２行目から３０行目）には、ｃｈｏｉｃｅ要素は存在しないため、ステップＳ６５に進む。

次に、制限候補情報更新部１２４は、ＰｕｒｃｈａｓｅＩｎｆｏ要素宣言内に、出現回数が固定でないパーティクルがあるか否かを判定する（Ｓ６５）。ここで、ＰｕｒｃｈａｓｅＩｎｆｏ要素宣言内に含まれるパーティクルのうち２７行目のａｎｙ要素は、ｍｉｎＯｃｃｕｒｓ属性が０であり、ｍａｘＯｃｃｕｒｓ属性がｕｎｂｏｕｎｄｅｄであることから、出現回数が固定ではないことがわかり、ステップＳ６６に進む。

ステップＳ６６では、制限候補情報更新部１２４は、このａｎｙ要素の情報（２７行目）を取得する。ここで、このａｎｙ要素のパーティクルＩＤは簡単のため「ａｎｙ」とする。

次に、制限候補情報更新部１２４は、ステップＳ６７の処理として、以下の処理を行う。

まず、制限候補情報更新部１２４は、ステップＳ６６で取得したａｎｙ要素の出現回数を、ステップＳ６０で取得した子要素のリストＬ［ＰｒｏｄｕｃｔＮａｍｅ，Ｑｕａｎｔｉｔｙ］から特定する。ここで、子要素のリストＬ［ＰｒｏｄｕｃｔＮａｍｅ，Ｑｕａｎｔｉｔｙ］には、ａｎｙ要素に対応した要素は出現しておらず、ａｎｙ要素の出現回数は０回であることが分かる。なお、ａｎｙ要素に対応した要素であるか否かは、ａｎｙ要素以外の要素に対応する子要素をリストＬから差し引けばよい。

そして、制限候補情報更新部１２４は、第二制限候補テーブル１１５ｇに新たなレコードを追加して、ＩＤ欄１１５ｈには、情報のレコードから連番となるＩＤの値を格納し、要素宣言ＩＤ欄１１５ｉには、処理対象となっているＰｕｒｃｈａｓｅＩｎｆｏ要素の要素宣言ＩＤである「ＰｕｒｃｈａｓｅＩｎｆｏ」を格納し、パーティクルＩＤ欄１１５ｊには、処理対象となっているａｎｙ要素のパーティクルＩＤである「ａｎｙ」を格納し、制約条件の種別欄１１５ｋには、「出現回数」を格納し、制約条件の候補欄１１５ｌには、ａｎｙ属性の出現回数である「０」を格納する。

次に、制限候補情報更新部１２４は、ＰｕｒｃｈａｓｅＩｎｆｏ要素宣言内に、ａｎｙ要素があるか否かを判定する（Ｓ６８）。ここで、オリジナルスキーマ１１３ａのＰｕｒｃｈａｓｅＩｎｆｏ要素宣言（２２行目から３０行目）には、ａｎｙ要素が存在するため（２７行目）、ステップＳ６９に進む。

そして、制限候補情報更新部１２４は、ステップＳ６９での処理として以下の処理を行う。

まず、制限候補情報更新部１２４は、ａｎｙ要素と対応するサンプルデータ１１４ａ内の要素を取得する。ここで、ステップＳ６０で取得した子要素のリストＬ［ＰｒｏｄｕｃｔＮａｍｅ，Ｑｕａｎｔｉｔｙ］から、サンプルデータ１１４ａにはａｎｙ要素に対応した要素は出現していない。

そして、制限候補情報更新部１２４は、以上により得られた情報を第二制限候補テーブル１１５ｇに格納する。

具体的には、第二制限候補テーブル１１５ｇに新たなレコードを追加して、ＩＤ欄１１５ｈには、情報のレコードから連番となるＩＤの値を格納し、要素宣言ＩＤ欄１１５ｉには、処理対象となっているＰｕｒｃｈａｓｅＩｎｆｏ要素の要素宣言ＩＤである「ＰｕｒｃｈａｓｅＩｎｆｏ」を格納し、パーティクルＩＤ欄１１５ｊには、処理対象となっているａｎｙ要素のパーティクルＩＤである「ａｎｙ」を格納し、制約条件の種別欄１１５ｋには、「出現要素」を格納し、制約条件の候補欄１１５ｌには、ａｎｙ属性に対応した要素が存在しないため、空欄とする。

以上で、ＰｕｒｃｈａｓｅＩｎｆｏ要素に対する制限候補情報の更新処理を終了する。

次に、要素Ｅがサンプルデータ１１４ａの１１行目から１５行目までのＰｕｒｃｈａｓｅＩｎｆｏ要素である場合には、制限候補情報更新部１２４は、ＰｕｒｃｈａｓｅＩｎｆｏ要素の子要素を特定し、リストＬを取得する（Ｓ６０）。ここで、ＰｕｒｃｈａｓｅＩｎｆｏ要素の子要素のリストＬは、［ＰｒｏｄｕｃｔＮａｍｅ，Ｑｕａｎｔｉｔｙ，Ｄｉｓｃｏｕｎｔ］となる。

次に、制限候補情報更新部１２４は、第二制限候補テーブル１１５ｇにＰｕｒｃｈａｓｅＩｎｆｏ要素宣言に対応するレコードがあるか判定する（Ｓ６１）。ここでは、既に、サンプルデータ１１４ａの０７行目から１０行目までのＰｕｒｃｈａｓｅＩｎｆｏ要素に対する処理を行った結果、第二制限候補テーブル１１５ｇにＰｕｒｃｈａｓｅＩｎｆｏ要素宣言に対応するレコードがあるため、ステップＳ７０に進む。

ステップＳ７０では、制限候補情報更新部１２４は、ＰｕｒｃｈａｓｅＩｎｆｏ要素宣言内に、ｃｈｏｉｃｅ要素があるか否かを判定する。ここで、オリジナルスキーマ１１３ａのＰｕｒｃｈａｓｅＩｎｆｏ要素宣言（２２行目から３０行目）には、ｃｈｏｉｃｅ要素は存在しないため、ステップＳ７３に進む。

次に、制限候補情報更新部１２４は、ＰｕｒｃｈａｓｅＩｎｆｏ要素宣言内に、出現回数が固定でないパーティクルがあるか否かを判定する（Ｓ７３）。ここで、ＰｕｒｃｈａｓｅＩｎｆｏ要素宣言内に含まれるパーティクルのうち２７行目のａｎｙ要素は、ｍｉｎＯｃｃｕｒｓ属性が０であり、ｍａｘＯｃｃｕｒｓ属性がｕｎｂｏｕｎｄｅｄであることから、出現回数が固定でないことが分かり、ステップＳ７４に進む。

ステップＳ７４では、制限候補情報更新部１２４は、このａｎｙ要素の情報（２７行目）を取得する。ここで、このａｎｙ要素のパーティクルＩＤは簡単のため「ａｎｙ」とする。

次に、制限候補情報更新部１２４は、ステップＳ７５の処理として、以下の処理を行う。

まず、制限候補情報更新部１２４は、ステップＳ７４で取得したａｎｙ要素の出現回数を、ステップＳ６０で取得した子要素のリストＬ［ＰｒｏｄｕｃｔＮａｍｅ，Ｑｕａｎｔｉｔｙ，Ｄｉｓｃｏｕｔ］から特定する。ここで、子要素のリストＬ［ＰｒｏｄｕｃｔＮａｍｅ，Ｑｕａｎｔｉｔｙ，Ｄｉｓｃｏｕｔ］には、ａｎｙ要素に対応した要素［Ｄｉｓｃｏｕｔ］が出現しているため、要素［Ｄｉｓｃｏｕｔ］の出現回数（１回）を取得する。

そして、制限候補情報更新部１２４は、第二制限候補テーブル１１５ｇにおいて、要素宣言ＩＤ欄１１５ｉに「ＰｕｒｃａｓｅＩｎｆｏ」が格納され、パーティクルＩＤ欄１１５ｊに「ａｎｙ」が格納され、制約条件の種別欄１１５ｋに「出現回数」が格納されているレコードを選択して、制約条件の候補欄１１５ｌに格納されている数値と、当該数値に要素［Ｄｉｓｃｏｕｔ］の出現回数（１回）を加算した数値と、の両方を含む出現回数（ここでは、０〜１）を格納する。

次に、制限候補情報更新部１２４は、ＰｕｒｃｈａｓｅＩｎｆｏ要素宣言内に、ａｎｙ要素があるか否かを判定する（Ｓ７６）。ここで、オリジナルスキーマ１１３ａのＰｕｒｃｈａｓｅＩｎｆｏ要素宣言（２２行目から３０行目）には、ａｎｙ要素が存在するため（２７行目）、ステップＳ７７に進む。

そして、制限候補情報更新部１２４は、ステップＳ７７での処理として以下の処理を行う。

まず、制限候補情報更新部１２４は、ａｎｙ要素と対応するサンプルデータ１１４ａ内の要素を取得する。ここで、ステップＳ６０で取得した子要素のリストＬ［ＰｒｏｄｕｃｔＮａｍｅ，Ｑｕａｎｔｉｔｙ，Ｄｉｓｃｏｕｎｔ］から、サンプルデータ１１４ａにはａｎｙ要素に対応した要素［Ｄｉｓｃｏｕｎｔ］が出現している。

そして、制限候補情報更新部１２４は、以上により得られた情報を第二制限候補テーブル１１５ｇに格納する。

具体的には、第二制限候補テーブル１１５ｇにおいて、要素宣言ＩＤ欄１１５ｉに「ＰｕｒｃａｓｅＩｎｆｏ」が格納され、パーティクルＩＤ欄１１５ｊに「ａｎｙ」が格納され、制約条件の種別欄１１５ｋに「出現要素」が格納されているレコードを選択して、制約条件の候補欄１１５ｌに「Ｄｉｓｃｏｕｎｔ」が格納されていない場合には、当該欄に「Ｄｉｓｃｏｕｎｔ」を格納する。

以上で、ＰｕｒｃｈａｓｅＩｎｆｏ要素に対する制限候補情報の更新処理を終了する。

次に、要素Ｅがサンプルデータ１１４ａの０１行目から１６行目までのＰｕｒｃｈａｓｅＯｒｄｅｒ要素である場合には、制限候補情報更新部１２４は、ＰｕｒｃｈａｓｅＯｒｄｅｒ要素の子要素を特定し、リストＬを取得する（Ｓ６０）。ここで、ＰｕｒｃｈａｓｅＯｒｄｅｒ要素の子要素のリストＬは、［ＣｕｓｔｏｍｅｒＮａｍｅ，Ｔｅｌｅｐｈｏｎｅ，ＣｕｓｔｏｍｅｒＩｎｆｏ，ＰｒｏｄｕｃｔＮａｍｅ，Ｑｕａｎｔｉｔｙ，ＰｕｒｃｈａｓｅＩｎｆｏ，ＰｒｏｄｕｃｔＮａｍｅ，Ｑｕａｎｔｉｔｙ，Ｄｉｓｃｏｕｎｔ，ＰｕｒｃｈａｓｅＩｎｆｏ］となる。

次に、制限候補情報更新部１２４は、第二制限候補テーブル１１５ｇにＰｕｒｃｈａｓｅＯｒｄｅｒ要素宣言に対応する情報があるか判定する（Ｓ６１）。ここでは、第二制限候補テーブル１１５ｇには、ＰｕｒｃｈａｓｅＯｒｄｅｒ要素宣言の情報はないものとする。そのため、ステップＳ６２に進む。

次に、制限候補情報更新部１２４は、ＰｕｒｃｈａｓｅＯｒｄｅｒ要素宣言内に、ｃｈｏｉｃｅ要素があるか否かを判定する（Ｓ６２）。ここで、オリジナルスキーマ１１３ａのＰｕｒｃｈａｓｅＯｒｄｅｒ要素宣言（０３行目から１０行目）には、ｃｈｏｉｃｅ要素は存在しないため、ステップＳ６５に進む。

次に、制限候補情報更新部１２４は、ＰｕｒｃｈａｓｅＯｒｄｅｒ要素宣言内に、出現回数が固定でないパーティクルがあるか否かを判定する（Ｓ６５）。ここで、ＰｕｒｃｈａｓｅＯｒｄｅｒ要素宣言内に含まれるパーティクルのうち０７行目のＰｕｒｃｈａｓｅＩｎｆｏ要素は、ｍａｘＯｃｃｕｒｓ属性がｕｎｂｏｕｎｄｅｄであることから、出現回数が固定ではないことがわかり、ステップＳ６６に進む。

ステップＳ６６では、制限候補情報更新部１２４は、このＰｕｒｃｈａｓｅＩｎｆｏ要素の情報（０７行目）を取得する。ここで、このＰｕｒｃｈａｓｅＩｎｆｏ要素のパーティクルＩＤは簡単のため「ＰｕｒｃｈａｓｅＩｎｆｏ」とする。

次に、制限候補情報更新部１２４は、ステップＳ６７の処理として、以下の処理を行う。

まず、制限候補情報更新部１２４は、ステップＳ６６で取得したＰｕｒｃｈａｓｅＩｎｆｏ要素の出現回数を、ステップＳ６０で取得した子要素のリストＬから特定する。ここで、子要素のリストＬには、ＰｕｒｃｈａｓｅＩｎｆｏ要素に対応した要素は２回出現しているため、ＰｕｒｃｈａｓｅＩｎｆｏ要素の出現回数は２回であることがわかる。

そして、制限候補情報更新部１２４は、第二制限候補テーブル１１５ｇに新たなレコードを追加して、ＩＤ欄１１５ｈには、情報のレコードから連番となるＩＤの値を格納し、要素宣言ＩＤ欄１１５ｉには、処理対象となっているＰｕｒｃｈａｓｅＯｒｄｅｒ要素の要素宣言ＩＤである「ＰｕｒｃｈａｓｅＯｒｄｅｒ」を格納し、パーティクルＩＤ欄１１５ｊには、処理対象となっているＰｕｒｃｈａｓｅＩｎｆｏ要素のパーティクルＩＤである「ＰｕｒｃｈａｓｅＩｎｆｏ」を格納し、制約条件の種別欄１１５ｋには、「出現回数」を格納し、制約条件の候補欄１１５ｌには、ＰｕｒｃｈａｓｅＩｎｆｏ要素の出現回数である「２」を格納する。

次に、制限候補情報更新部１２４は、ＰｕｒｃｈａｓｅＯｒｄｅｒ要素宣言内に、ａｎｙ要素があるか否かを判定する（Ｓ６８）。ここで、オリジナルスキーマ１１３ａのＰｕｒｃｈａｓｅＯｒｄｅｒ要素宣言（０３行目から１０行目）には、ａｎｙ要素が存在しないため、ＰｕｒｃｈａｓｅＯｒｄｅｒ要素に対する制限候補情報の更新処理を終了する。

以上により、サンプルデータ１１４ａ内の全ての要素について、図１５又は図１６の処理を実行したため、制限候補情報の更新処理は終了する。

以上のように、本実施形態によれば、サンプルデータ１１４ａを用いて、オリジナルスキーマ１１３ａをより厳しく制限した変換後スキーマ１１６ａを生成することができる。このため、例えば、スキーマ変換装置１００のオペレータは、システムにおいて許可することのできる最大限に緩い制限となるサンプルデータを少なくとも一つ以上作成しておくことで、このようなサンプルデータが妥当と判断される最も厳格なスキーマを容易に生成することができるようになる。

例えば、本実施形態におけるスキーマ変換装置１００は、図１７（Ｗｅｂサービスシステム１７０の概略図）に示すＷｅｂサービスシステム１７０において使用することができる。

図示するように、Ｗｅｂサービスシステム１７０は、スキーマ変換装置１００と、メッセージ受信装置１７１と、スキーマ検証装置１７２と、アプリケーションサーバ装置１７３と、を備え、これらの装置は、ネットワーク１８０を介して、相互に情報を送受信することができる。

メッセージ受信装置１７１は、Ｗｅｂサービスクライアント（図示せず）から受信したメッセージををスキーマ検証装置１７２に送信する。ここでは、メッセージの全体又は一部分である検証前ＸＭＬ文書をスキーマ検証装置１７２に送信する。これは、例えばＳＯＡＰメッセージの本体部分であるＳＯＡＰボディの内容を取り出し、検証前ＸＭＬ文書としてスキーマ検証装置に送信する処理などが考えられる。

そして、スキーマ検証装置１７２においては、受信した検証前ＸＭＬ文書のスキーマ検証を実行する。ここで、スキーマ検証装置１７２は、スキーマ変換装置１００で生成された変換後スキーマを用いて、スキーマ検証を実行する。

そして、検証前ＸＭＬ文書が、スキーマ変換装置１００により生成された変換後スキーマに対して妥当である場合には、スキーマ検証装置１７２は、検証済みＸＭＬ文書をアプリケーションサーバ装置１７３に送信する。

このような検証済みＸＭＬ文書を受信したアプリケーションサーバ装置１７３は、検証済みＸＭＬ文書を用いて、例えば、商品の受注処理や旅行の予約処理など、何らかの業務処理を実行する。

なお、図１７に示した例では、アプリケーションサーバ装置１７３で提供するサービスにおいて、安全と判断されるサンプルデータを用いてスキーマ変換装置１００において変換後スキーマを生成しておくことで、アプリケーションサーバ装置１７３のセキュリティを確保することができるようになる。

また、図１７で示した例では、Ｗｅｂサービスシステム１７０での全体の処理を、スキーマ変換装置１００、メッセージ受信装置１７１、スキーマ検証装置１７２及びアプリケーションサーバ装置１７３とで分担して行っているが、このような態様に限定されず、Ｗｅｂサービスシステム１７０での全体の処理を分担する態様は、任意の態様を選択可能である。例えば、Ｗｅｂサービスシステム１７０での全体の処理をスキーマ変換装置１００だけで行うようにすることも可能であり、Ｗｅｂサービスシステム１７０での任意の処理をスキーマ変換装置１００で行うようにすることも可能である。

以上に記載した実施形態においては、図１５に記載したフローチャートにおいて、要素内容のデータ型と値の長さについてより制限を厳しくすることができるようにしているが、このような態様に限定されず、例えば、要素内容から、出現する文字列や、特殊記号の有無、整数値の範囲（最小値と最大値、正の値又は負の値）等の制限を厳しくするようにすることも可能である。

また、以上に記載した実施形態においては、サンプルデータ１１４ａを用いて要素に関する制限をより厳しくするようにしているが、このような態様に限定されず、属性に関しても、例えば、図１５と同様の処理で、属性値の値の範囲を限定することができ、また、図１６と同様な処理で、ａｎｙＡｔｒｉｂｕｔｅ属性値として出現する属性の限定等を行うことができる。

図１８は、本発明の第二の実施形態であるスキーマ変換装置２００の概略図である。

図示するように、スキーマ変換装置２００は、記憶部１１０と、制御部２２０と、入力部１３０と、出力部１４０と、通信部１５０と、を備え、第一の実施形態と比較して、制御部２２０が異なっているため、以下、制御部２２０に関連する事項について説明する。

制御部２２０は、全体制御部１２１と、スキーマ検証部１２２と、探索部１２３と、制限候補情報更新部１２４と、スキーマ変換部２２５と、スキーマ編集部２２６と、を備え、第一の実施形態と比較して、スキーマ変換部２２５及びスキーマ編集部２２６が異なっているため、以下これらに関連する事項について説明する。

スキーマ変換部２２５は、制限候補情報記憶領域１１５に記憶されている制限候補のうち、後述するスキーマ編集部２２６において、スキーマ変換装置２００のオペレータより制限の許可の入力を受け付けたものをオリジナルスキーマ１１３ａに適用することで、スキーマの変換を行い、変換後スキーマを生成する。

スキーマ編集部２２６は、制限候補情報記憶領域１１５に記憶されている制限候補を出力部１４０に出力し、当該制限候補うち、オリジナルスキーマ１１３ａに適用する制限候補の入力を、入力部１３０を介して受け付け、受け付けた制限候補をスキーマ変換部２２５に通知する。

例えば、本実施形態においては、図１９（エディタ画面２２６ａの概略図）に示すようなエディタ画面２２６ａを出力部１４０に出力することで、オペレータより制限候補の選択を受け付ける。

エディタ画面２２６ａは、オリジナルスキーマ表示領域２２６ｂと、行数表示領域２２６ｃと、を備える。

そして、行数表示領域２２６ｃには、制限候補情報記憶領域１１５に記憶されている制限候補が存在するパーティクルの行数に隣接する位置（図１９では、向かって右横の所定位置）に、制限候補が存在することを示すマーク２２６ｄが配置される。

そして、このマーク２２６ｄを指定した実行指示の入力を、入力部１３０を介して受け付けると、スキーマ編集部２２６は、当該マーク２２６ｄに関連するパーティクルに隣接した位置（図１９では、下方の所定位置）に、制限候補を特定する情報が表示される。

そして、スキーマ編集部２２６は、表示された制限候補を特定した実行指示の入力を、入力部１３０を介して受け付けることで（例えば、ダブルクリック等）、入力を受け付けた制限候補をスキーマ変換部２２５に通知する。

なお、このような通知を受けたスキーマ変換部２２５は、通知で特定される変換候補による変換をオリジナルスキーマ１１３ａに対して実行する。

図２０は、スキーマ変換装置２００における制限候補の選択処理を示すフローチャートである。

まず、スキーマ編集部２２６は、例えば、図１９に示すエディタ画面２２６ａを出力部１４０に表示して、別ウィンドウにて表示する制限候補の入力を受け付ける（Ｓ８０）。

そして、スキーマ編集部２２６は、入力部１３０を介して、行数表示領域２２６ｃに配置されているマーク２２６ｄを指定した実行指示の入力を受け付けると、入力された制限候補を特定する情報を表示する（Ｓ８１）。

ここでは、スキーマ編集部２２６は、ステップＳ８０で選択されたマーク２２６ｄに関連する行数で特定されるパーティクルの要素宣言ＩＤが、第一制限候補テーブル１１５ａの要素宣言ＩＤ欄１１５ｃ、または、第二制限候補テーブル１１５ｇの要素宣言ＩＤ欄１１５ｉ、に格納されているレコードを特定し、特定したレコードより、少なくとも制約条件の種別欄１１５ｄ、１１５ｋ及び制約条件の候補欄１１５ｅ、１１５ｌに格納されている情報を抽出し、抽出した情報を所定の表示形式に編集して、エディタ画面２２６ａの所定の位置に表示する。

そして、スキーマ編集部２２６は、入力部１３０を介して、表示した制限候補を特定した実行指示の入力を受け付けると、選択された制限候補に対応する第一制限候補テーブル１１５ａ又は第二制限候補テーブル１１５ｇのレコードに格納されている情報をスキーマ変換部２２５に通知し、スキーマ変換部２２５は、オリジナルスキーマ１１３ａの変換を実行する（Ｓ８３）。なお、変換を行った制限候補については、マーク２２６ｄを外したり、既に処理済みであることを明示したりする等の処理を行うことが望ましい。

ステップＳ８０〜Ｓ８３までの処理は、入力部１３０を介して、編集の終了の指示の入力を受け付けるまで行う（Ｓ８４）。

そして、スキーマ変換部２２５は、変換後スキーマを変換後スキーマ記憶領域１１６に記憶する（Ｓ８５）。

以上のように、本実施形態においては、オリジナルスキーマ１１３ａの変換を行う前に、変換候補を表示して、オペレータの選択を受け付けることで、オペレータが望まない変換が行われてしまうことを防止することができる。このような場合でも、変換候補は、サンプルデータ１１４ａに基づいて既に絞り込まれているため、オペレータは効率的に変換候補を選択することができる。

なお、以上に記載した実施形態においては、設定情報記憶領域１１２に記憶されている設定情報に基づいて制限候補を絞り込んでから、制限候補の選択を受け付けているが、このような態様に限定されず、設定情報記憶領域１１２に記憶されている設定情報に基づいて制限候補を絞り込まずに、スキーマ編集部２２６による編集処理を行ってもよい。

図２１は、本発明の第三の実施形態であるＷｅｂサービスシステム３７０の概略図である。

図示するように、Ｗｅｂサービスシステム３７０は、スキーマ変換装置３００と、クライアント端末３７４と、を備え、これらはネットワーク３８１を介して、相互に情報の送受信を行うことができるようにされている。

ここで、クライアント端末３７４は、通常のパーソナルコンピュータで構成可能であるため、詳細な説明を省略する。

図２２は、スキーマ変換装置３００の概略図である。

図示するように、スキーマ変換装置３００は、記憶部３１０と、制御部３２０と、入力部１３０と、出力部１４０と、通信部１５０と、を備える。

記憶部３１０は、スキーマリポジトリ記憶領域１１１と、設定情報記憶領域１１２と、オリジナルスキーマ記憶領域１１３と、サンプルデータ記憶領域１１４と、制限候補情報記憶領域１１５と、変換後スキーマ記憶領域１１６と、ログ情報記憶領域３１７と、を備え、第一の実施形態と比較して、ログ情報記憶領域３１７が追加されているため、以下、ログ情報記憶領域３１７に関連する事項について説明する。

ログ情報記憶領域３１７には、スキーマ検証部１２２において、スキーマ検証の対象となったＸＭＬ文書が、変換後スキーマに対しては妥当ではないが、オリジナルスキーマに対しては妥当であると判断された場合に、当該ＸＭＬ文書を特定する情報と、当該ＸＭＬ文書が、変換後スキーマに対しては妥当ではないが、オリジナルスキーマに対しては妥当であることを特定する情報と、が関連付けられて記憶される。

制御部３２０は、全体制御部１２１と、スキーマ検証部１２２と、探索部１２３と、制限候補情報更新部１２４と、スキーマ変換部１２５と、ログ取得部３２７と、アプリケーション部３２８と、を備え、第一の実施形態と比較して、ログ取得部３２７及びアプリケーション部３２８が異なっているため、以下これらに関連する事項について説明する。

ログ取得部３２７は、スキーマ検証部１２２において、スキーマ検証の対象となったＸＭＬ文書が、変換後スキーマに対しては妥当ではないが、オリジナルスキーマに対しては妥当であると判断された場合に、当該ＸＭＬ文書を特定する情報と、当該ＸＭＬ文書が、変換後スキーマに対しては妥当ではないが、オリジナルスキーマに対しては妥当であることを特定する情報と、が関連付けてログ情報としてログ情報記憶領域３１７に記憶する。

また、ログ取得部３２７は、スキーマ検証部１２２において、スキーマ検証の対象であるＸＭＬ文書が、オリジナルスキーマ１１３ａに対しては妥当であり、変換後スキーマ１１６ａに対しては妥当ではないと判断された場合に、当該ＸＭＬ文書のログ情報を、当該ＸＭＬ文書を送信してきたクライアント端末３７４に送信する処理を行う。

アプリケーション部は、スキーマ検証部１２２において妥当と判断された検証済みＸＭＬ文書を用いて、例えば、商品の受注処理や旅行の予約処理など、何らかの業務処理を実行する。

図２３は、スキーマ変換装置３００においてＸＭＬ文書の検証する際の処理を示すフローチャートである。

まず、スキーマ変換装置３００では、全体制御部１２１が、通信部１５０を介して、クライアント端末３７４よりＸＭＬ文書を受信する（Ｓ９０）。

次に、スキーマ検証部１２２は、変換後スキーマ記憶領域１１６に記憶されている変換後スキーマを用いて、ステップＳ９０で受信したＸＭＬ文書のスキーマ検証を行う（Ｓ９１）。

そして、スキーマ検証部１２２は、ＸＭＬ文書が変換後スキーマ１１６ａに対して妥当か否かを判断し（Ｓ９２）、妥当である場合には（ステップＳ９２でＹｅｓ）ステップＳ９３に進み、妥当でない場合には（ステップＳ９２でＮｏ）ステップＳ９４に進む。

ステップＳ９３では、スキーマ検証部１２２は、妥当と判断された検証済みＸＭＬ文書をアプリケーション部３２８に出力する。

一方、ステップＳ９４では、スキーマ検証部１２２は、ステップＳ９２で変換後スキーマに対して妥当ではないと判断されたＸＭＬ文書を、オリジナルスキーマ記憶領域１１３に記憶されているオリジナルスキーマ１１３ａを用いて、スキーマ検証を行う。

そして、スキーマ検証部１２２は、ＸＭＬ文書がオリジナルスキーマ１１３ａに対して妥当か否かを判断し（Ｓ９５）、妥当である場合には（ステップＳ９５でＹｅｓ）ステップＳ９６に進み、妥当でない場合には（ステップＳ９５でＮｏ）ステップＳ９７に進む。

ステップＳ９６では、ログ取得部３２７は、スキーマ検証の対象となったＸＭＬ文書がを特定する情報と、当該ＸＭＬ文書が、変換後スキーマに対しては妥当ではないが、オリジナルスキーマに対しては妥当であることを特定する情報と、が関連付けてログ情報としてログ情報記憶領域３１７に記憶する。

ステップＳ９７では、全体制御部１２１は、ＸＭＬ文書がスキーマ検証で妥当でないと判断された旨を通知するエラーメッセージ（ログ情報がある場合には、当該ログ情報を添付して）をクライアント端末３７４に送信する。

以上のような処理を行うことにより、スキーマの変換を行うことにより、スキーマ検証の結果が異なることとなった履歴（ログ）を取得することができ、当該履歴（ログ）を分析することで、スキーマ変換の妥当性を判断することができるようになる。

以上に記載した実施形態においては、制約条件の厳しい変換後スキーマを用いて、ＸＭＬ文書のスキーマ検証を実施するようにしている。しかしながら、スキーマ文書の利用用途はスキーマ検証だけではなく、他の用途に使用してもよい。

例えば、変換後スキーマをＷＳＤＬの中に含めてインターフェースとして公開してもよい。また、ＪＡＸＢ（Java Architecture for XML Binding）などのデータバインディングツールでは、スキーマ文書の情報を元にＪａｖａ（登録商標）のクラスを生成することができる。変換後ツールは、ＪＡＸＢを用いてＪａｖａ（登録商標）のクラスを生成する際に利用してもよい。

また、制限候補情報を保存しておけば、同じもしくは類似するオリジナルスキーマに対して変換を再度行なう場合、容易に再変換を実施することができる。

オリジナルスキーマを制約条件の厳しいスキーマに変更した後に、オリジナルスキーマの方に修正が加わってしまう可能性がある。その場合、スキーマの変更を再度実施することが考えられる。スキーマの変更を手作業で行っている場合、このような作業は非常に負担が大きい。しかし、本発明を用いると、制限候補情に変更内容が含まれているため、制限候補情を保存しておくことで、容易に再変換が可能である。

また、本実施形態では、ａｎｙ要素による任意の要素の出現を許す制約条件を、具体的な要素、例えばＤｉｓｃｏｕｎｔ要素の出現だけを許す制約条件に変換する方法を説明した。ここでは具体的な要素名を特定できる場合を例に取り説明したが、具体的な要素名を特定することが困難な場合、例えば出現を許す要素の名前空間ＵＲＩや名前空間の種別を特定するように制約条件を変更してもよい。ａｎｙ要素ではｎａｍｅｓｐａｃｅ属性により出現を許す名前空間を特定することができる。例えば、ｎａｍｅｓｐａｃｅ属性に＃＃ｏｔｈｅｒを指定した場合、対象名前空間以外の名前空間に属する要素の出現を許す。また、ｎａｍｅｓｐａｃｅ属性に＃＃ｔａｒｇｅｔＮａｍｅｓｐａｃｅを指定すると、出現を許す具体的な名前空間ＵＲＬを指定することができる。

また、図４の２７行目のａｎｙ要素を変換する場合、例えばａｎｙ要素のｎａｍｅｓｐａｃｅ属性に＃＃ｏｔｈｅｒを設定することで、対象名前空間とは異なる名前空間に属するＤｉｓｃｏｕｎｔ要素の出現を許しつつ、対象名前空間に属する要素の出現を禁止することができるため、具体的な要素名を特定することなく制約条件を厳しくすることができる。また、＃＃ｔａｒｇｅｔＮａｍｅｓｐａｃｅを利用してＤｉｓｃｏｕｎｔ要素が属する名前空間ＵＲＩであるｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｏｒｇ／ｏｒｄｅｒを指定することで、ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｏｒｇ／ｏｒｄｅｒの名前空間ＵＲＩに属するもののみ出現を許すことができ、より制約条件を厳しくすることができる。

スキーマ変換装置の概略図。 スキーマ文書管理テーブルの概略図。 設定情報テーブルの概略図。 オリジナルスキーマの概略図。 サンプルデータの概略図。 第一制限候補テーブルの概略図。 第二制限候補テーブルの概略図。 変換後スキーマの概略図。 コンピュータの概略図。 スキーマ変換装置における全体の処理を示すフローチャート。 制限候補情報を更新する処理を示すフローチャート。 要素に対応する要素宣言のデータを取得する処理を示すフローチャート。 スキーマの概略図。 ｉｍｐｏｒｔ要素の概略図。 テキストデータの制限候補情報を更新する処理を示すフローチャート。 子要素の制限候補情報を更新する処理を示すフローチャート。 Ｗｅｂサービスシステムの概略図。 スキーマ変換装置の概略図。 エディタ画面の概略図。 制限候補の選択処理を示すフローチャート。 Ｗｅｂサービスシステムの概略図。 スキーマ変換装置の概略図。 ＸＭＬ文書の検証する際の処理を示すフローチャート。

符号の説明

１００、２００、３００ スキーマ変換装置
１１０ 記憶部
１１１ スキーマリポジトリ記憶領域
１１２ 設定情報記憶領域
１１３ オリジナルスキーマ記憶領域
１１４ サンプルデータ記憶領域
１１５ 制限候補情報記憶領域
１１６ 変換後スキーマ記憶領域
３１７ ログ情報記憶領域
１２０ 制御部
１２１ 全体制御部
１２２ スキーマ検証部
１２３ 探索部
１２４ 制限候補情報更新部
１２５、２２５ スキーマ変換部
２２６ スキーマ編集部
３２７ ログ取得部
３２８ アプリケーション部
１３０ 入力部
１４０ 出力部
１５０ 通信部

Claims (20)

1. スキーマ文書を生成するスキーマ変換装置であって、
   サンプルデータに含まれる要素を妥当と判断可能な最も厳しい制約条件を変換候補として、当該要素毎に取得する処理と、
   前記要素に対応する要素宣言をオリジナルスキーマより特定し、特定した要素宣言の要素内容における前記要素に対する制約条件を、前記変換候補として取得した制約条件に変換することで、前記スキーマ文書を生成する処理と、を行う制御部を備えること、
   を特徴とするスキーマ変換装置。
2. 請求項１に記載のスキーマ変換装置であって、
   前記制御部は、
   前記サンプルデータに含まれる要素を、深さ優先で探索し、帰りがけ順で探索された要素を妥当と判断可能な最も厳しい制約条件を変換候補として取得すること、
   を特徴とするスキーマ変換装置。
3. 請求項２に記載のスキーマ変換装置であって、
   前記オリジナルスキーマ内の要素宣言と、サンプルデータに含まれる要素を妥当と判断可能な最も厳しい制約条件と、を変換候補情報として記憶する記憶部を備え、
   前記制御部は、
   前記サンプルデータに含まれる要素を、深さ優先で探索し、帰りがけ順で探索された要素を妥当と判断可能な最も厳しい制約条件を変換候補として取得する処理と、
   前記変換候補情報において、前記サンプルデータに含まれる要素に対応する要素宣言に対応付けられている制約条件と、取得した制約条件と、を満たす最も厳しい制約条件を特定し、前記変換候補情報における制約条件を、特定した制約条件に変更する処理と、を行うこと、
   を特徴とするスキーマ変換装置。
4. 請求項１に記載のスキーマ変換装置であって、
   前記制御部は、
   予め定められた制約条件の厳しさの序列に従って、サンプルデータに含まれる要素を妥当と判断可能な最も厳しい制約条件を取得すること、
   を特徴とするスキーマ変換装置。
5. 請求項４に記載のスキーマ変換装置であって、
   前記序列は、包含されるデータ型が、包含するデータ型よりもより厳しいと判断されるものであること、
   を特徴とするスキーマ変換装置。
6. 請求項４に記載のスキーマ変換装置であって、
   前記序列は、要素内容の値の長さの範囲の狭いものが、より厳しいと判断されるものであること、
   を特徴とするスキーマ変換装置。
7. 請求項４に記載のスキーマ変換装置であって、
   前記序列は、要素内容として出現する要素の数の範囲の狭いものが、より厳しいと判断されるものであること、
   を特徴とするスキーマ変換装置。
8. 請求項４に記載のスキーマ変換装置であって、
   前記序列は、要素内容として出現する要素が、任意の要素の出現を認めているものよりも、特定の要素の出現を認めているものの方が、より厳しいと判断されるものであること、
   を特徴とするスキーマ変換装置。
9. 請求項１に記載のスキーマ変換装置であって、
   オリジナルスキーマの変更を許容する要素宣言と、制約条件の種別と、を特定する設定情報を記憶する記憶部を備え、
   前記制御部は、前記変換候補のうち、前記設定情報において特定されている要素宣言及び制約条件の種別に対応する制約条件を、前記オリジナルスキーマの制約条件と変換すること、
   を特徴とするスキーマ変換装置。
10. 請求項１に記載のスキーマ変換装置であって、
    前記制御部は、
    前記変換候補を出力部に表示する処理と、
    入力部を介して、表示された変換候補を適用するか否かの入力を受け付ける処理と、
    適用すると入力された変換候補に対応する制約条件と、前記オリジナルスキーマの制約条件と、の変換を行う処理と、を行うこと、
    を特徴とするスキーマ変換装置。
11. コンピュータを、スキーマ文書を生成するスキーマ変換装置として機能させるプログラムであって、
    前記コンピュータを、
    サンプルデータに含まれる要素を妥当と判断可能な最も厳しい制約条件を変換候補として、当該要素毎に取得する処理と、
    前記要素に対応する要素宣言をオリジナルスキーマより特定し、特定した要素宣言の要素内容における前記要素に対する制約条件を、前記変換候補として取得した制約条件に変換することで、前記スキーマ文書を生成する処理と、を行う制御手段として機能させること、
    を特徴とするプログラム。
12. 請求項１１に記載のプログラムであって、
    前記制御手段に、
    前記サンプルデータに含まれる要素を、深さ優先で探索し、帰りがけ順で探索された要素を妥当と判断可能な最も厳しい制約条件を変換候補として取得する処理を行わせること、
    を特徴とするプログラム。
13. 請求項１２に記載のプログラムであって、
    前記コンピュータを、前記オリジナルスキーマ内の要素宣言と、サンプルデータに含まれる要素を妥当と判断可能な最も厳しい制約条件と、を変換候補情報として記憶する記憶手段として機能させ、
    前記制御手段に、
    前記サンプルデータに含まれる要素を、深さ優先で探索し、帰りがけ順で探索された要素を妥当と判断可能な最も厳しい制約条件を変換候補として取得する処理と、
    前記変換候補情報において、前記サンプルデータに含まれる要素に対応する要素宣言に対応付けられている制約条件と、取得した制約条件と、を満たす最も厳しい制約条件を特定し、前記変換候補情報における制約条件を、特定した制約条件に変更する処理と、を行わせること、
    を特徴とするプログラム。
14. 請求項１１に記載のプログラムであって、
    前記制御手段に、
    予め定められた制約条件の厳しさの序列に従って、サンプルデータに含まれる要素を妥当と判断可能な最も厳しい制約条件を取得する処理を行わせること、
    を特徴とするプログラム。
15. 請求項１４に記載のプログラムであって、
    前記序列は、包含されるデータ型が、包含するデータ型よりもより厳しいと判断されるものであること、
    を特徴とするプログラム。
16. 請求項１４に記載のプログラムであって、
    前記序列は、要素内容の値の長さの範囲の狭いものが、より厳しいと判断されるものであること、
    を特徴とするプログラム。
17. 請求項１４に記載のプログラムであって、
    前記序列は、要素内容として出現する要素の数の範囲の狭いものが、より厳しいと判断されるものであること、
    を特徴とするプログラム。
18. 請求項１４に記載のプログラムであって、
    前記序列は、要素内容として出現する要素が、任意の要素の出現を認めているものよりも、特定の要素の出現を認めているものの方が、より厳しいと判断されるものであること、
    を特徴とするプログラム。
19. 請求項１４に記載のプログラムであって、
    前記制御手段に、
    前記変換候補を出力手段に表示する処理と、
    入力手段を介して、表示された変換候補を適用するか否かの入力を受け付ける処理と、
    適用すると入力された変換候補に対応する制約条件と、前記オリジナルスキーマの制約条件と、の変換を行う処理と、を行わせること、
    を特徴とするプログラム。
20. 制御部を有するスキーマ変換装置が、スキーマ文書を生成するスキーマ生成方法であって、
    前記制御部が、サンプルデータに含まれる要素を妥当と判断可能な最も厳しい制約条件を変換候補として、当該要素毎に取得する過程と、
    前記制御部が、前記要素に対応する要素宣言をオリジナルスキーマより特定し、特定した要素宣言の要素内容における前記要素に対する制約条件を、前記変換候補として取得した制約条件に変換することで、前記スキーマ文書を生成する処理と、を行う過程と、を備えること、
    を特徴とするスキーマ生成方法。

Images