Argumentos técnicos en contra de OOXML (I parte)

No hay que escarbar mucho para descubrir la verdad; solo que algunos no la quieren buscar…

Darse cuenta de tantas cosas en tan poco tiempo te hace despertar de ese “letargo” cultural al que estamos por lo general “sometidos” debido al intenso trabajo, a la desidia, a la idea de que “otros decidan por tí”, etc.

Un ejemplo es con OOXML; cuando te dás cuenta que de la noche a la mañana tu país deja de ser miembro O y pasa a ser miembro P de comité de normas sobre IT (JTC1) y más especificamente de la secretariat de Documentos e Información (SC34) y que además de tenerlo “bien secretito” no nos habian informado a la colectividad que de hecho “si están” estudiando a DIS 29500 por una inminente aprobación por FONDONORMA?.

Donde queda la “imparcialidad” de un comité cuando uno de sus miembros forma parte “completamente parcial” del proceso y de múltiples maneras?; un ejemplo es Nelson Maquhae, que aparece bajo el cuadro “representante de la Universidad Central de Venezuela”; pero todos sabemos que además es miembro tesorero, vice-presidente y por ende de la junta directiva de CAVEDATOS (otra de las miembros del CT54 de FONDONORMA); pero que además es Oficial de Tecnología de Microsoft; entonces?, por qué esconderse detrás de la cara de “representante académico” pero a su vez nombrar presentantes en el CT54 para esos entes?; una, la empresa de la cual una vez fue directivo regional y de otra, una Cámara de empresas de Software de la cual fue vice-presidente y ahora es directivo?.

Sin embargo, este artículo no es de política completamente; realmente no me interesa pelear en ese campo, otros pueden hacerlo, me interesa el ámbito técnico.

La guerra de “lo viejo” versus “lo nuevo”:
Alguien dijo que la guerra entre OOXML y ODF era una guerra entre “una evolución” y una “revolución” (dicho hombre es un empleado de Microsoft que escribe para zdnet, aunque perdí el link donde leí eso algún tiempo atrás), en el sentido que OOXML era simplemente un “cambio para mejorar” algo que ya existia, pero que debia mantener esos “genes rezagados” que podian causar mutaciones extrañas; que ODF era una “revolución” de esas que hacen cambios radicales por hacer mejor las vidas de toda la humanidad (pero claro, que podia simplemente bañar en sangre un país, según escribe el columnista); sin embargo, cabe mencionar que TODAS las excusas de Microsoft para no cumplir o usar estandares (sean ISO o no) no son técnicas sino de “compatibilidad” con su plataforma existente de oficina y sus viejos formatos binarios.
Un ejemplo es la adopción de mathML, ODF no incorpora gestión de formulas en su sistema de hoja de cálculo porque esto puede ser gestionado por mathML, la razón de inventarse un “spreadsheetML” no es para “mejorar” a mathML; sino para (“Functional differences between MathML and the capability supported by Microsoft Office require a different solution to maintain compatiblity for existing documents. – Microsoft . Response to use of MathML, INDIA ISO Discution”) mantener la compatibilidad con su vieja y querida “hoja de excel”.
Si vamos gastar recursos en convertir algo de horrible a menos horrible por qué no de horrible para mejor?; que prefieren?, cambio o revolución?.
Ejemplo: tomemos la fracción A+B/C (el mismo ejemplo que MS toma para defender su Office Math ML):
en Office MML sería:

<m:f><m:num> <m:mr>a+b</m:mr> </m:num> <m:den> <m:mr>c</m:mr> </m:den> </m:f>

Fijense que el operador está DENTRO de la función, lo cual hace “intraducible” el simbolo a otros idiomas sin tener que “desglosar” el tag m:num; claro, dividen entre operador y numerador; una “inversion” de la fraccion (convertir numerador en denominador) implica “volver a hacer la estructura XML” en cambio en mathML:

<m:mfrac> <m:mrow> <m:mi>a</m:mi> <m:mo>+</m:mo> <m:mi>b</m:mi> </m:mrow> <m:mi>c</m:mi> </m:mfrac>

Observen que la fraccion inversa es simplemente invertir (suffle de nodos); ademas el operador es aislado; si, puede que mathML sea menos “verbose” que OMML; pero cuando nos enfrentamos a cosas complejas como:

diff.gif
Se reduce a:
<apply><diff/>
<bvar>
<ci>x</ci>
<degree> <cn>3</cn> </degree>
</bvar>
<apply><fn> f </fn>
<ci> x </ci>
</apply>
</apply>

Cuantas tags necesitaremos para construir eso en OMML? (si es que se puede hacer diferenciales en Excel).

Estadísticas de Estándares:

Distribución de las 6000 páginas de la DIS 29500:
* ~100 son de partes “fundamentales y principios” del documento.
* ~200 paginas acerca de “empaquetado” del documento;
* ~450 paginas de un tutorial (a “page primer”);
* ~1850 referencias a WordProcessingML, el SGML de de documentos;
* ~1090 paginas de referencia a spreadsheetML;
* ~270 pagians referentes a presentacion del documento;
* ~1140 paginas sobre drawingML (que por cierto, no usará este formato office 2008);
* ~900 paginas sobre referencias “externas” a otros formatos Microsoft (VML, SharedML)
* ~42 paginas sobre “futura” (porque aun no tiene) soporte a accesibilidad de OOXML.

Aun si sumáramos todas las especificaciones “básicas” detrás de ODF tendríamos:
SPECS detras de OpenDocument:
ODF                     722 paginas
SVG                     719
MathML             665
XForms               152
XLink                     36
SMIL                   537
OpenFormula     371
—-
3.202 paginas

Lo que notamos es que la gran guerra que le tienen a ODF porque es un “estandar ligero” se debe a que en vez de “volver a re-inventar la rueda” usa cosas ya inventadas y que son estandares de algún tipo (muchos se quejan de la capacidad de formulas de ODF; pero para que inventarse un spreadsheetML si podemos implementar MathML y openFormula en un documento?).

Hasta la Web tiene que ver con OOXML:

Una de las cosas tristes que plantea Microsoft es desligarse definitivamente de la W3c en cuanto a estandares de la web, XML, SGML y demás proyectos; Microsoft quiere agarrar por su lado.

La NO utilización de XHTML 2.0 o de XML en favor de XAML!, el HTML de Microsoft para futuras versiones de .NET es una de esas formas.

XAML/WPF será el estandar “de facto” inter-operable de desarrollo (cuando sea aprobado OOXML) de todas las plataformas de desarrollo

Microsoft; al tener un “estandar” se puede dedicar a crear webServices que no hablen WSDL sino cualquier forma de XML que nazca de OOXML, XAML, WPF o familias de SGML-Like que tiene MS dentro.

Nota: tomar en cuenta que en el 2003 esta version de XUL de Microsoft (XAML) fue tema de litigio de patentes:
http://www.stylusstudio.com/xmldev/200312/post30280.html

Patentes, patentes, paTentes … 

En vista que perdieron el juicio de patentes, ahora quieren “regalarnos” esa patente? … :p

recordemos ademas que esa “combinacion mortal” de flash, flex, XAML con ajax está patentada bajo las leyes Americanas:
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=7,000,180.PN.&OS=PN/7,000,180&RS=PN/7,000,180
El “no demandar por patentes” se reduce a Microsoft y sobre desarrolladores directos, no sobre, por ejemplo, clientes o empresas third party que estuvieran alrededor del “nucleo” microsoft y que son dueñas de patentes e “independientes” de demandar.

.NET WinForms es una forma de esquematizacion de formularios XML QUE NO USA el estandar ya existente XForms (que ya usan Java, Python, Perl y será aprobado en XHTML 2.0); donde está la inter-operatibilidad en eso?.
Ej. hasta el momento, Mono.NET soporta WinForms 1.1 y es solo usable en X11 (no inter-plataforma).

De hecho, observando la “adopción” de .NET, algunos “expertos microsoft” o “usuarios .net” (como el blog de Miguel de Icaza); la real y gradual adopción de WPF como un “estandar de facto” ya no es posible; pues requiere que el software del mundo sea re-escrito para poder ser usado (dicho por Miguel de Icaza en su blog).

pero OpenOffice tambien lo tiene!
en un articulo hablan de que Microsoft “si documenta” sus “applications features”:

(http://blogs.msdn.com/brian_jones/archive/2007/02/20/beyond-the-basics.aspx)

sin embargo, la corresppondencia está mal; la aproximacion de ODF es a través de la sección “application settings” donde puedes agregar cualquier configuración de aplicación “No alcanzable” por otras aplicaciones; es decir, ODF no incluye directivas como “ZoomFactor”; porque esto es de OpenOffice y OpenOffice usará esta sección de “application Settings” para agregar dicha información; sin embargo, este nombre “zoomFactor” o “VisibleArea” puede ser usado por otras aplicaciones para la construcción de “Comportamientos de la aplicación basadas en el documento”; sin embargo, vendiendonos gato por liebre, dicen que sus “especificaciones” son “full documentadas” pero como puede ejemplo; Koffice puede implementar un setting llamado “autoSpaceLikeWord95”?, o “footnoteLayoutLikeWW8” o “lineWrapLikeWord6”?, mientras los settings de ODF son inter-operables entre distintas aplicaciones y extendibles en el futuro, algo llamado “como word 95” es del pasado, simple remanente de querer ser compatibles con una aplicación, no con un estandar.
y ni dejen atras a “uiCompat97To2003”; por qué algo así debe estar en un estandar?.

Incluso, Microsoft puede agregar sus “application features” (como ese “uiCompat97To2003”) dentro de la sección “application settings” de ODF y crear un word document a partir de un ODF; puede ODF agregar (en alguna parte) una directiva “zoom” sin verse en conflicto con las ya creadas por MS Office? (recordemos que no todos los specs de MS Office están liberados, solo “aquellos” que importaban a la norma DIS 29500).

La historia del “date bug” o como echarle facil la culpa a otro:

“When Lotus 1-2-3 was first released, the program assumed that the year 1900 was a leap year, even though it actually was not a leap year. This made it easier for the program to handle leap years and caused no harm to almost all date calculations in Lotus 1-2-3. When Microsoft Multiplan and Microsoft Excel were released, they also assumed that 1900 was a leap year. This assumption allowed Microsoft Multiplan and Microsoft Excel to use the same serial date system used by Lotus 1-2-3 and provide greater compatibility with Lotus 1-2-3. Treating 1900 as a leap year also made it easier for users to move worksheets from one program to the other.”

Como ven, no es un “bug”, es una “feature” (como cosa siempre rara en MS que admitan un error); la culpa viene de los años 80 y de intentar ser compatibles con una “exitosa” hoja de calculo de la epoca; tambien se hicieron “compatibles” en los bugs; esos son los errores que se cometen cuando, en vez de seguir estandares, se persiguen “compatibilidades comerciales de facto”.

Ahora bien, por qué no corregirlo AHORA en la DIS 29500?, porque de hacerlo, hacer un “plugin” de migración les daría mucha pereza (se cansaron de escribir 6000 páginas y el cerebro no les dá para más)  y costaría que todas las hojas de excel del planeta tierra decrezcan un día en sus formulas; corregir este valor tomaría DEMASIADO TIEMPO Y DINERO, especialmente en formulas que usan fechas (o sea, que excusa!).

  • Algunas formulas como WEEKDAY dependen de ese bug, por que reportaría días anómalos y mostraría fechas incorrectamente.

Nota: seguimos jugando a la “application compatibility” y no al “estandar Compatibility”, que le debe importar a un estandar ISO a que una “UNICA Y SOLITA” aplicación no sepa usar WEEKDAY?, es como que HP diga que no puede fabricar impresoras A4; por qué no “escribir otra norma” de papel para reducir medio centimetro el papel?…
Corregir este “comportamiento” (fijense que no lo llaman bug) puede dar SERIOS problemas de compatibilidad entre Microsoft Excel y otros programas de MS que usan fechas (o sea, HAN ADMITIDO que otras aplicaciones de MS tienen el mismo fallo?).

Pero, si el problema se mantiene sin corregir, solo pueede pasar una cosa (o sea que bonito, no se va a corregir):

  • la función WEEKDAY retornará valores incorrectos para fechas antes del 1 de marzo de 1900; como la mayoría de las personas del planeta ya no son del 1900 para atrás, entonces cual problema hay?.

    Me parece lógica la idea; por qué no quemamos todos los libros de historia?, es que realmente nadie está vivo de esa época para que los verifique así que para que conservarlos?.

Para Microsoft, SpreadsheetML el siglo comienza en marzo 1 de 1900 y no el 31 de Diciembre de 1899.

Una explicación “detallada” de por qué no puede haber inter-operatibilidadISO 8601 y el formato interno de fecha de spreadsheetML:

“If you can support ISO 8601 formats in spreadsheet then please explain how you would handle this example:

Spreadsheets generally use an internal format for date calculations. It would be very difficult to maintain integrity between such an internal format and an ISO standard representaion in de document file.

For instance when two date are subtracted in ISO that leaves a ‘period’ it would be something that is very weird implementing into a spreadsheet.

Example:

Cel a contains 20070214T131031

Cel b contains 20070214T131030

Cel c contains 20070214T131030/20070214T131031

These are all correct ISO 8601 where in cell c there is effectivly a 1 second

‘period’ that corresponds with the difference between cell a and cell b.

In an internal spreadsheet formula format that would represent as:

Cel a 39127,548969907400

Cel b 39127,548958333300

Cel c 0,000011574113

This is an example of the internal Excel 1900 date format where in cell c also is a 1 second period that corresponds with the difference in cell a and cell b.

However it is virtually impossible to go from ISO to internal format and then convert back to ISO without data loss.”

sobre el OpenXML translator:
http://blogs.msdn.com/brian_jones/archive/2006/07/05/657510.aspx

CleverAge es una empresa que ha diseñado un convertidor ODF; dicho “conversor” no está directamente en el menú de Office 2007; sino que hay que “descargarlo” aparte; desde cuando openOffice tiene en su menú a Office y a otros formatos (PDF) sin tener que decirle al usuario que eso es “un plugin aparte, que requiere una aplicación adicional?”.
(http://sourceforge.net/projects/odf-converter/)
Donde queda entonces la “libertad para escoger del usuario”? si solo verá un formato y tendrá que “descargar” los otros formatos que desee como “plugins?.

Para una empresa creadora del J++ (con el cual Sun les ganó una batalla por Java), del JScript (el enemigo del ECMAScript y campeón de nuestros sufrimientos del código “cross-browser en javascript), de los ActiveX (que solo corrian en sus versiones windows de IE, ni siquiera en el IE de Mac) ahora se declaran los “campeones de la inter-operatibilidad?!!.

Carta Abierta a la Bondad 

Ellos en “carta abierta” (http://www.microsoft.com/interop/letters/userchoice.mspx) indican que el “usuario” debe escoger sus formatos; pero si le pones en el menú un solo formato?, si las opciones “alternativas” requieren una “descarga adicional” la cual el usuario nunca o casi nunca va a hacer por desconocimiento?, por qué el conversor massachussets (http://searchenterpriselinux.techtarget.com/originalContent/0,289142,sid39_gci1144104,00.html) pone tantas “alertas al usuario” de que lo que está intentando abrir es malo, desonesto, que no cumple con EULAs y ese tipo de cosas que solo a los de Redmont-Windows Vista se les ocurre?.

Crear un “Menu separado” para un estandar ISO es una clara des-integración (en vez de integración) de documentos; eso hace imposible una “transparente importación”; lo cual incluso es malo para ellos; un usuario de un ODT no podrá abrir su documento en Office a menos que se descargue un plugin, lo instale, realice la importación y conversión respectiva (con todas sus amenazas), uno a uno por todos los documentos que se tengan; por qué no agregarlo al menú “abrir como … ” y “guardar como … ” como TODO el mundo regularmente en las aplicaciones hace con los formatos de Microsoft?.

Nota: Tampoco puedes decidir que ODF es el “formato por defecto” para guardar un documento en vez del docx (binario) o el OOXML.
Mas información:
http://holloway.co.nz/can-other-vendors-implement-ooxml.html

Nota final: como una empresa liderada por una persona (Steve Ballmer) que piensa estas cosas del Software Libre

(http://money.cnn.com/magazines/fortune/fortune_archive/2007/05/28/100033867/); podemos confiar en que están por otro lado, diseñando un estandar completamente libre y ajeno a patentes de software, licencias y libre completamente de royalties?.
Hay que ser ingenuos para confiar en ellos.

Más para leer:

Priorizando estandares:
http://www.groklaw.net/articlebasic.php?story=20070720073215943

Con respecto a FONDONORMA:
Todos por favor, en base a estos y otros problemas técnicos, aboguen por qué FONDONORMA, segun la regla 9.8 de ISO, votar NO con comentarios o al menos abstenerse (pero nunca votar Si); si alguien (como ha pasado en Alemania o Portugal) no presenta argumentos técnicos en contra; se puede votar Si, sino, debe votarse NO y agregar los comentarios (reglas de los “fast-track”, por eso es que Microsoft NUNCA ha admitido que OOXML tiene errores, sería admitir que el DIS 29500 nunca debió ser colocado en “fast-track” y debió pasar por el proceso regular de evaluación, escrutinio, revisión y corrección de errores, etc).

Mas articulos al respecto:
http://stephesblog.blogs.com/my_weblog/2007/02/index.html
http://groklaw.net/article.php?story=20060725104331240
http://blogs.infosupport.com/wouterv/archive/2007/07/22/Questions-on-Open-XML.aspx
http://boycottnovell.com/category/sun/
Venezuela es miembro P de la secretariat del JTC1-SC34
http://www.jtc1sc34.org/document/secretariat_temp.html#pmbr

Acerca de phenobarbital

http://about.me/phenobarbital

Publicado el 24 agosto 2007 en Cultura Libre, La soda y la pastilla, Linux, PlanetaLinux, Política. Añade a favoritos el enlace permanente. 5 comentarios.

  1. Miguel de Icaza

    Veo que borraste mi comentario que contradecia varias falsedades de este post.

    Nos dio verguenza?

    Miguel.

  2. No, simplemente no quiero “flames” en mi post, pero si quieres lo coloco; por ahi lo tengo guardado …

  1. Pingback: Phenobarbital con Soda » Blog Archive » Libertad versus apertura en Silverlight (o II parte de No a OOXML)

  2. Pingback: Util PC Blog » Blog Archive » OOXML Probado como Estandar ISO. Hasta cuando Microsoft!!!????

  3. Pingback: [Nota del día] Sobre quienes escriben las leyes (y II Parte) | Phenobarbital con Soda!

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: