HTML5仕様をめぐるW3CとWHATWGについて、Ian Hickson氏がメーリングリストに書いたこと
HTML5の仕様策定が、今後W3CとWHATWGに分裂するのではないか、といった言説が流れています。発端となったのは、W3CのWHATWGグループにIan Hickson氏が投稿したメールです。
この投稿の日本語訳を、Mozilla Japanの浅井智也氏が公開しています。
本記事の後半で、浅井氏から許可をいただいて翻訳の全文を転載しています。結論から言えば、今後もWHATWGとW3Cが関係を維持しつつHTML5の策定を進めていく、という内容に読めます。
日本語訳を紹介する前に、少しこれまでの背景を説明したほうがこのメールの意味を理解しやすいと思うので、Publickeyなりの理解による背景説明をしたいと思います。
HTML5はもともとWHATWGが発端
HTML5はもともと、W3CがHTML4以降はXHTMLへ注力していたため、それとは別にHTMLを発展させていこうと2004年にモジラ、オペラ、アップルらの有志で設立されたWHATWG（Web Hypertext Application Technology Working Groupが、「Web Applications 1.0」という名前で開発を進めていた標準でした。
その後WHATWGとW3Cが共同でHTML5として標準化を進めるようになってからも、WHATWGは引き続き活動を続け、WHATWGのHTML5仕様を進化させていました。
W3CとWHATWGはおおざっぱに言えば、比較的自由で先進的な議論を進めるWHATWGと、きちんとした手続きに従ったW3Cが、おおむね仕様を同期しながらも細かいところに差異はあるがそれは気にしないことにして、自由な議論がしやすいWHATWGと業界のお墨付きを持つW3Cが、お互いをうまく利用しつつ策定が進んでいたように見えます。
こうした間柄の両者の関係は良好かつメンバーはかなり重複しており、しかもW3CのHTML5とWHATWGでHTML5のエディタを務めていたのは同一人物。グーグルのIan Hickson氏（通称Hixie：ヒクシー）。彼がこれまでのHTML5の仕様策定全般をずっと引っ張ってきたといっていいと思います（Hickson氏はたしかWHATWG設立時にはオペラにいたと記憶しています）。
今年の4月にはWHATWGはW3Cのコミュニティグループとなり、またW3CはHTML5の次の仕様策定に向けて、HTML.nextの準備のためにHickson氏の後継となるエディタを探すことを明らかにしていました（その後どうなったかはウォッチしていません、ご存じの方がいたら教えてください）。
今回のHickson氏のメールは、W3CとWHATWGのこうした共存関係を振り返りつつ、これからについて展望したものだと思います。
以下からは、そのメールを翻訳した記事が掲載されている、modestの浅井氏の記事の転載です。
Hickson氏が投稿したメールの翻訳
若干テンション高めというかフレンドリーというかそんなニュアンスで訳しました。Hixie の意図するニュアンスとは異なる可能性がありますがご了承ください。
誤訳の指摘はコメント欄やTwitterで@dynamitter宛にお願いします。
原文：http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jul/0119.html
運営メモ: WHATWG の HTML Living Standard と W3C の HTML5 仕様との関係についての最新情報
HTML 仕様策定にここ数年 W3C が参加していたのを無視してこれた人は読まなくてオーケー。大量のバグメールが飛んできたけど何でだ？と思った人は続けて読んでね。
当時僕らが公式には “Web Applications 1.0”、裏では “HTML5”って呼んでた仕様について W3C と共同作業を始めたのは今から数年ほど前 (2007 年頃) だった。僕らは仕様の名前を “HTML5″ と変更し、W3C もそのコピーを公開するようになったんだ。すると程なく、W3C では標準をいくつかの標準に分割したから (つまり、2D Canvas API, Server-Sent イベント、postMessage とかにね)、WHATWG 側でもそれに合わせるよう努力してみたんだ。けれど複数バージョンの仕様があることで混乱し、結局 WHATWG 側では僕が担当するすべてをまとめた、1 つの仕様だけに戻すことにしたんだ。僕らが今 “HTML Living Standard” って呼んでるやつにね。それから数年、この文書と W3C 側のいろんな文書はちょっとずつフォークしていったんだ。WHATWG 標準の冒頭 (訳注: 多分ここのこと) で書いてるようにね。
最近になって、HTML 戦線における W3C と WHATWG の目標もちょっとずれてきた。WHATWG では HTML や関連技術の正確な説明を作り上げることに集中してきた、つまり、バグは見つけたらすぐ [1] 直し、新しい機能は必要になったり使えるようになったら追加し、実装も追いかけてきた。その間 W3C はご立派な W3C 標準化プロセスに従ってスナップショット作りにいそしんできたんだ。そして遂に W3C ワーキンググループの議長達と僕は作業を 2 つに分けることにしたんだ。W3C HTML5, Canvas, Microdata 仕様の執筆に責任を持つ人と WHATWG 仕様のエディタ (僕) は別にしようってね。[2]
W3C と一緒にやっていく中で、僕らは WHATWG 仕様右下のウィジェットで登録されたバグを W3C の Bugzilla システムで管理してきた。W3C は WHATWG 仕様に対して登録されたバグのホストを快く続けてくれていたんだ。これまで W3C と WHATWG の仕様を両方を一人のエディタが担当していたから両仕様のバグを 1 つにまとめて、僕は仕様は 1 つしかないかのように処理してこられた。でもフォークしちゃうと (訳注: エディタが別になると) それは続けられない。だから、W3C の Bugzilla システムで HTML 仕様に登録されていたバグをすべて取り出して複製したんだ。1つは W3C 用に、もう一つは WHAWG 用にね。僕は WHATWG のバグを扱っていき、W3C の新しいエディタ(達)は W3C のバグを扱っていく。もし君が最近大量の “operation convergence” って書かれたバグメールを受け取っていたら、そういうことさ。具体的にどうなるんだってことはこのメールに続けて書くね。
僕にどんな影響があるの？
WHATWG の仕様にフィードバックを送るなら、このメーリングリスト ([email protected]) に送ってくれるのが一番簡単だよ。
WHATWG の仕様のバグを報告するなら、WHATWG 仕様に付いてるツールを使ってくれれば適切なコンポーネントを選んでくれる。
W3C Bugzilla を直接使ったり WHATWG 仕様のバグを検索したいのなら、Bugzilla で “WHATWG” プロダクトを選択してくれ。僕が編集してる仕様のコンポーネントは “HTML” だよ。他のコンポーネントは Anne とか他のエディタが編集してる仕様のためのものだからね。
Bugzilla にコメントを書いて僕に読んで欲しいのなら、僕に割り当てられてるバグにコメントしているか確認してね。”WHATWG” プロダクトじゃなくて “HTML WG” プロダクトのバグは HTML WG のエディタに割り当てられているもので、多分僕は見ないから。(もちろん僕も W3C 側の変更をできる限り追い続けるけど、個別のバグコメントまでは目を通せないと思うんだ。)
WHATWG HTML 仕様で現在未解決のバグはこのリンクで確認できる。
フィードバックがどれくらい溜まってるか確認するには、僕はこのグラフを見てる。
“operation convergence” についての詳細:
これまでバグには2つのバケツがあったんだ。(“HTML5 spec” とかいろんなコンポーネントの) W3C 仕様に登録されたバグと、(“other Hixie drafts” コンポーネントの) WHATWG 仕様に登録されたバグがね。その殆どは僕に割り当てられ、コンポーネントなんて気にしてこなかった [3]。
僕は最近 W3C スタッフと協力して 2 つのスクリプトを走らせて、バグを全部複製したんだ。1つ目のスクリプトでは “HTML5 spec” コンポーネントにあったバグを選択して、複製したバグを WHATWG プロダクトに登録して僕に割り当て、元のバグは nobody に割り当てた。2 つ目のスクリプトでは “other Hixie drafts” コンポーネントにあったバグを選択して、”WHATWG” プロダクトに移動させ、”HTML5 spec” コンポーネントに複製し、nobody に割り当てた。今回 nobody に割り当てられたバグはそのうち W3C の HTML5 仕様エディタになる誰かに割り当てられることになるだろう。今後登録されるバグには何も影響しない。これから先に進むため、長期的な計画をどうしていくか、僕はこれからも HTML ワーキンググループの議長達と一緒に決めていく。古い “other Hixie drafts” コンポーネントは無くしたよ。
ここで書いたことは、4月にアナウンスした WHATWG は W3C コミュニティグループ になるって件とは関係ないんだけど、要するに、W3C の HTML ワーキンググループからは独立するけど W3C との協力関係は保たれるってことさ。[4]
最終的な結果としては、HTML Living Standard の策定作業が再び加速され、W3C ワーキンググループと共同作業を始める前のペースを取り戻せることを、僕は期待している。
質問があるなら、僕に直接メールするか、IRC チャンネル (Freenode の #whatwg)で聞いてね。技術的議論の S/N 比を保ちたいから、このメーリングリストでは仕様策定プロセスに関する議論はしないで欲しいんだ。
– 脚注 – [1] あるいは、見つけてから数ヶ月後にね… 今僕は 6 ヶ月ほど遅れてる。ゴメンね。頑張るよ！ (・・).
[2] http://lists.w3.org/Archives/Public/public-html/2012Apr/0204.html
[3] 詳しく書くと、僕は W3C HTML WG コンポーネントのバグについては “Accepted” や “Rejected” として閉じるブックマークレットを使っていた。HTML ワーキンググループのプロセスで要求される雛形があったからね。”other” コンポーネントのバグについては雛形なんて使わなかった。HTMLWG のプロセスを経る必要があるのは彼らのバグだけだったから。
[4] http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Apr/0240.html
– Ian Hickson
訳者コメント
今回の件で「WHATWG と W3C が決別して HTML5 がフォークした！」と騒ぐ人もいるかと思いますが、そんな話ではありません。フォークって言葉を強調した記事に釣られないようにしましょう。
プロジェクトやツリー全体がフォークするのではなく、安定バージョンのブランチを切ってブランチ専用のメンテ担当者を割り当てましょうって話が進んでいて、バグ管理もトランクとブランチで分けるようになったんだと理解するのが正しいかと思います。普通の製品開発でも安定ブランチ作りますよね？
Hixie の期待通り再び HTML の仕様策定が加速され、Web がより魅力的なプラットフォームになることを期待しています。(・・).
あわせて読みたい
