ネットワークを介してXML文書である電文を受信する受信手段と、前記電文の構造が顧客毎にそれぞれ定義されている第1のスキーマと、前記第1のスキーマでそれぞれ共通して定義される項目が定義されている第2のスキーマと、前記電文と前記第1及び第2のスキーマを対応付ける対応情報と、を記憶する記憶手段と、前記記憶手段で記憶されている対応情報に基づいて、前記受信手段で受信した電文に対応する前記第1のスキーマ及び前記第2のスキーマを特定する特定手段と、前記受信手段で受信した電文の構造が、前記特定手段で特定した第1のスキーマにより定義されている構造であるか否かを判定する受信電文判定手段と、前記受信電文判定手段により前記電文の構造が前記第1のスキーマにより定義されている構造であると判定された場合、前記特定手段で特定した第2のスキーマに基づいてインスタンスを生成するインスタンス生成手段と、前記インスタンス生成手段で生成されたインスタンスに前記電文の情報を記録して対応する顧客にネットワークを介して送信する送信手段と、を備えることを特徴とするXMLメッセージ変換装置。前記送信手段は、前記インスタンス生成手段で生成されたインスタンスに前記電文の情報を記録した情報を、送信用のXML文書である送信用電文に変換する変換手段と、前記送信用電文の構造が前記特定手段で特定した第1のスキーマにより定義されている構造であるか否かを判定する送信電文判定手段と、を備えることを特徴とする請求項1に記載のXMLメッセージ変換装置。前記受信電文判定手段により前記電文の構造が前記第1のスキーマにより定義されていない構造であると判定された場合、ネットワークを介してエラーメッセージを通知する通知手段を、さらに備えることを特徴とする請求項1又は2に記載のXMLメッセージ変換装置。ネットワークを介してXML文書である電文を受信する受信ステップと、前記電文の構造が顧客毎にそれぞれ定義されている第1のスキーマと、前記第1のスキーマでそれぞれ共通して定義される項目が定義されている第2のスキーマと、前記電文と前記第1及び第2のスキーマを対応付ける対応情報と、を記憶する記憶ステップと、前記記憶ステップで記憶された対応情報に基づいて、前記受信ステップで受信した電文に対応する前記第1のスキーマ及び前記第2のスキーマを特定する特定ステップと、前記受信ステップで受信した電文の構造が、前記特定ステップにより特定された第1のスキーマにより定義されている構造であるか否かを判定する受信電文判定ステップと、前記受信電文判定ステップにより前記電文の構造が前記第1のスキーマにより定義されている構造であると判定された場合、前記特定ステップで特定された第2のスキーマに基づいてインスタンスを生成するインスタンス生成ステップと、前記インスタンス生成ステップで生成されたインスタンスに前記電文の情報を記録して対応する顧客にネットワークを介して送信する送信ステップと、を備えることを特徴とするXMLメッセージ変換方法。コンピュータを、ネットワークを介してXML文書である電文を受信する受信手段、前記電文の構造が顧客毎にそれぞれ定義されている第1のスキーマと、前記第1のスキーマでそれぞれ共通して定義される項目が定義されている第2のスキーマと、前記電文と前記第1及び第2のスキーマを対応付ける対応情報と、を記憶する記憶手段、前記記憶手段で記憶されている対応情報に基づいて、前記受信手段で受信した電文に対応する前記第1のスキーマ及び前記第2のスキーマを特定する特定手段、前記受信手段で受信した電文の構造が、前記特定手段で特定した第1のスキーマにより定義されている構造であるか否かを判定する受信電文判定手段、前記受信電文判定手段により前記電文の構造が前記第1のスキーマにより定義されている構造であると判定された場合、前記特定手段で特定した第2のスキーマに基づいてインスタンスを生成するインスタンス生成手段、前記インスタンス生成手段で生成されたインスタンスに前記電文の情報を記録して対応する顧客にネットワークを介して送信する送信手段として機能させることを特徴とするプログラム。しかしながら、非特許文献1に記載のオブジェクトモデル方式では、個々の金融機関単位でXMLスキーマを作成するため、XMLスキーマ量に応じて業務アプリケーションのプログラム製造規模が増加する。また、非特許文献1に記載のオブジェクトモデル方式では、XMLスキーマの数が増加すると、それに応じて生成されるクラスも増加するため、プログラム量も増加する。さらに、非特許文献1に記載のオブジェクトモデル方式では、金融機関の要望に応じてXMLスキーマの定義を変更する度にプログラムを修正する必要があるが、当該プログラムは複数の金融機関で共同利用するため、特定の金融機関が希望する任意のタイミングで修正することが困難であった。そのため、金融機関毎に柔軟なバリデーションを行うという観点からみると、未だ十分ではない。ここで、バリデーションとは、あるXMLインスタンスXML形式で記述されたデータを含む文書の内容が、対応するXMLスキーマに定義されている情報に適合しているか否かを検証する処理のことである。本発明は、上述のような事情に鑑みてなされたものであり、顧客毎に柔軟なバリデーションが可能なXMLメッセージ変換装置、XMLメッセージ変換方法、およびプログラムを提供することを目的としている。上記目的を達成するため、本発明の第1の観点に係るXMLメッセージ変換装置は、ネットワークを介してXML文書である電文を受信する受信手段と、前記電文の構造が顧客毎にそれぞれ定義されている第1のスキーマと、前記第1のスキーマでそれぞれ共通して定義される項目が定義されている第2のスキーマと、前記電文と前記第1及び第2のスキーマを対応付ける対応情報と、を記憶する記憶手段と、前記記憶手段で記憶されている対応情報に基づいて、前記受信手段で受信した電文に対応する前記第1のスキーマ及び前記第2のスキーマを特定する特定手段と、前記受信手段で受信した電文の構造が、前記特定手段で特定した第1のスキーマにより定義されている構造であるか否かを判定する受信電文判定手段と、前記受信電文判定手段により前記電文の構造が前記第1のスキーマにより定義されている構造であると判定された場合、前記特定手段で特定した第2のスキーマに基づいてインスタンスを生成するインスタンス生成手段と、前記インスタンス生成手段で生成されたインスタンスに前記電文の情報を記録して対応する顧客にネットワークを介して送信する送信手段と、を備えることを特徴とする。また、前記送信手段は、前記インスタンス生成手段で生成されたインスタンスに前記電文の情報を記録した情報を、送信用のXML文書である送信用電文に変換する変換手段と、前記送信用電文の構造が前記特定手段で特定した第1のスキーマにより定義されている構造であるか否かを判定する送信電文判定手段と、を備えていてもよい。また、前記XMLメッセージ変換装置は、前記受信電文判定手段により前記電文の構造が前記第1のスキーマにより定義されていない構造であると判定された場合、ネットワークを介してエラーメッセージを通知する通知手段を、さらに備えていてもよい。上記目的を達成するため、本発明の第2の観点に係るXMLメッセージ変換方法は、ネットワークを介してXML文書である電文を受信する受信ステップと、前記電文の構造が顧客毎にそれぞれ定義されている第1のスキーマと、前記第1のスキーマでそれぞれ共通して定義される項目が定義されている第2のスキーマと、前記電文と前記第1及び第2のスキーマを対応付ける対応情報と、を記憶する記憶ステップと、前記記憶ステップで記憶された対応情報に基づいて、前記受信ステップで受信した電文に対応する前記第1のスキーマ及び前記第2のスキーマを特定する特定ステップと、前記受信ステップで受信した電文の構造が、前記特定ステップにより特定された第1のスキーマにより定義されている構造であるか否かを判定する受信電文判定ステップと、前記受信電文判定ステップにより前記電文の構造が前記第1のスキーマにより定義されている構造であると判定された場合、前記特定ステップで特定された第2のスキーマに基づいてインスタンスを生成するインスタンス生成ステップと、前記インスタンス生成ステップで生成されたインスタンスに前記電文の情報を記録して対応する顧客にネットワークを介して送信する送信ステップと、を備えることを特徴とする。上記目的を達成するため、本発明の第3の観点に係るプログラムは、コンピュータを、ネットワークを介してXML文書である電文を受信する受信手段、前記電文の構造が顧客毎にそれぞれ定義されている第1のスキーマと、前記第1のスキーマでそれぞれ共通して定義される項目が定義されている第2のスキーマと、前記電文と前記第1及び第2のスキーマを対応付ける対応情報と、を記憶する記憶手段、前記記憶手段で記憶されている対応情報に基づいて、前記受信手段で受信した電文に対応する前記第1のスキーマ及び前記第2のスキーマを特定する特定手段、前記受信手段で受信した電文の構造が、前記特定手段で特定した第1のスキーマにより定義されている構造であるか否かを判定する受信電文判定手段、前記受信電文判定手段により前記電文の構造が前記第1のスキーマにより定義されている構造であると判定された場合、前記特定手段で特定した第2のスキーマに基づいてインスタンスを生成するインスタンス生成手段、前記インスタンス生成手段で生成されたインスタンスに前記電文の情報を記録して対応する顧客にネットワークを介して送信する送信手段として機能させることを特徴とする。本発明によれば、顧客毎に柔軟なバリデーションが可能となる。本発明の実施形態に係るXMLメッセージ変換装置について、図面を参照して説明する。XMLメッセージ変換装置は、メディアセンタと複数の金融機関ホストとの間で通信される業務電文を送受信するとともに、共通スキーマと個別スキーマを用いて業務電文の柔軟なバリデーションを行うバリデーション機能を備えている。メディアセンタは、例えば、個人ユーザや業者等を含む利用者から送信される業務電文を収集するコンピュータである。また、金融機関ホストは、例えば、銀行や証券会社、生命保険会社等を含む金融機関に設置されるコンピュータで、受信した業務電文に基づく処理を行う。ここで、業務電文はXML電文であり、クライアント番号、銀行コード、電文コード、及び、サービスコード等を含む業務データ、残高照会や振り込み等の処理要求、及び、各処理の結果が含まれる。XMLメッセージ変換装置は、上記機能を実現する構成として、図1に示すように、主記憶部101と、補助記憶部102と、制御部103と、通信部104と、入出力部105と、上記各部を相互に接続するシステムバス106と、を備えている。XMLメッセージ変換装置100は、メディアセンタ200と複数の金融機関ホスト300とそれぞれネットワークを介して通信可能に接続されている。主記憶部101は、RAMRandomAccessMemory等を含んで構成され、後述するCPUの作業領域として用いられる。補助記憶部102は、ROMReadOnlyMemory、磁気ディスク、半導体メモリ等の不揮発性メモリを含んで構成されている。この補助記憶部102には、制御部103が処理を行うために必要なデータやパラメータ、プログラム等が記憶されている。また、補助記憶部102には、後述する入出力部105からユーザの入力操作により入力される関連情報110と、共通XMLスキーマ111と、銀行別XMLスキーマ112と、が格納される。関連情報110は、図2に示すように、業務電文中に含まれるクライアント番号、銀行コード、電文コード、及び、サービスコードに対応する共通XMLスキーマ111及び銀行別XMLスキーマ112を特定するための情報である。関連情報110は、ユーザの入力操作により後述する入出力部105から入力される。ここで、クライアント番号とは、パソコン等の端末を利用して残高照会等の各種金融業務を要求する顧客を一意に特定するための情報である。銀行コードは、金融機関ホストを一意に特定するための情報である。電文コードは、業務電文を一意に特定するための情報である。サービスコードは、各種金融業務毎に割り振られ、金融業務を一意に特定するための情報である。共通XMLスキーマ111は、ユーザにより生成され、後述するスキーマ準備処理においてユーザの入力操作により格納される。ここで、スキーマとは、XMLドキュメントの文法規則、すなわち、XMLドキュメントの取り得る構造を記述したデータである。スキーマは、XMLデータの文書構造と、値のデータ型が厳密にスキーマの定義内容と合っているかどうかを検証するために使用される。共通XMLスキーマ111は、全ての属性や構成要素、及び、業務電文であるXMLドキュメントの構造タグ名称が定義されたスキーマである。なお、構造タグ名称とは、XMLドキュメント中の各構成要素の名称を示す。銀行別XMLスキーマ112は、ユーザにより生成され、後述するスキーマ準備処理においてユーザの入力操作により格納される。銀行別XMLスキーマ112は、共通XMLスキーマ111で定義された構造タグ名称に従って、各金融機関別に、タグ名称、タグ出現回数、出現順序、桁数、及び、正規表現等のXML構造が定義されたスキーマである。銀行別XMLスキーマ112は、各金融機関別の業務電文のバリデーションを行う際に用いられる。ここで、XMLドキュメントの構造について図3を参照して説明する。タグ名称は、XMLドキュメント内の各要素を識別する名称である。タグ出現回数は、同一のタグ名称の要素の、XMLドキュメント内における出現回数を示す。出現順序は、それぞれのタグ名称により識別される要素の、XMLドキュメント内における出現順序を示す。桁数は、各タグ名称により識別される要素の桁数制限を示す。正規表現は、タグ名称により識別される各要素の、XMLドキュメント内における内容制限を示し、例えば、文字列のみ、数字のみ、といった制限を課すよう設定できる。次に、共通XMLスキーマ111と銀行別XMLスキーマ112について図4を参照して詳細に説明する。ここで、銀行別XMLスキーマ112は、銀行毎に存在し、銀行別に各項目がそれぞれ定義される。図示するように、銀行別XMLスキーマ112は、共通XMLスキーマ111で定義されたタグ名称及び出現順序に基づいてタグ名称及び出現順序が定義される。出現回数については、図示するように、例えば、共通XMLスキーマ111では、最小が0、最大が無制限を意味するunboundedに定義され、銀行別XMLスキーマ112では、最小が0、最大が50に定義される。また、桁数については、共通XMLスキーマ111では、桁数は制限されず、銀行別XMLスキーマ112では、桁数が制限される。図示する例では、銀行別XMLスキーマ112での桁数は12桁に制限される。正規表現については、図示するように、共通XMLスキーマ111では、特に制限がされず、任意の文字列であればよい、ということだけが定義される。一方、銀行別XMLスキーマ112では、制限が課される。制限は、例えば、タグ名称により識別される各要素の内容が、図示するように、数字のみに制限したり、図5に示すように、所定の文字のみ許可されるように制限できる。このように、銀行別XMLスキーマ112は、共通XMLスキーマ111で定義された範囲内において、各項目が銀行別にそれぞれ定義される。制御部103は、CPUCentralProcessingUnit等から構成される。制御部103は、補助記憶部102に格納されているプログラムに従って動作する。制御部103は、プログラムにより提供される主要な機能部として、記録部131と、送受信部132と、圧縮解凍部133と、XML解釈検証部134と、スキーマコンパイラ部135と、インスタンス生成部136と、電文編集部137と、電文変換部138と、を備えている。なお、上記各機能部で処理されるデータ等は、適宜後述する入出力部105へ出力され、表示されるものとする。記録部131は、後述する準備処理において、後述する入出力部105からユーザの入力操作により入力された関連情報110、共通XMLスキーマ111、及び、銀行別XMLスキーマ112等を補助記憶部102へ記録する。送受信部132は、後述する通信部104を介して、メディアセンタ200や金融機関ホスト300と業務電文の送受信処理を行う。圧縮解凍部133は、送受信部132で受信した業務電文の圧縮及び解凍を行う。圧縮の形式は、例えばZIP形式等である。圧縮解凍部133は、メディアセンタ200又は金融機関ホスト300から送受信部132の機能により受信した業務電文を解凍し、補助記憶部102へ格納する。また、圧縮解凍部133は、解凍した業務電文を、後述するXML解釈検証部134及びスキーマコンパイラ部135へ渡す。また、圧縮解凍部133は、後述する電文変換部138から供給された送信用業務電文を圧縮し、送受信部132へ供給する。XML解釈検証部134は、補助記憶部102に格納されている関連情報110を読み出し、圧縮解凍部133から供給された解凍済みの業務電文に対応する銀行別XMLスキーマを特定112する。具体的には、XML解釈検証部134は、業務電文中のクライアント番号、銀行コード、電文コード、及び、サービスコードをキーとして、関連情報からこれらに対応する銀行別XMLスキーマ112を特定する。また、XML解釈検証部134は、特定した銀行別XMLスキーマ112を補助記憶部102から読み出し、業務電文の構造が妥当であるか否かを検証する。具体的には、XML解釈検証部134は、業務電文中に含まれている各種コードの桁数やタグ名称、及び出現順序等が、特定した銀行別XMLスキーマ112に定義されている桁数や名称、及び構造に含まれるか否かを検証する。これにより、銀行別に業務電文のバリデーションが行われる。スキーマコンパイラ部135は、後述する準備処理において、補助記憶部102に格納されている共通XMLスキーマ111に基づいてJava登録商標クラスファイルを生成し、共通XMLスキーマ111と対応付けて補助記憶部102に格納する。Javaクラスファイルの生成は、例えば、XML文書からJavaのオブジェクトへの変換およびJavaのオブジェクトからXML文書への変換をするAPIであるJAXBJavaArchitectureforXMLBindingにより行われる。また、スキーマコンパイラ部135は、後述するサービス提供時の処理において、補助記憶部102に格納されている関連情報110を読み出し、圧縮解凍部133から受け取った解凍済みの業務電文に対応する共通XMLスキーマ111を、業務電文中のクライアント番号、銀行コード、電文コード、及び、サービスコードをキーとして特定する。スキーマコンパイラ部135は、特定した共通XMLスキーマ111に対応付けられて補助記憶部102に格納されているJavaクラスファイルを読み込み、後述するインスタンス生成部136に渡す。インスタンス生成部136は、スキーマコンパイラ部135から受け取ったJavaクラスファイルに基づいてJavaインスタンスJavaクラスファイルに定義されたデータ構造を、コンピュータのメモリ上に保持するための領域を生成する。また、インスタンス生成部136は、生成したJavaインスタンスに業務電文の内容を記録する。インスタンス生成部136は、業務電文の内容を記録したJavaインスタンスを、後述する電文編集部137へ渡す。電文編集部137は、インスタンス生成部136から受け取ったJavaインスタンスの内容を編集し、電文変換部138へ渡す。なお、Javaインスタンスの内容の編集は、例えば、各項目の通番の処理等を含んでいる。電文変換部138は、電文編集部137から受け取ったJavaインスタンスの内容を、金融機関ホスト300又はメディアセンタ200へ送信するためのXMLメッセージである送信用業務電文に変換する。また、電文変換部138は、送信用業務電文を送受信部132へ渡す。通信部104は、シリアルインタフェース、或いはアナログ信号を受信するためのアナログインタフェースを有している。メディアセンタ200または金融機関ホスト300から送信される情報は、通信部104によって受信され、システムバス106を介してCPUへ供給される。また、通信部104は、CPUから受け取った業務電文をメディアセンタ200または金融機関ホスト300へ送信する。入出力部105は、キーボード、マウス、表示装置などから構成される。入出力部105は、ユーザの入力操作により入力された種々の指示やデータを制御部103へ渡す。また、入出力部105は、制御部103から出力されるデータ等を取得して表示する。以上が本実施形態に係るXMLメッセージ変換装置100の構成である。次に、XMLメッセージ変換装置100の動作について、図6乃至図8を参照して説明する。まず、XMLメッセージ変換装置100によるバリデーション機能を実現するための準備を行う準備処理について、図6を参照して説明する。なお、準備処理は、入出力部105からのユーザによる入力操作に応じて開始される。XMLメッセージ変換装置100は、記録部131の機能により、入出力部105から入力された共通XMLスキーマ111を補助記憶部102へ格納するステップS101。次に、XMLメッセージ変換装置100は、記録部131の機能により、入出力部105から入力された銀行別XMLスキーマ112を補助記憶部102へ格納するステップS102。続いてXMLメッセージ変換装置100は、記録部131の機能により、入出力部105から入力された関連情報110を補助記憶部102へ格納するステップS103。次に、XMLメッセージ変換装置100は、スキーマコンパイラ部135の機能により、補助記憶部102に記憶されている共通XMLスキーマ111に基づいてJavaクラスファイルを生成するステップS104。そしてXMLメッセージ変換装置100は、スキーマコンパイラ部135の機能により、生成したJavaクラスファイルを共通XMLスキーマ111と対応付けて補助記憶部102に格納するステップS105。以上が準備処理におけるXMLメッセージ変換装置100の動作である。次に、サービス提供時の処理におけるXMLメッセージ変換装置100の動作について、図7及び図8を参照して説明する。サービス提供時の処理には、上り処理と下り処理があり、これらの処理は、通信部104がメディアセンタ200又は金融機関ホスト300から業務電文を受信する度に開始される。まず、通信部104がメディアセンタ200から業務電文を受信して金融機関ホスト300へ送信する上り処理について、図7を参照して説明する。XMLメッセージ変換装置100は、送受信部132の機能により、メディアセンタ200から送信された業務電文であるXMLドキュメントを、通信部104を介して取得するステップS201。続いてXMLメッセージ変換装置100は、圧縮解凍部133の機能により、送受信部132で取得したXMLドキュメントを解凍し、XML解釈検証部134及びスキーマコンパイラ部135へ渡すステップS202。XMLメッセージ変換装置100は、XML解釈検証部134の機能により、補助記憶部102に格納されている関連情報110を読み出し、圧縮解凍部133から受け取った解凍済みのXMLドキュメントに対応する銀行別XMLスキーマ112を特定するステップS203。続いてXMLメッセージ変換装置100は、XML解釈検証部134の機能により、特定した銀行別XMLスキーマ112を補助記憶部102から読み出し、XMLドキュメントの構造が妥当であるか否かを検証するステップS204。ステップS204において、XMLドキュメントの構造が妥当であると判断された場合ステップS204;Yes、XMLメッセージ変換装置100は、スキーマコンパイラ部135の機能により、補助記憶部102に格納されている関連情報110を読み出し、圧縮解凍部133から供給された解凍済みのXMLドキュメントに対応する共通XMLスキーマ111を特定するステップS205。一方、ステップS204において、XMLドキュメントの構造が妥当でないと判断された場合ステップS204;No、XMLメッセージ変換装置100は、XML解釈検証部134の機能により、エラーメッセージを生成し、通信部104を介して金融機関ホスト300へ送信するステップS206。そしてXMLメッセージ変換装置100は、この処理を終了する。次に、XMLメッセージ変換装置100は、スキーマコンパイラ部135の機能により、特定した共通XMLスキーマ111に対応するJava登録商標クラスファイルを補助記憶部102から読み込み、インスタンス生成部136に渡すステップS207。XMLメッセージ変換装置100は、インスタンス生成部136の機能により、スキーマコンパイラ部135で読み込んだJavaクラスファイルに基づいてJavaインスタンスを生成し、生成したJavaインスタンスにXMLドキュメントの内容を記録するステップS208。次に、XMLメッセージ変換装置100は、電文編集部137の機能により、インスタンス生成部136から受け取ったJavaインスタンスの内容を編集し、電文変換部138へ渡すステップS209。続いてXMLメッセージ変換装置100は、電文変換部138の機能により、受け取ったJavaインスタンスを、金融機関ホスト300へ送信するためのXMLメッセージである送信用業務電文に変換しステップS210、圧縮解凍部133へ渡す。XMLメッセージ変換装置100は、圧縮解凍部133の機能により、受け取った送信用業務電文を圧縮しステップS211、送受信部132へ渡す。XMLメッセージ変換装置100は、送受信部132の機能により、受け取った圧縮された送信用業務電文を、通信部104を介して対応する金融機関ホスト300へ送信しステップS212、この処理を終了する。次に、通信部104が金融機関ホスト300から業務電文を受信してメディアセンタ200へ送信する下り処理について、図8を参照して説明する。XMLメッセージ変換装置100は、送受信部132の機能により、金融機関ホスト300から送信された業務電文であるXMLドキュメントを、通信部104を介して取得するステップS301。続いてXMLメッセージ変換装置100は、図示するようにステップS302からステップS311までの処理を行うが、このステップS302からステップS311までの処理は上り処理におけるステップS202からステップS211までの処理と同様であるため説明を省略する。そしてXMLメッセージ変換装置100は、送受信部132の機能により、受け取った圧縮された送信用業務電文を、通信部104を介してメディアセンタ200へ送信しステップS312、この処理を終了する。以上が、サービス提供時の処理におけるXMLメッセージ変換装置100の動作である。このように、本実施形態の構成によれば、共通XMLスキーマ111によって業務電文中の前提となる部分を定義し、銀行毎に異なる業務電文中の項目の妥当性については個別に定義した銀行別XMLスキーマ112に基づいて確認する。このような独立した2段階構造のスキーマとすることで、共通XMLスキーマだけをコンパイルすればよい。したがって銀行毎に業務アプリケーションの修正を行うことなく、銀行毎に柔軟なバリデーションが可能となる。また、本実施形態の構成によれば、金融機関側の要望によりXMLスキーマの定義を変更する場合についても、その金融機関に対応する銀行別XMLスキーマ112を変更すればよく、共通XMLスキーマ111や他の銀行別XMLスキーマ112を変更する必要がなくなる。変形例この発明は、上記の実施の形態に限定されず、種々の変形及び応用が可能である。上記実施の形態では、関連情報110、共通XMLスキーマ111、及び、銀行別XMLスキーマ112がユーザの入力操作により入出力部105から入力される場合について説明したが、必ずしもこれに限定されない。搬送波に関連情報110、共通XMLスキーマ111、及び、銀行別XMLスキーマ112を重畳し、通信ネットワークを介して配信することも可能である。また、上記実施の形態では、準備処理において、共通XMLスキーマ111、銀行別XMLスキーマ112、関連情報110の順に補助記憶部102へ格納する例について説明したが、これらを格納する順番は任意であり、共通XMLスキーマ111、銀行別XMLスキーマ112、関連情報110のいずれの情報から格納してもよい。上記実施の形態では、XMLメッセージ変換装置100がXMLドキュメントの構造が妥当であるか否かを検証し、妥当でないと判断した場合に通信部104を介してエラーメッセージを金融機関ホスト300へ送信する例を示したがこれは一例である。エラーメッセージは、例えば、金融機関ホスト300ではなく、メディアセンタ200を介してユーザに送信してもよい。また、エラーメッセージを金融機関ホスト300に送信し、さらにメディアセンタ200を介してユーザに送信してもよい。この構成によれば、ユーザ側においても業務電文の構造エラーを検知することができ、早期に対応することが可能となる。上記実施の形態では、各スキーマに定義される出現回数について、共通XMLスキーマ111では最小が0、最大が無制限を意味するunboundedに定義され、銀行別XMLスキーマ112では最小が0、最大が50に定義される例を示したが、これは一例である。各スキーマにおける出現回数の定義は任意であり、銀行別XMLスキーマ112で定義される出現回数が共通XMLスキーマ111で定義されている出現回数の範囲内であれば任意の数でよい。また、上記実施の形態では、Javaインスタンスを送信用業務電文に変換する処理ステップS210及びステップS310の後に、送信用業務電文を圧縮する処理を行うステップS211及びステップS311例について説明したが、これらの処理の間に、送信用業務電文の構造が妥当であるか否かを検証する処理ステップS204及びステップS304を再度行ってもよい。この構成によれば、XMLドキュメントの編集処理等の前後において電文の構造の妥当性を検証することができ、より信頼性の高いバリデーションを行うことが可能になる。なお、本発明の実施の形態にかかるバリデーション機能を実現するための情報処理装置は、専用のシステムによらず、通常のコンピュータシステムを用いて実現可能である。例えば、汎用コンピュータに、上述の処理を実行するためのプログラムを格納した媒体CD-ROMなどから当該プログラムをインストールすることにより、上述の処理を実行する各種サーバを構成することができる。また、上述の機能を、OSOperatingSystemとアプリケーションとの分担、またはOSとアプリケーションとの協同により実現する場合等には、OS以外の部分のみを媒体に格納してもよい。また、搬送波にプログラムを重畳し、通信ネットワークを介して配信することも可能である。例えば、通信ネットワーク上の掲示板BBS、BulletinBoardSystemに当該プログラムを掲示し、ネットワークを介して当該プログラムを配信してもよい。そして、これらのプログラムを起動し、オペレーティングシステムの制御下で、他のアプリケーションプログラムと同様に実行することにより、上述の処理を実行できるように構成してもよい。