JP4806158B2 - マークアップ内でサブクラスを宣言的に定義し、使用するためのシステムおよび方法 - Google Patents

Description

本発明は、マークアップ内でサブクラスを宣言的に定義し、拡張し、使用するためのシステムおよび方法に関し、マークアップ言語を使用してコンポーネントを作成し、拡張し、使用するためのメカニズムを提供するものである。

今日、ソフトウェア開発ツールにより、ソフトウェア開発者は、Ｃ、Ｃ＋＋、Ｃ＃などのプログラミング言語（programming language）を使用して実行可能なコンポーネントを作成することができるようになっている。実行可能なコンポーネントを作成することの１つの利点は、コンポーネントは、作成されると、その他のソフトウェアプログラムによって再利用されることが可能なことである。実行可能なコンポーネントを作成することの別の利点は、新しいコンポーネントを既存のコンポーネントから容易に拡張可能なことである。

一般に、コンポーネントはサブクラス化によって拡張され、サブクラス化とは、新しいクラスを既存のクラスから導出することを意味する。このクラスおよびサブクラスは、プログラミング言語のどれかを使用して記述される。記述されるコードは、一般にソースコードと呼ばれる。従来のランタイム環境の場合、ソフトウェア開発ツールがソースコードをオブジェクトコードにコンパイルした後、複数のオブジェクトコードを一緒にリンクして実行可能コードを生成する。ただし、この従来のランタイム環境が抱える問題の１つは、各プログラミング言語、およびそのプログラミング言語の各バージョンが、異なるランタイム環境を必要とすることである。

この問題を克服するため、新しいタイプのランタイム環境が、従来のランタイム環境の言語間インターフェース問題および言語バージョン問題の多くを実質的に解消するように設計されている。この新しいタイプのランタイム環境では、開発ツールがソースコードを中間言語にコンパイルする。ランタイム中、ランタイム環境が、その中間言語をネイティブバイナリ実行可能コードにコンパイルする。したがって、新しいランタイム環境は、ランタイム中に「リンクタイプ」のプロセスを行う。この「リンクタイプ」のプロセスを行うため、ランタイム環境は、情報（例えば、メタデータ）を読み取り、実行されているプログラムに関連するコンポーネントに関するＩＬアセンブリにアクセスする。メタデータは、タイプ、バージョン、リソース等に関する記述を含む。ＩＬアセンブリは、単一のダイナミックリンクライブラリ（ＤＬＬ）であること、または多数のＤＬＬおよびリソースであることが可能である。

従来のタイプのランタイム環境と新しいタイプのランタイム環境の両方の場合で、ソースコードは、プログラミング言語を使用して記述される。各プログラミング言語は、自らの固有のシンタックス、およびランタイム環境に特有の１組のアプリケーションプログラミングインターフェース（ＡＰＩ）を有する。ソフトウェア開発者は、ソースコードを記述するのに、プログラミング言語のシンタックス、およびランタイム環境に関連するＡＰＩを習得しなければならない。シンタックスおよびＡＰＩを習得することには、非常に時間がかかり、困難が伴う。さらに、開発者が複数のプログラミング言語および／または様々なランタイム環境を使用してプログラミングすることを望む場合、その開発者は、プログラミング言語のシンタックスのそれぞれ、および様々なランタイム環境に対するＡＰＩの間の類似性および微妙な違いを覚えていなければならない。

コンポーネントを使用することの利点から、コンポーネントを作成し、拡張し、使用するためのよりよいメカニズムの必要性が存在する。

本発明は、マークアップ内でサブクラスを宣言的に定義し、拡張し、使用するためのシステムおよび方法を対象とする。本発明は、開発者がマークアップ言語を使用してコンポーネントを作成し、拡張し、使用するためのメカニズムを提供する。このコンポーネントには、再利用可能なコンポーネント、アプリケーションユーザインターフェース、ドキュメントユーザインターフェース等が含まれる。このメカニズムは、開発者がプログラミング言語を知っていることを必要としない。代わりに、このメカニズムは、開発者がＸＭＬ（拡張可能なマークアップ言語）などの慣れ親しんだマークアップ言語を使用してコンポーネントを作成することを可能にする。ＸＭＬは、習得するのがはるかに容易であり、一般のコンピュータプログラマの間でより普及してきているため、本発明は、従来のプログラミング言語を使用することに優るいくつかの利点を提供する。１つの利点は、コンポーネントをマークアップドキュメント内、並びに他のマークアップテキスト内で定義して、非常に洗練された電子ドキュメントを作成可能なことである。別の利点は、開発者が実行可能なコンポーネントを生成するのに全くプログラミング言語を知ったり、または理解する必要がないことである。

本発明のシステム、方法、およびデータ構造により、マークアップドキュメント内に記述されたサブクラス定義から、サブクラスに関連する実行可能なアセンブリを生成することができるようになる。本発明によれば、サブクラス定義は、スキーマに基づいて記述される。このスキーマは、ＸＭＬベースのものであることが可能である。スキーマは、サブクラスの名前を定義するためのサブクラスタグを含む。名前は、実行可能なアセンブリが実行されたときにインスタンス化されるオブジェクトのタイプに関連する。スキーマは、サブクラス定義をコンパイルするプログラミング言語（programming language）を指定するため、サブクラスがそこから導出されるスーパークラスを指定するため、オブジェクトがインスタンス化されたときに行われるアクションを指定するため、サブクラスに関するＥｖｅｎｔ定義、および関連するＥｖｅｎｔＨａｎｄｌｅｒを生成するため、並びにオブジェクトがインスタンス化されるとそのオブジェクト内のフィールドとなるプロパティを指定するためなどのヒントをさらに含む。

本発明は、マークアップドキュメント内でサブクラスを宣言的に定義し、拡張し、使用するためのシステムおよび方法を対象とする。本発明は、開発者がマークアップ言語を使用してコンポーネントを作成し、拡張し、使用するためのメカニズムを提供する。このメカニズムは、開発者がプログラミング言語（programming language）を知っていることを必要としない。代わりに、このメカニズムは、開発者が拡張可能なマークアップ言語（ＸＭＬ）などの慣れ親しんだマークアップ言語を使用してコンポーネントを作成することを可能にする。

例示的なコンピューティング環境
図１は、本発明の例示的な実施例において使用することができる例示的なコンピューティングデバイスを示している。図１を参照すると、非常に基本的な構成において、コンピューティングデバイス１００は、通常、少なくとも１つの処理ユニット１０２およびシステムメモリ１０４を含む。コンピューティングデバイス１００の構成およびタイプが正確にどのようなものであるかに依存して、システムメモリ１０４は、揮発性（ＲＡＭなどの）、不揮発性（ＲＯＭ、フラッシュメモリなどの）、または揮発性と不揮発性の何らかの組合せであることが可能である。システムメモリ１０４は、通常、オペレーティングシステム１０５、１つ以上のプログラムモジュール１０６を含み、またプログラムデータ１０７も含むことが可能である。プログラムモジュール１０６の例には、ブラウザアプリケーション、財務管理アプリケーション、ワードプロセッサ等が含まれる。この基本的な構成を破線１０８内のコンポーネントで図１に示している。

コンピューティングデバイス１００は、追加のメカニズムまたは機能を有することが可能である。例えば、コンピューティングデバイス１００は、例えば、磁気ディスク、光ディスク、またはテープなどの追加の（取外し可能な、かつ／または取外し不可能な）データ記憶媒体も含むことが可能である。そのような追加のストレージを図１に取外し可能なストレージ１０９および取外し不可能なストレージ１１０で示している。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータなどの情報を記憶するための任意の方法または任意の技術で実装された揮発性の媒体および不揮発性の媒体、取外し可能な媒体および取外し不可能な媒体が含まれることが可能である。システムメモリ１０４、取外し可能ストレージ１０９および取外し不可能なストレージ１１０は全てコンピュータ記憶媒体の例である。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタルバーサタイルディスク（ＤＶＤ）またはその他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたはその他の磁気記憶媒体、あるいは所望の情報を記憶するのに使用することができ、コンピューティングデバイス１００によってアクセスされることが可能な任意の他の媒体が含まれるが、以上には限定されない。任意のそのようなコンピュータ記憶媒体がデバイス１００の一部となっていることが可能である。また、コンピューティングデバイス１００は、キーボード、マウス、ペン、音声入力装置、タッチ入力装置などの入力装置１１２も有することが可能である。ディスプレイ、スピーカ、プリンタなどの出力装置１１４も含めることが可能である。以上のデバイスは、当技術分野で周知であり、本明細書で詳述するまでもない。

また、コンピューティングデバイス１００は、デバイス１００がネットワークを介するなどして、他のコンピューティングデバイス１１８と通信することを可能にする通信接続１１６も含むことが可能である。通信接続１１６は、通信媒体の一例である。通信媒体は、通常、搬送波、またはその他のトランスポートメカニズムなどの変調されたデータ信号内のコンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータによって実現され、任意の情報配信媒体を含む。「変調されたデータ信号」という用語は、情報を信号内に符号化するような仕方で特性の１つまたは複数が変更されている信号を意味する。例として、限定としてではなく、通信媒体には、有線ネットワークまたは直接配線接続などの有線媒体、並びに音響媒体、ＲＦ媒体、赤外線媒体、およびその他のワイアレス媒体などのワイアレス媒体が含まれる。本明細書で使用するコンピュータ可読媒体という用語には、記憶媒体と通信媒体がともに含まれる。

図２は、本発明の一実施例を実施するための開発システムを一般的に示す機能ブロック図である。このシステムは、マークアップコンパイラ（compiler）２０２およびパーサ（parser）２０４を含む。マークアップコンパイラ２０２およびパーサ２０４は、図１に示したコンピューティングデバイス１００などのコンピューティングデバイス上に常駐することが可能なソフトウェアモジュール（すなわち、図１に示したプログラムモジュール１０６）である。マークアップコンパイラ２０２は、マークアップドキュメント２０６を入力する。一実施例では、マークアップドキュメント２０６は、拡張可能なマークアップ言語（ＸＭＬ）ベースのドキュメントである。簡単に述べると、図４〜図６に示し、以下に詳細に説明するマークアップドキュメント２０６は、サブクラス定義の部分を示すタグ（図示せず）を含む。後により詳細に説明する通り、このタグは、サブクラスおよび関連するエレメントの存在を示す。このタグに出会うと、マークアップコンパイラ２０２は、サブクラスを作成するためのパーサ２０４と通信を始める。

一実施例では、パーサ２０４によって提供される機能は、マークアップコンパイラ２０２内で提供されることが可能である。別の実施例では、パーサ２０４によって提供される機能が、マークアップコンパイラ２０２内の既存のパーサクラスから構文解析クラスを導出することによって提供されることも可能である。導出された構文解析クラスは、本発明に従って定義されたサブクラストークン（すなわち、タグ）のそれぞれに関する機能指定変更を含むことが可能である。簡単に述べると、図１０に示し、後により詳細に説明する機能指定変更は、サブクラスに関連するエレメントの定義の開始および終了を知らせる一連のコールバック機能の一部であることが可能である。

パーサ２０４は、マークアップドキュメント２０６内のサブクラス定義を構文解析するように構成されている。簡単に述べると、マークアップコンパイラ２０２がマークアップドキュメント２０６内のコンテンツをコンパイルする。一実施例では、マークアップコンパイラ２０２は、トークン化（tokenized）バイナリファイル２０８の中に保存されるトークン化バイナリストリームにコンテンツを変換する。トークン化バイナリファイル２０８は、当分野の技術者に周知のいくつかの形態のどれかであることが可能である。トークン化バイナリファイル２０８は、マークアップドキュメント２０６の中で指定されたコンポーネントのツリーを表わす。ただし、マークアップコンパイラ２０２は、コンテンツの一部を直接に変換することができない可能性があり、そのコンテンツがパーサ２０４に送られることが可能である。本発明に従ってマークアップドキュメント２０６内で定義されたサブクラス定義が、そのようなコンテンツの例である。パーサ２０４が、このサブクラス定義内のプロパティ、イベント等を識別し、これらのアイテムに関する妥当な情報をマークアップコンパイラ２０２に中継する。

妥当な情報を受け取ると、マークアップコンパイラ２０２は、そのサブクラス定義に関連するマークアップドキュメント２０６にトークンを追加する。また、マークアップコンパイラ２０２は、ＩＬアセンブリ２１０の生成の元となる代表的なソースコード２１２も生成する。ＩＬアセンブリ２１０は、マークアップドキュメント２０６内で定義されたサブクラス（例えば、コンポーネント）に関するコンピュータ命令を含む。過去には、このＩＬアセンブリは、プログラム言語（programmatic language）を使用して記述されたソースコードをコンパイルし、リンクするソフトウェア開発ツールを使用して生成された。また、マークアップコンパイラ２０２がトークン化バイナリファイル２０８を生成することなしにＩＬアセンブリ２１０を生成することが可能な別の実施例を実施可能なことも、当分野の技術者には認められよう。

マークアップコンパイラ２０２によって生成されたＩＬアセンブリ２１０は、従来のプログラミング開発ツールによって再利用されることが可能である。さらに、ＩＬアセンブリ２１０は、他のマークアップドキュメントの中で再利用されることも可能である。マークアップドキュメント内でＩＬアセンブリ２１０を再利用できることを図７に例示し、それに併せて説明している。したがって、本発明は、コンポーネント開発者がマークアップ言語を使用してコンポーネントを容易に作成し、拡張することができるようにする。本発明に従って新しいコンポーネントが作成されると、その新しいコンポーネントは、あたかも従来のプログラミング言語を使用して作成されたかのように見える。したがって、本発明のメカニズムおよび方法を使用する開発者は、プログラミング言語のシンタックスおよび微妙な違いを習得せずに、コンポーネントを作成することができる。

図３は、本発明の一実施例を実施するためのランタイム環境を一般的に示す機能ブロック図である。このランタイム環境は、ランタイムエンジン３０２、トークン化バイナリリーダ３０４、およびトークン化バイナリローダ３０６を含む。ランタイムエンジン３０２は、特定のリソース（例えば、図２に示すマークアップドキュメント２０６）をロードする要求を受け取ったとき、ページマップテーブル３０８にアクセスする。ページマップテーブル３０８は、マークアップドキュメント２０６がコンパイル済みのバージョン（例えば、トークン化バイナリファイル２０８）を有するか否かを明らかにする。コンパイル済みのバージョンが存在する場合、ランタイムエンジン３０２は、トークン化バイナリローダ３０６と通信してトークン化バイナリファイル２０８をロードする。一実施例では、トークン化バイナリファイル２０８は、そのトークン化バイナリファイル２０８に関連するＩＬアセンブリ（例えば、ＩＬアセンブリ２１０）を特定する。次に、トークン化バイナリローダ３０６は、特定されたＩＬアセンブリ２１０をロードする。トークン化バイナリファイル２０８の一部または全部、および関連するＩＬアセンブリ２１０がロードされると、トークン化バイナリリーダ３０４が、トークン化バイナリファイル２０８を読み取ることを始め、またＩＬアセンブリ２１０が、プロセッサ（例えば、図１に示す処理ユニット１０２）上で実行されるネイティブ命令を生成することを始める。トークン化バイナリリーダ３０４は、メタデータ３１０にアクセスして、タイプ、メソッド、およびイベントなどの情報を判別することができる。一般に、メタデータ３１０は、メソッド、フィールド、プロパティ、およびイベントに関する情報を含む。以上のアイテムのそれぞれは、さらなる詳細のために読み取られることが可能な独自のメタデータを有することが可能である。したがって、メタデータ３１０を使用して、トークン化バイナリリーダ３０４は、ランタイム中に反映（reflection）を使用して、トークン化バイナリファイル２０８内のエレメントに関する情報をプログラミング式に判別する。さらに、後に以下により詳細に説明する通り、マークアップドキュメント２０６内で最初に定義されたサブクラスが、本発明に従って生成されたＩＬアセンブリ２１０を使用して直接に実行されることが可能である。

図４〜図６は、本発明の一実施例によるサブクラスを宣言的に定義するための例示的なシンタックスを示すマークアップドキュメント２０６内のマークアップの一連の主立った部分を示している。図１０は、マークアップコンパイラ２０２が、図４〜図６に示されたマークアップの主立った部分に基づいて生成することができる代表的なソースコードを示す例示的なソースコードリストである。一実施例では、マークアップコンパイラ２０２は、代表的なソースコードを含むファイルを実際に生成することが可能である。これは、開発者がデバッグフラグを設定したときに行われることが可能である。その場合、代表的なソースコードを含むファイルにより、開発者は、マークアップドキュメント２０６の中のテキスト内の問題の可能性、またはマークアップコンパイラ２０２内の問題を判別することができるようになる。代表的なコードがファイル内に保存されない別の実施例を実施することも可能である。この実施例の場合、マークアップコンパイラ２０２は、代表的なソースコードをまず生成して、または生成することなしに、トークン化バイナリファイル２０８およびＩＬアセンブリ２１０を生成することができる。

概観すると、一連の図４〜図６は、本発明によるマークアップ内でサブクラスを宣言的に定義するための様々な態様を漸進的に描いている。図４は、サブクラス、およびサブクラス階層を定義するための例示的なシンタックスを示している。図５は、サブクラスに関する識別子、コード、およびコンストラクタ（constructor）を定義するための例示的なシンタックスを示している。図６は、サブクラスに関するプロパティおよびイベントを定義するための例示的なシンタックスを示している。次に、以上の図のそれぞれをより詳細に説明する。

図４は、サブクラス、およびサブクラス階層を定義するための例示的なシンタックスを示している。マークアップ４００の主立った部分（例えば、サブクラス定義）は、スーパークラスタグ４０２（例えば、「Ｂｕｔｔｏｎ」）を含む。以下の考察では、各タグ（例えば、スーパークラスタグ４０２）が、対応する終了タグを有する。便宜上、終了タグについては、記載する説明では明示的に述べず、関連する図に示している。マークアップ４００は、ネームスペース（namespace）属性４０４、定義ネームスペース宣言４０６、およびいくつかのコンパイラヒント（例えば、ヒント４０８および４１０）を含む。ネームスペース属性４０４は、スーパークラス（例えば、Ｂｕｔｔｏｎ）が配置されているネームスペース（例えば、「Ｓｙｓｔｅｍ．Ｃｏｎｔｒｏｌ」）およびアセンブリを特定する。定義ネームスペース宣言４０６は、「ｄｅｆ：」プレフィクスを含むマークアップ４００内のあらゆる属性が、コンパイラが行う必要があるアクションに関するコンパイラに対するヒントを表わすことを示す。

例えば、ヒント４０８（以降、言語ヒント４０８と呼ぶ）は、言語ヒント４０８に割り当てられた言語（例えば、Ｃ＃）を使用してＩＬアセンブリを生成するようにコンパイラに示す。言語ヒント４０８には、Ｃ、Ｃ＋＋などの、様々ないくつかのプログラミング言語のいずれか１つが割り当てられていることが可能である。ヒント４１０（以降、ｄｅｆ：Ｃｌａｓｓヒント４１０と呼ぶ）は、ｄｅｆ：Ｃｌａｓｓヒント４１０に割り当てられた名前４１４（例えば、ＭｙＢｕｔｔｏｎ）を使用してサブクラスを定義するようにコンパイラに示す。また、ｄｅｆ：Ｃｌａｓｓヒント４１０は、新しいサブクラスの関連付けが行われるべきネームスペース（例えば、「ＭｙＣｏｎｔｒｏｌＬｉｂ」）を特定するサブクラスネームスペース４１２も含むことが可能である。したがって、図４では、開発者が「Ｓｙｓｔｅｍ．Ｃｏｎｔｒｏｌｓ」ネームスペースの中にある「Ｂｕｔｔｏｎ」クラスを拡張する「ＭｙＢｕｔｔｏｎ」と命名された新しいサブクラスを宣言的に定義している。この新しいサブクラスは、「ＭｙＣｏｎｔｒｏｌＬｉｂ」ネームスペースに関連付けられる。

図４に示したマークアップ４００の中で、エレメント宣言タグ４２０（例えば、「Ｉｍａｇｅ」）が定義されている。特定のネームスペースはエレメント宣言タグ４２０内で定義されていないため、ネームスペース属性４０４がエレメント宣言タグ４２０に関連するエレメント（例えば、「Ｉｍａｇｅ」）の場所も定義する。エレメント宣言タグ４２０は、エレメント４２１およびソース属性４２２を含む。ソース属性４２２は、プロパティ４２４（例えば、「Ｓｏｕｒｃｅ」）および値４２６（例えば、「ＨａｐｐｙＦａｃｅ．ｊｐｇ」）を含む。エレメント宣言タグ４２０は、「ＭｙＢｕｔｔｏｎ」と定義されたサブクラスに関するサブクラス定義内にあるため、エレメント宣言タグ４２０に関連するエレメントは、そのサブクラスがインスタンス化されたときにインスタンス化される。さらに、エレメント宣言タグ４２０に関連するエレメントは、その新しいサブクラスの子集合内に含まれる。言い換えれば、サブクラスがエレメント宣言タグ４２０に関連するエレメントに対する親である。したがって、マークアップ４００により、コンパイラが定義されているサブクラス（例えば、「ＭｙＢｕｔｔｏｎ」）をルートとするエレメントツリーを生成することを可能にするような形で、開発者が階層を表現できるようになることが、当分野の技術者には認められよう。

図５は、サブクラスに関する識別子、コード、およびコンストラクタを定義するための例示的なシンタックスを示している。マークアップ５００の主立った部分には、識別子、コード、およびコンストラクタを定義するためのマークアップに加えて、前述したマークアップ４００が含まれる。読み易くするため、図４に示し、前掲した符号は、新しい態様を説明するのに役立つのでない限り、図５では示していない。図５では、エレメント宣言タグ４２０が、ｉｄ属性５２０およびイベント属性５２６などの属性をさらに含む。ｉｄ属性５２０は、ｉｄプロパティ５２１（例えば、「ＩＤ」）およびｉｄ値５２３（例えば、「ｉｍｇ１」）を含む。ｉｄ属性５２０は、本発明によるサブクラスの識別子を定義するための例示的なメカニズムを示している。

イベント属性５２６は、イベントトリガ５２７（例えば、「ＤａｔａＬｏａｄｅｄ」）およびイベント値５２９（例えば、「ＯｎＬｏａｄｅｄ」）を含む。イベントトリガ５２７は、監視されるイベントを指定し、またイベント値５２９は、イベントトリガ５２７が生じた際に実行されるメソッドを指定する。イベント値５２９は、メソッド５３０（例えば、「ＯｎＬｏａｄｅｄ」ファンクション）に関連している。メソッド５３０は、プログラミング言語を使用して記述されていることが可能である。メソッド５３０は、マークアップ５００内で定義されたクラスおよびサブクラスのインスタンスを参照することが可能である。メソッド５３０がマークアップドキュメント内のプログラミング言語を使用して記述されているとき、メソッド５３０は、コードヒント５４０に関連する。コードヒント５４０により、開発者は、サブクラス定義の本文にコードの断片（code snippet）を追加することが可能になる。一実施例では、コードは、コードヒント５４０に従い、呼出し可能なメソッドまたはイベントハンドラである。マークアップ５００の中で、例えば、ＯｎＬｏａｄｅｄファンクション５３０が、Ｉｍａｇｅコントロールによって生成されたＤａｔａＬｏａｄｅｄイベントに対するイベントハンドラの役割をする。図５に示したＣｕｓｔｏｍＩｎｉｔファンクション５５０などのその他のコードの断片も、サブクラス定義の本文に追加することができる。

また、マークアップ５００は、コンストラクタヒント５４２も含む。コンストラクタヒント５４２により、開発者は、サブクラスに関して生成されたデフォルトのコンストラクタを補足する補足のコンストラクタを記述することが可能になる。一実施例では、補足のコンストラクタは、生成されたデフォルトのコンストラクタによって実行される最後の挙動（behavior）である。補足のコンストラクタは、構成時にサブクラスの挙動に影響を与えるコードを含むことが可能である。開発者は、補足のコンストラクタ内でスーパークラスのコンストラクタを呼び出すことができる。図５に示した補足のコンストラクタは、ユーザによって定義された専用メソッドであるＣｕｓｔｏｍＩｎｉｔファンクション５５０を呼び出す。

図６は、サブクラスに関するプロパティおよびイベントを定義するための例示的なシンタックスを示している。マークアップ６００の主立った部分には、プロパティおよびイベントを定義するためのマークアップに加えて、前述したマークアップ４００およびマークアップ５００が含まれる。読み易くするため、図４〜図５に示し、前掲した符号は、新しい態様を説明するのに役立つのでない限り、図６では示していない。

マークアップ６００は、プロパティをサブクラス上で定義することを可能にするプロパティヒント６１０を含む。プロパティは、サブクラスのメンバ変数として作用する。プロパティヒント６１０は、名前属性６１２、タイプ属性６１４、デフォルト値属性６１６、およびフラグ属性６１８などの属性を含むことが可能である。名前属性６１２は、プロパティの名前を指定する。一実施例では、名前は、大文字と小文字が区別され、ランタイムエンジンは、名前に使用される文字に全く制約を課さない。名前は、その名前を登録する所有者に固有でなければならない。タイプ属性６１４は、プロパティの値のタイプを指定する。このタイプには、組込みタイプ、ユーザ定義タイプ、ストラクト（struct）タイプ、クラスタイプ、インターフェースタイプ、列挙（enum）タイプ等が含まれる。デフォルト値属性６１６は、プロパティがインスタンス化されたときに割り当てられる値を指定する。フラグ属性６１８は、プロパティがインスタンス化されたときにラッパ（wrapper）によって生成されるメソッドのタイプを指定する。フラグは、読取り専用、子エレメントに継承可能、専用などの、プロパティの特性を制御する能力を有する。

また、マークアップ６００は、イベントヒント６２０も含む。イベントヒント６２０により、イベントをサブクラス上で定義することが可能になる。イベントヒント６２０は、名前属性６２２、ルート属性６２４、フラグ属性６２６などの属性を含むことが可能である。名前属性６２２は、イベントを指し示す文字列を指定する。ｘｍｌファイルがサブクラスを使用する際、ｘｍｌファイルは、この文字列を使用して適切なアプリケーション開発者によって定義されたコードを付加する。ルート属性６２４は、イベントを生成させる箇所のツリー内のエレメントを決めるメソッドを指定する。フラグ属性６２６はイベントに関連するその他の特徴を指定する。例えば、マークアップ６００の場合、マークアップコンパイラは、ＤｂｌＣｌｉｃｋと呼ばれるイベントを可能にするコードを生成し、サポートされるルート、フラグなどの、そのイベントに関連する情報を含む。本発明の範囲を逸脱することなく、属性に関連する名前および値を変更できることが、当分野の技術者には認められよう。

また、マークアップ６００は、イベントハンドラ宣言６３０も含む。イベントハンドラ宣言６３０には、公衆／専用、委託、リターンタイプなどのイベントハンドラ変更子６３２が関連していることが可能である。図６で、イベントハンドラ宣言６３０は、関連するイベントが生じたときに呼び出されるイベントハンドラ（すなわち、メソッド）（例えば、「ＤｂｌＣｌｉｃｋＥｖｅｎｔＨａｎｄｌｅｒ」）を宣言している。

その他のタグも、マークアップドキュメント内で定義することができる。例えば、ルートタグ（例えば、「ｄｅｆ：Ｌｉｂｒａｒｙ」）を使用して、別個のファイルの中のサブクラスを定義すること、１つのファイルの中で他のサブクラスとともにサブクラスを定義することなどを行うようにコンパイラおよび／またはパーサに通知することが可能である。カスタムエレメント、ルートタグ内で定義されたすべてのクラス等に関して、ネームスペースを定義することができる。

図７は、マークアップドキュメント内からのサブクラスを使用するための例示的なシンタックスを示すマークアップドキュメントの主立った部分を示している。マークアップ７００が、ルートエレメント７０２（例えば、ＦｌｏｗＰａｎｅｌ エレメント）、デフォルトのネームスペース宣言７０４、定義ネームスペースプレフィクス７０６、およびエレメント７０８を含む。エレメント７０８は、前に明示したシンタックスを使用して作成されたカスタムコンポーネントを参照することが可能なことが認められよう。デフォルトのネームスペース宣言７０４は、プレフィクスなしのタグに関するデフォルトのネームスペースを指定する。例示的なマークアップ７００の中で、デフォルトのネームスペース宣言７０４は、「Ｓｙｓｔｅｍ．Ｃｏｎｔｒｏｌｓ」ネームスペースを参照する。定義ネームスペースプレフィクス７０６は、カスタムコンポーネントまたはカスタムエレメントが見出される可能性がある場所を指定する。例示的なマークアップ７００の中で、定義ネームスペースプレフィクス７０６は、「ＭｙＣｏｎｔｒｏｌＬｉｂ」を参照する。エレメント７０８は、クラス名７１０（例えば、「ＭｙＣｏｎｔｒｏｌＬｉｂ」）、識別子７１２、およびテキスト文字列７１４を含む。クラス名７１０は、このエレメントに関してインスタンス化されたクラスを参照する。識別子７１２は、エレメントを参照し、名前（例えば、「ＩＤ」）および値（例えば、「ｂｕｔｔｏｎ１」）を含む。この値は、ランタイム中、クラス名７１０のインスタンスの名前になる。

実施例の一般化された動作
図８は、本発明の一実施例による宣言的に定義されたサブクラスをコンパイルするためのプロセスを一般的に示す論理流れ図である。図４〜図６に示した例示的なマークアップ、並びに図１０の代表的なソースコードを図８と併せて使用してプロセスを説明する。図１０をマークアップ６００と比較した後、容易に認識することができる通り、本発明により、開発者が基礎にあるプログラミング言語を理解することを必要とすることなく、洗練されたサブクラスを宣言的に生成することが可能になる。図１０の代表的なコードは、Ｃ＃ソースコードである。ただし、マークアップコンパイラは、本発明に従って、任意のプログラミング言語のシンタックスを使用して代表的なコードを生成することができる。

プロセスは、ブロック８０１で開始し、マークアップコンパイラがマークアップドキュメントをコンパイルし、サブクラス定義を有するマークアップに出会っている。マークアップコンパイラは、マークアップを別の形式としては認識しないこと、サブクラスタブ（例えば、ｄｅｆ：Ｃｌａｓｓ）を認識すること等によって自らがサブクラス定義に出会ったことを判定することができる。例えば、マークアップ４００の中で、マークアップコンパイラは、サブクラス定義を特定するサブクラスタグ（例えば、ｄｅｆ：Ｃｌａｓｓヒント４１０）に出会うまでに、いくつかのステートメントを処理することが可能である。別の実施例では、サブクラスタグに出会うのは、サブクラスがベースクラス（例えば、ボタン）を指定しないときなど、他のステートメントより前とすることも可能である。一般に、サブクラスタグは、マークアップ内でエレメントタグが出現することが可能なところであれば、どこにでも出現することが可能である。マークアップがサブクラス定義を有するものと特定されると、処理はブロック８０２に進む。

ブロック８０２で、サブクラスタグが処理される。図４に関連して説明した通り、サブクラスタグ（ｄｅｆ：Ｃｌａｓｓヒント４１０とも呼ばれる）に、名前４１４が割り当てられ、名前４１４は、サブクラスネームスペース４１２も含むことが可能である。この情報に基づき、図１０の行１などの代表的なコードをアセンブリのために生成することができる。さらに、図１０の行５に示したように、割り当てられた名前を有するクラスが生成される。行５には、さらなるステートメント（例えば、ネームスペースおよびスーパークラス）が処理されると、他の生成されたコードが増補される。サブクラスタグを処理することの一環として、プロセスは、サブクラスが何らかのクラス（すなわち、スーパークラス）から拡張されているかどうかを明らかにし、スーパークラスに関連する情報を獲得する。図４で、作成中のサブクラス「ＭｙＢｕｔｔｏｎ」が、スーパークラスタグ４０２で定義された「Ｂｕｔｔｏｎ」から拡張されている。したがって、図１０の行５は、図示する通り、ＢｕｔｔｏｎからＭｙＢｕｔｔｏｎを拡張する代表的なコードを含む。

さらに、サブクラスに関するデフォルトのコンストラクタが生成される。この場合も、さらなるステートメントが処理されると、このデフォルトのコンストラクタに、さらなる代表的なコードが増補されることが可能である。図１０の行２３〜２４および２６が生成された代表的なコードに相当する。ただし、以下に説明する通り、「ｔｈｉｓ．＿Ｉｎｉｔｉａｌｉｚｅ＿Ｔｈｉｓ（）」は、別のステートメントを処理した後に追加されるコードである。サブクラスタグが処理されると、処理はブロック８０４に進む。

ブロック８０４で、マークアップ内の次のステートメントが取り出される。次のステートメントは、サブクラス定義の中のサブクラスタグステートメントの場所に依存して、サブクラスタグステートメントの前のステートメントであることも、後のステートメントであることも可能である。次のステートメントが取り出されると、処理は判定ブロック８０６に進む。

判定ブロック８０６で、ステートメントがクラスを定義しているかどうかの判定が行われる。前述した通り、本発明により、階層を宣言的に表現することが可能になる。一実施例では、サブクラスの子である別のクラス（すなわち、エレメント）を定義するステートメントがサブクラスタグステートメントの後に出現する。当面、現行のステートメントはクラスを定義していないものと想定すると、処理はブロック８０８に進む。

ブロック８０８で、ステートメントが処理される。サブクラス定義の中で出現する可能性がある様々なタイプのステートメントが存在する。このステートメントは、様々な順序で出現することが可能である。各タイプのステートメントに関して関与する処理を以下により詳細に説明する。ただし、一般に、処理される各ステートメントは、サブクラス定義に関するさらなる代表的なコードの生成をもたらす。ステートメントの１つがブロック８０８で処理されると、処理は判定ブロック８１０に進む。

判定ブロック８１０で、サブクラス定義に関して処理されるべきステートメントが残っているかどうかが判定される。別のステートメントが存在する場合、処理はループバックしてブロック８０４〜８０８を通り、そのステートメントを処理する。サブクラス定義の中のすべてのステートメントが処理されると、処理は判定ブロック８１０からブロック８１２に進む。

ブロック８１２で、以上のプロセス中に生成された代表的なコードを使用して、サブクラス定義に関するＩＬアセンブリが生成される。開発者が、コンパイラヒントステートメント（ブロック８２０）のどれかの中で、代表的なコードを生成する際に使用するプログラム言語を指定していること、どのアセンブリファイルがサブクラス定義を記憶するかを指定していること等が可能である。ＩＬアセンブリまたはＩＬアセンブリ群が生成されると、処理は完了である。前述した通り、以上に生成されたアセンブリが、この時点で、従来のプログラミング言語を使用する、本発明によるマークアップステートメントを使用するなどして、実行されるように用意されている。アセンブリは、あたかもプログラム言語を使用して記述されているかのように見える。

判定ブロック８０６に戻ると、ステートメントが新しいクラス（すなわち、エレメント）に関する定義を開始した場合、処理はブロック８１４に進む。ブロック８１４で、この新しいクラスに関係があるステートメントが、各ステートメントに関してブロック８０８内の処理を使用して処理され、その新しいクラスに関係があるすべてのステートメントの処理が済むまで、処理が続けられる。例えば、図５で、新しいクラス「Ｉｍａｇｅ」に関するステートメント５２０、５２６、４２２が処理される。Ｉｍａｇｅは、サブクラス「ＭｙＢｕｔｔｏｎ」の子である。処理はブロック８０４に進み、そのサブクラスに関連するステートメントを処理することを続けて行う。

次に、ブロック８０８に戻ると、サブクラス定義の中で出現する可能性があるそれぞれの個別タイプのステートメント（ブロック８２０〜８３２）に関する処理を説明する。ブロック８２０で、コンパイラヒントであるステートメントが処理される。一般に、コンパイラヒントであるステートメントは、どのようにアセンブリが生成されるべきかに関する情報をマークアップコンパイラに提供する。例えば、図４では、言語ヒント４０８が、代表的なコードを生成する際に使用するプログラミング言語をマークアップコンパイラに通知するコンパイラヒントステートメントである。図４で、言語ヒント４０８には、Ｃ＃が割り当てられており、したがって、図１０で示される代表的なコードは、Ｃ＃ソースコードである。

ブロック８２２で、ネームスペースを定義するステートメントが処理される。次に、このネームスペースが、図１０の行２および３で示すように代表的なコードの中に含められる。

ブロック８２４で、クラスの識別子（ｉｄ）を定義するステートメントが処理される。マークアップドキュメント内のあらゆるｉｄ属性に関して、マークアップコンパイラは、関連するクラスに関するフィールドメンバを生成する。ｉｄ属性が定義されているクラスと同じタイプを有するフィールドメンバが生成される。フィールドメンバの名前は、そのｉｄ属性に割り当てられたｉｄ値である。例えば、図５では、Ｉｍａｇｅクラスに関係があるステートメントを処理する際、ｉｄ属性５２０に出会う。したがって、図１０の行７で示す通り、マークアップコンパイラは、以下の通り定義されたフィールドメンバを有するＭｙＢｕｔｔｏｎクラスに関する代表的なコードを生成する。

private System.Controls.Image img1
ランタイム中、フィールドメンバは、ＩｎｉｔＣｏｍｐｏｎｅｎｔ（）メソッドにおいて生成された対応するタイプ（例えば、Ｉｍａｇｅ）のインスタンスに初期設定される。この結果、ＭｙＢｕｔｔｏｎクラスの中の任意のコードが、単にクラスのｉｄ値によって階層内の任意の他のエレメントインスタンスにアクセスすることができる。フィールドメンバを初期設定することを図１０の行３７で示している。

ブロック８２６で、クラスに関するプロパティを定義するステートメントが処理される。マークアップドキュメント内で定義されたあらゆるプロパティに関して、マークアップコンパイラは、そのプロパティに関する代表的なソースコードを生成し、必要な場合、そのプロパティを登録する。例えば、図６では、マークアップ６００が、様々な属性６１２〜６１８を有するプロパティヒント６１０を含んでいる。プロパティヒント６１０は、プロパティヒント６１０に続くステートメントがプロパティに関するものであることをマークアップコンパイラに知らせる。次に、属性６１２〜６１８がプロパティステートメントとして読み込まれる。マークアップコンパイラは、図１０の行９〜１２に示される通り、「Ｌａｂｅｌ」プロパティに関する代表的なコードを生成してＭｙＢｕｔｔｏｎクラスに関するプロパティを登録する。また、マークアップコンパイラは、図１０の行２８〜３０で示されるプロパティを定義する代表的なコードも生成する。行２８〜３０は、どのように名前属性６１２が代表的なコードの中のプロパティの名前になるか、またどのようにタイプ属性６１４が代表的なコードの中のプロパティに関するタイプになるかを示している。

一実施例では、プロセスは、反映を使用してランタイムにコードを実行するプロパティのタイプに関するＴｙｐｅＣｏｎｖｅｒｔｅｒを呼び出し、文字列をプロパティタイプの実際のオブジェクトインスタンスに変換することによってプロパティの値に関するコードを生成する。別の実施例では、プロセスが実際のオブジェクト値を獲得するためにプロパティに関するタイプコンバータを呼び出し、値をＩｎｓｔａｎｃｅＤｅｓｃｒｉｐｔｏｒオブジェクトに変換することもできる。ＩｎｓｔａｎｃｅＤｅｓｃｒｉｐｔｏｒオブジェクトは、十分な情報を含み、したがって、マークアップコンパイラは、このオブジェクトを反映させて、プロパティヒントに関連する属性の中で指定される通り値のタイプの新しいインスタンスを生成する代表的なコードを生成することができる。図１９の行２８〜３０は、ランタイム中、どのようにｌａｂｅｌＰｒｏｐｅｒｔｙがＬａｂｅｌプロパティの割当て値でＭｙＢｕｔｔｏｎのインスタンス上に設定されるかを示している。この割当て値は、マークアップ内で（図７に示す通り）宣言的に割り当てること、または任意のプログラミング言語を使用してプログラミングで割り当てることが可能である。

ブロック８２８で、クラスに関するイベントを定義するステートメントが処理される。イベントステートメントの場合、マークアップコンパイラは、そのイベントに関する代表的なコードを生成する。イベントは、図５に示したイベント属性５２６、および図６に示したイベントヒント６２０などの様々なメカニズムを使用してマークアップ内で定義することができる。まず、イベント属性を使用するメカニズムを説明する。イベント属性は、イベントトリガおよびイベント値を含む。イベントトリガは、イベントに対応し、またイベント値は、イベントトリガが生じた際に実行されるメソッドに対応する。図５を参照すると、「ｔｈｉｓ．ＯｎＬｏａｄｅｄ」を新しいＳｙｓｔｅｍ．Ｃｏｎｔｒｏｌｓ．ＤａｔａＬｏａｄｅｄＥｖｅｎｔＨａｎｄｌｅｒとして定義することにより、イベント値５２９（「ＯｎＬｏａｄｅｄ」）が、図１０の代表的なコードの行３８〜４０でイベントハンドラとして追加されている。ＡｄｄＨａｎｄｌｅｒの最初のパラメータをＳｙｓｔｅｍ．Ｃｏｎｔｒｏｌｓ．Ｉｍａｇｅ．ＤａｔａＬｏａｄｅｄＥｖｅｎｔとして定義することにより、イベントトリガ５２７（「ＤａｔａＬｏａｄｅｄ」）が、図１０の代表的なコードの行３８でイベントとして追加されている。ＡｄｄＨａｎｄｌｅｒのその他のパラメータは、デフォルト値を使用すること、またはマークアップドキュメント内で指定されることが可能である。

次に、イベントヒント６２０を使用するメカニズムを説明する。イベントヒント６２０は、イベント名属性およびその他の属性を含む。イベント名属性に割り当てられた名前は、イベントとして登録される。例えば、図６を参照すると、「ＤｂｌＣｌｉｃｋ」がイベント名属性に割り当てられた名前である。したがって、「ＤｂｌＣｌｉｃｋ」は、図１０の行１４〜１６で生成されるＲｅｇｉｓｔｅｒＥｖｅｎｔメソッドの最初のパラメータである。メソッド「ＤｂｌＣｌｉｃｋＥｖｅｎｔＨｄｌｒ」もまた図１０のＲｅｇｉｓｔｅｒＥｖｅｎｔメソッドのパラメータとして含まれる。この場合も、ＲｅｇｉｓｔｅｒＥｖｅｎｔメソッドのその他のパラメータは、デフォルト値を使用すること、またはその他の属性を使用してマークアップドキュメント内で指定されることが可能である。ランタイム中、一実施例によれば、イベントは、反映を使用してＤｂｌＣｌｉｃｋＥｖｅｎｔＨａｎｄｌｅｒのタイプを特定し、そのメソッドを探し出すように結合（hook up）される。

ブロック８３０で、コードを定義するステートメントが処理される。コードを定義するステートメントは、コードヒントなどのコンパイラヒントステートメント（ブロック８２０）に従う。このステートメントは、プログラミング言語で記述され、代表的なコードの中でそそまま現れる。例えば、図５がメソッド５３０およびＣｕｓｔｏｍＩｎｉｔファンクション５５０を示している。メソッド５３０およびＣｕｓｔｏｍＩｎｉｔファンクション５５０はそれぞれ、図１０の行１８〜１９および２１で現れる。

ブロック８３２で、補足のコンストラクタを定義するステートメントが処理される。この場合も、補足のコンストラクタを定義するステートメントは、コンストラクタヒントなどのコンパイラヒントステートメント（ブロック８２０）に従う。マークアップコンパイラは、補足のコンストラクタ（図１０の「ｔｈｉｓ．＿Ｉｎｉｔｉａｌｉｚｅ＿Ｔｈｉｓ（）」）を生成し、その補足のコンストラクタ内でステートメントを追加する。例えば、図５では、コンストラクタヒント５４２の後のステートメントが「ＣｕｓｔｏｍＩｎｉｔ（）」を呼び出す。したがって、図１０では、行３３で、マークアップコンパイラが、「ＣｕｓｔｏｍＩｎｉｔ（）」を代表的なソースコードの中の補足のコンストラクタに追加する。

本発明を逸脱することなく、ブロック８１２は、ブロック８０４〜８１０を処理しながら、漸進的に行うことが可能なことが、当分野の技術者には認められよう。さらに、パーサ２０４およびマークアップコンパイラ２０２の機能上の実施形態に依存して、プロセス中にパーサ２０４とマークアップコンパイラ２０２の間でコールバックが存在することが可能である。

図９は、本発明の一実施例によるマークアップドキュメント内から宣言されたサブクラスを使用するためのランタイムプロセス９００を一般的に示す論理流れ図である。図７に示した例示的なマークアップを図９と併せて使用してプロセス９００を説明する。プロセス９００は、ブロック９０１で開始し、ランタイムエンジンが特定のリソース（例えば、マークアップドキュメント）に関する要求を受け取り、その特定のリソースに関してコンパイル済みのバージョンが存在することを判定する。例えば、図７で、マークアップ７００が以前にトークン化バイナリファイルにコンパイルされていないものと想定すると、マークアップコンパイラは、エレメント７０８に出会ったとき、ＭｙＢｕｔｔｏｎクラスが、関連するトークン化バイナリファイルおよびＩＬアセンブリを有することを判定する。次に、ＭｙＢｕｔｔｏｎクラスに関するトークン化属性を含むこの関連するトークン化バイナリファイルがプロセス９００を使用して処理される。関連するトークン化バイナリファイルおよびＩＬアセンブリは、本発明を使用して生成されていることが可能である。処理はブロック９０２に進む。

ブロック９０２で、トークン化バイナリファイルがロードされる。トークン化バイナリファイルは、漸進的にロードされること、または全体がロードされることが可能である。トークン化バイナリファイルは、ロードされる必要があるトークン化バイナリファイルに関連するＩＬアセンブリを特定することが可能である。図７を参照すると、例えば、ＭｙＢｕｔｔｏｎクラスに関連するＩＬアセンブリがロードされる。処理はブロック９０４に進む。

ブロック９０４で、トークンがトークン化バイナリファイルから取り出される。前述した通り、新しいランタイム環境において、生成されたトークン化バイナリファイルは、そのトークン化バイナリファイルを生成するのに使用されたプログラミング言語とは独立である。したがって、ランタイムエンジンは、トークン化バイナリファイルを生成するのに最初に使用されたプログラミング言語を考慮することなく、そのトークン化バイナリファイルを処理することができる。処理は判定ブロック９０６に進む。

判定ブロック９０６で、取り出されたトークンがイベントであるかどうかの判定が行われる。トークンがイベントではない場合、処理はブロック９０８に進む。

ブロック９０８で、トークンが処理される。前述した通り、トークンの処理は、トークン化バイナリファイルが生成された仕方に依存しない。言い換えれば、マークアップドキュメント内から、またはプログラミング言語を使用して宣言的に作成されたトークン化バイナリファイル内のトークンの処理は、同様に行われる。したがって、トークン化バイナリファイル内のトークンの処理は当分野の技術者には周知であるため、トークンの処理を本明細書で詳述するまでもない。処理は判定ブロック９１０に進む。

判定ブロック９１０で、トークン化バイナリファイル内にさらなるトークンが存在するかどうかが判定される。さらなるトークンが存在する場合、処理はブロック９０４にループバックして、前述した通り進められる。これに反して、もはやトークンが存在しない場合、処理は完了であり、終了ブロックに進む。

判定ブロック９０６に戻ると、トークンがイベントであった場合、処理はブロック９１２に進む。ブロック９１２で、トークン化バイナリファイルに関連するメタデータがロードされる。メタデータには、タイプ、リソース、メソッド等に関する記述が含まれる。処理はブロック９１４に進む。

ブロック９１４で、メタデータおよび反映を使用して、プロセスは、イベントに関するターゲットエレメントのタイプを見出す。これには、メタデータにアクセスすること、および各フィールドを調べてタイプを判別することが関わる。処理はブロック９１６に進む。

ブロック９１６で、イベントは、そのターゲットエレメントのタイプに対して検証される。これにより、イベントが有効なイベントであることが確実なものとなる。イベントがそのターゲットエレメントのタイプに対して有効なイベントではない場合、誤りがもたらされる。処理はブロック９１８に進む。

ブロック９１８で、ターゲットエレメントのタイプに対して判定を使用してイベントメソッドを獲得し、次に、イベントメソッドが実行される。イベントメソッドの実行には、関連するＩＬアセンブリ内のコードを実行することが関わる。したがって、図７を参照すると、ＭｙＢｕｔｔｏｎがインスタンス化されてイベントが見出されると、イベントメソッド（「ＤｂｌＣｌｉｃｋＥｖｅｎｔ」）が付加される。これにより、イベントハンドラ（例えば、ＤｂｌＣｌｉｃｋＥｖｅｎｔＨａｎｄｌｅｒ）がイベント（例えば、ＤｂｌＣｌｉｃｋ）に付加される。処理は判定ブロック９１０に進み、前述した通り進められる。

したがって、前述した通り、本発明により、マークアップドキュメント内でサブクラスを宣言的に定義するため、およびマークアップドキュメント内からサブクラスを使用するためのメカニズムが提供される。これにより、開発者が、いずれか１つのプログラミング言語でコンポーネントをどのように実装するかを気にする代わりに、コンポーネントを使用する仕方により集中することができるようになる。

以上の明細書、実施例、およびデータにより、本発明のコンポーネントの製造および使用の完全な説明が提供される。本発明の趣旨および範囲を逸脱することなく、本発明の多くの実施例を実現することが可能であるため、本発明は、特許請求の範囲に存するものとする。

本発明の例示的な実施例で使用することが可能な例示的なコンピューティングデバイスを示す図である。 本発明の一実施例を実施するためのコンポーネントを一般的に示す機能ブロック図である。 本発明の一実施例を実施するためのランタイム環境を一般的に示す機能ブロック図である。 本発明の一実施例によるサブクラスを宣言的に定義するための例示的なシンタックスを示すマークアップドキュメントの一連の主立った部分を示す図である。 本発明の一実施例によるサブクラスを宣言的に定義するための例示的なシンタックスを示すマークアップドキュメントの一連の主立った部分を示す図である。 本発明の一実施例によるサブクラスを宣言的に定義するための例示的なシンタックスを示すマークアップドキュメントの一連の主立った部分を示す図である。 マークアップドキュメント内から実行可能なコンポーネントを使用するための例示的なシンタックスを示すマークアップドキュメントの主立った部分を示す図である。 本発明の一実施例による宣言的に定義されたサブクラスをコンパイルするためのプロセスを一般的に示す論理流れ図である。 本発明の一実施例によるマークアップドキュメント内から宣言されたサブクラスを使用するためのランタイムプロセスを一般的に示す論理流れ図である。 図４〜図６に示したマークアップドキュメントに基づき図２に示したマークアップコンパイラによって生成された代表的なソースコードの例示的なソースコードリストを示す図である。

符号の説明

１００ コンピューティングデバイス
１０２ 処理ユニット
１０４ システムメモリ
１０５ オペレーティングシステム
１０６ プログラムモジュール
１０７ プログラムデータ
１０９ 取外し可能なストレージ
１１０ 取外し不可能なストレージ
１１２ 入力装置
１１４ 出力装置
１１６ 通信接続
１１８ 他のコンピューティングデバイス
２０２ マークアップコンパイラ
２０４ パーサ
２０６ マークアップドキュメント
２０８ トークン化バイナリファイル
２１０ ＩＬアセンブリ
２１２ ソースコード
３０２ ランタイムエンジン
３０４ トークン化バイナリリーダ
３０６ トークン化バイナリローダ
３０８ ページマップテーブル
３１０ メタデータ

Claims (4)

1. サブクラスに関する実行可能なアセンブリを生成するための命令を記憶したコンピュータ可読記録媒体であって、
   前記命令により、コンピュータに、
   拡張可能なマークアップ言語（ＸＭＬ）に基づいて作成されたマークアップドキュメント内で、スーパークラスからサブクラスを定義するサブクラス定義を特定させることと、
   前記サブクラスに関連するオブジェクトのインスタンスを生成可能なアセンブリを前記サブクラス定義に基づいて生成させること、を行わせ、
   前記生成されたアセンブリはプログラム言語とは関係なくコンピュータ内で実行されるように前記アセンブリを生成するために最初に使用されたプログラミング言語からは独立であり、
   前記サブクラス定義を前記コンピュータに特定させることはサブクラスタグを構文解析させることを含み、該サブクラスタグは名前を定義するためのサブクラス名前属性を含み、前記名前はインスタンス化される前記オブジェクトのタイプに関連付けられ、
   前記アセンブリを前記コンピュータに前記サブクラス定義に基づいて生成させることは、
   前記サブクラスがそこから導出されるスーパークラスを定義するスーパークラスタグを前記コンピュータに構文解析させることと、
   プログラム言語に関連するシンタックスを使用して前記コンピュータに継承を指定させることと、
   前記アセンブリの一部となるように前記コンピュータに前記シンタックスをコンパイルさせること
   を含むことを特徴とするコンピュータ可読記録媒体。
2. コンピュータによって実施される、実行可能なアセンブリを生成する方法であって、
   コンピュータ内において、拡張可能なマークアップ言語（ＸＭＬ）に基づいて作成されたマークアップドキュメント内で、スーパークラスからサブクラスを定義するサブクラス定義を特定するステップと、
   コンピュータ内において、前記サブクラスに関連するオブジェクトのインスタンスを生成可能なアセンブリを前記サブクラス定義に基づいて生成するステップと、を含み
   前記生成されたアセンブリはプログラム言語とは関係なくコンピュータ内で実行されるように前記アセンブリを生成するために最初に使用されたプログラミング言語からは独立であり、
   前記サブクラス定義を特定する前記ステップはサブクラスタグを構文解析することを含み、該サブクラスタグは名前を定義するためのサブクラス名前属性を含み、前記名前はインスタンス化される前記オブジェクトのタイプに関連付けられることを含み、
   アセンブリを前記サブクラス定義に基づいて生成する前記ステップは、
   前記サブクラスがそこから導出されるスーパークラスを定義するスーパークラスタグを構文解析するステップと、
   プログラム言語に基づくシンタックスを使用して継承を指定するステップと、
   前記アセンブリの一部となるように前記シンタックスをコンパイルするステップと
   を含むことを特徴とする方法。
3. 拡張可能なマークアップ言語（ＸＭＬ）に基づいて作成されたマークアップドキュメントを使用してスーパークラスからサブクラス定義からアセンブリを生成するためのコンピュータシステムであって、
   プロセッサとメモリを含んでおり、
   該メモリは、前記プロセッサにより複数のコンピュータ実行可能命令がロードされるために割り振られ、
   該コンピュータ実行可能命令により、前記プロセッサに
   マークアップドキュメント内で、サブクラスを定義するサブクラス定義を特定させるステップと、
   前記サブクラスに関連するオブジェクトのインスタンスを生成可能なアセンブリを前記サブクラス定義に基づいて生成させるステップと、を含む方法を行わせ、
   前記生成されたアセンブリはプログラム言語とは関係なくコンピュータ内で実行されるように前記アセンブリを生成するために最初に使用されたプログラミング言語からは独立であり、
   前記サブクラス定義を特定させる前記ステップは前記プロセッサにサブクラスタグを構文解析させることを含み、該サブクラスタグは名前を定義するためのサブクラス名前属性を含み、前記名前はインスタンス化される前記オブジェクトのタイプに関連付けられることを含み、
   アセンブリを前記プロセッサに前記サブクラス定義に基づいて生成させる前記ステップは、前記オブジェクトがインスタンス化されると行われる少なくとも１つの補足のアクションを定義するコンストラクタヒントを前記プロセッサに構文解析させることを含んでおり、前記補足のアクションは前記アセンブリの一部であることを特徴とするコンピュータシステム。
4. 実行可能なアセンブリを生成するシステムであって、
   拡張可能なマークアップ言語（ＸＭＬ）に基づいて作成されたマークアップドキュメント内で、スーパークラスからサブクラスを定義するサブクラス定義を特定するための手段と、
   前記サブクラスに関連するオブジェクトのインスタンスを生成可能なアセンブリを前記サブクラス定義に基づいて生成するための手段と、を含み、
   前記生成されたアセンブリはプログラム言語とは関係なくコンピュータ内で実行されるように前記アセンブリを生成するために最初に使用されたプログラミング言語からは独立であり、
   前記サブクラス定義を特定するための前記手段はサブクラスタグを構文解析するための手段を含み、該サブクラスタグは名前を定義するためのサブクラス名前属性を含み、前記名前はインスタンス化される前記オブジェクトのタイプに関連付けられ、
   アセンブリを前記サブクラス定義に基づいて生成するための前記手段は、
   前記サブクラスがそこから導出されるスーパークラスを定義するスーパークラスタグを構文解析するための手段と、
   プログラム言語に基づくシンタックスを使用して継承を指定するための手段と、
   前記アセンブリの一部となるように前記シンタックスをコンパイルするための手段と
   を含むことを特徴とするシステム。

Images