スキーマ文書を使用する XML 文書

XML スキーマ は、XML 文書のテンプレート (スキーマ) を定義するためにスキーマ文書 (.xsd 拡張子) を使用する XML 文書用データ・モデルです。DTD とは異なり、スキーマ文書は、スキーマを記述するために、XML 文書と同じ構文を使用します。XML 文書のスキーマを表すビジネス・オブジェクト定義は、文書の構造を保存および記録するために、スキーマ文書内の情報を使用します。このセクションでは、ビジネス・オブジェクト定義に対応する構造情報のスキーマ文書からの引き出しに関する次の内容について説明します。

スキーマ文書に基づくビジネス・オブジェクト定義の要件

スキーマ文書を表すビジネス・オブジェクト定義が XML データ・ハンドラーの要件に適合していることを確認するには、このセクションで示すガイドラインを使用します。ガイドラインは次のように構成されています。

スキーマ文書のビジネス・オブジェクト構造

スキーマ文書に基づき、ビジネス・オブジェクト定義を使用して XML データ・ハンドラーにより処理されるビジネス・オブジェクトは、次の規則に準拠していることが必要です。

XML 文書用のスキーマ文書の例を図 18 に示します。 このスキーマ・文書の名前は Order で、アプリケーション Order エンティティーに対応するエレメントを格納しています。このスキーマ文書のサンプルは、前述の DTD 文書のサンプルと同じビジネス・オブジェクト 構造を記述しています。図 13 に、Order スキーマ文書 に関連する XML 文書に対応して作成されることがあるビジネス・オブジェクト定義の構造を示します。

図 18. XML スキーマ文書のサンプル

<?xml version="1.0" encoding="UTF-8"?>
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
         elementFormDefault="qualified">
 
        <xs:complexType name="AccessoryType">
                 <xs:sequence>
                         <xs:element ref="Quantity"/>
                         <xs:element ref="Type"/>
                 </xs:sequence>
                 <xs:attribute name="Name" type="xs:string" use="required"/>
         </xs:complexType>
         <xs:element name="Order">
                 <xs:complexType>
                         <xs:sequence>
                                 <xs:element name="Unit" type="UnitType"
                     maxOccurs="unbounded"/>
                         </xs:sequence>
                 </xs:complexType>
         </xs:element>
         <xs:element name="PartNumber" type="xs:string"/>
         <xs:element name="Price" type="xs:string"/>
         <xs:element name="Quantity" type="xs:string"/>
         <xs:element name="Type" type="xs:string"/>
         <xs:complexType name="UnitType">
                 <xs:sequence>
                         <xs:element ref="PartNumber" minOccurs="0"/>
             <xs:element ref="Quantity"/>
             <xs:element ref="Price"/>
             <xs:element name="Accessory" type="AccessoryType" minOccurs="0"
                    maxOccurs="unbounded"/>
                 </xs:sequence>
     </xs:complexType>
 </xs:schema>
 

スキーマ文書に必要なビジネス・オブジェクト定義

スキーマ文書を表すには、少なくともビジネス・オブジェクトの構造で説明 した 2 つのビジネス・オブジェクト定義が必要です。スキーマ文書では、これらのビジネス・オブジェクト定義に以下の追加要件があります。

注:
ビジネス・オブジェクトの一般要件のリストについては、ビジネス・オブジェクト定義の要件を参照してください。

これらの必須のビジネス・オブジェクト定義には、ターゲット・ネーム・スペースおよびコンポーネント名の制限を定義する、ビジネス・オブジェクト・レベルのアプリケーション固有情報が必要です。詳細については、ビジネス・オブジェクト・レベルのアプリケーション固有情報を参照してください。

図 18 の XML schema エレメントは次のとおりです。

<?xml version="1.0" encoding="UTF-8"?>
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
         elementFormDefault="qualified">
 

図 19 に、このスキーマ・エレメントを表すトップレベル・ビジネス・オブジェクト定義 TopLevel を示します。

図 19. トップレベル・ビジネス・オブジェクト定義のサンプル

[BusinessObjectDefinition]
 Name=TopLevel
 AppSpecificInfo=elem_fd=qualified;attr_fd=unqualified
 ...
 
   [Attribute]
    Name=XMLDeclaration
    Type=String
    AppSpecificInfo=type=pi;
    ...
    [End]
 
   [Attribute]
    Name=Order
    Type=TopLevel_Order
    AppSpecificInfo=elem_name=Order;
    ...
    [End]
 ...
 [End]
 

XML ODA が図 19 のトップレベル・ビジネス・オブジェクト定義を生成した場合、次の ODA 構成プロパティーが設定されて います。
ODA 構成プロパティー プロパティーの値
BOPrefix 設定なし
TopLevel "TopLevel"
Root "Order"
DoctypeorSchemaLocation true

root エレメント・ビジネス・オブジェクト定義の例は、図 26 を参照してください。

スキーマ文書に基づく通常のビジネス・オブジェクト定義

通常の ビジネス・オブジェクト定義は、次の XML 構造のいずれかを表します。

このタイプのビジネス・オブジェクト定義では、ビジネス・オブジェクト・レベルのアプリケーション固有情報に特別な情報は必要ありません。通常のビジネス・オブジェクト定義の属性は、XML 複合タイプ内に定義されているエレメントを 表します。

注:
子エレメントの sequence グループを持つ複合タイプの場合、sequence グループ内の各子エレメントは、ビジネス・オブジェクト定義の中では属性として表現されます。

例えば、Unit という XML エレメントが次のように定義されていると仮定します。

<xsd:element name="Unit">
     <xsd:complexType>
     ...
     </xsd:complexType>
 </element>
 

次のビジネス・オブジェクト定義は、Unit エレメントを表します。

[BusinessObjectDefinition]
 Name = MyApp_Unit
 AppSpecificInfo =
 [Attribute]
    ...
 

スキーマ文書に基づく混合ビジネス・オブジェクト定義

混合 ビジネス・オブジェクト定義は、文字データおよびその他のサブエレメントが混合した内容を格納している混合 XML エレメントを表します。スキーマ文書は、混合タイプの XML エレメントを、次のように、mixed 属性が true に設定された複合タイプとして記述します。

<xsd:complexType mixed="true">
     <xsd:sequence>
         <xsd:element name="subElement1" type="subElementType"/>
         ...
     </xsd:sequence>
 </xsd:complexType>
 

注:
このセクションで説明する混合ビジネス・オブジェクトは、エレメントと文字データの繰り返しリスト用に使用されます。選択リストに文字データが含まれない場合には、修飾されたコンポーネント名 で説明するラッパー・ビジネス・オブジェクトを使用してください。

この複合タイプでは mixed 属性が true に設定されるため、このタイプにより定義される 1 つ以上のサブエレメントの他に文字データを格納することができます。mixed 属性が false に設定されている複合タイプの場合、文字データを入れることはできません。

図 20 に、スキーマ文書で定義される混合タイプの XML エレメントの例を示します。

図 20. 混合タイプの XML エレメント用のスキーマ文書サンプル

<xsd:complexType name="Cust" mixed="true">
     <xsd:sequence>
         <xsd:element name="Name"/>
         <xsd:element name="Address"/>
         <xsd:element name="Phone"/>
     </xsd:sequence>
 </xsd:complexType>
 

混合タイプの XML エレメントを表すには、次の 2 つのビジネス・オブジェクト定義 が必要です。

ビジネス・オブジェクト定義 MyApp_Cust が、図 20 に示した Cust 混合タイプ・エレメントを表す場合、そのアプリケーション固有情報は次のようになります。

[BusinessObjectDefinition]
 Name = MyApp_Cust
 AppSpecificInfo = type=MIXED;
  
    [Attribute]
    Name=Cust_wrapper1
    Type=MyApp_CustWrapper1
    Cardinality=n
    AppSpecificInfo=(Cust|Address|Phone)
    ...
    [End]
 

スキーマ文書に基づくラッパー・ビジネス・オブジェクト定義

ラッパー・ビジネス・オブジェクト定義は、繰り返し選択リストを表します。このタイプのビジネス・オブジェクト定義は、XML エレメントに任意の順序と任意のカーディナリティーになり得る子がある場合に必要です。ラッパー・ビジネス・オブジェクトは、子エレメントの順序とカーディナリティーを特定の XML 文書に保存します。

注:
このセクションで説明するラッパー・ビジネス・オブジェクトは、エレメントを含み、文字データは含まない 繰り返し選択リスト用に使用されます。選択リストの文字データが含まれる場合には、混合ビジネス・オブジェクトを使用してください。詳細については、スキーマ文書に基づく混合ビジネス・オブジェクト定義を参照してください。

スキーマ文書は、選択リストの XML エレメントを、次のモデル・グループのいずれかを含む複合タイプとして記述することができます。

カーディナリティーを指示するため、これらのモデル・グループでは、minOccurs および maxOccurs 属性により、出現の制限をサポートしています。詳細については、表 18を参照してください。

スキーマ文書内の XML エレメント定義の例を次に示します。

<xsd:element name="CUST">
     <xsd:complexType>
         <xsd:choice minOccurs="0" maxOccurs="unbounded">
             <xsd:element ref="U"/>
             <xsd:element ref="I"/>
             <xsd:element ref="B"/>
         </xsd:choice>
     </xsd:complexType>
 </xsd:element>
 

このエレメントには 3 つのオプションのサブエレメントが含まれ (ただしリストのサブエレメントが必ず 1 つは存在しなければなりません)、その出現順序は任意です。図 14 に、このタイプの XML 文書を示します。図 16 に、この XML 文書に対応する親ビジネス・オブジェクト定義を示します。図 17 に、ラッパー・ビジネス・オブジェクト定義を示します。

スキーマ文書に基づく混合ビジネス・オブジェクト定義における型置換

型置換 によって、個々の XML 文書インスタンス内で基本タイプの代わりに派生型を使用できます。型置換が行われると、1 つのデータ型を用いた宣言に適合するエレメントは、それを拡張または制限する任意のデータ型を持つことができます。以下のスキーマ定義では、ShirtType および HatType は基本的な ProductType の派生型です。

図 21. 型置換を用いたスキーマのサンプル

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <xsd:element name="items" type="ItemsType"/>
 <xsd:complexType name="ItemsType">
   <xsd:sequence>
             <xsd:element ref="product" maxOccurs="unbounded"/>
           </xsd:sequence>
 </xsd:complexType>
 <xsd:element name="product" type="ProductType"/>
 <xsd:complexType name="ProductType">
     <xsd:sequence>
           <xsd:element name="number" type="xsd:string"/>
             <xsd:element name="name" type="xsd:string"/>
       </xsd:sequence>
 </xsd:complexType>
 <xsd:complexType name="ShirtType">
     <xsd:complexContent>
     <xsd:extension base="ProductType">
           <xsd:sequence>
                 <xsd:element name="size" type="xsd:string"/>
                 <xsd:element name="color" type="xsd:string"/>
           </xsd:sequence>
     </xsd:extension>
     </xsd:complexContent>
 </xsd:complexType>
 <xsd:complexType name="HatType">
     <xsd:complexContent>
     <xsd:extension base="ProductType">
       <xsd:sequence>
                 <xsd:element name="size" type="xsd:string"/>
               </xsd:sequence>
             </xsd:extension>
         </xsd:complexContent>
     </xsd:complexType>
 </xsd:schema>
 

上記のスキーマを基にした場合、以下の XML 文書が有効です。

図 22. XML 文書内の派生型

<items xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <product>
       <number>999</number>
       <name>Special Seasonal</name>
 </product>
 <product xsi:type="ShirtType">
       <number>557</number>
       <name>Short-Sleeved Linen Blouse</name>
       <size>M</size>
       <color>blue</color>
 </product>
 <product xsi:type="HatType">
       <number>443</number>
       <name>Four-Gallon Hat</name>
       <size>L</size>
 </product>
 </items>
 

ProductType が出現する箇所では、その派生型の ShirtType および HatType (xsi:type 属性によって表される) を代わりに使用することができます。型置換が行われる XML 文書を表すため、XML データ・ハンドラーは、ラッパー・ビジネス・オブジェクトを XML 文書の子の属性として作成します。このラッパー・ビジネス・オブジェクトは、複合型 (図 21 内の ProductType) およびその派生型 (ShirtType および HatType) に対応する子の属性を持ちます。表 16 および表 17 に、前述の XML スキーマから生成されるビジネス・オブジェクト定義を示します。

表 16. ItemsType のビジネス・オブジェクト定義
属性名 カーディナリティー ASI
Product ProductTypeWrapper N (product);typeSub=true

表 17. ProductTypeWrapper のビジネス・オブジェクト定義
属性 カーディナリティー ASI
ProductType ProductType 1 Elem_name=product;
xsiType=ProductType
ShirtType ShirtType 1 Elem_name=product;
xsiType=ShirtType;
HatType HatType 1 Elem_name=product;
xsiType=HatType;

スキーマ文書のビジネス・オブジェクト属性プロパティー

XML 文書用のビジネス・オブジェクト定義がスキーマ文書に基づいている場合、ビジネス・オブジェクト属性プロパティーには、ビジネス・オブジェクトの属性プロパティーで説明した制約があります。さらに、スキーマ文書の構文により、ビジネス・オブジェクト属性の「必須性」が決まる場合があります。

「必須性」とは、カーディナリティーや属性がキーであるかどうかなどの要因の組み合わせであり、XML データ・ハンドラーがその属性を必要とするかどうかを指定します。属性が必須な場合には、Required 属性プロパティーを true に設定することが必要です。

Required 属性プロパティーの設定は、以下に示すように、XML エレメントおよび属性の指定のほか、Cardinality、Key、および Foreign Key 属性プロパティーの設定に依存します。

スキーマ文書内の XML コンポーネントのアプリケーション固有情報

このセクションでは、スキーマ文書に基づくビジネス・オブジェクト定義のためのアプリケーション固有情報フォーマットの次の内容について説明します。

ビジネス・オブジェクト・レベルのアプリケーション固有情報

XML データ・ハンドラーは次のタイプのビジネス・オブジェクト定義を使用して、スキーマ文書に定義されている異なる種類の root XML エレメントを表します。これらのビジネス・オブジェクト定義のタイプは、ビジネス・オブジェクト・レベルでアプリケーション固有情報により識別されます。

表 21. ビジネス・オブジェクト・レベルのアプリケーション固有情報のタグ
アプリケーション
固有情報内のタグ
説明 詳細
target_ns スキーマ文書のターゲット・ネーム・スペースを指定します。 スキーマ・ネーム・スペース
attr_fd 属性名を修飾するかどうかを指定します。 修飾されたコンポーネント名
elem_fd ローカルに宣言されたエレメント名を修飾するかどうかを指定します。 修飾されたコンポーネント名

注:
ビジネス・レベルのアプリケーション固有情報には、type=MIXED タグを組み込むこともできます。詳細については、スキーマ文書に基づく混合ビジネス・オブジェクト定義を参照してください。

スキーマ・ネーム・スペース

DTD とは異なり、スキーマ文書は、1 つ以上のネーム・スペースの定義を必要とします。ネーム・スペース は、XML 文書内のエレメント名、エレメント・タイプ、および属性のコンテキストを規定します。ネーム・スペースは Uniform Resource Identifier (URI) であり、HTTP、FTP、およびその他のパスが含まれます。表 22 に、スキーマ・コンポーネント間で参照を解決するためにスキーマ文書で宣言できるネーム・スペースを示します。

表 22. XML ネーム・スペース
ネーム・スペース 説明 名前 共通プレフィックス
XML スキーマ・ネーム・スペース XML スキーマ定義言語 (XSDL) で使用される elementschemasimpleType などすべてのコンポーネントを定義します。
http://www.w3.org/2001/
 XMLSchema
 
xsdxs
XML スキーマ・インスタンス・ネーム・スペース スキーマ・インスタンスに関連付けられた 4 つの 属性 typenilschemaLocationnoNamespaceSchemaLocation を 定義します。
http://www.w3.org/2001/
 XMLSchema-instance
 
xsi
ユーザー定義のネーム・スペース

グローバル宣言により宣言または定義されたすべてのコンポーネント (elementattributetypegroup など) を定義します。

注:
ローカルに宣言されたエレメントでは、ターゲット・ネーム・スペースを使用する場合と、しない場合があります。詳細については、修飾されたコンポーネント名を参照してください。
ユーザー定義 ユーザー定義

注:
XML ODA は、複数のターゲット・ネーム・スペースを持つスキーマ文書をサポートしています。

各スキーマ文書では 1 つのターゲット・ネーム・スペース を宣言でき、targetNamespace タグを使用して、ネーム・スペースがどのグローバル・コンポーネント (エレメント、属性、タイプ、またはグループ) に属するか を指定します。 スキーマ・エレメントに targetNamespace タグを設定する場合、そのスキーマ文書用に生成された各ビジネス・オブジェクト定義のアプリケーション固有情報に target_ns タグを設定して、XML 文書で宣言されたターゲット・ネーム・スペースを指定する必要があります。

target_ns=URI address for target namespace
 

target_ns タグは、次のようにしてすべての ビジネス・オブジェクト定義のビジネス・オブジェクト・レベルのアプリケーション固有情報に設定する必要があります。

注:
以前のバージョンの XML データ・ハンドラーでは、トップレベル・ビジネス・オブジェクト定義にネーム・スペース・プレフィックスの属性を設定し、属性レベルのアプリケーション固有情報に適切な type=defaultNS タグ と type=xmlns タグを使用する必要がありました。

このようにネーム・スペース・プレフィックスを定義する仕組みは置き換えられましたが、XML データ・ハンドラーは、既存のビジネス・オブジェクト定義との後方互換性のためにこの仕組みのサポートを継続しています。新規のビジネス・オブジェクト定義では、このセクションで説明したように target_ns タグを使用します。XML ODA は、target_ns タグを使用するよう変更されました。

例えば、図 23 のスキーマ文書は、(xsd プレフィックス を持つ) XML スキーマ・ネーム・スペースとターゲット・ネーム・スペース (デフォルトのネーム・スペース) を 記述しています。

図 23. スキーマ文書のサンプル Schema1.xsd

<?xml version="1.0" encoding="UTF-8"?>
 <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://www.ibm.com/ns1" xmlns="http://www.ibm.com/ns1">
 
   <xsd:complexType name="TaxInfoType">
       <xsd:sequence>
          <xsd:element name="SSN" type="string">
          </xsd:element>
 
         <xsd:element name="State" type="string">
          </xsd:element>
       </xsd:sequence>
    </xsd:complexType>
 
   <xsd:element name="Customer">
       <xsd:complexType>
          <xsd:sequence>
             <xsd:element name="TaxInfo" type="TaxInfoType">
             </xsd:element>
 
            <xsd:element name="BillTo" type="xsd:string">
             </xsd:element>
          </xsd:sequence>
 
         <xsd:attribute name="Name" type="xsd:string">
          </xsd:attribute>
 
         <xsd:attribute name="ID" type="xsd:string">
          </xsd:attribute>
       </xsd:complexType>
    </xsd:element>
 </xsd:schema>
 

XML ODA は、このスキーマ文書に対して BOPrefix_TopLevelBOPrefix_TopLevel_Customer、および BOPrefix_TopLevel_TaxInfoType という 3 つのビジネス・オブジェクト定義を生成します (ここで、BOPrefix および TopLevel はこれらの ODA 構成プロパティーの値です)。これらの 3 つのビジネス・オブジェクト定義では、ビジネス・オブジェクト・レベルのアプリケーション固有情報に次の行が設定されます。

target_ns=http://www.ibm.com/ns1;elem_fd=unqualified;attr_fd=unqualified
 

注:
図 23schema エレメント には elementFormDefault 属性も attributeFormDefault 属性も含まれていないので、このアプリケーション固有情報には unqualified に設定 した elem_fd タグと attr_fd タグが組み込まれます。詳細については、修飾されたコンポーネント名を参照してください。

1 つのスキーマ文書では 1 つのターゲット・ネーム・スペースのみを定義できます。ただし、import エレメントを使用すると、別のスキーマ文書のターゲット・ネーム・スペースで定義されたエレメントや属性を組み込むことができます。

図 23 で定義した Schema1.xsd 文書に基づくスキーマ文書を図 24 に示します。このスキーマ文書は、TaxInfoType 複合タイプ、BillTo エレメント、および Name 属性を宣言する ns2 ネーム・スペースをインポート します。

図 24. ターゲット・ネーム・スペースのインポート

<?xml version "1.0" encoding="UTF-8"?>
 <xsd:schema smlns:xsd="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://www.example.com/ns1" xmlns="http://www.example.com/ns1"
    attributeFormDefault="qualified" elementFormDefault="qualified"
    xmlns:ns2="http://www.example.com/ns2">
 
   <xsd:import schemaLocation="Schema2.xsd"
       namespace="http://www.example.com/ns2"/>
 
   <xsd:element name="Customer2">
       <xsd:complexType>
          <xsd:sequence>
             <xsd:element name="TaxInfo" type="ns2:TaxInfoType">
             </xsd:element>
 
            <xsd:element ref="ns2:BillTo">
             </xsd:element>
          </xsd:sequence>
 
         <xsd:attribute ref="ns2:Name">
          </xsd:attribute>
 
         <xsd:attribute name="ID" type="xsd:string">
          </xsd:attribute>
       </xsd:complexType>
    </xsd:element>
 </xsd:schema>
 

root エレメントのビジネス・オブジェクト定義 Customer2 は、TaxInfo、BillTo、および Name XML コンポーネントを表す属性に、この代替ネーム・スペースを次のように指定する必要があります。

図 25 に、ns2 ネーム・スペース 内の TaxInfoTypeBillTo、および Name XML コンポーネント を定義するスキーマ文書を示します。

図 25. 2 番目のネーム・スペースの定義

<?xml version "1.0" encoding="UTF-8"?>
 <schema smlns:xsd="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://www.example.com/ns2"
    attributeFormDefault="qualified" elementFormDefault="qualified"
    xmlns:ns2="http://www.example.com/ns2">
 
   <complexType name="TaxInfoType">
       <sequence>
          <element name="SSN" type="string">
          </element>
          <element name="State" type="string">
          </element>
       </sequence>
    </complexType>
 
   <attribute name="Name" type="string"
    </attribute>
 
   <complexType name="AddressType">
       <sequence>
          <element name="Zip" type="string">
          </element>
          <element name="Street" type="string">
          </element>
       </sequence>
    </complexType>
 
   <element name="BillTo" type="ns2:AddressType">
    </element>
 </schema>
 

図 25 に、Customer2 root エレメントのビジネス・オブジェクト定義を示します。

図 26. root エレメント・ビジネス・オブジェクト定義のサンプル

[BusinessObjectDefinition]
 Name=TopLevel_Customer2
 AppSpecificInfo=target_ns=http://www.example.com/ns1;elem_fd=qualified;
    attr_fd=qualified
 ...
 
   [Attribute]
    Name=Name
    Type=String
    AppSpecificInfo=attr_name=Name;type=attribute;attr_ns=http://www.example.com/ns2
    ...
    [End]
 
   [Attribute]
    Name=ID
    Type=String
    AppSpecificInfo=attr_name=ID;type=attribute
    ...
    [End]
 
   [Attribute]
    Name=schemaLocation
    Type=String
    AppSpecificInfo=attr_name=schemaLocation;type=xsischemalocation
    ...
    [End]
 
   [Attribute]
    Name=TaxInfo
    Type=TopLevel_TaxInfoType
    AppSpecificInfo=elem_name=TaxInfo
    ...
    [End]
 
   [Attribute]
    Name=BillTo
    Type=TopLevel_AddressType
    AppSpecificInfo=elem_name=BillTo;elem_ns=http://www.example.com/ns2
    ...
    [End]
 ...
 [End]
 

修飾されたコンポーネント名

XML 文書の中で、ネーム・スペースに関連付けられたコンポーネント名は、次のように修飾されるか、または修飾されません。

schema エレメントの elementFormDefault 属性は、ローカルに宣言されたエレメント名を修飾するかどうかを指定します。 デフォルトでは、ローカルに宣言されたエレメントは修飾されず、デフォルトのネーム・スペースに属します。 表 23 に示すように、elementFormDefault 属性の値は、ビジネス・オブジェクト・レベルのアプリケーション固有情報内の elem_fd タグの値を決定します。

表 23. elem_fd タグの設定
elementFormDefault の値 elem_fd タグの値
"unqualified" (または属性がまったく指定されない) elem_fd=unqualified
"qualified" elem_fd=qualified

例えば、図 23 のスキーマ文書の schema エレメントには、elementFormDefault 属性は含まれません。したがって、このスキーマ文書のすべて のビジネス・オブジェクト定義のビジネス・オブジェクト・レベルのアプリケーション固有情報 (BOPrefix_TopLevelBOPrefix_TopLevel_Customer、および BOPrefix_TopLevel_TaxInfoType。ここで、BOPrefixTopLevel は これらの ODA 構成プロパティーの値) には、次のタグが含まれます。

elem_fd=unqualified
 

注:
スキーマ文書の schema エレメントに次の属性が含まれる場合、これらの 3 つのビジネス・オブジェクト定義のビジネス・オブジェクト・レベルのアプリケーション固有情報には、これと同じタグが含まれます。
elementFormDefault="unqualified"
 

個々の XML エレメントに form 属性が含まれる場合、この form 属性 の値は elementFormDefault 属性のすべての設定をオーバーライドします。

schema エレメントの attributeFormDefault 属性は、エレメント名を修飾するかどうかを指定します。 デフォルトでは、属性名は修飾されず、いずれのネーム・スペースにも 属しません。表 24 に示すように、attributeFormDefault 属性の値は、ビジネス・オブジェクト・レベルのアプリケーション固有情報の attr_fd タグの値を決定します。これは、elementFormDefault 属性の値が elem_fd タグ の値を決定するのと同様です。

表 24. attr_fd タグの設定
attributeFormDefault の値 elem_fd タグの値
"unqualified" (または属性がまったく指定されない) attr_fd=unqualified
"qualified" attr_fd=qualified

例えば、図 23 のスキーマ文書の schema エレメントには、attributeFormDefault 属性は含まれません。したがって、このスキーマ文書のすべて のビジネス・オブジェクト定義のビジネス・オブジェクト・レベルのアプリケーション固有情報 (BOPrefix_TopLevelBOPrefix_TopLevel_Customer、および BOPrefix_TopLevel_TaxInfoType。ここで、BOPrefixTopLevel は これらの ODA 構成プロパティーの値) には、次のタグが含まれます。

attr_fd=unqualified
 

注:
スキーマ文書の schema エレメントに次の属性が含まれる場合、これらの 3 つのビジネス・オブジェクト定義のビジネス・オブジェクト・レベルのアプリケーション固有情報には、これと同じタグが含まれます。
attributeFormDefault="unqualified"
 

属性アプリケーション固有情報

ビジネス・オブジェクト定義の属性は、以下の XML コンポーネントを表すことができます。

表 25 に、これらのさまざまな XML コンポーネントの属性レベルのアプリケーション固有情報のタグと、タグの詳細が記載されている本書のセクションを示します。

表 25. 属性のアプリケーション固有情報のタグ
ビジネス・オブジェクト属性の表現 アプリケーション固有情報 詳細
XML エレメント

elem_name=name of XML element

elem_ns=namespace for element's definition

elem_fd=value of form attribute

XML エレメントの場合
複合タイプの XML エレメント

type=pcdata

複合タイプの XML エレメントの場合
XML エレメントの属性

attr_name=name of XML attribute

type=attribute

attr_ns=namespace for attribute's definition

attr_fd=value of form attribute

XML 属性の場合
特殊文字を持つ XML エレメントまたは属性

escape=true

特殊文字が含まれる XML エレメントまたは属性の場合
XML 文書に追加されるコメント type=comment XML コメントの場合
処理命令 type=pi XML 処理命令の場合
XML インスタンスの schemaLocation または noNamespaceSchemaLocation 属性

type=xsischemalocation

type=xsinoNSlocation

XML スキーマ・ロケーションの場合

注:
属性のアプリケーション固有情報には、( a | b | c ) という形式のタグを使用して、反復選択を表す複数カーディナリティーの属性を指定することもできます。詳細については、スキーマ文書に基づくラッパー・ビジネス・オブジェクト定義を参照してください。

XML エレメントの場合

ビジネス・オブジェクト属性が XML エレメントを表す場合、アプリケーション固有情報に次の elem_name タグを設定して、関連するエレメントを識別する必要があります。

elem_name=name of XML element
 
 

XML エレメント名には特殊文字 (ピリオドやハイフンなど) を使用できます。ただし、ビジネス・オブジェクト属性名にこれらの特殊文字を使用することはできません。したがって、XML エレメント名 を elem_name タグに指定する必要があります。ビジネス・オブジェクト属性に名前を付けるとき、XML ODA は XML エレメントの名前から特殊文字を除去します。

ビジネス・オブジェクト属性は、次の場合に XML エレメントを表すことができます。

XML エレメントを表すビジネス・オブジェクト属性は、そのアプリケーション固有情報に、次のタグも組み込むことができます。

複合タイプの XML エレメントの場合

ビジネス・オブジェクト定義が XML 複合タイプ (complexType) を表す場合、この複合タイプの内容は、このビジネス・オブジェクト定義内の単純 (String) 属性 によって表されます。

これらのビジネス・オブジェクト属性のアプリケーション固有情報には、elem_name タグ を組み込んで、エレメント名を指定する必要があります

注:
このタグの詳細については、XML エレメントの場合を参照してください。

XML 複合タイプでは、ビジネス・オブジェクト属性は表 26 に 示す複合タイプの内容を表すことができます。

表 26. XML 複合タイプの内容
複合タイプのエレメントのタイプ 説明 属性のアプリケーション固有情報
単純な XML エレメント 文字のみ を含むエレメント。他のエレメントや XML 属性は格納できません。これが可能なのは複合タイプに限られます。 type=pcdata
単純な内容 文字データのみ (エレメントなし)。 type=pcdata;notag
属性を持つ XML エレメント 文字データおよび サブエレメントと属性の組み合わせの両方 を含むエレメント。

なし。

このタイプの XML エレメントは、単一のビジネス・オブジェクト属性としてではなく、ビジネス・オブジェクト定義を使用して表す必要があります。詳細については、スキーマ文書に基づく通常のビジネス・オブジェクト定義を参照してください。

type=pcdata タグを使用する例として、図 23 の スキーマ文書には、単純な XML エレメントのみを持つ TaxInfoType 複合タイプ の定義が含まれます。 TaxInfoType XML 複合タイプのビジネス・オブジェクト定義 (BOPrefix_TopLevel_TaxInfoType。ここで BOPrefixTopLevel は、それぞれの名前を持つ ODA 構成プロパティー の値) には、2 つの属性が含まれます。各属性のアプリケーション固有情報 には、図 27 に示すように、関係する XML エレメントの名前が含まれます。この複合タイプには単純な XML エレメントのみが含まれる (サブエレメントや 属性は含まれない) ので、対応するビジネス・オブジェクト属性のアプリケーション固有情報 に type=pcdata タグも設定する必要があります。

図 27. 単純なエレメントを持つ XML 複合タイプのビジネス・オブジェクト定義のサンプル

[BusinessObjectDefinition]
 Name=BOPrefix_TopLevel_TaxInfoType
 AppSpecificInfo=target_ns=;elem_fd=unqualified;attr_fd=unqualified
 ...
 [End]
 
[Attribute]
 Name=SSN
 Type=String
 AppSpecificInfo=elem_name=SSN;type=pcdata
 ...
 [End]
 
[Attribute]
 Name=State
 Type=String
 AppSpecificInfo=elem_name=SSN;type=pcdata
 ...
 [End]
 

notag キーワードを type=pcdata タグとともに使用する例として、Price という XML エレメントが PriceType 複合タイプであり、単純な内容のみ、つまり文字データのみが含まれると仮定します。 この例で、simpleContent エレメントには Currency という名前 の属性が定義され、Price 用のデータが必要です。

<xsd:element name="Price" type="PriceType">
     <xsd:complexType name="PriceType">
         <xsd:simpleContent>
             <xsd:extension base="xsd:decimal">
                 <xsd:attribute name="Currency" type="xsd:NMTOKEN"/>
             </xsd:extension>
         </xsd:simpleContent>
     </xsd:complexType>
 </element>
 

PriceType 複合タイプのビジネス・オブジェクト定義には、単純な内容に関連付けられた文字データを保持するための属性が設定されています。この属性のアプリケーション固有情報には、次のタグを設定する必要があります。

type=pcdata;notag
 

notag キーワードにより、XML データ・ハンドラーによる開始タグの重複生成 (ビジネス・オブジェクト定義用と属性用) を防止できます。 XML データ・ハンドラーは、ビジネス・オブジェクト属性ごとに XML 開始タグと終了タグを作成します。ただし、この属性のアプリケーション固有情報に notag が指定されている場合にはタグの作成はありません。

Price 子ビジネス・オブジェクト定義は、次のようになります。

[BusinessObjectDefinition]
 Name = Price
 AppSpecificInfo =
  
 [Attribute]
 Name = Currency
 Type = String
 AppSpecificInfo = attr_name=Currency;type=attribute;
 ...
 [End]
  
 [Attribute]
 Name = Price
 Type = String
 AppSpecificInfo = elem_name=Price;type=pcdata;notag
 ...
 [End]
 

Price データを保持するにはビジネス・オブジェクト属性が必要です。Price データの属性には、そのアプリケーション固有情報に notag を指定して、データ・ハンドラーがこの属性の開始および終了タグを作成しないようにする必要があります。この場合、データ・ハンドラーは、Price データの新しい XML エレメントは生成せず、データを親エレメントに追加するだけです。

さらに、ビジネス・オブジェクト定義には、Currency 属性値を保持するための別の属性が必要です。単純な内容に属性が格納されている場合には、ビジネス・オブジェクト定義に、各 XML 属性に対応する属性も設定されていることが必要です。 属性のアプリケーション固有情報には、type=attribute タグが設定されていることが必要です。 詳細については、XML 属性の場合を参照してください。

XML 属性の場合

ビジネス・オブジェクト定義が XML エレメントまたは複合タイプを表す場合、スキーマ文書がこのエレメント用に宣言するすべての属性は、ビジネス・オブジェクト定義内の属性として表す必要があります。ビジネス・オブジェクト属性が XML エレメントの属性を表す場合、アプリケーション固有情報に次のタグを設定する必要があります

注:
これらのタグの詳細については、XML 属性の場合を 参照してください。type=attribute タグの使用例については、複合タイプの XML エレメントの場合を参照してください。

XML 属性を表すビジネス・オブジェクト属性は、そのアプリケーション固有情報に、次のタグも組み込むことができます。

特殊文字が含まれる XML エレメントまたは属性の場合

特殊文字を含む XML エレメントまたは XML 属性を表すビジネス・オブジェクト属性 は、XML データ・ハンドラーによるエスケープ処理を必要とします。

データ・ハンドラーにエスケープ処理の必要性を通知するには、ビジネス・オブジェクト属性のアプリケーション固有情報に次のタグを設定する必要があります。

escape=true
 

エスケープ処理の対象である XML 文書が、そのスキーマの記述にスキーマ文書を使用している場合、エスケープ処理を指定するステップは、スキーマの記述に DTD を使用している XML 文書に対してエスケープ処理を指定するステップと同じです。詳細については、特殊文字が含まれる XML エレメントまたは属性の場合を参照してください。

XML コメントの場合

XML データ・ハンドラーがビジネス・オブジェクトを XML 文書に変換するとき、XML 文書への XML コメントの追加を XML データ・ハンドラーに指示することができます。これを実行するには、属性のアプリケーション固有情報に次のタグを設定します。


 type=comment
 

XML ODA は、XML コメント用ビジネス・オブジェクト属性を自動的には生成しません。このような属性は、手動で追加する必要があります。スキーマ文書によって記述されている XML 文書に コメントを追加するステップは、DTD によって記述されている XML 文書にコメントを 定義するステップと同じです。詳細については、XML コメントの場合を参照してください。

XML 処理命令の場合

XML 文書に XML 処理命令が含まれる場合、スキーマ文書に関連するビジネス・オブジェクト定義に、処理値を保持するための属性を設定する必要があります。この属性のアプリケーション固有情報には、次の type タグを設定する必要があります。

type=pi
 
 

例えば、XML データ・ハンドラーが XML 文書をビジネス・オブジェクトに変換するときには、トップレベル・ビジネス・オブジェクト定義の特別な属性 XMLDeclaration に XML バージョン を置きます。図 19 のトップレベル・ビジネス・オブジェクトは、TopLevel_Customer ビジネス・オブジェクト定義内 の XMLDeclaration 属性を示しています。type=pi タグの詳細については、XML 処理命令の場合を参照してください。

XML スキーマ・ロケーションの場合

XML 文書が、そのスキーマ文書のスキーマ・ロケーションを指す場合、その XML 文書は次の情報を格納していることが必要です。

例えば、XML 文書に、図 28 に示したネーム・スペース宣言があると仮定します。

図 28. XML 文書内のスキーマ・ロケーション定義サンプル

<order xmlns="http://sampleDoc.org.ord"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://www.example.com/order order.xsd">
    ...
 /<order>
 

スキーマ文書には、ターゲット・ネーム・スペースを定義している次のネーム・スペース宣言が含まれる場合があります。

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
      xmlns="http://www.example.com/order"
      targetNamespace="http://www.example.com/order">
 

この XML 文書を表すビジネス・オブジェクトが schemaLocation 属性の情報を保持するためには、ビジネス・オブジェクト定義にこのスキーマ・ロケーション情報のための属性を設定する必要があります。root エレメント・ビジネス・オブジェクト定義では、このスキーマ・ロケーション情報は次のように表現されます。

この XML 文書を表すスキーマ文書の root エレメント・ビジネス・オブジェクト定義には、スキーマ・ロケーションに対応する次の属性が含まれます。

[Attribute]
 Name=schemaLocation
 Type=String
 AppSpecificInfo=type=xsischemalocation;
 

注:
属性が schemaLocation または noNamespaceSchemaLocation XML 属性 を表す場合、アプリケーション固有情報に type=attribute タグを設定する 必要はありません

XML ODA は、DoctypeorSchemaLocation ODA 構成プロパティーの値に基づいて、トップレベル・ビジネス・オブジェクトに schemaLocation 属性 を作成するか、noNamespaceSchemaLocation 属性を作成するかを決定します。

スキーマ文書からのビジネス・オブジェクト定義の作成

スキーマ文書は XML 文書の内容を規定し、制約します。したがって、ビジネス・オブジェクト定義のために必要な情報を取得する上で、スキーマ文書は非常に有用です。スキーマ文書の構造情報をビジネス・オブジェクト定義に変換するため、XML Object Discovery Agent (ODA) を使用することができます。XML ODA については、ビジネス・オブジェクト定義を作成するための XML ODA の使用を参照してください。

サポートされるスキーマ文書構造

XML ODA はスキーマのエレメント宣言をオブジェクト定義の属性にマップします。ビジネス・オブジェクト属性のタイプは、XML エレメント宣言で指定したタイプによって異なります。単純タイプは String Java タイプにマップされます。複合タイプはビジネス・オブジェクト定義にマップされます。

XML ODA は、次のスキーマ文書構造をサポートしています。

サポートされないスキーマ文書構造

XML ODA は、ほとんどのスキーマ文書を処理できます。ただし、次のスキーマ文書構造はサポートされていません。

Copyright IBM Corp. 2004