Acabo de promover a beta o Page2Docbook; o plugin para o Trac que referi recentemente.

Faz mais de um ano que andei em busca de uma boa forma de produzir documentos e, não tendo encontrado uma solução perfeita, resolvi reduzir o âmbito do tipo de documentos em causa e concentrar-me na produção dos documentos que tipicamente aparecem durante o processo de desenho e desenvolvimento de software.

A ideia foi simples; partir das funcionalidades de wiki do trac e adicionar a capacidade de exportar cada página como docbook. A partir de uma exportação para docbook, há uma série de opções que se abrem em termos de conversões para outros formatos.

Para chegar aí tinha duas opções, ou converter directamente do formato wikitext do trac, ou partir do xhtml (strict!) que o trac gera a partir do wikitext. A primeira opção consegue-se implementar com umas quantas expressões regulares, mas parece-me talvez mais difícil conseguir prever os casos todos (sobretudo se se tiverem em conta os outros formatos que se podem encontrar misturados com wikitext, nos quais não queria mesmo ter de pensar). A segunda opção pede claramente a utilização de uma folha de estilo XSLT (apesar de também existirem outro tipo de soluções). Convenientemente, encontrei algumas folhas de estilo que fazem já esta conversão, de xhtml para docbook. As mais promissoras foram:

• Uma disponibilizada no DocBook Wiki, escrita por Jeff Beal
• Uma extensão à anterior, que encontrei incluída num módulo de perl, escrito por Kathryn Andersen
• E finalmente, uma outra folha de estilo, com o mesmo objectivo mas escrita por Oliver Steele

Esta última é a mais completa, e com a qual as minhas experiências funcionaram melhor.

Agora basta juntar água (ou por outras palavras, usar os bindings do python para libxml e libxsl) e temos um plugin para o trac ;) A bem dizer, já ando a usar uma versão alpha deste plugin há uns meses. Na altura criei um espaço no trac-hacks para alojar o projecto. Nos próximos dias espero portar o código para o trac 0.11.1 e torná-lo usável por terceiros. Os interessados fiquem por perto ;)

Reparei num artigo do David Rodrigues em que é mostrada uma forma de encontrar ficheiros na Web (mp3, neste caso), e o qual me fez lembrar um artigo que escrevi há já uns tempos, sobre como encontrar câmaras de segurança livremente acessíveis na Web.

Sem dúvida, muito do mérito de pesquisas deste género é dos potentes algoritmos de classificação do google mas, mais importante nesta perspectiva, também da expressividade da sintaxe de pesquisa. A escrita de expressões de pesquisa no google tanto consegue ser feita por quem nunca o tenha feito antes, separando simplesmente uma série de palavras chave por espaços, ou pode ser feita por quem já tenha alguma experiência no assunto, usando operadores conforme necessário. Diguemos que é uma sintaxe desenhada para permitir uma aprendizagem progressiva.

Nota mental: tenho de dar uma vista de olhos mais a sério na especificação da CQL um dia destes.

Na próxima quinta e sexta vou estar nas jornadas “A Gestão de Informação na Era Digital”, realizadas na Trofa.

Há algum leitor deste blog que vá também lá estar?

No outro artigo que escrevi sobre formas de produzir documentos já houve quem desse alguns palpites interessantes, mas vou tentar resumir melhor as possibilidades que tenho considerado.

• Latex – Principais pontos fracos são a curva de aprendizagem (é fácil aprender o básico, mas perco tipicamente demasiado quando preciso de fazer algo de novo) e a sintaxe pouco amigável (sobretudo quando se usam tabelas ou se incluem imagens). Contudo, a qualidade de apresentação do resultado final é a melhor que conheço.
• Docbook – É XML e, por consequência , algo verboso. No entanto, consegue-se estruturar um documento de forma muito clara. As ferramentas de edição e processamento de docbook é que nem sempre funcionam de forma tão integrada quanto gostaria. Para windows o sistema mais integrado que conheço é o eDE (que faz uso de umas folhas de estilo XSLT que transformam Docbook em XSL-FO e do processador de XSL-FO da Apache).
• Wiki – Ao contrário da opinião de muita gente não acho a sintaxe do wiki tão amigável quanto isso, mas a verdade é que cumpre a sua função e mantém um certo grau de simplicidade. Por outro lado, as ferramentas que apoiam a edição são geralmente bem fraquinhas; mesmo repartindo por várias páginas os vários capítulos de um documento, as coisas começam a ficar difíceis de gerir quando existe conteúdo consideravelmente extenso em cada uma dessas páginas (convém gravar frequentemente, e cada gravação começa a demorar cada vez mais tempo à medida que aumenta a quantidade de texto a enviar para o servidor Web). Não é também, à partida, das abordagens mais orientadas a documentos impressos.
• ODF – Tanto quanto sei não é possível separar conteúdo de apresentação de forma clara. Neste momento a única implementação digna desse nome é o OpenOffice.
• OOXML – Além das desvantagens do ODF, é caro, considerando que para o usar é necessário contentarmo-nos com o MSOffice.
• GoogleDocs – Excelente para trabalho colaborativo mas tem na minha opinião umas quantas outras limitações.

Já vi, com base nestas opções, também uma solução híbrida entre um wiki e o docbook :) Um meu amigo criou um script python que exporta para docbook um conjunto de páginas de um mediawiki, para posterior geração de um PDF com o eDE. Aproveitam-se vantagens das duas abordagens e o resultado final é bastante decente. Mantêm-se no entanto as desvantagens de usar os limitado editores dos wikis.

Uma outra solução, que me parece promissora, é a que estão a usar no DjangoBook (um livro livre sobre o projecto django). Estão a usar um sistema (desenvolvido pelos próprios mentores do projecto) com umas funcionalidades engraçadas, nomeadamente, permite à comunidade comentar o livro que estão a escrever com a granularidade de parágrafos. A ideia é posteriormente exportar os conteúdos para um qualquer formato mais orientado à impressão. O código deste projecto não está disponível, mas encontrei entretanto um outro projecto paralelo, que é praticamente uma cópia do anterior. Ainda lhe devo dar uma vista de olhos com mais atenção, mas parece-me apesar de tudo algo aquém do que queria, sobretudo porque não vejo forma de versionar o documento e as limitações do editor que encontro num wiki mantêm-se também aqui.

Além destas, haverá mais alguma opção digna de nota?

Algo que volta e meia procuro sem sucesso é um método diferente de produção de documentos escritos, de forma a que:

• Mantenha um historial de versões facilmente comparáveis entre si – Usar um sistema de controlo de versões é a solução que me ocorre mais facilmente. Alguns sistemas (o subversion é um deles) portam-se aliás bastante bem com ficheiros binários (ie, poupam espaço guardando apenas as diferenças para a versão anterior), mas isso não permite necessariamente uma fácil comparação entre versões; para que as versões sejam facilmente comparáveis o formato deve ser de texto (pena eu não conseguir ler binário com a mesma fluência que leio texto ;)
• Possa escrever o documento sem me preocupar com forma como será formatado – Os estilos do MSOffice e do OpenOffice não chegam. Separar verdadeiramente o conteúdo da apresentação quer dizer que, se assim o entender, devo conseguir desenhar várias apresentações para um mesmo documento e de alternar entre elas facilmente;
• Existam boas ferramentas de edição – Neste ponto as ferramentas WYSIWYG são geralmente as mais integradas, mas por outro lado nada mais leve e simples que um editor de texto simples;
• Seja fácil de incluir imagens – As ferramentas WYSIWYG são as mais confortáveis neste ponto;
• Possibilite trabalho simultâneo e colaborativo sobre o mesmo documento – Embora não sinta a necessidade da “colaboração” ser em tempo real (como por exemplo no googledocs), é fácil que a edição conjunta de um documento se torne importante a partir do momento que exista mais que um autor. A publicação do documento na Web ao longo do processo de produção é também uma boa mais valia;
• O resultado final seja agradável à vista, tendo em atenção a impressão e a Web – Entre as duas, a “impressão” é a verdadeira questão. Se o objectivo for a produção de documentos apenas para a Web parece-me que um bom editor de XHTML pode resolver a questão;
• O formato de armazenamento não seja fechado – Mesmo dentro dos formatos abertos alguns são mais obscuros e/ou difíceis de manipular que outros, o que se torna importante do ponto de vista de preservação a longo prazo;
• Seja barato – Aliás, de preferência gratuito ;)

Nos próximos dias ainda conto escrever mais alguma coisa sobre as alternativas que tenho considerado.

Comecei a ficar ficar farto de colocar aqui como artigo todos os eventos relacionados com informática de que vou tendo conhecimento, de forma que criei um grupo para esse fim.

Os interessados podem inscrever-se livremente ou simplesmente subscrever a respectiva feed.

Nunca cheguei realmente a questionar o facto de, a partir de determinada altura, todos começarem a chamar aos endereços Web URIs, em vez de URLs (sobretudo no contexto da dita Web 2.0). O que começo a achar é que isso é completamente despropositado.

A razão da mudança, quer-me parecer, foi o facto de os URIs terem associada uma maior carga de “identificador único e imutável“, a qual não será das mais correctas. É um facto que ao falar em URLs ou em URIs não estamos a falar necessáriamente de algo imutável. Um URI é apenas um identificador único, o que significa que identifica um, e apenas um, determinado recurso. As orientações de boa utilização vão no sentido que estes identificadores não devem mudar ao longo do tempo, mas para que consideremos um dado identificador um URI não é, na realidade, fundamental que isso aconteça.

A melhor forma que conheço de evidenciar que um determinado URL não muda ao longo do tempo é chamar-lhe um Permalink (apesar de este ser um termo ainda muito ligado aos blogs). Chamar-lhe URI é acertar ao lado.

A bem dizer, um URL *é* um URI, assim como um URN também *é* um URI.

URI

Identifica univocamente um dado recurso;

URL

Identifica univocamente a localização da existência de um dado recurso;

URN

Identifica univocamente o nome de um determinado recurso.

Mais umas leituras sobre o tema:

• Architecture for the WWW – Identification
• Caving vs. Spelunking

Fui hoje assistir a algumas palestras das IV Jornadas Ciências de Informação. Tiveram hoje lugar na FEUP, amanhã será na FLUP.

Eis a razão porque tenho adicionado aqui menos informação últimamente. Acabo de terminar as alterações a este blog que me permitem a partir de agora adicionar etiquetas ao que publico. Cada etiqueta fica a ligar ao Technorati. Futuramente, quando tiver uma base de etiquetas razoável, haverei de adicionar outras funcionalidades, que disso tirem partido.