HTML5.JP

Ads

W3C - Architectural vision for HTML/XHTML2/Forms Chartering 日本語訳

一部、直訳ではなく意訳した部分がございます。原文と表現が異なることがございますので、ご了承ください。この日本語訳は、私が理解を深めるために、自分なりに日本語化したものです。本日本語訳には、翻訳上の誤りがある可能性があります。したがって、内容について一切保証をするものではありません。正確さを求める場合には、必ず原文を参照してください。当方は、この文書によって利用者が被るいかなる損害の責任を負いません。もし誤りなどを見つけたら、当サイトのお問い合わせより連絡いただければ幸いです。

概要

この文書は、W3Cが今後HTMLをどういう方向性で策定を進めていくのかという方針をまとめたものです。

原文の最終更新日は2007/03/07となっていましたが、時期を察するに、HTML5を意識したものと推測されます。同日にW3Cから「HTML標準の更新に着手」という報道発表がありました。もともとW3CはHTMLというものをすべてXMLをベースとした拡張可能な整形式文書にするビジョンを持っていました。現状では、そのビジョンに沿った最新の仕様はXHTML 2.0です(2007/08/05現在)。しかし、実際には期待したほどXHTMLは世の中に浸透しませんでした。

そのような状況下で、WHATWGからWeb Apps 1.0がHTML5として提案されました。これは、HTML4からの拡張、そして後方互換性を重視する意味合いが強く、XHTML 2.0という方向性とは完全に一致しませんでした。しかし、W3Cは報道発表の通り、新たなHTML標準の更新を検討しはじめました。これは、W3Cの方向転換とも捉えられかねません。このような混乱を避けるべく、W3CとしてのHTMLの今後の方向性の見解を説明したものと考えられます。報道発表や本ドキュメントではWeb AppsやHTML5という具体的な用語は一切使われいません。最終的にXHTMLとHTMLはどうなるのかという核心までは触れられておらず、非常にあいまいな状態ですが、HTMLの今後の行方を占うにも、貴重な情報といえるでしょう。

原文ではタグスープ(tag soup)という用語が使われています。主に、HTML構造とセマンティクスのルールを考慮せずに書かれたHTMLコードのこと表し、文書の情報がタグに埋もれてしまっている様を皮肉った意味として使われます。

Wikipedia - Tag soup

日本語訳

Architectural vision for HTML/XHTML2/Forms Chartering

HTML関連作業のre-charteringにまつわる議論は広範囲に及びます。便利な要約のために、この文書では、これらのグループのcharteringの背後にある全体的なアーキテクチャの展望を、そして、それらが相互作用の領域と全体的なウェブアーキテクチャのより広範囲なパターンにどのように適合するのかを論じます。

コミュニティが提議しているアーキテクチャの方向性は、多くのアドバイス提供の結果であり、そして、新しい活動にかかわる皆さんは、現状と他人の要求に適応しなければいけないでしょう。この作業のいたるところに強い共通の要素があり、ユーザとウェブデザイナ側にある深刻なニーズ、この場を改善する重要な機会がみなさんにあるのです。

XMLベースのアーキテクチャとタグスープ

W3Cは、XMLが進むべき正しい方向であり、実装はいずれ必要に応じて一致すると考えてきました。モバイル市場や、SMIL、SVG、MathML、Timed-Textなどの非HTMLクライアント技術では、実際にそうなってきました。しかし、デスクトップブラウザ市場では、われわれが期待し望んできた以上に長くタグスープ・マークアップが存続してきました。その結果、"タグスープ"HTMLがいつまでも存続することがウェブの健全なアーキテクチャと調和するのかどうかを検討するために、TAGのissue TagSoupIntegration-54: Tag soup integrationが開設されました。

そんな状況はあり得ないと偽ることを受け入れなければ、その状況に近づくいくつかの方法があります。

  1. ユーザと実装者に現存のXHTML 1.xのより一層な適用を強制してみる。要するに、これは以前の戦略だが、いくつかの欠点がある。:

    1. Appendix C of XHTML 1.0は、そのようなコンテンツがレガシーユーザエージェントに送られることを許しているので、ユーザはコンテンツが整形式でなくても一切警告を受けない。それゆえに、非整形式コンテンツがまん延する。ユーザエージェントは、XHTML 1.xは整形式でないと仮定するか、XML宣言やStrict doctypeのような指標を探ることから始める。

    2. XHTML 1.0は新たな機能が追加されず、XHTML 1.1ではルビしか追加されなかったため、ユーザにとってXMLベースへ移行する動機が小さい。整形式コンテンツを製作することの理論的な満足を超えてまで、そうするメリットがないのである。

  2. 別のメディアタイプで、拡張性、アクセシビリティを向上し、豊富なセマンティクスを持つ新しい言語を作る。この新しいフォーマットを理解できない旧来のユーザエージェントは、それをリクエストすることはないし、それを拒絶しないだろう。これはXHTML 2.0の戦略だった。

    残念ながら、これもまた欠陥がある。XHTML 2.0がオーサリング(例えば、デバイスに特化したオーサリング)に、そして企業(XFormsのサポートは役に立ち、クライアントの選択をコントロールできる)において採用された。しかし、それは旧来のブラウザベンダの中では成功とは言い難く、それを推進するような新しいブラウザベンダも現れなかった。そのため、クライアント側の利用は小規模にとどまり、これが参入障壁となっている。このアプローチはさらに長い期間をかければ成功するかもしれない。しかし、現段階では、十分な牽引力とはならないようだ。

  3. 独立しているが、これまでとは違う聴衆用の関連言語を作る。これは単一言語に関連する明らかな欠陥がある。XMLが共通の解析モデルを形成するなら、まだ特別に検討する余地がある。

    まずデスクトップ指向そして消費者志向の言語用に、タグスープのシリアライゼーションだけを持たせることはできたであろう。しかし、それは間違いなく、ウェブアーキテクチャに否定的で分裂的な作用が生じただろう。XMLに余計な非互換性は極力避けるべきである。

    代わりに、単一のDOM(またはinfoset:タグスープは今のところinfosetを持つことを考慮することはできないが、DOMを持つことはできる)に対応した2つの同等なシリアライゼーションをHTML WGで開発するよう要請する。これであれば間違いなくXMLシリアライゼーションを排除するという決定がなされることはない。それは、2つのシリアライゼーションが自動的に内部変換されることを許す。新たな言語機能を持つことで、コンテンツ作者にそれを使う動機が生まれる。そして、クライアント側の実装は、それを本当に使う可能性があることを意味する。

これらのうち、W3Cは3つ目のアプローチを選択しました。もしこの新しいHTMLファミリーのフォーマットが広く使われるなら、そして、それがその形式にまだシリアライズされず、それが確実にXMLに変換されることができるなら、XMLベースのワークフローが作られ、このコンテンツを消費することができます。一方、企業強度のニーズは、XFormを含むXHTML2によって対応します。2つのフォーマットは、展開の方針や期待される利用分野によって違いが出てきます。

単一のDOMの2つのシリアライゼーション間の相互変換は、うまく定義されるべきです。例えばHTML TidyやTagSoupにおけるJohn Cowan氏の作品での経験は、実現可能性を実証します(しかし、HTML Tidyでの場合とは違い、相互変換はエラー訂正として見られるべきではありません。)。

モバイルクライアントはぜいたくに複数のパーサを実装する余裕はなく、XMLパーサがすでに必要とされているため、モバイルデバイス上で見られる(またはモバイルデバイスを排除しない)と期待されるコンテンツは、XMLシリアライゼーションを使うと書かれるべきです。加えて、拡張性に対するニースがあればすぐに、XMLシリアライゼーション(XML名前空間を使って)はすぐに実用上の利点を得ます。

そのため、やがて、このフォーマットのコンテンツの量が増え、XMLシリアライゼーションにおけるパーセンテージも増えると期待されるはずです。

この方向性は、ウェブやそれ以外でのマークアップの中心的なアーキテクチャとしてのXMLの役割を縮退するものではありません。それは、より創造的で、うまくいけばより成功できる方法を試しているにすぎません。その方法は、同じ目標に向かいます。障壁ではなく橋を作り、大きなステップを小さなステップに分割し、それぞれのステップでやる気にさせるのです 。

XML生態系との融合

複合文書に取り組んでいるCompound Document Formats (CDF) WGは、いまのところはリファレンスよる複合文書にとどまっていますが、現在、本当のmulti-namespace文書による複合文書の取り組みを開始しました。multi-namespace文書では、明らかに、XMLがこの計画に向う唯一の方法です。これはまた、適応(繰り返すが、最初にモバイルで次にデスクトップで)を推進するはずです。

企業強度で拡張可能なマークアップ言語を作り、加えて、他のXML構文に適用可能な派生技術を作りだすというXHTML 2 ワーキンググループの役割もまた重要視されるでしょう。特に、XHTML 2 ワーキンググループは、 Hypertext Coordination groupと同じくXML Coordination groupに参加するでしょう。

拡張性の問題は、いくつかのコメントによって提起されました。。XMLは名前空間や名前空間属性を持つため、MathMLやSVGからリッチなメタデータまで明確に識別された拡張をもった複合文書を作る明確なメソッドがあります。タグスープは拡張が存在しないところでのみ使われることが期待されます。


Dan Connolly, Chris Lilley, Tim Berners-Lee
サイト運営者情報 | プライバシーポリシー | 当サイトのご利用条件 | お問い合わせ | サイトマップ
Copyright © 2007-2011 Futomi Hatano (@futomi) All Rights Reserved.