XML正規言語記述 RELAX コア

序文

この標準情報(TR)は，日本規格協会 情報技術標準化研究センター(INSTAC)に設立された高速Web環境における標準化に関する調査研究委員会で，1999年度に行われた高速Web言語の調査研究をもとに，工業標準化の促進に関連して特に重要と判断される技術情報をまとめ，標準情報(TR)(タイプII)として公表するものである。

1. 適用範囲

RELAX (REgular LAnguage description for XML)は，XMLベースの言語の構文を記述するための機構を提供する。例えば，XHTML 1.0の構文はRELAX によって記述することができる。

同様の機構であるDTDと比較して，RELAXは次の特徴を備えている。

• a) XML文書として記述できる。
• b) 豊富なデータ型を備えている。
• c) 名前空間を扱うことができる。

RELAXは，RELAX Core及びRELAX Namespaceの二つの部分からなる。RELAX Coreは，単一の名前空間だけを扱う。この標準情報(TR)は，RELAX Coreを規定する。RELAX Namespaceは，RELAX Coreで書かれた記述を組み合わせることによって，複数の名前空間を扱う。別の標準情報(TR)がRELAX Namespaceを規定する。

RELAX Coreプロセサというソフトウェアモジュールは，要素(及びその子孫要素)の並びを与えられて，RELAX Coreによる記述と照合し，結果を出力する。RELAX Coreプロセサは，ユーザが直接起動することができる。別のソフトウェアモジュールであるRELAX Namespaceプロセサから呼び出すこともできる。

RELAX Coreの機能のうち，DTDの機能にデータ型を加えた部分だけを備えたサブセットを用意する。このサブセットは, 実装が特に容易であり，データ型に関する情報以外の欠落なく, DTDとの間で相互に変換することができる。

2. 引用規定

次に示す規定は，この標準情報(TR)の文中での引用によって, この標準情報(TR)の規定の一部となる。

TR X 0008:1999 拡張可能なマーク付け言語(XML) 1.0

備考 W3C (World Wide Web Consortium), Extensible Markup Language (XML) 1.0 (eds. Tim Bray, Jean Paoli, and C. M. Sperberg-McQueen), Recommendation, http://www.w3.org/TR/REC-xml, 1998が[TR X 0008]に一致している。

TR X 0023:1999 XML名前空間

備考 W3C (World Wide Web Consortium), Name Spaces in XML, Recommendation, eds., Tim Bray, Dave Hollander, and Andrew Layman, http://www.w3.org/TR/REC-xml-names, 1999が[TR X 0023]に一致している。

W3C (World Wide Web Consortium), XML Information Set, W3C Working Draft, ed. John Cowan, http://www.w3.org/TR/xml-infoset, 2000

W3C (World Wide Web Consortium), XML Schema Part 2, W3C Working Draft, eds. Paul Biron and Ashok Malhotra, http://www.w3.org/TR/xmlschema-2, 2000

IETF RFC 2396 IETF (Internet Engineering Task Force). RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax, eds. T. Berners-Lee, R. Fielding, and L. Masinter, 1998.

3. 定義

3.1 XML 1.0

この標準情報(TR)では，XML 1.0で定義されている次の用語をそのまま用いる。

• a) 開始タグ(start tag)
• b) 終了タグ(end tag)
• c) 空要素タグ(empty-element tag)
• d) 属性(attribute)
• e) 属性名(attribute name)
• f) 内容(content)
• g) 内容モデル(content model)
• h) 属性リスト宣言(attribute-list declaration)
• i) DTD(DTD)
• j) XMLプロセサ(XML processor)
• k) 妥当性(validity)
• l) 妥当性を検証するプロセサ(validating processor)
• m) 妥当性を検証しないプロセサ(non-validating processor)
• n) 空白文字(whitespace)
• o) 子(child)
• p) パラメタ実体(parameter entity)

次の用語は，XML 1.0で定義された意味のほかに，この標準情報(TR)で規定する意味をもつので注意すること。

• a) マッチ(5.8を参照)

3.2 XML名前空間

この標準情報(TR)では，XML名前空間で定義されている次の用語を用いる。

• a) 名前空間(namespace)
• b) 名前空間名(namespace name)

3.3 XML Schema Part 2

この標準情報(TR)では，XML Schema Part 2で定義されている次の用語を用いる。

• a) 字句表現(lexical representation)
• b) 相(facet)
• c) データ型(datatype)
• d) 組み込み済みデータ型(built-in datatype)

3.4 XML Information Set

この標準情報(TR)では，XML Information Setで定義されている次の用語を用いる

• a) 情報セット(information set)
• b) 文書情報項目(document information item)
• c) 要素情報項目(element information item)
• d) 特性(properties)
• e) コア特性(core properties)
• f) 読み込まれなかった実体情報項目への参照(reference to skipped entity information items)
• g) 実体情報項目(entity information item)
• h) 記法情報項目(notation information item)

3.5 独自の定義

a) タグ名(tag name)

開始タグ，終了タグ及び空要素タグに現れる名前(いわゆるGeneric Identifier)のことを，この標準情報(TR)ではタグ名と言う。

b) 生け垣(hedge)

要素(及びその子孫要素)と文字データの並びを，この標準情報(TR)では生け垣と言う。

4. 記法

この標準情報(TR)は，RELAXモジュールの構文を規定するため，DTD記法の一部を用いる。DTDは名前空間を正しく扱えないので，DTDをそのまま採用せずに一部だけを用いる。

要素がどんな内容をもつかを記述するため，内容モデルを採用する。これは，XML 1.0 の非終端記号contentspecにマッチするものとする。

例えば，要素fooが内容をもたないとき，要素fooの内容を次のとおりに記述する。

	EMPTY

要素がどんな属性をもつかを記述するため，属性リスト宣言の一部を採用する。これは，XML 1.0 の非終端記号AttDefにマッチするものとする。

例えば，要素fooが属性barだけをもち，barは省略可能で，barの値は任意の文字列のとき，要素fooの属性定義を次のとおりに記述する。

	bar CDATA #IMPLIED

5. 基本概念

5.1 設計原則

RELAX Coreの設計原則を次に示す。

• a) 簡潔かつ強力であること。
• b) 設計はすみやかに行なわれること。
• c) 既存のAPI(SAX, DOMなど)の上に容易に実現可能なこと。
• d) DTDと上位互換であること。
• e) データ型に関する以外の情報の欠落なしにDTDに変換可能なサブセットを用意すること。
• f) データ型は，XML Schema Part 2との整合性に配慮すること。
• g) 設計は厳密かつ簡潔であること。

5.2 インスタンス，文法及びメタ文法

5.2.1 インスタンス

XML文書を表す文書情報項目をインスタンスと言う。あるRELAX文法に従っているインスタンスは，そのRELAX文法に照らして合法であると言う。文脈から明らかな場合は，どのRELAX文法に照らして合法なのかを明示せずに, 単に合法であると言う。

備考 XML 1.0で言う妥当性とこの標準情報(TR)で言う合法性とは異なる。妥当でない文書が合法なことも，妥当な文書が合法でないこともある。

5.2.2 RELAX文法

XML文書を表す文書情報項目であって，RELAX Namespaceが規定する制約条件を満たしているものをRELAX文法と言う。

5.2.3 RELAXメタ文法

RELAXの構文をRELAXで可能な範囲で表現したもの(すなわちRELAX文法)をRELAXメタ文法と言う。どんなRELAX文法も，RELAXメタ文法に照らして合法なインスタンスになる。

5.3 モジュール及び文法

XML文書を表す文書情報項目であって，この標準情報(TR)が規定する制約条件を満たしているものをRELAXモジュールと言う。RELAXモジュールは，単一の名前空間に属する要素，並びにその属性及び内容を扱う。

複数の名前空間を扱うRELAX文法は，複数のモジュールを参照し，互いの間の関連付けを行う。このようなRELAX文法は，RELAX Namespaceによって表現する。

単一の名前空間を扱うRELAX文法は，一つのモジュールだけを参照する。このようなRELAX文法は，モジュールを参照する以外の役割をもたず，参照されるモジュールだけで代用できる。

5.4 島及びインスタンス

一般に，一つのインスタンスは複数の名前空間に属しており，複数のモジュールから構成される文法と照合される。この照合は，インスタンスを幾つかの島に分割し，それぞれの島と一つのモジュールとの照合を繰り返すことによって行われる(図1参照)。一つの島は，一つの名前空間に属する生け垣になる。

単一の名前空間からなるインスタンスは，そのまま島と見なすことができる。

照合 モジュール ←─ 　　 島 　│ │ 　│ │ 　↓ ↓ 　　　　　 照合 文法　　　 ←─ インスタンス

図1. モジュール及び文法並びに島及びインスタンスの関係

5.5 RELAX Coreプロセサの働き

島及びRELAXモジュールを与えられて，島がRELAXモジュールに照らして合法であるかどうかを調べるソフトウェアモジュールを, RELAX Coreプロセサと言う。合法であるかどうかを調べる処理を照合と言う。

RELAX Coreプロセサ，XMLプロセサ及びアプリケーションプログラムの関係を図2に示す。

RELAX Coreプロセサは，島及びRELAXモジュールをXMLプロセサから情報セットとして受け取る。情報セットに含まれる情報項目のコア特性だけを， RELAX Coreプロセサは利用する。

参考 現実の実装では，SAX, DOMなどのAPIを通じて情報項目が渡される。

RELAX Coreプロセサは，島のトップレベルの要素の並びを制約する生け垣モデルも受け取ることができる。

照合が終わると，島が合法であるというメッセージ又は合法でないというメッセージを，RELAX Coreプロセサは出力する。これ以外にも，RELAX Coreプロセサは幾つかのメッセージを出力する。

RELAX Coreプロセサはメッセージ以外の何も出力しない。アプリケーションプログラムは，XMLプロセサが出力する情報セット及びRELAX Coreプロセサが出力するメッセージだけを受け取って処理を行う。

RELAX Coreプロセサが利用するXMLプロセサは，妥当性を検証するプロセサであっても，妥当性を検証しないプロセサであっても構わない。

読み込まれなかった実体情報項目をRELAX Coreプロセサが受け取ったときは，ユーザが適切なオプションを指定しているなら, メッセージを出力しなければならない。

島 │ │ XMLプロセサ │ ↓ 利用 アプリケーション モジュール 情報セット ←────────── プログラム │ │ │ │ XMLプロセサ │ │ │ │ トップレベルの要素の列 │ ↓ │ を制約する生け垣モデル │ 情報セット │ (必須ではない) │ │ │ │ │ │ │ │ │ ──────────────────── │ │ │ │RELAX Coreプロセサ │ │ │ ↓ │ 利用 │ 合法か非合法を示す ←───────────── メッセージ

図2. RELAX Coreプロセサ，XMLプロセサ及びアプリケーションプログラムの関係

5.6 データ型

RELAX Coreでは，XML Schema Part 2の組み込み済みデータ型をそのまま用いる。データ型は，属性についての条件としても，生け垣モデルとしても使用できる。

RELAX Coreでいうデータ型は, 文字列の集合とする。文字列がデータ型に属しているかどうかは, 機械的に判定できる。例えば，integerという名前のデータ型は，数字を表す文字列の集合である。ある文字列がintegerを表現しているかどうかは, 機械的に判定できる。

データ型を参照するとき，相という制約条件を加えることができる。例えば，integerを参照するとき，10以上20以下という条件を相として加えることができる。

RELAX Coreプロセサは，文字列からデータへの変換(例えば"1"という文字列から1という整数への変換)は行わない。これはアプリケーションプログラムに任される。

参考 変換プログラムを準備しておき，アプリケーションプログラムはそれを単に呼び出すのが通常である。

5.7 役割及び節

タグ名及び属性についての制約条件を，RELAX Coreでは役割及び節によって表現する。役割は名前であり，節によって記述される。節は名前をもたない。

節は，tag要素又はattPool要素とする。tag要素は, タグ名についての制約条件を含むが，attPool要素は含まない。ある属性についての制約条件を含むtag要素又はattPool要素は, この属性を宣言していると言う。

一つの役割を記述する節が複数存在してはならない。

ある役割を記述する節が他の役割を参照することができる。自分自身への再帰的な参照は許されない。

他の節から参照される節は，attPool要素によって記述されているものとする。tag要素によって 記述されていてはならない。

ある節が，同一の役割を複数回参照してはならない。直接 の参照だけではなく，他の節を経由した間接的な参照も含む。

ある節が，同一の属性を複数回宣言してはならない。直接の 宣言だけではなく，他の節を経由した間接的な宣言も含む。

5.8 生成規則，ラベル及び生け垣モデル

論理構造についての制約を，RELAX Coreではラベル及び生成規則によって表現する。ラベルは名前であり，生成規則によって記述される。生成規則は名前をもたない。

生成規則は，elementRule要素又はhedgeRule要素とする。elementRule要素は, ラベル，役割，生け垣モデルの三つ組みとし，hedgeRule要素は, ラベル及び生け垣モデルの対とする。

elementRule要素が参照する役割は，tag要素で記述されているものと する。attPool要素で記述されている節を参照してはならない。

複数のelementRuleが一つのラベルを共有することができ，複数の hedgeRuleが一つのラベルを共有することができる。しかし， elementRuleとhedgeRuleがラベルを共有することはできない。

複数のelementRuleが一つの役割を共有することができる。

参考 文字列を扱う正規文法では，生成規則の左辺が非終端記号であり，右辺が終端記号，終端記号と非終端記号を並べたもの，非終端記号のいずれかである。RELAX Coreは，論理構造を扱うように拡張された正規文法とみなすことができる。ラベルが左辺の非終端記号に相当し，役割が終端記号に相当する。内容モデルは，文字列ではなく木構造を扱うために右辺の非終端記号を拡張したものに相当する。

要素の内容についての制約条件は, 生け垣モデルによって記述する。生け垣モデルは，要素生け垣モデル，混合生け垣モデル，データ型参照の3種類とする。

複数のelementRuleがラベル及び役割の両方を共有する場合は，すべてが要素 生け垣モデルをもつか，すべてが混合生け垣モデルをもつか，すべてがデータ 型参照であるのいずれかとする。すべてがデータ型参照のときは，同じ名前の データ型を参照しなければならない。

5.8.1 要素生け垣モデル

要素生け垣モデルは，ラベル列の正規集合を生成する。この集合に含まれるラベル列は，この要素内容にマッチする。先頭のラベルの前，最後のラベルの後，ラベルとラベルとの間に空白文字を幾つか挿入したものもマッチする。

5.8.2 混合生け垣モデル

混合生け垣モデルは，要素生け垣モデルに混合であると言う印をつけたものとする。この要素生け垣モデルが生成する正規集合に含まれているラベル列は，この混合生け垣モデルにマッチする。先頭のラベルの前，最後のラベルの後，ラベルとラベルとの間に任意の文字を幾つか挿入したものもマッチする。挿入される文字は, 空白文字とは限らないことに注意。

5.8.3 データ型参照

データ型参照は，データ型の名前を指定する。さらに，相という付加的な条件を指定してもよい。文字の並びがデータ型参照にマッチするのは，参照されたデータ型に属し，相をすべて満たしているときとする。

5.9 名前の分類及び出現位置

RELAX Coreで用いる名前は，データ型名，タグ名，属性名，役割，ラベルの5種類とする。種類が違えば同じ名前を使用してもよい。例えば, integerというデータ型名が存在しても，タグ名又はラベルにintegerを使って構わない。

これらの名前が，インスタンスで出現するかどうか，及びRELAXモジュールではどこに出現するのかを, 次の表に示す。

	インスタンスで	RELAXモジュールで
データ型名	出現しない	属性についての条件として出現する 生け垣モデル(データ型参照)として出現する
タグ名	出現する	節の一部として出現する
属性名	出現する	節の一部として出現する
役割	出現しない	節の一部として出現する(役割の記述) 節の一部として出現する(役割の参照) 生成規則の一部として出現する
ラベル	出現しない	生成規則の一部として出現する(ラベルの記述) 生成規則の一部として出現する(ラベルの参照)

6. モジュールを構成する要素

6.1 module

モジュール全体を表す要素としてmoduleを導入する。module要素は，モジュール全体についての管理情報を表す。

module要素は，moduleVersion属性，relaxCoreVersion属性，targetNamespace属性を もつ。relaxCoreVersion属性は，必須とする。

	moduleVersion CDATA #IMPLIED
	relaxCoreVersion CDATA #REQUIRED
	targetNamespace CDATA #IMPLIED

moduleVersion 属性は，このモジュールの版数を表す。

relaxCoreVersion属性は，RELAX Coreの版数を表す。RELAX Core 1.0 に適合することを示すためには，版数"1.0" を使用しなければならない。あるモジュールが，RELAX Core 1.0に適合しないとき，値"1.0"を使用するのはエラーとする。

参考 RELAX Coreの今後の版に"1.0"以外の値を付与することが，この標準情報(TR)の原案作成委員会の意図であるが，RELAX Coreの将来の版を作成することを確約するわけではなく，作成したとしても版数指定について，特定の方法を使用することを確約するわけでもない。将来の版を作成する可能性があるので，必要な場合に自動的な版の認識を可能とするため，この属性を提供する。

ユーザが適切なオプションを指定したとき，RELAX Coreプロセサは，サポートしていない版数のついたモジュールを受け取ったらメッセージを出力しなければならない。その後，RELAX Coreプロセサは処理を続行してもよく，中止してもよい。

targetNamespace属性は，このモジュールの記述対象である名前空間を示す。省略した場合は，""が指定されたとみなされる。

モジュールを表現する要素はすべて，名前空間名 http://www.xml.gr.jp/xmlns/relaxCoreに属するものとする。したがって, module要素は, この名前空間を宣言しなければならない。

module要素の内容は，次の内容モデルによって規定される。

	(annotation?, interface?,
	  (tag | attPool | elementRule | hedgeRule | div | include )*)

6.2 interface

interface要素は，モジュールとRELAX文法とのインタフェース情報を表現する。単一の名前空間からなるRELAX文法の場合は，interface要素がインスタンスのルートについての情報を与える。

interface要素は, 属性をもたない。

interface要素の内容は，次の内容モデルによって規定される。

	(annotation?, (export | div)*)

6.3 export

export要素は，RELAX文法から参照できる情報を明示する。

export要素は, label属性を必ず指定する。

	label NMTOKEN #REQUIRED

label属性の値は，外部に公開するラベルを示す。単一の名前空間からなるRELAX文法の場合は，インスタンスのルートのラベルを示す。

export要素の内容は，次の内容モデルによって規定される。

	(annotation?)

次に，export要素の例を示す。

	<export label="doc"/>

6.4 tag

tag要素は，タグがある役割をもつ必要十分条件を，タグ名についての条件，属性についての条件，他の役割への参照の組み合わせによって表現する。

tag要素は，role属性及びname属性をもつ。

	role  NMTOKEN      #IMPLIED
	name  NMTOKEN      #IMPLIED

タグ名は, name属性で指定する。role属性は, 役割を参照する。

tag要素がelementRuleの子要素でない場合は，name属性は必須だが， role属性は必須ではない。role属性が省略されたときは，name属性と 同じ値が指定されたものとみなす。

tag要素がelementRuleの子要素である場合は，name属性は必須ではなく， role 属性は禁止する。role属性の値としては，自動的に適当なものをRELAX Core プロセサが生成する（8.5を参照）。name属性が省略されたときは，親要素 であるelementRuleのlabel属性と同じ値が指定されたものとみなす。

tag要素の内容は，次の内容モデルによって規定される。tagの子であるref要素は，role属性をもたなければならない。

	(annotation?, ref*, attribute*)

tag要素は，role属性で参照した役割をタグがもつための必要十分条件を表現する。ある要素eがこの必要十分条件を満たすのは, 次の三つがいずれも成り立つときとする。

• a) eのタグ名が, name属性値とマッチする。
• b) 属性についての条件(これは子要素attributeによって表現される)のそれぞれが, eのいずれかの属性によって満足されている。
• c) 子要素refによって参照されているすべての役割を, eがもつ。

tag要素で言及されていない属性が要素にあっても，条件が満たされることに注意。

tag要素の例を次に示す。ref要素は，役割bar1を参照している。

	<tag name="foo" role="bar">
	  <ref role="bar1"/>
	</tag>

6.5 attPool

attPool要素は，タグがある役割をもつ必要十分条件を，属性についての条件と，他の役割への参照との組み合わせによって表現する。

attPool要素は，role属性をもつ。

	role  NMTOKEN      #REQUIRED

attPool要素の内容は，次の内容モデルによって規定される。attPoolの子であるref要素は，role属性をもたなければならない。

	(annotation?, ref*, attribute*)

attPool要素は，role属性で参照した役割をタグがもつための必要十分条件を表現する。ある要素eがこの必要十分条件を満たすのは, 次の二つがいずれも成り立つときとする。

• a) 子要素refによって参照されているすべての役割をeがもつ。
• b) 属性についての条件(これは子要素attributeによって表現される)のそれぞれが，eのいずれかの属性によって満足されている。

次にattPool要素の例を示す。子要素であるrefは，役割bar1を参照している。

	<attPool role="bar">
	  <ref role="bar1"/>
	</attPool>

6.6 role属性をもつref

role属性をもつref要素は，attPoolで記述されている役割を参照する。

role属性をもつref要素は, 他の属性をもたない。

	role    NMTOKEN      #REQUIRED

role属性をもつref要素の内容は，次の内容モデルによって規定される。

	EMPTY

role属性をもつref要素の例は，tag要素の例及びattPool要素の例に含まれている。

6.7 attribute

attribute要素は，属性の名前及び値についての制約を表現する。属性が省略可能かどうかも表現する。

attribute要素は，name属性，required属性及びtype属性をもつ。name属性は, 必須とする。

	name      NMTOKEN      #REQUIRED
	required   (true)      #IMPLIED
	type      NMTOKEN      #IMPLIED

name属性は，属性の名前を指定する。required属性は，属性が省略可能かどうかを表す。trueが指定されれば, 省略は許されない。

一つのtag要素と，それが直接又は間接に参照するすべてのattPool 要素に含まれる複数のattribute要素は，相互にマッチする名前をname属性 で指定してはならない。

type属性は，データ型名を参照する。type属性が省略されたときは，組込み済みデータ型stringが指定されたものとみなす。

attribute要素の内容は，次の内容モデルによって規定される。この内容モデルでは，相を表現するすべての要素を"|"で繋げたものが, パラメタ実体facetとして定義されていることを仮定している。

	(annotation?, (%facet;)*)

type属性で指定したデータ型名及び子要素で指定した相は, データ型参照を構成する。name属性で指定した属性の値は，このデータ型参照にマッチしなければならない。

次に，attribute要素の例を示す。tag要素の子要素として, attribute 要素が使われている。

	<tag name="a">
	  <attribute name="href" type="uriReference"/>
	</tag>

備考 XML 1.0では，属性をもたない要素型は，属性リスト宣言を必要としない。しかし，RELAX Coreでは，使用されるタグ名は, 常にtag要素を必要とする。

6.8 elementRule

elementRule要素は，ラベル，役割，生け垣モデルの三つ組みからなる生成規則を表現する。

elementRule要素は，role属性，label属性及びtype属性をもつ。子要素tagをもたない場合は，role属性は必須とし，label属性は省略可能とする。省略されたときは，role属性と同じ値が指定されたものとみなす。子要素tagをもつ場合は，label属性は必須とし, role属性は禁止する。

	role        NMTOKEN #IMPLIED
	label       NMTOKEN #IMPLIED
	type        NMTOKEN #IMPLIED

role属性は, 役割を指定する。label属性は, ラベルを指定する。type属性は, データ型を参照する。elementRule要素が，要素生け垣モデル又は混合生け垣モデルをもつ場合に, type属性を指定してはならない。

elementRule要素の内容は，次の内容モデルによって規定される。この内容モデルでは，相を表現するすべての要素を"|"で繋げたものが, パラメタ実体facetとして定義されていることを仮定している。elementRuleの子であるref要素は, label属性をもたなければならない。

	(annotation?,  tag?,
        ((ref | hedgeRef | choice | sequence | element | none | empty | mixed)?
          |
         (%facet;)*))

子要素として出現するtagの扱いは, 8.5で規定する。

ref, hedgeRef, choice, sequence, element, none, emptyのいずれかが指定されているとき，このelementRuleは要素生け垣モデルをもつと言う。

mixedが指定されているとき，このelementRuleは混合生け垣モデルをもつと言う。

要素生け垣モデルでも混合生け垣モデルでもない場合は, データ型への参照をtype属性によって指定しなければならない。データ型への参照を用いるときは, elementRule要素の内容として相を指定する。データ型及び相については, 7.に示す。

6.9 hedgeRule

hedgeRule要素は，ラベル及び生け垣モデルの対からなる生成規則を表現する。

hedgeRule要素は，label属性をもつ。

	label       NMTOKEN #REQUIRED

label属性は, ラベルを指定する。

hedgeRule要素の内容は，次の内容モデルによって規定される。hedgeRuleの子であるref要素は，label属性をもたなければならない。

	(annotation?,  
	  (ref | hedgeRef | choice | sequence | element | none | empty)?)

6.10 label属性をもつref

label属性をもつref要素は，elementRule要素で記述されたラベルを参照する要素生け垣モデルとする。

label属性をもつref要素は, occurs属性をもつ。

	label    NMTOKEN      #REQUIRED
	occurs    CDATA        #IMPLIED

occurs属性の値は, "*", "+", "?"のいずれかとする。

label属性をもつref要素の内容は，次の内容モデルによって規定される。

	EMPTY

label属性によって指定されたラベルを, lとする。このref要素が生成するラベル列は，一つのlだけからなるラベル列とする。ただし，occurs属性が指定されたときは，値が"*"なら0回以上の繰返し，"+"なら1回以上の繰返し，"?"なら0回又は1回の繰返しを適用する。

6.11 hedgeRef

hedgeRef要素は，hedgeRule要素で記述されたラベルを参照する要素生け垣モデルとする。

hedgeRef要素は, label属性及びoccurs属性をもつ。

	label    NMTOKEN      #REQUIRED
	occurs    CDATA        #IMPLIED

occurs属性の値は, "*", "+", "?"のいずれかとする。

hedgeRef要素の内容は，次の内容モデルによって規定される。

	EMPTY

hedgeRef要素は，それが参照するラベルを記述するhedgeRule の生け垣モデルで置き換えられる（詳細は8.4を参照）。

6.12 sequence

sequence要素は，幾つかの要素生け垣モデルの連結を表す要素生け垣モデルとする。

sequence要素は, occurs属性をもつ。occurs属性の値及び意味は，label属性をもつref要素のときと同様とする。

	occurs    CDATA        #IMPLIED

sequence要素の内容は，次の内容モデルによって規定される。

	(ref | hedgeRef | choice | sequence | element | none | empty)*

sequence要素の子要素を, c₁, c₂, ..., c_mとする。c₁がラベル列l₁₁, l₁₂, ..., l_1n1を生成し，c₂がラベル列l₂₁, l₂₂, ...., l_2n2を生成し，c₃以降も同様のラベル列を生成し，c_mがラベル列l_m1, l_m2, ...., l_mnmを生成するものとする。このとき，sequence要素は, l₁₁, l₁₂, ..., l_1n1, l₂₁, l₂₂, ...., l_2n2, ..., l_m1, l_m2, ...., l_mnmを生成する。ただし，occurs属性が指定されたときは，値が"*"なら0回以上の繰返し，"+"なら1回以上の繰返し，"?"なら0回又は1回の繰返しを適用する。

6.13 choice

choice要素は，幾つかの要素生け垣モデルからの選択を表す要素生け垣モデルとする。

choice要素は, occurs属性をもつ。occurs属性の値及び意味は, label属性をもつref要素のときと同様とする。

	occurs    CDATA        #IMPLIED

choice要素の内容は，次の内容モデルによって規定される。

	(ref | hedgeRef | choice | sequence | element | none | empty)*

choice要素の子要素を, c₁, c₂, ..., c_mとする。c₁がラベル列l₁₁, l₁₂, ..., l_1n1を生成し，c₂がラベル列l₂₁, l₂₂, ...., l_2n2を生成し，c₃以降も同様のラベル列を生成し，c_mがラベル列l_m1, l_m2, ...., l_mnmを生成するものとする。このとき，choice要素は， ラベル列l₁₁, l₁₂, ..., l_1n1, ラベル列l₂₁, l₂₂, ...., l_2n2，...， ラベル列l_m1, l_m2, ...., l_mnmのいずれも生成する。ただし，occurs属性が指定されたときは，値が"*"なら0回以上の繰返し，"+"なら1回以上の繰返し，"?"なら0回又は1回の繰返しを適用する。

6.14 empty

empty要素は，空のラベル列を生成する要素生け垣モデルとする。

empty要素は, 属性をもたない。

empty要素の内容は，次の内容モデルによって規定される。

	EMPTY

6.15 none

none要素は，ラベル列を一つも生成しない要素生け垣モデルとする。

none要素は, 属性をもたない。

none要素の内容は，次の内容モデルによって規定される。

	EMPTY

6.16 mixed

mixed要素は，混合生け垣モデルとする。

mixed要素は, 属性をもたない。

mixed要素の内容は，次の内容モデルによって規定される。

	(ref | hedgeRef | choice | sequence | element | none | empty)

mixed要素の子である要素生け垣モデルが，あるラベル列を生成するものとする。このラベル列は，この混合生け垣モデルにマッチする。先頭のラベルの前，最後のラベルの後，ラベルとラベルとの間に任意の文字を幾つか挿入したものも，この混合生け垣モデルにマッチする。

6.17 element

ref, tag, elementRule要素に展開される構文糖衣として，element要素を導入する。

element要素は，name属性，type属性，occurs属性をもつ。name属性及び type属性は必須とする。occurs属性の値及び意味は，label属性をもつ ref要素のときと同様とする。

	name     NMTOKEN #REQUIRED
	type     NMTOKEN #REQUIRED
	occurs   CDATA   #IMPLIED

element要素の内容は，次の内容モデルによって規定される。この内容モデルでは，相を表現するすべての要素を"|"で繋げたものがパラメタ実体facetとして定義されていることを仮定している。

	(annotation?, (%facet;)*)

element要素は，次の規則に従ってref, tag, elementRule要素に展開される。

a) ref要素の生成

ref要素が自動生成され，element要素を置き換える。ref要素のlabel属性の値として，他のラベルと衝突しないラベルを自動的に生成する。もし，element要素にoccurs属性があれば，このref要素がそれを引き継ぐ。

b) elementRule要素の生成

elementRule要素が自動生成され，このモジュールに追加される。elementRule要素のrole属性の値として，他の役割と衝突しない役割が自動生成される。label属性の値は，a)で自動生成したラベルとする。

このelementRuleの生け垣モデルは，データ型参照とする。参照するデータ 型は，element要素のtype属性で指定されたものとする。elementRuleの内容と しては，element要素の内容をそのまま用いる。

c) tag要素の生成

tag要素が自動生成され，このモジュールに追加される。tag要素のrole属性の値は，elementRuleを生成するときに自動生成した役割とする。name属性の値は，元のelement要素のname属性の値とする。

6.18 include

他のモジュールを参照するための機構として，include要素を導入する。

include要素は，moduleLocation属性を必ずもつ。

	moduleLocation CDATA #REQUIRED

moduleLocation属性は，他のモジュールをURI reference[IETF RFC 2396]によって参照する。URI referenceは, fragment identifierを含んではならない。

include要素の内容は，次の内容モデルによって規定される。

	(annotation?)

include要素をもつモジュールを参照元モジュールといい，moduleLocation属性が参照するモジュールを参照先モジュールと言う。参照先モジュール及び参照元モジュールのtargetNamespace属性値は, 一致しなければならない。

6.19 div

module要素内に記述される節, 生成規則又はincludeのグループ化, interface要素内に記述されるexport要素のグループ化のための機構として, div要素を導入する。

div要素は, 属性をもたない。

div要素の内容は，次の内容モデルによって規定される。div要素が子要素としてexportをもつのは，interfaceが祖先要素であるときに限る。div要素が, 子要素として節, 生成規則又はincludeをもつのは，interfaceが祖先要素でないときに限る。

	(annotation?,
               div*,
               (((elementRule | hedgeRule | tag | attPool | include),
                   (elementRule | hedgeRule | tag | attPool | include | div)*)
                |
                (export, (export | div)*))?)

6.20 annotation

モジュール内に注釈を埋め込むための機構として，annotation要素を導入する。

annotation要素は，属性をもたない。

annotation要素の内容は，次の内容モデルによって規定される。

	(appinfo | documentation)*

6.21 documentation

人が読むための注釈として，documentation要素を導入する。

documentation要素は，source属性をもつ。

	source     CDATA      #IMPLIED

source属性が指定されたときは，その値は, URI reference[IETF RFC 2396]でなければならない。

documentation要素の内容は，次の内容モデルによって規定される。

	(#PCDATA)

source属性をもつdocumentation要素は，空要素でなければならない。空要素でないdocumentation要素は，source属性をもってはならない。

6.22 appinfo

スキーマを処理するプログラムのための情報を埋め込む機構として, appinfo要素を導入する。

appinfo要素は，source属性をもつ。

	source     CDATA      #IMPLIED

source属性が指定されたときは，その値は, URI reference[IETF RFC 2396]でなければならない。

appinfo要素の内容は，次の内容モデルによって規定される。

	(#PCDATA)

source属性をもつappinfo要素は，空要素でなければならない。空要素でないappinfo要素は，source属性をもってはならない。

7. データ型

この標準情報(TR)におけるデータ型は，XML Schema Part 2の組込み済みデータ型，及びRELAX Core独自のデータ型とする。

備考 ユーザがデータ型を定義することは, 許していない。

7.1 XML Schema Part 2にあるデータ型の組込み済みデータ型

7.1.1 string

XML Schema Part 2のデータ型stringの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型stringのときと同じとする。

7.1.2 boolean

XML Schema Part 2のデータ型booleanの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型booleanのときと同じとする。

7.1.3 float

XML Schema Part 2のデータ型floatの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型floatのときと同じとする。

7.1.4 double

XML Schema Part 2のデータ型doubleの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型doubleのときと同じとする。

7.1.5 decimal

XML Schema Part 2のデータ型decimalの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型decimalのときと同じとする。

7.1.6 timeDuration

XML Schema Part 2のデータ型timeDurationの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型timeDurationのときと同じとする。

7.1.7 recurringDuration

XML Schema Part 2のデータ型recurringDurationの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型recurringDurationのときと同じとする。

7.1.8 binary

XML Schema Part 2のデータ型binaryの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型binaryのときと同じとする。

7.1.9 uriReference

XML Schema Part 2のデータ型uriReferenceの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型uriReferenceのときと同じとする。

7.1.10 ID

XML Schema Part 2のデータ型IDの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型IDのときと同じとする。

ID属性は，attribute要素のtype属性だけから参照でき，elementRule要素のtype属性から参照することはできない。

ある属性をID型であると直接又は（attPool要素を通じて）間 接に宣言するtag要素は，別のtag要素とタグ名を共有してはならない。

一つのXML文書情報項目に含まれる複数の要素情報項目が, 同一の名前をID型の値として指定してはならない。つまり，IDの値は，要素情報項目を一意に特定しなければならない。

一つのtag要素及びそれが参照するすべての節は，複数の属性をデータ型IDであると宣言してはならない。

7.1.11 IDREF

XML Schema Part 2のデータ型IDREFの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型IDREFのときと同じとする。

IDREF属性は，attribute要素のtype属性だけから参照でき，elementRule要素のtype属性から参照することはできない。

ある属性をIDREF型であると直接又は（attPool要素を通じて）間 接に宣言するtag要素は，別のtag要素とタグ名を共有してはならない。

データ型がIDREFに属する文字列は，ある要素情報項目のID属性の値とマッチしなければならない。IDREFの値は，あるID属性の値とマッチしなければならない。

7.1.12 ENTITY

XML Schema Part 2のデータ型ENTITYの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型ENTITYのときと同じとする。

ENTITY属性は，attribute要素のtype属性だけから参照でき，elementRule要素のtype属性から参照することはできない。

データ型ENTITYに属する文字列は，解析対象外実体情報項目の名前とマッチしなければならない。

7.1.13 NOTATION

XML Schema Part 2のデータ型NOTATIONの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型NOTATIONのときと同じとする。

NOTATION属性は，attribute要素のtype属性だけから参照でき，elementRule要素のtype属性から参照することはできない。

データ型NOTATIONに属する文字列は，記法情報項目の名前とマッチしなければならない。

7.1.14 QName

XML Schema Part 2のデータ型QNameの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型QNameのときと同じとする。

7.1.15 language

XML Schema Part 2のデータ型languageの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型languageのときと同じとする。

7.1.16 IDREFS

XML Schema Part 2のデータ型IDREFSの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型IDREFSのときと同じとする。

IDREFS属性は，attribute要素のtype属性だけから参照でき，elementRule要素のtype属性から参照することはできない。

ある属性をIDREFS型であると直接又は（attPool要素を通じて）間 接に宣言するtag要素は，別のtag要素とタグ名を共有してはならない。

データ型IDREFSに属する文字列は，データ型がIDである属性によって指定された名前によって構成されなければならない。

7.1.17 ENTITIES

XML Schema Part 2のデータ型ENTITIESの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型ENTITIESのときと同じとする。

ENTITIES属性は，attribute要素のtype属性だけから参照でき，elementRule要素のtype属性から参照することはできない。

データ型ENTITIESに属する文字列は，解析対象外実体情報項目の名前によって構成されなければならない。

7.1.18 NMTOKEN

XML Schema Part 2のデータ型NMTOKENの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型NMTOKENのときと同じとする。

NMTOKEN属性は，attribute要素のtype属性だけから参照でき，elementRule要素のtype属性から参照することはできない。

7.1.19 NMTOKENS

XML Schema Part 2のデータ型NMTOKENSの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型NMTOKENSのときと同じとする。

NMTOKENS属性は，attribute要素のtype属性だけから参照でき，elementRule要素の type属性から参照することはできない。

7.1.20 Name

XML Schema Part 2のデータ型Nameの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型Nameのときと同じとする。

7.1.21 NCName

XML Schema Part 2のデータ型NCNameの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型NCNameのときと同じとする。

7.1.22 integer

XML Schema Part 2のデータ型integerの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型integerのときと同じとする。

7.1.23 nonPositiveInteger

XML Schema Part 2のデータ型nonPositiveIntegerの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型nonPositiveIntegerのときと同じとする。

7.1.24 negativeInteger

XML Schema Part 2のデータ型negativeIntegerの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型negativeIntegerのときと同じとする。

7.1.25 long

XML Schema Part 2のデータ型longの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型longのときと同じとする。

7.1.26 int

XML Schema Part 2のデータ型intの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型intのときと同じとする。

7.1.27 short

XML Schema Part 2のデータ型shortの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型shortのときと同じとする。

7.1.28 byte

XML Schema Part 2のデータ型byteの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型byteのときと同じとする。

7.1.29 nonNegativeInteger

XML Schema Part 2のデータ型nonNegativeIntegerの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型nonNegativeIntegerのときと同じとする。

7.1.30 unsignedLong

XML Schema Part 2のデータ型unsignedLongの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型unsignedLongのときと同じとする。

7.1.31 unsignedInt

XML Schema Part 2のデータ型unsignedIntの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型unsignedIntのときと同じとする。

7.1.32 unsignedShort

XML Schema Part 2のデータ型unsignedShortの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型unsignedShortのときと同じとする。

7.1.33 unsignedByte

XML Schema Part 2のデータ型unsignedByteの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型unsignedByteのときと同じとする。

7.1.34 positiveInteger

XML Schema Part 2のデータ型positiveIntegerの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型positiveIntegerのときと同じとする。

7.1.35 timeInstant

XML Schema Part 2のデータ型timeInstantの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型timeInstantのときと同じとする。

7.1.36 time

XML Schema Part 2のデータ型timeの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型timeのときと同じとする。

7.1.37 timePeriod

XML Schema Part 2のデータ型timePeriodの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型timePeriodのときと同じとする。

7.1.38 date

XML Schema Part 2のデータ型dateの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型dateのときと同じとする。

7.1.39 month

XML Schema Part 2のデータ型monthの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型monthのときと同じとする。

7.1.40 year

XML Schema Part 2のデータ型yearの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型yearのときと同じとする。

7.1.41 century

XML Schema Part 2のデータ型centuryの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型centuryのときと同じとする。

7.1.42 recurringDate

XML Schema Part 2のデータ型recurringDateの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型recurringDateのときと同じとする。

7.1.43 recurringDay

XML Schema Part 2のデータ型recurringDayの字句表現の集合を表現する。適用可能な相は，XML Schema Part 2のデータ型recurringDayのときと同じとする。

7.2 RELAX Core独自のデータ型

7.2.1 none

データ型noneは，空集合を表現する。どんな文字列もこのデータ型には属さない。適用可能な相はない。

7.2.2 emptyString

データ型emptyは，空の文字列だけからなる集合を表現する。適用可能な相はない。

7.3 相

この標準情報(TR)における相は，XML Schema Part 2の相とまったく同一とする。

7.3.1 length

XML Schema Part 2のlengthと同一とする。

7.3.2 minlength

XML Schema Part 2のminlengthと同一とする。

7.3.3 maxlength

XML Schema Part 2のmaxlengthと同一とする。

7.3.4 pattern

XML Schema Part 2のpatternと同一とする。

7.3.5 enumeration

XML Schema Part 2のenumerationと同一とする。

7.3.6 maxInclusive

XML Schema Part 2のmaxInclusiveと同一とする。

7.3.7 maxExclusive

XML Schema Part 2のmaxExclusiveと同一とする。

7.3.8 minInclusive

XML Schema Part 2のminInclusiveと同一とする。

7.3.9 minExclusive

XML Schema Part 2のminExclusiveと同一とする。

7.3.10 precision

XML Schema Part 2のprecisionと同一とする。

7.3.11 scale

XML Schema Part 2のscaleと同一とする。

7.3.12 encoding

XML Schema Part 2のencodingと同一とする。

7.3.13 duration

XML Schema Part 2のdurationと同一とする。

7.3.14 period

XML Schema Part 2のperiodと同一とする。

8. 合法性

RELAXモジュール及び要素生け垣モデルの二つに照らして，あるインスタンス断片が合法であるかどうかの判定基準を示す。

備考 ここに示す判定基準は，実装を規定するものではない。

8.1 要素生け垣モデルの決定

島のトップレベルの要素の並びを制約する要素生け垣モデルが与えられていない場合は，export要素にあるlabel属性から要素生け垣モデルを構成する。

このモジュールに存在するすべてのexport要素のlabel属性に含まれるラベルすべてを考える。これらを参照するref要素をchoice要素で括ったものを，要素生け垣モデルとして用いる。ref要素及びchoice要素には, occurs属性を付与しない。

8.2 moduleの展開

include要素によって参照している他のmodule要素をすべて展開する。参照先のmoduleがinclude要素によってさらに他のmoduleを参照しているときは，参照先にあるinclude要素をまず展開してから，展開を行う。

8.3 elementの展開

要素生け垣モデルに出現するelement要素を, ref, elementRule及びtagに展開する。

8.4 hedgeRefの展開

hedgeRef要素は，それが参照するラベルを記述するhedgeRuleの生け垣モデル で置き換える。置換えの詳細を次に示す。

• a) このhedgeRef要素が参照するラベルを記述するhedgeRuleをすべて探す。
• b) これらのhedgeRuleの生け垣モデルをchoice要素で一つに括る。
• c) hedgeRefのoccurs属性を，このchoice要素に転記する。
• d) このchoice要素で，hedgeRef要素を置き換える。

choice要素に別のhedgeRef要素が現れる場合は，再帰的に置換えを 繰り返す。

8.5 elementRuleに埋め込まれたtagの展開

あるelementRuleに埋め込まれているtagは，このelementRuleの兄弟要素となるように移動する。他と衝突しない役割を一つ生成し，このtagのrole属性として指定し，このelementRuleのrole属性として指定する。このtagがname属性をもたないとき，elementRuleのlabel属性の値をname属性として指定する。

8.6 解釈

生け垣の中のそれぞれの要素に対して, 一つの役割及び一つのラベルを関連付けることを考える。この関連付けをこの生け垣の解釈と言う。

生け垣が合法であるとは，その合法的な解釈が少なくとも一つ存在することと定義する。ここで，ある生け垣の合法的な解釈とは，次の条件を満たす解釈とする。

• a) 各要素は，それに関連付けられた役割をもつ。
• b) 各要素における導出が正しい。
• c) トップレベルの要素に振られたラベルの列が，与えられた要素生け垣モデルとマッチする。

各要素における導出が正しいということを定義する。ある要素をeとし，その子要素をe₁, e₂, ...., e_nとする。eの内容であって，e₁の前に存在する文字の並びをt₀とする。eの内容であって，e_iの後ろ，e_(i+1)の前に存在する文字の並びをt_iとする。eの内容であって，e_nの後ろにある文字の並びをt_nとする。したがって，t₀, e₁, t₁, e₂, t₂, ..., t_(n-1), e_n, t_nが, 要素eの内容になる。

要素eに関連付けられたラベルをlとし，要素e₁, e₂, ..., e_nに関連付けられたラベルをl₁, l₂, ..., l_nとする。lをlabel属性で指定し，eに関連付けられた役割をrole属性で指定し，その生け垣モデルにt₀, l₁, t₁, l₂, t₂, ..., t_(n-1), l_n, t_nがマッチするelementRuleが存在すれば，要素eにおける導出は正しい。

要素eの属性が，eに関連づけられた役割を記述するtag要素によって直接に も（attPool要素を通じて）間接にも宣言されていないとき，ユーザが適切な オプションを指定しているなら，RELAX Coreプロセサはメッセージを出力しな ければならない。

ラベルl₁及びl₂に対して次の条件が成り立つとき，l₁及びl₂は文脈によって区別できないという。

• a) ラベルl₁を参照する生け垣モデルをもつelementRule e₁が存在する。
• b) ラベルl₂を参照する生け垣モデルをもつelementRule e₂が存在する。
• c) e₁及びe₂は同一のelementRuleであるか，role属性で同一の役割を指定し，label属性で同一のラベルを指定している。

備考1: どのラベルlも自分自身とは文脈によって区別できない。

役割r₁及びr₂の両方を満たす開始タグが構築可能な ら，r₁及びr₂は両立可能であるという。

備考2: どの役割も自分自身と両立可能である。

role属性で役割rを指定し，label属性でラベルlを指定するelementRuleが 存在するとき，rはlを導くと言う。

すべてのRELAX Coreプロセサが処理可能なのは，次の一意性条件を満たす RELAXモジュールに限る。

• a) ラベルq₁及びq₂が文脈によって区別できず， 役割r₁及びr₂が両立可能で，r₁がq₁ を導き，r₂がq₂を導くなら，q₁及びq₂ は同一かつr₁及びr₂は同一でなければならない。

一意性条件を満たさないRELAXモジュールを受け取ったとき，RELAX Coreプロ セサはメッセージを出して処理を終了してもよい。一意性条件が満たさ れていないときは警告を出すことが望ましい。

9. 適合性

RELAX Coreは，モジュールに関する適合性水準及びRELAX Coreプロセサに関する適合性水準を定める。

9.1 モジュールに関する適合性水準

モジュールに関する適合性水準は，classic及びfully relaxedの二つとする。

適合性水準classicでは次の制限がある。

• a) elementRuleは, label属性をもってはならない。
• b) 複数のelementRuleが, 同一の役割を指定してはならない。
• c) 複数のhedgeRuleが, 同一のラベルを指定してはならない。
• d) tagは, role属性をもってはならない。
• e) 複数のtagが, 同一のタグ名を指定してはならない。
• f) element要素を使用してはならない。
• g) elementRule要素の子要素として, tagを使用してはならない。
• h) mixed要素の子要素は，label属性をもつref，hedgeRef, choiceのいずれかと する。子要素は，occurs属性の値として"*"を指定しなければならない。子要素 hedgeRefには項目j)の制限が適用される。
• i) 前項のchoiceの子要素は，label属性をもつref，hedgeRef のいず れかとする。choice要素の子要素はoccurs属性を指定してはならない。子要素 hedgeRefには項目j)の制限が適用される。
• j) 前項及び前々項でいうhedgeRefが参照するhedgeRuleは，生け垣 モデルとして，label属性をもつref，hedgeRef, choiceのいずれかをもつ。 これらはoccurs属性を指定してはならない。子要素hedgeRefには本項の制限 が再帰的に適用される。
• k) 使用してよいデータ型は，次のものに限る。string, boolean, float, double, long, int, short, byte, ID, IDREF, ENTITY, NOTATION, IDREFS, ENTITIES, NMTOKEN, NMTOKENS
• l) 使用してよい相は，次のものに限る。enumeration, maxInclusive, maxExclusive, minInclusive, minExclusive

適合性水準fully relaxedでは, 一切の制限はない。

9.2 RELAX Coreプロセサに関する適合性水準

RELAX Coreプロセサに関する適合性水準は，classic及びfully relaxedの二つとする。

適合性水準classicでは，適合性水準classicに適合するモジュールだけを正しく処理すればよい。適合性水準classicを越えるモジュールは, 処理を中止してもよい。ユーザが適切なオプションを指定した場合は，処理を中止する前にメッセージを出力しなければならない。

適合性水準fully relaxedでは，いっさいの制限はなく，あらゆるモジュールを正しく処理しなければならない。

RELAXモジュールに文法エラーがある場合(XML文書を表す文書情報項目でない，又はこの標準情報(TR)が規定する制約条件を満たしていない)には，正常な照合は行わない。ユーザが適切なオプションを指定したとき，RELAX Coreプロセサは, 文法エラーを報告しなければならない。