Estándares, estándares...

| | Comentarios (2) | TrackBacks (0)
debate.jpgEn estos momentos hay una intensa discusión sobre la manera en que debe votar Chile con respecto a la adopción de OOXML como estándar ISO.

Ayer se realizó una reunión en el INN donde se pudo exponer el punto de vista de los criticos a la adopción de este estándar.

Personalmente me he convencido de que adoptar OOXML como estándar sería pésimo, por razones técnicas, y comerciales, al final esto sólo lleva a perpetuar el lock in de un proveedor específico: Microsoft.

Hay argumentos sin fundamentos, y que tratan de confundir (para variar), y qué sólo dejan mal a quienes los esgrimen.

Ejemplos de estos malos argumentos se encuentran en las respuestas a sus lectores en el blog de José Antonio Barriga.

El primer argumento dice:

No sé si eres programador ni tampoco si sabes que la ISO tienen un sinúmero de lenguajes de programación (ISO FORTRAN, ISO PASCAL, ISO Eiffel, ISO Common LISP, ISO C, ISO BASIC, ISO ADA, ISO C++, ISO C#, ISO EcmaScript, por nombrar algunos).¿ Como es esto si finalmente todos ellos generan un código binario que se netinede[sic] con la CPU? ¿Para que´tener tantos lenguajes? Recuerdo las peleas que tenía entre mis colegas si la papa era C++ o Fortran (si Fortran aunque ustedes no lo crean!)... al final el tema es que cada lenguaje está "diseñado" para resolver de una forma particular un algoritmo. Lo anterior nos lleva a que no existe un mejor lenguaje que otro, sino que dependiendo de cómo es mi set de información voy a ocupar uno u otro. (Recuerdo haber programado una calculadora en Cobol! Porque la circunstancia así me lo recomndaba[sic] ).

Hace años le hicieron esas preguntas a Microsoft con respecto a .Net, ¿para que soportar tantos lenguajes? ¿por qué no concentrarse en un sólo lenguaje, como lo hace Java?

La razón es muy simple, existen diversos lenguajes porque no todos los lenguajes de programación son de propósito general, pero es más, incluso los autodenominados lenguajes de propósito general no lo son.

Existen lenguajes específicos porque han sido definidos para distintos dominios de soluciones, los lenguajes son herramientas para los programadores. Podemos usar un alicate para clavar, o un destornillador como gubia, pero no fueron diseñados para esos usos.

Por eso que, así como existen estándares para cada herramienta, es obvio que exista un estándar para cada lenguaje de programación.

Pero esto no aplica para este caso. OOXML y ODF son dos estándares orientados para resolver el mismo problema, representar un documento, para su posterior transporte, impresión, almacenamiento, etc.

OOXML hace lo mismo que ODF, pero agrega una complejidad innecesaria. Además tiene muchos errores de consistencia, re inventa unidades de medida, e impone el uso de formatos patentados por Microsoft, algo que no es aceptable en un estándar ISO.

Acá hay que hacer una aclaración. Algunos que argumentan que LaTex es mejor que OOXML y ODF, o que PDF es un mejor estándar que ODF, la verdad es que están confundiendo las cosas. Estos formatos se encargan de resolver problemas en distintas etapas de la vida del documento (LateX para componer, OOXML y ODF para almacenar y compartir, y PDF para visualizar con calidad de impresión).

Pero si es XML...

El segundo argumento es bastante malo en realidad, y comete mismo error que cometieron en el gobierno al definir que la interoperabilidad de documentos electrónico sólo exige que estos sean XML y que estén disponibles los schemas respectivos (¿que hubieran pensado si el gobierno sólo exigiera que un documento electrónico esté formado por un conjunto de bytes?).

El segundo argumento va así:

"...en Wikipedia la cantiada[sic] de estándares ( mas de 140) basados en XML y que yo sepa, no ha pasado nada. Cada cual representa una realidad distinta y podrás ver que existen varios sobre la misma materia. Es mas , la Contraloría General de la república, a raiz del decreto del documento electrónico, creo su propio "estándar". Una cosa buena es que ese si puede ser incluído dentro de OXML pues, éste es extensible por diseño."

XML es un metalenguaje. Es una forma de ordenar documentos electrónicos en forma libre, y tiene reglas muy simples en realidad, una de las razones por la que ha sido exitoso (y también la causa de tanto abuso de este formato).

Cualquier cosa hecha sobre XML es extensible por diseño, eso no es ninguna gracia.

XML es como el alfabeto latino, pero uno puede escribir en francés, inglés, castellano incluso en chileno, usando el mismo alfabeto.

Así como se puede decir cualquier cosa usando el alfabeto latino, del mismo modo se puede decir cualquier cosa con XML, pero no todo es relevante, y no todo se entiende.

Decir que los documentos electrónicos deben estar en formato XML no es suficiente. Porque puedo convertir cualquier información en formato propietario, pasarlo a base64 e insertarlo como un blob entre dos etiquetas XML, de la siguiente manera:

<?xml version="1.0" ?>
<DocumentoElectronico>
TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlz
IHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2Yg
dGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGlu
dWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRo
ZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=
</DocumentoElectrinico>

Pero ¿qué pasa con el que recibe este "documento electrónico"?

Este documento está de acuerdo a lo definido por nuestro gobierno (el schema es bien simple, y basta con indicar que el blob decodificado corresponde al un documento word, por ejemplo), así que será problema del que recibe ver que hace con estos "garabatos".

El problema que muchos proyectos del Estado hacen esto. Hay reparticiones no tienen el software para interpretar el base64 decodificado, entonces ¿deben licenciar el software (esperando una aprobación de presupuesto), o "piratear" para poder leerlo? ¿Es eso aceptable? ¿Qué pasa con los privados que reciben estos documentos?

Por eso que decir "vamos a usar XML" no es suficiente, hay que ponerse de acuerdo en cómo se estructura el documento XML.

ODF y OOXML son definiciones, que basadas en XML estructuran una representación de un documento electrónico, pero estos estándares deben asegurar interoperabilidad, no es aceptable que requieran la compra de licencias de algún producto específico, o el pago de patentes.

OOXML es malo porque está pensado para prolongar la dependencia de un sólo proveedor: Microsoft.

Los estándares permiten competir

Los estándares permiten competir, y deben ser neutrales por lo mismo. Normalmente cuando un estándar surge desde la empresa privada pasa por un proceso de incorporación de todos los competidores, ya pasó con SOAP, y por eso que extraña que Microsoft sea tan tozudo con este caso.

Pero la verdad es que están defendiendo, de mala manera, al más exitoso de sus productos Office.
Microsoft debería entender que es mejor abrazar un estándar abierto, y potenciarlo, en vez de seguir con esta actitud arrogante.

Black and Decker, y Stanley son dos grandes empresas que compiten en la industria de las herramientas.

Ambas adoptan estándares, internacionales, y nacionales, para poder competir. Todos saben que las llaves tienen una forma estándar, cumplen con las normas de operación, dimensiones, etc.
Probablemente sin estos estándares la industria de las herramientas sería un caos.

Eso falta en la industria del software.

Pero ya no debemo resistirnos más.

Aunque podemos programar cualquier cosa, y el software permite un grado de flexibilidad casi infinita, los usuarios nos están pidiendo que paremos, que de una vez por todas empecemos a usar estándares de interoperabilidad.

Esto de los estándares hay que verlo como una oportunidad para mejorar, y que nos permitirá crecer aún más. Es mejor tomar el ejemplo de otras industrias, y adoptar estándares, que sean simples, y que estén bien pensados, no llenos de errores (como en OOXML).

0 TrackBacks

Abajo se encuentran listados enlaces a este artículo: Estándares, estándares....

URL de TrackBack URL para esta entrada: http://www.lnds.net/cgi-bin/mt-tb.cgi/1887

2 Comentarios

ymichaud dice:

Este es el segundo intento de comentar (¿no habrás saboteado el cgi?). Como decía en mi anterior intento, interesante el artículo, a mi modo de ver la cosa queda más entendible, pues también he leido los artículos de SK y El Francotirador. Casualmente me encuentro haciendo un curso de interoperabilidad gubernamental en modalidad e-learning donde se aborda la temática desde el punto de vista del gobierno y sus decretos supremos varios, más la obligatoriedad de utilizar XML entre los públicos. Sin embargo, al igual que Humbertito, me asalta una duda: cuando te refieres a "hay que ponerse de acuerdo en cómo se estructura el documento XML.", ¿no te estás refiriendo al contenido? Pues según entiendo, la forma de escribir los oficios y resoluciones debieran ser similares en (casi) todas las reparticiones públicas. El casi es por un tipo que se apellida Murphy, y uno nunca sabe cuando se va a topar con él... Quizá a eso te referías y yo entendí todo mal... Esperemos que el INN tome la mejor decisión, sino toda la normativa de interoperabilidad va a tener que ser revisada... por Microsoft Chile (ha ha ha ha).
En otro orden de cosas, el xml de ejemplo que pusiste no está bien formado, ¿viste que se aprende algo en los cursos?
Saludos.

Gracias por el comentario.

Cuando me refiero a ponerse de acuerdo me refiero al Schema.

Un oficio o una resolución tienen una forma estándar, pero ¿cómo denominaremos las etiquetas que definen a un oficio?¿En que orden se deben presentar estas etiquetas? ¿Cómo se firma? etc.
Eso se resuelve en parte con el Schema, pero además siempre es necesario tener un documento que aclare ciertos temas, los schemas no resuelven las dudas semánticas.

Cierto, el XML no está bien formado, y eso me da la idea para escribir más artículos, porque de XML y documentos electrónicos algo sé...

Escribir un comentario

(Si no dejó aquí ningún comentario anteriormente, quizás necesite aprobación por parte del dueño del sitio, antes de que el comentario aparezca. Hasta entonces, no se mostrará en la entrada. Gracias por su paciencia).

Introduzca los caracteres que ve en la imagen de arriba.

Sobre esta entrada

Esta página contiene una sola entrada realizada por ediaz y publicada el 22 de Agosto 2007 9:20 AM.

¿Código Libre? es la entrada anterior en este blog.

Se cae skype, no nos vamos a caer nosotros... es la entrada siguiente en este blog.

Encontrará los contenidos recientes en la página principal. Consulte los archivos para ver todos los contenidos.

Technorati

Technorati search

» Blogs que enlazan aquí

Creative Commons License
Este weblog está licenciado bajo una Licencia Creative Commons.

BloGalaxia website stats
Google
Encuentro Blogpower 2008