WD-html-in-xml-19990224
WD-html-in-xml-19990224
W3Cワーキングドラフト 1999年2月24日
この仕様書は、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 である。
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を拡張およびサブセット化する将来の文書型のファミリーの基礎となるものである。この考え方は、将来的な方向性に関する節でさらに詳細に論じられる。
HTML 4.0 [HTML] は、国際規格 ISO 8879 に準拠したSGML(標準的汎用マークアップ言語)アプリケーションであり、広くワールド=ワイド=ウェブの標準的なパブリッシング言語として認められている。
SGMLは、マークアップ言語、とりわけ電子文書交換や文書管理、文書出版に使われる言語を記述するための言語である。HTMLは、SGMLで定義された言語の一例である。
SGMLは、1980年代半ば以来広まっており、きわめて安定的なままでいる。この安定性の多くは、この言語が機能に富みつつ柔軟でもあるという事実によるものである。もっとも、この柔軟性は一定の対価によって実現されるものであり、その対価とは、ワールド=ワイド=ウェブを含め多様な環境で採用することの妨げとなるレベルの複雑さである。
HTMLは、元々の認識では、文書の専門家でない者による利用に適した、科学やその他の技術的な文書の交換のための言語たらんとするものであった。HTMLは、比較的単純な文書を制作するのに適した構造的タグおよび意味論的タグの小集合を規定することにより、SGMLの複雑さの問題に対処した。文書構造を単純化することに加えて、HTMLは、ハイパーテキストのサポートを追加した。マルチメディア機能が後に追加された。
驚くほど短時間でHTMLは広くポピュラーなものになり、急速に元の目的を越えて成長した。HTMLの起こり以来、(標準としての)HTMLで利用したり、HTMLを垂直的で高度に特化されたマーケットに適合させたりするための新しいエレメントが急速に開発され続けている。この大量の新しいエレメントが、異なるプラットフォームにわたる文書についての互換性問題をもたらしている。
ソフトウェアおよびプラットフォームの双方の異種混合性が急速に広がるに伴い、これらのプラットフォームで利用する「クラシックな」HTML 4.0 の安定性は幾分限定されることが明らかである。
XMLとは Extensible Markup Language™ の短縮表記であり、eXtensible Markup Language [XML] の頭字語である。
XMLは、SGMLの複雑さの大半を取り除きながらSGMLの力と柔軟性とを取り戻す手段として考えられていた。SGMLの制限形態であるけれども、にもかかわらずXMLは、SGMLの力や豊富さのほとんどを保ち、なおSGMLの一般的に使われる機能のすべてを残している。
有益な機能を維持しつつ、XMLは、適したソフトウェアの制作や設計を困難かつ高コストなものとするSGMLの複雑な機能の多数を除去するのである。
コンテンツ開発者がXHTMLを採用するべき主な理由は2つある。
第一に、XHTMLは拡張可能であるよう設計されている。この拡張性は、文書が整形式でなくてはならないというXML必須事項を当てにしている。SGMLの下では、新しいエレメントグループの追加がDTD全体の変更を意味することがよくあった。XMLベースのDTDでは、既存のDTDに追加されるために要求されることは、新しいエレメントセットが内部的に一貫性があり、整形式であることだけである。これが新しいエレメント集合体の開発や統合を著しく容易にするのである。
第二に、XHTMLはポータビリティをねらって設計されている。非デスクトップのユーザエージェントを利用してインターネット文書にアクセスすることは、ますます増えるであろう。ある推計が示すところによると、2002年までにインターネット文書閲覧の75%がこれらの代用プラットフォームで実行されるという。ほとんどの場合、これらのプラットフォームにはデスクトッププラットフォームの計算力をもっていないであろうし、不整なHTMLも、現在のユーザエージェントならば調整する傾向があるが、これらのプラットフォームはこれを調整するように設計されないであろう。実際、これらのユーザエージェントは整形式でないXHTMLを受け取っても、単にその文書を表示しなくてよいのである。
以下の用語がこの仕様書で使われるものである。この用語は、ISO/IEC 9945-1:1990 [POSIX.1] における類似の定義に基づいた方法で、[RFC2119] における定義を拡張したものである。
このバージョンのXHTMLは、厳格準拠XHTML文書に関する文書準拠性を定義するだけである。厳格準拠XHTML文書は、この仕様書において義務的なものとして記述されたファシリティのみを要求する文書である。そうした文書は、以下の規準のすべてに沿うものでなければならない。
付録 A にある3つのDTDのうちの一つに照らして妥当性が認められなければならない。
文書のルートエレメントは <html> でなければならない。
文書のルートエレメントは、xmlns アトリビュートを使うことにより、3つの定義済みDTDのうちの一つを指し示さなければならない [XMLNAMES]。指し示された名前空間は、その文書が妥当性が認められると主張する基準DTDの名前空間に一致しなければならない。定義済みの名前空間は、次の通りである。
http://www.w3.org/Profiles/xhtml1-strict.dtd
http://www.w3.org/Profiles/xhtml1-transitional.dtd
http://www.w3.org/Profiles/xhtml1-frameset.dtd
ルートエレメントに先立って、文書の中に 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>
準拠ユーザエージェントは、以下の基準のすべてに沿うものでなければならない。
XHTMLがXMLアプリケーションであるという事実により、SGMLベースの HTML 4.0 [HTML] では完全に合法である一定の慣習は変更されなければならない。
整形式性 (Well-formedness) は、[XML] によって導入された新しい概念である。本質的上これは、エレメントはすべて閉じタグをもつか(後述するように)特殊な形式で書かれなければならず、エレメントはすべてネストされなければならないとことを意味する。
オーバーラッピングはSGMLでは違法であるけれども、SGMLベースのブラウザでは広く黙認されていた。
正: ネストされたエレメント
<p>ここには強調された<em>段落</em>がある。</p>
誤: オーバーラッピングしているエレメント
<p>ここには強調された<em>段落</p>がある。</em>
XHTML文書は、HTMLエレメント名およびアトリビュート名にはすべて小文字を使わなければならない。この違いが避けられないのは、XMLが大文字と小文字とを区別し、たとえば <li> と <LI> とは異なるタグとみなされるからである。
SGMLベースの HTML 4.0 では、一定のエレメントは終了タグを省略することが許されていた。要素には黙示的な閉鎖がついていたのである。この省略はXMLベースのXHTMLでは許されない。DTDで EMPTY として宣言されたもの以外のエレメントはすべて、終了タグをもたなければならない。
正: 閉じられたエレメント
<p>ここに段落がある。</p><p>ここには他の段落がある。</p>
誤: 閉じられていないエレメント
<p>ここには段落がある。<p>ここには他の段落がある。
アトリビュート値は、数値として現れるものであっても、すべて引用符で括られなければならない。
正: 引用符で括られたアトリビュート値
<table rows="3">
誤: 引用符で括られないアトリビュート値
<table rows=3>
XMLはアトリビュート最小化をサポートしない。アトリビュート-値の対はフル表記で書かれなければならない。compact や checked といったようなアトリビュート名は、その値が規定されなければエレメントに出現できない。
正: 最小化されないアトリビュート
<dl compact="compact">
誤: 最小化されたアトリビュート
<dl compact>
空エレメントは /> で終了しなければならない。例. <br />, <hr />.
正: 閉じられた空タグ
<br /><hr />
誤: 閉じられていない空タグ
<br><hr>
XHTMLは、アトリビュート値の中にある空白の扱いについて、HTML 4.0 を変える。とりわけ、XHTMLは、先頭及び末尾の空白を剥ぎ取り、1個以上の空白キャラクタ(改行も含まれる)の連なりを単一の単語間空白(西洋文字についてはASCIIスペースキャラクタ)に割り付ける。[XML] の Section 3.3.3 を見ること。
XHTMLでは、スクリプトエレメントおよびスタイルエレメントは、#PCDATA 内容をもつものとして宣言される。結果として、< や & といったようなエンティティは、XMLプロセッサにより、それぞれ < や & に展開されることになる。スクリプトエレメントやスタイルエレメントの内容を CDATA マーク部の中に包み込むことで、これらのエンティティの展開が避けられる。
<script> <![CDATA[ ... エスケープされていないスクリプト内容 ... ]]> </script>
CDATA 部は、XMLプロセッサによって認識され、DOM(文書オブジェクトモデル)のノードとして現れる。DOM1勧告 [DOM] の Section 1.3 を見ること。
代替策としては、外部スクリプト文書や外部スタイル文書を使うというものがある。
SGMLは、DTDの書き手に、特定のエレメントがあるエレメントの中に包含されないよう排除する能力を与える。そうした禁則(「排除(exclusion)」と呼ばれる)は、XMLでは不可能である。
たとえば、HTML 4.0 Strict DTD は、子孫の深さを問わず、ある 'a' エレメントを他のある 'a' エレメントの中にネストすることを禁じる。XMLでそうした禁止を説明することは不可能である。この禁止がDTDで定義できない場合であっても、一定のエレメントはネストするべきではない。そうしたエレメントや、そのエレメントの中にネストされるべきではないエレメントをまとめたものは、規範性を有する 付録 B で見られる。
現行の HTML 4.0 DTD は、HTML 4.0 勧告 [HTML] に対してなされたエラッタを反映するものではない。XHTML DTD はこのエラッタを組み込み、そのため HTML 4.0 DTD のエラーは XHTML では訂正される。エラッタは [ERRATA] で見ることができる。
HTML Tidy は、既存のウェブコンテンツを自動的にXHTMLに変換するW3Cサンプルコードである。これは広範なマークアップエラーを処理することができ、既存のHTML文書からXHTMLへスムーズに移行するための手段を提供する。詳しい情報については、[TIDY] を見ること。
XHTML 1.0 文書が既存のユーザエージェントと互換的であるべきとの要求はないけれども、実際これは実現が簡単である。互換的な文書を作成するためのガイドラインは、付録 C で見ることができる。
XHTML文書は、以下のインターネットメディア型のうちの一つを使って転送してよい。これらの型を使って、汎用XMLアプリケーションへサーブできるXHTML文書(text/xml)や、旧来のHTMLユーザエージェントへサーブできるもの(text/html)、新しいXHTMLアプリケーションにサーブできるもの(text/xhtml)を作成することにより、文書制作者はポータブルなインターネットコンテンツを作成することができる。
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 として転送されても失われるような情報がないということにある。もっとも、この仕様書はその目標をまだ実現していない。
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文書は、既存のユーザエージェントによって通常の方法で処理される可能性が高い。
text/xhtml
上記の text/xml や text/html というインターネットメディア型はそれぞれXHTML文書についての情報を切り捨てるので、text/xhtml というインターネットメディア型を登録するというのがW3Cの意図である。
text/xhtml という型の文書に遭遇した準拠ユーザエージェントは、その文書がこの仕様書に準拠していると主張していることを前提としてよい。この前提は、text/xhtml 型の文書の受領者が、文書の整形式性をチェックしなければならず、また文書に結びつけられている XHTML DTD に照らして文書の妥当性をチェックしてもかまわないとことを意味する。
我々は、このメディア型の役割や代替機構に関する議論を大歓迎する。
XHTML 1.0 は、広範な新デバイスや新アプリケーションをサポートするために、モジュールを定義し、このモジュールを組み合わせるための機構を規定することにより、XHTML を拡張したりサブセット化する文書型のファミリーのための基礎を提供する。この機構は、新モジュールの定義を通じて統一的な方法で XHTML 1.0 の拡張やサブセットかを可能にするものである。
伝統的なデスクトップのユーザエージェントからその他のプラットフォームとXHTMLの用途が移るに伴い、すべてのプラットフォームでXHTMLエレメントのすべてが要求されるとは限らないことが明らかである。たとえば、ハンドヘルドのデバイスや携帯電話は、XHTMLエレメントのサブセットしかサポートしなくてもかまわない。
モジュラ化という処理は、XHTMLを一連の小さいエレメントセットに分割することである。そしてこれらのエレメントは、異なるコミュニティの必要に見合うよう再度組み合わせることができるのである。
このモジュールは、後のW3C文書で定義されるであろう。
モジュラ化はいくつかの利点をもたらす。
XHTMLをサブセット化するための形式面での機構を用意する。
XHTMLを拡張するための形式面での機構を用意する。
文書型間の変形を単純化する。
新しい文書型でのモジュールの再利用を促進する。
文書プロファイルは、文書セットの文法および意味論を規定するものである。文書プロファイルに準拠するということは、相互運用性の保証の基礎を提供する。文書プロファイルは、その型の文書を処理するために必要なファシリティ、たとえばどの画像フォーマットが使えるかということや、スクリプトのレベル、スタイルシートサポートなどといったものを規定する。
プロダクト設計者にとって見ると、これは多様なグループが独自の標準的プロファイルを定義することを可能にする。
制作者にとって見ると、これは、いくつもの異なるクライアントのための異なるバージョンの文書を書く必要性を取りのける。
科学者や医学者、数学者といったような特殊なグループにとって見ると、これは、その専門家の必要にかみ合うエレメントグループを標準的なHTMLエレメントに追加して使って、特殊なプロファイルが構築できるようにする。
この付録は規範的である。
3つのDTDとエンティティセットとが、この仕様書の規範的部分を形成する。XML宣言やSGML公開カタログつきのDTDファイルの完全セットは、この仕様書[の原文]についてのzipファイルの中に含まれている。
これらのDTDは HTML 4.0 DTD に近いものである。DTDがモジュラ化されるとき、HTML 4.0 にきわめて密接に対応するDTD構築の方法が採用される可能性は高い。
XHTMLエンティティセットは、HTML 4.0 用のものと同じであるが、妥当な XML 1.0 エンティティ宣言となるよう修正されている。ユーロ通貨記号(€ または €)を表すエンティティは、特殊キャラクタの一部として定義される。
この付録は規範的である。
以下のエレメントは、包含できるエレメントについての禁則がある(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 エレメントを包含できない.
|
この付録は参考である。
この付録は、既存のHTMLユーザエージェントでXHTML文書をレンダリングしたい制作者のための設計ガイドラインをまとめたものである。
ユーザエージェントによっては処理命令(PI)がレンダリングされることに気をつける。
空エレメントの末尾の / と > との前にスペースを1個組み込む。例. <br />, <hr />, <img src="karen.jpg" alt="Karen" />. また、空エレメントには、たとえば <br /> という最小化タグ文法を使う。XMLによって認められている代替文法 <br></br> は、多数の既存のユーザエージェントでは不確実な結果を与えるからである。
内容モデルが EMPTY でないエレメントの空インスタンスが与えられるならば(たとえば空のタイトルやパラグラフ)、最小化形式を使わない(たとえば、<p /> ではなく <p> </p> を使う)。
スタイルシートが < や &, ]]> を使っているならば、外部スタイルシートを使う。スクリプトが < や &, ]]> を使っているならば、外部スクリプトを使う。
アトリビュート値の中では、改行や複数の空白キャラクタを避ける。これはユーザエージェントによる扱いが一貫していない。
エレメントの言語を指定するときには、lang アトリビュートと xml:lang アトリビュートとの両方を使う。
XMLでは、"#foo" という形式のフラグメント識別子で終わるURIは、name="foo" というアトリビュートをもつエレメントを参照しない。むしろ、たとえば HTML 4.0 の id アトリビュートというような、ID という型であると定義されたアトリビュートをもつエレメントを参照する。多数の既存のHTMLクライアントは、ID-型アトリビュートの利用をこのような形でサポートしないので、その文書をHTML区ライン後で処理できるようになりたいならば、たとえば <a id="foo" name="foo">...</a> というように、ターゲットエレメントに id 値と name 値との両方を補いたいと思ってもかまわない。
文書のキャラクタエンコーディングを指定するには、xml 宣言でのエンコードアトリビュート指定(例. <?xml version="1.0" encoding="EUC-JP"?>)と、meta http-equiv ステートメント(例. <meta http-equiv="Content-type" content='text/html; charset="EUC-JP"' />)との両方を使う。
この付録は参考である。