JP2005534107A - レジストリ駆動型相互運用性及び文書の交換 - Google Patents

Abstract

本発明は、企業間又はアプリケーション間で交換される文書のレジストリ駆動型変換のためのシステム及び方法に関する。より具体的には、本発明は、１つ又はそれ以上の共通にアクセス可能なレジストリを用いて、異なるインターフェース間の電子商取引文書、好ましくはＸＭＬ文書を変換するためのシステム及びプロトコルに関する。本発明の特定の態様は、特許請求の範囲、明細書、及び図面に記載される。

Description

本発明は、企業間又はアプリケーション間で交換される文書のレジストリ駆動型意味変換のためのシステム及び方法に関する。より具体的には、本発明は、１つ又はそれ以上の一般にアクセス可能なレジストリを用いて、異なるインターフェース間の電子商取引文書、好ましくはＸＭＬ文書を変換するためのシステム及びプロトコルに関する。
（著作権に関して）
本特許文献の開示の一部は、著作権保護の対象となる題材を含んでいる。著作権者は、本特許文献が米国特許商標庁の特許ファイル又は記録において公開されたときに、誰であっても特許文献又は特許の開示を複写することに異議はないが、他の場合には、如何なる場合にも全ての著作権を留保する。

企業間（Ｂ２Ｂ）及びアプリケーション間（Ａ２Ａ）の電子商取引は、電子データ交換（ＥＤＩ）のためのこれまでのプロトコルを切り替えつつある。企業が、Ｂ２Ｂ及びＡ２Ａシステムを用いてその効率性を改善しようと努力するにつれて、多数の互換性のないプラットホーム及び競合する規格が登場した。認識されてきた必要性の１つは、あるシステムから別のシステムに文書を変換することである。

ＸＭＬは、インライン・マークアップを生成するために適用されなければならない厳格な構文規則によって、コンピュータ・プログラムが解釈して処理することが比較的簡単になるため、広く用いられる種類のデータとなった。例えば、ＸＭＬで書かれた購入注文は、何が購入されようとしているか、購入者はだれか、などを記述するマークアップ注釈の読み出し方を知っている受注ソフトウェア・アプリケーションによって処理されることができる。ＸＭＬが文書の符号化スキームとして次第に受け入れられつつあることが、エンタープライズ・アダプタ・インプリメンテーション（ＥＡＩ）ベンダによる、多くのレガシー・アプリケーションのためのＸＭＬ化されたアプリケーション・プログラム・インターフェイスの開発につながった。

ＥＡＩベンダは、アプリケーション間をベースとして、１つのシステムを次のシステムに繋ぐ。相互運用性は、設計時に、設計によって達成される。システム又はアプリケーション間の接続は、静的なものである。アプリケーションの新バージョンの実装には、静的な接続の修正が必要とされる。アプリケーション間の経路選択は、典型的には、企業内である。統合論理は、２地点間ベースで開発される。意味論理は、ＥＡＩルーチン内にコード化される。意味論理及び構文論理は、コーディングで組み合わされる。文書の送信集合すなわちソースは、自分が送信したものが正確に、ターゲットすなわち受け手が受信すると通知したものであることを保障する責任を負う。完全な互換性を求めるのとは対照的に、インターフェースについての互換性の程度をモデル化する概念は存在しない。サービスのインターフェースの最新バージョンを用いてすべてのクライアントを更新し、かつ、インターフェースを同時期に更新することが必要であるため、完全な互換性を達成することは難しい。変換コンポーネントは、再使用することが難しい。個々の変換の好みを取り込むか、又は、ユーザ・プロファイルに基づいて変換をサポートするために、共通にアクセスできるリポジトリが提供されていない。ＥＡＩベンダの手法では、変換ルーチンを１組のシステム又はアプリケーションからの別のシステム又はアプリケーションに適合させることが困難で高価なものになる。

図１は、４つの異なるシステムに送られてくる購入注文のサプライヤ処理に適用される、ＥＡＩベンダの手法を示す。この図においては、送られてくる購入注文は、３つのソース１０１、すなわち、電子データ交換（ＥＤＩ）バイヤー、オンライン・ストア・カスタマ、及びオープン・アプリケーション・グループ・ビジネス・オブジェクト・ドキュメント（ＯＡＧＢＯＤ）準拠バイヤーから発信される。ソースの各々は、ＥＡＩ基盤１０３に対する入力として購入注文を生成するネイティブ・インターフェース１０２を有する。文書のフォーマットは、ＥＤＩ、ＸＭＬ、及びＯＡＧを含むことができる。４つのターゲット・システム１０６は、ＳＡＰ財務システム、ＳＡＰＭＲＰシステム、ＢｉｚＩＱシステム、及びグレインジャー発送システムを含む。これらのターゲット・システムが受け入れる文書のネイティブ・フォーマット１０５は、ＩＤＯＣ、ＢＡＰＩ、ＯＡＧ、及び、カスタム・アプリケーション・プログラム・インターフェース（ＡＰＩ）を含む。ソースとターゲットとを接続するためには、構文及び意味の違いを克服する必要がある。２地点間アダプタ１０４は、ソース文書をターゲット文書に２つ１組で変換する。例えばＯＡＧ間変換などのように、異なる意味を含む文書を、同一構文を利用してシステム間で変換する場合でさえ、アダプタを必要とする。例えばＯｒａｃｌｅ財務システムをＳＡＰ財務システムに置き換えたり、又は、更新された発送システムがインストールされる場合のように、ソース・システム又はターゲット・システムが更新されたときは、新たなアダプタを書き込む必要がある。ＥＡＩ基盤は、古いアダプタと新しいアダプタとの両方を保持している可能性が高い。システムが更新されるにつれて、ますます多くのアダプタが変更又は交換の対象となる。単一の変換エンジンが変換プロセスを管理し、変換リソースを提供する。

したがって、異なるインターフェース間の文書の変換を共通に管理し、ランタイムの相互運用性と変換の分散実行とを提供する方法及び構造を発明する機会が生じる。

本発明は、企業間又はアプリケーション間で交換される文書のレジストリ駆動型変換のためのシステム及び方法に関する。より具体的には、本発明は、１つ又はそれ以上の共通にアクセスできるレジストリを用いて、異なるインターフェース間の電子商取引文書、好ましくはＸＭＬ文書を変換するためのシステム及びプロトコルに関する。本発明の特定の態様は、特許請求の範囲、明細書、及び図面に記載される。

以下の詳細な説明は、図面を参照して行われる。好ましい実施形態は、特許請求の範囲によって定められる本発明を説明するために記載されるものであって、本発明の範囲を限定するものではない。当業者であれば、以下の説明に関して種々の等価な変形物を認識するであろう。

図２は、４つの異なるシステムに向かうことになる、送られてくる購入注文のサプライヤ処理を示す。送られてくる購入注文は、３つのソース２０１、すなわち、ＥＤＩバイヤー、オンライン・ストア・カスタマ、及びＯＡＧ準拠バイヤーから発信される。３つのソース２０１が利用するネイティブ・フォーマットは、ＥＤＩ、ＸＭＬ、及びＯＡＧを含むことができる。４つのターゲット・システム２０６は、ＳＡＰ財務システム、ＳＡＰＭＲＰシステム、ＢｉｚＩＱシステム、及びグレインジャー発送システムを含む。これらのターゲット・システム２０６が受け入れるネイティブ・フォーマットは、ＩＤＯＣ、ＢＡＰＩ、ＯＡＧ、及びカスタムＡＰＩを含む。このシステムにおいては、ウェブ・サービス・エンジン２１１が、共通の構文基盤を用いて意味変換を行う。例えば、ＥＤＩ及びＯＡＧ文書は、共通の構文基盤としてのＸＭＬに変換される。ＸＭＬからＸＭＬへの変換は、ソース文書とターゲット文書との間の意味の違いを処理する。ＸＭＬ文書は、ＥＤＩ、ＯＡＧ、ＩＤＯＣ、又はＢＡＰＩなどのネイティブ・フォーマットに再変換することができる。ＸＭＬへの構文変換及びＸＭＬからの構文変換は、ウェブ・サービス・エンジン２１１の一部として、又はソース２０１及びターゲット２０６と関係付けられたインターフェース又はアダプタ２０２、２０５によって、処理することができる。

ウェブ・サービス・エンジン２１１は、共通の構文基盤を用いる変換を含む様々な変換２１３を利用できる。これらの変換は、再使用可能とすることができる。文書をソースの意味からターゲットの意味に変換するために、２つ以上の変換を呼び出すことができる。例えば送られてくる文書を、電子商取引文書２１２のためのｘＣＢＬスキーマのような汎用的な文書スキーマに変換するために、共通の意味基盤を利用することが好ましい場合がある。送られてくる文書を共通の意味基盤に変換することによって、２地点間変換についての必要性は最小になる。変換は、連鎖的に行うことができ、再使用可能とすることができる。変換は、同形又は準同形とすることができる。すなわち、変換は、完全に可逆的である必要はない。変換は、典型的には、変換に起因する損失の程度を推定するために、アプリオリに、又は、変換の前後でソース及びターゲットの意味を比較することによって、評価されることになる。変換成功スコアを用いて、ソースの意味からターゲットの意味への代替的な変換シーケンスの中から選択することができる。変換に起因する損失は、ソース文書からの不完全に変換された情報を取り込む１つ又はそれ以上のフィールドをターゲット文書に含めることによって、補償することができる。これらのフィールドはユーザが見られるようにすることができ、そのことにより、ソース、ターゲット、又は、中間のサービス・プロバイダと関連するユーザは、コンピュータ実装変換サービスの欠陥に対応することができる。或いはまた、不完全に変換されたか又は不完全に変換されたことが疑われるソース文書の部分に対する参照と共に、ソース文書及びターゲット文書をターゲットに送ることができる。これらの参照は、ターゲット文書の一部とするか、又はエラー文書などの別個の文書とすることができる。これらの参照は、文字列、ポインター、又は他の何らかの参照形態とすることができる。参照は、不完全に変換された情報が属するターゲット文書の１つ又はそれ以上のセクションに与えることができる。ターゲット文書に対する参照は、ターゲット文書の要素若しくはサブセクションに対するものか、又は、要素若しくはサブセクション内の特定の位置に対するものとすることができる。さらに別の実施形態においては、ターゲット文書とソース文書の抜粋とを、ソース文書の抜粋に対する参照、及び場合によってはターゲット文書に対する参照と共に、ターゲットに送ることができる。

図２に部分的に示される共通的にアクセス可能なレジストリによって、ＸＭＬスキーマ定義（ＸＳＤ）ベースのＸＭＬ電子商取引文書を用いたり、より一般的には、テキスト文字をコード化する文字データと、文書の論理構造に従ってストレージ・ユニットのセットを特定するマークアップ・データとを使用する構文についてのスキーマを用いたりしながら、コミュニティの管理を容易にする。少なくとも１つのリポジトリへの変換を保持することによって、必要な変換及び実行の両方の設計における再使用が容易になる。変換における共通アクセス可能なリポジトリが、分散実行も可能にする。ウェブ・サービス・エンジンは、ソース、ターゲット、又は中間サービスのリソースを用いることができる。ソース及びターゲットによって用いられるインターフェースを決定する際は、共通的にアクセス可能なレジストリか、又は、共通的にアクセス可能なレジストリから以前に取得した変換論理が保持されるキャッシュから、適切な変換論理を取得することができる。相互運用性は、１つ又はそれ以上のレジストリのエントリと、１つ又はそれ以上のリポジトリにある論理とに基づいて、実行時に確立される。実行時に、ソースとターゲットとの間の接続が動的に決定される。ソース又はターゲットがバージョン変更を実装するときは、接続の動的な決定がバージョン変更を考慮する。

共通的にアクセス可能なレジストリは、いわゆる意味ハブ(semantic hub)を提供することができる。共通的にアクセス可能なレジストリは、電子商取引サービスなどのサービスを提供するアプリケーションについてのサービス記述を保持することができる。入ってくる文書と出て行く文書のインターフェースは、好ましくはＸＳＤ定義の形態で、サービス記述の一部として登録される。サービスは、例えば電子商取引文書規格（例えば、ｘＣＢＬ２．０、ｘＣＢＬ３．０、又はｘＣＢＬ３．５）の多数のバージョン、又は、多数の文書規格（例えば、ｘＣＢＬ、ＩＤＯＣ、ＯＡＧ、又はＢＡＰＩ）に対応する多数のインターフェースを自由に登録することができる。文書ファミリーの概念を導入することによって、文書規格及び規格バージョン並びに顧客システムを越えて、スキーマ及び文書型を管理する方法が提供される。文書ファミリーは、同一のビジネス事象を表す文書型をファミリー内に関係付ける。変換マップ又は変換は、文書ファミリーのメンバー間で変換するための標準論理及びカスタム論理を管理する。特定の変換を用いるコストが、文書の不完全な変換を反映し得る。変換成功スコアは、以前の経験に基づいてアプリオリに、又は、変換適用の前後で文書の意味内容を動的に比較することによって、変換と関係付けることができる。

共通の構文基盤としてＸＭＬを用いて変換を保持することが好ましいが、必ずしも必要ではない。ＸＭＬは、宣言型マッピング論理を容易にする豊富な自己記述的データ表現である。ｘＣＢＬコンポーネント・モデルなどの幾つかの意味基盤は、ＸＭＬの強力な意味を利用する一貫性のある意味基盤を提供する。ＸＭＬ文書を意味レジストリに作ることによって、再利用と新しい変換の迅速な開発とが容易になり、それにより既存の変換の価値が高まる。共通の構文基盤だけでなく共通の意味基盤を持つ意味マッピングに焦点を当てることによって、新しい変換を開発する複雑さが軽減される。プログラマではなく事業アナリストが、変換オーサリング・ツールを用いて、ＸＭＬ間の意味変換を定めることが可能になる。

図３に示される文書ファミリーが、文書のカテゴリー化及びグループ化を可能にする。関連する文書が、同一の文書ファミリー３００の下にグループ化される。文書は、文書識別子によって特定することができる。文書識別子の論理構造を用いて、例えばＸＭＬ電子商取引文書のルート要素といった、メッセージのルート要素を表す。文書識別子は、文書ＩＤと、その関係と、バージョンと、ファミリーの関係とを指定することができる。ＸＭＬ文書及び非ＸＭＬ文書はともに、文書識別子が割り当てられ、共通レジストリに格納される。文書識別子の属性には、文書識別子（例えば名前「Ｏｒｄｅｒ」）と、名前空間（例えば、ｕｒｎ：ｘ−ｃｏｍｍｅｒｃｅｏｎｅ：ｄｏｃｕｍｅｎｔ：ｃｏｍ：ｃｏｍｍｅｒｃｅｏｎｅ：ＸＣＢＬ３０：ＸＣＢＬ３０．ｓｏｘ）と、文書ライブラリ名（例えば、ｘＣＢＬ、ＤＴＤ、ＥＤＩＦＡＣＴ）と、スキーマ言語（例えば、ＳＯＸ、ＸＳＤＬ）と、バージョン（例えば、３．０）と、文書ファミリー名（例えば、ＰｕｒｃｈａｓｅＯｒｄｅｒＦａｍｉｌｙ、ＰｒｉｃｅｌｎｑｕｉｒｙＦａｍｉｌｙ、ＱｕｏｔｅＦａｍｉｌｙ）とを含むことができる。文書ファミリーは、文書を、文書識別子によってバージョン階層で体系化する。図３においては、文書ファミリー・ツリー３００又は他のデータ構造を用いて、個々のファミリー３１０、３２０を体系化する。例えば、購入注文ファミリー３１０は、１つ又はそれ以上のメジャー・バージョン３１１、３１２、３１３を含むことができる。メジャー・バージョンの１つ又はそれ以上は、同様のツリー構造でマイナー・バージョン（図示せず）と関係付けられる。バージョン属性には、メジャー・バージョンとマイナー・バージョンの両方を記録することができる。メジャー・バージョンとマイナー・バージョンとの間の１つの可能な区別は、メジャー・バージョンが変換を必要とする大きな変更を有するのに対して、マイナー・バージョンは、サブ要素の拡張を除いて構造的な差がないことであろう。システムのユーザは、一般に、文書型自体を修正することなく文書のサブ要素を拡張することができる。このサブ要素の拡張は、文書型の修正が処理されるのと同じように、マイナー・バージョンとして扱うことができる。したがって、文書型ノードは、文書スキーマと、文書型要素を構成するすべてのスキーマとを表す。例えば、ＬｉｎｅＩｔｅｍ要素が拡張され、この拡張型がＰｕｒｃｈａｓｅＯｒｄｅｒのインスタンスで用いられる場合には、ｕｒｃｈａｓｅＯｒｄｅｒの文書型は、バージョン化される。サブ要素がバージョン化されたときは、ユーザは、新たな文書型を登録する。ユーザは、親文書型ノードを指定し、新たなマイナー・バージョン関係を親に割り当てる。バージョンＩＤが生成され、新たなノードに割り当てられる。

図４に示されるように、レジストリがスキーマを名前空間に細分することができる。ＸＭＬ名前空間（例えば、ＸＳＤ、ＳＯＸ、ＲｏｓｅｔｔａＮｅｔ、ＣＩＤＸ）及び非ＸＭＬ名前空間（例えば、ＥＤＩ、ＥＤＩＦＡＣＴ）は、スキーマ名前空間管理コンポーネントを用いて、登録し、管理することができる。スキーマ名前空間は、名前空間ＵＲＩと、名前と、分類と、名前空間ステータスと、妥当性ステータス（ＸＳＤ名前空間の場合）と、名前空間バージョンと、記述と、文書ライブラリ名と、スキーマ言語（ＸＳＤ型名前空間の場合）と、スキーマ・ファイルと、ビーン・ジャー・ファイル名と、従属名前空間（ＸＳＤ及びＳＯＸ型名前空間の場合に必要に応じて）と、外部ＵＲＬ又は通知ＵＲＬとを含む様々な属性を持つことができる。典型的には、異なるバージョンの名前空間は、異なるＵＲＩを有する。例えば、メジャーｘＣＢＬバージョン３．０ ４０１及びメジャーｘＣＢＬバージョン３．５ ４０２についての文書ライブラリは、それぞれ、マイナー・バージョンをサポートするのに用いることができる１つ又はそれ以上の名前空間（４１１、４１２、４１３）及び４１４を有する。スキーマを保持する１つの方法は、ｎの文書スキーマについてｎのファイルを用いることである。名前空間マネージャが、名前空間と、名前空間に関連するスキーマ・ファイルと、スキーマ・ファイルに対応するＪａｖａ（登録商標）Ｂｅａｎｓ及びクラスを含むＪａｖａジャー・ファイルとに関するメタ・データを格納することができる。ブラウザ・ベースのツールを利用するグラフィカル・ユーザ・インターフェースを用いて、名前空間セットの登録、アクティブ化、非アクティブ化、及び削除を管理することができる。公開名前空間は、関連するスキーマ・ファイルを含めて、ＸＭＬツール（ＸＤＫ）の検証ＡＰＩなどのツールを用いて最初に妥当性検証することができる。図４においては、２つの文書ライブラリ４０１、４０２が存在する。文書ライブラリの各々は、それぞれ、３つのスキーマ名前空間（４１１、４１２、４１３）及び４１４を含む。名前空間は、スキーマ・ファイル４２１〜４２５及び４２６と関係付けられる。購入注文についての名前空間ファミリー４３１からツリーを遡ってたどると、例えばｘＣＢＬ３．０型及びｘＣＢＬ３．５型の２つの購入注文４３２、４３３が、それぞれ特定の文書スキーマ４２１、４２６と関係付けられている。

図５は、ここでは変換によって相互接続された文書ファミリー・メンバーのネットワークとして描かれた、文書ファミリーの別の図を表す。この購入注文ファミリーにおいては、文書５０１、５０２、５０３は、ライブラリと、文書識別子と、バージョンと、スキーマ型によって特定される。例えば、文書５０１Ａは、ｘＣＢＬライブラリから、Ｏｒｄｅｒとして識別され、バージョンは４．０であり、スキーマ型ＸＳＤを用いるものである。文書５０１Ｃは、同様に、ｘＣＢＬライブラリから、Ｏｒｄｅｒとして識別され、バージョンは３．５であり、スキーマ型ＳＯＸを用いるものである。文書５０２Ａは、Ｘ１２マークアップ・ライブラリから、８５０文書として識別され、バージョンは４２００であり、スキーマ型ＸＳＤを用いるものである。文書５０２Ｂは、ＸＭＬでマークアップされたカスタム・フラット・ファイル文書である。これは、例えばテンプレート及びワード・プロセッサを用いて作成することができる種類の文書である。この図においては、文書ファミリー・メンバー間の各々の変換方向について、別々の変換を特定した。特定された変換型は、Ｃｏｎｔｉｖｏマップ、ＸＳＴマップ、ＸＳＬＴマップ、ＸＳＤ及びＳＯＸ間で変換するＪａｖａ（登録商標）クラス、Ｊａｖａ部分文字列置換、及びＪａｖａマップ（ＸＤＫ）を含む。文書ファミリー・メンバー間の変換及び逆変換について、異なる変換型を用いることができる。システムは、例えば既存のクラスの拡張のような新たな又は異なる変換型に適合させることができる。例えば、ｘＣＢＬバージョン３．５の５０１ＢからｘＣＢＬバージョン３．５の５０１Ｆへの翻訳には、ＸＳＬＴ変換を適用させる必要がある。逆方向の翻訳には、Ｊａｖａコンポーネントを適用させる必要がある。変換によって相互接続される文書ファミリー・メンバーのネットワークは、ノード（ファミリー・メンバー）間の相互接続が、異なる属性を持つ有向リンク（一方向変換）であるという意味で、有向グラフと考えることができる。ループすなわち循環参照を避けながらこのネットワークを巡回するために、周知のアルゴリズムを適用することできる。この図には示されないが、アプリオリな変換成功スコアすなわち経験ベースの変換成功スコアを、文書ファミリー・メンバーを結ぶ変換の各々に関係付けることができる。

図６及び図７は、図５に示されるような文書ファミリー内の変換を特定するのに用いることができるテーブルを示す。変換エンジンが実行時にこれらのテーブルにアクセスして、好ましい変換を特定することができる。幾つかの変換は、キャッシュに入れることができる。図６においては、ある文書ファミリー・メンバー６０１から別の文書ファミリー・メンバー６０２への変換は、表に記載された順に１つ又はそれ以上の論理コンポーネント６１１を適用することによって達成することができる。これらのロジックコンポーネントは、現在又は将来の文書規格及び変換規格に適合する、Ｊａｖａ（登録商標）クラス・ファイル、ＸＳＬＴマップ、ＸＳＴマップ、又は、他の何らかの業界標準変換若しくはカスタム変換とすることができる。変換成功スコア６１０は、ソース文書６０１をターゲット文書６０２に翻訳することによってもたらされる完全性を評価する。この例においては、変換項目は、ソース文書及びターゲット文書の属性によって索引付けされる。これらの属性は、文書ファミリー名前空間と、ファミリー名と、プロトコルと、スキーマ言語と、文書型と、ＸＭＬＱＮａｍｅと、バージョンＩＤとを含む。変換項目を検索するときは、ワイルドカードを検索に用いることができる。変換項目は、場合によっては、特別な規則６０３〜６０８についてのフラグを含んでもよい。カスタム変換は、取引パートナー・レベル、サービス・レベル、又はアクション・レベルで適用することができる。特定のソースの取引パートナー又はターゲットの取引パートナーについて特別な論理コンポーネントを用いるべきであることを示すために、ソースの取引パートナーＩＤ又はターゲットの取引パートナーＩＤのフラグを立てることができる６０３、６０４。同様に、特定のソースのサービス若しくはアクション又はターゲットのサービス若しくはアクションについて特別な論理コンポーネントを用いるべきであることを示すために、サービス及びアクションのフラグを立てることができる６０５〜６０８。変換エンジンは、利用可能な最も特定的な変換定義を用いるべきである。例えば、取引パートナーとサービスとアクションとのトリプレットに特定の定義は、取引パートナーのみによって指定される変換に、より特定的であると考えられるであろう。トリプレットの異なる要素が異なる変換について定義される場合には、階層重要性を、取引パートナー、サービス、又はアクションに割り当てることができる。例えば、２つの変換がソース文書型及びターゲット文書型に適合し、その一方の変換が取引パートナーに対して特定的であり、他方の変換がサービスに特定的である場合に、取引パートナーは、サービスより重要であると考えることができる。変換の他の属性が、特別な規則を生じさせる場合がある。本発明は、取引パートナー、サービス、及びアクションによってカテゴリー化される特別な規則に限定されるものではない。図７は、列６１１の変換のコンポーネントとして用いられる論理コンポーネント７０１に関する付加的な情報を与える。論理コンポーネント７０１について、型７０２、実装７０３、設定７０４、パッケージ７０５、及びバージョン７０６が提供される。

図８は、文書ファミリーを表すのに用いることができるクラスを示す。これらのクラスの幾つかの態様は、図３及び図４に示される論理構造に対応する。文書ライブラリ（ＤｏｃｕｍｅｎｔＬｉｂｒａｒｙ）８０１は、文書及びスキーマについての体系の最上位である。文書ライブラリの名前は、「ｘＣＢＬ」などの文字列で表される。ライブラリは、任意に、バージョン化することができる。ライブラリのバージョンは、文字列で表される。バージョン化されたライブラリ又バージョンされないライブラリについて、名前空間（Ｎａｍｅｓｐａｃｅ）を与えることができる８１１。名前空間クラスから名前空間クラスにポイントされる関係ループによって示されるように、名前空間の中で従属性が存在する場合がある。名前空間の属性は、名前空間ＵＲＩ（ｎａｍｅｓｐａｃｅＵＲＩ）と、名前（ｎａｍｅ）と、分類（ｃｌａｓｓｉｆｉｃａｔｉｏｎ）と、スキーマ言語（ｓｃｈｅｍａＬａｎｇｕａｇｅ）と、名前空間ステータス（ｎａｍｅｓｐａｃｅＳｔａｔｕｓ）と、妥当性ステータス（ｖａｌｉｄａｔｉｏｎＳｔａｔｕｓ）と、名前空間バージョン（ｎａｍｅｓｐａｃｅＶｅｒｓｉｏｎ）と、記述（ｄｅｓｃｒｉｐｔｉｏｎ）とを含む。これらの属性は、文字列（Ｓｔｒｉｎｇ）で表現することができる。さらに、名前空間が、アクティブか、非アクティブか、非推奨とされるか、又は消耗したかを示すために、フラグ又はフラグ値を提供することができる。フラグ又はフラグ値はまた、名前空間が妥当か妥当でないかを示すために提供することができる。名前空間と関係付けられるのは、外部リンク（ＥｘｔｅｒｎａｌＬｉｎｋ）８０３と、グローバル・エレメント（ＧｌｏｂａｌＥｌｅｍｅｎｔ）８２１と、スキーマ・ファイル（ＳｃｈｅｍａＦｉｌｅ）８２４と、外部ファイル（ＥｘｔｅｒｎａｌＦｉｌｅ）８２７である。この実施形態においては、名前空間は、ＵＲＬによってユニフォーム・リソース・ネームに外部的にリンクすることができる。外部リンク８０３の記述も提供することができる。名前空間は、グローバル・エレメント８２１のセットにリンクさせることができる。これらのグローバル・エレメントは、名前空間において認識される文書型に対応する、ＸＭＬ文書の妥当なルート要素名を表す。このグローバル・エレメントのクラスは、他のクラスに保持されるデータに対して冗長性を持たせることができる。名前空間はまた、スキーマ・ファイル８２４のセットにリンクさせることができる。ルート・スキーマ・ファイル又は他のスキーマ・ファイル・コンテナに対して、２つの別個のリンクを設けることができる。ルート・スキーマ・ファイルは、他のスキーマ・ファイルを結びつけるか又はそれらを含むルート・ファイルである。名前空間の間で従属関係が形成され、ある名前空間とすべての従属名前空間とについてのすべてのスキーマ・ファイルを取得することが可能になり、スキーマが、他の名前空間を矛盾した状態のままにして誤って除去されないことを保証する。スキーマ・ファイルの属性は、ファイル名（ｆｉｌｅＮａｍｅ）文字列と相対パス（ｒｅｌａｔｉｖｅＰａｔｈ）文字列とを含むことができる。代替的に、絶対パスを与えてもよい。スキーマ・ファイル要素８２４は、外部ファイル８２７によって表される。外部ファイル・オブジェクトは、ファイルの物理位置を形成するのに用いられ、物理ファイル表現を必要とするあらゆるエンティティが参照することができる。この外部ファイルは、例えば、名前空間に直接リンクされるビーン・ジャー・ファイルとすることができる。

名前空間は、この実施形態では文書ＩＤクラス（ＤｏｃＩｄ）８１２を介して、文書及び文書ファミリーにリンクされる。文書ＩＤ８１２は、実際には、名前空間に対する２つの種類のリンクを有することができ、一方は、名前空間が属するルート名前空間であり、他方は、拡張名前空間について用いられるものである。これは、メジャー・バージョンとマイナー・バージョンとに対応する。メジャー・バージョン文書ＩＤは、文書の以前のバージョンを拡張しない、文書の最新バージョンとすることができる。マイナー・バージョン文書ＩＤは、メジャー・バージョン文書ＩＤか、又はマイナー・バージョン文書ＩＤのいずれかを拡張することができる。メジャー・バージョン文書ＩＤは、内部でルート要素が定義される名前空間を参照する単一の名前空間関係のみを有することになる。マイナー・バージョン文書ＩＤは、内部に何らかの拡張が存在する他の何らかの名前空間と共に、スーパー親（メジャー・バージョン）文書ＩＤの名前空間を参照する。文書ＩＤ８１２は、文書ファミリー（ＤｏｃｕｍｅｎｔＦａｍｉｌｙ）８０４と、外部ＩＤ（ＥｘｔｅｒｎａｌＩｄ）８０５と、文書規約（ＤｏｃＩｄＲｕｌｅ）８１３と、変換マップ（ＴｒａｎｓｆｏｒｍａｔｉｏｎＭａｐ）８２３と、ＸＭＬ文書ＩＤ（ＸＭＬＤｏｃＩｄ）８２２と関係付けられる。文書ＩＤの属性は、名前（ｎａｍｅ）と、ＵＲＩと、一次代替ＵＲＩ（ｐｒｉｍａｒｙＡｌｔＵＲＩ）とを含むことができる。ＵＲＩは、３つのコンポーネント、すなわち、名前空間ＵＲＩと、文書ＩＤ名と、文書ＩＤバージョンとを用いて、文書ＩＤに対して自動的に生成される。この文書ＩＤ ＵＲＩは、この文書ＩＤを参照するのに用いられる。ユーザがカスタム文書ＩＤ命名スキームを必要とする場合には、自分自身のＵＲＩに入ることができ、これは、一次代替ＩＤ関係に設定される。ユーザは、２つ以上の命名スキームを持つこともでき、その場合には、他のＩＤ関係がこれらの名前を形成する。これらの名前のすべては、固有のものとすべきである。文書ＩＤの属性はさらに、表示名（ｄｉｓｐｌａｙＮａｍｅ）と、記述（ｄｅｓｃｒｉｐｔｉｏｎ）と、文書バージョン（ｄｏｃＶｅｒｓｉｏｎ）を含むことができる。これらの属性のすべては、文字列として保持することができる。文書ＩＤの特殊化は、ＸＭＬ文書についてのＸＭＬ文書ＩＤ８２２である。特殊化の属性は、ＸＭＬ要素名（ｘｍｌＥｌｅｍｅｎｔＮａｍｅ）と、バージョン型（ｖｅｒｓｉｏｎＴｙｐｅ）と、ビーン・クラス名（ｂｅａｎＣｌａｓｓＮａｍｅ）と、メジャー（ＭＡＪＯＲ）バージョン及びマイナー（ＭＩＮＯＲ）バージョンとを含むことができる。ＸＭＬの特徴として、関係ループは、ＸＭＬ文書ＩＤがネスト要素を表すことができることを示す。外部ＩＤ８０５は、文書ＩＤ８１２と関係付けることができる。外部ＩＤ８０５は、レジストリ・キー又はＵＲＩについてのエイリアスとすることができる。プライマリ・デフォルト・リンクと、１つ又はそれ以上のユーザ提供エイリアスとは共に、文書ＩＤと外部ＩＤとをリンクすることができる。

文書ＩＤ規約８１３は、変換と、妥当性検証と、表示マップとに対応するように、十分に一般化することができる。変換マップと呼ばれることもある変換８２３は、文書ＩＤ規約８１３の特殊化である。変換を実施する論理は、変換コンポーネント８２５のセットを介して文書ＩＤ規約８１３にリンクされる。変換コンポーネントは、次に、外部ファイル８２７にリンクされる。変換マップ８２３の属性は、コスト（ｃｏｓｔ）すなわち変換成功スコアと、変換ＵＲＩ（ｔｒａｎｓｆｏｒｍａｔｉｏｎＵＲＩ）と、ロケーションＵＲＩ（ｌｏｃａｔｉｏｎＵＲＩ）とを含むことができる。変換ＵＲＩは、レジストリ内部の変換マップを一意的に特定する。ロケーションＵＲＩは、変換がどこで行われるべきかを示す任意の識別子である。例えば、ネットワーク内部の１つのホストのみが変換を実施することができる場合には、そのホストのＵＲＩはロケーションＵＲＩ属性に割り当てられ、変換／ルータは、実施されるこのホストに変換を送信することになる。変換コンポーネント８２５の属性は、変換コンポーネントＵＲＩ（ｔｒａｎｓｆｏｒｍａｔｉｏｎＣｏｍｐｏｎｅｎｔＵＲＩ）と、名前（ｎａｍｅ）と、記述（ｄｅｓｃｒｉｐｔｉｏｎ）と、コンポーネント型（ｃｏｍｐｏｎｅｎｔＴｙｐｅ）と、実装ファイル（ｉｍｐｌｅｍｅｎｔａｔｉｏｎＦｉｌｅ）と、パッケージ名（ｐａｃｋａｇｅＮａｍｅ）と、実行順（ｅｘｅｃｕｔｉｏｎＯｒｄｅｒ）とを含むことができる。変換コンポーネント８２５は、セットとして文書ＩＤ規約８１３にリンクされる。実行順属性は、２つ以上の変換が必要な場合に、変換が適用されるシーケンスを確認する。この実施形態においては、変換論理は、ＸＳＬＴマップ、ＸＳＴマップ、Ｊａｖａ（登録商標）コンポーネント、又はＣｏｎｔｉｖｏマップの１つ又はそれ以上を含むことができる。変換コンポーネントは、設定要素（Ｃｏｎｆｉｇｕｒａｔｉｏｎ）８２６のセットにリンクされる。設定要素の属性は、名前（ｎａｍｅ）と、値（ｖａｌｕｅ）とを含むことができる。文書ＩＤ規約８１３は、マップ文脈（ＭａｐＣｏｎｔｅｘｔ）文字列８１４のセットにもリンクされる。図６及び図７との関連で上述されたように、これらの文字列は、文書ＩＤ規約８１３を、送信／ソース・パーティか受信／ターゲットパーティかのいずれかの特定の取引パーティ、又は特定のサービス若しくはアクションと関係付ける。

変換を取得し、実行するための論理は、図９に示されるように、ＸＭＬ変換モジュール（ＸＴＭ）を介してアクセスできることが都合がよい。ＸＴＭモジュールは、ローカル遠隔レジストリから変換論理を供給するレジストリ・サービス９０５によってサポートされる。レジストリ・クライアント・アプリケーション・プログラム・インターフェース９０４は、変換がローカル・キャッシュ若しくはレジストリ９０６又は遠隔レジストリから取得されるかどうかに関して、透明性を保持する。取得された変換又は変換参照は、本実施形態では様々な変換型９０８についてのリソースを含む文書変換アプリケーション・プログラム・インターフェース９０７に渡すことができる。代替的な実施形態の場合には、レジストリ・クライアントＡＰＩ９０４は、文書変換サービスとも呼ばれる文書変換ＡＰＩ９０７から呼び出すことができる。文書変換サービス９０７は、サービスのホーム・コミュニティ内に、又は、文書をホーム・コミュニティに送信しているコミュニティなどの遠隔コミュニティから、ＸＴＭモジュール９０２によって呼び出すことができる。変換サービスに対する更新は、新しい型の変換９０８及び新しいバージョンの変換エンジン９０７の追加を伴う。ＸＴＭモジュールと文書変換ＡＰＩとの間のコネクタは、文書変換ＡＰＩ９０７及びコンポーネント変換９０８の更新後に、段階的に更新することができる。文書変換サービスは、ホーム・コミュニティとは異なるコミュニティから呼び出されることがある。例えば、購入注文をコミュニティＡからコミュニティＢに送信するサービスは、コミュニティＢにあるサービスを呼び出すことができる。コミュニティＡの意味を用いて準備されたＰＯがコミュニティＢに受け入れられるように求められる変換を行うためには、コミュニティＢの変換エンジン上でのみ作動する変換を呼び出すことが必要な場合がある。この場合には、コミュニティＡのＸＴＭモジュールは、コミュニティＢの文書変換ＡＰＩを呼び出して１つ又はそれ以上の変換を遠隔的に実行し、購入注文をコミュニティＡの意味からコミュニティＢの意味に変換することになる。

変換は、変換を達成するためにどの変換を適用すべきかの詳細を含むことはできるが、それを含まないことが好ましい着信メッセージ９０１で特定することができる。図１０においては、いわゆる相互運用性契約文書（ＩＣＤ）１０１１が、変換されることになるメッセージと同一のエンベロープ９０１で、ＸＴＭ１００１に送信される。ＩＣＤは、文書をソースからターゲットに運ぶ経路に沿った変換命令及びコネクタのパスを含むことができる。一実施形態においては、ＸＴＭモジュールは、コミュニティが１つ又はそれ以上の通信ネットワークに属することができるＢ２Ｂアプリケーションのコミュニティにおけるコネクタ・コンポーネントと関係付けられる。ＸＴＭモジュールは、ＩＣＤにアクセスすることができ、ＩＣＤが含む変換命令が、何らかの変換を行うときにコネクタを特定するかどうかを判断する。現在のコネクタ又はそのＸＴＭモジュールによって行われることになる変換が存在しない場合には、ＸＴＭモジュールは、成功を戻すか、又は、状況に応じてパススルー・イベントを記録することができる。変換が現在のＸＴＭモジュールによって行われることになる場合には、ＸＴＭモジュールは、変換命令を解析し、レジストリ・クライアントＡＰＩ１００２から実行される変換のシーケンスを得る１００２、１００３。ＸＴＭは、エンベロープ９０１からソース文書を取り出す。ＸＴＭは、行われることになる第１の変換とソース文書の属性とを照合し、不一致が存在する場合にはエラーを表示する。ＸＴＭは、取得され、行われることになる変換のリストと共に、文書変換ＡＰＩ１０３を呼び出す１０１４。変換処理の間にエラーが発生した場合には、そのエラーを通知するか、又は、変換を中止して、エラーメッセージを戻すことができる。ＸＴＭモジュール１００１は、機密保護、否認防止、デバッグ、又は他の目的（図示せず）のために、ソース文書及び変換済みターゲット文書をアーカイブに入れることができる。ＸＴＭモジュールは、ターゲットが、変換済みターゲット文書だけでなく、送信されたソース文書を持つことを望むどうかを判断し、そのように望む場合には、発信するエンベロープ９０３を生成するとき１０１６に該ソース文書を添付する。ＸＴＭモジュールは、スレッドセーフな方法で実装されるべきである。変換済みエンベロープ９０３は、返信される１０１７。

ＩＣＤは、変換されることになるメッセージと同一のエンベロープ９０１に含まれ、必要な変換を特定するために、以下のスキーマを用いることができる。

上のスキーマに従って、変換命令の一例は、

である。この例においては、ソース文書型は、ＳｔａｒｔＤｏｃＴｙｐｅＮａｍｅ及びＳｔａｒｔＤｏｃＶｅｒｓｉｏｎによって特定される。ＳｔａｒｔＤｏｃＴｙｐｅＮａｍｅは、文書型についてルート要素の名前空間及びローカル名を含む完全修飾文書型、すなわちＸＭＬ用語におけるＱＮａｍｅとするべきである。代替的に、関連範囲内で独自性を課す適切な管理規定を持つ固有の命名規則を用いることができる。バージョン識別子は、同一の文書のバリエーションを区別するように与えられるべきである。例えば、顧客は、購入注文内のアドレス要素を拡張することができ、この拡張は、メジャー・バージョンではなく異なるマイナー・バージョンＩＤを持つことになる。ＥｎｄＤｏｃＴｙｐｅＮａｍｅ及びＥｎｄＤｏｃＶｅｒｓｉｏｎは、変換によって生じるターゲット文書を特定する。ＣｏｍｍｕｎｉｔｙＩＤは、変換が登録されるコミュニティを指定する。ＣｏｍｐｏｎｅｎｔＩＤは、例えば変換コンポーネント８２５を介して変換論理を検索するのに用いられる。

変換済みターゲット文書に加えて元のソース文書を受信する（又は受信しない）ようにユーザの選択を指定するＩＣＤの一実施形態は、以下のスキーマの抜粋に示される。

添付タグは、元のソース文書が添付されるべきか否かを示す。この要素がない場合には、デフォルトは、文書を添付するか、添付しないかのいずれかとすることができる。

図１１は、文書をソースの意味からターゲットの意味に変換するための変換の連鎖を示す。この図においては、文書の状態はブロックで示され、状態間の変換は、実線又は点線で示される。実線及び点線は、代替的な変換を示す。これらの変換は、公開変換及び非公開変換とするか、又は、一般に適用される変換及び特別に選択された変換とすることができる。第１の例においては、ソース１１０１は、購入注文をターゲット１１０４に送信することを望む。ソースの文書規格すなわちネイティブ・インターフェースは、ＩＤＯＣである。ＩＤＯＣ意味内のこの購入注文についての文書名及びバージョンは、ＯＲＤＥＲＳ２である。スキーマ型は、ＸＳＤである。ターゲットのネイティブ・インターフェースは、ＯＡＧである。文書名は、ＰｕｒｃｈａｓｅＯｒｄｅｒである。この購入注文についてのバージョンは、７．２．１である。スキーマ型は、ＸＳＤである。この例においては、ソースすなわち送信者レジストリ１１３１及びターゲットすなわち受信者レジストリ１１３２の両方からの変換が用いられる。一連の変換は、１１４１をたどる。ソース文書は、ソース・レジストリ１１３１の変換１１０１−１１０２及び１１０２−１１１２のターゲットとなる。これらの変換は、ＯＲＤＥＲＳ０２文書をｘＣＢＬバージョン４．０Ｏｒｄｅｒ文書に変換される。次に、ターゲット・レジストリ１１３２の２つの付加的な変換１１０３−１１１３及び１１１３−１１０４が適用される。このように、４つの変換の適用により、ＩＤＯＣインターフェース文書は、ＯＡＧインターフェース文書に変換される。この例では、中間の共通意味ベースは、ｘＣＢＬである。図１１の精査によって、ＩＤＯＣインターフェース文書を変換するために、送信者レジストリ１１３１の３つの変換と、受信者レジストリ１１３２の１つの変換とを代替的に用いることができたことが明らかとなる。代替的なパスが、送信者レジストリ１１３１の変換１１１２−１１２２を用いて、ｘＣＢＬバージョン４．０からバージョン３．５に変換することができたであろう。その場合、同様の機能を持つ受信者レジストリ１１３２の変換１１０３−１１１３は、用いる必要がないことになる。この変換についてのパス１１４１の選択は、受信者レジストリの１１０３と１１１３との間の点線によって説明することができる。このことは、バージョン４．０と３．５との間の変換について、ターゲットが自分自身の変換を用いることを選択したことを意味する。第２の例においては、ソース１１２１は、ＸＹＺＯｒｄｅｒをターゲット１１２４に送信することを望む。変換１１２１−１１２２、１１１３−１１２３、及び１１２３−１１２４が用いられる１１４２。同様に、変換についての意味ベースは、ｘＣＢＬである。カスタム変換を用いて、マークアップ・フラット・ファイルをｘＣＢＬバージョン３．５に変換する。その後、非カスタム変換を用いて、文書をＸ１２マークアップ・フォーマットに変換する。これらの変換は、ソース・レジストリとターゲット・レジストリとの両方に格納された変換を示すが、カスタム論理コンポーネントを持つソース及びターゲットのための単一の共通レジストリ、又は共通レジストリ及び補助レジストリといった、他の構成のレジストリも等しく用いることができる。

変換のソース・レジストリとターゲット・レジストリとを共に用いる変換シーケンスの計算に関するさらなる詳細が、図１２及び図１３のフローチャートで与えられる。図１２は、全体のフローチャートである。図１３は、文書ファミリー・メンバーの１つ又はそれ以上のレジストリを通るパスを追跡するのに用いることができる多くのアルゴリズムの１つを示す。図１２は、ソース文書並びにソース及びターゲットの特定に関する情報で始まる１２０１。ソース文書は、文書型属性セットによって記述される。ソース及びターゲットは、パーティとサービスとアクションの３つ１組で記述される。最初の論理分岐１２０２は、変換に対するポリシーが設定されたかどうかを判断する。この種のポリシーは、ターゲットが、誤った変換のすべてのリスクをソースに負わせたいため、公開変換要素の使用はソース自身の責任である場合に、適用することがある。変換に対するポリシーが存在する場合には、変換命令メッセージは戻されない１２１１。論理分岐１２０２を通過すると、ターゲットの文書型が取得される１２０３。上述のように、これはレジストリから取得される。ソース文書及びターゲット文書に関する情報が与えられると、パスについての変換成功スコアを含むことができ、ソース及びターゲットの変換選好も含むことができる選択的な変換シーケンスすなわちパスが決定される１２０４。選択的なパスのリストが調査され、所望のターゲット文書型を生成する候補パスが特定される１２０５。所望のターゲット文書型を生成するパスがリストに現れない場合には、変換命令メッセージは戻されない１２１１。論理分岐１２０６を通過すると、好ましいパスが選択され、取り出される１２０７。好ましいパスは、好ましい変換成功スコアを有するか、又は、ソース、ターゲット、若しくはその両方の選択選好に適合することになる。変換命令が生成され１２０８、戻される１２０９。

図１３は、特定の文書ファミリー・メンバーから始まって、ソース・レジストリ及びターゲット・レジストリを通る変換シーケンス・パスを追跡するステップを示す。概観すると、アルゴリズムは、ソース及びターゲットの文書ファミリーにおける同一の文書型の共通部分について、ソース・レジストリ及びターゲット・レジストリにクエリを行う。アルゴリズムは、図には示されない完全性及びエラーのチェックを行う。マルチパート・メッセージの各々のパートについて、アルゴリズムは、ターゲット文書を決定し、文書状態ノード間の変換リンクをたどりながら文書ファミリー・グラフを再帰的に巡回するコスト・アルゴリズムを実行する。あるノードの文書型が、以前に決定された同一の文書型の共通部分の中にある場合には、アルゴリズムは、両方のレジストリを通るパスに分かれる。損失のない変換（完全な変換成功スコア）を要求する変換ポリシーが適用される場合には、損失のある変換パスは無視される。この横断及びコスト計算は、すべての重みが負ではない辺重み付きグラフ上で単一ソースの最短経路問題を解決するためのＤｉｊｋｓｔｒａアルゴリズムの変形である。このアルゴリズムは、ある開始ノードから１つずつ他のすべてのノードへの最短経路を発見する。Ｄｉｊｋｓｔｒａアルゴリズムにおいては、重み付けされた長さの順に、最短のものから始まり最長のものへ向かって経路を巡回する。一般には、ソース文書からターゲット文書までの適用可能な文書ファミリーのあらゆる巡回を用いることができ、文書ファミリーは、用いられる特定の巡回が計算コストになるべく影響を与えないように小さなものとすることができる。

図１３のフローチャートを参照すると、アルゴリズムのこの部分は、開始ノードすなわち文書ファミリー・メンバーと、ソース及びターゲットを特定するパーティ／サービス／アクションの３つ１組とから始まる１２０４。ステップ１３０１で、ソース・レジストリとターゲット・レジストリとの間のノードの共通部分が計算される。例えば、ソース及びターゲットは共に、ｘＣＢＬバージョン３．０文書又はｘＣＢＬバージョン３．５文書を処理するか、などである。ソース及びターゲットによって処理される文書の意味間に共通部分がない場合には、変換シーケンスは利用できない。図１１を参照すると、共通部分は、ｘＣＢＬバージョン４．０及び３．５（１１１２から１１０３、及び、１１２２から１１１３）であろう。この処理アルゴリズムによって、ソース・ノード、処理ノード、及び変換シーケンスのリストが保持される。これらのリストの幾つか又はすべては、再帰的に割り当てられ、処理される変数のスタック又はヒープに保持することができる。図５を参照すると、ボックス（例えば５０１、５０２、又は５０３）は、有向グラフの探索が進行し始めるソース・ノードである。ソース・ノードは、探索の進行に応じて、ラベル付けされる場合もされない場合もある。探索は、ソース・ノードのリストに開始ノードを追加することによって始まる。リストは、１３０３及び１３０５によって囲まれるループ、並びに、１３１１及び１３２４によって囲まれる内部ループで処理される。１３０３において、ソース・ノード・リスト内のいわゆるｉノードの処理が始まる。現在のｉノードが、ラベル付けされる。次いで、文書ファミリーの、まだレベル付けされていない接続メンバーが考慮される１３１１。例えば、図５を参照すると、ｉノード５０１Ｂについて、文書ファミリー・メンバーの接続ノードは、５０１Ａ、５０１Ｃ、５０１Ｆ、及び５０２Ｃであろう。ラベル付けされない接続ノードは、ｙノードと呼ばれる１３１１。ｙノードは、処理ノード・リストにあるかどうかを判断するためにテストされ１３１２、ない場合には、リストに追加され１３２１、処理される１３１３。ｙノードが処理ノード・リストにある場合には、アルゴリズムは、ｙノードへの現在の経路が以前計算された経路より望ましいかどうかを判断する。ステップ１３１３において、現在のｙノード到達するコストが、同じノードに到達する先のコストと比較される。現在のコストが古いコストより優れている場合には、処理はステップ１３１４に進み、そこで、処理ノード・リストは更新される。ステップ１３１５で、ｙノードは、後の処理のために、ソース・ノード・リストに追加される。ステップ１３１３に戻ると、現在のコストが優れていない場合には、処理は１３２２に進み、そこでコストが同じかどうかテストされる。コストが同じ場合には、種々の基準を用いて、均衡を破る１３２３。１つの基準は、同じノードが受信者レジストリ及び送信者レジストリの両方に現れたときは、受信者レジストリにあるｙノードのインスタンスを有利にすることである。別の基準は、送信者レジストリにあるｙノードのインスタンスを有利にすることであろう。さらに別の基準は、最少のノード又はホップを含む経路を有利にすることであろう。ステップ１３２４で、処理は１３１１に戻り、そこで、ラベル付けされていない次の接続ノードが処理される。ラベル付けされていない接続ノードがすべて処理された場合には、次のステップは１３０５であり、そこで処理は、ソース・ノードの次のｉノードが処理される１３０３に戻る。すべてのソース・ノードが処理されたとき１３０５は、この処理の結果が戻される１３０６。

代替的な変換シーケンス及び好ましい変換シーケンスの計算は、異なる環境で作動することができる。以下の使用事例は、これらの環境の幾つかを示す。第１の使用事例では、変換が必要とされない。変換シーケンスを判断するためのモジュールは呼び出されるが、ソース文書とターゲット文書は同じ型である。変換は必要とされない。第２の使用事例では、ソースとターゲットとの間で変換が利用不可能である。これは、異なるソース文書とターゲット文書との間で変換シーケンスが計算できない場合か、変換ポリシーが「非変換」であり、ソース文書とターゲット文書とが異なる場合か、又は、損失のない変換のみが許容されるが、計算されたすべての変換シーケンスは、その変換成功スコアによって示したときに損失がある場合である。作動例外が発生する。第３の使用事例では、ソース及びターゲットが同一のコミュニティにあり、したがって、１つの変換レジストリのみが必要であり、妥当な経路が存在する。１つ又はそれ以上の変換シーケンスが決定される。好ましいシーケンスが決定される。第４の使用事例では、ソース及びターゲットが別々のコミュニティにあり、妥当な経路が存在する。２つの変換レジストリが必要である。第３の事例のように、１つ又はそれ以上の変換シーケンスが決定され、好ましいシーケンスが決定される。

上述のように、変換成功スコアは、経験によって若しくは動的に、アプリオリに、又は、より一般的には損失のある意味変換の何らかのメトリックによって、決定することができる。アプリオリなスコアは、分析及びテストのいくつかの組み合わせに基づいて、変換に割り当てられる。スコアは、経験と共には変化しない。経験ベースのスコアは、アプリオリなスコア又はデフォルト・スコアから始まり、経験とともに調整することができる。例えば、以下に説明されるような成功を動的に計算する方法は、用いられる選択済み変換に適用することができ、対応する変換成功スコアは、それまでの最も古い成功スコアを廃棄するか、又は、相対的な重みを過去及び現在の成功スコアに与えて、例えば重み付け平均又は移動平均として更新される。成功スコアを動的に決定する１つのアプローチは、変換を候補文書に適用し、変換された文書を分析することである。変換は、ソース文書又は中間のソース文書に適用され、ターゲット文書又は中間のターゲット文書を生成する。ソース文書及びターゲット文書について、（ＸＭＬ文書又は同様の文書の）要素の内容が、例えば度数分布表に記載される。ソースの度数とターゲットの度数との間の相違は、差が正であるか負であるかにかかわらず、変換成功スコアを減少させる。この相違は、場合によっては報告される。成功スコアは、要素内容間の正確な一致によって決まるか、又は、程度によって重み付けすることができる。以下の例は、この動的な採点方法を説明するのに役立つ。ソース文書のフラグメントは、

である。
変換されたターゲット文書のフラグメントは、

である。

ソース文書のフラグメントの要素に基づく、正確な一致の手掛かりである度数比較は、

となる。

ソース文書のフィールドのうちターゲット文書のフィールドとして逐語的に出現するフィールドの割合に対応する動的変換成功スコアは、７５パーセントの成功として表現することができるか、又は、２５パーセントのコストをこの例に割り当てることができる。ターゲット文書のｈｏｕｓｅ ｎｕｍｂｅｒ要素が、ソース文書のａｄｄｒｅｓｓ１要素の１つのトークンと一致するというような一部一致を数えた場合には、異なるスコアが割り当てられることになる。成功スコアは、ソース文書のフィールドにおけるテキストのうち、ターゲット文書のフィールドに逐語的に出現するテキストの割合に対応するものとする場合もある。一連のスコアの適用は、幾つかの目的で、総成功スコアの計算を必要とする。個々のスコアを組み合わせて総変換成功スコアにするときは、組み合わせ方法は、加法、平均、又は乗法とすることができる。総変換成功を構築する方法は、成功スコアを乗法的に組み合わせる場合には成功スコアシーケンスにおける変換数を考慮に入れることができ、又は、コストを加法的に組み合わせる場合には、エラーを累積する。例えば、乗法的組み合わせにおいて、変換がＴ１、Ｔ２、及びＴ３である場合には、損失割合は、３つの各々について計算され、（１−Ｔ１）＊（１−Ｔ２）＊（１−Ｔ３）として組み合わせることができる。より一般的には、総変換成功スコアは、ソース文書からターゲット文書への損失のある変換に起因する、変換のシーケンスの何らかのメトリックとすることができる。

文書ファミリー情報を管理し、変換を検索するためのユーザ・インターフェースが、図１４及び図１５に示される。図１４は、文書ファミリーの管理に対応するユーザ・インターフェースを示す。文書ツリー１４０１は、文書１４０２のメジャー・バージョン１４０３及びマイナー・バージョン１４０４の階層的な相互関係を示す。ファミリーについて、ファミリー・メンバーに共通する文書ファミリー情報は、１４１１に表示される。図１５は、例えば新しい変換シーケンスを用意するというように、利用可能な変換を見つける検索に対応するユーザ・インターフェースを示す。表示された結果１５１１は、ソース文書（ＰｕｒｃｈａｓｅＯｒｄｅｒ、ＣＢＬ、ＳＯＸ、Ｙ、２００）をｘＣＢＬバージョン２．０からバージョン３．０に変換する２３の変換シーケンスの一部を特定する。検索基準は、標準的なクエリ・インターフェース１５０１又は高度なクエリ・インターフェース１５０２を用いて指定される。結果の１つ又はそれ以上の列は、削除する１５１２か、又は、新しい変換を生成するのに用いる１５１３ことができる。この例では、戻された変換シーケンスは、送信パーティ１５１４又は受信パーティ１５１５の表示された選好と、変換のコスト又は損失性１５１６と、変換シーケンスを実装する論理コンポーネント１５１７とによって変化する。

本発明は、上述の好ましい実施形態及び例を参照して開示されるが、これらの例は、限定的な意味ではなく、例示的なものであることを意図していることが理解される。記載された実施形態には、コンピュータ支援処理がかかわっている。したがって、本発明は、コンピュータ支援処理のための方法、変換処理を行う論理を含むシステム、変換処理を行う論理を与えた媒体、変換処理を行う論理を与えたデータ・ストリーム、又は、コンピュータがアクセス可能な変換処理サービスで具体化することができる。当業者であれば、本発明の精神及び添付の特許請求の範囲内の改良及び組み合わせを容易に発想するであろうと考えられる。

２地点間接続を用いる先行技術の変換処理の概略ブロック図である。 ウェブ・サービス・エンジンを用いる変換処理の概略ブロック図である。 文書ファミリー及びバージョンの階層ブロック図である。 文書ライブラリ、名前空間、スキーマ、及び文書ファミリーのブロック図である。 文書ファミリー・メンバー、及び、メンバー間の変換のネットワーク図である。 変換シーケンス、及び、変換シーケンスを行うのに用いられる論理コンポーネントについてのテーブルである。 変換シーケンス、及び、変換シーケンスを行うのに用いられる論理コンポーネントについてのテーブルである。 文書ライブラリ、名前空間、文書型及びスキーマ、文書ファミリー、並びに変換を含むクラス図である。 変換を行うソフトウェア・コンポーネントの概略ブロック図である。 図９に対応するアクティビティ図である。 変換のシーケンスを示す。 ソース文書からターゲット文書に変換する変換の好ましいシーケンスを決定するフローチャートの表現形態である。 ソース文書からターゲット文書に変換する変換の好ましいシーケンスを決定するフローチャートの表現形態である。 文書ファミリーの管理と変換を探すための検索とを支援するユーザ・インターフェースを示す。 文書ファミリーの管理と変換を探すための検索とを支援するユーザ・インターフェースを示す。

Claims (28)

1. ソースの意味バージョンを用いてコード化され、且つターゲットに宛てられた文書の意味を変換するコンピュータ支援方法であって、
   ターゲットによって用いられる少なくとも１つのターゲットの意味バージョンを、ターゲットによって用いられる意味バージョンを含むインターフェース・レジストリから決定し、
   ソース意味バージョンから前記ターゲットの意味バージョンに文書を変える１つ又はそれ以上の変換を、文書ファミリー・メンバーによって用いられる意味バージョンと、前記意味バージョン間で利用可能な変換とを含む文書ファミリー・レジストリから特定し、
   前記変換を適用して前記文書を変換する、
   ステップを含むことを特徴とする方法。
2. 前記文書ファミリー・レジストリが、前記ソース及び前記ターゲットへアクセス可能であるが、該ソース及び該ターゲットとは別個のものであることを特徴とする、請求項１に記載の方法。
3. 前記文書ファミリー・レジストリが共有されることを特徴とする、請求項２に記載の方法。
4. 前記文書を受信し、且つ変換済み文書を出力するステップをさらに含むことを特徴とする、請求項１に記載の方法。
5. 意味バージョンが、システム規格によって区別されるメジャー・バージョンと、特定のシステム規格内でリリース・バージョンによって区別されるマイナー・バージョンとを含むことを特徴とする、請求項１に記載の方法。
6. 前記文書ファミリー・レジストリが、文書ファミリー・メンバーのために、システム規格の識別情報と、文書識別子と、リリース・バージョンと、スキーマ型とを含むことを特徴とする、請求項１に記載の方法。
7. 前記変換が、Ｃｏｎｔｉｖｏマップ、ＸＳＬＴマップ、ＸＳＴマップ、ＸＳＤ−ＳＯＸクラス、及びＪａｖａマップのうちの１つ又はそれ以上を含むことを特徴とする、請求項１に記載の方法。
8. 前記文書ファミリー・レジストリによって支持される変換が、Ｃｏｎｔｉｖｏマップと、ＸＳＬＴマップと、Ｊａｖａマップとを含むことを特徴とする、請求項１に記載の方法。
9. 前記変換を適用する前記ステップが、前記文書ファミリー・レジストリの処理リソースではなく、前記ソースの処理リソースを用いるステップを含むことを特徴とする、請求項１に記載の方法。
10. 前記変換を適用する前記ステップが、変換の共有リポジトリから該変換を回復するステップをさらに含むことを特徴とする、請求項９に記載の方法。
11. 前記変換が、共有リポジトリからローカル・リポジトリに回復されることを特徴とする、請求項１０に記載の方法。
12. 前記ローカル・リポジトリにおける前記変換は、最新性に関して適用前に確認されることを特徴とする、請求項１１に記載の方法。
13. 追加ソース及び追加ターゲットの意味バージョンに応じて、前記追加ソース及び前記追加ターゲットのための前記変換が再使用可能であることを特徴とする、請求項１に記載の方法。
14. 前記変換を適用するステップは、ソースの意味情報の変換が疑わしいときに、前記文書からの前記ソースの意味情報を前記変換済み文書のユーザ可視フィールドに保存するステップを含むことを特徴とする、請求項１に記載の方法。
15. 変換成功スコアに基づいて代替的な変換の中から選択するステップをさらに含むことを特徴とする、請求項１に記載の方法。
16. 前記文書ファミリー・レジストリは、複数の物理装置にわたって分散させられることを特徴とする、請求項１に記載の方法。
17. 文書ファミリーに適用できる意味変換を公開するコンピュータ支援方法であって、
    （１）特定の文書ファミリーについて、
    (a)ライブラリによって特定される文書ファミリー・メンバー、文書識別子、リリース・バージョン、及び、スキーマ型と、
    (b)文書ファミリー・メンバー間の意味変換であって、前記意味変換を実装するために遠隔的に実行される論理を含む意味変換と、
    (c)前記意味変換とソース及びターゲットの文書ファミリー・メンバーとの関係付けと、
    を含む文書ファミリー・レジストリ・データ構造を保持し、
    （２）遠隔的に実行されることになる前記論理を提供することによって、前記意味変換についての要求に応答する、
    ステップを含むことを特徴とする方法。
18. 文書ファミリー・メンバー間の前記意味変換の関係付けを探索（トラバース）し、ソースの文書ファミリー・メンバーからターゲットの文書ファミリー・メンバーへの１以上の変換における１以上のシーケンスを特定するステップをさらに含むことを特徴とする、請求項１７に記載の方法。
19. 前記意味変換を保持する前記ステップが、変換成功スコアを保持するステップをさらに含み、
    前記要求に応答する前記ステップが、変換の前記シーケンスについて、複合変換成功スコアを計算するステップをさらに含む、
    ことを特徴とする、請求項１８に記載の方法。
20. 前記変換成功スコアが、前記ソース文書のフィールドから前記ターゲット文書のフィールドに逐語的に翻訳されたフィールドの割合に対応することを特徴とする、請求項１９に記載の方法。
21. 前記変換成功スコアが、前記ソース文書のフィールドにおけるテキストのうち、前記ターゲット文書のフィールドに逐語的に見出されたテキストの割合に対応することを特徴とする、請求項１９に記載の方法。
22. 前記文書ファミリー・レジストリ・データ構造を保持する前記ステップが、文書交換における１以上の参加者に対応して適用されることになる変換についての特別な規則を保持するステップをさらに含み、
    遠隔的に実行されることになる前記論理を提供することによって応答する前記ステップが、前記文書ファミリー・レジストリ・データ構造とは別に非公開に保持された変換を参照して達成される、
    ことを特徴とする、請求項１７に記載の方法。
23. 文書ファミリーに適用可能な意味変換を選択するコンピュータ支援方法であって、
    （１）特定の文書ファミリーについて、
    (a)ライブラリによって特定される文書ファミリー・メンバー、文書識別子、リリース・バージョン、及び、スキーマ型と、
    (b)文書ファミリー・メンバー間の意味変換であって、前記意味変換を実装するために遠隔的に実行される論理を含む意味変換と、
    (c)前記意味変換とソース及びターゲットの文書ファミリー・メンバーとの関係付けと、
    を含む文書ファミリー・レジストリ・データ構造を保持し、
    （２）前記文書ファミリー・レジストリ・データ構造を有向グラフとして探索（トラバース）し、且つ前記探索によって決定される変換の１つ又はそれ以上のシーケンスを出力する、
    ことにより、文書をソースの意味バージョンからターゲットの意味バージョンに変換する変換についての要求に応答する、
    ステップを含むことを特徴とする方法。
24. 前記意味変換を保持する前記ステップが、変換成功スコアを保持するステップをさらに含み、
    前記文書ファミリー・レジストリ・データ構造を探索（トラバース）する前記ステップが、変換の前記シーケンスについて複合変換成功スコアを計算するステップをさらに含む、ことを特徴とする、請求項２３に記載の方法。
25. 前記変換成功スコアが、前記ソース文書のフィールドから前記ターゲット文書のフィールドに逐語的に翻訳されたフィールドの割合に対応することを特徴とする、請求項２４に記載の方法。
26. 前記変換成功スコアが、前記ソース文書のフィールドにおけるテキストのうち、前記ターゲット文書のフィールドに逐語的に見出されたテキストの割合に対応することを特徴とする、請求項２４に記載の方法。
27. 前記文書ファミリー・レジストリ・データ構造を保持する前記ステップが、文書交換における１つ又はそれ以上の参加者に対応して適用されることになる変換についての特別な規則を保持するステップをさらに含み、
    前記出力するステップが、前記文書ファミリー・レジストリ・データ構造とは別に非公開に保持された変換を参照するステップをさらに含む、
    ことを特徴とする、請求項２３に記載の方法。
28. 前記文書ファミリー・レジストリ・データ構造を保持する前記ステップが、文書交換における１つ又はそれ以上の参加者に対応して適用されることになる変換についての特別な規則を保持するステップをさらに含み、
    前記出力するステップが、前記文書ファミリー・レジストリ・データ構造内に安全に保持された非公開変換を参照するステップをさらに含む、
    ことを特徴とする、請求項２３に記載の方法。

Images