1. 導入 (Introduction)

この節は参考的。

1.1. XHTML とは何ぞや？ (What is XHTML?)

XHTML とは、 HTML 4 を XML アプリケーションとして再構成したものである。 XHTML 1.0 [XHTML1] は、HTML 4 の三つの DTDs: Strict, Translation, Frameset に対応して、三つの XML 文書型の仕様を与える。 XHTML 1.0 は、 HTML を拡張、又はサブセット化した文書型のファミリーとしての基礎を持っている。

1.2. XHTML モジュール化とは何ぞや？ (What is XHTML Modularization?)

XHTML モジュール化とは、 HTML 4 を参考として、 XHTML 1.0 を、機能性の仕様タイプを提供する抽象モジュールの集合に、分解することである。 これらの抽象モジュールは、 XML 文書型定義の言語を用いて、本仕様書において実装される。 抽象モジュールの定義と、 XML DTDs を用いた実装のための規則も、本文書において定義されている。

これらのモジュールは、相互に、また他のモジュールと結合され、 XHTML ファミリー文書型の一員としての資格を持つ、 XHTML 文書型のサブセットや、拡張型を作る。

1.3. 何故 XHTML をモジュール化するのか？ (Why Modularize XHTML?)

XHTML のモジュール化は、十分に定義された XHTML 要素のセットを特定するために参照される。これらの要素セットは、増え続ける大量のプラットフォームにコンテンツを乗ようとする際、コンテンツ製作者が、その労力を省き、実行できるようにするために、文書の作者、文書型の構築者、他の XML 標準仕様、そしてアプリケーションや製品の設計者によって、結合され、拡張され得る。

過去数年来、多岐に渡って専門化した市場は、コンテンツ言語として、 HTML に頼りだしてきた。 増え続けるコンピューティング・プラットフォームに渡り、 HTML を利用しようという大きな傾向が存在する。 最近は、 HTML を、モバイル・デバイス（ハンドヘルド・コンピュータ、携帯電話など）、テレビ（デジタル・テレビ、テレビ・ベースのウェブ・ブラウザなど）、家電（据え置き機能デバイス）へ HTML を移行させる動きがある。 これらのデバイスは、それぞれ異なる要件と制約を持っている。

あるデバイスが標準的な建築ブロックあるいは、どの建築ブロックが使われているか特定するための標準的手段を採用していれば、XHTML のモジュール化によって、製品設計者は、どの要素がサポートされているかを特定する手段が得られる。 これらのモジュールは、コンテンツ・コミュニティーに、「適合ポイント (point to conformance)」を提供する。 このコンテンツ・コミュニティーは、インストールされた土台がサポートする XHTML 要素の組み合わせをあれこれ心配するのではなく、今や特定のモジュール集合をサポートする土台を標的にすることができる． 標準的なものを利用することが、対極的に XHTML のモジュール化が成功するかどうかの条件になるのである。 コンテンツ開発者にとって、個々のそして全ての XHTML 要素の組み合わせに対してコンテンツを仕立て合わせることは、効率的に満足の行くことではない。 標準的なものを特定しておくことで、どのソフトウェアーも、そのプロセスで、自動的にコンテンツをデバイスに仕立て合わせたり、モジュールを実行するために必要なソフトウェアーを、デバイスが自動的にロードできる。

モジュール化すれば、 XML の拡張可能性を用いることで、 XHTML の標準仕様に抵触することなく、 XHTML のレイアウトと表現能力の拡張も考慮に入れられる。 この開発過程は、ウェブの急速な技術的変化にどうにか対応しているコンテンツ開発者や出版社に、安定的で、有意義で、実現可能なフレームワークを提供する。

1.3.1. 抽象モジュール (Abstract modules)

XHTML 文書型は抽象モジュールとして定義されている。 一つの抽象モジュールは、一つの種類のデータを定義しており、これは他の全てとは意味的に異なる。 抽象モジュールは、モジュールを定義している背後的なスキームに関して通暁することなしに、文書型に結合することが出来る。

1.3.2. モジュール実装 (Module implementations)

一つのモジュール実装は、要素タイプの一つのセット、一つの属性定義リスト、内容モデル宣言の一つのセットから成る。これら三つのセットの何れも空集合であってかまわない。 モジュールの属性定義のリストは、モジュールで定義されている要素タイプの外部で、要素タイプを修正するかもしれないし、内容モデルも、モジュールの要素タイプ・セットの外部でで、要素タイプを修正するかもしれない。

一つの実装・メカニズムは、 XML DTDs である。 XML DTD は、 XML 文書のクラスの構造、正確には XML 文書型として知られるものを表現する手段である。 XML DTDs は、 XML 1.0 勧告 [XML] で述べられている。 もう一つの実装メカニズムは、 XML スキーム [XMLSCHEMA] である。

1.3.3. 混合文書型 (Hybrid document types)

混合文書型は、 XML DTDs や DTD モジュールの集合から構成された文書型である。 この文書で述べられている、モジュール化フレームワークの最初の目的は、 DTD 作者に、複数の抽象モジュールから混合文書型へ要素を結合し、その混合文書型に対して文書を開発し、そしてその文書を関連する混合文書型にたいして妥当させることである。

SGML に対する XML の価値の中でも最も有意義なことは、要素セットの標準化のための敷居を下げられることである。こうすることで、コミュニティーは、互換性のあるフォーマットでデータを交換できるようになる。 しかしながら、ウェブのコンテンツ言語としての HTML の比較的固定的な性質のために、これらのコミュニティーはどこも、自身の XML 文書型がウェブ標準の一部として広く採用されるようになることを、殆ど望まなかった。 このモジュール化フレームワークでは、 これらの様々な文書型を、 XHTML ファミリーの文書型の中で、動的に混在させることにたいして、 XHTML 文書のドメインごとに特有な語彙の混在に対する敷居を、更に押し下げることが考慮されている。

1.3.4. 妥当性 (Validation)

ウェル・フォームド（整形式; well-formed）であっても、妥当 (valid) ではない文書を利用できることは、 XML の重要な価値である。 しかしながら、文書型を開発する過程で、エラー・チェックのための妥当性パーサによって提供される追加的な手段は重要である。 同じことが、複数の抽象モジュールによる要素をもつ XHTML 文書型に対しても言える。

文書は、文書のプロローグ部で特定されている DTD によって定義される、或る文書型の例である。 文書の妥当化とは、文書型定義の規則に相応するかどうかをチェックする過程である。

一つの文書は、文書の断片の複数から成る。一つの文書の中でその断片だけに対する妥当化は、その各々の断片が異なる文書型から成る場合には、このフレームワークの範囲を超えている。と言うのは、まだ定義されていない技術が必要とされるだろうからだ。

しかしながら、このモジュール化フレームワークによって、複数の文書型定義は統合され、新たな文書型を形成できる（例えば、 SVG は XHTML に統合された）。 この新しい文書型定義は、通常の XML 1.0 の妥当化に利用され得る。

1.3.5. フォーマット化のモデル (Formatting Model)

HTML の最初の頃の版では、文書のフォーマットに、ユーザー・エージェントが必要とされるようなモデルの部分を定義する傾向にあった。 HTML 4 の出現で、 W3C は構造と表現を分離する過程を開始した。 XHTML 1.0 はこの分離傾向を維持し、そしてこの文書は HTML とその後継言語を、この道に沿って進め続ける。 結果的に、この文書は、 XHTML 文書型でマークアップされた文書の表現に関するフォーマット化のモデルに関しては、いかなる要求もしない。

代わりに、この文書は、コンテンツ作者は、各自のフォーマット化のモデルの定義に対して、 CSS のようなスタイル・メカニズムを採用するように推奨する。 ユーザー・エージェントがスタイル・メカニズムをサポートする場合は、文書は想定された形式に従うだろう。 ユーザー・エージェントがスタイル・メカニズムをサポートしない場合は、文書はそのユーザー・エージェントに応じた形式に従うだろう。このことによって、 XHTML ファミリー・ユーザー・エージェントは、そうすることが適当なデバイス上では、豊かなフォーマット化のモデルをサポートできるようになり、そして、 そうすること が適当なデバイス上では、貧弱なフォーマット化のモデルをサポートできるようになる。