JP2012128853A - Ｘｍｌドキュメントを処理するためのシステム及び方法 - Google Patents

Abstract

【課題】ＸＭＬドキュメントを処理するための改善されたシステム及び方法を提供する。
【解決手段】ＳｔＡＸのようなプルベースのストリーミング・パーサ１０４を、ＸＭＬＢｅａｎｓ１０５のようなＸＭＬオブジェクト・バインディング・フレームワークと組み合わせることにより、メモリ制限を被ることなく任意のサイズのＸＭＬドキュメント１０７を処理することができる。加えて、ＳｔＡＸ及びＸＭＬＢｅａｎｓからアプリケーション・コードを隔離するフレームワーク１０２を提供し、アプリケーション・データ・オブジェクトは、ＳｔＡＸ及びＸＭＬＢｅａｎｓを意識する必要はない。コードは、これにより、より容易に維持することができ、且つアプリケーション１０１の動作に悪影響を及ぼすことなくスワップし、強化し、又は他の方法で修正することができる。
【選択図】図１

Description

本発明は、拡張マークアップ言語（Ｅｘｔｅｎｄｅｄ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）（ＸＭＬ）ドキュメントを処理するためのシステム及び方法に関し、より詳細には、メモリ制限に関わることなく任意のサイズのこうしたドキュメントを生成し、パーシングし、且つ処理することを可能にするためのフレームワークに関する。

ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）は、ドキュメントを電子的にエンコードするために広く用いられているルールのセットである。ＸＭＬデータにアクセスするために多くのプログラミング・インターフェースが利用可能であり、ソフトウェアのデプロイメント及び使用のための多くのＸＭＬベースのフォーマットが存在する。ＸＭＬ仕様が存在するが、ＸＭＬドキュメントを、それらが異なるソフトウェア・アプリケーションによって理解されるように、１つのフォーマットから別のフォーマットに変換することがしばしば必要である。こうした変換は、例えば、ＸＭＬ仕様の異なるバージョンを有する異種のシステムを統合するときに必要とされる場合がある。

ＸＭＬパーサは、ＸＭＬドキュメントを種々の方法で処理する。一般に、こうしたパーサは、ＸＭＬにアクセスするために、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を採用する。

ＸＭＬ処理のための既存のＡＰＩは、以下のカテゴリのうちの１つに入る傾向がある。
●シリアル（すなわちストリーム指向）ＡＰＩ（例えば、Ｓｉｍｐｌｅ ＡＰＩ ｆｏｒ ＸＭＬ（ＳＡＸ）
●ドキュメント・オブジェクト・モデル（ＤＯＭ）のようなプログラミング言語からアクセス可能なツリー・トラバーサルＡＰＩ
●ＸＭＬドキュメントとプログラミング言語オブジェクトとの間の自動トランスレーションを提供する、ＸＭＬデータ・バインディング
●ＸＳＬＴ及びＸＱｕｅｒｙのような宣言型変換言語

ＳＡＸのようなシリアルＡＰＩにおいて、データは、イベント駆動型プッシュモデルを用いてシリアル方式で処理される。ＸＭＬドキュメントのメモリ内表現は構築されない。ＸＭＬドキュメントは、あらゆる所与の時点で一部のみがメモリの中にロードされる状態で、直線的にトラバースされる。パーサがＸＭＬステートメントに遭遇する際に、パーサは、ソフトウェア・アプリケーションによって取り込まれるイベントを生成する。したがって、パーサは、同時にＸＭＬドキュメント全体へのアクセスを有さない。

こうしたシリアルＡＰＩを用いるアプリケーションは、ＸＭＬドキュメントのパーシングの間にイベントが発火されるときに、パーサによってコールされる多数のコールバックメソッドを定義する。

あらゆる所与の時点でＸＭＬドキュメント全体をメモリ内に保持する必要性を回避するために、シリアルＡＰＩは、比較的経済的なメモリ・フットプリントを維持しながら、任意に大きいＸＭＬドキュメントを処理することを可能にする。シリアルＡＰＩのメモリ・フットプリントは、ＸＭＬファイルの最大深さ（ＸＭＬツリーの最大深さ）と、ＸＭＬドキュメント全体を保持するのに要求されるメモリよりもしばしば小さい、単一のＸＭＬ要素上のＸＭＬ属性に格納された最大データとに基づいている。

しかしながら、或るタイプのデータ変換に対しては、特に、こうした変換が、ＸＭＬドキュメント全体が同時に利用可能となることを要求する場合には、シリアル手法は効果的ではない場合がある（言い換えれば、パーサは、シリアル方式で変換を行うことができない）。加えて、パーサは、一般に、ＸＭＬドキュメント要素の間の親／子関係を維持することができない。シリアルＡＰＩを用いるアプリケーションは、すべての発火したイベントを取り扱うためにハンドラ（コールバック）を提供する必要がある。シリアルＡＰＩは、したがって、アプリケーションがこうした親／子関係を維持すること、及びＸＭＬドキュメント全体が利用可能となることを要求する変換を行うことに対して、より大きな負担をかける。このアプリケーションに対するより大きな負担は、シリアルＡＰＩをそれらの有用性に限りのあるものにする。

ツリー・トラバーサル及びデータ・バインディングＡＰＩは、こうした問題を回避する可能性がある。例えば、ドキュメント・オブジェクト・モデル（ＤＯＭ）は、ＸＭＬをノード・オブジェクトのツリー階層として表し、ノードと下位階層にアクセスするためにインターフェースの標準化されたセットを提供する。ＸＭＬパーシングは、ツリーをトラバースすることによって行うことができる。ＤＯＭによって提供されるインターフェースは、より容易に用いることができるが、それらは一般に、ツリー全体がメモリ内に残ることを要求する。メモリ内ツリーは、それが表すＸＭＬドキュメントよりもかなり大きいスペースを必要とし、したがって、非常に大きいＸＭＬドキュメントに対しては実用的ではない場合がある。

同様に、ＸＭＬＢｅａｎｓ、Ｃａｓｔｏｒ、及びＪａｖａ（登録商標） Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ ＸＭＬ Ｂｉｎｄｉｎｇ（ＪＡＸＢ）のようなＸＭＬオブジェクト・バインディング・ツールは、ＸＭＬドキュメントを表わすオブジェクトモデル全体をメモリ内に保つ。

例えば、ＸＭＬＢｅａｎｓは、Ｊａｖａ（登録商標）とＸＭＬとをバインディングするフレームワークであり、Ｊａｖａ（登録商標）開発者がＸＭＬ又はＸＭＬ処理を知る必要なしにＸＭＬデータにアクセスし且つ処理することを可能にする。ＸＭＬＢｅａｎｓは、ＸＭＬドキュメントをＪａｖａ（登録商標）オブジェクトの形態でアプリケーションに提示することによって、Ｊａｖａ（登録商標）アプリケーションからＸＭＬドキュメントにアクセスするのを簡単にする。逆に言えば、これは、これらのＪａｖａ（登録商標）オブジェクトをＸＭＬドキュメントに戻るように変換するために必要なツールを提供する。

ＸＭＬＢｅａｎｓは、全ＸＭＬスキーマのサポートを有し、且つ等価なＪａｖａ（登録商標）クラスへのスキーマ・マッピング及びタイピング構築（ｔｙｐｉｎｇ ｃｏｎｓｔｒｕｃｔｓ）をできるだけ自然に提供する。ＸＭＬＢｅａｎｓは、ＸＭＬスキーマを用いて、ＸＭＬインスタンス・データにアクセスし及びＸＭＬインスタンス・データを修正するために用いることができるＪａｖａ（登録商標）インターフェース及びクラスをコンパイルする。

ＸＭＬＢｅａｎｓは、したがって、オリジナルの本来のＸＭＬ構造を保つＸＭＬデータのＪａｖａ（登録商標）オブジェクトベースのビューを提供する。これはまた、ＸＭＬドキュメントの一体性を保つ。ＸＭＬインスタンス・ドキュメント全体が総括して取り扱われる。ＸＭＬデータは、ＸＭＬとしてメモリ内に格納される。これは、ドキュメントの順番が保たれること、並びに、オリジナルの要素が余白を満たすことを意味する。

ＸＭＬＢｅａｎｓは、ドキュメントがメモリ内で利用可能である、ＸＭＬプログラミング状況のための、非常に有用なツールとすることができる。しかしながら、こうしたメモリ内モデルは、ＤＯＭ又は他のツリー・トラバーサル技術に関して上記で説明されたものと同じ制限に悩まされ、アプリケーションは、大きいＸＭＬドキュメントを処理しながらメモリ不足で走る可能性がある。

したがって、上記で説明されたツリー・トラバーサル手法又はデータ・バインディング手法のいずれかにおいて、処理することができるＸＭＬドキュメントのサイズは、利用可能なメモリの量によって制限される。加えて、こうした実装において、アプリケーション・コードには、しばしば必然的にＸＭＬオブジェクト・バインディング・ツール・コードが散りばめられる。ビジネス論理コードとＸＭＬツール・コードとの間の分離の欠如は、こうしたシステムを使用する又は維持するのを難しいものにする及び／又は混乱させることがある。

ＸＳＬＴ（ＸＳＬ変換）及びＸＱｕｅｒｙのような宣言型変換言語もまた、ＸＭＬドキュメントを変換することができる。しかしながら、こうした言語は、能力に限りがある。例えば、こうしたシステムにおいて、ＸＭＬドキュメントは、普通は、ＤＯＭによって表され、したがってＤＯＭの制限を受け継ぐ。そのうえ、ＸＭＬデータのオブジェクト表現は存在せず、ＸＳＬＴは、データを１つのフォーマットから別のフォーマットに変換するためにのみ用いられる。

別の手法は、Ｓｔｒｅａｍｉｎｇ ＡＰＩ ｆｏｒ ＸＭＬ（ＳｔＡＸ）を用いるものである。ＳｔＡＸは、それぞれシリアルＡＰＩ及びＤＯＭによって与えられるイベントベースのモデルとツリーベースのモデルとの間の妥協策として動作する。ＳｔＡＸメタファにおいて、プログラムの入口点は、ドキュメント内の点を表すカーソルである。アプリケーションは、パーサを駆動して、これがそれを必要とする場合に情報をプルするようにドキュメントを通してカーソルを本質的に動かす。これは、ドキュメント内のロケーションのトラックを保つのに必要な場合にアプリケーションがイベント間で状態を維持することを要求する、データをアプリケーションにプッシュするイベントベースのＡＰＩ（ＳＡＸのような）とは対照的なものである。

ＳＡＸと同様に、ＳｔＡＸは、任意に大きいサイズのＸＭＬドキュメントを処理することができながら、なお制御はパーサではなくアプリケーションと共に依然として残る。パーサがデータの次のチャンクの準備ができたときにアプリケーションに伝えるのではなく、アプリケーションがパーサに該アプリケーションが受信することを望むときにデータの次のチャンクを入手するように伝える。そのうえ、ＳｔＡＸは、既存のＸＭＬドキュメントを読み出すことができ、且つまた、如何なるサイズ制限もなしに新しいＸＭＬドキュメントを作成することができる。ＳＡＸは、一方向のパーサであり、新しいＸＭＬドキュメントを生成するために用いることはできず、一方、ＳｔＡＸは、双方向のＡＰＩである。

ＳｔＡＸは、したがって、大きいドキュメントを一度に一つのセクションずつ処理するために良好に働き、ドキュメントの最初から最後まで順次の方式で本質的に動く。しかしながら、ＳｔＡＸは、アプリケーションがドキュメントの広く分離された部分に同時に且つ潜在的に予測できない順序でアクセスする必要があるときには、良いソリューションではない。

必要とされるのは、したがって、アプリケーションがパーシングの低レベルの詳細に関与することを要求することなく、ドキュメントの異なる部分へのランダムアクセスを許可しながら、シリアルＡＰＩの利点を提供する、ＸＭＬ処理システム及び方法である。さらに必要とされるのは、ＤＯＭのような上記で説明されたツリー・トラバーサル方法において見出されるように厳しいメモリ制限を被らない技術である。さらに必要とされるのは、従来技術の方法の制限及び欠点を回避するＸＭＬパーシング・スキームである。

種々の実施形態において、本発明は、ＳｔＡＸのようなプルベースのストリーミング・パーサをＸＭＬＢｅａｎｓのようなＸＭＬオブジェクト・バインディング・フレームワークと組み合わせることによって、ＸＭＬドキュメントを処理するための改善されたシステム及び方法を提供する。このように、本発明は、メモリ制限を被ることなく任意のサイズのＸＭＬドキュメントを処理することができる。

加えて、本発明の種々の実施形態は、ＳｔＡＸ及びＸＭＬＢｅａｎｓからアプリケーション・コードを隔離するフレームワークを提供する。アプリケーション・データ・オブジェクトは、ＳｔＡＸ及びＸＭＬＢｅａｎｓを意識する必要はない。コードは、これにより、より容易に維持することができ、ＸＭＬオブジェクト・バインディング・フレームワーク（ＸＭＬＢｅａｎｓ）と組み合わせたＸＭＬパーサ（ＳｔＡＸ）の使用は、コードがアプリケーションの動作に悪影響を及ぼすことなくスワップされ、強化され、又は他の方法で修正されることを可能にする。

種々の実施形態において、本発明のシステム及び方法はまた、以下の特色及び利点を提供する。
●それらを特定用途向けハンドラによって取り扱うことができるように、アプリケーションへの確認エラーメッセージのハンドリングの構成可能な（Ｃｏｎｆｉｇｕｒａｂｌｅ）スキーマ確認及びデリゲーション
●ＸＭＬスキーマ定義（ＸＭＬ Ｓｃｈｅｍａ Ｄｅｆｉｎｉｔｉｏｎ）（ＸＳＤ）確認に失敗したセグメントの構成可能なスキップ／包含
●ＸＳＤ確認に失敗したレコードを識別する一助とするためのＸＳＤエラーメッセージの構成可能なカスタマイゼーション
●ＸＭＬファイルのＸＰａｔｈを介したフラットファイルへの構成可能な変換
●アプリケーション・データ・オブジェクトからのＸＭＬの増分的生成（ｉｎｃｒｅｍｅｎｔａｌ ｇｅｎｅｒａｔｉｏｎ）
●対応するアプリケーション・データ・オブジェクトを提供しながらＸＭＬセグメントをシリアルに抽出し且つ処理すること

ＳｔＡＸのようなプルベースのストリーミング・パーサとＸＭＬＢｅａｎｓのようなＸＭＬオブジェクト・バインディング・フレームワークとの組合せは、プログラマが低レベルのＸＭＬ処理ではなくＪａｖａ（登録商標）オブジェクトに対処することができるように、等価なＪａｖａ（登録商標）インターフェース／クラスへのスキーマ・マッピングを容易にしながら、本発明のＸＭＬパーサがあらゆるサイズのＸＭＬドキュメント上で動作することを可能にする。ＸＭＬドキュメントは、これにより、アプリケーションによって必要とされる場合にセグメントで処理することができる。ＸＭＬドキュメントから一度に一つのセグメントが抽出され、ＸＭＬＢｅａｎｓは、抽出されたセグメントをオブジェクトにロードするのに用いられる。逆に言えば、ＸＭＬドキュメントは、ＸＭＬＢｅａｎｓオブジェクトからＸＭＬセグメントを生成し、生成されたＸＭＬを、ＳｔＡＸを用いてストリームすることによって作成することができる。このように、あらゆるサイズのＸＭＬドキュメントを増加的に生成することができる。

一実施形態において、アプリケーション・データ・オブジェクトは、ＸＭＬＢｅａｎｓオブジェクトとアプリケーション・データ・オブジェクトとの間のマッピングを提供するために別個のトランスレーション層を提供することによって、ＳｔＡＸ及びＸＭＬＢｅａｎｓコードから隔離される。ＸＭＬＢｅａｎｓ関連のコードは、したがって、これがトランスレーション層内にのみ収容されることになるため、アプリケーションの他の部分に増殖しない。ゆえに、ＸＭＬＢｅａｎｓに精通する開発者は、トランスレーション層に集中することができ、一方、アプリケーション開発者は、ＳｔＡＸ又はＸＭＬＢｅａｎｓを絶えず理解する必要なしに、ビジネス論理部の実装に集中することができる。

付属の図面は、本発明の幾つかの実施形態を例証し、且つ、説明と共に、本発明の原理を解説するのに役立つ。図面に示された特定の実施形態は単なる例示的なものであって、本発明の範囲を限定することを意図されるものではないことを当業者は認識するであろう。

一実施形態に係る本発明を実施するためのアーキテクチャの例を描いたブロック図である。 一実施形態に係るＸＭＬドキュメントを処理するための方法を描いたイベント・トレース・ダイヤグラムである。 別の実施形態に係るＸＭＬドキュメントを処理するための方法を描いたイベント・トレース・ダイヤグラムである。 別の実施形態に係るＸＭＬドキュメントを処理するための方法を描いたイベント・トレース・ダイヤグラムである。 一実施形態に係るＸＭＬドキュメントを生成するための方法を描いたイベント・トレース・ダイヤグラムである。 一実施形態に係るＸＭＬドキュメントを生成するための方法を描いたイベント・トレース・ダイヤグラムである。 一実施形態に係るＸＭＬドキュメントをフラットファイルに変換するための方法を描いたイベント・トレース・ダイヤグラムである。 一実施形態に係るＸＭＬドキュメントをフラットファイルに変換するための方法を描いたイベント・トレース・ダイヤグラムである。 一実施形態に係るＸＭＬドキュメントを処理するための方法の概要を描いた流れ図である。 一実施形態に係るＸＭＬドキュメントを生成するための方法の概要を描いた流れ図である。 一実施形態に係るプロデューサ・クラスのためのクラス・ダイアグラムである。 一実施形態に係る消費者クラスのためのクラス・ダイアグラムである。

システム・アーキテクチャ
ここで図１を参照すると、一実施形態に係る本発明を実施するためのアーキテクチャの例を描いたブロック図が示されている。ＸＭＬパーシング・システム１００は、フレームワーク１０２、コンフィギュレータ１０３、ＳｔＡＸパーサ１０４、ＸＭＬＢｅａｎｓ１０５、及びトランスレーション層１０６を含む。ＸＭＬドキュメント１０７は、例えば、本発明の他のコンポーネントに対してローカルであってもよいし又はリモートであってもよいデータストア１０８のようなあらゆるソースから来ることができる。アプリケーション１０１は、ＸＭＬドキュメント１０７からのデータを要求するあらゆるソフトウェア・アプリケーションである。フレームワーク１０２は、ＸＭＬドキュメント１０７の生成並びに既存のＸＭＬドキュメント１０７からのデータの抽出及びパーシングを制御するための機能性モジュールである。フレームワークは、ＸＭＬドキュメント１０７のストリームされたパーシングのためのＳｔＡＸパーサ１０４と、アプリケーション・コードを生ＸＭＬから隔離するオブジェクト・バインディング・フレームワークを実装するためのＸＭＬＢｅａｎｓ１０５とを含む本発明の技術を実装するために、他のコンポーネントを採用し、且つこれと対話する。トランスレーション層１０６は、ＸＭＬＢｅａｎｓオブジェクトとアプリケーション・データ・オブジェクトとの間のマッピングを提供するように、ＸＭＬＢｅａｎｓオブジェクトからドメイン・オブジェクトを生成する。コンフィギュレータ１０３は、ＸＭＬの構造、トランスレータ・クラス、無効なレコードの包含／排除、ＸＳＤ確認を行うかどうか、ＸＭＬとフラットファイルとの変換構成などについての情報をフレームワーク１０３に提供する。

図１に示された種々の機能性モジュールは、別個のコンピューティング・エンティティ上で走るソフトウェアとして実装することができ、又はそれらは、あらゆる所望の構成で組み合わされてもよい。それらは、あらゆる数のハードウェアデバイスにわたって分散された様式で実装されてもよい。機能性モジュールの間での通信は、ＴＣＰ／ＩＰ及びＨＴＴＰのような公知のネットワーク・プロトコルを用いて、あらゆる公知のデジタル通信媒体上で行われてもよい。図１における及び別途本明細書に記載された機能性モジュールの特定の配置は、本発明の一実施形態の例証となることを意図され、本発明の範囲をいかなる方法によっても制限すると考えられるべきではない。

本発明の技術によれば、ＸＭＬパーシング・システム１００は、メモリ制限を被ることなく、任意のサイズのＸＭＬドキュメントの処理を容易にし、アプリケーション・データ・オブジェクトは、ＸＭＬＢｅａｎｓオブジェクトとアプリケーション・データ・オブジェクトとの間のマッピングを提供するために別個のトランスレーション層１０６を提供することによって、ＳｔＡＸ及びＸＭＬＢｅａｎｓコードから隔離される。

一実施形態において、システム１００は、アプリケーション１０１がフレームワーク１０２からのデータを必要とされるときにプルベースのパラダイムで要求するように、アプリケーション１０１をそれによって制御下におくことができる、機構を提供する。加えて、一実施形態において、システム１００は、プログラマが低レベルのＸＭＬ処理ではなくＪａｖａ（登録商標）オブジェクトに対処することができるように、等価なＪａｖａ（登録商標）インターフェース／クラスへのスキーマ・マッピングを容易にしながら、システム１００があらゆるサイズのＸＭＬドキュメント上で動作することを可能にするために、オブジェクト・バインディング・フレームワーク（ＸＭＬＢｅａｎｓ１０５のような）を採用する。

一実施形態において、アプリケーション１０１からの要求に応答して、フレームワーク１０２は、要求を満たすのに必要とされる場合にＸＭＬドキュメント１０７の一部を抽出する。抽出されたＸＭＬ部分は、ＸＭＬＢｅａｎｓ１０５に渡され、ＸＭＬＢｅａｎｓ１０５は、該部分のメモリ内モデルを生成し、且つこれをアプリケーション１０１に提示するためにフレームワーク１０２に戻す。このように、メモリ内でＸＭＬドキュメント全体１０７を表わす必要性が回避される。

一実施形態において、トランスレーション層１０６は、ＸＭＬＢｅａｎｓ１０５によって生成されたメモリ内モデルを、これがアプリケーション１０１によって理解されることが可能なドメイン・オブジェクトの形態であるようにトランスレートする。例えば、アプリケーションが、ファーストネーム、ラストネーム、アドレスなどを含むがそのデータを表わすＸＭＬが異なるフォーマットを有する、ｅｍｐｌｏｙｅｅオブジェクトを要求する場合、トランスレーション層１０６は、必要とされるトランスレーションを行う。

動作方法
本発明の技術によれば、少なくとも３種類の動作、すなわち、ＸＭＬセグメント及びサブセグメントに対応しているアプリケーション・データ・オブジェクトを得るためにＸＭＬドキュメントを処理すること、アプリケーション・データからＸＭＬドキュメントを生成すること、及びＸＭＬドキュメントをフラットファイルに変換すること、が利用可能である。

ここで図５を参照すると、一実施形態に係るＸＭＬドキュメントを処理するための方法の概要を描いた流れ図が示されている。アプリケーション１０１は、データ・オブジェクトを要求する５０２。フレームワーク１０２は、ＳｔＡＸパーサ１０４からデータ・チャンクを要求し且つ受信する５０３。例えば、アプリケーション１０１がｅｍｐｌｏｙｅｅを表わす要求されたデータを有する場合、ＳｔＡＸパーサ１０４からのデータ・チャンクは、ｅｍｐｌｏｙｅｅを表わすデータの次のチャンクであってもよい。フレームワーク１０２は、次いで、データ・チャンクをトランスレーション層１０６に渡し５０４、トランスレーション層１０６が変換を行い、且つＸＭＬＢｅａｎｓフォーマットで等価なオブジェクトツリーを戻す５０５。フレームワーク１０２がオブジェクトツリーを受信すると、フレームワーク１０２は、トランスレーション層１０６をコールして、オブジェクトをアプリケーション１０１が理解できるフォーマットに変換する５０６。トランスレーション層１０６は、結果が、ＸＭＬ低レベルＡＰＩ、ＸＭＬＢｅａｎｓオブジェクト、及びアプリケーションが関係しない他のアーチファクトのないものであるように、オブジェクトツリーをこうしたフォーマットにトランスレートする。

ここで図６を参照すると、一実施形態に係るＸＭＬドキュメントを生成するための方法の概要を描いた流れ図が示されている。アプリケーション１０１は、データ・オブジェクトをフレームワーク１０２に渡す。フレームワーク１０２は、トランスレーション層１０６をコールして、ＸＭＬＢｅａｎｓオブジェクトへのトランスレーションを行う。トランスレーションが行われると、フレームワーク１０２は、ＸＭＬＢｅａｎｓオブジェクトを用いて、等価なＸＭＬを抽出する６０３。フレームワーク１０２は、次いで、ＸＭＬをデータストア１０８に書き込む６０５。一実施形態において、ステップ６０５は、新しいＸＭＬドキュメントの作成の開始、又は以前に開始された既存のＸＭＬドキュメントへのＸＭＬの追記を含む。この様式、個別的な（ｐｉｅｃｅｍｅａｌ）様式、又はストリーミングの様式で、ＸＭＬドキュメントの作成が容易にされる。

一実施形態において、フレームワーク１０２は、指定されたメモリ限界に達するとすぐにＸＭＬの書き込みを行う。ＳｔＡＸパーサ１０４は、すべてのサブセグメントが書き込まれるときにＸＭＬのどの部分が書き込まれるべきか及びどの部分が書き込まれることになるメモリ内に保たれるべきかを判定するのに用いられる。例えば、以下のＸＭＬが生成されることになると想定する。

これは、「ｅｍｐｌｏｙｅｅｓ」セグメント内で各「ｅｍｐｌｏｙｅｅ」セグメントを増加的に生成することによって達成される。一実施形態において、ＸＭＬを生成するために以下のステップが行われる。
●１）最初に「ｅｍｐｌｏｙｅｅｓ」セグメントを生成するが、そのエンドタグ（＜／ｅｍｐｌｏｙｅｅｓ＞）は書き込まない。生成されたセグメントをメモリ内に保持する。フレームワーク１０２は、ＸＭＬをＳｔＡＸパーサ１０４に渡し、且つＳｔＡＸパーサ１０４にＸＭＬをオープニング・タグ及びエンディング・タグのような個々のタグに分割するように頼む。フレームワーク１０２は、次いで、エンディング・タグ以外のすべてのタグを書き込む。ここで、フレームワーク１０２は、ＸＭＬセグメント内の個々のタグを識別するためにＳｔＡＸパーサ１０４を利用している。
●２）「ｅｍｐｌｏｙｅｅ」要素の付加を続ける。フレームワーク１０２は、ｅｍｐｌｏｙｅｅデータに対応しているＸＭＬの追記を続ける。
●３）アプリケーション１０１がすべての「ｅｍｐｌｏｙｅｅ」要素が付加されていることを示すと、エンドタグ＜／ｅｍｐｌｏｙｅｅｓ＞を書き込む。

一実施形態において、本発明のシステムはまた、種々のタイプのドキュメント変換を行うことができる。例えば、ＸＭＬドキュメントをフラットファイルに変換することは時々有用であり、こうした変換は、ＸＭＬをアップロードすることができない場合があるコンポーネント（ＳＱＬ^＊Ｌｏａｄｅｒのような）との関連において動作するときの、データファイルの大量アップロードのために用いられてもよい。ドキュメント変換を行うときに、フラットファイルを生成するときにオリジナルのＸＭＬドキュメントの異なる部分からのデータを得ることが時々必要な場合がある。各データ・チャンクは、一般に、結果として得られるフラットファイルにおけるライン（又はラインの数）に対応する。しかしながら、ラインをポピュレートするためのデータは、別のチャンク、例えば異なるソース（又はソースの組合せ）から得る必要がある場合があるチャンクから来る場合がある。一実施形態において、コンフィギュレータ１０３は、フラットファイルのラインを生成するのに必要とされるこれらのデータ片を取り出し、且つフラットファイルのラインを生成するのに必要とされる限りにわたってメモリ内に保持することができるように、他のデータ・チャンクの送信元を識別する最初のデータ・チャンクを解釈する。処理されているデータ・チャンクによってクロスリファレンスされるデータ要素は、これにより必要とされる場合に取り出すことができる。このように、コンフィギュレータ１０３は、メモリ使用量を管理可能な量に依然として保ちながら、必要なデータ要素が取り出され且つ提示されることを保証する。一実施形態において、フラットファイルにおけるラインは、データのソースを指定する。

例えば、フラットファイルを生成する際に該当する情報を得るためにパートナーの（すなわちデータの補助ソース）情報が必要とされると想定する。ＸＭＬドキュメントからの最初のデータ・チャンクは、パートナーを指定してもよい。パートナーの識別は、他のデータ・チャンクを処理するための付加的な情報を得ることに該当する。したがって、フレームワークは、フラットファイルの生成を容易にするように、他のデータ・チャンクを処理しながらパートナー名をメモリ内に維持する。コンフィギュレータ１０３は、どのデータ要素がメモリ内に維持されるべきか及びそれらが処理された後でどれを廃棄することができるかを判定するのに必要とされる情報をフレームワーク１０２に提供する。

一実施形態において、コンフィギュレータ１０３は、ＸＰａｔｈドキュメントを用いてこうした情報を指定する。ＸＰａｔｈドキュメントは、どのデータ項目がクロスリファレンスであるかを示し、且つどのデータ・チャンクが提示されることになるどのデータを要求するかをさらに示す。ＸＰａｔｈ、ＸＭＬＰａｔｈ言語は、ＸＭＬドキュメントからノードを選択するための周知のクエリ言語である。この情報が与えられると、フレームワーク１０２は、クロスリファレンスを必要とされる限りにわたってメモリ内に保持し、且つもはや必要とされないこれらのアイテムを廃棄することができる。ＸＰａｔｈドキュメントは、１つのＸＭＬタイプから別のＸＭＬタイプへと変化してもよい。

一実施形態において、クロスリファレンスがもはや必要とされなくなると、例えばメモリを解放する必要がある場合に、ドキュメント変換がまだ完了していない場合であっても、それらは廃棄されてもよい。別の実施形態において、クロスリファレンスは、ドキュメント変換が完了するまで保持される。さらに別の実施形態において、もはや必要とされないクロスリファレンスは、それらが後で利用可能にされてもよいように、ディスク又は他の記憶装置にスワップ・アウトされる。

ＸＭＬドキュメントの処理
一実施形態において、本発明のシステムは、或る動作（クライアント要求をサービスすることのような）を行う際にアプリケーション１０１によって使用可能なアプリケーション・ドメイン・オブジェクトを生成するために、ＸＭＬドキュメント１０７を処理することができる。ＸＭＬドキュメント１０７は、例えば、どこにドキュメントが行くべきか及びどこからドキュメントが来るべきかを示す「ｔｏ」タグ及び「ｆｒｏｍ」タグを含む、多くの異なる種類の情報を収容することができる。ｅｍｐｌｏｙｅｅ情報を収容するＸＭＬドキュメントの例は以下の通りである。

一実施形態において、アプリケーション・ドメイン・オブジェクトは、アプリケーション１００（上記の例に示された＜ｅｍｐｌｏｙｅｅ＞キーのような）によって渡されるキーに基づいて生成される。キーは、コンフィギュレータ１０３によって用いられる構成ファイルを介して対応するＸＭＬセグメントにマップすることができる。

ＳｔＡＸパーサ１０４は、アプリケーション１０１によってパスインされる各セグメント名に対応しているセグメントを抽出する。ＸＭＬＢｅａｎｓ１０５は、抽出されたＸＭＬセグメントを用いて、対応するＸＭＬＢｅａｎｓオブジェクトを生成する。フレームワーク１０２は、生成されたＸＭＬＢｅａｎｓオブジェクト上でＸＳＤ確認を行い、確認エラーは、さらなる処理のために特定用途向けエラー・ハンドラにデリゲートされる。

一実施形態において、ＸＳＤ確認に失敗する事例では、（無効なＸＭＬセグメントを含むようにフレームワーク１０２が構成されない限り）同じキーをもつ次のセグメントがフレームワーク１０２によってフェッチされる。このプロセスは、有効なセグメントが見つけ出されるまで、又は次のセグメントの始まりが検出されるまで、若しくはＸＭＬドキュメント全体１０７が尽くされる（ｅｘｈａｕｓｔｅｄ）まで繰り返される。

一実施形態において、フレームワーク１０２は、アプリケーション・データ・オブジェクトの作成をＸＭＬＢｅａｎｓオブジェクトからトランスレーション層１０６にデリゲートする。結果として得られたアプリケーション・データ・オブジェクトがアプリケーション１０１に戻される。

一実施形態において、本発明のシステムは、メモリ制限に直面することなく任意のサイズのＸＭＬドキュメント１０７を処理することができる。アプリケーション１０１は、アプリケーション１０１が、増分的なシリアルな様式で各サブセグメントに対するデータを得ることができるように、そのサブセグメントのいずれの包含もなしにセグメントに収容されたデータに対応しているアプリケーション・データ・オブジェクトを得ることができる。一実施形態において、これは、ＳｅｇｍｅｎｔＣｕｒｓｏｒクラスのインスタンスを戻すｏｐｅｎＳｅｇｍｅｎｔ（）メソッドをコールすることによって達成される。アプリケーション１０１は、メソッドｇｅｔＤａｔａＯｂｊｅｃｔ（）を用いることによって、そのサブセグメントからの如何なるデータの包含もなしに、特定のセグメントに対応しているデータ・オブジェクトを得ることができる。メソッドは、ｅｍｐｌｏｙｅｅサブセグメントに対応しているデータ・オブジェクトをシリアルに得るために、次の（）を再帰的に用いることができる。

ここで図２Ａを参照すると、一実施形態に係るＸＭＬドキュメントの処理を描いたイベント・トレース・ダイヤグラムが示されている。図２Ａに描かれた特定のステップは、本発明の一実施形態の単に例示的なものに過ぎない。アプリケーション１０１は、ＸＭＬドキュメントのロケーション及び構成キーをフレームワーク１０２に送信する。フレームワークは、アプリケーション１０１によって提供されたキーに基づいて、コンフィギュレータ１０３からの構成情報（ＸＭＬドキュメントの構造のような）を要求する２０２。

この情報を取り出すために、フレームワーク１０２は、コンフィギュレータ１０３から、上記の例となるＸＭＬドキュメントに示されるように、「ｔｏ」及び「ｆｒｏｍ」情報を収容しているＸＭＬセグメント「ｈｅａｄｅｒ」のロケーションを要求する。コンフィギュレータ１０３は、ＸＭＬドキュメント１０７の該当する部分を見つけ出すことができる場所を示すマッピングを収容し、したがって、コンフィギュレータ１０３は、例えば、セグメント、サブセグメント、Ｘ−Ｐａｔｈクエリ、トランスレータ・クラスなどを含むＸＭＬ構造についての構成情報を送信すること２０３によって、要求２０２に応答する。上記の例では、ＸＭＬドキュメント１０７のヘッダにおいてこうした情報が見つけ出される。

アプリケーション１０１は、ＸＭＬセグメントの名前を提供することによって、アプリケーション・ドメイン・オブジェクトを要求する。フレームワーク１０２は、ＸＭＬセグメントを抽出するためにＳｔＡＸパーサ１０４に要求を送信する２０５。ＳｔＡＸパーサ１０４は、識別された情報に遭遇するまでＸＭＬドキュメント１０７をパースし、上記の例では、これは、「＜ｈｅａｄｅｒ＞」タグが見つけ出されるまでＸＭＬドキュメント１０７をパースし、且つタグが見つけ出されるときにフレームワーク１０２に通知する。フレームワークは、エンドタグ「＜／ｈｅａｄｅｒ＞」が見つけ出されるまでＳｔＡＸを介してＸＭＬの取り出しを続ける。

一実施形態において、こうしたパーシングは、データストア１０８からのデータの、繰返される取り出しを含んでもよい。識別された情報に遭遇すると、ＳｔＡＸパーサ１０４は、ＸＭＬセグメントを戻す２０６。

フレームワーク１０２は、次いで、例えば、抽出されたＸＭＬセグメントとアプリケーションによって提供されたセグメント名とを渡すことによって、ＸＭＬＢｅａｎｓオブジェクトへの変換を要求するためにトランスレーション層１０６に要求を送信する２０７。一実施形態において、トランスレーション層１０６は、周知の技術に従ってＸＭＬセグメントをＸＭＬＢｅａｎｓオブジェクトに変換するためのＸＭＬＢｅａｎｓモジュール１０５を含む。トランスレーション層１０６及び／又はＸＭＬＢｅａｎｓモジュール１０５は、フレームワーク１０２に対して及びシステム１００の他のコンポーネントに対してローカルに位置づけられてもよいし又はリモートに位置づけられてもよい。トランスレーション層１０６は、ＸＭＬセグメント及びセグメント名を用いて生成された対応するＸＭＬＢｅａｎｓオブジェクトを戻す２０８。

フレームワーク１０２は、次いで、オブジェクトをアプリケーション１０１によって理解されることが可能なフォーマットに変換するために、ＸＭＬＢｅａｎｓオブジェクトをトランスレーション層１０６に送信２０９し、トランスレーション層１０６にＸＭＬＢｅａｎｓオブジェクトとセグメント・キーを渡す。トランスレーション層１０６がこのアプリケーション・ドメイン・オブジェクトを生成すると、トランスレーション層１０６は、アプリケーション・ドメイン・オブジェクトを戻し２１０、次いで、これをフレームワーク１０２がさらなる処理のためにアプリケーション１０１に戻す２１１。

一実施形態において、コンフィギュレータ１０３は、例外ハンドリングを制御する。例えば、無効なＸＭＬに遭遇する場合に、コンフィギュレータ１０３は、無効なＸＭＬがスキップされるべきかどうか又は無効なＸＭＬの取り出し可能などんな部分をも取り出す試みがなされるべきかどうかを示すことができる。

ここで図２Ｂ及び図２Ｃを参照すると、付加的な詳細とエラー・ハンドリングとを含む別の実施形態に係るＸＭＬドキュメントの処理を描いたイベント・トレース・ダイヤグラムが示されている。

アプリケーション１０１は、例えばｏｐｅｎＤａｔａＯｂｊｅｃｔ（ｓｅｇｍｅｎｔＮａｍｅ）コールを発行することによりＸＭＬセグメントの名前を提供することによって、セグメントに対するアプリケーション・ドメイン・オブジェクトが開かれることを要求する２４１。フレームワーク１０２は、コールを受信し、且つ例えばｅｘｔｒａｃｔＳｔａｒｔＥｌｅｍｅｎｔＡｎｄＩｔｓＡｔｔｒｉｂｕｔｅｓ（ｓｅｇｍｅｎｔＮａｍｅ）をコールすることによって、セグメントに対するスタート要素及び属性を抽出する２４２ために、ＳｔＡＸパーサ１０４への要求をサブミットする。ＳｔＡＸパーサ１０４は、セグメントＸＭＬを戻す２５７。フレームワーク１０２は、次いで、例えばａｐｐｅｎｄＥｎｄＴａｇＩｎＥｘｔｒａｃｔｅｄＸｍｌ（）をコールすることによって、抽出されたＸＭＬにエンドタグを追記する２４３。抽出されたＸＭＬセグメントは、エンドタグが追記された後で整形式のＸＭＬに変化する。

フレームワーク１０２は、例えば、ｇｅｔＸｍｌＯｂｊｅｃｔ（ｅｘｔｒａｃｔｅｄＸｍｌ、ｓｅｇｍｅｎｔＮａｍｅ）コールを介して、抽出されたＸＭＬ及びセグメント名をトランスレーション層１０６に渡すことによって、トランスレーション層１０６からのＸＭＬＢｅａｎｓオブジェクトを要求する２４４。トランスレーション層１０６は、ｃｒｅａｔｅＣｏｒｒｅｓｐｏｎｄｉｎｇＸｍｌＯｂｊｅｃｔ（）をコールすることによって、対応するＸＭＬＢｅａｎｓオブジェクトを生成し２４５、且つ生成したＸＭＬＢｅａｎｓオブジェクトを戻す２４６。フレームワーク１０２は、例えばｇｅｎｅｒａｔｅＤａｔａＯｂｊｅｃｔ（ｘｍｌＯｂｊｅｃｔ）メソッドをコールすることによって、アプリケーション・ドメイン・オブジェクトを要求する２４７。トランスレーション層１０６は、アプリケーション・ドメイン・オブジェクトを戻すこと２４８によって応答する。

フレームワーク１０２は、次いで、例えばｉｎｓｔａｎｔｉａｔｅＳｅｇｍｅｎｔＣｕｒｓｏｒ（Ｏｂｊｅｃｔ）メソッドをコールすることによって、セグメント内のロケーションのトラックを保つために、アプリケーション・ドメイン・オブジェクトを要約するセグメント・カーソルをインスタンス化する２４９。このセグメント・カーソルは、アプリケーション１０１に戻される２５０。アプリケーション１０１は、このとき、アプリケーション１０１がデータフローの制御下にあるように、データ・オブジェクトをプル型配置で要求することができる。

アプリケーション１０１は、例えばｇｅｔＤａｔａＯｂｊｅｃｔ（）をコールすることによって、セグメント・カーソル２３１によって要約されたアプリケーション・ドメイン・オブジェクトを要求する２５１。セグメント・カーソル２３１は、要求されたアプリケーション・ドメイン・オブジェクトを戻す２５２。必要とされる場合に、アプリケーション１０１は、次いで、例えばｎｅｘｔ（ｓｕｂＳｅｇｍｅｎｔＮａｍｅ）コールを発行することによりサブセグメント名を渡すことによって、アプリケーション・ドメイン・オブジェクトを要求する２５３。セグメント・カーソル２３１は、現在開かれているセグメント及びそのサブセグメントの名前を提供するフレームワーク１０２に要求を転送する２５４。フレームワーク１０２は、図２Ａとの関連において上記で説明された技術に従うアプリケーション・ドメイン・オブジェクトを生成する２５７。しかしながら、一実施形態において、ＸＭＬは、現在の開かれたセグメント内からのみ抽出される。フレームワーク１０２は、次いで、アプリケーション・ドメイン・オブジェクトを戻し２５５、セグメント・カーソル２３１は、オブジェクトをアプリケーション１０１に戻す２５６。

図２Ｃに続くと、アプリケーション１０１は、例えば、ｇｅｔＤａｔａＯｂｊｅｃｔ（ｓｅｇｍｅｎｔＮａｍｅ）コールを介してＸＭＬセグメントの名前を提供することによって、ＸＭＬセグメントに対するアプリケーション・ドメイン・オブジェクトを要求する２６１。フレームワーク１０２は、例えば、ｅｘｔｒａｃｔＸｍｌＳｅｇｍｅｎｔ（ｓｅｇｍｅｎｔＮａｍｅ）をコールすることによって、識別されたセグメント名に対するＸＭＬセグメントを抽出するために、ＳｔＡＸパーサ１０４をコールする２６２。ＳｔＡＸパーサ１０４は、セグメントＸＭＬを戻す２７４。フレームワーク１０２は、次いで、例えば、ｇｅｔＸｍｌＯｂｊｅｃｔ（ｅｘｔｒａｃｔｅｄＸｍｌ，ｓｅｇｍｅｎｔＮａｍｅ）コールを介して、抽出されたＸＭＬ及びセグメント名をトランスレーション層１０６に渡すことによって、ＸＭＬＢｅａｎｓオブジェクトを要求する２６３。トランスレーション層１０６は、例えばｃｒｅａｔｅＣｏｒｒｅｓｐｏｎｄｉｎｇＸｍｌＯｂｊｅｃｔ（）をコールすることによって、抽出されたＸＭＬに対応しているＸＭＬＢｅａｎｓオブジェクトを生成する２６４。トランスレーション層１０６は、ＸＭＬＢｅａｎｓオブジェクトをフレームワーク１０２に戻す２６５。

一実施形態において、フレームワーク１０２は、例えばｖａｌｉｄａｔｅＡｇａｉｎｓｔＸｓｄ（）をコールすることによって、ＸＭＬＢｅａｎｓオブジェクトをＸＳＤに対して確認する２６６。メソッドコールは、ＸＭＬＢｅａｎｓオブジェクトにそれ自身をＸＳＤに対して確認するように依頼する。何らかの確認エラーが存在する場合、フレームワーク１０２は、ＸＭＬＢｅａｎｓ１０５からそれらを得る２６７。フレームワーク１０２は、エラーを有するこれらのオブジェクトに対するレコード識別子を抽出するためにレコード識別子ＸＰａｔｈクエリ（コンフィギュレータを介して構成される）を走らせ２６８（ｒｕｎＸＰａｔｈＱｕｅｒｉｅｓＴｏＥｘｔｒａｃｔＲｅｃｏｒｄＩｄｅｎｔｉｆｉｅｒｓ（ｘｍｌＯｂｊｅｃｔ））、ＸＭＬＢｅａｎｓ１０５は、レコード識別子（単数又は複数）を戻す２７５。フレームワーク１０２は、エラーのソースを識別することができるように、エラーメッセージに識別子文字列を追記する２６９（ａｐｐｅｎｄＩｄｅｎｔｉｆｉｅｒＳｔｒｉｎｇＴｏＥｒｒｏｒＭｅｓｓａｇｅｓ（））。フレームワーク１０２は、次いで、エラー・ハンドラ２３３でのハンドリングをそれに引き起こさせるエラー及びオブジェクトの識別を含む各エラーメッセージをエラー・ハンドラ２３３に送信する２７０（ｈａｎｄｌｅＶａｌｉｄａｔｉｏｎＥｒｒｏｒｓ（ｃｏｄｅ，ｍｅｓｓａｇｅ））。

フレームワーク１０２は、次いで、例えばｇｅｎｅｒａｔｅＤａｔａＯｂｊｅｃｔ（ｘｍｌＯｂｊｅｃｔ）コールを発行することによって、アプリケーション・ドメイン・オブジェクトに変換するために、ＸＭＬＢｅａｎｓオブジェクト及びセグメント名をトランスレーション層１０６に伝送する２７１。トランスレーション層１０６は、ＸＭＬＢｅａｎｓオブジェクトに対応しているアプリケーション・ドメイン・オブジェクトを生成すること２７２によってトランスレーションを行い、且つアプリケーション・ドメイン・オブジェクトをフレームワーク１０２に戻し２７３、フレームワーク１０２が、次いで、アプリケーション・ドメイン・オブジェクトをアプリケーション１０１に転送する２７６。

ＸＭＬドキュメントの生成
本明細書で説明されるように、ＸＭＬドキュメント１０７の生成は、個別的な様式で行うことができ、この場合、アプリケーション１０１は、各セグメントに対する情報を順に提供し、且つセグメントがフルセグメントであるか又は囲み（ｅｎｃｌｏｓｉｎｇ）セグメントであるかを示す。或るセグメントは、ＸＭＬドキュメント１０７が生成されている状態でメモリ内に保たれてもよく、一方、他のセグメントは、個々の要素（レコードのような）が１つずつ生成され且つ追記されてもよいようにメモリ内に保つには大きすぎる場合がある。

アプリケーション１０１は、あらゆる数のデータソースからのデータ並びにアプリケーション・ビジネス論理に基づいて、ＸＭＬドキュメント１０７を生成する必要がある場合がある。アプリケーション１０１は、したがって、アプリケーション・データ・オブジェクトに要約されるデータを有し、本明細書で説明されるように、これらのアプリケーション・データ・オブジェクトは、ＸＭＬセグメントを生成するために用いられる。本発明のシステムは、アプリケーション１０１にＳｔＡＸパーサ１０４又はＸＭＬＢｅａｎｓ１０５のあらゆる知識又は意識を有することを要求することなく、こうした変換が行われることを可能にする。データ・オブジェクトは、対応するＸＭＬセグメントを生成し且つ生成されているＸＭＬドキュメント１０７に追記することができるように、フレームワーク１０２に増加的に渡される。

フレームワーク１０２は、アプリケーション１０１によって提供されたデータ・オブジェクトに基づいて、そのメモリバッファにおけるＸＭＬコードの生産を開始する。プロセスは、メモリバッファが満杯であるときに、バッファに入れられたデータがデータストア１０８に書き込まれている状態で続行する。

上記で説明されたように、トランスレーション層１０６は、アプリケーション・データ・オブジェクトと対応するＸＭＬＢｅａｎｓオブジェクトとの間のマッピングを提供する。フレームワーク１０２は、ＸＭＬＢｅａｎｓオブジェクトを生成するタスクをトランスレーション層１０６にデリゲートする。フレームワーク１０２は、トランスレーション層１０６によって生成されたＸＭＬＢｅａｎｓオブジェクトの、ＸＭＬスキーマ定義（ＸＳＤ）に対する確認を行い、且つ確認エラーメッセージのハンドリングをアプリケーション・エラー・ハンドラにデリゲートする。フレームワーク１０２は、ＸＭＬＢｅａｎｓオブジェクトを用いて対応するＸＭＬセグメントを生成し、且つセグメントをそのバッファに書き込む。一実施形態において、このバッファは、より永続的なデータ記憶デバイスにバックアップされてもよい。アプリケーション１０１がＸＭＬ生成プロセスの終了を示すと、バッファがフラッシュされ、ファイルが閉じられる。

多くの状況において、多数のレコードが書き込まれることになる。セグメントＸＭＬ及び対応するＸＭＬＢｅａｎｓオブジェクトがメモリ内に生成されるので、フレームワーク１０２がすべてのレコードをメモリ内に同時に保持することを試みた場合に、リソース制限が存在する場合がある。したがって、本発明の技術は、それによってセグメントにおける要素を増加的に付加することができる、機構を提供する。アプリケーション１０１は、その子セグメント（サブセグメント）が増加的に付加されることになるセグメントを付加するようにフレームワーク１０２に依頼する。フレームワーク１０２は、生成されたＸＭＬからセグメント・エンドタグ（例えば＜／ｅｍｐｌｏｙｅｅｓ＞）を除去し、且つこれをスタックにプッシュする。アプリケーション１０１は、次いで、ｅｍｐｌｏｙｅｅサブセグメントを増加的に付加し続けることができる。アプリケーション１０１がすべてのサブセグメントの付加を終えると、スタックからの最後のタグがポップされ、且つ生成されたＸＭＬコードに戻って追記される。ＸＭＬのこの増分的な生成は、メモリ制限に直面することなく任意のサイズのＸＭＬドキュメントが生成されることを可能にする。

サブセグメントは、所望の場合に互いにネストすることができる。フレームワーク１０２は、階層の深さに対して如何なる制約をも課さない。一実施形態において、いつセグメントを開くか及びいつセグメントを閉じるかをフレームワーク１０２に通知することはアプリケーション１０１の担当である。

例えば、上記に示されたＸＭＬコードを生成する際に、＜ｈｅａｄｅｒ＞セグメントは、＜ｅｍｐｌｏｙｅｅｓ＞セグメント及び関連するデータ、並びに囲み＜ｗｍｉ＞タグと共に生成される。＜ｈｅａｄｅｒ＞セグメントを生成し且つ書き込むために、システムは、囲み＜ｗｍｉ＞タグを開き、且つ＜ｈｅａｄｅｒ＞セグメントを書き込む。エンディング＜／ｗｍｉ＞タグは、付加的なデータ（＜ｅｍｐｌｏｙｅｅｓ＞セグメント）が最初に書き込まれる必要が依然としてあるので、まだ書き込まれなくてもよい。したがって、ＸＭＬドキュメント１０７は、エンディング＜／ｗｍｉ＞タグが欠けることになるため、一時的に非整形式となるであろう。このエンディング・タグは、これが適切な時点で書き込まれることが可能となるように保持することができる。

一実施形態において、アプリケーション１０１がドキュメント１０７全体を書き込むことなくＸＭＬドキュメント１０７のセグメントを書き込むことを試みる場合に、これは、セグメントが開かれるべきであるがまだ閉じられるべきではないこと、及びデータの一部のみが送られており、さらに後に続くことをフレームワーク１０２に通知するように、ｏｐｅｎＳｅｇｍｅｎｔ（）コールを渡すことができる。これは、データ要素の増分的な書き込み（レコードのような）を可能にする。エンディング・タグは、データ要素がすべて書き込まれた後でこれが書き込まれることが可能となるように、ＳｔＡＸパーサ１０４から得られ且つメモリ内に保持されてもよい。

ここで図３Ａ及び図３Ｂを参照すると、一実施形態に係るＸＭＬドキュメント１０７の生成を描いたイベント・トレース・ダイヤグラムが示されている。アプリケーション１０１は、構成キーをフレームワーク１０２に送信３２１し、コンフィギュレータ１０３から、提供されたキーに対する構成を要求する３２２。コンフィギュレータ１０３は、トランスレータ・クラスが無効なＸＭＬセグメントを無視するか又は含むかなどについてのデータを含む、要求された構成情報を戻す３２３。

アプリケーション１０１は、オブジェクトがＸＭＬに変換されることを要求するアプリケーション・ドメイン・オブジェクトをフレームワーク１０２に渡す３０１。フレームワーク１０２は、例えばｇｅｎｅｒａｔｅＸｍｌＯｂｊｅｃｔ（）コールを発行することによって、オブジェクトをトランスレーション層１０６に送信する３０２。トランスレーション層（ｌａｔｅｒ）１０６は、ｃｒｅａｔｅＣｏｒｒｅｓｐｏｎｄｉｎｇＸｍｌＯｂｊｅｃｔ（）のようなメソッドを走らせ、且つ対応するＸＭＬＢｅａｎｓオブジェクトを戻す３０３。フレームワーク１０２は、次いで、例えばＸＳＤを用いて生成されたＸＭＬオブジェクト・クラスを用いて、ＸＭＬＢｅａｎｓオブジェクトからＸＭＬセグメントを生成する３０４。フレームワーク１０２は、以下のようにＸＭＬをデータストア１０８に書き込む３０９。

ここで図３Ｂを参照すると、アプリケーション１０１は、ｏｐｅｎＳｅｇｍｅｎｔ（ｏｂｊｅｃｔ）コールをフレームワーク１０２に送信する３０６。このコールは、書き込まれることになるデータに対する新しいセグメントを開くように、しかしエンディング・タグを書き込まないようにフレームワーク１０２に伝える。フレームワーク１０２は、例えばｇｅｎｅｒａｔｅＸｍｌＯｂｊｅｃｔ（）コールを発行することによって、アプリケーション・ドメイン・オブジェクトをトランスレーション層１０６に送信する３２４。トランスレーション層（ｌａｔｅｒ）１０６は、対応するＸＭＬＢｅａｎｓオブジェクトを戻す３２５。フレームワーク１０２は、次いで、例えばＸＳＤを用いて生成されるＸＭＬオブジェクト・クラスを用いて、ＸＭＬＢｅａｎｓオブジェクトから対応するＸＭＬセグメントを生成する３２６。

フレームワーク１０２は、エンディング・タグを得るようにパーシングするためにＸＭＬをＳｔＡＸパーサ１０４に送信する３０７。ＳｔＡＸパーサ１０４は、エンディング・タグを識別するためにＸＭＬをパースし、且つエンディング・タグをフレームワーク１０２に送信する３０８。一実施形態において、ステップ３０７は、ｒｅｍｏｖｅＳｅｇｍｅｎｔＥｎｄＴａｇＡｎｄＰｕｓｈＩｔＩｎＳｔａｃｋ（）コールを用いて実装され、これがエンディング・タグの除去を引き起こす。フレームワーク１０２は、例えば、エンドタグをスタックに保存することによって、エンディング・タグを後で用いるためにメモリ内ＦＩＦＯスタックに保持する。幾つかの事例において、多数のエンディング・タグがこの方法で保存されてもよい。エンドタグなしのＸＭＬコードは、データストア１０８におけるデータに追記される３１１。この技術を用いて、フレームワーク１０２は、メモリ制限にぶつかることなくあらゆる任意の長さのＸＭＬコードが書き込まれることを可能にする個別的な様式でＸＭＬコードを書き込むことができる。一実施形態において、これは、ｗｒｉｔｅＸｍｌＴｏＢｕｆｆｅｒＢａｃｋｅｄＢｙＦｉｌｅ（）コールを用いて実装され、これは、永続的記憶装置にもバックアップされる、ＸＭＬコードのバッファへの書き込みを引き起こす。

付加されることになる各セグメントに対して、アプリケーション１０１は、ａｄｄＳｅｇｍｅｎｔ（）コールをフレームワーク１０２に送信する３１０。これは、現在開かれているセグメントへの任意の数のサブセグメントの付加を可能にする。フレームワーク１０２は、例えば、ｇｅｎｅｒａｔｅＸｍｌＯｂｊｅｃｔ（）コールを発行することによって、アプリケーション・ドメイン・オブジェクトをトランスレーション層１０６に送信し３２９、これがｃｒｅａｔｅＣｏｒｒｅｓｐｏｎｄｉｎｇＸｍｌＯｂｊｅｃｔ（）メソッドを呼び出し、且つ対応するＸＭＬＢｅａｎｓオブジェクトを戻す３３０。

随意的に、フレームワーク１０２は、戻されたＸＭＬＢｅａｎｓオブジェクトをＸＳＤに対して確認してもよい。もしあれば、エラーメッセージが戻され、フレームワーク１０２は、例えばｇｅｔＲｅｃｏｒｄＩｄｅｎｔｉｆｉｅｒｓ（）コールを発行することによって、トランスレーション層１０６からのレコード識別子を要求する。トランスレーション層１０６は、アプリケーション・データ・オブジェクトから抽出された識別子文字列を戻す。トランスレーション層１０６は、有意味なレコード識別子を抽出し及び生成することを担当する。フレームワーク１０２は、エラーを引き起こした適切なレコードを識別することができるようにエラーメッセージに識別子文字列を追記し、こうした動作は、例えば、ａｐｐｅｎｄＩｄｅｎｔｉｆｉｅｒＳｔｒｉｎｇＴｏＥｒｒｏｒＭｅｓｓａｇｅｓ（）コールによって行うことができる。必要であれば、ｈａｎｄｌｅＶａｌｉｄａｔｉｏｎＥｒｒｏｒｓ（）コールを介してエラー・ハンドラを呼び出すことができる。

フレームワーク１０２は、ＸＭＬＢｅａｎｓオブジェクト３３０を用いて、例えばＸＳＤを用いて生成されるＸＭＬオブジェクト・クラスを用いて、対応するＸＭＬセグメントを生成する３３１。

フレームワーク１０２は、アプリケーション１０１から受信した命令に従ってＸＭＬセグメントを追記する３３３。

ステップ３１０及び３２９〜３３３は、付加されているすべてのセグメントに対して繰り返される。

すべてのデータがＸＭＬドキュメント１０７に付加されると、フレームワーク１０２は、開かれている囲みセグメント（もし存在すれば）を閉じ、且つドキュメントの書き込みを適正に終えるのに必要とされる場合にあらゆる他のエンディング・タグを追記する準備ができた状態となる。アプリケーション１０１は、ｃｌｏｓｅＳｅｇｍｅｎｔ（）コールを送信３１５し、これは、フレームワーク１０２に、そのサブセグメントが増加的に書き込まれていたセグメントに対するメモリ内スタックからエンディング・タグをポップさせ、且つエンディング・タグをデータストア１０８で書き込まれているデータに追記させる３１２。一実施形態において、ステップ３１２は、ｐｏｐＳｔａｃｋＡｎｄＷｒｉｔｅＰｏｐｐｅｄＥｎｄＴａｇＴｏＢｕｆｆｅｒＢａｃｋｅｄＢｙＦｉｌｅ（）メソッドをコールすることによって行われてもよい。

アプリケーション１０１は、次いで、ｃｌｏｓｅＡｌｌ（）コールを送信３１３し、これは、フレームワーク１０２に、スタックからすべての残りのクロージング・タグを取り出させ且つそれらをＸＭＬドキュメント１０７に追記させる。例えば、タグがスタックに保存されていた場合、フレームワーク１０２は、スタックからタグをポップし、且つそれらをデータストア１０８で書き込まれているデータに追記する３１４。このように、タグが適正な順番で書き込まれる。結果は、データストア１０８での整形式のＸＭＬドキュメント１０７である。一実施形態において、ステップ３１３及び３１４は、ｐｏｐＳｔａｃｋＵｎｔｉｌＥｍｐｔｙＡｎｄＷｒｉｔｅＰｏｐｐｅｄＥｎｄＴａｇｓＴｏＢｕｆｆｅｒＢａｃｋｅｄＢｙＦｉｌｅ（）メソッド、続いてｆｌｕｓｈＢｕｆｆｅｒ（）メソッド、及びｃｌｏｓｅＦｉｌｅ（）メソッドをコールすることによって行われてもよい。

ＸＭＬドキュメントのフラットファイルへの変換
前述のように、一実施形態において、本発明のシステムはまた、種々のタイプのドキュメント変換を行うことができる。例えば、ＸＭＬドキュメントをフラットファイルに変換することが時々有用である。フラットファイルは、構造化された関係性をもたないレコードを収容するデータファイルである。それらは、例えば、ＸＭＬをアップロードすることができない場合があるコンポーネント（ＳＱＬ^＊Ｌｏａｄｅｒのような）との関連において動作するときに、データファイルの大量アップロードのために用いられてもよい。バルク・ローダは、普通はフラットファイルからの入力をとり、それらを解釈するために或る付加的な知識を用いる。例えば、Ｏｒａｃｌｅ ＳＱＬ^＊Ｌｏａｄｅｒは、ファイル・フォーマット特性についての付加的な情報を提供するために制御ファイルを用いる。

一般に、フラットファイルは、あらゆる形態をとることができる。フラットファイルに対する１つの典型的な配置は、以下のセクションを含む。
●ヘッダ・データ：例えば、送信元識別子、トランザクション識別子、受信日付などを含んでいるメタデータを含む。一般に、ボディ・レコード毎に繰り返される必要のない情報を含む。
●ボディ・データ：ｅｍｐｌｏｙｅｅレコードのような個々のレコードを含む。
●フッタ・データ：レコードの総数などのようなデータをファイルにまとめるためのアイテムを保持する。

一実施形態において、本発明のシステムは、ＸＭＬドキュメント１０７をフラットファイルに変換するための機構を提供する。ＳｔａｘＢｅａｎＭａｐｐｉｎｇ．ｐｒｏｐｅｒｔｉｅｓと呼ばれる構成ファイルは、フラットファイル内のどこに種々のデータ項目が置かれるべきかについての情報を提供する。このように、ヘッダセクション、ボディセクション及び／又はフッタセクションにおいてポピュレートされることになるデータを、例えばＸｐａｔｈクエリ言語を介して指定することができる。ＸＰａｔｈは、セグメント、サブセグメント、及び／又は開かれたセグメントに対応しているＸＭＬオブジェクトを参照することができる。このように、あらゆる所与の時点でメモリ内に必要とされるのはＸＭＬの対応するセグメント及び／又はＸＭＬＢｅａｎｓオブジェクトのみであるため、メモリ使用量が最適化される。ＸＭＬドキュメント全体をメモリ内に保持する必要はない。データを１つのセグメントから別のセグメントにクロスリファレンスする必要がある場合、フレームワーク１０２は、変換の間にメモリ内に適切なデータを保持することができるように、ＸＰａｔｈリファレンスとして指定される、こうしたクロスリファレンスの構成を提供する。

フィールドを互いから分離するために及びレコードを互いから分離するために、あらゆる種類のフィールド区切り文字及びレコード区切り文字を用いることができる。例えば、フィールド区切り文字としてタブ又はコンマを用いることができ、フラットファイルの各ラインがレコードに対応するように、レコード区切り文字として改行（キャリッジリターン）を用いることができる。

一実施形態において、フラットファイルは、ファイルに対するシンタックスを指定する構成によって定義される。例えば、構成は、ボディ・データが現れるべき順番と、含まれるべきあらゆる付加的なメタデータ（例えばレコードの総数のような）とを指定してもよい。

本明細書に記載の技術に従ってフラットファイルに変換することができるＸＭＬドキュメント１０７の例は以下の通りである。

幾つかの状況において、ＸＭＬドキュメント１０７の一部ではなかった特定用途向けデータをフラットファイルにエンリッチすることが有用な場合がある。一実施形態において、フレームワーク１０２は、こうしたデータを変換されたフラットファイルに付加するためのサポートを提供する。こうしたデータは、構成によって指定されてもよく、且つ、例えば、ＸＭＬから抽出する、導出する、又は計算することができるデータを含んでもよい。こうしたデータは、例えば以下のものを含むことができる。
●現在処理されているセグメントからのデータ項目。これらは、例えば、セグメントＸＰａｔｈを用いて指定されてもよい。
●必要とされる場合があるが、現在処理されているセグメントから入手可能ではない、データ項目。これらは、例えば、クロスリファレンスＸＰａｔｈを用いて指定されてもよい。
○一実施形態において、ＸＰａｔｈクロスリファレンス・タイプは、ＸＰａｔｈクエリによって表される値がメモリに保存されるべきである及びエイリアスに割り当てられるべきであるフレームワークを示す構成ファイルにおいて指定される。ＸＰａｔｈに対応しているデータは、対応するエイリアスを参照することによって後でアクセスすることができる。例えば、ＸＰａｔｈクエリヘッダ／＠ｓｅｎｄｅｒＩＤ（ヘッダ・セグメントから抽出される）の値には、ＸＰａｔｈヘッダ／＠ｓｅｎｄｅｒＩＤに対応している値を含めるために他のセグメントによって用いられることが可能なクロスリファレンス・エイリアス「ｓｅｎｄｅｒＩＤ」を割り当てることができる。一実施形態において、すべてのクロスリファレンスされたエイリアスは、それらが属するセグメントが処理されるとすぐにメモリ内に保存される。
○一実施形態において、クロスリファレンス・データは、経時的に蓄積される幾つかの式に基づくグローバル・データを含んでもよく、且つ幾つかのセグメントに対するデータの組合せを表してもよい。
○一実施形態において、クロスリファレンス・データは、或る期間にわたって維持され、次いで、用いられたときに廃棄される、レコード別のデータを含んでもよい。
●導出されるデータ項目：これらは、１つ又は複数のセグメントから導出される何かを含んでもよい。例は、幾つのレコードが処理されているかのトラックを保つ、レコード・カウントである。例えば、フレームワーク１０２は、各ｅｍｐｌｏｙｅｅレコードを抽出し且つこれをフラットファイルに書き込みながら、開かれた各セグメントにおけるｅｍｐｌｏｙｅｅレコード（サブセグメント）のカウントを保つことができる。カウントは、ｅｍｐｌｏｙｅｅレコードの一部としてファイルに書き込むことができる。また、これは、ファイルのフッタセクションに書き込むことができる。
●セッション・データ項目：これらは、アプリケーション１０１が追記することを望むがＸＭＬで利用可能ではない、あらゆるデータを含んでもよい。例えば、パートナー・ソースがｉｎｖｅｎｔｏｒｙファイルを供給する場合、システムにファイル名を渡すことができ、且つファイル識別子を戻すことができる。このファイル識別子は、ＸＭＬから導出可能ではない場合があるが、これはフラットファイルに付加されることになるデータの有用な断片である場合がある。したがって、こうしたデータは、このカテゴリに含めることができる。他の例は、登録ＩＤ、処理時間などを含む。
●アプリケーション・データ：アプリケーション１０１は、ランタイムの間にあらゆる数の名前値のペアを付加することができる。これらの値は、それらの名前によって参照されることが可能であり、且つ所望の場合に、変換されたファイルのあらゆるセクション（単数又は複数）に付加することができる。

ここで図４Ａ及び図４Ｂを参照すると、一実施形態に係るＸＭＬドキュメント１０７をフラットファイルに変換するための方法を描いたイベント・トレース・ダイヤグラムが示されている。

アプリケーション１０１は、フレームワーク１０２をコールしてＸＭＬとフラットファイルとの変換を開始し、フレームワーク１０２にファイル・ロケーション及び構成キーを送信する４０２。一実施形態において、これは、ｃｒｅａｔｅＩｎｓｔａｎｃｅ（Ｓｔｒｉｎｇ ｋｅｙ，Ｆｉｌｅ ｉｎｐｕｔＦｉｌｅ）コールをフレームワーク１０２に送信するアプリケーション１０１によって達成される。

フレームワーク１０２は、コンフィギュレータ１０３から、キーと関連する構成を要求する４０３。これに応答して、コンフィギュレータ１０３は、構成をフレームワーク１０２に送信する４０４。構成を受信すると、フレームワーク１０２は、ＸＭＬファイルのどんな要素を、ヘッダ、ボディ、フッタ、区切り文字などを含むフラットファイルの種々の部分に対して用いるかをこのとき知る。

アプリケーション１０１によって送信されるキーは、したがって、一実施形態において、処理されているＸＭＬのタイプに固有の構成を識別する。構成ファイルに収容され且つキーを介して識別される情報は、以下のような情報を収容する。
●トランスレータ・クラス
●セグメント及びサブセグメントのようなＸＭＬの構造
●無効なレコードをスキップするか又は含むかどうか
●ＸＳＤ確認を行うかどうか

一実施形態において、構成は、ボディ・データが現れるべき順番と、含まれるべきあらゆる付加的なメタデータのような情報を含むフラットファイルの構造を指定する。一実施形態において、構成は、Ｊａｖａ（登録商標）クラスとして指定することができるが、あらゆる所望のフォーマットを用いることができる。

アプリケーション１０１は、次いで、指定されたＸＭＬドキュメント上で変換が行われることを要求する４３１。

フレームワーク１０２は、ＳｔＡＸパーサ１０４がセグメントＸＭＬを抽出するべくファイルのパーシングを始めることができるように、フレームワーク１０２にファイル・ロケーションを提供することをＳｔＡＸパーサ１０４にコールする。フレームワーク１０２は、ＳｔＡＸパーサ１０４から、ヘッダに対するＸＭＬセグメント及び／又は他のＸＭＬセグメントのような固有のデータを要求する。これに応答して、ＳｔＡＸパーサ１０４は、ＸＭＬセグメントを得る及びこのＸＭＬをフレームワーク１０２に戻すために、ＸＭＬドキュメント１０７の該当する部分をパースする。例えば、ヘッダ・セグメントに対して、フレームワーク１０２は、ｅｘｔｒａｃｔＸｍｌＳｅｇｍｅｎｔ（ｈｅａｄｅｒＳｅｇｍｅｎｔ）をコールすることによってこれらのステップを行うことができる。

一実施形態において、フラットファイルに対するヘッダ・レコードは、ＸＭＬデータから，構成ファイルにおいて構成される対応するセグメントを抽出することによって生成される。セグメントにおいて見つけ出される場合に、あらゆる構成されたグローバル・クロスリファレンス・エイリアスもまた抽出される。

フレームワーク１０２は、ＳｔＡＸパーサ１０４に、フラットファイルのヘッダ・レコードを生成するのに必要とされるセグメントを抽出することをコールする４１１。フレームワーク１０２は、コンフィギュレータ１０３からセグメントの名前を入手し、且つこれをＳｔＡＸパーサ１０４に渡して、対応するＸＭＬセグメントを入手する。ＳｔＡＸパーサ１０４は、ヘッダ・レコードに対して要求されるＸＭＬセグメントを戻す４１１Ａ。

フレームワーク１０２は、抽出されたＸＭＬセグメント及びセグメント名をトランスレーション層１０６に渡す４１１Ｂ。トランスレーション層は、対応するＸＭＬＢｅａｎｓオブジェクトを生成し４１１Ｃ、且つこれをフレームワーク１０２に戻す４１１Ｄ。

フレームワーク１０２は、構成されたＸｐａｔｈクエリをＸＭＬＢｅａｎｓオブジェクト上で走らせる４１１Ｅ。これはまた、構成されクロスリファレンスされたエイリアスに対してＸｐａｔｈクエリを走らせ、且つこれらを後で用いるためにメモリ内に格納する。

フレームワーク１０２は、ヘッダ・レコードをアセンブルし、且つこれをデータストア１０８で生成されているフラットファイルに書き込む４１２。

あらゆるグローバル・データ、クロスリファレンス・データ、又はそれに類似のものを、これを他のレコードと共に用いるために利用することができるように（例えばエイリアスに）格納することができる。

フレームワーク１０２は、そのサブセグメントが変換されたフラットファイルのボディにおけるレコードを表す、セグメントを処理する。図４Ｂは、フラットファイルに書き込むことに関与する固有のステップに関する付加的な詳細を描く。図４Ｂに示された方法によれば、フレームワーク１０２は、こうしたデータがレコードをフラットファイルに書き込むために必要とされる可能性があるときに、メモリ内にデータを維持することができる。

フレームワーク１０２は、各セグメント名に対応しているＸＭＬセグメントを提供するようにＳｔＡＸパーサ１０４に依頼する。一実施形態において、フレームワーク１０２は、スタート要素及び関連する属性を表わすＸＭＬセグメントのみを入手する。したがって、フレームワーク１０２は、ＳｔＡＸパーサ１０４から、書き込まれることになるフラットファイルのボディに対して構成されたＸＭＬセグメント、スタート要素、及びその属性を要求する４２１。ＳｔＡＸパーサ１０４は、要求されたＸＭＬを戻す４２２。フレームワーク１０２は、整形式のＸＭＬを生成するために、抽出されたＸＭＬにエンドタグを追記する４２２Ａ。

フレームワーク１０２は、次いで、ＸＭＬドキュメント１０７におけるセグメント及びサブセグメントを抽出し且つ対応するレコードをフラットファイルに書き込むプロセスを通してループする。各セグメント及びサブセグメントに対して、フレームワーク１０２は、ＳｔＡＸパーサ１０４によってサブセグメントの抽出を要求し、ＳｔＡＸパーサ１０４は、指定されたセグメント又はサブセグメントに対するＸＭＬセグメントを戻す。各サブセグメントは、ｅｍｐｌｏｙｅｅ又はそれに類似のもののような特定のエンティティと関係付けられてもよい。

付加的な詳細は図４Ｂに示される。フレームワーク１０２は、例えば、抽出されたＸＭＬ及びセグメント名をトランスレーション層１０６に渡すことによって、ＸＭＬＢｅａｎｓオブジェクトを要求する４２２Ｂ。トランスレーション層１０６は、対応するＸＭＬＢｅａｎｓオブジェクトを生成し４２２Ｃ、ＸＭＬＢｅａｎｓオブジェクトをフレームワーク１０２に戻す４２２Ｄ。フレームワーク１０２は、例えばセグメント・レベルで構成されるＸｐａｔｈクエリを走らせることによって、フラットファイルの生成のためにＸＭＬＢｅａｎｓオブジェクトからデータを抽出する４２２Ｅ。

フレームワーク１０２は、各サブセグメントの名前をＳｔＡＸパーサ１０４に１つずつ渡すことによって現在のセグメントのＸＭＬサブセグメントを抽出する。各サブセグメントに対して、フレームワーク１０２は、ＳｔＡＸパーサ１０４によるサブセグメントの抽出を要求し４２４、ＳｔＡＸパーサ１０４は、指定されたサブセグメントに対するＸＭＬセグメントを戻す４２５。フレームワーク１０２は、例えば抽出されたＸＭＬ及びサブセグメント名をトランスレーション層１０６に渡すことによって、ＸＭＬＢｅａｎｓオブジェクトを要求する４２５Ａ。トランスレーション層１０６は、対応するＸＭＬＢｅａｎｓオブジェクトを生成し４２５Ｂ、ＸＭＬＢｅａｎｓオブジェクトをフレームワーク１０２に戻す４２５Ｃ。フレームワーク１０２は、例えばサブセグメント・レベルで構成されるＸｐａｔｈクエリを走らせることによって、フラットファイルの生成のためにＸＭＬＢｅａｎｓオブジェクトからデータを抽出する４２５Ｄ。フレームワーク１０２はまた、前に抽出されたグローバル・データ及び／又はアプリケーションにより提供されたデータを用いてレコードをアセンブルすることができる。

フレームワーク１０２は、次いで、複数のソースから収集したデータを用いてボディ・レコードをアセンブルし４２５Ｅ、且つレコードをフラットファイルとしてデータストア１０８に書き込む４２９。

ステップ４２１〜４２９は、すべてのレコードが書き込まれるまで必要に応じて何度でも繰り返すことができる。一実施形態において、フレームワーク１０２は、ファイルにおける種々のボディ・セグメントを通してループする。各ボディ・セグメントは、あらゆる数のサブセグメントを収容してもよく、フレームワーク１０２は、これらを通して同様にループする。

すべてのセグメントが完了すると、フレームワーク１０２は、フッタ・レコードをアセンブルし４２９Ａ、且つフッタ・レコードをデータストア１０８に書き込んで４２９Ｂ、これをフラットファイルに追記する。フレームワーク１０２は、次いで、ファイルを閉じる４２９Ｃ。

したがって、各ボディ・セグメントに対して、フレームワーク１０２は、以下のステップを行うことができる。
●ボディのスタート要素及びその属性を抽出する（ｅｘｔｒａｃｔＳｔａｒｔＥｌｅｍｅｎｔＡｎｄＩｔｓＡｔｔｒｉｂｕｔｅｓ（ｓｅｇｍｅｎｔＮａｍｅ）。
●エンドタグ（ａｐｐｅｎｄＥｎｄＴａｇＩｎＥｘｔｒａｃｔｅｄＸｍｌ（））を追記する。
●ＸＭＬＢｅａｎｓオブジェクトへの変換を要求する（ｇｅｔＸｍｌＯｂｊｅｃｔ（ｅｘｔｒａｃｔｅｄＸｍｌ，ｓｅｇｍｅｎｔＮａｍｅ）をトランスレーション層１０６に送信し、トランスレーション層１０６がｃｒｅａｔｅＣｏｒｒｅｓｐｏｎｄｉｎｇＸｍｌＯｂｊｅｃｔ（）を実行し、且つＸＭＬＢｅａｎｓオブジェクトを戻すことによる）。
●ＸＭＬＢｅａｎｓオブジェクトからデータを抽出する（ｒｕｎＸＰａｔｈＱｕｅｒｉｅｓＯｎＸｍｌＯｂｊｅｃｔ（））。

次いで、ボディ・セグメントにおける各サブセグメントに対して、フレームワーク１０２は、以下のステップを行うことができる。
●サブセグメントに対応しているＸＭＬを抽出する。
●ＸＭＬＢｅａｎｓオブジェクトへの変換を要求する（ｇｅｔＸｍｌＯｂｊｅｃｔ（ｅｘｔｒａｃｔｅｄＸｍｌ，ｓｕｂＳｅｇｍｅｎｔＮａｍｅ）をトランスレーション層１０６に送信し、トランスレーション層１０６がｃｒｅａｔｅＣｏｒｒｅｓｐｏｎｄｉｎｇＸｍｌＯｂｊｅｃｔ（）を走らせ、且つＸＭＬＢｅａｎｓオブジェクトを戻すことによる。
●ＸＭＬＢｅａｎｓオブジェクトからデータを抽出する（ｒｕｎＸＰａｔｈＱｕｅｒｉｅｓＯｎＸｍｌＯｂｊｅｃｔ（））。
●抽出されたデータをフラットファイルに書き込む（ｗｒｉｔｅＥｘｔｒａｃｔｅｄＤａｔａＩｎＦｉｌｅ（））。

すべてのボディ・セグメントにおけるすべてのサブセグメントが処理されると、フレームワーク１０２は、フッタを書き込み（ｗｒｉｔｅＦｏｏｔｅｒＤａｔａＩｎＦｉｌｅ（））、且つファイルを閉じる（ｃｌｏｓｅＦｉｌｅ（））。

一実施形態において、フレームワーク１０２が、処理されるレコードの総数のようなグローバル・データのトラックを保つことが、有用な場合がある。こうした情報は、例えば、書き込まれているフラットファイルのフッタ又は他のデータ要素における包含のために用いられてもよい。こうした状況において、アプリケーション１０１は、ａｄｄＳｅｓｓｉｏｎＤａｔａ（ｋｅｙ，ｄａｔａ）のようなコールをフレームワーク１０２に発行することができる。コールに含まれるデータを、次いで、格納することができ、且つフレームワーク１０２によって適宜用いることが可能である。こうしたコールの例は、以下のものを含む。
●ａｄｄＳｅｓｓｉｏｎＤａｔａ（「ｒｅｇＩＤ」、３６５９０）；
●ａｄｄＳｅｓｓｉｏｎＤａｔａ（「ｔｉｍｅＰｒｏｃｅｓｓｅｄ」、「Ｊｕｌｙ２５，２００９」）

フレームワーク１０２は、次いで、レコードをフラットファイルに書き込みながら、アプリケーションにより供給されるセッション・データを用いることができる。一実施形態において、セッション・データは、フレームワーク１０２がそれを行うように構成される場合に、レコード（ボディ、ヘッダ、及び／又はフッタ）にのみ書き込まれるであろう。

フレームワーク・アーキテクチャ
上記で説明された技術は、ソフトウェア・モジュールの種々の配置を用いて実装することができる。以下は、多様な構成オプションを提供するフレームワーク１０２に対するアーキテクチャの例である。一実施形態において、プロデューサ・クラス及びトランスレータ・クラスのセットは、コンフィギュレータ１０３にアクセス可能な構成ファイルで構成される。上記で説明されたように、アプリケーション１０１は、用いられることになるトランスレータ・クラスのキーの名前を渡す。フレームワーク１０２は、次いで、トランスレーション層１０６と指定された構成ファイルとを用いて必要なタスクを行う。一実施形態において、少なくとも３つのクラス、すなわち、ＸＭＬドキュメント１０７を生成するためのプロデューサ・クラス、アプリケーション１０１によって使用可能なアプリケーション・ドメイン・オブジェクトを生成するべくＸＭＬドキュメント１０７を処理するための消費者クラス、及びＸＭＬドキュメント１０７をフラットファイル・フォーマットのような別のフォーマットに変換するためのトランスフォーマ・クラスが提供される。以下は、これらのクラスの詳細の幾つかの例である。

プロデューサ・クラス
ここで図７を参照すると、一実施形態に係るプロデューサ・クラス７００のためのクラス・ダイアグラムが示されている。このアーキテクチャにおいて、エラー・ハンドラ７０１、ＸｍｌＰｒｏｄｕｃｅｒ７０３、ＸｍｌＰｒｏｄｕｃｅｒＦａｃｔｏｒｙ７０４、及びＸｍｌＥｘｃｅｐｔｉｏｎ７０８がアプリケーション１０１に露出される。

Ｃｏｎｆｉｇｕｒａｔｏｒクラス７０９は、構成ファイルで提供される構成をロードすること、パーシングすること、確認すること、及びキャッシュに入れることを担当するコンフィギュレータ１０３を実装する。コンフィギュレータ１０３は、ＸｍｌＰｒｏｄｕｃｅｒＩｍｐｌのインスタンスをインスタンス化し、構成パラメータを設定し、且つトランスレータ・クラスのインスタンス（構成される場合に）を導入（ｉｎｊｅｃｔ）する。ＸｍｌＰｒｏｄｕｃｅｒＦａｃｔｏｒｙ７０４は、ＸｍｌＰｒｏｄｕｃｅｒＩｍｐｌの作成をＣｏｎｆｉｇｕｒａｔｏｒクラス７０９にデリゲートする。一実施形態において、フレームワーク１０２は、ＸＭＬを生成するために以下の構成を用いる。

●ｃｌａｓｓｅｓ．ｋｅｙｓエントリは、構成ファイルで用いられているすべてのキーの名前を指定するのに用いられる。これらは、生産する、消費する、及び／又は変換するのに必要とされるトランスレータ・クラス及びすべての他のクラスに対するキー及びフラットファイルへのＸＭＬファイルである。一実施形態において、各ＸＭＬタイプ（ＸＳＤによって駆動される）は、独自のキーと独自の構成を有する。同じキーは、ＸｍｌＰｒｏｄｕｃｅｒ７０３のインスタンスを入手するためにアプリケーション１０１によって用いられる。
●＜ｔｒａｎｓｌａｔｏｒ−ｋｅｙ＞．ｃｌａｓｓエントリは、ＰｒｏｄｕｃｅｒＴｒａｎｓｌａｔｏｒ７０２インターフェースを実装するトランスレータ・クラスの完全修飾（パッケージ名を伴う）名を指定する。アプリケーション１０１は、ＸｍｌＰｒｏｄｕｃｅｒ７０３インスタンスへの参照を入手するためにキー名を渡す。
●＜ｔｒａｎｓｌａｔｏｒ−ｋｅｙ＞．ｉｎｃｌｕｄｅＩｎｖａｌｉｄエントリは、ＸＳＤ確認に失敗したＸＭＬセグメントが結果セットに含まれるべきか否かを決定するためにフレームワーク１０２によって用いられる。これは真のデフォルト値をもつ随意的なエントリである。
●＜ｔｒａｎｓｌａｔｏｒ−ｋｅｙ＞．ｌｏｇＩｎｖａｌｉｄエントリは、ＸＳＤ確認に失敗したＸＭＬセグメントがログされる及び／又はエラー・ハンドラに渡されるべきか否かを決定するためにフレームワーク１０２によって用いられる。これは真のデフォルト値をもつ随意的なエントリである。

ＸｍｌＰｒｏｄｕｃｅｒインターフェース７０３は、ＸＭＬドキュメント１０７を生産するために要求される動作を含む。アプリケーション１０１は、ＸｍｌＰｒｏｄｕｃｅｒインターフェース７０３を用いてＸＭＬセグメントを増加的に生成する。アプリケーション１０１は、アプリケーション・データ・オブジェクトを渡し、ＸｍｌＰｒｏｄｕｃｅｒインターフェース７０３は、トランスレータ・クラス及びＸＭＬオブジェクト・クラスの助けによりＸＭＬを生産する。一実施形態において、ＸｍｌＰｒｏｄｕｃｅｒインターフェース７０３は、以下のメソッドを含む。
●ｖｏｉｄ ｏｐｅｎＳｅｇｍｅｎｔ（Ｏｂｊｅｃｔ ｏｂｊｅｃｔ）：アプリケーション１０１は、その子を増加的に付加することができるように、このメソッドを用いてＸＭＬ要素を開く。ＰｒｏｄｕｃｅｒＴｒａｎｓｌａｔｏｒインターフェース７０２は、パスインされたアプリケーション・データ・オブジェクトを用いて等価なＸＭＬＢｅａｎｓオブジェクトを作成する、トランスレーション層１０６によって実装される。
●ｂｏｏｌｅａｎ ａｄｄＳｅｇｍｅｎｔ（Ｏｂｊｅｃｔ ｏｂｊｅｃｔ）：アプリケーション１０１は、このメソッドを用いて、生産されているＸＭＬにＸＭＬセグメントを付加する。ＰｒｏｄｕｃｅｒＴｒａｎｓｌａｔｏｒ７０２は、パスインされたオブジェクトを用いて、等価なＸＭＬＢｅａｎｓオブジェクトを作成する。一実施形態において、ＸＭＬセグメントは、もしあれば最後の開かれたセグメントの子要素として追記されるであろう。他の場合には、これはドキュメント・ルートの子として付加されるであろう。セグメントがＸＳＤ確認を渡す場合、戻り値は真であり、他の場合にはこれは偽である。一実施形態において、ＸＳＤ確認は、フレームワーク１０２が無効なセグメントを除外するように構成されるか又は無効なセグメントをログするように構成されるかのいずれかの場合にのみ行われる。
●ｖｏｉｄ ｓｅｔＥｒｒｏｒＨａｎｄｌｅｒ（ＥｒｒｏｒＨａｎｄｌｅｒ ｈａｎｄｌｅｒ）：アプリケーション１０１は、随意的に、ＥｒｒｏｒＨａｎｄｌｅｒインターフェースを実装するエラー・ハンドラを設定することができる。ＸＳＤ確認エラーは、ハンドラにデリゲートされ、アプリケーション１０１は、それらを多少なりとも用いることができる。確認エラーは、エラー・ハンドラが設定されない場合にＪａｖａ（登録商標）ロガーを用いてログされる。
●ｖｏｉｄ ｃｌｏｓｅＳｅｇｍｅｎｔ（）：アプリケーション１０１は、このメソッドを用いて、現在開かれているセグメントのすべての子の増分的な付加が過度であることをフレームワーク１０２に通知する。フレームワーク１０２は、最後の開かれたセグメントのエンディング・タグを挿入する。
●ｖｏｉｄ ｃｌｏｓｅＡｌｌ（）：アプリケーション１０１は、このメソッドを用いて、これが如何なるさらなるデータをも有さず且つＸＭＬ生成が完了することをフレームワーク１０２に通知する。アプリケーション１０１は、ＸＭＬを適正に生成することができるように、このメソッドをコールする。フレームワーク１０２は、このコールの結果として以下の動作を行う。
○対応するエンディング要素をＸＭＬに挿入することによって、すべての開かれたセグメントを閉じる。この機能（ｆｅａｔｕｒｅ）は、アプリケーション１０１が複数の入れ子にされたセグメントを開き、且つそれらのすべてを閉じることを望むときに有用である。
○バッファをフラッシュし、出力ファイルを閉じる。

ＸｍｌＰｒｏｄｕｃｅｒＦａｃｔｏｒｙ ｃｌａｓｓ７０４は、ＸｍｌＰｒｏｄｕｃｅｒインターフェースを実装するオブジェクトの作成を要約する。一実施形態において、このクラスは、オブジェクトを作成するための、一方はファイル・オブジェクトを伴い、他方は生成されたＸＭＬを書き込むためのファイル名を伴う、２つのオーバーロードされるメソッドを含む。

ＸｍｌＥｘｃｅｐｔｉｏｎ ｃｌａｓｓ７０８は、例外のために用いられる。フレームワーク１０２は、ＸｍｌＥｘｃｅｐｔｉｏｎ ｃｌａｓｓ７０８のインスタンスで遭遇した例外を変換する。この例外は、オリジナルの例外における情報が失われないようにオリジナルの例外をラップする。

ＰｒｏｄｕｃｅｒＴｒａｎｓｌａｔｏｒインターフェース７０２は、トランスレーション層１０６におけるフレームワーク１０２とＰｒｏｄｕｃｅｒＴｒａｎｓｌａｔｏｒクラスとの間の規約を定義する。トランスレータ・クラスは、等価なＸＭＬＢｅａｎｓオブジェクトへのアプリケーション・データ・オブジェクトのマッピングを提供する。一実施形態において、ＰｒｏｄｕｃｅｒＴｒａｎｓｌａｔｏｒインターフェース７０２は、以下のメソッドを含む。
●ＸｍｌＯｂｊｅｃｔ ｇｅｔＲｏｏｔＯｂｊｅｃｔ（）：トランスレータ・クラスは、フレームワーク１０２がすべての適用可能なネーム空間と一緒にルート・ドキュメントの生成を開始できるように、ルート・ドキュメントＸｍｌＯｂｊｅｃｔインスタンスを戻すべきである。
●ＸｍｌＯｂｊｅｃｔ ｇｅｔＸｍｌＯｂｊｅｃｔ（Ｏｂｊｅｃｔ ｄａｔａＯｂｊｅｃｔ）：トランスレータ・クラスは、渡されたアプリケーション・データ・オブジェクトに基づいて対応するＸＭＬＢｅａｎｓインスタンスを生成するべきである。生成されたＸＭＬＢｅａｎｓオブジェクト（ＸｍｌＯｂｊｅｃｔ）は、ＸＭＬの対応するセグメントを生成するためにフレームワークによって用いられる。
●ＸｍｌＯｂｊｅｃｔ ｇｅｔＩｎｎｅｒＸｍｌＯｂｊｅｃｔ（Ｏｂｊｅｃｔ ｄａｔａＯｂｊｅｃｔ，ＸＭＬＯｂｊｅｃｔ ｏｂｊｅｃｔ）：トランスレータ・クラスは、アプリケーション・データ・オブジェクト並びに対応するＸＭＬＯｂｊｅｃｔの知識を有する。データタイプがＸＳＤで定義される方法に応じて、データ・オブジェクトからＸＭＬＢｅａｎｓオブジェクトを生成しながら、ＸＭＬオブジェクト・グラフにおいて親ＸＭＬＢｅａｎｓオブジェクトが生成されてもよい。例えば、単一のｅｍｐｌｏｙｅｅレコードのＸＭＬＢｅａｎｓオブジェクトを生成するために、Ｅｍｐｌｏｙｅｅｓ ＸｍｌＯｂｊｅｃｔが最初にインスタンス化され、その後、１つのＥｍｐｌｏｙｅｅ ＸｍｌＯｂｊｅｃｔを収容するサイズのアレイがインスタンス化される。このアレイは、ラッパー・オブジェクトに付加される。本質的に、Ｅｍｐｌｏｙｅｅ ＸｍｌＯｂｊｅｃｔをラップするのはＥｍｐｌｏｙｅｅｓ ＸｍｌＯｂｊｅｃｔである。ｅｍｐｌｏｙｅｅ ＸｍｌＯｂｊｅｃｔに対してＸＳＤ確認を行うために、フレームワーク１０２は、ラッパーＸＭＬＯｂｊｅｃｔ Ｅｍｐｌｏｙｅｅｓからｅｍｐｌｏｙｅｅ ＸｍｌＯｂｊｅｃｔを抽出する。トランスレータ・クラスは、アプリケーション・データ・オブジェクトに対応する内側ＸｍｌＯｂｊｅｃｔを戻す。戻されたＸｍｌＯｂｊｅｃｔは、ＸＳＤ確認を行うためにフレームワークによって用いられる。
●Ｓｔｒｉｎｇ ｇｅｔＯｂｊｅｃｔＩｄｅｎｔｉｆｉｅｒｓ（Ｏｂｊｅｃｔ ｄａｔａＯｂｊｅｃｔ）：ＸＳＤ確認エラーメッセージは、パーサからパーサへと変化することがある。技術者でない人々にとってそれらを理解するのは非常に難しいことがある。これらのエラーメッセージは、ＸＳＤ確認に失敗したレコードを識別するのに十分な情報を提供しない場合がある。一実施形態において、フレームワーク１０２は、ｇｅｔＯｂｊｅｃｔＩｄｅｎｔｉｆｉｅｒｓを用いて、付加的な情報をＸＳＤエラーメッセージに追記する。一実施形態において、追記されることになる情報を判定するのはトランスレータ・クラスである。アプリケーション・データ・オブジェクトは、これが適切な情報を抽出することができるように、トランスレーション・クラスに渡され戻される。抽出された情報は、ＸＳＤ確認エラーメッセージに追記される。アプリケーション・データ・オブジェクトは、これが対応するＸＭＬセグメントを生成するための情報のソースであるので、トランスレータ・クラスに渡される。フレームワーク１０２は、ＸＳＤ確認エラーをログするように構成されるときに、この関数を利用する。

ＸｍｌＰｒｏｄｕｃｅｒＩｍｐｌクラス７０７は、インターフェースＸｍｌＰｒｏｄｕｃｅｒを実装する。このクラスの新しいインスタンスが、ＸｍｌＰｒｏｄｕｃｅｒＦａｃｔｏｒｙを介してアプリケーション１０１に戻される。アプリケーション１０１は、ＸｍｌＰｒｏｄｕｃｅｒインターフェース規約において提供されるメソッドを呼び出すことによってＸＭＬを増加的に生産するためにＸｍｌＰｒｏｄｕｃｅｒインスタンス上で動作する。一実施形態において、ＳｔＡＸパーサ１０４、生成されたＸＭＬＢｅａｎｓオブジェクト、トランスレーション層１０６、及び確認メッセージ・ハンドリングの間でのすべての協調が、ＸｍｌＰｒｏｄｕｃｅｒＩｍｐｌクラス７０７によって制御される。これは、ＸＭＬを増加的に生産するのに必要とされる以下のようなすべての機能性を収容する。
●提供されたアプリケーション・データ・オブジェクトに対応しているＸＭＬセグメント及び開かれたセグメントを生産すること。
●ＸＭＬセグメントをファイルに書き込むこと。
●すべての開かれたセグメントのトラックとそれらの順番を保つこと。
●ＸＭＬセグメント上でＸＳＤ確認を走らせ、且つ確認エラーメッセージを特定用途向けエラー・ハンドラにデリゲートすること。

インターフェース・メソッドを実装することに加えて、ＸｍｌＰｒｏｄｕｃｅｒＩｍｐｌクラス７０７はまた、以下のような内部メソッドを含むことができる。
●ｐｒｏｔｅｃｔｅｄ ｖｏｉｄ ｓｅｔｕｐ保護されたボイド・セットアップ（Ｆｉｌｅ ｘｍｌＯｕｔＦｉｌｅ，ＰｒｏｄｕｃｅｒＴｒａｎｓｌａｔｏｒ ｐｒｏｄｕｃｅｒＴｒａｎｓｌａｔｏｒ，ｂｏｏｌｅａｎ ｉｎｃｌｕｄｅＩｎｖａｌｉｄ，ｂｏｏｌｅａｎ ｌｏｇＩｎｖａｌｉｄ）：コンフィギュレータ・クラス７０９は、アプリケーション１０１がＸｍｌＰｒｏｄｕｃｅｒＦａｃｔｏｒｙを介してＸｍｌＰｒｏｄｕｃｅｒのインスタンスを要求するときに、このクラスの新しいインスタンスを作成する。コンフィギュレータ１０３は、次いで、構成される場合にトランスレータ・クラスのインスタンスを作成し、且つこのメソッドを呼び出して、構成情報（例えば、ＸＳＤ確認が行われる必要があるかどうか、ＸＳＤ確認エラーをログするかどうか、及びトランスレータ・クラス・インスタンス）を渡す。
●ｐｒｉｖａｔｅ ｖｏｉｄ ｓｔａｒｔＤｏｃｕｍｅｎｔ（）：このメソッドは、トランスレータ・メソッドｇｅｔＲｏｏｔＯｂｊｅｃｔ（）によって戻される対応するＸｍｌＯｂｊｅｃｔに基づいてルート・ドキュメント・ノードを生成することを担当する。ＸＭＬは、ＸｍｌＯｂｊｅｃｔから抽出され、且つＳｔＡＸパーサ１０４に渡される。ルート・ドキュメント・エンド要素は、ＦＩＦＯ（Ｆｉｒｓｔ−Ｉｎ−Ｆｉｒｓｔ−Ｏｕｔ）キューにプッシュされる。アプリケーション１０１がすべてのセグメント及び開かれたセグメントの付加を完了すると、要素がポップされ、且つ生成されたＸＭＬに追記される。
●ｐｒｉｖａｔｅ ｂｏｏｌｅａｎ ａｎａｌｙｚｅプライベート・ブール解析（Ｏｂｊｅｃｔ ｄａｔａＯｂｊｅｃｔ，ＸｍｌＯｂｊｅｃｔ ｘｍｌＯｂｊｅｃｔ）：フレームワーク１０２は、このメソッドを用いてＸＳＤ確認を行い、且つそれを行うように構成される場合にあらゆるＸＳＤエラーをログする。これは、最初に、トランスレータ・クラスに、内側ＸｍｌＯｂｊｅｃｔを提供し、且つ戻された内側オブジェクト上でＸＳＤ確認を行うように依頼する。これは次いで、ＸＳＤ確認エラーメッセージに追記されることになる付加的な情報を入手するために、トランスレータ・クラスに対してｇｅｔＯｂｊｅｃｔＩｄｅｎｔｉｆｉｅｒｓ（ｄａｔａＯｂｊｅｃｔ）メソッドをコールする。最後に、エラーメッセージは、さらなる処理のためにＥｒｒｏｒＨａｎｄｌｅｒのアプリケーションにより提供される実装に引き渡される。

ＳｅｇｍｅｎｔＦｉｌｔｅｒクラス７０５は、非ルートＸｍｌＯｂｊｅｃｔから生成されたＸＭＬセグメントから開始及び終了ドキュメント要素をフィルタで除去するために、ｊａｖａｘ．ｘｍｌ．ｓｔｒｅａｍ．ｅｖｅｎｔｓ．ＥｖｅｎｔＦｉｌｔｅｒインターフェースを実装する。これは、ＳｔＡＸパーサ１０４を用いてＸＭＬをパーシングしながらこれらの要素をフィルタするために、ＸｍｌＰｒｏｄｕｃｅｒＩｍｐｌ７０７によって用いられる。

消費者クラス
ここで図８を参照すると、一実施形態に係る消費者クラス８００のためのクラス・ダイアグラムが示されている。このアーキテクチャにおいて、ＸｍｌＣｏｎｓｕｍｅｒ８１２、ＸｍｌＣｏｎｓｕｍｅｒＦａｃｔｏｒｙ８１１、及びＳｅｇｍｅｎｔＣｕｒｓｏｒ８０６がアプリケーション１０１に露出される。

一実施形態において、消費者クラス８００は、２つのタスク、すなわち、アプリケーション・データ・オブジェクトの生成と、ＸＭＬとフラットファイルとの変換を取り扱う。構成パラメータは、ＸＭＬからフラットファイルへの融通性のある変換を提供するために用いることができる。一実施形態において、コンフィギュレータ１０３及びＸｍｌＥｘｃｅｐｔｉｏｎクラス７０８は、フレームワーク１０２の消費者クラス８００とプロデューサ・クラス７００との両方に共通である。しかしながら、コンフィギュレータ１０３は、消費者クラス８００に対する付加的な構成パラメータを提供することができる。プロデューサ・クラス７００との関連において上記で説明された構成に加えて、消費者クラス８００に対する以下の付加的な構成パラメータを構成することができる。
●セグメント及びサブセグメント構成

ＸＭＬにおけるすべてのセグメントを、それらがＸＭＬドキュメントにおいて現れる順番にリストする。それらは本質的に、ドキュメント・ルート要素の即時の別個の子を表す。

一実施形態において、このエントリは、構成されたセグメント（サブセグメント）の子が順次に処理される必要があるときにのみ要求される。それらは、そのサブセグメントが抽出され且つ順次に処理される必要があるセグメントの一意の子を表す。言い換えれば、アプリケーション１０１は、それらを順次に抽出してもよい。

●クロスリファレンス構成：一実施形態において、消費者クラス８００は、一度に一つだけのセグメント／サブセグメントに対するデータをメモリ内に保つ。幾つかの事例において、他のセグメント（単数又は複数）からのデータが必要とされる場合がある。フレームワーク１０２は、処理されているＸＭＬドキュメントのライフサイクル全体にわたるセグメント／サブセグメントに収容される或るデータを格納する方法を提供する。こうしたデータは、クロスリファレンス・データと呼ばれる。クロスリファレンス・データは、セグメント及びサブセグメント上のＸＰａｔｈを用いて構成することができる。このデータは、識別子を介してアイデンティティを与えられる。ＸＭＬ処理のライフサイクルの全体を通して抽出されたデータを参照するために同じ識別子を用いることができる。以下は、クロスリファレンスを構成するために用いることができる構成の例である。

●ＸＳＤ確認エラー・カスタマイゼーション構成：以下の構成は、特定のセグメントに対するＸＳＤ確認エラーメッセージに追記されることになる付加的な情報を抽出するために用いることができる。

一実施形態において、あらゆる数のレコード識別子をセグメントと関連付けることができる。構成される識別子の値は、関連するタイプフィールドに基づいて評価される。それらのすべては、識別子フィールドに基づいて評価される。ｄｉｓｐｌａｙＮａｍｅエントリにおいて指定される、評価される値及び名前は、ＸＳＤ確認エラーメッセージに追記されることになる名前と値とのペアを生成するのに用いられる。例えば、ｅｍｐｌｏｙｅｅ ＩＤに、ＥＭＰＬＯＹＥＥのような表示名をもつすべての無効なｅｍｐｌｏｙｅｅセグメントを追記するために、構成は、以下のように現れる場合がある。

セグメントｅｍｐｌｏｙｅｅのすべてのＸＳＤ確認エラーメッセージは、以下のものを追記されるであろう。

この付加的な情報は、失敗したＸＳＤ確認に対するｅｍｐｌｏｙｅｅレコードを識別する一助となる。

一実施形態において、レコード識別子構成に対して以下のタイプがサポートされる。
●ＳＥＧＭＥＮＴ＿ＸＰＡＴＨ：このタイプに対応しているｒｅｆフィールドは、ＸＰａｔｈとなるべきである。Ｘｐａｔｈクエリは、セグメントをルート・ドキュメントとして対処することによって評価される。
●ＯＰＥＮ＿ＳＥＧＭＥＮＴ＿ＸＰＡＴＨ：このタイプに対応しているｒｅｆフィールドは、ＸＰａｔｈとなるべきである。Ｘｐａｔｈクエリは、その子要素のいずれもなしに開かれたセグメントをルート・ドキュメントとして対処することによって評価される。
●Ｘ＿ＲＥＦ：このタイプに対応しているｒｅｆフィールドは、クロスリファレンス識別子となるべきである。
●ＶＡＬＵＥ：このタイプに対するｒｅｆフィールド値は、如何なる評価をも行うことなく値として用いられる。
●ＣＯＵＮＴ：指定されたセグメント・レコードの現在のカウントは、ｒｅｆフィールドの値として評価される。
●ＳＥＳＳＩＯＮ＿ＤＡＴＡ：ｒｅｆフィールドにおいて指定されるキーをもつマッチング・セッション・データが用いられる。

以下は、図８に描かれた種々のクラスの記述である。

ＸｍｌＣｏｎｓｕｍｅｒクラス８１２は、ＸＭＬドキュメント１０７を処理するのに要求される動作を抽象化するために用いられる。アプリケーション１０１は、これを用いてＸＭＬセグメント／サブセグメントを順次に処理する。アプリケーション１０１は、セグメント／サブセグメントの名前を渡し、フレームワーク１０２は、ＳｔＡＸパーサ１０４、トランスレーション層１０６、及びＸＭＬＢｅａｎｓオブジェクトによって抽出された対応するＸＭＬセグメントを用いて、対応するアプリケーション・データ・オブジェクトを生成する。一実施形態において、ＸｍｌＣｏｎｓｕｍｅｒクラス８１２は、以下のメソッドを含む。
●ＳｅｇｍｅｎｔＣｕｒｓｏｒ ｏｐｅｎＤａｔａＯｂｊｅｃｔ（Ｓｔｒｉｎｇ ｓｅｇｍｅｎｔＮａｍｅ）：アプリケーション１０１は、このメソッドを用いて、指定されたセグメントのサブセグメントへのカーソルを得る。ＳｅｇｍｅｎｔＣｕｒｓｏｒインターフェースは、セグメント及びそのサブセグメントのすべてに対応しているアプリケーション・データ・オブジェクトを取り出すためにメソッドを提供する。
●Ｏｂｊｅｃｔ ｇｅｔＤａｔａＯｂｊｅｃｔ（Ｓｔｒｉｎｇ ｓｅｇｍｅｎｔＮａｍｅ）：アプリケーション１０１は、このメソッドを用いて、指定されたセグメントに対応しているアプリケーション・データ・オブジェクトを取り出す。フレームワーク１０２は、ＳｔＡＸパーサ１０４を用いて指定されたＸＭＬセグメントを抽出する。抽出されたＸＭＬ及びセグメント名は、トランスレータ・クラスに渡される。トランスレータ・クラスは、セグメント名と抽出されたＸＭＬセグメントとを用いて、対応するＸＭＬＯｂｊｅｃｔインスタンスをインスタンス化する。フレームワーク１０２は、トランスレータ・クラス（構成される場合）によって生成されたＸｍｌＯｂｊｅｃｔ上でＸＳＤ確認を行う。レコード識別子は、構成される場合にＸｍｌＯｂｊｅｃｔから抽出され、且つＸＳＤ確認エラーに追記される。確認エラーは、さらなる処理のために（提供される場合）特定用途向けエラー・ハンドラに引き渡される。最後に、フレームワーク１０２は、ＸｍｌＯｂｊｅｃｔ及びセグメント名をトランスレータ・クラスに渡す。トランスレータ・クラスは、アプリケーション１０１に戻される対応するアプリケーション・データ・オブジェクトを生成する。
●ｖｏｉｄ ｓｅｔＥｒｒｏｒＨａｎｄｌｅｒ（ＥｒｒｏｒＨａｎｄｌｅｒ ｈａｎｄｌｅｒ）：アプリケーション１０１は、随意的に、ＥｒｒｏｒＨａｎｄｌｅｒインターフェースを実装するエラー・ハンドラを設定することができる。ＸＳＤ確認エラーは、さらなる処理のためにアプリケーション固有のエラー・ハンドラにデリゲートされる。
●ｖｏｉｄ ｄｏＴｒａｎｓｆｏｒｍ（Ｆｉｌｅ ｔｒａｎｓｆｏｒｍｅｄＦｉｌｅ）：アプリケーション１０１は、このメソッドを用いて、ＸＭＬファイルをフラットファイルに変換する。変換は、構成ファイルにおいて指定される構成によって駆動される。
●ｖｏｉｄ ａｄｄＳｅｓｓｉｏｎＤａｔａ（Ｓｔｒｉｎｇ ｋｅｙ，Ｏｂｊｅｃｔ ｖａｌｕｅ）：アプリケーション１０１は、このメソッドを用いて、変換されたファイルをエンリッチするか又はＸＳＤ確認エラーにおける付加的な情報を付加するかのいずれかのために、フレームワークによって用いられる特定用途向けデータを付加する。

ＸｍｌＣｏｎｓｕｍｅｒＦａｃｔｏｒｙクラス８１１は、ＸｍｌＣｏｎｓｕｍｅｒインターフェースを実装する、オブジェクトの作成を要約するファクトリ・クラスである。一実施形態において、このクラスは、オブジェクトを作成するための、一方はファイル・オブジェクトを伴い、他方は処理されることになるＸＭＬドキュメントのファイル名を伴う、２つのオーバーロードされるメソッドを含む。

ＣｏｎｓｕｍｅｒＴｒａｎｓｌａｔｏｒインターフェース８０９は、消費者トランスレータ・クラスによって提供される動作を抽象化する。実装クラスは、抽出されたＸＭＬセグメントから適切なＸＭＬＯｂｊｅｃｔインスタンスをインスタンス化するのに十分な知識を有する。プロセスの後の方で、対応するアプリケーション・データ・オブジェクトがＸｍｌＯｂｊｅｃｔインスタンスからインスタンス化される。一実施形態において、ＣｏｎｓｕｍｅｒＴｒａｎｓｌａｔｏｒインターフェース８０９は、以下のメソッドを含む。
●ＸｍｌＯｂｊｅｃｔ ｇｅｔＲｏｏＮｏｄｅＮａｍｅ（）：トランスレータ・クラスは、ルート・ドキュメント・ノードの名前を戻す。フレームワーク１０２は、これを用いて、処理されているＸＭＬにおけるルートノードを識別する。
●ＸｍｌＯｂｊｅｃｔ ｇｅｔＸｍｌＯｂｊｅｃｔ（Ｓｔｒｉｎｇ ｓｅｇｍｅｎｔＮａｍｅ、Ｓｔｒｉｎｇ ｓｅｇｍｅｎｔＸｍｌ、Ｓｔｒｉｎｇ ｎａｍｅｓｐａｃｅＳｔａｒｔＷｒａｐｐｅｒ、ｂｏｏｌｅａｎ ｉｓＳｕｂＳｅｇｍｅｎｔ）：トランスレータ・クラスは、渡されたセグメント名及びセグメントＸＭＬに基づいて、対応するＸＭＬＯｂｊｅｃｔインスタンス生成する。トランスレータ・クラスは、それらが必要とされる場合に他の２つのパラメータを利用することができる。生成されたＸｍｌＯｂｊｅｃｔは、ＸＳＤ確認及びＸＰａｔｈクエリを用いるデータの抽出を行うためにフレームワークによって用いられる。
●ＸｍｌＯｂｊｅｃｔ ｇｅｔＩｎｎｅｒＸｍｌＯｂｊｅｃｔ（Ｓｔｒｉｎｇ ｓｅｇｍｅｎｔＮａｍｅ、ＸｍｌＯｂｊｅｃｔ ｏｂｊｅｃｔ）：トランスレータ・クラスは、セグメント及びそのＸＭＬＢｅａｎｓオブジェクト（ＸｍｌＯｂｊｅｃｔ）の知識を有する。生ＸＭＬデータからＸＭＬＢｅａｎｓを生成しながら、ＸＭＬＢｅａｎｓオブジェクト・グラフにおいて親ＸＭＬＢｅａｎｓオブジェクトが生成される。戻されたＸＭＬＢｅａｎｓオブジェクトは、ＸＳＤ確認を行うためにフレームワーク１０２によって用いられる。
●Ｏｂｊｅｃｔ ｇｅｎｅｒａｔｅＤａｔａＯｂｊｅｃｔ（ＸｍｌＯｂｊｅｃｔ ｘｍｌＯｂｊｅｃｔ）：トランスレータ・クラスは、パスインされたＸＭＬＢｅａｎｓオブジェクト（ＸｍｌＯｂｊｅｃｔ）を用いて、対応するアプリケーション・データ・オブジェクトを生成する。具体的なタイプのパスインされるｘｍｌＯｂｊｅｃｔインスタンスは、生成されることになるアプリケーション・データ・オブジェクト・タイプを判定するのに用いられる。

ＸｍｌＣｏｎｓｕｍｅｒＩｍｐｌクラス８０５は、ＸｍｌＣｏｎｓｕｍｅｒインターフェース８１２を実装する。このクラスの新しいインスタンスは、ＸｍｌＣｏｎｓｕｍｅｒＦａｃｔｏｒｙ８１１を介してアプリケーション１０１に戻される。アプリケーション１０１は、ＸＭＬセグメントを順次に処理するためにＸｍｌＣｏｎｓｕｍｅｒ８１２インスタンス上で動作し、ＸｍｌＣｏｎｓｕｍｅｒ８１２及びＳｅｇｍｅｎｔＣｕｒｓｏｒ８０６インターフェース規約において提供されるメソッドを呼び出す。一実施形態において、ＳｔＡＸパーサ１０４、生成されたＸＭＬＢｅａｎｓオブジェクト、トランスレーション層１０６、及び確認メッセージ・ハンドリングの間でのすべての協調が、ＸｍｌＣｏｎｓｕｍｅｒＩｍｐｌクラス８０５によって制御される。これは、ＸＭＬを順次に処理するのに必要とされる以下のようなすべての機能性を収容する。
●ＸＭＬセグメント／サブセグメント及び開かれたセグメントを処理することによってアプリケーション・データ・オブジェクト（単数又は複数）を生成すること。
●開かれたセグメント（単数又は複数）のトラックを保つこと。
●ＸＭＬセグメント上でＸＳＤ確認を走らせ、且つエラーをエラー・ハンドラにデリゲートすること。
●ＸｍｌＯｂｊｅｃｔインスタンス上でＸｐａｔｈクエリを走らせることによって構成されたデータを抽出すること。
●クロスリファレンス・データを抽出すること。
●構成される場合にＸＭＬからフラットファイルへの変換を行うこと。

一実施形態において、ＸｍｌＣｏｎｓｕｍｅｒＩｍｐｌクラス８０５は、２つの異なる規約、すなわち、以下で説明されるように、アプリケーション・データ・オブジェクトを提供すること及びＸＭＬをフラットファイルに変換することを実装する。

データ・オブジェクトの抽出。アプリケーション・データ・オブジェクトは、要求されたセグメントの抽出されたＸＭＬセグメントから作成される。一実施形態において、このタスクを達成するために以下のステップに従う。
１．アプリケーション１０１によって渡されるセグメント／サブセグメント名に基づいてセグメント／サブセグメントを抽出する。
２．トランスレータ・クラスは、抽出されたＸＭＬセグメントに対応している指定されたＸｍｌＯｂｊｅｃｔインスタンスを生成する。
３．戻されたＸｍｌＯｂｊｅｃｔ上でＸｐａｔｈクエリを走らせることによって、構成されたＸＰａｔｈクロスリファレンス・データを抽出する。
４．戻されたＸｍｌＯｂｊｅｃｔ上で確認を行い、確認エラーをカスタマイズし（構成される場合）、次いで、さらなる処理のためにエラーを特定用途向けＥｒｒｏｒＨａｎｄｌｅｒ８０８に引き渡す。抽出されたデータ値をエラーメッセージに付加するために、ＸｍｌＯｂｊｅｃｔ上のＸｐａｔｈクエリを用いて付加的なデータ（ログエントリにおいて構成される場合）が抽出される。
５．セグメントがＸＳＤ確認をパスせず、ｓｋｉｐ ｉｎｖａｌｉｄ ｏｐｔｉｏｎが真である場合に、現在のセグメントを無視する。次のセグメントを取り出し、且つこれをステップ（２）を通じて渡す。
６．トランスレータ・クラスは、ＸｍｌＯｂｊｅｃｔを用いて、対応するアプリケーション・データ・オブジェクトを生成する。
７．生成された特定用途向けデータ・オブジェクトがアプリケーション１０１に戻される。

ＸＭＬからフラットファイルへの変換。一実施形態において、ＸＭＬをフラットファイルに変換するために以下のステップが行われる。
１．フラットファイルのヘッダを生成するために、要求されたセグメント（構成される場合）を抽出する。
２．トランスレータ・クラスが、抽出されたＸＭＬセグメントに対応している指定されたＸｍｌＯｂｊｅｃｔインスタンスを生成する。
３．戻されたＸｍｌＯｂｊｅｃｔ上でＸｐａｔｈクエリを走らせることによって、構成されたＸＰａｔｈクロスリファレンス・データを抽出する。
４．戻されたＸｍｌＯｂｊｅｃｔ上で確認を行い、確認エラーをカスタマイズし（構成される場合）、次いで、さらなる処理のためにエラーをＥｒｒｏｒＨａｎｄｌｅｒ８０８に引き渡す。抽出されたデータ値を確認エラーメッセージに付加するために、ＸｍｌＯｂｊｅｃｔ上のＸｐａｔｈクエリを用いて付加的なデータ（ログエントリにおいて構成される場合）を抽出する。
５．戻されたＸｍｌＯｂｊｅｃｔからデータを抽出し、且つＸｐａｔｈクエリを走らせて、データを取り出し、且つこれをフラットファイルにポピュレートする。
６．すべてのボディ・セグメント及びサブセグメントに対してステップ（１）〜（５）を繰り返す。
７．フッタをフラットファイル（構成される場合）に追記する。

インターフェース・メソッドを実装することに加えて、ＸｍｌＣｏｎｓｕｍｅｒＩｍｐｌクラス８０５はまた、以下のような内部メソッドを含むことができる。
●ｐｒｏｔｅｃｔｅｄ ｖｏｉｄ ｓｅｔｕｐ保護されたボイド・セットアップ（Ｆｉｌｅ ｘｍｌＯｕｔＦｉｌｅ，ＣｏｎｓｕｍｅｒＴｒａｎｓｌａｔｏｒ ｔｒａｎｓ，Ｓｅｇｍｅｎｔ［ ］ｓｅｇｍｅｎｔｓ，ＸＰａｔｈＣｒｏｓｓＲｅｆｅｒｅｎｃｅ［ ］ｘＰａｔｈＣｒｏｓｓＲｅｆ，ｂｏｏｌｅａｎ ｉｎｃｌｕｄｅＩｎｖａｌｉｄ，ｂｏｏｌｅａｎ ｌｏｇＩｎｖａｌｉｄ）：コンフィギュレータ・クラス７０９は、アプリケーション１０１がＸｍｌＣｏｎｓｕｍｅｒＦａｃｔｏｒｙを介してＸｍｌＣｏｎｓｕｍｅｒのインスタンスを要求するときに、このクラスの新しいインスタンスを作成する。次いで、トランスレータ・クラスのインスタンスが作成され、構成情報（例えば、ＸＳＤ確認が行われる必要があるかどうか、ＸＳＤ確認エラーをログするかどうか、並びにセグメント及びそれらのサブセグメントのリスト）を渡すために、このメソッドが呼び出される。
●ｐｒｉｖａｔｅ ＸｍｌＯｂｊｅｃｔ ｇｅｔＳｅｇｍｅｎｔＸｍｌＯｂｊｅｃｔ（Ｓｔｒｉｎｇ ｓｅｇｍｅｎｔＮａｍｅ）：このメソッドは、パスインされたセグメント名に対応しているＸＭＬセグメントを抽出することを担当する。ＳｔＡＸパーサ１０４は、ＸＭＬセグメントを抽出するのに用いられる。トランスレータ・クラスは、抽出されたＸＭＬから対応するＸＭＬＢｅａｎｓオブジェクトを作成する。
●ｐｒｉｖａｔｅ ＸｍｌＯｂｊｅｃｔ ｏｐｅｎＳｅｇｍｅｎｔ（Ｓｔｒｉｎｇ ｓｅｇｍｅｎｔＮａｍｅ）：このメソッドは、パスインされたセグメント名に対応しているＸＭＬセグメント（その子要素のいずれもなしに）を抽出することを担当する。パーシングは、名付けられたセグメントの子が検出されるとすぐに停止される。整形式のＸＭＬは、クロージング・タグを追記することによって生成される。抽出されたＸＭＬ（追記されるクロージング・タグを伴う）は、トランスレータ・クラスに渡される。トランスレータ・クラスは、抽出されたＸＭＬから対応するＸＭＬＢｅａｎｓオブジェクトを作成する。
●ｐｒｉｖａｔｅ ｂｏｏｌｅａｎ ａｎａｌｙｚｅプライベート・ブール解析（Ｓｔｒｉｎｇ ｓｅｇｍｅｎｔＮａｍｅ，ＸｍｌＯｂｊｅｃｔ ｘｍｌＯｂｊｅｃｔ）：フレームワーク１０２は、このメソッドを用いてＸＳＤ確認を行い、且つそれを行うように構成される場合にあらゆるＸＳＤエラーをログする。トランスレータ・クラスは、ＸＳＤ定義に応じて内側ＸＭＬＢｅａｎｓオブジェクト又は同じオブジェクトを提供する。戻されたＸＭＬＢｅａｎｓオブジェクト上でＸＳＤ確認が行われる。エラーメッセージ（もしあれば）は、提供された構成に基づいてカスタマイズされる。最後に、エラーメッセージは、さらなる処理のためにＥｒｒｏｒＨａｎｄｌｅｒ８０８に引き渡される。

ＳｅｇｍｅｎｔＣｕｒｓｏｒＩｍｐｌクラス８０７は、開かれたセグメントのサブセグメントにわたって反復するためにＳｅｇｍｅｎｔＣｕｒｓｏｒ８０６インターフェースの実装を提供する。

ＸＰａｔｈＣｒｏｓｓＲｅｆｅｒｅｎｃｅクラス８１０は、ＸＰａｔｈクロスリファレンスと関係付けられた構成データを要約し、且つこのデータをセットし且つ入手するためにセッター／ゲッター・メソッドを提供する。

Ｆｉｅｌｄクラス８０１は、識別子の構成された名前及びタイプを要約し、例は、ＳＥＧＭＥＮＴ＿ＸＰＡＴＨ、ＯＰＥＮ＿ＳＥＧＭＥＮＴ＿ＸＰＡＴＨ、Ｘ＿ＲＥＦ、ＶＡＬＵＥ、ＣＯＵＮＴ、ＳＥＳＳＩＯＮ＿ＤＡＴＡ、及びＵＳＥＲ＿ＤＥＦＩＮＥＤを含む。Ｆｉｅｌｄクラス８０１は、名前及びタイプに対するセッター／ゲッター・メソッドを提供する。

ＬｏｇＦｉｅｌｄクラス８０２は、Ｆｉｅｌｄクラス８０１を拡張し、且つ表示名及び関係するセッター／ゲッター・メソッドを保持するために付加的な変数を付加する。

Ｓｅｐａｒａｔｏｒクラス８１３は、ＸＭＬとフラットファイルとの変換を行いながら、必要とされるレコード及びフィールド・セパレータに関係する構成データを要約する。

ＴｒａｎｓｆｏｒｍＣｏｎｆｉｇクラス８０４は、ＸＭＬをフラットファイルに変換するのに必要とされるすべての構成データ（ヘッダ、ボディ、フッタなどのような）を要約する。

Ｓｅｇｍｅｎｔクラス８０３は、その名前、親セグメント（もしあれば）、及びサブセグメント（もしあれば）のようなセグメントについての構成情報を要約する。

ＸＭＬとフラットファイルとの変換構成
上記で解説されたように、一実施形態において、フレームワーク１０２によって生成されるフラットファイルは、３つのセクション、すなわち、ヘッダ、ボディ、及びフッタを有する。一実施形態において、フレームワーク１０２は、以下のように、これらのセクションの各々に対する複数の構成オプションを提供する。

ヘッダ
ヘッダは、送信元情報、トランザクションＩＤ、レコードの数などのようなメタデータを収容する。データは、ヘッダに書き込まれることになるあらゆるＸＭＬセグメントから抽出することができる。構成に対するシンタックスの例は以下の通りである。

セグメント名は、ＸＭＬセグメントの名前であり、この場合、データは、フィールド構成で指定されたようにＸｐａｔｈクエリを走らせることによって抽出される必要がある。一実施形態において、フィールド構成は、ＸＳＤ確認エラー・カスタマイゼーション構成と同一である。しかしながら、ｒｅｆ及びｔｙｐｅは、コロンで区切られ、各ペアをコンマで区切ることによって構成することができる。ｒｅｆ部は、構成されるｔｙｐｅに基づいて評価される。このセクションで構成されるＸＰａｔｈは、一般に、シンプル・テキスト又は単一の属性値を評価する。評価された値は、ここで構成されたのと同じ順番でフラットファイル・ヘッダにポピュレートされる。変換されたファイルにポピュレートされた値は、区切り文字によって分離される。区切り文字の値は、以下で解説するように構成することができる。

ボディ
ヘッダ部に対して上記に示されたものと類似したフォーマットを用いて、あらゆる数のセグメントを構成することができる。一般に、構成されるセグメントのすべてのサブセグメントは、指定されたサブセグメントに遭遇する度に、再帰的に取り出され、１つのレコードが作成され、且つ変換されたファイルに追記される。前に述べたように、セグメント及びそれらのサブセグメントのリストは、それらがＸＭＬドキュメントにおいて現れる順番に構成される。

フッタ
フッタ構成は、サマリ・レコードを作成し且つこれを変換されたファイルの末尾に追記することへのサポートを提供する。これは、ヘッダに対して上記で説明されたのと類似したフォーマットに従う。

フィールド及びレコード区切り文字
一実施形態において、あらゆる区切り文字を指定することができる。以下の構成は、変換されたファイルにおける区切り文字を指定するために用いることができる。

実施例
以下は、本発明の技術を用いてＸＭＬドキュメント１０７を生成（生産）し及び処理（消費）する例である。例証する目的で、例は、以下のＸＳＤを用いる。

以下は、上記のＸＳＤに適合するサンプルＸＭＬドキュメント１０７である。

以下の例は、上記のＸＳＤ及びサンプルＸＭＬに対するプロデューサ動作、消費者動作、及びファイル変換動作を実証する。

第１のステップは、ＸＭＬＢｅａｎｓクラスを生成することである。ＸＭＬＢｅａｎｓクラスを生成するために以下のコマンドが用いられる。

このコマンドは、ＸＭＬＢｅａｎｓを拡張するＪａｖａ（登録商標）インターフェース・クラスを生成する。以下は、このプロセスによって生成されるサンプル・インターフェースＪａｖａ（登録商標）クラスのリストである。

トランスレーション層１０６は、動作するのにアプリケーション・データ・オブジェクトを必要とする。それらは、プロデューサ・トランスレータによってＸＭＬを生成するのに用いられる。消費者トランスレータは、抽出されたＸＭＬからそれらのインスタンスを作成する。データ・オブジェクトは、如何なるＸＭＬイベント又はＸＭＬＢｅａｎｓオブジェクトをも意識しない。しかしながら、それらは、プロデューサ・トランスレータによって用いられるときにそれらからデータを抽出する方法を提供し、且つ消費者トランスレータによって用いられるときにデータをポピュレートする方法を提供する必要がある。例証する目的で、我々は、アプリケーション１０１が、サンプルＸＭＬにおいて表されるデータを要約するために以下の３つのクラスを有すると仮定する。
●トランザクションＩＤ（ｔｒａｎｓａｃｔｉｏｎ ＩＤ）、トランザクション日付（ｔｒａｎｓａｃｔｉｏｎ ｄａｔｅ）、及びＸＭＬドキュメントの送信元（ｓｅｎｄｅｒ）についての情報のようなヘッダ・レベル・データを要約する、ＨｅａｄｅｒＤｔｏ。
●ｉｔｅｍのｉｎｖｅｎｔｏｒｙ情報を要約する、ＩｎｖｅｎｔｏｒｙＤｔｏ。
●ｐｒｏｍｏｔｉｏｎデータを要約する、ＰｒｏｍｏｔｉｏｎＤｔｏ。

これらのクラスの例が以下に示される。

前に述べたように、プロデューサ・トランスレータ・クラスは、ＰｒｏｄｕｃｅｒＴｒａｎｓｌａｔｏｒインターフェースを実装し、消費者トランスレータ・クラスは、ＣｏｎｓｕｍｅｒＴｒａｎｓｌａｔｏｒインターフェースを実装する。

ＰｒｏｄｕｃｅｒＴｒａｎｓｌａｔｏｒ（プロデューサ・トランスレータ）
一実施形態において、フレームワーク１０２は、３つの異なる方法のいずれかでＸＭＬドキュメント１０７を生成することができる。
●ＸＭＬドキュメント全体１０７を同時に生成する。この手法は、ｉｎｖｅｎｔｏｒｙ及びｐｒｏｍｏｔｉｏｎ要素が過多に存在しないときに実行可能である。アプリケーション１０１は、ＸＭＬドキュメント全体１０７を生産するのに必要とされるすべてのデータを有するアプリケーション・データ・オブジェクトを提供する。しかしながら、一実施形態において、ＸｍｌＣｏｎｓｕｍｅｒインターフェース規約は、単一のオブジェクトのみを渡すことを可能にする。この事例において、データは、複数のデータ・オブジェクト、すなわちＨｅａｄｅｒＤｔｏインスタンス、ＩｎｖｅｎｔｏｒｙＤｔｏ［］インスタンス、及びＰｒｏｍｏｔｉｏｎＤｔｏ［］インスタンスに要約される。これは、２つの方法のうちの１つ、すなわち、すべてのオブジェクトを別のオブジェクトの中にラップすること、又はそれらのすべてをＨａｓｈＭａｐに入れることのいずれかで行うことができる。例証する目的で、この例ではＨａｓｈＭａｐ手法が用いられるであろう。
●セグメントｔｒａｎｓａｃｔｉｏｎＩｎｆｏ、ｉｎｖｅｎｔｏｒｙ、及びｐｒｏｍｏｔｉｏｎｓを所与の順番で付加することによって、ＸＭＬドキュメント１０７を増加的に生成する。アプリケーション１０１は、各セグメントをＸＭＬに追記することができるように、Ｈｅａｄｅｒインスタンス、Ｉｎｖｅｎｔｏｒｙ［］インスタンス、及びＰｒｏｍｏｔｉｏｎ［］インスタンスを順次にフレームワーク１０２に渡す。
●ＸＭＬセグメントｔｒａｎｓａｃｔｉｏｎＩｎｆｏを生成し、次いで、セグメントｉｎｖｅｎｔｏｒｙを開き、そのサブセグメントｉｔｅｍを順次に付加する。同様に、開かれたセグメントｐｒｏｍｏｔｉｏｎｓを生成し、且つサブセグメントｐｒｏｍｏｔｉｏｎを順次に付加する。アプリケーション１０１は、ｔｒａｎｓａｃｔｉｏｎＩｎｆｏ ＸＭＬセグメントを生成することができるように、ＨｅａｄｅｒＤｔｏインスタンスを渡す。開かれたセグメントｉｎｖｅｎｔｏｒｙは、ｔｒａｎｓａｃｔｉｏｎＩｎｆｏセグメントに追従し、ＩｎｖｅｎｔｏｒｙＤｔｏオブジェクトのインスタンスは、フレームワーク１０２に順次に渡される。ｐｒｏｍｏｔｉｏｎｓに対して同じプロセス（ｉｎｖｅｎｔｏｒｙの事例のように）が繰り返される。

プロデューサ・トランスレータ・クラスは、これらの事例の各々を取り扱うことができ、したがって、これは、すべての３つの事例において対応するＸＭＬＯｂｊｅｃｔをインスタンス化することができる。

特性ファイルは、例えば以下のエントリを付加することによって、このトランスレータ・クラスを用いるように構成される。

ＸＭＬドキュメント全体１０７を同時に生成するために、アプリケーション１０１は、ＸＭＬドキュメント１０７を生成するのに必要とされるデータを（ＤＴＯの形態で）提供する。トランスレータ・クラスは、アプリケーション１０１が達成しようとしていることを理解することができるような方法で実装される。例えば、アプリケーション１０１は、アプリケーション・データ・オブジェクトのインスタンス、すなわち、キーヘッダ、ｉｎｖｅｎｔｏｒｙ、及びｐｒｏｍｏｔｉｏｎｓをそれぞれ伴うＨｅａｄｅｒＤｔｏ、ＩｎｖｅｎｔｏｒｙＤｔｏ［］アレイ、及びＰｒｏｍｏｔｉｏｎ［］アレイを収容するＨａｓｈＭａｐを渡してもよい。このパラメータを受信すると、フレームワーク１０２は、ＸＭＬドキュメント１０７全体を生成することができる。この手法によって生成されたＸＭＬドキュメント１０７の例は以下の通りである。

ＸＭＬドキュメント１０７を増加的に生成するために、ｔｒａｎｓａｃｔｉｏｎＩｎｆｏセグメント、ｉｎｖｅｎｔｏｒｙセグメント、及びｐｒｏｍｏｔｉｏｎｓセグメントが順次に付加される。例えば、フレームワーク１０２は、ＨｅａｄｅｒＤｔｏからｔｒａｎｓａｃｔｉｏｎＩｎｆｏ ＸＭＬセグメントを生成し、ＩｎｖｅｎｔｏｒｙＤｔｏ［］アレイ・インスタンスからｉｎｖｅｎｔｏｒｙセグメントを生成し、及びＰｒｏｍｏｔｉｏｎＤｔｏ［］アレイ・インスタンスからｐｒｏｍｏｔｉｏｎｓを生成する。

セグメント及びサブセグメントを順次に付加することによってＸＭＬドキュメント１０７を生成するために、ｔｒａｎｓａｃｔｉｏｎＩｎｆｏセグメントが最初に付加され、その後、ｉｎｖｅｎｔｏｒｙサブセグメントｉｔｅｍ、及びｐｒｏｍｏｔｉｏｎｓサブセグメントｐｒｏｍｏｔｉｏｎが順次に付加される。フレームワーク１０２は、最初にＨｅａｄｅｒＤｔｏインスタンスからｔｒａｎｓａｃｔｉｏｎＩｎｆｏ ＸＭＬセグメントを生成する。次に、これは、ｉｎｖｅｎｔｏｒｙに対する開かれたセグメントを付加し、且つすべてのそのサブセグメントを順次に付加する。ｉｎｖｅｎｔｏｒｙセグメントを閉じた後で、開かれたセグメントｐｒｏｍｏｔｉｏｎｓが付加される。そのサブセグメントのすべては、後で順次に付加される。ｃｌｏｓｅＡｌｌ（）へのコールは、それらが開かれた順番にすべての開かれたセグメントを閉じる。

消費者トランスレータ
一実施形態において、フレームワーク１０２は、３つの異なる方法のいずれかでＸＭＬドキュメント１０７を処理することができる。
●（ｔｒａｎｓａｃｔｉｏｎＩｎｆｏ、ｉｎｖｅｎｔｏｒｙ、及びｐｒｏｍｏｔｉｏｎｓのような）セグメントを順次に抽出する。アプリケーション１０１は、これらを順次に取り出すことができる。これらのセグメントのうちのすべてのサブセグメントは、それぞれのセグメントと一緒に取り出されるであろう。
●セグメントｔｒａｎｓａｃｔｉｏｎＩｎｆｏを抽出し、次いで、セグメントｉｎｖｅｎｔｏｒｙを開き、その後、そのサブセグメント（ｉｔｅｍ）を順次に抽出する。最後に、セグメントｐｒｏｍｏｔｉｏｎｓを開き、その後、そのサブセグメント（ｐｒｏｍｏｔｉｏｎ）を順次に抽出する。
●構成ファイルで指定された場合にＸＭＬドキュメント１０７をフラットファイルに変換する。

消費者トランスレータ・クラスは、これらの事例のいずれかを取り扱うために用いられる。

特性ファイルは、例えば以下のエントリを付加することによって、このトランスレータ・クラスを用いるように構成される。

これらのエントリは、フレームワーク１０２に以下のように指示する。
●トランスレーションのためにＩｎｖｅｎｔｏｒｙＣｏｎｓｕｍｅｒＴｒａｎｓｌａｔｏｒクラスを用いる。
●ＸＳＤ確認に失敗するセグメント／サブセグメントを含まないこと。
●ＸＳＤ確認エラーをログすること。
●ルートノードの３つの子、すなわち、ｔｒａｎｓａｃｔｉｏｎＩｎｆｏ、ｉｎｖｅｎｔｏｒｙ、及びｐｒｏｍｏｔｉｏｎｓが存在し、これらはセグメントと呼ばれる。
●ｉｔｅｍは、ｉｎｖｅｎｔｏｒｙセグメントの唯一のサブセグメント（子ノード）である。
●ｐｒｏｍｏｔｉｏｎは、ｐｒｏｍｏｔｉｏｎｓセグメントの唯一のサブセグメント（子ノード）である。

上記で解説されたように、フレームワーク１０２は、所望の場合にセグメント（ｔｒａｎｓａｃｔｉｏｎＩｎｆｏ、ｉｎｖｅｎｔｏｒｙ、及びｐｒｏｍｏｔｉｏｎｓ）を順次に抽出することによって、ＸＭＬドキュメント１０７を処理することができる。こうした処理によって生成される出力の例は、以下の通りである。

ｐｒｏｍｏｔｉｏｎ及びｉｔｅｍサブセグメントは、順次に処理することができる。サブセグメントを順次に処理することは、多数のサブセグメントが期待されるときに有用なことがあり、それらのすべてを一緒に抽出することは、アプリケーション１０１にメモリを使い果たさせる場合がある。

最初に、フレームワーク１０２は、固定されたサイズのセグメントｔｒａｎｓａｃｔｉｏｎＩｎｆｏを処理する。ｔｒａｎｓａｃｔｉｏｎＩｎｆｏセグメントを処理した後で、アプリケーション１０１は、フレームワーク１０２に、ｉｎｖｅｎｔｏｒｙセグメントを開き、且つｉｔｅｍサブセグメントを順次に処理するように依頼する。最後に、アプリケーション１０１は、フレームワーク１０２に、セグメントｐｒｏｍｏｔｉｏｎｓを開き、且つサブセグメントｐｒｏｍｏｔｉｏｎを順次に処理するように依頼する。

ＸＭＬドキュメント１０７をフラットファイルにトランスレートするときに、変換されたデータは、ＸＭＬにより指定されたものとアプリケーションにより指定されたものとの２つの異なるソースを有する。抽出されることになるＸＭＬデータは、ＸＰａｔｈｓを用いて表され、アプリケーションにより指定されたデータは、ｓｅｓｓｉｏｎ ｄａｔａとして表される。一実施形態において、データは、書き込まれることになるフラットファイルの各セクション、すなわち、ヘッダ、ボディ、及びフッタに対して適切に構成される。例えば、ヘッダは、すべてがｔｒａｎｓａｃｔｉｏｎＩｎｆｏセグメントから来る以下のフィールドを含むものと想定する。
●ｔｒａｎｓａｃｔｉｏｎＩｄ
●ｓｅｎｄｅｒ Ｉｄ
●ｓｅｎｄｅｒ Ｎａｍｅ

フラットファイルのボディは、ｉｎｖｅｎｔｏｒｙセグメント及びｐｒｏｍｏｔｉｏｎｓセグメントからのフィールドを含むものと想定する。サブセグメントに対応しているフィールドは、変換されたファイルにおけるボディ・レコードを構成するであろう。ｔｒａｎｓａｃｔｉｏｎＩｎｆｏセグメントからのＳｅｎｄｅｒ Ｉｄ及びｔｒａｎｓａｃｔｉｏｎ Ｉｄは、クロスリファレンスを介して含まれるであろう。また、各ｉｎｖｅｎｔｏｒｙレコードは、ワードＩＮＶＥＮＴＯＲＹで始まり、ｐｒｏｍｏｔｉｏｎレコードは、ワードＰＲＯＭＯＴＩＯＮで始まるべきである。そのうえ、累積レコード・カウント及びアプリケーションにより指定されたフィールド、すなわち処理日付もまた付加されることになると想定する。以下のフィールドは、フラットファイルにおけるｉｎｖｅｎｔｏｒｙ／ｐｒｏｍｏｔｉｏｎ及びフッタ・レコードを構成する。
●Ｉｎｖｅｎｔｏｒｙセグメント
○ＩＮＶＥＮＴＯＲＹというそのままのワード
○ｔｒａｎｓａｃｔｉｏｎＩｎｆｏセグメントからのｓｅｎｄｅｒ Ｉｄ
○ｉｔｅｍ ｉｄ
○ａｖａｉｌａｂｉｌｉｔｙ ｃｏｄｅ（利用可能コード）
○ａｖａｉｌａｂｉｌｉｔｙ ｑｕａｎｔｉｔｙ（利用可能量）
○アプリケーション・データ−ｐｒｏｃｅｓｓｉｎｇ ｄａｔｅ（処理日付）
○ｔｒａｎｓａｃｔｉｏｎＩｎｆｏセグメントからのｔｒａｎｓａｃｔｉｏｎ ｉｄ
○ｉｎｖｅｎｔｏｒｙセグメント内の累積ｉｔｅｍレコード・カウント
●Ｐｒｏｍｏｔｉｏｎｓセグメント
○ＰＲＯＭＯＴＩＯＮというそのままのワード
○ｔｒａｎｓａｃｔｉｏｎＩｎｆｏセグメントからのｓｅｎｄｅｒ Ｉｄ
○ｐｒｏｍｏｔｉｏｎコード
○ｔｒａｎｓａｃｔｉｏｎＩｎｆｏセグメントからのｔｒａｎｓａｃｔｉｏｎ ｉｄ
○ｐｒｏｍｏｔｉｏｎｓセグメント内の累積ｐｒｏｍｏｔｉｏｎレコード・カウント
●Ｆｏｏｔｅｒ（フッタ）
○ｔｒａｎｓａｃｔｉｏｎＩｎｆｏセグメントからのｔｒａｎｓａｃｔｉｏｎ ｉｄ
○ｉｔｅｍレコードの数
○ｐｒｏｍｏｔｉｏｎレコードの数
○ｐｒｏｍｏｔｉｏｎレコードとｉｔｅｍレコードの総数。

以下は、上記のフィールドを変換されたファイルに含めるための構成の例である。

１つのセグメントから別のセグメントにクロスリファレンスされているフィールドは、クロスリファレンスｃｏｎｆｉｇのリストに含まれる。

結果として得られるフラットファイルの例は以下の通りである。

この例において、フレームワーク１０２は、すべてのアプリケーションにより付加されたデータのｔｏＳｔｒｉｎｇ（）関数の出力を用いる。デフォルト・レコード・セパレータ（新しいライン）及びデフォルト・フィールド・セパレータ（｜）は、それらが指定されていなかった場合に用いられる。

一実施形態において、ＸＳＤ確認エラーメッセージは、それらに付加的な情報を追記することによってカスタマイズすることができる。例えば、ｉｔｅｍサブセグメントがＸＳＤ確認に失敗するときにはいつも、ｔｒａｎｓａｃｔｉｏｎＩｄ（クロスリファレンスを介して）及びｉｔｅｍＩｄを付加することを我々が望むと想定する。ｔｒａｎｓａｃｔｉｏｎＩｄに対する表示名は、ＴＲＡＮＳＡＣＴＩＯＮ ＩＤとなるべきであり、ｉｔｅｍＩｄに対する表示名は、Ｉｔｅｍ ＃となるべきである。このカスタマイゼーションに対する構成エントリは、以下のようになる可能性がある。

エラーメッセージは、次いで、以下のように読み出されるであろう。

角括弧内の情報は、無効なｉｔｅｍセグメントに遭遇するときの包含のためにフレームワーク１０２（構成される場合に）によって付加されている。

結論
上記の説明に基づいて、種々の実施形態において、本発明のシステムは、従来技術のスキームを上回る幾つかの利点を提供することが分かる。本発明のシステムは、任意のサイズのＸＭＬドキュメントをシリアルに処理し及び／又は生成することができるように、ＳｔＡＸパーサのストリーミング及び融通性をＸＭＬＢｅａｎｓのパワー及び使いやすさと組み合わせる。加えて、アプリケーション・コードは、ＸＭＬドキュメントのパーシング及び処理の詳細から隔離することができ、アプリケーション・コードを維持しやすいものにし、且つアプリケーションに影響を及ぼすことなく他のＸＭＬ技術でのスワップ・アウトを容易にする。

種々の実施形態において、本発明は、上記で説明された技術を単独で又はあらゆる組合せでのいずれかで行うためのシステム又は方法として実装することができる。別の実施形態において、本発明は、コンピューティング・デバイス又は他の電子装置におけるプロセッサに上記で説明された技術を行わせるための、一時的なものではないコンピュータ可読記憶媒体と、該媒体上でエンコードされるコンピュータ・プログラム・コードとを備えるコンピュータ・プログラム製品として実装することができる。

本明細書における「一実施形態」又は「実施形態」への言及は、実施形態との関連において説明された特定の機能ｆｅａｔｕｒｅ、構造、又は特徴が、本発明の少なくとも１つの実施形態に含まれることを意味する。本明細書の種々の場所での「一実施形態において」という語句の出現は、必ずしもすべてが同じ実施形態を言及するわけではない。

上記の幾つかの部分は、コンピュータ・メモリ内のデータ・ビット上の動作のアルゴリズム及び象徴的表現の観点で提示される。これらのアルゴリズム記述及び表現は、それらの研究の実体を他の当業者に最も効果的に伝えるためにデータ処理分野の当業者によって用いられる手段である。アルゴリズムは、ここでは及び一般に、所望の結果につながる、つじつまの合う一連のステップ（命令）となると考えられる。ステップは、物理的量の物理的操作を要求するものである。普通は、必ずしもそうであるわけではないが、これらの量は、格納する、伝送する、組み合わせる、比較する、変換する、及び他の方法で操作することができる電気信号、磁気信号、又は光信号の形態をとる。時には、主として恒例（ｃｏｍｍｏｎ ｕｓａｇｅ）の理由で、これらの信号を、ビット、値、要素、記号（ｓｙｍｂｏｌ）、文字（ｃｈａｒａｃｔｅｒ）、用語（ｔｅｒｍ）、数、又はそれに類似のものとして言及するのが便利である。そのうえ、時には、一般性を失わずに、物理的量の物理的操作を要求するステップの或る配置を、モジュール又はコード・デバイスとして言及するのも便利である。

しかしながら、これらの及び類似した用語のすべては、適切な物理的量と関連付けられるものであって、これらの量に貼られる単なる便利なラベルであることに留意されたい。特にそれ以外の指定のない限り、以下の解説から明らかなように、説明の全体を通して、「処理する」又は「コンピューティング」又は「計算する」又は「判定する」又は「表示する」又はそれに類似のもののような用語を用いる解説は、コンピュータ・システム・メモリ又はレジスタ若しくは他のこうした情報記憶装置、伝送デバイス、又はディスプレイ・デバイス内の物理的（電子）量として表されるデータを操作し及び変換するコンピュータ・システム又は類似した電子コンピューティング・デバイスのアクション及びプロセスを言及することが分かる。

本発明の或る態様は、アルゴリズムの形態の本明細書に記載のプロセス・ステップ及び命令を含む。本発明のプロセス・ステップ及び命令は、ソフトウェア、ファームウェア、又はハードウェアにおいて具体化することができ、ソフトウェアにおいて具体化されるときに、種々のオペレーティング・システムによって用いられる異なるプラットフォーム上に常駐するようにダウンロードし及びそこから動作することができることに注意されたい。

本発明はまた、本明細書の動作を行うための装置に関する。この装置は、要求された目的のために特別に構築されてもよく、又は、これは、コンピュータに格納されたコンピュータ・プログラムによって選択的にアクティブ化され又は再構成される１つ又は複数の汎用コンピュータ（単数又は複数）を備えてもよい。こうしたコンピュータ・プログラムは、限定はされないが、電子命令を格納するのに適しており、且つ各々がコンピュータ・システム・バスに結合される、フロッピー（登録商標）・ディスク、光ディスク、ＣＤ−ＲＯＭ、磁気−光ディスク、読出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気又は光学カード、特定用途向け集積回路（ＡＳＩＣ）、又はあらゆるタイプの媒体を含むあらゆるタイプのディスクのようなコンピュータ可読記憶媒体に格納されてもよい。そのうえ、本明細書において言及されるコンピュータ及び／又は他の電子装置は、単一のプロセッサを含んでもよく、又は、増加したコンピューティング能力のための多数のプロセッサ設計を採用するアーキテクチャであってもよい。一実施形態において、上記で説明された幾つかの又はすべての機能性コンポーネントは、ソフトウェアの制御の下で上記で説明されたステップを行うプロセッサを含むコンピュータ・ハードウェアとして実装される。

本明細書で提示されるアルゴリズム及び表示は、如何なる特定のコンピュータ又は他の装置とも本質的に関係付けられない。種々の汎用システムもまた本明細書の教示に係るプログラムと共に用いられる可能性があり、又は要求される方法ステップを行うためにより特化された装置を構築することが便利であることを証明する可能性がある。種々のこれらのシステムに対して要求される構造は、以下の説明から明らかとなるであろう。加えて、本発明は、如何なる特定のプログラミング言語にも関連して説明されない。種々のプログラミング言語は、本明細書で説明される場合の本発明の教示を実装するのに用いられてもよく、固有の言語への以下のあらゆる言及は、本発明の実施可能モード及び最良モードを開示するために提供されることが理解されるであろう。

したがって、種々の実施形態において、本発明は、コンピュータ・システム、コンピューティング・デバイス、又は他の電子装置、又はクライアント／サーバアーキテクチャ、又はそのあらゆる組合せ又は複数を制御するためのソフトウェア、ハードウェア、又は他の要素として実装することができる。本発明のシステムを実装するためのハードウェアは、例えば、当該技術分野では周知の技術に係るプロセッサ、入力デバイス（キーボード、マウス、タッチパッド、トラックパッド、ジョイスティック、トラックボール、マイクロフォン、及び／又はその任意の組合せのような）、出力デバイス（スクリーン、スピーカ、及び／又はそれに類似のもののような）、メモリ、長期記憶装置（磁気記憶装置、光学記憶装置、及び／又はそれに類似のもののような）、及び／又はネットワーク接続性を含むことができる。こうした電子装置は、ポータブルのものであってもよいし、又はポータブルのものでなくてもよい。本発明を実装するために用いられてもよい電子装置（又は本発明のコンポーネント）の例は、移動電話、パーソナル・デジタル・アシスタント、スマートフォン、公衆電話ボックス（ｋｉｏｓｋ）、デスクトップ・コンピュータ、ラップトップ・コンピュータ、消費者向け電子装置、テレビ、セットトップ・ボックス、又はそれに類似のものを含む。本発明を実装するための電子装置は、例えば、Ｒｅｄｍｏｎｄ、ＷａｓｈｉｎｇｔｏｎのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） ７のようなオペレーティング・システム、又はデバイス上で用いるために適合されるあらゆる他のオペレーティング・システムを用いてもよい。

最後に、本明細書で用いられる言語は、主として、読みやすさ及び教育上の目的のために選択されており、発明的な主題を描写する又は局限するように選択されているわけではないことに注意されたい。したがって、本発明の開示は、以下の請求項に記載される本発明の範囲を限定するのではなく、例証となることを意図される。

本発明は、好ましい実施形態及び幾つかの代替的実施形態を参照して具体的に示され説明されているが、本発明の精神及び範囲から逸脱することなく形態及び詳細における種々の変化をそこに加えることができることが当業者には理解されるであろう。

Claims (32)

1. ＸＭＬドキュメントを処理するためのコンピュータで実行される方法であって、
   プロセッサにおいて、ＸＭＬドキュメントからのデータを要求するメッセージをアプリケーションから受信すること、
   プロセッサにおいて、前記メッセージを受信することに応答して、
   前記ＸＭＬドキュメントから、要求された前記データを表わす少なくとも１つのセグメントを取り出すこと、
   取り出された前記少なくとも１つのセグメントをオブジェクトベースのＸＭＬ表現に変換すること、
   前記オブジェクトベースのＸＭＬ表現を少なくとも１つのアプリケーション・データ・オブジェクトに変換すること、
   プロセッサにおいて、前記少なくとも１つのアプリケーション・データ・オブジェクトを前記アプリケーションに伝送すること、
   を含む方法。
2. 前記オブジェクトベースのＸＭＬ表現を少なくとも１つのアプリケーション・データ・オブジェクトに変換することが、少なくとも１つのＸＭＬデータ・オブジェクトを少なくとも１つのアプリケーション−ドメイン・オブジェクトにトランスレートすることを含み、
   抽出された前記少なくとも１つのアプリケーション・データ・オブジェクトを前記アプリケーションに伝送することが、トランスレートされた前記アプリケーション−ドメイン・オブジェクトを前記アプリケーションに伝送することを含む、
   請求項１に記載の方法。
3. 前記オブジェクトベースの表現が、ＸＭＬ−バインディング・フレームワークにおけるオブジェクトを含む、請求項１に記載の方法。
4. 前記オブジェクトベースの表現が、ＸＭＬＢｅａｎｓオブジェクトを含む、請求項１に記載の方法。
5. 要求された前記データを表わす少なくとも１つのセグメントを取り出すことが、
   前記少なくとも１つのセグメントを取り出すためにパーサに要求を送信すること、及び、
   前記パーサから前記セグメントを受信すること、
   を含む、請求項１に記載の方法。
6. 前記パーサがＳｔＡＸパーサを含む、請求項５に記載の方法。
7. プロセッサにおいて、前記オブジェクトベースの表現を確認することをさらに含む、請求項１に記載の方法。
8. 前記オブジェクトベースの表現を確認することが、
   プロセッサにおいて、前記オブジェクトベースの表現の、ＸＭＬスキーマ定義に対する確認を行うことを含む、請求項７に記載の方法。
9. 前記ＸＭＬドキュメントから、要求された前記データを表わす少なくとも１つのセグメントを取り出すことが、
   プロセッサにおいて、少なくとも１つのセグメントを取り出すこと、及び、
   プロセッサにおいて、取り出された前記セグメントの少なくとも１つのサブセグメントを再帰的に取り出すこと、
   を含む、請求項１に記載の方法。
10. 前記ＸＭＬドキュメントから、要求された前記データを表わす少なくとも１つのセグメントを取り出すことが、
    プロセッサにおいて、構成から前記ＸＭＬドキュメントの前記少なくとも１つのセグメントのロケーションを要求すること、
    プロセッサにおいて、要求された前記ロケーションを受信すること、及び、
    プロセッサにおいて、要求された前記ロケーションからデータを取り出すこと、
    を含む、請求項１に記載の方法。
11. 要求された前記ロケーションからデータを取り出すことが、
    プロセッサにおいて、前記データを取り出すためにパーサに前記ＸＭＬドキュメントをパースするようにコールすることを含む、請求項１０に記載の方法。
12. 前記ＸＭＬドキュメントから、要求された前記データを表わす少なくとも１つのセグメントを取り出すことが、
    プロセッサにおいて、前記ＸＭＬドキュメント内のロケーションのトラックを保つためにセグメント・カーソルをインスタンス化すること、
    プロセッサにおいて、前記セグメント・カーソルに対応しているロケーションでデータを取り出すこと、
    を含む、請求項１に記載の方法。
13. ＸＭＬドキュメントを生成するためのコンピュータで実行される方法であって、
    プロセッサにおいて、アプリケーションからデータ・オブジェクトを受信すること、
    プロセッサにおいて、前記データ・オブジェクトをＸＭＬ−バインディング・フレームワークにおけるオブジェクトにトランスレートすること、
    プロセッサにおいて、前記ＸＭＬ−バインディング・フレームワークにおける前記オブジェクトをＸＭＬセグメントに変換すること、及び、
    前記ＸＭＬセグメントをデータストアに書き込むこと、
    を含む、方法。
14. 前記ＸＭＬ−バインディング・フレームワークにおける前記オブジェクトが、ＸＭＬＢｅａｎｓオブジェクトを含む、請求項１３に記載の方法。
15. 前記ＸＭＬセグメントをデータストアに書き込むことが、新しいＸＭＬドキュメントを作成することを含む、請求項１３に記載の方法。
16. 前記ＸＭＬセグメントをデータストアに書き込むことが、前記ＸＭＬセグメントを既存のＸＭＬドキュメントに追記することを含む、請求項１３に記載の方法。
17. 前記ＸＭＬセグメントが複数のデータ要素を含み、前記ＸＭＬセグメントをデータストアに書き込むことが、
    プロセッサにおいて、前記データ要素を増加的に書き込むことを含む、請求項１３に記載の方法。
18. 前記ＸＭＬセグメントの少なくとも１つのデータ要素がエンドタグを含み、前記データ要素を増加的に書き込むことが、
    プロセッサにおいて、前記ＸＭＬセグメントの要素に対する少なくとも１つのエンドタグを除去すること、
    プロセッサにおいて、除去された前記エンドタグをスタック上にプッシュすること、
    プロセッサにおいて、子データ要素を増加的に前記データストアに書き込むこと
    プロセッサにおいて、前記スタックから前記ＸＭＬセグメントに対する前記少なくとも１つのエンドタグをポップすること、
    プロセッサにおいて、ポップされた前記エンドタグを前記データストアに書き込むこと、
    を含む、請求項１３に記載の方法。
19. ＸＭＬドキュメントをフラットファイルに変換するためのコンピュータで実行される方法であって、少なくとも１つのプロセッサを含むコンピューティング・システムにおいて、
    プロセッサにおいて、ＸＭＬドキュメントをフラットファイルに変換するために要求を受信すること、
    プロセッサにおいて、前記フラットファイルに対する構成を得ること、
    プロセッサにおいて、前記ＸＭＬドキュメントの少なくとも１つのセグメントを取り出すこと、
    プロセッサにおいて、取り出された前記少なくとも１つのセグメントをオブジェクトベースの表現に変換すること、
    プロセッサにおいて、前記オブジェクトベースの表現から少なくとも１つのオブジェクトを抽出すること、
    プロセッサにおいて、抽出された前記少なくとも１つのオブジェクトを表わすデータを、前記得られた構成によって指定されるフォーマットで、前記フラットファイルに書き込むこと、
    を含む、方法。
20. プロセッサにおいて、得られた前記構成によって指定される前記フォーマットに応答して、前記ＸＭＬドキュメントの少なくとも１つのセグメントから少なくとも１つのデータ項目を導出すること、
    プロセッサにおいて、導出された前記データを前記フラットファイルに書き込むこと、
    をさらに含む、請求項１９に記載の方法。
21. ＸＭＬドキュメントをフラットファイルに変換するためのコンピュータで実行される方法であって、少なくとも１つのプロセッサを含むコンピューティング・システムにおいて、
    プロセッサにおいて、ＸＭＬドキュメントをフラットファイルに変換するために要求を受信すること、
    プロセッサにおいて、前記フラットファイルに対する構成を得ること、
    プロセッサにおいて、前記ＸＭＬドキュメントの第１のセグメントを取り出すこと、
    プロセッサにおいて、前記第１のセグメントをオブジェクトベースの表現に変換すること、
    プロセッサにおいて、前記ＸＭＬドキュメントの第１のセグメントと前記ＸＭＬドキュメントの第２のセグメントとの間の少なくとも１つのクロスリファレンスの指示を受信すること、
    プロセッサにおいて、少なくとも１つのクロスリファレンスの前記指示に基づいて、前記ＸＭＬドキュメントの前記第１の部分のオブジェクトベースの表現から抽出される少なくとも１つのクロスリファレンスされる値をメモリ内に維持すること、
    プロセッサにおいて、前記ＸＭＬドキュメントの前記第２のセグメントを取り出すこと、
    プロセッサにおいて、前記第２のセグメントをオブジェクトベースの表現に変換すること、
    プロセッサにおいて、前記ＸＭＬドキュメントの前記第１の部分の前記オブジェクトベースの表現から少なくとも１つのオブジェクトを抽出すること、
    プロセッサにおいて、前記ＸＭＬドキュメントの前記第２の部分の前記オブジェクトベースの表現から少なくとも１つのオブジェクトを抽出すること、
    プロセッサにおいて、前記ＸＭＬドキュメントの前記第１の部分及び前記第２の部分の前記オブジェクトベースの表現から抽出されるオブジェクトを表わすデータを、得られた前記構成によって指定されるフラットファイル・フォーマットで書き込むこと、
    を含む、方法。
22. 前記ＸＭＬドキュメントの前記第１の部分及び前記第２の部分の前記オブジェクトベースの表現から抽出されるオブジェクトを表わすデータを書き込むことが、
    前記フラットファイルに対する前記構成によって指定される様式で前記ＸＭＬドキュメントの前記第１の部分及び前記第２の部分からのデータを組み合わせること、
    を含む、請求項２１に記載の方法。
23. 前記ＸＭＬドキュメントの前記第１の部分の前記オブジェクトベースの表現から抽出される前記少なくとも１つのクロスリファレンスされる値をメモリ内に維持することが、
    前記ＸＭＬドキュメントの前記第１の部分の前記オブジェクトベースの表現から抽出される各クロスリファレンスされる値をメモリ・ロケーション内に格納し、且つ前記値をエイリアスによって識別すること、
    を含む、請求項２１に記載の方法。
24. 前記少なくとも１つのクロスリファレンスされる値を格納した後で、メモリから前記第１の部分の前記オブジェクトベースの表現を廃棄すること、
    をさらに含む、請求項２１に記載の方法。
25. プロセッサにおいて、得られた前記構成によって指定される前記フォーマットに応答して、前記ＸＭＬドキュメントの前記第１の部分及び前記第２の部分のうちの少なくとも１つから少なくとも１つのデータ項目を導出すること、
    プロセッサにおいて、前記導出されたデータを前記フラットファイルに書き込むこと、をさらに含む、請求項２１に記載の方法。
26. ＸＭＬドキュメントを処理するためのコンピュータ・プログラム製品であって、
    一時的なものでないコンピュータ可読記憶媒体と、
    コンピュータ・プログラム・コードであって、少なくとも１つのプロセッサに、
    ＸＭＬドキュメントからのデータを要求するメッセージをアプリケーションから受信するステップと、
    前記メッセージを受信するステップに応答して、
    前記ＸＭＬドキュメントから、要求された前記データを表わす少なくとも１つのセグメントを取り出し、
    取り出された前記少なくとも１つのセグメントをオブジェクトベースのＸＭＬ表現に変換し、及び、
    前記オブジェクトベースのＸＭＬ表現を少なくとも１つのアプリケーション・データ・オブジェクトに変換し、
    前記少なくとも１つのアプリケーション・データ・オブジェクトを前記アプリケーションに伝送するステップと、
    を行わせるための、媒体上でエンコードされるコンピュータ・プログラム・コードと、
    を備えるコンピュータ・プログラム製品。
27. ＸＭＬドキュメントを生成するためのコンピュータ・プログラム製品であって、
    一時的なものでないコンピュータ可読記憶媒体と、
    コンピュータ・プログラム・コードであって、少なくとも１つのプロセッサに、
    アプリケーションからデータ・オブジェクトを受信するステップと、
    前記データ・オブジェクトをＸＭＬ−バインディング・フレームワークにおけるオブジェクトにトランスレートするステップと、
    前記ＸＭＬ−バインディング・フレームワークにおける前記オブジェクトをＸＭＬセグメントに変換するステップと、
    前記ＸＭＬセグメントをデータストアに書き込むステップと、
    を行わせるための、媒体上でエンコードされるコンピュータ・プログラム・コードと、
    を備えるコンピュータ・プログラム製品。
28. ＸＭＬドキュメントをフラットファイルに変換するためのコンピュータ・プログラム製品であって、
    一時的なものでないコンピュータ可読記憶媒体と、
    コンピュータ・プログラム・コードであって、少なくとも１つのプロセッサに、
    ＸＭＬドキュメントをフラットファイルに変換する要求を受信するステップと、
    前記フラットファイルに対する構成を得るステップと、
    前記ＸＭＬドキュメントの少なくとも１つのセグメントを取り出すステップと、
    取り出された前記少なくとも１つのセグメントをオブジェクトベースの表現に変換するステップと、
    前記オブジェクトベースの表現から少なくとも１つのオブジェクトを抽出するステップと、
    抽出された前記少なくとも１つのオブジェクトを表わすデータを、得られた前記構成によって指定されるフォーマットで前記フラットファイルに書き込むステップと、
    を行わせるための、媒体上でエンコードされるコンピュータ・プログラム・コードと、
    を備えるコンピュータ・プログラム製品。
29. ＸＭＬドキュメントをフラットファイルに変換するためのコンピュータ・プログラム製品であって、
    一時的なものでないコンピュータ可読記憶媒体と、
    コンピュータ・プログラム・コードであって、少なくとも１つのプロセッサに、
    ＸＭＬドキュメントをフラットファイルに変換する要求を受信するステップと、
    前記フラットファイルに対する構成を得るステップと、
    前記ＸＭＬドキュメントの第１のセグメントを取り出すステップと、
    前記第１のセグメントをオブジェクトベースの表現に変換するステップと、
    前記ＸＭＬドキュメントの第１のセグメントと前記ＸＭＬドキュメントの第２のセグメントとの間の少なくとも１つのクロスリファレンスの指示を受信するステップと、
    少なくとも１つのクロスリファレンスの前記指示に基づいて、前記ＸＭＬドキュメントの前記第１の部分の前記オブジェクトベースの表現から抽出される少なくとも１つのクロスリファレンスされる値をメモリ内に維持するステップと、
    前記ＸＭＬドキュメントの前記第２のセグメントを取り出すステップと、
    前記第２のセグメントをオブジェクトベースの表現に変換するステップと、
    前記ＸＭＬドキュメントの前記第１の部分の前記オブジェクトベースの表現から少なくとも１つの値を抽出するステップと、
    前記ＸＭＬドキュメントの前記第２の部分の前記オブジェクトベースの表現から少なくとも１つのオブジェクトを抽出するステップと、
    前記ＸＭＬドキュメントの前記第１の部分及び前記第２の部分の前記オブジェクトベースの表現から抽出されるオブジェクトを表わすデータを、得られた前記構成によって指定されるフラットファイル・フォーマットで書き込むステップと、
    を行わせるための、媒体上でエンコードされるコンピュータ・プログラム・コードと、
    を備えるコンピュータ・プログラム製品。
30. ＸＭＬドキュメントを処理するためのシステムであって、
    プロセッサを有するコンピューティング・システムにおいて、ＸＭＬドキュメントからのデータを要求するメッセージをアプリケーションから受信し、且つＸＭＬセグメントの抽出を要求するためのフレームワークと、
    要求された前記データを表わす少なくとも１つのセグメントを前記フレームワークに提供するための、前記フレームワークに通信可能に結合される、パーサと、
    前記取り出された少なくとも１つのセグメントをオブジェクトベースのＸＭＬ表現に変換し、且つ前記オブジェクトベースのＸＭＬ表現を少なくとも１つのアプリケーション・データ・オブジェクトに変換するための、前記フレームワークに通信可能に結合される、トランスレーション層と、
    を備え、前記フレームワークが、前記少なくとも１つのアプリケーション・データ・オブジェクトを前記アプリケーションに伝送する、システム。
31. ＸＭＬドキュメントを生成するためのシステムであって、
    プロセッサを有するコンピューティング・システムにおいて、アプリケーションからデータ・オブジェクトを受信するためのフレームワークと、
    前記データ・オブジェクトをＸＭＬ−バインディング・フレームワークにおけるオブジェクトにトランスレートし、且つ前記ＸＭＬ−バインディング・フレームワークにおける前記オブジェクトをＸＭＬセグメントに変換するための、前記フレームワークに通信可能に結合される、トランスレーション層と、
    前記ＸＭＬセグメントを格納するための、前記フレームワークに通信可能に結合される、データストアと、
    を備えるシステム。
32. ＸＭＬドキュメントをフラットファイルに変換するためのシステムであって、
    プロセッサを有するコンピューティング・システムにおいて、ＸＭＬドキュメントをフラットファイルに変換する要求を受信するためのフレームワークと、
    前記フラットファイルに対する構成を前記フレームワークに伝送するための、前記フレームワークに通信可能に結合される、コンフィギュレータと、
    前記構成に基づいて、前記ＸＭＬドキュメントの少なくとも１つのセグメントを取り出すための、前記フレームワークに通信可能に結合される、パーサと、
    取り出された前記少なくとも１つのセグメントをオブジェクトベースの表現に変換するための、前記フレームワークに通信可能に結合される、トランスレーション層と、
    前記フレームワークは、前記オブジェクトベースの表現から少なくとも１つのオブジェクトを抽出し、
    抽出された前記少なくとも１つのオブジェクトを、得られた前記構成によって指定されるフォーマットでフラットファイルに格納するための、前記フレームワークに通信可能に結合される、データストアと、
    を備えるシステム。

Images