Estrutura dos documentos XML

Autor: Nelson Henrique Zanete

RESUMO

Em recentes sistemas de biblioteca digital ou ambiente World Wide Web, muitos documentos estão começando a ser disponibilizados no formato estruturado, e etiquetados com linguagens de marcação como SGML e XML. [3] No intuito de facilitar a edição e recuperação de informações, interpretadores e analisadores sintáticos para este tipo de documento, têm sido criados. Neste artigo, são abordadas algumas ferramentas e técnicas para o desenvolvimento de programas utilitários de escrita e recuperação de informações em documentos estruturados. A idéia básica consiste em criar documentos XML de boa-formação e cuidar para que tais ferramentas não produzam respostas errôneas.

1. Introdução

A maioria das ferramentas de edição de documentos XML já garante a construção de um documento de boa-formação. Documento de boa-formação é aquele em que os seus elementos aninham-se de forma apropriada, criando uma estrutura na forma de árvore. Um documento XML de boa-formação é particularmente apropriado para uso na World Wide Web, porque ele pode ser processado com ferramentas simples. Ele consistirá de uma mistura de strings de caracteres conhecidas coletivamente como marcação, juntamente com o conteúdo de informações verdadeiro do documento, conhecido como dados de caracteres. [2] Exemplos de marcação incluem tags de início e término, comentários, etc. As ferramentas e técnicas abordadas nesse artigo requerem que os documentos estejam de acordo com o padrão XML, ou seja, devem estar bem-formados. Este artigo também descreve como estas ferramentas interpretam e processam as informações dos documentos XML, fornecendo uma visão dos processos de interpretação e, conseqüentemente, alertando para as possíveis respostas errôneas retornadas pelas ferramentas. O artigo está organizado como segue: Seção 2 propõe formas de verificação da estrutura dos documentos XML. Seção 3 apresenta os problemas com o uso de ferramentas não apropriadas para XML. Seção 4 propõe alternativas para leitura/gravação em documentos XML. Seção 5 apresenta as considerações finais com algumas sugestões adicionais.

Palavras chaves: XML, Interpretadores XML, DOM.

2. Estrutura

Para ser capaz de conter coisas, os documentos precisam ter um tamanho finito. [1] O tamanho finito de um documento é obtido através de tags iniciais e tags finais, as quais marcam as delimitações de um elemento (seu começo e seu fim) e todos os elementos aninhados formam o documento. Dois documentos XML podem diferir em sua estrutura física (tags + dados de caracteres), mas podem ser equivalentes em sua estrutura lógica (tags). Uma das formas de verificar se dois documentos XML fisicamente diferentes possuem a mesma estrutura lógica é através do subconjunto de informações contido nele e uma sintaxe para expressar aquele subconjunto. Esta sintaxe, chamada de XML canônica, é projetada para codificar a estrutura lógica de documentos XML. Se um documento de XML é mudado por uma aplicação, mas sua forma XML-Canônica não mudou, então o documento mudado e o documento original são considerados equivalentes para a finalidade de muitas aplicações. [4] Esta especificação canônica é útil para introduzir a noção de equivalência entre documentos XML e que podem ser testados como sintático, em particular, através da comparação byte-a-byte. Na sintaxe, é descrito que documentos logicamente equivalentes são idênticos byte-a-byte. Documentos XML podem ser transformados em XML canônico (com potencialmente alguma perda de informação), e o resultado desta transformação é descrito como a forma canônica do documento original.

Observe o conteúdo do documento e1.xml e o exemplo minimalista:

e1.xml

Hello World!!

Documento A

<!DOCTYPE d [

               <!ENTITY lsb '['>

               <!ENTITY rsb ']'>

               <!ENTITY hello SYSTEM "e1.xml">

]>

<d>&lsb;&hello;&rsb;</d>

As duas entidades lsb e rsb são consideradas entidades internas do documento "A", diferentemente de e1.xml, que se refere a uma entidade externa. A última linha do documento reúne as três entidades entre as tags "<d>" e "</d>" através da concatenação do "&" + nome_entidade + ";". Quando um documento fisicamente escrito dessa forma é convertido para a forma canônica o resultado é apresentado como:

<d>[Hello World!!]</d>

A forma canônica de um documento XML é um documento XML. Então um segundo documento "B" escrito fisicamente como segue, seria equivalente logicamente ao primeiro documento fisicamente diferente A:

Documento B

<d>[Hello World!!]</d>

3. Ferramentas não apropriadas para XML

A natureza de texto simples dos documentos XML torna-os muito fáceis de se trabalhar usando toda uma variedade de ferramentas, desde editores-padrão até linguagens de script. [2] A conveniência de utilizar ferramentas de escrita e recuperação de informações não apropriadas para documentos XML, mesmo que para pesquisas simples, podem resultar em respostas errôneas. Para ilustrar os resultados, considere a tarefa de contagem de elementos "<NOME>" em um documento.

<?xml version = "1.0"?>

<PCS>

<PC>

  <NOME>IBM</NOME>

  <PRECO>2300</PRECO>

</PC>

<PC>

  <NOME>ITAUTEC</NOME>

  <PRECO>2100</PRECO>

</PC>

<PC>

  <NOME>HP</NOME>

  <PRECO>2300</PRECO>

</PC>

</PCS>

A contagem dos elementos "<NOME>" com utilitários de pesquisa de texto simples (não baseado em XML) normalmente resulta uma resposta correta, ou seja "3" ocorrências encontradas. Entretanto, como visto anteriormente, variações na estrutura física de documentos podem ocorrer, causando problemas para ferramentas que utilizam a mesma abordagem, pois elas não reconhecem sintaticamente as marcações XML. Um destes problemas está no uso de entidades, pois como as ferramentas não baseadas em XML ignoram as referências às entidades em um documento, elas não são capazes de retornar os elementos contidos em tais entidades. Isso pode ser visto a seguir:

<?xml version = "1.0"?>

<!DOCTYPE PCS [

<!ENTITYcap100 "<CAPACIDADE>100</CAPACIDADE>">]>

<PCS>

<PC>

<NOME>IBM</NOME>

&cap100;

<PRECO>2300</PRECO>

</PC>

<PC>

  <NOME>ITAUTEC</NOME>
  &cap100;

<PRECO>2100</PRECO>

</PC>

<PC>

<NOME>HP</NOME>

<CAPACIDADE>300</CAPACIDADE>

<PRECO>2300</PRECO>

</PC>

</PCS>

Considere a contagem do elemento "<CAPACIDADE>", o problema aqui é causado pelo fato de o texto de substituição "cap100" de entidades poder conter marcações. Neste caso, o utilitário encontraria apenas duas ocorrências do elemento CAPACIDADE e não três ocorrências, como seria correto.

4. Alternativas para Leitura/Gravação em documentos XML

Algumas alternativas convenientes para inibir problemas no processo de recuperação de informação podem ser realizadas. Uma dessas alternativas está no uso de ferramentas de interpretação de documentos XML, antes da leitura ou escrita de tais informações. O interpretador EsisDemo, que acompanha o processador da XML Ælfred, desenvolvido por David Megginson da Microstar Corporation, é um exemplo deste tipo de ferramenta. O formato resultante desse interpretador é simples e orientado à linha. Cada "evento" importante da XML, tais como tags iniciais e tags finais, aparece como uma única linha de saída. O início e final de um elemento são indicados respectivamente por "(" e ")". As linhas iniciando por "A" indicam um atributo e seu valor, as linhas iniciando por "-" indicam dados de caracteres e as iniciando por "?" indicam instruções de processamento. Algumas construções de marcação como comentários não são partes do resultado. Caracteres especiais como os que representam linhas novas são ignorados, isto é, esses caracteres aparecem como "/n".

Observe, abaixo, o formato resultante do documento acima, após o uso do interpretador. As colunas, em seqüência, formam um único documento texto. O utilitário acima, que contou erroneamente duas ocorrências para o elemento CAPACIDADE, utilizado-se com este formato interpretado, do mesmo documento, retornaria uma resposta correta, ou seja, três elementos. Observe no formato resultante que as referências às entidades, foram convertidas em seu respectivo texto de substituição, e ainda assim seriam, mesmo que as entidades fossem externas. (um arquivo externo).

(PCS

-\n

(PC

-\n

(NOME

-IBM

)NOME

-\n

(CAPACIDADE

-100

)CAPACIDADE

-\t\n

(PRECO

-2300

)PRECO

-\n

)PC

-\n

(PC

-\n

(NOME

-ITAUTEC

)NOME

-\n

(CAPACIDADE

-100

)CAPACIDADE

-\n

(PRECO

-2100

)PRECO

-\n

)PC

-\n

(PC

-\n

(NOME

-HP

)NOME

-\n

(CAPACIDADE

-300

)CAPACIDADE

-\n

(PRECO

-2300

)PRECO

-\n

)PC

-\n

)PCS

Fig.1 Formato resultante do interpretador EsisDemo

No formato resultante, orientado à linha, um processamento de escrita em batch poderia ser realizado (como por exemplo, um acréscimo de 10% no valor dos PC’s) e novamente convertido para a forma de XML. Devemos alertar para alguns problemas com a alternativa de interpretação de documentos XML antes da leitura ou escrita. De modo geral os interpretadores XML procuram afastar o usuário da estrutura física do documento e apenas comunicar informações referentes à estrutura lógica. Esta postura faz com que o documento seja convertido em uma única estrutura lógica não preservando informações de referências às entidades. A partir do momento que as referências às entidades são perdidas, eliminamos qualquer possibilidade de conversão para a forma original do documento. No formato resultante, perdemos a informação de que o elemento CAPACIDADE para os dois primeiros PC’s são uma única entidade. A conseqüência deste fato poderia se agravar se as entidades fossem externas aos documentos e "processadas" por outros aplicativos.

5. Conclusão

Depois de conhecer como as ferramentas tratam e interpretam a estrutura lógica e física dos documentos XML, observamos que as ferramentas não específicas para XML não são confiáveis, mesmo quando utilizadas com documentos bem-formados. Por outro lado, as ferramentas de interpretação apropriadas para XML, que são mais confiáveis, também não oferecem resultados satisfatórios, principalmente quando utilizadas para escrita. Uma consideração importante, quando se planeja escrever utilitários para alterar documentos XML, é com relação à estrutura física destes documentos. Além da boa-formação da estrutura lógica, a estrutura física deve ser mantida, a ponto de reconhecer todas as referências às entidades externas, o que possibilita, se necessário, o trabalho ou acesso com outros aplicativos vinculados a esta entidade. Uma tecnologia emergente, capaz de lidar com a preservação das estruturas das entidades, a qual recomendamos é a tecnologia DOM –Document Object Model.

O Modelo de Objeto de Documento provê um conjunto padrão de objetos para representar documentos HTML e XML, um modelo padrão de como estes objetos podem ser combinados, e uma interface padrão para acessá-los e manipulá-los.[5] A especificação consiste em um núcleo (core), que fornece um conjunto de objetos de baixo nível que podem representar qualquer tipo de documento estruturado. Este conjunto de objetos oferece "operações" para lidar com os diversos elementos da árvore que compõe um documento. Um documento estruturado é representado no DOM como uma árvore, onde cada nó, com exceção do nó raiz, possui um nó pai associado, e esses objetos permitem as funcionalidades básicas de leitura e escrita dos elementos da árvore.

Referências

1. LIGHT, R. Iniciando em XML. São Paulo: Makron Books, 1999. p. 79-89

2. McGRATH, S. XML: aplicações práticas. Rio de Janeiro: Campus, 1999. 368 p.

3. SHIN, D.; JANG, H.; JIN, H. BUS: An effective indexing and retrieval scheme in structured documents. Republic of Korea: Chungnam National University, 1998. p. 1.

4. WORLD WIDE WEB CONSORTIUM (W3C). Canonical XML version 1.0 W3C working draft: June 1, 2000. Disponível em: http://www.w3.org/TR/xml-c14n. Acesso em: 09 jun. 2000.

5.Document Object Model (DOM) Level 1 Specification Version 1.0: October 1, 1998. Disponível em: http://www.w3.org/TR/ 1998/REC-DOM-Level-1-19981001/. Acesso em: 09. jun. 2000.