XHTML™ 1.0: 拡張可能ハイパーテキストマークアップ言語


W3CWD-html-in-xml-19990224

XHTML 1.0: 拡張可能ハイパーテキストマークアップ言語

XML 1.0 による HTML 4.0 の再定式化

W3Cワーキングドラフト 1999年2月24日

このバージョン[原文]:
http://www.w3.org/TR/1999/WD-html-in-xml-19990224
以前のバージョン:
http://www.w3.org/TR/1999/WD-html-in-xml-19981205
最新の公開バージョン:
http://www.w3.org/TR/WD-html-in-xml
ローカルブラウジング用に、[原文の] Zip圧縮のアーカイブとしても手に入れられる。
著作権:
著作権  ©  1998-1999 W3C (マサチューセッツ工科大学, フランス国立情報処理自動化研究所, 慶應義塾大学). すべての権利が留保されている。
著者:
Steven Pemberton, CWI (HTMLワーキンググループ座長)
Murray Altheim, Sun Microsystems
Daniel Austin, CNET: The Computer Network
Frank Boumphrey, HTML Writers Guild
John Burger, Mitre
Andrew W. Donoho, IBM
Sam Dooley, IBM
Klaus Hofrichter, GMD
Philipp Hoschka, W3C
Masayasu Ishikawa, W3C
Warner ten Kate, Philips Electronics
Peter King, Unwired Planet
Paula Klante, JetForm
Shin'ichi Matsui, W3C/Panasonic
Shane McCarron, The Open Group
Ann Navarro, HTML Writers Guild
Zach Nies, Quark
Dave Raggett, W3C/HP
Patrick Schmitz, Microsoft
Chris Wilson, Microsoft
Ted Wugofski, Gateway 2000
Dan Zigmond, WebTV Networks

概要

この仕様書は、HTML 4.0 を XML 1.0 アプリケーションとして再定式化した XHTML 1.0 を定義し、また HTML 4.0 によって定義されている名前空間に対応する3つの名前空間を定義するものである。エレメントおよびそのアトリビュートの意味論は、HTML 4.0 についてのW3C勧告で定義される。この意味論はXHTMLの将来的な拡張性の基礎を提供する。既存のHTMLユーザエージェントの互換性は、小集合のガイドラインに従うことにより実現可能である。

この文書の位置づけ

このワーキングドラフトは、何時にても他のW3C文書によって更新され、置換され、あるいは廃止されることがある。W3Cワーキングドラフトを参照資料として利用したり、「進行中の作業」以外のものとして引用することは不適切である。この文書は進行中の作業であって、W3C会員組織による保証としての意味合いを含むものではない。

この文書は W3C HTML アクティビティの一部として作成されている。HTMLワーキンググループ(会員限定)の目標はHTMLワーキンググループ憲章(会員限定)に論じられている。

コメント

この文書[原文]に関する詳細なコメントを www-html-editor@w3.org までお送り願いたい。個人的な応答は保証できないが、それが適切であるときには努力するつもりである。HTML機能に関する公開の議論は、メーリングリスト www-html@w3.org で行われる。HTMLに関する作業についてのW3Cスタッフ連絡役は Dave Raggett である。

目次

  1. XHTMLとは何か
    1. HTML 4.0 とは何か
    2. XMLとは何か
    3. XHTMLはなぜ必要か
  2. 定義集
    1. 用語集
    2. 全般的な用語
  3. XHTML 1.0 の規範的定義
    1. 文書の準拠性
    2. ユーザエージェントの準拠性
  4. HTML 4.0 との相違点
    1. 新しい必須事項
    2. 既存のコンテンツをXHTMLに変換する
  5. 互換性の問題
    1. インターネットメディア型
  6. 将来的な方向性
    1. HTMLのモジュラ化
    2. サブセットと拡張性
    3. 文書プロファイル

付録
付録 A. DTD
付録 B. エレメントの禁則
付録 C. ガイドライン
付録 D. 参照資料

1. XHTMLとは何か

XHTMLは、HTML 4.0 [HTML] を XML 1.0 [XML] のアプリケーションとして再定式化したものである。

XHTML 1.0 は、Strict, Transitional, Frameset という HTML 4.0 の3つのDTDに対応して、3つのXML名前空間を規定する。この3つの名前空間はそれぞれ独自のURIによって識別される。

XHTML 1.0 は、HTMLを拡張およびサブセット化する将来の文書型のファミリーの基礎となるものである。この考え方は、将来的な方向性に関する節でさらに詳細に論じられる。

1.1 HTML 4.0 とは何か

HTML 4.0 [HTML] は、国際規格 ISO 8879 に準拠したSGML(標準的汎用マークアップ言語)アプリケーションであり、広くワールド=ワイド=ウェブの標準的なパブリッシング言語として認められている。

SGMLは、マークアップ言語、とりわけ電子文書交換や文書管理、文書出版に使われる言語を記述するための言語である。HTMLは、SGMLで定義された言語の一例である。

SGMLは、1980年代半ば以来広まっており、きわめて安定的なままでいる。この安定性の多くは、この言語が機能に富みつつ柔軟でもあるという事実によるものである。もっとも、この柔軟性は一定の対価によって実現されるものであり、その対価とは、ワールド=ワイド=ウェブを含め多様な環境で採用することの妨げとなるレベルの複雑さである。

HTMLは、元々の認識では、文書の専門家でない者による利用に適した、科学やその他の技術的な文書の交換のための言語たらんとするものであった。HTMLは、比較的単純な文書を制作するのに適した構造的タグおよび意味論的タグの小集合を規定することにより、SGMLの複雑さの問題に対処した。文書構造を単純化することに加えて、HTMLは、ハイパーテキストのサポートを追加した。マルチメディア機能が後に追加された。

驚くほど短時間でHTMLは広くポピュラーなものになり、急速に元の目的を越えて成長した。HTMLの起こり以来、(標準としての)HTMLで利用したり、HTMLを垂直的で高度に特化されたマーケットに適合させたりするための新しいエレメントが急速に開発され続けている。この大量の新しいエレメントが、異なるプラットフォームにわたる文書についての互換性問題をもたらしている。

ソフトウェアおよびプラットフォームの双方の異種混合性が急速に広がるに伴い、これらのプラットフォームで利用する「クラシックな」HTML 4.0 の安定性は幾分限定されることが明らかである。

1.2 XMLとは何か

XMLとは Extensible Markup Language の短縮表記であり、eXtensible Markup Language [XML] の頭字語である。

XMLは、SGMLの複雑さの大半を取り除きながらSGMLの力と柔軟性とを取り戻す手段として考えられていた。SGMLの制限形態であるけれども、にもかかわらずXMLは、SGMLの力や豊富さのほとんどを保ち、なおSGMLの一般的に使われる機能のすべてを残している。

有益な機能を維持しつつ、XMLは、適したソフトウェアの制作や設計を困難かつ高コストなものとするSGMLの複雑な機能の多数を除去するのである。

1.3 XHTMLはなぜ必要か

コンテンツ開発者がXHTMLを採用するべき主な理由は2つある。

第一に、XHTMLは拡張可能であるよう設計されている。この拡張性は、文書が整形式でなくてはならないというXML必須事項を当てにしている。SGMLの下では、新しいエレメントグループの追加がDTD全体の変更を意味することがよくあった。XMLベースのDTDでは、既存のDTDに追加されるために要求されることは、新しいエレメントセットが内部的に一貫性があり、整形式であることだけである。これが新しいエレメント集合体の開発や統合を著しく容易にするのである。

第二に、XHTMLはポータビリティをねらって設計されている。非デスクトップのユーザエージェントを利用してインターネット文書にアクセスすることは、ますます増えるであろう。ある推計が示すところによると、2002年までにインターネット文書閲覧の75%がこれらの代用プラットフォームで実行されるという。ほとんどの場合、これらのプラットフォームにはデスクトッププラットフォームの計算力をもっていないであろうし、不整なHTMLも、現在のユーザエージェントならば調整する傾向があるが、これらのプラットフォームはこれを調整するように設計されないであろう。実際、これらのユーザエージェントは整形式でないXHTMLを受け取っても、単にその文書を表示しなくてよいのである。

2. 定義集

2.1 用語集

以下の用語がこの仕様書で使われるものである。この用語は、ISO/IEC 9945-1:1990 [POSIX.1] における類似の定義に基づいた方法で、[RFC2119] における定義を拡張したものである。

実装定義の (implementation-defined)
正しい文書構造についての対応する必須事項の定義[および文書化]が実装にゆだねられているとき、値または挙動は実装定義である。
してもよい (may)
実装に関しては、「してもよい」という言葉は、この仕様書において要求はされないが提供することができるオプショナル機能として解釈されるべきものである。文書の準拠性に関しては、「してもよい」という言葉は、オプショナル機能が使われてはならないという意味である。「オプショナルな」という用語は「してもよい」と同じ定義である。
しなければならない (must)
この仕様書では、「しなければならない」という言葉は、文脈次第で、実装か厳格準拠XHTML文書かに関する義務的な必須事項として解釈されるべきものである。「すべし(shall)」という用語は「しなければならない」と同じ定義である。
予約済み (reserved)
値または挙動は未規定であるが、準拠文書によって使われることや準拠ユーザエージェントによってサポートされることが許されない。
べきである (should)
実装に関しては、「べきである」という言葉は、実装の勧告であるが必須事項ではないと解釈されるべきものである。文書に関しては、「べきである」という言葉は、文書について推奨されるプログラミング慣習であり、厳格準拠XHTML文書の必須事項として解釈されるべきものである。
サポートされる (supported)
この仕様書にある一定のファシリティはオプショナルである。あるファシリティがサポートされるならば、それはこの仕様書によって規定された通りの挙動をする。
未規定の (unspecified)
値または挙動が未規定であるときは、そのファシリティを使う文書に直面させられたときであっても、仕様書は実装のファシリティについてポータビリティ必須事項を定義しない。そうしたインスタンスにおいて、そのファシリティを使うときに任意の挙動を黙認するのでなく特定の挙動を要求する文書は、厳格準拠XHTML文書ではない。

2.2 全般的な用語

アトリビュート (attribute)
アトリビュートとは、DTDで宣言されたエレメントのパラメータである。アトリビュートの型や値域は、とりうるデフォルト値も含め、DTDで定義される。
DTD
DTD、あるいは文書型定義とは、そのDTDに従う文書で利用できる合法な構造やエレメントアトリビュートを集合体として定義するXML宣言の集合体である。
文書 (document)
文書とは、それが参照する他のすべてのストリームと組み合わされた後の、結びつけられたDTDに定義されている通りに組み立てられたエレメントの中に含まれる情報を保持するように構築されたデータのストリームである。詳しい情報は文書の準拠性を見ること。
エレメント (element)
エレメントとは、DTDで宣言される、文書の構造単位である。エレメントの内容モデルはDTDで定義されるものであり、追加的な意味論はそのエレメントの散文的解説で定義されてもかまわない。
ファシリティ (facilities)
機能としては、エレメントアトリビュート、およびそのエレメントアトリビュートに結びつけられる意味論があげられる。当該機能をサポートする実装は、必要なファシリティを提供すると言われる。
実装 (implementation)
実装とは、ファシリティの集合体や、この仕様書をサポートするサービスを提供するシステムである。詳しい情報はユーザエージェントの準拠性を見ること。
解析 (parsing)
解析とは、文書をスキャンし、その文書に含まれている情報をその情報が構築されるエレメントの文脈へとフィルタリングする行為である。
レンダリング (rendering)
レンダリングとは、文書内の情報を表現する行為である。この表現は、その環境にとってもっとも適切な形式でなされる(たとえば音声的に、あるいは視覚的に、印刷で)。
ユーザエージェント (user agent)
ユーザエージェントとは、XHTML文書を引き出して表現する実装である。詳しい情報はユーザエージェントの準拠性を見ること。
妥当性検証 (validation)
妥当性検証とは、結びつけられたDTDに照らして文書を確認し、構造や、エレメントの用法、アトリビュートの用法がDTDにある定義と一貫しているよう保証する処理である。
整形式の (well-formed)
文書は、XML 1.0 勧告 [XML]Section 2.1 に定義された規則に従って構築されているとき、整形式である。基本的に、この定義は、開始タグと終了タグとで区切られたエレメントが互いに適切にネストされているということを言っている。

3. XHTML 1.0 の規範的定義

3.1 文書の準拠性

このバージョンのXHTMLは、厳格準拠XHTML文書に関する文書準拠性を定義するだけである。厳格準拠XHTML文書は、この仕様書において義務的なものとして記述されたファシリティのみを要求する文書である。そうした文書は、以下の規準のすべてに沿うものでなければならない。

  1. 付録 A にある3つのDTDのうちの一つに照らして妥当性が認められなければならない。

  2. 文書のルートエレメントは <html> でなければならない。

  3. 文書のルートエレメントは、xmlns アトリビュートを使うことにより、3つの定義済みDTDのうちの一つを指し示さなければならない [XMLNAMES]。指し示された名前空間は、その文書が妥当性が認められると主張する基準DTDの名前空間に一致しなければならない。定義済みの名前空間は、次の通りである。

  4. ルートエレメントに先立って、文書の中に DOCTYPE 宣言が1個なければならない。DOCTYPE 宣言に組み込まれる公開識別子は、付録 A にある3つのDTDのうちの一つを、それぞれの公式公開識別子を使って参照するものでなければならない。システム識別子は、適当に修正されてもかまわない。

    <!DOCTYPE
        html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
                    "xhtml1-strict.dtd">
    
    <!DOCTYPE
        html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
                    "xhtml1-transitional.dtd">
    
    <!DOCTYPE
        html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
                    "xhtml1-frameset.dtd">
    

厳格準拠XHTML文書は、tex/html または text/xhtml というインターネットメディア型でラベルづけされてもかまわない。text/html としてラベルづけされたときは、文書は 付録 C で明らかにされるガイドラインに従うべきである。このガイドラインに従わなければ、ほとんど確実に、その文書は古い実装で処理されないこととなるだろう。

こちらは、最小限のXHTML文書の例である。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
                         "xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/Profiles/xhtml1-strict.dtd">
<head>
<title>バーチャルライブラリ</title>
</head>
<body>
<p><a href="http://www.vlib.org/">www.vlib.org</a> に移転しました。</p>
</body>
</html>

3.2 ユーザエージェントの準拠性

準拠ユーザエージェントは、以下の基準のすべてに沿うものでなければならない。

  1. XML 1.0 勧告 [XML] と一貫したものであるよう、ユーザエージェントはXHTML文書の整形式性を解析し評価しなければならない。ユーザエージェントが妥当性を検証するユーザエージェントであると主張するならば、[XML] に従い、その参照されるDTDに照らして文書の妥当性も検証しなければならない。
  2. ユーザエージェントが、この仕様書の中で定義され、あるいは規範的参照を通じてこの仕様書によって要求されているファシリティをサポートすると主張するときには、そのファシリティの定義と一貫した方法でファシリティをサポートしなければならない。

4. HTML 4.0 との相違点

XHTMLがXMLアプリケーションであるという事実により、SGMLベースの HTML 4.0 [HTML] では完全に合法である一定の慣習は変更されなければならない。

4.1 新しい必須事項

4.1.1 文書は整形式でなければならない.

整形式性 (Well-formedness) は、[XML] によって導入された新しい概念である。本質的上これは、エレメントはすべて閉じタグをもつか(後述するように)特殊な形式で書かれなければならず、エレメントはすべてネストされなければならないとことを意味する。

オーバーラッピングはSGMLでは違法であるけれども、SGMLベースのブラウザでは広く黙認されていた。

正: ネストされたエレメント

<p>ここには強調された<em>段落</em>がある。</p>


誤: オーバーラッピングしているエレメント

<p>ここには強調された<em>段落</p>がある。</em>

4.1.2 エレメント名およびアトリビュート名は小文字でなければならない.

XHTML文書は、HTMLエレメント名およびアトリビュート名にはすべて小文字を使わなければならない。この違いが避けられないのは、XMLが大文字と小文字とを区別し、たとえば <li> と <LI> とは異なるタグとみなされるからである。

4.1.3 空でないエレメントについては終了タグが必須である.

SGMLベースの HTML 4.0 では、一定のエレメントは終了タグを省略することが許されていた。要素には黙示的な閉鎖がついていたのである。この省略はXMLベースのXHTMLでは許されない。DTDで EMPTY として宣言されたもの以外のエレメントはすべて、終了タグをもたなければならない。

正: 閉じられたエレメント

<p>ここに段落がある。</p><p>ここには他の段落がある。</p>


誤: 閉じられていないエレメント

<p>ここには段落がある。<p>ここには他の段落がある。

4.1.4 アトリビュート値はつねに引用符で括られなければならない.

アトリビュート値は、数値として現れるものであっても、すべて引用符で括られなければならない。

正: 引用符で括られたアトリビュート値

<table rows="3">


誤: 引用符で括られないアトリビュート値

<table rows=3>

4.1.5 アトリビュート最小化

XMLはアトリビュート最小化をサポートしない。アトリビュート-値の対はフル表記で書かれなければならない。compactchecked といったようなアトリビュート名は、その値が規定されなければエレメントに出現できない。

正: 最小化されないアトリビュート

<dl compact="compact">


誤: 最小化されたアトリビュート

<dl compact>

4.1.6 空エレメント

空エレメントは /> で終了しなければならない。例. <br />, <hr />.

正: 閉じられた空タグ

<br /><hr />


誤: 閉じられていない空タグ

<br><hr>

4.1.7 アトリビュート値の空白の扱い

XHTMLは、アトリビュート値の中にある空白の扱いについて、HTML 4.0 を変える。とりわけ、XHTMLは、先頭及び末尾の空白を剥ぎ取り、1個以上の空白キャラクタ(改行も含まれる)の連なりを単一の単語間空白(西洋文字についてはASCIIスペースキャラクタ)に割り付ける。[XML]Section 3.3.3 を見ること。

4.1.8 スクリプトエレメントおよびスタイルエレメント

XHTMLでは、スクリプトエレメントおよびスタイルエレメントは、#PCDATA 内容をもつものとして宣言される。結果として、&lt;&amp; といったようなエンティティは、XMLプロセッサにより、それぞれ <& に展開されることになる。スクリプトエレメントやスタイルエレメントの内容を CDATA マーク部の中に包み込むことで、これらのエンティティの展開が避けられる。

<script>
 <![CDATA[
 ... エスケープされていないスクリプト内容 ...
 ]]>
 </script>

CDATA 部は、XMLプロセッサによって認識され、DOM(文書オブジェクトモデル)のノードとして現れる。DOM1勧告 [DOM]Section 1.3 を見ること。

代替策としては、外部スクリプト文書や外部スタイル文書を使うというものがある。

4.1.9 SGMLのエレメント排除

SGMLは、DTDの書き手に、特定のエレメントがあるエレメントの中に包含されないよう排除する能力を与える。そうした禁則(「排除(exclusion)」と呼ばれる)は、XMLでは不可能である。

たとえば、HTML 4.0 Strict DTD は、子孫の深さを問わず、ある 'a' エレメントを他のある 'a' エレメントの中にネストすることを禁じる。XMLでそうした禁止を説明することは不可能である。この禁止がDTDで定義できない場合であっても、一定のエレメントはネストするべきではない。そうしたエレメントや、そのエレメントの中にネストされるべきではないエレメントをまとめたものは、規範性を有する 付録 B で見られる。

4.1.10 HTML 4.0 エラッタ

現行の HTML 4.0 DTD は、HTML 4.0 勧告 [HTML] に対してなされたエラッタを反映するものではない。XHTML DTD はこのエラッタを組み込み、そのため HTML 4.0 DTD のエラーは XHTML では訂正される。エラッタは [ERRATA] で見ることができる。

4.2 既存のコンテンツをXHMTLに変換する

HTML Tidy は、既存のウェブコンテンツを自動的にXHTMLに変換するW3Cサンプルコードである。これは広範なマークアップエラーを処理することができ、既存のHTML文書からXHTMLへスムーズに移行するための手段を提供する。詳しい情報については、[TIDY] を見ること。

5. 互換性の問題

XHTML 1.0 文書が既存のユーザエージェントと互換的であるべきとの要求はないけれども、実際これは実現が簡単である。互換的な文書を作成するためのガイドラインは、付録 C で見ることができる。

5.1 インターネットメディア型

XHTML文書は、以下のインターネットメディア型のうちの一つを使って転送してよい。これらの型を使って、汎用XMLアプリケーションへサーブできるXHTML文書(text/xml)や、旧来のHTMLユーザエージェントへサーブできるもの(text/html)、新しいXHTMLアプリケーションにサーブできるもの(text/xhtml)を作成することにより、文書制作者はポータブルなインターネットコンテンツを作成することができる。

5.1.1 text/xml

どのXHTML文書も整形式かつ妥当なXML文書でもあるから、text/xml [RFC2376] というインターネットメディア型を使って転送されてもかまわない。もっとも、XHTML文書を text/xml として転送すると、2つの点で情報が失われる。

第一に、この仕様書のテキストに与えられているが文書に結びつけられた XHTML DTD によって捉えられない制約は、妥当性を検証する汎用XMLパーサが強制することはできない。

第二に、HTML 4.0 仕様書に記述されているが文書に結びつけられたスタイルシートによって捉えられないレンダリング意味論は、汎用XMLアプリケーションがレンダリングすることはできない。

要するに、受領者が text/xml しか知らなければ、XHTML特有の解析制約をチェックするべきことがわからず、またXHTML特有の意味論をレンダリングするべきことがわからないのである。

文書に関して汎用のXML処理だけが要求される環境では、サーバはなおXHTML文書を text/xml として転送することを選んでもよかろう。

将来のバージョンのXHTMLにとっての究極の目標の一つは、XHTML文書が text/xml として転送されても失われるような情報がないということにある。もっとも、この仕様書はその目標をまだ実現していない。

5.1.2 text/html

XHTML文書が 付録 C の内容であるガイドラインに準拠すれば、それは HTML 4.0 文書でもあり、そうすると text/html というインターネットメディア型を使って転送されてもかまわない。もっとも、XHTML文書を text/html として転送すると、2つの点で情報が失われる。

第一に、受領者は、その文書が妥当なXML文書であると主張していることを知る方法がなく、そうすると汎用XMLツールを使ってその文書の文法をチェックしたり文書をレンダリングすることができない。したがって、その場限りの方式で HTML 4.0 文法をチェックし、かつ/または HTML 4.0 意味論をレンダリングするべく用意されていなければならない。

第二に、受領者は、その文書が妥当なXHTML文書であると主張していることを知る方法がなく、そうするとXHTML文書には要求されるが HTML 4.0 文書には要求されない制約を強制することができない。

XHTMLサポートが受領者には存在しない環境では、サーバはXHTML文書を text/html として転送することを選んでもよかろう。

text/html というインターネットメディア型を使ってXHTML文書を転送することは、HTMLからXHTMLへのスムーズな意向を支援する助けとなり、またその早期の採用を奨励する助けとなるであろう。この型を使って転送されたXML文書は、既存のユーザエージェントによって通常の方法で処理される可能性が高い。

5.1.3 text/xhtml

上記の text/xmltext/html というインターネットメディア型はそれぞれXHTML文書についての情報を切り捨てるので、text/xhtml というインターネットメディア型を登録するというのがW3Cの意図である。

text/xhtml という型の文書に遭遇した準拠ユーザエージェントは、その文書がこの仕様書に準拠していると主張していることを前提としてよい。この前提は、text/xhtml 型の文書の受領者が、文書の整形式性をチェックしなければならず、また文書に結びつけられている XHTML DTD に照らして文書の妥当性をチェックしてもかまわないとことを意味する。

我々は、このメディア型の役割や代替機構に関する議論を大歓迎する。

6. 将来的な方向性

XHTML 1.0 は、広範な新デバイスや新アプリケーションをサポートするために、モジュールを定義し、このモジュールを組み合わせるための機構を規定することにより、XHTML を拡張したりサブセット化する文書型のファミリーのための基礎を提供する。この機構は、新モジュールの定義を通じて統一的な方法で XHTML 1.0 の拡張やサブセットかを可能にするものである。

6.1 HTMLのモジュラ化

伝統的なデスクトップのユーザエージェントからその他のプラットフォームとXHTMLの用途が移るに伴い、すべてのプラットフォームでXHTMLエレメントのすべてが要求されるとは限らないことが明らかである。たとえば、ハンドヘルドのデバイスや携帯電話は、XHTMLエレメントのサブセットしかサポートしなくてもかまわない。

モジュラ化という処理は、XHTMLを一連の小さいエレメントセットに分割することである。そしてこれらのエレメントは、異なるコミュニティの必要に見合うよう再度組み合わせることができるのである。

このモジュールは、後のW3C文書で定義されるであろう。

6.2 サブセットと拡張性

モジュラ化はいくつかの利点をもたらす。

6.3 文書プロファイル

文書プロファイルは、文書セットの文法および意味論を規定するものである。文書プロファイルに準拠するということは、相互運用性の保証の基礎を提供する。文書プロファイルは、その型の文書を処理するために必要なファシリティ、たとえばどの画像フォーマットが使えるかということや、スクリプトのレベル、スタイルシートサポートなどといったものを規定する。

プロダクト設計者にとって見ると、これは多様なグループが独自の標準的プロファイルを定義することを可能にする。

制作者にとって見ると、これは、いくつもの異なるクライアントのための異なるバージョンの文書を書く必要性を取りのける。

科学者や医学者、数学者といったような特殊なグループにとって見ると、これは、その専門家の必要にかみ合うエレメントグループを標準的なHTMLエレメントに追加して使って、特殊なプロファイルが構築できるようにする。

付録

付録 A. DTD

この付録は規範的である。

3つのDTDとエンティティセットとが、この仕様書の規範的部分を形成する。XML宣言やSGML公開カタログつきのDTDファイルの完全セットは、この仕様書[の原文]についてのzipファイルの中に含まれている。

A.1 文書型定義 (DTD)

これらのDTDは HTML 4.0 DTD に近いものである。DTDがモジュラ化されるとき、HTML 4.0 にきわめて密接に対応するDTD構築の方法が採用される可能性は高い。

A.2 エンティティセット

XHTMLエンティティセットは、HTML 4.0 用のものと同じであるが、妥当な XML 1.0 エンティティ宣言となるよう修正されている。ユーロ通貨記号(&euro; または &#8364;)を表すエンティティは、特殊キャラクタの一部として定義される。

付録 B. エレメントの禁則

この付録は規範的である。

以下のエレメントは、包含できるエレメントについての禁則がある(Section 4.1.9 を見ること)。この禁則は、すべてのネスト深度に適用される。すなわち、すべての子孫エレメントが含まれるのである。

a 他の a エレメントを包含できない.
pre img, object, big, small, sub, sup エレメントを包含できない.
button input, select, textarea, label, button, form, fieldset, or iframe エレメントを包含できない.
label 他の label エレメントを包含できない.
form 他の form エレメントを包含できない.

付録 C. ガイドライン

この付録は参考である。

この付録は、既存のHTMLユーザエージェントでXHTML文書をレンダリングしたい制作者のための設計ガイドラインをまとめたものである。

付録 D. 参照資料

この付録は参考である。

[CC/PP]
"Composite Capability/Preference Profiles (CC/PP): A user side framework for content negotiation", F. Reynolds, J. Hjelm, S. Dawkins, S. Singhal, 1998年11月30日.
この文書は、RDF(リソース記述フォーマット)を使って、ユーザ選好やデバイス能力を記述するための、一般的であるながら拡張可能であるフレームワークを作成するための方法を記述したものである。サーバはこれを活用して、提供されるサービスやコンテンツをカスタマイズすることができる。
http://www.w3.org/TR/NOTE-CCPP にて入手可能.
[CSS2]
"Cascading Style Sheets, level 2 (CSS2) Specification", B. Bos, H. W. Lie, C. Lilley, I. Jacobs, 1998年5月12日.
http://www.w3.org/TR/REC-CSS2 にて入手可能.
[DOM]
"Document Object Model (DOM) Level 1 Specification", Lauren Wood , 1998年10月1日.
http://www.w3.org/TR/REC-DOM-Level-1 にて入手可能.
[ERRATA]
"HTML 4.0 Specification Errata".
この文書は、HTML 4.0 仕様書についてのエラッタを列挙したものである。
http://www.w3.org/MarkUp/html40-updates/REC-html40-19980424-errata.html にて入手可能.
[HTML]
"HTML 4.0 Specification", D. Raggett, A. Le Hors, I. Jacobs, 1997年12月18日, 1998年4月24日校訂.
http://www.w3.org/TR/REC-html40 にて入手可能.
[POSIX.1]
"ISO/IEC 9945-1:1990 Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) [C Language]", Institute of Electrical and Electronics Engineers, Inc, 1990.
[RFC2119]
"RFC2119: Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, 1997年3月.
http://www.ietf.org/rfc/rfc2119.txt にて入手可能.
[RFC2376]
"RFC2376: XML Media Types", E. Whitehead, M. Murata, 1998年7月.
http://www.ietf.org/rfc/rfc2376.txt にて入手可能.
[RFC2396]
"RFC2396: Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, L. Masinter, August 1998.
この文書はRDF1738およびRFC1808を更新する。
http://www.ietf.org/rfc/rfc2396.txt にて入手可能.
[TIDY]
"HTML Tidy" は、HTMLに蔓延している広範なマークアップエラーを検知して訂正するためのツールである。これは既存のHTMLコンテンツを整形式XMLになるよう変形するためのツールとしても使うことができる。Tidy は、その他のW3Cサンプルコードと同じ約款に基づいて、すなわち目的を問わず無料であるが完全に自身のリスクにおいて利用できるようにされている。
http://www.w3.org/Status.html#TIDY から入手可能である。
[XML]
"Extensible Markup Language (XML) 1.0 Specification", T. Bray, J. Paoli, C. M. Sperberg-McQueen, 1998年2月10日.
http://www.w3.org/TR/REC-xml にて入手可能.
[XMLNAMES]
"Namespaces in XML", T. Bray, D. Hollander, A. Layman, 1999年1月14日.
XML名前空間は、XML文書で使われる名前を、URIによって識別される名前空間と結びつけることにより修飾するための単純な手段を用意するものである。
http://www.w3.org/TR/REC-xml-names にて入手可能.
[XMLSTYLE]
"Associating stylesheets with XML documents Version 1.0", J. Clark, 1999年1月14日.
この文書は、xml-stylesheet というターゲットをもつ1個以上の処理命令を文書のプロローグ部に組み込むことによりXML文書にスタイルシートを結びつける方法を記述したものである。
http://www.w3.org/TR/PR-xml-stylesheet にて入手可能.

どら猫本舗 (webmaster@doraneko.org)