Requêtes OLAP sur une base de données XML native - Cercle ...

3.5 Les DTD et les Schémas XML 20
⊲ #CDATA désigne les données textuelles qui ne doivent pas être traitées par l’analyseur ;
⊲ EMPTY signifie que l’élément ne peut rien contenir ;
⊲ ANY signifie que l’élément peut contenir ce que l’on veut.
Pour illustrer, analysons l’exemple suivant :
]>
L’art de l’intrusion
< auteurs >
< personne > Mitnick < prenom >Kevin
< personne >Simon < prenom > William
Il s’agit d’un document XML valide précédé de sa DTD. Cette DTD peut être interprétée comme
suit :
⊲ !DOCTYPE livre définit qu’il s’agit d’un document de type livre.
⊲ !ELEMENT livre (titre, auteurs) définit qu’un élément livre doit contenir comme
fils un élément titre et un élément auteurs.
⊲ !ATTLIST livre ISBN CDATA #REQUIRED définit l’attribut ISBN d’un élément livre.
Cet attribut est obligatoire pour chaque livre. S’il n’est pas spécifié, le document ne sera
pas validé.
⊲ !ELEMENT titre #CDATA et les autres lignes similaires définissent que les éléments titre,
nom et prenom doivent contenir des données CDATA. Rien d’autre n’est précisé à propos
de ces données, si ce n’est que ce sont des données textuelles.
⊲ !ELEMENT auteurs (personne+) définit qu’un élément auteurs doit être composé d’au
moins un élément personne.
⊲ !ELEMENT personne (nom,prenom) définit qu’un élément personne est composé d’un
élément nom et d’un élément prenom.
Cependant, un des gros défauts des DTD, malgré leur simplicité, est qu’il n’est pas possible
de définir des contraintes comme le nombre de fois qu’un élément particulier doit apparaître
dans le document, le type des données de chaque élément, etc. Il faut se rappeler que les DTD
ont été inventées à l’époque du SGML, utilisé pour décrire des documents. Des contraintes
d’instanciation et de typage sont moins critiques pour des documents XML orientés présentation,