As coisas se complicam para o OOXML

Bem, desculpem o hiato: as minhas novas atividades de serviço exigiram um tempo meu especial, onde precisei me focar mais nele e abandonei um pouco o blog.
Nesse meio tempo, ocorreu o Ballot Resolution Meeting (BRM) para a aprovação ou não do Office Open XML. Basicamente, esse é o momento onde todas as contradições (ou comentários) aplicados ao mesmo quando ele não foi aprovado, em uma tentativa de resolver os problemas e com isso aprovar o formato.
Antes que se pense que isso é mais um empurrão da nossa “amiga de Redmond”, na realidade isso é parte do processo de Fast track da ISO, portanto não há nada de errado nesse processo. Muito pelo contrário, ele é completamente válido na medida em que é parte de um processo já validado dentro de uma organização como a ISO.
Os problemas vão surgindo, porém, quando você entende o que está acontecendo por trás dos panos.
Como já comentei anteriormente nesse mesmo blog, existem uma série de problemas sobre como o formato está sendo publicado na ISO. Esse é inclusive o motivador do Ballot Resolution Meeting (BRM): estudar e chegar a um consenso sobre como serão corrigidos os problemas no mesmo. Mas como chegar a um consenso sendo que o formato possui mais de 6000 páginas de documentação técnica com coisas específicas para emular a formatação do Word 95 (?!) ou do Wordperfect (?!)?
Mas isso ainda não é o pior do que está acontecendo sobe o Ballot Resolution Meeting (BRM). Existem coisas ainda piores ocorrendo.
O Jomar, do Homembit e da ODF Alliance Brasil, é um dos representantes da ABNT no comitê JTC1 da ISO, responsável pelo OOXML (DIS 29000), sendo que os outros foram o Deivi Kuhn do SERPRO e o Fernando Gebara, da Microsoft, dois profissionais respeitados na área. Ele é uma fonte de referência para saber o que se passa nesse processo. Além dele, recomendo a leitura do blog do César Taurion, da IBM, também bastante respeitado, que vêm falando bastante do ODF e do OOXML. Eles foram para Genebra participar do BRM como representantes brasileiros. E as coisas começaram a aparecer, apesar da “lei de silêncio” envolvendo o BRM:
Comecemos pelo post do Jomar onde ele esclarece uma proposta do Brasil para facilitar a aceitação do OOXML, principalmente quanto à questão das famosas questões de retrocompatibilidade (lineWrapLikeWord6), que era a possibilidade de um mapeamento de formatos binários (como o .doc) para o OOXML (.docx).
Bem, vamos deixar que ele fale:

Afinal: O que fomos fazer em Genebra ? | void life(void)

Não posso contar os detalhes da reunião, mas posso contar uma conversa que tivemos (eu e mais um delegado brasileiro) com uma pessoa no início da pausa para o almoço de sexta feira. Vou divulgar esta conversa pois nosso interlocutor se identificou como sendo membro do ECMA, membro de uma delegação nacional presente no BRM mas não disse que estava falando em nome de ninguém (como é o protocolo lá), e por isso entendo que esta foi uma conversa que não está coberta pela escandalosa “Lei do Silêncio” imposta a todos nós.
Esta pessoa nos procurou dizendo que considera que não deveríamos apresentar nossa proposta que pedia o mapeamento, pois não havia tempo hábil na reunião (pouco mais de três horas) para escrevermos o documento. Nós dissemos que nossa proposta partia da premissa de que o ECMA já tinha este documento, pois, se justifica a necessidade do OOXML por causa do suporte ao binário e se afirma ainda que existem coisas que não podem ser traduzidas (deprecated), eles devem ter estudado aprofundadamente esta situação e no mínimo ter feito o mapeamento.
Eu nunca vi uma pessoa tão nervosa e envergonhada na minha vida… Ele disse que a Microsoft deve ter este mapeamento e se nós quisermos, podemos pedir à Microsoft mas não pedir ao ECMA. Disse que o ECMA só foi responsável por criar o novo schema XML e que não têm esta documentação.
Como nossa conversa não ia a lugar nenhum, eu lhe expliquei que o que iriamos propor era o resultado do trabalho de um comitê no Brasil e que infelizmente se ele não pudesse voltar ao tempo e vir ao Brasil contar esta história toda, que teríamos que insistir com nossa proposta.
Fiz questão de contar isso aqui, pois não deixaram o Brasil apresentar a proposta…

OK… Pode parecer correto o que a pessoa disse. Mas vejamos o que diz outro profissional envolvido, o Avi Alkalay, da IBM:

OOXML: Está rolando um barraco na ISO :: Avi Alkalay

Só pra lembrar qual é o propósito do OOXML, extraido (em livre tradução) de sua especificação:

O objetivo deste padrão [OOXML] é […] representar fielmente o corpo de documentos existentes […]

Os tais “documentos existentes” são no caso todos os documentos em formato binário legado do MS Office (.doc, ,ppt, .xls), algo fora do escopo do OOXML.
Se esse mapeamento não fizer parte da especificação OOXML, seu objetivo primordial é inválido. A especificação é inválida. E a delegação brasileira queria levantar essa bola: cadê o mapeamento ?

Sem um mapeamento, é praticamente impossível obter a total fidelidade no corpo de documentos existentes e transpor isso ao OOXML, mesmo recorrendo-se a engenharia reversa. Qualquer um que tenha aberto um arquivo .DOC no BrOffice.org ou exportado um documento do BrOffice.org para .DOC sabe disso. Sem esse mapeamento, o resultado prático é que características estranhas dos documentos, principalmente .DOC, não poderão ser representados adequadamente em um OOXML. E é justamente isso que questiona Rob Weir, que é parte da representação americana no OOXML:

An Antic Disposition: The Carolino Effect

The scope of OOXML, as amended by the BRM is stated as:

This International Standard defines a set of XML vocabularies for representing word-processing documents, spreadsheets and presentations. The goal of this standard is, on the one hand, to represent faithfully the existing corpus of word-processing documents, spreadsheets and presentations that have been produced by Microsoft Office applications (from Microsoft Office 97 to Microsoft Office 2008 inclusive). It also specifies requirements for Office Open XML consumers and producers , and on the other hand, to facilitate extensibility and interoperability by enabling implementations by multiple vendors and on multiple platforms.

Faithful representation of Microsoft Office 97-2008. I’ve learned it is rarely polite to ask a man what he means by “faithful”, but let me make an exception here. We have now the binary Office format specifications, not part of the standard, but posted by Microsoft. And we have OOXML specification. In what way does the OOXML “represent faithfully” the “existing corpus” of legacy documents?
Does OOXML tell you how to translate a binary document into OOXML? No. Does it tell you how to map the features of legacy documents in OOXML? No. Does it give an implementor any guidance whatsoever on how to “represent faithfully” legacy documents? No. So it is both odd and unsatisfactory that primary goal of the OOXML standard is so tenuously supported by its text.
Now, certainly, someone using the binary formats specifications, and using the OOXML specification, could string them together and attempt a translation, but the results will not be consistent or satisfactory. (…). Knowing the two endpoints is not the same as knowing how to correctly map between them. A faithful mapping requires knowledge not only of the two vocabularies, but also the interactions.

Uma tradução livre desse trecho é a seguinte:

O Escopo do OOXML, como foi corrigido no BRM é definido como:

Esse padrão internacional define um conjunto de vocabulários XML para a representação de documentos de processamento de texto, planilhas e apresentações eletrônicas. O objetivo desse padrão é, por um lado, representar fielmente a formatação existente de documentos de processamento de texto, planilhas e apresentações eletrônicas produzidas por aplicações do Microsoft Office (do Microsoft Office 97 ao Microsoft Office 2008, inclusive). Também especifica requisitos para consumidores e produtores de documentos Office Open XML e, por outro lado, facilita a extensibilidade e a interoperabilidade ao permitir implementações por vários desenvolvedores e em várias plataformas.

Representação fiel de documentos do Microsoft Office 97 ao 2008. Aprendi que raramente é polido perguntar a alguém o que ele quer dizer com “fiel”, mas aqui há uma exceção. Nós temos agora as especificações do formato dos arquivos binários do Office, não incluídos como parte do padrão, mas sim fornecidos pela Microsoft; e temos a especificação do OOXML. Como é que o OOXML “representar fielmente a formatação existente” dos documentos legados?
O OOXML nos diz como traduzir um documento binário em OOXML? Não. Diz como mapear as features dos documentos legados para OOXML? Não. Oferece um caminho para o desenvolvedor “representar fielmente”, seja lá o que queira isso dizer, os documentos legados? Não. Portanto é ao mesmo estranho e insatisfatório que o objetivo principal do OOXML seja tão tenazmente definido por esse texto.
Na verdade, alguém que queira tentar uma tradução usando as especificações dos formatos binários e do OOXML poderia amarrá-los e tentar seguir em frente, mas os resultados não serão consistentes ou satisfatórios. (…) Saber os pontos de chegada e partida não significa saber o caminho entre eles. Um mapeamento fiel exige não apenas o conhecimento das duas especificações, mas também das interações entre elas. (Grifo meu)

Perceba aqui o problema: não é possível saber como “representar fielmente” os documentos em questão. O máximo que um desenvolvedor pode fazer é “ir no chute”, mas “os resultados não serão consistentes ou satisfatórios“. Como disse, basta tentar abrir um arquivo do Word em qualquer outro editor e ver que isso é uma verdade. O resultado nunca é o mesmo. Mesmo quando o formato é conhecido, existem leves diferenças na implementação (quem nunca desconfigurou a formatação de um documento ao abrir ele na versão mais atual de um editor?). Problemas entre formatos é obviamente uma realidade.
E isso é apenas a ponta do Iceberg.
No dia que eu escrevo isso, o Avi Alkalay publicou em seu blog um post falando sobre uma das “features” que serão exigidas no OOXML. No caso, cito a fonte do mesmo, novamente o Rob Weir:

An Antic Disposition: A Leap Back

(…) in 1582 Pope Gregory XIII promulgated a new way of calculating leap years, saying that years divisible by 100 would be leap years only if they were also evenly divisible by 400. So, the year 1600 and 2000 were leap years, but 1700, 1800 and 1900 were not leap years. This Gregorian calendar was initial adopted by Catholic nations like Spain, Italy, France, etc. Protestant nations pretty much had adopted it by 1752, and Orthodox countries later, Russia after their 1918 revolution and Greece in 1923.

traduzindo (desculpem, o post vai se tornar longo, mas tenho a prática de citar a fonte “as is” e as traduzir a posteriori quando isso pode ser relevante):

(…) em 1582 o Papa Gregório XIII promulgou uma nova forma de calcular-se anos bissextos, determinando que os anos divisíveis por 100 só seriam bissextos se fossem divisíveis também por 400. Portanto, 1600 e 2000 foram anos bissextos, mas 1700, 1800 e 1900 não. Esse calendário gregoriano foi inicialmente adotado em nações católicas como a Espanha, Itália, França, etc… As nações protestantes o adotaram em 1752, e as nações ortodoxas mais tarde: a Rússia após a revolução de 1918 e a Grécia em 1923.

OK… Um pouco de história? Qual é o problema?
O problema é a seguinte imagem:

O que foi feito aqui?
Quando se formata uma casa do Excel como data, ela conta a partir de 01/01/1900. Ou seja, se quero representar o dia de hoje, eu somo o número de dias que passou entre 01/01/1900 e hoje (um princípio básico da computação que é adotado em diversos formatos, com leves diferenças entre unidades e “ponto zero” adotados). Isso facilita a computação para fórmulas, principalmente envolvendo datas. Pensando assim, e lembrando o que foi dito anteriormento, o Avi definiu que o valor da data como a primeira data do escopo (01/01/1900) + os trinta dias seguintes (ou seja, levaria até 31/01/1900) e somou mais 29 dias em seguida. O resultado seria 29 dias após o dia 31/01/1900. Como não é bissexto (como o Rob explicou anteriormente), o resultado adequado seria 01/03/1900. A imagem comprova que o resultado foi 29/02/1900 (também conhecido como dia de São Nunca).
Agora, você pergunta: “Qual é o problema?”
Lembra a questão de “‘representar fielmente a formatação existente‘ dos documentos legados”? Bem, isso quer dizer representar inclusive os bugs!!! Pode-se alegar que é um bug inconveniente, mas não é, e mesmo que fosse isso não é desculpa. E a questão é a seguinte: se um erro bobo como esse passa (lembrando que esses documentos legados podem estar por aí em 2100, que também não é um ano bissexto), imagina detalhes mais complexos?
E as coisas não acabaram:
As pessoas que estão acompanhando esse processo do OOXML sabem que a Microsoft prometeu liberar totalmente de royalties o OOXML, atraves do que ela chama de “Microsoft Open Specification Promise” (OSP). Basicamente, ela afirma por meio disso que está não irá processar ninguém por usar ou desenvolver em cima dessas patentes. Porém, o pessoal do Software Freedom Law Center, que estuda licenças de software para analisar sua compatibilidade com o Software Livre, procurou analisar a OSP e verificar sua compatibilidade com as licenças livres, como a GPL, a Artistic (do Apache) ou a CDDL (Sun/OpenOffice.org). O resultado é:

Microsoft’s Open Specification Promise: No Assurance for GPL – Software Freedom Law Center

(…), we publicly conclude that the OSP provides no assurance to GPL developers and that it is unsafe to rely upon the OSP for any free software implementation, whether under the GPL or another free software license.

traduzindo:

(…), concluímos publicamente que a OSP não oferece nenhuma segurança para desenvolvedores que usem a GPL e que não é seguro se basear na OSP para qualquer implementação livre [do OOXML], seja segundo a GPL ou segundo qualquer outra licença de software livre. (grifos meus)

Você pode se perguntar: “o que mais esses open-xiitas querem? Não basta as especificações da ECMA?“
Não basta! Tanto não basta que a própria ISO não aceita padrões que possuam patentes, a não ser que essas patentes estejam para acesso a qualquer um sem cobrança de royalties. A pergunta então pode ser: “qual é o problema?” Bem, vamos aos fatos:

Microsoft’s Open Specification Promise: No Assurance for GPL – Software Freedom Law Center

Microsoft makes its promise “irrevocably,” but upon careful reading of the entire OSP, this promise is weakened considerably in the definition of Covered Specifications. In that provision, Microsoft clarifies that:

New versions of previously covered specifications will be separately considered for addition to the list.

Because of this narrow definition of the covered specifications, no future versions of any of the specifications are guaranteed to be covered under the OSP. Each new version is subject to Microsoft’s ongoing discretion on a case by case basis. In other words, every time a specification changes, Microsoft can effectively revoke the OSP as it had applied to previous versions of that same specification. Microsoft states that it will commit to renewal of the promise for future versions of specifications subject to standardizing activity “to the extent that Microsoft is participating in those efforts,” which means that Microsoft reserves the right to cancel the promise with respect even to standardized specifications, by merely withdrawing from the relevant standard-setting workgroup or activity. While technically an irrevocable promise, in practice the OSP is good only for today.

tradução:

A Microsoft torna sua promessa “irrevogável”, mas se lemos a OSP completamente, percebemos que essa promessa é enfraquecida sensivelmente pela definição de Especificações Cobertas pela mesma. Nessa provisão, a Microsoft deixa claro que:

Novas versões de especificações anteriormente cobertas pela mesma poderão ser consideradas separadamente para serem adicionadas à lista [de especificações].

Devido à essa definição ampla de Especificações Cobertas, nenhuma versão futura de nenhuma dessas especificações estarão seguramente cobertas pela OSP. Cada nova versão é alvo da decisão da Microsoft em uma situação caso-a-caso. Em outras palavras, cada vez que uma especificação mudar, a Microsoft pode efetivamente revogar a OSP do modo como ela se aplica às versões anteriores da mesma especificação. A Microsoft determinou que irá renovar a promessa para futuras versões das especificações sujeitas à atividade de padronização “enquanto a Microsoft participar desses esforços”, o que na prática quer dizer que a Microsoft se reserva no direito de cancelar a promessa até mesmo para as especificações que passaram por padronização, simplesmente abandonando os grupos de trabalho ou atividades relevantes. Embora tecnicamente ela seja irrevogável, na prática a OSP só funcionaria de imediato. (grifos meus)

Atentemos aos grifos: por eles, compreendemos que, ao bel-prazer, a Microsoft pode, mesmo após aprovado o padrão, revogar sua OSP e sair processando todo mundo, criando uma patente submarina potencial, uma vez que, pelos termos citados, ao revogar sua OSP, todo usuário potencial da OSP estaria infringindo direitos de patente e, com isso, sendo alvo potencial de processos. Sem sombra de dúvidas, uma forma capciosa de implementar minas-terrestres de Propriedade Intelectual contra os usuários.
Mas não acabou: você não poderia incorporar código de implementações do OOXML em qualquer coisa que não envolva implementação OOXML. Vejamos o que a SFLC tem a dizer sobre isso:

Microsoft’s Open Specification Promise: No Assurance for GPL – Software Freedom Law Center

(…) any code written in reliance on the OSP is covered by the promise only so long as it is not copied into a program that does something other than implement the specification. This is true even if the code has not otherwise been modified, and code that conforms to the specification cannot be modified if the resulting modified code does not conform.

Traduzindo:

(…) qualquer código que tenha sido escrito em observância à OSP estará coberto pela promessa enquanto ele não for incorporado a qualquer programa que faça qualquer outra coisa que imp,ementar a especificação. Isso é verdadeiro mesmo se o código não for modificado, e o código que estiver seguindo a especificação não pode ser modificado se o código modificado resultante não estiver em observância.

O que isso quer dizer? Basicamente, não temos um uso livre para incorporação em qualquer situação, o que é definido pela Liberdade 2 da Free Software Foundation e que é parte do princípio por trás da GPL. Embora possa-se alegar que uma biblioteca poderia rodar segundo LGPL e assim trabalhar em conjunto com software GPL, ainda assim não pode-se afirmar que esse seja um uso livre ou mesmo seguro do mesmo.
O pior é que, segundo a Microsoft, a culpa é da GPL:
Microsoft’s Open Specification Promise: No Assurance for GPL – Software Freedom Law Center

In its FAQ regarding the OSP, Microsoft confuses the issue further, saying:

Because the General Public License (GPL) is not universally interpreted the same way by everyone, we can’t give anyone a legal opinion about how our language relates to the GPL or other OSS licenses, but based on feedback from the open source community we believe that a broad audience of developers can implement the specification(s).

While not attempting to clarify the text of the OSP to indicate compatibility with the GPL or provide a safe harbor through its guidance materials, Microsoft wrongly blames the free software legal community for Microsoft’s failure to present a promise that satisfies the requirements of the GPL. It is true that a broad audience of developers could implement the specifications, but they would be unable to be certain that implementations based on the latest versions of the specifications would be safe from attack. They would also be unable to distribute their code for any type of use, as is integral to the GPL and to all free software.

traduzindo:

Em sua FAQ relacionada à OSP, a Microsoft distorce essa questão [do licienciamento segundo a GPL] dizendo que:

Uma vez que a Licença Pública Geral (GPL) não é universalmente interpretada da mesma forma por todos, não podemos dar uma opinião legal sobre como nosso texto se relaciona à GPL e a outras licenças de software livre ou aberto, mas baseado no feedback que recebemos da comunidade do software aberto acreditamos que uma ampla gama de desenvolvedores pode implementar a(s) especificação(ões).

Além de não tornar claro o texto da OSP para indicar compatibilidade com a GPL ou oferecer um porto seguro por meio de eus materiais, a Microsoft erroneamente culpa a comunidade jurídica relacionada ao software livre por sua incapacidade de oferecer uma promessa que satisfaça as condições da GPL. É verdade que uma ampla gama de desenvolvedores poderá implementar as especificações [segundo a OSP], mas eles não terão certeza de que implementações baseadas nas versões mais recentes estarão seguras contra litígios. Eles também não terão garantias de que poderão distribuir tais códigos para serem usados como necessário, o que é uma parte fundamental da GPL e de qualquer software livre. (Grifos meus)

Perceba que citei anteriormente a possibilidade de adotar-se a LGPL. O problema é que pela primeira questão levantada (a possibilidade de revogação da OSP), não há garantias de que, mesmo sob LGPL, o software continue legalmente sendo aceito, devido às patentes.
Pretendo comentar mais sobre essa questão, uma vez que em alguns dias haverá a decisão final sobre a padronização do OOXML. Mas é importante ficarmos com a orelha em pé: não sabe-se o que pode acontecer.