MARCUS BARBOSA PINTO
UMA PROPOSTA PARA INTEGRAÇÃO DE ESQUEMAS
PARA DOCUMENTOS XML
Palmas
2003
MARCUS BARBOSA PINTO
UMA PROPOSTA PARA INTEGRAÇÃO DE ESQUEMAS
PARA DOCUMENTOS XML
“Monografia apresentada como
requisito parcial da disciplina de
Prática
de
Sistemas
de
Informação II, orientada pela
Profª. Deise de Brum Saccol”
Palmas
2003
MARCUS BARBOSA PINTO
UMA PROPOSTA PARA INTEGRAÇÃO DE ESQUEMAS
PARA DOCUMENTOS XML
“Monografia
apresentada
como
requisito parcial da disciplina de Prática
de Sistemas de Informação II, orientada
pela Profª. Deise de Brum Saccol”
Aprovado em Dezembro de 2003
BANCA EXAMINADORA
_____________________________________________
Profª. Deise de Brum Saccol
Centro Universitário Luterano de Palmas
_____________________________________________
Prof. Eduardo Kessler Piveta
Centro Universitário Luterano de Palmas
_____________________________________________
Profª. Parcilene Fernandes de Brito
Centro Universitário Luterano de Palmas
Palmas
2003
“O homem é capaz de partir e de chegar. Mas, o
que o define mesmo é a estrada. Mais do que ser de
chegada e de partida, o homem é um ser da
estrada. É um eterno caminhante. É um peregrino
destinado. É um estradeiro infatigável. Não resiste
ao apelo do horizonte misterioso que lhe pede
novos passos".
Arduini
DEDICATÓRIA
Para meus pais, Antônio Jorge Pinto e Elza Maria Barbosa Pinto, aos meus irmãos,
Maurício Barbosa Pinto e Murilo Barbosa Pinto e à minha querida sobrinha e afilhada
Wanessa Miranda Borges Pinto, simplesmente por fazerem parte da minha vida,
minimizando os obstáculos que freqüentemente dificultam minha caminhada e fazendo
valer a pena cada esforço. Obrigado por vocês existirem.
Para Adryelle Castro Coelho, Álvaro Nunes Prestes, Cristina Dornellas Filipakis, Danilo
de Abreu Noleto, Deise de Brum Saccol, Eduardo Kessler Piveta, Eduardo Leal, Fabiano
Fagundes, Helena Jorge Pinto, Liliam Deisy Ghizoni, Michael Schuenck dos Santos,
Parcilene Fernandes de Brito e Pollyane de Almeida Lustosa, pelo incentivo, paciência e
colaboração demonstrados ao longo desse ano.
AGRADECIMENTOS
Agradeço primeiramente a Deus por ter permitido que o meu caminho se cruzasse com o
caminho de tantas pessoas maravilhosas. Foram tantos os momentos de satisfação e alegria
que as dificuldades encontradas anteriormente parecem tão insignificantes. Obrigado, Pai,
por ter permitido esses encontros.
Agradeço a minha orientadora, Deise de Brum Saccol, pela flexibilidade, companheirismo,
confiança e atenção demonstrados durante todo esse tempo de convivência universitária.
Obrigado por tudo.
Agradeço aos amigos, Fabiano Fagundes e Parcilene Fernandes pelo apoio, credibilidade e
incentivo expressos desde o primórdio do NET (Núcleo Especial de Treinamento em
Informática) até os dias atuais.
Agradeço aos amigos, Danilo de Abreu Noleto, Michael Schuenk dos Santos e Pollyane
de Almeida Lustosa que compartilharam comigo os fracassos, as descobertas e as alegrias
proporcionados durante a fase de conclusão desse trabalho.
SUMÁRIO
1.
INTRODUÇÃO ......................................................................................................... 14
2.
REVISÃO DE LITERATURA................................................................................. 16
3.
4.
2.1
Dados Semi-estruturados .................................................................................... 16
2.2
Extensible Markup Language.............................................................................. 17
2.3
Document Type Definition................................................................................... 19
2.4
Data Guide .......................................................................................................... 21
2.5
XML Schema........................................................................................................ 25
2.6
Integração de esquemas XML ............................................................................. 27
2.7
Processo de integração de esquemas .................................................................. 29
2.8
Arquitetura JAXB ................................................................................................ 35
MATERIAIS E MÉTODOS..................................................................................... 37
3.1
Local e Período ................................................................................................... 37
3.2
Materiais.............................................................................................................. 37
3.3
Metodologia......................................................................................................... 37
RESULTADOS E DISCUSSÕES ............................................................................ 39
4.1
Proposta .............................................................................................................. 39
4.2
Estudo de caso ..................................................................................................... 42
4.3
Geração de DTD a partir de um documento XML.............................................. 45
4.4
Representação da DTD em formato XML ........................................................... 48
4.5
A ferramenta PINAJÉ.......................................................................................... 50
4.5.1
O processo de Integração da ferramenta...................................................... 50
4.5.2
Utilização..................................................................................................... 53
4.5.3
Arquivos de entrada..................................................................................... 55
4.5.4
Carregando documentos .............................................................................. 56
4.5.5
Instanciando objetos .................................................................................... 57
4.5.6
Identificando elementos e atributos na lista ................................................ 59
4.5.7
Classe ManipulaElemento ........................................................................... 61
4.5.7.1
Método nomeIgual(String nome) ............................................................ 61
4.5.7.2
Método nomeIgualTipoDiferente(String nome, String tipo)................... 61
4.5.7.3
Método integraNomeIgualTipoDiferente(Pai P) ..................................... 63
4.5.7.4
Método integraNomeIgualTipoIgual(Pai P)............................................ 64
4.5.7.5
Método insereElemento(int indice, Elemento E) .................................... 65
4.5.8
Classe ManipulaAtributo............................................................................. 66
4.5.8.1
Método nomeIgual(String elem,String nome)......................................... 66
4.5.8.2
Método nomeIgualTipoIgual(String elem,String nome, String Tipo)..... 67
4.5.8.3
Método integraNomeIgualTipoIgual(String elem,Atributo A) ............... 68
4.5.8.4
Método integraNomeIgualTipoDiferente(String elem,Atributo A) ........ 69
4.5.8.5
Método insereAtributo(Atributo A, String elemento) ............................. 70
5.
CONSIDERAÇÕES FINAIS.................................................................................... 72
6.
REFERÊNCIAS BIBLIOGRÁFICAS .................................................................... 74
LISTA DE FIGURAS
Figura 1 – Exemplo de um documento XML.................................................................. 18
Figura 2 – Exemplo de uma DTD .................................................................................... 21
Figura 3 – Objeto atômico ................................................................................................ 22
Figura 4 - Objeto complexo .............................................................................................. 23
Figura 5 – Exemplo de um Data Guide ........................................................................... 24
Figura 6 - Arquitetura para um sistema mediador (MELLO, 2002) ........................... 32
Figura 7 - Processo de integração de esquemas [MEL 2002] ........................................ 34
Figura 8 – Parte de um documento XML Schema ......................................................... 36
Figura 8 – Arquitetura de integração de esquemas ....................................................... 41
Figura 9 – Exemplo de declaração de atributo não permitida ...................................... 42
Figura 10 – Exemplo de declaração de elemento não permitida................................... 42
Figura 11 – Parte de um documento XML representando uma monografia .............. 44
Figura 12 - DTD gerada a partir de um documento XML ............................................ 48
Figura 13 - DTD representada por um documento XML.............................................. 50
Figura 14 – Exemplo da utilização da ferramenta PINAJÉ com dois arquivos .......... 55
Figura 15 – Carregando um documento xml .................................................................. 56
Figura 16 – Instanciando objetos ..................................................................................... 59
Figura 17 – Identificando elementos e atributos ............................................................ 60
Figura 18 – Parte do esquema utilizado para a criação das classes.............................. 60
Figura 19 – Exemplos de elementos com mesmo nome e tipos diferentes.................... 62
Figura 20 – Exemplos do código do método nomeIgualTipoDiferente ........................ 62
Figura 21 – Exemplos da integração de elementos......................................................... 63
Figura 22 – Exemplos do código do método nomeIgualTipoDiferente ........................ 64
Figura 23 – Exemplo de elementos diferentes com nomes e tipos iguais...................... 64
Figura 24 – Código do método integraNomeIgualTipoIgual ........................................ 64
Figura 25 – Exemplo de integração de elementos com tipos nulos ............................... 65
Figura 26 – Exemplo de integração de elementos mistos............................................... 65
Figura 27 – Inserindo novos elementos ........................................................................... 66
Figura 28 – Código do método nomeIgualTipoIgual da classe ManipulaAtributo ........ 67
Figura 29 – Exemplo de atributos com padrões de declarações diferentes.................. 68
Figura 30 – Parte do código do método integraNomeIgualTipoDiferente da classe
ManipulaAtributo ........................................................................................................ 69
Figura 31 – Parte do código do método insereAtributo(...) ........................................... 70
LISTA DE TABELAS
Tabela 1 – Tabela de marcações básicas (ANDERSON, 2001) ..................................... 19
Tabela 2 – Tipos de atributos (ANDERSON, 2001) ....................................................... 20
Tabela 3– Nomenclatura dos arquivos gerados pelas ferrementas............................... 54
Tabela 4 – Exemplo do processo de integração .............................................................. 57
RESUMO
Dados representados em XML podem ser considerados dados semi-estruturados. Dados
semi-estruturados possuem como características marcantes uma estrutura irregular,
dinâmica e heterogênea. Em função disto, a definição de um esquema único que valide
vários documentos pode não ser uma tarefa muito simples. Para ter acesso a esses dados,
comumente as aplicações baseiam-se nos esquemas que estão relacionados aos
documentos. Porém é possível que existam documentos sem nenhum esquema relacionado
ou ainda documentos referentes a um mesmo domínio com esquemas diferentes. A geração
de um esquema para os documentos que não o possuem e sua integração com os demais
esquemas existentes pode solucionar o problema mencionado. Neste sentido, este trabalho
ojetiva desenvolver uma ferramenta de integração de esquemas XML, visando a
automatização desse processo e diminuindo a necessidade de intervenção do usuário.
Palavras-chave: Esquemas para documentos XML, integração de esquemas, DTD
ABSTRACT
Data represented in XML can be considered semistructured data. Semistructured data have
some characteristics, as irregular, dynamic and heterogeneous structure. Because of that,
the definition of an unique schema that validates several documents can be a hard task. To
have access to these data, usually the applications base on the schemas that are in
accordance with the documents. However, it is possible the existence of documents
without schema or documents related to the same domain with different schemas. The
schema generation for documents that do not have it and its integration with the others can
solve the mentioned problem. In this sense, this work aims to develop an integration tool of
XML schemas, being aimed at the automatization of this process and decreasing of user
intervention.
Keywords: XML, structures for XML documents, DTD
14
1. INTRODUÇÃO
O crescente número de informações disponibilizadas eletronicamente através da
Web é consequência da popularização da internet e do aumento constante do número de
novos usuários. Uma característica comum entre a maior parte desses dados é a forma com
que são disponibilizados, não obedecendo a um padrão específico, principalmente por
possuírem estruturas irregulares, dinâmicas e bastante heterogêneas.
Inúmeras pesquisas estão sendo desenvolvidas na tentativa de propor um modelo
que possa dar uma certa estrutura a esses dados, possibilitando, desta forma, um melhor
acesso a esses dados (XML, 2003). A linguagem XML apresenta-se como uma alternativa
bastante satisfatória para representação destes dados.
Atualmente, a linguagem XML tem sido muito utilizada para representação e troca
de dados. Sua aceitação como mecanismo principal para representação e troca de dados
semi-estruturados, pode ser percebida no aumento do número de pesquisas relacionadas a
essa nova tecnologia. A tendência é a padronização dessa linguagem como principal
mecanismo para representação e intercâmbio dos dados que apresentam uma estrutura
irregular (MELO, 2001).
Assim como a comunidade científica está acreditando na utilização desse novo
recurso para representação e intercâmbio de dados semi-estruturados, a área comercial
também investe nessa nova tecnologia. O surgimento de bancos de dados específicos
(Tamino, Lore etc.) e a incorporação desse recurso à ferramentas bastante conhecidas
(Delphi, Oracle etc) é uma prova dessa aceitação.
Todavia, a irregularidade das estruturas dos documentos representados pela
linguagem XML dificulta o acesso automatizado a esses dados. Uma aplicação XML deve
ser flexível o suficiente para suportar as alternativas de representação que um determinado
dado pode possuir. Buscando englobar todos esses dados, é comum as ferramentas
utilizarem-se do esquema relacionado para alcançarem esse objetivo.
Um esquema XML deve prever quais elementos são encontrados nos documentos,
a ordem em que estes elementos estão dispostos, o tipo de dados do conteúdo de cada
15
elemento etc. Essas informações disponibilizadas pelo esquema podem ser utilizadas para
diversos fins. Entretanto, devido a grande heterogeneidade que envolvem os documentos
XML, é possível que existam esquemas diferentes referentes a um mesmo domínio de
aplicação. A integração de esquemas XML referentes a um domínio específico pode ser
uma alternativa satisfatória para solucionar o problema mencionado.
O objetivo dessa monografia é disponibilizar uma alternativa para a integração de
esquemas XML. Desta forma, torna-se necessário o conhecimento de alguns mecanismos
que funcionam como esquemas para dados representados através dessa linguagem e o
conhecimento de algumas regras encontradas na literatura para a integração de esquemas.
A seção 2, deste trabalho, apresenta um levantamento teórico sobre algumas tecnologias
relacionadas a linguagem XML. O capítulo 3 especifica os materiais utilizados para o
desenvolvimento do trabalho. Os resultados e discussões, presentes no capítulo 4,
apresentam as características principais do processo de integração utilizado nesse trabalho.
O capítulo 5 é referente às considerações finais.
16
2. REVISÃO DE LITERATURA
Nesta seção são discutidos alguns pontos relevantes para o trabalho. As
considerações, observações e as conclusões alcançadas foram baseadas nos estudos e
pesquisas realizadas. Os temas abordados nesta seção estão relacionados à tecnologia
XML.
2.1
Dados Semi-estruturados
Dados armazenados em SGBDR’s (Sistemas Gerenciadores de Banco de Dados
Relacionais) são considerados dados estruturados. O fator de maior relevância para a
afirmação acima está relacionado à sua estrutura, a qual é definida antes do conhecimento
dos dados (definição de esquema a priori). Portanto, espera-se que os dados sigam um
mesmo padrão, diferentemente dos dados semi-estruturados que podem não seguir.
Os dados semi-estruturados possuem como características principais uma estrutura
irregular, dinâmica e bastante heterogênea. Um exemplo típico destes tipos de dados pode
ser encontrado nos dados da Web. A grande maioria dos dados existentes na internet não
estão armazenados de forma estruturada e não seguem um padrão único, sendo
considerados portanto dados semi-estruturados.
A busca por mecanismos que auxiliam o entendimento tanto por aplicações quanto
pelo homem está tornando-se freqüente na área científica. A linguagem XML vem se
destacando como um mecanismo de fundamental importância e tornando-se a cada dia um
padrão para manipulação de dados semi-estruturados (DAUM, 2002).
17
2.2
Extensible Markup Language
XML é uma sigla que representa eXtensible Markup Language - linguagem de
marcação extensível (XML, 2003). Diferentemente da maioria das linguagens de
marcação, inclusive a própria HTML (HyperText Markup Language – linguagem de
marcação de hipertexto), XML não apresenta um conjunto limitado de tags a serem
utilizadas. Sua característica flexível permite a seus usuários a definição de suas próprias
tags e a criação de suas próprias linguagens de marcação. Para a definição de um conjunto
de tags, XML oferece uma estrutura padrão que possibilita ao usuário a criação de sua
própria estrutura ou a utilização de outras estruturas já definidas. Uma considerável
vantagem da utilização da XML para criação de novas linguagens é o fato que todas as
linguagens baseadas na XML compartilham uma sintaxe básica comum (RDF, OWL, XML
Schema, MML). A figura 1 representa um documento XML.
1
<?xml version='1.0'?>
2
<lista>
3
<responsavel>
4
<nome>Kenia</nome>
5
<nome>Rosmarina</nome>
6
<nome>Samira</nome>
7
<nome>Pollyane</nome>
8
<nome>Alina</nome>
9
</responsavel>
10
<local>
11
<lugar>Quarteto</lugar>
12
<lugar>Caculinha</lugar>
13
</local>
14
<data dia="12" mes="8" ano="2002"/>
15
<setor>
16
<nomes>Frios</nomes>
17
<produto>
18
<nomep>Queijo</nomep>
19
<quant>2</quant>
20
<unit>kg</unit>
21
<precoant>9,00</precoant>
22
<precoatual>10,00</precoatual>
23
</produto>
18
24
<produto>
25
<nomep>Presunto</nomep>
26
<quant>2</quant>
27
<unit>kg</unit>
28
<precoant>10,00</precoant>
29
<precoatual>12,00</precoatual>
30
31
32
</produto>
</setor>
</lista>
Figura 1 – Exemplo de um documento XML
A XML possui sua origem na SGML (Standard Generalized Markup Language),
um padrão especificado pela ISO 8879 em 1986, mais poderoso para criação de linguagens
que a própria XML (ANDERSON, 2001). Um fator de relevância que levou
desenvolvedores a pesquisarem e criarem novas linguagens mais leves, simples e que
fossem utilizadas na Web foi a complexidade que envolve a utilização da SGML.
Entretanto, SGML ainda tem sido bastante utilizada por grandes empresas que buscam
desenvolver alternativas satisfatórias que possam auxiliar na realização de diferentes
funções (McGRATH, 1999).
XML foi lançada oficialmente em 1996 pelo W3C (World Wide Web Consortium),
organização responsável pela regulamentação dos padrões da internet, possuindo como
característica marcante a combinação da capacidade e flexibilidade da SGML com a
enorme aceitação da HTML (ANDERSON, 2001).
A XML vem tornando-se o principal padrão para representação de dados que não
apresentam uma estrutura bem definida. A própria especificação da linguagem XML
apresentada pelo W3C juntamente com a crescente necessidade da definição de uma
estrutura para documentos semi-estruturados permitem a realização dessa afirmação.
XML pode ser utilizada para representação e troca de documentos e informações
entre sistemas e aplicações diferentes, sendo um elo comum de entendimento entre ambos.
Além disso, permite o armazenamento estruturado dos dados em um formato de texto
próprio com extensão .xml. Uma característica expressiva dessa linguagem é a adição de
uma certa estrutura a documentos semi-estruturados.
19
2.3
Document Type Definition
Normalmente, um documento XML está ligado a uma linguagem de especificação,
definição ou marcação. DTD é uma linguagem utilizada para definição dos tipos de dados
a serem usados no documento relacionado. Comumente, atribui-se a uma DTD a
responsabilidade do uso de uma linguagem oficial para delimitar a estrutura e os possíveis
valores nos documentos XML. Basicamente uma DTD define um vocabulário comum que
documentos .xml referenciados devem obedecer (ANDERSON, 2001).
As regras a serem especificadas em uma DTD devem iniciar sempre com os
símbolos <! (menor e exclamação) seguido de um marcador básico obrigatoriamente
escrito com letra maiúscula e terminado com um sinal de maior. Todas as definições que
fogem desse padrão não fazem parte da especificação de DTD. A tabela abaixo apresenta
os quatro tipos possíveis de declarações de marcação básicas usadas na DTD:
Tabela 1 – Tabela de marcações básicas (ANDERSON, 2001)
Marcadores básicos
Significado
ELEMENT
Declaração de um tipo de elemento XML
ATTLIST
Declaração dos atributos que podem ser designados a um tipo
de
elemento
específico
e
os
valores
permissíveis
destes
atributos
ENTITY
NOTATION
Declaração de conteúdo reutilizável
Declarações de formato para o conteúdo externo que não deve
ser analisado em termos de sintaxe (dados binários, por
exemplo), e a aplicação externa que lida com o conteúdo
De acordo com (ANDERSON, 2001), o conteúdo de um elemento DTD pode ser
dividido em cinco grupos:
•
Dados de caractere: Todo elemento declarado como sendo do tipo #PCDATA deverá
ter em seu conteúdo somente caracteres que devem obedecer as regras de nomes da
especificação XML, como não iniciar com alguns caracteres especiais.
•
Conteúdo vazio: O elemento declarado como do tipo
EMPTY
não pode ter nenhum
texto ou elemento em seu conteúdo. Somente atributos são permitidos a esse tipo de
elemento.
20
•
Conteúdo misto: O elemento do tipo misto é formado por uma mistura de dados de
caractere e por elementos. Toda declaração de conteúdo misto deve ser iniciada
com o
#PCDATA
e a cardinalidade do conjunto deve ser “zero ou mais”,
obrigatoriamente.
•
Conteúdo indefinido: é possível definir um tipo de elemento que não tenha um tipo
básico definido, podendo ser formado por uma combinação de elementos ou texto.
Um elemento declarado como do tipo ANY possui essas características.
•
Conteúdo de elementos: Elementos que não possuem
textos nem atributos,
possuindo apenas elementos filhos, enquadram-se nesse grupo.
A DTD disponibiliza uma forma relativamente simples de definição de
cardinalidade na declaração de elementos.
? - elemento opcional, podendo aparecer no máximo uma vez.
+ - elemento deve aparecer pelo menos uma vez.
* - elemento pode aparecer zero ou mais vezes.
Além de elementos, uma DTD também pode ser composta por atributos,
normalmente utilizados para complementar e modificar elementos. Os atributos são
considerados uma das propriedades mais ricas de um documento XML quando este é
definido por uma DTD, oferecendo meios de associar propriedades simples a elementos
(ANDERSON, 2001). Toda definição de um atributo em uma DTD consiste na utilização
da tag ATTLIST seguida do nome do elemento que receberá o atributo, do nome do atributo,
do tipo de atributo e de uma das declarações padrões de atributos. De acordo com
(ANDERSON, 2001) os tipos de atributos são:
Tabela 2 – Tipos de atributos (ANDERSON, 2001)
Tipo de atributo
CDATA
ID
IDREF
Significado
Dados de caractere (string)
Nome único em um dado documento
Referência a alguns elementos que tenham um atributo ID com o
mesmo valor que o atributo IDREF
IDREFS
Série de IDREFs delimitados por espaço em branco
ENTITY
Nome de um entidade externa predefinida
ENTITIES
Série de nomes ENTITY delimitados por espaço em branco
21
NMTOKEN
Um nome
NMTOKENS
Uma série de NTOKENS delimitados por espaço em branco
NOTATION
Aceita um ou uma série de nomes indicando tipos de anotação
declarados no DTD
Valor enumerado
Aceita uma de uma série de valores definidos pelo usuário
A figura 2 apresentada abaixo representa uma das possiveis DTDs que podem
validar o documento XML referente à figura 1.
1
<!ELEMENT lista (responsavel, local, data,setor)>
2
<!ELEMENT responsavel (nome+)>
3
<!ELEMENT nome (#PCDATA)>
4
<!ELEMENT local (lugar+)>
5
<!ELEMENT lugar (#PCDATA)>
6
<!ELEMENT data EMPTY>
7
<!ATTLIST data dia CDATA #REQUIRED
8
mes (1|2|3|4|5|6|7|8|9|10|11|12) "1" ano CDATA #REQUIRED>
9
<!ELEMENT setor (nomes+,produto+)>
10
<!ELEMENT nomes (#PCDATA)>
11
<!ELEMENT produto (nomep,quant, unit, precoant, precoatual)>
12
<!ELEMENT quant (#PCDATA)>
13
<!ELEMENT unit (#PCDATA)>
14
<!ELEMENT nomep (#PCDATA)>
15
<!ELEMENT precoant (#PCDATA)>
16
<!ELEMENT precoatual (#PCDATA)>
Figura 2 – Exemplo de uma DTD
2.4
Data Guide
O Data Guide é uma estrutura de índices para banco de dados semi-estruturados
gerados dinamicamente a partir de um ou mais documentos XML. Pode ser considerado
um esquema dinâmico gerado a partir da fonte de dados XML, sendo bastante útil para
navegação, armazenamento, formulação e otimização de consultas em banco de dados
semi-estruturados (GOLDMAN, 2000).
Essa estrutura de índices foi desenvolvida pela Universidade Stanford, nos Estados
Unidos, para definição de esquemas para banco de dados semi-estruturados, mais
22
especificamente o Lore (Lightweight Object Repository). Ambos estão relacionados ao
projeto de pesquisa LORE (LORE 2003).
Uma característica dessa estrutura de índices é sua relação com a definição de
OEM (Object Exchange Model), modelo de dados orientado a grafo. Todo Data Guide é
baseado nessa estrutura de grafos proposta por Papakonstantinou em 1995.
O modelo de grafos OEM é baseado na idéia de que cada objeto existente na base
de dados possui um identificador único, um OID (identificador único do objeto), bastante
utilizado na especificação dos bancos de dados orientados a objetos e pós-relacional
(bancos de dados objeto-relacional). O modelo de grafos OEM possui uma representação
bastante simples e muito flexível para a representação de dados que não apresentam uma
estrutura bem definida. Seguindo uma estrutura hierárquica em forma de árvore, um
modelo OEM deve representar todas as ocorrências dos dados semi-estruturados existentes
no documento.
Apenas dois tipos de objetos são encontrados na definição de OEM (MELO, 2000):
objetos atômicos e objetos complexos. Os objetos atômicos podem ser dos tipos já
definidos e conhecidos como integer, real, string, double etc. Todo objeto atômico é
representado como nó folha em uma representação gráfica do OEM.
Os objetos
complexos normalmente são formados por um conjunto de outros objetos. Na verdade,
cada objeto complexo possui um tipo que faz referência a outros objetos do documento,
representando objetos que apontam para outros objetos.
Um objeto OEM é formado por (PAPAKONSTANTINOU, 1995):
•
Rótulo – é uma string de caracteres de tamanho variável que descreve a
representação do objeto.
•
Tipo – define o tipo do objeto. Cada tipo pode ser atômico ou complexo, em que o
último pode ser formado por um conjunto ou lista de tipos.
•
Valor – é um valor de tamanho variável para o objeto.
•
OID (identificador do objeto) – é um identificador único de tamanho variável do
objeto. Um OID pode ser nulo ou ainda omitido da representação conceitual, uma
vez que seus valores devem ser tratados internamente pelo banco de dados.
Objetos OEM podem ser representados conforme as figuras abaixo:
1
<RG, integer, 395782>
Figura 3 – Objeto atômico
23
1
2
<Funcionario, set,{Tnome,Tendereco,Ttelefone,Trg,TestadoCivil}>
Tnome is<nome, string, “Marcus Barbosa Pinto”>
5
Tendereco is<endereco,string,“QD 403 Sul QI 02 Lote 09”>
6
Ttelefone is <telefone, string, “(63)225-2090”>
7
Trg is <rg, integer, 395782 >
8
TestadoCivil<estadoCivil, string, “solteiro”>
Figura 4 - Objeto complexo
O primeiro exemplo representa um objeto atômico
RG
que representa um
determinado número de registro geral. O segundo exemplo representa um objeto complexo
Funcionario
que faz referência a outros objetos, podendo ser outros objetos complexos ou
outros objetos atômicos.
Com o surgimento da linguagem XML, as pesquisas relacionadas à utilização de
OEM para representar dados semi-estruturados foram gradativamente substituídas. O
banco de dados LORE também substituiu sua forma de representação de dados que
apresentam uma estrutura irregular, antes usando grafos OEM, por essa nova linguagem.
Baseado nessa estrutura de grafos, um Data Guide é dinâmico e pode sofrer
alterações à medida em que a estrutura dos documentos a ele relacionados estiverem sendo
atualizados. Com base em um número finito de arquivos XML dados como entrada, o Lore
gera os Data Guides. Essa estrutura possui a finalidade de melhorar o desempenho do
banco de dados, uma vez que tem a responsabilidade de descrever a existência de
determinados elementos, normalmente evitando que buscas por elementos inexistentes
sejam realizadas.
Outra característica dessa estrutura é sua não limitação do número de instâncias de
um determinado elemento que compõe o documento relacionado. O máximo que essa
estrutura informa é a existência ou não de um determinado elemento. Cabe à aplicação que
o estiver utilizando realizar a verificação de mais de uma instância do elemento.
Resumidamente, um Data Guide não informa o número de filhos que um determinado
elemento possui, ele apenas informa a existência deles.
24
Figura 5 – Exemplo de um Data Guide
Dependendo do domínio que está sendo utilizado, mais precisamente do tamanho
do Data Guide gerado, a representação gráfica dessa estrutura pode ajudar os usuários na
formulação de consultas válidas, aumentando o desempenho da aplicação que o está
utilizando.
Um Data Guide deve ser um conjunto de índices conciso, preciso e convenientes da
estrutura de uma base de dados (GOLDMAN, 2000). A consistência é assegurada quando
esta estrutura representa cada caminho existente na base de dados uma única vez,
independente da quantidade de vezes que esse dado aparece no documento. A precisão e a
exatidão são asseguradas quando o Data Guide não gera nenhum caminho que não exista
na base de dados. Somente caminhos válidos estarão representados na estrutura gerada. A
conveniência é assegurada quando um Data Guide pode ser entendido e trabalhado como
um objeto OEM, onde as técnicas de armazenamento e consulta anteriormente utilizadas
podem ser reaproveitadas.
É possível que para uma mesma base de dados sejam gerados vários Data Guides.
Assim sendo, pode ocorrer a necessidade de integração de Data Guides referentes a um
mesmo domínio de atuação; no entanto, o que normalmente ocorre é uma atualização em
um determinado Data Guide com base nas alterações que ocorreram nas fontes. Porém,
25
para a realização de alterações nos Data Guides o ideal seria que eles fossem considerados
Data Guides fortes, flexíveis e que representam todos os caminhos presentes na base de
dados, pois sua escolha pode influenciar no resultado final do processamento de
determinadas consultas ou ainda dificultar enormemente o processo de otimização das
mesmas. Um estudo detalhado sobre a importância dos Data Guides fortes pode ser
encontrada em (GOLDMAN, 2000).
2.5
XML Schema
A XML Schema foi desenvolvida pelo W3C com o objetivo principal de superar as
eventuais deficiências encontradas na DTD para definição de esquemas para documentos
XML. Lançada publicamente como “working draft” no ano de 1999 no site da W3C, a
XML Schema foi definitivamente recomendada em maio de 2001 como linguagem oficial
de definição de esquemas para documentos XML (DAUM, 2002).
Existem dois tipos básicos de elementos encontrados na linguagem XML Schema:
elementos simples e elementos complexos. Um elemento simples pode ser definido com a
utilização do elemento
element,
seguido
dos atributos
name
e
type,
nome e tipo do
elemento, respectivamente. Um elemento simples também pode ser definido com a
utilização do elemento
simpleType,
normalmente utilizado quando se deseja impor alguma
restrição ao elemento.
Ao contrário dos elementos simples, os elementos complexos podem conter outros
elementos e atributos. Existem duas formas distintas para a declaração de elementos
complexos: uma para a declaração de novos elementos e outra que permite a utilização de
elementos e atributos declarados pelo próprio autor do esquema. Para a declaração de
novos elementos complexos é necessário a utilização do elemento complexType juntamente
com a definição do nome e o conteúdo.
A XML Schema permite um certo reaproveitamento de código. É possível a
definição
de
tipos
de
elementos
reutilizando
tipos
declarados
anteriormente.
Conseqüentemente, todos os elementos que forem declarados como um tipo pré-definido
devem possuir todos os elementos e todos os atributos que constituem o elemento utilizado
como tipo na declaração. A ordem dos elementos deve ser obedecida.
26
A linguagem XML Schema disponibiliza dois atributos para a definição de
cardinalidade na declaração de elementos. O atributo minOccurs é responsável por indicar o
número mínimo de vezes que um elemento deve aparecer. Quando esse atributo é omitido
da
declaração é assumido que a quantidade mínima de vezes que o elemento pode
aparecer é 1. O atributo responsável pela indicação do número máximo de vezes que um
determinado elemento pode aparecer é o
maxOccurs.
Quando não se tem definido a
quantidade máxima de vezes em que um elemento deve aparecer o valor unbounded deve
ser atribuído ao atributo maxOccurs. Se esse atributo for omitido da declaração, entende-se
que esse elemento deve aparecer no máximo uma vez no documento.
A XML Schema define três delimitadores de grupos para definição da ordem em que
os elementos devem aparecer dentro do documento XML válidos pelo esquema. O
delimitador sequence informa que os subelementos devem aparecer no documento XML na
mesma ordem em que se apresentam no documento XML Schema. O delimitador
choice
informa que apenas um dos subelementos declarados no esquema deve aparecer no
documento. Por fim tem-se o delimitador
all
que informa que todos os elementos
declarados no esquema podem aparecer uma ou nenhuma vez no documento, podendo
aparecer em qualquer ordem.
Os atributos dentro das definições da linguagem XML Schema são de fundamental
importância para a consolidação dessa linguagem como padrão para a definição de
esquemas para documentos XML. São eles os responsáveis por grande parte do controle
exercido sobre os dados que compõem os documentos XML válidos pelo esquema.
Basicamente, os atributos são declarados com a utilização do elemento
seguido do atributo
name
e
type,
attribute
e igualmente aos elementos simples, eles não podem
conter outros elementos ou outros atributos. Outras informações podem ser adicionadas na
declaração de atributos com utilização do use (utilização), fixed (valor fixo) e default (valor
padrão). O tipo
simpleType
também é utilizado como uma forma de aumentar as restrições
existentes no atributo a ser declarado. Toda declaração de atributo deve estar relacionada à
declaração de um elemento complexo.
Apesar da evolução alcançada com a utilização da linguagem XML Schema para
definição de esquemas para documentos XML, ainda existem muitos obstáculos que
devem ser superados. Alguns desses obstáculos estão relacionados ao fato que a XML
Schema é relativamente complicada para entender, sendo normalmente um arquivo de
texto bastante extenso. Pelo fato do seu tamanho ser relativamente grande, a sua utilização
27
no desenvolvimento de aplicações cliente-servidor pode trazer problemas de validação,
uma vez que o cliente pode realizar alguma operação antes do carregamento total do
esquema de validação (DAUM, 2002). O esquema de validação no caso anterior seria o
próprio documento XML Schema.
Outra deficiência percebida na utilização da XML Schema está relacionada com as
definições de restrições nos elementos e nos atributos. Apesar dos enormes avanços se
comparados à DTD, a XML Schema somente impõe restrições básicas, como tipo de dados
e relações com exclusividade. As restrições de correlação entre atributos de um mesmo
elemento praticamente não existem. Não é possível definir, por exemplo, que um
determinado atributo seja preenchido com determinado valor se um outro atributo receber
um valor 0.
2.6
Integração de esquemas XML
A necessidade cada vez maior de utilização de dados que não apresentam uma
estrutura regular pode ser encontrada na maioria das áreas da informática. Dentre elas, uma
em especial há muito já reconheceu essa necessidade. Inicialmente uma preocupação da
comunidade de Banco de Dados era de encontrar uma estrutura rígida na qual os dados,
ainda em seu formato bruto, pudessem ser encaixados em um esquema pré-definido. O
enquadramento desses dados em uma estrutura fixa trouxe consideráveis benefícios.
Partindo de um princípio simples no qual os dados seriam armazenados de acordo com um
determinado esquema que aparentemente permaneceria invariável, onde todas as
informações contidas seguiriam obrigatoriamente essa mesma estrutura, melhorias
puderam mais facilmente ser incrementadas.
Com a organização dos dados e a aparente restrição imposta pelo esquema,
aplicações puderam gerenciar mais facilmente os possíveis dados armazenados. SGBD’s
foram agregando com o tempo novas tecnologias que aumentavam ainda mais sua
capacidade de gerenciamento dos dados armazenados. Como exemplo dessa evolução,
pode-se citar os SGBDR’s que sofreram evoluções consideráveis ao longo de sua
existência. Questões relacionadas principalmente à capacidade de armazenamento,
segurança das informações contidas no banco e desempenho apresentaram um alto grau de
evolução nos últimos anos.
28
Para aplicações que se beneficiam dos esquemas dos documentos XML, o ideal
seria que os documentos estivessem de acordo um único esquema específico. Normalmente
isso não ocorre. É comum a existência de documentos XML relacionado a um esquema
próprio ou ainda sem nenhuma relação. Para o primeiro caso, a integração de esquemas
relacionados a um domínio específico pode ser uma saída satisfatória.
O tema principal desse trabalho está relacionado à integração de esquemas para
documentos XML. A utilização de técnicas relacionadas à tecnologia XML é justificada,
uma vez que sua aceitação é crescente tanto em meios acadêmicos quanto em meios
comerciais.
A integração de esquemas proposta neste trabalho tem com base as seguintes
premissas (ANDERSON, 2001):
•
Um esquema XML é todo o documento que represente a estrutura de um ou
mais documentos semi-estruturados;
•
Esquemas podem ser considerados um conjunto de regras que descrevem o
conteúdo dos documentos relacionados;
•
Restrições podem ser especificadas dentro de um esquema;
•
Relacionamentos entre elementos podem ser encontrados em esquemas;
•
Um esquema defini um conjunto de documentos válidos de acordo com suas
regras;
•
Resumidamente, um esquema possui na maioria das vezes dois conceitos
básicos: restringir e explicar;
•
DTD, XML Schema e Data Guides são considerados esquemas para
documentos XML;
•
A DTD é a estrutura escolhida para integração de esquemas.
A realização da integração de esquemas para documentos XML representados
através de uma DTD, parte do princípio que dado um conjunto de esquemas acerca de um
mesmo domínio como entrada, produza como saída um esquema único que explique ou
restrinja todos os documentos antes definidos pelos esquemas de entrada. Para suportar as
diversidades que podem ser encontradas nos documentos relacionados, é possível que as
restrições ou explicações sejam impostas com menos rigor no esquema final gerado com
base nos arquivos de entrada.
29
Esquemas para documentos XML são normalmente utilizados por aplicações que
manipulam os dados contidos nos documentos XML. Com base nestes esquemas, essas
aplicações tentam beneficiar-se das informações disponibilizadas pelo esquema para
realizarem tarefas específicas, normalmente relacionadas à manipulação dos dados
contidos nos documentos XML relacionados. Como exemplo destas aplicações, pode-se
citar os Sistemas Gerenciadores de Banco de Dados Semi-estruturados Lore (McHUGH,
1997) (LORE, 2003) e Tamino (SOFTWARE AG, 2003).
2.7
Processo de integração de esquemas
O gerenciamento adequado dos dados que apresentam um elevado grau de
heterogeneidade é uma área de pesquisa da comunidade de banco de dados há vários anos.
As pesquisas realizadas nessa área estão relacionadas à necessidade crescente das
organizações de compartilharem as mais diversas informações. Muitas vezes, estas
informações estão dispostas em locais, plataformas e gerenciadas por aplicações diferentes.
As evoluções ocorridas na área de redes de computadores, principalmente com a
padronização estabelecida pelos órgãos competentes (ISO, 2003), também contribuíram
para o aumento das pesquisas relacionadas ao gerenciamento de dados heterogêneos.
Segundo
(WIEDERHOLD,
1993),
podem
ocorrer
diversos
tipos
de
heterogeneidade entre banco de dados, dentre os quais, a heterogeneidade de hardware (a
existência de diferentes sistemas operacionais e principalmente protocolos de acesso), a
heterogeneidade de software (diferentes sistemas gerenciadores de banco de dados e com
diferentes modelos de dados) e a utilização de esquemas diferentes para o banco
(interpretações podem ser comprometidas visto que um mesmo dado pode está
representado de formas diferentes).
Independente da arquitetura que será utilizada por qualquer sistema de
gerenciamento de dados heterogêneos, existe a necessidade da criação de um esquema
global para a fonte de dados. Normalmente é possível que a geração desse esquema global
esteja relacionado à integração dos esquemas já existentes para as diversas bases de dados.
Integração de esquemas pode ser definida como um processo de geração de um esquema
integrado e único com base em um conjunto finito de esquemas de entrada, resolvendo as
diversidades semânticas e estruturais existentes nos esquemas de entrada (BATINI, 1986).
30
O processo de integração de esquemas é bem complexo, pois normalmente a
semântica dos esquemas não está formalmente documentada. Por isso, grande parte das
ferramentas para integração de esquemas são semi-automáticas: em sua maioria, elas
sugerem conceitos que aparentemente podem ser integrados, cabendo ao usuário aceitar,
ignorar ou ainda realizar modificações na integração sugerida pela ferramenta (RAHM
,2001).
A integração de esquemas pode ser dividida nas seguintes etapas (BATINI, 1986):
•
Pré- integração: existe a necessidade de analise dos esquemas existentes para
escolher a melhor forma de integração a ser utilizada. Pode ser necessário decidir a
ordem em que a integração deverá ocorrer e se essa integração é total ou parcial;
•
Comparação de Esquemas: talvez seja necessário identificar possíveis conflitos que
podem ocorrer no processo de integração. As correspondências e as diferenças de
conceitos existentes nos esquemas de entrada, principalmente ligadas a atributos,
restrições de integridade e relacionamentos, devem ser especificadas;
•
Unificação: eliminação de conflitos entre conceitos presentes nos esquemas. Para a
realização dessa unificação, os seguintes critérios devem ser seguidos:
o Completude e corretude: obrigatoriamente o esquema gerado a partir dos
esquemas de entrada deve conter todos os conceitos presentes nos esquemas
iniciais;
o Minimalidade: não poderá ocorrer a repetição de conceitos dentro do
esquema global gerado (um conceito que foi representado em mais de um
esquema de entrada só poderá ser representado uma única vez no esquema
global);
o Compreensão: preferencialmente o esquema geral gerado com base nos
esquemas de entrada deve ser de fácil compreensão para projetistas e
usuários. A preferência por representações claras torna-se evidente.
Normalmente informações de mapeamento entre conceitos no esquema final
e esquemas de entradas são gerados nessa etapa do processo e mantidos em local
específico (dicionário de sinônimos, por exemplo).
•
Reestruturação: atividades como inclusão de relações inter-esquemas e a
simplificação do esquema integrado, como a eliminação de relacionamentos
31
repetidos, podem ser necessárias. A primeira atividade também pode ocorrer na
etapa anterior.
Um processo de integração de esquemas que se baseia na entrada de uma
quantidade finita de esquemas e gera como saída um esquema global resultante da união
dos conceitos existentes em cada esquema, é conhecido como um processo bottom-up.
Quando esse processo ocorre de forma inversa, ou seja, a partir de um esquema único são
gerados vários esquemas com menor amplitude, é conhecido como processo top-down
(SHETH, 1990). O processo utilizado nesse trabalho pode ser encaixado no processo
bottom-up.
Para a integração de fontes de dados XML, (MELLO, 2002) propõe um processo
chamado BinXS, sigla que representa Bottom-up Integration of XML Schemata. Esse
processo é uma parte integrante da camada de mediação para a realização de acessos às
várias fontes XML que podem existir. Dois propósitos são encontrados nessa camada: a
possibilidade de realização de consultas com base no esquema global e a integração
semântica dos esquemas.
A figura 6 representa a arquitetura de um sistema que utiliza mediadores. (MELLO,
2002) divide a arquitetura representada pela figura 6 em wrapping, mediação e
apresentação:
•
A camada de wrapping: é a camada mais baixa do sistema, sendo composta por um
conjunto de wrappers, onde cada um é responsável pelo acesso aos dados de um ou
mais documentos XML que estejam definidos de acordo com uma determinada
DTD. Em caso da inexistência de uma estrutura que defina um documento XML,
no caso específico uma DTD, cabe ao wapper providenciar sua geração através de
um exame dos dados existentes no documento analisado. Essa camada também
realiza consultas sob sua responsabilidade. Para tanto, recebe informações da
camada de mediação referentes às consultas a serem realizadas e retorna para a
mesma camada o resultado da requisição solicitada em formato XML. Cada
consulta realizada dever estar de acordo com a DTD de cada wapper. Por não fazer
parte do foco principal do trabalho, detalhes dessa camada não foram apresentadas
na proposta.
32
Figura 6 - Arquitetura para um sistema mediador (MELLO, 2002)
•
A camada de mediação: é a camada mediadora da arquitetura. O mediador
encontrado nessa camada é responsável pela realização do processo de integração
semântica de esquemas e consulta a fontes XML. Na proposta foi definido que o
sistema atuará sobre um único domínio de aplicação, necessitando de um único
mediador.
•
A camada de apresentação: é a camada superior da arquitetura. Nessa camada
encontra-se uma interface utilizada pelos usuários e pelas aplicações para a
realização de consultas nas fontes de dados XML. Uma visão do esquema global é
disponibilizada nessa interface para auxílio na formulação de consultas que
posteriormente serão traduzidas para uma linguagem de consulta a dados XML e
enviadas para a camada de mediação. A interface de consulta também pode ser
responsável pela conversão das informações recebidas pela camada de mediação,
33
antes que sejam apresentadas ao usuário. Essa conversão pode ser entendida como,
por exemplo, a agregação de uma tabela aos dados XML recebidos ou ainda a
inclusão de outras formas de apresentação com gráficos, textos etc.
É importante ressaltar que o processo de integração proposto no BinXS é semiautomático e bottom-up. Essa característica semi-automática exige a necessidade de um
usuário especialista que tenha a função de validar as possíveis integrações sugeridas na
proposta (MELLO, 2002).
O processo de integração proposto por (MELLO, 2002) no BInXS apresenta duas
etapas bem definidas, como representadas na figura 7:
•
A etapa de conversão de DTD: Nessa etapa, cada DTD associada aos documentos
referentes à fonte XML é convertida em um esquema conceitual. Essa conversão
possibilita uma abstração maior da DTD que leva em conta a semântica de seus
dados, minimizando as complicações que podem ocorrer na etapa posterior à
integração. Possivelmente haverá a necessidade da intervenção do usuário para
determinar a intenção de um determinado dado. Além da DTD, os documentos
XML referentes são também analisados para auxílio em alguns pontos dessa
conversão, como por exemplo, a definição de relacionamentos existentes na DTD.
Todas as informações referentes ao mapeamento realizado são armazenadas em um
local específico.
34
Figura 7 - Processo de integração de esquemas [MEL 2002]
•
A etapa de integração: essa etapa é responsável pela integração dos esquemas
gerados. Como resultado dessa integração é gerado um esquema global para os
esquemas de entrada. Os passos seguidos nessa etapa seguem basicamente a mesma
ordem sugerida pelo processo de integração bottom-up tradicional, sendo a
intervenção do usuário novamente requerida para confirmar ações que ocorram nas
fases de unificação e comparação de esquemas. A Ferramenta ARTEMIS
(CASTANO, 2001) é utilizada nesse processo.
A proposta BInXS sugerida por (MELLO, 2002) exige necessariamente a
existência de um usuário especialista do domínio que confirme, anule ou modifique os
esquemas que podem ser sugeridos em todo o processo. A principal vantagem dessa
técnica está relacionada a uma considerável diminuição dos conflitos que podem ocorrer
em um processo de integração de esquemas. Em contrapartida, um processo que às vezes é
35
manual, pode torna-se exaustivo e bastante demorado, dependendo da integração que está
sendo realizada.
Para o processo de integração de esquemas DTD’s, o trabalho utilizará a arquitetura
JAXB para acessar os dados referentes a cada documento, visto que cada documento será
convertido para um formato XML. Maiores informações sobre a conversão de DTD’s para
XML podem ser encontradas na seção 4.4 desse trabalho.
2.8
Arquitetura JAXB
A arquitetura JAXB é uma tecnologia Java que permite criar uma série de classes
Java para manipular documentos XML de acordo com um XML Schema. Essa tecnologia
permite a representação de cada documento XML, mapeando-o para uma série de objetos
java. Partes específicas do documento referenciado são representadas por objetos das
classes geradas pela arquitetura (ARMSTRONG, 2003).
Um documento XML Schema utiliza a sintaxe da linguagem XML para descrever
os possíveis relacionamentos existentes entre os elementos, atributos e entidades de cada
documento XML relacionado. A finalidade de um documento XML Schema é definir uma
classe para documentos XML que devem obedecer a uma série de regras específicas
relacionadas principalmente à sua estrutura (W3C CONSORTIUM, 2003). A figura abaixo
representa parte do documento XML Schema utilizado para a geração das classes java.
1
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
2
<xsd:element name="raiz" type="Raiz2"/>
3
<xsd:complexType name="Raiz2">
4
<xsd:choice maxOccurs="unbounded">
5
<xsd:element name="elemento" type="Elemento"/>
6
<xsd:element name="atributos" type="Atributos" minOccurs="0"/>
7
</xsd:choice>
8
</xsd:complexType>
9
<xsd:complexType name="Elemento">
10
11
12
<xsd:sequence>
<xsd:element name="pai" type="Pai"/>
</xsd:sequence>
13
</xsd:complexType>
14
<xsd:complexType name="Pai">
36
15
<xsd:sequence>
16
<xsd:choice minOccurs="0" maxOccurs="unbounded">
17
<xsd:element name="filho" type="Filho"/>
18
<xsd:element name="delimitador" type="xsd:string"/>
19
</xsd:choice>
20
<xsd:element name="tipo" type="xsd:string" minOccurs="0"/>
21
<xsd:element name="misto" type="Misto" minOccurs="0"/>
22
<xsd:element name="mod" type="xsd:string" minOccurs="0"/>
23
<xsd:element name="nome" type="xsd:string"/>
24
</xsd:sequence>
25
26
27
</xsd:complexType>
...
</xsd:schema>
Figura 8 – Parte de um documento XML Schema
A arquitetura JAXB utiliza das informações disponibilizadas pelo esquema para a
geração das classes com o objetivo de manipular os documentos XML que estão de acordo
com o esquema.
37
3. MATERIAIS E MÉTODOS
3.1
Local e Período
As pesquisas foram realizadas no Núcleo de Desenvolvimento de Software (NDS)
do Centro Universitário Luterano de Palmas, localizado no prédio do curso de Sistemas de
Informação, sendo desenvolvido no segundo semestre de 2003.
3.2
Materiais
Os recursos utilizados foram em sua maioria hardware e software disponibilizados
no próprio laboratório. Algumas ferramentas gratuitas, disponíveis na Web, também foram
utilizadas. O sistema operacional utilizado foi o Windows 2000 Professional instalado
juntamente com os softwares XML Writer, XMLSPY e o SmartDraw 6, ambos aplicativos
de versão experimental. As ferramentas utilizadas como suporte foram o Adobe Acrobat 5,
Adobe Distiller 5 e o Winzip 8. A linguagem escolhida para o desenvolvimento da
ferramenta foi Java juntamente com a arquitetura JAXB. O microcomputador utilizado
possui a seguinte configuração básica: Pentium III, 750 Mhz, 20 Gb com 128 MB de
memória RAM.
3.3
Metodologia
Um levantamento teórico sobre as principais definições de esquemas para
documentos XML tornou-se necessário para que o objetivo final do trabalho fosse
alcançado. A escolha da estrutura para a realização da integração foi concluída logo em
38
seguida. Posteriormente foram realizadas, quase que simultaneamente, as alterações em um
parser DTD para converter os esquemas em um formato XML e a geração de um
documento XML Schema com base nas alternativas possíveis dos arquivos convertidos.
Utilizando-se do esquema gerado para os arquivos convertidos, a arquitetura JAXB gerou
uma série de classes e métodos para manipulação de qualquer documento XML válido de
acordo com o esquema. Essas classes permitiram a integração dos esquemas (convertidos
em arquivos XML) mais facilmente e uma posterior conversão ao formato original após o
processo de integração. Os testes foram realizados juntamente com o desenvolvimento da
ferramenta, observando uma série de situações específicas que podem ocorrer em um
processo de integração.
39
4. RESULTADOS E DISCUSSÕES
4.1
Proposta
O gerenciamento de dados heterogêneos é uma área de pesquisa crescente na
comunidade de banco de dados desde a década de oitenta. Os avanços ocorridos com a
computação distribuída e redes de computadores, juntamente com o crescimento da
necessidade de compartilhar informações entre diferentes plataformas e aplicações de
gerenciamento de dados, impulsionaram ainda mais pesquisas relacionadas a essa área
(MELLO, 2002).
Atualmente, a utilização da linguagem XML como alternativa para a troca de
informações
entre
plataformas
e
aplicações
diferentes
pode
ser
uma
saída
consideravelmente satisfatória. Por ser uma linguagem aparentemente simples e
independente da plataforma que se está utilizando, sua aceitação e utilização são
crescentes, tanto em áreas acadêmicas quanto em comerciais. O crescente número de
publicações relacionadas a essa nova tecnologia e o aumento do número de ferramentas
que dão suporte à mesma são provas do seu crescimento e aceitação.
A estruturação dos dados que aparentemente não apresentam muita semelhança
também pode ser alcançada com a utilização da linguagem XML. Uma característica
marcante dessa linguagem é dar uma certa estrutura aos dados considerados irregulares,
que não seguem uma estrutura bem definida. Apesar do foco principal deste trabalho estar
restrito à utilização da linguagem XML, as questões relacionadas no início desta seção
podem justificar sua escolha.
Uma característica própria dos dados semi-estruturados representados pela
linguagem XML está relacionada à diversidade com que os dados estão organizados. É
40
extremamente comum a existência de documentos referentes a um mesmo domínio,
estruturados de formas bem diferentes. Como a definição dos elementos e atributos que
compõem os documentos é de responsabilidade de seus usuários, e normalmente depende
do tipo de problema que se deseja resolver, a estruturação de um documento XML torna-se
bastante subjetiva.
Normalmente, as aplicações que trabalham com documentos XML baseiam-se em
uma estrutura de definição de documentos. Essas estruturas normalmente possuem a
responsabilidade de explicar ou restringir um ou mais documentos relacionados. Vistas
desta forma, essas estruturas são consideradas esquemas para documentos XML. Como as
variações entre as estruturas dos documentos XML podem ser muito grande, normalmente
as aplicações que manipulam esses documentos usam o esquema como base para acessar
os dados contidos nesse documento.
A estrutura de definição de documentos aparentemente mais utilizada é a DTD.
Considerada uma estrutura bastante simples e de fácil entendimento, sua aprendizagem
está inteiramente relacionada a aprendizagem da linguagem XML. Mesmo após o
surgimento da linguagem XML Schema (W3C CONSORTIUM, 2003), padrão
especificado pela W3C como esquema para documentos XML, a DTD ainda é bastante
utilizada, principalmente pela aparente complexidade que envolve a utilização desse novo
padrão.
Documentos XML podem existir isoladamente, sem a necessidade de um esquema
relacionado. Normalmente, as aplicações que necessitam de um esquema para se
beneficiarem das informações contidas no documento geram automaticamente essa
estrutura a partir dos dados contidos no documento. O esquema gerado, no exemplo a
DTD, é totalmente baseado na estrutura do documento relacionado e não permite, na
maioria das vezes, uma variação na estrutura do documento. Resumidamente, a DTD
gerada só possui valor para aquele determinado documento. Outros documentos XML
referentes ao mesmo domínio podem não ser validados pela DTD gerada anteriormente,
sendo normalmente necessário a geração de uma DTD para cada documento XML.
A geração de DTD para cada documento ocorre porque grande parte das DTDs
geradas automaticamente são restritas aos documentos que estão relacionadas. Como
normalmente a aplicação utiliza o esquema para acessar os documentos, o ideal seria que
todos os documentos seguissem um único esquema ou que os esquemas existentes fossem
integrados. A segunda alternativa foi a escolhida nesse trabalho
41
A arquitetura proposta nesse trabalho apresenta as seguintes etapas conforme a
figura 8:
Figura 8 – Arquitetura de integração de esquemas
•
A primeira etapa é a geração de uma DTD para o documento XML desejado. Esta
etapa é opcional e depende da inexistência de uma DTD relacionada ao documento.
A ferramenta DTDGenerator (DTDGenerator, 2003) gera automaticamente uma
DTD para o documento XML de entrada. É necessário que o documento de entrada
seja válido de acordo com a especificação dada pela W3C.
•
A segunda etapa é a conversão da DTD para um documento XML. Essa conversão
obedece a uma ordem específica necessária para que a aplicação realize a
integração. É importante ressaltar que a conversão realizada nessa etapa tem o
objetivo único de converter a estrutura da DTD para um documento XML. A
42
existência
de
mecanismos
que
manipulam
satisfatoriamente
documentos
estruturados com a linguagem XML torna essa conversão apropriada. Manipular
arquivos XML é mais fácil que manipular arquivos de texto comum.
•
A terceira etapa é a integração dos esquemas. Baseando-se na estrutura esperada, a
ferramenta de integração faz uma leitura dos arquivos convertidos e gera na saída
uma DTD integrada das estruturas dadas como entrada. A DTD gerada deve
obrigatoriamente validar todos os arquivos XML relacionados às DTD’s. Nessa
etapa é utilizada a Arquitetura JAXB para realizar a integração.
A ferramenta de integração de esquemas proposta nesse trabalho é a PINAJÉ. Para
sua utilização, é importante ressaltar três pontos relevantes:
•
Todos os documentos devem obrigatoriamente possuir o mesmo elemento raíz;
•
Tipos enumerados para atributos não podem iniciar com números. A figura abaixo
exemplifica essa restrição.
1
<!ATTLIST email mes (1|2|3|4|5|6|7|8|9|10|11|12)>
Figura 9 – Exemplo de declaração de atributo não permitida
•
Elementos declarados com o operador de cardinalidade “*” após os parênteses não
são validados pelo parser utilizado no processo. As exceções são os elementos
mistos.
1
<!ELEMENT lista ( item )* >
Figura 10 – Exemplo de declaração de elemento não permitida
A maior parte das restrições identificadas acima não foram impostas pela
ferramenta PINAJÉ propriamente, e sim pela ferramenta DTDParser que é utilizada no
processo de integração de esquemas proposto nesse trabalho, mais especificamente na
etapa de conversão da DTD para um documento XML.
4.2
Estudo de caso
O processo de integração apresentado nesse trabalho parte do pressuposto que os
arquivos XML utilizados como entrada são referentes a um mesmo domínio, e
43
possivelmente utilizados para solucionar um problema único. Como exemplo, serão
utilizados documentos XML referentes a monografias de acadêmicos de instituições que
possuem estruturas diferentes e seguem seus próprios formatos.
A escolha do domínio de monografias pode ser justificada de várias formas. Por ser
uma fonte de pesquisa bastante interessante e comumente utilizada dentro e fora das
instituições, o armazenamento destes dados para uma posterior consulta torna-se
interessante. Porém, a estrutura desses documentos pode variar bastante, mesmo quando as
monografias seguem as mesmas normas. É importante ressaltar que os documentos
mencionados nesse trabalho estão representados em XML, logo podem existir variações
significantes em suas estruturas.
A existência de partes opcionais pode ser considerada uma característica das
monografias. Agradecimentos, dedicatória, anexos, catalogação, lista de abreviaturas, etc,
podem ser partes opcionais de um trabalho de graduação. Outra característica é a
indefinição da seqüência dos elementos dentro de uma seção. Uma seção pode ser formada
por: parágrafo + figura + parágrafo ou parágrafo + tabela + tabela + parágrafo ou por
outra seqüência lógica obedecendo às restrições impostas normalmente pela instituição e
influenciadas pela escolha do autor.
Para exemplificar a realização da integração de esquemas proposta neste trabalho, a
figura 11 representa a estrutura de um documento XML referente ao domínio monografia.
Como já foi citada anteriormente, essa etapa do processo de integração é opcional e
depende da existência das DTD’s referente a cada documento XML. O processo de
integração apresentado como exemplo nesse trabalho parte da suposição que os
documentos XML podem não possuir nenhum esquema relacionado, mais especificamente
nenhuma DTD.
1
<?xml version="1.0" encoding="ISO-8859-1"?>
2
<monografia>
3
<capa>
4
<logomarca>CEULP / ULBRA</logomarca>
5
...
10
</capa>
11
<contracapa>
12
<logomarca>CEULP / ULBRA</logomarca>
13
<instituicao>Centro Universitario Luterano de Palmas</instituicao>
14
<titulo>DTD</titulo>
44
15
<autor>Marcus Pinto</autor>
16
<orientador>Deise de Brum</orientador>
17
<local>Palmas</local>
18
<ano>2003</ano>
19
</contracapa>
20
<agradecimento>Agradeco...</agradecimento>
31
<listadetabelas> ...
34
</listadetabelas>
35
<resumo>...
39
</resumo>
40
<abstract>...
44
</abstract>
45
<corpo>
46
<capitulo numero="1" pagina="8" titulo="Introducao">
47
<paragrafo>texto</paragrafo>
48
<secao numero="1" pagina="8" titulo="subIntroducao">
49
<paragrafo>texto</paragrafo>
50
<figuraCorpo number="1" pag="15">nome</figuraCorpo>
51
<paragrafo>texto</paragrafo>
52
</secao>
53
</capitulo>
62
<capitulo numero="3" pagina="20" titulo="Materiais e Metodos">
63
<paragrafo>texto</paragrafo>
64
<lista>
65
<item>item#1</item>
66
<item>item#2</item>
67
<item>item#3</item>
68
</lista>
69
<paragrafo>texto</paragrafo>
70
71
72
73
74
</capitulo>
</corpo>
<referencias>texto</referencias>
<anexos>texto</anexos>
</monografia>
Figura 11 – Parte de um documento XML representando uma monografia
Apesar da estrutura do documento XML representado pela figura 11 estar
relacionada às normas especificadas pela instituição onde a monografia foi escrita, a
estruturação dos elementos é bastante subjetiva. Os documentos XML utilizados como
45
entrada para o processo de integração, as DTD’s geradas e as representações em XML das
DTD’s podem ser encontrados na seção de anexos deste trabalho.
4.3
Geração de DTD a partir de um documento XML
Para a geração dos esquemas para os documentos XML utilizados como entrada para
o processo de integração, é utilizada uma ferramenta que gera automaticamente a DTD
para cada documento relacionado. A única restrição encontrada na utilização dessa
ferramenta para a geração automática da DTD é a obrigatoriedade do documento XML ser
bem-formado. De acordo com (ANDERSON, 2001), para que um documento XML seja
considerado bem-formado, este deve obedecer às seguintes regras:
•
Obedecer às especificações XML;
•
Os elementos devem formar uma árvore hierárquica, contendo um único nó raiz;
•
Não poderá existir referência a entidades externas; salvo se fornecida a DTD
relacionada.
A ferramenta escolhida para a geração automática da DTD é a DTDGenerator, um
programa que realiza um exame no documento XML de entrada e produz como saída uma
DTD para o documento. O esquema gerado normalmente não permite muitas variações na
estrutura do documento referenciado, portanto, mesmo se tratando de documentos XML
relacionados a um mesmo domínio e utilizando os mesmos elementos e atributos, essa
ferramenta pode gerar esquemas diferentes para cada um dos documentos.
A ferramenta DTDGenerator gera um esquema a partir do documento XML, com
base em uma série de constantes numéricas que o auxiliam na determinação de alguns tipos
para elementos e atributos. Como exemplo da utilização dessas variáveis, pode-se citar a
identificação de valores enumerados para atributos. Essas constantes são a base para a
definição do tipo de grande parte dos elementos e atributos que compõem o documento.
A DTDGenerator (DTDGenerator, 2003) faz uma listagem de todos os elementos e
atributos que aparecem no documento XML, observando como estão organizados
hierarquicamente e anotando que elementos contém dados de caracteres. A DTD é gerada
de acordo com as seguintes regras:
•
Se um elemento contém dados de caracteres e elementos filhos, a ferramenta então
o identifica como um elemento misto que contém todos os elementos identificados
46
como filhos. Um elemento também será considerado misto se em algum momento
existirem duas instâncias diferentes para esse mesmo elemento: em um primeiro
momento um determinado elemento é do tipo string, posteriormente, esse mesmo
elemento aparece formado com outros elementos filhos.
•
Se nenhum caractere for encontrado em um elemento, a ferramenta parte da
suposição que o elemento não pode conter dados de caractere.
•
Se um elemento contém somente elementos filhos, então declara-se o elemento
superior como sendo o pai e os demais elementos como filhos. Se os elementos
filhos ocorrem em cada instância do elemento pai e em uma seqüência única, esta
seqüência deverá ser obedecida na declaração do elemento. Se os elementos filhos
forem repetidos ou omitidos em alguns exemplos do elemento pai, estes serão
declarados como multivalorado ou opcionais, podendo ser ambos (+,?,*). Caso não
seja detectada nenhuma seqüência consistente entre os elemento filhos, será
assumido que pelo menos um desses elementos pode ocorrer uma ou mais vezes e
em qualquer ordem.
•
Se não forem encontrados nenhum elemento filho e nenhum dado de caractere para
determinado elemento, a ferramenta supõe que o elemento seja vazio.
•
Um atributo que aparece em todas as ocorrências de um determinado elemento será
considerado um atributo obrigatório.
•
Todo atributo que contenha no mínimo 10 ocorrências diferentes e no máximo de
100.000, será considerado um atributo de identificação único (ID).
•
Um atributo será considerado do tipo enumerado se tiver menos de 20 valores
distintos, contanto que o número de instâncias do atributo seja pelo menos três
vezes maior que o número de valores distintos.
Como já foi citado anteriormente, a geração de esquemas (DTD’s) realizada pela
ferramenta DTDGenerator é baseada em uma série de regras determinadas pelo
desenvolvedor e com características bastante subjetivas. As regras citadas anteriormente
são baseadas nas constantes numéricas existentes no código fonte da ferramenta. Desta
forma, as regras podem ser alteradas de acordo com a necessidade do usuário, pois a
ferramenta disponibiliza seu código fonte.
A partir do documento XML referente à figura 11 foi gerada uma DTD que será
utilizada no processo de integração. A figura abaixo representa a DTD gerada.
47
1
<!ELEMENT abstract ( textoAbstract, keyword+ ) >
2
<!ELEMENT agradecimento ( #PCDATA ) >
3
<!ELEMENT anexos ( #PCDATA ) >
4
<!ELEMENT ano ( #PCDATA ) >
5
<!ELEMENT autor ( #PCDATA ) >
6
<!ELEMENT capa ( logomarca, instituição, titulo, autor, local, ano ) >
7
<!ELEMENT capitulo ( lista | paragrafo | secao )+ >
8
<!ATTLIST capitulo numero NMTOKEN #REQUIRED >
9
<!ATTLIST capitulo pagina NMTOKEN #REQUIRED >
10
<!ATTLIST capitulo titulo CDATA #REQUIRED >
11
<!ELEMENT contracapa ( logomarca, instituicao, titulo, autor, orientador, local, ano ) >
12
<!ELEMENT corpo ( capitulo+ ) >
13
<!ELEMENT figura ( #PCDATA ) >
14
<!ATTLIST figura numero NMTOKEN #REQUIRED >
15
<!ATTLIST figura pagina NMTOKEN #REQUIRED >
16
<!ELEMENT figuraCorpo ( #PCDATA ) >
17
<!ATTLIST figuraCorpo number NMTOKEN #REQUIRED >
18
<!ATTLIST figuraCorpo pag NMTOKEN #REQUIRED >
19
<!ELEMENT instituicao ( #PCDATA ) >
20
<!ELEMENT item ( #PCDATA ) >
21
<!ELEMENT keyword ( #PCDATA ) >
22
<!ELEMENT lista ( item+ ) >
23
<!ELEMENT listadefiguras ( figura+ ) >
24
<!ELEMENT listadetabelas ( tabela+ ) >
25
<!ELEMENT local ( #PCDATA ) >
26
<!ELEMENT logomarca ( #PCDATA ) >
27
<!ELEMENT monografia ( capa, contracapa, agradecimento, sumario+, listadefiguras,
listadetabelas, resumo, abstract, corpo, referencias, anexos ) >
28
<!ELEMENT orientador ( #PCDATA ) >
29
<!ELEMENT palavraChave ( #PCDATA ) >
30
<!ELEMENT paragrafo ( #PCDATA ) >
31
<!ELEMENT referencias ( #PCDATA ) >
32
<!ELEMENT resumo ( textoResumo, palavraChave+ ) >
33
<!ELEMENT secao ( figuraCorpo | paragrafo | subsecao )+ >
34
<!ATTLIST secao numero NMTOKEN #REQUIRED >
35
<!ATTLIST secao pagina NMTOKEN #REQUIRED >
36
<!ATTLIST secao titulo NMTOKEN #REQUIRED >
37
<!ELEMENT subsecao EMPTY >
38
<!ELEMENT sumario ( titulo ) >
39
<!ATTLIST sumario numero NMTOKEN #REQUIRED >
48
40
<!ATTLIST sumario pag NMTOKEN #REQUIRED >
41
<!ELEMENT tabela ( #PCDATA ) >
42
<!ATTLIST tabela numero NMTOKEN #REQUIRED >
43
<!ATTLIST tabela pagina NMTOKEN #REQUIRED >
44
<!ELEMENT textoAbstract ( #PCDATA ) >
45
<!ELEMENT textoResumo ( #PCDATA ) >
46
<!ELEMENT titulo ( #PCDATA ) >
Figura 12 - DTD gerada a partir de um documento XML
A DTD gerada pela ferramenta DTDGenerator é apenas um dos possíveis
esquemas que podem ser gerados com base no documento de entrada. A DTD gerada pode
ser examinada e editada para descrever mais precisamente o documento relacionado. Para
a utilização nesse trabalho, não foi detectada a necessidade de qualquer tipo de
modificação na DTD resultante, porém é possível que em alguns casos possa ser necessário
realizar algumas alterações. A etapa de conversão da DTD para uma representação XML
determinará a necessidade ou não da realização de pequenas alterações no esquema gerado.
A DTD acima e as demais DTD’s geradas com base nos documentos XML podem ser
encontradas na seção de anexos desse trabalho.
4.4
Representação da DTD em formato XML
A aceitação e o crescimento da linguagem XML incentivou um número
considerável de pesquisas relacionadas a essa nova tecnologia. Como resultado, existe um
grande número de ferramentas que dão suporte e possibilitam o processamento de
documentos representados através dessa linguagem. Em contrapartida, os avanços com o
processamento de DTD’s não ocorreram na mesma proporção. Por conveniência, optou-se
por representar cada DTD através de um documento XML. Para efetuar essa conversão, foi
utilizado a ferramenta DTDParser (DTDParser, 2003), originalmente um parser para
verificação de DTD. As alterações realizadas no código fonte dessa ferramenta tornaram-se
necessárias para que o resultado desejado fosse alcançado. A eliminação das mensagens de
erros e a geração de um documento XML podem ser citados como exemplos das alterações
realizadas na ferramenta.
Um analisador léxico possui a responsabilidade de ler uma série de caracteres de
entrada, produzindo uma seqüência de tokens de nome que um determinado parser
49
utilizará para sua análise sintática. O analisador sintático é responsável pela verificação
dessa seqüência de tokens lidas pelo analisador léxico, observando se essa cadeia de tokens
pode ser gerada pela gramática da linguagem (AHO, 1995).
As metas a serem alcançadas em um analisador sintático são (AHO, 1995):
•
Relatar a presença de erros claramente;
•
Identificar todos os erros que se encontram no código fonte;
•
Não diminuir o desempenho no processamento de programas que não contenham
erros;
Com as alterações realizadas no código fonte da DTDParser, essa ferramenta além
de verificar se uma determinada DTD é válida, produz como saída um documento XML
que representa fielmente o arquivo de entrada de acordo com o que é pretendido pela
proposta para a realização da integração.
A figura 13 abaixo representa parte da DTD da figura 12 utilizando a linguagem
XML. O código de todas as DTD’s representadas pela linguagem XML podem ser
encontradas na seção de anexos do referente trabalho.
1
2
3
4
5
<raiz>
29
<Elemento>
<pai>
<filho>
<nome>textoAbstract</nome>
30
<tipo>NMTOKEN</tipo>
32
<padrao>REQUIRED</padrao>
33
<nome>numero</nome>
</filho>
34
7
< delimitador >|</delimitador>
35
<filho>
<Atributo>
31
6
8
<Atributos>
</Atributo>
<ElementoRef>capitulo</ElementoRef>
36
</Atributos>
9
<mod>+</mod>
37
<Atributos>
10
<nome>keyword</nome>
38
<Atributo>
11
</filho>
39
<tipo>NMTOKEN</tipo>
12
<nome>abstract</nome>
40
<padrao>REQUIRED</padrao>
41
<nome>pagina</nome>
13
</pai>
14
</Elemento>
42
15
<Elemento>
43
16
<pai>
</Atributo>
<ElementoRef>capitulo</ElementoRef>
44
</Atributos>
...
17
<pcdata>PCDATA</pcdata>
45
18
<nome>agradecimento</nome>
46
<Elemento>
47
<pai>
19
</pai>
20
</Elemento>
48
21
<Elemento>
49
<filho>
<nome>lista</nome>
50
22
<pai>
50
23
<pcdata>PCDATA</pcdata>
51
24
<nome>anexos</nome>
52
25
</pai>
</filho>
< delimitador >|</delimitador>
<filho>
53
<nome>paragrafo</nome>
26
</Elemento>
54
27
<Elemento>
55
...
56
<raiz>
28
...
</filho>
Figura 13 - DTD representada por um documento XML
4.5
A ferramenta PINAJÉ
A ferramenta PINAJÉ foi desenvolvida com o objetivo de integrar esquemas para
documentos XML; essa integração obedece a uma série de regras definidas pelo
desenvolvedor para alcançar o objetivo desejado. As regras definidas para o processo de
integração visam o enquadramento de todos os documentos, que antes estavam de acordo
com seus respectivos esquemas, a um único esquema obedecendo as restrições
apresentadas no seção 4.1.
4.5.1 O processo de Integração da ferramenta
O processo de integração utilizado pela ferramenta PINAJÉ é relativamente
simples, uma vez que não se preocupa com a semântica dos dados. Apenas a parte
sintática, a localização e a hierarquia dos dados são observados nesse processo de
integração. Deste modo, é possível que existam duplicações de informações no esquema
integrado. A afirmação acima pode ser entendida quando uma mesma informação está
apresentada de formas diferentes em cada fonte. Conseqüentemente, a ferramenta
DTDGenerator gerará esquemas diferentes para cada uma das fontes. Como a DTD
integrada deve conter todas as informações das DTD’s de entrada, esta conterá as duas
informações.
A integração realizada pela ferramenta segue os seguintes passos:
•
Para o primeiro documento passado como argumento é identificada sua extensão
(tipo). Caso seja um documento XML, é gerado uma DTD e feita a conversão para
51
um formato .xml. Se for uma DTD, o primeiro passo acima é omitido. Esse arquivo
é considerado pela aplicação como o esquema principal;
•
Para os demais documentos, são seguidos os mesmos passos da seção anterior. A
aplicação considera os demais arquivos como esquemas secundários. O processo de
integração é realizado somente entre dois arquivos por vez. O resultado de cada
integração é armazenado no esquema principal, ficando à espera de outro esquema
secundário. O processo se repete até que acabem os arquivos de entrada.
•
Para cada elemento do esquema secundário, é feita a verificação da sua existência
no esquema principal. Caso não exista nenhum elemento no esquema principal que
possua o mesmo nome do elemento do esquema secundário, ele então é inserido no
esquema principal. Se ele já existe:
o É verificado se possuem tipos diferentes. Possuindo nomes iguais e tipos
diferentes a integração é realizada da seguinte forma:
Se o elemento referente ao esquema principal tiver somente filhos:
•
se o elemento referente esquema secundário for do tipo
PCDATA,
então o elemento no esquema principal torna-se um
elemento misto com seus elementos filhos;
•
se o elemento referente ao esquema secundário for do tipo
ANY,
então o elemento referente ao esquema principal torna-
se um ANY;
•
se o elemento referente ao esquema secundário for do tipo
EMPTY,
então o modificador do elemento referente ao
esquema principal é alterado para “*”.
•
se o elemento no esquema secundário for misto, então
transforma o elemento do esquema principal em um
elemento misto e faz a integração dos dois elementos mistos.
Se o elemento referente ao esquema principal for do tipo EMPTY:
•
se o elemento referente ao esquema secundário tiver somente
filhos, então o elemento referente ao esquema principal
recebe o elemento do esquema secundário, alterando seu
modificador para “*”.
52
•
se o elemento referente ao esquema secundário for do tipo
ANY, PCDATA
ou
misto,
realiza o mesmo procedimento
anterior, apenas não alterando o modificador.
Se o elemento referente ao esquema principal for do tipo PCDATA:
•
se o elemento referente ao esquema secundário tiver apenas
filhos, então o elemento no esquema principal torna-se um
elemento misto com os filhos do elemento do esquema
secundário;
•
se o elemento no esquema secundário for do tipo
ANY,
então
o elemento do esquema principal muda seu tipo para ANY.
o Possuindo tipos e nomes iguais o processo é realizado da seguinte forma:
Se forem elementos que possuam apenas elementos filhos, então é
realizada a integração dos elementos filhos no esquema principal. O
elemento pai resultante da integração deverá conter seus filhos
originais e os filhos do elemento secundário. Quando existirem
elementos filhos com nomes iguais em ambos os esquemas, estes
não são inseridos no esquema principal, pois já existem;
Se forem elementos mistos, então é realizada a integração desses
elementos filhos. Para a existência de elementos filhos com nomes
iguais, o mesmo procedimento da seção anterior é realizado.
•
O procedimento para a integração de atributos é bastante semelhante ao processo de
integração de elementos. Para cada atributo do esquema secundário é verificado sua
existência no esquema principal com o mesmo nome do elemento relacionado, pois
é possível que existam atributos iguais em elementos diferentes. Caso o atributo
referente ao elemento não exista no elemento de mesmo nome no esquema
principal, ele é inserido no esquema principal no mesmo elemento. Se ele já existe:
o É verificado se possuem tipos iguais e se estão relacionados a elementos
com mesmo nome. Caso sejam iguais:
é verificada a declaração padrão (REQUIRED,
IMPLIED
etc). Se forem
iguais, é realizada a integração para os tipos enumerados e para o
tipo notação. Se não for de nenhum tipo acima, nada é feito. Em
seguida, é verificado se o tipo é
CDATA
com valores default
diferentes ou do tipo FIXED com valores default diferentes. Caso uma
53
das afirmações acima seja verdadeira, o atributo é modificado para
IMPLIED
sem valor default.
Se a declaração padrão for diferente:
•
Se o padrão de declaração referente ao atributo principal for
REQUIRED
e o padrão de declaração do atributo do esquema
secundário for
IMPLIED,
então o atributo referente ao
esquema principal é modificado para IMPLIED;
•
Se o padrão de declaração referente ao atributo principal for
FIXED,
então o atributo referente ao esquema principal é
modificado para IMPLIED e sem valor default .
o Se o atributo possui nomes iguais, tipos diferentes e estão relacionados com
elementos de nomes iguais em ambos os esquemas:
o tipo do atributo referente ao esquema principal é alterado para
CDATA
com padrão de declaração IMPLIED.
4.5.2 Utilização
O propósito da ferramenta PINAJÉ resume-se na integração de esquemas para
documentos XML expressos através de DTD’s. A ferramenta disponibiliza ao usuário três
formas distintas para iniciar o processo de integração:
•
apenas com documentos XML;
•
apenas com documentos DTD;
•
com documentos XML e DTD;
Não existe um limite definido para a quantidade de arquivos passados como
argumentos para iniciar o programa. Uma possível limitação será imposta pela linguagem
Java ou pelo sistema operacional e não pela aplicação propriamente (limitação do número
de argumentos por exemplo).
Para utilização da ferramenta, os seguintes requisitos devem ser observados:
•
J2SDK e o Java Web Services contem alguns arquivos utilizados pela ferramenta.
Sua instalação é recomendada;
•
É necessário criar uma pasta para os arquivos e incluí-la no CLASSPATH ;
54
•
O arquivo var.bat deve ser analisado, onde o diretório do J2SDK deve ser corrigido
caso exista necessidade. Essa verificação torna-se necessária devido à quantidade
de versões do J2SDK onde cada uma possui um diretório padrão distinto. ex: c:\
j2sdk1.4.0, c:\ j2sdk1.4.1, etc.
•
No mínimo dois arquivos devem ser passados como argumento para o programa;
•
O elemento raiz de cada documento deve ser o mesmo;
•
Ambos os arquivos devem ser válidos de acordo com a especificação da W3C;
•
Nenhum elemento pode possuir apenas um caractere. ex:<!ELEMENT a (#PCDATA)>
•
Atributos enumerados não podem iniciar com números;
•
Elementos declarados com o operador de cardinalidade “*” após os parênteses não
são validados pelo parser utilizado no processo. A única exceção são os elementos
mistos.
Os arquivos de entrada utilizados no processo de integração não são modificados
pela ferramenta PINAJÉ. Apenas são gerados novos arquivos pelas ferramentas
DTDGenerator e DTDParser. A tabela abaixo exemplifica como são escolhidos os nomes
dos arquivos gerados.
Tabela 3– Nomenclatura dos arquivos gerados pelas ferrementas
Ferramenta
arquivo de entrada
arquivo de saída
DTDGenerator
arquivo.xml
arquivon.dtd
DTDParser
arquivo.dtd
arquivo.xml
onde n é igual a 1,2,3,4...
Quando o arquivo de entrada é um documento XML, as ferramentas
DTDGenerator e DTDParser são utilizadas nesta mesma sequência, não existindo a
necessidade da alteração do nome do arquivo pela ferramenta DTDParser, apenas na
extensão do mesmo. ex: arquivo.xml => arquivo1.dtd => arquivo1.xml.
A ferramenta PINAJÉ, bem com as ferramentas que foram acopladas
(DTDGenerator e DTDParser), necessitam que algumas informações sejam inseridas nas
variáveis de ambiente para funcionarem. Essa inclusão pode ser feita através da execução
55
do arquivo var.bat existente no pacote da ferramenta. ex: c:\diretorio_pinaje\var.bat
seguido de <enter>.
Para iniciar o processo de integração proposto nesse trabalho, deve-se direcionar até
o local onde os arquivos foram salvos, executar o arquivo var.bat e a ferramenta PINAJÉ
com no mínimo dois argumentos. A figura representada abaixo exemplifica o processo de
utilização da ferramenta em questão:
1
java PINAJE arquivo_entrada1 arquivo_entrada2 > arquivo_saida.dtd
Figura 14 – Exemplo da utilização da ferramenta PINAJÉ com dois arquivos
A DTD integrada gerada pela ferramenta PINAJÉ é apenas um dos possíveis
esquemas que podem ser integrados com base nos documentos de entrada. A DTD gerada
pode ser examinada e editada para descrever mais precisamente os documentos
relacionados. As regras de integração utilizadas pela ferramenta podem comprometer
algumas restrições impostas pelas DTD’s. A DTD menos restrita se impõe sobre as demais
e influencia na formação do documento gerado.
4.5.3 Arquivos de entrada
A ferramenta PINAJÉ foi implementada na linguagem Java, utilizando a arquitetura
JAXB para acessar os documentos, realizar a integração e gerar um arquivo com extensão
.dtd com saída. Como já foi citado anteriormente, a tecnologia JAXB provê uma série de
classes com métodos bem flexíveis para manipular documentos XML. As classes e os
métodos gerados pela arquitetura citada são baseados no documento XML Schema
utilizado pela tecnologia JAXB.
O primeiro passo da ferramenta PINAJÉ é a verificação da extensão dos arquivos
de entrada. A classe PINAJÉ disponibiliza dois métodos com a responsabilidade de
verificar o tipo dos arquivos. Cabe ao método
ehXML(String nome)
informar se o arquivo
passado como parâmetro é um documento XML. O método ehDTD(String nome) informa se
o arquivo passado como parâmetro possui nome com extensão .dtd. Ambos os métodos
retornam true ou false, dependendo da extensão dos arquivos.
Se o documento usado como entrada para o processo de integração for um arquivo
com extensão .xml, é criado um processo paralelo onde a ferramenta DTDGenerator
56
modificada é executada. Como nova saída, tem-se um documento DTD gerado a partir do
documento XML dado como entrada para o processo. Quando esse processo é finalizado, é
criado um novo processo paralelo onde a ferramenta DTDParser, também alterada, é
executada, gerando um novo documento XML que será usado no processo de integração.
Quando o documento dado como entrada for um arquivo com extensão .dtd, apenas
a ferramenta DTDParser é utilizada, uma vez que não existe a necessidade da geração de
um documento DTD. É importante ressaltar que a ferramenta DTDParser possui como
maior responsabilidade a conversão do documento com extensão .dtd para um documento
XML, mas para que a ferramenta alcance seus objetivos é necessário que o documento
esteja de acordo com a especificação da W3C e obedeça às restrições apresentadas na seção
4.5.1.
4.5.4 Carregando documentos
A arquitetura JAXB disponibiliza uma forma para recuperar os dados contidos em
um documento XML e armazená-los na memória para aumentar o desempenho na
manipulação dos dados contidos no documento. É importante ressaltar que apenas os
documentos válidos de acordo com o XML Schema utilizado para a geração das classes
poderão ser carregados. Ignorar essa restrição ocasionará a geração de uma exceção
juntamente com a impossibilidade da continuação da execução do programa.
Para a realização da leitura de um documento XML, a arquitetura JAXB dispõe da
classe
Unmarshaller
que possui o método
unmarshal(...)
com a responsabilidade de
recuperar todos os dados do arquivo XML passado como parâmetro. A figura abaixo
exemplifica o processo de leitura de um documento xml.
1
...
2
JAXBContext jc = JAXBContext.newInstance( "primer.po" )
3
Unmarshaller u = jc.createUnmarshaller()
4
Raiz R = (Raiz)u.unmarshal( new FileInputStream( “arquivo.xml” ) )
5
ListaElementosAtributos = R.getElementoOrAtributos()
6
....
Figura 15 – Carregando um documento xml
57
A interface Raiz exemplificada na figura acima é a principal, onde os objetos dessa
classe são instanciados com a utilização do arquivo XML de entrada. Os objetos dessa
classe contem todos os dados do documento de entrada com métodos específicos para a
manipulação dos mesmos. O método
getElementoOrAtributos()
referente ao objeto
R
e
exemplificado na figura acima (linha 5), retorna uma lista de todos os atributos e elementos
que contem o documento XML.
O processo de integração utilizado pela ferramenta PINAJÉ carrega o primeiro
documento passado como parâmetro e o considera o esquema principal. Os próximos
arquivos serão considerados secundários, onde as mudanças ocorrerão somente no arquivo
principal (as alterações ocorrem somente em memória, não afetando os arquivos originais).
Resumidamente, esse processo de integração ocorre somente entre dois arquivos. O
resultado das integrações fica armazenado no documento principal e à espera do próximo
documento para realizar uma nova integração.
Tabela 4 – Exemplo do processo de integração
Passos
Documento
Documento
Processo de integração
Resultado da integração
1
arquivo1.xml
arquivo2.xml
⊕⊕⊕
arquivo1.xml
2
arquivo1.xml
arquivo3.xml
⊕⊕⊕
arquivo1.xml
3
arquivo1.xml
arquivo4.xml
⊕⊕⊕
arquivo1.xml
4
arquivo1.xml
arquivo5.xml
⊕⊕⊕
arquivo1.xml
5
...
...
...
arquivo1.xml
A tabela acima representa a seqüência utilizada pela ferramenta para a realização da
integração, onde as alterações são realizadas somente no primeiro documento que foi
carregado na memória. As iterações que ocorrem na execução da ferramenta dependem da
quantidade de argumentos que são passados na linha de comando.
4.5.5 Instanciando objetos
Após serem carregados os documentos de entrada, faz-se necessário a utilização de
quatro classes com funções bem definidas. As quatro classes criadas foram divididas de
acordo com suas funcionalidades e possuem responsabilidades distintas:
•
Classe PrintDTD
58
o Possui a responsabilidade de converter o documento XML, normalmente
integrado, para um documento DTD, apresentando o resultado ao usuário;
o Para instanciar um objeto dessa classe é necessário passar uma lista
contendo todos os elementos e atributos do documento a ser convertido
como construtor da classe.
•
Classe Novo
o Possui uma série de métodos com a responsabilidade de criar novos
elementos. Esses métodos são úteis, principalmente em situações que
exigem a criação de novos elementos quando seu aproveitamento no
processo de integração torna-se inviável ou quando o elemento só existe em
uma das bases;
o Para instanciar objetos dessa classe não é necessário passar nenhum
parâmetro.
•
Classe ManipulaElemento
o Todos os relacionamentos existentes entre os elementos das DTD’s a serem
integradas são de responsabilidade desta classe. Essa classe possui uma
serie de métodos que compartilham um objetivo em comum: a integração de
elementos;
o Objetos dessa classe necessitam de uma lista dos elementos e atributos que
compõem o documento XML para serem instanciados.
•
Classe ManipulaAtributo
o A integração dos atributos entre os documentos de entrada é de
responsabilidade dessa classe. Assim como a classe citada acima, a
instanciação de um objeto dessa classe exige uma lista dos elementos e
atributos que compõem o documento.
A figura 16 exemplifica a instanciação de todas as classes citadas anteriormente. A
lista de todos os elementos que compõem o documento é obtida através de um método da
interface
Raiz
exemplificado na figura 15, linha 5. Essa lista é na verdade todo o
documento, com elementos e atributos, e é utilizada pela maioria das classes.
1
...
2
PrintDTD Print = new PrintDTD(ListaElementosAtributos)
59
3
Classe Novo = new Novo()
4
ManipulaElemento MElemento = new ManipulaElemento(ListaElementosAtributos)
5
ManipulaAtributo MAtributo = new ManipulaAtributo(ListaElementosAtributos)
6
....
Figura 16 – Instanciando objetos
O objeto ListaElementoAtributo é um atributo da classe PINAJÉ que contém todos os
elementos e atributos do esquema definido como principal. O atributo ListaElemAtri também
é um atributo da mesma classe que é instanciado com todos os elementos e atributos dos
esquemas definidos como secundários.
4.5.6 Identificando elementos e atributos na lista
No processo de conversão da DTD para um documento XML, a ferramenta
DTDParser pega todo o conteúdo do documento original e o converte para uma série de
elementos, conforme foi abordado na seção 4.4 deste trabalho. Esses elementos foram
divididos em duas formas: os elementos que representam os elementos originais da DTD e
os elementos que representam todos os atributos do documento original. A tecnologia
JAXB gerou apenas um método único que retorna uma lista de todo o conteúdo do
documento original para a interface Raiz (figura 15).
Observa-se que a cada posição da lista é possível que exista um elemento ou um
atributo representado. Para identificação do tipo existente em cada posição da lista, a
seguinte alternativa foi escolhida: para cada posição, pega-se o nome da classe
representada na lista, compara com o nome da classe que trabalha com elementos; se forem
iguais, instancia um objeto
Elemento
na mesma posição da lista. Caso não seja um
elemento, então instancia-se um objeto Atributo. A figura 17 exemplifica esse processo:
1
...
2
ListaElemAtri = R2.getElementoOrAtributos();
3
for(int i=0; i< ListaElemAtri.size(); i++)
4
{
5
6
7
if(ListaElemAtri.get(i).getClass().getName().equals(classe_elemento)
|| ListaElemAtri.get(i).getClass().getName().equals(classe_elemento2))
{
60
8
Elemento E = (Elemento)ListaElemAtri.get(i);
9
....
10
}
11
else
12
{
13
Atributos As =(Atributos)ListaElemAtri.get(i);
14
...
15
}
16
17
}
...
Figura 17 – Identificando elementos e atributos
As variáveis constantes
classe_elemento
e
classe_elemento2
exemplificadas na
figura acima, nas linhas 5 e 6 respectivamente, são na verdade atributos da classe PINAJÉ
que contém o nome das classes que manipulam elementos. Como as classes foram geradas
automaticamente pela tecnologia JAXB, obedecendo ao esquema utilizado, duas classes
foram criadas com o mesmo objetivo: trabalhar com elementos. A figura 18 mostra parte
do esquema utilizado.
1
...
2
<xsd:complexType name="Raiz2">
3
<xsd:choice maxOccurs="unbounded">
4
<xsd:element name="elemento" type="Elemento"/>
5
<xsd:element name="atributos" type="Atributos" minOccurs="0"/>
6
</xsd:choice>
7
</xsd:complexType>
8
<xsd:complexType name="Elemento">
9
<xsd:sequence>
10
<xsd:element name="pai" type="Pai"/>
11
</xsd:sequence>
12
</xsd:complexType>
13
...
Figura 18 – Parte do esquema utilizado para a criação das classes
Observando o elemento complexo
Raiz2
representado na linha 2 da figura acima,
percebe-se que o mesmo pode ser formado por um ou muitos
elemento
ou zero ou muitos
atributos.
Na linha 8 da mesma figura tem-se a declaração de um elemento complexo
Elemento.
Para manipulação de elementos foi criada a interface
Elemento
referente ao
elemento complexo Elemento da linha 8. Mas na linha 4 existe um elemento desse mesmo
61
tipo; logo foi gerada uma nova interface com nome Raiz2.Elemento que herda de Elemento.
Essa duplicação de interfaces que manipulam os mesmos objetos também ocorre com
outros elementos desse mesmo esquema.
4.5.7 Classe ManipulaElemento
Como já foi mencionado anteriormente, todo objeto da classe
ManipulaElemento
é
instanciado utilizando a lista de elementos e atributos que contém todo o esquema definido
como principal. Normalmente os métodos referentes a essa classe recebem como
parâmetro alguma informação repassada pelo esquema considerado secundário e o utiliza
para uma possível integração. Os principais métodos dessa classe serão apresentados nas
seções subseqüentes.
4.5.7.1 Método nomeIgual(String nome)
Esse método é utilizado para realizar a verificação no esquema considerado
principal para confirmar uma possível existência de um elemento com o mesmo nome em
ambos os esquemas. Para isso é seguida a seguinte sequência, considerando que o esquema
principal já foi utilizado para a instanciação de um objeto da classe ManipulaElemento:
para cada elemento existente no esquema secundário, é verificado se existe um elemento
com o mesmo nome no esquema principal. O retorno desse método é do tipo boolean
podendo ser true ou false dependendo se existirem ou não elementos com os mesmos
nomes em ambos os esquemas.
4.5.7.2 Método nomeIgualTipoDiferente(String nome, String tipo)
Os dois parâmetros desse método
nome
e
tipo
são respectivamente o nome e o tipo
de um determinado elemento do esquema secundário. Esse método possui a
responsabilidade de informar se o esquemas possuem algum elemento com o mesmo nome
e com tipos diferentes. A figura representada abaixo exemplifica uma possível situação:
62
1
No esquema principal
No esquema secundário
2
<!ELEMENT usuario ( nome, dominio) >
3
...
<!ELEMENT usuario ( #PCDATA ) >
Figura 19 – Exemplos de elementos com mesmo nome e tipos diferentes
O método
nomeIgualTipoDiferente
da classe
ManipulaElemento
funciona de acordo
com os seguintes passos: inicialmente é verificado se existe no esquema principal um
elemento com o mesmo nome que foi passado como parâmetro; caso a afirmação seja
verdadeira, é buscado o tipo do elemento com base no nome que é novamente passado
como parâmetro para uma nova função,
retornaTipo(String nomeElemento),
que retorna o
tipo do elemento; após a obtenção do tipo do elemento no esquema principal, basta
compará-lo ao tipo do elemento do esquema secundário. A figura representada abaixo
mostra o código desse método.
1
2
public boolean nomeIgualTipoDiferente(String nome, String tipo)
if(nomeIgual(nome))
{
3
String type = retornaTipo(nome);
4
if(type == null)
5
return (tipo != null);
6
else
7
return(!type.equals(tipo))
8
}
9
else
10
11
{
return false;
}
Figura 20 – Exemplos do código do método nomeIgualTipoDiferente
Como pode ser observado no código representado pela figura 20, o método
nomeIgualTipoDiferente
é do tipo boolean, retornando true para a existência de elementos
com nomes iguais e tipos diferentes. Dentro da aplicação esse método só é executado após
a verificação da existência de elementos com nomes iguais em ambos os esquemas. Essa
alternativa
foi
utilizada
nomeIgualTipoDiferente
para
confirmar
a
seguinte
afirmação:
se
a
função
retornar false, então os tipos são iguais. Caso esse método fosse
utilizado sem essa restrição, a afirmação acima não seria verdadeira, pois quando os nomes
são diferentes em cada esquema, ela também retorna false.
63
4.5.7.3 Método integraNomeIgualTipoDiferente(Pai P)
Esse método é utilizado quando existe a necessidade da integração de dois
elementos com nomes iguais e tipos diferentes. O processo de integração utilizado
privilegia os tipos menos restritos ou cria-se um novo elemento com base nos elementos
de ambos os esquemas.
1
No esquema principal
No esquema secundário
2
<!ELEMENT nome ANY >
<!ELEMENT nome ( #PCDATA )>
3
Integração
4
<!ELEMENT nome ANY >
5
....
...
6
<!ELEMENT usuario ( nome, dominio) >
<!ELEMENT usuario ( #PCDATA ) >
7
Integração
8
<!ELEMENT usuario (#PCDATA | nome | dominio )*>
Figura 21 – Exemplos da integração de elementos
O parâmetro
Pai
do método acima contém as informações necessárias para a
realização da integração entre os elementos dos esquemas. Esse parâmetro representa um
elemento do esquema secundário. O figura 22 representada abaixo exemplifica parte do
código do método citado. Na linha 2 é obtido o tipo do elemento no esquema principal com
base no nome do elemento que foi passado como parâmetro.
1
public void integraNomeIgualTipoDiferente(Pai P){
2
String PrincTipo = retornaTipo(P.getNome());
3
4
if(PrincTipo = = null){
if(P.getTipo().equals("PCDATA"))
5
6
7
insereMisto(P.getNome());
...
else{
8
if(PrincTipo.equals("EMPTY")){
9
if(P.getTipo() = = null){
10
mudaPaiTipo(P.getNome(),"ANY");
11
....
12
if(PrincTipo.equals("PCDATA")){
13
if(P.getTipo() = = null)
14
15
insereMistoElemento(P);
else{
64
16
if(P.getTipo().equals("ANY")){
17
Elemento Elem = ClasseNovo.novoElemento(P);
18
removeElemento(P.getNome());
19
insereElemento(-1,Elem);
20
...
Figura 22 – Exemplos do código do método nomeIgualTipoDiferente
4.5.7.4 Método integraNomeIgualTipoIgual(Pai P)
O método
integraNomeIgualTipoIgual(Pai P)
da classe
ManipulaElemento
possui a
responsabilidade de integrar elementos com nomes iguais e tipos iguais. A utilização desse
método torna-se necessária quando são identificados em ambos os esquemas elementos
com nomes e tipos iguais mas que podem apresentar diferenças significativas. Como
exemplo das diferenças que podem ocorrer entre esquemas que possuem nomes e tipos
iguais pode-se citar os elementos formados por outros elementos. Apesar de possuírem os
mesmos nomes e o tipos, é possível que seus elementos filhos sejam diferentes.
1
esquema 1
esquema 2
2
<!ELEMENT autor (primeiroNome, sobrenome) >
<!ELEMENT autor ( nomeCompleto )>
Figura 23 – Exemplo de elementos diferentes com nomes e tipos iguais
Quando um determinado elemento possui apenas elementos filhos, como os
representados na figura 23, entende-se que seu tipo é nulo. Portanto os elementos
exemplificados acima possuem nomes e tipos iguais. Os elementos mistos também podem
ser citados como exemplo de elementos diferentes com nomes e tipos iguais. A figura
abaixo exemplifica parte do código desse método.
1
public void integraNomeIgualTipoIgual(Pai P){
2
if(P.getTipo() = = null)
3
integraPaiNulo(P);
4
else
5
if(P.getTipo().equals("misto"))
6
7
integraMisto(P.getNome(),P.getMisto());
}
Figura 24 – Código do método integraNomeIgualTipoIgual
65
O método
integraPaiNulo(Pai P)
referente a linha 3 da figura acima é responsável
pela integração de elementos que possuem apenas elementos filhos. Esse método faz a
verificação dos elementos filhos de cada elemento e os integra em um único elemento.
Além dessa integração, esse método também modifica os delimitadores do elemento
substituindo o delimitador “,” por “|” e acrescentando um modificador “*” ao elemento
“pai”. A figura abaixo exemplifica esse processo.
1
Esquema principal
Esquema secundário
2
<!ELEMENT autor (primeiroNome, sobrenome) >
<!ELEMENT autor ( nomeCompleto )>
3
processo de integração
4
<!ELEMENT autor (primeiroNome | sobrenome | nomeCompleto)* >
Figura 25 – Exemplo de integração de elementos com tipos nulos
A linha 6 da figura 24 exemplifica o método
integraMisto(String,Misto)
responsável
pela integração de elementos mistos. O processo utilizado para a integração de elementos
mistos é semelhante ao processo de integração de elementos com tipos nulos,
diferenciando-se apenas pelo fato que a integração de elementos mistos não exige uma
mudança na estrutura do elemento, apenas são acrescentados novos elementos ao elemento
referente ao esquema principal.
1
Esquema principal
Esquema secundário
2
<!ELEMENT pai (#PCDATA | filho | nome)*>
<!ELEMENT pai (#PCDATA | filho | mod )*>
3
processo de integração
4
<!ELEMENT pai (#PCDATA | filho | nome | mod)* >
Figura 26 – Exemplo de integração de elementos mistos
4.5.7.5 Método insereElemento(int indice, Elemento E)
O método
insereElemento(int, Elemento)
é utilizado quando existe um elemento no
esquema secundário que não existe no esquema principal. Para que o objetivo da
integração seja alcançado é necessário que o esquema principal (ou esquema final) suporte
66
todas as instâncias dos documentos XML suportados por cada esquema. Portanto torna-se
necessário a inclusão desse novo elemento no esquema principal.
1
public void insereElemento(int indice,Elemento E)
2
{
3
if(indice == -1)
4
ListaElementosAtributos.add(E);
5
else
6
7
ListaElementosAtributos.add(indice,E);
}
Figura 27 – Inserindo novos elementos
O parâmetro
indice
do método
insereElemento(...)
é utilizado para informar a
posição em que o novo elemento será inserido. Ele é bastante útil em situações que por
conveniência, um determinado elemento é substituído no processo de integração. Quando
esse parâmetro for igual a “–1” ele deverá ser desconsiderado e o elemento é inserido na
última posição. O parâmetro Elemento é o elemento que será inserido no esquema principal.
4.5.8 Classe ManipulaAtributo
Assim como a classe
ManipulaElemento,
a classe
ManipulaAtributo
exige um
construtor para a instanciação de objetos referentes a essa classe. Outra semelhança com a
classe citada é a utilização do mesmo construtor e os mesmos nomes de grande parte dos
métodos; embora as implementações sejam diferentes, a idéia central é a mesma. Ambas as
classes são instanciadas com os elementos que compõem o esquema principal. As seções
subseqüentes apresentam os principais métodos dessa classe.
4.5.8.1 Método nomeIgual(String elem,String nome)
O método
nomeIgual(String,
String)
da classe ManipulaAtributo possui a
responsabilidade de informar uma possível existência de um determinado atributo
relacionado a um elemento. O primeiro parâmetro desse método informa o nome do
elemento que o atributo está relacionado. Esse procedimento torna-se necessário, pois é
67
possível que existam atributos com os mesmos nomes e relacionados a elementos
diferentes. O retorno desse método é true ou false dependendo da existência ou não do
atributo relacionado ao elemento informado.
4.5.8.2 Método nomeIgualTipoIgual(String elem,String nome, String Tipo)
A responsabilidade de informar a existência de atributos com nomes e tipos iguais
relacionados a elementos com o mesmo nome em ambos os esquemas é desse método. O
retorno desse método pode ser true ou false. A figura abaixo apresenta o código referente
oa método citado.
1
public boolean nomeIgualTipoIgual(String elemento,String nome,String tipo)
2
{
3
for(int i=0; i< ListaElementosAtributos.size(); i++)
4
{
5
if(ListaElementosAtributos.get(i).getClass().getName().equals(classe_atributos)
6
|| listaElementosAtributos.get(i).getClass().getName().equals(classe_atributos2))
7
{
8
Atributos As =(Atributos)ListaElementosAtributos.get(i);
9
List Atr = As.getAtributo();
10
for(int j=0; j<Atr.size(); j++)
11
{
12
Atributo A = (Atributo)Atr.get(j);
13
if(As.getElementoRef().equals(elemento) && A.getNome().equals(nome)
14
&& A.getTipo().equals(tipo))
15
return true;
16
}
17
}
18
}
19
return false;
20
}
Figura 28 – Código do método nomeIgualTipoIgual da classe ManipulaAtributo
As linhas 5 e 6 da figura 28 acima possuem a responsabilidade de verificar se o
elemento referente a cada posição da lista é um atributo. Quando uma determinada posição
da lista for um atributo, é realizada um associação entre um objeto da classe
Atributos
eo
item referente a uma determinada posição da lista. Atributos são formados por uma lista de
68
Atributo
e o mesmo processo é realizado (linhas 9,10, 11, 12). Essa rotina se repete até que
o elemento seja encontrado ou quando acabarem os itens da lista, retornando true ou false,
respectivamente.
4.5.8.3 Método integraNomeIgualTipoIgual(String elem,Atributo A)
O método
integraNomeIgualTipoIgual(String, Atributo)
é responsável pela integração
dos atributos que possuem nomes e tipos iguais e estão relacionados a elementos com os
mesmos nomes em ambos os esquemas. O primeiro parâmetro desse método armazena o
nome do elemento que está relacionado ao atributo e o segundo parâmetro contém as
informações referente ao atributo.
A utilização desse método torna-se necessária quando existem atributos com
informações distintas em ambos os esquemas mas que estão relacionados a elementos com
os mesmos nomes, possuindo nomes e tipos iguais. Atributos com diferentes padrões de
declarações (REQUIRED, IMPLIED) podem ser enquadrados nesse contexto.
1
2
Esquema principal
<!ATTLIST data dia
CDATA #REQUIRED>
Esquema secundário
<!ATTLIST data dia
CDATA #IMPLIED>
Figura 29 – Exemplo de atributos com padrões de declarações diferentes
Atributos do tipo enumerado e do tipo notação também podem ser enquadrados no
contexto acima. É possível que atributos do tipo enumerado ou notação possuam
argumentos diferentes. O processo de integração utilizado pela ferramenta PINAJÉ prevê
essa situação, integrando no esquema principal os atributos de ambos os esquemas.
Resumidamente, é feito uma varredura nos atributos de ambos os esquemas, acrescentando
no atributo referente ao esquema principal os argumentos que só existem no atributo
referente ao esquema secundário.
69
4.5.8.4 Método integraNomeIgualTipoDiferente(String elem,Atributo A)
Para a integração de atributos com nomes iguais e tipos diferentes foi definida uma
única regra. Baseando-se nos tipos de atributos de uma DTD, que se resumem em apenas
dez tipos distintos, e na dificuldade da realização de uma integração de atributos distintos,
optou-se por padronizar aintegração de todos os atributos com nomes iguais e tipos
diferentes. Como exemplo da dificuldade encontrada pode-se citar a integração de dois
atributos: um do tipo
NOTATION.
ID
e outro do tipo
IDREF
ou ainda um atributo
FIXED
e outro do tipo
Em todos as ocorrências de atributos com as caracteristicas citadas
anteriormente, terá como resultado um atributo do tipo
CDATA
e
IMPLIED.
A figura abaixo
exemplifica parte do código referente ao método integraNomeIgualTipoDiferente(...).
1
public void integraNomeIgualTipoDiferente(String elementoRef,Atributo a)
2
{
3
...
4
Atributos As =(Atributos)ListaElementosAtributos.get(i);
5
List Atr = As.getAtributo();
6
for(int j=0; j<Atr.size(); j++)
7
{
8
9
Atributo A = (Atributo)Atr.get(j);
if(As.getElementoRef().equals(elementoRef) && A.getNome().equals(a.getNome()))
10
{
11
A.setTipo("CDATA");
12
A.setPadrao("IMPLIED");
13
A.setAttribValue(null);
14
15
...
}
Figura 30 – Parte do código do método
integraNomeIgualTipoDiferente
da classe
ManipulaAtributo
Como foi mencionado anteriormente, esse método apenas modifica o atributo
desejado tornando-o bastante amplo. Uma restrição maior poderá ser introduzida pelo
usuário após a realização do processo de integração da ferramenta PINAJÉ.
70
4.5.8.5 Método insereAtributo(Atributo A, String elemento)
Assim como ocorreu a necessidade de inserir novos elementos para a realização da
integração entre os elementos, o mesmo ocorre quando deseja-se integrar atributos, pois as
chances de existirem atributos com nomes distintos referentes a um mesmo elemento não
devem ser desconsideradas.
O primeiro parâmetro desse método é o atributo desejado para a inserção; o
segundo parâmetro informa o elemento que o atributo está relacionado. O primeiro passo
do processo de inserção de um atributo é a verificação da existência de mais atributos
relacionados ao elemento especificado. Confirmando a existência, a inserção é realizada na
lista de todos os atributos referentes ao elemento informado. Caso não exista nenhum
atributo relacionado ao elemento, é criado um novo objeto da classe
Atributos;
insere o
atributo na lista desse objeto e insere o conteúdo do objeto no esquema principal. A figura
31 exemplifica parte do código desse método.
1
public void insereAtributo(Atributo a,String elemento){
2
boolean existe = false;
3
...
4
Atributos As =(Atributos)ListaElementosAtributos.get(i);
5
if(As.getElementoRef().equals(elemento))
6
{
7
As.getAtributo().add(a);
8
existe = true;
9
}
10
...
11
If(!existe){
12
...
13
Atributos AS = ClasseNovo.novoAtributos(elemento);
14
AS.getAtributo().add(a);
15
ListaElementosAtributos.add(AS);
16
17
…
}
Figura 31 – Parte do código do método insereAtributo(...)
A variável “booleana” existe é utilizada para informar se foi encontrado pelo menos
um atributo relacionado ao elemento que foi passado como parâmetro. Quando não é
71
encontrado nenhum atributo relacionado ao elemento informado, o atributo é inserido no
esquema principal como único atributo do elemento informado.
72
5. CONSIDERAÇÕES FINAIS
A alta heterogeneidade que envolve grande parte dos documentos XML dificulta
seu tratamento eficiente. Consultas, atualizações, remoções e inserções podem ser tarefas
desgastantes quando a fonte acessada não apresenta uma estrutura regular. Para tanto, o
tratamento de documentos semi-estruturados é normalmente realizado com base em um
esquema relacionado à fonte desejada. As informações contidas nesse esquema ajudam a
minimizar o impacto da alta heterogeneidade desses documentos.
Contudo, a heterogeneidade dos documentos também é refletida em seus esquemas.
É comum a existência de esquemas diferentes relacionados a um mesmo domínio de
aplicação. A flexibilidade e subjetividade, características dos documentos XML, muitas
vezes também são herdadas pelos seus esquemas. A existência de um esquema único,
global, suficientemente capaz de suportar todas as alternativas possíveis para todos os
documentos referentes a um mesmo domínio de aplicação, solucionaria o problema
mencionado. A integração dos esquemas existentes pode ser uma alternativa viável para a
geração de um esquema global.
Uma alternativa para a integração de esquemas para documentos semi-estruturados
é apresentada nesse trabalho. Esse processo de integração tenta unir todas as informações
contidas em cada esquema a ser integrado em um único esquema geral. No entanto, os
esquemas menos restritos prevalecem sobre os demais e pode muitas vezes omitir as
informações contidas em esquemas mais rígidos.
Apesar do processo de integração de esquemas XML utilizado nesse trabalho ser
inteiramente sintático, não considerando a semântica dos dados contidos nos documentos,
a ferramenta desenvolvida pode ser uma solução para a problemática da integração de
esquemas semi-estruturados representados através da utilização de DTD’s. O problema
semântico pode ser resolvido pela aplicação, que se beneficiará do esquema integrado,
73
juntamente com auxílio de um especialista de domínio, visto que a mesma informação
pode estar disponibilizada diferentemente.
Como trabalho futuro, pretende-se realizar a integração de outros tipos de esquemas
XML. Esquemas representados pela linguagem XML Schema disponibilizam normalmente
mais informações que as DTD’s. Assim como as DTD’s, os documentos XML Schema
possuem uma seqüência lógica que pode ser prevista por outro esquema. A própria W3C
disponibiliza um esquema geral dessa linguagem. No entanto, a integração desses
esquemas requer mais detalhamento que o utilizado pela proposta. A possibilidade da
utilização de namespaces e as diversas alternativas de representação de uma mesma
informação são fatores relevantes e que deverão ser levados em consideração. Uma
integração semântica e semi-automática torna-se interessante.
74
6. REFERÊNCIAS BIBLIOGRÁFICAS
(ANDERSON, 2001)
ANDERSON, R. et al. Professional XML. Rio de Janeiro:
Ciência Moderna LTDA., 2001.
(AHO et al 1995)
AHO, Alred V., SETHI Ravi, ULLMAN, Jeffrey D.,
Compiladores Principios, Técnicas e Ferramentas,
Tradução Daniel de Ariosto Pinto, Editora: Afiliada, Rio
de Janeiro, RJ 1995.
(ARMSTRONG, 2003)
ARMSTRONG, E. et al. Java Web Services Tutorial.
Disponível
em
http://java.sun.com/webservices/docs/1.3/tutorial/doc/inde
x.html. Acesso em 10/09/2003
(BARTINI, 1986)
BARTINI, C; LANZERINI, M; NAVATHE, S. B. A
comparative analysis of methodologies for database
schema integration. ACM Press, New York, NY, USA,
December 1986.
(CASTANO, 2001)
CASTANO, S.; ANTONELLIS, V.; VIMERCATI, S. C.
Global Viewing of Heterogeneous Data Sources. on
Knowledge and Data Engineering, 2000. Disponível em
http://192.167.20.141/webdb/interdata_tema3/Artemis/arti
cles.html. Acesso em 05/11/03.
(DAUM, 2002)
DAUM, Berthold; MERTEN, Udo. Arquitetura de
Sistemas com XML. Rio de Janeiro: Campus, 2002. 440p
(DTDGenerator, 2003)
DTDGenerator. A tool to generate XML DTds. Version
7.0.
Disponível
na
internet
em
75
http://saxon.sourceforge.net/dtdgen.html.
Acesso
05/11/2003
(DTDParser, 2003)
DTDParser, JavaCC Grammar Repository. Disponível
em:http://www.cobase.cs.ucla.edu/pub/javacc/DTDParser.j
j. Acessado em 08/10/2003.
(GOLDMAN, 2000)
GOLDMAN,
Roy;
Widom,
Jennifer.
DataGuides:
Enabling Query Formulation and Optimization in
Semistructured
Databases.
Disponível
em
<http://dbpubs.stanford.edu:8090/pub/showDoc.Fulltext?
lang=en&doc=1997-50&format=pdf&compression=>
Acesso em 22/04/2003.
(ISO, 2003)
ISO. International Organization for Standardization.
Disponível em http://www.iso.ch. Acesso 03/11/2003
(LORE, 2003)
LORE, Database. Stanford: Universidade de Stanford.
Disponível em <http://www-db.stanford.edu/lore/> Acesso
em 02/06/2003.
(MARCHAL, 2000)
MARCHAL, Benoit. XML conceitos e aplicações. São
Paulo: Berkeley, 2000. 547p.
(McGRATH, 1999)
McGRATH, Sean. XML Aplicações práticas. Rio de
Janeiro: Campus, 1999. 367p.
(McHUGH, 1997)
McHUGH,
QUASS,
J.;
D.;
Management
ABITEBOUL
S.;
WIDOM,
Lore:
System
J..
for
GOLDMAN,
A
R.;
Database
Semistructured
Data.
SIGMOD Record, 26(3): 54-66 (1997).
(MELLO, 2002)
MELLO, R. S. Uma Abordagem Bottom- Up para a
Integração Semântica de Esquemas XML. Tese
(Doutorado), Programa de pos-graduação em Computação.
Universidade Federal do Rio Grande do Sul, Porto
76
Alegre.145p.
(MELO, 2000)
MELO, Ronaldo dos Santos. Aplicação de Ontologias a
Bancos de Dados Semi-Estruturados. Exame de
Qualificação (Pós-Graduação em Computação) 2000.
Instituto de Informática da Universidade Federal do Rio
Grande do Sul. Universidade Federal do Rio Grande do
Sul, Porto Alegre.150 p.
(PAPAKONSTANTINOU,1995) PAPAKONSTANTINOU, Y; GARCIA-MOLINA, H;
WIDOM, J. Object Exchange Across Heterogeneous
Information Sources. International Conference on Data
Engineering, Taipei, Taiwan, 1995.
(RAHM, 2001)
RAHM, E;BERNSTEIN, P; PHILIP, A. On Matching
Schemas Automatically. Disponível em http://dol.unileipzig.de/pub/2001-5. Acesso 03/11/2003
(SHETH, 1990)
SHETH, A. P; LARSON, J, A. Federal Database System
for
Managing
Automomous
Distributed,
Heterogeneos,
and
Disponível
em
Databases.
http://lsdis.cs.uga.edu/lib/download/SL90.pdf.
Acesso
03/11/2003.
(SOFTWARE AG, 1999)
SOFTWARE
Documentation
AG.
Introducing
Overview.
Tamino.
Tamino
Disponível
em
<http://www.cs.uni-essen.de/dawis
/teaching/ss2000/nsdb/tamino/help/concepts/cfintro.htm>.
Acesso em 20/06/2003
(SOFTWARE AG, 2003)
SOFTWARE AG, Tamino XML Server . Disponível em
<http://www.softwareag.com/tamino/>.
Acesso
em
23/04/2003
(TAMINO, 2002)
TAMINO DOCUMENTATION. Tamino XML Server
Version 3.1.1. abril 2002
(W3C CONSORTIUM, 2003)
W3C CONSORTIUM. XML Schema Part 0: Primer.
77
W3C Recommendation 02 may 2001. Disponível em <
http://www.w3.org/TR/xmlschema-2/
>
Acesso
em
Integration
of
11/03/2003
(WIEDERHOLD, 1993)
WIEDERHOLD,
G.
Inteligent
Information. ACM-SIGMOD, Washington DC, May
1993.
(XML, 2003)
WORLD WIDE WEB CONSORTIUM. Extensible
Markup
Language
(XML).
Disponível
<http://www.w3.org/XML/>. Acesso em 12/05/2003.
em
78
ANEXOS
79
DOCUMENTO 1: Documento XML referente ao domínio de monografias
<?xml version="1.0" encoding="ISO-8859-1"?>
<monografia>
<capa>
<logomarca>CEULP / ULBRA</logomarca>
<instituicao>Centro Universitario Luterano de Palmas</instituicao>
<titulo>DTD</titulo>
<autor>Marcus Pinto</autor>
<local>Palmas</local>
<ano>2003</ano>
</capa>
<contracapa>
<logomarca>CEULP / ULBRA</logomarca>
<instituicao>Centro Universitario Luterano de Palmas</instituicao>
<titulo>DTD</titulo>
<autor>Marcus Pinto</autor>
<orientador>Deise de Brum</orientador>
<local>Palmas</local>
<ano>2003</ano>
</contracapa>
<agradecimento>Agradeco...</agradecimento>
<sumario numero= "1" pag= "8">
<titulo>Introducao</titulo>
</sumario>
<sumario numero= "2" pag= "9">
<titulo>Revisao de Literatura</titulo>
</sumario>
<listadefiguras>
<figura numero="1" pagina="15">nome da figura#1</figura>
<figura numero="2" pagina="25">nome da figura#2</figura>
</listadefiguras>
<listadetabelas>
<tabela numero="1" pagina="20">nome da tabela#1</tabela>
<tabela numero="2" pagina="30">nome da tabela#2</tabela>
</listadetabelas>
<resumo>
<textoResumo>este eh o resumo</textoResumo>
<palavraChave>palavra#1</palavraChave>
<palavraChave>palavra#2</palavraChave>
</resumo>
<abstract>
80
<textoAbstract>este eh o resumo</textoAbstract>
<keyword>palavra#1</keyword>
<keyword>palavra#2</keyword>
</abstract>
<corpo>
<capitulo numero="1" pagina="8" titulo="Introducao">
<paragrafo>primasdh
sbfjh
sbghbasfbgkf
gihouhfgoiuahr
iughpia
drgoiuahv airgius guygsou</paragrafo>
<secao numero="1" pagina="8" titulo="subIntroducao">
<paragrafo>ajsgjfasgdjfgasdgh</paragrafo>
<figuraCorpo
number="1"
pag="15">nome
da
figura
da
figura
#1</figuraCorpo>
<paragrafo>ajsgjfasgdjfgasdgh</paragrafo>
</secao>
</capitulo>
<capitulo numero="2" pagina="9" titulo="Revisao de Literatura">
<paragrafo>jhsg djgsdgjsgjd</paragrafo>
<secao numero="3" pagina="10" titulo="secaoTeste">
<paragrafo>jhsg djgsdgjsgjd</paragrafo>
<figuraCorpo
number="2"
pag="25">nome
#2</figuraCorpo>
</secao>
</capitulo>
<capitulo numero="3" pagina="20" titulo="Materiais e Metodos">
<paragrafo>jhsg djgsdgjsgjd</paragrafo>
<lista>
<item>item#1</item>
<item>item#2</item>
<item>item#3</item>
</lista>
<paragrafo>jhsg djgsdgjsgjd</paragrafo>
</capitulo>
</corpo>
<referencias>texto</referencias>
<anexos>texto</anexos>
</monografia>
81
DOCUMENTO 2: Documento XML referente ao domínio de monografias
<?xml version="1.0"?>
<monografia>
<capa>
<identificacao>
<logomarca> CEULP / ULBRA </logomarca>
<nomeinstituicao>
Centro
Universitario
Luterano
de
Luterano
de
Palmas</nomeinstituicao>
<titulo> SGML </titulo>
<autor>Pollyane Lustosa</autor>
<local>Palmas</local>
<ano>2003</ano>
</identificacao>
</capa>
<contracapa>
<identificacao>
<logomarca> CEULP / ULBRA </logomarca>
<nomeinstituicao>
Centro
Universitario
Palmas</nomeinstituicao>
<titulo> SGML </titulo>
<autor>Pollyane Lustosa</autor>
<local>Palmas></local>
<ano>2003</ano>
</identificacao>
<texto> Trabalho para Topicos II</texto>
</contracapa>
<resumo>O trabalho e interessante...</resumo>
<abstract>The work is interessant...</abstract>
<listatabelas>
<itemtabela> Tabela 1 - Blabla</itemtabela>
<itemtabela> Tabela 2 - Bleble</itemtabela>
</listatabelas>
<listafiguras>
<itemfigura> Figura 1 - Blabla</itemfigura>
<itemfigura> Figura 2 - Bleble</itemfigura>
</listafiguras>
<sumario>
<item>Introducao</item>
<item>Desenvolvimento</item>
<item>Conclusao</item>
<subitem> SGML </subitem>
82
<subitem> HTML </subitem>
</sumario>
<corpomonografia>
<secao>
<titulo>Introducao</titulo>
<corpo>
<paragrafo>
<texto> amdlsokokspfkdo</texto>
<citacaodireta>
<autor> Maria </autor>
<ano> 2000 </ano>
</citacaodireta>
</paragrafo>
<figura>Figura 1</figura>
<paragrafo>
<texto> amdlsokokspfkdo</texto>
<citacaodireta>
<autor> Maria </autor>
<ano> 2000 </ano>
</citacaodireta>
</paragrafo>
</corpo>
</secao>
<secao>
<titulo>Desenvolvimento</titulo>
<corpo>
<paragrafo>
<texto> amdlsokokspfkdo</texto>
<citacaodireta>
<autor> Maria </autor>
<ano> 2000 </ano>
</citacaodireta>
</paragrafo>
</corpo>
<subsecao1>
<titulo>Linguagens de Marcacao</titulo>
<corpo>
<paragrafo>
<texto> amdlsokokspfkdo</texto>
<citacaodireta>
<autor> Maria </autor>
<ano> 2000 </ano>
83
</citacaodireta>
</paragrafo>
</corpo>
<subsecao2>
<titulo>SGML</titulo>
<corpo>
<paragrafo>
<texto> amdlsokokspfkdo</texto>
<citacaodireta>
<autor> Maria </autor>
<ano> 2000 </ano>
</citacaodireta>
</paragrafo>
</corpo>
</subsecao2>
<subsecao2>
<titulo>HTML</titulo>
<corpo>
<paragrafo>
<texto> amdlsokokspfkdo</texto>
<citacaodireta>
<autor> Maria </autor>
<ano> 2000 </ano>
</citacaodireta>
</paragrafo>
</corpo>
</subsecao2>
</subsecao1>
</secao>
</corpomonografia>
<referenciabibliografica>
<titulo> a vida </titulo>
<cidade> palmas </cidade>
<editora> atica </editora>
<ano> 2000 </ano>
</referenciabibliografica>
<anexo>
blaldlfadoaodgldla
</anexo>
</monografia>
84
DTD 1 : DTD gerada automaticamente pela ferramenta DTDGenerator com base no
DOCUMENTO 1
<!ELEMENT abstract ( textoAbstract, keyword+ ) >
<!ELEMENT agradecimento ( #PCDATA ) >
<!ELEMENT anexos ( #PCDATA ) >
<!ELEMENT ano ( #PCDATA ) >
<!ELEMENT autor ( #PCDATA ) >
<!ELEMENT capa ( logomarca, instituicao, titulo, autor, local, ano ) >
<!ELEMENT capitulo ( lista | paragrafo | secao )+ >
<!ATTLIST capitulo numero NMTOKEN #REQUIRED >
<!ATTLIST capitulo pagina NMTOKEN #REQUIRED >
<!ATTLIST capitulo titulo CDATA #REQUIRED >
<!ELEMENT contracapa ( logomarca, instituicao, titulo, autor, orientador, local, ano ) >
<!ELEMENT corpo ( capitulo+ ) >
<!ELEMENT figura ( #PCDATA ) >
<!ATTLIST figura numero NMTOKEN #REQUIRED >
<!ATTLIST figura pagina NMTOKEN #REQUIRED >
<!ELEMENT figuraCorpo ( #PCDATA ) >
<!ATTLIST figuraCorpo number NMTOKEN #REQUIRED >
<!ATTLIST figuraCorpo pag NMTOKEN #REQUIRED >
<!ELEMENT instituicao ( #PCDATA ) >
<!ELEMENT item ( #PCDATA ) >
<!ELEMENT keyword ( #PCDATA ) >
<!ELEMENT lista ( item+ ) >
<!ELEMENT listadefiguras ( figura+ ) >
<!ELEMENT listadetabelas ( tabela+ ) >
<!ELEMENT local ( #PCDATA ) >
<!ELEMENT logomarca ( #PCDATA ) >
<!ELEMENT
monografia
(
capa,
contracapa,
agradecimento,
listadetabelas, resumo, abstract, corpo, referencias, anexos ) >
<!ELEMENT orientador ( #PCDATA ) >
<!ELEMENT palavraChave ( #PCDATA ) >
<!ELEMENT paragrafo ( #PCDATA ) >
<!ELEMENT referencias ( #PCDATA ) >
<!ELEMENT resumo ( textoResumo, palavraChave+ ) >
<!ELEMENT secao ( figuraCorpo | paragrafo | subsecao )+ >
<!ATTLIST secao numero NMTOKEN #REQUIRED >
<!ATTLIST secao pagina NMTOKEN #REQUIRED >
<!ATTLIST secao titulo NMTOKEN #REQUIRED >
<!ELEMENT subsecao EMPTY >
sumario+,
listadefiguras,
85
<!ELEMENT sumario ( titulo ) >
<!ATTLIST sumario numero NMTOKEN #REQUIRED >
<!ATTLIST sumario pag NMTOKEN #REQUIRED >
<!ELEMENT tabela ( #PCDATA ) >
<!ATTLIST tabela numero NMTOKEN #REQUIRED >
<!ATTLIST tabela pagina NMTOKEN #REQUIRED >
<!ELEMENT textoAbstract ( #PCDATA ) >
<!ELEMENT textoResumo ( #PCDATA ) >
<!ELEMENT titulo ( #PCDATA ) >
86
DTD 2 : DTD gerada automaticamente pela ferramenta DTDGenerator com base no
DOCUMENTO 2
<!ELEMENT abstract ( #PCDATA ) >
<!ELEMENT anexo ( #PCDATA ) >
<!ELEMENT ano ( #PCDATA ) >
<!ELEMENT autor ( #PCDATA ) >
<!ELEMENT capa ( identificacao ) >
<!ELEMENT cidade ( #PCDATA ) >
<!ELEMENT citacaodireta ( autor, ano ) >
<!ELEMENT contracapa ( identificacao, texto ) >
<!ELEMENT corpo ( figura | paragrafo )+ >
<!ELEMENT corpomonografia ( secao+ ) >
<!ELEMENT editora ( #PCDATA ) >
<!ELEMENT figura ( #PCDATA ) >
<!ELEMENT identificacao ( logomarca, nomeinstituicao, titulo, autor, local, ano ) >
<!ELEMENT item ( #PCDATA ) >
<!ELEMENT itemfigura ( #PCDATA ) >
<!ELEMENT itemtabela ( #PCDATA ) >
<!ELEMENT listafiguras ( itemfigura+ ) >
<!ELEMENT listatabelas ( itemtabela+ ) >
<!ELEMENT local ( #PCDATA ) >
<!ELEMENT logomarca ( #PCDATA ) >
<!ELEMENT monografia ( capa, contracapa, resumo, abstract, listatabelas, listafiguras, sumario,
corpomonografia, referenciabibliografica, anexo ) >
<!ELEMENT nomeinstituicao ( #PCDATA ) >
<!ELEMENT paragrafo ( texto, citacaodireta ) >
<!ELEMENT referenciabibliografica ( titulo, cidade, editora, ano ) >
<!ELEMENT resumo ( #PCDATA ) >
<!ELEMENT secao ( titulo, corpo, subsecao1? ) >
<!ELEMENT subitem ( #PCDATA ) >
<!ELEMENT subsecao1 ( titulo, corpo, subsecao2+ ) >
<!ELEMENT subsecao2 ( titulo, corpo ) >
<!ELEMENT sumario ( item+, subitem+ ) >
<!ELEMENT texto ( #PCDATA ) >
<!ELEMENT titulo ( #PCDATA ) >
87
DOC 1: DTD 1 representada através da linguagem XML com a utilização da ferramenta
DTDParser alterada
<raiz>
<elemento>
<pai>
<filho>
<nome>textoAbstract</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<mod>+</mod>
<nome>keyword</nome>
</filho>
<nome>abstract</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>agradecimento</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>anexos</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>ano</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>autor</nome>
</pai>
</elemento>
88
<elemento>
<pai>
<filho>
<nome>logomarca</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>instituicao</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>titulo</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>autor</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>local</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>ano</nome>
</filho>
<nome>capa</nome>
</pai>
</elemento>
<elemento>
<pai>
<filho>
<nome>lista</nome>
</filho>
<delimitador>|</delimitador>
<filho>
<nome>paragrafo</nome>
</filho>
<delimitador>|</delimitador>
<filho>
<nome>secao</nome>
</filho>
<mod>+</mod>
89
<nome>capitulo</nome>
</pai>
</elemento>
<atributos>
<atributo>
<tipo>NMTOKEN</tipo>
<padrao>REQUIRED</padrao>
<nome>numero</nome>
</atributo>
<elementoRef>capitulo</elementoRef>
</atributos>
<atributos>
<atributo>
<tipo>NMTOKEN</tipo>
<padrao>REQUIRED</padrao>
<nome>pagina</nome>
</atributo>
<elementoRef>capitulo</elementoRef>
</atributos>
<atributos>
<atributo>
<tipo>CDATA</tipo>
<padrao>REQUIRED</padrao>
<nome>titulo</nome>
</atributo>
<elementoRef>capitulo</elementoRef>
</atributos>
<elemento>
<pai>
<filho>
<nome>logomarca</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>instituicao</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>titulo</nome>
</filho>
<delimitador>,</delimitador>
<filho>
90
<nome>autor</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>orientador</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>local</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>ano</nome>
</filho>
<nome>contracapa</nome>
</pai>
</elemento>
<elemento>
<pai>
<filho>
<mod>+</mod>
<nome>capitulo</nome>
</filho>
<nome>corpo</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>figura</nome>
</pai>
</elemento>
<atributos>
<atributo>
<tipo>NMTOKEN</tipo>
<padrao>REQUIRED</padrao>
<nome>numero</nome>
</atributo>
<elementoRef>figura</elementoRef>
</atributos>
<atributos>
<atributo>
91
<tipo>NMTOKEN</tipo>
<padrao>REQUIRED</padrao>
<nome>pagina</nome>
</atributo>
<elementoRef>figura</elementoRef>
</atributos>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>figuraCorpo</nome>
</pai>
</elemento>
<atributos>
<atributo>
<tipo>NMTOKEN</tipo>
<padrao>REQUIRED</padrao>
<nome>number</nome>
</atributo>
<elementoRef>figuraCorpo</elementoRef>
</atributos>
<atributos>
<atributo>
<tipo>NMTOKEN</tipo>
<padrao>REQUIRED</padrao>
<nome>pag</nome>
</atributo>
<elementoRef>figuraCorpo</elementoRef>
</atributos>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>instituicao</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>item</nome>
</pai>
</elemento>
<elemento>
<pai>
92
<tipo>PCDATA</tipo>
<nome>keyword</nome>
</pai>
</elemento>
<elemento>
<pai>
<filho>
<mod>+</mod>
<nome>item</nome>
</filho>
<nome>lista</nome>
</pai>
</elemento>
<elemento>
<pai>
<filho>
<mod>+</mod>
<nome>figura</nome>
</filho>
<nome>listadefiguras</nome>
</pai>
</elemento>
<elemento>
<pai>
<filho>
<mod>+</mod>
<nome>tabela</nome>
</filho>
<nome>listadetabelas</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>local</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>logomarca</nome>
</pai>
93
</elemento>
<elemento>
<pai>
<filho>
<nome>capa</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>contracapa</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>agradecimento</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<mod>+</mod>
<nome>sumario</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>listadefiguras</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>listadetabelas</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>resumo</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>abstract</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>corpo</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>referencias</nome>
94
</filho>
<delimitador>,</delimitador>
<filho>
<nome>anexos</nome>
</filho>
<nome>monografia</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>orientador</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>palavraChave</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>paragrafo</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>referencias</nome>
</pai>
</elemento>
<elemento>
<pai>
<filho>
<nome>textoResumo</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<mod>+</mod>
<nome>palavraChave</nome>
</filho>
95
<nome>resumo</nome>
</pai>
</elemento>
<elemento>
<pai>
<filho>
<nome>figuraCorpo</nome>
</filho>
<delimitador>|</delimitador>
<filho>
<nome>paragrafo</nome>
</filho>
<delimitador>|</delimitador>
<filho>
<nome>subsecao</nome>
</filho>
<mod>+</mod>
<nome>secao</nome>
</pai>
</elemento>
<atributos>
<atributo>
<tipo>NMTOKEN</tipo>
<padrao>REQUIRED</padrao>
<nome>numero</nome>
</atributo>
<elementoRef>secao</elementoRef>
</atributos>
<atributos>
<atributo>
<tipo>NMTOKEN</tipo>
<padrao>REQUIRED</padrao>
<nome>pagina</nome>
</atributo>
<elementoRef>secao</elementoRef>
</atributos>
<atributos>
<atributo>
<tipo>NMTOKEN</tipo>
<padrao>REQUIRED</padrao>
<nome>titulo</nome>
</atributo>
96
<elementoRef>secao</elementoRef>
</atributos>
<elemento>
<pai>
<tipo>EMPTY</tipo>
<nome>subsecao</nome>
</pai>
</elemento>
<elemento>
<pai>
<filho>
<nome>titulo</nome>
</filho>
<nome>sumario</nome>
</pai>
</elemento>
<atributos>
<atributo>
<tipo>NMTOKEN</tipo>
<padrao>REQUIRED</padrao>
<nome>numero</nome>
</atributo>
<elementoRef>sumario</elementoRef>
</atributos>
<atributos>
<atributo>
<tipo>NMTOKEN</tipo>
<padrao>REQUIRED</padrao>
<nome>pag</nome>
</atributo>
<elementoRef>sumario</elementoRef>
</atributos>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>tabela</nome>
</pai>
</elemento>
<atributos>
<atributo>
<tipo>NMTOKEN</tipo>
<padrao>REQUIRED</padrao>
97
<nome>numero</nome>
</atributo>
<elementoRef>tabela</elementoRef>
</atributos>
<atributos>
<atributo>
<tipo>NMTOKEN</tipo>
<padrao>REQUIRED</padrao>
<nome>pagina</nome>
</atributo>
<elementoRef>tabela</elementoRef>
</atributos>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>textoAbstract</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>textoResumo</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>titulo</nome>
</pai>
</elemento>
</raiz>
98
DOC 2: DTD 2 representada através da linguagem XML com a utilização da ferramenta
DTDParser alterada.
<raiz>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>abstract</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>anexo</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>ano</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>autor</nome>
</pai>
</elemento>
<elemento>
<pai>
<filho>
<nome>identificacao</nome>
</filho>
<nome>capa</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>cidade</nome>
</pai>
99
</elemento>
<elemento>
<pai>
<filho>
<nome>autor</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>ano</nome>
</filho>
<nome>citacaodireta</nome>
</pai>
</elemento>
<elemento>
<pai>
<filho>
<nome>identificacao</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>texto</nome>
</filho>
<nome>contracapa</nome>
</pai>
</elemento>
<elemento>
<pai>
<filho>
<nome>figura</nome>
</filho>
<delimitador>|</delimitador>
<filho>
<nome>paragrafo</nome>
</filho>
<mod>+</mod>
<nome>corpo</nome>
</pai>
</elemento>
<elemento>
<pai>
<filho>
<mod>+</mod>
100
<nome>secao</nome>
</filho>
<nome>corpomonografia</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>editora</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>figura</nome>
</pai>
</elemento>
<elemento>
<pai>
<filho>
<nome>logomarca</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>nomeinstituicao</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>titulo</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>autor</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>local</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>ano</nome>
</filho>
101
<nome>identificacao</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>item</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>itemfigura</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>itemtabela</nome>
</pai>
</elemento>
<elemento>
<pai>
<filho>
<mod>+</mod>
<nome>itemfigura</nome>
</filho>
<nome>listafiguras</nome>
</pai>
</elemento>
<elemento>
<pai>
<filho>
<mod>+</mod>
<nome>itemtabela</nome>
</filho>
<nome>listatabelas</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
102
<nome>local</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>logomarca</nome>
</pai>
</elemento>
<elemento>
<pai>
<filho>
<nome>capa</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>contracapa</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>resumo</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>abstract</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>listatabelas</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>listafiguras</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>sumario</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>corpomonografia</nome>
</filho>
103
<delimitador>,</delimitador>
<filho>
<nome>referenciabibliografica</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>anexo</nome>
</filho>
<nome>monografia</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>nomeinstituicao</nome>
</pai>
</elemento>
<elemento>
<pai>
<filho>
<nome>texto</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>citacaodireta</nome>
</filho>
<nome>paragrafo</nome>
</pai>
</elemento>
<elemento>
<pai>
<filho>
<nome>titulo</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>cidade</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>editora</nome>
</filho>
104
<delimitador>,</delimitador>
<filho>
<nome>ano</nome>
</filho>
<nome>referenciabibliografica</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>resumo</nome>
</pai>
</elemento>
<elemento>
<pai>
<filho>
<nome>titulo</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>corpo</nome>
</filho>
<delimitador>,</delim tador>
<filho>
<mod>?</mod>
<nome>subsecao1</nome>
</filho>
<nome>secao</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>subitem</nome>
</pai>
</elemento>
<elemento>
<pai>
<filho>
<nome>titulo</nome>
</filho>
<delimitador>,</delimitador>
105
<filho>
<nome>corpo</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<mod>+</mod>
<nome>subsecao2</nome>
</filho>
<nome>subsecao1</nome>
</pai>
</elemento>
<elemento>
<pai>
<filho>
<nome>titulo</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<nome>corpo</nome>
</filho>
<nome>subsecao2</nome>
</pai>
</elemento>
<elemento>
<pai>
<filho>
<mod>+</mod>
<nome>item</nome>
</filho>
<delimitador>,</delimitador>
<filho>
<mod>+</mod>
<nome>subitem</nome>
</filho>
<nome>sumario</nome>
</pai>
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>texto</nome>
</pai>
106
</elemento>
<elemento>
<pai>
<tipo>PCDATA</tipo>
<nome>titulo</nome>
</pai>
</elemento>
</raiz>
107
DTD resultante : DTD integrada resultante das integração das DTD’s (DTD 1 e DTD 2)
<!ELEMENT abstract ( #PCDATA | textoAbstract | keyword)*>
<!ELEMENT agradecimento ( #PCDATA ) >
<!ELEMENT anexos ( #PCDATA ) >
<!ELEMENT ano ( #PCDATA ) >
<!ELEMENT autor ( #PCDATA ) >
<!ELEMENT capa ( logomarca | instituicao | titulo | autor | local | ano | identificacao )* >
<!ELEMENT capitulo ( lista | paragrafo | secao )+ >
<!ATTLIST capitulo numero
<!ATTLIST capitulo pagina
NMTOKEN #REQUIRED >
NMTOKEN #REQUIRED >
<!ATTLIST capitulo titulo
CDATA #REQUIRED >
<!ELEMENT contracapa (
logomarca | instituicao | titulo | autor | orientador | local | ano |
identificacao | texto )* >
<!ELEMENT corpo ( capitulo | figura | paragrafo )* >
<!ELEMENT figura ( #PCDATA ) >
<!ATTLIST figura numero
<!ATTLIST figura pagina
NMTOKEN #REQUIRED >
NMTOKEN #REQUIRED >
<!ELEMENT figuraCorpo ( #PCDATA ) >
<!ATTLIST figuraCorpo number
<!ATTLIST figuraCorpo pag
NMTOKEN #REQUIRED >
NMTOKEN #REQUIRED >
<!ELEMENT instituicao ( #PCDATA ) >
<!ELEMENT item ( #PCDATA ) >
<!ELEMENT keyword ( #PCDATA ) >
<!ELEMENT lista ( item+ ) >
<!ELEMENT listadefiguras ( figura+ ) >
<!ELEMENT listadetabelas ( tabela+ ) >
<!ELEMENT local ( #PCDATA ) >
<!ELEMENT logomarca ( #PCDATA ) >
<!ELEMENT monografia (
capa | contracapa | agradecimento | sumario | listadefiguras |
listadetabelas | resumo | abstract | corpo | referencias | anexos | listatabelas | listafiguras |
corpomonografia | referenciabibliografica | anexo )* >
<!ELEMENT orientador ( #PCDATA ) >
<!ELEMENT palavraChave ( #PCDATA ) >
<!ELEMENT paragrafo ( #PCDATA | texto | citacaodireta)*>
<!ELEMENT referencias ( #PCDATA ) >
<!ELEMENT resumo ( #PCDATA | textoResumo | palavraChave)*>
<!ELEMENT secao ( figuraCorpo | paragrafo | subsecao | titulo | corpo | subsecao1 )* >
<!ATTLIST secao numero
<!ATTLIST secao pagina
<!ATTLIST secao titulo
NMTOKEN #REQUIRED >
NMTOKEN #REQUIRED >
NMTOKEN #REQUIRED >
108
<!ELEMENT subsecao ( EMPTY ) >
<!ELEMENT sumario ( titulo | item | subitem )* >
<!ATTLIST sumario numero
<!ATTLIST sumario pag
NMTOKEN #REQUIRED >
NMTOKEN #REQUIRED >
<!ELEMENT tabela ( #PCDATA ) >
<!ATTLIST tabela numero
<!ATTLIST tabela pagina
NMTOKEN #REQUIRED >
NMTOKEN #REQUIRED >
<!ELEMENT textoAbstract ( #PCDATA ) >
<!ELEMENT textoResumo ( #PCDATA ) >
<!ELEMENT titulo ( #PCDATA ) >
<!ELEMENT anexo ( #PCDATA ) >
<!ELEMENT cidade ( #PCDATA ) >
<!ELEMENT citacaodireta ( autor , ano ) >
<!ELEMENT corpomonografia ( secao+ ) >
<!ELEMENT editora ( #PCDATA ) >
<!ELEMENT identificacao ( logomarca , nomeinstituicao , titulo , autor , local , ano ) >
<!ELEMENT itemfigura ( #PCDATA ) >
<!ELEMENT itemtabela ( #PCDATA ) >
<!ELEMENT listafiguras ( itemfigura+ ) >
<!ELEMENT listatabelas ( itemtabela+ ) >
<!ELEMENT nomeinstituicao ( #PCDATA ) >
<!ELEMENT referenciabibliografica ( titulo , cidade , editora , ano ) >
<!ELEMENT subitem ( #PCDATA ) >
<!ELEMENT subsecao1 ( titulo , corpo , subsecao2+ ) >
<!ELEMENT subsecao2 ( titulo , corpo ) >
<!ELEMENT texto ( #PCDATA ) >