WD-html-in-xml-19981205
WD-html-in-xml-19981205
W3Cワーキングドラフト 1998年12月5日
このワーキングドラフトは、HTML 4.0 をXMLアプリケーションとして再定式化し、対応するネームスペースを定義するものである。ますます異種混交的な環境におけるHTMLの異なるサブセットおよびスーパーセットについて相互運用性を保証する基礎として、文書プロファイルが導入される。これらは、HTML 4.0 の意味論を書き直すのではなく、この仕様書において別段上書きされない限り、HTML 4.0 のW3C勧告によって定義されているものである。既存のHTMLブラウザとの互換性は、ガイドラインの小セットに従うことにより可能である。
このワーキングドラフトは、他のW3C文書よって何時にても更新され、置換され、または廃棄される場合がある。W3Cワーキングドラフトを参照資料として用いたり、「進行中の作業」以外のものとして引用することは不適切である。これは進行中の作業であって、W3C会員組織による保証としての意味合いをもたない。
この文書は、W3C HTML Activity の一部分として生み出されているものであり、HTMLをXMLの応用として再定式化することについての勧告提案 (Proposed Recommendation) のドラフト化に至る過程の、早期の議論のために向けられたものである。HTMLワーキンググループ(会員専用)の目標はHTML憲章(会員専用)の中で論じられている。
このセクションは、最初はXMLをサポートするブラウザがほとんどないであろうのに、なぜW3Cが次世代HTMLの代わりにXMLへ転換しようし、また、どのようにしてこの移行を、コンテント提供者に対して即時的な利益を与える方法で実現されることになるかを説明する。
XMLとは、ISO規格 Standard Generalized Markup Language(SGML)のサブセットである the eXtensible Markup Language(拡張可能マークアップ言語)の略称である。SGMLは、マークアップ言語を記述するための言語であり、とりわけ電子的な文書交換、文書管理、文書公開に使われるものである。HTMLはSGMLで定義された言語の一例である。
SGMLは、1980年代半ば以来出まわっているものであり、きわめて安定的である。この安定性の多くは、この言語が機能に富み柔軟性を有しているという事実に由来する。しかしながら、この柔軟性は、WWWに接続されたきわめて多数多種なプラットフォームにわたる採用を妨げる一定レベルの複雑さの原因になっている。
HTMLはこの問題を、比較的単純な文書を規律するための限定的なタグセットを規定することにより処理した。文書構造の単純化に加えて、HTMLはハイパーテキストやマルチメディアのサポートを追加した。
HTMLの開発以来、(規格としての)HTML内部で利用したり、垂直的水平的に特化されたマーケットにHTMLを適応させるための新しいタグが急速に開発されている。このことは、異なるプラットフォームにわたるコンテント(文書)についての互換性の問題を引き起こしており、これがソフトウェアとプラットフォームとがますます異種混交的に混じり合う急速に進化しつつある環境において、HTMLの利用法を制限している。
XMLは、SGMLの複雑さなしに、SGMLの能力と柔軟性とを回復する手段として導入された。XMLは、単純化されたSGMLサブセットであり、比較的広く使われているSGMLの機能は残したまま、複雑で実装にコストのかかる多数の機能を取り除いている。
HTMLのモジュラ化とは、プロダクト設計者によって混合配合可能な、よく定義されたHTMLタグセットを指定するという考え方である。たとえば、「テーブルモジュール」であればテーブルをサポートするために必要なエレメントやアトリビュートを含んでいるであろうし、「リストモジュール」であればリストをサポートするために必要なエレメントやアトリビュートを含んでいるであろう。
HTMLをモジュラ化する理由は、コンテント開発者が多数多種のプラットフォーム上でコンテントを配信することを経済的に実現可能にするためである。
最近一両年にわたって、多数の特化されたマーケットが、コンテント言語としてのHTMLに目を向けはじめている。ますます多様なコンピューティングプラットフォームにわたるHTMLの利用に向けた大きな動きが計画中である。現在のところは、HTMLをモバイルデバイス(ハンドヘルドコンピュータ、携帯電話など)やテレビジョンデバイス(デジタルテレビジョン、TVベースのウェブブラウザなど)、家電製品(固定機能デバイス)へ移転させようとする活動がある。これらのデバイスはそれぞれが異なる要求や制約を有している。
XMLによってHTMLを再定式化することは、プロダクト設計者に、彼らの気づいた顧客の要求を処理するためにHTMLを拡張したりサブセット化できる道具を与える。もっとも、これは、準拠性についてのコンテントコミュニティの要求を解決するものではない。
HTMLのモジュラ化は、標準的な組立ブロックと、どの組立ブロックが使われているかを指定するための標準的なメソッドとにより、どのエレメントがサポートされているかを指定する手段をプロダクト設計者に提供する。
これらのモジュールは、コンテントコミュニティの「準拠点」として機能する。これでコンテントコミュニティは、あれやこれやのHTMLエレメントの組み合わせをサポートするインストールベースについて思いわずらうのではなく、一定のモジュールの集合体をサポートするインストールベースを標的とすることができるのである。
規格の利用は、モジュラ化HTMLが大規模に成功するために決定的である。コンテント開発者(制作者)が、HTMLエレメントのあらゆる組み合わせごとにコンテントを仕立てることは経済的に実現不能である。規格を仕様化することにより、ソフトウェアが自主的にデバイスに合わせてコンテントを仕立て、あるいはモジュールを処理するために必要なソフトウェアをデバイスが自動的に読み込むことができるのである。
XMLは、モジュラ化HTML言語を定義し、モジュールがどのように定義され、宣言され、有意義なシステムに組み合わさせるかを規定するために必要な道具を提供する。
文書プロファイルは、文書の文法および意味論を規定する。文書プロファイルへの準拠は、相互運用性の保証の基礎を提供する。プロファイルは、どのデータフォーマットがサポートされるか(例.どの画像フォーマットが使えるか)や、スクリプティングやスタイルシートのサポートの水準などを綴り出す。踏み込んだ詳細は下記に与えられている。文書プロファイルは、W3CのRDF (Resource Description Framework) で表わされる。
文書スキーマは、文書プロファイルに準拠した文書の文法を規定する。この仕様書は、XML 1.0 のDTD(文書型定義)文法をスキーマ文法として使っているが、代わりになる他のスキーマ言語の利用もプロファイルフレームワークの内部では可能である。文法は、どのHTMLモジュールが使われているかや、たとえば化学式や数式、楽譜、ベクトルグラフィックを表現するためのその他のXMLタグセットのための追加的なモジュールを用いて規定される。W3Cは、そうしたモジュールが、特化された種類の情報の共有に利害関係のある範囲の組織によって開発されることと考える。
このセクションは、文書プロファイルがカバーする情報の種類に一瞥を与えるつもりである。詳細は、別の仕様書の中で肉づけされることになる。W3Cは、他のグループからの文書プロファイルへの要望事項について知ることにとても興味がある。
文書プロファイルは、ユーザエージェントに期待される最小のサポートを定義するRDFで書かれた主張 (assertion) からなり、相互運用性の保証のための基礎を提供する。我々は、RDFスキーマ言語を使って文書プロファイルを定式化することを期待する。
基本的な考え方は、その効果への主張を多数なしうるということである。
文書プロファイルの寿命の保証。寿命は、更新をチェックする前にいつまで文書プロファイルを安全にキャッシュしてよいかという日時を規定する。
文書の文法を定義する文書スキーマのURI。文書スキーマは、XML文書型定義として、またはW3Cによって開発中のXMLスキーマ言語で表わされる。下記のとおり、スキーマは、文法を、タグセット(モジュール)からなる1個の構成物として定義する。
たとえばアンカーはネストできないとか、ラベルエレメントはその内容の中にフィールドを1つ、しかも1つだけ含むなどといった、合法な文書の空間をさらに制約する意味論的制約の、機械が解釈可能な表現。さいわいにも、これらの制約を表わす必要性は、XMLに関する将来の作業(XMLスキーマやXMLデータ)によって縮小されるであろう。
準拠ユーザエージェントがサポートすることの必須な内容型データフォーマットの一覧。
たとえば制作者がどのCSS機能のサポートを期待しているかや、どのライブラリが ECMAScript や Java に必要かといった、これらのフォーマットの詳細をカバーする追加的な主張。
文書プロファイルがよく合致するデバイスの種類を記述する主張。デバイスプロファイルに関する以下のセクションを見ること。
文書プロファイルの、人間が読むことのできる記述へのリンク。
プロファイルをいつ誰が定義したか(帰属および著作権)についての追加的な情報。
文書プロファイルは、サーバが与えられたデバイスプロファイルを用いて、ユーザエージェントへの配信に適したバージョンの文書をもっているかどうかを確証するために使うことができる。ときに、これは、より制約された文書プロファイルや cellphone のためのWMLといったようなデバイス特有文書への変形さえも伴う場合がある。
W3Cにおける別の作業は、ブラウザの能力やユーザの選好を規定するデバイスプロファイルを定義するためにRDFをどう使うべきかに注目している。これは、サーバが、おそらくブラウザのデバイスプロファイルと文書のデバイスプロファイルとの照合に基づいて内容を変形することで、ブラウザへ配信するのに適した品種の文書を選択できるようにするであろう。
文書プロファイルおよびデバイスプロファイルは、異なるデバイスの必要に沿うようにマークアップを調整する作業を大幅に単純化するはずである。あるクラスのデバイスによってサポートされるHTML機能のセットが正確に予想できるとき、変形ソフトウェアは単純で信頼できる方式でマークアップを再目的化できるのである。
たとえば、スクリプトやスタイルシート、画像をサポートしない携帯電話を考えてみよう。サーバは携帯電話に文書を送る前にこれらのものを文書から引き剥がして、ページ表示を高速化し、接続料金を抑える。サーバは、問題となっている文書の文書プロファイルとデバイスプロファイルとを比較して、何を引き剥がすかを決定することにより、このことができるのである。
変形は、ウェブサイト上で作業をする制作者によって適用される場合もあるし、インターネットサービスプロバイダの制御の下でプロキシサーバや、ブラウザ自身で適用される場合もある。
次世代HTMLに関する作業は、異なるデバイス上で稼働する異なるユーザエージェントに合わせて簡単に再目的化されてもよいコンテントを作成するコストを低下させる関連マネージメントツールの制作の開発を促進するべく探求するであろう。
Voyager とは、XMLの応用として再定式化されたHTMLのコードネームである。Voyager は、文書プロファイルを、それぞれ独自のウェブアドレス(URI)をもったXMLネームスペースとして仕様化する。HTMLワーキンググループは、(モバイルやテレビジョンといった)特定の領域における利用のために、1セットの Voyager 文書プロファイルを仕様化するであろう。たとえば、"HTML Strict" プロファイルであれば、一般的には HTML 4 Strict DTD に対応するモジュールを含んでいるであろう。文書プロファイルは、準拠文書の文法を、文法モジュールの組み合わせを用いて規定する。たとえば、「テーブル」モジュールであれば、HTMLのテーブル(組み表)に関係するエレメントやアトリビュートを含んでいるであろう。
非W3C実体(会社、協会、その他の標準化団体)がプラットフォームを仕様化するであろうと期待される。プラットフォームは、Voyager プロファイルと、プラットフォーム特有のテクノロジー、制約事項、利用上の要求事項とからなる。たとえば、デジタルテレビジョン標準化団体ならば、テレビジョンプロファイルや Java 仮想マシン、認められるプラグインの制約されたセットを含んだ "DTV" プラットフォームを仕様化するかもしれない。
こちらは、Voyager の目標の、いくぶん形式的な宣言である。
Voyager 文書は、"text/html" とラベルづけされても "text/xml" とラベルづけされてもかまわない。前者は、ユーザエージェントが内容をHTMLとして解釈し、HTMLに特有な意味論を適用することを認める。少数の単純なガイドラインに従うことにより、Voyager 文書は既存のブラウザ上で問題なくレンダリングされるであろう。これはスムーズな意向を提供するもので、重要である。HTMLユーザエージェントは、html エレメント上の xmlns アトリビュートの存在により、Voyager 文書を区別できる。このアトリビュートはネームスペースと文書プロファイルとの双方を指し示すURIを提供するものであり、これらは相互運用性の保証や文書の妥当性検証のために使うことができる。
<html xmlns="http://www.w3.org/Profiles/voyager-strict">
<head>
<title>Frobnostication</title>
</head>
<body>
<p>Moved to <a href="http://www.frob.com/">www.frob.com</a>.</p>
</body>
</html>
"text/xml" とラベルづけされた Voyager 文書は、汎用XMLプロセッサで処理してよい。そうしたプロセッサはHTMLの演繹的な知識をもたないので、文書をレンダリングする必要があるならばスタイルシートが必要である。標準的なXMLリンク機構が標準化されれば、それが使われるべきである。text/xml としての Voyager 文書配信についてのガイドラインは、下記に与えられている。
XML 1.0 仕様書によって定義されているようにである。XML 1.0 仕様書は、整形式制約違反に遭遇したときのユーザエージェントの挙動を制約していることに注意してほしい(section 1.2 Terminology を見ること)。
「しかしながら、いったん致命的エラーが探知されれば、プロセッサは通常の処理を継続してはならない。(すなわち、キャラクタデータや、文書の論理的構造についての情報を、通常の方法でアプリケーションに渡し続けてはならない。)」
xmlns アトリビュートを html エレメント上で使って、文書プロファイルを指し示さなければならない。Voyager 文書が text/html として配信されるとき、xmlns アトリビュートの存在は、html エレメントの内容が整形式のXMLで書かれていて XML 1.0 仕様書に照らして処理されなければならないことを示す。
Voyager 文書は、すべてのHTMLタグおよびアトリビュートについて小文字を使う。これは、XMLが大文字小文字を区別するので <li> と <LI> とが異なるタグとみなされるという事実により必要になる。
Voyager がXML応用であることの結果として、終了タグは必須である。
XMLはアトリビュートの最小化をサポートしない。結果として、compact や checked といったアトリビュートはフル表記で書かれなければならない。
<dl compact="compact">
これは正しいが、以下は許されない。
<dl compact>
Voyager では、script エレメントと style エレメントは #PCDATA 内容をもつものとして宣言される。これは、< や & といったエンティティがXMLプロセッサでそれぞれ < や & に展開されることを意味する。スクリプト命令文をCDATA マークつきセクションの内部に包み込むことにより、これを避けることができる。例.
<script>
<![CDATA[
... 未エスケープのスクリプト内容 ...
]]>
</script>
CDATA 部は、XMLプロセッサにより認識され、文書オブジェクトモデルの中のノードとして現れる。DOM level 1 specification の section 1.3 を見ること。
title エレメントは、head エレメントの内容の最初に置かれなければならず、base エレメントがあるならばこれがその次に続かなければならない。これらの制約は、XMLとSGMLとの相違点ゆえの迂路である。たとえば、
<html xmlns="http://www.w3.org/Profiles/voyager-strict">
<head>
<title>Frobnostication</title>
<style type="text/css">
body {
margin-left:10%;
margin-right: 10%;
font-family: sans-serif;
}
h1 { margin-left: -8%; }
h2 { margin-left: -5%; }
h3,h4,h5,h6 { margin-left: -3%; }
</style>
</head>
<body>
...
</body>
</html>
これは大丈夫であるが、以下のものは title エレメントが head エレメントの内容の最初に現れないからよくない。
<html xmlns="http://www.w3.org/Profiles/voyager-strict">
<head>
<style type="text/css">
body {
margin-left:10%;
margin-right: 10%;
font-family: sans-serif;
}
h1 { margin-left: -8%; }
h2 { margin-left: -5%; }
h3,h4,h5,h6 { margin-left: -3%; }
</style>
<title>Frobnostication</title>
</head>
<body>
...
</body>
</html>
XMLプロセッサがハイパーテキストリンクを認識できるようにするため、'a' タグは xml:link アトリビュートつきで宣言されるべきである。
<!ATTLIST a xml:link CDATA #FIXED "simple">
Voyager 文書はXMLで書かれるから、空タグは /> で終わらなければならない。
Voyager 文書は何段階かで処理される。
一般的には、ブラウザはこれらのステップを同時並行的に走らせて、データがネットワークから受け取られるにつれて漸増的に文書をレンダリングできるようにする。
空白の扱いについての HTML 4.0 の規則は、Voyager ではアトリビュート値へ拡張される。とりわけ、先頭および末尾の空白は引き剥がされ、1つまたはそれ以上の空白キャラクタ(含.改行)の列は、単一の単語間スペース(西洋文字用の ASCII スペースキャラクタ)に割り付けられる。XML 1.0 specification の section 3.3.3 を見ること。
HTML Tidy は、既存のウェブコンテントを Voyager に自動的に変換するための手段を提供するW3Cサンプルコードである。これは、広範囲なマークアップエラーを処理することができ、またHTMLのためにスムーズな移行を実現する助けとなる手段を提供する。
Voyager 仕様書は、現在W3Cで進行中の他のウェブプロジェクト、特に他のXMLベースの仕様書と完全に相互運用可能であることを狙って書かれている。そのモジュラゆえに、コンポーネントベースのアーキテクチャである Voyager は、HTML検証(会員専用)で打ちたてられた目標を満たすために、他のW3Cワーキンググループの作業に大きく依存している。Voyager はウェブパブリッシングのパズルの1ピースにすぎない。明らかに、他のワーキンググループも果たすべき役割を同様に有しているのである。以下のセクションは、キーとなる関連領域のいくつかの輪郭を描く。
このセクションは、既存のHTMLブラウザで Voyager 文書をレンダリングしたいと願う制作者のための設計ガイドラインをまとめたものである。
コンテントは "text/html" とラベルづけして、それがHTMLとして認識され、また適切な意味論で解釈されるよう確保する。
いくつかの古いブラウザではレンダリングされないから、処理命令は使わない。
たとえば <br />, <hr /> や <img src="karen.jpg" alt="Karen" /> というように、空タグの末尾の / と > との前にスペースを入れる。
スタイルシートが < や &, ]]> を使っている場合には、外部スタイルシートを使う。
スクリプトが < や &, ]]> を使っている場合には、外部スクリプトを使う。
非互換性のよくある原因であるから、<object> エレメントを使うことは避ける。
アトリビュート値の内部では改行や複数の空白キャラクタを避ける。これらはブラウザによって扱いが一貫しない。
すべてのアトリビュートがフル表記で書き出されていることを確認する。たとえば dl エレメントで compact アトリビュートを使いたいならば、<dl compact> ではなく <dl compact="compact"> と書く必要があるだろう。これは、フォームフィールドに使われる checked にも当てはまる。
エレメントの言語を指定するときには lang アトリビュートを使う。
HTML 3.2 または 4.0 にある以外のエレメントは使わない。
HTML特有の意味論を知らない汎用XMLプロセッサで利用するためのHTML文書を制作することには、異なる関心事のセットが関係する。
コンテントを "text/xml" とラベルづけして、それがXMLコンテントハンドラ経由で処理されることを確保する。
文書のキャラクタエンコーディングが UTF-8 または UTF-16 以外である場合には、XML処理命令を使う。例.
<?xml version="1.0" encoding="EUC-JP"?>
XML 1.0 仕様書に組み込まれている (<, &, >) 以外のキャラクタエンティティ名の使用は避ける。たとえば、単語区切りを生じないスペースを表わすのには、 ではなく   を使う。
スタイルシートは特別な処理命令によって参照する。例.
<?xml-stylesheet href="mystyle.css" type="text/css"?>
エンティティ宣言を組み込む必要があり、またはDTDに照らして文書の妥当性を検証できるようにしたい場合には、文書型宣言を使う。
XMLプロセッサが適切に扱えるよう、<a> や <img> エレメントではXMLリンクアトリビュートを使う。
frameset, frame, object, form, applet といったような汎用XMLプロセッサ経由では適切に処理できない エレメントの使用は避ける。
XMLでは、"#名前" で終わるURIは、a name= アトリビュートではなく、その名前の id アトリビュートをもつエレメントを参照する。多数の既存のHTMLクライアントは、このような id アトリビュートの利用をサポートせず、そのためHTMLクライアント上で文書を処理できるようにしたいならば、id 値と name 値との双方を補いたいと思ってもよい。例.
<a id="foo" name="foo"> ... </a>
エレメントの言語を指定するときには xml:lang アトリビュートを使う。文書をHTMLプロセッサ上でも処理できるようにしたいならば、xml:lang と HTML lang アトリビュートとの双方を使う。
Voyager は、XMLによるHTMLの再定式化だけではない。Voyager はHTMLを、いくつかのタグセットが1つに集合した集合体へとモジュラ化する。これらのタグセットは、制作者がWWW接続性をもった革新的な製品を構築するのに使ってよい組み立てブロックである。もっと重要なのは、これらのタグセットが、コンテントコミュニティにとって設計準拠点として機能することである。
下記に定義されているモジュールは、製品開発者(小さくて柔軟な組み立てブロックを求める)の要求と、コンテント開発者(組み合わせ数の少ない少数の組み立てブロックを求める)の要求とのバランスを取る合理的なモジュールセットを定義する初めての試みである。より強度なサブセット化が要望されるところでは、製品開発者は、コンテントコミュニティに対するフルモジュールサポートと、その配信プラットフォームのためのもっと小さい規定とを提供するサーバベースまたはプロキシベースの変形ソフトウェアを考慮するよう奨励される。
基礎モジュールは、基本的な Voyager データ型や内容モデルを、Voyager プロファイルが組み込まなければならない最小限のエレメントセットとともに規定する。具体的には、基礎モジュールには html, head, title, base, meta, link, body, h1-6, p, br, a, bdo, span, div というエレメントが含まれる。
移行モジュールは、HTML 4.0 Transitional プロファイルの中にはあるが HTML 4.0 Strict プロファイルからは除外されているエレメントを規定する。具体的には、移行モジュールは basefont, font, center, s, u というエレメントが含まれる。また border, align, noshade といった表現的アトリビュートの定義も含まれている。
スタイルモジュールは、style エレメント、style アトリビュートと、スタイルシートをリンクするため html link エレメントの使用とを規定する。
スクリプトモジュールは、script, noscript エレメントを規定する。
フォントモジュールは、HTML 4.0 Strict プロファイルの中に見られるフォント関連のエレメントを規定する。tt, b, i, big, small.
フレーズモジュールは、制作者の意図の上や背後にある領域特有の情報を提供するフレーズエレメントを規定する。具体的には、フレーズモジュールには abbr, acronym, address, blockquote, q, cite, code, dfn, kbd, samp, var というエレメントが含まれる。
抑揚モジュールは、領域特有の情報を提供するのでなく、制作者の意図のヒントを提供するフレーズエレメントを規定する。具体的には、抑揚モジュールには em, pre, strong, sub, sup, hr というエレメントが含まれる。
編集モジュールは、文書編集関連のエレメントを規定する。具体的には、編集モジュールには del, ins というエレメントが含まれる。
リストモジュールは、リスト関連のエレメントを規定する。具体的には、リストModule には dl, dt, dd, ul, ol, li というエレメントが含まれる。
フォームモジュールは、HTML 4.0 のフォーム関連のエレメントを規定する。具体的には、フォームモジュールには form, input, textarea, select, optgroup, option, label, button, fieldset, legend, isindex というエレメントが含まれる。
テーブルモジュールは、テーブル関連のエレメントを規定する。具体的には、テーブルモジュールには table, caption, col, colgroup, thead, tbody, tfoot, tr, th, td というエレメントが含まれる。
画像モジュールには img エレメントが含まれる。ローエンドシステムの中には、画像はサポートしてもイメージマップはサポートしないものがある。
イメージマップモジュールには、画像モジュールとともに利用する map, area というエレメントが含まれる。
オブジェクトモジュールは、オブジェクト関連のエレメントを規定する。具体的には、オブジェクトモジュールには object, param が含まれる。
アプレットモジュールには、applet, param というエレメントが含まれており、プロファイルが Java アプレットをサポートするときに使われる。
フレームモジュールは、HTML 4.0 のフレーム関連のエレメントを規定する。具体的には、フレームモジュールには frameset, frame, iframe, noframes エレメントが含まれる。
この仕様書は、HTML 4.0 の strict, transitional, frameset というDTDのそれぞれに対応し、XML 1.0 仕様書に従って再定式化した3つのプロファイルにつき、XMLネームスペースを定義する。
Voyager 文書型定義および関連規則 によって定義された文書は、この仕様書の規範的部分を構成する。これは、文書型宣言を除いて仕様書を印字したい人々の便宜のため別ファイルに置かれている。