Web標準化の関係者たちが語る、標準化の現実と前進のための処方箋（前編）。HTML5 Conference 2013

2013年12月9日

ふだん私たちが接しているWeb技術は、W3CやIETFといった国際的な標準化団体でさまざまな議論が行われた上で決定された仕様に基づいている。

その標準化団体とはどういうもので、標準化作業に伴う苦労はどのようなものなのか。実際に標準化を行っている、もしくはそれに関連した人たちが議論をするセッション「Spec EditorとContributorが語るWeb標準化と開発者への期待」が、11月30日に都内で開催された「HTML5 Conference 2013」で行われました。

左から、NTTコミュニケーションズ小松健作氏、Google　安田絹子氏、楽天石井宏治氏、矢倉眞隆氏。いちばん右がモデレータのGoogle 及川卓也氏

ディスカッションの内容を、前編と後編の2本で紹介します。

Spec EditorとContributorが語るWeb標準化と開発者への期待

Googleの及川です。こんな地味なセッションで立ち見が出るのは何かの間違いじゃないかって、さっき登壇者の人たちと話していたのですが、正直言うと非常に嬉しいです。

ではまず、登壇者の方々に自己紹介していただきます。

石井　楽天koboで標準化推進をしている石井と申します。CSSワーキンググループでCSS Text Decoration Module Level 3、CSS Writing Modes Level 3、CSS Rubyのエディターをしています。Unicodeのエディトリアルコミッティーに参加していまして、Unicodeのバーティカルレイアウトのエディターをしています。あとIDPF、EPUBワーキンググループと言った方が通りがいいですかね、こちらは全員共同の執筆スタイルですので、こちらでメンバーをしています。

安田　Googleでソフトウェアエンジニアをしています、安田絹子と申します。Chromeの開発を3年半ほどやっていまして、Quota Management APIのエディターをやっているんですけれど、それ以外にもFile System APIとかChrome独自のAPIですがSync File Systemを作ったりしています。

ちなみにQuota Management APIは超マイナーなAPIで、ユーザーのデバイスにデータを置く場合、どれくらい置けるか制限をかけたり、どれくらい置けるかアプリケーションが聞けるようにしたり、ディスクがあふれそうなときブラウザがどれを消せるかといったコミュニケーションがうまく行くためのAPIを提案しています。

小松　NTTコミュニケーションズの小松です。主にW3Cの方で、僕自身はスペックエディターではなくてコントリビュータという立場ですが、デバイス連携などのユースケースや実装例を提案したりして協力しています。

また、W3Cの標準化でスペックのテストを整備しなければならないのですが、そのテストをコミュニティの方で書いていこうという「Test the Web meetup」という活動があるのですが、それを日本で運営したりしています。

矢倉　矢倉と申します。html5jのスタッフをやっています。標準化に関してはほぼ受け身で、W3Cの仕様書を読んだり、たまにメーリングリストで「タイポがあるよ」って突っ込んだりとか、ブラウザのコミットログを追いかけたりとか、そういうことをしています。

W3C、IETF、Unicodeなど標準化団体の役割とは

及川　この4人の立ち位置は、石井さんと安田さんがエディターなどの立場で標準化に関わっていて、小松さんと矢倉さんはスペックは書かないけれども、それを支えるコントリビュータということで登壇いただいています。

さて、会場のみなさんで、標準化になんらかの形で貢献したことがある、という人はいますか？少ないですね。では、このセッションの私たちのゴールとしては、貢献したいという人が増えたらいいな、ということにしたいと思います。

Web標準と言ったときに、HTML、CSS、JavaScript、通信プロトコル、Unicodeなどさまざまなものがあり、さまざまな標準団体があります。それぞれどのような団体で、どういう風に標準化が進められているの。

矢倉さん、W3Cについて教えていただけますか。

矢倉　W3Cとは、主にHTMLとかCSSとかDOM APIなどを策定しているところで、これらは最終的にブラウザに実装される仕様です。特徴としては、（策定された最終仕様を）スタンダード、標準といわず“勧告”といっている。策定プロセスもユニークで、標準を作って決めてから製品を出すのでなく、その仕様が使えてなんぼ、というのをよしとします。つまりある程度スペックを書いてみたら実装してみて、フィードバックをもらってさらに仕様を高めていって、いい感じになったら勧告にします。実装がないと標準が完成しないというのがW3Cの特徴です。

及川　では、ネットワークのプロトコルを定めているIETFに関して小松さん、教えてください。

小松　IETFは通信プロトコルの標準化を進めているところで、WebSocketsやWebRTCなどのブラウザのAPIはW3Cで標準化をしていますが、APIを叩いたあとでどういう通信プロトコルで通信するかはIETFで決めています。

HTTPそのものもIETFで決めていますね。あとWeb関連では、データフォーマットも通信プロトコルということで、JSONとかATOMとかの標準化も進められています。

W3CがIETFの標準化プロセスを参考にしたということもあり、W3Cに近いですね。メーリングリストとミーティングを年に3回。そこでの議論や実装などのフィードバックを通してRFC（IETFにおける標準仕様）になります。

及川　小松さんはW3CとIETFの両方を知ってる立場ですが、この2つの違いはどうですか？

小松　ぶっちゃけていうと、IETFの方が仕様化は速いかなと思います。W3Cもデッドラインを決めて標準化しますよ、という約束はするのですが、その辺は緩いかなという気がしますね。それからステークホルダーがW3Cの方が幅広くなっている気が最近はしていて、いわゆるブラウザベンダだけでなくテレビや自動車など、いろんな産業からのリクワイヤメントがIETFより多いかなと。それも仕様化が遅くなっている理由なのかなと思います。

及川　石井さんが関わっているUnicodeについて教えてください。

石井　Unicodeはご存じのように文字コードを決める団体です。新しい文字、いまUnicodeに入っていない、そういった文字の追加を基本的には管理しています。

同時に、例えば文字単位で仕様を決める場合がある場合、日本でいうと禁則。この文字の前で改行してはいけないとか、これをW3CのCSSで決めると、Unicode 8.0に新しい文字が入ると誰かがCSSをそれに合わせてメンテしなければならなくなる。だから文字単位で決めなきゃいけないことはUnicodeで決めましょう、ということになりました。

だからUnicodeでは、どの文字の前で改行していいかどうかというプロパティが全部の文字についています。それからソートオーダーとか、文字単位で動くときのプロパティなど。現在Unicodeが管理しているプロパティが200個くらいあって、どこかの国がこの文字をUnicodeに追加しようというときには、じゃあそれらの200個のブロパティをどうしようか、というのを一斉にがーっと決めると。そういう団体です。

私が関わったのは、もともとCSSで縦書きをやろうとして、縦書きのときにどの文字が縦でどの文字が横になるのかとか決めなくちゃいけなくて。半角の数字は（縦書きのときは）横ですよね、これはあんまり異論はないと思います。漢字は縦にならなくてはいけない。じゃあダブルクォートはどっちだとか、あいまいなものも結構あって、それをCSSで決められないのでUnicodeで決めるということになって、その仕様を一個書いていると。

及川　Unicodeの標準は、W3Cに比べるとかちっとしている印象ですが、それは正しいですか？

石井　Unicodeにかちっとせざるを得ない部分があるのは、標準にはデファクト標準とデジュール標準というのがあって、（デファクトは業界標準なのに対して）デジュールというのはISOとかJISとか国や政府が決める標準ですね。Unicodeはデファクト標準として始まっているのですが、教科書とか政府調達品はデジュールに従っていないといけない、という規則があります。とするとUnicode採用製品を政府調達できないじゃないかと。

ということで、Unicodeに対応するISO10646という仕様があって、2つの仕様があっても作る側も使う側も困るので、両方で同期をしましょうということで、きちんとルールを守ってやっていきましょう、というところがあります。

標準化している当事者は何に苦労しているのか

及川　もう少し突っ込んだ話を聞かせてもらいたいところですので、安田さん、実際の標準化はどういうやり方をしていて、どういう点で苦労していますか。

安田　私はまだ標準化プロセスの途中までしかいってないので、どういうステップを踏んで標準化できるのかなというのを調べながらやっているのですが、W3Cのスペックにもいろいろあって、人気があってみんなが言いたいことがあるスペックは、意見をまとめた頃にまたそれをひっくり返すような意見が出たりと苦労されているようです。

でも私のやっているスペックは割とマイナーなスペックなので、どちらかというと開発者やブラウザベンダの人に重要性を分かってもらって実装してもらわないといけないんですね。なので例えば、少し面識ができたり知り合いになったブラウザベンダの人に、こういうのがあるのだけどフィードバックをくれない？とか実装をお願いしたり、で、断られたりするんですが（笑）。割と地味な努力をしています。

石井　エディターって、アイデアを出す部分とか提案する部分というのは小さなところで、標準化して行くにはステークホルダーがみんな満足すること、少なくとも納得すること（で、そこが苦労するところ）。

それから標準化する意味っていうのは、ある製品がシェア100％でみんな満足しているなら標準化する必要はないんです。標準化する意味っていうのは、2つ以上のベンダがあってたくさんのユーザーがいて、その2つ以上のベンダの製品が同じように動くことでみんながメリットを受ける。ユーザーも広がることでベンダも嬉しいと。

なので、この標準化をやりたいとベンダが手を挙げたとき、もう1つのベンダが手を挙げなかったら標準化する必要ないよねと。みんなの時間を使って議論するのも時間を使うし、それに見合う価値をみんなに納得してもらわないといけない。

ブラウザでいうとChrome、Safari、IE、Mozillaなどのうち最低2つ。理想としては全部が（仕様の標準化を）やりたいといってくれないと標準化は進まないので、要望してくれるみんなの声と、その機能が使う人に合っているかと、実装するベンダと、その全員が合意するようにもっていくのが大変かなと思います。

及川　石井さんがやっている縦書きのところは僕もちょっと関わっていたので、その辺は大変だなと分かる気がします。縦書きって、もうだいたいできてるんですよ。いまやってる細かい仕様って、千冊に一冊使うか使わないか、そのぐらいのレベルのところでも、「これがないと電子出版は日本ではダメだ」っておっしゃる方々がいるような気がして、そこで苦労されてるんですよね？

石井　標準化をやってる人たちの中で「後ろから撃たれる」っていうんですが、（国際標準の場などで）さんざん調整したあとで「そんな中途半端な機能なら日本はいらない」とかっていうメールが突然飛び込んできて、日本人からそれをいわれるとつらいなと。

≫後編に続く。後編では、標準化を速くするためになにができるのか？などについての議論が続きます。（昼頃公開予定）