Sobre os últimos anos, temos visto um monte de baderna ocorrendo no cenário internacional de padronização, e na minha opinião esta bagunça só aconteceu porque o “mundo mudou”, mas não mudaram as pessoas que trabalham com normalização.

A maioria dessas pessoas trabalham com normalização desde que eu nasci (1974), e eu reconheço que não deve ser uma tarefa fácil para eles, compreender e re-adequar para o novo mundo (e as novas regras de colaboração).

Com isto dito, o principal lição que eu tirei da infame aprovação do OpenXML pela ISO é que as coisas só vão mudar quando as pessoas mudarem, não apenas os desenvolvedores de padrões, mas também membros dos Boards das instituições internacionais de padronização.

É por isso que estou feliz em ver o meu amigo Charles Schulz como um candidato ao Board of Directors do OASIS (a votação termina no dia 23).

Creio que OASIS está fazendo um excelente trabalho, mas também acredito que nós realmente precisamos de ter pessoas como nós sendo cada vez mais bem preparadas para ocupar posições de liderança em instituições de padronização. Pessoas que não são apenas viciadas em tecnologia, mas também viciados em trabalho colaborativo e os seus benefícios (mais importante neste caso, a transparência).

É por isso que eu gostaria de lhe pedir que, se você tiver direitos de voto na OASIS, vote em Charles Schulz.

En los últimos años, hemos visto un montón de “cosas cuestionables” en el mundo de normalización, y, en mi opinión la mayor parte dellas, ocurren por que el “mundo ha cambiado”, pero no cambiaran los muchachos que trabajan y coordinan la normalización.

La mayoría de esa gente está trabajando con la normalización desde que yo he nacido (1974), y reconozco que no es una tarea fácil entender y se re-adecuar al nuevo mundo (y las nuevas normas de colaboración).

Dicho esto, la mayor lección que he extraído de la infame aprobación OpenXML en ISO es que las cosas sólo cambian cuando la gente cambia, no sólo el nivel de los desarrolladores de estándares, sino también los miembros del Board de las instituciones que los desarrollan.

Esta es la razón por la que estoy feliz de ver a mi amigo Charles Schulz como candidato al “Board of Directors” del OASIS (la votación termina el 23 de junio).

Creo que OASIS está haciendo un trabajo excelente, pero también creo que realmente necesitamos tener gente como nosotros en preparación para ocupar posiciones de liderazgo en las instituciones de normalización. Personas que son adictos a la tecnología, pero también adicto a la colaboración y sus beneficios (más importante en este caso, la transparencia).

Por esta razón, quisiera pedirle, si usted tiene el derecho de voto en OASIS, para votar en Charles Schulz.

On the past years, we’ve seen a lot of mess on the standardization world, and in my opinion most of that mess just happened because “World has changed” but normalization fellas don’t.

Most of those folks are working with standardization since I was born (1974), and I recognize that it isn’t an easy task to understand and re-adequate themselves to the new world (and the new collaborative rules).

With that said, the major lesson that I took from the infame OpenXML approval at ISO is that the things will only change when people change, not only the standard’s developers but also the board members of Standards Development Institutions.

This is why I’m happy to see my friend Charles Schulz as a candidate for OASIS’s Board (the ballot ends on June 23).

I believe that OASIS is doing an excellent job, but I also believe that we really need to have people like us being prepared to occupy leadership positions on standardization institutions. People that are addicted to technology, but also addicted to the collaborative work and its benefits (most important on this case, transparency).

This is why I would like to ask you, if you have voting rights at OASIS, to vote on Charles Schulz.

Tal como já havia feito com Java e HTML (só para citar dois casos), a Microsoft agora investiu ao menos 12 meses de trabalho para tentar fragmentar o ODF no mercado de TI: Uma vergonha.Juro que tinha me preparado para publicar nesta semana um post elogiando a Microsoft por ter finalmente lançado o SP2 do Office 2007 com suporte nativo ao ODF, mas infelizmente após os testes iniciais de diversos usuários, o que vemos é uma tentativa absurda de enganar os consumidores (que pagaram pelo software) e fragmentar o ODF na indústria de TI.

Quando uso o termo fragmentar, me refiro á tática já conhecida de usar a ‘criatividade’ no momento de implementação de um padrão para tornar a sua implementação compatível apenas com a sua ferramenta (que já viu sites que só funcionam no Internet Explorer sabe bem do que estou falando). Por fora os documentos parecem idênticos e compatíveis mais por dentro são completamente diferentes, fragmentando assim a uniformidade esperada com a utilização de um padrão.

Um dos primeiros artigo publicado sobre o tema e para o qual chamo a atenção de todos é do Rob Weir, coordenador do OASIS ODF TC (grupo que desenvolve o ODF, do qual faço parte). Chega a ser assustador o que o Office 2007 faz com as planilhas existentes de ODF.

Os detalhes técnicos estão todos no blog do Rob, mas em resumo, quando se abre uma planilha ODF (extensão .ods) existente no Office 2007, ele simplesmente elimina todas as fórmulas existentes sem avisar nada ao usuário, deixando nas células apenas os valores do resultado do cálculo das fórmulas (valores estes já previamente armazenados no documento). Se um usuário quiser testar o suporte ao ODF no Office, e sem prestar a devida atenção salvar uma planilha aberta, vai sobrescrever o documento eliminando todas as fórmulas, como se estivesse gravando um documento que foi totalmente digitado. Já vi absurdos na vida, mas nada se compara a isso.

Quando se utiliza o Office 2007 para gerar uma nova planilha, as fórmulas serão armazenadas de tal forma que só o Office 2007 (ou o CleverAge, um plug-in de suporte ao ODF para o Office desenvolvido em Open Source com patrocínio da Microsoft) será capaz de ler o documento, acabando com a possibilidade de que qualquer outra aplicação existente seja capaz de ler o documento.

Enquanto o primeiro problema simplesmente joga fora toda a inteligência de negócios dentro das planilhas (as fórmulas), o segundo prende o usuário ao Office 2007 para sempre (já vimos este filme antes, não é mesmo ?).

A justificativa que a Microsoft poderia usar para isso é a falta de definição de fórmulas em planilhas no ODF 1.0/1.1. Interessante notar que no ODF 1.2 (que é desenvolvido com a participação da Microsoft) este problema já foi resolvido com a criação do OpenFormula.

Na primeira tabela comparativa do post do Rob, que resume um teste sobre o mesmo assunto que ele fez há algumas semanas, fica fácil perceber que mesmo sem existir a especificação de fórmulas para planilhas dentro do ODF 1.1, a interoperabilidade entre as aplicações existentes testadas (KOffice, OpenOffice, Google Docs, Symphony e o plug-in da Sun para o Office) existe de fato (com exceção do CleverAge que apresentou alguns problemas). Isso significa que todos os outros desenvolvedores não se preocuparam apenas em ‘cumprir com um requisito de norma’ (ou seja, conformidade), mas também em desenvolver uma aplicação realmente útil e interoperável para seus usuários. O Rob comenta ainda que o conjunto de fórmulas utilizado por todas estas aplicações (com base no OpenOffice) foi desenvolvido com base nas fórmulas existentes no Excel (no mínimo irônico, heim ?).

Destaco ainda que os problemas apresentados pelo OpenOffice quando o Rob repetiu seus testes com a versão nova da suíte, foram causados por que os desenvolvedores do OpenOffice 3.0 decidiram incorporar como padrão na ferramenta o suporte ao ODF 1.2 que ainda está em desenvolvimento do OASIS. Não questiono o que os levou a tal decisão, mas tenho orientado a todos os usuários do OpenOffice 3.0 que conheço, que alterem a configuração da suíte para utilizar como padrão o ODF 1.0/1.1 (no menu de Opções do OpenOffice existe um grupo chamado “carregar/salvar” onde esta configuração pode ser feita). Admiro o esforço dos desenvolvedores do OpenOffice em incorporar o ODF 1.2 à sua ferramenta, mas acho que isso deveria ter sido colocado como uma funcionalidade adicional, e não como o seu formato padrão (tenho usado o meu OpenOffice 3.0.1 configurado para trabalhar com o ODF 1.0/1.1 e não tenho tido nenhum problema de interoperabilidade).

Gostei também de ver a avaliação que PJ (Groklaw) fez sobre o SP2 do MSOffice. PJ não desenvolve software e por isso criou um documento texto relativamente simples e obteve resultados absurdos também.

PJ escreve ainda algo bem interessante, e concordo 100% com o que escreveu:

“…Querida Microsoft, você poderia por favor fazer alguma coisa sobre isso ? É somente código, o que significa que pode ser corrigido. Como seu código é proprietário, nós não podemos corrigi-lo. Só você pode. Como as canções antigas falam, você poderia por favor acelerar isso ? Outros como o Google Docs parecem ser capazes de trabalhar com planilhas em ODF. Por que vocês não são ? Não tenho dúvidas de que haverão melhorias, mas quando ?…”

Como não tenho nenhuma máquina com Windows e não tenho o Office 2007 para testar, acabei testando algumas coisas no SP2 através de troca de documentos com amigos que possuem o Office 2007 e aqui vão os meus 2 centavos para os testes que todos estão fazendo (e publicando os resultados a cada segundo na rede):

O Microsoft Office 2007 não suporta a criptografia (proteção por senha) nos documentos ODF !!!

Gerei um documento texto (.odt) simples em ODF utilizando o OpenOffice e o gravei com proteção de senha. Enviei o documento (e a senha) a diversos amigos e o resultado foi o mesmo: O MS Office não pode abrir o documento pois ele está protegido por senha (alguns deles tinham em suas máquinas outras ferramentas com suporte a ODF e em 100% dos casos funcionou).

Pedi a eles que gerassem no Office 2007 um documento com senha e me enviassem, e disseram que quando tentam fazer isso, o Office apresenta uma mensagem de aviso dizendo que não é possível utilizar senha para proteger o documento utilizando o formato ODF.

Gostaria de verdade de encontrar uma explicação técnica para isso, uma vez que a criptografia e a proteção por senha estão completamente especificadas dentro do ODF 1.0/1.1 (item 17.3 da especificação), e utilizam algorítimos já existentes e mais do que conhecidos por qualquer desenvolvedor.

Um comentário do Rob no seu post (que não tratou da criptografia) é capaz de comentar com maestria o problema que encontrei (e concordo plenamente com ele):

“…Me ensinaram a nunca presumir malícia onde a incompetência pode ser a explicação mais simples. Mas o grau de incompetência necessária para explicar o suporte pobre ao ODF no Service Pack 2 atormenta a mente e me leva a ter pensamentos cruéis…”

É impressionante ver como a Microsoft demonstra constantemente o desrespeito aos seus clientes (o que eu ouvi de clientes deles ansiosos pelo suporte ao ODF no Office…), desrespeito aos parceiros de mercado e uma completa incapacidade de mudar.

Antes de encerrar o post, quero alertar aos incondicionáveis apoiadores da Microsoft que insistem em postar comentários sem conteúdo técnico algum neste blog que não tenho mais mais paciência (nem tempo) para ser educado ao responder as imbecilidades que vocês costumeiramente escrevem por aqui. Se escreverem bobagem aqui, vão receber resposta a altura. Se querem mesmo defender a Microsoft, enviem um curriculum para a empresa e tentem trabalhar lá dentro para mudar as coisas (falar é muito fácil, já fazer é outro assunto).

Aos demais, todos os comentários serão bem vindos (como sempre) e se encontrarem mais textos por aí comentando os problemas referentes ao ODF no Service Pack 2, por favor coloque os links nos comentários (vamos fazer deste post uma fonte para pesquisas sobre o assunto).

A todos, segue minha recomendação: Não utilizem o Office 2007 com o Service Pack 2 para manipular documentos em ODF. Se a sua decisão for continuar utilizando o MS Office (em qualquer versão), instale o plug-in da Sun, mas recomendo mesmo que vocês procurem uma outra solução que trate nativamente documentos ODF. Não percam mais tempo com quem não lhes respeita.

Quem quiser acompanhar as notícias sobre ODF no mundo, recomendo uma visita diária ao Planet ODF (ele indexa tudo).

Tal como han echo con Java y HTML (sólo para citar dos casos), Microsoft ha investido al menos 12 meses de trabajo para intentar fragmentar el ODF en el mercado de TI: Una vergüenza.Te lo juro que yo estaba listo para publicar esta semana un texto para congratular Microsoft por el lanzamiento del Service Pack 2 (SP2) de Office 2007 con soporte nativo a el ODF, pero lamentablemente después de las pruebas iniciales de distintos usuarios, lo que vemos es un absurdo intento de engañar los consumidores (que pagan por el software) y fragmentar el ODF en la industria de TI.

Cuando utilizo el termo ‘fragmentar’, me refiero a conocida táctica de utilizar la ‘creatividad’ durante la implementación de un estándar, de modo que tal implementación sólo sea compatible con su herramienta (quien ha visto los sitios que sólo funcionan en Internet Explorer saben muy bien do que estoy hablando). Externamente, los documentos parecen idénticos, pero cuando se mira su interior de forma más consistente, se nota que son completamente diferentes, lo que fragmenta la uniformidad esperada con el uso de un estándar.

Uno de los primeros artículos publicados sobre el tema y para lo cual llamo la atención de todos es el de Rob Weir, coordinador del OASIS ODF TC (grupo que desarrolla el ODF, do cual soy miembro). Es temeroso lo que hace Office 2007 con las hojas de cálculo del ODF existentes.

Los detalles técnicos están en el blog de Rob, pero en resumen, cuando se abre una hoja de cálculo existente del ODF (extensión .ods) en el Office 2007, el simplemente elimina la totalidad de las fórmulas matemáticas existentes, sin decir nada para el usuario, dejando sólo los valores en las células (resultado del cálculo de las fórmulas, que fueran almacenados previamente en el mismo documento). Si un usuario quiere poner a prueba el ODF en el Office 2007, y sin prestar la debida atención, decide guardar una hoja de cálculo abierta ya existente, se sobrescribirá el documento, eliminando todas las fórmulas, como si estuviera escribiendo un documento que ha sido completamente echo a mano (como una simples tabla). Ya vi cosas absurdas en la vida, pero nada comparado con esto.

Cuando se utiliza Office 2007 para generar una nueva hoja de cálculo, las fórmulas se almacenarán de manera que sólo el Office 2007 (o el CleverAge, un plug-in de soporte a el ODF en el Office 2007 desarrollado en Open Source y patrocinado por Microsoft) podrán leer el documento. Eso elimina la posibilidad de que cualquier otra aplicación existente sea capaz de leer el documento.

Mientras que el primer problema simplemente saque toda la inteligencia de negocios de dentro de la hoja de cálculo (fórmulas), el segundo prende el usuario a el Office 2007 para siempre (ya hemos visto esta película antes, ¿no?).

La justificativa que Microsoft puede intentar utilizar para esto, es la falta de definición de fórmulas en hojas de cálculo en el ODF 1.0/1.1. Interesante observar que en el ODF 1.2 (que se desarrolla con la participación de Microsoft), este problema se ha resuelto con la creación del OpenFormula.

En el primer cuadro comparativo en el post de Rob, que resume un ensayo sobre el mismo tema que el lo hizo hace un par de semanas, es fácil ver que, incluso sin ningún tipo de definición de las fórmulas de las hojas de cálculo dentro de el ODF 1.1, la interoperabilidad entre las aplicaciones existentes y testadas ( KOffice, OpenOffice, Google Docs, y la Sinfónica de Sun plug-in para Office) existe de facto (a excepción de CleverAge que presenta algunos problemas). Esto significa que todos los demás desarrolladores no están interesados sólo a “cumplir con un requisito de norma”, sino también en el desarrollo de una verdadera y útil aplicación interoperable para sus usuarios. Rob dice que el conjunto de las fórmulas utilizadas por estas aplicaciones (basado en OpenOffice) se desarrolló sobre la base de las fórmulas del Excel (por lo menos irónico, ¿no?).

También destaco que los problemas encontrados en OpenOffice cuando Rob reiteró su pruebas con la nueva versión de la suite, fueron causados por que los desarrolladores del OpenOffice 3.0 han decidido incorporar el soporte a el ODF 1.2 (que aún está en desarrollo en la OASIS) como el formato default de la suite ofimática. No cuestiono tal decisión, pero estoy recomendando a todos los usuarios de OpenOffice 3.0 que yo conozco, que cambien la configuración de su suite para utilizar como default el ODF 1.0/1.1 (en el menú Opciones de OpenOffice hay un grupo llamado “cargar/guardar” - o cosa equivalente - en lo cual que se puede hacer la configuración recomendada). Admiro el esfuerzo de los desarrolladores de OpenOffice para incorporar el ODF 1.2 a su herramienta, pero creo que debería haber sido colocado como una característica adicional, no como su formato default (uso mi OpenOffice 3.0.1 para trabajar con ODF 1.0/1.1 y no he encontrado ningún problema de interoperabilidad hasta ahora).

Me gusto también veer lo que escribió PJ (Groklaw) acerca del MSOffice SP2. PJ no desarrolla software y, por tanto, ha creado un documento de texto simples y lo que ha encontrado es demasiado absurdo.

PJ también escribe algo muy interesante, y estoy 100% de acuerdo :

“… Estimada Microsoft, ¿ustedes podrían hacer algo al respecto? Es sólo código, lo que significa que se puede corregir. A medida que su código es propietario, no podemos arreglarlo. Sólo usted puede. Como dice la vieja canción, ¿podría acelerar esto? Otros, como el Google Docs parecen ser capaces de trabajar con hojas de cálculo en el ODF. ¿Por qué ustedes no? No me cabe duda de que habrá mejoras, pero cuando ?…”

Como no tengo ninguna máquina con Windows y Office 2007 para las pruebas, he probado algunas cosas sobre el SP2 intercambiando documentos con amigos que tienen Office 2007 con el SP2 y aquí están mis 2 centavos para todas las pruebas que la gente esta haciendo (y publican los resultados a cada segundo en la red):

Microsoft Office 2007 no soporta criptografia (protección con contraseña) en documentos ODF !

He generado un documento ODF de texto (.odt) simples con el OpenOffice, y lo guardé con la protección de contraseña. He enviado el documento (y la contraseña) a varios amigos, y el resultado fue el mismo: El MS Office no puede abrir el documento, ya que está protegido con contraseña (algunos de ellos en sus máquinas también tienen otras herramientas con soporte el ODF y en 100% de los casos el documento fue abierto sin problemas).

Les pedí que generasen un documento texto ODF en el Office 2007 con contraseña y que lo enviasen a mí. Me informaran que cuando se intenta hacerlo, el Office presenta una mensaje de advertencia diciendo que no puede usar una contraseña para guardar que el documento utilizando el formato ODF.

Quisiera encontrar una explicación técnica para esto, ya que la criptografia y la protección con contraseña están completamente especificadas en el ODF 1.0/1.1 (artículo 17.3 de la especificación), y son utilizados algoritmos bien conocidos que cualquier desarrollador.

Un comentario de Rob en su post (que no trata de criptografia) es capaz de comentar con maestría el problema que he encontrado (y estoy totalmente de acuerdo con Rob):

“… Me enseñaron a jamás asumir malicia cuando la incompetencia puede ser la explicación más simples. Pero el grado de incompetencia necesario para explicar la pobre implementación del ODF en el Service Pack 2 es de atormentar la mente y me lleva a tener crueles pensamientos … ”

Es impresionante ver cómo Microsoft constantemente muestra falta de respeto a sus clientes, a sus “partners” en el mercado, además de una demostración de completa incapacidad para el cambio.

Son bienvenidos todos los comentarios (como siempre) y quien encontrar más textos comentando problemas relativos a el ODF en el Service Pack 2, por favor, poner sus enlaces en los comentarios (podemos hacer este post una referencia para la investigación futura sobre el tema).

Mi recomendación final: No utilizar Office 2007 con el Service Pack 2 para la manipulación de documentos ODF. Si tu decisión es todavía utilizar MS Office, instale el plug-in de Sun, pero recomiendo realmente que busque otra solución que soporte adecuadamente el ODF. No perca más tiempo con aquellos que no les respetan.

Quién quiere seguir diariamente las noticias sobre el ODF en el mundo, recomiendo una visita diaria al Planeta ODF.

As they did in the past with Java and HTML (just to cite two cases), Microsoft has now invested at least 12 months of work to try to fragment the ODF in the IT market: A shame.I swear I was ready to publish this week a post praising Microsoft for finally released SP2 of Office 2007 with native support for ODF, but unfortunately after the initial tests of various users, what we see is an absurd attempt to mislead consumers (who payed for the software) and fragment ODF in the IT industry.

When I use the word fragment, I mean the known tactic of using ‘creativity’ during the implementation of a standard to make the implementation only compatible with your software (people that had seen sites that only work in Internet Explorer already know what I’m talking about). Looking from outside, the documents appear identical but a most consistent inside look demonstrate that they are completely different, thus fragmenting the uniformity expected as a consequence of a standard adoption.

One of the first articles published about SP2 and for which I call the attention of everyone is from Rob Weir, chair of the OASIS ODF TC (group that develops the ODF, to which I belong). It is simply scary to see what Office 2007 does with existing ODF spreadsheets.

The technical details are all on Rob’s blog, but in summary, when opening an ODF spreadsheet (.ods file) using Office 2007, it simply removes all existing formulas without telling anything to the user, leaving only the values in cells (results of formulas evaluation, previously stored in the document). If a user wants to test the ODF support in Office, and without giving due attention, save an existing spreadsheet, will overwrite the document removing all the formulas (as if you were writing a table). I saw absurdities in life, but nothing compared to this.

When using Office 2007 to generate a new worksheet, the formulas will be stored in a way that only will be understood by Office 2007 (or by CleverAge, an MS Office plug-in to support ODF, developed as Open Source and sponsored by Microsoft), eliminating the possibility that any other existing application could be used to usefully read the document.

While the first problem simply throw out all the business intelligence inside the spreadsheet (formulas), the second locks in the user on Office 2007 forever (we have seen this movie before…).

The justification that could be used by Microsoft about it, is the lack of spreadsheet formula definition in ODF 1.0/1.1. Interesting to note that in ODF 1.2 (which is developed with the participation of Microsoft) this problem has been resolved with the creation of OpenFormula).

The first comparative table of Rob’s post, summarizes a test on the same subject that he did a few weeks ago, it is easy to see that even without any spreadsheet formula definition inside ODF 1.1, interoperability between the tested set of existing applications ( KOffice, OpenOffice, Google Docs, Symphony and Sun’s plug-in for Office) really exists on the real world (except for CleverAge that presented some problems). This means that all other developers are not concerned only to ‘comply with standard’s requirements’ (conformance) but also in developing a truly useful and interoperable application to users. Rob also says that the set of formulas used by these applications (based on OpenOffice) was developed based on existing formulas from Excel (at least ironic, huh?).

I also highlight that the problems presented on OpenOffice when Rob repeated his tests with the new version of the suite, were caused because the developers of OpenOffice 3.0 decided to incorporate ODF 1.2 as default. ODF 1.2 still under development in OASIS. No question about what led to this decision, but I’ve orientated all users of OpenOffice 3.0 that I know, to change the configuration of the office suite to use ODF 1.0/1.1 as the default file format (in the Options menu of OpenOffice, there is a group called “load / save” where it can be done). I admire the efforts of OpenOffice’s developers to incorporate the ODF 1.2 to their software, but I think it should have been placed as an additional feature, not as its default format (I’m using OpenOffice 3.0.1 configured to work with ODF 1.0/1.1 and I’ve had no interoperability problems at all).

I also enjoyed to see the comments that PJ (Groklaw) (I think it was PJ) made about MSOffice SP2. PJ isn’t a developer and therefore created a simple text document and find absurd results too.

PJ also wrote something very interesting, and I agree 100%:

“…Dear Microsoft, could you please do something about this? It’s just code, which means it can be fixed. But your code is proprietary, so we can’t fix it. Only you can. Like the old song says, could you please put on some speed? Others like Google Docs seem to be able to do ODF spreadsheets. Why can’t you? No doubt there will be improvements, but when?…”

As I don’t have a computer with Windows and I don’t have MS Office 2007 to test, I did some tests with SP2 trough the exchange documents with friends who have Office 2007 with SP2 installed and here are my 2 cents for all the tests that are appearing (and being published every second on the Internet):

Microsoft Office 2007 does not support encryption (password protection) in ODF documents !

I generated a simple text document (.odt) in ODF using OpenOffice and saved it with password protection. I sent the document (and password) to several friends and the result was the same: MS Office cannot open the document because it is password protected (some of those friends also have installed on their computers other tools that support ODF and on 100% of those tools it worked).

I also asked them to generate a document in Office 2007 with password protection and send me, but they said that when trying to do this, MSOffice presented a warning message saying that you cannot use password protection using the ODF format.

I would really like to find a good technical explanation for this, since the encryption and password protection are fully specified in ODF 1.0/1.1 (item 17.3 of the specification), and they are using existing algorithms, very familiar to any developer.

A comment from Rob in his post (that not dealt with the encryption) is able to comment with mastery the problem I found (and I fully agree with him):

“…I was taught to never assume malice where incompetence would be the simpler explanation. But the degree of incompetence needed to explain SP2’s poor ODF support boggles the mind and leads me to further uncharitable thoughts… ”

It is impressive to see how Microsoft constantly shows disrespect for their customers, partners and the market in general and it is also impressive to see this clearly demonstration of their complete inability to change.

If anyone have more texts about ODF problems found on Service Pack 2, please put the links on the comments (we can use this post as a source for research about those problems).

Here is my recommendation: Don’t use Office 2007 with Service Pack 2 for manipulating ODF documents. If your decision is still using MS Office, install the Sun’s plug-in, but I really recommend that you search for another solution that natively support ODF documents. Don’t loose time (and money) with those who disrespect you.

For people who wants to follow the news about ODF in the world, I recommend a daily visit to Planet ODF (it indexes everything).

He recibido en los últimos días varios documentos del JTC1/SC34 acerca de los progresos en el grupo de trabajo que está tratando de arreglar el OpenXML, y es impresionante lo hay de información surrealista en estos documentos.

El documento N1101/N1168 contiene por ejemplo, varios artículos en los que reconocen que hay decisiones tomadas en el BRM que no fueron incorporadas en el texto final de la norma publicada. En otras palabras, aun teniendo casi un año después de la aprobación de la norma a publicar el texto (sí, aprobado sin leer), no hubo tiempo/atención o cualquier otra cosa necesaria para hacer los cambios (algunos condicionantes de la aprobación) en el texto. Lo que más me deja enojado por esto, es que durante el BRM he preguntado acerca de quién sería responsable de verificar que todos estos cambios serían parte del texto final y la respuesta fue ITTF (como una secretaría conjunta de la ISO y la IEC). Cuando he preguntado si la ITTF realmente haría este trabajo, he recibido una respuesta intimidatoria: “Estas a dudar del ITTF, muchacho?” …

Peor que eso, es que las informaciones contenidas en este documento, para mí son suficientes para dudar de que todas las correcciones que han sido aprobados fueran aplicadas en el texto. Si antes sospechaba de que esta última versión de la especificación no era lo que todo el mundo pensaba, ahora estoy seguro que no es y creo que no hay problemas aún más graves encontrados por que la mayoría de la gente, como yo, se niega a mirar nuevamente las malditas 6.000 páginas.

En el documento N1171, uno de los grupos de trabajo de SC34 anuncia que fueran encontrados problemas en las fuentes del OpenXML y enviarán un informe de error sobre la cuestión al grupo responsable de la reparación de la norma (se ve gracioso, pero hasta hoy se están encontrando defectos…).

El documento N1183 justifica la subdivisión de las partes actualmente existentes de la norma, al decir que esto es necesario para que se pueda corregir algunos errores señalados, añadiendo a la especificación nuevas “pequeñas” funcionalidades (y que está bien, ahora que la ISO ha aprobado la norma, pueden escribir lo que quieras, ¿no?).

Me salvó la mejor para el final, el documento N1187, que nos relata que el OpenXML contiene “errores involuntarios que pueden impedir que los documentos existentes sean representados en este nuevo formato.” El soporte a el “legado de documentos” fue la razón principal utilizada para que se desarrollase y aprobase el OpenXML, y fue también la razón por la cual varios países apoyaron el desarrollo y la aprobación de la norma. Como eso se explica ahora ? En este documento, se explica también los criterios que se utilizarán para especificar los cambios que se desarrollarán a fin de que puedan hacerlo con rapidez (en otras palabras, abusan de la interpretación de las directivas del JTC1  para obtener los cambios necesarios o deseados si que se haga mucho ruido en el proceso).

Lamentablemente no puedo poner todos estos documentos para aquí en mi blog por que debe ser documentos rescritos del SC34 (0% de transparencia), pero creo que, tarde o temprano, ellos deberán ser publicados en alguna parte (y por supuesto, quién es miembro de su NB ya los debería haber recibido).

Desde niños he aprendido a no firmar el papel en blanco, pero creo que esto no es una lección valiosa en otros países.

Me gustaría de ver la contestación a algunas preguntas:

Brasil, Sudáfrica, India y Venezuela, tenían o no la razón cuando apelaran a la ISO (y fueran ignorados completamente)?

Sera que los mismos señores del board de la ISO, que ignoraran los protestos, están ahora siguiendo el desarrollo y documentos como los que he comentado aquí?

¿Quiénes son responsables de todo eso? Cómo se paga?

Received in recent days several documents from JTC1/SC34 reporting the progress at the working group that is trying to fix the OpenXML, and it’s impressive and surreal what one may find in those documents.

The document N1101/N1168 contains for example, several items in which they recognize that there are decisions made in the BRM (BRM resolutions) which were not incorporated into the final published text of the standard. In other words, even taking almost a year after the aproval of the standard to publish the text (yes, approved without reading), there wasn’t time/attention or anything else necessary to assure that the changes were published in the text (most of those changes, “conditioned” the approval). What makes me much more angry about this is that during the BRM I asked about who would be responsible for verifying that all these changes would be part of the final text and the answer was ITTF (kind of joint ISO/IEC secretariat). When I asked if the ITTF would really make this work, I received as a reply the intimidating: “You are doubting the ITTF, kid ?”…

Worse than this, the informations inside this document are sufficient for me to doubt that the approved/recommended corrections where even implemented. If before this document I suspected that the final version of the specification wasn’t what everybody thought, now I’m pretty sure about it and I think that we didn’t find even more severe problems there because most people, like me, refuses to look at those damn 6000 pages again.

On the document N1171, one of the working groups of SC34 announces that they’ve found problems in the OpenXML fonts specification and will submit an error report about it to the group responsible for repairing the standard (looks funny, but until today there are folks finding defects … ).

The document N1183 justifies the subdivision of the already existing parts of the standard to saying that to correct some errors pointed out, new “minor” features need to be added to the specification (and that is really cool, because now that the ISO has already approved the standard, they can write whatever they want , isn’t it?).

I saved the best for the end: document N1187. This one says that OpenXML “as is” contains unintentional errors that may prevent existing documents to be fully represented in this new format.  It is amazing because the legacy support was alleged as  the main reason for OpenXML development and approval at ISO, and also the reason why several countries supported the development and approval of the standard. In this document, they also explain the criteria that will be used to specify the changes that will be developed, so that they can do it all really quickly (in other words, they go trough the breaches of the JTC1 directives to get these changes incorporated into standard already approved without making much noise about it).

Unfortunately I can not put all these documents here, to allow access trough the blog, because they should be restricted SC34 documents (yep, zero transparency), but I believe that sooner or later they will be published somewhere (and of course, NB members should already received those).

Since I was a young boy I’ve learned to not sign blank papers, but I think that this isn’t a valuable lesson in other countries.

I would like to see answered some basic questions:

Brazil, South Africa, India and Venezuela were right or not when appealed (and had their appeals ignored by the ISO)?

Do the same gentleman at the ISO board, that ignored the appeals, are following the development work and documents commented here?

Who is responsible for all this, and how he will pay?

Recebi nos últimos dias diversos documentos do JTC1/SC34 relatando os avanços nos trabalhos do grupo que está tratando da correção do OpenXML, e é impressionante o que existe de informação surreal nestes documentos.

O documento N1101/N1168 contém por exemplo, diversos itens em que eles reconhecem que existem decisões tomadas no BRM que não foram incorporadas ao texto final publicado da norma. Em outras palavras, mesmo levando quase um ano após a aprovação da norma para publicarem o texto (sim, aprovaram sem ler), não houve tempo/atenção ou qualquer outra coisa necessária para que as alterações condicionantes da aprovação fossem publicadas no texto. O que mais me deixa irritado nisso é que durante o BRM eu perguntei sobre quem seria o responsável por verificar que todas estas alterações fariam parte do texto final, e a resposta foi ITTF (secretaria conjunta entre ISO e IEC). Quando perguntei se o ITTF iria realmente fazer este trabalho, recebi como resposta um intimidador: “Você está duvidando do ITTF, garoto ?”…

Pior que isso, é que as informações existentes neste documento são suficientes para que eu duvide que todas as correções aprovadas foram mesmo implementadas. Se antes eu suspeitava que esta versão final da especificação não era o que todos pensavam, agora tenho certeza que não é e acho que não foram encontrados problemas mais graves ainda pelo simples fato de que a maioria das pessoas, como eu, se recusa a olhar aquelas malditas 6.000 páginas de novo.

No documento N1171, um dos grupos de trabalho do SC34 alerta que encontrou problemas nas fontes do OpenXML e que irá enviar um relatório de erros sobre o assunto ao grupo responsável por consertar a norma (parece piada, mas estão encontrando defeitos até hoje…).

O documento N1183 justifica a subdivisão das partes da norma dizendo que para que se possa corrigir alguns erros apontados, novas “pequenas” funcionalidades precisam ser adicionadas á especificação (e isso é bem legal, agora que a ISO já aprovou, podem escrever o que quiser, não é mesmo ?).

Guardei o melhor para o final, pois no documento N1187, afirmam que o OpenXML contém “erros não intencionais que podem impedir que documentos existentes sejam representados neste novo formato”. Não era o suporte ao legado a principal razão para que o OpenXML fosse desenvolvido, razão pela qual diversos países apoiaram o desenvolvimento e a aprovação do padrão ? Ainda neste documento, explicam qual será o critério utilizado para especificar as alterações que serão desenvolvidas, para que possam faze-lo com rapidez (em outras palavras, andam pelas brechas das diretrizes do JTC1 para conseguir fazer estas alterações serem incorporadas á norma já aprovada sem levantar poeira).

Infelizmente não posso colocar estes documentos para que todos acessem aqui no Blog pois são documentos restritos do SC34 (transparência zero), mas acredito que cedo ou tarde eles devem ser publicados em algum lugar (e claro, quem é membro de seu NB já deveria ter recebido).

Desde criança aprendi a não assinar papel em branco, mas me parece que este não é um ensinamento tão valioso em outros países.

Gostaria de ver respondidas algumas perguntinhas básicas:

O Brasil, África do Sul, Índia e Venezuela estavam ou não com razão quando apelaram (e tiveram seus apelos ignorados pela ISO) ?

Será que os mesmos senhores do board da ISO que ignoraram os apelos recebidos estão acompanhando o desenvolvimento dos trabalhos e os documentos que comento aqui ?

Quem são os responsáveis por isso tudo ? Vão pagar como ?

Para celebrar el DocumentFreedom Day (DFD) mañana, la ODF Alliance Capítulo Brasil y 4Linux  van transmitir en directo mañana a las 7 pm (GMT -3) un talk show conmigo (Jomar Silva), Luiz Maluf (Sum Microsystems) y Marcelo Marques (4Linux y HackerTeen).

Durante una hora, contestaré todas las preguntas acerca del ODF enviadas a boteconet EN 4Linux.com.br (usted puede enviar sus preguntas en inglés / español / portugués antes o durante el evento). John maddog Hall ya nos ha enviado su pregunta.

El archivo de audio estará disponible para descargar a partir del final del programa, como un podcast.

El talk show será sólo en portugués, por lo que será una muy buena oportunidad para entrenar tu portugués de Brasil (yo se que usted planea llegar a Bahía o Río por lo menos una vez en tu vida, ¿ok?).

Para escuchar el programa, conectar el reproductor VLC para boteco.4linux.com.br: 8003 (usando HTTP / HTTPS / FTP / MMS).

Esperamos recibir (y contestar) a sus preguntas.

Grand DFD a todos