文書タイプ定義 (DTD) は、スキーマと呼ばれる XML 文書のテンプレートを規定するための特別な構文を提供する XML 文書用データ・モデルです。この DTD は .dtd 拡張子を持つファイルです。XML 文書のスキーマを表すビジネス・オブジェクト定義は DTD 内の情報を使用することにより、文書の構造を保存し、記録します。このセクションでは、ビジネス・オブジェクト定義に対応する構造情報の DTD からの引き出しに関する次の内容について説明します。
DTD に対応するビジネス・オブジェクト定義が XML データ・ハンドラーの要件に適合していることを確認するためには、このセクションで示すガイドラインを使用します。ガイドラインは次のように構成されます。
ビジネス・オブジェクト定義を正しく作成することにより、データ・ハンドラーがビジネス・オブジェクトと XML 文書との相互の変換を正しく行うことができます。XML データ・ハンドラーのビジネス・オブジェクトの作成方法の詳細については、スキーマ文書を使用する XML 文書を参照してください。
DTD を表すには、少なくともビジネス・オブジェクトの構造で説明 した 2 つのビジネス・オブジェクト定義が必要です。 DTD では、これらのビジネス・オブジェクト定義に以下の追加要件があります。
XML ODA がトップレベル・ビジネス・オブジェクト定義に DocType 属性 を生成するかどうかは、DocTypeOrSchemaLocation 構成プロパティーの設定 によって異なります。 詳細については、XML DOCTYPE 宣言の場合およびサポートされる DTD 構造を参照してください。
この属性のアプリケーション固有情報には、type=pi タグの設定が必要です。詳細については、XML 処理命令の場合を参照してください。
ビジネス・オブジェクトの構造で説明したように、この属性には、タイプとして単一カーディナリティーのビジネス・オブジェクトを指定し、そのタイプが root エレメントのビジネス・オブジェクト定義である必要があります。アプリケーション固有情報に、elem_name タグを使用してこのエレメントの名前がリストされている必要があります。詳細については、XML エレメントの場合を参照してください。
DTD に基づき、ビジネス・オブジェクト定義を使用して XML データ・ハンドラーにより処理されるビジネス・オブジェクトは、次の規則にも準拠していることが必要です。
XML 文書の DTD の例を以下に示します。 DTD は Order という名前で、アプリケーション Order エンティティーに対応するエレメントを含みます。
<!--Order --> <!-- Element Declarations --> <!ELEMENT Order (Unit+)> <!ELEMENT Unit (PartNumber?, Quantity, Price, Accessory*)> <!ELEMENT PartNumber (#PCDATA)> <!ELEMENT Quantity (#PCDATA)> <!ELEMENT Price (#PCDATA)> <!ELEMENT Accessory (Quantity, Type)> <!ATTLIST Accessory Name CDATA > <!ELEMENT Type (#PCDATA)>
図 13 に、Order DTD に関連する XML 文書に対応して作成されることがあるビジネス・オブジェクトの構造を示します。 Order DTD 内の各 XML エレメントとエレメント属性には、対応するビジネス・オブジェクト属性があります。トップレベル・ビジネス・オブジェクトには、XML 宣言、DOCTYPE、およびトップレベルの Order エレメントの各属性が格納されます。また、Name エレメント属性は、Accessory ビジネス・オブジェクト内の最初の属性であることにも注意してください。
図 13. Order DTD を使用する XML 文書のビジネス・オブジェクトの例
XML 文書用のビジネス・オブジェクト定義が DTD に基づいている場合、ビジネス・オブジェクト属性プロパティーには、ビジネス・オブジェクトの属性プロパティーで説明した制約があります。さらに、DTD 構文により、ビジネス・オブジェクト属性の「必須性」が決まる場合があります。
「必須性」とは、カーディナリティーや属性がキーであるかどうかなどの要因の組み合わせであり、XMLデータ・ハンドラーがその属性を必要とするかどうかを指定します。属性が必須な場合には、Required 属性プロパティーを true に設定することが必要です。
Required 属性プロパティーの設定は、以下に示すように、XML エレメントおよび属性の指定のほか、Cardinality、Key、および Foreign Key 属性プロパティーの設定に依存します。
表 13. DTD に対応するカーディナリティーと「必須性」
DTD ELEMENT フラグメント | カーディナリティー | 必須 |
---|---|---|
指定なし | 1 | はい |
? | 1 | いいえ |
+ | N | はい |
* | N | いいえ |
このセクションでは、DTD に基づくビジネス・オブジェクト定義のためのアプリケーション固有情報フォーマットの次の内容について説明します。
XML データ・ハンドラーは次のタイプのビジネス・オブジェクトを使用して、DTD から生成された異なる種類の XML エレメントを表します。
これらのタイプのビジネス・オブジェクトは、ビジネス・オブジェクト・レベルでアプリケーション固有情報により識別されます。
通常のビジネス・オブジェクトは XML エレメントを表します。
このタイプのビジネス・オブジェクトでは、ビジネス・オブジェクト・レベルでのアプリケーション固有情報により、ビジネス・オブジェクトが表す XML エレメントの名前を識別します。例えば、XML エレメントが次のように定義されていると仮定します。
<!ELEMENT Unit(...)>
関連するビジネス・オブジェクト定義に対応するビジネス・オブジェクト・レベルでのアプリケーション固有情報は次のとおりです。
[BusinessObjectDefinition] Name = MyApp_Unit AppSpecificInfo = elem_name=Unit [Attribute] ...
混合 ビジネス・オブジェクトは、文字データ (#PCDATA) およびその他のサブエレメントが混合した内容を格納している混合 XML エレメントを表します。 混合タイプの XML エレメントの DTD での表現は、次のようになります。
<!ELEMENT (#PCDATA | CONTAINED_ELEMENT1 | CONTAINED_ELEMENTN)*>
例えば、Cust XML エレメントが DTD で次のように定義されていると仮定します。
<!ELEMENT Cust(#PCDATA | Address | Phone)*>
混合タイプの XML エレメントを表すため、混合タイプのビジネス・オブジェクト定義を使用します。混合ビジネス・オブジェクト定義の場合、そのビジネス・オブジェクト・レベルのアプリケーション固有情報は、次のコンポーネントから構成されます。
Cust エレメントを表すビジネス・オブジェクト定義 MyApp_Cust の場合、ビジネス・オブジェクト・レベルでのアプリケーション固有情報は次のようになります。
[BusinessObjectDefinition] Name = MyApp_Cust AppSpecificInfo = Cust;type=MIXED;
ラッパー・ビジネス・オブジェクトは、反復選択項目リストを表します。このタイプのビジネス・オブジェクト定義は、XML エレメントに任意の順序と任意のカーディナリティーになり得る子がある場合に必要です。ラッパー・ビジネス・オブジェクトは、子エレメントの順序とカーディナリティーを XML 文書に保存します。
選択リストの XML エレメントの場合、DTD 定義は次のようになります。
(CONTAINEDELEMENT1 | ... | CONTAINEDELEMENTN)*
DTD 内の選択リスト XML エレメント定義の例を次に示します。
<!ELEMENT CUST( U | I | B )* )>
このエレメントは、任意の順序となりえるオプションの 3 つのサブエレメントを含んでいます。各サブエレメントは単純エレメントです。図 14 に、このタイプの XML 文書を示します。
<CUST> <U>..... </U> <B>..... </B> <I>..... </I> <B>..... </B> <U>..... </U> ...
DTD 内に定義された選択リスト XML エレメントを表すため、ビジネス・オブジェクト定義は階層型です。次のビジネス・オブジェクト定義から構成されています。
この親ビジネス・オブジェクト定義には、複数カーディナリティーのビジネス・オブジェクト配列を表す 1 つの属性があります。この属性は、そのタイプとして、関連付けられたラッパー・ビジネス・オブジェクトのビジネス・オブジェクト定義を保持しています。親ビジネス・オブジェクト定義には、次のアプリケーション固有情報が設定されています。
(choiceElement1|...|choiceElementN)
ここで、choiceElement1...choiceElementN は、定義された選択エレメントそれぞれに対応します。各選択エレメントはパイプ文字 (|) で区切り、タグ全体は括弧で囲むことが必要です。
ラッパー・ビジネス・オブジェクト定義には、選択リスト・エレメントに定義された各選択エレメントに対応した属性がそれぞれ設定されています。ビジネス・オブジェクト・レベルでのアプリケーション固有情報は必要ありません。
図 15 に、選択リスト XML エレメントに対応するビジネス・オブジェクト定義の階層構造を示します。実行時には、各子ビジネス・オブジェクトがラッパー・ビジネス・オブジェクトのインスタンスとなり、1 つの属性にのみデータが設定されます。例として、図 14 の XML 文書のビジネス・オブジェクトには 5 つの子があり、それぞれに該当する属性が設定されています。
図 15. 選択リスト XML エレメントに対応するビジネス・オブジェクト定義の階層構造
図 16 に、親ビジネス・オブジェクト定義である MyApp_Cust とそのアプリケーション固有情報を示します。
図 16. 選択リスト・エレメントの親ビジネス・オブジェクト定義
[BusinessObjectDefinition] Name = MyApp_Cust AppSpecificInfo = [Attribute] Name = CustWrapper Type = MyApp_CustWrapper Cardinality = N AppSpecificInfo = attr_name=CustWrapper;(U|I|B) [End]
ラッパー・ビジネス・オブジェクト定義 MyApp_CustWrapper には 3 つの属性があり、それぞれ 1 つの選択エレメントに対応しています。各選択エレメントには文字データが格納されているため、各属性に対応するアプリケーション固有情報により、以下の内容が指定されます。
図 17 に、この XML 文書に対応するラッパー・ビジネス・オブジェクト定義を示します。
図 17. 選択リスト・エレメントのラッパー・ビジネス・オブジェクト定義
[BusinessObjectDefinition] Name = MyApp_CustWrapper AppSpecificInfo = [Attribute] Name = DataU Type = String AppSpecificInfo = attr_name=U;type=pcdata; [End] [Attribute] Name = DataI Type = String AppSpecificInfo = attr_name=I;type=pcdata; [End] [Attribute] Name = DataB Type = String AppSpecificInfo = attr_name=B;type=pcdata; [End]
ビジネス・オブジェクト属性が他のエレメントを含む XML エレメントを表す場合、アプリケーション固有情報にはエレメントの名前が設定されている必要があります。例えば、DeliveryDate という名前の属性にビジネス・オブジェクト・タイプがあり、DATETIME という名前のエレメントを表す場合、アプリケーション固有情報には、次のようにエレメントの名前が設定されています。
Name = DeliveryDate Relationship = Containment Cardinality = n AppSpecificInfo = DATETIME
ビジネス・オブジェクト定義の属性は、以下の XML コンポーネントを表すことができます。
表 25 に、これらのさまざまな XML コンポーネントの属性レベルのアプリケーション固有情報のタグと、タグの詳細が記載されている本書のセクションを示します。
ビジネス・オブジェクト属性の表現 | アプリケーション固有情報 | 詳細 |
---|---|---|
XML エレメント | XML エレメントの場合 | |
PCDATA のみを持つ XML エレメント | PCDATA のみを持つ XML エレメントの場合 | |
XML エレメントの属性 |
attr_name=name of XML attribute
| XML 属性の場合 |
文字データと属性を持つ XML エレメント | 文字データおよび属性を持つ XML エレメントの場合 | |
特殊文字を持つ XML エレメントまたは属性 | 特殊文字が含まれる XML エレメントまたは属性の場合 | |
DOCTYPE 宣言 | XML DOCTYPE 宣言の場合 | |
CDATA セクション | CDATA セクションの場合 | |
XML 文書に追加されるコメント | type=comment | XML コメントの場合 |
処理命令 | type=pi | XML 処理命令の場合 |
XML エレメントを表すすべての単純 (String) ビジネス・オブジェクト属性 には、アプリケーション固有情報に elem_name タグを使用して、関連するエレメントを識別する必要があります。
elem_name=name of XML element
例えば、ビジネス・オブジェクト属性 CustLName が単純 XML 属性を表す場合には、そのアプリケーション固有情報は次のようになります。
Name = CustLName AppSpecificInfo = elem_name=CustLName;
XML エレメント名には特殊文字 (ピリオドやハイフンなど) を使用できます。ただし、ビジネス・オブジェクト属性名にこれらの特殊文字を使用することはできません。したがって、XML エレメント名 を elem_name タグに指定する必要があります。ビジネス・オブジェクト属性に名前を付けるとき、XML ODA は XML エレメントの名前から特殊文字を除去し、それらを下線 (_) 文字に置換します。
以下の例では、XML エレメントのアプリケーション固有情報で指定された名前は実際の XML エレメントの名前とは異なっています。これは、属性に特殊文字が含まれているためです。
Name = Phone_Tag AppSpecificInfo = elem_name=Phone#Tag;
XML エレメントの実際の名前にはポンド記号 (#) が含まれています。ポンド記号をビジネス・オブジェクト属性の名前に使用することはできません。このため、アプリケーション固有情報の elem_name タグで実際の XML エレメント名を指定します。関連したビジネス・オブジェクト属性の名前では、ポンド記号は下線に置換されます。
文字データのみを持つ XML エレメントが、PCDATA エレメント内容指定子のみを持つエレメントと混合されています。PCDATA のみが格納されている XML エレメントを表すビジネス・オブジェクト属性は、アプリケーション固有情報に次の type タグを使用する必要があります。
type=pcdata
この場合、エレメント名はアプリケーション固有情報の最初のフィールドで、type パラメーターが 2 番目のフィールドです。
例えば、PCDATA のみを格納している PartNumber という名前のエレメントは、DTD で次のように定義されています。
<!ELEMENT PartNumber (#PCDATA)>
ビジネス・オブジェクト定義内の対応する属性には、次のアプリケーション固有情報が設定されています。
Name = PartNumber AppSpecificInfo = elem_name=PartNumber;type=pcdata;
アプリケーション固有情報にテキスト notag も設定されている場合、XML データ・ハンドラーは XML マークアップを生成しません。データ・ハンドラー 自体の属性値のみを XML 文書に追加します。詳細については、文字データおよび属性を持つ XML エレメントの場合を参照してください。
ビジネス・オブジェクト属性が XML エレメントの属性を表す場合、アプリケーション固有情報に次のタグを設定する必要があります。
attr_name=attrName
XML 属性名には特殊文字 (ピリオドやハイフンなど) を使用できます。ただし、ビジネス・オブジェクト属性名にこれらの特殊文字を使用することはできません。したがって、XML 属性名 を attr_name タグに指定する必要があります。ビジネス・オブジェクト属性に名前を付けるとき、XML ODA は XML 属性の名前から特殊文字を除去します。
type=attribute
この type タグは、関連するビジネス・オブジェクト属性の目的を XML 属性 として識別します。
例えば、ID という名前のビジネス・オブジェクト属性が ID という 名前の XML 属性を表す場合、アプリケーション固有情報は次のとおりです。
Name = ID AppSpecificInfo = attr_name=ID;type=attribute;
type=attribute タグを使用している別の例については、文字データおよび属性を持つ XML エレメントの場合を参照してください。
XML エレメントが PCDATA または CDATA のみ を 含み、1 つ以上の XML 属性を持っている場合、そのビジネス・オブジェクト定義には次の属性が設定されていることが必要です。
属性名は、XML 属性の名前と一致していることが必要です。属性レベルのアプリケーション固有情報には、attr_name タグと type=attribute タグが設定されていることが必要です。 詳細については、XML 属性の場合を参照してください。
この属性には、親 XML エレメントに関係付けられたデータが設定されています。アプリケーション固有情報は以下を含んでいることが必要です。
例えば、Price という名前の XML エレメントに、Currency という名前の属性があり、Price 用のデータを必要としていると仮定します。
<!ELEMENT Price (#PCDATA)> <!ATTLIST Price Currency NMTOKEN #IMPLIED>
Price エレメントには XML 属性があるため、そのビジネス・オブジェクト定義に、Currency 用のビジネス・オブジェクト属性を作成することが必要です。さらに、Price データを保持するために別の属性も必要です。Price データの属性には、そのアプリケーション固有情報に notag を指定して、データ・ハンドラーがこの属性の開始および終了タグを作成しないようにする必要があります。
Price 子ビジネス・オブジェクトは、次のようになります。
[BusinessObjectDefinition] Name = Price AppSpecificInfo = Price
[Attribute] Name = Currency Type = String AppSpecificInfo = attr_name=Currency;type=attribute; ... [End]
[Attribute] Name = Price Type = String AppSpecificInfo = Price;type=pcdata;notag ... [End]
この場合、データ・ハンドラーは、Price データの新しい XML エレメントは生成せず、データを親エレメントに追加するだけです。
エスケープ処理を必要とする内容の XML エレメントまたは XML 属性を表すビジネス・オブジェクト属性の場合、そのアプリケーション固有情報には次のタグが設定されていることがあります。
escape=true
属性が表す XML エレメントが、次の特殊文字のいずれかを含む値を持つ場合、その属性にはエスケープ処理が必要です。
アプリケーション固有情報に escape=true タグが設定されている場合を除き、属性はエスケープ処理の対象外 です。このタグは、既存のアプリケーション固有情報の最後に入れることが必要です。例えば次のようになります。
[Attribute] Name=Data Type=String AppSpecificInfo=Price;type=pcdata;escape=true [End]
属性のアプリケーション固有情報に escape タグが設定されていない 場合、XML データ・ハンドラーは、DefaultEscapeBehavior プロパティーを調べることにより、エスケープ処理を実行するかどうか決定します。
ビジネス・オブジェクト属性が prolog 内の文書タイプ宣言を表す場合、アプリケーション固有情報には次の type タグが設定されていることが必要です。
type=doctype
例えば、ビジネス・オブジェクト属性 DocType が DOCTYPE エレメントを表す場合には、そのアプリケーション固有情報は次のようになります。
Name = DocType AppSpecificInfo = type=doctype;
DocType 属性が、次の値の場合、
DOCTYPE CUSTOMER "customer.dtd"
データ・ハンドラーは次の XML を生成します。
<!DOCTYPE CUSTOMER "customer.dtd">
このアプリケーション固有情報は、XML 文書の汎用エンティティー宣言を組み込むためにも使用されます。しかし、内部 DTD またはパラメーター・エンティティー宣言の組み込みに関する明示的なサポートはありません。これらを文書に組み込むには、アプリケーション固有情報に type=doctype が指定されている属性の値にテキスト全体を設定します。
ビジネス・オブジェクト属性が XML 文書内の CDATA セクションを表す場合、アプリケーション固有情報には次の type タグが設定されていることが必要です。
type=cdata
例えば、ビジネス・オブジェクト属性 UserArea が CDATA セクションを表す場合、そのアプリケーション固有情報は次のようになります。
Name = UserArea AppSpecificInfo = type=cdata;
XML データ・ハンドラーがビジネス・オブジェクトを XML 文書に変換するとき、XML 文書へのコメントの追加を XML データ・ハンドラーに指示することができます。データ・ハンドラーによるコメントの追加を可能にするには、次のステップを実行します。
type=comment
例えば、Comment という名前のビジネス・オブジェクト属性が、データ・ハンドラーが XML 文書に追加する XML コメントを表す場合、Comment 属性は次のようになります。
Name = Comment AppSpecificInfo = type=comment;
属性の値が「Customer information update from application A」であれば、次の XML が生成されます。
<!--Customer information update from application A-->
ビジネス・オブジェクト属性が処理命令を表す場合、アプリケーション固有情報には次の type タグが設定されていることが必要です。
type=pi
例えば、XMLDeclaration という名前のビジネス・オブジェクト属性が prolog 内の XML 宣言を表す場合、アプリケーション固有情報は次のとおりです。
Name = XMLDeclaration AppSpecificInfo = type=pi;
属性が、次の値の場合、
xml version = "1.0"
XML データ・ハンドラーは次の XML を生成します。
<?xml version="1.0"?>
DTD は XML 文書のフォーマットを記述します。 したがって、ビジネス・オブジェクト定義のために必要な情報を取得する上で、DTD は非常に有用です。DTD 内の構造情報をビジネス・オブジェクト定義に変換するため、XML Object Discovery Agent (ODA) を使用することができます。XML ODA については、ビジネス・オブジェクト定義を作成するための XML ODA の使用を参照してください。
XML ODA は次の DTD 構造をサポートします。
<!ENTITY % name value>
<!ELEMENT SCENE (ANY) >
対応するビジネス・オブジェクト定義は次のとおりです。
[Attribute] Name = SCENE Type = String Cardinality = 1 MaxLength = 255 IsKey = false IsForeignKey = false IsRequired = true AppSpecificInfo = SCENE;type=pcdata; [End]
XML ODA はほとんどの DTD を処理できます。ただし、次の DTD 構造はサポートされていません。