Summary

  • El borrador de Web SQL de 2009 definía una API para consultar bases locales con una variante de SQL. Ya advertía que todos los implementadores interesados usaban SQLite y que citar su dialecto no equivalía a especificar una lengua portable.
  • El grupo Web Applications del W3C acordó el 1 de noviembre de 2010 publicar el texto como nota de trabajo y retirarlo de la ruta hacia una recomendación. La nota apareció el 18 de noviembre; el informe de almacenamiento de 2011 habló de abandonar esa vía por IndexedDB.

Una prueba puede multiplicar los ordenadores y seguir teniendo una sola variable. Dos navegadores que hacen correr el mismo SQL sobre SQLite producirán respuestas concordantes porque comparten el motor. La concordancia sirve al desarrollador de hoy, pero ofrece al organismo de estándares una evidencia más estrecha: todavía no demuestra que otro motor entienda una regla escrita de manera independiente.

El borrador del W3C de diciembre de 2009 ofrecía operaciones reconocibles: abrir una base, ejecutar una instrucción dentro de una transacción y leer resultados. La interfaz asíncrona estaba descrita. El lenguaje que pasaba por ella seguía definido como variante de SQL, y el propio borrador identificaba el atasco. Todos los implementadores interesados habían elegido SQLite; dejar la definición del dialecto en una referencia a SQLite no servía para un estándar. El editor invitaba a construir un motor independiente que permitiera fijar los límites de ese lenguaje.

En abril de 2009, el ingeniero de Mozilla Vladimir Vukicevic escribió a la lista pública del W3C. Defendía SQLite como software y había abogado por llevarlo a Gecko. Su reparo apuntaba a la web: SQLite tenía decisiones particulares sobre tipos y sintaxis, y una aplicación escrita para ellas podía no funcionar sobre otro motor. Decir «haz lo que hace SQLite» obligaría a los fabricantes de navegadores a aceptar también su evolución y mantenimiento de seguridad. Era la posición técnica de un participante, no un recuento de incompatibilidades ya observadas.

El problema para quien escribía una web era casi invisible. Si dos navegadores aceptaban una consulta, parecía segura para todos. En realidad, podía apoyarse en una costumbre compartida de SQLite que ningún documento había delimitado de forma reproducible. Un tercero que quisiera usar otro motor tendría que imitar la biblioteca o arriesgarse a romper páginas. La prueba de interoperabilidad exigía un dialecto expreso y una implementación que no heredara la respuesta del mismo código.

Las actas de la reunión del 1 de noviembre de 2010 recogen la decisión sin épica. Había dos implementaciones, pero ninguna voluntad suficiente para avanzar; ambas se basaban en SQLite y el subconjunto de SQL no estaba descrito aparte. El grupo acordó republicar Web SQL Database como nota. Alguien dejó abierta la posibilidad de recuperarlo si aparecía interés; otro recordó que volver al itinerario de recomendación obligaría a reiniciar el proceso de propiedad intelectual. Una nota preservaba la discusión. No certificaba el resultado como estándar.

La nota del 18 de noviembre declaró detenido el trabajo por falta de implementaciones independientes. Su sección sobre el lenguaje todavía ordenaba usar el dialecto de SQLite 3.6.19. Esa versión concreta hacía visible la dependencia. El W3C siguió trabajando en Web Storage e IndexedDB; en su panorama de agosto de 2011 describió la base SQL del navegador como trabajo abandonado a favor de IndexedDB.

Los textos no dicen que los navegadores borraran Web SQL de inmediato ni cuántos sitios lo usaban. Para medir esa consecuencia harían falta inventarios de aplicaciones y versiones. Lo que sí documentan es un límite institucional preciso: dos productos podían compartir una tecnología útil sin aportar dos pruebas independientes de un lenguaje web común.

Registros originales