標準XML Schema作成ガイドライン

(1)

標準 XML Schema 作成ガイドライン

第 1.0 版

2006 年 5 月 22 日

(2)

1. はじめに ...1 1.1 本ガイドラインが扱うスキーマ言語...1 1.2 本ガイドラインの対象読者...2 1.3 表記 ...2 1.4 ガイドラインの構成...3 1.5 規定記述形式 ...3 2. データの分析とモデル化...5 2.1 データモデリング手法...5 2.2 データ分析結果のXMLスキーマへの変換 ...7 2.3 データ分析を行う利点...8 3. モジュール化 ...10 3.1 モジュール化とは？そしてその利点...10 3.2 標準スキーマ開発におけるモジュール化...13 4. 全体的なスキーマ構成...17 4.1 全スキーマ共通規定...17 4.2 スキーマ記述の形式...19 4.3 インクルード、インポート...22 4.4 名前空間 ...25 4.5 履歴情報 ...26 4.6 コメントや説明に関して...26 4.7 他の標準スキーマ...27 4.8 サンプル・インスタンス...28 5. 命名規則 ...30 5.1 共通 ...30 5.2 要素名 ...31 5.3 型名 ...31 5.4 属性名 ...32 6. 定義と宣言 ...33 6.1 型定義 ...33 6.1.1 単純型規定...33 6.1.2 複合型規定...34 6.2 要素宣言 ...35 6.2.1 単純型に関する規定...35 6.2.2 複合型に関する規定...35

(3)

6.2.3 代替要素に関する規定...35 6.2.4 ルート要素宣言に関連した規定...36 6.3 属性宣言 ...36 7. その他の制限に関して...37 7.1 XML Schema機能 ...37 付録 1 ガイドライン規定項目一覧...38 付録 2 参考ガイドライン一覧...42 付録 3 参考標準スキーマ一覧...43

(4)

1. はじめに

インターネットの急速な浸透により、各業界においても XML によるデータ交換のための標準化への取り組みが進んでいる。この XML の標準化の鍵を握るのは、XML のスキーマの開発である。既に公開されている業界標準 XML スキーマを横断的に比較すると、その多くが W3C の XML Schema 規格に沿った標準開発を行っているとはいえ、定義や構築の方法はそれぞれ異なり、「誰もが読んで理解できる標準規格」が多くないことに気が付く。標準規格として普及浸透させるという観点から、スキーマは一般に分かりやすい構造でなければならならず、開発者だけが理解できるというのは望ましくない。今後の一層の情報化の進展に伴い XML Schema によるデータ交換のための規格策定の促進が予想される中、用途や業界などに関係なく、XML のスキーマ開発に関わる全ての開発者のための汎用的なスキーマ構築基準等を明確に示すことは有益である。この目的で XML Schema 技術の採用方法を明確に規定するガイドラインを表したのが本書である。この「標準XML Schema作成ガイドライン」は、W3Cが定めるXML文書の構造を定義する規格"XML Schema 1.0"1 に準拠したXMLスキーマを作成する開発者に対し、以下の点を考慮したスキーマの構築を行うよう提案を与えることを目的とする。用途・目的に応じた XML データ形式の定義更新、拡張を含め、メンテナンスの容易な XML スキーマの開発第三者にも理解しやすい XML スキーマの設計既存のより多くの XML 処理系（XML プロセッサ、XML データベース、及びアプリケーション）で処理可能であること 1.1 本ガイドラインが扱うスキーマ言語このガイドラインは、作成されるスキーマが W3C XML Schema 1.0 の規格に基づいて開発されることを前提に XML スキーマの定義方法に関連した規定を示す。XML のスキーマを定義する言語としては、他にも XML1.0 の中で定義された DTD（Document Type Definition）「文書型定義」もあるが、それらに関する規定はこのガイドラインには含まれない。

1

"Schema Part 1: Structures Second Edition XML Schema"と"Part 2: Datatypes Second Edition"か ら成る

(5)

1.2 本ガイドラインの対象読者

本書は、あらゆる分野、業界、組織において XML スキーマを作成する開発者を対象とする。読者には W3C が定める XML Schema 1.0 に関する基本的な知識が求められる。

1.3 表記

このガイドラインで定める規定の要求度を示すために使用されるキーワードは、The Internet Engineering Task Force（IETF）が定めるRFC-21192（IETFが発行する文章内で解釈されるべき要求度定義）に相当するものとする。 本ガイドライン使用キーワード RFC-2119 定義キーワード要求度説明 ∼しなければならない MUST SHALL REQUIRED 規定内容はどのような状況下でも絶対に満たされるべき条件である。 ∼してはならない MUST NOT SHALL NOT 規定内容はどのような状況下でも絶対に避けなければならない条件である。 ∼するべきである ∼することが望ましい SHOULD RECOMMENDED 特定の状況下においてこの規定を無視できる妥当な理由が存在してもよい。しかし、規定の意味を充分理解したうえで代替手段は決定されるべきである。 ∼するべきではない ∼することは望ましくない SHOULD NOT NOT RECOMMENDED ある行動が望ましい、或いは有用であるという妥当な理由が存在する状況において、この規定で否定されている行動を規定の意味を充分理解したうえで行うことも許されている。 ∼してもよい（任意である） MAY OPTIONAL 規定内容は任意である。表 1：キーワード対応表

(6)

1.4 ガイドラインの構成本文書「XML Schema 作成ガイドライン」は次の 6 章から構成されている。 1 章 – はじめに 2 章 – データの分析とモデル化 3 章 – モジュール化 4 章 – 全体的なスキーマ構成 5 章 – 命名規則 6 章 – 定義と宣言 7 章 – その他の制限に関して 1.5 規定記述形式このガイドラインで示す規定は以下の形式で記述される。基本的に『内容』、『説明』、『使用例』の 3 つの部分から成る。『内容』では直接的な規定事項が記述され、『説明』では『内容』に関する詳細な説明、また規定の理由について記述される。『使用例』は全ての規定に含まれるわけではなく、規定内容を補足する実際例や推奨される代替案などを示す。 [規定番号] 内容：説明：例：それぞれの規定には一意の『規定番号』が"RRRn"という形式で振られる。"RRR"は規定を分類する接頭辞を表し、n は連番を表す。規定分類接頭辞の値とその意味を以下の表に示す。 規定種類接頭辞 対応する規定種類 ATD 属性宣言 ATN 属性の命名 CTD 複合型定義 DOC 付属説明に関して ELD 要素宣言 ETN 要素の命名

(7)

GNR 共通命名規定 GXS XML スキーマの一般通則 IND インスタンス文書 NMS 名前空間 RED ルート要素宣言 SSM スキーマ構成のモジュール化 STD 単純型定義 TDN 型定義の命名表 2：ガイドライン分類接頭辞表このガイドラインで使用する用語を以下に列挙する。用語1【スキーマ】W3C が策定する XML Schema 1.0 に準拠して作成される XML Schema を指す。

(8)

2. データの分析とモデル化

XML スキーマを使用した標準を策定することに決めた段階で、そのスキーマの用途はある程度定まっていると考えられる。例えば、企業間で交換されるメッセージの形式を定義するものなのか、或いはある特定の分野における特定のデータ記述の形式を定義するものなのかといった具合である。また、それと同時にスキーマで記述形式が定義される対象となるデータもある程度絞り込まれていることであろう。標準スキーマを定義するにあたり、対象となるデータを分析し、それをモデル化するのは開発者にとっても、またスキーマを実際に使用するユーザにとっても非常に大切なプロセスである。特に開発者にとっては、目的に応じた標準スキーマを効率良く作成する上で必須のプロセスである。そしてユーザにとっては、標準スキーマを理解し運用する上で有用な説明資料となる。この項では、標準スキーマを定義する前の段階で行われることが望ましいデータ分析／モデル化に関し、その概要を説明する。 2.1 データモデリング手法データ分析は、対象となるデータの構造やそれを構成する部分の関連を分析するものであり、それを明確な形でモデル化する作業を伴う。このようなデータのモデル化はデータモデリングとも呼ばれ、一般的に ER 図（Entity Relationship Diagram）や UML（Unified Modeling Language）のクラス図といった手法が広く使用されている。どちらもスキーマの開発の基礎をなす上で非常に適している手法である。ここで、ER 図と UML のクラス図の概要を説明する。 ER 図は、対象データを構成する実体（エンティティ）とそれら実体間の関連（リレーションシップ）を概念的に表すモデルである。例えば、「ある会社が雇う従業員」という対象データを ER 図に表すとする。この場合、"会社"や"従業員"などデータの単位はエンティティとして表現される。それらエンティティ間は「雇う」という関連によって表現される。また、各エンティティが持つ固有の付属情報は『属性』として表現される。

(9)

会社雇う従業員名前住所 _所属 _名前住所エンティティ関連属性図 1：ER 図の例一方、クラス図は対象データを構成する部分をクラス（タイプ）に分類し、それらクラス間の関係（リレーションシップ）を概念的に表すモデルである。先の例を当てはめるとこの場合、"会社"や"従業員"はクラスという単位で表現される。そして、各クラスは付属情報を有する属性を持ち、クラス間の関係は線によって表現される。会社名前住所従業員所属名前住所雇う 1 0..* クラス関係属性図 2：クラス図の例データモデリング手法を詳細に記述することはこのガイドラインの目的ではないため、それらの手法については専門の解説書を参照されたい。どのようにデータ分析を行うかは開発者の判断に委ねられており、このガイドラインで

(10)

は特にどのデータモデリング手法を採用するようにという明示的な規定は示さない。しかし、標準スキーマを作成するに先立ち何らかの方法でデータ分析は必ず行われるべきであり、どのような手法を用いたのか、またその分析結果に関する詳細を目に見える形で、作成する標準スキーマの仕様書なりに記しておくのが望ましい。

例えば、そのような例として、地図や統計データの設計、管理、入力、検証、問い合わせと出力のための標準である Geography Markup Language（GML）は、データモデリングに UML を採用しているが、その詳細は Geography Markup Language 仕様書 Annex E： "UML-to-GML Application Schema Encoding Rules"に記述されている。

2.2 データ分析結果の XML スキーマへの変換標準スキーマで定義される対象データの分析結果が出たなら、次にそれをどのようにスキーマへ変換（反映）させるのか、一定のルールを定める必要がある。その際に、この「XML Schema 作成ガイドライン」で定める規定が適用されることが望ましい。前述した ER 図やクラス図で表現される概念的データモデルは、そのデータ構成を一貫した仕方でスキーマ定義へと変換することができるため、標準スキーマ作成に適したデータモデリングの手法である。 UML のクラス図からスキーマへの変換ルールの例を以下に示す。【クラス図からスキーマへの変換ルール例】ルール 1：クラスは要素として宣言するルール 2：クラスの属性はクラスの子要素として宣言するルール 3：関係は要素として表現し、関係において劣位にあるクラスがその子要素として含まれ、優位にあるクラスが子要素としてその要素を持つ先の UML のクラス図をこのスキーマ変換ルール例に適用し、「会社別従業員リスト」記述形式のためのスキーマを生成すると以下の通りとなる。

(11)

<xsd:element name="会社別従業員リスト"> <xsd:complexType>

<xsd:element ref="会社" maxOccurs="unbounded"/> </xsd:complexType>

</xsd:element>

<xsd:element name="会社" type="companyType"/> <xsd:element name="従業員" type="employeeType"/> <xsd:complexType name="companyType">

<xsd:sequence>

<xsd:element name="名前" type="nameType"/>

<xsd:element name="住所" type="addressType"/> ルール 2 ルール 1

<xsd:element name="従業員一覧" maxOccurs="unbounded"/>

</xsd:sequence> ルール 3

</xsd:complexType>

<xsd:complexType name="employeeType"> <xsd:sequence>

<xsd:element name="所属" type="departmentType"/> <xsd:element name="名前" type="nameType"/> <xsd:element name="住所" type="addressType"/> </xsd:sequence>

</xsd:complexType>

<xsd:element name="名前" type="xsd:string"/> <xsd:element name="住所" type="xsd:string"/> <xsd:element name="所属" type="xsd:string"/> <xsd:element name="従業員一覧">

<xsd:complexType> <xsd:sequence>

<xsd:element ref="従業員" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> ここで示すスキーマへの変換方法はあくまでも一つの例であり、様々なルール策定方法が考えられる。この「標準 XML スキーマ作成ガイドライン」はそのルールを決める際に参考されたい。 2.3 データ分析を行う利点データ分析を行う利点を 2 つの観点から考える。1 つ目に標準スキーマを普及させ標準として定着させるという観点、そして 2 つ目に標準スキーマの長期的な管理という観点である。

(12)

理解しやすさ、使いやすさである。データ分析を行うことで、対象となるデータの概念がより明確になるため、不必要な情報が含まれたり、必要な情報が見過ごされたりという状況を避けることができる。また、標準スキーマを管理するという観点からもデータ分析を行う必要性を理解することができる。標準スキーマ開発の基礎となるデータ分析を行い、それをスキーマへ反映するルールがあるなら、それにそって開発することにより将来的に開発者が変わったとしても統一した方法でスキーマを管理することができる。また、スキーマの拡張が必要となった場合には一定の方法に従って拡張することにより標準全体として統一のあるスキーマを作成することが可能となる。このように、たとえ既存の物理的なフォームを XML 形式へ変換するだけであっても、可能な限り対象となるデータの再分析を何らかのデータモデリング手法を用いて行い、それをスキーマに反映させるルールを記述しておくことが望ましい。

(13)

3. モジュール化

標準スキーマにおいて考慮すべき重要な点として、スキーマ開発の効率性や開発後のメンテナンス容易性が挙げられる。モジュール化という手法は、これらの実現を助けるものとなる。この章では、まず初めに、モジュール化とは何か、またそれがどのように標準スキーマ開発に求められる要件に寄与するのかについて概略を説明する。その後、標準スキーマ開発におけるモジュール化の方法を提案する。 3.1 モジュール化とは？そしてその利点標準 XML スキーマ開発におけるモジュール化とは、スキーマ定義を種類や機能別に整理し、複数のスキーマファイルに分割することである。分割されたスキーマファイルは XML Schema のインポート機能、或いはインクルード機能を使って参照する。標準スキーマは、策定する目的や対象によって単体のデータ構造を定義する場合と複数のデータ構造をまとめて一つの標準スキーマ内で定義する場合の二通りあるが、どちらの場合もモジュール化は行うことが可能である。単体の XML データ形式を定義する標準において、それ自体の内容量が膨大で複雑になる場合、スキーマ定義を種類ごとに分割しモジュール化を行うことにより、管理のしやすさやスキーマ構造の理解のしやすさが向上する。その例として、文章形式を定義する標準スキーマである DocBook がある。DocBook は一つのデータ構造を定義するものであるが、そのスキーマ定義は４つのスキーマファイルにその定義種類ごとに分割して記述されている。主なスキーマ定義は 3 つのスキーマファイルで行われ、それらをルートスキーマである docbook.xsd がインクルードして使用する。ここでいうルートスキーマとは、スキーマファイル構造において最上位に位置し、インスタンスから指定されるスキーマファイルのことである。

※OASIS (Organization for the Advancement of Structured Information Standards)の DocBook Technical Committee で策定された DocBook4.2 では、公式にはスキーマとして DTD を提供している。OASIS からもリンクされている http://www.docbook.org/で掲載されているのは、その DTD を変換して XML Schema 化したもの。公式の XML Schema はバージョン 5.0 で検討中である。

(14)

docbook.xsd DocBook文書のルートスキーマ dbpoolx.xsd DocBook文書の構成部分の定義 dbhierx.xsd DocBook文書の全体的な階層構造の定義 dbnotnx.xsd DocBook文書の構成要素の定義

DocBook

図 3：DocBook 標準を構成するモジュールスキーマファイルこれに対し、複数の XML データ構造の定義をまとめて一つの標準として提供する場合、標準を構成する複数のスキーマ間で共通する部分を抜き出し、モジュールとして取り分けておくならば、部品として再利用を行うことができ、開発効率の向上につながる。例えば、企業間で取引する商品の見積書と請求書を交換するための標準規格を作成するとする。モジュール化を行わない場合、以下に図示するように商品名や型番など両方に共通して定義される商品情報のための定義がそれぞれのスキーマに個別に含まれることになる。

<xsd:element name=“見積書” type=“quotationType”/> <xsd:complexType=“quotationType”>

<xsd:sequence>

<xsd:element name=“商品” productInfoType”/> ・・・ </xsd:sequence> ・・・見積書.xsd <xsd:complexType=“productInfoType”> <sequence>

<xsd:element name=“商品名” type=“productName”/> <xsd:element name=“型番” type=“model”/> ・・・

</xsd:complexType>

<xsd:element name=“請求書” type=“invoiceType”/> <xsd:complexType=“invoiceType”>

<xsd:sequence>

<xsd:element name=“商品” productInfoType”/> ・・・ </xsd:sequence> ・・・請求書.xsd <xsd:complexType=“productInfoType”> <sequence>

</xsd:complexType> 同一の

スキーマ定義

(15)

しかし、両方に含まれる同一のスキーマ定義部分を抜き出して別のスキーマファイルに定義し、それぞれのスキーマが XML Schema のインポート、或いはインクルード機能を介しそのモジュール化されたスキーマファイルを使用することにより、標準スキーマ開発において同じスキーマ定義を繰り返し定義するという無用な手間を省くことができる。

<xsd:element name=“見積書” type=“quotationType”/> <xsd:complexType=“quotationType”>

<xsd:sequence>

<xsd:element name=“商品” productInfoType”/> ・・・ </xsd:sequence> ・・・見積書.xsd <xsd:complexType=“productInfoType”> <sequence>

</xsd:complexType>

<xsd:element name=“請求書” type=“invoiceType”/> <xsd:complexType=“invoiceType”>

<xsd:sequence>

<xsd:element name=“商品” productInfoType”/> ・・・ </xsd:sequence> ・・・請求書.xsd 共通スキーマ定義.xsd ・・・・・・インポートインポート図 5：共通スキーマ定義部分のモジュール化例このように、スキーマのモジュール化はスキーマファイルの再利用が可能となり、効率的なスキーマ作成が行える点で利点がある。また、共通スキーマ定義部分に変更が必要になった場合でも、モジュール化を行っているならば一箇所に修正を加えるだけで済むため、標準スキーマのメンテナンス容易性からもその利点は大きい。複数のデータ構造を定義する標準スキーマでモジュール化を行っている代表的なものとして、宿泊施設、交通機関と旅行代理店の間で手配に必要な情報交換を行うことを目的とした複数のメッセージ形式を定義する Open Travel Alliance（OTA）や企業の各種財務情報を公開・交換するためのデータ形式を定義する Extensible Business Reporting Language（XBRL）がある。

モジュール化の主な利点 ■スキーマ可読性の向上

■スキーマ定義の再利用による開発効率の向上 ■メンテナンス容易性の向上

(16)

3.2 標準スキーマ開発におけるモジュール化ここまでの説明で分かるように、標準スキーマ開発において、小規模なスキーマを除きモジュール化を行うことが望ましい。モジュール化の方法は、作成する標準スキーマの基盤となるモデルによってそれぞれ異なると考えられるが、ここでは、様々なケースに応用可能な汎用的なモジュール化手法について説明する。まず、モジュール化の基本的な枠組みとして、スキーマ定義をその構造上の役割の観点から以下のような３つの階層構造に分けて考えるとよい。この階層構造を個別のスキーマファイルとして分割してモジュール化し、それらはインクルード／インポート機能を使って参照される。 ---①フレームワーク ---スキーマで定義するデータ・メッセージの全体的な枠組み（フレームワーク）の定義・ルート要素、全体的な枠組を構成する要素宣言 ---②コンポーネント ---フレームワークに取り込まれる様々な要素構造（コンポーネント）の定義・複合型要素宣言、及びその型（complexType）定義 ---③要素 ---コンポーネント内で使用される、実際にデータを持つ要素宣言・単純型要素宣言、及びその型（simpleType）定義図 6：スキーマ定義のモジュール化における 3 つの階層このモジュール化を応用した、最も簡単なスキーマ構築パターンは以下の通りである。

(17)

---フレームワーク ---コンポーネント ---要素 ---インポート/インクルードインポート/インクルードスキーマ定義データ構造図 7：最も簡単なモジュール化の応用例複数の個別データ構造を一つの標準として定義する場合（例えば、複数のメッセージをまとめて XML で標準化する場合など）、先のモジュール化の手法を以下のように組み立てて応用することができる。個別のデータ構造はそれぞれ固有なフレームワーク、コンポーネント、要素定義から成り立っているが、それらが複数存在することにより共通部分が見出されるならその部分は共通スキーマファイルとして外に出し、さらにモジュール化した後、インポート・インクルードを介して個別スキーマ定義により使用される。

(18)

共通定義 ---コンポーネント ---要素 ---インポート/インクルード ---フレームワーク ---コンポーネント ---要素 ---データ構造A インポート/インクルードインポート/インクルード ---フレームワーク ---コンポーネント ---要素 ---データ構造A インポート/インクルードインポート/インクルード ---フレームワーク ---コンポーネント ---要素 ---データ構造B インポート/インクルードインポート/インクルードインポート/インクルードスキーマ定義図 8：複数のデータ構造を定義する標準でのモジュール化の形態さらにこれを発展させたモジュール化の例として、全てのデータ構造定義に共通しないとしても、いくつかのコンポーネント及び要素定義の間で共通する部分が観察された場合、それらコンポーネント群を種類別に分類し、個別のデータ構造定義がそれぞれ必要とするコンポーネントのみをインポート・インクルードして使用するという手法も考えられる。ここで言う「種類別」とは、XML スキーマの定義そのものの種類ではなく、XML スキーマによって実際に定義される XML 文書の構成部分が持つようになる情報の種類によって分類するという意味である。

(19)

---種類Aとして分類されるコンポーネント及び要素 ---種類別に分類されるコンポーネント群 データ構造A データ構造B データ構造C ---種類Bとして分類されるコンポーネント及び要素 ---種類Cとして分類されるコンポーネント及び要素 ---共通定義 ---コンポーネント ---要素 ---インポート/インクルード ---フレームワーク ---コンポーネント ---要素 ---データ構造A インポート/インクルードインポート/インクルード ---フレームワーク ---コンポーネント ---要素 ---データ構造A インポート/インクルードインポート/インクルード ---フレームワーク ---コンポーネント ---要素 ---データ構造B インポート/インクルードインポート/インクルードインポート/インクルードスキーマ定義 ---フレームワーク ---フレームワーク ---フレームワーク ---スキーマ定義必要分のみをインポート/インクルード共通定義 ---コンポーネント ---要素 ---インポート/インクルードインポート/インクルード図 9：複数のデータ構造を定義する標準でのモジュール化の形態このようにコンポーネント群を種類別に分類することにより、作成者にとってコンポーネント定義に対して修正が必要となった場合もそのコンポーネント定義が識別しやすくメンテナンス容易性が高まり、またユーザにとっても分類されていることから目的に合った定義を見つけやすいという利点がある。ここまでに、スキーマ定義をフレームワーク、コンポーネント、要素定義に分けた上でそれらを組み合わせるという汎用的な手法としてモジュール化の形態を説明した。しかし、作成する標準スキーマのベースとなるデータモデルは様々であり、どのようなモジュール化の形態を取るべきかも異なるであろう。したがって、個々の標準スキーマ開発者は、ここで説明したようなモジュール化の形態を参考にしつつ、作成する標準スキーマの性質に合った適切なモジュール化を構築すればよい。

(20)

4. 全体的なスキーマ構成

この章では、全体的なスキーマ構成に関する規定を行う。 4.1 全スキーマ共通規定作成する標準スキーマを構成する全てのスキーマファイルが満たすべき共通規定を以下に列挙する。主に、全ての XML スキーマファイルに必ず定義される XML スキーマ定義言語のルート要素である schema 要素記述に関する規定である。 [GXS 1] 内容：全てのスキーマファイルの先頭に文字コード指定を含めたXML 宣言を記述しなければならない。説明：明示的に文字コードを含むXML 宣言があることにより、処理系がそのスキーマファイルを扱い易くなり、また、ユーザが通常のエディターでそのファイルを開いてスキーマを読むときにも、文字コード情報を手がかりにエディターを設定し、正しく文字を表示することができる。例： <?xml version="1.0" encoding="UTF-8"?> [GXS 2] 内容： XML 宣言に含まれる文字コード指定には UTF-8 を指定するのが望ましい。説明：標準スキーマが動作環境やアプリケーションの言語に関係なく対応できるようにするため、一般的に広く利用されているUTF-8 を基本の文字コードとして指定するのが良い。 [GXS 3] 内容： W3C XML Schema の名前空間接頭辞は"xsd"、或いは"xs"を使用するのが望ましい。説明：スキーマ定義の接頭辞は、一般的に使用されている"xsd"、或いは"xs"を使用することによりスキーマ定義部分が明確になる。標準が複数のスキーマファイルから構成される場合、全てのスキーマファイル間で共通の接頭辞を使用するのが望ましい。例： xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"

(21)

[GXS 4] 内容：作成する標準スキーマに名前空間を割り当て、それを対象名前空間として宣言しなければならない。説明：標準スキーマは、インポートして使用されることにより、他の標準スキーマと共に使用される場合もあるため、混在する標準スキーマの区別が明確になるよう名前空間を割り当てることは必要である。 [GXS 5] 内容：デフォルトの名前空間宣言は対象名前空間だけに許されることが望ましい。説明：接頭辞の記述が必要のないデフォルトの名前空間をスキーマファイル内で宣言する場合、標準スキーマの対象名前空間だけを指定可能と定めておくことにより、理解のしやすいスキーマとなる。 [GXS 6] 内容：実際に使用しない、或いはインポートを行わない名前空間の接頭辞宣言を含めるべきではない。説明：実際に使用されない不要な名前空間を宣言するのは、それを読むユーザの混乱を招くので避ける。 [GXS 7] 内容： elementFormDefault="qualified"と指定するのが望ましい。説明：この指定を明示的に<xsd:schema>要素に含めることにより、ローカルに宣言される要素も自動的に標準スキーマの対象名前空間に属するものとして扱われるようになる。（ローカルに宣言される要素のxsd:element 要素に form 属性の指定が含まれなくても名前空間が割り振られる）。このようにして、宣言される全ての要素が確実に標準スキーマの名前空間に属するものとなる。 [GXS 8] 内容： attributeFormDefault="unqualified"と指定するのが望ましい。説明： XML では本来、属性は要素に属するものという概念で考えられるため名前空間を振り当てる必要がない。また、グローバル属性と区別するためにもこの指定は必要である。明示的にこの指定を行わなくてもattributeFormDefault のデフォルト値は"unqualified"となっているので問題はないが、ユーザが分かりやすいようこれを明記するのが親切である。

(22)

[GXS 9] 内容：スキーマにDOCTYPE 宣言（スキーマ自体を XML 文書と見立ててその DTD を示すための宣言）を含めてはならない。説明：標準スキーマはXML Schema 規格に準拠して開発されることが前提なので、DOCTYPE 宣言は必要ない。（現在XML Schema 規格に対応したツールが DOCTYPE 宣言を使ってスキーマファイルの妥当性検証を行うことはない。） [GXS 10] 内容：標準スキーマ自体が書かれた言語を識別するため、xml:lang 属性を使用して言語を指定しなければならない。説明：作成する標準スキーマを、例えば一般的な共通語とみなされている英語で記述したとしても、 xml:lang を使用した明示的な指定がないなら標準スキーマを利用するアプリケーションなどは言語コードを理解することが不可能である。言語コードは、ブラウザ等の表示に加えて検索エンジンや音声合成にも役立つ情報を提供する。 [GXS 11] 内容：空のインポート宣言を含めるのは望ましくない。説明： W3C XML Schema の規格上インポートするスキーマを指定しない空のインポート宣言 <xsd:import/>を記述することは許されているが、スキーマ処理上意味はなく、混乱を避けるためにそのような指定はスキーマ中に含めないほうがよい。その場合は、コメント文など他の方法を使うべきである。例：空のインポート宣言とは次の通りである。 <xsd:import/> 4.2 スキーマ記述の形式標準スキーマ開発に関する一貫した方法を定める中で、スキーマ記述の形式を規定しておくことも重要である。標準スキーマが複数のスキーマファイルから構成される場合、複数の開発者がスキーマを記述することも考えられるが、そのようなときに記述形式が定められていることによって、スキーマ開発者がスキーマ定義記述を迷わず進めることができ、また、形式が統一されていることによって、標準スキーマを使用するユーザにとっても、そのスキーマは理解しやすいものとなる。

(23)

[GXS 12] 内容：事前にスキーマ記述の形式を定め、それに沿ってスキーマを作成するのが望ましい。説明：このガイドラインで定める推奨スキーマ記述形式は以下の通りとする。例： (注記：/**/内はコメント、"<>"内はユーザ指定) +--- <?xml version="1.0" encoding="UTF-8"?> /* XML 宣言 */ <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" /* XML スキーマ接頭辞指定 */ xmlns:xml= http://www.w3.org/XML/1998/namespace" /* XML 名前空間 */ targetNamespace=""<スキーマ対象名前空間>"" xmlns=""<スキーマ対象名前空間>"" /* デフォルトの名前空間指定 */ xmlns:"<接頭辞>"=""<インポートするスキーマの名前空間>"" /* ある場合のみ列挙 */ elementFormDefault="qualified" /* 要素名前空間修飾指定 */ attributeFormDefault="unqualified" /* 属性名前空間修飾指定 */ xml:lang=""<言語コード>"" /* 言語コード指定 */ > "<インポート・インクルード宣言>" /* ある場合のみ列挙 */ "<スキーマ定義>" </xsd:schema> +--- [GXS 13] 内容：スキーマ定義の順番を定め、それに沿って記述を行うのが望ましい。説明：スキーマ定義の順番に関しては様々な方法が考えられるが、一定の決まりを設けておくならば整理された、理解しやすいスキーマ作成が可能となる。標準スキーマの種類や構成にもよるが、単体のスキーマファイル、そしてモジュール化された複数のスキーマファイルから構成される標準スキーマにおける一般的なスキーマ定義順はそれぞれ以下の通り。例： ① 単体のスキーマファイルで構成される場合ルート要素を始点として階層を下方向へ辿った順に記述 +--- <xsd:element name="RootElement"> <xsd:complexType> <xsd:element ref="elementA"/> <xsd:element ref="elementB"/> … <xsd:complexType> </xsd:element> <xsd:element name="elementA"> <xsd:complexType>

(24)

…

<xsd:complexType> </xsd:element>

<xsd:element name="elementA1" type="xsd:string"/> <xsd:element name="elementB"> <xsd:complexType> <xsd:sequence> <xsd:element ref="elementB1"/> … </xsd:sequence> <xsd:complexType> </xsd:element> … +--- ② モジュール化された複数のスキーマファイルで構成される場合 (これはモジュール化が「3.2 標準スキーマ開発におけるモジュール化」で示したようにスキーマ定義が「フレームワーク」、「コンポーネント」、「要素」の3 種類に分割されている場合を想定した例である。) １．「フレームワーク」スキーマファイルルート要素を始点として階層を下方向へ辿った順に記述 +--- <xsd:element name="RootElement"> <xsd:complexType> <xsd:sequence> <xsd:element ref="elementA"/> <xsd:element ref="elementB"/> … </xsd:sequence> <xsd:complexType> </xsd:element>

<xsd:element name="elementA" type="elementAType"/> <xsd:element name="elementB" type="elementBType"/> … +--- ２．「コンポーネント」スキーマファイル階層の高いものから、その子要素を優先として下方向へ辿った順に記述 +--- <xsd:complexType name="elementAType"> <xsd:sequence> <xsd:element ref="personalInfo"/> </xsd:sequence> </xsd:complexType>

<xsd:element name="personalInfo" type="personlInfoType"/> <xsd:complexType name="personalInfoType"> <xsd:sequence> <xsd:element ref="name"/> <xsd:element ref="age"/> <xsd:element ref="address"/> </xsd:sequence> </xsd:complexType>

(25)

<xsd:complexType name="elementBType"> … </xsd:complexType> … +--- ３．「要素」スキーマファイルたとえばアルファベット順に記述すると、一般に探しやすいと思われる +---

<xsd:element name="address" type="xsd:string"/> <xsd:element name="age" type="xsd:integer"/> <xsd:element name="name" type="xsd:string"/> … +--- 4.3 インクルード、インポート標準スキーマが複数のスキーマファイルから構成されている場合、或いは他の標準スキーマを使用する場合などは、XML Schema のインポートやインクルード機能を使用することになる。これらは特にモジュール化を行っている標準スキーマにとっては必須の機能であるが、使用の方法によってはスキーマファイル間の関係を複雑にしてしまう可能性もあり、ユーザにとって理解しやすいスキーマとは言えなくなってしまうこともある。また、モジュール化によって実現するメンテナンス容易性も複雑なスキーマファイルの複雑な関係により逆に損なわれてしまう可能性もある。このように、インクルードとインポートは有用な機能であると同時に、その使用に関しては十分な注意が必要である。以下にインクルードとインポート機能に関わる規定を示す。 ※注釈：以下、インクルードとインポートに共通する規定は、インクルード（インポート）と記す。 [SSM 1] 内容：インクルード（インポート）を行うスキーマファイルからインクルード（インポート）されるスキーマファイルを矢印で表した時、他のスキーマファイルを介して矢印が自分に戻ってくるような循環的なインクルード（インポート）を行うことは望ましくない。説明：循環的なインクルード（インポート）は規格上禁止されているわけではないが、そのような指定はスキーマ定義を複雑にし、ユーザの混乱を招くので避けるのがよい。循環的なインクルード（インポート）の例を以下に図示する。

(26)

SchemaA.xsd <xsd:include schemaLocation=“SchemaB.xsd”/> SchemaB.xsd <xsd:include schemaLocation=“SchemaC.xsd”/> SchemaC.xsd <xsd:include schemaLocation=“SchemaA.xsd”/> インクルードインクルードインクルード図 10：循環的なインクルード（インポート） SchemaA.xsd <xsd:include schemaLocation=“SchemaB.xsd”/> SchemaB.xsd <xsd:include schemaLocation=“SchemaA.xsd”/> インクルードインクルード図 11：相互のインクルード（インポート） [SSM 2] 内容：実際に使用するスキーマ定義を含むスキーマファイル以外の不要なスキーマファイルをインクルード（インポート）するべきではない。説明：スキーマ定義中で他のスキーマファイルに含まれるスキーマ定義を参照する場合に限りインクルード（インポート）を行うべきであり、必要の無いスキーマファイルをインクルード（インポート）することは標準スキーマを利用するアプリケーションなどに掛かる負担を増すだけである。このようなケースは、ある時点で参照されていた要素などが削除されることにより、その定義を含むスキーマファイルのインクルード（インポート）が必要なくなったにも関わらず、インクルード（インポート）の宣言だけが残るといった場合に起こることがある。

(27)

[SSM 3] 内容：あるスキーマファイル中の定義で、他のスキーマファイルで定義されている要素や型を参照している場合、そのスキーマファイルを明示的にインクルードすることが望ましい。説明：あるスキーマファイル（A）中で参照している要素や型が他のスキーマファイル（B）で定義されている場合、さらに別のスキーマファイル（X）がそれら２つをインクルード／インポートすることによって参照関係は解決される。しかし、スキーマファイル（A）が明示的にスキーマファイル（B）をインクルード／インポートしていないなら、そのスキーマファイル（A）のみを利用しようとした場合には、その参照関係は解決されないことになり、モジュール化されたスキーマファイルの自立性の観点から好ましくない。

スキーマファイルX

<xsd:include schemaLocation=“スキーマA”/> <xsd:include schemaLocation=“スキーマB”/>

スキーマファイルB

<xsd:element name=“A”> ・・ </xsd:element>

スキーマファイルA

<xsd:element name=“B”> ・・ <xsd:element ref=“A”/> ・・ </xsd:element> インクルード明示的なインクルード指定なし図 12：局所的（スキーマファイル A、スキーマファイル B）に見た場合、直接的なインクルード指定がないスキーマ定義の例 [SSM 4] 内容：インクルード対象となるスキーマ・ファイルにもすべて標準スキーマの対象名前空間宣言を含めるのが望ましい。説明： XML Schema の規格では、あるスキーマファイルに対象名前空間の宣言がなくても、それをインクルードするスキーマファイルで宣言された名前空間に属するものと解釈されることになっているが、インクルードされるスキーマファイルも標準スキーマの一部であることを明確にするため、インクルードするスキーマで宣言される対象名前空間を宣言するべきである。

(28)

[SSM 5] 内容：対象名前空間が宣言されていないスキーマをインポートしてはならない（インポート宣言にはnamespace 属性が含められなければならない）。説明：規格上このようなインポートも許されているが、そこで定義されている要素などを参照する際に名前空間接頭辞を付けないため、通常行われるデフォルト名前空間と混乱する。分かりやすい標準スキーマを記述するという観点からこれは許されるべきではない。 4.4 名前空間名前空間はスキーマ定義を標準スキーマとして識別するものであり、全てのスキーマファイルに対して対象名前空間が割り当てられるべきである。この項では、名前空間を決める際の注意点や提案などに関連した規定を示す。 [NMS 1] 内容：名前空間にURI を使用してもよい。説明：名前空間はスキーマごとに一意の値でなければならない。その点、リソースを識別するための一意の名前を与える構文であるURI (Uniform Resource Identifiers)はその目的に適している。

[NMS 2] 内容：対象名前空間にバージョン情報を含めるのが望ましい。説明：対象名前空間にバージョンを記述することにより、スキーマが更新されバージョンが上がった場合の区別が容易である。つまり、バージョンが上がれば名前空間も変更されることになる。例： targetNamespace="http://www.naming-and-design-guideline/namespace/ver1.2 [NMS 3] 内容：一度公開された標準スキーマの対象名前空間は変更してはならない。説明：公開されている標準スキーマに修正を加える場合、新バージョンとして新しい名前空間が割り当てられるべきであり、既存のスキーマの名前空間名を変えてはならない。それがすでに活用されている場合、インスタンスとの整合性が保たれないからである。

(29)

4.5 履歴情報標準スキーマの管理という観点から、ある程度の履歴情報をスキーマに含めるのは妥当なことである。 [GXS 14] 内容：更新日、更新者、更新のベースとなったバージョンなど履歴情報をスキーマに含めるのが望ましい。説明：更新履歴情報を含めることにより最新版のスキーマがどれかを判別しやすくなり、また、初版から現バージョンに至るまで順を追う際にも役立つ。前バージョンとの違いを簡潔に記すのも良い。更新履歴情報は、XML スキーマのコメントや xsd:annotation を使用して記述することができる。 [GXS 15] 内容：スキーマファイル名にもバージョン番号を含めるのが望ましい。説明：スキーマファイルがどのバージョンに属するものかが一目瞭然となり、間違ったバージョンのスキーマファイルを使用することが避けられる。例： "invoice-1.0.xsd" "invoice-1.1.xsd" 4.6 コメントや説明に関して実際に標準スキーマを利用するユーザにとって、要素の用途など定義に関する簡単な説明はスキーマを理解するうえで役に立つ。XML のスキーマは XML 文書の構成定義が主な目的なため仕様書に記述するような詳細な説明は含める必要はないが、簡潔な注記を含めるとユーザによって親切な、分かりやすいスキーマとなる。 [DOC 1] 内容： xsd:annotation 要素の xsd:documentation 要素を使った説明文は簡潔に記述することが望ましい。説明：定義に関する簡単な説明を記述することは、第三者がスキーマを理解する上で役に立つ。しかし、仕様書に本来書くような詳細情報をスキーマ内に記述するのは冗長であり、アプリケーションに負担が掛かるため避けるべきである。

(30)

[DOC 2] 内容：ルート要素宣言にはxsd:annotation、或いはコメントを使用してルート要素であることを明示的に示さなければならない。説明： XML 文書において最上位の要素となるルート要素のスキーマ定義に関する規定を定めることは、標準スキーマの読みやすさ、理解のしやすさという観点から非常に重要である。一般的な現行標準スキーマを概観すると、ルート要素宣言の記述方法はそれぞれに異なり、中にはどれがルート要素なのか判別するのさえも困難なものがある。もちろんサンプル・インスタンスがスキーマファイルと共に公開されている場合はルート要素の判断は簡単だが、そうでない場合、ルート要素を特定するためにスキーマ定義を順に辿る手間を防ぐためにもルート要素を明確に示す必要がある。例： xsd:annotation 要素を使用した注記。 +--- <xsd:element name="RootElement"> <xsd:annotation> <xsd:documentation>この要素はこの標準スキーマに基づいて作成されるインスタンス文書においてルート要素として使用される。</xsd:documentation> </xsd:annotation> <xsd:complexType> … </xsd:complexType> </xsd:element> +--- [DOC 3] 内容： xsd:appInfo を使用してはならない。説明： xsd:appInfo は、xsd:annotation 内でスキーマを実装するシステム等に利用される情報を記述するものである。標準スキーマは特定のシステム、アプリケーションなどに限定されずに使用されるものであるため、スキーマ定義に記述する必要はない。 4.7 他の標準スキーマ作成しようとしている標準の要件を満たし、既に標準 XML スキーマとして確立されている標準があれば、それらを流用することにより開発の手間が省ける。同時に、既存の標準スキーマに精通しているユーザにとっては、作成される標準が完全に新規のものではなく、一部を既に理解しているため、そのスキーマを受け入れやすく、標準スキーマの普及という面での利点もある。

(31)

[GXS 16] 内容：作成するスキーマの要件を満たす既存の標準スキーマがあれば、それをインポートして使用するのが望ましい。説明：既に一般的に使用されている標準スキーマを使用することにより、開発の手間が省ける。また、既存の標準に精通しているユーザにとっては受け入れやすいものとなる。ただし、注意する点として、使用する標準スキーマの普及状況や信頼性を充分把握し、採用するかどうかに関する入念な考慮が必要である。例：

メタデータ記述のためにDublin Core Metadata Element Set （http://dublincore.org/documents/dces/）を使用することができる。 4.8 サンプル・インスタンス標準スキーマを公開する際、その定義に沿って作成されるサンプルとなるインスタンスを提供することが望ましい。作成するスキーマを標準として普及させるためには、ユーザの立場から見た標準スキーマの使い方を的確に提示しなければならないからである。複雑なスキーマになるほどサンプル・インスタンスの必要性は増す。ここでは、標準スキーマの普及に影響を及ぼす可能性のあるサンプル・インスタンスに関連した規定を提示する。 [IND 1] 内容：スキーマを公開する際、サンプルとなるインスタンスも共に公開するのが望ましい。説明：標準スキーマで定義するデータ形式が実際に目に見える形でサンプル・インスタンスを提供する。その際、スキーマ定義の一部ではなくできるだけ全体を網羅するサンプルを提供するべきである。また、標準スキーマが複数のデータ構造を定義する場合、見込まれる全てのケースを例示するサンプル・インスタンスを用意する。インスタンスは、作成する標準スキーマの適合性を試験する上でも必要となる。 [IND 2] 内容：全てのサンプル・インスタンスには文字コード指定を含むXML 宣言が含めるべきである。説明：サンプル・インスタンスは、まずユーザが読むことを目的としているので、明示的な文字コード指定を行うことにより、エディターでの編集が容易にするべきである。例： <?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="Shift_JIS"?>

(32)

[IND 3] 内容：公開するサンプル・インスタンスにはxsi:schemaLocation を使い、対応するスキーマファイルを指定するべきである。説明：汎用のXML プロセッサなどは、xsi:schemaLocation を使ってスキーマファイルを特定し、妥当性検証を行うことが多いため、最初からその指定が含まれていると便利である。また、一つの標準スキーマで複数のデータ構造が定義されており、個々のデータ構造が別個のスキーマファイルで表現されている場合など、複数のファイルの中から使用すべきスキーマファイルを探す手間を省くためにも xsi:schemaLocation でスキーマファイル名が分かると便利である。

(33)

5. 命名規則

5.1 共通要素、型、そして属性に共通する命名規則を以下に定める。 [GNR 1] 内容：マルチバイト文字（漢字、ひらがな、カタカナなど）は使用してはならない。説明：スキーマの標準化および国際的な利用という観点から、作動環境やアプリケーションによって対応できない可能性のあるマルチバイト文字は避け、アルファベットなどのシングルバイト文字を使用する。 [GNR 2] 内容：名前には英単語を使用するのが望ましい。説明：標準スキーマとして国際的にも普及させるため日本語を使用したローマ字表記は避け、汎用語として英単語を使用する。 [GNR 3] 内容：冗長な名前は避け、簡潔で情報を的確に識別する名前を付けるべきである。説明：理解しやすい標準スキーマを作成するうえで重要な点である。要素名や属性名は、最終的にはスキーマに準拠したインスタンスでも使用され、ユーザが読む可能性があるため、読みやすい簡潔な名前が求められる。 [GNR 4] 内容：略語の使用は控えるべきである。説明：一般的に使用されている略語、例えば識別子を表すID や番号を表す Num などを除き、略語の使用は極力控えるべきである。ただし、専門用語あるいは業界用語として想定利用者間で周知の略語の場合はこの限りではない。また、本来命名したい名前が非常に長く、略す必要に迫られることもあるかもしれない。その場合には、略語の意味が分かるようにxsd:annotation などを使って説明を加えるべきである。 [GNR 5] 内容：他の標準スキーマをインポートして使用する場合、他の名前空間で宣言されている要

(34)

素、型、また属性と重複した名前を使うことを避けるのが望ましい。説明：属する名前空間が異なれば名前（ローカル名）が重複していたとしても問題はない。しかし、混乱を避けるため、同じ名前を使わないよう心がけるのが望ましい。 5.2 要素名要素に特有な命名規定を以下に列挙する。 [ETN 1] 内容：要素名が複数の単語から成る場合、UpperCamelCase ルールを採用するのが望ましい。説明： UpperCamelCase とは、単語の頭文字を大文字で表現することである。そのようにすることにより、要素名が読みやすくなる。例：組織の損益計算書をXML 形式で記述した場合、そのルート要素を<ProfitAndLossAccount>とするほうが<profitandlossaccount>とするよりも読みやすい。 5.3 型名型に特有な命名規定を以下に列挙する。 [TDN 1] 内容：型の場合、型名の最後に"∼Type"と付けるのが望ましい。説明：要素宣言と区別し、それが型宣言であることをより分かり易くするためこのような命名規則が必要となる。この意味では、混乱を避けるため、要素名や属性名に"∼Type"という名前を付けるのを避けるべきである。例： <xsd:complexType name="addressType"> <xsd:sequence> … </xsd:sequence> </xsd:complexType> [TDN 2] 内容：定義される型が特定の要素だけに使用される場合、その要素名を型名に含めるのが望ましい。

(35)

説明：

定義する型が複数の要素によって参照される場合は一般的な名前を付けることができるが、特定の要素だけに使用される場合、その要素に特化した型であることを明示的に示すためにこのようにすることが望ましい。

例：

<xsd:element name="address" type="addressType">

5.4 属性名属性に特有な命名規定を以下に列挙する。 [ATN 1] 内容：ローカルな属性を定義する場合、属性を宣言する要素と同じ名前を付けるのは望ましくない。説明：標準スキーマに沿って作成されるインスタンスを読みやすくするため要素と属性の名前は分けるのが望ましい。例： XML スキーマ +--- <xsd:element name="note"> <xsd:complexType> …

<xsd:attribute name="note" type="xsd:string"/> </xsd:complexType> +--- XML インスタンス +--- <note note="status"> shipping </note> +---

(36)

6.

定義と宣言 6.1 型定義この項では、型がグローバル型として（名前付きで）定義される場合、また要素宣言に含まれる匿名の型として定義される場合の両方に共通する規定を提示する。定義する型は、単純型か複合型かに関係なく、XML Schema において全ては派生型である（単純型の場合は XML Schema のビルトインデータ型をベースとした派生型であり、複合型の場合は xsd:anyType 型をベースとした派生型である）。従って、この項では xsd:restriciton や xsd:extension の使用上の規定をも含める。 6.1.1 単純型規定単純型定義に関する規定を以下に示す。単純型定義とはビルトインデータ型をベースとした派生型の定義であり、その取り扱いに関する規定もここに含む。 [STD 1] 内容： xs:union の使用は望ましくない。説明： 1 つの要素や属性で複数のデータ型を受け付けられるというのは使用する側の混乱を招く。複数の単純データ型の和を受け付けるようにするxs:union を使用するのではなく、データ型別に異なる要素や属性を使用するのが望ましい。 [STD 2] 内容： xsd:pattern で正規表現を使用して単純型を定義する際、XML Schema 規格が定める規定に沿っているかどうか細心の注意を払わなければならない。説明：正規表現は難解であり、XML Schema 規格でどのような規定が行われているか確認する必要がある。特に、キャレット（^）やエスケープ（/）の記号の扱いに関して XML Schema 規格に適合しているかどうか細心の注意が必要である。特別の意味を持つ記号を、エスケープした上で文字そのものとして扱いたい場合にも注意が必要である。 [STD 3] 内容： xsd:enumeration は、列挙値の数が膨大である場合は使用しないのが望ましい。説明：要素の値をあらかじめ指定することができるenumeration だが、列挙値の数が膨大な場合、スキーマファイル自体が大きくなりすぎてしまうため、その確認は標準スキーマを使用するアプリケーションなりに任せるのが妥当である。

(37)

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"と記述すべきではない。説明：

(38)

れていないことと同義であり、意味のない記述である。混乱を招くこのような記述は避けるべきである。 [CTD 6] 内容： xsd:all の使用は望ましくない。説明： xsd:all 内で列挙される要素はその出現順に決まりがないため、インスタンスを書くときに混乱を招く恐れがある。また、データのモデル化という観点から曖昧な定義は望ましくない。 6.2 要素宣言要素宣言に関連した規定を以下に列挙する。（要素の内容（型）定義に関しては前項で記述している。） 6.2.1 単純型に関する規定単純型要素宣言に関する規定は特にない。 6.2.2 複合型に関する規定複合型要素宣言に関する規定は特にない。 6.2.3 代替要素に関する規定代替要素の使用に関する規定を以下に列挙する。 [ELD 1] 内容： substitutionGroup による代替要素は使用しないのが望ましい。説明：代替要素の使用すると、その要素が実際どこに出現できるか分かりにくくなる。特に代替要素が置き換わるヘッド型を含む型の派生を行う場合、派生の関係が判別しにくくなる。このため、代替要素の使用は避けるのが望ましい。要素宣言はその出現する場所で直接指定すべきである。 [ELD 2] 内容：要素のabstract 指定は使用しないのが望ましい。

(39)

説明： abstract 指定は他の要素宣言での substitution 指定による代替要素の指定を前提するが、代替要素の使用は、その要素がどこに出現できるかを分かりにくくするため、使用を避けるのが望ましい。要素宣言はその出現する場所で直接指定すべきである。 6.2.4 ルート要素宣言に関連した規定 XML 文書において最上位要素となるルート要素の宣言に関する規定を以下に示す。 [RED 1] 内容：複数の異なる名前空間を持つスキーマファイルから構成されている標準の場合、ルート要素宣言は最上位に位置するスキーマファイルに含めるのが望ましい。説明：インクルード／インポートによるスキーマファイルの階層構造において、インクルード／インポートした先のスキーマファイルにルート要素の宣言が含まれていると、スキーマを読む際、XML 全体の階層構造をたどりにくくなるため、そのようなスキーマの書き方は望ましくない。 6.3 属性宣言属性宣言に関する規定を以下に列挙する。 [ATD 1] 内容：属性はローカルとして定義するべきである。説明：本来、属性は要素に属するものとして考えられるべきであるため、グローバルとして定義するのは望ましくない。 [ATD 2] 内容： xsd:anyAttribute は使用するべきではない。説明：標準スキーマは、利用シナリオを明確に持ち、それにそって具体的なモデル化を行うべきである。その観点から、何がそこに来てもよいようにしておくという指定は望ましくない。また、出現する属性が不定となることは処理系構築の観点からも好ましくない。

(40)

7. その他の制限に関して

7.1 XML Schema 機能ここまでに取り上げられなかった、他の機能に関する規定を以下に示す。 [GXS 17] 内容： xsd:redefine を使用するのは望ましくない。説明：同じ名前空間に属するスキーマ定義を取り込みその一部、或いは全体を変更する場合に使用する機能だが、これを使用しなければスキーマが書けないわけではないうえ、作成者及び利用者の混乱を招く可能性があるため使用を控えるのが望ましい。

(41)

付録 1 ガイドライン規定項目一覧

[ATD] 属性宣言 ATD1 属性はローカルとして定義するべきである。 ATD2 xsd:anyAttribute は使用するべきではない。 [ATN] 属性の命名 ATN1 ローカルな属性を定義する場合、属性を宣言する要素と同じ名前を付けるのは望ましくない。 [CTD] 複合型定義 CTD1 xsd:anyType をベースとした派生は行うべきではない。 CTD2 空の複合型宣言<xsd:complexType/>は含めるべきではない。 CTD3 同じ複合型を持つ要素が複数宣言される場合、共通する型を名前付きで定義し参照するようにするのが望ましい。 CTD4 xsd:any 要素の使用は望ましくない。 CTD5 内容要素として宣言する要素の出現回数として minOccurs="0" maxOccurs="0"と記述すべきではない。 CTD6 xsd:all の使用は望ましくない。 [DOC] 付属説明に関して

DOC1 xsd:annotation 要素の xsd:documentation 要素を使った説明文は簡潔に記述することが望ましい。 DOC2 ルート要素宣言には xsd:annotation、或いはコメントを使用してルート要素であることを明示的に示さなければならない。 DOC3 xsd:appInfo を使用してはならない。 [ELD] 要素宣言 ELD1 substitutionGroup による代替要素は使用しないのが望ましい。 ELD2 要素の abstract 指定は使用しないのが望ましい。 [ETN] 要素の命名 ETN1 要素名が複数の単語から成る場合、UpperCamelCase ルールを採用するのが望ましい。

標準XML Schema作成ガイドライン