Share via

.NET XAML サービスの XAML 名前空間

  • [アーティクル]

XAML 名前空間は、XML 名前空間の定義を拡張する概念です。 XML 名前空間と同様に、マークアップで xmlns 属性を使用して XAML 名前空間を定義できます。 XAML 名前空間は、XAML ノード ストリームおよび他の XAML Services API でも表されます。 このトピックでは、XAML 名前空間の概念を定義し、XAML 名前空間を定義する方法と、XAML スキーマ コンテキストや .NET XAML サービスの他の側面で使用する方法について説明します。

XML 名前空間と XAML 名前空間

XAML が XML の特殊な形式で、そのマークアップに基本的な XML 形式を使用するのと同じように、XAML 名前空間は特殊な XML 名前空間です。 マークアップでは、要素に適用される xmlns 属性を使用して、XAML 名前空間とそのマッピングを宣言します。 XAML 名前空間が宣言されているのと同じ要素に対して、xmlns 宣言を行うことができます。 ある要素に対して行われた XAML 名前空間の宣言は、その要素、その要素のすべての属性、およびその要素のすべての子に対して有効です。 属性では、その属性が含まれる要素とは異なる XAML 名前空間を使用できますが、それができるのは、属性名自体において、マークアップでの属性名の一部としてプレフィックスを参照している場合だけです。

XAML 名前空間と XML 名前空間の違いは、XML 名前空間は、スキーマを参照するため、または単にエンティティを区別するために、使用される場合があることです。 XAML の場合、XAML で使用される型とメンバーは、最終的にバッキング型に解決される必要があり、XML スキーマの概念はこの機能にうまく適用されません。 XAML 名前空間には、この型マッピングを実行するために XAML スキーマ コンテキストで使用できる必要がある情報が含まれています。

XAML 名前空間のコンポーネント

XAML 名前空間の定義には、プレフィックスと識別子という 2 つのコンポーネントがあります。 これらの各コンポーネントは、XAML 名前空間がマークアップで宣言されていると、または XAML 型システムで定義されていると存在します。

プレフィックスには、XML 1.0 仕様での W3C 名前空間によって許可されている任意の文字列を使用できます。 プレフィックスは一般的なマークアップ ファイルで何度も繰り返されるため、慣例として、通常は短い文字列にします。 XAML の複数の実装で使用することを意図された特定の XAML 名前空間では、特定の従来のプレフィックスが使用されます。 たとえば、XAML 言語の XAML 名前空間は、通常、プレフィックス x を使用してマップされます。 既定の XAML 名前空間を定義できます。その場合、プレフィックスは定義では指定されませんが、.NET XAML Services API による定義またはクエリの場合は空の文字列として表されます。 通常、既定の XAML 名前空間は、XAML 実装テクノロジおよびそのシナリオとボキャブラリで、プレフィックスが省略されるマークアップの量が最大になるように、意図的に選択されます。

識別子には、XML 1.0 仕様での W3C 名前空間によって許可されている任意の文字列を使用できます。 慣例として、XML 名前空間または XAML 名前空間の識別子は、通常、URI 形式 (通常は、プロトコルで修飾された絶対 URI) で指定されます。 多くの場合、特定の XAML ボキャブラリを定義するバージョン情報が、パス文字列の一部として暗黙的に指定されます。 XAML 名前空間により、XML での URI の規則にはない付加的な識別子規則が追加されます。 XAML 名前空間の場合は、識別子により、その XAML 名前空間の下で要素として指定されている型を解決するため、または属性をメンバーに解決するために、XAML スキーマ コンテキストで必要な情報が伝えられます。

XAML スキーマ コンテキストに情報を伝えることが目的の場合、XAML 名前空間の識別子としてやはり URI 形式が使用されることがあります。 ただし、この場合の URI は、特定のアセンブリまたはアセンブリのリストにおいても一致する識別子として宣言されます。 これは、XmlnsDefinitionAttribute でアセンブリの属性を指定することによって行われます。 属性付きアセンブリで XAML 名前空間を識別し、CLR ベースの型解決動作をサポートするこの方法は、.NET XAML サービスでの既定の XAML スキーマ コンテキストでサポートされています。 より一般的には、この規則は、XAML スキーマ コンテキストに CLR が組み込まれている場合、または XAML スキーマ コンテキストが既定の XAML スキーマ コンテキストに基づいている場合に使用でき、これは CLR アセンブリから CLR 属性を読み取るために必要です。

XAML 名前空間は、CLR 名前空間と型定義アセンブリを伝える規則によって識別することもできます。 この規則は、型を含むアセンブリに XmlnsDefinitionAttribute 属性が存在しない場合に使用されます。 この規則は、URI の規則より複雑になる可能性があります。また、アセンブリを参照する方法が複数あるため、あいまいさと重複が発生する可能性もあります。

CLR 名前空間とアセンブリの規則を使用する識別子の最も基本的な形式は次のとおりです。

clr-namespace:clrnsName; assembly=assemblyShortName

clr-namespace: と ; assembly= は、構文のリテラル コンポーネントです。

clrnsName は、CLR 名前空間を示す文字列名です。 この文字列名には、CLR 名前空間および他の CLR 名前空間に対するその関係に関するヒントを提供する内部ドット文字 (.) が含まれます。

assemblyShortName は、XAML で役に立つ型が定義されているアセンブリの文字列名です。 宣言されている XAML 名前空間によってアクセスされる型は、そのアセンブリによって定義され、clrnsName によって指定されている CLR 名前空間内で宣言されているものと想定されます。 この文字列名は、通常、AssemblyName.Name によって報告される情報に似ています。

CLR 名前空間とアセンブリ規則のさらに完全な定義は次のとおりです。

clr-namespace:clrnsName; assembly=assemblyName

assemblyName は、Assembly.Load(String) の入力として有効な任意の文字列を表します。 この文字列には、カルチャ、公開キー、またはバージョン情報を含めることができます (これらの概念の定義は、Assembly のリファレンス トピックで定義されています)。 COFF 形式と証拠 (Load の他のオーバーロードによって使用されるもの) は、XAML アセンブリの読み込みの目的には関係ありません。すべての読み込み情報は、文字列として提供される必要があります。

アセンブリの公開キーを指定することは、XAML のセキュリティのため、またはアセンブリが簡易名によって読み込まれる場合や、キャッシュまたはアプリケーション ドメインに事前に存在する場合に発生する可能性があるあいまいさを解消するために、便利な手法です。 詳しくは、「XAML セキュリティの考慮事項」をご覧ください。

XAML Services API での XAML 名前空間の宣言

XAML Services API では、XAML 名前空間の宣言は NamespaceDeclaration オブジェクトによって表されます。 コードで XAML 名前空間を宣言する場合は、NamespaceDeclaration(String, String) コンストラクターを呼び出します。 ns および prefix パラメーターは文字列として指定し、これらのパラメーターで提供する入力は、このトピックで既に説明したように、XAML 名前空間識別子および XAML 名前空間プレフィックスの定義に対応します。

XAML ノード ストリームの一部として、または XAML 型システムへの他のアクセスを介して、XAML 名前空間の情報を調べる場合は、NamespaceDeclaration.Namespace によって XAML 名前空間識別子が報告され、NamespaceDeclaration.Prefix によって XAML 名前空間プレフィックスが報告されます。

XAML ノード ストリームでの XAML 名前空間の情報は、適用対象のエンティティの前に付加される XAML ノードとして指定できます。 これには、XAML 名前空間の情報が XAML ルート要素の StartObject の前に付加される場合が含まれます。 詳細については、「 Understanding XAML Node Stream Structures and Concepts」を参照してください。

.NET XAML Services API を使用する多くのシナリオでは、少なくとも 1 つの XAML 名前空間宣言が存在している必要があり、宣言には XAML スキーマ コンテキストで必要な情報が含まれるか参照されている必要があります。 XAML 名前空間により、読み込むアセンブリが指定されていること、または XAML スキーマ コンテキストによって既に読み込まれているか既知である名前空間およびアセンブリ内の特定の型の解決が支援されることが必要です。

XAML ノード ストリームを生成するには、XAML スキーマ コンテキストを通じて XAML 型情報が使用可能である必要があります。 作成する各ノードに関連する XAML 名前空間を最初に特定しなければ、XAML 型情報を特定することはできません。 この時点では、型のインスタンスはまだ作成されていませんが、XAML スキーマ コンテキストで、定義しているアセンブリとバッキング型から情報を検索することが必要な場合があります。 たとえば、マークアップ <Party><PartyFavor/></Party> を処理するには、XAML スキーマ コンテキストにおいて、Party の ContentProperty の名前と型を特定できる必要があり、Party と PartyFavor の XAML 名前空間の情報を把握している必要もあります。 既定の XAML スキーマ コンテキストの場合、静的なリフレクションにより、ノード ストリームで XAML 型ノードを生成するために必要な XAML 型システムの情報の多くが報告されます。

XAML ノードス トリームからオブジェクト グラフを生成するには、元のマークアップで使用され、XAML ノード ストリームに記録される各 XAML プレフィックスに、XAML 名前空間宣言が存在する必要があります。 この時点で、インスタンスが作成され、実際の型マッピング動作が発生します。

XAML 名前空間情報を事前に設定する必要があり、XAML スキーマ コンテキストで使用する XAML 名前空間がマークアップで定義されていない場合、使用できる方法の 1 つは、XML 名前空間宣言を XmlReader の XmlParserContext で宣言することです。 その後、XAML リーダー コンストラクターの入力としてその XmlReader を使用するか、または XamlServices.Load(XmlReader) を使用します。

.NET XAML サービスでの XAML 名前空間の処理に関連する他の 2 つの API は、属性 XmlnsDefinitionAttribute と XmlnsPrefixAttribute です。 これらの属性は、アセンブリに適用されます。 XmlnsDefinitionAttribute は、URI が含まれる任意の XAML 名前空間宣言を解釈するために、XAML スキーマ コンテキストによって使用されます。 XmlnsPrefixAttribute は、特定の XAML 名前空間を予測可能なプレフィックスでシリアル化できるように、XAML を生成するツールによって使用されます。 詳しくは、「カスタム型およびライブラリの XAML 関連の CLR 属性」をご覧ください。

関連項目