(57)【要約】【課題】  電子文書に対する検証処理の負担を軽減することにより、処理効率を向上できる文書検証装置を提供することを目的とする。【解決手段】  文書検証サービス１１０は、入力された電子文書が所定の条件を満たしているか否か検証された後に、前記電子文書および前記条件の少なくとも一方に対して検証結果に影響する変更が加えられたか否かを判定し、前記電子文書および前記条件の少なくとも一方に対して変更が加えられたと判定された場合には、前記電子文書が所定の条件を満たしているか否かを検証して検証結果を出力し、前記変更が加えられていないと判定された場合には、直近に前記電子文書が前記条件を満たしているか否か検証されたときの結果を検証結果として出力する。【選択図】          図２０
2006351002.tif 000002
【特許請求の範囲】
【請求項１】
入力された電子文書が所定の条件を満たしているか否か検証された後に、前記電子文書および前記条件の少なくとも一方に対して検証結果に影響する変更が加えられたか否かを判定する判定手段と、
前記電子文書および前記条件の少なくとも一方に対して変更が加えられたと判定された場合には、前記電子文書が所定の条件を満たしているか否かを検証して検証結果を出力し、前記変更が加えられていないと判定された場合には、直近に前記電子文書が前記条件を満たしているか否か検証されたときの結果を検証結果として出力する出力手段と
を備えることを特徴とする、文書検証装置。
【請求項２】
前記判定手段は、前記電子文書が整形式のＸＭＬ文書であるか否か検証することを特徴とする、請求項１に記載の文書検証装置。
【請求項３】
前記出力手段は、前記電子文書が構成要素を節とする木で表現される構造化文書である場合、該構造化文書が所定の文書スキーマで定義される条件を満たしているか否か検証することを特徴とする、請求項１に記載の文書検証装置。
【請求項４】
前記判定手段は、前記電子文書が直近に検証された時点で前記電子文書に所定の演算を実行して得られた情報と、前記入力された電子文書に前記所定の演算を実行して得られた情報が異なる場合に、前記電子文書に対して検証結果に影響する変更が加えられたと判定することを特徴とする、請求項１または請求項３に記載の文書検証装置。
【請求項５】
前記判定手段は、前記構造化文書が直近に検証された時点で所定の文書スキーマに所定の演算を実行して得られた情報と、前記所定の文書スキーマに前記所定の演算を実行して得られた情報が異なる場合に、前記所定の文書スキーマに対して検証結果に影響する変更が加えられたと判定することを特徴とする、請求項３に記載の文書検証装置。
【請求項６】
前記判定手段は、前記電子文書を二つ以上の部分に分割し、
前記出力手段は、前記分割された電子文書のそれぞれが所定の条件を満たしているか否か検証することを特徴とする、請求項１、請求項２、請求項４または請求項５に記載の文書検証装置。
【請求項７】
前記判定手段は、前記電子文書に対して検証結果に影響する変更が加えられたと判定された場合に、変更が加えられた部分とそれ以外とに前記電子文書を分割し、
前記出力手段は、前記変更が加えられた部分が所定の条件を満たしているか否か検証することを特徴とする請求項１、請求項２、請求項４または請求項５に記載の文書検証装置。
【請求項８】
前記判定手段は、前記電子文書を文字データ内容とそれ以外に分割することを特徴とする、請求項６または請求項７に記載の文書検証装置。
【請求項９】
前記判定手段は、前記電子文書が構成要素を節とする木で表現される構造化文書である場合、該構造化文書を文書要素属性とそれ以外に分割することを特徴とする、請求項６または請求項７に記載の文書検証装置。
【請求項１０】
前記判定手段は、前記電子文書が構成要素を節とする木で表現される構造化文書である場合、該構造化文書を部分木とそれ以外に分割することを特徴とする、請求項６または請求項７に記載の文書検証装置。
【請求項１１】
前記判定手段は、前記検証結果に影響しない部分を前記電子文書から除外した後、該除外した電子文書に対して検証結果に影響する変更が加えられたか否か判定することを特徴とする、請求項１、請求項４または請求項５に記載の文書検証装置。
【請求項１２】
前記判定手段は、前記電子文書がＸＭＬ文書である場合、前記検証結果に影響しない部分としてＣＤＡＴＡセクション、コメント、処理命令および文書スキーマ中の混合内容モデルに対応する内容に含まれる文字データのうち少なくとも一つを除外し、または前記文書スキーマ中の要素内容モデルに対応する内容に含まれる文書要素間の空白文字を除外することを特徴とする、請求項１１に記載の文書検証装置。
【請求項１３】
前記判定手段は、前記電子文書としてＸＭＬ文書、文書スキーマとしてＸＭＬ ＤＴＤが入力された場合、前記検証結果に影響しない部分として、文書要素の内容であって他の文書要素を含まないものを前記ＸＭＬ文書から除外することを特徴とする、請求項１１に記載の文書検証装置。
【請求項１４】
前記判定手段は、前記電子文書としてＸＭＬ文書が入力された場合、前記検証結果に影響しない部分として、ＸＭＬ  ＤＴＤの要素型宣言でＡＮＹキーワードを含むものに対応付けられる文書要素直下の文字データ内容、および、Ｗ３Ｃ ＸＭＬ Ｓｃｈｅｍａのａｎｙ要素を含むものに対応付けられる文書要素または文字データを、前記ＸＭＬ文書から除外することを特徴とする、請求項１１に記載の文書検証装置。
【請求項１５】
前記判定手段は、前記電子文書としてＸＭＬ文書、文書スキーマとしてＷ３Ｃ ＸＭＬ Ｓｃｈｅｍａが入力された場合、前記検証結果に影響しない部分として、Ｗ３Ｃ ＸＭＬ Ｓｃｈｅｍａで定義された文字列型の内容を持つべき文書要素の内容で、他の文書要素を含まないもの、および、文字列型の値を持つべき文書要素属性の値を前記ＸＭＬ文書から除外することを特徴とする、請求項１１に記載の文書検証装置。
【請求項１６】
前記判定手段は、前記電子文書としてＸＭＬ文書、文書スキーマとしてＷ３Ｃ ＸＭＬ Ｓｃｈｅｍａが入力された場合、前記検証結果に影響しない部分として、Ｗ３Ｃ ＸＭＬ Ｓｃｈｅｍａで定義されたａｎｙ要素に対応する位置に出現する文書要素、およびａｎｙＡｔｔｒｉｂｕｔｅ要素に対応する位置に出現する文書要素属性を前記ＸＭＬ文書から除外することを特徴とする、請求項１１に記載の文書検証装置。
【請求項１７】
文書スキーマの構造的特徴に基づいて前記電子文書である構造化文書を二つ以上の部分に分割する分割手段をさらに備え、
前記判定手段は、前記分割された構造化文書が前記文書スキーマを満たしているか否か検証された後に、前記分割された構造化文書の各部分および前記文書スキーマの少なくとも一つに対して検証結果に影響する変更が加えられたか否かを判定し、
前記出力手段は、前記分割された構造化文書の各部分のうち、前記判定手段により検証結果に影響する変更が加えられたと判定された特定部分については、前記特定部分が文書スキーマを満たしているか否かを検証して前記特定部分に関する検証結果とし、前記変更が加えられていないと判定された部分については、直近に前記構造化文書の各部分が前記条件を満たしているか否か検証されたときの結果を検証結果とし、これらの検証結果に基づいて前記入力された構造化文書全体としての検証結果を出力することを特徴とする、請求項１から請求項３のいずれかに記載の文書検証装置。
【請求項１８】
前記分割手段は、一つの文書スキーマに基づいて前記文書スキーマの構造的特徴を抽出することを特徴とする、請求項１７に記載の文書検証装置。
【請求項１９】
前記分割手段は、複数の文書スキーマに基づいて前記文書スキーマの構造的特徴を抽出することを特徴とする、請求項１７に記載の文書検証装置。
【請求項２０】
前記電子文書である構造化文書に加えられる変更に応じて、前記構造化文書を二つ以上の部分に分割する分割手段をさらに備え、
前記判定手段は、前記分割された構造化文書が前記文書スキーマを満たしているか否か検証された後に、前記分割された構造化文書の各部分および前記文書スキーマの少なくとも一つに対して検証結果に影響する変更が加えられたか否かを判定し、
前記出力手段は、前記分割された構造化文書の各部分のうち、前記判定手段に検証結果に影響する変更が加えられたと判定された部分については、前記特定部分が文書スキーマを満たしているか否かを検証して前記特定部分に関する検証結果とし、前記変更が加えられていないと判定された部分については、直近に前記構造化文書の各部分が前記条件を満たしているか否か検証されたときの結果を検証結果とし、これらの検証結果から前記入力された構造化文書全体としての検証結果を出力することを特徴とする、請求項１から請求項３のいずれかに記載の文書検証装置。
【請求項２１】
前記分割手段は、前記構造化文書へ変更が加えられる前に、前記構造化文書の変更可能性を特定することを特徴とする、請求項２０に記載の文書検証装置。
【請求項２２】
前記分割手段は、前記構造化文書へ変更を加える処理を記述する入力用文書スキーマおよび出力用文書スキーマに基づいて前記構造化文書に対する変更可能性を特定することを特徴とする、請求項２１に記載の文書検証装置。
【請求項２３】
前記分割手段は、前記構造化文書へ変更を加える処理が公開する変更情報に基づいて前記構造化文書に対する変更可能性を特定することを特徴とする、請求項２１に記載の文書検証装置。
【請求項２４】
前記分割手段は、前記構造化文書へ加えられた変更に応じて、前記構造化文書に対する変更可能性を特定することを特徴とする、請求項２１から請求項２３のいずれかに記載の文書検証装置。
【請求項２５】
前記分割手段は、前記一つの文書スキーマを構成する要素として、一つ以上の他の文書スキーマが利用されている場合、前記他の文書スキーマを利用した要素を前記文書スキーマの構造的特徴として抽出することを特徴とする、請求項１８に記載の文書検証装置。
【請求項２６】
前記構造化文書はXMLで記述され、前記文書スキーマはW3C XML Schemaで記述され、前記他の文書スキーマを利用した要素は他の文書スキーマをインポートすることで表現されていることを特徴とする、請求項２５に記載の文書検証装置。
【請求項２７】
前記分割手段は、前記一つの文書スキーマに基づいて前記文書スキーマに適合するために必須の文書要素を前記文書スキーマの構造的特徴として抽出することを特徴とする、請求項１８に記載の文書検証装置。
【請求項２８】
前記分割手段は、前記一つの文書スキーマに基づいて前記文書スキーマにおいて複数回出現することが許容されている文書要素を前記文書スキーマの構造的特徴として抽出することを特徴とする、請求項１８に記載の文書検証装置。
【請求項２９】
前記分割手段は、前記文書スキーマの構造化文書がXMLで記述され、前記文書スキーマがW3C XML Schemaで記述される場合、前記文書スキーマ中のパーティクルに基づいて前記必須の文書要素を特定することを特徴とする、請求項２７または請求項２８に記載の文書検証装置。
【請求項３０】
前記分割手段は、前記複数の文書スキーマが、一つの文書サービスに対する入力用文書スキーマと出力用文書スキーマである場合、前記入力用文書スキーマと前記出力用文書スキーマの共通部分を前記文書スキーマの構造的特徴として抽出することを特徴とする、請求項１９または請求項２２に記載の文書検証装置。
【請求項３１】
前記分割手段は、前記構造化文書がXMLで記述され、前記文書スキーマはW3C XML Schemaで記述される場合、前記一つの文書サービスのWSDL文書に基づいて前記一つの文書サービスに対する入力用文書スキーマと出力用文書スキーマを特定することを特徴とする、請求項３０に記載の文書検証装置。
【請求項３２】
前記分割手段は、前記複数の文書スキーマが、連携された文書サービス群で利用される複数の文書スキーマである場合、前記連携された文書サービス群で利用される複数の文書スキーマの共通部分を前記文書スキーマの構造的特徴として抽出することを特徴とする、請求項１９または請求項２２に記載の文書検証装置。
【請求項３３】
前記連携された文書サービス群で利用される複数の文書スキーマは、連携を形成するための情報から特定されることを特徴とする、請求項３２に記載の文書検証装置。
【請求項３４】
前記構造化文書はXMLで記述され、前記文書スキーマはW3C XML Schemaで記述され、前記連携を形成するための情報がBPEL4WSで記述されることを特徴とする、請求項３３に記載の文書検証装置。
【請求項３５】
前記分割手段は、前記連携された文書サービスで処理された文書を追跡することにより前記連携された文書サービス群で利用される複数の文書スキーマを特定することを特徴とする、請求項３２に記載の文書検証装置。
【請求項３６】
前記変更情報は検証処理装置に通知されることで公開されることを特徴とする、請求項２３に記載の文書検証装置。
【請求項３７】
前記変更情報はレジストリサービスを用いて公開されることを特徴とする、請求項２３に記載の文書検証装置。
【請求項３８】
前記変更情報はサービス記述言語を用いて公開されることを特徴とする、請求項２３に記載の文書検証装置。
【請求項３９】
前記変更情報は問い合わせインタフェースを用いて公開されることを特徴とする、請求項２３に記載の文書検証装置。
【請求項４０】
前記分割手段は、前記構造化文書をサンプリングすることにより前記構造化文書へ加えられた変更を調べることを特徴とする、請求項２４に記載の文書検証装置。
【請求項４１】
前記分割手段は、一つのサービスの入力文書と出力文書とをサンプリングすることにより前記構造化文書へ加えられた変更を調べることを特徴とする、請求項４０に記載の文書検証装置。
【請求項４２】
連携されたサービスで用いられる文書群をサンプリングすることにより前記構造化文書へ加えられた変更を調べることを特徴とする、請求項４０に記載の文書検証装置。
【請求項４３】
連携されたサービスのハブで前記サービスで用いられる文書群をサンプリングすることを特徴とする、請求項４２に記載の文書検証装置。
【請求項４４】
前記分割手段は、メッセージフローを追跡することにより前記構造化文書をサンプリングすることを特徴とする、請求項４２に記載の文書検証装置。
【請求項４５】
前記判定手段は、前記構造化文書が直近に検証された時点で前記構造化文書の各部分に所定の演算を実行して得られた情報と、前記入力された構造化文書の各部分に前記所定の演算を実行して得られた情報が異なる場合に、前記構造化文書の各部分に対して検証結果に影響する変更が加えられたと判定することを特徴とする、請求項１７から請求項４４のいずれかに記載の文書検証装置。
【請求項４６】
前記判定手段は、前記構造化文書が直近に検証された時点で所定の文書スキーマに所定の演算を実行して得られた情報と、前記所定の文書スキーマに前記所定の演算を実行して得られた情報が異なる場合に、前記所定の文書スキーマに対して検証結果に影響する変更が加えられたと判定することを特徴とする、請求項１７から請求項４４のいずれかに記載の文書検証装置。
【請求項４７】
前記分割手段は、構造化文書の分割に応じて、分割された各部分を検証するための文書スキーマフラグメントを生成し、
前記出力手段は、前記構造化文書に変更が加えられたと判定された部分の検証において、前記生成された文書スキーマフラグメントを用いることを特徴とする、請求項１７から請求項４６のいずれかに記載の文書検証装置。
【請求項４８】
前記分割手段は、前記判定手段が前記構造化文書の特定部分に変更が加えられたと判定した後に、前記特定部分に対応する文書スキーマフラグメントを生成することを特徴とする、請求項４７に記載の文書検証装置。
【請求項４９】
前記出力手段は、ある構造化文書の検証に用いた文書スキーマフラグメントを保持し、文書スキーマを同じくする他の構造化文書の検証の際に前記保持された文書スキーマフラグメントを再利用することを特徴とする、請求項４７または請求項４８に記載の文書検証装置。
【請求項５０】
前記出力手段は、前記構造化文書に変更が加えられたと判定された部分の検証において、前記分割手段による構造化文書の分割に応じて、特定の文書要素についてはその下位構造を検証することなく、前記特定の文書要素の存在をもってその下位構造は文書スキーマを満たすと見なして前記構造化文書を検証することを特徴とする、請求項１７から請求項４６のいずれかに記載の文書検証装置。
【請求項５１】
前記所定の演算は、前処理および一方向関数適用処理の一方を少なくとも含むことを特徴とする、請求項４、請求項５、請求項４５または請求項４６のいずれかに記載の文書検証装置。
【請求項５２】
前記前処理は、前記電子文書または前記構造化文書の表現のゆれを吸収するための正規化処理であることを特徴とする、請求項５１に記載の文書検証装置。
【請求項５３】
前記前処理は、前記電子文書または前記構造化文書の文字列表現から文書要素、文書要素属性および文書要素を含まない内容を節とする木のうち少なくとも一つを生成する処理であることを特徴とする、請求項５１記載の文書検証装置。
【請求項５４】
前記一方向関数適用処理は、ＭＤ５アルゴリズムおよびＳＨＡ１アルゴリズムを含むダイジェスト関数を適用する処理であることを特徴とする、請求項５１に記載の文書検証装置。
【請求項５５】
前記一方向関数適用処理は、線形合同法およびメルセンヌ・ツイスタを含む再現性のある擬似乱数アルゴリズムを適用する処理であることを特徴とする、請求項５１に記載の文書検証装置。
【請求項５６】
前記判定手段は、前記文書スキーマから検証結果に影響しない部分として注釈要素を頂点とする部分木を除外することを特徴とする、請求項５に記載の文書検証装置。
【請求項５７】
前記判定手段は、前記所定の文書スキーマが定義する第１の言語が前記構造化文書が直近に検証された時点での前記所定の文書スキーマが定義する第２の言語を包含しかつ直近の検証結果が真である場合、および前記第２の言語が前記第１の言語を包含しかつ直近の検証結果が偽である場合の一方の場合に前記文書スキーマに対して検証結果に影響する変更が加えられていないと判定することを特徴とする、請求項５に記載の文書検証装置。
【請求項５８】
前記電子文書が直近に検証された時に前記一方向関数適用処理の結果得られた値と検証結果の組と前記電子文書とを組にして保持する保持手段をさらに備えることを特徴とする、請求項５１に記載の文書検証装置。
【請求項５９】
過去の検証処理において前記一方向関数適用処理の結果得られた値と検証結果の組を保持する保持手段をさらに備え、
前記出力手段は、検証対象の文書に前記一方向関数適用処理の結果得られた値が前記保持手段で保持しているいずれかの値と同一である場合、その値に対応する検証結果を前記電子文書の検証結果とすることを特徴とする、請求項５１に記載の文書検証装置。
【請求項６０】
前記出力手段は、検証結果に加えて変更後の文書および該文書に所定の演算を実行して得られる情報を出力することを特徴とする、請求項４に記載の文書検証装置。
【請求項６１】
入力された電子文書が所定の条件を満たしているか否か検証された後に、前記電子文書および前記条件の少なくとも一方に対して検証結果に影響する変更が加えられたか否かを判定する判定ステップと、
前記電子文書および前記条件の少なくとも一方に対して変更が加えられたと判定された場合には、前記電子文書が所定の条件を満たしているか否かを検証して検証結果を出力し、前記変更が加えられていないと判定された場合には、直近に前記電子文書が前記条件を満たしているか否か検証されたときの結果を検証結果として出力する出力ステップと
を有することを特徴とする、文書検証方法。
【請求項６２】
前記出力ステップは、前記電子文書が構成要素を節とする木で表現される構造化文書である場合、該構造化文書が所定の文書スキーマで定義される条件を満たしているか否か検証することを特徴とする、請求項６１に記載の文書検証方法。
【請求項６３】
前記判定ステップは、前記電子文書が直近に検証された時点で前記電子文書に所定の演算を実行して得られた情報と、前記入力された電子文書に前記所定の演算を実行して得られた情報が異なる場合に、前記電子文書に対して検証結果に影響する変更が加えられたと判定することを特徴とする、請求項６１に記載の文書検証方法。
【請求項６４】
前記判定ステップは、前記構造化文書が直近に検証された時点で所定の文書スキーマに所定の演算を実行して得られた情報と、前記所定の文書スキーマに前記所定の演算を実行して得られた情報が異なる場合に、前記所定の文書スキーマに対して検証結果に影響する変更が加えられたと判定することを特徴とする、請求項６１に記載の文書検証方法。
【請求項６５】
前記電子文書を二つ以上の部分に分割するステップをさらに有し、
前記出力ステップは、前記分割された電子文書のそれぞれが所定の条件を満たしているか否か検証することを特徴とする、請求項６１に記載の文書検証方法。
【請求項６６】
文書スキーマの構造的特徴に基づいて前記電子文書である構造化文書を二つ以上の部分に分割する分割ステップをさらに有し、
前記判定ステップは、前記分割された構造化文書が前記文書スキーマを満たしているか否か検証された後に、前記分割された構造化文書の各部分および前記文書スキーマの少なくとも一つに対して検証結果に影響する変更が加えられたか否かを判定し、
前記出力ステップは、前記分割された構造化文書の各部分のうち、前記判定ステップにより検証結果に影響する変更が加えられたと判定された特定部分については、前記特定部分が文書スキーマを満たしているか否かを検証して前記特定部分に関する検証結果とし、前記変更が加えられていないと判定された部分については、直近に前記構造化文書の各部分が前記条件を満たしているか否か検証されたときの結果を検証結果とし、これらの検証結果に基づいて前記入力された構造化文書全体としての検証結果を出力することを特徴とする、請求項６１に記載の文書検証方法。
【請求項６７】
前記電子文書である構造化文書に加えられる変更に応じて、前記構造化文書を二つ以上の部分に分割する分割ステップをさらに有し、
前記判定ステップは、前記分割された構造化文書が前記文書スキーマを満たしているか否か検証された後に、前記分割された構造化文書の各部分および前記文書スキーマの少なくとも一つに対して検証結果に影響する変更が加えられたか否かを判定し、
前記出力ステップは、前記分割された構造化文書の各部分のうち、前記判定ステップに検証結果に影響する変更が加えられたと判定された部分については、前記特定部分が文書スキーマを満たしているか否かを検証して前記特定部分に関する検証結果とし、前記変更が加えられていないと判定された部分については、直近に前記構造化文書の各部分が前記条件を満たしているか否か検証されたときの結果を検証結果とし、これらの検証結果から前記入力された構造化文書全体としての検証結果を出力することを特徴とする、請求項６１に記載の文書検証方法。
【請求項６８】
請求項６１から請求項６７のいずれかに記載の文書検証方法をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、文書検証装置、文書検証方法およびプログラムに関する。
【背景技術】
【０００２】
構造化文書処理システムを作成・運用する上で、処理対象の構造化文書の検証処理の負荷の大きさが処理効率低下の一因となっている。この問題に対処するため、（１）検証処理プログラムの高速化、（２）検証処理の不要化、（３）システム外部への検証処理の委譲、といったアプローチが取られてきた。検証処理とは、文書スキーマなどによって表現された条件を構造化文書が満たすか否かチェックする処理である。代表的な構造化文書であるXML（Extensible Markup Language）文書に対する検証処理は、文書が整形式であることを検証する処理と、文書の妥当性を検証する処理とに大別される。前者は、文書がXML標準で定められた記法に基づいているか否か判定する処理で、後者は、文書スキーマの条件を文書が満たすか否か判定する処理である。代表的な文書スキーマには、文書型定義（DTD）やW3C XML Schemaなどがある。なお、“W3C”とは、標準化団体World Wide Web Consortiumの略称である。
【０００３】
検証処理プログラム高速化手法の例としては、特許文献１記載の「XML文書の妥当性を検証するためのオートマトンの生成方法」に記載の手法がある。具体的には、XML文書の妥当性検証処理において、DTDの内容モデル(文書要素が含む文書要素および文字列の出現順序や出現回数に関する規定)毎の複数のテーブル構造（文字列オートマトン）間の類似性を検出する。この類似性を利用して各内容モデルのオートマトンを取り纏め小型化する。あるいは各内容モデルの複数のテーブル構造を、要素の親子関係の規則を表すテーブルとともに取り纏めて単一のテーブル構造とする。
【０００４】
そしてこのテーブルの最小化を行う。一旦、最小化操作を終えていれば、従来技術より格段に小さい記憶領域、プログラムサイズによる妥当性検証が可能になる。またテーブルのデータへのアクセスも容易になるため、検証の高速化も可能になる。このテーブル構造を使い、記憶容量が少なくても高速に動作する汎用の検証器を作ることができる。
【０００５】
検証処理を不要化する手法の例として、特許文献２記載のスキーマ生成装置に記載の手法および、特許文献３記載の文書変換システムに記載の手法がある。
【０００６】
前者では、XSL Transformations (XSLT)標準に準拠した文書処理プログラムと変換前後の文書の文書スキーマを入力とし、変換前の文書を文書処理プログラムに入力して得られる文書が変換後の文書スキーマに適合するか判定する方法が開示されている。この方法を利用して、所望の文書スキーマに適合する文書のみを出力する文書変換プログラムを作成できれば、文書変換プログラムが出力した文書が所定の文書スキーマに適合することを保証できるので、出力文書に対する検証処理が不要となる。
【０００７】
また、後者では、第１の文書型定義に基づいて生成された第１の構造化文書を第２の文書型定義に基づく第２の構造化文書に変換する際に、第１の文書型定義及び第２の文書型定義を解析し、相違する文書型定義を抽出し、前記解析の結果に応じて、第２の構造化文書が第２の文書型定義に矛盾することのないような変換ルールを記述した変換テンプレートを生成し、変換テンプレートを用いて文書変換処理を行うことにより、第２の構造化文書が第２の文書型定義に適合することを保証し、変換後の妥当性検証ステップを省略できるようにする方法を開示している。
【０００８】
検証処理を委譲する手法の例として、特許文献４記載の外部XML有効性検証装置を利用するXMLパージング装置に記載の手法がある。この手法では、XML文書に対する処理を実行する文書処理モジュールと、文書スキーマに対する文書の妥当性を検証するモジュール(検証モジュール)および文書のDOMツリーおよびSAXツリーを生成するモジュール(ツリー生成モジュール)を分離し、携帯電話や携帯端末上の文書処理モジュールからネットワークで接続されたサーバ上の検証モジュールやツリー生成モジュールを呼び出すよう構成することで、計算機資源の貧弱な機器上での文書処理を可能とする方法を開示している。
【特許文献１】特開２００３−８４９８７号公報
【特許文献２】特開２００３−８５０１６号公報
【特許文献３】特開２００３−１５０５８６号公報
【特許文献４】特開２００４−３０６５１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、上記の従来手法は、検証処理による処理負担の増加という問題を解決しているとはいえない。まず、検証処理プログラム高速化手法では、今後予想される商用の文書スキーマおよび文書の大規模化に対処しきれない。
【００１０】
また、第１の検証処理不要化手法（特許文献２）は、XSLTに基づく文書変換処理に特化したものであり、それ以外の処理には利用できない。また、第２の検証処理不要化手法（特許文献３）は、変換後の文書が所定の文書スキーマに適合するように変換テンプレートを人手で編集する必要があるが、複雑な文書スキーマ間の変換処理では、この編集作業は一般に容易ではない。また、検証処理の委譲手法によって、計算機資源が豊富なサーバに検証処理を委譲しても、サーバによる検証処理の負担が軽減されるわけではない。
【００１１】
そこで、本発明は、上記問題点に鑑みてなされたもので、電子文書に対する検証処理の負担を軽減することにより、処理効率を向上できる文書検証装置、文書検証方法およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
上記課題を解決するために、本発明は、入力された電子文書が所定の条件を満たしているか否か検証された後に、前記電子文書および前記条件の少なくとも一方に対して検証結果に影響する変更が加えられたか否かを判定する判定手段と、前記電子文書および前記条件の少なくとも一方に対して変更が加えられたと判定された場合には、前記電子文書が所定の条件を満たしているか否かを検証して検証結果を出力し、前記変更が加えられていないと判定された場合には、直近に前記電子文書が前記条件を満たしているか否か検証されたときの結果を検証結果として出力する出力手段とを備える文書検証装置である。本発明によれば、電子文書および条件に変更が加えられていないと判定された場合には、直近に電子文書が条件を満たしているか否か検証されたときの結果を検証結果として出力する。一般に、判定処理時間は再検証処理時間より小さいため、電子文書に対する検証処理の負担を軽減することができ、処理効率を向上することができる。
【００１３】
前記判定手段は、前記電子文書が整形式のＸＭＬ文書であるか否か検証することを特徴とする。前記出力手段は、前記電子文書が構成要素を節とする木で表現される構造化文書である場合、該構造化文書が所定の文書スキーマで定義される条件を満たしているか否か検証することを特徴とする。
【００１４】
前記判定手段は、前記電子文書が直近に検証された時点で前記電子文書に所定の演算を実行して得られた情報と、前記入力された電子文書に前記所定の演算を実行して得られた情報が異なる場合に、前記電子文書に対して検証結果に影響する変更が加えられたと判定することを特徴とする。本発明によれば、直近に検証処理の対象となった時点での文書と現在の文書との比較に所定の演算を実行して得られる情報（たとえばメッセージダイジェスト値、以下ダイジェスト値と略記）を利用することにより、妥当性検証処理を実行せずに済むだけでなく、直近に検証処理の対象となった時点での文書を比較のために保存しておく必要がなくなり、必要な記憶領域を大幅に削減できる。なお、ダイジェスト値とは短い固定長のｂｉｔ列であり、電子情報に対して一方向関数を適用することで計算されるものである。
【００１５】
前記判定手段は、前記構造化文書が直近に検証された時点で所定の文書スキーマに所定の演算を実行して得られた情報と、前記所定の文書スキーマに前記所定の演算を実行して得られた情報が異なる場合に、前記所定の文書スキーマに対して検証結果に影響する変更が加えられたと判定することを特徴とする。本発明によれば、直近に検証処理の対象となった時点での文書スキーマと現在の文書スキーマとの比較に所定の演算を実行して得られる情報（たとえばダイジェスト値）を利用することにより、妥当性検証処理を実行せずに済むだけでなく、直近に検証処理の対象となった時点での文書スキーマを比較のために保存しておく必要がなくなり、必要な記憶領域を大幅に削減できる。
【００１６】
前記判定手段は、前記電子文書を二つ以上の部分に分割し、前記出力手段は、前記分割された電子文書のそれぞれが所定の条件を満たしているか否か検証することを特徴とする。本発明によれば、処理対象の文書を複数の部分に分割し、それぞれについて検証処理結果に影響を及ぼす変更がなされたか否かを判定することにより、文書が変更された場合でも、妥当性検証処理を実行すべき対象を文書全体より少なくでき、処理効率を改善できる。
【００１７】
前記判定手段は、前記電子文書に対して検証結果に影響する変更が加えられたと判定された場合に、変更が加えられた部分とそれ以外とに前記電子文書を分割し、前記検証手段は、前記変更が加えられた部分が所定の条件を満たしているか否か検証することを特徴とする。本発明によれば、処理対象の文書を複数の部分に分割し、それぞれについて検証処理結果に影響を及ぼす変更がなされたか否かを判定することにより、文書が変更された場合でも、妥当性検証処理を実行すべき対象を文書全体より少なくでき、処理効率を改善できる。
【００１８】
前記判定手段は、前記電子文書を文字データ内容とそれ以外に分割することを特徴とする。本発明によれば、変更される可能性が高い文字データ内容とそれ以外に文書を分割することで、妥当性検証処理を実行すべき対象を文書全体より少なくすることができ、処理効率を改善できる。前記判定手段は、前記電子文書が構成要素を節とする木で表現される構造化文書である場合、該構造化文書を文書要素属性とそれ以外に分割することを特徴とする。本発明によれば、変更される可能性が高い文書要素属性とそれ以外に文書を分割することで、妥当性検証処理を実行すべき対象を文書全体より少なくでき、処理効率を改善できる。
【００１９】
前記判定手段は、前記電子文書が構成要素を節とする木で表現される構造化文書である場合、該構造化文書を部分木とそれ以外に分割することを特徴とする。本発明によれば、文書が変更される可能性が高い部分木とそれ以外に分割することで、妥当性検証処理を実行すべき対象を文書全体より少なくでき、処理効率を改善できる。前記判定手段は、前記検証結果に影響しない部分を前記電子文書から除外した後、該除外した電子文書に対して検証結果に影響する変更が加えられたか否か判定することを特徴とする。本発明によれば、処理効率を改善できる。
【００２０】
前記判定手段は、前記電子文書がＸＭＬ文書である場合、前記検証結果に影響しない部分としてＣＤＡＴＡセクション、コメント、処理命令および文書スキーマ中の混合内容モデルに対応する内容に含まれる文字データのうち少なくとも一つを除外し、または前記文書スキーマ中の要素内容モデルに対応する内容に含まれる文書要素間の空白文字を除外することを特徴とする。
【００２１】
前記判定手段は、前記電子文書としてＸＭＬ文書、文書スキーマとしてＸＭＬ ＤＴＤが入力された場合、前記検証結果に影響しない部分として、文書要素の内容であって他の文書要素を含まないものを前記ＸＭＬ文書から除外することを特徴とする。検証結果に影響しない部分として、文書要素の内容であって他の文書要素を含まないものをＸＭＬ文書から除外することで、処理効率を改善できる。
【００２２】
前記判定手段は、前記電子文書としてＸＭＬ文書が入力された場合、前記検証結果に影響しない部分として、ＸＭＬ  ＤＴＤの要素型定義でＡＮＹキーワードを含むものに対応付けられる文書要素直下の文字データ、および、Ｗ３Ｃ ＸＭＬ Ｓｃｈｅｍａのａｎｙ要素に対応付けられる文書要素および文字データを、前記ＸＭＬ文書から除外することを特徴とする。これにより、処理効率を改善できる。
【００２３】
前記判定手段は、前記電子文書としてＸＭＬ文書、文書スキーマとしてＷ３Ｃ ＸＭＬ Ｓｃｈｅｍａが入力された場合、前記検証結果に影響しない部分として、Ｗ３Ｃ ＸＭＬ Ｓｃｈｅｍａで定義された文字列型の内容を持つべき文書要素の内容で、他の文書要素を含まないもの、および、文字列型の値を持つべき文書要素属性の値を前記ＸＭＬ文書から除外することを特徴とする。これにより、処理効率を改善できる。
【００２４】
前記判定手段は、前記電子文書としてＸＭＬ文書、文書スキーマとしてＷ３Ｃ ＸＭＬ Ｓｃｈｅｍａが入力された場合、前記検証結果に影響しない部分として、Ｗ３Ｃ ＸＭＬ Ｓｃｈｅｍａのａｎｙ要素に対応する文書要素および文字データ、およびａｎｙＡｔｔｒｉｂｕｔｅ要素に対応する文書要素属性を前記ＸＭＬ文書から除外することを特徴とする。これにより処理効率を改善できる。
【００２５】
本発明の文書検証装置は、文書スキーマの構造的特徴に基づいて前記電子文書である構造化文書を二つ以上の部分に分割する分割手段をさらに備え、前記判定手段は、前記分割された構造化文書が前記文書スキーマを満たしているか否か検証された後に、前記分割された構造化文書の各部分および前記文書スキーマの少なくとも一つに対して検証結果に影響する変更が加えられたか否かを判定し、前記出力手段は、前記分割された構造化文書の各部分のうち、前記判定手段により検証結果に影響する変更が加えられたと判定された特定部分については、前記特定部分が文書スキーマを満たしているか否かを検証して前記特定部分に関する検証結果とし、前記変更が加えられていないと判定された部分については、直近に前記構造化文書の各部分が前記条件を満たしているか否か検証されたときの結果を検証結果とし、これらの検証結果に基づいて前記入力された構造化文書全体としての検証結果を出力する。
【００２６】
前記分割手段は、一つの文書スキーマに基づいて前記文書スキーマの構造的特徴を抽出する。前記分割手段は、複数の文書スキーマに基づいて前記文書スキーマの構造的特徴を抽出する。
【００２７】
本発明の文書検証装置は、前記電子文書である構造化文書に加えられる変更に応じて、前記構造化文書を二つ以上の部分に分割する分割手段をさらに備え、前記判定手段は、前記分割された構造化文書が前記文書スキーマを満たしているか否か検証された後に、前記分割された構造化文書の各部分および前記文書スキーマの少なくとも一つに対して検証結果に影響する変更が加えられたか否かを判定し、前記出力手段は、前記分割された構造化文書の各部分のうち、前記判定手段に検証結果に影響する変更が加えられたと判定された部分については、前記特定部分が文書スキーマを満たしているか否かを検証して前記特定部分に関する検証結果とし、前記変更が加えられていないと判定された部分については、直近に前記構造化文書の各部分が前記条件を満たしているか否か検証されたときの結果を検証結果とし、これらの検証結果から前記入力された構造化文書全体としての検証結果を出力する。
【００２８】
前記分割手段は、前記構造化文書へ変更が加えられる前に、前記構造化文書の変更可能性を特定する。前記分割手段は、前記構造化文書へ変更を加える処理を記述する入力用文書スキーマおよび出力用文書スキーマに基づいて前記構造化文書に対する変更可能性を特定する。前記分割手段は、前記構造化文書へ変更を加える処理が公開する変更情報に基づいて前記構造化文書に対する変更可能性を特定する。前記分割手段は、前記構造化文書へ加えられた変更に応じて、前記構造化文書に対する変更可能性を特定する。
【００２９】
前記分割手段は、前記一つの文書スキーマを構成する要素として、一つ以上の他の文書スキーマが利用されている場合、前記他の文書スキーマを利用した要素を前記文書スキーマの構造的特徴として抽出する。前記構造化文書はXMLで記述され、前記文書スキーマはW3C XML Schemaで記述され、前記他の文書スキーマを利用した要素は他の文書スキーマをインポートすることで表現されている。前記分割手段は、前記一つの文書スキーマに基づいて前記文書スキーマに適合するために必須の文書要素を前記文書スキーマの構造的特徴として抽出する。
【００３０】
前記分割手段は、前記一つの文書スキーマに基づいて前記文書スキーマにおいて複数回出現することが許容されている文書要素を前記文書スキーマの構造的特徴として抽出する。前記分割手段は、前記文書スキーマの構造化文書がXMLで記述され、前記文書スキーマがW3C XML Schemaで記述される場合、前記文書スキーマ中のパーティクルに基づいて前記必須の文書要素を特定する。なお、パーティクルとは内容モデルの構成要素であり、要素参照宣言(element要素)や順番に出現させる指定(sequence要素)などを含む。
【００３１】
前記分割手段は、前記複数の文書スキーマが、一つの文書サービスに対する入力用文書スキーマと出力用文書スキーマである場合、前記入力用文書スキーマと前記出力用文書スキーマの共通部分を前記文書スキーマの構造的特徴として抽出する。前記分割手段は、前記構造化文書がXMLで記述され、前記文書スキーマはW3C XML Schemaで記述される場合、前記一つの文書サービスのWSDL(Web Service Description Language)文書に基づいて前記一つの文書サービスに対する入力用文書スキーマと出力用文書スキーマを特定する。
【００３２】
前記分割手段は、前記複数の文書スキーマが、連携された文書サービス群で利用される複数の文書スキーマである場合、前記連携された文書サービス群で利用される複数の文書スキーマの共通部分を前記文書スキーマの構造的特徴として抽出する。前記連携された文書サービス群で利用される複数の文書スキーマは、連携を形成するための情報から特定される。前記構造化文書はXMLで記述され、前記文書スキーマはW3C XML Schemaで記述され、前記連携を形成するための情報がBPEL4WSで記述される。
【００３３】
前記分割手段は、前記連携された文書サービスで処理された文書を追跡することにより前記連携された文書サービス群で利用される複数の文書スキーマを特定する。前記変更情報は検証処理装置に通知されることで公開される。前記変更情報はレジストリサービスを用いて公開される。前記変更情報はサービス記述言語を用いて公開される。前記変更情報は問い合わせインタフェースを用いて公開される。前記分割手段は、前記構造化文書をサンプリングすることにより前記構造化文書へ加えられた変更を調べる。
【００３４】
前記分割手段は、一つのサービスの入力文書と出力文書とをサンプリングすることにより前記構造化文書へ加えられた変更を調べる。連携されたサービスで用いられる文書群をサンプリングすることにより前記構造化文書へ加えられた変更を調べる。連携されたサービスのハブで前記サービスで用いられる文書群をサンプリングする。前記分割手段は、メッセージフローを追跡することにより前記構造化文書をサンプリングする。
【００３５】
前記判定手段は、前記構造化文書が直近に検証された時点で前記構造化文書の各部分に所定の演算を実行して得られた情報と、前記入力された構造化文書の各部分に前記所定の演算を実行して得られた情報が異なる場合に、前記構造化文書の各部分に対して検証結果に影響する変更が加えられたと判定する。前記判定手段は、前記構造化文書が直近に検証された時点で所定の文書スキーマに所定の演算を実行して得られた情報と、前記所定の文書スキーマに前記所定の演算を実行して得られた情報が異なる場合に、前記所定の文書スキーマに対して検証結果に影響する変更が加えられたと判定する。
【００３６】
前記分割手段は、構造化文書の分割に応じて、分割された各部分を検証するための文書スキーマフラグメントを生成し、前記出力手段は、前記構造化文書に変更が加えられたと判定された部分の検証において、前記生成された文書スキーマフラグメントを用いる。前記分割手段は、前記判定手段が前記構造化文書の特定部分に変更が加えられたと判定した後に、前記特定部分に対応する文書スキーマフラグメントを生成する。
【００３７】
前記出力手段は、ある構造化文書の検証に用いた文書スキーマフラグメントを保持し、文書スキーマを同じくする他の構造化文書の検証の際に前記保持された文書スキーマフラグメントを再利用する。前記出力手段は、前記構造化文書に変更が加えられたと判定された部分の検証において、前記分割手段による構造化文書の分割に応じて、特定の文書要素についてはその下位構造を検証することなく、前記特定の文書要素の存在をもってその下位構造は文書スキーマを満たすと見なして前記構造化文書を検証する。
【００３８】
前記所定の演算は、前処理および一方向関数適用処理の一方を少なくとも含むことを特徴とする。前記前処理は、前記電子文書の表現のゆれを吸収するための正規化処理であることを特徴とする。前記前処理は、前記電子文書の文字列表現から文書要素、文書要素属性および文書要素を含まない内容を節とする木(DOMツリーまたはXPathノードセットのうち少なくとも一つ)を生成する処理であることを特徴とする。前記一方向関数適用処理は、ＭＤ５（Message Digest 5）アルゴリズムおよびＳＨＡ１（Secure Hash Algorithm 1）アルゴリズムを含むダイジェスト関数を適用する処理であることを特徴とする。前記一方向関数適用処理は、線形合同法およびメルセンヌ・ツイスタを含む、再現性のある擬似乱数アルゴリズムを適用する処理であることを特徴とする。
【００３９】
前記判定手段は、前記文書スキーマから検証結果に影響しない部分として注釈要素を頂点とする部分木を除外することを特徴とする。W3C XML Schemaにおける注釈要素はannotation要素である。前記判定手段は、前記所定の文書スキーマが定義する第１の言語が前記構造化文書が直近に検証された時点での前記所定の文書スキーマが定義する第２の言語を包含しかつ直近の検証結果が真である場合、および前記第２の言語が前記第１の言語を包含しかつ直近の検証結果が偽である場合の一方の場合に前記文書スキーマに対して検証結果に影響する変更が加えられていないと判定することを特徴とする。
【００４０】
本発明の文書検証装置は、前記電子文書が直近に検証された時に前記一方向関数適用処理の結果得られた値と検証結果の組と前記電子文書とを組にして保持する保持手段をさらに備える。本発明の文書検証装置は、過去の検証処理において前記一方向関数適用処理の結果得られた値と検証結果の組を保持する保持手段をさらに備え、前記出力手段は、検証対象の文書に前記一方向関数適用処理の結果得られた値が前記保持手段で保持しているいずれかの値と同一である場合、その値に対応する検証結果を前記電子文書の検証結果とすることを特徴とする。また、直近の検証処理時点での所定の演算を実行して得られた情報を文書とともに流通させることで、文書識別子を管理するコストが不要になる。前記出力手段は、検証結果に加えて変更後の文書および該文書に所定の演算を実行して得られる情報を出力することを特徴とする。
【００４１】
本発明の文書検証方法は、入力された電子文書が所定の条件を満たしているか否か検証された後に、前記電子文書および前記条件の少なくとも一方に対して検証結果に影響する変更が加えられたか否かを判定する判定ステップと、前記電子文書および前記条件の少なくとも一方に対して変更が加えられたと判定された場合には、前記電子文書が所定の条件を満たしているか否かを検証して検証結果を出力し、前記変更が加えられていないと判定された場合には、直近に前記電子文書が前記条件を満たしているか否か検証されたときの結果を検証結果として出力する出力ステップとを有する。本発明によれば、電子文書および条件に変更が加えられていないと判定された場合には、直近に電子文書が条件を満たしているか否か検証されたときの結果を検証結果として出力する。一般に、判定処理時間は再検証処理時間より小さいため、電子文書に対する検証処理の負担を軽減することができ、処理効率を向上できる。
【００４２】
前記出力ステップは、前記電子文書が構成要素を節とする木で表現される構造化文書である場合、該構造化文書が所定の文書スキーマで定義される条件を満たしているか否か検証することを特徴とする。前記判定ステップは、前記電子文書が直近に検証された時点で前記電子文書に所定の演算を実行して得られた情報と、前記入力された電子文書に前記所定の演算を実行して得られた情報が異なる場合に、前記電子文書に対して検証結果に影響する変更が加えられたと判定することを特徴とする。
【００４３】
本発明によれば、直近に検証処理の対象となった時点での文書と現在の文書との比較に所定の演算を実行して得られる情報（たとえばダイジェスト値）を利用することにより、妥当性検証処理を実行せずに済むだけでなく、直近に検証処理の対象となった時点での文書を比較のために保存しておく必要がなくなり、必要な記憶領域を大幅に削減できる。
【００４４】
前記判定ステップは、前記構造化文書が直近に検証された時点で所定の文書スキーマに所定の演算を実行して得られた情報と、前記所定の文書スキーマに前記所定の演算を実行して得られた情報が異なる場合に、前記所定の文書スキーマに対して検証結果に影響する変更が加えられたと判定することを特徴とする。本発明によれば、直近に検証処理の対象となった時点での文書スキーマと現在の文書スキーマとの比較に所定の演算を実行して得られる情報（たとえばダイジェスト値）を利用することにより、妥当性検証処理を実行せずに済むだけでなく、直近に検証処理の対象となった時点での文書スキーマを比較のために保存しておく必要がなくなり、必要な記憶領域を大幅に削減できる。
【００４５】
本発明の文書検証方法は、前記電子文書を二つ以上の部分に分割するステップをさらに有し、前記出力ステップは、前記分割された電子文書のそれぞれが所定の条件を満たしているか否か検証することを特徴とする。本発明によれば、処理対象の文書を複数の部分に分割し、それぞれについて検証処理結果に影響を及ぼす変更がなされたか否かを判定することにより、文書が変更された場合でも、妥当性検証処理を実行すべき対象を文書全体より少なくでき、処理効率を改善できる。
【００４６】
本発明のプログラムは、入力された電子文書が所定の条件を満たしているか否か検証された後に、前記電子文書および前記条件の少なくとも一方に対して検証結果に影響する変更が加えられたか否かを判定する判定ステップ、前記電子文書および前記条件の少なくとも一方に対して変更が加えられたと判定された場合には、前記電子文書が所定の条件を満たしているか否かを検証して検証結果を出力し、前記変更が加えられていないと判定された場合には、直近に前記電子文書が前記条件を満たしているか否か検証されたときの結果を検証結果として出力する検証ステップをコンピュータに実行させる。
【００４７】
本発明によれば、電子文書および条件に変更が加えられていないと判定された場合には、直近に電子文書が条件を満たしているか否か検証されたときの結果を検証結果として出力する。一般に、判定処理時間は再検証処理時間より小さいため、電子文書に対する検証処理の負担を軽減でき、処理効率を向上できる。本発明のプログラムは、前記電子文書が構成要素を節とする木で表現される構造化文書である場合、該構造化文書が所定の文書スキーマで定義される条件を満たしているか否か検証することを特徴とする。
【発明の効果】
【００４８】
本発明によれば、電子文書に対する検証処理の負担を軽減することにより、処理効率を向上できる文書検証装置、文書検証方法およびプログラムを提供することができる。
【発明を実施するための最良の形態】
【００４９】
以下、本発明を実施するための最良の形態について説明する。
【００５０】
［旅程表作成サービス概要］
図１は、本システムの構成図である。図２は本システムの処理の流れ図である。図１に示すように、システム１００は、ホテル１０１、レンタカー会社１０２、レンタカー会社１０３、翻訳サービス１０４、航空会社１０５、航空会社１０６、鉄道会社１０７、利用者クライアント１０８、旅行代理店１０９および文書検証サービス１１０を備える。これらはそれぞれＣＰＵ、ＲＡＭおよびＲＯＭ等を備えたサーバまたはパーソナルコンピュータで構成され、インターネットなどのネットワーク１２０を介して接続されている。文書検証サービス（文書検証装置）１１０は、検証結果に影響する変更が文書・文書スキーマに加えられた場合のみ再検証し、また、影響が局所的な場合は、影響が及んだ部分のみ再検証することで、電子文書に対する検証処理の負担を軽減して、全体の処理効率を向上するものである。
【００５１】
以下の実施例１から実施例９で用いられる旅程表作成サービスは、利用者クライアント１０８から旅行代理店１０９が旅程表作成依頼書を受け取り、鉄道会社１０７や航空会社１０５、１０６、レンタカー会社１０２、１０３やホテル１０１などの予約状況を確認しながら旅程表を作成し、文言を利用者の所望の言語（日本語や英語）に統一して出力するものである。
【００５２】
より詳細には、利用者クライアント１０８から旅行代理店１０９に旅程作成依頼書が送付されると、旅行代理店１０９は、鉄道会社１０７に鉄道の予約を、旅行会社１０５に航空機の予約を、旅行会社１０６に航空機の予約を、レンタカー会社１０２にレンタカーの予約を、レンタカー会社１０３にレンタカーの予約を、ホテル１０１に宿泊予約を、翻訳サービス１０４に翻訳をそれぞれ依頼する。すると、旅行代理店１０９は、仮予約結果や翻訳結果を受けて、旅程案を作成し、利用者クライアント１０８に送付する。文書検証サービス１１０は、各サービスからの依頼に応じて、文書の妥当性検証処理を行うものである。
【００５３】
図３は利用者クライアント１０８が旅行代理店１０９に送信する旅程表作成依頼書を示す図である。図３の文書の２行目のitineraryRequest要素には、xmlns:xsi属性とxsi:noNamespaceSchemaLocation属性が含まれている。これらの属性は、この文書に対応する文書スキーマを特定するための手がかりを処理プログラムに与えるためにW3C XML Schema標準で定められたものである。以下の説明で用いる文書にもこれらの属性が出現する。ただし、W3C XML Schema標準では「処理プログラムは、これらの属性以外の手がかりを利用して文書スキーマを特定してもよい」とされている。したがって、図３の文書、および以下の説明で用いる文書からこれらの属性を除外し、文書スキーマと文書を対応付けるための他の方法を用いても、以下の各実施例で示す効果と同一の効果を得ることができる。文書スキーマと文書を対応付けるための他の方法の例を以下に示す。各サービスがＷｅｂサービスとして実現される場合、サービスごとに作成・公開されるWSDL文書の一部として、サービスの入出力文書に対応する文書スキーマが記述または参照されていてもよい。
【００５４】
図４から図１８は、図３の旅程表作成依頼書が本サービスに入力されたとき、図２のシーケンス図に記載された一連の処理実行時に生成・利用される文書を示す図である。図４は旅程表作成依頼書スキーマを示す図である。このスキーマはW3C XML Schema標準に準拠している。
【００５５】
図５は旅行代理店１０９が作成し、鉄道会社１０７に送信する旅程表ドラフトを示す図である。travel要素（８行目、５４行目）のstatus属性の値が"requested"に設定されている。これらの値の説明は以下の図６で行う。なお、２行目のitineraryInProcess要素などにはxml:lang属性が含まれている。この属性は、属性を含む文書要素の内容に含まれる文字データの言語（日本語、英語など）を示すため、XML標準で定められたものである。
【００５６】
図６は旅程表ドラフトスキーマを示す図である。travel要素は移動する行為を、stay要素は宿泊する行為を意味する。これらの要素のstatus属性の値が"inactive"の場合その行為は"未予約"であり、"requested"の場合その行為は"予約依頼中"であり、"reserved"の場合その行為は"予約済み"であることを意味する。
【００５７】
図７は鉄道会社１０７が旅行代理店１０９に返信する旅程表ドラフトを示す図である。鉄道会社１０７は、status属性の値が"requested"であるtravel要素に対応する予約を試み、予約できた場合は予約内容を記載したmethod要素をtravel要素の末子に追加し、status属性の値を"reserved"に変更する。図８は旅行代理店１０９が航空会社１０５に送信する旅程表ドラフトを示す図である。２２行目と５２行目のtravel要素のstatus属性の値が"requested"になっている。
【００５８】
図９は航空会社１０５が旅行代理店１０９に返信し、旅行代理店１０９が航空会社１０６に送信する旅程表ドラフトを示す図である。航空会社１０５は、２２行目のtravel要素に対応する予約のみを実行する。これに伴い、22行目のtravel要素のstatus属性の値が"reserved"に変更される。旅行代理店１０９は、５７行目のtravel要素に対応する予約を航空会社１０６に依頼する。図１０は航空会社１０６が旅行代理店１０９に返信する旅程表ドラフトを示す図である。航空会社１０６は、５７行目のtravel要素に対応する予約を実行する。これに伴い、57行目のtravel要素のstatus属性の値が"reserved"に変更される。
【００５９】
図１１は旅行代理店１０９がレンタカー会社１０２に送信し、レンタカー会社１０２が返信し、旅行代理店１０９がレンタカー会社１０３に送信する旅程表ドラフトを示す図である。３６行目と５０行目のtravel要素のstatus要素の値が"requested"になっている。レンタカー会社１０２は、レンタカーを手配できなかったので、そのまま旅行代理店１０９に返信する。図１２は、レンタカー会社１０３が旅行代理店１０９に返信する旅程表ドラフトである。レンタカー会社１０３は、要求された予約を実行する。これに伴い、３６行目と５５行目のtravel要素のstatus要素の値が"reserved"に変更される。
【００６０】
図１３は旅行代理店１０９がホテル１０１に送信する旅程表ドラフトを示す図である。５０行目のstay要素のstatus属性の値が"requested"になっている。図１４はホテル１０１が旅行代理店１０９に返信する旅程表ドラフトを示す図である。ホテルは予約を実行し、結果を旅程表ドラフトに追加して旅行代理店１０９に返信する。図１５は旅行代理店１０９が欠落情報を補足した旅程表ドラフトを示す図である。旅行代理店１０９によって、36行目と55行目のstatus属性が"reserved"に変更され、４２行目と５７行目のplace要素のlang属性と内容を追加される。
【００６１】
図１６は旅行代理店１０９が旅程表ドラフトから生成し、翻訳サービス１０４に送信する旅程表を示す図である。旅行代理店109は、旅程表ドラフトの情報のうち、最終出力である旅程表に必要なもののみを抽出する。この旅程表の一部は英語で記述されているので、利用者の要求する日本語に変換するため、旅程表を翻訳サービス１０４に送信する。図１７は旅程表スキーマを示す図である。図１８は翻訳サービス１０４が旅行代理店１０９に返信し、旅行代理店１０９が利用者に送信する旅程表を示す図である。翻訳サービス１０４から返信された旅程表は利用者クライアント１０８を介して利用者１１６に送信される。
【００６２】
［文書検証サービスの役割］文書検証サービス１１０は図２のシーケンス図には記載されていないが、旅程表作成サービスを構成する各サービス（利用者クライアント１０８、旅行代理店１０９、鉄道会社１０７、航空会社１０５、１０６、レンタカー会社１０３、ホテル１０１）に文書（旅程表依頼書、旅程表ドラフト、旅程表）が送信されるとき、送信先の各サービスは文書を文書検証サービス１１０に出力し、妥当性検証処理を依頼する。
【００６３】
なお、文書がサービス間で送受信されるとき、文書そのものだけが送受信されるのではなく、文書を含む送受信用文書が実際には送受信される。図１９は図１１の旅程表ドラフトが旅行代理店１０９からレンタカー会社１０２に送信され、レンタカー会社１０２が文書検証サービス１１０に妥当性検証処理を依頼するときの送受信用文書を示す図である。
【００６４】
図１９に示すように、送受信用文書はSOAP文書として実現されており、送受信の対象となる文書はSOAPボディ（Body要素、6行目から92行目）の内容として表現されている。また、SOAPヘッダ（Header要素、3行目から5行目）の内容には、文書検証サービス１１０の処理に必要な情報がvalidatorID要素（実施例１）またはdigest要素（実施例２以降）として記載されている。validatorID要素の内容は、SOAPボディの内容である文書に付与されている識別子であり、digest要素の内容は、文書のダイジェスト値である。また、validity属性の値は、SOAPボディの内容である文書がもっとも最近に妥当性検証処理の対象となったときの処理結果の真偽値である。
【００６５】
文書検証サービス１１０に妥当性検証処理を依頼したサービスは、文書検証サービス１１０から送受信用文書を受け取り、SOAPヘッダ中のvalidatorID要素またはdigest要素のvalidity属性の値を参照して妥当性検証処理の結果を得る。そして、妥当性検証処理が成功した場合は、文書に対して所定の処理を実行し、失敗した場合は所定のエラー処理を実行する。
【実施例１】
【００６６】
まず、実施例１について説明する。実施例１は文書同士を比較する場合の例である。図１１の旅程表ドラフトが旅行代理店１０９からレンタカー会社１０２に送信され、そのまま旅行代理店１０９に返信される局面を考える。このとき、旅程表ドラフトは、レンタカー会社１０２に送信されたときと旅行代理店１０９に返信されたときに文書検証サービス１１０による妥当性検証処理の対象となる。本実施例の文書検証サービス１１０では、旅行代理店１０９に返信されたときの妥当性検証処理を実行せずに済むため、処理の効率化を実現できる。
【００６７】
図２０は実施例１のシステムの構成図である。図２０に示すように、システム１００は、レンタカー会社１０２、旅行代理店１０９および文書検証サービス１１０を備える。これらはネットワーク１２０を介して接続されている。文書検証サービス１１０は、送受信用文書保持部１１１、検証済文書保持部１１２、文書正規化部１１３、文書検証部１１４および検証処理制御部１１５を備える。図２０では、データの流れを矢印で示している。
【００６８】
送受信用文書保持部１１１は、入力された送受信用文書を保持し、検証対象の文書に識別子を付与してそのコピーを検証結果とともに保持する。検証済文書保持部１１２は、電子文書が直近に検証された時に一方向関数適用処理の結果得られた値と検証結果の組と検証済み電子文書とを組にして保持する。
【００６９】
検証処理制御部１１５は、検証処理全体を制御するものであり、入力された電子文書が所定の条件を満たしているか否か検証された後に、電子文書または条件に対して検証結果に影響する変更が加えられたか否かを判定する。ここで、所定の条件とは、電子文書が構造化文書である場合は、所定のスキーマで定義される条件のことをいう。検証処理制御部１１５は、電子文書または条件に対して変更が加えられたと判定された場合には、電子文書が所定の条件を満たしているか否かを検証して検証結果を出力し、変更が加えられていないと判定された場合には、検証済文書保持部１１２を参照して直近に電子文書が前記条件を満たしているか否か検証されたときの結果を検証結果として出力する。なお、直近の検証結果がない場合には、電子文書が所定の条件を満たしているか否かを検証して結果を出力する。
【００７０】
また、検証処理制御部１１５は、電子文書が直近に検証された時点で電子文書に所定の演算を実行して得られた情報と、入力された電子文書に所定の演算を実行して得られた情報が異なる場合に、電子文書に対して検証結果に影響する変更が加えられたと判定する。この所定の演算には前処理が含まれる。ここで前処理には電子文書の表現のゆれを吸収するための正規化処理が含まれる。この正規化処理は、文書正規化部１１３で実行される。正規化処理とは、文書が複数のプログラムによって順次処理されるとき、個々のプログラムによる本来の機能とは無関係な処理（スペースや改行記号の追加、文字コードの変換など）によって発生する表記のゆれを吸収するための処理である。文書に対して正規化処理を実行することにより、同一とみなすべき文書をまったく同じ表記にそろえることができるので、同一性の判定が容易になる。文書検証部１１４は文書を検証するものであり、電子文書が構造化文書である場合、構造化文書が所定の文書スキーマで定義される条件を満たしているか否か検証する。
【００７１】
図２２は上記の局面で検証済文書保持部１１２に保持されている文書を示す図である。図２２に示すように、SOAP文書は、ヘッダ部分（SOAPヘッダ、図２２の３行目から５行目）とボディ部分（SOAPボディ、図２２の６行目から９４行目）に大別できる。図２２の文書の４行目に保持されているvalidatorID要素には、SOAPボディに保持されている文書の識別子（validatorID要素の内容）と、この文書の妥当性検証結果（validity属性の値）が保持されている。
【００７２】
一方、図２３はレンタカー会社１０２から文書検証サービス１１０に入力される送受信用文書を示す図である。図２３のSOAPボディ中の文書は、図２２のSOAPボディ中の文書に対し、４１行目と５５行目のtravel要素のstatus属性の値を"inactive"から"requested"に変更したものである。この送受信用文書のSOAPヘッダには、図２２の文書と同じ識別子が付与されている。
【００７３】
次に、文書検証サービス１１０の処理の流れを説明する。図２１は実施例１の検証処理制御部１１５の処理の流れ図である。図２１の処理で起動されるサブルーチンCANONICALIZEとサブルーチンVALIDATEはそれぞれ文書正規化部１１３と文書検証部１１４が実行する。
【００７４】
図２３の送受信用文書が文書検証サービス１１０に入力されると、図２１の処理が起動する。ステップＳ１２４１で、検証処理制御部１１５は、変数ＸにSOAPボディの内容を代入する。ステップＳ１２４２で、変数Ｘの文書に文書識別子が付与されていない場合、ステップＳ１２４３で、文書識別子を新規に発行して変数Ｘの文書に割り当て、ステップＳ１２４９に進む。ステップＳ１２４２で、変数Ｘの文書に文書識別子が付与されている場合は、ステップＳ１２４４で、検証済文書保持部１１２から変数Ｘの文書の文書識別子を持つ文書を得て変数Ｙに代入する。図２３のSOAPボディ中の文書には識別子が付与されているので、検証済文書保持部１１２からその識別子を持つ文書（図２２の文書）が得られる。ステップＳ１２４５で、文書正規化部１１３は、変数Ｘの値を引数にしてサブルーチンCANONICALIZEを実行する。サブルーチンCANONICALIZEは、正規化処理を実行する。
【００７５】
ステップＳ１２４６で、両者が比較され、サブルーチンCANONICALIZEの出力と変数Ｙが同一の場合、ステップＳ１２４８で、変数Ｙの文書に対応付けられた検証結果を送受信用文書に付与し、ステップＳ１２４１２に進む。つまり、レンタカー会社１０２が図１１の文書を変更せずにそのまま旅行代理店１０９に返信し、旅行代理店１０９が文書検証サービス１１０に図２３の文書の検証処理を依頼するとき、ステップＳ１２４６で比較されるのはいずれも図２３の文書なので両者は同一と判定され、サブルーチンVALIDATEはスキップされる。このように、本実施例の文書検証サービスを利用することで、送受信用文書が旅行代理店１０９に返信されたときの妥当性検証処理を実行せずに済むので、処理効率を向上できる。
【００７６】
ステップＳ１２４６で、サブルーチンCANONICALIZEの出力と変数Ｙが同一でない場合、ステップＳ１２４７で、変数Ｙの文書が検証済文書保持部１１２から削除される。図２３の例では、すでに示したとおり両者は異なるので、ステップＳ１２４７で図２２の文書が検証済文書保持部１１２から削除される。ステップＳ１２４９で、文書検証部１１４は、変数Ｘを引数にしてサブルーチンVALIDATEを実行する。サブルーチンVALIDATEでは、文書スキーマに対する文書の妥当性検証処理が実行され、検証結果が真偽値で出力される。ステップＳ１２４１０で、変数Ｘの文書とサブルーチンVALIDATEの出力が検証済文書保持部１１２に追加される。本例では、サブルーチンVALIDATEは"真"を返すので、図２３の文書がそのまま検証済文書保持部１１２に追加される。ステップＳ１２４１１で、サブルーチンVALIDATEの出力が送受信用文書に付与される。ステップＳ１２４１２で、送受信用文書が返信される。つまり、レンタカー会社１０２には図２３の文書がそのまま返信される。
【００７７】
ＸＭＬ文書に対する正規化処理の仕様には、Canonical XML、Exclusive XML Canonicalizationがある。ステップＳ１２２４では、これらの仕様に基づく正規化処理のいずれかが実行されるものとする。これらの正規化処理で実行される具体的な処理は、XMLプロセッサ（XML文書を読み込み、その内容および構造へのアクセスを提供するプログラム。XML標準で規定されている）が実行する処理と、正規化処理固有の処理に大別でき、それぞれには以下のもののうち０個以上が含まれる。
【００７８】
（XMLプロセッサが実行する処理）
・改行記号の#xAへの統一
・属性値の正規化
・CDATAセクションの文字内容への置き換え
・文字参照、解析対象実体参照の置き換え
（正規化処理固有の処理）
・文字コードのUTF-8への統一
・XML宣言およびDTDの削除
・空要素の開始タグ・終了タグの組への置き換え
・属性値の区切り文字の二重引用符への統一
・冗長な名前空間宣言の削除
・デフォルト属性値の設定（XML標準 3.3.3節）
・文書要素属性・名前空間宣言のソート（XML Canonicalization標準 2.2節）
【００７９】
なお、XML Canonicalization標準 2.2節で定義されている文書要素属性・名前空間宣言の順序関係は以下の通りである。
・名前空間宣言が文書要素属性よりも先に出現する
・名前空間宣言は名前空間の名前（ローカル名）でソートされる
・文書要素属性は、名前空間URIをプライマリキー、名前（ローカル名）をセカンダリキーとしてソートされる
【００８０】
本実施例によれば、送受信用文書が旅行代理店１０９に返信されたときの妥当性検証処理を実行せずに済むので、処理効率を向上できる。
【実施例２】
【００８１】
次に実施例２について説明する。実施例２はダイジェスト値の比較を行う例である。実施例２も、実施例１と同様、図１１の旅程表ドラフトが旅行代理店１０９からレンタカー会社１０２に送信され、そのまま旅行代理店１０９に返信される局面を考える。このとき、旅程表ドラフトは、レンタカー会社１０２に送信されたときと旅行代理店１０９に返信されたときに文書検証サービス１１０による妥当性検証処理の対象となる。
【００８２】
図２４は実施例２のシステムの構成図を示す図である。図２４に示すように、システム２００は、レンタカー会社１０２、旅行代理店１０９および文書検証サービス２１０を備える。これらはインターネットなどのネットワーク１２０を介して接続されている。文書検証サービス２１０は、送受信用文書保持部１１１、文書正規化部１１３、文書検証部１１４、検証処理制御部１１５、ダイジェスト値算出部２１１を備える。図２４では、データの流れを矢印で示している。文書検証サービス２１０は、入力された送受信用文書を送受信用文書保持部１１１に保持し、検証処理制御部１１５の処理が起動する。
【００８３】
検証処理制御部１１５は、電子文書が直近に検証された時点で電子文書に所定の演算を実行して得られた情報と、入力された電子文書に所定の演算を実行して得られた情報が異なる場合に、電子文書に対して検証結果に影響する変更が加えられたと判定する。この所定の演算には、実施例１で説明した前処理の他に、ダイジェスト値算出部２１１が行う一方向関数適用処理が含まれる。
【００８４】
図２５は実施例２の検証処理制御部１１５の処理の流れを示す図である。図２８は、レンタカー会社１０２による妥当性検証処理依頼時、レンタカー会社１０２から文書検証サービス２１０に入力される送受信用文書を示す図である。ステップＳ１０４１で、検証処理制御部１１５は、変数ＸにSOAPボディの内容を代入する。つまり、図１１の文書が変数Ｘに代入される。ステップＳ１０４２で、変数Ｘを引数にしてサブルーチンEVALUATEが実行される。ステップＳ１０４３で、サブルーチンEVALUATEの出力が変数Ｘに対応付けられる。つまり、ステップＳ１０４３では、ステップＳ１０４２で出力された値の組が、変数Ｘの値である文書に対応付けられて送受信用文書のSOAPヘッダに書き込まれる。図３１は、ステップＳ１０４３終了時点での送受信用文書を示す図である。
【００８５】
ステップＳ１０４４で、図３１の送受信用文書がレンタカー会社１０２に返信され、処理が終了する。レンタカー会社１０２は図３１の送受信用文書の４行目のdigest要素のvalidity属性の値を参照して妥当性検証処理が成功したことを知り、文書に対する処理が実行される。本実施例では、レンタカー会社１０２は文書を変更することなく旅行代理店に図３１の送受信用文書を送信する。
【００８６】
図２６はステップＳ１０４２で、サブルーチンEVALUATEの処理の流れを示す図である。この処理は検証処理制御部１１５により実行される。ステップＳ１０５１で、入力文書に対してサブルーチンCANONICALIZEを実行して、図１１の文書からDOM(Document Object Model)ツリーを生成する。DOMは、XML文書などの構造化文書をテキストとしてではなく、文書（DOCUMENT）、文書要素（ELEMENT）、文書要素属性（ATTRIBUTE）、属性値（TEXT）や文字データ （TEXT）を表すオブジェクトを節（ノード）とする木として扱うためのモデルと、このモデルにアクセスするためのインタフェースである。図２９は生成されるDOMツリーを示す図である。図２９では、DOMツリーを構成するノードを各行に記載している。ノードのタイプは各行の先頭から”:”までの文字列で示される。たとえば１行目のノードのタイプは、文書全体を示すDOCUMENTノードである。ノードが文書要素（ELEMENTノード）または文書要素属性（ATTRIBUTEノード）である場合は、”:”の後に要素名または属性名が示される。ノードがテキスト（TEXTノード）である場合は、”:”の後にテキストデータが示される。
【００８７】
また、ノード間の親子関係は行頭からのインデントで表わす。たとえば２行目のELEMENTノードの親ノードは1行目のDOCUMENTノードであり、子ノードは３行目、５行目、７行目のATTRIBUTEノードと、９行目、１４行目のELEMENTノードである。また、図３０は、図２９の１行目から４２行目の各ノードの説明を示す図である。
【００８８】
ステップＳ１０５２で、出力に対してサブルーチンGET_DIGESTが実行される。ステップＳ１０５３で、文書に旧ダイジェスト値が付与されていない場合、ステップＳ１０５５に進み、送受信用文書保持部１１１中の送受信用文書（図２８参照）のSOAPヘッダ中のdigest要素（４行目）が参照された結果、文書に旧ダイジェスト値が付与されていると判定され、処理がステップＳ１０５４に移る。ステップＳ１０５４で、旧ダイジェスト値と、サブルーチンGET＿DIGESTから出力された新ダイジェスト値が同一か判定され、新ダイジェスト値と旧ダイジェスト値が同一の場合、ステップＳ１０５７で、旧ダイジェスト値、直近のサブルーチンVALIDATEの結果の組が出力される。
【００８９】
ステップＳ１０５４で、新ダイジェスト値が旧ダイジェスト値と同一でない場合、ステップＳ１０５５に進む。本実施例では、両者は同一でないため、処理がステップＳ１０５５に進んでサブルーチンVALIDATEが実行され、サブルーチンVALIDATEでは、文書スキーマに対する文書の妥当性検証処理が実行され、検証結果が真偽値で出力される。本例では、妥当性検証処理の結果として"真"が出力される。そしてステップＳ１０５６で、以下のサブルーチンVALIDATEの結果と新ダイジェスト値の組が出力されてステップＳ１０４２が終了する。
"真", "3bebcec335f6e46bfe3563897ee544e0"
【００９０】
ステップＳ１０５１のサブルーチンCANONICALIZEでは、正規化処理の一例として、入力文書からDOMツリーを生成する。なお、DOMツリーはDOMインタフェースを備えるXMLプロセッサによって生成されるので、実施例１で示した正規化処理のうち、XMLプロセッサによる処理はここでも実行されるものとする。
【００９１】
さらに、DOMツリーが出力される前に、以下の処理が実行されているものとする。
・文字コードのUTF-8への統一
・冗長な名前空間宣言の削除
・デフォルト属性値の設定（XML標準 3.3.3節）
・文書要素属性・名前空間宣言のソート（XML Canonicalization標準 2.2節）
【００９２】
なお、本実施例を含む本明細書のすべての実施例では、入力文書からDOMツリーを生成するとき、ELEMENTノードを兄弟に持つTEXTノードで、内容が空白文字（スペース、復帰、改行、タブ）のみからなるものを削除するものとする。XML標準では、文書スキーマ中の要素内容モデルに対応する内容に含まれる文書要素の間に空白文字を含むことを許しているが、この空白文字は検証処理結果に影響を及ぼさない。本実施例を含むすべての実施例で用いられる文書スキーマで定義される内容モデルはすべて要素内容モデルであるため、上で示したTEXTノードで、空白文字を削除しても検証処理結果に影響しない。また、DOMの仕様では、DOMツリーでは文書要素と内容の関係がDOMツリーを構成し、文書要素と文書要素属性の関係はDOMツリーには含まれないとされている。しかし、本実施例を含む本明細書のすべての実施例では、前者だけでなく後者の関係もDOMツリーに含めるものとする。
【００９３】
図２７はステップＳ１０５２のサブルーチンGET_DIGESTの処理の流れを示す図である。この処理はダイジェスト値算出部２１１で実行される。ステップＳ１０６１では、ダイジェスト値算出部２１１は、DOMツリーの各ノードに順次DOMHASHアルゴリズムを適用し、ダイジェスト値を得る。ステップＳ１０６２で、ダイジェスト値をエンコードして出力する。サブルーチンGET＿DIGESTから出力されるダイジェスト値を以下に示す。
3bebcec335f6e46bfe3563897ee544e0
【００９４】
上記において、DOMHASHアルゴリズムをDOMツリーの各ノードに適用するため、DOMツリーのノードを順序付ける必要があるが、深さ優先探索アルゴリズムや幅優先探索アルゴリズムなどの探索順序を採用すればよい。
【００９５】
DOMHASHアルゴリズムは、DOMツリーを構成するノードのうち、テキスト、処理命令、文書要素属性、文書要素、および文書ノードのダイジェスト値を算出するアルゴリズムである。なお、本発明の各実施例でDOMHASHアルゴリズムを利用する場合には、処理命令ノードに対するダイジェスト値算出処理は実行しないものとする。なお、上記のDOMHASHアルゴリズムで利用するハッシュ関数として、MD5アルゴリズムやSHAアルゴリズム、SHA1アルゴリズムなどを利用できるが、本実施例および他の実施例ではSHA1アルゴリズムを利用するものとする。
【００９６】
［旅行代理店による妥当性検証処理依頼］旅行代理店１０９は図３１の送受信用文書を受信し、文書検証サービス２１０に妥当性検証処理を依頼する。このとき、ステップＳ１０５２で、サブルーチンGET＿DIGESTから出力されるダイジェスト値を以下に示す。
3bebcec335f6e46bfe3563897ee544e0
【００９７】
ステップＳ１０５３では、送受信用文書保持部１１１中の送受信用文書（図２８参照）のSOAPヘッダ中のdigest要素（４行目）が参照された結果、文書に旧ダイジェスト値が付与されていると判定され、処理がステップＳ１０５４に移る。ステップＳ１０５４では、旧ダイジェスト値と、サブルーチンGET＿DIGESTから出力されたダイジェスト値が同一か判定される。ここでは、両者は同一であるため、ステップＳ１０５７で旧ダイジェスト値と直近のサブルーチンVALIDATEの結果が前記digest要素から読み出されて出力され、ステップＳ１０４２が終了する。
【００９８】
ステップＳ１０４３では、ステップＳ１０４２で出力された値の組が、変数Ｘの値である文書に対応付けられて送受信用文書のSOAPヘッダに書き込まれる。ここでは、ステップＳ１０４２で出力された値の組と、送受信用文書保持部１１１中の送受信用文書のSOAPヘッダ中のdigest要素の内容が同一であるため、送受信用文書は変更されない。そしてステップＳ１０４４で図３１の送受信用文書が旅行代理店１０９に送信され、処理が終了する。
【００９９】
このように、本実施例の文書検証サービス２１０を利用することで、直近に検証処理の対象となった時点での文書と現在の文書との比較にダイジェスト値を利用する。これにより、旅行代理店１０９に返信されたときの妥当性検証処理を実行せずに済むだけでなく、直近に検証処理の対象となった時点での文書を保存しておく必要がなくなり、必要な記憶領域を大幅に削減できる。また、直近の検証処理時点でのダイジェスト値を文書とともに流通させるので、文書識別子を管理するコストが不要になる。
【０１００】
なお、本明細書の各実施例では、文書検証サービス２１０でのサブルーチンCANONICALIZEを実行した結果得られる文書は文書検証サービス２１０から出力されないという前提に基づいていた。しかし、W3C XML Schemaを利用した検証処理では、文書スキーマに定義された文書要素内容のデフォルト値を文書中の文書要素に反映する処理など、文書を変更する処理を含む場合がある。たとえば図３２の文書スキーマで図６の文書を検証すると、検証結果の文書（図３３参照）にはplace要素(27行目など)の値としてデフォルト値の”TBD”が追加されている。
【０１０１】
このように変更された文書を他のサービスでも利用する場合には、送受信用文書保持部１１１の文書と、サブルーチンCANONICALIZEから出力される文書を置き換え、サブルーチンCANONICALIZEから出力される文書に対してサブルーチンGET＿DIGESTを実行した結果出力されるダイジェスト値と、サブルーチンVALIDATEの出力である真偽値の組とともに出力するよう構成すればよい。すなわち、検証処理制御部１１５は、検証時に文書が変更される場合、検証結果に加えて変更後の文書および該文書に所定の演算を実行して得られる情報を出力する。
【実施例３】
【０１０２】
次に実施例３について説明する。実施例３はテキスト表現からダイジェスト値を算出する場合の例である。実施例３の文書検証サービスは、サブルーチンCANONICALIZE（Ｓ１０５１）およびサブルーチンGET＿DIGEST（Ｓ１０５２）の内容を除いて、実施例２の文書検証サービスと同一である。実施例３でも、図２４を用いて説明する。検証処理制御部１１５が行う前処理が、電子文書の文字列表現から文書要素、文書要素属性および文書要素を含まない内容を節とする木を生成する処理であり、ダイジェスト値算出部２１１が行う一方向関数適用処理がＳＨＡ１アルゴリズムを含むダイジェスト関数を適用する処理である場合の例である。本実施例の文書検証サービス２１０のサブルーチンCANONICALIZEは、実施例１のサブルーチンCANONICALIZE（Ｓ１２４５）と同一の処理を実行する。このため説明を省略する。
【０１０３】
図３４は本実施例の検証処理制御部１１５のサブルーチンGET＿DIGESTの処理の流れを示す図である。ステップＳ１０７１で、文書のテキストとしての表現からダイジェスト値を出力する。実施例２のGET＿DIGEST（図２７参照）では文書からDOMツリーを経由してダイジェスト値を算出したのに対し、本実施例では文書のテキストとしての表現からダイジェスト値を算出する。ダイジェスト値の算出には、ハッシュ関数として、MD５アルゴリズムやSHAアルゴリズム、SHA１アルゴリズムなどを利用できる。ステップＳ１０７２で、ダイジェスト値がエンコードされ出力される。エンコード処理とは、バイナリデータとして出力されるダイジェスト値をテキストデータに変換する処理である。なお、本発明の各実施例では、エンコード処理を実行した後に新旧ダイジェスト値を比較しているが、旧ダイジェスト値をバイナリデータのまま保持しておき、エンコード処理を実行せずに同等の効果を得るよう構成することも可能である。
【０１０４】
本実施例の文書検証サービス２１０により、実施例２の文書検証サービスと同等の効果を得ることができる。具体的には、実施例２と同様に、図１１の旅程表ドラフトが旅行代理店１０９からレンタカー会社１０２に送信され、そのまま旅行代理店１０９に返信される局面を考える。このとき、本実施例の文書検証サービス２１０では、旅行代理店１０９に返信されたときの妥当性検証処理を実行せずに済むため、処理の効率化を実現できる。
【０１０５】
なお、本実施例では、サブルーチンCANONICALIZEで実施例１と同一の正規化処理を実行したため、サブルーチンCANONICALIZEの出力はXML文書のテキスト表現となっている。一方、XML Canonicalization標準に示されている通り、正規化処理はXML文書のテキスト表現だけでなくXPathノードセットを対象に実行できる。これを利用し、文書のテキスト表現（電子文書の文字列表現）からXPathノードセット（文書要素、文書要素属性および文書要素を含まない内容を節とする木）を生成し、XML Canonicalization標準の正規化処理を実行した後に、文書のテキスト表現に戻すことなくXPathノードセットから直接ダイジェスト値を算出するように構成することも可能である。
【実施例４】
【０１０６】
次に実施例４について説明する。実施例４はサンプリング関数を用いる例である。実施例４は、ダイジェスト値算出部２１１が行う一方向関数適用処理が、線形合同法およびメルセンヌ・ツイスタを含む再現性のある擬似乱数アルゴリズムを適用する処理である場合の例である。すなわち、実施例４の文書検証サービスは、実施例３の文書検証サービスのダイジェスト値算出部２１１のステップＳ１０７１で用いられるMD５アルゴリズムやSHA１アルゴリズムなどのハッシュ関数の代わりに、文書の文字数やバイト数を算出する関数と、線形合同法やメルセンヌ・ツイスタなどの再現性のある擬似乱数発生関数を組み合わせたものを用いる点を除いて、実施例３の文書検証サービスと基本的に同一である。
【０１０７】
これらの関数の組合せは、文書の文字数またはバイト数とサンプル文字列の組を出力する。本実施例でも図２４を用いて説明する。なお、以下の例では、サンプル文字列の文字数を３２とする。本実施例で採用した方法(ハッシュ関数の代わりに、文書の文字数やバイト数を算出する関数と、線形合同法やメルセンヌ・ツイスタなどの再現性のある擬似乱数発生関数を組み合わせたものを用いる方法)は、実施例３の文書検証サービスだけでなく、実施例２の文書検証サービスのステップＳ１０６１にも適用することが可能である。
【０１０８】
本実施例でも実施例１と同様に、図１１の旅程表ドラフトが旅行代理店１０９からレンタカー会社１０２に送信され、そのまま旅行代理店１０９に返信される局面を考える。図３５は、レンタカー会社１０２に送信される送受信用文書の例を示す図である。４行目のdigest要素には、直近に文書検証サービスによって検証されたときの検証結果（validity属性の値）、文書の文字数（documentLength属性の値）、サンプル文字列（内容）が保持されている。なお、サンプル文字列中にはタグの開始文字である"＜"や文字参照の開始文字である"＆"が出現し得るので、これを単なる文字とみなすため、サンプル文字列をCDATAセクション中に記述している。
【０１０９】
図３６は本実施例の文書検証サービス２１０の検証処理制御部１１５が実行するサブルーチンEVALUATEの処理の流れの一例を示す図である。ステップＳ１０８１で、入力文書に対してサブルーチンCANONICALIZEを実行する。ステップＳ１０８２で、サブルーチンCANONICALIZEの出力に対してサブルーチンGET＿DIGESTが実行される。図３５の送受信用文書が本実施例の文書検証サービス２１０に入力されたとき、サブルーチンGET＿DIGESTから出力される文書の文字数とサンプル文字列を以下に示す（二重引用符を除く）。
"2923"
"annl 5ee0/n5 tu ri =dlma00at100p"
【０１１０】
ステップＳ１０８３で、文書に旧（文字数、サンプル文字列）の組が付与されている場合、ステップＳ１０８４に進み、付与されていない場合、ステップＳ１０８５に進む。ステップＳ１０８４で、新文字数が旧文字数と同一であり、かつ新サンプル文字列が旧サンプル文字列と同一の場合、ステップＳ１０８７で、旧（文字数、サンプル文字列）、直近のサブルーチンVALIDATEの結果の組が出力される。ステップＳ１０８４で、新文字数が旧文字数と同一であり、かつ新サンプル文字列が旧サンプル文字列と同一でない場合、ステップＳ１０８５に進む。本例では、ステップＳ１０８４で、ステップＳ１０８２のサブルーチンGET＿DIGESTから出力される値は図３５の４行目のdigest要素に記載されている文字数およびサンプル文字列と異なるので、処理はステップＳ１０８５に進む。
【０１１１】
ステップＳ１０８５で、入力文書に対してサブルーチンVALIDATEが実行される。ステップＳ１０８６で、新（文字数、サンプル文字列）、VALIDATEの結果の組を出力する。本例では、上記の文書文字数、サンプル文字列、VALIDATEの結果（"真"）が出力される。この結果、レンタカー会社１０２に返信される送受信用文書を図３９に示す。図３５の送受信用文書に対し、４行目のdigest要素の値が更新されている。
【０１１２】
図３７はダイジェスト値算出部２１１が実行するサブルーチンGET＿DIGESTの処理の流れの一例を示す図である。ステップＳ１０９１で、ダイジェスト値算出部２１１は、文書の文字数とサンプル文字列を算出する。ステップＳ１０９２で、文字数、サンプル文字列が出力される。
【０１１３】
図３８はステップＳ１０９１の処理の流れの一例を示す図である。ステップＳ１１０１で、ダイジェスト値算出部２１１は、変数Ａにサンプル文字列数を、変数Ｂに０を、変数Ｃに空の文字列を代入する。ステップＳ１１０２で、入力文書から制御文字（改行記号、タブなど）が取り除かれる。ステップＳ１１０３で、文書の文字数が変数Ｄに代入される。ステップＳ１１０４で、変数Ａの値が変数Ｂの値より大きい場合、ステップＳ１１０５で、変数Ｄ以下の正の整数が一つランダムに生成され、変数Ｅに代入される。線形合同法やメルセンヌ・ツイスタなどの擬似乱数発生関数は、ステップＳ１１０５で用いられる。ステップＳ１１０６で、文書の（変数Ｅの値）番目の文字が変数Ｃの末尾に追加される。ステップＳ１１０８で、変数Ｂを一つインクリメントしてステップＳ１１０４に戻る。ステップＳ１１０４で、変数Ａの値が変数Ｂの値よりも大きくない場合、ステップＳ１１０９で、変数Ｄの値、変数Ｃの値が出力される。
【０１１４】
次に、図３９の送受信用文書がレンタカー会社１０２からそのまま旅行代理店１０９に返信される局面を考える。旅行代理店１０９は文書検証サービス２１０に再び妥当性検証処理を依頼する。このとき、GET＿DIGESTから出力される文書の文字数とサンプル文字列は以下のとおりとなり、図３９の４行目のdigest要素に記載されている文字数およびサンプル文字列と一致する。
"2923"
"annl 5ee0/n5 tu ri =dlma00at100p"
このため、処理はステップＳ１０８７に進み、サブルーチンVALIDATEをスキップできるので、処理の効率化を実現できる。
【実施例５】
【０１１５】
次に実施例５について説明する。実施例５の文書検証サービス２１０は、妥当性検証処理結果に影響しない部分を文書から削除した結果に対してダイジェスト値算出処理を実行することを特徴とする。本実施例においても図２４を用いて説明する。
【０１１６】
文書スキーマがW3C XML Schemaの仕様に基づく場合、文書中の処理命令や文字列型の内容などを文書から除外しても、妥当性検証処理結果には影響しない。このため、本実施例では、検証処理制御部１１５は、電子文書がXML文書である場合、検証結果に影響しない部分としてCDATAセクション、コメント、処理命令および文書スキーマ中の混合内容モデルに対応する内容に含まれる文字データ（図４２の６行目“子供は３歳児です。”）を除外する。
【０１１７】
また、検証処理制御部１１５は、電子文書としてXML文書を、文書スキーマとしてW3C XML Schemaが入力された場合、検証結果に影響しない部分として、W3C XML Schemaで定義された文字列型の内容で、他の文書要素を含まないもの、および、文字列型の値を持つべき文書要素属性の値をXML文書から除外する。これらの部分を除外してからダイジェスト値や文字数・サンプル文字列を算出することで、ダイジェスト値算出処理の効率を改善できる。
【０１１８】
本実施例の文書検証部１１４は、妥当性検証処理実行中に、文字データのみを内容とする文書要素を処理した後に、その文書要素のcontentType属性を追加し、その値として、内容の文字データのデータ型に対応する文字列を設定するものとする。また、混合内容モデルを持つ要素型に対応する文書要素を処理した後に、その文書要素にcontentType属性を追加し、値を”mixed”に設定するものとする。
【０１１９】
図４０は旅行代理店１０９からレンタカー会社１０２へ送信される文書にこの追加処理を実行した結果得られる文書を示す図である。図１１の文書と比較して、文字列内容を持つ文書要素（たとえば４行目のadult要素）のcontentType属性として、内容の文字データのデータ型が追加されている。さらに、図４１は旅行代理店１０９からレンタカー会社１０２へ送信される文書に対応する文書スキーマである。この追加処理を実行した結果得られる文書が図４２に示すものであるとする。図４２の文書は図４０の文書と比較して、passengers要素直下に文字データ”子供は３歳児です。”が追加されている。また、混合内容モデルを持つpassengers要素の属性としてcontentType属性が追加され、値が”mixed”に設定されている。
【０１２０】
図４３は本実施例のサブルーチンCANONICALIZEの処理の流れを示す図である。ステップＳ１１２１で、ツリーＴを空、ポインタＰを文書先頭文字にする。ステップＳ１１２２で、ポインタＰが入力文書の末尾に到達していない場合、ステップＳ１１２３で、ポインタＰを移動してノードが一つ生成される。ステップＳ１１２４で、生成ノードは条件＃１：“文字ノード、文書要素ノード、文書要素属性ノード、テキストノードのいずれかである”を満たす場合、ステップＳ１１２５に進み、満たさない場合、ステップＳ１１２６に進む。ステップＳ１１２５で、生成ノードがツリーＴに追加される。ステップＳ１１２６で、条件＃２：“自ノードの直下に名前が“contentModel”である属性ノードが存在し、かつ、その属性ノードの直下に値が“string”であるテキストノードが存在する”を満たす場合、ステップＳ１１２７に進み、満たさない場合、ステップＳ１１２８に進む。
【０１２１】
ステップＳ１１２７で、そのノード直下にあるテキストノードと名前が“contentModel”である属性ノードを頂点とする部分木が削除される。ステップＳ１１２８で、条件＃３：“自ノードの直下に名前が“contentModel”である属性ノードが存在し、かつ、その属性ノードの直下に値が“mixed”であるテキストノードが存在する”を満たす場合、ステップＳ１１２９に進み、満たさない場合、ステップＳ１１２２に戻る。ステップＳ１１２９で、そのノード直下にあるテキストノードと、名前が“contentModel”である属性ノードを頂点とする部分木が削除され、ステップＳ１１２２に戻る。ステップＳ１１２２で、ポインタＰが入力文書の末尾に到達した場合、ステップＳ１１２１０で、ツリーＴが出力される。
【０１２２】
図４０の文書と図４２の文書をそれぞれサブルーチンCANONICALIZEに入力したときに得られるDOMツリーはいずれも図４４の通りとなる。図４４では、妥当性検証処理結果に影響しないノード（ノード番号２４、３３、３８など）を除外したため、図２９では１６０あったノードが１４８に減少している。また、図４０の文書に対して図４２の文書で追加された文字データ”子供は３歳児です。”に対応するノードも除外されている。この結果、後処理であるダイジェスト値算出処理の効率化を実現できる。
【０１２３】
なお、本実施例では、文書をDOMツリーに変換してから、検証処理結果に影響しない部分に対応するノードを削除した。しかし、これ以外にも、テキスト形式の文書から検証処理結果に影響しない部分を除外するよう構成することも可能である。
【実施例６】
【０１２４】
次に実施例６について説明する。実施例６の文書検証サービスは、実施例５の文書検証サービスと同様、妥当性検証処理結果に影響しない部分を文書から削除した結果に対してダイジェスト値算出処理を実行することを特徴とする。本実施例でも図２４を用いて説明する。
【０１２５】
文書スキーマがW3C XML Schemaの仕様に基づく場合、文書スキーマ中にany要素（processContents属性の値が”skip”または”lax”であるもの）以外に文書要素の定義を含まない内容モデルに対応する文書要素を文書から除外しても、妥当性検証処理結果には影響しない。また、文書スキーマ中にanyAttribute要素（processContents属性の値が”skip” または”lax”であるもの）以外に文書要素属性の定義を含まない内容モデルに対応する文書要素属性を文書から除外しても、妥当性検証結果には影響しない。このため、本実施例では、検証処理制御部１１５は、電子文書としてXML文書を、文書スキーマとしてW3C XML Schemaが入力された場合、検証結果に影響しない部分として、W3C XML Schemaで定義されたany要素に対応する位置に出現する文書要素、およびanyAttribute要素に対応する位置に出現する文書要素属性をXML文書から除外する。これらの部分を除外してからダイジェスト値や文字数・サンプル文字列を算出することで、ダイジェスト値算出処理の効率を改善できる。
【０１２６】
本実施例の文書検証部１１４は、妥当性検証処理実行中に、文書スキーマのany要素（processContents属性の値が”skip” または”lax”であるもの）以外に文書要素の定義を含まない内容モデルに対応する文書要素を処理した後に、その文書要素に属性contentModel、属性値anyを追加するものとする。また、文書スキーマのanyAttribute要素（processContents属性の値が”skip”であるもの）以外に文書要素属性の定義を含まない内容モデルに対応する文書要素属性を処理した後に、その文書要素属性が属する文書要素の属性として属性contentModel、属性値anyAttributeを追加するものとする。
【０１２７】
図４６は本実施例の文書スキーマを示す図である。図６の文書スキーマと比較して、passengers要素の内容モデル（４７行目）がany要素で表現されている点が異なる。図４７は旅行代理店１０９からレンタカー会社１０２へ送信される文書にこの追加処理を実行した結果得られる文書を示す図である。図１１の文書と比較して、passengers要素（３行目から６行目）の内容に含まれるadult要素とchildren要素にcontentModel属性が追加されている。
【０１２８】
図４５は本実施例のサブルーチンCANONICALIZEの処理の流れを示す図である。ステップＳ１２６１で、ツリーＴを空、ポインタＰを文書先頭文字にする。ステップＳ１２６２で、ポインタＰが入力文書の末尾に到着した場合、ステップＳ１２６１０に進み、ステップＳ１２６１０でツリーＴが出力され、到着していない場合は、ステップＳ１２６３に進む。ステップＳ１２６３で、ポインタＰを移動してノードが１つ生成される。ステップＳ１２６４で、生成ノードが条件＃１：“文書ノード、文書要素ノード、文書要素属性ノード、テキストノードのいずれかである”を満たさない場合、ステップＳ１２６６に進み、生成ノードが条件＃１を満たす場合、ステップＳ１２６５で、生成ノードがツリーＴに追加される。
【０１２９】
ステップＳ１２６６で、条件＃２：“自ノードの直下に名前が“contentModel”である属性ノードが存在し、かつ、その属性ノードの直下に値が“any”であるテキストノードが存在する“を満たすノードが存在しない場合、ステップＳ１２６８に進み、存在する場合、ステップＳ１２６７で、そのノード直下の文書要素ノードと、名前が“contentModel”の属性ノードと、その子ノードで名前が“any”のテキストノードを削除する。ステップＳ１２６８で、条件＃３：“自ノードの直下に名前が“contentModel”である属性ノードが存在し、かつ、その属性ノードの直下に値が“anyAttribute”であるテキストノードが存在する”を満たすノードが存在しない場合、ステップS１２６２に戻り、条件＃３を満たすノードが存在する場合、ステップＳ１２６９で、そのノード直下の文書要素属性ノード直下のテキストノードの内容を空にする。また、そのノード直下で名前が“contentModel”の属性ノードと、その子ノードで名前が“anyAttribute”のテキストノードを削除する。
【０１３０】
図４８は図４６の文書スキーマを利用し、図４７の文書をサブルーチンCANONICALIZEに入力したときに得られるDOMツリーを示す図である。妥当性検証処理結果に影響しないノード（ノード番号１０、１１、１２、１３）を除外したため、図２９では１６０あったノードが１５６に減少している。この結果、後処理であるダイジェスト値算出処理の効率化を実現できる。
【０１３１】
なお、本実施例では、文書をDOMツリーに変換してから、検証処理結果に影響しない部分に対応するノードを削除した。しかし、これ以外にも、テキスト形式の文書から検証処理結果に影響しない部分を除外するよう構成することも可能である。
【実施例７】
【０１３２】
次に実施例７について説明する。実施例７の文書検証サービスは、実施例５および実施例６の文書検証サービスと同様、妥当性検証処理結果に影響しない部分を文書から削除した結果に対してダイジェスト値算出処理を実行することを特徴とするが、XML DTDの仕様に基づく文書スキーマを対象とする。本実施例においても図２４を用いて説明する。
【０１３３】
文書スキーマがXML DTDの仕様に基づく場合、文書中の処理命令や文字データのみからなる内容を文書から除外しても、妥当性検証結果には影響しない。検証処理制御部１１５は、電子文書としてXML文書、文書スキーマとしてXML DTDが入力された場合、検証結果に影響しない部分として、文書要素の内容であって他の文書要素を含まないものをXML文書から除外する。これらの部分を除外してからダイジェスト値や文字数・サンプル文字列を算出することで、ダイジェスト値算出処理の効率を改善できる。
【０１３４】
図４９は図６のW3C XML Schemaに基づく文書スキーマとほぼ同等の、XML DTDに基づく文書スキーマを示す図である。図５０は、図１１の文書と同等の文書で、図６の文書スキーマではなく図４９の文書スキーマを参照する文書を示す図である。なお、図５０の文書スキーマ（XML DTD）参照の表記法は、XML標準仕様で定められている表記法とは異なり、W3C XML Schema標準で定められている文書スキーマを参照する場合の表記法を用いている。図５１は、XML標準仕様に基づく表記法を採用した文書の例を示す図である。
【０１３５】
XML標準仕様に基づく表記法を採用しない理由は以下の通りである。もし図５１の表記法を採用すると、文書がSOAPボディの内容として保持され、送受信用文書の一部として処理されるとき、XML宣言の直後にしか出現が許されていないDOCTYPE宣言が送受信用文書の途中に出現することになり、エラーとなる。この問題を解決できる表記法が制定された場合には、図５０の表記法はその表記法に置き換えることが望ましい。
【０１３６】
図５２は本実施例のダイジェスト値算出部２１１が実行するサブルーチンCANONICALIZEの処理の流れを示す図である。ステップＳ１１３１で、ダイジェスト値算出部２１１は、ツリーＴを空、ポインタＰを文書先頭文字にする。ステップＳ１１３２で、ポインタＰが入力文書の末尾に到達していない場合、ステップＳ１１３３で、ポインタＰが移動されノードが一つ生成される。ステップＳ１１３２でポインタＰが入力文書の末尾に到達している場合、ステップＳ１１３６に進む。ステップＳ１１３４で、生成ノードが条件１：文書ノード、文書要素ノード、文書要素属性ノード、文書属性ノードを親ノードとするテキストノードのいずれかであるかを満たす場合、ステップＳ１１３５に進み、満たさない場合、ステップＳ１１３２に戻る。ステップＳ１１３５で、生成ノードがツリーＴに追加され、ステップＳ１１３２に戻る。ステップＳ１１３２で、ポインタＰが入力文書の末尾に到達した場合、ステップＳ１１３６で、ツリーＴが出力される。
【０１３７】
図５３は図５０の文書がサブルーチンCANONICALIZEに入力されたときに得られるＤＯＭツリーを示す図である。妥当性検証処理結果に影響しないノード（ノード番号１１、１３、２４、３１、３６、３８、４０）を除外したため、図２９では１６０あったノードが１５３に減少している。この結果、後処理であるダイジェスト値算出処理の効率化を実現できる。
【０１３８】
なお、実施例５で示した、混合内容モデルを持つ文書要素の文字データ内容を除外する処理は、文書スキーマがW3C XML Schemaである場合だけでなくDTDである場合にも容易に実現可能である。また、本実施例では、文書をDOMツリーに変換してから、検証処理結果に影響しない部分に対応するノードを削除した。しかし、これ以外にも、テキスト形式の文書から検証処理結果に影響しない部分を除外するよう構成することも可能である。
【実施例８】
【０１３９】
次に実施例８について説明する。実施例８の文書検証サービスは、XML DTDまたはW３C XML Schemaの仕様に基づく文書スキーマを対象とし、妥当性検証処理結果に影響しない部分を文書から削除した結果に対してダイジェスト値算出処理を実行することを特徴とする。本実施例においても図２４を用いて説明する。
【０１４０】
検証処理制御部１１５は、検証結果に影響しない部分を電子文書から除外した後、該除外した電子文書に対して検証結果に影響する変更が加えられたか否か判定する。文書スキーマがXML DTDの仕様に基づく場合、ANYキーワードで定義されている内容モデルに対応する内容の直下に位置する文字データを除外しても、妥当性検証結果には影響しない。同様に、文書スキーマがW3C XML Schemaの仕様に基づく場合、any要素に対応する文書要素および文字データを除外しても、妥当性検証結果には影響しない。
【０１４１】
このため、検証処理制御部１１５は、電子文書としてXML文書が入力された場合、検証結果に影響しない部分として、XML DTDの要素型定義でANYキーワードを含むものに対応付けられる文書要素直下の文字データ内容、および、W3C XML Schemaでany要素に対応する文書要素および文字データを、XML文書から除外する。これらの部分を除外してからダイジェスト値や文字数・サンプル文字列を算出することで、ダイジェスト値算出処理の効率を改善できる。
【０１４２】
文書検証部１１４は、妥当性検証処理実行中に、文書スキーマのANYキーワードで定義される内容モデルに対応する文書要素を処理した後に、その文書要素に属性contentModel、属性値anyを追加するものとする。なお、以下の説明では、文書スキーマとしてXML DTDを想定している。しかし、W3C XML Schemaに対しても、any要素に対応する文書要素を処理した後に、その文書要素に属性contentModel、属性値anyを追加するように構成することで、同等の効果を得ることができる。
【０１４３】
図５４は図４６のW3C XML Schemaに基づく文書スキーマとほぼ同等の、XML DTDに基づく文書スキーマを示す図である。図５５は、図４２の文書と同等の文書で、図６の文書スキーマではなく図５４の文書スキーマを参照する文書を示す図である。なお、図５５での文書スキーマ（XML DTD）参照の表記法は、図５０と同様、XML標準仕様で定められている表記法とは異なる。
【０１４４】
図５６は本実施例のダイジェスト値算出部２１１が実行するサブルーチンCANONICALIZEの処理の流れを示す図である。ステップＳ１２７１で、ダイジェスト値算出部２１１は、ツリーＴを空、ポイントＰを文書先頭文字にする。ステップＳ１２７２で、ポインタＰが入力文書の末尾に到達していない場合、ステップＳ１２７３で、ポインタＰが移動されノードが一つ生成される。ステップＳ１２７４で、生成されたノードが条件＃１：“文書ノード、文書要素ノード、文書要素属性ノード、テキストノードのいずれかである”を満たす場合、ステップＳ１２７５で、生成ノードがツリーＴに追加され、満たさない場合、ステップＳ１２７６に進む。
【０１４５】
ステップＳ１２７６で、条件＃２：“自ノードの直下に名前が“contentModel”である属性ノードが存在し、かつ、その属性ノードの直下に値が“any”であるテキストノードが存在する”を満たさない場合、ステップＳ１２７２に戻り、条件＃２を満たす場合、ステップＳ１２７７で、そのノード直下のすべてのノードと、名前が“contentModel”の属性ノードと、その子ノードで名前が“any”のテキストノードが削除され、ステップＳ１２７２に戻る。ステップＳ１２７２で、ポインタＰが入力文書の末尾に到達した場合、ステップＳ１２７８で、ツリーＴが出力される。
【０１４６】
図５５の文書がサブルーチンCANONICALIZEに入力されたときに得られるDOMツリーは、図５５の文書の６行目に追加された文字データ”子供は３歳児です。”に対応するノードが除外される結果、図２９に示したものと同一となる。この結果、後処理であるダイジェスト値算出処理の効率化を実現できる。
【０１４７】
なお、本実施例では、文書をDOMツリーに変換してから、検証処理結果に影響しない部分に対応するノードを削除した。しかし、これ以外にも、テキスト形式の文書から検証処理結果に影響しない部分を除外するよう構成することも可能である。
【実施例９】
【０１４８】
次に実施例９について説明する。実施例９の文書検証サービスは、サブルーチンEVALUATEの入力が文書全体ではなく一部分であることを特徴とする。本実施例でも図２４を用いて説明する。検証処理制御部１１５は、電子文書を二つ以上の部分に分割する。このとき、検証処理制御部１１５は、たとえば電子文書を文字データ内容とそれ以外に分割する。また、検証処理制御部１１５は、電子文書が構成要素を節とする木で表現される構造化文書である場合、構造化文書を文書要素属性とそれ以外に分割する。文書検証部１１４は、分割された電子文書のそれぞれが所定の条件を満たしているか否か検証する。これにより、文書が変更された場合でも、妥当性検証処理を実行すべき対象を文書全体より少なくすることができ、処理効率を改善できる。
【０１４９】
図５７は実施例９の検証処理制御部１１５の処理の流れの一例を示す図である。ステップＳ１１４１で、検証処理制御部１１５は、変数Ｘに送受信用文書保持部中のSOAP文書のSOAPボディの内容を代入する。ステップＳ１１４２で、変数Ｘの内容が文書要素間の関係と個々の文書要素に分割され、それぞれが配列Ｙに代入される。つまり、ステップＳ１１４２では、文書が文書要素間の関係と個々の文書要素の文書要素属性およびテキスト内容に分割される。ステップＳ１１４３で、変数Ｚを配列Ｙの要素数、変数Ｗを０とする。
【０１５０】
ステップＳ１１４４で、変数Ｚの値が変数Ｙの値より大きくない場合、ステップＳ１１４５で、配列Ｙの“変数Ｚ”番目の要素に対応する文書スキーマフラグメントが生成される。ステップＳ１１４６で、配列Ｙの“変数Ｚ”番目の要素を引数にしてサブルーチンEVALUATEが実行される。ステップＳ１１４７で、サブルーチンEVALUATEの出力が配列Ｙの“変数Ｚ”番目の要素に対応付けられる。ステップＳ１１４８で、変数Ｚをインクリメントし、ステップＳ１１４４に戻り、変数Ｚの値が変数Ｙの値より大きい場合、ステップＳ１１４９で、送受信用文書が返信される。
【０１５１】
図５８は検証処理制御部１１５の処理の流れのもう一つの例を示す図である。ステップＳ１３０１で、検証処理制御部１１５は、変数ＸにSOAPボディの内容を代入する。ステップＳ１３０２で、変数Ｘの値から属性値・文字データを削除したものが配列Ｙに追加され、変数Ｘ中の文書要素のうち属性または文字データ内容を持つものが配列Ｙに追加される。つまり、ステップＳ１３０２では、文書から属性値と文字データ（外部の文書スキーマで定義されている文書要素の内容と属性は除く）を削除したものと、文書を構成する各文書要素のうち属性または文字データ内容を持つものを処理対象とする。
【０１５２】
ステップＳ１３０３で、変数Ｚを配列Ｙの要素数、変数Ｗを０とする。ステップＳ１３０４で、変数Ｚの値が変数Ｙの値より大きくない場合、ステップＳ１３０５で、配列Ｙの変数Ｚ番目の要素に対応する文書スキーマフラグメントが生成される。またステップＳ１３０５では、文書全体に対する文書スキーマとして、入力の文書スキーマの文字データに対するデータ型をすべて文字列型に変換したものを生成する。ステップＳ１３０６で、配列Ｙの変数Ｚ番目の要素を引数にしてサブルーチンEVALUATEが実行される。ステップＳ１３０７で、サブルーチンEVALUATEの出力が配列Ｙの変数Ｚ番目の要素に対応付けられる。テップＳ１３０８で、変数Ｚをインクリメントし、ステップＳ１３０４に戻る。ステップ１３０４で、変数Ｚの値が変数Ｙの値より大きい場合、ステップＳ１３０９で、送受信用文書が返信される。
【０１５３】
図５７の処理では、文書を文書要素間の関係と個々の文書要素に分割し、それぞれに対応する文書スキーマを生成した。また、図５８の処理では、文字データの型チェックを行わない文書スキーマと、個々の文書要素に対して文字データの型チェックを行う文書スキーマを生成し、それぞれに対応する文書フラグメントを生成した。これらは、文書の変更が特定文書要素を対象とした局所的なものになることが多いという仮定に基づいている。なお、これら以外にも、たとえば文書要素間の関係と、文字データを除く個々の文書要素と、個々の文字データに分割することも可能である。また、特定の文書要素を頂点とする部分木と、それ以外とに分割することも可能である。
【０１５４】
図５９から図６９は、本実施例の文書検証サービスに図１８の文書が入力され、検証処理制御部１１５で図５７の処理が実行されたとき、ステップＳ１１４２で生成される処理対象の一部（文書要素間の関係、および、図１８の１行目から１５行目に出現する文書要素）を示す図である。図７０は、図１８の４３行目のplace要素に対応する文書を示す図である。図７１から図８１は、図５９から図７０の文書に対応する文書スキーマフラグメントを示す図である。図８２は、図７０の文書に対応する文書スキーマフラグメントを示す図である。
【０１５５】
図８４、図６０、図６２、図６３は、本実施例の文書検証サービス２１０に図１８の文書が入力され、検証処理制御部１１５で図８３の処理が実行されたとき、ステップＳ１３０２で生成される処理対象の一部（文書から属性値を含む文字データを削除したもの、および図１８の１行目から６行目に出現する文書要素）をそれぞれ示す図である。また、図８５、図７２、図７４、図７５は、これらに対応する文書スキーマフラグメントを示す図である。
【０１５６】
なお、文書スキーマを入手した時点で図７１から図８２および図８６に示した文書スキーマフラグメントを含むすべての文書スキーマフラグメントを事前に作成しておくことも可能である。これにより、同一の文書スキーマに対応付けられた文書を数多く処理する場合の処理効率を改善できる。
【０１５７】
以下、本実施例では、検証処理制御部１１５で図５７の処理が実行されていると仮定する。図８３の処理が実行される場合でも、以下の説明で示す処理結果と同様の処理結果を得ることができる。
【０１５８】
図８６は翻訳サービスから返信される、図１８の文書を含む送受信用文書の一部を示す図である。図８６の４行目から１５行目までは、図５９から図６９に対応する文書部分を指定する記述と、その文書部分が直近に妥当性検証処理されたときの処理結果の真偽値およびそのときの文書部分から得られたダイジェスト値を保持するdigest要素が保持されている。なお、説明を簡略化するため、他の文書部分に対応するdigest要素の記載を省略した。
【０１５９】
たとえば、４行目のdigest要素のstructure属性、text属性、attribute属性は、このdigest要素に対応する文書部分が文書要素間の関係のみを含み、テキスト内容や文書要素属性を含まないことを意味する。また、path属性の値は、このdigest要素に対応する文書部分の頂点に位置する文書要素を特定するためのXPathロケーションパスを示す。なお、validity属性とdigest要素の内容の意味はすでに説明した通りである。
【０１６０】
図８７は図８６の送受信用文書が文書検証サービスに入力されたとき、図５９から図７０で示した文書部分ごとに算出されるダイジェスト値（新ダイジェスト値）と、図８６で示したダイジェスト値（旧ダイジェスト値）の一覧を示す図である。図８７に示したとおり、ロケーションパスが"/itinerary/stay[1]/place"である文書部分（図１８の４３行目のplace要素）のみ新旧のダイジェスト値が異なるので、この文書部分のみを対象にしてサブルーチンVALIDATEが実行され、ダイジェスト値が更新される。
【０１６１】
なお、本実施例の文書検証サービス２１０は、入力された文書をテキスト形式のまま分割してからサブルーチンEVALUATEを呼び出した。この方法以外にも、入力された文書をDOMツリーに変換してから分割するように構成することも可能である。
【０１６２】
このように、処理対象の文書を複数の部分に分割し、それぞれについて検証処理結果に影響を及ぼす変更がなされたか否かを判定することにより、文書が変更された場合でも、妥当性検証処理を実行すべき対象を文書全体より少なくすることができ、処理効率を改善できる。
【実施例１０】
【０１６３】
次に実施例１０について説明する。実施例１０の文書検証サービス２１０は、実施例６と同様、サブルーチンEVALUATEの入力が文書全体ではなく一部分である。それに加えて、実施例１０の文書検証サービスは、妥当性検証処理を依頼したサービスから、そのサービスが変更した文書部分に関する情報を受信し、その情報を利用して文書を分割することを特徴とする。本実施例において図２４を用いて説明する。検証処理制御部１１５は、電子文書に対して検証結果に影響する変更が加えられたと判定された場合に、変更が加えられた部分とそれ以外とに電子文書を分割する。このとき、検証処理制御部１１５は、電子文書が構造化文書である場合、構造化文書を部分木とそれ以外に分割する。文書検証部１１４は、変更が加えられた部分が所定の条件を満たしているか否か検証する。これにより、文書が変更された場合でも、妥当性検証処理を実行すべき対象を文書全体より少なくすることができ、処理効率を改善できる。
【０１６４】
以下具体的に説明する。旅行代理店１０９から航空会社１０５に図８の文書が送信され、航空会社１０５から本実施例の文書検証サービス２１０に図８の文書を含む送受信用文書が送信され、妥当性検証処理が依頼された局面を考える。図８８は、このとき送信される送受信用文書を示す図である。
【０１６５】
図８８の４行目には、文書全体が直近に妥当性検証処理の対象になったときの検証結果とダイジェスト値を保持するdigest要素が保持されている。それに加え、５行目と６行目には、この送受信用文書の受信者である航空会社１０５によって変更が加えられる可能性のある部分を示すmodification要素が、この送受信用文書を発信した旅行代理店１０９によって追加されている。modification要素のpath属性の値は、変更が加えられる可能性のある部分構造の頂点に位置する文書要素を指示するXPathロケーションパスである。
【０１６６】
subtree属性は、変更が加えられる可能性のある部分構造が、path属性で指定された文書要素を頂点とする部分木か、文書要素を頂点とする部分木を除いたもののいずれかを指定する。属性値が"true"の場合は前者、"false"の場合は後者である。５行目と６行目のmodification要素は、itineraryInProcess要素直下で２番目に出現するtravel要素を頂点とする部分木と、５番目に出現するtravel要素を頂点とする部分木が変更される可能性があることを示している。
【０１６７】
図８３は検証処理制御部１１５の処理の流れを示す図である。図８３の処理は、ステップＳ１１５２の内容を除いて図５７の処理と同一である。図５７の処理では、文書の分割結果はあらかじめ決められていた。一方、図８３の処理では、文書の分割結果は、送受信用文書のＳＯＡＰヘッダ部分に記述されているmodification要素およびdigest要素の内容に基づいて決められる。
【０１６８】
ステップＳ１１５１で、検証処理制御部１１５は、変数ＸにSOAPボディの内容を代入する。ステップＳ１１５２で、modification要素およびdigest要素の内容に基づき変数Ｘの内容が２つ以上の部分構造に分割され、それぞれが配列Ｙに代入される。ステップＳ１１５３で、変数Ｚを配列Ｙの要素数、変数Ｗを０とする。ステップＳ１１５４で、変数Ｚの値が変数Ｙの値より大きくない場合、ステップＳ１１５５で、配列Ｙの変数Ｚ番目の要素に対応する文書スキーマフラグメントが生成される。ステップＳ１１５６で、配列Ｙの変数Ｚ番目の要素を引数にしてサブルーチンEVALUATEが実行される。ステップＳ１１５７で、サブルーチンEVALUATEの出力が配列Ｙの変数Ｚ番目の要素に対応付けられる。ステップＳ１１５８で、変数Ｚをインクリメントし、ステップＳ１１５４に戻る。ステップＳ１１５４で、変数Ｚの値が変数Ｙの値より大きい場合、ステップＳ１１５９で、送受信用文書が返信される。
【０１６９】
図８９は、文書検証サービス２１０から航空会社１０５に返信される送受信用文書を示す図である。図８８のmodification要素の内容を反映して、図８９ではitineraryInProcess要素直下で２番目に出現するtravel要素を頂点とする部分木、５番目に出現するtravel要素を頂点とする部分木、これらの部分木を文書から除いて得られる文書に対する妥当性検証結果とダイジェスト値がそれぞれ５行目、６行目、４行目のdigest要素として保持されている。
【０１７０】
次に旅行代理店１０９によって図８９の送受信用文書中の文書本体が図８から図９に更新され、旅行代理店１０９に返信された局面を考える。図９０は、このとき旅行代理店１０９から文書検証サービス１１０に送信される送受信文書を示す図である。また、図９１は、妥当性検証結果とダイジェスト値が保持されている３つの部分構造ごとに、digest要素に保持されているダイジェスト値（旧ダイジェスト値）と、文書検証サービス１１０によって算出されるダイジェスト値（新ダイジェスト値）の一覧を示す図である。
【０１７１】
図９１から、itineraryInProcess要素直下で２番目に出現するtravel要素を頂点とする部分木のみが変更されたことがわかるので、この部分木のみに対してサブルーチンVALIDATEが実行され、ダイジェスト値と検証結果が更新される。なお、W３C XML Schemaに基づく文書スキーマを利用すれば、文書に対応する文書スキーマをそのまま利用して、文書の任意の部分木のみを対象にした検証処理を実行できる。このため、サブルーチンVALIDATE実行時には図６の文書スキーマをそのまま利用できる。
【０１７２】
なお、本実施例の文書検証サービスは、図８８のmodification要素によって変更の可能性が無いと指定された部分（文書から、itineraryInProcess要素直下で２番目に出現するtravel要素を頂点とする部分木と、５番目に出現するtravel要素を頂点とする部分木を除いたもの)についてもダイジェスト値の算出と比較を実行しているが、これらの処理をスキップするように構成することも可能である。
【０１７３】
本実施例の文書検証サービス２１０は、入力された文書をテキスト形式のまま分割してからサブルーチンEVALUATEを呼び出すように構成することも可能である。また、この方法以外にも、入力された文書をDOMツリーに変換してから分割するように構成することも可能である。
【０１７４】
このように、サービスからの情報に基づいて処理対象の文書を複数の部分に分割し、それぞれについて検証処理結果に影響を及ぼす変更がなされたか否かを判定することにより、文書が変更された場合でも、妥当性検証処理を実行すべき対象を文書全体より少なくすることができ、処理効率を改善できる。
【実施例１１】
【０１７５】
次に実施例１１について説明する。実施例１１は文書スキーマの変更による再検証をする場合の例である。実施例１１の文書検証サービスは、文書だけでなく文書スキーマの変更を検知して、妥当性検証を実行することを特徴とする。図９２は、本実施例のシステム３００の構成図を示す図である。図９２に示すように、システム３００は、航空会社１０５、航空会社１０６、旅行代理店１０９および文書検証サービス３１０を備える。これらは、インターネットなどのネットワーク１２０にそれぞれ接続されている。文書検証サービス３１０は、送受信用文書保持部１１１、文書正規化部１１３、文書検証部１１４、検証処理制御部１１５、ダイジェスト値算出部２１１および文書スキーマ保持部３１１を備える。図２４で示した構成要素に加え、文書スキーマ保持部３１１が追加されている。文書スキーマ保持部３１１は、文書スキーマを保持する。
【０１７６】
検証処理制御部１１５は、構造化文書が直近に検証された時点で所定の文書スキーマに所定の演算を実行して得られた情報（文書スキーマの旧ダイジェスト値）と、所定の文書スキーマに所定の演算を実行して得られた情報（文書スキーマの新ダイジェスト値）が異なる場合に、所定の文書スキーマに対して検証結果に影響する変更が加えられたと判定する。このように、本実施例の文書検証サービス３１０では、文書だけでなく文書スキーマの変更を検知して妥当性検証を実行できる。
【０１７７】
図９３は検証処理制御部１１５のサブルーチンEVALUATEの処理の流れ図である。図９３では、文書と文書スキーマの旧ダイジェスト値と新ダイジェスト値がともに一致するときのみ旧ダイジェスト値の組と直近の妥当性検証結果が出力され、それ以外のときはサブルーチンVALIDATEが呼び出される。ただし、文書スキーマに対しては、サブルーチンCANONICALIZEが呼び出される前に、ステップＳ１１７５で、検証処理制御部１１５は、文書スキーマから検証結果に影響しない部分として注釈（annotation）要素を頂点とする部分木を削除（除外）する。
【０１７８】
ステップＳ１１７１で、入力文書に対してサブルーチンCANONICALIZEが実行される。ステップＳ１１７２で、出力に対してサブルーチンGET_DIGESTが実行される。ステップＳ１１７３で、文書の旧ダイジェスト値が付与されていない場合、ステップＳ１１７１１に進み、付与されている場合、ステップＳ１１７４に進む。ステップＳ１１７４で、文書の新ダイジェスト値と文書の旧ダイジェスト値が同一でない場合、ステップＳ１１７１１に進み、文書の新ダイジェスト値と文書の旧ダイジェスト値が同一の場合、ステップＳ１１７５に進む。ステップＳ１１７５で、文書スキーマから、注釈（annotation）要素を頂点とする部分木が削除される。
【０１７９】
ステップＳ１１７６で、文書スキーマに対してサブルーチンCANONICALIZEが実行される。ステップＳ１１７７で、出力に対してサブルーチンGET_DIGESTが実行される。ステップＳ１１７８で、文書に文書スキーマの旧ダイジェスト値が付与されている場合、ステップＳ１１７９に進み、付与されていない場合はステップＳ１１７１１に進む。ステップＳ１１７９で、文書スキーマの新ダイジェスト値と文書スキーマの旧ダイジェスト値が同一の場合、ステップＳ１１７１０で、旧文書ダイジェスト値、旧文書スキーマダイジェスト値、直近のサブルーチンVALIDATEの結果の組が出力される。ステップＳ１１７１１で、入力文書に対してサブルーチンVALIDATEが実行される。ステップＳ１１７１２で、新文書ダイジェスト値、新文書スキーマダイジェスト値、サブルーチンVALIDATEの結果の組が出力される。
【０１８０】
図９の文書が航空会社１０５から旅行代理店１０９に返信され、旅行代理店１０９から航空会社１０６に送信される前に図６の文書スキーマが更新されたと仮定する。図９４は、更新後の文書スキーマを示す図である。図６の文書スキーマでは、passengers要素直下にchildren要素は必ず出現しなければならなかったが、図９４の文書スキーマでは、children要素は出現しなくてもよいように変更された（１９行目参照）。これに伴い、annotation要素（４行目）の内容も変更されている。
【０１８１】
図９５は図９の文書が旅行代理店１０９に返信されるときの送受信用文書を示す図である。図９５のSOAPヘッダ部分には、文書のダイジェスト値と直近の検証結果（４行目）だけでなく、文書スキーマのダイジェスト値（５行目）を保持するdigest要素が追加されている。
【０１８２】
図９５の文書が旅行代理店１０９から航空会社１０６に送信され、航空会社１０６が文書検証サービス３１０に妥当性検証処理を依頼する。すると、図９３の処理の流れに基づいて、ステップＳ１１７４およびステップＳ１１７９で、文書と文書スキーマの新旧ダイジェスト値が比較される。その結果、文書の新旧ダイジェスト値は一致するが、ステップＳ１１７９で、文書スキーマの新旧ダイジェスト値が一致しないので、処理がステップＳ１１７９からステップＳ１１７１１に移動し、ステップＳ１１７１１で、サブルーチンVALIDATEが呼び出され、ステップＳ１１７１２で、新しいダイジェスト値とサブルーチンVALIDATEの処理結果が出力される。
【実施例１２】
【０１８３】
次に実施例１２について説明する。実施例１２は、文書スキーマの定義する言語の包含関係を判定する場合の例である。実施例１２の文書検証サービス３１０は、実施例１１の文書検証サービスと同様、文書スキーマの変更を検知して妥当性検証を実行するが、スキーマの変更が妥当性検証結果に影響を及ぼすか否か判定し、影響を及ぼすと判定された場合にのみ妥当性検証を実行することを特徴とする。
【０１８４】
本実施例の文書検証サービスの構成図は実施例１１の文書検証サービスと同様図９２であるが、本実施例の文書検証サービス３１０は、サブルーチンVALIDATEが実行されるごとに、同一識別子で特定される文書スキーマの最新版を文書スキーマ保持部３１１に保持しておくものとする。
【０１８５】
検証処理制御部１１５は、新文書スキーマの定義する言語（所定の文書スキーマが定義する第１の言語）が旧文書スキーマの定義する言語（構造化文書が直近に検証された時点での前記所定の文書スキーマが定義する第２の言語）を包含し、かつ、直近のサブルーチンVALIDATEの結果（検証結果）が"真"である場合には、文書スキーマに対して妥当性検証結果に影響する変更が加えられていないと判定する。検証処理制御部１１５は、旧文書スキーマの定義する言語が新文書スキーマの定義する言語を包含し、かつ、直近のサブルーチンVALIDATEの結果が”偽”である場合にも、文書スキーマに対して妥当性検証結果に影響する変更が加えられていないと判定する。
【０１８６】
図９６は検証処理制御部１１５の処理の流れ図である。ステップＳ１１８１で、検証処理制御部１１５は、入力文書に対してサブルーチンCANONIZALIZEを実行する。ステップＳ１１８２で、出力に対してサブルーチンGET_DIGESTが実行される。ステップＳ１１８３で、文書の旧ダイジェスト値が付与されていない場合、ステップＳ１１８１３に進み、付与されている場合、ステップＳ１１８４に進む。ステップＳ１１８４で、文書の新ダイジェスト値と文書の旧ダイジェスト値が同一でない場合、ステップＳ１１８１３に進み、文書の新ダイジェスト値と文書の旧ダイジェスト値とが同一の場合、ステップＳ１１８５に進む。ステップＳ１１８５で、文書スキーマから注釈（annotation）要素を頂点とする部分木が削除される。ステップＳ１１８６で、文書スキーマに対してサブルーチンCANONICALIZEが実行される。
【０１８７】
ステップＳ１１８７で、出力に対してサブルーチンGET_DIGESTが実行される。ステップＳ１１８８で、文書に文書スキーマの旧ダイジェスト値が付与されていない場合、ステップＳ１１８１３に進み、付与されている場合、ステップＳ１１８９に進む。ステップＳ１１８９で、文書スキーマの新ダイジェスト値と文書スキーマの旧ダイジェスト値が同一でない場合、ステップＳ１１８１１に進み、文書スキーマの新ダイジェスト値と文書スキーマの旧ダイジェスト値とが同一の場合、ステップＳ１１８１０で、旧文書ダイジェスト値、旧文書スキーマダイジェスト値、直近のサブルーチンVALIDATEの結果の組が出力される。ステップＳ１１８１１で、新文書スキーマの定義する言語が旧文書スキーマの定義する言語を包含し、かつ、直近のサブルーチンVALIDATEの結果が“真”でない場合、ステップＳ１１８１３に進み、“真”の場合、ステップＳ１１８１２で、旧文書ダイジェスト値、新文書スキーマダイジェスト値、直近のサブルーチンVALIDATEの結果の組が出力される。ステップＳ１１８１３で、入力文書に対してサブルーチンVALIDATEを実行する。ステップＳ１１８１４で、新文書ダイジェスト値、新文書スキーマダイジェスト値、VALIDATEの結果の組が出力される。
【０１８８】
実施例９の検証処理制御部１１５の処理（図９３）では、文書スキーマの新旧のダイジェスト値が同一でなければ無条件にサブルーチンVALIDATEが起動された。一方、実施例１２の検証処理制御部１１５では、両者が同一でなくても、新文書スキーマの定義する言語が旧文書スキーマの定義する言語を包含し、かつ、直近のサブルーチンVALIDATEの結果が"真"である場合には、文書スキーマの変更が妥当性検証結果に影響を及ぼさないと判断し、サブルーチンVALIDATEを起動せずに処理を終了する。
【０１８９】
なお、図９６の処理の流れでは示していないが、旧文書スキーマの定義する言語が新文書スキーマの定義する言語を包含し、かつ、直近のサブルーチンVALIDATEの結果が”偽”である場合にも、文書スキーマの変更が妥当性検証結果に影響を及ぼさないと判断し、サブルーチンVALIDATEを起動せずに処理を終了する処理を追加することも可能である。
【０１９０】
図９７は文書スキーマＡの定義する言語が文書スキーマＢの定義する言語を包含するか否か判定する処理の流れを示す図である。ステップＳ１１９１で、文書スキーマＡから生成規則の集合が生成され、集合Ａに代入される。ステップＳ１１９２で、文書スキーマＢから生成規則の集合が生成され、集合Ｂに代入される。ステップＳ１１９３で、集合Ｂのすべての生成規則について、左辺の記号を左辺に持つ生成規則が集合Ａに含まれてない場合、ステップＳ１１９１２で、“偽”が出力され、含まれていない場合、ステップＳ１１９４に進む。ステップＳ１１９４で、集合Ｂのすべての生成規則の左辺の記号がリストＣに代入され、リストＣの先頭要素が変数Ｄに代入される。ステップＳ１１９５で、変数Ｄの記号を左辺に持つ生成規則が集合Ａ、集合Ｂから特定され、それぞれ変数Ｅ、変数Ｆに代入される。
【０１９１】
ステップＳ１１９６で、変数Ｅ、変数Ｆの生成規則から決定性有限オートマトンが生成され、変数Ｇ、変数Ｈに代入される。ステップＳ１１９７で、変数Ｈの値、変数Ｇの値を引数にしてサブルーチンCOMPAREが実行される。ステップＳ１１９８で、サブルーチンCOMPAREの返り値は真でない場合、ステップＳ１１９２で、偽が出力され、真の場合、ステップＳ１１９９に進む。ステップＳ１１９９で、変数Ｄの値がリストＣの末尾要素でない場合、ステップＳ１１９１０で、リストＣの次要素が変数Ｄに代入され、ステップＳ１１９５に戻り、リストＣが末尾要素の場合、Ｓ１１９１０で、真が出力される。
【０１９２】
なお、図９７の処理は、同じ記号を左辺に持つ生成規則がただ一つ得られることを前提としている。DTDではこの前提は常に成り立つ。一方、W3C XML Schemaでは、ローカル要素・ローカル属性というメカニズムを用いて、文書要素の出現位置によって異なる内容モデルを定義できるため、同一記号を左辺に持つ生成規則が複数得られる可能性がある。本明細書のすべての実施例では、文書要素の出現位置によらず単一の内容モデルが定義された文書スキーマのみを対象とする。
【０１９３】
図９８はステップＳ１１９７のサブルーチンCOMPAREの処理の流れ図である。サブルーチンCOMPAREの処理は、第二引数の決定性有限オートマトンの定義する言語が第一引数の決定性有限オートマトンの定義する言語を包含するか判定する処理である。ステップＳ１２５１で、状態の組の集合Ｓを空、状態の組のリストＴを空にする。ステップＳ１２５２で、状態の組のリストＴの先頭要素をオートマンＡの初期状態、オートマンＢの初期状態とする。ステップＳ１２５３で、状態の組のリストＴが空の場合、ステップＳ１２５１７で真が出力され、状態の組のリストＴが空の場合、ステップＳ１２５４で、状態の組Ｕに、状態の組のリストＴの先頭要素が代入される。ステップＳ１２５５で、状態の組の集合Ｓの要素としてＵが追加される。ステップＳ１２５６で、状態Ｖを状態の組Ｕの第一要素、状態Ｗを状態の組Ｕの第二要素とする。ステップＳ１２５７で、状態Ｖが受理状態の場合、ステップＳ１２５８に進み、状態Ｖが受理状態でない場合、ステップＳ１２５９に進む。
【０１９４】
ステップＳ１２５８で、状態Ｗが受理状態の場合、ステップＳ１２５９に進み、状態Ｗが受理状態でない場合、ステップＳ１２５１８で偽が出力される。ステップＳ１２５９で、状態のリストＸを、状態Ｖを開始端とする状態遷移のリストとする。ステップＳ１２５１０で、状態の集合Ｙを、状態Ｗを開始端とする状態遷移の集合とする。ステップＳ１２５１１で、状態のリストＸが空の場合、ステップＳ１２５３に戻り、状態のリストＸが空でなければステップＳ１２５１２に進む。ステップＳ１２５１２で、状態のリストＸの先頭要素に対応する記号に対応する要素が、状態の集合Ｙに含まれない場合、ステップＳ１２５１９で、偽が出力され、状態の集合Ｙに含まれる場合、ステップＳ１２５１３で、状態の組Ｚを、状態のリストＸの先頭要素、状態のリストＸの先頭要素に対応する記号に対応するＹの要素とする。
【０１９５】
ステップＳ１２５１４で、Ｚの要素がＸ、Ｙから削除される。ステップＳ１２５１５で、状態の組Ｚが、状態の組の集合Ｓまたは状態の組のリストＴに含まれる場合、ステップＳ１２５１１に戻り、含まれない場合、ステップＳ１２５１６で、状態の組のリストＴの末尾要素として状態の組Ｚを追加し、ステップＳ１２５１１に戻る。
【０１９６】
図９９は図６の文書スキーマ中のpassengers要素に対応する記号を左辺に持つ生成規則が導出する言語を受理する決定性有限オートマトンを示す図である。図１００は図９４の文書スキーマ中のpassengers要素に対応する記号を左辺に持つ生成規則が導出する言語を受理する有限オートマトンを示す図である。図９９および図１００で、開始端に節を持たない辺の終端に位置する節は初期状態を表す。また、白抜き数字が書かれた節は受理状態を表す。また、破線で示された節はトラップ状態を表す。開始端の節を持つ辺は状態遷移を表し、辺の添え字は状態遷移に対応する記号である。
【０１９７】
図１００の決定性有限オートマトンの受理する記号列からなる言語は図９９の決定性有限オートマトンの受理する記号列からなる言語を包含する。図１００の決定性有限オートマトンは記号”adult”のみからなる記号列を受理するが、図９９の決定性有限オートマトンはこの記号列を受理しない。また、図９９の決定性有限オートマトンが受理するすべての記号列は図１００の決定性有限オートマトンが受理する。
【０１９８】
なお、これ以外の文書要素に対応する記号を左辺に持つ生成規則および有限オートマトンは図６と図９４とで同一のものが得られる。これらのオートマトンを引数にしてサブルーチンCOMPAREを起動すると、図１００の決定性有限オートマトンの受理する言語は図９９の決定性有限オートマトンの受理する言語を包含するため、サブルーチンCOMPAREは”真”を返す。このため、サブルーチンVALIDATEを実行せずに処理を終了でき、処理効率を改善できる。
【実施例１３】
【０１９９】
次に実施例１３について説明する。実施例１３は整形式を検証する際の実施例である。実施例１３の文書検証サービスは、実施例１から実施例１２の文書検証サービスと異なり、入力される文書が整形式のXML文書であるか否か判定するものである。図１０１は、本実施例のシステムの構成図である。図１０１に示すように、システム４００は、文書編集サービス４２０、文書ＤＢサービス４３０および文書検証サービス４１０を備える。これらはインターネットなどのネットワーク１２０に接続されている。文書検証サービス４１０は、送受信用文書保持部１１１、検証処理制御部１１５、ダイジェスト値算出部２１１および文書検証部１１４を備える。検証処理制御部１１５は、入力された電子文書が整形式のXML文書であるか否か検証するものである。
【０２００】
図１０１の文書編集サービス４２０は、利用者が編集している文書に適した文書編集プログラムを提供する。たとえば、編集対象の文書が非XML文書である場合はテキストエディタが起動し、XML文書である場合はXML文書エディタが起動する。利用者は、編集途中の文書を文書ＤＢサービス４３０に保存し、必要に応じて文書編集サービス４２０に再ロードし、作業を再開することができる。
【０２０１】
文書が文書編集サービス４２０に再ロードされるとき、文書編集サービス４２０は文書を文書検証サービス４１０に送信して、文書が整形式のXML文書か否かの判定を依頼する。文書検証サービス４１０は文書のダイジェスト値と判定結果を含む送受信用文書を文書編集サービス４２０に返信する。文書編集サービス４２０は、文書が整形式のXML文書であると判定された場合にはXML文書エディタを、そうでないと判定された場合はテキストエディタを起動する。
【０２０２】
本実施例の文書検証サービス４１０の検証処理制御部１１５の処理の流れは図２５で示したものと同一である。図１０２は、サブルーチンEVALUATEの処理の流れ図である。ステップＳ１２１１で、入力文書に対してサブルーチンGET_DIGESTが実行される。ステップＳ１２１２で、文書に旧ダイジェスト値が付与されている場合、ステップＳ１２１３に進み、付与されていない場合、ステップＳ１２１４に進む。ステップＳ１２１３で、新ダイジェスト値が、旧ダイジェスト値の場合、ステップＳ１２１６で、旧ダイジェスト値、直近のサブルーチンPARSEの結果の組が出力される。ステップＳ１２１４で、入力文書に対してサブルーチンPARSEが実行される。ステップＳ１２１５で、新ダイジェスト値、サブルーチンPARSEの結果の組が出力される。
【０２０３】
図１０３はステップＳ１２１１の処理の流れ図である。なお、図１０２の処理では、サブルーチンCANONICALIZEを起動しない。文書が整形式のXML文書か否かわからないので、正規化処理を実行できないためである。ステップＳ１２２１で、文書のダイジェスト値が算出される。ステップＳ１２２２で、ダイジェスト値をエンコードして出力する。
【０２０４】
図１０４は本実施例の文書検証サービスに入力される送受信用文書の例を示す図である。SOAPボディの内容に、編集途中の文書が保持されている。この文書はXML文書のように見えるが、１１行目のp要素の終了タグがないため、整形式のXML文書ではない。このため、４行目のdigest要素のwellformedness属性の値は"false"になっている。この値は、この文書がもっとも最近に整形式か否か判定されたとき、整形式ではないと判定されたことを示す。図１０４の送受信用文書が入力されたとき、以下のダイジェスト値が得られたとする。
4162bbb1d56dcf998518516f001fd72f
【０２０５】
この値は、４行目のdigest要素の内容と同一なので、文書検証サービス４１０は文書が変更されていないと判断し、digest要素の内容を変更せずに送受信用文書を文書編集サービス４２０に送信する。
【０２０６】
次に図１０４の送受信用文書中の文書がテキストエディタにより整形式のXML文書に編集され、文書ＤＢサービス４３０に保存された後、再び文書編集サービス４２０にロードされる局面を考える。図１０５は、文書編集サービス４２０から文書検証サービス４１０に送信される送受信用文書を示す図である。図１０５の送受信用文書が入力されたとき、以下のダイジェスト値が得られたとする。
001fd72f4162bbb1d56dcf998518516f
【０２０７】
この値は、４行目のdigest要素の内容と異なるので、文書検証サービス４１０は文書が変更されたと判断し、サブルーチンPARSEを実行する。その結果、文書が整形式のXML文書であると判定されるので、digest要素の内容を更新し、図１０６の送受信用文書を文書編集サービス４２０に送信する。文書編集サービス４２０はこの結果（digest要素のwelformedness属性の値）を参照し、この文書向けのエディタとしてテキストエディタでなくXML文書エディタを起動する。
【０２０８】
このように、本実施例の文書検証サービス４１０によって、文書が変更されていないときにはその文書が整形式のXML文書か否かの判定処理を実行しなくても、整形式のXML文書か否かを知ることができるので、処理効率を改善できる。
【実施例１４】
【０２０９】
次に実施例１４について説明する。実施例１４は、検証履歴を保持する場合の実施例である。図１０７は本実施例のシステム５００の構成図である。図１０７に示すように、システム５００は、レンタカー会社１０２、旅行代理店１０９および文書検証サービス５１０を備える。これらはインターネットなどのネットワーク１２０に接続されている。文書検証サービス５１０は、送受信用文書保持部１１１、文書正規化部１１３、文書検証部１１４、検証処理制御部１１５、ダイジェスト値算出部２１１および検証履歴保持部５１１を備える。
【０２１０】
これまでの実施例では、検証対象の文書がもっとも最近に検証されたときのダイジェスト値と検証結果は文書を送受信する送受信文書（SOAP文書）のヘッダ部分に保持されていた。本実施例の検証履歴保持部５１１は、過去の検証処理において一方向関数適用処理の結果得られた値（文書のダイジェスト値）と検証結果の組を保持する。検証処理制御部１１５は、検証対象の文書に一方向関数適用処理の結果得られた値が検証履歴保持部５１１が保持しているいずれかの値と同一である場合、その値に対応する検証結果を電子文書の検証結果とする。
【０２１１】
これにより、検証対象の文書とダイジェスト値・検証結果を組にしておく必要が無くなり、検証依頼者であるサービスから文書検証サービスへ検証対象文書だけを送信すればよい。このため、サービス間の通信に、これまでの実施例で用いたSOAPだけでなくREST（REpresentational State Transfer）プロトコルを利用できる。RESTプロトコルとは、インターネットで接続されたサービス間で文書をやり取りするためのプロトコルの一つである。
【０２１２】
図１０８は検証処理制御部１１５が実行するサブルーチンEVALUATEの処理の流れ図である。ステップＳ１２９１で、検証処理制御部１１５は、入力文書に対してサブルーチンCANONICALIZEを実行する。ステップＳ１２９２で、出力に対してサブルーチンGET_DIGESTが実行される。ステップＳ１２９３で、文書ダイジェスト値と同じ値を含む（文書ダイジェスト値、検証結果）の組が検証履歴保持部にある場合、ステップＳ１２９７で、特定した組の検証結果が出力され、文書ダイジェスト値と同じ値を含む（文書ダイジェスト値、検証結果）の組が検証履歴保持部にない場合、ステップＳ１２９４で、入力文書に対してサブルーチンVALIDATEが実行される。ステップＳ１２９５で、新ダイジェスト値、サブルーチンVALIDATEの結果の組が検証履歴保持部５１１に追加される。ステップＳ１２９６で、サブルーチンVALIDATEの結果が出力される。
【０２１３】
実施例１および実施例２と同様、図１１の旅程表ドラフトが旅行代理店１０９からレンタカー会社１０２に送信され、そのまま旅行代理店１０９に返信される局面を考える。このとき、文書検証サービス５１０の検証履歴保持部５１１には、検証結果とダイジェスト値の組として以下のものが保持されている。
"真", "3bebcec335f6e46bfe3563897ee544e0"
【０２１４】
文書検証サービス５１０は、旅行代理店１０９から図１１の旅程表ドラフトの検証処理を依頼されると、旅程表ドラフトのダイジェスト値を算出する。そして、その値と同じダイジェスト値を持つ組を検証履歴保持部５１１から特定しようと試み、上の組を特定する。そして、特定した組の検証結果である”真”を旅行代理店１０９に出力して処理を終了し、旅程表ドラフトに対する検証処理をスキップできるので、処理効率が向上する。
【０２１５】
実施例２の文書検証サービスを利用し、図１１１の文書と図１１２の文書スキーマを処理対象としたときの、（１）従来手法での検証処理時間(図２６でサブルーチンVALIDATEのみを実行)、（２）本発明の手法での未検証文書に対する処理時間(図２６でサブルーチンCANONICALIZE、サブルーチンGET_DIGEST、サブルーチンVALIDATEを実行)、(3)本発明の手法での検証済文書に対する処理時間(図２６でサブルーチンCANONICALIZE、サブルーチンGET_DIGESTを実行)、の計測結果例を図１０９に示す。なお、図１１１の文書と図１１２の文書スキーマは、W3C XML Schema 仕様書（Part 0: Primer）に記載されているものを用いている。図１０９に示すとおり、処理（２）の処理時間は、処理（１）の処理時間よりも大きいものの、処理（３）の処理時間は、処理（１）の処理時間よりも小さい。変更される回数が少なく利用される回数が多い文書に本発明の手法を適用すると、処理（２）の実行回数が少なく処理（３）の実行回数が多くなるので、処理時間の合計で比較すると従来技術よりも小さくなることが多い。
【０２１６】
図１０９の処理時間を仮定した場合に、同一の文書に対する処理回数と、本発明の手法の処理時間を１としたときの従来手法の処理時間との相関を図１１０に示す。図１１０に示すとおり、処理回数が小さいときは従来手法の処理時間が小さいが、処理回数が４のときに従来手法の処理時間がはじめて本発明の手法を上回り、さらに処理回数が大きくなるにつれて本発明の手法の処理時間が従来手法の処理時間と比較して小さくなる。つまり、処理対象の文書が変更されずに処理される回数が多いほど、本発明の手法による効果は大きくなる。このように、本発明の手法でサブルーチンVALIDATEにサブルーチンCANONICALIZEやサブルーチンGET_DIGESTを追加しても、処理回数が一定値(図１１０の例では４)を上回る場合は、従来手法のようにサブルーチンVALIDATEを繰り返すよりも処理時間が小さくなる。
【０２１７】
なお、本発明による文書検証方法は、入力された電子文書が所定の条件を満たしているか否か検証された後に、前記電子文書および前記条件の少なくとも一方に対して検証結果に影響する変更が加えられたか否かを判定する判定ステップと、前記電子文書および前記条件の少なくとも一方に対して変更が加えられたと判定された場合には、前記電子文書が所定の条件を満たしているか否かを検証して検証結果を出力し、前記変更が加えられていないと判定された場合には、直近に前記電子文書が前記条件を満たしているか否か検証されたときの結果を検証結果として出力する検証ステップとを含む。ＣＰＵがプログラムを実行することで、各ステップが実現される。なお、検証処理制御部１１５により判定手段が実現され、文書検証部および検証処理制御部１１５により出力手段が実現される。
【０２１８】
なお、本実施例のシステム５００の検証履歴保持部５１１は文書ダイジェスト値と検証結果の組のみを保持しているが、これらだけでなく、本発明の各実施例で用いられた送受信用文書のSOAPヘッダのdigest要素が保持する情報を保持するよう構成することも可能である。また、本発明の各実施例では、文書検証装置を独立したサービスとして実現したが、他の一つ以上のサービスに付随する機能として実現することも可能である。
【実施例１５】
【０２１９】
次に、本発明の実施例１５について説明する。図１１３は、本発明の実施例１５に係るシステムの構成を示す図である。図１１３に示すように、システム６００は、文書検証サービスシステム６０１およびサービスシステム６２１〜６２Ｎを備える。文書検証サービスシステム６０１は、パブリックネットワーク６３０を介して他のサービスシステム６２１〜６２Ｎとメッセージを送受信できるようになっており、他のサービスシステム６２１〜６２Ｎから構造化文書の検証を依頼するメッセージを受信し、検証結果のメッセージを送信する。この送受信されるメッセージ中に後述する検証用情報が含まれている。文書検証サービスシステム６０１は、入力された構造化文書が所定の文書スキーマを満たしているか否か検証するためのものである。文書検証サービスシステム６０１は、この検証用情報を利用して検証処理の効率化を図る。
【０２２０】
また、文書検証サービス６０１は、制御部６０２、メッセージ送受信部６０３、メッセージ記憶部６０４、入出力部６０５、検証用情報記憶部６０６、文書インスタンス記憶部６０７、文書スキーマ記憶部６０８、正規化部６０９、ダイジェスト値計算部６１０、文書分割部６１１、妥当性検証部６１２および検証結果出力部６１３を備える。
【０２２１】
文書分割部６１１は、データ構造的視点から構造化文書を分割する手法として、文書スキーマの構造的特徴に基づいて構造化文書を二つ以上の部分に分割する。そして、制御部６０２は、分割された構造化文書が文書スキーマを満たしているか否か検証された後に、分割された構造化文書の各部分および文書スキーマの少なくとも一つに対して検証結果に影響する変更が加えられたか否かを判定する。
【０２２２】
検証結果出力部６１３は、分割された構造化文書の各部分のうち、制御部６０２により検証結果に影響する変更が加えられたと判定された特定部分については、特定部分が文書スキーマを満たしているか否かを検証して特定部分に関する検証結果とする。また、検証結果出力部６１３は、変更が加えられていないと判定された部分については、直近に構造化文書の各部分が条件を満たしているか否か検証されたときの結果を検証結果とする。そして、検証結果出力部６１３は、これらの検証結果から入力された構造化文書全体としての検証結果を出力する。
【０２２３】
上記において、文書分割部６１１は、例えば、一つの文書スキーマから文書スキーマの構造的特徴を抽出する。このとき、文書分割部６１１は、一つの文書スキーマを構成する要素として、一つ以上の他の文書スキーマが利用されている場合、他の文書スキーマを利用した要素を文書スキーマの構造的特徴として抽出する。例えば、構造化文書がXMLで記述され、文書スキーマがW3C XML Schemaで記述されている場合、他の文書スキーマを利用した要素は、他の文書スキーマをインポートすることで表現されている。そして、文書分割部６１１は、他の文書スキーマを利用した要素を単位として構造化文書を分割する。
【０２２４】
また、文書分割部６１１は、一つの文書スキーマに基づいて文書スキーマに適合するために必須の文書要素を文書スキーマの構造的特徴として抽出してもよい。さらに、文書分割部６１１は、一つの文書スキーマに基づいて文書スキーマにおいて複数回出現することが許容されている文書要素を文書スキーマの構造的特徴として抽出してもよい。例えば、文書分割部６１１は、文書スキーマの構造化文書がXMLで記述され、文書スキーマがW3C XML Schemaで記述される場合、文書スキーマ中のパーティクルに基づいて必須の文書要素を特定する。
【０２２５】
また、文書分割手段６１１は、複数の文書スキーマに基づいて文書スキーマの構造的特徴を抽出してもよい。この場合、文書分割部６１１は、複数の文書スキーマが、一つの文書サービスに対する入力用文書スキーマと出力用文書スキーマである場合、入力用文書スキーマと出力用文書スキーマの共通部分を文書スキーマの構造的特徴として抽出する。そして、文書分割部６１１は、入力用文書スキーマと出力用文書スキーマの共通部分を単位として構造化文書を分割する。例えば、文書分割部６１１は、構造化文書がXMLで記述され、文書スキーマがW3C XML Schemaで記述される場合、一つの文書サービスのWSDL文書に基づいて一つの文書サービスに対する入力用文書スキーマと出力用文書スキーマを特定する。
【０２２６】
また、処理プロセスに視点を置いた例では、文書分割部６１１は、構造化文書に加えられる変更に応じて、構造化文書を二つ以上の部分に分割する。このとき、文書分割手段６１１は、構造化文書へ変更が加えられる前に、構造化文書に対する変更可能性を特定する。例えば、文書分割部６１１は、構造化文書へ変更を加える処理を記述する入力用文書スキーマおよび出力用文書スキーマに基づいて構造化文書に対する変更可能性を特定する。また、文書分割部６１１は、複数の文書スキーマが、連携された文書サービス群で利用される複数の文書スキーマである場合、連携された文書サービス群で利用される複数の文書スキーマの共通部分を文書スキーマの構造的特徴として抽出してもよい。
【０２２７】
このとき、文書分割部６１１は、連携を形成するための情報に基づいて、連携された文書サービス群で利用される複数の文書スキーマを特定する。例えば、構造化文書がXMLで記述され、文書スキーマがW3C XML Schemaで記述され、連携を形成するための情報がBPEL4WSで記述される。また、別の例では、文書分割部６１１は、連携された文書サービスで処理された文書を追跡することにより連携された文書サービス群で利用される複数の文書スキーマを特定するようにしてもよい。
【０２２８】
文書分割部６１１は、構造化文書へ変更を加える処理が公開する変更情報に基づいて構造化文書に対する変更可能性を特定することもできる。この変更情報は、例えば、検証処理装置に通知されることで公開され、レジストリサービスを用いて公開され、サービス記述言語を用いて公開され、問い合わせインタフェースを用いて公開される。
【０２２９】
また、文書分割部６１１は、構造化文書へ加えられた変更に応じて、構造化文書に対する変更可能性を特定してもよい。具体的には、文書分割部６１１は、構造化文書をサンプリングすることにより構造化文書へ加えられた変更を調べる。例えば、文書分割部６１１は、一つのサービスの入力文書と出力文書とをサンプリングすることにより構造化文書へ加えられた変更を調べる。また、文書分割部６１１は、連携されたサービスで用いられる文書群をサンプリングすることにより構造化文書へ加えられた変更を調べることができる。例えば、連携されたサービスのハブで連携されたサービスで用いられる文書群をサンプリングする。また、文書分割部６１１は、メッセージフローを追跡することにより構造化文書をサンプリングする。
【０２３０】
制御部６０２は、構造化文書が直近に検証された時点で構造化文書の各部分に所定の演算を実行して得られた情報と、入力された構造化文書の各部分に所定の演算を実行して得られた情報が異なる場合に、構造化文書の各部分に対して検証結果に影響する変更が加えられたと判定する。また、制御部６０２は、構造化文書が直近に検証された時点で所定の文書スキーマに所定の演算を実行して得られた情報と、所定の文書スキーマに所定の演算を実行して得られた情報が異なる場合に、所定の文書スキーマに対して検証結果に影響する変更が加えられたと判定する。
【０２３１】
ここで、所定の演算は、前処理および一方向関数適用処理の一方を少なくとも含む。前処理は、例えば構造化文書の表現のゆれを吸収するための正規化処理である。前処理は、例えば構造化文書の文字列表現から文書要素、文書要素属性および文書要素を含まない内容を節とする木のうち少なくとも一つを生成する処理であってもよい。また、一方向関数適用処理は、例えば、ＭＤ５アルゴリズムおよびＳＨＡ１アルゴリズムを含むダイジェスト関数を適用する処理である。また、一方向関数適用処理は、例えば、線形合同法およびメルセンヌ・ツイスタを含む再現性のある擬似乱数アルゴリズムを適用する処理であってもよい。
【０２３２】
さらに、文書分割部６１１は、構造化文書の分割に応じて、分割された各部分を検証するための文書スキーマフラグメントを生成し、検証結果出力部６１３は、文書スキーマフラグメントに基づいて構造化文書に変更が加えられたと判定された部分の検証を行うようにしてもよい。このとき、文書分割部６１１は、制御部６０２が構造化文書の特定部分に変更が加えられたと判定した後に、特定部分に対応する文書スキーマフラグメントを生成する。また、文書スキーマ記憶部６０８は、ある構造化文書の検証に用いた文書スキーマフラグメントを保持し、妥当性検証部６１２は、文書スキーマを同じくする他の構造化文書の検証の際にこの保持された文書スキーマフラグメントを再利用する。
【０２３３】
妥当性検証部６１２は、構造化文書に変更が加えられたと判定された部分の検証において、文書分割部６１１による構造化文書の分割に応じて、特定の文書要素についてはその下位構造を検証することなく、特定の文書要素の存在をもってその下位構造は文書スキーマを満たすと見なして構造化文書を検証する。
【０２３４】
図１１４は、文書検証サービスシステム６０１の基本的な検証処理フローを示す図である。具体的には、図１１４は、文書検証サービスシステム６０１における、検証依頼メッセージの受信から検証結果メッセージの送信に至る基本的な処理フローを示す図である。図１１４に示した処理フローは、制御部６０２により実行される。
【０２３５】
この処理フローでは、次に挙げることから検証処理を効率化する。
（１）一度検証が実施された構造化文書は、その構造化文書および文書スキーマに変更がない場合には検証結果は前回と同じであるため、再度の検証は行わない。
（２）構造化文書や文書スキーマの変更の有無は、ダイジェスト値計算などの所定の演算から生成される値を比較することにより、簡単に判定できる。
（３）構造化文書を分割して各部分ごとに検証結果と所定の演算から生成される値とを用意することにより、構造化文書が変更された場合には、構造化文書全体を再検証することなく、変更箇所を含む部分のみ再検証することで構造化文書全体の検証結果を得ることが出来る。
【０２３６】
以下、詳細に説明する。図１１４に示すように、制御部６０２は、受信メッセージに検証用情報が含まれているかどうかを判断し、受信メッセージに検証用情報が含まれている場合（ステップＳ２００１で「はい」）、正規化部６０９により検証に用いた文書スキーマを正規化する（ステップＳ２００２）。次いで、制御部６０２は、ダイジェスト値計算部６１０により文書スキーマのダイジェスト値を計算する（ステップＳ２００３）。制御部６０２は、計算されたダイジェスト値が検証用情報の中の値と一致した場合（ステップＳ２００４で「はい」）、文書分割部６１１により検証用情報中の分割箇所に従い、検証対象の構造化文書を分割する（ステップＳ２００５）。
【０２３７】
そして、制御部６０２は、正規化部６０９により分割された各部分を正規化し（ステップＳ２００６）、ダイジェスト値算出部６１０により分割された各部分のダイジェスト値を計算する（ステップＳ２００７）。制御部６０２は、計算されたダイジェスト値が検証用情報中の値と全て一致する場合（ステップＳ２００８で「はい」）、送信する検証用情報として、受信メッセージの検証用情報をコピーし（ステップＳ２００９）、ステップＳ２０２２に進む。制御部６０２は、計算されたダイジェスト値が検証用情報中の値と全て一致しない場合（ステップＳ２００８で「いいえ」）、妥当性検証部６１２によりダイジェスト値が一致しなかった部分について妥当性を検証し、検証結果を生成する（ステップＳ２０１０）。制御部６０２は、生成された検証結果と、ダイジェスト値が一致する部分に関する検証用情報中の検証結果から文書全体の検証結果を生成する（ステップＳ２０１１）。
【０２３８】
制御部６０２は、ダイジェスト値計算部６１０により、ダイジェスト値が一致しなかった部分のダイジェスト値を計算する（ステップＳ２０１２）。また、制御部６０２は、送信する検証用情報として、受信メッセージの検証用情報をコピーに対して、ダイジェスト値が一致しなかった部分について新たに生成した検証結果と新たに計算したダイジェスト値で上書きした検証用情報を生成し（ステップＳ２０１３）、ステップＳ２０２２に進む。制御部６０２は、ステップＳ２００１で、受信メッセージに検証用情報が含まれない場合、又はステップＳ２００４で、計算されたダイジェスト値が検証用情報中の値と一致しない場合、文書分割部６１１により検証対象の文書を分割する（ステップＳ２０１４）。制御部６０２は、正規化部６０９により分割された各部分を正規化する（ステップＳ２０１５）。
【０２３９】
制御部６０２は、妥当性検証部６１２により各部分の妥当性を検証し、検証結果を生成する（ステップＳ２０１６）。制御部６０２は、各部分の検証結果から構造化文書全体の検証結果を生成し（ステップＳ２０１７）、ダイジェスト値計算部６１０により各部分のダイジェスト値を計算し（ステップＳ２０１８）、正規化部６０９により検証に用いた文書スキーマを正規化し（ステップＳ２０１９）、ダイジェスト値計算部６１０により文書スキーマのダイジェスト値を計算する（ステップＳ２０２０）。そして、制御部６０２は、検証結果、分割箇所およびダイジェスト値を含む検証用情報を生成し（ステップＳ２０２１）、ステップＳ２０２２に進む。最後に、制御部６０２は、検証用情報を含むメッセージを依頼元に送信する（ステップＳ２０２２）。
【実施例１６】
【０２４０】
次に、本発明の実施例１６について説明する。図１１５は、実施例１６におけるシステムの構成を示す図である。本実施例では、物品調達において購入側システム６３１と販売側システム６３２との間で交わされる構造化文書を、文書検証サービスシステム６５０が検証する。本実施例では、購入側システム６３１と販売側システム６３２との間でのやりとりで、国際標準化団体Organization for the Advancement of Structured Information Standards (OASIS)が勧告する標準であるUniversal Business Language (UBL) 1.0に準拠する文書を用いている。
【０２４１】
図１１６は、ＵＢＬの調達プロセスと使用されるスキーマを示す図である。ＵＢＬでは、図１１６に示すように、物品調達プロセスにおける購入側(Buyer)と販売側(Seller)とで交わされる構造化文書を、”Order”, “OrderResponseSimple”などの文書スキーマによって定義している。なお、データフォーマットとしては、構造化文書はXML、文書スキーマはW3C XML Schema、メッセージはＳＯＡＰが用いられる。なお、図１１６はUBL 1.0仕様書から引用した。
【０２４２】
また、本実施例では、文書分割部６１１は、構造化文書の分割手法として、一つの文書スキーマに基づいて文書スキーマの構造的特徴を抽出する。また、文書スキーマとして、ＵＢＬの調達プロセスに使用されるものを使用する。ここでは、ある文書スキーマが他の文書スキーマをインポートしているため、それに応じて構造化文書の分割を行う例である。分割点指定として、インポートされた文書スキーマのルート要素にあたる文書要素を示すXPathロケーションパスを生成する。所定の演算の手法は、正規化部６０９は、前処理として正規化、ダイジェスト値計算部６１０は、一方向関数適用処理としてダイジェスト値の計算を実行する。
【０２４３】
ダイジェスト値算出部６１０は、分割点として指定された文書要素とその下位要素を削除した部分構造aに対するダイジェスト値と、その要素とその下位要素だけからなる部分構造ｂに対するダイジェスト値とを計算する。分割された構造化文書の検証手法にはフラグメント生成する手法を用いる。遅延評価により文書スキーマフラグメントを生成する。文書スキーマフラグメントとして、分割点として指定された文書要素をオリジナルの文書スキーマから削除したものと、分割点として指定された文書要素をルートとするものとを生成する。前者は部分構造aの検証に利用し、後者は部分構造ｂの検証に利用する。
【０２４４】
なお実施例１６の変形として、必須要素および繰り返し要素による分割、他の前処理と一方向関数適用処理、フラグメント再利用および遅延評価について、文章を補う形で触れる。
【０２４５】
以下、各機能部について説明する。制御部６０２は、システム全体の処理を統括する機能を持つ。メッセージ送受信部６０３は、パブリックネットワーク６３０を介して他のサービスシステムとメッセージを送受信する機能を持つ。本システムが受信するメッセージには、少なくとも、他のサービスシステムから構造化文書の検証を依頼するメッセージがある。また、送信するメッセージとして、受信された検証依頼に対して、依頼した他のシステム宛に検証結果を含むメッセージがある。
【０２４６】
メッセージ記憶部６０４は、メッセージ送受信部６０３によって受信されたメッセージ、および、本システムから他のシステムへ送信するために作成されたメッセージを記憶する機能を持つ。入出力部６０５は、本システムの管理者に情報を提供する機能とともに、管理者によるシステムに対する指示を受け付ける機能を持つ。文書インスタンス記憶部６０７は、検証対象となる構造化文書、および、後述する文書分割によって作られる部分構造を記憶する機能を持つ。文書スキーマ記憶部６０８は、検証に用いられる文書スキーマ、および、後述する文書分割によって作られる文書スキーマフラグメントを記憶する機能を持つ。文書スキーマ記憶部６０８に記憶される文書スキーマは、UBL 1.0に定義されるものである。
【０２４７】
正規化部６０９は、ダイジェスト値計算の前処理として、構造化文書の表現の揺れを吸収するための正規化処理を行う機能を持つ。ここで、正規化処理とは、文書が複数のプログラムによって順次処理されるとき、個々のプログラムによる本来の機能とは無関係な処理によって発生する表記のゆれを吸収するための処理である。個々のプログラムによる本来の機能とは無関係な処理には、例えば、スペースや改行記号の追加、文字コードの変換などが含まれる。構造化文書に対して正規化処理を実行することにより、同一とみなすべき文書をまったく同じ表記にそろえることができる。本実施例では、正規化部６０９は、W3C勧告のCanonical XMLに従って正規化を行う。
【０２４８】
ダイジェスト値計算部６１０は、文書スキーマ記憶部６０８中の文書スキーマ、および、文書インスタンス記憶部６０７中の部分構造のダイジェスト値を計算する機能を持つ。ある電子情報からは一意のダイジェスト値が計算されるため、その電子情報に対する変更の有無は、以前のダイジェスト値と現在のダイジェスト値を比較してダイジェスト値が一致した場合に電子情報に変更がなかったことが判定でき、ダイジェスト値が一致しない場合に電子情報に変更があったことが容易に判定できる。実施例１６では、構造化文書の部分構造や文書スキーマへの変更の有無の判定にダイジェスト値を用いる。なお一方向関数適用処理としては、ＭＤ５アルゴリズムやＳＨＡアルゴリズム、ＳＨＡ１アルゴリズムなどを含むダイジェスト関数を適用する処理を利用できる。
【０２４９】
文書分割部６１１は、検証対象となる構造化文書を部分構造に分割する機能を持つ。実施例１６では、検証対象となる構造化文書を部分木に分割するが、このときに文書分割部６１１は一つの文書スキーマの構造的特徴に着目して分割を行う。この実施例１６における構造的特徴は、ある文書スキーマが他の文書スキーマをその構成要素として含んでいることである。
【０２５０】
図１１７は、スキーマインポートの例を示す図である。図１１７に示す例では、文書スキーマOrderResponseSimpleがUBL-CoreComponentParameters-1.0などの他の文書スキーマをインポートする形で構成要素として用いている。これらインポートされる文書スキーマは、例えば注文書中の発注者情報など、文書内での意味的なかたまりを形成している。文書内での意味的なかたまりは、ある文書処理において一括して内容が生成ないし更新されるか、あるいは全く変更されずに参照のみされる場合が多い。したがって、このようなかたまりに着目して文書構造を分割し、部分ごとに検証と必要に応じた再検証を実行することにより、ある部分の変更が他の部分に影響を及ぼす可能性が少ないため、全体として検証処理の効率を上げることが出来る。
【０２５１】
文書分割部６１１は、検証対象となる構造化文書を調べ、インポートされる文書スキーマでのルート要素にあたる文書要素（複数の場合あり）を、文書構造の分割点として抽出する。そして、分割点以下の部分構造と、元の構造化文書から部分構造を取り除いたものとを生成し、文書インスタンス記憶部６０７に記憶させる。そして、文書分割部６１１は、文書要素に応じて文書スキーマフラグメントを生成して、文書スキーマ記憶部６０８に記憶させる。本実施例における文書スキーマフラグメントとは、分割された部分構造を検証するための文書スキーマであり、オリジナルの文書スキーマから一部の要素を削除したものである。ここで、文書スキーマフラグメントの必要性、並びに、文書の分割と文書スキーマフラグメントの関係について概念図（図１１８）を用いて説明する。
【０２５２】
図１１８は、文書スキーマフラグメントの例を示す図である。図１１８右上の文書インスタンスは、図１１８左上に示すオリジナルの文書スキーマを満たしているとする。ここで、文書要素BreakHereを分割点とした場合、部分構造ａおよび部分構造ｂが生成される。このとき、オリジナルの文書スキーマを用いてこれらの部分構造を検証すると、検証結果はいずれも「妥当ではない」となる。なぜなら、いずれの部分構造もオリジナルの文書スキーマで必須の要素として規定される文書要素を欠いているためである。このように、オリジナルの文書スキーマを用いても、分割された部分構造を検証するために不都合が生じる場合がある。そこで、オリジナルの文書スキーマから部分構造検証用の文書スキーマを作ることを考える。
【０２５３】
図１１８の例では、オリジナルの文書スキーマからBreakHere要素を規定する部分を除いた文書スキーマフラグメントａと、BreakHere要素をルートとして他の部分を除いた文書スキーマフラグメントｂにあたる。図１１８右上の文書インスタンスがオリジナルの文書スキーマを満たす場合は、文書スキーマフラグメントａで部分構造ａを検証した結果が「妥当」かつ、文書スキーマフラグメントｂで部分構造ｂを検証した結果が「妥当」となる。また、図１１８右上の文書インスタンスがオリジナルの文書スキーマを満たさない場合は、文書スキーマフラグメントを用いた部分構造の検証の少なくとも一方で「妥当でない」という結果が得られる。
【０２５４】
このように、文書スキーマフラグメントを用いることにより、部分構造を検証し、構造化文書全体としての検証結果を得ることが出来るようになる。なお、図１１８の例では説明を簡単にするために、部分構造ｂの定義は文書スキーマ要素BreakHereの開始タグと終了タグの間にすべて書かれているものとした。しかし、W3C XML Schemaによって記述された文書スキーマにおいては、Composite要素に含まれる要素はComposite要素の外側で定義され、Composite要素の開始タグと終了タグの間に存在するパーティクルで定義を用いる、といった場合がある。本実施例での文書分割部６１１は、このような場合でも、必要な定義を文書スキーマフラグメントに含める。
【０２５５】
妥当性検証部６１２は、ある部分構造が特定の文書スキーマフラグメントを満たすかどうかを検証する機能を持つ。本実施例での妥当性検証は、前述したように部分構造と文書スキーマフラグメントが生成されるため、W3C XML Schemaによって記述された文書スキーマに対するXML文書の妥当性を検証する通常の手法を適用できる。検証用情報記憶部６０６は、検証対象となる構造化文書ごとに検証用情報を記憶する機能を持つ。
【０２５６】
図１１９は、検証用情報の例を示す図である。検証用情報は、構造化文書全体としての直近の検証結果としてのブール値（図１１９での要素ResultOfDoc）、直近の検証時での文書スキーマのダイジェスト値（図１１９での要素SchemaDigest）、構造化文書部分ごとの検証用情報（図１１９での要素Part）から構成される。構造化文書部分ごとの検証用情報は、その構造化文書部分の分割点をXPath式によって示した情報（図１１９での要素DividingPoint）、その構造化文書部分の直近の検証結果としてのブール値（図１１９での要素SchemaDigest）、直近の検証時でのその構造化文書部分のダイジェスト値（図１１９での要素PartDigest）からなる。なお、図１１８での部分構造ａにあたる、分割点以下を除いた残りに構造化文書部分を示す場合、要素DividingPointの内容としてnull値が割り当てられる。
【０２５７】
検証用情報は、他のシステムから文書検証を依頼された際に、そのメッセージに含まれる場合がある。また、検証依頼の結果を返す際に、そのメッセージに検証用情報が含まれる。本実施例では、他のシステムとの情報交換にはSOAPエンベロープを用いており、検証用情報はエンベロープのヘッダ部に含まれる。
【０２５８】
検証結果出力部６１３は、検証用情報を新たに生成するか、あるいは、検証依頼に含まれるものからコピーを作成して検証用情報記憶部６０６に記憶させる。そして、検証結果出力部６１３は、文書分割部６１１、妥当性検証部６１２、ダイジェスト値計算部６１０のそれぞれの処理結果に合わせて検証用情報を更新する機能を持つ。
【０２５９】
以下、実施例１６の変形例について述べる。一つの文書スキーマの構造的特徴に応じた分割として、前記のものの他に、文書構造として必須の要素とオプショナルな要素とを分割してもよい。また、繰り返し現れうる要素をそれぞれ分割しても良い。これは、オプショナルな要素や繰り返し現れうる要素は、文書処理の過程で追加削除が行われる可能性が高いためである。このような分割を行うことにより、追加削除が行われた場合でも他の部分に影響を及ぼさない検証用情報を付与できる。
【０２６０】
また異なる変形例として、検証対象となる構造化文書の文字列表現から文書要素、文書要素属性および文書要素を含まない内容を節とする木のうち少なくとも一つを生成する処理を前処理としてもよい。この前処理は、DOMツリーに対して一方向関数を適用する前に、名前空間を示す接頭辞(prefix)や文字列の表層表現の違いなどが影響を与えないようにするための処理である。この前処理は、例えばRFC2803で定義されるDOMHASHでのコードフラグメントに対する処理に相当する。
【０２６１】
また異なる変形例として、一方向関数適用処理は、線形合同法およびメルセンヌ・ツイスタを含む再現性のある擬似乱数アルゴリズムを適用する処理であってもよい。再現性のある擬似乱数アルゴリズムを適用した場合、ダイジェスト値計算と同様に、ある文書部分の変更の有無をその部分を詳細に調べることなく値の比較によって判定できるようになる。
【０２６２】
また異なる変形例として、文書分割部６１１が検証依頼毎に文書スキーマフラグメントを生成するのではなく、以前の検証処理で生成して文書スキーマ記憶部６０８に記憶させた文書スキーマフラグメントを再利用しても良い。例えば、図１１８で文書スキーマフラグメントｂにあたるものを再利用することを考えると、文書スキーマフラグメントとオリジナルの文書スキーマのダイジェスト値とを対応づけて文書スキーマ記憶部６０８に記憶しておく。
【０２６３】
新たな検証依頼で分割点となっている文書要素の要素名が記憶された文書スキーマフラグメントのルート要素のname属性に一致し、かつ、その時点における文書スキーマのダイジェスト値と前記対応づけて記憶されたダイジェスト値が一致する場合、文書スキーマフラグメントは文書要素を検証するためのものであり、かつ、オリジナルの文書スキーマは変更されていないので、文書スキーマフラグメントを再利用できる。また、異なる変形例として、文書スキーマフラグメントの生成に、ダイジェスト値を比較した結果として再検証が必要になってから初めて生成するという、遅延評価を用いても良い。
【実施例１７】
【０２６４】
次に、本発明の実施例１７について説明する。図１２０は、実施例１７におけるシステム７００の構成を示す図である。ネットワーク６３０上には、旅行代理店側システム７２１、旅行企画会社側システム７２２、ホテル側システム７２３およびホテル側システム７２４のサービスシステムが接続されている。図１２０に示すように、本実施例における文書検証サービス７０１では、図１１３に示した文書検証サービス６０１と比べて、ＷＳＤＬ文書インスタンス記憶部７０２が追加されている。
【０２６５】
本実施例では、構造化文書の分割の手法には、複数の文書スキーマから構造的特徴を抽出する手法と、構造化文書の変更可能性を文書スキーマから特定する手法を用いる。文書スキーマは、TravelXML実証実験で用いられたもののうち、特定のサービスの入力用文書スキーマおよび出力用文書スキーマを使用する。この例では、これらの文書スキーマに共通部分がある。このため、文書分割部６１１は、この共通部分を切り出して構造化文書の分割を行う。入力用文書スキーマと出力用文書スキーマの対応関係は、そのサービスのWSDL文書で調べることが出来る。なお、分割点指定は実施例１６と同様である。なお、TravelXMLは、非営利団体XMLコンソーシアムが勧告する標準である。
【０２６６】
また、分割された文書の検証手法には、みなし検証を用いる。分割点以下の部分構造を検証する場合と、分割点以下を除いた部分構造を検証する場合とで、妥当性検証アルゴリズムを変える。分割点以下の部分構造を検証する場合は、その分割点がルートにあたることを許容することを除き、オリジナルの文書スキーマを用いた通常の検証と同じである。分割点以下を除いた部分構造の検証では、分割点の存在を確認した段階で、それ以下の構造については文書スキーマを満たすものとみなして検証をスキップし、検証を続行する。
【０２６７】
所定の演算の手法は、ほぼ実施例１６と同じだが、実施例１６とは検証手法が異なるので、ダイジェスト値を計算する部分構造に若干の違いがある。部分構造aにあたるものには、分割点となる文書要素の存在を示す情報は含まれている。ここで、分割点となる文書要素の存在を示す情報とは、ＸＭＬの場合、その文書要素の開始タグと終了タグのペアとなる。部分構造ｂにあたるものには、分割点となる文書要素の存在を示す情報が除かれている。なお実施例１７の変形例として、抽出した共通部分の再利用と、入出力文書をサンプリングして分割をさらに絞り込むことについて、文章を補う形で触れる。
【０２６８】
本実施例では、パッケージツアーでの在庫照会および予約手配で用いられる構造化文書を、文書検証サービスシステム７０１が検証するものである。本実施例では、購入側システムと販売側システムとの間でやりとりはTravelXMLを用いている。また、旅行代理店側システム７２１の問い合わせから開始される在庫照会および予約手配プロセスでの一連の処理手続きは、旅行企画会社側システム７２２に実装されている。なお、データフォーマットとしては、構造化文書はXML、文書スキーマはW3C XML Schema、サービスインタフェース記述としてWSDL、メッセージはSOAPが用いられる。
【０２６９】
以下、各機能部について説明するが、実施例１６と同等なものは説明を省略する。WSDL文書インスタンス記憶部７０２は、他のシステムのサービスインタフェースを記述したWSDL文書を記憶する機能を持つ。このWSDL文書は、後述するように検証対象となる構造化文書を分割するのに用いられる。文書インスタンス記憶部７０２は、後述するように妥当性検証の手法が実施例１６とは異なるため、本機能部に部分構造は記憶されない。本実施例での文書スキーマ記憶部６０８は、WSDL文書インスタンス記憶部７０２に記憶されたWSDL文書に記述されている文書スキーマを記憶する機能を持つ。なお、後述するように妥当性検証の手法が実施例１６とは異なるため、本機能部に文書スキーマフラグメントは記憶されない。
【０２７０】
本実施例での文書分割部６１１は、二つの文書スキーマの構造的特徴に着目して、検証対象となる構造化文書の分割点を決定する機能を持つ。ここで、二つの文書スキーマとは、WSDL文書インスタンス記憶部７０２に記憶された一つのWSDL文書に記述されている、あるシステムの入力用文書スキーマと出力用文書スキーマである（図１２２参照）。図１２２は、実施例１７におけるWSDL文書インスタンスの概念図を示す図である。
【０２７１】
文書分割部６１１は、これらの文書スキーマ中の共通部分を抽出し、検証対象となる構造化文書の文書部分がこの共通部分に含まれる場合は文書部分を分割する。これは、共通部分となる入力部分と出力部分は同じ部分構造と内容が含まれる可能性があるためである。例えば、ホテルに対する空室照会における入力と出力において、旅行者情報やパッケージツアー情報が含まれ、これらの情報はホテル側では参照するのみで上書きは行われず入力と出力は同じ部分構造と内容を持つ。このような共通部分を分割して検証と必要に応じた再検証を実行することにより、部分構造と内容が変化しない場合には再検証の必要がないので、検証効率を上げることが出来る。決定された分割点は、実施例１５と同様に、検証用情報の分割点としてXPath式で記述される。
【０２７２】
なお、本実施例での文書分割部６１１は、後述するように妥当性検証の手法が異なるため、実施例１６とは異なり、部分構造および文書スキーマフラグメントを生成しない。
【０２７３】
本実施例での妥当性検証部６１２は、一般の妥当性検証のアルゴリズムと異なり、分割点以下の部分構造を検証する場合と、分割点以下を除いた部分構造を検証する場合とで、妥当性検証アルゴリズムを変える。この検証アルゴリズムについて図１２４を用いて説明する。図１２４は、実施例１７における妥当性検証部６１２の検証手法の概念図を示す図である。
【０２７４】
図１２４に示す文書スキーマと文書インスタンス、および分割点となる文書要素BreakHereは図１１８と同様である。分割点となる文書要素BreakHere以下を除いた部分構造の検証では、文書要素Rootから左深さ優先で検証を行う。そして分割点の存在、すなわち、BreakHere要素の開始タグと終了タグを確認し、もし揃っている場合その内側は検証せずに検証を続行する。揃っていない場合、分割点が存在しないと判断し「妥当ではない」という結果を返して検証を終了する。分割点となる文書要素BreakHere以下の部分構造を検証する場合は、他の部分を検証しないという点を除き、通常の検証と同じである。
【０２７５】
以下、実施例１７の変形例について述べる。実施例１７の変形例として、文書分割部６１１は、WSDL文書インスタンス記憶部６０７に新たにWSDL文書が記憶されるごとに、文書スキーマ中の共通部分をあらかじめ抽出して記憶しておき、抽出されたものを構造化文書の分割の際に再利用する形にしても良い。また異なる変形例として、共通部分が複数箇所存在する場合に、入出力文書の検証情報をサンプリングして分割点を絞り込んでもよい。例えば、サンプリングされた複数の文書において、共通部分に対応する複数の文書部分のダイジェスト値が、一つの文書内では常に揃って変化がない場合には、この共通部分を内包する上位要素から分割しても良い。
【実施例１８】
【０２７６】
次に、本発明の実施例１８について説明する。図１２１は、実施例１８におけるシステムの構成を示す図である。図１２１に示すように、システム８００では、ネットワーク６３０上には、旅行代理店システム７２１、旅行企画会社側システム７２２、ホテル側システム７２３、ホテル側システム７２４および連携サービス側システム８２５のサービスシステムが接続されている。また、文書検証サービス８０１には、BPEL4WS文書インスタンス記憶部８０２が追加されている。
【０２７７】
本実施例では、実施例１７と同様に、パッケージツアーでの在庫照会および予約手配で用いられる構造化文書を、文書検証サービスシステム８００が検証するものである。実施例１７との違いは、旅行代理店側システム７２１の問い合わせから開始される在庫照会および予約手配プロセスでの一連の処理手続きは、連携サービス側システム８２５で実装されており、この一連の手続きをBPEL4WSを用いて記述している。したがって、本実施例では連携サービス側システム８２５をハブとしてメッセージ交換が行われ、一連の処理手続きが進められる。
【０２７８】
また、構造化文書の分割の手法には、実施例１７と同様に、複数の文書スキーマから特徴を抽出する手法と、構造化文書の変更可能性を文書スキーマから特定する手法を用いる。文書スキーマとして、連携されたサービスでの文書スキーマを用いる点が異なる。文書スキーマには、TravelXML実証実験で用いられたもののうち、特定の処理シナリオで用いられた文書スキーマを使用する。この例では、これらの文書スキーマに共通部分があるので、この部分を切り出して構造化文書の分割を行う。文書スキーマの共通部分を見つける方法は、連携の記載にBPEL4WSを用いたものとして、BPEL4WS文書から参照されているWSDL文書を利用する。なお、分割点指定は実施例１６と同様である。また、分割された構造化文書の検証手法および所定の演算の手法は実施例１７と同じである。
【０２７９】
なお実施例１８の変形例として、連携されたサービス間で交わされる構造化文書を連携のハブとなるBPEL4WS実行プロセスでサンプリングして分割をさらに絞り込むことについて、文章を補う形で触れる。
【０２８０】
以下、各機能部について説明するが、実施例１７と同等なものは説明を省略する。BPEL4WS文書インスタンス記憶部８０２は、連携サービス側システムで用いられるBPEL4WS文書を記憶する機能を持つ。このBPEL4WS文書は、後述するように検証対象となる構造化文書の分割に用いられる。文書分割部６１１は、複数の文書スキーマの構造的特徴に着目して、検証対象となる構造化文書の分割点を決定する機能を持つ。ここで複数の文書スキーマとは、BPEL4WS文書インスタンス記憶部８０２に記憶された一つのBPEL4WS文書にリンクされた複数のWSDL文書に記述されている文書スキーマである（図１２３参照）。図１２３は、実施例１８におけるBPEL4WS文書インスタンスの概念図である。
【０２８１】
文書分割部６１１は、これらの文書スキーマ中の共通部分を抽出し、検証対象となる構造化文書の文書部分がこの共通部分に含まれる場合はこの文書部分を分割する。共通部分を利用する理由は実施例１６と同等である。
【０２８２】
以上述べた実施例の変形例として、共通部分が複数箇所存在する場合に、連携サービス側システム８２５で入出力されるメッセージに含まれる検証用情報をサンプリングして分割点を絞り込んでもよい。例えば、サンプリングされた複数の文書において、共通部分に対応する複数の文書部分のダイジェスト値が、一つの文書内では常に揃って変化がない場合には、この共通部分を内包する上位要素から分割しても良い。
【実施例１９】
【０２８３】
次に、本発明の実施例１９について説明する。図１２５は、実施例１９のシステムの構成を示す図である。図１２５に示すように、システム９００では、ネットワーク６３０上に、旅行代理店側システム９２１、レンタカー会社側システム９２２、ホテル側システム９２３および鉄道会社側システム９２４のサービスシステムが接続されている。また、文書検証サービス９０１では、文書変更／参照情報記憶部９０２が追加されている。
【０２８４】
本実施例では、構造化文書の分割の手法には、個々のサービスが変更の有無を公開する手法のうち、検証処理へ通知する手法を用いる。また、分割された構造化文書の検証手法および所定の演算の手法は、実施例１６と同じである。なお、実施例１９の変形例として、レジストリへの公開とサービス記述言語（具体的にはWSDL）の拡張と専用問い合わせインタフェースについて、文章を補う形で触れる。また、メッセージフローを追跡してサンプリングし、分割点を絞り込むことについても触れる。
【０２８５】
図１２６は、実施例１９でのメッセージフロー概念図である。本実施例では、旅行代理店側システム９２１を旅行予約プロセスの出発点とし、ホテル側システム９２３、鉄道会社側システム９２４およびレンタカー会社側システム９２２の各システムは、受け取った旅程表の日程候補に在庫が存在する場合は予約情報を書き込んで次工程のシステムに更新された旅程表を渡し、在庫がない場合は予約失敗として旅行代理店側システム９２１にその旨を通知して処理を打ち切る。なお、説明を簡単にするため、図１２６では成功例のみを記載する。
【０２８６】
そして、この一連の処理に関わる各システム９２１〜９２４は、文書検証サービスシステム９０１に旅程表の検証を依頼するものである。なお本実施例では、各システム９２１〜９２４は、旅行旅程表を受け取る以前に代理店側の指示に従い、次工程のシステムについて知っており、各システムで旅程表を受け取って次工程に渡すまでの処理は個々に実装されている。
【０２８７】
以下、各機能部について説明するが、上記実施例と同等なものは説明を省略する。本実施例での文書スキーマ記憶部６０８には、旅程表の文書スキーマが記憶されている。文書変更／参照情報記憶部９０２は、各システムが変更する、あるいは参照する文書要素について、旅程表の文書スキーマ中の要素名と編集種別（変更あるいは参照を示す予約語）とを組とした情報を記憶している。ここで変更とは、文書要素の追加や削除、および内容の追記や上書きや削除を含んでいる。この情報は、各システムから送られる検証依頼メッセージのヘッダ部分に、検証用情報とともに、XML形式で記述されている。
【０２８８】
本実施例での文書分割部６１１は、文書変更／参照情報記憶部９０２中の情報に応じて構造化文書の分割を行う。文書変更／参照情報記憶部９０２に記憶された情報の内、複数のシステムで同じ部分が参照されている場合、構造化文書のうちこの部分を分割することで検証処理の効率を上げることが出来る。また逆に、複数のシステムで構造化文書のうち同じ部分が変更されている場合、その部分を分割することで他の部分に変更の影響が及ばなくなるため、検証処理の効率を上げることが出来る可能性がある。
【０２８９】
本実施例の変形例として、サービスを公開するためのレジストリサービスに各システムがサービス登録する際に、文書変更／参照情報を同時に登録し、文書検証サービスシステム９０１がこのレジストリを確認して変更される文書変更／参照情報に応じて構造化文書を分割するようにしてもよい。特にTravelXMLのような業界標準の文書スキーマが存在する場合は、異なる組織で運営されている複数のシステムにおいても、業界標準の文書スキーマに基づいて同種のメッセージが統一的に運用されるようになる。このような場合には、文書検証サービスシステム９０１が受信するメッセージに文書変更／参照情報を含めるのではなく、文書検証サービスシステム９０１が必要に応じてレジストリサービスを参照する方が、ネットワーク帯域の利用の観点から望ましい場合がある。
【０２９０】
また異なる変形例として、各システムの入出力を定義するサービス記述言語を拡張し、文書変更／参照情報を記述できるようにしても良い。例えばWSDLでは、message要素として入力メッセージ及び出力メッセージが持つ文書構造と内容の型を定義できるが、WSDLを拡張して文書変更／参照情報を表現する新たな要素とmessage要素との対応を記述できるようにしても良い。また異なる変形例として、各システムが文書変更／参照情報を問い合わせるための専用インタフェースを持ち、文書検証サービスシステム９０１が必要に応じて各システムに文書変更／参照情報を問い合わせるようにしても良い。
【０２９１】
また異なる変形例として、文書検証サービスシステム９０１が検証依頼を受けたメッセージをサンプリングし、一連の処理において実際に起こる構造化文書の変更の度合いに応じて分割点を絞り込んでもよい。例えば、あるシステムが構造化文書のある部分を変更する可能性があるが必ずしも毎回変更しない場合、文書変更／参照情報としてはその部分は「変更」として表現される。このような場合に、構造化文書の変更頻度が低い場合はその構造化文書の部分を分割しないで検証処理を行う方が、分割にかかる処理時間など鑑みて効率的である場合がある。
【０２９２】
以上、上記実施例１５〜実施例１９によれば、文書スキーマの構造的な特徴および文書処理プロセスに応じて構造化文書が分割され、各部分ごとの検証用の情報が生成され、検証時に利用される。これにより、構造化文書が変更されない限りはその文書に対する検証処理を一度だけ実行すればよく、また、変更された場合においても変更箇所を含む部分のみ再検証すればよいので、構造化文書の検証処理の効率が向上する。
【０２９３】
以上本発明の好ましい実施例について詳述したが、本発明は係る特定の実施例に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形、変更が可能である。
【図面の簡単な説明】
【０２９４】
【図１】本システムの全体構成図である。
【図２】本システムの処理の流れ図である。
【図３】利用者クライアントが旅行代理店に送信する旅程表作成依頼書を示す図である。
【図４】旅程表作成依頼書スキーマを示す図である。
【図５】旅行代理店が作成し、鉄道会社に送信する旅程表ドラフトを示す図である。
【図６】旅程表ドラフトスキーマを示す図である。
【図７】鉄道会社が旅行代理店に返信する旅程表ドラフトを示す図である。
【図８】旅行代理店が航空会社に送信する旅程表ドラフトを示す図である。
【図９】航空会社が旅行代理店に返信し、旅行代理店が航空会社に送信する旅程表ドラフトを示す図である。
【図１０】航空会社が旅行代理店に返信する旅程表ドラフトを示す図である。
【図１１】旅行代理店がレンタカー会社に送信し、レンタカー会社が返信し、旅行代理店がレンタカー会社に送信する旅程表ドラフトを示す図である。
【図１２】レンタカー会社が旅行代理店に返信する旅程表ドラフトを示す図である。
【図１３】旅行代理店がホテルに送信する旅程表ドラフトを示す図である。
【図１４】ホテルが旅行代理店に返信する旅程表ドラフトを示す図である。
【図１５】旅行代理店が欠落情報を補足した旅程表ドラフトを示す図である。
【図１６】旅行代理店が旅程表ドラフトから生成し、翻訳サービスに送信する旅程表を示す図である。
【図１７】旅程表スキーマを示す図である。
【図１８】翻訳サービスが旅行代理店に返信し、旅行代理店が利用者に送信する旅程表を示す図である。
【図１９】レンタカー会社が文書検証サービスに妥当性検証処理を依頼するときの送受信用文書を示す図である。
【図２０】実施例１に係るシステムの構成図である。
【図２１】実施例１に係る検証処理制御部の処理の流れ図である。
【図２２】実施例１に係る検証済文書保持部に保持されている文書を示す図である。
【図２３】レンタカー会社から文書検証サービスに入力される送受信用文書を示す図である。
【図２４】実施例２に係るシステムの構成図を示す図である。
【図２５】実施例２に係る検証処理制御部１１５の処理の流れを示す図である。
【図２６】実施例２に係るサブルーチンEVALUATEの処理の流れを示す図である。
【図２７】実施例２に係るサブルーチンGET_DIGESTの処理の流れを示す図である。
【図２８】レンタカー会社から文書検証サービスに入力される送受信用文書を示す図である。
【図２９】実施例２に係るDOMツリーを示す図である。
【図３０】図２９の１行目から４２行目の各ノードの説明を示す図である。
【図３１】ステップＳ１０４３終了時点での送受信用文書を示す図である。
【図３２】文書スキーマを示す図である。
【図３３】検証結果の文書を示す図である。
【図３４】実施例３に係るサブルーチンGET＿DIGESTの処理の流れを示す図である。
【図３５】レンタカー会社に送信される送受信用文書の例を示す図である。
【図３６】実施例４に係るサブルーチンEVALUATEの処理の流れの一例を示す図である。
【図３７】実施例４に係るサブルーチンGET＿DIGESTの処理の流れの一例を示す図である。
【図３８】ステップＳ１０９２の処理の流れの一例を示す図である
【図３９】レンタカー会社に返信される送受信用文書を示す図である。
【図４０】旅行代理店からレンタカー会社へ送信される文書に追加処理を実行した結果得られる文書を示す図である。
【図４１】旅行代理店からレンタカー会社へ送信される文書に対応する文書スキーマである。
【図４２】追加処理を実行した結果得られる文書を示す図である。
【図４３】実施例５に係るサブルーチンCANONICALIZEの処理の流れを示す図である。
【図４４】図４０の文書と図４２の文書をそれぞれサブルーチンCANONICALIZEに入力したときに得られるDOMツリーを示す図である。
【図４５】実施例６に係るサブルーチンCANONICALIZEの処理の流れを示す図である。
【図４６】実施例６に係る文書スキーマを示す図である。
【図４７】旅行代理店からレンタカー会社に送信される文書を示す図である。
【図４８】図４６の文書スキーマを利用し、図４７の文書をサブルーチンCANONICALIZEに入力したときに得られるDOMツリーを示す図である。
【図４９】実施例７に係るXML DTDに基づく文書スキーマを示す図である。
【図５０】図４９の文書スキーマを参照する文書を示す図である。
【図５１】XML標準仕様に基づく表記法を採用した文書の例を示す図である。
【図５２】実施例７に係るサブルーチンCANONICALIZEの処理の流れを示す図である。
【図５３】実施例７に係るＤＯＭツリーを示す図である。
【図５４】実施例８に係るXML DTDに基づく文書スキーマを示す図である。
【図５５】図５４の文書スキーマを参照する文書を示す図である。
【図５６】実施例８に係るサブルーチンCANONICALIZEの処理の流れを示す図である。
【図５７】実施例９に係る検証処理制御部の処理の流れの一例を示す図である。
【図５８】実施例９に係る検証処理制御部の処理の流れのもう一つの例を示す図である。
【図５９】ステップＳ１１４２で生成される処理対象の一部を示す図である。
【図６０】ステップＳ１１４２で生成される処理対象の一部を示す図である。
【図６１】ステップＳ１１４２で生成される処理対象の一部を示す図である。
【図６２】ステップＳ１１４２で生成される処理対象の一部を示す図である。
【図６３】ステップＳ１１４２で生成される処理対象の一部を示す図である。
【図６４】ステップＳ１１４２で生成される処理対象の一部を示す図である。
【図６５】ステップＳ１１４２で生成される処理対象の一部を示す図である。
【図６６】ステップＳ１１４２で生成される処理対象の一部を示す図である。
【図６７】ステップＳ１１４２で生成される処理対象の一部を示す図である。
【図６８】ステップＳ１１４２で生成される処理対象の一部を示す図である。
【図６９】ステップＳ１１４２で生成される処理対象の一部を示す図である。
【図７０】図１８の４３行目のplace要素に対応する文書要素を示す図である。
【図７１】実施例９に係る文書スキーマフラグメントを示す図である。
【図７２】実施例９に係る文書スキーマフラグメントを示す図である。
【図７３】実施例９に係る文書スキーマフラグメントを示す図である。
【図７４】実施例９に係る文書スキーマフラグメントを示す図である。
【図７５】実施例９に係る文書スキーマフラグメントを示す図である。
【図７６】実施例９に係る文書スキーマフラグメントを示す図である。
【図７７】実施例９に係る文書スキーマフラグメントを示す図である。
【図７８】実施例９に係る文書スキーマフラグメントを示す図である。
【図７９】実施例９に係る文書スキーマフラグメントを示す図である。
【図８０】実施例９に係る文書スキーマフラグメントを示す図である。
【図８１】実施例９に係る文書スキーマフラグメントを示す図である。
【図８２】図７２に対応する文書スキーマフラグメントを示す図である。
【図８３】実施例９に係る検証処理制御部の処理の流れを示す図である。
【図８４】ステップＳ１３０２で生成される処理対象の一部を示す図である。
【図８５】実施例９に係る文書スキーマフラグメントを示す図である。
【図８６】翻訳サービスから返信される、図１８の文書を含む送受信用文書の一部を示す図である。
【図８７】図８６の送受信用文書が文書検証サービスに入力されたとき、図５９から図７０で示した文書部分ごとに算出されるダイジェスト値（新ダイジェスト値）と、図８６で示したダイジェスト値(旧ダイジェスト値)の一覧を示す図である。
【図８８】実施例１０に係る送受信用文書を示す図である。
【図８９】文書検証サービスから航空会社に返信される送受信用文書を示す図である。
【図９０】旅行代理店から文書検証サービスに送信される送受信文書を示す図である。
【図９１】妥当性検証結果とダイジェスト値が保持されている３つの部分構造ごとに、digest要素に保持されているダイジェスト値と、文書検証サービスによって算出されるダイジェスト値の一覧を示す図である。
【図９２】実施例１１に係るシステムの構成図を示す図である。
【図９３】実施例１１に係るサブルーチンEVALUATEの処理の流れ図である。
【図９４】実施例１１に係る更新後の文書スキーマを示す図である。
【図９５】図９の文書が旅行代理店に返信されるときの送受信用文書を示す図である。
【図９６】実施例１２に係る検証処理制御部の処理の流れ図である。
【図９７】文書スキーマＡの定義する言語が文書スキーマＢの定義する言語を包含するか否か判定する処理の流れを示す図である。
【図９８】実施例１２に係るサブルーチンCOMPAREの処理の流れを示す図である。
【図９９】図６の文書スキーマ中のpassengers要素に対応する記号を左辺に持つ生成規則が導出する言語を受理する決定性有限オートマトンを示す図である。
【図１００】図９４の文書スキーマ中のpassengers要素に対応する記号を左辺に持つ生成規則が導出する言語を受理する決定性有限オートマトンを示す図である。
【図１０１】実施例１３に係るシステムの構成図である。
【図１０２】実施例１３に係るサブルーチンEVALUATEの処理の流れ図である。
【図１０３】ステップＳ１２１１の処理の流れ図である。
【図１０４】文書検証サービスに入力される送受信用文書の例を示す図である。
【図１０５】文書編集サービスから文書検証サービスに送信される送受信用文書を示す図である。
【図１０６】送受信用文書を示す図である。
【図１０７】実施例１４に係るシステムの構成図である。
【図１０８】実施例１４に係るサブルーチンEVALUATEの処理の流れ図である。
【図１０９】従来手法での検証処理時間、本発明の手法での未検証文書に対する処理時間、本発明の手法での検証済文書に対する処理時間の計測結果例を示す図である。
【図１１０】図１０９の処理時間を仮定した場合に、同一の文書に対する処理回数と、本発明の手法の処理時間を１としたときの従来手法の処理時間との相関を示す図である。
【図１１１】計測に用いた文書を示す図である。
【図１１２】計測に用いた文書スキーマを示す図である。
【図１１３】本発明の実施例１５に係るシステムの構成を示す図である。
【図１１４】文書検証サービスシステムの基本的な検証処理フローを示す図である。
【図１１５】本発明の実施例１６のシステムの構成を示す図である。
【図１１６】ＵＢＬの調達プロセスと使用されるスキーマを示す図である。
【図１１７】スキーマインポートの例を示す図である。
【図１１８】文書スキーマフラグメントの例を示す図である。
【図１１９】検証用情報の例を示す図である。
【図１２０】実施例１７におけるシステムの構成を示す図である。
【図１２１】実施例１８におけるシステムの構成を示す図である。
【図１２２】実施例１７におけるWSDL文書インスタンスの概念図である。
【図１２３】実施例１８におけるBPEL4WS文書インスタンスの概念図である。
【図１２４】実施例１７における妥当性検証部の検証手法の概念図である。
【図１２５】実施例１９におけるシステムの構成を示す図である。
【図１２６】実施例１９でのメッセージフロー概念図である。
【符号の説明】
【０２９５】
１００  システム
１０１  ホテル
１０２、１０３  レンタカー会社
１０４  翻訳サービス
１０５、１０６  航空会社
１０７  鉄道会社
１０８  利用者クライアント
１０９  旅行代理店
１１０、２１０、３１０、４１０、５１０  文書検証サービス
１１１  送受信用文書保持部
１１２  検証済文書保持部
１１３  文書正規化部
１１４  文書検証部
１１５  検証処理制御部
１１６  文書利用者
１２０  ネットワーク
２１１  ダイジェスト値算出部
３１１  文書スキーマ保持部
５１１  検証履歴保持部
【図１】
2006351002.tif 000003
【図２】
2006351002.tif 000004
【図３】
2006351002.tif 000005
【図４】
2006351002.tif 000006
【図５】
2006351002.tif 000007
【図６】
2006351002.tif 000008
【図７】
2006351002.tif 000009
【図８】
2006351002.tif 000010
【図９】
2006351002.tif 000011
【図１０】
2006351002.tif 000012
【図１１】
2006351002.tif 000013
【図１２】
2006351002.tif 000014
【図１３】
2006351002.tif 000015
【図１４】
2006351002.tif 000016
【図１５】
2006351002.tif 000017
【図１６】
2006351002.tif 000018
【図１７】
2006351002.tif 000019
【図１８】
2006351002.tif 000020
【図１９】
2006351002.tif 000021
【図２０】
2006351002.tif 000022
【図２１】
2006351002.tif 000023
【図２２】
2006351002.tif 000024
【図２３】
2006351002.tif 000025
【図２４】
2006351002.tif 000026
【図２５】
2006351002.tif 000027
【図２６】
2006351002.tif 000028
【図２７】
2006351002.tif 000029
【図２８】
2006351002.tif 000030
【図２９】
2006351002.tif 000031
【図３０】
2006351002.tif 000032
【図３１】
2006351002.tif 000033
【図３２】
2006351002.tif 000034
【図３３】
2006351002.tif 000035
【図３４】
2006351002.tif 000036
【図３５】
2006351002.tif 000037
【図３６】
2006351002.tif 000038
【図３７】
2006351002.tif 000039
【図３８】
2006351002.tif 000040
【図３９】
2006351002.tif 000041
【図４０】
2006351002.tif 000042
【図４１】
2006351002.tif 000043
【図４２】
2006351002.tif 000044
【図４３】
2006351002.tif 000045
【図４４】
2006351002.tif 000046
【図４５】
2006351002.tif 000047
【図４６】
2006351002.tif 000048
【図４７】
2006351002.tif 000049
【図４８】
2006351002.tif 000050
【図４９】
2006351002.tif 000051
【図５０】
2006351002.tif 000052
【図５１】
2006351002.tif 000053
【図５２】
2006351002.tif 000054
【図５３】
2006351002.tif 000055
【図５４】
2006351002.tif 000056
【図５５】
2006351002.tif 000057
【図５６】
2006351002.tif 000058
【図５７】
2006351002.tif 000059
【図５８】
2006351002.tif 000060
【図５９】
2006351002.tif 000061
【図６０】
2006351002.tif 000062
【図６１】
2006351002.tif 000063
【図６２】
2006351002.tif 000064
【図６３】
2006351002.tif 000065
【図６４】
2006351002.tif 000066
【図６５】
2006351002.tif 000067
【図６６】
2006351002.tif 000068
【図６７】
2006351002.tif 000069
【図６８】
2006351002.tif 000070
【図６９】
2006351002.tif 000071
【図７０】
2006351002.tif 000072
【図７１】
2006351002.tif 000073
【図７２】
2006351002.tif 000074
【図７３】
2006351002.tif 000075
【図７４】
2006351002.tif 000076
【図７５】
2006351002.tif 000077
【図７６】
2006351002.tif 000078
【図７７】
2006351002.tif 000079
【図７８】
2006351002.tif 000080
【図７９】
2006351002.tif 000081
【図８０】
2006351002.tif 000082
【図８１】
2006351002.tif 000083
【図８２】
2006351002.tif 000084
【図８３】
2006351002.tif 000085
【図８４】
2006351002.tif 000086
【図８５】
2006351002.tif 000087
【図８６】
2006351002.tif 000088
【図８７】
2006351002.tif 000089
【図８８】
2006351002.tif 000090
【図８９】
2006351002.tif 000091
【図９０】
2006351002.tif 000092
【図９１】
2006351002.tif 000093
【図９２】
2006351002.tif 000094
【図９３】
2006351002.tif 000095
【図９４】
2006351002.tif 000096
【図９５】
2006351002.tif 000097
【図９６】
2006351002.tif 000098
【図９７】
2006351002.tif 000099
【図９８】
2006351002.tif 000100
【図９９】
2006351002.tif 000101
【図１００】
2006351002.tif 000102
【図１０１】
2006351002.tif 000103
【図１０２】
2006351002.tif 000104
【図１０３】
2006351002.tif 000105
【図１０４】
2006351002.tif 000106
【図１０５】
2006351002.tif 000107
【図１０６】
2006351002.tif 000108
【図１０７】
2006351002.tif 000109
【図１０８】
2006351002.tif 000110
【図１０９】
2006351002.tif 000111
【図１１０】
2006351002.tif 000112
【図１１１】
2006351002.tif 000113
【図１１２】
2006351002.tif 000114
【図１１３】
2006351002.tif 000115
【図１１４】
2006351002.tif 000116
【図１１５】
2006351002.tif 000117
【図１１６】
2006351002.tif 000118
【図１１７】
2006351002.tif 000119
【図１１８】
2006351002.tif 000120
【図１１９】
2006351002.tif 000121
【図１２０】
2006351002.tif 000122
【図１２１】
2006351002.tif 000123
【図１２２】
2006351002.tif 000124
【図１２３】
2006351002.tif 000125
【図１２４】
2006351002.tif 000126
【図１２５】
2006351002.tif 000127
【図１２６】
2006351002.tif 000128