Para tentar remediar esse problema, tentarei explicar da maneira mais simples possível, usando linguagem não técnica (o que pode chocar os desenvolvedores, mas este artigo não é direcionado a eles), algumas características técnicas do Open Document Format (ODF), que o tornam a pedra angular de um ecossistema aberto e independente de fornecedores para documentos de escritório, defendendo as liberdades digitais de todos os usuários e a governança de seu conteúdo.
Vou começar explicando como descompactar um arquivo ODF, que não é nada mais do que um conjunto de arquivos XML e outros arquivos (para imagens e vídeos) contidos em uma pasta ZIP, a fim de examinar seus componentes internos e, em particular, o arquivo content.xml, que é o que contém o corpo do documento (ou seja, a propriedade intelectual do usuário).
O objetivo não é tanto avaliar a conformidade (conformidade com especificações) e a interoperabilidade (a capacidade de trocar arquivos de forma consistente entre as ferramentas), pois esses aspectos sempre serão tratados por especialistas, mas sim entender as vantagens para o usuário do formato aberto e padrão sobre o formato fechado e proprietário (que é falsamente padrão, uma vez que foi aprovado pela ISO / IEC, desafiando as “suas” definições de padrões).
Por esse motivo, farei uma breve digressão final sobre as características do formato OOXML (Office Open XML) usado pelo Microsoft Office e Microsoft 365, novamente para esclarecer aos usuários os riscos que enfrentam e os danos que causam a si e a outros usuários quando usam os formatos DOCX, XLSX e PPTX, bem como o “presente” que estão dando à Microsoft, a quem eles estão efetivamente confiando ao gerenciamento e futuro de seu conteúdo.
Analisando um arquivo ODF
Pegue qualquer documento que você tenha criado com o LibreOffice. Por conveniência, recomendo começar com um documento de texto criado com o LibreOffice Writer, com a extensão ODT. Antes de fazer qualquer outra coisa, duplique o arquivo, porque um erro no procedimento poderia torná-lo ilegível e mover o original para outra pasta.
Renomeie a cópia, substituindo a extensão ODT pela extensão ZIP, sem excluir o ponto. O ícone do arquivo se tornará o de um arquivo compactado. Se ele se tornar branco ou vazio, você fez algo errado ou excluiu o ponto. Verifique todas as etapas até que o ícone se torne o de um arquivo compactado.
Neste ponto, clique com o botão direito do mouse no ícone e selecione “unzip” ou “expand” para extrair o conteúdo do arquivo compactado em uma pasta com o mesmo nome do arquivo sem a extensão.
A pasta conterá os seguintes itens:
- a pasta META-INF, que conterá o arquivo manifest.xml
- a pasta Thumbnails, que pode conter o arquivo thumbnail.png
- o arquivo content.xml, que contém o corpo do documento
- o arquivo styles.xml, que contém as definições de estilo
- o arquivo meta.xml, que contém os metadados do arquivo (autor, data de criação, data de última modificação, etc.)
- o arquivo settings.xml, que contém as configurações do aplicativo
Cada arquivo XML dentro de um documento ODF deve estar em conformidade com o esquema RelaxNG XML, ou REgular LAnguage para XML Next Generation, criado pelo OASIS em 2001 e 2002, que é mais simples – e, portanto, mais acessível a usuários não técnicos – do que outros esquemas XML. As regras de embalagem são definidas pelas especificações OpenDocument Packaging.
Além da validação do esquema, deve atender a uma série de condições.
- Composição estrutural: os elementos dos arquivos ZIP e manifest.xml
- Conformidade de funcionalidade: todas as funcionalidades padrão e opcionais (metadados, estilos, tabelas, gráficos, etc.)
- Conformidade da fórmula: as fórmulas das folhas de cálculo devem ser compatíveis com a semântica OpenFormula
- Conformidade de segurança: perfis ODF, criptografia, assinatura digital
O arquivo manifest.xml contido na pasta META-INF deve listar todos os arquivos no arquivo ZIP, com seu tipo de mídia:
"manifest:manifest xmlns:manifest"urn:oasis:names:tc:opendocument:xmlns:manifest:1.0
"manifest:file-entry manifest:full-path"/" manifest: media-type"""application/vnd.oasis.opendocument.text”/
"manifest:file-entry manifest:full-path"content.xml" manifest:media-type""texto/xml"/
“manifest:file-entry manifest:full-path””styles.xml” manifest:media-type.text/xml”/
?– miniaturas, configurações, etc. –
?/manifest:manifest (em inglês)
Simplesmente omitir um arquivo ou cometer um erro na descrição de seu tipo de mídia é suficiente para tornar o arquivo ODF estruturalmente não compatível.
ODF: a importância do arquivo content.xml
Para entender os benefícios do usuário de um formato padrão aberto, como o ODF, em um formato proprietário, mesmo que seja teoricamente aberto, como o OOXML, uma análise rápida do arquivo content.xml de arquivos ODF e seu equivalente em arquivos OOXML, que difere dependendo do tipo de arquivo (e isso sozinho é um sinal de que o desenvolvimento do OOXML não levou em conta as necessidades do usuário, mas focado em complexidade artificialmente crescente), é suficiente.
Vamos dar um primeiro exemplo, baseado em uma das frases mais famosas da história da literatura mundial, ou seja, “ser ou não ser, essa é a pergunta” proferida pelo protagonista de Hamlet de William Shakespeare.
O arquivo content.xml de um documento de texto contendo apenas esta frase tem 32 linhas: os primeiros 18 fornecem referências a todos os padrões usados (como X-Forms e MathML), liste as fontes usadas nos estilos de documento e defina os estilos (neste caso, apenas um, dado o comprimento do texto e a ausência de formatação).
As próximas 13 linhas são as seguintes:
"Oficiário:body"
"Oficiário:texto"
"office:forms form:automatic-focus""forma":apply-design-mode""false" /
"texto:sequence-decls"
Texto:sequence-decl texto:display-outline-level"0""0" texto:"Ilustração"/'
Texto:sequence-decl texto:display-outline-level"0' text:name'"Table"/
"text:sequence-decl text:display-outline-level"0"0" Texto:"Text"/?
?text:sequence-decl texto:display-outline-level”0? text:name?””Drawing”/????
"text:sequence-decl text:display-outline-level"0' text:name'"Figura"/
?/text:sequence-decls
"text:p text:style-name"P1"Para ser, ou não ser, essa é a pergunta -/text:p?
?/o escritório:texto
?/o escritório:body?
As primeiras linhas definem o corpo do documento e o fato de que ele é um texto. As seguintes linhas são declarações que, neste caso, não acrescentam nada, mas noutros contextos forneceria informações sobre outros elementos do documento.
A linha-chave é esta: "text:p text:style-name" P1'? Ser ou não ser, ou não ser, que é a questão -/texto:p, que define um parágrafo, declara seu estilo (P1) e fornece o conteúdo: Ser ou não ser, essa é a pergunta. Claro e legível por qualquer usuário, que agora tem as chaves para acessar o documento e gerenciar seu conteúdo, ou seja, o produto de seu cérebro.
Naturalmente, documentos e conteúdos mais complexos corresponderiam a um arquivo content.xml mais complexo, mas sempre respeitando a legibilidade do conteúdo e a simplicidade do esquema XML.
OOXML: o que acontece dentro do arquivo
Vamos ver o que acontece no caso do mesmo documento salvo no formato DOCX, fechado e proprietário e artificialmente complexo. O arquivo é chamado de document.xml e não content.xml, e isso – obviamente – não seria significativo se não fosse mais um sinal da complexidade do formato, dado que no caso do Excel o arquivo é chamado workbook.xml e no caso do PowerPoint é chamado de slide1.xml, e assim por diante.
O arquivo document.xml de um documento de texto contendo apenas a frase “Ser ou não ser, ou não, ou seja, a pergunta” tem 41 linhas: a primeira fornece referências a todos os elementos proprietários usados (como processamento de textoCanvas, VML e WordML) e todas as linhas subsequentes estão relacionadas ao conteúdo:
?w:body
?w:p xmlns: www14?”http://schemas.microsoft.com/office/wordml/wordml” w14:paraId?”2DC08235? w14: textId
?w:r w:rsidR?”6B254FF6
?w:rPr/?
"w:t xml:space""preserve"?Para ser, ou "/w:t?
?/w:r?
?w:r w:rsidR?”6B254FF6
?w:rPr/?
?w:t?not?/w:t?
?/w:r?
?w:r w:rsidR?”6B254FF6
?w:rPr/?
"w:t xml:space" preervir" - para ser, "/w:t"
?/w:r?
?w:r w:rsidR?”6B254FF6
?w:rPr/?
"w:t'that'/w:t?
?/w:r?
?w:r w:rsidR?”6B254FF6
?w:rPr/?
?w:t xml:space?” preerve” ?/w:t?
?/w:r?
?w:r w:rsidR?”6B254FF6
?w:rPr/?
"w:t'is'/w:t'
?/w:r?
?w:r w:rsidR?”6B254FF6
?w:rPr/?
"w:t xml:space" preervir" - a pergunta "/w:t"
?/w:r?
?/w:p ?
?w:sectPr?
?w:pgSz w:w?”11906 ? w:h?”16838? w:orient”””/
"w:pgMar w:top"1440" w:right"1440"1440" w:bottom"1440" w:left"1440' w: fonemilhado"720' w:footer"720' w:
?w:cols w: space?”720?/?
?w:docGrid w:linePitch?”360?/?
?/w:sectPr?
?/w:body
Obscuro e ilegível. Eu desafio qualquer usuário a reconstruir um texto de qualquer complexidade de um documento XML como este, se o arquivo original estiver danificado. No caso do ODF, conseguimos reconstruir até mesmo documentos de centenas de páginas, ou apresentações de dezenas de slides, porque o conteúdo era legível por qualquer usuário, mesmo não técnico.
Vamos tentar imaginar o tamanho do arquivo content.xml e o arquivo document.xml se, em vez da frase do príncipe Hamlet, houvesse todas as 5.566 linhas de toda a tragédia, na versão original escrita por William Shakespeare. Neste caso, a diferença fala por si só: content.xml é 5,598 linhas de comprimento (32 linhas a mais do que o texto), document.xml é 93,289 linhas de comprimento (87,723 linhas mais do que o texto).
Complexidade de arquivos como a nova estratégia de lock-in
Essa complexidade do arquivo é intencionalmente escondida do usuário, que vê um documento de aparência normal na tela e não tem ideia de que eles estão escrevendo um arquivo em seu disco rígido ou na nuvem que tem características muito semelhantes às dos arquivos proprietários usados no século passado, que são ilegíveis sem o software com o qual foram escritos.
Um usuário que acredita ter feito progressos significativos em termos de soberania digital porque usa um formato que acredita ser aberto e padrão, mas que, pelo contrário, é ainda pior do que os formatos binários dos anos 1900 – que nada mais eram do que escrever o que estava na memória – porque, sendo baseado em XML, é a prole de um algoritmo que pode ser modificado remotamente com uma atualização de rotina (como acontece na realidade, onde o mesmo documento é escrito em formato DOCX, mas em um formato XML. Microsoft).
Portanto, é um formato ainda mais fechado e proprietário do que os formatos binários que substituiu em 2006. Este último, sendo o resultado de escrever o que estava na memória dos arquivos, era previsível e poderia ser emulado, enquanto o OOXML é imprevisível devido ao algoritmo e, portanto, quase impossível de emular sem o estudo constante de suas muitas evoluções.
O OOXML é um formato teoricamente aberto e padrão, que na realidade é fechado e proprietário, e representa a mais recente evolução da estratégia de bloqueio que sustenta todos os produtos da Microsoft para a produtividade individual, defendendo um volume de negócios estimado em mais de US $ 25 bilhões por ano, com um lucro líquido estimado em mais de US $ 20 bilhões por ano (todos os números são estimativas, já que os números dos analistas não estão mais disponíveis e são provavelmente mais baixos do que os números reais).
Talvez tenha chegado o momento de as organizações supranacionais, os governos centrais e locais, e provavelmente também os utilizadores individuais, abrirem os olhos e dar um simples passo em frente para a soberania digital, ou seja, a governação dos documentos e o seu conteúdo, independentemente das escolhas comerciais de uma única empresa, adotando o ODF e abandonando o OOXML.
Publicação original pode ser vista clicando aqui.
Comentários
Postar um comentário