お客様が developerWorks に初めてサインインすると、プロフィールが作成されます。プロフィールで選択した情報は公開されますが、いつでもその情報を編集できます。お客様の姓名（非表示設定にしていない限り）とディスプレイ・ネームは、投稿するコンテンツと一緒に表示されます。

送信されたすべての情報は安全です。

developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

送信されたすべての情報は安全です。

My developerWorks：

通知：

サイン・アウト

言語を選択する：

XHTML 2 を今すぐ使う

ブラウザーはまだ次のバージョンの XHTML を処理できなくても、リッチなコンテンツ構造の利点は今でも活用できます

Bob DuCharme (bob@snee.com), Solutions Architect, UDICo

Bob DuCharme は Innodata Isogen のソリューション・アーキテクトであり、XML が禁句であった頃には XML の「エキスパート」でした。彼は情報技術に関して 4 冊の本と100 本近くのオンライン記事や印刷記事を書いていますが、そのどれにも「機能性 (functionality)」という単語を使っていません。詳しくは http://www.snee.com/bob をご覧ください。

概要： XHTML 2 仕様はまだ完成していませんが、既に XHTML 1 よりも優れた点を数多く持っています。例えば、さまざまな構造を取り得るようになったため、単一ソースのパブリッシング・システムの中心スキーマとしての役割を担う編集フォーマットとして、XHTML 1 よりも実用的です。XHTML 2 の新しいユーザー・インターフェース機能をブラウザーがサポートするまで待たなくても、大規模な、あるいは小規模なパブリッシング作業を行うために、これらの機能を今からでも使い始めることができます。

タグを付ける!

日付: 2007年 6月 12日
レベル: 初級
この記事の原文: 英語
アクティビティー： 3235 ビュー
お気軽にご意見・ご感想をお寄せください：

1 年ほど前、ある業界標準化団体が私に対して、XHTML 2 がいかにパブリッシャーにとって有用かに関してのプレゼンテーションを依頼してきました。当時の私は XHTML 2 が有用かどうかわからなかったのですが、彼らはニューヨークまでの旅費を払ってくれるというので、私は XHTML 2 について調べてみることにしました。

しかし、あまり詳しく調べる必要はありませんでした。XHTML 2 は XHTML の構造を非常に高度なレベルに高めているため、単にブラウザーにコンテンツを提供するためのフォーマットであるにとどまらず、コンテンツを作成して保存するためのフォーマットとして実用的なのです。ただし、XHTML 2 は既に使用可能なレベルにあると言ってしまうと、少し誇張していることになります。多くの企業では、(妥当なポリシーとして) 未完成の標準を使うことに反対するものです。しかも XHTML 2 はまだワーキング・ドラフトの状態にすぎません (詳しくは「参考文献」を参照してください)。ただし XHTML 2 は、ほとんどすべての HTML 関連の標準とは異なり、有名なブラウザーがサポートするよりもはるかに前から、多大な価値をもたらしているのです。なぜなら XHTML 2 では、多くの人におなじみの HTML 要素や属性から大きく変わることなく、リッチで高度な構造を持つコンテンツを保存できるという、より大きな可能性があるのです。

XHTML の現状

W3C の XHTML 1.0 標準 (「参考文献」を参照) によって、HTML の XML 版が作られました。ブラウザーは Web ページが整形式の XML かどうかを気にしませんが、Web サイトの設計者は Firefox と Microsoft™ Internet Explorer とで方法を変えることにうんざりしているため、標準に大きな価値を見出しています。Open Web Design や Open Source Web Design (どちらも「参考文献」にリンクがあります) など、オープンソースの CSS のコレクションに用意されたスタイルシートの多くは、デモ用に XHTML 1 のサンプル・ファイルを使っており、整形式の意味をほとんど理解していない Web デザイナーは、彼らのサイトが XHTML に基づいていると誇らしげに主張する、という話を私は聞いたことがあります。Internet Explorer と Firefox が CSS の機能をより多くサポートするようになるにつれ、こうした Web デザイナーは彼らのデザイン作業の大部分を CSS スタイルシートに移行し、その結果彼らのベース文書には、より簡潔で単純な (そしてより容易に再利用が可能な) XHTML が残るようになっています。

XHTML 1.1 (「参考文献」を参照) は何も新しい機能を追加していませんが、XHTML をモジュールに分割しています。これは 2 つの理由から重要なことでした。第 1 に、(他のモジュールではなく) そのモジュールに価値があると思ったときに、そのサブセットを容易に採用することができます。例えば、WAP (Wireless Application Forum) は、携帯電話にコンテンツを提供するために、彼らの標準に基本的な XHTML 構造を取り入れることは大歓迎でした。しかし携帯電話の小さな画面では無意味な、画像マップや編集モジュール機能などのユーザー・インターフェース機能を WAP 文書に取り入れることは望みませんでした。

DTD あるいはスキーマがモジュール構造を持つことによる、もう 1 つの利点は、独自アプリケーション専用の新しいモジュールを容易にプラグインできることです。既存のモジュールから適当なものを選択できる機能と組み合わせると、この機能は既にパブリッシング業界にメリットをもたらしています。そのメリットとは、パブリッシング業界のメタデータのための PRISM 標準化グループが XHTML 1.1 のサブセットを選択し、パブリッシングのワークフローの中でのコンテンツ追跡を容易にするための業界専用のボキャブラリーを持つ、新しいモジュールを追加したことです。(PRISM について詳しくは「参考文献」を参照してください)。

XHTML 1.1 の開発は、家の地下室の機能を整理することに似ているかもしれません。つまり、多くのものを捨てなくても、整理整頓することで置いてあるものを容易に使えるようになり、さらには新しいものを作るための作業台を作る余地まで得られるかもしれません。

XHTML 1.1 は、2001年5月から、標準 (W3C の用語では勧告) となっています。XHTML 2.0 の最新版は、2006年7月の新しいワーキング・ドラフトです。このドラフトは、まださらに何段階かを経る必要がありますが、現在入手可能な RELAX NG スキーマ (リンクは「参考文献」を参照) を使うと、今でも XHTML 2 文書を作成して使用することができ、この仕様が勧告になった時に XHTML への移行を速やかに行うことができます。また簡単な XSLT スタイルシートを使うと、これらのファイルを XHTML 1 に変換してブラウザーに表示することができます。あるいは、現在 XHTML 2 のワーキング・ドラフト (「参考文献」を参照) に含まれている CSS スタイルシートを使って、これらの文書をブラウザーに表示することもできます。(現状では Firefox の方が適切に表示できるようです。)

上に戻る

XHTML 2 は何が新しいのか

XHTML 2 は XHTML 1 の作業の継続として、既存の構文を整理して単純にしており、また新しい機能を追加しています。そして HTML で 10 年以上使われているフォームをより進化させて後継とした XForms のサポートを追加しています。また XHTML 2 には、XML Events も含まれています。XML Events を利用すると、イベントを特定してある種のユーザー・インターフェース・アクションをトリガーできるため、JavaScript あるいは ASP を使うスクリプトを作成する必要が少なくなります。こうした機能は、主要なブラウザーがサポートするようになると特に興味深い機能なのですが、ブラウザーが XHTML 2 をサポートする前であってもコンテンツを公開しようとする人達にとっては、他にも次のような興味深い機能があります。

リッチで再利用しやすい構造
機器への非依存性とアクセシビリティー、そしてセマンティクス
メタデータの追加しやすさ

上に戻る

リッチな構造

コンテンツを XML で保存している多くのパブリッシャーは、独自のスキーマをゼロから作るよりも、既存の標準スキーマ (ここでは W3C Schema や RELAX NG スキーマ、あるいは DTD を指します) を使った方が良いことを昔から知っていました。彼らは DocBook を調べて複雑すぎることに気付き、HTML あるいは XHTML 1 を調べて単純過ぎることに気付きました。彼らの多くにとって、XHTML 2 は DocBook のリッチさと XHTML 1 の単純さの間にあって最適な複雑さになっており、さまざまな媒体での配布用にコンテンツを他のフォーマットに変換する必要があるか否かによらず、コンテンツの保存に最適のフォーマットなのです。

リスト 1 は XHTML 1 のサンプル・ファイルを含んでおり、その構造は字下げで表現されています。

リスト 1. XHTML 1 ファイルの構造

                                
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>My Web page</title>
  </head>
  <body>
    <h1>My Web Page</h1>
    <p>Here is my Web page.</p>
    <h2>Section 1 of my Web page</h2>
    <p>Here is section 1 my Web page.</p>
    <h3>Section 1.1 of my Web page</h3>
    <p>Here is a subsection of my Web page.</p>
    <h2>Section 2 of my Web page</h2>
    <p>Here is section 2 of my Web page.</p>
  </body>
</html>

body 要素の中には字下げがほとんどありません。これは、そこにほとんど構造がないためです。この文書をツリーで表現すると、body 要素は多くの子を持ちますが孫は持たないとして表示され、また「Here is a subsection of my Web page」という段落は、メインの h1 タイトル「My Web Page」の兄弟として表示されます。この段落がサブセクションの一部であることがマークアップからわかるための唯一の手掛かりは、この段落の前にあってかつ最も近くにあるヘッダー h3 が、その前のヘッダーよりも大きな数字を持っている、という事実のみです。h1 ヘッダーと Web ページの他の表示可能コンテンツを囲む body 要素を数えないかぎり、コンテンツのタイトルとなっているヘッダーをグループ分けするコンテナー要素はありません。ヘッダーとコンテンツの組み合わせごとに、その前後を div 要素で囲むことはできますが、div は span 要素と同じく非常に一般的なグループ要素です。div の用途は広く、例えば、ある段落がメニューや囲み記事を形成することを示したり、あるいは Web ページ上の別の視覚表示要素を形成することを示したりします。そのため、div があることでコンテンツの構造単位であることがわかる、ということにはなりません。

XHTML 2 の新しい section 要素と h 要素を組み合わせると、コンテンツを容易に再利用できる、リッチな構造を作成することができます。リスト 2 は、リスト 1 の body 要素に等価な XHTML 2 を示しています。

リスト 2. XHTML 2 の body 要素

                                
<body>
  <section>
    <h>My Web Page</h>
    <p>Here is my Web page.</p>
    <section>                      
      <h>Section 1 of my Web page</h>
      <p>Here is section 1 my Web page.</p>
      <section>
        <h>Section 1.1 of my Web page</h>
        <p>Here is a subsection of my Web page.</p>
      </section>
    </section>
    <section>
      <h>Section 2 of my Web page</h>
      <p>Here is section 2 of my Web page.</p>
    </section>
  </section>
</body>

このバージョンでは、「Here is a subsection」という段落は、メイン・タイトルを示す「My Web Page」という h 要素を持つ section 要素のひ孫になっています。本来こうあるべきなのです。

このリッチな構造の利点の 1 つは、ストリーム処理が容易なことです (これは単一ソースの公開システムのための中心フォーマットとして、XHTML 2 が XHTML 1 よりも有望な候補である重要な理由でもあります)。処理すべき入力が大量すぎ、処理前にすべてをメモリーにロードできない場合 (例えば CD-ROM 用のコンテンツを準備する場合など)、XHTML 2 文書では、プロセスは各セクションがどこで終わるのかを容易に判断することができます。例えば、タイトルに「Beagle (ビーグル犬)」という単語を持つ、すべてのセクションを抽出したい場合を考えてみてください。これらのタイトルを見つけるのは非常に簡単ですが、そのセクションがどこで終わるのかを判断しようとすると、XHTML 1では非常に困難です。この XHTML をストリーム・ベースのインターフェースで処理するにせよ、あるいは XQuery や XSLT で処理するにせよ、セクションの終わる境界が明確であることによって、抽出はずっと容易になります。

今度は、ビーグル犬に関する新しい公開資料に追加するために、こうしたセクションを抽出したと考えてみてください。抽出するすべてのセクションは、ヘッダーとして h3 要素を持っています。XHTML 1 での番号付きヘッダー (h3 など) は XHTML 2 でも有効ですが、もし新しい公開資料が、こうした要素をメイン・セクションとして、あるいは特定の章のサブセクションとして使うとしたらどうでしょう。h3 要素をそのまま使うことはできず、h3 要素を h2 要素、あるいは h4 要素に変更したり、あるいは新しいコンテキストでの役割を示す何らかの要素に変更したりする必要があります。もしこれらの要素がオリジナルの文書で XHTML 2 の h 要素であり、階層構造の中での役割が、それぞれの要素が持つ section 祖先要素の番号によって示されたとすれば (例えば上のリスト 2 で、section 1.1 の h 要素は 3 つの section ヘッダー祖先を持っていますが、「My Web Page」の h 要素は 1 つしか持っていません)、これらの要素を何も変更せずに新しい文書に挿入することができ、それぞれの要素の役割は新しい文書の section 要素のネストによる配置によって示されることになります。CSS や XSLT、その他の XML 処理ツールや XML 標準はすべて、同じ名前を持つ要素をネスト・レベルに応じて別々に扱うための方法を提供しています。そのため、XHTML 1 のヘッダーの一部であった番号をそのまま使えます。h2 要素と h3 要素があっても h1 要素がない、あるいは h1 要素と h3 要素があっても h2 要素がない、といった (X)HTML 文書が既に多数あることを考えると、こうした要素を適切な階層構造を示すために使う人が少ないのは明らかです。

p 要素も、XHTML 2 では多くの構造を持つことができます。例えば、文の真ん中にサンプル・コードを挿入したい場合を考えてみてください。例えば次のような場合です。

print "Hello? World?";

もしサンプル・コードの後に文を続けようとすると、XHTML 1 は、2 つに分割された文のそれぞれを強制的に 2 つの別々のp 要素の中に置きます。そうするとセマンティクス上は両方とも同じ段落にあることになっていまします。一方 XHTML 2 では、サンプル・コードや、箇条書きリストや番号付きリスト、その他多くのブロック要素を p 要素の中に置くことができ、マークアップは文書の構造をより正確に反映することができます。

また、表示マークアップから構造マークアップへの小さな一歩として、hr 要素が separator と名前が変更されています。HTML ワーキング・グループは、hr の元々の名前 (horizontal rule: 横罫線) が構造マークアップと表示マークアップのどちらに属するとも言えないことに気付きました。彼らは一部のアジア系言語で作成している人達から vertical rule (縦罫線) が必要だという要求を受けており、また実際には罫線ではない横方向の区切り線 (separator) が数多く使用されていることにも気付いていました (HTML ワーキング・グループの議長である Steven Pemberton が、スライドによるプレゼンテーションの中で、James Joyce による Ulysses では hr がいくつか異なる使われ方をしていることを指摘しています。「参考文献」のリンクを参照してください)。こうしたことから、hr 要素の名前を変更し、使い方を正確に反映して柔軟に表示できるようにしたのです。

上に戻る

機器に対する非依存性とアクセシビリティー、そしてセマンティクス

これらの 3 つの目標は、お互いに重なる部分があります。音声合成ソフトでの読み上げに適した Web ページは 1 つのプラットフォームでの提供に限定されない Web ページであり、視覚障害者が容易に理解できる Web ページでもあります。XHTML 2 のワーキング・ドラフトには、次のような記述があります。

電話や PDA、タブレット、テレビなど、新しい機器が次々にオンライン化されているという事実は、機器のタイプごとに新しいバージョンの文書を作成するのではなく、1 度の作成で、さまざまな機器でさまざまな方法で表現できるような文書設計が必須であることを意味しています。

パブリッシャーは、この価値を理解するために将来を見る必要はありません。機器に対する非依存性こそ、XML が発明される前に多くのパブリッシャーが SGML に引きつけられた大きな理由です。SGML を使うことで、同じコンテンツを印刷でも Web ページでも、そして CD-ROM でも公開することができます。そのために必要なことは、そのコンテンツの編集用のバージョンが十分に構造化され、セマンティクスの情報を持った上で保存でき、自動ルーチンで各フォーマットに変換できることだけです。私は11 年前、当時私が勤務していたオフィスで、私達の競合が彼らのコンテンツの編集バージョンを HTML で保存していると聞いた時、鼻で笑ったことを覚えています。しかし XHTML 2 では、これはそれほど気違いじみた考えではありません。

XHTML 2 の要素の既存のセマンティクスでは十分ではない場合には、新たな属性 role (この属性は、ほとんどあらゆる要素に付加することができます) を使って、その要素の目的に関してより多くのことをを表現することができます。XHTML 2 の仕様では、この属性の取り得る値として、9 種類を指定しています (banner と note、contentinfo、search、definition、secondary、main、seealso、そして navigation)。role の値として banner や navigation は明らかに表示用ですが、definition や note などの値は複数の媒体用にコンテンツを用意するパブリッシング環境に便利なセマンティクスを持っています。また (独自の名前空間にあるのであれば)、独自の role 値を作り出すこともできます。

上に戻る

メタデータの追加しやすさ

W3C の RDF 標準では、URL で識別可能なすべてのものに対してメタデータを割り当てることができます。このための標準 RDF/XML 構文は 1999年から存在していますが、複雑で難しいため、多くの人は恐れて使いません。XHTML 2 では、既存の XHTML 属性を使い、またいくつかの新しい属性を追加することで、識別用に about 属性を持つ文書と文書コンポーネントに関するメタデータを、新しい単純な RDFa 構文を使って追加することができます。リスト 3 に示すいくつかの例では、RDF メタデータを表現するために使われる主語と述語と目的語のトリプル (目的語 ID 属性と名前属性と値のトリプルの方が考えやすいかもしれません) を埋め込むために必要な追加情報を、span 要素が保存しています。

リスト 3. span 要素でメタデータをエンコーディングする

                                
<section>
  <span property="dc:subject" content="recipe"/>
  <span property="fb:workflowStage" content="3a"/>

  <h><span property="dc:title">
Carrion, My Wayward Son
</span></h>
  <p><span property="dc:date" content="2007-05-15" datatype="xs:date>
May 15, 2007
</span></p>
</section>
</blockcode>
</section>

リスト 3 の RDFa マークアップは主語に名前を付けるための about 属性を使っていないので、RDFa プロセッサーは、この文書自体が各トリプルの主語であると見なします。これこそ私達が求めているものです。つまりトリプルが文書自体に関するメタデータなのです。

接頭辞 dc が Dublin Core 名前空間 http://purl.org/dc/elements/1.1/ を表すように宣言されており、また fb が架空の FooBar Company の http://www.foobarco.com/ns/vocab# という名前空間を表しているとすると、リスト 3 の RDFa マークアップは (RDF トリプルのデータベースから抽出し、またこのデータベースへロードできる形式で) 下記を表現しています。

この文書は Dublin Core の主語「recipe」を持っています。
この文書は「3a」の値として workflowStage (この文書を作成した会社のメタデータを少しカスタマイズしたもの) を持っています。
この文書は Dublin Core のタイトル「Carrion, My Wayward Son」を持っています。この記述の場合、メタデータの値、つまりトリプルの目的語は実際の Web ページの一部であり、他の span 要素の場合と同じように、content 属性の中には保存されません。別の目的語を指定する必要がなく、そして文書自体が主語として動作するため、ここにあるのは、1 つの属性のみを持つ span 要素を使って文書に追加された便利なメタデータ・トリプルということになります。
この文書の公開日は 2007年5月15日です。実際に保存される値は ISO 8601 標準フォーマットの 2007-05-15 です。この文書はデータ型の情報まで含んでおり、データ型は W3C Schema データ型です (「参考文献」を参照)。

セマンティック Web は大きな夢として、Web ページのデータを 2 つの目的に使おうとしています。つまり人間が読み取るために公開するコンテンツとして、そしてデータベースからプログラムが読み取るデータとして使うのです。これはリスト 3 の dc:title の例にある通りです。fb:workflowStage の例は、RDFa にはもう 1 つ利点があることを示しています。つまり XHTML 2 文書には、企業独自のやり方に特化した、本当に任意のメタデータを追加することができるのです。これによって文書の追跡や再利用が容易になります。

上に戻る

XHTML 2 を今すぐ使う

XHTML 2 の新しいユーザー・インターフェース機能 (例えば XML Events など) を使うためには、やはり少し待つ必要があります。しかし XHTML 2 の新しい構造上の機能を試すために今必要なものは、既に皆さんの手元にあります。まだ仕様は完成していないため不確定要素はありますが、そうした要素は少なくなりつつあります。また、現在使用できるスキーマや CSS スタイルシートを使うことで、皆さんのオペレーションにとってどのような点でメリットがあるのかを試し、検討することができます。実際私はこの記事を書くために、 Emacs の nXML モード (「参考文献」を参照) を使い、XHTML 2 の RELAX NG スキーマによる、コンテキストを理解する XML 編集機能を活用しました。そして記事を提出する前に、developerWorks の DTD に準拠するように、簡単な XSLT スタイルシートを使って記事を変換したのです。XHTML 2 が標準としての勧告になるまでに、私は XHTML 2 を完全に使いこなそうと思っています。

参考文献

学ぶために

XHTML 2 に関する基本的な情報源に用意された、XHTML 2.0 technical report を見てください。ワーキング・ドラフトから勧告に至るまでの進行状況を知ることができます。
XHTML 2 のワーキング・ドラフトに含まれている CSS stylesheet を見てください。
XHTML 1.0 Recommendation を見てください。これは W3C が XML 1.0 の応用として HTML 4 を再構成したものであり、また HTML 4 で定義された DTD に対応する 3 つの DTD も、ここで見ることができます。
W3C の XHTML 1.1 Recommendation では、拡張されたXHTML ファミリーの将来の文書型の基礎となる、新しい XHTML 文書型を見ることができます。
「The Web's future: XHTML 2.0」(Nicholas Chase 著、developerWorks、2002年9月) を読んでください。初期の段階で XHTML 2.0 を調べており、これを将来どう使うべきかを解説しています。
2 回シリーズの第 2 回目の記事「HTML の将来、パート 2：XHTML 2.0」(Edd Dumbill 著、developerWorks、2006年1月) を読んでください。XML 2.0 の多くの機能を解説しながら HTML の将来を解説しています。
Chris Herboth 著による developerWorks の 3 回シリーズ「XForms 入門」(2006年9月から) を読んでください。
- 「第 1 回: フォームのための新しい Web 標準」は、XForms の実際の動作と、XForms のサンプルを表示するために Firefox と Microsoft Internet Explorer で XForms を設定する方法を解説しています。
- 「第 2 回: フォーム、モデル、コントロール、そして送信アクション」は、さまざまなコントロールを使った XForms ベースのフォームの作成や、データ・モデルの作成に焦点を当てています。
- 「第 3 回: アクションとイベントを使う」は、XForms でのアクションとイベントの使い方と、フォームの出力フォーマットのコントロール方法を解説しています。
W3C XForms Recommendation を見てください。XForms が機器に依存せず、スクリプトが削減されることから、コンテンツから表示を分離でき、再利用や強い型付けが可能になり、またサーバーへの往復回数が低減されることを知ることができます。
「XHTML2: Accessible, usable, device independent and semantic」は、HTML ワーキング・グループの議長 Steven Pemberton と XHTML 2.0 補助仕様のエディター Mark Birbeck による 2005 年のスライドショーであり、XHTML 2 の概要を非常に適切に解説しています。
XML Schema Part 2 を見てください。この W3C 勧告は、RDF や他の標準で使われているデータ型に関する詳しい情報を提供しています。
Open Web Design と Open Source Web Design はオープンソースの CSS のコレクションです。使い方を示した XHTML 1 サンプル・ファイルを含め、数多くのスタイルシートが用意されています。
Wireless Application Forum には、仕様や公開資料、DTD、スキーマなどが豊富に用意されています。
パブリッシング業界のメタデータのための標準化グループ、PRISM について学んでください。
XML および関連技術において IBM 認証開発者になる方法については、IBM XML certification を参照してください。
developerWorks の XML ゾーンは XML の技術ライブラリーとして、広範な話題を網羅した技術記事やヒント、チュートリアル、技術標準、IBM レッドブックなどを用意しています。
developerWorks technical events and webcasts で最新情報を入手してください。
Technology bookstore には、この記事や他の技術的な話題に関する本が豊富に取り揃えられています。