XHTML 2.0の目的と今後のXHTML

先週開かれたW3C TPAC Weekというイベントにて、XHTML 2ワーキンググループおよび、HTMLワーキンググループの部会に出席してきました。今回は、XHTML 2.0の現在のWebとの関わり、および今後について、部会で得た情報をもとに考えてみます。

XHTML 2ワーキンググループが考えるHTMLとは、その名の通り「文書をマークアップするための言語」です。文書マークアップのベースとしてXHTMLを用い、足りない機能の追加はモジュールを定義したり、SVGのような他のXMLフォーマットを取り込むアプローチをとっています。

XMLの持つ拡張性と、XHTMLの汎用性を組み合わせることで、文書そのものをアプリケーション側の処理（表示やコントロールの追加など）を分け、持続可能な文書フォーマットとしてXHTMLを利用することが可能です。eBayやTIMEでは既にXHTML 2.0を利用しているという話もあり、文書を何らかの電子データとして保存する場合において、XHTMLはその有用性を発揮できそうだと感じました。

一方、現在のWebという場面において、XHTMLが持つモジュール化やXMLという特性、またアプリケーションの実装から完全に独立した仕様は、なかなか機能しにくいのではないかと考えるようになりました。

ひとつは、XMLとして処理できない、不完全なXHTMLが非常に多いこと。7月に「XHTMLを採用したWebサイトが全体の2割」とお伝えしましたが、文書型にXHTMLを採用していてもValidや整形式ではないHTML文書がほとんどであるというコメントが、調査を行なったIan Hicksonからその後なされています。MIME型がtext/htmlで送出されたXHTML文書は、たとえ整形式ではなくてもブラウザがHTMLと同じように処理してしまうため、このようなエラーを持ったXHTML文書がはびこっているのです。

また、エラーが見つかったらそこで処理をストップするXMLのパース処理が、ユーザーに対して適切なものであるのかという疑問もあります。計算処理やデータの厳密性がさほど求められず、人が読む文書フォーマットにおいては、構文のエラーを受け止め処理してくれるHTMLのようなフォーマットが望ましいのではないかと感じます。

もうひとつは、現在のWebアプリケーションやWebサイトは、アプリケーション個々の実装にかなり依存したものとなっています。このような状態において、仕様の実装要件が事細かに決められていない場合、また既にある実装との互換性や相互運用性を取る必要がある場合は、実装と仕様を完全に分離することが難しいのではないか、または仕様で細かい実装要件が規定されない場合が多いのではないかという懸念があります。

また、他のXMLを取り入れた拡張性の確保に関しても、取り入れたい言語の実装度合いが異なれば、それをWebにて「使う」ことは難しいでしょう。ある程度のまとまりを各ベンダがいっせいに実装しなければ、普及は難しいのではないかと考えています。

部会の中で、XHTML 2.0はそのレンダリングに注視しないという発言もあったことから、今後の流れとしては、よりXMLを生かせる環境においての展開を考えている印象を受けました。フロントエンドでのXHTMLは、現在のXHTML 1.0に加え、HTML 5のXML構文がこの流れを引き継ぐものと考えられます。