Las vacaciones de los miembros de TC45 de ECMA, me temo que no son envidiables. Su trabajo sin embargo es... admirable. El ritmo, profundidad y seriedad en la resolución de comentarios, no solo ha sorprendido al los miembros del SC34 de ISO durante su última reunión de Kioto, sino a cualquiera que haya seguido mínimamente este proceso.

La suma "bruta" de comentarios llegó a 3.522. Comentarios de 87 países. Muchos repetidos (será muy interesante e ilustrativo hacer un análisis sobre esta circunstancia en un futuro), por lo que finalmente, el número de comentarios únicos se ajusta a cualquier otro estándar remitido por FastTrack, según indica Jan van den Beld en su blog, secretario general de ECMA internacional hasta Abril del 2007: un comentario por cada 6 páginas aproximadamente.

A fecha de hoy, ECMA ha propuesto modificaciones para 2.298, es decir, casi 2/3 (65,25%). Los resueltos en el último lote, recogen algunos de los aspectos más "mediáticos" durante la fase anterior del proceso, divididos en tres grandes bloques:

• TRATAMIENTO DE FECHAS 
1. Almacenamiento de fechas anteriores a 1900 y cumplimiento de ISO8601
2. Cálculo correcto del año 1900 (no bisiesto)
• FUNCIONALIDADES EXTRAIDAS DE LA ESPECIFICACIÓN PRINCIPAL

• Muchos países señalaron la inconveniencia de reproducir en el estándar errores conocidos, aunque los motivos fueran compatibilidad con aplicaciones antiguas. Esto no es algo nuevo, y de hecho ya hay precedentes en otros estándares como SQL's ISO 9075:2003 Part 1 o C++'s ISO/IEC 14882:1998. Estas funcionalidades se cana fuera de la especificación y se anexan de forma independiente para que nunca sean usadas por nuevos documentos, lo que perpetuaría los errores. Esto aplica fundamentalmente a tres aspectos: VML y Compatibility settings
1. ECMA quitará totalmente VML, y lo sustituirá por DrawingML. Se anexará la especificación VML exclusivamente para la migración de documentos binarios, pero nunca se utilizará en documentos nuevos.
2. "Compatibility settings". ECMA da la razón a los países que pidieron incluir detalle de implementación de funciones (existente por compatibilidad) como AutoSpaceLikeWord95, truncateFontHeightsLikeWP6 etc.. De nuevo, los nuevos documentos no lo utilizarán, pero anexar su documentación completa permitirá implementaciones completas de OpenXML.
• ORGANIZACIÓN DE LA ESPECIFICACIÓN
• Algunos países pidieron más claridad y guía para facilitar las implementaciones a los desarrolladores. Con ese objetivo, la especificación se organiza de forma algo diferente:
1. Las clausulas de conformidad serán más específicas (a WordprocessingML, spreadsheetML, PresentationML, OPC etc., ) e incluso se añadiran mas cuando se requiera mas granularidad. Se añade incluso conformidad semántica, no incluyendo nunca funcionalidad alguna en desuso de aquellas recogidas en el anexo.
2. Muchos países proponían que, dada la modularidad del estándar, se planteara un estándar con múltiples partes para aislar tecnologías específicas en especificaciones diferentes.  ECMA considera esta propuesta muy positiva, y plantea la reorganización de DIS29500 en tres partes diferentes: DIS 29500-1 que recojerá WordprocessingML, SpreadsheetML, PresentationML, SharedML; DIS 29500-2 que contendrá las especificaciones de OPC (packaging); DIS 29500-3 para las especificaciones de Extensibilidad del estándar.

En fin, estas son solo unas cuantas de las modificaciones que hasta la fecha lleva el estándar. ECMA sigue manteniendo la fecha del 14 de Enero como fecha de finalización de los trabajos previos al BRM (Balloting Resolution Meeting) de finales de Febrero en Ginebra.

Ojalá, y a diferencia de la anterior fase del proceso, solo hablemos de tecnología, tecnología y mas tecnología, que al final, es de lo que va esto.