1) Não estou interessado em iniciar uma flame war.
2) Não acredito que qualquer coisa que eu disser irá mudar a sua opinião.
3) Estou com preguiça de ler.

Só gostaria de deixar claro que o termo “meia dúzia de revolucionários [...]” não se referia diretamente a você, e reafirmar que o OOXML é um padrão aberto, já que infelizmente as pessoas insistem em mentir e dizer que ele é fechado.

Quanto ao mais, o tempo determinará se o OOXML é bom ou não. No momento tudo é muito prematuro e especulativo, além de terem muitas emoções envolvidas.

Abraços!

André Caldas.

São desvantagens da liberdade. Vejam o Linux, por exemplo, existem trocentas interfaces, vários toolkits gráficos, centenas de formatos de pacote, etc etc, tanta opção que acaba atrapalhando o sistema de certa forma. Mas este é o preço da liberdade.

Vejo que você confunde um pouco a “aplicação” com o “padrão”. Talvez se você reler o meu texto anterior…

Não é problema você ter vários aplicativos diferentes. O problema é ter vários padrões diferentes. Qual é mesmo a vantagem? Enquanto as coisas não são padronizadas, cada um inventa o seu, e isso é uma parte importante do processo de criação. Com a experiência adquirida pode-se criar um padrão que vise atender as necessidades das várias partes interessadas.

O seu exemplo das trocentas interfaces, por exemplo… existe sem dúvida um movimento para padronizar alguns aspectos. Principalmente no que diz respeito à interoperabilidade e portabilidade. Você poderia querer padronizar a aplicação, a cor dos botões, a posição do menu, etc., mas tem gente que iria dizer que o contexto dessa padronização (ou uniformização) do ambiente pertence ao escopo do ambiente gráfico e não deve constar do padrão. Isso funciona como qualquer ciência, você faz experimentos (implementa novas idéias) e depois tenta organizar o conhecimento adquirido em uma teoria (padrão).

No caso específico dos ambientes gráficos, me parece interessante que a API de cada serviço oferecido seja padronizada. Assim, conseguiríamos maior portabilidade. Os programas poderiam ser implementados utilizando essa API, e automaticamente funcionariam em qualquer ambiente gráfico. Isso é bom para o desenvolvedor, que não precisa fazer retrabalho para que seu aplicativo funcione em diversos ambientes. É bom para o mantenedor, porque o código seria mais enxuto e conseqüentemente mais fácil de manter e menos propenso a ter falhas. É bom para o usuário, porque além de maior qualidade de código resultante dos fatores citados, a portabilidade garante maior disponibilidade de aplicativos. Essa disponibilidade de aplicativos seria uma faceta da liberdade de escolha (o usuário poderia escolher o ambiente de que mais gostasse) proporcionada pela padronização da API. Quanto mais padrões, menor a liberdade de escolha – se a sua escolha de ambiente gráfico não for compatível com a escolha da biblioteca utilizada pelo desenvolvedor, então você não pode utilizar o aplicativo, a menos que você opte por utilizar o mesmo ambiente gráfico que ele utiliza!

Eu realmente acredito que o processo de criação não deve começar com a padronização, e que não se deve padronizar nada que não seja maduro o suficiente para atender as necessidades de todas as partes interessadas. E é isso o que acontece com tudo o que você cita acima! Acredito que a existência do Gnome e KDE, entre outros, aumenta minha liberdade de escolha, mas a falta de interoperabilidade entre eles, por outro lado, limita essa liberdade. Eu em particular, não utilizo nenhum aplicativo que comesse com “K”. Não seria esse o fato, se as essas interfaces utilizassem uma API comum. Acho que quando tudo estiver mais maduro, teremos muito mais liberdade de escolha, justamente porque todas as interfaces seguirão o mesmo padrão. Nesse dia, o Kxxx, quando executado na minha máquina vai se parecer exatamente com um aplicativo bem integrado ao meu ambiente.

Quanto aos pacotes, acontece o mesmo. Eles vão amadurecendo e a portabilidade vai aumentando. Espero que um dia, eu possa fazer um projeto, e sem muito trabalho, quando eu escrever “make deb”, terei um pacote no formato “deb”, e quando escrever “make rpm” terei um “rpm”. Todos os vários tipos de pacotes serão automaticamente gerados através de informações guardadas em um certo XML. Eu como desenvolvedor precisarei saber apenas a semântica desse XML, e não a de cada formato de pacote separadamente. Quem sabe, se eu escrever “make publish”, todos os pacotes suportados serão gerados automaticamente, assinados e publicados no meu website!!

Mas devo esclarecer uma coisa… nada do que você citou acima é padrão ISO!! Se você quiser falar de CSS, HTML, HTTP, SMTP, POP, DNS, etc… aí poderemos conversar sobre a mesma coisa, mas enquanto você ficar misturando as idéias, nada vai funcionar.

Mais detalhes sobre interoperabilidade entre ambientes gráficos: Free Desktop.

E não existem tantos erros assim, a maioria dos supostos erros são questões de implementação, algumas pessoas concordam e outras não.

Sim, e não. Não sei bem do que você esta falando. Se é do padrão, existem sim, muitos defeitos.

Agora se você esta falando dos aplicativos que irão implementar os diversos padrões, obviamente que são questões de implementação! Porque você não diz algo mais óbvio? Era exatamente o que eu estava dizendo. O que acontece, é que quanto mais complexo o sistema é, mais bugs – de implementação, óbvio – terá! Já ouviu falar em KISS?

Um exemplo é… imagine que você está desenvolvendo uma página em HTML que você quer que rode em “todos” os navegadores, inclusive o IE4. Suponha que você tem disponível a documentação completa do javascript, css e html de cada um desses navegadores. Agora imagine todos os hacks que você terá que implementar para fazer essa página funcionar! O que é mais fácil? Desenvolver para um padrão, ou para vários? Qual página vai ter mais bugs? A sua, ou a minha que será implementada para funcionar nos navegadores que seguem os padrões internacionais? Certamente que os usuários que não utilizam o mesmo IE6 que você usou para testar sua página terão problemas em acessá-la, e fatalmente serão obrigados a utilizar o mesmo navegador que você. Onde fica a liberdade de escolha?

A qualidade do código, ou da biblioteca, irá ser bastante influenciada pela complexidade. Imagine o código de um navegador que tem que se comportar de maneira diferente para cada tipo de informação sendo acessada? O comportamento desse navegador é previsível?

E daí que a especificação tem 6000 página? Poderia ter até mais, ninguém espera simplicidade de um padrão composto por 4 formatos preparados para serem usados por centenas de milhões de pessoas no mundo inteiro.

Desculpe, mas eu espero. O ODF, que foi preparado para ser usado por centenas de milhões de pessoas, tem 722 páginas, e pelo que você disse, o OOXML chegou a 8000!! Espero que o OOXML seja ao menos 10x melhor. :-)

O OpenXML já está em todo lugar, no seu Mac, no seu PC, no seu bolço, no seu navegador web, todo mundo está implementando o OpenXML, antes mesmo dele ser um padrão ISO, você vê uma dificuldade que simplesmente não existe.

Não sei se você reparou, mas a sua resposta ao meu comentário não respondeu nada! (veja no final do texto sobre suas falácias)

De qualquer modo, me parece que você vê a questão da interoperabilidade como um problema muito longe do cidadão comum. É mais um problema entre grandes empresas. Pois eu não vejo dessa forma. Para usar o ODF, ou OOXML, eu não preciso estar criando um “office”! Ou posso simplesmente estar fazendo uma biblioteca para gerar documentos no meu site. Por exemplo, eu posso gerar um relatório de alguma coisa bem simples. Para compor o meu relatório, eu posso querer gerar uma planilha com um gráfico. Isso não é para “grandes”. Um mero mortal como eu pode fazê-lo.

Eu me lembro que na época que conhecia pouco sobre software livre… na época em que era usuário do “Linux”, e não do “Stallmanix”, como sou hoje, eu achava que era muito mais fácil desenvolver meus aplicativos. Tinha um site na internet e lembro ter desenvolvido meu próprio servidor HTTP. Foi uma experiência bem bacana. Tive que ler o padrão (uma RFC) e implementar de acordo. Não foi difícil… felizmente o RFC não tinha 8000 páginas!

Eu prefiro acreditar na experiência da Microsoft na área de suites para escritório do que na opinião de meia dúzia de revolucionários anti-Microsoft que nunca escreveram uma linha de código.

Claro que as pessoas que não concordam com sua opinião são simplesmente “revolucionários anti-Microsoft”. É interessante você dizer isso, porque todos os meus argumentos foram bem embasados. Ao contrário dos seus, que estão incorretos por compararem “aplicativos” com “padrões”, mostrando como você entende pouco do que está falando (ou simplesmente quer desviar o rumo da discussão). Outros argumentos seus foram mais no estilo “e daí!”. Releia seus argumentos e veja como são genéricos e poderiam ser aplicados em qualquer tipo de discussão.

Por exemplo, quando você diz que as pessoas que não concordam com você são revolucionários que nunca escreveram uma linha de código, você esta usando um argumento um tanto quanto genérico. Em primeiro lugar, você não conhece essas pessoas. É um argumento genérico que pode ser usado em qualquer discussão sobre software quando as pessoas não concordam com você.

O mais interessante, é que além de você criticar as pessoas que “nunca escreveram uma linha de código”, você considera que desenvolvimento é para poucos… apenas os que tiverem capacidade e recursos para ler 8000 páginas de documentação. Como você critica uma pessoa que supostamente se comporta exatamente da maneira que você espera? Se você não acredita que eu vá ter interesse em desenvolver algo que suporte o padrão, porque critica aqueles que não desenvolvem?

Me chamar de “meia dúzia de revolucionário anti-Microsoft” é uma falácia chamada Ad hominem. Você poderia ter tentado ir direto ao ponto, e mostrar como meus argumentos são falhos… assim como fiz com os seus!

Outra falácia é quando você fala sobre gerenciamento de pacotes, etc, que não tem nenhuma relação com “padrões internacionais”. Essa eu procurei na wikipedia e chama-se Ignoratio elenchi.

Mais uma: Argumento de autoridade. Quando você fala da Microsoft. Sim, tudo está OK, porque a Microsoft é uma empresa com muita experiência e competência. Essa não foi muito séria, porque você simplesmente disse que prefere confiar na M$. Mas eu interpretei como se a opinião de “meia dúzia de revolucionários” não importasse, independentemente do argumento, pois a Microsoft tem autoridade.

Não vou me estender mais por que essa mensagem já está muito longa. De qualquer modo, não se esqueça que essa discussão tem muitas facetas. Não se discute simplesmente se o OOXML tem problemas ou não. O que se discute é:
* É necessário o OOXML ser um padrão ISO?
* Houve irregularidades no processo?
* O OOXML tem muitos defeitos que deveriam ser corrigidos antes de ser considerada sua adoção como padrão?
* Não seria mais correto que o ODF fosse melhorado para incorporar as supostas deficiências que supostamente tornam o OOXML necessário?
* A intenção do OOXML é garantir o que a Microsoft, incorretamente, chamou de “compatibilidade descendente” com os outros formatos office. Esse objetivo pode ser realmente atingido com essas 8000 páginas? Como, se a especificação não diz como interpretar o conteúdo dos formatos “legados”?

André Caldas.

Erick, já existia m padrão, aberto e de qualidade. Acho que somente isso joga seu discurso no lixo.

Quem perde são os programadores, para desenvolver aplicações que usem o OOXML vamos ter que apelar para bibliotecas muitas das vezes caras.

Implementar o OOXML sem o uso delas é inviável, tente você.

“Frase interessante dita por um idiota, que com certeza não sabe de bulhufas e não deve ter mais de 15 anos, é chegada a hora de deixar de ser criança e entender que negócio é negócio, as empresas são livres para escolher o padrão, não serão forçadas, ainda mais que o ODF também é padrão não esqueçam disso!”

Tem certeza??? Com a base de súíte MS Office instalada em 99% dos computadores, e com um formatato fechado homolagado que não interopera bem com nada? Onde está a concorrência? Como concorrer?? Você adora chamar todos de crianças e idealistas, que ideologia não enche barriga, como se todo mundo aqui fosse comunista ou sustentado pelo pai…Acho que criança é você, ainda mais ingênua. Qualquer pessoa sabe que a MS comprou a especificação. Se você é a favor dela, da MS, ao menos seja síncero.

Essa é a frase pronta mais ridícula e mais utilizada…

Os usuários precisam de escolha de aplicativos, e não de padrões. Qual seria a utilidade de poder escolher entre “metros”, “milhas” ou “polegadas”?
- Por favor, qual é a distância até o ponto-de-ônibus?
- 0,2 milhas!
- E quanto é isso em metros?
- Converter entre os vários padrões é problema seu.
Muito útil essa liberdade de escolha!

Para os desenvolvedores isso é muito ruim, porque precisam trabalhar o triplo e criar aplicativos muito maiores e consequentemente com muito mais bugs, simplesmente para TENTAR implementar os diversos padrões.

São desvantagens da liberdade. Vejam o Linux, por exemplo, existem trocentas interfaces, vários toolkits gráficos, centenas de formatos de pacote, etc etc, tanta opção que acaba atrapalhando o sistema de certa forma. Mas este é o preço da liberdade.

E não existem tantos erros assim, a maioria dos supostos erros são questões de implementação, algumas pessoas concordam e outras não. Eu prefiro acreditar na experiência da Microsoft na área de suites para escritório do que na opinião de meia dúzia de revolucionários anti-Microsoft que nunca escreveram uma linha de código.

Além disso, o padrão foi atualizado para corrigir diversos erros apontados pela ISO, e 2000 páginas de correções foram anexadas ao processo.

Sem contar que esta é apenas a primeira versão, com certeza o OOXML irá melhorar bastante conforme a especificação for recebendo novas versões.

A especificação: de só uma olhada na foto!

E daí que a especificação tem 6000 página? Poderia ter até mais, ninguém espera simplicidade de um padrão composto por 4 formatos preparados para serem usados por centenas de milhões de pessoas no mundo inteiro.

Quem lhe disse que a M$ irá seguir o padrão ISO? Quem lhe disse que se você implementar TODO o padrão será capaz de ler e interpretar todo o conteúdo de outros documentos que também seguem o padrão? Isso não é verdade para o OOXML.

O iWorks’ 08, da Apple, já é compatível com o OpenXML. Ou o iPhone e iPod touch, que suportam a leitura de OpenXML pelo Safari Mobile. Ou o Zoho Writer, um programa web-based bastante prominente, similar ao Google Docs, que também suporta o OpenXML (leitura e escrita).

O OpenXML já está em todo lugar, no seu Mac, no seu PC, no seu bolço, no seu navegador web, todo mundo está implementando o OpenXML, antes mesmo dele ser um padrão ISO, você vê uma dificuldade que simplesmente não existe.

Agora, a Microsoft conseguir que um padrão com trocentas falhas, problemas de patentes e de implementação seja homologado pela ISO, realmente, vemos que tudo é realmente movido só pelo dinheiro, a força econômica venceu, uma empresa que era tida como referência virou motivos de piada e zombaria, além do próprio padrão que ninguém conseguirá implementar, nem mesmo a Microsoft. Fico triste.

Espero sinceramente que o Brasil NÃO adote o OOXML, pois a ABNT votou levando em conta a parte técnica e viu as falhas e problemas de adoção dele como norma ISO, além de se ter o ODF já devidamente escrutinado, analisado e realmente aprovado pela sua qualidade técnica irrepreensível.

As pessoas desconhecem os princípios que regem a idéia de se ter padrões, até as mais tecnicamente capacitadas. Sobrevivem com padrões de tomadas diferentes e acham que é a mesma coisa que ver formatos diferentes de cartão de visita, por exemplo.

Um padrão é muito mais complexo que um formato. É, digamos, um “meta-formato”, uma referência, um paradigma… um padrão!

Todos os outros formatos podem parecer o que quiserem, mas sabem que o padrão está lá e que devem convergir para ele em algum momento, mesmo que em parte.

Por isso essa idéia da Microsoft de um padrão que atenda 100% o legado dos diversos Offices que existiram além de impraticável é uma balela dispensável. O que importa é conseguir ler o conteúdo e reproduzir as fórmulas. Perder a formatação de parágrafo daquele arquivo em Word 98 é uma problema menor frente ao universo de normatizações futuras possível… E isso o ODF já faz, e bem.

Vi na especicação do ODF que ele busca ser compatível com outras mídias é padrões, como o SMIL e arquivos de biblioteconomia, uma interoperatividade que a Microsoft nunca sonhou ou quis para si, seus produtos e formatos de arquivos. Imagine fazer um único arquivo em ODF e poder compatibilizá-lo com um formato multimídia do Quicktime ou diretamente com um servidor de indexação de artigos como o Sloan, do MIT?

A Microsoft ganhou e vai levar porque muito profissional bom não conhece o significado de ter um padrão e, pior, o que isso poderia significar nas implementações futuras de suas soluções.

André Caldas.