3. 適合性定義 (Conformance Definition)

本節は規範的。

XHTML ファミリーの文書が、 XHTML ファミリーのユーザーエージェントで最大限にポータブルであることを確実にするために、この仕様書は、これら及び XHTML ファミリーの文書型のための適合性要求を厳しく定義する。 適合性定義は、本節で見つけることができるので、これらは、本文書、 XHTML に基礎的な仕様書 [XHTML1] 及び、他の関連する仕様書中の、規範的なテキストを参照する必要がある。 規範的な参考文献を全て読むことで、 XHTML に対する適合性要求を充分に理解することが、唯一のできることである。

本文書中の、「しなければならない (MUST) 」、「してはならない (MUST NOT) 」、「要求される、必須 (REQUIRED) 」、「望ましい (SHALL) 」、「望ましくない (SHALL NOT) 」、「すべきである (SHOULD) 」、「推薦される (RECOMMENDED) 」、「しても良い (MAY) 」、および「任意 (OPTIONAL) 」と言ったキーワードは、 [RFC2119] で述べられているように解釈されることになっている。

（訳注：本邦訳では、上記の使い分けは曖昧である。正しくは、原典を参照。）

3.1. XHTML ホスト言語文書型適合性 (XHTML Host Language Document Type Conformance)

既存の文書型を修正し、この仕様で定義されたモジュールと、他のモジュールを利用して、完全に新しい文書型を定義することが可能だ。 その文書型は、以下の条件を満たすとき、「XHTML ホスト言語適合 (XHTML Host Language Conforming)」である：

1. この文書型は、 W3C によって定義された実装方法の一つを使って定義されなければならない。 現在、これは、 XML 文書型に限られているが、ほどなく XML スキーム (XML Schema) も利用できるようになるだろう。 他の実装も可能ではあるが、本節の残りの部分は、「DTDs」に言及する。
2. この文書型を定義する DTD は、公開テキスト記述の最初のトークンに、「XHTML」と言う文字列を用いて、 命名規則 (Naming Rules) で定義されているような、一意的な識別子を持たなければならない。
3. この文書型を定義する DTD は、最低でも、本仕様書で定義されている、構造モジュール、ハイパーテキスト・モジュール、テキスト・モジュール、リスト・モジュールを含まなければならない。
4. というのは、ここに含まれている W3C 定義済みのモジュール、すなわち全ての要素、属性、属性タイプ（全ての必須の網羅的リストを含む）、そして全ての必須最小内容モデルの各々は、この文書型の内容モデルに含まれなければならない（また、拡張されるかもしれない）からである。 内容モデルが拡張されるときは、元となる内容モデルで必須となる、全ての要素と属性（その型や全ての必須の網羅的リストと共に）は、引き続き必須とされる。
5. この文書型を定義する DTD は、追加要素や属性を定義しても良い。 しかし、これらは、自身の XML 名前空間 [XMLNAMES] 内でなければならない。

3.2. XHTML 統合セット文書型適合性 (XHTML Integration Set Document Type Conformance)

XHTML に基づく文書型を定義し、その構造に固執しない文書型を定義することも可能である。このような文書型は、以下の条件を満たすとき、「XHTML 統合セット適合 (XHTML Integration Set Document Type Conformance) 」である：

1. この文書型は、 W3C によって定義された実装方法の一つを使って定義されなければならない。 現在、これは、 XML DTD に限られているが、ほどなく XML スキーム (XML Schema) が利用できるようになるだろう。 他の実装も可能ではあるが、本節の残りの部分では、「DTDs」に付いて言及する。
2. この文書型を定義する DTD は、公開テキスト記述の最初のトークン以外に、「XHTML」と言う文字列を用いて、命名規則 (Naming Rules) で定義されているような、一意的な識別子を持たなければならない。
3. この文書型を定義する DTD は、最低でも、本仕様書で定義されている、ハイパーテキスト・モジュール、テキスト・モジュール、リスト・モジュールを含まなければならない。
4. というのは、ここに含まれる W3C 定義済みのモジュール、すなわち全ての要素、属性、属性タイプ（全ての必須の網羅的リストを含む）、そして全ての必須最小内容モデルの各々は、この文書型の内容モデルに含まれなければならない（また、拡張されるかもしれない）からである。 内容モデルが拡張されるときは、元の内容モデルで必須となる、全ての要素および属性（それらの型や必須の網羅的リストと共に）は、引き続き必須とされる。
5. この文書型を定義する DTD は、追加の要素および属性を定義するかもしれない。しかし、これらは、自身の XML 名前空間 [XMLNAMES] 内でなければならない。

3.3. XHTML ファミリー・モジュール適合性(XHTML Family Module Conformance)

この仕様書は、 XHTML に適合するモジュールを定義する方法を定義する。モジュールが以下の全ての条件を満たすとき、そのモジュールは、本仕様書に適合性する：

1. この文書型は、 W3C によって定義された実装方法の一つを使って定義されなければならない。 現在、これは、 XML DTD に限られているが、ほどなく XML スキーム (XML Schema) が利用可能となるだろう。 他の実装も可能ではあるが、本節の残りの部分では、「DTDs」に付いて言及する。
2. このモジュールを定義する DTD は、命名規則 (Naming Rules) で定義されているような、一意的な識別子を持っていなければならない。
3. このモジュールが XML DTD を用いて定義されるときは、このモジュールは、一意的なの接頭辞、あるいはその他の、よく似た方法を利用して、そのパラメタ実体名を隔離しなくてはならない。
4. このモジュール定義は、それが宣言する要素、属性、且つ/又は、内容モデルの構文的、意味的な要求に関する、散文的な定義を持たなければならない。
5. このモジュール定義は、他の W3C 定義済みのモジュールで定義されている、いかなる要素名も、再利用してはならない。但し、内容モデルと、これらの要素の意味が、元のものと、それを拡張したものとで、一意的である場合や、再利用された要素名が、自身の名前空間内である場合（以下参照）を除く。
6. このモジュール定義の要素および属性は、 XML 名前空間 [XMLNAMES] の一部分でなければならない。 もし、このモジュールが W3C 以外の組織によって定義されているならば、この名前空間は、他の W3C モジュールが定義している名前空間と同じではならない。

3.4. XHTML ファミリー文書適合性 (XHTML Family Document Conformance)

適合性している XHTML ファミリー文書は、文書型を適合性させる XHTML ホスト言葉の妥当な実例 (valid instance) である。

3.5. XHTML ファミリー・ユーザー・エージェント適合性 (XHTML Family User Agent Conformance)

適合性しているユーザー・エージェントは、以下の全ての条件を（[XHTML1] で定義されているように）満たさなければならない：

1. XML 1.0 勧告と一貫するように、このユーザー・エージェントは、 XHTML 文書を、ウェル・フォームド (well-formed) であるように、構文解析し、評価しなければならない。（訳注："well-formed" とは、全ての要素に開始・終了があり、文書は一つの最大親要素（ルート要素）に対して、全ての子孫要素が樹形状に入れ子関係になっていることである。「整形式」と訳される場合もある。 XML 1.0 勧告を参照されたい。）もし、このユーザー・エージェントが、妥当なユーザー・エージェントであると主張するなら、 [XML] に従い、文書の、それが参照する DTD に対する、妥当性検証もしなければならない。
2. このユーザー・エージェントが、本仕様書で定義された装備や、規範的参考文献を通して本仕様書に要求された装備をサポートすると主張する場合は、その装備の定義と一貫するようなやり方で、サポートしなければならない。
3. ユーザー・エージェントが、 XHTML 文書を [XML] の一般例として処理する場合は、 ID タイプの属性（例えば、殆どの XHTML 要素の id 属性）だけを、断片識別子 (fragment identifier) として認識するだろう。
4. ユーザー・エージェントが認識できない属性に遭遇した場合は、引き続きその子要素を処理しなければならない。もしその内容がテキストであれば、そのテキストはユーザーに提供されなければならない。
5. ユーザー・エージェントが認識できない属性に遭遇した場合は、その属性の仕様全体（例えば、属性とその値）を無視しなければならない。
6. ユーザー・エージェントが認識できない属性値に遭遇した場合は、その属性の初期値を使わなければならない。
7. もしユーザー・エージェントが何の宣言も処理できない（その宣言がユーザー・エージェントが取得できない外部サブセット中にある場合起こり得る）、実体参照（定義済み実体以外）に遭遇した場合は、その実体参照は、その実体参照を構成する何文字か（アンド記号で始まり、セミコロンで終了する）として描画されるべきである。
8. 内容を描画するとき、認識は出来ても描画できない文字や文字実体参照に遭遇したユーザー・エージェントは、通常の描画が為されなかったことを、ユーザーに明示する文書を表示すべきである。

9. 空白は、以下の規則に則って扱われる。以下の文字は、 [XML] で空白類文字として定義されている：

   • スペース (SPACE) ( )
   • 水平タブ文字 (HORIZONTAL TABULATION) (	)
   • キャリッジ・リターン (CARRIAGE RETURN) (
)
   • ライン・フィード (LINE FEED) (
)

   XML 処理装置は、異なるシステムの改行コードを、一つの LINE FEED 文字に規格化し、これはアプリケーションまで渡される。

   ユーザー・エージェントは、 XML 処理装置から受け渡されたデータの空白類文字を、以下のように処理しなければならない：

   • ブロック要素に隣接する全ての空白類文字は取り除かれるべきである。
   • コメントは全て取り除かれ、空白処理に影響しない。コメント前後にある一つの空白類文字は二つの空白類文字として取り扱われる。
   • 'xml:space' 属性が 'preserve' に設定されているとき、空白類文字は保持されなければならず、特にブロック中の LINE FEED 文字は、変換されてはならない。
   • 'xml:space' 属性が 'preserve に設定されていないときは、次のようにしなければならない：
     • ブロック要素中で、先行、もしくは後続する空白は取り除かれなければならない。
     • LINE FEED 文字は以下の文字の一つに変換されなければならない： SPACE 文字、ゼロ幅 SPACE 文字 (​)、なし（すなわち除去）。 結果の文字の選択は、ユーザー・エージェント依存であり、 LINE FEED 文字に先行、後続する文字のスクリプト・プロパティに条件付けられる。
     • LINE FEED 文字を除いた空白類文字の連続は、単一の SPACE 文字に縮められなければならない。
     • 一つ以上の LINE FEED 文字を含んだ空白類文字の連続は、一つの LINE FEED 文字と同様に縮められなければならない。

   属性値中の空白類文字は、 [XML] に従って処理される。

   注意（参考的）： LINE FEED 文字の変換方法の特定において、ユーザー・エージェントは、以下の場合について考慮すべきであり、これによって、 LINE FEED の前後にある文字のスクリプトが置換の選択を特定する。 普遍的なスクリプトの文字（句読点のような）は、他方にあるスクリプトと同じように扱われる：

   1. LINE FEED 文字に先行、後続する文字が、その中で単語区切りとして SPACE 文字が使われているスクリプトに属していれば、 LINE FEED 文字は SPACE 文字に変換されるべきである。そのようなスクリプトの例は、ラテン語、ギリシャ語、キリル語である。
   2. LINE FEED 文字に先行、後続する文字が、単語区切りの無い表意文字ベースのスクリプトや記法に属していれば、 LINE FEED 文字は消去されなけれるべきである。 そのようなスクリプトの例は、中国語、日本語である。
   3. LINE FEED 文字に先行、後続する文字が、単語区切りの無い非表意文字ベースのスクリプトに属していれば、 LINE FEED は ZERO WIDTH SPACE 文字 (​) に変換されるか、消去されるべきである。 そのようなスクリプトの例は、タイ語、クメール語である。
   4. (1) から (3) のどの状況も真でなければ、 LINE FEED 文字は SPACE 文字に変換されるべきである。

   ユニコード [UNICODE] 技術レポート TR#24 (Script Names) は、全ての文字に対するスクリプト名の割り当てを提供している。

3.6. 命名規則 (Naming Rules)

XHTML ホスト言語文書型は、ソフトウェアとユーザが文書型と XHTML との関係を、問題なく特定できるように、厳密な命名法を厳守しなければならない。 XML 文書型定義として実装される文書型の名前は、公式公開識別子 (Formal Public Identifier; FPIs) を通して定義される。 FPIs 中では、領域は二重スラッシュ文字シークエンス (//) で分けられる。 様々な領域は、以下のように構成される：

1. プライベートに定義された資源であることを示すために、先頭の領域は "-" でなければならない。
2. 二番目の領域は、命名されたアイテムを維持管理する責任を負う組織の名前を含んでいなければならない。 これらの組織名のための如何なる登録機関も無い。 個々の組織は、その名前を一意的に決定すべきである。 W3C によって使われている名前は、例えば W3C である。
3. 三番目の領域は、二つの構造を持つ：公開クラスが、公開テキスト記述に後続される。 三番目の領域における最初のトークンは、 ISO 8879, 10.2.2.1 節 公開テキスト・クラス (Public Text Class) を厳守すべき公開テキスト・クラスである。 XHTML ホスト言語に適合した文書だけが、公開テキスト記述が XHTML トークンで始まるべきである。 文書型が、統合セットに適合するならば、公開テキスト記述は XHTML と言う文字列を含むべきである。 領域は組織定義の一意的な識別子（すなわち、 MyML 1.0）も含まなければならない。 この識別子は、一意的な名前と、文書型が発展したときに更新できる、バージョン識別子とから構成されるべきである。
4. 四番目の領域は、そのアイテムが開発された言語（例えば EN）を定義する。

これらの規則を利用することで、 XHTML ホスト言語に適合する文書型の名前は、 -//MyCompany//DTD XHMTL MyML 1.0//EN となるかもしれない。 XHTML ファミリーに適合するモジュールの名前は、 -//MyCompany//ELEMENTS XHTML MyElements 1.0//EN になるかもしれない。 XHTML 統合セットに適合する文書型の名前は、 -//MyCompany//DTD Special Markup with XHTML//EN となるかもしれない。

3.7. XHTML モジュールの進化 (XHTML Module Evolution)

本仕様書で定義されている各々のモジュールは、前節の命名規則を遵守した一意的な識別子が与えられている。 時が経ち、モジュールは進化するかもしれない。このような進化の論理的な分岐は、モジュールの諸相がもはや前の定義と互換性が無いと言うことになるかもしれない。 本仕様書で定義されたモジュールに対して定義された文書型が、継続して実行できることを確かにする一助として、変化したモジュールと関係する識別子は更新されることになるだろう。 明らかに、そのモジュールの公式公開識別子 (FPI) とシステム識別子 (SI) は、各々に含まれるバージョン識別子の修正によって変更されることになるだろう。 更新された機能性を取り入れたい文書型は、同様の更新を必要とすることになるだろう。

加えて、モジュールの前のバージョン（複数あるかもしれない）は、前の、一意的な識別子を通して利用可能でありつづけるだろう。このようにして、 XHTML モジュールを利用して開発された文書型は、その集合が拡張、進化したとしても、それらの元となる定義をシームレスに利用して機能し続けるだろう。 同様に、そのような文書方に対して記述された文書例は、以前のモジュール定義を利用して妥当であり続けるだろう。

他の XHTML ファミリー・モジュールと文書型の作者は、それらの文書型に基づいた、それらのモジュールと文書例の継続的な機能性を確保するよう、同様の戦略を適用するように奨励される。