Meio-Bit e a polêmica das traduções em SL

Eu tenho que admitir que até gosto de ler o Meio-Bit: o Cardoso parece de certa forma o similar brasileiro do John C. Dvorak (colunista norte-americano que publica colunas na Info brasileira), com um certo teor de trollagem no qual pode estar uma preocupação verdadeira. Isso é algo de se admirar nele.
Mas acho que às vezes até mesmo isso passa dos limites.
Recentemente ele postou no Meio-Bit um artigo com um nome no mínimo provocativo: Quer ajudar o Software Livre? Esqueça o Babelfish. O artigo até tem uma opinião bastante relevante, ainda que não possamos concordar: é o problema relacionado com a diferença entre tradução e localização. Mas o problema é que o tom do artigo, mais o próprio retrospecto do autor, mais uma série de outras questões compromete o que ele diz:

Quer ajudar o Software Livre? Esqueça o Babelfish | Meio Bit

No caso das traduções, temos um agravante: São de péssima qualidade. Um desenvolvedor de um projeto Open Source pequeno não tem mão-de-obra para certificar uma tradução. Se for um idioma pouco-familiar então, está na mão de quem “colaborou” com a versão.

Acho que o agravante aqui não é a péssima qualidade, o tamanho do projeto ou qualquer catzo que o seja, e sim na real é o fato de que as pessoas ainda não entenderam (provavelmente como o Cardoso) que a programação não é a única forma de colaborar com Software Livre. Ou seja, ou programo ou não colaboro.
Embora seja programador formado, vou admitir que não sou um super-programador, um über-hacker de códigos. Mas acho que conheço bem inglês e português. Quando tomei conhecimento do projeto Babelzilla (um projeto que fornece um site e ferramentas para tradução de extensões dos software do Mozilla), decidi começar a participar. Já tinha feito a tradução de uma extensão simples (a Add Bookmarks Here), então decidi procurar alguma na qual pudesse ajudar. Acabei pegando uma das mais importantes extensões atualmente, a Scribefire (ferramenta de edição de posts para blogs do Firefox). Antes que pensem que é fácil, mesmo ela sendo localizada e tudo o mais, são mais de 300 strings para traduzir com cuidado com termos e consistência. Não é um processo fácil e a cada novo release, novas strings relacionadas a novas funcionalidades surgem e precisam ser traduzidas.
A questão aqui é que existem formas razoavelmente simples de participar-se desse tipo de projeto e apoiar traduções, sobre as quais falarei adiante.
Vejamos o que o Cardoso diz a seguir:
Quer ajudar o Software Livre? Esqueça o Babelfish | Meio Bit

Tradução, aliás, que não é só rodar uma série de strings no Babelfish, colar de volta, enviar e dizer “eu sou desenvolvedor Open Source”. Parte do esforço deveria incluir localização, mas aí entra mexer em código, e os 99% lá de cima não têm competência pra isso.

Aqui é importante também que os desenvolvedores colaborem para tornar o software localizável. No caso do Firefox e das suas extensões, existem ferramentas de código que tornam o software localizável. Diferentemente do que se prega, localizar um software não é uma questão também de criar-se códigos com compilação condicional para os vários idiomas. Um software localizável tem que ter um mecanismo de:

  1. Identificar o “idioma preferido” do ambiente em questão;
  2. Carregar arquivos de localização específicos para o idioma em questão e;
  3. Substituir determinadas strings pelas informações contidas em um arquivo de localização;
  4. Modificar e corrigir determinadas características idiomáticas para o “idioma preferido” (por exemplo, no caso do japonês, chinês e hebraico, entre outros, onde a leitura dos conteúdos é feita da direita para a esquerda, o texto e a posição dos elementos de tela devem ser invertidos);

OK… Aqui temos uma questão interessante sobre como tornar o software localizável. Consultando a Internet, achei esse artigo no Guia do Mochileiro. Esse artigo comenta um pouco do processo de transformar o software em localizável. É um processo que depende de todos os lados e que é feito para ser “independente”, ou seja, o tradutor não precisa ser parte da equipe de tradução e vice-versa.
Agora, qual a dificuldade?
Na verdade, a dificuldade é justamente coisas como a que o Cardoso coloca e que o Vladimir Melo comenta:
Conheço alguém que prejudica o software livre « Vladimir Melo

(…) Ele faz críticas duras à tradução de software livre e encerra afirmando absurdamente: “Afinal pro usuário não importa se a janelinha está em inglês ou português, essencial é que ela faça alguma coisa.”

(…)Ele ou qualquer outra pessoa deveria pesquisar na internet durante meia hora para conhecer os projetos de tradução e saber (inclusive pelos usuários) o quanto eles têm melhorado tecnicamente. (…)

Por exemplo, as pessoas que vão a um hipermercado e compram um computador popular não têm obrigação de saber inglês (e muitas vezes não sabem). O fato de um aplicativo estar traduzido ou não faz toda a diferença para que elas o usem. Mas certamente este blogueiro não tem consciência de que sua atitude afasta colaboradores e dificulta o nosso trabalho de recrutamento e divulgação.

A questão é que, pela exposição do Cardoso, uma pessoa deveria se preocupar apenas em programar SL. A verdade é que, embora isso seja importante (1) não é fácil de ser feito e (2) tira foco.
O programador de SL tem que ser visto como programador, e o tradutor como tradutor. Se você não possui habilidade como programador, não há problema: o mundo do SL possui espaço para todo tipo de envolvimento, seja desenvolvimento, documentação, tradução, artes ou evangelização. Escolha uma área onde você sinta ter proficiência e vá em frente. Bug report, relato de problemas com a tradução e por aí afora também é importante. Não se sinta acanhado: existe MUITO ESPAÇO para atuar-se (aproveito e me coloco à disposição de qualquer usuário do Scribefire para comentários sobre a tradução para o português brasileiro).
Agora, tenho que concordar com a citação do Vladimir acima: o que o Cardoso diz no final do seu artigo é, no mínimo, irresponsável:
Quer ajudar o Software Livre? Esqueça o Babelfish | Meio Bit

Você vai colaborar muito mais com o Open Source (e com seu futuro profissional) se ao invés de sair chutando traduções automáticas agora, se preparar por uns 2 ou 3 anos e entrar produzindo de verdade. Afinal pro usuário não importa se a janelinha está em inglês ou português, essencial é que ela faça alguma coisa. (grifos meus)

Dizer isso é irresponsável pois no Brasil muitas pessoas mal sabe ler, escrever e compreender o português direito, quanto mais o Inglês, que é um idioma que, por mais que os anglófonos queiram dizer, é cheio de nuances e detalhes específicos. Colocar um software em inglês, à exceção de software altamente especializado (como programação, CAD e afins) ou em jogos (onde o inglês se resume praticamente a “Press Start”, à exceção de jogos no estilo RPG) é algo que eu diria no mínimo temerário. Mesmo a MS percebeu isso e com o passar do tempo passou a localizar todos os seus softwares para outros idiomas além do inglês. Não adianta o software fazer algo se o usuário não sabe o que ele faz, e simplesmente adestrar o usuário em “Clique aqui, clique aqui, clique aqui…” não resolve o problema básico, que é o fato de ele não saber o que cargas-d’água ele está fazendo.
Não tiro alguns méritos do artigo do Cardoso, e ressalto aos usuários de SL: se perceberem coisas estranhas em traduções, COMENTEM JUNTO ÀS COMUNIDADES OU DESENVOLVEDORES!!! A maior parte dos software mais importantes possuem comunidades específicas para a tradução (Ubuntu LoCo Teams, os projetos de localização do Debian como o Debian Brasil, Babelzilla, BrOffice.org, etc…) e elas são receptivas com os interessados (sei disso pela recepção que tive dos desenvolvedores do Scribefire), oferecendo todos os recursos para aqueles que desejarem aprender, assim como listas onde pode-se discutir termos adotados até que um consenso seja obtido. Se você souber um pouco mais de programação, prepare software para ser localizado (o artigo da Wikipedia citado anteriormente serve de bom ponto de partida). Acima de tudo participe!
Mas também tenho que afirmar que o artigo do Cardoso, apesar de tudo isso, foi de um mau-gosto atroz, e de um nível de temerariedade incrível. Vou me abster de comentar mais sobre o artigo per se, pois creio que o fundamento dele já foi desfeito aqui.
De qualquer modo, fica a sugestão aos novatos: participem. Aos veteranos: ajudem os novatos, por favor!

Anúncios

As coisas se complicam para o OOXML

Bem, desculpem o hiato: as minhas novas atividades de serviço exigiram um tempo meu especial, onde precisei me focar mais nele e abandonei um pouco o blog.
Nesse meio tempo, ocorreu o Ballot Resolution Meeting (BRM) para a aprovação ou não do Office Open XML. Basicamente, esse é o momento onde todas as contradições (ou comentários) aplicados ao mesmo quando ele não foi aprovado, em uma tentativa de resolver os problemas e com isso aprovar o formato.
Antes que se pense que isso é mais um empurrão da nossa “amiga de Redmond”, na realidade isso é parte do processo de Fast track da ISO, portanto não há nada de errado nesse processo. Muito pelo contrário, ele é completamente válido na medida em que é parte de um processo já validado dentro de uma organização como a ISO.
Os problemas vão surgindo, porém, quando você entende o que está acontecendo por trás dos panos.
Como já comentei anteriormente nesse mesmo blog, existem uma série de problemas sobre como o formato está sendo publicado na ISO. Esse é inclusive o motivador do Ballot Resolution Meeting (BRM): estudar e chegar a um consenso sobre como serão corrigidos os problemas no mesmo. Mas como chegar a um consenso sendo que o formato possui mais de 6000 páginas de documentação técnica com coisas específicas para emular a formatação do Word 95 (?!) ou do Wordperfect (?!)?
Mas isso ainda não é o pior do que está acontecendo sobe o Ballot Resolution Meeting (BRM). Existem coisas ainda piores ocorrendo.
O Jomar, do Homembit e da ODF Alliance Brasil, é um dos representantes da ABNT no comitê JTC1 da ISO, responsável pelo OOXML (DIS 29000), sendo que os outros foram o Deivi Kuhn do SERPRO e o Fernando Gebara, da Microsoft, dois profissionais respeitados na área. Ele é uma fonte de referência para saber o que se passa nesse processo. Além dele, recomendo a leitura do blog do César Taurion, da IBM, também bastante respeitado, que vêm falando bastante do ODF e do OOXML. Eles foram para Genebra participar do BRM como representantes brasileiros. E as coisas começaram a aparecer, apesar da “lei de silêncio” envolvendo o BRM:
Comecemos pelo post do Jomar onde ele esclarece uma proposta do Brasil para facilitar a aceitação do OOXML, principalmente quanto à questão das famosas questões de retrocompatibilidade (lineWrapLikeWord6), que era a possibilidade de um mapeamento de formatos binários (como o .doc) para o OOXML (.docx).
Bem, vamos deixar que ele fale:

Afinal: O que fomos fazer em Genebra ? | void life(void)

Não posso contar os detalhes da reunião, mas posso contar uma conversa que tivemos (eu e mais um delegado brasileiro) com uma pessoa no início da pausa para o almoço de sexta feira. Vou divulgar esta conversa pois nosso interlocutor se identificou como sendo membro do ECMA, membro de uma delegação nacional presente no BRM mas não disse que estava falando em nome de ninguém (como é o protocolo lá), e por isso entendo que esta foi uma conversa que não está coberta pela escandalosa “Lei do Silêncio” imposta a todos nós.
Esta pessoa nos procurou dizendo que considera que não deveríamos apresentar nossa proposta que pedia o mapeamento, pois não havia tempo hábil na reunião (pouco mais de três horas) para escrevermos o documento. Nós dissemos que nossa proposta partia da premissa de que o ECMA já tinha este documento, pois, se justifica a necessidade do OOXML por causa do suporte ao binário e se afirma ainda que existem coisas que não podem ser traduzidas (deprecated), eles devem ter estudado aprofundadamente esta situação e no mínimo ter feito o mapeamento.
Eu nunca vi uma pessoa tão nervosa e envergonhada na minha vida… Ele disse que a Microsoft deve ter este mapeamento e se nós quisermos, podemos pedir à Microsoft mas não pedir ao ECMA. Disse que o ECMA só foi responsável por criar o novo schema XML e que não têm esta documentação.
Como nossa conversa não ia a lugar nenhum, eu lhe expliquei que o que iriamos propor era o resultado do trabalho de um comitê no Brasil e que infelizmente se ele não pudesse voltar ao tempo e vir ao Brasil contar esta história toda, que teríamos que insistir com nossa proposta.
Fiz questão de contar isso aqui, pois não deixaram o Brasil apresentar a proposta…

OK… Pode parecer correto o que a pessoa disse. Mas vejamos o que diz outro profissional envolvido, o Avi Alkalay, da IBM:

OOXML: Está rolando um barraco na ISO :: Avi Alkalay

Só pra lembrar qual é o propósito do OOXML, extraido (em livre tradução) de sua especificação:

O objetivo deste padrão [OOXML] é […] representar fielmente o corpo de documentos existentes […]

Os tais “documentos existentes” são no caso todos os documentos em formato binário legado do MS Office (.doc, ,ppt, .xls), algo fora do escopo do OOXML.
Se esse mapeamento não fizer parte da especificação OOXML, seu objetivo primordial é inválido. A especificação é inválida. E a delegação brasileira queria levantar essa bola: cadê o mapeamento ?

Sem um mapeamento, é praticamente impossível obter a total fidelidade no corpo de documentos existentes e transpor isso ao OOXML, mesmo recorrendo-se a engenharia reversa. Qualquer um que tenha aberto um arquivo .DOC no BrOffice.org ou exportado um documento do BrOffice.org para .DOC sabe disso. Sem esse mapeamento, o resultado prático é que características estranhas dos documentos, principalmente .DOC, não poderão ser representados adequadamente em um OOXML. E é justamente isso que questiona Rob Weir, que é parte da representação americana no OOXML:

An Antic Disposition: The Carolino Effect

The scope of OOXML, as amended by the BRM is stated as:

This International Standard defines a set of XML vocabularies for representing word-processing documents, spreadsheets and presentations. The goal of this standard is, on the one hand, to represent faithfully the existing corpus of word-processing documents, spreadsheets and presentations that have been produced by Microsoft Office applications (from Microsoft Office 97 to Microsoft Office 2008 inclusive). It also specifies requirements for Office Open XML consumers and producers , and on the other hand, to facilitate extensibility and interoperability by enabling implementations by multiple vendors and on multiple platforms.

Faithful representation of Microsoft Office 97-2008. I’ve learned it is rarely polite to ask a man what he means by “faithful”, but let me make an exception here. We have now the binary Office format specifications, not part of the standard, but posted by Microsoft. And we have OOXML specification. In what way does the OOXML “represent faithfully” the “existing corpus” of legacy documents?
Does OOXML tell you how to translate a binary document into OOXML? No. Does it tell you how to map the features of legacy documents in OOXML? No. Does it give an implementor any guidance whatsoever on how to “represent faithfully” legacy documents? No. So it is both odd and unsatisfactory that primary goal of the OOXML standard is so tenuously supported by its text.
Now, certainly, someone using the binary formats specifications, and using the OOXML specification, could string them together and attempt a translation, but the results will not be consistent or satisfactory. (…). Knowing the two endpoints is not the same as knowing how to correctly map between them. A faithful mapping requires knowledge not only of the two vocabularies, but also the interactions.

Uma tradução livre desse trecho é a seguinte:

O Escopo do OOXML, como foi corrigido no BRM é definido como:


Esse padrão internacional define um conjunto de vocabulários XML para a representação de documentos de processamento de texto, planilhas e apresentações eletrônicas. O objetivo desse padrão é, por um lado, representar fielmente a formatação existente de
documentos de processamento de texto, planilhas e apresentações eletrônicas produzidas por aplicações do Microsoft Office (do Microsoft Office 97 ao Microsoft Office 2008, inclusive). Também especifica requisitos para consumidores e produtores de documentos Office Open XML e, por outro lado, facilita a extensibilidade e a interoperabilidade ao permitir implementações por vários desenvolvedores e em várias plataformas.


Representação fiel de documentos do Microsoft Office 97 ao 2008. Aprendi que raramente é polido perguntar a alguém o que ele quer dizer com “fiel”, mas aqui há uma exceção. Nós temos agora as especificações do formato dos arquivos binários do Office, não incluídos como parte do padrão, mas sim fornecidos pela Microsoft; e temos a especificação do OOXML. Como é que o OOXML “
representar fielmente a formatação existente” dos documentos legados?
O OOXML nos diz como traduzir um documento binário em OOXML? Não. Diz como mapear as
features dos documentos legados para OOXML? Não. Oferece um caminho para o desenvolvedor “representar fielmente”, seja lá o que queira isso dizer, os documentos legados? Não. Portanto é ao mesmo estranho e insatisfatório que o objetivo principal do OOXML seja tão tenazmente definido por esse texto.
Na verdade, alguém que queira tentar uma tradução usando as especificações dos formatos binários e do OOXML poderia amarrá-los e tentar seguir em frente, mas os resultados não serão consistentes ou satisfatórios. (…) Saber os pontos de chegada e partida não significa saber o caminho entre eles. Um mapeamento fiel exige não apenas o conhecimento das duas especificações, mas também das interações entre elas. (Grifo meu)

Perceba aqui o problema: não é possível saber como “representar fielmente” os documentos em questão. O máximo que um desenvolvedor pode fazer é “ir no chute”, mas “os resultados não serão consistentes ou satisfatórios“. Como disse, basta tentar abrir um arquivo do Word em qualquer outro editor e ver que isso é uma verdade. O resultado nunca é o mesmo. Mesmo quando o formato é conhecido, existem leves diferenças na implementação (quem nunca desconfigurou a formatação de um documento ao abrir ele na versão mais atual de um editor?). Problemas entre formatos é obviamente uma realidade.
E isso é apenas a ponta do Iceberg.
No dia que eu escrevo isso, o Avi Alkalay publicou em seu blog um post falando sobre uma das “features” que serão exigidas no OOXML. No caso, cito a fonte do mesmo, novamente o Rob Weir:

An Antic Disposition: A Leap Back

(…) in 1582 Pope Gregory XIII promulgated a new way of calculating leap years, saying that years divisible by 100 would be leap years only if they were also evenly divisible by 400. So, the year 1600 and 2000 were leap years, but 1700, 1800 and 1900 were not leap years. This Gregorian calendar was initial adopted by Catholic nations like Spain, Italy, France, etc. Protestant nations pretty much had adopted it by 1752, and Orthodox countries later, Russia after their 1918 revolution and Greece in 1923.

traduzindo (desculpem, o post vai se tornar longo, mas tenho a prática de citar a fonte “as is” e as traduzir a posteriori quando isso pode ser relevante):

(…) em 1582 o Papa Gregório XIII promulgou uma nova forma de calcular-se anos bissextos, determinando que os anos divisíveis por 100 só seriam bissextos se fossem divisíveis também por 400. Portanto, 1600 e 2000 foram anos bissextos, mas 1700, 1800 e 1900 não. Esse calendário gregoriano foi inicialmente adotado em nações católicas como a Espanha, Itália, França, etc… As nações protestantes o adotaram em 1752, e as nações ortodoxas mais tarde: a Rússia após a revolução de 1918 e a Grécia em 1923.

OK… Um pouco de história? Qual é o problema?
O problema é a seguinte imagem:

O que foi feito aqui?
Quando se formata uma casa do Excel como data, ela conta a partir de 01/01/1900. Ou seja, se quero representar o dia de hoje, eu somo o número de dias que passou entre 01/01/1900 e hoje (um princípio básico da computação que é adotado em diversos formatos, com leves diferenças entre unidades e “ponto zero” adotados). Isso facilita a computação para fórmulas, principalmente envolvendo datas. Pensando assim, e lembrando o que foi dito anteriormento, o Avi definiu que o valor da data como a primeira data do escopo (01/01/1900) + os trinta dias seguintes (ou seja, levaria até 31/01/1900) e somou mais 29 dias em seguida. O resultado seria 29 dias após o dia 31/01/1900. Como não é bissexto (como o Rob explicou anteriormente), o resultado adequado seria 01/03/1900. A imagem comprova que o resultado foi 29/02/1900 (também conhecido como dia de São Nunca).
Agora, você pergunta: “Qual é o problema?”
Lembra a questão de “‘representar fielmente a formatação existente‘ dos documentos legados”? Bem, isso quer dizer representar inclusive os bugs!!! Pode-se alegar que é um bug inconveniente, mas não é, e mesmo que fosse isso não é desculpa. E a questão é a seguinte: se um erro bobo como esse passa (lembrando que esses documentos legados podem estar por aí em 2100, que também não é um ano bissexto), imagina detalhes mais complexos?
E as coisas não acabaram:
As pessoas que estão acompanhando esse processo do OOXML sabem que a Microsoft prometeu liberar totalmente de royalties o OOXML, atraves do que ela chama de “Microsoft Open Specification Promise” (OSP). Basicamente, ela afirma por meio disso que está não irá processar ninguém por usar ou desenvolver em cima dessas patentes. Porém, o pessoal do Software Freedom Law Center, que estuda licenças de software para analisar sua compatibilidade com o Software Livre, procurou analisar a OSP e verificar sua compatibilidade com as licenças livres, como a GPL, a Artistic (do Apache) ou a CDDL (Sun/OpenOffice.org). O resultado é:

Microsoft’s Open Specification Promise: No Assurance for GPL – Software Freedom Law Center

(…), we publicly conclude that the OSP provides no assurance to GPL developers and that it is unsafe to rely upon the OSP for any free software implementation, whether under the GPL or another free software license.

traduzindo:

(…), concluímos publicamente que a OSP não oferece nenhuma segurança para desenvolvedores que usem a GPL e que não é seguro se basear na OSP para qualquer implementação livre [do OOXML], seja segundo a GPL ou segundo qualquer outra licença de software livre. (grifos meus)

Você pode se perguntar: “o que mais esses open-xiitas querem? Não basta as especificações da ECMA?
Não basta! Tanto não basta que a própria ISO não aceita padrões que possuam patentes, a não ser que essas patentes estejam para acesso a qualquer um sem cobrança de royalties. A pergunta então pode ser: “qual é o problema?” Bem, vamos aos fatos:


Microsoft’s Open Specification Promise: No Assurance for GPL – Software Freedom Law Center

Microsoft makes its promise “irrevocably,” but upon careful reading of the entire OSP, this promise is weakened considerably in the definition of Covered Specifications. In that provision, Microsoft clarifies that:

New versions of previously covered specifications will be separately considered for addition to the list.

Because of this narrow definition of the covered specifications, no future versions of any of the specifications are guaranteed to be covered under the OSP. Each new version is subject to Microsoft’s ongoing discretion on a case by case basis. In other words, every time a specification changes, Microsoft can effectively revoke the OSP as it had applied to previous versions of that same specification. Microsoft states that it will commit to renewal of the promise for future versions of specifications subject to standardizing activity “to the extent that Microsoft is participating in those efforts,” which means that Microsoft reserves the right to cancel the promise with respect even to standardized specifications, by merely withdrawing from the relevant standard-setting workgroup or activity. While technically an irrevocable promise, in practice the OSP is good only for today.

tradução:

A Microsoft torna sua promessa “irrevogável”, mas se lemos a OSP completamente, percebemos que essa promessa é enfraquecida sensivelmente pela definição de Especificações Cobertas pela mesma. Nessa provisão, a Microsoft deixa claro que:

Novas versões de especificações anteriormente cobertas pela mesma poderão ser consideradas separadamente para serem adicionadas à lista [de especificações].

Devido à essa definição ampla de Especificações Cobertas, nenhuma versão futura de nenhuma dessas especificações estarão seguramente cobertas pela OSP. Cada nova versão é alvo da decisão da Microsoft em uma situação caso-a-caso. Em outras palavras, cada vez que uma especificação mudar, a Microsoft pode efetivamente revogar a OSP do modo como ela se aplica às versões anteriores da mesma especificação. A Microsoft determinou que irá renovar a promessa para futuras versões das especificações sujeitas à atividade de padronização “enquanto a Microsoft participar desses esforços”, o que na prática quer dizer que a Microsoft se reserva no direito de cancelar a promessa até mesmo para as especificações que passaram por padronização, simplesmente abandonando os grupos de trabalho ou atividades relevantes. Embora tecnicamente ela seja irrevogável, na prática a OSP só funcionaria de imediato. (grifos meus)
Atentemos aos grifos: por eles, compreendemos que, ao bel-prazer, a Microsoft pode, mesmo após aprovado o padrão, revogar sua OSP e sair processando todo mundo, criando uma patente submarina potencial, uma vez que, pelos termos citados, ao revogar sua OSP, todo usuário potencial da OSP estaria infringindo direitos de patente e, com isso, sendo alvo potencial de processos. Sem sombra de dúvidas, uma forma capciosa de implementar minas-terrestres de Propriedade Intelectual contra os usuários.
Mas não acabou: você não poderia incorporar código de implementações do OOXML em qualquer coisa que não envolva implementação OOXML. Vejamos o que a SFLC tem a dizer sobre isso:

Microsoft’s Open Specification Promise: No Assurance for GPL – Software Freedom Law Center

(…) any code written in reliance on the OSP is covered by the promise only so long as it is not copied into a program that does something other than implement the specification. This is true even if the code has not otherwise been modified, and code that conforms to the specification cannot be modified if the resulting modified code does not conform.

Traduzindo:

(…) qualquer código que tenha sido escrito em observância à OSP estará coberto pela promessa enquanto ele não for incorporado a qualquer programa que faça qualquer outra coisa que imp,ementar a especificação. Isso é verdadeiro mesmo se o código não for modificado, e o código que estiver seguindo a especificação não pode ser modificado se o código modificado resultante não estiver em observância.

O que isso quer dizer? Basicamente, não temos um uso livre para incorporação em qualquer situação, o que é definido pela Liberdade 2 da Free Software Foundation e que é parte do princípio por trás da GPL. Embora possa-se alegar que uma biblioteca poderia rodar segundo LGPL e assim trabalhar em conjunto com software GPL, ainda assim não pode-se afirmar que esse seja um uso livre ou mesmo seguro do mesmo.
O pior é que, segundo a Microsoft, a culpa é da GPL:
Microsoft’s Open Specification Promise: No Assurance for GPL – Software Freedom Law Center

In its FAQ regarding the OSP, Microsoft confuses the issue further, saying:

Because the General Public License (GPL) is not universally interpreted the same way by everyone, we can’t give anyone a legal opinion about how our language relates to the GPL or other OSS licenses, but based on feedback from the open source community we believe that a broad audience of developers can implement the specification(s).

While not attempting to clarify the text of the OSP to indicate compatibility with the GPL or provide a safe harbor through its guidance materials, Microsoft wrongly blames the free software legal community for Microsoft’s failure to present a promise that satisfies the requirements of the GPL. It is true that a broad audience of developers could implement the specifications, but they would be unable to be certain that implementations based on the latest versions of the specifications would be safe from attack. They would also be unable to distribute their code for any type of use, as is integral to the GPL and to all free software.

traduzindo:

Em sua FAQ relacionada à OSP, a Microsoft distorce essa questão [do licienciamento segundo a GPL] dizendo que:

Uma vez que a Licença Pública Geral (GPL) não é universalmente interpretada da mesma forma por todos, não podemos dar uma opinião legal sobre como nosso texto se relaciona à GPL e a outras licenças de software livre ou aberto, mas baseado no feedback que recebemos da comunidade do software aberto acreditamos que uma ampla gama de desenvolvedores pode implementar a(s) especificação(ões).

Além de não tornar claro o texto da OSP para indicar compatibilidade com a GPL ou oferecer um porto seguro por meio de eus materiais, a Microsoft erroneamente culpa a comunidade jurídica relacionada ao software livre por sua incapacidade de oferecer uma promessa que satisfaça as condições da GPL. É verdade que uma ampla gama de desenvolvedores poderá implementar as especificações [segundo a OSP], mas eles não terão certeza de que implementações baseadas nas versões mais recentes estarão seguras contra litígios. Eles também não terão garantias de que poderão distribuir tais códigos para serem usados como necessário, o que é uma parte fundamental da GPL e de qualquer software livre. (Grifos meus)

Perceba que citei anteriormente a possibilidade de adotar-se a LGPL. O problema é que pela primeira questão levantada (a possibilidade de revogação da OSP), não há garantias de que, mesmo sob LGPL, o software continue legalmente sendo aceito, devido às patentes.
Pretendo comentar mais sobre essa questão, uma vez que em alguns dias haverá a decisão final sobre a padronização do OOXML. Mas é importante ficarmos com a orelha em pé: não sabe-se o que pode acontecer.

Office OpenXML (OOXML) e inapto pela ISO 29500

BrOffice.org – ODF: O formato Inevitável

Em 1999, um cientista desejava ter acesso a alguns dados de amostras de solo de Marte coletadas em 1975 pela sonda espacial Viking. Ele desejava testar uma teoria sobre uma possível existência de bactérias e micróbios em Marte – ou seja, a existência de vida em Marte. O cientista pensou que ele poderia encontrar o que precisava em um dos diversos sites da NASA, mas não foi tão fácil quanto aparentava. Os dados originais não estavam onde se esperava, e quando as grandes fitas magnéticas que continham esses dados foram localizadas, eles estavam “em um formato tão antigo que os programadores que sabiam como ele funcionava haviam morrido”. Alguém então encontrou um conjunto de versões impressas dos dados que estavam servindo como peso de papel e o entendimento da humanidade quanto ao universo aumentou um pouco mais. O senso de tragédia que poderia ter resultado da perda de tais conhecimentos são ecoados em registros sobre a destruição da Biblioteca de Alexandria, e explica porque em uma sociedade sadia a queima de livros normalmente é vista como insanidade.

Claro que nem todos os dados perdidos ou inacessíveis armazenam pistas para a vida em Marte, e obviamente nem toda informação precisa ir além da vida do seu autor. Muitos documentos ilegíveis não farão falta, mas políticas públicas responsáveis exigem que documentos do governo – contratos, escritúras e registros processuais que têm força por décadas ou mesmo séculos – precisam ser arquivadas e estar disponíveis a todos. Seja como for, quando os dados são armazenados e compartilhados em formatos antigos ou obsoletos, com o tempo se tornará cada vez mais caro o acesso aos mesmos, sendo que eles podem até mesmo desaparecer.

Quando estamos falando de documentos que podem ser criados, armazenados e compartilhados digitalmente, a tecnologia para a prevenção do desaparecimento devido a formatos já existe e está tornando-se cada vez mais popular. Ela é chamada de Formatos para Documentos Abertos (Open Document Format – ODF) e se você ainda não o usa, algum dia irá usar.

O ODF é um formato de marcação de documentos baseado em XML que foi inicialmente desenvolvido em 1999 pela Stardivision e então no projeto OpenOffice.org, financiado pela Sun Microsystem. Concebido para ser uma alternativa a um software proprietário de manipulação de documentos, que então dominava completamente o mundo, a força motriz que impulsiona o ODF é a necessidade de um formato de documentos independente de fabricante ou de aplicação, que possa ser escrito e aberto por todos, sem a necessidade de royalties ou de licenciamento. Ele foi promovido com a idéia de que empresas e consumidores possam economizar dinheiro. Um formato aberto pode criar competição na esfera das aplicações de escritório. Todos os documentos podem ser abertos e compartilhados por todos. Não haveria perdas pelo tempo ou por mudanças em códigos proprietários ou pelas exigências de licenciamento. Informações de grande interesse público, como informações censitárias, informações sobre o clima, estatísticas sobre saúde, informações de investigações, registros jurídicos e informações de pesquisas científicas, pagas com os empostos dos contribuíntes, não precisariam mais serem escritas em um formato proprietário e fechado, obrigando os cidadãos a pagar duas vezes pelo acesso à informação que eles próprios produziram. Usando ODF, dizem seus proponentes, os documentos públicos permanecem sempre públicos.

A Organização para o Avanço dos Padrões de Informação EstruturadaOrganization for the Advancement of Structured Information Standards – OASIS) foi criada em 2002 para padronizar o formato, que foi reconhecido pela Organização Internacional para PadronizaçãoInternational Organization for Standardization – ISO) em 2006. Em Março de 2006 foi fundada a Aliança para o Formato Aberto de Documentos (Open Document Format Alliance) para promover o formato, criando condições públicas, legais e políticas para a adoção de padrões abertros de tecnologia por parte de instituições públicas egovernos.

– A Red Hat é um dos membros fundadores da ODF Alliance e Tom Rabon (Vice-presidente para assuntos corporativos) é parte do conselho executivo da organização. – diz Stephanie McGarrah, antiga Gerente de Políticas Públicas da Red Hat. – A Red Hat trabalha com os outros membros do conselho executivo para coordenar esforços e conversar com os governos de todo o mundo sobre o ODF.

Embora o ODF tenha sido lançado com um grande impulso derivado do bom-senso soprando forte, o momento para adoção em massa do formato foi enfraquecido pela inércia da burocracias, políticas locais, conceitos errôneos persistentes sobre a viabilidade do ODF (reforçados por oponentes do formato) e pelos “perigos” da adoção do formato. Muito do medo, incerteza e dúvida surgiram de uma fonte, cujos formatos proprietários são usados na maior parte dos documentos de todo o mundo.

Os oponentes do ODF não aceitam a sua adoção inevitávl, e ativamente fazem lobby contra ele. Não é que todos sejam contra o ODF per se, ou que tenham encontrado alguma razão real que questione a necessidade do mesmo. A lógica por trás do ODF e a transparência na sua criação é algo que dificilmente pode ser questionado. Na verdade, é a questão de padrões abertos que está por trás do ODF que é o alvo principal. Do ponto de vista dos detratores do formato, as coisas estão indo muito bem do jeito que estão atualmente. O “padrão” é deles, eles são donos do “mercado” de documentos, e pensam nele como um “território” “conquistado” de maneira limpa. Eles não conseguem imaginar um futuro sem esse “território” (isso sequer consta de seu plano de negócios), e já que todos utilizam suas aplicação e formatos, por que mudar? Os oponentes do ODF devotam recursos consideráveis no lobby de comissões de aconselhamento de TI tanto no Executivo quanto no Legislativo em uma tentativa de convencê-los de que a adoção do ODF na realidade limita a escolha e fere a eficiência do modelo de mercado ao “expulsar” empresas como eles. Eles afirmam que a migração é cara, e até mesmo argumentam que a adoção do ODF irá limitar o acesso público ao fatiar o ambiente de TI em milhares de formatos “incompatíveis”. E quem realmente confia em toda essa idéia de “gratuito”?

Mas os propontentes do formato, como a ODF Alliance, tem seus próprios argumentos, muitos deles partindo do princípio de refutação que diz que “Inicialmente, o oponente está certo…”

A ODF Alliance afirma que os padrões abertos na verdade promovem a escolha e a competição entre fabricantes ao definir as regras básicas do jogo. Os padrões são abertos e disponíveis livremente para que qualquer um possa implementá-los. Não existe nenhuma competição envolvendo o formato, e sim a aplicação que será usada para o manipular. Nesse universo, a melhor aplicação ganha. A ODF Alliance também aponta que implementar ou migrar para ODF não é mais complicado ou custoso do que a atualização períodica de uma versão de uma aplicação proprietária para a seguinte, e ao tornar a mudança para versões futuras mais simples, existe uma redução nos custos ao longo do tempo. Quanto à questão de disponibilidade de aplicações, o OpenOffice (e outras aplicações que seguem o ODF) podem ser copiadas da internet livremente e podem ser usadas já. Não existem questões de compatibilidade na realidade, dizem os defensores, apenas questões de não-cooperação.

– Acho que muitos governos não sabem da existência ou não têm um corpo técnico capaz de entender o valor do ODF. – explica McGarrah. – Portanto, o trabalho da aliança divulgar essa mensagem para as pessoas nos governos que possam tomar tais decisões.

Mas o principal argumento em favor do uso do ODF para documentos públicos é o fato de que é um melhor negócio para os cidadãos no longo prazo. Usar software proprietário e com padrões fechados para documentos públicos é como comprar uma privada de 10 mil dólares, ou proibir o governo federal de negociar preços melhores nos remédios a serem distribuídos pelo SUS, ou tentar suprir um exército e apoiar a reconstrução de antigos campos de batalha por meioo de contratos secretos, não licitados e não competivitivos. É a não competitividade em seu pior sentido.

Apesar da oposição, a adoção do ODF está indo em frente, devagar mas inexoravelmente, e conforme os governos vão entendendo melhor o ODF, o ODF vem desafiando a atual ubiqüidade dos formatos proprietários. Indo mais adiante, o Japão obrigou recentemente que todos os contratos de seus ministérios com vendedores de software fossem feitos de modo a envolver padrões abertos. Brasil, Polônia, Malásia, Itália, Coréia, Noruega, França, Holanda, Dinamarca, Bélgica, o Estado de Massachusetts nos EUA e o Estado de Dehli na Índia estão todos fazendo mudanças nas leis de forma a adotar o ODF e, provavelmente mais importante de tudo, reconhecer o imperativo de usar-se padrões abertos. A ODF Alliance continuar a armar e iluminar os legisladores com as informações e ferramentas que eles precisam para fazer recomendações e mudanças de políticas, mas ninguém que promova o ODF acredita que sua adoção em massa é iminiente. Ela levará algum tempo.

– Esses legisladores tem muitas outras coisas importantes para resolver, como saúde, educação, transporte, combate a pobreza e outros, portanto decisões sobre tecnologia não estão normalmente no topo de suas listas. – diz McGarrah – Já tivemos avanços quanto a uma maior adoção do ODF. Muitos governos adotaram o ODF e estão trabalhando na implementação do padrão, mas ainda há muito o que fazer.

Powered by ScribeFire.

BrOffice.org: Tabelas Pivôs com outro nome

Por Bruce Byfield (2007-07-31 11:31)

O Assistente de Dados é o equivalente no BrOffice.org ao que o MS Excel e outras planilhas eletrônicas chamam de tabelas pivô (pivot tables). Sob qualquer nome, eles são uma ferramentas para extração e sumarização de conteúdo contido nas células de uma planilha de uma maneira conveniente. Usando um Assistente de Dados, você pode imediatamente ver relacionamentos entre várias informações que poderiam ser difíceis, senão impossíveis, de serem encontradas usando fórmulas, e tediosos de serem extraídos manualmente. Portanto, um Assistente de Dados lhe dá uma parte do poder de um banco de dados sem precisar realmente sair da planilhas. Não surpreende, portanto, que algo em torno de metade dos usuários de planilhas eletrônicas utilizem Assistente de Dados ou tabelas pivôs.

Para entender a utilidade do Assistente de Dados, imagine que você seja um fabricante de tocadores de arquivos Ogg Vorbis vendendo-os no mercado norte americano. Seu produto vem em duas cores, bege e preto, e com tamanhos de 80, 150 e 300 megabytes cada, vendidos em conjuntos. Para cada venda, você registra o total de conjuntos vendidos e o preço total. Em uma planilha, os seus dados pareceriam-se com algo como abaixo:

Country Color Size Quantity Price
Canada Beige 80 1 $500.00
USA Black 150 5 $5000.00
Mexico Beige 80 1 $500.00
Mexico Beige 80 2 $1000.00
US Black 150 3 $3000.00
US Beige 300 2 $4000.00
US Beige 300 7 $14,000.00
Canada Black 300 4 $8000.00
Total $36,000.00
Note que todas as colunas possuí rótulos. Esses rótulos são um pré-requisito para trabalhar-se com Assistentes de Dados.

Quando você for analizar esses dados, você pode querer saber as respostas para perguntas como “quantas unidades de cada cor foram vendidas” ou “quantas unidades foram vendidas em cada país“. Você pode obter essas informações usando filtros e fórmulas, mas criar um Assistentes de Dados é muito mais rápido.

Por exemplo, para achar rapidamente quantos conjuntos foram vendidos por país, você poderia criar o seguinte Assistentes de Dados:

Filter
Country -all-
Quantity
1 $1,000.00
2 $5000.00
3 $3000.00
4 $8000.00
5 $5000.00
7 $14,000.00

Vendas para todos os países são apresentadas por padrão. Porém, se você usar o filtro no alto do Assistentes de Dados, você poderâ ver as vendas apenas para o Canadá:
Filter
Country  Canada
Quantity
1 $500.00
4 $8000.00
As células cinzas em cada Assistentes de Dados representam os filtros que você pode usar para o modificar. Clicando em um desses filtros, você pode mudar a informação apresentada no Assistentes de Dados.

Adicionalmente, você pode arrastar os outros filtros para novas posições de modo a modificar como a informação é apresentada. Por exemplo, se você arrastar o filtro Country para a direita da coluna Quantity no Assistentes de Dados existente, ele irá apresentar agora a quantidade vendida separada por país, com as primeiras linhas como o exemplo abaixo:

Filter
Quantity Country
1 Canada $500.00
Mexico $500.00
2 Mexico $1000.00
US $4,000.00

Como você pode perceber, um Assistentes de Dados é uma forma ideal de obter-se novas perspectivas dos dados com o mínimo de esforço.

Criando um Assistentes de Dados

Para começar a criar um Assistentes de Dados, selecione a faixa de células que você deseja que seja a fonte dos dados, então selecione Dados | Assistente de Dados | Iniciar para abrir a caixa de diálogo do Assistentes de Dados. Alternativamente, escolha o mesmo item do menu, então selecione uma fonte de dados que você já registrou no BrOffice.org usando Arquivo | Novo | Banco de Dados e uma faixa de dados da mesma.

A janela do Assistentes de Dados lhe dá um diagrama do Assistentes de Dados que você está criando e uma lista de colunas da fonte de dados. Para criar o layout geral da fonte de dados, tudo o que você tem que fazer é arrastar o nome da coluna para os espaços Coluna ou Linha, e então eles se tornarão a primeira célula de uma linha ou coluna conforme o indicado (no Assistentes de Dados mostrado anteriormente, Quantity foi escolhida como coluna, e nenhuma linha foi escolhida). De maneira similar, se você arrastar uma coluna para o campo de Dados, ele irá se tornar os dados no Assistentes de Dados (no primeiro exemplo acima, o campo Price). A única escolha que pode causar confusão é o campo de Página, que é na realidade apenas o filtro desejado para alterações no conteúdo do Assistente de Dados em tempo real (no primeiro exemplo, o campo Country). Se você fizer algo errado, você pode arrastar a coluna de volta para a lista de colunas da direita.

Uma vez que você tenha feito a configuração básica, você pode também escolher qual será a função a ser usada pelo Assistentes de Dados. Nos exemplos anteriores, foi usada simplesmente a função padrão Soma, o que na maioria dos casos será tudo o que você irá precisar. Porém, você pode também utilizar outras dez funções padrão: Contagem, Média, Máx., Min., Produto, Contar (Somente Números), DesvPad (exemplo), DesvPad (População), Var (exemplo) e VarP (população). Se preciar, você poderá encontrar detalhes sobre o que cada uma dessas funções faz na documentação online do BrOffice.org.

Por padrão, o Assistentes de Dados é criado imediatamente embaixo da faixa de dados na qual ele se baseia. Porém, se você selecionar o botão Mais na caixa de díalogo, você podera definir as células ou a planilha na qual ele será criado. Você também pode definir opções adicionais, como ignorar linhas vazias. porém, para a maioria dos casos você pode simplesmente ignorar essas opções, principalmente se você está começando a trabalhar com Assistentes de Dados, pois em geral os padrões serão satisfatórios.

Após criar o Assistentes de Dados, selecionar partes dele irá ativar a opção Dados | Assistentes de Dados | Atualizar, se você precisar atualizá-lo devido a alterações na informação original. O mesmo submenu contêm um item Excluir que você poderá usar quando não precisar mais do Assistentes de Dados.

Conclusão

Aprender a trabalhar com Assistentes de Dados leva algum tempo. Novos usuários devem entender que são as colunas, e não as linhas, que deveriam conter rótulos. Eles também deveriam controlar quais colunas contêm dados e quais não: se essas colunas não forem levadas para o campo de Dados na caixa de diálogo, os resultados não irão fazer sentido. Porém, para muitas pessoas, será apenas questão de algumas tentativas para dominar-se os básicos dos Assistentes de Dados.

Não demorará muito tempo para que você enxergue seus dados de formas que você nunca imaginou antes. Após isso, o que você irá fazer com os Assistentes de Dados será limitado apenas pela sua imaginação.
Bruce Byfield é um jornalista da área de informática que escreve para a Datamation, Linux.com e Linux Journal.

Powered by ScribeFire.

BrOffice.org: Um inventivo sistema de controle de versões para o OpenOffice.org

Por Dmitri Popov (23/07/2007 – 9:00:00 AM)


Original em inglês: http://www.linux.com/feature/118083

Embora o OpenOffice.org permita que você salve múltiplas versões de um documento, esse recurso possui uma série de problemas que limitam sua utilidade. Para os iniciantes, salvar todas as versões de um documento no mesmo arquivo é o mesmo que colocoar todas as suas fichas em um cavalo só. Mais importante, esse mecanismo torna difícil compartilhar versões dos documentos com outros usuários e controlar as mudanças feitas no documento. Uma alternativa, um sistema completo de versionamento ou uma solução dedicada para o gerenciamento de documentos é supérflua se tudo o que você precisa é de uma forma simples de manter modificações em versões de um documento e permitir que outros usuários saibam delas. Uma solução mais compromissada usa o OpenOffice.org para manter um feed RSS com as mudanças no documento.

A solução completa consiste em um arquivo do Writer que contêm os dados do feed RSS, e uma macro em OpenOffice.org Basic que faz duas coisas: salvar uma versão dos documentos atualmente abertos e criar um item no feed RSS ligando-o à versão salva. Para melhor entendimento de como essa macro funciona, vamos dar uma olhada em um feed RSS que tem as informações que precisamos para o controle de versões.

  <?xml version="1.0"?>

  <rss version="2.0">

    <channel>

      <title>OpenOffice.org RSS Feed</title>

      <link>http://192.168.1.7</link>

      <description>A simple feed that tracks changes in OpenOffice.org documents</description>

      <language>en-us</language>

      <generator>OpenOffice.org 2.2.1</generator>

      <item>

        <title>Loremipsum.odt</title>

        <description>Initial version of the document.</description>

        <guid>http://192.168.1.7/Loremipsum.odt</guid>

      </item>

    </channel>

  </rss>

Como você pode ver, o feed nada mais é que um arquivo XML plano composto por duas partes: um preâmbulo estático que contêm informação de meta-dados sobre o feed (título, descrição, etc…) e os items do feed, o que incluí nomes, descrições e links para os documentos apropriados.
Olhando para o feed, é fácil imaginar que a macro deveria simplesmente criar um novo item para cada versão salva do documento e o escrever no arquivo RSS. Embora o OpenOffice.org possa ler e escrever arquivos de texto puro, ele não é muito bom ao manipular. É por isso que iremos criar um arquivo de documento do Writer (por exemplo: RSS.odt) que conterará o feed RSS. A macro então irá usar esse arquivo para criar as novas entradas RSS e salvá-las em um arquivo .xml. Inicialmente, o arquivo RSS.odt deverá conter um feed vazio sem nenhum item nele:

  <?xml version="1.0"?>

  <rss version="2.0">

    <channel>

      <title>OpenOffice.org RSS Feed</title>

      <link>http://192.168.1.7</link>

      <description>A simple feed that tracks changes in OpenOffice.org documents</description>

      <language>en-us</language>

      <generator>OpenOffice.org 2.2.1</generator>

    </channel>

  </rss>

Uma vez que o documento RSS.odt estiver pronto, você pode começar a trabalhar na macro. Primeiro, você tem que definir algumas variáveos e checar se o documento foi salvo:

  Sub AddRSSItem()

  Dim ObjSearch As Object

  Dim Args(0) As New com.sun.star.beans.PropertyValue

  ThisDoc=ThisComponent

  If ThisDoc.hasLocation=False Then

  MsgBox ("You must save the document first!", , "Attention!") :End

  End If

Em seguida, a macro terá que obter o nome do arquivo atualmente aberto, pois ele será usado como o título da entrada no feed:

  DocURL=ThisDoc.getURL()

  FileName=Dir(DocURL, 0)

Uma vez que a macro escreve primeiro a entrada de RSS no documento RSS.odt e em seguida o grava como um arquivo XML, você precisa especificar três valores: o caminho para o arquivo RSS.odt, o caminho onde o XML de saída deverá ser salvo e o nome do arquivo XML.

  RSSFile="ftp://user:password@192.168.1.7/web/RSS.odt"

  RSSPath="ftp://user:password@192.168.1.7/web/"

  RSSXMLFile="rss.xml"

No exemplo acima, tanto o RSS.odt quanto o arquivo rss.xml resultante estão armazenados no mesmo local em um servidor FTP local, portanto os usuários de RSS locais podem assinar o feed RSS. Mas você pode publicar o feed RSS em um servidor Web e manter o documento RSS.odt em sua máquina local.

A macro também adiciona um timestamp que atua como identificador único de cada versão salva. Há várias formas de fazer-se isso, dependendo de como você quiser o adicionar. O código abaixo adiciona-o como um prefixo AAAAMMDD_HH-MM-SS_ ao dcoumento. Ele então utiliza o RSSPath para salvar a versão do documento no mesmo local no arquivo rss.xml, desse modo tornando mais fácil ligá-lo a ele:

  Timestamp=CDateToISO(Date) & "_" & Format(Hour(Now), "00") &_

  "-" & Format(Minute(Now), "00") & "-" &_

  Format(Second(Now), "00")

  VersionPath = RSSPath & Timestamp & "_" & FileName

Uma vez que a macro tenha todos os elementos necessários, ele salva a versão do documento atual com o timestamp:

  Args(0).Name="Overwrite"

  Args(0).Value=True

  ThisDoc.storeToURL(VersionPath, Args())

O próximo passo é atualizar o feed RSS para refletir as mudanças. Primeiro, a macro abre o arquivo RSS.odt e notifica o usuário para que ele entre com uma descrição das mudanças.

  ThisDoc=StarDesktop.loadComponentFromURL(RSSFile, "_blank", 0, Array())

  ChangesDescription=InputBox("Summary of changes", "Enter a brief description of changes" , "")

Usando as informações fornecidas, a macro então tem que gerar uma nova entrada RSS e a inserir no arquivo RSS.odt. O último passo é um pouco mais complicado, pois a nova entrada tem que ser adicionada antes das tags . Uma forma de resolver esse problema é usar uma rotina de busca e substituição para encontrar a tag e a substituir pela nova entrada RSS seguida por . Outro problema é que a rotina padrão de busca e substituição do OOoBasic ignora quebras de linhas definidas pelo código CHR(13). Isso quer dizer que o feed RSS inteiro será adicionado como uma linha. Embora isso não faça diferença na análise do RSS por parsers, isso o torna mais complexo de ser lido. Felizmente, existe uma forma simples de contornar o problema, que é usar expressões regulares e usar o código \n para inserir as quebras de linha. O bloco de código final para busca e substituição irá parecer-se com algo assim.


  RSSEnd="</channel>"

  NewRSSItem=Chr(13) & "<item>n <title>"& FileName & "</title>n <description>" & ChangesDescription &_

  "</description>n <guid>" & VersionPath & "</guid>n </item>nn</channel>"

  ThisDoc=ThisComponent

  ObjSearch=ThisDoc.createReplaceDescriptor

  ObjSearch.SearchString=RSSEnd

  ObjSearch.ReplaceString=NewRSSItem

  ObjSearch.SearchWords=true

  ObjSearch.SearchRegularExpression=true

  nReplace=ThisDoc.ReplaceAll(ObjSearch)

A macro está praticamente pronta; basta agora salvar o documento RSS.odt, então salvá-lo como um arquivo XML, e fechá-lo para deixar tudo certo:

  ThisDoc=ThisComponent

  ThisDoc.Store

  Args(0).Name="FilterName"

  Args(0).Value="Text"

  ThisDoc.StoreAsURL (RSSPath & RSSXMLFile, Args())

  ThisDoc.Close(True)

  End Sub

E é isso: uma solução caseira de controle de versões está pronta para ser publicada. Mova o documento RSS.odt para a localização adequada, tenha certeza que todos os caminhos para a macro estão corretos e comece a usá-lo. Outros usuários então poderão assinar o feed RSS gerado e manter-se informados sobre as mudanças no documento.

Dmitri Popov é um escritor freelancer cujos artigos aparecem em revistas de informática na Rússia, Inglaterra, Estados Unidos, Alemanha e Holanda.

Powered by ScribeFire.