Anotação Estrutural de Documentos e Sua Semântica

Anotao Estrutural de Documentos e sua Semntica
Especicao da Sintaxe, Semntica e Estilo para Documentos

2000
Jos Carlos Leite Ramalho

Departamento de Informtica - Escola de Engenharia Universidade do Minho
Superviso: Pedro Rangel Henriques
Anotao Estrutural de Documentos e sua Semntica: Especicao da Sintaxe, Semntica e Estilo para Documentos por Jos Carlos Leite Ramalho e Superviso: Pedro Rangel Henriques
Este documento descreve o trabalho realizado no mbito da tese de doutoramento do autor. O trabalho teve duas grandes linhas orientadoras. A estruturao de documentos, como a maneira de os tornar mais "ricos"e mais "vivos". E, a semntica dos documentos, desde a aparncia visual at interpretao (signicado) do seu contedo. No m, estas duas linhas acabaram por convergir na elaborao dum novo modelo de processamento documental. Ao longo da dissertao, ir ser apresentada uma comparao de modelos de processamento documental, ou publicao electrnica; referir-se- o processamento dos documentos normais, que so apenas textos, e dos documentos anotados, que tm uma estrutura lgica e um contedo. Esta anlise ser ilustrada com alguns casos prticos que se desenvolveram ao longo deste trabalho. As vantagens dos documentos estruturados sero apresentadas e os passos para a implementao de um sistema de produo de documentos estruturados sero descritos. A seguir, apresentar-se- o conjunto de necessidades e requisitos actuais que se podem colocar a um sistema destes e analisar-se- aquilo que se designou por "semntica dos documentos". As necessidades identicadas esto relacionadas com o problema da qualidade de contedos na publicao electrnica. A qualidade em publicaes electrnicas pode ser analisada segundo vrios parmetros, desde o aspecto visual, o lingustico e literrio, correco da informao (signicado, semntica). A tecnologia existente permite de alguma forma automatizar e normalizar todos estes aspectos, excepto o ltimo. Foi no desenvolvimento de uma soluo para este problema que se centrou esta dissertao: como adicionar semntica esttica (condies contextuais ou invariantes) aos documentos; e como processar esta semntica esttica dum modo integrado com a tecnologia existente. So apresentadas duas vias para a soluo da especicao e processamento da semntica esttica, a primeira segue uma aproximao via modelos abstractos, a outra, uma aproximao via gramticas de atributos. No m, uma das solues ser escolhida e integrada num sistema (S4) que sugere um novo modelo de processamento para documentos estruturados e que explora alguns paradigmas novos neste contexto (adoptam-se para os documentos metodologias utilizadas nas linguagens de programao como consequncia duma hiptese levantada pelo autor, da existncia dum
paralelismo entre o processamento de documentos e o processamento das linguagens de programao), que vo desde a anlise da informao at ao seu tratamento. A dissertao inclui a apresentao dos passos seguidos na produo do seu prprio texto, uma vez que se adoptaram as solues defendidas e nela apresentadas.
Este documento foi submetido, pelo autor, Escola de Engenharia da Universidade do Minho para obteno do grau de Doutor. Os direitos de cpia do documento encontram-se reservados, portanto, instituio e autor do mesmo.
Dedicatria
minha famlia, a Carmen, o David, e o pequeno Leonardo, que toleraram as minhas ausncias e a minha obcesso durante um largo perodo de tempo.
ndice
Agradecimentos...................................................................................................... 14 1. Introduo .......................................................................................................... 15 1.1. A Tese ....................................................................................................... 17 1.2. Estrutura da Dissertao ........................................................................... 18 2. Notaes e Formalismos utilizados................................................................... 21 2.1. CAMILA: uma pequena introduo ......................................................... 21 2.2. Gramticas de Atributos ........................................................................... 25 2.2.1. Clculo de Atributos ...................................................................... 27 2.2.2. Synthesizer Generator (SGen) ....................................................... 28 3. Documentao Estruturada .............................................................................. 31 3.1. Anotao ................................................................................................... 32 3.1.1. Anotao Procedimental ................................................................ 33 3.1.2. Anotao Descritiva ....................................................................... 35 3.1.3. Linguagens de Anotao................................................................ 36 3.1.4. Formatao e/ou Estrutura? ........................................................... 37 3.1.4.1. Anotao orientada ao formato........................................... 37 3.1.4.2. Anotao orientada estrutura............................................ 38 3.1.4.3. Anotao orientada ao contedo......................................... 39 3.1.4.4. Uma anotao equilibrada................................................... 39 3.2. Documentos e Linguagens de Anotao................................................... 40 3.2.1. Evoluo ........................................................................................ 41 3.2.2. O Sentido Ecumnico do HTML ................................................... 42 4. SGML - ISO8879 ............................................................................................... 44 4.1. Documentos SGML .................................................................................. 44 4.2. Arquitectura de um sistema SGML .......................................................... 47 4.2.1. Textos SGML................................................................................. 48 4.2.2. Um ou mais DTDs ......................................................................... 49 4.2.3. Um parser....................................................................................... 49 4.2.4. Um sistema de processamento ....................................................... 50 4.3. Componentes dum Documento SGML..................................................... 51 4.3.1. Prlogo........................................................................................... 51 4.3.2. DTD ............................................................................................... 53 4.3.2.1. Elementos............................................................................ 55
4.3.2.1.1. lgebra do Contedo ............................................... 56 4.3.2.1.1.1. Operadores de Conexo ................................ 56 4.3.2.1.1.2. Operadores de Ocorrncia............................. 57 4.3.2.1.2. Excepes ................................................................ 58 4.3.2.2. Atributos ............................................................................. 60 4.3.2.3. Entidades............................................................................. 63 4.3.2.3.1. Conceitos.................................................................. 64 4.3.2.3.2. Entidades Gerais ...................................................... 66 4.3.2.3.3. Entidades caracter .................................................... 67 4.3.2.3.4. Entidades externas ................................................... 68 4.3.2.3.5. Entidades paramtricas ............................................ 71 4.3.2.4. Instrues de Processamento .............................................. 71 4.3.3. Instncia ......................................................................................... 72 5. O Ciclo de Desenvolvimento dos Documentos SGML .................................... 74 5.1. Anlise Documental.................................................................................. 74 5.1.1. Determinao da rea de aplicao................................................ 76 5.1.2. Denio de uma estratgia para o DTD....................................... 77 5.1.3. Identicao dos utilizadores......................................................... 77 5.1.4. O nome do DTD............................................................................. 77 5.1.5. Os elementos lgicos do DTD ....................................................... 78 5.1.6. Elemento ou atributo? .................................................................... 79 5.1.7. Determinao da estrutura hierrquica .......................................... 81 5.1.8. Diagramas de Estrutura.................................................................. 82 5.2. Edio de Documentos SGML ................................................................. 88 5.3. Validao................................................................................................... 89 5.4. Estilo e especicao da Forma ................................................................ 93 5.5. Formatao e Transformao.................................................................... 93 5.6. Armazenamento ........................................................................................ 95 6. Documentos e Semntica................................................................................... 99 6.1. Documentos e Programas ....................................................................... 100 6.2. Semntica Dinmica: o DSSSL .............................................................. 101 6.2.1. Componentes funcionais de especicao................................... 103 6.2.2. Modelo Conceptual...................................................................... 104 6.2.3. Linguagem de Transformao ..................................................... 105 6.2.4. O Processo de Transformao...................................................... 106 6.2.4.1. Construo do Grove ........................................................ 107
6.2.4.2. Transformao .................................................................. 109 6.2.4.3. Gerao de SGML ............................................................ 111 6.2.5. Linguagem de Estilo .................................................................... 111 6.2.5.1. Estrutura das Regras de Construo ................................. 112 6.2.6. O Processo de Formatao........................................................... 115 6.2.7. Algumas especicaes exemplo................................................. 116 7. Validao Semntica em Documentos SGML ............................................... 122 7.1. Semntica Esttica .................................................................................. 122 7.1.1. Qual o problema? ...................................................................... 122 7.1.1.1. Registos Paroquiais ........................................................... 123 7.1.1.2. Arqueologia....................................................................... 124 7.1.2. Restries e condies de contexto.............................................. 125 8. Validao Semntica com Modelos Abstractos ............................................. 134 8.1. Modelos Abstractos: porqu? ................................................................. 134 8.2. Linguagem de Restries........................................................................ 139 8.3. Associao de Restries aos Elementos................................................ 142 8.4. Processamento das Restries................................................................. 145 8.4.1. Implementao............................................................................. 148 9. Validao Semntica com Gramticas de Atributos..................................... 151 9.1. Aproximao via gramticas de atributos............................................... 151 9.2. O sistema S4 ........................................................................................... 157 9.2.1. Arquitectura do S4 ....................................................................... 159 9.2.1.1. Editor de DTDs com Restries ....................................... 161 9.2.1.1.1. Um sistema noticioso automtico .......................... 163 9.2.1.2. Editor de Estilo ................................................................. 169 9.2.2. Linguagem de Restries............................................................. 170 9.2.2.1. Escolha da linguagem ....................................................... 175 9.2.2.1.1. Padres e Contexto................................................. 176 9.2.2.1.2. Quanticador: todos............................................... 177 9.2.2.1.3. Atributos ................................................................ 178 9.2.2.1.4. Filtro - sub-query ................................................... 178 9.2.2.1.5. Expresses booleanas............................................. 180 9.2.2.1.6. Equivalncia........................................................... 181 9.2.2.2. Denio da linguagem de restries ............................... 182 9.2.2.3. Aplicao aos casos de estudo apresentados .................... 191 9.2.2.4. Estado actual do S4........................................................... 193
10. Concluso........................................................................................................ 195 10.1. Trabalho Futuro..................................................................................... 197 A. Como foi produzida esta tese ......................................................................... 198 A.1. O DTD.................................................................................................... 198 A.2. O Editor.................................................................................................. 201 A.3. O Formatador ......................................................................................... 204 A.4. A organizao da tese em mdulos........................................................ 208 A.5. Resultados gerados................................................................................. 211 B. Projectos desenvolvidos................................................................................... 213 B.1. Publicao Electrnica ........................................................................... 213 B.1.1. Publicao na Internet das "Memrias Particulares de Incio Jos Peixoto".......................................................................................... 213 B.1.2. Publicao na Internet do "Index das Gavetas do Cabido da S de Braga" ............................................................................................ 214 B.1.3. Publicao na Internet do Livro "Ensaio Sobre as Minas de Joze Anastacio da Cunha"...................................................................... 214 B.2. Recuperao de edies esgotadas......................................................... 216 B.2.1. Recuperao do livro "ndice da gaveta das Cartas"................... 216 B.2.2. Recuperao do livro "Inventrio da gaveta das Visitas e Devassas" 217 B.3. Outros Projectos ..................................................................................... 217 C. Converso de DTDs para Gramticas........................................................... 219 C.1. Regras gerais .......................................................................................... 219 C.1.1. Elemento genrico....................................................................... 220 C.1.2. Elemento sem atributos ............................................................... 220 C.1.3. Elemento com contedo #PCDATA ............................................ 220 C.1.4. Elemento denido como um grupo - () ....................................... 221 C.2. Converso de declaraes de elementos................................................. 222 C.2.1. Elemento com estrutura singular................................................. 222 C.2.2. Operador de ocorrncia zerone ................................................... 223 C.2.3. Operador de ocorrncia zeron ..................................................... 224 C.2.4. Operador de ocorrncia onen ...................................................... 225 C.2.5. Operador de conexo seq (sequncia) ......................................... 226 C.2.6. Operador de conexo or (alternativa) .......................................... 226 C.3. Regras para os atributos ......................................................................... 227 C.3.1. Elemento com atributos............................................................... 227
C.3.2. Atributo do tipo enumerado ........................................................ 229 C.3.3. Atributo do tipo CDATA ............................................................. 230 C.3.4. Atributo do tipo NUMERICAL .................................................. 230 C.3.5. Atributo do tipo ID ...................................................................... 231 C.3.6. Atributo do tipo IDREF............................................................... 231 C.3.7. Atributo do tipo ENTITY............................................................ 232 C.3.8. Atributo denido com o valor #IMPLIED .................................. 232 C.3.9. Atributo denido com o valor #REQUIRED .............................. 232 C.3.10. Atributo denido com o valor #FIXED .................................... 233 C.3.11. Atributo denido com o valor #CURRENT.............................. 233 C.4. Regras de converso para entidades ....................................................... 234 C.4.1. Entidades ..................................................................................... 234 C.5. Uma converso passo a passo................................................................. 235 D. Futuros standards relacionados com SGML................................................ 238 D.1. Extensible Markup Language (XML) 1.0.............................................. 240 D.1.1. O Passado.................................................................................... 240 D.1.2. Porqu XML?.............................................................................. 241 D.1.3. XML: caractersticas ................................................................... 242 D.1.3.1. Vlido versus Bem-Estruturado ....................................... 243 D.2. Document Object Model (DOM)........................................................... 245 D.3. CSS e XSL ............................................................................................. 246 D.3.1. Cascading Style Sheets (CSS)..................................................... 247 D.3.1.1. Cascading Style Sheets Level 2 (CSS2)........................... 248 D.3.1.1.1. Especicao de Estilo.......................................... 248 D.3.1.1.2. Associar uma Especicao de Estilo................... 249 D.3.2. Extensible Stylesheet Language (XSL) ...................................... 249 D.3.2.1. Anatomia de uma folha de estilo XSL ............................. 250 D.4. Extensible Linking Language (XLL) e Extended Pointers (XPointer).. 252 D.5. NameSpaces in XML (XML Namespace) ............................................. 253 D.6. Vector Markup Language....................................................................... 254 D.7. Simplied Markup Language - SML ..................................................... 255 Bibliograa ........................................................................................................... 257
Lista de Tabelas
2-1. Tipos Abstractos de Dados e CAMILA............................................................ 21 2-2. Funes Finitas: X Y ................................................................................... 24 2-3. Sequncias: X-seq............................................................................................. 24 4-1. Tipos de Atributo .............................................................................................. 61 4-2. Valores por omisso.......................................................................................... 62 6-1. Documentos e Programas ............................................................................... 100 8-1. Esquema de Traduo SGML CAMILA................................................... 137 9-1. Esquema de Traduo SGML Gramticas de Atributos............................ 153 C-1. Valores por omisso de Atributos .................................................................. 227 D-1. Domnios de aco......................................................................................... 239 D-2. CSS versus XSL ............................................................................................ 246
Lista de Figuras
4-1. Estrutura do texto anotado................................................................................ 45 4-2. Arquitectura dum sistema SGML..................................................................... 48 4-3. Estrutura Fsica de um documento ................................................................... 64 4-4. Os vrios tipos de entidades ............................................................................. 66 5-1. Ciclo de desenvolvimento dos documentos SGML.......................................... 74 5-2. Estrutura hierrquica do memorandum ............................................................ 81 5-3. Travessia da rvore ........................................................................................... 82 5-18. ELM-tree do Memorandum............................................................................ 88 6-1. DSSSL - modelo conceptual........................................................................... 103 6-2. DSSSL - processo de transformao .............................................................. 106 6-3. DSSSL - processo de formatao ................................................................... 116 7-1. Edio baseada em SGML ............................................................................. 122 8-1. Novo Modelo para Processamento de Documentos SGML ........................... 134 8-2. O Novo Componente de Validao CAMILA............................................. 145 9-1. S4 - os conceitos ............................................................................................. 157 9-2. S4 - Ambiente para Programao de Documentos......................................... 159 9-3. S4 - Estrutura interna...................................................................................... 160 9-4. Arquitectura funcional dum editor estruturado .............................................. 170
10
Lista de Exemplos
2-1. Especicao do modelo Stack ........................................................................ 23 3-1. Uma carta anotada ............................................................................................ 34 3-2. Texto anotado em TeX...................................................................................... 34 3-3. Texto anotado de uma carta .............................................................................. 35 3-4. Anotao orientada ao formato......................................................................... 38 3-5. Anotao orientada estrutura ......................................................................... 38 3-6. Anotao orientada ao contedo....................................................................... 39 4-1. Documento anotado em SGML........................................................................ 44 4-2. Um Prlogo SGML .......................................................................................... 52 4-3. DTD para uma carta ......................................................................................... 54 4-4. Incluso............................................................................................................. 58 4-5. Excluso............................................................................................................ 59 4-6. Atributos - tipos e valores................................................................................. 63 4-7. Declarao de uma entidade geral .................................................................... 66 4-8. Referncia a uma entidade geral....................................................................... 67 4-9. Entidades gerais utilizadas na escrita da tese ................................................... 67 4-10. Referncia a uma entidade caracter ................................................................ 68 4-11. Declarao de uma entidade externa .............................................................. 68 4-12. Identicadores pblicos e o Catlogo............................................................. 69 4-13. Referncia a uma entidade externa ................................................................. 70 4-14. Entidades externas e escrita modular de documentos .................................... 70 4-15. Entidades Paramtricas................................................................................... 71 4-16. Instruao de Processamento............................................................................ 72 4-17. Instncia de CARTA ....................................................................................... 73 5-1. A Inexistncia de uma estrutura nica.............................................................. 75 5-2. Memorandum (SGML)..................................................................................... 78 5-3. Elemento ou Atributo?...................................................................................... 79 5-4. DTD correpondente aos DEs do Memorandum ............................................... 87 5-5. Memorandum em formato ESIS....................................................................... 90 6-1. Grove - estrutura para manipulao de documentos SGML .......................... 107 6-2. A Transformao identidade........................................................................... 109 6-3. Regra associada ao documento....................................................................... 113 6-4. Regra associada a todos os elementos no documento original ....................... 113 6-5. Regra associada a uma classe de elementos ................................................... 114
11
6-6. Regra associada a um elemento especco identicado por um atributo do tipo ID ................................................................................................................... 114 6-7. Regra associada a uma query ....................................................................... 114 6-8. Especicao de Estilo bsica ........................................................................ 117 6-9. Adicionando margens ..................................................................................... 117 6-10. Formatando os ttulos ................................................................................... 118 6-11. Adicionando variveis para facilitar a manuteno...................................... 118 6-12. Utilizando mais de uma passagem sobre o documento ................................ 119 7-1. SGML com restries..................................................................................... 126 7-2. Normalizao via adio dum atributo ........................................................... 127 7-3. Atributos "#FIXED" ....................................................................................... 129 7-4. Uma rvore binria ......................................................................................... 131 8-1. Literate Programming..................................................................................... 135 8-2. Reis e Decretos ............................................................................................... 140 8-6. Dum DTD para CAMILA .............................................................................. 149 9-1. GIC derivada do DTD de Literate Programming ........................................... 153 9-2. O DTD da Notcia........................................................................................... 164 9-3. Gramtica Independente de Contexto para a Notcia ..................................... 165 9-4. Converso da primeira restrio semntica da Notcia................................... 166 9-5. Converso da segunda restrio semntica da Notcia ................................... 168 9-6. Query simples ................................................................................................. 173 9-7. Query mais complexa ..................................................................................... 174 9-8. Seleco de contextos..................................................................................... 176 9-9. Seleco com "*"............................................................................................ 177 9-10. Seleco com atributos ................................................................................. 178 9-11. Sub-query...................................................................................................... 179 9-12. Operadores booleanos................................................................................... 180 9-13. Equivalncia ................................................................................................. 181 C-1. Elemento Titulo sem atributos ....................................................................... 220 C-2. Elemento com contedo #PCDATA............................................................... 221 C-3. Operador de conexo seq ............................................................................... 226 C-4. Elemento News com atributos ....................................................................... 229 C-5. Atributo do tipo enumerado ........................................................................... 230 C-6. Uma converso: DTD GA......................................................................... 235 D-1. Um documento bem estruturado.................................................................... 243 D-2. Um documento vlido.................................................................................... 244 D-3. Especicao de estilo para um elemento ..................................................... 247
12
D-4. Documento XML........................................................................................... 248 D-5. curso.css......................................................................................................... 249 D-6. Esqueleto de uma folha de estilo XSL........................................................... 251 D-7. Regra de construo....................................................................................... 251 D-8. XPointer......................................................................................................... 253 D-9. XML NameSpaces......................................................................................... 253
13
Agradecimentos
Em primeiro lugar, gostaria de agradecer ao meu supervisor, o Professor Pedro Henriques, pela superviso omnipresente e, mais importante ainda, a constante disponibilidade em discutir, analisar e reler resultados, permitindo um desfecho mais rpido e rico em termos de ideias. Ao meu colega, Jos Joo, pelas discusses e parcerias donde resultaram ideias inovadoras, algumas delas concretizadas em ferramentas e publicaes. Aos meus co-autores, durante os ltimos quatro anos, que colaboraram comigo na publicao de vrios artigos e outras monograas: Pedro Henriques, Jos Joo, Jorge Rocha, Alda Lopes. Alda Lopes e ao Pedro Sousa o terem aceite fazer as suas teses de mestrado comigo. O seu trabalho deu um empurro precioso na parte prtica desta tese. Aos alunos nalistas que comigo colaboraram na realizao de vrios projectos reais, dando-me o contacto com a realidade que to necessrio foi para a elaborao de algumas ideias: Nuno Figueiredo, Paulo Carvalho, Rogrio Paiva, Salom Ribeiro, Snia Gaspar, Carla Lopes, Clara Oliveira, Armando Lemos, Jos Henrique Cerqueira, Antnio Pedro Lopes. Ao Norman Walsh, a prontido com que sempre me acudiu na resoluo de problemas com as stylesheets do Docbook. Ao Sebastian Rahtz, a pacincia que teve para comigo instalarmos o ambiente denitivo com que viria a ser produzida esta dissertao.
14
Captulo 1. Introduo
Se observarmos de perto uma empresa, um establecimento de ensino, ou outra instituio pblica ou privada, depressa conclumos que o produto de cada dia de trabalho resulta, directa ou indirectamente, na criao de documentos; cada membro de uma organizao, na sua actividade diria, cria de alguma forma documentao. Pode ser uma carta, um memo, a planta de um edifcio ou o manual de um produto. Quaisquer que sejam os documentos produzidos eles formam parte da histria da instituio e so um importante componente da sua memria corporativa. Algumas formas de informao so altamente estruturadas. De facto, algumas so to estruturadas que permitem a sua representao numa forma tabular ou numrica. Informao sobre inventrios, preos, empregados, um exemplo deste tipo de informao. Hoje em dia, a maioria dos sistemas de gesto corporativa so desenhados para gerir informao relacional e muito estruturada (folhas de clculo, BDs). Mas, surpreendentemente, estima-se que esta informao representa apenas 10% do total de informao disponvel numa empresa. Assim surgem as seguintes questes: Que tipo de informao representa os outros 90%? Como se poder tirar partido dela? Estes 90% da informao correspondem a textos que so produzidos e circulam dentro da instituio. As metodologias relacionais so difceis ou mesmo impossveis de aplicar a texto. Pode-se ento colocar a questo: Haver alguma maneira de aceder ao potencial da informao mantida num formato textual? Se ele se mantiver numa forma simples, puramente sequencial, a soluo parece difcil; a resposta recai, mais uma vez, na estruturao desses textos [Ken96]. Documentos estruturados so documentos que tm a sua estrutura explcita, as suas componentes esto identicadas. Se esta estrutura fr denida formalmente, identicando as componentes e a maneira de a partir delas se construir o documento, torna-se possvel estipular um conjunto de regras para a criao desses documentos. Por exemplo, as regras para um determinado manual podem estipular que o documento ter uma pgina de rosto, um ndice, e um prefcio; esta parte inicial dever ser continuada por no mnimo quatro captulos; cada captulo dever ter um ttulo seguido de texto ou ter ainda esse texto dividido em seces. Essas seces podero ter tambm a sua estrutura, e assim por diante. A maioria dos textos produzidos numa empresa so estruturados ou no estruturados? A probabilidade de eles terem sido produzidos de acordo com um
15
Captulo 1. Introduo
conjunto regras da empresa muito grande. Isto faz com que eles tenham uma estrutura que lhes inerente, o que no quer dizer que essa organizao seja explcita. Este problema, de tentar manter viva a informao correspondente aos 90% do patrimnio duma instituio d-nos a primeira motivao para este trabalho. O segundo mote, vem duma rea relacionada: a publicao electrnica. Nas ltimas dcadas, a Publicao Electrnica sofreu uma enorme evoluo. O avanar da informtica e das tecnologias a ela associadas tem levado a uma substituio gradual e efectiva do papel pelo suporte digital, magntico ou ptico (disquete, disco de computador, ou CDROM). Nos ltimos anos, a exploso da Internet (cada vez mais fcil e amplamente acessvel), veio acelerar e aumentar ainda mais a produo documental em suporte digital, consolidando novos tipos e arquitecturas de informao: o hipertexto e a hipermedia [DD94]. Esta evoluo trouxe com ela vrios problemas e veio agravar outros j existentes. O mais grave foi, e , o da proliferao de formatos proprietrios e a incompatibilidade de cada um deles face aos outros. Com a Internet e a banalizao da produo de CDROMs, para alm dos vrios sistemas tradicionais de arquivo e processamento de texto, os utilizadores passam a precisar de manter os seus documentos em mais formatos e suportes. Um documento leva tempo a produzir, consome espao de arquivo pelo que, se a sua reutilizao no fr possvel, o seu custo aumentar ainda mais. Por estas razes, a produo documental deve ser inteligente, de modo a que os documentos produzidos se mantenham vivos (ao m de vrios anos, em diferentes sistemas e depois de vrias verses do software que os produziu) e que a sua reutilizao, para os mais variados ns, seja possvel. Outro problema prende-se com a globalizao da informao. Hoje a Internet praticamente acessvel a todos, tendo-se tornado um veculo apetecvel para quem disponibiliza e para quem consome informao. Como resultado temos uma maior proliferao documental. Torna-se praticamente invivel colocar documentos puramente textuais na Internet. Os motores de pesquisa e de indexao teriam um trabalho innito para procurar e encontrar fosse o que fosse. Neste contexto surgiram projectos como o "Dublin Core"[Hee96] ou o "TEI"[SB94] que visam resolver estes problema acrescentando meta-informao aos documentos. Meta-informao informao sobre informao [Cap95], neste caso sobre documentos. Mais especicamente, trata-se duma espcie de registo bibliogrco
16
Captulo 1. Introduo
que se agrega a um documento de modo a disponibilizar facilmente informao como a data da sua criao, quem so os seus autores e at mesmo, uma memria descritiva do seu contedo. Quando se fala de documentos e meta-informao, o "Dublin Core" quase uma referncia obrigatria. Isto resulta do facto de ter sido denido numa workshop que reuniu os especialistas nos mais variados ramos da informtica e da meta-informao [WGMD]. No entanto, esta proposta de standard visa resolver apenas uma pequena parte do problema, o da localizao de documentos na Internet. No se preocupa com o seu contedo ou a sua estruturao, nem com a uniformizao de formatos uma vez que aceita quase tudo desde Postscript [POSTSCRIPT] a SGML [Gol90]. Recentemente, uma das reas que tem registado signicativos contributos e que muito tem evoludo a da representao abstracta de documentos, ou de objectos com a forma de documento. Aqui os problemas comeam logo pela denio de documento. Para algumas pessoas um documento apenas um registo textual enquanto para outras pode ser muita coisa desde texto at um ser vivo. O esforo para normalizar tem sido enorme e standards como o SGML [Her94], o Hytime [DD94], o XML [XML], e propostas como o DOM [DOM] e o RDF [Bray98] esto a tornar-se familiares para muita gente e esto a ser seguidos e implementados pela indstria. A Internet foi a grande responsvel pelas recentes evolues registadas na publicao electrnica e no conceito de documento e documento estruturado. Mais frente, traaremos o percurso dessa evoluo, desde as suas razes at aos dias de hoje. Resumindo, pretende-se analisar a tecnologia deste ramo de aplicao e ver de que modo possvel a sua aplicao no mbito institucional de modo a tornar vivel o acesso inteligente a toda a documentao produzida. Por outro lado, interessa-nos tambm, ver at que ponto a tecnologia associada aos documentos estruturados pode ajudar a melhorar, normalizar e automatizar a publicao electrnica. Aqui, interessa-nos, especialmente, o control de qualidade na vertente associada correco de contedos.
1.1. A Tese
Face s duas grandes linhas de motivao apresentadas, a existncia dum vasto
17
Captulo 1. Introduo
patrimnio documental que urgente tornar acessvel e, a melhoria do processo de publicao electrnica, a tese do autor a de que a soluo para estes dois grandes problemas passa pela utilizao da tecnologia associada aos documentos estruturados. Em muitos casos, a aplicao desta tecnologia resolve apenas parcialmente o problema e noutros, levanta novos problemas. aqui que surgem os contributos do autor que demonstra conseguir resolver alguns problemas recorrendo especicao da semntica esttica. Contribui tambm com outras solues para outros problemas mais pequenos como a normalizao de contedos e a associao de tipos de dados a contedos. So apresentadas duas vias para a soluo da especicao e processamento da semntica esttica, a primeira segue uma aproximao via modelos abstractos, a outra, uma aproximao via gramticas de atributos. No m, uma das solues ser escolhida e integrada num sistema que sugere um novo modelo de processamento para documentos estruturados e que explora alguns paradigmas novos neste contexto (adoptam-se para os documentos metodologias utilizadas nas linguagens de programao como consequncia duma hiptese levantada pelo autor, da existncia dum paralelismo entre o processamento de documentos e o processamento das linguagens de programao), que vo desde a anlise da informao at ao seu tratamento. Este novo modelo de processamento, tambm enriquecido com uma nova linguagem, denida pelo autor, para a especicao de semntica esttica. A dissertao inclui a apresentao dos passos seguidos na produo do seu prprio texto, uma vez que se adoptaram as solues defendidas e nela apresentadas, e termina com a apresentao do S4, o sistema de processamento documental que integra e implementa as ideias defendidas ao longo da dissertao.
1.2. Estrutura da Dissertao

Esta dissertao pode ser dividida em duas grandes partes. Na primeira, apresenta-se um estudo da tecnologia existente para trabalhar com documentos estruturados. Na segunda, analisa-se a aplicao da tecnologia a alguns casos reais; identicam-se alguns problemas; e, por m, propem-se solues para a resoluo dessas situaes.
18
Captulo 1. Introduo
Assim, a primeira parte comea por um captulo (Captulo 3) onde se expem os conceitos subjacentes aos documentos estruturados: contedo e anotao, linguagem de anotao. A seguir surge um dos captulos basilares da dissertao (Captulo 4), onde se apresenta um estudo do SGML, o standard para a denio de linguagens de anotao e criao de documentos estruturados. No captulo seguinte (Captulo 5), apresenta-se o ciclo de vida dos documentos estruturados, identicando para cada etapa o estado actual de desenvolvimento e utilizao. Esta primeira parte, termina no captulo onde se comea a discutir a semntica (Captulo 6). Existe um standard (DSSSL - [Cla96]) para a especicao da semntica dinmica que aqui descrito em detalhe. Porm, relativamente especicao da semntica esttica existe o vazio. Excepto alguns invariantes estruturais nativos no SGML, no h nenhuma forma de especicar condies de contexto, ou invariantes, para documentos estruturados. Como aqui j estamos a entrar na parte inovadora desta tese, este assunto passou para o captulo seguinte (Captulo 7), onde comea a segunda parte lgica da tese. A segunda parte inicia-se, portanto, num captulo onde se discute a especicao da semntica esttica. Nessa discusso surgem dois problemas para os quais se apontam solues: como garantir a normalizao de contedos; e como associar um tipo de dados ao contedo. Nos dois captulos seguintes, parte-se para duas solues de implementao. No primeiro (Captulo 8), utiliza-se uma abordagem via modelos abstractos e usa-se o ambiente de prototipagem CAMILA para testar a viabilidade da soluo. No segundo, utilizam-se gramticas de atributos como abordagem ao problema e usa-se um ambiente de gerao de compiladores para implementar a soluo. Antes dessas duas partes centrais, inclui-se alguma informao sobre formalismos e notao utilizados na dissertao (Captulo 2). Por m, a dissertao termina com um captulo de concluses onde so includos apontadores para trabalho futuro. A dissertao possui ainda quatro apndices. O primeiro descreve a produo da prpria dissertao, processo em que se utilizaram a maior parte das metodologias descritas e defendidas ao longo da mesma. O segundo, enumera e descreve sucintamente alguns dos projectos reais onde foram testadas as ideias defendidas nesta dissertao, e que muito contriburam para enriquecer a viso prtica que o autor agora tem do assunto. O terceiro quase que acaba por ser um documento destacvel, enumera e descreve um conjunto de regras desenvolvidas ao longo desta
19
Captulo 1. Introduo
dissertao para a converso de DTDs em Gramticas de Atributos. Por m, inclui-se um quarto apndice dedicado s novidades que esto a surgir: descrevem-se algumas propostas de standards que podero revolucionar o mundo dos documentos estruturados e, como efeito lateral, a disponibilizao de contedos na Internet.
20
Captulo 2. Notaes e Formalismos utilizados

Ao longo desta tese, faz-se o estudo duma rea (processamento de documentos) e identica-se um problema em particular (semntica esttica dos documentos). Para a resoluo desse problema seguem-se duas abordagens, cada uma delas suportada por um formalismo, nomeadamente: CAMILA (abordagem algbrica no Captulo 8); e Gramticas de Atributos (abordagem gramatical, no Captulo 9). Para facilitar a discusso apresentada nesses captulos e outras referncias ao longo da dissertao, optou-se por introduzir brevemente os referidos formalismos (conceitos bsicos e notao) no presente captulo: CAMILA (Seco 2.1); e Gramticas de Atributos (Seco 2.2).
2.1. CAMILA: uma pequena introduo

CAMILA uma linguagem formal de especicao funcional orientada por modelos algbricos que serve de suporte a um ambiente de prototipagem com o mesmo nome [ABNO97]. Uma especicao CAMILA um conjunto de componentes de software. Cada um destes um modelo composto por um tipo abstracto de dados e por denies de funes e de estado [BA95]. A estrutura geral de um modelo a seguinte:
Modelo MODEL identificador DefTipo DefFunc DefEstado ENDMODEL
Em que a denio de tipo tem a seguinte forma:

DefTipo TYPE (id = Tipo)* ENDTYPE
21
Os tipos bsicos do CAMILA so apresentados na tabela seguinte, Tabela 2-1. Tabela 2-1. Tipos Abstractos de Dados e CAMILA Tipos Abstractos Conjuntos Listas Funes Finitas Relaes Binrias Unio Disjunta tuplos Inteiros Strings Tokens Universo Notao CAMILA X-set X-seq XY XY X|Y T = X : A; Y : B INT STR SYM ANY
Para alm destes tipos, o CAMILA tem mais alguns tipos primitivos que no tm uma correspondncia matemtica directa mas que so inerentes ao seu ambiente de programao. Na denio seguinte apresenta-se a forma genrica da denio de uma funo em CAMILA. Denio: uma funo em CAMILA
DefFunc FHeader FPreCond FState FBody
FHeader FPreCond FState FBody FUNC fid (ParamLst) : typeid PRE CondExp STATE exp RETURNS Exp
Por m, a denio de um estado faz-se como se mostra a seguir. Denio: um estado em CAMILA
DefEstado STATE sid : typeid
Para exemplicar estes conceitos apresenta-se o exemplo seguinte:
22
Exemplo 2-1. Especicao do modelo Stack Pretende-se especicar o modelo da stack tradicional. A declarao dos tipos e do estado so:
; ------- SORTS ------------TYPE X = STR; Stack = X-list; ENDTYPE ; ------- STATE ------------STATE S : Stack;
As funes normais sobre uma stack especicam-se, ento, da seguinte maneira:

; ------- FUNCTIONS ----------FUNC push(x:X,s:Stack):Stack RETURN cons(x,s); FUNC top(s:Stack):X PRE s != <> RETURN head(s); FUNC pop(s:Stack):Stack PRE s != <> RETURN tail(s);
Como se pode ver esta verso puramente funcional, no tem efeitos laterais. As mesmas funes mas agora com os efeitos laterais que provocam alteraes no estado, especicam-se da seguinte maneira:
; ------- EVENTS ------------FUNC INIT(): STATE S <- <>; FUNC PUSH(x:X): STATE S <- push(x,S); FUNC POP():X PRE S != <>
23
RETURN head(S) STATE S <- tail(S); FUNC TOP():X PRE S != <> RETURN head(S);
A cada tipo CAMILA est associada uma coleco de funes bsicas que permitem manusear os valores desse tipo (construir, seleccionar, converter, transformar). Alm disso, tambm esto pr-denidas as conectivas proposicionais e os quantiadores. Para exemplicar estes operadores, apresentam-se duas tabelas com um resumo das duas coleces de operadores mais usadas ao longo da tese: os operadores para funes nitas; e para sequncias. Em cada tabela apresenta-se a sintaxe CAMILA, uma breve descrio informal e a correspondente notao na teoria de Sets. Tabela 2-2. Funes Finitas: X Y CAMILA dom(f) ran(f) f[x] f/s f\s Tabela 2-3. Sequncias: X-seq CAMILA hd(s) tl(s) nth(i,s) s^r <x:s> Descrio Head Tail Seleco do isimo elemento Concatenao Insero dum elemento cabea Descrio Domnio Contra-domnio Aplicao Restrio de domnio Subtraco de domnios
24
CAMILA elems(s) inds(s)
Descrio Conjunto dos elementos Domnio
As especicaes CAMILA podem ser animadas no ambiente de prototipagem designado pelo mesmo nome, CAMILA. Desta maneira, possvel vericar a adequao da especicao ao problema que se est a resolver.
2.2. Gramticas de Atributos

Uma gramtica de atributos um formalismo muito divulgado e utilizado pela comunidade dos compiladores para especicar a sintaxe e a semntica das linguagens [Hen92]. Introduzidas por Knuth [Knu68], as gramticas de atributos surgiram como uma extenso das gramticas independentes de contexto (GIC), permitindo a denio local (sem a utilizao de variveis globais) do signicado de cada smbolo num estilo declarativo. Os smbolos terminais tm atributos intrnsecos (que descrevem a informao lxica a cada um deles associada). Por outro lado, os smbolos no-terminais so associados com atributos genricos, atravs dos quais se poder sintetizar informao semntica (subindo na rvore, das folhas para a raiz), ou herdar informao semntica (descendo na rvore, do topo para as folhas), permitindo referncias explcitas a dependncias de contexto. Seja G, uma gramtica independente de contexto denida como um tuplo G=<T ,N ,S,P>, onde:

T representa o conjunto de smbolos terminais (o alfabeto). N o conjunto de smbolos no-terminais. S o smbolo inicial, ou axioma: S N . P o conjunto de produes, ou regras de derivao, cada uma com a forma:
A , A N e (T U N )*
que representaremos neste documento como:
25
X 0 X 1 X 2 ... X n
Para cada regra de derivao p P existe uma rvore de sintaxe cuja raz X 0, o no-terminal do lado esquerdo, e os seus n descendentes so os X i com n i 1, correspondentes aos smbolos do lado direito. A rvore de sintaxe abstracta respectiva aquela na qual se retiram os nodos que correspondem a palavras reservadas, s cando os que representam smbolos com carga semntica. Dada uma frase f de LG, a linguagem gerada pela gramtica G, designa-se por rvore de Sintaxe (AS), ou rvore de Derivao , a rvore cuja raz o axioma da gramtica S, e cuja fronteira (as folhas) composta pelos smbolos terminais que, uma vez concatenados da esquerda para a direita, formam a frase inicial. A rvore de Sintaxe Abstracta (ASA) obtm-se colando as respectivas sub-rvores abstractas correspondentes a cada uma das regras de derivao p P seguidas para derivar a frase a partir do axioma S. Uma gramtica de atributos (GA) um tuplo GA=<G,A,R,C>, onde:

G uma GIC que segue a denio dada acima. A a unio dos A(X ) para cada X (T U N ), e representa o conjunto de todos os atributos (cada um com um nome e um tipo); os atributos dos smbolos terminais chamam-se intrnsecos e o seu valor no precisa de ser calculado, provm da anlise lxica; para cada no-terminal X , o conjunto dos respectivos atributos A(X ) divide-se em dois subconjuntos: os atributos herdados AH (X ), e os atributos sintetizados AS(X ). R a unio dos Rp, o conjunto das regras de clculo dos valores dos atributos para cada produo p P. C a unio dos Cp, o conjunto das condies de contexto para cada produo p P.
Seja p uma produo duma GIC (p P), Rp o respectivo conjunto de regras de clculo, e Cp o respectivo conjunto de condies de contexto. Neste contexto:
X i.a, i 0, representa o atributo a associado ao smbolo X que ocorre na posio i da produo p. uma regra de clculo uma expresso da forma X i.a = f un( ..., X j.b, ... ) com:
26
a AS(X 0) V a AH (X i), i > 0 b AH (X 0) V b AS(X j), j > 0 f un uma funo do tipo V a (o tipo do atributo a)
uma condio de contexto um predicado da forma: pred( ..., X i.a, ... ), i 0
Dada uma frase de LGA, a linguagem gerada pela gramtica de atributos GA, seja ASA a correspondente rvore de Sintaxe Abstracta, como denido acima. Originalmente, cada nodo da rvore etiquetado com o smbolo gramatical correspondente e o identicador da produo aplicada para o derivar. Suponhamos, agora, que cada nodo enriquecido com os atributos, herdados ou sintetizados, associados aquele smbolo. Uma rvore de Sintaxe Abstracta Decorada (ASAD) a ASA inicial depois de passar pelo processo de clculo dos atributos, que vai associar aos atributos de cada nodo um valor do tipo apropriado. Para que seja uma ASAD vlida ainda necessrio que todas as condies de contexto associadas s produes correspondentes aos nodos da rvore, sejam satisfeitas (cujo valor seja verdadeiro para os valores actuais dos atributos).
2.2.1. Clculo de Atributos

A gramtica de atributos um formalismo declarativo para especicar linguagens. Porm a gramtica de atributos pode tambm ser usada para a construo (manual ou automtica) de processadores para as linguagens especicadas (compiladores, tradutores, etc). Assim como da GIC se retira toda a informao para desenvolver o analisador lxico e o analisador sinttico (parser), tambm das regras de clculo e condies de contexto se pode extrair informao necessria para implementar a anlise semntica. A anlise semntica, implementada segundo este paradigma da traduo dirigida pela semntica, constituda por duas grandes tarefas aplicadas a cada um dos nodos da ASAD:

o clculo do valor das ocorrncias dos atributos a validao das condies contextuais associadas a cada nodo da DAST
27
Este clculo faz-se aplicando as funes descritas explicitamente na gramtica de atributos sob a forma de regras de clculo (conjunto Rp), de igual forma a validao realiza-se avaliando os predicados tambm explicitamente especicados na forma de condies de contexto (conjunto Cp). As regras de clculo, ao denirem o valor de uma ocorrncia de atributo em funa dos valores de outras ocorrncias de atributos, induz imediatamente dependncias entre estes. Estas dependncias tm de ser identicadas pois iro inuenciar a ordem de clculo, na medida em que devem ser respeitadas para que uma funo seja sempre invocada com os argumentos instanciados com os valores correctos. A determinao da ordem de clculo uma tarefa complexa (cresce exponencialmente em tempo e espao relativamente ao nmero de atributos) que executada pelo sistema gerador do compilador. Na prtica, o problema foi contornado introduzindo a noo de classes gramaticais para as quais se desenvolveram algoritmos de ordenao mais ecientes [Hen92]. Alm disso, dada a quantidade de ocorrncias de atributos que podem surgir numa ASAD (muitos deles tomando valores em tipos estruturados), o processo de clculo consome grande parte do tempo total da compilao. Por causa deste factor temporal, surgiu o conceito de clculo incremental dos atributos no contexto de compiladores que so activados em simultneo com editores estruturados. Nesses ambientes, o compilador tem de ser reactivado (para reanalisar o texto) cada vez que feita uma alterao a esse texto-fonte. O clculo incremental (conceito tambm existente nas "folhas de clculo") tem por objectivo a minimizao do esforo dispendido na anlise semntica para que o processo de edio/compilao seja mais rpido. A ideia manter-se, em tempo real, a informao sobre as dependncias entre atributos de modo a que, aps uma alterao qualquer na ASA, se identiquem os atributos associados aos smbolos que foram alterados e aqueles que deles dependem, e se calculem apenas esses valores, sendo conservados todos os restantes. Como foi dito, para desenvolver parte do trabalho apresentado nesta tese (Captulo 9), recorreu-se a este formalismo. Para implementar os prottipos, recorreu-se a um ambiente de gerao de compiladores incrementais baseado em Gramticas de Atributos: o Synthesizer Generator [RT89a, RT89b, Ram93], que se apresenta na seco seguinte.
2.2.2. Synthesizer Generator (SGen)

28
Aps ter sido introduzido o conceito de Gramticas de Atributos, apresenta-se agora o Synthesizer Generator (SGen) como uma ferramenta que permite gerar automaticamente editores estruturados associados a compiladores incrementais. O SGen uma ferramenta que tem por objectivo implementar editores dirigidos pela sintaxe de uma dada linguagem. Estes so gerados a partir de uma especicao formal escrita na linguagem do SGen, a SSL ("Synthesizer Specication Language"). A SSL uma linguagem funcional que foi pensada e concebida para a especicao de aces semnticas num compilador. Muitos dos ingredientes necessrios para o efeito so suportados nativamente na linguagem: manipulao da rvore de derivao, tipos de dados estruturados pensados para suportar tarefas comuns num compilador como por exemplo a gesto duma tabela de smbolos, etc. O SGen foi desenvolvido na Universidade de Cornell, Estados Unidos, por Thomas Reps e Tim Teitelbaum [RT89a, RT89b]. Surgiu como o sucessor do "Cornell Program Synthesizer" [TR81], que era basicamente um editor de PL/I com um compilador e um interpretador incremental. Este sistema comeou a ser desenvolvido em 1981, e devido ao sucesso que alcanou, em 1990, o projecto termina no meio acadmico e continua numa empresa constituda para o efeito, GrammaTech, Inc. Os editores gerados pelo SGen trazem algumas vantagens ao desenvolvimento de programas e outras especicaes do gnero:

a sua maior potencialidade, a facilidade de compilao incremental. o editor gerado pelo SGen faz a anlise lxica, a anlise sinttica e a anlise semntica em simultneo com a edio, podendo ainda, como efeito lateral, realizar o processamento da informao reconhecida at ao momento. o conhecimento da sintaxe da linguagem permite que o prprio editor d um feed-back imediato ao seu utilizador, guiando-o e dispensando-o de conhecer a sintaxe concreta. o conhecimento da semntica da linguagem pode ser usado para transformar a informao incrementalmente durante a edio. a possibilidade de dotar o editor com o conhecimento estrutural e sinttico de uma dada linguagem faz com que estes editores sejam ptimos meios de
29
normalizao de escrita de programas ou documentos. Por exemplo, dotando um editor com o conhecimento estrutural duma carta possvel pr as pessoas duma empresa a escrever cartas com a mesma estrutura.
o editor gerado pode ainda ser congurado para ter janelas extra onde so mostradas vistas transformadas da rvore de sintaxe abstracta ("unpasing rules"); normalmente estas vistas correspondem s vrias geraes de cdigo realizadas pelo compilador.
Um compilador desenvolvido em SGen tem a mesma estrutura dum compilador genrico, tendo portanto os mesmos mdulos, s que alm destes tem outros relacionados com a interface e a edio estruturada. A especicao dum editor estruturado em SSL compreende vrios mdulos: sintaxe abstracta (onde se especica a sintaxe da linguagem custa apenas dos elementos estruturais com valor semntico), sintaxe concreta (onde se especica toda a sintaxe da linguagem; este mdulo que usado para carregar cheiros externos no editor), atributos (onde se declaram os atributos e se especicam as suas equaes de clculo) e, por m, as regras de "unparsing"(onde se especica de que maneira queremos ver a informao sintetizada na rvore de sintaxe abstracta decorada; para cada transformao pretendida da informao sintetizada iremos ter um destes mdulos). Para exemplos concretos, o leitor poder consultar as referncias fornecidas ou ainda, as duas teses de mestrado desenvolvidas nesta linha de investigao [Lop98, Sou98].
30
Captulo 3. Documentao Estruturada

Os documentos so criados com o objectivo de registar informao de modo a ser possvel comunic-la, ou partilh-la. Para que tenham valor necessrio que sejam fceis de localizar, fceis de consumir (interpretar), fceis de validar e fceis de reutilizar. A estrutura de um documento a chave para a informao que nele est contida e pode determinar o seu valor. As vantagens da explicitao da estrutura, para o aumento de mais-valias da informao baseada em documentos, podem ser analisadas luz das seguintes perspectivas (traando um paralelismo com a tecnologia baseada em bases de dados relacionais): Acesso Nas bases de dados relacionais, a rapidez e exibilidade com que se consegue aceder informao permite selecionar e ordenar os registos de modo a criar os relatrios necessrios num dado momento. Da mesma maneira, a estrutura associada aos documentos permite que elementos destes sejam rapidamente localizados e manipulados. Por exemplo, pode-se seleccionar todos os ttulos de captulos de um livro e construir um ndice alfabtico. Validao A vericao de que a informao apresentada est completa e de acordo com as regras estruturais designada por validao. Numa base de dados relacional sempre possvel validar o contedo de um campo ou de um registo. Se os documentos forem estruturados correctamente possvel criar algoritmos que executam, de forma aceitvel, a validao. Reutilizao No contexto de uma base de dados pode-se encarar a reutilizao como a possibilidade de gerar diferentes relatrios para o mesmo conjunto de informao. Se, pelo seu lado, os documentos tiverem uma estrutura de algum modo previsvel ser possvel localizar alguns elementos e utiliz-los para
31
outros ns. Por exemplo, imagine-se um manual de manuteno em que cada tarefa sempre identicada com um nmero e um ttulo descritivo. Deste manual poderiam ser extrados cartes de tarefa, cada um respeitante a uma tarefa, que seriam entregues aos diferentes mecnicos encarregues de as realizar. importante perceber que todas estas vantagens da estruturao s so possveis se esta fr rigorosamente mantida. A estrutura dos documentos deve ser monitorada e a sua qualidade controlada ao longo de todo o processo de publicao. Este processo implica um reformular completo dos mtodos existentes e uma reconverso por parte das pessoas intervenientes no processo.
3.1. Anotao
Desde h muito tempo, que quem trabalha em publicao de documentos sentiu necessidade de tornar explcitas certos aspectos dos textos que iam ser publicados. Historicamente, o termo ingls "markup", em portugus anotao, codicao ou etiquetagem, foi usado para descrever as anotaes ou outras marcas que eram colocadas nos textos para instruir os compositores e tipgrafos de como estes deviam ser impressos ou compostos. Por exemplo, palavras sublinhadas com linha ondulada deveriam ser impressas em "boldface" (letra mais carregada). Com a automao das tarefas de formatao e impresso o termo comeou a ser utilizado num sentido mais amplo, cobrindo todas as espcies de cdigos de anotao inseridos em textos electrnicos para dirigir a sua formatao, impresso ou outro tipo de processamento. Generalizando, podemos denir anotao de um texto como um meio de tornar explcita uma interpretao desse texto. Como exemplo mais banal de anotao podemos olhar para os sinais de pontuao que induzem uma determinada interpretao do texto em que esto inseridos. A ideia de anotar um documento surge naturalmente quando se pensa num documento especco. Por exemplo, uma carta comercial, um documento com uma determinada estrutura intrnseca, e quase todas as empresas as escrevem de acordo com essa estrutura (a importncia do standard). Ora, para o computador ser muito mais fcil processar este tipo de documento se ele estiver anotado, i.e., etiquetando o que o cabealho, a assinatura, a data, ... Caso contrrio teria que se
32
percorrer o texto a adivinhar quem o qu. Normalmente, os sistemas de processamento de texto requerem que o texto original seja enriquecido com informao adicional. Esta informao adicional, que tem a forma de anotaes, serve dois propsitos: a. Divide o documento nas suas componentes lgicas; e b. Especica qual ou quais as funes de processamento que devem ser aplicadas naquele componente. Em sistemas de DTP ("DeskTop Publishing"), que envolvem formataes muito complexas, a anotao normalmente realizada pelo utilizador, que foi especialmente treinado para desempenhar a tarefa. Nos sistemas de processamento de texto, as formataes a realizar sobre o texto so mais simples, o que permite que a anotao seja feita pelo utilizador sem um esforo muito consciente. Mas, com o evoluir da tecnologia, mesmo os processadores de texto comeam a incluir facilidades de DTP, o que vem trazer uma maior complexidade tarefa de anotar. Em concluso, a tarefa de anotar um texto requer esforo e consome tempo. Embora o utilizador, na maior parte das situaes, no se aperceba, h trs passos distintos na tarefa de anotao: a. Primeiro, h que analisar a estrutura da informao e os atributos que a caracterizam. b. Depois, preciso determinar, de memria ou consultando uma norma de estilos, quais as funes de processamento que produziro o formato/transformao desejado para cada elemento. c. Por ltimo, h que inserir as anotaes no texto. Distinguem-se dois tipos de anotao: procedimental e descritiva. Na primeira, mais orientada a aspectos tipogrcos, as anotaes vo ter um correspondente impacto fsico no aspecto nal do documento. A segunda, preocupa-se mais com aspectos lgicos e estruturais do texto, as anotaes apenas identicam as vrias componentes do documento.
33
3.1.1. Anotao Procedimental

Observe-se o seguinte exemplo de uma carta, j devidamente anotada:
Exemplo 3-1. Uma carta anotada

Comit Organizador da Conferncia "Sistemas de Informao para o Futuro" .vspace Caros Senhores, Venho por este meio informlos dos meios necessrios minha palestra: .tab 4 .of 4 .vspace 1. um retroprojector 2. um projector com conector VGA para ligao a computador porttil .vspace Obrigado
Um sistema de anotao procedimental dene qual o processamento a ser realizado em determinados pontos do documento. No exemplo acima, os comandos .vspace, .tab 4, e .of 4, realizam funes do tipo: deixar uma linha em branco; inserir uma tabulao de quatro posies; e mover a margem esquerda quatro posies. Como possvel observar, este tipo de anotao muito pouco exvel e dicultar futuras utilizaes com objectivos diferentes do de formatao. As linguagens de anotao procedimental so especcas e dependentes duma plataforma, no so facilmente portveis para outro sistema com um conjunto de funes e comandos diferente. A anotao procedimental foca o formato e aparncia, no tem nenhuma relao com com a hierarquia ou identicao de componentes. Assim, demasiado ambgua para ser utilizada em aplicaes que necessitem de ver o texto com uma estrutura associada. Este tipo de anotao pode, tambm, tornar-se complexo e de leitura difcil para um humano.
34
Um dos formatadores mais famosos o TeX, disponvel em vrias plataformas. Observe o seguinte exemplo de cdigo TeX:
Exemplo 3-2. Texto anotado em TeX

\hrule \vskip 3cm \centerline{\bf Escrevendo uma tese} \vskip 6pt \centerline{\sl por Jos Carlos} \vskip .5cm
Como se pode ver, a anotao procedimental pode, muito rapidamente, tornar-se complexa. No entanto, permite um control directo do formato visual do texto no output. Desde que ao utilizador s interesse criar papel a anotao procedimental serve perfeitamente para atingir os seus objectivos. Se, por outro lado, se se pretender dar outras utilizaes ao texto este no o caminho a seguir.
3.1.2. Anotao Descritiva

Ao contrrio da abordagem anterior, a anotao descritiva utiliza cdigos de anotao que apenas classicam as componentes do documento. Cdigos como <P> ou \end{description}, apenas identicam partes do documento e indicam asseres do tipo: "aqui pargrafo", ou "este o m da ltima lista descritiva iniciada".
Exemplo 3-3. Texto anotado de uma carta

<CARTA> <DEST>Comit Organizador da Conferncia "Sistemas de Informao para o Futuro"</DEST>
35
<ABERTURA>Caros Senhores,</ABERTURA> <CORPO><PARA>Venho por este meio informlos dos meios necessrios minha palestra: <LISTA> <LITEM>. um retroprojector</LITEM> <LITEM>. um projector com conector VGA para ligao a computador porttil</LITEM> </LISTA></PARA> <PARA>Por agora tudo. At dia 25.</PARA></CORPO> <FECHO>Obrigado</FECHO> </CARTA>
As vantagens deste tipo de anotao so bvias: o mesmo documento susceptvel de ser tratado, sem nenhuma alterao, por vrios processadores diferentes, podendo, cada um destes, aplicar funes de processamento distintas s vrias componentes do documento; cada processador, pode tambm, tratar apenas as partes relevantes para si. Por exemplo, um programa poder extrair, de um documento, nomes prprios de pessoas e lugares, para inserir numa base de dados, enquanto outro, processando o mesmo documento, apenas imprimir os nomes prprios num tipo de letra diferente.
3.1.3. Linguagens de Anotao

Como seria de esperar, as vrias comunidades de utilizadores procuram standardizar o conjunto de anotaes que utilizam. Ao conjunto de anotaes, utilizado por uma dada comunidade de utilizadores num determinado contexto, chamaremos "Linguagem de Anotao". Como se poder ver mais frente, existem mecanismos formais para a denio destas linguagens. Uma linguagem de anotao no dene apenas quais as anotaes que se podero utilizar num dado contexto, mas tambm especica qual a ordem em que essas anotaes devem e podem ou no ser utilizadas. Existem algumas linguagens de anotao de ampla utilizao, embora quem as utilize no tenha muita conscincia do que est a fazer. O melhor exemplo uma linguagem que toda a gente utiliza no dia-a-dia sem se aperceber: os sinais de
36
pontuao. Os sinais de pontuao que se colocam num texto induzem uma dada interpretao desse texto e dividem-no em componentes. Outros exemplos, so as linguagens presentes nos sistemas de edio de texto: o LaTeX [GMS94], o RTF e o velhinho WordStar; e linguagens, mais actuais, utilizadas na anotao de documentos para a Internet, o HTML e o XML. Ao tentar classicar cada uma daquelas linguagens em termos de anotao procedimental ou descritiva, constata-se que essa classicao reecte a evoluo da anotao.
3.1.4. Formatao e/ou Estrutura?

Mesmo utilizando uma linguagem de anotao descritiva, h certos cuidados a ter na denio e utilizao dessa linguagem que tm a ver com a subjectividade da tarefa de anotar. H trs abordagens bsicas tarefa de anotar: 1. Anotao orientada ao formato. 2. Anotao orientada estrutura. 3. Anotao orientada ao contedo. Uma boa linguagem de anotao ter de surgir de um equilbrio destas trs aproximaes. Optando por uma em detrimento das outras poder levar a lacunas que se faro sentir aquando da anotao de um documento.
3.1.4.1. Anotao orientada ao formato

Este o processo de anotar o documento com preocupaes de estilo e aparncia visual. Depois de tudo o que se disse sobre independncia de plataformas pode paracer contraditrio estar agora a falar em formas mas, h elementos cuja natureza intrnseca est denitivamente ligada forma. Texto carregado ou em itlico um bom exemplo disso - o autor pode querer colocar o texto nesta forma de modo a realar essa parte do texto. Outro exemplo, seria a quebra de pgina - em certos projectos, a paginao no pode ser livre. Outro exemplo ainda, so as tabelas que representam uma boa maneira de apresentar certo tipo de informao mas que como se disse esto muito ligadas apresentao.
37
Exemplo 3-4. Anotao orientada ao formato

<TITULO alinha="centrado" estilo="carregado" >Isto um ttulo centrado e com letra carregada</TITULO> <P>Isto um pargrafo onde o autor quis colocar algumas <REALCE>letras realadas</REALCE>.</P>
O perigo deste tipo de anotao o de no permitir, no futuro, utilizaes alternativas do contedo do documento. A anotao orientada ao formato descreve o aspecto visual dum elemento, mas no o identica nem especica qual a sua funo.
3.1.4.2. Anotao orientada estrutura

A anotao orientada estrutura baseia-se na hierarquia genrica. Os elementos so denidos pelo seu nome hierrquico. Este tipo de anotao torna-se til quando se tratam vrios tipos de estrutura diferentes ao mesmo tempo. Ao denir os elementos em termos da sua posio hierrquica, vo ser necessrias menos anotaes do que se estivssemos a identicar os elementos pelo seu contedo.
Exemplo 3-5. Anotao orientada estrutura

<SEC1>Isto uma seco de nvel 1.</SEC1> <SEC2>Isto uma seco de nvel 2.</SEC2> <P0>Isto um pargrafo do nvel de topo.</P0> <LISTA1>Isto um item duma lista de nvel 1.</LISTA1> <LISTA2>ISTO um item duma lista de nvel 2.</LISTA2>
O uso abusivo deste tipo de anotao pode levar a situaes em que elementos diferentes em termos de contedo mas que ocorrem na mesma posio hierrquica sejam anotados com mesma marca. Se, mais tarde, pretendermos ter um
38
processamento orientado ao contedo no vamos conseguir diferenciar os elementos porque a marca que os identica a mesma.
3.1.4.3. Anotao orientada ao contedo

A anotao orientada ao contedo o corao da anotao genrica. A identicao dos elementos pelo seu contedo e propsito, em lugar da sua forma ou posio hierrquica, faz com que se atinja o expoente mximo da exibilidade no contexto aplicacional. Na denio de anotaes orientadas ao contedo, d-se nomes diferentes a elementos que tipogracamente so idnticos.
Exemplo 3-6. Anotao orientada ao contedo

<RECEITA> <TITULO>Mousse de Chocolate</TITULO> <INGREDIENTES> <INGREDIENTE>Meia dzia de ovos</INGREDIENTE> <INGREDIENTE>200g chocolate</INGREDIENTE> <INGREDIENTE>50g de manteiga</INGREDIENTE> </INGREDIENTES> <INSTRUES> <INSTRUO>Separar as gemas das claras...</INSTRUO> ... </INSTRUES> </RECEITA>
Mais uma vez, o uso abusivo pode levar a situaes problemticas. Neste caso, em situaes extremas poderemos estar a anotar elementos com marcas diferentes e, mais tarde, nunca tiraremos partido dessas anotaes e as anotaes pesam no processamento do documento. Documentos com anotao abusiva tornam-se dispendiosos e muitas vezes impossiveis de processar.
3.1.4.4. Uma anotao equilibrada
39
Mostraram-se trs pequenos exemplos que reectem os trs tipos bsicos de anotao. Para cada um destes tipos de anotao, identicaram-se alguns problemas que surgiriam se se optasse por levar ao extremo qualquer um deles. Depois disto, torna-se claro que a soluo bvia usar os trs de forma equilibrada. Na escrita desta tese utilizou-se uma linguagem de anotao desenvolvida para a indstria da publicao electrnica, chamada DocBook [DocBook,WM99]. Nesta linguagem esto representados os trs paradigmas: Formato EMPH para realar texto, e TABLE para organizar visualmente a informao. Estrutura SECT1, SECT2 e SECT3 para marcar os vrios nveis de seces e subseces. Contedo NAME, AUTHOR, PUBDATE, COMMAND, ..., para marcar vrios items de informao. Podemos pois, prever que num projecto real com alguma dimenso, a anotao a utilizar seja resultado da combinao destes trs paradigmas: apresentao, estrutura e contedo.
3.2. Documentos e Linguagens de Anotao

O HTML o formato universal para quem produz documentos para o WWW; a maior parte dos autores nem tem a conscincia de que h alternativas. Mas, nos ltimos tempos, com o aparecimento do XML, a situao mudou. Esto a aparecer formatos alternativos e mais atractivos. Embora o XML suceda ao HTML, ambos so denidos em SGML que precede o HTML e mesmo a prpria Internet. O
40
SGML foi desenvolvido para dar mais exibilidade aos autores na expresso do signicado do que escrevem, e o XML transportou este conceito para a Internet.
3.2.1. Evoluo
A ideia de que os documentos estruturados pudessem ser trocados e manipulados se fossem publicados num formato standard e aberto, data dos anos 60 onde os esforos foram iniciados para que isso se tornasse uma realidade. De um lado, a associao norte-americana Graphic Communications Association (GCA), criou uma linguagem designada por GenCode para desenvolver anotaes para os documentos dos seus clientes que utilizavam diferentes aplicaes e geravam diferentes formatos. O GenCode permitiu GCA integrar no mesmo conjunto os vrios documentos provenientes desses clientes. Num esforo paralelo, a IBM desenvolveu outra linguagem designada por Generalized Markup Language (GML), na tentativa de resolver os seus problemas internos de publicao electrnica. O GML foi desenhado de modo a permitir que o mesmo documento pudesse ser processado para produzir um livro, um relatrio, ou uma edio electrnica. Como os tipos de documento comearam a proliferar, tendo cada um requisitos diferentes e exigindo por isso um conjunto de anotaes diferente, a necessidade para publicar e manipular duma forma standard cada tipo de documento tambm foi crescendo. No princpio dos anos 80, os representantes do GenCode e do GML juntaram-se formando um comit do American National Standards Institute (ANSI) designado por Computer Languages for the Processing of Text. O seu objectivo era normalizar a metodologia de especicao, a denio, e a utilizao de anotaes em documentos. A meta-linguagem SGML, Standardized Generalized Markup Language, foi lanada publicamente em 1986 como o standard ISO 8879. uma linguagem desenhada com o objectivo de permitir a denio e utilizao de formatos de documentos. sucientemente formal para permitir validar os documentos, tem estrutura suciente para permitir a especicao e manuseamento de documentos complexos, e extensvel de modo a suportar a gesto de grandes repositrios de informao. No m da dcada de 80, o SGML tinha j penetrado nalgumas instituies de grande dimenso como a indstria aeronutica e a de maquinaria pesada. No
41
entanto, foi no laboratrio suio do CERN, que um investigador ento a desenvolver a sua aplicao de hipertexto, lhe achou graa e pensou inclu-la na sua aplicao. Com efeito, Tim Berners-Lee, pai do World Wide Web (WWW), escolheu um conjunto de anotaes, que retirou dum DTD em SGML, e adoptou essas anotaes como a linguagem da sua aplicao. Em Nexus, o editor e navegador original do WWW, ele usou essas anotaes, folhas de estilo para formatar visualmente as pginas, e aquilo que lanou denitivamente este gnero de aplicaes: links. Em 1993, altura em que apareceu o Mosaic (primeiro browser a ter uma grande divulgao e utilizao), os utilizadores estavam j a estender ao mximo o HTML, puxando pelos seus limites. Mesmo a ltima verso do HTML, a 4.0, lanada em Julho de 1997, fornece apenas um conjunto limitado de anotaes. E, se pensarmos um pouco, depressa chegaremos concluso de que nenhum conjunto xo de anotaes ser suciente para anotar devidamente todos os documentos que circulam na Internet. Desde 1992, o HTML evoluiu de uma sintaxe ad-hoc para uma linguagem de anotao denida em SGML. A ideia era a de fornecer um suporte formal linguagem e de que as ferramentas da Internet passassem a implementar o HTML como um caso especco do SGML com uma formatao por defeito, i.e., as ferramentas deixariam de ser especcas do HTML e passariam a ser mais genricas. Desta maneira, qualquer alterao sintaxe do HTML seria automaticamente propagada a todas as ferramentas bastando para isso alterar a especicao do HTML e dos estilos. Esta era uma ideia avanada para a poca, os seus custos eram grandes e, nessa altura, a Internet no estava preparada para uma linguagem de anotao genrica mas sim para um pequeno conjunto de anotaes que qualquer pessoa pudesse aprender numa tarde. A denio do HTML em SGML foi o primeiro passo para aproximar o SGML da Internet e desta forma cativar o interesse da indstria de software. Estavam, neste momento, presentes os ingredientes que viabilizariam o aparecimento do XML, eXtensible Markup Language, por um lado o reconhecimento do SGML como uma boa metodologia para estruturar e representar documentos, do outro, as limitaes do conjunto xo de anotaes do HTML.
3.2.2. O Sentido Ecumnico do HTML

Por incrvel que possa parecer, o sucesso do HTML encontra-se associado sua
42
grande pobreza semntica. S um contexto muito pobre pode ser utilizado por uma grande comunidade, um contexto mais rico s pode ser partilhado por uma comunidade pequena e especca. Actualmente, existem vrias comunidades Internet identicadas e que partilham necessidades especcas na anotao dos seus documentos. O SGML possibilita a criao do contexto especco para cada uma destas comunidades. So exemplos: a indstria qumica, a matemtica, o comrcio electrnico, a medicina e a msica. O HTML s se pode extender atravs de ps-processamentos especcos e no atravs de novos elementos adicionados linguagem. O problema fundamental que o HTML no unilateralmente extensvel (h um organismo que centraliza todo o processo - W3C). Numa linguagem de anotao de utilizao genrica, a introduo de uma nova anotao potencialmente ambgua em termos semnticos (A que que est associada? Qual o seu papel na estrutura?) e em termos de apresentao (principalmente se no houver referncia a uma especicao de estilo). Pelo contrrio, o investimento em SGML possibilita trs funcionalidades crticas: Extensibilidade o autor pode denir novas anotaes, relacion-las com as existentes na estrutura, e acrescentar-lhe os atributos que desejar. Estrutura o autor pode associar e denir uma estrutura a um tipo de documento. Validao torna-se possvel validar o contedo do documento relativamente estrutura. O prximo captulo dedicado ao estudo do SGML (Captulo 4), e uma vez que o SGML representa a origem das outras linguagens de anotao que sero discutidas ao longo da tese, aquele estudo introduzir os conceitos bsicos que iro ser necessrios ao longo da tese.
43
Captulo 4. SGML - ISO8879

Depois de alguma resistncia, principalmente da parte da indstria de software, o SGML tem-se vindo a impr gradualmente a nvel mundial. Os seus primeiros clientes residem na indstria que produz mais documentao sobre os produtos que fabrica: a aeronutica (manuais de construo, manuteno e utilizao), a farmacutica, maquinaria pesada, etc. A seguir vieram as bibliotecas digitais, despolatadas por um projecto piloto na universidade americana Virginia Tech, existem um pouco por todo o mundo. Hoje, o SGML, uma realidade, no meio acadmico, na indstria e no sector tercirio. A maioria das empresas j estudou ou est a estudar os custos de uma migrao para esta tecnologia. Neste captulo faremos vrias travessias, em diferentes perspectivas, do SGML, tentando dar uma ideia dos nveis de complexidade e de utilizao possveis para o standard. Assim, iremos discutir o que so documentos SGML em geral (Seco 4.1), quais as entidades de informao que interagem num sistema SGML (Seco 4.2), e por m, quais os componentes do SGML e qual a utiliadade de cada um deles (Seco 4.3).
4.1. Documentos SGML

No mbito da anotao genrica, ou descritiva, o termo documento no refere uma entidade fsica, como um cheiro ou um conjunto de folhas impressas. Um documento visto como uma estrutura lgica encarada como uma hierarquia, identicando-se um elemento especial como a raz de uma rvore de componentes que constituem o contedo do documento. Por exemplo, livro pode ser a raz de um documento que conter elementos do tipo captulo que, por sua vez, podem conter elementos do tipo pargrafo ou imagem. Os elementos distinguem-se uns dos outros por informao extra anotaes ou marcas que adicionada ao contedo do documento. Assim, um documento contm dois tipos de informao: dados e anotaes.
44
Exemplo 4-1. Documento anotado em SGML

<PARAG>O <toponimico valor="PRSSIA, Rei darei da Prussia</toponimico> andava no exercito. Em hua aldeia sentio quatro tiros; hum lhe matou o cavallo. Hum guarda julgando o rei morto hia a vingarse da atrocidade. O rei clamou: -Estou vivo sem ferida, no haja efuso de sangue. Recolheose a <toponimico valor="VERDUN, Praa dePraa de Verdun</toponimico> e ahi ficou sitiado pelos franceses. Mas quem no poderia aqui fazer reflexoens? A <toponimico valor="PRSSIAPrussia</toponimico> queria isto, elle no fazia o negocio deveras.</PARAG> <PARAG>Entretanto chusmas de franceses expatriados se recolhio a Inglaterra. Aqui se abriro consignaoens para remedio destes miseraveis e nem a diferena de religio nem a politica impedio a generosidade anglicana a esta demonstrao de piedade christ. Alguns ministros protestantes se mostraro os mais zelosos na caridade. A causa dos miseraveis era tocante.</PARAG>
Excerto do livro "Memrias de Incio Peixoto dos Santos". Como se pode observar, o texto tem os pargrafos devidamente anotados (marca <PARAG>) e em cada um deles os nomes prprios relativos a pessoas e lugares esto marcados respectivamente com as anotaes <toponimico> e <antroponimico>.
45
Figura 4-1. Estrutura do texto anotado
O exemplo apresentado apenas mostra um extracto de uma das partes que constituem um documento SGML. Um documento SGML composto por trs partes distintas:
Prlogo ("SGML declaration") O prlogo [SGML.Decl] utilizado para declaraes iniciais que vo permitir distinguir as anotaes do texto: quais os caracteres delimitadores das marcas; qual o tamanho mximo dos seus identicadores; ... Normalmente, sempre que no fr desenvolvido um Prlogo prprio, novo, assumido um por defeito o prlogo que se encontra especicado no standard (hoje em dia, insuciente para a maior parte das aplicaes). DTD ("Document Type Declaration") O DTD um conjunto de declaraes, escritas na metalinguagem SGML, que no seu conjunto especicam um tipo de documento. Dois documentos com estrutura diferente (carta, memo, livro, ...), dizem-se de tipos diferentes, ou pertencentes a diferentes classes, e tero por isso DTDs distintos.
46
Um DTD:

Dene qual a estrutura dum documento. Especica quais as anotaes/marcas disponveis para anotar cada um dos elementos constituintes dos documentos deste tipo. Para cada elemento, especica quais os atributos que lhe esto associados, qual o seu domnio e quais os seus valores por defeito. Para cada elemento, dene a estrutura do seu contedo: que subelementos tem; em que ordem; onde que pode aparecer texto normal; onde que podem aparecer dados que no sejam texto.
Texto Anotado (Instncia) A terceira parte o documento propriamente dito. Contm a informao (o contedo textual), as anotaes, e uma referncia ao DTD (se este no estiver presente no documento). Um DTD pode ser externo aos documentos, i.e., os documentos concretos (instncias) podem apenas ter uma referncia para o seu DTD que armazenado noutro cheiro. O SGML, com os DTDs veio criar um novo conceito: o de documento vlido. Um documento vlido se a sua estrutura respeitar as regras especicadas no DTD de acordo com o qual pressuposto que ele tenha sido escrito. Antes de se pormenorizar mais o SGML (ver Seco 4.3), vai-se contextualizar esta tecnologia (Seco 4.2). O que que est volta. O que interage com o SGML e como.
47
4.2. Arquitectura de um sistema SGML

Figura 4-2. Arquitectura dum sistema SGML
Na gura Figura 4-2, faz-se uma apresentao esquemtica dum sistema SGML, com as componentes de informao e de software. O SGML est por detrs da maior parte dos componentes da arquitectura: nas anotaes dos textos; na denio do DTD; e na aco do parser. Normalmente, estes componentes so transparentes para o utilizador, esto inseridos no sofware com o qual o utilizador interage, como o editor, o formatador, e a base de dados.
4.2.1. Textos SGML

So cheiros que contm textos enriquecidos com anotaes denidas num DTD escrito em SGML. Hoje em dia, h editores de SGML bastante poderosos capazes de tornar as anotaes invisveis para o utilizador, validar a estrutura do texto que est a ser inserido e fornecer uma ajuda contextual na escrita desse texto. O SGML, uma vez que independente de plataformas de hardware e software, no
48
especica nenhuma directiva de comportamento dos editores. Assim, estes nascem apenas das ideias da equipe que os implementa tendo apenas uma coisa que comum a todos: para se ser um editor SGML tem que se poder importar qualquer texto SGML e, tem que se conseguir exportar qualquer texto criado em SGML.
4.2.2. Um ou mais DTDs

Os DTDs so o elo de ligao dum sistema SGML. No se pode utilizar SGML sem se pensar num DTD. No se pode pensar em estruturar um documento sem antes ter pensado e denido uma estrutura para esse tipo de documento. Um DTD deve ser pensado e denido por um especialista. Este processo deve surgir no incio de qualquer projecto editorial, numa fase que se designa por Anlise Documental (ver Seco 5.1), que em tudo semelhante fase de anlise na implementao de um sistema de informao.
4.2.3. Um parser
Para assegurar que as anotaes num documento esto consistentes com o DTD e sem erros, um sistema SGML tem um programa que reconhece as anotaes de um documento SGML, e que lhes aplica um processo de validao. Este programa tem o nome de parser. Um documento SGML deve ser sempre submetido a um parser (passar por um processo de validao) antes de ser exportado para outra palataforma ou antes de ser processado com o objectivo da sua transformao. Um parser verica:

se o DTD est bem denido, de acordo com a sintaxe do SGML; se a instncia, o texto anotado do documento, est em conformidade com o DTD.
Um editor SGML inclui estas facilidades de validao estrutural, por isso, tem sempre um parser associado. Como se poder constatar mais frente, no so apenas os editores que incluem um parser, mas todas as ferramentas que processam textos SGML. No entanto, a maior parte dos parsers de SGML disponveis tm a
49
capacidade de funcionar individualmente sem necessidade de estarem dependentes de outras ferramentas. Existe uma grande variedade de parsers disponveis, uns comerciais, outros simplesmente livres para quem os quiser utilizar. Curiosamente,e ao contrrio de muitas outras tecnologias, so estes ltimos, sem encargos comerciais, os mais utilizados, quer pela comunidade de utilizadores SGML, quer pelos produtores de software que os incluem nos editores e formatadores que desenvolvem. Assim temos por ordem de evoluo, o ARCSGML [ARCSGML], o SGMLS [SGMLS], e por ltimo o SP [SP]. O ARCSGML considerado como um dos primeiros parsers a cobrir a maioria da funcionalidade descrita no sandard SGML. O SGMLS j um parser da nova gerao; resultou da reescrita do ARCSGML por James Clark que uns anos depois voltou a reescrever, desta vez o SGMLS, numa implementao orientada a objectos, o SP. O SP deve ser o parser de SGML mais utilizado, de momento. O seu autor desenvolveu um conjunto de ferramentas que o incluem, que so livres de direitos comerciais, e que so utilizadas por muitas pessoas e empresas no dia-a-dia: nsgmls, sgmlnorm, spam, spent.
4.2.4. Um sistema de processamento

Uma vez que no tm informao especca sobre a sua formatao, os documentos SGML so constitudos apenas pelo contedo textual e informao estrutural. Para um utilizador comum, um documento SGML acaba por ser um texto de alguma maneira codicado que ele no entende. Assim, depois de validados pelo parser, os documentos SGML tm que ser processados de modo a serem transformados numa forma mais prxima do utilizador nal. A sua estrutura tem que ser traduzida para um conjunto de comandos de um processador de texto, ou de uma base de dados, conforme o objectivo nal. Por exemplo, se se quiser uma verso em papel dum documento SGML, para distribuir a um conjunto de leitores, ter-se- que converter de SGML para RTF, ou Postscript, ou PDF, e usar um formatador para imprimir (no caso do RTF, o MSWord poderia ser usado para criar a verso papel). O processamento de documentos SGML est fora dos limites do standard. No entanto, a comunidade ligada publicao electrnica est atenta e em 1996 foi publicado um outro standard ISO que visa normalizar o processamento de
50
documentos SGML; este novo standard foi designado por DSSSL ("Document Style and Semantics Specication Language") [Cla96,Mul98], e que analisado na Seco 6.2. Apesar de ser recente, o DSSSL tem vindo a ser utilizado cada vez mais. Isto deve-se ao facto de, com esta nova pea, se conseguir obter uma abordagem completamente standard para a produo documental, desde a criao do documento at ao output nal. J existem disponveis vrios sistemas de processamento baseados em DSSSL, uns comerciais e outros livres de direitos. Mais uma vez, o mais divulgado um sistema sem direitos comerciais, podendo ser utilizado por quem quiser, o Jade [jade]. Neste momento, no h nenhum sistema que implemente uma especicao DSSSL na globalidade das suas potencialidades. O Jade representa a implementao mais conseguida, oferecendo praticamente tudo o respeitante ao processamento de estilos (as primitivas necessrias para formatar gracamente um documento) e a um ou outro detalhe semntico. O resultado do sistema de processamento pode ser muita coisa, desde o documento traduzido num formato que pode ser carregado num processador de texto at uma lista de nomes colectada ao longo do documento, ou simplesmente um resumo estatstico do contedo do documento.
4.3. Componentes dum Documento SGML

Um documento SGML composto por trs grandes e distintas partes: o Prlogo, o DTD e a Instncia.
4.3.1. Prlogo
O prlogo uma parte formal de cada documento SGML. Especica, por exemplo, quais os caracteres que podem ser utilizados na escrita dos documentos e dentro destes, quais os que sero utilizados como limites das anotaes e, muitas outras caractersticas de baixo nvel como o limite mximo do tamanho dos identicadores das anotaes.
51
Um prlogo

, normalmente, comum a todos os documentos SGML num dado ambiente. pode ou no fazer parte do documento (no caso da sua ausncia ser usado um por defeito - o denido no standard). fornece detalhes precisos de como o SGML ser aplicado ao documento. dene os caracteres que sero usados para distinguir as anotaes do texto (e.g. <, >, />). dene o conjunto de caracteres (ASCII, EBCDIC ou outro) que vai ser utilizado.
Um utilizador no precisa de conhecer a existncia do prlogo para criar e manusear documentos SGML. Uma vez que este dene aspectos de muito baixo nvel, os sistemas SGML trazem alguns prlogos previamente denidos que permitem aos utilizadores abstrairem-se completamente da sua existncia.
Exemplo 4-2. Um Prlogo SGML

<!SGML "ISO 8879:1986"
CHARSET BASESET "ISO 646:1983//CHARSET International Reference Version (IRV)//ESC 2/5 4/0" DESCSET 0 9 UNUSED os primeiros 9 caracteres comeando em 0 no so utilizados9 2 9 os prximos, 9 e 10, so mapeados nos caracteres 9 e 10 da base (BASESET)11 2 UNUSED - o 11 e o 12 no so usados 13 1 13 - o 13 mapeado no 13 14 18 UNUSED os prximos 18, comeando no 14, no so usados -
52
32 95 32 os prximos 95, comeando no 32, so mapeados nos caracteres 32126 do conjunto base (BASESET) 127 1 UNUSED - o caracter 127 no usado CAPACITY PUBLIC "ISO 8879:1986//CAPACITY Reference//EN" SCOPE DOCUMENT SYNTAX PUBLIC "ISO 8879:1986//SYNTAX Reference//EN" FEATURES MINIMIZE DATATAG NO OMITTAG YES RANK NO SHORTTAG YES LINK SIMPLE NO IMPLICIT NO EXPLICIT NO OTHER CONCUR NO SUBDOC NO FORMAL NO APPINFO NONE >
No entanto, o prlogo que vem congurado por defeito (ver Exemplo 4-2) est relacionado com as lnguas anglo-saxnicas, e compreende apenas metade dos caracteres ASCII. Os pases mais ocidentais da Europa, nos quais se inclui Portugal, necessitam do ASCII extendido na escrita dos seus textos. Portanto, na instalao dum sistema SGML deve ter-se o cuidado de instalar um prlogo que inclua os caracteres do ISO LATIN1 como o prlogo por defeito, ou em casos mais complicados incluir o Unicode [Unicode].
4.3.2. DTD
53
A anotao de um elemento composta por duas marcas, uma anotao de incio do elemento e uma anotao de m. Estas anotaes iro descrever as qualidades caractersticas do elemento. Uma daquelas caractersticas o identicador genrico, que identica o tipo do elemento: pargrafo, gura, lista, ... Adicionalmente, um elemento poder ser qualicado por mais caractersticas que lhe so inerentes; estas recebem a designao de atributos. O conjunto de anotaes num documento, descrevem a sua estrutura. Indicam quais os elementos que ocorrem no documento e em que ordem. Esta estrutura tem de ser vlida de acordo com o conjunto de declaraes no DTD que denem todas as estruturas permitidas num determinado tipo de documento. Para introduzir este conceito de DTD, recorre-se ao exemplo seguinte. Nesse exemplo, todas as linhas comeadas por "<!"so comentrios e destinam-se a esclarecer o objectivo geral do tipo de documento, e os de cada elemento em particular.
Exemplo 4-3. DTD para uma carta

<!- Este DTD define a estrutura de docs do tipo CARTA > <!DOCTYPE CARTA [ <!- Uma carta uma sequncia de elementos: um destinatrio, > <!- um texto de abertura, um corpo, e um texto de fecho. > <!ELEMENT CARTA - - (DEST, ABERTURA, CORPO, FECHO)> <!- O destinatrio texto. > <!ELEMENT DEST - - (#PCDATA)> <!- A abertura texto. > <!ELEMENT ABERTURA - - (#PCDATA)> <!- O corpo composto por um ou mais pargrafos. > <!ELEMENT CORPO - - (PARA)+> <!- Um pargrafo composto por texto podendo ter uma ou > -
54
<!- mais listas intercaladas. > <!ELEMENT PARA - - (#PCDATA | LISTA)+> <!- Uma lista uma sequncia de um ou mais items. > <!ELEMENT LISTA - - (LITEM)+> <!- Um item texto. > <!ELEMENT LITEM - - (#PCDATA)> <!- O fecho texto. > <!ELEMENT FECHO - - (#PCDATA)>
Este DTD muito simples, contm apenas declaraes de elementos. Mesmo assim, permite escrever cartas estruturadas e anotadas e ainda, fazer a validao estrutural desses documentos.Contudo, est ainda um pouco distante dum DTD real que contm normalmente maior riqueza informativa.
Formalmente, podemos dizer que um DTD composto por um conjunto de declaraes. Existem quatro tipos de declaraes: elementos, atributos, entidades, e instrues de processamento.
4.3.2.1. Elementos
Um elemento denido no DTD numa declarao do tipo ELEMENT, que obedece seguinte estrutura:
<!ELEMENT
identificador - - (exp-contedo) excepo>
identicador identicador do elemento expresso de contedo denio do contedo do elemento expressa numa linguagem de expresses regulares que obedece a uma lgebra [CMAlgebra]. A expresso regular que
55
dene o contedo do elemento especica que subelementos podem aparecer, em que ordem e em que nmero. excepo a excepo opcional e permite modicar a denio do contedo do elemento, permitindo elementos opcionais no mencionados na expresso de contedo e/ou excluindo outros elementos opcionais pernitidos pela expresso de contedo.
4.3.2.1.1. lgebra do Contedo Nas expresses regulares que podem aparecer a denir o contedo dos elementos h dois tipos de operadores: operadores de sequncia, ou conexo; e operadores de ocorrncia. 4.3.2.1.1.1. Operadores de Conexo So normalmente colocados entre dois subelementos e especicam a ordem em que podem ocorrer: , Exemplo: (a, b) signica que este elemento tem que ser composto por um elemento a e um elemento b, e que a deve preceder b. Do nosso exemplo anterior:
<!ELEMENT CARTA
- - (DEST, ABERTURA, CORPO, FECHO)>
uma carta obrigatoriamente constituda por um destinatrio, uma abertura, um corpo e um fecho, nesta ordem. | Exemplo: (a | b) signica que o elemento corrente composto por um elemento a ou um elemento b. &
56
Exemplo: (a & b) signica que o elemento corrente composto por um elemento a e por um elemento b sem ordens de precedncia, i.e., desde que os dois estejam presentes, a ordem no importa. Se na declarao anterior de carta substitussemos os operadores:
<!ELEMENT CARTA
- - (DEST& ABERTURA& CORPO& FECHO)>
a constituio dum documento carta seria a mesma, a ordem dos elementos poderia ser qualquer, por exemplo, uma carta poderia iniciar-se com o fecho. Na prtica, este operador deve ser evitado porque, como iremos ver mais frente, apesar de nos facilitar a especicao do tipo de alguns documentos mais complicados, vai-nos levantar problemas de processamento e portabilidade.
4.3.2.1.1.2. Operadores de Ocorrncia So aplicados individualmente a um elemento ou a uma estrutura j especicada. ? (0 ou 1 vez) Exemplo: (a?,b) o elemento que tem este contedo tem que ser constitudo opcionalmente por um elemento a seguido dum elemento b. * (0 ou mais vezes) Exemplo: (a*,b) o elemento que tem este contedo tem que ser constitudo por zero ou mais elementos a seguidos dum elemento b. + (1 ou mais vezes) Exemplo: (a+,b) o elemento que tem este contedo tem que ser constitudo por um ou mais elementos a seguidos dum elemento b. Resumindo, a lgebra do contedo dene uma linguagem composta por strings de caracteres e elementos do documento. Vamos representar o conjunto de caracteres por . As expresses que denem o contedo dos vrios elementos num DTD so muito semelhantes a expresses regulares sobre um alfabeto V , que composto
57
pelos identicadores de tipo dos elementos do DTD e #PCDATA. Iremos referir-nos aos membros de V como smbolos. A linguagem L(E) denida por uma expresso de contedo E dene-se indutivamente como se segue ( representa a string vazia):
L(#PCDATA) = {v1...vn|v1...vn , n 0} L(a) = {a} para a V - {#PCDATA} L(F|G) = L(F) U L(G) L(F,G) = {vw | v L(F), w L(G)} L(F?) = L(F) U { } L(F*) = {v1...vn | v1, ..., vn L(F), n 0} L(F+) = {v1...vn | v1, ..., vn L(F), n 1} L(F1&...&Fn) = {v1...vn | vi L(F(i)), i=1, ..., n, e uma permutao de {1, ..., n}
Num captulo nal, onde discutiremos a implementao dum sistema baseado em SGML voltaremos a abordar esta lgebra de contedos referindo alguns problemas de concepo do standard que fazem com que a implementao dum parser SGML seja extremamente difcil e trabalhosa.
4.3.2.1.2. Excepes Como j foi referido, as excepes permitem alterar a expresso de contedo dum elemento, forando a incluso ou a excluso de certos elementos. Trata-se de mais uma caracterstica relacionada com as limitaes da tecnologia informtica da altura (1986): editores de texto simples, ausncia de apoio contextual. As excepes surgiram para abreviar a escrita dos DTDs, no entanto, a sua presena num DTD torna o parsing deste muito complicado. Os dois tipos de excepo demonstram-se nos exemplos seguintes.
Exemplo 4-4. Incluso Se estivssemos a desenvolver um DTD para o tipo de documentos MEMO podamos querer tomar a deciso de ter um elemento NOTA-RODAPE "pendurado"em qualquer um dos subelementos de MEMO. Em vez de adicionarmos o elemento NOTA-RODAPE s expresses de contedo de todos os
58
elementos (o que pode no ser simples para expresses complexas), podemos abreviar esta tarefa ligando o elemento NOTA-RODAPE ao elemento raz MEMO atravs de uma incluso. A sintaxe de uma incluso a seguinte:
<!ELEMENT nome minimizao (exp-contedo) +(incluso)>
Assim, a situao anterior seria especicada da seguinte maneira:

<!ELEMENT MEMO - - ((PARA & DE),CORPO,FECHO?) +(NOTA-RODAPE)>
Por razes de ecincia e diculdade de processamento que iremos discutir mais frente, as incluses devem ser utilizadas com algum cuidado e, preferencialmente, para elementos que no fazem parte do contedo lgico no ponto em que ocorrem. Por exemplo: palavras-chave, entradas dum index, entradas do ndice, guras, tabelas, ...
Exemplo 4-5. Excluso Pode surgir uma situao em que um elemento deva ser excludo do contedo de um dado elemento. Um exemplo disso o controle do mecanismo de incluso no sentido de evitar recursividades indesejveis. No exemplo anterior (Exemplo 4-4), a NOTA-RODAPE no dever ocorrer dentro do seu prprio contedo. Isto pode ser conseguido atravs duma excluso. A sintaxe genrica para as excluses a seguinte:
<!ELEMENT nome minimizao (exp-contedo) -(excluso)>
Na continuao do exemplo anterior, introduzimos as seguintes declaraes no DTD:

<!ELEMENT NOTA-RODAPE - - (PARAGRAFO+) -(NOTA-RODAPE)> <!ELEMENT PARAGRAFO - - (TEXTO | NOTA-RODAPE)+> <!ELEMENT TEXTO - - (#PCDATA)>
Um elemento s pode ser excludo se fr opcional, se fr repetitivo ou, se ocorrer numa alternativa. A excluso de um elemento obrigatrio d origem a uma situao de erro.
59
Normalmente , as excluses servem para limitar a recursividade das incluses. Para evitar que um documento se torne no-estruturado, as exluses devero ser usadas, sempre que possvel, no nvel mais baixo da rvore documental.
4.3.2.2. Atributos
Um elemento pode ter um ou mais atributos que, por sua vez, podem ser opcionais ou obrigatrios. Os atributos visam qualicar o elemento a que esto associados. A especicao de atributos num DTD pode ser comparada especicao de parmetros num programa escrito numa linguagem de programao, ou pode-se ainda traar um paralelo com a nossa lngua: os elementos seriam substantivos e, os atributos, os adjectivos. Assim:
Isto uma casa Isto uma casa verde == ==
<CASA> <CASA
COR="verde
Os atributos devem aparecer sempre na anotao que marca o incio do elemento, uma vez que vo qualicar o contedo que se segue. No h limite para o nmero de atributos que podem estar associados a um elemento. Especicou-se atrs um DTD para o tipo de documento carta. Suponha-se que agora se pretendia classicar cada uma das cartas escritas de acordo com aquele DTD como pessoais ou pblicas. Isso pode ser feito associando ao elemento carta um atributo tipo com a possibilidade de ter os valores "pessoal"ou "pblica":
<!ATTLIST
CARTA TIPO (pessoal | pblica) pblica>
Adicionalmente, os valores dos atributos podem ser mais do que simples strings, podem ter uma semntica especca. Por exemplo, um atributo pode ser declarado de modo a que o valor que a ele seja associado seja nico. Isto o que se pode chamar de identicador chave e que pode ser usado para referenciar e localizar um elemento numa instncia dum documento. Este identicador chave pode ser usado por outros elementos para o referenciarem num contexto hipertextual. A declarao de atributos em SGML tem a seguinte forma:
60
<!ATTLIST elem-id att1-id att1-tipo att1-valor-omissao ... attn-id attn-tipo attn-valor-omissao >
Onde: elem-id o identicador do elemento ao qual os atributos caro associados. atti-id o identicador do atributo i. atti-tipo o tipo do atributo i. atti-valor-omissao o valor por omisso do atributo i. No quadro seguinte, descrevem-se os tipos de atributo mais relevantes e em uso. Tabela 4-1. Tipos de Atributo Tipo CDATA ENTITY Descrio o valor do atributo ser uma string ( o tipo de atributo mais usado) o valor do atributo dever ser o identicador duma entidade declarada no DTD o valor do atributo devr ser um identicador nico em todo o documento
ID
61
Tipo IDREF
Descrio o valor do atributo dever ser um identicador pertencente a um atributo do tipo ID de outro elemento (implementao das referncias) o valor do atributo dever ser um identicador duma notao declarada no DTD o valor do atributo numrico
NOTATION
NUMBER
Por sua vez, o quadro seguinte descreve os valores por omisso dos atributos: Tabela 4-2. Valores por omisso #IMPLIED #REQUIRED #FIXED o valor poder no ser instanciado, o atributo opcional. o utilizador ter obrigatoriamente que instanciar o atributo, este obrigatrio o valor do atributo tem que aparecer a seguir palavra-chave (ver Seco 7.1, Exemplo 7-3) signicando que se o atributo fr instanciado ter que ser com um valor igual ao declarado, caso no seja instanciado o sistema assumir esse valor. o valor do atributo herdado da ltima instncia do mesmo elemento onde o valor do atributo foi instanciado (segue-se a ordem ascendente na rvore de elementos) o valor usado para referncias externas (cada vez menos utilizado, no ir ser considerado nas regras que se seguem) um dos valores pertencentes ao tipo enumerado denido para esse atributo.
#CURRENT
#CONREF
valor dum tipo enumerado
62
Para terminar a descrio dos atributos, apresenta-se um exemplo comum a quase todas as publicaes, as referncias bibliogrcas.
Exemplo 4-6. Atributos - tipos e valores Numa lista de items bibliogrcos:

<BIB.LISTA> <BIB.ITEM IDENT="Saramago <AUTOR>Jos Saramago</AUTOR> <TITULO>Jangada de Pedra</TITULO> ...
Ao item bibliogrco (<BIB.ITEM) atribui-se um identicador chave ao seu atributo IDENT, que pode agora ser usado noutros stios para referenciar este item. As referncias aos items bibliogrcos podem ser feitas usando um elemento especco para o efeito, por exemplo, BIB.REF, que ter um atributo, por exemplo, REFIDENT, que ir ter um valor previamente atribudo a um atributo IDENT dum item bibliogrco:
O escritor de muitas obras, das quais se destaca "Jangada de Pedra" <BIB.REF REFID="Saramago ...
As respectivas declaraes em SGML seriam:

<!ATTLIST BIB.ITEM IDENT ID #IMPLIED> <!ATTLIST BIB.REF REFID IDREF #REQUIRED>
4.3.2.3. Entidades
Um documento SGML pode estar espalhado por vrios cheiros do sistema. Facilita-se desta maneira a reutilizao de subcomponentes, dentro do prprio documento ou noutros documentos, e permite-se que informao noutro formato seja inserida no documento. No resto desta seco, vai-se descrever o mecanismo do SGML que suporta estas facilidades.
63
Conceitos
4.3.2.3.1. Conceitos O SGML tem um mecanismo que permite isolar sicamente e armazenar separadamente qualquer parte de um documento. Por exemplo, cada captulo de um livro pode ser gravado em cheiros distintos, ou, as guras podem estar guardadas separadamente e podem ser inseridas num dado ponto do documento. Cada uma destas unidades de informao designada por entidade e tem um identicador nico associado pelo qual referenciada. A nica excepo a entidade correspondente ao documento principal que no precisa do identicador pois normalmente referenciada pelo nome do cheiro que a contm. Nos casos mais simples, esta ser a nica entidade relacionada com o documento (o documento SGML est contido num cheiro - Figura 4-3 a). Noutros casos, o cheiro principal ter a maior parte do contedo do documento, contendo referncias a outras entidades que identicam os cheiros com o contedo que preencher alguns intervalos (Figura 4-3 b). No outro extremo, a entidade/cheiro principal no mais do que um esqueleto, usado para posicionar o contedo de outras entidades (Figura 4-3 c). Figura 4-3. Estrutura Fsica de um documento
Uma entidade denida numa declarao prpria que normalmente aparece no incio do DTD. Nesta declarao atribudo um nome entidade e -lhe associado um contedo ou uma referncia para um cheiro externo onde est esse contedo. As entidades so usadas por referncia, i. e., o autor coloca uma referncia no texto que identica univocamente uma entidade. No h limite para o nmero de
64
referncias a uma mesma entidade num documento. Mais tarde, quando o documento fr processado as referncias so substitudas pelos respectivos contedos. No texto de uma entidade poder haver referncias a outras entidades. No entanto, no so permitidas referncias cclicas. Deve-se ter algum cuidado na utilizao de entidades e ter alguma ateno na limitao da sua utilizao. O seu uso abusivo aumenta a complexidade do tratamento do documento. H, no entanto, vrias situaes em que a utilizao de entidades deve ser considerada:
quando a mesma informao utilizada algumas vezes no documento; a duplicao sempre susceptvel de erros e tem custos temporais. quando a informao tem representaes diferentes em sistemas incompatveis. quando informao diz respeito a um grande documento que deve ser separado em unidades mais pequenas de modo a facilitar a sua manuteno. quando a informao composta por dados num formato diferente do SGML.
Dos princpios acima enunciados d para perceber que precisamos de mais de um tipo de entidade de modo a podermos tratar informao SGML e informao que no SGML, unidades de grandes dimenses e outras de pequenas dimenses: entidades gerais so usadas como um mecanismo de abreviaturas para strings grandes de texto que se iro repetir ao longo de um texto (situao anloga denio de constantes, ou macros, nas linguagens de programao. entidades caracter representam a maneira de codicar caracteres especiais: caracteres acentuados, letras de outros alfabetos, e alguns smbolos matemticos. entidades externas servem para referenciar cheiros externos, de modo a ser possvel inclu-los nos pontos adequados.
65
entidades paramtricas so usadas como variveis na escrita de DTDs, para abreviar a sua escrita e tornar as expresses regulares de contedo mais simples. As referncias a entidades gerais devem ser colocadas no texto onde se pretender que aquelas sejam expandidas. Figura 4-4. Os vrios tipos de entidades
4.3.2.3.2. Entidades Gerais Tal como os elementos e os atributos as entidades so denidas no DTD numa declarao prpria.
Exemplo 4-7. Declarao de uma entidade geral Sintaxe da declarao: <!ENTITY identicador "contedo"> Exemplo:
<!ENTITY
SGML "Standard Generalized Markup Language
66
Depois, podem ser utilizadas no texto com uma sintaxe especca.
Exemplo 4-8. Referncia a uma entidade geral Sintaxe da referncia: & identicador ; Exemplo:
"A migrao para uma tecnologia baseada em &SGML; tem custos que ...
Na escrita desta tese foram utilizadas entidades gerais de uma forma peculiar para resolver um problema prtico e especco. O DTD usado traz nele includas algumas bibliotecas de entidades especiais que mapeiam caracteres matemticos, gregos, etc. Para a escrita de algumas denies matemticas estava-se a usar uma biblioteca de letras caligrcas, "ISOmscr.gml". O problema que nenhum dos "back-ends"utilizados, RTF e HTML, mapeia aqueles caracteres na fonte apropriada e at um dia isso acontecer foi preciso arranjar uma soluo de compromisso: mapeou-se cada um dos caracteres num elemento de realce como se pode ver no seguinte exemplo.
Exemplo 4-9. Entidades gerais utilizadas na escrita da tese

<!ENTITY ascr "<EMPHASIS>a</EMPHASIS> <!ENTITY bscr "<EMPHASIS>b</EMPHASIS> <!ENTITY dscr "<EMPHASIS>d</EMPHASIS>
Assim, quando no texto se usa uma daquelas entidades, por exemplo &ascr;, sempre que o documento processado a entidade substituda pelo elemento EMPHASIS com contedo igual letra correspondente. Mais tarde, se os caracteres correspondentes a estas entidades vierem a ter o suporte desejado por parte dos "back-ends", aquelas podero vir a ser retiradas ou colocadas em comentrio.
67
4.3.2.3.3. Entidades caracter O conjunto de caracteres denido no prlogo de um documento SGML pode ser muito mais lato do que os caracteres que o teclado disponibiliza. As entidades caracter vm possibilitar a referncia de qualquer caracter denido no prlogo. O nome destas entidades o nmero decimal correspondente ao caracter que se quer referenciar. Por exemplo , se estivermos a trabalhar com os caracteres ASCII a entidade de nome 65 corresponde ao A. Sintaxe da declarao: A sua declarao est intrnseca na declarao dos caracteres no prlogo. Sintaxe da referncia: &# identicador ;
Exemplo 4-10. Referncia a uma entidade caracter

... a flecha tinha-lhe trespassado o corao.
4.3.2.3.4. Entidades externas Quando um documento cresce e atinge dimenses considerveis, a sua edio pode tornar-se penosa e difcil. Numa situao destas, a soluo dividir o documento em unidades mais pequenas, havendo um documento principal a integrar aquelas unidades. Esta tese, por exemplo, encontra-se repartida em vrios cheiros SGML. A poltica seguida foi a separao por captulos. Esta losoa implementada em SGML atravs de entidades externas. Uma entidade externa corresponde a uma das parties do documento original. No documento principal, colocam-se referncias s entidades externas no local onde deveriam ser inseridos os respectivos cheiros SGML.
Exemplo 4-11. Declarao de uma entidade externa
68
Sintaxe da declarao: <!ENTITY identicador [PUBLIC identicador-pblico] [SYSTEM path] Os blocos entre "["e "]"so opcionais mas um deles dever estar presente. Os dois blocos dizem respeito aos dois mtodos possveis de endereamento dos cheiros externos: indirectamente atravs de identicador pblico ou, directamente atravs do nome e local do cheiro no sistema. O mtodo indirecto surge para facilitar a gesto dos cheiros dentro do sistema. Pressupe a existncia de um cheiro com o nome catalog, que faz o emparelhamento entre identicadores pblicos e nomes de cheiros. Um identicador pblico uma string que obedece a um conjunto de normas estipuladas num standard Spy97. Exemplo:
<!ENTITY capitulo1 SYSTEM "a:\cap1.sgm <!ENTITY capitulo2 PUBLIC -//jcr//Capitulo 2 da tese//PT <!ENTITY fig1 PUBLIC -//jcr//Figura 1//PT" "a:\fig1.gif
Aqui esto as trs hipteses para a declarao de uma entidade externa: identicador do sistema, identicador pblico, e identicador pblico mais identicador de sistema (este ltimo ter precedncia na maior parte das situaes.
Como foi referido, a utilizao de identicadores pblicos um mecanismo indirecto para o endereamento de cheiros que relega para um catlogo a misso de emparelhar os identicadores com os cheiros do sistema. Apresenta-se a seguir um exemplo de um pequeno catlogo que deveria acompanhar o exemplo anterior.
Exemplo 4-12. Identicadores pblicos e o Catlogo O catlogo referente s declaraes anteriores teria o seguinte aspecto:
PUBLIC -//jcr//Capitulo 2 da tese//PT" "a:\cap2.sgm" PUBLIC -//jcr//Figura 1//PT" "a:\fig1.gif" ...
A utilidade mais bvia deste mecanismo a movimentao de cheiros. Se pretendssemos mover os cheiros no sistema para uma directoria diferente s
69
teramos de alterar as respectivas paths no catlogo, caso contrrio teramos que percorrer todos os documentos no nosso sistema e fazer a alaterao em todos os que inclussem as entidades em causa (lembrar que as entidades so reutilizveis em vrios documentos).
As entidades externas so referenciadas como todas as outras que vimos at agora.
Exemplo 4-13. Referncia a uma entidade externa Sintaxe da referncia: & identicador ; Exemplo: ... &capitulo1;...
A seguir apresenta-se um exemplo que mostra como as entidades externas foram utilizadas para modularizar a escrita desta tese seguindo o esquema apresentado na Figura 4-3.
Exemplo 4-14. Entidades externas e escrita modular de documentos

<!DOCTYPE BOOK PUBLIC -//Davenport//DTD DocBook V3.0//EN" [ <!ENTITY captulo1 SYSTEM "chap-doc-est.sgm" Documentao Estruturada-> <!ENTITY captulo2 SYSTEM "chap-int.sgm" -Introduo-> <!ENTITY captulo3 SYSTEM "chap-sgml.sgm" -SGML-> <!ENTITY prefacio SYSTEM "prefacio.sgm" -teste de mdulos-> ]> <BOOK LANG="pt <BOOKINFO> <BOOKBIBLIO> <TITLE>Anotao Estrutural de Documentos ... &captulo1;
70
&captulo2; &captulo3; ...
As entidades externas podem ainda ser usadas para incluir num documento objectos externos como imagens, audio ou video.
4.3.2.3.5. Entidades paramtricas Uma entidade paramtrica normalmente utilizada na construo do DTD. A sua declarao semelhante s outras apenas leva o sinal de percentagem, %, depois da palavra chave ENTITY . Pode ser denida uma entidade geral com o mesmo nome desde que se omita o sinal de percentagem.
Exemplo 4-15. Entidades Paramtricas

<!ENTITY % UmaEntidade "(paragrafo | lista) <!ENTITY UmaEntidade "Isto uma entidade.
Para que seja possvel distinguir as referncias a entidades paramtricas das referncias a entidades gerais (uma vez que podem ter o mesmo nome), substitui-se o caracter limitador de incio, "&", pelo caracter "%".
4.3.2.4. Instrues de Processamento

Uma instruo de processamento contm informao especca para uma aplicao que ir processar o documento SGML. Ao contrrio das outras declaraes, uma instruo de processamento no tem regras ou estrutura a seguir, tudo vlido dentro dos limitadores que so respectivamente "<?"e "?>". O contedo de uma instruo de processamento comea normalmente por uma palavra chave signicativa para uma das aplicaes que ir processar o documento a seguir. Segue-se um espao que separa a palavra chave do cdigo da instruo de
71
processamento. assumido que a sintaxe faz sentido para alguma das aplicaes que a seguir ir processar o documento caso contrrio, o seu contedo ser simplesmente ignorado.
Exemplo 4-16. Instruao de Processamento

... <paragrafo>Seria bom se a pgina terminasse aqui... <?TeX \newpage?> <?HTML <P><HR>?> </paragrafo> ...
Pretende-se que, quer na gerao para LaTeX quer na gerao para HTML fosse introduzido um separador mais forte no meio do pargrafo. Assim, colocaram-se duas instrues de processamento uma para TeX e outra para HTML. claro que esta no a maneira de fazer as coisas respeitando a losoa do SGML, estamos a adicionar informao especca dependente de plataformas. A maneira correcta de fazer o mesmo seria inserir um elemento vazio que marcaria a quebra de pgina. De qualquer forma estaramos a violar parcialmente a losoa do SGML pois estaramos a introduzir um elemento com conotaes semnticas de forma e no de estrutura.
4.3.3. Instncia
A instncia o documento propriamente dito e que composto por:
texto - contedos. anotaes - que delimitam os elementos estruturais. uma referncia ao DTD (caso este no esteja presente no documento).
72
Usa-se o termo instncia porque se trata de uma realizao concreta duma classe de documentos que tem a estrutura denida por um DTD. A ttulo de exemplo apresenta-se uma instncia dum documento do tipo CARTA cujo DTD foi denido no incio deste captulo (Exemplo 4-3).
Exemplo 4-17. Instncia de CARTA

<!DOCTYPE CARTA SYSTEM "carta.dtd <CARTA> <DEST>Meus amigos</DEST> <ABERTURA>Carssimos,</ABERTURA> <CORPO> <PARA>Na impossibilidade de poder contactlos a todos de forma mais personalizada, envio esta carta electrnica com os meus votos de: UM BOM NATAL e BOAS ENTRADAS num novo ano que muito promete.</PARA> </CORPO> <FECHO>At ao novo ano</FECHO> </CARTA>
Termina aqui a nossa travessia do SGML. No prximo captulo iremos descrever o ciclo de vida de um documento SGML: que fases, que ferramentas, que outros standards interagem com o SGML, e por m como obter um produto nal de toda esta tecnologia. No podamos deixar de fazer aqui uma referncia ao arquivo universal de SGML, onde o utilizador poder encontrar tudo o que desejar desde bibliograa at software, agora mantido pela organizao no governamental OASIS responde no endereo internet: http://www.oasis-open.org/cover
73
Captulo 5. O Ciclo de Desenvolvimento dos Documentos SGML

Os documentos SGML tm um ciclo de desenvolvimento muito bem denido que se pode observar na Figura 5-1. Figura 5-1. Ciclo de desenvolvimento dos documentos SGML
Eve Maler e Jeanne Andaloussi dedicaram um livro [MA96] a este ciclo de desenvolvimento, com especial relevo na fase de anlise. Trata-se de uma publicao que um marco na bibliograa desta rea pois trouxe um pouco de ordem a um universo que estava bastante catico: detalham-se todos os passos, enumeram-se os formalismos que os suportam e traa-se um perl da evoluo nesta rea. O que a seguir se apresenta um pequeno resumo que inclui esta e outras abordagens que serve para dar uma ideia do que este ciclo de desenvolvimento. Como se pode vericar, o ciclo comea numa fase de anlise. Esta fase muito semelhante fase de anlise com que habitual iniciar o desenvolvimento de um sistema de informao tradicional; neste caso o resultado a denio de um DTD. As fases seguintes tm nomes bastante elucidativos: edio/criao, validao, armazenamento e formatao/distribuio. Nas prximas subseces iremos debruar-nos sobre cada uma delas.
74
5.1. Anlise Documental

semelhana de outras reas da informtica, a anlise aparece aqui como uma disciplina de modelao de informao, i. e., construo de uma abstraco da realidade mais fcil de manusear que o objecto real. O objectivo desta fase o de compreender todas as componentes, ou elementos, que constituem uma dada famlia de documentos, bem como as relaes entre eles, de modo a ser possivel desenhar o respectivo DTD com rigor. No existe, porm, para um dado contexto, uma nica estrutura documental espera de ser descoberta. Cada um v aquilo que pretende de acordo com as suas necessidades aplicacionais, como se ilustra no exemplo a seguir.
Exemplo 5-1. A Inexistncia de uma estrutura nica Veja-se o seguinte texto para o qual se pretende desenhar um DTD:
Eis um pargrafo que no contm listas. 1. Primeiro item de uma lista. 2. Segundo item da lista.
Uma anlise que podemos fazer a de que documentos deste tipo contm um corpo com dois elementos - pargrafos e listas - e que a lista ordenada est no mesmo nvel hierrquico do pargrafo. Por outras palavras, listas e pargrafos podem ocorrer dentro de seces; no entanto, uma lista no pode ocorrer dentro de um pargrafo e um pargrafo no pode ocorrer dentro de uma lista, resultando uma estrutura lgica do gnero esquematizado na gura abaixo.
Alternativamente, olhando para o texto do exemplo acima nada indica que o pargrafo est terminado quando a lista comea. Assim, outra possvel anlise
75
concluiria que a lista um subelemento do pargrafo e ocorre somente dentro de pargrafos.
O SGML pode facilmente albergar pequenas variaes da estrutura da mesma informao. Cada pessoa traz uma experincia diferente consigo. Por exemplo, escritores de documentao tcnica tm requisitos diferentes, e como tal diferentes vises, dos programadores de bases de dados. Daqui preciso reter que os resultados da anlise documental sero tanto melhores quanto maior e mais representativo fr o envolvimento de futuros utilizadores da aplicao, na equipe de anlise. Desenvolver um DTD deixando de parte um grupo de utilizadores pode resultar numa omisso de elementos que so importantes para esse grupo. O senso comum um ingrediente indispensvel para assegurar a qualidade de um DTD. Quanto mais pessoas estiverem envolvidas no desenvolvimento do DTD menos chances h de que existam omisses ou grandes erros. A anlise documental composta pelas seguintes etapas:

Determinao da rea de aplicao. Denio de uma estratgia para o DTD. Identicao dos utilizadores. Escolha de um nome para o DTD. Reconhecimento dos elementos lgicos do tipo de documento em causa. Escolha entre elementos e atributos. Determinao da estrutura hierrquica para o tipo de documento e dos diagramas de estrutura dos contedos dos elementos.
5.1.1. Determinao da rea de aplicao

Normalmente, quando uma empresa resolve aderir tecnologia baseada em SGML, pretende reformular todo o seu sistema de suporte documentao, i. e., pretende que todos os documentos que circulam na empresa estejam integrados, classicados,
76
e que obedeam todos mesma losoa. Tudo isto faz com que o primeiro passo da anlise passe pela identicao dos tipos de documento que circulam e habitam no universo que se pretende remodelar. Eric van Herwijnen [Her94] diz em relao a este ponto: quando se est a pretender aplicar SGML para sistematizar/formalizar um universo documental, est-se a tentar aplicar ordem ao caos. A ideia agrupar documentos com propriedades semelhantes em classes. Por exemplo, documentos encontrados nas prateleiras de uma biblioteca so livros; textos que so enviados de uma pessoa para outra usando algum sistema de correio so cartas; documentos produzidos para descrever a utilizao de produtos so manuais.
5.1.2. Denio de uma estratgia para o DTD

Um DTD desenhado de raz para documentos que vo ser criados diferente de um DTD desenhado para suportar documentao j existente (o que acontece quando j existe um patrimnio documental). Portanto, nesta etapa, devemos interrogar-nos sobre os objectivos do DTD que estamos a desenhar, sobre o seu contexto, e sobre a sua compatibilidade com documentos ou DTDs j existentes.
5.1.3. Identicao dos utilizadores

necessrio identicar os potenciais utilizadores para que todos sejam ouvidos. Isto evitar omisses e algum conito quando mais tarde aqueles forem confrontados com o produto nal.
5.1.4. O nome do DTD

Para aqueles que se habituaram a um modo de funcionamento anrquico, o SGML vai causar-lhes alguma frustrao pois reduz o grau de liberdade do utilizador; e isto vai reectir-se a vrios nveis. Um deles, o nome com que se vai baptizar o DTD. Este deve ser elucidativo do tipo de documento que representa e dever tambm coincidir com o elemento do topo da hierarquia denida para esse tipo de documento.
77
5.1.5. Os elementos lgicos do DTD

Um dos resultados da anlise uma lista de elementos, atributos e entidades. Os atributos e as entidades no fazem parte da estrutura hierrquica do documento. Os primeiros identicam propriedades dos elementos. Os ltimos reetem a organizao fsica do documento e esto relacionados com a forma de armazenamento e manuseamento do documento. Nesta fase, o objectivo obter uma descrio da estrutura do documento; interessa, portanto, encontrar e distinguir os elementos que logicamente compem o documento. O ponto de partida poder ser a criao duma lista de todos os elementos que se possam distinguir nos documentos pertencentes ao tipo de documento que se pretende especicar. Veja-se o seguinte memorandum (escrito em SGML):
Exemplo 5-2. Memorandum (SGML)

<!DOCTYPE MEMO SYSTEM "memo.dtd <MEMO> <PARA>Camarada Napoleo</PARA> <DE>Bola de neve</DE> <CORPO> <P>Na obra intitulada "A Quinta dos Animais", George Orwell escrevia: <C>... os porcos tinham muito trabalho, diariamente, com umas coisas chamadas ficheiros, relatrios, minutas e memos. Estes eram grandes folhas de papel que tinham de ser cuidadosamente cobertas com escritos, assim que estivessem cobertas eram queimadas na fornalha...</C> Ser que o SGML teria ajudado os porcos? Qual a tua opinio?</P></CORPO> </MEMO>
No exemplo acima os elementos lgicos so:
78
O elemento MEMO que contm todo o memorandum. O elemento PARA que contm a identicao do destinatrio do memo. O elemento DE que contm a identicao do emissor. O elemento CORPO que contm a parte textual do memo. O elemento P que contm o texto dum pargrafo. O elemento C que contm o texto duma citao.
Durante este processo h questes que devem estar sempre presentes: Preciso mesmo de distinguir este elemento? Que que quero fazer com ele? Para que este processo seja o mais completo possvel, o analista deve munir-se de vrios documentos exemplo pertencentes ao mesmo tipo/classe, e deve rodear-se ou escutar os futuros clientes e utilizadores desses documentos. Isto, na tentativa de cobrir todos os ngulos do problema. Para o DTD dos memorandus, apesar de no estarem presentes no documento exemplo apresentado, podamos ainda identicar elementos como ASSUNTO e ASSINATURA, ou mesmo um elemento mais complexo que visaria registar o percurso do documento dentro da instituio. Por ltimo, devem ter-se presentes os processamentos a que iro ser submetidos os documentos. Cada processamento pode ter implicaes na estrutura. O conjunto nal de elementos dever suportar todos estes requisitos.
5.1.6. Elemento ou atributo?

Sempre que tentamos criar modelos para objectos do mundo real, somos confrontados com alguns casos marginais, os casos de fronteira. O desenho de DTDs no diferente. Aqui o caso fronteira surge quando na especicao de um elemento somos levados a hesitar entre elemento e atributo.
Exemplo 5-3. Elemento ou Atributo? Um bom exemplo de um caso marginal surge na linguagem de descrio de pginas da Internet, o HTML. Em HTML os hyperlinks so denidos por elementos anchor
79
<A>. Este elemento pode ter a ele associado uma srie de informao: o texto; o URL para onde o browser dever ir caso o link seja selecionado; um identicador que identica unicamente o elemento; ... Na denio do HTML (em SGML) o URL denido como um atributo, de nome HREF, do elemento anchor. Um link em HTML corrente tem a seguinte forma:
...
<A HREF="www.di.uminho.pt/~jcrHome de Ramalho</A>...
Se pensarmos um pouco em termos de estrutura, o URL poderia perfeitamente ser um subelemento do elemento A. Ou seja, alternativamente poderamos denir o elemento em causa com dois subelementos, LABEL e HREF, de modo a obedecer seguinte estrutura:
... <A><LABEL>Home de Ramalho</LABEL><HREF>www.di.uminho.pt/~jcr</HREF><
As duas formas tm a mesma informao, mas a segunda tem mais estrutura. O que poder ter levado os analistas do HTML a optar pela primeira forma ter sido o processamento semntico que feito dos links pelos browsers; a forma adoptada facilita parte desse processamento. No entanto, a dvida "atributo ou elemento?"deve ter persistido durante algum tempo.
Este problema crtico no tem, como boa parte dos problemas de engenharia, uma soluo nica, denitiva; ser resolvido, caso a caso, procurando a melhor soluo de compromisso. Contudo, apresentam-se a seguir alguns princpios que podero ajudar a desambiguar:
A informao estrutural? Um objecto que por natureza deve estar obrigatoriamente presente na estrutura (por exemplo, o remetente ou o destinatrio de uma carta) um bom candidato a elemento. A informao qualica o contedo ou faz parte de um padro repetitivo? Uma carta pode ter a ela associada um indicador que identica o seu tipo como "privada"ou "negcios", no estando relacionado estruturalmente com o elemento carta. Sempre que tivermos informao que pode ser descrita por um valor pertencente a uma lista enumerada, temos um bom candidato a atributo. A informao est relacionada com o aspecto visual? Os atributos no devem ser usados para descrever o aspecto visual da informao. Por exemplo, se
80
pretendermos realar certas partes do texto, no devemos faz-lo recorrendo a atributos, mas sim recorrendo a um novo elemento.
A informao requer um processamento especial? Esta questo no muito evidente para quem nunca tenha implementado um processador de SGML, mas pertinente. O que no evidente que quando se opta por utilizar SGML estamos a optar por trabalhar com documentao estruturada em todas as fases do ciclo de vida. O processamento no excepo e orientado pela estrutura do documento, pelos elementos. No processamento, os atributos aparecem como algo secundrio a que se pode aceder em caso de necessidade para melhor qualicar o processamento, mas o seu contedo visto como um bloco. Portanto no deve colocar-se estrutura no valor de um atributo e qualquer item de informao que requeira um processamento especial deve ser um elemento e no atributo.
5.1.7. Determinao da estrutura hierrquica

Logo que todos os elementos de um dado tipo de documento tenham sido determinados, necessrio especicar as relaes entre eles. No exemplo Exemplo 5-2, o elemento MEMO a raiz da estrutura hierrquica, por isso, contm todos os outros. Por sua vez, os elementos PARA e DE no tm estrutura, apenas texto; o elemento CORPO contm uma sequncia de pargrafos que por sua vez podem conter texto com alguns elementos pelo meio que identicam citaes. Esta estrutura hierrquica pode ser observada na Figura 5-2. Figura 5-2. Estrutura hierrquica do memorandum
81
A rvore estrutural do documento d uma boa maneira de visualizar a sua estrutura; s vezes, torna-se difcil olhar para um texto anotado e tentar perceber qual a sua estrutura. No entanto, a rvore do documento no tem informao nenhuma sobre a frequncia de cada um dos elementos: no nos diz quais so opcionais, e no distingue os que podem aparecer com repeties. Para isso teremos que recorrer a outra representao pictrica: os diagramas de estrutura.
5.1.8. Diagramas de Estrutura

At agora, como resultado da anlise documental, temos um conjunto de elementos e a estrutura hierrquica onde estes se inserem. Daqui at ao que necessrio para escrever um DTD ainda existe alguma distncia. Os diagramas de estrutura surgem para colmatar essa diferena. Um diagrama de estrutura uma representao pictrica de um DTD, sem atributos (estes no tm representao no diagrama). Para a construo do diagrama de estrutura dum determinado tipo de documento parte-se da rvore esboada na seco anterior (Seco 5.1.7). Faz-se uma travessia da rvore de cima para baixo e da esquerda para a direita (depth-rst). A cada n da rvore vai corresponder um dos oito tipos de diagramas de estrutura. O diagrama de estrutura de cada um dos ns desenhado olhando para os lhos desse n e especicando para cada um deles, o seu tipo de frequncia. Para obtermos o diagrama de estrutura do memorandum (Exemplo 5-2), partiramos da rvore denida (Figura 5-2) e atravessla-amos da maneira indicada em Figura 5-3; para cada n desenharamos o respectivo diagrama de estrutura usando os oito tipos de diagrama que se descrevem a seguir.
82
Figura 5-3. Travessia da rvore
H oito tipos de diagrama de estrutura. Cada um corresponde a uma das estruturas bsicas que um dado n pode ter:
1. Um elemento dentro de uma caixa signica que esse elemento aparece uma vez. Figura 5-4. Um elemento
2. Uma caixa seguida de outra, em srie, signica que o elemento da primeira caixa precede o segundo e que ambos ocorrem uma vez. Figura 5-5. Sequncia
3. Duas caixas em paralelo signica que um dos elementos ter de estar presente,
83
mas apenas um. Figura 5-6. Alternativa
4. Duas caixas em srie, em paralelo, com a mesma srie invertida, signica que ambos os elementos devem aparecer mas a ordem livre. Figura 5-7. Qualquer ordem
5. Uma caixa com uma seta de feedback signica que o elemento deve aparecer uma ou mais vezes. Figura 5-8. Uma ou mais vezes
6. Uma caixa com uma seta a fazer-lhe um "bypass"signica que o elemento opcional. Figura 5-9. Opcional
84
7. Uma caixa com uma seta de feedback e outra de "bypass"signica que o elemento pode aparecer um nmero indenido de vezes (zero ou mais vezes). Figura 5-10. Zero ou mais vezes
8. Uma caixa, igual ao primeiro diagrama, mas com um tringulo negro no canto inferior direito, usada se um nodo no tiver subnodos, fr uma folha. Figura 5-11. Elemento terminal
Vamos ento ver quais os diagramas de estrutura resultantes da travessia da rvore do memorandum:
Primeiro nodo (marcado com 1 na Figura 5-3) respeitante ao elemento MEMO. Tem 3 subnodos, PARA, DE, CORPO. At agora nada foi dito sobre a sua sequncia ou frequncia. Para tornar o exemplo interessante e elucidativo vamos assumir que CORPO vem no m e que a ordem dos outros dois irrelevante. Estes pressupostos dariam origem ao seguinte diagrama: Figura 5-12. Diagrama de Estrutura do elemento MEMO
85
Segundo nodo (marcado com 2): o elemento PARA terminal, o seu contedo apenas texto. Figura 5-13. Diagrama de Estrutura do elemento PARA
Terceiro nodo (marcado com 3): o elemento DE tambm terminal. Figura 5-14. Diagrama de Estrutura do elemento DE
Quarto nodo (marcado com 4): o elemento CORPO composto por um ou mais pargrafos (P). Figura 5-15. Diagrama de Estrutura do elemento CORPO
Quinto nodo (marcado com 5): o elemento P tem aquilo que se designa por contedo misto - essencialmente texto mas podem aparecer algumas citaes pelo meio.
86
Figura 5-16. Diagrama de Estrutura do elemento P
Sexto nodo (marcado com 6): o elemento C composto por texto. Figura 5-17. Diagrama de Estrutura do elemento C
Como o leitor atento pode j ter constatado existe quase uma correspondncia de um para um entre os tipos de diagramas de estrutura e os operadores de conexo e de ocorrncia que se usam para escrever o DTD. Assim, e no caso do memorandum, para escrever o DTD basta escrever a declarao correspondente ao diagrama de estrutura que se determinou para cada elemento. Apresenta-se a seguir o DTD para o memorandum (Exemplo 5-4).
Exemplo 5-4. DTD correpondente aos DEs do Memorandum

<!- DTD para o MEMORANDUM - jcr - 99.01.09 -> <!- Elemento MEMO -> <!ELEMENT MEMO - - ((PARA & DE) , CORPO)> <!- Elemento PARA -> <!ELEMENT PARA - - (#PCDATA)> <!- Elemento DE -> <!ELEMENT DE - - (#PCDATA)> <!- Elemento CORPO -> <!ELEMENT CORPO - - (P+)>
87
<!- Elemento P -> <!ELEMENT P - - (#PCDATA | C)*> <!- Elemento C -> <!ELEMENT C - - (#PCDATA)>
As metodologias de anlise baseadas em grasmos so de particular importncia em projectos onde o dilogo com interlocutores no informticos necessrio. Foi apresentada uma metodologia que assenta numa especicao grca: rvore hierrquica de componentes e diagramas de estrutura para cada um dos nodos. Para documentos de grande complexidade esta separao pode levar a algumas diculdades na sua leitura pelo que, mais recentemente, surgiu a ideia de fundir as duas etapas. O formalismo grco foi designado por ELM-tree (Element Lucid Model - tree) e introduzido em grande detalhe por Maler e Andaloussi [MA96]. A ttulo de exemplo apresenta-se na gura seguinte a ELM-tree para o memorandum. Figura 5-18. ELM-tree do Memorandum
5.2. Edio de Documentos SGML

Esta fase corresponde criao das instncias documentais SGML.
88
Em princpio, qualquer editor de texto pode servir para escrever um documento SGML. Mas, se quisermos tirar partido, durante a edio, do DTD criado teremos que usar um tipo especco de editor - um editor de SGML. Um editor de SGML no mais do que um editor estruturado parametrizvel pelo DTD, i.e., um editor que lendo um DTD vai ser contextualmente sensvel a esse DTD. Em primeiro lugar, tais editores ajudam o escritor a marcar o seu texto sem ter de saber de cor a sintaxe de todas as anotaes em uso; em segundo lugar, possibilitam a validao estrutural imediata do documento que est a ser editado e outros tipos de pequenas validaes que no seu conjunto do uma grande ajuda ao utilizador na produo de documentos estruturalmente correctos. Durante o trabalho experimental desta tese, foram vrios os editores testados e utilizados em diversos projectos, a saber: FrameMaker+SGML, Emacs+PSGML, Wordperfect8, AuthorEditor, Documentor, XMetal. No Seco A.2 apresenta-se uma anlise crtica desses editores utilizados. No caso da escolha do editor recair num editor SGML, preciso fazer a sua congurao, trabalho que requer conhecimentos especcos ou, alternativamente, a interveno do analista que desenvolveu o DTD. A congurao dum editor relativamente a um DTD consiste na compilao deste, isto porque o editor usa os DTDs num formato binrio que permite uma maior velocidade em tudo o que diz respeito validao contextual e este formato obtem-se compilando o DTD com uma ferramenta prpria que normalmente acompanha o editor. Depois de compilado, o DTD adicionado biblioteca de DTDs do editor cando disponvel para orientar a edio de documentos do tipo nele especicado.
5.3. Validao
A possibilidade de validao uma das mais-valias que a documentao estruturada trouxe para o universo do processamento e edio documental. Mais especicamente, referimo-nos validao estrutural, possibilidade de vericar se a estrutura dum determinado documento respeita um determinado DTD. Esta tarefa/fase reveste-se de especial importncia quando o que est em causa um sistema baseado em SGML. Um sitema destes gira em torno da validao estrutural. Esta realizada na edio para validar a introduo do documento, na formatao, na transformao e at na insero numa base de dados.
89
Neste caso, esta tarefa da responsabilidade dum parser ou de um meta-parser se nos referirmos ao SGML como meta-linguagem. Independentemente da designao que lhe fr atribuda trata-se de um parser diferente, congurvel por uma especicao de estrutura, um DTD, e este DTD que vai orientar o reconhecimento e validao do documento. Normalmente, os parsers de SGML no aparecem como ferramentas isoladas mas sim integrados noutras aplicaes como editores estruturados, formatadores/tranformadores, bases de dados documentais, e outras. Quando a aplicao invoca a aco de parsing para validar o documento, o parser percorre o documento vericando se este obedece s regras especicadas no DTD e produz dois resultados: um uma lista de erros que, caso esteja tudo bem, vazia; o outro um texto declarativo correspondente travessia da estrutura de dados interna usada para guardar o documento durante o processo de reconhecimento. Quanto s mensagens de erro, estas variam de acordo com a qualidade do parser. Relativamente linguagem/formato usado para a sada dos dados da travessia, pode haver algumas variaes mas h uma assumida como standard: o ESIS Element Structure Information Set. O ESIS uma adapatao da notao usada em muitos sistemas funcionais tipo LISP, as expresses-S. A ttulo de exemplo apresenta-se a seguir o cheiro, em formato ESIS, resultante da aplicao do parser ao memorandum do Exemplo 5-2.
Exemplo 5-5. Memorandum em formato ESIS

(MEMO (PARA -Camarada Napoleo )PARA (DE -Bola de neve )DE (CORPO (P -Na obra intitulada "A Quinta dos Animais", George Orwell escrevia:\n (C
90
-... os porcos tinham muito trabalho, diariamente, com umas coisas \nchamadas ficheiros, relatrios, minutas e memos. Estes eram grandes folhas\nde papel que tinham de ser cuidadosamente cobertas com escritos, assim que\nestivessem cobertas eram queimadas na fornalha... )C Ser que o SGML\nteria ajudado os porcos? Qual a tua opinio? )P )CORPO )MEMO
Cada linha do texto apresentado no exemplo acima tem um signicado muito preciso. Descreve-se a seguir os elementos principais da notao utilizada: (elem-id Incio do elemento com identicador elem-id. Se o elemento tiver atributos, eles j deveriam ter aparecido em linhas com prexo A. )elem-id Fim do elemento cujo identicador elem-id. -texto Contedo do ltimo elemento iniciado. Anome valor O prximo elemento a ser iniciado ter um atributo de nome nome com o valor valor. ?proc-inst Instruo de processamento proc-inst.
91
Muitas vezes, o parser invocado no porque seja necessria a validao mas porque necessrio o formato ESIS do documento (o que acontece na formatao, como se poder ver na Seco 5.5). Como se cabou de ver, o ESIS um formato em que a informao tem um prexo que a identica; torna-se, por isso, um formato ideal para processamento de documentos. A identicao e a estrutura geradas (que compem o ESIS) so apenas uma viso diferente mas equivalente da estrutura presente no documento atravs das anotaes e validada pelo DTD. A construo dum parser para SGML uma tarefa bastante complicada devido a algumas particularidades do SGML. Por exemplo, uma das que levanta mais problemas o operador & que indica a possibilidade combinatria dos seus operandos. Por isso, no surpresa que at hoje no tenha havido muitas iniciativas para a implementao de parsers de SGML. Porque a pea central de um sistema baseado em SGML, apresentam-se a seguir os parsers existentes: SP: James Clarks SGML Parser Um dos ltimos parsers a ser desenvolvido e talvez o mais actual e completo [SP]. No bem um parser mas sim uma biblioteca de parsing desenvolvida seguindo uma losoa orientada a objectos. utilizada na maior parte dos produtos SGML, comerciais ou no. SGMLS: James Clarks SGMLS parser O antecessor do SP [SGMLS]. ARC-SGML: Charles Goldfarbs Almaden Research Center SGML Parser Um dos primeiros parsers a aparecer em pblico [ARCSGML]. Foi desenvovido enquanto o standard era escrito para validar este ltimo. Foi o antecessor do SGMLS. ASP-SGML: Jos Warmers Amsterdam SGML Parser Um dos primeiros a ser desenvolvido tambm. Resultou de uma experincia acadmica na Universidade de Amsterdo [ASP].
92
YASP: Pierre Richards Yorktown Advanced SGML Parser (or: Yet Another SGML Parser) Desenvolvido em 1997 e programado em C++ [YASP]. No to utilizado como os outros. YAO (Yuan-ZeAlmadenOslo project) Parser Materials YAO um projecto criado no seio da comunidade SGML [YAO], que visa o desenvolvimento de pacotes de ferramentas para o utilizador, o analista e o programador de SGML com o requisito de que tudo livre de direitos comerciais. Deste projecto, resultou uma biblioteca de parsing desenvolvida, seguindo uma losoa orientada a objectos. Os parsers acima enumerados foram desenvolvidos usando vrios paradigmas de programao, embora a maior parte tenha seguido o paradigma da programao orientada a objecto. No entanto, no que diz respeito s tcnicas de parsing e compilao propriamente ditas todos seguiram a abordagem tradicional da traduo dirigida pela sintaxe. No mbito desta tese, avanou-se com a implementao de um ambiente de programao de documentos SGML (Seco 9.2), onde se seguiu a abordagem da traduo dirigida pela semntica (baseada em gramticas de atributos), que resolve directamente alguns problemas do parsing de SGML.
5.4. Estilo e especicao da Forma

Tendo acabado de escrever o DTD, esta a altura ideal para pensar no estilo de apresentao que se quer associar a cada um dos elementos. uma tarefa que envolve alguma complexidade e uma vez que o assunto est relacionado com a formatao, deixaremos para a Seco 5.5 a sua descrio.
5.5. Formatao e Transformao

Neste momento, o leitor atento j tem uma boa ideia do que um documento SGML e algumas perguntas devem estar a perturb-lo: O que se faz com um
93
documento SGML? Como se consegue obter uma cpia em papel num dado formato? Como que distribudo populao alvo? Quem opta por uma soluo SGML tem de estar consciente de que est a optar por uma soluo que separa o contedo da formatao. Nas seces anteriores mostramos como que se pode produzir um contedo independente de plataformas de software ou hardware. Agora, vamos ver como que podemos produzir, a partir desse contedo, a forma nal desejada. Duma maneira geral, o que se pretende fazer com um documento SGML transform-lo: simplesmente traduzi-lo para RTF, PDF, ou HTML; ou converter a sua estrutura numa estrutura nova dando origem a um novo documento. Neste contexto, a formatao aparece como a preocupao mais imediata de quem produz documentos, mas no mais que um caso particular da transformao. Uma soluo simples e directa para o problema seria a criao de ferramentas especcas para resolver cada caso particular - uma soluo ainda praticvel para pequenos casos. Bastaria adoptar, alternativamente, um parser (como vimos na Seco 5.3 alguns destes so disponibilizados como bibliotecas para permitir que os utilizadores os congurem e utilizem medida das suas necessidades) e acrescentar-lhe o cdigo necessrio para realizar a transformao do documento. Ou ainda, adquirir uma ferramenta de transformao que traz um parser embutido e fornece, em termos de programao, uma srie de operadores que facilitam esta tarefa) e program-la para realizar a converso. Esta ltima foi durante algum tempo, e ainda , uma via aberta para a soluo do problema. No entanto, contraria a losoa que tem vindo a ser seguida desde a criao do documento: a inexistncia de dependncias em relao a plataformas e a utilizao de um formalismo declarativo para especicao da estrutura e anotao do contedo. Para conservar estas caractersticas era necessrio um mtodo normalizado para a especicao da transformao e formatao de um documento SGML. Estavam ento reunidas as condies para o lanamento de um standard para a especicao da transformao/formatao de documentos SGML. Foi assim que em 1996, foi publicado o DSSSL, Document Style and Semantics Specication Language, o standard ISO/IEC 10179:1996. Devido importncia e diculdade deste tema, criou-se um captulo especco nesta tese para a sua discusso Captulo 6.
94
5.6. Armazenamento
Quem trabalha com documentao estruturada tem por objectivo, tirar partido dessa estrutura para outros ns como: extrair partes; poder realizar procuras inteligentes sobre os documentos; criar ndices; extrair partes para construir novos documentos por composio; etc. Para isso necessrio armazenar os documentos num ambiente que permita, posteriormente, realizar aquelas operaes sobre eles. Hoje em dia, banal a associao das bases de dados com o termo armazenar. No entanto, neste contexto, a soluo no to simples, h que ter em conta a estrutura da informao e a ecincia do sistema de suporte que se ir utilizar. Actualmente, podemos dividir o leque de solues de armazenamento de documentos SGML em trs: 1. Armazenar os documentos no sistema de cheiros do prprio sistema operativo do computador - no uma soluo to inocente quanto aparenta! Os documentos tm a estrutura visvel atravs das anotaes e, se o sistema possuir um conjunto de ferramentas SGML batch que possa ser utilizado para a implementao das procuras e outras operaes pretendidas, o problema ca resolvido (com alguma redundncia e confuso a nvel de cheiros, uma vez que DTDs, documentos, entidades e ferramentas de software convivem todos no mesmo espao). 2. Armazenar os documentos numa base de dados relacional - parece uma soluo bvia, mas no . primeira vista, podemos ser levados a pensar que basta dividir um documento estruturado nos seus componentes e associar cada um destes a um campo da base de dados. Falso, o texto tem uma ordem linear inerente sua essncia. Por outro lado, no h qualquer relao de ordem entre os campos de uma tabela duma base de dados relacional. Assim, se tentssemos armazenar um documento estruturado numa base de dados relacional distribuindo os seus componentes pelos campos duma ou vrias tabelas estaramos a destruir a ordem linear do texto. Figura 5-19. Documentos Estruturados numa BDR
95
No entanto, e devido aos baixos custos que uma soluo baseada no modelo relacional representa, houve vrias tentativas nesta rea. A mais divulgada, utilizada e at usada como imagem de marca foi a proposta e implementada pela Omnimark [Omn98], designada por Micro-Document Architecture - MDA. Esta soluo parte dum princpio muito simples: analisa-se a estrutura de um documento e determina-se quais os elementos e subelementos que podem ser separados (que no necessitam da ordem linear do texto), esses elementos so armazenados cada um num campo de uma tabela; depois desta operao resta algum ou alguns subdocumentos para os quais a ordem linear dos seus elementos importante; estes, so armazenados cada um no seu campo memo que car associado a um mini-DTD tambm armazenado noutra tabela. Desta maneira, os campos de informao que foram separados podem ser utilizados em queries normais da base de dados, os outros podem ser geridos como blocos mas se quisermos algo mais inteligente como queries ao seu contedo estruturado teremos de envolver um motor de processamento de SGML externo, que faa uso, no s desse campo memo, mas tambm do mini-DTD a ele associado. Na gura Figura 5-19 apresenta-se uma possvel soluo para estruturar uma base de dados relacional para documentos do tipo MEMO. Por outro lado, na
96
gura Figura 5-20, pode-se ver a estrutura funcional que teria de ser montada para que o sistema respondesse a queries sobre o contedo estruturado dos documentos. Figura 5-20. Estrutura funcional dum sistema de query para uma BDR documental
3. Armazenar os documentos numa base de dados orientada a objectos - soluo cara mas ecaz. O modelo hierrquico de objectos modela directamente qualquer rvore documental portanto nada mais lgico do que utilizar este modelo para armazenar os documentos estruturados. Foi o que pensaram vrios construtores de software que desenvolveram vrios produtos equivalentes para armazenamento e gesto de documentos estruturados [DuC98], dos quais se destacam: o Astoria, da Chrystal; o Poet, da Poet; e o Infomanager, da Texcel. Deles s podemos dar uma opinio das demonstraes disponveis, pois o custo das licenas extremamente elevado e, quando contactados sobre a hiptese de um acordo com a Educao/Universidade, a sua receptividade foi nula. H, no entanto, outros produtos, como o Object Store, que no tendo sido desenvolvidos a pensar no SGML tm sido usados para esse m, principalmente em projectos de bibliotecas digitais, como a de Alicante Espanha - "Biblioteca Digital Miguel Cervantes"[DLMC]. De qualquer maneira, a problemtica do armazenamento sempre o ltimo ponto a
97
ser considerado num projecto. O sistema de cheiros um recurso utilizado at ao limite. A deciso de aquisio de um sistema de armazenamento sempre complicada face aos custos envolvidos. Com este captulo, encerramos esta panormica geral do que o mundo dos documentos SGML, como funciona, como composto, que interaces existem, quais os passos na implementao dum sistema destes. Nos prximos captulos iremos entrar na parte inovadora da tese: que lacunas foram detectadas nesta losoa de trabalho; que solues o autor prope para colmatar aquelas decincias.
98
Captulo 6. Documentos e Semntica

At agora discutimos uma tecnologia que nos permite padronizar a anotao e produo documental e at mesmo validar estruturalmente os documentos que esto a ser produzidos. No entanto, no abordamos ainda dois aspectos fundamentais que so: o contedo e o produto nal. Relativamente ao contedo, podemos interrogar-nos se no haver uma forma de garantir certas restries ou de impr certas condies de contexto que nos ajudem a detectar e a precaver erros semnticos que, quando acontecem, podem ter consequncias graves e embaraosas, como iremos ver em certos exemplos. Mas, nesta rea e enquando esta tese decorria no havia nada que permitisse de alguma maneira realizar esta tarefa. Da ter sido alvo de um estudo aprofundado que teve como resultados alguns dos contributos mais importantes desta tese. Este assunto foi baptizado de "Semntica Esttica" e discutido em detalhe no Captulo 7. A questo do produto nal mais crtica que a anterior pois quem produz um documento quer depois v-lo impresso ou distribu-lo; se tal no fosse possvel de certeza que no adoptaria a tecnologia em causa. Assim, surgiu um standard que visa normalizar a transformao dos documentos SGML nos vrios produtos nais pretendidos pelos utilizadores. Este processo discutido na Seco 6.2 que foi baptizada com o nome de "Semntica Dinmica". Reinventando a Roda? O facto de no existerem metodologias associadas ao SGML que nos permitam especicar a semntica esttica, no quer dizer que aquelas tenham de ser desenvolvidas de raz. Devemos procurar dentro do mesmo domnio se no haver j solues desenvolvidas capazes de serem adaptadas a este caso. Assim, na prxima seco, iremos estabelecer uma relao entre o processamento documental e o processamento das linguagens de programao, na tentativa de reaproveitar algumas solues. A seguir, apresenta-se uma seco dedicada semntica dinmica, mais relevante para o utilizador que quer ver o resultado nal logo que possvel, e por isso, de alguma maneira, j normalizada h alguns anos. No m, na seco dedicada semntica esttica, apresentam-se algumas das inovaes mais relevantes deste trabalho, com discusso de casos de estudo.
99
6.1. Documentos e Programas

Neste momento, podemos traar um paralelismo entre um documento SGML e um programa escrito numa linguagem de programao. Este paralelismo mais profundo do que parece; podemos mesmo arriscar e dizer que a evoluo que est a sofrer o processamento dos documentos a mesma j sentida no processamento das linguagens de programao. Assim, surgiu a ideia de estudar este paralelismo e ver se as solues adoptadas para as linguagens de programao poderiam ser aproveitadas para o processamento dos documentos estruturados, especialmente no campo do tratamento semntico que estava menos desenvolvido. A tabela seguinte apresenta o resultado da comparao destes dois universos das cincias da computao. Tabela 6-1. Documentos e Programas Instncia do Documento Linguagem de Anotao Conjunto de anotaes DTD Programa Linguagem de Programao Vocabulrio Gramtica
Podemos ver o DTD dum documento SGML como uma gramtica generativa formal. A partir daqui fcil estabelecer as relaes apresentadas na tabela. Assim como as gramticas so o cerne do processamento das linguagens de programao, tambm os DTDs sero o cerne do processamento dos documentos estruturados. As anotaes denidas no DTD correspondem ao vocabulrio da linguagem. Uma instncia documental escrita de acordo com um DTD equivalente a um programa escrito numa linguagem de programao. Um programa teve sempre de ser processado para que se obtivesse o cdigo executvel correspondente. O processamento de um programa, ainda hoje designado por compilao, compreendia e compreende as seguintes fases:

Anlise Lxica Anlise Sintctica Anlise Semntica Esttica
100
Gerao de Cdigo, tambm designada por Processamento da Semntica Dinmica
No incio, o modelo utilizado, e que ainda se utiliza, foi a Traduo Dirigida pela Sintaxe (TDS). Neste modelo, a anlise lxica evoluiu e os analisadores lxicos so gerados automaticamente a partir da sua especicao. A anlise sintctica tambm evoluiu nesse sentido e os analisadores sintcticos so tambm gerados automaticamente mediante a sua especicao, mas a anlise semntica no. Esta programada pelo autor da linguagem na linguagem hospedeira (linguagem utilizada para implementar os analisadores gerados nas outras fases da compilao). Se olharmos agora para o universo do SGML, o modelo TDS que se acabou de descrever corresponde ao estado actual de desenvolvimento do modelo de processamento do SGML. O parser de SGML realiza a anlise lxica e sintctica e a anlise semntica deixada para ser programada num ambiente externo. Em 1968, Donald Knuth introduziu uma nova abordagem: as Gramticas de Atributos [Knu68]. Com Gramticas de Atributos continuamos a poder manter a simplicidade das Gramticas Independentes de Contexto mas agora, com a possibilidade de dar signicado s frases custa de caracterizar os seus smbolos via atributos, e especicar a semntica atravs de equaes sobre esses atributos. Este novo formalismo deu origem a um novo modelo de processamento de linguagens de programao designado por Traduo Dirigida pela Semntica. De alguma forma, o trabalho desenvolvido nesta tese colocou o processamento documental no ponto em que se encontrava o processamento das linguagens de programao no incio dos anos 80. H um formalismo para especicar a semntica, preciso um motor capaz de o processar. No m deste captulo vamos ver as vrias hipteses estudadas e desenvolvidas para permitir a especicao de semntica em documentos estruturados, mas antes iremos ver de onde vem essa necessidade.
6.2. Semntica Dinmica: o DSSSL

Normalmente, no universo do processamento de linguagens de programao d-se o nome de "Semntica Dinmica" gerao de cdigo, devido ao facto de dessa gerao resultar o signicado operacional (a obter em tempo de execuo) do programa. Como nesta seco vamos abordar a gerao do documento nal,
101
partindo do documento estruturado original, por analogia com o processo de compilao, nada mais natural do que atribuir-lhe o mesmo nome. Como o interesse dos utilizadores pelo SGML era crescente, a indstria de software comeou a reagir. Estavamos no incio dos anos noventa e os editores estruturados baseados em SGML comearam a aparecer no mercado oriundos de esforos empresariais ou acadmicos. Como j foi referido vrias vezes ao longo deste documento, o SGML especica apenas estrutura, no fornece qualquer facilidade para a especicao de aparncia visual ou formato. Isto criou uma lacuna que comeou a ser colmatada da mais bvia mas pior maneira possvel. Cada editor de SGML tinha a sua linguagem prpria para associar estilo aos documentos SGML. A portabilidade do SGML estava assim ameaada, pois os documentos eram apenas parcialmente compatveis: o mesmo documento SGML podia ser transportado dum editor para outro sem perdas nem necessidade de alteraes estruturais ou de contedo, mas todo o estilo especicado dentro dum editor era automaticamente perdido quando o documento se manuseava num outro editor diferente. Foi, pois, na tentativa de normalizar o que faltava do processo que um comit ISO lanou o standard ISO/IEC 1079:1996 [Cla96], hoje conhecido como "Document Style Semantics and Specication Language"(DSSSL) . O DSSSL foi formalmente denido em SGML mas um pouco diferente das linguagens de anotao que normalmente se denem em SGML; isto deve-se ao facto de a operao de transformao/formatao necessitar de algum processamento. Assim foi preciso dotar o standard de uma linguagem de clculo. Adoptou-se um subconjunto do standard das linguagens funcionais, o Scheme; este subconjunto forma uma linguagem declarativa e em termos de processamento livre de efeitos laterais. Com este novo elemento, j possvel montar uma cadeia de processamento documental completamente standard. Essa cadeia compreende a criao/utilizao de trs cheiros e vrias aces/processos sobre eles:
primeiro h que denir a estrutura do documento que se quer criar utiliza-se o SGML na denio de um DTD, que normalmente guardado num cheiro com a extenso ".dtd". com um editor, especco de SGML ou no, cria-se a instncia do documento, que ser depois validada por um parser embutido no editor ou externo a este; normalmente as instncias dos documentos guardam-se em cheiros com a
102
extenso ".sgm".
uma vez criado o DTD pode e deve-se criar a especicao de estilo em DSSSL para esse DTD, que guardada num cheiro com a extenso ".dsl"; para que o sistema produza o resultado desejado, passam-se estes trs cheiros a um motor de formatao que percebe de SGML e DSSSL e que produz o resultado desejado: RTF, TeX, HTML, ou outro.
Fazer um motor de formatao capaz de entender SGML e DSSSL uma tarefa difcil e penosa. Decorridos j quatro anos desde a publicao do DSSSL apenas trs tentativas so dignas de registo: o SENG da empresa "Copernican Solutions", o Hybrick dos laboratrios "Fujitsu", e o Jade de James Clark [jade]. O ltimo foi o primeiro a surgir, e aparece dum esforo do editor do DSSSL. Hoje, continua a ser o mais utilizado quer na indstria quer no meio acadmico, facto a que no alheia a particularidade de se tratar de um produto livre de direitos comerciais. Mais frente voltaremos a referir-nos a esta ferramenta pois foi e continua a ser utilizada nos trabalhos realizados ao longo desta tese.
6.2.1. Componentes funcionais de especicao

O DSSSL esteve vrios anos em desenvolvimento e sofreu vrias alteraes nesse perodo. A complexidade que lhe inerente bastante alta o que justica a pouca bibliograa existente apesar dos esforos realizados nesse sentido; alm do texto do standard [Cla96], algumas tutoriais bastante superciais [Ken97, DuC97, Spe98], e duas mais recentes e mais completas [Ger96, Pre97], h apenas aquilo que se baptizou de "DSSSL Documentation Project"que um esforo global, levado a cabo atravs da Internet com a colaborao de todos os utilizadores de DSSSL, para a criao de um livro didctico [Mul98], que sirva quer a principiantes quer a utilizadores experientes. O modelo conceptual subjacente linguagem bastante complexo (Figura 6-1), pelo que vamos analisar a sua estrutura e depois cada uma das suas subcomponentes separadamente.
103
Figura 6-1. DSSSL - modelo conceptual
O DSSSL essencialmente uma linguagem de especicao na qual podemos distinguir quatro sublinguagens. Duas principais, para preparar o documento nal e format-lo:
uma linguagem para especicar a transformao de um ou mais documentos SGML num ou mais documentos SGML. uma linguagem para especicar a aplicao de atributos de formatao a um documento SGML.
E outras duas auxiliares:
uma linguagem de interrogao, Standard Document Query Language (SDQL), que se pode utilizar para identicar e seleccionar partes de um documento SGML. uma linguagem funcional de clculo de expresses, que um subconjunto do standard para as linguagens funcionais - Scheme, que serve de suporte e de ligao s outras linguagens.
Em termos de implementao, e referindo-nos ao jade, a nica sublinguagem totalmente implementada a de especicao da formatao. Todas as outras foram parcialmente implementadas, e continuam a s-lo medida das necessidades. Necessidades estas que tm a ver com a formatao dos documentos, e como a primeira necessidade dos utilizadores a que tem de ser servida primeiro para que a tecnologia seja adoptada e tenha sucesso.
104
6.2.2. Modelo Conceptual

Uma especicao DSSSL compreende duas partes:
uma especicao de transformao - h situaes em que o contedo do documento nal pretendido difere do original, um subconjunto ou corresponde a uma reordenao do contedo inicial; nestas situaes o documento original tem que passar por uma fase de transformao antes de ser formatado. uma especicao de estilo - que vai dirigir a formatao.
O transformador actua sobre o documento SGML de origem e transforma-o, de acordo com a especicao, dando origem a um novo documento SGML. Este novo documento por sua vez passado a um formatador que o vai formatar de acordo com a especicao de estilo dando origem a um documento no formato previamente seleccionado para output (RTF, Postscript, PDF, HTML, etc). A especicao de estilo controla parcialmente o processo de formatao (denio de margens, escolha do tipo de letra, tamanho da letra). O controle apenas parcial porque h muitos detalhes que so pr-estabelecidos pela equipe responsvel pela implementao do formatador e que podem diferir de uns para os outros. Por exemplo, os algoritmos que gerem a quebra de linha e de pgina podem ser implementados de vrias maneiras. Estes dois processos, transformao e formatao, podem constituir uma s aplicao ou, podero ser duas aplicaes completamente independentes. No h qualquer dependncia entre eles.
6.2.3. Linguagem de Transformao

Como j foi referido, a linguagem de transformao permite especicar processos de modicao (alterao/eliminao/criao). Um processo de transformao pode compreender operaes como:

Rearranjo de estruturas - reordenao e/ou agrupamento de estruturas existentes. Construo de novos elementos relacionados com outros elementos j existentes - o analista especica como que os novos elementos se obtm a partir dos
105
existentes - por exemplo, as footnotes que vo aparecendo podem ser agrupadas e colocadas no m do respectivo captulo.
Associao de novas caractersticas a sequncias especcas de contedo - o primeiro pargrafo de um captulo pode ter um incio diferente dos outros pargrafos nesse captulo - estas sequncias de contedo podem ser identicadas recorrendo utilizao de SDQL. Associao de novas caractersticas a componentes especcos de contedo - por exemplo, associar atributos de formatao a strings do texto que no se encontram anotadas em SGML.
Resumindo, com esta linguagem o utilizador pode especicar modicaes que afectam, quer o contedo, quer a estrutura do documento SGML original. Como se disse acima, todas as operaes especicadas no processo de transformao so independentes do processo de formatao que se lhe vai seguir.
6.2.4. O Processo de Transformao

O processo de transformao, SGML Tree Transformation Process (STTP), representado na Figura 6-2, compreende as etapas, que se descrevem a seguir: Construo do Grove (Seco 6.2.4.1); Transformao (Seco 6.2.4.2); Gerao de SGML (Seco 6.2.4.3). Figura 6-2. DSSSL - processo de transformao
106
6.2.4.1. Construo do Grove

O documento SGML submetido a um parser que vai reconhecer a sua estrutura e que o vai guardar numa estrutura interna especial - o Grove. Um grove a representao em grafo da estrutura e contedo de um documento; trata-se de um grafo orientado e pesado em que cada nodo fortemente tipado (cada nodo tem uma etiqueta associada que responde pelo seu tipo: no Exemplo 6-1, temos nodos do tipo receita, titulo, ...) e relaciona-se de vrias maneiras com os seus vizinhos (podemos ver uma relao como o peso associado a um ramo, no Exemplo 6-1 temos as relaes: lho/contedo, irmo, atributos). Deste modo, a estrutura pode ser atravessada de diferentes formas, de acordo com o m em vista. Podemos por exemplo, realizar pesquisas contextuais do tipo: "D-me todas as receitas cujo ttulo contem a palavra BOLO"; ou operaes de ltragem do tipo: "Lista de todos os ttulos de receita". A estrutura utilizada nas ferramentas mais completas, como o jade [jade], bastante complexa; no entanto, depois de se ter observado cerca de meia centena de equipes a pensar sobre o assunto1, concluiu-se que a estrutura mnima para representar um documento estruturado, especicada em CAMILA, seria a seguinte:
Grove Nodo Atributos Atributo Contedo : : : : : Nodo-Seq identificador * Atributos * Contedo Atributo-Seq identificador * tipo * valor Nodo-Seq
Apresenta-se a seguir um exemplo prtico de um grove (Exemplo 6-1).
Exemplo 6-1. Grove - estrutura para manipulao de documentos SGML Eis uma instncia dum documento SGML muito simples a partir do qual se ir construir o grove:
<RECEITAS> <TITULO> O Meu Livro de Receitas </TITULO> <RECEITA ORIGEM="Portugal <TITULO> Bolo </TITULO> <INGREDIENTE> 500g de farinha </INGREDIENTE> <INGREDIENTE> 200g de aucar </INGREDIENTE>
107
<INGREDIENTE> 300g de manteiga </INGREDIENTE> </RECEITA> </RECEITAS>
O qual foi escrito de acordo com o seguinte DTD:

<!DOCTYPE <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ATTLIST ]> RECEITAS [ RECEITAS (TITULO,RECEITA*)> TITULO (#PCDATA)> RECEITA (TITULO,INGREDIENTE+)> INGREDIENTE (#PCDATA)> RECEITA ORIGEM CDATA #IMPLIED>
Na gura abaixo apresenta-se o grove correspondente ao documento apresentado em cima.
Os nodos com o identicador TEXTO so nodos com contedo documental, ao contrrio dos outros que contm informao estrutural. Podemos tambm ver as relaes acima faladas: na primeira posio do tuplo que representa cada um dos nodos do grafo temos o identicador do tipo de nodo, na segunda posio temos o ramo correspondente relao atributos, na terceira o ramo correspondente relao lho, e na quarta o ramo correspondente relao irmo. Em groves mais complexos, normal aparecerem representadas as relaes inversas ( apenas uma deciso de implementao e est relacionada com a ecincia de algumas operaes.
108
Para mais informao o leitor pode consultar o texto do standard [Cla96] ou o j citado livro de DSSSL que est a ser escrito com as contribuies de todos atravs da Internet [Mul98].
6.2.4.2. Transformao
A Transformao propriamente dita o cerne desta primeira fase sendo realizada por um sistema de traduo que vai reescrevendo a informao de cada nodo de acordo com regras Condio-Aco: uma regra activada (seleccionada) sempre que a respectiva Condio sobre o nodo corrente (da travessia que o processo est a realizar) tiver o resultado verdadeiro; ento a Aco executada (normalmente corresponde a uma transformao do contedo do nodo corrente cujo resultado enviado para a sada). A especicao das operaes de transformao utilizada para controlar este processo que parte do grove do documento inicial e o transforma no grove do documento nal. A especicao de transformao composta por um conjunto de associaes. Cada associao um triplo: uma expresso de query (para seleccionar os componentes do documento que iro ser afectados pela transformao) - aqui usa-se a referida SDQL; uma expresso de transformao - aqui usa-se Scheme; e uma expresso de prioridade, que opcional (no se usa na maior parte dos casos). Em CAMILA poderamos denir uma especicao de transformao da seguinte forma:
Espec-Transf : Associao-Set Asso: Exp_Seleco * Exp_Transformao *Exp_Prioridade
ciao
Devido complexidade e dimenso do assunto remete-se o leitor para as referncias j habituais [Cla96, Mul98], e apresenta-se a seguir um exemplo comentado de uma das transformaes mais simples, a Transformao Identidade, que copia para a sada o contedo do grove.
109
Exemplo 6-2. A Transformao identidade

; Transformao identidade ; cria um novo grove igual ao primeiro ; (=> (tudo) (transf-por-defeito)) ; em que tudo a Exp-Seleco (define (tudo) (subgrove (current-root))) ; em que transf-por-defeito a Exp-Transformao (define (transf-por-defeito) (if (occurrence-mode (current-node)) (transf-por-origem) (create-root #f (copy-current)))) (define (transf-por-origem) (create-sub (origin (current-node)) (copiar-actual) (property: (occurrence-mode (current-node))))) (define (copiar-actual) (subgrove-spec node: (current-node)))
Algumas legendas sobre as funes utilizadas: subgrove devolve todos os descendentes de um nodo na forma de uma lista. current-node devolve uma lista singular contendo o nodo que est a ser objecto da transformao.
110
subgrove-spec o subGrove que est a ser criado descrito utilizando um objecto do tipo subgrove-spec. O argumento node: especica qual a raiz do subGrove que est a ser criado. create-root recebe como argumentos um identicador e um objecto do tipo subgrove-spec e especica a criao da raiz do Grove nal. create-sub (origin...) especica a criao de um subGrove no Grove nal com a origem especicada pelo argumento origin.
6.2.4.3. Gerao de SGML

Esta fase normalmente realizada por um gerador que faz uma travessia em profundidade (descendente, da esquerda para a direita) ao Grove enviando para o output o seu contedo em formato SGML. O documento SGML resultante pode, depois, ser passado a um formatador, ou usado para intercmbio com outras aplicaes.
6.2.5. Linguagem de Estilo

A linguagem de estilo permite descrever a aparncia visual desejada para o documento nal atravs da especicao do processo de formatao. O processo de formatao vai:
aplicar estilos de apresentao ao contedo do documento original e ir determinar a sua posio real na organizao fsica das pginas.
111
seleccionar e reordenar o contedo do documento nal tendo em conta a sua posio no documento original. incluir material que no estava explicitamente presente no documento original exemplo: gerao de um ndice. excluir, do documento nal, material presente no documento original.
Uma especicao de estilo composta por um conjunto de regras de construo. O objectivo destas regras a construo de uma nova estrutura, a Flow Object Tree (FOT). A FOT uma rvore de objectos grcos que funciona de representao intermdia para o processo de formatao. A especicao de estilo acaba por ser a especicao da transformao de uma rvore, o grove, noutra rvore, a FOT. Os objectos grcos, que correspondem aos nodos da FOT encontram-se denidos no standard [Cla96]; no resto desta seco apresentam-se exemplos envolvendo a criao de alguns deles. Actualmente o DSSSL suporta cinco tipos de regras de construo: root, element, default, query e id. Umas so mais especcas que as outras. Se as ordenssemos da mais para a menos especca obteramos a seguinte ordem: query, id, element, default, root. A prioridade de uma regra serve para resolver conitos, por exemplo: se um elemento do grove fr seleccionado por uma regra do tipo element ento, a regra default j no se aplicar quele elemento.
6.2.5.1. Estrutura das Regras de Construo

Em DSSSL, as regras de construo seguem a estrutura genrica que se apresenta a seguir:
(nome-da-regra (exp-seleco) (exp-aco) )
A exp-seleco serve para seleccionar os nodos do Grove aos quais ser aplicada a exp-aco. Cada exp-aco est normalmente associada construo dum nodo da FOT. Cada nodo da FOT pertence a uma classe de objectos grcos. Cada classe tem a ela associados uma srie de atributos que vo determinar a aparncia visual dos respectivos objectos.
112
O DSSSL possui um conjunto de classes base e d ao utilizador a possibilidade de denir outras. Apresentam-se a seguir vrios exemplos de regras de construo.
Exemplo 6-3. Regra associada ao documento

(root (make display-group (process-children) ) )
Aqui, root corresponde ao nome da regra, a expresso de seleco encontra-se omissa, e a aco corresponde invocao da funo make.
A aco process-children indica que se pretende aplicar o resto da especicao aos descendentes deste nodo. Sem esta indicao o documento seria truncado a partir deste nodo.
Exemplo 6-4. Regra associada a todos os elementos no documento original

(default (process-children) )
Neste exemplo, default corresponde ao nome da regra, a expresso de seleco omissa, e a aco corresponde invocao da funo process-children.
As duas regras apresentadas em cima fogem ao caso genrico ao no terem a expresso de seleco. Isto deve-se ao facto de essa expresso estar subjacente ao tipo de regra. No primeiro caso, regra de construo root, a regra, se estiver presente, sempre seguida, mas apenas uma vez, quando o elemento a processar a raiz do grove, que representa todo o documento. No segundo caso, regra de
113
construo default, a regra seguida para todos os nodos elemento, excepto quando estes so seleccionados por outra regra (lembrar a especicidade).
Exemplo 6-5. Regra associada a uma classe de elementos

(element (seccao titulo) (make paragraph font-family-name: "Helvetica" font-weight: bold (process-children) ) )
A expresso de seleco (seccao titulo) indica que esta regra ser usada para processar nodos titulo que so lhos de nodos seccao. Esta regra car associada a todos os elementos do documento que pertenam a esta classe. Outros nodos titulo, que no dentro de seco, no sero associados a esta regra.
Exemplo 6-6. Regra associada a um elemento especco identicado por um atributo do tipo ID
(id ("sec2") (make paragraph font-family-name: "Helvetica" font-weight: bold (process-children) ) )
Ao contrrio da regra anterior, esta ca associada apenas a uma instncia dum elemento, quele que tiver um atributo do tipo ID com valor igual ao indicado na expresso de seleco - "sec2".
114
Exemplo 6-7. Regra associada a uma query

(query q-class pi (make paragraph literal "Instruo de Processamento:" (node-property system-data (current-node)) ) )
Esta regra permite seleccionar todos os elementos abrangidos pela expresso de seleco. Neste caso, a expresso de seleco pi indica que se pretende seleccionar todas as "Processing Instructions". Devido grande complexidade que levanta na sua implementao, no foi implementada nos processadores de DSSSL actualmente disponveis.
6.2.6. O Processo de Formatao

Tal como se disse atrs para o caso da transformao, antes do incio do processamento o documento tem que ser analisado e uma estrutura arbrea tem que ser criada com o seu contedo - o Grove: se o processo de formatao se seguir a uma transformao o grove encontra-se j disponvel; seno, ter de se comear pelo parsing do documento fonte. Como j se mostrou, cada nodo desta estrutura corresponde a um elemento do documento. O processo de formatao especica-se associando a cada nodo do grove um conjunto de regras de construo que iro criar uma nova estrutura - a Flow Object Tree (FOT). Nesta nova estrutura, cada um dos nodos corresponde a um objecto com caractersticas grcas. Para nalizar o processo, esta estrutura passada a um formatador que apenas vai organizar espacialmente, no suporte fsico de output seleccionado, os objectos grcos. Assim, e resumindo, o processo de formatao, que se v esquematizado na Figura 6-3, compreende trs fases: Construo do grove
115
O documento SGML submetido a um parser que o vai validar e produzir um Grove (como no processo de transformao). Construo da Flow Object Tree O grove submetido a um processo que lhe vai aplicar as regras de construo especicadas na especicao de estilo e assim gerar a Flow Object Tree. Formatao O formatador parte da Flow Object Tree, aplica as suas regras geomtricas, faz a composio dos vrios objectos grcos pertencentes Flow Object Tree e produz o documento nal.
Figura 6-3. DSSSL - processo de formatao
6.2.7. Algumas especicaes exemplo

Apresentam-se agora algumas especicaes DSSSL que, se fossem utilizadas para processar o livro de receitas do Exemplo 6-1, serviriam para obter os efeitos indicados em cada caso. Comecemos por uma especicao de estilo bsica que simplesmente converter o texto do documento SGML original para RTF, MIF, ou TeX (conforme a opo passada ao formatador), sem nenhum requisito de formatao.
116
Exemplo 6-8. Especicao de Estilo bsica

(root (make simple-page-sequence (process-children)) )
make uma funo que constri um nodo da FOT; neste caso um nodo da classe simple-page-sequence. um nodo do tipo simple-page-sequence vai fazer com que seja produzida uma sequncia de reas de pgina. a funo process-children d a indicao de que o processamento dever continuar para os descendentes do nodo que se est a processar.
Vamos agora complicar um pouco o exemplo anterior, adicionando especicao as indicaes necessrias para formatar as margens do texto.
Exemplo 6-9. Adicionando margens

(root (make simple-page-sequence left-margin: 3cm right-margin: 2cm top-margin: 3cm bottom-margin: 3cm (process-children)) )
O objecto simple-page-sequence tem uma srie de atributos que permitem descrever a formatao do seu contedo. Neste caso utilizamos os atributos relativos s dimenses das pginas.
117
Complicando mais um pouco, vamos agora formatar de maneira diferente o ttulo do livro de receitas e o ttulo individual de cada receita.
Exemplo 6-10. Formatando os ttulos

(element (RECEITAS TITULO) (make paragraph quadding: center font-size: 18pt keep-with-next?: #f (process-children) ) ) (element (RECEITA TITULO) (make paragraph quadding: left font-size: 16pt keep-with-next?: #f (process-children) ) )
As expresses de seleco associam respectivamente uns atributos a um e ao outro tipo de titulo. A classe paragraph geralmente utilizada para elementos do tipo bloco, que se individualizam dos elementos que o precedem e que lhe sucedem.
A especicao anterior pode ser reescrita recorrendo utilizao de variveis para os valores dos atributos, o que facilitar a sua manuteno.
Exemplo 6-11. Adicionando variveis para facilitar a manuteno

;Constantes
118
(define *tituloPrinc* 18pt) (define *tituloReceita* (- *tituloPrinc* 2)) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (element (RECEITAS TITULO) (make paragraph quadding: center font-size: *tituloPrinc* keep-with-next?: #f (process-children) ) ) (element (RECEITA TITULO) (make paragraph quadding: left font-size: *tituloReceita* keep-with-next?: #f (process-children) ) )
Desta maneira, a modicao do tamanho da fonte s necessita de ser feita num local, o que facilita enormemente a manuteno.
Aqui esto a ser utilizados alguns dos muitos atributos da classe paragraph. Para uma informao mais detalhada sobre as classes e respectivos atributos aconselha-se a leitura do standard. Por m, mostra-se um exemplo que exibe o tipo de especicao utilizada para a criao de ndices e outros tipos de listas de contedos. Neste caso, iremos colocar no incio do livro de receitas uma lista de todos os ingredientes necessrios para a execuo de todas as receitas - isto implica uma passagem adicional sobre o documento para a construo desta lista.
119
Exemplo 6-12. Utilizando mais de uma passagem sobre o documento

(element RECEITAS (make sequence (literal "Ingredientes necessrios:") (make paragraph (with-mode *ingredientes* (process-matching-children "INGREDIENTE"))) (process-children) ) ) (mode *ingredientes* (element INGREDIENTE (if (= (child-number) 1) (make sequence font-posture: italic (process-children)) (make sequence font-posture: italic (literal " & ") (process-children)))) (default (empty-sosofo)))
Cada passagem sobre o documento tem a designao de mode. Se nada fr declarado o processamento realizado em normal-mode; para processamentos adicionais outros mode tero de ser criados - neste caso criou-se o mode ingredientes.
Nesta seco, deu-se uma ideia da potencialidade do DSSSL e da metodologia de especicao que lhe subjacente. Muita coisa cou fora desta abordagem, no entanto, as caractersticas aqui apresentadas permitem concretizar processos de formatao com alguma complexidade. A Semntica Esttica um assunto completamente novo. At data, no houve nenhum estudo que apontasse uma soluo para a sua denio e implementao. Neste momento, existem umas propostas em estudo [DCD, WIDL] a nvel do World
120
Wide Web Consortium (W3C) - entidade que superintende a criao de novos standards relacionados com a publicao electrnica e a Internet, mas numa forma ainda muito incipiente. Como a discusso desta temtica reecte a contribuio mais signicativa desta tese, apresentada num captulo parte, o prximo, Captulo 7.
Notas
1. No contexto de uma disciplina de compilao leccionada s licenciaturas em informtica, na Universidade do Minho.
121
Captulo 7. Validao Semntica em Documentos SGML

7.1. Semntica Esttica
A introduo do SGML trouxe uma nova abordagem ao processamento documental: validao estrutural automtica, validao em tempo real durante a edio (o autor est sempre informado sobre a correco ou incorreco estrutural do documento que est a produzir), independncia face a plataformas de software e hardware. Na gura seguinte mostra-se este modelo de trabalho, que no mais do que um subconjunto do ciclo de vida apresentado na Captulo 5. Figura 7-1. Edio baseada em SGML
7.1.1. Qual o problema?

O modelo apresentado suciente para uma grande parte das aplicaes do SGML. No entanto, quando se trabalha um certo tipo de informao h uma grave lacuna: validao semntica. Por exemplo, suponhamos que algum est a produzir um CD-ROM com contedo histrico; um erro na data de nascimento dum rei ou uma associao cronolgica com o reinado mal feita pode fazer colapsar todo o projecto. Relativamente consistncia e correco da informao, o SGML assegura uma validao estrutural completa e alguma validao semntica (atravs da associao
122
de atributos aos elementos); possvel garantir que um determinado atributo tem um valor dentro dum conjunto de possibilidades. Mas, quando trabalhamos com documentos com contedos mais ricos precisamos de colocar restries mais fortes sobre esses contedos; esta necessidade est para alm das capacidades do SGML. Esta lacuna tornou-se evidente quando se avanou na implementao de projectos reais (descritos mais frente em Apndice B). Nesses projectos, trabalhmos com o Arquivo Distrital de Braga e com o Departamento de Histria da Universidade do Minho. Pretendia-se disponibilizar grandes volumes de informao na Internet e trabalh-la de modo a ser possvel gerar tambm outras formas: CD-ROM, papel, ... Para tal montou-se uma linha editorial baseada em SGML. Um dos problemas crticos era o tempo e aqui comeou a sentir-se a falta de uma validao semntica automtica que, como era inexistente, levou a que se implementasse uma srie de ciclos de reviso, o que atrasou (e ainda atrasa) os projectos na sua fase nal de divulgao da informao. Nas seces seguintes, no iremos apresentar uma soluo completa para o problema da validao semntica, a soluo desenvolvida tratar um subconjunto de problemas de validao semntica: restringir o contedo textual (#PCDATA) de um determinado tipo de elemento, e vericar relaes entre subelementos e atributos. Para exemplicar estas ideias apresentam-se a seguir dois casos de estudo. Estes dois casos emergem dos projectos acima referidos, onde estamos a colectar informao de vrias fontes, que depois de processada distribuda via Internet. Os problemas apontados so simples e seriam facilmente resolvidos se houvesse alguma maneira de expressar restries no modelo.
7.1.1.1. Registos Paroquiais

Neste caso, a fonte de informao so os registos duma parquia. Numa comunidade catlica, o proco mantm um registo dos eventos realizados na parquia: casamentos, baptismos, funerais, ... Temos portanto, vrios tipos de documentos: certides de casamento, de baptismos, de bito, e ainda outros que no se encaixam numa classicao deste tipo. O que se pretende aqui, reunir aquela informao documental e construir uma base de dados de indivduos com as respectivas relaes familiares. Esta base de dados poder depois fornecer informao para a construo de modelos estatsticos que registaro a evoluo de hbitos e costumes permitindo que cada um de ns
123
possa aprender um pouco sobre as suas razes. Imagine-se agora, que temos uma equipe a introduzir aqueles documentos no computador em formato SGML (os originais esto bastante deteriorados e so demasiado irregulares na estrutura para permitirem uma digitalizao automtica). As pessoas, por vezes, cometem erros nas transcries. O parser de SGML detecta os erros de sintaxe/estruturais. Os outros, erros semnticos, passam indetectados e podero levar a vrios problemas que inuenciaro os modelos estatsticos que se pretendem criar. Por exemplo:
idades ao casamento negativas - provavelmente foi introduzida uma data errada num dos certicados. morte antes do baptismo - o mesmo problema retratado acima. casamentos entre pessoas com uma diferena de idades superior a 100 - um dos elementos do casal deve ter uma data a ele associada que foi mal introduzida.
Todos estes problemas podiam ser resolvidos com restries simples sobre o domnio de valores: "data de nascimento deve ser sempre maior que data de morte"; relativamente a casamentos, "a diferena das datas de nascimento dos conjugues dever ser sempre menor que um determinado valor", etc.
7.1.1.2. Arqueologia
Outra fonte de informao com quem trabalhamos a Unidade de Arqueologia da Universidade do Minho. Esta equipe de arquelogos tem produzido uma srie de documentos SGML que retratam arqueostios e artefactos. Na estrutura destes documentos h 2 elementos que tm de estar presentes obrigatoriamente e que dizem respeito localizao geogrca da entidade descrita: latitude e longitude. medida que cada documento produzido queremos lig-lo a um ponto dum mapa, construindo desta forma um Sistema de Informao Geogrca (SIG). Uma coisa que queremos e devemos garantir que cada par de coordenadas cai dentro do mapa, dentro dum certo intervalo. Isto, no pode ser feito usando apenas SGML, mas uma linguagem simples onde se pudessem expressar restries sobre um dado domnio serviria.
124
7.1.2. Restries e condies de contexto

Temos um problema para resolver. Queremos impr condies sobre o contedo de alguns elementos e queremos que o sistema tenha capacidade para vericar essas condies. Para isso, precisamos de adicionar restries aos documentos SGML, o que traz algumas implicaes e levanta outros problemas: normalizao de contedos, associao de tipos aos contedos, que linguagem utilizar para denir as restries, e como process-las. Como j foi referido, no se pode utilizar a sintaxe do SGML para expressar restries ou invariantes sobre o contedo dos elementos que compem o documento. O SGML foi criado como uma metodologia para especicao de estrutura, e na rea da validao estrutural o grande nmero de ferramentas disponveis faz dele uma forte e poderosa metodologia de especicao. Se o que pretendemos para salvaguardar a semntica dos documentos restringir contedos, precisamos de facto de adicionar essa capacidade ao SGML. Para isso, temos vrias hipteses: pode-se simplesmente adicionar sintaxe extra ao SGML; ou desenhar uma nova linguagem que podia ser embebida no SGML, ou coexistir fora dele. A adio de sintaxe extra implicaria a modicao de todas as ferramentas existentes para que estas reagissem nova extenso ou simplesmente a ignorassem. O custo desta soluo seria enorme; por isso seguiremos o outro caminho: a denio duma linguagem que permita a especicao de restries sobre elementos em documentos SGML. At ao momento, as restries que sentimos necessidade de impr so bastante simples. Na maioria dos casos, apenas se pretende restringir o valor de elementos atmicos a um domnio, vericar uma relao entre elementos, ou vericar se um determinado contedo est coerente com a informao guardada numa base de dados de suporte. Uma das razes para isto acontecer a validao estrutural j realizada pelo SGML ser to forte que apenas deixa o contedo dos elementos de fora. Pode parecer, portanto, que uma linguagem simples resolve o problema. No entanto, podemos desde j distinguir duas fases importantes neste processo:
a denio - a parte sintctica do modelo de restries, as declaraes que expressam as restries. o processamento - a parte semntica do modelo de restries, a sua interpretao.
125
Estas duas fases tm objectivos diferentes e correspondem tambm a diferentes nveis de diculdade na sua implementao. A primeira envolve a criao de uma linguagem, ou a adopo duma existente. Para a fase de processamento, precisamos de implementar um motor que seja capaz de avaliar e reagir s declaraes escritas na linguagem de restries. Para implementar este motor vamos necessitar de ter tipos associados nossa informao com toda a complexidade que lhes inerente. Neste momento, podamos ser tentados a questionar esta complexidade: "No poderemos sobreviver sem tipos?". Consideremos o seguinte exemplo extrado do segundo caso de estudo (Seco 7.1.1.2):
Exemplo 7-1. SGML com restries

SGML Document <latitude>41.32</latitude> Restrio latitude > 39 and latitude < 43
Neste exemplo, queremos garantir que o valor introduzido no elemento latitude de um arqueostio est compreendido dentro de certos valores. Estamos a vericar se um determinado valor est dentro dum domnio. Estamos a comparar o contedo do elemento latitude com valores numricos que tm um tipo inerente (inteiro ou real). Assim, o motor que vai executar esta comparao ir ter de inferir um tipo para o contedo do elemento latitude que est a ser comparado. Exemplos como este so muito simples. O contedo numrico de um elemento tem uma forma mais ou menos normalizada (pode ser expressso por uma expresso regular). Mas h outros bem mais complexos, como a data: h mais de cem maneiras diferentes de escrever uma data (e provavelmente qualquer um de ns pode facilmente inventar mais uma). Noutro caso de estudo, um trabalho realizado para o Arquivo Distrital de Braga [Fig98], estamos a trabalhar com documentos do sculo XVII e XVIII; nesses documentos, o nome "Afonso Henriques", o primeiro rei portugus, aparece escrito de duas maneiras diferentes: "Afonso"e "Affonso". E ainda h outros personagens que so referenciados de mais de duas maneiras distintas. Para podermos impr
126
restries ao nome dos reis de Portugal, temos de saber o tipo desses elementos e de usar um valor independente da ortograa. Vamos designar este problema por problema de normalizao. Para alm desta situao de imposio de restries, a normalizao torna-se crtica quando se pretende construir ndices sobre os documentos, para alimentar motores de busca ou simplesmente para implementar mecanismos de acesso informao. O computador precisa de entender que textos diferentes so referncias para o mesmo objecto. Por agora, propem-se duas solues para resolver os problemas da normalizao e da inferncia de tipos:
desenvolver e implementar uma linha de ferramentas, com alguma complexidade, que resolvero os problemas, primeiro a normalizao, depois a inferncia de tipos. introduzir algumas modicaes no DTD que resolvero o problema da normalizao e reduziro a inferncia de tipos a um problema mais simples.
Obviamente, a segunda que deve ser seguida. No s porque mais simples, mas tambm porque o problema da normalizao tem atrado a ateno de investigadores, principalmente na rea da Histria, o que fez com que vrias aproximaes a uma boa soluo tivessem surgido. Uma das melhores e a mais utilizada no momento a proposta do "Text Encoding Initiative (TEI)"[SB94]. A soluo bastante simples, basta adicionar um atributo de nome "value" (no nosso caso designaremos esse atributo por "valor") aos elementos cujo contedo levantar problemas de normalizao. A ideia a do contedo do elemento poder tomar qualquer forma, desde que o atributo "valor" seja preenchido com o valor normalizado.
Exemplo 7-2. Normalizao via adio dum atributo

... perdeu a batalha no <data valor="1853.10.05 quinto dia do ms de Outubro do ano 1853 </data> ...
Neste exemplo, convencionou-se que o formato normalizado para as datas seria o ANSI (ano.ms.dia).
127
Esta soluo, pressupe uma anlise prvia do contedo documental, que pode ser feita antes ou depois da edio do documento em SGML. Durante essa anlise devero ser levantados todos os problemas de normalizao para que depois ou durante a edio do documento SGML se adicione, aos elementos crticos, o atributo "valor" com o valor convencionado. Em trabalhos publicados durante a realizao desta tese [RRAH99], props-se uma soluo semelhante para simplicar a inferncia de tipos. A todos os elementos que iro ter a eles associada uma restrio adicionado um atributo de nome "type"("tipo"na implementao portuguesa) cujo valor a designao do tipo de dados que se quer associar aos elementos em causa. Se aplicarmos estas duas receitas aos exemplos discutidos durante esta seco o resultado seria o seguinte: [latitude]
<latitude tipo="real 41.32 </latitude> ...
[datas]
... aconteceu no <data tipo="date" valor="1853.10.05 quinto dia do ms de Outubro do ano 1853 </data> ...
[nomes]
... naquele ano <nome valor="Afonso Affonso </nome> proclamou vrios decretos ...
Assume-se que, quando um atributo "valor" no se encontra instanciado, o contedo do elemento respectivo j se encontra na forma normalizada. Relativamente ao atributo "tipo", a sua colocao levanta alguns problemas. Normalmente, o analista que desenvolve o DTD e o utilizador que vai usar esse DTD para editar os seus documentos so pessoas diferentes, com nveis de conhecimento tcnico diferentes. E, este atributo faz com que o utilizador tenha que saber o que so tipos de dados, quais os tipos de elementos que iro ter restries
128
sobre eles (s esses necessitam de ser "tipados"), e que instancie correctamente este atributo para estes elementos. O ideal seria que apenas o analista se preocupasse com este aspecto e tudo isto fosse transparente para o utilizador. O SGML tem uma caracterstica que nos permite implementar esta separao: os atributos do tipo "#FIXED". Sempre que tivermos um elemento com um determinado atributo de valor constante, e no quisermos que o utilizador altere esse valor, esse atributo deve ser declarado como #FIXED no DTD onde o respectivo valor dever tambm ser declarado. Voltando ao exemplo das latitudes:
Exemplo 7-3. Atributos "#FIXED"

DTD ... <ELEMENT latitude <ATTLIST latitude ...

- - (#PCDATA)> tipo CDATA #FIXED "real
tipo o nome do atributo. CDATA o tipo do valor do atributo, neste caso, indica que ser uma string. #FIXED o valor por omisso do atributo; indica ao sistema que no caso do utilizador no tiver sido instanciado o sistema dever assumir o valor fornecido na declarao, por outro lado, se o utilizador instanciar o atributo o sistema dever garantir que este idntico quele que foi fornecido na declarao. "real" o valor do atributo.
Ao trabalhar com um documento que esteja a ser criado com o DTD exemplicado acima, o sistema, em todas as operaes que envolvam o processamento SGML (por exemplo na exportao do documento para o sistema), acrescentar um atributo "tipo"a todos os elementos "latitude" com valor "real". Qualquer tentativa do utilizador para instanciar aquele atributo com outro valor ser ignorada pelo
129
sistema. Desta maneira, a associao de tipos aos elementos tornou-se transparente para o utilizador, at mesmo inacessvel. A adio destes dois atributos a um ou a vrios elementos levanta alguns problemas nas futuras transformaes que se pretendam implementar sobre o documento. No caso do atributo valor, h situaes em que se pretende utilizar o valor normalizado (por exemplo numa procura, ou na construo dum ndice), e outras, em que se pretende utilizar o valor original (por exemplo numa publicao el ao documento original). Uma questo relevante pode agora ser levantada: Ser que necessitamos de associar um tipo a todos os elementos? Ou apenas a elementos atmicos (aqueles cujo contedo apenas #PCDATA)? A questo levantada aparenta ser simples com uma resposta binria de sim ou no. No entanto, qualquer uma das respostas traz consigo um certo peso. Uma resposta armativa implicaria que para alm de tipos atmicos de dados, o nosso sistema, suportasse tipos estruturados que seriam associados aos nodos intermdios da rvore documental. Desta maneira, teramos um mapeamento completo entre a estrutura do documento e o nosso modelo abstracto de tipos. As respectivas consequncias desta abordagem, vantagens e desvantagens, seriam:

o sistema de tipos ca mais complexo. os tipos estruturados seriam mais facilmente inferidos do DTD do que do contedo dos elementos; isto implicaria a criao de uma ferramenta de converso. um mapeamento completo entre a estrutura do documento e um modelo abstracto de tipos de dados permitiria o processamento do documento no sistema de suporte do modelo abstracto; o que implicaria a criao e a utilizao de ferramentas poderosas (estas ferramentas resultariam da combinao dos operadores algbricos do sistema de suporte do modelo abstracto).
Por outro lado, se decidssemos associar um tipo de dados apenas a alguns elementos atmicos (algumas folhas da rvore documental), poderamos prever as seguintes consequncias:
a linguagem de restries seria muito simples; reduzida a operaes lgicas sobre tipos atmicos de dados e algumas funes de interrogao.
130
o motor de processamento resultaria simples e por isso fcil de implementar. o modelo abstracto estaria incompleto; caramos com um conjunto de pequenos bocados do modelo completo; isto tornaria invivel qualquer processamento do documento no sistema de suporte do modelo abstracto.
Em defesa deste ltimo ponto de vista podemos ainda apontar o seguinte: o SGML puramente declarativo ("declarative markup"); serve para denir estruturas; estas estruturas no so mais nem menos do que os tipos estruturados que temos vindo a discutir. Assim, podemos armar que os tipos estruturados so intrnsecos aos documentos; a respectiva validao feita quando o documento analisado e portanto no ser necessrio complicar a linguagem de restries para realizar esta tarefa. Para claricar este ponto, veja-se o prximo exemplo: vamos descrever em SGML uma rvore binria que neste caso modela uma rvore genealgica.
Exemplo 7-4. Uma rvore binria O respectivo DTD (a declarao da estrutura de dados) dene-se da seguinte maneira:
<!DOCTYPE <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT ]>
arv-bin arv-bin nodo valor filhos [ (nodo)> (valor,filhos?)> (#PCDATA)> (nodo?,nodo?)>
O leitor atento reparar que se introduz um nvel de redundncia na especicao ao declarar-se o elemento FILHOS como opcional e, depois, os seus descendentes NODO, de novo, como opcionais. Isso foi feito conscientemente devido s implicaes que existiriam na escrita de instncias se FILHO, fosse obrigatrio (para nodos sem lhos o autor seria sempre obrigado a colocar a anotao FILHO apesar de depois no lhe introduzir nenhum contedo). A gura seguinte apresenta uma rvore genealgica que a seguir instanciada em SGML de acordo com o DTD apresentado.
131
<arv-bin> <nodo> <valor>David</valor> <filhos> <nodo> <valor>ZCarlos</valor> <filhos> <nodo> <valor>Jos</valor> </nodo> <nodo> <valor>Flora</valor> <filhos> <nodo> <valor>Maral</valor> </nodo> <nodo> <valor>Maria</valor> </nodo> </filhos> </nodo> </filhos> </nodo> <nodo> <valor>Carmen</valor> <filhos> <nodo> <valor>Jos</valor> </nodo> <nodo> <valor>Edite</valor> </nodo>
132
</filhos> </nodo> </filhos> </nodo>
Deste exemplo, podemos concluir o seguinte: podemos denir tipos estruturados de dados duma forma puramente declarativa; a semntica est nos tipos atmicos; se ignorarmos os tipos atmicos ou, deixarmos ao sistema o trabalho de inferir o seu tipo, podemos armar que as estruturas denidas em SGML correspondem a tipos estruturados de dados. Num primeiro trabalho publicado no mbito desta tese [RAH95], apresentou-se uma abordagem primeira das direces apontadas (associao de tipos a todos os elementos). Num trabalho posterior [RAH96], aquela abordagem foi renada e um estudo comparativo com uma outra foi apresentado. Como resultado desse estudo, desenvolveram-se duas solues para o problema do processamento da semntica esttica. Cada soluo seguiu uma abordagem formal diferente. So estas duas abordagens que se apresentam nos dois captulos seguintes e que so respectivamente, uma abordagem via modelos abstractos, Captulo 8, e uma abordagem via gramticas de atributos, Captulo 9.
133
Captulo 8. Validao Semntica com Modelos Abstractos

Neste captulo vamos apresentar uma soluo para o processamento de restries semnticas em que esse processamento residir num ambiente externo ao da aplicao SGML. A ideia criar uma soluo compatvel com as aplicaes existentes, fazer com que o processamento das restries se possa acoplar ao que j existe sem alteraes das metodologias e ferramentas de trabalho. Como se pode ver na gura seguinte (Figura 8-1), aquilo que se prope aqui fazer uma pequena adio ao modelo de processamento existente: um novo componente que no provocar nenhuma alterao dos outros componentes. Figura 8-1. Novo Modelo para Processamento de Documentos SGML
Neste captulo, iremos ver como foi implementado este novo componente e, o impacto e respectivas consequncias no ciclo de vida da produo de documentos.
8.1. Modelos Abstractos: porqu?

Para ilustrar estas ideias iremos utilizar um caso de estudo, bastante importante para ns ( bom para demonstrar vrios aspectos do problema): o tipo de documentos subjacente ao conceito "literate programming"[Knu92]. Este tipo de documentos foi criado para permitir a mistura, dentro do mesmo cheiro, do cdigo de um programa e respectivo manual/relatrio. Para isso esto disponveis anotaes que
134
permitem a identicao e o estabelecimento de relaes entre aqueles dois tipos de componentes, de modo a que mais tarde seja possvel extrair as partes relevantes: o programa para compilar ou o relatrio para imprimir. Com efeito, nos exemplos que aparecem frente, iremos centrar a nossa ateno no procedimento de extraco e composio de programas a partir dum documento literate programming. Este procedimento servir como termo de comparao das vrias abordagens. Assim, um documento em literate programming um texto de contedo misto, composto por elementos especiais, cdigo e denies. Uma denio uma associao de um identicador a um pedao de cdigo ou texto; um programa pode incluir referncias a estes identicadores. Apresenta-se a seguir um exemplo dum DTD e respectiva instncia documental para este tipo de documentos.
Exemplo 8-1. Literate Programming O DTD que se segue dene formalmente a estrutura dum documento do tipo literate programming.
<!DOCTYPE litprog [ <!ELEMENT litprog - ((#PCDATA|prog|def|id|sec|tit)*)> <!ELEMENT prog - - ((#PCDATA|id)*)> <!ELEMENT def - - (prog)> <!ATTLIST def ident ID #REQUIRED> <!ELEMENT sec - - (#PCDATA)> <!ELEMENT tit - - (#PCDATA)> <!ELEMENT id - o EMPTY> <!ATTLIST id refid IDREF #REQUIRED> ]>
O texto seguinte um exemplo concreto dum documento escrito de acordo com o DTD acima.
<litprog> <tit>Exemplo de Literate Programming</tit> <sec>Stack - FAQ</sec> <def ident="main <prog>
135
main(){ int S[20]; sp=0; <id refid="push <id refid="pop } </prog> </def>
<sec>Push</sec> Esta funo podese usar para colocar elementos na stack. <def ident="push <prog>void push(int x) {S[sp++]=x;} </prog> </def> </litprog>
O texto em si um manual dum determinado programa. Quando se produz um documento deste tipo h dois processamentos esperados: a produo do manual propriamente dito e a extraco do programa para se compilar. O extractor poder retirar o programa ou parte dele, o utilizador indicar o que pretende passando o identicador da raz da subrvore de pedaos de cdigo que pretende extrair.
Nesta aproximao iremos converter o documento num modelo abstracto de dados e utilizaremos o sistema de suporte desse modelo (neste caso o CAMILA) para especicar o processamento do documento. Um DTD, do ponto de vista algbrico pode ser visto como um modelo, como j foi discutido em [RAH95]. Por exemplo, no nosso caso de estudo teramos o seguinte modelo CAMILA:
model type litprog = X-seq X = (TEXTO | prog | def | id | sec | tit) prog = Y-seq
136
Y def sec id tit endtype
= (TEXTO | id) = = = = i:ID * p:prog TEXTO ID TEXTO
A construo do modelo CAMILA foi feita sistematicamente seguindo a tabela de equivalncia abaixo apresentada. Tabela 8-1. Esquema de Traduo SGML CAMILA SGML x,y x&y x|y x* x+ x? CAMILA produto cartesiano produto cartesiano unio disjunta X-seq X-seq [X]
Desta tabela fcil concluir que no h uma equivalncia directa entre os elementos dos dois universos. Na maior parte dos casos, para no se perder semntica, teria de ser associado um invariante ao tipo de dados CAMILA. Por exemplo, no quinto caso (x+), no correspondente tipo CAMILA nada dito sobre a cardinalidade da sequncia; um invariante garantindo que a sequncia no vazia teria de ser associado ao tipo CAMILA correspondente. Nesta abordagem, o processamento especicado como uma funo ou funes sobre o modelo abstracto. Por exemplo, o nosso extractor de programas getprogram(), ser ento expresso como uma funo que recebe um documento do tipo literate programming, colecta todos os bocados de cdigo nele espalhados, organiza-os de forma correcta, produzindo assim um programa, neste caso em C, do tipo cprog denido abaixo.
type cprog = TEXTO-seq endtype
137
Ento, o referido extractor poderia ser assim especicado:

func getprogram( d :litprog ) :cprog returns explode(main,mkindex(t));
A funo getprogram() realiza uma substituio recursiva (explode) dos identicadores (id) pelos respectivos programas, comeando pelo identicador main. O exerccio ca completo com a denio das duas funes que faltam: explode() e mkindex().
func mkindex( d :litprog ) :id->prog return [i(x) -> p(x) | x <- t : is-def(x) ]; /* a funo mkindex recebe um documento e constroi uma funo finita de identificador para bocado de cdigo -- a funo colectora */ func explode( i :id, d :id->prog ) :cprog pre i in dom(d) returns( CONC( < if( is-id(x) -> explode(x,d), else -> <x> ) | x <- d[i]> ); /* a funo explode recebe a funo finita construda na funo anterior, um identificador indicando qual a raz da derivao, e constri o programa - a funo compositora */
Esta abordagem boa para prototipar, quer estruturas, quer processamento. No caso especco dos documentos SGML, apresentamos uma possvel via de translaco do seu processamento para o nosso sistema algbrico. H no entanto alguns pontos a renar: o esquema de traduo tem de ser enriquecido, os modelos abstractos nos quais mapeamos os construtores do SGML so, regra geral, menos especcos, tm menor poder expressivo; assim, tero de ser restringidos via adio de um invariante de tipo para se conseguir manter a mesma semntica. A maior parte da especicidade do SGML resulta deste ter sido pensado para anotar texto. O texto tem uma ordem linear inerente. Esta ordem foi transportada para o SGML sob a
138
forma dos operadores "&"e ",". Se tivermos um DTD onde aqueles operadores existam, a sua converso num modelo CAMILA necessitar da adio de invariantes que garantam a especicidade da ordem. Poderamos ser tentados neste ponto a pensar se no valeria a pena criar um prottipo em CAMILA que suportasse o ciclo de vida do SGML. A ideia seria prescindirmos do parser e usar os constructores do CAMILA para especicar uma estrutura que depois seria preenchida com instncias documentais s quais seriam aplicados processamentos sob a forma de execuo de funes sobre o modelo algbrico. Isto seria possvel se a equivalncia semntica entre as duas notaes de especicao fosse real. Como j foi discutido a notao CAMILA mais lata, menos especca que o SGML e a criao deste sistema s seria possvel via adio de vrios invariantes e condies de contexto que no seu todo seriam semanticamente equivalentes a um parser SGML.
8.2. Linguagem de Restries

A questo pertinente do momento : Como iremos especicar as restries? Em que linguagem? Como j foi discutido no captulo passado, temos duas opes: desenvolver uma nova linguagem, ou, utilizar uma existente. Uma vez que o que se est a desenvolver um prottipo e a escolha de uma linguagem existente poupar-nos-ia algum trabalho, foi esta a opo escolhida. Para se poder manipular elementos SGML e especicar restries sobre eles a escolha natural seria uma linguagem de especicao baseada em modelos. Como j foi exemplicado na seco anterior (Seco 8.1) e em [RAH95], cada denio dum elemento no DTD tem um modelo implcito, e cada instncia desse elemento pode ser convertida numa expresso algbrica desse modelo. No prottipo descrito mais frente Figura 8-2, estamos a utilizar uma ferramenta de converso automtica, dtd2cam, para traduzir o DTD para um modelo na linguagem de especicao de SETs, CAMILA [ABNO97, BA95]. Depois desta converso, o analista pode escrever as restries em CAMILA uma vez que estas so naturalmente integradas no modelo calculado automaticamente a partir do DTD. Em termos prticos, cada restrio ir corresponder a um predicado que dever sempre retornar o valor booleano verdade, caso contrrio uma mensagem de erro ter de ser enviada ao utilizador.
139
Na nossa implementao, as restries so especicadas por um conjunto de regras; cada regra, um par formado por uma condio (a negao da respectiva restrio) e a reaco que lhe ca associada. Os casos prticos que temos em mos so de alguma complexidade e tm problemas muito especcos, o que os torna imprprios para exemplicar o nosso sistema. Assim, vamos recorrer a um exemplo mais pequeno, com complexidade suciente para ilustrar as nossas ideias e o nosso prottipo.
Exemplo 8-2. Reis e Decretos Um documento composto por uma lista de decretos proclamados por um determinado rei. Apresenta-se a seguir o respectivo DTD:
<!DOCTYPE rei [ <!ELEMENT rei (nome, cognome, datan, datam,decreto+)> <!ELEMENT decreto - (data, corpo)> <!ELEMENT (nome,cognome,datan,datam,data) (#PCDATA)> <!ATTLIST (datan,datam,data) valor CDATA #IMPLIED tipo CDATA #FIXED date> <!ELEMENT ]>
corpo - (#PCDATA)>
Repare-se na declarao dos atributos tipo e valor para os elementos relacionados com datas. O atributo tipo tem um valor xo que ser usado mais tarde pelo processador de restries (o validador semntico) para inferir o tipo do seu contedo. O atributo valor ser utilizado para guardar a forma normalizada das datas; o processador usar o valor deste atributo, sempre que este estiver instanciado, em vez do contedo do elemento. O texto seguinte uma instncia do referido documento, escrita de acordo com o DTD.
<rei>
140
<nome>D.Dinis</nome> <cognome>O Lavrador</cognome> <datan valor="1270.09.2323 de Setembro de 1270</datan> <datam valor="1370.09.23" >23 de Setembro de 1370</datam> <decreto> <data valor="1300.07.15" >Ao dcimo quinto dia do ms de Agosto do ano 1300:</data> <corpo>A partir do dia de hoje, apenas bicicletas podero circular na cidade de Braga.</corpo> </decreto> <decreto> <data>1389.11.03</data> <corpo>O McDonalds passar a vender vinho verde em vez de COCA-COLA.</corpo> </decreto> </rei>
Observando o DTD e a respectiva instncia podemos identicar de imediato algumas condies que devem ser vericadas:
A data de cada decreto dever sempre estar compreendida entre a data de nascimento (datan) e a data de falecimento (datam) do respectivo rei. O nome do rei dever constar da nossa base de dados de pessoas famosas.
Para adicionarmos estas condies de contexto ao nosso sistema de validao, adicionamos ao DTD a declarao de entidades externas onde as condies estaro especicadas. Este mtodo para associar restries ao DTD representa apenas uma das trs opes possveis para o fazer e que so discutidas mais frente (Seco 8.3).
<!DOCTYPE rei [ <!NOTATION CAM SYSTEM "camila.exe <ELEMENT rei - (nome,cognome,datan,datam,decreto+)> <ENTITY rei-rest SYSTEM "rei.cam" NDATA CAM> ...
141
<ELEMENT decreto - - (...)> <ENTITY decretorest SYSTEM "decreto.cam" NDATA CAM> ]>
Neste caso, utilizamos uma entidade para cada conjunto de restries.
No contexto do nosso exemplo, poderamos escrever as seguintes restries (utilizando a linguagem CAMILA):
rei(r) = { if(nome_(r) notin PessFamDB > nome_(r) ++ "No existe..."), if(datan_(r) > datam_(r) > nome_(r) ++ "Morreu antes de nascer."), if(datam_(r) - datan(r) > 120 > nome_(r) ++ "Viveu demais!"), if(!all( x<decreto_l(r) : datan_(r) < data_(x) /\ data_(x) < datam_(r)) -> nome_(r) ++ "fez um decreto fora da sua vida!") };
Se o nosso modelo instanciado tivesse os seguintes valores:

r = ("D.Dinis", "O Lavra-
dor", "1265.06.24", "1211.04.12", ...)

datan_(r) = "1265.06.24" datam_(r) = "1211.04.12"
Este conjunto de valores faria disparar a regra

if(datan_(r) > datam_(r)
que produziria como resultado a concatenao ("++") do nome do rei ("nome_(r)") com a string "Morreu antes de nascer.".
142
8.3. Associao de Restries aos Elementos

Tendo decidido sobre a linguagem que ir ser utilizada na escrita de restries altura de pensar na associao destas aos elementos que compem o respectivo DTD. A tarefa de escrever as restries atribuda ao analista que as dever denir quando estiver tambm a denir o DTD. A primeira deciso que foi tomada surge neste ponto: Como incluir as restries no DTD sem alterar a sintaxe do SGML? Um dos objectivos a no alterao do mtodo de trabalho existente. Analisando os construtores do SGML, pensou-se em trs mtodos alternativos: seces de comentrios especiais Um comentrio pode aparecer em qualquer lugar do DTD. Assim, podemos denir as restries em comentrios espalhados pelo DTD. Estes comentrios levam uma marca para os distinguir dos comentrios normais: a palavra reservada Constraints utilizada.
Exemplo 8-3. Restries como comentrios

<!DOCTYPE rei [ <!ELEMENT rei - (nome,cognome,datan,datam,decreto+)> <!- Constraints rei(k) = ... -> ... ]>
cheiro externo
143
A ideia utilizar de novo um comentrio especial que indicar qual o cheiro que tem as restries que devero ser associadas com o DTD corrente.
Exemplo 8-4. Restries num cheiro externo

<!DOCTYPE rei [ <!- Constraints: rei.cam -> ... ]>
entidade externa Uma vez que os comentrios so completamente ignorados pelas aplicaes SGML, pode parecer estranho estarmos a utiliz-los para adicionar informao semntica aos documentos. Para quem possa pensar assim, avanmos com uma terceira alternativa bem dentro do SGML: a utilizao de uma ou vrias entidades externas. Uma entidade vista pelas aplicaes como um componente do documento. No caso da validao, o parser ir tentar analisar o seu contedo. Neste caso, no nos interessa que isso acontea uma vez que o contedo no SGML. Para evitar essa situao, utilizmos a mesma tcnica que se usa para imagens: declaramos que a entidade tem um contedo que deve ser tratado por uma aplicao externa que saber processar a informao que estiver l dentro.
Exemplo 8-5. Restries numa entidade externa

<!DOCTYPE rei [ <!NOTATION CAM SYSTEM "camila.exe <!ELEMENT rei - (nome,cognome,datan,datam,decreto+)> <!ENTITY king-rest SYSTEM "king.cam" NDATA CAM> ... ]>
144
Na segunda linha, declara-se que CAM uma notao que interpretada pela aplicao "camila.exe". Depois, podemos indicar ao sistema que as entidades externas que contm restries tm o contedo nesta notao (linha 4).
Qualquer uma das trs alternativas vlida e no implica qualquer alterao nos sistemas existentes em funcionamento. Para o desenvolvimento dos casos de estudo escolhemos a segunda alternativa. A primeira mistura as restries com as declaraes do DTD e no caso de DTDs complexos faria com que estes cassem ainda mais complicados de ler e de entender. A segunda e a terceira alternativas so funcionalmente equivalentes; a segunda mais fcil de utilizar em prototipagem (os comentrios so livres, as aplicaes SGML no lhes atribuem qualquer semntica). A separao das restries do DTD vem ainda permitir a construo de uma pequena e til ferramenta: um processador simples que analisa o DTD e produz o esqueleto do cdigo das restries. Desta maneira, o analista poder trabalhar mais rpido e com mais segurana (no esqueleto j esto todos os prottipos das restries, nenhum foi esquecido).
8.4. Processamento das Restries

Depois de discutirmos a incluso/ligao de restries aos DTDs, vamos ver agora de que modo que podemos acoplar o mdulo de validao extra a um sistema existente. Como foi apresentado na Figura 8-1, adicionou-se um processo extra ao modelo de processamento baseado em SGML tradicional. Este novo processo ser o responsvel pela execua das tarefas necessrias vericao das restries. Na gura seguinte (Figura 8-2), podemos ver este processo com mais detalhe.
145
Figura 8-2. O Novo Componente de Validao CAMILA
A adio deste novo processo exige adaptaes a dois nveis: um relacionado com as pessoas intervenientes, analista e utilizadores, e outro relacionado com o software, como que vo interactuar as novas rotinas com as j existentes. O primeiro nvel ser designado por operacional e o segundo por aplicacional e podem ser descritos da seguinte forma:
Nvel Operacional Neste nvel consideramos que h sempre a interveno de dois tipos de agente: o analista e o autor. No modelo tradicional (Figura 7-1), o analista apenas tinha que desenvolver o DTD. No novo modelo, alm do DTD, o analista ter de desenvolver ao mesmo tempo a especicao de restries. No m da fase de anlise, uma cpia do DTD enviada ao processo de edio e, a mesma cpia juntamente com as restries, enviada a um novo processo de software que realizar a validao adicional (Figura 8-2). Estas alteraes so invisveis para o utilizador do sistema. Ele s sentir mudanas na preocupao que agora ter que ter em relao normalizao de
146
informao. Nvel de Aplicacional Este nvel diz respeito ao novo componente (o processo adicional de validao) que passaremos a descrever. Como se pode ver na Figura 8-2, este processo composto por vrios subcomponentes/funes. O maior e mais complexo foi designado por Validador-CAMILA (devido linguagem e sistema de prototipagem em que foi desenvolvido - [ABNO97]). Os outros foram baptizados de acordo com a sua funcionalidade: dtd2cam, esis2cam, e nsgmls que o conhecido parser de SGML desenvolvido por James Clark [SP]. O processo centrado na funo Validador-CAMILA, que recebe trs tipos de informao provenientes dos outros intervenientes e produz um resultado. O DTD concebido na fase de anlise enviado ao dtd2cam, que traduz a denio dos elementos com as restries associadas num modelo CAMILA (tipos com invariantes associados), passando este ao Validador-CAMILA. As restries que so escritas directamente na linguagem CAMILA vo directamente para o Validador-CAMILA. Do outro lado, e j com um autor a editar documentos, quando este quer validar o documento que est a editar, activa a funo valida que comea por enviar o documento ao nsgmls; o output do nsgmls (o documento no formato ESIS - formato intermdio usado nas aplicaes SGML), que normalmente ignorado a menos das mensagens de erro, enviado ao processo esis2cam, que vai us-lo para instanciar a estrutura j denida em CAMILA, traduzindo as instncias dos elementos no documento em expresses CAMILA (termos dos tipos de dados algbricos). Assim, o Validador-CAMILA em posse do DTD (traduzido pelo dtd2cam), das restries e do documento (traduzido pelos nsgmls e esis2cam) pode desencadear a validao semntica, bastando para isso executar as restries. Como resultado, o Validador-CAMILA envia ao utilizador um OK ou uma lista de mensagens de erro. Podemos aperceber-nos facilmente que este processo no simples e de que vrias decises foram tomadas no curso da sua implementao.
147
No resto do captulo, acompanharemos o percurso dum documento que ir atravessar o nosso sistema. Aproveitaremos vrios estados dessa passagem para ilustrar as decises tomadas na sua implementao e respectivos porqus.
8.4.1. Implementao
O processo, cujo comportamento foi descrito na seco anterior, compreende duas tarefas de traduo. A primeira resolvida por um processador, esis2cam, que converte um documento, depois deste ter passado o processo de validao tradicional, em formato ESIS (Seco 5.3) em expresses CAMILA. Aplicando o nsgmls ao nosso exemplo, o resultado ESIS seria o seguinte:
(rei (nome -D. Dinis )nome ... (decreto A valor CDATA "1300.07.15" A tipo CDATA "date" (data -1300.07.15 )data (corpo -A partir do dia de hoje ... )corpo )decreto ... )rei
No passo seguinte, esis2cam ir converter este resultado em termos do modelo abstracto CAMILA gerado por dtd2cam. A segunda tarefa de traduo (dtd2cam) no to simples pois envolve um mapeamento entre um DTD e uma lgebra:
o DTD traduzido para um modelo na teoria de SETs.
148
cada elemento mapeado num tipo, de acordo com um esquema de traduo [RAH95, RAH98]. cada elemento tem uma restrio a ele associada que car agora associada ao tipo. uma restrio um conjunto de pares: condio - reaco; por defeito tem o valor verdadeiro; a condio e a reaco so escritas de acordo com a sintaxe CAMILA com a utilizao de operadores CAMILA (Seco 2.1).
O prximo exemplo demonstra a aplicao deste processo ao caso dos "reis e decretos"que tem vindo a ser seguido.
Exemplo 8-6. Dum DTD para CAMILA O DTD que temos vindo a usar composto pelas seguintes declaraes:
<!ELEMENT
rei - (nome, cognome, datan, datam,decreto+)> <!ELEMENT decreto - (data, corpo)> <!ELEMENT (nome,cognome,datan,datam,data) -
(#PCDATA)>
<!ATTLIST (datan,datam,data) valor CDATA #IMPLIED tipo CDATA #FIXED date> <!ELEMENT
corpo - (#PCDATA)>
Aplicando dtd2cam a este DTD obtemos:

TYPE rei=nome_ cognome_ datan_ datam_ decreto_l :text :text :date :date :decreto-seq
decreto=data_ :date corpo_ :text ENDTYPE
149
rei(r)=true; decreto(d)=true; ...

Elementos estruturados so mapeados em tuplos: rei e decreto. Elementos atmicos sem um tipo associado so automaticamente denidos como sendo text: nome e cognome. Elementos com um tipo associado so denidos como sendo desse tipo: datan, datam e data. Elementos com indicadores de ocorrncia so denidos como listas. Por m, gerado um invariante para cada elemento. O invariante gerado uma tautologia podendo e devendo ser reescrito pelo analista conforme as restries que este quiser impr.
Termina aqui a travessia do nosso sistema. Os exemplos prticos obtidos com esta abordagem demonstraram-nos que esta uma boa soluo para a implementao da validao semntica. No aumenta muito a complexidade do sistema e no altera as aplicaes SGML existentes.
150
Captulo 9. Validao Semntica com Gramticas de Atributos

Neste captulo vamos apresentar uma soluo baseada em gramticas de atributos para o problema da denio e processamento de restries semnticas. Quando nos debruamos mais sobre a semelhana destes dois mundos surgiu a ideia de se utilizar uma ferramenta de gerao automtica de compiladores para gerarmos editores SGML especcos. A ideia evoluiu mais um pouco e o resultado nal reecte-se no sistema S4. O sistema S4 um ambiente integrado para a programao de documentos. Uma das facilidades integradas no sistema a possibilidade de denio e processamento de restries (o problema que temos vindo a perseguir). Mas alm desta, inclui outras como a integrao duma sintaxe mais ligeira que o DSSSL para a especicao de estilos. O produto nal pode resumir-se dizendo que um gerador de editores estruturados baseados em SGML com possibilidade de denir e processar restries semnticas e com a possibilidade de acoplar uma especicao de estilo que far com que o editor gerado produza automaticamente vistas do documento com o contedo transformado, ou formatado. Nas prximas seces e aps uma introduo terica que suporta a abordagem seguida, apresentaremos o sistema S4 e discutiremos os vrios pormenores da sua implementao.
9.1. Aproximao via gramticas de atributos

As operaes que normalmente se fazem com documentos incluem: traduo, formatao do contedo, interpretao, acesso e recuperao de partes relevantes da informao contida no documento. Olhando para esta lista de operaes, mais uma vez, o paralelismo entre o processamento de documentos e o processamento de linguagens formais emerge (ver o que se disse atrs na (Seco 6.1):
para todas estas operaes necessrio um primeiro passo de reconhecimento e
151
criao de uma representao intermdia - regra geral corresponde a uma anlise lxica e uma anlise sintctica; no caso dos documentos SGML so realizadas pelo parser genrico de SGML; no caso das linguagens tambm realizado pelo parser especco de cada linguagem.
a interpretao corresponde a uma anlise semntica que feita aps as duas primeiras. a traduo e a formatao correspondem a travessias da representao intermdia - quer num caso quer no outro tm de ser programadas de acordo com o objectivo nal pretendido. o acesso e recuperao de partes correspondem a travessias da representao intermdia com ltragem de componentes - no caso dos documentos SGML corresponde realizao de uma query; nas linguagens, em termos de funcionalidade, corresponder parcialmente optimizao do cdigo gerado.
Nesta seco, vamos aplicar ao processamento documental uma tcnica que j se vem aplicando no processamento de algumas linguagens formais. Nesta abordagem representaremos a semntica dum documento como uma rvore de Sintaxe Abstracta Decorada (ASAD). Uma ASAD formalmente especicada por uma gramtica de atributos. Relativamente semntica, vamos deixar de fora na da introduo as restries de contexto que se podero associar a um documento SGML e que temos vindo a discutir em captulos anteriores. O objectivo aqui vericar se esta aproximao tem capacidade para representar os documentos SGML com todas as restries possveis de expressar num DTD e que um sistema SGML tradicional automaticamente valida. S depois iremos discutir se ou no possvel acrescentar restries semnticas extra SGML mas relacionadas com o documento em causa. A notao relativa s gramticas de atributos que ir ser usada ao longo deste captulo, nas especicaes sintcticas e semnticas dos exemplos, foi j devidamente apresentada no captulo introdutrio (Seco 2.2). Nas partes mais especcas e relacionadas com a implementao, utilizada a linguagem SSL "Synthesizer Specication Language", tambm introduzida numa seco do captulo inicial (Seco 2.2.2). O primeiro passo para a construo desta representao semntica de documentos a concepo da Gramtica Independente de Contexto (GIC) que lhe servir de base. sempre possvel derivar uma GIC sistematicamente, ou automaticamente,
152
partindo do DTD. A tabela seguinte, Tabela 9-1, apresenta um primeiro esboo dum esquema de traduo entre os dois formalismos. Tabela 9-1. Esquema de Traduo SGML Gramticas de Atributos SGML x,y x&y x|y x* x+ x? Gramticas de Atributos ZXY ZXY|YX ZX|Y Z X ; X X-elem X | Z X ; X X-elem X | X-elem ZX|
A GIC que se segue foi obtida sistematicamente a partir do DTD apresentado para o tipo de documentos literate programming (Exemplo 8-1).
Exemplo 9-1. GIC derivada do DTD de Literate Programming

p1: p1.1: p1.2: p1.3: p2: p2.1: p2.2: p3: p4: p5: p6: litprog X -> "<litprog>" X "</litprog>" -> TEXTO X | prog X | def X | id X | sec X | tit X | -> "<prog>" Y "</prog>" -> TEXTO Y | id Y | -> -> -> -> "<def ident=" ID " prog "</def>" "<sec>" TEXTO "</sec>" "<tit>" TEXTO "</tit>" "<id refid=" ID "
prog Y
def sec tit id
Depois de se obter a GIC, o passo seguinte consiste na associao de atributos aos smbolos da GIC e na escrita das respectivas regras de clculo (no contexto de cada regra de derivao).
153
A introduo de atributos vai permitir duas coisas: por um lado, expressar as condies de contexto necessrias para restringir o conjunto de frases vlidas (predicados que tm de ser vericados no contexto de algumas produes); por outro lado, transportar atravs dos atributos toda a restante informao no estrutural que inferida do documento, directa ou indirectamente, e que necessria para realizar a transformao do documento. No primeiro caso, diremos que o objectivo a denio da semntica esttica e, no segundo, a denio da semntica dinmica. Os atributos correspondentes semntica esttica so facilmente derivveis a partir das clusulas ATTLIST presentes no DTD. Considerando de novo o nosso caso de estudo, a derivao dos seguintes atributos (associados aos smbolos def e id) imediata:
def: syn {ident: word} id: syn {refid: word}
Aos quais associamos as seguintes regras de clculo:

p3: def -> "<def ident=" ID " prog "</def>" ident(def) = lexval(ID) id -> "<id refid=" ID " refid(id) = lexval(ID)
p6:
Assumiu-se que cada smbolo terminal (no nosso exemplo ID e TEXTO) tem um atributo intrnseco chamado lexval (valor lxico) do tipo word. A nica restrio de contexto que preciso especicar, para este exemplo, em termos de atributos diz respeito validao de atributos do tipo ID e IDREF que um parser SGML faz ( das poucas validaes semnticas realizadas): cada ID s aparece denido uma vez e cada IDREF deve ter um valor de um ID denido algures no documento. Assim, no nosso caso, denimos as seguintes condies de contexto:
p3: CC: def -> "<def ident=" ID " prog "</def>" not exists( ident(def), itab(def) )
154
p6: CC:
id
-> "<id refid=" ID " exists( refid(id), itab(id) )
Para escrever estas condies de contexto, vimo-nos perante a necessidade de associar aos smbolos def e id um atributo herdado, itab. Este atributo faz o papel de uma tabela de smbolos, que aqui vai registando os identicadores que so denidos ao longo do documento, e que consultada sempre que um identicador referenciado. Para manter esta tabela actualizada ainda necessrio acrescentar os seguintes atributos, cuja semntica explicada mais frente:
def: inh {itab: IdentTAB} syn {pros: PEleList} inh {itab: IdentTAB} inh {itab: IdentTAB} syn {stab: IdentTAB}
id: X:
prog: syn {pros: PEleList}
Com as seguintes regras de clculo:

p3: def -> "<def ident=" ID " prog "</def>" pros(def) = pros(prog) X
-> def X itab(def) = itab(X0) itab(X1) = actualiza( itab(X0), ident(def), pros(def) ) stab(X0) = stab(X1)
-> id X itab(id) = itab(X0) itab(X1) = itab(X0) stab(X0) = stab(X1)
155
O desenvolvimento da gramtica de atributos prosseguiria desta forma at todas as restries semnticas estarem cobertas e todos atributos utilizados nessas restries estarem especicados. Para completar o nosso exemplo temos de denir ainda os atributos pros e tab associados ao axioma da GIC, litprog; pros ser uma estrutura associativa onde sero guardados pares com a seguinte composio: identicador>pedao-de-programa; tab, tal como os acima referidos itab e stab, uma tabela de identicadores normal.
litprog: syn {tab: IdentTAB; pros: PEleList} X: syn {pros: PEleList}
E as respectivas regras de clculo:

X -> prog X pros(X0) = append( pros(prog), pros(X1) )
litprog -> "<litprog>" X "</litprog>" tab(litprog) = stab(X) pros(litprog) = pros(X)
Neste ponto, dispomos do necessrio para especicar qualquer processador para este tipo de documentos via equaes/funes sobre os atributos. Por exemplo, um extractor de programas poderia ser especicado da seguinte maneira:
p1: litprog -> "<litprog>" X "</litprog>" getprogram( pros(litprog), tab(litprog) )
O procedimento getprogram vai percorrer as duas estruturas criadas durante o reconhecimento do documento, respectivamente pros que tem o cdigo dos excertos de programas e tab que tem a informao sobre os identicadores. Com a anlise deste exemplo pretende-se mostrar a capacidade deste formalismo para representar a semntica em documentos. Pode-se, ento, concluir que, no s tem capacidades para o fazer, como nos d uma margem de manobra para criar extenses (a linguagem de clculo de atributos um novo universo operacional). No exemplo seguido, fez-se uma converso manual dum DTD para uma gramtica mas,
156
se considerarmos a tabela de converso construda (Tabela 9-1) fcil ver que este processo sistemtico e por isso automatizvel. E este o objectivo que iremos perseguir ao longo deste captulo, automatizar o processo de modo a que as gramticas de atributos no passem de uma mera curiosidade cientca para o utilizador. Na prxima seco (Seco 9.2) iremos descrever o desenvolvimento e implementao dum sistema que ir automatizar muitas das fases do ciclo de vida dos documentos SGML. Os conceitos fundamentais relacionados com o sistema S4 foram apresentados ao longo dos captulos anteriores: O SGML como objectivo de edio, as gramticas de atributos como fundamento de especicao, e o Synthesizer Generator como primeira ferramenta de implementao, tendo esta implementao evoludo recentemente para o sistema LRC.
9.2. O sistema S4
Apesar de ter sido um passo em frente na catica produo documental, o SGML no de todo acessvel ao utilizador comum. Quando, numa determinada linha administrativa, se faz a opo de produzir toda a documentao em SGML, algum cuidado deve ser colocado na adaptao dos utilizadores a esta nova maneira de "pensar"e "produzir"documentos. Esta foi uma das preocupaes que esteve na gnese do S4. A constatao do que se passa com as pginas HTML veio tambm reforar a ideia de criar o S4: no preciso ser-se um utilizador muito experiente para conseguir produzir documentos para disponibilizar no "World Wide Web (WWW)"; muita gente, nas mais variadas reas prossionais, produz pginas HTML; na maior parte das vezes, estes utilizadores no tm conscincia de que aquilo que esto a fazer escrever um documento SGML de acordo com um DTD o DTD do HTML. , precisamente, esta transparncia e simplicidade de utilizao que nos interessa captar para o sistema S4. O nome S4 vem do ingls "Syntax, Semantics and Style Specication".
157
Figura 9-1. S4 - os conceitos
O S4 surge como a reunio de todos os problemas e solues apontados e desenvolvidos no decorrer desta tese. A ideia, esquematizada na Figura 9-1, juntar debaixo do mesmo chapu as trs grandes linhas da edio estruturada de documentos: a sintaxe, a semntica e o estilo. No m, o sistema resultante ser capaz de gerar editores estruturados WYSIWYG sensveis a restries semnticas. O ponto comum, o chapu de que falvamos h pouco, um sistema gerador de compiladores baseado em gramticas de atributos; inicialmente comeou por ser o "Synthesizer Generator"[RT89a, RT89b], mas, a breve prazo, ser iniciado um projecto de implementao em LRC [SAS99] ou ANTLR [ANTLR] - a ideia encontrar o ambiente com maior capacidade de
158
portabilidade nos editores gerados, o SGen bastante limitado, o LRC e o ANTLR so menos limitados mas perdem algumas caractersticas de qualidade que o outro tem. Na prxima seco (Seco 9.2.1), descreve-se a arquitectura funcional do sistema, do ponto de vista do utilizador e do analista, antes de se apresentar a descrio do interior do sistema. Na seco seguinte (Seco 9.2.2), descreve-se o suporte da linguagem de restries, um dos contributos especcos desta tese. Por m mostra-se a aplicao da linguagem aos problemas dos casos de estudo levantados ao longo da tese.
9.2.1. Arquitectura do S4
Na Figura 9-2, apresenta-se a arquitectura bsica de utilizao do sistema. Figura 9-2. S4 - Ambiente para Programao de Documentos
O sistema disponibiliza duas interfaces diferentes: uma para o utilizador e outra para o analista. A ideia ter um sistema integrado com dois nveis de acesso diferentes. Um de carcter administrativo e outro de utilizao. A interface disponibilizada ao analista permite-lhe denir novos tipos de documento: qual a sua estrutura, quais os invariantes sobre o seu contedo que devero ser vericados e qual a aparncia/estilo (uma ou mais) nal dos documentos desse tipo. O utilizador apenas se servir do sistema para produzir os seus documentos por isso
159
apenas lhe permitida a escolha de um tipo de documento e dentro dos estilos disponveis para esse tipo qual o pretendido. Na Figura 9-3, apresenta-se o esquema da organizao interna do S4, com especial relevo para as relaes e dependncias entre os vrios editores. Figura 9-3. S4 - Estrutura interna
No S4, os botes da mquina de lavar so os trs editores representados na Figura 9-3. Como iremos ver a gura referida representa tambm uma espcie de uxograma do S4. O analista tem sua disposio dois editores, de certa forma interligados, um editor sensvel sintaxe do SGML que foi enriquecido com sintaxe extra de modo a permitir especicar restries e outro que sensvel a uma sintaxe muito semelhante linguagem "eXtended Style Language" (XSL - [xsl]). O primeiro serve
160
para o analista especicar o DTD e as restries semnticas, e o segundo para especicar o estilo, o aspecto visual de cada elemento. O editor de DTDs genrico, conhece a sintaxe SGML e permite ao analista especicar qualquer DTD. O editor de estilos j no genrico mas especco e dependente do DTD denido no editor de DTDs. O editor de estilos gerado pelo editor de DTDs e representa o primeiro resultado daquele. A ideia por detrs desta dependncia a de que, conhecendo a estrutura dum determinado tipo de documentos (DTD), a especicao de estilo ser restrita aos elementos presentes nessa estrutura. Assim, pode-se gerar um esqueleto da especicao de estilo automaticamente partindo do DTD, com a vantagem de nenhum elemento ter sido esquecido. Como j foi amplamente discutido, um DTD no mais do que uma gramtica (independente de contexto, se nos abstivermos de usar algumas das facilidades do SGML que uma vez que no foram implementadas no nosso editor no levantam qualquer problema) o que torna de certa maneira simples a gerao da gramtica abstracta correspondente (Seco 9.2.1.1). E esta gramtica abstracta, representada na sintaxe SSL, o segundo resultado do editor de DTDs. O editor de estilo gerado pelo editor de DTDs especco dum determinado DTD e vai permitir ao analista associar um estilo a cada um dos elementos nesse DTD (Seco 9.2.1.2). Recebendo estas especicaes (DTD, restries, especicao de estilo) o S4 vai usar uma segunda instncia do SGen para process-las e produzir um novo editor estruturado. Este editor especco e permitir ao utilizador escrever documentos de um determinado tipo. O cerne do S4, o editor de DTDs com restries, foi tambm gerado da mesma maneira que os novos editores; especicou-se em SSL o SGML; adicionou-se a especicao da sub-linguagem de restries; e, utilizou-se o SGen para compilar tudo e gerar o editor nal. Desta maneira, o S4 encontra-se implementado usando uma losoa de "bootstrap".
9.2.1.1. Editor de DTDs com Restries

O editor de DTDs com Restries, na sua primeira verso, foi objecto de estudo dum projecto de investigao (DAVID - especicao e processamento algbrico de documentos, [HAR99]) e duma tese de mestrado, onde o autor da presente tese
161
participou como co-orientador. Remete-se, por isso, o leitor interessado nos pormenores de implementao para a tese j referida [Lop98]. Depois da descrio das origens e do modo como foi concebido, vamos ver o que este editor capaz de fazer. A tarefa mais relevante deste editor a converso dum DTD para uma gramtica abstracta. Como j foi discutido, procurou-se automatizar este processo. A automatizao foi conseguido graas elaborao dum conjunto de regras que no seu todo formam o algoritmo de converso. No Apndice C, encontram-se descritas todas as regras que se sumarizam abaixo, pois sero importantes nas discusses que se seguiro: Elemento do DTD Smbolo no-terminal da gramtica abstracta Para cada elemento do DTD gerado um smbolo no-terminal da gramtica. O conjunto de produes deste smbolo permite derivar o contedo associado a este elemento. Estas produes so geradas num ou mais passos conforme a expresso de contedo do elemento: de notar que no DTD existem operadores de ocorrncia que no tm equivalncia na notao gramatical (h notaes gramaticais com BNF estendido [ANTLR], mas o SSL no pertence a esta categoria); a converso consegue fazer-se usando a tcnica de converso de expresses regulares em gramticas regulares (desde que algumas facilidades doSGML, que podem originar linguagens ambguas ou no-regulares, no estejam presentes; so exemplos dessas facilidades o operador &, as incluses e as excluses; nestes casos algoritmos especcos teriam de ser utilizados mas nem todas as situaes poderiam ser resolvidas - [Bru94]). Atributo dum Elemento do DTD Smbolo no-terminal da gramtica abstracta Neste ponto e logo partida, h um conito de nomes que necessrio esclarecer: o atributo dum elemento dum DTD diferente do atributo dum smbolo duma gramtica de atributos. O primeiro um subelemento estrutural do elemento a que pertence, e o segundo utilizado para associar informao semntica a um smbolo. Podemos ver isto ainda da seguinte maneira, em SGML temos dois nveis de especicao estrutural, o elemento e o atributo, nas gramticas temos apenas um nvel, o smbolo. A existncia destes dois nveis em SGML tem sido alvo de muitas discusses (Seco 5.1.6) e, muito recentemente, tem at sido posta em causa (Seco D.7) o mais recente
162
movimento a favor duma "Simplied Markup Language - SML" defende, entre outras coisas a eliminao de atributos mediante a unicao destes com os elementos. A soluo para a eliminao dos atributos do SGML passa pela promoo daqueles a elementos (quem est habituado a usar SGML ir sempre arguir que algo se perdeu). Uma vez que nas gramticas temos apenas um nvel de especicao estrutural, para convertermos DTDs em gramaticas vamos ter que colocar atributos e elementos no mesmo plano. Assim, atributo e elemento sero tratados da mesma maneira e um atributo, tal como o elemento corresponder a um smbolo no-terminal. Como h vrios tipos de atributo, cada um com a sua semntica especca, aqui as suas derivaes tambm sero diferentes: um atributo do tipo enumerado corresponder a um smbolo no-terminal com uma produo para cada um dos possveis valores; um atributo com valor por omisso #IMPLIED ter duas produes, uma vazia e outra para o respectivo valor; um atributo com valor por omisso #REQUIRED ser representado directamente pelo seu valor; ... Entidade do DTD Smbolo no-terminal da gramtica abstracta No caso das entidades, guardamos o seu identicador e os seus atributos num atributo da gramtica que implementa uma tabela de smbolos convencional [PP92] e que ser associado aos vrios smbolos gramaticais (gerados pelas regras anteriores). O principal efeito da declarao duma entidade faz-se sentir nos elementos textuais, pois aquelas podem aparecer em qualquer ponto do texto. Assim, a derivao de um elemento de contedo textual tem que contemplar a possibilidade de no meio do texto aparecerem referncias a entidades. Ao longo desta seco, a questo das restries e da linguagem usada para as especicar tem sido tratada de forma algo leviana. Isto deve-se ao facto de uma das prximas seces ser inteiramente dedicada a isso (Seco 9.2.2). A ttulo de exemplo, apresenta-se na subseco seguinte a converso de um DTD pertencente a um pequeno caso de estudo. 9.2.1.1.1. Um sistema noticioso automtico
163
Este exemplo foi extrado de uma aplicao real desenvolvida no mbito do projecto GEiRA [GEIRA]. Neste exerccio, utilizou-se um servidor de email especial para implementar um servio noticioso automtico. Qualquer pessoa que queira reportar um facto, um evento, ..., envia uma mensagem de email que tem de obedecer a uma certa estrutura. Esta mensagem processada pelo nosso servidor e se tudo estiver correcto a mensagem publicada numa pgina WWW que actua como um boletim noticioso. A estrutura da mensagem denida pelo DTD a seguir listado.
Exemplo 9-2. O DTD da Notcia O DTD que dene o tipo Notcia o seguinte:
<!DOCTYPE News [ <!- root element News has title, begin-date, an optional end-date and an optional body -> <!- it also has two required attributes: type and subject -> <!ELEMENT News - - (Title, Begin-date, End-date?, Body?)> <!ATTLIST News Type (Event | Novelty) #REQUIRED Subject (Nature | Culture | Science) #REQUIRED> <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT ]> Title Begin-date End-date Body Para (#PCDATA)> (#PCDATA)> (#PCDATA)> (Para)+> (#PCDATA)>
De acordo com o nosso ponto de vista, uma mensagem que nos fosse enviada por este sistema, para ser tomada como vlida, teria que respeitar o DTD e as seguintes restries semnticas:
164
As notcias do tipo Event tm de ter uma Begin-date (j exigida pelo DTD) e uma End-date. A End-date duma notcia do tipo Event dever sempre ser maior ou igual que a Begin-date dessa notcia.
No nosso caso, expressamos estas restries nos seguintes comentrios especiais:

<!-CONSTRAINT: if News.type = "Event" then End-date != Null-> <!-CONSTRAINT: date-> if News.type = "Event" then Begin-date <= End-
Aplicando as regras brevemente enunciadas no incio desta seco e detalhadas em apndice Apndice C, convertemos este DTD na Gramtica independente de contexto que se segue.
Exemplo 9-3. Gramtica Independente de Contexto para a Notcia

News NewsAttList NewsContent NewsAttList Type Subject Type EVENT | NOVELTY Subject NATURE | CULTURE | SCIENCE NewsContent Title Begin-date Grupo1_01 Grupo2_01 Title TitleAttList TitleContent TitleContent textLst TitleAttList Begin-date Begin-dateAttList Begin-dateContent Begin-dateAttList Begin-dateContent textList Grupo1_01 Grupo1 |
165
Grupo1 End-date End-date End-dateAttList End-dateContent End-dateAttList End-dateContent textList Grupo2_01 Grupo2 | Grupo2 Body Body BodyAttList BodyContent BodyAttList BodyContent Grupo3_1n Grupo3_1n Grupo3 Grupo3_1n | Grupo3
Grupo3 Para Para ParaAttList ParaContent ParaAttList ParaContent textList textList text textList | text STR
fcil ver que h muitas produes redundantes, mas elas so resultantes de um processo automtico de converso, que pode depois ser bem optimizado: por exemplo, elementos sem atributos no precisam de ter o terminal ElemNameAttList e as respectivas produes nulas. Para completar o exemplo, falta fazer a converso/derivao das restries semnticas. Ao contrrio do ponto anterior, em que as regras de converso j se encontram formalmente especicadas, para a converso das restries semnticas vamos seguir algumas regras empricas. O processo ainda est em fase de sistematizao. A prpria sintaxe em que se expressam as restries ainda est em discusso como veremos na prxima seco (Seco 9.2.2).
166
Exemplo 9-4. Converso da primeira restrio semntica da Notcia A primeira restrio semntica exige que todas as notcias do tipo Event tenham uma data de m (End-date) e foi denida assim:
<!-CONSTRAINT: if News.type = "Event" then End-date != Null->
A correspondente especicao gramatical :

News NewsAttList NewsContent CC: if(NewsAttList.newsType = "Event") then if(NewsContent.endDate != ) then "OK" else "ERRO" NewsAttList Type Subject NewsAttList.newsType = Type.newsType Type EVENT Type.newsType = "Event" | NOVELTY Type.newsType = "Novelty" NewsContent Title Begin-date Grupo1_01 Grupo2_01 NewsContent.endDate = Grupo1_01.endDate Grupo1_01 Grupo1 Grupo1_01.endDate = Grupo1.endDate | Grupo1_01.endDate = Grupo1 End-date Grupo1.endDate = End-date.endDate ... End-dateContent textList End-dateContent.endDate = Conv(date, textList)
newsType o atributo que transportar ao longo da rvore de sintaxe o "tipo da notcia". O seu valor sintetizado nas produes associadas a Type. Por sua vez, o atributo endDate sintetizado nas pordues associadas ao NT End-date e copiado ao longo da rvore at raz da subrvore a partir da qual se sintetiza este e o atributo newsType.
167
A segunda restrio semelhante primeira diferindo apenas no facto da restrio ser sobre o contedo de elementos e no sobre o valor de atributos.
Exemplo 9-5. Converso da segunda restrio semntica da Notcia A segunda restrio um predicado que diz que se a Notcia do tipo Event ento a data de m ter que ser superior data de incio, e foi denida assim:
<!-CONSTRAINT: date-> if News.type = "Event" then Begin-date <= End-
A correspondente especicao gramatical :

News NewsAttList NewsContent CC: if(NewsAttList.newsType = "Event") then if(NewsContent.beginDate <= NewsContent.endDate) then "OK" else "ERRO" NewsAttList Type Subject NewsAttList.newsType = Type.newsType Type EVENT Type.newsType = "Event" | NOVELTY Type.newsType = "Novelty" NewsContent Title Begin-date Grupo1_01 Grupo2_01 NewsContent.beginDate = Begin-date.beginDate NewsContent.endDate = Grupo1_01.endDate Grupo1_01 Grupo1 Grupo1_01.endDate = Grupo1.endDate | Grupo1_01.endDate = Grupo1 End-date Grupo1.endDate = End-date.endDate ...
168
End-dateContent textList End-dateContent.endDate = Conv(date, textList) Begin-dateContent textList Begin-dateContent.beginDate = Conv(date, textList)
Neste caso, temos dois atributos, beginDate e endDate, cujos valores so sintetizados. O valor de beginDate transportado ao longo da rvore at ao ponto onde endDate sintetizado. Nesse ponto, em posse dos dois valores j possvel calcular a condio de contexto.
Ao longo desta seco, vimos como est implementado o editor de DTDs com Restries na parte que diz respeito aos DTDs. A questo das Restries por ser muito importante no contexto desta tese foi delegada para uma seco especca no m do captulo (Seco 8.2). Na prxima seco, vamos "visitar"o editor de estilo que muito semelhante ao que acabou de ser descrito.
9.2.1.2. Editor de Estilo

O editor de estilo em tudo muito semelhante ao editor de DTDs com restries:
A ideia da sua integrao no sistema S4 surge tambm no mbito do projecto DAVID. A sua concepo deu origem a uma tese de mestrado [Sou98], tambm co-orientada pelo autor da presente dissertao. Foi gerado pelo SGen a partir duma especicao SSL (gerada pelo editor de DTDs). Como resultado, gera parte da especicao SSL dum editor (para ser integrada com a outra parte que gerada pelo editor de DTDs.
A losoa e a integrao destes editores esto relacionadas com a metodologia e a ferramenta que se esto a utilizar. Um editor estruturado gerado pelo SGen, ou pelo LRC, composto por dois blocos funcionais: um faz o reconhecimento sinttico e
169
semntico e como resultado produz uma representao intermdia (uma rvore de sintaxe abstracta decorada); o outro realiza uma tarefa de sntese, faz uma travessia representao intermdia e gera normalmente uma viso transformada dos dados da rvore. Na gura seguinte, apresenta-se este esquema. Figura 9-4. Arquitectura funcional dum editor estruturado
O reconhecimento essencialmente especicado pela gramtica de atributos da linguagem que se est a reconhecer e usa equaes sobre os atributos da gramtica para construir a representao intermdia. A sntese essencialmente especicada pelas "unparsing rules", que tambm podem recorrer a equaes sobre atributos para transformar parte da informao. Sobre o editor de estilos, e uma vez que a sua concepo e funcionamento muito semelhante ao editor de DTDs, no nos vamos alargar mais. O leitor mais interessado poder recorrer leitura da referida tese de mestrado onde discutida a linguagem implementada e a concepo do editor. O resto deste captulo ser inteiramente dedicado linguagem de restries: sua denio e implementao.
9.2.2. Linguagem de Restries

At este ponto, o leitor atento dever ter notado que a preocupao com a linguagem de restries est patente ao longo de quase toda a tese. A motivao por detrs dela e a prpria linguagem em si so um dos principais contributos desta tese.
170
No entanto, notria a obscuridade que paira sobre a denio da sua sintaxe. A ideia seguida foi a de discutir este assunto ao nvel mais abstracto possvel tentando fugir da sua concretizao. Mesmo na abordagem com modelos abstractos seguida no captulo anterior (Captulo 8), fugiu-se a esta questo. Utilizou-se a linguagem do ambiente de prototipagem para especicar as restries. Pode parecer que a soluo adoptada ento semelhante que se defende mais frente neste captulo. H, no entanto, uma grande diferena. A linguagem utilizada para a especicao de restries no tinha nenhuma relao com o SGML ou sequer tinha sido pensada para o processamento de documentos estruturados, o que levou a que o documento SGML fosse processado por uma ferramenta (anlise sinttica) e as restries por outra (anlise semntica). A soluo que se persegue aqui ir no sentido de integrar estes dois processamentos. Como se poder ver mais frente, a sintaxe que se ir escolher para a especicao das restries est muito ligada natureza dos documentos estruturados SGML, tornando mais fcil a sua percepo e aquisio. Nesta altura, j no possvel fugir mais sua denio pois estamos a discutir a implementao dum sistema em que ela aparece integrada. E, embora os editores gerados pelo Sgen (usado nas primeiras verses do S4) no necessitem duma sintaxe concreta para arrancar e funcionar, vo precisar dela sempre que se tentar reutilizar algum texto criado pelo sistema. Em termos abstractos, e supondo que as restries sejam simplesmente locais a um elemento (condies associadas sempre ao elemento), basta-nos enriquecer a denio do elemento da seguinte maneira:
elem : Element( identificador, expresso-contedo, restrio);
Um elemento passa a ser um triplo composto por um identicador, uma expresso de contedo e uma restrio (simples ou composta). Faltaria agora continuar a denir (em termos abstractos) a estrutura de cada um dos elementos do triplo. Por outro lado, a sintaxe concreta que queremos ter no nosso sistema a do SGML e j vimos quais as possibilidades de adicionar restries usando a sintaxe SGML, sem a alterar (Seco 8.3). Qualquer uma das solues apontadas no prev uma associao implcita, duma restrio a um elemento. Essa associao tem de ser feita e a soluo mais simples usar a tcnica das bases de dados para relacionar duas tabelas: neste caso, usar um dos campos do triplo.
171
O campo mais lgico para ser utilizado como chave da relao entre a denio do elemento e da restrio o identicador do elemento. Porm a realidade diferente da suposio feita acima e na prtica levanta-se outro problema: o mesmo elemento pode aparecer em contextos diferentes e por isso, ter semnticas diferentes. Portanto as restries no devem ser associadas a um elemento mas sim a um contexto, donde o que precisamos no do identicador do elemento mas de algo ligeiramente mais complexo: um selector de contexto. Assim, se usarmos comentrios especiais como sintaxe de base para as restries, podamos ter uma sintaxe concreta com a seguinte forma:
<!- CONSTRAINT sel-contexto (restrio) ->
Ou seja, h duas coisas a considerar numa restrio, a seleco do contexto, e a especicao da restrio propriamente dita. Este ponto, permitiu abrir a discusso da sintaxe concreta da linguagem de restries e dividi-la desde j em duas partes: a sub-linguagem de seleco de elementos e a sub-linguagem com a qual se iro especicar as restries. A operao de seleccionar os elementos com os quais se quer fazer alguma coisa, ou aos quais se quer aplicar algum processamento, tem sido, desde h algum tempo, uma preocupao das pessoas que trabalham nesta rea. Comeou por surgir na transformao e na formatao: era preciso seleccionar os elementos que se queriam transformar, ou que se queriam mapear num ou mais objectos com caractersticas grcas (formatao). Este esforo visvel no DSSSL (j discutido na Seco 6.2); o primeiro elemento das suas regras uma expresso de "query" que selecciona os elementos aos quais ser aplicado o processamento especicado. Por ltimo, esta necessidade surgiu ligada s linguagens de "query" para documentos estruturados, como as que foram propostas na ltima conferncia dedicada a esse tpico [RLS98, DeR98, Tom98, Wid8, CCDFPT98]. At aqui s se levantou a ponta do vu e j comearam a proliferar linguagens, todas elas com o mesmo objectivo. Foi o que constataram alguns investigadores ligados rea e que comearam a olhar com mais ateno para cada uma delas tentando extrair um denominador comum. Assim se chegou, rapidamente, concluso de que a operao de seleco necessria para a transformao ou formatao era muito semelhante necessria nos sistemas de bases de dados documentais para a realizao de "queries".
172
Seguindo a mesma linha de raciocnio, podemos dizer que a linguagem de selectores de que necessitamos para as restries tambm equivalente quelas, podendo ns, desta maneira, tirar partido duma linguagem j existente com as seguintes vantagens: menos uma sintaxe no mundo das linguagens e consequentemente no nosso sistema, menos trabalho de implementao, menos trabalho de aprendisagem e de ensino, e por tudo isto menos confuso. Depois de algum tempo de discusso (moderada pelo W3C - World Wide Web Consortium), comea a emergir algum consenso na utilizao do XSLT [xslt], uma sublinguagem de padres presente no XSL [xsl] - a proposta de normalizao para a especicao de estilos a associar a documentos XML. O XSLT encontra-se j numa fase prvia ao lanamento de um standard e foi j alvo de um estudo formal por parte de Wadler [Wad99], apresentado na ltima conferncia mundial da rea ("Markup Technologies 99"), e onde ele dene a linguagem usando semntica denotacional (formalismo de cariz funcional utilizado para especicar a sintaxe e a semntica de linguagens - [Paa95]). Durante o trabalho desta tese, tambm se procedeu ao estudo de algumas destas linguagens (em particular todas as que j foram referidas) e, foi fcil constatar que o XSLT um denominador comum de uma grande parte delas, aquelas que foram desenvolvidas a pensar em documentos estruturados, tratando-se portanto de uma linguagem especca. Houve, no entanto, uma linguagem que cativou a ateno do autor, pela sua simplicidade e recurso teoria de conjuntos, a linguagem proposta por Tim Bray [Bray98] na QL98 - The Query Languages Workshop designada por Element Sets. Um estudo mais atento da linguagem e do seu historial, revelou ser esta a especicao por detrs do conhecido motor de procura Pat comercializado pela OpenText e utilizado na maior parte dos primeiros portais da Internet. Enquanto as linguagens do tipo XSLT assentam numa sintaxe concreta e especca, a Element Sets dene uma notao abstracta baseada em cinco operadores da teoria de conjuntos: contido (within), contm (including), unio (+), interseco (^) e diferena (-). Bray argumenta ser capaz de especicar uma grande percentagem de queries que possam ser necessrias num sistema de arquivo documental custa da combinao daqueles cinco operadores. Numa primeira anlise e a ttulo comparativo, apresentam-se a seguir dois exemplos, uma query simples e uma mais complicada que iro ser especicadas respectivamente recorrendo a XSLT e a Element Sets.
173
Exemplo 9-6. Query simples Pretende-se seleccionar todos os pargrafos (PARA) pertencentes introduo (INTROD) que contenham uma ou mais notas de rodap (FOOTNOTE) ou uma ou mais referncias (REF) a outros elementos no documento. Em Element Sets a query seria:
set1 set2 set3 set4 = = = = Set(PARA) within Set(INTROD) set1 including Set(FOOTNOTE) set1 including Set(REF) set2 + set3
A funo Set selecciona todos os elementos do tipo indicado no argumento. No m, o resultado da query dado pelo valor de set4. Por outro lado, em XSLT teramos:
INTROD/PARA[FOOTNOTE $or$ REF]
A query tem duas partes, a primeira de seleco de contexto, INTROD/PARA, que selecciona todos os pargrafos dentro da introduo, e a segunda parte de restrio desse contexto, [FOOTNOTE $or$ REF], que restringe o conjunto de elementos seleccionadas queles que tenham pelo menos um elemento do tipo FOOTNOTE ou REF.
Depois desta comparao, num caso muito simples, veja-se uma outra situao de interrogao mais elaborada.
Exemplo 9-7. Query mais complexa Pretende-se agora, seleccionar todos os pargrafos da introduo que contenham uma referncia ou uma nota de rodap mas no ambos. Em Element Sets a query seria:
set1 = Set(PARA) within Set(INTROD) set2 = set1 including Set(FOOTNOTE) set3 = set1 including Set(REF)
174
set4 = (set2 + set3) - (set2 ^ set3)
Apesar de complexa, foi fcil especicar esta query. Bastou excluir (diferena de conjuntos) os elementos resultantes da query anterior que continham ambos os elementos (interseco de conjuntos), REF e FOOTNOTE. Temos agora, a especicao em XSLT:
INTROD/PARA[(FOOTNOTE $and$ $not$ REF) OTNOTE)] $or$ (REF $and$ $not$ FO-
Do estudo comparativo realizado entre os dois tipos de linguagem, e do qual os dois exemplos acima fazem parte, podemos concluir que, em termos da operao de seleco, so mais ou menos equivalentes, no se tendo encontrado nenhuma situao que uma solucionasse e a outra no. Vo diferir no mtodo como fazem a seleco: o XSLT usa a rvore documental e toda a operao de seleco feita em funo dessa estrutura; a Element Sets, por outro lado, no usa a rvore documental, manipula o documento como um conjunto de elementos usando uma sintaxe mais universal. Mas esta diferena existe apenas perante o utilizador que usa a linguagem porque em termos de implementao no se pode fugir s travessias da rvore documental. Tendo estudado os dois paradigmas era preciso tomar uma deciso: Qual a linguagem a adoptar/adaptar para a sub-linguagem de seleco no S4? Ao contrrio do que o leitor poderia supor nesta altura, a escolha no recaiu sobre a Element Sets mas sim sobre uma linguagem do tipo XSLT, a XQL - XML Query Language [RLS98]. Os motivos por detrs desta escolha so muito simples. Apesar dos paradigmas, em termos de seleco, serem equivalentes, as linguagens do tipo XSLT vo alm da seleco, permitem ter um segundo nvel de seleco baseado em restries sobre o contedo. A ideia utilizar a sintaxe desse segundo nvel de seleco para especicar as restries; apenas ser necessrio alterar-lhe a semntica: em lugar dum conjunto de elementos, devolver um valor booleano. Assim as nossas restries sero compostas, como referido, por uma seleco e uma condio, mas integradas na mesma sintaxe. No resto desta seco, iremos descrever ambas as partes da linguagem.
9.2.2.1. Escolha da linguagem
175
A linguagem XSLT fornece um mtodo bastante simples para descrever a classe de nodos que se quer seleccionar. declarativa em lugar de procedimental. Apenas preciso especicar o tipo dos nodos a procurar usando um tipo de padres simples baseado na notao de directorias dum sistema de cheiros (a sua estrutura equivalente de uma rvore documental). Por exemplo, livro/autor, signica: seleccionar todos os elementos do tipo autor contidos em elementos livro. A XQL uma extenso do XSLT. Adiciona operadores para a especicao de ltros, operaes lgicas sobre contedo, indexao em conjuntos de elementos, e restries sobre o contedo dos elementos. Basicamente, uma notao para a especicao de operaes de extraco de informao de documentos estruturados. No nosso contexto, vamos dar-lhe uma aplicao diferente. Vamos usar uma parte para seleccionar elementos/contexto e outra para calcular condies de contexto sobre esses elementos. A condio de contexto vai ter um comportamento semelhante a um invariante: a linguagem de query selecciona todos os elementos para os quais se obtm um valor verdadeiro da condio; na nossa utilizao da linguagem, uma mensagem de erro ser emitida sempre que um dos elementos seleccionados faa com que se obtenha um valor falso da condio. Como j foi dito, vamos comear por descrever operadores relacionados com a seleco mas a linha divisria entre seleco e restrio ir sendo diluda ao longo do texto, confundindo-se at, para os casos em que a integrao das duas muito forte. 9.2.2.1.1. Padres e Contexto Uma expresso de seleco sempre avaliada em funo dum contexto de procura. Um contexto de procura um conjunto de nodos a que uma expresso se pode aplicar de modo a calcular o resultado. Todos os nodos no contexto de procura so lhos do mesmo nodo pai; o contexto de procura constitudo por todos os nodos que so lhos deste nodo pai e respectivos atributos mais os atributos do nodo pai. As expresses de seleco podero ser absolutas (o contexto seleccionado em funo do nodo raz - "/"), ou relativas (o contexto seleccionado em funo do contexto actual - "."). Na especicao do contexto pode ainda ser usado o operador "//"com o signicado de descendncia recursiva.
176
Exemplo 9-8. Seleco de contextos 1. Seleccionar todos os elementos autor no contexto actual.
./autor
Que equivalente a:
autor
2. Seleccionar o elemento raz (livro) deste documento.

/livro
3. Seleccionar todos os elementos autor em qualquer ponto do documento actual.

//autor
4. Seleccionar todos os elementos captulo cujo atributo tema igual ao atributo especialidade de livro.
captulo[/livro/@especialidade = @tema]
5. Seleccionar todos os elementos ttulo que estejam um ou mais nveis abaixo do contexto actual.
.//ttulo
9.2.2.1.2. Quanticador: todos O operador "*"quando usado numa expresso de seleco selecciona todos os elementos nesse contexto.
Exemplo 9-9. Seleco com "*" 1. Seleccionar todos os elementos lhos de autor.
autor/*
2. Seleccionar todos os elementos nome que sejam netos de livro.

livro/*/nome
177
3. Seleccionar todos os elementos netos do contexto actual.

*/*
4. Seleccionar todos os elementos que tenham o atributo identicador.

*[@identificador]
9.2.2.1.3. Atributos Como j se pde observar nalguns exemplos, o nome de atributos precedido por "@". Os atributos so tratados como sub-elementos, imparcialmente, sempre que possvel. De notar que os atributos no podem ter sub-elementos pelo que no podero ter operadores de contexto aplicados ao seu contedo (tal resultaria numa situao de erro sintctico). Os atributos tambm no tm conceito de ordem, so por natureza anrquicos pelo que nenhum operador de indexao dever ser-lhes aplicado.
Exemplo 9-10. Seleco com atributos 1. Seleccionar o atributo valor no contexto actual.
@valor
2. Seleccionar o atributo dlar de todos os elementos preo no contexto actual.

preo/@dlar
3. Seleccionar todos os elementos captulo que tenham o atributo lngua.

captulo[@lngua]
4. Seleccionar o atributo lngua de todos os elementos captulo.

captulo/@lngua
5. O prximo exemplo no vlido.

preo/@dlar/total
178
9.2.2.1.4. Filtro - sub-query O resultado duma query pode ser renado atravs de uma sub-query (restrio aplicada ao resultado da query principal), indicada entre "["e "]"(nos exemplos anteriores j apareceram vrias sem nunca se ter explicado a sua sintaxe e semntica). A sub-query equivalente clusula SQL WHERE. O valor resultante da aplicao de uma sub-query booleano e os elementos para os quais o valor nal seja verdadeiro faro parte do resultado nal. H operadores nas sub-queries que permitem testar o contedo de elementos e atributos. Vamos deixar a sua discusso para a seco seguinte pois iremos us-los para especicar restries.
Exemplo 9-11. Sub-query 1. Seleccionar todos os elementos captulo que contenham pelo menos um elemento excerto.
captulo[excerto]
2. Seleccionar todos os elementos ttulo pertencentes a elementos captulo que tenham pelo menos um elemento excerto.
captulo[excerto]/titulo
3. Seleccionar todos os elementos autor pertencentes a elementos artigo que tenham pelo menos um elemento excerto, e onde autor tenha email.
artigo[excerto]/autor[email]
4. Seleccionar todos os elementos artigo que contenham elementos autor com email.
artigo[autor/email]
5. Seleccionar todos os elementos artigo que tenham um autor e um ttulo.

artigo[autor][titulo]
Como se pode observar nalguns destes exemplos, algumas das restries que pretendemos colocar sobre os documentos podem ser especicadas com os
179
construtores e operadores j apresentados. A linha divisria entre a seleco e a restrio parece j um pouco diluda. Como os restantes operadores que se podem usar nas sub-queries j permitem interrogar contedos vamos discuti-los como uma aproximao especicao de restries.
9.2.2.1.5. Expresses booleanas As expresses booleanas podem ser usadas nas sub-queries e estas, j nos permitem especicar condies contextuais como a restrio de valores a um domnio. Uma expresso booleana tem a seguinte forma:
val-esquerda $operador$ val-direita
Os operadores tm a forma $operador$ e so normalmente binrios: tomam como argumentos um valor esquerda e um valor direita. Com estes operadores e o agrupamento por parentesis podem especicar-se queries bastante complexas, no nosso caso, restries.
Exemplo 9-12. Operadores booleanos 1. Seleccionar todos os elementos autor que tenham um email e um url.
autor[email $and$ url]
No universo das queries, o resultado seria o conjunto de autores que tivessem email e url. Do nosso ponto de vista, e pensando na expresso como uma especicao duma restrio aplicada a todos os elementos autor o resultado seria uma mensagem de erro para todos os autores que no tivessem um email ou um url. 2. Seleccionar todos os elementos autor que tenham um email ou um url e pelo menos uma publicao.
autor[(email $or$ url) $and$ publicao]
3. Seleccionar todos os elementos autor que tenham um email e nenhuma publicao.

autor[email $and$ $not$ publicao]
180
4. Seleccionar todos os elementos autor que tenham pelo menos uma publicao e no tenham email nem url.
autor[publicao $and$ $not$ (email $or$ url)]
Como se pode ver, todas estas queries podem ser encaradas como restries, apenas preciso dar uma interpretao diferente aos resultados. A partir deste ponto, e uma vez que os operadores seguintes so dirigidos ao contedo, vamos, nos exemplos, deixar de nos referir a queries, e passar a faz-lo em relao a restries.
9.2.2.1.6. Equivalncia A igualdade notada por = e a desigualdade por !=. Alternativamente podem ser usados $eq$ e $neq$. Podemos usar strings nas expresses desde que limitadas por aspas simples ou duplas. Na comparao com o contedo de elementos o mtodo value() est implcito. Por exemplo nome=Carlos uma abreviatura de nome!value()=Carlos. Como se disse no m da ltima seco, vamos agora dar exemplos de restries. Apesar de algumas parecerem um pouco "articiais", elas so necessrias para exemplicar alguns dos operadores.
Exemplo 9-13. Equivalncia 1. Garantir que todos os autores tm o sub-elemento organizao preenchido com o valor U.Minho.
autor[organizao = U.Minho]
2. Garantir que todos os elementos tm o atributo lngua preenchido com o valor pt.
*[@lngua = pt]
3. Imaginemos que temos vrios documentos relativos aos curriculae de vrios autores e que estes documentos foram gerados automaticamente a partir de uma
181
base de dados. Agora queremos garantir que todos as publicaes tm o sub-elemento nome do elemento autor preenchido com um valor igual ao sub-elemento nome que gura no elemento curriculum.
publicao/autor[nome = /curriculum/nome]
Esta uma restrio complexa uma vez que envolve a comparao de elementos localizados em diferentes ramos da rvore documental, da a necessidade de recorrer a duas expresses de seleco. 4. Vamos agora para uma situao corrente numa instituio. O prazo para a entrega da proposta em que a equipe tem vindo a trabalhar foi ultrapassado. Em conversa com a entidade competente fomos informados de que os documentos ainda iriam a tempo se fossem entregues nos prximos dois dias mas as datas constantes nos documentos teriam de ser inferiores a 1999-12-22. Podamos adaptar o nosso editor para fazer essa vericao acrescentando-lhe a seguinte condio de contexto:
data[. < 1999-12-22]
O operador . selecciona o contedo do contexto actual. Assumiu-se que as datas estavam normalizadas, de qualquer modo, as que no estiverem no passaro pela restrio e sero detectadas.
A linguagem possui todos os operadores relacionais habituais, cuja utilizao no foi aqui exemplicada, porm, a sua semntica bem conhecida e o seu lugar na linguagem ser bem especicado na prxima seco onde iremos denir formalmente a linguagem de restries.
9.2.2.2. Denio da linguagem de restries

As restries sero especicadas junto com o DTD usando seces de comentrio especiais (intocadas pelo parser SGML, podendo por isso ter uma sintaxe mais alargada). A restrio propriamente dita ser especicada em CL ("Constraint Language") que no mais do que o subconjunto da XQL apresentada na seco anterior. A declarao duma restrio ter a seguinte forma:
182
<!- - CONSTRAINT
expresso-CL
aco - - >
Onde: CONSTRAINT uma palavra reservada que serve para indicar ao interpretador das restries que este no um comentrio SGML mas uma expresso em CL que dever ser processada. expresso-CL uma expresso em CL que especica a condio de contexto a ser vericada. aco a aco que dever ser executada sempre que o clculo da expresso resultar num valor falso. Nesta primeira verso, corresponder apenas a uma string que conter uma mensagem de erro a ser mostrada sempre que a aco fr despoletada. Tendo denido o enquadramento das restries com o SGML, vai-se agora apresentar a denio formal da CL. A CL no um subconjunto da XQL, apenas utiliza uma parte da sintaxe da outra, semanticamente so completamente diferentes como se poder ver frente. Iremos usar gramticas de atributos para especicar a sua sintaxe e semntica. Para que a denio aqui apresentada no que muito pesada ser usada a sintaxe SSL apenas para a declarao dos atributos e especicao das suas equaes de clculo. Nas funes semnticas que iro surgir, e que aparecero devidamente especicadas (assinatura e descrio), assumida uma estrutura global, o grove (Seco 6.2.4.1), que construdo durante o reconhecimento do documento. A maior parte destas funes so o que se denomina por vezes de "tree-walkers"; o grove uma estrutura arbrea muitas vezes vista como uma lista generalizada e que uma representao abstracta aceite para representar o documento anotado (contedo, anotao, atributos, ...). Cada restrio em CL, ir fazer clculos sobre o grove e este sempre assumido globalmente por cada restrio. Isto tem uma implicao: no h
183
endereamentos relativos no grove, cada expresso de contexto dever especicar um endereo absoluto. Para uma melhor identicao as produes encontram-se numeradas de 1 a n, sendo 1 a produo correspondente ao axioma. A estrutura seguida para a especicao de cada produo a seguinte:
n <produo> <declarao atributos> <equaes de clculo>
e, por sua vez <declaracao atributos> :

<Smbolo> {(modo tipo nome-atributo;)+};
Para efeitos de legibilidade, os atributos so declarados na produo correspondente sua primeira utilizao. Assim, a nossa gramtica de atributos :
1. CLexp Contexto Cond CLexp { syn STR contexto; syn STR condicao; syn MAP[IDENT,BOOL] resultado; }; Contexto { syn STR fc; }; /* final context exp */ Cond { syn STR fb; }; /* final boolean exp */ { $$.contexto = Contexto.fc; $$.condicao = Cond.fb; $$.resultado = Valida($$.contexto, $$.condicao); };
Uma expresso em CL estruturalmente constituda por duas partes: um selector de contexto, e uma condio. Portanto, o smbolo no-terminal (NT) CLexp ir ter dois atributos sintetizados; um que sintetizar a expresso de contexto e outro que sintetizar a condio: contexto, condicao. O clculo da expresso de contexto dever resultar num conjunto de nodos do grove (muitas vezes singular). Por outro lado, o clculo da expresso condicional, quando
184
aplicada aos nodos anteriores resultar num conjunto de valores booleanos. Ambas as expresses so sintetizadas num formato pr-xo ( semelhana de uma linguagem funcional tipo LIST). Quando da expresso de contexto resultar um conjunto de nodos, a condio ser avaliada para cada um deles individualmente. A funo semntica valida recebe uma expresso de contexto que ir seleccionar um conjunto de nodos no grove, recebe ainda uma condio e vai calcular para cada nodo o valor booleano da condio. No m, produz um resultado que uma correspondncia entre o identicador do nodo e o resultado booleano do clculo da condio sobre esse nodo.
2. Contexto / RelContexto RelContexto { syn STR fc; inh STR ic; }; { $$.fc = RelContexto.fc; RelContexto.ic = "ROOT"; };
O NT RelContexto tem um atributo herdado (ic), necessrio em todos os smbolos com produes recursivas com dependncias semnticas e que tem o valor sintetizado na iterao anterior. A expresso de contexto / representa o nodo raz do grove. Isso indicado atravs da constante "ROOT".
3. Contexto RelContexto { $$.fc = RelContexto.fc; RelContexto.ic = "ROOT"; };
Quando a expresso no comea por / assume-se que o contexto inicial "ROOT".

4. RelContexto elem-id / RelContexto elem-id { syn IDENT v; }; { $$.fc = RelContexto$2.fc; RelContexto$2.ic = "(Sel " + elem-id.v + $$.ic + ")"; };
185
elem-id um smbolo terminal que tem um atributo intrnseco (proveniente da anlise lxica) cujo valor corresponde ao nome dum elemento. A funo Sel tem a seguinte assinatura:
Sel : nome identificador-set identificador-set
Ou seja, funciona como um ltro. Restringe o conjunto de nodos passado como segundo parmetro, aos nodos que tenham o nome igual ao primeiro parmetro. Note-se a diferena entre nome e identicador. Pode haver vrios nodos com o mesmo nome, por exemplo captulo, mas cada um desses nodos tem um identicador nico que calculado pelo sistema no momento da construo do grove.
5. RelContexto elem-id / / RelContexto { $$.fc = RelContexto$2.fc; RelContexto$2.ic = "(Descendentes " + elemid.v + $$.ic + ")"; };
A funo Descendentes tem a seguinte assinatura:

Descendentes : identificador-set identificador-set
Recebe um conjunto de identicadores como entrada e d como resultado o conjunto de identicadores de todos os nodos dos sub-groves com raz correspondente aos nodos referenciados pelos identicadores entrados.
6. RelContexto * { $$.fc = "(Filhos " + $$.ic + ")"; };
A funo Filhos tem a seguinte assinatura:

Filhos : identificador-set identificador-set
Recebe um conjunto de identicadores (normalmente singular) e devolve um conjunto de identicadores correspondentes aos nodos lhos dos nodos correspondentes aos identicadores de entrada.
7. RelContexto elem-id { $$.fc = "(Sel " + elem-id.v + " " + $$.ic + ")"; }; 8. RelContexto @ Atrib Atrib
186
{ syn IDENT v; }; { $$.fc = "(Atributo " + Atrib.v + " " + $$.ic + ")"; };
A funo Atributo tem a seguinte assinatura:

Atributo : atrib-identificador identificadorset atrib-identificador-set
Esta funo selecciona identicadores correspondentes a Atrib.v (nome de um atributo) que sejam lhos de algum dos nodos em identicador-set.
9. Atrib atrib-id atrib-id { syn IDENT v; }; { $$.v = atrib-id.v; };
atrib-id.v um atributo intrnseco proveniente da anlise lxica.

10. Atrib * { $$.v = "ALL"; };
ALL um identicador especial, selecciona todos os atributos. A sua utilidade no contexto da linguagem de restries tambm ser discutida numa futura optimizao.
11. Cond [ Exp ] { $$.fb = Exp.fb; };
Primeira produo respeitante derivao de condio. Como j foi dito, iremos sintetizar uma expresso na forma pr-xa com parentesis para a condio.
12. Exp Termo OR Exp Termo { syn STR fb; }; { $$.fb = "(Or "+Termo.fb+" "+Exp.fb+")"; };
187
As funes presentes na expresso que est a ser sintetizada so as operaes lgicas e aritmticas normais pelo que no iremos aqui deni-las.
13. Exp Termo { $$.fb = Termo.fb; }; 14. Termo Factor AND Termo Factor { syn STR fb; }; { $$.fb = "(And "+Factor.fb+" "+Termo.fb+")"; }; 15. Termo Factor { $$.fb = Factor.fb; }; 16. Factor SubExp SubExp { syn STR fb; }; { $$.fb = SubExp.fb; }; 17. Factor NOT SubExp { $$.fb = "(Not "+SubExp.fb+")"; }; 18. Factor ( Exp ) { $$.fb = Exp.fb; }; 19. SubExp Operando comp-op Operando Operando { syn STR valor; }; comp-op {syn STR op; }; { $$.fb = "("+comp-op.op+ " "+ Operando.valor+" "+" "+Operando.valor+")"; };
com-op.op um atributo intrnseco sintetizado da anlise lxica e que poder ter um dos valores: =, !=, <, >, <=, >=.
20. Operando elem-id { $$.valor = "(Contedo "+elem-id.v+")"; };
188
A funo Contedo tem a seguinte assinatura:

Contedo : identificador-set STR-seq
Um dos componentes dos nodos tipo elemento o seu contedo (relembrar a estrutura dum grove). Esta funo extrai esse contedo dos nodos correspondentes aos identicadores e devolve-os numa lista.
21. Operando . Cond, Exp, Termo, Factor, SubExp, Operando {inh STR ic; }; { $$.valor = "(Contedo(eval("+Operando.ic+"))"; };
Operando tem um atributo herdado de nome ic que tem a expresso de contexto sintetizada no axioma. Este valor passado ao longo da rvore atravs deste atributo herdado que todos aqueles NT acima indicados tm. Nas produes anteriores, no se colocaram as equaes de cpia ("copy rules") para no tornar a gramtica desnecessariamente pesada. A funo eval recebe uma expresso de contexto e d como resultado um conjunto de identicadores. Tem a seguinte assinatura:
eval : contexto-exp identificador-set 22. Operando @ atrib-id { $$.valor = "(Valor "+atrib-id.v+")"; };
A funo Valor semelhante funo Contedo, s que aplicada a atributos. Valor devolve uma lista correspondente aos valores dos atributos cujos identicadores lhe so passados como parmetro. Tem a seguinte assinatura:
Valor : atrib-identificador-set STR 23. Operando Expnum Expnum {syn STR vnum; };
189
{ $$.valor = Expnum.vnum; }; 24. Operando string { $$.valor = string.v; };
string.v um atributo intrnseco proveniente da anlise lxica.

25. Operando Selec Selec { syn STR fc; }; { $$.valor =" (Contedo(eval "+Selec.fc+"))"; };
O NT Selec representa o path para um elemento ou atributo noutro ponto da rvore que no o nodo corrente ou algum da sua descendncia. Ser usado para derivar condies que comparam valores localizados em sub-groves distintos.
26. Operando ( SubExp ) { $$.valor = SubExp.fb; }; 27. Selec / RelSelec RelSelec { syn STR fc; inh STR ic; }; { $$.fc = RelSelec.fc; RelSelec.ic = "ROOT"; };
A construo da expresso de contexto para Selec ser muito semelhante que foi usada para o NT Contexto.
28. Selec RelSelec { $$.fc = RelSelec.fc; RelSelec.ic = ; }; 29. RelSelc elem-id / RelSelec { $$.fc = RelContexto$2.fc; RelContexto$2.ic = "(Sel " + elem-id.v + $$.ic + ")"; }; 30. RelSelc elem-id { $$.fc = "(Sel " + elem-id.v + " " + $$.ic + ")"; }; 31. RelSelc @ atrib-id
190
{ $$.fc = "(Atributo " + Atrib.v + " " + $$.ic + ")"; }; 32. Expnum TermoN OpAd ExpNum TermoN { syn STR vnum; }; { $$.vnum = (OpAd.op == +) ? "(+ "+TermoN.vnum+" "+Expnum$2.vnum+")" : "(- "+TermoN.vnum+" "+Expnum$2.vnum+")"; };
As expresses aritmticas so semelhantes s expresses lgicas. O esquema de prioridades reectido na gramtica o mesmo, apenas muda a simbologia dos operadores.
33. Expnum TermoN { $$.vnum = TermoN.vnum; }; 34. TermoN FactorN OpMul TermoN FactorN { syn STR vnum; }; { $$.vnum = (OpMul.op == *) ? "(* "+FactorN.vnum+" "+TermoN$2.vnum+")" : "(/ "+FactorN.vnum+" "+TermoN$2.vnum+")"; }; 35. TermoN FactorN { $$.vnum = FactorN.vnum; }; 36. FactorN num { $$.vnum = num.v; }; 37. FactorN ( Expnum ) { $$.vnum = Expnum.vnum; };
Fica assim denida a primeira verso da linguagem de restries. Haver com certeza optimizaes a fazer. Um dos aspectos a ter em conta no trabalho futuro ser analisar a utilidade dos operadores denidos, alguns deles introduzem muita complexidade a nvel semntico, caso venha a concluir-se que no so muito necessrios sero os primeiros a sair. Na seco seguinte, vamos ilustrar a utilizao da linguagem, aplicando-a a exemplos que tm vindo a ser introduzidos.
191
9.2.2.3. Aplicao aos casos de estudo apresentados

Ao longo dos captulos anteriores, foram apresentados vrios problemas onde era necessrio especicar condies de contexto que teriam de ser vericadas de modo a limitar os erros no contedo dos respectivos documentos. Vamos, agora, ver como se especica cada uma daquelas restries com a linguagem que acabamos de denir. Iremos identicar cada exemplo e indicar a soluo proposta na altura em que foi apresentado: Reis e Decretos Este foi o exemplo utilizado no captulo anterior para ilustrar a abordagem especicao de restries com modelos abstractos. Na altura, especicaram-se as restries em CAMILA da seguinte forma:
rei(r) = { if(nome_(r) notin PessFamDB > nome_(r) ++ "No existe..."), if(datan_(r) > datam_(r) > nome_(r) ++ "Morreu antes de nascer."), if(datam_(r) - datan(r) > 120 > nome_(r) ++ "Viveu demais!"), if(!all( x<-decreto_l(r) : datan_(r) < data_(x) /\ data_(x) < datam_(r)) > nome_(r) ++ "fez um decreto fora da sua vida!") };
Usando CL especicaramos as mesmas restries assim:

<!- - CONSTRAINT /rei[datan/@valor < datam/@valor] "Morreu antes de nascer" - -> /rei[datan/@valor-datam/@valor < 120] "Viveu muito tempo" - ->
<!- - CONSTRAINT
<!- CONSTRAINT
/rei/decreto[(data/@valor < rei/datam/@valor) $or$ (data/@valor > rei/datan/@valor)]
192
"Fez decretos fora da sua vida" - ->
No foi possvel exprimir a primeira condio pois nesta verso da CL no foi prevista a ligao a bases de dados. Na comparao das datas usou-se o atributo valor pois aqui que est o valor normalizado da data (lembrar discusso sobre a normalizao de contedos: Exemplo 7-2). Arqueologia No Captulo 7, pegamos num caso real em que estvamos a trabalhar, a edio dos "Arqueostios do Noroeste portugus", para exemplicar a necessidade de invariantes durante a edio de documentos. Especicamente, tnhamos dois campos, latitude e longitude, cujo contedo deveria estar compreendido dentro de determinado domnio. Estava prevista uma ligao a um sistema de informao geogrco, e aquele domnio seria denido pelas coordenadas das extremidades do mapa. Em CL, seria simples especicar esta restrio:
<!- - CONSTRAINT latitude[(.>39) $and$ (.<42)] "Latitude errada!" - -> longitude[(.>0) $and$ (.<55)] "Longitude errada!" - ->
<!- - CONSTRAINT
Ou ainda, e relembrando que um contexto de procura constitudo por todos os nodos que so lhos do nodo pai indicado, e respectivos atributos, mais os atributos do nodo pai:
<!- CONSTRAINT arqueositio[(latitude>39) $and$ (latitude<42)] "Latitude errada!" - ->
<!- - CONSTRAINT arqueositio[(longitude>0) $and$ (longitude<55)] "Longitude errada!" - ->
Esta ltima soluo s testa acondio para os elementos latitude e longitude do arqueostio. Se outros houver ela no lhes ser aplicada.
193
9.2.2.4. Estado actual do S4

Neste momento, o estado de implementao do S4 o seguinte:
o editor de DTDs est implementado sem restries. No entanto, no decorrer desta tese as regras de converso de DTDs para GAs foram revistas vrias vezes da resultando a verso em apndice (Apndice C), que muito diferente da que se encontra implementada [Lop98]; logo uma reimplementao ser necessria. a linguagem de restries tem agora a sua sintaxe e semntica especicadas numa gramtica de atributos (a sua implementao no ser difcil). o editor de estilos est implementado [Sou98], mas a ligao ao editor de DTDs necessita de ser trabalhada; a linguagem para a especicao de estilos dever tambm ser revista o que reconduzir a nova implementao.
Neste captulo, apresentamos o contributo mais importante da tese: a denio formal da linguagem de restries e a construo duma arquitectura funcional que integra o processamento desta nova linguagem com o ciclo de vida dos documentos SGML. A tese termina no prximo captulo com uma sntese do trabalho realizado e deixando alguns indicadores de trabalho futuro.
194
Captulo 10. Concluso

Neste documento descreve-se o trabalho realizado pelo autor na sua tese de doutoramento. O trabalho teve duas grandes linhas orientadoras. A estruturao de documentos, como a maneira de os tornar mais "ricos"e mais "vivos". E, a especicao da semntica dos documentos, desde a aparncia visual at interpretao (signicado) do seu contedo como um meio de melhorar a qualidade na produo documental electrnica. No m, estas duas linhas acabaram por convergir na elaborao dum novo modelo de processamento documental. As vantagens dos documentos estruturados foram apresentadas e os passos para a implementao de um sistema de produo de documentos estruturados foram descritos. Depois, apresentou-se o conjunto de necessidades e requisitos actuais que se podem colocar a um sistema destes e analisou-se aquilo que se designou por "semntica dos documentos". As necessidades identicadas esto relacionadas com o problema da qualidade de contedos na publicao electrnica. A qualidade em publicaes electrnicas pode ser analisada segundo vrios parmetros, desde o aspecto visual , o lingustico e literrio, correco da informao (signicado, semntica). A tecnologia existente permite de alguma forma automatizar e normalizar todos estes aspectos, excepto o ltimo. Foi no desenvolvimento de uma soluo para este problema que se centrou esta dissertao: como adicionar semntica esttica (condies contextuais ou invariantes) aos documentos; e como processar esta semntica esttica dum modo integrado com a tecnologia existente. Foram apresentadas duas vias para a soluo da especicao e processamento da semntica esttica, a primeira segue uma aproximao via modelos abstractos, a outra, uma aproximao via gramticas de atributos. As duas abordagens surgiram em alturas diferentes e seguiram duas direces diferentes. Enquanto na abordagem com modelos abstractos optamos por denir modelos especcos (deriva-se o modelo do DTD), na abordagem com gramticas de atributos construmos a representao abstracta habitual para um documento, o grove, e assumimos a existncia duma mquina virtual que trabalha sobre o grove com quatro funes de travessia. A primeira abordagem revelou-se mais fraca porque:
195
o analista tem que especicar as restries em CAMILA (tem que conhecer mais uma sintaxe) a especicao de restries est dependente do modelo (este especco) as travessias da estrutura (uma vez que esta especca) tm que ser especicadas em CAMILA pelo analista
Todas estas razes no vo contra a metodologia utilizada (especicao via modelos abstractos) mas sim contra a utilizao dela (modelo especco, processamento especco). A segunda abordagem resultou muito melhor porque:

a informao sempre carregada na mesma estrutura abstracta, o grove a linguagem denida pelo autor e na qual so especicadas as restries tem uma sintaxe orientada manipulao do grove, bastante simples e acessvel o analista no precisa de programar nenhuma travessia ou outro tipo de processamento sobre o grove; o processador da linguagem de restries traduz estas para instrues duma mquina virtual que tem nela implementadas todas as travessias e processamentos necessrios
Da implementao desta segunda abordagem resultou o sistema S4, um sistema de processamento documental que integra e implementa as ideias defendidas: especicao de sintaxe, de estilo e de semntica. Como j foi referido (Captulo 9), o S4 est ainda num estado embrionrio de implementao: existe um prottipo do editor de DTDs; existe um prottipo do editor de estilos; a linguagem de especicao para as restries foi denida nesta dissertao. Nos prximos tempos, vai-se lanar um novo projecto de implementao do S4, onde se iro combinar os dois prottipos existentes e adicionar o terceiro componente para tratamento das restries (editor + processador). Neste momento, est em desenvolvimento uma terceira abordagem resultante da experincia prtica que o autor tem vindo a adquirir com o desenvolvimento de projectos reais nesta rea. Esta abordagem passa pela utilizao de um motor de transformao "Open Source"; as restries so especicadas na linguagem denida pelo utilizador e o motor alterado para que durante a travessia do documento teste se h restries a ser calculadas; se houver, processa-as e faz depender o resto da execuo do resultado desse processamento.
196
10.1. Trabalho Futuro

Depois de ler esta dissertao (apndices includos), fcil concluir que esta uma rea em permanente ebulio e que novas linguagens e metodologias surgem a cada dia que passa. Porm, h duas etapas do ciclo de vida dos documentos que no tm tido a ateno das outras, so elas: a anlise e o armazenamento. Relativamente anlise, as metodologias vo aparecendo [MA96]. O mesmo no acontece com ferramentas que as implementem (ferramentas visuais para especicao de estrutura, motores de inferncia gramatical): so quase inexistentes! Esta portanto uma linha de investigao em aberto que o autor pretende explorar no futuro e se possvel integrar resultados da resultantes no S4. Em relao ao armazenamento, apesar da grande variedade de produtos existente [DuC98], a verdade que nenhuma das equipes de desenvolvimento por detrs deles exps como que o seu sistema armazena os documentos, que mecanismos implementou para tirar partido da sua estrutura, etc. Isto leva-nos a crer que as suas solues podero ser solues de implementao e no metodologias que possam ser aplicadas genericamente. H aqui, portanto, trabalho a desenvolver, que tipo de base de dados utilizar, como criar os ndices de modo a tirar partido da estrutura dos documentos, que mecanismos de endereamento utilizar, etc. claro, que o S4 tambm ir, no futuro, necessitar dum sistema de armazenamento, pelo que este trabalho de investigao dever tambm ser integrado no projecto global do S4. O S4, por sua vez, ser integrado com outras linhas de investigao relacionadas, tais como: criao e manuteno de catlogos para documentos estruturados; thesaurus; e encicolpdias electrnicas. Este novo projecto de investigao, do grupo de investigao onde est integrado o autor da presente dissertao, ser designado por Scriptorium.
197
Apndice A. Como foi produzida esta tese

Porqu este apndice? No esta tese igual a tantas outras? A resposta poderia ser sim, noutro local ou noutra fatia temporal, mas neste caso no. Neste momento, provavelmente a primeira tese a ser produzida de raz na lngua portuguesa usando a tecnologia SGML. Como tal, importante que quem registados os vrios passos dados na realizao deste objectivo. A publicao desta tese constituiu em si um pequeno projecto cujas etapas se enumeram a seguir: 1. Anlise da estrutura da dissertao e denio do DTD. 2. Escolha do editor estruturado de SGML. 3. Escolha de um sistema de formatao: stylesheets, processadores, conversores, ... 4. Escolha do formato de sada, HTML, RTF, TeX/PDF, a ser produzido para visualizao e impresso do documento. 5. Denio de uma estratgia para o desenvolvimento (escrita e impresso) modular da tese. Vamos agora ver com mais detalhe cada uma das etapas.
A.1. O DTD
O primeiro passo dum projecto deste tipo consiste sempre na anlise do tipo de documento que se quer desenvolver para se decidir pela escolha dum DTD j existente para essa classe, ou pela criao dum novo. Uma vez que criar um DTD pode vir a ser uma tarefa rdua, sempre aconselhvel procurar um DTD j desenvolvido que sirva as nossas necessidades (at porque juntamente com o DTD , normalmente, desenvolvido um conjunto de ferramentas que nos podem fazer ganhar tempo noutras etapas do projecto).
198
Em 1998, David Megginson publicou uma anlise que fez aos DTDs disponveis no mercado [Meg98]. Nessa anlise, ele catalogou cada DTD seguindo alguns parmetros, nomeadamente: facilidade de aprendizagem; facilidade de utilizao; e facilidade no processamento. A facilidade na aprendizagem medida em funo de alguns parmetros como o tamanho (nmero de elementos e atributos), consistncia e o ser ou no intuitivo. A facilidade na utilizao est quase exclusivamente relacionada com a organizao em nveis do DTD (corresponde ao esforo fsico de criao dum contexto, instanciao de atributos, ...). A facilidade no processamento est muito relacionada com os dois items anteriores: diversidade de contextos, previso, anlise do DTD. A anlise de mercado de Megginson reduziu o domnio de escolha a cinco possibilidades, que correspondem s maiores percentagens de utilizao por parte da indstria de publicao electrnica: ISO 12083 Este devia ter sido o DTD da indstria da publicao electrnica. Foi desenvolvido por um grupo de especialistas da publicao electrnica para a preparao e anotao de manuscritos electrnicos. Resultou num DTD de dimenso considervel e com grande complexidade o que aliado a algumas incapacidades como a falta de consenso na anotao da matemtica fez com que no tivesse grande aceitao. DocBook DTD utilizado e desenvolvido inicialmente pela IBM. Hoje um dos mais difundidos, com direito at a publicaes sobre a sua concepo e parametrizao [WM99]. Entre muitos outros utilizado pela IBM, pela OReilly, e na maior parte das publicaes SGML cientcas. Foi um dos DTDs a ir para a balana, na implementao desta tese. Text Encoding Initiative (TEI) Este DTD resulta de um esforo de cinco anos por parte de membros da comunidade acadmica e de investigao. Iniciado em 1987, o projecto desenvolveu-se custa da vontade de pessoas ligadas s reas de humansticas, cincias sociais e letras, que utilizavam computadores. Este grupo percebeu as
199
vantagens de ter um mesmo conjunto de anotaes para a sua produo documental: reduzir a diversidade de conjuntos de anotaes (DTDs) existentes e em uso, simplicar o processamento feito pelo computador, e encorajar o intercmbio de textos electrnicos. O DTD foi sendo desenvolvido modularmente (segundo os autores seguindo o modelo da "Chicago Pizza") e com o decorrer dos anos foi engrossando a sua estrutura aumentando desta maneira o nmero de reas de aplicao [SB94]. Hoje , dos DTDs mais utilizados o maior e a referncia a utilizar pela comunidade de humansticas, artes, letras e cincias sociais. Tambm foi para a balana na implementao desta tese. MIL-STD-38784 (CALS) Um dos primeiros grupos a adoptar o SGML como formato de base para a produo documental foi o exrcito americano. Exrcito e organizaes governamentais investiram meios no desenvolvimento de DTDs para documentos como os manuais de manuteno de aeronaves e outro tipo de equipamento pesado. Desse esforo resultaram alguns bons DTDs. O que est aqui em questo para a produo de manuscritos mas a falta de informao sobre a sua utilizao muito grande no domnio pblico. No entanto, houve um mini-DTD desenvolvido por este grupo que se tornou um standard: designado por CALS-TABLE-MODEL um pequeno DTD includo na maior parte dos outros para tratar a informao com estrutura tabular. HTML 4.0 Como a produo documental para a Internet no pra de aumentar e, apesar de todos os avisos, a maior parte dessa documentao continua a ser produzida em HTML, este ainda um dos DTDs com maior nmero de utilizadores [html4.0]. Por razes bvias levantadas ao longo desta tese (mistura de contedo e forma, conjunto de anotaes limitado, ...), este DTD no foi tido em conta na nossa seleco. Depois desta pequena exposio, no dever ser difcil concluir que a escolha estaria entre o Docbook e o TEI. Foi uma deciso trabalhosa. Testaram-se ambos
200
em vrios documentos e com vrias ferramentas. Destes testes resultaram as seguintes concluses:
Ambos tm um tamanho considervel, o que tem algumas implicaes na facilidade de utilizao. H um maior suporte para o Docbook. Quase todas as ferramentas de SGML/XML trazem uma verso desse DTD, pronta a usar. Existe algum suporte para o TEI, mas a sua utilizao nunca foi to directa como a do outro. Para o Docbook existem uma srie de ferramentas de processamento mas, mais importante, existe um projecto a decorrer de desenvolvimento e aperfeioamento dum conjunto de stylesheets DSSSL. No caso do TEI, e reportando-nos poca em que se tomou esta deciso (1996/97), existiam apenas algumas scripts em Perl para o processar, e o projecto de criao de stylesheets DSSSL estava ainda numa fase de estudo de viabilidade. Dado que, a escolha teria que ter em ateno o que viria frente, foi principalmente o ltimo ponto (a existncia de stylesheets DSSSL) que fez com que a escolha recasse sobre o Docbook.
A.2. O Editor
Depois de ter escolhido o DTD, era necessrio decidir sobre qual o ambiente de edio a utilizar. Um editor normal no serviria pois no permitiria tirar partido da utilizao do SGML. Assim, foi necessrio procurar um editor SGML na oferta do mercado de ento (hoje as possibilidades so mais variadas). Para alm dos parmetros normais a ter em conta na seleco dum editor de texto (velocidade, suporte grco, manuseamento de rato), h outros que necessrio ter em conta quando o editor vai ser usado para editar SGML:
O editor deve ser capaz de reconhecer no texto as anotaes que marcam o incio e m dos elementos, os atributos, e as entidades, denidos por um DTD. O editor deve fornecer ajuda contextual ao utilizador. Preveni-lo sempre que este incorrer em erro, fornecer a lista de anotaes vlidas num determinado ponto do documento, e localiz-lo na rvore estrutural do documento.
201
O editor deve permitir que o utilizador se desloque, ao longo do texto, de anotao em anotao.
A seguir enumeram-se os editores analisados. Nalguns casos foram mesmo testados em situaes reais, como a escrita de artigos que seriam enviados para conferncias SGML (nessas conferncias, os artigos s so aceites para avaliao se forem redigidos de acordo com um determinado DTD, o que obriga utilizao dum editor SGML e/ou a uma validao posterior com um parser). Emacs + PSGML Na altura, esta plataforma representava a nica soluo sem custos de aquisio e consistia no editor Emacs (disponvel para quase todas as plataformas) parametrizado com o modo PSGML [Sta99] (o Emacs um editor aberto que permite que a maior parte das suas funcionalidades sejam reescritas; o PSGML uma congurao para adaptar o editor ao SGML: introduz a ajuda contextual na edio e acrescenta uma srie de menus para gerir as anotaes). Os primeiros artigos submetidos a conferncias de SGML foram escritos usando esta plataforma. Os resultados eram satisfatrios. Comearam a surgir problemas com as ltimas verses do Emacs, o modo PSGML no se instalava correctamente e o funcionamento do editor cava um pouco baralhado. Houve que procurar outra plataforma. FrameMaker+SGML Depois de contactada, a Adobe enviou uma cpia do produto que se podia utilizar em pequenos projectos para efeitos de avaliao. O FrameMaker era, nas verses anteriores, um editor/processador de texto muito poderoso, esta verso com suporte para SGML manteve essas caractersticas. Testmo-lo num projecto de estgio dum aluno nalista que redigiu o respectivo relatrio em SGML usando a ferramenta. Pudemos concluir o seguinte: O ambiente de trabalho muito bom, ajuda contextual grca, o utilizador pode seleccionar o modo como quer editar o texto (como um editor normal ou trabalhando sobre a rvore documental), WYSIWYG permitindo mesmo ter imagens (uma limitao de muitos editores SGML), fecha o ciclo
202
de produo permitindo a partir duma especicao de estilo (numa linguagem prpria) que o utilizador gere o resultado nal que entender (PDF,PS, ...). Tem, no entanto, uma grande desvantagem, a congurao do editor difcil e a linguagem para a especicao de estilo tambm no acessvel. Como estes motivos criavam atrasos, esta soluo foi colocada de lado. WordPerfect+SGML Esta plataforma foi-nos cedida pela Corel numa conferncia SGML. O objectivo deles foi arranjar uma equipe de testes sem custos (o produto cedo revelou que ainda precisava de uns acabamentos). Podemos dizer que se trata de um editor j conhecido, com umas pequenas adaptaes para trabalhar com o SGML. Assim, perde um pouco quando comparado com ferramentas semelhantes desenvolvidas de raz a pensar no SGML. De notar, que esta plataforma serve apenas para edio, apesar de ser WYSIWYG os resultados impressos no so satisfatrios. A verso testada, WordPerfect 8.0, tinha alguns problemas com as guras e alguns ambientes onde a preservao dos caracteres brancos era essencial. Na altura, uma nova verso estava em desenvolvimento, na qual, o autor fez parte da equipe de testes tendo apontado alguns problemas detectados na utilizao da verso anterior. Depois de algumas utilizaes e devido a alguns problemas (pequenos mas que por vezes assumiam outras dimenses), acabamos por colocar esta soluo de lado. Adept Editor Este produto da Arbortext, talvez seja o melhor editor do mercado. No foi possvel test-lo "em casa"uma vez que a empresa no foi receptiva a um perodo de experimentao ou mesmo a uma utilizao no ensino e uma licena do produto custa dez vezes mais que a licena dum editor mdio. AuthorEditor Simples, ecaz, barato. Foi a nossa escolha. O produto foi descontinuado depois da Softquad ter vendido os seus direitos, no entanto, a mesma empresa
203
lanou um novo produto compatvel com todos os documentos SGML criados pelo outro, mas mais vocacionado para documentos XML: o XMetal. O XMetal tambm est a ser utilizado nos nossos projectos. No est a ser utilizado para este da tese porque apareceu numa fase em que a escrita desta ia avanada e, apesar do contedo no estar dependente da plataforma (lembrar uma das caractersticas fundamentais do SGML), a mudana exigiria uma adapatao da metodologia de trabalho que no se justicava. Ao longo desta exposio, discutiram-se os editores SGML com mais utilizao e com mais presena no mercado. A nossa escolha foi motivada em primeiro pelo custo e em segundo pela simplicidade e suporte da losoa SGML.
A.3. O Formatador
Alm da edio dirigida pela sintaxe SGML, a validao estrutural dum documento assegurada por um parser (SP) associado ao Editor. Assim, sada do editor temos um documento SGML puro (texto com anotaes e sintaticamente vlido). H que process-lo para se obter o documento num formato ideal para publicao. O ideal que este processamento seja o mais standard possvel, sem haver necessidade de muitas parametrizaes ou mesmo programaes especcas. Pretendia-se que esta tese fosse publicada em papel ( o normal e obrigatrio), em CDROM e na Internet. O que implicava a gerao do documento em formato: para papel, RTF, PDF ou PS; para a Internet e CDROM, HTML. Tnhamos, portanto partida dois formatos bem diferentes, o normal para papel em que um documento estruturado em pginas, e o outro, em HTML, no tem conceito de pgina fsica (no h dimenses limites), hipertexto (consegue-se navegar no documento seguindo as referncias e entradas de ndices). Depois do que foi apresentado na tese, havia tambm a convico de se usar DSSSL para especicar o estilo no qual o documento deveria ser convertido. Uma das razes que fez a escolha recair sobre o DTD Docbook foi a existncia dum projecto de desenvolvimento dum conjunto de stylesheets em DSSSL para processar documentos escritos segundo aquele DTD. Este projecto de desenvolvimento est a ser conduzido por Norman Walsh com a designao "Modular Docbook DSSSL Stylesheets" [Wal2000] e tem recebido contribuies de vrias dezenas de
204
utilizadores o que faz com que novas e melhoradas verses sejam lanadas cada quinze dias (quando aderimos ao esquema comeamos por utilizar a verso 1.05, agora j estamos a utilizar a verso 1.50). A compatibilidade entre verses garantida desde que algum cuidado seja tido em conta aquando da sua utilizao. De qualquer modo, a linguagem de especicao no alterada, o que acontece que elementos que no eram suportados pela especicao tm vindo a ser adicionados. Como o Docbook nunca tinha sido usado para formatar um documento escrito em portugus foi preciso adicionar o suporte da lngua portuguesa, tarefa que logo me dispuz a fazer e que uma vez terminada, foi imediatamente adicionada distribuio por Walsh. Tendo o documento SGML e a especicao DSSSL do estilo era preciso um processador que percebesse as duas linguagens, fosse capaz de juntar os dois cheiros e produzir o resultado nal desejado. A escolha dessa ferramenta foi simples, o jade [jade] o motor de DSSSL que suporta mais funcionalidades da linguagem (existem outros como o SENG escrito em Java mas o suporte da linguagem muito parcial), e alm disso no tem direitos comerciais, como vem sendo hbito no software desenvolvido por James Clark ( distribudo ao abrigo da licena da GNU). Com o documento SGML e a especicao de estilo DSSSL, o jade pode converter o documento em RTF, TeX, MIF, HTML, texto ASCII, ou FOT (documento xml que descreve o grove nal do processo de formatao, a Flow Object Tree). Como a essncia do formato HTML diferente dos outros, seriam necessrias duas especicaes de estilo j previstas na distribuio das stylesheets. Houve que parametrizar cada uma delas. A parametrizao feita pelo autor para a verso papel foi a seguinte:
<!DOCTYPE style-sheet PUBLIC //James Clark//DTD DSSSL Style Sheet//EN" [ <!ENTITY dbstyle SYSTEM "..\style1.50\docbook\print\docbook.dsl" CDATA DSSSL> ]> <style-sheet> <style-specification use="docbook <style-specification-body> (define %paper-type% "A4")
205
(define (define (define (define
%default-title-end-punct% " ") %two-side% #t) %section-autolabel% #t) %example-rules% #t)
(define biblio-citation-check #t) (define biblio-number #f) </style-specification-body> </style-specification> <external-specification id="docbook" document="dbstyle </style-sheet>
Como se pode ver, um grande nmero de parmetros esto relacionados com a mancha de texto no papel. A parametrizao para HTML ligeiramente diferente:
<!DOCTYPE style-sheet PUBLIC //James Clark//DTD DSSSL Style Sheet//EN" [ <!ENTITY dbstyle SYSTEM "../style1.44/docbook/html/docbook.dsl" CDATA DSSSL> ]> <style-sheet> <style-specification use="docbook <style-specification-body> (define %default-title-end-punct% " ") (define %section-autolabel% #t) (define %example-rules% #t) (define biblio-citation-check #t) (define biblio-number #f) (element emphasis (let ((func (if (attribute-string (normalize "ROLE")) (attribute-string (normalize "ROLE")) (normalize "normal")))) (cond ((equal? func "SCRIPT") ($italic-mono-seq$))
206
((equal? func "NORMAL") ($italic-seq$)) (else (literal func))))) </style-specification-body> </style-specification> <external-specification id="docbook" document="dbstyle </style-sheet>
As parametrizaes relacionadas com o papel desapareceram. Podemos ver aqui uma redenio de estilo para o elemento EMPHASIS. Est-se a usar este elemento para inserir letras num estilo matemtico. Para esse efeito, o seu atributo ROLE toma um valor que indica o tipo de contedo do elemento. O estilo portanto condicionado pelo contedo do atributo ROLE. Para a verso papel, optou-se de incio por gerar RTF. O resultado era directamente visvel no MSWord Viewer, o que permitia trabalhar num s sistema operativo (o AuthorEditor s existe para Windows). As coisas corriam bem at se ter atingido o montante de 120 pginas. A partir daqui o MSWord Viewer comeou a ter um comportamento no determinstico em relao s imagens, umas eram carregadas outras no (as imagens no formato RTF so mantidas externamente, no cdigo h apenas um comando de incluso da imagem; da responsabilidade do software que ir abrir o documento, o carregamento das imagens). Com mais algumas pginas, as imagens simplesmente deixaram de ser carregadas o que impossibilitava a sua impresso e mesmo a disposio correcta do texto uma vez que o respectivo espao no era reservado. Tnhamos um problema grave, era preciso gerar outro formato para a impresso em papel. O avanado estado de escrita da tese no permitia grandes aventuras, e por uma questo de princpio era conveniente manter a produo em SGML e a formatao em DSSSL. A opo foi comear a gerar TeX. A partir do TeX era tambm possvel gerar PDF o que nos deu dois caminhos escolha: 1. Gerar TeX; converter as imagens para EPS; o resultado nal para impresso seria o Postscript. 2. Gerar TeX; converter o TeX em PDF; converter as imagens para PNG; o resultado nal para impresso seria o PDF (que permite tambm distribuir como edio electrnica - CDROM).
207
Como o resultado da converso das imagens para EPS no foi satisfatrio, ao contrrio da converso daquelas para PNG, optou-se pela segunda via. O jade gera um formato TeX especial, que para ser processado precisa duma verso e duma congurao especial: o jadetex (que vem acompanhado do pdfjadetex que realiza a converso posterior para PDF). O jadetex um processador de TeX especco que realiza a converso pretendida muito bem, contudo a sua congurao muito penosa e, ainda, preenchida com alguns passos obscuros. Depois desta plataforma estar instalada, tudo comeou a correr melhor, as imagens j eram carregadas (no caso do PDF elas so includas dentro do cheiro nal), mas as tabelas (apenas 3 ou 4) apareciam completamente desformatadas. Com a ajuda preciosa de um dos autores do jadetex, o Sebastian Rhatz, constatou-se que a verso do jade que eu utilizava era a mais pura mas para o caso precisava duma verso extendida desenvolvida por um grupo de utilizadores que decidiram levar o desenvolvimento do jade a srio e criaram o projecto de desenvolvimento OpenJade [OpenJade]. Depois de instalado (na verso 1.2.2), o circuito montado cou a funcionar em pleno, permitindo gerar esta verso da tese.
A.4. A organizao da tese em mdulos

Dada a dimenso da tese e a variedade de formatos para cada imagem (cada imagem mantida em GIF, PNG e WMF), o seu desenvolvimento dentro de um s cheiro cedo deixou de ser vivel. Assim, houve que estrutur-la em mdulos e fazer corresponder cada mdulo a um documento. A tese foi dividida em captulos, cada captulo um documento SGML. Cada imagem mantida num cheiro no sistema. Imagens do mesmo formato esto agrupadas numa coleco. H um documento especial que o elemento agregador, onde esto declarados os vrios mdulos, as vrias coleces de imagens, e onde est especicado em que ordem os mdulos so carregados e, no caso particular das imagens, qual a coleco que deve ser carregada (as coleces de imagens encontram-se em seces condicionais e s uma dever estar activa. A seguir apresenta-se um extracto desse documento comentado:
208
<!DOCTYPE BOOK PUBLIC -//OASIS//DTD DocBook V3.1//EN" [ <!- O formato PNG para imagens no fazia parte do DTD, houve que declar-lo. <!NOTATION PNG SYSTEM "PNG <!- Declarao dos vrios mdulos -> <!ENTITY <!ENTITY <!ENTITY ... <!ENTITY ... <!ENTITY header SYSTEM "header.sgm prefacio SYSTEM "prefacio.sgm chap2 SYSTEM "chap2-doc.sgm ap-a SYSTEM "ap-a.sgm biblio SYSTEM "biblio.sgm
->
<!- Tratamento das letras usadas na matemtica enquanto as entidades do ISOmscr no forem suportadas -> <!ENTITY % my-script SYSTEM "script.ent %my-script; <!- Tratamento das vrias coleces de imagens -> <!ENTITY % my-wmf SYSTEM "my-wmf.ent <!ENTITY % my-gif SYSTEM "my-gif.ent <!ENTITY % my-png SYSTEM "my-png.ent <!- Apenas <!ENTITY % <!ENTITY % <!ENTITY % ]> uma carregada: include -> RTF "INCLUDE HTML "IGNORE TEX "IGNORE
<!- tese.sgm: o documento -> <BOOK LANG="pt &header; <TOC></TOC> &prefacio; &chap2; ...
209
&ap-a; ... &biblio; </BOOK>
Os restantes mdulos so documentos SGML simples. Para gerir todas as especicaes envolvidas, DTD - cerca de 30 cheiros, especicao DSSSL - cerca de 60 cheiros, tese - cerca de 110 cheiros, usaram-se identicadores pblicos (acaba por ser um identicador abstracto). Este identicadores pblicos so depois mapeados em identicadores do sistema; isto faz-se usando declaraes prprias no cheiro catalog. A vantagem que podemos reutilizador vrias vezes um mdulo, carregando o seu contedo, referenciando-o por aquele identicador pblico. Se um dia decidirmos alterar a localizao ou o cheiro que est a ser usado para o mdulo s ser preciso alterar a respectiva declarao no catalog. A ttulo de exemplo apresenta-se o catalog principal da tese:
-Main Catalog file for my phd thesis -jcr 1999.11.12 CATALOG CATALOG CATALOG CATALOG CATALOG "..\dtd\docbook.cat" "wmf.cat" "gif.cat" "eps.cat" "iso-ent.cat"
CATALOG "..\style1.50\docbook\catalog"
fcil concluir que este catlogo constitudo apenas por referncias a outros catlogos. Por exemplo, a primeira declarao indica onde est o catlogo para o DTD (cada verso do DTD traz um - para actualizar para uma verso mais actual basta-nos instalar a nova verso e alterar esta declarao para procurar o novo catlogo), a ltima indica qual o catlogo para a especicao DSSSL. As outras entradas carregam os meus catlogos das coleces de imagens. A ttulo de exemplo apresenta-se a seguir um excerto do catlogo para as imagens PNG:
210
- CHAP8 - Validacao com GAs - S4 PUBLIC -//jcr//ENTITIES S4: Arquitectura Conceptual 19991216//PNG" "../imagens/PDF/s4-arq-conceptual.png" PUBLIC -//jcr//ENTITIES INES: Arquitectura Funcional 19991112//PNG" "../imagens/PDF/ines-arq.png" PUBLIC -//jcr//ENTITIES S4: Arquitectura Funcional 19991217//PNG" "../imagens/PDF/s4-arq-func.png" PUBLIC -//jcr//ENTITIES Arquitectura funcional dum editor estruturado 20000120//PNG" "../imagens/PDF/estrutura-editor.png"
Esta apresentao dos catlogos encerra a discusso da implementao modular da tese.
A.5. Resultados gerados

As diferentes verses da tese, nos dois formatos referidos obtm-se invocando o jade:
PDF Para gerar o PDF so necessrios dois passos. No passo intermdio gera-se TeX e s depois se converte este para PDF:
jade -t tex -d jcr.dsl tese.sgm pdfjadetex tese.tex
a opo -t indica qual o formato desejado para o resultado; a opo -d indica qual a especicao DSSSL a utilizar; por m o terceiro elemento nome do documento SGML que se quer processar. HTML A gerao de HTML mais fcil, basta invocar o jade e indicar que se quer transformar o documento SGML passado como parmetro noutro documento SGML (lembrar que o HTML SGML).
jade -t sgml -d jcr2.dsl tese.sgm
211
Note que a especicao DSSSL outra, correspondente parametrizao para HTML das folhas de estilo distribudas. As imagens usadas nesta verso esto em formato GIF. Termina aqui a redaco do "Making of My Thesis". O objectivo deste apndice foi mostrar que: muitas das ideias defendidas na tese esto aplicadas na sua edio electrnica; a tecnologia SGML vivel e funciona; se fosse adoptada em Universidades e outras instituies acadmicas, como formato obrigatrio para a produo de teses, tornaria a distribuio e publicao destas mais fcil e consequentemente o seu contedo acessvel a mais gente, bem como ajudaria a ajustar o DTD e at as ferramentas para a sua edio/formatao.
212
Apndice B. Projectos desenvolvidos

Para se trabalhar e perceber bem o SGML necessrio estar envolvido em problemas reais. S assim se consegue atingir um nvel de compreenso do standard sucientemente alto para apontar defeitos e porpr novas solues. Desta necessidade de envolvimento surgiram uma srie de projectos, uns grandes outros mais pequenos, dos quais se destacam os que a seguir se descrevem. Os projectos encontram-se agrupados em dois grupos. O primeiro designado por "Publicao Electrnica"tinha o ponto de partida num formato digital no SGML. O segundo, designado por "Recuperao de edies esgotadas", tinha o seu ponto de partida numa verso em papel. Portanto, o tratamento dumas fontes e doutras foi diferente como a seguir se expe.
B.1. Publicao Electrnica

Em 1989-90, foi desenvolvida, no Arquivo Distrital de Braga, uma linguagem de anotao para a edio dos livros que ento se tentava publicar. De nome HiTex, por basear a sua sintaxe no TeX e usar aquele processador como ferramenta de formatao e composio nal, foi usada na anotao de vrios livros. Apesar do HiTeX ser uma linguagem de anotao anterior ao SGML (pelo menos na altura no havia conhecimento da existncia deste), seguia j alguns dos bons princpios do SGML. No entanto, na presso nal para a publicao daqueles livros muito cdigo procedimental foi-lhes acrescentado, tronando hoje a sua alterao e reedio muito difcies. Surgiu ento a ideia, em 1997, de recuperar aqueles textos convertendo-os em documentos SGML para posterior publicao na Internet e papel. disso que tratam os trs projectos que se descrevem a seguir.
B.1.1. Publicao na Internet das "Memrias Particulares de Incio Jos Peixoto"

Como o ttulo indica, o objectivo nal foi a publicao na Internet do referido livro. Como ponto de partida havia as fontes em formato HiTeX. O projecto seguiu as seguintes fases:
213
Anlise documental da obra e especicao do DTD. Eliminao das anotaes HiTeX redundantes (lixo de formatao) - com o objectivo de facilitar o processamento seguinte. Especicao dos ltros para realizar a converso HiTeX DTD criado. Especicao dos ltros para realizar a converso SGML HTML, e gerao dos respectivos ndices (geral, antroponmico e toponmico).
Uma vez que a mo-de-obra era de alunos havia preocupaes pedaggicas na realizao do projecto. Foi por isso que no se utilizou um DTD existente e se desenvolveu um novo. A ideia era a de que os alunos cobrissem, o mais possvel, todo o ciclo de desenvolvimento. No entanto, com o DTD e o documento anotado sempre possvel realizar a transformao do documento anotado noutro documento que respeite um novo DTD escolhido. Para a construo dos ltros e conversores usaram-se duas bibliotecas Perl desenvolvidas para processar documentos SGML: SGMLS.pm e NSGMLS.pl. Foi neste projecto que surgiu o primeiro problema de normalizao. Havia que construir uma srie de ndices para permitir uma "navegao"inteligente no documento. No caso dos ndices toponmico e antroponmico (haviam sido preparados mo por historiadores), existiam muitos casos em que o nome no ndice era diferente do nome no documento (o nome no ndice seria o mais conhecido para o personagem em causa). Para estes casos aplicou-se a soluo de normalizao apresentada na Seco 7.1.2. Os resultados visveis deste projecto encontram-se disponveis no site da Internet do Arquivo Distrital de Braga: http://www.adb.pt.
B.1.2. Publicao na Internet do "Index das Gavetas do Cabido da S de Braga"

Este projecto foi desenvolvido pela mesma equipe do projecto anterior e a estratgia foi semelhante. Os problemas encontrados foram os mesmos e as solues seguidas tambm. De momento, os resultados no se encontram disponveis na Internet por que uma breve exposio permitiu detectar uma srie de erros pelo que, os documentos esto em reviso.
214
B.1.3. Publicao na Internet do Livro "Ensaio Sobre as Minas de Joze Anastacio da Cunha"
Este projecto desenvolveu-se ao mesmo tempo que os outros dois. As metodologias aplicadas foram as mesmas. Surgiu no entanto um problema diferente: a matemtica. Joze Anastacio da Cunha foi um famoso engenheiro portugus que era muito requisitado para gerir a escavao de minas. Tambm era um bom construtor de armas e foram estas duas valncias que o chamaram s cortes dos reis de Frana. Um dos documentos escritos por ele este livro que acaba por ser um manual para a escavao de minas. Por isso e devido formao do autor, o livro apresenta diversas frmulas matemticas de complexidade variada, num total de 208. Era aqui que residia o problema. A colocao da matemtica no papel um problema que vem apaixonando pessoas da rea da computao h algum tempo. A matemtica no segue uma ordem linear como o texto, mas sim uma distribuio espacial a duas dimenses. Em SGML, o problema ainda no foi inteiramente resolvido. H, no entanto, algum consenso na utilizao da linguagem de anotao MathML para a representao da matemtica. O MathML um DTD denido a partir do TeX (o TeX ainda o sistema de processamento que melhor trata a matemtica), a sintaxe a do SGML, os comandos so os que j existiam no TeX. Tendo as frmulas devidamente codicadas em MathML surgia agora o problema de como produzir um resultado nal para dispobilizar na Internet (lembrar que o HTML tambm no tem capacidades para representar matemtica). Na altura, devido a uma deslocao a uma conferncia de SGML estabeleceu-se contacto com o grupo "alphaworks"da IBM. Eles estavam a desenvolver um "plug-in"para o Netscape, designado por Techexplorer, que permitia que, no meio duma pgina HTML, surgissem frmulas matemticas anotadas segundo o MathML. O Techexplorer desenhava a imagem correcta da frmula em tempo de execuo na janela do browser. Adoptou-se ento esta soluo. Instalou-se o Techexplorer nas mquinas que deveriam ser usadas para visionar o livro e no tratamento de contedos usou-se MathML para a codicao das frmulas matemticas. Apesar de tudo e uma vez que estvamos perante a verso inicial do Techexplorer s foi possvel tratar 200 das 208 frmulas. Motivo pelo qual o livro ainda no est
215
disponvel na Internet. Actualmente, j existe uma nova verso do Techexplorer bastante mais evoluda e, nos prximos tempos, tentar-se- de novo ver se as restantes frmulas se podem tratar.
B.2. Recuperao de edies esgotadas

Como j se disse, a diferena principal entre os projectos que a seguir se descre vem e os prximos, foi o ponto de partida. Nos projectos anteriores, tnhamos os documentos num formato e suporte digital. Nos que se apresentam a seguir apenas se possua o documento em papel. Tratavam-se de documentos com idade anterior informatizao do Arquivo pelo que haviam sido dactilografados. Mais grave ainda foi terem-se deixado esgotar os volumes ento editados sem os reeditar ou mesmo convert-los num formato digital. O ponto de partido foi portanto, uma verso fotocopiada do documento original.
B.2.1. Recuperao do livro "ndice da gaveta das Cartas"

Este projecto teve como nalidade recuperar e reproduzir para vrios formatos electrnicos um livro que j no editado e se encontra esgotado, de nome "Inventrio das Cartas do Cabido de Braga", existente no Arquivo Distrital de Braga. As etapas que constituram o projecto foram:

Anlise documental e elaborao dum DTD para o documento em causa. Digitalizao das pginas, recorrendo a um scanner. Converso da imagem digitalizada em texto: para o efeito utilizou-se um software de OCR ("Online Character Recognition") que permitia, entre outros, converter a imagem num documento no formato RTF, que foi o escolhido. Converso RTF XML: foi necessrio recorrer a um ltro desenvolvido em Omnimark por Rick Geimer para realizar esta converso; depois de congurado,
216
o ltro permitiu a passagem do documento para um XML bastante pobre (a estrutura era basicamente constituda por pargrafos que tinham, porm, dois atributos, estilo e tamanho de letra, com os quais se conseguia determinar uma estrutura mais rica).
Converso XML XML: coverso para o formato XML que est de acordo com o DTD denido na fase de anlise (esta converso s foi possvel graas queles dois atributos; testando as combinaes dos seus dois valores foi possvel reconstruir uma estrutura com captulos, seces, subseces e pargrafos); o conversor foi desenvolvido em Omnimark. Anotao manual dos elementos pertencentes aos ndices: para os elementos constantes nos ndices, nomes de pessoas e lugares, foi necessrio anotar o documento caso a caso, usou-se para o efeito o XMetal. Desenvolvimento dos conversores para as verses HTML e LaTeX (impresso em papel): utilizou-se de novo o Omnimark para o desenvolvimento destes conversores.
Os resultados deste projecto encontram-se no Arquivo. A verso HTML encontra-se j disponvel na Internet: http://www.adb.pt.
B.2.2. Recuperao do livro "Inventrio da gaveta das Visitas e Devassas"

Este projecto teve como nalidade recuperar e reproduzir para vrios formatos electrnicos um livro que j no editado e se encontra esgotado, de nome "Inventrio da gaveta das Visitas e Devassas", existente no Arquivo Distrital de Braga. Este projecto seguiu a mesma linha de aco do anterior pelo que caremos por aqui na sua descrio. Relativamente aos resultados, o livro ainda no se encontra disponvel porque a equipe que trabalhou no projecto ao anotar os elementos dos ndices deparou com muitas incorreces semnticas o que motivou uma grande reviso dos contedos do livro que est a ser realizada pelos autores do livro. No entanto, o Arquivo est em posse de tudo o que necessrio para introduzir as correces no documento XML nal e gerar automaticamente as verses de distribuio.
217
B.3. Outros Projectos

O autor tem vindo a ser solicitado para trabalhar nalguns projectos reais s vezes como consultor. Num desses contactos, surgiu o convite para integrar, juntamente com o supervisor, uma equipe do INESC que tem um projecto com o objectivo de elaborar uma proposta para o MPEG7 (espera-se que seja o formato de vdeo num futuro prximo). Neste projecto, a responsabilidade do autor tem sido o desenvolvimento duma linguagem de anotao para a descrio de contedos: vdeo, imagem e texto. O projecto teve oramento do PRAXIS durante um ano para se melhorar e aprofundar as ideias iniciais pelo que, ir ser submetido de novo na prxima candidatura.
218
Apndice C. Converso de DTDs para Gramticas

Um dos contributos desta tese foi a sistematizao da converso de um DTD SGML para uma Gramtica de Atributos. A primeira aproximao a esta sistematizao foi feita na tese de mestrado de Alda Lopes [Lop98]. A verso de ento revelou-se insuciente e com algumas lacunas quando aplicada aos casos de estudo. Houve, portanto, necessidade de renar aquele primeiro estudo e proceder correco de vrios problemas e a uma maior generalizao do conjunto de regras de converso. O resultado nal apresenta-se neste apndice e deve ser interpretado como um manual de instrues para a realizao ou implementao duma converso. Algumas destas regras podem parecer simples e so-no, mas h algumas que no o so. A ideia deste estudo a de ser a primeira verso duma especicao formal da converso de DTDs em Gramticas. O leitor atento perceber tambm facilmente que este estudo d uma viso interior do SGML ajudando a perceber o porqu de certas caractersticas e a sua semntica. As regras apresentadas encontram-se agrupadas por classes correspondendo cada classe a uma seco. Assim temos um conjunto de regras gerais, que sero aplicadas a todas as declaraes. Depois temos dois grupos de regras um para aplicar s declaraes de elementos e outro para aplicar s declaraes de atributos. A converso da declarao dum elemento num conjunto de produes um processo de clculo recursivo: a expresso de contedo de um elemento pode ser composta por vrias subexpresses aninhadas e s quais esto aplicados vrios operadores com diferentes prioridades; o agrupamento e a prioridade dos operadores tem que ser captado na gramtica. Este problema semelhante ao do clculo duma expresso aritmtica onde preciso ter em conta a precedncia e a associatividade dos operadores pelo que a soluo implementada anda muito prxima da dum calculador de expresses matemticas s que o clculo o de uma gramtica de atributos. No que se segue, seja Conv() a funo correspondente aplicao recursiva das regras enunciadas.
219
C.1. Regras gerais

As regras gerais so as mais simples e as que devero mais utilizadas.
C.1.1. Elemento genrico

Seja elem um elemento declarado no DTD, e Content a expresso de contedo que o dene:
<!ELEMENT elem Content>
Independentemente de ter atributos associados ou no, a correspondente produo gramatical :

elem elemAttList elemContent
onde elemContent o smbolo no-terminal que representa todo o seu contedo e elemAttList o smbolo no-terminal correspondente declarao da lista de atributos de elem.
C.1.2. Elemento sem atributos

Se elem no tiver nenhum atributo declarado, elemAttList deriva na produo vazia:
elemAttList
Esta a situao inicial pois primeiro surge a declarao do elemento e s mais tarde,no DTD, surge a declarao dos atributos daquele elemento. Nessa altura, esta produo reescrita de acordo com a regra aplicada e que tem a ver com o tipo de atributo.
Exemplo C-1. Elemento Titulo sem atributos

Title TitleAttList TitleContent TitleAttList
220
C.1.3. Elemento com contedo #PCDATA

Se o contedo dum elemento fr atmico, do tipo #PCDATA, elemContent ter a seguinte derivao:
elemContent textList textList text textList | text STR
Esta regra assim apenas inicialmente. H situaes que iro provocar a sua reescrita (para completar as alternativas de text), como a incluso de seces marcadas ou a denio de entidades no DTD (ver Seco C.4).
Exemplo C-2. Elemento com contedo #PCDATA O contedo do elemento Begin-date est denido como #PCDATA no DTD do servio noticioso, o que faz com que este seja derivvel nas seguintes produes:
Begin-date Begin-dateAttList Begin-dateContent Begin-dateContent textList textList text textList | text str
C.1.4. Elemento denido como um grupo - ()
221
Quando o contedo do elemento em denio no atmico, #PCDATA, denido por um grupo de elementos (um ou mais entre parentesis). Nesse caso, o conjunto de produes em que deriva o contedo :
elemContent GrupoX GrupoX Conv(elemContent)
Em que GrupoX um smbolo no-terminal introduzido pela regra e cujo nome formado pela string "Grupo" concatenada com o valor dum contador interno X que logo incrementado. s vezes, os grupos so singulares, elemContent constitudo apenas por um elemento. Neste caso, esta regra poder ser abreviada fundindo as duas produes apresentadas.
C.2. Converso de declaraes de elementos

Se o contedo do elemento que se est a derivar fr estruturado vai ser necessrio analisar a estrutura desse contedo antes de se fazer a converso. Primeiro, preciso determinar o operador de ocorrncia: zerone para zero ou uma ocorrncias (operador ? do SGML); zeron para zero ou mais ocorrncias (operador * do SGML); e onen para uma ou mais ocorrncias (operador + do SGML). Se este no existir, passamos de imediato ao passo seguinte. A seguir, analisa-se o operador de conexo: sequencial (seq) - os subelementos devero aparecer todos pela ordem indicada; alternativa (or) - s um dos sublementos dever aparecer. Esta anlise a dois passos vai-se repetir recursivamente para os sublementos at elementos atmicos serem atingidos (#PCDATA).
C.2.1. Elemento com estrutura singular
222
Se o a expresso de contedo fr formada por apenas um elemento (elem). A respectiva regra de derivao :
elemContent elem
C.2.2. Operador de ocorrncia zerone

No caso do sistema noticioso tnhamos:
<!ELEMENT News - - (Title, Begin-date, End-date?, Body?)>
O elemento Body pode aparecer zero ou uma vezes no contedo do elemento News, assim como o elemento End-date. Poderamos tratar esta situao na gramtica ao nvel das derivaes de News:
News NewsAttList NewsContent NewsContent Grupo1 Grupo1 Title Begin-date End-date Body | Title Begin-date End-date | Title Begin-date Body | Title Begin-date
Desta maneira, temos de trabalhar com permutaes, o que torna o processo muito complicado. A situao simplica-se introduzindo um smbolo no-terminal para cada elemento (ou grupo de elementos numa sub-expresso de contedo) que tiver um operador de ocorrncia a ele aplicado. Assim, sempre que uma sub-expresso (SubExp) fr afectada de um operador de ocorrncia ?:
SubExp = A?
essa sub-expresso ser denotada por um smbolo no-terminal de nome GrupoX_01, cujas produes para a sua derivao so:
GrupoX_01 GrupoX |
223
GrupoX Conv(A)
Onde, GrupoX_01 corresponde subexpresso inicial A?, e GrupoX o smbolo no-terminal que ir derivar a subexpresso que est afectado pelo indicador de ocorrncia (para a derivao de sub-expresses convencionou-se que os nomes dos smbolos no-terminais seriam formados pela palavra Grupo seguida do valor dum contador interno, que incrementado cada vez que se gera um novo nome, seguidos dum indicador do operador de ocorrncia: 01,0n, ou 1n). Neste ponto, o processo de converso aplicar-se-ia recursivamente sub-expresso A, como se pode observar pela ltima produo. Voltando ao nosso exemplo, a derivao de News ser:
News NewsAttList NewsContent NewsContent Title Begin-date Grupo1_01 Grupo2_01 Grupo1_01 Grupo1 | Grupo1 End-date End-date End-dateArrList End-dateContent Grupo2_01 Grupo2 | Grupo2 Body Body BodyAttList BodyContent
C.2.3. Operador de ocorrncia zeron

Novamente do caso do sistema noticioso, podemos extrair outro exemplo para ilustrar esta regra (vamos alter-lo ligeiramente e supr que Body composto por zero ou mais pargrafos):
224
<!ELEMENT Body - - (Para)*>
Aqui, o operador de ocorrncia implica iterao o que vai traduzir em recursividade na gramtica. Assim, sempre que uma sub-expresso (SubExp) fr afectada de um operador de ocorrncia *:
SubExp = A*
essa sub-expresso ser denotada por um smbolo no-terminal de nome GrupoX_0n, que deriva segundo as produes:
GrupoX_0n GrupoX | GrupoX Conv(A) GrupoX_0n
A converso da denio do elemento Body corresponde ento ao conjunto seguinte de produes:

Body Grupo3_0n Grupo3_0n Grupo3 Grupo3_0n | Grupo3 Para
C.2.4. Operador de ocorrncia onen

Vamos usar o exemplo da regra anterior substituindo apenas o operador de ocorrncia:
<!ELEMENT Body - - (Para)+>
A situao tratada de forma idntica da regra anterior, sendo neste caso a sub-expresso A+ denotada pelo smbolo no-terminal GrupoX_1n que no pode derivar em vazio:
225
GrupoX_1n GrupoX | GrupoX GrupoX Conv(A)
GrupoX_1n
Donde, para o exemplo em causa se ter:

Body Grupo3_1n Grupo3_1n Grupo3 Grupo3_1n | Grupo3 Grupo3 Para
Como foi dito, depois da anlise do operador de ocorrncia faz-se a anlise do operador de conexo que pode ser seq ou or; sejam, op1, ..., opn, os elementos (operandos) abrangidos por um desses operadores. Duas situaes podero ocorrer. As regras seguintes foram criadas para tratar estas situaes.
C.2.5. Operador de conexo seq (sequncia)

Os operandos duma sequncia tm que ser derivados na ordem em que se encontram na sequncia. Assim, fcil ver que a produo correspondente :
elemContent Conv(op1) ... Conv(opn)
Exemplo C-3. Operador de conexo seq Como j visto no nosso sistema noticioso, o elemento News composto por uma sequncia de elementos, o que d origem seguinte produo:
NewsContent Title Begin-date Grupo_01 Grupo_02
226
C.2.6. Operador de conexo or (alternativa)

Os seus operandos so alternativas, assim s um corresponder ao contedo do elemento. As produes correspondentes sero:
elemContent Conv(op1) | ... | Conv(opn)
C.3. Regras para os atributos

Cada um dos atributos no DTD vai corresponder a um smbolo no-terminal na gramtica de atributos. O SGML permite denir atributos de vrios tipos. Apresenta-se, primeiro, uma regra geral que dever ser aplicada sempre, independentemente do tipo do atributo, e a seguir, as regras que permitem converter os tipos mais usuais de atributos.
C.3.1. Elemento com atributos

Se elem tem atributos, sejam eles att1, ..., attn. A sua declarao no DTD seria:
<!ATTLIST elem att1 att1-type att1-def-value ... attn attn-type attn-def-value>
A produo principal correspondente regra geral, :

elemAttList Att1 ... Attn
onde Atti o smbolo no-terminal introduzido para representar o atributo atti. att1-type, ..., attn-type representam o tipo de cada um dos atributos: enumerado, CDATA, NUMERICAL, ID, IDREF, IDREFS, ENTITY, e outros que j no se
227
utilizam. Na declarao de um atributo tambm podemos associar-lhe um valor por omisso, representado acima por atti-def-value, que deve ser tido em conta sempre que o atributo no fr instanciado pelo utilizador. Os valores possveis para este so os denidos na tabela abaixo: #FIXED seguido de uma string, o que signica que se o atributo fr instanciado ter que ser com um valor igual a string; um dos valores pertencentes a um tipo enumerado denido para esse atributo; ou uma das palavras-chave seguintes: Tabela C-1. Valores por omisso de Atributos #IMPLIED #REQUIRED #FIXED o valor poder no ser instanciado, o atributo opcional. o utilizador ter obrigatoriamente que instanciar o atributo, este obrigatrio o valor do atributo tem que aparecer a seguir palavra-chave (ver Seco 7.1, Exemplo 7-3) signicando que se o atributo fr instanciado ter que ser com um valor igual ao declarado, caso no seja instanciado o sistema assumir esse valor. o valor do atributo herdado da ltima instncia do mesmo elemento onde o valor do atributo foi instanciado (segue-se a ordem ascendente na rvore de elementos) o valor usado para referncias externas (cada vez menos utilizado, no ir ser considerado nas regras que se seguem) um dos valores pertencentes ao tipo enumerado denido para esse atributo.
#CURRENT
#CONREF
valor dum tipo enumerado
O valor por omisso levanta-nos um problema: no possvel deriv-lo da gramtica, ou seja, o comportamento deste item essencialmente semntico - "se o atributo no estiver instanciado, ento use-se este valor". Como tal, iremos recorrer
228
a equaes sobre atributos (da gramtica de atributos) para o modelar, como se poder ver nas regras seguintes. As restantes produes de cada um dos atributos dependem dos seus tipos e valores por omisso. Sero tratadas nas regras que se seguem.
Exemplo C-4. Elemento News com atributos No nosso caso de estudo do servio noticioso, o elemento News tinha dois atributos: Type e Subject. Assim, as produes correspondentes so:
News NewsAttList NewsContent NewsAttList Type Subject
O contedo do elemento pode ser estruturado ou texto.
C.3.2. Atributo do tipo enumerado

Se um atributo att do elemento X fr declarado da seguinte maneira:
<!ATTLIST X att (att-val1 | ... | att-valn) att-vali>
do tipo enumerado: o seu tipo est denido como a lista att-val1, ..., att-valn,, e o seu valor por omisso att-vali com 0<i<n. As produes correspondentes so:
att att-val1 | ... | att-valn |
Os smbolos att-val1, ..., att-valn so smbolos terminais da gramtica, correspondem a tokens/palavras-chave xos; corresponde string vazia e esta derivao corresponde inexistncia do atributo na instncia documental (a situao em que o utilizador no instancia o atributo), e onde dever ser assumido, portanto, o valor por omisso.
229
Assim as produes anteriores tm de ser enriquecidas com as seguintes equaes sobre o atributo gramatical valor, que ir guardar o valor do atributo SGML att:
att att-val1 valor = f(att-val1) | ... ... | att-valn valor = f(att-valn) | valor = f(att-vali)
Aqui e no resto das regras, a funo f representa a converso de tipos necessria para passar o valor devolvido pelo analisador lxico (tipo=string) para o valor pretendido no atributo semntico.
Exemplo C-5. Atributo do tipo enumerado No nosso sistema noticioso, o elemento News tem um atributo de nome Type do tipo enumerado, com valores Event ou Novelty, o que d origem s seguintes produes:
Type event valor = "Event" | novelty valor = "Novelty"
C.3.3. Atributo do tipo CDATA

Se um atributo fr do tipo CDATA, signica que tem um contedo textual, e a produo correspondente :
att str valor = f(str)
230
O smbolo str um smbolo terminal da gramtica resultante.
C.3.4. Atributo do tipo NUMERICAL

Se um atributo fr do tipo NUMERICAL, signica que tem um contedo numrico e a produo correspondente :
att number valor = f(number)
O smbolo number um smbolo terminal da gramtica resultante.
C.3.5. Atributo do tipo ID

Se um atributo fr do tipo ID, signica que tem um contedo textual e uma semntica associada: o valor do atributo, instanciado pelo utilizador, tem que ser nico, i.e., no pode haver no documento mais nenhum atributo deste tipo instanciado com o mesmo valor. A produo e semntica correspondentes so:
att ident if( exists(ident, Tabid) ) erro = "Identificador j existente!" else insert(ident, Tabid) valor = f(ident)
C.3.6. Atributo do tipo IDREF

Se um atributo fr do tipo IDREF, signica que tem um contedo textual e uma semntica associada, que o inverso da situao anterior: o valor do atributo, instanciado pelo utilizador, tem que existir na tabela de identicadores, tem que estar declarado num atributo do tipo ID algures no documento. A produo e a semntica correspondentes denem-se como:
att ident if( !exists(ident, Tabid) ) erro = "Identificador inexistente!"
231
valor = f(ident)
C.3.7. Atributo do tipo ENTITY

Se um atributo fr do tipo ENTITY, signica que tem um contedo textual e uma semntica associada: o valor do atributo, instanciado pelo utilizador, tem que ser o identicador de uma entidade existente na tabela de entidades, tem que estar declarado numa declarao de entidade no DTD (Seco C.4). A produo e a semntica correspondentes denem-se como:
att ent-ident if( !exists(ent-ident, Tab-entidade) ) erro = "Entidade inexistente!" valor = f(ent-ident)
C.3.8. Atributo denido com o valor #IMPLIED

Se um atributo fr denido com o valor por omisso #IMPLIED, signica que opcional, e as produes correspondentes so:
att att-val |
A derivao pela string vazia acresce a uma das converses anteriores dependendo do tipo. A produo att att-val representa a produo resultante da converso do tipo de atributo; ao juntarmos a converso do valor por omisso vamos acrescentar produes derivao de att e, nalguns casos, alguns atributos e respectivas equaes de clculo.
C.3.9. Atributo denido com o valor #REQUIRED

Se um atributo fr denido com o valor por omisso #REQUIRED, signica que obrigatrio, e as produes correspondentes so:
att att-val
232
| erro = "Atributo obrigatrio!"
A derivao pela string vazia acresce a uma das converses anteriores dependendo do tipo.
C.3.10. Atributo denido com o valor #FIXED

Se um atributo fr denido com o valor por omisso #FIXED, signica que o seu valor foi xo na declarao. O utilizador poder sempre instanci-lo mas o valor ter que ser igual ao fornecido na declarao do atributo no DTD. As produes e a semntica correspondentes denem-se como:
att att-val if(f(att-val) != Tab-attr(att).valor) erro = "O valor do atributo no o esperado!" valor = Tab-attr(att).valor | valor = Tab-attr(att).valor
A derivao pela string vazia e as condies de contexto acrescem a uma das converses anteriores dependendo do tipo.
C.3.11. Atributo denido com o valor #CURRENT

Este valor por omisso s se utiliza para atributos pertencentes a elementos que podem aninhar-se. Por exemplo, um documento pode construir a sua hierarquia de seces e subseces custa de apenas um elemento seco ao qual, no DTD, se deu permisso para aninhar recursivamente. Assim, uma seco que ocorra dentro de outra seco uma subseco daquela ou uma seco de nvel dois. Este tipo de elementos tem, normalmente, atributos, que se forem declarados com o valor por omisso #CURRENT no precisam de estar instanciados, nesse caso, o atributo herdar o seu valor da ltima instanciao desse atributo percorrendo os elementos de baixo para cima at encontrar um que o tenha instanciado.
233
As produes e a semntica correspondentes denem-se como:

att att-val valor = f(att-val) | valor = Procura(att, ASAD)
A funo Procura vai tentar calcular o valor do atributo percorrendo a rvore de sintaxe abstracta decorada calculada at ao momento, em ordem ascendente. A derivao pela string vazia e as condies de contexto acrescem a uma das converses anteriores dependendo do tipo.
C.4. Regras de converso para entidades

Sempre que uma entidade declarada no DTD, o utilizador pode utiliz-la no texto (como uma abreviatura ou incluso de uma imagem, por exemplo). Portanto quando uma ou mais entidades estiverem denidas no DTD os elementos de contedo textual passam a poder ter um contedo misto (texto onde, em qualquer lugar, podem aparecer referncias a entidades).
C.4.1. Entidades
Sejam ent1, ..., entn, entidades denidas no DTD. Ento, todos os elementos de contedo textual tero de permitir referncias a qualquer uma daquelas entidades no seu contedo. Por conseguinte, a regra apresentada em Seco C.1.3 para contedos do tipo #PCDATA teria de ser completada da seguinte maneira:
elemContent textList textList text textList | text str
234
| ent1 | ... | entn
Termina aqui a lista de regras de converso. Estas regras encontram-se implementadas no sistema S4, descrito em detalhe num dos ltimos captulos (Seco 9.2).
C.5. Uma converso passo a passo

No captulo onde se discutiu a semntica dinmica (Captulo 6), foi introduzido um documento SGML que continha o seguinte DTD.
<!DOCTYPE <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ATTLIST ]> RECEITAS [ RECEITAS (TITULO,RECEITA*)> TITULO (#PCDATA)> RECEITA (TITULO,INGREDIENTE+)> INGREDIENTE (#PCDATA)> RECEITA ORIGEM CDATA #IMPLIED>
Agora, vamos seguir a sua converso numa gramtica de atributos, passo a passo, atravs da aplicao sistemtica das regras denidas ao DTD:
Exemplo C-6. Uma converso: DTD GA Para cada declarao do DTD apresentam-se as produes geradas sistematicamente: Receitas (Titulo,Receita*)
Receitas ReceitasAttList ReceitasContent ReceitasAttList
235
ReceitasContent Grupo1 Grupo1 Titulo Grupo2_0n Grupo2_0n | Grupo2 Grupo2_0n Grupo2 Receita
Titulo (#PCDATA)
Titulo TituloAttList TituloContent TituloAttList TituloContent textList textList text textList | text str
Receita (Titulo,Ingredente+)
Receita ReceitaAttList ReceitaContent ReceitaAttList ReceitaContent Titulo Grupo3_1n Grupo3_1n Grupo3 | Grupo3 Grupo3_1n Grupo3 Ingrediente
Ingrediente (#PCDATA)
Ingrediente IngredienteAttList IngredienteContent
236
IngredienteAttList IngredienteContent textList
ATTLIST RECEITA ORIGEM CDATA #IMPLIED

ReceitaAttList Origem Origem str |
Com este exemplo, ca concludo este apndice sobre a converso de DTDs em Gramticas de Atributos.
237
Apndice D. Futuros standards relacionados com SGML

Desde o incio desta tese j se passaram quatro anos. E foram quatro anos bem efervescentes. A indstria de software acordou para o SGML e para os standards relacionados com a estruturao de contedos (normalmente, para a internet). Nos ltimos dois anos, tem havido uma exploso de ideias, os interesses multiplicaram-se bem como as pessoas neles envolvidas. Este apndice surge, ao terminar a escrita da dissertao, para fazer o ponto da situao actual. Ser fcil concluir que, apesar da proliferao de ideias e de propostas para novos standards, os conceitos so os mesmos, a losoa SGML est l: formato neutro, estruturao de contedos, independncia relativamente apresentao. A lista de especicaes SGML bem como o nmero de propostas de novos standards submetidas ao W3C enorme. Aqui, vamos focar as mais relevantes e aqueles para as quais se prev um maior impacto e desenvolvimento, que andam indubitavelmente a gravitar em torno do XML As especicaes que se descrevem esto ainda em diferentes estgios de desenvolvimento (na sua maioria anda inacabadas), podem, por isso, ser alteradas. Isto no implica que no estejam a ser utilizadas; muito pelo contrrio, h especicaes ainda no primeiro nvel de desenvolvimento j implementadas. Actualmente, o W3C considera quatro nveis de desenvolvimento para as propostas de normalizao que lhe so submetidas. Apresenta-se a seguir uma lista dos nveis de desenvolvimento e correspondentes especicaes. Recomendao Signica que a especicao est estvel, contribui para uma evoluo da tecnologia e suportada pelos membros do W3C que apoiam a sua aplicao.

Extensible Markup Language (XML) 1.0 Document Object Model (DOM) Level 1 Cascading Style Sheets Level 1 (CSS1)
238
Cascading Style Sheets Level 2 (CSS2) NameSpaces in XML (XML Namespace)
Recomendao Proposta Signica que a especicao est a ser revista pelos membros do W3C.
Neste momento no h nenhuma relacionada com o XML.
Rascunho Signica que a especicao pode ser alterada em qualquer altura, substituda ou simplesmente posta de lado; este tipo de material no deve ser usado como referncia podendo, no entanto, ser citado como "trabalho em desenvolvimento".

Extensible Stylesheet Language (XSL) XML Linking Language (XLL) XML Pointer Language (XPointer)
Notas Signica que se trata de uma especicao submetida ao W3C pelo pblico, ou por algum membro; no foi submetida num "Call for proposals"; por ter interesse ou qualidade publicada e mantida para discusso.

XML Query Language (XQL) XML Data (XML-Data) Schema for Object-oriented XML (SOX) Vector Markup Language (VML) Simplied Markup Language (SML)
No tabela seguinte, sintetiza-se o domnio de aco das propostas mais relevantes:
239
Tabela D-1. Domnios de aco Especicao SGML XML SML Estilo DSSSL XSL CSS1 CSS2 A utilizao combinada das vrias linguagens possvel: pode-se montar um sistema escolhendo uma proposta de cada categoria tendo o cuidado de vericar se se est a escolher a mais adequada ao m em causa. O XML representa a linguagem de anotao mais verstil podendo combinar-se com qualquer uma das outras categorias. O SGML tambm se poder combinar com algumas das outras (com o DSSSL o mais usual) mas com algumas adaptaes. O SML, de momento no passa de uma ideia, de certa maneira retrgada, como iremos ver mais frente. Algumas destas propostas so explicadas a seguir. Transformao DOM XSL SOX Seleco XQL XLL XPointer
D.1. Extensible Markup Language (XML) 1.0

E ento surgiu o XML... E surge a pergunta: porqu XML e no SGML? Sim, porque o XML apresentado como um subconjunto do SGML. partida parece que se vai perder algo adoptando um e no o outro. A resposta encontra-se na histria e desenvolvimento da informtica. O SGML surgiu j h mais de 10 anos e teve de conviver com os condicionalismos da poca o que se traduz actualmente num pequeno subconjunto de caractersticas que deixaram de fazer sentido e que apenas atrapalham. A linguagem de anotao XML foi denida pelo W3C [http://www.w3c.org], para a produo de contedos estruturados para a Internet. As prximas seces daro resposta questo que ca agora no ar: Porqu mais um standard para a Internet?
D.1.1. O Passado
240
O XML no mais do que um subconjunto do SGML (Captulo 4). O SGML e o XML so mais do que linguagens de anotao, so meta-linguagens; permitem a denio de novas linguagens. Por outro lado, o HTML, a linguagem de anotao mais conhecida para a produo de pginas para a Internet, est denida em SGML. uma linguagem concreta, no possvel estend-la a no ser que se altere a sua denio inicial (o que a transformaria noutra linguagem). O XML no tem esta limitao. Sendo uma meta-linguagem, permite em qualquer momento o acrescentar de novos elementos linguagem. Na prtica, isto traduz-se numa linguagem aberta que nos permite especicar qualquer coisa com o nvel de detalhe que pretendermos. Neste momento, o HTML continua a ser a linguagem mais utilizada na Internet mas, ir ser gradualmente substitudo pelo XML.
D.1.2. Porqu XML?

O crescimento espantoso da Internet, nomeadamente do servio WWW, nos ltimos anos, um facto que se deve principalmente possibilidade de distribuir, facilmente e a baixos custos, informao e aplicaes, a qualquer utilizador, em qualquer parte do mundo. medida que a informao que se coloca na Internet se vai tornando cada vez mais complexa, e o nmero de utilizadores vai crescendo, as limitaes das tecnologias e standards actuais vo-se tornando cada vez mais evidentes. A limitao na construo de pginas WWW deve-se principalmente ao facto do HTML possuir apenas um conjunto xo e pr-denido de etiquetas com o qual se pode denir a estrutura e a aparncia duma pgina WWW. Foi esta limitao, e a impossibilidade de de criar extenses linguagem que tornou a criao dum novo standard desejvel. Nalgumas aplicaes, principalmente onde uma publicao electrnica de alta qualidade e desempenho o objectivo a atingir, tem-se vindo a adoptar o SGML para a produo e manuteno de contedos; as pginas WWW so depois geradas automaticamente, partindo destes contedos. No entanto, o SGML complexo e de difcil aprendizagem o que far com que seja apenas utilizado por comunidades que possuam um elevado nvel tcnico, e portanto, no tenha uma grande aceitao por parte dos utilizadores normais. Nos ltimos tempos, as aplicaes distribudas em geral, vieram realar a falta dum standard para a transferncia de dados estruturados. Apesar dos esforos e do
241
dinheiro investido esse standard no surgiu. Os problemas surgem quando diferentes aplices querem interagir; normalmente, cada uma tem o seu prprio formato para comunicar dados que diferente do da outra. Para resolver estes problemas, foi criado o XML. O XML oferece um mtodo estruturado e consistente para descrever e transferir informao. A melhor caracterstica que possui, herdada do SGML, a separao do formato visual da informao propriamente dita. Isto faz com que o XML seja a linguagem ideal para a produo de contedos textuais (inependncia de plataformas de hardware e software, longevidade, ...). Duas aplicaes XML podem enviar e receber informao livremente sem preocupaes com o formato dessa informao, a informao contida num documento XML auto-descreve-se. O XML foi concebido tendo uma srie de objectivos em vista:
Deve ser directamente utilisvel na Internet - os utilisadores devem ser capazes de ver pginas XML da mesma maneira que vem pginas HTML. Deve suportar uma srie de aplicaes: editores, browsers, sistemas de gesto de bases de dados, ... No entanto, o principal objectivo a produo de contedos estruturados para a Internet. Deve ser compatvel com o SGML - j existem muitos contedos em SGML e para quem os produziu a compatibilidade entre os dois crtica. A escrita de programas para processar documentos XML deve ser simples. O nmero de catactersticas opcionais deve ser reduzido a um mnimo, pois quantas mais houver mais problemas de compatibilidade podero surgir.
D.1.3. XML: caractersticas

Como j foi dito, o XML acaba por ser um subconjunto do SGML. Uma vez que o SGML j foi detalhadamente descrito nesta tese, podemos descrever o XML enunciando quais as caractersticas do SGML que foram deixadas de fora. Assim, vamos ter simplicaes ao nvel das declaraes no DTD e da funcionalidade esperada. Ao nvel do DTD foram retiradas as seguintes caractersticas:
242
Incluses e excluses. O operador &. Ao nvel de entidades apenas podemos ter um nvel de indireccionamento. As entidades do tipo caracter no fazem parte de nenhuma distribuio uma vez que foi adoptado o Unicode como conjunto de caracteres base [Unicode].
A diferena mais marcante entre o SGML e o XML a importncia dada validao do documento com o DTD, como se pode ver na prxima seco.
D.1.3.1. Vlido versus Bem-Estruturado

Numa linguagem, qualquer que ela seja, precisamos de ter uma entidade que verique se um dado documento escrito nessa linguagem est de acordo com a gramtica e especicaes dessa linguagem. No nosso caso, o DTD corresponde gramtica e o parser ao vericador. No entanto, o XML foi pensado para suportar aplicaes "Web"e, em muitos casos, o DTD e as respectivas vericaes podem tornar-se um fardo bem pesado. Ento criaram-se dois patamares de validao: o documento vlido e o documento bem-formado. Um documento diz-se vlido se tiver um DTD associado e se o texto do documento est de acordo com as especicaes no DTD; um documento diz-se bem-formado se obedecer s seguintes condies:

Tiver um ou mais elementos. H apenas um elemento (o elemento raz) para o qual nem a anotao de incio nem a anotao de m esto dentro de qualquer outro elemento. Todas as outras anotaes tm que estar aninhadas correctamente. Todas as entidades usadas no documento tm de estar denidas em XML ou no DTD.
Podemos ver agora dois exemplos: o primeiro dum documento bem estruturado e o segundo do mesmo documento mas agora com o DTD associado ilustrando o conceito de documento vlido.
243
Exemplo D-1. Um documento bem estruturado

<RECEITAS> <TITULO> O Meu Livro de Receitas </TITULO> <RECEITA ORIGEM="Portugal <TITULO> Bolo </TITULO> <INGREDIENTE> 500g de farinha </INGREDIENTE> <INGREDIENTE> 200g de aucar </INGREDIENTE> <INGREDIENTE> 300g de manteiga </INGREDIENTE> </RECEITA> </RECEITAS>
Exemplo D-2. Um documento vlido

<!DOCTYPE RECEITAS [ <!ELEMENT RECEITAS (TITULO,RECEITA*)> <!ELEMENT TITULO (#PCDATA)> <!ELEMENT RECEITA (TITULO,INGREDIENTE*)> <!ELEMENT INGREDIENTE (#PCDATA)> <!ATTLIST RECEITA ORIGEM CDATA #IMPLIED> ]> <RECEITAS> <TITULO> O Meu Livro de Receitas </TITULO> <RECEITA ORIGEM="Portugal <TITULO> Bolo </TITULO> <INGREDIENTE> 500g de farinha </INGREDIENTE> <INGREDIENTE> 200g de aucar </INGREDIENTE> <INGREDIENTE> 300g de manteiga </INGREDIENTE> </RECEITA> </RECEITAS>
Terminamos a apresentao do XML com um pequeno conjunto de regras que permitem transformar qualquer documento SGML num documento XML (lembrar que em XML no necessitamos do DTD pelo que basta que as anotaes estejam de
244
acordo com as regras do XML para que o documento possa ser considerado um documento XML):
Acrescentar no incio do documento a seguinte instruo de processamento:

<?xml version="1.0" encoding="ISO-8859-1"?>
Fechar todas as anotaes iniciadas (no h anotaes opcionais - o SGML permitia a ausncia de anotaes nalguns casos). Todos os elementos vazios passam de:
"...discutido em <Referencia citeid="plima</Referencia> ..."
a
"...discutido em <Referencia citeid="plima"/> ..."
O que ir facilitar muito a vida ao parser (ao encontrar "/>", sabe que o elemento corrente termina ali).
Todos os valores de atributos devem estar dentro de aspas.
D.2. Document Object Model (DOM)

Esta especicao dene uma interface e uma plataforma neutras que iro permitir que programas e scripts acedam e alterem o contedo, a estrutura e o estilo dos documentos, duma forma normalizada. Isto permitir uma maior portabilidade de programas e scripts. Apesar do seu nome, o DOM no um modelo orientado a objectos e sim, uma maneira independente de declarar interfaces e objectos para manipulao de documentos XML e HTML. Vo ser disponibilizados trs mtodos para utilizar o DOM para aceder a documentos XML:
245
Utilizando Javascript ou Vbscript numa pgina Web. Utilizando uma aplicao tipo "plug-in", ou ActiveX, que acedem ao documento atravs dum browser. Utilizando um parser XML externo que implementa o DOM.
Quer o Netscape Navigator, quer o Internet Explorer, suportam o DOM, mas com vrias alteraes no normalizadas. No entanto, cou estabelecido que nas prximas verses dum e doutro, o DOM suportado seria o standard.
D.3. CSS e XSL

Neste momento, h duas linguagens de especicao de estilo para documentos XML em desenvolvimento: Cascading Style Sheets (CSS) e Extensible Stylesheet Language (XSL). Ambas sero descritas em mais detalhe nas prximas seces. Neste momento, uma questo poderia ser levantada: porqu desenvolver duas linguagens e no apenas uma? O quadro seguinte fornece a resposta. Tabela D-2. CSS versus XSL CSS Pode ser usada com sim HTML? Pode ser usada com XML? sim Pode transformar documentos? Sintaxe no CSS XSL no sim sim XSL
Da anlise do quadro, pode-se concluir que o CSS pode ser usado para formatar documentos XML e HTML, no entanto, no pode ser usado para transformar documentos. Por outro lado, o XSL apenas pode ser usado para formatar XML e pode transformar documentos. Podemos agora perguntar: quando usar CSS e quando usar XSL? Sempre que o documento nal fr uma verso estilizada do documento original, devemos usar o CSS. Quando o documento nal resultar duma transformao do
246
documento original (construo de ndices, listas de nomes, ...), deve ser usado o XSL.
D.3.1. Cascading Style Sheets (CSS)

O CSS uma linguagem declarativa muito simples que permite, a autores e utilizadores, associar informao de estilo a documentos estruturados XML ou HTML. O estilo de um elemento especica-se associando-lhe propriedades e valores.
Exemplo D-3. Especicao de estilo para um elemento

H1 { font-size: 16pt; font-weight: bold; color: blue; }
Neste exemplo, est-se a declarar que os elementos H1 devem ter o texto em 16 pontos, letra carregada e de cr azul. As outras propriedades do CSS permitem especicar tudo desde o tamanho de letra dum pargrafo at margens, espaamento de linhas e texturas de fundo. O CSS tem dois nveis de especicao suportados em duas implementaes diferentes: CSS Level 1 (CSS1) O CSS1 uma linguagem de fcil leitura e permite expressar o estilo numa terminologia comum a sistemas normais de publicao. Como o nome indica, vrias especicaes de estilo podem ser aninhadas para produzir o resultado nal. CSS Level 2 (CSS2)
247
O CSS2 dene um nvel de abstraco acima do CSS1 - d um maior controle ao utilizador na disposio dos objectos na pgina. Com poucas excepes, todas as especicaes CSS1 so especicaes CSS2. Na seco seguinte descreve-se melhor o CSS2.
D.3.1.1. Cascading Style Sheets Level 2 (CSS2)

O CSS pode ser usado com qualquer documento estruturado. Vamos ver, por exemplo, a sua aplicao ao XML.
Exemplo D-4. Documento XML

<?xml version="1.0"?> <CURSO> <TITULO>XML, uma promessa?... </TITULO> <AUTOR>Jos Carlos Ramalho</AUTOR> <RESUMO> <PARA>Durante este curso, faremos uma travessia do universo <ACRON>XML</ACRON> ... </PARA> ... </RESUMO> ... </CURSO>
Para formatar este documento recorrendo ao CSS2 temos de fazer duas coisas:
Criar uma especicao de estilo Associar essa especicao de estilo ao documento XML
D.3.1.1.1. Especicao de Estilo A especicao de estilo simplesmente um cheiro de texto com extenso ".css". Para este exemplo criou-se o cheiro "curso.css".
248
Exemplo D-5. curso.css

ACRON {display: inline} CURSO, TITULO, AUTOR, RESUMO, PARA {display: block} TITULO {font-size: 16pt} AUTOR {font-style: italic} CURSO, TITULO, AUTOR, RESUMO, PARA {margin: 2cm}
As primeiras duas linhas especicam se os elementos so "inline"(devem ser colocados na mesma linha que os caracteres que os precedem e antecedem), ou "block"(h uma quebra de linha no incio do elemento e outra no m). As outras linhas alteram o valor de algumas propriedades dos elementos a que se referem (tamanho de letra, postura, margens).
D.3.1.1.2. Associar uma Especicao de Estilo Neste momento, a maneira de associar uma especicao de estilo a um documento XML inserir no incio do documento uma instruo de processamento com um determinado formato:
<?xml version="1.0"?> <?xml:stylesheet type="text/css" href="curso.css"?> ... Resto do documento ...
D.3.2. Extensible Stylesheet Language (XSL)

O CSS uma boa opo para a especicao do estilo sempre que os elementos (pargrafos, listas, cabealhos, imagens, tabelas, ...) sejam formatados e apaream no documento resultado na mesma ordem em que se encontram no documento original. Mas, nem sempre assim. H situaes em que se pretende reordenar estruturalmente o contedo dum documento. Pode-se, por exemplo, querer gerar
249
uma sntese do documento original, ou uma tabela de referncias. Este tipo de operaes requer uma transformao do documento original. O XSL permite especic-las. O XSL adoptou a sintaxe do XML. No entanto, encontra-se ainda em fase de desenvolvimento, podendo ser alterado a qualquer momento. Este facto no assustou, por exemplo a Microsoft que j integrou no seu browser ("Internet Explorer") a possibilidade de processar estilos especicados em XSL. O XSL resultou da fuso de algumas caractersticas de duas outras linguagens de especicao de estilo: do DSSSL (Seco 6.2), e do j descrito CSS. O XSL combina parte das potencialidades do DSSSL com o CSS e adiciona uma linguagem de programao para lig-las, o ECMAScript, uma verso standard de Javascript. Para construir um determinado output da informao guardada num documento XML, um processador XSL ir utilizar uma especicao de estilo para fazer uma travessia ao documento e produzir o output desejado. At ao momento, os processadores XSL disponveis geram apenas outputs em HTML, mas em teoria poderiam gerar qualquer outro formato ( semelhana do DSSSL): RTF, ASCII, PDF, TEX, etc. Num futuro muito prximo, o XSL (na verso corrente ou com alteraes) ser suportado directamente nos browsers, de momento isso no acontece. Em XSL, a associao de uma folha de estilo a um documento XML feita da mesma maneira que em CSS, atravs da incluso da linha:
<?xml-stylesheet type="text/xsl" href="curso.xsl"?>
D.3.2.1. Anatomia de uma folha de estilo XSL

Eis o conceito mais importante subjacente ao XSL: o XSL no manipula elementos, manipula objectos grcos ("ow objects"). Mais especicamente, transforma bocados dum documento XML em objectos grcos. Surge ento a questo: O que so de facto estes objectos grcos? Um objecto grco uma unidade no resultado nal de uma verso impressa ou colocada na Internet. Por exemplo, quando se formata um pargrafo com um
250
determinado tipo de letra, ou quando se coloca uma imagem num determinado ponto do cran, no estamos a tratar individualmente nem os caracteres do pargrafo nem os pixeis da imagem. Um aspecto interessante destes objectos que podem ser agrupados numa hierarquia de objectos grcos: uma caixa ("box") pode conter um ou mais pargrafos ("paragraph"). Este aninhamento de objectos comea a parecer familiar, parece mesmo a estrutura dum documento XML. Parece mas no ; um objecto grco a representao pictrica dum componente lgico do documento. Basicamente, uma folha de estilo XSL composta por um conjunto de regras de construo. Cada regra tem duas partes, um padro e um conjunto de aces. Sempre que um elemento do documento original XML corresponder ao padro especicado numa regra, o correspondente bloco de aces executado.
Exemplo D-6. Esqueleto de uma folha de estilo XSL

<xsl> <rule> [regra de construo 1] [regra de construo 2] ... </rule> <rule> [regra de construo 3] ... </rule> </xsl>
Voltamos ao exemplo do curso e das aulas para demonstrar o que uma regra de construo.
Exemplo D-7. Regra de construo

<rule> <target-element type="Aula"/>
251
<DIV font-size="12pt" font-family="sans-serif" font-style="italic <children/> </DIV> </rule>
As folhas de estilo em XSL podem ser muito simples ou muito complexas. Para mais informaes o leitor encontrar no ltimo captulo dedicado bibliograa as referncias necessrias.
D.4. Extensible Linking Language (XLL) e Extended Pointers (XPointer)

Uma das caractersticas que tornou o HTML popular foi a possibilidade de inserir hiperligaes numa pgina que a ligassem a outras pginas. Foi assim que o foi criado o grande manancial de informao que o WWW. O XML pretende ir mais alm e ultrapassar algumas das limitaes do mecanismo de hiperligaes do HTML. O XLL tem duas partes: o XLink dedicado especicao de ligaes e o XPointer dedicado ao endereamento. O Xlink difere do HTML porque vai tentar ultrapassar as limitaes existentes, nomeadamente:
Ligaes multi-direccionais - a possibilidade de uma ligao poder ser atravessada em ambos os sentidos. Ligaes com destinos mltiplos - dar a possibilidade ao utilizador de escolher um de entre vrios destinos. Pode operar com um repositrio de endereos e toda a gesto a este associada. Permite a colocao de ligaes "out-of-line- podemos ter um cheiro parte onde ser colocada a informao das ligaes (quais so as suas extremidades); este cheiro acaba por ser uma lista de pares; este mecanismo um passo na implementao das ligaes bi-direccionais.
252
O Xpointer vem complementar o Xlink. Normalmente quando temos uma ligao duma pgina a outra, e se indica ao browser que se quer seguir essa ligao, o browser carrega a nova pgina integralmente. A ideia por detrs do Xpointer optimizar esta funcionalidade. Para isso, disponibiliza uma pequena linguagem de query que permite seleccionar qual a parte da nova pgina que se quer ver. Apresenta-se a seguir um exemplo.
Exemplo D-8. XPointer

http://www.di.uminho.pt/~jcr/CURSOS/curso.xml# ROOT()CHILD(4,Aula)
Este endereo apontaria para a quarta aula no documento estruturado XML de nome curso.xml
O Xlink e o Xpointer so bastante complexos e mereceriam um captulo inteiramente dedicado a eles mas o facto de no serem ainda suportados por nenhuma ferramenta faz deles apenas um objecto de estudo a ter em conta. No entanto, quem quiser ler mais sobre o assunto pode consultar o livro [Bra98].
D.5. NameSpaces in XML (XML Namespace)

Esta mais uma proposta no sentido de adoptar a losoa dos objectos para o SGML. A ideia podermos criar um documento em que uma parte obedea a um DTD e outras partes obedeam a outros. Ou seja, podemos criar novas estruturas documentais combinando partes de outras j existentes. Esta proposta est ainda num estado embrionrio e o respectivo suporte a nvel de ferramentas de processamento quase inexistente. Para terminar apresentamos um exemplo da sua aplicao.
253
Exemplo D-9. XML NameSpaces Voltemos ao DTD das receitas. Agora, queremos criar uma nova receita mas queremos colocar para cada ingrediente uma marca aconselhada. Como no previmos nenhum elemento para isso vamos import-lo do DTD de artigos (descreve os produtos venda no mercado). Declaramos a importao de novos elementos:
<?xml:namespace name="http://jcr.pt/" href="http://jcr.pt/dtds/artigo.dtd" as="art"?>
a partir deste momento todos os elementos do dtd artigo podem ser usados desde que prexados com "art". Assim, podamos escrever:
<RECEITAS> <TITULO> O Meu Livro de Receitas </TITULO> <RECEITA ORIGEM="Portugal <TITULO> Bolo </TITULO> <INGREDIENTE> 500g de farinha </INGREDIENTE> <art:MARCA>Branca de Neve</art:MARCA> <INGREDIENTE> 200g de aucar </INGREDIENTE> <art:MARCA>Portugus</art:MARCA> <INGREDIENTE> 300g de manteiga </INGREDIENTE> <art:MARCA>Loreto</art:MARCA> </RECEITA> </RECEITAS>
D.6. Vector Markup Language

Tem havido um grande esforo para normalizar o formato utilizado para as imagens na Internet. Os normais GIF e JPEG j no satisfazem e a procura de um formato vectorial tem animado empresas e particulares. Decidiu-se que haveria dois formatos, um de alta denio vocacionado para esquemas de maquinaria,
254
arquitectura e aplicaes semelhantes e outro com menos detalhe usado para as imagens que estamos habituados a ver, logotipos, fotograas, esquemas simples. A guerra pelo formato de alta denio teve poucos concorrentes e cou rapidamente decidido que seria o CGM. O outro formato tem sido alvo de bastante polmica. Tudo comeou com a proposta da Adobe, o SVG ("Standard Vector Graphic") que logo teve resposta da Microsoft com o VML ("Vector Markup Language"). Outras foram tambm propostas, como a DML ("Drawing Markup Language"), mas no motivaram tanto interesse. At ao momento, mantm-se as duas como propostas. De qualquer modo existem implementaes das duas em browsers que as suportam.
D.7. Simplied Markup Language - SML

Quando tudo parecia calmo eis que surge nova tempestade. Quem pensava que o XML j era muito simples e que, provavelmente, seria o formato adoptado por toda a gente enganou-se. Na passagem do milnio, surge algum (Robert Quey - [Que99]) que diz que preciso uma linguagem mais simples. Eis o que os defensores duma linguagem de anotao simplicada advogam:

S deveria usar unicode no formato UTF-8. No deve ter instrues de processamento. No deve ter entidades paramtricas. No deve ter um DTD. No deve ter notaes. No deve ter entidades. No deve ter atributos. No deve ter elementos.
No m, teramos:
255
texto comentrios (onde o utilizador os quisesse colocar)
claro que as reaces no demoraram, e Rick Jeliffe [Jel99], rebate esta proposta ponto por ponto. No entanto, ser que isto no nos faz lembrar nada?...
256
Bibliograa
Artigos
[ABNO97] CAMILA: Formal Software Engineering Supported by Functional Programming, J.J. Almeida, L.S. Barbosa, F.L. Neves, e J.N. OliveiraEditado por e J. Diaz, Proc. II Conf. Latino Americana de Programacion Funcional (CLaPF97), La Plata, Argentina, October 1997.. [Aho98] Features of Knowledge Discovery Systems, Helena Ahonen. International SGML Users Group (ISUG) Newsletter, 1998. [BHW99] Visually Specifying Context, Anne Bruggemann-Klein, Stefan Hermann, e Derick Wood, March 1999. [Bray98] RDF and Metadata, Tim Bray, Seybold and OReilly Publicatons, June 1997. [Bru94] Compiler-Construction Tools and Techniques for SGML parsers: Difculties and Solutions, Anne Bruggemann-Klein, May 1994. [Bry98] Topic Navigation Maps, Martin Bryan. International SGML Users Group (ISUG) Newsletter, 1998. [Cap95] You Call It Corn, We Call It Syntax-Independent Metadata for Document-Like Objects, Priscilla Caplan, 1995. The Public-Access Computer Systems Review 6, 4. [CKR97] The Evolution of Web Documents, Dan Connolly, Rohit Khare, e Adam Rifkin, Seybold and OReilly Publicatons, October 1997. [CCDFPT98] XML-GL: A Graphical Language for Querying and Reshaping XML Documents, Stefano Ceri, Sara Comai, Ernesto Damiani, Piero Fraternali,
257
Stefano Paraboschi, e Letizia Tanca, QL98 - The Query Languages Workshop, December 5, 1998. [DeR98] XQuery: A unied syntax for linking and querying general XML documents, Steven DeRose, QL98 - The Query Languages Workshop, December 5, 1998. [DuC97] Formatting Documents with DSSSL Specications and Jade: Parts 1, 2, 3, Bob DuCharme. <TAG> Newsletter, May, June, July 1997. [Hee96] Review of Metadata Formats: Program, 30, 345-373, Rachel Heery, October 1996. [Ken96] Tales from the Front Understanding Structured Documents: <TAG> The SGML Newsletter, Dianne Kennedy, February 1996. [Ken97] An Introduction to DSSSL (ISO/IEC 10179), Dianne Kennedy. <TAG> Newsletter, February 1997. [Kil99] SGML & XML content models, Pekka Kilpelainen99. Markup Languages: theory and practice, Editado por C. M. Sperberg-McQueen, Editado por B. Tommie Usdin, Spring 1999. [Knu68] Semantics of Context Free Languages, Donald E. Knuth. Mathematical Systems Theory journal, 1968. [Knu92] Literate Programming, Donald E. Knuth, University of Chicago Press, 1992. [MA98] Conceptual Structures and Structured Documents, Philippe Martin e Laurence Alpay, INRIA - ACACIA project. [Mar99a] Construction Rules, Didier PH Martin, OpenJade Project.
258
http://www.netfolder.com [New97] Document Architectures: the New Hytime, Steven Newcomb. International SGML Users Group (ISUG) Newsletter, 1997. [Omn98] Dening Microdocument Architecture, Omnimark Technologies. http://www.omnimark.com [Paa95] Attribute Grammars Paradigms: A High-Level Methodology in Language Implementation, Jukka Paakki, ACM Computing Serveys, 27, 2, June 1995. [RAH95] Algebraic Specication of Documents, Jos Carlos Ramalho, Jos Joo Almeida, e Pedro Rangel Henriques, TWLT10 - Algebraic Methods in Language Processing - AMiLP95, number 10 in Twente Workshop on Language Technology, Twente University - Holland, Dec. 1995. [RAH96] Document Semantics: Two Approaches, Jos Carlos Ramalho, Jos Joo Almeida, e Pedro Rangel Henriques, SGML96 - Celebrating a Decade of SGML, Boston - USA, Nov. 1996. [RAH98] Algebraic specication of documents, Jos Carlos Ramalho, Jos Joo Almeida, e Pedro Rangel Henriques. Theoretical Computer Science, 1998. [RLS98] XML Query Language (XQL), Jonathan Robie, Joe Lapp, e David Schach, QL98 - The Query Languages Workshop, December 5, 1998. [RRAH99] SGML documents: Where does quality go?, Jos Carlos Ramalho, Jorge Gustavo Rocha, Jos Joo Almeida, e Pedro Rangel Henriques. Markup Languages: theory and practice, Editado por C. M. Sperberg-McQueen, Editado por B. Tommie Usdin, Winter 1999. [SAS99] Designing and Implementing Combinator Languages, S.Doaitse Swierstra, Pablo Alcocer, e Joo Saraiva, Advanced Functional Programming
259
Summer School, Editado por Pedro Henriques, Editado por J.N. Oliveira, Universidade do Minho, 1999. [Spe98] A Gentle Introduction to DSSSL, Dan Speck. International SGML Users Group (ISUG) Newsletter, 1998. [Tom98] Providing exible access in a query language for XML, Frank Tompa, QL98 - The Query Languages Workshop, December 5, 1998. [TR81] The Cornell Synthesizer Program: A Syntax-Directed Programming Environment, Tim Teitelbaum e Thomas Reps, ACM, 24, September 1981. [Wad99] A formal semantics of patterns in XSLT , Philip Wadler, Markup Technologies99, Philadelphia - USA, Dec. 1999. [WGMD] OCLC/NCSA Metadata Workshop Report, Stuart Weibel, Jean Godby, Eric Miller, e Ron Daniel. [Wid8] Querying XML with Lore, Jennifer Widom, QL98 - The Query Languages Workshop, December 5, 1998.
Livros
[Bra98] The XML Companion, Neil Bradley, Addison-Wesley, 1998. [DD94] Making Hypermedia Work: A Users Guide to HyTime, Steven DeRose e David Durand, Kluwer Academic Publishers, 1994. [GMS94] The LaTeX Companion, Michel Goossens, Frank Mittelbach, e Alexander Samarin, Addison-Wesley, May 1994. [Gol90] The SGML Handbook, Charles Goldfarb, Clarendon Press, 1990. [Hen92] Gramticas de Atributos, Pedro Rangel Henriques, Tese de Doutoramento, Escola de Engenharia - Departamento de Informtica - Universidade do Minho, 1992.
260
[Her94] Practical SGML, Eric Herwijnen, Kluwer Academic Publishers, 1994. [Lop98] Gerador de Editores Estruturados de Documentos SGML Denidos por DTDs, Alda Cristina Reis Santos Lopes, Tese de Mestrado em Informtica, Escola de Engenharia - Departamento de Informtica - Universidade do Minho, 1998. [MA96] Developing SGML DTDs: From Text to Model to Markup, Eve Maler e Jeanne Andaloussi, Prentice-Hall, 1996. [Meg98] Structuring XML Documents, David Megginson, Prentice-Hall, 1998, 0-13-642299-3. Charles F. Goldfarb Series on Open Information Management. [PP92] The Art of Compiler Design, Thomas Pittman e James Peters, Prentice-Hall, 1992. [Ram93] Um Compilador para o GLiTCH , Jos Carlos Leite Ramalho, Tese de Mestrado em Informtica, Escola de Engenharia - Departamento de Informtica - Universidade do Minho, 1993. [RT89a] The Synthesizer Generator: A System for Constructing Language-Based Editors, Thomas Reps e Tim Teitelbaum, Texts and Momographs in Computer Science., Springer-Verlag, 1989.. [RT89b] The Synthesizer Generator Reference Manual, Thomas Reps e Tim Teitelbaum, Texts and Momographs in Computer Science., Springer-Verlag, 1989.. [Sou98] Semntica de Documentos SGML, Pedro Rui Marques Frana Pereira de Sousa, Tese de Mestrado em Informtica, Escola de Engenharia Departamento de Informtica - Universidade do Minho, 1998. [Tar92] Data Processing in the Unix Environment, Ramkrishna Tare, McGraw-Hill, 1989. [SB94] Guidelines for Electronic Text Encoding and Interchange (TEI P3), C.M. Sperberg-McQueen e Lou Burnard , Association for Computers and the
261
Humanities, Association for Computational Linguistics, Association for Literary and Linguistic Computing, 1994. [TW95] The SGML Implementation Guide: A Blueprint for SGML Migration, Brian Travis e Dale Waldt, Springer, 1995. [WM99] DocBook: The Denitive Guide, Norman Walsh e Leonard Muellner, OReilly, 1-56592-580-7, October 1999.
Relatrios
[BA95] CAMILA: A Reference Manual, L.S. Barbosa e J.J. Almeida, Technical Report DI-CAM-95:11:2, DI (U.Minho), 1995. [Fig98] Publicao na Internet do livro "Memrias de Jos Incio Peixoto dos Santos", Nuno Figueiredo, Arquivo Distrital de Braga / Universidade do Minho, Fevereiro de 1998. [HAR99] DAVID - Manipulao Algbrica de Documentos: Projecto JNICT 2479/96, Pedro Rangel Henriques, Jos Joo Almeida, e Jos Carlos Ramalho, Departamento de Informtica - Universidade do Minho, 1996-1999. [LC99] Recuperao de Edies Esgotadas: Inventrio das Cartas do Cabido da S de Braga, Armando Lemos e Jos Henrique Cerqueira, Arquivo Distrital de Braga / Universidade do Minho, Fevereiro de 1999. [LO99] Publicao de Edies Esgotadas do Arquivo Distrital de Braga na Internet: Inventrio das Visitas e Devassas do Cabido da S de Braga, Carla Lopes e Clara Oliveira, Arquivo Distrital de Braga / Universidade do Minho, Fevereiro de 1999. [RG98] Publicao na Internet do Livro: "Ensaio Sobre as Minas de Joze Anastacio da Cunha, Salom Ribeiro e Snia Gaspar, Arquivo Distrital de Braga / Universidade do Minho, Julho de 1998. [Sal97] SGML/XML tools and comparision: Design and development of SGML conversions, Carlos Salgado, FAST - Faculdade de Wuerzburg - Alemanha /
262
Universidade do Minho, 1997.
Publicaes Electrnicas
[ANTLR] "ANTLR- (http://www.ANTLR.org) [ARCSGML] "ARCSGML- (ftp://ftp.i.uio.no/pub/SGML/ARC-SGML) [ASP] "ASP-SGML: Jos Warmers Amsterdam SGML Parser(ftp://ftp.i.uio.no/pub/SGML/ASP-SGML) [Bray98] "When is an attribute an attribute?- Tim Bray; (http://www.oasis-open.org/cover/brayAttr980409.html)Robin Cover; OASIS; 1998/04/09 [CMAlgebra] "Content Model Algebra(http://www.omnimark.com/white/content/)Omnimark White Papers; Omnimark Technologies; 1998 [css1] "Cascading Style Sheets Level 1 (CSS1)- World Wide Web Consortium Recommendation 17-December-1996; (http://www.w3.org/TR/REC-CSS1-961217) [css2] "Cascading Style Sheets Level 2 (CSS2)- World Wide Web Consortium Recommendation 12-May-1998, (http://www.w3.org/TR/1998/REC-CSS2-19980512/) [DuC98] "DBMS support of SGML- Bob DuCharme; (http://www.oasis-open.org/cover/ducharmeVendors9808.html)Robin Cover; OASIS; 1998/08 [DCD] "Document Content Denition(http://www.w3c.org/TR/1998/NOTE-dcd-19980731.html)World Wide Web Consortium Note; World Wide Web Consortium; 1998.07.31 [DLMC] "Digital Library Miguel de Cervantes(http://www.w3c.org/TR/1998/NOTE-dcd-19980731.html)Universidade de Alicante // Banco Santander Central Hispano; 1999-2000 [DocBook] "The DocBook DTD- (http://www.oasis-open.org/docbook/)OASIS; 1998 [DOM] "Document Object Model (DOM)- (http://www.w3c.org/DOM/)
263
[Cla96] "DSSSL - Document Style and Semantics Specication Language- Editado por James Clark; (http://www.jclark.com/dsssl); 1996 [Mul98] DSSSL Documentation Project (http://www.mulberrytech.com/dsssl/dsssldoc/index.html)Mulberry Technologies; 1998 [GEIRA] "Gesto da Informao da rea fronteiria norte- Universidade do Minho; (http://www.geira.pt/); 1996 - 1999 [Ger96] "An Introduction to DSSSL- Daniel Germn; (http://www.jclark.com/dsssl); 1996 [Hol99] "When to use attributes as opposed to elements- G. Ken Holman; (http://www.oasis-open.org/cover/holmanElementsAttrs.html)Robin Cover; OASIS; 1999/01/11 [html4.0] "HyperText Markup Language Version 4.0 (HTML)(http://www.w3.org/TR/1998/REC-html40-19980424/)World Wide Web Consortium Recommendation 24-Apr-1998; [jade] "Jade- James Clark; (http://www.jclark.com/jade/); 1996-99 [Jel99] "Goldilocks and SML- Rick Jeliffe; (http://www.xml.com/pub/1999/12/sml/goldilocks.html); Dec. 15 1999 [Kim97] "Designing a DTD: Elements or attributes?- W. Eliot Kimber; (http://www.oasis-open.org/cover/attrKimber9711.html)Robin Cover; OASIS; 1997/11/18 [Meg98b] "PSGML - DSSSL- David Megginson; (http://www.oasis-open.org/cover/megg-psgml-dsssl-el.txt); 1998.02.23 [OpenJade] "OpenJade- (http://www.netfolder.com/DSSSL/index.html) [POSTSCRIPT] "Postscript- (http://www.adobe.com) [Pre97] "Introduction to DSSSL- Paul Prescod; (http://www.jclark.com/dsssl); 1997 [Que99] "SML: Simplifying XML- Robert Quey; (http://www.xml.com/pub/1999/12/sml/index.html); Nov. 24 1999 [SGML.Decl] "Understanding The SGML Declaration(http://www.omnimark.com/white/dec/)Omnimark White Papers; Omnimark Technologies; 1998
264
[SGMLS] "SGMLS- James Clark; (http://www.jclark.com/jade/) [SP] "SP - SGML Parser- James Clark; (http://www.jclark.com); 1995-99 [Spy97] "Formal Public Identier Roadtrip(http://www.cm.spyglass.com/doc/fpi.html)Cambridge Spyglass Technical Reference; Spyglass Inc.; 1997 [Sta99] "PSGML- (http://www.lysator.liu.se/projects/about-psgml.html); 1999.10.14 [Tho97] "SGML Groves: A Partial Illustrated Example(http://www.cogsci.ed.ac.uk/~ht/grove.html)Henry Thompson; 1997 [Unicode] "Unicode - (http://www.unicode.org) [Wal2000] "Modular Docbook DSSSL Stylesheets- (http://nwalsh.com) [WIDL] "Web Interface Denition Language(http://www.w3c.org/TR/1998/NOTE-widl-19970922.html)World Wide Web Consortium Note; World Wide Web Consortium; 1997.09.22 [xlink] "Extensible Linking Language (XLink)(http://www.w3.org/TR/1998/WD-xlink-19980303)World Wide Web Consortium Working Draft 3-March-1998; [XML] "eXtended Markup Language (XML)- (http://www.xml.com) [xml1.0] "Extensible Markup Language (XML) Version 1.0 (http://www.w3.org/TR/1998/REC-xml-19980210.html)World Wide Web Consortium Recommendation 10-February-1998; [xpointer] "XML Pointer Language (XPointer)(http://www.w3.org/TR/1998/WD-xptr-19980303)World Wide Web Consortium Working Draft 3-March-1998; [xsl] "Extensible Stylesheet Language (XSL) Version 1.0(http://www.w3.org/TR/1998/WD-xsl-19980818)World Wide Web Consortium Working Draft 18-August-1998; [xslt] "XSL Transformations (XSLT) - Version 1.0(http://www.w3.org/TR/1999/REC-xslt-19991116.html)World Wide Web Consortium Recommendation 16-November-1999; [YASP] "YASP: Pierre Richards Yorktown Advanced SGML Parser (or: Yet Another SGML Parser)- (ftp://ftp.edf.fr/pub/SGML/YASP)
265
[YAO] "YAO (Yuan-ZeAlmadenOslo project) Parser Materials(ftp://hki.wsoy./pub/yao-u.tar.gz)
266

Anotação Estrutural de Documentos e Sua Semântica

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Anotação Estrutural de Documentos e Sua Semântica

Uploaded by

Copyright:

Available Formats

Anotao Estrutural de Documentos e sua Semntica

Especicao da Sintaxe, Semntica e Estilo para Documentos

Jos Carlos Leite Ramalho

Superviso: Pedro Rangel Henriques

1.2. Estrutura da Dissertao

Captulo 2. Notaes e Formalismos utilizados

2.1. CAMILA: uma pequena introduo

Em que a denio de tipo tem a seguinte forma:

Captulo 2. Notaes e Formalismos utilizados

Para exemplicar estes conceitos apresenta-se o exemplo seguinte:

Captulo 2. Notaes e Formalismos utilizados

As funes normais sobre uma stack especicam-se, ento, da seguinte maneira:

Captulo 2. Notaes e Formalismos utilizados

Captulo 2. Notaes e Formalismos utilizados

CAMILA elems(s) inds(s)

Descrio Conjunto dos elementos Domnio

2.2. Gramticas de Atributos

que representaremos neste documento como:

Captulo 2. Notaes e Formalismos utilizados

Captulo 2. Notaes e Formalismos utilizados

uma condio de contexto um predicado da forma: pred( ..., X i.a, ... ), i 0

2.2.1. Clculo de Atributos

Captulo 2. Notaes e Formalismos utilizados

2.2.2. Synthesizer Generator (SGen)

Captulo 2. Notaes e Formalismos utilizados

Captulo 2. Notaes e Formalismos utilizados

Captulo 3. Documentao Estruturada

Captulo 3. Documentao Estruturada

Captulo 3. Documentao Estruturada

Captulo 3. Documentao Estruturada

3.1.1. Anotao Procedimental

Exemplo 3-1. Uma carta anotada

Captulo 3. Documentao Estruturada

Exemplo 3-2. Texto anotado em TeX

3.1.2. Anotao Descritiva

Exemplo 3-3. Texto anotado de uma carta

Captulo 3. Documentao Estruturada

3.1.3. Linguagens de Anotao

Captulo 3. Documentao Estruturada

3.1.4. Formatao e/ou Estrutura?

3.1.4.1. Anotao orientada ao formato

Captulo 3. Documentao Estruturada

Exemplo 3-4. Anotao orientada ao formato

3.1.4.2. Anotao orientada estrutura

Exemplo 3-5. Anotao orientada estrutura

Captulo 3. Documentao Estruturada

3.1.4.3. Anotao orientada ao contedo

Exemplo 3-6. Anotao orientada ao contedo

3.1.4.4. Uma anotao equilibrada

Captulo 3. Documentao Estruturada

3.2. Documentos e Linguagens de Anotao

Captulo 3. Documentao Estruturada

Captulo 3. Documentao Estruturada

3.2.2. O Sentido Ecumnico do HTML

Captulo 3. Documentao Estruturada

Captulo 4. SGML - ISO8879

4.1. Documentos SGML

Captulo 4. SGML - ISO8879

Exemplo 4-1. Documento anotado em SGML

Captulo 4. SGML - ISO8879

Figura 4-1. Estrutura do texto anotado

Captulo 4. SGML - ISO8879

Captulo 4. SGML - ISO8879