O caso contra OOXML na ISO
Neste informe se discute porque o formato ISO DIS 29500, “Office Open XML”
(OOXML), não cumpre com os critérios definidos pela ISO para poder converter-se em
uma norma internacional. Este informe analisa uma reduzida seleção das centenas de
impedimentos sérios e concretos que durante nossos estudos temos encontrado e
documentado nas mais de 6000 páginas de especificação do OOXML. Por favor, solicitenos a lista completa se for de seu interesse.
1. Critérios para a avaliação de padrões
O que é um padrão? Existem várias definições relevantes. Esta é a oficial da ISO:
“[Um] documento, estabelecido por consenso e aprovado por um organismo
reconhecido que estabeleça, para efeitos de um uso comum e repetitivo, normas,
diretrizes ou pautas destinadas a atividades ou seus resultados, cujo objetivo seja
lograr um nível ótimo de ordenamento em um contexto determinado.
NOTA. As normas devem basear-se em resultados consolidados da ciência, da
tecnologia e da experiência, e seu objetivo é a promoção do benefício ótimo para a
comunidade.”1
Segundo o Instituto Britânico de Padrões (BSI):
“... uma norma é uma forma acordada e reprodutível de realizar algo. É um
documento publicado que contém as especificações técnicas e outros critérios
precisos desenhados para utilizar-se de maneira consistente como regra, pauta ou
definição. As normas ajudam a simplificar a vida e aumentar a confiabilidade e
eficácia de numerosos bens e serviços que utilizamos comumente. Pretendem ser
parâmetros de excelência, ou seja, um compendio de boas e melhores práticas, e não
de práticas gerais. As normas surgem a partir da união da experiência e da
idoneidade de todas as partes interessadas, tais como os produtores, vendedores,
compradores, usuários e reguladores de um material, produto, processo ou serviço
particular”.2
Segundo as diretivas do Comitê Técnico Conjunto N.º 1 (JTC1) de ISO/IEC:
“Um dos propósitos da normalização da tecnologia da informação é assegurar que
os produtos disponíveis no mercado possuam características de interoperabilidade,
capacidade de transferência e de adaptação cultural e lingüística. Por tanto, as
1
Guía ISO/IEC 2:2004, definición 3.2. Varios organismos nacionales de normalización han adoptado esta
definición de ISO, por ejemplo, el Instituto Alemán de Normalización (DIN).
2
http://www.bsi-global.com/en/Standards-and-Publications/About-standards/What-is-a-standard/
normas desenvolvidas deverão refletir os requisitos com as seguintes características
estratégicas comuns:
interoperabilidade,
capacidade de transferência,
capacidade de adaptação cultural e lingüística”.3
Destas e outras definições nacionais surgem temas comuns acerca do que as normas
deveriam obter:
1.
Definem um critério comum e preciso para realizar algo de maneira reprodutível.
2.
Proporcionam um nível ótimo de ordem em um contexto dado, pretendem ser
parâmetros de la excelência ao brindar os resultados consolidados da ciência, la tecnologia
e da experiência, em outras palavras, é um compendio de boas e melhores práticas, e não de
práticas gerais.
3.
Fomentam a interoperabilidade e a capacidade de transferência.
4.
Se adaptam as diferentes culturas e idiomas.
Este informe avalia o formato DIS 29500 “Office Open XML” (OOXML) mediante o
contraste com cada uno destes critérios. Se expõem alguns exemplos específicos dos
problemas da especificação OOXML, mas leva em conta que eles representam somente
uma pequena proporção de uma grande lista de centenas de exemplos. A quantidade total de
problemas sérios que tem o OOXML demonstar sua imaturidade como especificação e falta
de aptidão para ser aprovado pelo modo rápido (fast-track) como uma norma ISO.
2. Preciso, reprodutível, geral
Estos criterios hablan de la necesidad de que la norma proporcione una descripción
detallada y por escrito que permita la práctica generalizada de la tecnología en cuestión.
Em primeiro lugar, a parte de WordProcessingML de OOXML enumera uma grande
quantidade de “Configurações de compatibilidade”4 que proporcionam a Microsoft a
capacidad de armazenar informação relacionada com determinados funcionamentos a partir
de
aplicações
existentes.
Estas
configurações
têm
nomes
como:
“footnoteLayoutLikeWW8”, “autoSpaceLikeWord95” e “useWord97LineBreakRules.”5
Entretanto, a especificação OOXML somente enumera estas configurações. Não
proporciona uma definição delas. Somente a Microsoft conhece o significado destas
configurações, já que não esclarece a definição precisa das mesmas. Em troca, OOXML
remete ao leitor para as aplicações de softwares existentes:
3
Directivas del Comité Técnico Conjunto N.º 1, 5.ta edición, versión 3.0, sección 1.2
Parte 4, sección 2.15.3.9
5
Otros ejemplos incluyen: lineWrapLikeWord6, mwSmallCaps, shapeLayoutLikeWW8,
supressTopSpacingWP, truncateFontHeightsLikeWP6, useWord2002TableStyleRules, wpJustification y
wpSpaceWidth.
4
“Para reproduzir fielmente este comportamento, as aplicações devem imitar o
comportamento da dita aplicação, que incluí muitos funcionamentos possíveis e não
podem ser descritos fielmente na seção desta norma Office Open XML. Se é desejado
compatibilizar as aplicações com este comportamento, deve-se utilizar e duplicar o
resultado das ditas aplicações”.
Esta passagem reflete claramente a falta de precisão e certamente não facilita a prática
repetível ou generalizada destas funções. Uma aplicação que queira implementar OOXML,
ao ler aquele trecho do presente documento que utilize estes atributos, não será capaz de
interpreta-los corretamente nem de representar a página de maneira fiel e precisa. Além
disso, devido ao fato destes atributos aparecerem como uma mera enumeração sem
definição, a possibilidade de por em prática o benefício de ser “completamente compatível
com os grandes investimentos existentes nos documentos de Microsoft Office”6 (o objetivo
do OOXML segundo seus criadores) fica, consequentemente, reservado somente para a
Microsoft. O padrão OOXML não facilita a prática repetível ou generalizada do benefício.
Em segundo lugar, a parte de WordProcessingML de OOXML enumera uma grande
quantidade de estilos de listas que representam diversos sistemas de escrita, idioma e
convenções comerciais.7 Estes denominam-se com nomes como “chicago”,
“ideographDigital”, “ideographLegalTraditional”, “koreanDigital2” e “koreanLegal”. Estes
são meras etiquetas e, novamente, não são definidos de maneira precisa. Se é claro para os
futuros implementadores da especificação OOXML que existe algo denominado “Korean
Legal Numbering”, não é claro o seu significado, assim não será possível coloca-lo em uma
aplicação.
Por exemplo, um futuro implementador de OOXML na Coréia ficaria perplexo diante de
um estilo de numeração que somente afirma: “......a sequência deverá consistir em
caracteres definidos segundo o Manual de estilo de Chicago” ssem especificar a edição do
manual (existem 15 edições do Manual de estilo de Chicago) ou uma página de referência.
A especificação OOXML não proporciona de nenhuma maneira o uso repetível e
generalizado destas funções.
Terceiro, a parte de The SpreadsheetML de OOXML descreve um atributo de
“securityDescriptor” que, de acordo com a especificação:8
“…define a quantidade de usuários que podem editar este campo sem ter que inserir
uma senha para acessar o campo. Ao suprimir este atributo, se suprimirão todas as
permissões outorgadas ou negadas aos usuários deste campo”.
Esta é uma característica importante relacionada com a segurança que diz que o usuário
poderá editar um campo em uma planilha de cálculo sem necessidade de uma senha. Um
futuro programador que implementar esta característica necessitaria saber como se
representam estas contas de usuário no documento. Estão delimitadas por vírgulas? Estão
delimitadas por ponto e vírgula? Estão delimitadas por espaços? OOXML não proporciona
6
Parte 1, Introducción
Parte 4, sección 2.18.66
8
Parte 4, sección 3.3.1.69
7
estes detalhes (ainda que dê a entender que permite mais de um nome). Ademais, não existe
um conceito universal de identidade digital. Todos contamos com múltiplas contas de
usuário para o correio eletrônico, para bases de dados, para o acesso ao computador, para
registros de domínio, para protocolos de acesso a diretórios (LDAP), etc. A qual senha o
protocolo se refere neste caso? Esta função precisa de uma definição apropriada que
permita a interoperabilidade, que, por fim, é o que gerará o uso reprodutível e generalizado.
Em resumo, muitas áreas do OOXML não estão definidas ou estão parcialmente definidas.
Apesar da especificação proporcionar um marco excelente para que Microsoft represente
ali seus próprios documentos, esta capacidade não se traduz na possibilidade de acesso
eqüitativo para que outros obtenham estes mesmos benefícios. A pergunta que se deve
formular é: “OOXML define o formato de um documento de maneira suficientemente
precisa para permitir a prática repetível e generalizada dos benefícios pretendidos?” Os três
exemplos anteriores, junto com muitos outros, demonstram que OOXML não satisfaz o
critério exposto. Sua falta de maturidade como norma se reflete também na falta de
aplicações que implementem toda sua funcionalidade em uma breve revisão técnica prévia.
Estes fatores o tornam inapropriado para que se possa analisado pela via rápida (fast-track),
suas gritantes deficiências não permitem que seja certificado como uma norma
internacional.
3. Parâmetro de excelência, melhores práticas consolidadas
Uma norma ISO não devería ser somente o registro minucioso e detalhado das
características operativas de um produto particular de uma empresa, sem se importar com
quanto tão dominante seja a empresa em um campo determinado. Das definições citadas
anteriormente, proporcionadas pela ISO e outros, uma norma internacional deveria
representar os “resultados consolidados da ciência, tecnologia e da indústria”. Uma norma
deveria representar os “parâmetros de la excelência”. Em outras palavras, deveria fazer
mais do que somente mostrar a forma que um único provedor realiza uma determinada
tarefa. Deveria tentar proporcionar um “compendio de boas e melhores práticas” sobre a
base de consenso e da opinião de especialistas. Deveria proporcionar conhecimentos sobre
as melhores práticas para possibilitar a prática reprodutível e generalizada de uma
tecnologia determinada.
A indústria registra suas melhores práticas através da normalização. O corpo existente de
padrões de documentos e marcações representam um compendio das melhores práticas que
se tenham revisado, aprovado e implementado. O trabalho do Consórcio Word Wide Web
(W3C)9 adquiriu especial relevância para os documentos de formato XML, já que mantém
o padrão básico XML e também outros padrões relacionados como XHTML, CSS2, XSL,
XPath, XForms, SVG, MathML y SOAP, os padrões que representam a estrutura principal
de XML e tecnologias afins.
Todavia, OOXML incorpora pouco das melhores práticas consolidadas da indústria. E
ainda pior, pedem que os potenciais implementadores de OOXML utilizem formatos
9
http://www.w3.org
obsoletos que são propriedade exclusiva da Microsoft, inclusive quando existem normas
muito melhores e mais relevantes disponíveis no Consórcio W3C.
Por exemplo, a Microsoft desenvolveu a linguagem de marcação de vetores (VML) e a
propôs ao Consórcio W3C. Um comitê técnico a avaliou e a reprovou em 1998. Em seu
lugar, a indústria optou por apoiar a linguagem para gráficos vetoriais escaláveis (SVG) que
posteriormente o Consórcio W3C aprovou como norma e a adotou amplamente. SVG tem
sido o padrão para os gráficos vetoriais XML durante quase uma década. Mas OOXML
utiliza VML sob direitos de propriedade, porque Microsoft integrou seu VML com direitos
de propriedade exclusivos em sua aplicação Internet Explorer e Office 2000, ao invés de
adotar a norma SVG.
Além disso, a própria Microsoft reconheceu que VML não é a norma adequada para
representar gráficos vetoriais:
“O formato VML é um formato obsoleto introduzido originalmente com Office 2000.
Foi incluído e definido exclusivamente por razão de compatibilidade com produtos
anteriores. O formato DrawingML é um formato mais recente e completo, criado
com o objetivo de substituir progressivamente todos os usos de VML em formatos
Office Open XML. VML deve ser considerado como um formato não aprovado que
foi incluído no Office Open XML exclusivamente pela razão de compatibilidade com
formatos obsoletos e se recomenda que as aplicaciones novas que precisem um
formato de arquivo para gráficos utilizem preferencialmente DrawingML”.10
Em lugar de utilizar o padrão vigente SVG, Microsoft OOXML incluiu dois tipos de
linguagens de marcação diferentes para gráficos vetoriais, uma que o Consórcio W3C
rejeitou, em 1998, e outro que Microsoft desenvolveu em solitário por sua conta e risco. A
quantidade de esforço extra que isto origina para todos aqueles que desejem implementar
OOXML é imensa. Os implementadores deberão compatibilizar dois tipos diferentes de
marcações para a mesma função (sem que nenhuma delas seja o padrão) e ainda que isto
não assegure nenhum benefício adicional aos usuários. Somente a Microsoft será
beneficiada, já que essa empresa conta desde muito tempo com o suporte para VML no
Office.
Ademais, ao contrário do que no caso dos textos, é pouco provável que os conversores de
formato de documentos possam trabalhar perfeitamente os gráficos vetoriais. Por tanto, a
proliferação de normas redundantes para gráficos vetoriais, dois dos quais estão inclusos no
OOXML, ocasionarão importantes problemas de fidelidade na hora da conversão entre
formatos.
Isto é verdadeiramente um parâmetro de excelência? Certamente equivalerá ao fomento das
melhores práticas? Muito ao contrário: foram adicionadas 600 páginas de requisitos para
VML na especificação do OOXML que não acrescentam nenhum valor a ninguém, exceto à
Microsoft, que de fato resultará em mais trabalho e complicações para aqueles que querem
implementar o OOXML.
10
Parte 4, sección 6.1
Como segundo exemplo, temos o modo como se definem as datas nas folhas de cálculo,
onde se estabelece os seguintes requisitos:
“Por razão de compatibilidade com formatos antigos, uma aplicação que utilize o
sistema de base de dados com data de 1900 deverá considerar o 1900 como ano
bisexto… Como consequência disto, para as datas entre 1 de janeiro e 28 de
fevereiro, o DIA DE SEMANA mostrará um número imediatamente anterior ao dia
correto, então, a data (inexistente) de 29 de fevereiro pertence ao dia da semana que
segue imediatamente ao da data de 28 de fevereiro e que precede imediatamente ao
dia 1 de março.”11
Em outras palavras, o calendário gregoriano, esse calendário em que se baseia todo o
comércio, a ciência e os governos de todo o mundo, é deixado de lado devido as “razões de
compatibilidade”. O resultado é que todo futuro implementador de OOXML ficará
obrigado a fazer com que sua aplicação proporcione aos usuários respostas errôneas a
simples perguntas como “em que dia da semana caiu o 1 de fevereiro de 1900?”. Isso é
necessário no chamado padrão OOXML, exatamente para interpretar corretamente os
documentos que foram criados com ferramentas da Microsoft. Isto irá ocasionar um grande
problema na hora de executar algo tão habitual como inter-cambiar dados entre folhas de
cálculo e bases de dados relacionais através do padrão SQL. Um padrão deve no mínimo
exigir que seja utilizado o calendário gregoriano.12
Como terceiro exemplo, note que o OOXML define um novo tipo de cadeia de caracteres
denominado “Basic String” como “uma variante do tipo de cadeia de caracteres binária
básica”.13 Uma das propriedades desta nova cadeia de caracteres é a que permite a
codificação especial de caracteres que não sejam XML (caracteres de controle). Todavia, a
presença de caracteres que não sejam XML em um documento XML impedem a
interoperabilidade entre ferramentas XML e ferramentas baseadas neste formato. A
Atividade de internacionalização do Consórcio W3C confirma esta interpretação afirmando
que:
“Os códigos de controle devem ser substituídos pela marcação apropriada. Dado que
XML proporciona um modo padronizado de codificar dados estruturados, ao
representar códigos de controle que não se ajustem as marcações teríamos anuladas
as vantagens reais da utilização de XML. Nunca se recomenda a utilização de
códigos de controle em HTML e XHTML, já que estas linguagens de marcação
servem para representar textos e não dados”.14
Quarto, em diferentes pontos15 OOXML utiliza “máscaras de bits” para codificar valores
booleanos (que representam a lógica binária de verdadeiro/falso) em um único tipo de dado
inteiro. Apesar disto ter sido muito comum há 20 anos quando se programava em C em
condições de memória restrita, se considera um estilo muito deficiente para o ambiente
XML. Dificulta o processamento mediante ferramentas padrão XML como XSLT, já que
11
Parte 4, sección 3.17.4.1
Lenguaje de bases de datos SQL, parte 2: Fundamentación (ISO/IEC 9075-2:1999), sección 4.7.3
13
Parte 4, sección 7.4.2.4
14
http://www.w3.org/International/questions/qa-controls
15
Por ejemplo, parte 4, sección 2.3.1.6; parte 4, sección 2.4.51; parte 4, sección 2.4.52; parte 4, sección 2.4.7,
etc.
12
estas ferramentas carecem de operações em nível de bits que sejam necessárias para
processar de maneira eficiente esses dados em nível de bits.
Quinto, OOXML não somente deixa de proporcionar a consolidação das melhores práticas
da ciência, da indústria e do cotidiano, bem como tão pouco proporciona a consolidação das
melhores práticas da própria Microsoft. O OOXML recomenda que os ajustes de impressão
(quantidade de páginas para imprimir, quais páginas serão impressas, orientações sobre as
mesmas, qualidade de impressão, etc.) se armazenem com um formato binário específico da
sua plataforma. Por exemplo, para Windows, a orientação é armazenar no que se denomina
estrutura “DEVMODE”16 Ao fazê-lo dessa maneira, os ajustes de impressão se tornariam
dependentes de cada plataforma, o que impede a interoperabilidade. O que mais chama a
atenção na nova especificação é que a chamada “XML Paper Specification” (XPS) da
Microsoft oferece um elemento “PrintTicket” sobre o qual a Microsoft afirma:
“A tecnologia ‘PrintTicket’ é a sucessora da atual estrutura DEVMODE. Se trata de
um documento sobre a base de uma linguagem de marcação extensível (XML) que
especifica e mantém a informação do formato de trabalho e da configuração de
trabalho de impressão… En relação ao atual subsistema de impressão, a tecnologia
“PrintTicket” oferece a todos os componentes e clientes do subsistema de impressão
o acesso transparente a informação armazenada atualmente nas partes públicas e
privadas da estrutura DEVMODE, mediante a utilização de um formato XML bem
definido.”17
Por que o OOXML adota ajustes de impressão de menor qualidade, binários, difíceis de
transportar e dependentes de una plataforma e aplicação concretas, indo contra a prática
recomendada pela própria Microsoft que é mudar para um “formato XML bem definido”?
Como sexto exemplo, note que o OOXML define vários algoritmos criptográficos 18 que não
são padronizados. Em lugar de utilizar um algoritmo ISO/IEC 10118-3:2004, ou um que
esteja aprovado pelo Instituto Nacional de Padrões e Tecnologia (NIST) dos EUA, ou esteja
em uma lista de algoritmos aprovados segundo FIPS-180 (Padrões Federais de
Processamento da Informação, dos EUA)19, (existem vários que estão em ambas listas,
como SHA-256), o OOXML especifica um algoritmo hash obsoleto. Supomos que seja
utilizado em versões anteriores do Microsoft Office. Isto equivale a oferecer o
conhecimento consolidado sobre as melhores práticas da ciência, da industria e do
cotidiano? Pelo contrário, a Microsoft nem sequer recomenda a utilização destes
algoritmos. Em troca, proporciona sistemas de proteção do tipo DRM (gestão de direitos
digitais) no Office 2007 como extensões não documentadas do OOXML. Como este DRM
não está documentado, nenhum outro provedor poderá utilizar essas funções livremente. Os
documentos codificados no Office 2007 não podem ser lidos em nenhuma outra aplicação.
Pelo contrário, os futuros implementadores do OOXML somente contam com uma
compatibilidade de segurança obsoleta, que nem sequer cumpre com o padrão estabelecido
no FIPS-180. Novamente, a Microsoft reserva as melhores práticas para si e impede a
especificação do OOXML conte com uma segurança mais sólida.
16
Parte 1, sección 15.2.14
http://msdn2.microsoft.com/en-us/library/ms715246.aspx
18
Por ejemplo, en la parte 4, sección 2.15.1.28
19
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf
17
Em resumo, o OOXML é simplesmente uma porta aberta que nos conduz a formatos
binários de documentos exclusivos de um único fornecedor. O fato de evitar utilizar as
normas internacionais vigentes relevantes para o caso, assim como o uso inconsistente das
tecnologias de propriedade exclusiva da Microsoft, põe em evidência que OOXML não
representa os resultados consolidados da ciência, da indústria, nem da experiência. Não
reflete um parâmetro de excelência. Apesar de que pode prover-nos com uma técnica para
ler dados codificados em um formato de um único fornecedor determinado, isso o
posiciona, no melhor dos casos, somente como uma especificação técnica. Uma vez que
não representa as melhores práticas consolidadas na indústria, característica essencial de
uma norma ISO, a especificação OOXML não deve ser aprovada como norma
internacional.
4. Interoperabilidad y capacidad de transferencia
La capacidad de transferencia e interoperabilidad son dos de las “Características
estratégicas comunes” 20 del Comité Técnico Conjunto N.º 1 y son requisitos de todas las
normas aprobadas por el Comité Técnico Conjunto N.º 1. En el campo de los estándares
para el formato de documentos, la pregunta que hay que formularse es si la especificación
OOXML propuesta puede ser implementada completamente por parte de múltiples
aplicaciones distintas en diversos sistemas operativos. O bien, por contra, si se ha escrito de
manera que sólo sirva para el beneficio exclusivo de la aplicación de un solo proveedor.
Primeramente, un área importante de interoperabilidad es el intercambio de datos entre
hojas de cálculo y bases de datos relacionales. Muchos procesos comerciales se definen
sobre la base de esta capacidad, que la mayoría de los proveedores de hojas de cálculo han
apoyado durante más de una década. Sin embargo, OOXML no cuenta con la capacidad de
representar fechas previas al año 1900, mientras que las bases de datos modernas pueden
representar fechas de años anteriores. La base de datos DB2 de IBM, por ejemplo, puede
representar fechas del año 1. Oracle admite fechas del año 4712 a. C. La especificación
OOXML no debería evitar que los futuros implementadores utilicen fechas tan antiguas
como lo deseen. Un proveedor de aplicaciones deseará naturalmente equiparar su
compatibilidad de fechas para hojas de cálculo con las capacidades equivalentes de sus
bases de datos. ¿Por qué se restringe OOXML a las serias limitaciones de Microsoft Excel?
Esto daña seriamente la interoperabilidad entre las hojas de cálculo y las bases de datos.
Segundo, OOXML define un tipo ST_CF21, que registra los formatos del portapapeles
permitidos que pueden utilizarse con un objeto gráfico. Los valores permitidos de este tipo,
EMF, WMF, etc., pertenecen a los formatos de Windows. No se han hecho concesiones
para el uso en otros sistemas operativos. Por ejemplo, en Linux las imágenes generalmente
se copian en el portapapeles en un formato estándar abierto como PNG. Sin embargo, si un
proveedor codifica “PNG” en un registro de un documento de este tipo, el documento se
invalidará y ni el documento ni la aplicación cumplirán con la especificación OOXML.
20
21
Directivas del Comité Técnico Conjunto N.º 1, 5.ta edición, versión 3.0, sección 1.2
Parte 4, sección 6.4.3.1
Tercero, en SpreadsheetML, para definir las contraseñas con algoritmo hash en la
especificación de OOXML se aportan 5 páginas de código fuente en lenguaje C22, código
extraído probablemente de Excel. Sin embargo, las manipulaciones de bits de este código
son esencialmente dependientes de una determinada arquitectura de computadora y van a
proporcionar diferentes resultados dependiendo de cada arquitectura de procesador. Así, un
documento creado en una computadora tal vez no pueda leerse en otra distinta. OOXML no
ha proporcionado ninguna definición de alto nivel e independiente de plataforma para esta
función.
Cuarto, el elemento “optimizeForBrowser” de WordProcessingML23 se ha definido de tal
forma que ignora la existencia de otros navegadores presentes y futuros distintos a
Microsoft Internet Explorer. ¿Qué sucede con Firefox? ¿Qué sucede con Safari? ¿Qué
hacemos con Opera? Ninguno de éstos se puede establecer como navegador para el que se
optimiza el código del documento. Esta sección en OOXML define además que “todas las
configuraciones que no sean compatibles con el navegador web objetivo se inhabiliten”.
Pero, ¿qué sucede si deseo que mi aplicación genere resultados compatibles con los
estándares vigentes? En otras palabras, la combinación: sí a PNG, no a VML, sí a MathML
y SVG. Un implementador potencial no puede especificar esta combinación “estándar”
debido a la manera en la que OOXML fue diseñado: “sólo para Microsoft Internet
Explorer”.
Sexto, la función “Propiedades de sincronización de diapositivas” de DrawingML24 ofrece
la posibilidad de que en una presentación se sincronice el contenido de una diapositiva con
diapositivas almacenadas centralmente en un servidor. Ésta es una funcionalidad de
Microsoft PowerPoint y Microsoft SharePoint. Sin embargo, la descripción de esta función
en OOXML carece de suficientes detalles. ¿Qué es el protocolo de comunicación? ¿Cuál es
el modelo de datos? Si bien existen normas para describir un protocolo cliente-servidor de
este tipo, es decir, las diversas normas de servicios web, OOXML no proporciona
información al respecto. Se impiden las implementaciones interoperables independientes de
esta función y la única implementación que existe se relacionará con Microsoft SharePoint
en exclusiva.
En resumen, allá donde OOXML hace referencia a otras tecnologías, por lo general, lo hace
de manera que ata exclusivamente a tecnologías que ya son compatibles con Microsoft
Office. En algunos casos, se realizan esfuerzos ímprobos para incorporar en OOXML otras
especificaciones, tal como VML. OOXML no sólo ignora las tecnologías alternativas,
estándares y abiertas, sino que además evita que otros proveedores incorporen
compatibilidad interoperable para otras tecnologías. Si bien cualquier proveedor tiene
derecho a tomar sus propias decisiones con respecto a los diseños y sus prioridades, una
norma ISO debe poseer las características de transportabilidad e interoperabilidad para que
todos los proveedores puedan tener el mismo derecho a tomar sus propias decisiones sobre
los diseños y sus prioridades. Las restricciones arbitrarias de OOXML, que funcionan
extremadamente bien con las soluciones y plataformas de Microsoft, pero a la vez excluyen
a las todas las otras, hacen que esta propuesta de especificación no sea apta para ser
aprobada como una norma internacional.
22
Parte 4, sección 3.2.29, pág. 1917
Parte 4, sección 2.15.2.32
24
Parte 4, sección 4.7.1
23
5. Adaptación cultural y lingüística
Dado que las funciones de OOXML provienen de las funciones de Microsoft Office, no ha
de extrañar que estas funciones reflejen mejor las necesidades de los países y comunidades
desarrolladas donde el negocio de Microsoft ha experimentado el mayor éxito, olvidando a
las otras. Sin embargo, una norma internacional debe adoptar una perspectiva mundial y
proporcionar una amplia interoperabilidad cultural y lingüística.
Un ejemplo de esta carencia es la función de la hoja de cálculo NETWORKDAYS()25.
OOXML define esta función para devolver la cantidad de días hábiles entre dos fechas,
excluyendo cualquier fin de semana de ese intervalo. En algunas culturas, la semana
comprende el sábado y el domingo. En otras, los días de descanso son jueves y viernes o
viernes y sábado. OOXML no define “semana” ni proporciona una forma para que el
usuario defina este término. Tal como se implementa en Excel, la función supone que el fin
de semana siempre comprende el sábado y el domingo. Esta función de la hoja de cálculo
se define de manera que proporciona una respuesta incorrecta a miles de millones de
personas en todo el mundo. OOXML carece de adaptación cultural. Compare esto con la
misma función en el formato OpenDocument, en el que el usuario puede especificar un
parámetro adicional para anular la definición predeterminada de fin de semana.
Un segundo ejemplo, WordProcessingML posee una función denominada “Border Styles”26
que enumera una gran cantidad de gráficos prefijados que pueden utilizarse como bordes de
páginas. Éstos representan una lista cerrada de estilos de bordes prefijados y específicos
con unas imágenes que ya vienen prefijadas. La Ilustración 1 muestra un ejemplo de dos de
estos gráficos:
Ilustración 1: extracto de la especificación OOXML: bordes de página
Traducción:
25
26
Parte 4, sección 3.17.7.224
Parte 4, sección 2.18.4
earth1 (Borde decorativo de la Tierra)
Especifica un borde decorativo que consiste
en una imagen repetida de la Tierra, tal
como se indica a continuación (se muestran
dos repeticiones):
earth2 (Borde decorativo de la Tierra)
Especifica un borde decorativo que consiste
en una imagen repetida de la Tierra, tal
como se indica a continuación (se muestran
dos repeticiones):
Así, estas son las dos únicas posibilidades de mostrar la Tierra en un marco de página; sin
embargo, ninguna de ellas muestra Asia, el mayor continente de planeta. De igual forma,
existen gráficos para tartas de cumpleaños, cupidos del día de San Valentín, huevos de
Pascua pintados, galletas de jengibre de Navidad, calabazas iluminadas de Halloween y
otras imágenes que son adecuadas para el entorno cultural occidental cristiano, o incluso
más concretamente sólo para el mundo anglosajón, y que por tanto tienen una aplicación
más que reducida en cualquier otro lugar del mundo. El problema aquí es que esta lista de
estilos de bordes de página es una lista cerrada y coincide exactamente con lo que
proporciona Microsoft Word. Cualquier potencial implementador de OOXML no podrá
ampliar esa lista aportando sus tipos de imágenes adicionales con el propósito adaptarse
mejor al entorno cultural de sus clientes. Si así lo hiciera, sus documentos no serían
válidados por OOXML. De ahí que toda aplicación que pueda utilizar imágenes adicionales
“no permitidas” como bordes de páginas no cumplirá con la especificación OOXML. ¿Es
esta la forma en que OOXML se adapta a otras culturas? En el caso de los bordes de
páginas no ofrece adaptación que valga: todos hemos de ser anglosajones.
Tercer ejemplo: tal y como se mencionó anteriormente, WordProcessingML define una
relación determinada de estilos de numeración para las listas numeradas.27 Para empezar,
estos estilos de numeración sólo han sido mencionados, pero no definidos. Pero además se
incluyen como una lista cerrada y, de nuevo, coinciden justo con lo que admite Microsoft
Word, no pudiendo, obviamente, ampliarse a lo que admitan otros proveedores. Pero lo
peor es que la lista de estilos que se proporciona es incompleta, ya que no admite, por
ejemplo, el alfabeto armenio, el tamil, ni el griego, ni tampoco las numeraciones etiópicas y
jemer; tampoco admite la mayoría de los sistemas históricos que utilizan los estudiosos e
historiadores. La mejor solución hubiera sido utilizar un enfoque declarativo o generativo,
como el que usan los formatos XSL:FO de W3C y OpenDocument. Esto hubiera permitido
utilizar una lista abierta, dinámica y ampliable de estilos de numeración, cada uno además
autodefinido.
Por todo esto, la adaptación cultural y lingüística es un aspecto frustrada en OOXML
debido al uso generalizado de listados cerrados que, si bien coinciden perfectamente con lo
que Microsoft Office ofrece actualmente, no es ampliable a otros proveedores ni culturas de
manera interoperable.
27
Parte 4, sección 2.18.66
6. Resumen
Los estándares también se rigen por normas estándares. Sobre la base de la evaluación de la
especificación OOXML propuesta según los criterios que ISO proporcionó sobre cómo
debe ser una norma, este informe ha detallado algunos puntos en los que OOXML no
cumple con las diversas características que son de exigir para cualquier normas ISO:
precisión, criterios comunes, nivel óptimo de orden, excelencia, consolidación de las
mejores prácticas de la ciencia, tecnología y experiencia, interoperabilidad, capacidad de
transferencia, y adaptación cultural y lingüística. Mediante diversos ejemplos hemos
demostrado que la norma OOXML propuesta queda lejos de superar ese listón (de hecho,
estamos en disposición de entregarle cientos de ejemplos adicionales que ya hemos
estudiado y tenemos disponibles). Al no poder cumplir con estos criterios, OOXML es
imposible que provea el mejor beneficio a la comunidad como dicta ISO. De hecho, todo
apunta a que esta propuesta de estándar se dirige a beneficiar sólo y exclusivamente a una
empresa concreta.
Las exigencias que se deben adoptar para un formato que va a representar y almacenar
todos nuestros documentos son altas. Como deben serlo. Es imprescindible contar con un
formato de documento estándar que cumpla con los criterios mencionados anteriormente
para conservar a largo plazo nuestra herencia digital, de forma que toda la ciudadanía tenga
un acceso equitativo a los documentos y registros gubernamentales, y se consiga que
integre los procesos comerciales y flujos de trabajo a través de sistemas heterogéneos que
se basen en documentos eficaces y rentables. OOXML, el formato de fichero de Microsoft
Office, no proporciona ninguno de estos beneficios ni es, por tanto, adecuado para una
norma ISO.
Por todo ello instamos a votar en contra de esta propuesta de estándar en la votación DIS
29500 del Comité Técnico Conjunto N.º 1 de ISO/IEC.
Para mais informação e contatos:
http://www.openxml.info [ES, PT]
http://www.noooxml.org [EN]
Iste documento está endossado pelas entidades cujos logotipos mostran-se em
http://www.openxml.info. Entre outras:
FFII, Projeto Software Livre Brasil, FUNDECYT, Hispalinux, ATI, Red Internacional
de Administraciones Públicas para el Software Libre, Iniciativa Focus, Asociación Linux
Español, Fundación Ciencias de la Documentación.