jorge manuel neves coelho - ipp.ptjcoelho/tese.pdf · trabalhos e pelas reuni~oes semanais. tudo...

Jorge Manuel Neves Coelho

Processamento de XML emProgramacao em Logica

Departamento de Ciencia de ComputadoresFaculdade de Ciencias da Universidade do Porto

2002

Jorge Manuel Neves Coelho

Processamento de XML emProgramacao em Logica

Dissertacao submetida a Faculdade de Ciencias da

Universidade do Porto para a obtencao do grau de

Mestre em Informatica

Departamento de Ciencia de ComputadoresFaculdade de Ciencias da Universidade do Porto

2002

Aos meus pais, avos e a Sonia....

3

Agradecimentos

Comeco por agradecer ao meu orientador, Mario Florido, pelo tema e pelo apoioconstante ao longo deste trabalho. Em particular, pela organizacao do plano detrabalhos e pelas reunioes semanais. Tudo isto contribuiu para que todos os objectivospropostos fossem atingidos dentro do prazo previsto.

Agradeco a Lunjin Lu, por ter respondido prontamente a todas as minhas questoessobre alguns aspectos da inferencia de tipos em programacao em logica.

Agradeco tambem a Sandra Alves, por se disponibilizar a ler a versao final da dis-sertacao, bem como, por todos os esclarecimentos relativos ao LATEX.

Finalmente, um agradecimento especial aos meus pais, avos e a Sonia que sempre meapoiaram e incentivaram e sempre compreenderam todas as minhas ausencias.

5

Conteudo

Indice de Tabelas 11

Indice de Figuras 13

Resumo 15

1 Introducao 17

1.1 Trabalho Relacionado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.2 Resumo da dissertacao . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2 Preliminares 23

2.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.1 Contexto historico . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.2 Utilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.3 Constituicao dum documento XML . . . . . . . . . . . . . . . . 25

2.2.3.1 Elementos . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.3.2 Atributos . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.2.3.3 Entidades . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.2.3.4 Comentarios . . . . . . . . . . . . . . . . . . . . . . . 26

2.2.3.5 Instrucoes de processamento . . . . . . . . . . . . . . . 26

2.2.3.6 Declaracoes . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2.3.7 Declaracao de tipo de documento . . . . . . . . . . . . 27

7

2.2.3.8 Declaracao de XML . . . . . . . . . . . . . . . . . . . 27

2.2.3.9 Declaracoes CDATA . . . . . . . . . . . . . . . . . . . 28

2.2.4 Exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.3 Document Type Definition . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.3.1 Constituicao dum DTD . . . . . . . . . . . . . . . . . . . . . . 30

2.3.1.1 Elementos . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.3.1.2 Atributos . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.3.1.3 Entidades . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.3.1.4 Entidades Internas . . . . . . . . . . . . . . . . . . . . 34

2.3.1.5 Entidades Externas . . . . . . . . . . . . . . . . . . . . 34

2.3.1.6 Entidades de Parametro . . . . . . . . . . . . . . . . . 34

2.3.1.7 Notacoes . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.3.1.8 Exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.4 Linguagens de processamento de XML . . . . . . . . . . . . . . . . . . 36

2.4.1 XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.4.2 XDuce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.4.3 HaXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.5 Programacao em Logica . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3 Traducao de XML para Prolog 45

3.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.2 Traducao dum documento XML para um termo Prolog . . . . . . . . . 45

3.2.1 Elemento simples . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.2.2 Elemento vazio . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.2.3 Elemento com sub elementos . . . . . . . . . . . . . . . . . . . . 47

3.2.4 Elemento opcional que pode repetir-se . . . . . . . . . . . . . . 47

3.2.5 Elemento que pode repetir-se . . . . . . . . . . . . . . . . . . . 48

3.2.6 Elemento opcional . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.2.7 Disjuncao de elementos . . . . . . . . . . . . . . . . . . . . . . . 49

8

3.2.8 Tratamento de atributos . . . . . . . . . . . . . . . . . . . . . . 50

3.3 Uso do DTD na traducao . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.4 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.4.1 Acesso a ficheiro XML . . . . . . . . . . . . . . . . . . . . . . . 53

3.4.2 Acesso a ficheiro de DTD . . . . . . . . . . . . . . . . . . . . . 53

3.4.3 Criacao do termo final . . . . . . . . . . . . . . . . . . . . . . . 55

3.4.3.1 Sub elementos . . . . . . . . . . . . . . . . . . . . . . 56

3.4.3.2 Repeticoes zero ou mais vezes . . . . . . . . . . . . . . 57

3.4.3.3 Repeticoes uma ou mais vezes . . . . . . . . . . . . . . 58

3.4.3.4 Elemento opcional . . . . . . . . . . . . . . . . . . . . 59

3.4.3.5 Lista de opcoes . . . . . . . . . . . . . . . . . . . . . . 60

3.4.3.6 Exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.5 Discussao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4 Inferencia de tipos em Programacao em Logica 63

4.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.2 Tipos Regulares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.3 Operacoes sobre tipos regulares . . . . . . . . . . . . . . . . . . . . . . 65

4.3.1 Tipos vazios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.3.2 Comparacao de tipos regulares . . . . . . . . . . . . . . . . . . . 67

4.3.3 Interseccao de tipos regulares . . . . . . . . . . . . . . . . . . . 74

4.3.4 Unificacao de tipos regulares . . . . . . . . . . . . . . . . . . . . 76

4.4 Inferencia de tipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5 Processamento de XML validado estaticamente 85

5.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.2 Traducao de DTDs para Tipos Regulares . . . . . . . . . . . . . . . . . 85

5.2.1 Elemento simples (conteudo e texto) . . . . . . . . . . . . . . . 86

5.2.2 Elemento vazio . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

9

5.2.3 Elemento com qualquer conteudo . . . . . . . . . . . . . . . . . 87

5.2.4 Elemento com sub elementos . . . . . . . . . . . . . . . . . . . . 88

5.2.5 Elemento opcional que pode repetir-se . . . . . . . . . . . . . . 88

5.2.6 Elemento que pode repetir-se . . . . . . . . . . . . . . . . . . . 89

5.2.7 Disjuncao de elementos . . . . . . . . . . . . . . . . . . . . . . . 89

5.2.8 Elemento opcional . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.2.9 Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.2.10 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.3 Traducao de Prolog para XML . . . . . . . . . . . . . . . . . . . . . . . 95

5.4 Processamento de XML . . . . . . . . . . . . . . . . . . . . . . . . . . 95

6 Conclusao 105

6.1 Trabalho futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6.2 Consideracoes finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Referencias 107

10

Lista de Tabelas

2.1 Entidades predefinidas . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

11

Lista de Figuras

2.1 Arvore de documento XML. . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2 Exemplo de documento XML. . . . . . . . . . . . . . . . . . . . . . . . 28

2.3 Exemplo de DTD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.1 Um DTD para receitas . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.2 Tipos regulares para o DTD das receitas . . . . . . . . . . . . . . . . . 87

13

Resumo

Esta dissertacao descreve a implementacao dum sistema de processamento de docu-mentos XML (eXtensible Markup Language) em Programacao em Logica, que permitea validacao estatica de programas, recorrendo a um sistema de inferencia de tipos eao estabelecimento duma relacao entre os tipos inferidos dos programas e as regras deconstrucao dos documentos XML (os DTDs).

O nosso sistema e composto por quatro partes:

1. Traducao de XML para Prolog.

2. Traducao de DTDs (Document Type Definition) para Tipos Regulares.

3. Inferencia de tipos em Programacao em Logica.

4. Traducao de Prolog para XML.

A primeira parte consiste em traduzir documentos XML para estruturas mais naturaisna Programacao em Logica de forma a serem facilmente manipulados. A segunda parteconsiste em traduzir DTDs para Tipos Regulares. A terceira parte consiste em inferirTipos Regulares para programas Prolog que processam XML. Os Tipos Regularestraduzidos dos DTDs sao usados como declaracoes de tipos para os programas Prolog.A inferencia de tipos determina se o programa esta correcto ou nao face aos tiposdeclarados. A quarta parte consiste em traduzir XML da sua representacao emProgramacao em Logica para a sua representacao natural.

Com este sistema e possıvel construir programas em logica para processar documentosXML. Alem disso, o sistema de inferencia de tipos garante a correccao dos programas,pela utilizacao de tipos traduzidos de DTDs nas declaracoes de tipos dos mesmos.

15

Capıtulo 1

Introducao

A simplicidade de criacao de documentos XML (eXtensible Markup Language) [XML]e a existencia de regras para a especificacao da sua estrutura sob a forma de DTDs(Document Type Definition) [XML], tornaram o XML o formato ideal para o arma-zenamento de diferentes tipos de informacao cuja estrutura se pretende conhecida e oconteudo reutilizavel de diversas formas. As suas caracterısticas simples e a sua inde-pendencia comercial tornaram o seu uso generalizado. O aparecimento de tecnologiasque permitem manipular a informacao contida em documentos XML e constante, saoexemplos o XSLT [XSL], o DOM [DOM] e o SAX [SAX]. Todas estas tecnologiaspermitem a implementacao de programas que a partir dum documento XML originamoutro documento XML com uma nova estrutura. Por exemplo, suponhamos que umaescola tem a informacao sobre os seus alunos num documento XML:

<lista_alunos>

<aluno>

<codigo> aa0001 </codigo>

<nome> Ana Sofia </nome>

<confidencial>

<morada> Porto </morada>

<telefone> 123456789 </telefone>

</confidencial>

</aluno>

...

</lista_alunos>

A escola pretende publicar em diferentes formatos uma lista com os codigos e nomesdos seus alunos. Pretende por isso, criar um novo documento XML a partir do anteriorem que sao omitidas todas as informacoes englobadas pelas anotacoes <confidencial>e </confidencial>. O documento resultante e o seguinte:

<lista_alunos2>

17

18 CAPITULO 1. INTRODUCAO

<aluno>

<codigo> aa0001 </codigo>

<nome> Ana Sofia </nome>

</aluno>

...

</lista_alunos2>

A traducao para este novo documento pode ser feita por programas baseados nastecnologias enunciadas anteriormente. No entanto nada nos garante que o programaimplementado gera um documento correcto face ao DTD que determina a sua cons-trucao.

O principal objectivo deste trabalho e verificar ate que ponto se pode usar a Pro-gramacao em Logica para processar XML e usar sistemas de tipos standard paraProgramacao em Logica para validar estaticamente os programas de processamentode XML face aos DTDs dos ficheiros associados.

O sistema apresentado nesta dissertacao permite a construcao de programas em logicapara o processamento de documentos XML garantindo a sua validade face aos DTDs aeles associados. Por exemplo, para o primeiro documento XML temos o DTD seguinte:

<!ELEMENT lista_alunos1 aluno*>

<!ELEMENT aluno (codigo,nome,confidencial)>

<!ELEMENT codigo (#PCDATA)>

<!ELEMENT nome (#PCDATA)>

<!ELEMENT confidencial (morada,telefone)>

<!ELEMENT morada (#PCDATA)>

<!ELEMENT telefone (#PCDATA)>

Para o segundo documento, o DTD correspondente e:

<!ELEMENT lista_alunos2 aluno*>

<!ELEMENT aluno (codigo,nome)>

<!ELEMENT codigo (#PCDATA)>

19

O nosso sistema associa tipos aos DTDs. Sendo τ 1x o tipo do elemento x do primeiro

DTD, chegamos aos seguintes tipos:

τ 1

lista alunos → {lista alunos(τ 1

aluno∗)}

τ 1

aluno∗ → {nil, .(τ 1

aluno, τ1

aluno∗)}

τ 1

aluno → {aluno(τ 1

codigo, τ1

nome, τ1

confidencial)}

τ 1

codigo → {codigo(string)}

τ 1

nome → {nome(string)}

τ 1

confidencial → {confidencial(τ 1

morada, τ1

telefone)}

τ 1

morada → {morada(string)}

τ 1

telefone → {telefone(string)}

Sendo τ 2x o tipo do elemento x do segundo DTD, chegamos aos seguintes tipos:

τ 2

lista alunos2 → {lista alunos2(τ 2

aluno∗)}

τ 2

aluno∗ → {nil, .(τ 2

aluno, τ2

aluno∗)}

τ 2

aluno → {aluno(τ 2

codigo, τ2

nome}

τ 2

codigo → {codigo(string)}

τ 2

nome → {nome(string)}

O nosso sistema permite traduzir documentos XML para termos Prolog e vice-versa.O primeiro documento XML resulta no seguinte termo:

lista_alunos([

aluno(codigo(’aa0001’),

nome(’Ana Sofia’),

confidencial(morada(’Porto’),

telefone(’123456789’)))

...

])

Podemos criar um programa que processa este termo resultando num outro termoequivalente ao documento XML final que contem somente o codigo e nome de cadaaluno:

process(lista_alunos1(At,LA),lista_alunos2(At,LB)):-

process2(LA,LB).

process2([],[]).

process2([aluno(A1,codigo(AC,C),

nome(AN,N),


confidencial(AC,morada(AM,M),telefone(AT,T)))|RA],

[aluno(A1,codigo(AC,C),nome(AN,N))|RB]):-

process2(RA,RB).

Sendo γip o tipo do argumento i do predicado p e µ o tipo universal (que tipifica

qualquer termo), os tipos inferidos pelo nosso sistema para este programa sao:

γ1

process1 → {lista alunos1(γ1

process2)}

γ2

process1 → {lista alunos2(γ2

process2)}

γ1

process2 → {nil, .(aluno(codigo(µ), nome(µ),

confidencial(morada(µ), telefone(µ))), γ1

process2)}

γ2

process2 → {nil, .(aluno(codigo(µ), nome(µ)), γ2

process2)}

Se os termos que representam o ficheiro XML tiverem na declaracao de tipos respec-tivamente τ 1

lista alunos1 e τ 2

lista alunos2 o sistema conclui em tempo de compilacao que oprograma processa informacao valida. Caso o programa produza um resultado invalidoo nosso sistema detecta o erro e interrompe o processo de compilacao. Por exemplo,se em vez do programa anterior tivessemos o seguinte:

process(lista_alunos1(At,LA),lista_alunos2(At,LB)):-

process2(LA,LB).

process2([],[]).

process2([aluno(A1,codigo(AC,C),

nome(AN,N),

confidencial(AC,morada(AM,M),telefone(AT,T)))|RA],

[aluno(A1,codigo(AC,C),idade(AN,N))|RB]):-

process2(RA,RB).

O sistema detectaria um erro nos dados de saıda, pois nao existe o elemento idade noDTD correspondente.

O nosso sistema esta definido para funcionar com Prolog puro, isto e, clausulasdefinidas sem predicados extra-logicos. Isto deve-se ao facto do algoritmo de inferenciade tipos ter sido implementado para esta classe de programas.

1.1 Trabalho Relacionado

O processamento de XML baseado em Programacao em Logica foi tema dum trabalhorecente de Bry e Shaffert [BS02] onde foi definida uma linguagem de transformacaobaseada neste paradigma. Trabalho anterior sobre a representacao de XML usando

1.2. RESUMO DA DISSERTACAO 21

uma linguagem de termos baseada na Programacao em Logica foi apresentado em[BE00] e [Bol00]. O SWI-Prolog [SWI] inclui um analisador sintactico de XML.A biblioteca PiLLoW [Pil] tem ferramentas de manipulacao de XML e HTML quefacilitam a producao de aplicacoes Prolog para a Web. Estes trabalhos nao usaminferencia de tipos para as linguagens de transformacao. Tanto quanto sabemos, onosso trabalho e o primeiro a usar um sistema de tipos para validacao estatica deprogramas para processar XML no contexto da Programacao em Logica.

O nosso trabalho e inspirado em linguagens funcionais especializadas no domınio doXML tais como o XDuce [HP00] e o HaXML [WR99], que usam sistemas de tipos parafazerem validacao estatica de programas. No XDuce os tipos sao chamados “tipos deexpressoes regulares” e sao uma generalizacao natural dos DTDs. No HaXML osDTDs sao traduzidos para tipos do Haskell e o sistema de tipos da propria linguageme usado na validacao.

O uso de validacao estatica de XML foi tema de varios trabalhos. Milo, Suciu eVianu estudaram o problema da validacao por tipos recorrendo a “tree transducers”em [MSV00]. Uma boa apresentacao do uso de sistemas de tipos para XML pode serencontrada em [Suc01].

Implementamos um modulo de inferencia de tipos baseado no algoritmo de JustinZobel [Zob90] para Tipos Regulares. Os Tipos Regulares sao a linguagem de tiposmais usada na Programacao em Logica [Mis84, Zob87, YS90, FD92, DZ92, Lu01].Existem algoritmos mais eficientes do que o de Zobel como por exemplo o que se podeencontrar em [GdW93] mas cuja implementacao e mais complexa. A simplicidade doalgoritmo de Zobel favorece a sua compreensao e parece-nos a forma mais adequadade introduzir este problema.

Como pre-requisitos e esperado que o leitor esteja familiarizado com o paradigma daProgramacao em Logica [Llo87] e em particular com a linguagem Prolog [SS94].

O codigo fonte deste trabalho bem como exemplos do seu funcionamento encontram-sedisponıveis para download em http://www.dei.isep.ipp.pt/~jcoelho/x-prolog/

download.html.

O trabalho desenvolvido nesta dissertacao foi parcialmente exposto em [CF03].

1.2 Resumo da dissertacao

De seguida descrevemos de forma resumida o conteudo dos proximos capıtulos dadissertacao:

Capıtulo 2: Preliminares: Introducao de conceitos e resultados basicos relevantespara o nosso trabalho. Em particular, sao introduzidos conceitos relacionadoscom a constituicao de documentos XML e DTDs. Sao apresentados alguns


exemplos de linguagens de processamento de XML e finalmente sao apresentadosalguns conceitos basicos sobre a Programacao em Logica.

Capıtulo 3: Traducao de XML para Prolog: Neste capıtulo e explicada de formadetalhada a conversao dum documento XML para um termo Prolog, a suaimplementacao e o uso do SWI-Prolog neste processo.

Capıtulo 4: Inferencia de tipos em Programacao em Logica: Este capıtulo comecacom a introducao de conceitos e definicoes relacionadas com linguagens de ti-pos para Programacao em Logica. Posteriormente sao apresentadas diversasoperacoes sobre estes tipos e finalmente e apresentado um algoritmo de inferenciade tipos baseado nas operacoes anteriores.

Capıtulo 5: Processamento de XML validado estaticamente: Este capıtulo comecacom a apresentacao da relacao que estabelecemos entre os DTDs e os TiposRegulares, de seguida e apresentado duma forma sucinta a traducao de termosProlog para documentos XML e finalmente sao apresentados alguns exemplosdo funcionamento do nosso sistema.

Capıtulo 6: Conclusao: Neste ultimo capıtulo apresentamos algumas conclusoes fi-nais e algumas linhas futuras de investigacao.

Capıtulo 2

Preliminares

2.1 Introducao

Este capıtulo engloba as definicoes e conceitos de base ao trabalho apresentado nestadissertacao. Na seccao 2.2 sao apresentados o XML e as suas particularidades rele-vantes no contexto deste trabalho. Na seccao 2.4 dao-se exemplos de linguagens deprogramacao que inspiraram o trabalho aqui descrito. Na seccao 2.5 sao apresentadasdefinicoes e conceitos associados a Programacao em Logica.

2.2 XML

O XML (eXtensible Markup Language) [XML] e uma metalinguagem desenvolvidapelo W3C (World Wide Web Consortium) [W3C] para descrever linguagens de anotacao.As linguagens de anotacao permitem, a organizacao da informacao num formatoestruturado. Ao nao existirem elementos pre-definidos o XML permite a pessoase organizacoes a criacao da sua propria linguagem para o seu domınio especıfico.Alguns exemplos desta realidade sao, o SMIL [SMI], o MathML [Mat] e o VML[VML]. Os documentos XML sao organizados por anotacoes que funcionam comodelimitadores de informacao. A seguir apresentamos um exemplo dum documentoXML numa linguagem propria para um livro de enderecos:

<livro_enderecos>

<nome> Jorge Coelho </nome>

<paıs> Portugal </paıs>

<email> [email protected] </email>

<telefone>

<fixo> 123456789 </fixo>

<movel> 987654321 </movel>

23

24 CAPITULO 2. PRELIMINARES

</telefone>

<nome> Frank Brown </nome>

<paıs> United Kingdom </paıs>


</livro_enderecos>

Uma caracterıstica importante deste tipo de estrutura e que as anotacoes organizam ainformacao em formato de arvore. Podemos ver o exemplo anterior como uma arvorena figura 2.1.

livro enderecos

nome paıs email telefone nome paıs email

Jorge Coelho . . . . . . . . . . . . . . .

fixo movel

. . . . . .

Figura 2.1: Arvore de documento XML.

2.2.1 Contexto historico

As linguagens de anotacao visam tornar explıcita uma determinada interpretacaodum texto. Por exemplo, os espacos entre as palavras, os paragrafos e a pontuacaosao anotacoes que permitem ao ser humano, com conhecimento duma linguagem,interpretar um texto. Desde ha muito tempo que se recorre a anotacoes para estru-turar documentos. O SGML (Standard Generalized Markup Language) [SGM] e umstandard independente para a representacao de texto electronico usado desde 1986. Acomplexidade do SGML, no entanto, fez com que o seu sucesso fosse em parte reduzido.Foi com base no SGML que foi criado o HTML (Hyper Text Markup Language)[HTM], este tinha como objectivo ser uma linguagem de anotacao para a criacao dedocumentos para serem utilizados na World Wide Web. Apesar de existir um gruporesponsavel [W3C] pela concepcao do HTML e deste ser supostamente um standardindependente, os responsaveis pela criacao de browsers (tais como o Netscape e oMSIE) acabaram por acrescentar elementos incompatıveis com o objectivo de tiraremdaı algum partido comercial. A crescente pressao para a simplificacao do SGML epara o melhoramento do HTML deu origem ao XML.

2.2. XML 25

2.2.2 Utilidade

O XML oferece uma forma independente e poderosa de partilha de informacao. Po-demos pois, dividir em dois os grupos de aplicacao do XML:

Partilha de informacao entre aplicacoes: Troca de informacao entre sistemas debases de dados em que o XML e usado para organizar a informacao de campose tabelas num formato intermedio. Troca de informacao entre aplicacoes naWeb com recurso a RDF [RDF], XML-Data [XML98] ou MCF [MCF]. Troca deinformacao entre aplicacoes de um dado domınio.

Publicacao de documentos: Como o documento XML apenas tem informacao es-truturada e guardada de forma independente da publicacao, podemos, recor-rendo a ferramentas proprias, traduzir o documento para um formato especıficode publicacao num qualquer meio. Recorrendo a um browser capaz de interpretarXML, a uma folha de estilos XSLT [XSL] e a XHTML [HTM] podemos produzirconteudo para a Web. Tambem existe uma serie de aplicacoes comerciais depublicacao que usam XML, por exemplo, Adobe FrameMaker e W3Make. Basi-camente, a ideia e a de termos um formato universal e ferramentas que permitempassar desse formato para outros, sejam eles a Web, um formato impresso, umtelefone celular, ou outro dispositivo qualquer.

2.2.3 Constituicao dum documento XML

Um documento XML e, como ja foi referido, constituıdo por anotacoes que organizama informacao no mesmo. Existem diferentes tipos de anotacoes. Nas proximas subseccoes vamos enunciar as principais e dar exemplos. Esta descricao nao e exaustiva,visa apenas dar uma base para compor documentos XML rapidamente. Na seccao 2.3e num contexto mais preciso, a descricao de algumas anotacoes sera retomada.

2.2.3.1 Elementos

Os Elementos sao o tipo de anotacao mais vulgar num documento. Normalmentetem uma anotacao de inıcio e uma de fim, por exemplo, < nome elemento > <nome elemento >, mas tambem podem ter uma so anotacao, por exemplo, <nomeelemento />. Os seguintes exemplos representam o uso de elementos nome e img :


<img href="/images/img.png" />

O primeiro caso e o dum elemento que engloba informacao entre anotacoes, o segundoe vazio, toda a informacao esta dentro duma unica anotacao.

2.2.3.2 Atributos

Os atributos sao pares (atributo, valor) que ocorrem na anotacao de abertura, porexemplo:

<telefone tipo="pessoal"> 123456789 </telefone>

Os atributos permitem que uma anotacao contenha informacao adicional. No exemploanterior, em que o elemento telefone se destina a “guardar” informacao sobre umnumero de telefone, e guardada tambem informacao extra que identifica esse numerocomo sendo do tipo “pessoal”. Note-se que o valor do atributo esta delimitado por “ epor ”, no caso do seu valor conter algum destes caracteres, podemos delimitar o valordo atributo com ’.

2.2.3.3 Entidades

O conceito subjacente as entidades e o de identificar um conjunto de informacao porum nome. Num documento sempre que queremos usar uma informacao identificadacom uma entidade usamos apenas o seu nome de referencia. Existem varios tiposde entidades, por exemplo, podemos definir uma entidade para referir um texto quee repetido varias vezes no documento (como forma de abreviacao) ou podemos usaruma entidade para referir um objecto externo ao XML, como por exemplo um ficheirobinario. Uma perspectiva mais aprofundada das entidades sera dada na seccao 2.3.1.3.

2.2.3.4 Comentarios

O uso de comentarios pode ajudar a perceber ou relembrar o objectivo do documentoou de certas particularidades. Num documento XML podemos colocar comentariosentre <!- - e - ->. Os comentarios podem conter quaisquer caracteres excepto - -. Umexemplo de comentario e:



2.2.3.5 Instrucoes de processamento

E possıvel incluir num documento XML, anotacoes especiais com o objectivo do seuconteudo ser processado por uma determinada aplicacao. As instrucoes de processa-mento colocam-se entre <? e ?>. A primeira indicacao dentro desta instrucao e onome da aplicacao a qual diz respeito, o resto e a informacao que a aplicacao deveraprocessar. Um exemplo e:

2.2. XML 27

<? xml version="1.0" ?>

Esta instrucao usa a palavra reservada xml para indicar que o documento em questaoe XML versao 1.0.

2.2.3.6 Declaracoes

Um documento XML pode ter uma ou mais declaracoes que poderao ser tratadas porum pre-processador do documento. Estas declaracoes comecam com <! e acabam com>.

2.2.3.7 Declaracao de tipo de documento

E uma declaracao que indica qual o elemento a raiz da arvore que representa aestrutura do documento e um conjunto de regras para a validacao do mesmo. Asregras podem estar num ficheiro, descritas a seguir a indicacao do elemento raız oudivididas pelos dois sıtios. Por exemplo:

<!DOCTYPE livro_enderecos SYSTEM "enderecos.dtd">

Nesta declaracao indica-se que, livro enderecos e o elemento a raiz do documento eenderecos.dtd e o ficheiro de regras de validacao do mesmo. Os conjuntos de regrasDTD (Document Type Definition) [XML] serao abordados na seccao 2.3.

2.2.3.8 Declaracao de XML

Um documento XML pode ter no inıcio uma anotacao especial que o identifica e daalguma informacao sobre o seu conteudo. A informacao possıvel e:

• Versao do XML.

• Conjunto de caracteres usados no documento.

• Indicacao se existe informacao exterior ao documento que deve ser processada.

Por exemplo:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

A versao deste momento e a 1.0. O tipo de codificacao no documento e por omissaoUTF-8 [UTF]. A indicacao standalone indica que nao existe informacao externa aprocessar. No caso de, por exemplo, existir um ficheiro externo de regras de validacaoque deve ser levado em conta na validacao do XML, a indicacao standalone deveriater o valor “no”.

2.2.3.9 Declaracoes CDATA

Sao seccoes do documento em que podemos usar quaisquer caracteres (incluindo osdelimitadores das anotacoes < e >). Por exemplo:

<![CDATA [ (A>B)?A:B]]>

2.2.4 Exemplo

Na figura 2.2 e apresentado um pequeno exemplo dum documento XML que ilustraalgumas das possibilidades indicadas anteriormente.

<? xml version="1.0" encoding="UTF-8" standalone="no"?>

<!DOCTYPE livro_enderecos SYSTEM "enderecos.dtd" [

<!ENTITY assinatura "Jorge Manuel Neves Coelho" >

<!ENTITY foto1 SYSTEM "/images/jorge.png">

<!ENTITY foto2 SYSTEM "/images/frank.png">

]>

<livro_enderecos>

<nome> &assinatura; </nome>

<paıs cidade="Porto"> Portugal </paıs>


<telefone>

<fixo> 123456789 </fixo>

<movel> 987654321 </movel>

</telefone>

<foto ficheiro = "foto1" visualiza="Png"/>


<paıs cidade="London"> United Kingdom </paıs>


<foto ficheiro = "foto2" visualiza="Png"/>

</livro_enderecos>



Figura 2.2: Exemplo de documento XML.

A primeira linha indica a versao, tipo de codificacao e que existem referencias externasque devem ser processadas juntamente com o documento. Na segunda linha e indicadoo elemento de raiz bem como um ficheiro de validacao (DTD). Na terceira linha saodefinidas entidades (note-se, dentro da declaracao DOCTYPE), a primeira permitea abreviacao dum nome completo para uma so palavra e as seguintes referem-se a

2.3. DOCUMENT TYPE DEFINITION 29

objectos binarios. Nas linhas seguintes encontramos diversos elementos, com e sematributos, vazios ou contendo informacao. Na ultima linha incluımos um comentario.

2.3 Document Type Definition

Um DTD (Document Type Definition) [XML] e uma gramatica que especifica a es-trutura dum documento XML. No DTD estao descritas as anotacoes permitidas numdado documento bem como a forma de relacionamento entre elas. Existe uma seriede standards sob a forma de DTDs para manipulacao de informacao especıfica dumdeterminado domınio, por exemplo, SMIL, MathML e XHTML. Os DTDs sao umafuncionalidade opcional mas muito poderosa. Com o DTD podemos, por exemplo,verificar se um dado elemento e possıvel numa dada posicao do documento XMLou se os atributos sao ou nao validos. As declaracoes do DTD podem ser feitas noinıcio dum documento XML ou mais vulgarmente num ficheiro a parte ou mesmo nosdois sıtios. Devemos ter em atencao que as declaracoes feitas dentro do documentosao processadas primeiro e assumem por isso precedencia em relacao as declaracoesexternas. Declaracoes feitas dentro do documento XML, sao precedidas da palavrareservada DOCTYPE, por exemplo:

<!DOCTYPE livro_enderecos [



<!ENTITY ...>

...

]>

Para usar um DTD declarado externamente usamos apenas a referencia ao nome doseu ficheiro, no exemplo seguinte, enderecos.dtd.

<!DOCTYPE livro_enderecos SYSTEM "enderecos.dtd">

A palavra reservada SYSTEM e usada quando temos o ficheiro externo acessıvellocalmente, no entanto, podemos usar a palavra reservada PUBLIC para referir umDTD acessıvel pela Internet, por exemplo:

<!DOCTYPE livro_enderecos PUBLIC "-//Jorge Coelho//Enderecos//PT"

"http://www.meudominio.com/config/enderecos.dtd">

No exemplo anterior o texto a seguir a palavra PUBLIC comeca por ’-’ (significa queo DTD nao e ISO nem esta registado), segue-se o nome do autor, uma indicacao dotipo de informacao a que se refere e a lıngua utilizada (ISO 639). As informacoes saoseparadas por //.

Por fim, para usar uma mistura de declaracoes internas e externas, misturamos osexemplos anteriores:

<!DOCTYPE livro_enderecos SYSTEM "enderecos.dtd" [



<!ENTITY ...>

...

]>

2.3.1 Constituicao dum DTD

Num DTD podemos declarar, elementos, atributos, entidades e notacoes, todas asdeclaracoes aparecem entre <! e >. Faremos agora uma descricao das declaracoespossıveis.

2.3.1.1 Elementos

Podemos definir um elemento usando a palavra reservada ELEMENT, os argumentosusados sao, o nome do elemento (so pode comecar por uma letra, ou : e pode conteradicionalmente dıgitos e os caracteres “.” e “-”) e uma declaracao do conteudo domesmo. Os conteudo possıvel sao:

• ANY, o conteudo pode ser qualquer (outros elementos validos ou texto).

• EMPTY, o conteudo e vazio.

• #PCDATA, (Parsable Character Data), o conteudo e texto.

• Um ou mais sub elementos, agrupados por vırgulas (ou num caso particular por“|”) e entre parentesis. Este tipo de conteudo permite que o elemento tenha umamistura de sub elementos e texto. A ordem dos sub elementos e a ordem pelaqual devem aparecer no documento XML.

Exemplos de elementos validos sao:

<!ELEMENT a ANY>

<!ELEMENT b EMPTY>

<!ELEMENT c (a,b)>

Um exemplo dum documento XML valido face a estas declaracoes podera ser:

<c>

<a> texto exemplo </a>



</c>

Um exemplo dum documento invalido podera ser:

<c>

<a> texto exemplo </a>

<a> outro texto exemplo </a>



</c>

A nao validade resulta da declaracao nao permitir que o elemento c englobe oselementos (a,a,b), mas somente (a,b).

Quando um elemento contem algum sub elemento ou alguns sub elementos e possivel-mente texto, e possıvel declarar caracterısticas mais precisas. Podemos pois declararse o elemento e obrigatorio, opcional, se pode repetir-se, se e opcional e pode repetir-seou se e um de uma lista de sub elementos. Esta indicacao e dada pela colocacao deum dos seguintes caracteres a seguir ao nome dos sub elementos:

* o elemento pode aparecer zero ou mais vezes.

+ o elemento deve aparecer pelo menos uma vez podendo repetir-se.

? o elemento e opcional.

| se colocado entre elementos significa que um deles pode aparecer mas nao mais doque um.

Analisemos o seguinte exemplo de DTD:

<!ELEMENT a (b*,c?)+>

<!ELEMENT b (#PCDATA | d)>

<!ELEMENT c (#PCDATA)>

<!ELEMENT d (#PCDATA)>

Neste exemplo, o elemento a devera ter zero ou mais elementos do tipo b e opcional-mente um elemento do tipo c. O grupo de elementos definidos dentro do elementoa podera aparecer uma ou mais vezes. O elemento b e constituıdo por um texto (nocaso dum grupo de elementos em que pode existir texto, a indicacao #PCDATA temque aparecer obrigatoriamente no inıcio e o grupo de elementos tera que ser separadopor |, ou seja, do tipo escolha) ou pelo elemento d. O seguinte exemplo e XML validoface a este DTD:

<a>

 texto 

 mais texto 

 <d> ainda mais texto </d>

<c> tanto texto</c>

<c> ainda bem que acabou (o texto) </c>

</a>

2.3.1.2 Atributos

Podemos definir atributos usando a palavra reservada ATTLIST. A declaracao destese feita separadamente do elemento a que pertencem. Para por exemplo, declararmosatributos para um elemento nome, usamos:

<!ATTLIST nome atributo1 tipo_atributo1

atributo2 tipo_atributo2

... ... >

Numa declaracao ATTLIST, podemos definir todos os atributos dum elemento, o seutipo e um valor predefinido para o mesmo. O nome dum atributo tem as mesmasrestricoes que os dos nomes dos elementos, tal como foi visto na seccao 2.3.1.1. Ostipos possıveis sao:

CDATA O atributo pode ter qualquer texto. Por exemplo:

<cliente nome="Pato Donald">

NMTOKEN O atributo pode ter uma so palavra. As restricoes sao as mesmas queexistem relativamente aos nomes dos elementos, vistas na seccao 2.3.1.1, exceptopara o primeiro dos caracteres.

NMTOKENS Varios NMTOKEN separados por um espaco em branco. Por exem-plo:

<mapa coordenadas="1 5 78 65">

ID Identificacao dum elemento de forma unica. Todos os valores ID dum documentodevem ser unicos.

IDREF Deve ser o valor de um atributo ID do documento.

IDREFS Varios valores de IDs definidos no documento separadas por espacos.

ENTITY O atributo e uma entidade. Por exemplo:

<!ELEMENT foto EMPTY>

<!ATTLIST foto ficheiro ENTITY ...>

...

<foto ficheiro="foto1" />

ENTITIES Multiplas entidades separadas por espacos em branco.

Lista de nomes Um ou mais nomes, separados por “|”. O atributo deve ter umdestes valores. Por exemplo:

...

<!ATTLIST pessoa ...

sexo (feminino|masculino)

... >

...

<pessoa sexo="feminino">

...

Notacao Um atributo pode estar associado a um valor definido numa notacao, asnotacoes serao abordadas na seccao 2.3.1.7.

Como ja foi referido anteriormente, os atributos podem ter valores predefinidos. Alemda indicacao dum valor para um atributo podemos indicar se o valor deve ser dadoobrigatoriamente ou se e opcional. As opcoes sao as seguintes:

#REQUIRED O atributo deve existir todas as vezes que o elemento ao qual per-tence e usado.

#IMPLIED Este atributo pode nao aparecer.

#FIXED O atributo tem um valor fixo que e dado a seguir a esta palavra reservada.

Valor O atributo tem o valor indicado entre aspas.

Estas opcoes sao dadas no ultimo parametro da declaracao duma lista de atributos.O seguinte exemplo ilustra o uso destas opcoes:

<!ATTLIST cliente codigo ID #REQUIRED

nome CDATA #IMPLIED

sexo (fem|masc) "fem"

comentario CDATA #FIXED "comentario fixo">

Neste exemplo estamos a declarar que o elemento cliente tem os atributos, codigo quee unico e obrigatorio, nome que e uma string qualquer e e opcional, sexo que podetomar um de dois valores (fem ou masc) e por omissao tem o valor “fem” e comentarioque e fixo e tem o valor “comentario fixo”.

Nome da entidade Texto resultante< <> >

& &' ’" ”

Tabela 2.1: Entidades predefinidas

2.3.1.3 Entidades

As entidades sao declaradas com a palavra reservada ENTITY. Existem tres tipos deentidades, internas, externas e de parametro. De seguida vamos ver as diferencas entrecada uma destas.

2.3.1.4 Entidades Internas

As entidades internas consistem em blocos de texto referenciados por um nome e quepodem ser usados como uma abreviacao num documento. Por exemplo,

<! ENTITY assinatura "Jorge Manuel Neves Coelho" >

Sempre que no meu documento quiser inserir o nome “Jorge Manuel Neves Coelho”,posso pura e simplesmente introduzir &assinatura;. O XML tem predefinido cincoentidades internas como pode ser visto na tabela 2.1.

2.3.1.5 Entidades Externas

As entidades externas associam um nome a um ficheiro externo. O ficheiro pode ser detexto ou binario. A referencia a um ficheiro externo e precedida pela palavra reservadaSYSTEM ou PUBLIC, por exemplo:

<!ENTITY ent01 SYSTEM "/ents/ent01.xml">


2.3.1.6 Entidades de Parametro

As entidades de parametro sao usadas exclusivamente nos DTDs e servem comoabreviatura de declaracoes. Por exemplo, se estivermos a usar as duas seguintesdeclaracoes num DTD:

<!ELEMENT a (c|d|e)>

<!ELEMENT b (c|d|e)>

Podemos criar a entidade:

<!ENTITY % ab "(c|d|e)">

As declaracoes dos elementos passariam a:

<!ELEMENT a %ab;>

<!ELEMENT b %ab;>

Podemos assim ter entidades definidas externamente que sao aplicaveis a varios DTDsabreviando a sua concepcao.

2.3.1.7 Notacoes

As notacoes, identificadas pela palavra reservada NOTATION, identificam formatosexternos ao XML. No seguinte exemplo e ilustrado o uso de notacoes.

...

<!ELEMENT filme EMPTY>

<!ATTLIST filme ficheiro ENTITY #REQUIRED

visualiza NOTATION (Mov|Mpg) #REQUIRED>

<!ENTITY amelie SYSTEM "movies/amelie.mov" NDATA Mov>

<!NOTATION Mov SYSTEM "movieplayer">

...

<filme ficheiro = "&amelie;" visualiza = "Mov"/>

A notacao e usada como forma de indicar o programa usado para ler o ficheiro“amelie.mov”. Esta indicacao e feita usando o identificador da notacao no atributovisualiza do elemento filme.

2.3.1.8 Exemplo

O DTD apresentado na figura 2.3 valida documentos como o que e apresentado nafigura 2.2.

Neste momento, as entidades foto1 e foto2, definidas dentro do documento XMLapresentado na figura 2.2 podem ser substituıdas por uma versao mais completa emque e indicado o programa que deve ser usado para visualizar imagens Png :

<!ELEMENT livro_enderecos (nome,pais,email,telefone?,foto)*>


<!ELEMENT paıs (#PCDATA)>

<!ATTLIST paıs cidade CDATA #REQUIRED>

<!ELEMENT email (#PCDATA)>

<!ELEMENT telefone (fixo?,movel)>

<!ELEMENT fixo (#PCDATA)>

<!ELEMENT movel (#PCDATA)>

<!ELEMENT foto EMPTY>

<!ATTLIST foto ficheiro ENTITY #REQUIRED

visualiza NOTATION (Png) #REQUIRED>

<!NOTATION Png SYSTEM "picview">

Figura 2.3: Exemplo de DTD.

<!ENTITY foto1 SYSTEM "/images/jorge.png" NDATA Png>

<!ENTITY foto2 SYSTEM "/images/frank.png" NDATA Png>

Obviamente o atributo NDATA faz com que deixe de ser necessaria a existencia doatributo visualiza do elemento foto.

2.4 Linguagens de processamento de XML

Para processar informacao de documentos XML existem diversas linguagens e biblio-tecas. Existem duas APIs (Application Programmers Interface), o DOM (DocumentObject Model) [DOM] e o SAX (Simple API for XML) [SAX], e a linguagem XSLT[XSL] que sao, provavelmente, as abordagens mais populares para o processamentode XML. O DOM e uma abordagem em “arvore”. O documento e visto como umaarvore em memoria e o acesso aos seus elementos um problema de manipulacao de umaestrutura deste tipo. Esta abordagem tem no entanto alguns problemas, como sendoa quantidade de memoria consumida por grandes documentos e a perda de eficienciaconsequente. No caso do SAX a abordagem e “guiada por eventos”, o documentoe processado sequencialmente, sendo os seus elementos associados a determinadoseventos com determinadas consequencias. Deixamos neste caso de ter sempre acessoao documento inteiro. O XSLT e uma linguagem que permite transformar um docu-mento XML noutro documento XML, HTML ou outro qualquer desde que organizadonuma estrutura hierarquica. Estas abordagens nao satisfazem todas as necessidadesrelacionadas com o processamento de XML. Se quisermos por exemplo, traduzir umdocumento XML para um segundo documento XML com a garantia que o resultado evalido face a um determinado DTD para o primeiro documento e outro determinadoDTD para o segundo documento, nao conseguimos. Para resolver esta falha, estao aaparecer linguagens de processamento proprias para o domınio do XML que englobamesquemas de validacao, por exemplo, o XDuce [HP00] e o HaXml [WR99]. De seguida

2.4. LINGUAGENS DE PROCESSAMENTO DE XML 37

vamos ver com mais pormenor, o XSLT como um exemplo das primeiras abordagensaqui descritas e o XDuce e o HaXml como exemplos destas novas linguagens comcaracterısticas inovadoras.

2.4.1 XSLT

O XSLT (eXtensible Stylesheet Language Transformations) e parte da XSL (eXtensibleStylesheet Language) [XSL]. A XSL tem como objectivo, possibilitar a publicacao dedocumentos XML, pela utilizacao de estilos que fornecem, por exemplo, tamanhos deletra distintos e alinhamentos para textos. A transformacao entre um documento XMLe o seu formato de publicacao e feito pelo XSLT. Apesar do seu objectivo original,o XSLT serve para traduzir um documento XML numa outra qualquer estruturahierarquica. O seu funcionamento faz-se por intermedio duma folha de estilos queestipula a traducao a fazer sobre cada uma das anotacoes. O resultado e um documentofinal segundo as regras estipuladas na folha de estilos usada na sua criacao. De seguidavamos ver um exemplo de conversao dum documento XML para HTML, recorrendoao XSLT. Dado o seguinte documento XML:

<?xml version="1.0"?>

<titulo> Registos de clientes </titulo>

<registos>

<cliente id="MM01"> Rato Mickey </cliente>

<cliente id="PD01"> Pato Donald </cliente>

</registos>

Podemos converte-lo no seguinte documento HTML:

<html>

<head><title>Registos de clientes</title></head>

<body>

<table>

<tr>

<td>Rato Mickey</td>

<td>MM01</td>

</tr>

<tr>

<td>Pato Donald</td>

<td>PD01</td>

</tr>

</table>

</body>

</html>

Para isso podemos usar o seguinte XSLT:

<xsl:stylesheet version = "1.0"

xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

xmlns="http://www.w3.org/TR/REC-html40">

<xsl:output method="html" indent="yes" encoding="UTF-8"/>

<html>

<head><title><xsl:text> Registos de clientes</xsl:text>

</title></head>

<body>

<table>

<xsl:apply-templates/>

</table>

</body>

</html>

<xsl:template match="cliente">

<tr>

<td>

<xsl:value-of select="."/>

</td>

<td>

<xsl:apply-templates select="@id"/>

</td>

</tr>

</xsl:template>

<xsl:template match="@id">

<xsl:value-of select="."/>

</xsl:template>

</xsl:stylesheet>

Todo o documento XSLT deve comecar pela indicacao xsl:stylesheet, seguida da versaoe do domınio do Namespace correspondente (Namespaces sao basicamente domıniosde anotacoes, identificados por um determinado endereco. O seu estudo nao seraabordado neste trabalho, mais informacoes podem ser encontradas em [Nam]). Apartir daı todas as instrucoes XSLT devem ser precedidas por xsl:. Quando forencontrado o elemento cliente no XML o XSLT devera escrever uma nova linha dumatabela com duas celulas, uma com o texto contido entre anotacoes cliente e outra como valor do atributo id do mesmo em negrito. Para identificar os elementos aos quaisse deve aplicar determinado template usa-se um caminho tal qual e definido em XPath.O estudo do XPath nao sera abordado neste trabalho, mais informacoes podem serencontradas em [XPa]. Em linhas gerais, o processador XSL analisa o documentoXML e verifica se existem templates a aplicar aos seus elementos, no caso de existirem

2.4. LINGUAGENS DE PROCESSAMENTO DE XML 39

o seu conteudo e avaliado e um novo resultado e produzido. Note-se que as anotacoesHTML nao necessitam de um identificador para o namespace (como acontece com oxsl:) porque, neste caso, esta indicado que o HTML e o namespace por omissao (pelanao designacao dum identificador).

2.4.2 XDuce

O XDuce [HP00] e uma linguagem funcional especializada no processamento de do-cumentos XML. Esta linguagem tem um sistema de tipos baseado em expressoesregulares. Estes tipos podem ser vistos como uma generalizacao dos DTDs. Vejamosentao, um exemplo que relaciona um DTD com os tipos do XDuce. O DTD:

<!ELEMENT livro_enderecos (nome,morada,telefone?)*>

<!ELEMENT nome #PCDATA>

<!ELEMENT morada #PCDATA>

<!ELEMENT telefone #PCDATA)>

Corresponde as seguintes definicoes de tipos no XDuce:

type Livro_enderecos = livro_enderecos[(Nome,Morada,Telefone?)*]

type Nome = nome[String]

type Morada = morada[String]

type Telefone = telefone[String]

Um exemplo dum programa em XDuce para processar a informacao de documentosvalidos face ao DTD anterior e:

fun listaTel : (Nome,Morada,Telefone?)* -> (Nome,Telefone)* =

nome[n:String], morada[m:String], telefone[t:String],

rest(Nome,Morada,Telefone?)*

-> nome[n], telefone[t], listaTel(rest)

| nome[n:String], morada[m:String], rest(Nome,Morada,Telefone?)*

-> listaTel(rest)

| ()

-> ()

Este programa transforma um documento do tipo do livro de enderecos especificadopelo DTD presente no inıcio desta seccao, num documento em que somente constamnome e telefone. Na primeira regra a funcao anterior retorna um nome, numero detelefone e recursivamente a mesma funcao aplicada ao resto do documento. A segundaregra aplica-se quando o numero de telefone nao esta presente, retornando apenas oresultado da recursao. A terceira regra aplica-se a um documento vazio (ou que chegouao fim) e retorna vazio.


2.4.3 HaXML

O HaXml [WR99] e construıdo sobre a linguagem Haskell (um livro de referencia destalinguagem e [Tho99]). O HaXml permite manipular uma arvore dum documento XMLbem como traduzir DTDs para tipos do Haskell de forma a que esta informacao possaser usada para validar o resultado dos programas de processamento de XML. Duasdas principais vantagens do HaXml sao, permitir usar codigo Haskell puro e permitira traducao de DTDs para tipos do Haskell de forma a usar o sistema de tipos dalinguagem para validar o documento resultante do processamento.

2.5 Programacao em Logica

A Programacao em Logica e um paradigma centrado em dois princıpios: o uso da logicapara representar o conhecimento e o uso dum sistema de inferencia para manipularo conhecimento. A linguagem mais popular neste paradigma e o Prolog [SS94].Em Programacao em Logica usa-se um subconjunto da logica de primeira ordem,as Clausulas de Horn para representar o conhecimento e a Resolucao SLD comometodo de inferencia (ver [Llo87] ou [Hog90] para um estudo mais aprofundado desteparadigma). De seguida serao introduzidas definicoes e conceitos basicos usados aolongo desta dissertacao.

A linguagem da logica de predicados de primeira ordem e definida por:

Definicao 2.5.1 Assumimos um alfabeto de:

• Sımbolos constantes (a,b,c,. . . ).

• Sımbolos funcionais (f,g,h,. . . ).

• Sımbolos para variaveis (X, Y, Z, . . . ).

• Sımbolos para predicados (pai, gosta, possui,. . . ).

• Sımbolos para quantificadores (∀,∃).

• Sımbolos para conectivas (¬,∨,∧,←,↔).

• Sımbolos de pontuacao (“(”,“)” e “,”).

Definicao 2.5.2 Define-se termo da seguinte forma:

• Uma variavel e um termo.

• Uma constante e um termo.

• Sendo f um sımbolo funcional e t1, ..., tn termos, entao f(t1, ..., tn) e um termo.

2.5. PROGRAMACAO EM LOGICA 41

Exemplo 2.5.1 Os tres exemplos seguintes sao termos:

• a

• X

• f(a,f(b,h(c))).

Definicao 2.5.3 Define-se formula da seguinte forma:

• Seja p um sımbolo para predicado e t1, ..., tn termos, entao p(t1, ..., tn) e umaformula. A este tipo de formula chamamos formula atomica.

• Sejam W e V formulas, entao (¬W ), (W ∨V ), (W ∧V ), (W ← V ) e (W ↔ V )sao formulas.

• Seja W uma formula e x uma variavel, entao (∀xW ) e (∃xW ) sao formulas.

Exemplo 2.5.2 Os tres exemplos seguintes sao formulas atomicas:

• pai(X,Y).

• gosta(Y,ana).

• possui(ze,automovel).

Definicao 2.5.4 Dada uma formula W, designaremos por negacao de W a expressao¬(W).

Definicao 2.5.5 Chama-se literal a uma formula atomica ou a sua negacao.

Exemplo 2.5.3 Sao literais as seguintes formulas:

• pai(ze,joao).

• ¬possui(ze,barco).

Designamos por literal positivo, uma formula atomica e por literal negativo a suanegacao.

Definicao 2.5.6 Chama-se termo fechado a um termo sem variaveis e formula

fechada a uma formula sem variaveis.

Exemplo 2.5.4 Sao termos fechados, a e b e sao formulas fechadas, pai(joao,ze) egosta(ze,ana).


Chamaremos daqui para a frente aos sımbolos para variaveis e aos sımbolos paraconstantes simplesmente variaveis e constantes e as formulas atomicas chamaremospredicados.

Definicao 2.5.7 Seja V uma formula com variaveis X1, . . . , Xn. e sejam t1, . . . , tntermos. Uma instancia de V e obtida pela substituicao de todas as ocorrencias de Xi

em V por ti. Usaremos V {Xi/ti, . . . , Xn/tn} para denotar esta substituicao.

Definicao 2.5.8 Dizemos que uma formula esta na forma clausal (ou forma nor-mal conjuntiva) se e so se for constituıda por um conjunto de quantificadores univer-sais, seguidos duma conjuncao de formulas sem quantificadores em que cada uma dasformulas e uma disjuncao de um ou mais literais.

Exemplo 2.5.5 A seguinte formula esta na forma clausal:

∀X∀Y ∀Z((pai(joao, ze)) ∧ (pai(ze, ana)) ∧ (pai(ze, rui))∧(descendente(X, Y ) ∨ ¬pai(X, Y ))∧(descendente(X, Y ) ∨ ¬(pai(X, Z) ∧ descendente(Z, Y )))

A partir de agora escrevemos as formulas na forma clausal como conjuntos de formulasimplicitamente ligadas por conjuncoes:

Exemplo 2.5.6 O seguinte conjunto de formulas e equivalente a formula apresentadano exemplo anterior:

{ pai(joao, ze), pai(ze, ana), pai(ze, rui),∀X∀Y (descendente(X, Y ) ∨ ¬pai(X, Y )),∀X∀Y ∀Z(descendente(X, Y ) ∨ ¬(pai(X, Z) ∧ descendente(Z, Y )))}

Em Programacao em Logica e usual denotar formulas da forma:

∀x1,...,xn(A1 ∨ · · · ∨ Ak ∨ ¬B1 ∨ · · · ∨ ¬Bn)

Pela formula equivalente:

A1 ∨ · · · ∨ Ak ← B1 ∧ · · · ∧ Bn

A notacao usual e:A1, . . . , Ak ← B1, . . . , Bn

As vırgulas no antecedente B1, . . . , Bn denotam a conjuncao e no consequente A1, . . . , Ak

a disjuncao.

Exemplo 2.5.7 De seguida apresentamos o conjunto de formulas anterior na notacaousual na Programacao em Logica:

pai(joao, ze).pai(ze, ana).

2.5. PROGRAMACAO EM LOGICA 43

pai(ze, rui).descendente(X, Y )← pai(X, Y ).descendente(X, Y )← pai(X, Z), descendente(Z, Y ).

A cada uma das linhas do exemplo anterior chamamos clausula. As clausulas saoclassificadas em funcao do numero de literais positivos e negativos:

Clausula definida: Contem exactamente um literal positivo e zero ou mais lite-rais negativos. Um exemplo duma clausula definida e, descendente(X, Y ) ←pai(X, Y ). Note-se que esta clausula e equivalente a descendente(X, Y ) ∨ ¬pai(X, Y ), daı a referencia ao literal negativo.

Clausula unitaria positiva: Sem literais negativos. Por exemplo, pai(ze, rui).

Clausula unitaria negativa: Clausula negativa com exactamente um literal. Porexemplo, ¬pai(ze, rui).

Clausula negativa: Com zero ou mais literais negativos e nenhum literal positivo.Por exemplo, ¬pai(ze, rui).

Clausula indefinida: Clausula com pelo menos dois literais positivos. Por exemplo,pai(ze, rui) ∨ pai(rui, ze).

Definicao 2.5.9 Definimos um Programa Definido como sendo um conjunto finitode clausulas definidas.

Todas as clausulas com excepcao das indefinidas sao tambem designadas Clausulas deHorn. Em Programacao em Logica, as clausulas negativas sao tambem designadas porgolos ou questoes, as clausulas positivas sao designadas por factos e todas as outrasexcepto as indefinidas sao designadas por regras.

A estrategia de demonstracao mais usada em Programacao em Logica e a ResolucaoSLD. Nesta dissertacao assumimos que o leitor conhece o paradigma da Programacaoem Logica. Por isso nao vamos apresentar detalhes sobre o sistema de execucao deprogramas. Um estudo detalhado sobre o assunto pode ser encontrado em [Llo87].

Capıtulo 3

Traducao de XML para Prolog

3.1 Introducao

Para disponibilizar a informacao proveniente dum documento XML num programaProlog, fazemos uma conversao do seu formato original para um formato mais na-tural nesta linguagem. Neste capıtulo vamos analisar o processo de transformacaoentre o documento XML e a correspondente representacao no Prolog. Na seccao 3.2explicamos a traducao dum documento XML para um termo Prolog. Na seccao 3.3abordamos o papel dos DTDs na traducao. Na seccao 3.4 e explicada a implementacao.

3.2 Traducao dum documento XML para um termo

Prolog

Como ja foi visto, um documento XML tem uma estrutura em arvore e o Prologtem uma excelente capacidade para lidar com dados estruturados em arvore. A nossasolucao para o problema da traducao consiste em traduzir um documento XML numtermo fechado. Por exemplo, o documento:

<livro_enderecos>


<paıs> Portugal </paıs>


<telefone>

<fixo> 123456789 </fixo>

<movel> 987654321 </movel>

</telefone>


<paıs> United Kingdom </paıs>

45

46 CAPITULO 3. TRADUCAO DE XML PARA PROLOG


</livro_enderecos>

Traduzido para um termo Prolog resulta em:

livro_enderecos(

nome("Jorge Coelho"),

paıs("Portugal"),

email("[email protected]"),

telefone(

fixo("123456789"),

movel("987654321")),

nome("Frank Brown"),

paıs("United Kingdom"),

email("[email protected]"))

Basicamente a ideia e a de usar o nome dos elementos como sımbolos funcionais deestruturas que podem englobar outras estruturas representando outros elementos outexto.

Num exemplo mais complexo do que o apresentado anteriormente poderiam existirelementos opcionais, que poderiam repetir-se, que seriam um de uma lista ou queteriam atributos. A estrutura do nosso termo Prolog esta directamente relacionadacom os tipos dos elementos que representa, por isso, utilizamos as declaracoes doDTD no processo de construcao do termo. Outras caracterısticas do documentoque se podem inferir da analise do DTD, tais como, a ordem dos elementos ou aobrigatoriedade dum elemento estar presente, sao verificadas para garantir que o termoconstruıdo representa um documento valido. De seguida vamos ver em pormenor comoe que traduzimos elementos de cada um dos casos possıveis e o papel do DTD naconstrucao do termo Prolog.

3.2.1 Elemento simples

Sendo um elemento simples, aquele cujo conteudo e apenas texto, um exemplo poderaser aquele que e declarado pela seguinte linha dum DTD:

<!ELEMENT b #PCDATA>

Dado o seguinte documento XML valido para o DTD anterior:

Texto do elemento b

O termo resultante e:

b("Texto do elemento b")

3.2. TRADUCAO DUM DOCUMENTO XML PARA UM TERMO PROLOG 47

3.2.2 Elemento vazio

Quando se trata dum elemento cujo conteudo e vazio, o termo resultante e constituıdoapenas pelo nome do elemento. Dado o seguinte DTD:

<!ELEMENT b empty>

Dado o seguinte documento XML valido face ao DTD anterior



A traducao deste elemento resulta no termo:

b

3.2.3 Elemento com sub elementos

Quando um elemento contem sub elementos, estes sao integrados como sub termos dotermo gerado a partir do elemento principal. Dado o seguinte DTD:

<!ELEMENT a (b,c)>

<!ELEMENT b (#PCDATA)>


Dado o seguinte documento XML:

<a>

 Conteudo do elemento b

<c> Conteudo do elemento c</c>

</a>

O termo resultante sera:

a(

b("Conteudo do elemento b"),

c("Conteudo do elemento b"))

3.2.4 Elemento opcional que pode repetir-se

Quando encontramos um elemento que e opcional e que pode repetir-se, assinalado noDTD com um * a solucao e criar uma lista, que pode incluir n elementos, com n ≥ 0,do tipo assinalado. Por exemplo, dado o seguinte DTD:

<!ELEMENT a (b)*>


Dado o seguinte documento XML valido face ao DTD anterior:

<a>

 Primeiro vez que b aparece 

 Segunda vez que b aparece 

 Terceira vez que b aparece 

</a>


a(

[b("Primeiro vez que b aparece"),

b("Segunda vez que b aparece"),

b("Terceira vez que b aparece")])

Dado o seguinte documento valido face ao DTD anterior:

<a>

</a>


a([])

3.2.5 Elemento que pode repetir-se

Este caso e semelhante ao anterior, a unica diferenca e que a lista tem que conter pelomenos um elemento deste tipo, mais a frente veremos como impomos esta condicao.No caso do seguinte DTD:

<!ELEMENT a (b+,c)>



Dado o seguinte XML:

<a>

Conteudo de b

<c>Conteudo de c</c>

</a>

3.2. TRADUCAO DUM DOCUMENTO XML PARA UM TERMO PROLOG 49

O resultado produzido e:

a(

[b("Conteudo de b")],

c("Conteudo de c"))

3.2.6 Elemento opcional

Os elementos opcionais, assinalados com ?, podem ou nao estar presentes num docu-mento, dado o DTD:

<!ELEMENT a (b?,c)>



Tanto o documento:

<a>

<c> Conteudo de c </c>

</a>

Como o documento:

<a>

 Conteudo de b 


</a>

Sao validos e originam os seguintes termos respectivamente:

a(

b("Conteudo de b"),

c("Conteudo de c"))

a(

c("Conteudo de c"))

3.2.7 Disjuncao de elementos

No caso de estarmos a traduzir um elemento de entre varios duma lista de opcoes,verificamos se o elemento no documento e um dos da lista declarada no DTD econstruımos o respectivo termo. Dado o seguinte DTD:

<!ELEMENT a (b|c)>



Tanto o documento:

<a>

 Texto 

</a>

Como o documento:

<a>

<c> Outro texto </c>

</a>

Sao validos e originam os seguintes termos respectivamente:

a(b("Texto"))

a(c("Outro texto"))

O nosso programa de traducao garante que o termo Prolog que representa um do-cumento XML pode ser gerado pela gramatica definida pelo DTD do respectivodocumento.

3.2.8 Tratamento de atributos

Por uma questao de simplicidade, nas seccoes anteriores, nao abordamos o uso deatributos e o destino a dar aos mesmos no processo de traducao. No entanto, todaa nossa implementacao foi feita tendo em conta a presenca de atributos. A solucaoencontrada para a introducao dos mesmos no termo Prolog passa por, adicionar umalista a cada elemento com informacao relativa aos seus atributos. A lista pode ser vazia,no caso de nao existirem quaisquer atributos ou pode conter dados relativos a estes soba forma dum termo fechado, com sımbolo funcional attribute e contendo o nome doatributo e o respectivo valor, na forma, attribute(nome do atributo,valor do atributo).Se ao exemplo da seccao 3.2 acrescentarmos o atributo cidade ao elemento paıs, talque:

...


<paıs cidade="Porto"> Portugal </paıs>

3.3. USO DO DTD NA TRADUCAO 51

...


<paıs cidade="London"> United Kingdom </paıs>

...


livro_enderecos([],

nome([],"Jorge Coelho"),

paıs([attribute("cidade","Porto")],"Portugal"),

email([],"[email protected]"),

telefone([],

fixo([],"123456789"),

movel([],"987654321")),

nome([],"Frank Brown"),

paıs([attribute("cidade","London")],"United Kingdom"),

email([],"[email protected]"))

3.3 Uso do DTD na traducao

A traducao do documento XML para o termo Prolog e, na nossa implementacao ecomo ja foi referido, guiada pelo DTD. Esta caracterıstica permite que o termo geradotraduza XML valido, evitando erros. Por exemplo, dado o seguinte DTD:

<!ELEMENT a (b+,c)>




<a>




</a>

O termo nao sera construıdo uma vez que o elemento b, tera que aparecer pelo menosuma vez no documento XML. O mesmo acontece no documento XML seguinte:

<a>


 Conteudo de b 

</a>

Desta vez os elementos necessarios estao presentes, mas pela ordem errada. O pesodo DTD na traducao, pode mesmo originar dois termos distintos, para um mesmodocumento XML, se validados por regras diferentes. Por exemplo, dado o seguintedocumento:

<a>

 Conteudo do primeiro b

 Conteudo do segundo b 

</a>

Fazendo a traducao segundo o DTD:

<!ELEMENT a (b,b)>


Resulta no termo:

a([],

b([],"Conteudo do primeiro b"),

b([],"Conteudo do segundo b"))

Enquanto que o mesmo documento validado pelo DTD:

<!ELEMENT a b*>


Origina um termo diferente:

a([],

[b([],"Conteudo do primeiro b"),

b([],"Conteudo do segundo b")])

Tambem os atributos sao validados em funcao do que esta declarado no DTD. No en-tanto, a validacao dos atributos refere-se apenas a um teste da existencia da declaracaodo mesmo no DTD.

3.4 Implementacao

A implementacao foi feita no SWI-Prolog [SWI]. Este compilador de Prolog, tem umabiblioteca para processamento de ficheiros SGML, XML e DTD, que usamos comoforma de facilitar o acesso aos ficheiros que pretendemos processar.

3.4. IMPLEMENTACAO 53

3.4.1 Acesso a ficheiro XML

Para aceder ao conteudo dum ficheiro XML usamos o predicado load xml file/2, forne-cido pelo SWI-Prolog. Este predicado le o ficheiro XML dado no primeiro argumento eretorna uma lista com os seus elementos no segundo argumento. Os elementos estao ar-mazenados numa estrutura da forma element(NomeElemento,ListaAtributos,Conteudo)em que NomeElemento e o nome do elemento em causa, ListaAtributos e a listados respectivos atributos e Conteudo e o seu conteudo. Por exemplo, o documentoXML apresentado na figura 2.2, depois de interpretado com recurso ao predicadoload xml file/2 resulta na seguinte estrutura:

[element(livro_enderecos,[],

[element(nome, [], [’Jorge Manuel Neves Coelho’]),

element(paıs, [cidade=Porto], [’Portugal’]),

element(email, [], [’[email protected]’]),

element(telefone, [],

[element(fixo, [], [’123456789’]),

element(movel, [], [’987654321’])]),

element(foto, [ficheiro=foto1, visualiza=Png], []),

element(nome, [], [’Frank Brown’]),

element(paıs, [cidade=London], [’United Kingdom’]),

element(email, [], [’[email protected]’]),

element(foto, [ficheiro=foto2, visualiza=Png], [])]

3.4.2 Acesso a ficheiro de DTD

Para acedermos a informacao contida no ficheiro de DTD, usamos essencialmente trespredicados fornecidos pelo SWI-Prolog:

• new dtd(Doctype,DTD): Cria um novo DTD identificado com Doctype e retornaa referencia DTD que pode ser usada posteriormente noutros predicados demanipulacao do DTD.

• load dtd(DTD,Ficheiro): Define o DTD lendo o conteudo em Ficheiro. A variavelDTD e a devolvida pelo predicado new dtd/2.

• dtd property(DTD,Propriedade): Dado um DTD devolvido por new dtd/2 edefinido em load dtd/2, este predicado acede a diferentes propriedades do DTD,tais como:

– Lista de elementos.

– Propriedades dum elemento.

– Atributos dum elemento.


– Propriedades dum atributo.

– Entidades.

– Notacoes.

Se por exemplo, guardarmos o DTD da figura 2.3 no ficheiro enderecos.dtd e de seguidafizermos a seguinte questao ao SWI-Prolog:

?-new_dtd(livro_enderecos,DTD),load_dtd(DTD,’enderecos.dtd’),

dtd_property(DTD,X).

As propriedades a que temos acesso, obtidas como valores da variavel X sao (separadaspor ;):

doctype(livro_enderecos) ;

elements([movel, fixo, foto, telefone, email, paıs, nome,

livro_enderecos]);

entities([]) ;

notations([png]) ;

element(movel, omit(false, false), ’#pcdata’) ;

element(fixo, omit(false, false), ’#pcdata’) ;

element(foto, omit(false, false), empty) ;

element(telefone, omit(false, false), (?fixo, movel)) ;

element(email, omit(false, false), ’#pcdata’) ;

element(pais, omit(false, false), ’#pcdata’) ;

element(nome, omit(false, false), ’#pcdata’) ;

element(livro_enderecos, omit(false, false), *((nome, paıs, email,

?telefone, foto))) ;

attributes(movel, []) ;

attributes(fixo, []) ;

attributes(foto, [ficheiro, visualiza]) ;

attributes(telefone, []) ;

attributes(email, []) ;

attributes(paıs, [cidade]) ;

attributes(nome, []) ;

attributes(livro_enderecos, []) ;

attribute(foto, ficheiro, entity, required) ;

attribute(foto, visualiza, notation, required) ;

attribute(paıs, cidade, cdata, required) ;

notation(png, [system(picview)]) .

Temos portanto uma forma de acesso aos elementos, suas propriedades e atributos.Note-se que os sımbolos, *, + e ? funcionam como sımbolos funcionais de estruturasque englobam os elementos por eles abrangidos na definicao do DTD. Note-se tambemque o elemento omit(. . . ) da estrutura element esta relacionado exclusivamente como SGML e por isso e ignorado.


3.4.3 Criacao do termo final

Nesta seccao vamos analisar as partes mais relevantes do programa de traducao do do-cumento XML para o termo Prolog. Definimos o predicado processa(Xml,Dtd,TermoF)que dado um documento XML na representacao do SWI-Prolog no argumento Xml eum DTD devidamente definido em Dtd retorna o termo TermoF na nossa notacao.De seguida apresentamos o predicado processa/3:

processa([element(X,L2,L3)],DTD,TermoF):-

processa_aux(X,L2,L3,DTD,Lista,NAtr),

TermoF=[X,NAtr|Lista].

O predicado processa aux/7 usa os predicados fornecidos pelo SWI-Prolog para criaruma lista que vai originar o termo final na nossa notacao. Os seus argumentos sao,o nome do elemento, a lista de atributos, a lista de conteudo e o DTD e o seuresultado as listas do conteudo e dos atributos dum elemento. Este predicado e usadoconstantemente nos outros predicados do programa e esta descrito a seguir:

processa_aux(X,L2,L3,DTD,Lista,NAtr):-

dtd_property(DTD,element(X,_,Tipo)),

processa_tipo(Tipo,DTD,L3,Lista),

dtd_property(DTD,attributes(X,ListaAtr)),

valida_atributos(L2,ListaAtr,NAtr),

Resumidamente, o nosso processamento o que faz e, depois de obter o corpo doelemento, na variavel Tipo segundo a definicao do DTD (ver o exemplo da seccao 3.4.2),usar o predicado processa tipo/4 para, juntamente com a estrutura do documentoXML dada pelo SWI-Prolog, obter uma lista final representando o corpo do elementona nossa notacao. O predicado processa tipo/4 esta definido da seguinte forma:

processa_tipo(empty,_,[],[]):-!.

processa_tipo(’#pcdata’,_,L,L):- !.

processa_tipo(Sub,DTD,L,LSub):- processa_composto(Sub,DTD,L,_,LSub).

O primeiro argumento, representa o conteudo do elemento e pode ser empty, #pcdataou pode ter sub elementos, o segundo argumento e o DTD, o terceiro a lista como conteudo na notacao original e o quarto fica com o resultado. O predicado va-lida atributos/3 e usado para verificar a validade dos atributos e construir a respectivalista na nossa notacao, a sua implementacao e simples e auto explicativa:

valida_atributos([],_,[]).

valida_atributos([X=Y|L1],L2,[Termo|RTermos]):-

member(X,L2),

Termo = attribute(X,Y),

valida_atributos(L1,L2,RTermos).

Vejamos agora um exemplo que usa esta primeira parte da implementacao. Dado oseguinte DTD:

<!ELEMENT a (#PCDATA)>

<!ATTLIST a b CDATA REQUIRED>

Dado o seguinte XML valido face ao DTD anterior:

<a b="Conteudo do atributo b"> Conteudo do elemento a </a>

O SWI-Prolog gera a seguinte estrutura:

[element(a,[b=’Conteudo do atributo b’],[’Conteudo do elemento a’])]

O predicado processa/3 aplicado a este documento XML e ao respectivo DTD originao termo:

a([attribute(b,’Conteudo do atributo b’)],’Conteudo do elemento a’).

O processamento torna-se mais complexo quando se trata de elementos com subelementos. O predicado processa composto/5 encarrega-se destes casos. Os seus argu-mentos sao, o tuplo com os sub elementos, o DTD, a lista de elementos representativado documento XML dada pelo SWI-Prolog, o resto da lista de elementos a processar eo termo com o resultado final. Note-se que o tuplo de sub elementos dado no primeiroargumento de processa composto/5 e exactamente aquele que esta no DTD (podeobservar-se esta particularidade no exemplo da seccao 3.4.2) tendo por isso, a ordemcorrecta dos elementos e que devera ser respeitada no documento XML. Por exemplose na variavel Tipo estiver o seguinte tuplo, (a,b+,c*,d?), os elementos que aparecemno terceiro argumento de processa composto/5 e que representam o documento XMLterao que ter um elemento a, seguido de um ou mais elementos b, seguido de zeroou mais elementos c e opcionalmente dum elemento d. A nossa ideia e processarsimultaneamente as definicoes do DTD e o documento XML de forma a que esteultimo seja validado. De seguida vamos ver como o predicado processa composto/5trata cada um dos casos.

3.4.3.1 Sub elementos

O processamento de sub elementos e feito pelo predicado processa composto/5 daseguinte forma:

processa_composto((X,Y),DTD,LElem,RElem,LTerm):-!,

processa_composto((X),DTD,LElem,RE,LTerm1),


processa_composto((Y),DTD,RE,RElem,LTerm2),

append(LTerm1,LTerm2,LTerm).

processa_composto((X),DTD,[element(X,Atr,T)|RElem],RElem,[Termo]):-

processa_aux(X,Atr,T,DTD,LT,NAtr),!,

Termo = [X,NAtr|LT].

Quando e encontrado um tuplo com mais do que um sub elemento, a solucao eprocessar recursivamente cada um dos sub elementos. No caso de ser encontradoapenas um elemento o seu processamento e identico ao que ja foi visto na seccao 3.4.3.

3.4.3.2 Repeticoes zero ou mais vezes

O processamento de elementos opcionais que podem repetir-se e feito pelas seguintesclausulas:

processa_composto(*(_),_,[],[],[]):-!.

processa_composto(*((X,_)),_,[element(X1,Atr,T)|RElem],

[element(X1,Atr,T)|RElem],[]):-

X\=X1,!.

processa_composto(*((X,Y)),DTD,[element(X1,Atr,T)|RElem],

RElemF,[LTermo]):-!,

processa_composto((X,Y),DTD,[element(X1,Atr,T)|RElem],

RElemT,Termo1),

processa_composto_rep((X,Y),DTD,RElemT,RElemF,Termo2),

append(Termo1,Termo2,LTermo).

processa_composto(*(X),_,[element(X1,Atr,T)|RElem],


X\=X1,!.

processa_composto(*(X),DTD,[element(X,Atr,T)|RElem],

RElemF,[TermoF]):-


processa_composto_rep(X,DTD,RElem,RElemF,Termo2),

append([X,NAtr],LT,TF),

Termo1=..FT,

append([Termo1],Termo2,TermoF).

A primeira clausula refere-se ao processamento dum tuplo de repeticoes no fim dodocumento XML. A segunda clausula aplica-se quando o tuplo de repeticoes nao foi


encontrado. A terceira clausula refere-se a um tuplo que existe no documento, nestecaso a primeira ocorrencia e processada normalmente e as seguintes sao processadaspelo predicado processa composto rep/5. As quarta e quinta clausulas referem-se aoprocessamento de tuplos com um unico elemento deste tipo. A razao para a utilizacaodo novo predicado processa composto rep/5 e o facto de estarmos a usar um processosequencial de processamento do documento. Se no DTD encontramos (a,c*,d), vamosprocessar o a, e depois o c, no entanto neste caso o documento XML pode ter varioselementos c. Como estamos a processar o documento XML ao mesmo tempo que asdeclaracoes do DTD, antes de passar para o d temos que processar todas as ocorrenciasde c. O predicado processa composto rep/5 e analogo a processa composto/5 exceptopelo facto de fixar o elemento com repeticoes. Cada ocorrencia do mesmo e tratadacomo um elemento simples pelo predicado processa composto/5.

processa_composto_rep(_,_,[],[],[]):-!.

processa_composto_rep((X,_),[element(X1,_,_)|_],_,_,[]):-

X\=X1.

processa_composto_rep((X,Y),DTD,[element(X,Atr,T)|RElem],

RElemF,LTermo):-!,

processa_composto((X,Y),DTD,[element(X,Atr,T)|RElem],

RElem1,LTermo1),

processa_composto_rep((X,Y),DTD,RElem1,RElemF,LTermo2),

append(LTermo1,LTermo2,LTermo).

processa_composto_rep(X,_,[element(X1,Atr,T)|RElem],


X\=X1,!.

processa_composto_rep(X,DTD,[element(X,Atr,T)|RElem],

RElemF,TermoF):-

processa_aux(X,Atr,T,DTD,LT,NAtr),


Termo1=..[X,NAtr,LT],


3.4.3.3 Repeticoes uma ou mais vezes

Estas clausulas sao identicas as apresentadas para os elementos opcionais e que podemrepetir-se (*) , sendo que a principal diferenca reside no facto de ser obrigatoria apresenca de pelo menos um elemento deste tipo, o que se reflecte num menor numerode clausulas:

processa_composto(+((X,Y)),DTD,[element(X1,Atr,T)|RElem],


RElemF,[LTermo]):-

processa_composto((X,Y),DTD,[element(X1,Atr,T)|RElem],

RElemT,Termo1),

processa_composto_rep((X,Y),DTD,RElemT,RElemF,Termo2),

append(Termo1,Termo2,LTermo).

processa_composto(+(X),DTD,[element(X,Atr,T)|RElem],RElemF,[TermoF]):-



append([X,NAtr],LT,TF),

Termo1=..FT,


3.4.3.4 Elemento opcional

O processamento de elementos opcionais e feito pelas seguintes clausulas:

processa_composto(?(_),_,[],[],[]).

processa_composto(?(X,_),_,[element(X1,Atr,T)|RElem],


X\=X1,!.

processa_composto(?((X,Y)),DTD,[element(X,Atr,T)|RElem],

RElem2,Termo):-!,

processa_composto((X,Y),DTD,[element(X,Atr,T)|RElem],

RElem2,Termo).

processa_composto(?(X),_,[element(X1,Atr,T)|RElem],


X\=X1,!.

processa_composto(?(X),DTD,[element(X,Atr,T)|RElem],

RElem,[Termo]):-


append([X,NAtr],LT,LFinal),

Termo=..LFinal.

A primeira clausula trata do caso em que encontramos um elemento opcional comoultimo elemento e que nao esta presente no documento XML. A segunda clausularefere-se a um elemento opcional nao presente no documento, a terceira a um grupode elementos opcionais presentes no documento, a quarta e quintas clausulas referem-se ao tratamento de opcionais com um so elemento.

3.4.3.5 Lista de opcoes

Quando encontramos um elemento do documento XML que devera estar numa listade opcoes, recorremos ao predicado processa composto ou/5 que percorre a lista ateencontrar o elemento em causa:

processa_composto((X|Y),DTD,El,REl,LTer):-

processa_composto_ou((X|Y),DTD,El,REl,LTer).

processa_composto_ou((X),DTD,[element(X,Atr,T)],[],[Termo]):-



Termo=..LFinal.

processa_composto_ou((X|_),DTD,[element(X,Atr,T)],[],[Termo]):-



Termo=..LFinal.

processa_composto_ou((X|Y),DTD,[element(X1,Atr,T)|RElem],

RElemF,LTermo):-

X\=X1,

processa_composto_ou((Y),DTD,[element(X1,Atr,T)|RElem],

RElemF,LTermo).

3.4.3.6 Exemplo

Dado o seguinte DTD:

<!ELEMENT a (b,c*,d?)>

<!ELEMENT b (e+,f)>



<!ELEMENT e (#PCDATA)>

<!ELEMENT f (g|h)>

<!ELEMENT g (#PCDATA)>

<!ELEMENT h (#PCDATA)>

<!ATTLIST h i CDATA #REQUIRED>


<a>

<e> Conteudo do primeiro e </e>

<e> Conteudo do segundo e </e>

<f>

<h i="Atributo i"> Conteudo de h </h>

</f>



<d> Conteudo de d </d>

</a>

O SWI-Prolog fornece-nos a seguinte estrutura sobre o documento:

element(a,[]

[element(b, [],

[element(e, [], [ Conteudo primeiro e ]),

element(e, [], [ Conteudo segundo e ]),

element(f, [],

[element(h, [i=Atributo i],

[ Conteudo de h ])])]),

element(d, [], [ Conteudo de d ])]

Fornece-nos tambem as seguintes informacoes sobre o DTD:

elements([h, g, f, e, d, c, b, a]) ;

entities([]) ;

notations([]) ;

element(h, omit(false, false), ’#pcdata’) ;

element(g, omit(false, false), ’#pcdata’) ;

element(f, omit(false, false), (g|h)) ;

element(e, omit(false, false), ’#pcdata’) ;

element(d, omit(false, false), ’#pcdata’) ;

element(c, omit(false, false), ’#pcdata’) ;

element(b, omit(false, false), (+e, f)) ;

element(a, omit(false, false), (b, *(c), ?d)) ;

attributes(h, [i]) ;

attributes(g, []) ;

attributes(f, []) ;

attributes(e, []) ;

attributes(d, []) ;

attributes(c, []) ;

attributes(b, []) ;

attributes(a, []) ;

attribute(h, i, cdata, required) ;

O resultado do processamento feito pelo nosso programa e:


a([],

b([],

[e([], ’ Conteudo primeiro e ’),

e([], ’ Conteudo segundo e ’)],

f([],

h([attribute(i, ’Atributo i’)],

’ Conteudo de h ’))),

d([], ’ Conteudo de d ’)) ;

3.5 Discussao

A representacao de documentos XML descrita neste capıtulo foi previamente apre-sentada (embora com pequenas diferencas) num trabalho de Boley em [Bol00]. Estarepresentacao tem como principais vantagens:

1. Adequacao para o problema da inferencia de tipos.

2. O termo e uma estrutura natural e comum para o programador habituado aoparadigma da programacao em logica.

As principais desvantagens desta representacao sao:

1. Nao estar tao proximo do documento XML como por exemplo a representacaousada no SWI-Prolog.

2. Dar origem a termos Prolog muito grandes exigindo passar toda a arvore dodocumento XML para a memoria (esta desvantagem tambem existe por exemplono DOM).

Dado que um dos principais objectivos deste trabalho e o uso da inferencia de tipospara validacao optamos por esta representacao.

Capıtulo 4

Inferencia de tipos emProgramacao em Logica

4.1 Introducao

Os sistemas de tipos usados nas linguagens de programacao funcionam como uma pecacentral no processo de validacao e correccao de programas. Para atingirmos o objectivoproposto no nosso trabalho, implementamos um sistema de inferencia de tipos paraProgramacao em Logica que nos permite a validacao estatica de programas. O sistemaque implementamos foi descrito pela primeira vez por Dart e Zobel em [Zob90] e baseia-se na utilizacao de Tipos Regulares [DZ92]. Na seccao 4.2 apresentamos definicoesrelacionadas com os Tipos Regulares. Na seccao 4.3 descrevemos e implementamosoperacoes sobre Tipos Regulares necessarias a inferencia de tipos. Por ultimo, naseccao 4.4 descrevemos o processo de inferencia de tipos. A implementacao nao etotalmente identica a proposta por Dart e Zobel, foram feitas algumas modificacoesde forma a superar os problemas da proposta original descritos por Lu em [Lu01].

4.2 Tipos Regulares

Nesta seccao apresentamos definicoes relacionadas com os Tipos Regulares tal qualforam previamente apresentadas por Dart e Zobel em [DZ92].

Definicao 4.2.1 Assumindo que temos conjuntos infinitos de sımbolos para constan-tes, variaveis e tipos. Definimos termo de tipos da seguinte forma:

1. Um sımbolo para representar uma constante e um termo de tipos (a, b, c, . . . ).

2. Uma variavel e um termo de tipos (x, y, . . . ).

63

64 CAPITULO 4. INFERENCIA DE TIPOS EM PROGRAMACAO EM LOGICA

3. Um sımbolo para representar um tipo e um termo de tipos (α, β, . . . ).

4. Seja f um sımbolo funcional e τ1, . . . , τn termos de tipos entao f(τ1, . . . , τn) eum termo de tipos.

A partir deste ponto passaremos a chamar aos sımbolos para representar constantesapenas constantes.

Exemplo 4.2.1 Seja a uma constante, α um sımbolo e x uma variavel. As expressoesa, α, x e f(a, α, x) sao termos de tipos. Se a expressao nao tem variaveis e um termo

de tipos puro, por exemplo, a, α e f(α, g(β), c) sao termos de tipos puros.

Definicao 4.2.2 Uma regra de tipos e uma expressao da forma α → Υ onde α eum sımbolo representando um tipo e Υ e um conjunto de termos de tipos puros.Passaremos a usar T para representar um conjunto de regras de tipos.

Conjuntos de regras de tipos sao gramaticas de termos regulares [Tha73]. A partirdeste momento passaremos a chamar aos conjuntos de regras de tipos apenas conjuntosde regras. O conjunto vazio sera identificado com ∅.

Exemplo 4.2.2 Sejam α e β sımbolos para tipos, α→ {a, b} e β →{nil, tree(β, α, β)}sao regras de tipos.

Definicao 4.2.3 Um sımbolo para um tipo α e definido por um conjunto de regras Tse existir uma regra α→ Υ ∈ T .

Daqui para a frente assumimos os seguintes pontos:

1. As constantes dividem-se em subconjuntos nao vazios a que chamaremos tiposbase. Alguns exemplos destes tipos sao, string, int e number.

2. Assumimos a existencia de µ, para representar o tipo universal e φ para repre-sentar o tipo vazio.

3. Os sımbolos para tipos que podem ocorrer num conjunto de regras T sao, µ, φ,um tipo base ou um sımbolo para tipo que esteja definido em T . Cada sımbolopara tipo definido em T , tem exactamente uma regra que o define em T .

Definicao 4.2.4 Os Tipos Regulares sao definidos pela classe de tipos que podemser descritos por conjuntos de regras (ou alternativamente por gramaticas de termosregulares). O conjunto de tipos gerados por uma regra e o conjunto de termos regularesdefinidos por essa regra.

Exemplo 4.2.3 Seja T um conjunto de regras tal que

T = {α→ {a}, β → {nil, f(α, β)}}

O conjunto de tipos regulares gerado por α e {a} e por β e {nil, f(a, nil), f(a, f(a, nil)),. . . }.

4.3. OPERACOES SOBRE TIPOS REGULARES 65

4.3 Operacoes sobre tipos regulares

Nesta seccao vamos descrever operacoes sobre tipos regulares que vao ser usadasposteriormente no algoritmo de inferencia de tipos. Nos programas que serao descritosnas proximas seccoes usamos any para descrever o tipo universal µ e none paradescrever o tipo vazio φ. Usamos estruturas da forma type (X, Y ) para descreversımbolos para tipos em que o X e o nome do predicado a que se refere (ou 0 quandonao se refere a um predicado) e Y representa um ındice e usamos estruturas da formavar (X) para descrever as variaveis dos programas em analise, em que X representaum ındice. Os tuplos e conjuntos a que faremos referencia sao representados por listas.

4.3.1 Tipos vazios

Uma das funcionalidades de que vamos necessitar no processo de inferencia de tiposconsiste em testar se um determinado termo de tipos puro, definido por um conjuntode regras e ou nao vazio. Ou seja, se este termo de tipos puro origina ou nao umconjunto vazio de termos.

Exemplo 4.3.1 Seja T um conjunto de regras tal que

T = {α→ {φ}, β → {f(a, β, c)}, γ → {γ}, τ → {φ, τ, nil, .(a, τ)}}

O conjunto de tipos gerado por α, β e γ e vazio. O conjunto de tipos gerado por τnao e vazio e consiste em {nil, .(a, nil), .(a, a, nil), . . . }.

Implementamos o predicado vazio(X,T) que dado um termo de tipos puro X e umconjunto de regras T que o definem, retorna verdade se X e vazio e falso caso contrario.A sua implementacao e a seguinte:

vazio(X,T):-

vazio2(X,[],T).

O predicado vazio2(X,E,T), usa os mesmos argumentos de vazio/2 e uma lista auxiliarE que e usada para guardar os elementos que ja foram testados e que permite reco-nhecer tipos como o caso de γ no exemplo 4.3.1. A sua implementacao esta descritaa seguir:

vazio2(none,_,_).

vazio2(X,E,_):-membro(X,E).

vazio2(type_(P,X),E,TRules):-

membro(type_(P,X)--->L,TRules),


todos_vazios(L,[type_(P,X)|E],TRules).

vazio2(F,E,TRules):-

F=..[_|RLX],

arg_vazios(RLX,E,TRules).

A primeira clausula destina-se aos casos em que o tipo e φ. A segunda clausula trata oscasos em que o tipo recorre da sua definicao, nao originando qualquer tipo. A terceiraclausula destina-se ao tratamento de tipos identificados por um sımbolo para tipos,α definido pela regra α → TR, neste caso usamos o predicado todos vazios/3. Esteverifica se todos os elementos no conjunto TR sao vazios. A quarta clausula destina-seaos casos em que o termo tipo puro e da forma f(τ1, ..., τn) com n ≥ 0, neste ultimocaso basta verificar se um dos argumentos de f e vazio. Esta tarefa e realizada porarg vazios/3.

O predicado todos vazios(L,E,T) verifica se os tipos da lista L sao vazios face aoconjunto de regras T . A lista E tem os sımbolos para tipos que ja foram testados. Asua implementacao e a seguinte:

todos_vazios([],_,_).

todos_vazios([Y|RL],E,TRules):-

vazio2(Y,E,TRules),

todos_vazios(RL,E,TRules).

O predicado arg vazios(X,E,T) verifica se pelo menos um dos elementos da lista X evazio face ao conjunto de regras T , no caso de nao encontrar algum, falha. O conjuntoE armazena os sımbolos tipo que ja foram testados. A sua implementacao e a seguinte:

arg_vazios([A|_],E,TRules):-

vazio2(A,E,TRules),!.

arg_vazios([_|RA],E,TRules):-

arg_vazios(RA,E,TRules).

Exemplo 4.3.2 Dado o conjunto de regras

T = {α→ {β, f(γ)}, β → {g(γ)}, γ → {α}, κ→ {f(a, κ)}, θ → {f(a, b, c)}}

Usamos P1 ⇒ P2 para exemplificar a chamada do predicado P2 a partir do predicadoP1.

• vazio(θ,T ) ⇒ vazio2({a,b,c},{},T) ⇒ Falso.


• vazio(κ,T) ⇒ vazio2(κ,{},T ) ⇒ todos vazios({f(a, κ)},{κ},T )} ⇒vazio2(f(a, κ),{κ},T ) ⇒ arg vazios({a,κ},{κ},T ) ⇒ arg vazios({κ},{κ},T ) ⇒vazio2(κ,{κ},T ) ⇒ Verdade

• vazio(α,T ) ⇒ vazio2(α,{},T ) ⇒ todos vazios({β,f(γ)},{α},T )

– vazio2(β,{α},T ) ⇒ todos vazios({g(γ)},{α,β},T ) ⇒vazio2(g(γ),{α,β},T ) ⇒ arg vazios({γ},{α,β},T ) ⇒vazio2(γ,{α,β},T ) ⇒ todos vazios({α},{α,β,γ},T ) ⇒Verdade

– todos vazios(f(γ),{α},T ) ⇒ vazio2(f(γ),{α},T ) ⇒arg vazios({γ},{α},T ) ⇒ vazio2(γ,{α},T ) ⇒todos vazios({α},{α},T ) ⇒ vazio2(α,{α},T ) ⇒Verdade

4.3.2 Comparacao de tipos regulares

Para implementarmos o sistema de inferencia de tipos vamos necessitar duma formade saber se um tipo esta incluıdo noutro. Dados dois tipos α e β definidos por umconjunto de regras T , o objectivo e determinar se o conjunto de termos gerados porα esta contido no conjunto de termos gerados por β. Para isso, basta verificarmos setodos os elementos do primeiro conjunto de termos existem no segundo conjunto determos.

Sem perda de generalidade podemos afirmar que os elementos pertencentes ao corpoduma regra de tipos sao, µ, um sımbolo para um tipo ou uma estrutura do tipof(t1, . . . , tn) com n ≥ 0. Vamos comecar por estudar o terceiro caso, que vai acabarpor englobar os dois primeiros.

A questao de sabermos se um termo como f(t1, . . . , tn) ocorre num conjunto de termosΦ pode ser reduzida a sabermos se pertence ao subconjunto Φ′ de Φ cujos elementostem sımbolo funcional f . Temos depois o problema de saber se o tuplo de termos(t1, . . . , tn) esta contido no conjunto de tuplos (w1, . . . , wn) tal que f(w1, . . . , wn)pertence a Φ′. Mas (t1, . . . , tn) pode dar origem a muitos termos diferentes uma vezque elementos deste podem ser sımbolos para tipos e nesse caso geram novos termosa partir das suas regras. A ideia e, comecar por substituir t1, no caso de ser umsımbolo para tipos, por todos os elementos da sua regra de tipo, criando um ou maistuplos novos e comparar esses tuplos com os elementos de Φ′ cujo primeiro elementocoincida. Depois de reunir os elementos em Φ′ compatıveis, substitui-se o Φ′ poreste novo conjunto de termos e passa-se ao elemento seguinte do tuplo. O processocontinua ate nao existirem mais elementos no tuplo, o que confirma a inclusao inicial,ou ate encontrar-se uma situacao em que se verifique que nao existe nenhum elementode Φ′ compatıvel com o elemento em causa, neste caso sabemos que o termo inicialnao forma um conjunto de tipos que seja subconjunto de Φ. Considere-se o seguinteexemplo:


Dado o conjunto de regras:

T = {α→ {f(β, θ)}, β → {a, b}, γ → {f(a, c), f(b, c), f(c, e), g(d, e)}, θ→ {c}}

Segundo a estrategia que usamos, o problema de saber se α esta contido em γ podeser visto como saber se f(β, θ) esta contido em Φ = {f(a, c), f(b, c), f(c, e), g(d, e)}.Podemos pois seleccionar os elementos de Φ com o functor f , sendo estes {f(a, c),f(b, c), f(c, e)}. Agora podemos extrair o functor f e o problema passa a ser saber se(β,θ) esta contido em {(a, c),(b, c),(c, e)}. Como o primeiro elemento do primeiro tuploe o sımbolo para tipos β, devemos expandir este tuplo de forma a, usando o conjuntode regras para β, obter os termos possıveis. Temos agora o problema de saber se{(a,θ),(b,θ)} esta contido em {(a, c),(b, c),(c, e)}. Podemos pois seleccionar apenas ostuplos cujo primeiro elemento e a ou b. O problema passa a ser o de determinar se(θ) esta contido em {(c)}, expandindo (θ) obtemos (c), que esta contido no conjunto{(c)}. Temos pois um resultado verdadeiro para a questao inicial.

No nosso programa definimos tres predicados de base a esta parte do trabalho, expan-dir/3, que a partir dum tuplo devolve o conjunto de termos expandidos, seleccionar/3,que a partir dum elemento dum tuplo e dum conjunto de tuplos previamente expan-didos devolve o conjunto de tuplos compatıveis e extrair/3 que nos permite extrairsımbolos funcionais de estruturas.

Dado o tuplo L1 e o conjunto de regras T , caso o primeiro elemento de L1 seja umsımbolo para tipos, o predicado expandir(L1,T,L2), expande-o, originando o conjuntode tuplos L2. A sua implementacao esta descrita a seguir:

expandir([],_,[]).

expandir([H|L],_,[[H|L]]):-

not simbolo_para_tipos(H).

expandir([H|L],T,L3):-

member(H--->L2,T),

sequencias(L2,L,L3).

Para auxiliar a expansao foi tambem definido o predicado sequencias(L1,L2,L3) quedados todos os termos para tipos possıveis para o tipo a cabeca do tuplo inicial emL1 e a cauda desse mesmo tuplo em L2, produz uma lista L3 com todos os tuplosresultantes possıveis. A implementacao de sequencias/3 esta descrita a seguir:

sequencias([],_,[]).

sequencias([X|RX],L,[Y|RY]):-

append([X],L,Y),

sequencias(RX,L,RY).


Exemplo 4.3.3 Dado o conjunto de regras T = {α → {a,b,c}} e a sequencia S ={α,e,f}, a chamada ao predicado expandir(S,T,L) resulta em L = {{a,e,f}, {b,e,f},{c,e,f}}.

Necessitaremos de aplicar o expandir/3 a conjuntos de sequencias, para isso definimoso predicado expandir2/3 :

expandir2([],_,[]).

expandir2([X|RX],T,R):-

expandir(X,T,Y),

expandir2(RX,T,RY),

union(Y,RY,R).

Exemplo 4.3.4 Dado o conjunto de regras T = {α → {a, f(b, α)}} e o conjuntode sequencias S = { {e,f}, {1,5}, {α,c}, {f(g, g),g} }, a chamada ao predicadoexpandir2(S,T,L) resulta em L = {{e,f}, {1,5}, {a,c}, {f(b, α),c}, {f(g, g),g}}.

O predicado seleccionar(X,T1,T2) permite-nos seleccionar tuplos do conjunto de tu-plos expandidos T1 cujo elemento a cabeca e compatıvel com X, originando um novoconjunto T2. O predicado seleccionar/3 esta definido a seguir:

seleccionar(any,TS,T):-

membro_cabecas(any,TS,T),!.

seleccionar(X,TS,T3):-

tipo_base(X),!,

membro_cabecas(X,TS,T1),

membro_cabecas(any,TS,T2),

uniao(T1,T2,T3).


atom(X),!,

membro_cabecas(X,TS,T1),


membro_tipo(X,TS,T3),

uniao(T1,T2,T4),

uniao(T3,T4,T5).


funcional(X,Functor,Args),

aridade(X,N),

N>0,



membro_cabecas_func(X,TS,T2),

uniao(T1,T2,T3).

A primeira clausula permite-nos obter todos os elementos compatıveis com µ, para issoseleccionamos todos os tuplos que o incluem a cabeca. A segunda clausula permite-nos obter tuplos compatıveis com um tipo base, para isso juntamos todos os tuploscom esse tipo base ou com µ a cabeca. A terceira clausula permite-nos obter todosos elementos compatıveis com uma constante, os tuplos que nos interessam sao os quetem essa constante, o seu tipo base ou µ a cabeca. A quarta clausula destina-se aoscasos em que estamos a seleccionar tuplos com base num termo da forma f(w1, ..., wn)com n ≥ 0, para isso juntamos todos os tuplos cujo elemento a cabeca tenha sımbolofuncional f e n argumentos ou que seja µ. Quando existem varias alternativas, so aprimeira destas nos interessa.

Exemplo 4.3.5 Dado o conjunto expandido

T = {{e, f}, {1, 5}, {a, c}, {f(b, α), c}, {f(g, g), g}}

A chamada ao predicado seleccionar(f(d,d),T,L) resulta em

L = {{f(b, α), c}, {f(g, g), g}}

Definimos os predicados auxiliares cabeca/2 e cauda/2. O predicado cabeca(L,X), dadauma lista L retorna o seu primeiro elemento X. A sua implementacao e obvia e estadescrita a seguir:

cabeca([X|_],X).

O predicado cauda(L,L1), dada uma lista L retorna uma lista L1 com os elementosde L excepto o primeiro. A sua implementacao esta descrita a seguir:

cauda([_|R],R).

Definimos os predicados cabecas/2 e caudas/2 que generalizam os predicados cabeca/2e cauda/2 a listas de listas. A sua implementacao esta descrita a seguir:

cabecas([],[]).

cabecas([X|RX],[Y|RY]):-

cabeca(X,Y),

cabecas(RX,RY).

caudas([],[]).

caudas([X|RX],[Y|RY]):-

cauda(X,Y),

caudas(RX,RY).


O predicado extrair(X,TS,Y) permite “extrair” o primeiro elemento do tuplo expan-dido e seleccionado TS em funcao do termo a sua cabeca e do termo X, o tuploresultante e colocado em Y . A implementacao de extrair/3 esta descrita a seguir.

extrair(X,TS,Y):-

atom(X),

cauda(TS,Y).

extrair(X,TS,Y):-

tipo_base(X),

cauda(TS,Y).

extrair(X,TS,Y):-


cabeca(TS,any),

aridade(X,N),

N>0,

todos_any(Args,U),

cauda(TS,Z),

uniao(U,Z,Y).

extrair(X,TS,Y):-


cabeca(TS,H),

funcional(H,Functor,Args1),

aridade(X,N),

aridade(H,N),

N>0,

cauda(TS,Z),

uniao(Args1,Z,Y).

Dado um termo X e um qualquer tuplo TS a primeira e segunda clausulas saoresponsaveis por, caso o X seja uma constante, um tipo base ou µ retornar a cauda dotuplo TS. A terceira clausula e responsavel pelo caso em que X e da forma f(t1, . . . , tn)com n ≥ 0 e a cabeca de TS e µ, e retorna (µ, . . . , µ), com tantos elementos quantoos argumentos de f concatenado com a cauda do tuplo TS. A quarta clausula eresponsavel pelo caso em que X e da forma f(t1, . . . , tn) com n ≥ 0 e a cabeca de TSe um termo da forma f(w1, . . . , wn) e retorna (w1, . . . , wn) concatenado com a caudade TS.

O predicado extrair2(X,CS,R) resume-se a aplicacao de extrair/3 a um termo X e aum conjunto de sequencias CS, originando um novo conjunto R. A sua implementacaoe descrita a seguir:

extrair2(_,[],[]).


extrair2(X,[T|RT],Z):-

extrair(X,T,Y),

extrair2(X,RT,RY),

uniao([Y],RY,Z).

Exemplo 4.3.6 Dado X = f(a, b) e T = {{ f(b, α), c},{f(g, g), g}}, extrair2( X,T, R) resulta em R = {{b,α,c}, {g, g, g}}.

Neste momento ja e possıvel construir um predicado que dados dois termos e umconjunto de regras que os define, determina se o primeiro produz um subconjuntode termos do segundo. O predicado subconjunto(X,Y,T) tem sucesso se X gera umsubconjunto dos tipos gerado por Y segundo as regras T e esta definido a seguir:

subconjunto(none,_,_).

subconjunto(T1,T2,T):-

T1 \= none,

T2 \= none,

subconjunto2([T1],[[T2]],T,[]).

O primeiro termo e colocado dentro dum tuplo e o segundo dentro dum conjuntode tuplos. Note-se que todo este problema e resolvido com base em operacoes sobretuplos. O predicado subconjunto2/4, usando os predicados que definimos nesta seccaodetermina se o primeiro produz um subconjunto de tipos do segundo. O ultimoargumento de subconjunto2/4 e uma lista de elementos que ja foram processados.A sua implementacao e descrita a seguir:

subconjunto2(_,[],_,_):-!,fail.

subconjunto2([],_,_,_):-!.

subconjunto2(L1,L2,T,C):-

cabeca(L1,H),

membro([H,TR],C),

cabecas(L2,H2),

pertence(H2,TR),!,

cauda(L1,L3),

caudas(L2,L4),

subconjunto2(L3,L4,T,C).


cabeca(L1,H),

simbolo_para_tipos(H),!,


expandir(L1,T,L3),

cabecas(L2,HS),

union([[H,HS]],C,C2),

m_subconjunto2(L3,T,L2,C2).


cabeca(L1,H),

(tipo_base(H); funcional(H); H==any),!,

extrair(H,L1,L3),

expandir2(L2,T,L4),

seleccionar(H,L4,L5),

extrair2(H,L5,L6),

subconjunto2(L3,L6,T,C).

A primeira clausula de subconjunto2(X,Y,T,C) verifica se o conjunto de tuplos Y evazio, neste caso chegamos a uma situacao em que X nao e subconjunto de Y . Asegunda clausula e responsavel pelo caso em que X e um tuplo vazio e neste caso Xesta contido em Y . A terceira clausula verifica o caso em que a cabeca do tuplo Xja foi previamente analisada, juntamente com um conjunto de cabecas de tuplos Y 1e este ultimo esta contido no conjunto das cabecas de Y . Neste caso pode passar-sea analise da cauda de X e das caudas dos tuplos de Y . A quarta clausula destina-seaos casos em que X e um sımbolo para tipos. Neste caso expande X e recursivamenteverifica para cada termo expandido se produz um subconjunto de termos do segundoargumento. O predicado m subconjunto2(L1,T,L2,C) e reponsavel por verificar secada elemento do conjunto expandido L1 produz um subconjunto de termos de L2. Acabeca de X bem como as cabecas dos tuplos no conjunto de tuplos Y sao guardadosem C. A quinta clausula destina-se ao caso em que X e um tipo base, µ ou um termoda forma f(τ1, . . . , τn) com n ≥ 0. Neste caso extrai o primeiro elemento de X emfuncao do elemento a sua cabeca resultando em X1 e expande o conjunto de tuplosY resultando em Y 1. De seguida selecciona os elementos de Y 1 compatıveis com acabeca de X, originando Y 2. Continua extraindo a cabeca a cada um deles em funcaoda cabeca de X e resultando em Y 3. Por fim, verifica recursivamente se X1 gera umsubconjunto de termos de Y 3.

Exemplo 4.3.7 Dado o conjunto

T = {α→ {a, b}, β → {b, c}},

O predicado subconjunto(α,β,T ) resulta na chamada a subconjunto2({α}, {{β}}, T ,{}). Como α e um sımbolo para tipo passamos a chamar recursivamente

1. subconjunto2({a}, {{β}}, T , {[{α}, {{β}}])

2. subconjunto2({b}, {{β}}, T , {[{α}, {{β}}])


O predicado em 1 da origem a chamada subconjunto2({}, {}, T ,{[{α},{{β}}]) que re-sulta em Falso. O predicado em 2 da origem a extraccao de b em {b} originando {} e aexpansao de {{β}} que resulta em {{b,c}}, seguida da seleccao de b no conjunto expan-dido, resultando em {{b}}. A extraccao de b resulta num conjunto com uma sequenciavazia, {{}}. De seguida chama-se recursivamente subconjunto2({},{{}},T ,C} queresulta em Verdade. O resultado final e, pela conjuncao, Falso.

Exemplo 4.3.8 Dado o conjunto

T = {α→ {nil, f(a, f(a, α))}, β → {nil, f(const, β)}}

Note-se que const e o tipo base que representa todas as constantes. O predicadosubconjunto(α,β,T ) resulta na chamada a subconjunto2({α}, {{β}}, T , {}). Comoα e um sımbolo tipo passamos a chamar recursivamente

1. subconjunto2( {nil}, {{β}}, T ,{[{α}, {{β}}])

2. subconjunto2({f(a, f(a, α))}, {{β}}, T, {[{α}, {{β}}])

O passo 1 resulta em subconjunto2({},{{}},T,C} que e Verdade. O passo 2 resultaem subconjunto2({a, f(a, α)}, {{const,β}}, T , {[{α},{{β}}]) depois da expansao eextraccao do sımbolo funcional f . O passo seguinte e subconjunto2({f(a, α)}, {{β}},T , {[{α}, {{β}}]) uma vez que a e uma constante. Agora extraımos o sımbolo funcionalf resultando em subconjunto2({a,α}, {{const,β }}, T , {[{α}, {{β}}]) que mais umavez vai chamar subconjunto2({α}, {{β}}, T , {[{α}, {{β}}]). Uma vez que α e β jaforam analisados resulta em Verdade. O resultado final e portanto Verdade.

4.3.3 Interseccao de tipos regulares

Para inferir tipos de programas, necessitamos duma forma de saber qual o conjuntode termos gerado pela interseccao de dois tipos regulares. Dados os termos X e Y eo conjunto de regras T , o predicado interseccao(X,Y,T,Z,TZ) determina o tipo Z e oconjunto de regras TZ que representam a interseccao dos termos gerados a partir deX e Y .

O funcionamento de interseccao/5 e o seguinte:

1. Se os termos sao iguais, retorna um deles juntamente com o conjunto das regrasobtidas ate ao momento.

2. Se os termos ja foram intersectados previamente retorna o tipo originado duranteessa interseccao.

3. Se um dos termos e um tipo base e o outro pertence ao conjunto representado poresse tipo base, retorna o segundo juntamente com o conjunto de regras obtidoate ao momento.


4. Se pelo menos um dos termos e um sımbolo para tipo, calcula o produto cruzadoda interseccao do seu conjunto de regras com o outro termo. O produto cruzadoconsiste em, dados dois conjuntos de termos e o conjunto de regras que os define,determinar um novo conjunto composto por todas as interseccoes possıveis entreos dois primeiros. Note-se que se nao forem os dois sımbolos para tipos o produtocruzado e calculado directamente entre o conjunto de regras identificadas pelosımbolo para tipo e o outro termo.

5. No caso dos termos serem da forma f(τ 11 , . . . , τ 1

n) e f(τ 21 , . . . , τ 2

n) com n ≥0, devolve f(τ f

1 , . . . , τ fn ) em que τ f

i representa a interseccao de τ 1i com τ 2

i ,juntamente com o conjunto de regras obtido ate ao momento.

Exemplo 4.3.9 Dado o conjunto de regras

T = {α→ {b, g(a, g(α))}, β → {b, g(a, β), g(a, γ)}, γ→ {g(β)}}

A chamada a interseccao(α, β, T , TF , TR) vai resultar na criacao dum novo sımbolotipo a que chamaremos α1, na adicao dum triplo (α, β, α1) ao conjunto de interseccoesja efectuadas e na determinacao do produto cruzado dos seus conjuntos de regras:

pci({b, g(a, g(α))}, {b, g(a, β), g(a, γ)}, T, TF1, TR1).

1. A interseccao de b com b resulta em b.

2. A interseccao de b com g(a, β) resulta em φ.

3. A interseccao de b com g(a, γ) resulta em φ.

4. A interseccao de g(a, g(α)) com b resulta em φ.

5. A interseccao de g(a, g(α)) com g(a, β) resulta em g(a, φ).

6. A interseccao de g(a, g(α)) com g(a, γ) da origem a criacao dum novo sımboloa que chamaremos α2 para designar a associacao entre g(α) e γ. Determina-seo produto cruzado entre g(α) e g(β), ou seja entre α e β. Mas esta interseccaoja foi feita e o tipo resultante designa-se por α1. O conjunto de regras para α2 epois { g(α1)} (resultado do produto cruzado).

7. Dados todos os resultados das diferentes interseccoes em TF1 e o conjunto deregras resultante em TR1, reunimos os elementos de TF1 que nao representamtipos vazios para criar a nova regra de α1, temos que α1 → {b, g(a, α2) }.

O resultado final e :

• TF = α1

• TR = T ∪ {α1 → {b, g(a, α2)}, α2 → {g(α1)}


4.3.4 Unificacao de tipos regulares

Num programa, cada termo a cabeca de cada clausula dum predicado tem um tipoassociado e consequentemente as variaveis desse predicado tem tipos associados. Estaseccao destina-se a apresentar a implementacao duma unificacao entre termos de tiposque podem incluir variaveis, associando-lhes tipos via substituicoes. O resultado e umconjunto de regras resultante das diferentes interseccoes de tipos puros bem como umconjunto de substituicoes associadas as variaveis envolvidas no dito processo.

Por exemplo, se quisermos unificar as variaveis X e Y , sabendo que ambas estaorelacionadas com termos de tipos pelo conjunto de substituicoes S = {X/α,Y /β} eos tipos α e β estao definidos no conjunto de regras T = {α → {a,b,c}, β → {a,e,f}}entao a unificacao de X com Y resulta em X, num novo conjunto de substituicoes S= { X/Y , Y /γ} e num novo tipo definido pela regra γ → {a}.

O predicado unifica(X,Y,Z,S,R,T,W) determina a unificacao dos termos X e Y base-ado no conjunto de regras Z e no conjunto de substituicoes S. O termo, substituicoese conjunto de regras resultantes sao dados por R, T e W respectivamente. Estepredicado funciona segundo as seguintes regras (no caso de existir mais do que umapossibilidade usa-se a que aparecer primeiro):

1. Se X e Y sao identicos, retorna X juntamente com os conjuntos de regras esubstituicoes iniciais.

2. Se um dos termos for µ, retorna o outro termo juntamente com os conjuntos deregras e substituicoes iniciais.

3. Seja X uma variavel e X/w a substituicao que lhe corresponde no conjunto desubstituicoes S. Se X ocorre no termo Y retornamos o tipo vazio φ e os conjuntosde regras e substituicoes actuais. Caso contrario determinamos recursivamentea unificacao de w com Y resultando num termo w′ e em novos conjuntos deregras T ′ e de substituicoes S ′. De seguida substituımos X/w em S ′ por X/w′

resultando em S ′′. O resultado final e constituıdo pela variavel X, pelo conjuntode regras T ′ e pelas substituicoes S ′′.

4. Se tanto X como Y sao termos de tipos puros usamos a interseccao vistaanteriormente e retornamos o conjunto de regras resultante da interseccao deX com Y e o conjunto de substituicoes original.

5. Se X e um sımbolo para tipo definido por X → RT ∈ T e Y e da formaf(t1, . . . , tn) com n ≥ 0:

(a) Criamos um novo sımbolo para tipo, α1 e acrescentamos a regra α1 →{f(µ, . . . , µ)} a T originado T ′ (f fica com n elementos µ). Note-se que µe o tipo universal.


(b) Determinamos a interseccao de α1 com X, usando o conjunto de regras T ′.O resultado e um novo sımbolo para tipos X ′ e um novo conjunto de regrasT ′′.

(c) Consequentemente existe uma regra da forma X ′ → RT ′ ∈ T ′′ e todos oselementos de RT ′ sao da forma f(w1, . . . , wn).

(d) Construımos um novo conjunto

T ′′′ = T ′′ ∪ αk → {wk|f(. . . , wk, . . . ) ∈ RT ′|1 ≤ k ≤ n}

Cada αk e um sımbolo para tipos novo.

(e) O resultado final e obtido pela chamada recursiva da unificacao de Y comf(α1, . . . , αn) baseada nos conjuntos T ′′′ e S.

6. Se X e da forma f(τ 11 , . . . , τ 1

n) e Y e da forma f(τ 21 , . . . , τ 2

n) determina-se oresultado da unificacao de cada um dos seus argumentos τ f

i , sobrepondo em cadaunificacao os antigos conjuntos de regras e substituicoes pelos mais recentes. Oresultado e f(τ f

1 , . . . , τ fn ) e os conjuntos de regras e substituicoes mais recentes.

7. Se nenhuma das hipoteses anteriores se verifica entao nao e possıvel unificar osdois termos, sendo o resultado o tipo vazio.

Exemplo 4.3.10 Dados o conjunto de regras T = { α→ {a, b, c}} e de substituicoes{X/α, Y/a}, a chamada a unifica(X,Y,T,S,X’,T’,S’) resulta em:

1. Como X e uma variavel e X/α a substituicao que lhe corresponde, unifica-se αcom Y .

2. Como Y e uma variavel, Y/a a substituicao que lhe corresponde, unifica-se acom α.

3. Como α e a sao tipos puros, determinamos a sua interseccao, esta resulta numnovo tipo α1 com regra α1 → {a}. E retornado o novo tipo bem como o conjuntocontendo esta nova regra.

4. Voltando ao passo 2, substituımos Y/a por Y/α1 no conjunto de substituicoes eretornamos o Y e os conjuntos de regras e substituicoes.

5. Voltando ao passo 1, substituımos X/α por X/Y no conjunto de substituicoes.Retornamos como resultados o X, o conjunto de regras { α → {a, b, c}, α1 →{a}} e o conjunto de substituicoes {X/Y Y/α1}.

Exemplo 4.3.11 Dados o conjunto de regras T = {α → {f(β, β)}, β → {a}} e oconjunto de substituicoes S = {X/µ, Y/µ}, a chamada a unifica(f(X, Y ), α, T, S,XF, TF, SF) resulta em:


1. Como α e sımbolo para tipos e f(X, Y ) e um tipo funcional, determina-se ainterseccao entre α e α1 sobre o conjunto T ′ resultante da adicao da regra α1

→ {f(µ, µ)} a T . A interseccao resulta no tipo α2 com a regra α2 → {f(β, β)}incluıda no conjunto de regras resultante T ′′. Acrescentamos novos tipos α3

→ {β} e α4 → {β} a T ′′ resultando em T ′′′. Finalmente determinamos ainterseccao de f(X, Y ) com f(α3, α4).

2. A unificacao de f(X, Y ) com f(α3, α4) resulta na unificacao de cada um dosseus argumentos na mesma posicao.

3. A unificacao de X com α3 resulta na substituicao de X/µ em S por X/α3.

4. A unificacao de Y com α4 resulta na substituicao de Y /µ em S por Y /α4.

5. O resultado final e XF = f(X, Y ), TF = {α → {f(β, β)}, β → {a},α1 →{f(µ, µ)}, α2 → {f(β, β)}, α3 → {β}, α4 → {β}} e S = { X/α3, Y /α4}}.

Este ultimo exemplo mostra que o conjunto de regras obtido no final nao e dadonuma forma simplificada pois existem regras que foram criadas durante o processo deunificacao mas cuja relacao directa com o resultado final e nula. Estas regras podemser facilmente eliminadas.

4.4 Inferencia de tipos

Depois de termos implementado os predicados definidos anteriormente, estamos emcondicoes de apresentar o algoritmo de inferencia de tipos. Chama-se a atencaoque este algoritmo so esta definido para inferir tipos de programas definidos. Emparticular, predicados extra-logicos do Prolog nao sao tratados pelo nosso programa.

Comecamos por implementar o predicado tipo golo/5 que dado o corpo duma clausulaunifica todos os seus elementos com a sua definicao resultando num conjunto desubstituicoes que relaciona cada variavel com o seu tipo. De seguida implementamostipo programa/3 que usa o tipo golo/5 para obter os tipos dos argumentos a cabecaduma clausula. A uniao dos tipos das diferentes clausulas dum predicado origina o tipodo mesmo. Podem ser necessarias varias aplicacoes de tipo programa/3 para se obteros tipos dum programa com a maior precisao possıvel, por isso implementamos tambemo predicado super tipos/3 que aplica sucessivamente tipo programa/3. O criterio deparagem consiste em verificar se o tipo gerado na iteracao k+1 esta contido no tipogerado na iteracao k. Se assim for o programa para e os tipos obtidos sao mostrados.Existem no entanto casos em que o programa nao para. Para resolver essa situacaoimplementamos dois testes de paragem, um testa se chegamos a um determinadolimite de sımbolos funcionais iguais numa estrutura e outro verifica se chegamos a umdeterminado limite de sımbolos para tipos relacionados.

4.4. INFERENCIA DE TIPOS 79

Tambem obrigamos as regras de tipos a gozarem duma propriedade chamada distri-butividade nos tuplos pois Lu demonstrou em [Lu01] que o algoritmo para teste desubconjuntos de tipos so garante resultados correctos se os termos nas regras gozaremde distributividade nos tuplos.

Note-se que este sistema funciona sobre programas definidos e numa forma norma-lizada. Esta forma consiste em ter somente variaveis a cabeca das clausulas. Porexemplo, a clausula p(0) devera ser transformada em p(X):-X=0 para obedecer aforma normalizada. Por uma questao de simplicidade os programas apresentados nosnossos exemplos nao estao nesta forma.

Comecamos por descrever o predicado tipo golo(G,T,V,T2,S) que dado o corpo dumaclausula G, um conjunto de regras para tipos T e um conjunto de variaveis V , retornaum novo conjunto de regras T2 e um conjunto de substituicoes S.

tipo_golo(G,T,V,T2,Subst2):-

subst_univ(V,Subst),

tipo_golo2(G,T,Subst,T2,Subst2).

Assumimos de inıcio que o conjunto de substituicoes e constituıdo por elementos querelacionam todas as variaveis com o tipo universal µ (tarefa realizada por subst univ/2).O predicado tipo golo2/5 e entao chamado com este novo conjunto de substituicoes.Este predicado usa a unificacao como forma de obter uma substituicao para as variaveisdum golo e esta definido seguir:

tipo_golo2([],TRules,Subst,TRules,Subst).

tipo_golo2([G1=G2|RG],TRules,Subst,TRules3,Subst3):-

unifica(G1,G2,TRules,Subst,G3,TRules2,Subst2),

aplica_substituicoes(G3,Subst2,S),

not(vazio(S,TRules2)),!,

tipo_golo2(RG,TRules2,Subst2,TRules3,Subst3).

tipo_golo2([G1|RG],TRules,Subst,TRules3,Subst3):-

predicado(G1),

obtem_definicao_tipo(G1,Tipo_G1),

unifica(G1,Tipo_G1,TRules,Subst,G3,TRules2,Subst2),

aplica_substitucoes(G3,Subst2,S),

not(vazio(S,TRules2)),

tipo_golo2(RG,TRules2,Subst2,TRules3,Subst3).

Se o elemento em processamento no corpo da clausula e da forma A1=A2 unificamosA1 com A2 originando um novo termo e novos conjuntos de substituicoes e de regras.Doutra forma usamos obtem definicao tipo/2 para obtermos a definicao do predicadoem analise. Por exemplo, se encontramos o predicado p(a), a sua definicao e p(α1

p)


em que α1p e um sımbolo para tipos que define o tipo do argumento de p. De

seguida unificamos o predicado com a sua definicao originando um novo termo e novosconjuntos de substituicoes e de regras. Note-se que usamos tambem o predicadoaplica substituicoes(X,Y,Z) que dada uma estrutura X e um conjunto de substituicoesY , aplica repetidamente as substituicoes Y a X ate este ser um termo puro, originadoZ. O predicado tipo golo2/5 e consequentemente o predicado tipo golo/5 so terminacom sucesso se o termo originado pela unificacao nao e vazio.

Exemplo 4.4.1 Dado o conjunto de regras T = {αp → {a,b,c}} e o golo p(X), achamada a tipo golo(p(X),T,{X},TR,SR) resulta em TR = T e SR = {X/αp}.

Exemplo 4.4.2 Dado o conjunto de regras T = {αp1→ {µ}, αp

2→ {µ}} e o golo

(X=f(Y, Z), p(X, Z)), a chamada a tipo golo((X=f(Y,Z),p(X,Z)),T,{X,Y,Z},TR,SR)resulta em T = {αp

1→ {µ}, αp

2→ {µ}, α1 → {µ}, α2 → {µ}} e S = {X/f(Y, Z),

Y /α1, Z/α2}.

Como ja foi referido a correccao do algoritmo pressupoe a propriedade de distributivi-dade nos tuplos que passamos a enunciar:

Definicao 4.4.1 ([YFS92]) Seja S um conjunto de termos basicos. O fecho distri-butivo de S, α(S), e definido do seguinte modo:

α(S) = {c | c e uma constante ∧ c ∈ S} ∪ {f(t1, . . . , tn)|ti ∈ α(f−1

n,i (S)), 1 ≤ i ≤ n}

onde f e um sımbolo funcional em S e f−1

n,i (S) e definido como:

f−1

n,i (S)) = {ti | f(t1, . . . , ti, . . . , tn) ∈ S}

Um conjunto S e distributivo no tuplo se S = α(S).

Exemplo 4.4.3 O conjunto S = {a, b, f(a, b), f(c, d)} nao e distributivo no tuplo jaque, por exemplo, f(c, b) ∈ α(S) e f(c, b) /∈ S.

Exemplo 4.4.4 O conjunto S = {a, b, f(a, b), f(c, d), f(a, d), f(c, b)} e distributivono tuplo ja que, S = α(S).

O predicado tipo programa(P,T,NT), recebe o programa P e o conjunto de regras T edevolve um novo conjunto de regras NT com os tipos inferidos de P . A implementacaode tipo programa/3 esta descrita a seguir:

tipo_programa(P,T,NT2):-

tipo_programa2(P,T,T2,FT),

remove_tipos_antigos(T2,T3),

uniao(T3,FT,NT1),

ditribui_tuplos(NT1,NT2).


O predicado tipo programa/3 recorre a tipo programa2/4 para obter os tipos dumprograma, de seguida substitui os antigos tipos que definiam os predicados pelosnovos, alterando-os quando necessario para gozarem de distributividade nos tuplos.O predicado tipo programa2(Pred,T,NT,F) usa tipo programa3/4 para determinar otipo de cada uma das clausulas do predicado Pred com base no conjunto de regras T ,devolve o conjunto NT que consiste no conjunto T juntamente com os novos tipos queforam sendo gerados no processo de inferencia e devolve o conjunto F com os tipos decada um dos argumentos a cabeca do predicado Pred, obtidos a partir da uniao dostipos do argumento respectivo em cada clausula. A sua implementacao esta descritaa seguir:

tipo_programa2(P,T,T,[]):-

programa_vazio(P).

tipo_programa2(P,T1,T3,FL):-

regra(P,Regra),

resto_programa(P,R),

tipo_programa3(Regra,T1,T2,L),

tipos_finais(Regra,L,L2),

tipo_programa2(R,T2,T3,RL),

uniao(L2,RL,FL).

O predicado tipo programa3(C,T,NT,F) extrai as variaveis dos elementos da clausulaC e usa tipo programa4/6 para obter o tipo da clausula com base no seu corpo. Oconjunto de regras e dado em T e o resultado e um novo conjunto de regras NT . Asua implementacao e descrita a seguir:

tipo_programa3(P,T,T,[]):-

programa_vazio(P).

tipo_programa3(P,T1,T3,[L2|RL]):-

corpo(P,C),

cabeca(P,Cab),

argumentos(Cab,L),

variaveis(P,V),

tipo_programa4(C,V,T1,T2,L,L2),

resto_programa(P,R),

tipo_programa3(R,T2,T3,RL).

O predicado tipo programa4(CC,V,T,TF,A1,A2) recebe o corpo da clausula em CC,as variaveis desta em V , o conjunto de regras que definem os tipos dos seus argumentosem T e os argumentos a cabeca da clausula em A1 e devolve o novo conjunto de regrasTF e o resultado da aplicacao da substituicao obtida por intermedio de tipo golo/5a A1 em A2. No caso do tipo golo/5 nao ter sucesso os argumentos em A1 sao


substituıdos pelo tipo vazio none em A2. A descricao da sua implementacao e feita aseguir:

tipo_programa4(A,V,T1,T2,L1,L2):-

tipo_golo(A,T1,V,T2,Subst),!,

aplica_substituicoes(L1,Subst,L2,[]).

tipo_programa4(_,_,T,T,L1,L2):-

acrescenta_vazios(L1,L2).

Resumidamente este programa funciona aplicando o tipo golo/5 ao corpo de cadaclausula, no caso deste ter sucesso aplica-se o conjunto de substituicoes retornadoa cada argumento da cabeca da clausula, por exemplo, se a clausula e da formap(t1, . . . , tn) : −B, e o conjunto de substituicoes retornado por tipo golo/5 e S entaocria-se um τ p

ij resultado da aplicacao da substituicao S a ti na clausula j. O resultado eguardado e quando todas as clausulas tiverem sido examinadas determina-se o tipo decada argumento do predicado criando uma regra com a uniao dos resultados inferidosdas clausulas para esse argumento:

{αpi → {τ

pi1, . . . , τ

pin}|1 ≤ i ≤ n, e p e um predicado de aridade n}

Exemplo 4.4.5 Dado o programa P:

append([],L,L).

append([X|R1],Y,[X|R2]):-

append(R1,Y,R2).

E o conjunto de regras

T = {α1

append → {µ}, α2


append → {µ}}

A aplicacao de tipo programa/3 a estes resulta no conjunto de tipos:

T = {α1

append → {[], [µ|α1

append]}, α2


append → {[µ|α3

append]}}

Para certos programas a inferencia dos tipos implica mais do que uma aplicacao dopredicado tipo programa/3. O exemplo seguinte ilustra um destes casos.

Exemplo 4.4.6 Dado o programa P :

p(0).

p(f(X)):-q(X),X=f(Y).

q(f(0)).

q(g(X)).

q(f(X)):-p(X).


E o conjunto de regrasT = {α1

p → {µ}, α1

q → {µ}}

A primeira vez que usamos o tipo programa/3 obtemos o conjunto de regras:

NT2′ = {α1

p → {0, f(f(α1))}, α1

q → {g(µ), f(α2)}, α1 → {µ}, α2 → {0, α1

p}}

Se usarmos este conjunto de tipos numa nova chamada ao predicado tipo programa/3obtemos o seguinte conjunto:

NT2′′ = {α1

p → {0, f(f(α1))}, α1

q → {g(µ), f(α2)}, α1 → {0, α1

p}, α2 → {0, α1

p}}

Este ultimo conjunto caracteriza de forma mais precisa os tipos de P. Posterioreschamadas a tipo programa/3 resultam num conjunto de tipos equivalente a NT2”.O predicado infere tipos(P,T0,T1) recebe um programa P e um conjunto de tiposT0 (todos os tipos correspondentes a cada um dos argumentos dos predicados doprograma sao fornecidos inicialmente com um conjunto de regras que os define comoµ) e devolve, no caso de ser possıvel determinar, o conjunto de tipos inferidos T1. Asua descricao e feita a seguir:

infere_tipos(P,T0,T1):-

tipo_programa(P,T0,T1),

chegou_limite(T1),!,

nl, write(’N~ao e possıvel determinar os tipos!’).



igual(T0,T1),!.



infere_tipos(P,T1,T2).

Este predicado recorre a tipo programa/3 para determinar os tipos dum programa. Oprograma para quando os tipos obtidos num passo k + 1 sao identicos aos obtidos nopasso k ou quando e atingido um limite no numero de sımbolos funcionais identicosnuma estrutura ou no numero de tipos relacionados, evitando assim um ciclo infinito.

Capıtulo 5

Processamento de XML validadoestaticamente

5.1 Introducao

Ha uma correspondencia obvia entre DTDs e Tipos Regulares. Baseados nessa si-milaridade obtemos validacao estatica de programas em logica para o processamentode XML traduzindo DTDs para Tipos Regulares. Neste capıtulo estabelecemos arelacao entre os DTDs e os Tipos Regulares e descrevemos o processo de validacao deprogramas.

5.2 Traducao de DTDs para Tipos Regulares

Para usarmos os DTDs como declaracoes de tipos para programas em logica tradu-zimos os mesmos para Tipos Regulares. Por exemplo, o DTD na figura 5.1 validadocumentos XML que guardam informacoes sobre receitas. A sua traducao paratipos regulares consiste em criar uma regra de tipo para cada elemento. O conjuntoque define esta regra e constituıdo por termos disjuntos que representam o corpo doelemento em causa. A figura 5.2 apresenta os tipos inferidos a partir do DTD da figura5.1.

Cada elemento simples (sem sub elementos) e representado por um termo de tipospuro. Quando um elemento tem um ou mais sub elementos opcionais representamosa sua regra por um conjunto de termos puros que representam todas as combinacoespossıveis de sub elementos. Quando um elemento deve incluir pelo menos um subelemento, representamos a sua regra por uma lista de pelo menos um elemento (porexemplo τ13 representa passo+). Quando um elemento deve ter zero ou mais sub ele-mentos, representamos a regra por uma lista de elementos do seu tipo (por exemplo τ8

representa item* ). Quando um elemento tem sub elementos disjuntos estes aparecem

85

86 CAPITULO 5. PROCESSAMENTO DE XML VALIDADO ESTATICAMENTE

todos na regra que o representa. De seguida apresentamos a traducao de cada tipo deelemento possıvel num DTD, definindo uma funcao de traducao T .

<!ELEMENT receita (tıtulo, autor,descricao?, ingredientes, instrucoes?)><!ELEMENT tıtulo (#PCDATA)><!ELEMENT autor (nome, email?)><!ELEMENT nome (#PCDATA)><!ELEMENT email (#PCDATA)><!ELEMENT descricao (#PCDATA)><!ELEMENT ingredientes (item*)><!ELEMENT item (qtd,ingrediente)><!ELEMENT qtd (#PCDATA)><!ELEMENT ingrediente (#PCDATA)><!ELEMENT instrucoes (passo+)><!ELEMENT passo (#PCDATA)>

Figura 5.1: Um DTD para receitas

5.2.1 Elemento simples (conteudo e texto)

Para os elementos simples (cujo conteudo e texto), criamos uma regra com um sımbolotipo que o designa e cujo conteudo e da forma nome elemento(string):

T (<!ELEMENT e (#PCDATA) >) = τe → {e(string)}

Por exemplo, dada a seguinte declaracao:


Usando τ para designar a, a sua traducao para uma regra de tipo e:

τ → {a(string)}

5.2.2 Elemento vazio

Para os elementos cujo conteudo e vazio, a regra de tipo respectiva engloba apenas onome do elemento em causa:

T (<!ELEMENT e EMPTY >) = τe → {e}

5.2. TRADUCAO DE DTDS PARA TIPOS REGULARES 87

τ1 → {receita(τ2, τ3, τ6, τ7, τ12),receita(τ2, τ3, τ7, τ12),receita(τ2, τ3, τ7),receita(τ2, τ3, τ6, τ7)}

τ2 → {tıtulo(string)}τ3 → {autor(τ4,τ5), autor(τ4)}τ4 → {nome(string)}τ5 → {email(string)}τ6 → {descricao(string)}τ7 → {ingredientes(τ8)}τ8 → {nil, .(τ9, τ8)}τ9 → {item(τ10,τ11)}τ10 → {qtd(string)}τ11 → {ingrediente(string)}τ12 → {instrucoes(τ13)}τ13 → {.(τ14, nil), .(τ14, τ13)}τ14 → {passo(string)}

Figura 5.2: Tipos regulares para o DTD das receitas

<!ELEMENT a EMPTY>


τ → {a}

5.2.3 Elemento com qualquer conteudo

Para os elementos cujo conteudo e qualquer, a regra de tipo respectiva e da formanome elemento(µ). Note-se que µ representa o tipo universal:

T (<!ELEMENT e ANY >) = τe → {e(µ)}


<!ELEMENT a ANY>


τ → {a(µ)}

5.2.4 Elemento com sub elementos

Para os elementos cujo conteudo e composto por um ou mais sub elementos, a regrade tipo respectiva e da forma nome elemento(tipos dos sub elementos):

T (<!ELEMENT e (e1, . . . , en) > = τe → {e(τe1, . . . , τen

)}, ondeT (<!ELEMENT ei >) = τei

→ Υei,

para 1 ≤ i ≤ n


<!ELEMENT a (b,c)>



Usando τ1, τ2 e τ3 para designar a, b e c respectivamente, a sua traducao para regrasde tipos corresponde a:

τ1 → {a(τ2, τ3)}

τ2 → {b(string)}

τ3 → {c(string)}

5.2.5 Elemento opcional que pode repetir-se

A regra para designar o tipo dum elemento opcional que pode repetir-se e constituıdapor uma lista de elementos do tipo em questao que pode ser vazia:

T (<!ELEMENT e e1∗ >) = τe → {nil, .(τe1, τe)}, onde

T (<!ELEMENT e1 >) = τe1→ Υe1


<!ELEMENT a b*>


Usando τ1 e τ2 para designar a e b respectivamente, a sua traducao para regras detipos corresponde a:

τ1 → {a(τ2)}

τ2 → {nil, .(τ3, τ2)}

τ3 → {b(string)}

5.2.6 Elemento que pode repetir-se

A regra para designar o tipo dum elemento que aparece pelo menos uma vez e quepode repetir-se e constituıda por uma lista de elementos do tipo em questao com pelomenos um elemento:

T (<!ELEMENT e e1+ >) = τe → {.(τe1, nil), .(τe1

, τe)}, ondeT (<!ELEMENT e1 >) = τe1

→ Υe1


<!ELEMENT a b+>


Usando τ1 e τ2 para designar a e b respectivamente, a sua traducao para regras detipos corresponde a:

τ1 → {a(τ2)}

τ2 → {.(τ3, nil), .(τ3, τ2)}

τ3 → {b(string)}

5.2.7 Disjuncao de elementos

Para um elemento cujo conteudo e constituıdo por uma disjuncao de elementos, cria-seuma regra com todos estes elementos:

T (<!ELEMENT e (e1| · · · |en) >) = τe → {τe1, . . . , τen

}, ondeT (<!ELEMENT ei >) = τei

→ Υei,

para 1 ≤ i ≤ n


<!ELEMENT a (b|c)>



Usando τ1, τ2 e τ3 para designar a, b e c respectivamente, a sua traducao para regrasde tipos corresponde a:

τ1 → {a(τ2)}

τ2 → {τ3, τ4}

τ3 → {b(string)}

τ4 → {c(string)}

5.2.8 Elemento opcional

Para um elemento cujo conteudo e constituıdo por um conjunto de um ou mais subelementos em que pelo menos um destes e opcional, cria-se uma regra com todas ascombinacoes possıveis dos elementos nao opcionais com os elementos opcionais. Paraum elemento com um sub elemento opcional:

T (<!ELEMENT e (e1, . . . , ei?, . . . , en)) = τe → {e(τe1, . . . , τei−1

, τei+1, . . . , τen

),e(τe1

, . . . , τei−1, τei

, τei+1, . . . , τen

)},ondeT (<!ELEMENT ei >) = τei

→ Υei,

para 1 ≤ i ≤ n

Quando existem dois ou mais elementos opcionais determinamos todas as combinacoespossıveis e geramos os Tipos Regulares correspondentes. Por exemplo, dada a seguintedeclaracao:

<!ELEMENT a (b,c?,d?)>




Usando τ1, τ2, τ3 e τ4 para designar a, b, c e d respectivamente, a sua traducao pararegras de tipos corresponde a:

τ1 → {a(τ2), a(τ2, τ3), a(τ2, τ4), a(τ2, τ3, τ4)}

τ2 → {b(string)}

τ3 → {c(string)}

τ4 → {d(string)}

5.2.9 Atributos

Por uma questao de simplicidade, nas regras de tipos apresentadas nas sub seccoesanteriores nao foi abordado o destino a dar aos atributos. Estes sao irrelevantes noprocesso de inferencia de tipos. No entanto, estao presentes nos termos que represen-tam documentos XML e consequentemente estarao presentes nos tipos inferidos dosprogramas que processem estes termos. Por exemplo, o documento seguinte:

<a> Conteudo de a </a>

Origina o termo:


a([],’Conteudo de a’)

Este termo inclui uma lista (neste caso vazia) para os atributos. Um programa paraprocessar este termo e por exemplo:

p(a(X,’Conteudo de a’),a(X,’Outro conteudo’)).

O primeiro e segundo argumentos de p tem tipos:

τ 1

p → {a(µ, ’Conteudo de a’)}

τ 2

p → {a(µ, ’Outro conteudo’)}

Estes tipos incluem os atributos. Como vamos posteriormente proceder a comparacaodos tipos inferidos do programa com os tipos dos DTDs correspondentes, acrescenta-mos um argumento aos termos nas regras de tipos dos DTDs de forma a representarestes atributos e tornar a comparacao mais facil. O argumento sera sempre µ uma vezque ignoramos o destino a dar a lista de atributos. No caso da declaracao:



τ → {a(µ, string)}

5.2.10 Implementacao

Previamente criamos a partir do DTD uma lista com pares (elemento, conteudo) apartir da qual determinamos os tipos. Por exemplo a partir do DTD na imagem 5.1obtemos a lista seguinte:

[ (passo, #pcdata),

(ingrediente, #pcdata),

(qtd, #pcdata),

(item, (qtd, ingrediente)),

(email, #pcdata),

(nome, #pcdata),

(instruc~oes, +passo),

(ingredientes, *(item)),

(descric~ao, #pcdata),

(autor, (nome, ?email)),

(titulo, #pcdata),

(receita, (titulo, autor, ?descric~ao, ingredientes, ?instruc~oes))

]


O predicado processa lista tipos(L,D,LF,R) processa a lista de pares L segundo o DTDindicado em D e devolve a lista de tipos LF e o elemento R que representa a raiz dodocumento. Note-se que usamos o nome dos elementos para identificar a regra quelhe diz respeito. A sua implementacao esta descrita a seguir:

processa_lista_tipos([(X,T)],_,[X--->[TermType] | SubTypeList],X):-!,

processa_tipo(T,FT),

corpo_tipo(X,FT,TermType),

processa_tipo2(T,SubTypeList).

processa_lista_tipos([(X,T)|R],DTD,[X--->[TermType] | RFinal],Root):-

processa_tipo(T,FT),

corpo_tipo(X,FT,TermType),

processa_tipo2(T,SubTypeList),!,

processa_lista_tipos(R,DTD,R2,Root),

append(SubTypeList,R2,RFinal).

Neste predicado comecamos por processar o conteudo de cada elemento de forma aobtermos um termo para a regra que o define. Para isso recorremos a processa tipo/2que esta descrito a seguir:

processa_tipo(empty,[nil]):-!.

processa_tipo(’#pcdata’,[string]):-!.

processa_tipo(’#cdata’,[string]):-!.

processa_tipo((X,Y),[X|R]):-!,

processa_tipo(Y,R).

processa_tipo(X,[X]).

De seguida tratamos os casos em que o conteudo dum elemento e constituıdo por umconjunto de um ou mais sub elementos do tipo opcional (?), opcional que pode repetir-se (*) ou que pode repetir-se (+). Neste caso uma nova regra e criada para o casoem questao. O predicado processa tipo2/2 encarrega-se desta funcao e esta descrito aseguir:

processa_tipo2(empty,[]):-!.

processa_tipo2(’#pcdata’,[]):-!.

processa_tipo2(’#cdata’,[]):-!.

processa_tipo2(+((X,Y)),[+((X,Y))--->[.(((X,Y)),nil),

.(((X,Y)),+((X,Y)))]|R]):-!,

processa_tipo2(X,R1),

processa_tipo2(Y,R2),


append(R1,R2,R).

processa_tipo2(+(X),[+(X)--->[.(X,nil),.(X,+(X))]]):-!.

processa_tipo2(*((X,Y)),[*((X,Y))--->[nil,.(((X,Y)),*((X,Y)))]|R]):-!,



append(R1,R2,R).

processa_tipo2(*(X),[*(X)--->[nil,.(X,*(X))]]):-!.

processa_tipo2(?((X,Y)),R):-!,



append(R1,R2,R).

processa_tipo2(?(_),[]):-!.

processa_tipo2((X|Y),ListTypes):-!,

processa_tipo_ou((X|Y),(X|Y),ListTypes).

processa_tipo2((X,Y),R):-!,



append(R1,R2,R).

No caso em que estamos a tratar uma disjuncao de elementos recorremos ao predicadoauxiliar processa tipo ou/3 para construir a regra correspondente. Note-se que todosos elementos da disjuncao aparecem na regra. A implementacao de processa tipo ou/3esta descrita a seguir:

processa_tipo_ou(X,Type,[Type--->L]):-

processa_tipo_ou2(X,L).

processa_tipo_ou2((X),[X]).

processa_tipo_ou2((X|Y),[X|RType]):-

processa_tipo_ou2(Y,RType).

Tendo como exemplo o DTD na figura 5.1, nesta primeira fase criamos a lista de tipos:

[ receita ---> [ receita(titulo,autor,?descric~ao,ingredientes,

?instruc~oes)]

titulo ---> [ titulo(string)],

autor ---> [ autor(nome,?email)],


nome ---> [ nome(string)],

email ---> [ email(string)],

descric~ao ---> [ descric~ao(string)],

ingredientes ---> [ ingredientes(*(item))],

*(item) ---> [nil,[item| *(item)]],

item ---> [ item(qtd,ingrediente)],

qtd ---> [ qtd(string)],

ingrediente ---> [ingrediente(string)],

instruc~oes ---> [ instruc~oes(+passo)],

+passo ---> [ [passo|nil],[passo|+passo]],

passo ---> [ passo(string)],

]

Quando existem elementos opcionais e necessario incluir na regra correspondente todasas combinacoes possıveis de elementos em funcao dos opcionais. Dada a lista com asregras definidas ate ao momento, o predicado processa tipo op/2 cria novos termospara tipo para os elementos contendo opcionais.

Por exemplo, dada a lista de regras R = [ele→ [ele(?a, ?b, c, d)]], processa tipo op(R,R1)retira todos os elementos opcionais de ele, neste caso [a, b] e cria uma lista comtodas as combinacoes possıveis entre eles, resultando em [[], [a], [b], [a, b]]. Esta lista eusada para criar os novos termos para tipos de ele. Estes sao, ele(c, d) onde nenhumelemento opcional ocorre, ele(a, c, d) onde somente o elemento opcional a esta presente,ele(b, c, d) onde somente o elemento b esta presente e ele(a, b, c, d) onde todos oselementos opcionais ocorrem. A lista de regras final passa a ser R1 = [[τele → [ele(c, d),ele(a, c, d), ele(b, c, d), ele(a, b, c, d)]].

O DTD na figura 5.1 depois de processado por processa tipo op/2 resulta em:

type1 ---> [receita(any, type2, type3, type6, type7, type12),

receita(any, type2, type3, type7, type12),

receita(any, type2, type3, type7),

receita(any, type2, type3, type6, type7)]

type2 ---> [titulo(any, string)]

type3 ---> [autor(any, type4, type5),autor(any, type4)]

type4 ---> [nome(any, string)]

type5 ---> [email(any, string)]

type6 ---> [descric~ao(any, string)]

type7 ---> [ingredientes(any, type_(type8, 0))]

type8 ---> [[], [type9|type8]]

type9 ---> [item(any, type10, type11)]

type10 ---> [qtd(any, string)]

type11 ---> [ingrediente(any, string)]

type12 ---> [instruc~oes(any, type13)]

type13 ---> [[type14], [type14|type13]]

5.3. TRADUCAO DE PROLOG PARA XML 95

type14 ---> [passo(any, string)]

5.3 Traducao de Prolog para XML

Depois de processarmos um termo Prolog representando um documento XML, temosque o traduzir para um documento XML sob a forma dum ficheiro. Por exemplo, dadoo termo seguinte:

endereco([], [nome([], ’Jorge’),

morada([], ’Gondomar’),

telefone([], ’123456789’),

nome([], ’Sonia’),

morada([], ’Ermesinde’),

nome([], ’Pedro’),

morada([], ’Braga’),

telefone([], ’987654321’])

A sua traducao para um documento XML resulta em:

<endereco>

<nome> Jorge </nome>

<morada> Gondomar </morada>


<nome> Sonia </nome>

<morada> Ermesinde </morada>

<nome> Pedro </nome>

<morada> Braga </morada>


</endereco>

No nosso sistema isto e feito pelo predicado pro2xml(T,F) que dado um termo T eo nome dum ficheiro F , traduz o termo T para um documento XML que escreve noficheiro F .

5.4 Processamento de XML

Neste momento definimos, uma traducao de documentos XML para termos Prolog,uma traducao de DTDs para Tipos Regulares e algoritmos de inferencia de tipos

para programas Prolog. Com estas ferramentas podemos processar XML validadoestaticamente em Prolog puro. O nosso processo consiste em, dado um programa deprocessamento de XML e dois DTDs que validam os dados de entrada e saıda domesmo, inferir os tipos dos DTDs e utiliza-los como declaracoes de tipos para o nossoprograma. Este deve ter as suas clausulas numa forma normalizada. Comecamos pordefinir clausula Prolog normalizada:

Definicao 5.4.1 ([Zob90]) Uma clausula normalizada e uma clausula em que acabeca e qualquer literal, diferente da igualdade, tem uma variavel distinta para cadaargumento. A forma normalizada da clausula p(t1, . . . , tn)← B e a clausula:

p(x1, . . . , xn)← x1 = t1 ∧ · · · ∧ xn = tn ∧ B′

onde B′ e B onde cada literal positivo q(tq1, . . . , tqkq

) e substituıdo pela conjuncao

xq1 = tq1 ∧ · · · ∧ xq

kq= tqkq

∧ q(xq1, . . . , x

qkq

)

cada literal negativo ¬r(tr1, . . . , trkr

) e substituıdo pela conjuncao

xr1 = tr1 ∧ · · · ∧ xr

kr= trrr

∧ ¬r(xr1, . . . , x

rkr

)

onde x1, . . . , xn, . . . , xq1, . . . , x

qkq

, . . . , xr1, . . . , x

rkr

, . . . sao variaveis novas e distintas.

Por exemplo, dado o programa:

p(a(X,Y),d(X,Y)).

A sua forma normalizada e:

p(V1,V2):-

V1=a(V3,V4),

V2=d(V5,V6),

V3=V5,

V4=V6.

O nosso sistema declara os tipos do programa em analise como sendo inicialmenteo tipo correspondente aos DTDs que validam os dados de entrada e de saıda. Porexemplo, dado o DTD de entrada:

<!ELEMENT a (b,c)>

5.4. PROCESSAMENTO DE XML 97

Os tipos correspondentes para este sao:

τa → {a(τb, τc)}

τb → {b(string)}

τc → {c(string)}

Dado o DTD de saıda:

<!ELEMENT d (b,c)>



Os tipos correspondentes para este sao:

τd → {d(τb, τc)}

τb → {b(string)}

τc → {c(string)}

Dado o programa:

p(a(X,Y),d(X,Y)).

Depois de traduzir as clausulas para a forma normalizada o nosso sistema declara ostipos de p como sendo:

τ 1

p → {τa}

τ 2

p → {τd}

O sistema associa as variaveis a cabeca de p com estes tipos mediante substituicoes.

O facto do programa estar na forma normalizada obriga a sucessivas interseccoes(4.3.3) entre o tipo declarado e os tipos do programa, a medida que estes vao sendoinferidos. O exemplo anterior esta correcto e por isso o nosso sistema valida-o. Noexemplo anterior, se o DTD para os dados de saıda for o seguinte:

<!ELEMENT d (e,c)>



Os tipos correspondentes sao:

τd → {d(τe, τc)}

τe → {e(string)}

τc → {c(string)}

O comportamento do sistema e o seguinte (analise da clausula normalizada de p):

1. V 1 = a(V 3, V 4): A variavel V 1 que esta associada ao tipo de τa mediante subs-tituicoes e intersectada com o termo a(V 3, V 4). Daqui resulta que as variaveisV 3 e V 4 sejam associadas mediante substituicoes a τb e τc respectivamente.

2. V 2 = a(V 5, V 6): A variavel V 2 que esta associada ao tipo de τd mediante subs-tituicoes e intersectada com o termo a(V 5, V 6). Daqui resulta que as variaveisV 5 e V 6 sejam associadas mediante substituicoes a τe e τc respectivamente.

3. V 3 = V 5: Obriga a interseccao dos tipos τb e τe. A sua interseccao e vazia peloque existe um erro. O sistema alerta o utilizador para uma incompatibilidadede tipos.

Existem casos em que o programa so e valido para casos muito particulares, porexemplo a lista vazia. Nestes casos o sistema de tipos alerta o programador produzindoum aviso. Por exemplo dado o programa:

p(a(X),b(Y)):-

p2(X,Y).

p2([],[]).

p2([e(A)|R1],[d(A)|R2]):-

p2(R1,R2).

Dado o DTD para os dados de entrada:

<!ELEMENT a (e)*>


Com tipos correspondentes:

τa → {a(τe∗)}

τe∗ → {nil, .(τe, τe∗)}

τe → {e(string)}

Dado o DTD para os dados de saıda:

<!ELEMENT b (e)*>


Com tipos correspondentes:

τb → {b(τe∗)}

τe∗ → {nil, .(τe, τe∗)}

τe → {e(string)}

Neste caso o programa so produz resultados validos quando manipula um documentovazio. O nosso sistema avisa o utilizador que o resultado a saıda so pode ser umdocumento vazio mas compila o programa.

Apresentamos de seguida o predicado principal do nosso sistema, x-prolog(Ficheiro),onde Ficheiro e o nome do programa a ser avaliado pelo nosso sistema. A imple-mentacao de x-prolog/1 esta descrita a seguir:

x-prolog(Ficheiro):-

pre_processa(Ficheiro,Predicados),

declara_tipos(Predicados,TPred)

infere_tipos(’temp.x-prolog’,TPred),

consult(Ficheiro).

Dado o ficheiro F , o predicado pre processa(F,T) retorna uma lista com os predicadosraiz que processam XML. O predicado declara tipos(P,TP), constroi uma lista TPcom as declaracoes para os predicados raiz P . O ficheiro F e gravado na notacaointerna (clausulas Prolog normalizadas) no ficheiro temp.x-prolog e a partir deste, opredicado infere tipos(’temp.x-prolog’,Tipos) infere os tipos para o programa em F .Caso a inferencia tenha sucesso passa-se a compilacao do programa.

De seguida sao apresentados alguns exemplos do funcionamento do nosso sistema.Dado o seguinte DTD:

<!ELEMENT livro_enderecos1 (nome,pais,email?)*>


<!ELEMENT pais (#PCDATA)>


Sendo τ 1

DTD1, τ 2

DTD1, τ 3

DTD1e τ 4

DTD1sımbolos para os tipos de livro enderecos1, nome,

paıs e email respectivamente, os tipos correspondentes a este DTD sao:

τ 1

DTD1→ {livro enderecos1(τ 2

DTD1)}

τ 2

DTD1→ {nil, .(τ 3

DTD1, τ 4

DTD1, τ 5

DTD1, τ 2

DTD1), .(τ 3

DTD1, τ 4

DTD1, τ 2

DTD1)}

τ 3

DTD1→ {nome(string)}

τ 4

DTD1→ {pais(string)}

τ 5

DTD1→ {email(string)}

Dado o seguinte DTD:

<!ELEMENT livro_enderecos2 (nome,email)*>

100CAPITULO 5. PROCESSAMENTO DE XML VALIDADO ESTATICAMENTE

Sendo τ 1DTD2

, τ 2DTD2

e τ 3DTD2

sımbolos para os tipos de livro enderecos2, nome, e emailrespectivamente, os tipos correspondentes a este DTD sao:

τ 1

DTD2→ {livro enderecos2(τ 2

DTD2)}

τ 2

DTD2→ {nil, .(τ 3

DTD2, τ 4

DTD2, τ 2

DTD2)}

τ 3

DTD2→ {nome(string)}

τ 4

DTD2→ {email(string)}

Construımos um programa que traduz documentos validos face ao primeiro DTD paranovos documentos validos face ao segundo DTD. O proximo exemplo traduz um livrode enderecos constituıdo por triplos (nome, paıs, email) para um segundo livro deenderecos constituıdo por pares (nome, email).

prog(FileXML1,XMLTerm1,FileXML2,XMLTerm2):-

xml_to_prolog(FileXML1,’DTD1.dtd’,XMLTerm1,TypeDTD1),

process(XMLTerm1,XMLTerm2),

prolog_to_xml(’DTD2.dtd’,TypeDTD2,XMLTerm2,FileXML2).

process(livro_enderecos1(X),livro_enderecos2(Y)):-

process2(X,Y).

process2([],[]).

process2([nome(X),pais(Y),email(Z)|R1],[nome(X),email(Z)|R2]):-

process2(R1,R2).

process2([nome(X),pais(Y)|R1],R2):-

process2(R1,R2).

Sendo τ 1process e τ 2

process os tipos para o primeiro e segundo argumentos de process eτ 1process2 e τ 2

process2 os tipos para o primeiro e segundo argumentos de process2, os tiposinferidos para este programa sao:

τ 1

process → {livro enderecos2(τ 1

process2)}

τ 2


process2)}

τ 1

process2 → {[], [nome(any), pais(any), email(any)|τ 1

process2],

[nome(any), pais(any)|τ 1

process2]}

τ 2

process2 → {[], [nome(any), email(any)|τ 2

process2]}


O programa e valido e consequentemente compilado. Se o programa a validar for oseguinte:

...


process2(X,Y).

process2([],[]).

process2([nome(X),pais(Y),email(Z)|R1],[nome(X),telefone(Z)|R2]):-

process2(R1,R2).


process2(R1,R2).

Os tipos inferidos para este programa sao:

τ 1


process2)}

τ 2


process2)}

τ 1

process2 → {[], [nome(any), pais(any), email(any)|τ 1

process2],

[nome(any), pais(any)|τ 1

process2]}

τ 2

process2 → {[], [nome(any), telefone(any)|τ 2

process2]}

Neste caso os dados de saıda do nosso programa so sao validos face ao DTD declaradoinicialmente no caso do documento vazio. O nosso sistema produz um aviso e continuacom o processo de compilacao. Se o programa a validar for o seguinte:

...


process2(X,Y).

process2([],[]).

process2([nome(X),email(Y)|R1],[nome(X),email(Z)|R2]):-

process2(R1,R2).


process2(R1,R2).

Os tipos inferidos para este programa sao:

τ 1


process2)}

τ 2


process2)}

τ 1

process2 → {[], [nome(any), email(any)|τ 1

process2], [nome(any), pais(any)|τ 1

process2]}

τ 2

process2 → {[], [nome(any), telefone(any)|τ 2

process2]}

Neste caso os dados de entrada do nosso programa so sao validos no caso do documentovazio e o nosso sistema produz um aviso e continua com a compilacao do programa.

Suponhamos agora que estamos a tentar extrair informacao de um documento XMLque armazena informacao referente a um catalogo de livros. O ficheiro e o seguinte:

<catalogo>

<livro>

<titulo> The Art of Computer Programming - Volume 1</titulo>

<autor> D. Knuth </autor>

<ano> 1997 </ano>

<editora> Addison-Wesley </editora>

</livro>

<livro>

<titulo> Haskell - The Craft of Functional Programming</titulo>

<autor> Simon Thompson </autor>

<ano> 1999 </ano>

<editora> Addison-Wesley </editora>

</livro>

...

</catalogo>

O DTD que o valida e o seguinte:

<!ELEMENT catalogo (livro)+>

<!ELEMENT livro (titulo,autor,ano,editora)>

<!ELEMENT titulo (#PCDATA)>

<!ELEMENT autor (#PCDATA)>

<!ELEMENT ano (#PCDATA)>

<!ELEMENT editora (#PCDATA)>

Por vezes estamos interessados em obter um documento apenas com a informacaosobre o tıtulo e o ano de edicao de certos livros. Temos o DTD seguinte para estesdocumentos:

<!ELEMENT livro (titulo,ano)>



Podemos agora construir programas que nos traduzam documentos do primeiro DTDpara o segundo. Por exemplo, o programa seguinte destina-se a retirar informacaoapenas sobre os livros de D. Knuth:

prog(FileXML1,XMLTerm1,FileXML2,XMLTerm2):-

xml_to_prolog(FileXML1,’livros1.dtd’,XMLTerm1,TypeDTD1),

process(XMLTerm1,XMLTerm2),

prolog_to_xml(’livros3.dtd’,TypeDTD2,XMLTerm2,FileXML2).

process(catalogo([],L1),catalogo([],L2)):-

conversion(L1,L2).

conversion([livro(A,"D. Knuth",Z,_)],[livro(A,Z)]):-!.

conversion([livro(_,_,_,_)],[]).

conversion([livro(A,"D. Knuth",Z,_)|R1],[livro(A,Z)|R2]):-!,

conversion(R1,R2).

conversion([livro(_,_,_,_,_)|R1],R2):-

conversion(R1,R2).

O nosso sistema valida este programa, compila-o e permite a criacao do novo docu-mento:

<catalogo>

<livro>

<titulo> The Art of Computer Programming - Volume 1</titulo>

<ano> 1997 </ano>

</livro>

...

</catalogo>

Ja se o DTD de validacao dos dados de saıda for:


<!ELEMENT livro (titulo,ano,editora)>



<!ELEMENT editora (#PCDATA)>


O sistema detecta o erro, assinala um erro de tipos e nao compila o programa.

Capıtulo 6

Conclusao

Nesta dissertacao foi apresentado um sistema de processamento de XML em Pro-gramacao em Logica com validacao estatica de programas.

Dada a crescente utilizacao do XML como forma de organizacao de informacao foramdefinidas linguagens para processamento de documentos XML. Dado que as primeiraslinguagens (por exemplo, o XSLT) nao possuıam capacidades de validacao em tempode compilacao, surgiram linguagens novas especializadas no domınio do XML e capazesde validarem em tempo de compilacao os seus programas (por exemplo, o XDucee o HaXML). Neste trabalho adaptamos tecnicas desenvolvidas para estas novaslinguagens a Programacao em Logica e implementamos um sistema que permite usarprogramas em logica para processar XML com validacao estatica.

6.1 Trabalho futuro

Como continuacao do trabalho aqui apresentado sugerimos os seguintes pontos:

1. Prolog para processamento de XML: O algoritmo de inferencia de tipos queimplementamos funciona para programas definidos. O nosso proximo objectivoe estender a inferencia de tipos para Prolog completo.

2. Eficiencia: O algoritmo de inferencia de tipos e baseado no algoritmo descritopor Zobel em [Zob90]. Este algoritmo e indicado para uma primeira abordagema inferencia de tipos regulares em Programacao em Logica, uma vez que se baseiaem operacoes basicas como sendo a interseccao e a unificacao que simplificam asua compreensao. No entanto, existem abordagens mais eficientes a inferenciade tipos para a Programacao em Logica (por exemplo [GdW93]). A alteracaodo modulo de inferencia de tipos e um dos proximos objectivos.

3. Expressividade: Linguagens para a validacao de XML, dotadas duma maiorexpressividade estao agora a aparecer (por exemplo [XML00]). O estudo de lin-

105

106 CAPITULO 6. CONCLUSAO

guagens com sistemas de tipos capazes de tirarem partido destas novas propostasmerece um estudo aprofundado.

4. Representacao de XML: Os termos, embora naturais para o programador habi-tuado a programacao em logica, tem tambem inconvenientes na representacaode XML (como o tamanho daqueles que representam documentos enormes).Pensamos ser interessante pensar em alternativas para representar XML emprogramacao em logica. Ha ja algum trabalho apresentado em [BE00] que propoetermos flexıveis que contem apenas parte da informacao do documento XML querepresentam.

5. Linguagens com sistemas de tipos incorporados: As capacidades do nosso sistemapodem ser facilmente adaptadas a linguagens logicas com um sistema de tiposnativo (tal como o Mercury [Mer]), traduzindo os DTDs para os tipos dessalinguagem.

6.2 Consideracoes finais

Em ultima analise, pensamos que os objectivos por nos propostos foram cumpridos.Na nossa opiniao os termos Prolog que representam os documentos XML sao umaestrutura simples e confortavel para o programador habituado ao Prolog e mostramosque a inferencia de Tipos Regulares para Programacao em Logica pode ser usada comsucesso na validacao estatica de programas em logica para processar XML, face a tiposdefinidos por linguagens standard como os DTDs.

Referencias

[BE00] Francois Bry and Norbert Eisinger. Data modeling with markup languages:A logic programming perspective. In 15th Workshop on Logic Programmingand Constraint Systems, WLP 2000, Berlin, 2000.

[Bol00] H. Boley. Relationships between logic programming and XML. In Proc.14th Workshop Logische Programmierung, 2000.

[BS02] Francois Bry and Sebastian Schaffert. Towards a declarative query andtransformation language for XML and semistructured data: simulationunification. In Proc. of the 2002 International Conference on LogicProgramming, 2002.

[CF03] J. Coelho and M. Florido. Type-based XML Processing in Logic Program-ming. In Proceedings of the Fifth International Symposium on PracticalAspects of Declarative Languages (PADL’03), (aceite para publicacao), NewOrleans, USA, January 2003. Springer Verlag, LNCS.

[DOM] Document Object Model. World Wide Web, http://www.w3.org/DOM.

[DZ92] P. Dart and J. Zobel. A regular type language for logic programs. In FrankPfenning, editor, Types in Logic Programming. The MIT Press, 1992.

[FD92] M. Florido and L. Damas. Types as theories. In Proc. of post-conferenceworkshop on Proofs and Types, Joint International Conference and Sympo-sium on Logic Programming, 1992.

[GdW93] J.P. Gallagher and D.A. de Waal. Fast and precise regular approximationof logic programs. In Proceedings of the Eleventh International Conferenceon Logic Programming, 1993.

[Hog90] Christopher John Hogger. Essentials of Logic Programming. OxfordUniversity Press, 1990.

[HP00] Haruo Hosoya and Benjamin Pierce. Xduce: A typed XML processinglanguage. In Third International Workshop on the Web and Databases(WebDB2000), volume 1997 of Lecture Notes in Computer Science, 2000.

107

108 REFERENCIAS

[HTM] HyperText Markup Language. World Wide Web, http://www.w3.org/

MarkUp/.

[Llo87] J. W. Lloyd. Foundations of Logic Programming. Springer-Verlag, secondedition, 1987.

[Lu01] Lunjin Lu. On Dart-Zobel algorithm for testing regular type inclusion. InSIGPLAN Notices Volume 36, 2001.

[Mat] MathML. World Wide Web, http://www.w3.org/Math/.

[MCF] Meta Content Framework Using XML. World Wide Web, http://www.w3.org/TR/NOTE-MCF-XML/.

[Mer] The Mercury Programming Language. World Wide Web, http://www.cs.mu.oz.au/research/mercury/.

[Mis84] P. Mishra. Towards a theory of types in Prolog. In Proc. of the 1984International Symposium on Logic Programming, 1984.

[MSV00] T. Milo, D. Suciu, and V. Vianu. Typechecking for XML transformers. InACM Symposium on Principles of Database Systems, 2000.

[Nam] Namespaces. World Wide Web, http://www.w3.org/TR/REC-xml-names/.

[Pil] The PiLLoW Web Programming Library. World Wide Web, http://clip.dia.fi.upm.es/Software/pillow/pillow.html.

[RDF] Resource Descrition Framework. World Wide Web, http://www.w3.org/RDF/.

[SAX] Simple API for XML. World Wide Web, http://www.saxproject.org.

[SGM] Standard Generalized Markup Language. World Wide Web, http://www.w3.org/MarkUp/SGML/.

[SMI] Synchronized Multimedia. World Wide Web, http://www.w3.org/

AudioVideo/.

[SS94] Leon Sterling and Ehud Shapiro. The Art of Prolog, 2nd edition. The MITPress, 1994.

[Suc01] Dan Suciu. Typechecking for semistructured data. In InternationalWorkshop on Database Programming, 2001.

[SWI] SWI Prolog. World Wide Web, http://www.swi-prolog.org/.

[Tha73] J.W. Thatcher. Tree automata: An informal survey. Prentice-Hall, 1973.

[Tho99] Simon Thompson. Haskell The Craft of Functional Programming. AddisonWesley Longman Limited, second edition, 1999.

REFERENCIAS 109

[UTF] Unicode Transformation Format 8 bit. World Wide Web, http://www.

ietf.org/rfc/rfc2279.txt.

[VML] Vector Markup Language. World Wide Web, http://www.w3.org/TR/

NOTE-VML/.

[W3C] World Wide Web Consortium. World Wide Web, http://www.w3.org/.

[WR99] Malcom Wallace and Colin Runciman. Haskell and XML: Generic combina-tors or type-based translation? In International Conference on FunctionalProgramming, 1999.

[XML] Extensible Markup Language. World Wide Web, http://www.w3.org/XML/.

[XML98] XML-Data. World Wide Web, http://www.w3.org/TR/1998/

NOTE-XML-data-0105/, 1998.

[XML00] XML Schema. World Wide Web, http://www.w3.org/XML/Schema/, 2000.

[XPa] XPath. World Wide Web, http://www.w3.org/TR/xpath.

[XSL] The Extensible Stylesheet Language. World Wide Web, http://www.w3.

org/Style/XSL/.

[YFS92] E. Yardeni, T. Fruehwirth, and E. Shapiro. Polymorphic typed logicprograms. In Frank Pfenning, editor, Types in Logic Programming. TheMIT Press, 1992.

[YS90] E. Yardeni and E. Shapiro. A type system for logic programs. In TheJournal of Logic Programming, 1990.

[Zob87] Justin Zobel. Derivation of polymorphic types for prolog programs. In Proc.of the 1987 International Conference on Logic Programming, pages 817–838,1987.

[Zob90] Justin Zobel. Analysis of Logic Programs. PhD thesis, Department ofComputer Science, University of Melbourne, 1990.

jorge manuel neves coelho - ipp.ptjcoelho/tese.pdf · trabalhos e pelas reuni~oes semanais. tudo...

Documents