XML インスタンス文書および XML Schema では、ネーム・スペースを利用できます。 ネーム・スペースによって、オブジェクト名を修飾する方法が提供されます。
単一の XML インスタンス文書には、複数のアプリケーションに定義され、 おそらくはそれらのアプリケーションに使用される、エレメントおよび属性を入れることができます。 同じ文書内の 2 つの異なるエレメントまたは属性で、同じ名前が必要になる場合があります。 個々のアプリケーションは、処理するように設計されているエレメントおよび属性を認識することが必要です。 このような状況では、各エレメントを別々のネーム・スペースで修飾することによって、定義を相互に認識することができます。 これにより、名前の競合および認識の間違いによる問題を避けることができます。
XML Schema では、ターゲット・ネーム・スペースを定義できます。 ターゲット・ネーム・スペースが定義されている場合に、それによって、XML Schema 内で定義されている、 グローバルなエレメント、属性、グループ、およびタイプが修飾されます。 さらに、ターゲット・ネーム・スペースによって、ローカルのエレメントおよび属性を修飾することもできます。 そのため、ネーム・スペースは、独自に開発できる XML スキーマのライブラリーを開発する際に役立ちます。 XML スキーマで使用されるネーム・スペース名を固有の名前にすると、 開発者は他の XML スキーマ内で定義されているオブジェクトとの名前の重複について心配しなくて済みます。
ネーム・スペースの有効範囲は、それが包含する文書の有効範囲を越えて広がり、 Uniform Resource Identifier (URI) により識別されます。 その目的を果たすには、URI が固有でなければなりません。 Universal Resource Locator (URL) の概念のほうがよく知られているかもしれません。 URI はほとんどの場合、URL と同じ構文を使用しますが、URI 定義の方が URL の仕様よりも広範です。 これは URI の例です。http://mycompany.com/xml_schema
ネーム・スペース接頭部は完全な URI 名の簡略形式として宣言され、 そのネーム・スペースに属するすべてのエレメントを修飾するために使われます。 XML インスタンス文書または XML スキーマ内でのネーム・スペースで置換される接頭部は、xmlns または xmlnsc 属性を使用して指定します。 また、デフォルトのネーム・スペースは、xmlns または xmlnsc 属性を使用して定義できます。 デフォルトのネーム・スペースが定義されている場合、接頭部のないエレメントまたは属性は、 デフォルトのネーム・スペースで修飾されます。 デフォルトのネーム・スペースが定義されていない場合、接頭部のないエレメントまたは属性に、 ネーム・スペースでの修飾は行われません。
ネーム・スペースを使用可能にした単一メッセージ・セットには、さまざまなネーム・スペースを多数含めることができます。 各ネーム・スペースは、異なるメッセージ定義ファイルにより表現されます。 メッセージ定義ファイルを作成する場合、関連するネーム・スペースをそれに含めるかどうか、または notarget ネーム・スペース内にそれを入れるかどうかを選択できます。 ネーム・スペースをメッセージ定義ファイルに関連付ける場合、接頭部の選択も行わなければなりません。
メッセージ定義ファイルに関連するネーム・スペースがある場合、 以下のグローバル・オブジェクトがネーム・スペースで修飾されます。
さらに、ローカルのエレメントおよび属性を、ネーム・スペースで修飾することもできます。
メッセージ定義ファイルで定義したオブジェクトは、 同じメッセージ・セット内の他のメッセージ定義ファイル内のオブジェクトを参照できます。 これはインポートによって行うか、またはメッセージ定義ファイルを別のメッセージ定義ファイル内に含めることによって行います。
WebSphere Message Broker を使用しており、メッセージ・セットでネーム・スペースが使用可能になっている場合、 XML インスタンス文書を構文解析する際に、Broker はツリー内で xmlns または xmlnsc 属性の値を保管することはありません。 Schema Location および No Namespace Schema Location 属性の値の保管も行われません。 これは、XML 文書が書き出されるときに、Broker はこの情報を、 メッセージ・セットの XML ワイヤー形式のプロパティーから再生成するためです。
WebSphere Message Broker を使用している場合、XML メッセージの出力時に MRM ドメインによってネーム・スペースの URI/接頭部のペアの表が使用されます。 ネーム・スペースによって修飾されているエレメントおよび属性は、 その表からの対応する接頭部によって接頭部が付けられています。 Broker は、対応する xmlns または xmlnsc 属性 (接頭部をネーム・スペースにマップしている) の出力も管理します。 ネーム・スペースの URI/接頭部の表のすべてのエントリーの xmlns または xmlnsc 属性が、文書の開始時点で出力されるかどうか、 またはそれらが必要なときに文書内で出力されるだけにするかを選択できます。
ネーム・スペースがメッセージ・セットで使用可能な場合、 XML ワイヤー形式で、ネーム・スペースの URI をファイル名にマップするスキーマ・ロケーションの表が存在します。 エントリーをこの表を追加したり、ファイル名を notarget ネーム・スペースにマップできます。 WebSphere Message Broker を使用している場合、 この表が使用されて、schemaLocation および No Namespace Schema Location 属性が XML 文書の開始時に出力されます。
MRM ドメイン内で XML 形式を使用する場合、 構文解析対象のメッセージがメッセージ・モデルから生成されたディクショナリーと突き合わされるとき、 ディクショナリー内のネーム・スペースに基づいてエレメントと属性が突き合わされます。 そのため、メッセージ内のエレメントまたは属性でディクショナリーと突き合わせるために、名前とネーム・スペースが一致して いなければなりません。
WebSphere Message Broker を使用している場合、ESQL の書き込み時にネーム・スペースを指定できるように、サポートが提供されてます。 ネーム・スペースを使用していない場合、ネーム・スペースを認識する ESQL を作成する必要はありません。 しかし、ネーム・スペースを使用する場合は、選択されるネーム・スペースをメッセージ定義ファイルが ターゲットにすることがあり、ネーム・スペースを認識する ESQL を作成する必要があります。 エレメントが存在するネーム・スペースは、解析時にメッセージ・ツリーに保管されます。 これは論理プロパティーで、メッセージが解析および作成される物理ワイヤー形式に関係なく保留されます。 新しい構文が ESQL に追加され、定義された接頭部を使ってエレメント・ネーム・スペースの参照が容易になります。