Cours 7 : DTD et modélisation
<lgrobol@parisnanterre.fr>
Université Paris Nanterre
2024-03-04
On a vu que XML était à la fois plus souple et plus strict que HTML
Ce cours est inspiré entre autres des transparents XML et données internet de Pierre Nerzic
Les règles de syntaxe qu’on a vu dans le cours précédent définissent le fait d’être bien formé :
'
ou double "
quotes.Pour avoir une définition complète, mais très, très formelle : voir la spécification.
Même si un document XML est bien formé, ça ne signifie pas qu’il soit approprié pour une application.
Imaginez par exemple qu’un système de bibliographie soit prévu pour des données de la forme suivante :
Si on lui donne l’entrée suivante, qu’en faire ?
<?xml version="1.0" encoding="UTF-8"?>
<bibliography>
<book>
<title>Gender Trouble: Feminism and the Subversion of Identity</title>
</book>
</bibliography>
Le document est bien formé, mais il ne correspond pas aux attentes : il n’est pas valide
(Le terme n’est pas très heureux)
On dit qu’un document est valide s’il est conforme à une spécification qui décrit
Il existe plusieurs standard pour décrire une telle spécification : DTD, XML Schemas, RelaxNG, Schematron…
Ces langages modélisent des règles de validité plus ou moins précises et d’une manière plus ou moins lisible.
Valider un fichier XML, c’est le comparer à cette spécification à l’aide d’un outil qui indique
Dans ce cours, on se limitera aux DTD, plus anciennes et plus simples.
Une Document Type Definitions est une liste de règles définies au début d’un document XML pour permettre sa validation pendant sa lecture. Elle est déclarée par un élément spécial DOCTYPE
juste après le prologue et avant la racine :
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE itineraire ... >
<itineraire nom="essai">
<etape distance="0km">départ</etape>
<etape distance="1km">tourner à droite</etape>
</itineraire>
Attention : la syntaxe n’est pas la même que celle du contenu du XML
Une DTD peut être
Interne, intégrée au document, entre [ ]
:
Externe, dans un autre fichier, signalé par SYSTEM
suivi de l’URL du fichier :
Mixte, il y a à la fois un fichier et des définitions locales :
Une DTD externe peut être utilisée pour plusieurs fichiers XML, c’est donc ce qu’on utilise pour la plupart des applications.
Vous trouverez parfois un attribut standalone
valant "yes"
ou "no"
dans les prologues XML. Il est optionnel et présent uniquement quand il y a une DTD interne.
"no"
(par défaut) : la DTD interne fournit les valeurs par défaut et les entités et il peut y avoir des définitions externes (SYSTEM
)."yes
” : la DTD interne ne sert que pour la validation et ne peut pas employer d’entités ou de règles externes. Le document XML et avec sa DTD interne est totalement indépendant.De nombreux outils de validation existent, souvent associés à des éditeurs XML. Dans le cadre de ce cours, on peut utiliser l’extension XML de vscode ou se contenter d’un validateur simple comme https://www.truugo.com/xml_validator/.
Une DTD contient des règles comme celles-ci :
<!ELEMENT itineraire (etape+)>
<!ATTLIST itineraire nom CDATA #IMPLIED>
<!ELEMENT etape (#PCDATA)>
<!ATTLIST etape distance CDATA #REQUIRED>
Ce sont des règles qui définissent :
ELEMENT
) : leur nom et le contenu autorisé,ATTLIST
) : leur nom et options.Le nom présent après le mot-clé DOCTYPE
indique la racine du document. C’est un élément qui est défini dans la DTD.
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<!DOCTYPE itineraire [
<!ELEMENT itineraire (etape+)>
<!ATTLIST itineraire nom CDATA #IMPLIED>
<!ELEMENT etape (#PCDATA)>
<!ATTLIST etape distance CDATA #REQUIRED>
]>
<itineraire nom="essai">
<etape distance="0km">départ</etape>
<etape distance="1km">tourner à droite</etape>
</itineraire>
<!DOCTYPE itineraire
définit la racine <itineraire>
.
La règle <!ELEMENT nom contenu>
définit un élément : son nom et ce qu’il peut y avoir entre ses balises ouvrantes et fermantes.
La définition du contenu peut prendre différentes formes :
EMPTY
: signifie que l’élément doit être vide,ANY
: signifie que l’élément peut contenir n’importe quels éléments (définis dans la DTD) et textes (leur ordre d’apparition et leur nombre ne seront pas testés),#PCDATA
) : signifie que l’élément ne contient que du texte,Voici un exemple d’éléments simples :
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<!DOCTYPE itineraire [
<!ELEMENT itineraire ANY>
<!ELEMENT boucle EMPTY>
<!ELEMENT etape (#PCDATA)>
]>
<itineraire>
<boucle/>
<etape>départ</etape>
<etape>tourner à droite</etape>
<boucle></boucle>
<itineraire/> <!-- c'est possible avec ANY -->
<etape>tourner à gauche</etape>
</itineraire>
On peut restreindre les sous-éléments autorisés en donnant une liste ordonnée dans laquelle chaque sous-élément peut être suivi d’un quantificateur parmi *
, +
et ?
pour indiquer des répétitions, comme dans les expressions régulières.
Se lit ainsi : l’élément <boucle>
est en option, il doit être suivi d’au moins un <etape>
puis de zéro ou plus <variante>
.
La liste peut aussi contenir des alternatives notées ( contenu1 | contenu2 | … )
:
signifie que l’élément <information>
peut contenir soit un enfant <topoguide>
, soit un enfant <carte>.
On peut grouper plusieurs séquences avec des parenthèses pour spécifier ce qu’on désire :
On peut aussi indiquer que l’élément peut contenir du texte ou des sous-éléments :
On décrit un attribut avec une règle de la forme <!ATTLIST elem attr type valeur ...>
:
#REQUIRED
en tant que valeur indique que l’attribut est obligatoire#IMPLIED
qu’il est optionnel,"…"
, c’est la valeur par défaut.Il y a plusieurs types possibles, voici les plus utiles :
CDATA
l’attribut peut prendre n’importe quelle valeur texte. Ne pas confondre avec #PCDATA
.(mot1|mot2|...)
Cela force l’attribut à avoir l’une des valeurs de l’énumération.ID
l’attribut est un identifiant XML
ID
par élément.IDREF
l’attribut doit être égal, dans le document XML, à l’identifiant d’un autre élément.Les entités sont des symboles qui représentent des morceaux d’arbre XML ou des textes.
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<!DOCTYPE itineraire [
<!ELEMENT auteur ANY>
<!ELEMENT etape ANY>
<!ENTITY copyright "© IUT Lannion 2022">
<!ENTITY depart "<etape>Point de départ</etape>">
<!ENTITY equipement SYSTEM "equipement.xml">
]>
<itineraire>
<auteur>©right;</auteur>
&equipement;
&depart;
</itineraire>
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<!DOCTYPE itineraire [
<!ELEMENT auteur ANY>
<!ELEMENT etape ANY>
<!ENTITY copyright "© IUT Lannion 2022">
<!ENTITY depart "<etape>Point de départ</etape>">
<!ENTITY equipement SYSTEM "equipement.xml">
]>
<itineraire>
<auteur>© IUT Lannion 2022</auteur>
[Le contenu du fichier equipement.xml]
<etape>Point de départ</etape>
</itineraire>
Attention une entité ne peut remplacer que du XML bien formé et complet ! Ceci n’est pas valide :
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<!DOCTYPE itineraire [
<!ELEMENT auteur ANY>
<!ELEMENT etape ANY>
<!ENTITY depart "<etape>Point de départ">
]>
<itineraire>
&depart;</etape>
</itineraire>
Pour que ça le soit, c’est dans la définition de l’entité depart
qu’il faut mettre </etape>