(57)【要約】  １つまたは複数のデータストアが、保存、関連付けのため、および複数のデータコンシューマの間でコンピュータ生成ドキュメントに関連付けられた恣意的データの使用を可能にするため、ドキュメント内の１次提示ストレージから切り離されて維持される。データストアは、異なるデータコンシューマがリアルタイムに１つまたは複数のデータ部分にアクセスし、それに作用を及ぼすことを可能にするため、データストア内のデータの様々な部分へのアプリケーションプログラミングインタフェース（ＡＰＩ）を提示する。複数のデータコンシューマは、同時にデータの同じ部分にアクセスし、それを編集することができ、データの与えられた部分に対するどのような競合的変更も解決される。各データコンシューマは、変更を受け入れること、または拒否することができるばかりでなく、オリジナル変更の結果としての付加的なサイドエフェクト変更を行うこともできる。このようにして、データは、データコンシューマ間でリアルタイムに同期が取ることができる。
2009508231.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ生成ドキュメントに関連付けられ、データコンシューマ間で共有されるデータを同期させるためのコンピュータ実行可能命令を有する、コンピュータ可読媒体であって、
ドキュメントに関連付けられた構造化データ項目をデータストア内に保存するステップであって、前記データストアは、前記ドキュメントから切り離されているステップと、
前記データストア内の構造化データ項目に対する変更を第１のデータコンシューマによって開始するステップと、
前記構造化データ項目に対する前記変更に関心がある他のデータコンシューマが存在する場合、そのことを判定するステップと、
前記他のデータコンシューマに前記変更を通知するステップであって、前記他のデータコンシューマは、前記変更を受け入れること、前記変更を拒否すること、前記オリジナル変更の結果としてサイドエフェクト変更を開始すること、のうちの少なくとも１つを実行することができるステップと、
前記変更が受け入れられた場合、前記データストアに前記変更をコミットし、前記変更が拒否された場合、前記変更が開始された時点の前の状態まで前記データストアをロールバックするステップとを含むことを特徴とするコンピュータ可読媒体。
【請求項２】
拡張可能マークアップ言語（ＸＭＬ）仕様に従って前記データストア内の前記構造化データ項目を構造化するステップをさらに含むことを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項３】
前記構造化データ項目へのプログラム的アクセスを可能にするアプリケーションプログラミングインタフェース（ＡＰＩ）を前記データコンシューマに提示するステップをさらに含み、前記ＡＰＩは、前記ドキュメントが開かれている間、前記データストア内の前記構造化データ項目にアクセスする機能を提供し、前記ＡＰＩは、２つ以上のデータコンシューマが、同じ構造化データ項目に同時にアクセスすることを可能にし、前記ＡＰＩは、前記構造化データ項目の１つまたは複数を含む通知のために登録する機能を前記データコンシューマ提供することを特徴とする請求項２に記載のコンピュータ可読媒体。
【請求項４】
前記他のデータコンシューマの１つに関連付けられた表示を、前記第１のデータコンシューマによって変更された前記構造化データ項目の値を用いて更新するステップをさらに含むことを特徴とする請求項３に記載のコンピュータ可読媒体。
【請求項５】
前記サイドエフェクト変更は、後の実行のために待ち行列に入れられ、前記後の実行は、前記データコンシューマの各々が、受け入れ、拒否、およびサイドエフェクト変更を行う機会をもった後に起こることを特徴とする請求項４に記載のコンピュータ可読媒体。
【請求項６】
受け入れられた場合に前記変更をコミットするステップは、各サイドエフェクトを処理するステップと、各サイドエフェクトが受け入れられるかどうかを判定するステップとを含むことを特徴とする請求項４に記載のコンピュータ可読媒体。
【請求項７】
前記変更が開始された時点の前の状態まで前記データストアを戻すために使用され得るアンドゥーリストを維持するステップをさらに含むことを特徴とする請求項４に記載のコンピュータ可読媒体。
【請求項８】
コンピュータ生成ドキュメントに関連付けられたデータをデータコンシューマ間で共有するためのコンピュータ実行方法であって、
データストア内に含まれ、ドキュメントに関連付けられた構造化データ項目に対する変更を開始するステップであって、前記構造化データ項目は、拡張可能マークアップ言語（ＸＭＬ）に従って構造化され、前記データストアは、前記ドキュメントから切り離されているステップと、
前記変更の通知を登録データコンシューマに提供するステップと、
前記変更の結果であるサイドエフェクト変更を後の処理のために待ち行列に入れるステップと、
前記登録データコンシューマの１つからの応答が前記変更の拒否である場合に、そのことを判定するステップであって、前記応答が拒否である場合、前記変更と、前記データストア内のすべてのデータコンシューマからのあらゆるサイドエフェクト変更とを、最後に知られた良好な状態までロールバックするステップと、
前記登録データコンシューマの各々が前記変更を受け入れた場合に、そのことを判定するステップであって、前記登録データコンシューマの各々が前記変更を受け入れた場合、ＡＰＩを介して前記データコンシューマの１つによって提供されたＸＭＬスキーマファイルを使用して前記変更の有効性を確認し、前記変更を前記データストアにコミットするステップとを含むことを特徴とするコンピュータ実行方法。
【請求項９】
前記データストア内に含まれる構造化データ項目に対する変更を開始するステップは、前記データストア内の前記構造化データ項目にアクセスする機能を前記データコンシューマに提供するアプリケーションプログラミングインタフェース（ＡＰＩ）を提示するステップを含み、前記ＡＰＩは、２つ以上の前記データコンシューマが、同じ構造化データ項目に同時にアクセスすることを可能にすることを特徴とする請求項８に記載のコンピュータ実行方法。
【請求項１０】
前記通知に応答してサイドエフェクト変更を受け取るステップと、前記変更が処理されるまで、前記データストア内の前記サイドエフェクト変更の実行を遅延させるステップとをさらに含むことを特徴とする請求項９に記載のコンピュータ実行方法。
【請求項１１】
前記データストア内の前記サイドエフェクト変更を待ち行列に入れるステップをさらに含むことを特徴とする請求項１０に記載のコンピュータ実行方法。
【請求項１２】
前記登録データコンシューマの各々が前記変更を受け入れた場合に、そのことを判定するステップは、前記変更が各データコンシューマによって受け入れられた場合と、前記サイドエフェクト変更の各々が受け入れられた場合に、そのことを判定するステップを含むことを特徴とする請求項１０に記載のコンピュータ実行方法。
【請求項１３】
前記最後に知られた良好な状態まで前記データストアを戻すために使用され得るアンドゥーリストを維持するステップをさらに含むことを特徴とする請求項１０に記載のコンピュータ実行方法。
【請求項１４】
コンピュータ生成ドキュメントに関連付けられたデータをデータコンシューマ間で同期させるためのシステムであって、
前記ドキュメントを作成および編集するように構成され、前記ドキュメントに関連付けられた構造化データ項目と対話するように構成された内部データコンシューマと、
前記ドキュメントに関連付けられた構造化データ項目と対話するように構成された外部データコンシューマと、
前記ドキュメントに関連付けられた前記構造化データ項目を保存するように構成された、前記ドキュメントから切り離されているデータストアであって、前記外部データコンシューマおよび前記内部データコンシューマと対話するように構成され、提案された変更を受け取り、前記提案された変更に応答して、登録データコンシューマに前記提案された変更を通知し、前記提案された変更が受け入れられた場合、前記変更を前記データストアにコミットし、前記提案された変更が受け入れられなかった場合、前記データストアが有効な状態にあることを保証するように構成されるＡＰＩブローカを含み、前記提案された変更と、前記提案された変更に関連付けられたサイドエフェクト変更とを保存するように構成される変更ストアと、前記データストアを前記有効な状態にロールバックするように構成されるアンドゥーストアとをさらに含むデータストアとを含むことを特徴とするシステム。
【請求項１５】
拡張可能マークアップ言語（ＸＭＬ）に従って前記データストア内の前記構造化データ項目を構造化するステップをさらに含むことを特徴とする請求項１４に記載のシステム。
【請求項１６】
前記データストアは、前記サイドエフェクト変更を後の実行のために待ち行列に入れるようにさらに構成され、前記後の実行は、各登録データコンシューマが、受け入れ、拒否、およびサイドエフェクト変更を行う機会をもった後に起こるように構成されることを特徴とする請求項１５に記載のシステム。
【請求項１７】
前記データストアは、各サイドエフェクトを処理し、各サイドエフェクトが受け入れられるかどうかを判定するようにさらに構成されることを特徴とする請求項１６に記載のシステム。
【請求項１８】
前記データストアは、
前記構造化データ項目に適用される拡張可能マークアップ言語（ＸＭＬ）マークアップデータに対する変更を受け取り、
前記ＸＭＬマークアップデータに対する前記変更がそれに対して指図される、前記構造化データ項目に関連付けられたＸＭＬスキーマファイルを読み取り、
前記ＸＭＬマークアップデータに対する前記変更が有効かどうかを前記読み取りＸＭＬスキーマファイルに従って判定し、
前記ＸＭＬマークアップデータに対する前記変更が前記読み取りＸＭＬスキーマファイルによれば有効でない場合、前記ＸＭＬマークアップデータに対する前記変更を拒否し、前記ＸＭＬマークアップデータに対する前記変更が前記読み取りＸＭＬスキーマファイルによれば有効である場合、前記変更をコミットするようにさらに構成されることを特徴とする請求項１６に記載のシステム。
【請求項１９】
前記データストアは、各々がアンドゥーストアおよび変更ストアを含む複数のＸＭＬデータストアを含むことを特徴とする請求項１６に記載のシステム。
【請求項２０】
各アンドゥーストアは、その他のアンドゥーストアと通信するように構成されることを特徴とする請求項１９に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のコンピュータユーザ間で文書を共有し、文書に対して変更を加えるためのコンピュータ技術に関する。
【背景技術】
【０００２】
コンピュータユーザは、文章の記述、計算、データの整理、プレセンテーションの準備、電子メールの送受信、および作曲などを支援する、ユーザフレンドリなソフトウェアアプリケーションに慣れ親しむようになった。例えば、文書処理アプリケーションは、ユーザが様々な有用な文書を準備することを可能にする。表計算アプリケーションは、ユーザがデータを入力し、操作し、整理することを可能にする。スライドプレセンテーションアプリケーションは、テキスト、絵、データ、またはその他の有用なオブジェクトを含む様々なスライドプレセンテーションをユーザが作成することを可能にする。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかし、そのようなアプリケーションによって作成されたドキュメント（例えば、文書処理ドキュメント、スプレッドシート、スライドプレセンテーションドキュメント）は、ドキュメントのコンテキストによって要求される恣意的なメタデータの内容を保存／転送することに関して、制限された機能を有するに過ぎない。例えば、文書処理ドキュメントの上に構築されるソリューションは、例えば、以前のワークフロー承認状態（日付、時刻、名前）、現在の承認状態、完了前の将来のワークフロー状態、ドキュメント作成者の名前およびオフィス住所、ドキュメント変更など、ドキュメントの様々な状態を記述するワークフローデータの保存を必要とすることがある。この情報を保存するための選択肢は、主として、ドキュメント変数の使用、または既存のカスタムオブジェクトのリンキングおよびエンベディング（ＯＬＥ）ドキュメントプロパティの使用に限定されるが、制約を有している。例えば、階層データが保存できない、キャラクタ長が制限されるなどである。そのような方法のプロパティは、例えばＯＬＥプロパティストアなど、単一のストアに保存され、それは、プロパティが競合の可能性を有することを意味する。さらに、そのような保存されたプロパティは、データの有効性確認をもたない。そのようなアプリケーションおよび関連ドキュメントのユーザが、ドキュメントと共に恣意的なデータを保存することは難しいが、それは、多くのユーザが共通して必要としていることである。
【課題を解決するための手段】
【０００４】
この「課題を解決するための手段」は、以下の「発明を実施するための最良の形態」でさらに説明される概念の抜粋を簡潔な形で紹介するために提供される。この「課題を解決するための手段」は、特許請求される主題の主要な特徴または必須の特徴を示すことを意図したものではなく、特許請求される主題の範囲を決定する助けとして使用されることを意図したものでもない。
【０００５】
１つまたは複数のデータストア（ｄａｔａ  ｓｔｏｒｅ）が、保存、関連付けのため、および複数のデータコンシューマ（ｄａｔａ  ｃｏｎｓｕｍｅｒ）の間でコンピュータ生成ドキュメントに関連付けられた恣意的データの使用を可能にするため、ドキュメント内の１次提示ストレージ（ｐｒｉｍａｒｙ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｓｔｏｒａｇｅ）から切り離されて維持される。ドキュメントメタデータなど、ドキュメントに関連付けられた情報を構造化するためのデータは、データの異なる部分の間の関係が維持されるデータストア内に維持される。データストアは、異なるデータコンシューマがリアルタイムに１つまたは複数のデータ部分にアクセスし、それに作用を及ぼすことを可能にするため、データストア内のデータの様々な部分へのアプリケーションプログラミングインタフェース（ＡＰＩ）を提示する。複数のデータコンシューマは、同時にデータの同じ部分にアクセスし、それを編集することができ、データの与えられた部分に対するどのような競合的変更も解決される。各データコンシューマは、変更を受け入れること、または拒否することができるばかりでなく、オリジナル変更の結果としての付加的なサイドエフェクト変更（ｓｉｄｅ−ｅｆｆｅｃｔ  ｃｈａｎｇｅ）を行うこともできる。このようにして、データは、データコンシューマ間でリアルタイムに同期が取られることができる。
【０００６】
データの部分は、拡張可能マークアップ言語（ＸＭＬ）などのマークアップ言語によって構造化されることができる。ＸＭＬスキーマは、データの各部分に関連付けられることができ、データストアは、データの与えられた部分に関連付けられたＸＭＬスキーマに基づいて、データのＸＭＬ構造の有効性を自動的に確認することができる。これは、無効な変更がシステムに入力されることを許さないようにするのに役立つ。
【発明を実施するための最良の形態】
【０００７】
ここで図面を参照すると、図面では同様の数字は同様の要素を表しており、本発明の様々な態様が説明される。特に図１および対応する説明は、本発明の実施形態を実施する適切なコンピューティング環境の簡単で全般的な説明を提供することを意図している。
【０００８】
一般に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データ型を実施する、ルーチン、プログラム、コンポーネント、データ構造、およびその他のタイプの構造を含む。ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラム可能消費者家電、ミニコンピュータ、およびメインフレームコンピュータなどを含む、その他のコンピュータシステム構成も使用されることができる。通信ネットワークを介して結合されたリモート処理装置によってタスクが実行される、分散コンピューティング環境も使用されることができる。分散コンピューティング環境では、プログラムモジュールは、ローカルおよびリモート両方のメモリ記憶装置に配置されることができる。
【０００９】
本明細書および特許請求の範囲において、以下の用語は、用語の文脈を別途指示しない限り、本明細書に関連する意味をもつ。
【００１０】
「プレセンテーション」という用語は、ドキュメントが印刷された場合に目に見えるテキストおよびレイアウトなどのドキュメントの可視部分を指す。
【００１１】
「タグ」という用語は、ＸＭＬドキュメント内のエレメントを叙述する、ドキュメントに挿入されるキャラクタを指す。各エレメントは、多くて２つのタグ、すなわち、開始タグと終了タグを有することができる。（内容をもたない）空エレメントをもつことも可能であり、その場合、１つのタグが許される。
【００１２】
「マークアップ言語」または「ＭＬ」という用語は、ドキュメントの部分がアプリケーションによってどのように解釈されるべきかを規定する、ドキュメント内の特別なコードのための言語を指す。文書処理ファイルでは、マークアップ言語は、テキストがどのようにフォーマットまたはレイアウトされるべきかを規定する。
【００１３】
「エレメント」という用語は、ＸＭＬドキュメントの基本単位を指す。エレメントは、ＸＭＬドキュメントのためのアトリビュート、その他のエレメント、テキスト、およびその他の内容領域を含むことができる。
【００１４】
タグの間のＸＭＬ内容は、エレメントの「子供」（または子孫）と見なされる。したがって、エレメントの内容に埋め込まれた他のエレメントは、「子エレメント」または「子ノード」またはエレメントと呼ばれる。エレメントの内容に直接埋め込まれたテキストは、エレメントの「子テキストノード」と見なされる。エレメント内の子エレメントとテキストは、一緒になって、そのエレメントの「内容」を構成する。
【００１５】
「アトリビュート」という用語は、特定の値に設定され、エレメントに関連付けられた、付加的なプロパティを指す。エレメントは、それに関連付けられた、ゼロを含む恣意的な数のアトリビュート設定を有することができる。アトリビュートは、付加的なエレメントを含まない、またはテキストノードとして扱われるエレメントに付加的な情報を関連付けるために使用される。
【００１６】
「ＸＰａｔｈ」という用語は、ＸＭＬドキュメント内のノードを識別するためにパターン表現を使用する操作子である。ＸＰａｔｈパターンは、ＸＭＬドキュメント内のパスを記述する子エレメント名から成るスラッシュで区切られたリストである。パターンは、パスに一致するエレメントを「選択」する。
【００１７】
「サイドエフェクト変更」という用語は、別の変更に応答して行われる変更を指す。
【００１８】
「ドキュメント」という用語は、関連する内容タイプで定義されるプロパティを記述する恣意的なＸＭＬばかりでなく、ドキュメントの実際のサーフィス内容を記述するのに使用され得るその他のマークアップ言語からも成ることができる。
【００１９】
「ＸＭＬデータストアおよび／またはデータストア」という用語は、ファイルが開かれている間、ドキュメント内に保存された（例えばＸＭＬ形式の）データの保存および変更のためのアクセスを提供する、文書処理ドキュメント、表計算ドキュメント、スライドプレセンテーションドキュメントなどのドキュメント内のコンテナを指す。ＸＭＬデータストアのさらなる定義は、以下で図２に関連して提供される。
【００２０】
図１を参照すると、本発明を実施するための１つの例示的なシステムは、コンピューティング装置１００などのコンピューティング装置を含む。非常に基本的な構成では、コンピューティング装置１００は一般に、少なくとも１つの処理ユニット１０２と、システムメモリ１０４とを含む。コンピューティング装置の正確な構成およびタイプに応じて、システムメモリ１０４は、（ＲＡＭなどの）揮発性、（ＲＯＭ、フラッシュメモリなどの）不揮発性、または２つの何らかの組合せとすることができる。システムメモリ１０４は一般に、オペレーティングシステム１０５、１つまたは複数のアプリケーション１０６を含み、プログラムデータ１０７を含むこともできる。一実施形態では、アプリケーション１０６は、文書処理アプリケーション１２０を含むことができる。この基本構成は、図１では、破線１０８の内部の構成要素によって示されている。
【００２１】
コンピューティング装置１００は、付加的な特徴または機能をもつことができる。例えば、コンピューティング装置１００は、磁気ディスク、光ディスク、またはテープなど、付加的な（着脱可能および／または固定式）データ記憶装置を含むこともできる。そのような付加的な記憶装置は、図１では、着脱可能記憶装置１０９および固定式記憶装置１１０によって示されている。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータなどの情報を記憶するための任意の方法または技術で実施された、揮発性および不揮発性、着脱可能および固定式媒体を含むことができる。システムメモリ１０４、着脱可能記憶装置１０９、および固定式記憶装置１１０はすべて、コンピュータ記憶媒体の例である。コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、もしくはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、もしくはその他の光記憶、磁気カセット、磁気テープ、磁気ディスク記憶、もしくはその他の磁気記憶装置、または所望の情報を記憶するのに使用でき、コンピューティング装置１００によってアクセス可能なその他の任意の媒体を、これらに限定することなく含む。そのようなコンピュータ記憶媒体はどれも、装置１００の部分とすることができる。コンピューティング装置１００は、キーボード、マウス、ペン、音声入力装置、タッチ入力装置などの、入力装置１１２を有することもできる。ディスプレイ、スピーカ、プリンタなどの出力装置１１４も含まれることができる。これらの装置は、当技術分野でよく知られており、ここで詳しく説明される必要はない。
【００２２】
コンピューティング装置１００は、装置がネットワークなどを介して他のコンピューティング装置１１８と通信することを可能にする、通信コネクション１１６も含むことができる。通信コネクション１１６は、通信媒体の一例である。通信媒体は一般に、搬送波またはその他の転送機構などの変調データ信号内のコンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータによって実施されることができ、任意の情報伝送媒体を含む。「変調データ信号」という用語は、情報を信号内に符号化するように設定または変更された１つまたは複数の特徴を有する信号を意味する。限定することなく例を挙げると、通信媒体は、有線ネットワークまたは直接配線接続などの有線媒体、ならびに音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体を含む。本明細書で使用されるコンピュータ可読媒体という用語は、記憶媒体と通信媒体の両方を含む。
【００２３】
ネットワーク接続されたパーソナルコンピュータの動作を制御するのに適した、ワシントン州レッドモンドのＭＩＣＲＯＳＯＦＴコーポレーション製のＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムなどのオペレーティングシステム１０５を含む、多くのプログラムモジュールおよびデータファイルが、コンピューティング装置１００のシステムメモリ１０４に保存されることができる。システムメモリ１０４は、文書処理アプリケーション１２０および以下で説明される他のアプリケーションなど、１つまたは複数のプログラムモジュールも保存することができる。文書処理アプリケーション１２０は、電子ドキュメントを作成し、編集し、処理するための機能を提供するように動作する。
【００２４】
本発明の一実施形態によれば、文書処理アプリケーション１２０は、ＭＩＣＲＯＳＯＦＴコーポレーション製のＷＯＲＤプログラムを含む。しかし、その他の製造業者製の文書処理アプリケーションプログラムが利用されてもよいことを理解されたい。文書処理アプリケーションの図示は、単に例を挙げるために過ぎず、ドキュメントを生成し、それに作用を及ぼし得るその他のタイプのアプリケーションを制限するものではない。例えば、様々な形式の内容（例えば、テキスト、画像、絵など）を処理することが可能な、表計算アプリケーションプログラム、データベースアプリケーションプログラム、スライドプレセンテーションアプリケーションプログラム、ドローイングまたはコンピュータ支援アプリケーションプログラムなどの、その他のアプリケーションプログラム１０６も等しく適用可能である。様々な異なるタイプのドキュメントを生成し、それに作用を及ぼすアプリケーションプログラム１０６の一例は、ＭＩＣＲＯＳＯＦＴコーポレーション製のＯＦＦＩＣＥを含む。
【００２５】
本実施形態は、コンピュータプロセス、コンピュータシステムとして、またはコンピュータプログラム製品もしくはコンピュータ可読媒体などの製造物品として実施することができる。コンピュータプログラム製品は、コンピュータシステムによって可読であり、コンピュータプロセスを実行するための命令から成るコンピュータプログラムを符号化した、コンピュータ記憶媒体とすることができる。コンピュータプログラム製品は、コンピュータシステムによって可読であり、コンピュータプロセスを実行するための命令から成るコンピュータプログラムを符号化した、搬送波上の伝播信号とすることもできる。
【００２６】
図２は、１つまたは複数のクライアントアプリケーションと１つまたは複数のデータストアおよびデータストアの内容との間の関係を示すブロック図である。一般的に述べると、１つまたは複数のデータストアが、保存、関連付けのため、および複数のデータコンシューマの間でコンピュータ生成ドキュメントに関連付けられた恣意的データの使用を可能にするため、ドキュメント内の１次提示ストレージから切り離されて維持される。ドキュメントメタデータなど、ドキュメントに関連付けられた情報を構造化するためのデータは、データの異なる部分の間の関係が維持されるデータストア内に維持される。データストアは、異なるアプリケーションが１つまたは複数のデータ部分にアクセスし、それに作用を及ぼすことを可能にするため、データストア内のデータの様々な部分へのアプリケーションプログラミングインタフェース（ＡＰＩ）を提示する。本明細書で使用される「データコンシューマ」、「アプリケーション」、および「プロセス」という用語は、別途文脈が明確に指示しない限り、交換可能に使用されることができる。
【００２７】
データの部分は、拡張可能マークアップ言語（ＸＭＬ）などのマークアップ言語に従って構造化されることができる。ＸＭＬスキーマは、データの各部分に関連付けられることができ、データストアは、各要求の有効性を保証するため、データの与えられた部分に関連付けられたＸＭＬスキーマに基づいて、データに適用されるＸＭＬ構造の有効性を確認することができる。データストアは、拡張可能マークアップ言語（ＸＭＬ）に従って構造化された、任意の数の恣意的なデータ項目、例えばメタデータを含むことができる。したがって、ドキュメントソリューションプロバイダ（ｄｏｃｕｍｅｎｔ  ｓｏｌｕｔｉｏｎ  ｐｒｏｖｉｄｅｒ）は、与えられたドキュメントと共に恣意的なメタデータをＸＭＬとして保存することができ、データが削除もしくはデータストアにロードされる場合、および／またはドキュメントがユーザによって開かれ／編集され／セーブされる場合などのイベントの発生時に、データにアクセスする与えられたソリューションによって、その情報を処理させることができる。
【００２８】
ドキュメントが編集されている間、ＸＭＬ形式のデータへのプログラムによるアクセスも提供される。一実施形態によれば、ドキュメントが開かれている間、それを介してデータがプログラム的にアクセスされ、変更される、ソリューションプロバイダに馴染みの標準メカニズムが提供される。このプログラムによるアクセスは、標準ＸＭＬ  ＡＰＩをまねて設計される。データへのプログラムによるアクセスは、１つまたは複数の編集クライアントアプリケーション（例えば、ドキュメント編集または作成アプリケーション、および／またはサードパーティアプリケーションアドインソリューション（ｔｈｉｒｄ  ｐａｒｔｙ  ａｐｐｌｉｃａｔｉｏｎ  ａｄｄ−ｉｎ  ｓｏｌｕｔｉｏｎ））へのアプリケーションプログラミングインタフェースを介して提供される。したがって、複数のクライアントアプリケーションが、ドキュメントデータの同じ部分にアクセスし、それを編集することができ、データの与えられた部分に対するどのような競合的変更も解決される。データコンシューマは、任意の与えられた変更に応答して、サイドエフェクト変更を行うことができる。例えば、会社名を「Ｍｉｃｒｏｓｏｆｔ」に設定するのに応答して、データコンシューマは、株式シンボルを「ＭＳＦＴ」に変更することができる。加えて、１つまたは複数の変更を元に戻すことで、すべての関連する変更が逆転されるように、データに対する変更と任意の関連するサイドエフェクトは、データストアによって「一括」されることができる。これは、ユーザが、例えばアンドゥー（Ｕｎｄｏ）コマンドを押下することによって、ドキュメントサーフィスからオリジナル変更のアンドゥーを開始した場合に、すべての変更を逆転したことを保証するための開発の負担を、データコンシューマ自体から取り除くのに役立つ。
【００２９】
標準ＸＭＬスキーマ（ＸＳＤ）は、ドキュメントデータに適用されるＸＭＬデータが有効であることを保証するために、ドキュメントメタデータに関連付けられたカスタムＸＭＬデータの任意の部分の内容を定義するために使用されることもできる。これらのスキーマは、ドキュメント内に保存されたＸＭＬデータの任意のインスタンスにアタッチされることができ、データストアは、ＸＭＬデータのＸＭＬ構造（すなわち、内容ではなくてＸＭＬタグ）を無効なものにする、ＸＭＬデータに対するどのような変更も拒否するように構成されることができる。これは、ソリューションデベロッパがＸＭＬメタデータの特定の部分をドキュメントにアタッチできることを保証し、ＸＭＬデータを変更するためにどのデータコンシューマ（例えばアドイン）が使用されるかに関わらず、ＸＭＬデータが関連スキーマに従って構造的に「正しく」あり続けることを保証するのに役立つ。スキーマは、ファイルまたはハードドライブなどのコンピュータ可読媒体内に保存されることができる。
【００３０】
図２を参照すると、ドキュメントデータ２２０は、ＸＭＬ構造データと、ドキュメントのサーフィスまたは提示レベルビューを表す関連するドキュメントデータとを含む。例えば、ドキュメントデータ２２０は、ＸＭＬ構造（例えば、ヘディングタグ、ボディタグ、結論タグ）と、文書処理ドキュメント、表計算ドキュメント、およびスライドプレセンテーションドキュメントなどの関連するサーフィスビューデータ（例えば、語、文、段落）とを含むことができる。
【００３１】
データストア２０８は、与えられたドキュメントに関連付けられた１つまたは複数のタイプのデータに関連付けられた構造化データの１つまたは複数の部分を保存するための、ドキュメントデータリポジトリである。ただ１つのデータストアが図示されているが、２つ以上のデータストアが利用されてもよい。メタデータ１  ２２５（構造化データ項目）は、ＸＭＬ構造データと、ドキュメントに関連付けられたメタデータの第１の部分についての関連するデータとを含むことができる。例えば、メタデータ１  ２２５は、ドキュメント作成者、ドキュメント作成日付、およびドキュメント最終変更／セーブ日付などを列挙した、ＸＭＬ構造データ（例えば、日付タグ、名前タグなど）を含むことができる。メタデータ２  ２３０（構造化データ項目）は、ＸＭＬ構造データ（タグ）と、ドキュメントに関連付けられたメタデータの第２の部分を表す関連するメタデータとを含むことができる。メタデータ１およびメタデータ２は、例を挙げるためのものであり、与えられたドキュメントに関連付けてデータストア２０８内に維持され得る異なるタイプのデータの多様性および数を限定するものではない。例えば、本明細書で説明されるように、恣意的なデータは、ドキュメントデータにアクセスするソリューションプロバイダまたはユーザによって望まれる１つまたは複数のソフトウェアアプリケーションによって、構造化され、ドキュメントに追加されることができる。
【００３２】
スキーマファイル２４０、２４５は、データ２２５、２３０の各部分に適用される拡張可能マークアップ言語（ＸＭＬ）データに関連するシンタックスおよび有効性確認規則を指図するため、データストア２０８内に保存されるデータの各部分に適宜アタッチされることができる。ＸＭＬスキーマファイルは、ＸＭＬ環境においてデータを記述し、その有効性を確認する方法を提供する。スキーマファイルは、エレメントおよびアトリビュートを含む、どのＸＭＬマークアップデータが、ＸＭＬドキュメントの内容を記述するために使用されるかを述べ、スキーマファイルは、各エレメントがどこで許容されるか、どのタイプの内容がエレメント内で許容されるか、どのエレメントが他のエレメント内に出現できるかを含む、ＸＭＬマークアップシンタックスを定義する。スキーマファイルの使用は、ドキュメント（または／およびデータの個々の部分）が一貫性のある予想可能な方法で構造化されることを保証する。スキーマファイル２４０、２４５は、ユーザによって作成され、一般にＸＭＬなどの関連するマークアップ言語によってサポートされることができる。
【００３３】
ドキュメントのこの体系化（ｓｃｈｅｍａｔｉｚａｔｉｏｎ）は、データストアが、与えられたスキーマファイルに違反するどのような変更もデータストアレベルで拒否することによって、ドキュメントの構造的有効性を「保証」する機能を提供することを可能にする。一実施形態によれば、データストア２０８は、データの与えられた部分に追加されたＸＭＬ構造または与えられた部分に施された変更の有効性を関連するスキーマファイルに照らして確認するために、スキーマ有効性確認モジュール２６０を利用する。例えば、ドキュメント作成者または編集者が、データの与えられた部分、例えばメタデータ１に、与えられたＸＭＬタグを追加または削除するなどのＸＭＬ構造変更を施した場合、変更の有効性を保証するために、データストア２０８は、スキーマ有効性確認モジュールを利用して、関連するスキーマファイルに照らしてＸＭＬ構造変更をチェックする。変更が有効でない場合、編集者に対して、エラーが生成されることができる。理解されるように、データの与えられた部分に適用されるＸＭＬ構造のそのような制御は、クライアントおよびサードパーティアプリケーションが関連データと対話することを可能にするために特に重要な、構造的一貫性および予想可能性を可能にする。任意のデータコンシューマが、データの有効性を確認するために使用され得るスキーマを提供することができる。
【００３４】
データストア２０８は、クライアントアプリケーション２０５（例えば、文書処理アプリケーション、表計算アプリケーション、スライドプレセンテーションアプリケーションなど）ばかりでなく、サードパーティアプリケーション２１０、２１５によっても、それぞれのアプリケーションのオブジェクトモデル（ＯＭ）を介してアクセスされることができる、１つまたは複数のアプリケーションプログラミングインタフェース（ＡＰＩ）２７０を提供する。これらのＡＰＩは、クライアントアプリケーションおよびサードパーティアプリケーションが、任意の既存のＸＭＬファイルを与えられたドキュメントのデータストア２０８にロードすることを可能にし、したがって、そのデータが今はドキュメントの部分であり、（例えば、オープン／編集／セーブ／リネームなどを経る）そのライフタイムにわたって、またはデータがデータストアから削除されるまで、そのドキュメント内を移動することを保証する。一実施形態によれば、データストア内のデータは、データ２２５、２３０の与えられた部分のソースアプリケーションがクローズされた場合、または他の理由で利用可能でない場合であっても、ＸＭＬフォーマットで利用可能である。すなわち、データ２２５、２３０の与えられた部分は、１組のＡＰＩを介してアクセスされることができる。以下で説明するように、ＡＰＩは、クライアントおよびサードパーティアプリケーションが、データ項目２２５、２３０に適用されるＸＭＬマークアップデータに変更を施すことも可能にする。
【００３５】
ＸＭＬデータ２２５、２３０は、ドキュメント２２０との関連付けのためにデータストアにロードされると、ＸＭＬプログラミング標準についてのデベロッパの既存の知識を利用するために既存のＸＭＬ編集インタフェースと類似した方法を提供するように設計されたデータストアインタフェースを使用して、標準ＸＭＬとして操作されることができる。これは、ユーザが、ドキュメントのためにデータストアに追加されたＸＭＬデータ上で、エレメントおよびアトリビュートの追加、エレメントおよびアトリビュートの削除、既存のエレメント／アトリビュートの値の変更、関連ＸＭＬツリーの任意の既存部分の値の読み取りなどの、標準ＸＭＬ操作を実行することを可能にする。これらのＸＭＬ標準操作を使用して、ソリューションは、構造化された複雑なメタデータをドキュメントと共に保存することができる。例えば、サードパーティアプリケーション２１５は、ドキュメント毎にデータストア２０８に追加されるメタデータ１  ２２５を読むことによって、多数のドキュメントからドキュメント作成者名およびドキュメント作成日付を発見し、抽出するように記述されることができる。サードパーティアプリケーションの例は、与えられた組織によって作成されたすべてのドキュメントについてドキュメント作成者名およびドキュメント作成日付のリストを作成するためにプログラミングされたアプリケーションとすることができる。本発明の実施形態によれば、サードパーティアプリケーションは、所望のデータを効率的に発見し、抽出するために、メタデータ１に適用されるＸＭＬ構造を利用することができる。例えば、サードパーティアプリケーションは、<docauthor>および<doccreationdate>などのＸＭＬタグを発見して、それらのタグに関連付けられたデータを獲得し使用するために、メタデータ１のＸＭＬ構造を解析するように記述されることができる。理解されるように、上述の説明は、１つまたは複数のアプリケーションが、データストア２０８を介してドキュメントに関連付けられた構造化データと対話し得る、多くの方法の一例に過ぎない。
【００３６】
加えて、データストア２０８は、複数のアプリケーション２０５、２１０、２１５がデータの同じ部分を用いて作業できるように、（ストア項目としても知られる）ＸＭＬデータ２２０、２２５、２３０の個々の部分への任意の数のＡＰＩインタフェース２７０を提供する。例えば、クライアントアプリケーション（例えば文書処理アプリケーション）およびサードパーティのアプリケーションソリューション（例えば上述のようなサードパーティアプリケーション）などの複数のソリューションは、ドキュメントプロパティの同じ組（例えば、メタデータ２  ２３０ファイルに含まれるプロパティ）を用いて作業することができる。データストア２０８を使用して、これらのアプリケーションの各々は、データの同じ部分にアクセスする複数のデータコンシューマを有する複雑さを扱う必要なく、各アプリケーションが独自のオブジェクトマネージャを介してデータと通信することを可能にするため、独自のデータストアＡＰＩインタフェース２７０を介した所望のＸＭＬデータ２３０への別々のアクセスを受け取る。
【００３７】
これらの複数のアプリケーション２０５、２１０、２１５が同じデータにアクセスすることを可能にするため、データストア２０８は、これらのアプリケーションの各々に、ＸＭＬデータのいずれかの部分が別のアプリケーションによって変更された場合、与えられたアプリケーションが（独自プロセスに対して内部的に、および同じデータに対する他の変更によって外部的に）その変更に応答できるように通知する。１つのアプリケーションが与えられたデータ項目に対する変更を要求した場合、その要求は、すべての他のアプリケーションに自動的に送られ、他のアプリケーションが要求された変更にどのように応答するか、または応答するかどうかを決定する。一実施形態によれば、これは、各アプリケーションが、それに対するインタフェースを有するＸＭＬデータの任意の部分について「聞く（ｌｉｓｔｅｎ）」ように登録して、与えられたアプリケーションソリューション／プログラムが、独自のロジックに関係があるそれらのメッセージだけを受け取ることによって達成される。例えば、１つのタイプのアプリケーション２１０は、詳細なビジネスロジック機能をサードパーティソリューションに提供するために、与えられたＸＭＬデータに施されたすべての変更を聞くように登録することを望むことができるが、別のタイプのアプリケーション２１５は、そのロジックがＸＭＬデータの他の部分に対する変更には関心がないので、同じデータ内の１つまたは２つの特定のＸＭＬエレメントに対する変更だけを聞くことを望むことができる。
【００３８】
この実施形態によれば、複数のアプリケーション２０５、２１０、２１５は、ドキュメントデータの同じ部分にアクセスし、編集することができ、データの与えられた部分に対するどのような競合的変更も解決される。例えば、任意の与えられた変更に対する「サイドエフェクト」は、１つまたは複数のアプリケーションによる１つの変更が別のアプリケーションによるサイドエフェクト変更を引き起こす場合に作成されることができる。例えば、第１のアプリケーション２１０は、与えられたドキュメントに関連する会社の株式シンボルのリストを編纂するために、与えられたドキュメントに関連付けられた１つまたは複数のデータ項目２２５、２３０から会社名を抽出して、可能ならば、それらの名前を対応する株式シンボルに変換することを仕事として課されることができる。第２のアプリケーション２１５が、例えば、会社名を「Ｃｏｍｐａｎｙ  ＡＢＣ」から「Ｃｏｍｐａｎｙ  ＸＹＺ」に変更するなど、メタデータの与えられた部分の与えられた会社名の追加または変更を引き起こした場合、第１のアプリケーションは、この変更を聞いて、「Ｃｏｍｐａｎｙ  ＡＢＣ」の代わりに「Ｃｏｍｐａｎｙ  ＸＹＺ」の株式シンボルを含むように、株式シンボルのリストを自動的に更新することができる。加えて、１つまたは複数の変更を元に戻すことで、すべての関連する変更が逆転されるように、そのような変更および任意の関連するサイドエフェクトは、データストア２０８によって一括されることができる。
【００３９】
図３は、内部および外部データコンシューマとＸＭＬデータストアとの間の対話を示すシステム図を示している。図示のように、システム３００は、ドキュメント３１５と、データストア３０２と、プレセンテーションレイヤ３０４と、各々がエラーストアおよびアンドゥーストアを含む、データストア２０２内のＸＭＬストア１〜Ｎ（３０６）と、グローバル変更ストア３０８と、オプションのグローバルアンドゥーストア３１０と、内部データコンシューマ１〜Ｎ  ３１４に結合された内部ブローカ３１２と、ＸＭＬ外部ストア３２０と、外部データコンシューマ１〜Ｎ  ３１８に結合された外部ブローカ３１６とを含む。
【００４０】
データストア３０２およびＸＭＬデータストア３０６を使用して、ドキュメントは、任意の数の恣意的なデータ項目を（各々が標準ＸＭＬシンタックスに準拠している限り）含む能力を有する。恣意的なメタデータは、ＸＭＬとしてドキュメント内に保存されることができ、その情報は、ドキュメントがユーザによって開かれ／編集され／セーブされる場合に、自動的にラウンドトリップ（ｒｏｕｎｄ−ｔｒｉｐ）されることができる。
【００４１】
上述のように、このデータへのプログラムによるアクセスは、ドキュメントが編集される際に利用され得るＡＰＩを介して提供され、ＡＰＩは、ドキュメントが開かれている間、この情報がプログラムによってアクセスおよび変更されることを可能にする、ソリューションデベロッパに馴染みの標準メカニズムを提供する。一実施形態によれば、このプログラムによるアクセスは、標準ＸＭＬインタフェースをまねて設計される。ＡＰＩを使用して、データが文書処理アプリケーションなどのアプリケーションが動作している最中に追加／削除されることができ、データがストア項目（データストア内の部分）内に投入されることができ、データが標準ＸＭＬ構造を使用して操作されることができ、スキーマがデータストア内の任意のＸＭＬデータに関連付けられることができ、データストア項目と関連付けられた後、スキーマが追加／削除／変更されることができ、ＸＭＬ変更があらゆるリスニングクライアントにイベントとして通知されることができる。図示のように、ＡＰＩは、データストア３０２と対話する外部データコンシューマ３１８にインタフェースを提供する外部ブローカ３１６と、任意の内部データコンシューマ３１４にインタフェースを提供する内部ブローカ３１２とを含む。
【００４２】
データストア３０２への操作は、リアルタイムに行われてよい。上述のように、データストア３０２および３０６は、１つまたは複数のタイプのデータを含むことができる。例えば、ある会社は、保存したいと望むすべての異なるタイプのデータを単一のデータストア内に保存するために使用する１つのデータストアをもつことができ、別の会社は、異なるタイプのデータを異なるデータストアに分散させて保存することを望むことができる。
【００４３】
データコンシューマ（内部３１４および／または外部３１８）は、データストア内のデータに関するアクションに関係するイベントに対して登録することができる。例えば、データコンシューマは、どのようなタイプの変更がデータストアの１つまたは複数に行われた場合でもイベントを受け取るように登録することができる。別のデータコンシューマは、データストア内のあるエレメントまたは１組のエレメントに起こった変更に対して登録することができる。一般的なイベントは、項目の追加、項目の変更、およびデータストアの１つからの項目の削除を含む。イベントが起こった場合、登録を行った各データコンシューマは、データストアの状態が矛盾なく維持されている間、変更に対して反応することができる。多くの場合、変更が行われた時、データコンシューマは、どのようなアクションも実行しない。その他の場合、データコンシューマは、イベントに応答して、何らかのアクションを実行する。例えば、データコンシューマは、タイトル変更に応答して、ドキュメント内のヘッダを更新するなど、変更に応答して、データストアに何らかの他の変更を行うことができる。データコンシューマは、ドキュメントに影響しない何らかの他の操作も実行することができる。例えば、株式ティッカシンボルが挿入される場合、データコンシューマは、検索データのすべてがプレセンテーションレイヤでドキュメント内に表示されるわけではないとしても、その株式シンボルに関連付けられたデータを検索することができる。データコンシューマは、独自の有効性確認ロジックを使用して、変更を拒否することもできる。例えば、受け入れられない変更をデータコンシューマ１が受け取った場合、そのデータコンシューマは、変更が受け入れられないことを示すフラグをブローカに返すことができる。変更が受け入れられない場合は常に、その変更は、あたかも変更が起こらなかったかのように、すべてのサイドエフェクトと一緒にロールバックされる。各ＸＭＬストア３０６は、行われた変更を元に戻すために、それのアンドゥーストアを利用することができる。代替として、データストア全体にわたって行われた変更を元に戻すために、グローバルアンドゥーストア３１０が利用されてもよい。ドキュメントのプロパティに起こることに関心がある３つのデータコンシューマが存在し、そのため、これらのデータコンシューマの各々が、プロパティの変更に関するイベントを受け取るように登録したと想定する。変更が行われる場合、データストアは、登録を行った各データコンシューマを決定し、それらの各々に所定の順序で変更を通知する。各データコンシューマは、順々に、変更に応答して何らかのアクションを実行することができる。変更が、または変更の結果として登録データコンシューマによって行われたいずれかの変更が、いずれか１つのデータコンシューマによって受け入れられない場合、最初の変更に関係するすべての変更が元に戻される。
【００４４】
外部ブローカアプリケーションプログラミングインタフェースレイヤ３１６は、外部データコンシューマ３１８によるデータストア３０２へのアクセスを提供し、アプリケーションに関連付けられた内部データコンシューマがデータストアと対話するように、サードパーティクライアントがデータストア３０２と対話することを可能にする。データストア３０２内のＸＭＬデータストア３０６の各々は、識別目的の一意ＩＤを提供される。これは、ＸＭＬデータストア３０６を発見する際に役立つ。
【００４５】
任意の時点で、データコンシューマは、データストア内のデータの有効性を確認するのに使用されるスキーマを追加することができる。スキーマが追加され、データコンシューマがいずれかのデータを変更しようと試みる場合、データストアは、その変更が提供されたスキーマに矛盾しないかどうかを決定する。スキーマがアタッチされると、ブローカは、有効性確認用オブジェクトになる。
【００４６】
カスタム定義ＸＭＬスキーマは、文書処理ドキュメントおよび表計算ドキュメントなどのドキュメント内の内容を囲むセマンティックマークアップを提供するために使用されることができる。この強力な機能は、基礎をなすアプリケーションのプレセンテーションフォーマットの複雑さを扱うソリューションを必要とする代わりに、デベロッパが、このカスタムＸＭＬ埋め込みを利用して、データの構造および内容に直接働きかけるソリューションを生み出すことを可能にする。
【００４７】
例えば、ユーザが、ＸＭＬに準拠していないアプリケーションで、株式リサーチ報告書の表紙ページを作成する場合、有用なデータ（例えば、会社名、株式ティッカシンボル、株式格付け）を抽出するには、ドキュメントのプレセンテーションフォーマットに密接に結び付けられた、アプリケーションのオブジェクトモデルの使用を必要とする。これは必然的に、結果のソリューションロジックも、ドキュメントのプレセンテーションフォーマットに結び付けられ、そのプレセンテーションが変化した場合、障害を免れないことを意味する。例えば、スティッカシンボルが第１のテーブルの３列２行に存在することをコードが予期している場合、新しい行／列の追加は、このロジックを壊乱する。しかし、ＸＭＬ準拠のアプリケーションを用いた場合、このコードは、顧客自身のデータの構造にリンクされることができ、ロジックがプレセンテーションに結び付けられる必要性を排除する。その同じロジックが、文脈的提示（ｃｏｎｔｅｘｔｕａｌ  ｐｒｅｓｅｎｔａｔｉｏｎ）が大幅に変化したとしても、ＸＭＬノード<stockSymbol/>の内容を検索し、ドキュメント内のどこに存在しても、編集するためにそれを見つけ出すことができる。
【００４８】
ＸＭＬスキーマはしばしば、メタデータ（例えば、保存／処理用の作成者データ）、本体データ（例えば、報告対象の会社）、および表データ（例えば、株価履歴）を含む、いくつかのタイプのデータを包含する。しかし、これらのデータタイプは、相互に排他的ではない。実際、それらは通常、同じＸＭＬドキュメント内の広い領域で重複する。理想的には、このデータはすべて単一のＸＭＬスキーマによって表現されるが、これらの様々なデータ「タイプ」の各々は、そのデータの最適表現に特に適合された環境において編集等を行うことができる。例えば、ユーザがドキュメントのメタデータを容易に編集できるようにフォームが出現し得る一方、ドキュメント本体は、文書処理アプリケーションによって編集可能である。これは、ユーザがドキュメントの部分とフォームとに同時に記入することができるように、リアルタイムに生じる。
【００４９】
データストアは、一度に２つ以上のエレメントを受け取ることもできる。データ（ＸＭＬ）を１つの特定のストリームとして提供することは、ある状況でスキーマを満足させるのに役立つ。例えば、アタッチされたスキーマが、株式データが存在する場合、それは少なくとも２つの仲間をもたなければならないと述べていると仮定する。株式データが１つずつ追加された場合、それは有効ではない。
【００５０】
一実施形態によれば、データの有効性を確認するために、単一のパスが使用される。データストアに対して行われる変更をもたらし得る２つのパスを作成する代わりに、データがデータストアにコミットされる前に、有効性確認が実行される。これは、データコンシューマがデータストアにエラーを導入するのを防止するために役立つ。
【００５１】
本明細書で説明するように、ドキュメントに関連付けられたＸＭＬデータは、特定のアプリケーションドキュメントから切り離され、中央ＸＭＬデータストア３０２に保存されることができる。複数の環境が、ＸＭＬデータの１部分の提示／編集のために生成されることができる。そのデータの表現は、ＸＭＬデータストア内の同じデータへの接続を介して、自動的に同期される。そのようにして、複数のアプリケーションが、基礎をなす同じＸＭＬデータを同時に表示することができる。これは、ユーザが、同じデータを「ジョブにとって最良なツール」であるアプリケーションで編集する能力を与えられることを意味する。例えば、メタデータ情報を編集するためのフォーム、データの自由形式セクションを編集するための文書処理ドキュメントサーフィスなどである。これは、ユーザが、要望に応じて複数のアプリケーションでデータを編集し得ることも意味する。同じ情報が複数のアプリケーションに出現する場合、ユーザは、現在の編集コンテキストに基づいて、そのデータを要望に応じてそれらのいずれかで編集することができる。
【００５２】
各アプリケーションは、ドキュメントに関連付けられたＸＭＬデータ全体に同時アクセスを行うことができるが、そのデータのどの部分を表示し、編集するかについて、個別に選択することができる。これは、各アプリケーションが、そのコンテキスト内で関連するデータの部分だけを表示すればよいことを意味する。例えば、ドキュメントには、すべてのＸＭＬデータが表示されることができるが、別のアプリケーションは、データ内の１つのＸＭＬノードの値だけに関心があってよく、したがって、コンテキストを保証するためにＸＭＬ構造の残りの部分を「携行」することを心配せずに、データのその部分だけを表示すればよい。
【００５３】
ユーザは、同じＸＭＬ情報を表示する任意のアプリケーションで、データを編集することができ、データのその部分を参照するすべてのロケーションにおいて（適用可能なビジネスロジックと共に）そのデータを直ちに更新することができる。各ＸＭＬ変更についてのリアルタイムメッセージを受け取るこの機能は、単一のＸＭＬドキュメント内の様々な編集要件の重複性を反映した編集環境の作成を可能にするので役に立つ。
【００５４】
アプリケーションは、エラー情報も共有することができる。ユーザ定義の内容エラーの集まりが、各データストア内に保存されてよい。例えば、ビジネスロジックは、<startDate>ノードが<endDate>ノードより前の値をもたなければならないと命じることができる。複数のデータコンシューマが集団でエラーを共有することを可能にするため、ＸＭＬ内のノードの一覧＋（エラーテキストおよび名前から成る）エラーを保存するエラーストアが、各ＸＭＬストア内に含まれる。ＸＭＬ変更と同様に、１つのクライアントがエラーを生成することができ、次にそのエラー変更が各クライアントにブロードキャストされる。そのようにして、複数のアプリケーションは、そのデータのすべての表現に対して共有される有効性確認ロジックの単一の実装に依存することができる。言い換えると、同じロジックが、ＸＭＬデータを表示する各アプリケーションで複製される必要はない。
【００５５】
アンドゥーストアは、グローバルアンドゥーストア３１０であってもよく、および／またはアンドゥーストアは、各ＸＭＬストアと共に含まれてもよい。各データコンシューマの変更要求は、連結されて、アンドゥーストア３１０などの単一のアンドゥースタックに入れられ、アンドゥースタックは、各変更がまとまりとして元に戻され得るように、各変更をすべての関連する変更と組み合わせる。これは、すべてのクライアントが、最後の変更全部の「アンドゥー」を要求して、ドキュメント全体を知られた「良好」な状態に維持することを可能にする。
【００５６】
データの同期は、所定の事前定義されたデータコンシューマのグループに限定されない。言い換えると、新しいデータコンシューマは、いつでも、ＸＭＬデータに関する通知に対して登録を行うことができ、直ちに、その同じデータを他のすべてのクライアントのように編集することが可能である。例えば、最初、外部データコンシューマ１および２だけがデータを共有している。その後、１つまたは複数のデータコンシューマが、データストアに登録して、そのデータを共有し始めることができる。
【００５７】
１つのデータコンシューマが、ＸＭＬデータの「オーナ」として行為し、ＸＭＬデータの永続的な形式を維持すること、データのコピーを要求データコンシューマに提供すること、データに対する変更要求をデータコンシューマから受け取ること、および変更の通知を登録データコンシューマに送ることに責任を負う。一実施形態によれば、データストアは、オーナとして行為し、各データコンシューマのためにすべての更新および通知を処理する。ＸＭＬデータストアは、文書処理アプリケーション、表計算アプリケーション、スライドプレセンテーションプログラム、およびその他のデータコンシューマなどの異なるアプリケーションで利用可能な１組のインタフェースを含む。インタフェースは、ＸＭＬデータの所望の部分を獲得すること、データコンシューマがデータストアに対して行いたい変更をデータストアに通知すること、および他のデータコンシューマによって行われたそのストア項目に対する変更についての通知をＸＭＬデータストアから受け取るように登録することに充てられる。
【００５８】
データストアがデータコンシューマに変更を通知した場合、データコンシューマは、何もせず変更を受け入れること、１つまたは複数のサイドエフェクト変更を要求すること、および変更を拒否することができる。サイドエフェクト変更は一般に、データストアに対して行われる他の変更に応答して、変更を開始するロジックの追加を含む。例えば、株式リサーチ報告書を使用するデータコンシューマは、データストア内の<stockSymbol/>ノードが変更された場合に通知を受け取り、その変更に応答して、ウェブサーバにデータをサブミットし、データストア内にある<stockData/>サブツリーを更新することを望むことができる。
【００５９】
サイドエフェクト変更は、アンドゥー／キャンセルの目的で、オリジナル変更と共に一括され、データストアによって異なる方法で処理される。サイドエフェクト変更は、それ自体まだＸＭＬデータストアにコミットされていない変更に応答して要求されるので、異なる方法で処理される。
【００６０】
データコンシューマ（３１４および／または３１８）がＸＭＬデータストア３０２に対する変更を要求した場合、その変更は、変更が無効であること（例えば、不適切な形式のＸＭＬ）、および変更がデータコンシューマ内の何らかのロジックによって拒否されたことなどを含む、異なる理由で拒否されることができる。
【００６１】
いくつかのデータコンシューマは、ＸＭＬデータストア３０２から切り離されて維持される、独自バージョンのデータをストア３２０内に維持することができる。このＸＭＬデータの複数のコピーを維持することは、コピーが同期しなくなる（例えば、プロパティパネル内の「タイトル」がドキュメント内にインラインで表示された「タイトル」と一致しない）ことを含む、問題を引き起こすことがある。この問題に対処するため、ＸＭＬデータの各部分の単一の「マスタ」コピーが、セッションの間、維持される。その後、このマスタコピーは、セッションの間、複数のデータコンシューマによって使用される。セッションが終了すると、データのその他のコピーは、ＸＭＬデータストアの現在の状態を反映するように更新されることができる。一実施形態によれば、データストア３０２は、異なるデータストアからの同じ項目をマージし、その後、各コピーをセーブバックするように構成される。共通データ項目に対する要求が受け取られると、データストア３０２は、それら２つのデータストア項目を単一のペアレントノードにおいてラップ（ｗｒａｐ）し、各データ項目に関連付けられたスキーマをインポートするマージされたＸＳＤを生成し、このストア項目用のインタフェースをデータコンシューマに送付する。
【００６２】
データストア３０２は、過度な反復を検出するように構成され、検出された場合、データストアが与えられた変更に応答したサイドエフェクトのループを検出したならば、自動エラーを引き起こすように構成される。一実施形態によれば、深さが１６レベルを超えるか、またはサイドエフェクト総数が１０００を超えるループが、過度であると見なされる。データストアは、変更が構造的に無効であることがＸＭＬデータストアによって見出された場合、変更とそのサイドエフェクトを自動的に拒否するようにも構成されることができる。これは、構造変更がクライアントによって要求され、構造的に無効であることが見出された場合、データストアが、それ自体を最後の知られた良好な状態に回復し、他のデータコンシューマに送付され得るエラーを生成することを意味する。
【００６３】
各データコンシューマ（内部３１４／外部３１８）は、無効な変更を拒否することもできる。例えば、データコンシューマは、独自の有効性確認レイヤを含むことができる。データコンシューマ内で無効な変更が要求された場合、その変更は、存在する有効性確認レイヤによって拒否され、ＸＭＬデータストアに通知することなく、独自のデータストアからロールバックされることができる。その変更がＸＭＬデータストアから発した場合、データコンシューマは、データストアによって投じられたイベントに対する拒否を返し、データストアは、キャンセルを発動して「最後の知られた良好な状態」に戻る。
【００６４】
他のデータコンシューマによって要求されたデータストアに対する変更の場合、データストアは、現在のデータに関連付けられたＸＭＬスキーマの集まり（３０５）を有するならば、それらの変更の有効性を確認しようと試みる。スキーマが存在する場合、データストアは、構造的な無効を拒否する。
【００６５】
データバインディング（ｄａｔａ  ｂｉｎｄｉｎｇ）をサポートするため、内部データコンシューマ１  ３１４などの内部アプリケーションデータコンシューマは、ＸＭＬデータストア内のアクションとドキュメントサーフィス３１５上のアクションの間の対話を処理する。ユーザがデータバインディングフィールドを編集する場合、その変更は、ドキュメントの内容に影響する（したがって、アプリケーションのアンドゥースタックにレコードを追加する）ばかりでなく、データストアのＸＭＬ内容にも影響する（したがって、データストアのアンドゥースタックにレコードを追加する）。サーフィスとデータが常に同期を保つことを保証するのに役立つように、（ユーザが対話する）アプリケーションのアンドゥースタックは、サーフィスの変更を対応するＸＭＬデータストアのアンドゥー参照と共に１つのアンドゥーレコードに「一括」し、各スタックの最上位項目を元に戻すことで、アプリケーションとデータストアが同一状態に保たれることを保証することを可能にする。
【００６６】
ホストアプリケーションを含む各データコンシューマ用に別々のアンドゥースタックを維持すること、グローバルアンドゥースタックを共用すること、現在のフォーカスに基づいてデータコンシューマ用のアンドゥーを制限することを含む、異なる代替も、ユーザ起動のアンドゥーを処理するために利用可能である。
【００６７】
グローバルアンドゥースタックが使用される場合、データコンシューマは、アンドゥー要求をホストアプリケーションに直接受け渡し、その後、ホストアプリケーションは、そのアンドゥースタックから最後の項目を取り除く（アンドゥーは、フォーカスがアプリケーションフレーム内のどこにあるかに関わらず同じである）。これは、ＸＭＬデータストアに対するすべての変更が、何らかの包括的なレコード（例えば「Undo Property Edit」）と共に、ホストのアンドゥースタックに集約的に送られることを意味する。例えば、ユーザが文書処理アプリケーションで<company/>フィールドに「Microsoft Corp.」とタイプした場合、その操作は、その後、データストアのアンドゥースタックがそのアクションを含む原因となる。次に、そのテキストを削除するために、ユーザが文書処理アプリケーションでｕｎｄｏを押下した場合、文書処理アプリケーションは、そのアンドゥースタック上で最後の操作を元に戻し（データストアにそのスタック上で最後の操作を元に戻すように通知し）、その結果、他のクライアントがそのアクションを実行する。反対に、その後、ユーザが文書処理アプリケーションで非バインディングテキストをタイプし、パネル内のｕｎｄｏを押下した場合、他のクライアントは、その要求をホストに伝え、ホストは、そのアンドゥースタックから最後のアクション（この場合、ドキュメントサーフィスに対する編集）を取り除く。
【００６８】
データコンシューマがＸＭＬデータストアによって送られた変更を拒否する場合、ＸＭＬデータは、「不良」ビジネスロジック状態で終わることがあり得る。例えば、経費報告書に対するチェックを実行するビジネスロジックがあると仮定する。ロジックは、勘定項目が＄１００を超えているかどうかをチェックするステップを含み、超えている場合、データコンシューマは、<lineItemAmount/>の更新を拒否する。超えていない場合、データコンシューマは、新しい勘定項目金額を用いて合計を更新する。合計が＄５００を超えた場合、データコンシューマは、<reportTotal/>の更新を拒否する。ユーザが、＄５０の請求勘定を入力した結果、合計が＄５００を超えたと仮定し、ここで上述のロジックを使用すると、第１のロジックチェックは成功するが、第２のロジックチェックは合計の更新を拒否する。これは、最後の変更が元に戻された場合、勘定項目の和が合計と一致しない、請求書が存在することを意味する。その結果、一実施形態によれば、オリジナル変更のサイドエフェクトのすべてが、元に戻される。
【００６９】
データストア３０２は、アンドゥー目的でこれらのトランザクションを一括化することを可能にする、トランザクションメカニズムとして機能する。一実施形態によれば、「拒否」を処理するための３つの異なる代替方法が使用される。第１に、データストアは、有効な状態に戻すためにアンドゥー変更を発行することができる（「ロールバック」とも呼ばれる）。第２に、アンドゥーとキャンセルは、非同等性（ｎｏｎ−ｐａｒｉｔｙ）を有し、第３に、クライアントは、キャンセルできない。
【００７０】
第１の代替方法は、有効な状態に戻るために、ＸＭＬデータストアにアンドゥー変更を発行させる。これは必然的に、ビジネスロジックエラーを誘発するきっかけとなった変更まで、すべての操作を元に戻す。この代替方法では、ＸＭＬデータストアは、「アンドゥー」フラグがＴＲＵＥに設定された変更要求を発行して、データコンシューマに自らこれらの変更を実行させることができ、ＸＭＬデータストアは、それの「アンドゥー」フラグが設定された変更要求を発行することができる。以下は一例である。
【００７１】
【表１】
2009508231.tif 000003
【００７２】
【表２】
2009508231.tif 000004
【００７３】
要するに、データコンシューマは、２つのＸＭＬデータストアコール（ペアレント変更Ａを残したまま、変更ＢおよびＣを元に戻すための要求）を受け入れ、さもないと、２つのＸＭＬドキュメントオブジェクトマネージャは、同期が保てなくなる。
【００７４】
別の代替方法は、データコンシューマに現在の変更を「キャンセル」させて、ソリューションを無効なビジネスロジック状態のままにしておける限り、キャンセルとアンドゥーの間の現在の非同等性（ｄｉｓｐａｒｉｔｙ）を維持するものである。この場合、ＸＭＬデータストアは、拒否／キャンセルされた変更「だけ」をロールバックし、その変更を元に戻すが、その後、ストアのアンドゥースタック上にあるさらなる変更を元に戻すことなく、直ちに停止する。
【００７５】
データコンシューマは、独自のアンドゥースタックを維持することもできる。しかし、アプリケーションは、そのスタックの最上位アクションがライブ同期境界（ｌｉｖｅ  ｓｙｎｃ  ｂｏｕｎｄａｒｙ）の他の側から要求された操作に一致する場合、そのアンドゥースタックに追加のアクションを追加しないように「スマート」であるべきである。例えば、ユーザが文書処理アプリケーションで<company/>フィールドに「Microsoft Corp.」とタイプした場合、その操作は、「ライブ同期」が取られ、その結果、アンドゥーアクションを各登録データコンシューマのアンドゥースタック上に出現させる。次にユーザが、入力したばかりのテキストを削除するために、文書処理アプリケーションでアンドゥーを押下した場合、文書処理アプリケーションは、そのアンドゥースタック上の最後の操作を元に戻す（と共に、データストアにそのアンドゥースタック上の最後の操作を元に戻すように通知する）が、この時、データコンシューマは、この要求を見て、ストアのアンドゥースタックはデータストアと必ず一致しなければならないので、そのアンドゥースタックから（任意のサイドエフェクトを含む）最後のアクションを取り除く。ユーザがデータコンシューマでアンドゥーを押下した場合、データコンシューマは、そのアンドゥースタックから最後のアクションを削除し、文書処理アプリケーションは、データストアからアンドゥーアクションを取得した時に、それがそのアンドゥースタック上の最後のアクションと一致することに気づいて、それを同じように削除する。反対に、データコンシューマでアンドゥーを押下する前に、ユーザが文書処理アプリケーションで何らかの非バインディングテキストをタイプ（して、アンドゥーレコードを文書処理アプリケーションに追加）した場合、クライアントは、そのアンドゥースタックから最後のアクションを削除し、ストアも同じことをするが、文書処理アプリケーションは、（アンドゥースタック上の最後の物は最後のＸＭＬ変更ではないので）別のアクションを追加する。しかし、文書処理アプリケーションは、その変更を、ストアはオリジナル状態に戻るためにはリドゥー（ｒｅｄｏ）を実行する必要があるという事実と共に保存する。
【００７６】
別の代替方法は、データコンシューマを互いについて知るようにすることを含む。アンドゥー制御は、データコンシューマの間で受け渡されることができる。例えば、ユーザが１つのアプリケーションで<company/>フィールドを編集した場合、その後、それは別のデータコンシューマにブロードキャストされ、アンドゥースタックは次のようになる。
【００７７】
【表３】
2009508231.tif 000005
【００７８】
この場合、ＸＭＬデータストア上のアンドゥーレコードは、トランザクションをホストしない。代わりに、それは、アンドゥーアクションを完了するために制御をクライアントに渡すことを可能にするマーカをホストする。その後、ユーザが文書処理アプリケーションに行き、アンドゥーを実行したと仮定すると、アプリケーションのキャンバスは、更新されて元に戻り、その後、制御をデータストアに渡す。ＸＭＬデータストアは、最後のトランザクションを元に戻すように試みるが、マーカを見て、そのアンドゥーのために制御をデータコンシューマに渡す。データコンシューマは、ストアに対してアンドゥー要求を実行し、その後、ストアは、それをアンドゥーとしてすべての他のクライアントにブロードキャストする。これは、ユーザがクライアントでアクションを実行し、それに文書処理アプリケーションの異なるフィールド上でのアクションが続く場合、アンドゥースタックが次のようになることを意味する。
【００７９】
【表４】
2009508231.tif 000006
【００８０】
この場合、ユーザの次のアクションがホストアプリケーションでのアンドゥーである場合、ホスト（およびデータストア）は、アンドゥーアクションを実行し、データコンシューマはそれを独自のＤＯＭ上で実行し、アンドゥーマーカを投げる。ユーザの次のアクションがデータコンシューマでのアンドゥーである場合、データコンシューマは、（最上位アクションはちょうど「マーカ」であるので）このアクションについての制御をホストに与え、同じホストアンドゥーが実行される。
【００８１】
図４は、ライブ同期の一例を示している。最も単純な場合の１つでは、「ライブ同期」とは、１つのロケーション（例えば文書処理アプリケーション）で提示されたＸＭＬデータに対するユーザ編集がリアルタイムに別のロケーション／アプリケーションのＵＩに反映される機能を指す。ドキュメントが編集されている間、ＸＭＬデータに影響する変更は、文書処理アプリケーションおよびプロパティパネルの両方など、そのデータに関心がある他の登録データコンシューマに送られる。これは、各アプリケーションのＸＭＬデータの内容が同じであり続けることを保証するのに役立つ。
【００８２】
ウィンドウ４００を参照すると、ドキュメント４１５が編集のために開かれており、プロパティパネル４２０が示されている。プロパティパネル（４０５）およびドキュメント（４１０）の両方にタイトルが示されている。ウィンドウ４００内のタイトル４０５が、ウィンドウ４２５内のタイトル４３５およびタイトル４４０に示されているように、Data Binding - Live Sync IntegrationからFoo Bar Bizに変更されたと仮定する。プロパティパネルタイトル４３５内でタイトルが更新されると直ちに、その変更を受け入れること、または拒否することができるように、変更が文書処理アプリケーションに送られる。この例では、アプリケーションは、プロパティパネルアプリケーションを使用して行われたタイトルに対する変更を受け入れ、ドキュメント内のタイトル４４０は更新される。
【００８３】
図５〜図８は、データコンシューマ間でのＸＭＬデータのリアルタイム同期のためのプロセスを示している。
【００８４】
本明細書で提示されるルーチンの説明を読む場合、様々な実施形態の論理操作は、（１）コンピューティングシステム上で実行される一連のコンピュータ実施行為またはプログラムモジュールとして、および／または（２）コンピューティングシステム内の相互接続マシン論理回路または回路モジュールとして実施されることを理解されたい。実装は、本発明を実施するコンピューティングシステムの性能要件に依存する選択の問題である。したがって、本明細書で説明される実施形態を構成する示された論理操作は、操作、構造的装置（ｓｔｒｕｃｔｕｒａｌ  ｄｅｖｉｃｅ）、動作、またはモジュールなど様々に呼ばれる。これらの操作、構造的装置、動作、およびモジュールは、ソフトウェア、ファームウェア、専用デジタルロジック、およびそれらの任意の組合せで実施されることができる。
【００８５】
図５は、２つのクライアントとＸＭＬデータストアの間の対話を示している。
【００８６】
データストア５２０は、アプリケーション５１０を使用して行われたノードＡに対するユーザ編集を受け取る。データコンシューマ１  ５３０は、データストア５２０からノードＡに対する変更の通知を受け取る。ノードＡに対する変更の結果、データコンシューマ１は、ノードＢに対するサイドエフェクト変更を要求する。データストア５２０は、後の実行のためサイドエフェクト変更Ｂを待ち行列に入れる。データコンシューマ１からのすべてのサイドエフェクト変更が待ち行列に入れられると、データストア５２０は、データコンシューマ２（５４０）にノードＡに対する変更を通知する。データコンシューマ２は、ノードＣに対するサイドエフェクト変更を要求する。それに応答して、データストアは、後の実行のためノードＣ変更を待ち行列に入れる。この時点で、ノードＡに関する処理は完了するが、まだノードＢおよびノードＣに対する保留中のサイドエフェクト変更が存在する。データコンシューマ１がノードＢに対する変更を要求したので、データストアは、提案されたＢの変更の通知をデータコンシューマ２に送る。データコンシューマ２は、それに応答してどのような変更も行わず、変更を受け入れる。同様に、データコンシューマ２がノードＣに対する変更を要求したので、データストアは、ノードＣの変更の通知をデータコンシューマ１に送る。データコンシューマ１は、変更を受け入れる。この例では、変更のすべてが、対象データコンシューマのすべてによって受け入れられる。したがって、データストアは、データストアに変更をコミットする。要するに、データストアは、各データコンシューマが、変更に応答して任意の変更を実行することを可能にし、データストアは、これらの変更を、それが受け取られた順序で実行および伝達し、それによって、変更が逐次的に伝達されることを可能にする。
【００８７】
図６は、２つの外部データコンシューマの間の対話と、ＸＭＬデータストアに対する変更を示している。
【００８８】
オリジナル変更が、図５に示されたドキュメントを生成するアプリケーションなどの内部クライアントによって生成される場合、データコンシューマは僅かに変化する。この例は、複数のクライアントからの変更についての２つの基本規則を示している。第１の規則は、上位レベル変更が深さから最初に発生することである。第２の規則は、サイドエフェクト変更を待ち行列に入れることを含む。
【００８９】
第１の規則は、変更のサイドエフェクトは、新しい変更が発生し得る以前に起こるという事実に関係する。データコンシューマ１が２つの変更を行う機能を実行する、以下の例について考える。第１の変更は、ノードＡに対して行われ、第２の変更は、ノードＢに対して行われる。
【００９０】
データコンシューマ１（６３０）がノードＡに対する変更を要求した場合、ＸＭＬデータストア６２０がノードＡを変更する要求を受け取った後、通知が、データコンシューマ２（６４０）に送られる。それに応答して、データコンシューマ２は、ノードＣに対するサイドエフェクト変更を要求し、サイドエフェクト変更は、後の実行のためデータストアによって待ち行列に入れられる。その後、データコンシューマ１は、ノードＢに対する変更を要求し、ノードＡに対する変更がまだ完了していないので、それは待ち行列に入れられる。データコンシューマ２は、ノードＡに対する変更を受け入れ、それに応答して、データストアは、待ち行列に入れられたＣに対するサイドエフェクト変更を実行する。データコンシューマ１は、ノードＣに対する変更の通知を受け取り、その変更に応答することができる。この例では、データコンシューマ１は、その変更を受け入れる。その後、データストアは、データコンシューマ１によって要求された、待ち行列に入れられたＢに対するサイドエフェクト変更を実行する。データコンシューマ２は、データストアからＢを変更する通知を受け取り、それに対して応答することができる。データコンシューマ２は、変更を受け入れ、変更がデータストアにコミットされる。
【００９１】
この場合、データコンシューマ２は、Ａに対する変更に最初に応答し、以下の２行のコードが、２つの独自の変更をトリガする。
【００９２】
【表５】
2009508231.tif 000007
【００９３】
第２の規則は、変更のサイドエフェクトは要求されると待ち行列に入れられ、したがって、最初の変更のサイドエフェクトが発生する前に、複数の変更が待ち行列に入れられ得るという事実に関係する。
【００９４】
図７は、複数のサイドエフェクト変更を含むプロセスを示している。以下の例は、以下の変更を示す。データコンシューマ１（７３０）は、ノードＡが変更された通知を受け取った場合、ノードＢおよびＣに対するサイドエフェクト変更を実行したいと仮定する。データコンシューマ２（７４０）は、ノードＢに対する変更の通知に応答して、ノードＤ、Ｅ、Ｆに対するサイドエフェクト変更を実行したい。
【００９５】
図７を参照すると、データコンシューマ１は、そのサイドエフェクト変更のすべてを、ノードＢの変更に関するサイドエフェクト変更が実行される前に、ノードＡに対する変更の通知の結果として引き起こすことが分かる。したがって、ノードＣに対する変更は、ノードＤ、Ｅ、Ｆに対する変更の前に発生する。
【００９６】
図８は、呼び側のサイドエフェクトが最後に実行されることを示すプロセスを示している。この場合、データコンシューマ１自体によって生成されるサイドエフェクトは、他のすべてのクライアントが変更を見て、独自のサイドエフェクトを生成する機会をもった後に起こることが分かる。これは、ＸＭＬデータストアが呼び側に成功状態を返し、呼び側がサイドエフェクトを実行するためのイベントを提供することを可能にする前に、ＸＭＬデータストアが、（各クライアントがその変更を受け入れる／拒否する機会をもつことを保証するために）各クライアントに変更を通知するという事実から必要とされるサイドエフェクトである。ＸＭＬデータストアのすべてのクライアントによって変更が受け入れられたか、それとも拒否されたかを聞くために、変更を要求したデータコンシューマが最後になるべきことが予想可能である。同様に、これは、２つの変更が競合し、構造的でない場合、一般に望ましい結果とされる、呼び側の変更が勝つことを保証するのに役立つ。
【００９７】
上記の明細書、例、およびデータは、本発明の構成の製造および使用の完全な説明を提供する。
【図面の簡単な説明】
【００９８】
【図１】コンピュータ用の例示的なコンピューティングアーキテクチャを示す図である。
【図２】１つまたは複数のクライアントアプリケーションと１つまたは複数のデータストアおよびデータストアの内容との間の関係を示すブロック図である。
【図３】内部および外部データコンシューマとＸＭＬデータストアとの間の対話を示すシステム図である。
【図４】ライブ同期の一例を示す図である。
【図５】２つのクライアントとＸＭＬデータストアの間の対話を示す図である。
【図６】２つの外部データコンシューマの間の対話と、ＸＭＬデータストアに対する変更を示す図である。
【図７】複数のサイドエフェクト変更を含むプロセスを示す図である。
【図８】本発明の態様によれば呼び側のサイドエフェクトが最後に実行されることを示すプロセスを示す図である。
【図１】
2009508231.tif 000008
【図２】
2009508231.tif 000009
【図３】
2009508231.tif 000010
【図４】
2009508231.tif 000011
【図５】
2009508231.tif 000012
【図６】
2009508231.tif 000013
【図７】
2009508231.tif 000014
【図８】
2009508231.tif 000015
【国際調査報告】
2009508231.tif 000016
2009508231.tif 000017