Conferência eLearning Lisboa 2007
Estive ontem na conferência eLearning Lisboa 2007. Fui convidado para participar num Workshop sobre Standards e Interoperabilidade e no qual tive a companhia do Diogo Rebelo, da DRI. Estiveram cerca de 40 pessoas nesta sessão e o conteúdo discutido foi muito bom. Falou-se em standards e formatos, principalmente na área de eLearning, falou-se de Software Open Source, falou-se de Software proprietário, falou-se muito de interoperabilidade, entre outros temas.
Achei o debate interessante porque fez-me ver que existem áreas onde se fizeram grandes progressos em termos de interoperabilidade e outras áreas em que qualquer acordo é perfeitamente impossível.
Falou-se, por exemplo do Sugar CRM, e do acordo que assinou com a Microsoft - https://www.sugarcrm.com/crm/about/press-releases/20060214-microsoft.html
Falou-se, da Zend, do Moodle, do blackboard, entre outros
Falou-se, igualmente, sobre formato de documentos. E nesta área será muito difícil atingir um acordo ou mesmo consenso. Por um lado temos a Microsoft, que na sua última versão do Microsoft Office 2007 adoptou o formato Open XML. Do outro a lado, temos a IBM (não tanto a SUN) que se quer relançar nesta área adoptando o ODF como formato para a sua suite de produtividade.
Apesar disto, existe algum software já desenvolvido que faz a conversão nos dois sentidos para os dois formatos. https://odf-converter.sourceforge.net/features.html
Todos conhecemos histórias de muito standards que nunca foram massivamente utilizados. O mercado é quem vai ter a última palavra!
Comments
Anonymous
January 01, 2003
Marcos, "Isto é o mesmo que dizer "sabes mas não te serve de nada". Se não serve de nada não devia estar na especificação." Estou de acordo com o Victor. Pode servir, mas em casos especificos!Anonymous
January 01, 2003
Marcos, Eu nunca disse que nós não iríamos falar abertamente sobre o tema. Iremos continuar a falar e será o tema do meu próximo post. Relativamente ao tema do debate, o que lhe posso dizer é que não havia condições para a nossa participação, já que "foram feitas acusações pessoais a colaboradores da Microsoft". O Marcos sabe quem fez essas acusações... Como sempre disse, o conteúdo é válido, a forma é que é discutível. Relativamente ao seu comentário sobre o Open XML, o meu próximo post é só sobre esse tema. Mas respondo-lhe da seguinte forma:
- "a não implementabilidade do formato numa plataforma não-windows" - ver http://en.wikipedia.org/wiki/OOXML#Adoption
- "implementar o uso de binários dentro do "XML" ou a existência de tags como um autoSpaceLikeWord95 ou useWord97LineBreakRules..." - retro compatibilidade
Anonymous
January 01, 2003
Marcos, Não percebi o seu post. Eu fui convidado para falar sobre standards e interoperabilidade no eLearning. Falamos de SMI, SCORM entre outros. Como era um Workshop, o publico podia participar e alguém na audiência fez um comentário sobre formato de documentos e foi ai que tanto eu como o Diogo Rebelo defendemos, cada um , o seu ponto de vista. A minha resposta mantêm-se e vai-se manter até ao final de Fevereiro.Anonymous
October 16, 2007
Engraçado, estava eu convencido que como "durante o processo de normalização do Open XML, que ainda está a decorrer, foram feitas acusações pessoais a colaboradores da Microsoft", "acusações publicas em jornais e blogs sobre a reputação e integridade dos mesmos" que a a Microsoft Portugal achava "que não existem condições para a [v]ossa participação" em debates sobre esta temática... Afinal a disponibilidade depende do público alvo.Anonymous
October 17, 2007
que estranho, mas o vosso formato não é aberto, interoperável? então para quê um conversor? "última versão do Microsoft Office 2007 adoptou o formato Open XML." até aqui faltam à verdade, desde quando é que o m$-office 2007 implementa o ooxml? implementa um subset xml, não o ooxml apresentado quer à ECMA e por sua vez à ISO. ai ai, não consegue dizer uma certaAnonymous
October 17, 2007
The comment has been removedAnonymous
October 17, 2007
Mind Booster Noori "o OOXML não é aberto mas por várias outras falhas, como por exemplo a não implementabilidade do formato numa plataforma não-windows, o facto de implementar o uso de binários dentro do "XML"" Já agora podes explicar-me o que é que o elemento Office:Binary-data faz no ODF? http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1.pdf E porque é que o seu objectivo é diferente do do OOXML? Em relação às restantes tags, penso que o nome dirá tudo, serão importantes para o rendering dos documentos, não torna refém o seu conteúdo... mas mais importante é que, se tu como implementador utilizares o que está especificado, os utilizadores da tua aplicação vão criar novos documentos e estas tags não serão utilizadas, se tiveres de ler documentos do Office criados nestas versões antigas podes na mesma tentar apresentá-los da forma que considerares adequada. Aliás se reparares nenhum dos formatos hoje tem solução para garantir o rendering 100% fiel entre diferentes aplicações... As tags de retro compatibilidade tenderão a desaparecer com o tempo imagino eu. por isto tudo não consigo perceber as tuas preocupações.Anonymous
October 17, 2007
Victor: A especificação do OOXML tem notações platform-specific (o que vai contra o objectivo de um standard) e notações binárias, como o DEVMODE, que não cumprem com os requisitos de um documento XML. Usar base64 encoding (como o ODF) cumpre com os requisitos de um documeto XML. Quanto às tags não especificadas, o argumento "o nome diz tudo" é estranho, porque para isso não haviam especificações, certo? Se existe uma tag chamada lineWrapLikeWord6 mas não a especificação de como se implementa, eu não posso desenvolver um programa que implemente a leitura de um documento OOXML convenientemente, visto que não sei (não está na especificação!) como o fazer. Sim, posso tentar "adivinhar", mas se não posso fazer nada além de adivinhar, então é porque a especificação está incompleta, e visto que só a Microsoft sabe como implementar tais tags, o formato está fechado a todos que não a Microsoft ou a quem a Microsoft ceder a especificação para estas tags. A Microsoft insiste em dizer que um dos objectivos do OOXML é garantir backward compatibility com os seus formatos anteriores, mas estas tags em vez de eliminarem este tipo de dados deprecated, está a manter uma dependência aos produtos da Microsoft, visto que só eles saberão ler estas tags convenientemente.Anonymous
October 17, 2007
Mind Booster Noori: "A especificação do OOXML tem notações platform-specific (o que vai contra o objectivo de um standard) e notações binárias, como o DEVMODE, que não cumprem com os requisitos de um documento XML. Usar base64 encoding (como o ODF) cumpre com os requisitos de um documeto XML." O OOXML também utiliza a mesma forma do ODF para embeber elementos binários. Em relação à estrutura que mencionas, até poderiam ser omissos, e na realidade noutras plataformas podes ignorá-la completamente. Mas para mim (e não sou o único certamente) o mais importante é que continuas a ter acesso ao conteúdo, e na tua argumentação isso é sempre esquecido, já que continuamos a discutir aspectos puramente aplicacionais... "então é porque a especificação está incompleta" Se formos entrar por aí é também fácil perceber que o ODF não é o melhor exemplo, consideras o standard aprovado uma boa especificação? Então porque ainda hoje, não consegues ter documentos reproduzidos de forma fiel em diferentes aplicações? Eu respondo, porque é omisso em muitas áreas deixando ao critério da aplicação a decisão de decidir sobre essas omissões. "e visto que só a Microsoft sabe como implementar tais tags, o formato está fechado a todos que não a Microsoft ou a quem a Microsoft ceder a especificação para estas tags." Vou tornar a repetir, se criares os teus documentos com esta especificação nunca vais ter que lidar com tags desconhecidas, assim como nos documentos novos criados pelo Office. "mas estas tags em vez de eliminarem este tipo de dados deprecated, está a manter uma dependência aos produtos da Microsoft, visto que só eles saberão ler estas tags convenientemente." Vou repetir, não necessitas do Office nem de nenhum produto da MS para ler estes documentos. O importante como algumas vezes referes neste ficheiros é efectivamente o seu conteúdo... e esse qq implementador vai ter acesso e vais ver que não vai ter problemas em o representar... e só estamos a falar destes documentos com estas tags, porque os novos não as terão e por isso a tua preocupação deixa de fazer sentido.Anonymous
October 18, 2007
"O OOXML também utiliza a mesma forma do ODF para embeber elementos binários." Sim, a forma /correcta/ segundo a especificação de XML. O problema é que não usa só essa... "Em relação à estrutura que mencionas, até poderiam ser omissos, e na realidade noutras plataformas podes ignorá-la completamente." Se essas tags não servem para nada, então em vez de serem omitidas nas implementações, elas devem ser excluídas da especificação. Mas o problema é que essas tags servem para alguma coisa, mas só vocês é que sabem o quê e como o fazer. Grande "standard aberto", hein? "Mas para mim (e não sou o único certamente) o mais importante é que continuas a ter acesso ao conteúdo, e na tua argumentação isso é sempre esquecido, já que continuamos a discutir aspectos puramente aplicacionais..." Não são aspectos "aplicacionais", mas pode dizer que são "aspectos visuais". Deixe-me só relembrar que um formato de documentos não serve para representar "o conteúdo dos documentos", mas sim "os documentos", incluindo a sua forma. Esse é, inclusivé, um dos aspectos fulcrais nestas questões para áreas como por exemplo a da preservação documental, em que é igualmente importante a preservação da forma e do conteúdo. Se quisessemos apenas o conteúdo e a forma fosse irrelevante, então não precisaríamos documentos estruturados e não precisaríamos de standards: usam-se ficheiros .txt! "[O ODF] é omisso em muitas áreas deixando ao critério da aplicação a decisão de decidir sobre essas omissões." Exemplos? "Vou tornar a repetir, se criares os teus documentos com esta especificação nunca vais ter que lidar com tags desconhecidas, assim como nos documentos novos criados pelo Office." Se a especificação diz que os documentos OOXML podem ter essas tags, então para suportar totalmente o formato ter-se-à de suportar as ditas tags. Se elas não são importantes, como tenta fazer crer, então eliminem-se tais tags da especificação. Descreva isto da forma que quiser, mas a verdade é incontornável.Anonymous
October 18, 2007
"O OOXML também utiliza a mesma forma do ODF para embeber elementos binários." Sim, a forma /correcta/ segundo a especificação de XML. O problema é que não usa só essa... "Em relação à estrutura que mencionas, até poderiam ser omissos, e na realidade noutras plataformas podes ignorá-la completamente." Se essas tags não servem para nada, então em vez de serem omitidas nas implementações, elas devem ser excluídas da especificação. Mas o problema é que essas tags servem para alguma coisa, mas só vocês é que sabem o quê e como o fazer. Grande "standard aberto", hein? "Mas para mim (e não sou o único certamente) o mais importante é que continuas a ter acesso ao conteúdo, e na tua argumentação isso é sempre esquecido, já que continuamos a discutir aspectos puramente aplicacionais..." Não são aspectos "aplicacionais", mas pode dizer que são "aspectos visuais". Deixe-me só relembrar que um formato de documentos não serve para representar "o conteúdo dos documentos", mas sim "os documentos", incluindo a sua forma. Esse é, inclusivé, um dos aspectos fulcrais nestas questões para áreas como por exemplo a da preservação documental, em que é igualmente importante a preservação da forma e do conteúdo. Se quisessemos apenas o conteúdo e a forma fosse irrelevante, então não precisaríamos documentos estruturados e não precisaríamos de standards: usam-se ficheiros .txt! "[O ODF] é omisso em muitas áreas deixando ao critério da aplicação a decisão de decidir sobre essas omissões." Exemplos? "Vou tornar a repetir, se criares os teus documentos com esta especificação nunca vais ter que lidar com tags desconhecidas, assim como nos documentos novos criados pelo Office." Se a especificação diz que os documentos OOXML podem ter essas tags, então para suportar totalmente o formato ter-se-à de suportar as ditas tags. Se elas não são importantes, como tenta fazer crer, então eliminem-se tais tags da especificação. Descreva isto da forma que quiser, mas a verdade é incontornável.Anonymous
October 18, 2007
The comment has been removedAnonymous
October 18, 2007
"No caso do DEVMODE obviamente que que é dependente da plataforma, mas não é obrigatória a sua utilização." Certo, ninguém é obrigado a criar um documento com isso, mas se alguém criar todos os leitores deviam ter a liberdade de conseguir ler essas partes desses documentos. Não o conseguindo, a implementabilidade do OOXML é limitada. "nestas versões dos formatos nenhuma delas consegue fidelidade a 100% entre implementações, e isso é verdade quer para o ODF quer para OOXML, que num caso garante os melhores resultados no codebase do Oo e derivados e no outro ao MS Office." Isto não é verdade. O ODF explicita e descreve todas as tags de apresentação passíveis de ser utilizadas, incluindo como devem ser interpretadas, pelo que qualquer pessoa pode implementar um programa que seja fiel à implementação. Já o mesmo não é verdade no caso do OOXML. "http://testsuite.opendocumentfellowship.org/summary.html" Acho que não leu bem o link que referiu... Deixe-me destacar os factos "Most documents has associated rendering samples created with: OpenOffice; KOffice on Linux" e "please note that uncertain or untested results are not counted, so the totals may not add up to 100%". "Suporte para formulas por exemplo" http://wiki.oasis-open.org/office/About_OpenFormula <- ler "Myth #2" "a forma como chegas à justificação de um parágrafo" Isto não é verdade, não só está especificada a forma como se faz a justificação, como o ODF suporta um tipo de justificação que o OOXML não suporta: Segundo ohttp://odf-converter.sourceforge.net/features.html#hUnsupportedDOCX o OOXML não permite "Last line alignment in justified paragraph". "Onde não concordamos é que nesta área de aplicações de produtividade, reduzir as coisas a um único formato, o ritmo da inovação seria definitivamente reduzido, e para especificações perfeitas não precisas de mais do que uma aplicação... é isso que preferes? Olha eu não, mas devo ser só eu..." Haver um único formato usado para todos, em que todos contribuem para a evolução desse formato é produtivo e incentivador de inovação: toda a gente a trabalhar para o mesmo lado. Você não acredita nisso, posso saber porquê? Quanto a especificações perfeitas, infelizmente não as há, mas quantas mais pessoas trabalharem para elas, todas no mesmo sentido, melhores elas ficam... Quanto ao número de aplicações a existir, obviamente que mesmo que houvesse um formato perfeito, nunca poderia haver uma aplicação perfeita, porque há utilizadores que gostam mais das coisas de certa forma e outros que preferem as coisas de outra forma. Haver apenas uma aplicação passível de implementar um formato faz desse formato um não-standard. "não é necessário suportar a especificação a 100%, porque eu na minha aplicação posso não querer disponibilizar todas as funcionalidades, ou eu, lá porque quero criar um processador de texto tenho que replicar um word?" Mais um Microsoft Word? Por favor, não! Mas obviamente que uma aplicação que LEIA documentos tem de saber lê-los BEM, e só poderá fazê-lo se souber ler e implementar TODA a especificação. Mais do que isso, o que está em causa não é o senhor que "pode não querer disponibilizar todas as funcionalidades", é o outro senhor que "quer disponibilizar todas as funcionalidades e não pode". O OOXML é assim defensor da tal "aplicação única" que você tanto advoca abominar.Anonymous
October 18, 2007
"Não o conseguindo, a implementabilidade do OOXML é limitada." Por acaso atés sabes o que a estrutura possui, está documentado, não te serve é para o mesmo, e no teu caso podes decidir ignorar, mas é decisão tua. "Isto não é verdade. O ODF explicita e descreve todas as tags de apresentação passíveis de ser utilizadas, incluindo como devem ser interpretadas, pelo que qualquer pessoa pode implementar um programa que seja fiel à implementação. " Ainda não explicaste porque é que uma especificação tão completa e com tanto tempo de vida, ainda não nos permitiu ver diferentes aplicações com representações 100% iguais... Continua à espera de exemplos. "Acho que não leu bem o link que referiu... Deixe-me destacar os factos "Most documents has associated rendering samples created with: OpenOffice; KOffice on Linux" e "please note that uncertain or untested results are not counted, so the totals may not add up to 100%"." Li li, eu nem sequer me preocupei com a percentagem, fui directo às partes que dizem: is not supported in OpenOffice is not supported in KOffice "http://wiki.oasis-open.org/office/About_OpenFormula <- ler "Myth #2" Não é um mito, exemplo disso é o nascimento do OpenFormula que infelizmente não faz parte do standard ISO... http://www.tbray.org/ongoing/When/200x/2005/10/01/Open-Office-Conference E a sintaxe a utilizar nas implementações actuais ou é partilhada e conhecida ou a possibilidade decidir como definir as formulas é do próprio implementador. "Segundo o http://odf-converter.sourceforge.net/features.html#hUnsupportedDOCX o OOXML não permite "Last line alignment in justified paragraph"." É preciso não apenas ler, mas interpretar, estás a comparar formatos diferentes, obviamente que possuem muita funcionalidade semelhante e muitas outras não possuem equivalência, mas é natural ou não? Mais uma vez é para andarmos a fazer todos o mesmo, sendo que as únicas diferenças são o ambiente de trabalho, que poderia variar de aplicação para aplicação? http://odf-converter.sourceforge.net/features.html#unsupportedODT "Haver um único formato usado para todos, em que todos contribuem para a evolução desse formato é produtivo e incentivador de inovação: toda a gente a trabalhar para o mesmo lado. Você não acredita nisso, posso saber porquê? " Se isso fosse verdade, sabes quantas pessoas participaram em 75% das reuniões do OASIS para a definição do ODF? 2 pessoas, chamas a isso participado e inclusivo? Podes ir ver às actas. "Mais um Microsoft Word? Por favor, não!" Falei do Word por ser o melhor, mas podia dizer o Writer, que era a mesma coisa. "Mas obviamente que uma aplicação que LEIA documentos tem de saber lê-los BEM, e só poderá fazê-lo se souber ler e implementar TODA a especificação. " E pode fazê-lo e ainda assim decidir o que quer tratar ou não (depende sempre dos requisitos) e pode e deve informar o utilizador sobre as suas limitações. Repara, crias documentos NOVOS com tudo o que está especificado, outra aplicação pode ler o teu documento porque vai utilizar o mesmo conhecimento sobre o formato. O interessante é que, se tu como implementador utilizares esta especificação e ela for decidida por alguém como a formato a adoptar, essa aplicação não pode ser excluída por não ser o Office. Até porque se não quiseres mexer nos documentos legacy, e os quiseres preservar, tens sempre os viewers que garantem que continuarás a ver e a imprimir os mesmos ao longo tos tempos. E nos novos estás em pé de igualdade com o Office. Embora eu acredite que a não especificação daquelas tags não vai impedir ninguém de representar os documentos mais antigos e com qualidade se assim o desejar. Com menos informação já quase todas as suites aplicacionais o garantiam antes de iniciarmos o processo de criação destes standards.Anonymous
October 18, 2007
"Por acaso atés sabes o que a estrutura possui, está documentado, não te serve é para o mesmo, e no teu caso podes decidir ignorar, mas é decisão tua." Isto é o mesmo que dizer "sabes mas não te serve de nada". Se não serve de nada não devia estar na especificação.Anonymous
October 18, 2007
"Isto é o mesmo que dizer "sabes mas não te serve de nada". Se não serve de nada não devia estar na especificação." Porque este domínio das aplicações é um bocadinho diferente, porque estamos a falar de funcionalidades que não é garantido que todos queiram ou não ter. Aliás estás a falar mas não é garantido que no ODF venhas algum dia a ter implementações tão completas como a do codebase do Oo... Podes dizer o que quiseres mas não vais conseguir garantir isso.