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


W3CWD-html-in-xml-19990304

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

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

W3Cワーキングドラフト 1999年3月4日

このバージョン[原文]:
http://www.w3.org/TR/1999/WD-html-in-xml-19990304
以前のバージョン:
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会員組織による保証としての意味合いを含むものではないので注意されたい。

この仕様書は最終案内(last call)に入っており、コメントは1999年3月24日より前に求められる。このバージョンのワーキングドラフトは、先のバージョン(2月24日)で検知された2つのエラーを訂正したものである。この2つのエラーとは、frame 要素に src 属性が欠けていたことと、名前空間URIが ".dtd" で終了しており不正だったこととである。

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

コメント

ワーキンググループ内でまだ緩やかに継続しており、我々がそれについて特にコメントを受け取ることに興味のある問題が1つある。我々は新しいインターネットメディア型 "text/xhtml" を登録すべきか否かという問題である。

ごく簡単に言うと、選択肢には2つある。yes - リソースにアクセスすることなく応用型を認識するにはそれが唯一の方法である。no - この問題はすべてのXMLアプリケーションにあるであろうことであり、アプリケーションを一つずつ登録するのでは答えにならない。

HTMLをモジュラ化したり他のXMLターゲットと組み合わせたりするための基礎として文書プロファイルを定義するアイデアに関しては、作業が続いている。第6節「将来的な方向性」を見ること。

この文書に関する詳細なコメントを 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 は、3つの HTML 4.0 DTD に対応して、Strict, Transitional, Frameset という3つの名前空間を規定する。この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を受け入れる能力を持つようには設計されないであろう。

2. 定義集

2.1 用語集

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

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

2.2 一般的な用語

属性 (attribute)
属性とは、DTDで宣言された要素に対するパラメータである。属性の型や値の範囲は、取りうるデフォルト値を含め、DTDで定義される。
DTD
DTD、あるいは文書型定義とは、そのDTDに従う文書で利用できる合法な構造や要素, 属性を集合体として定義する、XML宣言の集合体である。
文書 (document)
文書とは、それが参照する他のすべてのストリームと組み合わされた後、結びつけられたDTDで定義されている通りに組織される要素に包含された情報を保持するよう構築される、データのストリームである。さらなる情報については文書の準拠性を見ること。
要素 (element)
要素とは、DTDで宣言された文書構築単位である。要素の内容モデルはDTDで定義され、追加的な意味論がその要素の散文的記述で定義されることがある。
ファシリティ (facility)
ファシリティとしては、要素, 属性と、それらの要素属性に結びつけられた意味論とがある。その機能をサポートしている実装は、必要なファシリティを用意していると言われる。
実装 (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文書(Strictly Conforming XHTML Document)に関する文書の準拠性を定義するのみである。厳格準拠XHTML文書とは、この仕様書において義務的なものとして記述されているファシリティのみを要求する文書である。そうした文書は、以下の判断基準のすべてに沿うものでなければならない。

  1. 付録Aに見られる3つのDTDのうちの一つに照らして妥当性を有しなければならない。

  2. 文書のルート要素は <html> でなければならない。

  3. 文書のルート要素は、xmlns 属性を使うことにより [XMLNAMES]、定義済みの3つの名前空間のうちの一つを指し示さなければならない。指し示された名前空間は、その文書が妥当性を有するものと主張するDTDの名前空間に一致しなければならない。定義済みの名前空間は、つぎのものである。

  4. ルート要素に先立ってその文書の中には DOCTYPE 宣言がなければならない。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文書は、text/html または text/xhtml というインターネットメディア型でラベルされてもかまわない。text/html としてラベルされたときは、文書は付録Cのうちの4つ目のガイドラインセットに従うべきである。このガイドラインに従い漏らすと、ほぼ確実に、古い実装の上で文書が処理され損なうことになる。

こちらは、最小限の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 文書は整形式でなければならない.

整形式性[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 script 要素および style 要素

XHTMLでは、script 要素や style 要素は #PCDATA 内容をもつものとして宣言される。結果として、&lt;&amp; といった実体は、XMLプロセッサによってそれぞれ <& に展開されることになる。script 要素や style 要素を CDATA マークされた部分の中に包み込めば、これらの実体の展開が避けられる。

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

CDATA 部は、XMLプロセッサによって認識され、文書オブジェクトモデルにおけるノードとして現れる。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 DTD では訂正される。エラッタは [ERRATA] で見ることができる。

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

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

5. 互換性の問題

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

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

XHTML文書を転送するのに使ってよいのは、以下のインターネットメディア型のうちの一つである。これらの型を使って、文書制作者は、汎用的なXMLアプリケーションに対して(text/xml)や、従来のHTMLユーザエージェント(text/html)、新しいXHTMLアプリケーション(text/xhtml)に対して配信できる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 にあるガイドラインに準拠している場合には、text/html というインターネットメディア型を使って転送してもかまわない。もっとも、XHTML文書を text/html として転送すると、2つの点で情報の損失が生じる。

第一に、受信側は、インターネットメディア型からその文書が妥当なXML文書であると主張していることがわからず、そのため、汎用的なXMLツールを使って文書の文法をチェックしたり文書をレンダリングしたりすることができない。ゆえに受信側は、アドホックな様式で HTML 4.0 文法のチェックおよび/または HTML 4.0 意味論のレンダリングをするよう心構えをしておかなければならない。

第二に、受信側は、インターネットメディア型だけからでは、その文書が妥当な XHTML 1.0 文書であると主張していることがわからず、そのため XHTML 文書については要求されるが HTML 4.0 文書に要求されない制約事項を強制することができない。

それでもなおサーバは、受信側にXHTMLサポートがない環境では、XHTML文書を text/html として転送することを選ぶかもしれない。

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

5.1.3 text/xhtml

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

text/xhtml 型の文書に遭遇した準拠的なユーザエージェントは、その文書がこの仕様書に準拠していると主張しているものと前提してもかまわない。この前提は、text/html 型の文書の受信側が文書の整形式性をチェックしなければならず、またその文書に結びつけられた 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 文書型定義

3つのDTDは HTML 4.0 DTD に近似する。DTDがモジュラ化されるときには、もっと HTML 4.0 に密接に対応したDTD構築の手段が採用される可能性が高いであろう。

A.2 実体セット

XHTML実体セットは HTML 4.0 のものと同じであるが、妥当な XML 1.0 実体宣言となるように修正されている。ユーロ通貨記号(&euro; または &#8364; または &#x20AC;)は特殊キャラクタの部分に定義されているので注意されたい。

付録B. 要素の禁止事項

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

以下の要素は、包含できる要素について禁止事項がある(Section 4.1.9 を見ること)。この禁止事項は、すべてのネスト深度に適用される。すなわち、すべての子孫要素を包含するのである。

a 他の a 要素を含むことができない。
pre img, object, big, small, sub, sup 要素を含むことができない。
button input, select, textarea, label, button, form, fieldset, iframe 要素を含むことができない。
label 他の label 要素を含むことができない。
form 他の form 要素を含むことができない。

付録C. ガイドライン

この付録は参考である。

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

付録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, 19997年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, 1998年8月.
この文書は RFC1738 および 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個以上の処理命令(PI)を組み込むことにより、スタイルシートをXML文書に結びつける手段を解説したものである。http://www.w3.org/TR/PR-xml-stylesheet で入手可能。

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