[Openxml] Envío de resumen: Se debe votar no con comentarios

[Rafael Bonifaz]

Estimados Amigos,


A las 15:00 de hoy se ha terminado la discusión técnica en la lista de
correo. Recogiendo los correos electrónicos de la lista más las
respuestas de Microsoft a las observaciones técnicas realizadas, tenemos
las siguientes consideraciones. 



ERRORES DE FECHAS


Existen varias preguntas que no han sido contestadas. Uno de los
argumentos más visible tiene que ver con la fecha, ya que uno de los
problemas más graves del estándard es no soportar fechas menores al año
1900. Las respuestas de ECMA[1] no han propuesta ninguna solución al
tema y por lo contrario han argumentado que ese es un problema menor. En
la reunión del día viernes 24 de agosto, la representante del Instituto
de Propiedad Intelectual pregunto que pasaría con las patentes que
tienen registros anteriores a 1900. Esta pregunta no fue contestada ese
día y si revisamos todo el historial de la lista de correo[1], no vamos
a encontrar ninguna respuesta puntual. A pesar de que el tema fue
expuesto en varias ocasiones.[2]


[1]
http://www.asle.ec/wiki/lib/exe/fetch.php/respuesta_ecma_ecuador.pdf?id=ooxml&cache=cache

[2] http://mail.inen.gov.ec/pipermail/openxml/2007-August/


Creemos que el problema de las fechas no se lo debe negar y debe ser
solucionado. No es admisible decir que la historia anterior a 1900 no es
relevante. ¿Se olvidar fechas tan importantes como el primer grito de
independencia (10 de agosto de 1810), gobiernos tan importantes como los
de Gabriel García Moreno y Eloy Alfaro. Estas preguntas fueron hechas en
reiteradas ocasiones en la lista y nunca fueron
respondidas.[3][4][5][6]. 


Ante un problema tan grave no es posible aceptar una respuesta que
menosprecie a grupos tan importantes como historiadores y
genealogistas[7].


La mayoría de usuarios no llegan a usar fecha menores a Enero 1, 1900 e
incluso el estándar ISO 8601 utiliza fechas Gregorianas, siendo usadas
únicamente como fechas válidas aquellas que son posteriores al año 1582,
debido a que antes de ese año los historiadores utilizaban las fechas
Julianas, así que el uso de hojas de campos de fecha en hojas de cálculo
está limitado paras los historiadores/genealogistas sin importar el
estándar que se utilice. Es por ello que no hay necesidad de indicar
fechas antes de 1900


Ante esto la respueta de Ricardo Arguello es muy clara[8]

Falso. El estándar ISO-8601 no utiliza "fechas Gregorianas", no existe
tal cosa. Como mencioné anteriormente, el estándar solo utiliza dos
ideas puntuales del calendario Gregoriano: el tamaño de los meses (28,
29, 30, 31) y el método para calcular un año bisiesto. Si se lee el
estándar ISO-8601 se comprenderá que no limita el año mínimo a utilizar.
Según dicho estándar, el tamaño del año debe ser de 4 dígitos, lo cual
permite representar años desde 0 hasta 9999. Incluso este tamaño puede
ser modificado, según queden de acuerdo las partes interesadas, para
soportar años "menores" a 0 o mayores a 9999. Referencia: Estándar ISO
8601:2004, Sección 3.5: 'Expansion ... By mutual agreement of the
partners in information interchange, it is permitted to expand the
component identifying the calendar year, which is otherwise limited to
four digits. This enables reference to dates and times in calendar years
outside the range supported by complete representations, i.e. before the
start of the year [0000] or after the end of the year [9999].'
"siendo usadas únicamente como fechas válidas aquellas que son
posteriores al año 1582, debido a que antes de ese año los historiadores
utilizaban las fechas Julianas,"

Falso, como queda demostrado en el comentario anterior. Nada tiene que
ver el calendario Gregoriano en cuanto al limite inferior posible para
el campo de años. Es totalmente falso que el estándar ISO-8601 soporte
solo años posteriores a 1582. Por favor leer el estándar ISO-8601.


Así que señores miembros del comité creemos que el simple hecho de
errores de fecha sería suficiente para un voto de no con comentarios.


[3] http://mail.inen.gov.ec/pipermail/openxml/2007-August/000061.html

[4] http://mail.inen.gov.ec/pipermail/openxml/2007-August/000117.html

[5] http://mail.inen.gov.ec/pipermail/openxml/2007-August/000067.html

[6] http://mail.inen.gov.ec/pipermail/openxml/2007-August/000092.html

[7] Primer comentario de la respuesta de ECMA

[8] http://mail.inen.gov.ec/pipermail/openxml/2007-August/000092.html


¿ÉS REALMENTE UN ESTANDARD ABIERTO?


La idea de que Microsoft proponga un estándard abierto es algo muy
bueno. ¿Habría que preguntarse qué tan abierto es este estándard? Dentro
de la documentación existe un sin número especificaciones no
especificadas. Es inaceptable que un estándard sea considerado abierto
si el 100% de su especificación no es abierta. Aún si las partes son
consideradas “opcionales” deben ser documentadas, En la lista de correo
publicó un email que hace referencia a las respuestas de ECMA[9] donde
nunca se respondió sobre este tema[10]:

* Existe un sin numero de elementos que no están documentados. 

Ejemplos:
      Parte 4, Sección 2.15.3.54: uiCompat97To2003
      Parte 4, Sección 2.15.3.54: truncateFontHeightsLikeWP6
      Parte 4, Sección 2.15.3.6: autoSpaceLikeWord95
      Parte 4, Sección 2.15.3.63: useWord2002TableStyleRules
      Parte 4, Sección 2.15.3.64: useWord97LineBreakRules
        ......

etc

[9]
http://www.asle.ec/wiki/lib/exe/fetch.php/respuesta_ecma_ecuador.pdf?id=ooxml&cache=cache

[10] http://mail.inen.gov.ec/pipermail/openxml/2007-August/000124.html

Creemos que es importante que ECMA o Microsoft muestren todas las
especificaciones pertinentes para que el Estándard puede ser considerado
justo para la mayoría y no solo para quien propone el estándard.


¿ÉS UN ESTANDARD INDEPENDIETE DE PLATAFORMA?


El señor Esteban Ordóñez intentó discutir el tema de dependencia de
plataforma:[11]


Dependencias de plataforma como las referencias exclusivas a productos como
Microsoft Internet Explorer, Microsoft Sharepoint, Microsoft Office y
Microsoft Active Directory impiden que se pueda llamar neutral repecto a
plataforma y aplicación. Por otro lado, dependencias binarias como la
codificación de los hash de las hojas de cálculo (en C para Windows con
dependencias de little/big endian) o dependencias como el control de
impresoras DEVMODE, hacen que no se pueda decir que es "neutral" de
plataforma salvo que sólo se cuenten como plataformas los distintos sistemas Windows de la proponente Microsoft.

[11] http://mail.inen.gov.ec/pipermail/openxml/2007-August/000108.html


Sobre esto nunca hubo una respuesta en la lista de correo por parte de
los defensores de OpenXML. Es lamentable que se quiera aprobar un
estándard dependiente de la plataforma. Esto hace que OpenXML de
preferencia a los usuarios de Microsoft Windows.


Ante las discusiones expuestas y el documento con los comentarios
técnicos entregados a este comité podemos concluir que la mejor opción
para el Ecuador y el mundo desde el punto de vista técnico el voto del
Ecuador debe ser: NO CON COMENTARIOS.