6.1.2 複合型規定
複合型定義に関する規定を以下に列挙する。
[CTD 1]
内容： xsd:anyTypeをベースとした派生は行うべきではない。
説明：
全ての複合型定義はXML Schemaの概念ではanyTypeをベースとした派生であり、敢えて明示的
にanyTypeをベースとして指定して派生型を定義するのは意味のないことである。
[CTD 2]
内容：
空の複合型宣言<xsd:complexType/>は含めるべきではない。
説明：
W3C XML Schema 1.0の規格では許されているが、意味のない記述のため避けるのが妥当である。
[CTD 3]
内容：
同じ複合型を持つ要素が複数宣言される場合、共通する型を名前付きで定義し参照す るようにするのが望ましい。
説明：
名前付きで型をあらかじめ定義しておくなら、同じ型を持つ要素はそれを参照するだけで済み、同 じ型を繰り返し定義する必要はなくなるので効率的なスキーマ作成が可能となる。
[CTD 4]
内容： xsd:any要素の使用は望ましくない。
説明：
標準スキーマは、利用シナリオを明確に持ち、それにそって具体的なモデル化を行うべきである。
その観点から、何がそこに来てもよいようにしておくという指定は望ましくない。また、出現する要 素が不定となることは処理系構築の観点からも好ましくない。
[CTD 5]
内容：
内容要素として宣言する要素の出現回数としてminOccurs="0" maxOccurs="0"と記 述すべきではない。
説明：
XML Schema規格ではmaxOccursで指定する値がminOccursを下回らなければよく
れていないことと同義であり、意味のない記述である。混乱を招くこのような記述は避けるべきであ る。
[CTD 6]
内容： xsd:allの使用は望ましくない。
説明：
xsd:all内で列挙される要素はその出現順に決まりがないため、インスタンスを書くときに混乱を
招く恐れがある。また、データのモデル化という観点から曖昧な定義は望ましくない。
6.2 要素宣言
要素宣言に関連した規定を以下に列挙する。（要素の内容（型）定義に関しては前項で記 述している。）
6.2.1 単純型に関する規定
単純型要素宣言に関する規定は特にない。
6.2.2 複合型に関する規定
複合型要素宣言に関する規定は特にない。
6.2.3 代替要素に関する規定
代替要素の使用に関する規定を以下に列挙する。
[ELD 1]
内容： substitutionGroupによる代替要素は使用しないのが望ましい。
説明：
代替要素の使用すると、その要素が実際どこに出現できるか分かりにくくなる。特に代替要素が置 き換わるヘッド型を含む型の派生を行う場合、派生の関係が判別しにくくなる。このため、代替要素 の使用は避けるのが望ましい。要素宣言はその出現する場所で直接指定すべきである。
[ELD 2]
内容：
要素のabstract指定は使用しないのが望ましい。
説明：
abstract指定は他の要素宣言でのsubstitution指定による代替要素の指定を前提するが、代替要素
の使用は、その要素がどこに出現できるかを分かりにくくするため、使用を避けるのが望ましい。要 素宣言はその出現する場所で直接指定すべきである。
6.2.4 ルート要素宣言に関連した規定
XML文書において最上位要素となるルート要素の宣言に関する規定を以下に示す。
[RED 1]
内容：
複数の異なる名前空間を持つスキーマファイルから構成されている標準の場合、ルー ト要素宣言は最上位に位置するスキーマファイルに含めるのが望ましい。
説明：
インクルード／インポートによるスキーマファイルの階層構造において、インクルード／インポー トした先のスキーマファイルにルート要素の宣言が含まれていると、スキーマを読む際、XML全体 の階層構造をたどりにくくなるため、そのようなスキーマの書き方は望ましくない。
6.3 属性宣言
属性宣言に関する規定を以下に列挙する。
[ATD 1]
内容： 属性はローカルとして定義するべきである。
説明：
本来、属性は要素に属するものとして考えられるべきであるため、グローバルとして定義するのは 望ましくない。
[ATD 2]
内容：
xsd:anyAttributeは使用するべきではない。
説明：
標準スキーマは、利用シナリオを明確に持ち、それにそって具体的なモデル化を行うべきである。
その観点から、何がそこに来てもよいようにしておくという指定は望ましくない。また、出現する属 性が不定となることは処理系構築の観点からも好ましくない。