Convertendo vídeos do Decodificador de TV Digital/PVR LB-SAT LBDTV10T para AVI no Linux

Com o surgimento da TV Digital no Brasil, no seu padrão ISDB-Tb (ou ISDB-International), vários conversores estão sendo vendidos a preços interessantes com a mais diversa gama de recursos. Um muito popular é o recurso de PVR (Personal Video Recorder – Gravador Pessoal de Vídeo), onde o aparelho grava em um disco rígido externo ou pendrive à programação de TV, como era o caso nos antigos videocassetes. No caso, iremos falar do decodificador LBDTV10T, da empresa LBSat. Esse é um produto a um preço razoável e que pode ser encontrado em boas casas especializadas em equipamento de TV (no caso, comprei em uma loja da Rua Vitória, uma das travessas da Santa Efigênia), e possui as seguintes características.

Características:

  • HDTV e SDTV
  • Instalação automática de canais
  • Menu na tela (OSD) – facilita a configuração do aparelho.
  • Saída HDMI para imagens em alta definição e áudio digital
  • Saídas S-Video, Vídeo Componente, vídeo e áudio estéreo
  • Saída de áudio digital óptica e SPDIF
  • EPG (Guia de Programação Eletrônica) Permite visualizar informações sobre os programas da TV. (Este recurso depende da transmissão pela emissora)
  • Programação de canais favoritos
  • Sintonia automática UHF para TV Digital – Canais 7 ao 69
  • Controle Remoto multifunção
  • Ajustes de Áudio / Vídeo / Volume
  • Seleção automática de voltagem – entre 100 e 240 Vac
  • Idiomas do menu: Português

Observações:
Antes de comprar o conversor, certifique-se de que a sua região já recebe as transmissões da TV Digital. Para captar o sinal digital corretamente é necessária a utilização de uma antena UHF, interna ou externa. A captação é restrita aos sinais da TV aberta, não incluindo, portanto, os sinais de TV por assinatura.
Especificações:

  • Resolução de vídeo : 1080i / 720p / 576i
  • Conexão USB para : MP-3, MP-4, Fotos. Através dela é possível reproduzir arquivos de músicas em MP-3, de vídeo MPEG-2, MPEG-4, e exibir arquivos de fotos JPEG.
  • Formatos de Tela : 16:9 e 4:3

É ótimo poder gravar vídeos em um HD externo, ainda mais se pensarmos que esses arquivos são acessíveis pelo computador como arquivos normais de vídeo. O problema é que a maior parte dos decodificadores (esse incluído) gravam o stream DTV recebido da antena diretamente (como se usasse um tee entre a saídea de vídeo e um arquivo no HD externo), o que envolve formatos proprietátios estranhos e convenções um pouco complexas. Mas com a ajuda do Google e do pessoal do Clube do LBDTV10T no HT-Fórum. Ainda não foi possível automatizar o processo devido a alguns problemas com o arquivo do decodificador, em especial na parte de áudio, mas tentarei fazer o melhor possível para expĺicar detalhadamente o processso de modo que você possa converter adequadamente os seus vídeos para usá-los no computador.
Esse tutorial foi elaborado em um Intel Core 2 Duo 2GHz, 3GB de RAM, 320 GB de disco, Ubuntu Linux Karmic Koala (9.10), com o repositório Medibuntu original e todos os pacotes de vídeos e áudio, incluindo os non-free e restricted. Você precisará ter instalado mencoder, mplayer, VLC e ffmpeg. Uma vez dito isso, vamos começar o processo.

1-) Encontrando o vídeo no disco e preparando-o para codificação

A primeira parte é encontrar e prepara o vídeo. Nesse caso, existe apenas uma sugestão: limpe o disco pelo decodificador (MENU -> Meu de Função -> Função PVR -> Formatar HDD). Caso contrário, você terá que descobrir o arquivo em meio aos diversos vídeos gravados e o modo como os vídeos são nomeados internamente pelo decodificador não ajuda. Os arquivos ficam gravados em uma pasta dentro do HD chamada PVR, em diretórios com o nome PVRXXXXX, (onde X são números hexadecimais), Dentro dessas pastas, existem pastas ~DATA/, onde vários arquivos DATAXX.trp (onde X são números normais). Esses arquivos são as várias partes do vídeo gravadas pelo decodificador. Isso ocorre pois, como ele formata os discos em FAT32 para maior eficiência, o tamanho máximo do arquivo é de 2 GB. Quando esse valor é superado, o decodificador cria um novo arquivo. Nesse caso, iremos fundir os arquivos com o seguinte comando em um terminal, dentro da pasta ~DATA/ do vídeo: cat DATA00.trp DATA01.trp DATA02.trp ... DATAXX.trp > convert.trp. Caso o vídeo tenha menos partes, basta usar menos arquivos. É só lembrar de listar todos os arquivos DATAXX.trp nesse comando. PS: não faça isso no disco do PVR! Copie os arquivos para uma partição Ext3/ext4/NTFS ou outro formato de arquivos mais avançado, caso contrário continuará com a limitação do tamanho de arquivo e não funcionará. Um comando alternativo seria cat DATA*.trp > convert.trp, mas não existe como garantir a seqüência dos arquivos.
Trabalharemos no caso com esse arquivo convert.trp. Ele é um arquivo em um formato chamado Transport Stream (TS), um encapsulamento do MPEG-2 para a transmissão contínua de arquivos, E conterá vídeo e áudio. Esse tutorial não irá aprofundar nos mecanismos de extração de áudio, uma vez que o TS permite vários canais de áudio e isso é usado em especial em vídeos (onde você pode colocar um canal de áudio em porutugês e um no idioma nativo do programa). No caso, nos restringiremos ao uso mais simples possível desse tutorial.

2-) Demultiplexação do vídeo original:

Um problema com o sistema de TV Digital Brasileiro é que ele utiliza na camada de áudio o formato HE-AAC, que não é muito bem suportado tanto por FFMpeg quanto por MPlayer/mencoder, os principais mecanismos de codificaçaão/decodificação/reprodução de vídeos e áudios em Linux. Porém, ele funciona muito bem no VLC e isso permite que utilizemos tal player para codificar o áudio.
A primeira parte então é demultiplexar o vídeo original, ou seja, separar as partes de vídeo e áudo do TS para que possamos trabalhar calma e corretamente com cada arquivo sem maiores problemas. No final desse processso, teremos um arquivo .mp4 (MPEG-4 AVC H264) e um outro arquivo de áudio .aac (MPEG-4 HE-AAC). Para esse processo, utilizaremos o Mplayer. Abra um terminal e, dentro da pasta ~DATA/ do vídeo desejado, use os seguintes comandos:

mencoder convert.trp -o convertVideo.mp4 -demuxer lavf -nosound -ovc copy
mplayer -dumpaudio -dumpfile convertAudio.aac convert.trp

Nesse momento, podemos reproduzir o vídeo no sistema para (1) testar se a demulplexação foi bem-sucedida e (2) verificar se o arquivo é o desejado. Para isso, digite mplayer convertVideo.mp4 e veja se está OK. Tudo OK, vamos para começar a trabalhar os arquivos.

3-) Codificação do áudio:

Um problema de fazer o processo de demultiplexação dos arquivos é que precisaremos optar por formatos de vídeo e aúdio individuais dos formatos de vídeo desejados, sem podermos recorrer a templates e outros esquemas que associem o vídeo e áudio a um formato. No caso, utilizaremos o AVI com vídeo XviD e áudio MP3. Nesse processo, iremos codificar cada parte separadamente e depois iremos multiplexar os arquivos no arquivo final, juntando ambos os arquivos de vídeo e áudio em uma saída final.
No caso, vamos focar primeiro na codificação do áudio, que iremos fazer usando o VLC. Esse passo justamente é o que impede criar-se um script para automatizar a codificação do arquivo, uma vez que VLC é um programa em iterface gráfica. Então, vamos ao passo a passo:

  1. Abra o VLC e vá no menu Mídia e escolha a opção Converter/Salvar;
  2. Na Aba Arquivo, clique em Adicionar. Na caixa de diálogo de arquivos, vá até a pasta PVRXXXXX/~DATA do vídeo desejado e escolha o arquivo convertAudio.aac desse ~DATA;
  3. Clique em Converter/Salvar. Na janela que abrir, na seção Configurações, escolha o perfil “Áudio – MP3“;
  4. Copie o conteúdo de Fonte (onde deverá ter o caminho completo para o arquivo de origem convertAudio.aac) para Destino e modifique a extensão para .mp3, de modo que fique convertAudio.mp3;
  5. Clique em “Iniciar“. Se quiser verificar as configurações, clique no ícone de chave de fenda, que irá apresentar as informações de codificação de áudio;

Agora, aguarde o arquivo ser codificado pelo VLC. Se preferir, teste o arquivo de saída com mpg123 convertAudio.mp3. Tudo estando OK, é hora de codificar o vídeo e encerrar o serviço.

4-) Codificar o vídeo e obter o arquivo final:

Agora codificado o áudio de saída em MP3, é hora de codificar o vídeo para XviD. No caso, também usaremos o mencoder para codificar o arquivo de saída de vídeo. Para isso, use o seguinte comando em um terminal na pasta PVRXXXXX/~DATA do vídeo desejado:

mencoder -o convertVideo.avi -ovc lavc -lavcopts vcodec=mpeg4:vhq:vbitrate=5000 -vf scale -zoom -xy 720 convertVideo.mp4

No caso, setei algumas poucas opções, entre elas -vf scale -zoom -xy 720, que permite codificar corretamente o vídeo para 720p. Se você preferir outras opções, dê uma pesquisada na Internet que configurações possam ser ajustadas para melhor resultado. O único objetivo aqui é obter uma saída de qualidade razoável. Atenção: esse comando foi baseado em sugestões para ripping de DVD obtidas em sites na Internet. Não sou um especialista em codificação de vídeos e não saberia informar a melhor combinação de parâmetros.
Se desejar, teste o vídeo no Mplayer como fizemos anteriormente. Uma vez tudo OK, você pode multiplexar (juntar) os arquivos de vídeo e áudio em um arquivo de saída com os comandos abaixo:

ffmpeg -i convertVideo.avi -i convertAudio.mp3 -acodec copy -vcodec copy convertFinal.avi
ou
mencoder -oac copy -ovc copy -o convertFinal.avi -audiofile convertAudio.mp3 convertVideo.avi

O resultado é o arquivo AVI com o nome convertFinal.avi. Esse arquivo é o resultado final, que poderá ser usado em outros formatos e gerar DVD e afins. Não vou entrar nesses méritos, mas muita documantação pode ser encontrada na Internet. Também não foi testado se a saída possui ou não perda de sincronismo entre o áudio e o vídeo. Aparentemente isso pode acontecer ocasionalmente e infelizmente não existe uma solução simples nesse caso. O que pode-se sugerir caso isso ocorra é ajustar-se o arquivo de áudio MP3, removendo alguns milisegundos de seu início e depois multiplexar novamente o vídeo.
Espero que esse tutorial tenha sido útil e que você possa obter o melhor de seu decodificador de TV Digital.

Anúncios

Por que não me surpreendo? Documentos produzidos no MS Office 2007 NÃO SÃO COMPATÍVEIS com DIS 25900 (OOXML)

Certas coisas, quando você lê, não te surpreende. Não interessa o que, mas certas coisas, ao lê, não te surpreende. No meu caso foi ler que, via Groklaw, que documentos MS Office 2007 não são compatíveis com o ISO 25900, também conhecido como OOXML.
Surpreendente? Calma que a coisa ainda vai fiar pior!!!

Bem, tudo começa quando Alex Brown, um dos pais dessa aberração chamada OOXML, decide fazer um teste após receber os schemas atualizados com as modificações sugeridas no BRM.

Griffin Brown Weblog – OOXML and Office 2007 Conformance: a Smoke Test

I was excited to receive from Murata Makoto a set of the RELAX NG schemas for the (post-BRM) revision of OOXML, and thought it would be interesting to validate some real-world content against them, to get a rough idea of how non-conformant the standardisation of 29500 had made MS Office 2007.

Not having Office 2007 installed at work (our clients aren’t using it – yet), the first problem is actually getting a reasonable sample for testing. Fortunately, the Ecma 376 specification itself is available for download from Ecma as a .docx file, and this hefty document is a reasonable basis for a smoke test …

Resumindo aqui, uma vez que a tradução seria longa e desenecessária: ele recebeu os novos schemas do OOXML atualizados para considerar as modificações do BRM e decidiu validar algum conteúdo “real” para ter uma idéia de o quão não-padronizado um arquivo .docx produzido pelo MS Office 2007 era. Como ele não tinha nenhum Office 2007 à mão, ele utilizou as próprias especificações do OOXML segundo a ECMA, que foram publicadas em… .docx.
Perceba a fina ironia: o que deveria confirmar o padrão acabou tornando-se um caso de uso negativo contra o mesmo. Acha engraçado? Eu não.

Griffin Brown Weblog – OOXML and Office 2007 Conformance: a Smoke Test

The main document (“document.xml”) content for Part 4 of Ecma 376 weighs in at approx. 60MB of XML. (…) So we have a document and a RELAX NG schema. All that’s necessary now it to use jing (or similar) and we can validate (…) The STRICT conformance model is quite a bit different from Ecma 376, essentially because most of that format’s most notorious features (non ISO dates, compatibility settings like autospacewotnot, VML, etc.) have been removed. Thus the expectation is that existing Office 2007 documents might be some distance away from being valid according to the strict schemas.

Sure enough, jing emitted 17MB (around 122,000) of invalidity messages when validating in this scenario. Most of them seem to involve unrecognised attributes or attribute values: I would expect a document which exercised a wider range of features to generate a more diverse set of error message.

Traduzindo

Os conteúdos do documento principal (“document.xml”) da Parte 4 do ECMA 376 [a primeira versão do OOXML] tinham algo em torno de 60 MB de XML (…) portanto tinhamos um documento e um schema em formato RELAX NG. Tudo o que precisávamos portanto era usar o jing [validador de documentos segundo schemas RELAX NG feito em Java] ou outros sistemas similares e poderíamos validar o documento (…) O modelo de conformitade STRICT é um tanto diferente do ECMA 376, essencialmente por causa de que os mais notórios recursos (como datas não-ISO, informações de compatibilidade como os do autospacewotnot, VML, etc.) forma removidos. Desse modo a expectativa era de que documentos Office 2007 deveriam estar longe de serem considerado válidos segundo schemas restritos.
Obviamente, o jing retornou algo em torno de 17MB (ou por volta de 122.000) de mensagens de erro enquanto validando o documento nesse cenário. A maior parte deles tem a ver com atributos ou valores de atributos não reconhecidos: imagino que um documento que utilize uma gama maior de recursos provoque uma gama maior de erros.
(Grifos meus)

Note que o próprio autor assume que (1) documentos do MS Office 2007 não estavam longe de serem considerados padrão e (2) que documentos que usassem mais recursos provavelmente gerariam mais mensagans de erro.
Agora, a pergunta é: se o formato foi padronizado, quanto tempo o usuário do Office 2007 deveria esperar para ter documentos DIS-25900 compliant, uma vez que o Office 2007 é a “implementação de referência” do OOXML? Como comparação, o OpenOffice.org é a “implementação de referência” do ODF, e levou apenas duas semanas para que o mesmo gerasse documentos ODF compliant.
No mesmo post, o autor mostra um outro schema, TRANSITIONAL, que é mais “liberal” que o STRICT. Mesmo assim, o documento gerou mensagens de erro relacionadas a uma tag específica. As concluões? O próprio autor coloca:

Griffin Brown Weblog – OOXML and Office 2007 Conformance: a Smoke Test

  • Word documents generated by today’s version of MS Office 2007 do not conform to ISO/IEC 29500
  • Making them conform to the STRICT schema is going to require some surgery to the (de)serialisation code of the application
  • Making them conform to the TRANSITIONAL will require less of the same sort of surgery (since they’re quite close to conformant as-is)

Traduzindo:

  • Documentos do Word gerados pela versão atual do MS Office 2007 não são compatíveis com o ISO/IEC 29500
  • Torná-los compatíveis com o schema STRICT demandaria alguma “cirurgia” nos códigos de (de)serialização de objetos na aplicação
  • Torná-los compatíveis com o schema TRANSITIONAL demandaria menos “cirurgia”, uma verz que ele está mais próximo da compatibilidade como-está;

Para resumir:

  1. Documentos do Word 2007 não são compatíveis com o OOXML;
  2. Torná-los compatíveis fielmente ao padrão OOXML (ISO 29500) demandaria grandes modificações no código do Office 2007;
  3. Torná-los compatíveis ao schema de transição demandaria poucas modificações, uma vez de que este schema está mais próximo do Office 2007;

Será que sou só eu que ainda acredito que isso não passou de um motivo para a MS arrumar um selinho de ISO para seus produtos e ainda assim manter seu lock-in nos documentos?
Além disso, será que a própria Microsoft não irá sabotar esse “padrão ISO” por si? O autor do post que estamos comentando é otimista (talvez de maneira quase Polianística):
Griffin Brown Weblog – OOXML and Office 2007 Conformance: a Smoke Test

Given
Microsoft’s proven ability to tinker with the Office XML file format
between service packs, I am hoping that MS Office will shortly be
brought into line with the 29500 specification, and will stay that way.
Indeed, a strong motivation for approving 29500 as an ISO/IEC standard
was to discourage Microsoft from this kind of file format rug-pulling
stunt in future.

Ou seja

Dada à habilidade da Microsoft de melhorar o formato do Office XML por meio dos service packs, espero que logo o MS Office seja alinhado com as especificações 29500 e assim permaneça. De fato, um dos maiores motivadores para a aprovação do 29500 como um padrão ISO/IEC foi como uma forma de desencorajar a Microsoft quanto a essa atitude de discrepâncias em relação ao padrão no futuro.

Diferentemente do autor do post em questão, sou mais cético: o retrospecto histórico, inclusive durante o processo de padronização do OOXML, da MS joga contra ela. Porém, espero realmente que, caso a MS continue por essa vereda, que ela ao menos alinhe-se ao padrão que, por mais ruim que seja, ela ajudou a criar. Mas até lá, vou continuar atento, observando isso e evitando ao máximo o OOXML.

Office OpenXML (OOXML) e inapto pela ISO 29500

OOXML = ISO 29500 – Microsoft Ganha, todos perdemos

Pois é Aconteceu o que temíamos: o OOXML agora é o ISO 29500 (com link apenas para que não achem que isso é um “1° de Abril” atrasado). Com uma série de defeitos técnicos e irregulariedades, e contando com o voto de “importantes países” como Azerbaijão, Costa do Marfim, Casaquistão, e Trinidad e Tobago, a Microsoft conseguiu seu intento e agora OOXML é um “padrão internacional”.
Ou seja: ela ganha, nós perdemos.
Por favor, não me venham dizer aquele positivismo polianista de que tudo está OK e que veremos implementações livres do OOXML logo. Sinceramente, um padrão de 6000 páginas, cheia de problemas técnicos e incertezas jurídicas, sobre os quais eu cansei de falar nesse blog, e que foi comentado por muita, muita gente, apenas fez com que a Microsoft conseguisse uma ferramenta para legitimar seu monopólio e ao mesmo tempo minou completamente a legitimidade da ISO, vítima de suas próprias decisões e da má-fé de Redmond. Mesmo que não houvessem os riscos de “patente submarina” (prefiro o termo “campo minado de Propriedade Intelectual”), a complexidade dos padrões e as questões dos artefatos de implementação complicam e muito o desenvolvimento de uma solução à parte da Microsoft de implementação do OOXML. Essa é a preocupação justamente do pessoal da ODF Alliance:

ODF Alliance Weblog – ODF Alliance Statement on the ISO Vote on OOXML

The process itself brought to the fore OOXML’s deficiencies that will prevent its use by public administrations, chief among them that OOXML remains a “community of one”—undocumented features, IPR restrictions, and features and functionality linked to other Microsoft products that will prevent OOXML’s use in other software products. (…) Nothing about the process will provide governments with any more confidence in OOXML’s openness and interoperability than they had before the vote.

Traduzindo:

O próprio processo [de padronização] trouxe à luz todas as deficiências que irão impedir o uso do OOXML na administração pública, a começar pelo fato de que o OOXML continua sendo uma “comunidade de uma pessoa só” – recursos não documentados, restrições relacionadas a Propriedade Intelectual, e recursos e funcionalidades ligadas a outros produtos Microsoft que o impedirão de ser usado com outros produtos (…) Não houve nada nesse processo que ofereceu aos governos qualquer confiança adicional na abertura e interoperabilidade do OOXML. (Grifos Meus)

Ou seja, qual a confiança que um governo, que possui necessidades críticas em vários sentidos quanto a documentação, possui de adotar o OOXML? Quais as garantias de compatibilidade, interoperabilidade, abertura e transparência do mesmo? Quais são as garantias que, uma vez que um governo crie uma estrutura baseada no OOXML, independente de utilizar produtos Microsoft ou não, ele poderá o fazer sem riscos e sem a possibilidade de processos por patentes ou qualquer outro tipo de infração de propriedade intelectual?
Governos necessitam armazenar documentos por 10, 20, 30, até mesmo 50 anos dependendo o documento, apenas pelo caráter legal. Confiar em um formato onde, a qualquer momento, uma pessoa, não importa qual, pode simplesmente dizer que vai levar a bola para casa e pior, que todo mundo que jogou com ele vai ter que pagar por ter usado a bola, é algo para dizer o mínimo temerário.
Isso é uma coisa que não poderia passar, como não passou e a ODF Alliance comenta:

ODF Alliance Weblog – ODF Alliance Statement on the ISO Vote on OOXML

The vote shined a spotlight on OOXML that will not dim. Only in response to growing public pressure has Microsoft promised to make changes to OOXML, and, to be sure, similar promises have been made on numerous occasions. To avoid any questions concerning the legitimacy of the vote, which included many documented irregularities, Microsoft needs to ensure that these promises made to national standards bodies are actually delivered.

Tradução:

A votação [de padronização da ISO] acendeu um sinal de alerta no OOXML que não irá apagar-se. Foi apenas graças à pressão pública que a Microsoft prometeu fazer mudanças no OOXML, o que, para ser sincero, já aconteceu antes em várias ocasiões. Para evitar questões relacionadas à legitimidade da votação, que inclui muitas irregularidades documentadas, a Microsoft tem que garantir que essas promessas feitas aos órgãos nacionais [de padronização] sejam realmente cumpridas. (Grifos meus)

Agora, será que isso acontecerá? De uma maneira otimista, eu gostaria que sim: gostaria de ver maior interoperabilidade entre os vários produtos. Porém, conhecedor do retrospecto (me sinto tentado a usar o termo karma) da Microsoft, não vejo como ter tais esperanças.
A ISO também sai perdendo nesse processo. Ao deixar que uma série de irregularidades ocorre-se (e perceba que a participação da Microsoft em vários NBs ou de seus Partners não é em si tal coisa), ela comprometeu todos os fundamentos que a tornavam digna de crédito: ao abaixar a cabeça para não ver o que aconteceu em vários países, ela acabou recebendo e aceitando sua parcela de culpa por um processo que, a meu ver, foi feito de maneira completamente errada. E se você acha que isso é blá-blá-blá meu, veja no mapa abaixo o tanto de caveiras que existem no mapa (cada caveira indica um país onde foram constatadas irregulariedades sérias no processo):

Clique para ampliar

Desse modo, o que aconteceu é que a ISO, ao “fechar-se em copas” em relação a essas falhas sérias do OOXML acabou perdendo muita coisa:

R.I.P. International Standards Organization « Adventures in a Perambulator

A failure, on the part of ISO, in so re-evaluating this situation during the next 2 months will result in my calling into question anything considered a standard by ISO. Any government, organization, agency or other that uses ISO as the authority for anything being a standard will be asked to prove that it actually is a standard: ISO authority will not be an acceptable response. It is my opinion that by this action of approving MSOOXML as a standard, ISO has demonstrated that it lacks the qualifications to adequately evaluate technical material and has further shown that its ethical behavior is subject to the highest bidder.

Traduzindo:

Uma falha por parte da ISO em reavaliar essa situação [de considerar padrão qualquer coisa que lhe seja empurrada goela abaixo] nos próximos dois meses me levará a questionar qualquer coisa que a ISO considere padrão. Qualquer governo, organização, órgão ou afim que use a ISO como autoridade para qualquer coisa que seja considerada um padrão deverá se questionar se realmente isso é um padrão: apenas a autoridade da ISO não será mais uma resposta aceitável. Na minha opinião, ao aprovar o MSOOXML como um padrão, a ISO demonstrou ter perdido as qualificações para adequadamente avaliar materiais técnicos e também demostrou que seu comportamento ético é digno de intenso repúdio. (Grifos meus)

Deixando-se penetrar por um processo que, embora tenha seguido (ainda mal-e-mal) a letra da norma, foi corrompido por trás dos panos por uma série de questionamentos, irregulariedades, lobbies e afins, a ISO perdeu (ou ao menos manchou) sua credibilidade. Se tal aprovação viesse de um consenso, seja por Fast-Track ou não, a ISO manteria sua credibilidade. Porém, ao aceitar as pressões de Redmond e não questionar como as coisas ocorreram nos países, aceitando passivamente isso, ela deixou essa credibilidade ser maculada (de maneira permanente, potencialmente) e, desse modo, colocou em xeque TODOS os padrões ISO. Alguns, como ODF, PDF e ISO 9000 escaparam ilesos, uma vez que são reconhecidos não apenas por meio da ISO, mas por suas próprias qualidades. Os demais, porém, passarão a ser questionados cada vez mais.
Eu duvido que em algum momento os questionamentos feitos foram realmente levados a sério. Parece choradeira de mau perdedor, mas se você ler os artigos do meu blog sobre o assunto, você verá que em si não sou contra o OOXML. O que eu sou contra é que, como colocado, o OOXML é uma forma de obter-se um crivo internacional a um monopólio que vem a dar poderes ilimitados apenas a uma empresa.
Não vou continuar repetindo meus entendimentos sobre o OOXML: basta ler aqui no meu blog todos os artigos que escrevi sobre o assunto. Porém, o que vou afirmar é que, a não ser que o processo de padronização do OOXML seja revertido, ninguém mais confiará na ISO e ela irá obter a mesma reputação que a Microsoft (que não é lá muito boa).
Gostaria de citar o desabafo do Jomar, alguém que camelou demais e viu seus esforços por um padrão realmente técnico e correto ser atropelado por um rolo compressor vindo de Redmond:


OpenXML: Eles realmente ganharam ? | void life(void)

Se a decisão é de que problemas são “coisinhas”, ela não foi técnica e portanto ganhamos todos um grande exemplo de onde se chega quando se coloca a boa técnica de lado (ou alguém aí consegue, sem consumir substâncias alucinógenas, acreditar que ter CINCO RECOMENDAÇÕES OFICIAIS PARA SE ESCREVER UMA SIMPLES DATA é algo lógico e natural !!! E que isso ainda irá contribuir para o aumento da interoperabilidade ?). Prá falar a verdade, como fã de Rock’n Roll eu até que vi um bom “revival” da lisergia dos anos 70 nisso tudo (pois só com muito LSD na cabeça eu talvez conseguisse explicar e defender publicamente a tese de que uma só norma internacional é na verdade cinco que na verdade possue duas cláusulas de conformidade que a torna dez sendo ao mesmo tempo uma… fiquei até tonto só de pensar nisso para poder escrever…e olha que eu não tomei nada, heim…).

Ou seja, na realidade, a ISO e todo o processo do Fast-track foi apenas uma forma da Microsoft conseguir um Selinho de ISO para o Office 2007. Sabe, como os selinhos ISO-9000 que qualquer empresa deseja para mostrar que seu produto é o máximo, ainda que ele seja uma porcaria… ainda que seja a mesma porcaria o tempo todo? Como um padrão com redundâncias, discrepâncias, contradições e afins passou pela ISO, que deveria zelar pela qualidade técnica?
E para realmente terminar esse post, deixo as mesmas perguntas do Jomar à Microsoft:

OpenXML: Eles realmente ganharam ? | void life(void)

  1. Quando o Microsoft Office vai suportar a IS 29500 (ele agora suporta apenas o ECMA-376, que é uma especificação diferente) ? E quais delas serão suportadas (IS 29500-1, IS 29500-2, IS 29500-3, IS 29500-4, IS 29500-5) com quais classes de conformidade (viu como agora vai ser bem fácil comprar uma suite de escritório que suporte o OpenXML…) ?
  2. Quando sai o próximo Service Pack do OpenXML ?
  3. Vocês já prepararam algum mecanismo de Auto-Update na ISO ? Vai ser via plug-in ou via backdoor mesmo ?

Por isso, apesar de tudo isso, continuo apoiando o ISO 26300 (ODF) como o verdadeiro formato de documentos padrão.

Office OpenXML (OOXML) e inapto pela ISO 29500

Powered by ScribeFire.

A sujeira continua a aparecer no OOXML

A verdade está aparecendo cada vez mais no OOXML, e de como o processo está se tornando não apenas estranho, mas totalmente fora de ordem. Hoje, o Jomar postou algumas informações sobre o que diabos aconteceu realmente no BRM: na realidade, a famosa “Lei do Silêncio” não foi ‘esclarecida’ (perceba a ironia aqui). A questão não é de que havia algum tipo de “Lei de Silêncio”, mas sim de que os participantes deveriam (não seriam obrigados) a permanencer em silêncio quanto a esses eventos… É engraçado que isso tenha sido colocado agora, quando todos ficaram calados, enquanto outras partes interessadas utilizaram-se desses valores para tentar “passar a perna” no debate. Isso mostra como essas coisas são úteis para aqueles que querem trapacear processos ISO.
Como sempre, o Jomar manda muito bem ao esclarecer as coisas: ele se preservou enquanto não tinha a certeza de poder ou não comentar o processo, o que mostra que ele é um cara ético. Agora, porém, ele resolveu “rasgar o verbo”:

Finalmente: os detalhes sobre o resultado do BRM | void life(void)

Como informado no meu penúltimo post, entrei en contato com a ISO e o IEC (na verdade com o Gabriel Barta do ITTF), e ele me esclareceu que apenas “recomendou” que os detalhes não fossem revelados e que não pode fazer nada contra isso (nem contra a Microsoft, nem contra este pobre delegado). Além disso me disse que eu posso falar o que quiser, mas mantém a recomendação… Tá bom…obrigado pelo conselho…

E vamos ver o que o Jomar tem a dizer:

Finalmente: os detalhes sobre o resultado do BRM | void life(void)

Para iniciar a história, na reunião de véspera do BRM, os Chefes de Delegação (HoD) foram avisados que na quarta feira teriamos todos que tomar uma decisão sobre o que fazer com as propostas do ECMA que não pudessem ser discutidas.

Vamos entender o que aconteceu: o BRM, que em teoria deveria resolver todos os problemas do padrão em estudo, ao invés de debater todos os problemas do padrão simplesmente fez uma postura de João-Sem-Braço, ignorando a função básica do BRM de alcançar um consenso normativo (como dito anteriormente) ignoraram sumariamente uma massa completa de inconsistências e erros, conforme citado pelo Cezar Taurion da IBM. Desse modo, além de perder-se fundamentalmente o objetivo principal do BRM, fez-se uma espécie de “padronização a toque de caixa” que demonstra que não houve por parte dos principais interessados nesse caso (ECMA e Microsoft) de u debate completo e técnico quanto ao formato.
Continuando, o Jomar explica como é feito o debate das contradições durante o BRM, e mostra uma coisa MUITO interessante:

Finalmente: os detalhes sobre o resultado do BRM | void life(void)

O forma de trabalhar adotada nos dois primeiros dias de reunião (e no papel funciona que é uma beleza), cada um dos países presentes (na verdade os chamados National Bodies ou NBs e se não me engano eram 33) poderiam apresentar para a discussão uma das propostas de seu interesse (ou seja, em ordem alfabética cada um apresentava um problema). O debate então se iniciava e caso fosse muito polêmico, os NBs envolvidos com a discussão eram convidados a discutir “off-line”, colocando o assunto para um backlog. Toda discussão terminava em instruções de alteração para o editor e qualquer coisa que não contivesse “instruções de alteração para o editor” era simplesmente ignorada.
O resultado disso é que até sexta feira, sequer duas rodadas completas foram realizadas (ou seja, houve NB que pode apresentar só uma vez) … explicação: Falta de Tempo (que aliás, explica todas as demais decisões tomadas lá, ok ?). (grifos meus)

Alguns detalhes a ressaltar:

  1. Perceba que cada NB podia apresentar por rodada um único problema. O dilema é: alguns NBs, como o brasileiro, tinham listas enormes de problemas a serem questionados. Mesmo considerando-se a possibilidade de um mesmo problema ser apresentado por vários NBs, como é que todos poderiam ser investigados dessa forma.
  2. O Jomar diz que “qualquer coisa que não contivesse “instruções de alteração para o editor” era simplesmente ignorada“. Ou seja, uma série de fatores que importantes, como a questão do mapeamento de binários entre outros foi simplesmente chutados para escanteio sumariamente. Desse modo, como pode-se alcançar um melhor esclarecimento sobre essas questões? Principalmente em um padrão lotado de artefatos de implementação (wrapLikeWord95 e afins)?

Mas ainda assim as coisas continuam piorando:
Finalmente: os detalhes sobre o resultado do BRM | void life(void)

Durante os debates, algumas discussões acabavam se expandindo e abrangendo mais do que uma resposta (ou as vezes as respostas tratavam de temas coligados) e isso explica o elevado grau de itens discutidos (ou como prefiro chamar “tocados”) no BRM (retirado deste documento, o documento final do BRM): 189 respostas ou 18,4 % do total (isso é que é o que se espera de um debate internacional sobre uma norma de tamanha relevância, não é mesmo… Já imaginou se nossa constituição fosse escrita assim, com apenas 18% das leis discutidas e analisadas ?).

Alguém vai falar: “18,4% não é bom?” Não, não é? Isso é um padrão internacional: em um mundo globalizado, a troca de informações (e portanto de documentos) por meios digitais assumirá cada vez mais uma importante função nas empresas de todos os portes e nos governos, e até mesmo nas relações pessoais. Um formato mal-padronizado, com “minas terrestres de patentes”, cheio de furos técnicos, redundante, e simplesmente complexo demais deveria ser aprovado com tão pouco debate em cima do mesmo? Como o Jomar disse: “Isto significa que especialistas do mundo todo foram a Genebra para resolver apenas 18,4 % de um tremendo problema. O resto (81,6%) foi “dado um jeitinho”.
Mas vocês acham que acabou? Não, ainda tem mais!

Finalmente: os detalhes sobre o resultado do BRM | void life(void)

Aliás, me reservo o direito de não comentar aqui o que levou a aprovação desta proposta [da transformação da especificação em uma Multi-Part standard, na qual o Brazil apresentou uma objeção], que na verdade transforma o OpenXML (ou a DIS 29500) em singelas cinco normas internacionais que poderão ter vida própria (única diferença de cinco normas “tradicionais” é a sua numeração compartilhada, DIS 29500-1, DIS 29500-2 … DIS 29500-5). Lindo isso, não ?

Ou seja, existiram coisas tão atrapalhadas (ou intencionalmente manipuladas), que o Jomar se absteve de comentar. Em uma situação como essa, o que leva a pessoa a se abster, senão um processo terrivelmente mal-feito (ou intencionalmente manipulado).
Agora, vem uma parte importante desse post do Jomar e uma resposta para muitas coisas: de onde a Microsoft tirou a questão dos 98% de aprovação dos comentários ao OOXML?!
Finalmente: os detalhes sobre o resultado do BRM | void life(void)

Quando chegou a quarta feira, nos foram apresentadas quatro opções de “destino” às demais respostas (ou seja, 81,6% do total). Eram apenas quatro opções e uma delas deveria ser escolhida (na hora eu me lembrei do filme “A escolha de Sofia”):
1 – Todas rejeitadas.
2 – Todas aprovadas.
3 – O ITTF decide tudo.
4 – Decisão por voto em lote (com a possibilidade de declaração de voto individual para cada resposta e/ou definição de um voto global, do tipo “aceito tudo”).
Evidentemente que a opção menos ridícula era a opção 4 e por isso ela foi aprovada (no documento final existe uma cópia da cédula de votação). Muito foi debatido sobre a possibilidade de que alguns NBs fizessem votos de bloqueio (como votar tudo sim para forçar a aprovação ou tudo não para desaprovar), mas nada poderia ser feito a este respeito…
Houve um protesto muito interessante de uma delegação que disse que não tinha ido até a Suiça para votar, que poderia fazer isso de casa e a resposta: “Paciência… a vida é assim” .
Outro NB protestou dizendo que só recebeu o documento contendo as respostas para seus próprios questionamentos e não tinha tido a oportunidade sequer de analisar as demais respostas. Por isso foi criada a opção “Não quero registrar uma posição” na cédula. O problema apontado ocorreu com outros NBs e portanto, teve NB que votou em propostas que nunca leu !!! (legal isso, né ?).
(…)
Fiz questão de contar isso apenas para que seja pública a explicação aos 98% de aprovação que certas empresas andam utilizando mundialmente.
Viu como agora os 98% não significam absolutamente nada ? E os 18,4%… estes sim merecem ser debatidos (e explicados por alguém).

Repare aqui a questão: houve uma verdadeira “aprovação em massa” de uma série de questões importantíssimas e que foram simplesmente ignoradas pela ISO. Desse modo, como confiar no OOXML? Como desenvolver para isso? Qual a segurança que temos de que os documentos irão abrir corretamente, mesmo no Microsoft Office 2007? Quais são as garantias que o esforço potencial para desenvolver-se sistemas que abram e manipulem tais formatos não será jogado fora ao perceber-se que os documentos resultantes não abrem ou oferecem informações errôneas em outros sistemas compatíveis com esse formato? Pequenas discrepâncias são aceitas (grave um documento no OOo e abra no Lotus Symphony da IBM e você poderá ter isso), mas quais são as garantias?
A postura brasileira de Dizer NÃO ao OOXML está correta por tudo isso: esse formato é simplesmente horrível e não tem condições de fazer NADA ao que se propõe a fazer. Aprovar o OOXML agora é transformar a ISO em um órgão de “ceder selinhos” para empresas, o que desvritualizaria tudo o que a ISO representa. A ISO não é perfeita (X.25 alguém), mas muitos padrões que ela divulgou foram adotados a partir de um consenso e tornaram-se importantes no mercado (os próprios padrões ISO 9000 são exemplos).
Se o OOXML passar agora, vai ser a submissão da ISO à Microsoft e resultará em um lock-in oficializado, uma vez que até agora, à exceção dos produtos Microsoft, não existe nada que abra os documentos OOXML do MS Office 2007 corretamente. Sendo que atualmente ainda é impossível desassociar o OOXML do MS Office (o que acontece com o ODF em relação ao seu “software de referência”, o OpenOffice.org), temos uma situação como nunca foi vista na ISO: uma única empresa poder oficializar um gigantesco monopólio por meio de um padrão “consolidado de um consenso”.
Quem tem a ganhar nesse caso? O Brasil ou a Microsoft? Sua empresa ou a Microsoft? Você ou a Microsoft?
Pense muito nisso…

Office OpenXML (OOXML) e inapto pela ISO 29500


Powered by ScribeFire.

O que a Microsoft e sites pornô têm em comum?

Pode parecer uma pergunta absurda, mas existe uma relação sim, denunciada pelo pessoal do site open… e pelo pessoal do NoOOXML.com: a prática de Cybersquatting, ou seja, a idéia de, segundo a Wikipedia, “registrar, traficar ou usar um nome de domínio com a má intenção de obter lucros com a boa fê de uma marca pertencente a outros“. Em geral, essa prática é normalmente feita por sites pornôs que (a) tentam obter acessos quando a pessoa digita o nome de um site conhecido de maneira errada ou (b) tentam vender posteriormente os domínios aos verdadeiros detentores da marca registrada em questão por rios de dinheiro. Além disso, há também a prática de scam de redirecionamento, quando você digita uma URL e é redirecionada para outra por meio de scripts. Embora não seja sempre um site pornô e seja uma prática que pode ser legítima (com em sites que mudaram de domínio), ela pode ser usada para levar o usuário a locais indesejados.
Agora, você pode se perguntar: “o que a Microsoft tem a ver com tudo isso?
Ontem, dia 26/03, foi comemorado o Document Freedom Day (Dia da Liberdade de Documentos), ou seja, o dia de defender a liberdade de formatos de documentos e independência de ferramenta ao editar documentos. Para divulgar a iniciativa e criar meios para registrar-se grupos que se organizariam para tomar ações, foi registrado o site http://www.documentfreedom.org.
OK: um grupo conhecido como OpenXML Community (sem links para eles pela sacanagem que fizeram), que se apresenta como “uma comunidade de instituições públicas, empresas, profissionais de tecnologia, acadêmicos e desenvolvedores que suportam o ECMA Office Open XML e (…) acreditam na promoção da escolha, interoperabilidade, inovação e excelência técnica nos padrões de documentos” (conforme o próprio site deles), registrou o domínio http://www.documentfreedomday.COM (perceba o top-level domain comercial, oposto ao .org da iniciativa do Document Freedom Day). Ao tentar acessar essa página, a pessoa era redirecionada a um documento chamado “Dispelling Common Myths About Open XML” (o qual ainda pretendo desmitificar…).
Agora, o que há de errado? É um domínio livre, qualquer um pode pagar para o registrar!“, você pode dizer.
O problema é que justamente quando existe toda uma iniciativa para que o OOXML não seja aprovado (e não por ser da Microsoft, mas sim por ser um formato simplesmente horrível, como eu e vários outros estamos falando a bastante tempo) aparece um grupo realmente astroturf (ou seja, embora aparentando ser algo realmente espontâneo ser algo criado por grupos com os mais diversos interesses) vem tentando minar essa iniciativa por meio de uma técnica que pode ser considerada na melhor das hipóteses um jogo baixo.
Isso reflete muitas questões e mostra os verdadeiros objetivos do OOXML. Como disse anteriormente, toda a questão da ISO é baseada em consensos. Em um processo normal, todas as contradições seriam resolvidas, de modo que o consenso fosse atingido e a votação passasse a ser apenas uma formalização desse consenso formado entre todas as partes. Esse consenso não precisa derivar de um formato perfeito, pois mesmo o ODF não o é, e espaço para evoluções são sempre interessantes.
O problema é que cada vez mais fica claro que a Microsoft não tem como objetivo nenhum consenso ou portabilidade. As “minas terrestres de patentes“, as várias contradições não explicadas, e a confusão entre inter e intraoperabilidade, o fato de um produto não estar sendo usado apenas de formato referência, mas como fundamento para manutenção de falhas graves no formato, devido a escolhas específicas de implementação de recursos (o que é conhecido tecnicamente como artefatos de implementação), e os diversos problemas de “inflação dos NBs” e de obstruções e atritos com aqueles que vão contra o formato OOXML mostra que na realidade a iniciativa de transformar o OOXML em um padrão ISO é apenas uma jogada de marketing da Microsoft:

  • Ela passa a posar de boazinha, mas na realidade pode minar completamente qualquer iniciativa livre de desenvolvimento de parsers e conversores do OOXML para outros;
  • Mesmo que seja possível tais sistemas, eles não teriam o mesmo comportamento que o dos produtos da Microsoft, criando a “dependência de DLLs”, o que em resumo quer dizer que qualquer sistema bom deveria recorrer a DLLs ou bibliotecas da mesma;
  • Cria uma verdadeira aberração jurídica, um lock-in oficializado por meio de um “padrão”;

Como já disse em outros posts e pretendo escrever no futuro com mais tempo: eu não sou contra o OOXML. Ser pró-ODF não é o mesmo que ser contra-OOXML, como foi dito pelo Mark Shuttleworth do Ubuntu (e eu traduzi aqui nesse blog). O grande problema é: o OOXML tem muitas, muitas, MUITAS, MUITAS FALHAS! Existe muita coisa, para dizer o mínimo, estranha no OOXML que simplesmente passou no BRM, devido ao curto tempo e ao tamanho monstruoso da documentação. Artefatos de implementação e coisas bizarras como wrapLikeWord95 (que diz que você deve quebrar linhas como Word 95… sem dizer como isso é feito) e documentos que, uma vez validados contra as DFDs do OOXML ainda assim dão erro (ou seja, existe uma inconsistência entre o formato descrito nas especificações e o descrito pelas DFDs).
Enquanto as coisas estiverem nesse pé, e enquanto a ECMA e a Microsoft não ouvirem as contradições todas e realmente as acertar, concordo com o NÃO dado pelo Brasil, e torço para que outros países sigam a mesma iniciativa. Mas como disse o Jomar, “a guerra continua (e o outro lado está levando a sério a expressão VALE TUDO)“.
Espero que você que esteja lendo entende as coisas e tenha realmente entendido os fatos (sim, a “piada” com Get the facts foi intencional).

Office OpenXML (OOXML) e inapto pela ISO 29500

Powered by ScribeFire.

Está decidido: Brasil mantêm o NÃO ao OOXML. Mas ainda estão surgindo coisas estranhas

O Avi Alkalay da IBM postou ontem a noite e eu replico aqui: o Brasil vai dizer novamente NÃO ao OOXML. E o motivo disso é o mais simples possível: “OOXML is an awful specification“. Ou seja, o OOXML é simplesmente horrível.
O Avi é parte do grupo de estudo na ABNT para o OOXML, junto com outras pessoas que já citei nesse blog, como o Cézar Taurion, o Deivi Kuhn, o Jomar e outros. É interessante ler também a explicação mais detalhada do Avi quanto a essa decisão.

OOXML: Brazil Says NO. Again. :: Avi Alkalay

That outcome was expected because we simply followed the process: technically analyze the OOXML specification, make comments, wait for responses, analyze them and see if all problems were fixed. Is there any single remaining unresolved problem? Vote NO. And in fact there were many many unresolved problems.

Tradução (o Avi posta bastante em inglês, apesar de ser brasileiro):

Esse resultado já era esperado, pois simplesmente seguimos o processo: analisar a especificação do OOXML tecnicamente, comentá-la, esperar respostas, analisá-las e ver se todos os problemas foram corrigidos. Ainda tem problemas sem solução? Vota-se NÃO. E a verdade é que existem muitos problemas não resolvidos.

Isso já foi mencionado em posts anteriores, onde dizemos que existe uma coisa muito importante na questão de padronização, que inclusive é o fundamento básico da existência de órgãos como a ABNT e a ISO, que é o fato de que deve-se obter um consenso antes que um padrão seja adotado. Nesse entender, a votação é apenas uma formalização do consenso, não o consenso em si. O processo de normalização, não importa se comum ou por vias como o Fast-Track adotado pelo OOXML (e pelo ODF, via PAS – Publicly Available Specification), deve ser entendido como um processo onde as partes envolvidas deveriam alcançar o consenso, como bem esclarece os representantes gregos no BRM do OOXML, por meio de Antonis Christofides.
Some clarifications on the OOXML Ballot Resolution Meeting — ΕΜΠ – Τυποποίηση

First, it is important to clarify that the BRM did not say either that the specification is OK, or that it is not OK, because it is not within its competence to say such a thing. There was good co-operation, and, to a large extent, good will, from all sides, because the BRM has a single purpose: make the specification better. Let me repeat that: the BRM has the single purpose of making the specification better, so that if it is accepted, it is the best possible. Or, the same thing viewed from another viewpoint, the BRM attempts to make it better, to maximize its chances of going through. Well, this is in theory, of course; in practice some want to maximize its chances of not going through, and I’m certain that it’s not the first standard in which this happens.

Tradução:

Antes de mais nada é importante deixar claro que o BRM não tem como objetivo determinar se a especificação está pronta ou não, porque esse não é seu objetivo. Havia um clima bom de cooperação e, de maneira geral, de boa vontade de todos os lados. Porque o BRM tem um objetivo simples, que é tornar a especificação melhor. Deixe-me repetir: o BRM tem um objetivo simples, que é tornar a especificação melhor, de modo que caso ele seja aceito ele seja o melhor possível. Ou, vendo as coisas de um outro ângulo, o BRM tenta torná-lo melhor, de modo a aumentar suas chances de ser aceito. Ou ao menos essa é a teoria; na prática alguns tentam aumentar as chances dele ser reprovado, e  estou certo que esse não é o primeiro caso onde isso acontece. (Grifos meus)

A visão dele bate com o que o Avi disse: a idéia é que, por meio dos comentários, sejam avaliado problemas em potencial com o padrão. O problema é que, apesar de tudo o que tem sido postado na Net disendo que o BRM foi um sucesso, a realidade é outra:

Some clarifications on the OOXML Ballot Resolution Meeting — ΕΜΠ – Τυποποίηση

The fact that 98% of Ecma responses were adopted means that the BRM believes that they improve the original text. It does not mean that the BRM believes that the resulting text is OK. My opinion, for example, and many delegates agree with me, is that the Ecma responses make the text slightly better, but though slightly better it is still abysmal.

Tradução:

Some clarifications on the OOXML Ballot Resolution Meeting — ΕΜΠ – Τυποποίηση

Na realidade, o fato de 98% das respostas dadas pela ECMA [NA: órgão que foi o primeiro a adotar o OOXML como padrão e meio que um “patrono” do OOXML] terem sido adotadas quer dizer que elas melhoraram o texto [do padrão], mas isso não quer dizer que ele esteja pronto. Na minha opinião [do Antonis], por exemplo, e muitos delegados concordam comigo, é que as respostas da ECMA tornaram o texto um pouquinho melhor, mas ainda assim ele é horrível.

Desse modo, podemos perceber que o nosso amigo grego concorda com o que o Avi disse: por mais que as coisas tenham melhorado um pouco, o formato ainda assim é horrível.
E ainda assim as coisas podem ficar ainda pior: órgãos nacionais (NBs) como o do Brasil e da Grécia tem procurado o consenso, o mesmo em vários outros. Mas existem órgãos nos quais tudo não passa de votação. Nesse caso as coisas se complicam de vez:
OOXML: Brazil Says NO. Again. :: Avi Alkalay

Technically speaking, if your country’s vote was YES or ABSTENTION, one of these possibilities happened:

  1. Nobody had time to analyze the OOXML specification and the ABSTENTION was the right choice.
  2. Nobody had time to analyze the OOXML specification and a few people decided for you to vote YES, based on ideology or a result of lobby, not technology benefits.
  3. Even having time to analyze the OOXML specification, a few people decided for you to vote YES, based on ideology or result of lobby, not technology benefits.

Traduzindo:

Falando tecnicamente, se um país votou SIM ou ABSTENÇÃO, aconteceu uma das seguintes coisas:

  1. Ninguém teve tempo de analisar a especificação do OOXML e a ABSTENÇÃO foi a melhor opção;
  2. Ninguém teve tempo de analisar a especificação do OOXML e algumas pessoas decidiram votar SIM baseando suas decisões em ideologia ou como resultado de lobby, e não pelos benefícios técnicos;
  3. Mesmo tendo tempo de analisar a especificação do OOXML, algumas
    pessoas decidiram votar SIM baseando suas decisões em ideologia ou como
    resultado de lobby, e não pelos benefícios técnicos
    ;

(Grifos meus)

Ou seja: o que foi feito por vários NBs que votaram a favor do OOXML não foi feito por qualidades técnicas do formato (que devem existir), mas sim por pressão empresarial, lobby ou favorecimento ideológico. Pode-se alegar que o mesmo ocorreu no ODF, mas existem dois fatores que diferenciam esses casos:

  1. ODF não possui uma companhia por trás. Embora a Sun tenha sido a fornecedora do “formato de referência” (o antigo formato Star Office XML), ainda assim ele passou por uma organização de normatização (a OASIS) e foi trabalhada de modo a tornar-se um novo formato, o qual foi publicado e divulgado para análise, sendo que o mesmo foi aprovado por unanimidade na ISO;
  2. ODF é um formato muito menor em tamanho do que o OOXML, e o processo de PAS leva “menos tempo”. Na realidade, leva menos tempo porque, como eu disse anteriormente, ele já vem com um consenso firmado, sendo a votação apenas uma formalização desse consenso;

Agora, ainda assim, existem países que votaram favorável ao OOXML? Sim, como a República Checa. Já outros, como a Polônia, ainda estão em dúvida, mas as coisas ficam ainda mais complicadas quando você analisa o que está acontecendo por trás dos panos:

  • Já existem confirmações de “inflação” dos NBs de vários países com representantes da Microsoft ou partners da mesma que, de outra maneira, sequer saberiam de tudo isso. Exemplos dessa “inflação” são os casos dos NBs de Portugal, Estados Unidos, da Suécia (tendo seu voto invalidado), da Índia (que por incrível que pareça acabou votando NÃO) e da Romênia;
  • A Microsoft vem criando atritos com os seus “opositores” propositalmente: na Romênia, representantes do comitê de estudos do OOXML no NB local que se opunham ao formato foram impedidos de votar;  na Índia, após ter sua posição negada, ela reclamou contra o NB;

Existe muito mais coisas estranhas por aí. É importante ficar atento, pois esse é um formato que é simplesmente horrível, como foi dito pelo Avi.
Fiquemos atentos aos próximos acontecimentos.

Office OpenXML (OOXML) e inapto pela ISO 29500

Powered by ScribeFire.

“Something wicked this way comes…”

Apesar do título, não, esse post não tem nada em absoluto a ver com Harry Potter. Mas como diz a música Double Trouble, “algo sinistro está vindo aí”.
No dia 29 desse mês, haverá a decisão final da ISO sobre a aprovação ou não do formato OOXML como padrão ISO. Como já falei anteriormente, existem coisas que estão extremamente complicadas sobre ele. Já disse também que existe uma série de defeitos técnicos no formato, além de uma série de implicações relacionadas à questão do Open Specification Promise (Promessa de Especificações Abertas) da Microsoft e da Covenant Not to Sue (Acordo Contra Processos) da mesma. Inclusive, recentemente o César Taurion da IBM deixa muito claro isso:

IBM developerWorks : Blogs : Software, Open Source, SOA, Innovation, Open Standards, Trends

Mais, não é só. Também é impossivel alguém dizer que existem 100% de certeza quanto a resolução dos vários problemas de propriedade intelectual que foram encontrados nos documentos Open Specification Promise (OSP) e Covenant Not to Sue da Microsoft. Nestes documentos lêem-se: “claims of Microsoft-owned or Microsoft-controlled patents that are necessary to implement only the required portions of the Covered Specification that are described in detail and not merely referenced in such Specification”. E “promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation to the extent it conforms to a Covered Specification…”.
O que isto signfica na prática? Que a promessa não cobre as especificações que “are not described in detail”, que são muitas; que limita a liberdade de uso à sintaxe da especificação, mas não a “application behavior” que estão espalhados nas suas mais de 6.000 páginas; e não inclui patentes das subsidiárias e afiliadas da Microsoft. E um ponto importantíssimo: a OSP é limitada a atual versão do OpenXML! Fica então a pergunta: o que acontecerá com as próximas e inevitáveis versões da especificação?

Como comentamos anteriormente nesse mesmo blog, e o Taurion ressalta no post dele, é impossível determinar claramente se o OSP e o CNS cobrem software livre. Na realidade, ela já foi considerada insegura pela Software Freedom Law Center para implementações livres do OOXML, e por diversos motivos. Ou seja, como algo que pode ser um verdadeiro “campo minado” de Propriedade Intelectual pode tornar-se um padrão ISO?
Podemos entender isso da seguinte forma. que o Avi Alkalay da IBM apresenta: a Microsoft não está tentando promover interoperabilidade (onde o que importa é o padrão e os produtos disputam entre si para ver qual o melhor), mas sim uma intraoperabilidade (onde o produto é importante e favorecem um produto em detrimento aos demais). Pode parecer uma diferença pequena, mas compare as seguintes imagens que o Avi publicou em seu site:


Esse é um exemplo de Interoperabilidade

Esse é um exemplo de intraoperabilidade

A coisa toda, porém, continua ficando cada vez mais estranha conforme você vai acompanhando os posts. Por exemplo, a Microsoft comemora o fato de que 98% das contradições (problemas) do OOXML tinham sido modificados e aprovados. Até que ponto isso é verdade? E se não foi, por que?

IBM developerWorks : Blogs : Software, Open Source, SOA, Innovation, Open Standards, Trends

(…) Embora alguns digam que a reunião foi um sucesso, com 98% dos comentários sendo resolvidos, indiscutivelmente que a realidade é outra. Cerca de 80% dos comentários não foram sequer analisados e da votação que se seguiu, seis países aceitaram as sugestões do Ecma, quatro foram contra e 18 se abstiveram. Ora 22 países de 26 não votaram a favor da proposta!

E porque? Na minha opinião existem muitos senões que impedem um voto SIM, de forma consciente e profissional. O próprio processo de Fast Track não permitiu que fossem feitas avaliações adequadas da especificação. Para termos uma idéia deste problema, das mais de 6.000 páginas originais (devem ser quase 7.000 agora, depois do BRM…), as entidades de padrões tiveram apenas um curto período de cinco meses para avaliar toda esta massa de documentação. Apesar desta limitação de tempo, foram detetadas 3.522 inconsistências e erros. A Ecma respondeu a estes 3.522 comentários com 1.027 propostas, para serem debatidas nos cinco dias do BRM.
Ora, fazendo uma simples conta, com 6.045 páginas divididas por 1.027, temos um erro a cada 5,8 páginas. Claro que, se houvesse mais tempo, muito mais erros seriam encontrados!

Perceba um fato: essas pessoas que analisaram essa documentação, como o Taurion e o Avi da IBM, o Jomar da ODF Alliance, o Gebara da própria Microsoft, o Deivi Kuhn do SERPRO, nenhum deles é desocupado ou “caiu de paraquedas”. Todos são profissionais competentes, experientes, com dedicação total (ou ampla) para esse estudo. O processo Fast-Track tem sido uma constante dor de cabeça para as pessoas tentarem aprovar esse formato. Você continua ainda assim achando que está tudo OK e que a intraoperabilidade é uma boa idéia? Vejamos o que o Taurion fala sobre isso:

IBM developerWorks : Blogs : Software, Open Source, SOA, Innovation, Open Standards, Trends

A própria proposta da especificação, de produzir um padrão compatível com o Office nos leva a uma situação no mínimo preocupante: uma ferramenta (o Office) definindo um padrão e não o contrário. Imagino como seria se a especificação HTML refletisse as caraterísticas internas do Firefox ou do Explorer…Na minha opinião usar um software específico como modelo de referência obriga a que o padrão seja limitado pelas escolhas técnicas originalmente feitas pelos desenvolvedores do software. O que nem sempre é um bom negócio, principalmente quando o software tem mais de vinte anos de desenho, mantendo dentro de si idéias e algoritmos já ultrapassados pelo tempo…

Ou seja, o que podemos fazer ou deixar de fazer, o que devemos implementar ou não fica restrito por escolhas específicas de uma implementação específica cujo cenário era específico. Por exemplo: como seria uma implementação do OOXML em um ambiente Mainframe? Embarcado? Palms? Nintendo DS? Como seria replicar escolhas específicas feitas em um ambiente Windows para algum desses ambientes? Como proceder para portar recursos?
Mas as coisas continuam piorando:
Segundo o Jomar da ODF Alliance, existe uma espécie de “Lei do Silêncio” cercando os resultados do BRM, o que por si só é estranho, pois ao menos em teoria um processo como esse deveria ser aberto para o público interessado se antenar. Não cabe a mim fazer afirmações de que houve má-fé ou não pois não fui parte em momento nenhum desse processo e estou apenas dando opiniões. Mas percebamos o que o Jomar falou recentemente.

Afinal existe ou não SIGILO sobre o BRM ? | void life(void)

Como delegado Brasileiro no BRM do OpenXML, estou me segurando prá não sair por aí contando os detalhes daquela reunião, pois acredito que todos deveriam saber detalhadamente o que aconteceu dentro daquela sala, para poder entender como existem empresas mal intencionadas e sem limite ético nenhum hoje em dia.
Só para citar um exemplo, soube recentemente que foi utilizado em uma apresentação em um NB (ABNT de algum país), um SLIDE que foi inicialmente apresentado na reunião de encerramento do BRM. Apesar de não poder contar os detalhes, como última participação minha no BRM, pedi em nome da delegação brasileira ao responsável pelo ITTF (ISO/IEC) na reunião – Mr Barta – que o texto do slide apresentado fosse corrigido, pois ele distorcia tudo o que havia sido realizado naquela semana. Imediatamente ele determinou ao autor do slide (Mr. Oh, um japonês secretário do SC34) que aquele slide e aqueles números jamais deveriam sair daquela sala, pois eles não representavam o resultado do trabalho do BRM e também não detalhavam o processo utilizado na reunião.
Quando saí da reunião e cheguei no hotel, descobri que um profissional da empresa proponente já havia publicado na web os dados (e logo em seguida retirado… estranho, né). Para quem não sabe do que estou falando, é do absurdo número de 98% dos problemas resolvidos que a Microsoft insiste em utilizar no mundo todo, cometendo um CRIME cada vez que usam ou apresentam este números.

Para entender: perceba que há realmente uma “Lei do Silêncio”, como o Jomar falou anteriormente, mas que uma pessoa quebrou essa norma de sigilo imposta na reunião. Mas isso apenas piora:

Afinal existe ou não SIGILO sobre o BRM ? | void life(void)

O fato concreto é que fui informado por um colega do Chile, que na semana passada este slide (com o nome do Sr. Oh nele) foi utilizado em uma reunião do NB deles. O slide fazia parte de uma apresentação feita pela Microsoft para demonstrar como tudo estava resolvido no OpenXML. Isto é um CRIME DE VIOLAÇÃO DE SIGILO OU NÃO ?

Ou seja, até que ponto valem essas normas de sigilo? Isso tudo está criando um precedente muito sério, que pode inviabilizar totalmente a credibilidade da ISO. É como a Red Hat publicou recentemente:

Red Hat Magazine | ISO approval: A good process gone bad

For a standards body to have credibility, the procedures it follows need to be credible. ISO’s JTC-1 directives say that the “objective in the development of International Standards should be the achievement of consensus between those concerned rather than a decision based on counting votes.” Clearly, there has been no achievement of consensus regarding the adoption of OOXML as a standard, and therefore ISO has turned to a voting process.

We believe that the flaws in the ISO voting process for OOXML are so serious that they must be addressed in order to maintain ISO’s credibility as a standards body. For a standards body to review a proposal adequately and achieve consensus, the participants need to be involved in the entire review process, not merely show up to cast a vote.

Para aqueles não proficientes no idioma inglês, a tradução:

Para um órgão de padronização ter credibilidade, os procedimentos que ele segue devem ser dignos de credibilidade. As diretivas do comitê JTC-1 da ISO definem que “o objetivo do desenvolvimento de Padrões Internacionais deve ser alcançar o consenso entre todos aqueles que estão envolvidos ao invés de meramente basear tudo na contagem de votos”. Mas claramente não houve nenhum consenso quanto à adoção do OOXML como um padrão, e portanto a ISO tornou-o [a padronização do OOXML] em um processo de votação.
Nós [da Red Hat] acreditamos que o processo de votação da ISO para o OOXML foi algo tão sério que deveria ser questionado de modo a manter a credibilidade da ISO como um órgão de padronização. Para que um órgão de padronização veja uma proposta adequadamente, de modo a alcançar consenso, os participantes devem se envolver no processo como um todo, e não apenas ir lá para votar.
(grifos meus)

Isso tudo vem sendo mostrado a tempos: vários países receberam incentivos da Microsoft para irem lá e simplesmente votarem a favor do OOXML, sem um estudo prévio da proposta. A própria idéia do Fast-Track foi mal executada. Apesar de executivos da Microsoft terem criticado aqueles que criticam isso, lembrando de casos como os do MPEG, é importante lembrar que o MPEG já vinha passando por estudos a muito tempo, de modo que o Fast-Track foi mais uma formalização de um consenso já adquirido fora da ISO (tanto que recebeu bem menos contradições que o OOXML). Além do mais, existe toda uma questão estatística que impede a pessoa de ler um documento como esse, de 6000 páginas, para um padrão novo, pouco conhecido e debatido e extremamente amarrado a um produto específico, com uma série de exigências voltadas especificamente a esse produto, de ser analisado em tão pouco tempo.
Existe toda uma série de paradoxos sobre quais são os objetivos do OOXML, como exemplo, cito dois e dou recursos para uma leitura detalhada sobre eles:

  • Interoperabilidade: existe uma questão relacionada com a falta do mapeamento de binários. Já tratei rapidamente desse assunto no meu blog, mas acho melhor que você vá direto à fonte e entenda melhor essa questão.
  • Customização do formato: aqui o assunto se torna mais sério. Em resumo, a Microsoft afirma que o OOXML permite a expansão do formato por meio do conceito de Custom XML, onde em teoria você poderia implementar suas próprias tags. Até aqui sem problemas, exceto que o pessoal do OOXML is defective by Design descobriu que isso simplesmente não funciona, e que pode chegar a criar um pesadelo de segurança de dados, pois “eventually, confidential information from the corporate databases will end up there, and a PR disaster automatically follows“, ou seja, pode-se fazer inadvertivamente que dados importantes de bases corporativas vazem para dentro desses Custom XML, criando falhas de segurança simplemente grotescas. Recomendo a leitura do artigo para um maior esclarecimento sobre os perigos e problemas do Custom XML.
Simplesmente, as coisas foram feitas de uma forma extremamente arbitrárias, “socando goela abaixo” um formato que é enorme, inchado, voltado a um produto específico, sendo que já existe um bom formato para esse mesmo tipo de aplciação, que é o ODF. Alegações de “temos HTML, XML, PDF, etc…” não colam, pois esses formatos possuem outros objetivos (ou alguém acredita que HTML seja a melhor forma de editar-se documentos de texto?)
Existe um risco monstruoso de que o OOXML possa passar, ainda mais com a pressão que a Microsoft vem fazendo no plano político para que os órgãos nacionais de normatização (NBs) votem a favor. Realmente espero que isso não passe, mas o que posso fazer é assistir e esperar.
Vejamos os próximos lances.

Office OpenXML (OOXML) e inapto pela ISO 29500

Powered by ScribeFire.