Summary

  • W3Cの2009年のWeb SQL草案は、ウェブアプリがローカルのデータベースへ問い合わせるAPIを定めた。一方、関心を持つ実装者が皆SQLiteを使い、SQL方言をSQLiteへの参照だけで説明するのは標準として足りないと明記した。
  • Web Applications作業部会は2010年11月1日、文書を勧告へ進める経路から外して作業部会ノートにすることを決めた。18日のノートは独立実装の不足を理由に挙げ、2011年のW3Cの概説はIndexedDBへ向かう方針を記した。

実装が二つあれば安心、という勘定には落とし穴がある。二つのブラウザーがSQLの処理を同じSQLiteに任せれば、同じ結果は返しやすい。それは製品の動作確認にはなる。しかし、別の開発者が文書だけを読んで互換のSQL処理系を作れるという証拠にはならない。Web SQLを止めたのは、この「二」の中身だった。

2009年12月のW3C作業草案には、データベースを開き、トランザクションで文を実行し、結果を読むための非同期APIが載っている。手順は細かい。その先で渡すSQLは「変種」とされ、どこまでが共通の言語なのかは書き切れていなかった。草案は、関心のある実装者が全員SQLiteを使い、その方言をSQLiteへの参照で済ませるのは標準として認められないと述べる。編集者は独立したバックエンドを作る人を求めた。

Mozillaの技術者Vladimir Vukicevicは、2009年4月のW3C公開メーリングリストへの投稿で、SQLiteを嫌っていたわけではない。Geckoへの導入を後押しした一人だと書いている。そのうえで、SQLite特有の型や構文をウェブのページに見せれば、別のデータベースでは同じアプリが動かない恐れがあると指摘した。「SQLiteと同じように動くこと」を規則にすれば、各ブラウザーメーカーはその実装と将来の安全対策まで引き受ける。これは議論に参加した技術者の見解で、実際に何サイトで障害が起きたかを測った記録ではない。

サイトの開発者からは違いが見えにくい。手元の二製品でクエリーが通れば、移植できると思うだろう。だが共通の土台がSQLiteなら、通った理由は規格の明晰さではなく、共有した処理系の癖かもしれない。第三の実装者には、独立したSQLの範囲と、それを検証する試験が必要だった。

2010年11月1日のW3C会議録は、二つの実装がありながら前進する意欲が乏しく、双方がSQLiteを使い、SQLの部分集合を別に定義していないと記す。作業部会は勧告を目指す文書からノートへ移すことで合意した。将来関心が戻れば再開もあり得るという意見が出た一方、勧告の経路へ戻るには知的財産権の手続きをやり直す必要があるとの指摘もあった。ノートは議論を保存するが、完成した標準として承認するものではない。

2010年11月18日のノートは、独立した複数の実装がなく仕様作業を止めたと明記する。その本文はなお、利用者エージェントにSQLite 3.6.19のSQL方言を実装するよう求めていた。エンジンの版番号が言語の代わりに書かれていたわけだ。W3CはWeb StorageとIndexedDBの作業を続け、2011年8月の技術動向報告ではSQL型のブラウザーデータベースの作業をIndexedDBに譲ったと説明した。

これらの記録は、既に配られたブラウザーからWeb SQLがいつ消えたかを示さない。利用するアプリの数もない。明らかなのは、同じエンジンに乗った二つの実装では、エンジンの外にある規則を試せないということだ。

一次資料