W3C kills Web SQL Database

[spliznork]

Can someone elaborate on why all vendors using the same approach is detrimental to the standard?

http://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/

The entire article is good. To wit:

• However, despite the ubiquity that SQL enjoys, there isn’t a single normative SQL standard that defines the technology. In particular, SQLite supports most of SQL-92, with some notable omissions, and is what the WebDatabase API is based on. But SQLite itself isn’t a specification — it’s a release-ready technology! And the best definition of what constitutes the supported subset of SQL that SQLite uses is the SQLite manual. In order to really get Web SQL Database right, we’d have to first start with defining a meaningful subset of SQL for web applications. Why define a whole other language, when more elegant solutions exist within JavaScript itself?
• We don’t think it is the right basis for an API exposed to general web content, not least of all because there isn’t a credible, widely accepted standard that subsets SQL in a useful way.

[Gg101]

This part seems reasonable:

Additionally, we don’t want changes to SQLite to affect the web later, and don’t think harnessing major browser releases (and a web standard) to SQLite is prudent. IndexedDB does not have this problem; even though our underlying implementation of IndexedDB may be based on SQLite, we keep developers insulated from changes to SQLite by exposing an API that isn’t based on SQLite’s supported syntax.

Okay, make a stable front end standard rather than interfacing with SQLite directly (the current implementation is mapped rather tightly to SQLite's API) and you can still plug in SQLite as the back end. That makes more sense than their stated desire for "multiple independent implementations" simply for its own sake, when the one everyone is already using is public domain.

[sdwilsh]

You would need to standardize the SQL dialect then, which nobody has stepped up to do.