XMLによるHTMLの再定式化


W3CWD-html-in-xml-19981205

XMLによるHTMLの再定式化

W3Cワーキングドラフト 1998年12月5日

このバージョンのドラフト(原文):
http://www.w3.org/TR/1998/WD-html-in-xml-19981205
最新のバージョン:
http://www.w3.org/TR/WD-html-in-xml
ローカルブラウジング用に Zip 圧縮されたアーカイブ(原文のアーカイブ)としても入手可能である。
編集者:
Dave Raggett <dsr@w3.org>, W3C on assignment from HP
Frank Boumphrey <bckman@ix.netcom.com>, HTML Writers Guild,
Murray Altheim <altheim@eng.sun.com>, Sun Microsystems,
Ted Wugofski <ted.wugofski@otmp.com>, Over the Moon Productions.
著作権:
著作権  ©  1998 W3C (マサチューセッツ工科大学, フランス国立情報処理自動化研究所, 慶應義塾大学). すべての権利が留保されている。

概要

このワーキングドラフトは、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憲章(会員専用)の中で論じられている。

目次

  1. なぜHTMLをXMLの応用として再定式化することを選ぶか
    1. XMLとは何か
    2. HTMLのモジュラ化
    3. 文書プロパティ
    4. デバイスプロパティ
    5. 異なるデバイスのためにマークアップを変形する
  2. Voyager
    1. Voyager とは何か
    2. Voyager の目標
    3. Voyager の規範的定義
      1. Voyager 文書は整形式XMLでなければならない
      2. xmlns アトリビュートは文書プロファイルを指し示す
      3. タグおよびアトリビュートは小文字でなければならない
      4. 終了タグは必須である
      5. アトリビュートの最小化
      6. script エレメントと style エレメント
      7. title エレメントと base エレメント
      8. アンカーエレメント
      9. 空エレメント
    4. 処理モデル
    5. 空白の扱い
    6. 既存のコンテントを Voyager に変換する
    7. 他のW3Cイニシアティブに対する Voyager の関係
  3. 互換性ガイドライン
    1. 既存のHTMLブラウザ
    2. 汎用XMLプロセッサ
  4. Voyager モジュール
    1. 基礎モジュール
    2. 移行モジュール
    3. スタイルモジュール
    4. スクリプトモジュール
    5. フォントモジュール
    6. フレーズモジュール
    7. 抑揚モジュール
    8. 編集モジュール
    9. リストモジュール
    10. フォームモジュール
    11. テーブルモジュール
    12. 画像モジュール
    13. イメージマップモジュール
    14. オブジェクトモジュール
    15. アプレットモジュール
    16. フレームモジュール
  5. strict, loose, frameset プロファイル用のネームスペース
    および関連文書型定義:
  6. 謝辞
  7. 参照資料

1 なぜHTMLをXMLの応用として再定式化することを選ぶか

このセクションは、最初はXMLをサポートするブラウザがほとんどないであろうのに、なぜW3Cが次世代HTMLの代わりにXMLへ転換しようし、また、どのようにしてこの移行を、コンテント提供者に対して即時的な利益を与える方法で実現されることになるかを説明する。

1.1 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の機能は残したまま、複雑で実装にコストのかかる多数の機能を取り除いている。

1.2 HTMLのモジュラ化

HTMLのモジュラ化とは、プロダクト設計者によって混合配合可能な、よく定義されたHTMLタグセットを指定するという考え方である。たとえば、「テーブルモジュール」であればテーブルをサポートするために必要なエレメントやアトリビュートを含んでいるであろうし、「リストモジュール」であればリストをサポートするために必要なエレメントやアトリビュートを含んでいるであろう。

HTMLをモジュラ化する理由は、コンテント開発者が多数多種のプラットフォーム上でコンテントを配信することを経済的に実現可能にするためである。

最近一両年にわたって、多数の特化されたマーケットが、コンテント言語としてのHTMLに目を向けはじめている。ますます多様なコンピューティングプラットフォームにわたるHTMLの利用に向けた大きな動きが計画中である。現在のところは、HTMLをモバイルデバイス(ハンドヘルドコンピュータ、携帯電話など)やテレビジョンデバイス(デジタルテレビジョン、TVベースのウェブブラウザなど)、家電製品(固定機能デバイス)へ移転させようとする活動がある。これらのデバイスはそれぞれが異なる要求や制約を有している。

XMLによってHTMLを再定式化することは、プロダクト設計者に、彼らの気づいた顧客の要求を処理するためにHTMLを拡張したりサブセット化できる道具を与える。もっとも、これは、準拠性についてのコンテントコミュニティの要求を解決するものではない。

HTMLのモジュラ化は、標準的な組立ブロックと、どの組立ブロックが使われているかを指定するための標準的なメソッドとにより、どのエレメントがサポートされているかを指定する手段をプロダクト設計者に提供する。

これらのモジュールは、コンテントコミュニティの「準拠点」として機能する。これでコンテントコミュニティは、あれやこれやのHTMLエレメントの組み合わせをサポートするインストールベースについて思いわずらうのではなく、一定のモジュールの集合体をサポートするインストールベースを標的とすることができるのである。

規格の利用は、モジュラ化HTMLが大規模に成功するために決定的である。コンテント開発者(制作者)が、HTMLエレメントのあらゆる組み合わせごとにコンテントを仕立てることは経済的に実現不能である。規格を仕様化することにより、ソフトウェアが自主的にデバイスに合わせてコンテントを仕立て、あるいはモジュールを処理するために必要なソフトウェアをデバイスが自動的に読み込むことができるのである。

XMLは、モジュラ化HTML言語を定義し、モジュールがどのように定義され、宣言され、有意義なシステムに組み合わさせるかを規定するために必要な道具を提供する。

1.3 文書プロファイル

文書プロファイルは、文書の文法および意味論を規定する。文書プロファイルへの準拠は、相互運用性の保証の基礎を提供する。プロファイルは、どのデータフォーマットがサポートされるか(例.どの画像フォーマットが使えるか)や、スクリプティングやスタイルシートのサポートの水準などを綴り出す。踏み込んだ詳細は下記に与えられている。文書プロファイルは、W3CのRDF (Resource Description Framework) で表わされる。

文書スキーマは、文書プロファイルに準拠した文書の文法を規定する。この仕様書は、XML 1.0 のDTD(文書型定義)文法をスキーマ文法として使っているが、代わりになる他のスキーマ言語の利用もプロファイルフレームワークの内部では可能である。文法は、どのHTMLモジュールが使われているかや、たとえば化学式や数式、楽譜、ベクトルグラフィックを表現するためのその他のXMLタグセットのための追加的なモジュールを用いて規定される。W3Cは、そうしたモジュールが、特化された種類の情報の共有に利害関係のある範囲の組織によって開発されることと考える。

プロファイルの働き方を示した図

このセクションは、文書プロファイルがカバーする情報の種類に一瞥を与えるつもりである。詳細は、別の仕様書の中で肉づけされることになる。W3Cは、他のグループからの文書プロファイルへの要望事項について知ることにとても興味がある。

文書プロファイルは、ユーザエージェントに期待される最小のサポートを定義するRDFで書かれた主張 (assertion) からなり、相互運用性の保証のための基礎を提供する。我々は、RDFスキーマ言語を使って文書プロファイルを定式化することを期待する。

基本的な考え方は、その効果への主張を多数なしうるということである。

文書プロファイルは、サーバが与えられたデバイスプロファイルを用いて、ユーザエージェントへの配信に適したバージョンの文書をもっているかどうかを確証するために使うことができる。ときに、これは、より制約された文書プロファイルや cellphone のためのWMLといったようなデバイス特有文書への変形さえも伴う場合がある。

1.4 デバイスプロファイル

W3Cにおける別の作業は、ブラウザの能力やユーザの選好を規定するデバイスプロファイルを定義するためにRDFをどう使うべきかに注目している。これは、サーバが、おそらくブラウザのデバイスプロファイルと文書のデバイスプロファイルとの照合に基づいて内容を変形することで、ブラウザへ配信するのに適した品種の文書を選択できるようにするであろう。

1.5 異なるデバイスに適するようにマークアップを変形する

文書プロファイルおよびデバイスプロファイルは、異なるデバイスの必要に沿うようにマークアップを調整する作業を大幅に単純化するはずである。あるクラスのデバイスによってサポートされるHTML機能のセットが正確に予想できるとき、変形ソフトウェアは単純で信頼できる方式でマークアップを再目的化できるのである。

たとえば、スクリプトやスタイルシート、画像をサポートしない携帯電話を考えてみよう。サーバは携帯電話に文書を送る前にこれらのものを文書から引き剥がして、ページ表示を高速化し、接続料金を抑える。サーバは、問題となっている文書の文書プロファイルとデバイスプロファイルとを比較して、何を引き剥がすかを決定することにより、このことができるのである。

変形は、ウェブサイト上で作業をする制作者によって適用される場合もあるし、インターネットサービスプロバイダの制御の下でプロキシサーバや、ブラウザ自身で適用される場合もある。

次世代HTMLに関する作業は、異なるデバイス上で稼働する異なるユーザエージェントに合わせて簡単に再目的化されてもよいコンテントを作成するコストを低下させる関連マネージメントツールの制作の開発を促進するべく探求するであろう。

異なるデバイス上でレンダリングするためにスクリプトがマークアップをどのように変形するかを示した図

2 Voyager

2.1 Voyager とは何か

Voyager とは、XMLの応用として再定式化されたHTMLのコードネームである。Voyager は、文書プロファイルを、それぞれ独自のウェブアドレス(URI)をもったXMLネームスペースとして仕様化する。HTMLワーキンググループは、(モバイルやテレビジョンといった)特定の領域における利用のために、1セットの Voyager 文書プロファイルを仕様化するであろう。たとえば、"HTML Strict" プロファイルであれば、一般的には HTML 4 Strict DTD に対応するモジュールを含んでいるであろう。文書プロファイルは、準拠文書の文法を、文法モジュールの組み合わせを用いて規定する。たとえば、「テーブル」モジュールであれば、HTMLのテーブル(組み表)に関係するエレメントやアトリビュートを含んでいるであろう。

非W3C実体(会社、協会、その他の標準化団体)がプラットフォームを仕様化するであろうと期待される。プラットフォームは、Voyager プロファイルと、プラットフォーム特有のテクノロジー、制約事項、利用上の要求事項とからなる。たとえば、デジタルテレビジョン標準化団体ならば、テレビジョンプロファイルや Java 仮想マシン、認められるプラグインの制約されたセットを含んだ "DTV" プラットフォームを仕様化するかもしれない。

2.2 Voyager の目標

こちらは、Voyager の目標の、いくぶん形式的な宣言である。

  1. Voyager は、インターネット上でそのまま簡単に利用できるものでなければならない。
  2. Voyager 文書は、Voyager 仕様書に従って妥当性を検証できるXML文書でなければならない。
  3. Voyager 文書は、アプリケーションに対して "text/xml" と "text/html" とのどちらとして特定されてもよい。アプリケーションは、"text/xml" として特定された文書を、XML 1.0 仕様書において規定された制約を越えて処理する義務を負わない。
  4. Voyager 文書機能は、Voyager 仕様書と一貫性のある標準的でよく定義された方法で拡張可能でなければならない。
  5. サーバが適切な文書コンテントをクライアントに配信できるようにするため、リアルタイムリターンチャンネルが利用可能であれば Voyager 準拠ユーザエージェントは文書リクエストが作られる時にサーバに対してユーザエージェントの機能を特定しなければならず、また Voyager 文書はプロファイルつきで明確にマークされなければならない。
  6. Voyager 文書の作成は、特化されたツールの利用なしに可能でなければならない。
  7. Voyager は、W3Cによって定義される関連したXMLベースの仕様書との相互運用性を維持しなければならない。
  8. Voyager 仕様書は、形式的かつ正確に、また可能な限り実装者による解釈がばらつきにくい方法で書かれなければならない。
  9. Voyager 仕様書は、モジュラ性および拡張性に向かう1ステップとして、首尾一貫したエレメントセットを用いて Voyager 文書を定義する。
  10. Voyager は、上記に表明された目標と一貫性のある最大限の範囲で、以前のバージョンのHTMLとの後方互換性を提供するような方法で仕様化されなければならない。

2.3 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 文書配信についてのガイドラインは、下記に与えられている。

2.3.1 Voyager 文書は整形式XMLでなければならない

XML 1.0 仕様書によって定義されているようにである。XML 1.0 仕様書は、整形式制約違反に遭遇したときのユーザエージェントの挙動を制約していることに注意してほしい(section 1.2 Terminology を見ること)。

「しかしながら、いったん致命的エラーが探知されれば、プロセッサは通常の処理を継続してはならない。(すなわち、キャラクタデータや、文書の論理的構造についての情報を、通常の方法でアプリケーションに渡し続けてはならない。)」

2.3.2 xmlns アトリビュートを使って文書プロファイルを指し示さなければならない

xmlns アトリビュートを html エレメント上で使って、文書プロファイルを指し示さなければならない。Voyager 文書が text/html として配信されるとき、xmlns アトリビュートの存在は、html エレメントの内容が整形式のXMLで書かれていて XML 1.0 仕様書に照らして処理されなければならないことを示す。

2.3.3 タグおよびアトリビュートは小文字でなければならない

Voyager 文書は、すべてのHTMLタグおよびアトリビュートについて小文字を使う。これは、XMLが大文字小文字を区別するので <li> と <LI> とが異なるタグとみなされるという事実により必要になる。

2.3.4 終了タグは必須である。

Voyager がXML応用であることの結果として、終了タグは必須である。

2.3.5 アトリビュートの最小化

XMLはアトリビュートの最小化をサポートしない。結果として、compactchecked といったアトリビュートはフル表記で書かれなければならない。

  <dl compact="compact">

これは正しいが、以下は許されない。

  <dl compact>

2.3.6 Script エレメントと Style エレメント

Voyager では、script エレメントと style エレメントは #PCDATA 内容をもつものとして宣言される。これは、&lt; や &amp; といったエンティティがXMLプロセッサでそれぞれ < や & に展開されることを意味する。スクリプト命令文をCDATA マークつきセクションの内部に包み込むことにより、これを避けることができる。例.

  <script>
    <![CDATA[
       ... 未エスケープのスクリプト内容 ...
    ]]>
  </script>

CDATA 部は、XMLプロセッサにより認識され、文書オブジェクトモデルの中のノードとして現れる。DOM level 1 specificationsection 1.3 を見ること。

2.3.7 Title エレメントと Base エレメント

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>

2.3.8 アンカーエレメント

XMLプロセッサがハイパーテキストリンクを認識できるようにするため、'a' タグは xml:link アトリビュートつきで宣言されるべきである。

<!ATTLIST    a    xml:link  CDATA    #FIXED  "simple">

2.3.9 空エレメント

Voyager 文書はXMLで書かれるから、空タグは /> で終わらなければならない。

2.4 処理モデル

Voyager 文書は何段階かで処理される。

  1. キャラクタデータのネットワークエンコーディングをデコードする。これは Unicode キャラクタのストリームとなる。
  2. XML 1.0 に照らしたトークン化。
  3. XML 1.0 に照らして解析する。このステップは、W3C文書オブジェクトモデル(DOM)を経由してアクセスや操作が可能な解析樹を生む。
  4. 文書スキーマに照らした任意的な妥当性検証。
  5. 整形する。このステップは、スタイルシートや、たとえばフォームやアプレットについてHTMLによって規定されたその他の意味論を適用して、整形オブジェクトの階層構造を作り出す。
  6. 整形オブジェクトのレンダリング。

一般的には、ブラウザはこれらのステップを同時並行的に走らせて、データがネットワークから受け取られるにつれて漸増的に文書をレンダリングできるようにする。

2.5 空白の扱い

空白の扱いについての HTML 4.0 の規則は、Voyager ではアトリビュート値へ拡張される。とりわけ、先頭および末尾の空白は引き剥がされ、1つまたはそれ以上の空白キャラクタ(含.改行)の列は、単一の単語間スペース(西洋文字用の ASCII スペースキャラクタ)に割り付けられる。XML 1.0 specification の section 3.3.3 を見ること。

2.6 既存のコンテントを Voyager に変換する

HTML Tidy は、既存のウェブコンテントを Voyager に自動的に変換するための手段を提供するW3Cサンプルコードである。これは、広範囲なマークアップエラーを処理することができ、またHTMLのためにスムーズな移行を実現する助けとなる手段を提供する。

2.7 他のW3Cイニシアティブに対する Voyager の関係

Voyager 仕様書は、現在W3Cで進行中の他のウェブプロジェクト、特に他のXMLベースの仕様書と完全に相互運用可能であることを狙って書かれている。そのモジュラゆえに、コンポーネントベースのアーキテクチャである Voyager は、HTML検証(会員専用)で打ちたてられた目標を満たすために、他のW3Cワーキンググループの作業に大きく依存している。Voyager はウェブパブリッシングのパズルの1ピースにすぎない。明らかに、他のワーキンググループも果たすべき役割を同様に有しているのである。以下のセクションは、キーとなる関連領域のいくつかの輪郭を描く。

ネームスペース
この仕様書は、HTML 4 に基づいた3つのネームスペースを定義する。相互運用性の保証を記述するための基礎として文書プロファイルにネームスペースを結びつけるべく、将来の作業が予定されている。(原文を)書いている時点では、"Namespaces in XML" が勧告提案 (Proposed Recommendation) として W3C会員により検討されているところである。
XMLリンク
HTMLの将来のバージョンは、XMLリンクワーキンググループ(会員専用)によって実行に移されているリンクおよびアドレッシングに関する作業を活用するであろう。
XMLフラグメント
XMLフラグメントワーキンググループ(会員専用)は、XML文書のフラグメントを、それを包み込んでいる文書を送る必要なしに配信できるようにするための方法を開発中である。この機能は、HTMLの将来の利用にとって重要なものになりそうである。
リソース記述言語(RDF)
RDFは、文書プロファイルの基礎として使われることになろう。RDFスキーマ言語は、文書プロファイルを定式化するために使われることになろう。
文書オブジェクトモデル(DOM)
これは、HTML文書へのプログラム的アクセスの基礎を提供する。DOM level 1 はW3C勧告である。
スタイルシート(CSSおよびXSL)
これらは、HTML文書のレンダリングを制御する手段や、文書を変形するための手段を提供する。文書プロファイルは、そのプロファイルに準拠したユーザエージェントについて、どのスタイルシート機能を頼ることができるかを指定するための手段を提供するであろう。
同期化マルチメディア
この領域におけるW3Cの作業は、HTML文書をマルチメディア表現の一部として使えるようにするであろう。
ベクトルグラフィック
スケーラブルベクトルグラフィックワーキンググループ(会員専用)は、HTML文書との統合のためにグラフィックのXMLフォーマットを開発中である。
数学
MathML で書かれた数学的コンテントがHTMLにシームレスに統合できることを保証している。
アクセシビリティ
Web Accessability Initiative は、HTMLコンテントがすべての人にとっててアクセス可能であることを確保するべく作業中である。
国際化
HTML文書がすべての言語の必要に応えるものであるよう保証しようとしている。
ウェブ拡張テレビジョンの放送
ウェブコンテントを組み込んだテレビジョン放送で利用するための文書プロファイルの開発。
ウェブへのモバイルアクセス
モバイルデバイスで利用するための文書プロファイルの開発。

3 互換性ガイドラインのまとめ

3.1 既存のHTMLブラウザ

このセクションは、既存のHTMLブラウザで Voyager 文書をレンダリングしたいと願う制作者のための設計ガイドラインをまとめたものである。

3.2 汎用XMLプロセッサ

HTML特有の意味論を知らない汎用XMLプロセッサで利用するためのHTML文書を制作することには、異なる関心事のセットが関係する。

4 Voyager モジュール

Voyager は、XMLによるHTMLの再定式化だけではない。Voyager はHTMLを、いくつかのタグセットが1つに集合した集合体へとモジュラ化する。これらのタグセットは、制作者がWWW接続性をもった革新的な製品を構築するのに使ってよい組み立てブロックである。もっと重要なのは、これらのタグセットが、コンテントコミュニティにとって設計準拠点として機能することである。

下記に定義されているモジュールは、製品開発者(小さくて柔軟な組み立てブロックを求める)の要求と、コンテント開発者(組み合わせ数の少ない少数の組み立てブロックを求める)の要求とのバランスを取る合理的なモジュールセットを定義する初めての試みである。より強度なサブセット化が要望されるところでは、製品開発者は、コンテントコミュニティに対するフルモジュールサポートと、その配信プラットフォームのためのもっと小さい規定とを提供するサーバベースまたはプロキシベースの変形ソフトウェアを考慮するよう奨励される。

4.1 基礎モジュール

基礎モジュールは、基本的な Voyager データ型や内容モデルを、Voyager プロファイルが組み込まなければならない最小限のエレメントセットとともに規定する。具体的には、基礎モジュールには html, head, title, base, meta, link, body, h1-6, p, br, a, bdo, span, div というエレメントが含まれる。

4.2 移行モジュール

移行モジュールは、HTML 4.0 Transitional プロファイルの中にはあるが HTML 4.0 Strict プロファイルからは除外されているエレメントを規定する。具体的には、移行モジュールは basefont, font, center, s, u というエレメントが含まれる。また border, align, noshade といった表現的アトリビュートの定義も含まれている。

4.3 スタイルモジュール

スタイルモジュールは、style エレメント、style アトリビュートと、スタイルシートをリンクするため html link エレメントの使用とを規定する。

4.4 スクリプトモジュール

スクリプトモジュールは、script, noscript エレメントを規定する。

4.5 フォントモジュール

フォントモジュールは、HTML 4.0 Strict プロファイルの中に見られるフォント関連のエレメントを規定する。tt, b, i, big, small.

4.6 フレーズモジュール

フレーズモジュールは、制作者の意図の上や背後にある領域特有の情報を提供するフレーズエレメントを規定する。具体的には、フレーズモジュールには abbr, acronym, address, blockquote, q, cite, code, dfn, kbd, samp, var というエレメントが含まれる。

4.7 抑揚モジュール

抑揚モジュールは、領域特有の情報を提供するのでなく、制作者の意図のヒントを提供するフレーズエレメントを規定する。具体的には、抑揚モジュールには em, pre, strong, sub, sup, hr というエレメントが含まれる。

4.8 編集モジュール

編集モジュールは、文書編集関連のエレメントを規定する。具体的には、編集モジュールには del, ins というエレメントが含まれる。

4.9 リストモジュール

リストモジュールは、リスト関連のエレメントを規定する。具体的には、リストModule には dl, dt, dd, ul, ol, li というエレメントが含まれる。

4.10 フォームモジュール

フォームモジュールは、HTML 4.0 のフォーム関連のエレメントを規定する。具体的には、フォームモジュールには form, input, textarea, select, optgroup, option, label, button, fieldset, legend, isindex というエレメントが含まれる。

4.11 テーブルモジュール

テーブルモジュールは、テーブル関連のエレメントを規定する。具体的には、テーブルモジュールには table, caption, col, colgroup, thead, tbody, tfoot, tr, th, td というエレメントが含まれる。

4.12 画像モジュール

画像モジュールには img エレメントが含まれる。ローエンドシステムの中には、画像はサポートしてもイメージマップはサポートしないものがある。

4.13 イメージマップモジュール

イメージマップモジュールには、画像モジュールとともに利用する map, area というエレメントが含まれる。

4.14 オブジェクトモジュール

オブジェクトモジュールは、オブジェクト関連のエレメントを規定する。具体的には、オブジェクトモジュールには object, param が含まれる。

4.15 アプレットモジュール

アプレットモジュールには、applet, param というエレメントが含まれており、プロファイルが Java アプレットをサポートするときに使われる。

4.16 フレームモジュール

フレームモジュールは、HTML 4.0 のフレーム関連のエレメントを規定する。具体的には、フレームモジュールには frameset, frame, iframe, noframes エレメントが含まれる。

5 strict, loose, frameset プロファイル用のネームスペース

この仕様書は、HTML 4.0 の strict, transitional, frameset というDTDのそれぞれに対応し、XML 1.0 仕様書に従って再定式化した3つのプロファイルにつき、XMLネームスペースを定義する。

http://www.w3.org/Profiles/voyager-strict
HTML 4.0 strict から変換された文書で使うネームスペース。これらの文書は Voyager strict DTD に準拠しなければならない。
http://www.w3.org/Profiles/voyager-loose
HTML 4.0 transitional(別名 loose)から変換された文書のためのネームスペース。HTML 4.0 transitional は多数の表現的エレメントおよびアトリビュートを組み込んでいる。これらの文書は Voyager loose DTD に準拠しなければならない。
http://www.w3.org/Profiles/voyager-frameset
HTML 4.0 frameset から変換された文書のためのネームスペース。HTML 4.0 frameset は、フレームセットとして機能する文書のために使われる。これらの文書は Voyager frameset DTD に準拠しなければならない。

Voyager 文書型定義および関連規則 によって定義された文書は、この仕様書の規範的部分を構成する。これは、文書型宣言を除いて仕様書を印字したい人々の便宜のため別ファイルに置かれている。

6 謝辞

HTMLワーキンググループ議長
Steven Pemberton <steven.pemberton@cwi.nl>, CWI
協力者:
Daniel Austin, CNET
John Burger, Mitre
Angus Davis, Netscape
Andrew Donho, IBM
Jon Gnaegy, Apple
Klaus Hofrichter, GMD
Philipp Hoschka, W3C
Masayasu Ishikawa, W3C
Peter King, Unwired Planet
Paula Klante, Jet Form
Kenneth Lee, Citibank
Shin'ichi Matsui, Panasonic
Shane McCarron, Open Group
Ann Navarro, HTML Writers Guild, Inc.
Zach Nies, Quark
Robert Pernett, Lotus
Patrick Schmitz, Microsoft
Robert Sutor, IBM
Chris Wilson, Microsoft
Dan Zigmond, WebTV
Warner ten Kate, Philips

7 参照資料

HTML 4.0
HTML 4.0 Specification 18 December 1997, revised 24 April 1998. Dave Raggett, Arnaud Le Hors, Ian Jacobs. これは http://www.w3.org/TR/REC-html40 で入手可能である。
XML 1.0
Extensible Markup Language (XML) 1.0 Specification 10 February 1998, Tim Bray, Jean Paoli, C. M. Sperberg-McQueen. これは http://www.w3.org/TR/REC-xml で入手可能である。[拙訳あり]
CSS2
Cascading Style Sheets, level 2 (CSS2) Specification 12 May 1998, Bert Bos, Håkon Wium Lie, Chris Lilley, Ian Jacobs. これは http://www.w3.org/TR/REC-CSS2 で入手可能である。
Associating stylesheets with XML documents
XMLスタイルシートのターゲットをもつ1つ以上の処理命令を文書のプロローグ部に組み込むことにより、スタイルシートをXML文書に結びつける方法を解説する。これは http://www.w3.org/TR/WD-xml-stylesheet で入手可能である。(訳者註:現在は勧告提案 (Proposed Recommendation) が出ている。http://www.w3.org/TR/PR-xml-stylesheet [拙訳あり]で入手可能である。)
Namespaces in XML
XMLネームスペースは、XML文書の中で使われている名前を、URIで特定されるネームスペースと結びつけることにより修飾するための単純な手段を提供する。(原文を)書いている時点では、この作業は勧告提案 (Proposed Recommendation) 状態にあり、http://www.w3.org/TR/PR-xml-names で見ることができる。(訳者註:現在は勧告 (Recommendation) が出ている。http://www.w3.org/TR/REC-xml-names[拙訳あり]で入手可能である。)
XML Linking Language (XLink)
オブジェクト間のリンクを記述するためにXMLリソースに挿入してよい構造物を仕様化する。これはXML文法を使って、今日のHTMLの単純な一方通行的ハイパーリンクだけでなく、より洗練された複数端のタイプづけされたリンクも記述できる構造物を作成するものである。これは http://www.w3.org/TR/WD-xlink で入手可能である。[拙訳あり]
DOM Level 1
Document Object Model (DOM) Level 1 Specification, Vidur Apparao, et al. これは http://www.w3.org/TR/REC-DOM-Level-1 で入手可能である。[拙訳あり]
URI (Web addresses, including URLs and URNs)
"RFC2396: Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, L. Masinter, August 1998. これは RFC1738 および RFC1808 に代わるものである。http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2396.txt で利用可能。
HTML Tidy
これは、HTMLで蔓延している広い範囲のマークアップエラーを探知して訂正するためのツールである。これは既存のHTMコンテントを整形式のXMLになるよう変換するためのツールとしても使うことができる。Tidy は、その他のW3Cサンプルコードと同じ約款、すなわち完全に自分自身のリスクにおいて目的を問わず無料で利用可能にされている。
Composite Capability/Preference Profiles (CC/PP): A user side framework for content negotiation
RDFを使って、ユーザ選好やデバイス機能を記述するための一般的でありなお拡張可能な枠組みを作成する方法を解説する。サーバは、これを活用して、提供されているサービスやコンテントをカスタマイズすることができる。この文書は http://www.w3.org/TR/NOTE-CCPP/ で利用可能である。

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