メッセージ・モデルのネーム・スペース

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 ネーム・スペース内にそれを入れるかどうかを選択できます。 ネーム・スペースをメッセージ定義ファイルに関連付ける場合、接頭部の選択も行わなければなりません。

メッセージ定義ファイルに関連するネーム・スペースがある場合、 以下のグローバル・オブジェクトがネーム・スペースで修飾されます。

  • エレメント
  • 属性
  • 単純タイプ
  • 複合タイプ
  • グループ
  • 属性グループ

さらに、ローカルのエレメントおよび属性を、ネーム・スペースで修飾することもできます。

メッセージ定義ファイルで定義したオブジェクトは、 同じメッセージ・セット内の他のメッセージ定義ファイル内のオブジェクトを参照できます。 これはインポートによって行うか、またはメッセージ定義ファイルを別のメッセージ定義ファイル内に含めることによって行います。

XML ワイヤー形式
メッセージ定義ファイルに関連付けられているネーム・スペースは、メッセージ・モデルの論理レイヤーの一部です。 そのため、XML ワイヤー形式の存在には依存していません。 しかし、XML ワイヤー形式が含まれている場合、XML ワイヤー形式のいくつかのプロパティーへの取り込みを行うために、 論理レイヤーからのネーム・スペース情報が使用されます。 ネーム・スペースがメッセージ・セットで使用可能な場合、XML ワイヤー形式で、 ネーム・スペースの URI/接頭部のペアの表が保持されます。 最初はこの表には、作成時にそれらの接頭部を含むすべてのメッセージ定義ファイルのネーム・スペースが取り込まれています。

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 文書の開始時に出力されます。

メッセージの構文解析および ESQL
WebSphere Message Broker を使用している場合、MRM ドメイン、および XMLNS と XMLNSC ドメイン・パーサーは、解析する XML メッセージ中の接頭部付きの名前を認識し、 内部的にこれらを正しいネーム・スペースにマップします。 メッセージ・モデルから生成されたディクショナリー内のエレメントおよび属性は、 メッセージ・モデルのセクションで説明したように、ネーム・スペースで修飾するかどうかを選択できます。

MRM ドメイン内で XML 形式を使用する場合、 構文解析対象のメッセージがメッセージ・モデルから生成されたディクショナリーと突き合わされるとき、 ディクショナリー内のネーム・スペースに基づいてエレメントと属性が突き合わされます。 そのため、メッセージ内のエレメントまたは属性でディクショナリーと突き合わせるために、名前とネーム・スペースが一致して いなければなりません。

WebSphere Message Broker を使用している場合、ESQL の書き込み時にネーム・スペースを指定できるように、サポートが提供されてます。 ネーム・スペースを使用していない場合、ネーム・スペースを認識する ESQL を作成する必要はありません。 しかし、ネーム・スペースを使用する場合は、選択されるネーム・スペースをメッセージ定義ファイルが ターゲットにすることがあり、ネーム・スペースを認識する ESQL を作成する必要があります。 エレメントが存在するネーム・スペースは、解析時にメッセージ・ツリーに保管されます。 これは論理プロパティーで、メッセージが解析および作成される物理ワイヤー形式に関係なく保留されます。 新しい構文が ESQL に追加され、定義された接頭部を使ってエレメント・ネーム・スペースの参照が容易になります。

他の形式からのインポート
メッセージ・モデルを使用すれば、他の形式からメッセージ定義ファイルを作成できます。 これは、他の形式を Message Brokers Toolkit にインポートすることによって行います。
  • XML DTD ファイルをインポートする場合、作成されるメッセージ定義ファイルは notarget ネーム・スペースに入れられます。
  • XML スキーマ・ファイルをインポートする場合、作成されたメッセージ定義ファイルのターゲット・ネーム・スペースは、ネーム・スペースがメッセージ・セットで使用可能になっているかどうかによって異なります。
    • ネーム・スペースが使用可能になっている場合、作成されるメッセージ定義ファイルのターゲット・ネーム・スペースは、インポートされる XML スキーマのターゲット・ネーム・スペースになります。
    • メッセージ・セットでネーム・スペースが使用不可の場合、作成されるメッセージ定義ファイルは notarget ネーム・スペースに入れられます。 このタイプのインポートでは、完全なネーム・スペースのサポートは提供されません。 WebSphere Message Broker を使用している場合、 このメッセージ・モデルから生成されたディクショナリーと比較して構文解析された XML メッセージを処理するための、ネーム・スペースを認識する ESQL または Java を書く必要はありません。 この作業を行う理由については、ネーム・スペースが使用不可になっているメッセージ・セットへの XML スキーマのインポートを参照してください。
  • COBOL コピーブックまたは C ヘッダー・ファイルをインポートする場合、作成されたメッセージ定義ファイルのターゲット・ネーム・スペースは、ネーム・スペースがメッセージ・セットで使用可能になっているかどうかによって異なります。
    • ネーム・スペースが使用可能になっている場合、作成されるメッセージ定義ファイルのターゲット・ネーム・スペースは、notarget ネーム・スペースです。 「新規メッセージ定義ファイル」ウィザードでターゲット・ネーム・スペースを指定することにより、デフォルトのネーム・スペースをオーバーライドすることができます。 この作業を行う理由については、非 XML メッセージを含むネーム・スペースを参照してください。
    • メッセージ・セットでネーム・スペースが使用不可の場合、作成されるメッセージ定義ファイルは notarget ネーム・スペースに入れられます。

XML に関する詳細情報

World Wide Web Consortium (W3C) Web サイトで、以下も参照してください。

特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック
Copyright IBM Corporation 1999, 2006 最終更新: 08/21/2006
ad00820_