| Anotação Estrutural de Documentos e sua Semântica | ||
|---|---|---|
| Prev | Capítulo 8. Validação Semântica com Modelos Abstractos | Next |
Tendo decidido sobre a linguagem que irá ser utilizada na escrita de restrições é altura de pensar na associação destas aos elementos que compõem o respectivo DTD.
A tarefa de escrever as restrições é atribuída ao analista que as deverá definir quando estiver também a definir o DTD.
A primeira decisão a tomar surge neste ponto: Como incluir as restrições no DTD sem alterar a sintaxe do SGML? Um dos objectivos é a não alteração do método de trabalho existente.
Analisando os construtores do SGML, pensou-se em três métodos alternativos:
Um comentário pode aparecer em qualquer lugar do DTD. Assim, pode-se definir as restrições em comentários espalhados pelo DTD. Estes comentários levam uma marca para os distinguir dos comentários normais: a palavra reservada Constraints é utilizada.
Exemplo 8-3. Restrições como comentários
<!DOCTYPE rei [
<!ELEMENT rei - - (nome,cognome,datan,datam,decreto+)>
<!-- Constraints
rei(k) = ...
-->
...
]>A ideia é utilizar de novo um comentário especial que indicará qual o ficheiro que tem as restrições que deverão ser associadas com o DTD corrente.
Exemplo 8-4. Restrições num ficheiro externo
<!DOCTYPE rei [ <!-- Constraints: rei.cam --> ... ]>
Uma vez que os comentários são completamente ignorados pelas aplicações SGML, pode parecer estranho a sua utilização para adicionar informação semântica aos documentos. Para quem possa pensar assim, avançou-se com uma terceira alternativa bem dentro do SGML: a utilização de uma ou várias entidades externas.
Uma entidade é vista pelas aplicações como um componente do documento. No caso da validação, o parser irá tentar analisar o seu conteúdo. Neste caso, não interessa que isso aconteça uma vez que o conteúdo não é SGML. Para evitar essa situação, utiliza-se a mesma técnica que se usa para imagens: declara-se que a entidade tem um conteúdo que deve ser tratado por uma aplicação externa que saberá processar a informação que estiver lá dentro.
Exemplo 8-5. Restrições numa entidade externa
<!DOCTYPE rei [ <!NOTATION CAM SYSTEM "camila.exe"> <!ELEMENT rei - - (nome,cognome,datan,datam,decreto+)> <!ENTITY king-rest SYSTEM "king.cam" NDATA CAM> ... ]>
Na segunda linha, declara-se que CAM é uma notação que é interpretada pela aplicação "camila.exe". Depois, pode-se indicar ao sistema que as entidades externas que contêm restrições têm o conteúdo nesta notação (linha 4).
Qualquer uma das três alternativas é válida e não implica qualquer alteração nos sistemas existentes em funcionamento.
Para o desenvolvimento dos casos de estudo escolheu-se a segunda alternativa. A primeira mistura as restrições com as declarações do DTD e no caso de DTDs complexos faria com que estes ficassem ainda mais complicados de ler e de entender. A segunda e a terceira alternativas são funcionalmente equivalentes; a segunda é mais fácil de utilizar em prototipagem (os comentários são livres, as aplicações SGML não lhes atribuem qualquer semântica).
A separação das restrições do DTD vem ainda permitir a construção de uma pequena e útil ferramenta: um processador simples que analisa o DTD e produz o esqueleto do código das restrições. Desta maneira, o analista poderá trabalhar mais rápido e com mais segurança (no esqueleto já estão todos os protótipos das restrições, nenhum foi esquecido).