[inenjtc1] Las 10 peores respuestas del BRM

Jue Mar 27 19:29:57 ECT 2008

Less envío la traducción de este documento de la ODF
Alliance sobre el fiasco que supuso el BRM:
http://www.odfalliance.org/resources/Oracle%20Comments%20on%20DIS%2029500.pdf

David B.

OOXML – Las peores 10 respuestas (y una cosa más...)

Si tiene la poco envidiable tarea de revisar la
Disposición de Comentarios propuesta por Ecma sobre
dis 29500 – la especificación para OOXML- podría estar
inicialmente impresionado de que Ecma y Microsoft
hayan producido respuestas para todos los cientos de
no conformidades que han surgido acerca de la
especificación.

Sin embargo, si se toma su tiempo para familiarizase
con el contenido de sichas respuestas, verá que no
todas las no conformidades están resueltas de forma
que mejoren o hagan progresar la especificación. Para
que se divierta, aquí tiene una lista (disculpas a
Dave Letterman) de las 10 Peores Respuestas de Ecma.

10. Peor Petición Ignorada – Respuesta  620 –
Identifica 'w:sz' como un elemento con 'graves
inconsistencias internas'. Los elementos tienen
unidades de medios puntos, puntos, píxeles,
porcentajes, etc, dependiendo del contexto, y cuando
se usan como un atributo puede ser de octavos de
punto, centésimas de punto, porcentaje de la pantalla
o incluso los valores "completo", "mitad" y "cuarto".
La respuesta confirma que "el atributo/elemento sz
tiene diferentes significados dependiendo de su
elemento padre", pero insiste en dejar las cosas
igual. No se aporta ningún cambio.

9. Peor No-Respuesta – Empate!! Respuestas 759 y 862 –
Ambas simplemente citan el comentario. Para la
respuesta 759 la disposición propuesta dice: "En la
fila Numeración de la tabla en la Parte 4,
§2.16.5 página 1508, la segunda parte de la
descripción de "Numeración" no tiene sentido." Tan
solo eso, sin cambios.

8. Peor uso de XML – Respuesta 559 – El uso del
elemento 'e' rompe las convenciones de uso de XML. La
respuesta de Ecma cita 18 usos diferentes para el
elemento 'e' pero no resuelve el problema, sino que
evidencia aún más la pobre calidad de esta
especificación y la forma impropia en que se ha
empleado XML. No se aporta ningún cambio.

7. Peor Introducción de Agujeros de Seguridad –
Respuesta 102 – Esta respuesta de Ecma, proporciona
una lista de valores reservados para algoritmos de
hash y tras los cuatro primeros (MD2, MD4, MD5 y
RIPEMD-128) sigue esta nota: "Se recomienda que las
aplicaciones eviten usar este algoritmo para almacenar
nuevos valores de has, debido a vulnerabilidades
públicamente conocidas"

6 Peor Táctica de 'Puerta Trasera' – Respuesta 82 – El
comentario pide 'especificar' o 'eliminar' el elemento
'ink' que es un posicionador para una funcionalidad
no-interoperable y definida a nivel de aplicación.
La propuesta de Ecma añade un tipo de elemento al
esquema XML y recomienda usar InkML, que es un
Borrador de Trabajo del W3C, pero deja abierta su
capacidad para el uso de formatos no interoperables
definidos a nivel de aplicación. Para empeorar el
problema, la respuesta está plagada con referencias a
VML, el cual se propone considerar desaprobado
(deprecated) en otras respuestas, diciendo incluso 'Un
objeto ink es un objeto VML...'. ¿Se está
reintroduciendo VML en la especifiación?

5. Peor 'Tirar el niño con el agua de la bañera'
('Baby and Bathwater' parte de una expresión popular
de EE.UU, que significa eliminar lo bueno junto con lo
malo) – Otro EMPATE! Respuestas 425 y 624 – Los
comentarios piden soporte explícito para objetos
ebebidos para KDE y Gnome, además de para los objetos
OLE de Microsoft. La respuesta de Ecma dice que OOXML
permite "un método general para incrustar objetos
desde un componente tecnológico externo" y elimina
toda las referencias a OLE. A la luz del abuntante uso
de la inclusión de objetos OLE en los actuales
documentos de MS Office, la interoperabilidad depende
fuertemente de esta funcionalidad. Cambiar el lenguaje
de la especificación para no llamar directamente
"objetos OLE" a los objetos embebidos (i.e. eliminar
la referencia normativa) tiene el potencial de
degradar sustancialmente la interoperabilidad de los
documentos OOXML. Esto hace que los objetos embebidos
queden a discreción de la implementación a los ojos de
la especificación.

4.Peor Estandarización de un error de Microsoft –
Respuesta 782 – El comentario cuestiona un ejemplo
para FILESIZE en el que 4660736 bytes se redondea a
4661 kb. Esto es incorrecto; se utiliza una división
por 1000 en vez de 1024. El resultado debería ser 4552
kb. En vez de corregir el ejemplo, la propuesta de
Ecma cambia la unidad de 'kilobyte' a 'miles de bytes'
(y 'megabyte' a 'millones de bytes'

Esto resulta extraño, porque los tamaños de archivo se
calculan normalmente en kilobytes y megabytes. Esta
propuesta sugiere que hay un error en la aplicación
actual de Microsoft, en donde el programador dividió
por 1000 en vez de 1024 (y 1000000 en vez de 1048576
que es 1024+1024) La propuesta de Ecma favorece este
error por encima del comportamiento obvio.

3. Peor respuesta para 'conseguir lo que quieres de
cualquier manera' – Respuesta 43 – La respuesta de
Ecma sugiere que en vez de tener una forma
estandarizada de representar las fechas (ISO 8601),
¡debería haber cinco! Además de ISO 8601, proponen dos
representaciones heredadas con 1900 y 1904 como fechas
base, sin soporte para fechas anteriores a esos años,
más dos representaciones totalmente nuevas basadas en
los sitemas de 1900 y 1904 que manejen los años
anteriores a las fechas base pero que no están
completamente definidas.

2.Peor Duelo a Muerte entre Respuestas – Respuesta 222
y Respuesta 691 – En este ejemplo, de considerable
importancia, las dos propuestas llegan a conclusiones
opuestas en una pregunta sobre precedencia entre el
texto y los esquemas en los anexos electrónicos. Cual
de estas dos fuentes es definitiva es extremadamente
importante para la definición. La respuesta 222
propone eliminar una linea de texto dando precedencia
a los esquemas, diciendo "Conforme; esta afirmación
debería ser elminada"

La respuesta 691 rechaza esa misma propuesta diciendo
"Disconforme." y "... las versiones en formato ZIP
deben considerarse las versiones definitivas.".

1. Peor caso de emplear días de mi vida leyendo todas
estas respuestas – Respuesta 885 -
"Conforme; las características desaprobadas
(deprecated) no deberían usarse en documentos creados
de cero con Office Open XML." TODOS los documentos
OOXML se CREARÁN DE CERO. Aunque hay muchos documentos
en los formatos binarios anteriores, solo unos pocos
están en el formato OOXML que ni siquiera está
terminado todavía. Excepto para un número
extremadamente pequeño de documentos (un error de
redondeo comparado con el a menudo citado 'corpus de
documentos existentes'), todos los documentos OOXML se
crearán "de cero" o bien creandolos desde el principio
o bien convirtiendo los documentos binarios
existentes. Si lo que diferencia a OOXML y ODF son las
características de compatibilidad con formatos
antiguos (ver la Respuesta 926 para el ámbito
revisado), y estas características están desaprobadas
y no deben usarse, entonces, en primer lugar para qué
estamos haciendo todo esto?

Pero espere, hay un Bonus de Peor Respuesta...:
Peor 'Nos Ocuparemos de eso Después' – (¡UN EMPATE!)

Respuesta 803 – Los comentarios piden una definición
clara de los parámetros de definiciones de funciones.
La respuesta de Ecma promete proporcionarla pero solo
da 3 ejemplos de cómo se harán los cambios. Debido a
que las definiciones de funciones son fundamentales
para la interoperabilidad de las hojas de cálculo,
estos son cambios con importantes consecuencias.

Respuesta 1 – Uso impropio de la palabra "shall"
(futuro). Hay más de 6000 ejemplos de esta palaba y la
respuesta de Ecma es "Conforme, algunos usos del
futuro, el condicional "podría", y demás son
inconsistentes. En vez de enumerar todos los sitios
que necesitan cambios en esta respuesta, los
comentarios generales sobre dicho uso se resolverán
con una revisión editorial sobre todas las secciones:"

Lo que es interesante es que estas disposiciones
propuestas (si se aceptan en el BRM) no pueden ser
revisadas antes de que el borrador final de DIS 29500
esté disponible, lo que es probable que ocurra despues
de que los Organismos Nacionales (NBs) se reunan para
finalizar sus votos.

Para aquellos con acceso al documento de disposiciones
propuesto por Ecma, aquí estan los números de
comentarios de los NB referenciados a las respuestas
de Ecma:

Respuesta 1 (AU-0007, DE-0042, DK-0076, ECMA-0018,
GB-0014, JP-0006,
JP-0007, JP-0008)
Respuesta 43 (AU-0016, BR-0046, CA-0044, CH-0006,
CH-0007, CH-0017,
CL-0013, CL-0147, CO-0035, CO-0154, CO-0155, CO-0156,
CZ-0009, DE-0030,
DE-0031, DE-0032 ,DE-0072 ,DK-0033, DK-0136, DK-0137,
DK-0153, FI-0013,
FR-0182, FR-0183, FR-0351, GB-0300, GB-0301, GB-0304,
GB-0363, GB-0364,
GH-0002, GR-0003, GR-0004, GR-0005, GR-0006, IE-0002,
IN-0007, IN-0057,
IN-0058, IN-0061, IN-0080, IR-0001, IR-0002, KE-0054,
KE-0055, MX-0005,
PE-0002, PE-0003, PH-0005, PT-0085, SG-0002, US-0130,
US-0131, UY-0003,
VE-0011, VE-0060, ZA-0014)
Respuesta 82 (BR-0057, CL-0209, FR-0373, GB-0485,
PT-0111, US-0157)
Respuesta 102 (CA-0037, CL-0027, CL-0028, CL-0055,
CL-0197, CL-0202,
CO-0096, CO-0143, CO-0146, DK-0030, DK-0114, DK-0139,
FR-0338, FR-0341,
FR-0345, GB-0219, GB-0291, GB-0292, B-0298, GH-0008,
GR-0021, GR-0022,
GR-0076, IN-0010, IN-0026, IN-0063, IN-0064, IN-0077,
IR-0012, IR-0047,
JP-0068, KR-0024, MY-0017, PT-0090, PT-0091, PT-0093,
US-0027, US-0051,
US-0138, US-0144, US-0252, VE-0001, VE-0017, VE-0054,
ZA-0009)
Respuesta 222 (GB-0061)
Respuesta 425 (DK-0031)
Respuesta 559 (GB-0537)
Respuesta 620 (IN-0011)
Respuesta 624 (DK-0032 and ECMA-0045)
Respuesta 691 (DK-0053)
Respuesta 759 (FR-0147)
Respuesta 782 (GB-0256)
Respuesta 803 (FR-0453)
Respuesta 862 (FR-0356)
Respuesta 885 (GB-0013)

http://www.endsoftwarepatents.org

-- 
Saludos/Greetings
Quiliro Ordóñez
593(02)340 1517 / 593(09)821 8696
Por favor evite enviarme archivos adjuntos en Word, Excel, Power Point
porque son formatos privativos que retrazan el desarrollo tecnológico de
nuestro país.
http://www.gnu.org/philosophy/no-word-attachments.es.html

-- 
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que está limpio.
For all your IT requirements visit: http://www.transtec.co.uk

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://mail.inen.gov.ec/pipermail/openxml/attachments/20080327/c0bd157d/attachment.html 