Acabo de anunciar na minha palestra sobre ODF na Campus Party que foi aprovada na semana passada a proposta que apresentei ao comitê do ODF (OASIS ODF TC) junto com Bob Jolliffe (Governo da África do Sul) sobre assinatura digital no ODF 1.2.

A utilização do padrão XMLDSig para assinaturas digitais no ODF 1.2 já havia sido aprovada anteriormente e em nossa proposta, procuramos estender este suporte incorporando o XAdES, uma extensão ao XMLDSig desenvolvida pelo ETSI que incorpora, entre outras características, o vetor “tempo” nos certificados digitais.

O XAdES foi incorporado à ICP-Brasil em sua versão mais atual, finalizada em Dezembro de 2008.

A proposta inicial que apresentamos em Julho de 2008, propunha a alteração do schema do ODF 1.2 para permitir a identificação do tipo de assinatura utilizado (XMLDSig ou um dos tipos possíveis do XAdES), além de descrever os mecanismos de identificação utilizados para indicar o stream XML assinado.

Depois de uma série de discussões com especialistas de dentro do comitê do ODF e também de comitês externos, como os especialistas que desenvolveram o XAdES dentro do ETSI, optamos por simplificar a proposta, mas nos comprometemos a elaborar no médio prazo um framework para assinaturas digitais dentro da especificação do ODF. Com a simplificação feita, indicamos de forma clara que são aceitas as assinaturas feitas através do XMLDSig e suas extensões (XAdES).

Na próxima versão do ODF, ainda sem nome dentro do comitê, iremos trabalhar para incorporar dentro da especificação os perfis de assinatura existentes (coisa que não pudemos fazer hoje, pois ainda são raras as aplicações reais de assinaturas digitais como a ICP-Brasil… estamos na vanguarda, acreditem se quiser).

Tão logo seja aprovada a versão 1.2 do ODF dentro do comitê, o que espero que ocorra nos próximos meses, iremos (eu e o Bob) iniciar o trabalho para a especificação do framework para as assinaturas digitais e já combinamos que um dos perfis será o ICP-Brasil.

A incorporação destes perfis à especificação do ODF é importante, pois permitirá aos desenvolvedores ter sempre á mão toda a documentação necessária para validar e suportar os perfis específicos de assinatura digital, sem a necessidade de consultar nenhuma referência externa (para vocês terem uma idéia, se alguém hoje quiser implementar a ICP-Brasil dentro de uma aplicação terá que consultar a documentação do ITI, que está toda em português. Eu quase tive que traduzir todos os documentos da ICP-Brasil para poder explicar algumas coisas para os demais membros do comitê).

Foi um grande prazer ter trabalhado durante todos estes meses nesta proposta dentro do comitê e é muito gratificante para participar do comitê de desenvolvimento do ODF (espero que outros brasileiros e latino americanos se empolguem também e participem mais de comitês internacionais como este. Por incrível que pareça para alguns, temos de verdade muito a contribuir com eles).

Gostaria de deixar aqui um agradecimento ao pessoal do ITI que nos apoiou tecnicamente durante este processo e um super agradecimento especial ao Bob Jolliffe, que me ajudou nesta empreitada (e Bob, teremos muito trabalho pela frente e conte comigo).

Para finalizar, toda vez que você for utilizar uma assinatura digital em um documento ODF, lembre-se que a especificação para isso foi feita por um Brasileiro (Latino Americano) e por um Sul Africano. Em tempos de Barack Obama, esta é uma constatação, ao menos, muito interessante

I announced a few hours ago, on my presentation about ODF at Campus Party that on last week, the committee that develops ODF (OASIS ODF TC) has approved a proposal presented by me and Bob Jolliffe (Government of South Africa) regarding digital signatures support on ODF 1.2.

The use of XMLDSig for digital signatures in ODF 1.2 had been previously approved and in our proposal, we extend this support incorporating XAdES, an extension to XMLDSig developed by ETSI which incorporates, among other features, the vector “time” in the digital certificates.

XAdES was also incorporated by the ICP-Brazil (Brazilian framework and legal requirement regarding Digital Signatures) on its latest version, finalized in December 2008.

The original proposal was presented by us at the ODF TC in July 2008, proposed a change at the ODF 1.2 schema to identify signature type used (XMLDSig or one of the possible XadES types), in addition to describing the mechanisms used to identify the signed XML stream.

After a series of discussions with experts from the ODF committee and also some external experts, as the people who developed XAdES within ETSI, we decided to simplify the proposal, but we are committed to establish in the medium term a framework for digital signatures within the ODF specification. With the simplification made, we indicated clearly that they are accepted XMLDSig signatures and its extensions (XAdES).

The next version of ODF - that stills without a name within the committee - we will work to incorporate within the specification, profiles of existing digital signatures (this is something we couldn’t do today, because the real world applications of digital signatures as the ICP-Brazil still very rare to find… In Brazil we are in the vanguard, believe in it or not).

As soon as the version 1.2 of ODF is approved at the committee, which I expect to occur in the next months, we (me and Bob) will start working to specify the framework for digital signatures and we already agreed that one of the profiles will be the ICP -Brazil.

The incorporation of these profiles on the next version of the ODF specification will be important, because it will allow developers to have in hand, inside the ODF spec, all the documentation needed to validate and support the specific profiles of digital signature, without the need to consult any external reference (just to give you an an idea, if someone today wants to implement the ICP-Brazil on an application, will need to consult the documentation available in Brazil, which is all in Portuguese. I almost had to translate all the ICP-Brazil spec documents to explain some things to the other members of the committee).

It was a great pleasure to have worked for all these months on this proposal within the committee and it is very gratifying to participate in the ODF development committee (I hope that other Brazilians and Latin American folks felt animated with that history and participate more in international committees like this one. It may sounds incredible to some people, but we really have something to contribute from Brazil and Latin America).

I want to thanks to the staff of the ITI (National Institute of Information Technology) that technically supported us during this process and a super special thanks to Bob Jolliffe, who helped me in this work (and Bob, we have much work ahead and count on me).

Finally, every time you use a digital signature on a ODF document, remember that the specification for this was made by a Brazilian (Latin American) and a South African. In times of Barack Obama, this is at least, a very interesting observation

He anunciado hace unas horas, en mi presentación sobre el ODF en la Campus Party que en la última semana, la comisión que desarrolla el ODF (OASIS ODF TC) ha aprobado una propuesta presentada por mí y Bob Jolliffe (Gobierno de Sudáfrica) acerca del soporte a firmas digitales en el ODF 1.2.

El uso de XMLDSig para firmas digitales en el ODF 1.2 ya había sido previamente aprobada y en nuestra propuesta, proponemos extender este soporte utilizando el XAdES, una extensión del XMLDSig desarrollado por el ETSI, que recoge, entre otras características, el vector “tiempo” en los certificados digitales.

XAdES también fue incorporado por la ICP-Brasil (framework y marco legal del gobierno brasileño acerca de las Firmas Digitales) en su versión más reciente, finalizada en diciembre de 2008.

La propuesta original fue presentada por nosotros a el ODF TC en julio de 2008, y proponíamos un cambio en el esquema del ODF 1.2 para identificar el tipo de firma utilizada (XMLDSig o uno de los posibles tipos del XAdES), además de describir los mecanismos utilizados para identificar lo stream XML firmado.

Después de una serie de debates con expertos del comité del ODF y también con algunos expertos externos, como las personas que han desarrollado el XAdES en el ETSI, se decidió simplificar la propuesta, pero nos hemos comprometido a establecer en el mediano plazo un framework para firmas digitales dentro de la especificación del ODF. Con la simplificación hecha, indicamos claramente que se aceptan las firmas XMLDSig y sus extensiones (XAdES).

La próxima versión del ODF - que aún no tiene un nombre dentro de la comisión - vamos a trabajar para incorporar en la especificación, los perfiles de firmas digitales existentes e utilizados (esto es algo que no se puede hacer hoy, porque en el mundo real las aplicaciones de firmas digitales como el ICP-Brasil sigue siendo muy raro encontrar… En Brasil estamos en la vanguardia, por increíble que parezca).

Tan pronto la versión 1.2 del ODF sea aprobada en la comisión, lo que espero que ocurra en los próximos meses, (yo y Bob) empezaremos a trabajar para especificar el framework para firmas digitales y estamos ya de acuerdo que uno de los perfiles será la ICP-Brasil.

La incorporación de estos perfiles en la próxima versión de la especificación del ODF será importante, porque permitirá a los desarrolladores tienen en la mano, dentro de la especificación del ODF, toda la documentación necesaria para validar y apoyar los perfiles específicos de firmas digitales, sin necesidad de consultar a cualquier referencia externa (sólo para darle una idea, si hoy alguien quiere aplicar la ICP-Brasil en una aplicación, tendrá que consultar la documentación disponible en Brasil, que es todo en portugués. Yo casi tuvo que traducir todos los documentos de la ICP-Brasil a inglés para explicar algunas cosas a los demás miembros de la comisión).

Fue un gran placer haber trabajado durante todos estos meses en torno a esta propuesta en el seno del Comité y estoy muy grato por participar del comité de desarrollo el ODF (y espero que otros brasileños y latinoamericanos se animen con esa historia y participen más en comités internacionales como este. Tal vez suena increíble a algunas personas, pero realmente tenemos algo que compartir).

Quiero agradecer al personal del ITI (Instituto Nacional de Tecnología de la Información), que técnicamente nos apoyaron durante este proceso y un super especial gracias a Bob Jolliffe, que me ayudó en este trabajo (y Bob, tenemos mucho trabajo por delante y puedes contar conmigo).

Por último, cada vez que usted utilizar una firma digital en un documento en ODF, recuerde que la especificación para este fue desarrollada por un brasileño (latinoamericano) y un sudafricano. En tiempos de Barack Obama, esto es una observación, al menos, muy interesante

He aprendido en 2008 que cuanto más rezo, más fantasmas me aparecen y para comenzar 2009 con el pie izquierdo, recibí un e-mail de la ISO en la última semana, a través de la ABNT, invitando a Brasil para unirse al esfuerzo internacional para “recoger errores técnicos y de redacción del OpenXML”.Para aquellos que no saben do que se trata, voy a resumir la historia del OpenXML:

En 2006, la ISO aprobó el ODF (OpenDocument Format - ISO 26.300), como una norma internacional y desde entonces, se ha adoptado el ODF en todo el mundo, principalmente por los gobiernos, como el estándar para el almacenamiento de documentos electrónicos editables (hojas de cálculo, documentos de texto y presentaciones).

La aprobación del ODF en la ISO y su creciente adopción es una gran amenaza a lo mercado de “suite ofimática”, y como varias herramientas de software trabajan con los documentos ODF, la comoditización de este mercado es inevitable, y eso termina el monopolio de la Suite Ofimática del Clips.

Viendo que no podían perder el mercado tan fácilmente, Microsoft ha desarrollado en 12 meses un standard “equivalente” a el ODF, en una entidad llamada ECMA, que tuve la habilidad de escribir, discutir, votar y aprobar más de 6.000 páginas de especificación técnica en 12 meses. Al final de este proceso, la norma (o texto) fue enviado a la ISO (ECMA fue la elegida, porque es la entidad que tiene un “permiso especial” para la ISO, la FastTrack).

El proceso utilizado por ECMA para presentar la especificación a la ISO se llama FastTrack, y este proceso define que en 6 meses todos los países (National Bodies - NBs) deben analisar y votar para la aprobación o rechazo de una norma.

La votación sobre el OpenXML ocurrió a mediados de 2007, y el resultado fue el rechazo, soportado por más de 3.000 deficiencias técnicas señaladas por los países.

Extrañamente (dado el resultado de la votación y la gran cantidad de errores encontrados), la ISO insistió en la cuestión y propuso una reunión de 5 días en febrero de 2008, para discutir y resolver los problemas técnicos presentados (para los que no saben, asistí esta reunión como uno de los tres delegados de Brasil). Esta reunión se llamo BRM - Ballot Resolution Meeting y fue realizada enGinebra, Suiza.(Si alguien piensa que hemos debatido y resuelto los 3.000 problemas técnicos en días 5, póngase en contacto conmigo porque tengo una hermosa tierra para vender en Plutón y Marte).

Un mes después del final de la reunión, los países tuvieron la oportunidad de cambiar su voto y, milagrosamente, hubo un cambio de votos y la norma fue aprobada, con todos los vergonzosos errores y problemas técnicos existentes.

Brasil votó NO en la primera oportunidad, decidió por el mantenimiento de la votación en la segunda oportunidad y después de que el resultado final fue presentado, envió un protesto oficial a la ISO, pidiendo la anulación del FastTrack, basado en varias violaciónes a las directivas de la ISO, y fuimos sumariamente ignorados. Sudáfrica, Venezuela y la India han enviado también sus protestos y también fueron sumariamente ignoradas (me parece que la ISO odia los países del tercer mundo, ¿no?).

Resultado final: OpenXML aprobado como norma ISO 29.500 a principios de abril de 2008, pero el texto final sólo fue conocido en diciembre de 2008. (Me olvidé decirle este “pequeño detalle”: Los países han cambiado su voto sin conocer el texto final de la norma).

A finales del año pasado, después de la publicación de lo que debería ser el texto de la norma, la ISO ha creado un grupo con una misión peculiar: “Fijar OpenXML”!

La primera tarea de este grupo es colectar un conjunto de problemas que fueran encontrados en el mundo (una gran limpieza). Es una tarea tan grande, que incluso exigió la creación de un portal para ayudar a recoger y organizar la desorden.

La semana pasada, se han enviado a todos los miembros de SC34 (Organizmos Nacionales de normalización) invitando a todos a enviar a el SC34 errores técnicos o editoriales encontrados en el estándar OpenXML. Despues de la recepción y organización de todos los errores, un grupo de trabajo trabajará para resolverlos, creando lo que será una versión “sin errores técnicos y de redacción” de la norma ! Y no hay ninguna fecha fijada para que todos eso sea hecho !

Esta es la primera vez que veo una estándar “reserva”, que fue aprobado sólo para “reservar el espacio”. Es como un estándar “cono de tráfico”, similar a los conos que algunas personas ponen en la calle para la reserva espacio en plazas de aparcamiento.

Algunas preguntas que quedan sin una respuesta plausible, sobre todo este lío:

¿Cuál es la utilidad de aprobar una norma con muchos errores, que ahora necesita un sitio web para ayudar a resolverlos?

La aprobación de una norma con tantos problemas se puede considerar una actitud responsable? ¿Quién es el principal responsable de tal irresponsabilidad?

¿Estamos entrando en una nueva era de la normalización internacional, una época en la que vamos aprobar primero y después de la aprobación que se escriba el texto aprobado?

¿Cuál es el valor real de una norma ISO en esta situación? ¿Hay alguien ingenuo (o malicioso) suficiente en el mundo para utilizar la IS 29.500 por algo, antes de que la norma sea finalmente corregida (si posible)?

¿Cómo es la reputación de la ISO después de tal desastre? Para mí, esta historia ha superado Monty Python hace mucho tiempo!

Soy sólo yo, o cualquier otra persona ya notó los cambios en las carreras (y empleadores) de los diversos “expertos” y “neutrales” que trabajaran arduamente para la aprobación de OpenXML en todo el mundo?

Después de todo esto, estoy horrorizado al ver la falta de escrúpulos del grupo que, haciendo caso omiso de todo lo que he descrito aquí, continua todavía tratando de empujar el OpenXML a los gobiernos de todo el mundo.

Este grupo me enferma

Learned in 2008 that the more I pray, more ghosts appears to me and to begin 2009 with the left foot, I received an ISO e-mail on last week, through Brazilian NB, inviting Brazil to join the international effort to “collect OpenXML technical and editorial errors”.For those who don’t know, I’ll summarize the OpenXML history:

In 2006, ISO approved the ODF (OpenDocument Format - ISO 26.300) as an international standard and since then, ODF has been adopted worldwide, mainly by governments, as the standard for storage of editable electronic documents (spreadsheets, text documents and presentations).

The ODF approval at ISO and its growing adoption was a huge threat to the “office suite” market, as several software tools works with ODF documents and therefore the commoditization of this market is inevitable, ending the monopoly of the Paper Clips Office Suite.

Seeing that they couldn’t lose market that easy, Microsoft has developed in 12 months a standard “equivalent” to ODF, inside an entity named ECMA, who had the prowess to write, discuss, vote and approve more than 6,000 pages of technical specification in 12 months. At the end of this process, the standard (or text) was sent to ISO (the ECMA was chosen, because it is the entity that has a “special pass” to the ISO, the FastTrack).

The process used by ECMA to submit the specification to ISO is called FastTrack, and this process provides that in 6 months all countries (National Bodies - NBs) should consider and vote for approval or rejection of a standard.

The vote on the OpenXML occurred in mid-2007 and the result was the rejection, supported by more than 3,000 technical defects identified by the countries.

Strangely (given the voting result and the vast amount of errors found), the ISO insisted in the matter and scheduled a 5 days meeting in February 2008, to discuss and solve the technical problems reported (for those who don’t know, I attended this meeting as one of the three Brazilian delegates). This meeting was called BRM - Ballot Resolution Meeting and was realized on Geneva, Switzerland (If anyone thinks that we discussed and resolved the 3,000 technical problems in 5 days, please contact me because I have a beautiful land to sell on Pluto and Mars).

A month after the end of the meeting, the countries had the opportunity to change their vote and miraculously, there was a change of required votes and the standard was approved, even with all the shameful errors and technical problems existing in it.

Brazil voted NO on the first opportunity, maintained the vote in the second opportunity and after the final result, sent a formal appeal to ISO, asking for the annulment of the FastTrack process, but despite several violations to the ISO directives demonstrated at the appeal text, we were summarily ignored. South Africa, Venezuela and India has sent appeals too and were also summarily ignored (seems to me that the ISO hates the third world, isn’t it?).

Final result: OpenXML approved as ISO 29.500 in early April 2008, but the final text was only known in December 2008. (I forgot to tell this “small detail”: The countries have changed their vote without knowing the final text of the standard).

Late last year, after publication of what should be the text of the standard, ISO has created a group with a peculiar mission: “Fix OpenXML”!

The first task of this group is a collection of problems encountered in the world (a huge cleaning). It is a so big task, that even demanded the creation of a portal to help them to collect and organize the mess.

Last week, they’ve sent to all members of SC34 (National Bodies) an invitation asking them to sent to SC34 all editorial or technical errors found on OpenXML standard. Upon receipt of all errors, they will be organized and then a working group will work to resolve them, creating what will be a version “without editorial and technical errors” of the standard !!! And there isn’t any date set to get all this mess fixed !!!

This is the first time that I see a “reserve” standard, which was approved only for “reserving the space.” It is like a “traffic cone” standard, similar to the cone that some folks put on the street to reserve parking spaces.

Some questions that remain without a plausible answer about all this mess:

What is the usefulness of approving a standard with so many errors that now needs a website to help solve them?

The approval of a standard with so many problems can be considered a responsible attitude? Who is the major responsible for such irresponsibility ?

Are we entering on a new era of international standardization, an era where we first approve and after the approval we write the approved text?

What is the real value of an ISO standard in this situation? Is there anyone naive (or malicious) enough in the world to use the IS 29500 for something, before the standard is finally corrected (if possible) ?

How is the reputation of ISO after such mess ? For me, this story has surpassed Monty Python a long time ago !!!

It is just me, or anyone else already noticed the changes in careers (and employers) of various “experts” and “neutral” folks that worked hard for the approval of OpenXML worldwide?

After all this, I am horrified to see the lack of scruples of the group that, ignoring everything that I described here, still trying to push (or rush) OpenXML on governments around the world.

This group really make me sick

Aprendi em 2008 que quanto mais eu rezo, mais assombração aparece e nada melhor para começar este 2009 com o pé esquerdo do que o e-mail da ISO que recebi nos últimos dias, via ABNT, convidando o Brasil para participar do esforço internacional de “coleta de erros” do OpenXML.

Para quem não conhece, resumo a história do OpenXML:

Em 2006, a ISO aprovou como norma Internacional o ODF (OpenDocument Format – ISO 26.300) e desde então ele vem sendo adotado no mundo todo, principalmente por governos, como o padrão para armazenamento de documentos eletrônicos editáveis (planilhas, textos e apresentações).

A aprovação do ODF e sua crescente adoção se mostrou como uma gigantesca ameaça ao mercado de suites de escritório, pois diversas ferramentas de software trabalham com documentos ODF e por isso, a comoditização deste mercado é inevitável, acabando com o monopólio da Suíte de Escritório do Clips.

Como não poderia perder seu mercado assim de bandeja, a Microsoft desenvolveu em 12 meses uma norma “equivalente” ao ODF em uma entidade chamada ECMA, que teve a proeza de escrever, discutir, votar e aprovar mais de 6.000 páginas de especificação técnica em 12 meses. Ao término deste processo, a norma (ou o texto) resultante foi enviado á ISO (o ECMA foi escolhido por ser a entidade que tem um “passe especial” para a ISO, o FastTrack).

O processo utilizado pela ISO para a análise da norma, chamado de FastTrack prevê que em 6 meses todos os países devem analisar e votar pela aprovação ou rejeição de uma norma.

A votação do OpenXML ocorreu em meados de 2007 e o resultado foi a reprovação, justificada por mais de 3.000 defeitos técnicos apontados pelos países.

Estranhamente (dado o resultado da votação e a vasta quantidade de erros apresentada), a ISO insistiu no assunto e agendou uma reunião de 5 dias em Fevereiro de 2008 para que os problemas técnicos fossem discutidos e resolvidos (para quem não sabe, eu participei desta reunião como um dos três delegados Brasileiros). Esta reunião se chamou BRM - Ballot Resolution Meeting, e foi realizada em Genebra na Suiça. (Se alguém aí acha que conseguimos mesmo discutir e solucionar 3.000 problemas técnicos em 5 dias, me contacte pois eu tenho um terreno lindo para vender em Plutão).

Um mês após o término da reunião, foi dada aos países a oportunidade de mudar o seu voto e milagrosamente houve a mudança de votos necessária para que a norma fosse aprovada, mesmo com todos os erros e problemas técnicos escandalosos existentes nela.

O Brasil votou pela rejeição na primeira votação, manteve seu voto nesta segunda e após o resultado final enviou um apelo formal á ISO, pedindo a anulação do processo, mas apesar de demonstrarmos diversas violações ás diretrizes da ISO em nosso apelo, fomos sumariamente ignorados. África do Sul, Venezuela e Índia procederam da mesma forma e também foram sumariamenteignorados (me parece que a ISO detesta o terceiro mundo, não é mesmo ?).

Resultado final: OpenXML aprovado como norma ISO 29.500 no início de Abril de 2008, mas seu texto final só foi conhecido em dezembro de 2008. (Esqueci de contar este detalhe: Os países mudaram seu voto SEM CONHECER O TEXTO FINAL da norma).

No final do ano passado, após a publicação do que deveria ser o “texto da norma”, é criado na ISO um grupo com a missão de “corrigir o OpenXML” !!!

A tarefa vai passar inicialmente por uma coleta dos problemas encontrados no mundo todo (um faxinão) que de tão grande, demandou até a criação de um portal para ajudar a organizar a bagunça.

Na semana passada, enviaram a todos os National Bodies membros do SC34 (ABNTs de outros países) um convite para que sejam enviados a eles todos os defeitos técnicos ou editoriais da norma do OpenXML. Após o recebimento de todos os erros, estes serão organizados e depois um grupo de trabalho irá trabalhar para resolve-los, gerando o que deverá ser uma versão “sem erros editoriais e técnicos” da norma !!! E tudo isso sem data definida !!!

Esta é a primeira vez que eu tomo conhecimento de uma norma “reserva”, que foi aprovada só para “guardar lugar”. É como se fosse uma norma “cone de trânsito”, daqueles que a galera põe na rua para reservar vagas de estacionamento.

Algumas perguntas que continuam sem resposta plausível sobre tudo isso:

Qual foi a utilidade de aprovar uma norma tão cheia de erros que agora precisa até de um site para ajudar a resolve-los ?

A aprovação de uma norma com tantos problemas pode ser considerada uma atitude responsável ? Quem será o grande culpado por tamanha irresponsabilidade ?

Entramos em uma nova era na normalização internacional, onde primeiro se aprova e depois se escreve o texto aprovado ?

Qual é o valor real de uma norma ISO nesta situação ? Será que existe alguém suficientemente ingênuo ou mal intencionado no mundo para utilizar a IS 29.500 para alguma coisa antes que ela seja definitivamente corrigida ?

Como fica a reputação da ISO depois de tanta lambança ? Prá mim esta história já ultrapassou Monty Python faz tempo !!!

Será que sou só eu, ou alguém mais notou uma séria de mudanças nas carreiras (e empregadores) de diversos “especialistas” e “neutros” que trabalharam arduamente para a aprovação do OpenXML no mundo todo?

Depois de tudo isso, fico mesmo horrorizado em ver a falta de escrúpulo da turma que ignorando tudo isso, fica tentando de qualquer forma empurrar o OpenXML para cima dos governos do mundo todo.

Esta turma me dá nojo

He recibido un montón de mensajes de muchas personas en los últimos días con observaciones o a pedir mi opinión sobre el anuncio hecho la semana pasada, que Microsoft he publicado los “detalles técnicos” de su aplicación del ODF. En primer lugar, quisiera advertir a todos que el extenso documento publicado no es más que la versión 1.1 de la especificación del  ODF (OASIS v1.1 FOD), que fue publicado violando los derechos de autor del OASIS.

Dentro de este documento, hay notas y comentarios técnicos (marcado por las pequeñas letras “N” en rojo), que además de no presentar algo práctico acerca de su aplicación del ODF, todavía nos deja mucho más preocupados por la eficacia de la interoperabilidad de los documentos generados por sus aplicación del ODF (ya hemos encontrado graves problemas, pero vamos a seguir estudiando el texto a publicar una lista completa).

Como siempre, creo que el departamento de marketing de Microsoft fue mas rápido que sus ingenieros una vez más, y nos da como un regalo de Navidad un documento mal redactado, como si se tratara de “El Grand Regalo de Navidad” (y hay algunas personas que están asombrados con el tamaño del documento, pensando que es grande por que explica todos los detalles acerca de su aplicación del ODF… intentando inducir a error a las personas en vísperas de Navidad … ¡qué vergüenza).

El mismo departamento de marketing también presento en los últimos días de un conjunto de T-shirts temáticas de MS, y me pregunto cuánto va a costar la camiseta de la pantalla azul de Windows (BSOD)?

A ver todos los ‘Regalos de Navidad’ desde Redmond, y hablando de azul, creo que lo próximo cambio internacional que ellos van a proponer es la creación de un Papá Noel Azul (como un homenaje a la BSOD). Me imagino que si existía el tipo en el día de hoy, después de todos estos regalos de Navidad, sería su canto para todos nosotros:

“Jingle Bell, Jingle Bell, Papá Noel Azulito
Él va entregar un hermosos regalo hasta su … ”

Feliz Navidad a todos, gracias por más de 45 mil visitas a este blog en 2008 y deseo a todos un 2009 lleno de felicidad y la libertad (y no te preocupes, voy a pasar todo el año que viene observando muy atentamente sus movimientos de nuevo:) ).

Felices fiestas!

PS.: Cuidado con el Papá Noel Azulito

I received a lot of messages from many people in recent days with comments or asking my opinion about the announcement made last week, that Microsoft was publishing the “technical details” of their ODF implementation. In first place, I would like to warn everyone that the extensive document published is nothing more than the ODF version 1.1 specification (OASIS ODF v1.1), which was published by them violating the OASIS copyright.

Within this document, there are notes and technical comments (marked by small letters “N” in red), which apart from not present anything practical about their ODF implementation, still leaves us much more concerned about the effective interoperability of ODF documents generated by their implementation (we already found serious problems, but we’ll continue studying the text to publish a complete list).

As always, I think that Microsoft’s marketing department was faster than their engineering again, giving us as Christmas  gift a poorly drafted document as if it was “The Christmas Gift” (and there are some folks that are amazed with the size of the document, thinking that it was that large because it explains all the details about their ODF implementation… trying to mislead people at Christmas eve … what a shame).

The same marketing department also launched in recent days of a set of MS themed T-shirts, and I wonder how much will cost the shirt of the Windows blue screen of death (BSOD)?

Seeing all those ‘Christmas gifts’ from Redmond, and talking about blue, I think that the next international change that they will propose is the creation of a blue Santa Claus (as a tribute to the BSOD). I imagine that if it existed today, after all these Christmas presents, he would be singing to us all:

 ”Jingle Bell, Jingle Bell, the blue Santa saidz
He’ll deliver a beautiful gift right up to your …”

Merry Christmas to everyone, thanks for more than 45 thousand visits to this blog in 2008 and wish you all a 2009 full of happiness and freedom (and not worry, I will spend the whole next year watching very carefully their moves again:) ).Happy Holidays!

PS.: Beware of Blue Santa Claus

Muita gente me contactou nos últimos dias para saber minha opinião ou para comentar o anúncio feito na última semana, de que a Microsoft estava publicando os “detalhes técnicos” da sua implementação do ODF. Em primeiro lugar, eu gostaria de avisar a todos que o extenso documento publicado nada mais é do que a especificação 1.1 do ODF (OASIS ODF v1.1), que foi publicado por eles violando o copyright do OASIS.

Dentro deste documento, existem notas e comentários técnicos (marcados por pequenas letras N em vermelho), que além de não apresentar nada prático sobre a implementação que farão do ODF, ainda nos deixa muito mais preocupados com a efetiva interoperabilidade dos documentos ODF gerados por ele (já encontramos problemas sérios, mas vamos continuar estudando o texto para poder publicar uma lista completa).

Como sempre, me parece que o departamento de marketing da Microsoft novamente passou á frente da engenharia, dando-nos como presente de Natal um documento mal elaborado como sendo um “presentão de Natal” (e tem gente que se espantou com o tamanho do documento, achando que tudo aquilo era detalhe de implementação… tentando enganar as pessoas às vésperas do Natal… que vergonha).

O mesmo departamento de marketing lançou nos últimos dias também uma grife de camisetas, e me pergunto quanto será que custa a camiseta da tela azul do Windows (BSOD) ?

Tendo em vista estes “presentes de Natal” de Redmond, e falando em azul, acho que a próxima mudança internacional que eles vão propor é a criação de um Papai Noel azul (homenagem ao BSOD). Imagino que se ele já existisse hoje, depois de todos estes presentes de Natal, cantaria a todos nós:

“Jingle Bells, Jingle Bells, o Papai Noel Azul
Vai colocar o presentinho dentro do seu…”

Feliz Natal a todos, obrigado pelas mais de 45 mil visitas a este blog em 2008 e desejo a todos um 2009 cheio de liberdade e felicidade (e não se preocupem, vou passar o ano que vem todinho de olho neles de novo ).

Boas Festas !!!

PS.: Cuidado com o Papai Noel Azul

A principios de este mes, durante la tercera edición del Foro sobre Gobernanza de Internet (IGF 2008) en India, fue desarrollado por un grupo de expertos en estándares abiertos y los representantes de los gobiernos, un documento que compromete a sus signatarios a la adopción de estándares abiertos hasta el año 2010.

La siguiente es la traducción del documento al Español:

Dynamic Coalition on Open Standards (DCOS) - Acuerdo sobre Contratación Pública en apoyo a la interoperabilidad y los estándares abiertos

3er Internet Governance Forum (IGF)

Hyderabad, India

6 de diciembre 2008

Preámbulo

Las Partes Contratantes,

Recordando la Declaración de Principios de “World Summit on the Information Society” (WSIS), que establece que ” las normas internacionales tienen por objeto crear un entorno en el que los consumidores pueden tener acceso a servicios en todo el mundo, independientemente de la tecnología subyacente”,

Reconociendo que las normas cada vez más son preocupaciones mundiales, que involucran bienes y servicios que se mueven en el comercio internacional a través de las fronteras,

Consciente de que la actual competición y soluciones jurídicas pueden no ser suficiente para resolver las tensiones inherentes que habitualmente surgen en el ámbito de las patentes y normas,

Deseosos de fomentar las políticas de adquisiciones que requieran la evaluación de múltiples productos concurrentes y basados en estándares abiertos de TIC con el fin de garantizar la igualdad de condiciones a los proveedores, los gobiernos y los consumidores,

Conscientes de la necesidad de políticas de adquisición de software basados en los estándares abiertos,

Estándares abiertos

Habida cuenta de la multiplicidad de interpretaciones del término estándares abiertos, con el propósito de este documento, apoyamos como una definición aceptable la posición contenida en la “European Interoperability Framework” de la Unión Europea:

1) El estándar abierto es adoptado y será mantenido por una organización sin fines de lucro, y su continuo desarrollo se produce sobre la base de un procedimiento abierto de toma de decisiones a disposición de todas las partes interesadas (consenso o decisión por mayoría, etc.).

2) El estándar abierto ha sido publicado y el documento de especificación del estándar está disponible, ya sea libremente o en un cargo nominal. Debe ser permitido a todos a copiar, distribuir y utilizar sin costo alguno o a un precio nominal.

3) La propiedad intelectual - patentes, es decir, que puedan estar presentes - de (o partes de) el estándar abierto serán irrevocablemente disponible en una base libre de regalías (royalty free).

4) No hay limitaciones en la reutilización de la norma.

(IDABC EIF v2 v2 (http://ec.europa.eu/idabc/en/document/7728))

Como se señaló en el European Interoperability Framework antes citado, estándares abiertos o las especificaciones técnicas deben permitir que todas las partes puedan aplicar el estándar y competir en calidad y precio. El objetivo es disponer de una competitiva e innovadora industria, y no proteger las cuotas de mercado mediante el aumento de obstáculos a los recién llegados. Por lo tanto, las normas abiertas o las especificaciones técnicas deben ser posible aplicables en el software distribuido bajo las más comúnmente licencias utilizadas de código abierto, sin limitaciones derivadas de los derechos de propiedad intelectual asociados con la norma en cuestión.

Además de los requisitos antes mencionados, se recomienda que debe haber múltiples implementaciones independientes de la norma.

Los gobiernos, instituciones publicas o sin fines de lucro, acuerdan en aplicar las siguientes políticas.

Los gobiernos, instituciones publicas o sin fines de lucro
Acuerdan las siguientes medidas con el fin de fomentar la interoperabilidad y la accesibilidad a través de la utilización de estándares abiertos.

1. Crear una declaración de política sobre interoperabilidad y estándares abiertos, que estará a disposición de los empleados y el público.

2. Para 2010, las adquisiciones de todo el software deberá ser a través de un proveedor neutral y implementar los estándares abiertos.

3. En 2010, las especificaciones para compra del hardware (incluidoslos periféricos y dispositivos móviles) debería exigir que los fabricantes entreguen los drivers y información de la interfaz necesaria para trabajar con un margen razonable de sistemas operativos, privativos y en software libre.

4. Para 2010, todas las páginas web de acenso publico deben ajustarse a las normas de W3C para su estructura, presentación y accesibilidad.

5. Para 2010, las licitaciones para el suministro de servicios basados en web (por ejemplo, las reservas en línea) debe especificar los requisitos del punto 4.

6. Para 2010, los organismos deben aplicar políticas en relación con el almacenamiento y archivo de datos públicos y los registros para asegurar que los datos se almacenen en formatos abiertos de datos y documentos.

Firmado por:

Aslam Raffee, Government IT Officers’ Council, OSS Working Group, Republic of South Africa

Association for Progressive Communications (APC)

Bob Jolliffe, Freedom To Innovate, South Africa

Centre for Internet and Society, India

Hamid Rabiee, Sharif University of Technology, Iran

Knowledge Ecology International

Moving Republic, India

Shuttleworth Foundation, South Africa

Swathanthra Malayalam Computing, India

Avalado por:

Alternative Law Forum, India

Bangladesh Friendship Education Society, Bangladesh

CECS (Community Education Computer Society), South Africa

Foundation for Media Alternatives, Philippines

Indian Social Action Forum (INSAF), India

IT for Change, India

OpenForum Europe

Schoolforge-UK, UK

Las entidades interesadas en apoyar el acuerdo debe enviar un e-mail a IGF-dcos @ keionline.org.

*Gracias a Rafael Bonifaz por me ayudar con la traducción a Español.