departamento de engenharia informática - instituto superior de …paf/proj/junho2001/xml.pdf ·...

Instituto Superior de Engenharia do Porto Licenciatura em Informática Comput ador es e Si st emas

Porto, Maio 2001

Autor: José Fernando Pereira de Jesus Barbosa

nº 940550

A elaboração de um trabalho a este nível envolve normalmente a participação de terceiros. Neste sentido, gostaria de agradecer ao Engº Paulo Ferreira pela orientação, empenho e disponibilidade com que contribuiu para o desenvolvimento deste documento.

O crescimento da Internet e comunicações, e a influência que têm sobre as nossas vidas, conduzem a uma evolução constante que nos surpreende em intervalos curtos de tempo. A banalização do termo Internet, trouxe-nos a possibilidade de comunicar com qualquer entidade, individual ou não, a partir de qualquer ponto do mundo. Desde a nossa casa, passando pela escola até a local de trabalho, a Internet é um meio de comunicação por excelência. Um dos aspectos fundamentais deste meio, está relacionado com a apresentação de informação. Os standards aceites internacionalmente, como a HTML, o JavaScript ou a utilização de GIFs contribuíram ao longo dos ultimos anos para a evolução da Internet tal e qual a conhecemos hoje. No entanto, não disponibilizam capacidades suficientes para dar resposta a um outro aspecto, talvez ainda mais importante. A manipulação dessa informação. Seguindo a mesma linha de raciocínio relacionado com a evolução da Internet associada a estas tecnologias, a criação de um standard para representação e manipulação de informação, contribuiria de igual modo para uma evolução talvez ainda mais acentuada. Este facto, está directamente relacionado com o advento dos novos conceitos como o B2B e B2C, aliados à partilha de informação entre grandes centros de armazenamento mundiais, entre outros, que vieram revolucionar a forma como entendemos as comunicações hoje, e a nossa antevisão de um futuro próximo. A linguagem XML surge neste contexto, com o objectivo de se afirmar como um standard na representação e manipulação de informação, sendo o principal veículo de comunicação de dados entre as entidades mais diversas. A sua versatilidade e o seu potencial contrastam com a sua simplicidade de utilização. Este documento pretende ser uma abordagem simples e objectiva dos conceitos, sintaxes e aplicação desta linguagem. Recorrendo a uma estrutura ao alcance de qualquer leitor, pretende salientar a crescente importância da utilização desta norma no nosso dia a dia, como programadores ou simples utilizadores das tecnologias de informação. O documento apresenta-se dividido em cinco capítulos, cuja abordagem encaminha o leitor para o conhecimento da XML, desde os seus fundamentos mais simples, até às técnicas mais elaboradas de representação e tratamento de informação. O primeiro capítulo, é uma introdução ao conceito de utilização, às tecnologias associadas e à aplicação corrente da linguagem em casos concretos.

O segundo capítulo inicia o leitor na utilização dos conceitos fundamentais, através de exemplos simples, evoluindo posteriormente para a caracterização dos elementos mais relevantes ligados à especificação, como por exemplo, as tags, os atributos, os elementos, entre outros. O terceiro capítulo aborda os conceitos ligados à internacionalização e validação dos documentos XML, nomeadamente, a norma Unicode e os DTDs. O quarto capítulo, aborda as linguagens ligadas à XML, sem as quais esta não teria o potencial que a caracteriza. Refiro-me concretamente à XSL e às CSSs, fundamentais na representação e manipulação de informação. O quinto e último capítulo, apresenta outras tecnologias relacionadas, como os XLinks, os XPointers e os Namespaces, que de igual modo, contribuem para a flexibilidade e versatilidade da XML.

O objectivo deste documento é disponibilizar ao leitor uma abordagem simples e prática da linguagem XML e das tecnologias que lhe estão associadas. Sem pretender ser uma bíblia, aborda de forma aprofundada os aspectos fundamentais da linguagem, realçando os elementos que considero mais importantes para entrar neste “mundo” , com base na experiência diária que tenho na utilização desta tecnologia. Utilizando uma linguagem simples, perceptível a qualquer leitor, poderei dizer que é um documento fundamental para quem quer dominar os aspectos fundamentais da XML, com um dispêndio de tempo não muito elevado. De leitura agradável, servirá de acompanhamento nos estágios inicial e intermédio da evolução do utilizador, como ferramenta de consulta ou referência, sendo um veículo excelente para um posterior aprofundamento exaustivo, quer da XML, quer das tecnologias relacionadas, nomeadamente a XSL e as CSSs.

CAPÍTULO I ................................................................................................................... 11

INTRODUÇÃO .................................................................................................................... 12 O que é a XML ............................................................................................................... 12 O que define a XML....................................................................................................... 13 Troca de informação entre aplicações............................................................................ 13 Informação estruturada e integrada................................................................................ 14

O DOCUMENTO XML ...................................................................................................... 15 Editores........................................................................................................................... 15 Processadores ................................................................................................................. 15 Browsers e outras ferramentas........................................................................................ 15

UM ASPECTO GRÁFICO DO PROCESSO.............................................................................. 16 TECNOLOGIAS RELACIONADAS........................................................................................ 17

HTML............................................................................................................................. 17 CSS................................................................................................................................. 17 XSL................................................................................................................................. 17 URLs e URIs.................................................................................................................. 18 XLL ................................................................................................................................ 18 Os caracteres Unicode.................................................................................................... 18 Como se encaixam todas estas tecnologias.................................................................... 18

APLICAÇÕES DA XML ...................................................................................................... 20 A CML............................................................................................................................ 20 A MathML...................................................................................................................... 20 A MusicML .................................................................................................................... 21 Literatura Clássica.......................................................................................................... 21

CAPÍTULO I I ................................................................................................................. 22

O PRIMEIRO DOCUMENTO................................................................................................ 23 A criação de um documento........................................................................................... 23 O significado da estrutura do documento....................................................................... 24 O significado das tags..................................................................................................... 24 Construir uma CSS......................................................................................................... 25 Aplicar a CSS ao documento XML................................................................................ 25

A ESTRUTURAÇÃO DE DADOS EM XML ........................................................................... 27 A importância da organização de dados......................................................................... 27 Apresentação do exemplo............................................................................................... 27 O processo de estruturação............................................................................................. 28 As vantagens de utilização do formato XML................................................................. 32

ATRIBUTOS, ELEMENTOS E TAGS.................................................................................... 34 Atributos......................................................................................................................... 34

Atributos vs. Elementos.................................................................................................. 35 Tags................................................................................................................................ 37

A LINGUAGEM XSL .......................................................................................................... 39 Os templates................................................................................................................... 39 CSS ou XSL ................................................................................................................... 44

DOCUMENTOS XML BEM FORMADOS ............................................................................. 45 A constituição do documento XML ............................................................................... 45 A linguagem de marcação .............................................................................................. 45 Comentários.................................................................................................................... 46 Referências..................................................................................................................... 46 CDATA .......................................................................................................................... 47 Tags................................................................................................................................ 48 Atributos......................................................................................................................... 49 Regras de codificação em XML ..................................................................................... 49 Regras de codificação em HTML................................................................................... 50

CAPÍTULO I I I ................................................................................................................ 51

A REPRESENTAÇÃO DE LINGUAGENS............................................................................... 52 Scripts, Conjuntos de Caracteres e Fontes ..................................................................... 52 O formato Unicode......................................................................................................... 53 Como escrever XML em Unicode.................................................................................. 53

DTDS ................................................................................................................................ 55 Conceito.......................................................................................................................... 55 Especificação.................................................................................................................. 56 Validação........................................................................................................................ 57 Listagem de elementos................................................................................................... 57 Declaração de elementos................................................................................................ 58 Comentários.................................................................................................................... 62 Partilha de DTDs entre documentos............................................................................... 63 DTDs Públicos................................................................................................................ 64 Combinação de DTDs internos e externos..................................................................... 65 Entidades........................................................................................................................ 65

Entidades Internas........................................................................................................ 66 Entidades Externas....................................................................................................... 68

Entidades e DTDs em documentos bem formados......................................................... 70 Declarações de Atributos no DTD ................................................................................. 71

Declaração de múltiplos atributos................................................................................ 72 Especificação de valores por defeito............................................................................ 73 Tipos de Atributos........................................................................................................ 74 Atributos pré-definidos................................................................................................ 77

Integração de dados não XML ....................................................................................... 78 Notações....................................................................................................................... 79 Entidades externas não interpretadas........................................................................... 80 Instruções de Processamento........................................................................................ 81

Secções condicionais nos DTDs..................................................................................... 82

CAPÍTULO IV ................................................................................................................ 83

CSSS – CASCADING STYLE SHEETS................................................................................. 84 Conceito.......................................................................................................................... 84 Selecção de elementos.................................................................................................... 85 Atributos de estilo........................................................................................................... 87 Herança........................................................................................................................... 87 Mais do que uma folha de estilos no mesmo documento............................................... 88 As unidades de representação de valores....................................................................... 89

Valores do tipo length.................................................................................................. 89 Valores do tipo URL .................................................................................................... 89 Valores do tipo cor ....................................................................................................... 90 Valores do tipo keyword.............................................................................................. 90

Os elementos Block, InLine, e List Item........................................................................ 90 Propriedades................................................................................................................... 92

Fontes........................................................................................................................... 93 Aspectos de Fundo....................................................................................................... 93 Texto ............................................................................................................................ 94 Caixas........................................................................................................................... 94

Extensão da CSS............................................................................................................. 95 XSL ................................................................................................................................... 98

Conceito.......................................................................................................................... 98 Árvores......................................................................................................................... 98

O documento XSL ........................................................................................................ 100 Como decorre o processo de transformação................................................................. 101 Os templates em XSL ................................................................................................... 101

O elemento xsl:apply-templates................................................................................. 101 O atributo select ......................................................................................................... 103

Determinar o valor de um elemento com xsl:value-of ................................................. 103 Processar vários elementos com xsl:for-each............................................................... 104 Padrões para efectuar matching.................................................................................... 105

O elemento raiz .......................................................................................................... 105 Os outros elementos................................................................................................... 105 A utilização dos símbolos /, //, @ e |.......................................................................... 106 Efectuar testes utilizando [ ]....................................................................................... 107

Selecções condicionais................................................................................................. 108 A utilização de xsl:if .................................................................................................. 108 A utilização de xsl:choose.......................................................................................... 109

Ordenar elementos........................................................................................................ 109 Definição de constantes................................................................................................ 110 Utilização de nomes em templates............................................................................... 111 Incluir múltiplos documentos de estilo......................................................................... 112

A utilização de xsl:import .......................................................................................... 112 A utilização de xsl:include......................................................................................... 113

CAPÍTULO V................................................................................................................ 114

XL INKS........................................................................................................................... 115 Ligações simples .......................................................................................................... 115

Descrições de recursos............................................................................................... 116 Comportamento da ligação ........................................................................................ 116

Ligações estendidas...................................................................................................... 117 Ligações Out-of-Line................................................................................................. 118 Grupos de ligações estendidas................................................................................... 118

XPOINTERS..................................................................................................................... 119 Localização absoluta .................................................................................................... 119 Localização relativa...................................................................................................... 120

Selecção por número.................................................................................................. 121 Selecção por tipo........................................................................................................ 122 Selecção por atributo.................................................................................................. 123

Localização baseada em texto ...................................................................................... 123 NAMESPACES.................................................................................................................. 125

Conceito........................................................................................................................ 125 Sintaxe de utilização..................................................................................................... 126 Namespaces por defeito................................................................................................ 127 Namespaces em DTDs ................................................................................................. 128

Conceito

A linguagem XML Conceito

12

Neste capítulo apresentam-se os aspectos caracterizadores da linguagem XML em conjunto com as definições e conceitos essenciais, no sentido de proporcionar ao leitor um enquadramento geral no contexto da utilização desta nova tecnologia, e outras com as quais está intimamente relacionada.

A notação XML representa a designação por extenso de eXtensible Markup Language. A XML é, basicamente, uma linguagem que constitui um conjunto de regras utilizadas para definir uma semântica de marcações ( tags ), que dividem um documento em partes. Um erro comum é identificar na XML algo idêntico à HTML ( Hiper-Text Markup Language ) ou outras linguagens deste género. Existe no entanto uma diferença fundamental entre ambas que reside no facto de a segunda definir um conjunto de tags fixo que como tal, descreve um conjunto fixo de elementos. Este facto limita o utilizador em termos de codificação, uma vez que este irá sempre depender das especificações incluídas na linguagem. A XML é uma linguagem bastante mais flexível, permitindo ao utilizador a definição de tags de acordo com as suas necessidades. Esta definição, embora tenha que obedecer a um conjunto de normas, não possui um carácter restritivo, antes pelo contrário. Imaginemos áreas tão distintas como a investigação espacial e a culinária, onde as terminologias e necessidades em termos de identificação de informação levariam a pensar que as deveríamos codificar de forma completamente isolada. Com a XML tal não acontece uma vez que o utilizador detém total liberdade de codificação. Alguns aspecto relacionados com esta liberdade residem no facto de não ser necessário que a codificação obedeça a parágrafos, listas de itens, sublinhados ou outras formas conhecidas de distinguir ou enfatizar informação. Outro aspecto interessante, que abordarei mais à frente, é a possibilidade de documentar num DTD ( Document Type Definition ) um conjunto de tags definidas pelo utilizador. Por agora tenhamos apenas em mente que um DTD é uma espécie de vocabulário que pode ser associado a um ou mais documentos XML. Adicionalmente, posso também adiantar que um browser não necessita de saber como representar um conjunto ilimitado de tags aquando da leitura de um DTD. Esta especificação poderá ser feita separadamente numa folha de estilos. Ao longo do tempo várias vertentes distintas, como por exemplo a música ou a matemática, tiverem de aguardar que os fornecedores de soluções disponibilizassem nas suas especificações um conjunto de tags suficiente para representar os mais variados


13

tipos de informação. Hoje, a XML vem oferecer a possibilidade de quebrar definitivamente esta dependência, conferindo aos utilizadores o papel de “ inventores” das suas próprias especificações.

Algo que o leitor deve entender é que a XML define a semântica e estruturação dos elementos e não a formatação da sua apresentação na página de um browser. Essa formatação pode ser definida numa folha de estilos. Resumidamente, um documento XML apenas possui dados e não a forma como estes serão apresentados ao utilizador, ou seja, estamos na presença de um conceito completamente distinto da HTML. Vejamos o seguinte exemplo em HTML:

<t abl e> <t r > <t d> O meu t ext o. </ t d> </ t r > </ t abl e>

E uma definição de dados em XML:

<t abel a> <l i nha> <col una> O meu t ext o. </ col una> </ l i nha> </ t abel a>

Como podemos observar, a marcação presente no segundo exemplo é muito mais intuitiva para o utilizador. A grande vantagem é que qualquer utilizador, devidamente enquadrado no contexto de utilização do documento, entenderá perfeitamente a sua função tendo uma percepção quase imediata do seu conteúdo. Podemos por exemplo codificar a informação de uma base de dados utilizando tags associadas aos conceitos inerentes a este contexto, como por exemplo, tabela, campo, etc.

Uma vez que a XML é uma linguagem não proprietária e é muito simples de ler e escrever, torna-se logo à partida num excelente formato de troca de dados entre


14

aplicações. Neste sentido bastará apenas seleccionar de um leque de ferramentas aquela que melhor se adequa ao nosso esquema de trabalho, dotando-a de capacidade de entender o formato XML, fazendo o uso correcto do seu conteúdo. O seu grau de flexibilidade é de tal forma elevado que podemos utilizar ferramentas distintas para ver ou editar o conteúdo de um documento. Estes factores são extraordinariamente importantes na comunicação entre plataformas diferentes, quer ao nível dos sistemas quer ao nível de linguagens de programação, componentes, etc.

A linguagem XML é ideal para documentos de tamanho considerável uma vez que a informação se apresenta de forma perfeitamente estruturada. Não só possibilita a especificação de um vocabulário de elementos como também relações entre estes. No exemplo da especificação de uma base de dados, podemos garantir que não faltam campos ou mesmo até fornecer informação por defeito. Além destes factores, a XML possibilita um mecanismo de ligação, do lado do cliente, possibilitando a integração de dados provenientes de várias fontes. Algumas partes da informação poderão mesmo ser omitidas ou não, dependendo das acções levadas a cabo pelo utilizador.


15

Do que já foi abordado até aqui, podemos dizer que a XML é, basicamente, um formato de documento. Existem dois níveis de conformidade no standard XML: documentos bem formados e documentos válidos. A vasta gama de aplicações desta linguagem leva a que não seja apenas necessário entender a forma correcta de escrever um documento que obedeça às normas XML. Será também necessário entender como editar este documento, como é interpretado pelos processadores, como passa informação às aplicações, e como estas podem trabalhar essa informação.

Os documentos XML podem ser criados e alterados com qualquer tipo de editor de texto, desde o Notepad do Windows ao VI do Unix. Existem no entanto editores direccionados para a edição de documentos XML, que facilitam a tarefa ao utilizador por disponibilizarem um conjunto de ferramentas WYSIWG ( What You See Is What You Get ) que se revelam bastante úteis, um deles é por exemplo o XML Spy. Existem no entanto, outros tipos de formas de geração de documentos XML. Algumas aplicações, nomeadamente ligadas às bases de dados, oferecem a possibilidade de gerar documentos com estruturas de informação em formato XML. Um exemplo é o ADO ( ActiveX Data Objects ).

Um processador XML, também conhecido por Parser, lê um documento e verifica se o seu conteúdo está bem formado. Pode ainda verificar se o documento é válido. Assumindo que o documento passa estes testes, é automaticamente convertido numa árvore de elementos.

Os dados provenientes do processador são posteriormente enviados a uma aplicação, que pode ser por exemplo o Mozilla ou outro programa que entenda a informação recebida. Se estivermos na presença de um browser, o conteúdo é apresentado ao utilizador. Note-se no entanto que o conteúdo de um documento XML pode ser interpretado por qualquer aplicação que conheça a forma como este está estruturado, podendo a informação ser apresentada ao utilizador ou simplesmente guardada sob a forma de base de dados.


16

De facto, a melhor forma de entendermos concretamente todo o processo é recorrermos a um pequeno esquema: Um editor gera um documento XML que vai ser interpretado por um browser ou utilizado por uma aplicação, podendo ser enviado ao utilizador ou guardado numa base de dados. É importante entendermos que as pequenas parcelas do processo são completamente independentes. A única interligação existente é o documento XML.

Editor

Documento.xml

Browser ou

Aplicação

Uilizador Ou

Base Dados


17

A linguagem XML não opera sozinha. Usar esta linguagem como algo mais que uma simples formatação de dados exige interacção com outras tecnologias. E é neste contexto que apresentamos alguns conceitos que nos poderão acompanhar sempre que usarmos a XML, concretamente a HTML, a XSL, a XLL, as CSS, os URLs, os URIs e o formato de caracteres Unicode. Muito sucintamente vou fazer uma apresentação de cada uma destas tecnologias.

A HTML ( Hiper-Text Markup Language ), já referida anteriormente, é utilizada no desenvolvimento de conteúdos de páginas para a Internet. Aconselha-se vivamente que o leitor esteja familiarizado com esta linguagem para que possa entender ou migrar para soluções baseadas em XML.

A CSS ( Cascading Style Sheet ), é uma linguagem que foi inicialmente concebida para HTML e que permite a definição de estilos de apresentação. Esses estilos envolvem por exemplo fontes, cores, tamanhos de fontes, entre outros, que podem ser aplicados a determinados elementos. Sempre que um browser recebe informação para apresentar sob a forma XML ou HTML, recebe também a correspondente CSS cujos atributos estão presentes nas tags dos documentos enviados.

A XSL ( Extensible Style Language ), é uma linguagem de especificação de estilos mais avançada que a CSS, e foi concebida especificamente para utilização com a XML. Os documentos XSL são eles próprios, documentos XML bem formados. Os documentos XSL contêm um conjunto de regras que se aplicam a determinados padrões de elementos XML. Um processador XSL lê um documento XML comparando o seu conteúdo com as tags presentes no documento XSL. Sempre que as tags condizem, ou seja, sempre que façam um match, o conteúdo do ficheiro XSL é substituído pela informação delimitada pelas tags XML. Embora as CSSs sejam suportadas por um numero mais elevado de browsers, a XSL é bastante mais flexível e poderosa.


18

Os documentos XML podem existir na Internet da mesma forma que os documentos HTML. Quando assim acontece estes podem ser referenciados através de URLs ( Uniform Resource Locators ), por exemplo: ht t p: / / www. casa. pt / t ext o. xml . Embora os URLs sejam perfeitamente compreendidos e suportados, a XML utiliza mais frequentemente os URIs ( Uniform Resource Identifiers ). Os URIs são uma arquitectura mais genérica par localizar recursos na Internet. Na prática esta tecnologia ainda está em fase de desenvolvimento.

A XLL ( Extensible Link Language ) introduz dois novos conceitos, ou melhor dizendo, estende dois conceitos já em utilização na HMTL. Desde que os documentos XML existam na Internet existe a possibilidade de estabelecer ligações para eles ou entre eles. É possível as utilizar tags de ligação da HTML em documentos XML, bem como constituir ancoras dentro de um documento que permitem navegar para determinadas áreas dentro desse mesmo documento. Em XML existem adicionalmente os conceitos de XPointers e XLinks. Os primeiros permitem não só apontar para um determinado documento presente numa determinada localização mas para também para uma parte em particular dentro de um documento. OS XLinks permitem que qualquer elemento se transforme num link, ao contrário do que acontecia na HMTL em que apenas o elemento <A> identificava uma ligação. Adicionalmente os links podem ser bidireccionais, multi-direccionais ou apontar para vários sites relacionados com a ligação corrente. Os XLinks utilizam URLs.

A Web é puramente internacional, mas no entanto, a maior parte da informação que podemos encontrar está em inglês. A XML, ao disponibilizar o formato Unicode, oferece o suporte de praticamente quase todas as especificações de caracteres internacionais.

A XML, como já referi, define uma gramática baseada em tags que pode ser utilizada para estruturar informação num documento, utilizando por defeito o formato Unicode.


19

Entre outras coisas, um documento XML pode conter ligações em hipertexto para outros documentos e recursos. Estas ligações são especificadas de acordo com o descrito acerca da utilização de URLs e URIs. Quando um documento XML vai ser lido por humanos – o que não é sempre verdade – então a CSS encarrega-se de fornecer informação de apresentação. Outra alternativa, mais poderosa, é a utilização da XSL.


20

Antes de entrarmos em concreto na aprendizagem desta nova tecnologia, convém deixar ao leitor uma imagem da aplicação prática da XML nos nossos dias, por forma a reforçar o incentivo à sua utilização. Cada aplicação XML tem a sua própria sintaxe e vocabulário, perfeitamente enquadrada nas normas definidas pela linguagem. Ao utilizar o formato XML, uma aplicação pode tratar uma grande quantidade de informação recorrendo a um mínimo de processamento em termos de utilização de bibliotecas ou outras ferramentas.

A CML ( Chemical Markup Language ) pode ter sido a primeira aplicação XML. Podemos dizer que a CML resulta da união entre a HTML e “mais algumas moléculas” . Os chamados “documentos moleculares” contêm enormes quantidades de informação relacionados com a área. Mas melhor do que as palavras, aqui fica um exemplo simples, famosamente nosso conhecido como H2O:

<?xml ver si on=” 1. 0” ?> <CML> <MOL TI TLE=” Wat er ” > <ATOMS> <ARRAY BUI LTI N=” ELSYM” >H O H</ ARRAY> </ ATOMS> <BONDS> <ARRAY BUI LTI N=” AT1D1” >1 2</ ARRAY> <ARRAY BUI LTI N=” AT1D2” >2 3</ ARRAY> <ARRAY BUI LTI N=” ORDER” >1 1</ ARRAY> </ BONDS> </ MOL> </ CML>

Estará porventura fora do alcance do leitor entender alguma da notação apresentada se não estiver ligado ao ramo da química, no entanto, o objectivo é apenas ficar com uma ideia duma especificação XML nesta área.

A MML ( Mathematical Markup Language ), é uma outra especificação com base na XML, utilizada no contexto da especificação de equações matemáticas. Para o leitor ter uma ideia do potencial desta especificação, posso adiantar que consegue representar


21

expressões desde o nosso tempo da primária, ou seja, aritmética simples, até a áreas tão vastas como o cálculo diferencial.

A MML ( Music Markup Language ) é uma outra especificação, que como o nome indica está inserida no domínio da música. Inclui descrição de notas, ritmos, claves, acordes e muito mais. Foi desenvolvida, com base nesta especificação, uma aplicação que consegue efectuar um parsing de um documento XML para uma pauta, tal qual nós a conhecemos. Se tivermos em linha de conta que o nível de codificação destes documentos é até bastante simples podemos perspectivar a potencialidade desta especificação e a sua utilização num numero bem alargado de aplicações.

Um senhor de nome Jon Bosak, traduziu obras completas de Shakespeare para XML. Os textos foram integralmente incluídos e as marcações XML foram utilizadas nomeadamente na distinção de títulos, subtítulos, direcções de palco, discursos, etc. O leitor poderá perguntar qual a vantagem de tudo isto para um indivíduo que lê habitualmente. De facto, assim à partida até poderia ser considerado inútil, mas vejamos a perspectiva da leitura por parte de um computador. Imaginemos a facilidade com que se pesquisariam num vasto documento as linhas correspondentes à obra “Romeu e Julieta” , ou ainda como seria simples, por exemplo para um actor, imprimir determinada secção de uma obra que lhe fosse atribuída no decurso de uma representação. Existem muito mais aplicações da linguagem XML igualmente interessantes. Se perdermos um pouco de tempo a pensar, quase que arriscaria a dizer que a sua aplicação se poderá estender a praticamente todas as áreas profissionais e não só, que fazem parte do nosso quotidiano. Só é necessário apelar a nossa imaginação e sentido criativo.

Utilização

A linguagem XML Utilização

23

Neste ponto vou apresentar a criação de um documento simples, desde a definição de tags que façam sentido no contexto de utilização do documento, passando pela criação de uma folha de estilos e finalmente, a forma de enviar o documento para um browser. Penso ser esta a melhor abordagem, ou seja, elaborar algo simples, efectuando o percurso completo desde a criação à utilização em concreto.

Passo a apresentar então um documento XML na sua forma mais simples:

<?xml ver si on=” 1. 0” st andal one=” yes” ?> <mensagem> O meu pr i mei r o document o. </ mensagem>

Não é muito sofisticado mas é um documento XML bem formado ( well-formed ). Poderá escrevê-lo utilizando qualquer tipo de editor de texto, desde que este não grave os documentos num qualquer formato nativo mas apenas como texto simples. Passemos então ao passo seguinte, ou seja, vamos atribuir-lhe um nome para que possa ser gravado, por exemplo documento.xml. Note-se a extensão necessária ( .xml ). Se utilizarmos um browser para visualizar este documento obteremos algo do género da fig.1.

fig.1


24

Agora, o nosso documento tem um aspecto mais inteligível, uma vez que o browser se encarrega de distinguir as diferentes componentes. No entanto, o browser não entende o significado do elemento <mensagem>. Necessitamos então de construir uma CSS, que indique a forma de apresentar esta tag. Antes disso, vamos em primeiro lugar observar mais pormenorizadamente o nosso documento.

A primeira linha, <?xml ver s i on=” 1. 0” st andal one=” yes” ?>, identifica uma instrução de processamento. Estas instruções, encontradas no inicio do documento, estão delimitadas pelos símbolos <? e ?>. A palavra “xml” , identifica o nome da instrução de processamento. A instrução possui ainda outro conceito, o de atributo. Um atributo é uma espécie de constante presente dentro de um elemento. Neste caso temos os atributos ver si on e st andal one, cujos valores são atribuídos através da igualdade presente na instrução. Os valores de um atributo estarão sempre delimitados por aspas ( “ “ ). Obrigatoriamente, qualquer documento XML terá como primeira linha uma instrução deste género, indicando sempre qual a versão em uso. O atributo st andal one, utiliza-se para identificar se este documento está completo ou se existe uma continuidade presente num outro documento. Analisemos agora as restantes linhas:

<mensagem> O meu pr i mei r o document o. </ mensagem>

Em conjunto, estas três linhas formam um elemento, de nome “mensagem”. Todos os elementos possuem uma tag de abertura, <mensagem>, e uma tag de fecho com o mesmo nome antecedido pelo símbolo /, </ mensagem>. Entre as duas tags, inclui-se informação, que poderá ter a forma de texto, como neste caso, ou então surgirá sob a forma de um ou mais elementos.

As tags podem ter três significados distintos: estrutura, semântica e estilo. A primeira organiza a estrutura de um documento em árvore, a segunda relaciona os elementos com informação do mundo real no contexto idealizado pelo autor do documento, e finalmente, a terceira define a forma de apresentação de um elemento ao utilizador, por exemplo num browser.


25

De notar que no nosso exemplo, o nome da tag poderia ser outro qualquer que não “mensagem”, oferecendo total liberdade ao utilizador. O significado das tags será da incumbência da aplicação que irá trabalhar o documento XML, detendo esta o conhecimento necessário para o tratamento do seu conteúdo.

Como já foi referido, um browser não tem como entender o tipo de especificação presente nas tags, uma vez que foram livremente criadas pelo autor do documento. Deste facto surge a necessidade da criação de uma folha de estilos. No contexto das folhas de estilos poderemos optar por uma gama relativamente alargada de soluções, no entanto, utilizaremos neste caso a CSS, por ter sido estabelecida como um standard W3C, e porque provavelmente o leitor já teve um contacto anterior com HTML, não sendo completamente estranho a este conceito. Suponhamos então que queremos criar um estilo de apresentação da nossa mensagem. Para tal criaremos, utilizando por exemplo o mesmo editor de texto do nosso documento XML, um documento ao qual daremos o nome de estilo.css. Saliento mais uma vez a importância da extensão ( .css ). Este nosso documento terá então o seguinte conteúdo:

mensagem { di spl ay: bl ock; f ont - s i ze: 24pt ; f ont - wei ght : bol d; }

Existem várias formas de proceder à interligação entre uma CSS e um documento XML para efeitos de apresentação. No nosso exemplo vamos simplesmente acrescentar mais uma instrução de processamento. O documento passa a ter o seguinte aspecto:

<?xml ver si on=” 1. 0” st andal one=” yes” ?> <?xml - st y l esheet t ype=” t ext / css” hr ef =” est i l o. css” ?> <mensagem> O meu pr i mei r o document o. </ mensagem>

A instrução de processamento acrescentada na segunda linha possui dois atributos, designadamente, t ype e hr ef . O primeiro identifica o tipo de linguagem utilizada, enquanto o segundo é um URL correspondente à localização do nosso documento estilo.css.


26

Em resumo, a instrução de processamento denominada xml - st y l esheet indica que o nosso documento.xml irá usar, para efeitos de apresentação, uma folha de estilos denominada estilos.css. Se voltarmos a abrir o nosso documento num browser obteremos o resultado apresentado na fig.2:

fig.2 Como podemos observar, a aplicação da folha de estilo cumpriu no pleno a sua função, ou seja, conferiu um aspecto diferente ao nosso documento, informando o browser acerca do formato de apresentação. Mais adiante, dedicarei uma atenção mais profunda ao formato das CSSs. Desta forma simples concluímos o processo que decorre desde a criação de um documento XML até à fase final de apresentação ao utilizador.


27

Vou abordar agora um exemplo mais elaborado, por forma a entrarmos no conceito da estruturação de informação num documento XML, quer seja para apresentação num browser, quer para ser tratada por uma outra qualquer aplicação.

A linguagem XML é baseada num modelo de conteúdo hierárquico. Cada elemento XML pode conter texto ou outros elementos, os quais se denominam filhos. Embora possam existir situações em que um elemento pode conter texto e outros elementos, é algo que por norma deve ser evitado uma vez que poderá dar origem a documentos mal formados. Suponhamos então que pretenderíamos organizar informação noticiosa, proveniente de várias áreas. A forma de organizar esta informação será tanto mais importante quanto a utilização que lhe pretendemos conferir. De facto, uma boa estruturação permitirá não só uma fácil compreensão por parte de outros utilizadores, mas facilitará de certa forma a implementação de aplicações que venham posteriormente a manipular esta mesma informação. Outro aspecto importante que devemos levar em linha de conta quando estruturamos a informação relaciona-se com aquilo que pretendemos obter dessa informação, ou seja, que tipos ou formas de processamentos envolverão a sua utilização.

O exemplo que vamos abordar está directamente relacionado com algo que lidamos no nosso dia-a-dia, nomeadamente na Internet. Refiro-me concretamente a informação noticiosa, sob a forma de jornais ou revistas electrónicas. Este exemplo não pretende uma abordagem exaustiva do tratamento deste tipo de informação. Irei apenas elaborar um esquema simples que permita servir o propósito de ajudar o leitor a assimilar de uma forma prática, os conceitos relacionados com a estruturação de dados em XML. O esquema seguinte apresenta apenas alguns itens de informação que pretendemos ver estruturados: Áreas Noticiosas:

� Economia


28

� Cultura � Desporto � Mundo

A essência da informação está sobretudo no conteúdo que pretendemos armazenar. A ideia base deste exemplo será, duma forma simples, apresentar ao utilizador a informação em destaque para um determinado dia, de uma forma organizada, e ao mesmo tempo efectuar uma estruturação de dados que permita a sua utilização por outras aplicações.

Todos os documentos XML obedecem a uma estrutura similar aquela que abordei no nosso primeiro exemplo. Se olharmos para um documento XML sob a forma de uma árvore de informação, facilmente nos aperceberemos do conceito de raiz. Basicamente, a raiz do documento XML é um elemento que conterá todos os outros elementos, ou seja, será o elemento de nível superior, devendo ser único. Indo de encontro ao conceito de documento bem formado ( well-formed document ), todo o documento XML deverá conter obrigatoriamente um elemento raiz. Determinamos que no nosso exemplo, esse elemento terá o nome de “destaques” . Assim o nosso documento terá o seguinte aspecto:

<?xml ver si on=” 1. 0” ?> <dest aques> </ dest aques>

Antes de prosseguirmos vamos apenas frisar alguns aspectos, que embora sejam disponibilizados automaticamente por editores de XML, se revelam bastante importantes no auxilio da leitura do documento. Refiro-me em concreto à forma de indentar a informação, e à sua separação em linhas distintas. Não quer isto dizer que o autor do documento não possa escrevê-lo continuamente ao longo de uma ou mais linhas. Apenas penso que estaremos de acordo que tal facto não será de todo uma boa política. Em termos de nomes atribuídos às tags a serem criadas, adoptarei um esquema baseado em minúsculas, embora esta especificação possa ser perfeitamente arbitrária, desde que para um elemento, a tag inicial tenha exactamente a mesma notação que a tag final. A informação que pretendemos estruturar já está dividida em áreas de interesse, e como tal poderemos logo à partida definir essas áreas:


29

<?xml ver si on=” 1. 0” ?> <dest aques> <economi a> </ economi a> <cul t ur a> </ cul t ur a> <despor t o> </ despor t o> <mundo> </ mundo> </ dest aques>

Cada uma das áreas está assim delimitada pela sua tag inicial e pela sua tag final, identificada com o símbolo /. Observe-se também que o elemento <dest aques>, que definimos como sendo o nosso elemento raiz, envolve todos os outros. Analisando cada uma das áreas, poderemos identificar algumas diferenças relativamente à informação que pretendemos apresentar. Vamos supor que na área de Economia, apenas apresentaremos um conjunto de noticias soltas podendo construir a sua estrutura da seguinte forma:

<?xml ver si on=” 1. 0” ?> <dest aques> <economi a> <not i ci a> <codi go>1</ codi go> <t i t ul o>Ti t ul o 1</ t i t ul o> <sumar i o>Sumar i o 1</ sumar i o> </ not i c i a> <not i ci a> <codi go>2</ codi go> <t i t ul o>Ti t ul o 2</ t i t ul o> <sumar i o>Sumar i o 2</ sumar i o> </ not i c i a> </ economi a> <cul t ur a> </ cul t ur a> <despor t o> </ despor t o> <mundo> </ mundo> </ dest aques>

Como podemos observar dentro do elemento <economi a>, surgem vários elementos do mesmo tipo, identificados com o nome “noticia” , que contêm informação acerca do código, titulo e sumário de uma determinada noticia ( poderíamos ter muito mais informação, como é óbvio ).


30

A área Cultural, poderá no entanto aumentar o nível de especificação, introduzindo uma subdivisão noticiosa em, por exemplo, Cinema e Teatro. Vejamos como ficaria organizada a informação:

<?xml ver si on=” 1. 0” ?> <dest aques> <economi a> <not i ci a> <codi go>1</ codi go> <t i t ul o>Ti t ul o 1</ t i t ul o> <sumar i o>Sumar i o 1</ sumar i o> </ not i c i a> <not i ci a> <codi go>2</ codi go> <t i t ul o>Ti t ul o 2</ t i t ul o> <sumar i o>Sumar i o 2</ sumar i o> </ not i c i a> </ economi a> <cul t ur a> <ci nema> <not i c i a> <codi go>1</ codi go> <t i t ul o>Ti t ul o 1</ t i t ul o> <sumar i o>Sumar i o 1</ sumar i o> </ not i ci a> <not i c i a> <codi go>2</ codi go> <t i t ul o>Ti t ul o 2</ t i t ul o> <sumar i o>Sumar i o 2</ sumar i o> </ not i ci a> </ c i nema> <t eat r o> <not i c i a> <codi go>1</ codi go> <t i t ul o>Ti t ul o 1</ t i t ul o> <sumar i o>Sumar i o 1</ sumar i o> </ not i ci a> </ t eat r o> </ cul t ur a> <despor t o> </ despor t o> <mundo> </ mundo> </ dest aques>

Obedecendo à mesma estrutura utilizada na área de Economia, foram incluídos elementos <noticia> para identificar a informação. Note-se também que a nossa estrutura hierárquica desceu um nível para identificar as duas novas áreas dentro da área de Cultura. Seguindo o mesmo raciocínio para as outras áreas, observemos um aspecto final do documento:


31

<?xml ver si on=” 1. 0” ?> <dest aques> <economi a> <not i ci a> <codi go>1</ codi go> <t i t ul o>Ti t ul o 1</ t i t ul o> <sumar i o>Sumar i o 1</ sumar i o> </ not i c i a> <not i ci a> <codi go>2</ codi go> <t i t ul o>Ti t ul o 2</ t i t ul o> <sumar i o>Sumar i o 2</ sumar i o> </ not i c i a> </ economi a> <cul t ur a> <ci nema> <not i c i a> <codi go>1</ codi go> <t i t ul o>Ti t ul o 1</ t i t ul o> <sumar i o>Sumar i o 1</ sumar i o> </ not i ci a> <not i c i a> <codi go>2</ codi go> <t i t ul o>Ti t ul o 2</ t i t ul o> <sumar i o>Sumar i o 2</ sumar i o> </ not i ci a> </ ci nema> <t eat r o> <not i c i a> <codi go>1</ codi go> <t i t ul o>Ti t ul o 1</ t i t ul o> <sumar i o>Sumar i o 1</ sumar i o> </ not i c i a> </ t eat r o> </ cul t ur a> <despor t o> <f ut ebol > <pr i mei r a_l i ga> <not i c i a> <codi go>1</ codi go> <t i t ul o>Ti t ul o 1</ t i t ul o> <sumar i o>Sumar i o 1</ sumar i o> </ not i c i a> </ pr i mei r a_l i ga> </ f ut ebol > <basket bal l > <not i c i a> <codi go>2</ codi go> <t i t ul o>Ti t ul o 2</ t i t ul o> <sumar i o>Sumar i o 2</ sumar i o> </ not i ci a> </ basket bal l > </ despor t o> <mundo> <pai s> <nome>Nome pai s</ nome> <not i c i as> <not i c i a> <codi go>1</ codi go> <t i t ul o>Ti t ul o 1</ t i t ul o> <sumar i o>Sumar i o 1</ sumar i o> </ not i c i a>


32

<not i c i a> <codi go>2</ codi go> <t i t ul o>Ti t ul o 2</ t i t ul o> <sumar i o>Sumar i o 2</ sumar i o> </ not i c i a> </ not i ci as> </ pai s> </ mundo> </ dest aques>

Da observação do documento final ficamos com uma ideia da complexidade e ao mesmo tempo da flexibilidade que existe em termos de descrição da informação, a níveis distintos, organizados num ou mais documentos, de acordo com a envergadura que pretendemos ver estruturada. De notar ainda que a estruturação de informação, embora deva obedecer a algumas normas já anteriormente referidas, deve-se pautar pelo intuito da utilização que lhe vai ser atribuída, ficando à responsabilidade do autor do documento a sua correcta organização.

Do conjunto de vantagens decorrentes da utilização deste formato destaco as seguintes:

� A informação está auto-descrita; � Os dados podem ser manipulados recorrendo a diversas ferramentas; � Os dados podem ser visualizados recorrendo a diversas ferramentas; � É possível criar várias formas de utilização recorrendo ao uso de folhas de estilo.

Com efeito, a informação, ao ser delimitada por tags fica automaticamente descrita pelo nome das próprias tags, sendo o seu significado inerente. A manipulação e tratamento da informação pode ser efectuada pelas mais diversas ferramentas. No exemplo que apresentamos, as tags de nome “codigo” podem constituir uma fonte de informação importante no caso do documento ser “ trabalhado” por uma aplicação. Um aumento de informação deste tipo, embora possa dilatar o tamanho do documento, constitui uma forte base de flexibilidade em termos de leitura da informação. A facilidade de edição de texto em qualquer editor normal é sem duvida uma mais valia na construção de documentos XML. A apresentação de informação recorrendo a várias ferramentas, como por exemplo a especificação de formatos usando CSSs, permite o alargamento dos horizontes em termos do processamento em browsers. O leitor poder-se-á questionar acerca do tamanho destes documentos em termos de ocupação de recursos físicos, como por exemplo espaço em disco. No entanto, alguns


33

testes efectuados, comprovaram o elevado grau de compressão associado a documentos deste tipo, que normalmente ronda os 90%. A acrescentar a este facto, observamos hoje em dia que a maior parte dos servidores HTTP avançados envia a informação de forma comprimida por forma a garantir um aproveitamento mais eficiente da largura de banda disponível.


34

Neste ponto vou fazer uma abordagem mais aprofundada aos itens que constituem a estrutura XML, designadamente à relação de opção de utilização entre atributos e elementos e a outra forma de representação de tags.

Como vimos no exemplo anterior, a estruturação da informação foi completamente efectuada recorrendo à utilização de elementos. Existem no entanto outras formas de abordagem que podem complementar esta, refiro-me à representação de informação sob a forma de atributos. Alguns autores defendem que este tipo de abordagem não deve ser utilizado, ou seja, toda e qualquer informação deveria sempre ser representada sob a forma de elementos. No entanto, reconhece-se o interesse da utilização de atributos. Observando a linguagem HTML, certamente nos recordaremos que grande parte do seu conjunto de tags recorre a este conceito. Consideremos por exemplo a tag <IMG>:

<i mg sr c=embl ema. gi f wi dt h=100 hei ght =80 al t =Home Page>

Neste exemplo, a tag possui quatro atributos, sr c, wi dt h, hei gt h e al t . Se quiséssemos transformar este código para XML teríamos de efectuar algumas alterações, em concreto, apenas duas:

<i mg sr c=” embl ema. gi f ” wi dt h=” 100” hei ght =” 80” al t =” Home Page” ></ i mg>

Seria necessário incluir o conteúdo de cada atributo entre aspas (“ “ ) e fechar a tag <i mg> com a tag terminadora de elemento, </ i mg>. Note-se entretanto que em XML simples, a tag <i mg> não detém qualquer significado para um browser. Vamos então efectuar algumas alterações no documento ( em formato reduzido ) do segundo exemplo por forma a exemplificar na prática uma utilização efectiva do conceito de atributo.

<?xml ver si on=” 1. 0” ?> <dest aques> <economi a> <not i ci a codi go=” 1” dat a=” 12- 04- 2001” > <t i t ul o>Ti t ul o 1</ t i t ul o> <sumar i o>Sumar i o 1</ sumar i o>


35

</ not i c i a> <not i ci a codi go=” 2” dat a=” 15- 04- 2001” > <t i t ul o>Ti t ul o 2</ t i t ul o> <sumar i o>Sumar i o 2</ sumar i o> </ not i c i a> </ economi a> <mundo> <pai s nome=” Nome do pai s” > <not i c i as> <not i c i a codi go=” 1” dat a=” 10- 04- 2001” > <t i t ul o>Ti t ul o 1</ t i t ul o> <sumar i o>Sumar i o 1</ sumar i o> </ not i c i a> <not i c i a codi go=” 2” dat a=” 10- 04- 2001” > <t i t ul o>Ti t ul o 2</ t i t ul o> <sumar i o>Sumar i o 2</ sumar i o> </ not i c i a> </ not i c i as> </ pai s> </ mundo> </ dest aques>

As transformações efectuadas, assinaladas a bold, reflectem exemplos duma possível utilização de atributos. O elemento <codi go> foi substituído pelo respectivo atributo com o mesmo nome e valor, e foi ainda acrescentado um outro, a data da noticia, por ser interessante, por exemplo, informar o utilizador que uma noticia, embora em destaque numa determinada data, ter tomado lugar numa data anterior. Foi também feita uma substituição idêntica para o elemento <pai s>.

Apesar de tudo, não existem regras que restrinjam a utilização de atributos ou elementos. Regra geral segue-se o caminho mais lógico na codificação de um documento, contextualizando a sua utilização. Uma abordagem interessante refere-se a codificar como elemento informação que consista em dados, e como atributo, informação acerca desses dados, vulgarmente designada como meta-dados. Basicamente distinguiríamos a segunda como informação que apenas é utilizada internamente pelas aplicações que processam o documento, não sendo portanto apresentada ao utilizador. No nosso exemplo, seria o caso do código da notícia. Poderão, como é evidente, ocorrer ao leitor outros tipos de abordagens igualmente lógicas, mas devemos sempre ter cuidado na informação que seleccionamos para codificar como atributo. Seria completamente incorrecto, por exemplo, codificar os elementos <not i ci a> como atributos, uma vez que a sua representação surge de forma indeterminada em termos de numero, acrescendo o facto de eles próprios conterem elementos filho.


36

Referindo novamente a transformação efectuada no nosso exemplo, poderíamos concluir que talvez não fosse muito correcto, dependendo do contexto, representar a data como um atributo. Poderia ser necessário distinguir as suas três componentes ( dia, mês, ano ), e neste caso, seria mais lógico um elemento do género:

<?xml ver si on=” 1. 0” ?> <dat a> <ano>2001</ ano> <mes>Abr i l </ mes> <di a>12</ di a> </ dat a>

A utilização de atributos pode ser conveniente na representação de informação não estruturada. Quando tal acontece não será necessária a utilização de elementos filho. No entanto, o tempo de vida de um documento pode conduzir à necessidade de acrescentar informação e por vezes a nossa representação em atributo pode comprometer esta necessidade. Vejamos o exemplo da representação da noticia. Resumidamente, a representação adoptada foi a seguinte:

<?xml ver si on=” 1. 0” ?> <not i ci a codi go=” 1” > <t i t ul o>Ti t ul o da not i c i a</ t i t ul o> <sumar i o>Sumar i o da not i c i a</ sumar i o> </ not i c i a>

A determinada altura resolvemos acrescentar a informação relativa ao seu Autor, através de um atributo:

<?xml ver si on=” 1. 0” ?> <not i ci a codi go=” 1” aut or =” Nome do Aut or ” > <t i t ul o>Ti t ul o da not i c i a</ t i t ul o> <sumar i o>Sumar i o da not i ci a</ sumar i o> </ not i c i a>

Imaginemos agora, um documento bastante mais elaborado, com grandes quantidades de informação. Surge então a necessidade, por exigências de apresentação de informação ao utilizador final, de distinguir o primeiro e ultimo nome do autor. Se o documento ou documentos que possuem este tipo de estrutura estiverem a ser processados por uma aplicação que “conhece” a hierarquia de especificação, torna-se complicado transformar um atributo em elementos filho, sem efectuar alterações de vulto nessa aplicação. A representação correcta da informação deveria corresponder a algo do género:


37

<?xml ver si on=” 1. 0” ?> <not i ci a codi go=” 1” > <t i t ul o>Ti t ul o da not i c i a</ t i t ul o> <sumar i o>Sumar i o da not i c i a</ sumar i o> <aut or > <pr i mei r o_nome>Nome</ pr i mei r o_nome> <ul t i mo_nome>Ul t i mo Nome</ ul t i mo_nome> </ aut or > </ not i c i a>

Outro facto que devemos considerar é o de existirem vários autores da mesma noticia, o que aumenta o “peso” da decisão de representação da informação através de elementos. Sem duvida que a utilização de elementos em vez de atributos se revela quase sempre bastante mais vantajosa, e em caso de dúvida, deve ser a solução adoptada. As vantagens, como o leitor pode observar nos exemplos anteriores, relacionam-se sobretudo com a facilidade que existe em acrescentar mais informação aos documentos, e transformar a hierarquia ou proceder à sua reorganização através da expansão de elementos filho. Apesar de a maioria dos factores apontarem na direcção do conceito de elemento, existem casos em que a utilização dos atributos é também inequívoca. Estes casos formam o conjunto de informação simples acerca de um documento que permanecerá imutável ao longo da sua existência. Temos como forte exemplo deste caso, os atributos da já mencionada tag <IMG>. Neste caso, a variação da imagem a representar implicará a variação do seu tamanho em termos de altura e largura, ou seja, a alteração do conteúdo dos atributos wi dt h e hei ght , enquanto que a sua forma de representação permanecerá imutável. Outros aspectos que favorecem a utilização de atributos estão relacionados com a extensão em XML da linguagem HTML, e com a consequente representação de estilos dentro de determinadas tags, como por exemplo:

<t i t ul o st y l e=” f ont - st y l e: i t al i c” >Ti t ul o</ t i t ul o>

Esta extensão é importante por um lado, em termos de manutenção de compatibilidade com browsers mais antigos, e por outro, ajudando os utilizadores para a linguagem XML.

Já foram referidos praticamente todos os aspectos que se revelam importantes nesta componente da linguagem XML. Falta apenas acrescentar m pormenor que terá grande utilidade quando abordarmos a linguagem XSL. Refiro-me em concreto à utilização de tags sem conteúdo ou vazias.


38

De facto, não é necessário que um elemento, delimitado pelas respectivas tags, possua conteúdo. Podemos simplesmente representar a informação em atributos, embora, como já tivemos a oportunidade de verificar, esta não seja uma boa abordagem.

<not i ci a codi go=” 1” aut or =” Nome aut or ” t i t ul o=” Ti t ul o da not i c i a” ></ not i c i a>

Como podemos verificar, o conteúdo deste elemento está totalmente representado sob a forma de atributos. Uma representação mais “avançada” deste elemento seria:

<not i ci a codi go=” 1” aut or =” Nome aut or ” t i t ul o=” Ti t ul o da not i c i a” / >

A ausência de conteúdo permite a supressão da tag terminadora através da inclusão da barra ( / ), no final da especificação do elemento. Este tipo de representação poderia ser utilizada no nosso segundo exemplo. Recordemos o seu formato inicial:

<?xml ver si on=” 1. 0” ?> <dest aques> <economi a> </ economi a> <cul t ur a> </ cul t ur a> <despor t o> </ despor t o> <mundo> </ mundo> </ dest aques>

Com esta nova facilidade ficaria representado:

<?xml ver si on=” 1. 0” ?> <dest aques> <economi a/ > <cul t ur a/ > <despor t o/ > <mundo/ > </ dest aques>

De facto, obtivemos uma representação mais simples e até mais intuitiva. Para resumir podemos então dizer que um elemento sem conteúdo do tipo <not i ci a></ not i c i a>, pode simplesmente ser representado por <not i ci a/ >.


39

Na continuidade do que abordei no ponto anterior, pode dizer-se que os atributos de um documento, após a aplicação de uma folha de estilos ( CSS ), deixam de ser visualizados. Tal facto deve-se a que a CSS é apenas aplicada sobre o conteúdo de um documento e não sobre os seus atributos. Quando utilizamos uma CSS, qualquer tipo de informação que desejemos ser visualizada pelo utilizador, deve estar representada num documento XML sob a forma de conteúdo e não sob a forma de atributos. É precisamente no contexto desta limitação que surge uma alternativa à CSS, ou seja, a XSL. A XSL é uma linguagem que permite, além da informação de conteúdo, apresentar a informação descrita como atributo. Totalmente suportada pelos browsers actuais, esta linguagem está dividida em duas secções: formatação e transformação. A formatação define a apresentação de documentos como páginas de um browser, de forma versátil e poderosa, que abrange todos os tipos de representação gráfica de informação já conhecidos na linguagem HTML, desde fontes, tabelas, e muito mais. A transformação permite a substituição de tags por conteúdos ou outras tags. É possível definir regras que substituem tags XML com representações HTML, incluído as formatações CSS. Pode ainda ser acrescentado conteúdo a um documento, de forma completamente dinâmica. Farei agora uma abordagem simples desta linguagem, focando os aspectos fundamentais que permitam compreender o seu modo de operação. Após o leitor se ter integrado na filosofia da sua utilização, procederei a um aprofundamento, em pontos posteriores.

Uma folha de estilo XSL contém templates que serão a base de representação para os conteúdos XML. Um template pode ser algo semelhante ao seguinte:

<xsl : t empl at e mat ch=” / ” > <ht ml > <head> <t i t l e> Conj unt o de i nst r uções XSL par a obt er o t i t ul o pr i nci pal . </ t i t l e> <h1>Conj unt o de i nst r uções XSL par a obt er o t i t ul o secundár i o. </ h1> </ head> <body> Conj unt o de i nst r uções XSL par a obt er i nf or mação adi c i onal .


40

<body> </ ht ml > </ xsl : t empl at e>

Neste exemplo, os conteúdos assinalados a bold seriam substituídos por elementos XSL que acrescentariam informação ao documento. Esta informação estaria presente num documento XML semelhante aos que tenho apresentado nos exemplos até aqui. O conceito de template em XSL representa a possibilidade de reutilização sobre inúmeras formas de estruturação de informação. O exemplo do quadro anterior poderia ser aplicado a diferentes documentos XML, que possuíssem informação susceptível de ser interpretada ou representada da forma descrita pelo template. Resumidamente, um folha de estilo XSL, é um documento que possuirá ( embora não obrigatoriamente ) uma parte do código baseado em instruções HTML, que conjuntamente com instruções XSL, formará uma página de apresentação num browser. Estas instruções XSL, confrontadas com um documento XML, encarregar-se-ão, através de um mecanismo de matching, de preencher a informação a ser apresentada. Para melhor percepção do leitor, vou apresentar um exemplo prático, bastante simples. Observemos então o nosso documento XML ( em formato reduzido ) contendo informação noticiosa:

<?xml ver si on=” 1. 0” ?> <dest aques> <economi a> <not i ci a codi go=” 1” dat a=” 12- 04- 2001” > <t i t ul o>Ti t ul o 1</ t i t ul o> <sumar i o>Sumar i o 1</ sumar i o> </ not i c i a> <not i ci a codi go=” 2” dat a=” 15- 04- 2001” > <t i t ul o>Ti t ul o 2</ t i t ul o> <sumar i o>Sumar i o 2</ sumar i o> </ not i c i a> </ economi a> </ dest aques>

Vamos então construir uma folha de estilo XSL capaz de apresentar esta informação ao utilizador, sob um determinado formato HTML, suportado por um browser.

<?xml ver si on=” 1. 0” ?> <xsl : st y l esheet xml ns: xsl =” ht t p: / / www. w3. or g/ TR/ WD- xsl ” > <xsl : t empl at e mat ch=” / ” > A i nf or mação HTML sur gi r á nest e l ocal . </ xsl : t empl at e> </ xsl : s t y l esheet >


41

Este exemplo não só é uma folha de estilo XSL, como deverá obrigatoriamente ser também um documento XML bem formado. Dos conceitos que apresentei até aqui podemos deduzir que, o documento XSL se inicia com uma instrução de processamento, em tudo igual a um documento XML normal. O elemento raiz está identificado por <xsl : st y l esheet >, e indica a descrição de uma folha de estilos em formato XSL. Por fim, esta folha de estilos contém um ou mais templates XSL, que serão sempre representados por um elemento do tipo <xsl : t empl at e>. Este elemento contém um atributo mat ch que indica a sua área de acção ( matching ) sobre um documento XML, e envolverá um conjunto de instruções HTML. Ao ler um documento XML que referenciasse esta folha de estilos, à qual poríamos o nome de folha.xsl, realçando novamente a extensão obrigatória ( .xsl ), o browser iria tentar aplicar, todas as ocorrências de elementos <xsl : t empl at e>. Neste caso, seria percorrido todo o documento XML, uma vez que o atributo do elemento <xsl : t empl at e>

tentará fazer o match com a raiz, representada por “ /” . No decurso desta operação iria ser transformada a informação encontrada, sendo inserida dinamicamente na folha de estilos de acordo com as instruções de transformação XSL. Como o nosso exemplo não possui ( ainda ) este tipo de instruções, apenas seria transportado para o browser o conteúdo representado por instruções HTML. Para estabelecer uma ligação entre a nossa folha de estilos e o documento XML que contém a informação, será necessário acrescentar a este último a seguinte instrução:

<?xml ver si on=" 1. 0" ?> <?xml - st y l esheet t ype=" t ext / xsl " hr ef =" f ol ha. xsl " ?> <dest aques> <economi a> <not i c i a codi go=" 1" dat a=" 12- 04- 2001" > <t i t ul o>Ti t ul o 1</ t i t ul o> <sumar i o>Sumar i o da not i ci a numer o 1. </ sumar i o> </ not i c i a> <not i ci a codi go=" 2" dat a=" 15- 04- 2001" > <t i t ul o>Ti t ul o 2</ t i t ul o> <sumar i o>Sumar i o da not i ci a numer o 2. </ sumar i o> </ not i c i a> </ economi a> </ dest aques>

A linha acrescentada, destacada a bold, funciona de forma idêntica ao que já tinha sido abordado em relação à aplicação de CSSs, apenas variando o valor do atributo t ype, deixando de ser “ t ext / css” , para passar a ser “ t ext / xs l ” . Está assim criado o relacionamento entre os dados e a apresentação, com a vantagem de se representarem em documentos distintos e independentes.


42

Vou agora incluir na folha de estilos o código necessário para integrar a informação que irá ser recolhida deste documento XML e apresentada ao utilizador sob a forma de página de um browser:

<?xml ver si on=" 1. 0" ?> <xsl : st y l esheet xml ns: xsl =" ht t p: / / www. w3. or g/ TR/ WD- xsl " > <xsl : t empl at e mat ch=" / " > <ht ml > <t abl e> <t r > <t d col span=" 2" ><h1>Not i ci as em Dest aque</ h1></ t d> </ t r > <t r > <t d><h2>Economi a</ h2></ t d> <t d></ t d> </ t r > <xsl : appl y- t empl at es sel ect =" dest aques/ economi a" / > </ t abl e> </ ht ml > </ xsl : t empl at e> <xsl : t empl at e mat ch=" economi a" > <xsl : f or - each sel ect =" not i c i a" > <t r ><t d hei ght =" 30" ></ t d></ t r > <t r > <t d al i gn=" cent er " ><i ><xsl : val ue- of sel ect =" @dat a" / ></ i ></ t d> <t d><h3><xsl : val ue- of sel ect =" t i t ul o" / ></ h3></ t d> </ t r > <t r > <t d></ t d> <t d><xsl : val ue- of sel ect =" sumar i o" / ></ t d> </ t r > </ xsl : f or - each> </ xsl : t empl at e> </ xsl : s t y l esheet >

Neste momento, o leitor familiarizado com a linguagem HTML, encontrará por certo algumas porções de código perceptíveis, mas antes de fazer uma abordagem ao exemplo, observemos o resultado da invocação do documento XML que ligamos a esta folha de estilos, num browser:


43

fig.3 Introduzindo agora uma abordagem diferente acerca do modo de operação de um documento XSL, podemos dizer que as suas instruções navegam na informação contida num documento XML da mesma forma que um utilizador navega na estrutura hierarquizada em pastas ( folders ) de uma directoria de um disco. Como já vimos, existe o conceito de raiz e de elementos filho, da mesma forma que existe a raiz de uma directoria e as pastas contidas nesse directoria. Utilizando instruções XSL é possível efectuar uma navegação, de certa forma semelhante à que efectuariamos num sistema DOS ou UNIX. Observemos então de que forma. Na folha de estilos existem dois templates, um que se encarrega de tratar a raiz do documento XML e outro, do seu elemento “economia” ( contido no elemento “destaques” ), como podemos deduzir do conteúdo dos atributos match. O primeiro template, identificado por <xsl : t empl at e mat ch=” / ” >, contém a estrutura principal da página, definida em HTML, e ainda uma instrução <xsl : appl y- t empl at es

sel ect =” dest aques/ economi a” >, cuja função é aplicar um template onde o atributo match refira o elemento “economia” . Após encontrado esse template serão processadas as instruções XSL definidas no seu interior.


44

Essas instruções, <xsl : f or - each sel ect =” not i ci a” > e <xsl : val ue- of sel ect =” . . . ” >, encarregam-se respectivamente de percorrer todos os elementos “noticia” dentro do elemento “economia” e retirar a informação referente aos elementos “ titulo” e “sumario” , e do atributo “data” . Este procedimento reflecte assim a informação para dentro da estrutura HTML, que no seu conjunto constrói a página observada na fig.3. Como facilmente se pode observar, as instruções XSL obedecem à mesma notação de tags já referida na descrição dos documentos XML. Todas as instruções terão uma tag inicial “<xsl:” e uma tag final “</xsl:” , seguidas do comando XSL respectivo com a sintaxe apropriada.

Sem duvida que a XSL é bem mais poderosa que a CSS, no entanto este poder é igualado pela sua complexidade. Por agora procurei apenas efectuar uma abordagem introdutória. À medida que aprofundamos as capacidades desta linguagem e tomamos contacto com a sua versatilidade e capacidade de “ trabalhar” a informação também nos deparamos com algumas estruturas, que nos levam a pensar por qual optar. Embora o leitor possa estar, talvez, familiarizado com as CSSs, por utilização da linguagem HTML, já aqui foram apresentados alguns pontos a favor da XSL. Volto a relembrar aqueles que considero serem cruciais, atendendo à evolução do conceito Internet, da programação que lhe está associada, e das crescentes tecnologias que emergem neste sentido:

� A facilidade de aceder à informação presente não só em elementos, mas também em atributos;

� O facto de separar a informação, ou seja, os dados, de tudo o resto que está relacionado com a apresentação da página;

� O conjunto XML+XSL permite a separação entre documentos de dados e páginas Internet;

� Os documentos gerados neste conjunto, são mais fáceis de manter e manipular; � É sem duvida a escolha acertada para aplicações de grande volume de dados.


45

Embora a linguagem XML ofereça completa liberdade aos autores dos documentos, através da criação das tags de que necessitam para representar a informação, existe um conjunto de regras, não arbitrárias, sobre as quais um documento XML deve assentar por forma a poder ser interpretado pelos browsers ou outras aplicações com capacidade de o fazer. Um documento que obedeça a estas regras será denominado de “documento bem formado” ( well-formed document ). Este ponto pretende fazer uma abordagem ao conjunto de regras necessário para que seja conferida esta classificação a um documento.

Um documento XML contém texto que representa informação e texto que representa marcações ou tags. Este documento, pode ser guardado numa base de dados, pode simplesmente residir em memória ou resultar da combinação de outros documentos. Alguns dos conceitos que envolvem a constituição de um documento XML foram já mencionados anteriormente, no entanto, vou aproveitar para relembrar o leitor desta constituição e acrescentar-lhe mais alguns conceitos importantes.

Esta linguagem, identificada pelas nossas já conhecidas tags, permite a demarcação de dados compreendidos em elementos estruturados. Por seu turno, a informação presente nestes elementos pode ainda ser acrescida pela inclusão de atributos caracterizadores dos mesmos. Assim podemos dizer que um elemento contém informação, ou outros elementos, delimitada por tags, as quais podem ainda conter atributos. Uma característica do XML é que distingue perfeitamente a sua linguagem de marcação dos dados do documento.


46

À semelhança do que acontece na linguagem HTML, podemos incluir comentários no texto que constitui um documento, da seguinte forma:

<?xml ver si on=” 1. 0” ?> <i nf or macao> <not i c i a> <! - - Est e é o coment ár i o à not i c i a do document o- - > <t i t ul o>Ti t ul o 1</ t i t ul o> <sumar i o>Sumar i o 1</ sumar i o> </ not i c i a> <! - - <not i c i a> <t i t ul o>Ti t ul o 1</ t i t ul o> <sumar i o>Sumar i o 1</ sumar i o> </ not i c i a> - - > </ i nf or macao>

Os comentários são sempre delimitados pela notação de inicio <! - - e fim - - > de comentário, e podem envolver uma ou mais linhas, como podemos observar no exemplo. Devemos ter alguns cuidados na sua utilização, nomeadamente não os incluir dentro de tags e não usar a notação “--“no seu interior.

Como o leitor provavelmente já deve ter reparado, existem caracteres que são reservados à notação XML, como por exemplo os símbolos “<” e “>” para os quais deveremos utilizar uma notação alternativa sempre que quisermos incluí-los num documento XML. A tabela seguinte apresenta alguns desses exemplos:

Referência Caracter

& & &l t ; < &gt ; >

&quot ; “ ' ‘

Como facilmente podemos observar, a representação alternativa obedecerá sempre à sintaxe & descr ição_do_caracter ;. Existem muito mais caracteres que podem ser representados desta forma, nomeadamente os referentes à acentuação na língua


47

portuguesa. O leitor verá a sua tarefa facilitada se utilizar editores vocacionados para XML, que oferecem tabelas bastante completas contendo esta informação. A utilização destes caracteres deve ser utilizada sempre que necessário, de acordo com o contexto, uma vez que a ausência da sintaxe descrita fará com que o browser interprete o caractere como parte da linguagem de marcação, podendo, inadvertidamente, dar origem a documentos mal formados. Eis um exemplo da sua utilização:

<?xml ver si on=” 1. 0” ?> <empr esa> <nome>&quot ; Ant er o & Companhi a&quot ; </ nome> </ empr esa>

Da notação utilizada surgiria o nome descrito pelo respectivo elemento, “Antero & Companhia” .

Até aqui sempre assumi-mos que tudo o que está dentro dos símbolos “<” e “>” corresponde a linguagem de marcação, e tudo o resto são dados. Existe no entanto uma excepção, os blocos CDATA. Todo e qualquer conteúdo presente num bloco deste tipo não será alvo de qualquer tipo de interpretação. Assim, sempre que pretendermos que uma porção de texto seja entendida tal qual está escrita, mesmo contendo caracteres reservados dos tipos já referidos no ponto anterior. Estes blocos são particularmente úteis quando pretendermos que um dado documento possua instruções noutras linguagens como por exemplo Java ou C. Outro exemplo de utilização é aquilo que o leitor pode observar neste manual. Suponhamos que o traduziria completamente para XML, deveria incluir em blocos CDATA todos os exemplos relativos à linguagem.Vejamos um exemplo:

<?xml ver si on=” 1. 0” st andal one=” yes” ?> <codi go_exempl o> <! [ CDATA[ <?xml ver s i on=” 1. 0” st andal one=” yes” ?> <mensagem> O meu pr i mei r o document o. </ mensagem> ] ] > </ codi go_exempl o>


48

O código em itálico não seria interpretado. A sintaxe é bastante simples, como aliás se depreende do exemplo: <! [ CDATA[ Text o do

ut i l i zador ] ] >. Como seria de esperar, não é possível incluir no texto a simbologia que termina a sintaxe da instrução CDATA, ou seja, “ ]]>” . Embora este tipo de instrução não seja utilizada com muita frequência, podem surgir alguns casos em que tal se justifique, e não existe alternativa melhor, uma vez que utilizar a simbologia do ponto anterior se revelaria uma tarefa árdua.

A grande componente da linguagem de marcação são sem duvida as tags. Embora já tivesse abordado este item da linguagem, vou aproveitar para cimentar um pouco mais o conhecimento do leitor. Basicamente, as tags são tudo o que começa pelo símbolo “<” e termina no símbolo “>” , desde que não esteja contido dentro dum bloco CDATA. A acrescentar, podemos dizer que esta notação obedece à sintaxe presente na linguagem HTML, ou seja, as tags de abertura começam pelo símbolo “<” e as tags de fecho, pelo símbolo “</” , ambos seguidos pelo nome da tag. O primeiro símbolo “>” encontrado, fecha a tag. Os nomes das tags devem sempre começar por uma letra ou por um símbolo “_” ( underscore ). Eis alguns exemplos:

Correctos Incorrectos <HELP> <Li vr o> <vol ume> <cabeçal ho1> <seccao. par agr af o> <t ext o_cont i nuo> <_1oCapi t ul o>

<Li vr o%7> <vol ume 1> <1oCapi t ul o>

Como já referi, as tags de fecho conterão sempre o mesmo nome das respectivas tags de abertura, por exemplo:

<t ext o>Text o do meu document o i ni c i al . </ t ext o>

Os nomes das tags obedecem ao tipo de capitalização utilizada, ou usando o termo técnico, são case sensitive. Para terminar relembro a possibilidade da utilização de tags vazias ou sem conteúdo, por exemplo <t ext o></ t ext o>, ou simplesmente <t ext o/ >. No entanto, devemos ter em atenção a utilização da segunda notação, uma vez que alguns browsers revelam


49

comportamentos inconsistentes na sua interpretação. Por questões de segurança, aconselho a utilização da primeira notação.

Atributos são constantes presentes dentro de tags. Esses atributos recebem o seu valor sempre contido entre aspas ( “valor” ), como demonstra o exemplo seguinte:

<?xml ver si on=” 1. 0” ?> <empr esa codi go=” 129” > <nome>Nome da Empr esa</ nome> </ empr esa>

Os nomes dos atributos obedecem exactamente às mesmas regras aplicadas em relação aos nomes das tags. Como é óbvio, não poderão existir dentro da mesma tag atributos com o mesmo nome. Como os valores dos atributos têm sempre o formato de texto, o utilizador deve ter em conta que no caso do processamento de atributos numéricos, por parte de uma aplicação, estes devem ser convertidos para números. Não existem limitações na atribuição de valores a atributos, no entanto devemos ter cuidado quando pretendemos utilizar os símbolos “ ou ‘ . Na maior parte das vezes o método mais seguro será substitui-los pelas referências apresentadas no ponto 10.1.5.. No caso de pretendermos usar aspas ( “ “ ) no valor do atributo este deve ser delimitado por pelicas ( ‘ ‘ ). Observemos os seguintes exemplos:

<?xml ver si on=” 1. 0” ?> <r ect angul o compr i ment o=’ 7” ’ l ar gur a=’ 8. 5” ’ / >

<?xml ver si on=” 1. 0” ?> <r ect angul o compr i ment o=’ 8' 7&quot ; ’ compr i ment o=” 10' 6&quot ; ” / >

Para que um documento possa ser interpretado por um browser, deverá ser classificado como “bem formado” , caso contrário nem sequer será interpretado. Para sintetizar o que


50

foi abordado até aqui, com relevância para o ponto anterior, apresento o conjunto de regras base que fundamentam esta classificação:

� No inicio do documento deve existir sempre uma declaração de processamento XML;

� Os elementos que contêm dados devem ser delimitados por uma tag inicial e uma tag final;

� Os elementos que não contêm dados e usem apenas uma tag, devem conter no final dessa tag o símbolo “ /” ;

� O documento deve possuir sempre um elemento raiz ( elemento que contém todos os outros );

� Os elementos devem ser organizados de forma hierárquica, não podendo acontecer sobreposição de elementos: <t ag_a><t ag_b>cont eudo</ t ag_b></ t ag_a> e não <t ag_a><t ag_b>cont eudo</ t ag_a></ t ag_b>;

� Os valores dos atributos devem estar definidos entre aspas ( “ “ ); � Os símbolos “<” e “&” devem ser usados apenas para iniciar tags ou referências,

exceptuando os casos abordados no elemento CDATA; � Devem apenas ser utilizadas referências conhecidas.

Estas regras são particularmente importantes quando não existe um DTD ( Document Type Definition ) associado.

As regras referidas no ponto anterior devem ser também respeitadas na codificação HTML sempre que a utilizarmos em documentos XML ou XSL, embora esta linguagem possua apenas um conjunto pré-definido de tags. Normalmente, da experiência que possuo no desenvolvimento de código HTML, a linguagem revela-se muito mais permissiva em relação a algumas das regras referidas. Ainda assim, é boa política adoptar uma estrutura de desenvolvimento organizada e consistente com as normas XML, uma vez que a tarefa de integração das linguagens sairá muito menos penosa e os resultados serão com certeza bem mais apreciados. Deixo aqui alguns alertas para problemas comuns que se reflectem aquando desta integração, do código HTML:

� As tags de abertura não possuem a respectiva tag de fecho; � As tags de fecho não se referem a nenhuma tag de abertura; � Elementos sobrepostos; � Valores de atributos não incluídos entre aspas; � Não utilização de referências; � Inexistência de um elemento raiz; � A capitalização utilizada nas tags não condiz, entre a tag inicial e final.

Representação de Linguagens e Definição de Documentos

A linguagem XML Representação de linguagens e Definição de Documentos

52

Como sabemos, a Internet é uma “entidade” internacional. Embora a maior parte da informação que podemos encontrar seja disponibilizada em inglês, existe uma quantidade elevada de sites que recorrem a outras línguas. Ao navegarmos pela Internet, deparamos por vezes com páginas, que por utilizarem um conjunto de caracteres desapropriado ( scripts diferentes do Western ), se tornam praticamente ilegíveis. São os exemplos de páginas soviéticas, hebraicas, japonesas, etc. A utilização do Unicode, aceite como um standard internacional, reduz drasticamente este problema. O formato Unicode, consiste num conjunto de caracteres que oferecem um vasto potencial gráfico de representação linguística, disponibilizando ao utilizador a possibilidade de representar praticamente qualquer linguagem conhecida. Uma das grandes vantagens da XML, é precisamente o suporte deste formato. Antes de abordar os procedimentos necessários à sua utilização, deixo ficar ao leitor alguns conceitos relacionados com a área da representação de caracteres, que ajudam a compreender melhor como funcionam estas tecnologias.

A designação script, é utilizada para classificar o conjunto de caracteres utilizados para representar uma linguagem. Um script pode ser conotado com um alfabeto fonético, embora não tenha necessariamente que o ser. As línguas chinesa, japonesa e coreana por exemplo utilizam um único caracter ou símbolo para representar uma palavra. Linguagens diferentes tendem no entanto a partilhar os mesmo scripts, apenas com pequenas variações. As linguagens anteriormente referidas são um exemplo disso, assim como o português em relação a grande parte das linguagens mundiais. A XML, por si só, não tem capacidade suficiente para ler um script. Para que tal seja possível, são ainda necessários os seguintes componentes:

� Um conjunto de caracteres para o script; � Uma fonte; � Um método de leitura; � Um sistema operativo e aplicações que “entendam” o script;

Um computador apenas entende números. Antes de processar qualquer tipo de texto, necessita de o codificar de acordo com uma tabela de correspondências. Esta contém um conjunto de pares constituídos por um código numérico e a respectiva letra associada. Este conjunto denomina-se de script.


53

A fonte apenas serve para indicar ao processador a forma como cada caractere presente no script deverá ser representado graficamente, independentemente da forma como estes possam ser armazenados. O método de leitura funciona como interface entre o utilizador e a máquina. Normalmente, os países que utilizam um script como o português ou pelo menos semelhante, não têm problemas neste interface, quase sempre representado por um teclado. No entanto, este facto já não é tão linear nos casos grego, árabe ou chinês. Existe um conjunto variado de técnicas que têm vindo a evoluir no sentido de proporcionar a estes povos uma forma fácil e eficaz na introdução de texto em computadores. Reconhecimento de voz e escrita, embora com algumas deficiências, serão nitidamente o caminho a seguir. Por agora proliferam algumas técnicas quase sempre baseadas em teclados com combinações de teclas para representar palavras. Actualmente, sistemas operativos como o Unix e o Windows, já possuem um suporte relativamente fiável de scripts e fontes de caracteres para que um browser possa apresentar informação numa língua de qualquer parte do mundo.

Utilizar diferentes scripts poder-se-á revelar um solução funcional desde que não seja ao mesmo tempo e os documentos não sejam trocados com utilizadores que utilizem scripts diferentes, mas o ideal é possuir uma notação que seja comum a todos os utilizadores. É desta necessidade que surge o Unicode. Embora o seu desenvolvimento, ainda em curso, seja algo bastante pesado, como se compreende pelo seu grau de abrangência, os grandes vendedores à escala mundial têm caminhado todos no mesmo sentido, nesta área. A linguagem XML elege o Unicode como a sua linguagem de caracteres por defeito. Se o leitor estiver interessado, existe uma especificação escrita bastante completa denominada The Unicode Standard.

Praticamente todos os browsers disponíveis suportam este formato e conseguem oferecer um bom nível de representação, sendo apenas limitados pelo conjunto de fontes existente. Como ainda não existem editores que suportem a globalidade da especificação Unicode, surgiu a necessidade de se contornar o problema. Assim, normalmente o utilizador deverá optar por uma destas soluções:


54

� Desenvolver um documento num formato suportável e só depois o convertê-lo para Unicode;

� Incluir no texto de um documento referências que identifiquem determinados tipos de caracteres.

Aconselha-se a primeira hipótese, quando existe uma enorme quantidade de texto e apenas se utiliza um script. A segunda hipótese aplica-se quando surge a necessidade da utilização de vários scripts num documento. Se o utilizador não dispuser de um editor com a capacidade de representar Unicode, pode então recorrer ao uso de referências. Para tal bastará representar os caracteres pretendidos com algo do género: &#960. Esta notação obedece à sintaxe & #<código_do_caractere>. Este código resulta do facto de a especificação Unicode representar as suas referências num intervalo entre 0 e 65535. Existe ainda a possibilidade de efectuar a mesma representação recorrendo à notação hexadecimal, mas considero-a um pouco mais elaborada. Guardar um documento em formato Unicode, é uma funcionalidade normalmente disponibilizada pela maioria dos editores actuais. Por exemplo o Notepad do Windows, oferece essa possibilidade. Existem no entanto em alguns sistemas, aplicações que possibilitam a conversão do documentos através da linha de comando. Ao construir um documento, salvo instrução em contrário, um processador XML assume o formato UTF-8 ( que efectua compressão de Unicode, utilizando apenas um byte para representação da maioria dos caracteres ). Como o UTF-8 inclui um subconjunto ASCII, praticamente todos os processadores o interpretam correctamente. Se o autor do documento necessitar de utilizar outros formatos deverá incluir na instrução de processamento o atributo encode, numa das seguintes formas:

<?xml ver si on=” 1. 0” encodi ng=” I SO- 8859- 1” ?> <dados> Aqui f i car i am os dados do document o. </ dados>

<?xml ver si on=” 1. 0” ?> <?xml encodi ng=” I SO- 8859- 1” ?> <dados> Aqui f i car i am os dados do document o. </ dados>

No endereço da Internet Assigned Numbers Authority ( http://www.isi.edu/in-notes/iana/assignments/character-sets ), pode ser encontrada a lista oficial de formatos disponíveis para codificar um documento.


55

A linguagem XML é baseada em marcações ou tags. A liberdade que oferece em termos de construção de documentos, permite ao utilizador criar ele próprio uma estrutura particular, idealizada de acordo com um determinado contexto. Este conceito, pode ser implementado recorrendo ao uso de DTDs ( Document Type Definitions ). Posteriormente, um documento construído de acordo com o referido contexto, poderá ser validado pelo DTD. Neste ponto irei abordar e aprofundar esta forma de definição da estrutura da informação de um documento, referindo os aspectos essenciais da sua concepção.

Um DTD define regras para a estruturação de um documento, disponibilizando um conjunto de elementos, atributos, notações e entidades, bem como as relações entre eles. Por exemplo, um DTD pode definir um elemento denominado Livro, contendo elementos filho identificados por Código, Titulo e Autor. Um DTD pode ser incluído no próprio documento XML ou ser acedido externamente através de um link URL. Este ultimo tem a grande vantagem de poder ser utilizado por outros documentos. Existem outras vantagens relacionadas com a utilização de DTDs, que se resumem nos seguintes aspectos:

� Reforço do relacionamento entre as mais diversas entidades, abrindo caminho à criação de standards de estruturação de documentos, facilitando dessa forma o processo negocial entre as mesmas;

� Facilidade na comunicação entre diferentes aplicações, aderentes a um mesmo standard ou standards;

� Definição exacta do que é ou não permitido na especificação de um documento, estabelecendo que tipos de elementos deverão ser interpretados por software de edição ou apresentação, garantindo que qualquer estruturação que não esteja de acordo com o especificado seja inválida;

� Visualização da estrutura de um documento sem necessidade de apresentação da informação, continuando assim a permitir a separação entre ambos.


56

Para que um documento utilize um DTD, necessita de receber uma instrução nesse sentido. Esta instrução, que deve ser incluída sempre após a instrução de processamento XML e antes do elemento raiz, terá o seguinte aspecto:

<?xml ver si on=” 1. 0” st andal one=” yes” ?> <! DOCTYPE dados [ <! ELEMENT dados ( #PCDATA) > ] > <dados> Aqui f i car i am os dados do document o. </ dados>

Analisando a porção de código destacada, podemos observar a instrução de definição do DTD que é delimitada pelas tags <! DOCTYPE e ] >. Esta instrução poderia ser completamente representada numa linha única, no entanto, é boa prática por questões de organização na especificação do DTD, que esta seja repartida por várias linhas. O nome que sucede a esta instrução, “dados”, é de carácter obrigatório uma vez que define, logo à partida, que qualquer documento que utilize este DTD terá de conter um elemento raiz de nome “dados”. Os parêntesis rectos ( [ ] ) delimitam a definição do DTD. Esta definição baseia-se num conjunto de declarações que identificam elementos, atributos, e entidades. Uma destas declarações define o elemento raiz, e no nosso exemplo corresponde a <! ELEMENT dados ( #PCDATA) >. Esta linha representa uma declaração de um tipo de elemento, de nome “dados” que possui informação para ser interpretada, identificada sob a forma ( #PCDATA) . Mais uma vez, este tipo de declaração pode ser combinada com a utilização de uma folha de estilos:

<?xml ver si on=” 1. 0” st andal one=” yes” ?> <?xml - st y l esheet t ype=” t ext / css” hr ef =” est i l o. css” ?> <! DOCTYPE dados [ <! ELEMENT dados ( #PCDATA) > ] > <dados> Aqui f i car i am os dados do document o. </ dados>


57

Para que possa ser considerado válido, um documento deverá obedecer às regras especificadas no DTD, nomeadamente, deverá possuir o elemento raiz identificado na instrução <! DOCTYPE >. Basicamente o nosso exemplo define que um documento válido teria o seguinte aspecto:

<dados> Aqui f i car i am os dados do document o. </ dados>

Exemplos de documentos inválidos seriam:

<dados> <el ement o>Aqui f i car i am os dados do document o. </ el ement o> <el ement o/ > </ dados>

<dados> <dados>Aqui f i car i am os dados do document o. </ dados> </ dados>

Como se pode deduzir, um documento que utilize um DTD não poderá conter uma estrutura arbitrária, como no caso documento XML normal. O primeiro exemplo apresentado como inválido é um documento XML bem formado, no entanto não obedece à especificação do DTD. A validação de um documento em relação a um DTD é efectuada por parsers. Um parser de validação encarregar-se-á então de verificar se um determinado documento vai de encontro ao DTD especificado. Caso tal não aconteça apresentará uma mensagem de erro. Quando desenvolvemos um documento XML, deveremos ter sempre o cuidado de efectuar este tipo de verificação antes de o distribuirmos para utilização. Existem vários parsers disponíveis na Internet, na sua maioria grátis, nomeadamente o XML for Java, XJParser, SXP ou o XML Spy. Qualquer um deles efectua a validação de documentos XML, apresentando uma lista de erros ( no caso de existirem ) ao utilizador.

À semelhança dos aspectos que abordei relacionados com o tema da estruturação de informação num documento XML, também aqui se releva a importância do pleno conhecimento da informação a estruturar sob a forma de DTD.


58

Em primeiro lugar é necessário identificar quais os elementos a utilizar no documento. Ao especificar o DTD procede-se à declaração destes elementos bem como dos filhos que entram na sua composição, como tal, será importante ter em mente a composição da estrutura XML que pretenderemos obter. Observemos um exemplo simples de um documento que especifica a informação contida numa agenda:

<?xml ver si on=” 1. 0” st andal one=” yes” ?> <agenda> <cont act o> <nome>Nome 1</ nome> <mor ada>Mor ada 1</ mor ada> <t el ef one>111 1111</ t el ef one> <mai l >mai l @cont act o. um. pt </ mai l > </ cont act o> <cont act o> <nome>Nome 2</ nome> <mor ada>Mor ada 1</ mor ada> <t el ef one>222 2222</ t el ef one> <mai l >mai l @cont act o. doi s. pt </ mai l > </ cont act o> <cont act o> <nome>Nome 3</ nome> <mor ada>Mor ada 3</ mor ada> <t el ef one>333 3333</ t el ef one> <mai l >mai l @cont act o. t r es. pt </ mai l > </ cont act o> </ agenda>

Devemos identificar cuidadosamente a estrutura do documento que pretendemos obter, as relações que possam existir entre os diversos elementos, os filhos que os compõem, etc. É importante também, construir um DTD que possa ser reutilizável. Os DTDs podem ser incluídos dentro de outros, formando uma estrutura mais complexa, definida pelo grau de densidade especificada em cada um dos DTDs. Um DTD bem estruturado pode ser utilizado em vários contextos, sobre diversos tipos de documentos.

Cada tag utilizada na estrutura XML de um documento necessita de ser declarada no DTD. Esta declaração especifica o nome e conteúdo do elemento. O conteúdo desse elemento, será representada recorrendo a uma gramática simples, utilizando meta-caracteres como * , ? ou +, para identificar o numero de ocorrências de um determinado elemento. O processo de especificação do DTD tornar-se-á mais fácil se o abordarmos de fora para dentro da hierarquia, permitindo-nos assim ir verificando a correcta estruturação XML. Recorrendo então ao exemplo anterior, vamos construir um DTD apropriado. A primeira instrução seria:


59

<! DOCTYPE agenda [

] >

Desta forma, identificamos o elemento raiz. De notar que esta instrução não especifica qual o conteúdo deste elemento, para tal devemos utilizar a declaração:

<! ELEMENT agenda ANY>

Todas as declarações de elementos iniciam com a tag <! ELEMENT e terminam com >. Como é óbvio, também são case-sensitive. Incluem ainda o nome do elemento, neste caso “agenda” , seguido da especificação do conteúdo. Neste caso, a palavra chave ANY, indica que o elemento poderá conter outros elementos ou texto. Para representar os elementos que contêm apenas texto utilizamos a palavra chave #PCDATA. Observemos um exemplo:

<! ELEMENT nome ( #PCDATA) >

Este tipo de elemento não contém elementos filho associados. No exemplo, será o caso também dos elementos <mor ada>, <t el ef one> e <mai l >. Uma definição possível para o exemplo da agenda seria:

<?xml ver si on=” 1. 0” st andal one=” yes” ?> <! DOCTYPE agenda [ <! ELEMENT agenda ANY> <! ELEMENT cont act o ANY>

<! ELEMENT nome ( #PCDATA) > <! ELEMENT mor ada ( #PCDATA) > <! ELEMENT t el ef one ( #PCDATA) > <! ELEMENT mai l ( #PCDATA) >

] > <agenda> <cont act o> <nome>Nome 1</ nome> <mor ada>Mor ada 1</ mor ada> <t el ef one>111 1111</ t el ef one> <mai l >mai l @cont act o. um. pt </ mai l > </ cont act o> <cont act o> <nome>Nome 2</ nome> <mor ada>Mor ada 1</ mor ada> <t el ef one>222 2222</ t el ef one> <mai l >mai l @cont act o. doi s. pt </ mai l > </ cont act o> <cont act o> <nome>Nome 3</ nome> <mor ada>Mor ada 3</ mor ada> <t el ef one>333 3333</ t el ef one> <mai l >mai l @cont act o. t r es. pt </ mai l > </ cont act o> </ agenda>


60

A ordem pela qual os elementos aparecem descritos não é importante. Apenas interessa o conteúdo das suas especificações. No entanto, o utilizador poderá desenvolver o DTD de acordo com a ordem hierárquica que o documento XML deverá apresentar, por questões de perceptibilidade. Embora este DTD esteja correcto, não integra um grande nível restritivo. As palavras chave ANY, poderão ser utilizadas nas fases iniciais da elaboração da especificação, mas deverão dar lugar a declarações mais especificas de conteúdo. Observemos então como poderíamos indicar qual a constituição do elemento <cont act o>.

<! ELEMENT cont act o ( nome, mor ada, t el ef one, mai l ) >

Desta forma especificaríamos concretamente que o elemento <cont act o> possui um elemento <nome> seguido dos elementos <mor ada>, <t el ef one> e <mai l >. É importante referir que esta declaração define a existência de apenas uma ocorrência de cada elemento filho. Se por exemplo existissem dois telefones alternativos identificados pela mesma tag <t el ef one>, modificaríamos a definição para:

<! ELEMENT cont act o ( nome, mor ada, t el ef one, t el ef one, mai l ) >

Também neste caso, a ordem definida entre parêntesis deverá ser respeitada. Não seria possível, na definição XML do documento alterar a ordem dos elementos filho pertencentes ao elemento <cont act o>. Da mesma forma, uma vez utilizada a declaração anterior, seria necessário que cada elemento <cont act o> possuísse obrigatoriamente dois elementos <t el ef one>, caso contrário o documento seria inválido. Cada elemento deve ser declarado na sua respectiva tag <! ELEMENT > apenas uma vez, mesmo que surja repetido várias vezes no documento. Vou agora debruçar-me sobre o elemento raiz. Pelo que foi dito anteriormente, para definirmos este elemento recorreríamos à declaração:

<! ELEMENT agenda ( cont act o) >

Desta forma teríamos um “pequeno” problema. A nossa agenda só poderia ter um contacto. Uma declaração de acordo com as nossas exigências deve ter o seguinte aspecto:

<! ELEMENT agenda ( cont act o+) >

O símbolo +, indica que o elemento <agenda>, possui um ou mais elementos do tipo <cont act o>. No entanto, num extremo, a nossa agenda até poderá estar vazia. Nesse caso alteraríamos a declaração anterior para:

<! ELEMENT agenda ( cont act o* ) >


61

O símbolo * , indica que poderão existir zero ou mais elementos do tipo <cont act o>. Da mesma forma, embora não se aplique ao nosso exemplo, o sinal ?, indicaria a existência de zero ou um elementos. Assim, o aspecto final do DTD para o nosso documento seria:

<?xml ver si on=” 1. 0” st andal one=” yes” ?> <! DOCTYPE agenda [ <! ELEMENT agenda ( cont act o* ) > <! ELEMENT cont act o ( nome, mor ada, t el ef one, mai l ) >



Poderíamos ainda acrescentar alguma versatilidade ao nosso DTD, por forma a oferecer um pouco mais de liberdade à construção do documento XML. As restrições na declaração de elementos filho podem ser atenuadas da seguinte forma:

<! ELEMENT pagament o ( di nhei r o | cheque) >

Ao substituirmos as virgulas por símbolos pipe ( | ), oferecemos ao utilizador a possibilidade de seleccionar qual dos elementos pretende colocar no seu documento. No exemplo acima o elemento <pagament o> deverá conter um elemento filho do tipo <di nhei r o> ou <cheque>. Podemos ainda agrupar elementos de acordo com um determinado contexto, e caracterizar a forma como devem surgir no documento XML. Imaginemos o exemplo da linguagem HTML em relação à definição de listas, utilizado da seguinte forma:


62

<dl > <dt >i ndi ce<dd>t ext o

<dt >i ndi ce<dd>t ext o <dt >i ndi ce<dd>t ext o </ dl >

A sua representação seria:

<! ELEMENT dl ( dt , dd) * >

Podemos também combinar as várias formas de especificação, como no exemplo seguinte:

<! ELEMENT ar t i go ( t i t ul o, ( f ot ogr af i a | gr af i co) * , t ext o, aut or ?) >

Devemos no entanto ter cuidado quando pretendemos combinar a palavra chave #PCDATA. Com efeito, esta palavra chave é mais restritiva quer em termos de construção de um documento XML, quer na própria elaboração do DTD. A única combinação possível será:

<! ELEMENT pai ( #PCDATA | f i l ho1 | f i l ho2 | f i l ho3) >

Qualquer utilização dos símbolos abordados até aqui ( * , ?, + ), será inválida, bem como a separação de elementos filho por virgulas. Para terminar o ponto da declaração de elementos, falta apenas referir a declaração de tags vazias, ou elementos sem conteúdo. Este tipo de elemento representa-se recorrendo à palavra chave EMPTY, da seguinte forma:

<! ELEMENT BR EMPTY>

À semelhança das outras formas de especificação, os DTDs também podem ser comentados. Embora não possam ser utilizados dentro de declarações, os comentários são bastante úteis na organização de uma especificação de um DTD. A sintaxe da sua representação obedece ao que já nos habituamos a ver, quer na XML quer na HTML:

<! - - Est e é um coment ár i o col ocado num DTD - - > <! ELEMENT nome ( #PCDATA) >


63

Os exemplos apresentados até aqui incluem a representação do DTD no próprio documento XML. No entanto, o grande poder da XML é a partilha de DTDs entre os documentos. Esta partilha é conseguida incluindo no documento XML apenas uma referência ao DTD que vai utilizar, ao invés da especificação do próprio DTD. Como se pode deduzir, este conceito é bastante poderoso, mas acresce um facto que alguns poderão achar desvantajoso. Se o autor do DTD resolver alterar a sua especificação, poderá invalidar documentos que o estejam a utilizar. A forma de incluir a referida referência consiste apenas em acrescentar ao documento XML uma declaração do género:

<! DOCTYPE el ement o_r ai z SYSTEM “ URL_do_DTD” >

Onde o elemento_raiz corresponde ao que já vimos até aqui, e o URL_do_DTD é uma localização relativa ou absoluta do DTD. Para aplicarmos este conceito ao exemplo da agenda, retiramos do documento XML o texto referente à especificação do DTD, guardando-o num documento à parte de nome agenda.dtd. Realço a importância da extensão ( .dtd ). Seguidamente acrescentamos ao documento XML a instrução acima referida. Teríamos então o documento do DTD, agenda.dtd:

<! DOCTYPE agenda [ <! ELEMENT agenda ( cont act o* ) > <! ELEMENT cont act o ( nome, mor ada, t el ef one, mai l ) >


] >

E o respectivo documento XML, com a necessária alteração do atributo st andal one=” no” , agenda.xml:

<?xml ver si on=” 1. 0” st andal one=” no” ?> <! DOCTYPE agenda SYSTEM “ agenda. dt d” > <agenda> <cont act o> <nome>Nome 1</ nome> <mor ada>Mor ada 1</ mor ada> <t el ef one>111 1111</ t el ef one> <mai l >mai l @cont act o. um. pt </ mai l > </ cont act o> <cont act o> <nome>Nome 2</ nome>


64

<mor ada>Mor ada 1</ mor ada> <t el ef one>222 2222</ t el ef one> <mai l >mai l @cont act o. doi s. pt </ mai l > </ cont act o> <cont act o> <nome>Nome 3</ nome> <mor ada>Mor ada 3</ mor ada> <t el ef one>333 3333</ t el ef one> <mai l >mai l @cont act o. t r es. pt </ mai l > </ cont act o> </ agenda>

Neste caso, ambos os documentos teriam a mesma localização. O DTD poderia, no entanto, estar localizado num endereço URL qualquer, que apenas necessitaria de ser incluído na instrução <! DOCTYPE >. Se acrescentássemos uma folha de estilos para representar o nosso documento, teríamos a informação completamente separada em três documentos distintos, factor revelador da versatilidade desta linguagem. A relação DTD - documento XML é mais estreita que a relação CSS - documento XML, uma vez que a alteração do DTD implica a revalidação do documento XML.

A palavra chave SYSTEM, é utilizada quando nos referimos a DTDs utilizados internamente, elaborados por um determinado grupo fechado. No entanto, a tendência será para que organizações como a ISO ou a IEEE, estabeleçam standards de DTDs. Nestes casos a notação utilizada será:

<! DOCTYPE el ement o_r ai z PUBLI C “ NOME_do_DTD” “ URL_do_DTD” >

A palavra chave SYSTEM é substituída por PUBLI C, sendo acrescentado um identificador do DTD. Algumas convenções utilizadas nos nomes dos DTDs identificam os standards ISO com o prefixo “ ISO.” , outras entidades aprovadas iniciam com “+” e no caso de não serem DTDs certificados iniciam com “-“ . Este prefixo é acrescido do nome do autor, do tipo de documento descrito e do país origem separados pelo símbolo “ //” . Para o nosso exemplo seria “ -//Particular//Agenda//PT” .


65

É possível combinar os dois tipos de DTDs num mesmo documento, utilizando um DTD externo e estendendo-o internamente. O exemplo seguinte apresenta o procedimento necessário:

<?xml ver si on=” 1. 0” st andal one=” yes” ?> <! DOCTYPE agenda SYSTEM “ dt d_ext er no” [ <! ELEMENT agenda ( cont act o* ) > <! ELEMENT cont act o ( nome, mor ada, t el ef one, mai l ) >



O documento possui uma declaração <! DOCTYPE >, que referencía o DTD externo, declarando elementos adicionais no seu interior. Em situações de conflito entre nomes de elementos, persiste a declaração efectuada internamente.

Um documento XML pode ter o seu conteúdo distribuído por vários outros documentos. Quando o contexto de utilização de um documento envolve uma grande quantidade de informação, a estrutura desenvolvida pode ser distribuída por inúmeros documentos, facilitando a organização e tratamento da mesma.


66

As unidades responsáveis por este armazenamento distribuído designam-se Entidades. Uma entidade poderá ser um ficheiro, um registo de uma base de dados ou qualquer outro item que armazene informação. Nesta árvore de distribuição de informação, surge a necessidade de identificar o documento raiz, normalmente denominado de Documento Entidade, caracterizado por possuir a instrução de processamento XML e a definição do DTD. No entanto, qualquer elemento presente numa representação XML poderá conter referências a outras fontes de informação, a serem incluídas no original aquando da sua interpretação por um parser. Existem dois tipos de entidades: internas e externas. As primeiras são definidas no próprio documento, sendo ele próprio uma entidade. As entidades externas são normalmente localizadas através de um endereço URL. Por exemplo, um documento HTML possui entidades externas referenciadas em tags do tipo <I MG>, sendo que a definição inclusa entre as tags <ht ml ></ ht ml >, definem uma entidade interna. Podem-se ainda distinguir dois tipos de categorias nas entidades: interpretadas ou não. As primeiras englobam XML bem formado, as segundas estão relacionadas com dados binários ou não-XML. ��

Uma entidade interna representa geralmente informação que pode ser representada duma forma abreviada, normalmente de carácter repetitivo. Um exemplo deste tipo de entidades está relacionado com o cabeçalho ou rodapé de uma página, num documento de texto. A forma de proceder à sua definição consiste em incluir no DTD declarações do tipo:

<! ENTI TY nome_da_ent i dade “ t ext o_de_subst i t ui ção” >

O nome_da_entidade representa a abreviação do texto_de_substituição. No documento constará a primeira, mas o utilizador visualizará a segunda. Um exemplo simples está relacionado com a utilização de siglas:

<! ENTI TY DTD “ Document Type Def i ni t i on” >

Na prática, teríamos algo do género:

<?xml ver si on=” 1. 0” st andal one=” yes” ?> <! DOCTYPE dados [ <! ELEMENT dados ANY> <! ELEMENT si gl a ( #PCDATA) >

<! ENTI TY DTD “ Document t ype Def i ni t i on” > ] >


67

<dados> <si gl a>&DTD; </ si gl a> </ dados>

Num documento que possui este tipo de entidades a validação só será efectuada após ter tomado lugar o processo de substituição. A grande vantagem de utilizar este tipo de codificação reside na facilidade de efectuar alterações no texto ao longo de um documento. Uma entidade interna pode fazer parte da declaração de outra:

<! ENTI TY XML “ Ext ended Mar k Up Language i n &DTD; ” >

Este tipo de construção é válido uma vez que a entidade fazer parte do próprio conteúdo do documento. A facilidade de utilização pode ainda estender-se a outras formas:

<! ENTI TY cabecal ho “ <cabecal ho>

<empr esa>Nome da Empr esa</ empr esa> <mor ada>Mor ada</ mor ada> <mai l >Mai l @Nome. pt </ mai l >

</ cabecal ho>” >

No entanto, não são permitidas referências circulares, nem referências que contenham texto que não venha a fazer parte dos dados do documento, como nos dois exemplos seguintes:

<! ENTI TY XML “ Ext ended Mar k Up Language i n &DTD; ” > <! ENTI TY DTD “ Document t ype Def i ni t i on f or &XML; ” >

<! ENTI TY PCD “ ( #PCDATA) ” > <! ELEMENT nome &PCD; >

Existem algumas entidades pré-definidas, que inclusivamente já tive a oportunidade de abordar. Refiro-me em concreto às referências utilizadas para os caracteres que fazem parte do XML, & , &l t ; , etc. A sua definição corresponde ao seguinte:

<! ENTI TY l t “ & #60; ” > <! ENTI TY gt “ > ” > <! ENTI TY amp “ & #38; ” > <! ENTI TY apos “ ' ” > <! ENTI TY quot “ " ” >

Existe ainda um outro conceito ligado às Entidades Internas. O que foi visto até aqui refere-se à informação que ao ser substituída fará parte dos dados do documento, no entanto, é possível incluir referências que apenas farão parte do DTD, baseadas em parâmetros.


68

As principais diferenças residem na substituição do prefixo & por % , e no facto de este tipo de referências apenas aparecerem no DTD. A forma de declaração tem a seguinte sintaxe, em tudo idêntica à definição anteriormente apresentada, exceptuando o símbolo %:

<! ENTI TY % nome_da_ent i dade “ t ext o_de_subst i t ui ção” >

Com este tipo de referência o exemplo dado como inválido, será aceite:

<! ENTI TY % PCD “ ( #PCDATA) ” > <! ELEMENT nome %PCD; >

Facilmente se deduz a utilidade de instruções deste género na definição de DTDs, em especial, quando tratamos um volume considerável de informação repetitiva. Observemos o seguinte exemplo:

<! ENTI TY % el ement os_f i l ho “ ( pessoa | nome | model o | pr odut o | i ngr edi ent e) * ”

> <! ELEMENT pagar af o %el ement os_f i l ho; > <! ELEMENT cel ul a %el ement os_f i l ho; > <! ELEMENT l i nha %el ement os_f i l ho; >

Este tipo de referências deverão sempre ser declaradas antes de serem utilizadas, só podendo ser utilizadas como parte da declaração de um DTD externo. Em DTDs internos, as referências só podem ser utilizadas fora das declarações. ��

As entidades externas permitem construir um documento XML à custa da informação presente noutros documentos. A flexibilidade da XML, permite que um determinado documento referencie outro, mesmo quando os seus elementos raiz coincidem, desde que o DTD defina que o elemento raiz pode conter-se a ele próprio. A construção de um documento com base num conjunto de outros documentos é uma grande vantagem da XML, uma vez que se trata de uma estrutura independente da localização física dos mesmos. Um parser encarrega-se do procedimento de integração tendo como única restrição a garantia de que não existem referências cíclicas entre os documentos envolvidos. A sintaxe de inclusão duma referência externa num DTD é a seguinte:

<! ENTI TY nome SYSTEM “ URI ” >

Suponhamos que pretendemos incluir a definição de um cabeçalho em todos os documentos que vão constituir as páginas de um site. Um documento XML conteria a referida definição, podendo ser localizado através de um endereço do tipo http://definicoes.paginas/cabecalhos/cabecalho.xml:


69

<?xml ver si on=” 1. 0” ?> <cabecal ho>

<empr esa>Nome da Empr esa</ empr esa> <mor ada>Mor ada</ mor ada> <mai l >Mai l @Nome. pt </ mai l > </ cabecal ho>

Poderíamos incluir a definição deste documento num DTD da seguinte forma:

<?xml ver si on=” 1. 0” st andal one=” no” ?> <! DOCTYPE dados [ <! ELEMENT dados ANY>

<! ENTI TY cabecal ho SYSTEM “ ht t p: / / def i ni coes. pagi nas/ cabecal hos/ cabecal ho. xml ”

> ] >

<dados> &cabecal ho; <t i t ul o>Ti t ul o do document o</ t i t ul o> </ dados>

Mais uma vez, recordo a necessidade de colocar o atributo st andal one=” no” , uma vez que este documento, para ficar completo, necessita de recorrer a um outro documento externo. Uma abordagem deste tipo utiliza um DTD que define todos os elementos utilizados no documento. Este facto pode-nos conduzir a definições imensas quase incomportáveis num único documento. O que acontece na maior parte das vezes, é que utilizaremos apenas partes de DTDs nos documentos que elaboramos. À semelhança do que acontecia nas Entidades Internas, também aqui existe a possibilidade de utilização de parâmetros. As Entidades Externas baseadas em parâmetros, permitem a construção de DTDs de pequena dimensão a partir de grandes DTDs. Esta abordagem facilita bastante a análise de DTDs, ao mesmo tempo que permite a separação do código por vários documentos. Um exemplo da utilização num DTD destas referências poderia assemelhar-se ao seguinte:

<! ELEMENT equi pa ( c i dade, nome, j ogador * ) > <! ELEMENT ci dade ( #PCDATA) > <! ELEMENT nome ( #PCDATA) > <! ENTI TY % j ogador SYSTEM “ j ogador es. dt d” > %j ogador ;

Neste caso, o nosso documento conteria informação acerca de equipas, recolhendo a especificação de construção do DTD, para a parte respeitante aos jogadores, num DTD


70

externo contido num documento denominado “ jogadores.dtd”, referenciado pela entidade %j ogador ; .

Como já vimos até aqui, o conceito de documento bem formado passa por obedecer por um lado às restrições da XML, e por outro às restrições de um DTD utilizado por um ou mais documentos. No conjunto destas duas características um documento será também classificado como válido. Existe ainda um terceiro nível de conformidade: documentos que contêm DTDs e estão bem formados mas não são válidos, devido ao facto de o DTD estar incompleto ou por não obedecer às restrições do DTD. Existem casos em que não existe a necessidade que um documento XML seja válido. Bastará ser simplesmente bem formado. O mesmo se passa em relação aos DTDs. Alguns processadores, que não validam a XML, tiram partido da informação de um DTD sem necessitarem que existam as referidas restrições de conformidade. Nestes casos, o processador só vai interpretar as declarações do tipo ENTI TY. A utilização de entidades internas, além das referências pré-definidas ( <, >, etc. ) é um dos exemplos de utilização de um DTD, num documento que não necessite de validação. Ao invés de declararmos a globalidade do DTD, podemos simplesmente construir algo do género:

<?xml ver si on=” 1. 0” st andal one=” yes” ?> <! DOCTYPE dados [

<! ENTI TY dt d “ Document Type Def i ni t i on” > ] >

<dados> <t i t ul o>Ti t ul o do document o</ t i t ul o> <descr i cao>&dt d; </ descr i cao> </ dados>

Este é o exemplo de um documento que pode ser classificado como bem formado mas não é válido. Poderíamos também, não respeitar sequer a restrição de que o elemento definido na palavra chave <! DOCTYPE > fosse o elemento raiz do documento, continuando o documento a usufruir da mesma classificação. Em relação às entidades externas, os processadores poderão resolver as respectivas referências, embora este facto não se verifique sempre. A utilização de referências externas é particularmente útil no armazenamento de tipos de representação de caracteres. Poderíamos ter uma definição, com base em declarações ENTI TY, de um conjunto de caracteres a serem utilizados em conteúdos textuais, relacionados com alguns tipos de línguas distintos.


71

Um DTD deste tipo pode então ser codificado num determinado documento, que seria posteriormente incluído num qualquer documento XML, através de uma referência externa. Este documento XML pode conter tags não definidas no DTD externo, tornando-o num documento bem formado, embora inválido. Realço no entanto a obrigatoriedade da declaração no DTD externo, das referências utilizadas no documento XML.

Como já tive a oportunidade de abordar no capítulo de introdução à XML, a linguagem dispõem do conceito de atributo para representar informação nos documentos que, na maior parte das vezes, apenas se destina a ser utilizada por aplicações que manipulem a informação. Esta informação, normalmente, nunca será apresentada numa página de um browser. Relembro agora um exemplo da sua utilização, e alguns aspectos relevantes:

<?xml ver si on=” 1. 0” st andal one=” yes” ?> <l i vr os> <l i vr o codi go=” 1” > <t i t ul o>Ti t ul o do Li vr o</ t i t ul o> <edi t or a>Edi t or a do Li vr o</ descr i cao> <aut or >Aut or do Li vr o</ aut or > <capa i magem=” i magem. j pg” ></ capa> </ l i vr o> </ l i vr os>

Neste exemplo observamos dois atributos. O atributo codi go apenas será utilizado para efeitos de controlo, ao invés do atributo i magem, que será utilizado na apresentação de informação num browser. Um aspecto comum em relação a estes dois atributos, e ao conceito de atributo, refere-se ao facto de representarem informação acerca do conteúdo e não o próprio conteúdo. Com efeito o atributo codi go indica que a informação respeitante a um livro está identificada por um valor numérico, que obviamente será diferente para cada elemento <l i vr o>. Por seu lado, o atributo i magem, não contém a imagem propriamente dita, mas uma indicação referente à sua localização. Outro aspecto relacionado com o conceito de atributo, é que um elemento poderá conter mais do que um, sendo que, apenas podem ser representados nas tags de abertura. A declaração de um atributo, à semelhança de outras entidades de um DTD, faz-se recorrendo ao uso de uma tag denominada <! ATTLI ST>. A sua representação obedece à seguinte sintaxe:


72

<! ATTLI ST nome_do_el ement o nome_do_at r i but o t i po val or _def ei t o>

A sintaxe é bastante simples de entender. Os identificadores nome_do_elemento e nome_do_atributo, caracterizam o elemento que contém o atributo e o nome desse atributo, respectivamente. O valor_defeito, representa o valor que o atributo recebe, sempre que não é especificado nenhum valor inicial. Em relação ao exemplo anterior, a declaração do atributo codi go seria: <! ELEMENT l i vr o ( t i t ul o, edi t or a, aut or , capa) > <! ATTLI ST l i vr o codi go CDATA “ - 1” >

Estas instruções descrevem a constituição de um elemento <l i vr o>, acrescentando que, elementos deste tipo possuem um atributo denominado codi go. Quando o valor desse atributo não é especificado no documento, este conterá o valor –1 por defeito. A lista de atributos, ATTLI ST, é sempre declarada separada do elemento, e os atributos declarados nessa lista pertencem somente ao elemento indicado. Se outros elementos tiverem um atributo com a mesma designação, necessitarão de uma nova declaração. A ordem pela qual os atributos são declarados não é importante. O parâmetro tipo, poderá tomar os valores que se descrevem na tabela seguinte:

Tipo Significado CDATA Car act er es. Text o não mar cado. Enumer at ed Uma l i s t a de val or es possi vei s, da qual só se

sel ecci onar á um. I D Um nome úni co, não par t i l hado por mai s nenhum at r i but o

dest e t i po no document o. I DREF Val or de um at r i but o do t i po I D. I DREFS Múl t i pl os val or es par a I D, separ ados por vi r gul as. ENTI TY Nome duma ent i dade decl ar ada no DTD. ENTI TI ES Nomes de múl t i pl as ent i dades decl ar adas no DTD, separ ados

por v i r gul as. NMTOKEN Um nome XML. NMTOKENS Múl t i pl os nomes XML, separ ados por v i r gul as. NOTATI ON Nome da not ação decl ar ada no DTD.

Veremos o seu significado mais adiante. ��

Na maior parte das vezes, os elementos possuem mais do que um atributo. Um exemplo, na linguagem HTML, o elemento <i mg> possui uma lista considerável. Aliás, a linguagem HMTL é o exemplo por excelência no que se refere a elementos com múltiplos atributos.


73

A declaração de múltiplos atributos pode ter duas formas, suponhamos um elemento denominado <r ect angul o>, que se representaria desta forma: <r ect angul o al t ur a=” 10” l ar gur a=” 15” / >

A declaração dos dois atributos poder-se-ia representar: <! ELEMENT r ect angul o EMPTY> <! ATTLI ST r ect angul o al t ur a CDATA “ 0” > <! ATTLI ST r ect angul o l ar gur a CDATA “ 0” >

ou, <! ELEMENT r ect angul o EMPTY> <! ATTLI ST r ect angul o al t ur a CDATA “ 0” l ar gur a CDATA “ 0” >

Esta segunda notação é válida mesmo quando o tipo ou valor por defeito do atributo, são diferentes. ��

Ao invés de explicitarmos o valor por defeito, por não termos boas opções para o fazer, podemos simplesmente requerê-lo ao autor do documento, omitir o valor ou utilizar sempre o mesmo. Para o efeito existem três palavras chave, #REQUI RED, #I MPLI ED, #FI XED. Em relação à palavra chave #REQUI RED, ela é utilizada para forçar o autor do documento a disponibilizar determinado tipo de informação. Imaginemos que era necessário, nos documentos que circulam numa determinada empresa, que o autor fosse sempre especificado da seguinte forma: <aut or nome=” nome_do_aut or ” mai l =” mai l _do_aut or ” / >

Provavelmente, poderiam surgir representações do tipo <aut or / >. Para impedir que tal acontecesse, a declaração desta tag deveria ser feita da seguinte forma: <! ELEMENT aut or EMPTY> <! ATTLI ST aut or nome CDATA #REQUI RED> <! ATTLI ST aut or mai l CDATA #REQUI RED>

Se o parser não encontrar os atributos especificados como obrigatórios, devolverá um erro. A palavra chave #I MPLI ED, é utilizada nos casos em que não existe obrigatoriedade de fornecer o valor do atributo. Imaginemos, para o exemplo anterior, que apenas seria necessário fornecer o mail do autor. A declaração do elemento poderia ser:


74

<! ELEMENT aut or EMPTY> <! ATTLI ST aut or nome CDATA #I MPLI ED> <! ATTLI ST aut or mai l CDATA #REQUI RED>

Nestes casos, se o valor do atributo nome não for fornecido, o parser apenas emite uma informação nesse sentido. Finalmente, se pretendermos fornecer um valor para um atributo que não queremos que seja alterado pelo autor do documento utilizamos a palavra chave #FI XED. No exemplo anterior, acrescentávamos à informação o nome da empresa. Esse nome seria fixo, e a declaração do elemento passaria a ter o seguinte aspecto: <! ELEMENT aut or EMPTY> <! ATTLI ST aut or nome CDATA #I MPLI ED> <! ATTLI ST aut or mai l CDATA #REQUI RED> <! ATTLI ST aut or empr esa CDATA #FI XED “ Nome da empr esa” >

O atributo empresa não é obrigatório, uma vez que será automaticamente fornecido. No entanto, se o autor do documento o incluir, deverá utilizar o valor por defeito existente, caso contrário o parser devolverá um erro. ��

Vejamos agora mais concretamente, o significado de cada um dos tipos representados na tabela anterior. O tipo CDATA é o mais genérico. O valor do atributo pode conter qualquer caracter exceptuando os símbolos < e “ . Para os podermos representar devemos utilizar as referências &l t ; e &quot ; . Esta representação também deverá ser utilizada na representação de outros caracteres não permitidos, como aliás já tive a oportunidade de abordar no capítulo anterior. O tipo Enumer at ed, não é uma palavra chave do XML, mas uma lista de valores para um atributo, separados pelo símbolo pipe ( | ). O autor do documento poderá então seleccionar um valor dessa lista. Vejamos o seguinte exemplo: <! ATTLI ST par agr af o vi s i vel ( t r ue | f al se ) “ t r ue” >

Neste caso o utilizador poderia seleccionar um valor do atributo, de acordo com a forma de representação necessária, visível ou não: <par agr af o v i s i vel =” t r ue” >Est e t ext o sur ge na f ol ha. </ par agr af o> <par agr af o>Est e t ext o t ambem sur ge na f ol ha. </ par agr af o> <par agr af o v i s i vel =” f al se” >Est e t ext o não sur ge na f ol ha. </ par agr af o>

É evidente que esta construção, por si só, não esconde ou mostra o texto. Seria implementar numa linguagem de estilo, XSL, o código necessário ao tratamento deste atributo.


75

O tipo NMTOKEN restringe o valor de um atributo a um identificador ou nome válido para a XML. As regras referentes à representação de nomes, nomeadamente nomes de tags, foram já discutidos no capítulo anterior. A utilização deste atributo revela-se útil quando pretendemos que um determinado atributo não aceite valores, de alguma forma inválidos para a XML. Supondo que tínhamos a necessidade que um determinado valor não contivesse espaços. Representar esta restrição num DTD consistiria em utilizar a seguinte declaração: <! ATTLI ST el ement o at r i but o NMTOKEN #REQUI RED>

No seguimento deste conceito surge o de NMTOKENS, que não é mais do que a extensão do anterior a uma lista de nomes XML, separados por espaços. O âmbito da sua utilização é exactamente o mesmo e as possibilidades aumentam de acordo com o conteúdo da lista. <! ATTLI ST el ement o at r i but o NMTOKENS #REQUI RED>

Pode ser representado da seguinte forma: <el ement o at r i but o=” val or 1 val or 2 val or 3” / >

O tipo I D, identifica um elemento de forma única. O nome utilizado deverá ser válido para a XML, ou seja, deverá obedecer às regras de definição de nomes. Sempre que este I D for utilizado mais do que uma vez num documento o parser devolverá um erro. A utilização deste tipo é incompatível com a palavra chave #FI XED, e na maior parte das vezes será #REQUI RED. Vejamos um exemplo:


<! ELEMENT dados ( el ement o* ) > <! ELEMENT el ement o ( #PCDATA) > <! ATTLI ST el ement o i dent i f i cador I D #REQUI RED> ] >

<dados> <el ement o i dent i f i cador =” 1” >Pr i mei r o el ement o. </ el ement o> <el ement o i dent i f i cador =” 2” >Segundo el ement o. </ el ement o> </ dados>

O tipo I DREF representa uma referência a um outro atributo do tipo I D presente no mesmo documento. Pode-se utilizar por exemplo, para relacionar elementos filho com os seus pais.


<! ELEMENT dados ( pessoa* ) > <! ELEMENT pessoa ( #PCDATA) > <! ATTLI ST pessoa i dent i f i cacao I D #REQUI RED>


76

<! ATTLI ST pessoa l i gacao I DREF #I MPLI ED> ] >

<dados> <pessoa i dent i f i cacao=” pai ” >El ement o pai . </ pessoa> <pessoa i dent i f i cacao=” f i l ho” l i gacao=” pai ” > El ement o f i l ho. </ pessoa> </ dados>

Este tipo de atributo, é utilizado quando queremos estabelecer uma ligação entre elementos de um documento que não são representados de acordo com a hierarquia pai-filho. O tipo ENTI TY, é utilizado em atributos que estabelecem ligações a entidades externas. Um exemplo comum da sua utilização tem a haver com imagens: <! ELEMENT i magem EMPTY> <! ATTLI ST i magem l ocal i zacao ENTI TY #REQUI RED> <! ENTI TY l ogot i po SYSTEM “ l ogo. gi f ” >

Nos dados do documento poderíamos ter algo do género: <i magem l ocal i zacao=” l ogot i po” >

Por analogia, o tipo ENTI TI ES, funciona de modo igual mas relacionado com um conjunto de referências separadas por espaços. Imaginemos o caso de um documento que apresenta, a dada altura, um conjunto de slides: <! ELEMENT sl i deshow EMPTY> <! ATTLI ST sl i deshow l ocal i zacoes ENTI TI ES #REQUI RED> <! ENTI TY i magem1 SYSTEM “ i mg1. gi f ” > <! ENTI TY i magem2 SYSTEM “ i mg2. gi f ” > <! ENTI TY i magem3 SYSTEM “ i mg3. gi f ” >

Nos dados do documento poderíamos ter algo do género: <sl i deshow l ocal i zacoes=” i magem1 i magem2 i magem3” >

Para finalizar, resta-me o tipo NOTATI ON. Como o próprio nome indica, o valor de um atributo deste tipo representa o nome de uma notação ( informação que não está no formato XML ) utilizada num DTD. Vejamos um exemplo: <! ATTLI ST l ei t or _de_som t i po_f i chei r o NOTATI ON ( MP3) #REQUI RED> <! NOTATI ON MP3 SYSTEM “ mp3pl ayer . exe” >

Poderíamos ainda definir um conjunto de notações diferentes da seguinte forma:


77

<! ATTLI ST l ei t or _de_som t i po_f i chei r o NOTATI ON ( MP3| MI DI | WAV) #REQUI RED> <! NOTATI ON MP3 SYSTEM “ mp3pl ayer . exe” > <! NOTATI ON MP3 SYSTEM “ mi di pl ayer . exe” > <! NOTATI ON MP3 SYSTEM “ wavpl ayer . exe” >

Mais uma vez, recordo que os exemplos que apresentei, não funcionam por si só. São apenas especificações que carecem de ser interpretadas por uma linguagem de estilo como o XSL. � ��

Existem dois atributos pré-definidos na linguagem XML, designadamente, xml : space e xml : l ang. Aplicados num elemento do DTD, descrevem respectivamente a forma como são utilizados espaços em branco e o tipo de linguagem num elemento. A utilização do atributo xml : space, torna-se importante na representação de dados que contenham espaços em branco significativos. A linguagem HTML ignora espaços em branco, não lhes conferindo por esse facto, a importância que deveriam ter na representação de determinados tipos de informação. Em XML, tal não acontece uma vez que o processador transmite a uma aplicação a informação tal e qual ela está representada num documento. Em condições normais, esta aplicação irá ignorar os espaços em branco. No entanto, a utilização deste atributo permite contrariar este comportamento, indicando que a informação deve ser utilizada na sua forma original. Vejamos o seguinte exemplo de apresentação de uma tabela Ascii:

<?xml ver si on=” 1. 0” st andal one=” yes” ?> <! DOCTYPE pr ogr ama [

<! ELEMENT pr ogr ama ( #PCDATA) > <! ATTLI ST pr ogr ama xml : space ( def aul t | pr eser ve) “ pr eser ve” > ] >

<pr ogr ama xml : space=” pr eser ve” > publ i c cl ass Asci i Tabl e { publ i c st at i c voi d mai n ( st r i ng[ ] ar gs) { f or i nt ( I =0; I &l t ; 128; I ++) Syst em. out . pr i nl n( I +” “ + ( char ) I ) ; } } </ pr ogr ama>

Os filhos de um elemento que utilize este atributo comportar-se-ão como o elemento pai, excepto se eles próprios contiverem um atributo xml : space que entre em conflito com o definido no elemento pai.


78

Realço aqui a importância da utilização dos dois tipos Enumer at ed ( preserve e default ), na declaração da ATTLI ST. O atributo xml : l ang identifica a linguagem em que o conteúdo de um elemento está representado. O valor deste atributo poderá ser do tipo CDATA, NMTOKEN ou Enumer at ed. Idealmente, o valor de cada um destes atributos deverá corresponder a um dos códigos de duas letras presentes na norma ISO-639. A utilização deste atributo é particularmente importante quando representamos no nosso documento XML, elementos que contenham texto escrito em línguas diferentes. A sua declaração aplica-se a um elemento pai, propagando-se a todos os filhos, até que um destes defina uma linguagem diferente, e poderá ser efectuada do seguinte modo: <! ELEMENT t ext o ( #PCDATA) > <! ATTLI ST t ext o xml : l ang NMTOKEN “ pt ” >

O elemento poderia ser algo do género: <t ext o xml : l ang=” pt ” >I st o é um t ext o em por t uguês</ t ext o>

A IANA possui uma lista de códigos das linguagens suportadas, que poderá ser encontrada no endereço http://www.isi.edu/in-notes/iana/assignments/languages/tags. O valor do atributo xml : l ang poderá possuir um sub-código adicional, separado do código inicial pelo símbolo ( - ). Uma utilização comum diz respeito à distinção de origens da língua portuguesa: <t ext o xml : l ang=” pt - PT” >Text o em por t uguês</ t ext o> <t ext o xml : l ang=” pt - BR” >Text o em br asi l ei r o</ t ext o>

Os tipos sugeridos para atributos deste género derivam do facto de necessitarmos de efectuar uma representação restrita dos seus valores possíveis. Poderemos utilizar o tipo NMTOKEN, como já vimos anteriormente, ou declarar um conjunto de identificadores de linguagens, através de um tipo Enumer at ed: <! ELEMENT t ext o ( #PCDATA) > <! ATTLI ST t ext o xml : l ang ( en| pt | br | l a) “ pt ” >

Como referi, também podemos utilizar o tipo CDATA, no entanto os dois anteriormente referidos são mais seguros em termos de detecção de eventuais erros.

Nem toda a informação que existe pode ser codificada através da XML. Com efeito, existe uma vasta gama de informação, como imagens, som, e outras, que necessitam da utilização de outras tecnologias para que possam ser transmitidas ou interpretadas.


79

A XML, disponibiliza três tipos de construções que permitem representar este tipo de informação: notações, entidades externas não interpretadas e instruções de processamento. As notações descrevem o formato da informação que não é XML. As entidades externas não interpretadas, disponibilizam uma forma de aceder exteriormente a essa informação. As instruções de processamento encarregam-se da apresentação da informação. � ��

O primeiro passo a tomar quando lidamos com informação “estranha” será identificar o seu formato e o modo como pode ser representada. Uma forma simples de lidar com o problema será através da definição de um conjunto de tags fixo, que identifique tipos de informação diferentes. Essas tags encarregar-se-iam de descrever as características mais importantes, para que uma aplicação fosse capaz de tratar devidamente a informação referenciada num documento, como por exemplo, no caso de informação áudio, indicar um programa de leitura adequado. As notações são construções XML que permitem efectuar o que foi descrito. Declaradas no DTD ao nível de outras construções já abordadas ( entidades, elementos, etc. ), apresentam a seguinte sintaxe: <! NOTATI ON nome_do_f or mat o SYSTEM “ i dent i f i cador _ext er no” >

O nome_do_formato é utilizado para identificar um tipo de formatação presente num documento, enquanto que o identificador_externo contém uma descrição perceptível da notação, por exemplo: <! NOTATI ON gi f SYSTEM “ i magens/ gi f ” >

As notações também poderão identificar entidades publicas, utilizando, ao invés da palavra chave SYSTEM, PUBLI C. Vejamos um exemplo que se revela muitas vezes problemático no nosso dia-a-dia como programadores, a representação de datas. Seguindo a forma de representação baseada em notações teríamos o seguinte:

<?xml ver si on=” 1. 0” st andal one=” yes” ?> <! DOCTYPE agenda [

<! NOTATI ON I SODATE SYSTEM “ ht t p: / / www. i so. ch/ cat e/ d15903. ht ml ” > <! ELEMENT agenda ( mar cacao* ) > <! ELEMENT mar cacao ( not a, dat a) > <! ATTLI ST dat a f or mat o NOTATI ON ( I SODATE ) #I MPLI ED> ] >

<agenda> <mar cacao> <not a>Descr i ção da mar cação</ not a> <dat a f or mat o=” I SODATE” >20010513</ dat a>


80

</ mar cacao> </ agenda>

Desta forma definiríamos para a representação de datas do documento, um formato standard existente no URL referenciado. ��

A XML não é uma linguagem adequada para representar qualquer tipo de formato, particularmente os que não envolvem texto ou podem ser representados como tal. O leitor poderá imaginar o que seria representar uma imagem recorrendo a instruções do tipo <PI XEL x=” 234” y=” 321” cor =” FF3452” / >. Uma página Internet, contém informação de variados tipos, som, imagem, animação, etc. A linguagem HTML, habituou-nos ( no caso do leitor ser familiarizado ), a representar estes tipos de informação através de um conjunto restrito de tags, que na maior parte das vezes passam por identificar um URL onde a informação pode ser recolhida. A XML também pode trabalhar assim, mas tal não será necessário. Para tal, utiliza as entidades externas não interpretadas. Estas, disponibilizam links para a localização da informação, servindo-se posteriormente de um tipo ENTI TY para associar a informação a um determinado elemento no documento. Já vimos como se podem utilizar entidades para aceder à informação, no entanto, neste caso estamos a falar de informação que não é XML. Nestes casos é necessária a utilização da palavra chave NDATA. Observemos o seguinte exemplo: <! ENTI TY l ogot i po SYSTEM “ l ogot i po. gi f ” NDATA gi f >

A palavra gi f , presente no final da instrução corresponde ao nome de uma notação declarada no DTD. A declaração de entidades externas não interpretadas não pode ser efectuada de qualquer maneira no DTD. Eis uma declaração válida:

<?xml ver si on=” 1. 0” st andal one=” no” ?> <! DOCTYPE dados [

<! ELEMENT dados ANY> <! ENTI TY l ogot i po SYSTEM “ l ogot i po. gi f ” NDATA gi f > <! NOTATI ON gi f SYSTEM “ i magens/ gi f ” > <! ELEMENT i magem EMPTY> <! ATTLI ST i magem l ocal i zacao ENTI TY #REQUI RED> ] >

<dados> <i magem l ocal i zacao=” l ogot i po” / > </ dados>


81

Para utilizar entidades externas não interpretadas declara-se o elemento que servirá para identificar a informação ( neste caso <i magem> ), e posteriormente o atributo de tipo ENTI TY para o referido elemento ( neste caso l ocal i zacao ). Este fornece o nome da entidade externa não interpretada. Após esta declaração, compete à aplicação a tarefa de reconhecer a informação e proceder à sua apresentação. Para terminar, saliento que é possível referir, não uma, mas várias entidades externas. O procedimento é análogo ao descrito até aqui, apenas sendo necessário declarar várias ENTI TY, para identificar a entidade externa. ��

As instruções de processamento são um mecanismo explicito utilizado para acrescentar a um documento, informação que apenas se destina a um conjunto de aplicações em particular, ou seja, não está destinada aos parsers nem aos browsers. Uma das suas formas de aplicação é precisamente a de disponibilizar informação adicional acerca de como representar entidades externas não interpretadas. Podemos identificar uma instrução de processamento através da sua delimitação pelos caracteres <? e ?>. No seu interior, existirá obrigatoriamente um nome XML, seguido dos dados pretendidos. Este nome poderá ser o de uma aplicação ou uma notação do DTD. As instruções de processamento não fazem parte da estrutura do documento, nem são elas próprias um elemento. A maior parte das aplicações que recolhem informação de documentos XML limitam-se a ignorar estas instruções. Podem ser colocadas em qualquer local do documento, exceptuando o interior de tags ou secções do tipo CDATA. Podem também existir no interior da declaração do DTD, no conteúdo de um elemento ou mesmo até após uma tag de fecho. O leitor ainda estará recordado, certamente, duma instrução de processamento que provavelmente agora até passará despercebida mas que nos tem acompanhado desde o inicio, <?xml ver si on=” 1. 0” st andal one=” no” ?>. As instruções denotadas com a sintaxe <?xml ?>, estão reservadas ao standard XML, no entanto, qualquer outra construção idealizada pelo autor de um documento será válida. A relação entre as instruções de processamento e as entidades externas não interpretadas, deriva do facto de a informação disponibilizada pelas ultimas em relação à primeira, se caracterizar por um conteúdo bem mais arbitrário, oferecendo assim um vasto leque de possibilidades de caracterização de informação. Com efeito, estas instruções podem ser utilizadas para fornecer informação, desde um nome de uma aplicação até ao seu tamanho em bytes.


82

Para terminar, saliento um ultimo aspecto importante em relação à utilização das instruções de processamento no contexto que referi anteriormente. É necessário que quer o autor do documento XML, quer a aplicação que o vai interpretar, identifiquem qual a instrução ou instruções, que dizem respeito à entidade externa.

Além dos comentários, que já tive a oportunidade de abordar, existem outras formas de condicionar o texto num DTD por forma a este não ser interpretado. Seguidamente apresento alguns exemplos: <! [ I GNORE Conj unt o de decl ar ações a ser i gnor ado. ] ] >

Podemos também incluir código: <! [ I NCLUDE Conj unt o de decl ar ações a ser em i ncl ui das ou não i gnor adas. ] ] >

De notar que quando a segunda instrução é colocada dentro da primeira, será também ela ignorada. O contrário já não é verdade. Após esta explicação, o leitor perguntar-se-á qual o sentido da utilização do conjunto <! [ I NCLUDE ] ] >. Vejamos a resposta: <! ENTI TY % i nf or macao “ I GNORE” > <! [ %i nf or macao; Decl ar ações. ] ] >

Agora imaginemos que em determinada altura alteramos a palavra I GNORE para I NCLUDE. O DTD veria o seu conteúdo completamente modificado.

Linguagens de Estilo

A linguagem XML Linguagens de Estilo

84

No primeiro capítulo deste manual, tive a oportunidade de introduzir este tema. Neste ponto irei aprofundar um pouco mais a utilização das CSSs, aproveitando para relembrar alguns dos conceitos relacionados. Como é óbvio este aprofundamento não será demasiado extensivo, mas antes uma abordagem dos aspectos essenciais da utilização desta tecnologia, ela própria merecedora de um documento que lhe fosse inteiramente dedicado. Um aspecto importante a salientar, diz respeito à existência de duas especificações da CSS, denominadas CSS de nível 1 e CSS de nível 2. A abordagem que irei efectuar cobre principalmente a primeira, para que de forma simples, o leitor possa entrar no conceito da especificação da representação deste tipo de folhas de estilo. Uma vez assimilado o conceito e entendida a forma como se processa este tipo de especificação, será mais fácil a evolução para a CSS de nível 2, mais vasta e poderosa em termos de recursos. Em relação a esta especificação, sintetizarei apenas alguns dos aspectos mais relevantes resultantes da evolução, destacando algumas diferenças em relação à anterior.

Basicamente, a CSS é uma linguagem baseada num conjunto de regras, cuja utilização se relaciona com a forma com que a informação presente num documento se apresenta a um utilizador, numa página de um browser. A definição das regras é aplicada sobre os elementos, definindo o estilo, em termos de cor, fonte, tamanho, gráficos e outras, com que a informação que contêm deverá ser apresentada. Analisemos o seguinte exemplo: poema { di spl ay: bl ock } t i t ul o { di spl ay: bl ock; f ont - s i ze: 16pt ; f ont - wei ght : bol d; } poet a { di spl ay: bl ock; mar gi n- bot t om: 10px } quadr a { di spl ay: bl ock; mar gi n- bot t om: 10px } ver so { di spl ay: bl ock; }

Esta folha de estilo enumera cinco regras. Cada uma delas identifica o elemento a que corresponde e o estilo com que deve ser apresentado, delimitado por chavetas { } . Todas as regras definem que os elementos deverão ser representados num bloco. O elemento <t i t ul o> deverá ser apresentado numa fonte destacada, de tamanho 16. Os elementos <poet a> e <quadr a> indicam ainda que a sua representação deverá estar distanciada 10 pixels do item seguinte a ser apresentado na página do browser.


85

Supondo que guardaríamos a descrição anterior com o nome de poemas.css - aproveito para destacar a extensão ( .css ) - poderíamos aplicar a nossa folha a um documento da seguinte forma:

<?xml ver si on=” 1. 0” ?> <?xml - st y l esheet t ype=” t ext / css” hr ef =” poemas. css” ?> <poema> <t i t ul o>Ti t ul o</ t i t ul o> <poet a>Nome do Poet a</ poet a> <quadr a> <ver so>Ver so 1</ ver so> <ver so>Ver so 2</ ver so> </ quadr a> </ poema>

A instrução de processamento <?xml - st y l esheet ?>, encarrega-se de estabelecer a ligação entre o documento e a folha de estilos, conduzindo um browser a apresentar a informação de acordo com o especificado. O atributo t ype indica o tipo de folha de estilos que está a ser utilizado, e o atributo hr ef indica a sua localização física. De notar que esta localização poderá ser absoluta ou relativa, sendo representada sob a forma de um URL. Num mesmo documento poderão ser utilizadas várias instruções de processamento como esta, referenciando folhas de estilo diferentes.

A parte da regra que refere o elemento designa-se por selector. O selector da regra do exemplo seguinte será t i t ul o: t i t ul o { di spl ay: bl ock; f ont - s i ze: 16pt ; f ont - wei ght : bol d; }

No entanto, os selectores podem especificar mais do que um elemento, assim como o mesmo elemento pode ter mais do que uma regra aplicada: poema, t i t ul o { di spl ay: bl ock } t i t ul o { f ont - s i ze: 16pt ; f ont - wei ght : bol d; }

Existem dois pseudo-elementos utilizados para referir itens de um documento que não são elementos propriamente ditos, mas uma parte de um elemento. Imaginemos o elemento <capí t ul o>: capí t ul o: f i r st - l et t er { f ont - s i ze: 300%; ver t i cal - al i gn: t ext - t op } capí t ul o: f i r st - l i ne { f ont - var i ant : smal l - caps }

Neste exemplo, são utilizados dois pseudo-elementos, f i r s t - l et t er e f i r s t - l i ne, que identificam respectivamente, as formas de representação da primeira letra e da primeira


86

linha da informação contida no elemento <capí t ul o>. Este tipo de formatações é muito habitual em textos de revistas, livros, etc. De notar apenas, no caso do f i r s t - l i ne, que o conteúdo a ser formatado como primeira linha depende directamente do tamanho da janela do browser. Outro conceito interessante é o de pseudo-classe. Se pretendermos que elementos do mesmo tipo tenham associadas formas de apresentação diferentes, podemos acrescentar-lhes um atributo distintivo, caracterizando-o posteriormente na CSS, de forma diferente. Vejamos como:

<?xml ver si on=” 1. 0” ?> <?xml - st y l esheet t ype=” t ext / css” hr ef =” bi bl i ogr af i a. css” ?> <bi bl i ogr af i a> <ci t acao aut or =” Aut or 1” i d=” 1” > <t ext o>Text o da ci t ação. </ t ext o> </ c i t acao> <ci t acao aut or =” Aut or 2” i d=” 2” > <t ext o>Text o da ci t ação. </ t ext o> </ c i t acao> </ bi bl i ogr af i a>

A folha de estilos bibliografia.css, conteria as seguintes regras: bi bl i ogr af i a { di spl ay: bl ock } c i t acao. Aut or 1 { col or : bl ue } c i t acao. Aut or 2 { col or : r ed }

Desta forma, o elemento <ci t acao>, teria duas representações distintas com base no valor do seu atributo aut or . Um aspecto importante a salientar, prende-se com o facto de que a declaração deste atributo deverá fazer parte dum DTD de validação do documento, caso contrário este será classificado como inválido. Por vezes, necessitamos que um elemento único possua uma representação igualmente única. Para tal adicionamos mais um atributo do tipo I D ao elemento, podendo assim construir uma regra na CSS com base no conteúdo desse atributo, da seguinte forma: c i t acao#1 { f ont - wei ght : bol d }

Existe ainda a possibilidade de individualizarmos a representação de elementos filho, definindo na CSS uma hierarquia de aplicação: t i t ul o { f ont - s i ze: 16pt ; f ont - wei ght : bol d; } not i c i a t i t ul o { f ont - s i ze: 12pt ; f ont - wei ght : bol d; }

Neste caso os elementos <t i t ul o> filhos do elemento <not i ci a>, têm um tamanho de fonte diferente dos restantes elementos com a mesma designação, que se encontrem em níveis hierárquicos diferentes.


87

O atributos de estilo são utilizados para modificar características de determinados elementos sem haver necessidade de editar directamente o conteúdo da CSS. Será suficiente acrescentar um atributo st y l e ao elemento sobre o qual pretendemos aplicar um novo estilo. Este atributo, poderá conter um conjunto de características, separadas por virgulas, conferindo-lhe assim um amplo leque de possibilidades.

<?xml ver si on=” 1. 0” ?> <?xml - st y l esheet t ype=” t ext / css” hr ef =” bi bl i ogr af i a. css” ?> <bi bl i ogr af i a> <ci t acao aut or =” Aut or 1” i d=” 1” st y l e=” f ont - s i ze: 16pt ; f ont - wei ght : bol d” > <t ext o>Text o da ci t ação. </ t ext o> </ c i t acao> </ bi bl i ogr af i a>

No exemplo anterior, acrescentei ao elemento <ci t acao> um atributo st y l e que configura duas características da fonte, a serem aplicadas aquando da apresentação de informação. Se as propriedades definidas num atributo st y l e entrarem em conflito com as definidas na CSS, tomarão precedência as primeiras. Embora a utilização destas construções se revele vantajosa em determinadas circunstâncias, ela deverá ser evitada uma vez que é uma fonte de inconsistência e desorganização em termos da especificação do documento, conduzindo, na maior parte das vezes, a dificuldades de manutenção do código. Do mesmo modo do que já referi em relação às pseudo-classes, será necessário declarar este atributo num DTD de validação do documento, se pretendermos que ele seja assim classificado.

A CSS não requer que as propriedades sejam definidas de forma particular em cada elemento de um documento. O conceito de herança, permite que as propriedades existentes em elementos de nível superior sejam propagadas aos seus descendentes, sempre que as mesmas não sejam definidas por estes. Vejamos o seguinte exemplo:

t i t ul o { f ont - wei gt h: bol d; f ont - s i ze: 24pt ; f ont - f ami l y: sans- ser i f } subt i t ul o { f ont - st y l e: i t al i c; f ont - f ami l y: ser i f }

Analisando o código XML:


88

<t i t ul o>

Est e é o t i t ul o <subt i t ul o>Est e é o subt i t ul o</ subt i t ul o>

</ t i t ul o>

Embora o elemento <subt i t ul o> não tenha especificado um tamanho de fonte ou um estilo de fonte, vai herdar estas propriedades, por ter sido representado como filho do elemento <t i t ul o>. No caso da família da fonte, cada elemento será representado com a respectiva definição que individual.

É possível utilizar mais do que uma CSS no mesmo documento. Nestes casos, a existência de regras conflituosas deverá ser resolvida pela sua ordem de aplicação. Este processo denomina-se cascade, e é daqui que decorre a notação Cascading Style Sheets. Existem várias formas de ligar uma CSS a um documento:

� Utilizando uma instrução de processamento do tipo <?xml - st y l esheet ?>; � Utilizando a directiva @i mpor t ; � Especificando um mecanismo de importação no próprio browser; � O próprio browser define a maioria das propriedades por defeito.

Podemos incluir nas CSSs directivas do tipo @i mpor t , com o objectivo de ler outras CSSs externas. Normalmente, a sua localização é referida à custa de um URL, como no exemplo seguinte:

@i mpor t ur l ( ht t p: / / www. w3. or g/ basi cst y l es. css) ;

Devemos incluir esta directiva sempre no inicio da CSS, antes de definirmos qualquer tipo de regra. As regras definidas nas CSSs importadas não têm precedência sobre as regras definidas pelas CSSs importadoras. As regras aplicam-se na mesma ordem em que as folhas são importadas. Os estilos dos elementos são obtidos a partir das regras que lhe estão associadas nas CSSs. Existe uma questão de especificidade relacionada com a forma como estas regras são aplicadas. As regras definidas para um elemento na sua posição efectiva têm precedência sobre as regras definidas para o mesmo elemento, utilizando um representação hierárquica.


89

As propriedades definidas nas CSSs têm nomes e valores. Todos os nomes utilizados são palavras reservadas, no entanto, os valores que representam podem ser bastante diversos. Diferentes propriedades permitem diferentes valores, que se resumem aos tipos length, URL, color e keyword. A única variante, entre os diversos tipos de propriedades, é a keyword. Todas as outras se mantêm. � ��

O comprimento nas CSSs, é uma medida escalar utilizada para definir alturas, comprimentos, espaçamento de fontes, indentações, margens, etc., podendo ser especificadas em unidades relativas, absolutas ou percentagens. O conceito de unidade absoluta de comprimento num monitor, é algo um pouco incipiente uma vez que fica sempre dependente da resolução aplicada. De qualquer das formas, podem ser representadas por Inches ( i n ), Centímetros ( cm ), milímetros ( mm ), pontos ( pt ), ou picas ( pc ). Algumas propriedades permitem valores negativos. As representações relativas de comprimento efectuação recorrendo à notação em, ex e px. As duas primeiras dizem respeito ao comprimento e altura, respectivamente. A ultima define o tamanho dos pixels. As representações em percentagem são sempre relativas a um determinado item. Por exemplo, se o valor de uma fonte de um elemento <quadr a> é de 12 pontos, e o valor da fonte de um elemento <ver so>, filho do anterior, é de 150%, então a fonte do verso será 18 pontos. � ��

Existem propriedades que possuem valores deste tipo, como por exemplo backgr oud-

i mage, l i s t - st y l e- i mage, etc. Como já referi anteriormente, as directivas @i mpor t são outro exemplo da sua utilização. A utilização destes valores deve obedecer à seguinte sintaxe:

ur l ( nome_do_URL )

São aceites todas as formas de URLs, relativas ou absolutas. Todos os caracteres do tipo parêntesis, virgulas, espaços em branco, pelicas ou aspas, devem ser precedidos do símbolo \ ( backslash ).


90

No caso do nome_do_URL possuir caracteres deste tipo, eles devem ser precedidos de % seguido do respectivo código. � ��

A possibilidade de aplicação de cores de fundo e cores de topo está disponível em quase todos os elementos de uma página. Algumas das propriedades utilizadas são: col or , backgr ound- col or ou bor der - col or . As CSSs disponibilizam quatro formas de especificar uma cor: pelo nome, pelo seu formato hexadecimal, por números inteiros ou por percentagens. Alguns nomes utilizados: aqua, black, blue, gray, green, lime, maroon, navy, olive, purple, red, silver, teal, white e yellow. Normalmente, esta é a notação mais comum. No entanto, a manipulação de cores é muitas vezes representada em percentagem, por exemplo: vermelho seria r gb( 100%, 0%, 0%) , ou em RGB decimal, r gb( 255, 0, 0) . � ��

As keywords são o tipo mais variável dos anteriormente referidos. Não sendo os mesmos de propriedade para propriedade, têm significados similares em propriedades diferentes. Por exemplo, no caso dos estilos de um bordo esquerdo, referido pela propriedade bor der - l ef t - st y l e, teremos as keywords possíveis: none, dotted, dashed, solid, double, groove, ridge, inset ou outset. Para representar qualquer um dos outros bordos, as keywords seriam as mesmas, mantendo o seu significado.

Na perspectiva da CSS de nível 1 todos os elementos são do tipo bl ock, i nl i ne, l i s t -

i t em ou i nv i s i bl e. A CSS de nível 2 acrescenta mais algumas possibilidades. O tipo de representação de um determinado elemento é identificado pela propriedade di spl ay. É esta propriedade que utiliza as keywords bl ock, i nl i ne, l i s t - i t em e i nv i s i bl e. De uma forma básica, os elementos do tipo i nl i ne, não estão separados do resto do texto. Se tivermos presente a HTML, são exemplos das notações <I >, <B>, <A>, etc. Os elementos do tipo bl ock, separam-se dos restantes, normalmente através de quebras de linha. Estão associados às notações <P>, <HR>, <BR>, etc. Os elementos do tipo bl ock podem conter outros do mesmo tipo ou i nl i ne. Os elementos do tipo l i s t - i t em são


91

elementos do tipo bl ock envolvidos por um elemento do tipo <LI >. Finalmente, elementos cuja propriedade di spl ay seja colocada a none são invisíveis. Para que o leitor tenha uma percepção mais concreta das noções apresentadas e da utilização efectiva destas keywords, vamos analisar a construção de uma CSS para o seguinte documento:

<?xml ver si on=” 1. 0” ?> <?xml - st y l esheet t ype=” t ext / css” hr ef =” peca_t eat r al . css” ?> <peca> <t i t ul o>Ti t ul o</ t i t ul o> <act o> <numer o>Act o 1</ numer o> <cena> <numer o>Cena 1</ numer o> <l ocal >Local da Cena 1</ l ocal > </ cena> <cena> <numer o>Cena 2</ numer o> <l ocal >Local da Cena 2</ l ocal > </ cena> <cena> <numer o>Cena 3</ numer o> <l ocal >Local da Cena 3</ l ocal > </ cena> </ act o> <act o> <numer o>Act o 2</ numer o> <cena> <numer o>Cena 1</ numer o> <l ocal >Local da Cena 1</ l ocal > </ cena> <cena> <numer o>Cena 2</ numer o> <l ocal >Local da Cena 2</ l ocal > </ cena> <cena> <numer o>Cena 3</ numer o> <l ocal >Local da Cena 3</ l ocal > </ cena> </ act o> </ peca>

O documento, retracta o exemplo simples da organização de informação de uma peça teatral, ou uma opera, por exemplo. Uma CSS inicial poderia corresponder ao seguinte:

peca, t i t ul o, act o, cena { di spl ay: bl ock }

A figura seguinte apresenta um aspecto do documento anterior, utilizando esta CSS:


92

fig. 4 Podemos observar o efeito da utilização da keyword bl ock, na representação da informação. Existem alguns aspectos a ter em conta. A CSS definida não necessita da especificação dos elementos <cena>, <l ocal > e <numer o> como i nl i ne. Este facto é assumido por defeito. A propriedade di spl ay, não é herdada pelos filhos dos elementos especificados na CSS, uma vez que o facto de o elemento <cena> ser um bloco não implica que os seus filhos também o sejam. Poderíamos alterar a CSS para a utilização de elementos do tipo l i s t - i t em. Esta ficaria com o seguinte aspecto:

peca, t i t ul o { di spl ay: bl ock } act o { di spl ay: l i s t - i t em; l i s t - st y l e- t ype: squar e } cena { di spl ay: l i s t - i t em; l i s t - st y l e- t ype: squar e }

As CSSs possuem um conjunto considerável de propriedades que podemos utilizar para a caracterização de elementos nos nossos documentos XML. Podemos agrupar essas propriedades de acordo com o contexto de utilização, ou seja, com características particulares que serão aplicadas sobre elementos.


93

Deste modo podemos ter propriedades referentes a aspectos como fontes, cores ( já abordado ), aspectos de fundo, texto, caixas, tamanhos e posicionamento. De uma forma resumida, apresento seguidamente algumas das propriedades mais relevantes associadas a cada um destes grupos. A sintaxe utilizada para cada uma das propriedades é em tudo igual aos exemplos de construções de CSSs que tenho vindo a apresentar, ou seja:

el ement o { pr opr i edade: val or es }

Como já vimos anteriormente, os valores podem ser representados por keywords, isoladamente ou sob a forma de uma lista, separada por virgulas. � ��

As propriedades relacionadas com fontes oferecem um conjunto alargado de características que poderemos utilizar isoladamente ou de forma combinada. A tabela seguinte apresenta algumas propriedades disponíveis e a sua descrição: Propriedade Descrição font-family Define um conjunto de nomes de fontes, separados por virgulas, como

por exemplo ser i f , sans- ser i f , cur si ve, monospace, f ant asy. font-style Define o estilo. Tem três valores: nor mal , i t al i c e obl i que. font-variant Define a capitalização. Pode assumir valores nor mal ou smal l - caps. font-weight Define a espessura da fonte. Pode assumir os valores nor mal , bol d,

bol der ou l i ght er . font-size Define o tamanho da fonte. Pode assumir os valores xx- smal , x- smal l ,

smal l , medi um, l ar ge, x- l ar ge, xx- l ar ge. � � ��

� ��

O aspecto de fundo de um elemento pode ser uma cor ou uma imagem. No caso de ser uma imagem, existem várias possibilidades de representar a sua disposição. A tabela seguinte apresenta algumas das propriedades relacionadas com o posicionamento da imagem. Propriedade Descrição background-color Define a cor de fundo dos elementos. Pode ser utilizado

qualquer tipo de representação de cor e adicionalmente a keywor d t r anspar ent .

background-image Define a cor de fundo de uma imagem. Pode assumir os valores none ou o URL de localização da imagem.


94

background-repeat Define a organização das imagens como pano de fundo. Pode assumir os valores r epeat , r epeat - x, r epeat - y ou no-

r epeat . background-attachment Define o nível de ligação da imagem à janela do browser ou

à página propriamente dita. Pode assumir os valores scr ol l ou f i xed.

background-position Define o alinhamento da imagem relativamente ao elemento ao qual está ligada. Pode assumir valores t op, cent er , bot t om, l ef t ou r i ght .

��

Existem várias propriedades que definem a forma como o texto se apresenta, independentemente da fonte que está a ser utilizada: Propriedade Descrição word-spacing Define o espaço existente entre cada palavra. Pode assumir

valores relativos ao comprimento. letter-spacing Define o espaço existente entre cada letra. Pode assumir

valores relativos ao comprimento. text-decoration Pode assumir os valores none, under l i ne, over l i ne, l i ne-

t hr ough, bl i nk. vertical-align Define o alinhamento relativamente à base do texto. Pode

assumir os valores basel i ne, sub, super , t op, t ext - t op, mi ddl e, bot t om ou t ext - bot t om.

text-transform Define se o texto é representado totalmente em maiúsculas ou minúsculas. Pode assumir os valores capi t al i ze, upper case, l ower case ou none.

text-align Define o alinhamento horizontal do texto. Apenas pode ser utilizado em elementos do tipo bl ock. Pode assumir os valores l ef t , r i ght , cent er ou j ust i f y .

text-indent Define a indentação da primeira linha de um bloco, relativamente às restantes. Apenas pode ser utilizado em elementos do tipo bl ock. Pode assumir valores relativos ao comprimento.

line-height Define a distancia entre as linhas do texto. Pode assumir valores relativos à altura.

��

As CSSs definem um espaço bidimensional onde pode ser apresentada a informação. As propriedades relacionadas com este tipo de representação, permitem-nos definir valores


95

para altura, largura, margens, bordos, tamanhos e posicionamento. A tabela seguinte apresenta algumas dessas propriedades. Área Propriedade Definição Margem margin-top Define o valor da margem de topo. margin-bottom Define o valor da margem de fundo. margin-right Define o valor da margem direita. margin-left Define o valor da margem esquerda. Bordo border-style Define o aspecto do bordo da caixa. Pode

assumir valores dot t ed, dashed, sol i d, doubl e, gr oove, r i dge, i nset ou out set .

border-top-width Define a largura da linha do bordo superior. Pode assumir valores t hi n, medi um, t hi ck.

border-right-width Define a largura da linha do bordo direito. Pode assumir valores t hi n, medi um, t hi ck.

border-bottom-width Define a largura da linha do bordo inferior. Pode assumir valores t hi n, medi um, t hi ck.

border-left-width Define a largura da linha do bordo esquerdo. Pode assumir valores t hi n, medi um, t hi ck.

border-color Define a cor do bordo. Pode assumir valores baseados na representação de cores.

Tamanho width Define a largura da caixa. Assume valores

relativos à largura. height Define a altura da caixa. Assume valores

relativos à altura. Posicionamento float Define o posicionamento do elemento.

Assume os valores none, l ef t ou r i ght . clear Define se o elemento pode ter itens

flutuantes nas suas zonas laterais. Assume os valores none, l ef t , r i ght ou bot h.

O surgimento da CSS de nível 2 ( CSS2 ) veio contribuir com um aumento de potencial bastante elevado no desenvolvimento de folhas de estilo para apresentação de documentos XML e HTML. Incorporando características já há muito tempo esperadas pelos responsáveis pelo desenvolvimento orientado para a Internet, a especificação da CSS2 praticamente duplicou a original. Seguidamente vou sintetizar os aspectos mais importantes relacionados com a evolução da CSS, deixando aqui o convite ao leitor a visitar o endereço onde pode encontrar a


96

especificação completa, http://www.w3.org./tr /rec-css2. Esta síntese aborda alguns dos aspectos mais relevantes em termos de evolução, salientando algumas das diferenças existentes entre as duas implementações. As novas características disponibilizadas por este formato permitem logo à partida uma selecção e formatação mais precisa dos elementos. Foram criadas novas pseudo-classes e novos pseudo-elementos, tipos media, internacionalização, controle da formatação visual, tabelas, e muitas outras. As pseudo-classes seleccionam elementos que tenham algo em comum mas que não sejam necessariamente do mesmo tipo. A pseudo-classe : hover , por exemplo, refere um qualquer elemento seleccionado para tratamento, independentemente do seu tipo. Os pseudo-elementos identificam elementos específicos, através de informação distinta daquela que está disponível no documento XML. Por exemplo, os pseudo-elementos : f i r s t - l i ne e : f i r s t - l et t er , que tive a oportunidade de referir, seleccionam respectivamente a primeira linha e a primeira letra, independentemente destas estarem directamente representadas por um elemento. A CSS2 adiciona dois novos pseudo-elementos, : af t er e : bef or e. O primeiro permite a inserção de objectos após de um determinado elemento. Estes objectos podem ser imagens, contadores automáticos ou texto. O segundo, permite efectuar o mesmo processo antes um determinado elemento. A CSS2 define dez tipos media, dos quais o Braille e a televisão, são apenas dois exemplos. É possível especificar estilos diferentes para tipos diferentes. São ainda disponibilizados novos controlos sobre quebras de página e métodos de identificar individualmente páginas de um documento. Esta capacidade permite a formatação de documentos para impressão sem afectar o seu aspecto no monitor. Como meio de comunicação e de apresentação de informação internacional, foram conseguidos grandes avanços no suporte de novas linguagens. A CSS2 suporta Unicode e texto bidireccional, por forma a que possamos personalizar as línguas chinesa ou hebraica tão facilmente como o inglês ou o francês. As propriedades de formatação cresceram em numero e versatilidade, oferecendo um nível mais elevado de controlo sobre os elementos formatados. Podemos ainda especificar as posições e dimensões absolutas de elementos. Foram também acrescentados mais estilos, desde a formatação de letra até ao aspecto do rato. Os avanços conseguidos ao nível da propriedade di spl ay, facilitam o tratamento dos elementos sob a forma XML, através de um esquema baseado em tabelas. A geração automática de conteúdo, à medida que a página vai sendo apresentada, é outro dos pontos interessantes que saíram bastante melhorados nesta nova versão.


97

A nova especificação também mudou a forma como algumas características estavam definidas na CSS1. Incluídas no lote de alterações estão as pseudo-classes, os mecanismos de cascading e uma variedade de propriedades. Um dos aspectos a salientar tem a haver com o conceito de herança. Na CSS2, todas as propriedades dos elementos filho, podem herdar dos elementos pai, utilizando para tal a keyword i nher i t . Quando uma propriedade utiliza esta notação, herda do “parente” mais próximo. Os mecanismos de cascading, na CSS1, utilizavam uma notação denominada !ignore, para que o autor da folha de estilo tivesse sempre a maior precedência. Na CSS2, este facto é revertido. A propriedade di spl ay, passa a ser entendida como i nl i ne. Recordo que na CSS1, esta propriedade era considerada do tipo bl ock. Um ultimo aspecto está relacionado com o tratamento de margens. Enquanto que na CSS1, algumas propriedade seriam ignoradas se estivessem na presença de outras, na CSS2 existem critérios mais correctos na aplicação de propriedades.


98

A XSL ( Extensible Style Language ), é composta por uma linguagem de transformação e uma linguagem de formatação. Cada uma delas, é uma aplicação XML. A primeira, disponibiliza um conjunto de regras utilizado para transformar um documento XML num outro documento XML. Este documento transformado, poderá utilizar um DTD do documento original, ou simplesmente utilizar um conjunto de tags definido pela linguagem de formatação. Neste documento abordarei apenas a vertente das transformações XSL, procurando destacar os aspectos mais relevantes da sua utilização, permitindo ao leitor o enquadramento essencial com esta linguagem. Como se compreende, descrever a globalidade da XSL, só por si, conduziria ao desenvolvimento de um único documento. Em relação à vertente de formatação em XSL, ela está ainda num processo de evolução, e a sua estruturação continua a ser revista e re-implementada. Alguns autores, mais pessimistas referem o facto de esta especificação ser uma sobreposição da CSS2, não acrescentando nada de novo, além da sintaxe. Outros, mais optimistas, afirmam que a XSL-FO ( XSL Formating Objects ) terá a longo prazo o seu lugar no campo da apresentação de informação. Entretanto, os browsers existentes ainda têm bastantes “dificuldades” em trabalhar com esta especificação. Com base neste conjunto de factores, não abordarei neste documento a vertente da formatação, por correr o risco de estar a transmitir ao leitor informação que além de não estar a ser utilizada, ficará obsoleta num curto espaço de tempo.

A transformação de documentos XML funciona independentemente da linguagem de formatação. Essencialmente, a função das transformações XSL consiste em construir dinamicamente, através da junção entre informação XML e, por exemplo HTML, documentos passíveis de serem processados por um browser. Baseado nas instruções presentes no documento XSL, o processador gera um novo documento XML. � � � ��

Todo o documento XML bem formado tem a estrutura de uma árvore de elementos. Partindo da raiz, esta estrutura poderá desenvolver-se num numero infinito de ramos, denominados elementos filho. Por seu turno, estes filhos poderão conter outros, e assim


99

sucessivamente, dando origem a uma estrutura capaz de crescer em tamanho e complexidade. Nesta perspectiva, poderemos dizer que uma árvore não é mais do que um conjunto constituído por outras árvores, mais pequenas. Os nós da árvore são os elementos e o seu conteúdo. No entanto, em XSL, os atributos, as instruções de processamento, etc., também são considerados nós. Assim os tipos de nós a considerar em XSL são os seguintes:

� Raiz; � Elementos; � Texto; � Atributos; � Namespaces; � Instruções de processamento; � Comentários.

Vejamos uma árvore gráfica, para que o leitor fique com uma percepção mais concreta acerca do conceito: Esta árvore, seria representada num documento XML da seguinte forma:

<Rai z> <El ement o1 At r i but o1=” val or ” > <El ement o11>Val or </ El ement o11> </ El ement o1> <El ement o2> <El ement o21>Val or </ El ement o21> <El ement o22 At r i but o21=” val or ” > <El ement o221/ > </ El ement o22> </ El ement o2> </ Rai z>

Raiz

Atributo1=”valor”

Elemento1 Elemento2

Elemento11 Elemento21 Elemento22

Atributo21=”valor”

Elemento2211

Valor Valor


100

A ideia base, já referida, é que uma transformação XSL converte um documento XML num novo documento XML, com uma árvore diferente, ou seja, o processo requer que tanto o input como o output sejam documentos XML bem formados. Recordando alguns conceitos já abordados, um documento XSL contém uma lista de regras, algumas das quais designadas de templates. Os templates são constituídos por um padrão, que identifica as árvores de informação à qual se aplicam, e pelas regras de formatação aplicadas para apresentar essa informação. Através do processamento de um documento XSL, a informação contida num documento XML relacionado, vai ser confrontada com o conjunto de padrões definidos nos templates descritos. Por cada match concretizado, a informação obtida vai ser combinada com a formatação presente no interior do template, sendo gerado um novo documento de output. A XSL utiliza as regras da XML para definir todo o este processo. O documento XSL está delimitado por um elemento raiz, denominado <xsl : st yl esheet >, e cada template é um elemento identificado por <xsl : t empl at e >. Por sua vez, o padrão para a concretização de um match definido no template não é mais do que um atributo. Deste modo, facilmente se deduz que todas as instruções XSL são elementos identificados por tags do tipo <xsl : i nst r ução >. Vejamos o exemplo seguinte:

<?xml ver si on=” 1. 0” ?> <xsl : st y l esheet xml ns: xsl =” ht t p: / / www. w3. or g/ TR/ WD- xsl ” > <xsl : t empl at e mat ch=” not i ci as” > <ht ml > <xsl : appl y- t empl at es/ > </ ht ml > </ xsl : t empl at e> <xsl : t empl at e mat ch=” not i ci a” > <ht ml > <xsl : appl y- t empl at es/ > </ ht ml > </ xsl : t empl at e> </ xsl : s t y l esheet >

Relembrando agora o nosso saudoso exemplo da informação noticiosa, observamos que este documento XSL, possui dois templates, o primeiro processará toda a informação identificada no documento XML com o elemento <not i ci as>, o segundo, encarregar-se-á da informação contida nesse elemento, ou seja, a noticia propriamente dita. A instrução <xsl : appl y- t empl at es/ > tem a função de incluir apenas a informação ( não a marcação ) proveniente do documento XML.


101

O processo de transformação entre um documento XML e um outro formato, normalmente HTML, através de um documento XSL, pode ocorrer das seguintes formas:

� O documento XML e a folha de estilos associada são ambas enviadas ao cliente, o browser, que posteriormente se encarrega de transformar a informação e de a apresentar ao utilizador;

� O servidor aplica a folha XSL sobre um documento XML para efectuar a

transformação enviando posteriormente o resultado ao cliente, que o apresenta ao utilizador;

� Uma terceira aplicação, transforma o documento XML noutro formato antes deste

ser colocado no servidor. Ambos, o servidor e o cliente, apenas manipulam o documento transformado.

Cada uma destas abordagens utiliza um software diferente, embora todas elas manipulem os mesmos documentos, ou seja, XML e XSL. Compete ao programador, decidir qual das abordagens será mais vantajosa para aplicação sobre um determinado projecto. Será conveniente ter sempre em conta, a quantidade de informação a ser processada para que se possa decidir como deverão ser distribuídas as “cargas” de processamento entre cliente e servidor.

As regras definidas pelos templates são as mais importantes de um documento XSL. Cada template é um elemento que será associado a uma determinada informação de input, correspondente ao atributo definido como mat ch. Um template pode conter texto, que irá aparecer inalterado no documento final, e instruções XSL que se encarregam de copiar informação do documento XML para o documento final. Como todas as instruções XSL estão identificadas por elementos do tipo <xsl : >, é bastante fácil distingui-las da restante informação. �

��

Para que possamos extrair informação para além da raiz de um documento XML, é necessário efectuar um processamento recursivo que traduza a navegação através de elementos filho. O elemento <xsl : appl y- t empl at es> encarrega-se de despoletar este processamento sempre que é invocado. À medida que o documento XSL é processado a presença desta instrução faz com que sejam aplicados todos os templates existentes.


102

Sempre que ocorre um match com um elemento do documento XML, é aplicado o template respectivo. Note-se que um template poderá conter ele próprio instruções deste tipo. Porque considero importante que o leitor compreenda o processamento de templates, vou apresentar uma espécie de processamento passo a passo. Observemos o seguinte documento XSL:

<?xml ver si on=” 1. 0” ?> <xsl : st y l esheet xml ns: xsl =” ht t p: / / www. w3. or g/ TR/ WD- xsl ” > <xsl : t empl at e mat ch=” / ” > <ht ml > <xsl : appl y- t empl at es/ > </ ht ml > </ xsl : t empl at e> <xsl : t empl at e mat ch=” not i ci as” > <body> <xsl : appl y- t empl at es/ > </ body> </ xsl : t empl at e> <xsl : t empl at e mat ch=” not i ci a” > Uma not i ci a. </ xsl : t empl at e> </ xsl : s t y l esheet >

E o documento XML ao qual será aplicado:

<?xml ver si on=" 1. 0" ?> <?xml - st y l esheet t ype=" t ext / xsl " hr ef =" document o. xsl " ?> <not i ci as> <not i c i a codi go=" 1" dat a=" 12- 04- 2001" > <t i t ul o>Ti t ul o 1</ t i t ul o> <sumar i o>Sumar i o da not i c i a numer o 1. </ sumar i o> </ not i c i a> <not i c i a codi go=" 2" dat a=" 15- 04- 2001" > <t i t ul o>Ti t ul o 2</ t i t ul o> <sumar i o>Sumar i o da not i c i a numer o 2. </ sumar i o> </ not i c i a> </ not i c i as>

O processo desenrola-se da seguinte forma: A raiz do documento XML vai ser comparada com todos os templates presentes no documento XSL. É efectuado um match com “ /” . O primeiro template é aplicado sendo escrita no documento resultado a tag <ht ml >. A instrução <xsl : appl y- t empl at es/ >

origina o processamento dos elementos filho do elemento raiz..


103

O primeiro elemento da raiz <?xml : st y l esheet >, não consegue fazer match com nenhum template. O processamento avança para o segundo elemento, <not i ci as>. O match é efectuado com o segundo template. Como aconteceu anteriormente, o elemento <body> é escrito no documento resultado. A instrução <xsl : appl y- t empl at es/ > origina um novo processamento dos elementos filho, agora do elemento <not i ci as>. O primeiro filho de <not i ci as>, é <not i ci a>. Concretizado mais um match, desta vez com o terceiro template, é escrito o texto “Uma noticia.” . O segundo filho volta a concretizar o match. É novamente escrito o texto. Terminado o processamento recursivo, são escritos os elementos </ body> e </ ht ml >. O nosso documento resultado seria:

<ht ml ><body> Uma not i c i a. Uma not i c i a. </ body></ ht ml >

Como se pode constatar, o processo recursivo é bastante simples e intuitivo, sendo aplicado a cada membro da árvore sempre da mesma forma. �

��

Para que possamos substituir o texto “Uma noticia.” , por exemplo com o seu titulo, devemos recorrer à utilização do atributo sel ect . Ao ser utilizado, este atributo indica que apenas os elementos indicados deverão ser processados. Vejamos como:

<xsl : t empl at e mat ch=” not i c i a” > <xsl : appl y- t empl at es sel ect =” t i t ul o” / > </ xsl : t empl at e>

Como resultado da aplicação desta regra, obteríamos o seguinte documento resultado:

<ht ml ><body> Ti t ul o 1 Ti t ul o 2 </ body></ ht ml >

Esta instrução copia o valor de um elemento do documento XML para o documento resultado. O atributo sel ect , também presente nesta instrução, indica qual o elemento pretendido. O exemplo anterior poderia então ser codificado da seguinte forma:


104

<xsl : t empl at e mat ch=” not i c i a” > <xsl : val ue- of sel ect =” t i t ul o” / > </ xsl : t empl at e>

O documento resultado seria exactamente o mesmo. Devemos ter sempre em atenção que o item identificado pelo atributo sel ect , se refere ao elemento origem com o qual foi efectuado o match do template, neste caso <not i ci a>. O valor recolhido por esta instrução diz respeito apenas a texto. Não são incluídas as tags de marcação, comentários ou outro tipo de representações que não digam respeito à informação.

A utilização da instrução xsl : val ue- of , não deve ser feita quando estamos na presença de informação ambígua, ou seja, quando existem vários elementos de um determinado tipo, uma vez que apenas será identificado o primeiro elemento encontrado. O exemplo seguinte seria um desses casos:

<xsl : t empl at e mat ch=” not i c i as” > <xsl : val ue- of sel ect =” not i ci a” / > </ xsl : t empl at e>

Como existem vários elementos do tipo <not i ci a>, a informação não seria processada na totalidade, mas apenas a primeira ocorrência. Existem então duas formas de processar múltiplos elementos. A primeira já abordada, é através da utilização da instrução <xsl : appl y- t empl at es/ >:

<xsl : t empl at e mat ch=” not i c i as” > <xsl : appl y- t empl at es sel ect =” not i c i a” / > </ xsl : t empl at e>

<xsl : t empl at e mat ch=” not i c i a” > <xsl : val ue- of sel ect =” . ” / > </ xsl : t empl at e>

O atributo sel ect =” . ” do segundo template, indica ao processador para recolher o valor do elemento com o qual foi efectuado o match, neste caso, <not i ci a>. Utilizando a instrução xsl : f or - each, teríamos algo do género:

<xsl : t empl at e mat ch=” not i c i as” > <xsl : f or - each sel ect =” not i c i a” / > <xsl : val ue- of sel ect =” . ” / > </ xsl : f or - each> </ xsl : t empl at e>


105

O atributo mat ch utilizado no elemento <xsl : t empl at e >, possui uma vasta capacidade de construção em termos de sintaxe de forma a indicarmos exactamente a informação que pretendemos extrair de um documento XML. Vou apresentar algumas delas. �

��

Para que o documento resultado continue a ser um documento bem formado, o primeiro elemento a ser transformado deve ser a raiz. Daí que o primeiro template que normalmente encontramos num documento XSL contenha o atributo mat ch=” / ” . Quando presente, esta regra será apenas aplicada sobre a raiz da árvore da estrutura do documento XML. ��

A identificação mais básica, que aliás observamos nos exemplos apresentados até aqui, é efectuada através do nome do elemento. Vejamos o documento XSL referente à informação noticiosa, construído à base da selecção de elementos pelo nome:

<?xml ver si on=” 1. 0” ?> <xsl : st y l esheet xml ns: xsl =” ht t p: / / www. w3. or g/ TR/ WD- xsl ” > <xsl : t empl at e mat ch=” / ” > <ht ml > <xsl : appl y- t empl at es sel ect =” not i ci as” / > </ ht ml > </ xsl : t empl at e> <xsl : t empl at e mat ch=” not i c i as” > <body> <xsl : appl y- t empl at es sel ect =” not i ci a” / > </ body> </ xsl : t empl at e> <xsl : t empl at e mat ch=” not i c i a” > <xsl : val ue- of sel ect =” t i t ul o” / > <xsl : val ue- of sel ect =” sumar i o” / > </ xsl : t empl at e> </ xsl : s t y l esheet >

Note-se a correspondência entre os atributos sel ect e o atributo mat ch. Desta forma garantimos que apenas serão verificados os templates correspondentes aos elementos pretendidos.


106

Chamo ainda a atenção para o facto de a ordem pela qual aparecem as instruções xsl : val ue- of ser irrelevante para a leitura do documento XML, o mesmo não acontecendo na apresentação do documento resultado. Para controlarmos este aspecto podemos recorrer à instrução xsl : sor t , que terei a oportunidade de abordar mais tarde. � �� Existem várias formas de identificar elementos para além do descrito até aqui. A utilização de alguma simbologia adicional, confere ao processo de matching um vasto potencial. Vejamos então a utilização possível dos símbolos /, // e @. Os símbolos / e // são essencialmente utilizados para navegação entre elementos, de forma idêntica aos sistemas DOS ou UNIX, quando efectuávamos navegação entre directórios através da linha de comando ( partindo do principio que o leitor está familiarizado com este conceito ). Quando é efectuado um match de um determinado template não temos que nos limitar aos filhos do elemento seleccionado. Podemos descer um ou mais níveis na hierarquia através da utilização do símbolo /. Quando utilizado isoladamente, indica a raiz do documento, mas poderemos então utiliza-lo da seguinte forma:

<xsl : t empl at e mat ch=” not i c i a/ t i t ul o” > <b><xsl : val ue- of sel ect =” . ” / ></ b> </ xsl : t empl at e>

Deste modo teríamos acesso a todos os elementos <t i t ul o> filhos de um elemento <not i ci a>. Podemos ainda ir mais longe. Vejamos o exemplo seguinte:

<xsl : t empl at e mat ch=” not i c i as/ * / t i t ul o” > <b><xsl : val ue- of sel ect =” . ” / ></ b> </ xsl : t empl at e>

Utilizando o símbolo asterisco ( * ), que significa qualquer conteúdo, podemos fazer navegações mais arbitrárias. A utilização do símbolo // permite-nos navegar através da árvore de um documento ignorando elementos intermédios. Vejamos o exemplo seguinte:

<xsl : t empl at e mat ch=” not i c i as/ / t i t ul o” > <b><xsl : val ue- of sel ect =” . ” / ></ b> </ xsl : t empl at e>

A regra anterior aplica-se a todos os descendentes de <not i ci as>, denominados <t i t ul o>. A utilização deste tipo de construção é tão mais importante quanto maior for a profundidade da árvore do documento. É bastante comum surgirem elementos com nomes iguais, pertencentes a diferentes sub-árvores. Analisemos a seguinte instrução:


107

<xsl : t empl at e mat ch=” / / t i t ul o” > <b><xsl : val ue- of sel ect =” . ” / ></ b> </ xsl : t empl at e>

Quando utilizado desta forma, o símbolo //, procura qualquer elemento de nome <t i t ul o> descendente da raiz. O símbolo @ é normalmente utilizado para seleccionar atributos, bastando para tal utilizarmos este símbolo como prefixo do nome do atributo.

<xsl : t empl at e mat ch=” not i c i a” > <xsl : val ue- of sel ect =” @dat a” / > </ xsl : t empl at e>

No exemplo anterior obteríamos o valor do atributo dat a pertencente ao elemento <not i ci a>, correspondente ao match efectuado. Finalmente o símbolo |, que têm um significado que já nos é familiar e que foi abordado no ponto dedicados à especificação de DTDs. A utilização deste símbolo significa o processamento de um match alternativo:

<xsl : t empl at e mat ch=” not i c i aA | not i c i aB” > <b><xsl : val ue- of sel ect =” . ” / ></ b> </ xsl : t empl at e>

No exemplo anterior, partindo do pressuposto que o documento XML possui uma estrutura com elementos do tipo <not i ci aA>, <not i ci aB>, etc., o template seria aplicado alternativamente sempre que fossem encontrados elementos de qualquer um dos tipos especificados. Podem-se combinar todos estes símbolos na representação do atributo mat ch. Podemos construir algo do género: <xsl : t empl at e mat ch=” / not i ci a/ * / @dat a” > ou <xsl : t empl at e

mat ch=” not i c i aA/ @* | not i c i aB/ @* ” >. No ultimo caso, seleccionaríamos todos os atributos do elemento <not i ci aA> ou <not i ci aB>. � � ��

Até agora temos vindo a pesquisar somente elementos através dos seus nomes. No entanto, é possível efectuar testes um pouco mais elaborados utilizando o símbolo [ ]. Da sua utilização decorrem as seguintes verificações possíveis:

� Se um elemento contém um determinado filho, atributo ou outro qualquer nó; � Se o valor de um atributo corresponde a um determinado texto; � Se o valor de um elemento corresponde a um determinado texto; � Que posição ocupa determinado nó na hierarquia.


108

Por exemplo, vejamos uma construção para procurar uma noticia que tem um determinado titulo.

<xsl : t empl at e mat ch=” not i c i a[ t i t ul o=’ Ti t ul o 1’ ] ” > Encont r ei a not i ci a. </ xsl : t empl at e>

Ou um elemento que contenha um filho denominado <aut or >:

<xsl : t empl at e mat ch=” * [ aut or ] ” > Encont r ei a not i c i a. </ xsl : t empl at e>

Ou ainda um elemento <not i ci a> cujo atributo dat a corresponda a um determinado valor:

<xsl : t empl at e mat ch=” not i c i a[ @dat a=’ 2001- 05- 14’ ] ” > Encont r ei a not i ci a. </ xsl : t empl at e>

A linguagem XSL disponibiliza dois elementos que podem ser utilizados para seleccionar informação de acordo com determinados critérios ou condições, denominados xsl : i f e xsl : choose. O primeiro, apenas aplicará o conjunto de instruções definido nos seus limites se se verificar a condição imposta na sua declaração. O segundo, permite seleccionar uma opção, de acordo com uma lista de possibilidades, executando as instruções definidas para a escolha efectuada. Vejamos como se processa a utilização de cada um deles. � ��

Este elemento possibilita a construção de documentos XSL bastante versáteis permitindo alterar a informação a ser apresentada de acordo com uma determinada condição. Se a condição definida se verificar então a informação subjacente será apresentada, caso contrário não será apresentada qualquer tipo de informação. Vejamos o exemplo seguinte:

<xsl : t empl at e mat ch=” not i c i a” > <xsl : i f t est =” [ @codi go=’ 1’ ] > Est a é a not i c i a 1. </ xsl : i f > </ xsl : t empl at e>

As expressões utilizadas no atributo t est obedecem à mesma construção que já abordei para os atributos mat ch e sel ect .


109

Apesar de estarmos na presença de um elemento condicional, podemos ser lavados a pensar que existem construções do tipo if-else. No entanto, tal não acontece. Os elementos <xsl : el se> ou <xsl : el se- i f >, não fazem parte da especificação XSL. Esta funcionalidade é proporcionada pelo elemento <xsl : choose>, que abordarei seguidamente. � ��

O elemento xsl : choose vai executar um determinado processamento de acordo com uma selecção efectuada a partir de uma lista de possibilidades. Cada uma dessas possibilidades tem associado um template de output definido à custa de um elemento xsl : when. Este elemento contém um atributo t est , que, à semelhança do elemento xsl : i f , verificará uma expressão condicional. Vejamos um exemplo:

<xsl : t empl at e mat ch=” not i c i a” > <xsl : choose> <xsl : when t est =” [ @codi go=’ 1’ ] > Est a é a not i c i a 1. </ xsl : when> <xsl : when t est =” [ @codi go=’ 2’ ] > Est a é a not i c i a 2. </ xsl : when> <xsl : when t est =” [ @codi go=’ 3’ ] > Est a é a not i c i a 3. </ xsl : when> <xsl : ot her wi se> Est a é a uma not i c i a qual quer que não t em códi go. </ xsl : when> </ xsl : choose> </ xsl : t empl at e>

Neste caso, seria tomada a acção que satisfizesse a condição definida no atributo t est . No caso de nenhuma das condições se verificar, existe uma alternativa, descrita pelo elemento <xsl : ot her wi se>.

A XSL disponibiliza uma forma de ordenar a informação que vai constar do documento resultante do processo de transformação. Para tal utiliza o elemento xsl : sor t . Este elemento surge sempre como descendente de um xsl : appl y- t empl at es ou um xsl : f or -

each. O atributo sel ect que consta deste elemento indica qual a chave de ordenação. Por defeito, os elementos serão ordenados por ordem alfabética. Se existir mais do que um elemento xsl : sor t , então o processo de ordenação é efectuado pela ordem que surgem os elementos de ordenação de acordo com as chaves identificadas.


110

O exemplo seguinte ordenaria as noticias pelo seu atributo dat a:

<?xml ver si on=” 1. 0” ?> <xsl : st y l esheet xml ns: xsl =” ht t p: / / www. w3. or g/ TR/ WD- xsl ” > <xsl : t empl at e mat ch=” / ” > <ht ml > <xsl : appl y- t empl at es/ > </ ht ml > </ xsl : t empl at e> <xsl : t empl at e mat ch=” not i ci as” > <body> <xsl : appl y- t empl at es> <xsl : sor t sel ect =” @dat a” / > </ xsl : appl y- t empl at es> </ body> </ xsl : t empl at e> <xsl : t empl at e mat ch=” not i ci a” > Uma not i ci a. </ xsl : t empl at e> </ xsl : s t y l esheet >

Podemos ainda acrescentar alguma sofisticação ao elemento xsl : sor t , através de outros atributos disponíveis, como por exemplo case- or der , dat a- t ype e or der . O atributo case- or der é utilizado para definir se a ordenação coloca em primeiro lugar as palavras em maiúsculas ou minúsculas. O atributo dat a- t ype é utilizado, para não ordenar a informação como textual mas sim como numérica, nos casos em que tal acontece. Bastará para o efeito colocar dat a- t ype=” number ” . O atributo or der define o tipo de ordenação, através dos valores “ascending” ou “descending” .

A definição de constantes pode-se revelar bastante útil na organização do conteúdo de um documento XSL. As constantes, uma vez definidas, permitem a reutilização do seu conteúdo em vários locais, tornando mais fácil a manutenção do documento. Para definir uma constante procede-se da seguinte forma:

<xsl : var i abl e name=” t est e” > I st o é um t est e.

</ xsl : var i abl e>


111

Como facilmente de depreende, a definição de uma constante é sempre delimitada pelo elemento xsl : var i abl e, e o atributo name identifica o nome pelo qual ela será conhecida no documento. Para podermos utilizar o seu conteúdo ao longo do documento utilizaremos o símbolo $ seguido do nome da constante, de acordo com a construção seguinte:

<xsl : val ue- of sel ect =” $t est e” >

O conteúdo de uma constante poderá incluir outras instruções XSL. Isto significa que poderemos obter o conteúdo de uma constante à custa de informação externa ou até proveniente de outras constantes. No entanto, esta informação não poderá entrar num processo cíclico.

Outra forma, mais poderosa do que a utilização de constantes para identificar informação repetitiva presente num documento XSL, é através da definição de templates recorrendo à inclusão de um atributo name. Esta facilidade permite que possamos invocar um determinado template sempre que necessitarmos de aplicar o conjunto de instruções que nele definimos, através da invocação do seu nome. Vejamos o seguinte exemplo de definição de um template:

<xsl : t empl at e name=” sumar i o_not i c i a” > <t d> <f ont f ace=” Ti mes, Ser i f ” col or =” bl ue” s i ze=” 2” > <xsl : val ue- of sel ect =” . ” / > </ f ont > </ t d> </ xsl : t empl at e>

A utilização deste template permitiria aplicar determinadas definições de fonte ao elemento do documento XML que estivesse a ser tratado. Para que conseguíssemos concretizar esse efeito, construiríamos algo do género:

<xsl : t empl at e mat ch=” not i c i a/ sumar i o” > <xsl : cal l - t empl at e name=” sumar i o_not i ci a” / >

</ xsl : t empl at e>

Como é evidente, este exemplo tem como objectivo, apenas apresentar ao leitor o âmbito da possibilidade de utilização desta técnica. É óbvio que a sua utilização se pode estender a um vasto numero de aplicações, conferindo ao documento XSL um automatismo elevado bem como uma excelente capacidade de actualização e manutenção. Acrescendo a esta possibilidade, a invocação de um template através do seu nome, permite a passagem de parâmetros, de forma a tornar o seu conteúdo ainda mais dinâmico. No elemento xsl : t empl at e os parâmetros são representados como elementos


112

filho do tipo xsl : par am- var i abl e. Quando invocamos o template, utilizando o elemento xsl : cal l - t empl at e, passamos os parâmetros através de elementos filhos definidos com xsl : par am. Vejamos como tudo funciona na prática. Imaginemos que queríamos incluir um link dinâmico numa determinada parte do nosso documento, por exemplo associado a um determinado elemento. Definiríamos o template do seguinte modo:

<xsl : t empl at e name=” t empl at e_di nami co” > <xsl : par am- var i abl e name=” l i nk” > f i chei r o. ht ml </ xsl : par am- var i abl e>

<t d> <f ont f ace=” Ti mes, Ser i f ” col or =” bl ue” s i ze=” 2” > <a hr ef =” { $l i nk} ” ><xsl : val ue- of sel ect =” . ” / ></ a> </ f ont > </ t d> </ xsl : t empl at e>

O atributo name do elemento xsl : par am- var i abl e identifica o parâmetro, enquanto que o conteúdo do elemento especifica o valor do parâmetro por defeito. A invocação do template poderia ser feita da seguinte forma:

<xsl : t empl at e mat ch=” el ement o” > <xsl : cal l - t empl at e macr o=” t empl at e_di nami co” > <xsl : par am- name=” l i nk” >O_meu_l i nk. ht ml </ xsl : par am> <xsl : val ue- of sel ect =” . ” / > </ xsl : cal l - t empl at e>

</ xsl : t empl at e>

Na invocação, identificamos a chamada ao template criado anteriormente, através do atributo macro do elemento xsl : cal l - t empl at e. Na definição deste elemento indicamos o valor do parâmetro a passar, através do elemento xsl : par am- name.

Um único documento XML pode utilizar vários tipos de vocabulários de marcação descritos por diferentes DTDs. Podemos também utilizar várias folhas de estilo para cada um destes vocabulários. A XSL disponibiliza os elementos xsl : i mpor t e xsl : i nc l ude, para que seja possível juntar várias folhas de estilo, de forma a obter um documento sofisticado e ao mesmo tempo funcional. � ��

Este é um elemento de topo cujo atributo hr ef contém o URI da folha de estilo a ser importada. Define-se como elemento de topo por ter de ser declarado antes de qualquer outro no documento XSL. O exemplo seguinte apresenta um documento XSL que utiliza duas folhas de estilo adicionais:


113

<xsl : st y l esheet xml ns: xsl =” ht t p: / / www. w3. or g/ XSL/ Tr anf or m/ 1. 0” >

<xsl : i mpor t hr ef =” f ol ha_de_est i l o_1. xsl ” / > <xsl : i mpor t hr ef =” f ol ha_de_est i l o_2. xsl ” / > <! - - cont eudo - - >

</ xsl : s t y l esheet >

Pode acontecer que algumas das regras presentes nos documentos que estão a ser importados entrem em conflito com as que já existem no documento principal. Neste caso, têm precedência as regras dos documentos externos. No caso de existir conflito entre estes, prevalecem as regras do ultimo documento importado. A instrução xsl : appl y- i mpor t s, comporta-se do mesmo modo que a instrução xsl : appl y-

t empl at es. A diferença é que a primeira apenas se aplica às regras importadas. � ��

Este elemento, também de topo, copia uma folha de estilo ( conteúdo delimitado pelo elemento xsl : st y l esheet ) para o ponto do documento XSL original onde é invocado. O seu atributo hr ef contém o URI do documento a importar. Um elemento xsl : i nc l ude poderá surgir em qualquer parte de um documento XSL, sempre após um elemento xsl : i mpor t ( no caso de existir ). Ao contrário do que acontecia com o elemento xsl : i mpor t , as regras incluídas num documento XSL através do elemento xsl : i nc l ude não se distinguem das do documento original. De facto, o processo funciona de modo análogo a uma copia de conteúdos efectuada por um utilizador entre dois ficheiros.

Tecnologias Suplementares

A linguagem XML Tecnologias Suplementares

115

Os XLinks são parte integrante da XLL ( Extensible Linking Language ), utilizada para definir a forma como dois documentos podem comunicar, ou melhor dizendo, como se podem ligar. Basicamente, os XLinks apontam para URIs ( na prática URLs ), que especificam um recurso em particular. A utilização desta tecnologia faz frente aos links utilizados em HTML por vários motivos. Os URLs estão limitados a apontar para outros documentos. Não lhes é possível, por exemplo, apontar para a terceira palavra do quinto parágrafo de um documento, sendo necessário para tal, recorrer à utilização de âncoras. Adicionalmente, não conseguem manter um histórico das relações entre os documentos. A partir do interior do documento HTML, não é possível saber qual a proveniência do utilizador. A XLL é a solução para uma gestão eficiente e poderosa das ligações entre documentos, sendo especialmente concebida para utilização com a XML, embora alguns aspectos sejam também suportados pela HTML. Além de disponibilizar a mesma tecnologia da ultima, acrescentou-lhe a possibilidade de definir ligações multi-direccionais, definir outros elementos, além do <A>, para estabelecer ligações e não necessita que estas definições estejam no mesmo documento onde serão utilizadas.

Enquanto que em HTML só é possível definir ligações através da tag <A>, em XML qualquer elemento pode conter uma ligação. Um elemento deste tipo é identificado por um atributo xl i nk: f or m com os valores si mpl e ou ext ended. Adicionalmente contêm um atributo hr ef que identifica o URI da ligação.

<r odape x l i nk: f or m=” si mpl e” hr ef =” r odape. xml ” / > <i magem xl i nk: f or m=” si mpl e” hr ef =” l ogot i po. gi f ” / >

Os dois exemplos anteriores são em tudo idênticos às ligações efectuadas em HTML, exceptuando o elemento onde estão definidos. De acordo com um DTD especificado para um documento, podemos omitir alguns atributos do elemento de ligação.

<r odape hr ef =” r odape. xml ” / > <i magem hr ef =” l ogot i po. gi f ” / >

Neste caso o DTD possuiria a declaração do atributo xl i nk: f or m na forma #FI XED

“ Si mpl e” .


116

O facto de um elemento implementar uma ligação, não o impede de ter uma construção normal, incluindo outros atributos e descendentes. ��

Um elemento do tipo ligação pode conter dois atributos adicionais: cont ent - r ol e e cont ent - t i t l e.

<aut or hr ef =” ht t p: / / pagi na_do_aut or . ht ml ” cont ent - t i t l e=” aut or da pági na” cont ent - r ol e=” cont act o” >

Nome do Aut or </ aut or >

Estes dois atributos são utilizados para descrever o conteúdo da ligação local. São normalmente utilizados pela XML para apresentarem informação adicional acerca da ligação que está ou vai ser efectuada, por exemplo no rodapé do browser, ou para fornecer informação à aplicação que utiliza o documento. Nenhum destes atributos é de carácter obrigatório. Um elemento do tipo ligação pode ainda conter os atributos r ol e e t i t l e, que descrevem a ligação remota, ou seja, o documento ou recurso ao qual se ligam.

<aut or hr ef =” ht t p: / / pagi na_do_aut or . ht ml ” t i t l e=” pagi na pessoal do aut or ” r ol e=” i nf or mação adi c i onal ” cont ent - t i t l e=” aut or da pági na” cont ent - r ol e=” cont act o” >

Nome do Aut or </ aut or >

Do mesmo modo que os dois atributos anteriores, também estes podem ser utilizados para obter ou apresentar informação adicional, não sendo no entanto obrigatórios. Como qualquer atributo, também estes deverão ser adequadamente descritos no DTD utilizado pelo documento. � ��

Existem três outros atributos que podemos adicionar ao elemento de ligação, show, act uat e e behavi or . O primeiro descreve como a informação deve ser apresentada quando a ligação é activada. O segundo indica se a ligação deve ser feita automaticamente ou a pedido do utilizador. Finalmente, o terceiro informa uma aplicação acerca de como a ligação deve ser estabelecida. O atributo show, pode assumir os valores r epl ace, new ou embed. O valor r epl ace tem um comportamento igual ao HTML, ou seja, quando seleccionamos o link, o destino


117

identificado substitui a página corrente. O valor new faz com que a ligação seja aberta numa nova janela. O valor embed insere o recurso apontado pela ligação no documento existente. O efeito ficará à responsabilidade da aplicação, mas podemos imaginar o seu processamento da mesma forma que um include. Um exemplo de utilização:

<aut or hr ef =” ht t p: / / pagi na_do_aut or . ht ml ” show=” new” > Nome do Aut or

</ aut or >

O atributo act uat e pode assumir os valores user ou aut o. O valor por defeito, user , indica que a ligação deve ser efectuada apenas quando o utilizador quiser. O valor aut o indica que a ligação é estabelecida sempre que for activada uma outra ligação do mesmo elemento. O atributo behavi or é utilizado para passar informação arbitrária, num formato também arbitrário a uma aplicação. A aplicação aguarda esta informação para definir exactamente o comportamento da ligação. Vejamos um exemplo:

<composi t or xl i nk: f or m=” si mpl e” r ef =” ht t p: / / pagi na_do_composi t or . ht ml ” behavi or =” sound: musi ca. mp3”

Pagi na do composi t or </ composi t or >

Como é óbvio, a aplicação que recebe esta informação “sabe” a utilização que lhe deve conferir. Esta é uma grande vantagem na transmissão e posterior interpretação de informação de diferentes formatos.

As ligações simples, como vimos no ponto anterior, têm um comportamento mais ou menos standard relativamente ao que já conhecíamos ( se for o caso do leitor ) da HTML. As ligações estendidas são um pouco mais ambiciosas, acrescentando o conceito de links multi-direcionais e out-of-line.

<pagi naWeb xl i nk: f or m=” ext ended” / >

A primeira grande vantagem é a possibilidade de identificar mais do que uma ligação no mesmo elemento. Para alem do atributo hr ef existe o elemento l ocat or . Vejamos o exemplo seguinte:

<pagi nasWeb xl i nk: f or m=” ext ended” / > Pagi nas de l i gação.

<l ocat or hr ef =” ht t p: / / pagi na1. hmt l ” >Pagi na 1</ l ocat or > <l ocat or hr ef =” ht t p: / / pagi na2. hmt l ” >Pagi na 2</ l ocat or > <l ocat or hr ef =” ht t p: / / pagi na3. hmt l ” >Pagi na 3</ l ocat or > </ pagi nasWeb>


118

Como podemos observar, tanto o elemento principal como os filhos podem ter atributos. No entanto, o elemento <pagi nasWeb> só contém atributos aplicáveis à ligação como um todo, enquanto os atributos <l ocat or > possuem atributos particulares à ligação que descrevem. Atributos do tipo act uat e, behavi or e show, no caso de existirem, pertencerão a estes elementos. Se as várias ligações apontarem o mesmo sítio ou recurso e tiverem ainda em comum atributos e respectivos valores, então estes poderão ser definidos no elemento principal. Não deverão no entanto ser também definidos nos elementos filho. � ��

As ligações consideradas até aqui, tanto simples como estendidas são denominadas de inline links, cujo significado está relacionado com o facto de a ligação utilizar o conteúdo do elemento de ligação como parte do documento que a contém. As ligações podem também ser out-of-line. Esta designação indica que a ligação poderá não existir em nenhum dos documentos que a definem. Ao invés, existirá um documento onde as ligações estarão definidas. Imaginemos uma projecção de slides baseada em ligações. Poderíamos facilmente alterar a ordem de projecção modificando simplesmente o documento que contém essas ligações. Este tipo de ligação é identificada através do atributo i nl i ne, com o valor f al se.

<pagi naWeb x l i nk: f or m=” si mpl e”

i nl i ne=” f al se” hr ef =” ht t p: / / pagi na. ht ml ”

t i t l e=” Ti t ul o da pági na. ” r ol e=” i nf or mação”

</ pagi naWeb>

O exemplo anterior é bastante simples e não muito utilizado. Normalmente, a utilização do conceito out-of-line, é bastante mais útil em ligações estendidas. ��

Os grupos de ligações estendidas, como o próprio nome indica, contêm uma lista de ligações para um conjunto de documentos em particular. Cada documento do grupo é referenciado através de um elemento de ligação. Será da responsabilidade da aplicação, “entender” as ligações entre os diversos elementos do grupo. Este conceito é muito útil em várias áreas, nomeadamente em formação ou páginas de ajuda on-line.


119

A XML define um esquema de endereçamento orientado a partes individuais de um documento. Este esquema é conseguido recorrendo à utilização de XPointers. Os URIs utilizados pelos XLinks podem incluir uma parte baseada em XPointers, de modo a conseguirem referenciar partes mais especificas dos recursos a que pretendem aceder. À semelhança do que referi em relação aos XLinks, também aqui a HTML apresenta as suas limitações. De facto, os XPointers permitem um novo conjunto de funcionalidades que fazem falta ao desenvolvimento de documentos com um grau mais elevado de flexibilidade. É bastante útil podermos estabelecer ligações a partes de um determinado elemento ou grupo de elementos, sem ser necessário modificar qualquer um dos alvos dessas ligações. Por exemplo, é de grande utilidade podermos aceder a partir de uma página apresentação noticiosa, a um parágrafo definido no texto de uma determinada noticia presente num documento XML. É precisamente neste ponto que os XPointers revelam toda a sua utilidade.

Os XPointers definem-se pela utilização de termos de localização. No caso da localização absoluta, cada termo especifica uma localização particular dentro de um documento, geralmente relativo a uma posição bem definida, como por exemplo o topo do documento ou outro termo de localização. O tipo de termo de localização absoluta é definido pelas palavras chave i d( ) , r oot ( ) ou chi l d( ) . A melhor forma de apresentar a utilização destes termos será através de um exemplo. Observemos o seguinte documento:

<?xml ver si on=” 1. 0” ?> <f ami l i a> <pessoa i d=” p1” > <nome>Nome 1</ nome> <i dade>40</ i dade> <f ami l i ar i dr ef =” p2” > </ pessoa> <pessoa i d=” p2” > <nome>Nome 2</ nome> <i dade>35</ i dade> <f ami l i ar i dr ef =” p1” > </ pessoa> <pessoa i d=” p3” pai =” p1” mae=” p2” > <nome>Nome 3</ nome> <i dade>5</ i dade> </ pessoa> </ f ami l i a> </ xsl : s t y l esheet >


120

Para a abordagem que vou efectuar, imaginemos que este documento se localiza no endereço http://familia.xml. O termo de localização i d( ) , é o mais simples e o mais utilizado. Selecciona os elementos do documento a partir dos atributos do tipo ID, definidos num DTD. Relembrando o conceito de atributo do tipo ID, saliento a importância de o seu valor ser único num documento. Assim, poderíamos aceder a um elemento do exemplo através do XPointer:

ht t p: / / f ami l i a. xml #i d( p3) De notar que esta instrução irá seleccionar o elemento e toda a sua estrutura, incluído elementos filho. A desvantagem deste termo de localização é a necessidade dos elementos possuírem um atributo do tipo ID, ou seja, está limitado à própria estrutura do documento. O termo de localização r oot ( ) aponta para o elemento raiz do documento. Não existem argumentos definidos. Um exemplo de utilização seria ht t p: / / f ami l i a. xml #r oot ( ) . O termo de localização ht ml ( ) selecciona ancoras definidas em documentos HTML. Imaginemos que um determinado documento HTML tem a seguinte instrução:

<a name=” ancor a” >Ancor a do document o HTML. </ a>

A utilização do termo ht ml ( ) seria:

ht t p: / / document o. ht ml #ht ml ( ancor a) . Este termo continua a ser utilizado por questões de compatibilidade com documentos mais antigos.

Enquanto que os termos de localização absoluta identificam a informação directamente, os termos de localização relativa, servem-se de outros termos ou localizações para atingirem o seu fim. O processo normal será partir de uma localização absoluta para uma localização ou localizações relativas. No caso de serem várias, as localizações definem-se à custa da anterior, atendendo a uma estrutura separada por pontos, como no exemplo seguinte:

ht t p: / / f ami l i a. xml #r oot ( ) . chi l d( 1, pessoa) . chi l d( 1, nome)


121

Partindo da raiz, chegaríamos ao primeiro elemento <nome> do primeiro elemento <pessoa>. Os termos de localização relativa existentes e a sua função apresentam-se na tabela seguinte: Termo Função child Selecciona um filho do elemento corrente. descendant Selecciona todos os descendentes de um determinado tipo a partir da

localização corrente. ancestor Selecciona todos os ascendentes a partir do elemento corrente, começando

pelos mais próximos. preceding Selecciona os elementos que antecedem o corrente. following Selecciona os elementos que precedem o corrente. psibling Selecciona os elementos que antecedem o corrente, dentro do mesmo

elemento pai. fsibling Selecciona os elementos que precedem o corrente, dentro do mesmo

elemento pai. Cada termo de localização relativa inicia a sua pesquisa numa determinada posição, que designarei origem. Normalmente a origem é um termo de localização absoluta. No caso de não ser especificada será o elemento raiz. A pesquisa será orientada de acordo com um determinado critério, a ser fornecido através de uma lista de argumentos fornecida ao termo de localização relativa. Estes argumentos podem ser números, podem referir o tipo ( elemento, comentário, instrução de processamento, etc. ) e/ou o valor de um determinado atributo. A sintaxe de representação dos argumentos num termo de localização relativa, obedece à seguinte sintaxe:

t er mo( numer o, t i po, at r i but o, val or _at r i but o)

Não devem existir espaços na invocação de termos de pesquisa relativa. ��

A forma de selecção mais simples é através de um numero. A deslocação na estrutura do documento será feita de acordo com o sinal utilizado, positivo ou negativo. É também possível utilizar a palavra chave al l .

ht t p: / / f ami l i a. xml #r oot ( ) . chi l d( 1) ht t p: / / f ami l i a. xml #r oot ( ) . chi l d( 2) ht t p: / / f ami l i a. xml #r oot ( ) . chi l d( 3)


122

Esta instrução devolve os primeiros três filhos do elemento raiz, ou seja, os três elementos <pessoa>. Se pretendermos obter o primeiro elemento <pessoa> completo, procedemos da seguinte forma:

ht t p: / / f ami l i a. xml #r oot ( ) . descendant ( 1)

ou,

ht t p: / / f ami l i a. xml #i d( p1) . chi l d( al l )

Note-se que se voltássemos a repetir a primeira instrução, com o parâmetro 2, obteríamos o elemento <nome>, uma vez que estamos a tratar posicionamento relativo. Se utilizarmos números negativos, efectuamos a pesquisa em sentido inverso. No caso da utilização chi l d ou descendant , estes deslocar-se-ão para trás, a partir da tag final do elemento corrente. Se efectuarmos a instrução:

ht t p: / / f ami l i a. xml #r oot ( ) . chi l d( - 1, pessoa)

Estamos a referir o ultimo elemento pessoa do documento. ��

A selecção de elementos por numero tem a desvantagem de ser demasiadamente dependente da estrutura do documento, ou seja, se adicionarmos ou removermos informação do documento XML, corremos o risco de as ligações definidas recorrendo ao posicionamento numérico deixarem de funcionar. A selecção baseada no tipo de nó da estrutura é independente das alterações que possam tomar lugar. Podemos ainda assim, combinar este tipo de selecção com a selecção baseada em números, recorrendo às palavras chave #el ement , #pi , #comment , #t ext , #cdat a, #al l ou Name. Estas palavras surgem como segundo argumento na invocação dos termos de localização relativa, logo após o numero. Um exemplo para seleccionar todas as pessoas do documento seria:

ht t p: / / f ami l i a. xml #r oot ( ) . chi l d( , pessoa)

Saliento a importância da presença da virgula, quando não existe a especificação do argumento anterior. A informação seleccionada por cada uma das palavras chave indicadas anteriormente está praticamente implícita na sua designação. Vejamos a tabela seguinte:


123

Tipo Selecciona: #element Qualquer elemento #pi Qualquer instrução de processamento #comment Qualquer comentário #text Qualquer caracter não marcado #cdata Blocos do tipo CDATA #all Todas as anteriores Name Elementos do nome especificado

��

Podemos adicionar um terceiro e quarto argumentos na invocação de um termo de localização relativa, de forma a efectuarmos selecções com base em atributos. Como já referi na construção da sintaxe de invocação, o terceiro argumento é o nome do atributo e o quarto será o seu valor. Desta forma poderemos ter construções do tipo:

ht t p: / / f ami l i a. xml #r oot ( ) . chi l d( al l , pessoa, pai , p1)

Neste caso seria seleccionado o terceiro elemento <pessoa>, uma vez que possui o atributo pai com o valor 1.

ht t p: / / f ami l i a. xml #r oot ( ) . chi l d( al l , #el ement , i d, * )

O exemplo anterior selecciona todos os elementos que possuam um atributo i d, independentemente do seu valor. Embora a utilização do argumento #el ement seja válida neste caso, a utilização de atributos não pode ser combinada com #t ext , #dat a, #pi ou #comment .

Os tipos de localização abordados até aqui são bastante úteis em relação a informação estruturada de acordo com a XML. No entanto, como sabemos, um documento XML também possui informação que poderá não estar representada como tal, ou seja, representada em blocos CDATA, comentários, instruções de processamento ou outro qualquer tipo. É neste contexto que surge a necessidade de efectuar localizações com base em texto. Como a designação indica, este tipo de localização é efectuada de acordo com um determinado conteúdo textual, e pode ser construída da seguinte forma:

ht t p: / / f ami l i a. xml #st r i ng( 1, ” Nome 2” )


124

Este exemplo referencía a posição seguinte à letra “N” , que não é o mesmo que o nome inteiro. Podemos ainda adicionar um terceiro argumento que indica a posição a referenciar para a direita do primeiro caracter indicado no segundo argumento:

ht t p: / / f ami l i a. xml #st r i ng( 1, ” Nome 2” , 3)

Um quarto argumento, opcional, indica o numero de caracteres a referenciar:

ht t p: / / f ami l i a. xml #st r i ng( 1, ” Nome 2” , 3, 10)

Neste exemplo, seriam referenciados os 10 caracteres à direita do caracter “m”.


125

A XML não é uma ilha isolada. Se por um lado é útil construir documentos que obedeçam a um standard de marcação, por outro, também é necessária alguma flexibilidade na inclusão de vocabulários provenientes de outras linguagens. O problema que decorre desta abordagem, advém do facto de por vezes ser impossível evitar que a notação utilizada em dois vocabulários distintos, possua tags coincidentes. A função dos namespaces é precisamente eliminar esta ambiguidade.

A XML oferece aos autores dos documentos a possibilidade de criarem as suas próprias linguagens de definição. Posteriormente, poderão efectuar a sua distribuição a projectos similares, espalhados pelo globo. Um exemplo deste tipo de especificações é a XSL. Como podemos observar, quando abordei esta linguagem, ela é tipicamente XML, com a utilização de um conjunto de tags próprio. A necessidade de criar uma distinção entre diferentes especificações de XML levou à criação dos denominados namespaces. Podemos dizer que um namespace, é uma área de definição de uma e só uma linguagem. Por exemplo, a definição da XSL na sua vertente de transformação pertence à área http://www.w3.org/xsl/Transform/1.0. Observemos o seguinte exemplo:

<?xml ver si on=” 1. 0” ?> <xsl : st y l esheet xml ns: xsl =” ht t p: / / www. w3. or g/ xsl / t r ansf or m/ 1. 0” xml ns: f o=” ht t p: / / www. w3. or g/ xsl / f or mat / 1. 0” > <xsl : t empl at e mat ch=” / ” > <f o: f l ow> <xsl : appl y- t empl at es/ > </ f o: f l ow> </ xsl : t empl at e> </ xsl : s t y l esheet >

Os diferentes namespaces são identificados no inicio do documento, no elemento xsl : st y l esheet , recorrendo à construção xml ns: namespace=” l ocal i zação” .


126

No exemplo são definidos os dois templates da XSL, ligados à vertente da transformação e formatação. Os seus elementos podem depois ser invocados na construção do documento através da identificação do namespace a que pertencem, <xsl : > ou <f o: >. O que acontece na prática é que a definição do namespace, além de nos permitir utilizar as tags associadas, também nos permite tornar o aspecto do documento um pouco mais atraente, vejamos que as seguintes instruções são perfeitamente iguais:

xsl : st y l esheet ht t p: / / www. w3. or g/ xsl / t r ansf or m/ 1. 0: st yl esheet

O namespace associado à instrução é substituído por um prefixo seguido de dois pontos ( xsl: ).

Antes de mais, convém realçar que os processadores XML que não “conheçam” a definição de namespaces, quando este são utilizados num documento, não dão origem a erros. O documento será interpretado normalmente. Para definir um namespace utiliza-se um prefixo xml ns: , seguido do nome e do URI da sua localização.

<xsl : st y l esheet xml ns: xsl =” ht t p: / / www. w3. or g/ xsl / t r ansf or m/ 1. 0” >

O URI utilizado é apenas uma formalidade. A sua função é quebrar as ambiguidades que possam existir num documento. Não é necessário apontar para nenhum endereço em particular, ou mesmo até que exista algum documento do endereço apontado. O prefixo utilizado pode ser qualquer nome XML válido, que não contenham o símbolo “dois pontos” ( : ). Convém ter em atenção as formas de construção aceites em nomes XML. Como é evidente, um documento que utilize namespaces tem que continuar a ser bem formado. Um documento pode conter mais do que um namespace, sendo a sua declaração habitualmente efectuada no elemento <xsl : st y l esheet >. No entanto esta localização não é obrigatória. Ela pode também ser efectuada dentro de um determinado elemento, sendo apenas conhecida do seu nível para baixo. Vejamos um exemplo:

<?xml ver si on=” 1. 0” ?> <xsl : st y l esheet xml ns: xsl =” ht t p: / / www. w3. or g/ xsl / t r ansf or m/ 1. 0” > <xsl : t empl at e mat ch=” / ” xml ns: f o=” ht t p: / / www. w3. or g/ xsl / f or mat / 1. 0” > <f o: f l ow> <xsl : appl y- t empl at es/ >


127

</ f o: f l ow> </ xsl : t empl at e> </ xsl : s t y l esheet >

Podemos ainda redefinir um determinado namespace num elemento filho:

<?xml ver si on=” 1. 0” ?> <xsl : st y l esheet xml ns: xsl =” ht t p: / / www. w3. or g/ xsl / t r ansf or m/ 1. 0” > <xsl : t empl at e mat ch=” / ” xml ns: xsl =” ht t p: / / www. w3. or g/ xsl / f or mat / 1. 0” > <xsl : f l ow> <xsl : appl y- t empl at es/ > </ xsl : f l ow> </ xsl : t empl at e> </ xsl : s t y l esheet >

No entanto esta abordagem não é muito recomendada, por questões de organização e percepção da lógica de estruturação de um documento.

Em documentos longos, com um conjunto elevado de marcações pode-se tornar inconveniente acrescentar o prefixo identificador do namespace em cada elemento. Uma solução possível é utilizar um atributo xml ns sem prefixo.

<?xml ver si on=” 1. 0” ?> <xsl : st y l esheet xml ns=” ht t p: / / www. w3. or g/ xsl / t r ansf or m/ 1. 0” xml ns: f o=” ht t p: / / www. w3. or g/ xsl / f or mat / 1. 0” > <t empl at e mat ch=” / ” > <f o: f l ow> <appl y- t empl at es/ > </ f o: f l ow> </ t empl at e> </ xsl : s t y l esheet >


128

Como já referi a utilização de namespaces não isenta um documento da necessidade de ser bem formado. Para que um documento que utilize namespaces seja válido, é necessário que os atributos xml ns estejam definidos no DTD associado, para os elementos que dele fazem uso. Por exemplo, se um documento utiliza um elemento do tipo <mat h: cal cul o > é necessário que exista uma declaração:

<! ELEMENT mat h: cal cul o EMPTY> Também se revela útil a utilização da palavra chave #I MPLI ED, como no exemplo seguinte:

<! ATTLI ST mat h: cal cul o xml ns: mat h “ ht t p: / / www. w3. or g/ t r / r ec- mat hml ” " #I MPLI ED>

Esta declaração coloca todos os elementos mat h: cal cul o no namespace especificado entre aspas.

Concluída a leitura deste documento, espero ter contribuído para que o leitor seja, a partir deste momento, um conhecedor e utilizador de respeito da linguagem XML. O potencial descrito, aliado à simplicidade de utilização, é sem dúvida o elemento apelativo deterministico em relação à sua utilização. A crescente evolução das tecnologias de suporte da linguagem fazem antever um futuro em que a XML se irá impor facilmente na área da manipulação e representação de informação. Com a esperança de ter cativado mais um utilizador, espero que todos nós demos o nosso contributo para conferir à XML o lugar que foi destinado, o de standard de comunicação de dados. O autor,

“XML Bible”, Elliote Rusty Harold, IDG Books. “XML Design and Implementation” , Paul Spencer, Wrox.

departamento de engenharia informática - instituto superior de …paf/proj/junho2001/xml.pdf ·...

Documents