NIEM IEPD を作成する: 第 3 回 NIEM の拡張

米国政府機関の間での XML 情報交換を設計する

この連載の最初の 2 回の記事では、NIEM 情報交換のモデルを作成する方法、そのモデルを NIEM の基本モデルにマッピングする方法、そして独自の IEPD で使用する NIEM モデルのサブセットを作成する方法を学びました。今回は、作成したモデルのなかで NIEM に直接対応していない部分に対処する方法を、カスタマイズした型およびプロパティーを定義する拡張スキーマと交換スキーマを作成する手順を通して説明します。

Priscilla Walmsley, Managing Director, Datypic

Photo of Priscilla WalmsleyPriscilla Walmsley は、Datypic の取締役兼シニア・コンサルタントです。彼女の専門は XML 技術、設計、および実装で、最近では (Trusted Federal Systems を通じて) 米国司法省に協力し、NIEM ベースの IEPD フレームワーク、LEXS に取り組みました。著書には『Definitive XML Schema』(Prentice Hall、2001年)、『XQuery』(O'Reilly Media、2007年) があります。また、『Web Service Contract Design and Versioning for SOA』(Prentice Hall、2008年) の共著者でもあります。



2010年 3月 18日 (初版 2010年 3月 09日)

2010年 5月 18日: 連載第 4 回へのリンクを導入部分、まとめ、そして参考文献のセクションに追加しました。

2010年 5月 12日: 読者からのコメントを基に、著者によって一方のダウンロード・ファイルの XML スキーマ文書が変更されました。これにより、エラーが発生するとスキーマが無効になるようになりました。
また、リスト 1 の 15 行目の終わりに、/niem-core.xsd を追加しました。これにより、現在 15 行目は以下のようになっています。

  <xsd:import schemaLocation="../../niem/niem-core/2.0/niem-core.xsd"

ダウンロード・ファイル niem3schemas.zip も更新バージョンに置き換わっています。

よく使われる頭字語

  • CMT: Component Mapping Template
  • IEPD: Information Exchange Package Documentation
  • NDR: NIEM Naming and Design Rules
  • NIEM: National Information Exchange Model
  • SSGT: NIEM Schema Subset Generation Tool
  • XML: Extensible Markup Language

NIEM (National Information Exchange Model) は 6000 を超える要素で構成された大規模なモデルですが、独自に作成する XML 情報交換に組み込む必要のあるすべての要素が揃っていることはめったにありません。このモデルは考えられるあらゆるシナリオに対応するように意図されているのではなく、最もよく使用される情報の構成要素をおさえるように意図されています。そのため、作成する IEPD (Information Exchange Package Documentation) のほとんどでは、その特定の情報交換に固有の型とプロパティーを追加するための拡張スキーマを作成することになります。NIEM では、NIEM IEPD 間での相互運用性を最大限に引き出すようにモデルを拡張する方法について、詳細なガイドラインを示しています。

NIEM モデルでは、情報交換に含まれるすべてのオブジェクトをアセンブルするためのメッセージ・タイプや構造を特に定義していません。情報交換スキーマを作成し、ルート要素とメッセージの基本構造を宣言するのは、IEPD の作成者に委ねられています。

連載の第 1 回と第 2 回では、単純な盗難報告書を例に作業を進めてきました (この 2 つの記事へのリンクについては「参考文献」を参照してください)。図 1 に、この例を基に作成した情報交換モデルを示します。前回の記事でベースとなる NIEM モデルにマッピングできなかったプロパティーと型には、Bicycle 型と TheftReport 型、そして IsRegisteredVehicleCategoryCountyCode の 3 つのプロパティーがあります。

図 1. 拡張する部分が示された IEPD モデル

二重のアスタリスク (**) は、ベースとなる NIEM モデルにマッピングされていないプロパティーと型に付けられています。二重のアスタリスクが付けられているものには、Bicycle 型と TheftReport 型、そして IsRegistered プロパティー、VehicleCategory プロパティー、および CountyCode プロパティーがあります。

拡張する部分が示された IEPD モデル(図 1) をテキストで表現したもの

リスティングを見るにはここをクリック

拡張する部分が示された IEPD モデル(図 1) をテキストで表現したもの

                          ____________________________ 
                          |     ** TheftReport        |
                          |___________________________|
                          | ** TheftReportDate : date |
                          |___________________________|
                                    ^
                                    V 1
                                    |
                                    |
                                    |
________________________            | 1..*
|    TheftLocation      |         ___________________________ 
|_______________________|         |          Theft           | 1             1  _________________________
| Address : string      | 1   1 * |__________________________|__________________|       Property         |
| City : string         |_________| TheftDateTime : dateTime |                  |________________________|
| State : string        |         |__________________________|                  | SerialNumber : integer |
| ZipCode : string      |         |                     |                       | Description : string   |
| ** CountyCode : code  |         | 1                 1 |                       | Color : string         |
|_______________________|         |                     |                       |________________________|
                                  |                     |                             ^           ^
                                  | 1              0..* |                             |           |
                           ____________   ___________________                         |           |
                          |   Victim   |  |    Witness       |                        |           |
                          |____________|  |__________________|      ____________________________   ____________________________
                          |            |  | Account : string |      |     MotorVehicle          |  |     ** Bicycle            |
                          |____________|  |__________________|      |___________________________|  |___________________________|
                              |                  |                  | LicensePlate : string     |  | ** IsRegistered : boolean |
                              | 1                | 1                | ** VehicleCategory : code |  |___________________________|
                              |                  |                  |___________________________|
                              | RoleofPerson     | RoleofPerson
                              |                  |                  
                              | 1                | 1                
                              |                  |             
                           _________________________ 
                           |         Person         |                    _____________________ 
                           |________________________|   1  PersonName  1 |    PersonName      |
                           | DriverLicense : string |<>------------------|____________________|
                           |                        |                    | FirstName : string |
                           |________________________|                    | LastName : string  |
                                                                         |____________________|

この例の場合、NIEM は要求をほとんど満たしているとは言え、以下の 2 つの新しいスキーマについては独自に作成する必要があります。

  • Bicycle 型と IsRegisteredVehicleCategoryCountyCode の各プロパティーを定義する拡張スキーマ
  • TheftReport 型を定義し (これがルートであるため)、その他すべての型をメッセージに組み込むための構造を規定する交換スキーマ

NIEM スキーマの作成

NIEM の拡張スキーマと交換スキーマ (および生成されたサブセット・スキーマ) は、XML Schema で作成されます。この記事では NIEM に準拠したスキーマの例を記載しますが、XML Schema 言語については詳しく説明しません。まだスキーマについてよく理解していない方は、わかりやすく解説している XML Schema の入門書 (「参考文献」を参照) を読むことをお勧めします。

XML Schema によって課せられる制約の他に、NIEM は NDR (NIEM Naming and Design Rules) 文書 (リンクについては「参考文献」を参照) に文書化された独自のルールを設けています。NIEM 独自のルールが何よりも対象としているのは、NIEM コンポーネントの命名および文書化標準、使用可/不可の XML Schema 構成体、そして認可されている NIEM の使用方法および拡張方法です。IEPD のスキーマがこれらの NDR ルールに従っていなければ、NIEM 準拠のスキーマにはなりません。

スキーマ文書には、それぞれに固有のターゲット名前空間がなければなりません。この例の IEPD の場合、拡張スキーマの名前空間には http://www.datypic.com/theftreport/extension/1.0 (接頭辞 trext: を使用) を使用し、交換スキーマの名前空間には http://www.datypic.com/theftreport/exchange/1.0 (接頭辞 tr: を使用) を使用します。

フォルダー構造には、名前空間の名前を反映した構造を使用することが慣例となっています。そこで、Theft Report IEPD 内に extension という名前のフォルダーと exchange という名前のフォルダーを作成し、それぞれのフォルダー内に 1.0 という名前のサブフォルダーを作成して、そこに該当するスキーマ文書を配置することにします。

典型的な NIEM スキーマ文書 (この例の場合は、Theft Report の拡張スキーマ) の先頭の部分をリスト 1 に記載します。

リスト 1. NIEM に準拠したスキーマの先頭部分
<xsd:schema targetNamespace="http://datypic.com/theftreport/extension/1.0"
            version="1.0"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:trext="http://datypic.com/theftreport/extension/1.0"
            xmlns:s="http://niem.gov/niem/structures/2.0"
            xmlns:nc="http://niem.gov/niem/niem-core/2.0"
            xmlns:niem-xsd="http://niem.gov/niem/proxy/xsd/2.0"
            xmlns:i="http://niem.gov/niem/appinfo/2.0">
  <xsd:annotation>
    <xsd:documentation>Theft Report extension schema</xsd:documentation>
    <xsd:appinfo>
      <i:ConformantIndicator>true</i:ConformantIndicator>
    </xsd:appinfo>
  </xsd:annotation>
  <xsd:import schemaLocation="../../niem/niem-core/2.0"
              namespace="http://niem.gov/niem/niem-core/2.0"/>
  <xsd:import schemaLocation="../../niem/proxy/xsd/2.0/xsd.xsd"
              namespace="http://niem.gov/niem/proxy/xsd/2.0"/>
  <xsd:import schemaLocation="../../niem/structures/2.0/structures.xsd"
              namespace="http://niem.gov/niem/structures/2.0"/>
  <xsd:import schemaLocation="../../niem/appinfo/2.0/appinfo.xsd"
              namespace="http://niem.gov/niem/appinfo/2.0"/>

NIEM スキーマ文書には xsd:annotation 要素が必要です。この要素のなかに、そのスキーマ文書の説明 (xsd:documentation 内) と NIEM 準拠の標識 (xsd:appinfo 内) が含まれていなければなりません。

あらゆるスキーマの例に洩れず、NIEM スキーマ文書は直接参照する必要のある名前空間をすべて宣言し、インポートします。また、リスト 1 の最後の行にある appinfo スキーマもインポートする必要があります。このスキーマが、xsd:appinfo 要素内で使用される要素を宣言します。

注: この記事のリストがすべて組み込まれた完全な拡張スキーマ文書および交換スキーマ文書は、「ダウンロード」から入手することができます。


拡張スキーマ

IEPD の複雑さによっては、拡張スキーマが 1 つしかないこともあれば、多数ある場合もあります。IEPD 開発者のなかには、拡張スキーマをサブジェクトの分野別に分割し、複数の文書にすることによって各種の情報交換でスキーマをより細かいレベルで再利用できるようにしている開発者もいれば、頻繁にバージョン管理される可能性のあるコンポーネント (コード・リストなど) を別のスキーマ文書に分けることにしている開発者もいます。

盗難報告書の例は単純なので、拡張スキーマを 1 つだけ作成することにします。リスト 1 に記載したスキーマの先頭部分に続けて、カスタム・コンポーネント用に型を定義し、要素を宣言する必要があります。NIEM を拡張する方法には何通りもの方法があるので、以下に説明するカスタマイズでは、それぞれに異なる方法を使用しようと思います。

置換グループを使用する

NIEM を拡張するのに最も簡単な方法は、おそらく置換グループを使用することでしょう。置換グループを使用すれば、独自の要素を宣言し、その要素を NIEM 要素の置き換えとして指定することができます。つまり、置換グループは、NIEM 要素の使用が許可された任意の場所で使用できるということです。置換グループを使用するという方法は、要求している内容と意味的に等価な要素が NIEM モデルの中にあるものの、要求を完全には満たしていない場合に使用することができます。一例として、サンプル・モデルにある CountyCode プロパティーは、住所のなかに出現する nc:LocationCounty という NIEM の抽象要素と意味的には同じです。この抽象要素の置換グループには NIEM コア・モデルの一部となっている要素がすでに 2 つありますが、これらの要素はこの場合の要求を満たしません。nc:LocationCountyCode が使用するコード・リストは異なり、nc:LocationCountyName はコードではなくスペルアウトした名前を対象としているからです。そのため、これらの要素の代わりに、独自のコード・リストを使用する新しい要素、trext:LocationCountyCode を宣言します。

リスト 2 に、trext:LocationCountyCode 要素の宣言を記載します。この要素で nc:LocationCounty を置き換えられることを示すために、substitutionGroup 属性を使用しています。

リスト 2. trext:LocationCountyCode 要素および関連する型の宣言
<xsd:element name="LocationCountyCode" type="trext:CountyCodeType"
             substitutionGroup="nc:LocationCounty">
 <xsd:annotation>
  <xsd:documentation>A county code.</xsd:documentation>
 </xsd:annotation>
</xsd:element>

<xsd:simpleType name="CountyCodeSimpleType">
 <xsd:annotation>
  <xsd:documentation>A data type for a county code.</xsd:documentation>
  <xsd:appinfo>
    <i:Base i:namespace="http://niem.gov/niem/structures/2.0" i:name="Object"/>
  </xsd:appinfo>
 </xsd:annotation>
 <xsd:restriction base="xsd:token">
  <xsd:enumeration value="A">
    <xsd:annotation>
     <xsd:documentation>Ascot County</xsd:documentation>
    </xsd:annotation>
  </xsd:enumeration>
  <xsd:enumeration value="B">
    <xsd:annotation>
     <xsd:documentation>Burke County</xsd:documentation>
    </xsd:annotation>
  </xsd:enumeration>
  <xsd:enumeration value="C">
    <xsd:annotation>
     <xsd:documentation>Cross County</xsd:documentation>
    </xsd:annotation>
  </xsd:enumeration>
 </xsd:restriction>
</xsd:simpleType>

<xsd:complexType name="CountyCodeType">
 <xsd:annotation>
  <xsd:documentation>A data type for a county code.</xsd:documentation>
  <xsd:appinfo>
    <i:Base i:namespace="http://niem.gov/niem/structures/2.0" i:name="Object"/>
  </xsd:appinfo>
 </xsd:annotation>
 <xsd:simpleContent>
  <xsd:extension base="trext:CountyCodeSimpleType">
    <xsd:attributeGroup ref="s:SimpleObjectAttributeGroup"/>
  </xsd:extension>
 </xsd:simpleContent>
</xsd:complexType>

リスト 2 には、trext:LocationCountyCode 要素をサポートする 2 つの型も定義しています。最初に定義しているのは、コードの値ごとに xsd:enumeration 要素を持つ単純型です。次に、この単純型を基にして複合型を定義しています。複合型が追加する s:id などの汎用属性は、s:SimpleObjectAttributeGroup を参照することにより、すべての NIEM オブジェクトで使用することができます。

まったく新しい型を作成する

NIEM を拡張するには、まったく新しい型を作成するという方法もあります。NIEM モデルには、サンプル・モデルの Bicycle に相当するものがないため、新しい要素とそれに対応する新しい複合型を作成する必要があります。新しい型を追加する場合は必ず、既存の NIEM の型 (nc:ActivityTypenc:PersonTypenc:ItemType など) を特殊化した型にするかどうかを検討してください。Bicycle の場合、新しい型は nc:ConveyanceType をベースにすることにします。その理由は、この型が表すのは輸送手段なので、自転車 (Bicycle) にはちょうどよいからです。また、nc:ConveyanceType にはシリアル番号や説明など、この例に必要なプロパティーのほとんどがあることも理由となっています。

前の拡張方法と同じように、trext:Bicycle という新しい要素と、trext:BicycleType という新しい型の両方を定義する必要があります。リスト 3 にこれらの定義を記載します。

リスト 3. trext:Bicycle 要素および関連する型の宣言
<xsd:element name="Bicycle" type="trext:BicycleType">
 <xsd:annotation>
  <xsd:documentation>A bicycle.</xsd:documentation>
 </xsd:annotation>
</xsd:element>

<xsd:complexType name="BicycleType">
 <xsd:annotation>
  <xsd:documentation>A data type for a bicycle.</xsd:documentation>
 </xsd:annotation>
 <xsd:complexContent>
  <xsd:extension base="nc:ConveyanceType">
    <xsd:sequence>
     <xsd:element ref="trext:BicycleRegisteredIndicator" minOccurs="0" maxOccurs="1"/>
    </xsd:sequence>
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

trext:BicycleType 型の定義には、これが nc:ConveyanceType の継承であることが示されています。注意する点として、真に新しい型を作成する場合 (つまり、NIEM の既存の概念をベースとしない場合) には、NIEM のすべての複合型のルートである s:ComplexObjectType をベースに型を作成してください。

trext:BicycleType で参照している trext:BicycleRegisteredIndicator 要素については、別個に宣言する必要があります。NIEM スキーマのすべての要素、属性、型は、グローバルな固有名が付けられた最上位のコンポーネントとなります。trext:BicycleRegisteredIndicator 要素の宣言はリスト 4 のとおりです。

リスト 4. trext:BicycleRegisteredIndicator 要素の宣言
<xsd:element name="BicycleRegisteredIndicator" type="niem-xsd:boolean">
 <xsd:annotation>
  <xsd:documentation>Whether a bicycle is registered.</xsd:documentation>
 </xsd:annotation>
</xsd:element>

独自のコード・リスト型がある trext:LocationCountyCode とは異なり、trext:BicycleRegisteredIndicator には XML Schema 組み込み型の 1 つである boolean に対応する型があります。けれどもここでは、この要素に組み込み型 xsd:boolean を指定するのではなく、niem-xsd:boolean を指定しています。「プロキシー」スキーマ xsd.xsd に定義されているこの複合型は、要素がそこに含まれる xsd:boolean の値だけでなく、s:id などの汎用 NIEM 属性も許容するように指定します。

既存の型にプロパティーを追加する

型を拡張する際に、NIEM の型と意味的に等価な複合型に対して、何らかの形の変更または追加が必要になることもあります。サンプル・モデルの場合、MotorVehicle クラスは NIEM の nc:VehicleType に相当しますが、このクラスには VehicleCategoryCode というプロパティーも必要です。マッピングの段階で、nc:ItemCategoryText をマッピング候補として検討しましたが、これでは汎用的すぎると判断しました。実際、VehicleCategoryCode プロパティーは課税を目的とした車両の分類を表すため、この要素には trext:VehicleTaxClassCode という名前を付けることにします。

必要な XML Schema 定義は、Bicycle の拡張と同様です。リスト 5 に、trext:Vehicle という新しい要素と、nc:VehicleType を継承する新しい複合型、trext:VehicleType を宣言する方法を示します。

リスト 5. trext:Vehicle 要素および関連する型の宣言
<xsd:element name="Vehicle" type="trext:VehicleType">
 <xsd:annotation>
  <xsd:documentation>A motor vehicle.</xsd:documentation>
 </xsd:annotation>
</xsd:element>

<xsd:complexType name="VehicleType">
 <xsd:annotation>
  <xsd:documentation>A data type for a motor vehicle.</xsd:documentation>
 </xsd:annotation>
 <xsd:complexContent>
  <xsd:extension base="nc:VehicleType">
    <xsd:sequence>
     <xsd:element ref="trext:VehicleTaxClassCode" minOccurs="0" maxOccurs="1"/>
    </xsd:sequence>
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

既存の型を使用して新規オブジェクトを追加する

NIEM の型で十分必要は満たせるけれども、特定の情報交換に固有の名前、あるいはそれに関連した名前を使用したい場合もあります。私のサンプル・モデルでは、Theft クラスは NIEM の nc:ActivityType に対応すると判断しましたが、要素を nc:Activity という名前にするだけでは、あまりにも大まかすぎて説明が足りないため完全に満足できるわけではありません。この例では、trext:Theft という名前の新しい要素を宣言します。ただしこの要素には、新しい型を定義するのではなく、既存の nc:ActivityType 型を指定します。リスト 6 にこの要素の宣言を記載します。

リスト 6. trext:Theft 要素の宣言
<xsd:element name="Theft" type="nc:ActivityType">
 <xsd:annotation>
  <xsd:documentation>A theft incident.</xsd:documentation>
 </xsd:annotation>
</xsd:element>

交換スキーマ

交換スキーマには、メッセージ・タイプまたはメッセージ・タイプのグループに固有の定義が記載されます。通常、定義に含まれるのはルート要素とその型のみですが、場合によってはメッセージの基本フレームワークを形作る構造要素も含まれることがあります。拡張スキーマは複数の IEPD で共有される場合もありますが、交換スキーマは一般に IEPD に固有のものです。

交換スキーマと拡張スキーマをそれぞれ個別に用意する必要はありません。1 つのスキーマ文書にすべての拡張スキーマを含めることができます。また、異なるメッセージ・タイプや異なるメッセージ・タイプのグループを表すために複数の交換スキーマを使用することも可能です。

交換スキーマは、拡張スキーマのセクションで説明したすべてのルールに従います。例えば、固有のターゲット名前空間を持つこと、そしてアノテーションを持つことなどが要件となっています。

盗難報告書の例で交換スキーマに含めることになるのは、ルートである tr:TheftReport 要素とその型、そしてモデルに示されている TheftReportDate です。しかしそれよりも重要なことは、tr:TheftReport 要素が、情報交換モデルに定義されたオブジェクトと関連のすべてを 1 つにまとめるという点です。TheftReport の要素および型をリスト 7 に記載します。

リスト 7. tr:TheftReport 要素および関連する型の宣言
<xsd:element name="TheftReport" type="tr:TheftReportType">
 <xsd:annotation>
  <xsd:documentation>A theft report.</xsd:documentation>
 </xsd:annotation>
</xsd:element>

<xsd:complexType name="TheftReportType">
 <xsd:annotation>
  <xsd:documentation>A data type for a theft report.</xsd:documentation>
  <xsd:appinfo>
    <i:Base i:namespace="http://niem.gov/niem/structures/2.0" i:name="Object"/>
  </xsd:appinfo>
 </xsd:annotation>
 <xsd:complexContent>
  <xsd:extension base="s:ComplexObjectType">
    <xsd:sequence>
     <xsd:element ref="tr:TheftReportDate" minOccurs="1" maxOccurs="1"/>
     <xsd:element ref="trext:Theft" minOccurs="0" maxOccurs="unbounded"/>
     <xsd:element ref="nc:ActivityConveyanceAssociation"
                                    minOccurs="0" maxOccurs="unbounded"/>
     <xsd:element ref="trext:Vehicle" minOccurs="0" maxOccurs="unbounded"/>
     <xsd:element ref="trext:Bicycle" minOccurs="0" maxOccurs="unbounded"/>
     <xsd:element ref="j:ActivityLocationAssociation"
                                    minOccurs="0" maxOccurs="unbounded"/>
     <xsd:element ref="nc:Location" minOccurs="0" maxOccurs="unbounded"/>
     <xsd:element ref="j:ActivityVictimAssociation"
                                    minOccurs="0" maxOccurs="unbounded"/>
     <xsd:element ref="j:Victim" minOccurs="0" maxOccurs="unbounded"/>
     <xsd:element ref="j:ActivityWitnessAssociation"
                                    minOccurs="0" maxOccurs="unbounded"/>
     <xsd:element ref="j:Witness" minOccurs="0" maxOccurs="unbounded"/>
     <xsd:element ref="nc:Person" minOccurs="0" maxOccurs="unbounded"/>
    </xsd:sequence>
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

オブジェクトおよび関連要素はすべて、互いに兄弟の関係にある点に注意してください。これは NIEM メッセージに特有のことです。つまり、オブジェクト間の関連は別個のコンポーネントであり、s:ref 属性を使用して関連オブジェクトを参照します。

リスト 8 に、メッセージのなかで盗難と盗難場所の間の関連を示す部分を記載します。trext:Theft オブジェクトと nc:Location オブジェクトは兄弟で、そのそれぞれに、オブジェクト固有の ID を指定する s:id 属性があります。j:ActivityLocationAssociation 関連もこれらのオブジェクトの兄弟であり、s:ref 属性を持つ子要素によって、この 2 つのオブジェクトを関連付けています。

リスト 8. 関連を示すインスタンスの例
<trext:Theft s:id="T1">
  <nc:ActivityDate>
      <nc:DateTime>2006-05-04T08:15:00</nc:DateTime>
  </nc:ActivityDate>
</trext:Theft>

<j:ActivityLocationAssociation>
   <nc:ActivityReference s:ref="T1"/>
   <nc:LocationReference s:ref="L1"/>
</j:ActivityLocationAssociation>

<nc:Location s:id="L1">
  <nc:LocationAddress>
   <nc:StructuredAddress>
     <nc:LocationStreet>
       <nc:StreetFullText>123 Main Street</nc:StreetFullText>
     </nc:LocationStreet>
     <nc:LocationCityName>Big City</nc:LocationCityName>
     <trext:LocationCountyCode>A</trext:LocationCountyCode>
     <nc:LocationStateUSPostalServiceCode>MI</nc:LocationStateUSPostalServiceCode>
     <nc:LocationPostalCode>49684</nc:LocationPostalCode>
   </nc:StructuredAddress>
  </nc:LocationAddress>
</nc:Location>

オブジェクト間の関係を表現するには、包含という方法もあります。この場合、あるオブジェクトが別のオブジェクトの親となります。例えば仮定として、まったく新しい TheftType を作成し、そのなかに個人と場所、または個人や場所への参照を含めることも可能です。ただし、この方法は NIEM の使用法としては推奨されません。関連を分離したほうが、オブジェクトの表現が簡潔になり、再帰に伴う問題が減るからです。さらに、多対多の関係にも適応しやすくなります。


NIEM コンポーネントの命名および文書化

今まで記載した例で使用している名前には、何らかの一貫性があることにお気付きでしょう。NIEM では、名前に関して以下のルールに従わなければなりません。

  • 名前にはオブジェクトを表す語とプロパティーを表す語を含めます。単純な要素の場合には、さらに表現を表す語も含めます。例えば、BicycleRegisteredIndicator という名前の場合、Bicycle がオブジェクトを表す語、Registered がプロパティーを表す語、そして Indicator が表現を表す語です。オプションで修飾子を表す語を含めることもできます。
  • 表現を表す語には、認可されている特定の用語があります。例えば、Indicator、Code、Date、Text、Value、および Quantity などです。
  • すべての名前には区切り文字を使用せずに、キャメル・ケース形式を使用します (つまり、各単語の先頭文字を大文字にします)。
  • 属性の名前は小文字で始まり、要素と型の名前は大文字で始まります。
  • 型の名前はすべて、Type という単語で終わります。

上記の他に、NIEM コンポーネントの文書化に関して設けられたルールもあります。スキーマ、要素、属性、型、列挙はすべて定義を持たなければなりません。そしてそれらの定義は認可された開始フレーズのいずれか (「A name of (~の名前は)」、「A relationship (関係は)」など) で始まらなければなりません。

上記はルールのいくつかを抜粋しただけにすぎません。完全な NIEM ルールの一覧は、NDR に記載されています。


サブセットの変更

拡張スキーマと交換スキーマを作成しているうちに、サブセットに含めていないコンポーネントを NIEM からさらに追加する必要が出てくる場合もあります。例えば trext:BicycleRegisteredIndicator の型は niem-xsd:Boolean ですが、この型は作成済みのサブセットには含まれていません。

幸い、SSGT (Schema Subset Generation Tool) を使用すれば、簡単にサブセットを変更することができます。SSGT (リンクについては「参考文献」を参照) のメイン・ページで、右上隅にある「Options (オプション)」をクリックすると、図 2 に示すページが表示されます。

図 2. SSGT のオプション・ページ
SSGT のオプション・ページのスクリーン・キャプチャー

クリックして大きなイメージを見る

図 2. SSGT のオプション・ページ

SSGT のオプション・ページのスクリーン・キャプチャーの拡大バージョン

Load Wantlist (Wantlist のロード)」セクションに、wantlist.xml のファイル名を入力し (または参照して指定し)、「Load Want List (必要な項目をロード)」をクリックします。この操作によって、左側ペインに現在のサブセットが表示されます。この表示を基に、「Search (検索)」をクリックし、右側ペインを使用して NIEM サブセットにコンポーネントを追加することができます。作業が完了したら、サブセットをもう一度生成します。

サブセットを再生成する方法

サブセットを再生成する方法の詳細については、連載第 2 回の「NIEM サブセットの生成」を参照してください。

拡張を操作しているときに、SSGT を使用してプロパティーではなく、型を検索したいという場合もあります。niem-xsd:boolean を検索する場合、デフォルトによるプロパティーの検索を使用することはできません。デフォルトで検出されるのは要素名と属性名だけで、型の名前は検出されないからです。型を明確な検索対象とするには、SSGT の検索ページにある「Search for a (検索対象)」ドロップダウン・メニューから「Types (型)」を選択してください。


CMT でのマッピングの文書化

拡張は必ず、連載第 2 回で説明した CMT (Component Mapping Template) に文書化してください。少なくとも、拡張要素の XPath 式については入力する必要があります。表 1 に、MotorVehicle クラスと Bicycle クラスに関して入力した拡張を記載します。

表 1. 拡張用の XPath マッピング
ソースの型ソースのプロパティー...Ext?XPath
MotorVehicle...Ytrext:Vehicle
MotorVehicleLicensePlate...Ytrext:Vehicle/ nc:ConveyanceRegistrationPlateIdentification/ nc:IdentificationID
MotorVehicleVehicleCategory...Ytrext:Vehicle/ trext:VehicleTaxClassCode
Bicycle...Ytrext:Bicycle
BicycleIsRegistered...Ytrext:Bicycle/ trext:BicycleRegisteredIndicator

NIEM を利用している人のなかには、拡張の種類、基本型と要素、および意味的な一致レベルをそれぞれ別々の列に記載した正式な CMT を作成する人もいますが、サンプル CMT ではそれよりも大まかな手法を採用し、これらの情報を「Comments (コメント)」列に含めることによって依存関係を定義しています。完成版の Theft Report CMT は、「ダウンロード」から入手してください。


まとめ

今回の記事では、NIEM を拡張するプロセスを取り上げ、拡張スキーマと交換スキーマの役割を説明し、NIEM コンポーネントをベースに新しい要素と型を追加するさまざまな方法を紹介しました。この時点で、NIEM IEPD を作成する作業の大半は完了しています。第 4 回では、いよいよ最後のステップ、IEPD のアセンブルを取り上げ、IEPD を構成する各種の成果物について説明し、プロセスの最終結果として NIEM 準拠のTheft Report IEPD を完成させます。


ダウンロード

内容ファイル名サイズ
Component Mapping Template (CMT)niem3mapping.zip26KB
NIEM Exchange, Extension and Subset Schemasniem3schemas.zip17KB

参考文献

学ぶために

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=XML
ArticleID=480475
ArticleTitle=NIEM IEPD を作成する: 第 3 回 NIEM の拡張
publish-date=03182010