(57)【特許請求の範囲】
【請求項１】
ネットワーク化されたコンピューティング環境におけるルーティング・デバイスが、ＸＭＬでエンコードされた入力文書をデータ・コンテンツに基づいてルーティングする方法であって、
（ａ）前記ＸＭＬでエンコードされた入力文書を、前記データ・コンテンツを文書構造から分離し、前記入力文書のツリー構造におけるノード指定に続いて前記データ・コンテンツを配置した、ｍＸＭＬでエンコードされた出力文書に変換するステップと、
（ｂ）前記ｍＸＭＬでエンコードされた出力文書の読取をするステップと、
（ｃ）前記読取をした出力文書が次にルーティングされるターゲットを識別するステップと、
（ｇ）前記ターゲットがｍＸＭＬでエンコードされた文書を処理できるかどうかを示す判定データを前記ターゲットから受信し、前記ターゲットの識別データと対応付けて記憶するステップと、
（ｄ）記憶した前記判定データを参照し、前記ターゲットがｍＸＭＬでエンコードされた文書を処理できるかどうかを判定するステップと、
を含む方法。
【請求項２】
前記ステップ（ｃ）が、前記読取をした出力文書を構文解析するステップを含む、請求項１に記載の方法。
【請求項３】
前記ステップ（ｃ）が、前記読取をした出力文書のルーティングのためにホスト名ストリングを識別するステップを含む、請求項２に記載の方法。
【請求項４】
前記ステップ（ａ）が、
（ａ１）前記入力文書の文書ツリー表現を作成するステップと、
（ａ２）前記文書ツリー表現内のノードのカウントを表すノード・カウントを得るステップと、
（ａ３）前記ノード・カウントを、前記出力文書を保管するのに使用するｍＸＭＬバッファに書き込むステップと、
（ａ４）前記文書ツリー表現内の各ノードをトラバースし、前記ｍＸＭＬバッファ内で対応するノード指定を生成するステップであって、ノード名を生成するステップと、前記ノードの属性に関する０個以上の（属性名、属性値）対への参照を指定する属性リストを生成するステップと、前記ノードの子である０個以上の子ノードのインデックス値を指定する子リストを生成するステップと、前記ノードが値を有しない場合に空である、ノード値指定を生成するステップとを含むステップと、
（ａ５）前記属性リストから参照される属性名および属性値と、前記ノード値指定から参照されるノード値とを含むデータ・バッファを生成するステップと、
（ａ６）前記出力文書を形成するために、前記ｍＸＭＬバッファに前記データ・バッファを付加するステップと、
を含む、請求項１に記載の方法。
【請求項５】
前記ステップ（ｂ）が、
（ｂ１）前記出力文書を構文解析するステップ
を含む、請求項１に記載の方法。
【請求項６】
前記ステップ（ｂ１）が、
（ｂ１ａ）前記出力文書からルーティングに使用されるルーティング・データを抽出するステップ
を含む、請求項５に記載の方法。
【請求項７】
（ｈ）前記ターゲットが前記ステップ（ｄ）においてｍＸＭＬでエンコードされた文書を処理できると判定される場合に、前記読取をした出力文書を前記ターゲットに送るステップ
をさらに含む、請求項１に記載の方法。
【請求項８】
（ｉ）前記ターゲットが前記ステップ（ｄ）においてｍＸＭＬでエンコードされた文書を処理できると判定される場合に、前記読取をした出力文書からルーティング情報を抽出するステップ
をさらに含む、請求項１に記載の方法。
【請求項９】
（ｅ）前記ターゲットが前記ステップ（ｄ）においてｍＸＭＬでエンコードされた文書を処理できないと判定される場合に、前記読取をしたｍＸＭＬでエンコードされた出力文書をＸＭＬでエンコードされた出力文書に変換するステップ
をさらに含む、請求項１に記載の方法。
【請求項１０】
（ｆ）前記変換されたＸＭＬでエンコードされた出力文書を前記ターゲットに送るステップ
をさらに含む、請求項９に記載の方法。
【請求項１１】
前記ステップ（ｂ１）が、
（ｂ１ａ）前記文書内のノードのカウントを表すノード・カウントを構文解析するステップと、
（ｂ１ｂ）前記ノードのそれぞれのノード指定を構文解析するステップであって、ノード名を構文解析するステップと、前記ノードの子である０個以上の子ノードのインデックス値を指定する子リストを構文解析するステップと、前記ノードの属性に関する０個以上の（属性名、属性値）対への参照を指定する属性リストを構文解析するステップと、前記ノードが値を有しない場合に空である、ノード値指定を構文解析するステップとを含むステップと、
（ｂ１ｃ）前記属性リストから参照される属性名および属性値と前記ノード値指定から参照されるノード値とを含むデータ・バッファを構文解析するステップと、
を含む、請求項５に記載の方法。
【請求項１２】
ネットワーク化されたコンピューティング環境におけるルーティング・デバイスが、データ・コンテンツを文書構造から分離し、文書のツリー構造におけるノード指定に続いて前記データ・コンテンツを配置した、ｍＸＭＬでエンコードされた入力文書を、前記データ・コンテンツに基づいてルーティングする方法であって、
（ａ１）前記入力文書が次にルーティングされるターゲットを識別するステップと、
（ａ３）前記ターゲットがｍＸＭＬでエンコードされた文書を処理できるかどうかを示す判定データを前記ターゲットから受信し、前記ターゲットの識別データと対応付けて記憶するステップと、
（ａ２）記憶した前記判定データを参照し、前記ターゲットがｍＸＭＬでエンコードされた文書を処理できるかどうかを判定するステップと、
（ｂ）前記ターゲットがｍＸＭＬでエンコードされた文書を処理できないと判定される場合に、前記ｍＸＭＬでエンコードされた入力文書を、ＸＭＬでエンコードされた出力文書に変換するステップと、
を含む方法。
【請求項１３】
前記ステップ（ｂ）が、
（ｂ１）前記入力文書の文書ツリー表現を識別するステップと、
（ｂ２）前記文書ツリー表現内のノードのカウントを表すノード・カウントを、前記入力文書を保管するのに使用するｍＸＭＬバッファから読み取るステップと、
（ｂ３）前記文書ツリー表現内の各ノードをトラバースし、前記ｍＸＭＬバッファ内で対応するノード指定を生成するステップであって、ノード名を識別するステップと、前記ノードの属性に関する０個以上の（属性名、属性値）対への参照を指定する属性リストを識別するステップと、前記ノードの子である０個以上の子ノードのインデックス値を指定する子リストを識別するステップと、前記ノードが値を有しない場合に空である、ノード値指定を識別するステップとを含むステップと、
（ｂ４）前記属性リストから参照される属性名および属性値と、前記ノード値指定から参照されるノード値とを含むデータ・バッファを生成するステップと、
（ｂ５）前記出力文書を形成するために、変換された文書を保管するＸＭＬバッファに前記データ・バッファを付加するステップと、
を含む、請求項１２に記載の方法。
【請求項１４】
（ｄ）前記ｍＸＭＬでエンコードされた入力文書を構文解析するステップ
をさらに含む、請求項１２に記載の方法。
【請求項１５】
（ｃ）前記ＸＭＬでエンコードされた出力文書を前記ターゲットに送るステップ
をさらに含む、請求項１２に記載の方法。
【請求項１６】
１つまたは複数のコンピュータ可読媒体上で実施され、ネットワーク化されたコンピューティング環境におけるルーティング・デバイスに、ＸＭＬでエンコードされた入力文書をデータ・コンテンツに基づいてルーティングさせるコンピュータ・プログラムであって、
前記ＸＭＬでエンコードされた入力文書を、前記データ・コンテンツを文書構造から分離し、前記入力文書のツリー構造におけるノード指定に続いて前記データ・コンテンツを配置した、ｍＸＭＬでエンコードされた出力文書に変換するコンピュータ可読プログラム・コードと、
前記ｍＸＭＬでエンコードされた出力文書の読取をするコンピュータ可読プログラム・コードと、
前記読取をした出力文書が次にルーティングされるターゲットを識別するコンピュータ可読プログラム・コードと、
前記ターゲットがｍＸＭＬでエンコードされた文書を処理できるかどうかを示す判定データを前記ターゲットから受信し、前記ターゲットの識別データと対応付けて記憶するコンピュータ可読プログラム・コードと、
記憶した前記判定データを参照し、前記ターゲットがｍＸＭＬでエンコードされた文書を処理できるかどうかを判定するコンピュータ可読プログラム・コードと、
を含むコンピュータ・プログラム。
【請求項１７】
前記ＸＭＬでエンコードされた入力文書を、前記データ・コンテンツを文書構造から分離し、前記入力文書のツリー構造におけるノード指定に続いて前記データ・コンテンツを配置した、ｍＸＭＬでエンコードされた出力文書に変換するコンピュータ可読プログラム・コードが、
前記入力文書の文書ツリー表現を作成するコンピュータ可読プログラム・コードと、
前記文書ツリー表現内のノードのカウントを表すノード・カウントを得るコンピュータ可読プログラム・コードと、
前記ノード・カウントを、前記出力文書を保管するのに使用するｍＸＭＬバッファに書き込むコンピュータ可読プログラム・コードと、
前記文書ツリー表現内の各ノードをトラバースし、前記ｍＸＭＬバッファ内で対応するノード指定を生成するコンピュータ可読プログラム・コードであって、ノード名を生成するコンピュータ可読プログラム・コードと、前記ノードの属性に関する０個以上の（属性名、属性値）対への参照を指定する属性リストを生成するコンピュータ可読プログラム・コードと、前記ノードの子である０個以上の子ノードのインデックス値を指定する子リストを生成するコンピュータ可読プログラム・コードと、前記ノードが値を有しない場合に空である、ノード値指定を生成するコンピュータ可読プログラム・コードと、を含むコンピュータ可読プログラム・コードと、
前記属性リストから参照される属性名および属性値と、前記ノード値指定から参照されるノード値とを含むデータ・バッファを生成するコンピュータ可読プログラム・コードと、
前記出力文書を形成するために、前記ｍＸＭＬバッファに前記データ・バッファを付加するコンピュータ可読プログラム・コードと、
を含む、請求項１６に記載のコンピュータ・プログラム。
【請求項１８】
前記ｍＸＭＬでエンコードされた出力文書の読取をするコンピュータ可読プログラム・コードが、
前記出力文書を構文解析するコンピュータ可読プログラム・コードであって、
前記文書内のノードのカウントを表すノード・カウントを構文解析するコンピュータ可読プログラム・コードと、
前記ノードのそれぞれのノード指定を構文解析するコンピュータ可読プログラム・コードであって、ノード名を構文解析するコンピュータ可読プログラム・コードと、前記ノードの子である０個以上の子ノードのインデックス値を指定する子リストを構文解析するコンピュータ可読プログラム・コードと、前記ノードの属性に関する０個以上の（属性名、属性値）対への参照を指定する属性リストを構文解析するコンピュータ可読プログラム・コードと、前記ノードが値を有しない場合に空である、ノード値指定を構文解析するコンピュータ可読プログラム・コードと、を含むコンピュータ可読プログラム・コードと、
前記属性リストから参照される属性名および属性値と前記ノード値指定から参照されるノード値とを含むデータ・バッファを構文解析するコンピュータ可読プログラム・コードと、
を含む、請求項１６に記載のコンピュータ・プログラム。
【請求項１９】
ネットワーク化されたコンピューティング環境において、ＸＭＬでエンコードされた入力文書をデータ・コンテンツに基づいてルーティングするシステムであって、
前記ＸＭＬでエンコードされた入力文書を、前記データ・コンテンツを文書構造から分離し、前記入力文書のツリー構造におけるノード指定に続いて前記データ・コンテンツを配置した、ｍＸＭＬでエンコードされた出力文書に変換する手段と、
前記ｍＸＭＬでエンコードされた出力文書の読取をする手段と、
前記読取をした出力文書が次にルーティングされるターゲットを識別する手段と、
前記ターゲットがｍＸＭＬでエンコードされた文書を処理できるかどうかを示す判定データを前記ターゲットから受信し、前記ターゲットの識別データと対応付けて記憶する手段と、
記憶した前記判定データを参照し、前記ターゲットがｍＸＭＬでエンコードされた文書を処理できるかどうかを判定する手段と、
を含むシステム。
【請求項２０】
前記ＸＭＬでエンコードされた入力文書を、前記データ・コンテンツを文書構造から分離し、前記入力文書のツリー構造におけるノード指定に続いて前記データ・コンテンツを配置した、ｍＸＭＬでエンコードされた出力文書に変換する前記手段が、
前記入力文書の文書ツリー表現を作成する手段と、
前記文書ツリー表現内のノードのカウントを表すノード・カウントを得る手段と、
前記ノード・カウントを、前記出力文書を保管するのに使用するｍＸＭＬバッファに書き込む手段と、
前記文書ツリー表現内の各ノードをトラバースし、前記ｍＸＭＬバッファ内で対応するノード指定を生成する手段であって、ノード名を生成する手段と、前記ノードの属性に関する０個以上の（属性名、属性値）対への参照を指定する属性リストを生成する手段と、前記ノードの子である０個以上の子ノードのインデックス値を指定する子リストを生成する手段と、前記ノードが値を有しない場合に空である、ノード値指定を生成する手段と、を含む手段と、
前記属性リストから参照される属性名および属性値と、前記ノード値指定から参照されるノード値とを含むデータ・バッファを生成する手段と、
前記出力文書を形成するために、前記ｍＸＭＬバッファに前記データ・バッファを付加する手段と、
を含む、請求項１９に記載のシステム。
【請求項２１】
前記ｍＸＭＬでエンコードされた出力文書の読取をする手段が、
前記出力文書を構文解析する手段であって、
前記出力文書内のノードのカウントを表すノード・カウントを構文解析する手段と、
前記ノードのそれぞれのノード指定を構文解析する手段であって、ノード名を構文解析する手段と、前記ノードの子である０個以上の子ノードのインデックス値を指定する子リストを構文解析する手段と、前記ノードの属性に関する０個以上の（属性名、属性値）対への参照を指定する属性リストを構文解析する手段と、前記ノードが値を有しない場合に空である、ノード値指定を構文解析する手段と、を含む手段と、
前記属性リストから参照される属性名および属性値と前記ノード値指定から参照されるノード値とを含むデータ・バッファを構文解析する手段と、
を含む、請求項１９に記載のシステム。
【請求項２２】
ネットワーク化されたコンピューティング環境におけるルーティング・デバイスが、入力文書をデータ・コンテンツに基づいてルーティングする方法であって、
（ａ１）前記入力文書が次にルーティングされるターゲットを識別するステップと、
（ａ３）前記ターゲットが、データ・コンテンツを文書構造から分離し、文書のツリー構造におけるノード指定に続いて前記データ・コンテンツを配置したｍＸＭＬでエンコードされた文書を処理できるかどうかを示す判定データを、前記ターゲットから受信し、前記ターゲットの識別データと対応付けて記憶するステップと、
（ａ２）記憶した前記判定データを参照し、前記ターゲットがｍＸＭＬでエンコードされた文書を処理できるかどうかを判定するステップと、
（ｂ）前記入力文書がｍＸＭＬでエンコードされ、前記ターゲットがｍＸＭＬでエンコードされた文書を処理できない場合に、前記入力文書をＸＭＬでエンコードされた出力文書に変換するステップと、
を含む方法。
【請求項２３】
（ｃ）ＸＭＬでエンコードされた元の文書を、前記ｍＸＭＬでエンコードされた入力文書に変換するステップ
をさらに含む、請求項２２に記載の方法。
【請求項２４】
前記ステップ（ａ１）が、前記入力文書を構文解析するステップを含む、請求項２３に記載の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、全般的には、ＸＭＬ（eXtensible Markup Language）でデータを交換するコンピュータ・システムのネットワークに関し、具体的には、たとえば通信ネットワーク内のContent Based Routing（ＣＢＲ）を実行するネットワーク・デバイスなどのネットワーク・デバイスでの拡張可能文書の表現および交換のためのマシン向き表記（ｍＸＭＬ）の使用に関する。ｍＸＭＬ表記およびｍＸＭＬの文書を操作（たとえば構文解析および保管）するための方法、システム、およびコンピュータ・プログラム製品が、米国特許出願第０９／６５２０５６号明細書に記載されている。
【０００２】
【従来の技術】
一般にネットワーク・コンピューティングとも称する分散コンピューティングのビジネスおよび個人による使用が、ここ数年で非常に人気を集めている。このコンピューティング・モデルでは、特定の計算タスクを実行するのに使用されるデータまたはプログラムが、一般に複数のコンピュータに存在し（その間で「分散され」）、これらの複数のコンピュータが、なんらかのタイプのネットワークによって接続される。インターネットおよび、ワールド・ワイド・ウェブ（以下では「ウェブ」）と称するインターネットの一部は、複数のコンピュータが公衆ネットワークを使用して接続されるこの種の環境の周知の例である。分散コンピューティングを使用することができる他のタイプのネットワーク環境には、一般に制限されたユーザの組（ある会社の従業員など）がアクセス可能な私有ネットワークであるイントラネットと、エクストラネット（たとえば、そのネットワークを所有または管理する会社の従業員だけではなく、他のユーザもアクセス可能な企業ネットワーク）が含まれる。
【０００３】
ビジネス用途について、分散コンピューティングのコンピューティング要素の間のネットワーク相互作用には、ユーザをビジネス・プロセスに接続するものと、ビジネス・プロセス要素を相互接続するものという２つの主なカテゴリがある。第１のカテゴリの例が、ユーザがウェブ・ブラウザ・ソフトウェアを使用して、ＨＴＴＰ（HyperText Transport Protocol）によって移送されるハイパーテキスト・マークアップ言語（ＨＴＭＬ）データ・フォーマットを使用するウェブ・サーバのビジネス・データおよびアプリケーションと相互作用できる、従来のウェブである。第２のカテゴリの例が、標準化された電子フォーマット（ＡＮＳＩＸ．１２またはＵＮ／ＥＤＩＦＡＣＴなど）で存在する請求書、注文、送り状、集荷通知などの文書が、Ｘ．４００、ＳＮＡＤＳ、ＴＭＲ、ＳＭＴＰなどのプロトコルによって組織プロセスの間で移動される従来の「電子文書交換」（ＥＤＩ）である。ネットワーク相互作用のこれらの２つのカテゴリについて、ＨＴＴＰウェブ・トランスポート・プロトコルおよび、ＸＭＬ（eXtensible Markup Language）と称する共通データ・フォーマットの使用に向かう傾向がある。ＸＭＬはタグ言語であり、タグ言語とは、情報を区切る（または「マーク・アップする」）のに「タグ」と称する特に指定された構成を使用する言語である。一般的な例では、タグは、タグに関連するデータが何であるかを識別するキーワードであり、通常は、特殊文字で囲まれた文字ストリングからなる。「特殊文字」とは、タグと共に使用するために定義され、予約された、英数字以外の文字を意味する。特殊文字は、データ・ストリームを処理するパーサが、これがタグであることを認識するようにするために使用される。タグは、通常は、それに関連するデータの前に挿入され、対応するタグも、そのデータが終わる位置を明瞭に識別するために、データの後に挿入される場合がある。
【０００４】
ＸＭＬの構文は、拡張可能かつ柔軟であり、これによって、文書開発者が、明示的に入れ子にされたツリー文書構造を伝えるタグを作成できるようになる（構造は、特定の文書内のタグの間の関係から決定される）。さらに、文書開発者は、応用例固有のセマンティクスを有することができる独自のタグを定義することができる。この拡張性のゆえに、ＸＭＬ文書を使用して、事実上無制限の数のコンテキストでの使用のための、多数の異なるタイプの情報を指定することができる。ＸＭＬの人気の原因は、主にこの拡張性および柔軟性である（多数のＸＭＬ派生表記が、特定の目的のために定義されており、定義され続けている）。「ＶｏｉｃｅＸＭＬ」が、そのような派生物の１例である。本明細書での「ＸＭＬ」への言及は、ＸＭＬ派生物と、ＸＭＬがそこから派生したStandard Generalized Markup Languageまたは「ＳＧＭＬ」の派生物などの意味論的に類似する表記を含むことが意図されている。ＳＧＭＬに関するさらなる情報については、ＩＳＯ８８７９「Standard Generalized Markup Language (SGML)」、１９８６年を参照されたい。ＸＭＬに関するさらなる情報については、ワールド・ワイド・ウェブ上のhttp://www.w3.org/TR/1998/REC-xml-19980210で入手できる「Extensible Markup Language (XML), W3C Recommendation 10-February-1998」を参照されたい。
【０００５】
図１に、名前（たとえば、会社の従業員の名前、商売の顧客の名前など）の指定に使用することができる文書１００の従来技術のＸＭＬ構文の単純な例を示す。この例では、<LAST_NAME>タグ対１０５および１１０が、姓の情報を表すのに使用され、<FIRST_NAME>タグ対１１５および１２０が、名の情報を表すのに使用される。姓および名のデータ・コンテンツ値は、開始タグと終了タグの間に現れる（この例ではストリングとして）。この例の<MIDDLE_INITIAL />タグ１２５では、データ・コンテンツを有しないタグのタグ名に終了タグ記号「／＞」が続く、速記の空タグ・フォーマットが使用されている。ＸＭＬタグには、開始<LAST_NAME>タグ１３０内で指定される「SUFFIX = “Jr.”」属性１３５によって示されるように、属性名および属性値も含めることができる。この文書１００を観察するとわかるように、この例のデータ・コンテンツ全体に、２２文字が含まる。しかし、タグ構文によって、別の２０１個の印刷可能文字（タブ、改行、ブランクなどを含まない）または全文書ファイル・サイズの約９０％が追加される。一般的な場合に、タグ構文に使用される文字に関するオーバーヘッドは、タグ名が図示のものよりさらに長くなる可能性があるので、さらに高くなる可能性がある。さらに、この例で属性として（「SUFFIX = “Jr.”」属性１３５）指定されたデータ・コンテンツは、その代わりに、それ自体の開始タグ／終了タグ対の中の要素として表すことができ、これは、さらに多量のタグ関連オーバーヘッドにつながる。
【０００６】
ＸＭＬは、優秀なデータ・フォーマットではあるが、ＸＭＬ文書の構文解析、操作、および変換には、かなりの量のオーバーヘッドが伴う。拡張可能なタグ構文によって、ＸＭＬ文書を、簡単に人間可読にすることができる。というのは、タグ名を、関連するデータ値のセマンティックな意味およびデータの要素の間の全体的な関係を伝えるように設計することができるからである。たとえば、図１では、タグ名および構造によって、名前に名、姓、およびミドル・イニシャルが含まれることが明示的に示される。このヒューマン・フレンドリで明確に構造化されたフォーマットによって、人間が任意のＸＭＬ文書の属性をすばやく通し読み、データおよびその意味を理解することができる。しかし、コンピュータは、データを理解し、それを用いて有用なことを行うために多大な労力を要する。ほとんどのＸＭＬ文書の生のコンテンツは、決して人間に見られず、エンド・ユーザが見るものは、一般にタグをはぎとり、埋め込まれたデータ・コンテンツだけを表示するレンダリング・アプリケーション（たとえばブラウザ内のＸＭＬパーサ）を使用して作成される。したがって、ヒューマン・フレンドリなタグ構文の追加オーバーヘッドは、business-to-business（「Ｂ２Ｂ」）使用またはbusiness-to-consumer（「Ｂ２Ｃ」）使用のためのコンピュータ・プログラム間での交換のためにフォーマットされた文書など、文書がコンピュータ・プログラムによってのみ「見られる」時に、構造化文書の処理および保管の無用な非効率性につながる。
【０００７】
本発明者は、ＸＭＬの代替物として使用するためのマシン向き表記を以前に開発した。マシン向き表記では、ＸＭＬの拡張性および柔軟性を維持しながら、かつ同等のコンテンツおよびセマンティック情報を伝えながら、任意の構造を有する文書の処理時間が改善され、保管要件およびデータ交換の伝送コストが減る。このマシン向き表記を、本明細書で「ｍＸＭＬ」と呼称する。米国特許出願第０９／６５２０５６号明細書に、ｍＸＭＬ表記ならびにｍＸＭＬを操作する（たとえば、ｍＸＭＬの文書を構文解析し、保管する）方法、システム、およびコンピュータ・プログラム製品が開示されている。
【０００８】
このマシン向き表記は、製品境界内で使用することができ、（たとえば）ｍＸＭＬ文書を異なる処理構成要素の間で共用でき、ある記憶媒体から別の記憶媒体へ（メモリとディスクの間など）で転送することなどができる。e-commerceまたはe-businessを行う方法も、文書がｍＸＭＬでコーディングされる時に促進される。というのは、これらの文書を、企業内の異なる位置にあるビジネス当事者の間で効率的に交換することなどができるからである。
【０００９】
ネットワーク相互作用の両方のカテゴリについて、効率的な相互作用が、たとえば情報またはデータのアプリケーション層制御に基づく、メッセージまたは要求のアクティブ・ネットワーク・ルーティングに用いられる要素の間で追求された。そのような効率的な相互作用の１つの手法を、「Content Based Routing」（ＣＢＲ）と称する。ＣＢＲを用いると、負荷分散、サービス問題の品質の分解、分散アプリケーションおよびデータの類似性、セキュリティ問題の効率的な解決、およびビジネス・プロセス・ポリシの効率的な表現を伴う最適化が可能になる。たとえば、ＣＢＲを使用して、データ要求が、必要なアプリケーション特性に一致する最適アプリケーション・プロセスへ直接的な形で流れることを保証する、たとえば、注文の、顧客の販売代理人に関連する販売事務所注文サービス・システムへのルーティングを保証すること、または、クレジット・カード・トランザクションの、めいめいのクレジット・カード口座番号に関連する銀行システムへのルーティングを保証することができる。ＣＢＲネットワークのもう１つの特性は、データ要求の最終的なターゲットが、要求がＣＢＲネットワークに入る時点で未知であることと、最終的なターゲットが、要求がネットワーク内を進むにつれてより明瞭になり、要求がターゲット・システムに到着するまで絶対的に解決されないことである。
【００１０】
ＣＢＲを実施する、さまざまなプログラミング方法、ハードウェア、およびソフトウェアが、当技術分野で周知である。ＣＢＲ用の通常の技法には、ウェブを介してユーザをビジネス・プロセスに接続するのに使用される時に、文書または、ウェブ要求のＨＴＴＰヘッダなどのそれを移送するアプリケーション・プロトコル制御パラメータからの少量のデータのスキャン、読取、または抽出が含まれる。そのようなデータは、その後、ルーティングに使用される。たとえばＨＴＭＬフォーム文書などの非ＸＭＬ文書の場合、そのようなデータは、通常は、他のアプリケーション層制御情報がしばしば見つかる、セッションの最初の少数のパケット内で見つかる可能性がある。たとえば、ユーザによって完成されたＨＴＴＰフォームのデータは、しばしば、このフォーム・データをウェブ・サーバに送信するウェブ要求のＨＴＴＰ  ＧＥＴコマンド・ヘッダのＵＲＬストリング内にエンコードされる。
【００１１】
多数の他の従来のウェブ要求に関して、Cookieなどのアプリケーション・データを、検索されるＵＲＬなどを識別するＧＥＴウェブ要求ＨＴＴＰヘッダから抽出することができる。そのような要求に関して、そのような要求の一部として関連する（送信される）文書はない。したがって、そのような場合にＣＢＲを実行するためには、文書全体ではなく、ＧＥＴまたは他のＨＴＴＰコマンド・ヘッダ情報だけを検査すればよい。したがって、そのようなルーティング・データは、ＣＢＲ対応ネットワーク・デバイスに大きな重荷を課すことなく、簡単かつ効率的に見つけることができる。
【００１２】
ビジネス・プロセス要素を相互接続するのに使用される通常のＣＢＲ技法では、アプリケーション・エージェントを使用して、アプリケーション・パラメータをデコードする。そのようなアプリケーション・パラメータは、移送されたアプリケーション・メッセージ（文書）から抽出され、プロトコル・ヘッダの簡単にアクセス可能な部分に配置された、コンテンツのルーティング関連部分を表す。例示的な技法が、米国特許第５５６３８７８号明細書に開示されている。そのような技法では、要求のパスに沿った各ルーティング位置でのコンテンツ・スキャンの必要な深さが制限される。これは、ルーティング・ノードに、しばしば、アプリケーション固有コードが含まれることと、フロー内のソース・プロセスが、トランスポート・ネットワーク内のエージェントの可用性および詳細を知らなければならないことを意味する。さらに、ルーティング・データは、ＣＢＲ対応ネットワーク・デバイスに大きな重荷を課すことなく、簡単かつ効率的に見つけることができる。
【００１３】
ＸＭＬ文書がめいめいのノードに常駐するアプリケーション固有エージェントを使用せずにルーティングされる、ＣＢＲ対応ノードのネットワークでは、ルーティング要件が、しばしば、ＬＤＡＰディレクトリなどのリポジトリに保管されたルールの組として指定され、このルールの組は、ＣＢＲ対応デバイスによって検索され、汎用コードを使用して実行されて、めいめいの着信ＸＭＬ文書がたどらなければならない次の「ホップ」が決定される。たとえば、論理「IF （条件） THEN （次のホップ）」を有するルールを検討されたい。ここで、「（条件）」は、ＸＭＬ文書内のさまざまな構造またはデータの状態をテストする式である。しばしば、ＸＭＬ  Ｐａｔｈ言語（ＸＰａｔｈ）が、テストされるＸＭＬ文書の部分を識別するために式内で使用され（ＸＰａｔｈの詳細な情報については、http://www.w3.org/TR/1999/REC-xpath-19991116にある「XML Path Language (XPath) Version 1.0」、Ｗ３Ｃ勧告、１９９９年１１月１６日を参照されたい）、ＸＰａｔｈによって、ＸＭＬ文書がノードのツリーとしてモデル化される。これは、ＣＢＲ対応デバイスが、そのようなルールを適用するために、ルーティングされるＸＭＬ文書のそのような内部表現が可能でなければならないことを意味する。たとえば、高水準な形の「IF （注文が急送項目を有する） THEN （シカゴに転送する）」を有するルールは、「//item[descendant::delivery_options[@expedite='yes']]」のようなＸＰａｔｈ断片を含む詳細式を有する可能性があり、このＸＰａｔｈ断片によって、「yes」値をもつ「expedite」という名前の属性を有する、「delivery_options」という名前の子孫要素をもった文書ノードツリー内のすべての「item」要素が識別される。
【００１４】
ビジネス・プロセス間でＸＭＬ文書を移動するのにトランスポート・プロトコルとしてＨＴＴＰを使用する方向に向かう傾向があるので、ＸＭＬのコンテンツに基づくＣＢＲルールをＨＴＴＰのＰＵＴまたはＰＯＳＴウェブ要求に適用することができるＣＢＲネットワーク・デバイスの必要がある。ＰＵＴ要求およびＰＯＳＴ要求は、ＸＭＬ文書をサーバに送信するのに使用され、ここで、含まれるＵＲＬが、その文書を処理するために呼び出さなければならないアプリケーション・プロセスの指定機能であることがしばしばである。そのような要求に関して、ＸＭＬ文書は、インバウンド・ウェブ要求の一部であり、上の例示的なＸＰａｔｈ断片からわかるように、ＣＢＲに有用な情報を、ＸＭＬ文書内のどこにでも配置することができる。したがって、ＸＭＬ文書のＣＢＲは、しばしば、ＸＭＬ文書全体をノードのツリーとして扱って、ルーティングに有用な情報を抽出することを必要とする。したがって、ルーティング・デバイスは、要求が次にルーティングまたは送信される場所を判定できるまで、データストリームを深くバッファリングし、構文解析し、スキャンしなければならない。これによって、かなりの量の処理過負荷が生み出され、ＣＢＲ機能を実行する、ルータおよびスイッチなどのネットワーク・デバイスにかなりの重荷が課せられる。これは、そのようなデバイスの性能の大きな低下をもたらし、したがって、ネットワーク全体の大きな性能低下をもたらす。ＸＭＬが、business-to-business（「Ｂ２Ｂ」）、アプリケーション間、および他のシナリオでのデータを表すのにますます使用されるにつれて、ＣＢＲデバイスおよび関連するネットワークが、非常に重荷を課せられる。
【００１５】
したがって、必要なものは、ＸＭＬ文書からルーティング情報を抽出する効率的な方法、この抽出された情報を他のネットワーク・デバイス、ノード、またはプロセスに渡す手段、またはアプリケーション・サーバからＸＭＬ処理オーバーヘッドをオフロードする手段、もしくはこれらの組合せである。
【００１６】
【発明が解決しようとする課題】
本発明は、たとえばＣＢＲデバイスによる、ＸＭＬ文書がネットワークを介して流れる際の、たとえばそのような文書のバッファリング、構文解析、伝送、ルーティング、およびそれからのデータの抽出の、効率的な処理の方法を提供する。本発明は、効率的なｍＸＭＬマシン向き表記を使用する方法を提供する。本発明は、ネットワーク内でのよりよい性能を提供するだけではなく、本発明によるＣＢＲネットワーキング・デバイスによってＸＭＬ文書がｍＸＭＬ対応デバイスに送信される時の処理オーバーヘッドのオフロードも提供する。
【００１７】
【課題を解決するための手段】
本発明によれば、ＸＭＬ文書が、ＣＢＲサブネットワーク内のＣＢＲ対応ルータなどのｍＸＭＬ対応デバイスによって受信される際に、ｍＸＭＬに変換される。ｍＸＭＬ文書は、デバイスによって処理され、これによって、処理効率が実現される。本発明のシステム内のデバイスは、ターゲット・デバイスまたはターゲット処理がｍＸＭＬ対応であるかどうかの認識を与えられる。処理された出力文書が次にルーティングされるターゲットを、識別する。その後、ターゲットが、ｍＸＭＬでエンコードされた文書を処理できるかどうかを判定する。ターゲットが、ｍＸＭＬを処理できる場合には、ｍＸＭＬ文書がターゲットに渡され、その結果、ターゲットが、ｍＸＭＬで文書を処理でき、ＸＭＬをｍＸＭＬに変換する必要なく、処理効率が実現されるようになる。これによって、すなわち、ターゲットが文書を処理してＸＭＬからｍＸＭＬに変換することを必要とするのではなく、ｍＸＭＬフォーマットでターゲットに文書を供給することによって、ターゲットから処理が効率的にオフロードされる。ターゲットが、ｍＸＭＬの文書を処理できない場合には、ｍＸＭＬ文書を、ターゲットに渡す前にＸＭＬに変換する。
【００１８】
この発明の方法を実行するシステムおよびコンピュータ・プログラム製品も提供される。
【００１９】
【発明の実施の形態】
本発明は、マシン向き表記すなわちｍＸＭＬを使用する、たとえばＣＢＲデバイスによる、ＸＭＬ文書の効率的な処理の方法および装置を提供する。ｍＸＭＬ表記およびｍＸＭＬの文書を操作する（たとえば構文解析および保管）方法、システム、およびコンピュータ・プログラム製品が、米国特許出願第０９／６５２０５６号明細書に詳細に記載されている。本発明をより簡単に理解できるようにするために、ｍＸＭＬおよびＸＭＬとｍＸＭＬの間の変換の議論を、それから抜粋して下の図４ないし１２の議論で提供する。
【００２０】
図２に、本発明の好ましい実施形態による、ＸＭＬ文書を処理する論理を示す流れ図２００を示す。図３は、本発明による例示的なネットワーク・デバイス３４５すなわちｍＸＭＬ対応ルータを含む例示的なネットワーク化されたコンピューティング環境の図である。ネットワーク・デバイス３４５は、たとえば読取、構文解析、変換など、ｍＸＭＬ表記の理解または処理が可能であるという点で、「ｍＸＭＬ対応」である。ネットワーク・デバイス３４５は、たとえばIF （注文が急送項目を有する） THEN （シカゴに転送する）などのコンテンツに基づくcontent-based routingを実行できるという点で、「ＣＢＲ対応」でもある。具体的には、ネットワーク・デバイス３４５は、ｍＸＭＬ文書のＣＢＲを実行することができる。
【００２１】
たとえば、ＣＢＲ対応ネットワーク・デバイスには、ルータ、スイッチ、ロード・バランサー、プロキシ、キャッシュ、ＴＣＰシェーパなどを含めることができる。本発明によれば、そのようなデバイスを、ｍＸＭＬ対応として構成することができる。例示のために、図２および図３を、下で、例示的なｍＸＭＬ対応でＣＢＲ対応のルータとしてのネットワーク・デバイス３４５の観点から論ずる。ｍＸＭＬの機能としてＣＢＲを実行するようにｍＸＭＬ対応デバイスを構成するプログラミング技法は、単純であり、当技術分野で周知である。というのは、ｍＸＭＬランタイム処理環境が、ＸＭＬランタイム処理環境と同一のアクセス機能をサポートするからである。
【００２２】
図２および図３の例では、ネットワーク・デバイス３４５（ルータ）が、文書をＸＭＬからｍＸＭＬへおよびｍＸＭＬからＸＭＬへ変換することができる。したがって、ネットワーク・デバイス３４５は、ＸＭＬからｍＸＭＬへおよびその逆の変換方法を実行するソフトウェアまたは命令を保管する。そのような変換方法は、米国特許出願第０９／６５２０５６号明細書に詳細に開示されており、下で図７ないし９に関してさらに説明する。
【００２３】
図２からわかるように、本発明の方法は、ステップ２０５および２１０に示されているように、デスティネーション／ホストへのルーティングのためにネットワーク・デバイスが文書を受信することから開始される。たとえば、そのような文書は、ＸＭＬ対応ルーティング・デバイス３７０（すなわち、ＸＭＬ対応であるがｍＸＭＬ対応でないデバイス）を介してＸＭＬベースの企業イントラネット３６０の企業アプリケーション・サーバ３６５ｂから送信されるクレジット・カード・トランザクションを表すことができる。この例では、文書が、インターネットまたは通信ネットワークであるネットワーク３４０のＸＭＬ対応でＣＢＲ対応のルーティング・デバイス３５５によって受信される。文書は、その後、ネットワーク・デバイス３４５にルーティングされ、ネットワーク・デバイス３４５は、ＣＢＲサブネットワーク３１０内にある。図３の例では、ＣＢＲサブネットワーク３１０内のすべてのデバイスが、ＣＢＲ対応でありｍＸＭＬ対応である。
【００２４】
ネットワーク・デバイス３４５は、次に、ステップ２２０に示されているように、文書がｍＸＭＬでエンコードされた文書（「ｍＸＭＬ文書」）であるかどうかを判定する。これは、ネットワーク・デバイス３４５に保管されたソフトウェアによって実行される。このステップを実行するプログラミングの方法および技法は、単純である。たとえば、ＨＴＴＰがトランスポート・プロトコルとして使用されている場合には、プロトコルの「メッセージ」ヘッダ・フィールドに、トランスポートされる文書のフォーマットが記載されており、これを検査して、この判定を行うことができる。図２の例では、企業アプリケーション・サーバ３６５ｂから送信される、クレジット・カード購入トランザクションを表す文書が、ＸＭＬでエンコードされていると想定されたい。したがって、ステップ２２０のテストは、否定的に回答される。
【００２５】
図２のステップ２３０では、文書がＸＭＬ文書であるかどうかを判定する。このステップを実行するプログラミングの方法および技法は、当技術分野で周知である。上で説明した例示的なクレジット・カード・トランザクションでは、このテストが、肯定の結果を有する。
【００２６】
ｍＸＭＬ表記を使用して表現された文書は、既存のヒューマン・フレンドリな（プロセッサにはフレンドリでない）ＸＭＬ表記を使用する時よりはるかに効率的に処理することができる。具体的に言うと、ｍＸＭＬ表記を使用して表現された文書は、はるかに少ない記憶スペースを必要とし、データ交換（たとえば、ある計算装置からネットワークを介して別の計算装置へ）に関するはるかに低い伝送コストを有する。したがって、ネットワーク・デバイス３４５はｍＸＭＬ対応であるから、ネットワーク・デバイス３４５は、図２のステップ２４０に示されているように、ＸＭＬ入力文書を、インメモリ・アレイｍＸＭＬ表記でエンコードされた出力文書に変換する。ＸＭＬ文書をｍＸＭＬ文書に変換する方法は、米国特許出願第０９／６５２０５６号明細書に詳細に開示されており、下で図７に関して説明する。
【００２７】
出力文書は、その後、ステップ２５０に示されているように、ネットワーク・デバイスによる内部使用のために処理される。ステップ２５０には、ステップ２２０の「ｙｅｓ」からの行フォーマットｍＸＭＬ文書のメモリ・アレイｍＸＭＬ表現（ステップ２４０からの結果と同一の形）への構文解析が含まれる。ｍＸＭＬ文書を構文解析する方法は、米国特許出願第０９／６５２０５６号明細書に詳細に開示されており、下で図１０に関して説明する。このステップには、ルーティング・ルールを評価するのに必要なコンテンツ情報への高速アクセスを提供するエンベロープ様データ構造の突き止めまたは作成などの追加の最適化処理ステップも含めることができる。
【００２８】
ステップ２６０に示されているように、文書が、次に、ｍＸＭＬ対応デバイスすなわち、ｍＸＭＬでエンコードされた文書の解釈または処理もしくはその両方（集合的に「処理」）が可能なデバイスにルーティングされることになるかどうかを判定する。このために、本発明のシステム内のデバイスは、下で説明するように、ターゲット・デバイスまたはターゲット・プロセスがｍＸＭＬ対応であるかどうかの認識を与えられる。このデバイスが、次のルーティング・ターゲットである。ｍＸＭＬは、製品またはソフトウェア・アプリケーションの境界内で有用なので、文書が次に「ルーティング」される「ターゲット」には、この文書が渡される次のプロセス、ソフトウェア・サブルーチンなどを含めることができ、したがって、ネットワーク伝送を必要としない場合がある。たとえば、図２の論理は、クレジット・カード認証エージェントなどのｍＸＭＬをサポートするアプリケーション・プロセスに組み込むことができる。そのような例では、着信文書によって、ステップ２５０でｍＸＭＬアレイ・データ構造としてメモリ内で表現されるクレジット・カード課金を許可することを要求することができる。文書は、その後、ローカル・アプリケーション論理に渡され、このローカル・アプリケーション論理が、カード所有者の未払いの差引勘定がある限度内であることと、カードが盗まれたと報告されていないことなどを検証し、その後、文書およびプロトコル・ヘッダ情報を、送信される応答、たとえばクレジット拒否メッセージに変換するなどの機能を実行する。
【００２９】
ネットワーク・デバイス３４５を用いる図２および図３の例では、ステップ２６０に、文書のルーティング・パスの次ホップの識別が含まれる。たとえば、このステップには、要求が転送される先の、たとえばホスト名ストリングまたはＩＰアドレスによる、ＣＢＲターゲット、たとえばルータ、スイッチ、ロード・バランサ、プロキシ、キャッシュ、ＴＣＰシェーパなどの識別と、その後の、そのデバイスがｍＸＭＬ処理能力を含む登録された特性を有するかどうかを判定するためのディレクトリの参照のステップを含めることができる。代替案では、ｍＸＭＬ処理能力の特性を、ネットワーク・デバイス間でトポロジおよびコストの情報を移動するあるルーティング・プロトコル内で現在送信されつつあるデータ内に含めることができる。
【００３０】
ステップ２６０には、識別されたターゲットがｍＸＭＬでエンコードされた文書（「ｍＸＭＬ文書」）を処理することができるかどうかの判定も含まれる。たとえば、これは、複数のターゲット、たとえばルータまたはスイッチを、たとえばＩＰアドレスによって識別し、複数のターゲットのそれぞれがｍＸＭＬ文書を処理できるかどうかを示す、データのデータ・ストアを参照することによって達成することができる。そのような情報は、たとえば、ＬＤＡＰディレクトリまたは他のリポジトリを参照することによるか、ターゲット・システム内の特性情報を交換するプロトコルを使用することによって（たとえば、特性を含む管理情報ベース（ＭＩＢ）に関するシンプル・ネットワーク管理プロトコル（ＳＮＭＰ）要求を介して）得ることができる。そのようなディレクトリ、リポジトリ、およびプロトコルは、現在存在するが、ターゲットがｍＸＭＬ対応であるかどうかを示すために、本発明によって修正される。１実施形態では、デバイスがｍＸＭＬ対応であるかどうかを、たとえばデバイスからのｍＸＭＬ文書の受信時に、学習することができ、たとえばＬＤＡＰディレクトリ内に適当なエントリを作ることによって、記憶することができる。ターゲットがｍＸＭＬ対応であるかどうかは、たとえば、そのターゲットを記述するディレクトリ・エントリ内の属性として示すことができる。データ・ストアは、分散式に、たとえば各ネットワーク・デバイスのメモリ内に、または、集中式に、たとえばネットワーク・アクセス可能なリポジトリのメモリ内に、保管することができる。そのようなｍＸＭＬ対応情報は、任意選択として、たとえば、各ｍＸＭＬ対応デバイスが、それと通信するすべての他のデバイスにそのｍＸＭＬ処理能力を通信することなどによって、ネットワーク・デバイス間で交換し、伝搬することができる。このステップを実行するプログラミング技法は、当技術分野で周知である。
【００３１】
文書が、次に、ｍＸＭＬ対応デバイスにルーティングされる場合には、さらなる効率的な処理のために、文書をｍＸＭＬストリーム・フォーマットに保つことが有利である。したがって、メモリ・アレイ表現のｍＸＭＬを、次ホップ・デバイスに送信する時に、ワイヤ・フォーマットにシリアライズする。たとえば、ＣＢＲ環境では、文書が、たとえばＣＢＲサブネットワーク内の各ＣＢＲデバイスによって１回ずつ、複数回スキャンされる可能性がある。各デバイスは、ルーティングのために異なるコンテンツ情報についてスキャンしている可能性がある。各デバイスがｍＸＭＬ対応の場合には、複数のスキャンを各デバイスによって効率的に行うことができ、これによって、ネットワークの負担を大幅に減らすことができる。
【００３２】
したがって、ステップ２６０で、文書が次にｍＸＭＬ対応デバイスにルーティングされる場合には、その文書は、ステップ２７０および２８０に示されているように、当技術分野で一般に周知の形で処理され、この方法が終了する。この処理ステップ２７０には、たとえば、単に文書を次のホップまたは所期のデスティネーションにルーティングするなど、そのようなネットワーク・デバイスの分野で周知のどのような処理ステップでも含めることができる。ルータ・ネットワーク・デバイスの例では、この処理ステップに、たとえばｍＸＭＬ文書をターゲット・ノードに送信することを含む、文書から抽出されたcontent based routing情報によるターゲット・ノードへの文書のルーティングを含めることができる。これは特に有利である。というのは、次のｍＸＭＬ対応デバイスが、上で説明したように、ＸＭＬからｍＸＭＬへの変換の必要なく、ｍＸＭＬ文書を効率的に処理できるからである。この形で、ＸＭＬからｍＸＭＬへの処理のオフロードが達成され、これによって、オフロードされたターゲットの処理の負担が減る。
【００３３】
図３の例では、ルーティング・デバイス３５５から来るＸＭＬ文書が、次に、ネットワーク・デバイス３４５からｍＸＭＬ対応の企業イントラネット３２０のルーティング・デバイス３３０にルーティングされる。たとえば、小売り店チェーンの企業イントラネットの企業アプリケーション・サーバ３６５ｂから発するＸＭＬクレジット・カード許可トランザクション文書が、クレジット・カード清算ネットワーク、たとえばネットワーク３４０に送信され、ＸＭＬ対応（ｍＸＭＬ非対応）のルーティング・デバイス３５５に到着し、このルーティング・デバイス３５５が、従来技術の技法を使用して、関係するクレジット・カードのブランドをデコードする。ルーティング・デバイス３５５は、その後、ＸＭＬ文書をｍＸＭＬ対応のネットワーク・デバイス３４５に転送し、このネットワーク・デバイス３４５が、ＸＭＬ文書をｍＸＭＬに変換する。ネットワーク・デバイス３４５は、その後、関係する購入の詳細な記述にルールを適用し、このトランザクションが、自動清算処理に関してそのブランドによって設定された限度を越えると判定し、ｍＸＭＬ要求を地域銀行関連ネットワーク、たとえば企業イントラネット３２０のｍＸＭＬ対応のルーティング・デバイス３３０に転送する。ルーティング・デバイス３３０は、クレジット・カード番号を使用して、その口座が、銀行のｍＸＭＬ対応のサーバ３２５ｂに存在すると判定する。ルーティング・デバイス３３０は、ｍＸＭＬ文書をサーバ３２５ｂに転送し、サーバ３２５ｂが、許可検査を実行する。
【００３４】
このシナリオでは、適用されるＣＢＲルールを評価するために購入詳細が抽出される元のＤＯＭツリーを表現するのに、リンクされたオブジェクトではなくアレイ・ストレージを使用することのメモリ管理効率のゆえに、ネットワーク・デバイス３４５が、ＸＭＬ文書からｍＸＭＬインメモリ・アレイ表現への変換から利益を得る。ルーティング・デバイス３３０は、ネットワーク・デバイス３４５に関して注記した効率のほかに、ｍＸＭＬストリーム文書をｍＸＭＬアレイ・インメモリ表現に読み込むことに含まれるより複雑でない構文解析からも利益を得る（ネットワーク・デバイス３４５が、ルーティング・デバイス３３０がｍＸＭＬ対応であることを認識し、文書をｍＸＭＬストリーム・フォーマットで転送したので）。最後に、ｍＸＭＬ対応のサーバ３２５ｂは、ｍＸＭＬ文書の構文解析効率から利益を得たが、これは、本発明に従って、ネットワーク・デバイス３４５が、この例でサーバ３２５ｂからＸＭＬ構文解析オーバーヘッドを効果的にオフロードしたことを意味する。
【００３５】
ステップ２２０の判定で、ステップ２１０で受信される文書がｍＸＭＬ文書である場合には、ｍＸＭＬ対応のルーティング・デバイス３３０が、ステップ２５０に示され、上で説明したように、この文書を内部使用のために処理する。これによって、ネットワーク・デバイス３４５での効率的なｍＸＭＬベース処理が可能になる。この方法は、その後、上で説明したステップ２６０から継続される。
【００３６】
図２の例では、ステップ２１０で受信した文書が、ステップ２２０でｍＸＭＬ文書でないと判定され、ステップ２３０でＸＭＬ文書でないと判定される、すなわち、ＨＴＭＬ文書である場合に、その文書が、ステップ２７０で、当技術分野で周知のように単純に処理され、ステップ２８０に示されているように、この方法が終了する。
ステップ２６０で、文書が次にｍＸＭＬ対応ターゲットにルーティングされない、すなわち、ｍＸＭＬの解釈、構文解析、または他の処理が不可能なデバイスまたはプロセスにルーティングされると判定される場合には、ステップ２９０に示されているように、この文書をｍＸＭＬからＸＭＬに変換する。言い換えると、メモリ・アレイ情報のｍＸＭＬが、ステップ２９０でＸＭＬフォーマットにシリアライズされ、ステップ２７０で次ホップに送信される。これは、ターゲットが非ｍＸＭＬ対応なので、ターゲットが文書を処理するために必要である。
【００３７】
たとえば、ｍＸＭＬ対応でありＣＢＲサブネットワーク３１０内にある図３のサーバ３２５ｂから、ｍＸＭＬ非対応でありＣＢＲサブネットワーク３１０の外にある企業アプリケーション・サーバ３６５ｂに送信されたｍＸＭＬ文書を検討されたい。ネットワーク・デバイス３４５は、ｍＸＭＬ文書が、次に、ｍＸＭＬ対応でないルーティング・デバイス３５５（上でステップ２６０に関して説明したように判定される）にルーティングされると判定する時に、外部使用のために文書を処理する前、たとえば、文書をルーティング・デバイス３５５にルーティングする前に、文書をｍＸＭＬからＸＭＬに変換する。ｍＸＭＬ文書の一部の処理を、ステップ２９０で文書が変換され、ステップ２７０で処理／ルーティング・デバイス３５５に送信される前に、ｍＸＭＬ対応のネットワーク・デバイス３４５によって実行できることに留意されたい。文書をｍＸＭＬからＸＭＬに変換する方法は、米国特許出願第０９／６５２０５６号明細書に詳細に記載されており、下で図８ないし９に関して説明する。
【００３８】
この形で、ＸＭＬ文書が、比較的コンパクトでメモリ・バッファ効率のよいｍＸＭＬフォーマットに変換され、できる限りｍＸＭＬフォーマットで処理されると同時に、すべてのネットワーク・デバイス／ターゲットがｍＸＭＬ対応ではないことが認識され、必要な場合にそのようなデバイス／ターゲットによるＸＭＬフォーマットでの文書の処理が提供される。これによって、ネットワーク・デバイスによる効率的なcontent based routingが可能になる。具体的に言うと、本発明によって、ルーティング目的のＸＭＬ文書全体のスキャンに関連する処理オーバーヘッドが減り、ｍＸＭＬ文書のデータは、簡単な抽出および内部処理ステップ中の効率的なインメモリ表現をもたらすためにフォーマットされる。さらに、本発明は、この抽出されたルーティング情報を他のｍＸＭＬ対応ネットワーク・デバイスに渡すことを可能にし、このｍＸＭＬ対応ネットワーク・デバイスは、そのような情報を効率的に使用することができる。さらに、これによって、ｍＸＭＬ対応デバイスに関するＸＭＬ処理オーバーヘッドがアプリケーション・サーバからオフロードされる。というのは、文書が、ｍＸＭＬ対応デバイスに達する前に既にｍＸＭＬに変換されているからである。
【００３９】
任意選択の最適化を、図２のステップ２５０で実行して、ｍＸＭＬ対応デバイスが、めいめいのアプリケーション・トランスポート・プロトコルの仮想エンベロープまたはＣＢＲネットワーク内の他のノードにとって潜在的に重要なコンテンツ・データを伴うコンテンツ・ストリームに注釈を付けられるようにすることができる。この技法を使用すると、特定の文書タイプのＣＢＲルール・セットに、単純なコンテンツ参照が含まれる時に、後続のＣＢＲノードで文書の内部を見る必要をなくすことによって、性能を改善することができる。たとえば、上で図３に関して説明したＸＭＬクレジット・カード許可トランザクション・フローでは、ルーティング・デバイス３３０が、単一のデータ項目すなわちクレジット・カード番号を使用して、トランザクション／文書を送信する先を決定した。ルーティング・デバイス３３０でのＣＢＲ処理を、ステップ２５０で、クレジット・カード番号を抽出し、この情報を使用して仮想プロトコル・エンベロープに注釈を付け、その結果、ルーティング・デバイス３３０が、エンベロープの内側に何があるかを見るのではなくエンベロープ注釈だけを見ることによってそのルーティング決定を行えるようにすることによって、任意選択の最適化を実施するようにネットワーク・デバイス３４５を構成することによって、ルーティングされるｍＸＭＬ文書の内側を見る必要をなくすことによって、さらに最適化することができる。ＨＴＴＰトランスポート（プロトコル・エンベロープ）を使用する例では、この例の注釈を、クレジット・カード番号が値として含まれるＨＴＴＰヘッダ・フィールド内のcookieとすることができる。この例では、ルーティング・デバイス３３０が、クレジット・カード許可要求をサーバ３２５ｂに送信することを決定するためにこのcookie「注釈」を見ることだけが必要であり、これによって、ｍＸＭＬ文書の内側を見ないようになる。ルーティング・デバイス３３０が、それでも、図２に示されたステップ２６０を実行しなければならず、次のホップ／ターゲットが非ｍＸＭＬ対応である場合に文書をＸＭＬフォーマットに変換できなければならないことに留意されたい。
【００４０】
本発明の好ましい実施形態は、米国特許出願第０９／６５２０５６号明細書に完全に記載された、ｍＸＭＬ表記、ＸＭＬからｍＸＭＬへの変換方法、ｍＸＭＬからＸＭＬへの変換方法、およびｍＸＭＬの文書に対する他の操作を詳細に示す、下の図４ないし１２に関する説明に鑑みて、より簡単に理解することができる。
【００４１】
ｍＸＭＬ表記
図４に、既存のＸＭＬ表記で表現された単純な構造化文書であるＸＭＬ文書４００を示す。この文書には、３レベルの階層に編成された６つの要素が含まれる。要素名「root_element」を有するノード４０２は、ルート・ノードであり、階層の最上位にある。このノードは、要素名「level_one_element1」を有するノード４１０および要素名「level_one_element2」を有するノード４２０の２つの子ノードを有する。ノード４１０も、要素名「level_two_element11」を有するノード４１２および要素名「level_two_element12」を有するノード４１４の２つの子ノードを有し、ノード４２０は、要素名「level_two_element21」を有するノード４２２という単一の子ノードを有する。ＸＭＬ文書４００を表すツリー構造４３０を図５に示す。図５では、６つの要素のタグが、ツリーのノードを表す長方形の中に示され、各ノードに対応するデータ・コンテンツが、楕円形の中に示されている。このＸＭＬ文書４００の解釈およびそれに対応するツリー構造４３０は、当技術分野で周知である。
【００４２】
図６に、ｍＸＭＬ表記の構文の好ましい実施形態を使用する、図４のＸＭＬ文書４００と同一の情報を表す（図５のツリー構造４３０と同一のツリー構造を有する）ｍＸＭＬ文書４６０を示す。このｍＸＭＬ文書４６０では、２１６個の文字が使用されているが、同等のＸＭＬ文書４００では、２７３文字が使用される（さらに、ＸＭＬ文書４００には、約２３個の追加の非印字文字（空白、タブ、改行など）も含まれ、合計２９６文字になることに留意されたい）。既存のＸＭＬ表記と比較して、ｍＸＭＬの使用によって、構造化文書の保管に必要なバイト数が増える孤立した例が存在する可能性がある。しかし、この文字数の増加は、実際の実践では極端に希であると期待され、タグ名が極端に短い時にのみ発生する。したがって、ＸＭＬ文書の大多数が、ｍＸＭＬで表現される時により少ないスペースを必要とすることが期待される。
【００４３】
ｍＸＭＬ表記は、コンピュータが文書全体をすばやく効率的にスキャンでき、効率的に操作することもできる形でＸＭＬ文書を表現するように設計されている。したがって、文書は、そのｍＸＭＬフォーマットで直接に作成でき、ｍＸＭＬフォーマットで使用することができる。人間がヒューマン・フレンドリな形で文書を見なければならない（たとえば手作業の編集または他の目的で）希な機会に、ｍＸＭＬからＸＭＬへの変換を実行するために、比較的少ない量のオーバーヘッドをこうむる。既存のＸＭＬ構文で作成された文書は、ｍＸＭＬに変換することによって、より効率的に処理または保管することができる。
【００４４】
ｍＸＭＬ表記の長所には、下記が含まれる。
１）データ・コンテンツが、既存のＸＭＬ表記のように構造内に混ぜ合わされるのではなく、文書構造から分離される。図４ないし６の例では、データ・コンテンツに、要素値Ａ、Ｂ、Ｃ、Ｄ、およびＥと、属性名「id」および「name」（ノード４１０について）と「id」および「name」（ノード４２０について）と、対応する属性値１、１、２、および２が含まれる。図４に、従来技術でＸＭＬ文書４００全体にこの情報がどのように配置されるかを示す。その一方で、図６では、これらの値が、ｍＸＭＬ文書の末尾で、符号４８０によって示される位置から保管される。パーサが文書（ＸＭＬ文書４００またはｍＸＭＬ文書４６０）を操作する時に、パーサは、主に文書構造に関心を持つ。したがって、ｍＸＭＬ文書のデータ・コンテンツの処理は、それが必要な時まで遅延することができ、したがって、ｍＸＭＬで提供されるデータ構造とデータ・コンテンツの分離によって、パーサが、より効率的に動作できるようになる。
２）文書ツリー構造が、従来技術のＸＭＬタグを構文解析する時に必要であるようにルックアヘッド技法を使用して文書構造を推論するようにパーサに要求するのではなく、ｍＸＭＬを使用する時には文書内に明示的に保管される。したがって、ｍＸＭＬ文書を操作するパーサは、文書ツリーを構成する方法を学習する必要がなく、したがって、多数の計算集中型動作を除去することができる。その代わりに、ｍＸＭＬパーサは、単にｍＸＭＬ文書をスキャンし、明示的な既に保管された情報（下で詳細に説明する）に従ってツリーを再作成する。
３）ｍＸＭＬパーサの動作に必要な重要な情報が、前もってｍＸＭＬ文書内に保管され、その結果、パーサが、対応する文書ツリーを構成する時にそのメモリ操作を最小にすることができる。具体的に言うと、ノード・カウントが、事前に計算され、ｍＸＭＬ文書に保管される。ｍＸＭＬ表記の好ましい実施形態によれば、この値は、ｍＸＭＬ文書の先頭に保管される（代替実施形態では、データ・コンテンツのサイズも、事前に計算され、明示的に保管される。追加してまたはその代わりに、望むならば、データ・バッファの文書内の開始位置を明示的に保管することができ、これによって、下で図１０に関して説明する後方スキャン処理などの必要な追加処理なしでデータ・バッファに直接にアクセスできるようになる）。したがって、パーサは、動作の開始時に必要なメモリのほとんどを割り振ることができ、これによって、パーサが実行しなければならない計算的に高価なメモリ割振り動作（および割振り解除）の数が減る。さらに、メモリの割振りおよび割振り解除が頻繁に行われる時に発生する高コストのガーベッジ・コレクション動作を最小にすることができる。
【００４５】
前に述べたように、ｍＸＭＬ文書は、ノードの数の整数カウントまたは、同等であるが、文書内で表現されるタグ名の数から始まることが好ましい。ＸＭＬ文書をｍＸＭＬに変換する時には、このカウントが、開始タグ構文の出現についてスキャンすることによって簡単に判定される。
【００４６】
コメントは、一般に、ｍＸＭＬ文書がターゲットとする計算機に有用でないので、ノード・カウントに、コメント開始タグが含まれないことが好ましく、コメント・テキストが、そのような変換中に破棄されることが好ましい。その一方で、特定の文書に使用される文書型定義（「ＤＴＤ」）を識別するタグなどの有効な他のタグを、ＸＭＬからｍＸＭＬへの変換中に、そのようなタグの適当なキーワードを検索し、突き止められたコメントを保存することによって、ｍＸＭＬ表記に含めることができる。このタイプのタグを処理するのに好ましい技法を、下で、図１０の説明の前に詳細に説明する。
【００４７】
データ・サイズも文書内に明示的に保管される代替実施形態では、この整数値が、セミコロンなどの適当な区切り文字を使用して、ノード・カウントに続くことが好ましい。この代替実施形態の整数データ・カウントには、各属性名および各属性値の文字数と、各ノードのデータ値の文字数が含まれることが好ましい。というのは、これらの項目のすべてが、文書のデータ・バッファ区域（すなわちｍＸＭＬ文書の末尾）に保管されるからである。
【００４８】
１つまたは複数のノード指定が、ノード・カウントに続く。ノード指定のそれぞれが、好ましい実施形態で使用される括弧などの、開始区切り文字および終了区切り文字に囲まれることが好ましい（したがって、別の区切り文字をノード・カウントに続ける必要はない）。その代わりに、左右の大括弧など、開始区切り文字および終了区切り文字に別の構文を使用することができる。図６に示されているように、ｍＸＭＬに使用される区切り文字またはトークンの間にスペースを設けないことが好ましい。これによって、保管要件および伝送要件を最小にできるようになる。したがって、ノード・カウントに、最初の区切り左括弧が直接に続き、その直後に、最初のノード名が続き、以下同様である。
【００４９】
ｍＸＭＬ構文の好ましい実施形態によるノード指定に含まれる要素を、これから説明する。本明細書に開示された発明的概念から逸脱せずに、これらの要素の順序を変更できることに留意されたい。
好ましい実施形態のノード指定は、ノード名（すなわちそのタグ値）を明示的に記録することによって開始される。この名前の後に、区切り文字が続き、この区切り文字は、好ましい実施形態ではセミコロンである。ノードの子ノードのリストがこの区切り文字に続き、この子リストに、区切り文字のもう１つの出現と、ノードの属性情報のリストが続く。この属性情報に区切り文字が続き、この区切り文字に、ノードのデータ・コンテンツを突き止められるようにする情報が続く（その代わりに、たとえば好ましい実施形態のセミコロン区切り文字の代わりにコンマを使用し、その逆も行うことによって、好ましい実施形態で使用される区切り文字の意味を変更することができる）。
【００５０】
ノード指定の情報を、図４ないし６の例に関して詳細に説明する。図４に示されたノード４０２は、ノード４１０およびノード４２０という２つの子ノードを有する。ノード４１０は、この例の６つのノードの２番目であり、ノード４２０は、５番目のノードである。好ましい実施形態では、０ベースのカウントを使用し（既に説明したノード・カウントを除く）、したがって、ノード４０２の子リストは、構文「１、４」（２番目と５番目のノードを参照する）を使用して指定されて、全体的なタグ・シーケンス内のこのノードの子の相対位置が示される。ノード４１０は、ノード４１２およびノード４１４という２つの子ノードを有し、これらは、ＸＭＬ文書の３番目と４番目のノードである。したがって、ノード４１０の子リストは、「２、３」として指定される。あるノードが３つ以上の子を有する場合には、子ノードは、文書に現れる順番で指定され、コンマ（好ましい実施形態では）によって区切られる。たとえばノード４１２の場合のように、ノードに子がない場合には、その子リストは空であり、子の不在が、そのノード名に直接に続く、１行の中での２つのセミコロンの存在によって示される。
【００５１】
属性リスト内の各属性の情報も、コンマを使用して区切られることが好ましい。各属性の情報内では、区切り文字としてピリオドを使用することが好ましい。図４を参照すると、ノード４１０は、２つの属性を有する。最初の属性は、属性名「id」および属性値「１」を有する。したがって、属性名の長さは２であり、属性値の長さは１である。したがって、やはり０ベースのカウントを使用して、ノード４１０の属性リストで表される最初の属性は、「０．２．２．１」と指定され、これは、属性の名前が、データ・バッファ内で位置０から始まる２文字の長さで見つかり、値が、位置２から始まる１の長さで見つかることを意味する。図６に示されているように、データ・バッファは、ｍＸＭＬ文書の末尾に保管されることが好ましい。したがって、パーサは、構文解析中に、必要でない時に、これらの文字のスキャンを避けることができる。
【００５２】
この例のノード４１０の第２の属性は、名前「name」および値「１」を有する。したがって、この第２の属性の情報は、構文「３．４．７．１」を使用して指定され、これは、属性の名前が、データ・バッファ内で位置３から始まる４文字の長さで見つかり、その値が位置７から始まる１の長さで見つかることを意味する。ノードが３つ以上の属性を有する場合には、このドット区切り構文が、そのような属性のそれぞれについて使用され、コンマを区切り文字として使用して、このノードの他の属性指定から分離される。子リスト構文と同様に、ノードが属性を有しない場合には、その不在が、空の属性リストを指定することによって示される。
【００５３】
この実施形態で使用される構文では、ノード４１０の属性名および属性値について説明したように、開始位置および長さ値を使用してデータ・バッファを参照するが、代替構文では、データ・バッファ内の開始位置および終了位置を使用することができる。したがって、ノード４１０の最初の属性の指定は、「０．１．２．２」と表現され、これは、属性名が、位置０から始まり、位置１で終わり、属性値が、位置２から始まり、位置２で終わることを意味する。同様に、第２の属性の指定は、「３．６．７．７」と表現される。この実施形態の構文として選択された、長さ値の使用は、一般に、終了位置の使用よりわずかに少ないスペースを必要とする。
【００５４】
各ノード指定の最終項目は、データ・バッファ内のノードのデータの位置である。データ・バッファを参照する他の項目と同様に、この位置は、開始位置および長さとして指定されることが好ましく（しかし、代替実施形態では、開始位置および終了位置として指定することができる）、位置は、整数値として指定される。整数は、コンマによって区切られることが好ましく、０ベース・カウントを使用する。この例のノード４０２のように、ノードがデータを有しない場合には、この最後の項目を、空のままにする。ノード４１０は、この例では単一文字のデータ値を有し、したがって、このノードのノード指定の最終項目は、「８、１」になる。図６の構文の例からわかるように、属性名および属性値は、ｍＸＭＬデータ・バッファ内でノードのデータ・コンテンツと混ぜ合わされることが好ましい。
【００５５】
最後に、最後のノード（図６の例ではノード４２２）のノード指定の直後に、データ・バッファのコンテンツが続く。上で説明したように、整数ポインタ値によって、このデータ・バッファ内で各データ項目が始まる場所とその長さが指定されるので、データ・バッファ内でホワイト・スペースまたは他の区切り文字を使用する必要はない。
【００５６】
データ・バッファの先頭からのオフセットに関して開始位置を指定する代わりに、代替案として、ｍＸＭＬ文書の先頭からのオフセットとして開始位置を指定することができる。しかし、この手法は、わずかに多いスペースを必要とし、構造情報の長さの増減があるたびに、データ・バッファ・オフセットを再計算することが必要になる。
【００５７】
したがって、ｍＸＭＬ文書の構造が、文書内で明示的に指定されることがわかる。この情報は、望むならば、ＤＯＭ（Document Object Model）ツリーの作成に使用することができる。その後、ＤＯＭツリーを、従来技術と同様に処理することができる。その代わりに、ｍＸＭＬ文書表記を直接にトラバースして、たとえば、特定のノードに関する情報を突き止める、文書の全体的な構造を判定する、またはｍＸＭＬ文書に対する他の操作を行うことができる。ｍＸＭＬ文書は、米国特許出願第０９／６５２２９６号明細書に記載のアレイベースの拡張可能文書保管フォーマットを使用して保管することができ、これによって、文書を操作する時のさらなる処理効率（同特許出願明細書に記載）がもたらされる（ＤＯＭは、World Wide Web Consortium（「Ｗ３Ｃ」）勧告、表題「Document Object Model (DOM) Level 1 Specification, Version 1.0」（１９９８年）として公表され、ウェブのhttp://www.w3.org/TR/REC-DOM-Level-1で入手可能である。「ＤＯＭ」は、米国マサチューセッツ工科大学の商標である）。
【００５８】
ｍＸＭＬ文書またはそのアレイベース表現に対して直接に実行できる動作の例として、ノードの子またはおそらくはその親を判定することが必要になる場合がある。ｍＸＭＬ文書内の子リストを使用して各ノードの子を明示的に指定する技法を、上で説明した。ノードの親は、ターゲット・ノードのシーケンス番号を使用して子リストをトラバースすることによって、簡単に判定することができる。たとえば、ノード４１４の親を判定する必要があると想定されたい。このノードは、図６のノード指定で４番目に出会うノードであり、これは、０ベース・カウントを使用する時のシーケンス番号３に対応する。子リスト内にこのシーケンス番号が含まれるノード指定を突き止めることによって、ノード４１０が、ノード４１４の親である（また、ノード４１４が２つの子の２番目である）ことがわかる。
【００５９】
ＸＭＬ表記には、データ中心の文書指定に厳密に必要ではない複数の表記要素が含まれる。「ＳＭＬ」（Simple Markup Languageの略である）と称するＸＭＬサブセットが、現在、技術コミュニティで議論されている。このＸＭＬサブセットでは、ＸＭＬ構文のコア・セットを使用し、属性、処理命令などの機能を省略することが提案されている。たとえば、ラクエイ（Robert E. La Quey）著の、http://www.xml.com/pub/1999/11/sml/index.htmlで入手可能なウェブ公開された論文、表題「SML: Simplifying XML」（１９９９年１１月２４日公開）を参照されたい。本明細書に記載の好ましいｍＸＭＬ構文は、ＸＭＬ表記要素の１つのコア・セットのサポートを提供し（ＳＭＬについて提案されたコア・セットと同一ではないが）、基本ノード・タイプに、要素および属性が含まれる。追加のノード・タイプを含むより複雑なＸＭＬ文書は、この好ましいｍＸＭＬ構文を拡張することによってサポートでき、この場合に、追加のノード・タイプに、コメント・ノード、処理命令ノード、ＣＤＡＴＡノード、エンティティ・ノード、エンティティ参照ノード、および文書型ノードが含まれる。この拡張されたｍＸＭＬ構文を指定する好ましい技法では、「テキスト」ノードが、実際のノード・コンテンツを参照するためにｍＸＭＬ文書に追加される。上にリストしたものなどのノード・タイプのノード指定は、ｍＸＭＬ文書内でインラインに、対応するＸＭＬ文書に現れるのと同一の相対位置に現れることが好ましい。このノード指定には、ノード名の代わりのヌル値と、子がテキスト・ノードであることを除いて上で説明したノード指定で使用されるものと同様の１つまたは複数の子ノードを指すリストと、空の属性リストと、ノード値指定としての特殊な標識の対が含まれることが好ましい。特殊な標識対の中の開始位置項目が、どのタイプの他のノードが表現されるかを示すのに使用される。たとえば、−２の値が、コメントを表し、−３の値が、処理命令を表すなどである。特殊な標識対の中の長さ項目には、−１がセットされることが好ましい。特殊な子リストから参照される子テキスト・ノードのそれぞれのノード指定でも、ヌルの名前と、ヌルの子リストおよび属性リストが使用されることが好ましい。この子テキスト・ノードの値項目は、（１）ノードのコンテンツ（好ましくはソース・ノードからの意味のあるコンテンツのすべてを表す文字ストリングとして）が保管されるデータ・バッファ内の位置を指し、（２）このコンテンツの長さを保管する。
【００６０】
さらに、ＳＭＬ構文を、ｍＸＭＬの好ましい実施形態に関して説明した属性情報が省略される代替実施形態を使用して表すことができる。
【００６１】
ｍＸＭＬ文書へのＸＭＬ文書の変換
ＸＭＬ文書をｍＸＭＬ文書に変換するのに使用することができる、少なくとも２つの手法がある。第１の手法では、特殊なパーサを、この目的のために作成し、このパーサが、既存のＸＭＬパーサに類似する形でＸＭＬ構文を構文解析し、その後、ｍＸＭＬ構文を使用して、対応する文書を生成する。本明細書で開示する教示を使用すると、既存のＸＭＬ構文解析技法をこの目的に適合させる方法が明白になる（たとえば、Java（Ｒ）プログラミング言語で記述されたパーサを、ノード、属性名、属性値などの開始および終了を検出した時にイベントを発火させるように作成することができ、この場合に、適当なｍＸＭＬ構成を作成することによってこれらのイベントを処理するプログラミング・コードを作成する）。
【００６２】
第２の手法すなわち、図７の論理に関してこれから説明する好ましい実施形態では、従来技術のＸＭＬパーサを呼び出して、ＤＯＭツリーを作成する。このＤＯＭツリーをトラバースし、その中で表された文書情報を、ｍＸＭＬ構文を使用して、単純かつ効率的に書き出す。
【００６３】
図７を参照すると、変換処理は、ブロック５００で開始され、ここで、従来技術のＸＭＬパーサを使用して、ＸＭＬ文書を構文解析し、対応するＤＯＭツリーを作成する。その後、ブロック５１０で、このＤＯＭツリー内のノードのカウントを取得し、これを整数値としてバッファに書き込むが、このバッファは、作成されるｍＸＭＬ文書を保管するのに使用され、したがって、「ｍＸＭＬバッファ」と称する。その後、「データ・バッファ」と称する第２のバッファを初期化し、このデータ・バッファ内の現在位置を指すのに使用されるカウンタも初期化する（ブロック５２０）。
【００６４】
ブロック５３０ないし５８０の論理が、その後、ＤＯＭツリーをトラバースする際に繰り返される。図６に示された出力のｍＸＭＬ文書内のノードの順序付けと位置合せするために、深さ優先トラーバサルを使用することが好ましい。代替案では、望むならば、出力文書内のノードを、幅優先で作成し、出力文書内で指定することができる。
【００６５】
ＤＯＭツリーの終りに達していない間は、ブロック５３０のテストが否定の結果を有し、したがって、処理は、ブロック５４０で継続される。そうでない場合には、制御はブロック５９０に移る。ブロック５４０で、開始区切り文字「（」をｍＸＭＬバッファに書き込んで、現在ＸＭＬからｍＸＭＬに変換されつつあるノードのノード指定を開始する。その後、ブロック５５０で、ＤＯＭツリーからノードの名前を取得し、これをｍＸＭＬバッファの次の位置に書き込み、セミコロン区切り文字を続ける。
【００６６】
ブロック５６０で、子リストを作成し、ｍＸＭＬバッファの次の位置に書き込み、やはり出力文字にセミコロン区切り文字を続ける。ＤＯＭツリーから、ノードが子を有しないことが示される場合には、区切り文字だけを書き出す。そうでない場合には、子ノードの順序性を判定し、これらのノードの対応する整数値（０ベース・カウントに関して表現されることが好ましい）を、コンマ区切りリストとして書き込む。
【００６７】
ブロック５７０で、ノードの属性情報があれば、これを変換し、ｍＸＭＬバッファに書き込み、セミコロン区切り文字を続ける。ＤＯＭツリー内で突き止められている現在のノードの属性のそれぞれについて、属性の名前および値を、データ・バッファ内の連続する位置に書き込む。名前が開始されるデータ・バッファ内の位置および名前の長さを、属性指定の最初の２つのドット区切り整数としてｍＸＭＬバッファに書き込む。その後、ブロック５１０で初期化されたデータ・バッファ・カウンタを、属性名の長さだけ増分する。同様に、属性値が開始されるデータ・バッファ内の位置および属性値の長さを、ドット区切り表記を使用して（属性名の長さに続くドットの後に）ｍＸＭＬバッファに書き込み、データ・バッファ・カウンタを、属性値の長さだけ増分する。このノードが複数の属性を有する場合には、ｍＸＭＬバッファにコンマを書き込んで、ドット区切り属性指定を区切る。
【００６８】
属性リストの終りをマークするセミコロン区切り文字を書き込んだ後に、ノードのデータ内容を処理する（ブロック５８０）。ＤＯＭツリーから、ノードがデータ・コンテンツを有しないことが示される場合には、右括弧区切り文字をｍＸＭＬバッファに書き込み、ブロック５３０に制御を戻す。そうでない場合には、ブロック５８０の処理が、データ・コンテンツをデータ・バッファの次に使用可能な位置に書き込むことによって継続される。このコンテンツの開始位置は、データ・バッファ・カウンタの現在値によって示される。したがって、この値を、ｍＸＭＬバッファに書き込み、コンマ区切り文字とコンテンツの整数の長さを続ける。データ・バッファ・カウンタをこの長さだけ増分し、右括弧をｍＸＭＬバッファに書き込む。その後、制御をブロック５３０に戻して、次のノードを処理する。
【００６９】
ＤＯＭツリーのすべてのノードが処理された時に、処理はブロック５９０に達する。対応するノード指定が、ｍＸＭＬに変換されており、ｍＸＭＬバッファに保管される。属性名および属性値が、ノードのデータ・コンテンツと共に、データ・バッファに保管されている。したがって、ブロック５９０では、データ・バッファからの情報を、ｍＸＭＬバッファの末尾に付加する。ｍＸＭＬバッファに、図４に示されたものなどの入力ＸＭＬ文書に対応する、図６に示されたものなどのｍＸＭＬ文書が含まれる。このｍＸＭＬ文書を、望みに応じて処理、送信、または後の使用のために保管することができる（データ・バッファのコンテンツをｍＸＭＬバッファに付加することの代替案として、この情報を伝えるポインタを設けることができる。これは、たとえば、変換が、別のコンピュータへのｍＸＭＬ文書の送信の前提条件として実行される場合に有用になる可能性がある。この場合には、ｍＸＭＬバッファのコンテンツを、まず送信し、その後に、ポインタを使用して突き止められるデータ・バッファのコンテンツを続けることができる）。
【００７０】
ｍＸＭＬ文書のＸＭＬ文書への変換
図８および９に、本発明の好ましい実施形態による、ｍＸＭＬ文書をＸＭＬ文書に変換するのに使用することができる論理を示す流れ図を示す（代替案では、米国特許出願第０９／６５２０９６号明細書に開示されたアレイベース構造で表現されたｍＸＭＬコンテンツを処理し、これらのアレイをトラバースする際に単純にＸＭＬ文書を書くことによって、ＸＭＬ文書を構成することができる。これを達成できる方法は、単純である）。
【００７１】
ｍＸＭＬ文書を構文解析し、それに対応するＸＭＬ文書を生成する処理は、ブロック６００で、ＸＭＬ文書を構成するのに使用されるバッファへのポインタと、ソース文書のｍＸＭＬデータ・バッファの先頭を指すデータ・バッファ・ポインタを初期化することによって開始される。ブロック６００では、ソースｍＸＭＬ文書からどのノード指定が現在処理されつつあるかを追跡するのに使用されるノード・ポインタも初期化される。
【００７２】
その後、ｍＸＭＬ文書からのノード指定を処理し、それに対応するＸＭＬ表現を作成するために、ブロック６０５ないし６８５の論理が、繰返し実行される（この論理は、下で説明するように、ブロック６８０から再帰的に呼び出される再入可能コードとして実施されることが好ましい）。
【００７３】
ブロック６０５で、次の左括弧区切り文字までスキャンすることによって見つかる次のノード指定をｍＸＭＬ文書から取得し、この指定を指すようにノード・ポインタをセットする。ブロック６１０で、処理が完了した（すなわち、ノード指定がもうない）かどうかを調べるためにテストする。このテストが肯定の応答を有する時には、ＸＭＬ文書が完成しており、制御はブロック６９０に移る。ブロック６９０では、ＸＭＬ文書を、特定の実施形態の必要に応じて処理することができる。たとえば、変換された文書を保管するのにインメモリ・バッファが使用された場合には、バッファ・コンテンツを永続的記憶媒体に書き込むことが好ましい。その後、図８および図９の処理が終了する。
【００７４】
ｍＸＭＬ文書に処理しなければならない別のノード指定がある時に、制御がブロック６１５に達する。ブロック６１５では、このノード指定から、左括弧区切り文字の次の位置から始めて最初のセミコロン区切り文字の前の位置までの、ノード名を得る。ブロック６２０で、開始ＸＭＬタグ区切り文字「＜」をＸＭＬバッファの現在位置に書き込み、このノードの名前を続け、ＸＭＬバッファ・ポインタをそれ相応に（すなわち、ＸＭＬバッファの次の位置へ）移動する。
【００７５】
ブロック６２５で、次の連続するセミコロン区切り文字に達するまでスキャンすることによって、子リストを得る。ブロック６３０で、子リストが空であるかどうかを調べる。そうである場合には、制御はブロック６４０に移る。そうでない場合には、ｍＸＭＬ文書内のリストからの子ノードのインデックス値を保管する（代替案では、ブロック６２０の動作の後に属性リストまで直接にスキャンすることによって、処理のこの点からブロック６２５ないし６３５の処理を省略することができる。この場合には、子リストが、ブロック６７５の動作の直前に、ノード指定を逆にスキャンすることによって得られることが好ましく、これによって、後の使用のためにインデックス値を保管する必要がなくなり、このリストが空であるかどうかに関して２つのテストを実行する必要がなくなる）。
【００７６】
ブロック６４０で、ノード指定から属性リストを得る。このリストを検査して（ブロック６４５）、それが空であるかどうかを調べる。そうでない場合には、ブロック６５０で、各属性の情報をＸＭＬバッファに書き込み、バッファ・ポインタを移動する。
【００７７】
各属性の情報の書込には、ブロック６２０で書き出されたノード名に続くブランク・スペースの書込が含まれることが好ましい。このブランク・スペースの後に、属性リストからの開始位置および長さをデータ・バッファ・ポインタと共に使用してｍＸＭＬデータ・バッファ内でインデクシングすることによって見つかる属性名と、その後、（ｉ）任意選択のブランク・スペース、（ｉｉ）等号、（ｉｉｉ）もう１つの任意選択のブランク・スペース、および（ｉｖ）左引用符が続く。その後、属性リストからの開始位置および長さを、データ・バッファ・ポインタと共に使用して、ｍＸＭＬデータ・バッファから属性値を得る。この属性値を、ＸＭＬデータ・バッファに書き込み、その後に右引用符を続ける。この処理が、属性リストの属性のそれぞれについて繰り返えされ（各属性名／値対が、ブランク・スペースを使用して前の対から分離されることが好ましい）、その後、処理が、ブロック６５５で継続される（好ましい実施形態を、ブランク・スペースを使用するＸＭＬ文書内での出力トークンの分離に関して説明するが、複数のブランク・スペース、タブ文字、または改行など、他の分離文字を同等に使用できることは明白である）。
【００７８】
ブロック６５５で、終了タグ区切り文字「＞」をＸＭＬ出力バッファに書き込む。その後、ブロック６６０で、ｍＸＭＬ文書からノードの値情報を得る。値がない場合には、ブロック６６５のテストが否定の結果を有し、ブロック６７０の処理が迂回される。そうでない場合には、ブロック６７０で、ノード指定の開始位置および長さをｍＸＭＬデータ・バッファ・ポインタと共に使用して、実際のノード値を入手し、この値をＸＭＬ出力バッファの次の位置に書き込む。
【００７９】
その後、ブロック６７５で、子ノードの前に保管したリスト（ブロック６３５から）が空であるかどうかをテストする。そうでない場合には、ブロック６８０で、子ノードをＸＭＬバッファに書き込む。これは、子ノードのそれぞれについてブロック６０５ないし６８５の論理を再帰的に呼び出すことによって実行されることが好ましく、その場合に、この子ノードの指定は、ｍＸＭＬ文書を介する単純な順序通りのトラバースを使用してブロック６０５で得られる。
【００８０】
ブロック６８５に達した時に、現在のノードのすべての子ノードが処理済みである。ブロック６８５で、「＜／」とその後のブロック６１５で判定されたノード名とその後の「＞」という構文を有する終了タグをＸＭＬバッファに書き込む。その後、制御をブロック６０５に戻して、次のノード指定を処理する。
【００８１】
ｍＸＭＬ文書の構文解析
図１０に、本発明による、好ましいｍＸＭＬ構文を使用するｍＸＭＬ文書を構文解析するのに使用することができる論理の好ましい実施形態を示す流れ図を示す。この処理は、ブロック７００で開始され、ここで、文書のサイズ情報（すなわちノードの数）を、入力をスキャンすることによって判定する。サイズ情報は、ｍＸＭＬ文書の最初のトークンとして見つかり、整数値になる。ｍＸＭＬ文書を、米国特許出願第０９／６５２０９６号明細書に開示されたアレイベース表現を使用して保管する場合には、サイズ情報を使用して、ブロック７１０でアレイを作成する。
【００８２】
その後、ブロック７２０で、ｍＸＭＬ文書のデータ・バッファがどこから始まるかを判定する。これに、文書コンテンツの末尾から、最初の（すなわち、最後に発生する）右括弧（または、括弧がノード指定に使用されない場合に、ノード指定の終了のために置換された他の区切り文字）を突き止めるまで、逆の順序で文書をスキャンすることが含まれることが好ましい。当技術分野で周知のように、区切り文字として使用するために定義された記号を、単純にデータの文字として使用する必要がある機会がありえる。エスケープ文字を定義して、区切り文字を通常の文字値として表現できるようにすることができる。したがって、このスキャンでは、この状況を考慮に入れ、最初のエスケープされていない右括弧を突き止めることが好ましい。データ・バッファは、図６の符号４８０によって示されるように、ｍＸＭＬ文書の次の順次位置から始まる（エスケープされた文字を考慮に入れることを、図１０に関してこれ以上は説明しない。当業者は、この処理を扱う方法を容易に理解するであろう）。
【００８３】
代替案では、前に述べたように、データ・バッファの位置またはデータ・バッファのサイズがｍＸＭＬ文書内で明示的に指定される時に、ブロック７２０の処理に、単に事前に保管された情報を使用することが含まれる。
【００８４】
ブロック７３０のテストで、文書内のすべての要素を構文解析したかどうかを調べる。このテストは、次の文字がノード指定開始区切り文字（好ましい実施形態では左括弧）でない時に、肯定の結果を有する。この場合には、図１０の構文解析処理が完了しており、制御は、ブロック７９０に示されているように、呼出し元の論理に返される。
【００８５】
文書内の要素が、完全には構文解析されていない時には、ブロック７３０のテストが、否定の結果を有し、処理が、ブロック７４０で継続される。ブロック７４０に示されているように、次の要素（すなわち次のノード）を、構文解析しなければならない。これには、ノード指定の開始の括弧を超えて位置決めすることが含まれる。その後、ブロック７５０で、ｍＸＭＬ文書からノードの名前を構文解析する。好ましい実施形態の構文では、これに、セミコロン区切り文字に出会うまで文字を読み取ることが含まれる。これらの文字が、ノードの名前を表し、保管または他の形で使用することができる。
【００８６】
ブロック７６０で、ノードの子リストを構文解析する。子リストは、ノードの名前に続くセミコロン区切り文字の後の文字から始まり、次のセミコロン区切り文字まで続く。子リストにコンマが含まれる場合には、これが、複数の子ノードがあることを示す（望むならば、この子リストのノードのノード指定を、子リストからの子のノード番号を使用して子のノード指定に位置決めし、ブロック７４０ないし７８０の論理を再帰的に呼び出すことによって、この時点で解析することができる。この場合には、適当な代替の「終了」テストが、ブロック７３０で使用される）。
【００８７】
ブロック７７０で、ノードの属性リストを構文解析する。この属性リストは、子リストを終了するのに使用されたセミコロン区切り文字に続き、次のセミコロン区切り文字まで続く。望むならば、これらの属性の名前および値を、ブロック７２０で判定されたデータ・バッファ開始位置を、属性リストに使用されるドット区切り表記内の整数として指定される個々の開始位置値および長さ値と共に使用して、データ・バッファから取り出すことができる。コンマが、ドット区切り表記の４つの整数の次に検出される場合には、これが、同一の形で処理される追加属性の存在を示す。
【００８８】
その後、ブロック７８０で、ノードの値を突き止める。これには、ノード指定の最後のセミコロン区切り文字に続く、コンマ区切り文字を用いて互いに分離される、開始位置値および長さ値を得ることが含まれる。ブロック７７０の属性名および属性値と同様に、ノード値を、データ・バッファへのポインタをノード名の開始値および長さ値と共に使用して、データ・バッファから取り出すことができる。
【００８９】
その後、制御をブロック７３０に戻し、構文解析しなければならないノード指定がまだあるかどうかを判定する。
【００９０】
ワークステーション／デバイス
図１１に、本発明を実践することができるコンピュータ・システムを示す。図１１のワークステーションのハードウェアは、当技術分野で周知のタイプである。図１１の環境には、関連する周辺装置を含むパーソナル・コンピュータなどの、代表的な単一ユーザ・コンピュータ・ワークステーションであるワークステーション８１０が含まれる。ワークステーション８１０には、マイクロプロセッサ８１２と、周知の技法に従ってマイクロプロセッサ８１２とワークステーション８１０の構成要素との間での接続と通信の使用可能化に使用されるバス８１４が含まれる。ワークステーション８１０には、通常は、ユーザ・インターフェース・アダプタ８１６が含まれ、ユーザ・インターフェース・アダプタ８１６は、キーボード８１８、マウス８２０、または、接触感知スクリーン、ディジタル化入力パッドなどの任意のユーザ・インターフェース・デバイスとすることができる他のインターフェース・デバイス８２２など、１つまたは複数のインターフェース・デバイスにバス８１４を介してマイクロプロセッサ８１２を接続する。バス８１４は、ＬＣＤスクリーンまたはモニタなどの表示装置８２４を、表示アダプタ８２６を介してマイクロプロセッサ８１２に接続する。バス８１４は、ハード・ディスク、ディスケット・ドライブ、磁気テープ・ドライブなどを含めることができる長期保管媒体８３０およびメモリ８２８にもマイクロプロセッサ８１２を接続する。
【００９１】
ワークステーション８１０は、たとえば通信チャネルまたはモデム８３２を介して、他のコンピュータまたはコンピュータのネットワークと通信することができる。代替案では、ワークステーション８１０が、ＣＤＰＤ（cellular digital packet data）カードなどの、符号８３２にある無線インターフェースを使用して通信することができる。ワークステーション８１０を、ＬＡＮまたは広域ネットワーク（ＷＡＮ）内の他のコンピュータと関連付けることができ、または、ワークステーション８１０を、別のコンピュータとのクライアント／サーバ配置のクライアントとすることができる。これらの構成のすべて、ならびに適当な通信ハードウェアおよびソフトウェアが、当技術分野で周知である。
【００９２】
本発明は、ワークステーションではなく、サーバまたはメインフレーム（参照を簡単にするために、以下ではサーバと称する）上で動作することができる。サーバのハードウェア環境は、当技術分野で周知である。または、本発明は、携帯情報端末（ＰＤＡ）、ポータブル・コンピューティング・デバイスなどの他のコンピューティング・デバイス上で動作することができる。本発明の使用を介して作成される文書は、コンピューティング・デバイスによって使用される永久的記憶媒体または取外し可能記憶媒体に保管することができ、また、そのようなデバイスとサーバの間、またはサーバと別のサーバの間で伝送することができ、この場合に、これらのタイプのデバイスを、ネットワークによって接続することができる。
【００９３】
好ましい実施形態では、本発明が、コンピュータ・ソフトウェアで実施される。このソフトウェアの実施形態は、１つまたは複数のコンピュータ・プログラムの１つまたは複数のモジュール（コード・サブルーチンまたは、オブジェクト指向プログラミングで「オブジェクト」とも称する）として動作することができる。
【００９４】
同様に、本発明は、ルータ、スイッチ、ロード・バランサ、プロキシ、ＴＣＰシェーパなどのネットワーク装置による実行のために、コンピュータ・ソフトウェアまたはハードウェアで実施することができる
【００９５】
ネットワーク
図１２に、本発明を実践することができる例示的なデータ処理ネットワーク９４０を示す。データ処理ネットワーク９４０には、無線ネットワーク９４２およびネットワーク９４４など、それぞれに複数の個々のワークステーション８１０を含めることができる、複数の個々のネットワークを含めることができる。さらに、当業者が諒解するように、１つまたは複数のＬＡＮ（図示せず）を含めることができ、ＬＡＮに、ホスト・プロセッサに結合された複数のインテリジェント・ワークステーションを含めることができる。
【００９６】
さらに図１２を参照すると、無線ネットワーク９４２およびネットワーク９４４に、ゲートウェイ・コンピュータ９４６またはアプリケーション・サーバ９４７（データ・リポジトリ９４８にアクセスできる）などのメインフレーム・コンピュータまたはサーバも含めることができる。ゲートウェイ・コンピュータ９４６は、各ネットワーク９４４への入口点として働く。ゲートウェイ・コンピュータ９４６は、通信リンク９５０ａによって別の無線ネットワーク９４２に結合できることが好ましい。ゲートウェイ・コンピュータ９４６は、通信リンク９５０ｂおよび９５０ｃを使用して、１つまたは複数のワークステーション８１０に直接に結合することもできる。ゲートウェイ・コンピュータ９４６は、ＩＢＭ社が販売するEnterprise Systems Architecture/370、Enterprise Systems Architecture/390コンピュータなどを使用して実施することができる。応用分野に応じて、Application System/400（ＡＳ／４００とも称する）などのミッドレンジ・コンピュータを使用することができる（「Enterprise Systems Architecture/370」は、ＩＢＭ社の商標であり、「Enterprise Systems Architecture/390」、「Application System/400」、および「AS/400」は、ＩＢＭ社の登録商標である）。これらは、本発明を使用することができるコンピュータの代表的なタイプにすぎない。
【００９７】
ゲートウェイ・コンピュータ９４６を、ストレージ・デバイス（データ・リポジトリ９４８など）に結合９４９することもできる。さらに、ゲートウェイ・コンピュータ９４６を、１つまたは複数のワークステーション８１０に直接にまたは間接的に結合することができ、ゲートウェイ・コンピュータ９４６およびアプリケーション・サーバ９４７などのサーバを、他のサーバに結合することができる。
【００９８】
当業者は、ゲートウェイ・コンピュータ９４６を、無線ネットワーク９４２から大きい地理的距離に配置することができ、同様に、ワークステーション８１０を、無線ネットワーク９４２およびネットワーク９４４からかなりの距離に配置することができることを諒解するであろう。たとえば、無線ネットワーク９４２を、カリフォルニアに配置し、ゲートウェイ・コンピュータ９４６を、テキサスに配置し、１つまたは複数のワークステーション８１０を、ニューヨークに配置することができる。ワークステーション８１０を、セル電話、ラジオ周波数ネットワーク、衛星ネットワークなどの多数の代替接続媒体上の伝送制御プロトコル／インターネット・プロトコル（「ＴＣＰ／ＩＰ」）などのネットワーキング・プロトコルを使用して無線ネットワーク９４２に接続することができる。無線ネットワーク９４２は、ＩＰ上のＴＣＰまたはＵＤＰ（ユーザ・データグラム・プロトコル）、Ｘ．２５、フレーム・リレー、ＩＳＤＮ（サービス総合ディジタル網）、ＰＳＴＮ（公衆交換電話網）などの通信リンク９５０ａを使用してゲートウェイ・コンピュータ９４６に接続されることが好ましい。ワークステーション８１０は、代替案では、ダイヤル接続の９５０ｂまたは９５０ｃを使用して、ゲートウェイ・コンピュータ９４６に直接に接続することができる。さらに、無線ネットワーク９４２およびネットワーク９４４を、図３に示されたものに類似する形で、１つまたは複数の他のネットワーク（図示せず）に接続することができる。
【００９９】
本発明を実施するソフトウェア・プログラミング・コードは、通常は、ＣＤ−ＲＯＭドライブまたはハード・ディスクなどの、あるタイプの長期保管媒体８３０から、マイクロプロセッサ８１２（たとえば、ワークステーション８１０、データ・リポジトリ９４８、ゲートウェイ・コンピュータ９４６、またはアプリケーション・サーバ９４７の）によってアクセスされる。ソフトウェア・プログラミング・コードは、ディスケット、ハード・ディスク、またはＣＤ−ＲＯＭなどのデータ処理システムと共に使用するためのさまざまな周知の媒体のいずれかの上で実施することができる。コードは、そのような媒体上で配布することができ、また、あるコンピュータ・システムのメモリまたはストレージから、あるタイプのネットワークを介して他のコンピュータ・システムへ、そのような他のシステムのユーザによる使用のために、ユーザに配布することができる。代替案では、プログラミング・コードを、メモリ８２８内で実施し、バス８１４を介してマイクロプロセッサ８１２によってアクセスすることができる。メモリ内または物理媒体上でソフトウェア・プログラミング・コードを実施するか、ネットワークを介してソフトウェア・コードを配布する、技法および方法は、周知であり、本明細書ではこれ以上は説明しない。
【０１００】
本発明は、ネットワーキング環境内のクライアント・コンピュータまたはサーバ上で、もしくは、独立型ワークステーション上で（たとえば、ネットワーク接続を介して、取外し可能記憶媒体を介して、などの形で受け取られたファイルを処理するか、ファイルを準備するために）使用することができる（本明細書でのクライアント・デバイスおよびサーバ・デバイスへの言及が、例示を目的とし、制限を目的としないことに留意されたい。本発明は、他のネットワーキング・モデルと共に有利に使用することもできる）。ネットワーキング環境で使用される時に、クライアント・デバイスおよびサーバ・デバイスを、「有線」接続または「無線」接続を使用して接続することができる。有線接続とは、ケーブルおよび電話回線などの物理的媒体を使用する接続であり、無線接続では、衛星リンク、ラジオ周波数波、赤外線波などの媒体が使用される。多くの接続技法を、これらのさまざまな媒体と共に使用することができ、電話回線上の接続を確立するためにコンピュータのモデムを使用すること、トークン・リングまたはイーサネット（Ｒ）などのＬＡＮカードを使用すること、無線接続を確立するためにセルラ・モデムを使用することなどが可能である。ワークステーションまたはクライアント・コンピュータは、ラップトップ、ハンドヘルド、またはモバイル・コンピュータ；車載デバイス；デスクトップ・コンピュータ；メインフレーム・コンピュータ；などを含む、処理（および、任意選択として通信）機能を有する、あらゆるタイプのコンピュータ・プロセッサとすることができる。サーバは、同様に、処理機能および通信機能を有する、任意の数の異なるタイプのコンピュータの１つとすることができる。これらの技法は、当技術分野で周知であり、それらの使用を可能にするハードウェア・デバイスおよびソフトウェアを、簡単に入手できる。
【０１０１】
同様に、本発明を、たとえば無線ネットワーク９４２およびネットワーク９４４などのネットワーク内の、ルータ、スイッチ、ロード・バランサ、プロキシ、ＴＣＰシェーパなどのネットワーク・デバイスによる実行のために、コンピュータ・ソフトウェアまたはハードウェアで実施することができる。
【０１０２】
本発明の好ましい実施形態を説明してきたが、当業者は、基本的な発明的概念を習得した時に、その実施形態の追加の変形形態および修正形態を思い浮かべることができる。具体的に言うと、ＸＭＬ表記の変更が発生した場合に、好ましい実施形態をその変更に適合させることができ、本明細書で開示された発明的概念も、構文的にＸＭＬに類似する他の表記と共に使用するために適合させることができる。したがって、請求項は、好ましい実施形態と、本発明の趣旨および範囲に含まれるすべての変形形態および修正形態の両方を含むものとして解釈されることが意図されている。
【０１０３】
まとめとして、本発明の構成に関して以下の事項を開示する。
【０１０４】
（１）  拡張可能でヒューマン・フレンドリなＸＭＬ（extensible markup language）でエンコードされた入力文書を処理する方法であって、
（ａ）前記ＸＭＬでエンコードされた入力文書を、マシン向きの拡張可能なマークアップ言語（「ｍＸＭＬ」）でエンコードされた出力文書に変換するステップと、
（ｂ）前記ｍＸＭＬでエンコードされた出力文書を処理するステップと、
（ｃ）前記処理された出力文書が次にルーティングされるターゲットを識別するステップと、
（ｄ）前記ターゲットがｍＸＭＬでエンコードされた文書を処理できるかどうかを判定するステップと
を含む方法。
（２）  ステップ（ｃ）が、前記処理された出力文書を構文解析するステップを含む、上記（１）に記載の方法。
（３）  ステップ（ｃ）が、前記処理された出力文書のルーティングのためにホスト名ストリングを識別するステップを含む、上記（２）に記載の方法。
（４）  ステップ（ｄ）が、データ・ストアを参照するステップを含み、前記データ・ストアが、複数のターゲットを識別し、前記複数のターゲットのそれぞれがｍＸＭＬでエンコードされた文書を処理できるかどうかを示すデータを保管する、上記（１）に記載の方法。
（５）  ステップ（ａ）が、
（ａ１）前記入力文書の文書ツリー表現を作成するステップと、
（ａ２）前記文書ツリー表現内のノードのカウントを表すノード・カウントを得るステップと、
（ａ３）前記ノード・カウントをｍＸＭＬバッファに書き込むステップと、
（ａ４）前記文書ツリー表現内の各ノードをトラバースし、前記ｍＸＭＬバッファ内で対応するノード指定を生成するステップであって、
ノード名を生成するステップと、
前記ノードの属性に関する０個以上の（属性名、属性値）対参照を指定する属性リストを生成するステップと、
前記ノードの子である０個以上のノードのインデックス値を指定する子リストを生成するステップと、
前記ノードが値を有しない場合に空である、ノード値指定を生成するステップと
を含むステップと、
（ａ５）前記属性リストから参照される属性名および属性値と、前記ノード値指定から参照されるノード値とを含むデータ・バッファを生成するステップと、
（ａ６）前記出力文書を形成するために、前記ｍＸＭＬバッファに前記データ・バッファを付加するステップと
を含む、上記（１）に記載の方法。
（６）  ステップ（ｂ）が、
（ｂ１）前記出力文書を構文解析するステップ
を含む、上記（１）に記載の方法。
（７）  ステップ（ｂ１）が、
（ｂ１ａ）前記出力文書からルーティング・データを抽出するステップ
を含む、上記（６）に記載の方法。
（８）  ステップ（ｂ）が、
（ｂ１）前記ターゲットがステップ（ｄ）でｍＸＭＬでエンコードされた文書を処理できると判定される場合に、前記処理された出力文書を前記ターゲットに送るステップ
を含む、上記（１）に記載の方法。
（９）  ステップ（ｂ）が、
（ｂ１）前記ターゲットがステップ（ｄ）でｍＸＭＬでエンコードされた文書を処理できると判定される場合に、content based routingのために前記出力文書を処理するステップ
を含む、上記（１）に記載の方法。
（１０）  （ｅ）前記ターゲットがステップ（ｄ）でｍＸＭＬでエンコードされた文書を処理できないと判定される場合に、前記処理されたｍＸＭＬでエンコードされた出力文書をＸＭＬでエンコードされた出力文書に変換するステップ
をさらに含む、上記（１）に記載の方法。
（１１）  （ｆ）前記変換されたＸＭＬでエンコードされた出力文書を処理するステップ
をさらに含む、上記（１０）に記載の方法。
（１２）  ステップ（ｆ）が、前記変換されたＸＭＬでエンコードされた出力文書を前記ターゲットに送るステップを含む、上記（１１）に記載の方法。
（１３）  ステップ（ｂ１）が、
（ｂ１ａ）前記文書内のノードのカウントを表すノード・カウントを構文解析するステップと、
（ｂ１ｂ）前記ノードのそれぞれのノード指定を構文解析するステップであって、
ノード名を構文解析するステップと、
前記ノードの子である０個以上のノードのインデックス値を指定する子リストを構文解析するステップと、
前記ノードの属性に関する０個以上の（属性名、属性値）対参照を指定する属性リストを構文解析するステップと、
前記ノードが値を有しない場合に空である、ノード値指定を構文解析するステップと
をさらに含むステップと、
（ｂ１ｃ）前記属性リストから参照される属性名および属性値と前記ノード値指定から参照されるノード値とを含むデータ・バッファを構文解析するステップと
を含む、上記（６）に記載の方法。
（１４）  マシン向きの拡張可能なマークアップ言語（「ｍＸＭＬ」）でエンコードされた入力文書を処理する方法であって、
（ａ）前記入力文書が、次に、ｍＸＭＬでエンコードされた文書を処理できるターゲットにルーティングされるかどうかを判定するステップと、
（ｂ）前記ターゲットがステップ（ａ）でｍＸＭＬでエンコードされた文書を処理できないと判定される場合に、前記ｍＸＭＬでエンコードされた入力文書を、ヒューマン・フレンドリなＸＭＬ（extensible markup language）でエンコードされた出力文書に変換するステップと、
（ｃ）前記ＸＭＬでエンコードされた出力文書を処理するステップと
を含む方法。
（１５）  ステップ（ａ）が、
（ａ１）前記入力文書が次にルーティングされるターゲットを識別するステップと、
（ａ２）前記ターゲットがｍＸＭＬでエンコードされた文書を処理できるかどうかを判定するステップと
を含む、上記（１４）に記載の方法。
（１６）  ステップ（ａ２）が、データ・ストアを参照するステップを含み、前記データ・ストアが、複数のターゲットを識別し、前記複数のターゲットのそれぞれがｍＸＭＬでエンコードされた文書を処理できるかどうかを示すデータを保管する、上記（１５）に記載の方法。
（１７）  ステップ（ｂ）が、
（ｂ１）前記入力文書の文書ツリー表現を識別するステップと、
（ｂ２）ノード・カウントをｍＸＭＬバッファから読み取るステップと、
（ｂ３）前記文書ツリー表現内の各ノードをトラバースし、前記ｍＸＭＬバッファ内で対応するノード指定を生成するステップであって、
ノード名を識別するステップと、
前記ノードの属性に関する０個以上の（属性名、属性値）対参照を指定する属性リストを識別するステップと、
前記ノードの子である０個以上のノードのインデックス値を指定する子リストを識別するステップと、
前記ノードが値を有しない場合に空である、ノード値指定を識別するステップと
をさらに含むステップと、
（ｂ４）前記属性リストから参照される属性名および属性値と、前記ノード値指定から参照されるノード値とを含むデータ・バッファを生成するステップと、
（ｂ５）前記出力文書を形成するために、ＸＭＬバッファに前記データ・バッファを付加するステップと
を含む、上記（１４）に記載の方法。
（１８）  （ｄ）前記ｍＸＭＬでエンコードされた入力文書を処理するステップ
をさらに含む、上記（１４）に記載の方法。
（１９）  ステップ（ｄ）が、前記ｍＸＭＬでエンコードされた入力文書を構文解析するステップを含む、上記（１８）に記載の方法。
（２０）  ステップ（ｃ）が、前記ＸＭＬでエンコードされた出力文書を送るステップを含む、上記（１４）に記載の方法。
（２１）  １つまたは複数のコンピュータ可読媒体上で実施されるコンピュータ・プログラムであって、拡張可能でヒューマン・フレンドリなＸＭＬ（extensible markup language）でエンコードされた入力文書を処理するように適合されたコンピュータ・プログラムであって、
前記ＸＭＬでエンコードされた入力文書を、マシン向きの拡張可能なマークアップ言語（「ｍＸＭＬ」）でエンコードされた出力文書に変換するコンピュータ可読プログラム・コードと、
前記ｍＸＭＬでエンコードされた出力文書を処理するコンピュータ可読プログラム・コードと、
前記処理された出力文書が次にルーティングされるターゲットを識別するコンピュータ可読プログラム・コードと、
前記ターゲットがｍＸＭＬでエンコードされた文書を処理できるかどうかを判定するコンピュータ可読プログラム・コードと
を含むコンピュータ・プログラム。
（２２）  前記拡張可能なヒューマン・フレンドリなＸＭＬ（extensible markup language）でエンコードされた入力文書を、マシン向きの拡張可能なマークアップ言語（「ｍＸＭＬ」）でエンコードされた出力文書に変換する前記コンピュータ可読プログラム・コードが、
前記入力文書の文書ツリー表現を作成するコンピュータ可読プログラム・コード手段と、
前記文書ツリー表現内のノードのカウントを表すノード・カウントを得るコンピュータ可読プログラム・コード手段と、
前記ノード・カウントをｍＸＭＬバッファに書き込むコンピュータ可読プログラム・コード手段と、
前記文書ツリー表現内の各ノードをトラバースし、前記ｍＸＭＬバッファ内で対応するノード指定を生成するコンピュータ可読プログラム・コード手段であって、
ノード名を生成するコンピュータ可読プログラム・コード手段と、
前記ノードの属性に関する０個以上の（属性名、属性値）対参照を指定する属性リストを生成するコンピュータ可読プログラム・コード手段と、
前記ノードの子である０個以上のノードのインデックス値を指定する子リストを生成するコンピュータ可読プログラム・コード手段と、
前記ノードが値を有しない場合に空である、ノード値指定を生成するコンピュータ可読プログラム・コード手段と
を含むコンピュータ可読プログラム・コード手段と、
前記属性リストから参照される属性名および属性値と、前記ノード値指定から参照されるノード値とを含むデータ・バッファを生成するコンピュータ可読プログラム・コード手段と、
前記出力文書を形成するために、前記ｍＸＭＬバッファに前記データ・バッファを付加するコンピュータ可読プログラム・コード手段と
を含む、上記（２１）に記載のコンピュータ・プログラム。
（２３）  前記出力文書を処理する前記コンピュータ可読プログラム・コードが、ｍＸＭＬでエンコードされた文書を処理するコンピュータ可読プログラム・コードであって、
前記文書を構文解析するコンピュータ可読プログラム・コード手段であって、さらに、
前記文書内のノードのカウントを表すノード・カウントを構文解析するコンピュータ可読プログラム・コード手段と、
前記ノードのそれぞれのノード指定を構文解析するコンピュータ可読プログラム・コード手段であって、さらに、
ノード名を構文解析するコンピュータ可読プログラム・コード手段と、
前記ノードの子である０個以上のノードのインデックス値を指定する子リストを構文解析するコンピュータ可読プログラム・コード手段と、
前記ノードの属性に関する０個以上の（属性名、属性値）対参照を指定する属性リストを構文解析するコンピュータ可読プログラム・コード手段と、
前記ノードが値を有しない場合に空である、ノード値指定を構文解析するコンピュータ可読プログラム・コード手段と
を含むコンピュータ可読プログラム・コード手段と、
前記属性リストから参照される属性名および属性値と前記ノード値指定から参照されるノード値とを含むデータ・バッファを構文解析するコンピュータ可読プログラム・コード手段と
を含むコンピュータ可読プログラム・コード手段と、
前記構文解析された文書を前記処理の入力として使用するコンピュータ可読プログラム・コード手段と
を含む、上記（２１）に記載のコンピュータ・プログラム。
（２４）  拡張可能でヒューマン・フレンドリなＸＭＬ（extensible markup language）でエンコードされた入力文書を処理するシステムであって、
前記ＸＭＬでエンコードされた入力文書を、マシン向きの拡張可能なマークアップ言語（「ｍＸＭＬ」）でエンコードされた出力文書に変換する手段と、
前記ｍＸＭＬでエンコードされた出力文書を処理する手段と、
前記処理された出力文書が次にルーティングされるターゲットを識別する手段と、
前記ターゲットがｍＸＭＬでエンコードされた文書を処理できるかどうかを判定する手段と
を含むシステム。
（２５）  前記拡張可能でヒューマン・フレンドリなＸＭＬ（extensible markup language）でエンコードされた出力文書を、マシン向きの拡張可能なマークアップ言語（「ｍＸＭＬ」）でエンコードされた出力文書に変換する前記手段が、
前記入力文書の文書ツリー表現を作成する手段と、
前記文書ツリー表現内のノードのカウントを表すノード・カウントを得る手段と、
前記ノード・カウントをｍＸＭＬバッファに書き込む手段と、
前記文書ツリー表現内の各ノードをトラバースし、前記ｍＸＭＬバッファ内で対応するノード指定を生成する手段であって、さらに、
ノード名を生成する手段と、
前記ノードの属性に関する０個以上の（属性名、属性値）対参照を指定する属性リストを生成する手段と、
前記ノードの子である０個以上のノードのインデックス値を指定する子リストを生成する手段と、
前記ノードが値を有しない場合に空である、ノード値指定を生成する手段と
を含む手段と、
前記属性リストから参照される属性名および属性値と、前記ノード値指定から参照されるノード値とを含むデータ・バッファを生成する手段と、
前記出力文書を形成するために、前記ｍＸＭＬバッファに前記データ・バッファを付加する手段と
を含む、上記（２４）に記載のシステム。
（２６）  前記ｍＸＭＬの出力文書を処理する前記手段が、
前記文書を構文解析する手段であって、さらに、
前記文書内のノードのカウントを表すノード・カウントを構文解析する手段と、
前記ノードのそれぞれのノード指定を構文解析する手段であって、さらに、
ノード名を構文解析する手段と、
前記ノードの子である０個以上のノードのインデックス値を指定する子リストを構文解析する手段と、
前記ノードの属性に関する０個以上の（属性名、属性値）対参照を指定する属性リストを構文解析する手段と、
前記ノードが値を有しない場合に空である、ノード値指定を構文解析する手段と
を含む手段と、
前記属性リストから参照される属性名および属性値と前記ノード値指定から参照されるノード値とを含むデータ・バッファを構文解析する手段と
を含む手段と、
前記構文解析された文書を前記処理の入力として使用する手段と
を含む、上記（２４）に記載のシステム。
（２７）  入力文書を処理する方法であって、
（ａ）前記入力文書が、次に、マシン向きの拡張可能なマークアップ言語（「ｍＸＭＬ」）でエンコードされた文書を処理できるターゲットにルーティングされるかどうかを判定するステップと、
（ｂ）前記入力文書がｍＸＭＬでエンコードされ、前記ターゲットがｍＸＭＬでエンコードされた文書を処理できない場合に、前記入力文書をヒューマン・フレンドリなＸＭＬ（extensible markup language）でエンコードされた出力文書に変換するステップと
を含む方法。
（２８）  （ｃ）ＸＭＬでエンコードされた元の文書を、マシン向きの拡張可能なマークアップ言語（「ｍＸＭＬ」）でエンコードされた入力文書に変換するステップ
をさらに含み、ステップ（ｃ）がステップ（ａ）のまえに実行される、上記（２７）に記載の方法。
（２９）  ステップ（ａ）が、
（ａ１）前記入力文書が次にルーティングされるターゲットを識別するステップと、
（ａ２）前記ターゲットがｍＸＭＬでエンコードされた文書を処理できるかどうかを判定するステップと
を含む、上記（２８）に記載の方法。
（３０）  ステップ（ａ１）が、前記入力文書を構文解析するステップを含む、上記（２９）に記載の方法。
（３１）  ステップ（ａ２）が、データ・ストアを参照するステップを含み、前記データ・ストアが、複数のターゲットを識別し、前記複数のターゲットのそれぞれがｍＸＭＬでエンコードされた文書を処理できるかどうかを示すデータを保管する、上記（３０）に記載の方法。
【図面の簡単な説明】
【図１】従来技術のＸＭＬ表記を使用する例示的な文書を示す図である。
【図２】本発明の好ましい実施形態による、文書を処理する論理を示す流れ図である。
【図３】本発明による例示的なネットワーク化されたコンピューティング環境を示す図である。
【図４】既存のＸＭＬ表記で作成された単純な構造化文書を示す図である。
【図５】図４の従来技術のＸＭＬ文書の構造およびデータ・コンテンツを表すツリー構造を示す図である。
【図６】ｍＸＭＬ表記で表現された、図４と同等の構造化文書を示す図である。
【図７】本発明の例示的実施形態による、ＸＭＬ文書のｍＸＭＬ文書への変換の論理を示す流れ図である。
【図８】本発明の例示的実施形態による、ｍＸＭＬ文書のＸＭＬ文書への変換の論理を示す流れ図の前半である。
【図９】本発明の例示的実施形態による、ｍＸＭＬ文書のＸＭＬ文書への変換の論理を示す流れ図の後半である。
【図１０】本発明の例示的実施形態による、ｍＸＭＬ文書の構文解析の論理を示す流れ図である。
【図１１】本発明を実践することができるコンピュータ・ワークステーション環境のブロック図である。
【図１２】本発明を実践することができるネットワーク化されたコンピューティング環境を示す図である。
【符号の説明】
２１０  ｍＸＭＬ対応ネットワーク・デバイスが、文書を受信するステップ
２２０  文書がｍＸＭＬ文書であるかどうかを判定するステップ
２３０  文書がＸＭＬ文書であるかどうかを判定するステップ
２４０  文書をＸＭＬからｍＸＭＬに変換するステップ
２５０  ネットワーク・デバイスが、内部使用のために文書を処理するステップ
２６０  文書が次にｍＸＭＬ対応デバイスにルーティングされるかどうかを判定するステップ
２７０  ネットワーク・デバイスが、外部使用のために文書を処理するステップ
２９０  文書をｍＸＭＬからＸＭＬに変換するステップ
【図１】
0004299492.tif 000002
【図２】
0004299492.tif 000003
【図３】
0004299492.tif 000004
【図４】
0004299492.tif 000005
【図５】
0004299492.tif 000006
【図６】
0004299492.tif 000007
【図７】
0004299492.tif 000008
【図８】
0004299492.tif 000009
【図９】
0004299492.tif 000010
【図１０】
0004299492.tif 000011
【図１１】
0004299492.tif 000012
【図１２】
0004299492.tif 000013