“Uma das minhas atribuições profissionais é representar oficialmente a IBM em entidades de padrões como a ABNT. Como estamos no processo final de avaliação da proposta OpenXML e a poucos dias de definir o voto brasileiro na ISO, tenho dedicado grande parte do meu tempo a esta atividade. Isto se reflete nos inúmeros posts que venho levantando sobre o assunto.

E, aqui vai mais um... Recentemente estive debatendo com professores e estudantes de diversas universidades sobre esta questão. Vou resumir alguns pontos debatidos.

Tenho começado o debate mostrando que já existe um padrão para formato de documentos, independente de fornecedor e aprovado pelo ISO desde maio do ano passado, que é o ODF. Agora, estamos debatendo a proposta da Microsoft e da Ecma de criar um segundo padrão. Esta proposta chegou à ISO através do processo chamado fast track, com um exíguo período de seis meses para as entidades de padrões (o Brasil é um deles) avaliar as suas mais de 6.000 páginas de documentação.

Uma pergunta que me fizeram várias vezes: “Porque dois padrões?”.Uma das principais alegações para apresentar este segundo padrão é que o OpenXML foi desenhado para garantir compatibilidade com os documentos legados do Office (vejam bem, apenas do Office...). Na proposta Ecma isto é claro: “OpenXML was designed from the start to be capable of faithfully representing the pré-existing corpus of Word-processing documents, presentations and spreadsheets that are encoded in binary formats defined by Microsoft Corporation”. Bem, então para garantir esta compatibilidade é necessário um segundo padrão? Por que não ampliar o padrão já existente, o ODF?

A resposta pode ser encontrada na própria especificação do OpenXML, onde em vários lugares lemos coisas como “2.15.3.6 autoSpaceLikeWord95 (Emulate Word 95 Full-Width Character Spacing). This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 95)…”.Ou seja, apesar das 6.000 páginas temos que saber exatamente como o Word 95 funciona! Então, não apenas temos que digerir a imensa documentação, mas temos que saber emular o Word 95, Word 97, Word 6, etc...! E quem sabe fazer isso, a não ser a Microsoft? Aí entra uma pergunta “Um padrão aberto pode requerer extensões proprietárias para poder ser implementado?”. A resposta deve ser um sonoro não!

Portanto, o caminho mais sensato seria ter um único padrão. Dois ou mais padrões aumentam os custos para todos. Com dois padrões não temos o dobro de benefícios que teríamos com apenas um...Ah, indaga alguém: “mas já existem padrões que overlapam uns aos outros...”. Bem, o fato de isto acontecer não significa que temos que perpetuar o erro. Padrões não devem ser duplicados. Se já existir um padrão aberto, porque não agregar esforços e evolui-lo? Criar um padrão alternativo para competir com o já existente só beneficia a quem o propõe.

Mas, vamos em frente, analisando as diversas documentações livremente disponíveis na Web (o blog lista inúmeros, que podem ser acessados pesquisando-se pelas tags ODF e OpenXML), coletei algumas deficiências do OpenXML, que cito nos debates, como inconsistências com padrões ISO já existentes (OpenXML implementa “language codes” diferentes do padrão ISO 639. E conta-se às dezenas tais casos...) e uso de padrões proprietários, como Windows Metafiles e Enhanced Metafiles.

Outro ponto que faço questão de lembrar é que a única implementação do OpenXML é a da Microsoft. E mesmo assim, de forma parcial. Na verdade o padrão OpenXML foi criado em torno da aplicação Office. Uma inversão de propósito. Além disso, lembro que existem restrições de interoperabilidade entre sistemas, uma vez que o OpenXML define funcionalidades existentes apenas no Windows, como DevMode, GUID e ClipBoard Data. Estas dependências fazem com que o OpenXML não funcione da forma correta em ambientes que não o Windows.

Bem, padrões são por natureza complexos e altamente técnicos. Um processo fast track limita em muito a sua análise de forma criteriosa. Aliás, como recordar é viver, vamos lembrar a tentativa anterior da Microsoft e da Ecma de propor à ISO, via fast track a aprovação das extensões C++/CLI. Como vocês podem ver em http://www.robweir.com/blog/2007/03/fast-track-wrong-direction.html, a proposta foi abortada pela avaliação negativa das entidades de padrões. Lessons learned? Se a proposta não for bem feita, as entidades de padrões podem e devem rejeitá-la, mesmo diante das carências de tempo sob fast track.”