"少なくとも一部はコンピューティングデバイスによって実装される、電子データ交換EDI取引を変換する方法であって、EDIデータをバッチとして受信するステップであって、前記EDIデータの前記バッチは、複数のEDIドキュメントを含み、該複数のEDIドキュメントの各々は、1つの取引タイプに対応する少なくとも1つのEDI取引を有する、受信するステップと、該受信したEDIデータを、EDI標準にしたがって復号化することにより、前記EDIドキュメントに含まれる前記EDI取引を識別するステップと、前記バッチ内の前記複数のEDIドキュメントから、1つの統合化されたEDIドキュメントを生成するステップであって、前記1つの統合化されたEDIドキュメントは、前記取引タイプにしたがって編成された、前記識別したEDI取引のEDIデータを含む、生成するステップとを備えることを特徴とする方法。前記統合化されたEDIドキュメントは、拡張可能マークアップ言語XMLドキュメントであることを特徴とする請求項1に記載の方法。前記統合化されたEDIドキュメントに含まれる前記EDI取引を、XMLタグによって構造化するステップをさらに備え、前記XMLタグは、前記EDI取引の前記取引タイプを示していることを特徴とする請求項2に記載の方法。前記統合化されたEDIドキュメントは、超スキーマを含んでおり、該超スキーマは、前記EDI取引が参照する複数のスキーマを表すことを特徴とする請求項1に記載の方法。前記複数のスキーマをランタイムに処理するように変換するためのランタイムスキーママップを定義するステップをさらに備えることを特徴とする請求項4に記載の方法。前記統合化されたEDIドキュメント内の前記EDI取引を、前記EDI取引に含まれる1つまたは複数の情報にしたがってサブドキュメントとして編成するステップをさらに備え、前記サブドキュメント内の前記EDI取引は、前記複数のEDIドキュメント内の前記EDI取引と相互に関連することを特徴とする請求項1に記載の方法。請求項1に記載の方法を実行するためのコンピュータ実行可能命令を有することを特徴とする1つまたは複数のコンピュータ読み取り可能な媒体。送信元と受信側デバイスとの間における電子データ交換EDI取引を変換するシステムであって、EDIデータをバッチとして送信する送信元であって、前記EDIデータの前記バッチは、複数のEDIドキュメントを含み、該複数のEDIドキュメントの各々は、1つの取引タイプに対応する少なくとも1つのEDI取引を有する、送信元と、前記EDIデータを前記バッチとして受信するインターフェースと、前記受信したEDIデータを、EDI標準にしたがって復号化することにより、前記複数のEDIドキュメントに含まれる前記EDI取引を識別し、前記EDIデータの前記バッチ内の前記複数のEDIドキュメントから、前記取引タイプにしたがって編成された、前記識別したEDI取引のEDIデータを含む1つの統合されたEDIドキュメントを定義するためのコンピュータ実行可能命令を実行するプロセッサとを備えたことを特徴とするシステム。前記統合化されたEDIドキュメントは、拡張可能マークアップ言語XMLドキュメントであることを特徴とする請求項8に記載のシステム。前記プロセッサは、前記統合化されたEDIドキュメントに含まれる前記EDI取引を、XMLタグによって構造化するようにさらに構成されており、前記XMLタグは、前記EDI取引の前記取引タイプを示していることを特徴とする請求項9に記載のシステム。前記統合化されたEDIドキュメントは、超スキーマを含んでおり、該超スキーマは、前記EDI取引が参照する複数のスキーマを表すことを特徴とする請求項8に記載のシステム。前記インターフェースは、前記複数のスキーマを前記プロセッサにより処理するように変換するためのランタイムスキーママップをさらに受信することを特徴とする請求項11に記載のシステム。前記プロセッサは、前記ランタイムスキーママップを適用して、前記複数のスキーマをランタイムに照合するように構成されていることを特徴とする請求項12に記載のシステム。前記プロセッサは、前記統合化されたEDIドキュメント内のEDI取引を、該EDI取引に含まれる1つまたは複数の情報にしたがってサブドキュメントとして編成するようにさらに構成されており、前記サブドキュメント内の前記EDI取引は、前記複数のEDIドキュメント内の前記EDI取引と相互に関連することを特徴とする請求項8に記載のシステム。電子データ交換EDI取引を変換するためのコンピュータ実行可能なコンポーネントを有する1つまたは複数のコンピュータ読み取り可能な媒体であって、前記コンピュータ実行可能なコンポーネントは、送信元からのEDIデータをバッチとして受信し、該受信したEDIデータを受信側に送信するためのインターフェースコンポーネントであって、前記EDIデータの前記バッチは、複数のEDIドキュメントを含み、該複数のEDIドキュメントの各々は、1つの取引タイプに対応する少なくとも1つのEDI取引を有する、インターフェースコンポーネントと、前記受信したEDIデータを、EDI標準にしたがって復号化することにより、前記複数のEDIドキュメントに含まれる前記EDI取引を識別するための識別コンポーネントと、前記EDIデータの前記バッチ内の前記複数のEDIドキュメントから、1つの統合化されたEDIドキュメントを定義するための変換コンポーネントであって、前記統合化されたEDIドキュメントは、前記取引タイプにしたがって編成された、前記識別したEDI取引を含む、変換コンポーネントとを備えたことを特徴とするコンピュータ読み取り可能な媒体。前記統合化されたEDIドキュメントは、拡張可能マークアップ言語XMLドキュメントであることを特徴とする請求項15に記載のコンピュータ読み取り可能な媒体。前記統合化されたEDIドキュメントに含まれる前記EDI取引を、XMLタグによって構造化するためのドキュメントコンポーネントをさらに備え、前記XMLタグは、前記EDI取引の前記取引タイプを示していることを特徴とする請求項16に記載のコンピュータ読み取り可能な媒体。前記ドキュメントコンポーネントは、前記統合化されたEDIドキュメント内のEDI取引を、該EDI取引に含まれる1つまたは複数の情報にしたがってサブドキュメントとしてさらに編成し、前記サブドキュメント内の前記EDI取引は、前記複数のEDIドキュメント内の前記EDI取引と相互に関連することを特徴とする請求項17に記載のコンピュータ読み取り可能な媒体。前記統合化されたEDIドキュメントは、超スキーマを含んでおり、該超スキーマは、前記EDI取引が参照する複数のスキーマを表すことを特徴とする請求項15に記載のコンピュータ読み取り可能な媒体。前記インターフェースコンポーネントは、前記複数のスキーマをランタイムにプロセッサにより処理するように変換するためのランタイムスキーママップをさらに受信することを特徴とする請求項15に記載のコンピュータ読み取り可能な媒体。EDIメッセージを解析および処理する際に、既存のシステムは、EDIデータを送信する。また、既存のシステムには、交換するときに、明確に記述された各ドキュメントにおけるフォーマットルールまたはスキーマが含まれる。たとえば、発注purchaseorder取引を表すEDIデータには、発注取引用のスキーマが含まれる。したがって、個々のEDI取引ドキュメントには、EDIデータと、その取引に固有のスキーマとが含まれている。こうした仕組みまたは構成によって、EDIデータの解析は容易になるが、これは静的であり、各取引ドキュメントのドキュメントサイズは増大する。さらに、含まれるスキーマは、共有することができない。すなわち、2つの発注取引ドキュメントAおよびBが存在する場合、たとえ各発注取引ドキュメントのスキーマが同一だったとしても、ドキュメントごとに発注スキーマを含める必要がある。また、EDI取引は有料であり、特に、行数またはドキュメント数、およびEDIデータの送信に必要な帯域幅に応じて課金される。事業体は、EDIを用いて、日常的に膨大な数の取引を送信するので、このようにスキーマ情報が重複して含まれる大量のEDI取引ドキュメントによって、冗長なスキーマ情報を保持するための無駄なコストが発生する。EDI取引ドキュメントが受信されると、送信先のアプリケーションは通常、このEDI取引ドキュメントをメモリ領域に記憶する。次いで、送信先のアプリケーションは、取引が受信されたことを示す受信確認応答receiptacknowledgementを送信元に送信する。その後、アプリケーションは、記憶されたEDI取引の有効性を検査して、取引ドキュメントに含まれるEDIデータが、該当する取引タイプのスキーマ用のフォーマットルールに準拠しているか否かを判定する。こうした有効性検査を実行している間、送信元たとえば、販売者または顧客は、取引データがフォーマットに準拠することを示す有効性確認応答を待つ必要がある。1つまたは複数の取引のフォーマットが適切でないと判定された場合、代替のEDI取引ドキュメントを再送信して処理する必要がある。こうした有効性検査の待機によって発生する遅延により、EDI取引の処理効率はさらに低下する。本発明の実施形態は、さまざまなEDI取引タイプを識別するネスト構造またはサブドキュメントを使用して複数のEDI取引ファイルを1つのEDIドキュメントに変換することにより、EDI取引の処理における既存のシステムのこうした欠点を克服する。さらに、本発明の態様によって、EDI取引がランタイムに処理されるときに、スキーマのインスタンスを使用できるようにすることにより、EDIドキュメントでスキーマが参照できるようになる。本発明の実施形態は、EDI取引が受信されたときに、取引タイプに関連付けられたスキーマを自動的に認識して、EDI取引を処理するという点で有効である。本発明の別の実施形態にしたがうと、EDI取引が受信されたときに、EDI取引の有効性が検査される。本発明のさらに別の実施形態では、複数のスキーマを表す、統合化されたメタスキーマunitarymeta-schemaが定義される。統合化されたメタスキーマが提供されると、エンドユーザは、スキーマのプロパティを変更することができる。この要約は、詳細な説明において以下でさらに記載するいくつかの概念を簡略化した形で紹介するために提供されたものである。この要約は、特許請求される主題事項の重要な特徴または本質的な特徴を示すものでも、特許請求される主題事項の範囲を決定するための助けとして使用するものでもない。その他の特徴については、一部は明らかであり、一部は本明細書の以下の部分で説明する。付録Aは、図10Aに示すXMLスキーマの全体を説明するものである。付録Bは、発注スキーマを表す、XMLフォーマットで記述された例示的な統合化されたメタスキーマを示している。すべての図面を通して、対応する参照番号は対応する要素を表している。図1は、EDI取引の処理の実装を示すブロック図である。図1に示すように、まず、送信元たとえば、ビジネスパートナ102は、一般的な通信ネットワーク108を介して、請求書invoice202を含めることができるEDIメッセージ106を、送信先104たとえば、企業の顧客に送信する。送信元102は、一般的な通信ネットワーク108を介して、スキーマおよびEDI取引データを含むEDIメッセージ106を、送信先104に送信する。一例では、送信コストまたは帯域幅コストを節約するために、EDIメッセージ106には、複数のEDI取引データがバッチとして含まれる。別の例では、一般的な通信ネットワーク108は、イントラネットなどの専用プライベートネットワークでもよいし、インターネットなどのパブリックネットワークでもよい。別の例では、パートナ間でのEDIメッセージの送信を円滑にするために、一般的な通信ネットワーク108には、FTP、HTTP、カーミットKermit、Xmodem、FrameDelay、EDIINT、3780Bisync登録商標など、1つまたは複数のネットワークプロトコルが含まれる。送信元102は、送信先104との接続セッションたとえば、セキュアソケット接続セッションをオープンすることにより、一般的な通信ネットワーク108を介して、EDIメッセージ106の送信を開始する。接続セッションがオープンになると、送信元102は、EDIメッセージ106を送信先104に送信する。送信先104におけるEDIトランスレータtranslatorシステムのセット110がEDIメッセージ106を受信すると、EDIトランスレータシステム110は、一般的な通信ネットワーク108を介して、EDIメッセージを受信したことを示す受信確認応答112を、送信元102に送信する。受信確認応答は、送信元102が接続セッションをクローズする前に送信元102に送信されるか、または返信されるのが一般的である。EDIメッセージ106が受信されると、EDI取引に関連付けられたEDIデータが、EDIトランスレータシステム110によって解析されて処理される。当業者にとっては周知であるように、EDI取引の解析および/または復号化には、さまざまなEDI標準、スキーマ仕様などを識別するための1つまたは複数のステップが含まれる。これを実行する際、EDIトランスレータシステム110は、解析または復号化したEDIデータを、ダウンストリームアプリケーションdownstreamapplication114に送信して、解析または復号化したEDIデータを処理する。たとえば、ダウンストリームアプリケーション114は、請求書を処理する会計アプリケーションであってもよいし、発注データを処理するソフトウェアであってもよい。このように、ダウンストリームアプリケーション114は、受信したEDIデータを解析および復号化した後で、スキーマに指定されたフォーマットルールに準拠しているか否かを判定することができる。受信したEDIデータがスキーマルールに準拠していた場合、ダウンストリームアプリケーション114は、有効性確認応答116を送信元102に送信する。一方、受信したEDIデータにエラーが含まれる場合、またはEDIデータが無効な場合、ダウンストリームアプリケーション114は、受信したEDIデータのエラーを示すエラー通知を、送信元に送信することができる。有効性確認応答116は通常、受信確認応答の送信後、遅延を伴って送信元102に送信される。他の実装では、解析したEDIデータは、データベースまたはデータストア図示せずに記憶され、有効性が検査されるまで待機する。したがって、送信元102は、送信先104によってEDIデータを適切に処理できることが確認されるまで、有効性確認応答116を待つよう頻繁に要求される。図2A~図2Cは、本発明の一実施形態にしたがう、電子データ交換EDIを使用した取引データの構造を示す図である。図2Aは、ANSIX12フォーマットを使用した請求書のEDI取引ドキュメント202の例を示している。この例では、請求書202には、機能グループfunctionalgroup204セクションなどの複数のセグメントまたは複数のセクションが含まれているX12EDI交換の構造218の概要については、図2Cを参照されたい。こうしたセグメントまたはセクションには、請求書202の追加の情報を含めることができる。たとえば、図2Cに示すように、サプライチェーンセクタでは、当業者にとっては周知であるように、機能グループ204内の情報または値は、交換セクションたとえば、交換制御ヘッダ内の情報または値に等しい。別の例では、機能グループ204内の情報または値には、比較的大規模な企業の事業単位または作業単位を識別する値または識別子が含まれる。また、請求書202には、企業の顧客の情報といった情報が記載されるヘッダ部分206も含まれている。この例では、ヘッダ部分206には、企業の顧客の名前ABCCompanyと、住所0887SixthStreet,SaintLouis,MO63101とが含まれている。一実施形態では、ヘッダ部分206には、有効性確認応答を受信するための送信先情報が含まれている以下の図8、図9A、および図9Bに関する説明を参照されたい。また、請求書202には、ループ210内に構成された1つまたは複数のデータセグメント212を示す詳細テーブルセクション208も含まれている。たとえば、ループ210には、意味的に関連するデータセグメントのグループが含まれている。当業者にはよく知られているように、これらのセグメントは、ANSIX12.6にしたがって、範囲が制限されてもよいし、制限されなくてもよい。EDI取引ドキュメントには、ANSIX12フォーマットまたはEDIFACTフォーマットにしたがって、本発明の範囲から逸脱することなく、追加のセグメントタイプ、セクション、および、それに対応する情報を含めることができる。たとえば、図2Bは、同一のEDIメッセージ106に含まれており、かつ送信先104にて処理される1つまたは複数の取引タイプを示している。請求書214および発注書216は、同じ顧客ABCCompanyに関連するため、請求書214および発注書216のEDI取引ドキュメントは、EDIメッセージ106に含まれている。関連する取引ドキュメントの追加のグループを、EDIメッセージ106として、交換に含めることもできる。一実施形態では、1つの送信先または1つの顧客に対するEDIドキュメントを、バッチとして送信することができる。EDI取引タイプの各々は、その取引タイプに関連付けられたスキーマに準拠する必要があることも理解されたい。たとえば、請求取引スキーマでは、特に販売者または購入者の名前を表す文字列の最大長または最小長に関する所定の制限を課すことができる。発注取引スキーマでは、小数点以下の最大桁数を指定することもできる。別の例では、さまざまな取引タイプに関するスキーマでは、特定のフィールドは必須であるが、別のフィールドはオプションであるように指定することもできる。既存の実装では、送信先104といった顧客にEDI取引を送信するときに、EDI取引ドキュメントに取引スキーマを含める。このような実装によってEDI取引の復号化は容易になるが、スキーマ設計者は、ビジネスパートナにEDI取引を送信する前に、かなりの時間をかけてスキーマの設計と設定とを行う必要がある。また、後にパートナ間の業務契約の変更に伴ってスキーマが変更された場合、スキーマの再設計が必要になる。したがって、本発明の実施形態では、取引タイプにしたがって1つまたは複数のEDI取引を編成するネスト構造またはサブドキュメントを使用してEDIメッセージを1つの統合されたEDIドキュメントに変換することにより、既存の実装のそのような欠点を克服する。また、EDIドキュメントには、取引タイプに関連付けられた複数のスキーマを表す超スキーマuber-schemaも含まれる。別の実施形態では、ランタイムスキーママップruntimeschemamapによって、送信先104において、複数のスキーマをランタイムに処理するように変換する。次に図3を参照すると、本発明の実施形態にしたがう、EDI取引を変換するシステム302のブロック図が示されている。システム302には、送信元304が含まれる。送信元304は、送信先306すなわち顧客と業務取引を行う販売者とすることができる。たとえば、送信元304は、コンピュータ機器を購入する企業顧客に大量の商品を販売する家電小売業者などの販売者であってもよい。別の例では、送信元304は、病院または薬局などのヘルスケア提供者とすることができ、送信元304は、請求を提出するため、または医療保険の相互運用性と責任に関する法律HIPAA:HealthInsurancePortabilityandAccountabilityActにしたがうために、医療保険会社または交換所clearinghouseにEDIデータを送信する。一実施形態では、送信元304および送信先306には、図12のコンピュータ130などの1つまたは複数のコンピューティングデバイスが含まれており、こうしたコンピューティングデバイスが、EDIドキュメントをバッチとして送信する。最初に、送信元304が、複数のEDIドキュメントを含むEDIメッセージ310を送信する。EDIドキュメントの各々には、取引タイプたとえば、請求、発注、支払勘定accountpayableなどに対応する少なくとも1つのEDI取引が含まれる。さらに図4Aを参照すると、本発明の実施形態にしたがってEDI取引を変換する方法の流れ図が示されている。送信元304が、送信先306と通信するために通信ネットワーク308上で接続セッションをオープンした後、送信元304は、送信先306のEDIエンジン312にEDIメッセージ310を送信する。一実施形態では、EDIエンジン312には、コンピュータ実行可能な命令、ルーチン、または機能を実行する1つまたは複数のコンピューティングデバイスたとえば、コンピュータ130が含まれている。402で、EDIエンジン312は、複数のEDIドキュメントを含むEDIメッセージ310を受信する。404で、EDIエンジン312は、複数のEDIドキュメントに含まれるEDI取引を識別する。上述したANSIX12の例を使用すると、EDIエンジン312は、図2Cに示したさまざまなデータヘッダおよびデータセグメントたとえば、ISA、GSなどを識別することにより、X12請求書の復号化または解析を行って、取引に含まれるEDIデータを判別する。別の実施形態では、EDIエンジン312はさらに、複数のEDIドキュメントに含まれるさまざまなスキーマも識別して、その取引タイプに固有のフォーマットルールを判別する。406で、EDIエンジン312は、複数のEDIドキュメントをバッチとして統合化したEDIドキュメント314を生成する。一例では、EDIエンジン312は、統合化したEDIドキュメント314を、XML構造マークアップタグ付きのXMLドキュメントとして生成する410。たとえば、各取引が1つのドキュメントとして編成される既存の実装とは異なり、本発明の実施形態では、複数のEDIドキュメント内のEDI取引を1つのXMLドキュメントとして編成する。このXMLドキュメントは、個々の取引セットを定義するだけでなく、セグメント、ループ、フィールド、デリミタなどを含めて、EDIデータのすべての特徴を取得することによって、交換を定義する。一例として、図6Aに、PO発注書などの、1つまたは複数のEDI取引を含む統合化された例示的なXMLドキュメントを示す。さらに別の実施形態では、統合化したEDIドキュメント314には、EDI取引によって参照される複数のスキーマを表す超スキーマが含まれる。たとえば、超スキーマは、EDI取引セットに含まれており、各EDI取引の機能グループおよびエンベロープセグメントenvelopesegments内に埋め込まれているか、または組み込まれている。したがって、エンドユーザは、EDIメッセージ310に含まれていると想定される取引セットごとに固有のスキーマを作成する必要がない。一例として、図6Bに、本発明の一実施形態にしたがって統合化されたEDIドキュメント314に含まれるXMLフォーマットの超スキーマのスクリーンショットを示す。このような設計では、統合化したEDIドキュメント314の交換により、それぞれがEDIドキュメント内の取引タイプに対応する1つまたは複数のスキーマを含める必要性が低減する。また、本発明の実施形態では、送信を行う前のスキーマの設計時間およびスキーマの開発時間も短縮される。別の実施形態では、図4Bの412で、EDIエンジン312は、ランタイムスキーママップまたはペイロードスキーマpayloadschemaを使用して、統合化されたEDIドキュメントを変換する。414で、EDIエンジン312は、統合化されたEDIドキュメント314に含まれるEDI取引を表すサブドキュメントまたはネスト構造を作成するさらなる説明は、表1および表2を参照されたい。代替実施形態では、統合化されたEDIドキュメント314は、ペイロードスキーマたとえば、ランタイムスキーママップによって変換され、さらに構造上変換されてもよい416。あるいは、統合化されたEDIドキュメント314は、構造上の変換を行わずに、ダウンストリームアプリケーション316に送信されて処理されてもよい418。420で、サブドキュメントまたはネスト構造を伴う統合化されたEDIドキュメント314は、ダウンストリームアプリケーション316に送信されて処理される。EDI取引を識別可能な構造によって定義して編成する統合化されたEDIドキュメント314を表すXML以外のマークアップタグ付きフォーマットを、本発明の範囲から逸脱することなく、使用できることを理解されたい。別の実施形態では、上述した本発明の態様を記憶可能なコンピュータ読み取り可能な媒体1102図11Aが提供される。たとえば、上述した1つまたは複数の動作を実行するEDIエンジン312には、インターフェースコンポーネント1104、識別コンポーネント1106、および変換コンポーネント1108を含めることができる。さらに、図4Aに示した方法を送信元304により実行することができるので、送信元304は、送信前に交換のサイズを低減できることも理解されたい。このように、統合化されたEDIドキュメント314のネスト構造またはサブドキュメントによって、行数が減少するため、行数にしたがって課金される場合、EDIデータの送信コストを削減することもできる。たとえば、表1は、統合化されたEDIドキュメント内でネスト構造をとる3つのEDI取引と、当該ネスト構造をとる3つのEDI取引の各々に対応する3つの取引の1つを含むオリジナルの3つのEDIドキュメントとを示している。業務において、ヘルスケアスポンサたとえば、雇用主Aは、支払人たとえば、ヘルスケア提供者BにEDIメッセージたとえば、HIPAA834ドキュメントを送信する必要があると仮定する。このような交換のスキーマでは、雇用主Aが、ヘルスケア受益者/受給者たとえば、従業員らおよび従業員らの扶養家族の利益の詳細を提示する必要がある。したがって、雇用主Aは一般に、スポンサおよび支払人の詳細情報を含める。このスポンサおよび支払人の詳細情報は、すべての受益者に共通であり、雇用主Aが提供する利益を受け取る従業員または扶養家族ごとに繰り返されることになる。既存のEDIの実装のように、数千人の従業員および扶養家族について同一のスポンサおよび支払人情報を繰り返すのではなく、本発明の実施形態では、ネスト構造を作成することによって、1つのEDIドキュメント内でループと同様のロジックを使用して、スポンサおよび支払人の詳細情報のコピーとともに、各メンバを作成できるようにする。図5Aは、本発明の実施形態にしたがうEDI取引のネストを示すブロック図である。たとえば、502で、送信元たとえば、送信元304から送信されたEDIメッセージたとえば、EDIメッセージ310が、送信先たとえば、送信先306にて受信される。504で、複数のEDI取引がネスト構造またはサブドキュメントとして含まれる統合化されたEDIドキュメントが生成される。一例では、エンベロープ/制御セグメントたとえば、ANSIX12フォーマットのISA/GS/GE/IEAセグメントが除去され、受信パイプラインによって取引セットST/SEが解析されて、取引セットごとに複数のXMLサブドキュメントが生成される。一実施形態では、複数のXMLサブドキュメントがメッセージボックスに格納される。506で、送信先の受信パイプラインが、受信した交換の有効性検査を実行し、適切な有効性確認応答を生成する図8、図9A、および図9Bを用いて詳細に説明する。一実施形態では、受信パイプラインはさらに、チェックサムおよび事業総計businesstotalsの更新も行う。上述したように、統合化されたEDIドキュメント314は、ダウンストリームアプリケーション316によって処理することができる。したがって、統合化されたEDIドキュメントは、送信ポートに送信され、508で、送信ポートは、EDI取引をEDIサブドキュメントとして送信する。一実施形態では、送信ポートに関連付けられた送信パイプラインは、XMLサブドキュメントをシリアライズしてserialize、セグメントの数が送信パイプラインにて更新されたn個の交換を送信する。一実施形態では、EDI交換が受信されると、その有効性が検査される。有効性検査でエラーがない場合、各取引セットは、そのスキーマにしたがって、XMLフォーマットに変換される。このようにして、EDI交換には、発注ドキュメントと請求ドキュメントとを含めることができる。発注書は、発注スキーマに準拠するXMLに変換される。同様に、請求書は、請求書XMLに変換される。図5Bは、EDI交換による例示的な発注書をXMLフォーマットで示している。図5Aで、この発注ドキュメントが送信側で処理される場合は、エンベロープセグメントの処理後に、EDIフォーマット514に変換される。図5Cは、図5BのXMLフォーマットから送信ポートによって生成される例示的なドキュメントを示している。一実施形態では、EDIフォーマット514には、2つのエンベロープセグメントすなわち、ISAで始まる行およびGSで始まる行が含まれる。同様に、EDIフォーマット514には、ドキュメントの終わりに2つのエンベロープセグメントGEおよびIEAが含まれる。図示されているように、STセグメントとSEセグメントとの間に含まれるデータは、オリジナルの取引セットのデータである。図5Bおよび図5Cに示した上述の例では、SE01の値矢印512を参照は14であり、送信ポートによって動的に計算される。EDIドキュメントをシリアライズする際に、EDIエンジンたとえば、EDIエンジン312の送信側は、取引セット内に存在するセグメント数を追跡する。この値に基づいて、SE01の値が決定される。送信元304が、統合化されたEDIドキュメント314を生成して複数のEDIドキュメントのEDI取引を含める場合、本発明の実施形態には、含まれるEDI取引をネスト構造で編成することが含まれる。別の例では、本発明の実施形態により、統合化されたEDIドキュメント314を送信元から受信する送信先306は、後方互換性を提供するために、すなわち、ドキュメントごとに単一の取引を含むEDIドキュメント以外を処理することができないダウンストリームアプリケーション316に対応するために、統合化されたEDIドキュメント314から複数のEDIドキュメントを復元することができる。本発明の代替実施形態では、ネスト構造のEDI取引を伴う統合化されたEDIドキュメントが、オリジナルの複数のEDIドキュメントを追跡するか、オリジナルの複数のEDIドキュメントと相関させることができる。たとえば、表2は、統合化されたEDIドキュメント314から複数のEDIドキュメントにEDI取引を変換する方法を示している。表2に示す例では、ネスト構造をとるEDI取引の処理は、予め定められたSubDocumentCreationBreakPointたとえば、親ドキュメント内で子ドキュメントの始まる位置を示すマーカ\を識別することによって開始して、複数のサブドキュメントを生成する。表2によると、列A1に示された統合化されたEDIドキュメントは、スキーマ内のBBループにて定義されるサブドキュメント作成のブレークポイントbreakにしたがって、3つの取引、すなわち、BB11~BB21、BB12、およびBB13~BB23に分割することができる。列A2では、取引セットBB11~BB21が独立したドキュメントに編成または分割され太字のテキストで示されている、列A3では、取引BB12が2番目のドキュメントに編成される下線付きのテキストで示されている。同様に、取引セットBB13~BB23は、ダウンストリームアプリケーション316によって処理される3番目のEDIドキュメントに編成される斜体のテキストで示されている。本発明の実施形態では、複数のEDIドキュメントに含まれるEDI取引を、統合化されたEDIドキュメント314に変換することにより、送信先306または送信元304は、各EDIドキュメントに含まれる複数のスキーマを、変換中に効率的に識別できるようにする。さらに、本発明の少なくとも1つの態様では、送信先306が、統合化されたEDIドキュメントを変換した後に、有効性確認応答を生成し、接続セッションが引き続きオープンである間に、送信元304に返信できるようにしている。すなわち、本発明の態様では、送信先306は、EDI取引を受信している間に複数のスキーマを自動的に識別してEDI取引の有効性を検査するように構成されている。次に、図7A~図7Dを参照すると、本発明の実施形態にしたがって、EDIスキーマを自動的に識別することを表す一連のスクリーンショットが示されている。図7Aは、ANSIX12による一般的な発注スキーマを示している。スキーマは、当該スキーマに関連付けられたDocTypeによって識別される。DocTypeは、ネームスペースおよびルートノード名などの、設定項目configurationitemsの組合せである。図7Aに示すように、このスクリーンショットの左の列702は、スキーマの階層構造を表している。この例では、左の列702はスキーマ構造を示している。中央の列704はスキーマのXMLコードを示している。右の列706は、スキーマに含まれるプロパティまたはターゲットネームスペースを示している。一実施形態では、DocTypeは、X12フォーマットにおいて、DocType=TargetNamespace‘’RootNodeNameである。これについては、以下で詳細に説明する。図7Aに示すX12スキーマについて説明するが、EDIFACTスキーマなどの他のスキーマフォーマットも、本発明の範囲から逸脱することなく、使用できることを理解されたい。DocTypeのルートノードは、X12フォーマット、X12_{Version}_{TsId}の1つを有している。この例では、ボックス708によって示されるように、設定項目rootnodeの値は、X12_00401_850である。すなわち、00401は、ドキュメントのバージョンであり、ランタイム処理中に設定またはインスタンスを決定する動的な情報である。同様に、850は、TsId、すなわち、処理中のスキーマの取引識別子IDであり、入力インスタンスから決定される。この例では、取引ID850は、ボックス710によって示されるように、発注を表している。また、ターゲットネームスペースは、右の列706にボックス712によって示されている。別の例では、EDIFACTフォーマットのスキーマを復号化または識別するために、現在、EDIFACTスキーマのフォーマットは、Efact_{Version}_{Tsid}である。すなわち、すべてのEDIFACTスキーマは、Efactで始まるルートノード名を有し、VersionおよびTsidの定義は、X12フォーマットの場合と同一である。一例として図3を使用すると、送信先306が送信元304からEDIドキュメントを受信したときに、EDI取引には、取引ID850とドキュメントとを含めることができる。しかし、バージョン情報またはターゲットネームスペース情報は、ランタイムに決定される。こうした設定項目の値は、別々のレベルで設定されてもよい。このように、EDI標準たとえば、X12またはEDIFACTにしたがったルールを適用して、対応する取引タイプたとえば、発注、請求などにしたがってEDI取引を復号化した後、EDIエンジン312は、復号化したEDI取引に含まれる設定項目を識別する。一実施形態では、EDIエンジン312は、パートナレベルおよび送信アプリケーションレベル、グローバルレベル、パイプラインレベル、またはデフォルトレベルなどの、1つまたは複数の設定レベルから設定項目を識別する。たとえば、図7Bは、パーティpartyレベルの設定における設定項目を表すスクリーンショットを示している。この例では、図7Aに示した上述のパートナの取引ID850は、上述のターゲットネームスペースおよびバージョン情報を使用するように設定されている。ボックス714によって示されるように、デフォルトのフラグまたはパラメータがオンであるため、その他のすべてのドキュメントタイプについてデフォルト値が使用される。別の例では、業務取引パートナ間で締結された業務契約に基づいて、別の取引パートナが、パーティレベルの設定における他の特定の設定項目を設定することもできる。設定項目の値を静的に決定する代わりに、本発明の実施形態では、スキーマを自動的に識別するときに、取引パートナにより1つまたは複数の設定レベルから設定された特定の値を決定することによって、設定項目の値を識別する。一実施形態では、パーティレベルの設定における設定項目の値は、送信側IDと取引IDとの特定の組合せにより、図7AのDocTypeに示した値とは異なる値に設定されてもよい。たとえば、X12では、各送信側IDは企業内の所定の部門を表していてもよい。したがって、ある企業における1つの送信側IDは、ハードウェア製品部門を意味し、別の送信側IDは、同一企業内のソフトウェア製品部門を意味することもできる。このようにして、本発明の実施形態では、こうした異なる設定が認識され、それに応じてスキーマが識別される。その結果、1つの企業が発行した同一の発注は、異なるスキーマ識別プロセスにより処理されることになり、たとえば、設定項目の値にしたがって、統合化されたEDIドキュメント314内に、適切であり、かつ異なるEDIデータが、XMLで生成されてもよい。また、特定のビジネスパートナによって、本発明の範囲から逸脱することなく、1つまたは複数の追加の設定項目を設定または指定できることも理解されたい。たとえば、1つのパートナが最小限の設定を行い、別のパートナが、そのパーティレベルの設定において詳細な設定項目を定義することもできる。次に図7Cを参照すると、EDIFACTスキーマとそのパーティレベルの設定とを表示したスクリーンショットが示されている。この例では、X12スキーマとは異なり、送信側アプリケーションIDオプション716のUNG2.1および718のUNG2.2など、バージョン720UNG8、および取引セットID722の特定の組合せに基づいて、ターゲットネームスペースを設定することができる。すなわち、1つの請求EDIドキュメントに対して、それぞれ一意のアプリケーションIDを伴う複数の設定が可能である。この場合では、ランタイムに特定のアプリケーションに一致するターゲットネームスペースが使用される。送信側アプリケーションIDが設定されていない場合では、送信側アプリケーションIDの値は、同一の取引IDを有する既存のレコードたとえば、ログファイルに含まれるいずれかの値と照合される。一致するものが複数存在する場合には、デフォルトのターゲットネームスペースが使用され、曖昧性があるときには、適切なデフォルト値が使用されることが保証される。図7Dは、X12スキーマのグローバルレベルの設定を示すスクリーンショットである。この例では、取引パートナがターゲットネームスペースまたはバージョンなどの設定項目を設定していないため、グローバルレベルの設定による設定項目の値が使用されることになる。この例では、ボックス724が、バージョンおよびターゲットネームスペースに値が設定されていないことを示している。したがって、設定項目の値は、ランタイムには変更されない。グローバルレベルにおいて欠落したmissing設定項目のいくつかが設定されていない場合は、パイプラインレベルの設定またはランタイムレベルの設定における設定項目の値が使用されることになる。したがって、ターゲットネームスペースがグローバルレベルで設定されていない場合、パイプラインレベルの設定における値が使用されることになる。一実施形態では、パイプラインレベルの設定における値は、ユーザが設定することもできる。別の実施形態において、図11Bは、本発明の態様を記憶できるコンピュータ読み取り可能な媒体1110を示している。たとえば、インターフェースコンポーネント1112は、送信元からEDIドキュメントをバッチとして受信する。ここで、各EDIドキュメントには、取引タイプに対応する少なくとも1つのEDI取引が含まれる。取引コンポーネント1114は、EDI標準たとえば、X12またはEDIFACTにしたがうルールを適用することにより、対応する取引タイプにしたがってEDI取引を復号化する。設定コンポーネント1116は、復号化したEDI取引に含まれるEDI取引の各々について、1つまたは複数の設定項目の値を識別する。スキーマコンポーネント1118は、設定項目の値に基づいて、1つまたは複数のスキーマタイプを判別する。代替実施形態では、前述の各セクションで説明した設定項目の値を、ランタイムに変更することができる。したがって、EDIエンジン312がEDIドキュメントを処理した後すなわち、スキーマを自動的に識別した後に、取引タイプ、ターゲットネームスペース、バージョンの値を変更することができる。このような実施形態では、変更は、これから処理されることになる後続のドキュメントに対して反映される。本発明のこうした動的な実装により、送信先306のユーザは、EDIドキュメントが送信元304から送信される前のスキーマ設計/設定を行う間ではなく、ランタイムに値を設定することができる。動作中に、スキーマを自動的に識別することにより、EDIパートナは、EDIドキュメントの処理をストリームライン処理streamlineprocessingすることができる。すべてのパートナおよびすべてのドキュメントタイプに対して受信接続および送信接続を設定しなければならない既存の実装とは異なり、EDIエンジン312では、ランタイムに設定項目の値を識別して判別する形で自動的にスキーマを識別できるので、EDIビジネスパートナは、EDIデータを柔軟に処理することができるようになる。少なくとも本発明の別の態様には、EDIデータを受信したときに、有効性確認応答を生成することが含まれていることについて再考する。図8Aは、こうした機能を示す流れ図である。802で、EDIメッセージたとえば、EDIメッセージ310が、送信元たとえば、送信元304から送信先たとえば、送信先306へ送信される。804で、EDI取引を含むEDIメッセージが送信先で受信される。次いで、806で、EDIメッセージが適切な受信者に宛てられたものであるか否かを判定することにより、EDIメッセージの送信が、有効か否かが判定される。EDIメッセージの送信が無効と判定された場合、EDIメッセージの処理が保留され、交換失敗確認応答interchangefailureacknowledgementが生成される808。EDIメッセージの交換が有効と判定された場合、次に、EDI取引のグループにエラーが含まれるか否かが判定される810。グループにエラーが含まれる場合、EDI取引のグループの処理が保留され、機能失敗確認応答functionalfailureacknowledgementが生成される812。たとえば、EDI仕様では、グループレベルおよび取引セットレベルで検出可能な複数のエラーを定義することができる。表3に、X12EDI交換に適用可能な一般的なエラーのリストを示す。たとえば、EDIエンジン312は、EDIメッセージ内の行/セグメントGSの6番目の値を識別することによって、エラーコード4、すなわち、機能グループのヘッダ内とトレーラ内のグループ制御番号が一致しないというエラーを確認する。図8Bで、532に示すGSの行の6番目の値は9であるボックス528によって示されている。EDI取引の有効性を検査する際に、本発明の実施形態では、534に示すGEの行の2番目の値に同一の値が存在するか否かを判定する。図8Bに示すように、534に示すGEの行の2番目の値は10であるボックス530によって示されている。このような不一致により、このEDIメッセージにはエラーがあることが確認される。別の例では、GS-GEセグメント間の取引セットを識別することにより、エラーコード5、すなわち、含まれる取引セットの数が実際のカウントと一致しないが検出される。図8Bに示すように、1つのGS-GEセグメントが存在するのに対して、GEの行の最初の値は02であり、2つの取引セットが存在することを示している。したがって、この機能グループはエラーになる。しかし、グループ内にエラーが存在しないと判定された場合は、次に814で、X12フォーマットまたはEDIFACTフォーマットにしたがうフォーマットルールを評価し、かつEDI取引に含まれるスキーマにしたがうルールを評価することにより、各EDI取引が、有効か否かが判定される。EDI取引が無効と判定された場合、EDI取引の処理が保留され、816で、機能失敗確認応答が生成される。たとえば、表4に、一般的な取引エラーのリストを示す。一例として図8Bを使用すると、EDIエンジンたとえば、EDIエンジン312は、STとSEとの間のセグメント行の数を評価することにより、エラーコード4、すなわち、含まれるセグメントの数が実際のカウントと一致しないを識別する。この例では、数は12であるのに対して、SEの行の最初の値は14である。したがって、この取引セットにはエラーが存在し、こうしたエラーコードを機能失敗確認応答に含めることができる。一実施形態では、EDIエンジンたとえば、EDIエンジン312は、EDI取引のさまざまなエラー条件またはルールを参照できるか、またはそうした情報を有することができる。EDIエンジン312は、EDIドキュメントを処理している間に、いずれのEDIフォーマットルールにも違反しないことを確認する。違反がある場合には、EDIエンジン312は、交換または機能レベルの確認応答の形で、適切にレポートする。一方、EDI取引が有効な場合は、送信先のEDIエンジン312が、EDI取引の処理に進む818。820で、EDI取引が有効であることを示す有効性確認応答が生成される。一実施形態では、EDIメッセージ、EDIグループ、および/またはEDI取引が受信されて有効性が確認された場合は、EDIエンジン312は、統合化した有効性確認応答をまとめて生成することができる。別の実施形態では、EDIメッセージ、EDIグループ、および/またはEDI取引が受信されて有効性が確認されるとほぼ同時に、EDIエンジンは、統合した有効性確認応答を生成する。824で、生成された有効性確認応答が、送信元に返送され、826で、送信元が、有効性確認応答を受信する。一実施形態では、送信元は、接続セッションをオープンしてEDIメッセージを送信し、有効性確認応答を受信した後に同じ接続セッションをクローズする。したがって、図3の矢印318によって示されるように、有効性検査のプロセスは、EDI取引のランタイムに、またはEDI取引の受信中に処理されるため、ドキュメントの有効性検査中に、データベースまたはデータストアへのアクセスも、ディスクI/Oも、発生しない。さらに別の実施形態では、有効性検査のプロセスは、ランタイムにプラグインハンドラによって拡張することもできる。代替実施形態では、EDIメッセージ/取引が受信されたときに、さまざまなタイプの有効性確認応答が生成され、別々の場所に送信されてもよいこうした場所の情報は、ヘッダ部分106において検出可能である。このように、本発明の実施形態では、1つまたは複数の段階たとえば、交換の1つの態様における有効性を検査した後で、有効性確認応答を生成して送信するか、または単一の段階で、統合化した確認応答を生成して送信する。さらに別の実施形態では、図3の矢印320によって示されるように、こうした確認応答は、同じソケット接続セッションまたは新たなソケット接続セッションを用いて、さまざまな送信先に配信するよう設定することができる。たとえば、スキーマまたはフォーマットルールの指定により、発注書の有効性確認応答が、企業内の顧客サービス部門に送信されるよう設定され、請求書の有効性確認応答が、同じ企業内の経理部門に送信されるよう設定されていると想定する。本発明の態様では、新たな接続セッションをオープンすることにより、それぞれの確認応答を適切な送信先に送信することができる。図9Aは、X12フォーマットのEDI取引に関する有効性確認応答を示しており、図9Bは、EDIFACTフォーマットのEDI取引に関する有効性確認応答を示している。別の実施形態において、図11Cは、本発明の態様を記憶できるコンピュータ読み取り可能な媒体1120を示している。たとえば、インターフェースコンポーネント1122、確認応答コンポーネント1124、および有効性検査コンポーネント1126は、図8Aに示した1つまたは複数のステップを実行するEDIエンジン312に組み込まれて、統合されてもよい。本発明のさらなる態様では、エンドユーザにEDIスキーマ開発者と同等の知識を要求することなく、EDIスキーマの変更が可能となる。たとえば、ある企業内で新たな部門が開設されたものの、その部門に適用するカスタマイズされたEDIスキーマまたはルールはまだ存在していないと仮定する。本発明の実施形態により、EDIスキーマ開発者に対してその新たな部門に固有のEDIスキーマの設計を要求するのではなく、エンドユーザが変更できるようにスキーマのプロパティを提示する形で、すべてのスキーマを表現するメタスキーマが定義される。図10Aは、本発明の実施形態にしたがって、複数のEDIスキーマを変更するための統合化されたメタスキーマを示すスクリーンショットである。ウィンドウペイン1002において、統合化されたメタスキーマの構造が、エンドユーザに示される。エンドユーザがプロパティMaxOccursを囲む破線によって示されるを強調表示すると、対応するプロパティコードセクションが、ウィンドウペイン1004において直ちに強調表示され、エンドユーザは、プロパティの値を変更することができる。一実施形態では、図10Aに示すように、本発明の態様を具現化するユーザインターフェースUIが、エンドユーザに提供される。付録Aは、図10Aに示すXMLスキーマの全体を説明するものである。図10Bは、本発明の実施形態にしたがって、統合化されたメタスキーマを使用して複数のEDIスキーマを変更する方法を示す流れ図である。1006で、複数のEDIスキーマ内のデータを復号化することにより、複数のEDIスキーマを表す統合化された構造が識別される。一例では、図11Dのデータ構造1128などの統合化された構造が、以下の1つまたは複数のデータを取得することにより、複数のEDIスキーマを表す。1.各EDIスキーマは、名前付きのルート要素rootelementから構成される。2.ルート要素は、ループまたはセグメントとすることができるデータブロックの繰り返しから構成される。3.各ループは以下の構造を有している。a.Name-ループの名前b.Block-データ要素の集合c.MinOccurs-出現回数の最小値d.MaxOccurs-出現回数の最大値4.各セグメントは、さまざまなプロパティを有している。a.Name-セグメントの名前b.TagId-セグメントのタグIDc.MinOccurs-出現回数の最小値d.MaxOccurs-出現回数の最大値e.データ要素のリスト5.各データ要素は、要素の集合から構成され、要素の集合の各々は、複合要素でも単一要素でもよい。6.各単一要素はさまざまなプロパティを有している。a.Name-要素の名前b.MinOccurs-出現回数の最小値c.MaxOccurs-出現回数の最大値d.MinLength-データ長の最小値e.MaxLength-データ長の最大値f.DataType-データ型。使用可能な値は、A、AN、ID、R、N、Date、Time-各EDIデータ型につき1つg.AllowedValues-使用可能な値のセット。要素の型がIDの場合にのみ適用可能。たとえば、データ構造1128には、第1のデータフィールド1130が含まれている。この第1のデータフィールド1130には、複数のEDIスキーマの各々におけるルート要素に関連付けられたルートデータが含まれている。データ構造にはまた、1つまたは複数の第2のデータフィールド1132も含まれている。この第2のデータフィールド1132には、複数のEDIスキーマの各々における1つまたは複数のデータブロックを表すデータが含まれている。1つまたは複数の第2のデータフィールドに含まれるデータは、第1のデータフィールド1130に含まれるルートデータの関数functionとして定義される。1008では、統合化された構造に含まれるプロパティが決定される。こうしたプロパティは、複数のEDIスキーマの特性を定義するものである。たとえば、ルート要素のプロパティ値が、purchaseorderの場合、統合化された構造の特性が、図7Aに示すような発注スキーマに対応することを示している。プロパティ値を伴う統合化された構造によって、統合化されたメタスキーマは、定義済みの特性、および統合化された構造に応じて、ユーザ用に定義される1010。定義されたメタスキーマは、複数のEDIスキーマに対応する。図10Aに示すように、1012で、定義されたメタスキーマに含まれる決定されたプロパティがエンドユーザに提供され、エンドユーザは、複数のEDIスキーマの各々における特性を変更することができる。付録Bは、以下の構造を含む発注スキーマを表す、XMLフォーマットで記述された例示的な統合化されたメタスキーマを示している。1.PurchaseOrderDetailセグメント2.LineItemおよびShippingAddressセグメントから構成されるループ3.Notesセグメント図12は、コンピュータ130の形態をとる汎用コンピューティングデバイスの一例を示している。本発明の一実施形態では、コンピュータ130などのコンピュータは、本明細書で示して説明した他の図面においても使用するのに適している。コンピュータ130は、1つまたは複数のプロセッサ、あるいは処理ユニット132と、システムメモリ134とを備えている。図示された実施形態では、システムバス136は、システムメモリ134を含むさまざまなシステムコンポーネントをプロセッサ132に接続している。システムバス136は、さまざまなバスアーキテクチャのいずれかを使用した、メモリバスまたはメモリコントローラ、周辺バス、アクセラレータグラフィックポート、およびプロセッサバスまたはローカルバスを含む様々なタイプのバス構造の任意の1つまたは複数を表している。こうしたバスアーキテクチャには、たとえば、ISAIndustryStandardArchitectureバス、MCAMicroChannelArchitectureバス、EISAEnhancedISAバス、VESAVideoElectronicsStandardsAssociationローカルバス、およびメザニンバスとも呼ばれるPCIPeripheralComponentInterconnectバスが含まれるが、これらに限定されるものではない。コンピュータ130は通常、少なくとも何らかの形態のコンピュータ読み取り可能な媒体を備えている。コンピュータ読み取り可能な媒体には、揮発性媒体および不揮発性媒体の両方、ならびに取り外し可能な媒体および取り外し不可能な媒体の両方を含めることができ、コンピュータ読み取り可能な媒体は、コンピュータ130によってアクセス可能な任意の使用可能な媒体とすることができる。たとえば、コンピュータ読み取り可能な媒体には、コンピュータ記憶媒体および通信媒体が含まれるが、これらに限定されるものではない。コンピュータ記憶媒体には、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、またはその他のデータなどの情報を記憶する任意の方法または技術を用いて実装された、揮発性媒体および不揮発性媒体、ならびに取り外し可能な媒体および取り外し不可能な媒体が含まれる。たとえば、コンピュータ記憶媒体には、RAM、ROM、EEPROM、フラッシュメモリ、もしくはその他のメモリ技術、CDROM、デジタル多用途ディスクDVD、もしくはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、もしくはその他の磁気記憶装置、または必要な情報を記憶でき、かつコンピュータ130がアクセス可能なその他の任意の媒体が含まれる。通信媒体は一般に、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、またはその他のデータなどを、搬送波やその他の搬送メカニズムのような変調されたデータ信号内に具現化したものであり、通信媒体には任意の情報伝達媒体が含まれる。当業者にとっては周知であるが、変調されたデータ信号は、信号内の情報を符号化するようにその1つまたは複数の特性が設定または変更された信号である。通信媒体の例として、有線ネットワークや直接配線接続などの有線媒体と、音響、RF、赤外線、またはその他の無線媒体などの無線媒体とがある。前述した媒体の任意の組合せも、コンピュータ読み取り可能な媒体の範囲に含まれる。システムメモリ134には、取り外し可能なメモリおよび/または取り外し不可能なメモリ、揮発性メモリおよび/または不揮発性メモリの形態をとるコンピュータ記憶媒体が含まれる。図示された実施形態では、システムメモリ134には、ROM138とRAM140とが含まれる。起動時などにコンピュータ130内の要素間の情報転送を支援する基本ルーチンを含む基本入出力システムBIOS142は通常、ROM138に記憶されている。RAM140には通常、処理ユニット132が直ちにアクセスでき、かつ/または処理ユニット132が現在操作しているデータおよび/またはプログラムモジュールが記憶される。たとえば、図12には、オペレーティングシステム144、アプリケーションプログラム146、その他のプログラムモジュール148、およびプログラムデータ150が示されているが、これらに限定されるものではない。コンピュータ130には、その他の取り外し可能/取り外し不可能な揮発性/不揮発性のコンピュータ記憶媒体を含めてもよい。例えば、図12には、取り外し不可能な不揮発性の磁気媒体に対して読み書きを行うハードディスクドライブ154が示されている。図12にはさらに、取り外し可能な不揮発性の磁気ディスク158に対して読み書きを行う磁気ディスクドライブ156、CDROMや他の光媒体などの取り外し可能な不揮発性の光ディスク162に対して読み書きを行う光ディスクドライブ160も示されている。例示的な動作環境で使用できるその他の取り外し可能/取り外し不可能な揮発性/不揮発性のコンピュータ記憶媒体には、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートRAM、ソリッドステートROMなどが含まれるが、これらに限定されるものではない。ハードディスクドライブ154、磁気ディスクドライブ156、および光ディスクドライブ160は通常、インターフェース166などの不揮発性メモリインターフェースを介して、システムバス136に接続される。図12に示して前述したドライブまたはその他の大容量記憶装置、およびこれらに関連するコンピュータ記憶媒体は、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、およびその他のデータのための記憶領域を、コンピュータ130に提供する。たとえば、図12において、ハードディスクドライブ154は、オペレーティングシステム170、アプリケーションプログラム172、その他のプログラムモジュール174、およびプログラムデータ176を記憶するものとして示されている。こうしたコンポーネントは、オペレーティングシステム144、アプリケーションプログラム146、その他のプログラムモジュール148、およびプログラムデータ150と同じであってもよいし、異なっていてもよいことに留意されたい。ここでは、オペレーティングシステム170、アプリケーションプログラム172、その他のプログラムモジュール174、およびプログラムデータ176には異なる番号を付けて、少なくとも異なるコピーであることを示している。ユーザは、キーボード180やポインティングデバイス182たとえば、マウス、トラックボール、ペン、またはタッチパッドなどの入力装置またはユーザインターフェース選択装置を介して、コンピュータ130にコマンドおよび情報を入力することができる。他の入力装置図示せずには、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信用アンテナsatellitedish、スキャナなどを含めることができる。これらの入力装置および他の入力装置は、システムバス136に接続されたユーザ入力インターフェース184を介して処理ユニット132に接続されているが、パラレルポート、ゲームポート、またはUSBなどの他のインターフェースやバス構造を介して接続されてもよい。モニタ188または他のタイプの表示装置も、ビデオインターフェース190などのインターフェースを介してシステムバス136に接続されている。コンピュータには、モニタ188に加えて、出力周辺インターフェース図示せずを介して接続できるプリンタやスピーカなどの出力周辺装置図示せずが備えられていることが多い。コンピュータ130は、リモートコンピュータ194などの1つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク環境において動作することができる。リモートコンピュータ194は、パーソナルコンピュータ、サーバ、ルータ、ネットワークPC、ピアデバイス、または他の一般的なネットワークノードとすることができ、通常は、コンピュータ130に関連して上述した要素の多くまたはすべてを備えている。図12に示す論理接続には、ローカルエリアネットワークLAN196とワイドエリアネットワークWAN198とが含まれるが、その他のネットワークを含めてもよい。LAN196および/またはWAN198は、有線ネットワーク、無線ネットワーク、およびそれらの組合せなどとすることができる。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、およびグローバルなコンピュータネットワークたとえば、インターネットにおいて一般的である。コンピュータ130は、ローカルエリアネットワーキング環境で使用される場合、ネットワークインターフェースまたはネットワークアダプタ186を介して、LAN196に接続される。コンピュータ130は一般に、ワイドエリアネットワーキング環境で使用される場合、インターネットなどのWAN198を介して通信を確立するためのモデム178またはその他の手段を備えている。内蔵型でも外付け型でもよいモデム178は、ユーザ入力インターフェース184または他の適切な機構を介して、システムバス136に接続される。ネットワーク環境では、コンピュータ130またはその一部に関連して説明したプログラムモジュールを、リモートメモリ記憶装置図示せずに記憶することができる。たとえば、図12には、メモリ装置に存在するものとしてリモートアプリケーションプログラム192を示したが、これに限定されるものではない。図示されたネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立する他の手段を使用してもよい。一般に、コンピュータ130のデータプロセッサは、コンピュータに備えられたさまざまなコンピュータ読み取り可能な記憶媒体に、さまざまな時間において記憶された命令によって、プログラミングされている。プログラムおよびオペレーティングシステムは、一般的には、たとえば、フロッピー登録商標ディスクやCD-ROMによって配布される。さらに、それら命令が、こうしたフロッピー登録商標ディスクやCD-ROMから、コンピュータの2次メモリにインストールまたはロードされる。実行時に、それら命令の少なくとも一部が、コンピュータの1次電子メモリにロードされる。上記およびその他のさまざまなタイプのコンピュータ記憶媒体に、以下でマイクロプロセッサまたはその他のデータプロセッサに関連して説明するステップを実装する命令またはプログラムが記憶されている場合、本明細書で説明した本発明の態様には、こうした媒体が含まれる。さらに、本明細書で説明した方法および技術にしたがってプログラミングされている場合、本発明の態様には、こうしたコンピュータ自体も含まれる。例示の目的上、オペレーティングシステムなどの、プログラムおよびその他の実行可能なプログラムコンポーネントは、本明細書では別個のブロックとして示されている。しかし、こうしたプログラムおよびコンポーネントは、さまざまな時間において、コンピュータのさまざまな記憶コンポーネントに記憶され、コンピュータの1つまたは複数のデータプロセッサによって実行されることが理解されよう。コンピュータ130を含む例示的なコンピューティングシステム環境に関して説明したが、本発明の実施形態は、他のさまざまな汎用または専用のコンピューティングシステム環境またはコンピューティングシステム構成とともに動作可能である。こうしたコンピューティングシステム環境は、本発明のいかなる態様についても、その使用または機能の範囲に関していかなる限定を示すものではない。さらに、こうしたコンピューティングシステム環境は、例示的な動作環境において図示されたコンポーネントの任意の1つ、またはそれらコンポーネントの組合せに関して、いかなる依存関係または要件を有するものとして解釈されるべきではない。本発明の態様とともに使用するのに適した周知のコンピューティングシステム、コンピューティング環境、および/またはコンピューティング構成の例には、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家庭用電子機器、携帯電話、ネットワークPC、ミニコンピュータ、メインフレームコンピュータ、前述の任意のシステムまたはデバイスを含む分散コンピューティング環境などが含まれるが、これらに限定されるものではない。本発明の実施形態は、1つまたは複数のコンピュータまたは他のデバイスによって実行される、プログラムモジュールなどのコンピュータ実行可能命令といった一般的なコンテキストにおいて説明することができる。一般に、プログラムモジュールには、特定のタスクを実行するか、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、およびデータ構造が含まれるが、これらに限定されるものではない。本発明の態様は、通信ネットワークを介して接続されるリモート処理デバイスによってタスクが実行される分散コンピューティング環境においても実施することができる。分散コンピューティング環境では、メモリ記憶装置を含むローカルのコンピュータ記憶媒体とリモートのコンピュータ記憶媒体との両方に、プログラムモジュールを配置することができる。インターフェースは、たとえば、Java登録商標2PlatformEnterpriseEditionJ2EE、COM、またはDCOMなどの密結合tightlycoupledによる同期の実装とすることができる。代替として、またはこれに加えて、インターフェースは、たとえば、SOAPを使用したウェブサービスなどの疎結合による非同期の実装であってもよい。一般に、インターフェースには、密結合、疎結合、同期、および非同期といった特性の任意の組合せが含まれる。さらに、インターフェースは、標準プロトコル、専用プロトコル、または標準プロトコルと専用プロトコルとの任意の組合せにしたがってもよい。本明細書で説明したすべてのインターフェースは、単一のインターフェースの一部であってもよいし、別々のインターフェースとして実装されてもよいし、それらの任意の組合せとして実装されてもよい。インターフェースは、ローカルまたはリモートで実行して、機能を提供してもよい。さらに、このインターフェースが備える機能は、本明細書で図示した機能または説明した機能より多くてもよいし、少なくてもよい。コンピュータ130は、動作中に、図面に示した命令などのコンピュータ実行可能命令を実行して、本発明の態様を実現する。本明細書で図示または説明した本発明の実施形態における動作の実行順序または実現順序は、特に指定されない限り、本質的なものではない。すなわち、特に指定されない限り、動作は、任意の順序で実行できる。また、本発明の実施形態には、本明細書で開示した動作より多くの動作を含めてもよいし、本明細書で開示した動作より少ない動作を含めてもよい。たとえば、特定の動作の実行または実現が、別の動作より前、別の動作と同時、または別の動作より後であっても、本発明の態様の範囲内にあることが意図されている。本発明の実施形態は、コンピュータ実行可能命令を使用して実装することができる。コンピュータ実行可能命令は、1つまたは複数のコンピュータ実行可能なコンポーネントまたはコンピュータ実行可能なモジュールに構成することができる。本発明の態様は、こうしたコンポーネントまたはモジュールを任意の数だけ任意に構成して実装することができる。たとえば、本発明の態様は、図面に示して本明細書で説明した特定のコンピュータ実行可能命令、特定のコンポーネント、または特定のモジュールに限定されるものではない。本発明の他の実施形態には、本明細書で図示または説明した機能より多いか、または少ない機能を備える別のコンピュータ実行可能命令またはコンピュータ実行可能なコンポーネントが含まれてもよい。本発明の態様またはその実施形態の要素を説明した際に、1つのa,an、そのthe,said、および前記the,saidという冠詞は、1つまたは複数の要素を意味するものと意図されている。用語備えるcomprising、含むincluding、および有するhavingは、包括的であるものとして意図されており、列挙した要素以外の要素が追加されてもよいことを意味している。本発明の態様の範囲を逸脱することなく、前述の構成、製品、および方法に対してさまざまな変更を加えることができるので、前述の説明に含まれる事項、および添付の図面に示される内容は、すべて例示的なものとして理解すべきであり、限定的な意味として解釈すべきではない。付録Aセクション1:XMLフォーマットにおいてEDIスキーマを表すメタスキーマ付録Bセクション2:メタスキーマの統合化された構造を使用した発注スキーマの例"