(57)【要約】  【課題】  制約条件の厳しいスキーマを効率よく生成すること。  【解決手段】  探索部１２３は、サンプルデータ記憶領域１１４に記憶されているサンプルデータを探索し、各々の要素を特定する。そして、制限候補情報更新部１２４は、特定した要素を妥当と判断することのできる最も厳しい制約条件を求め、制限候補として制限候補情報記憶領域１１５に記憶する。スキーマ変換部１２５は、制限候補情報記憶領域１１５に記憶されている制限候補のうち、設定情報記憶領域１１２に記憶されている設定情報で、制限が許可されているものを特定して、オリジナルスキーマに適用して、変換後スキーマを生成する。【選択図】図１
2010026857.tif 000002
【特許請求の範囲】
【請求項１】
スキーマ文書を生成するスキーマ変換装置であって、
サンプルデータに含まれる要素を妥当と判断可能な最も厳しい制約条件を変換候補として、当該要素毎に取得する処理と、
前記要素に対応する要素宣言をオリジナルスキーマより特定し、特定した要素宣言の要素内容における前記要素に対する制約条件を、前記変換候補として取得した制約条件に変換することで、前記スキーマ文書を生成する処理と、を行う制御部を備えること、
を特徴とするスキーマ変換装置。
【請求項２】
請求項１に記載のスキーマ変換装置であって、
前記制御部は、
前記サンプルデータに含まれる要素を、深さ優先で探索し、帰りがけ順で探索された要素を妥当と判断可能な最も厳しい制約条件を変換候補として取得すること、
を特徴とするスキーマ変換装置。
【請求項３】
請求項２に記載のスキーマ変換装置であって、
前記オリジナルスキーマ内の要素宣言と、サンプルデータに含まれる要素を妥当と判断可能な最も厳しい制約条件と、を変換候補情報として記憶する記憶部を備え、
前記制御部は、
前記サンプルデータに含まれる要素を、深さ優先で探索し、帰りがけ順で探索された要素を妥当と判断可能な最も厳しい制約条件を変換候補として取得する処理と、
前記変換候補情報において、前記サンプルデータに含まれる要素に対応する要素宣言に対応付けられている制約条件と、取得した制約条件と、を満たす最も厳しい制約条件を特定し、前記変換候補情報における制約条件を、特定した制約条件に変更する処理と、を行うこと、
を特徴とするスキーマ変換装置。
【請求項４】
請求項１に記載のスキーマ変換装置であって、
前記制御部は、
予め定められた制約条件の厳しさの序列に従って、サンプルデータに含まれる要素を妥当と判断可能な最も厳しい制約条件を取得すること、
を特徴とするスキーマ変換装置。
【請求項５】
請求項４に記載のスキーマ変換装置であって、
前記序列は、包含されるデータ型が、包含するデータ型よりもより厳しいと判断されるものであること、
を特徴とするスキーマ変換装置。
【請求項６】
請求項４に記載のスキーマ変換装置であって、
前記序列は、要素内容の値の長さの範囲の狭いものが、より厳しいと判断されるものであること、
を特徴とするスキーマ変換装置。
【請求項７】
請求項４に記載のスキーマ変換装置であって、
前記序列は、要素内容として出現する要素の数の範囲の狭いものが、より厳しいと判断されるものであること、
を特徴とするスキーマ変換装置。
【請求項８】
請求項４に記載のスキーマ変換装置であって、
前記序列は、要素内容として出現する要素が、任意の要素の出現を認めているものよりも、特定の要素の出現を認めているものの方が、より厳しいと判断されるものであること、
を特徴とするスキーマ変換装置。
【請求項９】
請求項１に記載のスキーマ変換装置であって、
オリジナルスキーマの変更を許容する要素宣言と、制約条件の種別と、を特定する設定情報を記憶する記憶部を備え、
前記制御部は、前記変換候補のうち、前記設定情報において特定されている要素宣言及び制約条件の種別に対応する制約条件を、前記オリジナルスキーマの制約条件と変換すること、
を特徴とするスキーマ変換装置。
【請求項１０】
請求項１に記載のスキーマ変換装置であって、
前記制御部は、
前記変換候補を出力部に表示する処理と、
入力部を介して、表示された変換候補を適用するか否かの入力を受け付ける処理と、
適用すると入力された変換候補に対応する制約条件と、前記オリジナルスキーマの制約条件と、の変換を行う処理と、を行うこと、
を特徴とするスキーマ変換装置。
【請求項１１】
コンピュータを、スキーマ文書を生成するスキーマ変換装置として機能させるプログラムであって、
前記コンピュータを、
サンプルデータに含まれる要素を妥当と判断可能な最も厳しい制約条件を変換候補として、当該要素毎に取得する処理と、
前記要素に対応する要素宣言をオリジナルスキーマより特定し、特定した要素宣言の要素内容における前記要素に対する制約条件を、前記変換候補として取得した制約条件に変換することで、前記スキーマ文書を生成する処理と、を行う制御手段として機能させること、
を特徴とするプログラム。
【請求項１２】
請求項１１に記載のプログラムであって、
前記制御手段に、
前記サンプルデータに含まれる要素を、深さ優先で探索し、帰りがけ順で探索された要素を妥当と判断可能な最も厳しい制約条件を変換候補として取得する処理を行わせること、
を特徴とするプログラム。
【請求項１３】
請求項１２に記載のプログラムであって、
前記コンピュータを、前記オリジナルスキーマ内の要素宣言と、サンプルデータに含まれる要素を妥当と判断可能な最も厳しい制約条件と、を変換候補情報として記憶する記憶手段として機能させ、
前記制御手段に、
前記サンプルデータに含まれる要素を、深さ優先で探索し、帰りがけ順で探索された要素を妥当と判断可能な最も厳しい制約条件を変換候補として取得する処理と、
前記変換候補情報において、前記サンプルデータに含まれる要素に対応する要素宣言に対応付けられている制約条件と、取得した制約条件と、を満たす最も厳しい制約条件を特定し、前記変換候補情報における制約条件を、特定した制約条件に変更する処理と、を行わせること、
を特徴とするプログラム。
【請求項１４】
請求項１１に記載のプログラムであって、
前記制御手段に、
予め定められた制約条件の厳しさの序列に従って、サンプルデータに含まれる要素を妥当と判断可能な最も厳しい制約条件を取得する処理を行わせること、
を特徴とするプログラム。
【請求項１５】
請求項１４に記載のプログラムであって、
前記序列は、包含されるデータ型が、包含するデータ型よりもより厳しいと判断されるものであること、
を特徴とするプログラム。
【請求項１６】
請求項１４に記載のプログラムであって、
前記序列は、要素内容の値の長さの範囲の狭いものが、より厳しいと判断されるものであること、
を特徴とするプログラム。
【請求項１７】
請求項１４に記載のプログラムであって、
前記序列は、要素内容として出現する要素の数の範囲の狭いものが、より厳しいと判断されるものであること、
を特徴とするプログラム。
【請求項１８】
請求項１４に記載のプログラムであって、
前記序列は、要素内容として出現する要素が、任意の要素の出現を認めているものよりも、特定の要素の出現を認めているものの方が、より厳しいと判断されるものであること、
を特徴とするプログラム。
【請求項１９】
請求項１４に記載のプログラムであって、
前記制御手段に、
前記変換候補を出力手段に表示する処理と、
入力手段を介して、表示された変換候補を適用するか否かの入力を受け付ける処理と、
適用すると入力された変換候補に対応する制約条件と、前記オリジナルスキーマの制約条件と、の変換を行う処理と、を行わせること、
を特徴とするプログラム。
【請求項２０】
制御部を有するスキーマ変換装置が、スキーマ文書を生成するスキーマ生成方法であって、
前記制御部が、サンプルデータに含まれる要素を妥当と判断可能な最も厳しい制約条件を変換候補として、当該要素毎に取得する過程と、
前記制御部が、前記要素に対応する要素宣言をオリジナルスキーマより特定し、特定した要素宣言の要素内容における前記要素に対する制約条件を、前記変換候補として取得した制約条件に変換することで、前記スキーマ文書を生成する処理と、を行う過程と、を備えること、
を特徴とするスキーマ生成方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、スキーマ文書を生成する技術に関する。
【背景技術】
【０００２】
構造化文書を記述するための代表的な言語にＸＭＬ（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）などのデータバインディングツールでは、スキーマ文書の情報を元にＪａｖａ（登録商標）のクラスを生成することができる。変換後ツールは、ＪＡＸＢを用いてＪａｖａ（登録商標）のクラスを生成する際に利用してもよい。
【０３０８】
また、制限候補情報を保存しておけば、同じもしくは類似するオリジナルスキーマに対して変換を再度行なう場合、容易に再変換を実施することができる。
【０３０９】
オリジナルスキーマを制約条件の厳しいスキーマに変更した後に、オリジナルスキーマの方に修正が加わってしまう可能性がある。その場合、スキーマの変更を再度実施することが考えられる。スキーマの変更を手作業で行っている場合、このような作業は非常に負担が大きい。しかし、本発明を用いると、制限候補情に変更内容が含まれているため、制限候補情を保存しておくことで、容易に再変換が可能である。
【０３１０】
また、本実施形態では、ａｎｙ要素による任意の要素の出現を許す制約条件を、具体的な要素、例えばＤｉｓｃｏｕｎｔ要素の出現だけを許す制約条件に変換する方法を説明した。ここでは具体的な要素名を特定できる場合を例に取り説明したが、具体的な要素名を特定することが困難な場合、例えば出現を許す要素の名前空間ＵＲＩや名前空間の種別を特定するように制約条件を変更してもよい。ａｎｙ要素ではｎａｍｅｓｐａｃｅ属性により出現を許す名前空間を特定することができる。例えば、ｎａｍｅｓｐａｃｅ属性に＃＃ｏｔｈｅｒを指定した場合、対象名前空間以外の名前空間に属する要素の出現を許す。また、ｎａｍｅｓｐａｃｅ属性に＃＃ｔａｒｇｅｔＮａｍｅｓｐａｃｅを指定すると、出現を許す具体的な名前空間ＵＲＬを指定することができる。
【０３１１】
また、図４の２７行目のａｎｙ要素を変換する場合、例えばａｎｙ要素のｎａｍｅｓｐａｃｅ属性に＃＃ｏｔｈｅｒを設定することで、対象名前空間とは異なる名前空間に属するＤｉｓｃｏｕｎｔ要素の出現を許しつつ、対象名前空間に属する要素の出現を禁止することができるため、具体的な要素名を特定することなく制約条件を厳しくすることができる。また、＃＃ｔａｒｇｅｔＮａｍｅｓｐａｃｅを利用してＤｉｓｃｏｕｎｔ要素が属する名前空間ＵＲＩであるｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｏｒｇ／ｏｒｄｅｒを指定することで、ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｏｒｇ／ｏｒｄｅｒの名前空間ＵＲＩに属するもののみ出現を許すことができ、より制約条件を厳しくすることができる。
【図面の簡単な説明】
【０３１２】
【図１】スキーマ変換装置の概略図。
【図２】スキーマ文書管理テーブルの概略図。
【図３】設定情報テーブルの概略図。
【図４】オリジナルスキーマの概略図。
【図５】サンプルデータの概略図。
【図６】第一制限候補テーブルの概略図。
【図７】第二制限候補テーブルの概略図。
【図８】変換後スキーマの概略図。
【図９】コンピュータの概略図。
【図１０】スキーマ変換装置における全体の処理を示すフローチャート。
【図１１】制限候補情報を更新する処理を示すフローチャート。
【図１２】要素に対応する要素宣言のデータを取得する処理を示すフローチャート。
【図１３】スキーマの概略図。
【図１４】ｉｍｐｏｒｔ要素の概略図。
【図１５】テキストデータの制限候補情報を更新する処理を示すフローチャート。
【図１６】子要素の制限候補情報を更新する処理を示すフローチャート。
【図１７】Ｗｅｂサービスシステムの概略図。
【図１８】スキーマ変換装置の概略図。
【図１９】エディタ画面の概略図。
【図２０】制限候補の選択処理を示すフローチャート。
【図２１】Ｗｅｂサービスシステムの概略図。
【図２２】スキーマ変換装置の概略図。
【図２３】ＸＭＬ文書の検証する際の処理を示すフローチャート。
【符号の説明】
【０３１３】
１００、２００、３００  スキーマ変換装置
１１０  記憶部
１１１  スキーマリポジトリ記憶領域
１１２  設定情報記憶領域
１１３  オリジナルスキーマ記憶領域
１１４  サンプルデータ記憶領域
１１５  制限候補情報記憶領域
１１６  変換後スキーマ記憶領域
３１７  ログ情報記憶領域
１２０  制御部
１２１  全体制御部
１２２  スキーマ検証部
１２３  探索部
１２４  制限候補情報更新部
１２５、２２５  スキーマ変換部
２２６  スキーマ編集部
３２７  ログ取得部
３２８  アプリケーション部
１３０  入力部
１４０  出力部
１５０  通信部
【図１】
2010026857.tif 000003
【図２】
2010026857.tif 000004
【図３】
2010026857.tif 000005
【図４】
2010026857.tif 000006
【図５】
2010026857.tif 000007
【図６】
2010026857.tif 000008
【図７】
2010026857.tif 000009
【図８】
2010026857.tif 000010
【図９】
2010026857.tif 000011
【図１０】
2010026857.tif 000012
【図１１】
2010026857.tif 000013
【図１２】
2010026857.tif 000014
【図１３】
2010026857.tif 000015
【図１４】
2010026857.tif 000016
【図１５】
2010026857.tif 000017
【図１６】
2010026857.tif 000018
【図１７】
2010026857.tif 000019
【図１８】
2010026857.tif 000020
【図１９】
2010026857.tif 000021
【図２０】
2010026857.tif 000022
【図２１】
2010026857.tif 000023
【図２２】
2010026857.tif 000024
【図２３】
2010026857.tif 000025