Escola de Engenharia	Departamento de Informática

Publicação Electrónica de um Inventário

Autores:

Docente:

O XML é uma meta linguagem standard, derivada do SGML, que permite a troca de informação estruturada entre plataformas heterogénias, como também possibilita a definição da estrutura dessa informação.

A crescente procura de informação de forma rápida e eficiente aliada à redução de custos, leva várias instituições ou autores a escrever essa informação em formatos electrónicos bastante utilizados, como por exemplo, os documentos «doc» do MS Word, os «pdf» da Adobe, os «html» para Web e outros, de forma a satisfazer um maior número de pessoas.

A realização deste trabalho surge da necessidade de uma instituição permitir o acesso a documentos antigos ou de edição única, que não podem estar sujeitos a uma excessiva utilização, devido ao seu frágil estado físico ou mesmo para evitar a degradação dos mesmos. Assim, torna-se inevitável a migração destes documentos, que se encontram em papel, para formato electrónico. Este trabalho mostra uma sequência de fases realizadas para efectuar essa migração.

Palavras-Chave: XML, DTD, Schema, Stylesheet.

1 - Introdução

Foi-nos proposta a realização de um trabalho com o objectivo de migrar um documento, que se encontra em papel, para um documento electrónico que seguisse uma estrutura bem definida e que permitisse a geração de vários formatos electrónicos.

Recorrendo à tecnologia XML é possível gerar tal documento electrónico estruturado, que ao mesmo tempo é portável para qualquer plataforma. Esta portabilidade deve-se à estandardização desta linguagem, bem como a todas as outras linguagens complementares, como o XSL, XSD, DTD, entre outras. Podemos dizer que um documento XML é um documento de formato neutro devido à sua portabilidade e fácil capacidade de gerar documentos de formatos electrónicos diferentes.

Esta solução é bastante utilizada por entidades que pretendem disponibilizar vários documentos em plataformas heterogénias. Assim, estas entidades evitam ter que gerar vários documentos de formatos electrónicos diferentes de um mesmo documento, que em muitas situações só eram alcançados manualmente. As bibliotecas são outra situação em que esta solução pode ser adoptada, visto que, permite disponibilizar aos utentes um serviço de pesquisa eficaz e facultar esses documentos em qualquer formato electrónico. Em alguns casos torna-se imperativo o uso de documentos electrónicos, por forma a permitir o acesso a estes, pois alguns desses documentos são históricos ou mesmo únicos, não estando acessíveis ao público.

Este relatório está dividido em secções, que descrevem os passos tomados para alcançar o objectivo final. É na secção Análise que descrevemos a análise efectuada ao documento e as decisões tomadas para obter uma estrutura que suportasse o documento em causa. A secção Desenvolvimento descreve as ferramentas desenvolvidas e utilizadas nas várias fases, desde o documento original até ao documento final (XML). São também descritas as scripts realizadas para obter documentos no formato HTML e LATeX. Na última secção, Conclusão, são apresentadas conclusões e sugestões para trabalhos futuros.

2 - Análise

Antes de definir qualquer tipo de estratégia para atingir o objectivo final, tivemos que analisar profundamente o documento em causa. A análise consistiu em indentificar informação relevante e o contexto em que essa informação se encontrava inserida, que permitisse alcançar uma boa estrutura para o documento. Assim começamos por identificar os elementos (a informação) folha, como por exemplo, nomes, lugares, entidades e outros, verificando o contexto em que estes se inseriam, e.g., parágrafos, séries, secções, entre outros.

Sendo este documento um inventário, reparámos que o autor atribuiu uma numeração geral a todos os livros inventariados. Mais se acrescenta, que o autor os dividiu em secções, fragmentando assim o inventário, atribuindo uma sub-numeração aos livros inseridos em cada fragmento. Este método de numeração utilizado pelo autor obrigou-nos a optar por uma de duas soluções possíveis: uma solução seria anotar a numeração, i.e., esta seria introduzida manualmente; a outra solução, por nós tomada, foi de gerar automaticamente essa numeração, produzindo-a fielmente segundo o documento original. Esta solução também foi assumida para outras situações análogas em que os elementos continham uma numeração. Esta fragmentação do inventário tornou a nossa estrutura complexa, mas mais flexível.

Foram identificados dois registos que agrupam um conjunto de livros, sendo esta uma situação bastante invulgar. Esta questão levantou-nos sérios problemas na sua resolução e por conseguinte levou-nos a ter duas considerações: a alteração da estrutura para que esta pudesse suportar esta situação e a não adulteração do contexto da numeração, para que não levasse a uma numeração incorrecta. Para tal, foi criado um elemento que agrupa esse conjunto de livros, sendo este numerado como um apenas, situação essa que se encontra também no documento original.

Foram também encontrados dois títulos no conteúdo do mesmo fragmento do inventário, situação essa que também teve que ser prevista na nossa estrutura.

Como este documento é um inventário e regista uma série de livros bastante antigos, encontramos duas palavras onde o caracter 'ẽ' e o 'ũ' aparecem. Como estes caracteres não fazem parte do nosso alfabeto acentuado, tivemos que criar dois elementos vazios, o etilde e o utilde, respectivamente, para os poder representar. O caracter '&' teve de ser também representado por um elemento vazio designado amp, devido a este ser usado para designar entidades no XML tornando assim um caracter reservado nesta linguagem.

Após a consideração de todas estas questões obtivemos o DTD que representa a estrutura final do documento original, que em seguida apresentamos:

O diagrama seguinte permite uma fácil leitura e compreensão do DTD por nós adoptado, para além de mostrar a complexidade da estrutura deste tipo de documentos. O diagrama e a sua respectiva notação gráfica, foi gerado automaticamente pela ferramenta XML SPY v4.0.1.

Figura 1 - Diagrama do DTD

3 - Desenvolvimento

Para tornar mais rápido e eficiente o desenvolvimento deste trabalho, decidimos dividi-lo em quatro fases. Cada uma destas fases realiza um subconjunto de acções pertencentes ao conjunto de acções necessárias para atingir o objectivo final. A primeira fase centra-se apenas na passagem do documento que se encontra em papel para um formato electrónico. Na segunda fase são tomadas acções para converter o documento obtido na fase anterior para um documento xml. Na terceira fase são desenvolvidas várias scripts para atingir o documento final em XML, que segue a estrutura especificada na análise. A última fase é dividida em duas sub-fases, nas quais são utilizadas scripts de transformação sobre o documento obtido na fase anterior, para gerar o documento em dois formatos electrónicos diferentes.

A figura seguinte representa o diagrama das quatro fases envolvidas.

Figura 2 - Diagrama das várias fases realizadas

3.1 - Fase 1

Esta fase teve como objectivo obter o documento original num formato electrónico e para isso recorremos à digitalização do mesmo, que foi gentilmente efectuada por um colega nosso. O formato electrónico escolhido foi o RTF, pela razão da existência de uma script Omnimark que converte este tipo de ficheiro para formato XML. No total, foram digitalizadas 37 páginas que geraram 37 ficheiros RTF.

3.2 - Fase 2

Após a conclusão da fase anterior, o objectivo desta foi converter os documentos RTF para um só documento XML. Para alcançar este objectivo recorremos a uma script Omnimark disponibilizada publicamente e denominada por rtf2xml.xom. Esta permite receber um conjunto de ficheiros RTF e convertê-los para um documento XML. Devido à nomenclatura dada aos ficheiros RTF, com o formato pagX.rtf, em que X representa o número da página com o número de digitos suficiente para representar o número dessa página, e.g., pag1.rtf e pag10.rtf, a passagem dos documentos RTF não era feita de forma ordenada. Para solucionar este problema procedemos à renomeação de apenas alguns ficheiros para o formato pagYY.rtf, em que Y representa um dígito. Por exemplo, o ficheiro pag1.rtf passou a denominar-se por pag01.rtf.

3.3 - Fase 3

Esta fase envolveu um conjunto de várias scripts que nos permitiu atingir o documento final XML. Concluída a fase 2, obtivemos um documento XML que continha meta informação referente aos ficheiros RTF, para além de a script da fase 2 ter codificado todos os caracteres acentuados com o respectivo Unicode. Para filtrar a meta informação e devolver a representação gráfica desses caracteres, utilizámos a stylesheet filtra.xsl. Apercebemo-nos que muitos elementos tinham o seu conteúdo vazio e, não sendo estes elementos relevantes no contexto, procedemos à sua remoção. Foi também efectuada a remoção dos espaços entre os elementos. Para efectuar tais remoções aplicou-se a stylesheet denominada por rm_spaces_and_empty_para_strings.xsl. Deparámo-nos com um caracter de representação gráfica idêntica à do hífen, devido à má conversão efectuada pelo processo de digitalização e, por esse facto, desenvolvemos a script rm_special_char.pl que procede à remoção desse mesmo caracter.

Neste momento, analisamos o documento XML obtido e verificamos que não era possível desenvolver uma script para anotar todo o documento, procedendo assim à sua anotação manual. Chegámos a uma fase em que denotámos que era possível desenvolver uma script que anotasse o elemento data em cada registo do inventário. Assim, esta script analisava o conteúdo do registo, determinando se existia um intervalo de anos ou se apenas existia o valor de um ano. Baseado nessa análise criava o elemento data com esse conteúdo, preenchendo os atributos inerentes a este elemento. Por exemplo, quando encontra a data 1753-1800, cria o seguinte elemento: <data inicio="17530101" fim="18001231">1753-1800</data>; no caso de encontrar a data 1650, o elemento é o seguinte: <data inicio="1650101" fim="16501231">1650</data>.

3.4 - Fase 4

Na fase 4 optámos por gerar dois formatos electrónicos, HTML e LATeX, e por conseguinte, subdividir esta fase conforme a Figura 2. Na fase 4-A foi necessário desenvolver uma script usando o módulo XML::DT, que nos permite atribuir a numeração geral a todos os registos do inventário e guardar essa numeração no atributo 'geral' do elemento registo, gerando um novo documento XML. Para obter o resultado final em HTML, foi desenvolvida uma stylesheet que segue a apresentação gráfica do documento original.

Para atingir o objectivo da fase 4-B, é utilizado o documento XML gerado na fase 4-A, sobre o qual foi executada a stylesheet format.xsl. Esta tem por objectivo introduzir a numeração automática no conteúdo dos elementos. Não sendo esta abordagem a mais correcta, pois o LATeX permite efectuar numeração automática, foi tomada esta decisão devido ao pouco conhecimento sobre este formato electrónico. Para conseguir o documento LATeX foi desenvolvida uma script Omnimark, que é aplicada ao documento XML gerado pela stylesheet anterior.

4 - Conclusões

Este trabalho permitiu-nos aprofundar o conhecimento numa área que se encontra em expansão e que é cada vez mais utilizada em soluções comerciais. O sucesso desta tecnologia deve-se à portabilidade da linguagem XML, verificada também por outras tecnologias, nomeadamente o Java.

Tentámos utilizar uma grande variedade de ferramentas, por forma a permitir um rápido e eficiente desenvolvimento do trabalho, como também expandir o nosso conhecimento na utilização destas ferramentas.

Durante o desenvolvimento deste trabalho apercebemo-nos da dificuldade de implementação de um processo automático de migração de documentos, visto que não é garantido que um documento com estrutura semelhante seja processado com sucesso. Desenvolver um processo de migração genérico é inviável, devido ao elevado número de documentos com estruturas diferentes que, caso fosse possível, obrigaria o processo a suportar todas essas estruturas. Logo, conclui-se que a migração de documentos semelhantes ao deste trabalho representa custos elevados para qualquer entidade, tornando-a monetariamente inviável para muitas destas.

Para trabalho futuro achamos interessante incluir flow-objects por forma a permitir a geração de mais formatos electrónicos de forma mais rápida e eficaz.

Bibliografia