Na quinta feira dia 9 aconteceu mais uma reunião na ABNT da CE (Comissão de Estudo) que debate se o Brasil apoiará ou não a proposta do OpenXML se tornar um padrão ISO. Infelizmente foi uma reunião muito tumultuada e pouco produtiva…E dentro de duas semanas acontecerá a reunião final, onde a Comissão definirá o voto brasileiro.

Bem, na minha opinião os membros da Comissão só deveriam votar YES se tiverem certeza que o padrão proposto não contém erros técnicos. Um voto YES significa que a entidade brasileira está aceitando o padrão como proposto e que os únicos problemas encontrados são meramente editoriais, como vírgulas e pontos fora do lugar. A desaprovação ou voto NÃO, com comentários, significa que foram encontrados erros técnicos e existem questões de propriedade intelectual ainda não resolvidas. Este voto com comentários anexados indica que o padrão poderá a vir a ser aceito desde que os problemas sejam corrigidos da forma sugerida.

Pode haver também um voto ABSTAIN, quando a entidade não se sentir competente tecnicamente ou não tiver tido tempo suficiente para avaliar o padrão. Também pode ser usado quando a CE não chegou a consenso quanto a votar YES ou NO.

Acredito que para uma decisão consciente por um voto YES ou NO é necessário um sólido background de conhecimentos sobre o assunto. Afinal, estamos falando do voto brasileiro para adoção ou não de um padrão. Claro que ninguém teve condições de ler as mais de 6.000 páginas, pois esta é uma tarefa impossível de se cumprir nos seis meses que estavam disponíveis para análise. Mas, inúmeros blogs e documentos que circulam na Web mostram centenas de problemas técnicos. O GT (Grupo de Trabalho) na ABNT que está analisando a situação do OpenXML no Brasil também detetou e registrou um número muito grande de problemas.

Na minha opinião, o voto é “NO with comments”. Além das várias razões para isso, como levantadas nos diversos posts anteriores sobre o assunto (vejam as tags ODF e OpenXML), cito a questão da compatibilidade com documentos legados, um dos principais motivos alegados para a criação de um novo padrão. No documento enviado pela Ecma está claramente explicitado isso: “OpenXML was designed from the start to be capable of faithfully representing the pre-existing corpus of word-processing documents, presentations, and spreadsheets that are encoded in binary formats defined by Microsoft Corporation. The standardization process consisted of mirroring in XML the capabilities required to represent the existing corpus, extending them, providing detailed documentation, and enabling interoperability. At the time of writing, more than 400 million users generate documents in the binary formats, with estimates exceeding 40 billion documents and billions more being created each year”.

Mas, o padrão apresentado não apresenta um mapeamento entre os formatos binários proprietários e o novo formato OpenXML. Sem este mapeamento, ninguém é capaz de escrever um software que garanta esta compatibilidade, a não ser a própria Microsoft que tem acesso aos fontes que descrevem os binários. Ora, se a compatibilidade não é garantida, para que apresentar este novo padrão? É muito mais racional então aglutinar esforços para evoluir o padrão já existente, o ODF.

Ter mais de um padrão sempre gera problemas. Um recente relatório feito pela PEGSCO (Pan-European eGovernment Services Committee), que pode ser lido em http://ec.europa.eu/idabc/servlets/Doc?id=26971 diz “Member State experts have identified the perceived compatibility problems between ISO 26300 (ODF) based products and the commercial applications that dominate the offices of today´s administrations as the main barrier for the use of document exchange and storage formats. The potential arrival of a second international standard for revisable documents may mean that administrations will be required to support multiple formats leading to more complexity and increased costs. Although filters, translators and plug-ins may theoretically enable interoperability, experience shows that multiple transformations of formats may lead to problems, especially as there is no complete mapping between all features of each of the different standards”.

Quem analisou as questões técnicas viu que existem inúmeros problemas na proposta atual do OpenXML, como inconsistências com padrões ISO já existentes (“paper sizes”, “dates and times”, “HTML colour names”, e outros) , inconsistências com recomendações da W3C (Uso do DrawingML ao invés do padrão SVG, como também não usa o padrão MathML). Várias seções da especificação fazem referência ao comportamento de uma aplicação sem definir a natureza deste comportamento. Por exemplo, “autoSpaceLikeWord95”. Como o Word95 é proprietário, torna difícil a outras empresas, que não a Microsoft, implementarem softwares baseados na especificação OpenXML.

E mais: não existe especificação para linguagem macro, embora o Office 2007 suporte macros VBA. Como VBA é uma linguagem proprietária, seu uso é restrito. Além disso, existem elementos dos formatos de arquivos Office 2007 que não estão documentados na proposta Ecma atual. O resultado é que existem grandes possibilidades de ocorrerem problemas de interoperabilidade.

Mesmo o uso de plug-ins não é tão simples assim. Demanda mais um componente de software a ser instalado e gerenciado (imaginem milhares de máquinas), bem como obriga a que os usuários envolvidos na troca de documentos mantenham plug-ins compatíveis entre si!

Portanto, temos uma decisão importante a tomar. Que deve ser tomada com consciência.

Bem, e quais são os cenários futuros? Um pouco de especulação…Supondo que a proposta Ecma não seja aprovada como padrão ISO, é muito provável que continue sendo mantida pela Microsoft. Se tornará um padrão “de facto”. Os softwares de escritório serão obrigados a suportar estes dois padrões, com os inevitáveis problemas de compatibilidade e interoperabilidade já citados. E pior, caso estes problemas se avolumem, pode-se ter uma reversão no processo de evolução para XML, com os usuários preferindo manter o formato binário, que acabará se perpetuando…

* Cezar Taurion é  gerente de Novas Tecnologias da IBM