remove
powerd by nog twitter

XHTML 1.0: 拡張可能なハイパーテキスト・マークアップ・ランゲージ

XML 1.0 のために、HTML 4 の再公式化

W3C 推奨 2000年1月26日

現在のバージョン(邦訳原文):
http://www.w3.org/TR/2000/REC-xhtml1-20000126
(ポストスクリプト版, PDF 版, ZIP アーカイブGzip'd TAR アーカイブ)
最新のバージョン:
http://www.w3.org/TR/xhtml1
前のバージョン:
http://www.w3.org/TR/1999/PR-xhtml1-19991210
著者:
謝辞を参照して下さい。

要約

この仕様書は、XHTML 1.0、 XML 1.0 適用としての HTML 4 の再公式化、 および、HTML 4 によって定義されたものに対応する3つのDTDを、定義します。 要素の語義論およびそれらの属性は、 HTML 4 に対する W3C推薦(W3C Recommendation)に定義されます。 これらの語義論は、XHTMLの将来の拡張性に基礎を与えます。 既存のHTMLユーザ・エージェントとの互換性は、ガイドラインのわずかなセットに従うことにより可能です。

このドキュメントのステータス

この文書は、個人的な学習を目的に、W3Cのドキュメントを翻訳したものですが、 出来るだけ原文に近いように、極端な意訳を避け、原文に近い表現になるように心がけたつもりです。 また、出来るだけわかり易くするため、 ところどころに "翻訳注" として注釈を追加しました。 この仕様書の標準は、W3Cの英語のパージョンです。 誤訳や意味の取り違え等の可能性は十分あり得ます。お気づきの点等ありましたら、 山下宛メール(yamashita_t@infoseek.jp)でお知らせ下さい。

このセクションは、このドキュメントの公表時における、このドキュメントのステータスについて記述します。 なお、別のドキュメントが、このドキュメントに取って代わるかもしれません。 このドキュメント・シリーズの最新のステータスは、W3Cで支持されます。

このドキュメントは、W3Cのメンバーおよび他の利害関係者によって再審理され、 W3C推薦(W3C Recommendation)として管理者によって推奨されました。 このドキュメントは、永続性のあるドキュメントで、 参照資料として使用されるか、あるいは、 別のドキュメントからの標準の参照として引用されるかもしれません。 推薦をすることにおけるW3Cの役割は、仕様書に注意を引き付けて、 その広範囲の配備を促進することです。 これは、機能性およびウェブの相互運用を増強します。

このドキュメントは、 W3C HTMLの活動(W3C HTML Activity) の一部として作成されました。 HTML Working Group (メンバーのみ) の目標は、 HTML Working Group 憲章 (メンバーのみ)内で議論されます。

現在のW3C推薦(W3C Recommendations)および他の技術文書のリストは、 http://www.w3.org/TRで見つけることができます。

HTMLの特徴に関する公の議論は、メーリング・リスト www-html@w3.org (アーカイブ)上で行なわれます。

このドキュメントにおけるエラーを、 www-html-editor@w3.org に報告して下さい。

この仕様書における既知のエラーのリストは、 http://www.w3.org/2000/01/REC-xhtml1-20000126-errata で利用可能です。

内容

1. XHTML とは何か?

XHTMLは、 現在と未来のドキュメントの型式に属するファミリーで、 HTML 4 [HTML] を再生し、部分集合化し、拡張するモジュールです。 XHTMLファミリーのドキュメントの型式は、 XML に基づき、 根本的には、XML に基づいたユーザ・エージェントと共に働くように設計されています。 このファミリーおよびファミリーの展開の詳細は、 将来の方向 についてのセクションで、より詳細に論じられます。

XHTML 1.0(この仕様)は、XHTMLファミリーにおいて最初のドキュメントの型式です。 XHTML 1.0 は、XML 1.0[XML] の適用としての3つの HTML 4 ドキュメント型式の再公式化です。 それは、内容が、XML 適合のみならず、 基本的なガイドラインに従う場合、 ユーザ・エージェントが従う HTML 4 において効果を表わすための文法として使用されるように意図されています。 XHTML 1.0 へ内容を移行する開発者は、次の利益を得るでしょう:

XHTMLファミリーは、インターネットの発展の次のステップです。 今日の XHTML に移行することによって、コンテンツ開発者は、 今までどおりそれらの内容の過去と将来の互換性に確信をもち続けたまま、 その付随する利益のすべてとともに、XML の世界に参加する事ができます。

1.1 HTML 4 とは何か?

HTML 4 [HTML] は、 国際標準の ISO 8879 に適合する SGML (標準一般化マークアップ・ランゲージ) のアプリケーションで、ワールド・ワイド・ウェブの標準的な発行文法と広く見なされています。

SGML は、 特に電子ドキュメント交換、 ドキュメント管理、および、 ドキュメント発行において使用するマークアップ・ランゲージを記述するための文法です。 HTML は、SGML において定義された文法の例です。

SGML は、およそ1980年代中盤から 、全く安定して存続しています。 この安定の多くは、文法が特徴豊富で柔軟であるという事実から生じます。 しかしながら、この柔軟性は代価を生じ、 その代価は、ワールド・ワイド・ウェブを含む様々な環境でその採用を妨げた複雑な水準です。

HTML は、元来考えられていたこととして、 科学的かつ他の技術文書(非文書専門家による使用にふさわしい)の交換用の文法であることでした。 HTML は、 比較的単純なドキュメント作成にふさわしい構造と意味的なタグのわずかなセットの指定により、 SGML の複雑な問題に取り組みました。 ドキュメント構造の単純化に加えて、HTML は、ハイパーテキストのサポートを加えられました。 マルチメディアの能力は、その後加えられました。

非常に短い期間の間に、HTML が、急激にポピュラーになり、急速にその元来の意図より大きくなりました。 HTML の当初から、HTML (標準としての)内の使用に適し、 HTML を縦断し、高度な専門化と、マーケットに順応する為の、 新しい要素の迅速な発明がされています。 この多くの新しい要素は、異なるプラットフォームにまたがるドキュメントに対する互換性の問題に結びつきました。

ソフトウェアおよびプラットフォームの両方の異種の急速な増加につれて、 これらのプラットフォーム上の使用にとって '模範的な' HTML 4 の適応性が、 多少制限されたことは明らかです。

1.2 XML とは何か?

XMLは、 Extensible Markup Language を表す簡略表記法で、 Extensible Markup Language [XML] の頭文字です。

XML は、SGML のその複雑さの大部分なしに、 能力と柔軟性を取り戻す手段として作られました。 SGML の書式の制限ですが、XML は、 それでもなお、ほとんどの SGML の能力と豊かさを保持します。 また、そのうえにさらに、SGML の一般に使用される特徴のすべてを維持します。

これらの有益な特徴を保持すると同時に、 XML は、 創作および適切なソフトウェアの設計を、 難しく、犠牲の大きいものにする SGML の、 より複雑な特徴の多くを削除します。

1.3 何の為に XHTML を必要とするのか ?

XHTML 1.0 に移行する利益は上に記述されています。 一般に XHTML に移行する利益のうちのいくつかは次のとおりです:

2. 定義

2.1 用語法

次の用語は、この仕様書の中で使用されます。 これらの用語は、ISO/IEC 9945-1:1990 [POSIX.1] の同様の定義に基づいた方法で、 [RFC2119] の定義を拡張しました:

Implementation-defined 実行定義
値、あるいは、動作が、 正確なドキュメントの組立のための必要条件に適合する定義[およびドキュメント]の実行をすることを任される場合の Implementation-defined です。
May
実装に関して、単語 "may" は、 この仕様書において、要求されないが提供することができる、 オプションの特徴として解釈されること。 ドキュメント準拠(Document Conformance)に関しては、 単語 "may" は、オプションの特徴が使用されてはならない事を意味します。 用語 "オプション" は、"may"と同様の定義を持っています。 (翻訳注:"してもさしつかえありません"という形で翻訳してあります)
Must
この仕様書において、 単語 "must" は、 実装に対して、あるいは、厳密に言えば、XHTMLドキュメントを適合させる事に対して、 文章の前後関係により、必須の要件として解釈されること。 用語 "shall" は、"must"と同様の定義を持っています。 (翻訳注:"しなければなりません"という形で翻訳してあります)
Reserved 留保された
値、あるいは、動作が、指示してない事ですが、 ドキュメントを適合させることのために使用されることも許可されませんが、 ユーザ・エージェントを適合させることのためにサポートされることもありません。
Should
実装に関して、単語 "should" は、 要件ではなく、実装の推奨として解釈されること。 ドキュメントに関しては、単語 "should" は、 ドキュメントおよび厳密に言えば XHTMLドキュメントを適合させる事に対して、 推奨されたプログラミングの実地として解釈されること。 (翻訳注:"したほうがよい"という形で翻訳してあります)
Supported サポートされた
この仕様書において、ある程度の機能は、オプションです。 もし機能がサポートされるなら、この仕様書で指定されるように作用します。
Unspecified 無指定
値、あるいは、動作が、指示してない場合、 仕様は、 機能を使用するドキュメントを直視した時でさえ、 実装における機能に対する軽便な要件を定義しません。 その機能を使用する場合、任意の動作を寛大に取り扱うより、 このような事例で明確な動作を要求するドキュメントは、 厳密に言えば XHTMLドキュメントに適合するものではありません。

2.2 一般的な用語

Attribute 属性
属性は、DTD の中で宣言された要素へのパラメーターです。 属性のタイプ、および、可能なデフォルト値を含む値の範囲は、DTD に定義されます。
DTD
DTD、すなわち、ドキュメント型定義(document type definition)は、XML の宣言のコレクションで、 コレクションとして、DTD に応じるドキュメントの使用に利用可能な、 正当な構造、要素、および属性 を、定義します。
Document ドキュメント
ドキュメントは、データの流れで、 ドキュメントが参照する別の流れと結合した後に、 関連する DTD において定義されるように編制される 要素 内で含まれる情報を保持するようなものとして組み立てられます。 さらに多くの詳細に関しては、 ドキュメント適合(Document Conformance) を参照して下さい。
Element 要素
要素は、 DTD において宣言されたユニットを組み立てるドキュメントです。 要素内容のひな形は、DTD に定義され、追加の意味付けは、要素の散文記述に定義され得ます。
Facilities 機能
機能性(Functionality)は、 要素属性、および、 それらの要素属性 に関連付けられた意味付けを含んでいます。 その機能性(Functionality)をサポートする実装は、必要な機能(facilities)を提供すると言われています。 (翻訳注:facilitiesは、便宜をはかるための設備、施設、機関、機能という意味です。)
Implementation 実装
実装は、 この仕様書をサポートする機能(facilities) とサービスのコレクションを提供するシステムです。 さらに多くの詳細に関しては、 ユーザ・エージェントの適合(User Agent Conformance) を参照して下さい。
Parsing 解析
解析は、ドキュメント が入念に調べられる行為です。 また、ドキュメント 内に含まれている情報は、 情報が組み立てられる要素 の状況までろ過されます。
Rendering 表現
表現は、ドキュメント 内の情報が表示される行為です。 この表示は、環境(例;聴覚、視覚、プリントにおいて)に最も適切な形で終了します。
User Agent ユーザ・エージェント
ユーザ・エージェントは、XHTMLドキュメントの検索および処理の実装 です。 さらに多くの詳細に関しては、 ユーザ・エージェントの適合(User Agent Conformance) を参照して下さい。
Validation 確認
確認は、ドキュメントが、 構造、要素 の使用、および、属性 の使用が、DTD の中の定義と適合するということを保証して、 関連するDTD 対して検証される処理です。
Well-formed 適正形式
ドキュメントは、 XML 1.0 推奨 [XML]セクション2.1 において定義された規則に従って組み立てられる場合の適正形式です。 基本的に、この定義では、開始タグと終了タグによって範囲が定められた要素が、 お互いの範囲内で適切に入れ子にされるということを明言します。

3. XHTML 1.0 の標準定義

3.1 ドキュメントの適合

XHTMLのこのバージョンは、 XHTMLドキュメント(XHTMLのネーム・スペースからの、タグおよび属性に制限される)を、 厳密に適合させる定義を提供します。 例えば、XHTMLドキュメントの範囲内で RDF(Resource Description Format) の中で表現されたメタデータを含む場合などの、 別のネーム・スペースを備えたXHTMLの使用についての情報に関しては、 セクション3.1.2 を参照して下さい。

3.1.1 厳密に適合するドキュメント

厳密に適合するXHTMLドキュメントは、 この仕様書において義務的なものと記述された機能だけを要求するドキュメントです。 そのようなドキュメントは、次の基準をすべて満たさなければなりません:

  1. 付録 Aにおいて見つけた3つのDTDのうちの1つに対し、 有効でなければなりません。

  2. ドキュメントの根要素は、<html> でなければなりません。

  3. ドキュメントの根要素は、xmlns の属性 [XMLNAMES] を使用する XHTML のネーム・スペースを指定しなければなりません。 XHTML 用のネーム・スペースは、http://www.w3.org/1999/xhtml であると定義されます。

  4. ドキュメント内で、根要素に優先して、DOCTYPE 定義がなければなりません。 DOCTYPE 定義に含まれた公の識別子は、それぞれの公式な PUBLIC の識別子を使用した、 付録 Aで見つかる3つの DTD の内の1つを参照しなければなりません。 システムの識別子は、ローカル・システムの約束事を反映するために変更されてもさしつかえありません。

    (翻訳注:システムの識別子は、例えば、下記の "DTD/xhtml1-strict.dtd" 等の DTD ファイルを直接指定している部分です。 なお、下記の場合、ドキュメントのあるディレクトリーの下の DTD ディレクトリーに DTD ファイルが置いてなければなりません。)

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

ここに、最小のXHTMLドキュメントの例があります。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html 
     PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" lang="ja">
  <head>
    <title>仮想図書館</title>
  </head>
  <body>
    <p><a href="http://vlib.org/">vlib.org</a>へ移動。</p>
  </body>
</html>

この例において、XML 宣言が含まれることに注意して下さい(翻訳注:先頭の '<?xml' で始まる部分)。 上記のもののようなXML 宣言は、すべてのXML ドキュメント中で要求されませんが、 XHTMLドキュメントの著者は、すべてのドキュメントの中でXML 宣言を使用するように強く奨励されます。 このような宣言は、 ドキュメントの文字符号づけが、デフォルトの UTF-8 か UTF-16 以外である場合、必要とされます。

翻訳注:UTFは、UCS(普遍的文字集合)変換フォーマットの略で、UTF-8は、[RFC 2279]で、UCS-2(別名Unicode、1文字16ビット)かUCS-4の文字集合で8ビット単位の可変長に変換する文字符号化機構として定義してありますが、 UTF-16 に関しては、IANA の文字集合の定義 ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets の中で見つける事ができません、 ISO/ITC 10646で符号化文字集合に対する符号化機構として定義してある、主に、XML を処理するアプリケーション内部で使用されるものです。

3.1.2 別のネーム・スペースを備えたXHTMLの使用

XHTML のネーム・スペースは、[XMLNAMES]によって、 別のネーム・スペースに対して使用されてもさしつかえありません。 しかし、そのようなドキュメントは、 上記に定義されたほど厳密に適合するXHTML 1.0のドキュメントではありません。 W3Cによる次の作業は、 多くの部分から成るネーム・スペースを必要とするドキュメントのための適合を、 指定する方法を扱うつもりです。

次の例は、XHTML 1.0 が、MathML 推薦(MathML Recommendation)と共に使用されることができる方法を示します:

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" lang="ja">
  <head>
    <title>数学上の例</title>
  </head>
  <body>
    <p>以下のものは、MathML のマーク付けです:</p>
    <math xmlns="http://www.w3.org/1998/Math/MathML">
      <apply> <log/>
        <logbase>
          <cn> 3 </cn>
        </logbase>
        <ci> x </ci>
      </apply>
    </math>
  </body>
</html>

次の例は、XHTML 1.0マーク付けが、別の XML のネーム・スペースへ組み入れられることができる方法を示します:

<?xml version="1.0" encoding="UTF-8"?>
<!-- 最初は、デフォルトのネーム・スペースは、"books"です -->
<book xmlns='urn:loc.gov:books'
    xmlns:isbn='urn:ISBN:0-395-36341-6' xml:lang="ja" lang="ja">
  <title>いくらでも安い</title>
  <isbn:number>1568491379</isbn:number>
  <notes>
    <!-- HTMLを、ハイパーテキスト注釈のためにデフォルトのネーム・スペースにします -->
    <p xmlns='http://www.w3.org/1999/xhtml'>
        これは、さらに <a href="http://www.w3.org/">オンライン</a> で利用可能です。
    </p>
  </notes>
</book>

3.2 ユーザ・エージェントの適合

適合するユーザ・エージェントは、次の基準をすべて満たさなければなりません:

  1. XML 1.0推薦 [XML] と矛盾しないために、 ユーザ・エージェントは、適正形式の状態に XHTMLドキュメントを解析し評価しなければなりません。 もし、ユーザ・エージェントが、批准するユーザ・エージェントであることを主張するならば、 さらに [XML] に従ってユーザ・エージェントの参照が付けられた DTD に対するドキュメントを、 有効にしなければなりません。
  2. ユーザ・エージェントが、この仕様書内に定義されたか、あるいは、標準に従う参照によって、 この仕様書で要求された 機能 をサポートすることを主張する場合、 それは機能の定義と矛盾しない方法で、そのように実行しなければなりません。
  3. ユーザ・エージェントが、一般的な XML として XHTMLドキュメントを処理する場合、 型 ID の属性(例.たいていのXHTML要素に関する id 属性)を、 断片識別子(fragment identifiers)として認めるだけでなければなりません。
  4. もし、ユーザ・エージェントが、認識しない要素に遭遇したなら、 ユーザ・エージェントは、要素の内容を表現しなければなりません。
  5. もし、ユーザ・エージェントが、認識しない属性に遭遇したなら、 ユーザ・エージェントは、属性の詳述全体(つまり属性およびその値)を無視しなければなりません。
  6. もし、ユーザ・エージェントが、認識しない属性値に遭遇したならば、 ユーザ・エージェントは、デフォルトの属性値を使用しなければなりません。
  7. もし、ユーザ・エージェントが、 宣言にない処理をする実体参照(あらかじめ定められた実体以外のもの)に遭遇したならば、 (宣言が、ユーザ・エージェントが読んでいない外部のサブセットの中にある場合起こります)、 実体参照は、実体参照する文字符号(アンパサンドで始めて、半コロンで終わって)として表現されたほうがよい (翻訳注:この文章は、should を使用した文章です)。
  8. 内容が表現される時、 認識されるが、表現可能でない、文字符号か、文字符号の実体参照に遭遇したユーザ・エージェントは、 正常な表現が行われていないことがユーザにとって理解しやすいように、 ドキュメントを表示したほうがよい(翻訳注:この文章は、should を使用した文章です)。
  9. 次の文字符号は、[XML]において、ホワイト・スペースの文字符号として定義されます:

    XML を処理するものは、異なるシステムの行終了コードを、 単一の行送りの文字符号(アプリケーションまで渡される)に統一します。 XHTMLのユーザ・エージェントは、 さらに、ホワイト・スペースとして、 次の文字符号を扱わなければなりません。

    要素において、'xml:space'の属性は、'preserve'(翻訳注:維持)に設定され、 ユーザ・エージェントは、すべてのホワイト・スペースをそっくりそのままの状態にしておかなければなりません。 そうでなければ、ホワイト・スペースは次の規定に従って扱われます:

    属性値内のホワイト・スペースは、 [XML] に従って処理されます。

4. HTML 4 との相違点

XHTMLが、XML のアプリケーションであるという事実により、SGML ベースの HTML 4 [HTML] において完全に有効だった、ある特定の慣習は、変更されなければなりません。

4.1 ドキュメントは、適正形式(well-formed)でなければならない

適正形式状態(Well-formedness)は、 [XML] で取り入れられた新しい概念です。 本質的に、すべての要素が閉じるタグを持っているか、 特別な形式(下に記述されたような)で書かれなければならず、 また、すべての要素が、入れ子にされなければならない事を意味します。

オーバーラップは、SGML において違法ですが、既存のブラウザーにおいて広く許容されました。

正しい: 入れ子になった要素。

<p>ここに強調された<em>節</em>があります。</p>

間違い: オーバーラップしている要素

<p>ここに強調された <em>節があります。</p></em>

4.2 要素と属性の名前は、小文字でなければならない

XHTMLドキュメントでは、すべてのHTML要素と属性の名前に対して小文字を使用しなければなりません。 この相違点は、XML がケース敏感(翻訳注:大文字・小文字を区別する)なので必要です。 例.<li> と <LI> は異なるタグです。

4.3 内容のある要素(non-empty elements)に対して、終了タグが要求されます

SGMLベースの HTML 4 では、ある特定の要素が、終了タグを省略することを許されました; 要素にとっては、必然的に、終止を含むことになります。 この省略は、XML ベースの XHTML の中で許されません。 EMPTY として DTD において宣言された要素以外の全ての要素は、 終了タグがなければなりません。

正しい: 終了した要素

<p>ここに、段落があります。</p><p>ここに、別の段落があります。</p>

間違い: 終了していない要素

<p>ここに、段落があります。<p>ここに、別の段落があります。

4.4 属性値は、常に引用されなければならない

属性値は、数値と思われるものでさえ、すべて引用されなければなりません。 (翻訳注:引用符で囲まなければなりません)

正しい: 引用された属性値

<table rows="3">

間違い: 引用されていない属性値

<table rows=3>

4.5 属性の最小化

XML は、属性の最小化をサポートしません。 属性値のペアは、全部書かれなければなりません。 compactchecked のような属性名は、 指定されている値なしに要素内で生じることができません。

翻訳注:HTML 4では、値が省略可能で、属性名だけを指定すればいい属性があります。さらに詳しい説明は、 この仕様書の 付録. C にあります。

正しい: 最小化されていない属性値

<dl compact="compact">

INCORRECT: 最小化された属性

<dl compact>

4.6 内容の無い要素(Empty Elements)

内容の無い要素要素は、終了タグがあるか、開始タグが /> で終了するか、 どちらかでなければなりません。例えば、 <br/> あるいは、 <hr></hr>。 これが、HTML 4 のユーザ・エージェントと、後方互換性をもつことを保証する方法についての情報に関しては、 HTML互換性ガイドライン(HTML Compatibility Guidelines) を参照して下さい。

正しい: 終了した内容の無い要素

<br/><hr/>

間違い: 終了しない内容の無い要素

<br><hr>

4.7 属性値内のホワイト・スペースの取り扱い

属性の値においては、ユーザ・エージェントが、1つ以上のホワイト・スペース文字(行区切りを含んで)の属性値、 および、マップ・シーケンスから、先行するホワイト・スペースと後に引くホワイト・スペースを、 1つの単語間のスペース(欧米の書体用のASCIIスペース文字)になるまで取り去ります。 [XML]セクション3.3.3 を参照して下さい。

4.8 スクリプト要素とスタイル要素

XHTMLでは、スクリプト要素とスタイル要素が、#PCDATA の内容を持っているように宣言されます。 その結果、<& は、 マーク付けの開始として扱われます。 また、&lt;&amp; のような実体は、 XML プロセッサーによって、それぞれ <& の実体参照と認められます。 CDATA の明白な部分内で、スクリプト要素か、スタイル要素の内容を包むことで、 これらの実体の展開を回避します。
(翻訳注:#PCDATA では、普通のテキストと同じ扱いになります。CDATA は、 文書文字セットによる文字集合として定義されているので、例えば、スクリプト内で、演算子として <& を使用しても問題ありませんが、 #PCDATA 内では、演算子として使用できません。 ちなみに、スクリプト要素とスタイル要素は、XML・XHTMLでは、#PCDATA として、 HTMLでは、CDATA としてそれぞれのDTDに宣言してあります。)

<script>
 <![CDATA[
 ... 回避しないスクリプトの内容 ...
 ]]>
 </script>

CDATA の部分は、XML プロセッサーによって認識され、 ドキュメント・オブジェクト・モデル内のノードとして現れます。 DOMのレベル1推奨[DOM] セクション1.3を参照して下さい。

代案は外部スクリプトおよびスタイル・ドキュメントを使用することです。

4.9 SGMLの排除

SGMLは、DTDの著者に、要素内に含まれるものから特定の要素を除外する能力を与えます。 そのような禁止("exclusions"[排除]と呼ばれた)は、XML において可能ではありません。

例えば、HTML 4 の 厳密なDTD(Strict DTD) は、 'a' 要素の入れ子を、別の 'a' 要素のどんな子孫の深さの範囲内でも禁止します。 XML の中のそのような禁止を、完全に綴ることは可能ではありません。 たとえ、DTD にこれらの禁止を定義することができなくても、ある一定の要素は入れ子にされないほうがよく。 そのような要素、および、それらの中で入れ子にされないほうがよい要素の要約は、標準の 付録B(Appendix B)で見つかます。

4.10 'id' 属性と 'name' 属性を備えた要素

HTML 4 は、 'a'、 'applet'、 'form'、 'frame'、 'iframe'、 'img'、 および 'map' に対して 'name' の属性を定義しました。 さらに、HTML 4 は、'id' の属性を導入しました。 これらの属性は両方とも、 断片識別子(fragment identifiers) として使用されるように設計されています。

XML では、断片識別子が、型 ID であり、 1つの要素当たり、たった1つの型 ID の属性であることだけができます。 したがって、XHTML 1.0では、'id' 属性は、型 ID であると定義されます。 XHTML 1.0 の文書が、適正構造化(well-structured) した XML ドキュメントであることを保証する目的で、 XHTML 1.0 の文書は、断片識別子を定義する場合、歴史的な 'name' 属性を持っている要素ですら、 'id' の属性を使用しなければなりません。 そのようなアンカー(翻訳注:'name' 属性を持つ 'a'要素)が、 後方互換性をもつことを保証することについての情報に関しては、 HTML互換性ガイドライン(HTML Compatibility Guidelines) を参照して下さい。

XHTML 1.0では、これらの要素の 'name' 属性が、 公式に非難されたので、 XHTMLの後のバージョンにおいて、 削除するつもりであるということに注意して下さい。

5. 互換性の問題

既存のユーザ・エージェントと互換性がある XHTML 1.0 のドキュメントに対しての要求がありませんが、 実際上、これを遂行することは容易です。 互換性をもつドキュメントを作成するためのガイドラインは、 付録C(Appendix C) で見つけることができます。

5.1 インターネットのメディア・タイプ

この推薦の発行時点では、XML に基づいた適用のために、 一般的な推奨された MIME のラベル付けは、さらに解決されなければなりません(翻訳注:"have to"の文章)。

しかしながら、 付録C(Appendix C) "HTML互換性ガイドライン" の中で述べられたガイドラインに従う XHTML のドキュメントは、 それらがほとんどの HTMLブラウザーと互換性をもつように、 インターネットのメディア・タイプ "text/html" を用いてラベル付けされてもさしつかえありません。 このドキュメントは、他の XHTMLドキュメントをラベル付ける MIME についての推奨をしません。

6. 将来の方向

XHTML 1.0 は、モジュールの定義と、こられのモジュールを組合せる為のメカニズムを指定することにより、 広範囲の新しい装置およびアプリケーションをサポートする目的で、 XHTMLを拡張し部分集合化(subset)するドキュメント・タイプに属するファミリーの基準を提供します。 このメカニズムは、新しいモジュール(基本単位)の定義を通して均一の方法の XHTML 1.0 の拡張と下位設定(sub-setting)を可能にします。

6.1 HTMLのモジュール化

XHTML の使用が、従来のデスクトップのユーザ・エージェントから、別のプラットフォームへの移行のように、 すべての XHTML 要素が、すべてのプラットフォーム上で要求されるとは限らないことは明らかです。 例えば、手に保持する装置、あるいは、携帯電話が、 XHTML 要素の部分集合だけをサポートしてもさしつかえありません。

モジュール化のプロセスは、一連のより小さな要素のセットに XHTML を分解します。 その後、これらの要素は、異なるコミュニティーの必要を満たすために再結合することができます。

これらのモジュールは、後ほど、W3C のドキュメントにおいて定義されます。

6.2 部分集合と拡張性

モジュール化は、いくつかの利点をもたらします:

6.3 ドキュメント・プロフィール

ドキュメント・プロフィールは、ドキュメントのセットに関して統語論(syntax)と意味論(semantics)を指定します。 ドキュメント・プロフィールへの適合は、相互運用の保証に根拠を提供します。 ドキュメント・プロフィールは、 ドキュメント・タイプを処理するのに必要な機能、 例えば、そのイメージ・フォーマットが、使用することができるスクリプトを書くレベル、スタイル・シートのサポートなど、 を指定します。

製品デザイナーについては、様々なグループが、 これによってグループ自身の標準プロフィールを定義することができます。

著者にとって、これは、異なるクライアントのために、 いくつかの異なるバージョンのドキュメントを書くことの必要性を除去します。

化学者、医学の医者あるいは数学者のような特別のグループについては、 これは、特別のプロフィールが、 専門家のニーズに適応した要素のグループと標準の HTML 要素を使用して構築されるのを可能にします。

付録A. DTD

この付録は標準です。

これらのDTDと実体のセットは、この仕様書の標準の部分を形成します。 XML の宣言、および、SGML Open Catalog ならびに DTDファイルの完全なセットは、この仕様書用の zip ファイルに含まれています。

A.1 ドキュメント型定義

これらのDTDは、HTML 4 の DTD に近づきます。 DTDが、モジュール化された場合、DTD構築の方法が、HTML 4 により親密に一致して使用されます。

翻訳注:厳密バージョンのみ、DTDファイルのコメント部分を邦訳しました。 ちなみに、ENTITY が属性がとる値の定義で、ELEMENT が要素、 ATTLIST がその要素がもつ属性の定義のリストです。有用な情報がコメントされているので、 いちど目を通しておく事をお勧めします。

A.2 実体のセット

XHTML実体セットは、HTML 4に関しては同じであるが、有効な XML 1.0 実体宣言であるように修正されました。 ユーロ・マネーの記号(&euro;&#8364; あるいは &#x20AC;) のために、実体が、 例外的な文字符号の一部として定義されることに注意して下さい。

付録B.要素の禁止

この付録は標準です。

次の要素は、それらがどの要素を含むことができるかの禁止を行っています (セクション4.9を参照)。 この禁止は、すべての入れ子の深さに適用され、つまり、子孫要素をすべて含みます。

a
他の a 要素を含むことができません。
pre
img, object, big, small, sub あるいは sup 要素を含むことができません。
button
input, select, textarea, label, button, form, fieldset, iframe あるいは isindex 要素を含むことができません。
label
他の label 要素を含むことができません。
form
他の form 要素を含むことができません。

付録C. HTML互換性ガイドライン

この付録は、有益です。

この付録は、 既存のユーザ・エージェント上で描写するためのXHTMLドキュメントを望む著者のために、 設計ガイドラインを要約します。

C.1 処理指示

処理指示が、いくつかのユーザ・エージェント上で描写されることに気づいて下さい。 しかしながら、さらに、XML 宣言が、ドキュメントに含まれていない場合、 ドキュメントが、デフォルト文字符号づけ UTF-8 あるいは UTF-16 のみを使用することができることに注意して下さい。
(翻訳注:UTFは、UCS(普遍的文字集合)変換フォーマットの略で、UTF-8は、[RFC 2279]で、UCS-2(別名Unicode、1文字16ビット)かUCS-4の文字集合で8ビット単位の可変長に変換する文字符号化機構として定義してありますが、 UTF-16 に関しては、IANA の文字集合の定義 ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets の中で見つける事ができません、 ISO/ITC 10646で符号化文字集合に対する符号化機構として定義してある、主に、XML を処理するアプリケーション内部で使用されるものです)。

C.2 内容の無い要素

スペースを前に含んでいる / を後に引く、内容の無い要素の >、例えば、 <br />, <hr /> および <img src="karen.jpg" alt="Karen" />。 また、 内容の無い要素のための最小限のタグ構文の使用、例えば、<br />、 代替構文として <br></br> は、 多くの既存のユーザ・エージェントのあやふやな結果を認める XHL によって許可されました。

C.3 要素の最小化 および 内容の無い要素 の内容

内容モデルが、EMPTY でない要素の内容の無い実体(例えば、内容の無いタイトルか段落)がある場合、 最小化形式を使用しないで下さい (例. <p /> ではなく <p> </p> を使用)。

C.4 埋め込まれたスタイル・シートおよびスクリプト

あなたのスタイル・シートが、<&]]> あるいは -- を使用する場合、外部のスタイル・シートを使用して下さい。 あなたのスクリプトが、<&]]> あるいは -- を使用する場合、外部のスタイル・シートを使用して下さい。 XML パーザが、暗黙にコメントの内容を削除することを許されることに注意して下さい。 したがって、ドキュメントの後方互換性に役立つコメントの内に"隠すこと"のスクリプトおよびスタイル・シートの歴史的な慣例は、 XML ベースの実装では予想通りに働きません。

C.5 属性値内の改行

属性値内の改行、および、多様なホワイト・スペースの文字符号を回避して下さい。 これらは、ユーザ・エージェントによって矛盾して扱われます。

C.6 isindex

ドキュメントの head に、1つ以上の isindex 要素を含めないで下さい。 isindex 要素は、input 要素の支持のために、不支持を唱えられました。 (翻訳注:isindex 要素は、一行プロンプトで、 ヘッド部に記述し、入力フィールド等を表示実行指定するのに使用しました。 現在は、推移バージョンに含まれていますが、将来的には削除される予定です)

C.7 langxml:lang 属性

要素の言語を指定する場合、lang および xml:lang 属性の両方を使用して下さい。 xml:lang 属性の値は、優先して用いられます。
(翻訳注:一番知りたいのは、どう違うかなのですが... lang は、後方互換性の為のもので、 xml:lang は、XML 1.0 専用のものです)

C.8 断片識別子 (Fragment Identifiers)

(翻訳注:下記の説明は、a 要素を目標アンカーとして使用する場合のものです) XML において、 形式 "#foo" の断片識別子で終わる URIs [RFC2396] は、属性 name="foo" を備えた要素を参照しません; もっと正確に言えば、それらは、型 ID であると定義された属性 (例えば、HTML 4 の id 属性)を備えた要素を参照します。 多くの既存の HTMLクライアントは、この方法で ID 型の属性の使用をサポートしません。 そこで、同一の値が、最大限の前方と後方互換性を保証するため、これらの属性の両方に与えられてもさしつかえありません。 (例、<a id="foo" name="foo">...</a>)。

さらに、型 ID の属性に対する合法な値のセットが、型 CDATA のもののためによりもはるかに小さいので、 name 属性の型は、NMTOKEN に変更されました。 この属性は、型 ID と同じ値だけを持つことができるようなもの、 あるいは、XML 1.0 の セクション2.5 production 5 における Name の成果として、 抑制されます。 遺憾ながら、この制約は、XHTML 1.0 の DTD において表現することができません。 この変更のために、既存の HTMLドキュメントを変換する場合、注意する必要があります。 これらの属性の値は、ドキュメントの範囲内でユニークでなければなりません、 これらの断片識別子(内部と外部の両方)へのどんな参照でも、万一、値が変換する時に変更されるならば、 更新される必要があります。

翻訳注:NMTOKENID などの型の定義に関しては、 XML 1.0 仕様書 [XML] の セクション 3.3.1 "Attribute Types" に、 詳細の記述があります。

最後に、XHTML 1.0 では、 a, applet, form, frame, iframe, img, と map の要素の name 属性に反対を唱えており、 name 属性は、後のバージョンにおいて、XHTML から取り除かれるでしょう。

C.9 文字符号付け

ドキュメント中の文字符号付けを明記するため、 xml 宣言上の符号付け属性の詳述 (例. <?xml version="1.0" encoding="EUC-JP"?>) と、'meta http-equiv' の構文 (例. <meta http-equiv="Content-type" content='text/html; charset="EUC-JP"' />) の両方を使用します。 xml 処理指示の符号づけ属性の値は、優先して用いられます。

C.10 ブール(Boolean)の属性

いくつかの HTML のユーザ・エージェントは、 ブールの属性が、XML 1.0によって求められるような、 正式の形式(最小化にされない)で現れる場合、ブールの属性を解釈することができません。 この問題が、HTML 4 に従順なユーザ・エージェントに、影響しないことに注意して下さい。 次に続く属性が関係します: compact, nowrap, ismap, declare, noshade, checked, disabled, readonly, multiple, selected, noresize, defer

翻訳注:セクション 4.5 属性の最小化 で説明してあることの補足です。 なお、HTML 4 に適合しているユーザ・エージェントでは、上記のものに対する対策が施されている筈です。

C.11 ドキュメント・オブジェクト・モデル と XHTML

ドキュメント・オブジェクト・モデル レベル1推薦[DOM]は、 XML と HTML 4 のドキュメント・オブジェクト・モデル・インターフェースを定義します。 HTML 4 のドキュメント・オブジェクト・モデルは、HTML の要素名と属性名が、大文字で返されることを明示します。 XML のドキュメント・オブジェクト・モデルは、要素名と属性名が、明示されたケース (翻訳注:大文字は大文字で、小文字は小文字で)で返されることを明示します。 XHTML 1.0 では、要素と属性が、小文字で指定されます(翻訳注:このことの詳細は、セクション 4.2 を参照して下さい)。 この明白な違いは、2つの方法で扱うことができます:

  1. XHTMLドキュメントにアクセスするアプリケーションは、 DOM 経由で、 インターネット・メディア・タイプ text/html が、 HTML の DOM を使用でき、 そのインターフェースから、要素名と属性名が大文字で返されることを当てにできるものとして取り扱います。
  2. また、XHTMLドキュメントにアクセスするアプリケーションは、 インターネット・メディア・タイプ text/xml あるいは application/xml が、 XML の DOM を使用することができるものとして取り扱います。 要素と属性は、小文字で返されます。さらに、XHTML の要素は、 XHTML の要素が、内容モデルにおいてオプションなので、 オブジェクト・ツリーに現われるか、現われないかもしれません(例.table 内の tbody 要素)。 これが生じるのは、HTML 4 において、いくつかの要素で、 開始タグと終了タグが両方とも省略されるような(SGMLの特徴)、 最小化にされる事を許されたからです。 これは、XML において可能ではありません。 無関係な要素を挿入する事をドキュメントの著者に要求するのではなく、 XHTML では、要素をオプションにしました。 アプリケーションは、これに従って適合する必要があります。

C.12 属性値の中でアンパサンドを使用すること

属性値がアンパサンドを含んでいる場合、 それは文字実体参照(例. "&amp;")として表現されなければなりません。 例えば、a 要素の href 属性が、 パラメーターをとるCGIスクリプトを参照する時は、 http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user としてより、 http://my.site.dom/cgi-bin/myscript.pl?class=guest&amp;name=user として表現されなければなりません。

C.13 カスケーディング・スタイル・シート(CSS) と XHTML

カスケーディング・スタイル・シート・レベル2 推薦 [CSS2] は、 HTML か XML のドキュメントの解析ツリーに適用されるスタイルのプロパティを定義します。 解析の差は、使用されたセレクターに依存して、異なる視覚的あるいは聴覚の結果を生じます。 次のヒントは、両方のメディア・タイプとして修正なしで取り扱われるドキュメントのために、この影響を切り詰めます:

  1. XHTML に対する CSS のスタイル・シートは、 要素名と属性名に小文字を使用したほうがよい。
  2. テーブルにおいて、tbody 要素は、HTML のユーザ・エージェントのパーサによって、推測されますが、 XML のユーザ・エージェントのパーサによって推測されません。 したがって、あなたが、tbody 要素を、CSSのセレクターで参照する場合、 常に明白に tbody 要素 を付け加えたほうがよい。
  3. XHTMLのネーム・スペース内では、ユーザ・エージェントが、 "id" 属性を、型 ID の属性として評価すると予想されます。 したがって、スタイル・シートは、 ユーザ・エージェントが、DTDを読まなくても、 記号 "#" のセレクターの構文を使用することを持続できたほうがよい。 (翻訳注:記号 "#" は、id 属性をセレクターとして使用する為、スタイル・シートの中で、 id 属性の値の前に付ける記号です。詳しくは、全文翻訳CSS1セクション 1.5 を参照して下さい。)
  4. XHTML名前スペース内では、ユーザ・エージェントが、"class" 属性を認識すると予想されます。 したがって、スタイル・シートは、記号 "." のセレクターの構文を使用し続けることができたほうがよい。 (翻訳注:記号 "." は、class 属性をセレクターとして使用する為、スタイル・シートの中で、 class 属性の値の前に付ける記号です。詳しくは、全文翻訳CSS1セクション 1.4 を参照して下さい。)
  5. CSSは、HTML と XML のドキュメントのための異なる適合規則を定義します; HTML の規則は、 HTML と XML の規則が、 XML として提供された XHTML のドキュメントに当てあまるのと同様に、 提供された XHTML ドキュメントに適用されることに気づいてください。

付録D. 謝辞

この付録は有益です。

この仕様書は、W3C HTMLワーキンググループのメンバーの参加で書かれました:

Steven Pemberton、CWI (HTML ワーキンググループ議長)
Murray Altheim、サン・マイクロシステムズ
Daniel Austin、AskJeeves (CNET: 1999年7月を通じてのコンピューター・ネットワーク)
Frank Boumphrey、HTML著者ギルド
John Burger、Mitre
Andrew W. Donoho、IBM
Sam Dooley、IBM
Klaus Hofrichter、GMD
Philipp Hoschka、W3C
Masayasu Ishikawa、W3C
Warner ten Kate、フィリップス・エレクトロニクス
Peter King、Phone.com
Paula Klante、JetForm
Shin'ichi Matsui、パナソニック(1999年9月を通じてのW3Cの訪問しているエンジニア)
Shane McCarron、応用試験および技術(1999年8月を通じてのオープン・グループ)
Ann Navarro、HTML著者ギルド
Zach Nies、クォーク
Dave Raggett、W3C/HP(W3CがHTMLのために導く)
Patrick Schmitz、マイクロソフト
Sebastian Schnitzenbaumer、Stack Overflow
Peter Stark、Phone.com
Chris Wilson、マイクロソフト
Ted Wugofski、ゲートウェイ2000
Dan Zigmond、WebTVネットワーク

付録E. 参照

この付録は有益です。

[CSS2]
"カスケーディング・スタイル・シート, レベル 2 (CSS2) 仕様書", Bos, H. W. Lie, C. Lilley, I. Jacobs, 1998年5月12日.
最新のバージョンは、次で利用可能: http://www.w3.org/TR/REC-CSS2
[DOM]
"ドキュメント・オブジェクト・モデル (DOM) レベル 1 仕様書", Lauren Wood その他., 1998年10月1日.
最新のバージョンは、次で利用可能: http://www.w3.org/TR/REC-DOM-Level-1
[HTML]
"HTML 4.01 仕様書", D. Raggett, A. Le Hors, I. Jacobs, 1999年12月24日.
最新のバージョンは、次で利用可能: http://www.w3.org/TR/html401
[POSIX.1]
"ISO/IEC 9945-1:1990 情報技術 - ポータブル・オペレーティング・システム・インターフェース (POSIX) - パート 1: システム・アプリケーション・プログラム・インターフェース (API) [C 言語]", 電気電子協会法人, 1990年.
[RFC2046]
"RFC2046: 多目的インターネット・メール拡張 (MIME) パート 2: メディア・タイプ", N. Freed と N. Borenstein, 1996年11月.
http://www.ietf.org/rfc/rfc2046.txtで利用可能。 この RFC の 旧式の RFC1521, RFC1522, と RFC1590 に注意して下さい。
[RFC2119]
"RFC2119: 要求レベル(Requirement Levels)を示すRFCの中の使用に適したキーワード", S. Bradner, 1997年3月.
次で利用可能: http://www.ietf.org/rfc/rfc2119.txt
[RFC2376]
"RFC2376: XML のメディア・タイプ", E. Whitehead, M. Murata, 1998年7月.
次で利用可能: http://www.ietf.org/rfc/rfc2376.txt
[RFC2396]
"RFC2396: Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter, 1998年8月.
このドキュメントは、RFC1738 と RFC1808 を更新します。
次で利用可能: http://www.ietf.org/rfc/rfc2396.txt
[XML]
"拡張可能なマークアップ・ランゲージ (XML) 1.0 仕様書", T. Bray, J. Paoli, C. M. Sperberg-McQueen, 1998年2月10日.
最新のバージョンが、次で利用可能: http://www.w3.org/TR/REC-xml
[XMLNAMES]
"XML におけるネームスペース", T. Bray, D. Hollander, A. Layman, 1999年1月14日.
XML のネームスペースは、URIによって識別されたネーム・スペースに関連付けて考えることによって、 XMLドキュメントの中で使用される限定的な名前のための単純な方法を提供します。
最新のバージョンが、次で利用可能: http://www.w3.org/TR/REC-xml-names