1. Respecto del cambio del voto del INN como miembro “O” a “P” del Subcomité 34 y conforme a los antecedentes que se tienen:

• Carta de la CCE de fecha 6 de agosto ofreciendo colocar a disposición del Comité y del INN recursos para participar como miembro “P”.
• Carta respuesta del INN enviada con fecha 13 de agosto a la CCE.
• Que las obligaciones que involucra este cambio son:
  • Votar todos los borradores de los documentos o normas en discusión, enviando observaciones (en ingles) a los mismos, cuando se estime necesario.
  • Participar en reuniones internacionales, en la medida de lo posible.
• Seguimiento de las materias que elabora y estudia este Subcomité y las que a futuro se determine como prioritarias.
• Que el INN delega parte de la responsabilidad de la Secretaria Técnica del Comité Espejo JTC1/SC34 a la organización que estime formar el Comité, la cual debe ser representativa de todos los sectores involucrados.
• Que se firmará un convenio de cooperación entre la CCE y el INN, para los efectos de la constitución del Comité Espejo de ISO/IEC JTC1/SC34.

Se acuerda por unanimidad del Comité aceptar lo ofrecido y cambiar la participación en
ISO del INN, para este Subcomité, a miembro “P”.

Sin embargo, por el momento Chile no ha votado en los dos últimos temas relacionados con este comité. Tal como dice Andy Updegrove en su artículo, la mínima muestra de civilidad sería votar “abstención”, dado que es posible abstenerse cuando no ha habido tiempo para revisar los antecedentes. En cambio, cuando no se vota y la cantidad de países que no presentan su voto son un 50% o más, el tema queda automáticamente fuera.
En otras palabras, el único aporte que hemos hecho hasta el momento en el JTC-1 es demorar el proceso de estandarización de iniciativas que tuvieron la mala suerte de llegar justo después de la discusión del OO-XML. Esperemos que esta situación se revierta y sea solamente algo pasajero producto de la organización necesaria para hacer llegar los votos, porque esto no nos deja bien parados.
En todo caso, en el sitio web de la Cámara de Comercio Electrónico de Chile no hay rastros de cumplir con el compromiso que se adoptó en la reunión del 21 de Agosto, y tampoco he recibido invitación alguna a discutir sobre los temas que estamos actualmente bloqueando.

UPDATE (25/10/2007): me tocó estar hoy en la mañana en una reunión con José Antonio Barriga y le toqué el tema, dado que aparece como miembro del directorio de la Cámara de Comercio Electrónico. Por lo que me dice, hay un esfuerzo que se está haciendo para definir exactamente cuál va a ser el funcionamiento, sobre todo después de que el INN planteara justamente esa redefinición. De todas formas, el objetivo de la Cámara es participar activamente en los temas en los que actualmente aparecemos bloqueando la discusión. Pero dados los recursos que existen, la idea es definir las áreas en las cuales hay interés y posibilidades de participar activa y correctamente, y en ellas emitir opiniones, pero de todas formas dar los votos de abstención en los otros temas para no convertirse en un obstáculo a los estándares a nivel mundial. Ojalá eso se pueda resolver lo antes posible, porque también se acerca el deadline para la discusión sobre el OO-XML.

One of the things I would like to spread a lot more than it is known is the fact that we have very similar requirements in Chile to the ones being put forward in Massachsetts’ Enterprise Technical Reference Model. The requirements are defined in the supreme decree number 77 and supreme decree number 81 (both available in spanish only), issued in the context of the State Reform and Modernization project.

One of the issues that the State Reform and Modernization is aiming to achieve is the interoperability among governmental entities and with the citizens. This is in itself a complex topic and limiting it to file formats alone would be an unwise oversimplification. But file formats are one of the requirements that are needed and the supreme decrees 77 and 81 address them.

Supreme Decree 77

This decree, signed off on June 3rd 2004, addresses the efficiency of electronic communications among government bodies and between them and citizens. It defines that the government bodies need to specify their file formats and media compatible with their systems, and requires that special readers and applications can be required only when necessary and if those readers and applications are freely available (as in free beer). Also, the file formats have to be compatible, which is further specified in the Supreme Decree 81.

Supreme Decree 81

This decree, also signed off on June 3rd 2004, establishes the minimal technical requirements for governmental bodies handling electronic documents. It referrs to generating, sending, receiving, processing and storing electronic documents. Basically, all electronic documents have to be available in a XML format, following an XML Schema definition. All of the used Schemas have to be publicly available and of free access (as in free beer). The documents have to be self-contained and follow the general rules of being:

• flexible and extensible
• perennial
• interoperable
• having a multiplatform system

Similar requirements are made for repositories, transport of documents and signatures. The requirements start in 2004, 2006 and 2009, depending on the specific government body.Just as Sam writes in this entry on Massachusetts, the Microsoft XML document format does not satisfy the minimal requirements of the Supreme Decree 81. Interestingly, these supreme decrees have not had much public exposure nor criticism. Hopefully this does not mean they will be ignored.

In my own personal experience, which most web developers I talk with also share, developing a good, valid, accessible website that works in Firefox, Opera, Safari, Konqueror, and lynx often takes about half the time it takes to make the same website with only Internet Explorer and Firefox considered.

También menciona otros aspectos técnicos interesantes en el mismo artículo para los que quieran saber más. En otro artículo además señala lo peligroso que es usar Internet Explorer.

Pero es necesario repetirlo, ya lo escribí hace menos de un mes y lo repito en otras palabras: en la mayoría de los casos, para que un sistema funcione bien en todos los browsers, lo mejor es que sea simple. Es la receta de muchos servicios exitosos, donde lo que prima es el entregar la información por sobre la posibilidad de agregar fuegos artificiales y otros elementos superfluos.

Por lo tanto, un sitio web que funcione respetando los estándares debiera ser más barato que un sistema hecho especialmente para un cierto browser, y luego modificado para además funcionar en los browsers que ostentan el segundo y tercer lugar del mercado. Y por si fuera poco, aunque el sitio web se vea bien con el 99.999% de los browsers en uso, eso tampoco es suficiente si me genera problemas en herramientas que utilizaremos a futuro.
La compatibilidad va mucho más allá de ver un sitio en un browser. Se trata de darle acceso a discapacitados (alguien ciego hace uso de los atributos “alt” de las imágenes, las cuales generalmente no contienen la información que debieran, entre muchos otros detalles), de permitir servicios de valor agregado (lo que se puede hacer con agregadores de RSS es un tímido ejemplo), aparecer en resultados de búsqueda, y quizás qué otras funcionalidades que recién estaremos utilizando en el futuro.

En resumen: si alguien pretende cobrar más caro por un sitio que sea compatible con la mayoría de los browsers, lo más probable es que esté haciendo un trabajo mediocre porque su enfoque está muy equivocado. En tal caso es mejor contratar a alguien que lo haga bien desde el principio en vez de partir planificando parches que además van a hacer el sistema cada vez menos mantenible.

Espero poder contar algunas novedades pronto, pero lo cierto es que en el gobierno existe bastante gente competente (probablemente no todos, pero conozco personalmente a varios que sí lo son) y este tipo de hitos son positivos para ellos. Generalmente ellos andan pregonando cómo se debieran hacer las cosas, pero dependen de que otros tomen las decisiones. Y cuando los que toman las decisiones se enteran que existe presión para que las cosas se hagan bien, no sólo les dan permiso para hacerlas bien, sino que se lo encomiendan.

De todas maneras hay un par de cosas que se debieran mencionar con respecto al artículo:

• Existe, desde el 2004, una Guía Web de Gobierno que apunta hacia el lado correcto. La mayoría de los problemas señalados no se habrían presentado si se siguiera esa guía. Así que ya se ha dado el primer paso, y ahora es necesario seguir adelante.
• Hay un párrafo que dice “Incluso, dentro de la especificación de DTEs definidos por el SII, se menciona el uso de estándares como XML, PDF 417 y otros, que dejan de lado los utilizados por Firefox.”.
  En realidad XML y PDF 417 sí son estándares (bueno, XML es un lenguaje que permite especificar, codificar y transformar formatos estándares) y en Firefox se usan formatos en XML.
• La discusión que se menciona no fue en los foros de MundoOS, sino en la lista Linux de la UTFSM, cuyos registros son públicos. Se puede seguir toda la discusión a partir de este link. En particular, la frase que supuestamente escribió Juan Carlos Muñoz en realidad la escribí yo en este mensaje, no me interesa tanto la atribución, pero sí quiero evitar que se pongan palabras en boca (¿mano?) de alguien que no las escribió y quizás no esté de acuerdo con ellas.
• El logo de Firefox en realidad no es un zorro (a pesar del nombre: fox = zorro), sino un oso Panda Rojo, pero eso ya es hilar bastante fino…

Y finalmente, me gustaría agregar los links que pueden ayudar a profundizar un poco el tema:

• El listado de sitios incompatibles esta aquí: http://wiki.firefox.cl/index.php/Lista_de_Sitios_incompatibles
• Los detalles para participar de las discusiones de MundoOS están aquí.

Sí, antaño Internet Explorer era usado por el 98% de los “navegantes”. Hoy en día eso ya no se cumple y es más bien un 85.45 %; tendencia: bajando. Eso a pesar de que muchos browsers se hacen pasar por Microsoft Internet Explorer para evitar que deliberadamente se le envíen páginas que se ven mal, lo cual acrecenta el número asignado a ese browser. De todas formas, se justifica excluir a un 2% solamente porque el proveedor que me hace las páginas web no tiene interés en hacer bien su pega? Ni siquiera sale más barato: en general las incompatibilidades se dan porque se usa más parafernalia de la necesaria, justamente para poder cobrar más, sin obtener ningún beneficio…

En fin, si un negocio quiere perder entre un 5% (Fuente: Paris) a un 8% (contando solamente los que usan Firefox en Chile) de sus clientes por el capricho de algún proveedor, basta que lo justifiquen frente a los accionistas, suerte con eso. Algo muy distinto es que una institución pública siga esos pasos, como ocurre con el Ministerio de Educación (para postular a cualquier beca o crédito de estudio es necesario utilizar un producto específico de una empresa específica). O es que alumnos que tienen acceso a través del colegio, de los infocentros de Injuv o en su casa utilizando un NuestroPC simplemente no tienen derecho a becas??? Aunque fuera el 0,1% (sólo unos 167 estudiantes de los 167.000 que postularon este año), es inaceptable.

Vergonzoso (en mi calidad de ex-alumno y profesor del DCC de la UChile) es lo que ocurrió con el DEMRE. En ese caso, la respuesta fue la peor parte. En lo personal no conozco ningún estudio como el que se alude en esa respuesta, y menos uno que concluya tamañas barbaridades como las que se señalan en la carta (que por lo que he podido averiguar, parece ser una transcripción auténtica).

Esto es algo que no sólo ocurre en Chile, pero es necesario esperar que muera gente antes de tomar alguna medida? Siempre existe esa idea inconsciente de que un problema de incompatibilidad o un pequeño error en un programita que no maneja los sistemas de una planta atómica no mata a nadie… es absolutamente falso. Gente muere, se accidenta y queda con secuelas de por vida porque somos incapaces de hacer que dos sistemas hablen entre ellos, hay fallas en las aplicaciones y otros. Basta darse una vuelta por Risks.

* Lista de Sitios Incompatibles
* Guía Web de Gobierno (muy aplicable también a sitios que no son de gobierno)