HTML5カンファレンス2013（http://events.html5j.org/conference/2013/11/）の15:15〜16:00、ルーム5Cの「Spec EditorとContributorが語るWeb標準化と開発者への期待」（パネルディスカッション）のメモです。

（コーディネータ）Google 及川さん
（パネリスト）楽天 石井さん、Google 安田さん、NTTコム 小松さん、矢倉さん

楽天 石井さん（エディタの立場）
・楽天koboで標準化推進を担当している。
・CSS WG、Unicode Technical Committee、EPUB WG。

Google 安田さん（エディタの立場）
・ソフトエンジニア。Chromeの開発。
・WebApps WGでStorage関連。
・Quota Management APIのエディタ。
　Quota Management APIとは、データの置く量の制限や溢れそうなときにブラウザがどれを消すか、のようなもの。
　（Quota Management APIのWorking Draft→http://www.w3.org/TR/quota-api/）

NTTコム 小松さん（コントリビュータの立場）
・W3Cではコントリビュータの形で出させてもらっている。
　デバイス間連携でUPnPとかを繋げるところを話したり実装例を作ったり。
・テストを整理するにあたって、コミュニティでTest web forwardの運営等をやったり。

矢倉さん（コントリビュータの立場）
・html5jのスタッフ。
・標準化に関しては受け身。Typoを指摘したりコミットログを見たりぐらい。

エディタが2名、コントリビュータが2名。

標準化とは

（矢倉さん）
W3CはHTMLやJavaScriptやDOMの仕様を決めているところで、それがブラウザに実装される。
ゴールは「勧告」。
W3Cではデファクト標準、使えてなんぼのものを作るのが目的なので、実装がないと完成しない。

（NTTコム 小松さん）
IETFについて。
W3Cとの関わりで言うと、WebSocketとかWebRTCで具体的にどのような通信を行うか。
またHTTPそのものもIETFの管轄だし、jsonやATOMもIETF。

W3CがIETFのやり方を参考にしたというところもあり、MLを使ってとかフィードバックしたりというのは似ている。
IETFでは、最終的にRFCということでリコメンデーションされる。

W3Cとの違いは、IETFの方が動きが早い。
W3Cの方がステークホルダーが広い。最近だとテレビとか車屋さんとか、いろいろな人たちが入ってくる。
アクセシビリティの話もある。
W3CではそうしたいろいろなrequirementがIETFより多く、それがW3Cが遅くなる原因かと思う。

（楽天 石井さん）
いまUNICODEに入っていない文字の管理等をしている。
文字単位で仕様を決める必要がある場合、例えば禁則などだが、それをW3Cで決めてしまうと修正が入る時にW3CでメンテしないといけなくなってしまうのでUNICODEで管理している。

もともと関わったのは縦書きで、「半角の数字は横で漢字は縦で」「ではダブルクォートはどっちで？」とかいうのはCSSでは決められないので、UNICODEのほうで書いている。
W3Cの仕様がUNICODEの仕様を参照するという関連性を持っている。

標準にはデファクト標準とデジュール標準がある。
UNICODEはデファクトで、みんなが使っている分には差がないが、例えば政府調達にはデジュール標準でないといけないのISO-1060というデジュールに映した仕様があったりする。
同じものが2つになるため、相互に決めたものをやり取りする。

苦労している点

（Google 安田さん）
まだプロセスを途中までしか行っていないので（標準化策定の途中までしか経験していないので）どういう手順を踏んで標準化に至るか調べながらでやっているが、（WGに参加している）みんなが言いたいことを言っていて混乱するし、一度収まっても勧告前にまた別の話が出てきたりする。

デファクトという話があったが、安田さんがやっているのは仕様を書きながら実装しながらで、実際に実装しないとわからないところがあるので実装して仕様にフィードバックして、というようなところ。

（楽天 石井さん）
エディタというのは、「アイデアを出す」というのは全体のうちですごく小さい部分で、ステークホルダーが皆納得するようなところに調整していくということが大事。

みんなが同じ方向を向いているなら、そもそも標準化する必要はない、
標準化する意義は、2つ以上のベンダがいて、それが同じように動くことで利用者もベンダもハッピーになるということ。
2つ以上の実装がなければ標準化する必要がないので、最低2つ、できれば全部の方がいいが、それぞれがやりたいと手を上げて実装してくれなければ意味がない。
さんざん調整した後で後ろから撃たれると辛い。

Webの標準化に貢献するメリット

（小松さん）
コントリビュートという意味で言うと、その仕様自体にrequirementsがあることを示すこと自体がコントリビュートだと思う。
サンプルを作るとかブログで紹介するとか、それによってその仕様に対するrequirementsが出てくるとか問題が出てくるとか、それがコントリビュート、フィードバックだと思う。
そう考えると、ここにいる（聴講中の）方の中にもコントリビュートした人は結構いると思う。

英語の壁を越えれば比較的に簡単にできるか

（矢倉さん）
仕様に些細なエラーがあったり、アルゴリズムに不可解なところがあったりというのを突いたり。

HTMLにルビと言う要素があるが、それの日本語の要素がおかしいとかセンタリングがおかしいというのを伝えると、（海外の）エディタがそこに明るくないということもあるので、それで貢献できることがある。
また、その仕様に一段と深い知識が得られると言う意味で個人的な上澄みも出てくる。
Typoとかの指摘でもacknowledgement（仕様書の謝辞のところに載るあれ）扱いになる。

「こういう仕様を作りたい」と言ったときにどうすればいいか

（矢倉さん）
基本的には、MLに投げて賛成が出ればそれで仕様が作れる。
但し誰かがドライブしなければ進まない。

貢献というところで、新しい仕様のデモサイトやサンプルを書いてもらえるというのは非常にありがたい。
Specを適当に書いているところもあるので、そういうところは非常に参考になる。

その他、国や文化の違いなど

（安藤幸央さんからの質問、をGoogleの及川さんが代読）

（NTTコム 小松さん）
標準化の遅さについてはあまり感じない。
例えばAjaxは2004年に流行って普通に使われるようになっているが、あれはまだrecomendationされていない。
Living Standardなので。
皆が使って、それに市場の価値があるからLast Callまで進んでいく。

（楽天 石井さん）
縦書きは、いまWebKitと、今はIEも対応したがそちらはテストできない。
もし広まっていってもWebで縦書きを使うのかという話もあるし、IEで表示が違うと言うこともある。
「テストが2つ以上の実装でパスすること」が必須なので、問題を上げたりするのはスピードアップへの貢献になる。

（このパネルディスカッションでは外野: NTTコム 宮川さん）
ちょうど2年後の2015年、IETFが横浜で開催される。
そこで、それに合わせてTPAC（W3Cの年次イベント）も同じ週か次の週に開こうと検討している。

2年後に「日本で盛り上がっている」ということで、それを示すためにその2年後の時に何かの仕様をFinalizeさせようとすると、今から書き始めないといけない。

英語について

（NTTコム 小松さん）
英語についてはとにかく発言する。
下手な英語でも。別に殺されたり殴られたりするわけじゃないので。
盛り上げる方については、是非コミュニティのイベントをやりたい。

（Google 安田さん）
英語についてはがんばればまあ。
こうあるべきならMUSTを使うとか。

（楽天 石井さん）
読むのと書くのと。
英語で仕事する分にはいけるが、雑談とかは辛い。
単語力がつけば、文法がわからなくても何とかなる。

（矢倉さん）
海外に住んでいたことがあるのでアドバンテージはあるが、言語によらず自分の思っていることを伝えるのは難しい。
日本とか関係なく、盛り上がるのなら海外から呼んでもいいと思う。