[Openxml] Comentarios sobre las respuestas de Microsoft

[Ricardo Argüello]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Estimados/as miembros del comité DIS-29500:

A continuación les presento mis comentarios a las respuestas presentadas
por Microsoft ante los cuestionamientos técnicos de Rafael Bonifaz,
sobre el estándar propuesto DIS-29500, también conocido como OOXML.

Todos los comentarios fueron elaborados por mi y no los traduje de
ninguna otra persona, entidad o empresa. Estos comentarios representan
la opinión de Soporte Libre Cía. Ltda., compañía a la que represento
dentro del comité DIS-29500 del INEN.

Entre comillas irá la cita con el texto original de la respuesta
proporcionada por Fabio Rodriguez de Microsoft, y luego mis comentarios,
en forma intercalada.

En vista de que el mensaje original del señor Rodriguez no fue enviado a
la lista de discusión openxml en inen.gov.ec sino a individuos por
separado, puede que este mensaje les llegue dos veces, les pido
disculpas de antemano. Para una próxima ocasión por favor enviar todos
los mensajes a openxml en inen.gov.ec, como en cualquier lista de
discusión, no a direcciones por separado.

- ---------------------------------------------


1) Part 4, Section 3.17.4.1, Page 2522:

"Los formatos de fecha en Open XML son formatos diseñados para dar
soporte de mejor manera a las bases fundamentales con las que se
construyeron aplicaciones legadas existentes."

Esas aplicaciones "legadas" fueron desarrolladas cometiendo errores
evidentes, que están siendo demostrados ahora. En mi opinión, una norma
no debe de repetir errores tan obvios como los de las fechas.
Adicionalmente, estamos hablando de una norma, no de una implementación.

"Los formatos de Open XML permiten dos formatos de fechas. La primera de
ellas es utilizando el año de 1904 como línea base sin contradecir de
ninguna manera si el año 1900 fue o no un año bisiesto. Por ello los
desarrolladores pueden hacer uso este formato sin contradecir con el
Calendario Gregoriano declarado en la ISO 8601:2004."

Los dos formatos de fechas son incompletos, incorrectos y no contemplan
años anteriores a 1900. Adicionalmente, el estándar ISO-8601 no
"declaró" el calendario Gregoriano, simplemente utiliza del mismo los
tamaños de los meses y las reglas para el cálculo del año bisiesto.

"El segundo formato utiliza como año base 1900 con el fin de mantener
una compatibilidad con la base de documentos existentes."

Se aplica nuevamente mi anterior razonamiento: Por que repetir los
errores técnicos cometidos en la implementación de soluciones
propietarias anteriores?

"Como estos dos sistemas de fechas base dan conformidad con el estándar
y compatibilidad, no hay necesidad de definir un rango de base de fechas
declaradas por diferentes vendedores."

La necesidad si existe, como demostró muy claramente el señor Rafael
Bonifaz en su exposición. Su observación se mantiene: No se pueden
representar fechas anteriores a 1900 en el formato OOXML. En mi opinión,
las explicaciones proporcionadas no satisfacen las dudas acerca de este
tema.

"La mayoría de usuarios no llegan a usar fecha menores a Enero 1, 1900"

Falso, como quedo demostrado en la exposición de Rafael Bonifaz.

"e incluso el estándar ISO 8601 utiliza fechas Gregorianas,"

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 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."

El decir que este problema afecta solamente a historiadores y
genealogistas es una justificación totalmente simplista. Existen cientos
de ejemplos que podría utilizar, pero dejaré al lector el trabajo de
buscarle utilidad a fechas anteriores a 1900 en sus hojas de cálculo...
Y aun así, solo el hecho de que este problema afecte a historiadores y
genealogistas es suficiente para justificar la negativa a la
estandarización de este formato.

"Es por ello que no hay necesidad de indicar fechas antes de 1900."

Un juicio totalmente desacertado, y sin ninguna justificación técnica,
en mi opinión. Las razones expuestas para no soportar fechas anteriores
a 1900 son solamente razones de conveniencia para los autores de la
especificación OOXML, mas no para la comunidad en general. Un estándar
de nivel mundial no debe limitar el rango permitido de los años,
repitiendo errores de productos comerciales "legados".

- ---------------------------------------------


2) Part 4, Section 3.17.4.1, Page 2522:

"El sistema de base de datos de 1900 utiliza un comportamiento heredado
donde la línea base es el año 1900 y con el fin de mantener
compatibilidad con la base de documentos existentes, tiene un
comportamiento que emula el error para los primeros 60 días del año 1900."

Un estándar no debería "emular" errores de productos comerciales
implementados en forma errónea. un estándar no debe de servir a las
conveniencias de un vendedor sino de sus usuarios.

"La discrepancia con respecto a que el año 1900 es un año bisiesto no
presenta inconsistencias con la ISO 860:2004, pero ello se da debido a
que se necesita mantener una compatibilidad con herramientas como Lotus
Notes desarrollado por IBM y las primeras versiones de Microsoft Excel
ya que estas manejan el año 1900 como año bisiesto. Cuando Lotus 1-2-3
fue lanzado al mercado, el programa asumió que el año 1900 fue un año
bisiesto, a sabiendas que no lo era, esto hizo más fácil para el
programa manejar años bisiestos sin causar daño a todos los cálculos de
fecha utilizado por Lotus 1-2-3. Cuando Microsoft Multiplan y Microsoft
Excel fueron lanzados, también se asumió que el año 1900 era un año
bisiesto. esto permitió una mayor compatibilidad con Lotus 1-2-3."

Es una historia muy interesante, pero, en mi opinión, no justifica la
decisión de perpetuar dichos errores de implementación.

"Es así que para usuarios finales les resultó fácil mover hojas de
calculo de un programa a otro, debido a que se trato al año 1900 como
año bisiesto. El defecto solo afecta los primeros 60 días del año 1900.
No tiene ningún impacto en las fechas posteriores, así que no afecta de
ninguna manera a su uso futuro. Debido al pequeño impacto que
proporcionaba éste defecto, y al uso global de este comportamiento, se
determinó, que no era factible realizar cambios ya que acarrearía un
impacto negativo en la herencia de documentos de los usuarios."

El "pequeño impacto" de este defecto no permite confiar en cálculos que
incluyan el año 1900. En mi opinión no se justifica la compatibilidad
hacia atrás cuando se violan convenciones tan importantes como las de
las fechas. Entiendo que implementaciones de software anteriores tengan
errores tan garrafales como este, pero por que se deben perpetuar en el
tiempo en vez de corregirlos? No se pueden elevar a categoría de norma
los "trucos" utilizados en la implementación de productos de software
con evidentes errores de implementación. Estamos hablando de un norma,
no de una implementacion de software, aquí no existen los Service Packs...

- ---------------------------------------------


3) Part 4, Section 2.15.1.86,

"Bitmask es usado con el fin de permitir que el formato sea construido
matemáticamente. Ello ofrecerá una manera fácil y flexible de dar
formato. Los valores basados en Bitmask son útiles para ahorrar espacio
en el registro y para optimizar los valores de comparación. Bitmask,
realmente no limitan la implementación o interoperabilidad si son
definidos correctamente y puede ser validados a través de XLST. Una de
las metas de diseño es una compatibilidad hacia atrás, donde los valores
de bitmask son usados"

Un bitmask representa un conjunto de valores para varios parámetros en
una sola variable. Por ejemplo "1011" podría representar "Si No Si Si"
para el conjunto de parámetros "Negrillas, Centrado, Pie de Pagina, Con
borde".

Al momento de expresar un documento en formato XML, pierde el sentido de
utilizar bitmasks, puesto que toda la información debería ser expresada
en forma literal mediante elementos, por ejemplo:

<formato>
  <negrillas>true</negrillas>
  <centrado>false</centrado>
  <pie_de_pagina>true</pie_de_pagina>
  <con_borde>true</con_borde>
</formato>

donde el texto "true" o "false" es de tipo xsd:boolean.

El lenguaje XSLT no es un lenguaje de verificación como erróneamente se
menciona en la respuesta,
sino un lenguaje de transformación. Por tanto es falso que "puede ser
verificado
a través de XLST". El lenguaje de verificación a utilizar para validar
documentos OOXML debería ser XML Schema (XSD), que no soporta un
análisis tipo bitmask. Esto hace que corroborar la validez de una
instancia de documento XML que diga ser valida contra el XSD de OOXML
sera una tarea difícil, por que tendrá necesariamente que incluir
programación. Este tipo de validación que no utiliza un XML Schema es
una pésima practica y debe ser corregida, en mi opinión.


- --------------------------


4) Part 4, Section 2.3.3.19:

"Cualquier objeto que se encuentre dentro de un documento OOXML es
guardado en el paquete en una carpeta separada y la representación de la
imagen del objeto es usada para indicar el objeto en el documento.
Cuando el objeto enlazado es desplegado como una imagen en el documento,
las propiedades son especificadas usando sintaxis VML. La razón para
usar sintaxis VML para representar objetos como una imagen en el
documento es para brindar compatibilidad con la herencia de documentos."

El formato VML fue propuesto a la W3C para su estandarización en 1998 y
fue rechazado. Existen otras alternativas, por ejemplo SVG, de la W3C.

- --------------------------------------


Espero que mis comentarios sirvan para debatir técnicamente este tema.

Saludos,

- --
Ricardo Argüello <ricardo.arguello en soportelibre.com>
Red Hat Certified Engineer / Red Hat Certified Instructor
Soporte Libre Cia. Ltda.
+593 (9) 603-5996

Fabio Rodriguez wrote:
> Adjunto documento con todas las respuestas en ingles y algunas en español.
> 
> Saludos
> 
> Fabio R

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG0bVVmShjc7F2f+wRAplFAKCToSeGU9s09Xy3zeBd6m427gGnZgCeKY6/
vQW6NzDmyZMsyTizw70vX9g=
=7WtA
-----END PGP SIGNATURE-----