3. 適合性定義

XHTMLファミリの文書がXHTMLファミリの利用者エージェント間で最大の移植可能性をもつことを確実にするために，この規定は，これらの両者に対して, 及びXHTMLファミリの文書型に対して，適合性の要件を厳密に定義する。適合性の定義は, 3.に示されるが, それは, この標準情報(TR)の中, XHTML基本[XHTML1]の中, 及び他の関連規定の中の規定テキストを参照する必要がある。すべての引用規定を完璧に読むことだけによって, XHTMLの適合性の要件を完全に理解することができる。

この標準情報(TR)の中のキーワードの, "でなければならない(MUST)", "してはならない(MUST NOT)", "必要な(REQUIRED)", "でなければならない(SHALL)", "してはならない(SHALL NOT)", "であることが望ましい(SHOULD)", "推奨の(RECOMMENDED)", "してよい(MAY)", 及び"オプションの(OPTIONAL)"は，[RFC2119]に示されるとおりに解釈される。

3.1. XHTMLホスト言語文書型の適合性

既存の文書型を変更したり，この規定で定義されるモジュール及び他のモジュールの両方を使用して，全く新しい文書型を定義することができる。次の基準を満たす場合, その文書型は, "XHTMLホスト言語適合"とする。

• a) 文書型は，W3Cが定義する実装方法の一つを使用して, 定義されなければならない。現在，これはXMLのDTDに限定されているが，XMLスキーマがまもなく利用可能になる。他の実装は可能であるが，3.の残りの部分は，"DTD"を参照する。
• b) 文書型を定義するDTDは，公開テキスト記述の最初のトークンに文字列"XHTML"を使用する命名規則で定義される，一意識別子をもたなければならない。
• c) 文書型を定義するDTDは，最低でも，この規定で定義される構造モジュール, ハイパテキストモジュール, テキストモジュール, 及びリストモジュールを含まなければならない。
• d) ここに含まれるW3C定義の各モジュールについては，要素，属性，(必要な列挙値リストのすべてを含む)属性の型，及び必要な最小の内容モデルのすべてが，文書型の内容モデルの中に含まれなければならない(オプションで拡張されなければならない)。内容モデルが拡張される場合，元の内容モデルに必要な要素及び属性のすべては，(その型又は必須のすべての列挙値リストとともに)必要とされ続けなければならない。
• e) 文書型を定義するDTDは，追加の要素及び属性を定義してよい。しかし，これらは, それ自体のXML名前空間[XMLNAMES]の中になければならない。

3.2. XHTML統合集合文書型の適合性

XHTMLには基づくが，その構造には従わない文書型を定義することもできる。次の基準を満たす場合，その文書型は, "XHTML統合集合適合"とする。

• a) 文書型は, W3Cが定義する実装方法の一つを使用して定義されなければならない。現在，これはXMLのDTDに限定されているが，XMLスキーマがまもなく利用可能になる。他の実装は可能であるが，3.の残りの部分は, "DTD"を参照する。
• b) 文書型を定義するDTDには，公開テキスト記述の最初のトークンに文字列"XHTML"を使用しない命名規則で定義される，一意識別子をもたなければならない。
• c) 文書型を定義するDTDは，最低でも，この規定で定義されるハイパテキストモジュール, テキストモジュール, 及びリストモジュールを含まなければならない。
• d) ここに含まれるW3C定義の各モジュールについては，要素，属性，(必要な列挙型リストのすべてを含む)属性型，及び必要な最小の内容モデルのすべてが, 文書型の内容モデルに含まれなければならない(オプションで拡張されなければならない)。内容モデルが拡張される場合，元の内容モデルに必要な要素及び属性のすべては，(その型又は必須のすべての列挙値リストとともに)必要とされ続けなければならない。
• e) 文書型を定義するDTDは，追加の要素及び属性を定義してよい。しかし，これらは，それ自体のXML名前空間[XMLNAMES]の中になければならない。

3.3. XHTMLファミリモジュールの適合性

この規定は，XHTML適合モジュールの定義する方法を規定する。次の基準をすべて満たす場合に，モジュールはこの規定に適合する。

• a) 文書型は，W3Cが定義する実装方法の一つを使用して定義されなければならない。現在，これはXMLのDTDに限定されているが，XMLスキーマがまもなく利用可能になる。他の実装も可能であるが，3.の残りの部分は, "DTD"を参照する。
• b) モジュールを定義するDTDは，命名規則で定義される，一意識別子をもたなければならない。
• c) モジュールがXMLのDTDを使用して定義される場合，モジュールは，一意の接頭辞の使用又は他の類似した方法によって，そのパラメタ実体名を分離しなければならない。
• d) モジュール定義は，それが宣言する要素，属性，及び/又は内容モデルの構文要件及びセマンティック要件を記述する説明定義をもたなければならない。
• e) モジュール定義は，他のW3C定義のモジュールの中で定義される要素名を再使用してはならない。ただし，内容モデル及びそれらの要素のセマンティクスが, 元のもの又は元のものの拡張のどちらかと同一である場合，又は，再使用される要素名がそれ自体の名前空間内にある場合のどちらかの場合を除く(以降を参照)。
• f)モジュール定義の要素及び属性は，XML名前空間[XMLNAMES]の一部でなければならない。モジュールがW3C以外の組織によって定義される場合は，この名前空間は，他のW3Cモジュールが定義される名前空間と同じであってはならない。

3.4. XHTMLファミリ文書の適合性

適合するXHTMLファミリ文書は，XHTMLホスト言語に適合する文書型の有効なインスタンスとする。

3.5. XHTMLファミリ利用者エージェントの適合性

適合する利用者エージェントは，([XHTML1]で定義される)次の基準のすべてを満たさなければならない。

• a) XML 1.0勧告[XML]と一貫性を保つために，利用者エージェントは, 整形式に関してXHTML文書を解析し，評価しなければならない。利用者エージェントが妥当性検証利用者エージェントであることを主張する場合，それは, [XML]に従って，参照されるDTDに対して，文書の妥当性をも検証しなければならない。
• b) 利用者エージェントが, この原規の中で定内で定義されるか，引用規定を通してこの規定で要求される機能をサポートすることを主張する場合，それは, 機能の定義と一貫性のある方法でサポートを実行しなければならない。
• c) 利用者エージェントがXHTML文書を共通[XML]として処理するとき，ID型の属性(例えば, ほとんどのXHTML要素中のid属性)だけを素片識別子として認識しなければならない。
• d) 利用者エージェントが, それが認識しない要素に出会うと，それは, その要素の子供を処理し続けなければならない。内容がテキストである場合，そのテキストは利用者に表示されなければならない。
• e) 利用者エージェントが, それが認識しない属性に出会うと，それは, すべての属性規定(すなわち，属性及びその値)を無視しなければならない。
• f) 利用者エージェントが, それが認識しない属性値に出会うと，それは, デフォルト属性値を使用しなければならない。
• g) 利用者エージェントが, 利用者エージェントが宣言を処理しなかった(事前に定義された実体の一つではない)実体参照に出会うと，その実体参照は，実体参照を形成する文字(アンパサンドで始まり，セミコロンで終わる)としてレンダリングされるのが望ましい。利用者エージェントが宣言を処理しなかった実体参照は, その宣言が, 利用者エージェントが読まなかった外部集合の中にあるとき, 起こり得る。
• h) 内容をレンダリングする際に，認識されるがレンダリングできない文字又は文字実体参照に出会う利用者エージェントは，通常のレンダリングが行われなかったことが利用者に明らかになる方法で, 文書を表示するのが望ましい。
• i) 空白は, 次の規則に従って扱われる。次の文字は，[XML]では空白文字として定義されている。
  • スペース ( )
  • 水平タブ (	)
  • 復帰 (
)
  • 改行 (
)

  XMLプロセサは，異なるシステムの行末の符号を単一の改行文字に正規化し, これがアプリケーションに渡される。

  利用者エージェントは，次に示すとおり，XMLプロセサから受け取ったデータの中の空白文字を処理しなければならない。

  • ブロック要素を囲む空白はすべて削除されるのが望ましい。
  • コメントは完全に削除され，空白の操作に影響しない。コメントの片側の一つの空白文字は，二つの空白文字として取り扱う。
  • 'xml:space'属性が'preserve'に設定されている場合，空白文字は保存されなければならず，したがって，ブロック内の改行文字は変換されてはならない。
  • 'xml:space'属性が'preserve'に設定されていない場合は, 次のとおりとする。
    • ブロック要素内部の先行する空白及び後続の空白は, 削除されなければならない。
    • 改行文字は，スペース文字，ゼロ幅スペース文字(​), 又は文字なし(削除)の一つに変換されなければならない。結果としての文字の選択は, 利用者エージェントに依存し，改行文字の前後の文字のスクリプト特性に応じて変わる。
    • 改行文字のない空白文字の列は，単一のスペース文字に削減されなければならない。
    • 一つ以上の改行文字をもつ空白文字の列は，単一の改行文字と同じ方法で削減されなければならない。

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

  参考 改行文字を変換する方法を決定する際に，利用者エージェントは，次の事例を考慮するのが望ましい。つまり，改行の片側の文字のスクリプトは, 置換の選択を決める。句読点などの共通スクリプトの文字は，他の側のスクリプトと同じものとして扱われる。

  • 1) 改行文字の前後の文字が, スペース文字を語の分離文字として使用するスクリプトに属する場合，改行文字はスペース文字に変換されるのが望ましい。このスクリプトの例として，ラテン語，ギリシャ語及びキリル語がある。
  • 2) 改行文字の前後の文字が, 表意文字ベースのスクリプトに属するか，又は語の分離がない表記システムに属する場合，改行は削除されるのが望ましい。このスクリプトの又は表記システムの例として，中国語，日本語がある。
  • 3) 改行文字の前後の文字が, 単の分離がない非表意文字ベースのスクリプトに属する場合，改行はゼロ幅スペース文字(​)に変換されるか，削除されるのが望ましい。このスクリプトの例として，タイ語，クメール語がある。
  • 4) 1)から3)までのどの条件も真でない場合，改行文字はスペース文字に変換されるのが望ましい。

  Unicode [UNICODE]technical report TR#24 (Script Names)は，すべての文字にスクリプト名の割当てを行っている。

3.6. 命名規則

XHTML ホスト言語文書型は，厳密な命名の規約に従わなければならない。それによって，ソフトウェア及び利用者は，文書型のXHTMLへの関係を直ちに決定できる。XML文書型定義として実装される文書型の名前は，公式公開識別子(FPI)によって定義される。FPIの中では，フィールドは二つのスラッシュ文字の列(//)によって分離される。多様なフィールドは, 次のとおり構成されなければならない。

• a) 最初のフィールドは，私的定義の資源を示すために，"-"でなければならない。
• b) 第2フィールドは，命名された項目を保守する責任のある組織の名前を含まなければならない。これらの組織名に関する公式登録簿はない。各組織は, 一意の名前を定義するのが望ましい。例えば，W3Cが使用する名前は, W3Cとする。
• c) 第3フィールドは，二つの構成子を含む。つまり，公開テキストクラスの後に, 公開テキスト記述が続く。第3フィールドの最初のトークンは, 公開テキストクラスであり, それは，ISO 8879の10.2.2.1の公開テキストクラスに従うのが望ましい。XHTMLホスト言語適合文書だけは，公開テキスト記述をトークンXHTMLで始めるのが望ましい。文書型が統合集合適合であるとき，公開テキスト記述は，文字列XHTMLを含むのが望ましい。そのフィールドは，組織定義の一意識別子(例えば, MyML 1.0)も含まなければならない。この識別子は，一意の名前と，文書型が進展するときに更新できる版数識別子とから構成されるのが望ましい。
• d) 第4フィールドは，その項目が開発される言語(例えば, EN)を定義する。

これらの規則を使用すると，XHTMLホスト言語適合の文書型の名前は, -//MyCompany//DTD XHTML MyML 1.0//EN と例示できる。XHTMLファミリ適合のモジュールの名前は, -//MyCompany//ELEMENTS XHTML MyElements 1.0//EN と例示できる。XHTML統合集合適合の文書型の名前は, -//MyCompany//DTD Special Markup with XHTML//EN と例示できる。

3.7. XHTMLモジュールの進展

この標準情報(TR)で定義される各モジュールには，3.6の命名規則に従う一意識別子が提供される。モジュールは，たえず進展してよい。これらの進展の論理的細分化は，以前の定義とはもはや互換性がないモジュールもあり得ることにもなる。 この規定で定義されるモジュールに対して定義された文書型が動作し続けることを確実にするために，変化するモジュールに関連した識別子を更新する。特に，そのモジュールの公式公開識別子及びシステム識別子は，それぞれに含まれる版数識別子を修正することによって，変更される。更新された機能を組み込む必要のある文書型は, 同様に更新される必要がある。

さらに，モジュールの以前の版は，以前の一意の識別子によって継続して利用可能となる。この方法で，XHTMLモジュールを使って開発された文書型は，その集まりが拡張し，進展しても，元の定義を用いて連続して機能し続ける。同様に，これらの文書型に対して記述された文書インスタンスは，以前のモジュール定義を使用する妥当性検証を続ける。

他のXHTMLファミリモジュール及び文書型の作成者には，それらのモジュールに基づく文書型と, それらの文書型に基づく文書インスタンスとの継続した機能性を確実にするために, 同様の方法を採用することが推奨される。