JP2008544338A - Ｘｍｌアプリケーションフレームワーク - Google Patents
Ｘｍｌアプリケーションフレームワーク Download PDFInfo
- Publication number
- JP2008544338A JP2008544338A JP2008508957A JP2008508957A JP2008544338A JP 2008544338 A JP2008544338 A JP 2008544338A JP 2008508957 A JP2008508957 A JP 2008508957A JP 2008508957 A JP2008508957 A JP 2008508957A JP 2008544338 A JP2008544338 A JP 2008544338A
- Authority
- JP
- Japan
- Prior art keywords
- data
- components
- application
- graph
- phase
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/20—Software design
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/451—Execution arrangements for user interfaces
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Human Computer Interaction (AREA)
- Stored Programmes (AREA)
Abstract
本発明は、ＸＭＬアプリケーションフレームワーク（ＸＡＦ）に関する。コンピュータシステムに関するすべての動作がデータに焦点を合わせたものになるように、ＸＡＦアプリケーションはデータ駆動型である。さらに、ＸＡＦアプリケーションで使用されるコンポーネントは、データがどのように表示されるかと、どの型のデータが使用されるかとに従って、インスタンス化され、接続される。ＸＡＦ内のアプリケーションは、ユーザインターフェース（ＵＩ）コネクタ、アクションモジュール、およびデータコネクタを含む。ＵＩコネクタは、ＵＩイベントを受信し、そのＵＩイベントをアクションモジュールに接続する。アクションモジュールは、ＵＩイベントから標準フォーマットアクションを生成し、その標準フォーマットアクションをデータコネクタに送信する。データコネクタは、標準フォーマットアクションをデータ固有アクションに変換し、そのデータ固有アクションが、データストア内のデータを変更する。次に、データコネクタは、変更されたデータに対応する標準フォーマットデータ表現をＵＩコネクタに返送して、変更されたデータをＵＩに提供する。
Description
（著作権に関する声明）
本特許書類の開示の一部には、著作権保護の対象となる要素が含まれている。著作権所有者は、本特許書類または特許開示が米国特許商標庁の特許ファイルまたは記録の中に表示されている場合、いかなる者がそれらをファクシミリによって複製しても、異議を申し立てないものとするが、その他の場合は、いかなるものであれ著作権関連の権利をすべて留保する。
本特許書類の開示の一部には、著作権保護の対象となる要素が含まれている。著作権所有者は、本特許書類または特許開示が米国特許商標庁の特許ファイルまたは記録の中に表示されている場合、いかなる者がそれらをファクシミリによって複製しても、異議を申し立てないものとするが、その他の場合は、いかなるものであれ著作権関連の権利をすべて留保する。
一般に、ソフトウェアシステムは、コンピュータシステム内のソフトウェアコンポーネントを編成し、相互接続するソフトウェアアーキテクチャを提供する。ソフトウェアコンポーネントは、ソフトウェアアプリケーションにソフトウェアコンポーネントの機能を提供する動作を実行する。一般に、アプリケーションは、それぞれが１つまたは複数のコンポーネントを有する複数の特徴を用いて動作する。コンポーネントは、したがって、特徴は、その動作をより小さくより単純なタスクに分節する１つまたは複数の基礎になるソフトウェアコンポーネントから形成することができる。
ソフトウェアアプリケーションを構成するときに、ソフトウェア開発者は、Ｃ＃などの開発言語を使用してソフトウェアコンポーネントを作成しなければならない。命令コード（imperative code）すなわちソフトウェアコンポーネントにソフトウェアコードの機能を提供する当該ソフトウェアコードを作成する際に、開発者は、呼び出しまたは他の構造を介して、すべてのコンポーネント間のリンクを作成しなければならない。アプリケーションによって提供されるすべての機能について、ソフトウェア開発者は、一般に、そのアプリケーションに固有の機能を実行するすべての様々なソフトウェアコンポーネントに関するコードを作成し、タスクを完了するために互いに依存しあうソフトウェアコンポーネント間の相互接続を手作業でコーディングする。ソフトウェア開発者は、ユーザインターフェース（ＵＩ）、データ構造体、および、ユーザとアプリケーションとの間の対話に関するすべての必要な動作を作成する。
多くのアプリケーションでは、ＵＩ、動作、およびデータ構造体が、アプリケーションに固有である。したがって、アプリケーションを作成するために、ソフトウェア開発者は、通常、膨大な量のコードを作成する。さらに、ソフトウェア開発者は、一般に、ソフトウェアの様々な部分間のすべての相互関係を編成して、作成する。アプリケーションを作成するためには、アプリケーションの作成に使用される基礎になる言語が複雑なので、ソフトウェア開発者は、高い技量を有さなければならない。
アプリケーションを生成する現在の方法の複雑さに起因して、また、所与のアプリケーションのコードの特異性およびその不可避の相互接続に起因して、ソフトウェア開発者は、多大な労力なしに、また、既存のアプリケーションに対して悪影響を及ぼす危険性なしに、現在のアプリケーションを容易に修正し、または拡張することはできない。
本発明が行われたのは、上記および他の考慮事項に関してである。
この要約は、以下の詳細な説明でさらに説明される概念のうちから選択したものを単純化した形で紹介するために提供される。この要約は、特許請求される主題の主要な特徴または本質的な特徴を特定することを意図するものではない。
本発明の実施形態は、所与のソフトウェアアプリケーションのランタイム構造を生成し、そのソフトウェアアプリケーションの実行を管理するソフトウェアアプリケーションフレームワークを提供することによって、上記および他の問題を解決する。本発明のアプリケーションフレームワークによって生成されるアプリケーションは、接続されたアプリケーションコンポーネントの集合（collection）またはグラフから構成される。このアプリケーションフレームワークに従って構成されたアプリケーションの機能は、アプリケーションコンポーネントのグループをコンポーネントドメインに動的に構成することによって使用可能にでき、各ドメインは、アプリケーションの所与の機能、例えばワープロ文書内での画像の表示、を可能にするように構成される。
アプリケーションのランタイム構造を生成するために、アプリケーションは、必要なアプリケーション機能ごとのアプリケーション記述（application description）をアプリケーション記述エンジンに渡す。アプリケーション記述は、コンポーネントドメインを構造化して作成する宣言ルールを提供し、アプリケーション記述エンジンは、アプリケーションによって受信されるデータイベントに基づいて、必要に応じてコンポーネントドメインを作成して再構成するために、宣言ルールを解釈するように動作可能である。アプリケーションによって受信されるデータイベントは、ユーザアクションによって、例えば、ユーザインターフェース内の機能ボタン、コントロール、またはデータオブジェクトのユーザ選択に応答して、生成されるものとすることができる。データイベントは、外部変化によって、例えば、外部プロセスの実行の結果として、または別のアプリケーションもしくはサードパーティソースからアプリケーションによって受信されるデータによって生成されるものとすることもできる。一実施形態によれば、アプリケーション記述およびアプリケーション記述エンジンは、拡張マークアップ言語（ＸＭＬ）に従って構造化され、かつ／または動作する。フレームワーク内でのアクションまたは他の事象を記述する標準的で単純な手段を提供するために、ＸＭＬをアプリケーションフレームワーク内で使用することができるが、アプリケーションフレームワークは、ＸＭＬのみの使用に限定されるものではない。
アプリケーション記述エンジンは、必要な機能ごとにアプリケーション記述を解釈し、その後、必要な機能ごとのコンポーネントドメインを構築するのに必要なアプリケーションコンポーネントを取得する。一実施形態によれば、アプリケーション記述エンジンは、アプリケーションに関連して保持されるコンポーネントライブラリからアプリケーションコンポーネントを取得する。例えば、アプリケーション記述エンジンは、文書内でテキストを表示する第１のドメイン、文書内で画像オブジェクトを表示する第２のドメイン、アプリケーションのフォーマッティング機能のための第３のドメインなどを構成することができる。
実施形態によれば、アプリケーションフレームワークは、アプリケーションと、アプリケーションを含むドメインとの実行を管理する実行管理モデルをさらに含む。データイベント、例えば、データテーブル内のデータ項目の削除がアプリケーションの実行中に発生し、このデータイベントが、所与のアプリケーション機能の呼び出しを必要とし、したがって、その機能を使用可能にする特定のコンポーネントドメインの呼び出しを必要とする場合に、シングル処理スレッドが、データ駆動イベントに従ってドメインのコンポーネントを実行するために、アプリケーションによって対象ドメインにディスパッチされる。
シングル処理スレッドが対象ドメインに入ると、そのドメインのコンポーネントが、実行フェーズモデルに従って、そのスレッドによって実行される。第１のフェーズ、すなわち、読み取り／要求フェーズでは、要求されたデータの読み取り、例えば、テーブルオブジェクトから削除される値の読み取りが実行され、その後、必要な変更に関する要求、例えば、上記テーブルオブジェクトからの要求された値の削除が実行される。第２のフェーズ、すなわち、再検証／再構成フェーズ中に、対象ドメインが、要求された変更に従って、アプリケーション記述エンジンによって再検証されるか、または再構成される。すなわち、アプリケーション記述エンジンは、必要な場合に、データの変化に適用可能な新しい構成に従って、ドメインを再構成する。
再構成フェーズ中に、アプリケーション記述エンジンは、ドメインのいくつかのコンポーネントを破棄し、ドメインの新しいコンポーネントを取得し、あるいはドメインを完全に破壊することができる。したがって、所与のドメインは、初期構成と後続の再構成との間の時間と等しい有効期間サイクルを有するコンポーネントの集合であり、この後続の再構成は、その所与のドメインの次の構成がある場合に、その次の構成の有効期間サイクルを開始する。したがって、アプリケーション記述エンジンによって生成される各コンポーネントドメインは、アプリケーションの所与のデータ駆動機能を実行するのに必要なコンポーネントの集合として動作し、ドメインは、ドメインのサービスに関するアプリケーションの必要性によって決定される有効期間を有する。
本発明および本発明の改善は、添付図面、本発明の例示的な実施形態に関する以下の詳細な説明、および特許請求の範囲を参照することによって、より完全に理解することができる。
以下、本発明の実施形態が示されている添付図面を参照しながら、本発明について、より十分に説明する。しかし、本発明は、多数の異なる形で実施することができ、本明細書に示された実施形態に限定されるものと解釈すべきではない。そうではなく、これらの実施形態は、開示を完全なものにし、本発明の範囲を当業者に十分に伝えるために提供されるものである。
上記にて簡潔に説明したように、本発明の実施形態は、所与のソフトウェアアプリケーションのランタイム構造を生成し、ソフトウェアアプリケーションの実行を管理するソフトウェアアプリケーションフレームワークを提供する。所与のソフトウェアアプリケーションのランタイム構造は、そのソフトウェアアプリケーションの１つまたは複数の各機能を実行するのに必要なアプリケーションコンポーネントの１つまたは複数のドメインから構成される。コンポーネントドメインは、ドメインごとに、アプリケーションから受信されるアプリケーション記述に応答して、アプリケーション記述エンジンによって生成される。アプリケーションの実行中に、各コンポーネントドメインは、アプリケーション実行管理のユニットとして動作し、各ドメインは、アプリケーションの各機能を実行するのに利用される。データ変化が、所与のコンポーネントドメインに関連するアプリケーションによって受信されるときに、コンポーネントドメインは、関連するデータに応答する必要性に応じて、アプリケーション記述エンジンによって再構成される。アプリケーションによって受信されるデータ変化またはデータイベントは、ユーザアクションによって、例えば、ユーザインターフェース内の機能ボタン、コントロール、またはデータオブジェクトのユーザ選択に応答して、生成されるものとすることができる。データイベントは、外部変化によって、例えば、外部プロセスの実行の結果として、または別のアプリケーションもしくはサードパーティソースからアプリケーションによって受信されるデータによって生成されるものとすることもできる。したがって、アプリケーションは、そのアプリケーションによって受信され、かつ／または処理されるデータに基づいて編成され、動的に再構成される接続されたコンポーネントの集合またはグラフである。
本発明を実施できる適切なコンピューティングシステム環境１００の例を、図１に示す。コンピューティングシステム環境１００は、適切なコンピューティング環境の１つの例に過ぎず、本発明の使用または機能の範囲に関して限定されるものと示唆するよう意図するものではない。コンピューティング環境１００を、例示的な動作環境１００に示されたコンポーネントのいずれかまたはその組合せに関して、何らかの依存性または要件を有するものと解釈すべきでもない。
本発明は、多数の他の汎用または専用コンピューティングシステム環境またはコンピューティングシステム構成と共に動作可能である。本発明と共に使用するのに適切な周知のコンピューティングシステム、コンピューティング環境、および／またはコンピューティング構成の例には、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイス、ラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家庭用電子製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれかを含む分散コンピューティング環境などが含まれるが、これらに限定されるものではない。
本発明は、コンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的なコンテキストにおいて説明することができる。一般に、プログラムモジュールには、特定のタスクを実行するか、または特定の抽象データ型を実装するルーチン、プログラム、コンポーネント、データ構造体などが含まれる。本発明は、通信ネットワークを介して接続されるリモート処理デバイスによってタスクが実行される分散コンピューティング環境において実施することもできる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶デバイスを含む、ローカルコンピュータ記憶媒体とリモートコンピュータ記憶媒体との両方に配置することができる。
図１Ａを参照すると、本発明を実施する例示的なコンピュータシステム１００は、コンピュータ１１０の形態をとる汎用コンピューティングデバイスを含む。コンピュータ１１０のコンポーネントには、処理ユニット１２０と、システムメモリ１３０と、システムメモリ１３０を含む様々なシステムコンポーネントを処理ユニット１２０に結合するシステムバス１２１とが含まれるが、これらに限定されるものではない。システムバス１２１は、様々なバスアーキテクチャのいずれかを使用する、メモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含む複数のタイプのバス構造のいずれかとすることができる。例えば、そのようなアーキテクチャには、ＩＳＡバス、ＭＣＡバス、ＥＩＳＡバス、ＶＥＳＡローカルバス、およびメザニンバスとも呼ばれるＰＣＩバスが含まれるが、これらに限定されるものではない。
コンピュータ１１０には通常、様々なコンピュータ読み取り可能な媒体が含まれる。コンピュータ読み取り可能な媒体は、コンピュータ１１０によってアクセスすることができるすべての入手可能な媒体とすることができ、コンピュータ読み取り可能な媒体には、揮発性媒体および不揮発性媒体と、取外し可能な媒体および取外し不可能な媒体とのいずれもが含まれる。例えば、コンピュータ読み取り可能な媒体には、コンピュータ記憶媒体および通信媒体を含めることができるが、これらに限定されるものではない。コンピュータ記憶媒体には、コンピュータ読み取り可能命令、データ構造体、プログラムモジュール、またはその他のデータなどの情報を記憶する任意の方法または技術で実施される、揮発性媒体、不揮発性媒体、取外し可能な媒体、および取外し不可能な媒体が含まれる。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、もしくはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、もしくはその他の光ディスク記憶デバイス、磁気カセット、磁気テープ、磁気ディスク記憶デバイス、もしくはその他の磁気記憶デバイス、または所望の情報を記憶するのに使用することができ、かつコンピュータ１１０によってアクセスすることができるすべての他の媒体が含まれるが、これらに限定されるものではない。通信媒体は通常、搬送波またはその他の搬送機構などに、コンピュータ読み取り可能命令、データ構造体、プログラムモジュール、またはその他のデータなどの変調されたデータ信号を具現化したものであり、通信媒体には、すべての情報配信媒体が含まれる。用語「変調されたデータ信号」は、信号内で情報を符号化する形でその特性の１つまたは複数を設定または変更された信号を意味する。例えば、通信媒体には、有線ネットワークまたは直接配線接続などの有線媒体と、音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体とが含まれるが、これらに限定されるものではない。上記のいずれの組合せも、コンピュータ読み取り可能な媒体の範囲に含まれるべきである。
システムメモリ１３０には、ＲＯＭ１３１およびＲＡＭ１３２などの揮発性メモリおよび／または不揮発性メモリの形態をとるコンピュータ記憶媒体が含まれる。起動中などにコンピュータ１１０内の要素間での情報の転送を助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）１３３は通常、ＲＯＭ１３１に記憶される。ＲＡＭ１３２には通常、ＸＭＬアプリケーションフレームワークの下で構成されるか、または実行されるモジュールなどの、処理ユニット１２０によって直ちにアクセス可能であり、かつ／または処理ユニット１２０によって現在操作されているデータおよび／またはプログラムモジュールが含まれる。例えば、図１Ａには、オペレーティングシステム１３４、アプリケーションプログラム１３５、２０４（図２Ｂ）、３０４（図３）、その他のプログラムモジュール１３６、およびプログラムデータ１３７が示されているが、これらに限定されるものではない。ＸＭＬアプリケーションフレームワークは、ＲＡＭ１３２に記憶されるか、またはＲＡＭ１３２から実行される、すべてのソフトウェアのアプリケーションを構成して、実行するように動作することができる。
コンピュータ１１０には、その他の取外し可能／取外し不可能な揮発性／不揮発性コンピュータ記憶媒体を含めることもできる。例えば、図１Ａには、ハードドライブなどの取外し不可能な不揮発性磁気媒体１４１に対して読み書きする、取外し不可能な不揮発性メモリインターフェース１４０を有するコンピュータ１１０が示されている。コンピュータ１１０には、磁気ディスクなどの取外し可能な不揮発性媒体１５２に対して読み書きする、ディスクドライブなどのデバイス１５１に対して読み書きする不揮発性メモリインターフェース１５０も含めることができる。さらに、コンピュータ１１０には、ＣＤ−ＲＯＭまたはその他の光媒体などの取外し可能な不揮発性光ディスク１５６に対して読み書きする光ディスクドライブ１５５も含めることができる。この例示的な動作環境で使用することができるその他の取外し可能／取外し不可能な揮発性／不揮発性コンピュータ記憶媒体には、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどが含まれるが、これらに限定されるものではない。ハードディスクドライブ１４１は通常、インターフェース１４０などの取外し不可能なメモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は通常、インターフェース１５０などの取外し可能なメモリインターフェースを介してシステムバス１２１に接続される。
上記で説明し、図１Ａに図示したドライブおよびそれに関連するコンピュータ記憶媒体は、コンピュータ読み取り可能命令、データ構造体、プログラムモジュール、およびその他のデータの記憶領域をコンピュータ１１０に提供する。例えば、ハードディスクドライブ１４１が、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、およびプログラムデータ１４７を記憶するものとして示されている。これらは、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７と同一であってもよいし、異なるものであってもよい。オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、およびプログラムデータ１４７には、少なくともこれらが異なるコピーであることを示すために、本明細書では異なる符号が付与されている。ユーザは、キーボード１６２、および一般にマウス、トラックボール、またはタッチパッドと呼ばれるポインティングデバイス１６１などのユーザ入力デバイスに接続されたユーザ入力インターフェース１６０を介してコンピュータ１１０にコマンドおよび情報を入力することができる。その他の入力デバイス（図示せず）には、マイクロホン、ジョイスティック、ゲームパッド、衛星放送受信用パラボラアンテナ、スキャナなどを含めることができる。上記およびその他の入力デバイスは、システムバス１２１に結合されたユーザ入力インターフェース１６０を介して処理ユニット１２０に接続されることが多いが、パラレルポート、ゲームポート、またはＵＳＢなどの、その他のインターフェースおよびバス構造を介して接続されてもよい。
モニタ１９１またはその他のタイプのディスプレイデバイスも、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタ１９１の他に、コンピュータ１１０には、スピーカ１９４およびプリンタ１９３などの、出力周辺インターフェース１９２を介して接続することができる他の出力周辺デバイスも含めることができる。
コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードとすることができ、通常は、コンピュータ１１０に関して上述した要素の多数またはすべてを含むが、図１Ａにはメモリ記憶デバイス１８１だけが示されている。図１Ａに示された論理接続には、ローカルエリアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３が含まれるが、無線ネットワークなどの他のネットワークを含めることもできる。そのようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、およびインターネットでは一般的である。
ＬＡＮネットワーキング環境で使用される場合、コンピュータ１１０は、ネットワークインターフェースまたはネットワークアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用される場合、コンピュータ１１０には通常、インターネットなどのＷＡＮ１７３を介した通信を確立するモデム１７２またはその他の手段が含まれる。モデム１７２は、内蔵型または外付け型とすることができるが、ユーザ入力インターフェース１６０またはその他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク環境では、コンピュータ１１０に関して示されたプログラムモジュールまたはそのプログラムモジュールの一部を、リモートメモリ記憶デバイス１８１に記憶することができる。例えば、リモートアプリケーションプログラム１８５は、メモリデバイス１８１に存在するものとして示されているが、これに限定されるものではない。図示されたネットワーク接続は、例示的なものであり、コンピュータ間で通信リンクを確立するその他の手段を使用できることを理解されたい。
理解および例示の目的上、例示的なデータオブジェクトが表示される例示的なアプリケーションユーザインターフェースに関して、本発明の実施形態を説明することが有効である。図１Ｂに、１つまたは複数の表示されたデータオブジェクトを示す、例示的なワープロアプリケーションによって表示されている例示的なワープロ文書を示すコンピュータスクリーンディスプレイを示す。この例示的なユーザインターフェース１９５は、通常のソフトウェアアプリケーションユーザインターフェースを示している。ユーザは、この例示的なユーザインターフェース１９５に対し、関連するソフトウェアアプリケーションの機能に従って、１つまたは複数のデータオブジェクトを入力し、編集し、または他の形で操作することができる。例えば、ユーザインターフェース１９５は、「ファイル」コントロール（control）、「編集」コントロール、「表示」コントロール、および「その他」コントロールを含む、最上部の１つまたは複数の機能コントロールを有する例示的なワープロアプリケーションを示している。図１Ｂに示された機能コントロールは、例示のみを目的とし、本発明に適用可能なソフトウェアアプリケーションにおいて使用可能な膨大な数のユーザインターフェースタイプ、レイアウト、および関連する機能に関して限定的ではないことが理解されよう。
ユーザインターフェース１９５は、ユーザが望むようにユーザインターフェースワークエリア内に含まれるデータを上下にスクロールさせるスクロールバー１９９を含む。例示的なワープロ文書が、ユーザインターフェース１９５のワークエリア内に示されている。例示的な文書、例えば、手紙、メモ、レポートなどは、テキストオブジェクト１９６、埋め込み画像オブジェクト１９７、および埋め込みテーブルオブジェクト１９８を含む。図１Ｂを参照すると、ユーザインターフェース１９５に表示された文書は、テキストオブジェクト１９６がページの最上部になり、埋め込み画像オブジェクト１９７が２つのテキストオブジェクトの間に表示され、テーブルオブジェクト１９８がページの最下部に部分的に表示されるように、ユーザによってスクロールされたものである。すなわち、テーブルオブジェクト１９８は、視野に入りつつあるが、ユーザインターフェース１９５のワークエリア内に完全には表示されていない。
以下で詳細に説明するように、本発明の実施形態によれば、例示的なユーザインターフェース１９５および例示的なデータオブジェクト１９６、１９７、１９８を表示する役割を担うソフトウェアアプリケーションは、このアプリケーションによって要求される機能を提供するために、論理グループすなわちドメインに一緒にグループ化された関連するコンポーネントの集合またはグラフである。任意の所与のインスタンス（instance）において、アプリケーションには、そのインスタンスにそのアプリケーションの機能を提供するのに必要な関連するコンポーネントの論理グループ（本明細書ではドメインと呼んでいる）から構成されるランタイム構造が含まれる。アプリケーションが実行されるとき、コンポーネントドメインは、そのアプリケーションによって受信されるデータの変化と、データのその変化を処理するためにそのアプリケーションが要求する関連する機能とに基づいて、動的に再構成される。例えば、図１Ｂを参照すると、ユーザインターフェース１９５に現在表示されている文書の例示的なランタイム構造には、テキストオブジェクト１９６を表示して処理するのに必要なアプリケーションコンポーネントを有するテキストドメインが含まれることになる。上記の例示的なランタイム構造には、画像オブジェクト１９７を表示して処理するのに必要なアプリケーションコンポーネントを有する画像ドメインが含まれることになり、画像オブジェクト１９７の下に表示される第２のテキストオブジェクトを表示して処理するのに必要なアプリケーションコンポーネントを有する第２のテキストドメインが含まれることになり、入ってくる（incoming）テーブルオブジェクト１９８を表示するのに必要なアプリケーションコンポーネントを有するテーブルドメインが含まれることになる。当該ランタイム構造に関連するその他のコンポーネントドメインには、スクロールバー１９９の位置および移動、ユーザインターフェース内の機能コントロールの位置および表示プロパティ、ならびに現在必要な機能を提供するのに必要なアプリケーションの任意の他の態様を含む、他の機能のためのアプリケーションコンポーネントが含まれることになる。
以下で詳細に説明するように、データイベントがアプリケーションによって受信される当該アプリケーションの実行中に、コンポーネントドメインのランタイム構造は、データ駆動イベントに応答して、必要に応じて動的に再検証され、かつ／または再構成される。例えば、ユーザが、削除または他の変更のために画像オブジェクト１９７を選択する場合、アプリケーションは、このデータの変化をアプリケーション記述エンジンに渡し、アプリケーション記述エンジンは、画像オブジェクト１９７を表示する役割を担うコンポーネントドメインを動的に再構成する。その結果、そのコンポーネントドメインには、受信されたデータイベント、例えば画像オブジェクト１９７の削除または他の変更に基づいて、画像オブジェクト１９７を表示するのに適切なアプリケーションコンポーネントが含まれるようになる。新しい機能がアプリケーションによって要求される場合、例えば、テーブルオブジェクト１９８などの新しいデータオブジェクトがユーザインターフェース１９５内で視野に入る場合に、アプリケーションは、入ってくるデータオブジェクトを表示するのに必要な１つまたは複数のアプリケーションコンポーネントから構成される新しいコンポーネントドメインを生成するように、アプリケーション記述エンジンに要求する。
図２Ａは、アプリケーションとアプリケーション記述エンジンと１つまたは複数のコンポーネントドメインとの間の相互作用を示す機能図である。本発明の実施形態によれば、アプリケーションの１つまたは複数の機能を実行する、接続されたコンポーネントのグラフとしてアプリケーションを構成するアプリケーションフレームワークが提供される。図２Ａを参照すると、アプリケーション２０４、３０４は、それぞれのアプリケーションのプログラミングに従って１つまたは複数の有用な機能を提供する任意のソフトウェアアプリケーションを表していて、例えば、ワープロアプリケーション、スプレッドシートアプリケーション、スライドプレゼンテーションアプリケーション、データベースアプリケーション、デスクトップパブリッシングアプリケーション、電子メールおよびカレンダアプリケーションなどを表している。実際、本発明の実施形態は、以下の説明から理解されるように、特定のソフトウェアアプリケーションに限定されるものではない。
本発明の実施形態によれば、アプリケーション２０４、３０４は、複数のアプリケーションコンポーネントから構成され、各アプリケーションコンポーネントは、他のコンポーネントと独立に、または他のコンポーネントと関連して所与の機能を提供するために、ソフトウェア開発者によって作成されたものである。例えば、所与のアプリケーションコンポーネントは、関連するアプリケーションの印刷機能を提供するために、アプリケーション２０４、３０４に含めることができる。別のアプリケーションコンポーネントは、関連するアプリケーションの特定のフォーマッティング機能を提供するために、アプリケーション２０４、３０４に含めることができる。通常、アプリケーション２０４、３０４の所与の機能、例えば、フォーマッティング、印刷、編集、データ表示などは、一緒に動作するときに所望の機能を使用可能にして提供するアプリケーションコンポーネントの集合によって使用可能にされる。例えば、上記にて図１Ｂに示したテキストオブジェクト１９６または画像オブジェクト１９７を表示する所与のソフトウェアアプリケーションの機能には、要求された機能を提供するために特定の順序に従って実行されなければならない複数のアプリケーションコンポーネントが含まれる場合がある。上述したように、アプリケーション２０４、３０４は、いつでも、ランタイム構造の所与のインスタンスまたは所与の実行中のいずれであれ、接続されたアプリケーションコンポーネントの集合またはグラフである。様々なアプリケーションコンポーネントと、様々なアプリケーションコンポーネント間の相互作用との詳細な説明を、以下で図２Ｂ、図３、図４、図５を参照して説明する。
上記にて簡潔に説明したように、任意の所与のときに、アプリケーション２０４、３０４は、ランタイム構造を含み、このランタイム構造は、そのときにそのアプリケーションによって要求される接続されたアプリケーションコンポーネントのインスタンス化（instantiation）である。以下で説明するように、アプリケーションの実行中に、アプリケーションコンポーネントのインスタンス化は、そのアプリケーションによって受信されるデータに基づいて、アプリケーションの変更の必要性に応じて、動的に再構成される。アプリケーションコンポーネントの所与のランタイム構造を生成するために、アプリケーション２０４、３０４は、必要な各機能のアプリケーション記述をアプリケーション記述３１８からアプリケーション記述エンジン３２０に渡す。アプリケーション記述３１８と、アプリケーション記述エンジンの動作との詳細な説明を以下に示す。例えば、再度図１Ｂを参照すると、ユーザインターフェース１９５および関連するデータのランタイム構造のインスタンス化には、ユーザインターフェース１９５およびそれに関連する機能コントロールと、テキストオブジェクト１９６と、画像オブジェクト１９７と、入ってくるテーブルオブジェクト１９８とを表示するアプリケーションコンポーネント、およびスクロールバー１９９の現在位置を表示するアプリケーションコンポーネントを必要とする。
アプリケーション２０４、３０４は、アプリケーションによって現在要求されている機能のアプリケーション記述を、これらの機能のそれぞれを提供するのに必要なアプリケーションコンポーネントのグループ化を生成して構成するために、アプリケーション構成エンジンまたはアプリケーション記述エンジン３２０に渡す。本発明の一実施形態によれば、アプリケーションからアプリケーション記述エンジンに渡されるアプリケーション記述は、以下で図２Ｂおよび図３を参照して説明するように、拡張マークアップ言語（ＸＭＬ）に従って構成されフォーマットされた宣言ルールを含む。アプリケーション記述エンジン３２０は、アプリケーション２０４、３０４から受信された必要な各機能のアプリケーション記述を解釈するための十分なコンピュータ実行可能命令であって、必要な機能をアプリケーション２０４、３０４に提供するために、本明細書ではコンポーネントドメインまたはコンカレンシドメイン（concurrency domains）と呼ぶアプリケーションコンポーネントのグループをビルドして構成する、十分なコンピュータ実行可能命令を含むソフトウェアモジュールである。一実施形態によれば、アプリケーション記述エンジン３２０は、以下で図２Ｂ、図３、図４、図５を参照して説明するように、拡張マークアップ言語に従って動作する。アプリケーション記述エンジンの機能および動作は、以下で図３を参照しながら、見出し「アプリケーション記述言語」の下で詳細に説明する。
アプリケーション記述エンジン３２０が、アプリケーション２０４、３０４から、そのアプリケーションが必要とする機能に関連するアプリケーション記述を受信すると、アプリケーション記述エンジンは、記述された各機能、例えば、図１Ｂに示された画像オブジェクト１９７の表示を満たすのに必要なアプリケーションコンポーネントに関して、アプリケーション記述を解釈する。アプリケーション記述エンジンが、必要なコンポーネントと、必要なコンポーネント間の関係とを決定すると、アプリケーション記述エンジン３２０は、必要なコンポーネントインターフェースを含む必要なアプリケーションコンポーネントをコンポーネントライブラリ３２２から取得する。本発明の実施形態によれば、コンポーネントライブラリ３２２は、特定のアプリケーション、例えばワープロアプリケーションに関連するアプリケーションコンポーネントの集合またはライブラリとすることもできるし、アプリケーション記述エンジン３２０が、複数の様々なタイプのアプリケーション、例えば、ワープロアプリケーション、スプレッドシートアプリケーション、スライドプレゼンテーションアプリケーション、データベースアプリケーションなどに機能を提供するためのコンポーネントを取得できるコンポーネントの集合とすることができる。
アプリケーション記述エンジンが、必要なアプリケーションコンポーネント（例えば、ソフトウェアプログラムの個々のモジュール）を取得すると、アプリケーション記述エンジンは、アプリケーション２０４、３０４が現在要求している機能の各コンポーネントドメインを作成する。図２Ａに示されているように、図１Ｂに示されたデータに関するアプリケーション２０４、３０４の現在のデータ表示の必要性に応答して、アプリケーション記述エンジン３２０は、テキストオブジェクト１９６用の第１のコンポーネントドメイン２５０、画像オブジェクト１９７用の第２のコンポーネントドメイン２５５、およびテーブルオブジェクト１９８用の第３のコンポーネントドメイン２６０を作成する。すなわち、これらコンポーネントドメインの各々は、アプリケーションが現在必要とする機能を提供するのに必要なアプリケーションコンポーネントを各ドメインが含むように、アプリケーション記述エンジン３２０によって作成される。例えば、画像ドメイン２５５は、現在のディスプレイ特性およびプロパティを有する画像オブジェクト１９７を表示するためにアプリケーション２０４、３０４が必要とするアプリケーションコンポーネントを含むように、アプリケーション記述エンジン３２０によって生成される。図２Ａに示されたドメインは、図１Ｂに示されたデータオブジェクトについて生成され得るドメインを示すが、様々なデータオブジェクトが表示され、様々なユーザインターフェース機能が表示されるか、位置決めされるか、または他の形で構成されるアプリケーション２０４、３０４のランタイム構造の任意の他のインスタンスについて、ドメイン２５０、２５５、２６０の異なるセットが、必要に応じてアプリケーション記述エンジン３２０によって生成されることが理解されよう。
実施形態によれば、各コンポーネントドメインがアプリケーション２０４、３０４の実行管理のユニットとして動作する実行管理モデルが提供される。データイベントがアプリケーション２０４、３０４によって受信されるとき、以下で図２Ｂ、図３、図４、図５を参照して詳細に説明するように、アプリケーション２０４、３０４は、１つまたは複数の現在構成されているドメイン２５０、２５５、２６０を動的に再構成するために、または必要に応じて新しいドメインを作成するために、アプリケーション記述３１８をアプリケーション記述エンジン３２０に渡す。例えば、再度図１Ｂを参照すると、文書が上にスクロールされるときには、新しいデータがページの最下部に表示される。新しいデータが表示されるときに、アプリケーション２０４、３０４は、新しいデータオブジェクトを表示するために、アプリケーション記述エンジン３２０にコンポーネントドメインを要求する。例えば、テーブルオブジェクト１９８がスクロールされて見えるようになる前には、アプリケーション２０４、３０４は、図２Ａに示されたテーブルオブジェクトドメイン２６０を必要としない。というのは、現在は、アプリケーション２０４、３０４が、テーブルオブジェクト１９８を表示する機能を必要としないからである。しかし、アプリケーション２０４、３０４を動作させるオペレーティングシステム１３４が、テーブルオブジェクトがスクロールされて見えるようになりつつあることを検出すると、アプリケーション２０４、３０４には、オペレーティングシステムによって、テーブルオブジェクト１９８およびテーブルオブジェクト１９８に関連するデータが表示されなければならないことが通知される。その通知に応答して、アプリケーション２０４、３０４は、上述したように、入ってくるテーブルオブジェクト１９８に関するアプリケーション記述３１８をアプリケーション記述エンジン３２０に渡す。アプリケーション記述エンジン３２０は、このアプリケーション記述を解釈し、必要なアプリケーションコンポーネントを取得し、テーブルオブジェクトドメイン２６０を動的に作成する。このテーブルオブジェクトドメイン２６０には、入ってくるテーブルオブジェクト１９８を表示するのに必要なアプリケーションコンポーネントが含まれる。
同様に、図１Ｂに示された文書が上にスクロールされ、その結果、テーブルオブジェクト１９８がページの最下部から消えるようにスクロールする場合、アプリケーション２０４、３０４には、オペレーティングシステムによって、テーブルオブジェクト１９８の表示がもはや必要でないことが通知される。アプリケーション記述エンジンは、アプリケーション２０４、３０４から受信したアプリケーション記述３１８に応答して、アプリケーション２０４、３０４によるテーブルオブジェクト１９８の表示のために作成されたテーブルオブジェクトドメイン２６０を破棄する。というのは、テーブルオブジェクトを表示するために以前に必要であったこのコンポーネントドメインは、もはや必要ないからである。したがって、アプリケーション記述エンジンは、実行中のアプリケーション２０４、３０４の要件に基づいて、所与のコンポーネントドメインを動的に作成することもできるし、破棄することもできる。
アプリケーション２０４、３０４の実行中に、実行管理は、各コンポーネントドメインの動作およびコンポーネント構造を管理することによって達成される。図２Ａを参照すると、アプリケーション２０４、３０４の実行中に、所与のドメイン２５０、２５５、２６０の機能を呼び出すデータイベントがアプリケーション２０４、３０４によって受信されると、アプリケーション２０４は、それぞれのドメインを介してそのデータイベントを処理する。例えば、ユーザが、テーブルオブジェクト１９８内のデータ項目を選択し、その後、選択したデータ項目を削除するためにアプリケーション２０４、３０４の削除コントロールを選択した場合、選択したデータ項目および選択した削除コントロールに関連するデータイベントが、アプリケーション２０４、３０４によって受信される。当業者であれば、データ項目の選択および削除コントロールの選択は、アプリケーション２０４、３０４を動作させる役割を担うオペレーティングシステムによって検出され、そのデータイベントについての適切な通知が、アプリケーション２０４、３０４に対して行われることが理解されよう。
データイベントに応答して、アプリケーション２０４、３０４は、テーブルオブジェクト１９８に関連するデータイベントを処理する役割を担う適切なドメイン２６０にシングル処理スレッド２７５をディスパッチする。本明細書でコンカレンシドメインとも呼ぶ対象ドメインでは、シングル処理スレッド２７５は、コンポーネントのドメインに入り、一連のフェーズを経てデータイベントを処理する。ドメインのコンポーネントを介したデータ駆動イベントを処理するための対象ドメインへのシングル処理スレッドのディスパッチの詳細な説明については、以下で見出し「コンカレンシドメインを伴うマルチスレッディング」の下で示される説明を参照されたい。
現在の例について、削除コントロールが、選択したデータ項目をテーブルオブジェクト１９８から削除するために選択されると、シングル処理スレッドが、テーブル項目削除というアクションデータに応答して、ドメイン２６０にディスパッチされる。この処理スレッドがこのドメインに入ると、第１の処理フェーズ、すなわち、データ読み取り／データ要求フェーズが開始される。例えば、第１のフェーズ中に、データイベントが、コンポーネントドメイン２６０によって読み取られて、このデータ駆動イベントによって影響が及ぼされることになるテーブルオブジェクト１９８内のデータ項目またはデータ値が判定される。次に、第１の処理フェーズの一部として、データに対する変更、例えば、選択したデータ項目をテーブルオブジェクト１９８から削除する要求が、要求される。その要求に応答して、テーブルオブジェクトドメイン内のデータコネクタコンポーネントが、選択したデータ項目をテーブルオブジェクト１９８から削除する要求をセットアップする。データコネクタコンポーネントを含むアプリケーション２０４、２０５のコンポーネントの詳細な説明は、以下で図２Ｂ、図３、図４、図５を参照して提供する。データ読み取り／データ要求フェーズが完了すると、処理スレッドは、次の処理フェーズを開始できることを、ディスパッチャオブジェクト（以下で詳細に説明する）に通知する。
次の処理フェーズには、そのデータイベントに対応するコンポーネントドメインに対する変更がアプリケーション記述エンジンによって行われる、再検証／再構成フェーズが含まれる。再検証／再構成フェーズ中には、影響が及ぼされるデータに関連するすべてのデータコネクタコンポーネント、例えば、テーブルオブジェクト１９８から削除されるデータ項目に関連するデータコネクタコンポーネントに対して、再検証／再構成のために、これらのデータ項目をマークするよう通知される。一実施形態によれば、影響が及ぼされるデータのマーキングは、データ読み取り／データ要求フェーズのサブフェーズ中に行われる。
影響が及ぼされるすべてのデータアイテムがマークされると、再検証／再構成フェーズが進行し、マークされた各データ項目が、必要に応じて処理される。例えば、テーブルオブジェクト１９８から削除されるべきデータ項目が削除され、すべての関連するドメインコンポーネントが、必要に応じて削除されるか、または追加される。例えば、選択したデータ項目の削除の結果として、影響が及ぼされるドメイン２６０を構成する１つまたは複数のアプリケーションコンポーネントを除去する必要性が生じる場合、アプリケーション記述エンジンは、データイベントに応答して再検証フェーズ中にアプリケーション記述エンジンに渡されたアプリケーション記述３１８に応答して、これらのコンポーネントを除去するためにドメインを再構成する。その一方で、新しいアプリケーションコンポーネントが、影響が及ぼされるドメインに必要である場合、アプリケーション記述エンジンは、同様に、影響が及ぼされるドメインへの統合および影響が及ぼされるドメインの再構成のために、新しいアプリケーションコンポーネントを取得する。したがって、影響が及ぼされるコンポーネントドメインは、そのドメインに関連するデータイベントに基づいて、アプリケーションの実行中に動的に再構成される。コンポーネントドメイン２５０、２５５、２６０におけるデータイベントの処理に関して本明細書で説明する実行フェーズモデルの詳細な説明は、以下で見出し「アプリケーションフレームワークフェーズ化モデル」の下で提供する。
上述したように、各コンポーネントドメインは、アプリケーション２０４、３０４によるコンポーネントドメインに関する現在の必要性に基づいて、アプリケーション記述エンジン３２０によって構成される。また、上述したように、アプリケーション２０４、３０４の必要性が、データイベント、例えばデータオブジェクトの削除、データオブジェクトの追加、またはデータオブジェクトの変更に応答して変化するときに、必要に応じて、新しいコンポーネントドメインが作成されるか、既存のコンポーネントドメインが再構成される。所与のコンポーネントドメイン内の新しい各コンポーネントは、そのコンポーネントドメイン内の他のコンポーネントと等しい有効期間を有する。というのは、所与のコンポーネントドメインの有効期間は、アプリケーション記述エンジンによるそのドメインのインスタンス化またはアプリケーション記述エンジンによる再構成の際に始まり、そのコンポーネントドメインがアプリケーション記述エンジンによって破棄されるか、またはその後に再構成されるときに終わるからである。したがって、所与のコンポーネントドメインは、そのコンポーネントドメインが特定の構成で存在する時間の間に生存し、そのコンポーネントドメインが後続の再構成の際に終了する、すなわち死ぬ、アプリケーション機能および管理のユニットであり、そのコンポーネントドメインの後続の再構成されたバージョンは、アプリケーション実行管理の目的上、新しいコンポーネントドメインとみなされる。
上記にて、接続されたコンポーネントの集合またはグラフとしてソフトウェアアプリケーションを構成し、１つまたは複数のコンポーネントドメインを介してアプリケーションの構造および実行を管理するアプリケーションフレームワークを説明したので、以下では、所与のアプリケーションを構成するコンポーネントと、コンポーネント間の通信との詳細な説明を、図２Ｂ、図３、図４、図５を参照しながら提供する。さらに、図２Ｂ、図３、図４、および図５の次の説明は、上述したアプリケーションフレームワークの例示的な実施形態の説明を提供する。このアプリケーションフレームワークは、拡張マークアップ言語（ＸＭＬ）に基づくものである。ＸＭＬアプリケーションフレームワーク（ＸＡＦ）は、上述したように、ソフトウェアアプリケーションを実行して、作成する方法およびシステムを提供する。ＸＡＦは、データ変更、データイベント、ＵＩイベント、またはソフトウェアシステム内におけるその他のすべての事象を、標準フォーマットで表す標準言語に基づいて構築される。
例示的な実施形態において、ＸＡＦは、ＸＭＬ（拡張マークアップ言語）を使用して、ＸＭＬデータとしてデータを表し、ＸＭＬアプリケーションとしてアプリケーションを表す。以下の説明において、ＸＭＬは、標準言語を表すのに使用される。しかし、当業者であれば、本発明は、ＸＭＬを使用することだけに限定されないことが理解されよう。
ＸＡＦソフトウェアシステムは、データに焦点を合わせたものであり、データ駆動型であり、強力なデータ変換機能を提供する。このデータ変換機能には、相互に知らないソースからの異種データとの相互作用が含まれるが、これに限定されるものではない。ＸＡＦのすべての部分を、アプリケーションの挙動およびアプリケーションのユーザインターフェースを含めて、データを対象とするイベントまたはデータを伴うイベントとして説明することができる。ＸＡＦは、アプリケーションがデータ作成側であり、データが作成物であるというパラダイムを放棄する。そうではなく、ＸＡＦは、データに基づいてアプリケーションをビルドする。本発明の実施形態では、ＸＡＦアプリケーションコンポーネントは、データがどのように表示され、データが何であり、データがどのように記憶されるかに基づいて、実際にインスタンス化され相互接続される。したがって、ＸＡＦは、特定のデータを正しい形で処理するために、ランタイムに「正しい」コンポーネントを作成して、結合することができる。
アプリケーションをビルドする際、ＸＡＦにより、アプリケーション「作成者」は、データ型およびユーザインターフェース（ＵＩ）に基づいて、コンポーネントをどのように作成して、接続するかに関するルールを提供することができる。これらのルールおよびコンポーネントは、ＸＭＬで記述することができる。ＸＭＬは、現在のコンテキストに高感度である、リッチかつ構成可能なＵＩを可能にし、ソフトウェア開発者が構成的手法でアプリケーションをビルドすることを可能にする。ソフトウェア作成者は、ハードコーディングされたアプリケーションロジックの必要性を減らす宣言モデルにおいてエンドツーエンドに特徴またはアプリケーションをビルドすることができる。例えば、ソフトウェア作成者は、単純に、あるＵＩコネクタが、あるＵＩおよびあるアクションと組になることを宣言する。次に、ＸＡＦが、そのＵＩコネクタを、そのＵＩおよびそのアクションと一緒に接続する。
さらに、ＸＭＬアプリケーションフレームワークは、予めビルドされたコンポーネント、アプリケーション特徴、および例示的なアプリケーションのリッチライブラリ（rich library）を提供する。一部の命令コードがまだ必要ではあるが、ＸＡＦは、コンポーネントをライブラリに配置する。このライブラリにより、その他のソフトウェア作成者は、宣言モデルにおいて、これらのコンポーネントを使用または利用することができる。したがって、ソフトウェア開発者は、コンポーネントの新しい命令コードを生成することによって、ソフトウェア開発者自身のコンポーネントを作成することができるが、ソフトウェア作成者は、新しい命令コードを生成することなく、予めビルドされたコンポーネントを使用して、新しいアプリケーションまたは変更されたアプリケーションを構成することもできる。
例示的なＸＭＬアプリケーションフレームワーク２０２を、図２Ｂに示す。ＸＡＦ２０２は、アプリケーション２０４などのアプリケーションを構成し、その実行を管理するように動作する。ＸＡＦ２０２内で実行されるアプリケーション２０４は、１つまたは複数のＵＩコネクタ２０６、１つまたは複数のアクション２０８、および１つまたは複数のデータコネクタ２１０を含む。いくつかの実施形態では、アプリケーション２０４は、１つまたは複数のアクセッサ２１２、あるいは１つまたは複数のトランスフォーマ２１４および／または２１６も含む。アプリケーション２０４内のコンポーネントは、ＵＩイベントをデータ変化に変換し、データ変化をＵＩイベントに変換するように動作する。したがって、ＵＩコネクタ２０６は、１つまたは複数のＵＩ２１８および／または２２０に結合される。さらに、データコネクタ２１０は、１つまたは複数のデータストア２２２および／または２２４に結合される。ＸＡＦ２０２内では、アプリケーション２０４におけるデータイベントまたはデータ表現は標準フォーマットである。例えば、データイベントおよびデータ表現はＸＭＬである。
ＵＩコネクタ２０６は、アプリケーション２０４と、１つまたは複数のＵＩ２１８および／または２２０との間の接続をもたらす。一実施形態において、ＵＩ２１８および／または２２０は、情報をユーザに表示するグラフィカルユーザインターフェース（ＧＵＩ）である。ＵＩコネクタ２０６は、アプリケーションユーザがＸＡＦ２０２内でデータを編集する機能を提供し、サポートする。ＵＩコネクタ２０６は、（データコネクタ２１０と、データストア２２２および／または２２４とによって表される）ＸＡＦデータレイヤと、特定のＵＩ２１８および／または２２０との間でデータをマッピングする。さらに、ＵＩコネクタ２０６は、ＵＩ２１８および／または２２０からのＵＩイベントを、データストア２２２および／または２２４内のデータ編集動作にマッピングする。
ＵＩコネクタ２０６は、ＵＩ２１８および／または２２０内のＵＩ要素のタイプに固有である。したがって、ＵＩ２１８および／または２２０内のデータ項目のＵＩ表現ごとに、対応するＵＩコネクタ２０６が存在する。一例では、ＵＩ２１８および／または２２０内に表示される、スプレッドシート内のセル値などのデータ要素は、そのデータ要素に結合された特定のＵＩコネクタ２０６を有し、このＵＩコネクタ２０６は、そのデータ要素に対するユーザ変更をＵＩイベントに変換して、ＸＡＦデータに対するアクション２０８に接続する。したがって、ＵＩコネクタ２０６は、特定のＵＩイベントをＸＡＦアクション２０８に変換し、このＸＡＦアクション２０８は、包括的にＸＡＦアプリケーション２０４内で表される。一実施形態においては、アプリケーション２０４内のすべてのデータ変化が、ＸＭＬデータ変化として表される。別の例では、ユーザが、スクロールバーなどのユーザインターフェースコントロールを操作することができる。スクロールバーの変化により、ＵＩ２１８および／または２２０の状態変化が生成される。ＵＩ状態変化も、データ変化として表すことができる。したがって、ＵＩコネクタ２０６は、スクロールバー操作などのＵＩイベントを受信し、そのＵＩイベントをＸＡＦデータレイヤのＸＭＬデータ変化イベントに変換することができる。
ＵＩコネクタ２０６は、ＵＩイベントをアクション２０８に接続する。アクション２０８は、ＸＡＦデータレイヤ内のデータ変化に関する宣言ステートメントである。例えば、スクロールバーのユーザ操作により、「スクロールバー上でのクリック」イベントが生成される。ＵＩコネクタ２０６は、このＵＩイベントを、「スクロールバーを下に１ポジション分だけ増分する」といったアクション２０８に接続する。一実施形態において、データ変化アクションは、ＸＭＬで表される。例えば、あるデータ変化が、以下のＸＭＬステートメントとして現れる場合がある：
<Dropdown data = $taskpanelist>
<copy Deltaaction perform = "on selected change"
data = "selected value"
target = "current taskPane" />
<Dropdown data = $taskpanelist>
<copy Deltaaction perform = "on selected change"
data = "selected value"
target = "current taskPane" />
データコネクタ２１０は、外部データストア２２２および／または２２４との間でデータをマーシャリングする（marshal）。ＵＩコネクタ２０６と同様に、データコネクタ２１０は、内部ＸＡＦデータ表現と、異なるデータストア２２２および／または２２４内の外部データ型との間で変換する。したがって、外部データの型ごとにデータ固有のデータコネクタ２１０が存在する。データコネクタ２１０は、アクション２０８を受信し、標準フォーマットのＸＡＦデータアクション２０８を、データストア２２２および／または２２４内のデータに影響を及ぼすデータ固有アクションに変換する。一実施形態において、データコネクタ２１０は、ＸＭＬデータアクションをデータ固有アクションに変換する。例えば、標準フォーマットＸＭＬステートメントによって表されるスクロールバー操作は、インターフェース状態固有データ変化に変換され、特定のインターフェース状態データを記憶するデータストア２２２または２２４に送信される。
さらに、データコネクタ２１０は、データストア２２２および／または２２４内の変化を標準フォーマットＸＡＦデータ表現に変換し、この標準フォーマットＸＡＦデータ表現がＵＩコネクタ２０６に送信される。ＵＩコネクタ２０６は、標準フォーマットＸＡＦデータ表現をＵＩイベントに変換し、このＵＩイベントがＵＩ２１８および／または２２０に送信される。したがって、ＵＩ２１８および／または２２０内のすべての変化について、ＵＩコネクタ２０６は、ユーザインターフェースイベントをアクション２０８に接続する。このアクション２０８は、データコネクタ２１０に送信され、データコネクタ２１０は、アクション２０８をデータストア２２２および／または２２４内のデータ固有変化に変換する。データが変更されると、データコネクタ２１０は、データストア２２２および／または２２４内の変更されたデータを標準フォーマットＸＡＦデータ表現に変換する。データコネクタ２１０は、このＸＡＦデータ表現をＵＩコネクタ２０６に返信し、ＵＩコネクタ２０６は、このＸＡＦデータ表現をＵＩ固有ディスプレイイベントに変換する。ＵＩコネクタ２０６は、表示のために、このＵＩ固有ディスプレイイベントをＵＩ２１８および／または２２０に送信し、ＵＩ２１８および／または２２０は、ＵＩイベントから生成された変更されたデータを表示する。
アプリケーション２０４は、アプリケーション２０４内で発生するすべてのアクションについて、データとＵＩイベントとの間のこれらのサイクルする変化の処理を継続することができる。いくつかの実施形態においては、データストア２２２および／または２２４でのデータの変化も、ユーザの制御外にある別の動作から強制される変更されたデータなど、ユーザイベントの発生なしでＵＩ２１８および／または２２０内の変化を強制する。
アプリケーション２０４内のいくつかのオプションのコンポーネントには、アクセッサ２１２と、トランスフォーマ２１４および／または２１６とが含まれる。アクセッサ２１２は、アクション２０８とデータコネクタ２１０との間で調節する。あるデータストア２２２および／または２２４内のある型のデータにアクセスするために、アクション２０８は、そのデータについて使用されるアクセッサ２１２または「アクセスモデル」を指定することができる。アクセッサ２１２は、アプリケーション２０４が、ＪＰＥＧ、ＭＰＥＧなど、同種でない特定のデータの型にアクセスすることを可能にする。したがって、データストア２２２および／または２２４内のデータの型にかかわらず、アプリケーション２０４は、そのデータとインターフェースをとり、そのデータを変更する。アクセッサ２１２は、データコネクタ２１０が、まだ考案も開発もされていないデータ型を含む任意のデータ型を管理することを確実にする。アクセッサ２１２は、標準フォーマットアクションを、標準フォーマットであり、かつデータ用にカスタマイズされたアクションに変換する。
他の実施形態では、１つまたは複数のトランスフォーマ２１４および／または２１６が、データコネクタ２１０とＵＩコネクタ２０６との間で調節する。トランスフォーマ２１４および／または２１６は、表示のために、データコネクタ２１０から出力されるデータを、ＵＩコネクタ２０６が必要とするＵＩ用にカスタマイズされたフォーマットに変更する。例えば、ＵＩコネクタ２０６が、データをリストとして必要とする場合、トランスフォーマ２１４および／または２１６は、１つまたは複数の単純な変更を介して、表形式データをデータのリストに変更することができる。この単純な各変更は、単一のトランスフォーマ２１４および／または２１６によって実行される。したがって、データコネクタ２１０によって出力される任意の形のデータは、１つまたは複数のカノニカルな（canonical）トランスフォーマ２１４および／または２１６を介して、ＵＩコネクタ２０６によって受入れ可能であり、かつ使用可能である形に変換することができる。トランスフォーマ２１４、２１６などのトランザクション変換のオペレーションに関する詳細な説明については、以下の見出し「トランザクション変換」の下の説明を参照されたい。
本発明の実施形態に従う他のタイプの変換を利用することができる。例えば、関数変換（functional transform）を、ＸＱｕｅｒｙなどの関数言語（functional language）を使用して記述することができる。プロキシ変換は、位置のリストの形をとり、これらの位置で見つかるデータをエイリアス化されたデータのシーケンスの形でプロキシする。ソルバ変換は、専用ソルバ技術を具現化し、効率性のため、キャッシングをサポートする。例えば、あるソルバ変換は、代数方程式系を数値的に解き、別のソルバは、これら代数方程式系を記号的に解く。キャッシングおよびインデクシング変換は、データレベルでのパススルー（pass-through）変換であり（すなわち、出力データは入力データと等しい）、キャッシングおよびインデックス変換は、ダウンストリームのインデクシングされたアクセスを加速するために、指定された次元でキャッシングおよびインデクシングを追加する。
本発明の実施形態によれば、アプリケーションフレームワークは、本明細書で説明する、アプリケーションのコンポーネント間で共通インターフェースを使用する。このフレームワークは、本明細書で説明する様々なコンポーネント間のデータ通信に依存するので、ＸＭＬなどの均一なデータ構造体、およびコンポーネント間の共通インターフェースは、アプリケーションの構成および管理のために、効率的なデータ交換を可能にする。
次に図３を参照すると、本発明の実施形態では、ＸＡＦ３００は、図３に示されているように、複数のアプリケーション３０２および／または３０４を含む。より大きいアプリケーション３０２には、サブモジュールまたはサブコンポーネントとして機能する１つまたは複数のアプリケーション３０６および／または３０８を含めることができる。すべてのアプリケーション３０２および／または３０４は、より大きいアプリケーションであれサブコンポーネントであれ、ＵＩコネクタ２０６などのＵＩコネクタと、アクション２０８などのアクションと、データコネクタ２１０などのデータコネクタとを有する。したがって、アプリケーション３０６および／または３０８は、あるデータ要素３１４および／または３１６と、あるＵＩ要素３１０および／または３１２との間で動作するソフトウェアモジュールである。アプリケーション３０２および／または３０４は、複数の他のアプリケーション３０２および／または３０４と共に動作できるという点でマルチスレッド式とすることができる。さらに、以下で詳細に説明するように、アプリケーション３０２および／または３０４、あるいはアプリケーションコンポーネント３０６および／または３０８を、あるフェーズまたはドメインに制約することができる。
本発明の実施形態では、ＸＡＦ３００は、ＸＭＬアプリケーション記述（ＸＡＤ）３１８およびＸＭＬアプリケーション記述（ＸＡＤ）エンジン３２０を含む。ＸＡＤ３１８は、アプリケーション３０４など、ＸＡＦ３００内に含まれるすべてのアプリケーションの宣言ルールおよび記述を含む。ソフトウェア作成者は、そのソフトウェア作成者が望むアプリケーションのＸＡＤ３１８を作成する。ＸＡＤ３１８は、あるソフトウェアコンポーネントをプルする（pull）かインスタンス化してこれらのコンポーネントを一緒にバインドするための、スキーマおよびタグを含む。本発明の実施形態では、スキーマおよびタグは、コンポーネント群がどのように相互作用するかに関する。コンポーネントは、ＵＩコネクタ、アクション、アクセッサ、データコネクタ、トランスフォーマ、またはその他のソフトウェアコンポーネントとすることができる。いくつかの実施形態では、コンポーネントは、命令コードを用いて記述され、ポイント別の（point-wise）機能をアプリケーションに提供する。したがって、コンポーネントは、ＵＩコネクタ、アクション、データコネクタなど、ＸＡＦコンポーネントにオペラビリティを提供する、基礎になるソフトウェアとすることができる。
アプリケーション記述３１８は、他のフォーマットを使用して表現することができるが、一実施形態では、ＸＡＤ３１８はＸＭＬで表現される。タグはＸＭＬタグである。スキーマおよびタグは、ルールを宣言するための構文的かつ意味論的（syntactic and semantic）フレームワークを提供する。ＸＡＤは、アプリケーション作成者がアプリケーション全体のリソースおよびコマンドを宣言することを可能にする。コマンドは、マウスクリック、キーボード選択、音声コマンドなどのイベントに基づいて実行されるコードの一部分である。実施形態では、ユーザが、ユーザインターフェース内でイベントを作成するが、他の実施形態では、何らかのプロセスによる別のアクションが、イベントを作成することもある。コマンドは、図１７と関連させて以下で説明するように、例えば、選択範囲変更アクション、ビュー編集アクション、データ取り出しアクション、および入力編集アクションなど、名前付きアクションの形とすることができる。これらの名前付きアクションは、例示のためのものであり、本発明の実施形態に適用可能なコマンドおよび／または名前付きアクションに関して限定的なものではない。
ＸＡＤ３１８は、ＸＡＤエンジン３２０によって解析される。最初に、ＸＡＤエンジン３２０は、アプリケーションが起動されるときにＸＡＤ３１８を解析する。その後、ＸＡＤエンジン３２０は、必要なときにＸＡＤ３１８を解析する。例えば、一実施形態によれば、ＸＡＤ３１８は、プラグインコンポーネントをインスタンス化し、接続するときなど、アプリケーションを再構成するために、ＸＡＤエンジン３２０によってランタイムに解析される。別の実施形態によれば、ＸＡＤがコンパイル時に解析され、トークンのシーケンスに変換され、このシーケンスがランタイムにＸＡＤエンジンによって解釈される、コンパイルモデルが提供される。コンパイルしないときには、ＸＡＤがメモリにロードされるときに、テキスト解析が実行され、データ構造体として記憶される。
ＸＡＤエンジン３２０は、ルールを処理し、リソースを識別し、コンポーネントをインスタンス化し、コンポーネント、コンポジット（composite）、およびコマンドを接続する。コンポーネントおよびリソースは、Ｃ＃で記述された実行可能コードなどの命令コードとすることができる。命令コードは、ＵＩコネクタ、アクション、データコネクタ、およびその他のＸＡＦコンポーネントの基礎となる実際のソフトウェアコンポーネントおよびソフトウェアクラスを特徴付ける。コンポーネントは、コンポーネントライブラリ３２２などのコンポーネントライブラリからプルされる。コンポーネントライブラリ３２２は、ＸＡＦ３００内のすべてのアプリケーションにおいて使用されるすべてのコンポーネントを保持する。
コンポーネントライブラリ３２２内のコンポーネントの集合全体が、どのアプリケーションからも使用可能である。したがって、ＸＡＦ３００は、アプリケーションコンポーネントと、これらのコンポーネントを作成するコードとの豊富な共有を可能にする。さらに、ソフトウェア開発者が新しいコンポーネントを作成でき、その新しいコンポーネントをコンポーネントライブラリ３２２に記憶できるので、ＸＡＦは非常に拡張可能である。ＸＡＤエンジン３２０は、ＸＡＤ３１８内でソフトウェア作成者が作成する新しいルールを読み取ることによって、新しいコンポーネントを呼び出し、インスタンス化し、接続することができる。新しいルールおよび新しいコンポーネントは、新しいＸＡＦコンポーネント、新しいデータ型、新しいデータストア、新しいＵＩ、あるいは新しいアプリケーションさえも形成することができる。ＸＡＤおよびＸＡＤエンジンについては、以下でさらに詳細に説明する。
ユーザイベントを実行する方法４００の実施形態を、図４に示す。この実施形態では、ユーザイベント動作４０２がまず発生する。しかし、当業者であれば、方法４００を使用して、ユーザイベントに対応しないデータ変化を実行できることが理解されよう。説明したように、アプリケーションによって受信されるデータ変化またはデータイベントは、ユーザアクションによって、例えばユーザインターフェース内の機能ボタン、機能コントロール、またはデータオブジェクトのユーザ選択に応答して、生成されるものとすることができる。データイベントは、外部変化によって、例えば、外部プロセスの実行の結果として、または別のアプリケーションもしくはサードパーティソースからアプリケーションによって受信されるデータによって生成されるものとすることもできる。さらに、図２Ｂと関連させて上述したように、ユーザイベントは、ＵＩ２１８などのＵＩ内でユーザが実行する任意の変化または対話とすることができる。接続動作４０４において、ＵＩコネクタ２０６などのＵＩコネクタにてユーザイベントを受信し、そのユーザイベントを、アクション２０８などの対応するアクションに接続する。
提供動作４０６において、アクションにおいて表されるデータ変更の標準フォーマットアクションが提供される。一実施形態では、ＸＭＬステートメントが、データ変更に関するアクションを表す。一実施形態では、オプションの支援動作４０８において、アクションをアクセッサ２１２などのアクセッサに接続して、変更される特定のデータに関するアクションを構成するのを支援する。アクセッサは、データ固有アクションをデータコネクタ２１０などのデータコネクタに送信する。変換動作４１０において、データ固有アクションを受信し、ＸＭＬステートメントとすることができるこの標準フォーマットアクションを、データストア２２２などの特定のデータストア用のコードおよびデータ固有動作に変換する。
データ変更は、データストア内で行われる。次に、データコネクタが、変更されたデータをデータストアから読み取る。変更されたデータは、ＸＭＬデータ表現などの標準フォーマットデータ表現に変換される。オプションで、その後、標準フォーマットデータ表現が、トランスフォーマ２１４などのトランスフォーマに送信される。オプションの変更動作４１２において、トランスフォーマが受信したデータレコードをＵＩ固有データステートメントに変更する。例えば、データ変化が、そのデータをソートされたリストとして表示することを必要とする場合がある。１つまたは複数のトランスフォーマは、取り出されたデータをソートし、そのデータをソートされたリストとして提示させる最終的なデータステートメントを作成することができる。次に、トランスフォーマは、変更され変換されたデータをＵＩコネクタ２０６などのＵＩコネクタに提供する。
次に、接続動作４１４において、変更されたデータを受信し、ＵＩコンポーネントに接続して、変更されたデータを表示し、提供する。したがって、その時には、ＵＩは、変更されたデータのビューを提供する。一実施形態において、データ変化は、ユーザインターフェース状態とすることができ、変更されたデータの表示は、変更されたユーザインターフェースの表示である。ユーザイベント動作４０２に戻って継続するフローによって表されるように、イベントを受信し、データの変化に影響を及ぼし、変更されたデータを表示するというプロセス４００は、反復的であり、ユーザイベントごと、またはデータ変化ごとに繰り返して実現することができる。データ変化またはデータイベントが、アプリケーションの再構成を引き起こすか、または必要とする場合、図５と関連させて以下で説明するように、新しいコンポーネントを作成し、接続し、かつ／または再構成することができる。
アプリケーションを作成して構成する方法５００の実施形態を、図５に示す。起動動作５０２において、アプリケーション２０４などのアプリケーションを起動する。一実施形態では、ユーザが、アプリケーションアイコンをクリックすることによるなどして、ユーザイベントを介してアプリケーションを起動する。解析動作５０４において、ＸＡＤ３１８などのＸＡＤを解析する。一実施形態において、この解析は、ＸＡＤ内のスキーマおよび／またはルールを識別して、処理する。
識別動作５０６において、アプリケーションに必要なリソースおよび／またはコンポーネントを識別する。一実施形態において、コンポーネントおよびリソースは、コンポーネントライブラリ３２２などのコンポーネントライブラリ内で見つけられる。インスタンス化動作５０８において、コンポーネントをインスタンス化する。一実施形態では、ＸＡＤエンジン３２０などのＸＡＤエンジン内のヘルパコード（helper code）が、コンポーネントライブラリ内で識別されたコンポーネントを形式的にインスタンス化する。さらなる実施形態では、一時的なクリエータコンポーネント（creator components）のセットが、インスタンス化される。次に、クリエータコンポーネントが、入力データと、ＸＡＤ内のタグに関連するルールとに関して、処理コンポーネントをインスタンス化する。
接続動作５１０において、インスタンス化されたコンポーネントを接続する。一実施形態では、ＸＡＤエンジンが、使用されるデータまたは処理されるユーザイベントに従ってコンポーネントを接続する。アプリケーションコンポーネントがインスタンス化されて接続されると、待機動作５１２において、ユーザイベントを待つ。したがって、ＸＡＤエンジンは、アプリケーションとの受動的プレゼンス（passive presence）を維持する。ＸＡＤエンジンは、データ変化を継続的に監視し、データコネクタ２１０などのデータコネクタによって提供されるデータの変化に応答する。データが変化するときに、判定動作５１４において、データ変化が、プラグインコンポーネントの挿入など、アプリケーションの再構成を必要とするかどうかを判定する。再構成が必要である場合、フローは、Ｙｅｓから解析動作５０４に継続する。再構成が不要である場合、フローは、Ｎｏから待機動作５１２に継続する。
本明細書で説明するように、所与のソフトウェアアプリケーションのランタイム構造を生成し、ソフトウェアアプリケーションの実行を管理するアプリケーションフレームワークが提供される。次の記載は、トランザクション変換の動作および機能と、フェーズモデリングおよびスレッディングを介したコンポーネントドメイン処理と、アプリケーションコンポーネントの生成および再構成に関するアプリケーション記述エンジンの動作とを含む、上述した本発明の実施形態の様々な態様の詳細な説明である。
（トランザクション変換）
上述したように、１つまたは複数のデータストアが、１つまたは複数のコネクタを介してデータを受信して記憶するために設けられる。本発明の実施形態によれば、データは、１つまたは複数の「トランザクション変換」の使用により、データストアから選択的に分離することができる。図６に、データレイヤの編成を示し、データレイヤと、データストアおよびデータクライアントを含むその他のコンポーネントとの間の接続を示す。トランザクション変換６１４は、バッファリングモジュール６１６および制御モジュール６１８を含む。バッファリングモジュール６１６は、分離されたデータと、そのデータに関するステータス情報とを記憶する。制御モジュール６１８は、失敗したコミットがデータ消失をもたらさないように、バッファリングモジュール６１６と共に２フェーズコミットプロトコルを使用する。バッファリングモジュール６１６および制御モジュール６１８については、以下でより詳細に説明する。
上述したように、１つまたは複数のデータストアが、１つまたは複数のコネクタを介してデータを受信して記憶するために設けられる。本発明の実施形態によれば、データは、１つまたは複数の「トランザクション変換」の使用により、データストアから選択的に分離することができる。図６に、データレイヤの編成を示し、データレイヤと、データストアおよびデータクライアントを含むその他のコンポーネントとの間の接続を示す。トランザクション変換６１４は、バッファリングモジュール６１６および制御モジュール６１８を含む。バッファリングモジュール６１６は、分離されたデータと、そのデータに関するステータス情報とを記憶する。制御モジュール６１８は、失敗したコミットがデータ消失をもたらさないように、バッファリングモジュール６１６と共に２フェーズコミットプロトコルを使用する。バッファリングモジュール６１６および制御モジュール６１８については、以下でより詳細に説明する。
データストア６０２および６０４は、データベースサーバ上のデータまたはコンピュータ読み取り可能な媒体上のデータを含む。データは、上述したように、データストアから読み取り、データストアに書き込むことができる。所与のデータストアに接続されたエージェントにより、チェックまたは何らかのその他の要求を送信して、データストアへのデータの書き込みが可能であるかどうかを調べることができる。データの書き込みが可能である場合、肯定指示がエージェントに戻して渡される。同様に、データの書き込みが不可能であるか、または可能であるかがわからない場合、否定指示がエージェントに戻して渡される。
データコネクタ６０６および６０８は、データ変換６１０、６１２、および６１４をデータストア６０２および６０４に接続する。一実施形態では、１つまたは複数のタイプのデータストアを扱うために、プロトコルがデータコネクタ６０６および６０８内で実装される。各プロトコルは、特定のフォーマットを使用してエンコードされたデータベースファイルなどの、１つまたは複数のタイプのデータストアを扱う。データコネクタプロトコルは、データクライアント６２２および６２４から受信したデータ変更またはデータ変化をアトミックにコミットする。図２Ｂを参照して上述したＵＩコネクタ２０６が、データクライアント６２２、６２４の例である。
一実施形態において、データコネクタ６０６および６０８は、ペシミスティックコンカレンシ（pessimistic concurrency）によってアトミシティ（atomicity）を実現する。ペシミスティックコンカレンシは、クライアントが他のクライアントに影響を及ぼすようにデータを変更するのを防ぐために、データストアにてデータ（例えば、１つまたは複数のレコード）のサブセットをロックすることを含む。ペシミスティックコンカレンシモデルでは、クライアントが、ロックの適用を引き起こすアクションを実行するときに、他のクライアントは、ロックを所有するクライアントがそのロックを解放するまで、ロックを競合するアクションを実行することができない。データに関する激しい競合があり得る環境、および／または、ロックを用いてデータを保護するコストが、コンカレンシ競合が発生する場合にトランザクションをロールバックするコストより低い環境において、このモデルは有用である。ペシミスティックコンカレンシは、レコードのプログラム的処理など、ロック時間が短くなるときに、最もよく使用される。
別の実施形態において、データコネクタ６０６および６０８は、補償アクション（compnesation action）と共にオプティミスティックコンカレンシ（optimistic concurrency）を使用してアトミシティを実現する。オプティミスティックコンカレンシは、ロックを利用しない。第１のクライアントがレコードを更新する必要があるときに、このプロトコルは、別のクライアントが、第１のクライアントによる最後の読み取り以降にそのレコードを変更したかどうかを判定する。オプティミスティックコンカレンシは、データ競合がほとんどない環境において有用である。補償アクションは、トランザクションの影響を補償するアクションである。例えば、口座Ａから口座Ｂへの資金の銀行転送に関する補償効果は、口座Ｂから口座Ａに戻す同一金額の資金の転送である。同様に、ホテルルームの予約の補償アクションは、予約の取り消しになる。補償アクションは、トランザクションを「ロールバック」すること、または後に残る副作用も他の否定的な結果もなしに取り消すことを可能にする。補償アクションは、２つのクライアント間で競合が生じる（例えば、第１のクライアントがデータ値を読み取り、その後、第２のクライアントが、第１のクライアントがその値の変更を試みる前にそのデータ値を変更する）ときに、トランザクションをロールバックするのに使用することができる。一実施形態において、データコネクタ６０６および６０８は、それぞれデータストア６０２および６０４からのデータをキャッシュする。データクライアントによって要求されたデータが、データコネクタによってキャッシュされている場合、要求されたデータについて対応するデータストアに照会する必要はない。データコネクタについては、以下でより詳細に説明する。
データ変換６１０、６１２、６１４、および６２０は、予め定義されたルールに従ってデータをエンコードし、かつ／またはデコードする。データ変換６１０、６１２、６１４、および６２０は、任意に複雑な処理を実行できる機能を実施する。データ変換６１２および６２０は、互いに直列である。このため、データ変換６１２によって実施される機能の結果は、データ変換６２０によって実施される機能への入力として使用され、逆も同様である。一実施形態において、データ変換を直列に接続して、前の変換の結果をバッファリングすることができ、複雑な機能をより簡単にモジュール式として実施することが可能になる。同様に、ビュー内のデータのサブセットを、そのビュー内の残りのデータに影響を及ぼすことなくコミットするか、またはリフレッシュすることができる（以下を参照されたい）。
データ変換６１４は、トランザクション変換として知られる特別な種類のデータ変換であり、バッファリングモジュール６１６および制御モジュール６１８を含む。一実施形態において、トランザクション変換は、データがデータストア間で一貫するように、分離されたデータをアトミックにコミットすることを可能にする。バッファリングモジュール６１６は、データクライアント６２２および６２４からの分離されたデータを保持する。一例では、データクライアント６２２および６２４は、データストア６０４内のデータを編集するダイアログボックスである。データに対して行われる編集を、実質的に編集が行われるときにバッファリングモジュール６１６に記憶することができる。別の実施形態では、トランザクション変換は、そのトランザクション変換の出力に対する編集要求を、そのトランザクション変換の入力に対する編集要求に戻ってマッピングする。その結果、編集が行われるときに、入力／要求するエンティティは、そのような編集を完了したものとして認識する。さらに、これらのトランザクション変換は、そのバッファリングモジュール６１６を使用して、以下で説明するように、そのような編集における遅延され、かつ制御されたマッピングを可能にする。
複数のタイプの制御動作を、トランザクション変換によって実行することができる。ユーザが、データクライアント６２２またはデータクライアント６２４内のデータをコミットすることを望むとき（例えば、データクライアントに関連付けられた「適用」ボタンがアクティブ化されるとき）に、制御モジュール６１８は、そのデータクライアントからコミット制御動作を受信し、図６を参照して以下で説明する２フェーズコンカレンシプロトコルを使用して、そのデータをコミットすることを試みる。一実施形態において、バッファリングモジュール６１６にバッファリングされたデータは、成功してコミットされると削除することができる。ユーザが、バッファ内のデータ（したがって、対応するデータクライアントに表示されるデータ）をリフレッシュすることを望むときに、制御モジュール６１８は、そのデータクライアントからリフレッシュ制御動作を受信し、バッファリングモジュール６１６内のデータをリフレッシュする。リフレッシュされたデータは、そのデータクライアントに伝送され、その結果、ユーザは、更新されたデータにアクセスできるようになる。分離されたデータをリフレッシュする機能は、以下で図６を参照して説明するように、従来の２フェーズコンカレンシモデルにおけるコミットの中止の代わりに使用することができる。
状況によっては、１人または複数人のユーザが１つまたは複数のデータクライアントを使用して行ったコミットされていない変更を無効にすることなく、バッファ内のデータを更新することが有効である。そのような場合に、同期化制御動作を、データクライアントによって発行することができる。制御モジュール６１８が、同期化制御動作をデータクライアントから受信するときに、バッファリングモジュール６１６内の分離されたデータは、（１つまたは複数の）データストア内の最新バージョンに基づいて更新され、分離されたデータに対するコミットされていない変更は、更新されたデータにマージされる。データに対する変更の複数セットの同期化プロセスは、当技術分野では十分に理解されており、同期化は、様々な状況で使用することができる。所与のコンテキストにおいて同期化をどのように実施できるかについての詳細は、そのコンテキストに非常に固有である。例えば、製品データベースのコンテキストでは、製品の一系列をデータベースにマージすることが許容できる可能性があるが、製品名に対する変更の２つのバージョンをマージすることは許容可能でない可能性がある。その他のコンテキストは、同期化に関するその他のルールを有する可能性があり、そのすべてを、本発明と共に使用することができる。競合の解決法も周知である。競合する場合にどの更新が基準にならなければならないかに関して、予め定められたルールを提供し、そのルールに従わせることができる。他の実施形態では、そのような競合を解決するために、ユーザ（ら）に警告することができる。
バッファリングモジュール６１６は、現在進行中の動作のタイプに基づいて変わり得るステータス情報を保持する。例えば、コミットが進行中である場合、ステータス情報には、コミットが保留中であるか、成功したか、または失敗したかのうちのどれであるかを含めることができる。また、リフレッシュが進行中である場合、ステータス情報には、リフレッシュが保留中であるか、または完了したかのどちらであるかを含めることができる。同期化動作が進行中である場合、ステータス情報には、同期化が保留中であるか、成功したか、または失敗したかのうちのどれであるかを含めることができる。特定の制御動作については、以下でより詳細に説明する。
データクライアントからアクセス可能な何らかのデータには、分離を必要としない場合がある。例えば、金融データベース（銀行口座の追跡に使用されるものなど）に対する変更は通常、即座にコミットされる。一実施形態では、所与のデータビューに、分離されたデータと分離されないデータとの両方を含めることができる。別の実施形態では、所与のデータクライアントに、そのデータクライアント内では編集できない読み取り専用データを含めることができる。
アプリケーション開発者からのアプリケーション仕様の受信に応答して、本発明の実施形態は、アプリケーションのどの部分が分離されたデータを必要とするかを識別し、必要に応じてトランザクション変換を実施する。図７に、トランザクション変換動作の動作フローを示す。受信動作７０２において、アプリケーション仕様を受信する。一実施形態において、アプリケーション仕様は、どのデータを分離しなければならないかを含めてＸＡＦアプリケーションを識別し、識別動作７０４において、そのアプリケーション内の、分離されるべき対応するデータエンティティを識別してマークする。
実施動作７０６において、分離されるべきデータエンティティとしてマークされた各データエンティティに対応する１つまたは複数のトランザクション変換を実施する。その後、トランザクション変換は、データ変換と実質的に同一の方法で接続され、アクティブ化される。
図８に、トランザクション変換動作に従って実行される制御動作を示す。受信動作８０２において、データクライアントから制御動作要求を受信する。一実施形態において、この要求は、データクライアントに関連付けられたＵＩコントロールをユーザがクリックすることによってトリガされる。判定動作８０４において、制御動作要求がコミット動作を要求しているかどうかを判定する。制御動作要求がコミット動作に関するものである場合、フローは、ＹＥＳから発行動作９０８（図９）に分岐する。制御動作要求がコミット動作に関するものではない場合、フローは、ＮＯから判定動作８０６に分岐する。
判定動作８０６において、制御動作要求が同期化動作を要求しているかどうかを判定する。制御動作要求が同期化動作に関するものである場合、フローは、ＹＥＳから保存動作８０８に分岐する。制御動作要求が同期化動作に関するものではない場合、フローは、ＮＯからリフレッシュ動作８１０に分岐する。
同期化動作が要求された場合、保存動作８０８において、すべてのコミットされていない変更を、バッファリングされたデータに保存する。コミットされていない変更は、コンピュータ読み取り可能な媒体上のファイル、揮発性メモリもしくは不揮発性メモリ、または他の形態のコンピュータ記憶デバイスに保存することができ、あるいは、外部データベースまたは類似するサービスにコミットすることができる。その後、フローは、リフレッシュ動作８１０に進む。
リフレッシュ動作８１０において、データストアに存在するバッファリングされたデータの最新のコピーを取り出し、そのコピーをトランザクション変換に関連付けられたバッファに配置する。リフレッシュ動作８１０では、どのデータストアがデータの最新のコピーを含むかを判定するために、複数のデータストアに照会する必要がある場合がある。別の実施形態では、リフレッシュ動作８１０において、その代わりに、またはそれに加えて、データコネクタがバッファリングされたデータのキャッシュされたコピーを含むかどうかを調べるために、各データストアに関連付けられたデータコネクタをチェックすることができる。
判定動作８１２において、制御動作要求が同期化動作を要求しているかどうかを判定する。一実施形態において、判定動作８１２では、単純に判定動作８０６の結果をチェックするだけである。制御動作要求が同期化動作に関するものである場合、フローは、ＹＥＳからマージ動作８１４に分岐する。制御動作要求が同期化動作に関するものではない場合、フローは、ＮＯからこの動作フローの終了に分岐する。
同期化動作が要求された場合、マージ動作８１４において、保存動作８０８において保存されたバッファリングされたデータに対する変更を、リフレッシュ動作８１０においてリフレッシュされたバッファリングされたデータとマージする。データ本体の２つのバージョンをマージするルールは、アプリケーションのコンテキストに基づいて変化する。いくつかの例示的なルールを、図６に提示した。一実施形態では、様々なデータクライアントからの複数の変更を一緒にマージして、各データクライアントにおける同期化を実現することができる。
図９に、本発明の一実施形態に従って、コミット要求がどのように処理されるかを示す。受信動作９０２において、データクライアントからデータを受信する。一実施形態において、データクライアントは、ダイアログボックスであり、アプリケーションユーザは、そのダイアログボックスを介してデータを入力する。データは、そのダイアログボックスに関連付けられたＵＩコントロールがアクティブ化されるときに送信される。次に、バッファリング動作９０４において、１つまたは複数のトランザクション変換内、あるいは１つまたは複数のトランザクション変換に関連付けられたメモリ内のデータをバッファリングする。
受信動作９０６において、コミット動作の要求を受信すると、変更された２フェーズコミットプロトコルが呼び出される。第１に、発行動作９０８において、データストアに関連付けられた複数のデータコネクタにコミット要求を発行する。一実施形態において、コミット要求は、コミットされるデータを含む。コミット要求は、データをキャッシュしている１つまたは複数のデータコネクタと、データを保持する１つまたは複数のデータストアとのうちの少なくとも一方によって受信され、データをアトミックにコミットできるという保証の要求として扱われる。受信動作９１０において、データを保持するデータコネクタおよび／またはデータストアから応答を受信する。すべての応答が受信されると、判定動作９１２において、コミット要求のすべての受信側がコミットに合意したかどうかを判定する。すべての受信側が合意した場合、フローは、ＹＥＳから送信動作９１４に分岐する。少なくとも１つの受信側が合意していない場合、フローは、ＮＯから送信動作９１６に分岐する。
すべての受信側がデータのコミットに合意した場合、送信動作９１４において、発行動作９０８において発行されたコミット要求のすべての受信側に、コミットコマンドを送信する。受信側は、データをコミットする（すなわち、受信側自体の変更されたデータを更新する）。
少なくとも１つの受信側が合意していない場合、送信動作９１６において、アボートコマンドを受信側に送信する。したがって、受信側は、指示されたコミットが行われないことと、そのコミットに関連するすべてのデータを破棄できることとを認識することになる。一実施形態では、送信動作９１６において、データのコミットに合意した受信側だけにアボートコマンドを送信し、データのコミットに合意しなかった受信側は、明示的に指示されずに自動的にデータを破棄する。次に、リフレッシュ動作９１８において、バッファリングされたデータをリフレッシュするために、リフレッシュ制御動作を実行する。一実施形態では、リフレッシュ動作９１８において、その代わりに、バッファリングされたデータを同期化するために、同期化制御動作を実行する。
本発明の他の実施形態も想定されている。一実施形態において、各トランザクション変換には、同期化ルールを実施するポリシモジュールを含めることができる。別の実施形態では、ポリシモジュールは、リフレッシュおよび同期化に関するコンカレンシポリシを設定する。例示的なコンカレンシポリシには、コンサバティブコンカレンシ（conservative concurrency）（すべてのバッファリングされたデータの完全なコピーが必ず作成される）と、オプティミスティックコンカレンシ（データは、必要に応じてバッファにコピーされるだけである）とが含まれる。ポリシモジュールは、本明細書では説明しないその他のタイプの制御動作を処理するための、モジュール式のポリシの追加を可能にすることもできる。
別の実施形態では、クエリ言語と共にトランザクション変換を使用して、データにアクセスし、そのデータを操作することができる。ＳＱＬが、広く使用されているそのようなクエリ言語の１つである。ＸＱｕｅｒｙが、別のそのようなクエリ言語である。本発明と共に他のクエリ言語を使用することも想定されている。
さらに別の実施形態では、データコネクタ６１０が、例えば図６のバッファおよびロジック６１６などのバッファに関連し、ある程度、そのバッファを管理することができる。そのような場合、コネクタは、データのリフレッシュコンポーネントおよび／または同期化コンポーネントを制御するために、バッファリングされたデータにアクセスし、かつ／または操作するロジックを有する。
（アプリケーションフレームワークフェーズ化モデル）
上記にて簡潔に説明したように、アプリケーションおよび／またはアプリケーションコンポーネントは、あるフェーズに制約することができる。一般に、フェーズ化は、ソフトウェアコンポーネントをマルチティア型フェーズ化モデルに従わせることによって、コンピュータシステム内のソフトウェアメソッドの実行を制約する。ソフトウェアコンポーネントは、クラス、オブジェクト、メソッド、またはコンピュータシステム内のその他のソフトウェアコード構造とすることができる。フェーズは、ソフトウェアコンポーネントのセットによって同時かつ集合的に共有される動作状態である。コンピュータシステムは、マスタフェーズ化モデルとも呼ばれるトップレベルフェーズ化モデルを実行し、１つまたは複数のサブフェーズが、マスタフェーズ化モデルの１つまたは複数のフェーズの間に発生する。コンピュータシステム内の動作は、フェーズのセットまたはサブフェーズのセットに制約される。
上記にて簡潔に説明したように、アプリケーションおよび／またはアプリケーションコンポーネントは、あるフェーズに制約することができる。一般に、フェーズ化は、ソフトウェアコンポーネントをマルチティア型フェーズ化モデルに従わせることによって、コンピュータシステム内のソフトウェアメソッドの実行を制約する。ソフトウェアコンポーネントは、クラス、オブジェクト、メソッド、またはコンピュータシステム内のその他のソフトウェアコード構造とすることができる。フェーズは、ソフトウェアコンポーネントのセットによって同時かつ集合的に共有される動作状態である。コンピュータシステムは、マスタフェーズ化モデルとも呼ばれるトップレベルフェーズ化モデルを実行し、１つまたは複数のサブフェーズが、マスタフェーズ化モデルの１つまたは複数のフェーズの間に発生する。コンピュータシステム内の動作は、フェーズのセットまたはサブフェーズのセットに制約される。
マルチティア型フェーズ化モデル１０００の例示的な実施形態を、図１０に示す。マルチティア型フェーズ化モデルは、３つのフェーズ１００２、１００４、および１００６を含む第１のフェーズモデルすなわちマスタフェーズモデルを有する。マスタフェーズは、矢印１０１６によって表される順序で発生する。２つのサブフェーズ、すなわち、サブフェーズ１ １００８およびサブフェーズ２ １０１０が、フェーズ１ １００２中に発生する。さらに、２つのさらなるサブフェーズ、すなわち、サブフェーズ２ａおよびサブフェーズ２ｂが、サブフェーズ２中に発生する。したがって、フェーズ化モデル１０００は、サブフェーズが他のフェーズまたはサブフェーズ中に発生する、マルチティア型のフェーズのセットを表す。以下では、フェーズのすべての説明を、サブフェーズにも適用することができる。
各ソフトウェアコンポーネントは、あるフェーズ内で動作するように制約される。制約は、ソフトウェアメソッドが制約されるフェーズ中にのみ実行されるか、または呼び出されるように、ソフトウェアメソッドのそれぞれに課される。競合または矛盾した結果をもたらし得るソフトウェアメソッドは、異なるフェーズに制約され、これらのソフトウェアメソッドは、現在のフェーズから正当に呼び出すことはできない。したがって、各ソフトウェアメソッドは、矛盾するタスクを達成するメソッド間で競合することなく、既知の形で実行される。すべてのメソッドは、ソフトウェアシステムが現在のフェーズ制約と互換状態になることがわかるように、特定のフェーズ制約の下で実行される。
再度図１０を参照すると、フェーズ１ １００２は、サブフェーズ１ １００８およびサブフェーズ２ １０１０に対する上位フェーズである。２つのさらなるサブフェーズ、すなわち、サブフェーズ２ａ １０１２およびサブフェーズ２ｂ １０１４は、サブフェーズ２ １０１０中に発生する。同様に、サブフェーズ２ １０１０は、サブフェーズ２ａ １０１２およびサブフェーズ２ｂ １０１４に対する上位フェーズである。どのフェーズまたはサブフェーズであっても、サブフェーズを有することができる。マルチティア型フェーズ化モデルにおけるサブフェーズのレベルの数には制限がない。さらに、任意のフェーズスペース内には、少なくとも２つのフェーズが存在しなければならないが、２つを超えるフェーズの数に対する制限はない。さらに、上位フェーズ内にサブフェーズが存在する場合には、少なくとも２つのサブフェーズが存在しなければならないが、上位フェーズ中に発生するサブフェーズについて、２つを超えるサブフェーズの数に対する制限はない。上位フェーズ中に、任意のサブフェーズのセットを１回または複数回サイクルすることができる。
フェーズ化モデル１０００は、フェーズスペースを示す。フェーズスペースは、有効なフェーズ（グラフの節点（graph node））および有効なフェーズ遷移（グラフの辺（graph edge））を決定する有限有向グラフである。したがって、フェーズスペースは、有効なフェーズのシーケンスを決定する。フェーズスペース１０００は、フェーズセット、すなわち、フェーズ１ １００２、フェーズ２ １００４、およびフェーズ３ １００６にわたって定義される。フェーズスペース１０００は、３つのフェーズ遷移１０１８ａ、１０１８ｂ、および１０１８ｃも有する。フェーズ遷移は、遷移前フェーズを共有するすべてのソフトウェアコンポーネントによるフェーズの同時変化が発生するときを表す。
ソフトウェアコンポーネントがフェーズスペースを共有するとき、このソフトウェアコンポーネントは、１つのフェーズドメインの一部である。フェーズドメインは、特定のフェーズスペースによって定義される共通のフェーズ化モデルに合意するソフトウェアコンポーネントのセットである。例えば、マスタフェーズ１００２、１００４、および１００６を有するマスタフェーズスペースによって制約されることに合意するすべてのソフトウェアコンポーネントは、このマスタフェーズドメインの一部である。したがって、このマスタフェーズドメイン内のソフトウェアコンポーネントに関連するすべてのソフトウェアコンポーネントは、マスタフェーズ１００２、１００４、および１００６のうちの少なくとも１つに関連するフェーズ制約を含む。
フェーズ制約は、あるプログラムコンテキストにおいて有効なフェーズを制限する静的な制約である。具体的に言うと、制約をプログラムセクションに適用して、そのプログラムセクションがその制約に従うフェーズ中にのみ実行されることを確実にすることができる。一実施形態において、フェーズ制約は、［Ｐｈａｓｅ １］など、大括弧内の属性として記述される。このデータ構造については、以下でより詳細に説明する。
１つまたは複数のフェーズドメインを占める１つまたは複数のコンポーネントを有するコンピュータ環境１１００を、図１１に示す。マスタディレクタ１１０２は、マスタフェーズスペースの遷移および確立を制御する。このコンピュータ環境内のすべてのコンポーネントが、マスタフェーズドメイン１１００の一部であるが、１つまたは複数のサブフェーズドメインを占めることもできる。フェーズドメイン１１００の作成を可能にするために、プログラム作成者は、フェーズスペースと、そのフェーズスペースにおけるフェーズ遷移を実行するポリシと、フェーズドメインの境界をまたぐメッセージを処理するポリシとを選択する必要がある。
フェーズドメイン１１００は、マルチティア型フェーズスペースによって特徴付けることができる。本発明の実施形態では、コンポーネント１ １１０４などの１つまたは複数のコンポーネントが、マスタディレクタ１１０２に登録される。コンポーネント１ １１０４は、ソフトウェアコンポーネントまたはメソッドを含む、任意のタイプのソフトウェアコンポーネントを表す。ソフトウェアコンポーネント１１０４は、マスタフェーズスペースにおけるフェーズのうちの１つのフェーズに制約される。
他の実施形態では、サブディレクタ１ １１０６およびサブディレクタ２ １１０８などの１つまたは複数のサブディレクタが、マスタディレクタ１１０２に登録される。サブディレクタは、１つまたは複数の様々なフェーズスペースを用いて１つまたは複数の他のフェーズドメインを制御する。したがって、フェーズドメイン１１００は、１つまたは複数のネストされたフェーズドメインを有する。サブディレクタ１ １１０６に登録されたコンポーネント２ １１１０などのすべてのコンポーネントは、サブフェーズスペース内で、マスタフェーズスペースにおける１つまたは複数のマスタフェーズ中の１つまたは複数のサブフェーズに制約される。一実施形態において、サブディレクタによって制御されるサブフェーズドメインは、単一のマスタフェーズ内で動作する。サブフェーズの動作は、単一のマスタフェーズ中に繰り返して発生し得る。
本発明の実施形態では、サブディレクタ２などのサブディレクタは、さらなるネストされたサブフェーズドメインを作成するために、サブディレクタ３などのその他のサブディレクタを登録する。いくつかの実施形態において、サブディレクタ２ １１０８は、コンポーネント３ １１１２およびサブディレクタ３ １１１４の動作を制御する。さらなる実施形態では、サブディレクタ３ １１１４などのディレクタが、コンポーネント４ １１１６およびコンポーネント５ １１１８などの複数のコンポーネントを制御する。各サブディレクタは、独自のフェーズを有するフェーズスペースを制御することができる。したがって、サブディレクタ１ １１０６は、第１のサブフェーズスペースを動作させ、サブディレクタ３ １１１４は、第２のサブフェーズスペースを動作させる。２つのフェーズスペースが相互作用しない場合、それらのフェーズスペースを直交スペースと呼ぶ。直交フェーズスペースの組合せは、デカルトフェーズスペースを形成することができ、このデカルトフェーズスペースは、単一の積（product）に関するフェーズドメインを形成するのに使用することができる。基礎になるフェーズセットは、直交フェーズセットのデカルト積であり、有効なフェーズ遷移も、直交フェーズセットの有効な遷移のデカルト積である。
本発明の実施形態では、ディレクタは、論理クロックである。ディレクタは、ハードウェアシステム内のクロックと同様に、フェーズを通ってサイクルする。各フェーズ遷移にて、ディレクタは、フェーズドメイン内のすべてのソフトウェアコンポーネントについて、フェーズを同時に変更する。一実施形態において、すべてのサブディレクタは、サブフェーズドメイン内のサブフェーズを同時に変更することができる。論理クロックは、フェーズに制約された動作、またはフェーズに制約されたサブフェーズ内で実行される動作に制約された動作の完了を待つ。
マスタフェーズドメインに使用することができるフェーズスペース１２００の例示的な実施形態を、図１２に示す。フェーズスペース１２００は、３つのフェーズを有する。読み取り要求フェーズ１２０２中には、データを読み書きする要求、またはソフトウェアシステム内のその他のソフトウェアコマンドもしくは要求が、次のフェーズに入るまでキューされる。一実施形態では、要求された競合しないメソッドだけが、次のフェーズにおいて実行され、他のメソッドは、別のフェーズ、またはそのフェーズの次のサイクルまで待つ。
更新フェーズ１２０４は、コマンドおよび要求を適切なソフトウェアコンポーネントに向ける。本発明の実施形態では、更新フェーズ１２０４中に、ソフトウェアコンポーネントが、コマンドまたは要求を満たす。一実施形態において、更新フェーズ１２０４は、更新フェーズ１２０４中に発生するサブフェーズスペース５００を有する。例示的なサブフェーズスペース５００は図５に示されており、サブフェーズスペース５００については、以下で説明する。一実施形態において、更新フェーズ１２０４は、データレイヤのサブフェーズをトリガする。すなわち、データに書き込むすべての要求は、更新フェーズ１２０４のサブフェーズにおいて達成される。
第３のフェーズすなわち再検証フェーズ１２０６は、更新フェーズ１２０４中に処理されなかった他のメソッドを指揮し、実行する。一実施形態では、データを取り出すすべての要求が、再検証フェーズ１２０６中に完了する。例えば、データが更新フェーズ１２０４において更新された後に、すべてのソフトウェアコンポーネントに、データ変更が発生したことが通知され、通知されたソフトウェアコンポーネントは、更新されたデータを取り出す。一実施形態において、再検証フェーズ１２０６は、サブフェーズスペース６００を動作させる。サブフェーズスペース１３００の例示的な実施形態を、図１３に示し、以下で説明する。
フェーズを変更するために、フェーズスペース１２００は、フェーズ遷移を介して進行する。例示的な実施形態では、３つのフェーズ１２０２、１２０４、および１２０６の間の遷移を表す３つのフェーズ遷移１２０８ａ、１２０８ｂ、および１２０８ｃが存在する。上述したように、フェーズ遷移は、ディレクタ１１０２などのディレクタが、フェーズクロックを変更する時点であり、フェーズドメイン内のすべてのソフトウェアコンポーネントのフェーズは、同時に変化する。
現在のフェーズについて、または新しいフェーズへの遷移について警告するか通知するフェーズドメイン内のソフトウェアコンポーネントが、発生し得る。一実施形態では、ディレクタが、フェーズについてすべてのソフトウェアコンポーネントに通知する。他の実施形態では、要求するメソッドが、フェーズについてディレクタに要求する。本発明の実施形態では、遷移通知は、フェーズドメイン内の１つまたは複数のソフトウェアコンポーネントに送信される。一実施形態において、遷移通知は、現在のフェーズ中か、または次のフェーズの開始時のいずれかに発生する。他の実施形態では、別々のフェーズが、通知プロセス用に使用される。例えば、フェーズスペース１２００は、フェーズドメイン内のソフトウェアコンポーネントに通知するための、遷移１２０８ａ、１２０８ｂ、および１２０８ｃに位置付けられた３つの通知フェーズを有する。
更新フェーズ１２０４の例示的なサブフェーズスペース１３００を、図１３に示す。サブフェーズ１３００は、いくつかの実施形態において、データレイヤに対して使用される。すなわち、共有データ構造体にデータを書き込むメソッドは、データサブフェーズスペース１３００のサブフェーズの１つに制約される。一実施形態において、データを共有するすべてのソフトウェアコンポーネントは、合意フェーズ１３０２で、データをコミットするか、あるいは変更をアボートするかのいずれかに合意する。変更は、コミットまたはアボートフェーズ１３０４で、コミットされるか、あるいはアボートされるかのいずれかになる。
別の実施形態では、合意フェーズと、コミットまたはアボートフェーズとの両方が、「コミットまたはアボート」サブフェーズ１３０４のサブフェーズであり、サブフェーズスペース１３００は、合意フェーズ１３０２の代わりにマークフェーズ１３０２を有する。この場合、データ変更は、コミットまたはアボートフェーズ１３０４で行われ、そのデータを使用するすべてのソフトウェアコンポーネントは、マークフェーズ１３０２で更新に対してマークされる。ソフトウェアコンポーネントをマークすることは、適切な後のフェーズで更新されたデータを取り出すようソフトウェアコンポーネントにシグナリングする、ソフトウェアコンポーネント内のフラグを設定することである。一実施形態において、マークされたソフトウェアコンポーネントは、再検証フェーズ１２０６でデータを取り出す。別の実施形態では、マークフェーズ１３０２は、２つのサブフェーズ、すなわち、マークサブフェーズおよび最終マークサブフェーズを有する。この場合、データを使用するソフトウェアコンポーネントは、マークサブフェーズでマークされ、最終マークサブフェーズでデータを取り出す。
再検証フェーズ１２０６中に発生する別の例示的なサブフェーズスペース１４００を、図１４Ａに示す。サブフェーズスペース１４００に制約されるソフトウェア構造内の例示的な変化を、図１４Ｂに示す。サブフェーズスペース１４００は、プラグアンドプレイ動作のためにサブフェーズを提供する。プラグアンドプレイサブフェーズスペース１４００は、２つのフェーズ、すなわち、プレイサブフェーズ１４０４およびプラグサブフェーズ１４０２を有する。一般に、プラグサブフェーズ１４０２では、ソフトウェアコンポーネントのコンポジション（composition）および構成が、確立されるか、変更されるか、または削除されるが、プレイ時機能（playtime functionality）は実行されない。同様に、プレイサブフェーズ１４０４では、ソフトウェアコンポーネントの確立されたコンポジションまたは構成が、通常の機能のために使用されるが、コンポジションまたは構成の諸態様は、確立されず、変更されず、削除されない。
モジュール再構成の例示的な実施形態を、図１４Ｂに示す。この実施形態では、ソフトウェアモジュールが、第１の構成１４０６を有する。ユーザ入力要求などの、何らかのアクションの際に、ソフトウェアモジュールは、第２の構成１４０８に変化する。当業者であれば、ソフトウェアモジュールは、第２の構成１４０８と比較して、第１の構成１４０６では異なって動作することが理解されよう。したがって、再構成は、ソフトウェアモジュールと相互作用するプレイフェーズ中にメソッドが実行されることなく、行われる必要がある。本発明の実施形態では、プラグサブフェーズ１４０２中に、ソフトウェアインスタンスが、初期化され、接続または切断され、プロパティが設定される。いくつかの実施形態では、さらなるサブフェーズが、プラグサブフェーズ１４０２中に実行される動作を順序付けることを助ける。
一実施形態において、プラグサブフェーズ１４０２は、さらなるサブフェーズを有する。構築サブフェーズ１４１０は、既知のクラスをインスタンス化することによって、ソフトウェアコンポーネントを呼び出すことによって、またはクローンもしくは特殊化された導出されたインスタンスを取得するために既存のインスタンスにおけるインターフェースを使用することによって、新しいソフトウェアインスタンスを作成する。構成サブフェーズ１４１２は、インスタンス間の接続を追加するか、または除去する。最後に、初期化サブフェーズ１４１４は、プロパティを設定し、正しく接続されたインスタンス間のネゴシエーションを要求する。プラグサブフェーズ１４０２内のサブフェーズは、本明細書で提示されるサブフェーズから派生され得る。さらに、プレイサブフェーズ１４０４にも、サブフェーズを含めることができる。
他のフェーズ化スペースも企図されている。例えば、ユーザインターフェース変更用のサブフェーズスペースが企図されている。ユーザインターフェースサブフェーズスペースでは、無効化サブフェーズ（invalidate sub-phase）が、構造体をビルドするメソッドの実行を可能にすることができる。次に、描画サブフェーズ（draw sub-phase）が、ビルドされた構造体を描画する。当業者であれば、他のフェーズスペースを、他のタイプの動作用に使用することができることが認識されよう。さらに、当業者であれば、上記にて提示した例示的なフェーズスペースは、フェーズまたはサブフェーズの数に関して、ティアまたはレイヤの数に関して、およびフェーズまたはサブフェーズのタイプに関して、変更できることが認識されよう。したがって、本発明は拡張可能である。一実施形態では、新しい上位フェーズが、既存のフェーズスペースにオーバーレイされる。別の実施形態では、新しいフェーズが、既存のフェーズスペースに追加される。さらに別の実施形態では、より多くのサブフェーズ、またはサブフェーズスペースの新しいティアが、既存のフェーズスペースに追加される。
コードの項目の実行を制約するフェーズ制約を有するデータ構造体１５００の例示的な実施形態を、図１５に示す。データ構造体１５００はコード要素である。任意のタイプのコードが、フェーズ制約を有することができる。フェーズ制約１５０２が、メソッド１５０４の上に示されている。フェーズ制約１５０２は、メソッド１５０４の動作を、フェーズ制約において指定されたフェーズ、この実施形態ではフェーズ「Ｐｅｒｆｏｒｍ」に制約する。したがって、メソッド１５０４は、「Ｐｅｒｆｏｒｍ」フェーズまたは「Ｐｅｒｆｏｒｍ」サブフェーズ中にのみ実行される。
本発明の実施形態では、データ構造体は、ソフトウェアコンポーネントと、実行される動作のタイプとに依存する、ある形の制約を含む。一実施形態において、制約は呼び出し制約である。呼び出し制約は、メソッドの呼び出しを、指定されたフェーズに制約する。したがって、他のソフトウェアコンポーネントまたは同一のソフトウェアコンポーネント内のメソッドの実行は、このメソッドの開始を指定されたフェーズ中だけに制限することによって制約される。別の実施形態では、制約はコンストラクタ制約である。コンストラクタは、ソフトウェアコンポーネントをインスタンス化する、特殊な形のメソッドである。したがって、ソフトウェアコンポーネントのインスタンス化は、図１４Ａの構築サブフェーズ１４１０を用いて説明したフェーズなどの、指定されたフェーズに制約される。さらに別の実施形態では、制約は参照制約である。参照制約は、ソフトウェアコンポーネントの１つのクラス全体と、そのクラスのすべてのプリミティブ動作とを制約する。例えば、インターフェースに対して設けられた参照制約は、図１４Ａの接続サブフェーズ１４１２を用いて説明したものなど、ソフトウェアモジュール間の接続を制限する。
制約は、任意のターゲットソフトウェアコンポーネントに割り当てることができる、ソフトウェアコード内のフェーズ制約属性によって表される。本発明の実施形態では、フェーズ制約属性は、クラス全体に割り当てられ、継承可能である。したがって、子コンポーネントは、その親コンポーネントから制約を継承する。いくつかの実施形態において、フェーズ化方式は、同一のターゲットに複数のフェーズ制約属性を設ける。したがって、ソフトウェアターゲットは、複数のフェーズ制約の結合によって制約される。
各制約は、指定されたフェーズのレベルに関連付けられた「タイプ」に対する制約である。したがって、上位フェーズを指定する制約は、「上位フェーズ」に対する制約である。サブフェーズを指定する制約は、「サブフェーズ」に対する制約である。サブフェーズであるタイプに対する制約は、「上位タイプ」に対するすべての制約の結合に対する制約である。タイプに対する制約間の関係は、様々なソフトウェアコンポーネント間の制約関係の妥当性をチェックするために、コンパイラによって使用されるか、あるいは、ランタイムに使用される。
制約の実施は、ランタイムに、またはコンパイル時に行うことができる。コンパイル時には、タイプに対する制約をチェックすることができる。コンパイラは、サブタイプに対する制約を有するメソッドを呼び出すタイプに対する制約を有するメソッドの正常性ルール（soundness rules）のセットに対して、タイプに対する制約およびサブタイプに対する制約をチェックすることができる。制約方式は、サブタイプに対する制約がタイプに対する制約と同一か、またはタイプに対する制約より弱い場合に、例えば、タイプに対する制約がプラグフェーズ１４０２を指定し、サブタイプに対する制約が初期化サブフェーズ１４１４を指定する場合に、有効である。この実施形態では、初期化サブフェーズ制約１４１４は、プラグサブフェーズ１４０２内で実行され、したがって、より弱い制約である。制約方式は、サブタイプに対する制約が、タイプに対する制約と相互に素である場合に、例えば、タイプに対する制約がプレイサブフェーズ１４０４を指定し、サブタイプに対する制約が反対のプラグサブフェーズ１４０２を指定する場合に、無効である。制約方式は、サブタイプに対する制約がタイプに対する制約より強いか、またはタイプに対する制約とオーバーラップしている場合に、例えば、タイプに対する制約がプラグサブフェーズ１４０２を指定し、サブタイプに対する制約が初期化サブフェーズ１４１４を指定する場合に、有効であるが、ある動的チェックを受けなければならない。この実施形態では、フェーズドメインが、現在、プラグサブフェーズ１４０２と初期化サブフェーズ１４１４との両方で動作する場合に、呼び出し方式が有効である。しかし、ドメインが、この２つのフェーズの一方に含まれない場合、その方式は無効である。他の正常性ルールも企図されており、本発明に組み込まれている。
マルチティア型フェーズ化ドメイン内でコンピュータ環境を動作させる方法１６００の例示的な実施形態を、図１６Ａおよび図１６Ｂに示す。起動後に、遷移動作１６０２において、要求フェーズ１２０２などの第１のフェーズに遷移する。一実施形態では、マスタディレクタ１１０２などのマスタディレクタが開始される。一実施形態では、マスタフェーズのうちの１つに制約された、コンポーネント１１０４などのコンポーネントが、マスタディレクタに登録される。マスタディレクタは、フェーズクロックを開始して、フェーズスペース１２００などのフェーズスペース内のフェーズを通って論理時間をサイクルする。
判定動作１６０４において、コンポーネント１１０４などのいずれかのソフトウェアコンポーネントが、マスタフェーズの第１のフェーズに制約されるかどうかを判定する。ソフトウェアコンポーネントが第１のフェーズに制約されている場合、実行動作１６０６において、第１のフェーズ中に、そのソフトウェアコンポーネントを実行する。実行すべきソフトウェアコンポーネントがない場合、またはソフトウェアコンポーネントの実行中に、判定動作１６０８において、第１のフェーズ中に発生する、サブフェーズスペース１３００などのサブフェーズスペースがあるかどうかを判定する。第１のフェーズ中に発生するサブフェーズスペースがない場合、このプロセスは、接続子１から、図１６Ｂに示された遷移動作１６２２に進む。
第１のフェーズ中に発生するサブフェーズスペースがある場合、識別動作１６１０において、そのサブフェーズスペースおよび適用可能なサブフェーズを識別する。一実施形態では、サブディレクタ１１０６などのサブディレクタが、開始され、マスタフェーズスペースを制御するマスタディレクタに登録される。サブディレクタは、サブフェーズ論理クロックを開始して、サブフェーズスペース内のサブフェーズを通ってサイクルする。判定動作１６１２において、現在のサブフェーズに制約された、コンポーネント１１１２などのソフトウェアコンポーネントがあるかどうかを判定する。一実施形態において、サブフェーズスペースに制約されたソフトウェアコンポーネントは、サブディレクタに登録される。したがって、ネストされたサブフェーズドメインが、マスタフェーズドメインの下で作成される。現在のサブフェーズに制約されたサブフェーズドメイン内のソフトウェアコンポーネントがある場合、実行動作１６１４において、現在のサブフェーズ中に、それらのソフトウェアコンポーネントを実行する。判定動作１６１６において、現在のサブフェーズ内に発生する、サブフェーズ１４１０、１４１２、および１４１４などのさらなるサブフェーズスペースがあるかどうかを判定する。さらなるサブフェーズがある場合、このプロセスは、識別動作１６１０に戻って、さらなるサブフェーズを識別する。
識別すべきさらなるサブフェーズスペースがない場合、判定動作１６１８において、現在のサブフェーズスペース内で発生する他のサブフェーズが残っているかどうかを判定する。現在のサブフェーズスペース内で発生する別のサブフェーズがある場合、遷移動作１６２０において、サブフェーズスペース内の次のサブフェーズに遷移する。一実施形態において、サブディレクタは、現在のサブフェーズ内のすべてのスレッドが実行されるまで待ち、その後、次のサブフェーズに遷移する。次に、このプロセスは、もう一度判定動作１６１２に進む。現在のサブフェーズスペース内にサブフェーズが残っていない場合、判定動作１６１８において、いずれかの上位フェーズスペースに、遷移すべき別の上位フェーズがあるかどうかを判定する。別の上位フェーズがある場合、遷移動作１６２０において、次の上位フェーズに遷移する。このプロセス（上位フェーズ内のサブフェーズの判定、サブフェーズ内のソフトウェアコンポーネントの実行、すべてのサブフェーズが完了するまでの次のサブフェーズへの遷移、および次の上位フェーズへの遷移）は、すべてのサブフェーズスペースを通ってサイクルし、次のマスタフェーズへの遷移が必要になるまで、繰り返される。サブフェーズループが、第１のマスタフェーズについて終了すると、このプロセスは、接続子１から、図１６Ｂに示された遷移動作１６２２に進む。
遷移動作１６２２において、更新フェーズ１２０４などの次のマスタフェーズに遷移する。一実施形態において、マスタディレクタは、第１のフェーズ内で実行されるすべてのスレッドが終了するのを待つ。その後、マスタディレクタは、論理フェーズクロックを次のフェーズに変更する。いくつかの実施形態において、マスタディレクタは、図１１を参照して上記にて概要を示した遷移ルールに従う。その後、このプロセスは、サブフェーズ識別について第１のフェーズが発生するのに類似した動作に従う。したがって、サブフェーズプロセスに関する一部の詳細について、繰り返し説明はしないが、当業者であれば、第１のフェーズに関して説明した詳細を、次のフェーズに制約された任意の後続するプロセスにどのように実施すべきかが理解されよう。
判定動作１６２４において、いずれかのソフトウェアコンポーネントが現在のマスタフェーズに制約されるかどうかを判定する。次のマスタフェーズに制約されたソフトウェアコンポーネントがある場合、実行動作１６２６において、そのソフトウェアコンポーネントを実行する。実施形態において、ソフトウェアコンポーネントは、既にマスタディレクタに登録されている。ソフトウェアコンポーネントは、現在のフェーズについて、マスタディレクタに関してチェックをし続ける。フェーズが遷移し、マスタディレクタが、ドメインが今や次のマスタフェーズにあることをレポートするときに、次のマスタフェーズに制約されたソフトウェアコンポーネントが、実行を開始する。
次のマスタフェーズに制約されたソフトウェアコンポーネントがない場合、または制約されたソフトウェアコンポーネントの実行中に、判定動作１６２８において、現在のマスタフェーズ内にサブフェーズスペースがあるかどうかを判定する。サブフェーズスペースがある場合、識別動作１６３０において、サブフェーズスペースを識別し、第１のサブフェーズに遷移する。判定動作１６３２では、いずれかのソフトウェアコンポーネントが現在のサブフェーズに制約されるかどうかを判定する。現在のサブフェーズに制約されたソフトウェアコンポーネントがある場合、実行動作１６３４において、そのソフトウェアコンポーネントを実行する。
現在のサブフェーズに制約されたソフトウェアコンポーネントがない場合、またはこれらのソフトウェアコンポーネントの実行中に、判定動作１６３６において、現在のサブフェーズ内にさらなるサブフェーズスペースがあるかどうかを判定する。さらなるサブフェーズスペースがある場合、このプロセスは、識別動作１６３０に戻る。さらなるサブフェーズスペースが現在のサブフェーズ内にない場合、判定動作１６３８において、現在のサブフェーズスペース内の次のサブフェーズまたは上位フェーズスペース内の次の上位フェーズがあるかどうかを判定する。次のサブフェーズまたは上位フェーズがある場合、遷移動作１６４０において、次のサブフェーズまたは上位フェーズに遷移する。現在のマスタフェーズの下に次のサブフェーズまたは上位フェーズがない場合、判定動作１６４２において、再検証フェーズ１２０６などの次のマスタフェーズがあるかどうかを判定する。次のマスタフェーズがある場合、このプロセスは、遷移動作１６２２に戻る。マスタフェーズスペース内に別のマスタフェーズがない場合、このプロセスは、接続子２から、遷移動作１６０２に戻り、第１のフェーズへの遷移によって、フェーズサイクルを最初からやり直す。
本発明をさらに説明するために、マルチティア型フェーズ化ドメイン内で動作する例示的なコンピュータシステムを、図１７を参照して以下で説明する。この例示的なコンピュータシステムは、Ｍｉｃｒｏｓｏｆｔ（登録商標） Ｏｕｔｌｏｏｋ（登録商標）メッセージングおよびコラボレーションクライアントプログラムなどの個人用連絡帳アプリケーション（personal contacts application）を動作させる。ここで、ユーザインターフェースは、アドレス帳に含まれる１つまたは複数の連絡先を表示する。このユーザインターフェースは、マスタビューウィンドウ１７０２を有する。マスタビュー１７０２は、すべての連絡先を表示し、ユーザが連絡先に関するより詳細な情報を見るために、連絡先を選択することを可能にする。
コンピュータ環境１７００は、フェーズスペースの下で動作する。限定する目的ではなく説明のために、システム１７００全体が、図１２に示されたフェーズスペース１２００の下で動作するものとする。さらに、説明のために、コンピュータシステム１７００は、現在、要求フェーズ１２０２にあるものとする。したがって、コンピュータシステム１７００は、要求またはコマンドが受信されるすべての動作を可能にする。したがって、連絡先の詳細ビュー１７０４を見るためのユーザコマンド１７１６が、受信され、キュー内に配置される。さらに、コマンド１７１８が、要求された詳細情報を取り出すために、アドレス帳モジュール１７０８に送信される。データ要求１７１８もキューされる。
マスタディレクタ１１０２は、コンピュータシステムドメイン１７００内のフェーズを更新フェーズ１２０４に変更する。ここで、コマンド１７１６および１７１８がそれぞれ、選択状態モジュール１７０６およびアドレス帳モジュール１７０８に送信される。図１４を参照して上述したユーザインターフェースに対する変更に関するユーザインターフェースサブフェーズスペースは、更新フェーズ１２０４中へ遷移される。無効化サブフェーズが開始する。詳細ビュー１７０４に関するコマンド１７１６が、処理を開始する。マスタビュー１７０２内のビューが、無効化される。例えば、詳細ビュー１７０４の選択が、非アクティブに設定される。さらに、マスタビュー１７０２は、非アクティブウィンドウに設定される。詳細ビュー１７０４が、適切なフィールドおよびユーザインターフェース項目を用いて作成される。次に、ユーザインターフェースサブディレクタが、描画サブフェーズに遷移する。連絡先に関するマスタビュー１７０２内の選択が、非アクティブに見えるように描画され、例えば、強調表示された選択が、色を変更する。マスタビュー１７０２が、非アクティブとして描画される。例えば、マスタビュー１７０２のウィンドウペインは、そのウィンドウペインが非アクティブであることを示すために、色を変更する。詳細ビュー１７０４が、ユーザインターフェース要素と共に描画される。フィールドは、アドレス帳モジュール１７０８からデータを受信するために、開かれたままにされる。
マスタディレクタ１１０２は、すべての無効化および描画の制約された動作がユーザインターフェースサブフェーズスペースで完了した後に、再検証フェーズ１２０６に遷移する。データ取り出し動作が、再検証フェーズ１２０６中に実行される。データ取り出し動作は、一実施形態では、データ取り出しサブフェーズスペースに制約される。データ取り出しサブフェーズスペースは、図１３を参照して説明したように、２つのサブフェーズ、すなわち、マークサブフェーズおよび最終マークサブフェーズを有する。マークサブフェーズが開始される。アドレス帳が、データの更新を必要とするソフトウェアモジュールを検索する。詳細ビュー１７０４がマークされる。データ取り出しサブフェーズスペースのサブディレクタが、最終マークサブフェーズに遷移する。最終マークサブフェーズでは、アドレス帳１７０８が、３つのデータストア、すなわち、エクスチェンジサーバアドレス帳１７１０、クライアントアドレス帳１７１２、およびＭＳＮアドレス帳のうちの１つから、要求された連絡先情報を取り出す。連絡先情報を取り出すと、アドレス帳１７０８は、その連絡先情報を詳細ビュー１７０４に書き込む。
再検証フェーズ１２０６に制約されたすべての動作を完了すると、マスタディレクタ１１０２は、要求フェーズ１２０２に戻って遷移する。ここで、ユーザインターフェースは、再度ユーザ入力デバイスからコマンドおよび要求を受け入れる。ユーザが、詳細ビュー１７０４内の連絡先情報に対する変更を入力する。例えば、ユーザは、連絡先の住所を変更する。データを変更するため、コマンド１７２０が、詳細ビュー１７０４からアドレス帳１７０４に送信される。さらに、マスタビュー１７０２およびアドレス帳１７０４のビューを更新するために、コマンド１７２２が、選択状態１７０６に送信される。この実施形態では、コマンドがキューされ、マスタディレクタ１１０２が更新フェーズ１２０４に遷移する。更新フェーズ１２０４は、サブフェーズスペース１３００などのデータ書き込みサブフェーズスペースを開始する。
合意サブフェーズ１３０２において、アドレス帳が、データ変更要求を複数のデータストア１７１０、１７１２、および１７１４に送信する。データストアのうちの１つまたは複数には、詳細ビュー１７０４で変更されたデータのコピーが含まれる場合がある。したがって、そのデータを有する各データストアは、データを変更することに合意しなければならない。したがって、合意サブフェーズ１３０２中に、投票プロシージャ（voting procedure）が発生する。すべてのデータストアが、変更をコミットすることに合意する場合に、その合意が、アドレス帳１７０８に返送される。サブディレクタは、コミットまたはアボートフェーズ１３０４に、フェーズを変更する。ここで、データ変更が、データストアに送信され、データを更新するために使用される。
その一方で、更新フェーズ１２０４中に、ユーザインターフェースサブフェーズスペースが発生する。選択状態１７０６は、無効化サブフェーズ中に、マスタビュー１７０２および詳細ビュー１７０４における、古いデータを含むセクションを無効化する。描画サブフェーズでは、マスタビュー１７０２および詳細ビュー１７０４が、変更されたデータのスペースを保持しながら、再描画される。すべてのサブフェーズが更新フェーズ１２０４で完了すると、フェーズドメイン１７００は、再検証フェーズ１２０６に遷移する。
再検証フェーズ１２０６では、さらなるサブフェーズスペースが、マークサブフェーズおよび最終マークサブフェーズを含む。マークフェーズに遷移して、アドレス帳１７０８は、変更されたデータを必要とするものとして、マスタビュー１７０２および詳細ビュー１７０４をマークする。最終マークサブフェーズでは、変更されたデータが、マスタビュー１７０２および詳細ビュー１７０４に書き込まれる。これらの変更は、非常に短い時間で、微細な粒度で発生し得る。例えば、フェーズは、ユーザによって入力されるすべての文字の後、１秒も要さないほどのわずかな時間のうちにサイクルされる。したがって、変更は、瞬間的に発生するように見える。
この例は、マルチティア型フェーズ化が、システム内のメソッドの実行に対してどのように制約するかを示すものである。コマンドおよび変更がフェーズ化なしで発生する場合には、マスタビュー１７０２および詳細ビュー１７０４は、すべてのデータストアがデータを変更する前に、更新される可能性がある。したがって、データの変更を試みるメソッドおよびユーザインターフェースビューの更新を試みるメソッドの順序に応じて、ユーザは、詳細ビュー１７０４またはマスタビュー１７０２内で混合された結果を見る可能性がある。
（コンカレンシドメインを伴うマルチスレッディング）
上記にて簡潔に説明したように、アプリケーションおよび／またはアプリケーションコンポーネントは、あるフェーズまたはあるフェーズドメインに制約することができる。本発明の実施形態によれば、コンポーネントのパーティション内の同期化およびスレッド分離を提供し、かつコンポーネントのパーティション間の改善された並行動作を提供するために、ソフトウェアアプリケーションのコンポーネントを別々のドメインに区分することができる。図１８に、本発明の一実施形態による、複数のオブジェクトを同時に実行するように構成された例示的なシステムを示す。例示的なシステム１８００は、コンカレンシドメイン１８０１を含み、このコンカレンシドメイン１８０１は、すべてのシングルスレッドオブジェクト１８０３が単一のスレッド１８０２で実行される１つまたは複数の当該シングルスレッドオブジェクト１８０３の集合（またはパーティション）であり、外部オブジェクト１８１０と直接的に（例えば、または同期式に）は通信しない。内部スレッド１８０２は、コンカレンシドメイン１８０１によって課せられるロジックに従ってオブジェクト１８０３を実行する。内部スレッド１８０２は、コンカレンシドメイン１８０１内でシングルスレッドオブジェクト１８０３だけを実行する。内部スレッド１８０２は、外部オブジェクト１８１０をまったく実行しない。
上記にて簡潔に説明したように、アプリケーションおよび／またはアプリケーションコンポーネントは、あるフェーズまたはあるフェーズドメインに制約することができる。本発明の実施形態によれば、コンポーネントのパーティション内の同期化およびスレッド分離を提供し、かつコンポーネントのパーティション間の改善された並行動作を提供するために、ソフトウェアアプリケーションのコンポーネントを別々のドメインに区分することができる。図１８に、本発明の一実施形態による、複数のオブジェクトを同時に実行するように構成された例示的なシステムを示す。例示的なシステム１８００は、コンカレンシドメイン１８０１を含み、このコンカレンシドメイン１８０１は、すべてのシングルスレッドオブジェクト１８０３が単一のスレッド１８０２で実行される１つまたは複数の当該シングルスレッドオブジェクト１８０３の集合（またはパーティション）であり、外部オブジェクト１８１０と直接的に（例えば、または同期式に）は通信しない。内部スレッド１８０２は、コンカレンシドメイン１８０１によって課せられるロジックに従ってオブジェクト１８０３を実行する。内部スレッド１８０２は、コンカレンシドメイン１８０１内でシングルスレッドオブジェクト１８０３だけを実行する。内部スレッド１８０２は、外部オブジェクト１８１０をまったく実行しない。
一実施形態によれば、コンカレンシドメイン１８０１の寿命全体を通じて内部スレッド１８０２として、同一のスレッドを使用する必要はない。そうではなく、内部スレッド１８０２でオブジェクトを実行する必要がないときには、内部スレッド１８０２として動作するスレッドを、スレッドプール（図示せず）に返すことができる。スレッドがもう一度必要になったときには、新しいスレッドをスレッドプールからプルして、内部スレッド１８０２として動作させることができる。別の実施形態によれば、シングルスレッドオブジェクト１８０３のうちの１つが、スレッドアフィニティを有し、これは、シングルスレッドオブジェクト１８０３が同一のスレッドで実行されることを必要とすることを意味する。この実施形態では、同一のスレッドが、コンカレンシドメイン１８０１の寿命全体を通じて内部スレッド１８０２として動作する。一実施形態によれば、本明細書でより詳細に説明する、セカンダリスレッド１８０４も、スレッドプールから割り当てられる。
図１８をさらに参照すると、システム１８００は、少なくとも１つのセカンダリスレッド１８０４および少なくとも１つの外部オブジェクト１８１０をさらに含む。外部オブジェクト１８１０の実施形態には、１つまたは複数のセカンダリスレッド１８０４で実行される任意のオブジェクトが含まれる。セカンダリスレッド１８０４には、関連するアプリケーション内で実行される、内部スレッド１８０２以外の任意のスレッドが含まれる。上述したように、図１８に示された例示的なコンカレンシドメイン１８０１は、内部スレッド１８０２および複数のシングルスレッドオブジェクト１８０３を含む。これらのシングルスレッドオブジェクト１８０３は、内部スレッド１８０２だけを使用して実行される。
コンカレンシドメイン１８０１内のオブジェクト１８０３は、プログラム内で、残りのセカンダリスレッド１８０４および外部オブジェクト１８１０から分離される。セカンダリスレッド１８０４は、コンカレンシドメイン１８０１内に含まれるシングルスレッドオブジェクト１８０３をまったく実行しない。各外部オブジェクト１８１０は、セカンダリスレッド１８０４のうちの１つまたは複数で実行されるように構成される。外部オブジェクト１８１０は、コンカレンシドメイン１８０１内のシングルスレッドオブジェクト１８０３と非同期に通信する。通信には、オブジェクト間でデータを渡すこと、またはあるオブジェクトによって別のオブジェクトのメソッド（例えば、またはタスク）を呼び出すことが含まれる。
コンカレンシドメイン１８０１の境界にまたがる非同期通信は、バウンダリオブジェクト１８０７の使用により実現される。各コンカレンシドメイン１８０１は、１つまたは複数のバウンダリオブジェクト１８０７に関連付けられる。これらのバウンダリオブジェクト１８０７は、コンカレンシドメイン１８０１を囲む膜または門壁とみなすことができる。バウンダリオブジェクト１８０７の例には、コンカレンシドメイン１８０１間、またはコンカレンシドメイン１８０１と外部オブジェクト１８１０との間でカスタムプロトコルを実装するデータコネクタおよびオブジェクトが含まれる。
コンカレンシドメイン１８０１内のシングルスレッドオブジェクト１８０３は、１つまたは複数のバウンダリオブジェクト１８０７を使用して、外部オブジェクト１８１０と非同期に通信する。シングルスレッドオブジェクト１８０３は、内部スレッド１８０２を使用して、バウンダリオブジェクト１８０７と通信する。次に、バウンダリオブジェクト１８０７は、１つまたは複数のセカンダリスレッド１８０４を使用して、外部オブジェクト１８１０と通信する。これによって、バウンダリオブジェクト１８０７は、コンカレンシドメイン１８０１の境界にまたがって情報および呼び出しを渡す。別の実施形態によれば、あるバウンダリオブジェクト１８０７は、外部オブジェクト１８１０に情報を渡す前に、セカンダリスレッド１８０４を使用して、別のバウンダリオブジェクト１８０７と通信する。
バウンダリオブジェクト１８０７は、コンカレンシドメイン１８０１の内部スレッド１８０２と、セカンダリスレッド１８０４の各々との間のインターフェースとして動作する。一実施形態によれば、バウンダリオブジェクト１８０７は、セカンダリスレッド１８０４を使用して、外部オブジェクト１８１０からインバウンド通信を受信し、この通信を適切な内部オブジェクト１８０３にフィルタリングする。このフィルタリング方法については、本明細書でより詳細に説明する。別の実施形態によれば、バウンダリオブジェクト１８０７は、内部スレッド１８０２を使用して、内部オブジェクト１８０３からアウトバウンド通信を受信し、セカンダリスレッド１８０４を使用して、この通信を適切な外部オブジェクト１８１０に送信する。一実施形態によれば、バウンダリオブジェクトは、内部スレッド上で外部オブジェクトを呼び出すことができるが、それを行うバウンダリオブジェクトは、制約の下にある。すなわち、バウンダリオブジェクトが外部オブジェクトを呼び出すことを許容することが、それを行うことによって無制限の遅延またはデッドロックを引き起こしてはならない。別の制約は、外部オブジェクトの制御の下でコンカレンシドメインの直接再入可能性（direct reentrancy）を妨げる内部オブジェクトへの参照を外部オブジェクトが保持することを防ぐことである。
同期通信は、第１のオブジェクトが実行されているスレッドが、第２のオブジェクトのメソッドを実行するために第２のオブジェクトに入るときに発生する。外部オブジェクト１８１０は、コンカレンシドメイン１８０１内のシングルスレッドオブジェクト１８０３と同期通信しない。したがって、外部オブジェクト１８１０を実行するセカンダリスレッドは、コンカレンシドメイン１８０１内のシングルスレッドオブジェクト１８０３を直接呼び出さず、これに入らない。
図１９に、コンカレンシドメイン１９０１が、外部オブジェクト１９１０とインターフェースをとる別の例示的なシステム１９００を示す。非同期通信の１つの例が、外部オブジェクト１９１０と内部オブジェクト１９０３との間に示されている。コンカレンシドメイン１９０１は、内部スレッド１９０２、内部スレッド１９０２で実行されるように構成されたシングルスレッドオブジェクト１９０３、および外部オブジェクト１９１０と通信するバウンダリオブジェクト１９０７を含む。このシステム１９００の別の実施形態は、複数のバウンダリオブジェクト１９０７および複数のシングルスレッドオブジェクト１９０３を含む。
一実施形態によれば、外部オブジェクト１９１０は、複数のセカンダリスレッド１９０４で実行されるように構成されたマルチスレッドオブジェクト１９０５を含む。マルチスレッドオブジェクト１９０５の１つの部分１９０５Ａは、１つのセカンダリスレッド１９０４Ａで実行されるものとして示され、マルチスレッドオブジェクト１９０５の別の部分１９０５Ｂは、別のセカンダリスレッド１９０４Ｂで実行されるものとして示されている。別の実施形態によれば、外部オブジェクト１９１０は、１つのセカンダリスレッド１９０４で実行されるように構成された、複数のマルチスレッドオブジェクト１９０５またはシングルスレッドオブジェクト（図示せず）を含む。
システム１９００内のコンカレンシドメイン１９０１は、作業キュー１９０８を保持する。作業キュー１９０８は、タスク（例えば、内部シングルスレッドオブジェクト１９０３のメソッドの呼び出し、データ更新、および他の実行可能メソッド）がポストされ（例えば、挿入され）、そして、タスクが除去される、複数要素データ構造である。一実施形態によれば、タスクは、ポストされた順序と同一の順序でのみ、すなわち、先入れ先出し制約に従って作業キュー１９０８から除去される。別の実施形態によれば、作業キュー１９０８にポストされたタスクには、優先順位が割り当てられ、各タスクは、その優先順位に従って除去される。
着信通信は、バウンダリオブジェクト１９０７によって作業キュー１９０８にポストされる。これらのポストされた通信は、作業項目１９１１を形成し、この作業項目１９１１は、コンカレンシドメイン１９０１に関連付けられた内部シングルスレッドオブジェクト１９０３またはバウンダリオブジェクト１９０７のタスクの実行に関する要求（例えば、呼び出し）である。外部オブジェクト１９１０によって、または別のバウンダリオブジェクト１９０７によって、作業項目１９１１を形成する要求を、あるバウンダリオブジェクト１９０７に通信することができる。例えば、図１９では、矢印１９２０によって示されるように、外部オブジェクト１９１０のマルチスレッドオブジェクト１９０５が、タスクを実行するようバウンダリオブジェクト１９０７に要求する。次に、バウンダリオブジェクト１９０７は、矢印１９２５によって示されるように、そのタスクを含む作業項目１９１１を作業キュー１９０８の終わりにポストする。別の実施形態によれば、複数のバウンダリオブジェクト１９０７が、コンカレンシドメイン１９０１に関連付けられ、このバウンダリオブジェクト１９０７のうちの１つまたは複数が、作業項目１９１１を作業キュー１９０８にポストすることができる。さらに別の実施形態によれば、内部シングルスレッドオブジェクト１９０３が、タスクの実行を後の時間に延期するために、作業項目１９１１を作業キュー１９０８にポストするようバウンダリオブジェクト１９０７に要求する。
一実施形態によれば、新しいタスクを作業キュー１９０８にポストする準備をするときのリソースを節約するために、バウンダリオブジェクト１９０７は、作業キュー１９０８をチェックし、キューされた作業項目１９１１のいずれかが関連するタスクを含むかどうかを判定する。関連するタスクがある場合、バウンダリオブジェクト１９０７は、完全に新しい作業項目１９１１として新しいタスクをポストするのではなく、サブタスクとして、前にキューされた関連するタスクと選択的に新しいタスクをバンドルすることができる。
さらに図１９を参照すると、一実施形態によれば、コンカレンシドメイン１９０１は、処理のために作業キュー１９０８からシングルスレッドオブジェクト１９０３に作業項目１９１１をディスパッチするディスパッチャ１９０９を含む。ディスパッチャ１９０９は、内部スレッド１９０２を使用して、作業キュー１９０８から作業項目１９１１を除去し、内部スレッド１９０２での実行のために各作業項目１９１１をディスパッチする。ディスパッチャ１９０９は、作業項目１９１１に含まれるタスクを呼び出す。例えば、図１９では、矢印１９３０によって示されるように、ディスパッチャ１９０９が、作業キュー１９０８から作業項目１９１１をディスパッチする。次に、作業項目１９１１が、矢印１９３５によって示されるように、内部スレッド１９０２で実行される。
一実施形態によれば、作業キュー１９０８への作業項目１９１１のポストは、ディスパッチャ１９０９に動作させることを強制しない。そうではなく、作業項目１９１１の実行は、コンカレンシドメイン１９０１のトップレベルサイクルロジックによって規定される時点まで延期される。作業項目１９１１が作業キュー１９０８にポストされると、内部スレッド１９０２は、ディスパッチャ１９０９による決定に従って、コンカレンシドメイン１９０１の次の適切なサイクルに、要求されたタスクを実行する。したがって、外部オブジェクト１９１０は、作業項目１９１１がいつ除去されるかを決定せず、したがって、内部シングルスレッドオブジェクト１９０３のタスクがいつ呼び出されて実行されるかを決定しない。外部オブジェクト１９１０は、バウンダリオブジェクト１９０７がコンカレンシドメイン１９０１の内部スレッド１９０２のタスクをいつ実行するかについても決定しない。
タスクがディスパッチされ、完了すると、出力結果が、コールバックとしてバウンダリオブジェクト１９０７に渡される。次に、バウンダリオブジェクト１９０７は、その結果を達成したタスクを呼び出した作業項目１９１１を最初にポストした外部オブジェクト１９１０に、そのコールバックを通信する。コールバックの例には、タスクが完了したことを示すデータフラグやメソッド呼び出しなどが含まれる。
図２０に、内部シングルスレッドオブジェクトと外部オブジェクトとの間の非同期通信を示す。本発明の実施形態による、外部オブジェクト２００１と内部シングルスレッドオブジェクト２００９との間の非同期通信中に発生する通信のチェーン２０００が示されている。外部オブジェクト２００１は、まず、バウンダリオブジェクト２００３と通信する（２００２）。この通信２００２は、一般に、呼び出し、またはコンカレンシドメイン（図示せず）に関連するタスクのうちの１つまたは複数を呼び出す要求の形をとる。要求されたタスクは、実際にはシングルスレッドオブジェクト２００９のタスクであるが、外部オブジェクト２００１は、そのタスクをコンカレンシドメインまたはバウンダリオブジェクト２００３に関連付けるだけである。
次に、バウンダリオブジェクト２００３は、作業キュー２００５と通信する（２００４）。この通信２００４は、一般に、作業キュー２００５に作業項目（図示せず）をポストすることを含む。次に、作業キュー２００５は、ディスパッチャ２００７と通信する（２００６）。この通信２００６は、一般に、ディスパッチャ２００７が作業キュー２００５にポストされた各作業項目を順次ディスパッチすることを含む。最後に、ディスパッチャ２００７は、内部シングルスレッドオブジェクト２００９のタスクが呼び出されようとしている当該内部シングルスレッドオブジェクト２００９と通信する（２００８）。この通信２００８は、一般に、内部シングルスレッドオブジェクト２００９のタスクの呼び出しを含む。別の実施形態では、外部オブジェクト２００１は、コンカレンシドメインの別のバウンダリオブジェクト（図示せず）と通信している。
図１８〜図２０を参照して上述した、コンカレンシドメインの境界にまたがる非同期通信は、再入可能性問題から内部シングルスレッドオブジェクトを保護する。内部的に制御される再入可能性は、コンカレンシドメインのトップレベルロジックの制御の下にあるオブジェクト（例えば、内部シングルスレッドオブジェクトまたはバウンダリオブジェクト）が、やはりトップレベルロジックの制御の下にある別のオブジェクトに再入するよう内部スレッドに指示するときに生じることが理解されよう。外部的に制御される再入可能性は、コンカレンシドメインのトップレベルロジックの制御の下にはないオブジェクト（例えば、外部オブジェクト）が、トップレベルロジックの制御の下にある別のオブジェクトに再入するよう内部スレッドに指示するときに生じる。内部的に引き起こされる再入可能性は、内部オブジェクトがそれ自体または同一のコンカレンシドメイン内の別のオブジェクトに再入するときに生じる。外部的に引き起こされる再入可能性は、外部オブジェクトによって引き起こされたイベントが再入可能性に影響を及ぼし、効果的にコンカレンシドメインの内部オブジェクトにおいて集合的に実施されるロジックからの再入可能性に対する制御を除去するときに生じる。その結果は、非決定的再入可能性である（non-deterministic reentrancy）。
再度図１９を参照すると、コンカレンシドメイン１９０１の境界にまたがる非同期通信だけを可能にすることによって、内部シングルスレッドオブジェクト１９０３が、外部的に制御される再入可能性から保護される。例えば、内部シングルスレッドオブジェクト１９０３の実行が、外部オブジェクト１９１０のタスクの呼び出しを含む場合、内部スレッド１９０２は、コンカレンシドメイン１９０１に関連付けられたバウンダリオブジェクト１９０７のうちの１つに入り、外部オブジェクト１９１０のタスクの実行を要求する役割を担うタスクを呼び出すことになる。その後、内部スレッド１９０２は、内部シングルスレッドオブジェクト１９０３のタスクの実行、または作業キュー１９０８からディスパッチされた作業項目１９１１の実行に戻る。内部スレッド１９０２は、外部オブジェクト１９１０に入るためにコンカレンシドメイン１９０１から出ることはないので、外部オブジェクト１９１０の制御の下には入らない。
さらに、内部スレッド１９０２が、外部オブジェクト１９１０のタスクを実行することを許可され、かつそのタスクの実行が、内部シングルスレッドオブジェクト１９０３の別のタスクの呼び出しを含んでいる場合、内部スレッド１９０２は、コンカレンシドメイン１９０１に再入することを許可されない。そうではなく、内部スレッド１９０２は、コンカレンシドメイン１９０１のバウンダリオブジェクト１９０７に入って、作業項目１９１１をポストする役割を担うタスクを呼び出す。代替として、上述したように、ある制約の下で、バウンダリオブジェクトは、タスクの呼び出しのために、内部スレッドで外部オブジェクトを呼び出すことができる。タスクの呼び出しの後に、内部スレッド１９０２は、外部オブジェクト１９１０のタスクの実行に戻り、その後、内部シングルスレッドオブジェクト１９０３の第１の元々のタスクの実行に戻る。すなわち、内部スレッド１９０２は、第１のタスクの実行が完了し、かつコンカレンシドメイン１９０１のディスパッチャ１９０９によってそうするように指示されるまで、外部オブジェクト１９１０による第２のタスクの呼び出しを実行しない。
次に、図２１および図２２を参照して、データソースを含む例示的な外部オブジェクトに関して本発明の実施形態について説明する。図２１に、コンカレンシドメイン２１０１およびデータソース２１１２を含むシステム２１００を示し、図２２に、コンカレンシドメイン２１０１の内部スレッド２１０２と、データソース２１１２のセカンダリスレッド２１０４との間のインターフェースを示す動作フローチャート２２００を示す。一実施形態において、セカンダリスレッド２１０４は、複数のセカンダリスレッド２１０４を含む。コンカレンシドメイン２１０１は、シングルスレッドオブジェクト２１０３およびディスパッチャ２１０９を含み、バウンダリオブジェクト２１０７に関連付けられる。コンカレンシドメイン２１０１は、コンカレンシドメイン２１０１の内部スレッド２１０２で実行される保留中のタスクを表す作業キュー２１０８を保持する。一実施形態において、データソース２１１２はデータベースである。別の実施形態において、データソース２１１２はネットワークである。
内部スレッド２１０２およびセカンダリスレッド２１０４の実行の経路が、両方の図に示されている。図２１では、破線の矢印が、内部スレッド２１０２で発生するタスクの実行を示し、実線の矢印が、セカンダリスレッド２１０４のうちの１つまたは複数で発生するタスクの実行を示す。破線の矢印および実線の矢印の参照番号は、図２２に関して実行される動作またはタスクに対応し、図２２では、各タスクは、各タスクがスレッドで実行される当該スレッドに沿って配置されて示されている。
さらに図２１および図２２を参照すると、この方法は、開始ブロック２２０１で開始され、動作２２０２に進み、動作２２０２において、シングルスレッドオブジェクト２１０３が、データソース２１１２に関連付けられたタスクを呼び出すようバウンダリオブジェクト２１０７に要求する。この要求は、コンカレンシドメイン２１０１の内部スレッド２１０２で実行される。動作２２０３において、ディスパッチャ２１０９が、作業キュー２１０８を順序付け、各作業項目２１１１をディスパッチする。一実施形態によれば、作業項目２１１１は、作業項目２１１１が作業キュー２１０８にポストされた順序で、内部スレッド２１０２を使用してディスパッチされる。例えば、ディスパッチャ２１０９は、間に新しい作業項目２１１１が追加されないと仮定すると、作業項目１から順番を開始し、作業項目７で順番を終了する。すべての新しい作業項目２１１１は、作業項目７の後に追加される。別の実施形態によれば、作業項目２１１１は、割り当てられた優先順位値に従ってディスパッチされる。
メソッド２２０２は、メソッド２２１１にもつながっていて、メソッド２２１１は、動作２２０２と同時に実行される。メソッド２２１１では、バウンダリオブジェクト２１０７が、データソース２１１２に関連付けられたタスクを呼び出す。この呼び出しは、セカンダリスレッド２１０４のうちの１つで実行される。次に、この方法は、動作２２１２に進み、動作２２１２において、データソース２１１２のタスクが、セカンダリスレッド２１０４のうちの１つまたは複数で実行される。次に、動作２２１３は、データベース２１１２が、実行の結果をコールバックとしてバウンダリオブジェクト２１０７に返送することを含む。結果の送信は、セカンダリスレッド２１０４のうちの１つまたは複数で行われる。その後、動作２２１４において、バウンダリオブジェクト２１０７が、このコールバックを作業項目２１１１として作業キュー２１０８にポストする。このポストは、セカンダリスレッド２１０４のうちの１つまたは複数で実行される。
この方法は、動作２２１４から動作２２０４に進む。動作２２０３も、動作２２０４につながっている。動作２２０４は、動作２２０３において作業キュー２１０８内の作業項目２１１１を順次実行していたディスパッチャ２１０９が、動作２２１４においてバウンダリオブジェクト２１０７によって追加されたコールバック作業項目２１１１に達したときに発生する。ディスパッチャ２１０９は、内部スレッド２１０２を使用してこのコールバックをディスパッチする。コールバックがディスパッチされると、ディスパッチャ２１０９は、動作２２０５において、作業キュー２１０８内の各作業項目２１１１の順次ディスパッチを継続する。この方法は、２２０６で終了する。
次に、図２３および図２４を参照して、第２のコンカレンシドメインを含む例示的な外部オブジェクトに関して本発明の実施形態について説明する。図２３に、第１のコンカレンシドメイン２３０１および第２のコンカレンシドメイン２３２１を含むシステム２３００を示し、図２４に、第１のコンカレンシドメイン２３０１が第２のコンカレンシドメイン２３２１とインターフェースをとる動作フローチャート２４００を示す。各コンカレンシドメイン２３０１および２３２１はそれぞれ、内部スレッド２３０２および２３２２と、シングルスレッドオブジェクト２３０３および２３２３と、ディスパッチャ２３０９および２３２９とを含む。各コンカレンシドメイン２３０１および２３２１はそれぞれ、バウンダリオブジェクト２３０７および２３２７に関連付けられ、内部スレッド２３０２および２３２２で実行される保留中の作業項目２３１１および２３３１を表す作業キュー２３０８および２３２８を保持する。図２３では、第１の破線の矢印のセットが、内部スレッド２３０２で発生するタスクの実行を示し、実線のセットが、セカンダリスレッド２３０４のうちの１つまたは複数で発生するタスクの実行を示し、第２の破線の矢印のセットが、第２の内部スレッド２３２２で発生するタスクの実行を示す。これらの破線および実線の矢印は、第１のコンカレンシドメイン２３０１と第２のコンカレンシドメイン２３２１との間における通信に伴う様々な動作を実行するものとして示されている。これらの矢印の参照番号は、図２４に関して実行される動作またはタスクに対応する。
さらに図２３および図２４を参照すると、この方法は、開始ブロック２４０１で開始され、動作２４０２と２４２２との両方に進む。動作２４２２は、第２のコンカレンシドメイン２３２１のディスパッチャ２３２９が、内部スレッド２３２２を使用して作業キュー２３２８における各作業項目２３３１を順次ディスパッチすることを含む。動作２４０２は、動作２４２２と同時に実行される。動作２４０２において、第１のコンカレンシドメイン２３０１のシングルスレッドオブジェクト２３０３が、第２のコンカレンシドメイン２３２１のオブジェクトのうちの１つからのタスクを呼び出すようバウンダリオブジェクト２３０７に要求する。一実施形態において、要求されるタスクは、第２のコンカレンシドメイン２３２１のシングルスレッドオブジェクト２３２３のうちの１つにおけるタスクである。別の実施形態においては、要求されるタスクは、第２のコンカレンシドメイン２３２１に関連付けられたバウンダリオブジェクト２３２７のうちの１つにおけるタスクである。
この方法は、動作２４０２から、動作２４０３と２４１２との両方に進む。動作２４０３において、第１のコンカレンシドメイン２３０１のディスパッチャ２３０９が、作業キュー２３０８における各作業項目２３１１を順次ディスパッチする。動作２４１２において、第１のコンカレンシドメイン２３０１のバウンダリオブジェクト２３０７が、第２のコンカレンシドメイン２３２１のバウンダリオブジェクト２３２７と通信するために、セカンダリスレッド２３０４のうちの１つまたは複数を使用する。この通信は、タスクを呼び出す要求を含む。その後、動作２４１３において、第２のバウンダリオブジェクト２３２７が、要求されたタスクを作業項目２３３１として作業キュー２３２８にポストする。このポストは、セカンダリスレッド２３０４のうちの１つまたは複数を使用して実行される。
動作２４１３と動作２４２２との両方が、動作２４２３につながっている。動作２４２３において、ディスパッチャ２３２９が、要求されたタスクを含む作業項目２３３１に達し、この作業項目２３１１をディスパッチする。このディスパッチは、第２のコンカレンシドメイン２３２１の内部スレッド２３２２で実行される。その後、動作２４２４において、このタスクが、第１のコンカレンシドメイン２３０１内のシングルスレッドオブジェクト２３０３へのコールバックとして実行される。この時点で、この方法は、再度分岐して、動作２４２５と２４１４との両方に進む。動作２４２５において、ディスパッチャ２３２９が、作業キュー２３２８における各作業項目２３３１の順次ディスパッチを継続する。
動作２４１４は、動作２４２５と同時に発生する。動作２４１４において、第２のコンカレンシドメイン２３２１のバウンダリオブジェクト２３２７が、１つまたは複数のセカンダリスレッド２３０４を使用して、コールバックを作業項目２３１１として作業キュー２３０８にポストするよう、第１のコンカレンシドメイン２３０１のバウンダリオブジェクト２３０７に要求する。次に、動作２４１５において、バウンダリオブジェクト２３０７が、このコールバックを作業キュー２３０８にポストする。このポストは、セカンダリスレッド２３０４のうちの１つまたは複数で実行される。
動作２４０４は、第１のコンカレンシドメイン２３０１のディスパッチャ２３０９が、作業キュー２３０８にポストされたコールバックに達したときに発生する。ディスパッチャ２３０９は、第１のコンカレンシドメイン２３０１の内部スレッド２３０２を使用して、コールバックをディスパッチする。動作２４０５において、コールバックが実行される。次に、この方法は、動作２４０６に進み、動作２４０６において、ディスパッチャ２３０９が、作業キュー２３０８の順序付けを継続し、順番に各作業項目２３１１をディスパッチする。この方法は、２４０６で終了する。
システムの別の例（図示せず）は、相互に、および他の外部オブジェクトとインターフェースをとる３つ以上のコンカレンシドメインを含む。そのようなシステムは、実質的に本明細書で説明するものと同一の動作に従って機能する。そのシステム内の各コンカレンシドメインは、内部スレッド、１つまたは複数のシングルスレッドオブジェクト、およびディスパッチャを含む。各コンカレンシドメインは、少なくとも１つのバウンダリオブジェクトに関連付けられ、作業キューを保持する。コンカレンシドメインの境界にまたがるすべての通信は、非同期である（例えば、それぞれのバウンダリオブジェクト、作業キュー、およびディスパッチャを介してフィルタリングされる）。
（アプリケーション記述言語）
上記にて簡潔に説明したように、本発明の実施形態は、図３を参照して上述したアプリケーション３０４など、アプリケーションフレームワーク内に含まれるすべてのアプリケーションおよびコンポーネントの宣言ルールおよび記述を提供する、アプリケーション記述（ＸＡＤ）およびアプリケーション記述（ＸＡＤ）エンジンを含む。ある実施形態の諸態様は、アプリケーションを特徴付けるデータフロー、データバインディング、およびルールを作成するための宣言言語または記述言語に関連する。他の態様は、ランタイムエンジンに関連し、このランタイムエンジンは、ランタイムに、宣言アプリケーションすなわち「アプリケーション記述」を処理するか、または実行して、データを表示し、かつ／または処理するオブジェクトを（ビルダを介して）作成する。その結果、開発者は、データ処理を行うオブジェクトの実際のコードを記述する必要はなく、最終的にコンパイルされて実行される宣言アプリケーションファイルを記述するだけでよい。以下で詳細に説明するように、そのようなシステムは、アプリケーションをプログラミングする従来技術の方法よりも多数の利点を提供する。
上記にて簡潔に説明したように、本発明の実施形態は、図３を参照して上述したアプリケーション３０４など、アプリケーションフレームワーク内に含まれるすべてのアプリケーションおよびコンポーネントの宣言ルールおよび記述を提供する、アプリケーション記述（ＸＡＤ）およびアプリケーション記述（ＸＡＤ）エンジンを含む。ある実施形態の諸態様は、アプリケーションを特徴付けるデータフロー、データバインディング、およびルールを作成するための宣言言語または記述言語に関連する。他の態様は、ランタイムエンジンに関連し、このランタイムエンジンは、ランタイムに、宣言アプリケーションすなわち「アプリケーション記述」を処理するか、または実行して、データを表示し、かつ／または処理するオブジェクトを（ビルダを介して）作成する。その結果、開発者は、データ処理を行うオブジェクトの実際のコードを記述する必要はなく、最終的にコンパイルされて実行される宣言アプリケーションファイルを記述するだけでよい。以下で詳細に説明するように、そのようなシステムは、アプリケーションをプログラミングする従来技術の方法よりも多数の利点を提供する。
そのような宣言言語の使用は、アプリケーションのデータ、データの処理、データの変換、ユーザインターフェース（ＵＩ）、およびＵＩがデータと相互作用する方法を宣言的にモデル化することによる命令言語の使用とは異なる。本発明の実施形態は、ＸＭＬアプリケーションフレームワーク（ＸＡＦ）アプリケーションを特徴付けるために使用される特定の宣言言語に関連する。本明細書では、この宣言言語を、しばしばＸＡＦアプリケーション定義（ＸＡＤ）と呼ぶ。本明細書で説明する多数の実施形態の詳細において、ＸＭＬの使用について言及するが、当業者であれば、他の構文を使用して本発明の諸態様を実施できることが認識されよう。
宣言アプリケーションファイルと、データ処理を実行するインスタンス化されるオブジェクトの構成との間のそのような分離をもたらすために、一実施形態では、アプリケーションをビルドして実行するプラットフォームなどのプラットフォームを使用することができる。本発明の諸態様によれば、本明細書では、使用されるプラットフォームをＸＡＦプラットフォームと呼び、このＸＡＦプラットフォームは、そのようなソフトウェアアプリケーションをビルドして実行するプラットフォームである。具体的に言うと、ＸＡＦは、データを均一に表すためにＸＭＬも使用し、各アプリケーションのビルドに対する非常にコンポーネント化された手法を利用する。一実施形態において、ＸＡＦは、ＸＭＬを利用して、強力なデータ変換機能およびリッチデータを提供する。ＸＭＬの機能を使用して、外部データとアプリケーション状態との両方にアクセスし、操作することができる。ユーザインターフェースおよび複雑なデータフローは、ＸＡＤを用いて定義することができる。
上述したように、ＸＡＤは、ＸＡＦアプリケーションの作成に使用される宣言言語である。図２５は、実行可能アプリケーションを形成するために作成されるデータおよびオブジェクトと関連する高水準のアプリケーション記述を示す図である。ランタイムにコンポーネント２５１０、２５１２、および２５１４を作成して、データを処理し、表示し、かつ／または編集し、実行中のアプリケーションを構成するオブジェクトの構成を本質的に構成するように、ＸＡＤを使用して、データセットまたはデータストア２５０４、２５０６、および２５０８などのデータを宣言するか、または記述するアプリケーション記述２５０２を作成する。
本明細書における例示的な実施形態では、アプリケーション記述２５０２は、明確に形成されたＸＭＬなどの宣言構造のセットとして表現される。したがって、アプリケーション記述２５０２は、１つまたは複数のオブジェクト２５１０、２５１２、および２５１４を実行中のアプリケーション内でどのように構成しなければならないかを記述する。本質的に、アプリケーション記述２５０２は、アプリケーションの結果ではなくアプリケーションの構成を計算するのに使用され、アプリケーションの結果の計算は、オブジェクト２５１０、２５１２、および２５１４によって行われる。オブジェクト２５１０、２５１２、および２５１４は、非宣言言語で記述された他のアプリケーションによって使用することもできるので、ＸＡＤは、そのようなオブジェクトの再利用によってアプリケーション開発を改善する。さらに、ＸＡＤは、以下でより詳細に説明するように、従来の静的な宣言アプリケーション定義を使用することによっては不可能な方法で、アプリケーションの動的な作成および変更を可能にする。
図２５に示されたデータ２５０４、２５０６、および２５０８に関して、これらのソースは、テキストデータストア、ＳＱＬデータベースストア、ＸＭＬソース、ウェブサービスソースなどに関連するものとすることができる。実際に、アプリケーション記述２５０２は、データを中心とした、データ中心型（data centric）になっていると考えられる。アプリケーション状態は、「データ」の別のソースと考えることができ、オブジェクト２５１０、２５１２、および２５１４の構成が操作している、より標準的なデータに類似する形で扱うことができる。したがって、開発者は、主に、データがアプリケーションを通る形と、アプリケーションがそのデータにどのように応答するかを制御するルールとの指定に関心をもてばよい。ＸＡＤは、アプリケーションをビルドして変更する単純で安価な方法を提供し、これにより、別個のソフトウェアアプリケーションニッチ（software application niche）をターゲットにすることと、新しい開発者に対する複雑さのバーを下げることとを可能にする。特許請求される発明を使用してビルドされたアプリケーションは、そのアプリケーションに流れ込むデータを集約して変換する能力だけではなく、データ型に最も適切な１つまたは複数のユーザインターフェースを選択する能力も有する。
オブジェクト２５１０、２５１２、および２５１４は、ビューワ、エディタ、トランスフォーマなど、明確に要素化されたコンポーネントを表す。アプリケーション記述は、「予めプログラムされた」コンポーネントを呼び出すことができ、かつ／またはセットに新しいコンポーネントを追加することができる。
オブジェクトは、明確に定義された型を有し、したがって、対応するＸＡＤタグおよびパラメータは、ＸＡＤ言語における対応する型を有する。ＸＡＤは、強く型付けされており、ＸＡＤコンパイラは、エラーを静的に検出する。タグおよびパラメータは、戻り型およびカーディナリティ制約（cardinality constraint）を有する。さらに、データ型は、追加の制約、すなわち、スキーマ、変換要件、およびアクセッサアベイラビリティ（アクセッサは、ＸＭＬデータ用に強く型付けされたオブジェクトファサード（object facade）である）をサポートする。
ＸＡＤは、単純に１つまたは複数のテキストファイルを変更することによって既存のアプリケーションを変更するか、または補強することを可能にするだけではなく、以下でより詳細に説明するように、開発者がセキュリティを保つために変更およびアドイン（既存のアプリケーションに追加できるモジュールであって、おおむねブラウザプラグインに類似するもの）を制約することと、ユーザモデルの整合性とも可能にする。
（ＸＡＤアプリケーション例）
ＸＡＤ、具体的にはアプリケーション記述２５０２などのＸＡＤアプリケーション記述のニュアンスの多くを理解してもらうために、記述例について説明する。表１に、本発明の一実施形態によるＸＡＤアプリケーション例のソースコードを示す。表１のＸＡＤアプリケーション例は、比較的単純であり、多数の他の複雑なＸＡＤアプリケーションが企図されている。実際に、表１に示された例は、「Ｈｅｌｌｏ Ｗｏｒｌｄ」メッセージを表示するという唯一の機能を有する。
ＸＡＤ、具体的にはアプリケーション記述２５０２などのＸＡＤアプリケーション記述のニュアンスの多くを理解してもらうために、記述例について説明する。表１に、本発明の一実施形態によるＸＡＤアプリケーション例のソースコードを示す。表１のＸＡＤアプリケーション例は、比較的単純であり、多数の他の複雑なＸＡＤアプリケーションが企図されている。実際に、表１に示された例は、「Ｈｅｌｌｏ Ｗｏｒｌｄ」メッセージを表示するという唯一の機能を有する。
表１に示された例は、データを処理する、結果として生じるオブジェクトを記述するために、複数のＸＭＬタグを含む。行１は、ＸＭＬのバージョンを識別し、行２は、以下でより詳細に説明する、ＸＡＤアプリケーション記述のシステムタグを識別する。行３〜４は、ＸＡＦで使用可能なタグのいくつかのネームスペースを識別する。この説明における表１の例の主要な部分は、行８に示された「Ａｐｐｌｉｃａｔｉｏｎ」タグである。アプリケーションタグは、アプリケーションを調整するアプリケーションオブジェクトのランタイムでの作成を生じさせ、最高レベルのアプリケーション機能を制御するエンティティタグの例である。同様に、行９の「Ｗｉｎｄｏｗ」タグ（エンティティタグの別の例）は、ウィンドウオブジェクト、すなわち、アプリケーションのフレームを表示する役割を担うユーザインターフェースエンティティの作成を生じさせる。このケースでは、「Ｗｉｎｄｏｗ」は、「Ａｐｐｌｉｃａｔｉｏｎ」のパラメータである。最後に、「ＴｅｘｔＢｌｏｃｋ」エンティティ、すなわち、行１０におけるテキストタグの結果として作成される結果として生じるテキストオブジェクトは、テキスト（このケースでは「Ｈｅｌｌｏ Ｗｏｒｌｄ」）を表示する役割を担う、ランタイムに作成されるユーザインターフェースエンティティである。（ビルダを介して）オブジェクトを作成するためのタグの使用は、以下でより詳細に説明する。前述の例は、単に、より単純なＸＡＤアプリケーション例を示すために提供したものである。
動作中、表１に示されたＸＡＤアプリケーションは、コンパイルされて実行され、図２６に全般的に示されているように、アプリケーション、ウィンドウ、およびテキストオブジェクトを作成する。すなわち、図２６は、アプリケーション記述２６０２を示し、このアプリケーション記述２６０２は、本発明の特定の実施形態に従ってデータを処理するために実行されるときの、図２５に示された記述２５０２および／または表１に示されたＸＡＤアプリケーションに類似するものである。
最初に、開発者は、アプリケーション記述２６０２を作成する。一実施形態において、ＸＡＤファイル２６０２の最初のタグは、「＜ｓｙｓ：ＸＡＤ＞」である。また、正しく動作させるために、コンピュータシステムは、例えばＸＡＦ ＳＤＫをインストールすることによるなど、ＸＡＦまたは任意の適切な均等物にアクセスすることができる。アプリケーション起動コマンドを発行すると、ＸＡＤ２６０２が、自動的に検証され、一実施形態では、より効率的な形にコンパイルされる。コンパイラまたはＸＡＦエンジン２６０４は、ＸＡＤ２６０２を解析し、コンパイルされた形を実行し、これによって、必要なオブジェクトがインスタンス化される。また、エンジン２６０４は、オブジェクトコンポーネント（エンティティとも呼ぶ）２６１２、２６１４、２６１６、および２６１８のグラフを作成して、一緒に接続し、最終的にデータを処理するアプリケーション２６０６を作成する。その一方で、エンジン２６０４は、様々なオブジェクトを必要なデータ２６０８に接続する（すなわち、バインドする）。エンジン２６０４は、オブジェクトをインスタンス化し、オブジェクトを一緒に接続してアプリケーション２６０６を作成するという点で、構成サービスと考えることもできる。
アプリケーション２６０６は、接続されたコンポーネント２６１２、２６１４、２６１６、および２６１８のグラフである。例えば、アプリケーション２６０６は、１つまたは複数のデータコネクタエンティティ２６１２を有することができる。データコネクタエンティティ２６１２は、データをシステムに接続し、かつ使用可能な様々なデータストアと通信するオブジェクトを表す。別のタイプのエンティティは、ＵＩコネクタ２６１４に関する。ＵＩコネクタ２６１４は、ユーザインターフェースのフィーチャ（feature）を実際に処理し、かつユーザインターフェース２６２０と実際に通信するオブジェクトを表す。アプリケーション２６０６には、情報をＵＩコネクタに中継する前に、通常はデータの何らかの変換を提供する変換２６１６と、データの変更など、何らかのタイプのアクションを実行するためにデータを処理するアクション２６１８とがさらに含まれる。必要なコンポーネントを作成するプロセスおよびオブジェクトをデータにバインドするプロセスのさらなる詳細については、以下で説明する。
この説明から理解できるように、ＸＡＤ２６０２で使用されるタグは、特定のオブジェクトを参照するのに使用されるのではなく、ＸＡＤタグは、オブジェクトファクトリ（object factory）を参照する。オブジェクトファクトリとは、タグで指定されたパラメータを使用して１つまたは複数のエンティティをビルドするために、ＸＡＤがタグビルダクラスと共に使用する記述である。エンジン２６０４が、そのようなオブジェクトの実際の作成を提供する。一実施形態において、エンジンは、既存の、かつ／または再利用可能なタグおよびオブジェクトの詳細を提供するコンポーネントライブラリ２６２２にアクセスすることができる。
その結果、アプリケーション２６０２は、タグを使用して定義され、アプリケーションのモジュラ式構築が可能になる。図２７に、この概念によるコンポーネント間の構造的な相互関係を示す。エンティティタグ２７０２（表１の行８、９、および１０に示されたエンティティタグなど）は、エンティティ２７０６に関連付けられる。ビルダ２７０４が、エンティティタグ２７０２を読み取り、マッピングする。ビルダ２７０４は、エンティティタグに関連付けられた１つまたは複数のオブジェクト（図示せず）をインスタンス化して接続し、エンティティタグ２７０２をエンティティ２７０６に接続する。開発者にとって、エンティティタグ２７０２は、エンティティタグ２７０２に関連するエンティティ２７０６に暗黙的にマッピングされるように見える。というのは、マッピング、インスタンス化、接続、および初期化をバックグラウンドで行うことができるからである。
これらの一般的な原理を念頭において、ＸＡＤの詳細の一部について説明する。この言語のさらなる詳細について、本明細書に明示的に組み込まれている仕様書を、付録Ａとして添付する。
（オブジェクトおよびファクトリ）
オブジェクトは、ビルダコンポーネントとすることができるファクトリを介して、またはＸＡＤのフラグメントを用いてカスタマイズされたＸＡＤエンジンを介して、インスタンス化される。ファクトリは、遅延評価または仮想化などのために、遅延インスタンス化を可能にする（即座にインスタンス化される必要がないオブジェクトのコストを節約する）。これは、「ＮｅｗＳｃｏｐｅ＝“Ｔｒｕｅ”」属性を有するパラメータを介して達成される。ｓｙｓ：Ｓｗｉｔｃｈ構造を介する条件付きインスタンス化と共に、ファクトリは、動的なデータ依存アプリケーション構成を可能にする。ＸＡＦプラットフォームにおける依存関係管理および再検証の使用により、ＸＡＤエンジンは、データが変化するときに、必要に応じてアプリケーションを自動的に再構成することが可能となる。これは、普通に記述されたアプリケーションにおいて一般的であり、かつコストが高くエラーを被りがちな、命令再構成コードの必要性をなくす。ＸＡＤエンジンは、ファクトリをＸＡＤ言語で定義することを可能にし、対応するファクトリ実装を自動的に構築する。
オブジェクトは、ビルダコンポーネントとすることができるファクトリを介して、またはＸＡＤのフラグメントを用いてカスタマイズされたＸＡＤエンジンを介して、インスタンス化される。ファクトリは、遅延評価または仮想化などのために、遅延インスタンス化を可能にする（即座にインスタンス化される必要がないオブジェクトのコストを節約する）。これは、「ＮｅｗＳｃｏｐｅ＝“Ｔｒｕｅ”」属性を有するパラメータを介して達成される。ｓｙｓ：Ｓｗｉｔｃｈ構造を介する条件付きインスタンス化と共に、ファクトリは、動的なデータ依存アプリケーション構成を可能にする。ＸＡＦプラットフォームにおける依存関係管理および再検証の使用により、ＸＡＤエンジンは、データが変化するときに、必要に応じてアプリケーションを自動的に再構成することが可能となる。これは、普通に記述されたアプリケーションにおいて一般的であり、かつコストが高くエラーを被りがちな、命令再構成コードの必要性をなくす。ＸＡＤエンジンは、ファクトリをＸＡＤ言語で定義することを可能にし、対応するファクトリ実装を自動的に構築する。
ＸＡＤ内のフレームワークタグを使用して、図２５に示されたオブジェクト２５１０、２５１２、および２５１４など、様々なオブジェクトタイプをインスタンス化することができる。そのようなオブジェクトの１つは、データコネクタとも呼ばれる「データプロバイダ」オブジェクトに関し、データプロバイダオブジェクトは、アプリケーションが使用できるデータのソースおよび操作を表す。データプロバイダオブジェクトは、データソース（これによってアプリケーションは外部データを受信することができる）およびデータ変換（着信データに対して実行される論理演算または算術演算）に接続される。
ＸＡＤ内のフレームワークタグを使用してインスタンス化することができるオブジェクトの別のタイプは、ユーザインターフェースオブジェクトである。ユーザインターフェースオブジェクトは、コントロール表示および入力処理に関連する機能を提供する。ユーザインターフェースオブジェクトは、アクションをトリガするために使用することができる（以下で説明するアクションを参照されたい）。
ＸＡＤ内のフレームワークタグを使用してインスタンス化することができるオブジェクトのさらに別のタイプは、アクションである。アクションは、ユーザイベントに関するハンドルに「フック」（ユーザインターフェース要素にアタッチされる関数）を提供する。例えば、ユーザインターフェースにおけるボタンのクリックは、そのボタンに関連付けられたアクションオブジェクトをアクティブ化する。
ユーザイベントが発生するときに、対応するアクションを使用して、イベントの詳細を記憶し、渡すことができる。イベントの詳細は、メインメモリ内に、ハードドライブ上に、または他のメモリ媒体上に記憶することができる。イベントの詳細は、以下で説明する「スコープ」変数を使用して渡される。例えば、ユーザイベントがマウスクリックである場合、そのイベント時のマウスのｘ位置およびｙ位置を記憶することが意味をなす可能性がある。ユーザイベントが発生したときに記憶できる他の詳細には、どのキーが押下されたか、データ要素のリストのどのインデックスがイベント時に選択されていたか、テーブルのどの行および／または列がイベント時に選択されていたか、テーブルのどの行および／または列がイベント時にユーザに見えていたか、などが含まれるが、これらに限定されるものではない。これらのイベントの使用を介して、アプリケーション機能が実現される。
（エンティティタグ）
上記の表１に示された例から理解できるように、ＸＡＤアプリケーションは、タグの使用を含む。一実施形態では、タグの１つの種類は、「エンティティタグ」である。グループ化タグまたはセレクタタグなどの他のタグについては、以下でより詳細に説明する。エンティティタグは、ランタイムに共通言語ランタイム（ＣＬＲ）オブジェクトにマッピングされる。ＣＬＲオブジェクトに関する唯一の制限は、（一実施形態において、）ＣＬＲオブジェクトがＸＡＦエンティティでなければならないことである。ＸＡＦエンティティにするために、ＣＬＲオブジェクトは、２つのベースクラス、例えば「Ｍｉｃｒｏｓｏｆｔ．Ｘａｆ．Ｃｏｒｅ．ＢａｓｅＴｙｐｅｓ．ＥｎｔｉｔｙＥｌｅｍｅｎｔ」または「Ｍｉｃｒｏｓｏｆｔ．Ｘａｆ．Ｃｏｒｅ．ＢａｓｅＴｙｐｅｓ．ＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅ」から派生し、ＸＡＦによって定義されるある種のプロトコルおよび契約を厳守する。
上記の表１に示された例から理解できるように、ＸＡＤアプリケーションは、タグの使用を含む。一実施形態では、タグの１つの種類は、「エンティティタグ」である。グループ化タグまたはセレクタタグなどの他のタグについては、以下でより詳細に説明する。エンティティタグは、ランタイムに共通言語ランタイム（ＣＬＲ）オブジェクトにマッピングされる。ＣＬＲオブジェクトに関する唯一の制限は、（一実施形態において、）ＣＬＲオブジェクトがＸＡＦエンティティでなければならないことである。ＸＡＦエンティティにするために、ＣＬＲオブジェクトは、２つのベースクラス、例えば「Ｍｉｃｒｏｓｏｆｔ．Ｘａｆ．Ｃｏｒｅ．ＢａｓｅＴｙｐｅｓ．ＥｎｔｉｔｙＥｌｅｍｅｎｔ」または「Ｍｉｃｒｏｓｏｆｔ．Ｘａｆ．Ｃｏｒｅ．ＢａｓｅＴｙｐｅｓ．ＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅ」から派生し、ＸＡＦによって定義されるある種のプロトコルおよび契約を厳守する。
ビルダ２７０４（図２７）は、エンティティを実際にインスタンス化する役割を担い、しばしば、「タグビルダ」または「エンティティビルダ」と呼ばれる。一実施形態において、エンティティビルダは、エンティティを作成し、かつ／またはエンティティを互いに接続する、ユーザ定義の．ＮＥＴクラスである。エンティティビルダは、プリミティブＸＡＤタグを実装するのに使用される。さらに、エンティティビルダは、エンジン２６０４と、言語のカスタム拡張との間の相互作用のポイントであり、その結果、一実施形態では、ＸＡＤ言語が、エンティティビルダを記述する要件を具体的に定義する。タグビルダまたはエンティティビルダのさらなる詳細については、本明細書に明示的に組み込まれている添付された付録Ａのセクション３．５で提供されている。
例示的なエンティティタグが、上記の表１の行８、９、および１０に示されている。例えば、行８には、アプリケーションエンティティタグが示されている。上述したように、このタグは、アプリケーションを調整するエンティティのインスタンス化を生じさせ、最高レベルのアプリケーション機能を制御する。ウィンドウエンティティタグ（表１の行９）は、アプリケーションのフレームを表示する役割を担うユーザインターフェースエンティティの作成を生じさせる。最後に、テキストエンティティタグ（表１の行１０）は、テキスト（このケースでは「Ｈｅｌｌｏ Ｗｏｒｌｄ」）を表示する役割を担うユーザインターフェースエンティティの作成を生じさせる。当業者であれば、多数の他のエンティティ型を定義し、使用することができることが理解されよう。
表１に示されたアプリケーションエンティティタグ、ウィンドウエンティティタグ、またはテキストエンティティタグなどのエンティティタグを使用する前に、各エンティティタグは、例えばＸＡＦプラットフォーム内で定義される。実際に、すべてのエンティティタグは、対応するタグ定義を有する。すべてのタグ定義は、すべてのエンティティタグをエンティティに最終的にマッピングするのに十分な情報を含む。エンティティタグは、フォームの宣言によって定義され、例えば、「Ｔｅｘｔ」タグ定義は、「＜ｓｙｓ：ＴａｇＤｅｆｉｎｉｔｉｏｎ Ｎａｍｅ＝“Ｔｅｘｔ” ．．． ＞ ．．．」から始まり、「＜／ｓｙｓ：ＴａｇＤｅｆｉｎｉｔｉｏｎ＞」で終わる。
この定義に含まれるのは、新しいタグの「名前」、例えば「Ｔｅｘｔ」と、特定のエンティティタグの「型」である。エンティティタグを、様々な型に分類することができ、すべてのエンティティタグは、１つの型を有する。これらの型は、拡張可能なセットであり、実際に、タグに関連付けられたエンティティのＣＬＲ型に対応する。ＸＡＦフレームワークによって使用されるいくつかの型には、「ｓｙｓ：Ｄａｔａ」、「ｓｙｓ：ＥｖｅｎｔＨａｎｄｌｅｒ」、「ｆｗｋ：ＵＩＥｌｅｍｅｎｔ」、および「ｓｙｓ：Ｓｅｌｅｃｔｏｒ」が含まれる。タグがフレームワークまたはシステムのどちらに追加されるかは通常、タグが、コア言語と同一のレートで内部エンジンインターフェースおよび／またはバージョンを要するかどうかに依存する。そうである場合には、そのタグは、システムに追加されなければならず、そうでない場合にはフレームワークに追加される。型は、その定義で宣言される。上記にて示したＴｅｘｔ定義を続けると、このタグ定義は、以下の表２に示されるように拡張することができる。
表２では、タグ定義は、Ｔｅｘｔという名前で型ｆｗｋ：ＵＩＥｌｅｍｅｎｔ（エンティティのＵＩ Ｅｌｅｍｅｎｔ型を示すフレームワークタグ）の新しいエンティティタグを作成しなければならないことを示している。このＴｅｘｔタグは、その後、ｆｗｋ：ＵＩＥｌｅｍｅｎｔエンティティを呼び出せる場所であればどこでも使用することができる。Ｔｅｘｔエンティティタグの例は、表１に示されたＨｅｌｌｏＷｏｒｌｄ．ｘａｄの例において見ることができる。
（パラメータ化）
通常、ＸＡＤアプリケーション記述内の各エンティティタグは、結果として生じるオブジェクトまたはエンティティをどのように作成し、接続し、または構成するかを記述するために、いくつかのパラメータを有する。パラメータは、データへの参照、またはファクトリもしくはオブジェクトへの参照とすることができる。例えば、スコープ属性をパラメータに関連付けて、そのパラメータが、ファクトリまたはオブジェクトのどちらを参照するかを示すことができる。パラメータが、ある型のオブジェクトが適用可能であることを必要とする場合、パラメータを、型一貫性チェックのために、その型を用いてマークすることができる。そのような型チェックは、アプリケーションの実行が型不一致をもたらさないことを確実にする。この型不一致は、不正な計算を引き起こす可能性がある。
通常、ＸＡＤアプリケーション記述内の各エンティティタグは、結果として生じるオブジェクトまたはエンティティをどのように作成し、接続し、または構成するかを記述するために、いくつかのパラメータを有する。パラメータは、データへの参照、またはファクトリもしくはオブジェクトへの参照とすることができる。例えば、スコープ属性をパラメータに関連付けて、そのパラメータが、ファクトリまたはオブジェクトのどちらを参照するかを示すことができる。パラメータが、ある型のオブジェクトが適用可能であることを必要とする場合、パラメータを、型一貫性チェックのために、その型を用いてマークすることができる。そのような型チェックは、アプリケーションの実行が型不一致をもたらさないことを確実にする。この型不一致は、不正な計算を引き起こす可能性がある。
ＸＡＤは、エンティティのパラメータを宣言する多数の異なる形を許容する。一般的な形を、以下の表３に示す。
まず、「Ｐａｒａｍ」は、ＸＡＤの実施形態内で予約済みの名前であり、パラメータを定義するのに使用される。また、表３で省略記号によって示されているように、１つまたは複数の他のパラメータを、Ｔｅｘｔタグ定義に追加することもできる。この例では、型ＵＩ ｅｌｅｍｅｎｔでＴｅｘｔという名前の新しいエンティティを作成しなければならない。さらに、型「Ｄａｔａ」（より具体的には「Ｓｔｒｉｎｇ Ｄａｔａ」）の「ＦｏｎｔＦａｍｉｌｙ」という名前の単一のパラメータを作成しなければならない。結果として生じるＴｅｘｔタグは、静的な内容の文字列、例えば、「＜ｓｙｓ：Ｔｅｘｔ ＦｏｎｔＦａｍｉｌｙ＝“Ａｒｉａｌ” ．．．／＞と共に使用することができ、であり、「＜ｓｙｓ：Ｔｅｘｔ ＦｏｎｔＦａｍｉｌｙ＝“Ａｒｉａｌ” ．．．／＞は、テキストをＡｒｉａｌフォントにするものである。重要なことに、タグ定義パラメータは、そのパラメータと同一の名前を有するタグの実際のインスタンス内の属性に対応する。
代替として、タグを、他のエンティティであるパラメータをとるように定義することができ、例えば「＜Ｔｅｘｔ ＦｏｎｔＳｉｚｅ＝“２５”＞ ＜ｆｏｏ：ＲａｎｄｏｍＷｏｒｄＧｅｎｅｒａｔｏｒ Ｐａｒａｍ＝“Ｔｅｘｔ” ／＞ ＜／Ｔｅｘｔ＞」とすることができる。一実施形態において、上記の定義は、ＴｅｘｔタグのＴｅｘｔ属性に、ｆｏｏ：ＲａｎｄｏｍＷｏｒｄＧｅｎｅｒａｔｏｒ関数オブジェクトによって返される値を使用させ、結果として生じる値を２５ポイントフォントでスクリーンにレンダリングさせる。別の実施形態では、この定義を、「＜Ｔｅｘｔ ＦｏｎｔＳｉｚｅ＝“２５”＞ ＜Ｔｅｘｔ．Ｔｅｘｔ＞ ＜ｆｏｏ：ＲａｎｄｏｍＷｏｒｄＧｅｎｅｒａｔｏｒ ／＞ ＜／Ｔｅｘｔ．Ｔｅｘｔ＞ ＜／Ｔｅｘｔ＞」と書くことができる。後者の定義は、Ｔｅｘｔエンティティをインスタンス化し、そのＴｅｘｔ属性をｆｏｏ：ＲａｎｄｏｍＷｏｒｄＧｅｎｅｒａｔｏｒの値として定義する。
一実施形態では、パラメータ自体に、複数のそれ自体のエンティティを含めることができる。表４に、パラメータを設定するコード部分例を示す。
表４に示されたコード（行１）は、ＦｌｏｗＰａｎｅｌという名前のＵＩ Ｅｌｅｍｅｎｔを定義し、複数のパラメータを有し、したがって、ＵＩ要素のフローの表示を生じさせる。表示されるＵＩ要素のセットは、表４（行２）で定義される「Ｃｈｉｌｄｒｅｎ」という名前の単一のパラメータを介して指定することができる。すなわち、行２は、行１で定義されたフローパネルを呼び出す／記述するアプリケーション記述を示す。
１つのデフォルトパラメータを、ＸＡＤ内のエンティティごとに指定することができる。表５に、名前が「Ｃｈｉｌｄｒｅｎ」であるデフォルトパラメータを定義するコードの行の例を示す。パラメータ名が子タグで指定されない場合、子は、ＤｅｆａｕｌｔＰａｒａｍ属性に「ｔｒｕｅ」が設定されたパラメータに関連付けられる。
（データバインディング）
一実施形態において、ＸＡＤは、データバインディング（ＸＭＬデータの、特にそのデータ用に設計されたオブジェクトへのバインディング）を利用する。したがって、オブジェクトの名前を、データを参照するのに、より具体的にはパラメータを指定するときに、使用することができる。静的な値（定義により、アプリケーションの有効期間の間は一定のままである）と異なって、データバインドされた値を、そのデータバインドされた値の関連するデータの変更を介して更新することができる。一実施形態では、アプリケーションによって、この変更を実行することができる。別の実施形態では、ユーザまたは外部プロセスによって、この変更を実行することができる。例示的な実施形態では、行「＜Ｔｅｘｔ Ｔｅｘｔ＝“＄ＴｅｘｔＶａｌｕｅ” ＦｏｎｔＳｉｚｅ＝“２５” ／＞」が、Ｔｅｘｔパラメータに「＄ＴｅｘｔＶａｌｕｅ」の値を割り当てさせる。この実施形態では、「＄」が、予約済みの文字であり、この形でのこの文字の使用は、コンポーネントの作成中および接続中に、データバインディングを呼び出す。そのようなデータバインディングは、別のソースまたはオブジェクトからのデータの間接ポインティングまたは間接関連付けを、このエンティティタグにバインドさせる。
一実施形態において、ＸＡＤは、データバインディング（ＸＭＬデータの、特にそのデータ用に設計されたオブジェクトへのバインディング）を利用する。したがって、オブジェクトの名前を、データを参照するのに、より具体的にはパラメータを指定するときに、使用することができる。静的な値（定義により、アプリケーションの有効期間の間は一定のままである）と異なって、データバインドされた値を、そのデータバインドされた値の関連するデータの変更を介して更新することができる。一実施形態では、アプリケーションによって、この変更を実行することができる。別の実施形態では、ユーザまたは外部プロセスによって、この変更を実行することができる。例示的な実施形態では、行「＜Ｔｅｘｔ Ｔｅｘｔ＝“＄ＴｅｘｔＶａｌｕｅ” ＦｏｎｔＳｉｚｅ＝“２５” ／＞」が、Ｔｅｘｔパラメータに「＄ＴｅｘｔＶａｌｕｅ」の値を割り当てさせる。この実施形態では、「＄」が、予約済みの文字であり、この形でのこの文字の使用は、コンポーネントの作成中および接続中に、データバインディングを呼び出す。そのようなデータバインディングは、別のソースまたはオブジェクトからのデータの間接ポインティングまたは間接関連付けを、このエンティティタグにバインドさせる。
データバインディングを使用して、リテラルデータを参照することができる。すなわち、ｓｙｓ：ＩｎｌｉｎｅＤａｔａタグを使用して、リテラルデータを指定することができる。例えば、「＜ｓｙｓ：ＩｎｌｉｎｅＤａｔａ Ｎａｍｅ＝“ＴｅｘｔＶａｌｕｅ”＞Ｈｅｌｌｏ Ｗｏｒｌｄ＜／ｓｙｓ：ＩｎｌｉｎｅＤａｔａ＞」は、インラインデータ、すなわち、文字列「Ｈｅｌｌｏ Ｗｏｒｌｄ」を定義する。この例示的なリテラルデータタグには、名前ＴｅｘｔＶａｌｕｅが与えられる。その結果、ＸＡＤ記述で名前＄ＴｅｘｔＶａｌｕｅを使用することによって、ＸＡＤコードは、リテラルデータタグ内のデータにバインドすることができ、これを型ｓｙｓ：Ｄａｔａの任意のパラメータの値に使用することができる。
データバインディングを使用して、相対的なデータ位置を参照することもできる。例えば、＜Ｔｅｘｔ Ｔｅｘｔ＝“＄ＳｏｍｅＬｏｃａｔｉｏｎ／ｍｙｄ：Ｅｍｐｌｏｙｅｅｓ／ｍｙｄ：Ｅｍｐｌｏｙｅｅ／ｍｙｄ：Ｎａｍｅ” ／＞は、動的なプレフィックス、すなわち、「＄ＳｏｍｅＬｏｃａｔｉｏｎ」と、これに続くデータ参照、すなわち「＄」文字を使用しない「ｍｙｄ：Ｅｍｐｌｏｙｅｅｓ」、「ｍｙｄ：Ｅｍｐｌｏｙｅｅ」、および「ｍｙｄ：Ｎａｍｅ」を使用する。その結果は、所与の相対的な位置が追加された＄ＳｏｍｅＬｏｃａｔｉｏｎの値から形成される絶対的な位置へのデータバインディングである。
さらに、データバインディングをグループ化タグと共に使用することができる。例えば、表６のコード例（行１）は、ＭｅｒｇｅＴｒｅｅｓＴｒａｎｓｆｏｒｍエンティティをＲｅｓｏｕｒｃｅｓグループ化タグの下にあるエンティティのセットにバインドする。
表６（行２）は、ＸＡＤがデータ値へのバインディングを可能にすることを示している。例えば、次の定義は、アクションを＄ＳｃｒａｔｃｈＤａｔａの値にバインドする。この定義の下では、＄ＳｃｒａｔｃｈＤａｔａの初期値は「Ｂｙｅ」である。「ＭｏｕｓｅＬｅｆｔＢｕｔｔｏｎＤｏｗｎ」は、型「ｓｙｓ：ＥｖｅｎｔＨａｎｄｌｅｒ」のパラメータである。「ＭｏｕｓｅＬｅｆｔＢｕｔｔｏｎＤｏｗｎ」パラメータに対応するアクションは、Ｔｅｘｔエンティティが左マウスボタンダウンイベントに出会うときに必ず呼び出される。このイベントは、ＳｅｔＴｅｘｔＶａｌｕｅＡｃｔｉｏｎを呼び出させ、これによって、＜Ｇｒｅｅｔｉｎｇ＞要素のテキスト値が「Ｃａｉｏ」に変更される。同様に、右マウスボタンダウンイベントは、＄ＳｃｒａｔｃｈＤａｔａの値が「Ａｕ Ｒｅｖｏｉｒ」に変化することをもたらす。
さらに別の例では、データバインディングは、アプリケーションがコマンドラインパラメータを受け取ることを可能にする。例えば、表７のコード例は、コマンドラインパラメータの指定を可能にする。ｓｙｓ：Ｍａｉｎタグは、アプリケーションのエントリポイントである。
表７において定義されたアプリケーションは、「ｘａｄ ＣｏｍｍａｎｄＬｉｎｅ．ｘａｄ ／ＴｅｘｔＤａｔａ＝Ｔｅｓｔｉｎｇ」などのコマンドラインパラメータを受け入れる。ここで、ＣｏｍｍａｎｄＬｉｎｅ．ｘａｄはアプリケーションの名前であり、ＴｅｘｔＤａｔａはパラメータ名であり、Ｔｅｓｔｉｎｇは値である。一実施形態では、「ｘａｄ ＡｐｐｌｉｃａｔｉｏｎＮａｍｅ ／ＰａｒａｍＮａｍｅ１＝Ｖａｌｕｅ１ ／ＰａｒａｍＮａｍｅ２＝Ｖａｌｕｅ２ ．．． ／ＰａｒａｍＮａｍｅｎ＝Ｖａｌｕｅｎ」の形で、複数のパラメータをＸＡＤに渡すことができる。当業者であれば、上記の例示的な実施形態では、入力値として文字列を使用するが、コマンドラインパラメータには、その代わりに、またはそれに加えて、英数字値、ファイルの名前、画像または他のリソース位置などを含めることができることが理解されよう。また、パラメータについてコマンドラインパラメータ値が指定されない場合に使用されるデフォルト値を、コマンドラインパラメータに与えることができる。
（データソースタグ）
一実施形態において、外部データが、ＤａｔａＳｏｕｒｃｅタグによってＸＡＤアプリケーションに公開される。さらに、ＸｍｌＦｉｌｅＤａｔａＳｏｕｒｃｅタグを使用して、アプリケーションとＸＭＬファイルとの間で接続を確立することができ、その結果、アプリケーションによって、ＸＭＬファイルをデータソースとして使用できるようになる。外部データソースは、ｓｙｓ：ＩｎｌｉｎｅＤａｔａタグによって提供されるインラインデータに類似した形で使用することができる。しかし、外部データソースは、ＸＡＤアクションを使用してディスクに保存することができ、したがって、必要に応じて、アプリケーションは、他のユーザによるデータに対する変更を使用することができる。
一実施形態において、外部データが、ＤａｔａＳｏｕｒｃｅタグによってＸＡＤアプリケーションに公開される。さらに、ＸｍｌＦｉｌｅＤａｔａＳｏｕｒｃｅタグを使用して、アプリケーションとＸＭＬファイルとの間で接続を確立することができ、その結果、アプリケーションによって、ＸＭＬファイルをデータソースとして使用できるようになる。外部データソースは、ｓｙｓ：ＩｎｌｉｎｅＤａｔａタグによって提供されるインラインデータに類似した形で使用することができる。しかし、外部データソースは、ＸＡＤアクションを使用してディスクに保存することができ、したがって、必要に応じて、アプリケーションは、他のユーザによるデータに対する変更を使用することができる。
（派生タグ定義）
ＸＡＤは、抽象化および定義の再利用を利用するための派生タグ定義の使用を可能にする。例えば、一連の１２ポイントＶｅｒｄａｎａフォント見出しを必要とするアプリケーションにおいて、ユーザは、見出しが望まれる各位置に、「＜Ｔｅｘｔ ＦｏｎｔＦａｍｉｌｙ＝“Ｖｅｒｄａｎａ” ＦｏｎｔＳｉｚｅ＝“１２” Ｔｅｘｔ＝“ｈｅａｄｉｎｇ ｔｅｘｔ ｈｅｒｅ” ／＞」などの定義を配置することができる。しかし、それぞれが異なる可能性がある数百個または数千個の見出しが必要な場合には、派生タグ定義が、指定による、より高い効率を可能にする。より具体的には、派生タグ定義を定義することができ、派生タグ定義の例を、表８に示す。
ＸＡＤは、抽象化および定義の再利用を利用するための派生タグ定義の使用を可能にする。例えば、一連の１２ポイントＶｅｒｄａｎａフォント見出しを必要とするアプリケーションにおいて、ユーザは、見出しが望まれる各位置に、「＜Ｔｅｘｔ ＦｏｎｔＦａｍｉｌｙ＝“Ｖｅｒｄａｎａ” ＦｏｎｔＳｉｚｅ＝“１２” Ｔｅｘｔ＝“ｈｅａｄｉｎｇ ｔｅｘｔ ｈｅｒｅ” ／＞」などの定義を配置することができる。しかし、それぞれが異なる可能性がある数百個または数千個の見出しが必要な場合には、派生タグ定義が、指定による、より高い効率を可能にする。より具体的には、派生タグ定義を定義することができ、派生タグ定義の例を、表８に示す。
表８に示された定義は、ＸＡＤに、型ｆｗｋ：ＵＩＥｌｅｍｅｎｔのＴｉｔｌｅＴｅｘｔという名前の新しいタグを作成させる。このタグ内のＴｅｘｔパラメータは、＄Ｔｅｘｔについて渡される値にバインドされ、これは、見出しのインスタンス化ごとに異なるように渡すことができる。
別の例として、表９に示された以下の例を検討する。この例では、第１行は、ＸＡＤのスニペット例であり、第２行は、ＸＡＤのスニペットを置換する派生タグ定義例を示し、第３行は、派生タグ定義を使用するインスタンス化呼び出しを示す。
表９に示されているように、派生タグは、同一項目を複数回呼び出すか、またはインスタンス化する際の機能性および単純さを向上させることができる。
（スコープパラメータおよびニュースコープパラメータ）
スコープパラメータは、特にエンティティの遅延インスタンス化および／または繰り返されるインスタンス化のための、変化する有効期間のオブジェクトのサブグラフに関する定義された境界を提供する。ファクトリは、インスタンス化を遅延させ、後に呼び出す手段である。スコープ変数は、インスタンス化を呼び出すエンティティによって提供されるパラメータである値を提供する。スコープ変数の使用の１つの例は、マウスボタンダウンイベントなどの様々なイベントプロパティの受信を可能にすることである。
スコープパラメータは、特にエンティティの遅延インスタンス化および／または繰り返されるインスタンス化のための、変化する有効期間のオブジェクトのサブグラフに関する定義された境界を提供する。ファクトリは、インスタンス化を遅延させ、後に呼び出す手段である。スコープ変数は、インスタンス化を呼び出すエンティティによって提供されるパラメータである値を提供する。スコープ変数の使用の１つの例は、マウスボタンダウンイベントなどの様々なイベントプロパティの受信を可能にすることである。
ＸＡＤは、ニュースコープパラメータを使用して、アプリケーションコンポーネント間、オブジェクト間、および／またはその組合せの間でデータを渡す。一実施形態において、親コンポーネントがニュースコープパラメータを使用して、新たに作成される子コンポーネントにパラメータを渡すことができる。したがって、ＸＡＤは、ユーザがコード再利用を活用することを可能にする。一実施形態において、各リストエントリ内のデータへの参照を含むリストエンティティが構築される。単一のリストエンティティについて何を行うべきかを定義する同一のパラメータが、新しい各リストエンティティに適用され、単一のパラメータまたはパラメータのセットを使用して、任意に大きいエントリリストを作成することが可能になる。さらに、親オブジェクトと子オブジェクトとの間におけるパラメータの受け渡しを、同様に最適化することができる。例えば、親オブジェクトは、ニュースコープパラメータを介して、リストインデックスを子オブジェクトに渡すことができ、このリストインデックスは、子に渡されたリスト要素に対応する。
ニュースコープを導入するパラメータは、「ＮｅｗＳｃｏｐｅ」属性にｔｒｕｅが設定される。例えば、行「＜ｓｙｓ：Ｐａｒａｍ Ｎａｍｅ＝“．．．” ＮｅｗＳｃｏｐｅ＝“ｔｒｕｅ” ．．．／＞」は通常、新しい属性にｔｒｕｅを設定するのに使用される。ニュースコープパラメータは、スコープ内の１つまたは複数の変数を導入するのに使用することができる。変数は、暗黙的に宣言されるパラメータである。変数は、表１０（行１）において提供される例で見ることができるように、ニュースコープパラメータの宣言と共に宣言される。上述したように、ニュースコープは、複数回インスタンス化されなければならないすべてのエンティティについて導入される。表１０（行２）に、そのようなファクトリの定義を示す。
上記の例（表１０、行２）では、ＲｅｐｅａｔｅｄＣｈｉｌｄパラメータによって導入されるスコープが、ＤａｔａＣｏｎｔｅｘｔという名前のスコープ変数を有する。この変数には、インスタンス化されるサブビューに対応する項目が設定される。上記の定義は、Ｌｉｓｔ．ｘｍｌが表１１（行２）に示されたＸＭＬを含むものと仮定して、表１１（行１）に示されるように適用される。
表１１に示された例では、リスト項目ごとに、ＦｌｏｗＰａｎｅｌエンティティが、対応するＴｅｘｔエンティティを作成する。結果として生じるＦｌｏｗｐａｎｅｌエンティティは、ＥｍｐｌｏｙｅｅＡ〜Ｈのリストをモニタに表示する。当業者であれば、各行が１つのＴｅｘｔエンティティのインスタンス化に対応することが理解されよう。あるインスタンス化と次のインスタンス化との間で変化するものは、「ＤａｔａＣｏｎｔｅｘｔ」スコープ変数の値である。結果として生じるパターンは、リピータパターンと呼ばれる。これは、ＸＡＤにおけるデータセットに対する反復の基礎である。一実施形態では、多次元反復のために、リピータパターンをネストすることができる。
（アタッチドパラメータ）
アタッチドパラメータ（attached parameter）は、親オブジェクトによって子に関連付けられるパラメータであって、子が処理する方法を知らない可能性があるパラメータである。例えば、親「ｄｒａｗｉｎｇ」オブジェクトの子である「ｔｒｉａｎｇｌｅ」オブジェクトは、「位置」座標をどのように扱うべきかを具体的に知らない場合がある。というのは、位置座標は、図面内の全般的な位置に関連するもので、三角形などの形状に具体的には関連しないからである。アタッチドパラメータは、親オブジェクトが、子オブジェクトに関連付けられたデータおよび／または機能にアクセスすることを可能にする。ＸＡＤは、親オブジェクトにおけるこのパラメータの定義に基づいて、正しい使用法についてアタッチドパラメータをチェックする。表１２（行１）に、例示的なタグ定義を示す。
アタッチドパラメータ（attached parameter）は、親オブジェクトによって子に関連付けられるパラメータであって、子が処理する方法を知らない可能性があるパラメータである。例えば、親「ｄｒａｗｉｎｇ」オブジェクトの子である「ｔｒｉａｎｇｌｅ」オブジェクトは、「位置」座標をどのように扱うべきかを具体的に知らない場合がある。というのは、位置座標は、図面内の全般的な位置に関連するもので、三角形などの形状に具体的には関連しないからである。アタッチドパラメータは、親オブジェクトが、子オブジェクトに関連付けられたデータおよび／または機能にアクセスすることを可能にする。ＸＡＤは、親オブジェクトにおけるこのパラメータの定義に基づいて、正しい使用法についてアタッチドパラメータをチェックする。表１２（行１）に、例示的なタグ定義を示す。
表１２（行１）のＸＡＤコード定義は、ＤｏｃｋＰａｎｅｌと呼ばれるエンティティを定義し、このＤｏｃｋＰａｎｅｌは、「ＤｏｃｋＰａｎｅｌ．Ｄｏｃｋ」として参照できる、「Ｄｏｃｋ」と呼ばれるアタッチドパラメータを含む。表１２（行２）に、ＤｏｃｋＰａｎｅｌエンティティを使用する例示的なＸＡＤコードを示す。
表１２に示されているように、ＤｏｃｋＰａｎｅｌ．Ｄｏｃｋは、必ずしもＴｅｘｔエンティティのタグ定義で指定されるパラメータのうちの１つではないが、ＤｏｃｋＰａｎｅｌ．Ｄｏｃｋは、Ｔｅｘｔエンティティの各々に対する属性として指定される。ＤｏｃｋＰａｎｅｌ．Ｄｏｃｋは、アタッチドパラメータであるので、Ｔｅｘｔエンティティと共に使用されるが、実際には、表１２（行１）に示されたＤｏｃｋＰａｎｅｌエンティティの宣言において定義される。
（リソースパラメータ）
別のタイプのパラメータは、リソースパラメータである。リソースパラメータは、オブジェクト階層内に論理位置を有さないオブジェクトを記憶する場所を提供する。リソースパラメータは、所与のエンティティの下で、任意のエンティティのセットをアンカリングするのに使用することができる。リソースパラメータに関連付けられたアクションおよび状態は、アプリケーション全体を通じて使用することができる。例示的なリソースパラメータの定義を、表１３に示す。
別のタイプのパラメータは、リソースパラメータである。リソースパラメータは、オブジェクト階層内に論理位置を有さないオブジェクトを記憶する場所を提供する。リソースパラメータは、所与のエンティティの下で、任意のエンティティのセットをアンカリングするのに使用することができる。リソースパラメータに関連付けられたアクションおよび状態は、アプリケーション全体を通じて使用することができる。例示的なリソースパラメータの定義を、表１３に示す。
上述したように、ＸＡＤのデータバインディング機能を介して、ＵＩ要素を、状態および／またはアクションにバインドすることができる。
（構造体）
ＸＡＤでは、「構造体」は、１つの名前として渡すことができるエンティティのグループである。ＸＡＤの構造体はネストすることもできる。構造体およびネストされた構造体の例を、表１４に示す。
ＸＡＤでは、「構造体」は、１つの名前として渡すことができるエンティティのグループである。ＸＡＤの構造体はネストすることもできる。構造体およびネストされた構造体の例を、表１４に示す。
この例では、＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．Ａｃｔｉｏｎｓ．Ｐｒｉｎｔバインディングおよび＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．Ａｃｔｉｏｎｓ．Ｓａｖｅバインディングは、型ｓｙｓ：ＥｖｅｎｔＨａｎｄｌｅｒのすべてのパラメータについて有効である。同様に、＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．ＲｅｃｅｎｔＤｏｃｕｍｅｎｔｓ、＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．Ｐｒｅｆｅｒｅｎｃｅｓ．Ｕｓｅｒ、および＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．Ｐｒｅｆｅｒｅｎｃｅｓ．Ｅｎｔｅｒｐｒｉｓｅは、型ｓｙｓ：Ｄａｔａのすべてのパラメータについて有効である。＄ＡｃｔｉｏｎｓＡｎｄＤａｔａは、Ｓｉｇｎａｔｕｒｅ ａｐｐ：ＡｃｔｉｏｎｓＡｎｄＤａｔａＳｉｇｎａｔｕｒｅのすべてのパラメータについて有効である。＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．Ａｃｔｉｏｎｓは、Ｓｉｇｎａｔｕｒｅ ａｐｐ：ＡｃｔｉｏｎｓＳｉｇｎａｔｕｒｅのすべてのパラメータについて有効である。最後に、＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．Ｐｒｅｆｅｒｅｎｃｅｓは、Ｓｉｇｎａｔｕｒｅ ａｐｐ：ＰｒｅｆｅｒｅｎｃｅｓＳｉｇｎａｔｕｒｅｓのすべてのパラメータについて有効である。
（マニフェスト）
一実施形態において、ＸＡＤは、「Ｍａｎｉｆｅｓｔ」を使用して、アプリケーション記述など、アプリケーションの諸部分を一緒にまとめる。マニフェストは、アプリケーションの諸態様、例えば、どのファイルがアプリケーションによって必要とされるか、どの依存関係がオブジェクト間に存在するか、およびどのユーザ環境固有データがアプリケーションの一部であるか（アプリケーションが操作するデータではなく、ユーザのネイティブ言語でのユーザインターフェース要素テキスト、アイコンなど）を記述する、コンピュータによって処理できる仕様である。
一実施形態において、ＸＡＤは、「Ｍａｎｉｆｅｓｔ」を使用して、アプリケーション記述など、アプリケーションの諸部分を一緒にまとめる。マニフェストは、アプリケーションの諸態様、例えば、どのファイルがアプリケーションによって必要とされるか、どの依存関係がオブジェクト間に存在するか、およびどのユーザ環境固有データがアプリケーションの一部であるか（アプリケーションが操作するデータではなく、ユーザのネイティブ言語でのユーザインターフェース要素テキスト、アイコンなど）を記述する、コンピュータによって処理できる仕様である。
（ビルトインタグ）
ビルトインタグ（built-in tag）とは、予め定義され、重要な機能をＸＡＤ開発者に提供するタグである。通常、ビルトインタグには、「ｓｙｓ：」プレフィックスが付けられる。例えば、これらのビルトインタグは、条件付き動作、繰り返し動作、およびオブジェクトの作成を可能にする。そのようなタイプのビルトインタグの１つは、「ダイナミックエンティティ」タグと呼ばれ、このタグは、データ記述内で、使用されるオブジェクトの型を変更するのに使用することができる。これは、スクリーンにおけるオブジェクトの構成のリアルタイム変更を可能にする。例えば、ユーザが所与のユーザインターフェース要素を選択することに応答して、要素の機能および／または目的をリアルタイムで変更することができる。例えば、ある出力ウィンドウは、「次のアプリケーションビューへのサイクル」というユーザコマンドの受信に基づいて任意に多数の異なるアプリケーションビューからの出力を表示するのに使用することができる。一実施形態において、ダイナミックエンティティタグは、次の表１５に示されているように、タグ名による動的なエンティティのインスタンス化を提供する。
ビルトインタグ（built-in tag）とは、予め定義され、重要な機能をＸＡＤ開発者に提供するタグである。通常、ビルトインタグには、「ｓｙｓ：」プレフィックスが付けられる。例えば、これらのビルトインタグは、条件付き動作、繰り返し動作、およびオブジェクトの作成を可能にする。そのようなタイプのビルトインタグの１つは、「ダイナミックエンティティ」タグと呼ばれ、このタグは、データ記述内で、使用されるオブジェクトの型を変更するのに使用することができる。これは、スクリーンにおけるオブジェクトの構成のリアルタイム変更を可能にする。例えば、ユーザが所与のユーザインターフェース要素を選択することに応答して、要素の機能および／または目的をリアルタイムで変更することができる。例えば、ある出力ウィンドウは、「次のアプリケーションビューへのサイクル」というユーザコマンドの受信に基づいて任意に多数の異なるアプリケーションビューからの出力を表示するのに使用することができる。一実施形態において、ダイナミックエンティティタグは、次の表１５に示されているように、タグ名による動的なエンティティのインスタンス化を提供する。
表１５に示された例では、ビルトインエンティティ「Ｄｙｎａｍｉｃ Ｅｎｔｉｔｙ」が、エンティティを動的に定義する能力を開発者に提供する。このケースでは、＄ＤａｔｅＴａｇがローカル名を解決する。
「スイッチエンティティ」タグと呼ばれる別のタイプのビルトインタグは、オブジェクトまたは複数の関連するオブジェクトの条件付き構築によって、アプリケーションを動的に再構成することを可能にする。ＸＡＤは、宣言言語ではあるが、エンティティの条件付き構築を可能にするのに十分な表現力がある。単一の構造すなわちＳｗｉｔｃｈが、条件付き構築を可能にするために提供される。スイッチエンティティタグは、「ｃａｓｅｓ」タグまたは「ｃｏｎｄｉｔｉｏｎｓ」タグによってパラメータ化することができる。Ｃａｓｅは、Ｃ＃のｓｗｉｔｃｈに類似するものと考えることができ、Ｃｏｎｄｉｔｉｏｎｓは、Ｃ＃のｉｆ−ｅｌｓｅ節のセットに類似する。一実施形態では、ＣａｓｅｓおよびＣｏｎｄｉｔｉｏｎｓの使用が、相互に排他的であり、これは、Ｓｗｉｔｃｈが、その本体内でＣａｓｅｓおよびＣｏｎｄｉｔｉｏｎｓを混合できないことを意味する。さらに、この実施形態では、Ｃａｓｅｓは、ＳｗｉｔｃｈがそのＤａｔａパラメータの値を指定する場合に限り使用することができ、そうでない場合にはＣｏｎｄｉｔｉｏｎｓを使用しなければならない。
Ｓｗｉｔｃｈを使用することによって、作成者は、スイッチを評価した結果として、１つまたは多数のエンティティを条件付きで返せるようになる。表１６に、いくつかのＸＡＤデータ例（行１）と、条件付きスイッチの使用例（行２および３）とを示す。
表１６の行２は、５０．００ドルを超える値に基づいてエンティティを作成する、一実施形態での構文を示すことが理解されよう。表１６の行３は、この例を進めて、他の条件付きテストについてテキストブロックエンティティを示している。結果として生じるビューは、行１のすべての要素項目、すなわち、「Ｔｏａｓｔｅｒ」、「ＶＣＲ」、「ＤＶＤ Ｐｌａｙｅｒ」、「Ｒｅｃｅｉｖｅｒ」、および「Ｓｕｂ−ｗｏｏｆｅｒ」を表示する。しかし、「Ｔｏａｓｔｅｒ」は、Ｇｅｏｒｇｉａ太字フォントであり、緑色であるが、「Ｒｅｃｅｉｖｅｒ」は、Ａｒｉａｌ太字フォントであり、赤色である。
スイッチは、依存関係追跡および再検証と共に、動的な再構成の自動実施を可能にする。動的な再構成については、以下でより詳細に説明する。
（フレームワークタグ）
ＸＡＤおよびＸＡＦは、フレームワークタグ（「ｆｗｋ」と省略する）と呼ばれる別のタイプのタグを可能にする。フレームワークタグは、アプリケーションの一部であるオブジェクトを作成するのに使用することができる。フレームワークタグは、アクション、データソース、変換、および関連付けマネージャ（それぞれについて以下で説明する）を参照するのに使用することができる。一実施形態では、アプリケーションデバッギングも、フレームワークタグを介して実行することができる。
ＸＡＤおよびＸＡＦは、フレームワークタグ（「ｆｗｋ」と省略する）と呼ばれる別のタイプのタグを可能にする。フレームワークタグは、アプリケーションの一部であるオブジェクトを作成するのに使用することができる。フレームワークタグは、アクション、データソース、変換、および関連付けマネージャ（それぞれについて以下で説明する）を参照するのに使用することができる。一実施形態では、アプリケーションデバッギングも、フレームワークタグを介して実行することができる。
最も単純なレベルで、ＵＩコネクタは、ＸＡＦデータを可視化し、かつそのデータを変更するイベントに応答する能力を提供する。任意の１つの特定のＵＩコネクタは、実際には、「要素ツリー」、すなわち、表示でき、かつそのＵＩコネクタが提示しているビジュアル要素のセットを有する。各ＵＩコネクタには、データをビジュアル要素に変換するコードと、イベントを編集動作に変換するコードとが関連付けられる。
一実施形態において、ＵＩコネクタは、Ｗｉｎｄｏｗｓ（登録商標） Ｐｒｅｓｅｎｔａｔｉｏｎ Ｆｏｕｎｄａｔｉｏｎ（ＷＰＦ）要素などのクライアントプラットフォームのプロパティおよびイベントを単純に公開する。さらに、ＵＩコネクタは、ＸＡＦデータレイヤからのデータをＷＰＦ要素にバインドする特定の形のデータバインディングを提供する。様々な要素が、様々な型のデータを可視化するために設計される。例えば、Ｉｍａｇｅ要素は、ビットマップ表示データを可視化し、Ｔｅｘｔ要素は、文字列データを可視化し、ＬｉｓｔＢｏｘは、おそらくは異種であるデータの順序付きリストを可視化する。ＬｉｓｔＢｏｘおよびＴｅｘｔＢｏｘなど、いくつかの要素は、データに対する「選択」も可視化することができる。選択という概念は、基本的に、別のデータ入力である。
一般に、特定のＵＩコネクタは、可視化される特定の型のデータを処理するように設計される。２つの要素が、それらが可視化するものに関する入力（またはパラメータ）を受け入れるのに正確に同一の機構を使用する場合、開発者は、その両方を処理するために単一のＵＩコネクタを記述することができる。パラメータは、ＵＩコネクタにファクトリオブジェクトを提供するのに使用され、このファクトリオブジェクトは、必要に応じて子を作成するのに使用される。ＵＩコネクタは通常、データコンテキストをファクトリに提供する。ファクトリは通常、ＸＡＤエンジンによってオブジェクト内にラップされる、ＸＡＤのフラグメントである。表１７に、提供され得るＵＩコネクタのセットを示す。
フレームワークタグの１つのタイプである関連付けマネージャは、オブジェクトをデータ構造体またはデータ構造体の要素に関連付けるのに使用することができる。例えば、リスト関連付けマネージャを使用して、オブジェクトをリスト内の項目に関連付けることができる。結果として生じるリスト項目は、静的な値ではなく、オブジェクトへの参照と、それに関連するデータとを含むという点で、動的である。
（動作時）
図２８に、オブジェクトが使用のために作成されセットアップされる、本発明の一実施形態によるビルダによって実行される動作の動作フローを示す。インスタンス化プロセス２８００は、作成動作２８０２から始まり、初期化動作２８０６で終わる動作フローを使用して実行される。一般に、フロー２８００は、単一の構成サービスによって、または複数のサービスによって実行することができる。
図２８に、オブジェクトが使用のために作成されセットアップされる、本発明の一実施形態によるビルダによって実行される動作の動作フローを示す。インスタンス化プロセス２８００は、作成動作２８０２から始まり、初期化動作２８０６で終わる動作フローを使用して実行される。一般に、フロー２８００は、単一の構成サービスによって、または複数のサービスによって実行することができる。
作成動作２８０２において、オブジェクトを作成する。一実施形態では、作成動作２８０２において、オブジェクトに必要なデータ構造体を作成する。別の実施形態では、作成動作２８０２において、データ構造体に必要なメモリも割り当てる。
作成動作２８０２においてオブジェクトを作成すると、接続動作２８０４において、他のオブジェクトに対するそのオブジェクトの関係性に従って、そのオブジェクトを他のオブジェクトに接続する。一実施形態では、作成されたオブジェクトと、１つまたは複数の先在するオブジェクトとの間の接続のグラフを構築する。作成−接続−初期化シーケンスは、ＸＡＤエンジンが、オブジェクトのグループ間のサイクル接続（cyclic connection）をサポートすることを可能にする。データおよび変換の場合に、そのようなサイクルは禁止され、ＸＡＤコンパイラは、そのようなサイクルを防ぐために、何らかのチェックを実行する。
接続動作２８０４において作成された接続グラフは、オブジェクト間の相互接続および相互関係を定義する。一実施形態において、これらの接続は、動的な再構成（以下で説明する）によって変更されるまで、またはオブジェクトが消去されるまで、そのままの状態にある。どの接続が必要であるかは、エンジンによって、そのエンジンがアプリケーションマークアップコードを実行するときに判定される。一実施形態では、接続動作２８０４において、データプロバイダオブジェクトをアプリケーションに接続する。
初期化動作２８０６において、作成されたオブジェクトを初期化する。一実施形態において、初期化は、１つまたは複数の非決定値に、０または他の予め定義された値を設定することを含む。別の実施形態では、初期化動作２８０６において、オブジェクトに関連付けられたコンストラクタを呼び出す。さらに別の実施形態では、初期化動作２８０６において、作成されたオブジェクトに、それ自体を初期化するよう指示する。当業者であれば、本発明の範囲から逸脱することなく、初期化動作２８０６において、通常はオブジェクト初期化に関連する他の動作を実行することもできることが理解されよう。一実施形態において、初期化動作２８０６は、所与のオブジェクトが初期化されなければならないデータを含むかどうかに基づいて、条件付きで行われる。一実施形態では、条件に応じて様々な値を用いて、オブジェクトを初期化することができる。例えば、表１８に示された次の定義は、ＸＡＤに、５００ドルを超える価格が設定されている場合には赤でリスト内の項目を表示させ、１００ドル未満の価格が設定されている場合には緑で項目を表示させる。
一実施形態において、エンジンは、ジャストインタイムコンパイルを使用して、動作２８０２、２８０４、および２８０６を実行する。別の実施形態では、アプリケーションは、予めコンパイルされている。さらに別の実施形態では、事前コンパイルおよびジャストインタイムコンパイルの組合せを使用して、性能と柔軟性とのバランスを実現する。
ＸＡＤは、アプリケーションを動的に再構成することを可能にする。動的な再構成は、アプリケーションに流れ込むデータの変化によって、またはアプリケーションを用いる既存のデータの変更によって、トリガすることができる。図２９に、ＸＡＤの一実施形態において、アプリケーションをどのように動的に再構成できるかを示す。
リスナ（listener）は、ある種のイベントについてアプリケーションまたはアプリケーションのグループを監視するコンピュータエージェントである。ＸＡＤリスナは、値の変化についてＸＡＤアプリケーション内のある種の登録されたオブジェクトのデータを監視する。登録動作２９０２において、オブジェクトおよびそのデータをそのようなリスナに登録する。
登録されたオブジェクト内でデータ値の変化が発生するときに、受信動作２９０４において、変更通知がリスナから受信される。次に、マーク動作２９０６において、変化した値に依拠する１つまたは複数のデータ値を識別し、その変化によって影響が及ぼされるものとして、これらをマークする。分析動作２９０８において、マークされたデータ値の各々に対する変化した値の影響を分析する。この分析の結果に基づいて、判定動作２９１０において、変化した値によってオブジェクトが無効にされたかどうかを判定する。
１つまたは複数のオブジェクトが、変化によって無効にされた場合、フローは、ＹＥＳから除去動作２９１２に分岐し、除去動作２９１２において、１つまたは複数の現在は無効なオブジェクトを除去する。次いで、フローは、判定動作２９１４に分岐する。判定動作２９１０において、どのオブジェクトも変化によって無効にされなかったと判定された場合、フローは、ＮＯから判定動作２９１４に分岐する。
判定動作２９１４において、変化した値の結果として、新しいオブジェクトが必要であるかどうかを判定する。１つまたは複数の新しいオブジェクトが必要である場合、フローは、ＹＥＳから作成動作２８０２（図２８）に分岐し、図２８を参照して上述したように、オブジェクトの作成、接続、および初期化が進行する。判定動作２９１４において、新しいオブジェクトが必要ではないと判定された場合、フローは、ＮＯからこの例示的なフローの終わりに分岐する。
新しいオブジェクトの作成および無効なオブジェクトの削除を単純にするために、ＸＡＤは、オブジェクトの有効期間を管理することができる。有効期間ドメインは、ＸＡＤアプリケーション内の再構成のユニットである。有効期間が互いに結び付けられているオブジェクト（例えば、第１のオブジェクトは、第２のオブジェクトが存在しなければ意味がない場合があり、第２のオブジェクトは、第１のオブジェクトが存在しなければ意味がない場合がある）は、同一の有効期間ドメインに配置される。所与の有効期間ドメインに多数のオブジェクトを配置することができる。オブジェクトがもはや必要なくなったときには、（おそらくは、削除のために有効期間ドメイン内の何千個もの別々のオブジェクトを参照するのではなく、）削除のために有効期間ドメインを参照することによって、有効期間ドメイン内のすべてのオブジェクトを簡単に削除することができる。当業者であれば、所与の有効期間ドメイン内のオブジェクトは、機能的に関連する必要はなく、同時に削除できるように、作成時刻および共通の依存関係を共有することだけが必要であることが理解されよう。
一実施形態において、ＸＡＤは、アプリケーションの動的な再構成と共に、条件付きで作成されるオブジェクトを利用することができる。したがって、データ値変化の特性に応じて、様々な型のオブジェクトを作成することができる。図３０に、本発明の一実施形態による、作成動作２８０２（図２８）によって実行される動作の動作フローを示す。まず、判定動作３００２において、インスタンス化すべきタグがあるかどうかを判定する。インスタンス化すべきタグがある場合、フローは、ＹＥＳから判定動作３００４に分岐する。インスタンス化すべきタグがない場合、またはすべてのタグが既にインスタンス化されている場合、フローは、ＮＯから接続動作２８０４（図２８）に分岐する。
判定動作３００４において、インスタンス化する必要があるパラメータがタグに含まれるかどうかを判定する。パラメータタグが存在しない場合、フローは、ＮＯから動作３００８に分岐する。パラメータタグが存在する場合、フローは、ＹＥＳからインスタンス化動作３００６に分岐する。
インスタンス化動作３００６において、判定動作３００４において見つけられたパラメータをインスタンス化する。上述したように、パラメータは、ファクトリまたはオブジェクトをどのように作成し、接続し、または構成するかを記述するのに使用される。前述したように、パラメータには、ファクトリもしくはオブジェクトの１つまたは複数のプロパティ、データへの参照、あるいは別のファクトリもしくはオブジェクトへの参照を含めることができる。プロパティは、静的なものであっても、動的なものであってもよい。
処理動作３０１０において、データ型に従ってタグを処理する。複数の異なる種類のタグが存在し、したがって、複数の可能な手法が、処理動作３０１０において実装される。プリミティブタグ（オブジェクトに実際に対応するタグ）は、新しいオブジェクトを作成することによって処理される。一実施形態では、作成されるすべてのオブジェクトが、エンティティに対応する。
一部のタグは、スコープ境界を定義する。そのようなタグは、処理動作３０１０に「ファクトリ」を作成させ、このファクトリは、エンティティのオンデマンドインスタンス化のために、後で呼び出すことができる。ファクトリが処理されるときには、新しいスコープドメインが作成される。依存関係情報のために、エンティティによって、ファクトリをチェックすることができる。これは、動的な再構成中に有用である可能性がある。
処理動作３０１０は、スイッチファクトリを作成することによって、スイッチタグを処理する。これは、様々なユーザ指定条件に基づくアプリケーション制御の分岐をサポートするファクトリである。このファクトリは、様々な条件を監視するのに使用することができ、それらの条件が満たされたときに、アプリケーションフロー内の分岐がトリガされる。一実施形態では、ジャストインタイムコンパイルを使用して、動的な再構成の一部としてタグが再処理されることによって必要になったときに、オブジェクトを変更する。
処理動作３０１０では、他のタイプのタグを処理することもできる。例えば、バインディングタグは、処理動作３０１０をトリガして、ある種のパラメータ値が実際には何らかの他のエンティティへの参照であることを示すために、ファクトリを作成する。これは、おおむね、手続き型言語のポインタに類似している。ダイナミックエンティティタグは、作成されるエンティティを遅れてバインドすることを可能にする。一実施形態において、遅れてバインドすることは、アプリケーションのランタイムまで遅延される。
処理動作３０１０においてタグを処理した後に、フローは、判定動作３００２に戻る。
一実施形態では、アドインを、ＸＡＤアプリケーションに追加することができる。アドインは、アプリケーションのアップグレードを必要とせずに、所与のアプリケーションの基本機能セットを拡張できる、内蔵型の（self-contained）ソフトウェアパッケージである。アドインは、ユーザが高価と考えられるアップグレードサイクルを全部行うことを必要とせずに、新しい機能またはサードパーティの拡張機能が使用可能になったときに、これらの機能を増分的に追加することを可能にする。
ＸＡＤアドインは、アセンブリとしてパッケージ化される。一実施形態において、アセンブリは、（上述した）マニフェストにおいて指定される静的な依存関係を介してロードされる。一実施形態において、ＸＡＤアプリケーションは、拡張性プロトコル（extensibility protocol）を介してアドインと通信する。拡張性プロトコルは、別々のアセンブリ内で定義することができ、その結果、このプロトコルは、公開することができ、アプリケーションと、拡張機能を開発するサードパーティとの両方によって参照できるようになる。
拡張性プロトコルは、２つの部分を有する。第１の部分は、メタデータスキーマである。メタデータとは、データを記述するデータである。ＸＡＤのコンテキストでは、メタデータを使用して、アドインによって実装される機能を記述することができる。メタデータには、タグ名、渡されるパラメータ、ＵＩで人間が読み取り可能なテキストなどを含めることができる。拡張可能アプリケーションは、メタデータスキーマ（アドインに何を期待するか）を定義し、アドインは、そのコンテンツを提供する。拡張性プロトコルの第２の部分は、（上述した）タグシグネチャである。アドインは、タグを定義することによってその機能を実装する。アプリケーションは、これらのタグを使用して、アドイン機能にアクセスする。アプリケーションは、タグシグネチャ（タグがどのタイプのエンティティをもたらさなければならないか、タグがどのパラメータをとらなければならないか、など）を定義し、アドインは、タグ定義（タグ名および実際の実装）を提供する。したがって、タグシグネチャは、おおむね、インターフェースに類似するものであり、タグ定義は、おおむね、インターフェース実装に類似するものである。
一実施形態において、ＸＡＤは、Ｍｅｔａｄａｔａタグを介してアクセス可能なグローバルメタデータツリーをサポートする。メタデータツリーは、すべての動的にロードされるアセンブリからのすべてのメタデータ構成要素ファイルの結合である。メタデータツリーは、メタデータ構成要素ファイルを伴うアセンブリがロードされるか、またはアンロードされるときに、ランタイムに、必ず自動的に更新される。正しい変更通知が送信されるので、（図２９を参照して前述したように、）アプリケーションは、それ自体を動的に更新することができる。メタデータツリーは、アプリケーションが、どのアドインがロードされているかを発見し、アドインが提供する機能を利用することを可能にする。
一実施形態において、アドインは、そのアドインが実装する機能にアクセスするためのタグを定義する。アドインは、アプリケーションが記述されるときには使用可能でない場合があるので、アプリケーション作成者がアドインによって定義されたタグを認識して使用することが可能でない場合がある。作成者は、タグシグネチャを認識することだけができ、したがって、タグシグネチャを静的に定義することだけができる。実際のタグ名および最終的なパラメータ値は、アドインによって、メタデータを使用して提供することができる。メタデータ方式は、アプリケーション定義の拡張性プロトコルの一部であるので、メタデータ方式情報は、アプリケーションからアクセス可能である。したがって、アプリケーションは、メタデータを読み取ることができ、タグ名によってエンティティを動的にインスタンス化することができる。ＸＡＤは、この目的のためにＤｙｎａｍｉｃＥｎｔｉｔｙタグをサポートする。
本発明について、構造的特徴、方法論的動作、およびそのような動作を含むコンピュータ読み取り可能な媒体に固有の言葉で説明したが、特許請求の範囲で定義される本発明は、説明した特定の構造、動作、または媒体に必ずしも限定されないことを理解されたい。当業者であれば、本発明の趣旨および範囲に含まれる他の実施形態および改善が認識されよう。したがって、特定の構造、動作、または媒体は、特許請求される発明を実施する例示的な実施形態として開示されたものである。本発明は、特許請求の範囲によって定義されるものである。
付録Ａ
目次
概要 エラー！ブックマーク未定義
目次
１． 序論
１．１ ＸＡＦの原理
１．２ ＸＡＤの目標
１．３ ＸＡＦアプリケーションの構造およびＸＡＤの役割
１．４ 仕様書の構成
１．５ 仕様の規約
２． 言語の概念
２．１ Ｈｅｌｌｏ Ｗｏｒｌｄの例
２．２ 大文字小文字の区別
２．３ エンティティタグ
２．４ エンティティの基本的なパラメータ化
２．４．１ 静的文字列を用いるパラメータ化
２．４．２ 単一のエンティティを用いるパラメータ化
２．４．３ エンティティのセットを用いるパラメータ化
２．４．４ Ｒｅｓｏｕｒｃｅｓ
２．４．５ デフォルトパラメータ
２．４．６ アタッチドパラメータ
２．４．７ インラインデータ
２．５ バインディングを介するパラメータ化
２．５．１ タグの命名
２．５．２ エンティティへのバインディング
２．５．３ グループ化タグへのバインディング
２．５．４ タグ定義の仮パラメータへのバインディング
２．５．５ 編集を可能にするためのバインディングの使用
２．６ Ｍａｉｎタグ
２．６．１ 自動投入されるＰａｒａｍ値
２．６．２ コマンドラインパラメータ化
２．７ 無視されるブロック
２．８ アウトパラメータ
２．９ ホワイトスペース
２．１０ 構造体
２．１０．１ 単一レベルの構造体
２．１０．２ ネストされた構造体
２．１１ スタイル
２．１１．１ デフォルト指定のためのスタイル
２．１１．２ Ａｖａｌｏｎのビジュアルツリーのスタイル指定
２．１１．３ スタイル指定およびビジュアルトリガ
２．１２ スコープ付きパラメータ
２．１２．１ スコープ変数
２．１２．２ リピータパターン
２．１２．３ スコープに関連するバインディングの制限
２．１２．４ ネストされたリピータパターン
２．１３ パラメータ継承
２．１３．１ 制限
２．１４ 条件付きパラメータ化
２．１４．１ Ｃａｓｅｓ
２．１４．２ Ｃｏｎｄｉｔｉｏｎｓ
２．１４．３ ＳｗｉｔｃｈＥｎｔｉｔｙ
２．１４．４ ＳｗｉｔｃｈＥｎｔｉｔｉｅｓ
２．１４．５ 全般
２．１４．６ セレクタおよびタグ定義
２．１５ 関連付け
２．１６ タグドキュメンテーション
３． 形式的言語仕様
３．１ ブール属性
３．２ 修飾名
３．３ キーワード
３．３．１ ＜Ｘａｄ＞
３．３．２ ＜Ｄｏｃ＞
３．３．３ ＜Ｄｅｓｃｒｉｐｔｉｏｎ＞
３．３．４ ＜Ｔｙｐｅ＞
３．３．５ ＜ＴａｇＤｅｆｉｎｉｔｉｏｎ＞
３．３．６ ＜Ｓｉｇｎａｔｕｒｅ＞
３．３．７ ＜ＰａｒａｍＧｒｏｕｐ＞（＜Ｘａｄ＞の下の）
３．３．８ ＜Ｃｏｎｓｔ＞
３．３．９ ＜Ｐａｒａｍ＞
３．３．１０ ＜ＯｕｔＰａｒａｍ＞
３．３．１１ ＜ＰａｒａｍＧｒｏｕｐ＞（＜Ｃｈｏｉｃｅ＞の下の）
３．３．１２ ＜ＰａｒａｍＧｒｏｕｐＲｅｆ＞
３．３．１３ ＜Ｃｈｏｉｃｅ＞
３．３．１４ ＜ＰａｒａｍＤｅｆａｕｌｔＶａｌｕｅ＞
３．３．１５ ＜ＣｏｎｓｔＤｅｆａｕｌｔＶａｌｕｅ＞
３．３．１６ ＜Ｅｎｔｉｔｙ＞
３．３．１７ ＜Ｆｕｎｃｔｉｏｎ＞
３．３．１８ ＜Ｂｏｄｙ＞
３．３．１９ ＜ＳｃｏｐｅＶａｒｉａｂｌｅ＞
３．３．２０ ＜ＡｔｔａｃｈｅｄＰａｒａｍ＞
３．４ ビルトインエンティティ
３．４．１ ＜ＩｎｌｉｎｅＤａｔａ＞
３．４．２ ＜Ｂｉｎｄｉｎｇ＞
３．４．３ ＜ＸＰａｔｈ＞
３．４．４ ＜Ｍａｐｐｉｎｇ＞
３．４．５ ＜ＤｙｎａｍｉｃＥｎｔｉｔｙ＞
３．４．６ ＜ＡｓｓｏｃｉａｔｅｄＥｎｔｉｔｙ＞
３．４．７ ＜ＡｓｓｏｃｉａｔｅｄＤａｔａＥｎｔｉｔｉｅｓ＞
３．４．８ ＜ＳｗｉｔｃｈＥｎｔｉｔｙ＞
３．４．９ ＜ＳｗｉｔｃｈＥｎｔｉｔｉｅｓ＞
３．４．１０ ＜Ｃａｓｅ＞
３．４．１１ ＜Ｃｏｎｄｉｔｉｏｎ＞
３．５ エンティティビルダ
３．６ アクション
４． 共通のフレームワークエンティティ
５． デプロイメントモデル
５．１ ＸＡＤアプリケーション
５．２ ＸＡＤアセンブリ
５．３ アセンブリマニフェスト
５．３．１ マニフェストタグ
５．３．７ マニフェストの例
５．４ アセンブリの依存関係
５．５ アセンブリのバインディング、ロードおよびアンロード
５．６ パッケージングのシナリオ
５．６．１ １ファイルアプリケーション
５．６．２ 派生タグのライブラリ
５．６．３ プリミティブタグのライブラリ
６． アドインモデル
６．１ アドインモデルとは何か？
６．２ ＸＡＤアドインモデル
６．２．１ アセンブリの動的ロード
６．２．３ メタデータ駆動型の拡張性プロトコル
６．２．４ 動的なエンティティのインスタンス化
６．３ アドインのシナリオ
６．３．１ ＦｉｌｅＥｘｔｅｎｓｉｏｎＰｒｏｔｏｃｏｌアセンブリ
６．３．２ Ｆｉｌｅアセンブリ
６．３．３ ＳｍａｒｔＦｉｌｅｓＡｄｄＩｎアセンブリ
７． 付録Ａ：コーディング規約
７．１ Ｓｙｓｔｅｍネームスペースの「ｓｙｓ」プレフィックス
７．２ 名前のＰａｓｃａｌ式大文字小文字の区別
７．３ シグネチャ名は「Ｓｉｇｎａｔｕｒｅ」で終わらなければならない
７．４ 「Ｓｅｔ」パラメータの名前は「ｓ」で終わらなければならない
７．５ 「単一の」エンティティタグの名前は「ｓ」で終わってはならない
７．６ セレクタタグの名前は「Ｓｅｌｅｃｔｏｒ」で終わらなければ
ならない
７．７ パラメータ（指定される場合）はエンティティの最初の属性で
なければならない
７．８ 名前（指定される場合）はパラメータ（指定される場合）の後の
エンティティの最初の属性でなければならない
目次
概要 エラー！ブックマーク未定義
目次
１． 序論
１．１ ＸＡＦの原理
１．２ ＸＡＤの目標
１．３ ＸＡＦアプリケーションの構造およびＸＡＤの役割
１．４ 仕様書の構成
１．５ 仕様の規約
２． 言語の概念
２．１ Ｈｅｌｌｏ Ｗｏｒｌｄの例
２．２ 大文字小文字の区別
２．３ エンティティタグ
２．４ エンティティの基本的なパラメータ化
２．４．１ 静的文字列を用いるパラメータ化
２．４．２ 単一のエンティティを用いるパラメータ化
２．４．３ エンティティのセットを用いるパラメータ化
２．４．４ Ｒｅｓｏｕｒｃｅｓ
２．４．５ デフォルトパラメータ
２．４．６ アタッチドパラメータ
２．４．７ インラインデータ
２．５ バインディングを介するパラメータ化
２．５．１ タグの命名
２．５．２ エンティティへのバインディング
２．５．３ グループ化タグへのバインディング
２．５．４ タグ定義の仮パラメータへのバインディング
２．５．５ 編集を可能にするためのバインディングの使用
２．６ Ｍａｉｎタグ
２．６．１ 自動投入されるＰａｒａｍ値
２．６．２ コマンドラインパラメータ化
２．７ 無視されるブロック
２．８ アウトパラメータ
２．９ ホワイトスペース
２．１０ 構造体
２．１０．１ 単一レベルの構造体
２．１０．２ ネストされた構造体
２．１１ スタイル
２．１１．１ デフォルト指定のためのスタイル
２．１１．２ Ａｖａｌｏｎのビジュアルツリーのスタイル指定
２．１１．３ スタイル指定およびビジュアルトリガ
２．１２ スコープ付きパラメータ
２．１２．１ スコープ変数
２．１２．２ リピータパターン
２．１２．３ スコープに関連するバインディングの制限
２．１２．４ ネストされたリピータパターン
２．１３ パラメータ継承
２．１３．１ 制限
２．１４ 条件付きパラメータ化
２．１４．１ Ｃａｓｅｓ
２．１４．２ Ｃｏｎｄｉｔｉｏｎｓ
２．１４．３ ＳｗｉｔｃｈＥｎｔｉｔｙ
２．１４．４ ＳｗｉｔｃｈＥｎｔｉｔｉｅｓ
２．１４．５ 全般
２．１４．６ セレクタおよびタグ定義
２．１５ 関連付け
２．１６ タグドキュメンテーション
３． 形式的言語仕様
３．１ ブール属性
３．２ 修飾名
３．３ キーワード
３．３．１ ＜Ｘａｄ＞
３．３．２ ＜Ｄｏｃ＞
３．３．３ ＜Ｄｅｓｃｒｉｐｔｉｏｎ＞
３．３．４ ＜Ｔｙｐｅ＞
３．３．５ ＜ＴａｇＤｅｆｉｎｉｔｉｏｎ＞
３．３．６ ＜Ｓｉｇｎａｔｕｒｅ＞
３．３．７ ＜ＰａｒａｍＧｒｏｕｐ＞（＜Ｘａｄ＞の下の）
３．３．８ ＜Ｃｏｎｓｔ＞
３．３．９ ＜Ｐａｒａｍ＞
３．３．１０ ＜ＯｕｔＰａｒａｍ＞
３．３．１１ ＜ＰａｒａｍＧｒｏｕｐ＞（＜Ｃｈｏｉｃｅ＞の下の）
３．３．１２ ＜ＰａｒａｍＧｒｏｕｐＲｅｆ＞
３．３．１３ ＜Ｃｈｏｉｃｅ＞
３．３．１４ ＜ＰａｒａｍＤｅｆａｕｌｔＶａｌｕｅ＞
３．３．１５ ＜ＣｏｎｓｔＤｅｆａｕｌｔＶａｌｕｅ＞
３．３．１６ ＜Ｅｎｔｉｔｙ＞
３．３．１７ ＜Ｆｕｎｃｔｉｏｎ＞
３．３．１８ ＜Ｂｏｄｙ＞
３．３．１９ ＜ＳｃｏｐｅＶａｒｉａｂｌｅ＞
３．３．２０ ＜ＡｔｔａｃｈｅｄＰａｒａｍ＞
３．４ ビルトインエンティティ
３．４．１ ＜ＩｎｌｉｎｅＤａｔａ＞
３．４．２ ＜Ｂｉｎｄｉｎｇ＞
３．４．３ ＜ＸＰａｔｈ＞
３．４．４ ＜Ｍａｐｐｉｎｇ＞
３．４．５ ＜ＤｙｎａｍｉｃＥｎｔｉｔｙ＞
３．４．６ ＜ＡｓｓｏｃｉａｔｅｄＥｎｔｉｔｙ＞
３．４．７ ＜ＡｓｓｏｃｉａｔｅｄＤａｔａＥｎｔｉｔｉｅｓ＞
３．４．８ ＜ＳｗｉｔｃｈＥｎｔｉｔｙ＞
３．４．９ ＜ＳｗｉｔｃｈＥｎｔｉｔｉｅｓ＞
３．４．１０ ＜Ｃａｓｅ＞
３．４．１１ ＜Ｃｏｎｄｉｔｉｏｎ＞
３．５ エンティティビルダ
３．６ アクション
４． 共通のフレームワークエンティティ
５． デプロイメントモデル
５．１ ＸＡＤアプリケーション
５．２ ＸＡＤアセンブリ
５．３ アセンブリマニフェスト
５．３．１ マニフェストタグ
５．３．７ マニフェストの例
５．４ アセンブリの依存関係
５．５ アセンブリのバインディング、ロードおよびアンロード
５．６ パッケージングのシナリオ
５．６．１ １ファイルアプリケーション
５．６．２ 派生タグのライブラリ
５．６．３ プリミティブタグのライブラリ
６． アドインモデル
６．１ アドインモデルとは何か？
６．２ ＸＡＤアドインモデル
６．２．１ アセンブリの動的ロード
６．２．３ メタデータ駆動型の拡張性プロトコル
６．２．４ 動的なエンティティのインスタンス化
６．３ アドインのシナリオ
６．３．１ ＦｉｌｅＥｘｔｅｎｓｉｏｎＰｒｏｔｏｃｏｌアセンブリ
６．３．２ Ｆｉｌｅアセンブリ
６．３．３ ＳｍａｒｔＦｉｌｅｓＡｄｄＩｎアセンブリ
７． 付録Ａ：コーディング規約
７．１ Ｓｙｓｔｅｍネームスペースの「ｓｙｓ」プレフィックス
７．２ 名前のＰａｓｃａｌ式大文字小文字の区別
７．３ シグネチャ名は「Ｓｉｇｎａｔｕｒｅ」で終わらなければならない
７．４ 「Ｓｅｔ」パラメータの名前は「ｓ」で終わらなければならない
７．５ 「単一の」エンティティタグの名前は「ｓ」で終わってはならない
７．６ セレクタタグの名前は「Ｓｅｌｅｃｔｏｒ」で終わらなければ
ならない
７．７ パラメータ（指定される場合）はエンティティの最初の属性で
なければならない
７．８ 名前（指定される場合）はパラメータ（指定される場合）の後の
エンティティの最初の属性でなければならない
（序論）
ＸＡＤ（ＸＡＦアプリケーション定義）は、ＸＡＦアプリケーションを作成するのに使用される宣言言語である。ＸＡＤのＵＩコンポジション態様は、可能な場合には必ずＸＡＭＬと同一である。ＸＡＤによってサポートされる追加の機能は、ほとんどが、ＸＡＦプラットフォームのデータバインディング機能を指向するものである。ＸＡＤは、複数のフォーマットを使用して表現することができるが、その主要な表現は、Ｘｍｌである。これにより、ＸＡＭＬとの強い調和が可能となる。Ｘｍｌを使用することの別の利点は、ＸＡＤパーサならびにＸＡＤ開発ツールが、ＸＡＦのネイティブデータ表現（Ｘｍｌ）を直接的に扱えることである。ＸＡＤは、ＸＡＤ開発者が明示的なコンパイルステップを実行する必要がまったくないという意味で、「解釈される」ものである。これは、性能上の理由で、ある量の、バックグラウンドにある「ＪＩＴコンパイル」を排除するものではない。
ＸＡＤ（ＸＡＦアプリケーション定義）は、ＸＡＦアプリケーションを作成するのに使用される宣言言語である。ＸＡＤのＵＩコンポジション態様は、可能な場合には必ずＸＡＭＬと同一である。ＸＡＤによってサポートされる追加の機能は、ほとんどが、ＸＡＦプラットフォームのデータバインディング機能を指向するものである。ＸＡＤは、複数のフォーマットを使用して表現することができるが、その主要な表現は、Ｘｍｌである。これにより、ＸＡＭＬとの強い調和が可能となる。Ｘｍｌを使用することの別の利点は、ＸＡＤパーサならびにＸＡＤ開発ツールが、ＸＡＦのネイティブデータ表現（Ｘｍｌ）を直接的に扱えることである。ＸＡＤは、ＸＡＤ開発者が明示的なコンパイルステップを実行する必要がまったくないという意味で、「解釈される」ものである。これは、性能上の理由で、ある量の、バックグラウンドにある「ＪＩＴコンパイル」を排除するものではない。
（ＸＡＦの原理）
ＸＡＦは、マーケットに対して時間を大幅に低減する「Ｏｆｆｉｃｅクラス」アプリケーションをビルドするプラットフォームである。ＸＡＦの核になる原理は、以下の通りである：
・均一なデータ表現としてのＸｍｌの使用；
・アプリケーションのビルドに対する非常にコンポーネント化された手法；
・強力なデータ変換機能；
・基礎になるプレゼンテーションレイヤとしてＡｖａｌｏｎを使用する、リッチでコンポーズ可能なビュー。
ＸＡＦは、マーケットに対して時間を大幅に低減する「Ｏｆｆｉｃｅクラス」アプリケーションをビルドするプラットフォームである。ＸＡＦの核になる原理は、以下の通りである：
・均一なデータ表現としてのＸｍｌの使用；
・アプリケーションのビルドに対する非常にコンポーネント化された手法；
・強力なデータ変換機能；
・基礎になるプレゼンテーションレイヤとしてＡｖａｌｏｎを使用する、リッチでコンポーズ可能なビュー。
（ＸＡＤの目標）
ＸＡＤはＸＡＦアプリケーションの作成に使用されるので、ＸＡＤの目標は、核になるＸＡＦの原理に基づいて構築される：
・外部データとアプリケーション状態との両方に関する均一なデータ表現としてのＸｍｌの使用；
・Ｘｍｌデータソースと非Ｘｍｌデータソースとの両方へのシームレスで動的なデータバインディング（非ＸｍｌデータソースのＸｍｌ表現を介する）；
・複雑なデータフローの宣言定義；
・１）追加のデータバインディング構造を伴うＸＡＭＬに似た構文、または２）ＸＡＭＬ自体のいずれかを使用するＵＩの宣言定義；
・データをどのように変換し、表示し、相互作用するかのルールベースの宣言定義；
・強い型付け、および高い度合の静的チェック；
・「ビルトイン」キーワードの最小限のセットを用いる高い度合の拡張性；
・抽象化のプログレッシブなレベル；
・○広さおよび深さ
○性能
○品質
に関する「Ｏｆｆｉｃｅクラス」アプリケーションの仕様に十分にリッチである。
ＸＡＤはＸＡＦアプリケーションの作成に使用されるので、ＸＡＤの目標は、核になるＸＡＦの原理に基づいて構築される：
・外部データとアプリケーション状態との両方に関する均一なデータ表現としてのＸｍｌの使用；
・Ｘｍｌデータソースと非Ｘｍｌデータソースとの両方へのシームレスで動的なデータバインディング（非ＸｍｌデータソースのＸｍｌ表現を介する）；
・複雑なデータフローの宣言定義；
・１）追加のデータバインディング構造を伴うＸＡＭＬに似た構文、または２）ＸＡＭＬ自体のいずれかを使用するＵＩの宣言定義；
・データをどのように変換し、表示し、相互作用するかのルールベースの宣言定義；
・強い型付け、および高い度合の静的チェック；
・「ビルトイン」キーワードの最小限のセットを用いる高い度合の拡張性；
・抽象化のプログレッシブなレベル；
・○広さおよび深さ
○性能
○品質
に関する「Ｏｆｆｉｃｅクラス」アプリケーションの仕様に十分にリッチである。
（ＸＡＦアプリケーションの構造およびＸＡＤの役割）
ＸＡＦアプリケーションは、従来のＷｉｎｄｏｗｓ（登録商標）アプリケーションプログラミング技法とは異なる技法を使用して構築される。ほとんどの既存のＷｉｎｄｏｗｓ（登録商標）アプリケーション開発技法は、開発者がアプリケーションの実行フローを制御するコードを記述することに依存する。開発ツールには、ビジュアルデザイナを用いてダイアログおよびＵＩプリミティブが宣言的に設計される当該ビジュアルデザイナを含めることができるが、開発者は、最終的に実行フローの役割を担う。開発者は、アプリケーション状態を処理するために、イベントハンドラおよびデータ構造体を記述しなければならない。開発者は、データ構造体と、当該構造体を表すビジュアル要素との間のマッピングを管理する役割も担う。このすべてが、アプリケーションごとに異なる（類似する基礎になるパターンにもかかわらず、）大量の命令アプリケーションコードを伴う。ＸＡＦは、アプリケーション作成に対する異なる手法を採用する。ＸＡＦは、アプリケーションのデータ、ユーザインターフェース、およびＵＩがデータと相互作用する形を宣言的にモデル化する。核になる設計原理は、ビュー−データ分離である。ＸＡＦアプリケーションは、必要に応じて命令コードのバブル（bubble）が挿入されるが、大部分は宣言的と考えることができる。ＸＡＦアプリケーションは、データ中心型であると言われ、アプリケーションがデータを中心とすることに加えて、すべてのアプリケーション状態も、データとして扱われる。開発者の主な関心事は、データがアプリケーションを通って流れる形と、アプリケーションがそのデータにどのように応答するかを制御するルールとである。動的データバインディングの実際のインフラストラクチャは、開発者の関心事ではなく、追加機能なしでＸＡＦによって提供される。
ＸＡＦアプリケーションは、従来のＷｉｎｄｏｗｓ（登録商標）アプリケーションプログラミング技法とは異なる技法を使用して構築される。ほとんどの既存のＷｉｎｄｏｗｓ（登録商標）アプリケーション開発技法は、開発者がアプリケーションの実行フローを制御するコードを記述することに依存する。開発ツールには、ビジュアルデザイナを用いてダイアログおよびＵＩプリミティブが宣言的に設計される当該ビジュアルデザイナを含めることができるが、開発者は、最終的に実行フローの役割を担う。開発者は、アプリケーション状態を処理するために、イベントハンドラおよびデータ構造体を記述しなければならない。開発者は、データ構造体と、当該構造体を表すビジュアル要素との間のマッピングを管理する役割も担う。このすべてが、アプリケーションごとに異なる（類似する基礎になるパターンにもかかわらず、）大量の命令アプリケーションコードを伴う。ＸＡＦは、アプリケーション作成に対する異なる手法を採用する。ＸＡＦは、アプリケーションのデータ、ユーザインターフェース、およびＵＩがデータと相互作用する形を宣言的にモデル化する。核になる設計原理は、ビュー−データ分離である。ＸＡＦアプリケーションは、必要に応じて命令コードのバブル（bubble）が挿入されるが、大部分は宣言的と考えることができる。ＸＡＦアプリケーションは、データ中心型であると言われ、アプリケーションがデータを中心とすることに加えて、すべてのアプリケーション状態も、データとして扱われる。開発者の主な関心事は、データがアプリケーションを通って流れる形と、アプリケーションがそのデータにどのように応答するかを制御するルールとである。動的データバインディングの実際のインフラストラクチャは、開発者の関心事ではなく、追加機能なしでＸＡＦによって提供される。
重要：ＸＡＤは、ＸＡＦアプリケーションを特徴付けるデータフロー、バインディング、およびルールの宣言作成を可能にするために存在する。
（仕様書の構成）
この仕様書の後のセクションの一部は、経験を積んだＸＡＤ作成者にとって独立したリファレンスとして機能し得るが、一般的に言って、セクションは、互いに基づいて構築されている。
２．言語の概念：簡単なコード例を介する、核になる言語の概念および構造の例示。言語キーワードおよび共通のフレームワークタグが、例において多用されているが、これらは、後のセクションでのみ形式的に定義される。
３．形式的言語仕様：すべての言語キーワードの形式的定義（言語キーワードは、言語に「組み込まれた」タグと考えることができる）。このセクションには、ＸＡＤの拡張性機構、すなわち、サードパーティが自身のタグをどのようにして定義できるかの形式的定義も含まれる。
４．共通のフレームワークエンティティ：標準ＸＡＤフレームワークによって提供される最も一般的なタグの説明。ＸＡＤの拡張性機構を使用してサードパーティがビルドすることのできるタグが存在する。このフレームワークタグは、推奨される設計パターンおよびベストプラクティスを使用してアプリケーションを構築するのを支援する。
５．デプロイメントモデル：ＸＡＤのアセンブリベースのデプロイメントモデルにおける形式的定義および例示的な説明。
６．アドインモデル：アドインを指定するための宣言モデルとしてＸＡＤデプロイメントモデルをどのように利用できるかの例示的な説明。
付録Ａ：コーディング規約：推奨されるＸＡＤコーディング規約のリスト。標準ＸＡＤフレームワークは、これらの規約に従う。サードパーティは、これらの規約の一部またはすべてを採用することを選択することができる。
この仕様書の後のセクションの一部は、経験を積んだＸＡＤ作成者にとって独立したリファレンスとして機能し得るが、一般的に言って、セクションは、互いに基づいて構築されている。
２．言語の概念：簡単なコード例を介する、核になる言語の概念および構造の例示。言語キーワードおよび共通のフレームワークタグが、例において多用されているが、これらは、後のセクションでのみ形式的に定義される。
３．形式的言語仕様：すべての言語キーワードの形式的定義（言語キーワードは、言語に「組み込まれた」タグと考えることができる）。このセクションには、ＸＡＤの拡張性機構、すなわち、サードパーティが自身のタグをどのようにして定義できるかの形式的定義も含まれる。
４．共通のフレームワークエンティティ：標準ＸＡＤフレームワークによって提供される最も一般的なタグの説明。ＸＡＤの拡張性機構を使用してサードパーティがビルドすることのできるタグが存在する。このフレームワークタグは、推奨される設計パターンおよびベストプラクティスを使用してアプリケーションを構築するのを支援する。
５．デプロイメントモデル：ＸＡＤのアセンブリベースのデプロイメントモデルにおける形式的定義および例示的な説明。
６．アドインモデル：アドインを指定するための宣言モデルとしてＸＡＤデプロイメントモデルをどのように利用できるかの例示的な説明。
付録Ａ：コーディング規約：推奨されるＸＡＤコーディング規約のリスト。標準ＸＡＤフレームワークは、これらの規約に従う。サードパーティは、これらの規約の一部またはすべてを採用することを選択することができる。
（仕様の規約）
ＸＡＤ内のネームスペースの使用は、Ｗ３ＣのＸｍｌネームスペース仕様（http://www.w3.org/TR/REC-xml-names/）に完全に準拠する。この仕様書では、すべてのコード例において、所定の均一なネームスペース規約を使用する。
ＸＡＤ内のネームスペースの使用は、Ｗ３ＣのＸｍｌネームスペース仕様（http://www.w3.org/TR/REC-xml-names/）に完全に準拠する。この仕様書では、すべてのコード例において、所定の均一なネームスペース規約を使用する。
「ｓｙｓ」プレフィックスを有するすべてのタグは、「ＸＡＤ Ｓｙｓｔｅｍ」ネームスペース内に存在するタグである。このシステムネームスペース内のタグは、言語に組み込まれており、言語の予約済みキーワードと考えることができる。
すべてのコード例のデフォルトネームスペースは、「ＸＡＤ標準フレームワーク」である。この仕様書内では、ネームスペースプレフィックスを有さないすべてのタグは、この標準フレームワークに属するものとして識別することができる。他の場合には、ｆｗｋネームスペースが、提供され、ＸＡＤ標準フレームワークに属するタグに関連付けられなければならない。すべてのコード例は、付録Ａのコーディング規約に準拠する。
（言語の概念）
このセクションでは、核になるＸＡＤ言語の概念および構造を、簡単なコード例を用いて例示する。より一体化されたシナリオを伴うより大きいコード例を、後のセクションで提供する。言語キーワードおよび共通のフレームワークタグが、例において多用されているが、これらは、後のセクションでのみ形式的に定義される。
このセクションでは、核になるＸＡＤ言語の概念および構造を、簡単なコード例を用いて例示する。より一体化されたシナリオを伴うより大きいコード例を、後のセクションで提供する。言語キーワードおよび共通のフレームワークタグが、例において多用されているが、これらは、後のセクションでのみ形式的に定義される。
（Ｈｅｌｌｏ Ｗｏｒｌｄの例）
ＸＡＤコードは、必ず、明確に形成されたＸｍｌでなければならない。ＸＡＤファイルの最初のタグは、＜ｓｙｓ：Ｘａｄ＞である必要がある。ファイルは通常（必ずではないが）、．ｘａｄ拡張子を有する。
ＸＡＤコードは、必ず、明確に形成されたＸｍｌでなければならない。ＸＡＤファイルの最初のタグは、＜ｓｙｓ：Ｘａｄ＞である必要がある。ファイルは通常（必ずではないが）、．ｘａｄ拡張子を有する。
重要：Ｘａｄは、必ず、明確に形成されたＸｍｌでなければならない。
ＨｅｌｌｏＷｏｒｌｄ．ｘａｄ：
ＸＡＦ ＳＤＫをインストールした後には、「ｘａｄ．ｅｘｅ ＨｅｌｌｏＷｏｒｌｄ．ｘａｄ」が、この単純なアプリケーションの実行をもたらす。ＸＡＤコードの明示的なコンパイルステップは存在しない。ＸＡＤは、ＸＡＤコードの最初の実行時に自動的に検証される（コンパイルされる場合もあるが、これは、現在は行われない）。検証ステップに合格しないＸＡＤは、必要なコーディングエラーが修正されるまで、実行できない。
以下は、ＨｅｌｌｏＷｏｒｌｄ．ｘａｄアプリケーションがどのように見えるかのスクリーンショットである。
様々な言語の概念の説明は、対象とする概念の要求を満たす小さいＸＡＤ例を使用して行われる。Ｈｅｌｌｏ Ｗｏｒｌｄの例をリストしたことの主な目的は、ＸＡＤがどのように見えるかに関する、ある種の基本的なコンテキストを提供することであった。
（大文字小文字の区別）
以下のように記述することは、
以下のように記述することは、
以下のように記述することと「同一ではない」：
重要：ＸＡＤは、大文字と小文字とを区別する。
（エンティティタグ）
ＸＡＤのすべてのタグがエンティティタグであるわけではない（「グループ化タグ」および「セレクタタグ」として知られる２つの他の種類のタグがあり、これらは、エンティティタグの些細な変形であり、後の説明において定義される）。しかし、エンティティタグは、最も一般的であり、かつ重要な種類のＸＡＤタグである。
ＸＡＤのすべてのタグがエンティティタグであるわけではない（「グループ化タグ」および「セレクタタグ」として知られる２つの他の種類のタグがあり、これらは、エンティティタグの些細な変形であり、後の説明において定義される）。しかし、エンティティタグは、最も一般的であり、かつ重要な種類のＸＡＤタグである。
重要：ＸＡＤエンティティタグは、非常に単純に、ランタイムにＣＬＲオブジェクトにマッピングする。ＣＬＲオブジェクトに関する唯一の制限は、それがＸＡＦエンティティであることである。
ＸＡＦエンティティであるために、ＣＬＲオブジェクトは、以下のことを行わなければならない：
・２つのベースクラス、すなわち、
○Ｍｉｃｒｏｓｏｆｔ．Ｘａｆ．Ｃｏｒｅ．ＢａｓｅＴｙｐｅｓ．ＥｎｔｉｔｙＥｌｅｍｅｎｔ
○Ｍｉｃｒｏｓｏｆｔ．Ｘａｆ．Ｃｏｒｅ．ＢａｓｅＴｙｐｅｓ．ＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅ
の１つから派生し、
・http://xafteam/xafenv/doc/Platform/Core Components/_Dev/DevIntroToEntityDomains.docにおいて定義されたある種のプロトコルおよび契約を厳守する。
・２つのベースクラス、すなわち、
○Ｍｉｃｒｏｓｏｆｔ．Ｘａｆ．Ｃｏｒｅ．ＢａｓｅＴｙｐｅｓ．ＥｎｔｉｔｙＥｌｅｍｅｎｔ
○Ｍｉｃｒｏｓｏｆｔ．Ｘａｆ．Ｃｏｒｅ．ＢａｓｅＴｙｐｅｓ．ＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅ
の１つから派生し、
・http://xafteam/xafenv/doc/Platform/Core Components/_Dev/DevIntroToEntityDomains.docにおいて定義されたある種のプロトコルおよび契約を厳守する。
タグビルダクラスは、エンティティの実際のインスタンス化（ファクトリパターン）ならびにエンティティのパラメータ化の役割を担うクラスである。タグビルダは、実際には、フレームワークエクステンダ（framework extender）だけに重要な実装詳細である。
以下のＨｅｌｌｏ Ｗｏｒｌｄの例には、３つのエンティティタグ（Ａｐｐｌｉｃａｔｉｏｎ、Ｗｉｎｄｏｗ、およびＴｅｘｔ）が存在する。
この３つのエンティティタグの各々は、アプリケーションの実行時にエンティティの作成をもたらす：
・Ａｐｐｌｉｃａｔｉｏｎエンティティは、アプリケーションを「調整し」、最高レベルのアプリケーション機能を制御する、ルートレベルエンティティである；
・Ｗｉｎｄｏｗエンティティは、アプリケーションのフレームを表示する役割を担うＵＩエンティティである；
・Ｔｅｘｔエンティティは、テキスト（このケースでは「Ｈｅｌｌｏ Ｗｏｒｌｄ」）を表示する役割を担うＵＩエンティティである。
・Ａｐｐｌｉｃａｔｉｏｎエンティティは、アプリケーションを「調整し」、最高レベルのアプリケーション機能を制御する、ルートレベルエンティティである；
・Ｗｉｎｄｏｗエンティティは、アプリケーションのフレームを表示する役割を担うＵＩエンティティである；
・Ｔｅｘｔエンティティは、テキスト（このケースでは「Ｈｅｌｌｏ Ｗｏｒｌｄ」）を表示する役割を担うＵＩエンティティである。
エンティティタグは、フォームの宣言によって定義され、例えば、Ｔｅｘｔタグ定義は、以下のように始まる。
重要：すべてのタグ定義は、すべてのエンティティタグをエンティティに最終的にマッピングするのに十分な情報を含む。
重要：すべてのエンティティタグは、対応するタグ定義を有する。
エンティティタグを、様々な型に分類することができる。これらの型は、拡張可能なセットであり、実際に、タグに関連付けられたエンティティのＣＬＲ型に対応する。標準フレームワークによって多用される型のいくつかの例が、ｓｙｓ：Ｄａｔａ ｓｙｓ：ＥｖｅｎｔＨａｎｄｌｅｒ、ｆｗｋ：ＵＩＥｌｅｍｅｎｔ、およびｓｙｓ：Ｓｅｌｅｃｔｏｒである。
一般に、ＦｒａｍｅｗｏｒｋネームスペースまたはＳｙｓｔｅｍネームスペースにタグを追加することの区別は、以下の基準に基づく：
１．
ａ．タグが内部エンジンインターフェースに依存する
ｂ．コア言語と同一のレートのバージョンである
場合には、Ｓｙｓｔｅｍに追加し、
２．
ａ．内部エンジンインターフェースに依存しない
ｂ．コア言語と同一のレートのバージョンではない
場合には、Ｆｒａｍｅｗｏｒｋに追加する。
１．
ａ．タグが内部エンジンインターフェースに依存する
ｂ．コア言語と同一のレートのバージョンである
場合には、Ｓｙｓｔｅｍに追加し、
２．
ａ．内部エンジンインターフェースに依存しない
ｂ．コア言語と同一のレートのバージョンではない
場合には、Ｆｒａｍｅｗｏｒｋに追加する。
＄ＴＯＤＯ − 内部エンジンインターフェースの例を提供する。Ｘａｄファイルおよび行番号などの情報の取得が、内部Ｘａｄインターフェースにアクセスすることによって行われることはわかっているが、重要なものはどれであるか？
エンティティの型は、エンティティの定義において宣言され、Ｔｅｘｔタグに関して検討すると、そのＴｙｐｅは、そのタグ定義において以下のように指定されている。
エンティティの型は、エンティティの定義において宣言され、Ｔｅｘｔタグに関して検討すると、そのＴｙｐｅは、そのタグ定義において以下のように指定されている。
重要：すべてのエンティティタグは、型を有する。
（エンティティの基本的なパラメータ化）
前のセクションでは、エンティティタグが、ランタイムでのオブジェクト（より具体的にはＸＡＦエンティティ）の作成をもたらすことを確立した。しかし、オブジェクトが有用になるためには、オブジェクトは、ある種の意味のあるパラメータ化を必要とする。このセクションでは、ＸＡＤエンティティのパラメータ化に関する最も基本的な形を扱う。
前のセクションでは、エンティティタグが、ランタイムでのオブジェクト（より具体的にはＸＡＦエンティティ）の作成をもたらすことを確立した。しかし、オブジェクトが有用になるためには、オブジェクトは、ある種の意味のあるパラメータ化を必要とする。このセクションでは、ＸＡＤエンティティのパラメータ化に関する最も基本的な形を扱う。
（静的文字列を用いるパラメータ化）
ＸＡＤは、エンティティのパラメータを宣言する多数の異なる形を可能にする。一般的な形は、以下の通りである。
ＸＡＤは、エンティティのパラメータを宣言する多数の異なる形を可能にする。一般的な形は、以下の通りである。
この宣言は、Ｔｅｘｔエンティティが、「Ｔｅｘｔ」という名前で型「Ｄａｔａ」、より具体的には「Ｓｔｒｉｎｇ Ｄａｔａ」のパラメータを有することを示している。
Ｔｅｘｔエンティティの実際のインスタンスは、以下のようになる：
重要：タグ定義パラメータは、そのパラメータと同一の名前を有する、タグの実際のインスタンス内の属性に対応する。
定義：「静的な値」は、文字列の値が、アプリケーションの有効期間の間、固定されていることを意味する。
定義：「Ｓｔｒｉｎｇパラメータ」は、パラメータ宣言において、Ｔｙｐｅが「Ｄａｔａ」であり、Ｓｃｈｅｍａが、何らかのＸＳＤ Ｓｉｍｐｌｅ Ｔｙｐｅであることを意味する。
重要：静的な値を有するＳｔｒｉｎｇパラメータは、「．／」または「＄」から始めることができない。さらに、Ｓｔｒｉｎｇパラメータは、「．」（単一のドット）にすることができない。この３つの表現は、ＸＡＤバインディング用に予約済みである。
後のセクションで、＜ｓｙｓ：ＩｎｌｉｎｅＤａｔａ＞タグを紹介し、「．／」または「＄」から始まる静的文字列、もしくは「．」だけの静的文字列をどのように表すことができるかを説明する。
（単一のエンティティを用いるパラメータ化）
前の例では、ハードコーディングされた文字列すなわち静的文字列を使用して、Ｔｅｘｔ ＵＩ要素のテキストを指定することを選択した。その代わりに、文字列を作成するエンティティを用いて、Ｔｅｘｔ要素をパラメータ化することが可能である。ランダムな文字列を作成するＲａｎｄｏｍ Ｗｏｒｄ Ｃｏｎｎｅｃｔｏｒエンティティについて検討する。
前の例では、ハードコーディングされた文字列すなわち静的文字列を使用して、Ｔｅｘｔ ＵＩ要素のテキストを指定することを選択した。その代わりに、文字列を作成するエンティティを用いて、Ｔｅｘｔ要素をパラメータ化することが可能である。ランダムな文字列を作成するＲａｎｄｏｍ Ｗｏｒｄ Ｃｏｎｎｅｃｔｏｒエンティティについて検討する。
（Ｒａｎｄｏｍ Ｆｏｎｔ Ｆａｍｉｌｙの宣言は、主に、Ｔｙｐｅ属性が、ＴｅｘｔのＦｏｎｔＦａｍｉｌｙパラメータの対応するＴｙｐｅ属性と一致するという事実を強調するためにリストされたものである）。
別のエンティティを用いてパラメータ化されたＦｏｎｔＦａｍｉｌｙは、以下のようになる：
これは、「ＴｅｘｔエンティティのＦｏｎｔＦａｍｉｌｙパラメータについて有効としてＲａｎｄｏｍ Ｆｏｎｔ Ｆａｍｉｌｙを使用せよ」と解釈することができる。
重要：「Ｐａｒａｍ」属性は、所与のエンティティがどの単一のパラメータに対応するのかを示すのに使用される。
定義：単一のパラメータは、そのパラメータが多くとも１つのエンティティ（エンティティのセットではない）をとることを意味する。エンティティのセットのパラメータ化については、次のセクションで扱う。
重要：「Ｐａｒａｍ」は、予約済みパラメータ名である。
これは、単純に、ユーザ定義パラメータに「Ｐａｒａｍ」と命名することができないことを意味する。以下のことを記述することは、不正である。
他のエンティティを用いるエンティティのパラメータ化をよりよく理解してもらうために、エンティティ階層内に余分のレベルを有する次の例を検討する。
Ｘｍｌ Ｆｉｌｅ Ｄａｔａ Ｓｏｕｒｃｅエンティティは、数のリストを含むＸｍｌファイルの名前を用いてパラメータ化される。Ｆｉｌｅ Ｃｏｎｎｅｃｔｏｒエンティティは、数のリストを作成するものと考えることができる。Ｈｉｇｈｅｓｔ Ｖａｌｕｅ Ｔｒａｎｓｆｏｒｍは、（このケースでは、Ｘｍｌ Ｆｉｌｅ Ｄａｔａ Ｓｏｕｒｃｅによって提供される）リストを用いてパラメータ化される。
Ｈｉｇｈｅｓｔ Ｖａｌｕｅ Ｔｒａｎｓｆｏｒｍは、最大値を有するリスト項目を作成する。次に、Ｔｅｘｔ要素が、Ｈｉｇｈｅｓｔ Ｖａｌｕｅ Ｔｒａｎｓｆｏｒｍによって作成されたリスト項目を用いてパラメータ化される（リスト項目がＴｙｐｅ ｓｙｓ：Ｄａｔａであり、かつＴａｒｇｅｔＴｙｐｅ ｆｗｋ：Ｓｔｒｉｎｇである限り、そのリスト項目をＴｅｘｔによって使用することができる）。
次の図は、ここで発生しているネストされたデータフローを例示するのを助けるものである。
これを記述する別の形は、Ｐａｒａｍ属性を使用しない。こちらの方が理解されやすいことが多い。
上のＸａｄからわかるように、Ｐａｒａｍ構文を使用することによって、Ｘａｄアプリケーションをより簡潔にすることができる。しかし、この構文の使用は、機能的ではなく、スタイルの問題である。
（エンティティのセットを用いるパラメータ化）
ここまでは、単一のパラメータ化に焦点を合わせた。単一のパラメータとは、多くとも１つのエンティティをとるパラメータである。しかし、複数のエンティティをとるパラメータを宣言することが可能である。以下について検討する。
ここまでは、単一のパラメータ化に焦点を合わせた。単一のパラメータとは、多くとも１つのエンティティをとるパラメータである。しかし、複数のエンティティをとるパラメータを宣言することが可能である。以下について検討する。
その名が示す通り、ＦｌｏｗＰａｎｅｌ要素は、ＵＩ Ｅｌｅｍｅｎｔのフローを表示する。「フロー」される明示的なＵＩ Ｅｌｅｍｅｎｔのセットは、「Ｃｈｉｌｄｒｅｎ」という名前のパラメータを介して指定することができる。
ＦｌｏｗＰａｎｅｌインスタンスは、以下のように指定することができる：
ＦｌｏｗＰａｎｅｌ．Ｃｈｉｌｄｒｅｎグループ化タグの下で指定されるエンティティのセットは、ＦｌｏｗＰａｎｅｌの「Ｃｈｉｌｄｒｅｎ」パラメータに対応する。
結果として生じるビューは、以下のようになる：
Ｃｈｒｉｓ Ｈａｃｋｍａｎｎ
Ｖｌａｄｏ Ｈｒｉｓｔｏｖ
Ｗｉｌｌｉａｍ Ａｉｔｋｅｎ
Ｃｈｒｉｓ Ｈａｃｋｍａｎｎ
Ｖｌａｄｏ Ｈｒｉｓｔｏｖ
Ｗｉｌｌｉａｍ Ａｉｔｋｅｎ
重要：エンティティのセットをサポートするすべてのパラメータについて、そのパラメータと同一の名前を有する暗黙的なグループ化タグが存在する。
重要：グループ化タグは、そのグループ化タグに対応するパラメータを指定するエンティティと同一のネームスペース内に存在する。
１つのサブＵＩ ＥｌｅｍｅｎｔだけがＦｌｏｗＰａｎｅｌに関して指定された場合、以下のように記述することは、それでも有効である。
重要：１つのエンティティだけが使用される場合であっても、グループ化タグは、エンティティのセットをサポートするパラメータに対して使用することができる。
（１つのエンティティだけが指定される限り、）セットをとるパラメータに「Ｐａｒａｍ」を使用することが有効であることに留意されたい。
以下の記述も有効である。
以下のように記述することも可能である。
ＸＱｕｅｒｙの使用が有効なのは、これがＦｌｏｗＰａｎｅｌのＦｌｏｗＯｒｉｅｎｔａｔｉｏｎパラメータの値として使用されているからである（Ｐａｒａｍ＝“ＦｌｏｗＯｒｉｅｎｔａｔｉｏｎ”によって表される）。Ｐａｒａｍ＝“．．．”が省略された場合には、これは無効なＸａｄとなる。
重要：エンティティのセットの指定は、複数のグループ化タグに分割することができる。
（Ｒｅｓｏｕｒｃｅｓ）
重要：すべてのエンティティ（ｓｙｓ：ＩｎｌｉｎｅＤａｔａを除く）は、任意のエンティティの無制限のセットをとる、Ｒｅｓｏｕｒｃｅｓと呼ばれる暗黙的なパラメータを有する。
重要：すべてのエンティティ（ｓｙｓ：ＩｎｌｉｎｅＤａｔａを除く）は、任意のエンティティの無制限のセットをとる、Ｒｅｓｏｕｒｃｅｓと呼ばれる暗黙的なパラメータを有する。
すべてのエンティティに対して暗黙的にサポートされる、「Ｒｅｓｏｕｒｃｅｓ」という名前の特殊なパラメータが存在する。唯一の例外は、ｓｙｓ：ＩｎｌｉｎｅＤａｔａであり、これはＲｅｓｏｕｒｃｅｓをサポートしない。Ｒｅｓｏｕｒｃｅｓパラメータは、所与のエンティティの下で任意のエンティティのセットをアンカリングするのに使用される。
Ｒｅｓｏｕｒｃｅｓパラメータは、Ａｃｔｉｏｎおよび状態の「グラブバッグ（grab-bag）」として、アプリケーションの最上位レベルで使用されることが多い。次に、それらのＡｃｔｉｏｎおよび状態が、例えば、以下のように、アプリケーション全体を通じて使用される。
ＵＩ要素が状態および／またはＡｃｔｉｏｎにバインドされる形は、ＸＡＤバインディング構造を説明するときに明白になる。データコネクタの「Ｎａｍｅ」属性およびＡｃｔｉｏｎは、バインディングのコンテキストでも説明する。
（デフォルトパラメータ）
ここまでで、ＸＡＤ内でパラメータを指定する２つの形、すなわち、「Ｐａｒａｍ」属性の使用およびグループ化タグの使用を扱った。しかし、以下のＨｅｌｌｏ Ｗｏｒｌｄの例では、この両方が使用されない。
ここまでで、ＸＡＤ内でパラメータを指定する２つの形、すなわち、「Ｐａｒａｍ」属性の使用およびグループ化タグの使用を扱った。しかし、以下のＨｅｌｌｏ Ｗｏｒｌｄの例では、この両方が使用されない。
その理由は、このＨｅｌｌｏ Ｗｏｒｌｄの例が、「デフォルトパラメータ」に依拠しているからである。この例を、以下のように書き直すことができる。
Ａｐｐｌｉｃａｔｉｏｎのタグ定義は、以下のことに類似した行を含む。
重要：すべてのエンティティは、そのパラメータのうちの１つをデフォルトパラメータとして定義することができる。その結果、デフォルトパラメータに対応するエンティティは、「Ｐａｒａｍ」属性またはグループ化タグのいずれかを使用して修飾される必要がない。
上記のＦｌｏｗＰａｎｅｌの例を想起されたい。
これを、グループ化タグ（すなわち、ＦｌｏｗＰａｎｅｌ．Ｃｈｉｌｄｒｅｎ）なしで書き直すことができる。というのは、「Ｃｈｉｌｄｒｅｎ」が、ＦｌｏｗＰａｎｅｌエンティティのデフォルトパラメータとして指定されるからである。
重要：あるエンティティの所与のインスタンスを、デフォルトパラメータと非デフォルトパラメータとの両方を用いてパラメータ化することができる。
（アタッチドパラメータ）
ここまでで、エンティティが閉じられたパラメータのセットをどのように宣言できるかを確立した。次に、以下のＸＡＤスニペットを検討する。
ここまでで、エンティティが閉じられたパラメータのセットをどのように宣言できるかを確立した。次に、以下のＸＡＤスニペットを検討する。
結果のビューは、多少は以下のように見えることになる。
これらのＴｅｘｔエンティティは、ＤｏｃｋＰａｎｅｌエンティティの「Ｃｈｉｌｄｒｅｎ」パラメータとして指定される。
想起されたいこと：ＣｈｉｌｄｒｅｎはＤｏｃｋＰａｎｅｌエンティティのデフォルトパラメータなので、グループ化タグの必要性はない。
注記すべき興味深い点は、「ＤｏｃｋＰａｎｅｌ．Ｄｏｃｋ」が、Ｔｅｘｔエンティティの各々に対する属性として指定されていることである。しかし、「ＤｏｃｋＰａｎｅｌ．Ｄｏｃｋ」は、Ｔｅｘｔエンティティのタグ定義において指定されたパラメータの「１つではない」。
想起されたいこと：今までは、タグのインスタンスは、それに対応するタグ定義においてパラメータとして定義された属性だけを使用することができた。
「ＤｏｃｋＰａｎｅｌ．Ｄｏｃｋ」は、アタッチドパラメータの一例である。これは、実際にはＤｏｃｋＰａｎｅｌエンティティの宣言において定義される。
これは、Ｃｈｉｌｄｒｅｎパラメータの一部として指定されるＵＩ Ｅｌｅｍｅｎｔごとに、ＤｏｃｋＰａｎｅｌ．Ｄｏｃｋという名前のアタッチドパラメータを指定することが可能であることを示している。
アタッチドパラメータ（既知のＶ１シナリオのいずれにも違反しない）の（Ｘａｄエンジンによる）技術的制限は、単一ではないアタッチドパラメータを指定することができないことである。例えば、以下のように記述することは、不正である。
重要：Ｘａｄエンジンは、単一ではないアタッチドパラメータをサポートしない。
重要：ＡｔｔａｃｈｅｄＰａｒａｍのＴｙｐｅは、必ずｓｙｓ：Ｄａｔａでなければならない。
（ＴａｒｇｅｔＴｙｐｅは、基礎になるＭａｎａｇｅｄ Ａｖａｌｏｎ型を定義し、この型は、「Ｄｏｃｋ」アタッチドパラメータのＡｖａｌｏｎ型を定義する。）
用語アタッチドパラメータは、このパラメータがエンティティの親（このエンティティ自体ではなく）によって「提供される（sponsored）」か、または「アタッチされる」という事実に由来する。
さらに、ＤｏｃｋＰａｎｅｌ．Ｄｏｃｋ構文は、アタッチドパラメータとしてパラメータの特性を呼び出すのに使用される。第１の態様すなわちＤｏｃｋＰａｎｅｌは、パラメータを提供するエンティティを定義する。一方、第２の態様すなわちＤｏｃｋは、ＤｏｃｋＰａｎｅｌタグ定義内で定義されるアタッチドパラメータのＮａｍｅを定義する。
重要：あるエンティティのアタッチドパラメータは、通常のパラメータと同一の形で指定されるが、そのエンティティの親／そのエンティティを含むエンティティによって「オーソライズされ」、管理される。
重要：アタッチドパラメータのデフォルト値は、ＸＡＤが公開している対応するＸＡＭＬ要素によって決定される。その結果、ユーザは、上記で指定されたデフォルト値を見ない。
（インラインデータ）
ここまでの例では、属性を介して単純な静的文字列を指定するか、より複雑なデータをＸＡＤに持ち込むためにデータソースに依拠するかのいずれかであった。
ここまでの例では、属性を介して単純な静的文字列を指定するか、より複雑なデータをＸＡＤに持ち込むためにデータソースに依拠するかのいずれかであった。
Ｉｎｌｉｎｅ Ｄａｔａエンティティは、単純なデータと複雑なデータとの両方をＸＡＤに直接的に埋め込むのに使用できる、型「ｓｙｓ：Ｄａｔａ」のＳｙｓｔｅｍエンティティである。
以下のＸＡＤを記述する代わりに、
以下のように、Ｄａｔａ．ｘｍｌからＸＡＤに直接的にデータを埋め込むことが可能である。
（属性構文ははるかに簡潔であるにもかかわらず、）Ｉｎｌｉｎｅ Ｄａｔａエンティティを使用して、単純なテキスト値を指定することも可能である。「＄」または「．」から始まる文字列など、ある種のエッジ制約（edge condition）のために、Ｉｎｌｉｎｅ Ｄａｔａエンティティは、ＸＡＤ内で直接的に文字列を指定する唯一の形である。
結果として生じるビューは、 ＄５００ と表示する。
１）（ＴｏｎｙＷによる追加）単純な文字、すなわち、「＄」および「．」を簡単にエスケープするというアイデアを探る必要がある。「＄」の場合には、「＄＄」を使用できると思われる。「．」をエスケープする簡単な形はないと思われる。
定義：＜ｓｙｓ：ＩｎｌｉｎｅＤａｔａ＞は、型「ｓｙｓ：Ｄａｔａ」のエンティティタグであり、その下で直接的に書き込まれる単純なコンテンツまたは複雑なコンテンツを作成する。
（バインディングを介するパラメータ化）
（タグの命名）
重要：Ｎａｍｅは予約済みパラメータ名である。
（タグの命名）
重要：Ｎａｍｅは予約済みパラメータ名である。
これは、単純に、ユーザ定義パラメータにＮａｍｅという名前を付けられないことを意味する。以下のように記述することは、不正である。
重要：Ｎａｍｅ属性は、任意のエンティティタグ、グループ化タグ、またはセレクタタグに書き込むことができる。
セレクタタグについてはまだ説明していないが、さしあたって、この文は、すべてのエンティティタグおよびグループ化タグに名前を付けることができることを意味する。この命名は、純粋に、バインディング（別名エンティティの共有）を可能にするためである。例えば、
重要：Ｎａｍｅは、スコープ内で一意でなければならない。タグ定義の本体内のエンティティのいずれもがスコープを導入しない場合には、名前は、そのタグ定義の本体内で一意でなければならない。
スコープの概念についてはまだ紹介していないが、この説明のためには、ある種のパラメータを、新しいスコープを導入するものとして考えることで十分である。この文は、タグ定義の本体内にそのような「スコープを導入する」パラメータがない場合に、名前がそのタグ定義の本体内で一意でなければならないことを示している。
タグ定義内に複数のスコープが存在する場合には、名前の一意性制限が緩和される。名前は、所与のスコープ内で一意であるだけでよい。これは、スコープ付きパラメータを説明するときにより明瞭になるはずである。
（エンティティへのバインディング）
共通のデータソースに対する２つのビューを検討する。ＸＡＤ用語では、これは、３つのエンティティ、すなわち、２つのＵＩ Ｅｌｅｍｅｎｔエンティティおよび共有されるＤａｔａ Ｓｏｕｒｃｅエンティティを伴う。
共通のデータソースに対する２つのビューを検討する。ＸＡＤ用語では、これは、３つのエンティティ、すなわち、２つのＵＩ Ｅｌｅｍｅｎｔエンティティおよび共有されるＤａｔａ Ｓｏｕｒｃｅエンティティを伴う。
ここまでの説明では、必ず、エンティティと、そのエンティティが当該エンティティを用いてパラメータ化されるエンティティとの間に１対１マッピングが存在した。しかし、エンティティの共有は、明らかに一般的なシナリオである。ＸＡＤは、このことを達成するのに必要な構造を有する。
重要：ＳｏｍｅＰａｒａｍ＝“＄ＳｏｍｅＮａｍｅ”という形の属性は、ＳｏｍｅＰａｒａｍパラメータがＳｏｍｅＮａｍｅという名前のエンティティにバインドされることを意味する。
重要：パラメータの型およびパラメータがバインドされるエンティティの型は、一致しなければならない。
これは、以下のことが不正であることを意味する。
Ｂｅｅｐ Ｃｏｍｍａｎｄエンティティは、型「ｓｙｓ：ＥｖｅｎｔＨａｎｄｌｅｒ」であるが、Ｔｅｘｔパラメータは、型「ｓｙｓ：Ｄａｔａ」である。
ＴａｂｌｅおよびＴｒｅｅを伴う上記の例では、ＭｙＴａｂｌｅ．ｘｍｌが以下の形を有する。
Ｔｒｅｅは、任意のツリーを使用することができるが、Ｔａｂｌｅは、表形状を有するデータ（上記のデータについてはそうである）を必要とする。
次に、Ｔａｂｌｅ．ｘｍｌが、その代わりに以下を含む場合にどうなるかを検討する。
Ｔａｂｌｅは、表形式でないデータ（＜ＳｅａｒｃｈＲｅｓｕｌｔｓ＞タグ）にバインドされることになる。
この不一致を解決するためには、Ｔａｂｌｅパラメータに関するＴａｂｌｅのバインディングを、以下のように書き直さなければならない。
このバインディングは、「ＴａｂｌｅのＴａｂｌｅパラメータを、ＳｈａｒｅｄＤａｔａＳｏｕｒｃｅという名前のエンティティによって返されるＸｍｌツリー内のｍｙｄ：ＴａｂｌｅＤａｔａ要素にバインドせよ」と解釈される。
＄ＳｈａｒｅｄＤａｔａＳｏｕｒｃｅが、Ｘｍｌファイルのルートにバインドされる、すなわち、＄ＳｈａｒｅｄＤａｔａＳｏｕｒｃｅが＜ＳｅａｒｃｈＲｅｓｕｌｔｓ ．．．＞のエイリアスになることに留意することが重要である。したがって、位置＄ＳｈａｒｅＤａｔａＳｏｕｒｃｅ／ｍｙｄ：ＴａｂｌｅＤａｔａは、ｍｙｄ：ＳｅａｒｃｈＲｅｓｕｌｔｓ／ｍｙｄ：ＴａｂｌｅＤａｔａを指定することに類似する。
さらに、位置に対するネームスペースプレフィックスの使用に留意されたい。これは、非常に重要である。
Ｘｍｌファイルは、ｘｍｌｎｓ＝“ＭｙＤａｔａ”というデフォルトネームスペースを指定するので、Ｘａｄ内のバインディング位置は、データへのアクセスを試みるときに同一のネームスペースを使用しなければならない。ほとんどの場合、Ｘａｄアプリケーションは、デフォルトネームスペースとして、Ｘａｄ Ｆｒａｍｅｗｏｒｋネームスペースを使用する。
したがって、バインディングが以下のように指定され、
かつ、ＦｒａｍｅｗｏｒｋネームスペースがＸａｄアプリケーションにおけるデフォルトネームスペースである場合に、バインディングは、以下のように解釈される。
明らかに、これは、Ｘｍｌファイルから所望のデータを提供することにはならない。したがって、ｘｍｌｎｓ：ｍｙｄ＝“ＭｙＤａｔａ”ネームスペースの宣言は、非常に重要である。これを行わないことが、しばしば、多数のいらいらさせるアプリケーションバグの原因となる。
重要：＄ＳｏｍｅＮａｍｅ／ＳｏｍｅＸＰａｔｈの形のバインディングは、ＳｏｍｅＮａｍｅという名前のデータエンティティによって公開されたツリー内の位置へのバインディングを意味する。この位置は、ＳｏｍｅＸＰａｔｈによって指定され、ＳｏｍｅＸＰａｔｈは、有効な相対位置でなければならない。
定義：データエンティティは、型「ｓｙｓ：Ｄａｔａ」の任意のエンティティである。
所与のタグ定義の本体内で実際にバインドできるエンティティは、スコープの概念によって制限される。これは、スコープ付きパラメータの概念を以下で紹介するときに、より詳細に扱うことにする。
（有効な相対位置）
次のＸｍｌファイル（ＲｅｌＬｏｃＤａｔａ．ｘｍｌ）は、以下の相対位置の例において使用される。
次のＸｍｌファイル（ＲｅｌＬｏｃＤａｔａ．ｘｍｌ）は、以下の相対位置の例において使用される。
（Ｔｅｘｔ Ｅｌｅｍｅｎｔの指定）
これは、値Ｓｔｅｐｈｅｎ Ｄａｎｔｏｎを作成する。
（認識しておくべきいくつかの詳細）
留意すべき主要な態様は、相対位置が基礎になるデータソースにどのようにマッピングされるかである。＄ＲｅｌＬｏｃＤａｔａが、Ｘｍｌ文書全般にはマッピングされないことに留意されたい。そうではなく、＄ＲｅｌＬｏｃＤａｔａは、文書のルート、すなわち、＜ＴａｂｌｅＤａｔａ ．．．＞にマッピングされる。これについて考える別の形は、＄ＳｏｍｅＢｉｎｄｉｎｇが、それがバインドされるデータのＸｍｌルートのエイリアスになるというものである。この理由から、以下のように記述することができる。
留意すべき主要な態様は、相対位置が基礎になるデータソースにどのようにマッピングされるかである。＄ＲｅｌＬｏｃＤａｔａが、Ｘｍｌ文書全般にはマッピングされないことに留意されたい。そうではなく、＄ＲｅｌＬｏｃＤａｔａは、文書のルート、すなわち、＜ＴａｂｌｅＤａｔａ ．．．＞にマッピングされる。これについて考える別の形は、＄ＳｏｍｅＢｉｎｄｉｎｇが、それがバインドされるデータのＸｍｌルートのエイリアスになるというものである。この理由から、以下のように記述することができる。
というのは、これが、ｍｙｄ：ＴａｂｌｅＤａｔａ／ｍｙｄ：Ｅｍｐｌｏｙｅｅｓ．．．と記述することと本質的に同一であるからである。
バインディングを使用するときに認識しておくべきいくつかの他の態様。データソースが、データのテキスト要素への直接的なルート＄ＳｏｍｅＢｉｎｄｉｎｇバインディングを有しておらず、その値として、例えば、以下を公開する場合。
この場合に、Ｔｅｘｔ＝“＄ＵｎｒｏｏｔｅｄＤａｔａ”を指定すると、＄ＵｎｒｏｏｔｅｄＤａｔａが文字列“Ｗｈｅｒｅ ｉｓ ｍｙ ｒｏｏｔ？”に直接的にマッピングされるのが認識されよう。
既に理解されていると思われるが、明示的に呼び出すことがよい最後のシナリオは、例えば、以下のルート専用データソースである。
この場合に、＄ＲｏｏｔＯｎｌｙＤａｔａは、タグ＜Ｒｏｏｔ＞にマッピングされ、デフォルトで、そのタグの下の最初のテキスト要素、すなわち、文字列“Ｉ Ｒｏｏｔ ｔｈｅｒｅｆｏｒｅ Ｉ ａｍ”を返す。
以下のように属性値を指定すると、
値１が作成される。
以下のように特定の子を指定すると、
値Ａｎｄｙ Ｗａｓｓｙｎｇが作成される（すなわち、Ｅｍｐｌｏｙｅｅｓの２番目の子）。
＄ＴＯＤＯ − 時間が許す限りこのリストに追加すること
（グループ化タグへのバインディング）
エンティティタグにバインドできることに加えて、グループタグにバインドすることが可能である。例えば、
エンティティタグにバインドできることに加えて、グループタグにバインドすることが可能である。例えば、
Ｍｅｒｇｅ Ｔｒｅｅｓ Ｔｒａｎｓｆｏｒｍエンティティは、型「ｓｙｓ：Ｄａｔａ」のエンティティのセットをとる、「Ｔｒｅｅｓ」と呼ばれるパラメータを有する。Ｒｅｓｏｕｒｃｅｓグループ化タグにバインドすることによって、Ｍｅｒｇｅ Ｔｒｅｅｓ Ｔｒａｎｓｆｏｒｍは、Ｒｅｓｏｕｒｃｅｓグループ化タグの下のエンティティのセットに「バインド」されることになる。
重要：グループ化タグへのバインディングは、そのグループ化タグの下で指定されるエンティティのセットへのバインディングをもたらす。
（タグ定義の仮パラメータへのバインディング）
このトピックを、バインディングのコンテキストにおいて説明しているが、このトピックは、実際には、単なるパラメータのバインディングを超えたものに関する。ここでは、抽象化のプログレッシブなレベルを有するタグ（従来の言語における関数によく似ている）を簡単に作成するのに、ＸＡＤをどのように使用できるかを示す。
このトピックを、バインディングのコンテキストにおいて説明しているが、このトピックは、実際には、単なるパラメータのバインディングを超えたものに関する。ここでは、抽象化のプログレッシブなレベルを有するタグ（従来の言語における関数によく似ている）を簡単に作成するのに、ＸＡＤをどのように使用できるかを示す。
以下のＸＡＤスニペットを検討する。
このＸＡＤスニペットを「ＴａｂｌｅＷｉｔｈＣａｐｔｉｏｎ」という名前の抽象化として作り直したいと仮定することが現実的である。関数によく似て、抽象化のユーザは、何らかの挙動を再パラメータ化することを望む場合がある。これは、「ＴａｂｌｅＷｉｔｈＣａｐｔｉｏｎ」という名前の新しいエンティティタグを作成することによって達成することができる。このタグは、２つのパラメータ、すなわち、「Ｃａｐｔｉｏｎ」および「ＴａｂｌｅＦｉｌｅ」をとる。ＸＡＤ作成者は、以下の純粋な宣言定義を介して、これを達成することができる。
仮パラメータが、タグ定義の本体内のエンティティが参照されるのと正確に同一の形で、どのように参照されるかに留意されたい。
重要：タグ定義の本体内で、タグ定義に対する仮パラメータを、ＳｏｍｅＰａｒａｍ＝“＄ＦｏｒｍａｌＰａｒａｍＮａｍｅ”という形のバインディング構造によって参照することができる。
重要：型「ｓｙｓ：Ｄａｔａ」の仮パラメータについて、ＳｏｍｅＰａｒａｍ＝“＄ＦｏｒｍａｌＤａｔａＰａｒａｍＮａｍｅ／ＳｏｍｅＸＰａｔｈ”という形のバインディング構造を記述することが可能である。ＳｏｍｅＸＰａｔｈは、有効な相対位置でなければならない。
重要：パラメータの型およびパラメータがバインドされる仮パラメータの型は、一致しなければならない。
重要：タグ定義の本体内のエンティティの名前およびタグ定義への仮パラメータの名前は、同一であってはならない。
これは、ローカル変数による仮パラメータのシャドウイング（shadowing）を許容しないことと同等である。以下のように記述することは、不正である。
ＴａｂｌｅＷｉｔｈＣａｐｔｉｏｎタグの実際のインスタンス化は、以下のようなものとすることができる。
ＴａｂｌｅＷｉｔｈＣａｐｔｉｏｎなどの抽象化を作成するときの一般的なシナリオは、いくつかのパラメータについてデフォルト値を設けることである。タグ定義は、そのようなデフォルト値を指定するための備えを有する。このケースでは、Ｃａｐｔｉｏｎパラメータが、オプションとして指定され、文字列「Ｒｅｓｕｌｔｓ」をデフォルトとする。
「ＴａｂｌｅＷｉｔｈＣａｐｔｉｏｎ」のインスタンス化は、もはやＣａｐｔｉｏｎを必要としない。
デフォルトが文字列ではない場合、デフォルトの宣言には、インラインエンティティタグが含まれることになる。例えば、
（編集を可能にするためのバインディングの使用）
＜ｓｙｓ：ＩｎｌｉｎｅＤａｔａ＞でＷｒｉｔａｂｌｅ属性を設定することによって、Ｉｎｌｉｎｅ Ｄａｔａエンティティが書き込み可能になる。
＜ｓｙｓ：ＩｎｌｉｎｅＤａｔａ＞でＷｒｉｔａｂｌｅ属性を設定することによって、Ｉｎｌｉｎｅ Ｄａｔａエンティティが書き込み可能になる。
重要：Ｗｒｉｔａｂｌｅは、実際には定数パラメータであり、したがって、データバインドすることができず、静的な値を使用して表されなければならない。
以下の例に、ＸＡＤ内の「スクラッチパッド」として書き込み可能なＩｎｌｉｎｅ Ｄａｔａエンティティの簡単な使用を示す。
Ｔｅｘｔが最初に表示されるとき、表示されるテキストは、Ｉｎｌｉｎｅ Ｄａｔａエンティティの初期値、すなわち、
Ｂｙｅ
である。
Ｂｙｅ
である。
「ＭｏｕｓｅＬｅｆｔＢｕｔｔｏｎＤｏｗｎ」は、型「ｓｙｓ：ＥｖｅｎｔＨａｎｄｌｅｒ」のパラメータである。「ＭｏｕｓｅＬｅｆｔＢｕｔｔｏｎＤｏｗｎ」パラメータに対応するアクション（Ｐａｒａｍ＝“ＭｏｕｓｅＬｅｆｔＢｕｔｔｏｎＤｏｗｎ”によって表される）は、このＴｅｘｔエンティティが左マウスダウンイベントに出会うときに必ず呼び出される。このケースでは、ＳｅｔＴｅｘｔＶａｌｕｅＡｃｔｉｏｎが、呼び出され、Ｉｎｌｉｎｅ Ｄａｔａエンティティの＜Ｇｒｅｅｔｉｎｇ＞要素のテキスト値を変更する。これは、ＳｅｔＴｅｘｔＶａｌｕｅＡｃｔｉｏｎが、Ｄａｔａ（Ｄａｔａ＝“＄ＳｃｒａｔｃｈＰａｄ”によって表される）パラメータを介してＩｎｌｉｎｅ Ｄａｔａエンティティにバインドされているからである。要約すると、Ｔｅｘｔによって受け取られた左マウスダウンイベントは、Ｔｅｘｔが
Ｃｉａｏ
を表示することをもたらす。
Ｃｉａｏ
を表示することをもたらす。
同様に、右マウスダウンイベントは、Ｔｅｘｔが
Ａｕ Ｒｅｖｏｉｒ
を表示することをもたらす。
Ａｕ Ｒｅｖｏｉｒ
を表示することをもたらす。
書き込み可能データへのアクションのバインディングは、ＸＡＤにおいて編集可能性を達成する一般的な方法である。
テーブルへの新しい行の挿入を伴う、わずかに異なる以下のシナリオを検討する。
ＣＤｓ．ｘｍｌが、
を含む場合には、当初に表示されるテーブルは、次のように見える：
Ａｃｈｔｕｎｇ Ｂａｂｙ Ｕ２ １９．９９
Ｆｉｒｅｓｔａｒｔｅｒ Ｐｒｏｄｉｇｙ ２１．９９
Ａｃｈｔｕｎｇ Ｂａｂｙ Ｕ２ １９．９９
Ｆｉｒｅｓｔａｒｔｅｒ Ｐｒｏｄｉｇｙ ２１．９９
Ｔａｂｌｅが右マウスダウンイベントを受け取るときに、ＡｐｐｅｎｄＳｉｂｌｉｎｇＴｒｅｅＡｃｔｉｏｎが、呼び出され、そのＴｒｅｅ属性について指定された値を、そのＳｉｂｌｉｎｇパラメータによって提供されるノードに追加する。これが発生した後に、ツリーは、以下のようになる：
ツリーへの更新のために、テーブル表示が自動的に更新され、その結果、テーブル表示は、以下のように見えるようになる：
Ａｃｈｔｕｎｇ Ｂａｂｙ Ｕ２ １９．９９
Ｆｉｒｅｓｔａｒｔｅｒ Ｐｒｏｄｉｇｙ ２１．９９
？ ？ ０．００
Ａｃｈｔｕｎｇ Ｂａｂｙ Ｕ２ １９．９９
Ｆｉｒｅｓｔａｒｔｅｒ Ｐｒｏｄｉｇｙ ２１．９９
？ ？ ０．００
（Ｍａｉｎタグ）
上記のカノニカルなＨｅｌｌｏ Ｗｏｒｌｄの例で見られるように、Ｘａｄアプリケーションのエントリポイントは、ＣアプリケーションまたはＣ＃アプリケーションのＭａｉｎ関数に似ている。Ｘａｄ設計時シェルすなわちＸａｄ．ｅｘｅが動作するときに、Ｘａｄ．ｅｘｅは、「Ｍａｉｎ」ＴａｇＤｅｆｉｎｉｔｉｏｎ、すなわち、Ｎａｍｅ＝“ｓｙｓ：Ｍａｉｎ”を有するタグを探し、これをアプリケーションのエントリポイントとして使用する。
上記のカノニカルなＨｅｌｌｏ Ｗｏｒｌｄの例で見られるように、Ｘａｄアプリケーションのエントリポイントは、ＣアプリケーションまたはＣ＃アプリケーションのＭａｉｎ関数に似ている。Ｘａｄ設計時シェルすなわちＸａｄ．ｅｘｅが動作するときに、Ｘａｄ．ｅｘｅは、「Ｍａｉｎ」ＴａｇＤｅｆｉｎｉｔｉｏｎ、すなわち、Ｎａｍｅ＝“ｓｙｓ：Ｍａｉｎ”を有するタグを探し、これをアプリケーションのエントリポイントとして使用する。
一般的な命令言語との類似性について続けると、ｓｙｓ：Ｍａｉｎタグ定義を、コマンドライン値を用いてパラメータ化することができる。さらに、ｓｙｓ：Ｍａｉｎタグ定義は、アプリケーションの実行時に値を自動的に提供される３つの予め定義された値を公開する。
（自動投入されるＰａｒａｍ）
３つの名前がｓｙｓ：Ｍａｉｎパラメータタグのために予約されており、その名前は、ＸａｄＢａｓｅＤｉｒｅｃｔｏｒｙ、ＩｎｉｔｉａｌＷｏｒｋｉｎｇＤｉｒｅｃｔｏｒｙ、およびＭｅｔａｄａｔａである。これらの各々が、公開され、同一の形でバインドされる。さらに、これらの各々は、読み取り専用である。以下では、ＸａｄＢａｓｅＤｉｒｅｃｔｏｒｙパラメータを使用する例を提示する。
３つの名前がｓｙｓ：Ｍａｉｎパラメータタグのために予約されており、その名前は、ＸａｄＢａｓｅＤｉｒｅｃｔｏｒｙ、ＩｎｉｔｉａｌＷｏｒｋｉｎｇＤｉｒｅｃｔｏｒｙ、およびＭｅｔａｄａｔａである。これらの各々が、公開され、同一の形でバインドされる。さらに、これらの各々は、読み取り専用である。以下では、ＸａｄＢａｓｅＤｉｒｅｃｔｏｒｙパラメータを使用する例を提示する。
ＸａｄＢａｓｅＤｉｒｅｃｔｏｒｙは、そのＢａｓｅＵｒｉパラメータの値として、ＸｍｌＦｉｌｅＤａｔａＳｏｕｒｃｅと関連させて一般的に使用される。以下のＸａｄを検討する。
ＢａｓｅＵｒｉの値として＄ＸａｄＢａｓｅＤｉｒｅｃｔｏｒｙを使用することは、ＤａｔａＳｏｕｒｃｅに関連付けられたファイルが、Ｘａｄ．ｅｘｅすなわちＸａｄアプリケーション用の設計時シェルに渡されるファイルの位置で探されることを示すものである。したがって、ｆｏｏ．ｘａｄが、アプリケーションであり、Ｃ：＼ｘａｆ＼ｄｅｍｏｓ＼ｐｅｒｓｏｎａｌ＼にある場合には、ＸａｄＢａｓｅＤｉｒｅｃｔｏｒｙは、Ｃ：＼ｘａｆ＼ｄｅｍｏｓ＼ｐｅｒｓｏｎａｌと等しくなり、Ｆｉｌｅによって定義されるファイルは、そのディレクトリパス内で検索されることになる。
以下では、３つの予約済みパラメータの自動投入される値を定義する：
・ＸａｄＢａｓｅＤｉｒｅｃｔｏｒｙ − Ｘａｄ．ｅｘｅが起動された位置ではなく、アプリケーションのＸａｄベースディレクトリ、すなわち、アプリケーションがあるディレクトリから起動された当該ディレクトリを示した文字列；
・ＩｎｉｔｉａｌＷｏｒｋｉｎｇＤｉｒｅｃｔｏｒｙ − Ｘａｄ．ｅｘｅが起動された位置ではなく、アプリケーションの初期作業ディレクトリ、すなわち、アプリケーションがあるディレクトリから起動された当該ディレクトリを示した文字列；
・Ｍｅｔａｄａｔａ − アプリケーションに現在関連付けられているすべてのロードされたアセンブリのマージされたメタデータのツリー。
・ＸａｄＢａｓｅＤｉｒｅｃｔｏｒｙ − Ｘａｄ．ｅｘｅが起動された位置ではなく、アプリケーションのＸａｄベースディレクトリ、すなわち、アプリケーションがあるディレクトリから起動された当該ディレクトリを示した文字列；
・ＩｎｉｔｉａｌＷｏｒｋｉｎｇＤｉｒｅｃｔｏｒｙ − Ｘａｄ．ｅｘｅが起動された位置ではなく、アプリケーションの初期作業ディレクトリ、すなわち、アプリケーションがあるディレクトリから起動された当該ディレクトリを示した文字列；
・Ｍｅｔａｄａｔａ − アプリケーションに現在関連付けられているすべてのロードされたアセンブリのマージされたメタデータのツリー。
以下のＸａｄアプリケーションは、３つすべてのパラメータの使用を示す。
重要：自動投入されるｍａｉｎパラメータの各々は、読み取り専用であり、したがって、アプリケーションによってランタイムに変更することはできない。
（コマンドラインパラメータ化）
予約済みの自動投入されるｓｙｓ：Ｍａｉｎに加えて、アプリケーションは、ｓｙｓ：Ｍａｉｎのパラメータと異なる名前を有する任意の数のパラメータを指定することができる。これらのパラメータは、コマンドラインに基づいてパラメータ化され、すべての形のアプリケーション構成について使用することができる。以下のＸａｄは、ｓｙｓ：Ｍａｉｎパラメータの指定と、その後その値を提供するコマンドラインの指定との例を提供する。
予約済みの自動投入されるｓｙｓ：Ｍａｉｎに加えて、アプリケーションは、ｓｙｓ：Ｍａｉｎのパラメータと異なる名前を有する任意の数のパラメータを指定することができる。これらのパラメータは、コマンドラインに基づいてパラメータ化され、すべての形のアプリケーション構成について使用することができる。以下のＸａｄは、ｓｙｓ：Ｍａｉｎパラメータの指定と、その後その値を提供するコマンドラインの指定との例を提供する。
．．．コマンドライン．．．
xad CommandLine.xad /TextData=Testing
．．．より一般的には．．．
xad <AppFile> [/<ParamName1>=<Value1>[/<ParamName2>=<Value2>[ ...]]] [Switches]
．．．これは、以下のアプリケーションをもたらす．．．
xad CommandLine.xad /TextData=Testing
．．．より一般的には．．．
xad <AppFile> [/<ParamName1>=<Value1>[/<ParamName2>=<Value2>[ ...]]] [Switches]
．．．これは、以下のアプリケーションをもたらす．．．
（コマンドラインパラメータに渡される値は、単純なテキストである必要はなく、ファイル名、イメージ位置などとすることができる）。
（無視されるブロック）
ＸａｄがＸｍｌベースの言語であることを想起されたい。より具体的には、Ｘａｄコードは、「有効なＸｍｌでなければならない」。これは、Ｘａｄアプリケーションの開発を試みるときの興味深い制限、すなわち、「コメントアウトし、コーディングする（comment-out and code）」という手法を作り出す。明瞭にするために、Ｘｍｌは、コメントのネストをサポートせず、例えば、以下のＸｍｌは不正である。
ＸａｄがＸｍｌベースの言語であることを想起されたい。より具体的には、Ｘａｄコードは、「有効なＸｍｌでなければならない」。これは、Ｘａｄアプリケーションの開発を試みるときの興味深い制限、すなわち、「コメントアウトし、コーディングする（comment-out and code）」という手法を作り出す。明瞭にするために、Ｘｍｌは、コメントのネストをサポートせず、例えば、以下のＸｍｌは不正である。
したがって、Ｃ＋＋またはＣ＃などの命令言語と異なって、コメントにコメントすることは、そのような動作をサポートする特殊な構文がなければＸａｄでは不可能であり、この機能は、ｓｙｓ：ＩｇｎｏｒｅｄＢｌｏｃｋという名前のタグの形で現れ、以下のように定義される。
ＩｇｎｏｒｅｄＢｌｏｃｋタグは、残りのＸａｄが有効である限り、＜ｓｙｓ：Ｘａｄ＞スコープの下のどこにでも存在することができる。以下のことを検討する。
Ｘａｄコメントタグは、これらの要素のいずれの回りにもラップすることができない。というのは、これらのすべてが、有効なＸａｄアプリケーションに必須であるからである。
ＩｇｎｏｒｅｄＢｌｏｃｋの最初の出現は、それ自体およびその子をＸａｄチェッカによって無視させる。以下の有効なＸａｄを検討する。
以下のＩｇｎｏｒｅｄＢｌｏｃｋタグを追加すると、
これが無効なＸｍｌになり、このケースでは無効なＸａｄになる。したがって、Ｘａｄチェッカは、無効なＸｍｌに関するエラーをレポートする。というのは、さらなるチェックが実行される前に、Ｘａｄは有効なＸｍｌでなければならないからである。
＜ｓｙｓ：ＩｇｎｏｒｅｄＢｌｏｃｋ＞のネストは、ネストがＸｍｌの妥当性を保つ限り、許容される。
＜ｓｙｓ：ＩｇｎｏｒｅｄＢｌｏｃｋ＞の外側のＸｍｌコメントを示す以下のＸａｄを検討する。
これは、１つの大きいＸｍｌコメントとして扱われる、すなわち、ＩｇｎｏｒｅｄＢｌｏｃｋは、ここでは特別な機能を持たず、Ｘｍｌコメントの内側の単なる文字列である。
Ｘｍｌコメントをラップする＜ｓｙｓ：ＩｇｎｏｒｅｄＢｌｏｃｋ＞の外側のＸｍｌコメントを検討する。
これは不正である。上記にて注記したように、Ｘａｄは、必ず有効なＸｍｌでなければならない。定義により、Ｘｍｌコメントをコメント内にラップすることができないことを想起されたい。
Ｘｍｌコメントと異なって、＜ｓｙｓ：ＩｇｎｏｒｅｄＢｌｏｃｋ＞は、無効なＸｍｌをエスケープするのに使用することはできない。
上記のＸａｄは、無効なＸｍｌに関するチェッキングエラーを返すはずである。＜ＦＰ＞、＜Ａ＞、および＜Ｂ＞には、クロージングタグがない。
しかし、Ｘｍｌコメントを追加する場合には、これは問題がない。
重要：「内側のＩｇｎｏｒｅ」すなわち属性を無視する機能は、サポートされない。
ＩｇｎｏｒｅｄＢｌｏｃｋタグは、ｓｙｓ：ＩｎｌｉｎｅＤａｔａの内部をコメントアウトするのに使用することはできない。以下のＸａｄを検討する。
上記のコードは、「インラインデータ」と解釈され、＜ＥＦＧ＞＜／ＥＦＧ＞は無視されず、実際に、＜ｓｙｓ：ＩｇｎｏｒｅｄＢｌｏｃｋ＞は、＜ＥＦＧ＞の親になる。したがって、このインラインデータは、実際に、以下のように考えることで、より簡単なデータを定義している。
（アウトパラメータ）
＄ＴＯＤＯ − これはＭ３で詳細に説明される。
＄ＴＯＤＯ − これはＭ３で詳細に説明される。
（ホワイトスペース）
Ｘａｄアプリケーションに入ってくるすべてのデータは、データバインディングによって指定されるものであれ、Ｘａｄ作成者によって静的に定義されるものであれ、「そのままで」扱われる。したがって、Ｘａｄは、ホワイトスペースを制御するためのＵＩコンポーネント固有コントロールを一切公開しない。これは、Ｘａｍｌと異なって、我々がＵＩ要素レベルでｘｍｌ：ｓｐａｃｅ＝“Ｐｒｅｓｅｒｖｅ｜Ｄｅｆａｕｌｔ”を公開しないことを意味する。これは、ＸａｄおよびＸａｍｌの不一致の領域である。
Ｘａｄアプリケーションに入ってくるすべてのデータは、データバインディングによって指定されるものであれ、Ｘａｄ作成者によって静的に定義されるものであれ、「そのままで」扱われる。したがって、Ｘａｄは、ホワイトスペースを制御するためのＵＩコンポーネント固有コントロールを一切公開しない。これは、Ｘａｍｌと異なって、我々がＵＩ要素レベルでｘｍｌ：ｓｐａｃｅ＝“Ｐｒｅｓｅｒｖｅ｜Ｄｅｆａｕｌｔ”を公開しないことを意味する。これは、ＸａｄおよびＸａｍｌの不一致の領域である。
各ＵＩ要素、Ｄａｔａ Ｓｏｕｒｃｅ、Ｔｒａｎｓｆｏｒｍなどで「ホワイトスペースを保存する」というパラメータをサポートしないことを選択することによって、Ｏｆｆｉｃｅクラスアプリケーションにアピールすることが可能になる。このタイプのホワイトスペース管理は、単純にＯｆｆｉｃｅクラスアプリケーションには非現実的である。その代わりに、我々は、ホワイトスペースがどのように扱われるかをＸａｄ作成者がよりグローバル／データ駆動の形で定義することを可能にするＷｈｉｔｅｓｐａｃｅＴｒａｎｓｆｒｏｍ（一時的な名前、ＭＭ３機能）を公開する。
以下のシナリオを検討する。
すべてのホワイトスペースを、そのままで扱う。これは、以下のＸａｄがある場合に、
これが
「Ｓｔｅｖｅ 」
として現れることを意味する。
「Ｓｔｅｖｅ 」
として現れることを意味する。
同様に、
これは、
「 Ｓｔｅｖｅ」
として現れる。
「 Ｓｔｅｖｅ」
として現れる。
同様に、
これは、
「 Ｓ ｔ ｅ ｖ ｅ 」
として現れる。
「 Ｓ ｔ ｅ ｖ ｅ 」
として現れる。
また
<Text Text=“$foo” />
ただし、＄ｆｏｏ＝“ Ｓｔｅｖｅ ”である。
（＄ｆｏｏの値のすべての導出について繰り返す）。
<Text Text=“$foo” />
ただし、＄ｆｏｏ＝“ Ｓｔｅｖｅ ”である。
（＄ｆｏｏの値のすべての導出について繰り返す）。
重要：我々は、ＤａｔａＣｏｎｎｅｃｔｏｒに読み込まれるＸｍｌデータ、および一般にＳｙｓｔｅｍ．Ｘｍｌ規約に従って読み込まれるすべてのＸｍｌデータに対するｘｍｌ：ｓｐａｃｅ＝“Ｐｒｅｓｅｒｖｅ｜Ｄｅｆａｕｌｔ”を、（Ｓｙｓｔｅｍ．Ｘｍｌに従って）認識し／サポートする。
重要：ＭＭ３では、ＷｈｉｔｅｓｐａｃｅＴｒａｎｓｆｏｒｍのサポートを追加する。
（構造体）
ＸＡＤ内の構造体の不存在によって、アプリケーション機能をまったく排除されない。しかし、構造体は、大きいＸＡＤアプリケーションに関する複数の作成ワークフローを単純化する。トップレベルで定義された１つのアクション（Ｓａｖｅ）および３つの状態（Ｒｅｃｅｎｔ Ｄｏｃｕｍｅｎｔｓ、Ｕｓｅｒ Ｐｒｅｆｅｒｅｎｃｅｓ、およびＥｎｔｅｒｐｒｉｓｅ Ｐｒｅｆｅｒｅｎｃｅｓ）を有するアプリケーションを検討する。このアプリケーションが、複数のペイン（型「ｆｗｋ：ＵＩＥｌｅｍｅｎｔ」の派生タグとしてモデル化される）を有する場合、問題は、以下の通りである：
１．各パラメータを、各ペインに明示的に渡さなければならない（ＸＱｕｅｒｙを介するデータパラメータの集約は、データパラメータの数を減らすのに使用することはできるが、非データパラメータについては助けにならない）；
２．余分なアクション（例えば、Ｐｒｉｎｔ）の追加は、各ペインへの新しいパラメータの追加を必要とする（ペインがパラメータグループを共有するように設計されている場合に、各ペインのタグ定義の変更を回避できることに留意されたい。しかし、それでも、すべてのペインインスタンスを更新する必要がある）；
３．ネストされたカテゴリによってパラメータをグループ化する機構がない（古典的ＯＯでは、プロパティが他のクラスであるクラスによって達成される。ＸＡＦではコネクタインターフェースを介して達成される）。
ＸＡＤ内の構造体の不存在によって、アプリケーション機能をまったく排除されない。しかし、構造体は、大きいＸＡＤアプリケーションに関する複数の作成ワークフローを単純化する。トップレベルで定義された１つのアクション（Ｓａｖｅ）および３つの状態（Ｒｅｃｅｎｔ Ｄｏｃｕｍｅｎｔｓ、Ｕｓｅｒ Ｐｒｅｆｅｒｅｎｃｅｓ、およびＥｎｔｅｒｐｒｉｓｅ Ｐｒｅｆｅｒｅｎｃｅｓ）を有するアプリケーションを検討する。このアプリケーションが、複数のペイン（型「ｆｗｋ：ＵＩＥｌｅｍｅｎｔ」の派生タグとしてモデル化される）を有する場合、問題は、以下の通りである：
１．各パラメータを、各ペインに明示的に渡さなければならない（ＸＱｕｅｒｙを介するデータパラメータの集約は、データパラメータの数を減らすのに使用することはできるが、非データパラメータについては助けにならない）；
２．余分なアクション（例えば、Ｐｒｉｎｔ）の追加は、各ペインへの新しいパラメータの追加を必要とする（ペインがパラメータグループを共有するように設計されている場合に、各ペインのタグ定義の変更を回避できることに留意されたい。しかし、それでも、すべてのペインインスタンスを更新する必要がある）；
３．ネストされたカテゴリによってパラメータをグループ化する機構がない（古典的ＯＯでは、プロパティが他のクラスであるクラスによって達成される。ＸＡＦではコネクタインターフェースを介して達成される）。
このシナリオを、さらに明瞭にするために、以下に図に示す。
例示のために、まず、（最初の２つの問題に対処するため、）「単一レベルの構造体」を説明し、次に、（３番目の問題に対処するため、）「ネストされた構造体」に一般化する。実際には、「構造体」である１つの集合的特徴だけが存在する。
（単一レベルの構造体）
以下のＸＡＤは、構造体のシグネチャを記述するために記述される。
以下のＸＡＤは、構造体のシグネチャを記述するために記述される。
重要：構造体に適切なシグネチャは、（１）ｓｙｓ：Ｏｂｊｅｃｔと等しい型を有さなければならず、（２）アウトパラメータだけを含まなければならず、（３）チョイスすなわち＜ｓｙｓ：Ｃｈｏｉｃｅ＞を含むことができず、（４）Ｓｉｇｎａｔｕｒｅという名前のＯｕｔＰａｒａｍを有することができない。
「ａｐｐ：ＡｃｔｉｏｎｓＡｎｄＤａｔａＳｉｇｎａｔｕｒｅ」シグネチャを使用する構造体の例は、以下のようになる。
重要：構造体パラメータは、すべてインライン、すべてバインドされる、またはインラインおよびバインドされる組合せとして指定されなければならない。
重要：シグネチャを伴うパラメータは、同一のシグネチャを伴う値だけをとることができる。同一の型では不十分である。同一のことが、これらのパラメータのデフォルト値にもあてはまる。
重要：すべての構造体パラメータには、値が割り当てられなければならない。
構造体をタグ定義内で使用することができ、その例を以下に示す。
ペインのインスタンスは、以下のようになる。
本体内では、以下のバインディングが、型「ｓｙｓ：ＥｖｅｎｔＨａｎｄｌｅｒ」のすべてのパラメータについて有効になる：
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．ＰｒｉｎｔＡｃｔｉｏｎ」；
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．ＳａｖｅＡｃｔｉｏｎ」。
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．ＰｒｉｎｔＡｃｔｉｏｎ」；
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．ＳａｖｅＡｃｔｉｏｎ」。
本体内では、以下のバインディングが、型「ｓｙｓ：Ｄａｔａ」のすべてのパラメータについて有効になる：
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．ＲｅｃｅｎｔＤｏｃｕｍｅｎｔｓ」；
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．ＵｓｅｒＰｒｅｆｅｒｅｎｃｅｓ」；
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．ＥｎｔｅｒｐｒｉｓｅＰｒｅｆｅｒｅｎｃｅｓ」。
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．ＲｅｃｅｎｔＤｏｃｕｍｅｎｔｓ」；
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．ＵｓｅｒＰｒｅｆｅｒｅｎｃｅｓ」；
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．ＥｎｔｅｒｐｒｉｓｅＰｒｅｆｅｒｅｎｃｅｓ」。
例えば、ユーザプリファレンスが、以下の形のデータツリーによってモデル化される場合、
「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．ＵｓｅｒＰｒｅｆｅｒｅｎｃｅｓ／ＡｕｔｏＳａｖｅＦｒｅｑｕｅｎｃｙ」を介してＡｕｔｏ Ｓａｖｅ Ｆｒｅｑｕｅｎｃｙ設定にバインドすることが可能となることに留意されたい。
本体内で、以下のバインディングは、シグネチャ「ａｐｐ：ＡｃｔｉｏｎｓＡｎｄＤａｔａＳｉｇｎａｔｕｒｅ」のすべてのパラメータ（通常は、アプリケーションのアクションおよびプリファレンスにアクセスする必要がある他の派生タグへのパラメータ）について有効になる：
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ」。
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ」。
（ネストされた構造体）
ネストされた構造体（単純に、単一レベルの構造体の一般化）を使用して、同一のシナリオを解決することができる。
ネストされた構造体（単純に、単一レベルの構造体の一般化）を使用して、同一のシナリオを解決することができる。
本体内では、以下のバインディングが、型ｓｙｓ：ＥｖｅｎｔＨａｎｄｌｅｒのすべてのパラメータについて有効になる：
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．Ａｃｔｉｏｎｓ．Ｐｒｉｎｔ」；
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．Ａｃｔｉｏｎｓ．Ｓａｖｅ」。
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．Ａｃｔｉｏｎｓ．Ｐｒｉｎｔ」；
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．Ａｃｔｉｏｎｓ．Ｓａｖｅ」。
本体内では、以下のバインディングが、型ｓｙｓ：Ｄａｔａのすべてのパラメータについて有効になる：
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．ＲｅｃｅｎｔＤｏｃｕｍｅｎｔｓ」；
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．Ｐｒｅｆｅｒｅｎｃｅｓ．Ｕｓｅｒ」；
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．Ｐｒｅｆｅｒｅｎｃｅｓ．Ｅｎｔｅｒｐｒｉｓｅ」。
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．ＲｅｃｅｎｔＤｏｃｕｍｅｎｔｓ」；
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．Ｐｒｅｆｅｒｅｎｃｅｓ．Ｕｓｅｒ」；
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．Ｐｒｅｆｅｒｅｎｃｅｓ．Ｅｎｔｅｒｐｒｉｓｅ」。
本体内では、以下のバインディングが、Ｓｉｇｎａｔｕｒｅ ａｐｐ：ＡｃｔｉｏｎｓＡｎｄＤａｔａＳｉｇｎａｔｕｒｅのすべてのパラメータ（通常は、アプリケーションのアクションおよびプリファレンスにアクセスする必要がある他の派生タグへのパラメータ）について有効になる：
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ」。
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ」。
本体内では、以下のバインディングが、Ｓｉｇｎａｔｕｒｅ ａｐｐ：ＡｃｔｉｏｎｓＳｉｇｎａｔｕｒｅのすべてのパラメータ（通常は、アプリケーションのアクションだけにアクセスする必要がある他の派生タグへのパラメータ）について有効になる：
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．Ａｃｔｉｏｎｓ」。
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．Ａｃｔｉｏｎｓ」。
本体内では、以下のバインディングが、Ｓｉｇｎａｔｕｒｅ ａｐｐ：ＰｒｅｆｅｒｅｎｃｅｓＳｉｇｎａｔｕｒｅのすべてのパラメータ（通常は、アプリケーションのプリファレンスだけにアクセスする必要がある他の派生タグへのパラメータ）について有効になる：
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．Ｐｒｅｆｅｒｅｎｃｅｓ」。
・「＄ＡｃｔｉｏｎｓＡｎｄＤａｔａ．Ｐｒｅｆｅｒｅｎｃｅｓ」。
（スタイル）
Ａｖａｌｏｎスタイルの主な用途は、
・特定の要素のプロパティ値のデフォルトを指定すること；
・特定の要素の下のビジュアルツリーの外見のデフォルトを指定すること；
・特定の要素に関する入力応答（ビジュアルトリガ）のデフォルトを指定すること；
・コントロールの繰り返される子をどのように表示するかを指定すること
である。
Ａｖａｌｏｎスタイルの主な用途は、
・特定の要素のプロパティ値のデフォルトを指定すること；
・特定の要素の下のビジュアルツリーの外見のデフォルトを指定すること；
・特定の要素に関する入力応答（ビジュアルトリガ）のデフォルトを指定すること；
・コントロールの繰り返される子をどのように表示するかを指定すること
である。
これらは、以下の３つのカテゴリに分類される：
１．我々がＳＤＫ１に包含するスタイルの諸態様。我々は、さらに、ＸＡＭＬモデルを一般化し、ＸＡＤ固有の概念（例えば、派生タグ）に適用可能にすることによって価値を追加する。構文は、必ずしも同一ではなくなるが、一致の領域としての資格を有するのに十分に近い。例えば、プロパティ値のデフォルト指定；
２．実質的な設計なしで一般化された形に包含することが困難なスタイルの諸態様。これらは、価値があり、我々がなんとかしてＳＤＫ１の後に包含する必要がある態様である。例えば、ビジュアルツリーおよびビジュアルトリガ；
３．現在設計されているままでは脆弱であり、「Ｏｆｆｉｃｅグレードアプリケーション」の作成のためにスケーリングされる可能性が低いスタイルの諸態様。これらは、好ましいＸＡＤ手法によって対処される。例えば、繰り返される子の表示。さらに、我々は、互換性のためにＸＡＭＬ手法をサポートする可能性があるが、これらの判断は、ＳＤＫ１の後で行われる。
１．我々がＳＤＫ１に包含するスタイルの諸態様。我々は、さらに、ＸＡＭＬモデルを一般化し、ＸＡＤ固有の概念（例えば、派生タグ）に適用可能にすることによって価値を追加する。構文は、必ずしも同一ではなくなるが、一致の領域としての資格を有するのに十分に近い。例えば、プロパティ値のデフォルト指定；
２．実質的な設計なしで一般化された形に包含することが困難なスタイルの諸態様。これらは、価値があり、我々がなんとかしてＳＤＫ１の後に包含する必要がある態様である。例えば、ビジュアルツリーおよびビジュアルトリガ；
３．現在設計されているままでは脆弱であり、「Ｏｆｆｉｃｅグレードアプリケーション」の作成のためにスケーリングされる可能性が低いスタイルの諸態様。これらは、好ましいＸＡＤ手法によって対処される。例えば、繰り返される子の表示。さらに、我々は、互換性のためにＸＡＭＬ手法をサポートする可能性があるが、これらの判断は、ＳＤＫ１の後で行われる。
この文書では、我々がＳＤＫ１に包含する領域、すなわち、プロパティ値のデフォルト指定に焦点を合わせる。
（デフォルト指定のためのスタイル）
ＸＡＤエンジンは、リソースとして指定される、＜ｓｙｓ：Ｓｔｙｌｅ＞という名前の特殊なタグを処理する。このタグは、デフォルトパラメータ値の指定を可能にし、ＵＩエンティティに制限されない。以下は、デフォルト指定の例である。
ＸＡＤエンジンは、リソースとして指定される、＜ｓｙｓ：Ｓｔｙｌｅ＞という名前の特殊なタグを処理する。このタグは、デフォルトパラメータ値の指定を可能にし、ＵＩエンティティに制限されない。以下は、デフォルト指定の例である。
これは、別のデフォルトスタイルがＴｅｘｔＢｏｘに関して指定されない限り、ＸＡＤエンジンが、ＴｅｘｔＢｏｘを作成するときに以下のことを行うことを意味する：
・明示的なＷｉｄｔｈが指定されない場合に限り、Ｗｉｄｔｈに１００％を設定し、
・明示的なＨｅｉｇｈｔが指定されない場合に限り、Ｈｅｉｇｈｔに１００％を設定し、
・明示的なＢａｃｋｇｒｏｕｎｄが指定されない場合に限り、Ｂａｃｋｇｒｏｕｎｄにべた塗り赤ブラシ（solid red brush）を設定する。
・明示的なＷｉｄｔｈが指定されない場合に限り、Ｗｉｄｔｈに１００％を設定し、
・明示的なＨｅｉｇｈｔが指定されない場合に限り、Ｈｅｉｇｈｔに１００％を設定し、
・明示的なＢａｃｋｇｒｏｕｎｄが指定されない場合に限り、Ｂａｃｋｇｒｏｕｎｄにべた塗り赤ブラシ（solid red brush）を設定する。
重要：スタイルの影響の範囲は、厳密に階層的である、すなわち、上のスタイルは、エンティティツリー内でＤｏｃｋＰａｎｅｌの下に存在するエンティティだけに適用可能である。
「スタイル情報」は、ＸＡＤエンジンが既にリンクのために保存している階層環境と共に単純に記憶される。スタイルのルックアップは、ハッシュルックアップになり、ツリーのウォークアップを必要としない。我々は、ＸＡＤに対するランタイムアーティファクトがある（遅延処理スコープ）という事実を利用しているので、Ａｖａｌｏｎとは異なる。さらに、ビジュアルツリーのウォークを用いる手法は、デフォルト指定を厳密にＵＩエンティティに制限する。
スタイルをオフに切り替えることは、スタイル指定されるエンティティにおいてパラメータを指定しないようにすることによって達成することができる。以下は、ＴｅｘｔＢｏｘに関する以前のスタイル指定をすべて無効にする。
デフォルト指定は、派生タグに同等に適用可能である。
非ＵＩエンティティに適用されるデフォルト指定の例が、以下である。
これは、ＸｍｌＦｉｌｅＤａｔａＳｏｕｒｃｅのＡｃｃｅｓｓＭｏｄｅパラメータが明示的に指定されない場合に、このパラメータにＲｅａｄＯｎｌｙが設定されることを意味する。
必要なパラメータが、ＸＡＤ内で指定されなければならないことに留意されたい。例えばＸｍｌＦｉｌｅＤａｔａＳｏｕｒｃｅのＰａｔｈパラメータなど、必要なパラメータがスタイルによって設定されることに依存することは、可能ではない。この制限は、コンポジションを可能にするために存在する。スタイルの存在に依存することは、脆弱である。
さらに、型のレベルでデフォルトを指定することが可能になる。
これは、別のデフォルトスタイルがＵＩＥｌｅｍｅｎｔについて指定されない限り、ＸＡＤエンジンが、すべてのＵＩ Ｃｏｎｎｅｃｔｏｒを作成するときに以下のことを行うことを意味する：
・１．Ｗｉｄｔｈパラメータがサポートされ、
２．Ｗｉｄｔｈパラメータが明示的に指定されず、
３．対象とするＵＩ Ｅｌｅｍｅｎｔに固有のスタイル（例えば、ＴｅｘｔＢｏｘ固有スタイル）が指定されない場合に、
Ｗｉｄｔｈに１００％が設定される；
・Ｈｅｉｇｈｔについても同様；
・Ｂａｃｋｇｒｏｕｎｄについても同様。
・１．Ｗｉｄｔｈパラメータがサポートされ、
２．Ｗｉｄｔｈパラメータが明示的に指定されず、
３．対象とするＵＩ Ｅｌｅｍｅｎｔに固有のスタイル（例えば、ＴｅｘｔＢｏｘ固有スタイル）が指定されない場合に、
Ｗｉｄｔｈに１００％が設定される；
・Ｈｅｉｇｈｔについても同様；
・Ｂａｃｋｇｒｏｕｎｄについても同様。
２）我々は、正確な型の一致を要求すべきか、あるいは、我々は、さらに「最も近いＩｓＡｓｓｉｇｎａｂｌｅＦｒｏｍ」一致についてチェックすべきか？
スタイルに関する型チェックは、通常のＸＡＤに関するものより緩いものにする必要がある。具体的には、
・「型−スタイル」に対するパラメータ（例えば、上記の「ＵＩＥｌｅｍｅｎｔ」の例）は、各ＵＩＥｌｅｍｅｎｔがそれ自体のパラメータを導入できるので、チェックされない。型がシグネチャであり、したがって型がある種のパラメータを規定する場合には、これらのパラメータは、型チェックされる（これが可能であるのは、我々がＸＡＤにおいてパラメータのオーバーライドを許容しないからである）；
・スタイル内のアタッチドパラメータの値は、チェックされる、すなわち、ＤｏｃｋＰａｎｅｌ．Ｄｏｃｋ＝“Ｇａｒｂａｇｅ”は、許容されない。しかし、スタイル上で宣言されるアタッチドパラメータを記述することは可能である。例えば、スタイルが、ＤｏｃｋＰａｎｅｌの子ではないＴｅｘｔＢｏｘボックスに適用される可能性がある場合であっても、以下のことを記述することが可能である。
・「型−スタイル」に対するパラメータ（例えば、上記の「ＵＩＥｌｅｍｅｎｔ」の例）は、各ＵＩＥｌｅｍｅｎｔがそれ自体のパラメータを導入できるので、チェックされない。型がシグネチャであり、したがって型がある種のパラメータを規定する場合には、これらのパラメータは、型チェックされる（これが可能であるのは、我々がＸＡＤにおいてパラメータのオーバーライドを許容しないからである）；
・スタイル内のアタッチドパラメータの値は、チェックされる、すなわち、ＤｏｃｋＰａｎｅｌ．Ｄｏｃｋ＝“Ｇａｒｂａｇｅ”は、許容されない。しかし、スタイル上で宣言されるアタッチドパラメータを記述することは可能である。例えば、スタイルが、ＤｏｃｋＰａｎｅｌの子ではないＴｅｘｔＢｏｘボックスに適用される可能性がある場合であっても、以下のことを記述することが可能である。
３）我々は、アタッチドパラメータの概念をグローバルにしなければならない。これは、任意の場合のバブル化されたイベントのために、ＳＤＫ１後に必要になる。
ＸＡＭＬと同様に、我々は、「Ｓｔｙｌｅ」と呼ばれるすべてのエンティティ上の暗黙的なシステムレベルパラメータを介する特定のスタイルへのバインディングをサポートする。
しかし、このスタイルは、スコープ内にある必要がある。スコープ制限が、実際にはスタイルに固有であるのではなく、我々のスコープ付きバインディングモデルの結果であることに留意されたい。我々は、必要が生じた場合にＳｔｙｌｅｓなどのエンティティの特定の型へのグローバルバインディングをサポートすることができるが、とりあえず、我々は、スコープ付きモデルにどこまで取り組めるかを調べたい。実用的な応用例はないが、一貫性のために、以下のことを記述することが可能であることに留意されたい。
スタイルへのバインディングは、タイプセーフになる。その結果、以下の記述は、エラーをもたらす。
要約すると、我々は、スタイルを使用するデフォルト指定に関して、Ａｖａｌｏｎのモデルをサポートし、少数の領域で価値を追加する：
・デフォルト指定は、（ＵＩエンティティだけではなく、）すべてのエンティティに適用される；
・デフォルト指定は、（プリミティブタグだけではなく、）派生タグに適用される；
・デフォルト指定は、型のレベル、例えば、すべてのＵＩＥｌｅｍｅｎｔで行うことができる（Ａｖａｌｏｎは、これを最終的にサポートする可能性が非常に高い）。
型のレベルでのデフォルト指定は、ＳＤＫ１については実装されない。
・デフォルト指定は、（ＵＩエンティティだけではなく、）すべてのエンティティに適用される；
・デフォルト指定は、（プリミティブタグだけではなく、）派生タグに適用される；
・デフォルト指定は、型のレベル、例えば、すべてのＵＩＥｌｅｍｅｎｔで行うことができる（Ａｖａｌｏｎは、これを最終的にサポートする可能性が非常に高い）。
型のレベルでのデフォルト指定は、ＳＤＫ１については実装されない。
（Ａｖａｌｏｎのビジュアルツリーのスタイル指定）
この領域に関するＸＡＤ設計は、対応するＵＩ Ｃｏｎｎｅｃｔｏｒ設計と共に、ＳＤＫ１後に行われる。
この領域に関するＸＡＤ設計は、対応するＵＩ Ｃｏｎｎｅｃｔｏｒ設計と共に、ＳＤＫ１後に行われる。
（スタイル指定およびビジュアルトリガ）
この領域に関するＸＡＤ設計は、対応するＵＩ Ｃｏｎｎｅｃｔｏｒ設計と共に、ＳＤＫ１後に行われる。
この領域に関するＸＡＤ設計は、対応するＵＩ Ｃｏｎｎｅｃｔｏｒ設計と共に、ＳＤＫ１後に行われる。
（スコープ付きパラメータ）
一部のパラメータは、新しいスコープを導入する。新しいスコープを導入するパラメータでは、「ＮｅｗＳｃｏｐｅ」属性にｔｒｕｅが設定される。
一部のパラメータは、新しいスコープを導入する。新しいスコープを導入するパラメータでは、「ＮｅｗＳｃｏｐｅ」属性にｔｒｕｅが設定される。
パラメータは、以下の様々な理由のためにスコープを導入することを選択することができる：
・スコープ変数を導入するため；
・遅延される作業および／または繰り返される作業のユニットを導入するため；
・上記のすべて。
スコープ付き変数、ならびに遅延される作業および／または繰り返される作業の概念は、このセクションにおいて定義される。
・スコープ変数を導入するため；
・遅延される作業および／または繰り返される作業のユニットを導入するため；
・上記のすべて。
スコープ付き変数、ならびに遅延される作業および／または繰り返される作業の概念は、このセクションにおいて定義される。
スコープ付きパラメータに関連付けられたエンティティは、スコープ境界に存在する。パラメータによって、これらのエンティティは、スコープ境界に関連付けられ、スコープ境界を導入する。以下の図に、ネストされたスコープを導入するエンティティおよびグループ化タグが、スコープのツリーをどのようにもたらすかを示す。
（スコープ変数）
パラメータが新しいスコープを導入する理由の１つは、スコープ内の変数のセットを導入するためである。これらの変数は、暗黙的に宣言されることを除いて、仮パラメータに非常に似ている。スコープ付き変数へのバインディングは、仮パラメータにバインドするのと同一の形で行われる。
パラメータが新しいスコープを導入する理由の１つは、スコープ内の変数のセットを導入するためである。これらの変数は、暗黙的に宣言されることを除いて、仮パラメータに非常に似ている。スコープ付き変数へのバインディングは、仮パラメータにバインドするのと同一の形で行われる。
スコープ付き変数は、パラメータを導入するスコープの宣言と共に宣言される。例えば、以下のＴｅｘｔのタグ定義を検討する。
ｓｙｓ：ＰａｒａｍＧｒｏｕｐＲｅｆは、ｓｙｓ：ＰａｒａｍＧｒｏｕｐタグへの参照を定義し、これは、以下のようになる。
ＭｏｕｓｅＬｅｆｔＢｕｔｔｏｎＤｏｗｎという名前のｓｙｓ：Ｐａｒａｍの定義に留意されたい。これは、ＮｅｗＳｃｏｐｅと、Ｐｏｓｉｔｉｏｎ＿Ｘという名前のｓｙｓ：ＳｃｏｐｅＶａｒｉａｂｌｅとを指定する。
これは、ＭｏｕｓｅＬｅｆｔＢｕｔｔｏｎＤｏｗｎパラメータが使用されるときに、必ず、ＭｏｕｓｅＬｅｆｔＢｕｔｔｏｎＤｏｗｎが以下のことを行うことを示す：
１．新しいスコープを導入する、
２．Ｐｏｓｉｔｉｏｎ＿Ｘという名前のｓｙｓ：ＳｃｏｐｅＶａｒｉａｂｌｅを公開する。
１．新しいスコープを導入する、
２．Ｐｏｓｉｔｉｏｎ＿Ｘという名前のｓｙｓ：ＳｃｏｐｅＶａｒｉａｂｌｅを公開する。
スコープ付き変数のポイントは、以下のようなシナリオを可能にすることである。
このアプリケーションのＸａｄは、以下の通りである。
すべての例と同様に、このアプリケーションの機能の雰囲気をつかむために、ユーザがこのＸａｄを実行することが奨励される。
ＭｏｕｓｅＬｅｆｔＢｕｔｔｏｎＤｏｗｎに関連付けられたスコープ変数の使用を介して、我々は、左マウスダウンイベントが発生するたびに、オレンジ色の長方形の位置を更新することができる。さらに、以下のイベントコードを調べると、
ＭｏｕｓｅＬｅｆｔＢｕｔｔｏｎＤｏｗｎパラメータが、２つのスコープ変数、すなわち、Ｐｏｓｉｔｉｏｎ＿ＸおよびＰｏｓｉｔｉｏｎ＿Ｙを公開することがわかる。これらのスコープパラメータの値へのバインディングは、すべてのＸａｄバインディングと同一の形で行われる。
重要：スコープ内のエンティティは、スコープ変数と同一の名前を有することができない。
例えば、以下の記述は不正である。
というのは、Ｐｏｓｉｔｉｏｎ＿ＸがＭｏｕｓｅＬｅｆｔＢｕｔｔｏｎＤｏｗｎによって公開されているからである。
（リピータパターン）
リピータパターンは、様々なエンティティ型によって使用されるが、その使用法は、ＸＡＤ標準フレームワークに含まれるＣｏｍｐｏｕｎｄエンティティによって最もよく示される。データ駆動型複合エンティティは、データセットにバインドされ、そのデータセット内のデータ項目ごとに、サブ要素を表示する。ここまでで、我々は、複数の例においてＦｌｏｗＰａｎｅｌエンティティを使用してきた。ＦｌｏｗＰａｎｅｌエンティティは、実際には以下の２つのモードを有する：
・規定的（表示すべきサブエンティティは、Ｃｈｉｌｄｒｅｎパラメータとして明示的に指定される）；
・データ駆動型（このセクションにおいて定義されるリピータパターンを使用する）。
リピータパターンは、様々なエンティティ型によって使用されるが、その使用法は、ＸＡＤ標準フレームワークに含まれるＣｏｍｐｏｕｎｄエンティティによって最もよく示される。データ駆動型複合エンティティは、データセットにバインドされ、そのデータセット内のデータ項目ごとに、サブ要素を表示する。ここまでで、我々は、複数の例においてＦｌｏｗＰａｎｅｌエンティティを使用してきた。ＦｌｏｗＰａｎｅｌエンティティは、実際には以下の２つのモードを有する：
・規定的（表示すべきサブエンティティは、Ｃｈｉｌｄｒｅｎパラメータとして明示的に指定される）；
・データ駆動型（このセクションにおいて定義されるリピータパターンを使用する）。
ＦｌｏｗＰａｎｅｌエンティティの定義は、（ここまでの例で提案したように）Ｃｈｉｌｄｒｅｎパラメータだけを中心にしてはいない。そのタグ定義は、以下のように見える。
サブエンティティを規定的に指定するのではなく、ＤａｔａパラメータならびにＲｅｐｅａｔｅｄＣｈｉｌｄパラメータを指定することが可能である。これによって、ＦｌｏｗＰａｎｅｌエンティティが「データ駆動型」モードにされる。
ＦｌｏｗＰａｎｅｌタグ定義が、＜ｓｙｓ：Ｃｈｏｉｃｅ＞タグを使用し、これらのタグが、Ｃｈｉｌｄｒｅｎパラメータ（これによって、規定的レイアウトを定義する）、または、ＤａｔａおよびＲｅｐｅａｔｅｄＣｈｉｌｄの＜ｓｙｓ：ＰａｒａｍＧｒｏｕｐ＞を使用する間で選択するためのタグの何らかの実装を必要とすることに留意されたい。
重要：ＰａｒａｍＧｒｏｕｐは、すべてか無か（all-or-nothing）の形で使用されなければならないパラメータのセットを定義する。ＦｌｏｗＰａｎｅｌを調べると、作成者がＤａｔａの値を提供する場合、ＲｅｐｅａｔｅｄＣｈｉｌｄの値も提供しなければならない。
ＲｅｐｅａｔｅｄＣｈｉｌｄパラメータは、Ｄａｔａ内の項目ごとに複数回インスタンス化されるエンティティである。
重要：複数回インスタンス化されるすべてのエンティティは、新しいスコープ内に存在しなければならない。
ＲｅｐｅａｔｅｄＣｈｉｌｄパラメータによって導入されるスコープは、ＤａｔａＣｏｎｔｅｘｔという名前のスコープ変数を有する。この変数には、インスタンス化されるサブビューに対応する項目が設定される。
以下のスニペットに、データ駆動型の形でのＦｌｏｗＰａｎｅｌエンティティの使用法を示す。
Ｌｉｓｔ．ｘｍｌが、以下のＸｍｌを含むと仮定する。
リスト項目ごとに、ＦｌｏｗＰａｎｅｌエンティティはＴｅｘｔエンティティを作成する。最初のＴｅｘｔエンティティについて、ＤａｔａＣｏｎｔｅｘｔスコープ変数の値は、以下のようになる。
＄ＤａｔａＣｏｎｔｅｘｔ／＠Ｎａｍｅバインディングは、Ｎａｍｅ属性を作成する。Ｔｅｘｔは、属性にバインドされるときに、その属性の値を表示し、この値は、このケースでは「Ｃｈｒｉｓ Ｈａｃｋｍａｎｎ」である。
同一のことが、各リスト項目に適用可能である。ビューポートが十分に大きい場合に、ＦｌｏｗＰａｎｅｌエンティティは、スクリーンに以下を表示する。
各行は、１つのＴｅｘｔエンティティのインスタンス化に対応する。インスタンス化ごとに変化するのは、「ＤａｔａＣｏｎｔｅｘｔ」スコープ変数の値である。このパターンは、「リピータパターン」と呼ばれる。これは、ＸＡＤにおけるデータセットに対する反復の基礎となる。
＄ＤａｔａＣｏｎｔｅｘｔ／＠Ｎａｍｅバインディングは、ＤａｔａＣｏｎｔｅｘｔスコープ変数だけのために予約された特殊なショートハンド表記「．」（単一のドットまたはピリオド）のために、．／＠Ｎａｍｅと書き直すことができる。
重要：名前ＤａｔａＣｏｎｔｅｘｔは、スコープ変数のために予約済みである。
重要：スコープ変数がＤａｔａＣｏｎｔｅｘｔと命名される場合に、その変数は型ｓｙｓ：Ｄａｔａでなければならない。
重要：文字列をバインドする際の“＄ＤａｔａＣｏｎｔｅｘｔ”の出現は、ショートハンド「．」を使用して書き直すことができる。
（スコープに関連するバインディングの制限）
スコープは、ある種のバインディング制限を導入する。外部スコープから内部スコープへのバインディングは、「許可されない」。しかし、以下の図に示されているように、内部スコープから外部スコープへのバインディングは、「許可される」。
スコープは、ある種のバインディング制限を導入する。外部スコープから内部スコープへのバインディングは、「許可されない」。しかし、以下の図に示されているように、内部スコープから外部スコープへのバインディングは、「許可される」。
（ネストされたリピータパターン）
「リピータパターン」に関するセクションにおいて、データベースに対する単純な反復をどのように実現するかを示した。このセクションでは、より複雑なシナリオを検討する。
「リピータパターン」に関するセクションにおいて、データベースに対する単純な反復をどのように実現するかを示した。このセクションでは、より複雑なシナリオを検討する。
まず、以下の単純なデータセットを検討する。
この単純なデータセットの以下のビューを検討する：
Ｃｕｓｔｏｍｅｒ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｉｃｅ
Ｌｕｉｓ Ｆｉｇｏ Ｔｏａｓｔｅｒ ４９．９９
Ｌｕｉｓ Ｆｉｇｏ ＶＣＲ １９９．９９
このビューは、Ｔａｂｌｅエンティティを用いて簡単に達成できるが、例示のために、ＦｌｏｗＰａｎｅｌエンティティおよびＴｅｘｔエンティティだけにとどめる。
Ｃｕｓｔｏｍｅｒ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｉｃｅ
Ｌｕｉｓ Ｆｉｇｏ Ｔｏａｓｔｅｒ ４９．９９
Ｌｕｉｓ Ｆｉｇｏ ＶＣＲ １９９．９９
このビューは、Ｔａｂｌｅエンティティを用いて簡単に達成できるが、例示のために、ＦｌｏｗＰａｎｅｌエンティティおよびＴｅｘｔエンティティだけにとどめる。
命令言語に満足している人にとって、反復態様だけを、おおむね以下のようにモデル化することができる。
ここで、以下のわずかにより複雑なデータセットを検討する。
このより複雑なデータセットの以下のビューを検討する：
Ｃｕｓｔｏｍｅｒ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｉｃｅ
Ｌｕｉｓ Ｆｉｇｏ Ｔｏａｓｔｅｒ ４９．９９
Ｌｕｉｓ Ｆｉｇｏ ＶＣＲ １９９．９９
Ｌｉｌｉａｎ Ｔｈｕｒａｍ ＤＶＤ Ｐｌａｙｅｒ ２７９．７９
Ｌｉｌｉａｎ Ｔｈｕｒａｍ Ｒｅｃｅｉｖｅｒ ５４９．９９
Ｌｉｌｉａｎ Ｔｈｕｒａｍ Ｓｕｂ−ｗｏｏｆｅｒ ３５０．００
このケースにおける唯一の実際の相違は、反復の１つの余分なレベルが存在することである。単一のＰｕｒｃｈａｓｅ Ｏｒｄｅｒに対して反復するのではなく、まずＰｕｒｃｈａｓｅ Ｏｒｄｅｒのセットに対して反復しなければならない。各Ｐｕｒｃｈａｓｅ Ｏｒｄｅｒについては、おおむね同一のことを行う。主要な相違は、ｃｕｓｔｏｍｅｒ列が「外部の」反復の関数になることである。
Ｃｕｓｔｏｍｅｒ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｉｃｅ
Ｌｕｉｓ Ｆｉｇｏ Ｔｏａｓｔｅｒ ４９．９９
Ｌｕｉｓ Ｆｉｇｏ ＶＣＲ １９９．９９
Ｌｉｌｉａｎ Ｔｈｕｒａｍ ＤＶＤ Ｐｌａｙｅｒ ２７９．７９
Ｌｉｌｉａｎ Ｔｈｕｒａｍ Ｒｅｃｅｉｖｅｒ ５４９．９９
Ｌｉｌｉａｎ Ｔｈｕｒａｍ Ｓｕｂ−ｗｏｏｆｅｒ ３５０．００
このケースにおける唯一の実際の相違は、反復の１つの余分なレベルが存在することである。単一のＰｕｒｃｈａｓｅ Ｏｒｄｅｒに対して反復するのではなく、まずＰｕｒｃｈａｓｅ Ｏｒｄｅｒのセットに対して反復しなければならない。各Ｐｕｒｃｈａｓｅ Ｏｒｄｅｒについては、おおむね同一のことを行う。主要な相違は、ｃｕｓｔｏｍｅｒ列が「外部の」反復の関数になることである。
やはり、命令コードに満足している人にとって、この反復モデルは、おおむね以下の通りである。
命令コードが反復の余分なレベルを単純に追加するのと同一の形で、ＸＡＤは、以下のように同一のことを行う。
反復の余分なレベルに加えて、この例における他の興味深い例示は、外部スコープからスコープ変数を参照するための、＜ｓｙｓ：Ｂｉｎｄｉｎｇ Ｎａｍｅ＝“ＯｒｄｅｒＤａｔａＣｏｎｔｅｘｔ” ．．．＞エンティティの使用である。現実には、そのような機構は、
・外部スコープにあり、
・現在のスコープまたはそれを囲むスコープのスコープ変数と同一の名前を有する
スコープ変数を参照するという比較的まれな場合に限り、有用である。
・外部スコープにあり、
・現在のスコープまたはそれを囲むスコープのスコープ変数と同一の名前を有する
スコープ変数を参照するという比較的まれな場合に限り、有用である。
（パラメータ継承）
派生タグ定義を作成するときに、既存エンティティのパラメータを、ＢａｓｅＴａｇ属性によって使用可能にすることができる。例えば、
派生タグ定義を作成するときに、既存エンティティのパラメータを、ＢａｓｅＴａｇ属性によって使用可能にすることができる。例えば、
は、Ｘａｄ作成者が、以下のことを指定することを可能にする。
ＴｅｘｔおよびＦｏｎｔＦａｍｉｌｙが、タグ定義内のＰａｒａｍ値として呼び出されていないことに留意されたい。これは、これらのパラメータが、ｆｗｋ：Ｔｅｘｔタグ定義で指定されており、ＢａｓｅＮａｍｅ＝“ｆｗｋ：Ｔｅｘｔ”を指定した結果として、ＳｉｍｐｌｅＴｅｘｔタグ定義に自動的に渡されるからである。
重要：ＢａｓｅＴａｇパラメータに値を割り当てると、ＢａｓｅＴａｇ値のパラメータ（例えば、ｆｗｋ：Ｔｅｘｔ）がタグ定義に渡されるようになる。
さらに、ベースタグのタグ定義内で定義された値は、ＳｉｍｐｌｅＴｅｘｔタグ定義に自動的に割り当てられる。例えば、ＦｏｎｔＦａｍｉｌｙに、Ａｒｉａｌというデフォルト値が与えられる場合には、その値が、ＳｉｍｐｌｅＴｅｘｔタグ定義に渡される。
インスタンス対定義 − パラメータ値の優先。タグを定義するときに、その定義内の属性について静的に値を提供することができる。
これらの値がタグインスタンス内で指定されない場合には、これらの値は「そのまま」になるが、指定される場合には、インスタンス値が優先される。以下のことを検討する。
これは、サイズ２５の緑色のフォントを有するＳｉｍｐｌｅＴｅｘｔをインスタンス化する。タグインスタンス内のＦｏｎｔＳｉｚｅの値が、タグ定義内のＦｏｎｔＳｉｚｅ＝“５０”という宣言をオーバーライドする（すなわち、それより優先される）。
特定のパラメータを、無効にする、すなわち、何によっても「オーバーライド可能」でないものとして定義することができる。以下のことを検討する。
以下のインスタンス
を用いてタグインスタンス内でＦｏｎｔＦａｍｉｌｙを定義すると、上記の定義でこのパラメータが０のｍｉｎを有し、０のｍａｘも有するように定義されているので、（警告ではなく、）チェッキングエラーがもたらされる。
それでも、上記にて示されているように、タグ定義内で静的にＦｏｎｔＦａｍｉｌｙパラメータを設定することができることに留意されたい。
最上位タグの型と一致しないＢａｓｅＴａｇを指定することは、不正である。例えば、
は、そのＢａｓｅＴａｇパラメータについてｆｗｋ：Ｂｏｒｄｅｒの値を指定するが、最上位タグとして（型ｆｗｋ：Ｔｅｘｔを有する）Ｔｅｘｔを定義している。
（制限）
パラメータは、最上位タグによってのみ継承することができる。例えば、以下のことを記述する場合に、
パラメータは、最上位タグによってのみ継承することができる。例えば、以下のことを記述する場合に、
以下のインスタンスを用いると、
最上位タグはＢｏｒｄｅｒであり、したがって、そのパラメータのすべてが、新しいＢｏｒｄｅｒＴｅｘｔタグによって自動的に公開され、このタグ定義内のＢｏｒｄｅｒタグに属する。
共有パラメータは、最上位タグによって使用される。例えば、
ＢｏｒｄｅｒおよびＴｅｘｔの両方が、Ｍａｒｇｉｎパラメータを有するが、上記のインスタンスでＭａｒｇｉｎを設定すると、ＴｅｘｔのマージンではなくＢｏｒｄｅｒのマージンだけが設定される。
Ｔｅｘｔタグの値を設定するためには、その値を、ｓｙｓ：Ｐａｒａｍ構文を介して公開し、Ｔｅｘｔタグの内部にバインドする必要がある。以下のコードにこれを示す。
ここでは、以下のように見えるタグのインスタンスを用いる。
最後に、多重継承はサポートされない。例えば、タグ定義を定義し、そのタグ定義を別のタグ定義のＢａｓｅＴａｇとして使用することはできない。例えば、以下のことは不正である。
（条件付きパラメータ化）
ＸＡＤは、宣言言語ではあるが、エンティティの条件付き構築を可能にするのに十分な表現力がある。
ＸＡＤは、宣言言語ではあるが、エンティティの条件付き構築を可能にするのに十分な表現力がある。
条件付き構築の２つの形、すなわち、ＳｗｔｉｃｈＥｎｔｉｔｙまたはＳｗｉｔｃｈＥｎｔｉｔｉｅｓが可能である。これらの各々は、ＣａｓｅｓタグまたはＣｏｎｄｉｔｉｏｎｓタグのいずれかによってパラメータ化することができるが、この両方によってはパラメータ化することはできない。Ｃａｓｅｓは、Ｃ＃のｓｗｉｔｃｈと事実上、同等と考えることができ、Ｃｏｎｄｉｔｉｏｎｓは、Ｃ＃のｉｆ−ｅｌｓｅ節のセットに似ている。
ＣａｓｅｓおよびＣｏｎｄｉｔｉｏｎｓの使用は、相互に排他的であり、これは、Ｓｗｉｔｃｈが、その本体内でＣａｓｅｓおよびＣｏｎｄｉｔｉｏｎｓを混合できないことを意味する。さらに、Ｃａｓｅｓは、ＳｗｉｔｃｈがそのＤａｔａパラメータの値を指定する場合に限り使用でき、それ以外の場合にはＣｏｎｄｉｔｉｏｎｓを使用しなければならない。
ＳｗｉｔｃｈＥｎｔｉｔｙ、ＳｗｉｔｃｈＥｎｔｉｔｉｅｓ、Ｃａｓｅｓ、およびＣｏｎｄｉｔｉｏｎｓのすべてが、システムネームスペース内に存在する。規約によって、これらには、ｓｙｓ：ネームスペース、すなわち、ｓｙｓ：Ｃａｓｅ、ｓｙｓ：ＳｗｉｔｃｈＥｎｔｉｔｙなどのプレフィックスが付けられる。
以下の例のための次のデータセットを検討する。
（Ｃａｓｅｓ）
Ｃａｓｅｓは、これらの２つのオプションのうちの単純な方である。これらは、単一のパラメータすなわちＶａｌｕｅを有する。Ｖａｌｕｅの値は、ＩＳｔｒｉｎｇに評価されなければならない。Ｄａｔａの値を伴うＳｗｉｔｃｈを指定せずにＣａｓｅｓを使用すると、設計時チェッキングエラーがもたらされる。以下の不正なＸａｄを検討する。
Ｃａｓｅｓは、これらの２つのオプションのうちの単純な方である。これらは、単一のパラメータすなわちＶａｌｕｅを有する。Ｖａｌｕｅの値は、ＩＳｔｒｉｎｇに評価されなければならない。Ｄａｔａの値を伴うＳｗｉｔｃｈを指定せずにＣａｓｅｓを使用すると、設計時チェッキングエラーがもたらされる。以下の不正なＸａｄを検討する。
以下のＸａｄに、Ｃａｓｅｓの正しい使用法を示す。
（Ｃｏｎｄｉｔｉｏｎｓ）
Ｃｏｎｄｉｔｉｏｎｓは、Ｓｗｉｔｃｈの結果に関する高い度合の制御を、Ｘａｄ作成者に提供する。Ｃｏｎｄｉｔｉｏｎｓは、単一のパラメータすなわちＴｅｓｔを公開する。Ｔｅｓｔの値は、ロケーションテンプレートであり、これは、その値が有効なｘＱｕｅｒｙになることができることを意味する。Ｃｏｎｄｉｔｉｏｎｓは、ＳｗｉｔｃｈがそのＤａｔａパラメータの値を指定しない場合に限り、使用することができる。
Ｃｏｎｄｉｔｉｏｎｓは、Ｓｗｉｔｃｈの結果に関する高い度合の制御を、Ｘａｄ作成者に提供する。Ｃｏｎｄｉｔｉｏｎｓは、単一のパラメータすなわちＴｅｓｔを公開する。Ｔｅｓｔの値は、ロケーションテンプレートであり、これは、その値が有効なｘＱｕｅｒｙになることができることを意味する。Ｃｏｎｄｉｔｉｏｎｓは、ＳｗｉｔｃｈがそのＤａｔａパラメータの値を指定しない場合に限り、使用することができる。
Ｄａｔａの値を指定したＳｗｉｔｃｈと共にＣｏｎｄｉｔｉｏｎｓを使用すると、設計時チェッキングエラーがもたらされる。以下の不正なＸａｄを検討する。
以下のＸａｄに、Ｃｏｎｄｉｔｉｏｎｓの正しい使用法を示す。
（ＳｗｉｔｃｈＥｎｔｉｔｙ）
ＳｗｉｔｃｈＥｎｔｉｔｙを使用すると、作成者は、スイッチの評価の結果として単一の項目を条件付きで返せるようになる。
ＳｗｉｔｃｈＥｎｔｉｔｙを使用すると、作成者は、スイッチの評価の結果として単一の項目を条件付きで返せるようになる。
データセットの項目の各々を表示することを可能にする、以下のＸａｄを検討する。
結果として生じるビューは、以下のようになる。
ここで、５００を超える価格を赤のＧｅｏｒｇｉａフォントで表示し、１００未満の価格を緑のＡｒｉａｌフォントで表示することが望まれるシナリオを検討する。ＸＡＤは、以下のようになる。
結果として生じるビューは、以下のものに似たものになる（「Ｔｏａｓｔｅｒ」は、緑で太字のＡｒｉａｌとして表示され、「Ｒｅｃｅｉｖｅｒ」は、赤で太字のＧｅｏｒｇｉａとして表示される）。
重要：＜ｓｙｓ：ＳｗｉｔｃｈＥｎｔｉｔｙ＞は、Ｃａｓｅインスタンスの場合にはＤａｔａの値と一致する最初のＣａｓｅタグまたはＣｏｎｄｉｔｉｏｎタグの下のエンティティを作成し、ｃｏｎｄｉｔｉｏｎインスタンスの場合にはｔｒｕｅと評価される。それ以外の場合には、「ＤｅｆａｕｌｔＥｎｔｉｔｙ」パラメータとして指定されたエンティティを作成する。
（ＳｗｉｔｃｈＥｎｔｉｔｉｅｓ）
ＳｗｉｔｃｈＥｎｔｉｔｉｅｓタグは、複数の値を返すのに使用することができる。これは、複数のＣａｓｅｓまたはＣｏｎｄｉｔｉｏｎｓと一致すること、または複数の値を返す単一の条件を有することを意味する。ＳｗｉｔｃｈＥｎｔｉｔｙによって公開されるパラメータに加えて、ＳｗｉｔｃｈＥｎｔｉｔｉｅｓは、ＭａｔｃｈＦｉｒｓｔパラメータを公開する。デフォルトで、ＭａｔｃｈＦｉｒｓｔはｆａｌｓｅであり、これは、ＳｗｉｔｃｈＥｎｔｉｔｉｅｓが、すべての一致するＣａｓｅｓまたはＣｏｎｄｉｔｉｏｎｓの値と一致する、すなわち、それらの値を返すことを意味する。
ＳｗｉｔｃｈＥｎｔｉｔｉｅｓタグは、複数の値を返すのに使用することができる。これは、複数のＣａｓｅｓまたはＣｏｎｄｉｔｉｏｎｓと一致すること、または複数の値を返す単一の条件を有することを意味する。ＳｗｉｔｃｈＥｎｔｉｔｙによって公開されるパラメータに加えて、ＳｗｉｔｃｈＥｎｔｉｔｉｅｓは、ＭａｔｃｈＦｉｒｓｔパラメータを公開する。デフォルトで、ＭａｔｃｈＦｉｒｓｔはｆａｌｓｅであり、これは、ＳｗｉｔｃｈＥｎｔｉｔｉｅｓが、すべての一致するＣａｓｅｓまたはＣｏｎｄｉｔｉｏｎｓの値と一致する、すなわち、それらの値を返すことを意味する。
ＭａｔｃｈＦｉｒｓｔにｔｒｕｅが設定されている場合には、ＳｗｉｔｃｈＥｎｔｉｔｉｅｓは、最初に一致するＣａｓｅまたはＣｏｎｄｉｔｉｏｎの値だけを返す。ｆａｌｓｅと等しいＭａｔｃｈＦｉｒｓｔを指定する以下のＸａｄを検討する。
テキストボックスに入力される値に応じて、このＸａｄは、Ｃｏｎｄｉｔｉｏｎｓのうちの１つまたは複数と照合し、相応にＵＩを表示する。しかし、ＭａｔｃｈＦｉｒｓｔにｔｒｕｅが設定されている場合には、ｔｒｕｅと評価される最初のＣｏｎｄｉｔｉｏｎだけが、その値を返させる。
重要：＜ｓｙｓ：ＳｗｉｔｃｈＥｎｔｉｔｉｅｓ＞は、スコープパラメータの下で使用されなければならず、ＳｗｉｔｃｈＥｎｔｉｔｙのように非スコープコンテキストで使用することはできない。スコープパラメータが、ＮｅｗＳｃｏｐｅ属性にｔｒｕｅが設定される（すなわち、ＮｅｗＳｃｏｐｅ＝“ｔｒｕｅ”）と共に宣言されるパラメータであることを想起されたい。スコープパラメータの例が、ＤｏｃｋｉｎｇＰａｎｅｌのＲｅｐｅａｔｅｄＣｈｉｌｄパラメータである。
重要：＜ｓｙｓ：ＳｗｉｔｃｈＥｎｔｉｔｉｅｓ＞は、一致するすべてのセレクタタグの下のエンティティのセットを作成する。そうでない場合には、「ＤｅｆａｕｌｔＥｎｔｉｔｉｅｓ」パラメータとして指定されたエンティティを作成する。
重要：＜ｓｙｓ：ＳｗｉｔｃｈＥｎｔｉｔｉｅｓ＞の「ＭａｔｃｈＦｉｒｓｔ」属性にｔｒｕｅが設定されている場合、＜ｓｙｓ：ＳｗｉｔｃｈＥｎｔｉｔｉｅｓ＞は、一致する最初のＣａｓｅ／Ｃｏｎｄｉｔｉｏｎタグの下のエンティティのセットだけを作成する。そうでない場合には、「ＤｅｆａｕｌｔＥｎｔｉｔｉｅｓ」パラメータによって指定された１つまたは複数のエンティティを作成する。
（全般）
重要：＜ｓｙｓ：ＳｗｉｔｃｈＥｎｔｉｔｙ／ｉｅｓ＞は、その下にＣａｓｅタグまたはＣｏｎｄｉｔｉｏｎタグを配置させることしかできない。＜ｓｙｓ：ＳｗｉｔｃｈＥｎｔｉｔｙ／ｉｅｓ＞の直下に配置できる唯一のエンティティタグは、「ＤｅｆａｕｌｔＥｎｔｉｔｙ／ｉｅｓ」パラメータである。
重要：＜ｓｙｓ：ＳｗｉｔｃｈＥｎｔｉｔｙ／ｉｅｓ＞は、その下にＣａｓｅタグまたはＣｏｎｄｉｔｉｏｎタグを配置させることしかできない。＜ｓｙｓ：ＳｗｉｔｃｈＥｎｔｉｔｙ／ｉｅｓ＞の直下に配置できる唯一のエンティティタグは、「ＤｅｆａｕｌｔＥｎｔｉｔｙ／ｉｅｓ」パラメータである。
重要：＜ｓｙｓ：ＳｗｉｔｃｈＥｎｔｉｔｙ／ｉｅｓ＞が、型Ｔのパラメータのエンティティとして指定される場合、＜ｓｙｓ：ＳｗｉｔｃｈＥｎｔｉｔｙ／ｉｅｓ＞の下のＣａｓｅ／Ｃｏｎｄｉｔｉｏｎは、その下に型Ｔのエンティティを有さなければならない。「ＤｅｆａｕｌｔＥｎｔｉｔｙ／ｉｅｓ」パラメータが指定される場合、このパラメータも型Ｔでなければならない。
重要：＜ｓｙｓ：ＳｗｉｔｃｈＥｎｔｉｔｙ／ｉｅｓ＞が、非オプションパラメータのエンティティとして指定される場合、＜ｓｙｓ：ＳｗｉｔｃｈＥｎｔｉｔｙ／ｉｅｓ＞は、「ＤｅｆａｕｌｔＥｎｔｉｔｙ」パラメータを指定しなければならない。
（スコープ付きでないコンテキストにおける「Ｓｗｉｔｃｈ」の使用）
プロキシなしで、スコープ付きでないコンテキストにおいて、例えばＲｅｓｏｕｒｃｅｓの下で使用される場合、ｓｙｓ：ＳｗｉｔｃｈＥｎｔｉｔｙは、そのＴｙｐｅパラメータの値を指定しなければならない。以下を検討する。
プロキシなしで、スコープ付きでないコンテキストにおいて、例えばＲｅｓｏｕｒｃｅｓの下で使用される場合、ｓｙｓ：ＳｗｉｔｃｈＥｎｔｉｔｙは、そのＴｙｐｅパラメータの値を指定しなければならない。以下を検討する。
ｓｙｓ：ＤａｔａのＴｙｐｅを定義しなければならない。スコープ付きでないコンテキストに含まれるＳｗｉｔｃｈＥｎｔｉｔｙタグでＴｙｐｅを定義しないと、設計時チェッキングエラーがもたらされる。
（「Ｓｗｉｔｃｈ」のネスト）
ＳｗｉｔｃｈＥｎｔｉｔｙ／ｉｅｓは、以下のようにネストすることができる。
ＳｗｉｔｃｈＥｎｔｉｔｙ／ｉｅｓは、以下のようにネストすることができる。
これは、「＄ＡｐｐＳｔａｔｅ＝‘Ｂｌｏｒｋ’の場合に、＄ＡｐｐＳｔａｔｅ／Ｆｏｏ＝‘Ｂａｒ’であるかどうかを調べるためにテストし、そうである場合には、＄ＡｐｐＳｔａｔｅ／Ｆｏｏの値を有するＴｅｘｔ要素を表示せよ」と解釈すべきである。
（競合するネストされたアタッチドパラメータ）
以下のＸａｄを検討する。
以下のＸａｄを検討する。
アタッチドパラメータ（黄色で強調表示されている）は、競合している。最も外側のパラメータ（ｓｙｓ：ＳｗｉｔｃｈＥｎｔｉｔｉｅｓタグで指定される）は、このスイッチの戻り値が親になるＤｏｃｋＰａｎｅｌのＴｏｐにドッキングされなければならないことを示している。逆に、一致する内側のＣａｓｅタグ（シアンで強調表示されている）は、Ｔｅｘｔを親になるＤｏｃｋＰａｎｅｌのＢｏｔｔｏｍにドッキングしなければならないと指定するＴｅｘｔ要素を返す。
そのような競合の結果は、以下の通りである：
・Ｓｗｉｔｃｈが、可能な戻り値で指定されたアタッチドパラメータをシャドウイングするアタッチドパラメータを定義していることを示す設計時チェッキング警告；
・ランタイムには、最も内側の定義が「勝つ」。これは、内側のＣａｓｅが一致する場合に、ＴｅｘｔがＤｏｃｋＰａｎｅｌのＢｏｔｔｏｍにドッキングされることを意味する；
・最後に、明瞭さを保証するために、上記にて見られるデフォルトケースとの一致は、Ｓｗｉｔｃｈのアタッチドパラメータによって指定されるように、ＤｏｃｋＰａｎｅｌのＴｏｐにドッキングされたＴｅｘｔ要素をもたらす。
・Ｓｗｉｔｃｈが、可能な戻り値で指定されたアタッチドパラメータをシャドウイングするアタッチドパラメータを定義していることを示す設計時チェッキング警告；
・ランタイムには、最も内側の定義が「勝つ」。これは、内側のＣａｓｅが一致する場合に、ＴｅｘｔがＤｏｃｋＰａｎｅｌのＢｏｔｔｏｍにドッキングされることを意味する；
・最後に、明瞭さを保証するために、上記にて見られるデフォルトケースとの一致は、Ｓｗｉｔｃｈのアタッチドパラメータによって指定されるように、ＤｏｃｋＰａｎｅｌのＴｏｐにドッキングされたＴｅｘｔ要素をもたらす。
（セレクタおよびタグ定義）
場合によっては、セレクタまたはセレクタの集合を１つのタグ定義に抽象化し、これによって、セレクタを様々な領域で再利用できるようにすることが望ましい。以下のＸａｄを検討する。
場合によっては、セレクタまたはセレクタの集合を１つのタグ定義に抽象化し、これによって、セレクタを様々な領域で再利用できるようにすることが望ましい。以下のＸａｄを検討する。
これは、以下のアプリケーションを作成する。
しかし、以下のパターンは不正である。
重要：Ｘａｄは、作成者がタグ定義の＜ｓｙｓ：Ｂｏｄｙ＞の直下でＣｏｎｄｉｔｉｏｎまたはＣａｓｅをネストすることを許容しない。そうではなく、ＣａｓｅまたはＣｏｎｄｉｔｉｏｎは、最低でも＜ｓｙｓ：ＳｅｌｅｃｔｅｄＥｎｔｉｔ（ｙ｜ｉｅｓ）＞タグを親にしなければならない。
（関連付け）
ＸＡＤは、任意のエンティティとデータとの関連付けを可能にする。アプリケーションのワークスペース設定をモデル化する以下のＸｍｌ状態を検討する。
ＸＡＤは、任意のエンティティとデータとの関連付けを可能にする。アプリケーションのワークスペース設定をモデル化する以下のＸｍｌ状態を検討する。
「ＬａｙｏｕｔＳｃｈｅｍｅ」および「ＡｃｔｉｖｅＤｏｃｕｍｅｎｔＩｎｄｅｘ」が、この例では使用されていないことに留意されたい。これらは、単に、状態の構造を、アプリケーションにおいてしばしば使用されるパターンに似たものにするためにそこに存在するものである。
ＭＤＩアプリケーションは、そのような状態をアプリケーション内の様々なサブシステムに渡す。サブシステムの例は、以下のようなものがある：
・開かれている各文書の内容を別々のＭＤＩ子ウィンドウに表示する実際のＭＤＩワークスペース；
・すべての開かれている文書のサムネイルビューを有するサイドバー；
・「すべての文書を保存」などのコマンドを有するメニュー。
・開かれている各文書の内容を別々のＭＤＩ子ウィンドウに表示する実際のＭＤＩワークスペース；
・すべての開かれている文書のサムネイルビューを有するサイドバー；
・「すべての文書を保存」などのコマンドを有するメニュー。
これらの「サブシステム」の各々は、文書のリストだけではなく、文書に関連付けられたＤａｔａ Ｓｏｕｒｃｅも操作することを必要とする。理想的には、様々なサブシステムは、同一のＤａｔａ Ｓｏｕｒｃｅインスタンスを共有する。実際、共有は、依存ビューなどのシナリオに必須である。この共有は、Ａｓｓｏｃｉａｔｉｏｎ Ｍａｎａｇｅｒと呼ばれるエンティティのクラスを介して実現することができる。
Ａｓｓｏｃｉａｔｉｏｎ Ｍａｎａｇｅｒは、データに関連付けられたエンティティを作成して管理するエンティティである。例えば、Ｌｉｓｔ Ａｓｓｏｃｉａｔｉｏｎ Ｍａｎａｇｅｒは、リスト内のリスト項目の各々について関連付けを作成して管理する。
このＸＡＤは、以下のことを意味する：
・このＬｉｓｔ Ａｓｓｏｃｉａｔｉｏｎ Ｍａｎａｇｅｒは、＜ＯｐｅｎＤｏｃｕｍｅｎｔｓ＞リストの関連付けを管理している；
・リスト内の項目ごとに（すなわち、＜Ｄｏｃｕｍｅｎｔ＞ごとに）、Ｆｉｌｅ Ｄａｔａ Ｓｏｕｒｃｅが、「関連付けられたエンティティ」として作成される；
・各Ｆｉｌｅ Ｄａｔａ Ｓｏｕｒｃｅは、そのＦｉｌｅパラメータに、対応する＜Ｄｏｃｕｍｅｎｔ＞のＦｉｌｅｎａｍｅを設定させる。データコンテキスト（「．」）は、必ず、対応するリスト項目（すなわち、＜Ｄｏｃｕｍｅｎｔ＞）である；
・リスト項目（すなわち、各＜Ｄｏｃｕｍｅｎｔ＞）が、リストに追加されるか、またはリストから除去されるときに、対応する関連付けられたエンティティ（すなわち、Ｆｉｌｅ Ｄａｔａ Ｓｏｕｒｃｅ）が追加され、除去される。エンティティの実際の作成は、オンデマンドで行われることに留意されたい。
・このＬｉｓｔ Ａｓｓｏｃｉａｔｉｏｎ Ｍａｎａｇｅｒは、＜ＯｐｅｎＤｏｃｕｍｅｎｔｓ＞リストの関連付けを管理している；
・リスト内の項目ごとに（すなわち、＜Ｄｏｃｕｍｅｎｔ＞ごとに）、Ｆｉｌｅ Ｄａｔａ Ｓｏｕｒｃｅが、「関連付けられたエンティティ」として作成される；
・各Ｆｉｌｅ Ｄａｔａ Ｓｏｕｒｃｅは、そのＦｉｌｅパラメータに、対応する＜Ｄｏｃｕｍｅｎｔ＞のＦｉｌｅｎａｍｅを設定させる。データコンテキスト（「．」）は、必ず、対応するリスト項目（すなわち、＜Ｄｏｃｕｍｅｎｔ＞）である；
・リスト項目（すなわち、各＜Ｄｏｃｕｍｅｎｔ＞）が、リストに追加されるか、またはリストから除去されるときに、対応する関連付けられたエンティティ（すなわち、Ｆｉｌｅ Ｄａｔａ Ｓｏｕｒｃｅ）が追加され、除去される。エンティティの実際の作成は、オンデマンドで行われることに留意されたい。
クライアントは、＜ｓｙｓ：ＡｓｓｏｃｉａｔｅｄＥｎｔｉｔｙ＞を介して関連付けを参照する。
このＸＡＤは以下のことを意味する：
・＜ＯｐｅｎＤｏｃｕｍｅｎｔｓ＞リスト内のすべての＜Ｄｏｃｕｍｅｎｔ＞について、Ｄｏｃｋ Ｐａｎｅｌは、Ｏｕｔｌｉｎｅ Ｖｉｅｗを表示する（Ｏｕｔｌｉｎｅ Ｖｉｅｗは、そのＴｒｅｅパラメータをアウトラインフォーマットで表示する仮定のＵＩ Ｅｌｅｍｅｎｔである）；
・各Ｏｕｔｌｉｎｅ ＶｉｅｗのＴｒｅｅパラメータは、関連付けられるエンティティである；
・関連付けられるエンティティは、我々がリスト項目（すなわち、各＜Ｄｏｃｕｍｅｎｔ＞）に関連付けたＦｉｌｅ Ｄａｔａ Ｓｏｕｒｃｅである。
・＜ＯｐｅｎＤｏｃｕｍｅｎｔｓ＞リスト内のすべての＜Ｄｏｃｕｍｅｎｔ＞について、Ｄｏｃｋ Ｐａｎｅｌは、Ｏｕｔｌｉｎｅ Ｖｉｅｗを表示する（Ｏｕｔｌｉｎｅ Ｖｉｅｗは、そのＴｒｅｅパラメータをアウトラインフォーマットで表示する仮定のＵＩ Ｅｌｅｍｅｎｔである）；
・各Ｏｕｔｌｉｎｅ ＶｉｅｗのＴｒｅｅパラメータは、関連付けられるエンティティである；
・関連付けられるエンティティは、我々がリスト項目（すなわち、各＜Ｄｏｃｕｍｅｎｔ＞）に関連付けたＦｉｌｅ Ｄａｔａ Ｓｏｕｒｃｅである。
Ａｓｓｏｃｉａｔｉｏｎ Ｍａｎａｇｅｒは、以下のように、ダイナミックディクショナリとしてモデル化することができる。
＜ｓｙｓ：ＡｓｓｏｃｉａｔｅｄＥｎｔｉｔｙ＞は、Ａｓｓｏｃｉａｔｉｏｎ Ｍａｎａｇｅｒ内の値をプロキシするエンティティと考えることができ、プロキシされる値は、＜ｓｙｓ：ＡｓｓｏｃｉａｔｅｄＥｎｔｉｔｙ＞のＤａｔａパラメータによって駆動される。
この例では、関連付けられるエンティティがＤａｔａ Ｓｏｕｒｃｅであったが、関連付けられるエンティティの型は、任意とすることができ、例えば、Ｅｖｅｎｔ Ｈａｎｄｌｅｒとすることができることに留意されたい。
重要：＜ｓｙｓ：ＡｓｓｏｃｉａｔｅｄＥｎｔｉｔｙ＞が、あるデータＤおよび関連付けマネージャＡＭを与えられてエンティティＥを作成すると仮定する。Ｅは、「ＡＭ．ＬｏｏｋｕｐＡｓｓｏｃｉａｔｉｏｎ（Ｄ）」の結果である。
重要：関連付けられたエンティティのルックアップに失敗すると、ランタイムエラーがもたらされる。
重要：＜ｓｙｓ：ＡｓｓｏｃｉａｔｅｄＥｎｔｉｔｙ＞は、エンティティの型がプロキシ可能である当該エンティティを参照することだけに使用することができる。
（タグドキュメンテーション）
概要の形において、ＸＡＤタグドキュメンテーションに対するＸＡＦの手法は、マネージドＡＰＩ（maganed API）のリファレンスドキュメンテーションに関してＣ＃によって使用される手法を模倣することである。リファレンスコメンタリは、ＸＡＤ Ｔａｇの．ｘａｄコードに組み込まれ、そのコメンタリは、マネージドＡＰＩ参考資料のＭＳ内部作成で使用されるツールに概念および設計において類似するツールによって抽出され、後処理される。これらの追加の仕様は、以下のＸＡＤリファレンスドキュメンテーションを扱う：
・XAD Tags: Doc content and post processing scenarios
・XAD Tags: Doc markup and presentation
・XAD Tags: Doc production tools
これらの仕様の内容は、その名前に基づいて簡単に識別されるに違いない。次の形式的言語仕様セクションには、リファレンスドキュメンテーションの構造を制御するリファレンスドキュメンテーションマークアップタグの言及しか含まれない。ドキュメンテーション関連タグのすべてに関する完全な詳細については、「Doc markup and presentation」の仕様を参照されたい。
概要の形において、ＸＡＤタグドキュメンテーションに対するＸＡＦの手法は、マネージドＡＰＩ（maganed API）のリファレンスドキュメンテーションに関してＣ＃によって使用される手法を模倣することである。リファレンスコメンタリは、ＸＡＤ Ｔａｇの．ｘａｄコードに組み込まれ、そのコメンタリは、マネージドＡＰＩ参考資料のＭＳ内部作成で使用されるツールに概念および設計において類似するツールによって抽出され、後処理される。これらの追加の仕様は、以下のＸＡＤリファレンスドキュメンテーションを扱う：
・XAD Tags: Doc content and post processing scenarios
・XAD Tags: Doc markup and presentation
・XAD Tags: Doc production tools
これらの仕様の内容は、その名前に基づいて簡単に識別されるに違いない。次の形式的言語仕様セクションには、リファレンスドキュメンテーションの構造を制御するリファレンスドキュメンテーションマークアップタグの言及しか含まれない。ドキュメンテーション関連タグのすべてに関する完全な詳細については、「Doc markup and presentation」の仕様を参照されたい。
（形式的言語仕様）
このセクションでは、前のセクションでより非形式的に紹介した言語構造の多くの形式的宣言を提供する。「言語構造」とは、Ｓｙｓｔｅｍネームスペース（http://schemas.microsoft.com/2005/xad/system）に存在するタグを意味する。
このセクションでは、前のセクションでより非形式的に紹介した言語構造の多くの形式的宣言を提供する。「言語構造」とは、Ｓｙｓｔｅｍネームスペース（http://schemas.microsoft.com/2005/xad/system）に存在するタグを意味する。
前述したように、ＸＡＤコードは、明確に形成されたＸｍｌとして記述される。ＸＡＤファイルの最初のタグは、＜ｓｙｓ：Ｘａｄ＞である必要がある。このファイルは通常（必ずではないが）．ｘａｄ拡張子を有する。パッケージング構造およびデプロイメント構造は、言語にとって基礎であるが、形式的にはセクション５でのみ定義される。ＸＡＤ言語の部分的ＸＳＤ仕様は、http://xafteam/xafenv/doc/Platform/Application%20Components/xad.xsdにおいて入手可能である。この仕様は、主にＸＳＤが多数の構造的制約を取り込むのに十分な表現力を有さないので、「部分的」と言われる。
（ブール属性）
ＸＡＤシステムタグのすべてのブール属性は、オプションである。デフォルト値は、必ずｆａｌｓｅである。これが実際に意味するものは、ブール属性が、当該ブール属性の値をｔｒｕｅにする必要がない限り、指定される必要がないということである。すなわち、属性の不存在は、必ず、その値がｆａｌｓｅであることを意味し、属性の存在は、その値がｔｒｕｅであることを意味しなければならない。一貫性および可読性の理由から、フレームワークエクステンダは、フレームワークエクステンダ自身のブールパラメータを定義するときに、この規約に従うことが推奨される。
ＸＡＤシステムタグのすべてのブール属性は、オプションである。デフォルト値は、必ずｆａｌｓｅである。これが実際に意味するものは、ブール属性が、当該ブール属性の値をｔｒｕｅにする必要がない限り、指定される必要がないということである。すなわち、属性の不存在は、必ず、その値がｆａｌｓｅであることを意味し、属性の存在は、その値がｔｒｕｅであることを意味しなければならない。一貫性および可読性の理由から、フレームワークエクステンダは、フレームワークエクステンダ自身のブールパラメータを定義するときに、この規約に従うことが推奨される。
（修飾名）
ＸＡＤは、Ｘｍｌベースの言語であり、Ｘｍｌ修飾名を多用する。修飾名は、一意性を保証し、かつ競合を回避するために特定のネームスペースに属する（詳細については、http://www.w3.org/TR/REC-xml-names/を参照されたい）。修飾名を使用するＸＡＤ言語構造は、以下の通りである：
・型
・タグ定義
・シグネチャ
・パブリックパラメータグループ
所与のＸＡＤアプリケーションについて、上記にてリストした構造の各バケット（bucket）内のすべてのインスタンスは、そのバケット全体にまたがって一意な修飾名を有さなければならない。例えば、同一の名前の２つの型または同一の名前の２つのシグネチャが存在することはできない。しかし、異なるバケットからの項目は、同一の名前を有することができる。例えば、タグおよびシグネチャは、同一の名前を有することができるし、あるいは、パラメータグループおよび型は、同一の名前を有することができる。
ＸＡＤは、Ｘｍｌベースの言語であり、Ｘｍｌ修飾名を多用する。修飾名は、一意性を保証し、かつ競合を回避するために特定のネームスペースに属する（詳細については、http://www.w3.org/TR/REC-xml-names/を参照されたい）。修飾名を使用するＸＡＤ言語構造は、以下の通りである：
・型
・タグ定義
・シグネチャ
・パブリックパラメータグループ
所与のＸＡＤアプリケーションについて、上記にてリストした構造の各バケット（bucket）内のすべてのインスタンスは、そのバケット全体にまたがって一意な修飾名を有さなければならない。例えば、同一の名前の２つの型または同一の名前の２つのシグネチャが存在することはできない。しかし、異なるバケットからの項目は、同一の名前を有することができる。例えば、タグおよびシグネチャは、同一の名前を有することができるし、あるいは、パラメータグループおよび型は、同一の名前を有することができる。
（キーワード）
例：
＜ｄｅｓｃｒｉｐｔｉｏｎ＞タグの単純な使用については、前の例を参照されたい。＜ｄｅｓｃｒｉｐｔｉｏｎ＞タグの使用のより完全な扱いについては、「XAD Tags: Doc markup and presentation」の仕様を参照されたい。
（ビルトインエンティティ）
Ｎａｍｅｓｐａｃｅが指定される場合に、Ｔａｇの値がローカル名でなければならない、すなわち、Ｔａｇの値を「ｘｃａｌ：ＤａｔｅＰｉｃｋｅｒ」にすることはできず、「ＤａｔｅＰｉｃｋｅｒ」にしなければならないことに留意されたい。以下のＸａｄを検討する。
重要：＄ＤａｔｅＴａｇは、ＤａｔｅＰｉｃｋｅｒなどのローカル名に解決されなければならない。
（エラーケース）
ＴＯＤＯ：：これが正しいことを確実にすること。
ＴＯＤＯ：：これが正しいことを確実にすること。
エラー１：ＤｙａｎｍｉｃＥｎｔｉｔｙに関連するチェッキングエラー
シナリオ：ダイナミックエンティティのロードを試みるときに、一連のチェッキングエラーが発生し、これらのチェッキングエラーは、ＤｙｎａｍｉｃＥｎｔｉｔｙに関連付けられたステータスボードにポストされる。
シナリオ：ダイナミックエンティティのロードを試みるときに、一連のチェッキングエラーが発生し、これらのチェッキングエラーは、ＤｙｎａｍｉｃＥｎｔｉｔｙに関連付けられたステータスボードにポストされる。
（エラーケース）
エラー１：無効な関連付け
シナリオ：リスト関連付けマネージャを使用して、作成者が、そのマネージャに関する関連付けに解決されないデータノードを渡す。
エラー１：無効な関連付け
シナリオ：リスト関連付けマネージャを使用して、作成者が、そのマネージャに関する関連付けに解決されないデータノードを渡す。
（エンティティビルダ）
エンティティビルダは、エンティティを作成し、かつ／またはワイヤリングするためのユーザ定義の．ＮＥＴクラスである。エンティティビルダは、プリミティブＸＡＤタグを実装するのに使用される。ＸＡＤ言語は、エンティティビルダを記述する要件を定義する。というのは、エンティティビルダが、ＸＡＤランタイムと、この言語のカスタムエクステンションとの間の相互作用の点であるからである。エンティティの構築およびワイヤリングに応じて、新しいエンティティを定義するプリミティブタグを実装する、以下の４つの形が存在する。
エンティティビルダは、エンティティを作成し、かつ／またはワイヤリングするためのユーザ定義の．ＮＥＴクラスである。エンティティビルダは、プリミティブＸＡＤタグを実装するのに使用される。ＸＡＤ言語は、エンティティビルダを記述する要件を定義する。というのは、エンティティビルダが、ＸＡＤランタイムと、この言語のカスタムエクステンションとの間の相互作用の点であるからである。エンティティの構築およびワイヤリングに応じて、新しいエンティティを定義するプリミティブタグを実装する、以下の４つの形が存在する。
４つのケースのうちの３つにおいて、エンティティビルダクラスを指定しなければならないことに留意されたい。ＸＡＤは、エンティティビルダ用の以下の２つのインターフェースを定義する。
エンティティの構築およびワイヤリングに応じて、エンティティビルダは、このインターフェースの一方または両方を実装することができる。
エンティティビルダの要件：
・ステートレス。エンティティビルダは、Ｃｒｅａｔｅメソッドおよび／またはＷｉｒｅメソッドへの２つの呼び出しの間にローカル状態を保つことを、許可されない。ＸＡＤランタイムは、効率性の理由から、エンティティビルダのオブジェクトプールを作成する場合がある。したがって、ビルダメソッドへの呼び出しの順序および回数の保証はない；
・プレイ時挙動なし（no play-time behavior）。エンティティビルダは、２つのこと、すなわち、エンティティの作成およびワイヤリングを行うことができる。それ以外は許可されない。エンティティビルダは、そのエンティティビルダが作成またはワイヤリングするエンティティの他のインターフェースを使用することを、許可されない。
・ステートレス。エンティティビルダは、Ｃｒｅａｔｅメソッドおよび／またはＷｉｒｅメソッドへの２つの呼び出しの間にローカル状態を保つことを、許可されない。ＸＡＤランタイムは、効率性の理由から、エンティティビルダのオブジェクトプールを作成する場合がある。したがって、ビルダメソッドへの呼び出しの順序および回数の保証はない；
・プレイ時挙動なし（no play-time behavior）。エンティティビルダは、２つのこと、すなわち、エンティティの作成およびワイヤリングを行うことができる。それ以外は許可されない。エンティティビルダは、そのエンティティビルダが作成またはワイヤリングするエンティティの他のインターフェースを使用することを、許可されない。
以下の例に、プリミティブタグのタグ定義と、対応するエンティティビルダの実装とを示す。
以下は、同一のタグの単純化されたバージョンの例である。このエンティティは、定数パラメータへのアクセスを必要とせず、特別なコンストラクタパラメータを有さないので、エンティティビルダは、エンティティ構築を実装する必要はなく、ワイヤリングだけを実装する。
（アクション）
一般に、アクションは、エンティティ型「ｆｗｋ：ＥｖｅｎｔＨａｎｄｌｅｒ」を実装するエンティティである。
一般に、アクションは、エンティティ型「ｆｗｋ：ＥｖｅｎｔＨａｎｄｌｅｒ」を実装するエンティティである。
コマンドは、他のエンティティと同様に、エンティティクラスを実装し、タグ定義を記述することによって実装することができる。しかし、アクションは、最も一般的なエンティティの１つとして認識され、ＸＡＤは、アクションを実装する代替のより単純な形をサポートする。ＸＡＤは、エンティティではなく関数としてアクションを実装することを可能にする。バックグラウンドでは、ＸＡＤランタイムが、ＸＡＤパラメータをＣ＃パラメータにマッピングし、その関数を呼び出す。
コマンド実装として使用される関数は、以下の要件を満たさなければならない：
・エンティティクラスのメソッドとして定義される。エンティティクラスは、エンティティドメインサービスへのアクセスを提供する。複数のコマンド関数を、同一のエンティティクラスで実装することができる。しかし、これは、単にパッケージングの便宜のためであり、アクション間の相互作用を意味するものではない；
・ステートレス。ＸＡＤランタイムは、ランタイムに、コマンドエンティティのインスタンスをどのように管理するかを決定する。例えば、エンティティクラスの新しいインスタンスを、コマンド呼び出しごとに作成することが可能である。アクションは、ある呼び出しから別の呼び出しまで状態を保つことを、許可されない。アクションがアプリケーションに関して知る必要があるすべての情報は、パラメータとして渡されなければならない；
・参照パラメータおよびアウトパラメータがない。関数として実装されるアクションは、出力パラメータを有することができない。参照パラメータは、一般にＸＡＤによってサポートされず、したがって、コマンド関数は、このどちらも使用することができない。アクションは、インパラメータとして渡される書き込み可能なデータに書き込むことによって、アプリケーション状態に対する変更を行う。
・エンティティクラスのメソッドとして定義される。エンティティクラスは、エンティティドメインサービスへのアクセスを提供する。複数のコマンド関数を、同一のエンティティクラスで実装することができる。しかし、これは、単にパッケージングの便宜のためであり、アクション間の相互作用を意味するものではない；
・ステートレス。ＸＡＤランタイムは、ランタイムに、コマンドエンティティのインスタンスをどのように管理するかを決定する。例えば、エンティティクラスの新しいインスタンスを、コマンド呼び出しごとに作成することが可能である。アクションは、ある呼び出しから別の呼び出しまで状態を保つことを、許可されない。アクションがアプリケーションに関して知る必要があるすべての情報は、パラメータとして渡されなければならない；
・参照パラメータおよびアウトパラメータがない。関数として実装されるアクションは、出力パラメータを有することができない。参照パラメータは、一般にＸＡＤによってサポートされず、したがって、コマンド関数は、このどちらも使用することができない。アクションは、インパラメータとして渡される書き込み可能なデータに書き込むことによって、アプリケーション状態に対する変更を行う。
コマンド関数は、パラメータとしてエンティティをとる。しばしば、これらのパラメータはデータエンティティである。ＸＡＤは、強く型付けされたアクセスを可能にすることによって、データエンティティへのアクセスを容易にする。汎用データエンティティ型ＩＣＲａｎｇｅを使用することに加えて、コマンド作成者は、パラメータ型として強く型付けされたアクセッサを使用するというオプションを有する。
ファイル名に関してアウトパラメータまたは参照パラメータを使用するのではなく、更新アクセッサが使用されていることに留意されたい。
データエンティティによってサポートされないアクセッサを指定することは、エラーである。
コマンド関数に加えて、対応するタグ定義を記述しなければならない。タグ定義内のパラメータ名は、コマンド関数内のパラメータ名と正確に一致しなければならない。ＸＡＤランタイムは、名前によってパラメータを照合するので、一致しないパラメータ名を有することはエラーである。パラメータの順序は関係ない。
オプションパラメータ（Ｍｉｎ＝“０”）は許容される。オプションパラメータのデフォルト値を、タグ定義内で指定することができる。デフォルト値が指定されない場合、ＸＡＤランタイムは、ｎｕｌｌを渡し、クライアントコードは、ｎｕｌｌを処理する準備をしておかなければならない。デフォルト値なしの値型オプションパラメータを定義することは、エラーである。
設定パラメータ（Ｍａｘ＝“ｕｂｏｕｎｄｅｄ”）は許容される。設定パラメータは、関数において、ＩＣｏｌｌｅｃｔｉｏｎとして型指定されなければならない。汎用型は、項目の型を有する集合を特殊化するために、将来的に使用できるようになる。
４）カスタムチェッカはどのインターフェースを実装しなければならないのか？
５）パラメータ名とアタッチドパラメータ名との間の競合をどのように扱うべきか？
６）我々は動的にインスタンス化されるエンティティでアウトパラメータをサポートしたいのか？
７）我々は、Ｗｉｒｅに渡されるエンティティが強く型付けされるように何らかの形で汎用型を使用しようとしているのか？パラメータ値についてはどうか？
５）パラメータ名とアタッチドパラメータ名との間の競合をどのように扱うべきか？
６）我々は動的にインスタンス化されるエンティティでアウトパラメータをサポートしたいのか？
７）我々は、Ｗｉｒｅに渡されるエンティティが強く型付けされるように何らかの形で汎用型を使用しようとしているのか？パラメータ値についてはどうか？
（共通のフレームワークエンティティ）
（デプロイメントモデル）
（ＸＡＤアプリケーション）
ＸＡＤアプリケーションは、様々な関連する断片から構成される。ＸＡＤパッケージングおよびデプロイメントモデルは、これらの断片を一緒にグループ化し、以下の目的のために、それら断片間の関係を定義するルールを定義する：
・アプリケーションのすべての部分（アプリケーションの構成要素）の識別；
・アプリケーションの整合性の検証；
・インタープリタモードとコンパイルモードとの両方でのアプリケーションの実行；
・アプリケーションのデプロイメント；
・バージョニング（versioning）。
ＸＡＤは、アセンブリベースのパッケージングおよびデプロイメントモデルを使用し、このモデルは、Ｍｉｃｒｏｓｏｆｔデプロイメント戦略に従う（詳細については、Ｆｕｓｉｏｎのhttp://fusionを参照されたい）。Ｆｕｓｉｏｎは、バージョニング、サイドバイサイドインストール、「ＤＬＬヘル（DLL hell）」、管理、ポリシなどの問題を扱い、したがって、そのデプロイメントモデルおよびサービスを利用することは有益である。
（ＸＡＤアプリケーション）
ＸＡＤアプリケーションは、様々な関連する断片から構成される。ＸＡＤパッケージングおよびデプロイメントモデルは、これらの断片を一緒にグループ化し、以下の目的のために、それら断片間の関係を定義するルールを定義する：
・アプリケーションのすべての部分（アプリケーションの構成要素）の識別；
・アプリケーションの整合性の検証；
・インタープリタモードとコンパイルモードとの両方でのアプリケーションの実行；
・アプリケーションのデプロイメント；
・バージョニング（versioning）。
ＸＡＤは、アセンブリベースのパッケージングおよびデプロイメントモデルを使用し、このモデルは、Ｍｉｃｒｏｓｏｆｔデプロイメント戦略に従う（詳細については、Ｆｕｓｉｏｎのhttp://fusionを参照されたい）。Ｆｕｓｉｏｎは、バージョニング、サイドバイサイドインストール、「ＤＬＬヘル（DLL hell）」、管理、ポリシなどの問題を扱い、したがって、そのデプロイメントモデルおよびサービスを利用することは有益である。
様々なアプリケーション断片は、アセンブリと呼ばれるより大きいパッケージにグループ化される。アセンブリは、アプリケーションを形成するために結合される。
すべてのＸＡＤアプリケーションは、１つのエントリポイント、すなわち、そのエントリポイントからアプリケーション処理が開始されるタグを有する。アプリケーションエントリポイントの要件は、以下の通りである：
・タグは、ルートアセンブリ内で定義されなければならない；
・タグのローカル名は、Ｍａｉｎでなければならない。ネームスペースは、http://schemas.microsoft.com/2005/xad/systemに存在するものでなければならない；
・タグがパラメータをとる場合、そのパラメータは、コマンドラインから渡すことができるように、単純なデータ型（ｓｔｒｉｎｇ、Ｉｎｔｅｇｅｒ、Ｂｏｏｌｅａｎなど）でなければならない。
・タグは、ルートアセンブリ内で定義されなければならない；
・タグのローカル名は、Ｍａｉｎでなければならない。ネームスペースは、http://schemas.microsoft.com/2005/xad/systemに存在するものでなければならない；
・タグがパラメータをとる場合、そのパラメータは、コマンドラインから渡すことができるように、単純なデータ型（ｓｔｒｉｎｇ、Ｉｎｔｅｇｅｒ、Ｂｏｏｌｅａｎなど）でなければならない。
（ＸＡＤアセンブリ）
ＸＡＤアセンブリは、デプロイメントの最小単位である。ＸＡＤアセンブリは、ＸＡＤセマンティクスを有するｆｕｓｉｏｎアセンブリである。
ＸＡＤアセンブリは、デプロイメントの最小単位である。ＸＡＤアセンブリは、ＸＡＤセマンティクスを有するｆｕｓｉｏｎアセンブリである。
ＸＡＤアセンブリは、以下の２つの部分からなる：
・マニフェスト（５．３を参照されたい）；
・構成要素ファイル。
・マニフェスト（５．３を参照されたい）；
・構成要素ファイル。
（マニフェスト内にリストされる）アセンブリ構成要素ファイルは、実際のＸＡＤコード（タグ定義、エンティティ型、シグネチャなど）と、アプリケーションの一部である、すべての他の情報（データスキーマ、メタデータ、リソースなど）とを含む。ＸＡＤまたはスキーマファイルが、マニフェスト内に構成要素としてリストされると、その内容は、以下のために使用可能になる：
・アセンブリ内のすべてのＸＡＤファイル；
・依存ＸＡＤアセンブリ内のすべてのＸＡＤファイル。
・アセンブリ内のすべてのＸＡＤファイル；
・依存ＸＡＤアセンブリ内のすべてのＸＡＤファイル。
型、シグネチャ、パラメータグループ、およびタグ定義は、「内部」として定義することができ、その場合、これらは、そのアセンブリの外部からは不可視である。ＸＡＤファイルは、他のＸＡＤファイルまたはスキーマファイルを参照しない。依存関係（他のファイルからのタグ、型などの使用）は、ファイルレベルではなくアセンブリレベルで処理される。しかし、ＸＡＤアプリケーション内で使用される他の言語が、ファイル参照をサポートする場合がある。例えば、ＸＳＤは、インクルードディレクティブ（include directive）およびインポートディレクティブ（import directive）をサポートする。インクルードまたはインポートされるファイルは、自動的にアセンブリの一部になるのではない。これらのファイルは、構成要素ファイルとして明示的にリストされなければならない。
８）知的財産権（ＩＰ）保護に関して我々は何を行うのか？コンパイルされたアセンブリが回答になるかもしれない。
すべての構成要素ファイルは、マニフェストが配置されるのと同一のフォルダまたはサブフォルダ（任意に深いネストレベルのサブフォルダがサポートされる）に配置されなければならない。ＸＡＤアセンブリ用の、以下の２つのフォーマットが存在する：
・非ＰＥマルチファイルアセンブリ
ＰＥは、「Ｐｏｒｔａｂｌｅ Ｅｘｅｃｕｔａｂｌｅ（ポータブル実行可能ファイル）」を表す。このフォーマットは、開発中に便利である。アセンブリ全体を含む単一のファイルは存在しない。構成要素ファイルは、ＸＡＤ作成者によって作成されながら使用され、ディスクに保存される。ＸＡＤランタイムは、マニフェストを読み取ることによって、それらのファイルを発見する。構成要素ファイルに対する変更はすべて、ファイルが保存されるときにアセンブリ上で直ちに反映される。ＸＡＤアプリケーション内でアセンブリを使用するために、コンパイルステップは必要ではない；
・．ＮＥＴアセンブリ
これは、デプロイメントに便利な、コンパイルされた形のＸＡＤアセンブリである。コンパイルは、よりよい性能をもたらす。ＸＡＤアセンブリは、バイナリフォーマットで記憶され、他の．ＮＥＴアセンブリと同様に、ＧＡＣ（グローバルアセンブリキャッシュ）内で展開できるように、強い名前を用いて署名することができる。コンパイルされたＸＡＤアセンブリの正確なフォーマットが何になるかは、まだ決定されていない（ＳＤＫ１後ＴＢＤ）。しかし、コンパイルされたＸＡＤアセンブリが、エラー処理および意味のあるＷａｔｓｏｎダンプ生成のために、エラーをオリジナルのＸＡＤソースに戻って相関させることを可能にすることが必要である。
・非ＰＥマルチファイルアセンブリ
ＰＥは、「Ｐｏｒｔａｂｌｅ Ｅｘｅｃｕｔａｂｌｅ（ポータブル実行可能ファイル）」を表す。このフォーマットは、開発中に便利である。アセンブリ全体を含む単一のファイルは存在しない。構成要素ファイルは、ＸＡＤ作成者によって作成されながら使用され、ディスクに保存される。ＸＡＤランタイムは、マニフェストを読み取ることによって、それらのファイルを発見する。構成要素ファイルに対する変更はすべて、ファイルが保存されるときにアセンブリ上で直ちに反映される。ＸＡＤアプリケーション内でアセンブリを使用するために、コンパイルステップは必要ではない；
・．ＮＥＴアセンブリ
これは、デプロイメントに便利な、コンパイルされた形のＸＡＤアセンブリである。コンパイルは、よりよい性能をもたらす。ＸＡＤアセンブリは、バイナリフォーマットで記憶され、他の．ＮＥＴアセンブリと同様に、ＧＡＣ（グローバルアセンブリキャッシュ）内で展開できるように、強い名前を用いて署名することができる。コンパイルされたＸＡＤアセンブリの正確なフォーマットが何になるかは、まだ決定されていない（ＳＤＫ１後ＴＢＤ）。しかし、コンパイルされたＸＡＤアセンブリが、エラー処理および意味のあるＷａｔｓｏｎダンプ生成のために、エラーをオリジナルのＸＡＤソースに戻って相関させることを可能にすることが必要である。
（アセンブリマニフェスト）
ＸＡＤアセンブリマニフェストは、Ｆｕｓｉｏｎマニフェストであり、Ｆｕｓｉｏｎによって使用することができる。ＸＡＤアセンブリマニフェストは、ＸＡＤアセンブリを完全に記述する。このマニフェストは、「．ｍａｎｉｆｅｓｔ」拡張子を有するＸｍｌファイルである。最新のＦｕｓｉｏｎマニフェストスキーマは、http://teamweb/manifest/Shared%20Documents/Latest%20Manifest%20schema.htmで見つけることができる。マニフェストは、テキストエディタを使用して手作業で作成するか、開発ツールによって作成することができる。開発時に、マニフェストは、プロジェクトファイルの役割を担い、アセンブリのすべての部分およびその依存関係を記録する。ランタイムに、マニフェストは、アプリケーションのすべての部分を見つけてロードするために、ＸＡＤランタイムによって使用されるカタログの役割を担う。ＸＡＤランタイムは、Ｆｕｓｉｏｎマニフェストスキーマ全体を理解するのではなく、Ｆｕｓｉｏｎマニフェストスキーマのあるセクションを認識して、残りのセクションは無視する。
ＸＡＤアセンブリマニフェストは、Ｆｕｓｉｏｎマニフェストであり、Ｆｕｓｉｏｎによって使用することができる。ＸＡＤアセンブリマニフェストは、ＸＡＤアセンブリを完全に記述する。このマニフェストは、「．ｍａｎｉｆｅｓｔ」拡張子を有するＸｍｌファイルである。最新のＦｕｓｉｏｎマニフェストスキーマは、http://teamweb/manifest/Shared%20Documents/Latest%20Manifest%20schema.htmで見つけることができる。マニフェストは、テキストエディタを使用して手作業で作成するか、開発ツールによって作成することができる。開発時に、マニフェストは、プロジェクトファイルの役割を担い、アセンブリのすべての部分およびその依存関係を記録する。ランタイムに、マニフェストは、アプリケーションのすべての部分を見つけてロードするために、ＸＡＤランタイムによって使用されるカタログの役割を担う。ＸＡＤランタイムは、Ｆｕｓｉｏｎマニフェストスキーマ全体を理解するのではなく、Ｆｕｓｉｏｎマニフェストスキーマのあるセクションを認識して、残りのセクションは無視する。
ＸＡＤによって認識されるマニフェストセクションは、以下の通りである：
・アセンブリＩＤ；
・説明；
・他のアセンブリとの依存関係；
・構成要素ファイルのリスト。
・アセンブリＩＤ；
・説明；
・他のアセンブリとの依存関係；
・構成要素ファイルのリスト。
Ｆｕｓｉｏｎマニフェストスキーマのターゲットネームスペースは、「ｕｒｎ：ｓｃｈｅｍａｓ−ｍｉｃｒｏｓｏｆｔ−ｃｏｍ：ａｓｍ．ｖ２」である。このスキーマは、拡張可能であり、他のネームスペースからの要素および属性を追加することができる。ＸＡＤは、http://schemas.microsoft.com/2005/xad/assemblyのネームスペースで定義された拡張として、少数の属性を追加するに過ぎない。ＸＡＤは、要素に関してはマニフェストスキーマを拡張しない。
以下のリファレンスは、ＸＡＤによって認識されるＦｕｓｉｏｎマニフェストＸｍｌの要素および属性、ならびにＸＡＤによって追加される属性を説明するものである。
９）「カルチャ」属性の我々の使用法は何か？．ＮＥＴでは、「カルチャ」属性は、サテライトアセンブリのみのために意図されている。我々は、ローカライズされたリソースをどのように扱うのか？
１０）ｔｙｐｅ属性の我々の現在の使用法に関する問題：
−これは、「後方互換性のため」として文書化され、将来的に除去することができる；
−値「ｘａｄ」をグローバルに予約する方法はない；
−ｔｙｐｅは、依存関係において指定されたときに限り意味を持つ；
我々は、その代わりにｄｅｐｅｎｄｅｎｔＡｓｓｅｍｂｌｙ要素で我々自身の拡張属性を定義すべきか？
１０）ｔｙｐｅ属性の我々の現在の使用法に関する問題：
−これは、「後方互換性のため」として文書化され、将来的に除去することができる；
−値「ｘａｄ」をグローバルに予約する方法はない；
−ｔｙｐｅは、依存関係において指定されたときに限り意味を持つ；
我々は、その代わりにｄｅｐｅｎｄｅｎｔＡｓｓｅｍｂｌｙ要素で我々自身の拡張属性を定義すべきか？
１１）挙動マップファイルの将来はどうなるか？
（マニフェストの例）
このマニフェストの例は、名前「Ｄｅｍｏ」およびバージョン「１．０．０．０」を有するアセンブリを記述している。
「Ｄｅｍｏ」アセンブリは、以下の２つの他のアセンブリに依存する：
・「Ｍｉｃｒｏｓｏｆｔ．ＸＡＦ．ＸＡＤ．Ｆｒａｍｅｗｏｒｋ」、すなわち、ＸＡＤアセンブリ（ｔｙｐｅ＝“ｘａｄ”）；
・「ＤｅｍｏＥｎｔｉｔｙＢｕｉｄｌｅｒｓ」、すなわち、．ＮＥＴアセンブリ（ｔｙｐｅは指定されない）。
・「Ｍｉｃｒｏｓｏｆｔ．ＸＡＦ．ＸＡＤ．Ｆｒａｍｅｗｏｒｋ」、すなわち、ＸＡＤアセンブリ（ｔｙｐｅ＝“ｘａｄ”）；
・「ＤｅｍｏＥｎｔｉｔｙＢｕｉｄｌｅｒｓ」、すなわち、．ＮＥＴアセンブリ（ｔｙｐｅは指定されない）。
「Ｄｅｍｏ」アセンブリは、以下の２つの構成要素ファイルを有する：
・ＤｅｍｏＴａｇｓ．ｘａｄ、すなわち、最終的にタグ定義、シグネチャ、エンティティ型、およびパブリックパラメータグループを含めることができるＸＡＤファイル；
・ＤｅｍｏＤａｔａＳｃｈｅｍａ．ｘｓｄ、すなわち、スキーマファイル。
・ＤｅｍｏＴａｇｓ．ｘａｄ、すなわち、最終的にタグ定義、シグネチャ、エンティティ型、およびパブリックパラメータグループを含めることができるＸＡＤファイル；
・ＤｅｍｏＤａｔａＳｃｈｅｍａ．ｘｓｄ、すなわち、スキーマファイル。
（アセンブリの依存関係）
別のアセンブリとの依存関係を確立することによって、ＸＡＤアセンブリは、その内部にはない
・エンティティ型
・シグネチャ
・タグ定義
・パラメータグループ
・スキーマ
を使用することができる。
別のアセンブリとの依存関係を確立することによって、ＸＡＤアセンブリは、その内部にはない
・エンティティ型
・シグネチャ
・タグ定義
・パラメータグループ
・スキーマ
を使用することができる。
別のＸＡＤアセンブリとの依存関係は、マニフェストの依存アセンブリのリストにそのＩＤを含め、属性ｔｙｐｅ＝“ｘａｄ”を指定することによって確立される。ファイルまたはパス情報を指定する必要はない。アセンブリＩＤは、ランタイムに解決され、対応するアセンブリがロードされる（「アセンブリのバインディング、ロード、およびアンロード」を参照されたい）。
ＸＡＤアセンブリは、．ＮＥＴアセンブリに依存することもできる。．ＮＥＴアセンブリとの依存関係は、ｔｙｐｅ属性が指定されないか、異なる値を有することを除いて、ＸＡＤアセンブリとの依存関係と正確に同一の形で確立される。．ＮＥＴアセンブリとの依存関係は、
・エンティティ型定義
・プリミティブタグ定義におけるエンティティ参照
・プリミティブタグ定義におけるエンティティビルダ参照
・プリミティブタグ定義におけるコマンドクラス参照
・メタデータ
において．ＮＥＴ型がＸＡＤアセンブリによって参照されるたびに確立されなければならない。
・エンティティ型定義
・プリミティブタグ定義におけるエンティティ参照
・プリミティブタグ定義におけるエンティティビルダ参照
・プリミティブタグ定義におけるコマンドクラス参照
・メタデータ
において．ＮＥＴ型がＸＡＤアセンブリによって参照されるたびに確立されなければならない。
以下は、ＸＡＤアセンブリの依存関係に適用されるルールである：
・１つのアセンブリが、複数のアセンブリに依存することができる（Ａが、Ｂ、Ｃ、Ｄなどに依存することができる）；
・多数のアセンブリが、同一のアセンブリに依存することができる（Ｂ、Ｃ、Ｄなどが、Ａに依存することができる）；
・アセンブリの依存関係は、推移的ではない（ＡがＢに依存し、ＢがＣに依存する場合に、ＡはＣに依存しない。Ａは、必要に応じて、明示的にＣを参照しなければならない）；
・環状依存関係は、サポートされない（ＡがＢに依存し、ＢがＣに依存する場合、ＣはＡに依存することができない）。
・１つのアセンブリが、複数のアセンブリに依存することができる（Ａが、Ｂ、Ｃ、Ｄなどに依存することができる）；
・多数のアセンブリが、同一のアセンブリに依存することができる（Ｂ、Ｃ、Ｄなどが、Ａに依存することができる）；
・アセンブリの依存関係は、推移的ではない（ＡがＢに依存し、ＢがＣに依存する場合に、ＡはＣに依存しない。Ａは、必要に応じて、明示的にＣを参照しなければならない）；
・環状依存関係は、サポートされない（ＡがＢに依存し、ＢがＣに依存する場合、ＣはＡに依存することができない）。
（アセンブリのバインディング、ロード、およびアンロード）
バインディングは、アセンブリＩＤをその物理的位置に解決するプロセスである。アセンブリＩＤは、パスおよびファイルなどの位置情報を含まない。Ｆｕｓｉｏｎは、．ＮＥＴランタイムによって使用されるアセンブリバインディングアルゴリズムを定義する。長期ＸＡＤ（long-term XAD）は、Ｆｕｓｉｏｎによって提供されるサービスとして、バインディングアルゴリズムを使用する。短期には、ＸＡＤは、そのＣｈｉｌｄｒｅｎｅｔを実装する。
バインディングは、アセンブリＩＤをその物理的位置に解決するプロセスである。アセンブリＩＤは、パスおよびファイルなどの位置情報を含まない。Ｆｕｓｉｏｎは、．ＮＥＴランタイムによって使用されるアセンブリバインディングアルゴリズムを定義する。長期ＸＡＤ（long-term XAD）は、Ｆｕｓｉｏｎによって提供されるサービスとして、バインディングアルゴリズムを使用する。短期には、ＸＡＤは、そのＣｈｉｌｄｒｅｎｅｔを実装する。
すべての強く命名されてはいないアセンブリ（公開鍵トークンなし）が、アプリケーションフォルダの下に存在しなければならないことが要求される。アプリケーションフォルダは、ルート／メインアセンブリのマニフェストを含むフォルダである。
アセンブリＩＤが与えられると、ＸＡＤランタイムは、以下のアルゴリズムを使用して、アセンブリを見つける：
１．アセンブリがタイプ「ＸＡＤ」ではない場合には、アセンブリが．ＮＥＴアセンブリであると仮定し、ロードを．ＮＥＴフレームワークに委任する；
２．ＸＡＤアセンブリの場合には、アセンブリ名を有するマニフェストについてアプリケーションフォルダをチェックし、それをロードする；
３．見つからない場合には、アセンブリ名を有するサブフォルダについてアセンブリフォルダをチェックする。見つかった場合には、アセンブリ名を有するマニフェストファイルについてチェックし、それをロードする；
４．見つからず、これがデバッグビルドである場合には、環境変数ＸＡＤＰＡＴＨで指定される各フォルダについてステップ２およびステップ３を繰り返す。これは開発時ファシリティのみである。ＸＡＤＰＡＴＨにおけるパスは、セミコロンで区切られる。
１．アセンブリがタイプ「ＸＡＤ」ではない場合には、アセンブリが．ＮＥＴアセンブリであると仮定し、ロードを．ＮＥＴフレームワークに委任する；
２．ＸＡＤアセンブリの場合には、アセンブリ名を有するマニフェストについてアプリケーションフォルダをチェックし、それをロードする；
３．見つからない場合には、アセンブリ名を有するサブフォルダについてアセンブリフォルダをチェックする。見つかった場合には、アセンブリ名を有するマニフェストファイルについてチェックし、それをロードする；
４．見つからず、これがデバッグビルドである場合には、環境変数ＸＡＤＰＡＴＨで指定される各フォルダについてステップ２およびステップ３を繰り返す。これは開発時ファシリティのみである。ＸＡＤＰＡＴＨにおけるパスは、セミコロンで区切られる。
見つかったならば、アセンブリおよびそのすべての依存関係が、ＸＡＤランタイムによってロードされる。このプロセスは、再帰的であり、依存関係について繰り返される。各依存関係の内容は、依存アセンブリのために使用可能にされる。アセンブリの内容が、すべてのアセンブリについてグローバルに使用可能にされるのではなく、それに直接的に依存するもののみについてであることに留意することが重要である。
スキーマは、このルールの例外である。スキーマ構成要素ファイルを伴うアセンブリをロードすると、スキーマが、ロードされ、グローバルスキーマコレクションに追加され、すべてのアセンブリのために使用可能にされる。しかし、これは、現在の実装の制限であり、要件と考えてはならない。これは、将来的に変更される可能性が非常に高い。
アセンブリをロードする以下の２つの形が存在する：
・別のアセンブリのマニフェスト内の静的な依存関係を介する；
・プログラム的に、
ＬｏａｄＡｓｓｅｍｂｌｙＣｏｍｍａｎｄを介して；
低水準パブリックＡＰＩを介して。
・別のアセンブリのマニフェスト内の静的な依存関係を介する；
・プログラム的に、
ＬｏａｄＡｓｓｅｍｂｌｙＣｏｍｍａｎｄを介して；
低水準パブリックＡＰＩを介して。
ルートアセンブリ（アプリケーションアセンブリ）から開始し、その依存関係、当該依存関係の依存関係などに進むことによって、静的に依存するアセンブリの任意に深いグラフが形成される。ＸＡＤランタイムは、アプリケーション起動時に、これらのすべてのアセンブリをロードする。開発者は、静的な依存関係として指定されていないアセンブリをロードすることもできる。プログラム的にロードされるアセンブリという特徴がターゲットとする主なシナリオは、アドインのサポートである（さらなる詳細については、「アドインモデル」を参照されたい）。
アプリケーションアセンブリ（ルート）およびすべてのプログラム的にロードされるアセンブリは、トップレベルアセンブリのセットを形成する。トップレベルアセンブリだけが、アプリケーションメタデータに寄与する。ルートアセンブリを除くトップレベルアセンブリだけを、プログラム的にアンロードすることができる。アセンブリは、トップレベルアセンブリとして後にプログラム的にロードされた場合であっても、静的な依存関係としてロードされる場合にはアンロードすることができない。そのようなアセンブリのアンロードは、静的にロードされるアセンブリからではなく、トップレベルアセンブリからそのアセンブリを除去することだけをもたらす。
（パッケージングのシナリオ）
（１ファイルアプリケーション）
「Ｈｅｌｌｏ ｗｏｒｌｄ」は、単純な１ファイルアプリケーションの例である。１ファイルアプリケーションは、アプリケーション実行に必要なすべての情報を含む単一のＸＡＤファイルを有する。最小限でも、このファイルは、メインタグすなわちアプリケーションエントリポイントのタグ定義を含まなければならない。アセンブリまたはアセンブリマニフェストを作成する必要はない。
（１ファイルアプリケーション）
「Ｈｅｌｌｏ ｗｏｒｌｄ」は、単純な１ファイルアプリケーションの例である。１ファイルアプリケーションは、アプリケーション実行に必要なすべての情報を含む単一のＸＡＤファイルを有する。最小限でも、このファイルは、メインタグすなわちアプリケーションエントリポイントのタグ定義を含まなければならない。アセンブリまたはアセンブリマニフェストを作成する必要はない。
１ファイルアプリケーションの要件は、以下の通りである：
・標準フレームワークだけに依存する。標準フレームワークは、デフォルトで使用可能であり、アセンブリマニフェストにおいて依存関係として指定される必要はない。アプリケーションが、標準フレームワークからのタグ、型、およびシグネチャだけを使用している場合に、そのアプリケーションは、そのマニフェストにおいて依存関係を指定する必要がない（マニフェストにおいて依存関係セクションがない）；
・すべてのタグを単一ファイル内に有する。１つのファイルだけがある場合に、アプリケーションは、マニフェストの構成要素ファイルセクションを必要としない。そのタイプにかかわりなく、複数のファイルが生じるとすぐに、アプリケーションは、マニフェストにおいて構成要素ファイルを記述することを必要とする。
これらの要件が満たされる場合に、そのアプリケーションは、すべての重要なセクションが空になるので、アセンブリマニフェストを必要としない。これが１ファイルアプリケーションである。
・標準フレームワークだけに依存する。標準フレームワークは、デフォルトで使用可能であり、アセンブリマニフェストにおいて依存関係として指定される必要はない。アプリケーションが、標準フレームワークからのタグ、型、およびシグネチャだけを使用している場合に、そのアプリケーションは、そのマニフェストにおいて依存関係を指定する必要がない（マニフェストにおいて依存関係セクションがない）；
・すべてのタグを単一ファイル内に有する。１つのファイルだけがある場合に、アプリケーションは、マニフェストの構成要素ファイルセクションを必要としない。そのタイプにかかわりなく、複数のファイルが生じるとすぐに、アプリケーションは、マニフェストにおいて構成要素ファイルを記述することを必要とする。
これらの要件が満たされる場合に、そのアプリケーションは、すべての重要なセクションが空になるので、アセンブリマニフェストを必要としない。これが１ファイルアプリケーションである。
（派生タグのライブラリ）
ＸＡＤは、ＸＡＤ作成者がＸＡＤ作成者自身のタグを定義することによって、この言語を拡張することを可能にする。それを行う最も簡単な方法は、派生タグを定義することである。というのは、派生タグが、ＸＡＤによって実装され、低水準プログラミングのスキルを必要としないからである。ＸＡＤ作成者は、最終的に再利用可能なカスタムタグのセットを用意し、多数のアセンブリおよびアプリケーションにまたがってそれらのタグを共有したいと思うであろう。これは、その後に他のアセンブリによって参照できる別々のアセンブリにタグをパッケージングすることによって、行うことができる。
ＸＡＤは、ＸＡＤ作成者がＸＡＤ作成者自身のタグを定義することによって、この言語を拡張することを可能にする。それを行う最も簡単な方法は、派生タグを定義することである。というのは、派生タグが、ＸＡＤによって実装され、低水準プログラミングのスキルを必要としないからである。ＸＡＤ作成者は、最終的に再利用可能なカスタムタグのセットを用意し、多数のアセンブリおよびアプリケーションにまたがってそれらのタグを共有したいと思うであろう。これは、その後に他のアセンブリによって参照できる別々のアセンブリにタグをパッケージングすることによって、行うことができる。
以下の例には、ＭｙＴａｇｓ．ｘａｄファイルにおいて定義され、ＭｙＬｉｂｒａｒｙアセンブリにパッケージングされる２つの再利用可能な派生タグが存在する。ＭｙＬｉｂｒａｒｙアセンブリは、ＭｙＡｐｐｌｉｃａｔｉｏｎアセンブリによって参照され、ＭｙＡｐｐｌｉｃａｔｉｏｎアセンブリは、このライブラリによって提供されるタグを使用している。
次に、これがどのように動作するかを示す：
・ＭｙＴａｇｓ．ｘａｄファイルは、２つのタグ、すなわち、ＴｅｘｔＷｉｔｈＬａｂｅｌおよびＨｙｐｅｒｌｉｎｋを定義する；
・ＭｙＴａｇｓ．ｘａｄファイルは、ＭｙＬｉｂｒａｒｙマニフェストにおいて、構成要素ファイルとしてリストされている。これによって、このファイル内のすべてのタグが、ＭｙＬｉｂｒａｒｙアセンブリクライアントのために使用可能にされる；
・ＭｙＡｐｐｌｉｃａｔｉｏｎアセンブリは、ＭｙＬｉｂｒａｒｙアセンブリを参照し、したがって、ＭｙＬｉｂｒａｒｙにおいて定義されたすべてのタグへのアクセスを有する；
・ＭｙＡｐｐｌｉｃａｔｉｏｎファイルは、ＭｙＬｉｂｒａｒｙアセンブリにおいて定義されたＨｙｐｅｒｌｉｎｋタグを使用する。
・ＭｙＴａｇｓ．ｘａｄファイルは、２つのタグ、すなわち、ＴｅｘｔＷｉｔｈＬａｂｅｌおよびＨｙｐｅｒｌｉｎｋを定義する；
・ＭｙＴａｇｓ．ｘａｄファイルは、ＭｙＬｉｂｒａｒｙマニフェストにおいて、構成要素ファイルとしてリストされている。これによって、このファイル内のすべてのタグが、ＭｙＬｉｂｒａｒｙアセンブリクライアントのために使用可能にされる；
・ＭｙＡｐｐｌｉｃａｔｉｏｎアセンブリは、ＭｙＬｉｂｒａｒｙアセンブリを参照し、したがって、ＭｙＬｉｂｒａｒｙにおいて定義されたすべてのタグへのアクセスを有する；
・ＭｙＡｐｐｌｉｃａｔｉｏｎファイルは、ＭｙＬｉｂｒａｒｙアセンブリにおいて定義されたＨｙｐｅｒｌｉｎｋタグを使用する。
（プリミティブタグのライブラリ）
ＸＡＤは、カスタムプリミティブタグまたは派生タグを定義することによって、拡張することができる。派生タグは、ＸＡＤを使用して実装されるので定義がより簡単であるが、プリミティブタグは、ＶＢおよびＣ＃などの低水準プログラミング言語を使用して実装されるので、より豊かな機能を提供することができる。これらの言語は、ＯＳおよびマシンリソースへのフルアクセスを提供する。コンポーネント開発者、ツール開発者、およびプラットフォーム開発者は、多数のＸＡＤアプリケーションにおいてＸＡＤ作成者が再利用できるプリミティブタグを定義することができる。プリミティブタグのパッケージングは、派生タグのパッケージングとほとんど同一である（上記の例を参照されたい）。以下の２つの主要な相違が存在する：
・タグ定義は、ＸＡＤ本体ではなく、エンティティビルダクラスへの参照を含む；
・プリミティブタグを含むアセンブリのマニフェストは、エンティティビルダを含む．ＮＥＴアセンブリとの追加の依存関係を指定しなければならない。
ＸＡＤは、カスタムプリミティブタグまたは派生タグを定義することによって、拡張することができる。派生タグは、ＸＡＤを使用して実装されるので定義がより簡単であるが、プリミティブタグは、ＶＢおよびＣ＃などの低水準プログラミング言語を使用して実装されるので、より豊かな機能を提供することができる。これらの言語は、ＯＳおよびマシンリソースへのフルアクセスを提供する。コンポーネント開発者、ツール開発者、およびプラットフォーム開発者は、多数のＸＡＤアプリケーションにおいてＸＡＤ作成者が再利用できるプリミティブタグを定義することができる。プリミティブタグのパッケージングは、派生タグのパッケージングとほとんど同一である（上記の例を参照されたい）。以下の２つの主要な相違が存在する：
・タグ定義は、ＸＡＤ本体ではなく、エンティティビルダクラスへの参照を含む；
・プリミティブタグを含むアセンブリのマニフェストは、エンティティビルダを含む．ＮＥＴアセンブリとの追加の依存関係を指定しなければならない。
エンティティビルダは、プリミティブタグに対応するエンティティをどのように作成して、ワイヤリングするかを知っている．ＮＥＴコンポーネントである（エンティティビルダのさらなる詳細については、言語の概念を参照されたい）。
以下の例では、プリミティブタグとしてＨｙｐｅｒｌｉｎｋを実装している。
クライアントコードは、派生タグとしてのＨｙｐｅｒｌｉｎｋを使用するコードと同一である。クライアントアセンブリは、他のアセンブリからのタグの実装詳細にも、その依存関係にも公開されない。
（アドインモデル）
（アドインモデルとは何か？）
アドイン（アドオンまたはプラグインとも呼ばれる）は、アプリケーションのアップグレードを必要とせずに、所与のソフトウェアアプリケーションの基本機能セットを拡張する、内蔵型のソフトウェアパッケージである。アドインは、ユーザが高価と考えられるアップグレードサイクルを全部行うことを必要とせずに、新しい機能またはサードパーティの拡張機能が使用可能になったときに、これらの機能を増分的に追加することを可能にする。
（アドインモデルとは何か？）
アドイン（アドオンまたはプラグインとも呼ばれる）は、アプリケーションのアップグレードを必要とせずに、所与のソフトウェアアプリケーションの基本機能セットを拡張する、内蔵型のソフトウェアパッケージである。アドインは、ユーザが高価と考えられるアップグレードサイクルを全部行うことを必要とせずに、新しい機能またはサードパーティの拡張機能が使用可能になったときに、これらの機能を増分的に追加することを可能にする。
アドインアーキテクチャが動作するための、以下の４つの重要な要件が存在する：
・拡張性プロトコルが、定義され、公開されなければならない；
・拡張されるアプリケーションが、拡張性プロトコルを正しく実装しなければならない；
・アドインが、拡張性プロトコルを正しく実装しなければならない；
・アプリケーションが、アドインの発見（discovery）およびロードをサポートしなければならない。
・拡張性プロトコルが、定義され、公開されなければならない；
・拡張されるアプリケーションが、拡張性プロトコルを正しく実装しなければならない；
・アドインが、拡張性プロトコルを正しく実装しなければならない；
・アプリケーションが、アドインの発見（discovery）およびロードをサポートしなければならない。
（ＸＡＤアドインモデル）
ＸＡＤアドインモデルは、以下の主要な概念に基づく：
・アセンブリの動的ロード；
・メタデータ駆動型の拡張性プロトコル；
・動的なエンティティのインスタンス化。
ＸＡＤアドインモデルは、以下の主要な概念に基づく：
・アセンブリの動的ロード；
・メタデータ駆動型の拡張性プロトコル；
・動的なエンティティのインスタンス化。
（アセンブリの動的ロード）
アドインは、アセンブリ内にパッケージングされる。これは驚くべきことではない。というのは、ＸＡＤアプリケーションのすべての部分が、アセンブリ内にパッケージングされるからである。アセンブリは通常、アセンブリマニフェストにおいて指定された静的な依存関係を介してロードされる（「アセンブリの依存関係」を参照されたい）。ＸＡＤランタイムは、すべての静的な依存関係を自動的にロードする。
アドインは、アセンブリ内にパッケージングされる。これは驚くべきことではない。というのは、ＸＡＤアプリケーションのすべての部分が、アセンブリ内にパッケージングされるからである。アセンブリは通常、アセンブリマニフェストにおいて指定された静的な依存関係を介してロードされる（「アセンブリの依存関係」を参照されたい）。ＸＡＤランタイムは、すべての静的な依存関係を自動的にロードする。
アセンブリは、動的にロードすることもできる。この場合、アセンブリは、どのマニフェストにおいても静的な依存関係としてリストされない。その代わりに、アプリケーションは、システム定義コマンド＜ｌｏａｄＡｓｓｅｍｂｌｙ＞を使用して、そのマニフェストパスを指定することによって、アセンブリをロードすることができる。このパスは、単に１つのデータに過ぎず、ユーザ入力、アプリケーション状態、構成ファイルなどから取得することができる。アセンブリがロードされると、メタデータが更新され、そのエンティティが、動的インスタンス化に使用可能になる。
（メタデータ駆動型の拡張性プロトコル）
拡張可能なＸＡＤアプリケーションは、その拡張性プロトコルを別々のアセンブリ内で定義し、その結果、このプロトコルを、公開して、そのアプリケーションと、拡張機能を記述するサードパーティとの両方によって参照できるようになる。
拡張可能なＸＡＤアプリケーションは、その拡張性プロトコルを別々のアセンブリ内で定義し、その結果、このプロトコルを、公開して、そのアプリケーションと、拡張機能を記述するサードパーティとの両方によって参照できるようになる。
拡張性プロトコルは以下の２つの部分を有する：
・メタデータスキーマ：用語「メタデータ」は一般に、「データに関するデータ」を意味する。本仕様書の文脈では、メタデータは、アドインによって実装される機能の記述として使用される。メタデータには、タグ名、渡されるパラメータ、ＵＩで人間が読み取り可能なテキストなどを含めることができる。拡張可能なアプリケーションは、メタデータスキーマ（アドインに何を期待するか）を定義する。アドインは、そのコンテンツを提供する；
・タグシグネチャ：アドインは、ＸＡＤタグを定義することによってその機能を実装する。アプリケーションは、これらのタグを使用して、アドイン機能にアクセスする。アプリケーションは、タグシグネチャ（タグがどの型のエンティティをもたらさなければならないか、およびタグがどのパラメータをとるか）を定義し、アドインは、タグ定義（タグ名および実際の実装）を提供する。シグネチャをインターフェースになぞらえることができ、タグ定義をインターフェース実装になぞらえることができる。
・メタデータスキーマ：用語「メタデータ」は一般に、「データに関するデータ」を意味する。本仕様書の文脈では、メタデータは、アドインによって実装される機能の記述として使用される。メタデータには、タグ名、渡されるパラメータ、ＵＩで人間が読み取り可能なテキストなどを含めることができる。拡張可能なアプリケーションは、メタデータスキーマ（アドインに何を期待するか）を定義する。アドインは、そのコンテンツを提供する；
・タグシグネチャ：アドインは、ＸＡＤタグを定義することによってその機能を実装する。アプリケーションは、これらのタグを使用して、アドイン機能にアクセスする。アプリケーションは、タグシグネチャ（タグがどの型のエンティティをもたらさなければならないか、およびタグがどのパラメータをとるか）を定義し、アドインは、タグ定義（タグ名および実際の実装）を提供する。シグネチャをインターフェースになぞらえることができ、タグ定義をインターフェース実装になぞらえることができる。
ＸＡＤは、システム定義タグ＜Ｍｅｔａｄａｔａ＞を介してアクセス可能なグローバルメタデータツリーをサポートする。メタデータツリーは、すべての動的にロードされたアセンブリからのすべてのメタデータ構成要素ファイルの結合である（構成要素に関する詳細については「ファイルタイプ」を参照されたい）。メタデータツリーは、ランタイムに、メタデータ構成要素ファイルを伴うアセンブリがロードされるかアンロードされるたびに、自動的に更新される。アプリケーションがそれ自体を動的に更新できるようにするために、正しい変更通知が送信される。メタデータツリーを使用して、アプリケーションは、どのアドインがロードされているかを発見し、そのアドインが提供する機能を使用することができる。
（動的なエンティティのインスタンス化）
ＸＡＤ作成者は通常、ＸＡＤコード内に直接的にＸＡＤタグを記述する。ＸＡＤタグを使用することによって、作成者は、ＸＡＤランタイムによってどのエンティティが作成されなければならないかを静的に宣言する。
ＸＡＤ作成者は通常、ＸＡＤコード内に直接的にＸＡＤタグを記述する。ＸＡＤタグを使用することによって、作成者は、ＸＡＤランタイムによってどのエンティティが作成されなければならないかを静的に宣言する。
アドインは、そのアドインが実装する機能にアクセスするためのタグを定義する。アドインは、アプリケーションが記述される時点では使用できないので、ＸＡＤ作成者が、アドインによって定義されるタグを認識して使用することは、不可能である。作成者は、タグシグネチャを認識して、静的に定義するだけである。実際のタグ名、したがって最終的にパラメータ値は、アドインによってメタデータを介して提供される。アプリケーションは、メタデータスキーマがどのようなものであるかを正確に認識している。というのは、メタデータスキーマが、アプリケーション定義の拡張性プロトコルの一部であるからである。アプリケーションは、メタデータを読み取り、タグ名によってエンティティを動的にインスタンス化する。ＸＡＤは、タグ名による動的エンティティインスタンス化用のシステム定義タグ＜ＤｙｎａｍｉｃＥｎｔｉｔｙ＞をサポートする。プロキシを有するタイプのエンティティだけを、動的にインスタンス化することができる。エンティティが、
・動的にロードされるアセンブリ内、
・ＤｙｎａｍｉｃＥｎｔｉｔｙタグを使用しているアセンブリの静的な依存アセンブリ内
で定義される場合に限り、そのエンティティを動的にインスタンス化することができる。
・動的にロードされるアセンブリ内、
・ＤｙｎａｍｉｃＥｎｔｉｔｙタグを使用しているアセンブリの静的な依存アセンブリ内
で定義される場合に限り、そのエンティティを動的にインスタンス化することができる。
（アドインのシナリオ）
以下のシナリオでは、新しいタイプのファイルをサポートするためにアドインを介して拡張できるファイルアプリケーションを説明する。このアプリケーションのアイデアは、ファイルタイプをサポートするアドインを有する限り、任意のタイプのファイルを開いて、示すことができるというものである。この例は、以下の３つの部分を有する：
・ＦｉｌｅＥｘｔｅｎｓｉｏｎＰｒｏｔｏｃｏｌアセンブリ
Ｆｉｌｅアプリケーションの拡張プロトコルを定義する。この拡張プロトコルは、メタデータスキーマおよび個々のファイルタグのシグネチャから構成される。この拡張プロトコルは、このアプリケーションと、様々なアドインとの両方がこの拡張プロトコルを参照できるようにするために、別々のアセンブリ内で定義される；
・Ｆｉｌｅアセンブリ
Ｆｉｌｅアプリケーションコード用のアセンブリ；
・ＳｍａｒｔＦｉｌｅｓＡｄｄＩｎアセンブリ
架空の会社Ｓｍａｒｔｓ．ｃｏｍによって提供されるアドインアセンブリ。
以下のシナリオでは、新しいタイプのファイルをサポートするためにアドインを介して拡張できるファイルアプリケーションを説明する。このアプリケーションのアイデアは、ファイルタイプをサポートするアドインを有する限り、任意のタイプのファイルを開いて、示すことができるというものである。この例は、以下の３つの部分を有する：
・ＦｉｌｅＥｘｔｅｎｓｉｏｎＰｒｏｔｏｃｏｌアセンブリ
Ｆｉｌｅアプリケーションの拡張プロトコルを定義する。この拡張プロトコルは、メタデータスキーマおよび個々のファイルタグのシグネチャから構成される。この拡張プロトコルは、このアプリケーションと、様々なアドインとの両方がこの拡張プロトコルを参照できるようにするために、別々のアセンブリ内で定義される；
・Ｆｉｌｅアセンブリ
Ｆｉｌｅアプリケーションコード用のアセンブリ；
・ＳｍａｒｔＦｉｌｅｓＡｄｄＩｎアセンブリ
架空の会社Ｓｍａｒｔｓ．ｃｏｍによって提供されるアドインアセンブリ。
（ＦｉｌｅＥｘｔｅｎｓｉｏｎＰｒｏｔｏｃｏｌアセンブリ）
（Ｆｉｌｅアセンブリ）
（ＳｍａｒｔＦｉｌｅｓＡｄｄＩｎアセンブリ）
（付録Ａ：コーディング規約）
以下は、推奨されるＸＡＤコーディング規約のリストである。標準ＸＡＤフレームワークは、これらの規約のすべてに従う。サードパーティは、これらの規約の一部またはすべてを採用することを選択することができる。
以下は、推奨されるＸＡＤコーディング規約のリストである。標準ＸＡＤフレームワークは、これらの規約のすべてに従う。サードパーティは、これらの規約の一部またはすべてを採用することを選択することができる。
これらの規約は、ＸＡＤＣｏｐによって実施される。ＸＡＤＣｏｐは、趣旨において、．Ｎｅｔ ＦｒａｍｅｗｏｒｋにおけるＦｘＣｏｐに似たＸＡＤ固有チェッカである。
１２）＄ＴＯＤＯ： ＸＡＤＣｏｐドキュメンテーションが利用可能になったならば、それにリンクする
Ｓｙｓｔｅｍネームスペースの「ｓｙｓ」プレフィックス
１３）＄ＴＯＤＯ
名前のＰａｓｃａｌ式大文字小文字の区別
１４）＄ＴＯＤＯ
シグネチャ名は「Ｓｉｇｎａｔｕｒｅ」で終わらなければならない
１５）＄ＴＯＤＯ
「Ｓｅｔ」パラメータの名前は「ｓ」で終わらなければならない
１６）＄ＴＯＤＯ
「単一の」エンティティタグの名前は「ｓ」で終わってはならない
１７）＄ＴＯＤＯ
セレクタタグの名前は「Ｓｅｌｅｃｔｏｒ」で終わらなければならない
１８）＄ＴＯＤＯ
パラメータ（指定される場合）はエンティティの最初の属性でなければならない
１９）＄ＴＯＤＯ
名前（指定される場合）はパラメータ（指定される場合）の後のエンティティの最初の属性でなければならない
２０）＄ＴＯＤＯ
Ｓｙｓｔｅｍネームスペースの「ｓｙｓ」プレフィックス
１３）＄ＴＯＤＯ
名前のＰａｓｃａｌ式大文字小文字の区別
１４）＄ＴＯＤＯ
シグネチャ名は「Ｓｉｇｎａｔｕｒｅ」で終わらなければならない
１５）＄ＴＯＤＯ
「Ｓｅｔ」パラメータの名前は「ｓ」で終わらなければならない
１６）＄ＴＯＤＯ
「単一の」エンティティタグの名前は「ｓ」で終わってはならない
１７）＄ＴＯＤＯ
セレクタタグの名前は「Ｓｅｌｅｃｔｏｒ」で終わらなければならない
１８）＄ＴＯＤＯ
パラメータ（指定される場合）はエンティティの最初の属性でなければならない
１９）＄ＴＯＤＯ
名前（指定される場合）はパラメータ（指定される場合）の後のエンティティの最初の属性でなければならない
２０）＄ＴＯＤＯ
Claims (20)
- ソフトウェアアプリケーションの１つまたは複数の機能を実行するために、前記ソフトウェアアプリケーションを構成する方法を実行するコンピュータ実行可能命令が記憶されたコンピュータ読み取り可能な媒体であって、前記コンピュータ実行可能命令がコンピュータによって実行されたときに、前記方法は、
複数のアプリケーションコンポーネントを提供することと、
前記アプリケーションによって受信される１つまたは複数のデータイベントに基づいて、接続されたコンポーネントのグラフを形成するために、接続されたコンポーネントの前記グラフの構造と、前記複数のコンポーネントのうちのどれが前記複数のコンポーネントのうちの他のコンポーネントに接続されるかとを判定することと、
前記アプリケーションの第１の機能を提供するために、接続されたコンポーネントの前記グラフとして、前記複数のコンポーネントの一部を構成することと、
前記複数のコンポーネントのうちの１つによるデータイベントの受信に応答して、前記複数のコンポーネントのうちの１つまたは複数の他のコンポーネントによる処理を呼び出すことと、
前記複数のコンポーネントのうちの１つまたは複数の他のコンポーネントによる処理の呼び出しに応答して、前記アプリケーションの第２の機能を実行するために、接続されたコンポーネントの前記グラフを再構成することと
を備えることを特徴とするコンピュータ読み取り可能な媒体。 - 接続されたコンポーネントの前記グラフとして、前記複数のコンポーネントの一部を前記構成することは、
共通インターフェースを介して異なるタイプのコンポーネント間でデータを渡すことを可能にするために、アプリケーション記述エンジンによって、前記共通インターフェースを介して前記複数のコンポーネントの各々を前記複数のコンポーネントのうちの１つまたは複数の他のコンポーネントに接続することと、
接続されたコンポーネントの前記グラフが実行されるときに、接続されたコンポーネントの前記グラフが、前記アプリケーションの前記第１の機能を実行するように、接続されたコンポーネントの前記グラフ内の接続されたコンポーネント間のすべての接続を含む、接続されたコンポーネントの前記グラフを前記アプリケーション記述エンジンによってインスタンス化することと
をさらに含むことを特徴とする請求項１に記載のコンピュータ読み取り可能な媒体。 - 前記アプリケーションによって受信される１つまたは複数のデータイベントに基づいて、接続されたコンポーネントのグラフを形成するために、接続されたコンポーネントの前記グラフの構造と、前記複数のコンポーネントのうちのどれが前記複数のコンポーネントのうちの他のコンポーネントに接続されるかとを前記判定することは、
前記複数のコンポーネントのうちのどれが、接続されたコンポーネントの前記グラフ内の接続されたコンポーネントのユニットとして一緒にグループ化されなければならないかを判定することであって、接続されたコンポーネントの前記ユニットは、前記アプリケーションによって受信される前記１つまたは複数のデータイベントに応答して、前記アプリケーションの機能を実行するために必要である、判定すること
を含み、
前記アプリケーションの第１の機能を提供するために、接続されたコンポーネントの前記グラフとして、前記複数のコンポーネントの一部を前記構成することは、
前記アプリケーションによって受信される前記１つまたは複数のデータイベントに応答して、前記アプリケーションの機能を実行するために、接続されたコンポーネントのユニットとして一緒にグループ化されなければならない前記複数のコンポーネントを、コンポーネントドメインとして構成すること
を含むことを特徴とする請求項１に記載のコンピュータ読み取り可能な媒体。 - 前記複数のコンポーネントのうちの１つまたは複数の他のコンポーネントによる処理を前記呼び出すことは、
第１の処理フェーズにおいて、前記処理を呼び出す役割を担う前記データイベントに関連するデータを読み取って、接続されたコンポーネントの前記グラフに必要なすべての再構成を表すすべてのデータを要求することと、
第２の処理フェーズにおいて、前記アプリケーションの第２の機能を実行するために、接続されたコンポーネントの前記グラフを再構成することと
を含むことを特徴とする請求項１に記載のコンピュータ読み取り可能な媒体。 - 前記複数のコンポーネントのうちの１つまたは複数の他のコンポーネントによる処理を前記呼び出すことは、
前記データイベントに関連するコンポーネントドメインによる処理を呼び出すことと、
第１の処理フェーズにおいて、前記コンポーネントドメイン内で、前記処理を呼び出す役割を担う前記データイベントに関連するデータを読み取って、前記コンポーネントドメインに必要なすべての再構成を表すすべてのデータを要求することと、
第２の処理フェーズにおいて、前記コンポーネントドメイン内で、前記アプリケーションの第２の機能を実行するために、前記コンポーネントドメインを再構成することと
をさらに含むことを特徴とする請求項３に記載のコンピュータ読み取り可能な媒体。 - 前記アプリケーションによって受信される前記１つまたは複数のデータイベントに応答して、前記アプリケーションの機能を実行するためにコンポーネントドメインとして一緒に構成される前記コンポーネントは、
前記コンポーネントドメインが構成されるときから、前記コンポーネントドメインが前記コンポーネントドメインの再構成を必要とするデータイベントに応答して再構成されるときまでにまたがる有効期間の間に、アプリケーション実行のユニットとして動作する
ことを特徴とする請求項３に記載のコンピュータ読み取り可能な媒体。 - 接続されたコンポーネントの前記グラフを前記アプリケーション記述エンジンによって前記インスタンス化することは、
前記アプリケーションから、前記第１の機能を記述する１つまたは複数のアプリケーション記述を受信するように動作可能なアプリケーション記述エンジンによって、接続されたコンポーネントの前記グラフをインスタンス化すること
を含み、
前記方法は、
接続されたコンポーネントの前記グラフを形成するために、前記複数のコンポーネントのうちのどれを接続しなければならないかを判定するために、前記アプリケーション記述エンジンによって前記１つまたは複数のアプリケーション記述を解釈すること
をさらに備えることを特徴とする請求項２に記載のコンピュータ読み取り可能な媒体。 - 前記方法は、
接続されたコンポーネントの前記グラフを組み立てて構造化するための１つまたは複数の宣言ルールを、前記アプリケーション記述を介して受信することであって、前記アプリケーション記述エンジンは、前記アプリケーション記述を介して受信される前記宣言ルールに従って、接続されたコンポーネントの前記グラフをインスタンス化するようにさらに動作可能である、受信すること
をさらに備えることを特徴とする請求項７に記載のコンピュータ読み取り可能な媒体。 - 前記アプリケーションから、前記第１の機能を記述する１つまたは複数のアプリケーション記述を受信するように動作可能なアプリケーション記述エンジンによって、接続されたコンポーネントの前記グラフを前記インスタンス化することは、
前記アプリケーションから、前記第１の機能を記述する拡張マークアップ言語に従って構造化された１つまたは複数のアプリケーション記述を受信するように動作可能なアプリケーション記述エンジンによって、接続されたコンポーネントの前記グラフをインスタンス化すること
を含み、
前記アプリケーション記述エンジンは、前記複数のコンポーネントのうちの１つまたは複数に渡されるデータを、前記拡張マークアップ言語に従って構造化するようにさらに動作可能である
ことを特徴とする請求項７に記載のコンピュータ読み取り可能な媒体。 - 接続されたコンポーネントの前記グラフを前記アプリケーション記述エンジンによって前記インスタンス化する前に、
前記複数のコンポーネントを含むコンポーネントライブラリから、接続されたコンポーネントの前記グラフを含む前記複数のコンポーネントの前記一部を取り出す
ことを特徴とする請求項２に記載のコンピュータ読み取り可能な媒体。 - 前記複数のコンポーネントを含むコンポーネントライブラリから、接続されたコンポーネントの前記グラフを含む前記複数のコンポーネントの前記一部を前記取り出すことは、
ユーザインターフェースコネクタ、アクションコンポーネント、データコネクタ、アクセッサコンポーネント、トランスフォーマコンポーネント、およびインターフェースコンポーネントからなるコンポーネントのライブラリから、前記複数のコンポーネントの前記一部を取り出すこと
を含むことを特徴とする請求項１０に記載のコンピュータ読み取り可能な媒体。 - 前記複数のコンポーネントを含むコンポーネントライブラリから、接続されたコンポーネントの前記グラフを含む前記複数のコンポーネントの前記一部を前記取り出すことは、
１つまたは複数のユーザインターフェース（ＵＩ）イベントを受信し、前記１つまたは複数のＵＩイベントを前記データイベントに変換し、すべての変更されたデータに対応する標準フォーマットデータ表現を受信し、前記すべての変更されたデータをＵＩに提供するために前記ＵＩと接続する、少なくとも１つのＵＩコネクタを取り出すこと
を含むことを特徴とする請求項１０に記載のコンピュータ読み取り可能な媒体。 - 前記複数のコンポーネントを含むコンポーネントライブラリから、接続されたコンポーネントの前記グラフを含む前記複数のコンポーネントの前記一部を前記取り出すことは、
前記データイベントを受信し、該データイベントを標準フォーマットアクションに変換する、前記ＵＩコネクタに接続された少なくとも１つのアクションコンポーネントを取り出すこと
を含むことを特徴とする請求項１２に記載のコンピュータ読み取り可能な媒体。 - 前記複数のコンポーネントを含むコンポーネントライブラリから、接続されたコンポーネントの前記グラフを含む前記複数のコンポーネントの前記一部を前記取り出すことは、
前記標準フォーマットアクションを受信し、前記データに対する前記標準フォーマットアクションを完了するためにデータストアに接続し、前記標準フォーマットデータ表現を前記ＵＩコネクタに送信する、前記アクションコンポーネントと前記ＵＩコネクタとの両方に接続された少なくとも１つのデータコネクタを取り出すこと
を含むことを特徴とする請求項１３に記載のコンピュータ読み取り可能な媒体。 - 前記複数のコンポーネントを含むコンポーネントライブラリから、接続されたコンポーネントの前記グラフを含む前記複数のコンポーネントの前記一部を前記取り出すことは、
前記標準フォーマットデータ表現を、ＵＩ用にカスタマイズされたフォーマットに操作する少なくとも１つのトランスフォーマを取り出すこと
を含むことを特徴とする請求項１４に記載のコンピュータ読み取り可能な媒体。 - 前記複数のコンポーネントを含むコンポーネントライブラリから、接続されたコンポーネントの前記グラフを含む前記複数のコンポーネントの前記一部を前記取り出すことは、
前記標準フォーマットアクションを、標準フォーマットデータ用にカスタマイズされたアクションに操作する少なくとも１つのアクセッサコンポーネントを取り出すこと
を含むことを特徴とする請求項１５に記載のコンピュータ読み取り可能な媒体。 - 前記複数のコンポーネントを含むコンポーネントライブラリから、接続されたコンポーネントの前記グラフを含む前記複数のコンポーネントの前記一部を前記取り出すことは、
複数の他のコンポーネント間の通信を可能にするために、該複数の他のコンポーネント間のインターフェースを実装するサードパーティコンポーネントを取り出すこと
を含むことを特徴とする請求項１０に記載のコンピュータ読み取り可能な媒体。 - 前記方法は、
複数の他のコンポーネント間の通信を可能にするために、該複数の他のコンポーネント間のインターフェースを実装すること
をさらに備え、
該インターフェースを実装することは、
前記サードパーティコンポーネントによって、前記アプリケーション記述エンジンに提供される前記インターフェースを実装するための１つまたは複数の宣言ルールに従って、前記インターフェースを実装すること
を含むことを特徴とする請求項１７に記載のコンピュータ読み取り可能な媒体。 - ソフトウェアアプリケーションの１つまたは複数の機能を実行するために、前記ソフトウェアアプリケーションを構成する方法であって、
複数のアプリケーションコンポーネントを提供することと、
共通インターフェースを介して異なるタイプのコンポーネント間でデータを渡すことを可能にするために、アプリケーション記述エンジンによって、前記共通インターフェースを介して前記複数のコンポーネントの各々を前記複数のコンポーネントのうちの１つまたは複数の他のコンポーネントに接続することと、
前記複数のコンポーネントからなる接続されたコンポーネントのグラフが実行されるときに、接続されたコンポーネントの前記グラフが前記アプリケーションの第１の機能を実行するように、接続されたコンポーネントの前記グラフ内の接続されたコンポーネント間のすべての接続を含む、接続されたコンポーネントの前記グラフを前記アプリケーション記述エンジンによってインスタンス化することと
を備えることを特徴とする方法。 - ソフトウェアアプリケーションの１つまたは複数の機能を実行するために、前記ソフトウェアアプリケーションを構成する方法であって、
複数のアプリケーションコンポーネントを提供することと、
共通インターフェースを介して異なるタイプのコンポーネント間でデータを渡すことを可能にするために、アプリケーション記述エンジンによって、前記共通インターフェースを介して前記複数のコンポーネントの各々を前記複数のコンポーネントのうちの１つまたは複数の他のコンポーネントに接続することと、
前記複数のコンポーネントからなる接続されたコンポーネントのグラフが実行されるときに、接続されたコンポーネントの前記グラフが前記アプリケーションの第１の機能を実行するように、接続されたコンポーネントの前記グラフ内の接続されたコンポーネント間のすべての接続を含む、接続されたコンポーネントの前記グラフを前記アプリケーション記述エンジンによってインスタンス化することと、
前記複数のコンポーネントのうちの１つによるデータイベントの受信に応答して、前記複数のコンポーネントのうちの１つまたは複数の他のコンポーネントによる処理を呼び出すことと、
前記複数のコンポーネントのうちの１つまたは複数の他のコンポーネントによる処理の呼び出しに応答して、前記アプリケーションの第２の機能を実行するために、接続されたコンポーネントの前記グラフを再構成することと
を備えることを特徴とする方法。
Applications Claiming Priority (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US67613705P | 2005-04-29 | 2005-04-29 | |
| US60/676,137 | 2005-04-29 | ||
| US70322005P | 2005-07-28 | 2005-07-28 | |
| US60/703,220 | 2005-07-28 | ||
| US11/360,457 US8132148B2 (en) | 2005-04-29 | 2006-02-23 | XML application framework |
| US11/360,457 | 2006-02-23 | ||
| PCT/US2006/015161 WO2006118823A2 (en) | 2005-04-29 | 2006-04-20 | Xml application framework |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2008544338A true JP2008544338A (ja) | 2008-12-04 |
| JP5042993B2 JP5042993B2 (ja) | 2012-10-03 |
Family
ID=37235885
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2008508957A Expired - Fee Related JP5042993B2 (ja) | 2005-04-29 | 2006-04-20 | ソフトウェアアプリケーションを構成する方法 |
Country Status (4)
| Country | Link |
|---|---|
| US (2) | US8132148B2 (ja) |
| EP (1) | EP1875376A4 (ja) |
| JP (1) | JP5042993B2 (ja) |
| WO (1) | WO2006118823A2 (ja) |
Families Citing this family (38)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8275793B2 (en) * | 2005-04-29 | 2012-09-25 | Microsoft Corporation | Transaction transforms |
| US8418132B2 (en) * | 2005-04-29 | 2013-04-09 | Microsoft Corporation | Application description language |
| US20060245096A1 (en) * | 2005-04-29 | 2006-11-02 | Microsoft Corporation | Application framework phasing model |
| US8132148B2 (en) * | 2005-04-29 | 2012-03-06 | Microsoft Corporation | XML application framework |
| US8799857B2 (en) * | 2005-04-29 | 2014-08-05 | Microsoft Corporation | XML application framework |
| US7581225B2 (en) * | 2005-04-29 | 2009-08-25 | Microsoft Corporation | Multithreading with concurrency domains |
| US20080005752A1 (en) * | 2006-06-30 | 2008-01-03 | Robert Paul Morris | Methods, systems, and computer program products for generating application processes by linking applications |
| KR100948384B1 (ko) * | 2006-11-29 | 2010-03-22 | 삼성전자주식회사 | 권리객체의 이동이 가능한 디바이스와 휴대형 저장 장치 및권리객체의 이동 방법 |
| US8645909B2 (en) * | 2007-02-08 | 2014-02-04 | IdentityMine, Inc. | EvalBinding extension |
| US8190987B2 (en) * | 2007-10-25 | 2012-05-29 | Microsoft Corporation | Private views of data and local calculations during real time collaboration |
| US20090112570A1 (en) * | 2007-10-26 | 2009-04-30 | Microsoft Corporation | Declarative model interpretation |
| US8904276B2 (en) | 2008-11-17 | 2014-12-02 | At&T Intellectual Property I, L.P. | Partitioning of markup language documents |
| US8336027B2 (en) | 2009-05-27 | 2012-12-18 | Microsoft Corporation | Hierarchical view state storage |
| US20110035732A1 (en) * | 2009-08-06 | 2011-02-10 | Wynne Crisman | Method and apparatus for defining and compiling or converting language and user interface system agnostic view definitions to runnable code |
| US8510751B2 (en) | 2010-03-18 | 2013-08-13 | International Business Machines Corporation | Optimizing workflow engines |
| US8266126B2 (en) * | 2010-03-24 | 2012-09-11 | Matrixx Software, Inc. | System with multiple conditional commit databases |
| US8898628B2 (en) * | 2011-09-23 | 2014-11-25 | Ahmad RAZA | Method and an apparatus for developing software |
| WO2013063329A1 (en) * | 2011-10-25 | 2013-05-02 | Nicira, Inc. | Physical controllers for converting universal flows |
| US9178833B2 (en) | 2011-10-25 | 2015-11-03 | Nicira, Inc. | Chassis controller |
| US9164740B2 (en) * | 2013-05-16 | 2015-10-20 | Toshiba Global Commerce Solutions Holdings Corporation | System and method for replacing java beans |
| US9256751B2 (en) * | 2013-06-04 | 2016-02-09 | Sap Se | Public exposed objects |
| WO2015024237A1 (en) * | 2013-08-22 | 2015-02-26 | Successfactors, Inc. | Improved daily task tools that interface with backend systems |
| US9558014B2 (en) * | 2013-08-29 | 2017-01-31 | International Business Machines Corporation | System, method and apparatus for transparently enabling software applications with adaptive user interfaces |
| CN105706060B (zh) | 2013-09-04 | 2018-11-27 | 惠普发展公司，有限责任合伙企业 | 数据包的报头部分下载 |
| EP3049920A1 (de) | 2013-09-27 | 2016-08-03 | Rudolf Markus Petri | Verfahren und einrichtung zur automatisierten erzeugung und bereitstellung wenigstens einer softwareanwendung |
| US9158658B2 (en) | 2013-10-15 | 2015-10-13 | International Business Machines Corporation | Detecting merge conflicts and compilation errors in a collaborative integrated development environment |
| US10133586B2 (en) * | 2014-04-01 | 2018-11-20 | Henry Graber | Method to configure, control, and display data products from a user interface |
| US10108931B2 (en) * | 2014-09-26 | 2018-10-23 | Oracle International Corporation | Lock-based updating of a document |
| US10147158B2 (en) | 2014-12-13 | 2018-12-04 | Microsoft Technology Licensing, Llc | Frame invalidation control with causality attribution |
| US20160232470A1 (en) * | 2015-02-05 | 2016-08-11 | Keguo Zhou | Automated Generation of Process Flow Charts |
| SG10201507834SA (en) * | 2015-09-21 | 2017-04-27 | Yokogawa Electric Corp | Mobile based on collaborative and interactive operations with smart mobile devices |
| US10204122B2 (en) | 2015-09-30 | 2019-02-12 | Nicira, Inc. | Implementing an interface between tuple and message-driven control entities |
| US10768975B2 (en) * | 2016-03-04 | 2020-09-08 | Ricoh Company, Ltd. | Information processing system, information processing apparatus, and information processing method |
| US11019167B2 (en) | 2016-04-29 | 2021-05-25 | Nicira, Inc. | Management of update queues for network controller |
| US10203940B2 (en) * | 2016-12-15 | 2019-02-12 | Microsoft Technology Licensing, Llc | Compiler with type inference and target code generation |
| US10972567B2 (en) * | 2019-04-04 | 2021-04-06 | International Business Machines Corporation | Multi-dimensional tagging namespace for cloud resource management |
| EP3748518A1 (en) * | 2019-06-06 | 2020-12-09 | Siemens Aktiengesellschaft | Designing and building an automation system to perform rule-based transformations on complex technical systems |
| US20220138206A1 (en) * | 2020-10-30 | 2022-05-05 | Snowflake Inc. | System for implementing an object tagging framework |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2004227359A (ja) * | 2003-01-24 | 2004-08-12 | Hitachi Ltd | ポリシーに基づいたストレージシステムの運用管理方法 |
| JP2004258809A (ja) * | 2003-02-24 | 2004-09-16 | Kansai Electric Power Co Inc:The | 情報家電ネットワーク用ミドルウェア |
| JP2004280821A (ja) * | 2003-03-12 | 2004-10-07 | Microsoft Corp | ソフトウェアビジネスプロセスモデル |
| JP2004334896A (ja) * | 2000-04-10 | 2004-11-25 | Nec Corp | プラグアンドプレイ機能を有するフレームワークおよびその再構成方法 |
| US20060248449A1 (en) * | 2005-04-29 | 2006-11-02 | Microsoft Corporation | XML application framework |
Family Cites Families (135)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4943932A (en) * | 1986-11-25 | 1990-07-24 | Cimflex Teknowledge Corporation | Architecture for composing computational modules uniformly across diverse developmental frameworks |
| US5018097A (en) * | 1987-08-21 | 1991-05-21 | Siemens Aktiengesellschaft | Modularly structured digital communications system for interconnecting terminal equipment and public networks, and having operation and reliability programs |
| JPH0727505B2 (ja) * | 1990-02-12 | 1995-03-29 | インターナショナル・ビジネス・マシーンズ・コーポレイション | インターフェース方法及びインターフェース・システム |
| CA2061117C (en) | 1991-12-02 | 1998-09-29 | Neta J. Amit | Apparatus and method for distributed program stack |
| WO1993012488A1 (en) * | 1991-12-13 | 1993-06-24 | White Leonard R | Measurement analysis software system and method |
| US5392430A (en) | 1992-10-30 | 1995-02-21 | International Business Machines | Hierarchical scheduling method for processing tasks having precedence constraints on a parallel processing system |
| JPH06332711A (ja) | 1993-05-25 | 1994-12-02 | Fujitsu Ltd | データ処理システムにおけるオブジェクト管理処理方式 |
| US5519866A (en) | 1993-06-28 | 1996-05-21 | Taligent, Inc. | Method and apparatus of incrementally linking components of a modeled computer program |
| US6035321A (en) | 1994-06-29 | 2000-03-07 | Acis, Inc. | Method for enforcing a hierarchical invocation structure in real time asynchronous software applications |
| US5980096A (en) * | 1995-01-17 | 1999-11-09 | Intertech Ventures, Ltd. | Computer-based system, methods and graphical interface for information storage, modeling and stimulation of complex systems |
| US5805889A (en) | 1995-10-20 | 1998-09-08 | Sun Microsystems, Inc. | System and method for integrating editing and versioning in data repositories |
| US6721951B1 (en) | 1996-04-15 | 2004-04-13 | Microsoft Corporation | Data transfer utilizing single functionally independent data transfer mechanism |
| US6721941B1 (en) * | 1996-08-27 | 2004-04-13 | Compuware Corporation | Collection of timing and coverage data through a debugging interface |
| US6760903B1 (en) * | 1996-08-27 | 2004-07-06 | Compuware Corporation | Coordinated application monitoring in a distributed computing environment |
| US7054271B2 (en) * | 1996-12-06 | 2006-05-30 | Ipco, Llc | Wireless network system and method for providing same |
| US5951653A (en) | 1997-01-29 | 1999-09-14 | Microsoft Corporation | Method and system for coordinating access to objects of different thread types in a shared memory space |
| US5790855A (en) * | 1997-01-31 | 1998-08-04 | Sun Microsystems, Inc. | System, method and article of manufacture for type checking appropriateness of port connection and variable type matching in connection with multiport object-oriented components |
| US5842020A (en) * | 1997-01-31 | 1998-11-24 | Sun Microsystems, Inc. | System, method and article of manufacture for providing dynamic user editing of object oriented components used in an object oriented applet or application |
| GB2329490B (en) * | 1997-09-19 | 2002-06-05 | Ibm | Remote application design |
| US6339775B1 (en) | 1997-11-07 | 2002-01-15 | Informatica Corporation | Apparatus and method for performing data transformations in data warehousing |
| US5940828A (en) * | 1997-11-18 | 1999-08-17 | International Business Machines Corporation | Locking contention resolution for shared resources |
| US6256772B1 (en) * | 1997-11-24 | 2001-07-03 | International Business Machines Corporation | Multilingual hierarchial scripting environment |
| US6208336B1 (en) * | 1998-03-20 | 2001-03-27 | Sun Microsystems, Inc. | Dynamic graphical user interface feature-set configuration |
| US6083276A (en) | 1998-06-11 | 2000-07-04 | Corel, Inc. | Creating and configuring component-based applications using a text-based descriptive attribute grammar |
| US6205465B1 (en) | 1998-07-22 | 2001-03-20 | Cisco Technology, Inc. | Component extensible parallel execution of multiple threads assembled from program components specified with partial inter-component sequence information |
| US6256780B1 (en) | 1998-09-10 | 2001-07-03 | Microsoft Corp. | Method and system for assembling software components |
| US6272675B1 (en) | 1998-10-01 | 2001-08-07 | Unisys Corporation | Development system for automatically enabling a server application to execute with an XATMI-compliant transaction manager managing transactions within multiple environments |
| US6336118B1 (en) * | 1998-12-03 | 2002-01-01 | International Business Machines Corporation | Framework within a data processing system for manipulating program objects |
| US6826553B1 (en) | 1998-12-18 | 2004-11-30 | Knowmadic, Inc. | System for providing database functions for multiple internet sources |
| US6424948B1 (en) * | 1999-02-19 | 2002-07-23 | Guozhu Dong | Declarative workflow system supporting side-effects |
| US6718533B1 (en) | 1999-02-26 | 2004-04-06 | Real-Time Innovations, Inc. | Method for building a real-time control system with mode and logical rate |
| US6415434B1 (en) * | 1999-06-18 | 2002-07-02 | Hewlett-Packard Company | Apparatus and method for a runtime method overloading resolver |
| JP2001038796A (ja) | 1999-07-30 | 2001-02-13 | Nippon Plast Co Ltd | ブロー成形品及びブロー成形方法 |
| US6601233B1 (en) | 1999-07-30 | 2003-07-29 | Accenture Llp | Business components framework |
| US6601234B1 (en) | 1999-08-31 | 2003-07-29 | Accenture Llp | Attribute dictionary in a business logic services environment |
| US6854107B2 (en) | 1999-12-29 | 2005-02-08 | Baker Hughes Incorporated | Method of and system for designing an N-tier software architecture for use in generating software components |
| JP4925514B2 (ja) | 2000-02-29 | 2012-04-25 | 株式会社レーベン販売 | 内外イベントドリブン方式によるプログラム実行制御方法、プログラム、実行制御装置および記録媒体 |
| US6857008B1 (en) | 2000-04-19 | 2005-02-15 | Cisco Technology, Inc. | Arrangement for accessing an IP-based messaging server by telephone for management of stored messages |
| US7287259B2 (en) | 2000-04-24 | 2007-10-23 | Microsoft Corporation | Isolating assembly versions for binding to application programs |
| FR2810423A1 (fr) | 2000-06-16 | 2001-12-21 | Suntech | Systeme informatique modulaire et procede associe |
| US6670969B1 (en) | 2000-06-29 | 2003-12-30 | Curl Corporation | Interface frames for threads |
| US7039920B2 (en) | 2000-07-03 | 2006-05-02 | Oculus Technologies Corporation | Method and apparatus for providing a search engine for optimizing a decentralized or emergent model on a computer network |
| US6983464B1 (en) * | 2000-07-31 | 2006-01-03 | Microsoft Corporation | Dynamic reconfiguration of multimedia stream processing modules |
| JP2004506262A (ja) * | 2000-08-04 | 2004-02-26 | イントリンジック グラフィックス， インコーポレイテッド | グラフィックハードウェアおよびソフトウェアの開発 |
| JP3750504B2 (ja) | 2000-08-09 | 2006-03-01 | セイコーエプソン株式会社 | データ更新方法および情報処理装置 |
| US6795868B1 (en) | 2000-08-31 | 2004-09-21 | Data Junction Corp. | System and method for event-driven data transformation |
| US20020065950A1 (en) | 2000-09-26 | 2002-05-30 | Katz James S. | Device event handler |
| US9742614B2 (en) | 2000-09-28 | 2017-08-22 | Wellogix Technology Licensing, Llc | Data-type definition driven dynamic business component instantiation and execution framework |
| US6823518B1 (en) | 2000-10-17 | 2004-11-23 | Microsoft Corporation | Threading and communication architecture for a graphical user interface |
| EP1330709A2 (en) | 2000-11-03 | 2003-07-30 | Wilde Technologies Limited | A software development process |
| US20030204503A1 (en) | 2000-11-09 | 2003-10-30 | Lars Hammer | Connecting entities with general functionality in aspect patterns |
| US7031968B2 (en) * | 2000-12-07 | 2006-04-18 | Prev-U Israel Ltd. | Method and apparatus for providing web site preview information |
| US7200838B2 (en) | 2000-12-20 | 2007-04-03 | National Instruments Corporation | System and method for automatically generating a graphical program in response to a state diagram |
| US7085773B2 (en) | 2001-01-05 | 2006-08-01 | Symyx Technologies, Inc. | Laboratory database system and methods for combinatorial materials research |
| US20030236925A1 (en) * | 2001-05-17 | 2003-12-25 | Dusan Balek | Interactive portable object adapters support in an integrated development environment |
| US7043481B2 (en) | 2001-06-01 | 2006-05-09 | Thought, Inc. | System, method and software for creating, maintaining, navigating or manipulating complex data objects and their data relationships |
| US7367028B2 (en) | 2001-08-14 | 2008-04-29 | National Instruments Corporation | Graphically deploying programs on devices in a system |
| US7076483B2 (en) * | 2001-08-27 | 2006-07-11 | Xyleme Sa | Ranking nodes in a graph |
| US8473922B2 (en) * | 2001-09-19 | 2013-06-25 | Hewlett-Packard Development Company, L.P. | Runtime monitoring in component-based systems |
| US20030063120A1 (en) * | 2001-09-28 | 2003-04-03 | Wong Hoi Lee Candy | Scalable graphical user interface architecture |
| EP1298527A1 (en) * | 2001-09-28 | 2003-04-02 | Sony International (Europe) GmbH | A system for automatically creating a context information providing configuration |
| US7234111B2 (en) * | 2001-09-28 | 2007-06-19 | Ntt Docomo, Inc. | Dynamic adaptation of GUI presentations to heterogeneous device platforms |
| US7559032B2 (en) | 2001-10-12 | 2009-07-07 | National Instruments Corporation | System and method for enabling a graphical program to respond to user interface events |
| US7032210B2 (en) | 2001-11-11 | 2006-04-18 | International Business Machines Corporation | Method and system for generating program source code of a computer application from an information model |
| US6971004B1 (en) * | 2001-11-19 | 2005-11-29 | Cypress Semiconductor Corp. | System and method of dynamically reconfiguring a programmable integrated circuit |
| US20030135825A1 (en) * | 2001-12-05 | 2003-07-17 | Matthew Gertner | Dynamically generated mark-up based graphical user interfaced with an extensible application framework with links to enterprise resources |
| US6621295B1 (en) * | 2002-01-15 | 2003-09-16 | Xilinx, Inc. | Reconfigurable priority encoding |
| US7228326B2 (en) | 2002-01-18 | 2007-06-05 | Bea Systems, Inc. | Systems and methods for application deployment |
| US7240243B2 (en) | 2002-03-28 | 2007-07-03 | International Business Machines Corporation | System and method for facilitating programmable coverage domains for a testcase generator |
| US20040051739A1 (en) * | 2002-06-20 | 2004-03-18 | Schmickley Michael J. | Alarm graphic editor with automatic update |
| AU2003245660A1 (en) | 2002-06-24 | 2004-01-06 | National Instruments Corporation | Task based polymorphic graphical program function nodes |
| US7412497B2 (en) * | 2002-07-25 | 2008-08-12 | Sun Microsystems, Inc. | Generation of Administration framework for server systems |
| US7206827B2 (en) * | 2002-07-25 | 2007-04-17 | Sun Microsystems, Inc. | Dynamic administration framework for server systems |
| US6704656B1 (en) * | 2002-10-18 | 2004-03-09 | Schlumberger Technology Corporation | Method, apparatus and computer program product to allow automatic product composition |
| US7222332B2 (en) | 2002-10-24 | 2007-05-22 | International Business Machines Corporation | Method and apparatus for overlay management within an integrated executable for a heterogeneous architecture |
| US7181744B2 (en) | 2002-10-24 | 2007-02-20 | International Business Machines Corporation | System and method for transferring data between virtual machines or other computer entities |
| US20040083238A1 (en) | 2002-10-24 | 2004-04-29 | General Electric Company | Method, system, and storage medium for integrating project management tools |
| US6983456B2 (en) * | 2002-10-31 | 2006-01-03 | Src Computers, Inc. | Process for converting programs in high-level programming languages to a unified executable for hybrid computing platforms |
| US7290138B2 (en) * | 2003-02-19 | 2007-10-30 | Microsoft Corporation | Credentials and digitally signed objects |
| US7779405B2 (en) | 2003-03-14 | 2010-08-17 | At&T Intellectual Property I, L.P. | Run-time determination of application delivery |
| US20040187090A1 (en) | 2003-03-21 | 2004-09-23 | Meacham Randal P. | Method and system for creating interactive software |
| US7827524B2 (en) | 2003-04-22 | 2010-11-02 | Computer Associates Think, Inc. | System and method for integrating object-oriented model profiles and object-oriented programming languages |
| US7496574B2 (en) | 2003-05-01 | 2009-02-24 | International Business Machines Corporation | Managing locks and transactions |
| US7558841B2 (en) | 2003-05-14 | 2009-07-07 | Microsoft Corporation | Method, system, and computer-readable medium for communicating results to a data query in a computer network |
| US20040230945A1 (en) | 2003-05-15 | 2004-11-18 | Bryant Deborah E. | Integration of a configuration tool with a graphical program language |
| US20040235520A1 (en) | 2003-05-20 | 2004-11-25 | Cadiz Jonathan Jay | Enhanced telephony computer user interface allowing user interaction and control of a telephone using a personal computer |
| US7240327B2 (en) * | 2003-06-04 | 2007-07-03 | Sap Ag | Cross-platform development for devices with heterogeneous capabilities |
| JP4028444B2 (ja) | 2003-06-27 | 2007-12-26 | 株式会社東芝 | スケジューリング方法およびリアルタイム処理システム |
| JP2005043962A (ja) | 2003-07-22 | 2005-02-17 | Nippon Telegr & Teleph Corp <Ntt> | 分散サーバシステム、サーバ、アプリケーションプロセス起動制御方法、及びプログラム |
| CA2476156A1 (en) * | 2003-07-30 | 2005-01-30 | J2X Technologies Inc. | System, computer product and method for enabling wireless data synchronization |
| EP1660994A2 (en) * | 2003-08-07 | 2006-05-31 | National Instruments Corporation | A graphical program which executes a timed loop |
| US7650589B2 (en) * | 2003-08-15 | 2010-01-19 | National Instruments Corporation | Signal analysis function blocks and method of use |
| US7506307B2 (en) | 2003-10-24 | 2009-03-17 | Microsoft Corporation | Rules definition language |
| US7526771B2 (en) | 2003-11-12 | 2009-04-28 | Ntt Docomo, Inc. | Method and apparatus for configuring an application while the application is running |
| US7324931B1 (en) * | 2003-11-17 | 2008-01-29 | The Mathworks, Inc. | Conversion of model components into references |
| US7194663B2 (en) | 2003-11-18 | 2007-03-20 | Honeywell International, Inc. | Protective bus interface and method |
| US7287023B2 (en) * | 2003-11-26 | 2007-10-23 | International Business Machines Corporation | Index structure for supporting structural XML queries |
| US7676785B2 (en) | 2004-02-13 | 2010-03-09 | Microsoft Corporation | Hosted application as a designer in an integrated development environment |
| US7570267B2 (en) * | 2004-05-03 | 2009-08-04 | Microsoft Corporation | Systems and methods for providing an enhanced graphics pipeline |
| US7836426B2 (en) | 2004-05-06 | 2010-11-16 | National Instruments Corporation | Automatic generation of application domain specific graphical programs |
| US8063936B2 (en) * | 2004-06-01 | 2011-11-22 | L-3 Communications Corporation | Modular immersive surveillance processing system and method |
| US7730482B2 (en) * | 2004-06-08 | 2010-06-01 | Covia Labs, Inc. | Method and system for customized programmatic dynamic creation of interoperability content |
| EP1787197A2 (en) * | 2004-09-10 | 2007-05-23 | Graphlogic Inc. | Object process graph application development system |
| US7703027B2 (en) | 2005-01-13 | 2010-04-20 | National Instruments Corporation | Merging graphical programs |
| US8051148B2 (en) | 2005-01-13 | 2011-11-01 | National Instruments Corporation | Determining differences between configuration diagrams |
| US7987445B2 (en) | 2005-01-13 | 2011-07-26 | National Instruments Corporation | Comparing a configuration diagram to an actual system |
| JP4348546B2 (ja) * | 2005-01-20 | 2009-10-21 | ソニー株式会社 | 信号処理装置、信号処理プログラムおよび記録媒体 |
| US7383285B1 (en) | 2005-03-08 | 2008-06-03 | Unisys Corporation | Method for exposing hierarchical table structures and relationships to OLE DB applications |
| JP4457925B2 (ja) * | 2005-03-11 | 2010-04-28 | ヤマハ株式会社 | 編集装置、音響信号処理システム及びプログラム |
| US7657868B2 (en) | 2005-03-14 | 2010-02-02 | Research In Motion Limited | System and method for applying development patterns for component based applications |
| JP4622611B2 (ja) * | 2005-03-24 | 2011-02-02 | ソニー株式会社 | 信号処理装置 |
| US7653903B2 (en) * | 2005-03-25 | 2010-01-26 | Sony Corporation | Modular imaging download system |
| US7559054B2 (en) | 2005-04-19 | 2009-07-07 | Microsoft Corporation | Abstract interpretation with a congruence abstract domain and/or a heap succession abstract domain |
| US20060247936A1 (en) * | 2005-04-28 | 2006-11-02 | International Business Machines Corporation | Business Activity Creation Using Business Context Services for Adaptable Service Oriented Architecture Components |
| US7739691B2 (en) | 2005-04-29 | 2010-06-15 | Microsoft Corporation | Framework for declarative expression of data processing |
| US8418132B2 (en) | 2005-04-29 | 2013-04-09 | Microsoft Corporation | Application description language |
| US7581225B2 (en) | 2005-04-29 | 2009-08-25 | Microsoft Corporation | Multithreading with concurrency domains |
| US8275793B2 (en) | 2005-04-29 | 2012-09-25 | Microsoft Corporation | Transaction transforms |
| US20060245096A1 (en) | 2005-04-29 | 2006-11-02 | Microsoft Corporation | Application framework phasing model |
| US8799857B2 (en) | 2005-04-29 | 2014-08-05 | Microsoft Corporation | XML application framework |
| US20060253830A1 (en) | 2005-05-06 | 2006-11-09 | Rajanala Arun K | Guiding application building using business constraint metadata |
| US8510711B2 (en) | 2006-05-30 | 2013-08-13 | Siemens Aktiengesellschaft | Central strategy management component for providing semantic-free administration functions for a system of applications |
| US8863102B2 (en) | 2007-04-02 | 2014-10-14 | International Business Machines Corporation | Method and system for assembling information processing applications based on declarative semantic specifications |
| US8166465B2 (en) | 2007-04-02 | 2012-04-24 | International Business Machines Corporation | Method and system for composing stream processing applications according to a semantic description of a processing goal |
| US8087010B2 (en) | 2007-09-26 | 2011-12-27 | International Business Machines Corporation | Selective code generation optimization for an advanced dual-representation polyhedral loop transformation framework |
| US8087011B2 (en) | 2007-09-26 | 2011-12-27 | International Business Machines Corporation | Domain stretching for an advanced dual-representation polyhedral loop transformation framework |
| US8056065B2 (en) | 2007-09-26 | 2011-11-08 | International Business Machines Corporation | Stable transitions in the presence of conditionals for an advanced dual-representation polyhedral loop transformation framework |
| US8201147B2 (en) | 2008-02-08 | 2012-06-12 | Microsoft Corporation | Generic XAD processing model |
| US20090288069A1 (en) | 2008-05-15 | 2009-11-19 | One Microsoft Way | Dynamic Declarative Application Description |
| US8434053B2 (en) | 2008-11-26 | 2013-04-30 | Red Hat, Inc. | Package review process workflow |
| US8352914B2 (en) | 2008-12-15 | 2013-01-08 | Accenture Global Services Limited | Impact analysis of software change requests |
| US8302077B2 (en) | 2009-03-13 | 2012-10-30 | Oracle America, Inc. | Method and system for configuring software modules to execute in an execution environment |
| US8418165B2 (en) | 2009-05-27 | 2013-04-09 | Microsoft Corporation | Package design and generation |
| US8531451B2 (en) | 2009-06-19 | 2013-09-10 | Microsoft Corporation | Data-driven visualization transformation |
| US8843904B2 (en) | 2010-01-26 | 2014-09-23 | International Business Machines Corporation | Automated building and retargeting of architecture-dependent assets |
-
2006
- 2006-02-23 US US11/360,457 patent/US8132148B2/en not_active Expired - Fee Related
- 2006-04-20 JP JP2008508957A patent/JP5042993B2/ja not_active Expired - Fee Related
- 2006-04-20 WO PCT/US2006/015161 patent/WO2006118823A2/en active Application Filing
- 2006-04-20 EP EP06751026A patent/EP1875376A4/en not_active Withdrawn
-
2012
- 2012-03-02 US US13/410,383 patent/US8793649B2/en not_active Expired - Fee Related
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2004334896A (ja) * | 2000-04-10 | 2004-11-25 | Nec Corp | プラグアンドプレイ機能を有するフレームワークおよびその再構成方法 |
| JP2004227359A (ja) * | 2003-01-24 | 2004-08-12 | Hitachi Ltd | ポリシーに基づいたストレージシステムの運用管理方法 |
| JP2004258809A (ja) * | 2003-02-24 | 2004-09-16 | Kansai Electric Power Co Inc:The | 情報家電ネットワーク用ミドルウェア |
| JP2004280821A (ja) * | 2003-03-12 | 2004-10-07 | Microsoft Corp | ソフトウェアビジネスプロセスモデル |
| US20060248449A1 (en) * | 2005-04-29 | 2006-11-02 | Microsoft Corporation | XML application framework |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2006118823A3 (en) | 2009-05-14 |
| WO2006118823A2 (en) | 2006-11-09 |
| EP1875376A4 (en) | 2011-08-31 |
| US8793649B2 (en) | 2014-07-29 |
| EP1875376A2 (en) | 2008-01-09 |
| US20120167039A1 (en) | 2012-06-28 |
| US20060248449A1 (en) | 2006-11-02 |
| JP5042993B2 (ja) | 2012-10-03 |
| US8132148B2 (en) | 2012-03-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5042993B2 (ja) | ソフトウェアアプリケーションを構成する方法 | |
| US8046737B2 (en) | XML application framework | |
| CN101512503B (zh) | Xml应用程序框架 | |
| JP5021193B2 (ja) | 拡張可能ワークフローモデルの宣言的表現 | |
| JP5710852B2 (ja) | 設計時および実行時にワークフローを継ぎ目なくオーサリングし編集するためのフレームワーク | |
| JP4806240B2 (ja) | コンポーネント化された拡張可能なワークフローモデル | |
| US7793255B1 (en) | System and method for maintaining alternate object views | |
| US8375351B2 (en) | Extensible rapid application development for disparate data sources | |
| US20050188349A1 (en) | Data association | |
| US20050188350A1 (en) | Data binding | |
| WO2006118872A2 (en) | Application description language | |
| JP2006107479A (ja) | ワークフロー領域内の分野横断的動作問題（ｃｒｏｓｓ−ｃｕｔｔｉｎｇｂｅｈａｖｉｏｒａｌｃｏｎｃｅｒｎｓ）をモデル化するためのフレームワーク | |
| JP2006107480A (ja) | フローベースおよび制約ベースのワークフローをオーサリングし、実行するための統一モデル | |
| US20090288069A1 (en) | Dynamic Declarative Application Description | |
| US8201147B2 (en) | Generic XAD processing model | |
| US20060089941A1 (en) | Data source objects for producing collections of data items | |
| MacDonald et al. | Pro Asp. net 2.0 in C# 2005 | |
| Radjenovic et al. | The role of dependency links in ensuring architectural view consistency | |
| Abrams et al. | User interface markup language (UIML) specification | |
| Fernandez | BPEL with Explicit Data Flow: Model, Editor, and Partitioning Tool | |
| Osenkov | Designing, implementing and integrating a structured C# code editor | |
| Helms et al. | User Interface Markup Language (UIML) Version 4.0 | |
| Solano | Exploring How Model Oriented Programming Can Be Extended to the User Interface Level | |
| Narraway | An Example of a Synergistic Relationship Between Software Architecture and a Domain-Specific Language | |
| Bukovics | Workflow Serialization and Markup |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20090323 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20111116 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20111125 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20120227 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20120316 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20120615 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20120706 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20120711 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20150720 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |