(57)【要約】【課題】コンピュータシステムにおいて対象に関係する任意のデータを記述し、得るために使用する方法を提供する。【解決手段】この方法はメタ言語「構造化データの汎用オブジェクト指向記述（ＧＤＬ）」およびパーサを提供する。ＧＤＬによりユーザがテンプレートとして知られるスキーマの使用を介して対象を編成、定義かつ記述できる。テンプレートを用いて各対象要素の意味を定義でき、各要素がより大きいデータフレームワークに適合する方法を定義できる。継承の概念を介し、テンプレートを変化するレベルのネスティングに拡張かつ定義し、なおプロパティの共通コアを有せる。ＧＤＬにより、対象のフィーチャおよび属性を、ソースファイルの変更により、高速かつ容易に拡張あるいは修正できる。ＧＤＬパーサは、情報の構造化および階層化表現、テキストエントリの意味の検証、およびソースファイルから得られた情報をトラバースする手段を提供する。【選択図】図３
2008251033.tif 000002
【特許請求の範囲】
【請求項１】
サードパーティがＶａｌｕｅペアまたはコンストラクトを追加することができ、１つ以上の周辺デバイスに関係する情報を編成し、記述するための、コンピュータシステムにおいて用いられるコンピュータ実施方法であって、
前記コンピュータシステムが、各周辺デバイスを特徴付ける複数のエントリを含むソースファイルを前記コンピュータシステム上で動作するパーサに提供するステップであって、前記エントリが継承ベースのスキーマのインスタンシエーションであり、予め定義されたメタ言語構文に準拠している、そのようなソースファイルを提供するステップと、
前記コンピュータシステムが、前記パーサに前記ソースファイルの編成のためのスキーマを提供するステップであって、前記スキーマは１つ以上の、テンプレートのファミリを備え、テンプレートの各ファミリは、対応する周辺デバイスの機能を記述し、かつ、少なくとも１つのベーステンプレートを含むものであり、前記ベーステンプレートは、コンストラクトタイプであり、かつ、テンプレートの派生セットと、タイプの指定を含むテンプレートのメンバーセットとを含むように構成されるものであり、前記テンプレートの派生セットは、前記ベーステンプレートの特徴を継承するものであり、前記ベーステンプレートから派生された各派生テンプレートはコンストラクトタイプであり、かつ、少なくとも１つの名前と少なくとも１つのメンバテンプレートとを含むものであり、各メンバテンプレートは、名前を含み、かつ、エントリのセットの１つ以上のプロパティを定義するものである、そのようなスキーマを提供するステップと、
前記コンピュータシステムは、前記パーサを介して、前記ソースファイルからの１つ以上のエントリを同じファミリにおける他の先祖テンプレートに関連付けるステップと
を備えることを特徴とする方法。
【請求項２】
請求項１に記載の方法であって、前記１つ以上のエントリのプロパティがスキーマによって定義されることを特徴とする方法。
【請求項３】
請求項１に記載の方法であって、前記コンピュータシステムがテンプレートおよびエントリの内部表現を提供するステップをさらに備えることを特徴とする方法。
【請求項４】
請求項１に記載の方法であって、前記コンピュータシステムが前記関連付けをシリアライズするステップであって、前記シリアライズにより、前記ソースファイルを再読み込みする必要なしに、エントリの前記関連付けの系統的トラバースを可能にするステップをさらに備えることを特徴とする方法。
【請求項５】
請求項１に記載の方法であって、前記コンピュータシステムが前記関連付けをフィルタリングするステップをさらに備えることを特徴とする方法。
【請求項６】
請求項５に記載の方法であって、前記フィルタリングするステップが、前記関連付けの意味を検証するステップを含むことを特徴とする方法。
【請求項７】
請求項５に記載の方法であって、前記フィルタリングするステップが、前記関連付けにおける値タイプを変換するステップを含むことを特徴とする方法。
【請求項８】
請求項５に記載の方法であって、前記フィルタリングするステップが、値のデフォルト初期化を行うステップを含むことを特徴とする方法。
【請求項９】
請求項１に記載の方法を実行するためのコンピュータ実行可能命令を有することを特徴とするコンピュータ可読記憶媒体。
【請求項１０】
プロセッサ、メモリおよびオペレーティング環境を有し、請求項１に記載の方法を実行するように動作可能であることを特徴とするコンピュータシステム。
【請求項１１】
サードパーティがＶａｌｕｅペアまたはコンストラクトを追加することができ、１つ以上の周辺デバイスに関係する情報を、ソースファイル内で編成し、記述するための、コンピューティングシステムにおいて用いられるコンピュータ実施方法であって、
前記コンピュータシステムが、前記コンピュータシステム上で稼動するパーサに、前記ソースファイルの編成のためのスキーマを提供するステップであって、前記スキーマはテンプレートの１つ以上のファミリを含むものであり、テンプレートの各ファミリは、少なくとも１つの周辺デバイスを記述し、かつ、少なくとも１つのベーステンプレートを含むものであり、前記ベーステンプレートはテンプレートのメンバーセットおよびテンプレートの派生セットを含むように構成され、前記テンプレートのメンバーセットからの各メンバテンプレートはタイプの指定を含むものであり、前記テンプレートの派生セットは前記ベーステンプレートの特徴を継承するものであり、前記ベーステンプレートから派生された各派生テンプレートはコンストラクトタイプであり、かつ、少なくとも１つの名前と少なくとも１つのメンバテンプレートを含むものであり、各メンバテンプレートは名前を含み、かつ、エントリのセットの１つ以上のプロパティを定義するものである、そのようなスキーマを提供するステップと
を備えることを特徴とする方法。
【請求項１２】
請求項１１に記載の方法であって、前記スキーマが、
他の定義済みテンプレートをベースフレームワークとして利用する１つ以上のテンプレートを備え、
前記テンプレートが、変化するレベルでネストされることを特徴とする方法。
【請求項１３】
請求項１１に記載の方法であって、前記テンプレートが他のテンプレートを継承することを特徴とする方法。
【請求項１４】
請求項１１に記載の方法であって、前記テンプレートは、デバイスデータ要素のための意味を定義し、かつ、デバイスデータ要素が、より大きいフレームワークにどのように適合するかを定義するものであることを特徴とする方法。
【請求項１５】
請求項１１に記載の方法を実行するためのコンピュータ実行可能命令を有することを特徴とするコンピュータ可読記憶媒体。
【請求項１６】
プロセッサ、メモリおよびオペレーティング環境を有し、請求項１１に記載の方法を実行するように動作可能であることを特徴とするコンピュータシステム。
【請求項１７】
サードパーティがＶａｌｕｅペアまたはコンストラクトを追加することができ、周辺デバイスを記述するための、コンピュータシステムにおいて用いられるコンピュータ実施方法であって、
前記コンピュータシステムが、該コンピュータシステム上で稼動するパーサにテンプレートエントリおよび非テンプレートエントリを含むソースファイルを提供するステップであって、各テンプレートエントリは、少なくとも１つの対応する周辺デバイスの機能を記述するテンプレートエントリのファミリに属し、テンプレートエントリの各ファミリは少なくとも１つのベーステンプレートを含むものであり、前記ベーステンプレートはコンストラクトタイプであり、かつ、テンプレートのメンバーセットおよびテンプレートの派生セットを含むように構成されるものであり、前記テンプレートのメンバーセットからの各メンバテンプレートはタイプの指定を含み、前記テンプレートの派生セットは、前記ベーステンプレートの特徴を継承し、前記ベーステンプレートから派生された各派生テンプレートは、名前と少なくとも１つのメンバテンプレートとを含むコンストラクトタイプであり、各メンバテンプレートは、エントリのセットの１つ以上のプロパティを定義するものである、そのようなソースファイルを提供するステップと、
前記パーサが、少なくとも１つのツリーを作成するステップであって、作成されたツリーの各ノードは、非テンプレートエントリを、対応するテンプレートエントリに関係付けるものであり、前記パーサは、動的に構成可能な表現を、前記テンプレートエントリの少なくとも一部のそれぞれに関係付ける、そのようなツリーを作成するステップと
を備えることを特徴とする方法。
【請求項１８】
前記コンピュータシステムは、前記ソースファイルの表現を含むリアルツリー（ＲｅａｌＴｒｅｅ）および前記リアルツリーの論理構造の表現を含むインデクスツリー（ＩｎｄｅｘＴｒｅｅ）を作成するパーサを利用可能にするステップをさらに備えることを特徴とする請求項１７に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般にコンピュータソフトウェアに関し、より詳細には、コンピュータシステムにおける任意データに関係する情報を編成、定義かつ得るための方法およびシステムに関する。
【背景技術】
【０００２】
コンピュータのオペレーティングシステムは一般に、システムおよびアプリケーションの情報を複数のメーカの様々なデバイスと通信するための機能を組み込んでいる。コンピュータ業界の成長は、ハードウェアおよびソフトウェア周辺製品を市場向けに提供する多数の企業を生んだ。これらすべての場合で、オペレーティングシステムメーカは、このようなハードウェアおよびソフトウェアがインストールされるコンピュータ内、およびその間で互換性およびデータ交換を保証しなければならない。コンピュータシステム上で実行される多数のアプリケーションプログラムが有効に周辺デバイスと通信できるようにするため、オペレーティングシステム設計者は、デバイス非依存アクセスを可能にするインターフェイスを開発している。このような２つのインターフェイスは、グラフィックスデバイスインターフェイス（ＧＤＩ）および汎用プリンタ定義言語（ＧＰＤ）であり、これらはいずれも特にプリンタデバイスを処理するために設計された。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ＧＤＩは、デバイスに依存しない方法で印刷デバイスへのアクセスを可能にする機能を呼び出すことによって、アプリケーションプログラムからの出力データに作用する。まず、図２を参照すると、ＧＤＩは、プログラムがデータを送信するアプリケーションプログラム２０１および出力周辺デバイスに、一様なインターフェイス２０２を提供する。この一様なインターフェイスにもかかわらず、ＧＤＩは、市場で入手可能なプリンタデバイスの多数の各モデルを駆動することが可能な実際のプリンタコントロールコマンドを生成することができない。このように、個々の各プリンタは、ＧＤＩからの標準化された出力に基づいて、各プリンタの様々なコントロール機能を実施することができるそれ自体の個別のプリンタドライバを必要とした。これらの標準機能には、初期化、情報、出力、属性、モードおよびエスケープシーケンスが含まれた。これらのモノリシックな各ドライバは、各プリンタについて必要なインターフェイスを提供したが、これらは一般にサイズが非常に大きかった。このような拡張ドライバの必要性は、プリンタのメーカおよびオペレーティングシステムのベンダだけでなく、このようなドライバがインストールされる個々のコンピュータシステムにも影響を与えた。具体的には、システム上の空間要件およびリソース利用が、特に複数のプリンタをサポートする必要があるとき、非実際的なものとなる。加えて、これらのドライバの開発およびコーディングは、どんなによくても厄介である。ＧＤＩに関係する問題を克服するため、これらのドライバの記述を支援するようにグラフィカルユーザインターフェイス（ＧＵＩ）ツールが開発された。このツールにはＧｅｎｅｒｉｃ  Ｐｒｉｎｔｅｒ  Ｃｈａｒａｃｔｅｒｉｚａｔｉｏｎ（ＧＰＣ）が含まれており、これは、プリンタの相手先商品製造会社（ＯＥＭ）によって供給される１つ以上のプリンタの全機能性および能力を記述することのアプリケーション非依存性を提供するように意図されたものである。ＧＰＣは、プリンタデバイスを記述する能力が制限されており、プリンタ機能のための拡張性が制限されている。そのため、ＧＰＤとして知られたプリンタ定義内で使用される構文および意味（ｓｅｍａｎｔｉｃｓ）の柔軟性のあるモジュールアーキテクチャの開発に至った。この定義言語はより様々なプリンタのためのよりよいサポートを提供し、再設計を必要とすることなく、出力品質、使いやすさおよびパフォーマンスを向上させる。
【０００４】
さらに図２を参照すると、ＧＰＤはテキストベースのプリンタ記述ファイルフォーマットであり、単一のユニバーサルドライバ２０４で動作するミニドライバ２０３Ａおよび２０３Ｂを作成するためのものである。通常、各プリンタモデル２０５Ａおよび２０５Ｂについて１つのＧＰＤファイルがあり、異なるプリンタもＧＰＤファイルを共有することができる。ＧＰＤファイルはプリンタのすべての機能を記述し、これには、これらの機能の表示方法および呼び出し方法が含まれる。ＧＰＤファイルはまた、プリンタ固有のコマンドおよび属性も含み、これによりユニバーサルドライバ２０４が正しいプリンタレディ（ｐｒｉｎｔｅｒ−ｒｅａｄｙ）出力データを生成することができる。
【０００５】
ＧＰＤは汎用機能、カスタムヘルプ、インストール可能なオプションおよび様々なタイプの制約をサポートするが、これは、プリンタデバイスのみを対象とするという事実において制限されている。値依存性のためにＧＰＤにおいて提供されるサポートは、開発者がプリンタコマンドおよび／または属性の間のいかなる種類の依存性をも記述することを可能にする。このサポートは、コマンドパラメータ仕様スキームとあいまって、有用である一方、言語の幅広い規模の適用可能性においていくつかの制約でもある。ＧＰＤ用のパーサはデータを単一のバイナリフォーマットに解析するため、ユニバーサルドライバは、ＧＰＣ改訂版およびモノリシックなドライバの場合のように、異なるバイナリフォーマットについて心配する必要がない。ＧＰＤパーサはそれでもなお他の欠点を有する。たとえば、Ａｔｔｒｉｂｕｔｅ：Ｖａｌｕｅペアの静的（非拡張可能）なセット、およびプリンタデバイスの特徴を記述するために使用できるこれらのペアの事前定義された集まり（コンストラクト）は、新しい機能がプリンタに追加されるとき、新しいＡｔｔｒｉｂｕｔｅ：Ｖａｌｕｅペアまたはコンストラクトを定義し、かつＧＰＤ言語に追加することを必要とし、それによりＧＰＤパーサへの変更がプログラムレベルで必要となる。
【０００６】
ＧＰＤコンストラクトの意味を記述するタスクは、意味の内容が、コンストラクトが生じるコンテキストに依存するという事実によって複雑になる。たとえば、ＰａｐｅｒＳｉｚｅ  ＊Ｆｅａｔｕｒｅ内に現れる＊Ｏｐｔｉｏｎｓコンストラクトは、Ｒｅｓｏｌｕｔｉｏｎ  ＊Ｆｅａｔｕｒｅ内に現れる＊Ｏｐｔｉｏｎｓコンストラクトとは異なるメンバ（ｍｅｍｂｅｒｓ）を有する。実際に、カスタムの用紙を記述する＊Ｏｐｔｉｏｎは、システム定義の用紙を記述する＊Ｏｐｔｉｏｎとは異なり、さらにレターサイズの用紙を記述する＊Ｏｐｔｉｏｎも、法定サイズの用紙を記述する＊Ｏｐｔｉｏｎとは異なる。これにより、通常の拡張マークアップ言語（ＸＭＬ）スキーマを使用する記述が不可能となる。ＸＭＬはメタマークアップ言語であり、幅広い種類のケースについてコンテンツ、意味およびスキーマを符号化することによって構造化データを記述するためのフォーマットを提供するものであるが、ＸＭＬでは、記述がベースの記述のプロパティおよび特徴を継承（ｉｎｈｅｒｉｔ）することができる能力および機能性が欠乏している。多数のネストされたＳｗｉｔｃｈ／Ｃａｓｅ依存性を含むテンプレート（ｔｅｍｐｌａｔｅ）を使用した記述は、よくても扱いにくいものである。テンプレートの間の関係を、継承のオブジェクト指向の概念を使用して定義するための方法は、より単純でよりロバストな言語機能を生じる。この概念は、Ｃ＋＋などのオブジェクト指向プログラミング言語において使用可能であるが、これらの言語における継承の適用はソースコードおよびメモリ空間を対象とし、それらに適用可能である。実際には、これらの環境における継承の目的および使用は、コードの多相性（２つ以上の類似のオブジェクトを、共通のインターフェイスを介して見るための能力であり、したがって、オブジェクトの間で区別する必要がない）および再利用可能性のための手段としてのものである。
【０００７】
データのグループを、ＸＭＬによって定義されたものとして容易に記述かつ類別化する概念には多数の利点があるが、継承の概念によって得られるロバスト性、能力および構造に欠けている。多数の個々のものは、ＸＭＬ記述または定義グループ化を、その下にあるグループ化を修正することなく容易に拡張あるいは増大させることができず、したがって、互換性の問題が、元のデータのグループ化を利用したいかなるアプリケーションまたはプログラムにも生じる。同様に、継承をＣ＋＋などのオブジェクト指向プログラム（ＯＯＰ）内で利用する能力には、ＸＭＬによって得られる使いやすさが欠けている。個々のものは、コードおよびメモリ区分の組合せなどの対象を強制的にＯＯＰで定義させられ、これにより対象の定義または記述における所望の簡易性が混乱させられる。
【０００８】
したがって、記述言語およびパーサを継続的に更新する一方で、対象データの記述または定義における柔軟性も提供するために必要とされたオーバーヘッドを回避するための必要性がある。サードパーティが望むいかなるＡｔｔｒｉｂｕｔｅ：Ｖａｌｕｅペアまたはコンストラクトをも追加することができ、かつ新しい属性を、言語またはパーサを修正する要件なしに、テンプレートを使用して記述することができるメタ言語が必要とされる。テンプレート継承の使用により、拡張されたデータフォーマットが、元のデータスキーマを取り扱うように設計されているいかなるアプリケーションおよびユーティリティとも互換性を保つことが保証される。さらに、強力で使いやすい汎用メタ言語の使用により、記述および定義を、プリンタ記述または特徴付け言語を超えた目的のために実施する能力が得られる。
【課題を解決するための手段】
【０００９】
一般的に述べると、任意のデータを記述するためにコンピュータシステム内で使用するための方法が提供される。本発明によれば、この方法は、本明細書で「構造化データの汎用オブジェクト指向記述」（ＧＤＬ）と称するメタ言語およびパーサを提供する。ＧＤＬにより、ユーザが実際のデータを表現し、テンプレートを作成することができ、これらが、各データ要素のための意味を定義し、ならびに各データ要素がより大きいデータフレームワークに適合する方法を定義するために使用される。テンプレートはソースファイルにおいて実施され、これが１つ以上の対象データを属性およびコンストラクトの形式において定義する。パーサはメタ言語を実施し、ＧＤＬファイルのコンテンツを解釈し、テンプレート内で提供された定義に基づいてエントリの構文を確認する。
【００１０】
ＧＤＬはいくつかの主な概念を導入し、これには、以前の対象に特有の定義の汎用拡張、テンプレートの使用および継承の概念が含まれる。ＧＤＬは、いかなるタイプのコンピュータ周辺デバイスの定義にも適用可能であり、有用である。テンプレートは、記述されたデバイスに関連付けられるデータのコンテキスト、ならびに関係のあるデータの汎用編成を提供する。継承は、多数のテンプレートの間の関係を定義すると同時に、小型の定義およびベースフレームワークの変形の作成も可能にする。継承はまた、サードパーティがデバイス定義を拡張かつ修正すると同時に、最初に定義された標準システムテンプレートになお準拠するための手段も提供する。デバイス定義用のスキーマを作成するためのＧＤＬの構造化方法はまた、テキストベースのファイル内で意味および定義情報の検証を容易にするための手段も提供する。
【００１１】
ＧＤＬパーサは、ＧＤＬパラダイムに関連付けられた利点の実現を支援するコンポーネントである。パーサは構文解析、データ格納ツリーの構築、テンプレートのフィルタリング、意味の確認およびシリアライズ化／デシリアライズ化（ｓｅｒｉａｌｉｚａｔｉｏｎ／ｄｅｓｅｒｉａｌｉｚａｔｉｏｎ）のサポートを提供する。構文解析は、ＧＤＬソースファイルの構造およびコンテンツを調査し、発見することからなる。ＧＤＬファイルにおけるあらゆるエントリが最終的には、データまたはテンプレートツリーにおける一意のノードによって表現される。パーサフィルタが生の値ストリングを他のデータタイプおよびデータ構造に変換し、これらをクライアントが利用して、解析ツリーの異なるビューを提示することができる。パーサフィルタにより、クライアントが、各ＧＤＬエントリについて定義されているテンプレート属性を決定し、したがって意味を検証することもできる。以前に述べたように、ＧＤＬソースファイルの解析結果は複雑なツリーである。このツリーはシリアライズされ、解析から得られた情報の内部表現が、それがソースファイルを再解析する必要なく検索（デシリアライズ）することができる方法で格納されることを意味する。ツリーにおけるノードの内部表現は動的に構成可能であり、すなわちこれを、必要に応じて修正、削除あるいは追加することができる。
【００１２】
追加の利点および新しい特徴について以下に続く説明で述べるが、部分的には、当業者には以下を調べれば明らかになり、あるいは本発明の実施によって知ることができる。
【発明の効果】
【００１３】
本発明により、コンピュータシステムにおいて対象に関係する任意のデータを記述し、得るために使用する方法が提供される。
【発明を実施するための最良の形態】
【００１４】
本発明を以下でより詳細に、添付の図面を参照して記載する。
【００１５】
本発明は、様々な対象に関連付けられた情報を、コンピュータシステムを利用して編成、定義かつ得るための方法および言語を提供する。例として、それだけに限定されるものではないが、対象データには、コンピュータデバイス、抽象的アイデア、音楽および他のこのような情報または概念が含まれる。図１は、本発明を実施することができる適切なコンピューティングシステム環境１００の一実施例を例示する。コンピューティングシステム環境１００は、適切なコンピューティング環境の一実施例でしかなく、本発明の使用または機能性の範囲についていかなる限定をも示唆するように意図されるものではない。また、コンピューティング環境１００は、例示的オペレーティング環境１００に例示したコンポーネントのいずれか１つまたはその組合せに関係するいかなる依存性または要件をも有するものとして解釈されるべきでもない。
【００１６】
本発明は、多数の他の汎用または専用コンピューティングシステム環境または構成により動作可能である。本発明による使用に適切な可能性のある周知のコンピューティングシステム、環境および／または構成の実施例には、それだけに限定されるものではないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラム可能な家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上のシステムまたはデバイスなどのいずれかを含む分散コンピューティング環境が含まれる。
【００１７】
図１を参照すると、本発明を実施するための例示的システムは、コンピュータ１１０の形式における汎用コンピューティングデバイスを含む。コンピュータ１１０のコンポーネントは、それだけに限定されるものではないが、処理装置１２０、システムメモリ１３０、および、システムメモリを含む様々なシステムコンポーネントを処理装置１２０に結合するシステムバス１２１を含む。システムバス１２１はいくつかのタイプのバス構造のいずれにすることもでき、これにはメモリバスまたはメモリコントローラ、周辺バス、および様々なバスアーキテクチャのいずれかを使用するローカルバスが含まれる。例として、それだけに限定されるものではないが、このようなアーキテクチャには、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、および、メザニンバスとしても知られる周辺装置相互接続（ＰＣＩ）バスが含まれる。
【００１８】
コンピュータ１１０は通常、様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０によってアクセスすることができるいかなる使用可能な媒体にすることもでき、これには、揮発性および不揮発性媒体、取外し可能および取外し不可能な媒体が含まれる。例として、それだけに限定されるものではないが、コンピュータ可読媒体は、コンピュータ記憶媒体を含むことができる。コンピュータ記憶媒体は、揮発性および不揮発性媒体、取外し可能および取外し不可能な媒体を含み、これらはコンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータなど、情報を格納するためのいずれかの方法または技術において実施される。コンピュータ記憶媒体には、それだけに限定されるものではないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、または、所望の情報を格納するために使用することができ、かつコンピュータ１１０によってアクセスすることができる他のいかなる媒体もが含まれる。
【００１９】
システムメモリ１３０はコンピュータ可読媒体を含み、これは読取り専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性および／または不揮発性メモリの形式におけるものである。基本入出力システム１３３（ＢＩＯＳ）は、起動中など、情報をコンピュータ１１０内の要素の間で転送するための助けとなる基本ルーチンを含み、通常はＲＯＭ１３１に格納される。ＲＡＭ１３２は通常、データおよび／またはプログラムモジュールを含み、これらは処理装置１２０によって直接アクセス可能であり、かつ／またはほどなく動作される。例として、それだけに限定されるものではないが、図１はオペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６およびプログラムデータ１３７を例示する。
【００２０】
コンピュータ１１０はまた、他の取外し可能／取外し不可能、揮発性／不揮発性のコンピュータ記憶媒体も含むことができる。例としてのみ、図１は、取外し不可能、不揮発性の磁気媒体から読み取りあるいはこれに書き込むハードディスクドライブ１４１、取外し可能、不揮発性磁気ディスク１５２から読み取りあるいはこれに書き込む磁気ディスクドライブ１５１、および、ＣＤ−ＲＯＭまたは他の光媒体など、取外し可能、不揮発性光ディスク１５６から読み取りあるいはこれに書き込む光ディスクドライブ１５５を例示する。例示的オペレーティング環境において使用することができる、他の取外し可能／取外し不可能、揮発性／不揮発性のコンピュータ記憶媒体には、それだけに限定されるものではないが、磁気テープカセット、フラッシュメモリカード、デジタルビデオディスク、デジタルビデオテープ、ベルヌーイカートリッジ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどが含まれる。ハードディスクドライブ１４１は通常システムバス１２１へ、インターフェイス１４０などの取外し不可能メモリインターフェイスを介して接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は通常システムバス１２１へ、インターフェイス１５０などの取外し可能メモリインターフェイスによって接続される。
【００２１】
上述かつ図１において例示したドライブおよびそれらの関連付けられたコンピュータ記憶媒体が、コンピュータ１１０用の、コンピュータ可読命令、データ構造、プログラムモジュールおよび他のデータの記憶装置を提供する。図１では、たとえば、ハードディスクドライブ１４１が、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６およびプログラムデータ１４７を格納するものとして例示される。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６およびプログラムデータ１３７と同じものにも異なるものにもすることができる。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６およびプログラムデータ１４７には異なる番号が与えられて、最低でも、それらが異なるコピーであることが例示される。ユーザが、コマンドおよび情報をコンピュータ１１０へ、キーボード１６２およびポインティングデバイス１６１などの入力デバイスを介して入力することができ、これらは一般に、マウス、トラックボールまたはタッチパッドと呼ばれる。他の入力デバイス（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどが含まれる可能性がある。これらおよび他の入力デバイスがしばしば処理装置１２０へ、システムバスに結合されるユーザ入力インターフェイス１６０を介して接続されるが、これを、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）など、他のインターフェイスおよびバス構造によって接続することができる。モニタ１９１または他のタイプの表示デバイスもシステムバス１２１へ、ビデオインターフェイス１９０などのインターフェイスを介して接続される。モニタ１９１に加えて、コンピュータは、スピーカ１９７およびプリンタ１９６など、出力周辺インターフェイス１９５を介して接続することができる他の周辺出力デバイスも含むことができる。
【００２２】
コンピュータ１１０はネットワーク環境において、リモートコンピュータ１８０など、１つ以上のリモートコンピュータへの論理接続を使用して動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたは他の共通ネットワークノードにすることができ、通常は、コンピュータ１１０に関連して上に記載した要素の多数またはすべてを含むが、メモリデバイス１８１のみを図１に例示した。図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３を含むが、他のネットワークも含むことができる。このようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネットおよびインターネットにおいて一般的である。
【００２３】
ＬＡＮネットワーキング環境において使用するとき、コンピュータ１１０がＬＡＮ１７１へ、ネットワークインターフェイスまたはアダプタ１７０を介して接続される。ＷＡＮネットワーキング環境において使用するとき、コンピュータ１１０は通常、モデム１７２、またはインターネットなど、ＷＡＮ１７３を介して通信を確立するための他の手段を含む。モデム１７２を内部あるいは外部にすることができ、システムバス１２１へ、ネットワークインターフェイス１７０または他の適切なメカニズムを介して接続することができる。ネットワーク環境では、コンピュータ１１０に関して示したプログラムモジュール、またはその一部を、リモートメモリ記憶デバイスに格納することができる。例として、それだけに限定されるものではないが、図１はリモートアプリケーションプログラム１８５を、メモリデバイス１８１上に存在するものとして例示する。図示のネットワーク接続は例示的であり、通信リンクをコンピュータの間で確立する他の手段を使用できることは理解されよう。
【００２４】
コンピュータ１１０の多数の他の内部コンポーネントは図示しないが、このようなコンポーネントおよび相互接続が周知であることは、当業者には理解されよう。したがって、コンピュータ１１０の内部構造に関する追加の詳細を、本発明に関連して開示する必要はない。
【００２５】
コンピュータ１１０がオンにされるかあるいはリセットされたとき、ＲＯＭ１３１に格納されているＢＩＯＳ１３３が処理装置１２０に、オペレーティングシステムをハードディスクドライブ１４１からＲＡＭ１３２にロードするように命令する。オペレーティングシステム１３４がＲＡＭ１３２にロードされた後、処理装置１２０がオペレーティングシステムコードを実行し、オペレーティングシステム１３４のユーザインターフェイスに関連付けられた視覚的要素をモニタ１９１上に表示させる。アプリケーションプログラム１３５がユーザによって開かれたとき、プログラムコードおよび関連データがハードディスクドライブ１４１から読み込まれ、ＲＡＭ１３２に格納される。
【００２６】
本発明の方法およびシステムにより、対象に関係する情報の定義、スクリプティングおよび解析が可能となる。この方法およびシステムを、「ＭＩＣＲＯＳＯＦＴ  ＣＯＲＰＯＲＡＴＩＯＮ」による「ＷＩＮＤＯＷＳ（登録商標）」グラフィカルオペレーティングシステムにおいて実施されるものとして記載するが、この方法およびシステムを、サードパーティによって製造あるいは実施される多数の周辺デバイスをサポートするいかなるシステムにおいても使用できることは、当業者には理解されよう。加えて、本発明の方法はある構文−ＧＤＬにより実施されるものとして記載されるが、これは例示のために行われており、本明細書で提供された構文が例示的であることに留意されたい。他のメタ言語構文の使用は、本発明の範囲内である。
【００２７】
一般に、ＧＤＬデータはＡｔｔｒｉｂｕｔｅ（属性）：Ｖａｌｕｅ（値）エントリのセットである。エントリのセットは、０、１つ以上のエントリを指す。このようなエントリの集まりがコンストラクトと呼ばれる。コンストラクトの本体を形成する各エントリは、コンストラクトメンバと呼ばれる。各属性がパラメータ、およびそのパラメータに割り当てられる値を命名する。ＧＤＬでは、すべての属性名がアスタリスクで始まり、たとえば、＊ＯｄｏｍｅｔｅｒＲｅａｄｉｎｇ：２８１９５が、ＧＤＬにおけるＡｔｔｒｉｂｕｔｅ：Ｖａｌｕｅエントリとなる。コンストラクトにより、関係するエントリを論理データセットにグループ化することができる。たとえば、車を記述するデータのセットを有する場合、これを以下のように編成することができる。
*Vehicle: Dodge_Minivan
{
*Make: Dodge
*Model: Caravan
*Year: 1998
*OdometerReading: 28195
*LicensePlate: XQM 498
}
【００２８】
この実施例では、Ｖｅｈｉｃｌｅがコンストラクトタイプであり、これがいくつかの属性、すなわちＭｏｄｅｌ、Ｍａｋｅ、Ｙｅａｒ、ＯｄｏｍｅｔｅｒＲｅａｄｉｎｇおよびＬｉｃｅｎｓｅＰｌａｔｅを共にグループ化する。
【００２９】
図３は、本発明の実施の概観を、含まれるコンポーネントステップ３００〜３１０に関して例示する。一般に、本発明の実施は最初に、ＧＤＬテンプレートおよび他のデータエントリを含むテキストファイル３００を作成することを必要とする。ＧＤＬパーサは、ファイルおよび様々なエントリを読み込み、ならびにデータツリーを提供するプロセス、ブランチを列挙する方法、ツリーナビゲーション、Ｓｗｉｔｃｈ／Ｃａｓｅ処理およびデータアクセスを実行する。解析はステップ３０２で開始する。次いで、ステップ３０４で、パーサが内部表現（「ツリー」）を生成し、これはテキストファイルから得られるデータのものである。ステップ３０６で、パーサインターフェイス関数のセットｆ（１）ないしｆ（ｎ）が、内部表現されたテンプレートおよびデータへのアクセスを提供する。ステップ３０８で、クライアントアプリケーション、またはＧＤＬデータのコンシューマである他のプログラムに固有のフィルタが検証、競合の解消、および、パーサの範囲を超える他のタイプの特定のデータ操作または変換を実行する。最後にステップ３１０で、データを消費するアプリケーションおよび／またはプログラムが情報を得ることができる。前述の各ステップおよび手順の特定の詳細は以下の通りである。
【００３０】
ＧＤＬテキストファイルは、ＧＤＬ仕様の仕様に準拠しなければならない。ファイルはテンプレートおよび非テンプレートエントリからなり、その両方が有効なＧＤＬ構文に準拠する。非テンプレートエントリが使用されて有効なツリーが構築され、これがすべての属性およびコンストラクト、およびそれらの関連付けられた値を保持する。テンプレートエントリが使用されて別のツリーが作成され、これが有効なツリーにリンクされる。ＧＤＬファイルは、エントリのシーケンスとして見なすことができる。各エントリはキーワード：値ペアであり、コロンによって分離され、論理改行によって終了される。ＧＤＬの仕様は、言語に肝要なフィーチャの特定の参照および考察によって最適に説明される。これらのフィーチャは、テンプレート、テンプレート継承およびＧＤＬパーサの概念を含む。パーサを使用して言語の構文を、ＧＤＬデータがクライアントプログラムおよびアプリケーションにアクセス可能にされる方法と共に説明し、指定する。
【００３１】
テンプレートはデータのためのコンテキストを提供する。テンプレートは、ＧＤＬファイルが従うべきである意味ルールのセットを指定する、純粋にデータドリブンの方法である。たとえば、＊Ｎａｍｅキーワードはあるオブジェクトのための名前を定義し、次いで問題は、名前が人を指すか、惑星を指すか、プリンタを指すか、フィーチャを指すかオプションを指すかである。さらに、十分に形成された名前にいずれかの制約があるかどうかの問題がある。これおよび他の類似の問題が、テンプレートによって解決される。＊Ｔｅｍｐｌａｔｅコンストラクトおよびパーサが認識したテンプレートメンバエントリである＊Ｎａｍｅ、＊Ｉｎｈｅｒｉｔｓ、＊Ｍｅｍｂｅｒｓ、＊Ｔｙｐｅ、＊Ｉｎｓｔａｎｃｅｓ、＊Ｖｉｒｔｕａｌ、＊ＡｌｌｏｗＮｅｗＭｅｍｂｅｒｓおよび＊ＮｅｗＭｅｍｂｅｒＯｆにより、ＧＤＬテンプレートライタがテンプレートのツリーを定義することができ、これはパーサによって使用されて、特定のテンプレートが構築され、編成され、ユーザ定義の各属性およびコンストラクトに関連付けられる。＊Ｔｅｍｐｌａｔｅコンストラクトは１つのＧＤＬエントリのためのプロパティ、すなわち属性またはコンストラクトを定義する。コンストラクトのメンバにそれら自体の別々のテンプレートが与えられる。ＧＤＬパーサによって提供されたテンプレートのサポートは、グローバルな規模の編成をＧＤＬのデータに課す。テンプレートをＧＤＬファイルにおける各データエントリに関連付けることは、有効にテンプレート継承を利用するために必須である。あらゆるデータエントリがルートレベルで、あるいは親コンストラクトのメンバとして存在する。それがルートレベルで存在した場合、ＲＯＯＴテンプレートによって定義されたＭｅｍｂｅｒｓリストが、エントリに関連付けられるのに適切である第１のテンプレートについて探索される。データエントリがコンストラクトのメンバであった場合、親コンストラクトに関連付けられるテンプレートのＭｅｍｂｅｒｓリストが使用される。ＭｅｍｂｅｒｓリストおよびＧＤＬファイルエントリは、もっとも最近追加された要素から開始して探索される。Ｍｅｍｂｅｒｓリストが空になったとき、Ｍｅｍｂｅｒｓリストを含むテンプレートが派生されていた場合、もっともベースのテンプレートのＭｅｍｂｅｒｓリストが探索されるまで、探索が直接ベーステンプレートのＭｅｍｂｅｒｓリストに進む。探索は、データエントリを表すのに適切であるテンプレートが発見されたとき、終了する。このように、等しいテンプレート名の後続の使用は、異なるスキーマを、ＧＤＬファイル内の異なる位置において定義された他の変数以外の特定の変数に関連付けさせることができる。リストの最後に達したときに適切であるテンプレートが見つからなかった場合、データエントリはテンプレート関連付けなしに残され、これらを未識別エントリと称することができる。
【００３２】
よりローカルな意味コンテンツはフィルタに委ねられる。フィルタが使用されて、コンストラクトおよび属性プロパティを記述するテンプレートキーワードおよびエントリが、指定かつ／または定義される。たとえば、フィルタを使用して、属性の＊ＤａｔａＴｙｐｅを定義するか、あるいは、コンストラクトの特定のメンバが必要とされるかオプショナルであるかを記述することができる。テンプレートはそれ自体がＧＤＬ構文に書き込まれるので、ＧＤＬエントリの自己拡張可能性に関する前述のすべてがテンプレートエントリに適用されることに留意されたい。テンプレートの間の関係をよりよく定義するため、オブジェクト指向継承の概念がＧＤＬにおいて実施される。
【００３３】
テンプレート継承は小型の定義を作成し、基本タイプの変形を簡潔な方式で表し、かつデータのマニフェスト、構造および編成を作成する必要性に対処する。より重要なこととして、継承の概念により、エンドユーザがベースフレームワークを、ベースフレームワークを変更あるいは再定義する必要なく、拡張かつ構築することができる。継承はそれ自体を完全に、今日現在使用されているすべてのコンストラクトおよび属性を定義する標準テンプレートファイルをオペレーティングシステムが供給する環境に導くが、なお、ＯＥＭは継承を介して標準テンプレートを拡張して新しいメンバを定義するか、あるいは特殊なケースを作成することができる。テンプレートの継承はまた強制的に、テンプレートライタに自分が記述しようと試みているデータの構造を理解させる。たとえば、すべてのＦｅａｔｕｒｅコンストラクトはいくつかの共通のプロパティを共有する。これらのプロパティは、ベースのＦｅａｔｕｒｅテンプレートによって定義されることがもっとも適切である。次いで、特殊なＦｅａｔｕｒｅをベーステンプレートから派生することができ、これがフィーチャに特殊なプロパティまたは制限を追加する。各テンプレートをベースのＦｅａｔｕｒｅテンプレートから派生することにより、すべての派生テンプレートがすべてのＦｅａｔｕｒｅに共通のすべての必須のプロパティを継承することを保証する。常に「どのプロパティを特定のテンプレートが定義するべきであるか、どれを派生テンプレートに委ねるべきであるか」を尋ねることによって、設計者はデータの編成および構造、およびデータの間の関係に焦点を置く。
【００３４】
図４は、ＧＤＬパーサによって作成されたテンプレート継承ツリーの簡素化された図である。直線は、ベーステンプレートを下の派生テンプレートに接続する。曲線は、左側のコンストラクトテンプレートを右側のそのメンバに接続する。各メンバテンプレートはそれ自体を別のテンプレートのためのベーステンプレートから派生するか、あるいはそれになることができ、各メンバテンプレートを、他のメンバを参照するコンストラクトにすることもできることに留意されたい。各オプションテンプレートは、それらの各フィーチャテンプレートのメンバである。
【００３５】
テンプレートの概念は、テンプレートの動作方法を考察することによって最適に理解される。図４は、テンプレートおよびテンプレート継承ツリーの簡素化された図を示す。この表現において使用されている特定のキーワードのいくつかの考察は、本明細書の後のパーサについてのセクションで見ることができる。図のように、図における直線４５０、４５１および４５９は、ベーステンプレートから派生テンプレートへの接続を示す。曲線４５２〜４５８は、コンストラクトテンプレートからそのメンバへの接続を示す。以下は、プリンタおよびいくつかのプリンタのフィーチャを記述するソースファイルのコンテンツの一実施例である。いくつかのテンプレートの関係も、図４で図によって提供する。
【００３６】
*Template: NAME
{
*Name: "*Name"
*Type: ATTRIBUTE
*ValueType: QUOTEDSTRING
}
*Template: OPTIONID
{
*Name: "*OptionID"
*Type: ATTRIBUTE
*ValueType: INTEGER
}
*Template: OPTION
{
*Name: "*Option"
*Type: CONSTRUCT
*Virtual: TRUE
*Members: ( NAME , OPTIONID , OPTIONSELECTCOMMAND ,
RCICONID, RCHELPID, RCNAMEID)
}
*Template: GENERIC_OPTION
{
*Inherits: OPTION
*Instances: <ANY>
}
*Template: PAPERSIZE_NAME
{
*Inherits: NAME
*Name: "*Name"
*MaxCharLength: 24
}
*Template: INPUTBIN_NAME
{
*Inherits: NAME
*Name: "*Name"
*MaxCharLength: 16
}
*Template: PAPER_OPTION
{
*Inherits: OPTION
*Members: ( CURSORORIGIN, PAPERSIZE_NAME)
*Instances: <ANY>
*Virtual: TRUE
}
*Template: STANDARD_PAPER_OPTION
{
*Inherits: PAPER_OPTION
*Members: (PRINTABLEAREA, PRINTABLEORIGIN,)
*Instances: <ANY>
*Virtual: TRUE
}
*Template: LETTER_PAPER_OPTION
{
*Inherits: STANDARD_PAPER_OPTION
*Instances: LETTER
*Virtual: FALSE
*AllowNewMembers: TRUE
*RequiredInitializations:    *% specific initializations for
Letter Size
{
*OptionID: 1
}
}
*Template: LEGAL_PAPER_OPTION
{
*Inherits: STANDARD_PAPER_OPTION
*Instances: LEGAL
*Virtual: FALSE
*RequiredInitializations:    *% specific initializations for Legal
Size
{
*OptionID: 2
}
}
*Template: MEDIATYPE_OPTION
{
*Inherits: OPTION
*%Members: NONE
*Instances: <ANY>
*Virtual: FALSE
}
*Template: FEEDMARGINS
{
*Name: "*FeedMargins"
*Inherits: POINTVALUE
}
*Template: INPUTBIN_OPTION
{
*Inherits: OPTION
*Members: (FEEDMARGINS, PAPERFEED, INPUTBIN_NAME)
*Virtual: TRUE
}
【００３７】
図４を参照すると、第１のテンプレート４００は「オプション」という名前を有し、これはすなわちＮＡＭＥおよびＯＰＴＩＯＮＩＤという２つのメンバを有し、これはコンストラクトタイプのテンプレートである。オプション４００のメンバは、それ自体をテンプレート４０１、４０２によって記述することができる属性である。したがって、この実施例では、ＮＡＭＥ４０１およびＯＰＴＩＯＮＩＤ４０２は属性タイプのテンプレートであり、これらはさらに元のテンプレートＯＰＴＩＯＮ４００を定義する。ＩＮＰＵＴＢＩＮ＿ＯＰＴＩＯＮ４１０およびＰＡＰＥＲ＿ＯＰＴＩＯＮ４２０は、ＯＰＴＩＯＮ４００から派生されるテンプレートであり、したがってＯＰＴＩＯＮ４００の属性を継承する。さらに、テンプレートＩＮＰＵＴＢＩＮ＿ＯＰＴＩＯＮ４１０はそれ自体の属性も有し、これはそのメンバＦＥＥＤＭＡＲＧＩＮＳおよびＩＮＰＵＴＢＩＮ＿ＮＡＭＥによって定義されたものである。これらのメンバもテンプレート４１１、４１２によって記述される。
【００３８】
ＩＮＰＵＴＢＩＮ＿ＮＡＭＥ４１２などのメンバテンプレートは、ＮＡＭＥ４０１などの先のテンプレートからも派生することができ、すなわち、ＩＮＰＵＴＢＩＮ＿ＮＡＭＥ４１２は、ＮＡＭＥ４０１が含むあらゆるものを含むようになる。同じ解釈は、メンバテンプレートＰＡＰＥＲＳＩＺＥ＿ＮＡＭＥ４２２に適用可能となる。このネスティングを様々なレベルに伝えることができ、たとえば、ＩＮＰＵＴＢＩＮ＿ＯＰＴＩＯＮ４１０およびＰＡＰＥＲ＿ＯＰＴＩＯＮ４２０はＯＰＴＩＯＮ４００から派生され、それぞれがそれ自体の属性、すなわちＦＥＥＤＭＡＲＧＩＮＳ４１１およびＣＵＲＳＯＲＯＲＩＧＩＮ４２１も有することができる。テンプレートは、先に派生されたテンプレートからも派生することができ、たとえば、ＳＴＡＮＤＡＲＤ＿ＰＡＰＥＲ＿ＯＰＴＩＯＮ４３０がＰＡＰＥＲ＿ＯＰＴＩＯＮ４２０から派生され、これはＯＰＴＩＯＮ４００から派生されたものである。この場合、ＳＴＡＮＤＡＲＤ＿ＰＡＰＥＲ＿ＯＰＴＩＯＮ４３０は、ＰＡＰＥＲ＿ＯＰＴＩＯＮ４２０の属性、すなわちＣＵＲＳＯＲＯＲＩＧＩＮ４２１およびＰＡＰＥＲＳＩＺＥ＿ＮＡＭＥ４２２を継承するだけでなく、ＯＰＴＩＯＮ４００の属性、すなわちＮＡＭＥ４０１およびＯＰＴＩＯＮＩＤ４０２も継承する。
【００３９】
図４においてＰｒｉｎｔａｂｌｅＡｒｅａ４３１に関係する表現の解釈を、以下のように述べることができる。ＰｒｉｎｔａｂｌｅＡｒｅａ４３１はＳｔａｎｄａｒｄ＿Ｐａｐｅｒ＿Ｏｐｔｉｏｎ４３０の属性であり、これは使用可能なＰａｐｅｒ＿Ｏｐｔｉｏｎｓ４２０の変形であり、これは使用可能なＯｐｔｉｏｎｓ４００の変形である。これまで論じてきたこの表現は、ＧＤＬテキストファイルを解釈するパーサからの結果の一実施形態である。
【００４０】
パーサは、ＧＤＬファイルにおけるあらゆるデータ（非テンプレート）エントリをテンプレートに関連付ける。エントリがコンストラクトであった場合、テンプレートはそのコンストラクト内に現れる可能性のあるすべてのメンバを指定する。この関連付けは再帰的に適用され、あらゆるエントリをテンプレート化することができる。テンプレートのキーワードおよび関連付けの考察によりこの動作方法を例示する。
【００４１】
＊Ｔｅｍｐｌａｔｅ：ＳＹＭＢＯＬ−これはテンプレートコンストラクトを導入する。シンボル値はテンプレートの名前である。テンプレートはＲＯＯＴレベルでのみ現れることができる。テンプレートを再定義することはできない。これにより、継承を、記述の修正および拡張メカニズムとして使用することが助長される。以下に記載する残りのキーワードは、テンプレートコンストラクトの本体内で生じる。加えて、ＧＤＬテンプレートライタは、テンプレートの本体に、自分自身が作成した他のキーワードを挿入することができ、これに自分自身のフィルタによってアクセスすることができる。
【００４２】
＊Ｎａｍｅ：ＱＵＯＴＥＤ  ＳＴＲＩＮＧ−このエントリは、テンプレートに関連付けることができるキーワードを定義する。引用符付きストリングの値は、＊ＴｅｍｐｌａｔｅコンストラクトのＳＹＭＢＯＬ値との関係を有する必要がない。多数の異なるテンプレートが同じ＊Ｎａｍｅを有することができ、この問題を後に、パーサが各データエントリに関連付けるための正しいテンプレートを発見する方法に関するセクションで論ずる。＊Ｎａｍｅエントリはいかなる派生テンプレートにおいても再定義することができるが、そのようにすることで、ベース継承ツリーからの派生テンプレートおよびその子孫が排除される。すなわち、＊Ｎａｍｅを派生テンプレートにおいて再定義することにより、ベーステンプレートが派生テンプレートに、ベーステンプレートから派生されるものとしてレポートしないようにさせる。
【００４３】
＊Ｉｎｈｅｒｉｔｓ：ＳＹＭＢＯＬ−これにより、現在のテンプレートに、ＳＹＭＢＯＬによって命名されたベーステンプレートの継承プロパティを継承させる。現在は単一の継承のみがサポートされている。ベーステンプレートは先に定義されていなければならない。ベーステンプレートは派生テンプレートを、＊Ｎａｍｅが再定義されない限り、その継承ツリーの一部として登録する。
【００４４】
＊Ｍｅｍｂｅｒｓ：ＳＹＭＢＯＬのリスト（付加的に継承される）−すでにこのテンプレートに関連付けられているコンストラクトに属するいずれかのデータエントリとの関連付けのために考察される候補のテンプレートのリストを指定する。リストで命名されたもっとも右のテンプレートが最初に考察される。テンプレートエントリ＊ＮｅｗＭｅｍｂｅｒＯｆ：を使用して、テンプレートが定義された後にメンバをこのリストに追加することができる。このようなテンプレートは、＊Ｍｅｍｂｅｒｓリストで明示的に命名されたものの前に探索される。
【００４５】
＊Ｔｙｐｅ：ＥＮＵＭＥＲＡＴＯＲ（継承されるが、再定義は許可されない）−このテンプレートによって記述されているデータエントリまたはオブジェクトのタイプを指定する。パーサは列挙子の値｛ＣＯＮＳＴＲＵＣＴ，ＡＴＴＲＩＢＵＴＥ，ＶＡＬＵＥ｝を認識するが、いかなる列挙値も指定することができる。＊Ｔｙｐｅ＝ＣＯＮＳＴＲＵＣＴまたはＡＴＴＲＩＢＵＴＥを有するテンプレートのみが、＊Ｍｅｍｂｅｒｓリストに現れることができる。これは、すべての非派生テンプレートのために必要とされたキーワードである。Ｔｙｐｅ＝ＣＯＮＳＴＲＵＣＴの＊Ｔｅｍｐｌａｔｅは最終的には次のエントリを含まなければならない。すなわち、＊Ｎａｍｅ、＊Ｍｅｍｂｅｒｓおよび＊Ｉｎｓｔａｎｃｅｓである。Ｔｙｐｅ＝ＡＴＴＲＩＢＵＴＥの＊Ｔｅｍｐｌａｔｅは、＊Ｎａｍｅのみを定義する必要がある。パーサは他のテンプレートタイプにいかなるルールも課さない。他のタイプは、フィルタによって使用するために意図される。
【００４６】
＊Ｉｎｓｔａｎｃｅｓ：ＳＹＭＢＯＬのリスト（継承されない）−ＩｎｓｔａｎｃｅＮａｍｅ  ＳＹＭＢＯＬのリストを指定する。このエントリは、所与のコンストラクトのどのインスタンス（ｉｎｓｔａｎｃｅｓ）がこのテンプレートによって合致されるかを指定する。特殊な名前＜ＡＮＹ＞はすべてのインスタンス名に合致する。テンプレートがデータコンストラクトエントリに合致するようにするため、あらゆる継承されたテンプレートの＊Ｉｎｓｔａｎｃｅｓ属性も合致しなければならない。
【００４７】
＊Ｖｉｒｔｕａｌ：ＢＯＯＬ（デフォルトはＦＡＬＳＥ、継承されない）−このエントリのＢＯＯＬ値がＴＲＵＥである場合、パーサは、テンプレートが＊Ｎａｍｅ、＊Ｉｎｓｔａｎｃｅｓまたは＊Ｍｅｍｂｅｒｓを定義することを必要としない。これにより、このテンプレートが、継承を介して多数の異なるキーワードおよびインスタンスに適用することができる共通のプロパティのセットを定義することができる。派生テンプレートは、＊Ｎａｍｅ、＊Ｉｎｓｔａｎｃｅおよび＊Ｍｅｍｂｅｒｓを定義することができる。テンプレートは、＊Ｖｉｒｔｕａｌがいかなるデータエントリにも関連付けられないことを宣言する。Ｖｉｒｔｕａｌテンプレートがこれらのキーワードのいずれかまたはすべてを定義するように選択できることに留意されたい。設計者が共通プロパティを指定するために使用しようと意図するが、データエントリを完全に定義するために十分に完全ではないいかなるテンプレートも、Ｖｉｒｔｕａｌに指定することができる。
【００４８】
＊ＮｅｗＭｅｍｂｅｒＯｆ；ＳＹＭＢＯＬのリスト（継承されない）−テンプレート名のリストを指定する。これは現行のテンプレートを、その中で命名されたコンストラクトテンプレートのＭｅｍｂｅｒｓリストに追加する。命名されたテンプレートは、Ｔｙｐｅ＝ＣＯＮＳＴＲＵＣＴとして宣言されなければならず、＊ＡｌｌｏｗＮｅｗＭｅｍｂｅｒｓ：ＴＲＵＥを有していなければならない。
【００４９】
＊ＡｌｌｏｗＮｅｗＭｅｍｂｅｒｓ：ＢＯＯＬ（デフォルト値：ＦＡＬＳＥ、継承されない）−このテンプレートがその＊Ｍｅｍｂｅｒｓ：リストへのすべての後続の追加を、＊ＮｅｗＭｅｍｂｅｒＯｆエントリの使用を介して可能にするべきであるかどうかを指定する。
【００５０】
上述のキーワードの使用をよりよく例示するため、以下はサンプルのＧＤＬファイルエントリであり、ここでは属性＊Ｃｏｓｔ：をテンプレートによって記述することができる。
*Template: COST
{
*Type: ATTRIBUTE
*Name: "*Cost"
*ValueType: CURRENCY
}
このテンプレートは、例えば別のテンプレートで参照できる:
*Template: SERVICE_RECORD
{
*Name: "*Service "
*Type: CONSTRUCT
*Members: (COST, DATE, DETAILS)
*Instances: (OilChange, Repair, Overhaul, Bodywork)
}
【００５１】
ＳＥＲＶＩＣＥ＿ＲＥＣＯＲＤテンプレートは、テンプレートＣＯＳＴ、ＤＡＴＥまたはＤＥＴＡＩＬＳによって提供された定義に適合するメンバを含むことができるコンストラクトを定義する。次には、ＳＥＲＶＩＣＥ＿ＲＥＣＯＲＤテンプレートをＭＡＩＮＴＥＮＡＮＣＥ＿ＨＩＳＴＯＲＹテンプレートで参照することができる。
【００５２】
パーサはルートコンテキストに、ＲＯＯＴと命名されたテンプレートを関連付ける。ＲＯＯＴと命名されたテンプレートは常にＧＤＬファイル内で定義しなければならない。ルートレベルのすべてのデータエントリは、ＲＯＯＴテンプレートの＊Ｍｅｍｂｅｒｓリストで命名されたテンプレートに関連付けられるべきである。同じプロセスがコンストラクトに適用される。テンプレートライタは、各データコンストラクトに現れる各データエントリに関連付けられたテンプレートがあるようにし、このような各テンプレートが、データのコンストラクトに関連付けられたテンプレートの＊Ｍｅｍｂｅｒｓリストで命名されるようにするべきである。ここで論じたキーワードおよびテンプレートに加えて、ＧＤＬは、テキストベースのファイルにおいて行われるエントリの適切な表現および解釈を可能にする構文も含む。
【００５３】
何が有効なＧＤＬエントリを構成するかをより十分に説明するために、「解析コンテキスト」の概念を最初に説明しなければならない。パーサについて提供する情報および説明は例示的なものであり、スキーマに基づいた本発明の継承の概念の理解を容易にするために使用されることに留意されたい。解析コンテキストは、解析プロセスにおいて、テキストベースのファイルにおけるある行エントリが処理あるいは解釈されるべき方法を決定する段階である。すなわち、特定の文字は、このような文字に出会うときに現行のものであるコンテキストに応じて意味を有するか、有さない可能性がある。先に述べたように、ＧＤＬパーサはステートマシンであり、解析エンジンの状態は解析コンテキストに対応する。各コンテキストにおいて、すべての入力文字が３タイプの１つに分類される。
【００５４】
ニュートラル文字−コンテキスト変更を引き起こさない文字、
不正文字−このコンテキストにおいて許可されていない文字、
アクティブ文字−コンテキスト変更を引き起こす文字。
【００５５】
示したように、いくつかの文字は、あるコンテキスト内でのみ意味がある。すべてのコンテキストにおいて意味があるが、特定のコンテキストに応じて異なるように解釈されるいくつかの文字もある。たとえば、大抵のコンテキストは「論理余白」を認識し、これは「スペース」および「タブ」文字、「Ｃｔｒｌ−Ｚ」文字、「コメント」および「継続改行」からなる。「コメント」は２つの文字「＊％」で開始し、改行（「＼ｎ」または「＼ｒ」）文字に出会うときに終了する。余白または改行文字は「＊％」に先行しなければならない。いかなる文字も「コメント」内に現れることができる。「継続改行」は、直後に「プラス」の「＋」文字が続くことによってエスケープされる改行文字の組合せであり、情報が次の行に継続することを示す。逆に、値コンテキストの外側では、「論理空白」は通常、プロセスにおいて解析されているいかなるキーワードまたはトークンも終了させるが、そうでない場合は無視される。値コンテキスト内では、いかなる量の連続する「論理空白」も、ネイティブのＧＤＬパーサインターフェイスによって返される値ストリングにおいて現れる１つの「空白」文字となる。「論理改行」は通常エントリを終了させる。他のコンテキストは「論理改行」を「論理空白」として処理する。「論理改行」は、「＼ｎ」および「＼ｒ」、および組合せの「＼ｎ＼ｒ」および「＼ｒ＼ｎ」からなる。加えて、中括弧文字「｛」および「｝」は、「コンストラクトデリミタ」としてのそれらのロールに加えて、エントリターミネータとしても動作する。「継続改行」は「論理改行」とは見なされない。
【００５６】
「コンストラクトデリミタ」は、「現行の親」として指定されるノードを変更する。現行の親は、ツリーにおける表現である。ツリーはパーサによって、ＧＤＬテキストベースのファイルにおけるあるエントリの表現として作成される。このツリーに関連付けられるものは明確な起点であり、これを「ルート」と称する。ツリーは個々のノードからなり、これらがすべて共にリンクされる。「ルート」を除くあらゆるノードは親ノードを有する。各ノードはゼロ、１つ以上の子ノードを有することができる。親ノードはＧＤＬソースファイルにおけるコンストラクトエントリに対応する。その子ノードは、そのコンストラクトエントリのメンバに対応する。ＧＤＬソースファイルにおける各エントリが解析されるにつれて、ノードが解析ツリーに追加される。新しいノードは、パーサが「現行の親」として指定するノードの子ノードとして追加される。最初に、「現行の親」が「ルート」に設定される。「閉中括弧」文字「｝」は「現行の親」の親を新しい「現行の親」にする。「開中括弧」文字「｛」は、「現行の親」のもっとも最近作成された子を新しい「現行の親」にする。ＧＤＬパーサが「現行の親」を「ルート」の親に移動しようと試みた場合、あるいは、「現行の親」に、存在しない子ノードをポイントさせようと試みた場合、致命的な構文エラーとなる。他のノードの親であるノードは「コンストラクト」に対応するが、親ではないノードは「属性」に対応する。
【００５７】
「開中括弧」文字の直前にあるＧＤＬエントリは「コンストラクトエントリ」と呼ばれる。「コンストラクトエントリ」に与えられたキーワード名は「コンストラクトタイプ」と呼ばれるが、シンボル値は「コンストラクトインスタンス」として知られる。「シンボル値」トークンは、「英数字」および「アンダースコア」文字からなるものでなければならない。
【００５８】
「Ｎｅｗｅｎｔｒｙコンテキスト」は、いずれかの文字がＧＤＬファイルから読み込まれる前の最初の解析コンテキストである。このコンテキストでは、最初の「キーワード」トークンが予想される。いかなる量の「論理空白」も「キーワード」の前に現れることができ、無視される。「キーワード」を、ダブルコロン「：：」またはトークン「ＥＸＴＥＲＮ＿ＧＬＯＢＡＬ」の前に置いて、キーワードが実際には現在のコンストラクトではなく「ルート」のメンバであることを示すことができる。トークン「ＥＸＴＥＲＮ＿ＧＬＯＢＡＬ」が使用された場合、これはキーワードから「コロン」によって分離されなければならない。「キーワード」トークンは、「英数字」文字、「アスタリスク」、「クエスチョンマーク」および「アンダースコア」文字からなることができる。「キーワード」の直後に現れる「論理改行」は、値のない属性を定義する。値がこの「キーワード」に関連付けられるべきである場合、「キーワード」の後に「コロン」が続かなければならない。この「コロン」の直後に現れる「論理改行」も、値のない属性の結果となる。この「コロン」の解析は、「デフォルト値コンテキスト」への移行を引き起こす。  
【００５９】
「デフォルト値コンテキスト」は、値を解析するための最初のコンテキストである。これは、「論理改行」が値解析を終了し、属性の定義を完了する唯一のコンテキストでもある。いかなる値コンテキストからも、「アクティブ文字」が現行のコンテキストを保存させ、新しいコンテキストを作成させるか、あるいは現行のコンテキストを終了させ、先に保存されたテキストを返させるかあるいは異なるコンテキストへの移行を開始させる。現行の最初のコンテキストが保存されるとき、処理は、新しい第２のコンテキストが終了するときにこの第１のコンテキストにより再開する。値ストリングの解析中に、出会ういかなる「ニュートラル文字」も「値バッファ」に転送される。「値バッファ」は、値収集が終了されるまですべての文字を蓄積し、その時点で、蓄積されたバイトが、ＧＤＬエントリを表すノードに組み込まれる。「値バッファ」はこの時点でクリアされ、新しいＧＤＬエントリのための文字を蓄積する準備ができるようにする。あるアクションが起こり、いくつかの特定の文字には「デフォルト値コンテキスト：」において出会う。以下の表では各「アクティブ文字」を列挙し、開始される、関連付けられたコンテキスト移行を記述する。
【００６０】
【表１】
2008251033.tif 000003
【００６１】
「ＤｅｒｅｆｅｒｅｎｃｅＭａｃｒｏコンテキスト」はマクロ参照を、マクロのコンテンツによって置き換える。現行の入力ポインタがマクロの最初の文字をポイントする。マクロコンテンツが完了すると、コントロールが、先に保存されたコンテキストに戻る。
【００６２】
「開括弧コンテキスト」は「デフォルト値コンテキスト」に類似しているが、アクションに以下の違いがある。
【００６３】
【表２】
2008251033.tif 000004
【００６４】
「開角括弧コンテキスト」：「開括弧コンテキスト」に類似しているが、以下の違いがある。
【００６５】
【表３】
2008251033.tif 000005
【００６６】
「開中括弧コンテキスト」：「デフォルト値コンテキスト」に類似しているが、以下の違いがある。
【００６７】
【表４】
2008251033.tif 000006
【００６８】
「コマンドパラメータコンテキスト」：「開括弧コンテキスト」に類似しているが、以下の違いがある。
【００６９】
【表５】
2008251033.tif 000007
【００７０】
「引用符付きストリングコンテキスト」は、すべての文字をニュートラル文字として処理させるが、以下の文字および文字の組合せの例外がある。ストリング処理が実際に起こらず、そのタスクがパーサフィルタに委ねられることに留意されたい。
【００７１】
【表６】
2008251033.tif 000008
【００７２】
１６進ストリングコンテキストは、認識された１６進文字および論理空白のみを許可する。１６進文字はペアで生じて、構文エラーを防止するべきである。このテキストは実際には１６進ストリングフォーマットをバイナリバイトに変換せず、このタスクはパーサフィルタに委ねられる。
【００７３】
【表７】
2008251033.tif 000009
【００７４】
「任意値コンテキスト」は、「引用符付きストリングコンテキスト」および「１６進ストリングコンテキスト」を除くいかなる値コンテキストからも入力することができる。任意コンテキストでは、すべての文字処理が中断され、すべての文字が直接「値バッファ」にコピーされる。以下のフォーマット「＜ＢｅｇｉｎＶａｌｕｅ：タグ＞」を有するストリングに出会ったとき、コンテキストが入力される。コンテキストは、以下のフォーマット「＜ＥｎｄＶａｌｕｅ：タグ＞」に出会ったとき、終了する。両方のフォーマットにおいて、タグはユーザ定義のシンボル名であり、これは任意値内で生じないトークンとなるように選択される。ＥｎｄＶａｌｕｅ：に使用されるタグは、ＢｅｇｉｎＶａｌｕｅ：に使用されるタグに合致しなければならない。「任意値コンテキスト」により、パーサは、そうでない場合にＧＤＬ構文に違反するであろう値を処理することができる。このような値は、ＸＭＬまたはスクリプトまたはバイナリファイルのような他の言語における逐語的なソースコードを含むことができる。ＢｅｇｉｎＶａｌｕｅ：およびＥｎｄＶａｌｕｅ：指示文は、「値バッファ」にコピーされない。この指示文を含むいかなる要素の間にも空白は許可されない。
【００７５】
また、ＧＤＬ内で使用可能なものは、特殊なコンストラクトである。そうでない場合は通常のＧＤＬエントリが、その後に「ＯｐｅｎＣｏｎｓｔｒｕｃｔデリミタ」：「｛」が続くとき、コンストラクトを導入する。このＧＤＬエントリは「コンストラクトエントリ」と呼ばれる。すべての後続のＧＤＬエントリは、コンストラクトが合致する「ＣｌｏｓｅＣｏｎｓｔｒｕｃｔデリミタ」の「｝」によって閉じられるまで、そのコンストラクトのメンバとなる。コンストラクトは、他のコンストラクト内でネストすることができる。「コンストラクトエントリ」に与えられたキーワード名は「コンストラクトタイプ」と呼ばれ、「コンストラクトエントリ」の値はタイプ「シンボル名」でなければならない。「シンボル名」は「コンストラクトインスタンス名」または単に「インスタンス名」として知られる。同じ「コンストラクトタイプ」の多数のインスタンスを定義することができるので、「インスタンス名」はこのタイプの各インスタンスを識別する。コンストラクトを「ＥＸＴＥＲＮ＿ＧＬＯＢＡＬ」となるように宣言することはできない。
【００７６】
パーサによる特殊なケース処理をトリガするキーワードがあり、このように、しばしば、これらのキーワードに関連付けられた構文上の制約がある。これらのキーワードおよびそれらに関係する関連処理は以下の通りである。
【００７７】
＊Ｔｅｍｐｌａｔｅ：このキーワードはパーサによって予約されている。
【００７８】
＊Ｉｎｃｌｕｄｅ：「インクルードＧＤＬファイルの名前」。パーサが、命名されたＧＤＬファイルのコンテンツをこのエントリの直後に挿入する。二重引用符で囲まれたストリングは２進ストリングに変換され、このストリングは、デフォルトコードページを使用してユニコードに変換される。結果として生じるストリングはＯｐｅｎＦｉｌｅの引数として使用される。引用符付きストリングコンテキストの外側のいかなる文字も無視される。このキーワードを「コンストラクトエントリ」として使用することはできない。前処理パスは、いずれかのマクロ解決またはエントリの標準の解析が開始する前に実行される。しかし、前処理中に＃Ｉｎｃｌｕｄｅ：指示文に出会った場合、参照されたファイルが開かれ、親ファイルの残りのエントリにより再開する前に、前処理がインクルードファイル上で実行される。これにより、インクルードファイルにおけるプリプロセッサ指示文が、親ファイルの残りにおける前処理に影響を与えることができる。後方互換性のため、キーワード＊Ｉｎｃｌｕｄｅ：はなお認識されるが、新しいファイル内で定義されたいかなるプリプロセッサ指示文も、親ファイルにおけるすべての指示文の後になるまで実行されないことに留意されたい。
【００７９】
＊Ｃｍｄ：、＊Ｃｏｍｍａｎｄ：ＧＰＤコマンドパラメータ構文の使用が、これらのキーワードについて可能にされる。この構文は、他のキーワードについては許可されない。
【００８０】
＊ＳｗｉｔｃｈＣａｓｅＥｖａｌｕａｔｉｏｎＢｅｈａｖｉｏｒ：Ｃ＿ＰＲＯＧＲＡＭ＿ＢＥＨＡＶＩＯＲ＜または＞ＧＰＤ＿ＰＡＲＳＥＲ＿ＣＯＭＰＡＴＩＢＬＥ：このパーサ指示文が解析時間で評価されて、ｓｗｉｔｃｈ／ｃａｓｅコンストラクトのための現行の評価モードが設定される。指示文は、別の指示文に出会うまで、定義のポイントからＧＤＬファイルの部分に影響を与える。デフォルトでは、挙動がＧＰＤ＿ＰＡＲＳＥＲ＿ＣＯＭＰＡＴＩＢＬＥに設定される。
【００８１】
他のタイプの汎用ルールがＧＤＬテキストファイルに適用される。たとえば、空白およびコメントを使用して、ＧＤＬファイルの構造に視覚的明瞭さを追加するべきであるが、これらはパーサによって取り除かれる。値において存在する空白の量は、空白が「引用符付きストリング」の一部でない限り、意味がない。コメントが行の最初で開始しない場合、これは、少なくとも１つの空白文字によって先行されるべきである。明確にするため、アスタリスク文字は、キーワードの最初の文字としてのみ使用されるべきであり、クエスチョンマーク文字「？」は最後の文字としてのみ使用されるべきである。追加の文字が、コンストラクトエントリにおけるインスタンス名の後に続くことができる。しかし、インスタンス名のみがインターフェイス関数ＥｎｕｍｅｒａｔｅＣｏｎｓｔｒｕｃｔＩｎｓｔａｎｃｅｓ（）によって列挙され、インスタンス名のみがＳｗｉｔｃｈ／Ｃａｓｅコンストラクトの引数として現れるべきであり、あるいはコンフィギュレーションを指定するときに供給されるべきである。クライアントプログラムまたはアプリケーションがコンフィギュレーションを得てパーサのインターフェイス関数に供給することを支援するため、ＧＤＬファイルは、自己矛盾のない最初の「コンフィギュレーション」を定義する。これは、制約の解決を必要としないものである。最初のコンフィギュレーションは、＊ＤｅｆａｕｌｔＯｐｔｉｏｎキーワードを使用して、各フィーチャのためのオプションを選択することによって定義することができる。このキーワードが省略された場合、これはクライアントプログラムまたはアプリケーションに、各フィーチャの最初のオプションが最初の「コンフィギュレーション」を構築するために使用されることを指示するものである。＊ＤｅｆａｕｌｔＯｐｔｉｏｎがｓｗｉｔｃｈ／ｃａｓｅコンストラクトによって囲まれた場合、自己矛盾のない明示的な＊Ｄｅｆａｕｌｔ：ケースがあるべきであり、そうでない場合、最初のオプションがデフォルトとして仮定される。
【００８２】
本明細書の他のセクションで論じたように、ＧＤＬテキストファイルの解析処理の結果は、ツリーの構築である。１つのツリーは、属性を表すノードからなるが、他は、関係のある値を表し、その両方がテキストファイルから得られる。図５は、ＧＤＬパーサツリー５０２、フィルタ５０３、デバイスドライバ５０４およびデバイス５０５のモジュールのインタラクションおよびロールを例示する。ＧＤＬパーサの機能性は、クライアントによって、ＧＤＬパーサフィルタおよびテンプレートの使用を介して拡張することができる。テンプレートのためのサポートが存在した後、拡張には、ＧＤＬパーサへのいかなる変更も必要ではない。ネイティブのＧＤＬパーサインターフェイスは、ＧＤＬファイルにおけるあらゆる属性の生の未処理の値へのアクセスを、ツリー構造５０２を介して提供する。あるタイプの属性へのアクセスを制限するか（すなわち、ツリーの枝刈り）、あるいは生の値データバイトの追加の意味処理を提供することが望ましい可能性のあるときがある。これらの機能は、パーサフィルタ５０３を介して実施される。パーサフィルタは、ＧＤＬナビゲーションおよびクエリを実施するもう１つのクライアントインターフェイスであり、ネイティブＧＤＬパーサインターフェイスを呼び出して、ＧＤＬ情報にアクセスする。しかし、パーサフィルタは、受信された情報を、情報をそのクライアントに返す前に処理する。図５のように、フィルタ５０３は、パーサツリー５０２から検索された情報を、情報をドライバ５０４に返す前に処理する。各クライアントドライバ５０４は、それに関連付けられる特定のフィルタ５０３を有することができることに留意されたい。フィルタ５０４は、最終的なクライアント、この場合はデバイス５０５に特に関係付けられる機能を提供する。たとえば、フィルタは、望まない属性を、関数ＥｎｕｍｅｒａｔｅＥｎｔｒｉｅｓ（）によって返されたリストから除去するか、あるいは、いくつかの値を、より容易に使用されるデータに変換することができ、これは、値ストリング「ＰＡＩＲ（１０２４，０ｘｆｃ）」を２つのダブルワード：０ｘ４００および０ｘｆｃに変換することなどである。パーサフィルタは、ハードコードされた意味情報に依拠することができ、これは、パーサフィルタが新しいキーワードを処理するために再記述される必要があることを意味する。この代替方法は、テンプレートを使用することによって回避することができ、これは上述のようにデータドリブンの代替方法を提供する。次いで、新しいキーワードおよびコンストラクトのための意味処理を、単に新しいテンプレートエントリをソースファイルに追加することによって、提供することができる。すなわち、各デバイス５０５について、このようなデバイスに共通である属性および機能を記述かつ定義するＧＤＬテキストファイルにおける特定のテンプレート、および、このデバイスに特有である特殊なフィーチャを記述かつ定義する１つ以上の特定のテンプレートが存在することができ、これは、このような特殊なフィーチャが新しいキーワードまたはコンストラクトを含むとした場合である。新しい機能がメーカによってデバイス１  ５０５Ｃに追加されるとき、その機能に関係付けられ���関連キーワードおよび属性がＧＤＬソースファイルにおいて現れ、これを１つ以上の追加テンプレートによって記述することができる。
【００８３】
パーサは、それが解析するエントリを格納するための２つのツリーを構築する。ＲｅａｌＴｒｅｅは、前処理段階後のＧＤＬファイルのコンテンツ全体の１対１表現である。これは、すべてのＳｗｉｔｃｈ／Ｃａｓｅコンストラクトを含む、エントリおよびコンストラクトのマクロ定義、テンプレート、およびリテラル表現を保持する。属性またはコンストラクトが２度定義された場合、ツリーは各定義のためのノードを含む。ルートのネスティングレベルは、ツリーのルートノードに対応する。各コンストラクトおよび属性がノードによって表現され、コンストラクトノードの子が、対応するコンストラクトエントリのメンバに対応する。属性は子を有していない。各属性の実際の値がこのツリーに格納される。ＩｎｄｅｘＴｒｅｅは、ＲｅａｌＴｒｅｅの論理構造を表す、簡素化されたツリーである。ＩｎｄｅｘＴｒｅｅは、その構造がデータインターフェイスを介して公開されるツリーである。ＩｎｄｅｘＴｒｅｅは、マクロ、テンプレート、Ｓｗｉｔｃｈ／Ｃａｓｅコンストラクト、属性の値も多数の定義も含まない。ＩｎｄｅｘＴｒｅｅは、抑制されたカテゴリにないあらゆる一意のコンストラクトおよび属性ノードに対応するノードを有する。Ｇｅｔ  Ｄａｔａインターフェイスによって使用された現在位置は、ＩｎｄｅｘＴｒｅｅにおけるコンストラクトノードに対応する。属性を表す各ＩｎｄｅｘＴｒｅｅノードはリンクリストをポイントし、そのメンバは、ＲｅａｌＴｒｅｅに格納される実際の属性である。Ｇｅｔ  Ｄａｔａインターフェイス関数ＧｅｔＲｅｃｅｎｔＶａｌｕｅ（）およびＧｅｔＡｌｌＶａｌｕｅｓ（）はリンクリストにおける各属性を評価して、属性がコンフィギュレーションに適用可能であるかどうかを決定する。コンフィギュレーションは、ＦｅａｔｕｒｅＩｎｓｔａｎｃｅ：ＯｐｔｉｏｎＩｎｓｔａｎｃｅペアのセットであり、これはデバイスのための設定を表す。たとえば、（ＰａｐｅｒＳｉｚｅ：Ｌｅｔｔｅｒ，ＩｎｐｕｔＢｉｎ：Ｌｏｗｅｒ）である。Ｓｗｉｔｃｈ／Ｃａｓｅコンストラクトは、コンフィギュレーションにおける属性またはコンストラクトの依存性を表現する。ＲｅａｌＴｒｅｅにおける各属性の位置が使用されて、その値が呼び出し側にレポートされ戻されるかどうかが決定される。たとえば、属性が、＊Ｓｗｉｔｃｈ：ＰａｐｅｒＳｉｚｅおよび＊Ｃａｓｅ：Ｌｅｇａｌを含むブランチにおけるものであった場合、その値は、現行のコンフィギュレーションがＰａｐｅｒＳｉｚｅ：Ｌｅｔｔｅｒに設定されている場合、レポートされない。ＩｎｄｅｘＴｒｅｅの構成は大幅にインターフェイス関数の実施を簡素化し、パフォーマンスを改善する。
【００８４】
本発明の代替実施形態は、図面を含め、明細書を再検討することによって、関係する当業者には明らかになるであろう。図１ないし図５に示し、本明細書に記載した様々なコンピュータシステムおよびコンポーネントは単に、本発明に関連して使用するために適切なものの例示的なものでしかない。したがって、本発明の範囲は、前述の記載ではなく付属の特許請求の範囲によって定義される。
【図面の簡単な説明】
【００８５】
【図１】本発明の実施に使用するために適したコンピューティングシステム環境のブロック図である。
【図２】本発明の前にそれらが存在したような、ユニバーサルプリンタドライバとＯＥＭカスタマイゼーションモジュールの間の高レベルモジュールインターフェイスを例示する、簡素化されたブロック図である。
【図３】本発明の解析プロセスに含まれるコンポーネントおよびデータフローを例示するブロック図である。
【図４】本発明のＧＤＬパーサによって作成されたテンプレート継承ツリーの、簡素化された例示的図である。
【図５】本発明におけるＧＤＬパーサ、フィルタおよびデバイスドライバの間の高レベルモジュールインターフェイスを例示するブロック図である。
【符号の説明】
【００８６】
１２０  処理装置
１２１  システムバス
１３０  システムメモリ
１３１  ＲＯＭ
１３２  ＲＡＭ
１３３  ＢＩＯＳ
１３４  オペレーティングシステム
１３５  アプリケーションプログラム
１３６  他のプログラムモジュール
１３７  プログラムデータ
１４０  取外し不可能な不揮発性メモリインターフェイス
１４１  ハードディスクドライブ
１４４  オペレーティングシステム
１４５  アプリケーションプログラム
１４６  他のプログラムモジュール
１４７  プログラムデータ
１５０  取外し可能な不揮発性メモリインターフェイス
１５１  磁気ディスクドライブ
１５２  磁気ディスク
１５５  光ディスクドライブ
１５６  光ディスク
１６０  ユーザ入力インターフェイス
１６１  マウス
１６２  キーボード
１７０  ネットワークインターフェイス
１７１  ローカルエリアネットワーク
１７２  モデム
１７３  広域ネットワーク
１８０  リモートコンピュータ
１８１  メモリデバイス
１８５  リモートアプリケーションプログラム
１９０  ビデオインターフェイス
１９１  モニタ
１９５  出力周辺インターフェイス
１９６  プリンタ
１９７  スピーカ
２０１  アプリケーションプログラム
２０２  グラフィックスデバイスインターフェイス
２０３Ａ、２０３Ｂ  ミニドライバ
２０４  ユニバーサルドライバＵＮＩＤＲＶ５
２０５Ａ  プリンタモデルＡ
２０５Ｂ  プリンタモデルＺ
５０１  アプリケーションプログラム
５０２  ＧＤＬパーサツリー構造
５０３Ａ、５０３Ｂ、５０３Ｃ  フィルタ１
５０４Ａ  ユニバーサルドライバＵＮＩＤＲＶ５
５０４Ｂ  他のドライバＡ
５０４Ｃ  他のドライバＺ
５０５Ａ、５０５Ｂ  プリンタモデルＡ
５０５Ｃ  デバイス１
５０５Ｄ  デバイスＮ
【図１】
2008251033.tif 000010
【図２】
2008251033.tif 000011
【図３】
2008251033.tif 000012
【図４】
2008251033.tif 000013
【図５】
2008251033.tif 000014