XML スキーマ は、XML 文書のテンプレート (スキーマ) を定義するためにスキーマ文書 (.xsd 拡張子) を使用する XML 文書用データ・モデルです。DTD とは異なり、スキーマ文書は、スキーマを記述するために、XML 文書と同じ構文を使用します。XML 文書のスキーマを表すビジネス・オブジェクト定義は、文書の構造を保存および記録するために、スキーマ文書内の情報を使用します。このセクションでは、ビジネス・オブジェクト定義に対応する構造情報のスキーマ文書からの引き出しに関する次の内容について説明します。
スキーマ文書を表すビジネス・オブジェクト定義が XML データ・ハンドラーの要件に適合していることを確認するには、このセクションで示すガイドラインを使用します。ガイドラインは次のように構成されています。
スキーマ文書に基づき、ビジネス・オブジェクト定義を使用して XML データ・ハンドラーにより処理されるビジネス・オブジェクトは、次の規則に準拠していることが必要です。
詳細については、スキーマ文書に必要なビジネス・オブジェクト定義を参照してください。
XML 文書用のスキーマ文書の例を図 18 に示します。 このスキーマ・文書の名前は Order で、アプリケーション Order エンティティーに対応するエレメントを格納しています。このスキーマ文書のサンプルは、前述の DTD 文書のサンプルと同じビジネス・オブジェクト 構造を記述しています。図 13 に、Order スキーマ文書 に関連する 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 つのビジネス・オブジェクト定義が必要です。スキーマ文書では、これらのビジネス・オブジェクト定義に以下の追加要件があります。
この属性のアプリケーション固有情報には、type=pi タグの設定が必要です。詳細については、XML 処理命令の場合を参照してください。
ビジネス・オブジェクトの構造で説明したように、この属性には、タイプとして単一カーディナリティーのビジネス・オブジェクトを指定し、そのタイプが root エレメントのビジネス・オブジェクト定義である必要があります。アプリケーション固有情報に、elem_name タグを使用してこのエレメントの名前がリストされている必要があります。詳細については、XML エレメントの場合を参照してください。
XML ODA がトップレベル・ビジネス・オブジェクト定義に schemaLocation 属性を生成するかどうかは、DocTypeOrSchemaLocation 構成プロパティーの設定 によって異なります。 詳細については、XML スキーマ・ロケーションの場合を参照してください。
これらの必須のビジネス・オブジェクト定義には、ターゲット・ネーム・スペースおよびコンポーネント名の制限を定義する、ビジネス・オブジェクト・レベルのアプリケーション固有情報が必要です。詳細については、ビジネス・オブジェクト・レベルのアプリケーション固有情報を参照してください。
図 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 構造のいずれかを表します。
sequence グループの各子エレメントは、ビジネス・オブジェクト定義の中では属性として表されます。詳細については、複合タイプの XML エレメントの場合を参照してください。
このタイプのビジネス・オブジェクト定義では、ビジネス・オブジェクト・レベルのアプリケーション固有情報に特別な情報は必要ありません。通常のビジネス・オブジェクト定義の属性は、XML 複合タイプ内に定義されているエレメントを 表します。
例えば、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 つのビジネス・オブジェクト定義 が必要です。
この親ビジネス・オブジェクト定義には、複数カーディナリティーのビジネス・オブジェクト配列を表す 1 つの属性があります。この属性は、そのタイプとして、関連付けられたラッパー・ビジネス・オブジェクトのビジネス・オブジェクト定義を保持しています。親ビジネス・オブジェクト定義には、次のアプリケーション固有情報が設定されています。
(mixedTypeElement|subElement1|...|subElementN)
ここで、
各サブエレメントはパイプ文字 (|) で区切り、タグ全体は括弧で囲むことが必要です。
ラッパー・ビジネス・オブジェクト定義には、混合データ用の属性が設定されています。
type=pcdata タグについて詳しくは、複合タイプの XML エレメントの場合を参照してください。
ビジネス・オブジェクト定義 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 エレメントを、次のモデル・グループのいずれかを含む複合タイプとして記述することができます。
<xsd:complexType> <xsd:choice> ... </choice> </complexType>
choice グループを含む複合タイプの XML エレメントを表すため、XML データ・ハンドラーは、DTD で定義された選択リスト XML エレメント用の階層型ビジネス・オブジェクト定義と同じ階層型ビジネス・オブジェクト定義を想定します。
これらのビジネス・オブジェクト定義には、DTD 用の選択リスト XML エレメントの場合と同じフォーマットで、ビジネス・オブジェクト・レベルのアプリケーション固有情報が格納されています。詳細については、DTD に基づくラッパー・ビジネス・オブジェクト定義を参照してください。
<xsd:complexType> <xsd:all> ... </xsd:all> </xsd:complexType>
all グループを含む複合タイプの XML エレメントを表すため、XML データ・ハンドラーは、次のビジネス・オブジェクト定義を持つ階層型ビジネス・オブジェクト定義を想定します。
これらのビジネス・オブジェクト定義には、DTD 用の選択リスト XML エレメントの場合と同じフォーマットで、ビジネス・オブジェクト・レベルのアプリケーション固有情報が格納されています。詳細については、DTD に基づくラッパー・ビジネス・オブジェクト定義を参照してください。
カーディナリティーを指示するため、これらのモデル・グループでは、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 の派生型です。
<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 文書が有効です。
<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 属性プロパティーの設定に依存します。
表 18. スキーマ文書に対応するカーディナリティーと「必須性」
スキーマ・フラグメントの出現インディケーター | カーディナリティー | 必須 |
---|---|---|
指定なし | 1 | はい |
maxOccurs > 1 | N | はい |
maxOccurs = "unbounded" | N | はい |
minOccurs=0 | 影響なし | いいえ |
minOccurs>1 | N | はい |
スキーマ・フラグメントの出現属性: use | カーディナリティー | 必須 |
---|---|---|
指定なし | 影響なし | いいえ |
use=required | 影響なし | はい |
スキーマ・フラグメントの属性: id | キー | 必須 | コメント |
---|---|---|---|
id=ID | あり | いいえ |
|
このセクションでは、スキーマ文書に基づくビジネス・オブジェクト定義のためのアプリケーション固有情報フォーマットの次の内容について説明します。
XML データ・ハンドラーは次のタイプのビジネス・オブジェクト定義を使用して、スキーマ文書に定義されている異なる種類の root XML エレメントを表します。これらのビジネス・オブジェクト定義のタイプは、ビジネス・オブジェクト・レベルでアプリケーション固有情報により識別されます。
表 21. ビジネス・オブジェクト・レベルのアプリケーション固有情報のタグ
アプリケーション
固有情報内のタグ | 説明 | 詳細 |
---|---|---|
target_ns | スキーマ文書のターゲット・ネーム・スペースを指定します。 | スキーマ・ネーム・スペース |
attr_fd | 属性名を修飾するかどうかを指定します。 | 修飾されたコンポーネント名 |
elem_fd | ローカルに宣言されたエレメント名を修飾するかどうかを指定します。 | 修飾されたコンポーネント名 |
DTD とは異なり、スキーマ文書は、1
つ以上のネーム・スペースの定義を必要とします。ネーム・スペース
は、XML
文書内のエレメント名、エレメント・タイプ、および属性のコンテキストを規定します。ネーム・スペースは Uniform Resource Identifier (URI) であり、HTTP、FTP、およびその他のパスが含まれます。表 22
に、スキーマ・コンポーネント間で参照を解決するためにスキーマ文書で宣言できるネーム・スペースを示します。
ネーム・スペース | 説明 | 名前 | 共通プレフィックス |
---|---|---|---|
XML スキーマ・ネーム・スペース | XML スキーマ定義言語 (XSDL) で使用される element、schema、simpleType などすべてのコンポーネントを定義します。 |
http://www.w3.org/2001/ XMLSchema | xsd、xs |
XML スキーマ・インスタンス・ネーム・スペース | スキーマ・インスタンスに関連付けられた 4 つの 属性 type、nil、schemaLocation、noNamespaceSchemaLocation を 定義します。 |
http://www.w3.org/2001/ XMLSchema-instance | xsi |
ユーザー定義のネーム・スペース |
グローバル宣言により宣言または定義されたすべてのコンポーネント (element、attribute、type、group など) を定義します。
| ユーザー定義 | ユーザー定義 |
各スキーマ文書では 1 つのターゲット・ネーム・スペース を宣言でき、targetNamespace タグを使用して、ネーム・スペースがどのグローバル・コンポーネント (エレメント、属性、タイプ、またはグループ) に属するか を指定します。 スキーマ・エレメントに targetNamespace タグを設定する場合、そのスキーマ文書用に生成された各ビジネス・オブジェクト定義のアプリケーション固有情報に target_ns タグを設定して、XML 文書で宣言されたターゲット・ネーム・スペースを指定する必要があります。
target_ns=URI address for target namespace
target_ns タグは、次のようにしてすべての ビジネス・オブジェクト定義のビジネス・オブジェクト・レベルのアプリケーション固有情報に設定する必要があります。
このようにネーム・スペース・プレフィックスを定義する仕組みは置き換えられましたが、XML データ・ハンドラーは、既存のビジネス・オブジェクト定義との後方互換性のためにこの仕組みのサポートを継続しています。新規のビジネス・オブジェクト定義では、このセクションで説明したように target_ns タグを使用します。XML ODA は、target_ns タグを使用するよう変更されました。
例えば、図 23 のスキーマ文書は、(xsd プレフィックス を持つ) XML スキーマ・ネーム・スペースとターゲット・ネーム・スペース (デフォルトのネーム・スペース) を 記述しています。
<?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_TopLevel、BOPrefix_TopLevel_Customer、および BOPrefix_TopLevel_TaxInfoType という 3 つのビジネス・オブジェクト定義を生成します (ここで、BOPrefix および TopLevel はこれらの ODA 構成プロパティーの値です)。これらの 3 つのビジネス・オブジェクト定義では、ビジネス・オブジェクト・レベルのアプリケーション固有情報に次の行が設定されます。
target_ns=http://www.ibm.com/ns1;elem_fd=unqualified;attr_fd=unqualified
1 つのスキーマ文書では 1 つのターゲット・ネーム・スペースのみを定義できます。ただし、import エレメントを使用すると、別のスキーマ文書のターゲット・ネーム・スペースで定義されたエレメントや属性を組み込むことができます。
図 23 で定義した Schema1.xsd 文書に基づくスキーマ文書を図 24 に示します。このスキーマ文書は、TaxInfoType 複合タイプ、BillTo エレメント、および Name 属性を宣言する ns2 ネーム・スペースをインポート します。
<?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 ネーム・スペース 内の TaxInfoType、BillTo、および Name XML コンポーネント を定義するスキーマ文書を示します。
<?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 文書の中で、ネーム・スペースに関連付けられたコンポーネント名は、次のように修飾されるか、または修飾されません。
1 つ以上のネーム・スペースにプレフィックスを割り当てることができます。ネーム・スペースのプレフィックスは xmlns:prefix タグを使用して宣言します。ここで、prefix は宣言されたプレフィックスです。
スキーマ文書内のコンポーネント定義では、これらのコンポーネント名は修飾されます。これは、コンポーネント名の先頭にプレフィックスが付加されるためです (prefix:componentName)。
デフォルトのネーム・スペース は、コンポーネント名にプレフィックスを含まないコンポーネントに関連付けられるネーム・スペースを指定します。 デフォルトのネーム・スペースは、xmlns タグを使用して宣言します。
XML データ・ハンドラーが XML からビジネス・オブジェクトへの変換を正しく処理するためには、XML 文書用のネーム・スペースとスキーマ文書用のネーム・スペースが次のように一致していることが必要です。
schema エレメントの elementFormDefault
属性は、ローカルに宣言されたエレメント名を修飾するかどうかを指定します。
デフォルトでは、ローカルに宣言されたエレメントは修飾されず、デフォルトのネーム・スペースに属します。
表 23 に示すように、elementFormDefault 属性の値は、ビジネス・オブジェクト・レベルのアプリケーション固有情報内の
elem_fd タグの値を決定します。
elementFormDefault の値 | elem_fd タグの値 |
---|---|
"unqualified" (または属性がまったく指定されない) | elem_fd=unqualified |
"qualified" | elem_fd=qualified |
例えば、図 23 のスキーマ文書の schema エレメントには、elementFormDefault 属性は含まれません。したがって、このスキーマ文書のすべて のビジネス・オブジェクト定義のビジネス・オブジェクト・レベルのアプリケーション固有情報 (BOPrefix_TopLevel、BOPrefix_TopLevel_Customer、および BOPrefix_TopLevel_TaxInfoType。ここで、BOPrefix と TopLevel は これらの ODA 構成プロパティーの値) には、次のタグが含まれます。
elem_fd=unqualified
elementFormDefault="unqualified"
個々の XML エレメントに form 属性が含まれる場合、この form 属性 の値は elementFormDefault 属性のすべての設定をオーバーライドします。
schema エレメントの attributeFormDefault
属性は、エレメント名を修飾するかどうかを指定します。
デフォルトでは、属性名は修飾されず、いずれのネーム・スペースにも 属しません。表 24 に示すように、attributeFormDefault 属性の値は、ビジネス・オブジェクト・レベルのアプリケーション固有情報の
attr_fd タグの値を決定します。これは、elementFormDefault 属性の値が
elem_fd タグ の値を決定するのと同様です。
attributeFormDefault の値 | elem_fd タグの値 |
---|---|
"unqualified" (または属性がまったく指定されない) | attr_fd=unqualified |
"qualified" | attr_fd=qualified |
例えば、図 23 のスキーマ文書の schema エレメントには、attributeFormDefault 属性は含まれません。したがって、このスキーマ文書のすべて のビジネス・オブジェクト定義のビジネス・オブジェクト・レベルのアプリケーション固有情報 (BOPrefix_TopLevel、BOPrefix_TopLevel_Customer、および BOPrefix_TopLevel_TaxInfoType。ここで、BOPrefix と TopLevel は これらの ODA 構成プロパティーの値) には、次のタグが含まれます。
attr_fd=unqualified
attributeFormDefault="unqualified"
ビジネス・オブジェクト定義の属性は、以下の XML コンポーネントを表すことができます。
表 25 に、これらのさまざまな XML コンポーネントの属性レベルのアプリケーション固有情報のタグと、タグの詳細が記載されている本書のセクションを示します。
ビジネス・オブジェクト属性の表現 | アプリケーション固有情報 | 詳細 |
---|---|---|
XML エレメント |
elem_ns=namespace for element's definition
| XML エレメントの場合 |
複合タイプの XML エレメント | 複合タイプの XML エレメントの場合 | |
XML エレメントの属性 |
attr_name=name of XML attribute
attr_ns=namespace for attribute's definition
| XML 属性の場合 |
特殊文字を持つ XML エレメントまたは属性 | 特殊文字が含まれる XML エレメントまたは属性の場合 | |
XML 文書に追加されるコメント | type=comment | XML コメントの場合 |
処理命令 | type=pi | XML 処理命令の場合 |
XML インスタンスの schemaLocation または noNamespaceSchemaLocation 属性 |
| XML スキーマ・ロケーションの場合 |
ビジネス・オブジェクト属性が XML エレメントを表す場合、アプリケーション固有情報に次の elem_name タグを設定して、関連するエレメントを識別する必要があります。
elem_name=name of XML element
XML エレメント名には特殊文字 (ピリオドやハイフンなど) を使用できます。ただし、ビジネス・オブジェクト属性名にこれらの特殊文字を使用することはできません。したがって、XML エレメント名 を elem_name タグに指定する必要があります。ビジネス・オブジェクト属性に名前を付けるとき、XML ODA は XML エレメントの名前から特殊文字を除去します。
ビジネス・オブジェクト属性は、次の場合に XML エレメントを表すことができます。
この場合、ビジネス・オブジェクト属性は複合 属性であり、そのデータ型は XML 複合タイプを表すビジネス・オブジェクト定義です。 (属性のアプリケーション固有情報内の) elem_name タグには、XML エレメント の名前 (または複合タイプ) が含まれます。
この場合、ビジネス・オブジェクト属性は、タイプ String の単純 属性 です。 アプリケーション固有情報には elem_tag (複合タイプの XML エレメント名 を含む) および type=pcdata タグが設定されています。詳細については、複合タイプの XML エレメントの場合を参照してください。
XML エレメントを表すビジネス・オブジェクト属性は、そのアプリケーション固有情報に、次のタグも組み込むことができます。
例えば、ローカルに宣言された XML エレメントが次のように定義されていると仮定します。
<xsd:element ref="Name" form="qualified"></xsd:element>
関連するビジネス・オブジェクト属性は、次のフォーマットを使用します。
[Attribute] Name=ns2:Name Type=String AppSpecificInfo=elem_name=Name;elem_fd=qualified; ...
XML エレメントに form 属性が指定されて いない 場合、(schema エレメントの) elementFormDefault 属性の値によって、エレメント名が修飾されるかどうかが決定します。 詳細については、修飾されたコンポーネント名を参照してください。
例えば、複合タイプの XML エレメントが次のように定義されていると仮定します。
<xsd:element ref="ns2:BillTo"></xsd:element>
関連するビジネス・オブジェクト属性は、次のフォーマットを使用します。
[Attribute] Name=BillTo Type=String AppSpecificInfo=elem_name=BillTo;elem_ns=http:/www.imb.com/ns2; ...
2 番目のネーム・スペースに定義された XML エレメントを含むスキーマ文書の詳細な例については、スキーマ・ネーム・スペースを参照してください。
ビジネス・オブジェクト定義が XML 複合タイプ (complexType) を表す場合、この複合タイプの内容は、このビジネス・オブジェクト定義内の単純 (String) 属性 によって表されます。
これらのビジネス・オブジェクト属性のアプリケーション固有情報には、elem_name タグ を組み込んで、エレメント名を指定する必要があります。
XML 複合タイプでは、ビジネス・オブジェクト属性は表 26 に 示す複合タイプの内容を表すことができます。
複合タイプのエレメントのタイプ | 説明 | 属性のアプリケーション固有情報 |
---|---|---|
単純な XML エレメント | 文字のみ を含むエレメント。他のエレメントや XML 属性は格納できません。これが可能なのは複合タイプに限られます。 | type=pcdata |
単純な内容 | 文字データのみ (エレメントなし)。 | type=pcdata;notag |
属性を持つ XML エレメント | 文字データおよび サブエレメントと属性の組み合わせの両方 を含むエレメント。 |
なし。 このタイプの XML エレメントは、単一のビジネス・オブジェクト属性としてではなく、ビジネス・オブジェクト定義を使用して表す必要があります。詳細については、スキーマ文書に基づく通常のビジネス・オブジェクト定義を参照してください。
|
type=pcdata タグを使用する例として、図 23 の スキーマ文書には、単純な XML エレメントのみを持つ TaxInfoType 複合タイプ の定義が含まれます。 TaxInfoType XML 複合タイプのビジネス・オブジェクト定義 (BOPrefix_TopLevel_TaxInfoType。ここで BOPrefix と TopLevel は、それぞれの名前を持つ 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 属性が次のように定義されていると仮定します。
<xsd:attribute ref="Name" form="qualified"></xsd:attribute>
関連するビジネス・オブジェクト属性は、次のフォーマットを使用します。
[Attribute] Name=ns2:Name Type=String AppSpecificInfo=attr_name=Name;type=attribute;attr_fd=qualified ...
XML 属性に form 属性が指定されていない場合、(schema エレメントの) attributeFormDefault 属性の値によって、属性名が修飾されるかどうかが決定します。 詳細については、修飾されたコンポーネント名を参照してください。
例えば、XML 属性が次のように定義されていると仮定します。
<xsd:attribute ref="ns2:Name"></xsd:attribute>
関連するビジネス・オブジェクト属性は、次のフォーマットを使用します。
[Attribute] Name=Name Type=String AppSpecificInfo=attr_name=Name;attr_ns=http://www.example.com/ns2; type=attribute ...
2 番目のネーム・スペースに定義された XML 属性を含むスキーマ文書の詳細な例については、スキーマ・ネーム・スペースを参照してください。
特殊文字を含む XML エレメントまたは XML 属性を表すビジネス・オブジェクト属性 は、XML データ・ハンドラーによるエスケープ処理を必要とします。
データ・ハンドラーにエスケープ処理の必要性を通知するには、ビジネス・オブジェクト属性のアプリケーション固有情報に次のタグを設定する必要があります。
escape=true
エスケープ処理の対象である XML 文書が、そのスキーマの記述にスキーマ文書を使用している場合、エスケープ処理を指定するステップは、スキーマの記述に DTD を使用している XML 文書に対してエスケープ処理を指定するステップと同じです。詳細については、特殊文字が含まれる XML エレメントまたは属性の場合を参照してください。
XML データ・ハンドラーがビジネス・オブジェクトを XML 文書に変換するとき、XML 文書への XML コメントの追加を XML データ・ハンドラーに指示することができます。これを実行するには、属性のアプリケーション固有情報に次のタグを設定します。
type=comment
XML ODA は、XML コメント用ビジネス・オブジェクト属性を自動的には生成しません。このような属性は、手動で追加する必要があります。スキーマ文書によって記述されている XML 文書に コメントを追加するステップは、DTD によって記述されている XML 文書にコメントを 定義するステップと同じです。詳細については、XML コメントの場合を参照してください。
XML 文書に XML 処理命令が含まれる場合、スキーマ文書に関連するビジネス・オブジェクト定義に、処理値を保持するための属性を設定する必要があります。この属性のアプリケーション固有情報には、次の type タグを設定する必要があります。
type=pi
例えば、XML データ・ハンドラーが XML 文書をビジネス・オブジェクトに変換するときには、トップレベル・ビジネス・オブジェクト定義の特別な属性 XMLDeclaration に XML バージョン を置きます。図 19 のトップレベル・ビジネス・オブジェクトは、TopLevel_Customer ビジネス・オブジェクト定義内 の XMLDeclaration 属性を示しています。type=pi タグの詳細については、XML 処理命令の場合を参照してください。
XML 文書が、そのスキーマ文書のスキーマ・ロケーションを指す場合、その XML 文書は次の情報を格納していることが必要です。
この属性は、ネーム・スペースの名前をスキーマ・ロケーションに関連付けます。スキーマ文書がターゲット・ネーム・スペースを使用する場合には、このターゲット・ネーム・スペースの名前は、xsi:schemaLocation 属性 (XML 文書内) により指定されるネーム・スペースの名前と一致していることが必要です。
この属性により、スキーマ・ロケーションが識別されます。スキーマ文書がターゲット・ネーム・スペースを使用していない場合には、1 つのスキーマ・ロケーションを特定するため、XML 文書には noNamespaceSchemaLocation 属性が設定されています。
例えば、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;
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 は、ほとんどのスキーマ文書を処理できます。ただし、次のスキーマ文書構造はサポートされていません。