(57)【要約】【課題】データをバインドするためのプログラマビリティを提供すること。【解決手段】データバインディングインターフェースをエクスポーズし、データバインディングインターフェースに関連付けられたメソッド、プロパティ、またはイベントを用いる。そこでは前記メソッド、プロパティ、または前記イベントは、データバインディング、データ、またはデータバインディングに関連付けられた他のオブジェクトの操作を可能にするオブジェクトを返す。【選択図】図２
2006190277.tif 000002
【特許請求の範囲】
【請求項１】
データストアとコンテンツ領域とをリンクするデータバインディングの使用方法であって、
データバインディングインターフェースをエクスポーズするステップと、
前記データバインディングインターフェースに関連付けられたメソッド、プロパティ、またはイベントを用いるステップであって、そこでは前記メソッド、前記プロパティ、または前記イベントは、前記データバインディング、データ、または前記データバインディングに関連付けられた他のオブジェクトの操作を可能にするオブジェクトを返すステップと
を含むことを特徴とする方法。
【請求項２】
プロパティを用いて、特定のデータバインディングに関連付けられたＸＭＬデータを見つけるステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項３】
コードを用いて前記ＸＭＬデータを操作するステップをさらに含むことを特徴とする請求項２に記載の方法。
【請求項４】
プロパティを用いてＸＭＬデータ内でターゲットノードを見つけるステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項５】
コードを用いて、関連付けられたデータバインディングの前記ターゲットノードを操作するステップをさらに含むことを特徴とする請求項４に記載の方法。
【請求項６】
特定のデータバインディングを削除するオブジェクトを返すメソッドを用いるステップをさらに含むことを特徴とする請求項４に記載の方法。
【請求項７】
プロパティを用いて、特定のデータバインディングが懸垂参照かどうかを調べるステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項８】
コンテンツ領域内のデータバインディングを作成または変更するオブジェクトを返すメソッドを用いるステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項９】
特定のリンクに対してターゲットＸＭＬノードを提供するステップをさらに含むことを特徴とする請求項８に記載の方法。
【請求項１０】
コンテンツ領域内にデータバインディングを作成するために使用される情報を表すオブジェクトを返すメソッドを用いるステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項１１】
リンクに対してＸＰａｔｈとＸＭＬデータとを提供するステップをさらに含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
コンピュータ実行可能命令を格納するコンピュータ可読媒体であって、前記コンピュータ実行可能命令は、コンピュータによって実行された場合に、前記コンピュータにデータバインディングインターフェースをエクスポーズさせ、
前記データバインディングインターフェースは、前記データバインディングインターフェースに関連付けられたメソッド、プロパティ、またはイベントをエクスポーズするように動作し、前記メソッド、プロパティ、またはイベントは、前記データバインディング、データ、または前記データバインディングに関連付けられた少なくとも１つのオブジェクトの操作を可能にするオブジェクトを返す
ことを特徴とするコンピュータ可読媒体。
【請求項１３】
前記データバインディングインターフェースは、特定のデータバインディングに関連付けられたＸＭＬデータを見つけるオブジェクトを返すように動作可能であることを特徴とする請求項１２に記載のコンピュータ可読媒体。
【請求項１４】
前記データバインディングインターフェースは、ＸＭＬデータ内でターゲットノードを見つけるオブジェクトを返すように動作可能であることを特徴とする請求項１２に記載のコンピュータ可読媒体。
【請求項１５】
前記データバインディングインターフェースは、特定のデータバインディングが懸垂かどうかを調べるオブジェクトを返すように動作可能であることを特徴とする請求項１２に記載のコンピュータ可読媒体。
【請求項１６】
前記データバインディングインターフェースは、コンテンツ領域内のデータバインディングを作成または変更するオブジェクトを返すように動作可能であることを特徴とする請求項１２に記載のコンピュータ可読媒体。
【請求項１７】
データストアとコンテンツ領域との間のリンクへのアクセスを提供するように動作可能なシステムであって、
データバインディングインターフェースを備え、
前記データバインディングインターフェースは、前記データバインディングインターフェースに関連付けられたメソッド、プロパティ、またはイベントをエクスポーズするように動作可能であり、前記メソッド、プロパティ、またはイベントは、前記データバインディング、データ、または前記データバインディングに関連付けられた少なくとも１つのオブジェクトの操作を可能にするオブジェクトを返すことを特徴とするシステム。
【請求項１８】
前記データバインディングインターフェースは、ＸＭＬデータ内でターゲットノードを見つけるオブジェクトを返すように動作可能であることを特徴とする請求項１７に記載のシステム。
【請求項１９】
前記データバインディングインターフェースは、コンテンツ領域内のデータバインディングを作成または変更するオブジェクトを返すように動作可能であることを特徴とする請求項１７に記載のシステム。
【請求項２０】
関連付けられたデータバインディングとの連係動作のコードを開発するためのインターフェースを提供するように、さらに動作可能であることを特徴とする請求項１７に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データをバインディング（結合）する情報処理技術に関する。
【背景技術】
【０００２】
マークアップ言語は、近年幅広い支持を受けている。マークアップ言語の一種である拡張可能マークアップ言語（ＸＭＬ）は、様々な種類のデータを識別、交換、処理する方法を提供する汎用言語である。例えば、ＸＭＬは、様々なアプリケーションプログラムで利用可能な文書を作成するために用いられる。ＸＭＬファイルの要素は、一般に、関連付けられた名前空間およびスキーマを有する。
【０００３】
名前空間は、ＸＭＬ文書において要素／属性の名前および型を定義するために用いられる名前の集合体に対する一意識別子である。名前空間の名前は、ＸＭＬ文書の各クラスを一意識別するためによく用いられる。一意の名前空間は、名前が同じでもソースが異なるマークアップ要素を区別する。
【０００４】
ＸＭＬスキーマは、ＸＭＬ環境においてデータを記述および検査する方法を提供する。スキーマは、ＸＭＬ文書において、どの要素および属性を用いてコンテンツを記述するか、各要素はどこで可能か、そこではどのようなタイプのコンテンツが可能か、および他のどの要素内にどの要素が含まれることが可能かを指定する。スキーマを用いると、文書が、一貫性のある予測可能な様式で構造化される。スキーマは、ユーザによって作成可能であり、一般に、ＸＭＬなどの関連付けられたマークアップ言語でサポートされることが可能である。ユーザは、ＸＭＬエディタを用いて、ＸＭＬファイルを操作することが可能であり、ユーザが作成したスキーマに付随するＸＭＬ文書を生成することが可能である。従来のワードプロセッサアプリケーションでは、カスタムＸＭＬスキーマのサポートがアプリケーションに追加されていて、ユーザはカスタムＸＭＬマークアップ（例えば、＜ｔｉｔｌｅ＞）を用いて文書のコンテンツに「タグ」を付けることが可能であった。タグ付けは、基本的に、それまで未格付けの一連のテキストであったものにセマンティクス上の意味を与える。このことは、それまで単なる書式付きテキストであって、他のアプリケーションで処理されることが無意味であった文書が、他の任意のＸＭＬ対応アプリケーションでの検索および認識が可能な、任意のユーザ定義ＸＭＬスキーマの中の特定のＸＭＬマークアップ断片を含む構造化ＸＭＬ文書になりうることを意味していた。
【０００５】
基本的な例を示すと、文書の先頭にあるテキストは、ユーザ定義ＸＭＬスキーマの中にある＜ｔｉｔｌｅ＞ＸＭＬ要素によってタイトルとして「タグ付け」されることが可能であり、このことは、他のＸＭＬ対応アプリケーションが、タグ付けされた範囲のテキストに「タイトル」が含まれることを容易に認識し、それを適切に抽出することが可能になることを意味する。これにより、バックエンド処理において、適切なセマンティクスおよびコンテキストを有する、文書の一部（例えば、＜ｔｉｔｌｅ＞（タイトル）であるテキスト）をインテリジェントに抽出することが可能になる。
【０００６】
ただし、従来のワードプロセッサアプリケーションに関連付けられる弱点は、カスタムＸＭＬマークアップの追加および持続性が文書の提示と結びついている事実にある。すなわち、既存の実施態様では、ワードプロセッサ文書のＸＭＬマークアップ（例えば、ＸＭＬ書式で表現された顧客納品伝票の細目）と、その、文書表面における提示（例えば、３つのパラグラフのプレーンテキストと、それに続く、特定の表スタイルを有する５列４行の表）との間には厳然たる結び付きがある。したがって、従来のワードプロセッサアプリケーションで表現されるＸＭＬデータは、それが提示と結びついているので、文書のコンテンツと完全に一致していなければならない例えば、納品伝票のＸＭＬスキーマが、＜ｄａｔｅ＞が＜ａｄｄｒｅｓｓ＞の前であり、＜ａｄｄｒｅｓｓ＞が＜ｐｈｏｎｅＮｕｍｂｅｒ＞の前であるように指定していれば、これら３つのＸＭＬ要素は、文書内で提示される順序と一致した順序で存在していなければならない。つまり、提示書式を変更する（例えば、＜ｄａｔｅ＞を囲んでいるテーブル行を移動する）場合は、その文書に含まれるＸＭＬデータの構造を変更することも必要になり、ソリューション開発者の側では、このデータが、関連付けられているＸＭＬスキーマの構造に合致していることを確認するステップが余計に必要になる。したがって、この文書のエンドユーザは提示を勝手に操作することができない。勝手に操作すると、データのセマンティクスも変わってしまい、そのデータのＸＭＬスキーマに違反する可能性があるからである。
【０００７】
さらに、従来のワードプロセッサアプリケーションの上位で開発されるソリューションは、バックエンドアプリケーションで用いられる文書に対してデータの読み出し／書き込みを行う場合には、提示の意味合いをより注意深く考慮する必要がある。したがって、例えば、太字のテキストのパラグラフがタイトルとしてタグ付けされたとすると、結果として従来のワードプロセッサアプリケーションで保存されるＸＭＬは、次のようになるであろう。
【０００８】
【表１】
2006190277.tif 000003
【０００９】
上述のように、カスタムＸＭＬタグは、その両側を、従来のワードプロセッサアプリケーションの専用ＸＭＬタグ（この例ではｗ：ｐ、ｗ：ｒなど）で囲まれる。つまり、このデータを処理しようとするＸＭＬ対応ソリューションは、（＜Ｔｉｔｌｅ＞要素を含む）自身のデータ書式だけを認識していればよいわけではなく、従来のワードプロセッサアプリケーションの書式の詳細も完全に認識していなければならない。それによって、ＸＭＬ対応ソリューションは、自身のデータの検索時に、従来のワードプロセッサアプリケーションの書式情報をトラバースして無視することが可能である。したがって、この種の実施態様では、依然としてユーザに何らかの要求が課される。なぜなら、文書内のテキストの外見を少々変更する（例えば、＜Ｔｉｔｌｅ＞要素のコンテンツをテーブルセル内へドラッグする、など）だけでも、それを囲む、ワードプロセッサのネイティブタグ内のカスタムＸＭＬタブの位置が大きく変わる可能性があるからである。したがって、プログラマ／コード開発者は、従来のワードプロセッサアプリケーションがカスタムＸＭＬ要素をどこに配置しようとしているかを提示に基づいて予想および認識し、様々な並べ替えをすべて処理するための追加コードを書く必要がしばしばある。つまり、結果のソリューションは、特定の従来のワードプロセッサアプリケーションの要求を処理する論理コードをかなり多く含む必要が依然としてある可能性がある。
【００１０】
従来のワードプロセッサアプリケーションに関して作業を行うプログラマ／コード開発者は、さらに、読み出しおよび書き込みの操作を検討する場合に文書のレイアウト書式の意味合いを考慮する必要がある。例えば、ユーザは、ユーザが企業報告書を書く際のシンプルな強調として、＜ＳｔｏｃｋＳｙｍｂｏｌ＞要素の値を取得し、それを用いて同じ文書の＜ＣｏｍｐａｎｙＮａｍｅ＞要素内に会社のフルネームを配置することを試みる場合がある。文書の整合性を維持するために、プログラマ／コード開発者は、文書における所望のデータの読み出しと書き込みの両方について、文書の現在のレイアウト書式を考慮しなければ、それらのアクションを実行する機能コードを書くことができなかった。例えば、ユーザは、文書に挿入された場合に所望の結果を生成する、従来のワードプロセッサアプリケーションの書式情報を構築するために、書き込む値がテーブルセルや箇条書きリストなどに入っているかどうかを知る必要があったであろう。これは、ワードプロセッサアプリケーションの提示のセマンティクスを認識するために追加コーディングが必要な別の潜在的理由である。
【００１１】
従来のワードプロセッサアプリケーションのさらに別の制限は、ＸＭＬ要素の編集動作が「脆弱」であると感じられる場合があることである。これは、部分的には、上述のように、ＸＭＬデータの構造が、ユーザ定義スキーマに基づいて、文書表面上のタグの位置によって決まるという事実によって、ＸＭＬ要素の編集動作が制限されることによる。そのことによって、いくつかの問題が生じる可能性がある。第１に、一般的なユーザ操作（例えば、セクション間でのコピー／貼り付け）によって、ＸＭＬ構造が変わり、文書が、関連付けられたＸＭＬスキーマに準拠しない表現になる可能性がある。第２に、そのようなワードプロセッサの実施態様では、顧客定義ＸＭＬスキーマに必要なすべての要素が、何らかの形で文書表面に含まれる必要がある。したがって、開発者は、文書表面には表現されないが、メタデータとしてさらに動作する、文書に関する追加情報を持ち運ぶ方法として、関連付けられるＸＭＬデータを作成することが困難な場合がある。そして第３に、文書表面においてセマンティクス上は不要な要素（例えば、混合内容をマークアップしない非リーフ要素）もそのようなワードプロセッサの実施態様に含める必要があり、そのために、一般的なユーザ操作によってＸＭＬデータが変わる可能性がさらに高まる。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
多くの場合、ＸＭＬデータ（例えば、メモ文書を含むデータ）を定義するスキーマは、複数の異種処理システム間でのＸＭＬデータの伝達を促進するために、単一の標準化団体によって厳密に定義される傾向にある。ただし、そのようにバックエンド通信を促進させると、人間が文書データを読み取り、編集することが可能であることがしばしば犠牲になり、ユーザがそのデータを認識および解析することが困難になる。例えば、ＸＭＬ標準では、ｄｄ−ｍｍ−ｙｙｙｙＴｈｈ：ｍｍ：ｓｓ．ｓｓｓｓなどのように日付の標準書式を定義することが可能である。ＸＭＬ対応アプリケーションで解析されるためには、すべての日付がこの書式で表現されていなければならない。明らかに、ユーザがこの書式を正確に入力することは困難であり、ユーザが日付を入力する場合の一般的な方法と相容れない可能性が高い（例えば、多くのロケールでは、ｄｄ−ｍｍ−ｙｙｙｙよりｍｍ−ｄｄ−ｙｙｙｙを用いるほうが一般的である）。
【００１３】
したがって、開発者が、ＸＭＬデータと、ワードプロセッサアプリケーションなどのアプリケーションでのそのようなデータの提示とを分離可能にする方法が必要である。
【課題を解決するための手段】
【００１４】
本発明の実施形態は、データと提示とが分離可能なワードプロセッサ文書を作成する、スキーマを含むワードプロセッサアプリケーションを提供する。より詳細には、ワードプロセッサ文書にデータを入力したり、ワードプロセッサ文書からデータを抽出したりすることが可能であり、これらのデータは、ワードプロセッサ文書の提示書式とは別の場所に格納される。本発明の実施形態によれば、このワードプロセッサアプリケーションのユーザは、ワードプロセッサ文書データの独立した保管場所を作成し、そのデータのコンテンツと提示表面との間にリンク（バインディング）を確立することが可能である。
【００１５】
本発明の実施形態によれば、オブジェクトモデルは、プログラミング環境においてコードを開発することを可能にする。コードを用いて、アプリケーション内の１つまたは複数のデータバインディングを操作することが可能である。さらに、ＸＭＬデータのコンテンツ領域またはノードの、両方向の変化に反応するコードを、プログラミング環境において開発することが可能である。ファイルコンテンツとデータストア内のコンテンツとの間の関係を定義するコードを開発することが可能である。さらに、ファイルの境界領域内またはデータストア内の変化に反応して、編集、追加、削除などのイベントをトラップまたはインターセプトするコードを開発することが可能である。本発明の実施形態によれば、ユーザが、関連付けられたＸＭＬでコードを一度書くだけで、そのコードは、ターゲットアプリケーションの正確なセマンティクスを意識することなく、ＸＭＬ構造体の使用をサポートするファイルタイプに移植することが可能になり、それによって、アプリケーション開発が大幅に簡略化かつ合理化される。
【発明を実施するための最良の形態】
【００１６】
本明細書および特許請求項を通して、以下の用語は、文脈上明らかに別の意味でない限り、以下の内容に明示的に関連付けられる意味をとる。
【００１７】
用語「データ」は、ワードプロセッサ文書によって運ばれるか、参照されるか、使用される、任意の補足情報を意味する。この情報は、大きいことが多く、その全体が文書の提示層に露出されることはまずない。
【００１８】
用語「マークアップ言語」または「ＭＬ」は、文書内にあって、文書の各部分がアプリケーションによってどのように解釈されるべきかを指定する特殊なコードのための言語を意味する。ワードプロセッサファイルでは、マークアップ言語は、テキストがどのように書式化またはレイアウトされるべきかを指定する。
【００１９】
用語「要素」は、ＸＭＬ文書の基本単位を意味する。要素は、ＸＭＬ文書の属性、他の要素、テキスト、および他のコンテンツ領域を含むことが可能である。
【００２０】
用語「提示」は、文書の可視部分、すなわち、文書が印刷された場合に見えているであろうテキストおよびレイアウトを意味する。
【００２１】
用語「タグ」は、文書に挿入されて、ＸＭＬ文書内の要素を説明する文字を意味する。各要素は、タグを２つだけ有することが可能である。すなわち、開始タグと終了タグである。（コンテンツがない）空要素を有することも可能であり、その場合は、タグが１つでもよい。
【００２２】
タグとタグとにはさまれたＸＭＬコンテンツは、要素の「子」（または子孫）と見なされる。そこで、要素のコンテンツに埋め込まれた他の要素を「子要素」または「子ノード」または要素と呼ぶ。要素のコンテンツに直接埋め込まれたテキストは、要素の「子テキストノード」と見なされる。要素内の子要素とテキストとは、ともに、その要素の「コンテンツ」を構成する。
【００２３】
用語「属性」は、特定の値に設定され、要素に関連付けられた追加特性を意味する。要素は、それらに関連付けられた、（ゼロを含む）任意の数の属性設定を有することが可能である。属性は、追加要素を含まない要素か、テキストノードとして扱われる要素に追加情報を関連付けるために用いられる。
【００２４】
用語「コンテンツ領域」は、ユーザによって入力されたコンテンツのタイプのコンテナとして動作する、境界を定められた、かつ／または、任意にラベル付けされた、文書の領域を意味する。そのすべてが参照により本明細書に組み込まれている、本願の譲受人による２００４年９月３０日申請、「Methods, System, and Computer-Readable Medium For Managing Specific Types of Content In An Electronic Document」米国特許出願第１０／９５５６１２号明細書を参照されたい。
【００２５】
「ＸＰａｔｈ」は、パターン式を用いてＸＭＬ文書内のノードを識別する演算子である。ＸＰａｔｈパターンは、ＸＭＬ文書内のパスを記述する、スラッシュで区切られた、子要素名のリストである。パターンは、パスに対応する要素を「選択」する。
【００２６】
用語「ＸＭＬデータストア」は、ワードプロセッサ文書内にあって、ファイルが開いている間に、ワードプロセッサ文書内に保存されている（例えば、ＸＭＬ書式の）データの記憶および修正のためのアクセスを提供するコンテナを意味する。
【００２７】
用語「データバインディング」は、ワードプロセッサ文書内のＸＭＬデータの１つまたは複数の断片における、コンテンツ領域のコンテンツを格納することが可能な、ＸＰａｔｈの場所を決定する、コンテンツ領域に関する特性を意味する。本明細書では以下のように用いる。
【００２８】
「ｒｅｆ」−  個々のバインディングによって用いられる後続の特性の集合の中央保管場所を参照するための一意の整数を意味する（ファイル中の文書を開く場合／文書をファイルに保存する場合に用いられる）。
【００２９】
「ＩＤ」−  ＸＭＬデータストア内の特定のＸＭＬデータを指定する一意のＩＤを意味する。
【００３０】
「ｓｅｌｅｃｔｉｏｎＮａｍｅｓｐａｃｅｓ」−  ＸＭＬデータストア内の関連付けられたＸＭＬ文書に関するプレフィックスマッピング（名前空間を短縮形に関連付けるマッピング）を意味する。
【００３１】
「ｒｏｏｔＵＲＩ」−  ＸＭＬデータストア内の関連付けられたＸＭＬ文書のルート名前空間を意味する。
【００３２】
例示的動作環境
本発明の実施形態は、ＸＭＬデータと提示の記憶場所の分離が可能なワードプロセッサ文書を作成するワードプロセッサアプリケーションを提供する。より詳細には、ワードプロセッサ文書に入力されたり、ワードプロセッサ文書から抽出されたりすることが可能なデータを、ワードプロセッサ文書の提示書式とは別の場所に格納する。したがって、このワードプロセッサアプリケーションのユーザは、ワードプロセッサ文書内に含まれるＸＭＬデータの独立した記憶場所を作成することが可能であり、そのデータのコンテンツと提示表面との間にリンク（バインディング）を確立することが可能である。これにより、ユーザは、提示のコンテンツを編集することによって、関連付けられたＸＭＬデータを編集することが可能になるが、同様に、ユーザは、関連付けられたＸＭＬデータの構造を変更することが不可能になる。例えば、納品伝票のデータを、ワードプロセッサファイル書式のＸＭＬとして独立に保存できるので、文書内でリンクの場所を移動しても、独立したデータストアの構造は変わらない。したがって、この構造化データは、ユーザが文書をどのように編集するかに左右されない既知の構造を有するため、バックエンド処理がより容易になる。ユーザは、ワードプロセッサ文書において、データの編集、リッチ提示書式を含むデータの書式化などを行うことができ、テキストコンテンツの変更内容だけが、文書の背後に保存されているＸＭＬデータに「プッシュ」バックされる。ただし、本発明によれば、ユーザとワードプロセッサ文書との対話によって作成されている、更新されたデータはすべて、ＸＭＬのオリジナルネイティブストリームの形で使用可能である。したがって、本発明によれば、リンクされたＸＭＬデータを直接変更することによってワードプロセッサ文書のコンテンツを修正することも可能であり、その場合は、前述のとおり常に変化している可能性のある、そのデータの複雑な提示書式に関わる必要はない。これにより、ワードプロセッサ文書内での構造化データの追加、編集、抽出が大幅に簡略化される。
【００３３】
図１に示されるように、本発明を実施する一例示的システムは、コンピューティング装置１００のようなコンピューティング装置を含む。非常に基本的な構成では、コンピューティング装置１００は、一般に、少なくとも１つの処理ユニット１０２とシステムメモリ１０４とを含む。コンピューティング装置の厳密な構成およびタイプに応じて、システムメモリ１０４は、揮発性（ＲＡＭなど）、不揮発性（ＲＯＭ、フラッシュメモリなど）、または両者の何らかの組合せであってよい。システムメモリ１０４は、一般に、オペレーティングシステム１０５、１つまたは複数のアプリケーション１０６を含み、プログラムデータ１０７を含むことが可能である。一実施形態では、アプリケーション１０６は、ワードプロセッサアプリケーション１２０を含むことが可能である。これらの基本的な構成は、図１では、破線１０８内のコンポーネントで示されている。
【００３４】
コンピューティング装置１００は、さらに特徴または機能性を有することが可能である。例えば、コンピューティング装置１００はさらに、（リムーバブルおよび／または非リムーバブルの）補助データ記憶装置（例えば、磁気ディスク、光ディスク、テープなど）を含むことが可能である。そのような補助記憶装置は、図１では、リムーバブル記憶装置１０９および非リムーバブル装置１１０で示されている。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造体、プログラムモジュール、他のデータなどの情報を記憶する任意の方法または技術において実装される揮発性および不揮発性、リムーバブルおよび非リムーバブルの媒体を含むことが可能である。システムメモリ１０４、リムーバブル記憶装置１０９、および非リムーバブル記憶装置１１０は、すべて、コンピュータ記憶媒体の例である。コンピュータ記憶媒体として、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリテクノロジ、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、または他の磁気記憶装置、または他の任意の、所望の情報を格納するために使用可能であってコンピュータ装置１００からのアクセスが可能である媒体が含まれ、これらに限定されない。そのようなコンピュータ記憶媒体のどれもが、装置１００の一部になりうる。コンピュータ装置１００はさらに、キーボード、マウス、ペン、音声入力装置、タッチ入力装置などの入力装置１１２を有することが可能である。ディスプレイ、スピーカ、プリンタなどの出力装置１１４も含まれることが可能である。これらの装置は当該技術分野において周知であるので、本明細書で長々と説明する必要はない。
【００３５】
コンピューティング装置１００はさらに、ネットワークを経由するなどして、他のコンピューティング装置１１８と通信するための通信接続１１６を含むことが可能である。通信接続１１６は、通信媒体の一例である。通信媒体は、一般に、搬送波などの変調データ信号や他の搬送メカニズムの形でのコンピュータ可読命令、データ構造体、プログラムモジュール、または他のデータによって実施されることが可能であり、任意の情報配信媒体を含む。用語「変調データ信号」は、その１つまたは複数の特性が、信号内の情報をエンコードするように設定または変更される信号を意味する。例えば、通信媒体は、有線ネットワークや直接有線接続などの有線媒体と、音響、ＲＦ、赤外線、その他の無線媒体とを含み、これらに限定されない。本明細書で用いられる用語「コンピュータ可読媒体」は、記憶媒体と通信媒体の両方を含む。
【００３６】
コンピューティング装置１００のシステムメモリ１０４には、いくつかのプログラムモジュールおよびデータファイルを保存することが可能であり、これには、ネットワーク接続されたパーソナルコンピュータの動作の制御に好適なオペレーティングシステム１０５（ＭＩＣＲＯＳＯＦＴ  Ｃｏｒｐｏｒａｔｉｏｎ  ｏｆ  Ｒｅｄｍｏｎｄ、ＷａｓｈｉｎｇｔｏｎのＷＩＮＤＯＷＳ（登録商標）ＸＰオペレーティングシステムなど）が含まれる。システムメモリ１０４はさらに、ワードプロセッサアプリケーション１２０などの１つまたは複数のプログラムモジュールと、後述する他のものとを格納することが可能である。ワードプロセッサアプリケーション１２０は、電子文書を作成、編集、処理する機能性を提供するように動作可能である。
【００３７】
本発明の一実施形態によれば、ワードプロセッサアプリケーション１２０は、ＭＩＣＲＯＳＯＦＴ  Ｃｏｒｐｏｒａｔｉｏｎ製のＷＯＲＤプログラムを含む。しかしながら、他の製造元によるワードプロセッサアプリケーションプログラムも、本発明の様々な態様を実施するために利用可能であることを理解されたい。さらに、本発明の様々な態様は、ワードプロセッサアプリケーションプログラム向けに限定されず、様々な形式のコンテンツ（例えば、テキスト、イメージ、ピクチャなど）を処理することが可能な他のアプリケーションプログラム１０６（スプレッドシートアプリケーションプログラム、データベースアプリケーションプログラム、プレゼンテーションアプリケーションプログラム、ドローイングアプリケーションプログラム、コンピュータ支援アプリケーションプログラムなど）も利用可能であることを理解されたい。
【００３８】
本発明の実施形態は、コンピュータプロセスとして、コンピューティングシステムとして、あるいは、コンピュータプログラム製品やコンピュータ可読媒体のような製造物として実施されることが可能である。コンピュータプログラム製品は、コンピュータシステムによって可読なコンピュータ記憶媒体であって、コンピュータプロセスを実行する命令のコンピュータプログラムをエンコードしたものであることが可能である。コンピュータプログラム製品はまた、コンピュータシステムによって可読な、キャリア上の伝搬信号であって、コンピュータプロセスを実行する命令のコンピュータプログラムをエンコードしたものであることも可能である。
【００３９】
ワードプロセッサアプリケーションにおけるデータのバインディング
図２は、本発明の実施形態を実施するための例示的環境を示すブロック図である。図２に示される例示的環境は、ワードプロセッサ環境２００であって、これは、ワードプロセッサアプリケーション２０２と、ワードプロセッサ文書２０４と、プログラミング環境２０６と、データストア２０８と、スキーマファイル２１０と、ＸＭＬ処理モジュール２１２とを含む。しかし上述のように、本発明は、様々な形式のコンテンツ（例えば、テキスト、イメージ、ピクチャなど）を処理することが可能な他のアプリケーションプログラム１０６（スプレッドシートアプリケーションプログラム、データベースアプリケーションプログラム、プレゼンテーションアプリケーションプログラム、ドローイングアプリケーションプログラムまたはコンピュータ支援アプリケーションプログラムなど）にも適用可能である。プログラミングモジュール２０６は、ＸＭＬ処理モジュール２１２のためのシンプルなアプリケーションプログラミングインターフェース（ＡＰＩ）を提供することが可能であり、これによって、文書２０４のコンテンツまたはＸＭＬデータストア２０８のコンテンツを修正するコードの開発が可能になる。本発明は、本明細書に記載の特定の実施形態または実施例に限定されることを意図したものではないことが理解されよう。例えば、このワードプロセッサ環境は、複数のワードプロセッサ文書２０４、データストア２０８、および／またはスキーマファイル２１０を含むことが可能である。本発明の実施形態によれば、ＸＭＬ処理モジュール２１２は、拡張可能マークアップ言語に従って書式化されたデータを処理するために、ワードプロセッサアプリケーション２０２によって用いられる。好適なＸＭＬ処理モジュール２１２は、ＭＩＣＲＯＳＯＦＴ  Ｃｏｒｐｏｒａｔｉｏｎ  ｏｆ  Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎによって製造および販売されるＭＳＸＭＬである。
【００４０】
ワードプロセッサアプリケーション２０２は、自身の１つまたは複数の名前空間と、ワードプロセッサアプリケーション２０２に関連付けられた１つまたは複数の文書２０４に用いられるために定義されたスキーマ２１０またはスキーマの集合とを含む。ワードプロセッサアプリケーション２０２のためにスキーマ２１０によって定義されるタグおよび属性の集合は、文書２０４の書式を定義する。後述されるとおり、かつ、本発明の実施形態によれば、データストア２０８は、データ２０９を含むことが可能である。スキーマ２１０は、データストア２０８内でデータ２０９にアタッチされることが好ましい。ワードプロセッサ文書２０４はさらに、後述されるようにユーザによって作成されたコンテンツ領域２０７も含む。複数のデータストア２０８、関連付けられたＸＭＬデータ２０９、およびスキーマ２１０を、ワードプロセッサアプリケーション２０２の一部として含めることが可能である。所与のＸＭＬデータ２０９に含めることが可能なデータの型および構造を管理する文法規則およびデータ型規則の集合をＸＭＬデータ２０９に与えるために、ユーザが所与のＸＭＬデータ２０９に注釈を付ける場合に用いるＸＭＬ要素およびＸＭＬタグのそれぞれを管理する規則を与える１つまたは複数のＸＭＬスキーマ２１０を、ＸＭＬデータ２０９に関連付けることが可能である。スキーマ２１０は、それらの要素がＸＭＬデータ２０９に適用される場合の順序を管理する規則と、ＸＭＬデータ２０９に適用される個々の要素に関連付けられた特定の規則とを含む。
【００４１】
本発明の実施形態は、ワードプロセッサ文書とともに保存される独立したデータストア２０８の存在によってデータと提示とを分離することが可能なワードプロセッサ文書２０４を作成するように動作可能なワードプロセッサアプリケーション２０２を提供する。より詳細には、ワードプロセッサ文書２０４に入力されたり、ワードプロセッサ文書２０４から抽出されたりすることが可能なデータを、その文書のデータストア２０８内の１つまたは複数のＸＭＬデータ２０９ファイルに格納することによって、ワードプロセッサ文書２０４の提示書式からデータを分離する。したがって、ワードプロセッサアプリケーション２０２のユーザは、ワードプロセッサ文書２０４のデータの独立した記憶場所を作成することが可能であり、そのデータのコンテンツと提示表面２０３との間に、１つまたは複数のコンテンツ領域２０７に関連付けられたリンク（バインディング）２０５を確立することが可能である。これにより、ユーザは、提示のコンテンツを編集することによって、データを編集することが可能になるが、同様に、ユーザは、データ２０９の構造を変更することが不可能になる。文書２０４内でコンテンツ領域２０７の場所を移動しても、独立したデータストア２０８にあるＸＭＬデータ２０９の構造は変わらない。さらに、データの提示（太字、斜体、位置合わせなど）を変更しても、データ構造には影響しない。したがって、この構造化データは、バックエンド処理が簡略化される。それは、ＸＭＬデータ２０９が、ユーザが文書２０４をどのように編集するかに影響されない既知の構造に対応するためである。
【００４２】
本発明の実施形態によれば、リンクされたデータを直接変更することによってワードプロセッサ文書２０４のコンテンツを修正することが可能であり、その場合は、常に変化している可能性のある、複雑な提示書式に関わる必要はない。これにより、ワードプロセッサ文書２０４内での構造化データの追加、編集、抽出が大幅に簡略化される。さらに、構造化ＸＭＬデータ２０９にバインドされているデータバインディング２０５を、データの構造に影響を及ぼすことなく、文書２０４内で移動することが可能である。コンテンツ領域２０７内のデータバインディング２０５は、ユーザインターフェースまたはプログラミングウィンドウ２０６で定義可能なＸＰａｔｈ式を用いて有効化されることが好ましい。
【００４３】
ユーザは、ＸＰａｔｈ式（ＸＭＬツリー内でノード２１３を識別する、標準的なＸＭＬメソッド）を用いて、文書コンテンツ領域がバインドされる、所望のＸＭＬノード２１３を一意識別する。ワードプロセッサアプリケーション２０２は、データバインディング領域に対する所望のターゲットへのＸＰａｔｈを自動的に解析および使用するよう動作する。このことはさらに、ＸＰａｔｈ標準に慣れている開発者であれば、このＸＭＬの使い道を活用して、半動的な性質を有するデータバインディング２０５を作成することが可能であることを意味する。すなわち、データ２０９に対する別の変更または提示２０３に対する変更に基づいて別のターゲットノード２１３を識別すること。例えば、ユーザが、所定の期間に最も多くの売上を達成した社員の名前を表示したいとする。この情報が、文書２０４に関連付けられたＸＭＬデータ２０９内にあった場合、ユーザは、最多数の完了明細書を有する個人の名前にリンクするＸＰａｔｈ式を作成することが可能であり、そのリンクは、データが変化するにつれて自動的に該当場所（ノード２１３）に移動する。また、コード２１１の使用、ユーザインターフェース、またはプログラミング環境２０６により、このリンクをノード２１３間で変更することも可能である。
【００４４】
代替として、ユーザは、データ２０９内の、文書コンテンツ領域２０７がバインドされることが可能なノード２１３を表すオブジェクトを一意識別するデータバインディングを作成することが可能である。ワードプロセッサアプリケーション２０２は、データバインディング領域に対する所望のターゲットへのＸＰａｔｈを自動的に決定するよう動作する。ただし、これは、この場合には、データバインディング２０５が、同じＸＰａｔｈ式に対して同じオブジェクトを確実にポイントするように、データバインディング２０５がそのＸＰａｔｈを自動的に更新されるようにしていることを意味する。
【００４５】
前に簡単に触れたように、プログラミングコード２１１は、ＸＭＬ処理モジュール２１２を利用するために開発されることが可能であり、いずれの方向（すなわち、文書表面２０３のコンテンツ領域２０７からデータストア２０８のＸＭＬデータ２０９内のノード２１３への方向、およびその逆の方向）の移動による変化にも反応することが可能である。ユーザは、データストア２０８内で文書表面２０３と特定コンテンツとの間の関係を定義するコード２１１を開発することが可能である。さらに、文書２０４の境界領域内またはデータストア２０８内での変化に反応して、編集、追加、削除などのイベントをトラップまたはインターセプトするコード２１１を開発することが可能である。例えば、ユーザが、特定のタイトルを使用できる文書の数をせいぜい１つにしたいと考えているとする。タイトルノードに入力された内容に基づくコード２１１は、そのタイトルが既に使用されていないかどうかを中央データベースに照会することが可能である。そのタイトルが取得されている場合、コード２１１は、ユーザに対して、別のタイトルの入力を促すか、そのタイトルが使用不可であることを伝えるか、またはその両方を行うことが可能である。本発明の実施形態によれば、ユーザが、関連付けられたＸＭＬでコード２１１を一度書くだけで、そのコードは、ターゲットアプリケーションの正確なセマンティクスを意識することなく、ＸＭＬ構造体の使用をサポートするすべての文書タイプに移植することが可能になり、それによって、アプリケーション開発が大幅に簡略化かつ合理化される。
【００４６】
本発明の実施形態によれば、ワードプロセッサ文書２０４は、テキストの特定領域のセマンティクスを表現するコンテンツ領域２０７（例えば、Ｔｉｔｌｅ、Ｂｏｄｙなど）によってタグ付けされることが可能であり、データバインディング２０５を追加することによって、そのコンテンツ領域２０７の中の関連付けられたテキストが、文書２０４内のデータストア２０８にある特定のＸＭＬデータ２０９の内部のノード２１３に格納される。データ２０９は、文書内のコンテンツ領域２０７、すなわち、１つまたは複数のデータバインディング２０５を用いてタグ付けされた領域にリンクされる。したがって、データ２０９は、提示２０３内の関連付けられたコンテンツ、すなわち、ユーザが特定の文書の編集時に対話する、文書２０４のデジタル表現（例えば、特定のユーザ文書を描画するＷＯＲＤウィンドウ）をデータバインディング２０５がどこに配置するか、またはそのデータ２０９がどのように提示されるかに関係なく、自身のＸＭＬストリーム内の一貫した場所（「データストア」）に格納されることが可能である。したがって、ＸＭＬデータ２０９が、データストア２０８内で一貫した場所に配置されるので、ユーザは、文書２０４内を移動するデータを意識する必要がない。さらに、データストア２０８は、文書２０４内でデータバインディング２０５によって参照されていないデータ２０９も格納することが可能である。「エクストラ」データ（メタデータなど）は、ソリューション開発者などのユーザに、文書ユーザにとっては関係のない補助情報を提供する。
【００４７】
本発明の実施形態によれば、データの構造は、独立した場所（文書のデータストア２０８内のＸＭＬデータ２０９の１つまたは複数の断片）で保管されるので、ユーザは、データ構造に影響を及ぼすことなく、提示２０３内でリンク（すなわち、データバインディング２０５）を移動することが可能である。したがって、ＸＭＬデータ２０９の構造は変化せず、ワードプロセッサ文書２０４に関連付けられたＸＭＬデータ２０９の提示だけが変化する。したがって、文書２０４内のデータ提示の書式を変更しても、データストア２０８の構造には影響しない。ユーザが文書表面２０３を操作しても、実際のデータ２０９は動かない。したがって、ユーザは、（ストア２０８に独立して維持されている）データ２０９への悪影響を心配することなく、提示を完全に管理することが可能である。したがって、本発明の実施形態によれば、ユーザは、提示情報とは別のカスタムＸＭＬ情報にアクセスすることが可能である。
【００４８】
１つまたは複数のデータバインディング２０５を用いて、データソースのコンテンツ（データストア２０８内のＸＭＬデータ２０９）（本明細書ではＸＭＬデータ２０９と呼ぶ）を文書２０４内の場所に「バインド」することが可能である。ＸＭＬデータ２０９は、本明細書で用いられているように、テキスト（プレーンまたはリッチフォーマット）、イメージ、特定タイプのコンテンツ（日付）など、任意のタイプのコンテンツを含む。データバインディング２０５の構造は、ＸＰａｔｈリンクとして記述されることが可能であり、これによって、ワードプロセッサアプリケーション２０２は、文書２０４に関連付けられたＸＭＬデータストア２０８にあるＸＭＬノード２１３に接続し、これに同期し、リンクを持続することが可能である。ＸＭＬデータストア２０８は、文書２０４の一部であることが最も好ましい（すなわち、ストア２０８はワードプロセッサファイルとともに保存され、特定の文書２０４とともに移動するか、特定の文書２０４に関連付けられることが最も好ましい）。データバインディング２０５はさらに、提示（例えば、ワードプロセッサの文書表面２０３）とデータストア２０８との間でデータ２０９をどのように変換するかを管理する情報を含むことが可能である。ワードプロセッサアプリケーション２０２のユーザは、データストア２０８に格納されるデータ２０９（バックエンドアプリケーションによって操作されるデータ）が標準書式で保存されることを許可することが可能であり、その一方で、ワードプロセッサ文書２０４内の同じ情報をよりフレンドリな書式で提示することが可能である（例えば、ユーザに対してはＪａｎｕａｒｙ  ２９、２００４と表示されるが、データは、２９−０１−００４Ｔ１２：００：００．００００のようにｄａｔｅＴｉｍｅ書式で保存される）。別の例として、データバインディング情報は、イメージを格納することが可能である。このイメージは、データ２０９に対しては、一見無意味な文字列として表現されるが、前述した変換原理と同様に、ユーザに対しては、ワードプロセッサ文書２０４のコンテンツ領域２０７にあるイメージとして表示される。ユーザは、このイメージを追加／変更することが可能であり、ＸＭＬエンコードされた表現はＸＭＬデータ２０９まで持続されるので、すべてのバックエンドプロセスがその情報を保存／操作することが可能である。
【００４９】
実施形態によれば、ユーザは、データバインディング情報２０５をコンテンツ領域２０７に追加する場合に、ＸＰａｔｈ式を指定することによって、対象の（例えば、１つまたは複数のノード２１３を識別する）リンクされたＸＭＬデータ２０９を提供する。このコンテンツ領域２０７のコンテンツは、いったんバインドされれば、そのＸＰａｔｈで返されるノード２１３のコンテンツ（ＸＭＬデータ）にリンクまたはバインドされる。このことは、結果として、ＸＰａｔｈによって返されるＸＭＬノード２１３が変化するようにＸＭＬノード２１３が追加／削除／変更されると、文書２０４内のコンテンツ領域２０７のコンテンツが自動的に更新されることを意味する。あるいは、変更が発生した結果として特定のデータバインディング２０５によって返されるノード２１３がない場合は、データバインディング２０５が、後述する「懸垂参照」状態になる。
【００５０】
例えば、文書２０４が以下のパラグラフを含むとする。ここで、「Ｍｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎ」は、その文書のデータストア２０８内で、あるリンクされたＸＭＬデータ２０９内のＸＰａｔｈ／ｃｏｎｔｒａｃｔ（１）／ｈｅａｄｅｒ（１）／ｃｏｍｐａｎｙ（１）にバインドされたプレーンテキストコンテンツ領域２０７（斜体で示されている）に対応する。提示２０３に表示されるパラグラフは次のとおりである。
【００５１】
【表２】
2006190277.tif 000004
【００５２】
一実施形態によれば、プログラミング環境２０６において、（例えば、）次の単一行のコードを指定することによってリンクをセットアップすることが可能である。
【００５３】
【表３】
2006190277.tif 000005
【００５４】
対応する、リンクされたＸＭＬデータ２０９は次のようになるであろう（一重引用符で示されたノード２１３にリンクされている）。
【００５５】
【表４】
2006190277.tif 000006
【００５６】
今度は、ユーザがデータストア２０８  ＡＰＩを用いて、新しい＜ｃｏｍｐａｎｙ＞ノード２１３を、＜ｈｅａｄｅｒ＞の第１の子として追加するとする（新しいノード２１３は一重引用符で示されている）。
【００５７】
【表５】
2006190277.tif 000007
【００５８】
コンテンツ領域２０７内の結果のバインディング２０５は、同じＸＰａｔｈ（「／ｃｏｎｔｒａｃｔ（１）／ｈｅａｄｅｒ（ｌ）／ｃｏｍｐａｎｙ（１）」）にバインドされたままなので、文書コンテンツは、次のように、ただちにそのノード２１３の新しいコンテンツを表示するように更新される。
【００５９】
【表６】
2006190277.tif 000008
【００６０】
本発明によれば、コンテンツ領域２０７にバインドされたデータがワードプロセッサ文書２０４の１つまたは複数の領域に格納されている場合、文書２０４は、リンクされたコンテンツのどのソースの変化にも反応する。したがって、一連の文書２０４が、バインドされたデータである場合は、関連付けられたＸＭＬデータ２０９内のＸＭＬノード２１３のコンテンツを変更すると、コンテンツ領域２０７のテキストが自動的に変更される。これに対応して、一連の文書２０４が、バインドされたデータである場合に、文書２０４内のそのバインドされたコンテンツ領域２０７のテキストを変更すると、対応するＸＭＬデータ２０９にあるＸＭＬノード２１３のコンテンツが自動的に変更される。すなわち、同一バインディング２０５を有する複数のコンテンツ領域２０７が、文書２０４内の複数の場所に存在することが可能である。例えば、名前へのデータバインディング２０５を有するコンテンツ領域２０７を、文書２０４のヘッダならびにボディに追加することが可能である。これらの場所のいずれかを変更すると、そのテキストがＸＭＬデータストア２０８に同期し、この変更が、そのノード２１３へのデータバインディング２０５を有するコンテンツ領域２０７が存在する、文書２０４内のすべての場所に反映される。
【００６１】
ＸＭＬデータ２０９内のＸＭＬノード２１３は、文書２０４との間に一対多関係を有することが可能であり、このことは、ＸＭＬデータ２０９内の同じＸＭＬノード２１３が複数のデータバインディング２０５によって参照されることが可能であることを意味する。文書２０４内の、データがバインドされているコンテンツ領域２０７が更新されると必ず、ＸＭＬデータ２０９内の該当するＸＭＬノード２１３が変更され、これによって、文書２０４内の他のコンテンツ領域２０７にある、他のすべての関連付けられたバインディング２０５が新しいテキストによって更新される。例えば、文書２０４のヘッダにあるコンテンツ領域２０７が、あるＸＭＬデータ２０９内の＜ｔｉｔｌｅ／＞ノードのＸＰａｔｈ式を指定するデータバインディング２０５を含み、文書２０４のボディにある別のコンテンツ領域２０７も、その同じ要素へのデータバインディング２０５を含むとする。本発明によれば、それらの書式が異なる可能性があっても、両方とも同じコンテンツを表示する。ユーザが、文書２０４のボディにあるコンテンツ領域２０７のコンテンツを編集した場合、その更新は、データストア２０８内の該当するＸＭＬデータ２０９内の該当するＸＭＬノード２１３まで持続され、これによって、やはりそのＸＭＬノード２１３を指定する、文書２０４内の（例えば、ヘッダ内、フッタ内などにある）関連付けられたバインディング２０５を有する他のすべてのコンテンツ領域２０７が更新される。本発明の実施形態は、文書内の複数の場所をデータストア２０８内の単一ＸＭＬノード２１３にバインドし、それによって、それら３つのすべての場所のコンテンツをデータの単一ソースにリンクするメカニズムを提供する。したがって、ＸＭＬデータ２０９内の同じノード２１１にリンクされる、文書２０４内のすべてのコンテンツ領域２０７のコンテンツは同一である。
【００６２】
このことの具体例は、一般的な報告文書である。報告文書では、ユーザは、複数の場所にタイトルを表示させるのが普通である。すなわち、（大きな太字で）表紙に表示させたり、（小さな文字で）ヘッダに表示させたり、（小さな斜体文字で）フッタに表示させたりするであろう。通常、ユーザは各場所にタイトルを手入力しなければならず、それら３つの場所のいずれかでタイトルを変更した場合には、（コンテンツの一貫性を保つために）他の２か所でも変更することを忘れないようにする。しかしながら、これら３つの場所すべての同期を保つことは、あまりにも忘れやすい。本発明の実施形態によれば、ユーザが文書２０４内で表示させたいＸＭＬデータ２０９を含むデータストア２０８がしかるべき場所にあれば、文書内の複数の場所（例えば、上述の３つの場所）はすべて、データストア２０８内の単一のＸＭＬノード２１３にデータがバインドされたコンテンツ領域２０７であることが可能である。
【００６３】
したがって、３つの場所すべてのコンテンツが、単一ソースであるデータ２０９にリンクまたはバインドされる。このことは、ユーザが３つの領域のうちのいずれか１つ（例えば、表紙）のコンテンツを変更すると、そのユーザのテキストが、内在するＸＭＬデータ２０９に自動的にプッシュされ、次に、対応するデータバインディング２０５を有するコンテンツ領域２０７を有する、文書２０４内の他の場所（ここではヘッダとフッタ）にプッシュされることを意味する。これは、ユーザが、文書との対話のみによって、それら３つの領域のコンテンツを、それらすべてが同一であるようにリンクまたはバインドしたことを意味する。本発明の実施形態によれば、文書の各領域は複数の様式（大きな太字、小さな斜体、その他）で提示されることが可能であるが、データストア２０８内のデータ構造は同じままである。
【００６４】
懸垂参照
本発明の実施形態によれば、ユーザは、ターゲットがないＸＰａｔｈ式を指定することも可能である。すなわち、ユーザの指定したターゲットＸＭＬノード２１３がデータストア２０８内のＸＭＬデータ２０９に存在しないことも可能である。データバインディング２０５は、その目的のターゲットノード２１３を「忘れる」のではなく、「待ち」状態に入り、この状態では、どの特定のＸＭＬデータ２０９にも接続されず、補助ＸＭＬデータストア２０８内のＸＭＬデータ２０９に目的のノード２１３が現れるのを待つ。これは特に、文書を組み合わせてまとめる場合に有効である。この場合は、文書２０４の各部分（例えば、標準的な表紙、最終ページ、流用条項など）がデータバインディング２０５を含むことが可能であり、データバインディング２０５は、各部分が単一の最終文書２０４に組み合わせられたときにのみ埋められる。この場合、文書作成者は、各文書「部分」内のコンテンツ領域２０７内で、ＸＭＬデータ２０９内の、その部分に存在していなかったＸＭＬノード２１３へのデータバインディング２０５を指定する（例えば、表紙であれば、＜Ｔｉｔｌｅ／＞ＸＭＬ要素や＜Ｄａｔｅ／＞ＸＭＬ要素へのバインディング２０５を有するコンテンツ領域を含むであろう）。それらの部分をその最終文書以外のところで表示しても、ＸＭＬデータ２０９が存在しないために、それらのバインディングは接続されないが、目的のデータ２０９を含んでいる文書にそれらの部分を加えると、データバインディング２０５がただちにデータ２０９に接続（同期）され、正しいコンテンツが表示される。これにより、文書作成者は、データ２０９がまだ作成されていなくても、バインディング２０５を指定し、それを保存することが可能である。
【００６５】
１つのタイプの懸垂参照２１５は、コンテンツ領域２０７内のデータバインディング２０５が、リンクされたＸＭＬストリーム内のノード２１３に正常にリンクできない場合に（すなわち、コンテンツ領域内のバインディングの一状態）発生する。ノード２１３が、リンクされたＸＭＬストリームにおいて置き換えられたか、削除された場合は、結果として、１つまたは複数のデータバインディング２０５が懸垂参照２１５になる可能性がある。データバインディング２０５がそのＸＰａｔｈに起因する懸垂参照２１５を有する場合、ワードプロセッサアプリケーション２０２は、データバインディング２０５内のノード２１３について最後に知られたＸＰａｔｈを保存し続けることが好ましい。これは、ＸＰａｔｈがどのノード２０９も解決しなくなった場合に発生する可能性がある。データストア２０８が、あるＸＭＬデータ２０９の更新をワードプロセッサ文書２０４にメッセージ送信するたびに、ワードプロセッサアプリケーション２０２は、最新の更新によって解決されている懸垂参照２１５がないかどうかを調べる（すなわち、ＸＰａｔｈは、現在、ＸＭＬツリー内の有効なノード２１３をポイントしている）。ワードプロセッサアプリケーション２０２が懸垂参照を解決する場合は、データストア２０８のコンテンツが、現在データバインディング２０５にあるコンテンツより優先されることが好ましい。すなわち、データバインディング２０５のコンテンツは、データストア２０８内のノード２１３のコンテンツによって置き換えられる。懸垂参照は、１つまたは複数のプログラミング環境２０６からアクセス可能な、シンプルなＡＰＩレイヤを用いて公開されることが好ましい。
【００６６】
例として、ワードプロセッサ文書２０４が以下のパラグラフを含むとする。ここで、「Ｍｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎ」は、あるＸＭＬデータ２０９内のＸＰａｔｈ／ｃｏｎｔｒａｃｔ／ｈｅａｄｅｒ／ｃｏｍｐａｎｙ（３）にバインドされたプレーンテキストコンテンツ領域２０７のデータに対応する。
【００６７】
【表７】
2006190277.tif 000009
【００６８】
対応するＸＭＬデータ２０９は次のようになるであろう（一重引用符で囲まれたノード２１３にリンクされている）。
【００６９】
【表８】
2006190277.tif 000010
【００７０】
開発者などのユーザがデータストア２０８のＡＰＩを用いて＜ｈｅａｄｅｒ＞の下の第１の＜ｃｏｍｐａｎｙ＞ノード２１３を削除した場合は、次のようになるであろう（ノード２１３は一重引用符で囲まれている）。
【００７１】
【表９】
2006190277.tif 000011
【００７２】
文書２０４のコンテンツ領域２０７内の結果のデータバインディング２０５は、同じＸＰａｔｈへのリンクを維持するので、データバインディング２０５は、現時点では存在しない＼ｃｏｎｔｒａｃｔ＼ｈｅａｄｅｒ＼ｃｏｍｐａｎｙ（３）への懸垂参照２１５になる。
【００７３】
【表１０】
2006190277.tif 000012
【００７４】
これは、内部的にはリンクが切れているが、本発明によれば、コンテンツ領域２０７のコンテンツは変化せず、エラーは発生しないことを意味する。すなわち、次のとおりである。
【００７５】
【表１１】
2006190277.tif 000013
【００７６】
あるＸＭＬデータ２０９が置き換えられたか、削除された場合（または、リンクがドキュメント間で移動した場合）は、そのＸＭＬデータ２０９を参照するすべてのデータバインディング２０５が、ただちに、削除されたＸＭＬデータ２０９をポイントしている懸垂参照２１５になる。データバインディング２０５が懸垂参照２１５を含む場合、ワードプロセッサアプリケーション２０２は、そのデータバインディング２０５に関連付けられた、最後に知られたＸＰａｔｈ／名前空間リンクを保存し続ける。本発明の実施形態によれば、データバインディング２０５の集合が懸垂参照２１５になった場合、ワードプロセッサアプリケーション２０２は、これらのリンクを、関連付けられたＸＭＬデータストア２０８にある他の任意の使用可能なＸＭＬデータ２０９に再アタッチしようとする。いずれかのデータバインディング２０５が別のＸＭＬデータ２０９にあるノード２１３を解決した場合は、すべての懸垂参照２１５がそのＸＭＬデータ２０９に関連付けられ、どのデータバインディング２０５が現在接続されているかに関して、関連付けられたコンテンツ領域２０７が更新される。このＸＭＬデータ２０９がどの懸垂参照２１５についても有効なデータバインディング２０５をもたらさない場合、ワードプロセッサアプリケーション２０２は、データストア２０８内の各ＸＭＬデータ２０９などに対して同様の検査を実行する。懸垂参照２１５に対して使用可能なＸＭＬデータ２０９がない場合、バインディングは、元のＸＭＬデータ２０９への懸垂参照２１５のままになる。
【００７７】
図３に示されたフロー図を参照し、図２も引き続き参照しながら、本発明の実施形態を説明する。図３に示されたプロセス３００は、３０２から始まる。３０２では、ユーザがワードプロセッサアプリケーション２０２を用いてワードプロセッサ文書２０４を開く。３０４で、ワードプロセッサアプリケーションがデータストア２０８を作成する。次に３１０で、ワードプロセッサ文書２０４に格納されているＸＭＬデータ２０９か、ユーザインターフェースまたはプログラミングウィンドウ２０６を用いて要求されたＸＭＬデータ２０９があれば、そのＸＭＬデータ２０９でデータストア２０８が埋められる。データストア２０８は、文書２０４の一部であることが好ましいが、文書編集表面２０３上では不可視である。データストア２０８は、コンテンツ領域２０７およびデータバインディング２０５が作成される前にロードされることが可能であることを理解されたい。同様に、コンテンツ領域２０７は、データストア２０８より前に作成されることが可能である。言い換えると、図３に示されている各種操作は、特定の順序で実行される必要はまったくなく、特定のユーザの好みに応じて実施されてよい。
【００７８】
３０６で、ユーザが、文書２０４の表面２０３上に存在する１つまたは複数のコンテンツ領域２０７を作成する。これらのコンテンツ領域は、文書２０４の既存のコンテンツから読み出し可能であることにも注意されたい。３０８で、ユーザは、特定のリンクされたＸＭＬデータ２０９と、ターゲットノード２１３を指定するＸＰａｔｈ式とを与えることによって、データバインディング情報をコンテンツ領域２０７に関連付けることが可能である。１つまたは複数のデータバインディングが、データストア２０８内のＸＭＬデータ２０９の１つまたは複数のノード２１３を、１つまたは複数のコンテンツ領域２０７にリンクする。データバインディング２０５は、バインドされるか懸垂になる。前述のように、各ノード２１３は複数のコンテンツ領域２０７にバインドされることが可能であり、その各コンテンツ領域２０７は、同じＸＭＬノード２１３へのデータバインディング２０５を指定している。さらに、そのデータバインディング２０５は、複数のデータストア２０８にリンクされることが可能である。３０９で、ユーザが、ＸＭＬデータを、コンテンツ領域２０７内またはデータストア２０８内に作成することが可能である。３１０で、ワードプロセッサアプリケーション２０２が、すべてのＸＭＬデータをデータストア２０８にロードする。３１２で、ワードプロセッサアプリケーション２０２がコンテンツ領域２０７を、文書２０４から、またはユーザ３０６からの要求に応じてロードし、３１４で、ワードプロセッサアプリケーション２０２がデータバインディング２０５を、文書２０４から、またはユーザ３０８からの要求に応じてロードする。３１６で、ワードプロセッサアプリケーション２０２が、特定のデータバインディング２０５によって指定されたノード２１３に関連付けられたＸＭＬデータ２０９が存在するかどうかを調べる。
【００７９】
ＸＭＬデータ２０９が存在しない場合は、３１８で、ワードプロセッサアプリケーション２０２が、同じＸＭＬ名前空間内に他のＸＭＬデータ２０９が存在するかどうかを調べる。３１６で、データストア内でＸＭＬデータ２０９が見つかった場合は、３２０で、ワードプロセッサアプリケーション２０２が、指定されたＸＰａｔｈに対して関連付けられたＸＭＬノード２１３が存在するかどうかを調べる。そのＸＰａｔｈが存在する場合は、３２２で、ワードプロセッサアプリケーション２０２が、各種の文書コンテンツ（すなわち、コンテンツ領域２０７および他の任意のリンクされたコンテンツ）を、データバインディング経由で、関連付けられた１つまたは複数のＸＭＬノード２１３に接続する。３２０でそのＸＰａｔｈが見つからない場合は、３２４で、ワードプロセッサアプリケーション２０２が、特定のデータバインディング２０５を懸垂参照２１５としてラベル付けする（懸垂状態に入る）。３１８で、データストア２０８内の同じＸＭＬ名前空間で他のＸＭＬデータ２０９が見つかった場合は、３２６で、ワードプロセッサアプリケーション２０２が、そのデータの中にＸＭＬノード２１３が存在するかどうかを再度調べる。
【００８０】
ＸＭＬデータ２０９が存在しない場合は、３２４で、ワードプロセッサアプリケーション２０２が、特定のデータバインディング２０５を懸垂参照としてラベル付けする（懸垂状態に入る）。３２６で、ＸＭＬデータ２０９が３２６で存在することがわかった場合は、３２８で、ワードプロセッサアプリケーション２０２が、そのＸＭＬデータ２０９内で目的のＸＰａｔｈを探す。３２０でノード２１３が見つかった場合は、３２２で、ワードプロセッサアプリケーション２０２が、文書コンテンツ（すなわち、コンテンツ領域２０７および他の任意のリンクされたコンテンツ）を、関連付けられた１つまたは複数のＸＭＬノード２１３に接続する。
【００８１】
データをバインドするオブジェクトモデル
次に図４を参照して、本発明の別の実施形態を説明する。多くのソフトウェアアプリケーションにおいて、ユーザがアプリケーション（アプリケーション４００など）のユーザインターフェースから実行するタスクをコードで自動化する方法を提供するために、オブジェクトモデルを用いることが可能である。オブジェクトモデルは、例えば、次のことを行うコードを書くことを可能にする。
・  ユーザの繰り返しのタスクを自動化する、
・  ユーザのアクションに反応する（妥当性を検査するなど）、および／または
・  ファイル４１０が開かれた／編集された／保存されたときに自動アクションを実行する。
【００８２】
例えば、アプリケーション（例えば、ＷＯＲＤ２００３）は、ワードプロセッサのユーザインターフェースのすべての機能へのアクセスをコード経由で可能にするオブジェクトモデルインターフェースを提供する。オブジェクトモデルインターフェースは、ワードプロセッサアプリケーションのすべてのパラダイム／ユーザインターフェースの等価物へのコードアクセスを可能にする構造を提供することによってこれを行う。
【００８３】
この構造は、次の４つの基本カテゴリによって構成される。
・  オブジェクト：アプリケーション内でアクション可能なオブジェクトに対応する。例えば、文書表面におけるユーザのパラグラフに対応するように、パラグラフをオブジェクトモデル内のオブジェクトとして表すことが可能である。
・  メソッド：オブジェクトに対して実行可能なアクション（例えば、削除）。
・  プロパティ：オブジェクトに関して設定可能なものやこと（例えば、パラグラフを太字にすること）。
・  イベント：ユーザ（または他のコード）によるアプリケーションとの対話に反応して実行されるサブルーチンに対応する。例えば、ファイルが開くイベントをリスンするコードを登録することが可能であり、アプリケーションは、ユーザによってであれ、他のコードによってであれ、アプリケーション内でファイルが開かれたときに、このコードを通知することが可能である（これに対してユーザは任意のアクションを実行することが可能である）。
【００８４】
アプリケーションのオブジェクトモデル内にある任意のオブジェクトが、コードによるそのオブジェクトに対する操作を可能にするメソッド、プロパティ、および／またはイベントをエクスポーズすることが可能である。
【００８５】
本発明の実施形態による、プログラミング環境４０２を含むアプリケーション４００について説明する。プログラミング環境４０２は、アプリケーション４００（前述のワードプロセッサアプリケーション２０２など）内のオブジェクトへの、オブジェクトモデルによるコードアクセスを提供する。本発明の実施形態について、ワードプロセッサアプリケーションの文脈で説明してきたが、前述のように、本発明は特定のアプリケーションに限定されることを意図したものではないことを理解されたい。プログラミング環境４０２はさらに、メソッド／プロパティ／イベントのロバストな集合がコンテンツ領域４０８のコンテンツに対する変更をトラップすることを可能にしながら、コンテンツ領域４０８の動作を制御することを可能にするように動作可能である。さらにプログラミング環境４０２は、ユーザ（例えば、プログラマなど）が、１つまたは複数のコンテンツ領域４０８とデータストア４１４の１つまたは複数のノード４１６との間のリンクを与える１つまたは複数のデータバインディング４０６に、プログラムによってアクセスすることを可能にする。
【００８６】
前述のように、コード４０４は、プログラミング環境４０２を用いて、コンテンツ領域４０８またはＸＭＬデータ４１２内のノード４１６の、いずれの方向での変更にも反応するように開発されることが可能である。コード４０４はさらに、ファイルコンテンツとデータストア４１４内のコンテンツとの間の関係を定義するように開発されることも可能である。さらに、ファイル４１０の境界領域内またはデータストア４１４内の変化に反応して、編集、追加、削除などのイベントをトラップまたはインターセプトするコード４０４を開発することが可能である。本発明の実施形態によれば、ユーザが、関連付けられたＸＭＬでコード４０４を一度書くだけで、そのコードは、ターゲットアプリケーションの正確なセマンティクスを意識することなく、ＸＭＬ構造体の使用をサポートするすべてのファイルタイプに移植することが可能になり、それによって、アプリケーション開発が大幅に簡略化かつ合理化される。
【００８７】
アプリケーションプログラミングインターフェース（ＡＰＩ）などのプログラミング環境４０２は、オブジェクトをエクスポーズして、コード４０４によりアプリケーション４００内で１つまたは複数のデータバインディング４０６を操作する機能を提供する。１つまたは複数のデータバインディング４０６を、特定ファイル４１０の１つまたは複数のコンテンツ領域４０８に関連付けることが可能である。
【００８８】
コンテンツ領域のプロパティは、データバインディングの動作を操作する、次の２つのイベントを提供するオブジェクトを返すことが好ましい。
【００８９】
・  .BeforeStoreUpdate(ContentRegion As ContentRegion, Content As String)  コンテンツ領域のコンテンツが変更されてから、テキストがＸＭＬデータ４１２の当該ノード４１６に送信される前にオブジェクト（文字列）を返すイベントである。これにより、コード４０４は、コンテンツ領域４０８のコンテンツを変更することなく、その文字列がＸＭＬデータのノードに到達する前にその文字列を操作することが可能である。
【００９０】
・  .BeforeContentUpdate(ContentRegion As ContentRegion, Content As String)  関連付けられたコンテンツ領域４０８にリンクしている、ＸＭＬデータ４１２内のノード４１６のコンテンツが変更されてから、コンテンツ領域４０８が更新される前に発生するイベントである。これにより、コード４０４は、ノードのデータを変更することなく、データ４１２を、コンテンツ領域４０８に表示される前に操作することが可能である。
【００９１】
コンテンツ領域４０８は、プログラミング環境４０２からアクセス可能な、「ＤａｔａＢｉｎｄｉｎｇ」プロパティを含むプロパティを含むことが好ましい。ＤａｔａＢｉｎｄｉｎｇプロパティは、コンテンツ領域４０８と、ファイル４１０に関連付けられた、データストア４１４のデータ４１２との間の関係へのアクセスを提供する。ＤａｔａＢｉｎｄｉｎｇは、ＤａｔａＢｉｎｄｉｎｇオブジェクト（プロパティ、メソッド、およびイベント）を返すことによって、データバインディング４０６およびデータバインディング４０６に関連付けられた他のデータおよびオブジェクトの操作を可能にすることが好ましい。
【００９２】
代表的なメソッドおよびプロパティとして以下のものがあるが、これらに限定されない。
・  .CustomDataStream As CustomDataStream
（さらなる操作のために）データバインディング４０６に関連付けられたＸＭＬデータ４１２を表すオブジェクトを返すプロパティである。このオブジェクトモデルを用いてＸＭＬデータを直接操作するようにコード４０４を開発することが可能である。懸垂参照の場合は何も返さない。
【００９３】
・  .CustomDataXMLNode As CustomDataXMLNode
データバインディング４０６のターゲットである、ＸＭＬデータ４１２内のＸＭＬノード４１６を表すオブジェクトを返すプロパティである。特定のデータバインディング４０６のターゲットノード４１６を操作するようにコード４０４を開発することが可能である。懸垂参照の場合は何も返さない。例として、ユーザが、データバインディング４０６のターゲットを変更するためにノード４１６を移動したい場合がある。別の例として、ファイル４１０が何らかのパブリックサーバに移る予定なので、ユーザがノード４１６を削除したい場合がある。したがって、コード４０４を用いて、この返されたオブジェクトを用いてノード４１６を探して削除するようにし、ファイル４１０がパブリックサーバに配置されたときに情報が誤って送信されないようにすることが可能である。
【００９４】
・  .Delete As Void
コンテンツ領域４０８からデータバインディング４０６を削除するオブジェクトを返すメソッドである。例えば、ファイル４１０が、ＸＭＬデータ４１２内の名前要素にリンクされた名前（またはバインドされたデータ）を有するコンテンツ領域４０８を含む場合がある。ユーザはデータ４１２をフリーズさせたいので、コード４０４を用いてバインディング４０６（すなわち、「ｄａｔａＢｉｎｄｉｎｇ．Ｄｅｌｅｔｅ」）を削除することによって、コンテンツ領域４０８からリンクを削除するように操作することが可能である。
【００９５】
・  .IsBound As Boolean
データバインディング４０６が現時点で懸垂参照かどうかを調べるオブジェクトを返すプロパティである。コード４０４を用いて、ターゲットノード４１６が存在するかどうかを調べることが可能である。コード実装が成功するように、様々な状況において、ターゲットノードが存在するかどうか、すなわち、データバインディング４０６が懸垂かアクティブかを調べることが好ましい。ターゲットノードが存在する場合、オブジェクトは「．ｔｒｕｅ」を返し、そうでなく、懸垂参照が存在する場合、またはバインディングが存在しない場合は、「．ｆａｌｓｅ」を返す。
【００９６】
・  .SetBindingByNode(CustomDataXMLNode as CustomDataXMLNode) As Boolean
特定のリンクに対してターゲットＸＭＬノード４１６を提供することによって、コンテンツ領域４０８内のデータバインディング４０６を作成／変更するオブジェクト（ＣｕｓｔｏｍＤａｔａＸＭＬＮｏｄｅ）を返すメソッド。バインディングが存在する場合は既存のバインディングが置き換えられ、新しいバインドされたノードのストアコンテンツが（もしあれば）、既存のコンテンツを置き換える。ライブノードにバインドされている場合は「．ｔｒｕｅ」を返し、ライブノードにバインドされていない場合は「．ｆａｌｓｅ」を返す。
【００９７】
・  .SetBindingByXPath(CustomDataStream as Variant, XPath as String, [Pre fix Mapping As String]) As Boolean
リンクに対してＸＰａｔｈおよびＸＭＬデータ４１２を提供することによって、コンテンツ領域４０８上にデータバインディング４０６を作成するために用いられる情報（ＸＰａｔｈ、ノードへのポインタ（ＩＤ）、および／または名前空間に関連するプレフィックスマッピングなど）を表すオブジェクト（ＣｕｓｔｏｍＤａｔａＳｔｒｅａｍ、ＸＰａｔｈ、および／またはＰｒｅｆｉｘＭａｐｐｉｎｇ）を返すメソッドである。
【００９８】
・  ＣｕｓｔｏｍＤａｔａＳｔｒｅａｍ：バインド先のストアアイテムを指定するバリアントであって、以下のいずれかであることが可能である。
○  目的のストリームを表すＣｕｓｔｏｍＤａｔａＳｔｒｅａｍオブジェクト
○  目的のストリームのルート名前空間を表すＳｔｒｉｎｇ（文字列）−そのルート名前空間を有するストリームが複数存在する場合は、ストア内で最初に見つかったアイテムを取得する
○  ストアのコレクションにある目的のストアアイテムのインデックスを表すＩｎｔｅｇｅｒ（整数）
【００９９】
・  ＸＰａｔｈ：バインド先のＸＰａｔｈを表すＳｔｒｉｎｇ（文字列）。有効なＸＰａｔｈシンタックスであることを確認し、そうでない場合には失敗してエラーメッセージを出す。
【０１００】
・  ＰｒｅｆｉｘＭａｐｐｉｎｇ：提供されたＸＰａｔｈ式を照会する場合に用いられることが可能なプレフィックスマッピングを表す、オプションのＳｔｒｉｎｇ（文字列）。存在しない場合は、ストアアイテム自身によって用いられるプレフィックスマッピングの集合を用いる。
【０１０１】
・  .XPath As String
ＸＭＬデータ４１２内のターゲットＸＭＬノード４１６をポイントするデータバインディング４０６によって用いられるＸＰａｔｈ式を見つけるオブジェクトを返すプロパティ。
【０１０２】
以上のリストされたプロパティ、メソッド、およびイベントを用いるコード開発は、個々のアプリケーションに対して適応可能であることを理解されたい。
【０１０３】
本発明の各種実施形態の論理動作は、（１）コンピューティングシステムで動作する、コンピュータに実装されたアクションまたはプログラムモジュールのシーケンスとして、かつ／または、（２）コンピューティングシステム内で相互接続されたマシン論理回路またはマシン論理回路モジュールとして、実施されることを理解されたい。実施態様は、本発明を実施するコンピューティングシステムの性能要件に応じて選択される。したがって、本明細書で説明された、本発明の実施形態を構成する論理動作は、動作、構成装置、アクション、またはモジュールとして様々に参照される。当業者であれば、これらの動作、構成装置、アクション、およびモジュールは、添付の特許請求項において列挙されている本発明の趣旨および範囲から逸脱することなく、ソフトウェア、ファームウェア、専用デジタル論理、およびこれらの任意の組合せで実施可能であることを理解されよう。
【０１０４】
先述の明細書、実施例、およびデータは、本発明の構成物の製造および使用に関する完全な説明を提供する。本発明の趣旨および範囲から逸脱することなく本発明の様々な実施形態が作成可能なので、本発明は、添付の特許請求項に属する。
【図面の簡単な説明】
【０１０５】
【図１】本発明の一例示的実施形態で使用可能な例示的コンピューティング装置を示す図である。
【図２】本発明を実施するための例示的環境を示すブロック図である。
【図３】本発明の実施形態によるフロー図である。
【図４】本発明を実施するための別の例示的環境を示すブロック図である。
【符号の説明】
【０１０６】
１００  コンピューティング装置
１０２  処理ユニット
１０４  システムメモリ
１０５  オペレーティングシステム
１０６  アプリケーション
１０７  プログラムデータ
１０９  リムーバブル記憶装置
１１０  非リムーバブル記憶装置
１１２  入力装置
１１４  出力装置
１１６  通信接続
１１８  他のコンピューティング装置
１２０  ワードプロセッサ
【図１】
2006190277.tif 000014
【図２】
2006190277.tif 000015
【図３】
2006190277.tif 000016
【図４】
2006190277.tif 000017