JP2009283010A - オブジェクトの階層を定義するための宣言的（ｄｅｃｌａｔｉｖｅ）機構 - Google Patents

Abstract

【課題】オブジェクトを宣言的に定義するための方法を提供すること。
【解決手段】少なくとも１つの名前空間を有する定義ファイルの位置のＵＲＬをルートタグおよびマッピングタグのうちの一方のｘｍｌｎｓ属性にマップするステップと、当該少なくとも１つの名前空間内のクラス名にタグ名を設定するステップと、当該オブジェクトがプロパティ設定を有している場合、プロパティ名に当該タグの属性を設定するステップとを含む。
【選択図】図３

Description

本発明は一般にコンピュータシステムに関し、より詳細には、オブジェクトおよびオブジェクト型の階層を宣言的に作成するための方法およびシステムに関する。

マークアップ言語は一般に、作成しやすく、理解しやすい。拡張可能なマークアップ言語は、一般にＸＭＬとして知られており、今日使用されている最も一般的なマークアップ言語の１つである。ＸＭＬとは、構造化された情報をＷｅｂに運ぶように設計されている形式である。これは、電子データ交換用のＷｅｂベースの言語である。ＸＭＬは、ハイパーテキストマークアップ言語（ＨＴＭＬ）および他のＷｅｂ関連の標準を維持し、促進する責任を負う標準化団体であるＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ（Ｗ３Ｃ）のオープンな技術標準である。

ＸＭＬは、不必要な機能を削除しながらコンテキストによる分離という構造的に重要な側面を保つ標準一般化マークアップ言語（ＳＧＭＬ）の一部である。ＸＭＬ文書形式は、その構造を表すタグ内にその内容を埋め込む。また、ＸＭＬは、文書の文法の規則を表す能力も提供する。これら２つの特徴によって、データおよびメタデータの自動的な分離が可能となり、一般のツールがその文法に対してＸＭＬ文書を確認することができる。

ＸＭＬは、システム統合のために設計されている。ＸＭＬは、広範囲に実施可能であり、配備しやすいことがわかっている、データの構造的表現を提供する。タグの存在によってマークされた情報を要素と呼ぶ。一致した開始タグおよび終了タグを使用して情報をマークアップする。属性と呼ばれる名前値の対を付加することによって、要素をさらに説明することができる。ＸＭＬ要素は、その関連するデータを任意の所望のデータ要素であると宣言することができる。例えば、要素は小売価格、本のタイトルなどとすることができる。現在ＸＭＬは、アプリケーションデータ（ビジネス文書、ＥＤＩメッセージなど）、アプリケーションのユーザインターフェース、ＸＨＴＭＬ、および固定された１組のタグを有する他の文法の文法ベースの表現に適用されている。

こうした文法ベースの表現は、固定された１組のタグを容易に拡張して新しいタイプのＸＭＬ要素を作成することができる能力がないという点で限られている。さらに、コンピュータ業界がオブジェクト指向のプログラミングに着々と移行していくにつれて、ＸＭＬは、拡張可能な構成要素のオブジェクトを十分に表さなくなってきている。これらのオブジェクトは、他のソフトウェアプログラムによって再利用可能であり、新しいオブジェクトは、既存のオブジェクトから容易に拡張することができる。その結果、プログラマは、オブジェクトの階層を、宣言的にではなく、プログラム言語でプログラム的に作成することが多い。オブジェクトの階層は、使用時にはいつでもプログラミング言語で作成する必要がある。

オブジェクトおよび型の階層をプログラムロジックとともに宣言的に作成する能力をプログラマに提供するシステムを、当業者は逃してきた。

本発明は、オブジェクトの階層をマークアップ言語で宣言的に定義する機構を指向する。こうしたオブジェクトには、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴ ｆｒａｍｅｗｏｒｋの共通言語ランタイム型などのオブジェクトがある。ユーザインターフェースなどの項目を実施する従来の方法では、項目は同期に作成する必要がある。非常に大きい項目の場合、項目のロードは、時間により制限される可能性がある。本発明は、１つの階層（すなわちツリー）内のオブジェクトを同期または非同期に作成できる能力をユーザに提供する。

マークアップ言語はＸＭＬベースである。オブジェクトは、マッピングに基づくマークアップ言語で書かれる。マッピングは、オブジェクトクラスが指定されるアセンブリおよび名前空間を有する定義ファイルの位置を定義するＵＲＬ属性を含む。マークアップ言語によるタグ名は、クラス名にマップされる。タグの属性は、タグに関連するクラスのプロパティおよびイベントにマップされる。クラスに直接マップされない属性は、定義タグで定義される。また、プログラミングコードのページへの追加にも定義タグを使用する。

本発明はさらに、マークアップ言語を解析してオブジェクトの階層を作成する方法を含む。本発明の機構によってタグがマップされているクラスが検索されるように、定義ファイルを使用してオブジェクトクラスがどこに配置されているかを決定する。クラスが決定されると、クラスのプロパティセクションおよびイベントセクションで属性名が検索される。クラスのオブジェクトのインスタンスが作成される。属性は、複合プロパティを使用して指定することができる。

本発明は、マークアップ言語を使用してユーザインターフェース、ベクトル図形、および文書などの項目を同期または非同期に作成する機能を提供する。文書には、固定形式文書、および適応的フロー（ａｄａｐｔｉｖｅ−ｆｌｏｗ）文書などがある。固定形式文書とは、装置に依存しないやり方で、ページ数および各ページでのオブジェクトの位置を明示的に定義する文書である。適応的フロー文書とは、ページサイズが変更されるたびに、自動的にページを付け直し、各ページにおいてオブジェクトを再配置することができる文書である。

本発明の他の特徴および利点は、添付の図面を参照して進める以下の実施形態の例の詳細な説明から明らかになる。

本発明が存在するコンピュータシステムの例を示す概略ブロック図である。 本発明が動作可能な環境の例を示す概略ブロック図である。 マークアップ言語と図２の環境の例との間のマッピングを示す概略ブロック図である。 本発明によるマークアップファイルを解析する諸ステップを示すフロー図である。

添付の特許請求の範囲には本発明の特徴を詳細に記載しているが、本発明、およびその目的および利点は、添付の図面を併せ読むことによって、以下の詳細な説明から最もよく理解できる。

本発明は、ユーザが、オブジェクトの階層、およびオブジェクトの階層の背後にあるプログラムロジックをＸＭＬベースのマークアップ言語により指定できる機構を提供する。これによって、オブジェクトモデルをＸＭＬで記述する能力が提供される。１つの結果は、Ｍｉｃｒｏｓｏｆｔ社による．Ｎｅｔ Ｆｒａｍｅｗｏｒｋの共通言語ランタイム（ＣＬＲ）でのクラスなど拡張可能なクラスにＸＭＬでアクセスできることである。ＣＬＲでのクラスの数は増え続けている。これは、オブジェクトモデルのＸＭＬ表現が動的に増加していることを意味する。本明細書で説明するように、この機構は、ＸＭＬタグのＣＬＲオブジェクトへの直接のマッピングおよび関連するコードをマークアップで表す能力を提供する。この機構を使用して、固定形式文書、適応的フロー文書、ベクトル図形、アプリケーションユーザインターフェースおよびコントロールなど、および上記の任意の組合せを、ＸＭＬマークアップによって作成することができる。

図面を参照すると、図中、同様の参照番号は同様の要素を指しており、本発明を適したコンピューティング環境で実施されるものとして示している。必須ではないが、本発明は、パーソナルコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で説明することができる。一般にプログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、構成要素、データ構造などを含む。さらに、本発明は、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラム可能家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む他のコンピュータシステム構成で実施できることを当業者であれば理解できよう。また、本発明は、タスクが通信ネットワークによってリンクされているリモート処理装置によって実行される分散コンピューティング環境で実施できる。分散コンピューティング環境では、プログラムモジュールを、ローカルおよびリモートのメモリ記憶装置に置くことができる。

図１は、本発明を実施できる、適したコンピューティングシステム環境１００の例を示している。コンピューティングシステム環境１００は、適したコンピューティング環境の一例にすぎず、本発明の使用または機能の範囲に関する限定を示唆するものではない。また、コンピューティングシステム環境１００を、動作環境（符号１００）の例に示した構成要素のいずれか１つ、またはその組合せに関連する依存性または必要条件を有しているものと解釈すべきではない。

本発明は、他の多くの汎用または専用コンピューティングシステム環境または構成で動作可能である。本発明との使用に適したよく知られているコンピューティングシステム、環境、および／または構成の例には、それだけには限定されないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記の任意のシステムまたは装置を含む分散コンピューティング環境などがある。

本発明は、コンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で説明することができる。一般にプログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、構成要素、データ構造などを含む。また、本発明は、タスクが通信ネットワークによってリンクされているリモート処理装置によって実行される分散コンピューティング環境で実施できる。分散コンピューティング環境では、プログラムモジュールを、メモリ記憶装置を含むローカルおよびリモートのコンピュータ記憶媒体に置くことができる。

図１を参照すると、本発明を実施するシステムの例は、汎用コンピューティング装置をコンピュータ１１０の形で含んでいる。コンピュータ１１０の構成要素は、それだけには限定されないが、処理ユニット１２０、システムメモリ１３０、およびシステムメモリを含む様々なシステム構成要素を処理ユニット１２０に結合するシステムバス１２１を含む。システムバス１２１は、様々なバスアーキテクチャのうちの任意のものを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含むいくつかのタイプのバス構造のうちどんなものでもよい。こうしたアーキテクチャには、それだけには限定されないが一例として、ＩＳＡ（Ｉｎｄｕｓｔｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄ Ａｓｓｏｃｉｔｅ）ローカルバス、およびメザニンバスとしても知られているＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスなどがある。

コンピュータ１１０は、一般に様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０からアクセスできる使用可能な任意の媒体とすることができ、揮発性および不揮発性媒体、リムーバブルおよび非リムーバブル媒体を含む。コンピュータ可読媒体は、それだけには限定されないが一例として、コンピュータ記憶媒体および通信媒体を含み得る。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、他のデータなど、情報を記憶するための任意の方法または技術で実施される揮発性および不揮発性のリムーバブルおよび非リムーバブル媒体がある。コンピュータ記憶媒体には、それだけには限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶装置、または所望の情報の格納に使用でき、コンピュータ１１０からアクセスできる他の任意の媒体などがある。通信媒体は一般に、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを搬送波または他の移送機構などの変調されたデータ信号に組み込む。これには任意の情報配送媒体がある。「変調されたデータ信号」という用語は、信号内の情報を符号化するように設定または変更された１つまたは複数のその特徴を有する信号を意味する。通信媒体には、それだけには限定されないが一例として、有線ネットワーク、直接配線された接続などの有線媒体、および音響、ＲＦ、赤外線、その他の無線媒体などの無線媒体がある。また、上記のどんな組合せもコンピュータ可読媒体の範囲内に含まれるものとする。

システムメモリ１３０は、読取り専用メモリ（ＲＯＭ）１３１やランダムアクセスメモリ（ＲＡＭ）１３２など、揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を含む。ＢＩＯＳ（ｂａｓｉｃ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｓｙｓｔｅｍ）１３３は、例えば起動中など、コンピュータ１１０内の要素間での情報の転送を助ける基本ルーチンを含み、一般にＲＯＭ１３１に格納されている。ＲＡＭ１３２は一般に、処理ユニット１２０から直接アクセス可能な、かつ／または処理ユニット１２０が現在処理しているデータおよび／またはプログラムモジュールを含む。図１は、それだけには限定されないが一例として、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示している。

コンピュータ１１０は、他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピュータ記憶媒体を含むこともできる。一例にすぎないが、図１は、非リムーバブル不揮発性磁気媒体から読み取り、あるいはそこに書き込むハードディスクドライブ１４１、リムーバブル不揮発性磁気ディスク１５２から読み取り、あるいはそこに書き込む磁気ディスクドライブ１５１、およびＣＤ−ＲＯＭや他の光媒体など、リムーバブル不揮発性光ディスク１５６から読み取り、あるいはそこに書き込む光ディスクドライブ１５５を示している。動作環境の例で使用できる他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピュータ記憶媒体には、それだけには限定されないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、半導体ＲＡＭ、半導体ＲＯＭなどがある。ハードディスクドライブ１４１は一般に、インターフェース１４０などの非リムーバブルメモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は一般に、インターフェース１５０などのリムーバブルメモリインターフェースによってシステムバス１２１に接続される。

上述し、図１に示したドライブおよびその関連のコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびコンピュータ１１０の他のデータの記憶を提供する。図１では例えば、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を記憶するものとして示されている。これらの構成要素は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じであっても、異なっていてもよいことに注意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７は少なくとも異なるコピーであることを示すために、ここではそれらに異なる番号を付している。ユーザは、キーボード１６２、および一般にマウス、トラックボール、またはタッチパッドと呼ばれるポインティング装置１６１などの入力装置を介してコマンドおよび情報をコンピュータ１１０に入力することができる。他の入力装置（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどがある。これらおよび他の入力装置は、しばしばシステムバスに結合されているユーザ入力インターフェース１６０を介して処理ユニット１２０に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）など他のインターフェースおよびバス構造で接続してもよい。モニタ１９１または他のタイプの表示装置もまた、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタに加えて、コンピュータは、出力周辺インターフェース１９５などを介して接続できるスピーカー１９７、プリンタ１９６などの他の周辺出力装置を含むこともできる。

コンピュータ１１０は、リモートコンピュータ１８０など１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク式環境で操作することができる。リモートコンピュータ１８０は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、または他の一般のネットワークノードでよく、一般にパーソナルコンピュータ１１０に関連して上述した多くまたはすべての要素を含むが、図１にはメモリ記憶装置１８１のみを示している。図１に示した論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１および広域エリアネットワーク（ＷＡＮ）１７３を含むが、他のネットワークを含んでいてもよい。こうしたネットワーキング環境は、オフィス、全社規模のコンピュータネットワーク、イントラネット、およびインターネットではごく一般的である。

ＬＡＮネットワーキング環境で使用する場合、パーソナルコンピュータ１１０は、ネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用する場合、コンピュータ１１０は一般に、モデム１７２、またはインターネットなどＷＡＮ１７３を介して通信を確立する他の手段を含む。モデム１７２は、内蔵のものでも外付けのものでもよく、ユーザ入力インターフェース１６０または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク式環境では、パーソナルコンピュータ１１０に関連して示したプログラムモジュール、またはその一部をリモートメモリ記憶装置に格納することができる。図１は、それだけには限定されないが一例として、リモートアプリケーションプログラム１８５をメモリ装置１８１上に存在するものとして示している。図示したネットワーク接続は例であり、コンピュータ間の通信リンクを確立する他の手段を使用してもよいことは理解されよう。

以下の説明では、特に指定のない限り、１つまたは複数のコンピュータによって実行される動作および操作のシンボルを参照して本発明を説明する。したがって、コンピュータで実行されると言うこともあるこうした動作および操作が、コンピュータの処理単位による構造化された形式のデータを表す電気信号の操作を含むことは理解されよう。この操作は、データを変換し、またはコンピュータのメモリシステムのいくつかの場所にデータを維持し、これによって当業者にはよく理解されているようにコンピュータが再構成され、そうでない場合はその動作が変更される。データが維持されるデータ構造は、データの形式で定義された特定の特性を有するメモリの物理位置である。しかし、本発明を上記の文脈で説明しているが、以下に記載する様々な動作および操作をハードウェアでも実施できることを当業者であれば理解できるので、これに限定されるものではない。

上記に示したように、．ＮＥＴ ＦｒａｍｅｗｏｒｋのＣＬＲでの拡張可能なクラスには、本発明ではＸＭＬでアクセスすることができる。必ずしも必要ではないが、本発明が提供する利益をよりよく理解するために．ＮＥＴ ｆｒａｍｅｗｏｒｋの概略が有益となり得る。ここで図２を参照すると、最も簡単に表現した．ＮＥＴ ｆｒａｍｅｗｏｒｋ２００は、ＣＬＲ２０２、フレームワーククラスライブラリ２０４、ユーザインターフェース２０６、およびＷｅｂサービスおよびアプリケーション２０８から成る。．ＮＥＴ ｆｒａｍｅｗｏｒｋは、オペレーティングシステム１３４など、マシンのオペレーティングシステムに存在する。

ユーザインターフェース２０６およびＷｅｂサービスおよびアプリケーション２０８は、ファイルアクセスを含む一般の入／出力、ＸＭＬサポート、およびサービスを提供する。これらは、ＨＴＴＰからＨＴＭＬへのＷｅｂ技術およびサービスを公開し、Ｗｅｂページおよび／または従来のＷｉｎｄｏｗｓ（登録商標）ベースのユーザインターフェースを構築するユーザインターフェース要素を提供し、ＡＳＰ．ＮＥＴおよび他の多くのサービスを公開する。

ＣＬＲ２０２は、メモリを管理し、スレッドおよびプロセスを起動および停止し、セキュリティポリシーを実施する責任を負う。これは、プログラミング言語に依存しないデータ型の概念を提供する共通型システムを提供し、これによって様々なプログラミング言語が．Ｎｅｔ ｆｒａｍｅｗｏｒｋにおいてデータおよびコードを共有できるようになる。また、ＣＬＲ２０２は、特定のマシンがマシンのシステムプロセッサ上でネイティブに実行するように、ＭＳＩＬ（Ｍｉｃｒｏｓｏｆｔ中間言語）コードを変換し、最適化するＪＩＴコンパイラ（ｊｕｓｔ−ｉｎ−ｔｉｍｅ）を有している。

フレームワーククラスライブラリは、いくつかのクラスを含む。１つのクラスは、オブジェクトが実行できる操作（メソッド、イベント、またはプロパティ）を定義し、オブジェクトの状態を保持する値（フィールド）を定義する。クラスは、一般に定義および実装を含んでいるが、実装を有していない１つまたは複数のメンバを有することができる。共通型システムは、ランタイムにおいて型がどのように宣言され、使用され、管理されるかを定義する。．ＮＥＴ ｆｒａｍｅｗｏｒｋ型は、階層を含むドット構文名前付け方式（ｄｏｔ ｓｙｎｔａｘ ｎａｍｉｎｇ ｓｃｈｅｍｅ）を使用する。この技術は、関連する型を名前空間にグループ分けし、それらをより容易に検索でき、参照できるようにする。右端のドットまでの完全名の第１の部分は、名前空間名である。名前の最後の部分は、型名である。例えば、Ｓｙｓｔｅｍ．Ｃｏｌｌｅｃｔｉｏｎｓ．ＡｒｒａｙＬｉｓｔは、Ｓｙｓｔｅｍ．Ｃｏｌｌｅｃｔｉｏｎｓ名前空間に属しているＡｒｒａｙＬｉｓｔ型を表している。Ｓｙｓｔｅｍ．Ｃｏｌｌｅｃｔｉｏｎｓの型を使用して、オブジェクトの集まりを操作することができる。クラスがこのように系統立てられると、名前空間が果たす目的、およびそれがどのクラス機能を含むかを理解しやすくなる。例えば、Ｓｙｓｔｅｍ．Ｗｅｂ．Ｓｅｒｖｉｃｅｓは、そのクラスが何らかのＷｅｂ機能のサービスを提供することを伝える。同様に、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ（登録商標）．Ｓｈａｐｅｓは形状のサービスを提供すると判断しやすい。クラスを意味をつかみやすい統一クラスに論理的にグループ分けすることに加えて、名前空間は、ユーザが既存のものから各自の名前空間を導出できるという点で、拡張性がある。例えば、Ｓｙｓｔｅｍ．Ｗｅｂ．ＵＩ．ＡＣＭＥＣｏｒｐはＳｙｓｔｅｍ．Ｗｅｂ．ＵＩから導出することができ、カスタムＵＩ要素を提供することができる。フレームワークの名前空間は、ソリューションの構築および稼動に必要な「システム」または基本機能およびサービスを提供する。

以下の説明で、本発明は、本発明の特徴をＸＭＬから区別するためにｘａｍｌの用語を使用して説明する。次に図３を参照すると、本発明は、ＣＬＲ概念３００のＸＭＬ３１０への直接マッピングを提供する。名前空間３０２は、リフレクション（ｒｅｆｌｅｃｔｉｏｎ）と呼ばれるＣＬＲ概念を使用して、ｘｍｌｎｓ宣言３１２を介して検索される。クラス３０４は、ＸＭＬタグ３１４に直接マップする。プロパティ３０６およびイベント３０８は、属性３１６に直接マップする。ユーザは、このマッピングを使用して、ＸＭＬマークアップファイル内の任意のＣＬＲオブジェクトの階層ツリーを指定することができる。

ｘａｍｌファイルは、拡張子が．ｘａｍｌで、メディアタイプがａｐｐｌｉｃａｔｉｏｎ／ｘａｍｌ＋ｘｍｌのｘｍｌファイルである。ｘａｍｌファイルは、一般にｘｍｌｎｓ属性を使用して名前空間を指定する１つのルートタグを有する。特定のルートタグは必要なく、それによってユーザは、ルートとして異なるＣＬＲ関連のタグを有することができる。名前空間は、他のタイプのタグで指定することができる。

デフォルトの１組の名前空間を使用する。一実施形態では、５つの名前空間を使用する。これらの名前空間は、（要素のクラスを有する）Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ（登録商標）、（ボタン、パネル、テキストパネルなどのコントロール要素のクラスを有する）Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ（登録商標）．Ｃｏｎｔｒｏｌｓ、（文書中心のテキストレンダリング要素のクラスを有する）Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ（登録商標）．Ｄｏｃｕｍｅｎｔｓ、（Ｗｉｎｄｏｗｓ（登録商標）Ｖｅｃｔｏｒ Ｇｒａｐｈｉｃｓ要素のクラスを有する）Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ（登録商標）．Ｓｈａｐｅｓ、および（スクロールビューアなどブロック要素を構築するクラスを有する）Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ（登録商標）．Ｃｏｎｔｒｏｌｓ．Ａｔｏｍｓであり、ｘｍｌｎｓ宣言で指定される。他の名前空間を使用してもよく、デフォルトの組は、用途に応じて構成可能である。

上述したように、ｘａｍｌファイルのタグは、一般にＣＬＲオブジェクトにマップする。タグは、要素、複合プロパティ、定義、またはリソースとすることができる。要素は、一般にランタイム中にインスタンス化され、オブジェクトの階層を形成するＣＬＲオブジェクトである。これらの要素は階層に留まる。一部の要素は、必要な場合のみにインスタンス化される。要素は、．ＮＥＴ ｆｒａｍｅｗｏｒｋに適合するように、大文字で表す。一実施形態では、要素の主な組が５つある。これらは、Ｐａｎｅｌ、Ｃｏｎｔｒｏｌ、ＤｏｃｕｍｅｎｔＥｌｅｍｅｎｔ、Ｓｈａｐｅ、およびＤｅｃｏｒａｔｏｒである。Ｐａｎｅｌは、要素がページにどのように配列されるかを定義するために使用する。Ｐａｎｅｌの例には、ＴｅｘｔＰａｎｅｌ、ＤｏｃｋＰａｎｅｌ、Ｃａｎｖａｓ、ＦｌｏｗＰａｎｅｌ、およびＴａｂｌｅがある。Ｃｏｎｔｒｏｌは、対話式の経験を提供する。Ｃｏｎｔｒｏｌの例には、Ｂｕｔｔｏｎ、ＲａｄｉｏＢｕｔｔｏｎ、およびＬｉｓｔＢｏｘがある。ＤｏｃｕｍｅｎｔＥｌｅｍｅｎｔは、流し込みテキストをレンダリングし、その書式設定をするために使用する。これらの要素は、他の要素を含むことができる任意の要素内に配置することができる。ＤｏｃｕｍｅｎｔＥｌｅｍｅｎｔの例には、Ｐａｒａｇｒａｐｈ、Ｓｅｃｔｉｏｎ、Ｂｏｌｄ、およびＩｔａｌｉｃがある。ＳｈａｐｅはＶｅｃｔｏｒ Ｇｒａｐｈｉｃの要素である。Ｓｈａｐｅの例には、Ｅｌｌｉｐｓｅ、Ｌｉｎｅ、およびＰａｔｈがある。Ｄｅｃｏｒａｔｏｒは、子を１つしか持てないことを除いてＰａｎｅｌ要素に似ている。Ｄｅｃｏｒａｔｏｒの例には、ＢｏｒｄｅｒおよびＧｌｏｗがある。

複合プロパティタグを使用して、親タグ内にプロパティを設定する。これについて以下で詳述する。ランタイム中、複合プロパティタグは、階層ツリー内に一要素として存在してはいない。定義タグは、ページにコードを追加し、リソースを定義するために使用する。定義タグは、ｘａｍｌページで、またはｘａｍｌページの構成要素内で＜ｄｅｆ：ｘｙｚ＞として識別される。この場合、ｘｙｚは定義される項目である。例えば＜ｄｅｆ：Ｃｏｄｅ＞は、コードをページに追加するために使用され、＜ｄｅｆ：Ｒｅｓｏｕｒｃｅｓ＞は、１つまたは複数の再利用可能なリソースを定義する。＜ｄｅｆ：Ｒｅｓｏｕｒｃｅｓ＞タグ内に表示されるタグは、任意の要素または任意のＣＬＲオブジェクトにマップすることができる。リソースタグは、単にツリーをリソースとして指定しているオブジェクトのツリーを再利用する能力を提供する。定義タグは、別のタグ内でｘｍｌｎｓ属性として定義することもできる。

上述したように、属性は、クラスに関連するプロパティおよびイベントにマップする。一部の属性は真のＣＬＲクラスと関連付けられないため、定義タグも使用して、これらの属性を、プロパティまたはイベントにマップする属性と区別する。次の表には、こうした属性をまとめている。

基本の名前空間からｘｍｌｎｓ属性、クラス名からタグ名、ならびにプロパティおよびイベントから属性へのマッピングおよび定義済みの属性について説明してきたので、ｘａｍｌファイルの解析時に本発明が行うステップについて説明する。以下ｘａｍｌパーサーと呼ぶ本発明のパーサーは、ルートタグから、タグを見つけるためにどのＣＬＲアセンブリおよび名前空間を検索すべきかを決定する。ルートタグの例は、次の形式のものである。

ｘａｍｌパーサーは、ｘｍｌｎｓ属性によって指定されるＵＲＬディレクトリ内で名前空間定義ファイルを探す。例えば上記のルートタグの例で、ｘａｍｌパーサーは、http://microsoft.com/xaml/2004/xmlns.definitionで定義ファイルを検索する。

名前空間定義がｘｍｌｎｓ位置にないシナリオでは、一実施形態では＜？Ｍａｐｐｉｎｇ？＞タグを使用する。アセンブリに組み込まれているカスタム構成要素の場合、タグは
<?Mapping xmlns="foo" Namespace="ACME.Widgets" Assembly="acme" ?>の形式のものである。ユーザが実装を提供する別のエンティティ（例えばｗ３ｃ．ｏｒｇ）によって制御されるあるサイトをｘｍｌｎｓが指す名前空間では、タグは、
<?Mapping xmlns="http://www.w3c.org/2000/svg"
xmlnsdefinition="http://www.acme.com/svg/2000/xmlns.definition ?>の形式のものである。名前空間は、xmlns:foo=http://www.ACME/fooの形式を使用して指定することもできる。これは、名前空間「ｆｏｏ」を定義する。上述したように、名前空間は、別のタイプのタグで指定することもできる。例えば、名前空間は、次のＭｙＣｏｏｌＢｕｔｔｏｎタグで指定される。

名前空間定義ファイルは、アセンブリの名前およびそのインストールパス、およびＣＬＲ名前空間のリストを提供する。定義ファイルの例は次の通りである。

ｘａｍｌパーサーが新しいｘｍｌｎｓ定義ファイルに出会うと、定義ファイルは、フェッチされ、ローカルに格納される。

パーサーは、タグに出会うと、タグのｘｍｌｎｓおよびそのｘｍｌｎｓのｘｍｌｎｓ定義ファイルを使用してそのタグがどのＣＬＲクラスを参照するかを決定する。例えば、タグが＜Ｔｅｘｔ ｘｍｌｎｓ＝“．．．”＞の場合、パーサーは、定義ファイルで提供された名前空間内でテキストと呼ばれるクラスを検索する。パーサーは、アセンブリおよび名前空間がその定義ファイルで指定されている順序で検索する。一致を見つけると、パーサーは、クラスのオブジェクトをインスタンス化する。

ｘａｍｌタグ内の属性は、２つの方法のうちの一方で使用される。それは、プロパティを設定すること、またはイベントハンドラを連結することのいずれかである。例えば、ｘａｍｌパーサーは、以下のタグ
<Button Text="OK" Background ="Red" Click= "RunHandler" ID="bl">
をテキスト、背景、およびクリックプロパティおよび／またはイベントを有するＢｕｔｔｏｎと呼ばれるクラスとして解釈する。パーサーは、Ｂｕｔｔｏｎクラスのプロパティセクションにおいてテキスト、背景、およびクリック名を検索する。名前がプロパティセクションにない場合、パーサーは、イベントセクションで名前を探す。

上記の例で、パーサーは、ＴｅｘｔおよびＢａｃｋｇｒｏｕｎｄはプロパティであり、Ｃｌｉｃｋはイベントであると決定する。テキスト文字列「ＯＫ」が設定される。テキスト文字列の設定より複雑なプロパティおよびイベントの場合、ＣＬＲ型コンバータを使用して、文字列に変換する、また文字列から変換するオブジェクトを作成する。例えば、プロパティＢａｃｋｇｒｏｕｎｄは、ＣＬＲ型の型Ｐａｉｎｔであると決定される。型ＰａｉｎｔのＣＬＲ型コンバータを使用して、文字列「Ｒｅｄ」を型Ｐａｉｎｔのオブジェクトに変換する。この文字列は、Ｂｕｔｔｏｎの背景色の値として設定される。同様に、Ｃｌｉｃｋイベントは、ＲｕｎＨａｎｄｌｅｒメソッドに連結され、ＩＤプロパティはｂ１に設定される。

プロパティは、簡単な属性、文字列値を有する複合プロパティ、または値としてオブジェクトを有する複合プロパティとして設定することができる。簡単な属性は、＜Ｂｕｔｔｏｎ Ｂａｃｋｇｒｏｕｎｄ＝“Ｂｌｕｅ”／＞という形式のものである。この場合「Ｂｌｕｅ」は、型Ｐａｉｎｔ（Ｂａｃｋｇｒｏｕｎｄプロパティの型）のオブジェクトに文字列をどのように変換するかを知っている型コンバータを呼び出すことによって解釈される。次いでこれをＢｕｔｔｏｎのＢａｃｋｇｒｏｕｎｄプロパティの値として設定する必要がある。属性値が^*で開始する場合、属性は、リテラル値を指定しておらず、代わりに新しくインスタンス化されたオブジェクトまたは既存のオブジェクトと等しい値を設定している。

文字列値を有する複合プロパティは、次の形式のものである。

<Button>
<Button.Background>Blue</Button.Background>
</Button>

その中にピリオドが含まれているタグは、そのタグがプロパティへの参照であることを示す。パーサーは、後ろにピリオドが続く親タグのタグ名（例えば「Ｂｕｔｔｏｎ．Ｂａｃｋｇｒｏｕｎｄ」タグの「Ｂｕｔｔｏｎ」）で始まるタグを見つけると、そのピリオドの後ろの名前（例えば「Ｂｕｔｔｏｎ．Ｂａｃｋｇｒｏｕｎｄ」タグの「Ｂａｃｋｇｒｏｕｎｄ」）によって指定されるプロパティを検索する。この場合、「Ｂｌｕｅ」は、文字列を型Ｐａｉｎｔ（Ｂａｃｋｇｒｏｕｎｄプロパティの型）のオブジェクトに変換する方法を知っている型コンバータを呼び出すことによって解釈する必要がある。次いでこれをＢｕｔｔｏｎのＢａｃｋｇｒｏｕｎｄプロパティの値として設定する必要がある。

別のクラスからのプロパティもタグで宣言することができる。例えば、
<TextBox Button.Background="Blue">
のタグは、属性Ｂｕｔｔｏｎ．ＢａｃｋｇｒｏｕｎｄがＴｅｘｔＢｏｘクラスとは異なるクラスにマップされることを示す。パーサーは、ピリオドを見つけ、そのピリオドの後ろの名前によって指定されるプロパティ（例えば「Ｂｕｔｔｏｎ．Ｂａｃｋｇｒｏｕｎｄ」タグの「Ｂａｃｋｇｒｏｕｎｄ」）をピリオドの前の名前によって指定されるクラス（例えば「Ｂｕｔｔｏｎ」）内で検索する。

値としてオブジェクトを含む複合プロパティは、次の形式のものである。

この場合、ＣＬＲ ＨｏｒｉｚｏｎｔａｌＧｒａｄｉｅｎｔオブジェクトが作成され、次いでＢｏｔｔｏｎのＢａｃｋｇｒｏｕｎｄプロパティの値として設定される。

複合プロパティ構文を使用すると、単に値に対してオブジェクトを提供するだけではない。例えば次のように、Ａｎｉｍａｔｉｏｎまたは一部のデータへのＢｉｎｄを達成することができる。

これらの場合、タグは、特徴を提供するための適切なシステムを設定する能力をＡｎｉｍａｔｉｏｎまたはＢｉｎｄに提供するために使用される。例えば、Ａｎｉｍａｔｉｏｎオブジェクトを作成した後、ｘａｍｌパーサーは、ＩＡｐｐｌｙＶａｌｕｅと呼ばれるインターフェースを実装したかどうかを確認するためにオブジェクトに照会する。実装している場合、ｘａｍｌパーサーは、ＣｏｌｏｒＡｎｉｍａｔｉｏｎＯｂｊｅｃｔ．ＡｐｐｌｙＶａｌｕｅ（ｅｌｅｍｅｎｔＲｅｆｅｒｅｎｃｅ， ＢａｃｋｇｒｏｕｎｄＰｒｏｐｅｒｔｙＩＤ）を呼び出す。次いでＣｏｌｏｒＡｎｉｍａｔｉｏｎＯｂｊｅｃｔは、Ａｎｉｍａｔｉｏｎに連結する。オブジェクトがインスタンスをサポートしていない場合、ｘａｍｌパーサーは、ＢｕｔｔｏｎのＢａｃｋｇｒｏｕｎｄプロパティをＣｏｌｏｒＡｎｉｍａｔｉｏｎＯｂｊｅｃｔに設定する。

上述したように、属性値が^*で開始する場合、この属性は、新しくインスタンス化されたオブジェクトまたは既存のオブジェクトに等しい値を設定している。ｘａｍｌパーサーは、^*の後ろの名前を探し、^*の後ろの名前のＣＬＲ型を探す。例えば、<Button Background = "^*HorizontalGradient(Start=Red End=Blue)">タグでは、パーサーは、括弧の前の名前（すなわちＨｏｒｉｚｏｎｔａｌＧｒａｄｉｅｎｔ）を決定し、前のｘｍｌｎｓ設定値によって確立された現在の名前空間内でそのＣＬＲ型を検索する。パーサーは、括弧の後の項目を属性および値として扱う（例えばｓｔａｒｔは属性であり、ｒｅｄはその属性の値である）。「^*」エスケープ文字の使用の他の例を以下に示す。これらのすべての場合に、値が一度設定される。このプロパティと何らかのオブジェクトとの間の関係を維持するのに式または結合は設定しない。前方の参照は可能である。ツリー作成中、参照されるオブジェクトがまだ存在していない場合、それが現れるまで、またはツリーが完全に作成されるまでそのプロパティの設定が遅延する。

プログラミング言語は、．ｘａｍｌページの２つの場所に関連付けることができる。これらの場所は、．ｘａｍｌファイル、および関連するコードビハインドファイル（ｃｏｄｅ−ｂｅｈｉｎｄ ｆｉｌｅ）の中にある。コードビハインドファイルは、一般に．ｘａｍｌファイルと同じ名前が付けられ、末尾にプログラミング言語の一般の拡張子が添付されている。例えば、．ｘａｍｌ．ｃｓはＣ＃、．ｘａｍｌ．ｖｂはＶＢ、．ｘａｍｌ．ｊｓはＪｓｃｒｉｐｔの場合に使用される。ｘｍｌｎｓ：ｄｅｆ＝“Ｄｅｆｉｎｉｔｉｏｎ”の名前空間は、コードをページに追加するのに必要なタグを使用するために、ルート要素に追加される。ユーザは、ｄｅｆ：Ｌａｎｇｕａｇｅ属性をページのルート要素に追加することによってｘａｍｌページに関連するプログラミング言語を選択する。例えば、次のタグは、定義および言語属性がルート要素にどのように追加されるかを示している。<DockPanel xmlns="http://microsoft.com/xaml/2005" xmlns:def="Definition" xmlns:Language="C#">
「＞」、「＜」および／または「＆」文字を含むｘａｍｌファイル内にコードを追加するために、ＸＭＬで定義されたＣＤＡＴＡセクションが＜ｄｅｆ：Ｃｏｄｅ＞セクションに必要である。この例を以下に示す（この例では、含まれているコードは、「＜」、「＞」、または「＆」文字を使用しないため、ＣＤＡＴＡの括弧付けは必要ない）。

コードビサイドファイル（ｃｏｄｅ−ｂｅｓｉｄｅ ｆｉｌｅ）内においてコードを指定するには、ソース属性を使用する。ソース属性は、ｘａｍｌファイルのコードビハインドにＵＲＩを提供する。ＵＲＩは、相対または絶対とすることができる。ＵＲＩおよび簡単なコードビサイドファイルを指定する例を以下に示す。

簡単なコードビサイドファイルは次の通りである。

また、ｘａｍｌパーサーは、ＩＬｉｔｅｒａｌＣｏｎｔｅｎｔと呼ばれる特徴をサポートしている。ＩＬｉｔｅｒａｌＣｏｎｔｅｎｔを実装するオブジェクトでは、ｘａｍｌパーサーは、オブジェクトのタグを文字列として扱い、タグを解析しない。例えば、ＰｕｂｌｉｃクラスのＦｏｏＯｂｊｅｃｔがＩＬｉｔｅｒａｌＣｏｎｔｅｎｔを実装する場合、ｘａｍｌパーサーがタグ＜ＦｏｏＯｂｊｅｃｔ＞“Ｉ ａｍ ａ ｓｔｒｉｎｇ”＜／ＦｏｏＯｂｊｅｃｔ＞に出会うと常に、パーサーは、ＦｏｏＯｂｊｅｃｔのインスタンスを作成し、＜ＦｏｏＯｂｊｅｃｔ＞タグ内のデータ（例えば「Ｉ ａｍ ａ ｓｔｒｉｎｇ」）を新しく作成されたＦｏｏＯｂｊｅｃｔに渡す。

要するに、要素／オブジェクトが直接含むルートタグを解析するときに以下の規則を使用する。図４を参照すると、タグがスキーマ位置を指定するｘｍｌｎｓ属性を有する場合、ｘｍｌｎｓ属性に関連するアセンブリ／名前空間を有する定義ファイルは、ローカルに配置され、格納される（ステップ４００）。アセンブリ／名前空間は一般に、文書のルートタグまたはマッピングタグでスキーマのＵＲＬを使用して検索される。タグが要素タグである場合、パーサーは、要素がそこで指定されているｘｍｌ名前空間に基づいて、その名前のクラスを適切な１組のアセンブリ／名前空間で探し、そのクラスのオブジェクトのインスタンスがインスタンス化される（ステップ４０２）。クラス名が見つからない場合、ｘａｍｌパーサーは、包含側の親がその名前のプロパティを有しているかどうかをチェックする。それが包含側要素のプロパティである場合、ｘａｍｌパーサーは、複合プロパティ規則を使用してそのタグの内容を解析する。タグが属性タグの場合、その属性に関連するプロパティまたはイベントが設定される（ステップ４０４）。属性値が^*で開始する場合、属性は、リテラル値を指定しておらず、代わりに新しくインスタンス化されたオブジェクトまたは既存のオブジェクトに等しい値を設定している。タグは、親タグ上にプロパティを設定するために使用するタグを有していてもよい。タグは、複合プロパティである。タグが複合プロパティの場合、複合規則に従う（ステップ４０６）。こうした規則を以下に示す。ｘａｍｌパーサーは、複合プロパティが文字列であるかどうかを決定する。内容が文字列である場合、ｘａｍｌパーサーは、設定されるプロパティの適切な型の型コンバータを呼び出す。親タグの内容が別のタグである場合、ｘａｍｌパーサーは、オブジェクトを基準としてインスタンス化する。オブジェクトをインスタンス化した後、ｘａｍｌパーサーは、それをプロパティの値として親オブジェクトに設定する。タグのｘｍｌｎｓが「ｄｅｆ：」の場合、ｘａｍｌパーサーは、後述するように、内蔵されている１組の意味（ａ ｓｅｔ ｏｆ ｂｕｉｌｔ ｉｎ ｍｅａｎｉｎｇｓ）を使用する（ステップ４０８）。ファイル内の次のタグが解析され（ステップ４１０）、ｘａｍｌパーサーがｘａｍｌファイルの終了ルートタグを検出するまで、ステップ４００から４０８がタグごとに繰り返される。

本発明は、オブジェクトモデルをマークアップタグを使用してＸＭＬベースのファイルで表すことができる機構を提供することが上記からわかる。オブジェクトモデルをマークアップタグとして表すことができるこの能力を使用すると、ベクトル図形、固定形式文書、適応的フロー文書、およびアプリケーションＵＩを作成することができる。こうしたベクトル図形、固定形式文書、適応的フロー文書、およびアプリケーションＵＩは、非同期または同期に作成することができる。これによって、これらの項目をマークアップから構築してオブジェクトのツリーを作成することができるという利益が得られる。

固定形式文書は、予め決定されている装置に依存しないやり方で、文書ページ数およびサイズ、ならびに各ページでのオブジェクトの位置を明示的に定義する文書である。これによって、文書の表示に使用する実装システムに関係なく同じページがレンダリングされる形式で文書を作成し、共有できる能力がユーザに提供される。一実施形態では、固定形式文書のルートタグの一方は＜ＦｉｘｅｄＰａｎｅｌ＞であり、ページは＜Ｆｉｘｅｄ Ｐａｇｅ＞タグを使用して指定される。固定ページ内に、いくつかのタイプの要素を使用することができる。これらの要素には、テキスト、ベクトル図形、および画像などがある。フォントおよび共有画像などの外部リソースが指定される。テキストに使用するタグは、個々の文字グリフおよび文字グリフの位置に対する正確な制御をユーザに提供する。他のタグは、テキスト、ベクトル図形、および画像がどのように１ページに結び付けられるかに対する制御をユーザに提供する。ｘａｍｌパーサーは、固定形式文書のタグを認識する。他の任意のタイプの．ｘａｍｌファイルと同様、パーサーは、タグに関連するＣＬＲ名前空間およびクラスを決定し、ｘａｍｌファイル内のタグの型コンバータを呼び出し、固定形式文書をレンダリングする。

適応的フロー文書には、予め決定されているページサイズはない。適応的フロー文書におけるテキスト、画像、ＤｏｃｕｍｅｎｔＥｌｅｍｅｎｔ、および他のオブジェクトの組は、様々なページ幅に合うようにページ上に流出し、または再配置される。例えば、表示画面上のウィンドウにレンダリングされたページは、使用しているコンピューティングシステム、またはユーザの選好に応じて、異なる表示画面上では異なる幅となる可能性がある。印刷されるページは、ページサイズに応じて幅が異なる。例えば、テキストの行は、ページの幅が狭くなるとより短くなり、それによってテキストは、追加の単語をテキスト行からテキスト行にカスケード式の順序でページのさらに下方の行に流出し、または再配置される。属性を使用して、適応的フロー文書がどのように表示されるかに対するユーザの選好を指定する。

ｘａｍｌパーサーは、これらの属性を、オブジェクトのＣＬＲ型コンバータに渡して文書を作成する。オブジェクトは、ページ番号の振られていない、またはページ番号の振られているプレゼンテーションを作成することができる。ページ番号の振られていないプレゼンテーションでは、縦方向のスクロールバーなどのコントロールを用いて、表示画面上に底部のない単一のページが表示される。ページ番号の振られているプレゼンテーションでは、ページ高さに基づいて文書内容をセグメントに分割し、次ボタンや前ボタンなどのコントロールを用いて、各ページを表示画面に別個に表示する。別の属性は、ページ上の列幅および列数、すべてのテキスト要素のサイズ、テキスト行間隔、すべての画像および図形のサイズおよび位置、ならびにマージン幅および段組間の幅を決定する。またユーザは、ページサイズに合わせて最適に読めるように、文書を作成するオブジェクトが、列、テキストサイズおよび行間隔、画像サイズおよび位置、マージンおよび段組間の幅、ならびに他のページまたはテキストパラメータを自動的に調整すべきかどうかを属性によって指定することもできる。ｘａｍｌパーサーは、適応的フロー文書のタグを解析し、タグに関連するＣＬＲ名前空間およびクラスを決定し、適応的フロー文書をレンダリングするためにｘａｍｌファイル内で指定されたオブジェクトの型コンバータを呼び出す。

本発明の原理を適用できる多くの可能な実施形態を考慮して、図面との関連で本明細書に記載した実施形態は、例示的なものにすぎず、本発明の範囲を限定するものとみなされるべきではないことを理解されたい。例えば、ソフトウェアで示した実施形態の例の要素をハードウェアに、またその逆に実装でき、あるいは、実施形態の例を、本発明の意図から逸脱することなく、構成および詳細について変更できることを当業者であれば理解されよう。したがって、本明細書に記載した本発明は、添付の特許請求の範囲、およびその均等物の範囲内に含まれ得るすべての実施形態を企図する。

Claims (12)

1. マークアップ言語データ構造を格納しているコンピュータ可読媒体であって、
   プログラミング言語クラスにマップされるデータを含む第１のフィールドと、
   前記クラスのプロパティおよびイベントの一方にマップされるデータを含む第２のデータフィールドと
   を含むことを特徴とするコンピュータ可読媒体。
2. 前記第１のフィールドおよび前記第２のフィールドを解釈するために少なくとも１つのアセンブリおよび少なくとも１つの名前空間を有する定義ファイルを取り出すためのＵＲＬ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ）を示すデータを含む第３のフィールドをさらに含むことを特徴とする請求項１に記載のコンピュータ可読媒体。
3. 前記第２のデータフィールドが^*文字を有している場合、前記第２のデータフィールドは、前記データ構造のプロセス中に、新しくインスタンス化されたオブジェクトおよび既存の参照されるオブジェクトの一方に等しい値に設定されることを特徴とする請求項１に記載のコンピュータ可読媒体。
4. 前記第２のデータフィールドは複合プロパティを格納しており、前記第２のデータフィールドがテキスト文字列である場合、前記第２のデータフィールドが処理されると、型コンバータが呼び出されることを特徴とする請求項１に記載のコンピュータ可読媒体。
5. 前記第２のデータフィールドが他のタグである場合、前記第２のデータフィールドが処理されると、前記他のタグの名前に基づくクラスが探され、前記他のタグの名前に基づくクラスのオブジェクトがインスタンス化され、前記オブジェクトがプロパティの値として前記タグに設定されることを特徴とする請求項４に記載のコンピュータ可読媒体。
6. オブジェクトを宣言的に定義するための方法であって、
   少なくとも１つの名前空間を有する定義ファイルの位置のＵＲＬをルートタグおよびマッピングタグのうちの一方のｘｍｌｎｓ属性にマップするステップと、
   前記少なくとも１つの名前空間内のクラス名にタグ名を設定するステップと、
   前記オブジェクトがプロパティ設定を有している場合、プロパティ名に前記タグの属性を設定するステップと
   を含むことを特徴とする方法。
7. 前記オブジェクトが定義されたイベントを有する場合、前記タグの属性をイベント名に設定するステップをさらに含むことを特徴とする請求項６に記載の方法。
8. プログラミングコードの１つをページおよびリソースに追加する定義タグを定義するステップをさらに含むことを特徴とする請求項６に記載の方法。
9. 前記プログラミングコードの１つを前記ページおよび前記リソースに追加する定義タグを定義するステップは、ｄｅｆ：Ｃｏｄｅ要素を設定して前記プログラミングコードを前記ページに追加することを含むことを特徴とする請求項８に記載の方法。
10. クラスに関連付けられていない属性を追加する定義タグを定義するステップをさらに含むことを特徴とする請求項６に記載の方法。
11. クラスに関連付けられていない属性を追加する定義タグを定義するステップは、ｄｅｆ：Ｌａｎｇｕａｇｅ属性をコードのコンパイルに使用する言語を指定するように設定することを含むことを特徴とする請求項１０に記載の方法。
12. ピリオドで区切られた第１のセクションおよび第２のセクションとして属性を表し、前記第１のセクションは前記プロパティおよびイベントの一方が定義される前記クラスに対応するクラス名に設定され、前記第２のセクションは前記プロパティおよび前記イベントの一方の名前に設定されるステップをさらに含むことを特徴とする請求項６に記載の方法。

Images