Java e XML
Agora que você já tem conhecimento básico sobre XML, podemos começar a ver como podemos usar XML nas aplicações Java. Você vai aprender a ler e a criar documentos Java com algumas APIs Java.
O objetivo deste post é mostrar o que é um parser XML.
O que é um Parser?
Um parser é nada mais e nada menos que um pedaço de código que faz a leitura de um documento XML e analisa a sua estrutura.
Como utilizar um parser?
Em geral, você executa os seguintes passos para usar um parser: criar um objeto do tipo parser; Aponta o parser para o seu documento XML; Processa os resultados.
É claro que a última parte é a mais complicada (rs)! Depois que você sabe qual é o conteúdo do XML, você pode fazer várias coisas.
Tipos de parsers
Os parsers são organizados em algumas categorias:
- Parsers que fazem validação e parsers que não fazem validação
- Parsers que suportam a linguagem de XML Schema
- Parsers que suportam o DOM (Document Object Model)
- Parsers que suportam o SAX (Simple API for XML)
Parsers que fazem validação e parsers que não fazem validação
Bem, como já vimos nos posts antigos, existem três diferentes tipos de documentos XML:
- Documentos bem formados (aqui), que seguem as regras básicas do XML;
- Documentos válidos, que são documentos bem formados, além de seguirem um conjunto de regras especificados (aqui) em um DTD (aqui) ou XML Schema (aqui);
- Documento inválidos: os que não seguem as regras dos documentos acima.
Se um parser XML encontra alguma coisa que torna o XML um documento não bem formado, a especificação XML requer que o parser reporte um erro fatal (fatal error). Os parsers que fazem validação, validam o documento XML à medida que fazem sua leitura, ou seja, se um documento XML é bem formado, um parser que não faz validação, não se importa se o documento segue as regras especificadas em um DTD ou Schema.
Mas por qual razão deveria utilizar um parser que não faz validação? Duas boas razões: velocidade e eficiência. Você perde um pouco da eficiência quando o parser tem que ler um DTD ou Schema, e depois configurar as regras de formação na engine que faz com que todo elemento e atributo do documento XML esteja correto de acordo com as regras. Se você tem certeza de que o documento é válido (por exemplo, o documento pode ter sido gerado por uma outra aplicação que pegou as informações de um banco de dados), você pode colocar a validação em off. Dependendo de como as regras são (podem ser bem complicadas), você pode economizar um tempo significativo e também memória.
Se você escreveu um código que tem como input de informações um documento XML, e este código requer que este documento XML siga as regras de um DTD ou Schema, você provavelmente deverá validar todo o documento, independente do custo computacional para fazer isto. Mas é claro que isso vai depender da aplicação.
Parsers que suportam a linguagem de XML Schema
A especificação original do XML definiu o DTD como a maneira de definir como um documento XML deveria ser. Os DTDs têm uma sintaxe diferente dos documentos XML, dificultando o entendimento em algumas vezes. Para contornar essas limitações, O W3C criou a linguagem XML Schema. A linguagem XML Schema é muito rica, os documentos de XML Schema podem ser bem complexos. Por esta razão, os parsers que dão suporte a Schema costumam ser maiores.
Parsers que suportam o DOM (Document Object Model)
O DOM é uma recomendação oficial do W3C. É definida uma interface que permite aos programas acessarem e fazer updates na estrutura do XML.
Este assunto será abordado com mais detalhes em um post futuro.
Parsers que suportam o SAX (Simple API for XML)
SAX é uma alternativa para se trabalhar com documentos XML. Foi designado para ter uma memória menor, mas deixa mais trabalho para o programador. O SAX e o DOM dão complementares, cada um é apropriado para diferentes ocasiões.
Este assunto também será abordado em um post futuro.
Conclusão
Agora você já sabe o que é um parser.
Os posts futuros abordarão DOM, SAX, outras APIs Java e frameworks open-source que facilitam muito o nosso trabalho ao manipular arquivos XML.
Até a próxima!
Comments (1)
Links to this Post