Cours d'introduction à XML

Le minimum à savoir sur XML : intérêts, notion de document bien formé, technologies liées, etc.

GÉNÉRALITÉS

XML n'est pas un langage à proprement parler comme peut l'être HTML : XML est une famille de langages ayant en commun le respect de
certaines règles. Nous allons voir que là où HTML est simple, bien défini et non contraignant à la fois, XML est extensible et rigoureux.
En pratique, un fichier XML est un simple fichier texte, contenant des balises. La particularité de XML est qu'aucune balise n'est prédéfinie :
c'est au concepteur de définir les balises qui ont du sens pour lui.
Ces éléments permettent d'ores et déjà de dégager les intérêts de XML :
• Les documents sont faciles à compléter ou à modifier, il suffit d'un simple éditeur de texte parce qu'il s'agit de fichiers texte avec
un format connu et simple ;
• l'aspect textuel autorise également des recherches de base, soit à travers l'éditeur de texte, soit à l'aide des commandes de base
du système d'exploitation (grep sous Linux) ;
• comme il s'agit d'un format ouvert, des outils génériques sont disponibles et directement utilisable, du parser (lecture et
chargement du fichier en mémoire) à la transformation automatique avec XSLT ;
• l'utilisateur peut différencier le fond de la forme, ne travailler que sur la structure logique du document sans se soucier de sa
présentation ; cela car XML est clairement avant tout une solution de stockage et pas de publication.
Sur l'aspect stockage et recherche, le langage XML semble s'opposer aux bases de données. On l'a vu XML permet la saisie et les
modifications sans autre logiciel qu'un traitement de texte. Même une modification du schéma est facile à gérer en XML, au moins sur un
unique document XML. De plus, XML ne nécessite pas dans un premier temps l'apprentissage d'un langage comme SQL. Cependant,
l'efficacité des recherches reste l'avantage des bases de données.
XML est donc un standard ouvert et universel. On le trouve aujourd'hui dans les domaines les plus variés :
• édition (description d'ouvrage avec DocBook),
• graphisme (format SVG),
• mathématiques (formules avec MathML),
• chimie (CML permet la description de molécules en 3D),
• musique (partition musicale avec MusicML),
• etc.

UN DOCUMENT XML EN PRATIQUE

On a dit qu'un document XML était essentiellement du texte. Au milieu de ce texte, on va pouvoir trouver des éléments (ou balises), des
attributs associés aux éléments et enfin des entités.
Les règles que doit suivre un document XML sont les suivantes (si toutes ces contraintes sont respectées, le document XML est dit bien
formé) :

• la première ligne doit être de la forme <?xml version="1.0" encoding="iso-8859-1" ?> ; les deux attributs spécifient la version de
XML utilisée (1.0 ou 1.1) et le codage des caractères (utf-8 par défaut) ;
• les balises sont repérées par les caractères < et >, on écrira par exemple <balise>contenu</balise> ; la balise ouvrante peut
contenir des attributs ;
• toujours donner une valeur aux attributs, en suivant la syntaxe <balise attr="val"> (les guillemets sont obligatoires, les attributs ne
sont pas répétés dans la balise fermante) ;
• les entités sont systématiquement de la forme &nom; ;
• fermer toutes les balises ouvertes ; une balise sans contenu pourra être ouverte et immédiatement fermée en faisant suivre son
nom d'un slash, par exemple avec la balise br (passage à la ligne en HTML) : <br /> ;
• veiller à l'ordre de fermeture des balises : la première ouverte est toujours la dernière fermée ;
• respecter la casse : on peut utiliser majuscules et minuscules dans les noms de balises mais une fois qu'un nom d'élément a été
fixé, il faut s'y tenir, la balise <cv> ne pourra être fermée ni par </Cv> ni par </CV> ;
• ne pas utiliser de caractères réservés à XML dans le texte du document : <, > et & ; ces caractères pourront être respectivement
obtenues à l'aide des entités &lt;, &gt; et &amp; ;
• les noms de balises et d'attributs doivent être des noms XML :
• le premier caractère est une lettre quelconque ou un _ (underscore ou tiret bas) ;
• les caractères suivants peuvent être des lettres, des chiffres, des tirets bas (_), des traits d'union (-) ou des points (.) ;
• il n'y a pas de limitation sur la longueur d'un nom XML.
à noter que cette dernière règle interdit à un nom de balise de commencer par un chiffre. Cependant, la liberté pour choisir un nom
d'élément reste grande car on peut y faire figurer n'importe quelle lettre... or, le codage privilégié dans les documents et applications XML
est l'UTF-8 qui contient les alphabets latin, arabe, japonais, etc. Plus spécifiquement, on n'hésitera pas à utiliser des lettres accentuées
dans les noms d'éléments.
Finalement, voici un exemple de document XML bien formé :
<?xml version="1.0" encoding="iso-8859-1" ?>
<!-- commentaire : voici mon curriculum vitae -->
<cv>
<!-- commentaire : état civil -->
<identité naissance="1980">
<nom>Moustique</nom>
<prénom>Jules</prénom>
<prénom>Édouard</prénom>
<nationalité>grolandaise</nationalité>
</identité>
<!-- commentaire : mes diplômes maintenant -->
<diplome année="2005" intitulé="Master ID" mention="TB" />
<diplome année="2003" intitulé="Licence " mention="AB" />
</cv>

TECHNOLOGIES LIÉES
La simplicité et l'ouverture de XML fait qu'un document XML peut facilement être modifier par un être humain, sans outil spécifique.
La rigueur de XML (sensibilité à la casse, guillemets obligatoires pour encadrer les valeurs des attributs, fermeture systématique des
balises, etc.) autorise des traitements automatiques, qui pourront être partagés par tous les langages XML.
• contraindre un langage XML : DTD, Schémas, Relax NG ;
• mise en page avec CSS

<?xml-stylesheet href="livres.css" type="text/css">

en particulier utilisation de la propriété display (block ou inline) ;
• interrogration, requêtes sur un document XML avec XPath ou XQuery ;
• transformation de documents avec XSLT ;
• mise en page avec XSL-FO (Formatting Objects) et un programme comme FOP).
Cours sur l'écriture de DTD

Comment définir une DTD : éléments et imbrication, attributs, entités.

MOTIVATIONS
Nous avons vu comment il était possible d'écrire du XML en respectant ses règles de syntaxe et d'obtenir ainsi un document XML bien
formé.
Nous allons maintenant décrire comment spécifier des contraintes plus précises et propres à notre langage XML. Cela va prendre ici la
forme d'une DTD (Définition de Type de Document).
On dira alors qu'en plus d'être bien formé, le document est valide par rapport à une certaine DTD.
Cette spécification d'une grammaire pour un langage et la possibilité de tester automatiquement son respect par un document donné,
présentent les avantages suivants :
• faciliter l'échange et la mise en commun de documents produits par des rédacteurs différents ;
• aider les développeurs qui conçoivent des outils automatiques pour traiter les documents respectant la même DTD.

LIER UN FICHIER XML À UNE DTD

DTD INTERNE
Dans ce cas, la spécification de la DTD arrive dans l'entête du document XML : on trouve d'abord le mot-clef DOCTYPE suivi de l'élément
servant de racine au document et enfin la DTD elle-même entre crochets :
<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE cv [
.
.
.
]>
<cv>
.
.
.
</cv>

DTD EXTERNE
Cette fois, la DTD est détachée dans un fichier séparé, on se contente d'y faire référence dans l'entête du document XML. On retrouve le
mot-clef DOCTYPE suivi de l'élément servant de racine, puis le mot-clef SYSTEM suivi d'une URI menant au fichier DTD.
À noter également que la première ligne doit faire apparaître l'attribut standalone avec la valeur no.
<?xml version="1.0" encoding="iso-8859-1" standalone="no" ?>
<!DOCTYPE cv SYSTEM "cv.dtd">
<cv>
.
.
.
</cv>

À noter que, sans toucher au document XML, il est possible de faire le lien au moment de la validation. Par exemple, avec xmllint, on écrira :
xmllint --dtdvalid madtd.dtd mondoc.xml --noout

DTD MIXTE
Enfin, il est possible de mélanger les deux notations pour avoir une partie de la DTD dans un fichier séparé et une autre partie embarquée
dans le document XML :
<?xml version="1.0" encoding="iso-8859-1" standalone="no" ?>
<!DOCTYPE cv SYSTEM "cv.dtd" [
.
.
.
]>
<cv>
.
.
.
</cv>
DÉFINIR LES ÉLÉMENTS ET LEURS CONTENUS
Il s'agit ici de déclarer les éléments autorisés à apparaître dans le document, ainsi que leurs imbrications possibles. La forme générale est la
suivante :
<!ELEMENT nom_element modèle_de_contenu>

Les noms des éléments (comme ceux des attributs) doivent être des noms XML :

• le premier caractère est une lettre quelconque ou un _ (underscore ou tiret bas) ;

• les caractères suivants peuvent être des lettres, des chiffres, des tirets bas (_), des traits d'union (-) ou des points (.) ;
• il n'y a pas de limitation sur la longueur d'un nom XML.
Nous passons maintenant en revue les différents modèles de contenu utilisables dans les DTD.

CONTENU PUREMENT TEXTUEL

Si l'élément peut contenir du texte brut mais pas de nouvelles balises, on utilisera le modèle de contenu PCDATA :
<!ELEMENT téléphone (#PCDATA)>

Aucune balise n'est donc tolérée dans ce type de contenu mais, par contre, il est possible d'y utiliser des entités.

SOUS-ÉLÉMENTS
Ici, on va lister les sous-éléments pouvant apparaître dans le contenu, par exemple :
<!ELEMENT identité (prénom,nom)>

indique que l'élément identité doit contenir, dans l'ordre, un élément prénom, un élément nom, et rien d'autre.
Il est possible de moduler le nombre d'apparitions d'un sous-élément en utilisant des quantifieurs après les noms d'éléments. Les
quantifieurs utilisables dans les DTD sont :

• ? : 0 ou 1 fois ;
• * : 0, 1 ou plus ;
• + : 1 ou plus.

L'exemple suivant indique que l'élément identité doit contenir, toujours en respectant l'ordre, un ou plusieurs éléments prénom, un
élément surnom facultatif et exactement un élément nom :
<!ELEMENT identité (prénom+,surnom?,nom)>

ALTERNATIVES
Il est également possible de définir les sous-éléments qui peuvent apparaître de manière exclusive : si c'est l'un, ça n'est pas les autres.
Dans l'exemple ci-dessous, une expérience professionnelle peut être soit un emploi, soit un stage :
<!ELEMENT expérience (stage|emploi)>

COMBINAISONS
Enfin, il est possible de combiner les syntaxes vues précédemment :
<!ELEMENT diplôme ( (intitulé,année) | (année,compétences,stage?)+ )>

Dans ce cas, un diplôme est :

• soit l'intitulé du diplôme et l'année d'obtention ;

• soit une suite d'année, avec les compétences acquises cette année là, éventuellement validées par un stage.

CONTENU MIXTE
Une possibilité intéressante est de pouvoir mixer du texte brut avec des balises sans mettre plus de contraintes sur l'ordre et le nombre
d'apparitions de ces balises. Cela se fait avec une alternative entre un contenu de type PCDATA et des sous-éléments, cette alternative
pouvant se répéter plusieurs fois :
<!ELEMENT parcours (#PCDATA | diplôme)*>

Ici, on a un élément parcours qui a un contenu mixte : du texte pouvant contenir un nombre quelconque de sous-éléments diplôme.

CONTENU VIDE
Un élément peut également n'avoir aucun contenu, comme c'est le cas par exemple de la balise br (retour à la ligne en HTML). Cela se
précise dans la DTD de la manière suivante :
<!ELEMENT br EMPTY>
Une telle balise sera donc ouverte et immédiatement refermée avec la notation suivante : <br />.

CONTENU QUELCONQUE
On termine avec la possibilité d'autoriser n'importe quel contenu à apparaître dans un élément.
<!ELEMENT mavie ANY>

Dans ce cas, l'élément mavie pourra contenir du texte brut mélangé avec toute balise définie dans la DTD, dans n'importe quel ordre, autant
de fois que l'on veut.
Ce modèle de contenu est en contradiction avec l'esprit des DTD, lesquelles visent plutôt à restreindre au maximum le rédacteur. Une
utilisation cependant pratique du ANY intervient lors de la rédaction d'une DTD alors que les documents XML sont déjà existants : dans ce
cas, on définit les éléments de plus haut niveau en indiquant ANY pour leurs contenus, si les documents sont valides, on reprend la DTD en
affinant le contenu de chacun des éléments, etc.

UN EXEMPLE SIMPLE ET COMPLET

Une DTD que l'on enregistre dans un fichier nommé livres.dtd :
<!ELEMENT liste_livres (livre+)>
<!ELEMENT livre (titre,auteur+,éditeur,description?,prix)>
<!ELEMENT titre (#PCDATA)>
<!ELEMENT auteur (#PCDATA)>
<!ELEMENT éditeur (#PCDATA)>
<!ELEMENT description (#PCDATA)>
<!ELEMENT prix (#PCDATA)>

et un fichier XML la respectant :

<?xml version="1.0" encoding="iso-8859-1" standalone="no" ?>
<!DOCTYPE liste_livres SYSTEM "livres.dtd">
<liste_livres>
<livre>
<titre>Comprendre XSLT</titre>
<auteur>Bernd Amann</auteur>
<auteur>Philippe Rigaux</auteur>
<éditeur>O'Reilly</éditeur>
<description>
Le livre suit une double démarche de présentation des aspects les plus simples, puis, progressivement,
les plus complexes du langage XSLT, et d'application des mécanismes de ce langage à des cas concrets
d'utilisation. Il débute par un chapitre introductif en forme d'étude de cas qui propose, sur une
application de type "Officiel des spectacles" adaptée au Web, une déclinaison des différents thèmes
couverts.
</description>
<prix>33 euros</prix>
</livre>
<livre>
<titre>Learning XML</titre>
<auteur>Erik T. Ray</auteur>
<éditeur>O'Reilly</éditeur>
<prix>40 dollars</prix>
</livre>
</liste_livres>

DÉFINIR LES ATTRIBUTS

La syntaxe des DTD utilise cette fois le mot ATTLIST, suivi du nom de l'élément concerné, suivi de la liste de ses attributs : pour chacun, on
trouvera son nom, son type et son caractère optionnel ou non.
Comme nous l'avons déjà indiqué, les noms des attributs doivent être des noms XML :

• le premier caractère est une lettre quelconque ou un _ (underscore ou tiret bas) ;

• les caractères suivants peuvent être des lettres, des chiffres, des tirets bas (_), des traits d'union (-) ou des points (.) ;
• il n'y a pas de limitation sur la longueur d'un nom XML.
Une déclaration d'attributs typique aura la forme suivante :
<!ATTLIST identité prénom CDATA #REQUIRED
nom CDATA #REQUIRED
surnom CDATA #IMPLIED>

Dans ce cas, l'élément identité possède trois attributs prénom, nom et surnom. Les deux premiers sont obligatoires (REQUIRED) et le
dernier est optionnel (IMPLIED). À noter également la possibilité pour un attribut d'être FIXED, c'est-à-dire de prendre systématiquement la
même valeur.
Nous passons maintenant en revue les différents types d'attributs.

CDATA
Type général qui permet de saisir un texte quelconque pour un attribut de ce type.
NMTOKEN
Il s'agit ici un nom XML mais sans restriction sur le premier caractère (qui peut donc être un chiffre). Une contrainte essentielle est donc
qu'un attribut de ce type ne contiendra pas d'espace.
Par exemple, un code postal pourra être déclaré de ce type :
<!ATTLIST ville nom CDATA #REQUIRED
code NMTOKEN #REQUIRED>

NMTOKENS
Une suite de NMTOKEN, séparés par des espaces.

ÉNUMÉRATION
Dans ce cas, l'attribut ne peut prendre qu'un nombre fini de valeurs et l'on en donne la liste exhaustive, ces valeurs étant séparées par des |.
<!ATTLIST date jour (lundi|mardi|mercredi|jeudi|vendredi|samedi|dimanche) #REQUIRED
num NMTOKEN #REQUIRED
mois NMTOKEN #REQUIRED
année NMTOKEN #REQUIRED>

ID
Il doit s'agir d'un nom XML qui identifie de manière unique l'élément. Autrement dit, une valeur qui apparaît dans un tel attribut ne peut pas
apparaître une seconde fois dans le même document.
<!ATTLIST diplôme intitulé CDATA #REQUIRED
code ID #REQUIRED>

Cette notion est tout à fait comparable à la clef primaire d'une table dans une base de données. Cependant, il faut garder à l'esprit
qu'un ID ne peut pas être un nombre (car la valeur d'un ID doit être un nom XML).

IDREF
Un attribut de type IDREF doit contenir une valeur utilisée comme ID ailleurs dans le document.
<!ATTLIST stage entreprise CDATA #REQUIRED
diplôme IDREF #REQUIRED>

IDREFS
Une suite de IDREF, séparées par des espaces.

ENTITY
La valeur d'un attribut de ce type doit être une entité définie dans la DTD (voir section suivante pour la définition des entités).

ENTITIES
Une suite de ENTITY, séparées par des espaces.

DÉFINIR LES ENTITÉS

Intuitivement, il s'agit de définir des raccourcis (ou des alias) qui seront utilisables dans les documents XML liés à la DTD. Certaines entités
sont déjà définies en XML : &lt; (<), &gt; (>), &amp; (&), &quot; ("), et &apos; (').

ENTITÉS GÉNÉRALES
Le mot ENTITY suivi du nom de l'entité, puis de sa valeur entre guillemets ou apostrophes.
<!ENTITY ac "anticonstitutionnellement">

Cette déclaration permettra d'utiliser &ac; dans le document XML associé à la DTD.
La valeur de l'entité peut contenir du texte, des balises et des entités (le code XML ainsi défini doit être bien formé). Par exemple,
<!ENTITY piedpage '<hr />
<p>
Copyright 2005, dernière mise à jour octobre 2005.
</p>'>
ENTITÉS GÉNÉRALES EXTERNES
Si le code associé à une entité devient très important, il peut être intéressant de le détacher dans un fichier à part, ce que permet la syntaxe
suivante :
<!ENTITY piedpage SYSTEM "pp.xml">

Dans ce cas, le fichier pp.xml doit être un fichier XML bien formé (première ligne de déclaration de la version XML et du codage utilisé,
fermeture systématique des balises ouvertes, etc.).

ENTITÉS GÉNÉRALES EXTERNES NON PARSÉES

Enfin, il y a le cas où le fichier externe représenté par l'entité ne contient pas du XML et ne doit donc pas être parcouru par les applications
traitant le document.
<!NOTATION jpeg SYSTEM "image/jpeg">
<!ENTITY maphoto SYSTEM "toto.jpg" NDATA jpeg>

Ici, en plus du fichier externe, on trouve NDATA pour Notation Data et jpeg faisant référence à une NOTATION définie précédemment.
La NOTATION doit permettre à l'application de traiter le fichier externe : il peut s'agir d'un type MIME comme ici ou d'une commande à
exécuter.
Une telle entité pourra apparaître comme valeur d'un attribut défini avec le type ENTITY.

INTÉGRER LES ENTITÉS

Naturellement, les entités définies dans la DTD et utilisées dans le document XML devront tôt ou tard être remplacées par leurs véritables
valeurs
Certains navigateurs opèrent ce remplacement lorsque l'on les utilise pour visualiser ce document XML. Ca n'est pas le cas de Firefox par
exemple qui choisit de ne pas remplacer les entités et cela pour des raisons de sécurité.
Un moyen de tester les entités est d'utiliser xmllint :
xmllint doc.xml --valid --noent

on charge la dtd avec --valid et on demande la substitution des entités avec --noent.

ENTITÉS PARAMÈTRES
Ce type d'entité permet d'éviter de répéter les mêmes informations. Par exemple, on donnera toujours le nom et le prénom d'une personne,
quel que soit son statut dans le document :
<!ELEMENT identité (nom,prénom,naissance)>
<!ELEMENT enseignant (nom,prénom)>

L'utilisation d'une entité paramètre comme suit permet de ne pas répéter et autorise à enrichir ultérieurement la description d'une personne :
<!ENTITY % elements_personne "nom,prénom">
<!ELEMENT identité (%elements_personne;,naissance)>
<!ELEMENT enseignant (%elements_personne)>

DTD MODULAIRES

Des instructions (INCLUDE et IGNORE) permettent de prendre en compte un bloc de la DTD, ou de l'ignorer. La syntaxe est la suivante :
<![IGNORE[
<!ELEMENT personne (nom,prénom)>
<!ELEMENT nom (#PCDATA)>
<!ELEMENT prénom (#PCDATA)>
]]>

<![INCLUDE[
<!ELEMENT entreprise (dénomination,taille)>
<!ELEMENT dénomination (#PCDATA)>
<!ELEMENT taille (#PCDATA)>
]]>

Ce mécanisme devient puissant avec l'utilisation conjointe d'entités-paramètres.

<!ENTITY % bloc_personnes "INCLUDE">
<!ENTITY % bloc_entreprises "IGNORE">
<![%bloc_personnes;[
<!ELEMENT personne (nom,prénom)>
<!ELEMENT nom (#PCDATA)>
<!ELEMENT prénom (#PCDATA)>
]]>
<![%bloc_entreprises[
<!ELEMENT entreprise (dénomination,taille)>
<!ELEMENT dénomination (#PCDATA)>
<!ELEMENT taille (#PCDATA)>
]]>
Il est notable que ce choix ait été fait par le W3C pour définir la DTD du XHTML.

BILAN SUR LES DTD

Les reproches suivants sont systématiquement faits aux DTD :
• l'élément racine n'est pas spécifié pas dans la DTD ; un document peut être valide en utilisant n'importe quelle balise de la DTD
comme racine ;
• le nombre d'apparitions d'un élément ne peut pas être contraint précisément, puisque l'on ne dispose que des
quantifieurs ?, * et +, on aimerait pouvoir dire qu'un élément doit apparaître plus de 2 fois mais toujours moins de 5 ;
• on ne dispose pas de types pour les contenus des attributs et des éléments (nom, date, code postal, numéro de téléphone, url,
adresse mail, etc.) ;
• on ne peut pas contraindre la forme de ces contenus (entre 5 et 20 caractères, contenant un signe @, etc. ) ;
• enfin, le langage utilisé pour définir une DTD n'est pas un langage XML !
Pour palier à ces manques, d'autres propositions ont été faites, permettant elles aussi de spécifier un langage XML, citons les XML
Schema et Relax NG.
L'écriture de XML Schémas

Comment définir un XML Schéma : types, modèles de contenu, éléments et imbrication, attributs, etc.

DTD VERSUS XML SCHÉMA

Les DTD :
• types pauvres, peu de contraintes sur les contenus
• nombre d'apparitions d'un élément à choisir entre 0 et 1
• pas de gestion des espaces de noms
• pas un format XML
Les schémas :
• utilisation et définition de types, contraintes sur les contenus
• possibilité de définir précisément le nombre d'apparitions d'un élément
• espaces de noms supportés
• format XML, parsable facilement

LA BASE PRATIQUE
Le fichier XML :
<racine
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="monschema.xsd">
.
.
.
</racine>

Le fichier contenant le schéma (.xsd) :

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
.
.
.
</xs:schema>

La validation avec xmllint par exemple :

xmllint --schema monschema.xsd undoc.xml

MODÈLES DE CONTENU ET TYPES

On distingue deux familles de types :
• les simples qui caractérisent le contenu d'un noeud textuel ou d'un attribut ;
• les complexes sont utilisés pour décrire les autres formes de contenu.
Cela nous amène à distinguer différents modèles de contenu pour un élément selon la nature de ses noeuds fils autorisés :
• vide : aucun noeud fils ;
• simple : ne contient que des noeuds textuels ;
• complexe : que des sous-éléments ;
• mixte : à la fois du texte et des sous-éléments.
Dès qu'un élément possède un attribut, il est considéré comme étant de type complexe, même si son contenu est vide ou simple.

LES TYPES SIMPLES PRÉDÉFINIS

Consulter la recommandation du W3C pour avoir la liste exhaustive des types prédéfinis. Parmi ceux-ci, citons :
• string
• decimal, integer, positiveInteger, real
• date, dateTime, duration
• ID, IDREF, ENTITY, NMTOKEN, etc. (venant des DTD)
DÉFINIR UN NOUVEAU TYPE SIMPLE

Liste de valeurs d'un même type simple

<xs:simpleType name="telephone">
<xs:list itemType="xs:integer" />
</xs:simpleType>

Union de types simples

<xs:simpleType name="contact">
<xs:union memberTypes="adresse telephone" />
</xs:simpleType>

Restriction d'un type simple

consiste à ajouter des contraintes à un type de base, on distingue différents types de contraintes, appelés facettes, différents suivant le type
qui subit la restriction.
• Énumération pour les chaînes de caractères, nombres et dates
<xs:simpleType name="jourSemaine">
<xs:restriction base="xs:string">
<xs:enumeration value="lundi" />
<xs:enumeration value="mardi" />
<xs:enumeration value="mercredi" />
<xs:enumeration value="jeudi" />
<xs:enumeration value="vendredi" />
<xs:enumeration value="samedi" />
<xs:enumeration value="dimanche" />
</xs:restriction>
</xs:simpleType>

• longueur fixe, minimale ou maximale des chaînes de caractères

<xs:simpleType name="telephone">
<xs:restriction base="xs:string">
<xs:length value="10" />
</xs:restriction>
</xs:simpleType>

<xs:simpleType name="motdepasse">
<xs:restriction base="xs:string">
<xs:minLength value="8" />
<xs:maxLength value="20" />
</xs:restriction>
</xs:simpleType>

<xs:simpleType name="telephone">
<xs:restriction base="xs:string">
<xs:length value="10" />
</xs:restriction>
</xs:simpleType>

• bornes sur les entiers et les dates

<xs:simpleType name="temperature">
<xs:restriction base="xs:integer">
<xs:minInclusive value="-15" />
<xs:maxInclusive value="+35" />
</xs:restriction>
</xs:simpleType>

aussi minExclusive et maxExclusive

• nombre de chiffres sur les nombre
<xs:simpleType name="codepostal">
<xs:restriction base="xs:integer">
<xs:totalDigits value="5" />
</xs:restriction>
 </xs:simpleType>

<xs:simpleType name="prix">
<xs:restriction base="xs:decimal">
<xs:fractionDigits value="2" />
</xs:restriction>
</xs:simpleType>

• expressions régulières sur tous les types simples (?)

<xs:simpleType name="mail">
<xs:restriction base="xs:string">
<xs:pattern value=".+@.+" />
</xs:restriction>
</xs:simpleType>

DÉFINIR UN ATTRIBUT

• utilisation de la balise <xs:attribute /> ;

• indiquer le nom de l'attribut avec l'attribut <xs:attribute name="score" /> ;
• définir le type du contenu de l'élément en utilisant l'attribut type ;
• préciser son caractère obligatoire ou optionnel (required ou optional) à l'aide de l'attribut use ;
• éventuellement, indiquer une valeur par défaut avec l'attribut default.

<xs:attribute name="score" type="xs:integer" use="required" default="0" />

DÉFINIR UN ÉLÉMENT DE TYPE SIMPLE

• utilisation de la balise <xs:element /> ;

• indiquer le nom de l'élément avec l'attribut name ;
• préciser le nombre d'apparition autorisé pour cet élément à l'aide des attributs minOccurs et maxOccurs ;
• définir le type du contenu de l'élément en utilisant l'attribut type ;

Finalement :
<xs:element name="nom" minOccurs="1" maxOccurs="1" type="xs:string" />
<xs:element name="prénom" minOccurs="1" maxOccurs="unbounded" type="xs:string" />
<xs:element name="surnom" minOccurs="0" maxOccurs="1" type="xs:string" />

DÉFINIR UN ÉLÉMENT DE TYPE COMPLEXE

on définit les sous-éléments puis les attributs

CONTENU VIDE AVEC ATTRIBUT

<xs:element name="br">
<xs:complexType>
<xs:attribute name="class" type="string" />
</xs:complexType>
</xs:element>

CONTENU SIMPLE AVEC ATTRIBUT

extension ou restriction sur un type simple

<xs:element name="title">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="string">
<xs:attribute name="lang" type="string" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
CONTENU COMPLEXE

Il s'agit à nouveau d'utiliser <xs:complexType> puis de lister les sous-éléments autorisés au sein de l'une de ces balises :

• <xs:sequence> : les sous-éléments doivent tous apparaître, dans l'ordre ;

• <xs:all> : les sous-éléments doivent tous apparaître, mais dans un ordre quelconque ;
• <xs:choice> : seulement un des sous-éléments peut apparaître, au choix.

<xs:element name="auteur">
<xs:complexType>
<xs:sequence>
<xs:element name="nom" minOccurs="1" maxOccurs="1" type="xs:string" />
<xs:element name="prénom" minOccurs="1" maxOccurs="unbounded" type="xs:string" />
<xs:element name="surnom" minOccurs="0" maxOccurs="1" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>

CONTENU MIXTE

On définit pour cela un type complexe en précisant un attribut mixed, celui-ci indiquant que du texte peu se glisser entre tous les sous-
éléments autorisés.
<xs:element name="p">
<xs:complexType mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="em" type="xs:string" />
<xs:element name="strong" type="xs:string" />
</xs:choice>
</xs:complexType>
</xs:element>

STRATÉGIES D'ÉCRITURE D'UN SCHÉMA

En suivant l'arborescence des documents :

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="CHAMPIONNAT">
<xs:complexType>
<xs:sequence>
<xs:element name="JOURNEE" maxOccurs="38">
<xs:complexType>
<xs:sequence>
<xs:element name="RENCONTRE" maxOccurs="10">
<xs:complexType>
<xs:attribute name="DOMICILE" type="xs:string" />
<xs:attribute name="EXTERIEUR" type="xs:string" />
<xs:attribute name="SCORED" type="xs:string" />
<xs:attribute name="SCOREE" type="xs:string" />
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="NUMERO" type="xs:integer" />
<xs:attribute name="DATE" type="xs:string" />
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="DIVISION" type="xs:integer" />
<xs:attribute name="SAISON" type="xs:string" />
</xs:complexType>
</xs:element>

</xs:schema>

ou à plat avec références aux éléments déjà définis :

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:attribute name="DOMICILE" type="xs:string" />

<xs:attribute name="EXTERIEUR" type="xs:string" />
<xs:attribute name="SCORED" type="xs:string" />
<xs:attribute name="SCOREE" type="xs:string" />
<xs:attribute name="NUMERO" type="xs:integer" />
<xs:attribute name="DATE" type="xs:string" />
<xs:attribute name="DIVISION" type="xs:integer" />
<xs:attribute name="SAISON" type="xs:string" />

<xs:element name="RENCONTRE">
<xs:complexType>
<xs:attribute ref="DOMICILE" />
<xs:attribute ref="EXTERIEUR" />
<xs:attribute ref="SCORED" />
<xs:attribute ref="SCOREE" />
</xs:complexType>
</xs:element>

<xs:element name="JOURNEE">
<xs:complexType>
<xs:sequence>
<xs:element ref="RENCONTRE" maxOccurs="10" />
</xs:sequence>
<xs:attribute ref="NUMERO" />
<xs:attribute ref="DATE" />
</xs:complexType>
</xs:element>

<xs:element name="CHAMPIONNAT">
<xs:complexType>
<xs:sequence>
<xs:element ref="JOURNEE" maxOccurs="38" />
</xs:sequence>
<xs:attribute ref="DIVISION" />
<xs:attribute ref="SAISON" />
</xs:complexType>
</xs:element>

</xs:schema>

La première stratégie contraint l'élément racine, pas la seconde. La seconde est plus modulaire et permet de réutiliser des parties du
schéma.

CONTRAINTES D'UNICITÉ ET DE CLEF

On peut toujours utiliser les ID et IDREF des DTD mais c'est plus pauvre que le mécanisme offert par XML-Schémas. Celui-ci utilise (un
sous-ensemble) des expressions XPath.

UNICITÉ
<xs:element name="bibliotheque">
<xs:complexType>
...
</xs:complexType>
<xs:unique name="uniquelivre">
<xs:selector xpath="book" />
<xs:field xpath="isbn" />
</xs:unique>
</xs:element>

on peut mettre plusieurs fields

CLÉS
<xs:element name="bibliotheque">
<xs:complexType>
...
</xs:complexType>
 <xs:key name="cleflivre">
<xs:selector xpath="livre" />
<xs:field xpath="isbn" />
</xs:key>
</xs:element>

pareil que unique avec présence obligatoire de la clé en plus.

RÉFÉRENCE
<xs:keyref name="refcleflivre" refer="cleflivre">
<xs:selector xpath="citation"/>
<xs:field xpath="ref" />
</xs:keyref>

REGROUPEMENTS

REGROUPER DES ATTRIBUTS

<xs:attributeGroup name="attrs_photo">
<xs:attribute name="source" type="nomfichier" />
<xs:attribute name="alt" type="xs:string" />
</xs:attributeGroup>

<xs:element name="identite">
<xs:complexType>
<xs:attributeGroup ref="attrs_photo" />
<xs:attribute name="personne" type="xs:string" />
</xs:complexType>
</xs:element>

<xs:element name="paysage">
<xs:complexType>
<xs:attributeGroup ref="attrs_photo" />
<xs:attribute name="lieu" type="xs:string" />
</xs:complexType>
</xs:element>

REGROUPER DES ÉLÉMENTS

regrouper par all, choice, ou sequence...
<xs:group name="elems_text">
<xs:choice>
<xs:element ref="refacteur" />
<xs:element ref="film" />
<xs:element ref="realisateur" />
<xs:element ref="annee" />
</xs:choice>
</xs:group>

<xs:element name="p">
<xs:complexType mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:group ref="elems_text" />
</xs:choice>
</xs:complexType>
</xs:element>
Les transformations XSLT
Présentation de XSLT, langage de transformation pour les documents XML.

MOTIVATIONS ET GÉNÉRALITÉS
XSLT est un langage central dans le monde XML et beaucoup de qualités reconnues de XML reposent en fait sur l'utilisation de XSLT :
productions de versions diffusables (HTML, PDF, etc.), pérennité des documents, ouverture des formats, interopérabilité, etc.
La première motivation est d'associer un style à un document XML, tout comme on associe une feuille de style CSS à une page HTML. Les
CSS sont utilisables avec les documents XML mais présentent plusieurs défauts :
• les CSS ne permettent pas d'extraire les valeurs des attributs pour les faire apparaître ;
• il est possible avec les CSS de placer les blocs les uns par rapport aux autres, d'en faire disparaître certains, mais pas de tout
réorganiser de fond en comble, encore moins de créer de nouvelles données ;
• le langage CSS n'est pas un langage XML.
Cela amène à la définition d'un nouveau format : XSL pour eXtensible Stylesheet Language. Cependant, les critiques des CSS ont fait
apparaître deux besoins bien différents : mettre en page le document XML et, par ailleurs, lui faire subir des transformations. D'où la
définition de deux langages XML : XSL-FO (XSL Formating Objects) et XSLT (XSL Transformations). Dans ce cours, on ne s'intéresse qu'à
la partie XSLT.
Une transformation XSLT est donc d'abord un fichier XML, auquel on donne en général l'extension .xsl et qui au minimum contient :
<?xml version="1.0" ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
.
... ici des règles de transformation ...
.
</xsl:stylesheet>

De manière générale, XSLT permet de transformer un document XML en un autre document XML. Parmi les formats utilisés comme sortie
de XSLT citons : FO, XHTML, SVG, DocBook, etc.
Pour appliquer une feuille de transformation XSLT à un document XML, une première solution consiste à introduire un lien dans la
transformation dans le document :
<?xml version="1.0" ?>
<?xml-stylesheet type="text/xsl" href="doc2html.xsl" ?>
<document>
.
.
.
</document>

Ainsi, les programmes traitant le document et disposant d'un processeur XSLT pourront choisir d'appliquer la transformation, c'est le cas par
exemple des navigateurs. Une autre solution est d'indiquer explicitement la feuille XSLT à appliquer au moment de la transformation, par
exemple avec xsltproc :
xsltproc doc2html.xsl doc.xml > doc.html

Terminons avec OpenOffice qui est lui aussi capable d'appliquer des transformations XSLT pour charger des documents dans un format
XML quelconque.

EXTRAIRE DU DOCUMENT D'ORIGINE

Le premier besoin est de pouvoir récupérer des valeurs dans le document XML d'origine, où qu'elles se trouvent. Pour cela, on met à
contribution le langage XPath qui permet précisément d'obtenir une valeur ou un ensemble de noeuds particuliers.

L'INSTRUCTION VALUE-OF
Dans sa forme la plus simple et la plus utilisée, l'élément value-of est associé à son attribut select qui lui contient une requête XPath
désignant une valeur (le contenu d'en élément textuel, d'un attribut ou encore le résultat d'un calcul). En voici quelques exemples :
<xsl:value-of select="nom" />
<xsl:value-of select="@date" />
<xsl:value-of select="/personnes/personne[@id='p12']/nom" />
<xsl:value-of select="." />
<xsl:value-of select="count(/personnes/personne)" />
<xsl:value-of select="position()" />

L'instruction value-of possède un autre attribut disable-output-escaping qui peut prendre deux valeurs yes ou no. Vaut no par défaut
indiquant que les caractères comme < ou > doivent être remplacés par leurs entités : respectivement &lt; et &gt;. On le met donc à yes pour
contraindre la sortie de ces caractères sans modification.
L'appel à linstruction value-of provoque la sortie de la valeur calculée dans le document final.
LES VARIABLES

Un autre besoin est de récupérer une valeur ou des noeuds et simplement de les stocker avant de les traiter. Pour cela, on définit une
variable comme dans un langage de programmation quelconque, ici avec un élément noté xsl:variable, un attribut name pour nommer la
variable et, à nouveau, un attribut select contenant une requête XPath.
<xsl:variable name="nomdefamille" select="nom" />
<xsl:variable name="ladate" select="@date" />
<xsl:variable name="nbpersonne" select="count(/personnes/personne)" />
<xsl:variable name="lapersonne" select="/personnes/personne[@id='p12']" />
<xsl:variable name="lesgens" select="/personnes/personne" />

Une fois la variable définie, on peut l'utiliser (typiquement dans une nouvelle requête XPath) en utilisant son nom avec le signe dollar devant
:
<xsl:variable name="refpersonne" select="citation/@ref" />
<xsl:value-of select="/personnes/personne[@id=$refpersonne]/nom" />

<xsl:variable name="nb_matches" select="count(//RENCONTRE)" />

<xsl:variable name="nb_victoires" select="count(//RENCONTRE[@SCORED > @SCOREE])" />
<xsl:variable name="pc_victoires" select="100.*$nb_victoires div $nb_matches" />
<xsl:value-of select="format-number($pc_victoires,'##.##')" />

XSLT est un langage de programmation fonctionnel et par conséquent les variables ne sont pas modifiables. Il est donc déraisonnable
d'écrire quelque chose comme :
<xsl:variable name="i" select="$i+1" />

COPY ET COPY-OF

L'instruction copy-of reproduit un ensemble de noeuds récupéré par un select, avec la sous-arborescence de chacun. L'instruction copy elle
ne recopie que le noeud courant lui-même, sans son contenu et sans ses fils (il va donc falloir définir le nouveau contenu et les nouveaux
descendants).

<xsl:copy-of select="*" />

<xsl:copy-of select="diplome" />
<xsl:copy>
coucou
</xsl:copy>

Des exemples plus précis seront fournis dans les prochaines sections.

LES RÈGLES DE TRANSFORMATION

Les règles constituent les briques de base : on va y décrire une transformation portant sur un certains type de noeuds. Une telle règle est
représentée par l'élément xsl:template et contient le code XML à produire pour créer le nouveau document. Ce code doit être bien formé,
cela signifie en particulier que toute balise ouverte dans une règle, doit être refermée dans cette même règle.
On y trouve donc des balises du nouveau format (dans la suite on produit du XHTML) mais aussi des instructions XSLT comme celles déjà
vues (xsl:value-of, xsl:variable, etc.) et éventuellement des appels à d'autres règles de transformation. Dans un langage de programmation
classique, ce bloc peut être identifié à une procédure ou un fonction.

LES PRINCIPES DE BASE

Dans l'utilisation la plus courante, l'élément xsl:template est muni d'un attribut match contenant une requête XPath : les noeuds concernés
par la transformation sont ceux qui vérifient cette requête.
<xsl:template match="diplome">
. . .
</xsl:template>

<xsl:template match="mesdiplomes">
. . .
</xsl:template>

Lorsque l'on décrit une règle de transformation, il faut garder à l'esprit que les requêtes XPath sont évaluées par rapport aux noeud courant.
Dans l'exemple suivant, nom et @année sont respectivement un sous élément et un attribut du diplôme que l'on est en train de transformer.
<xsl:template match="diplome">
<h2>
<xsl:value-of select="nom" />
</h2>
<p>
Obtenu en <xsl:value-of select="@année" />
</p>
</xsl:template>
Enfin, les appels se font à l'aide de l'instruction apply-templates et d'un attribut select contenant une requête XPath : celle-ci sélectionne des
noeuds pour lesquels on va chercher des règles de transformation à activer. Ci dessous, une feuille XSLT complète, qui commence par
traiter la racine.
<?xml version="1.0" ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:template match="/">
<html>
<body>
<xsl:apply-templates select="mesdiplomes" />
</body>
</html>
</xsl:template>

<xsl:template match="mesdiplomes">
<h1>Mon cursus</h1>
<xsl:apply-templates select="diplome" />
</xsl:template>

<xsl:template match="diplome">
<h2>
<xsl:value-of select="nom" />
</h2>
<p>
Obtenu en <xsl:value-of select="@année" />
</p>
</xsl:template>

</xsl:stylesheet>

Précisons que l'attribut select de apply-templates n'est pas obligatoire, il peut être omis. Dans ce cas, on va chercher à appliquer les règles
de transformation à chacun des noeuds fils (ce qui revient à poser select="node()" par défaut). Cela est particulièrement intéressant dans le
cas d'un contenu mixte :
<xsl:template match="paragraph">
<p>
<xsl:apply-templates />
</p>
</xsl:template>

<xsl:template match="important">
<em><xsl:value-of select="." /></em>
</xsl:template>

Lors de la transformation d'un paragraphe, les noeuds texte seront recopiés à l'identique, tandis que les éléments important seront traités
par la seconde règle.
Terminons avec des utilisations des instructions copy-of et copy. L'exemple suivant remplace les éléments paragraph en éléments p tandis
que le contenu, probablement mixte (texte et balises), est recopié à l'identique :
<xsl:template match="paragraph">
<p>
<xsl:copy-of select="*" />
</p>
</xsl:template>

La règle ci-dessous permet de récupérer l'ensemble d'un document XML en ajoutant un attribut à chacune des balises ouvertes :
<xsl:template match="*|/">
<xsl:copy>
<xsl:attribute name="lang">fr</xsl:attribute>
<xsl:apply-templates />
</xsl:copy>
</xsl:template>

LES MODES
Pour pouvoir traiter plusieurs fois mais de manière différente les mêmes éléments, il est possible de spécifier un mode, dans la règle de
transformation et dans son appel.
<?xml version="1.0" ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<html>
<body>
<h1>Mon cursus</h1>
<ul>
<xsl:apply-templates select="diplome" mode="sommaire" />
</ul>
<xsl:apply-templates select="diplome" mode="tout" />
</body>
</html>
</xsl:template>

<xsl:template match="diplome" mode="sommaire" >

<li>
<xsl:value-of select="nom" />
</li>
</xsl:template>

<xsl:template match="diplome" mode="tout">

<h2>
<xsl:value-of select="nom" />
</h2>
<p>
Obtenu en <xsl:value-of select="@année" />
</p>
</xsl:template>

</xsl:stylesheet>

NOTATIONS ET INSTRUCTIONS ALTERNATIVES

Une difficulté apparaît lorsque l'on faire apparaître une valeur récupérée par value-of comme valeur d'attribut dans le nouveau document.
Cela conduirait à un code XML mal formé :

<a href="<xsl:value-of select="lien/@url" />">

<xsl:value-of select="lien/texte" />
</a>

Dans ce cas, on préférera utiliser une notation entre accolades :

<a href="{lien/@url}">
<xsl:value-of select="lien/texte" />
</a>

Une autre possibilité est de recourir aux instructions xsl:element et xsl:attribute :

<xsl:element name="a">
<xsl:attribute name="href">
<xsl:value-of select="lien/@url" />
</xsl:attribute>
<xsl:value-of select="lien/texte" />
</xsl:element>

LES RÈGLES IMPLICITES ET LES PRIORITÉS

D'après la recommandation du W3C, les règles suivantes sont implicitement définies dans toute feuille de style :
<xsl:template match="*|/">
<xsl:apply-templates />
</xsl:template>

<xsl:template match="text()|@*">
<xsl:value-of select="." />
</xsl:template>

<xsl:template match="processing-instruction()|comment()" />

Autrement dit, la première transformation que nous avons considérée et qui était vide, produit déjà un résultat : le contenu textuel de chaque
élément. Il faut observer que le premier xsl:apply-template sélectionne tous les noeuds qui ne sont pas des attributs, par conséquent la
deuxième règle produira le contenu textuel des éléments mais pas celui des attributs puisque ceux-ci ne lui sont pas fournis.
Il apparaît maintenant que, pour un noeud sélectionné, plusieurs règles de transformation peuvent s'appliquer et il s'agit d'en choisir une.
Pour cela, chaque règle de transformation se voit attribuer une priorité, cela permet de déterminer quelle règle doit être appliquée lorsqu'un
noeud en active plusieurs.
L'attribution des priorités est la suivante et traduit l'intuition que la règle la plus spécifique (selon son match) est celle à appliquer :

• "element" et "@att" ont chacun une priorité valant 0 ;

• "node()", "*", "@*", et "processing-instruction()" ont chacun une priorité valant -0,5 ;
• +0,5 dans les autres cas.
Ainsi, les règles implicites ont la priorité la plus basse (-0,5) et perdront systématiquement contre des règles plus spécifiques.
En cas d'égalité, la recommandation du W3C laisse le choix aux processeurs XSLT de s'arrêter en signalant une erreur ou de choisir la
règle activable avec la priorité la plus haute et qui apparaît en dernier dans le fichier de transformation.
Enfin, indiquons qu'il est possible de définir soi-même la priorité d'une règle avec l'attribut priority de l'élément xsl:template.

LES RÈGLES NOMMÉES ET LEURS PARAMÈTRES

Il est possible d'activer une règle simplement en lui donnant un nom et en l'appellant à l'aide de l'instruction call-template :
<xsl:template name="signature">
<hr />
Fabien Torre. Copyright 2006.
</xsl:template>

<xsl:template select="...">
.
.
.
<xsl:call-template name="signature" />
.
.
.
</xsl:template>

On voit ici clairement le parallèle avec les procédures et fonctions des autres langages de programmation et l'étape suivante est
naturellement de munir les règles de transformation de paramètres. Cela se fait avec xsl:param pour la déclaration des paramètres dans la
règle et xsl:with-param pour leur instanciation au moment de l'appel :
<xsl:template name="faireunlien">
<xsl:param name="url" />
<xsl:param name="texte" />
<a href="{$url}">
<xsl:value-of select="$texte" />
</a>
</xsl:template>

<xsl:template select="personne" mode="lien">

<xsl:call-template name="faireunlien">
<xsl:with-param name="texte" select="concat(prénom,' ',nommarital,' ',nom)" />
<xsl:with-param name="url" select="@adresse" />
</xsl:call-template>
</xsl:template>

LES RÈGLES RÉCURSIVES

Terminons avec un cas particulier de l'appel de règle, celui où appelante et appelée ne sont qu'une seule et même règle. L'exemple suivant
montre une telle règle qui produit le chemin conduisant au noeud courant :
<xsl:template match="domaine">
<xsl:apply-templates select="parent::domaine" />
<li><a href="{@id}.html"><xsl:value-of select="@intitulé" /></a></li>
</xsl:template>

Naturellement, la récursivité est encore plus explicite avec une règle nommée.
<xsl:template name="ancêtres">
<xsl:param name="noeud" />
<xsl:if test="name($noeud)='domaine'">
 <xsl:call-template name="ancêtres">
<xsl:with-param name="noeud" select="$noeud/parent::*" />
</xsl:call-template>
<li><a href="{$noeud/@id}.html"><xsl:value-of select="$noeud/@intitulé" /></a></li>
</xsl:if>
</xsl:template>

LES STRUCTURES DE CONTRÔLE

LE TEST UNIQUE AVEC XSL:IF

Comme dans tout langage de programmation, on retrouve avec xsl:if la possibilité de faire un test et des actions en fonction du résultat. Ici,
on regarde si un attribut est renseigné et on produit du code seulement si c'est le cas :

<xsl:if test="@mail != ''">

<a href="{@mail}">m'écrire</a>
</xsl:if>

Dans la cas suivant, on récupère un ensemble de noeuds et on vérifie qu'il est non vide avant de le traiter :

<xsl:variable name="tout" select="mesdiplomes/diplome" />

<xsl:if test="count($tout)>0">
<h2>Mon cursus</h2>
<xsl:apply-templates select="$tout" />
</xsl:if>

Notons que cette instruction if ne dispose pas de else.

TESTS AVEC XSL:CHOOSE, XSL:WHEN ET XSL:OTHERWISE

Par contre, XSLT fournit l'instruction xsl:choose dans laquelle on peut multiplier les xsl:when (qui ressemblent à des xsl:if) et peut se
terminer par xsl:otherwise pour traiter les cas qui auraient échappé à tous les tests :

<xsl:choose>

<xsl:when test="starts-with(@href,'#')">
<a href="@href">lien interne</a>
</xsl:when>

<xsl:when test="starts-with(@href,'mailto:')">
<a href="@href">adresse mail</a>
</xsl:when>

<xsl:otherwise>
<a href="{@href}">lien web</a>
</xsl:otherwise>

</xsl:choose>

LA BOUCLE FOR-EACH
On a vu que les itérations étaient assurées par le mécanisme d'activation des règles. Celui-ci est suffisant et apparente XSLT à la famille
des langages fonctionnels. On trouve cependant en XSLT une boucle classique des langages impératifs :
<xsl:for-each select="mesdiplomes/diplome">
<h2>
<xsl:value-of select="nom" />
</h2>
<p>
Obtenu en <xsl:value-of select="@année" />
</p>
</xsl:for-each>
AUTRES POSSIBILITÉS DE XSLT

TRIER DES NOEUDS SÉLECTIONNÉS

Que ce soit pour un apply-templates ou une boucle for-each, il est possible d'ordonner les noeuds sélectionnés avant de les traiter.
<xsl:template match="/">
<html>
<body>
<h1>Mon cursus</h1>
<xsl:apply-templates select="diplome">
<xsl:sort select="@année" order="descending" />
</xsl:apply-templates>
</body>
</html>
</xsl:template>

<xsl:template match="/">
<html>
<body>
<h1>Mon cursus</h1>
<xsl:for-each select="diplome">
<xsl:sort select="@année" order="descending" />
<h2><xsl:value-of select="nom" /></h2>
<p>Obtenu en <xsl:value-of select="@année" /></p>
</xsl:for-each>
</body>
</html>
</xsl:template>

L'instruction xsl:sort doit obligatoirement être la première instruction dans le xsl:for-each.

PARAMÈTRES EXTERNES
On a parfois envie de passer des paramètres à la feuille XSLT pour conditionner la sortie, par exemple pour produire des documents
différents à partir du même document d'origine. Pour cela, on déclare les paramètres comme pour des templates paramétrés, sauf que
ceux-ci sont des fils directs de l'élément xsl:stylesheet :
<?xml version="1.0" ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:param name="cible" />
<xsl:param name="refpersonne" />
.
... ici des règles de transformation ...
.

Il reste à préciser les valeurs de ces paramètres au moment de la transformation. Avec xsltproc, cela se fait comme suit :
xsltproc --stringparam cible index doc2html.xsl doc.xml > index.html
xsltproc --stringparam cible unepersonne --stringparam refpersonne p12 doc2html.xsl doc.xml > doc.html

CONDITIONNER LA SORTIE
L'instruction xsl:output peut apparaître comme fils direct de l'élément xsl:stylesheet et permet de préciser la sortie voulue, en particulier à
travers les attributs suivants :

• method : indication de ce que l'on veut produire (xml, html ou text) ;

• doctype-public : la DTD respectée par le document final (le processeur ajoutera de lui même la ligne DOCTYPE qui convient) ;
• omit-xml-declaration : comme son nom l'indique ;
• indent : indenter ou pas le document produit ;
• encoding : le codage à utiliser pour la sortie ;
• media-type : le type MIME du document produit.
Un exemple :
<?xml version="1.0" ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:output method="xml" encoding="iso-8859-1" indent="yes"

doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN" />
.
.
.

PRODUIRE DU TEXTE
Par exemple pour contraindre deux valeurs extraites à être séparées par un espace :
<xsl:value-of select="$prénom" />
<xsl:text> </xsl:text>
<xsl:value-of select="$nom" />
Cours sur la programmation SAX
Présentation de l'API SAX pour le parcours de documents XML.

Principes
SAX permet un parcours générique d'un document XML, c'est-à-dire qu'il est indépendant du format.
SAX signifie Simple API for XML et est donc disponible dans différents langages de programmation, avec la même interface.
Le principe de SAX est simple : pour chaque ouverture ou fermeture d'élément, chaque feuille texte, etc. un événement ( event) est
déclenché. Le développeur doit simplement anticiper ces événements et leurs associer les instructions à effectuer lorsqu'ils se
déclencheront.
SAX parcourt le document XML dans l'ordre du document et active du code associé selon les événements qui se déclenchent. De plus,
contrairement à d'autres modèles de traitement XML (DOM, XPath et XSLT), SAX ne charge pas le document en mémoire mais se contente
de le parcourir. SAX est donc particulièrement adapté pour réaliser des traitements XML simples, en séquence, éventuellement sur des
fichiers XML très louds.

Écrire un parser SAX

Le programme principal débute par la création du parser et la fourniture du fichier à traiter.
Pour définir les actions effectuées par le parser, SAX permet de spécifier le comportement à avoir lorsque certains événements se
déclenchent :

•startDocument: méthode appelée au début du document.

•endDocument: méthode appelée à la fin du document.
•startElement: méthode appelée à chaque fois qu'une balise ouvrante est rencontrée.
•endElement: méthode appelée à chaque fois qu'une balise fermante est rencontrée.
•characters: méthode appelée à chaque fois qu'une feuille textuelle est rencontrée.
Cours sur la programmation DOM en Python
Présentation de DOM.

Introduction
DOM, pour Document Object Model, vise à fournir un modèle d'un document semi-structuré, autrement dit d'un document XML. Il s'agit en
particulier de définir des méthodes d'accès et de modification opérant sur un tel document.
DOM est défini par des recommandations du W3C, trois niveaux ont aujourd'hui été définis. Certaines parties de ces recommandations sont
dédiées au traitement de documents XHTML ; nous nous concentrons ici sur le noyau de DOM fournissant des méthodes valables pour tout
document XML.
En pratique, DOM permet de charger un document XML tout entier en mémoire et s'oppose sur ce point à SAX (qui permet de traiter un
document XML en une passe, sans occupation mémoire). Au minimum, DOM utilise une zone mémoire de la fichier XML lu ; dans les faits,
c'est souvent plus et cela pour se préparer à répondre de manière efficace à des interrogations complexes.
En Python, le programme minimal qui charge un document XML sous forme de DOM est le suivant :
from xml.dom.minidom import parse
import sys

xmlfilename = sys.argv[1]
dom = parse(xmlfilename)

Le modèle DOM reflète la nature arborescente des documents XML : il nous permet d'accéder à la racine ou à des noeuds quelconques,
d'obtenir les fils d'un noeud précis, ou encore ses frères. L'implémentation réelle du modèle présent en mémoire après le chargement du
document XML est cachée dans un objet et peut varier avec le langage de programmation utilisé. Par contre les méthodes d'accès et de
modification de l'arbre DOM sont standardisées par le W3C et sont donc les mêmes d'un langage à l'autre.
Pour terminer, précisons que chaque information présente dans le document d'origine se retrouve en mémoire comme un noeud de l'arbre
DOM : les éléments, les attributs, les textes, les commentaires, etc. sont autant de noeuds accessibles dans l'arbre DOM.

Les noeuds du DOM

Nous venons de percevoir le rôle central des noeuds dans DOM, il convient de savoir les manipuler.

Informations sur un noeud

Étant donné un noeud de l'arbre DOM, nous pouvons obtenir son nom, sa valeur et son type.

nodeType 1 (élément) 2 (attribut) 3 (texte)

le nom de la
nodeName le nom de l'attribut #text
balise
nodeValu la valeur de le texte du
non définie
e l'attribut noeud

Obtenir un noeud
À partir de l'objet DOM, il est possible d'obtenir :

•l'élément racine du document XML à l'aide de documentElement ;

•le noeud élément portant un nom particulier à l'aide de getElementsByTagName.
Si l'on possède déjà un noeud, il est alors possible d'en obtenir d'autres qui lui sont liés dans le document d'origine :

•childNodes : la liste des noeuds fils ;

•parentNode : le père ;
•firstChild : le premier fils ;
•lastChild : le dernier fils ;
•nextSibling : le frère droit ;
•previousSibling : le frère gauche.
À noter que le noeud demandé peut ne pas exister : la racine n'a pas de père, un fils ainé n'a pas de frère gauche, etc. Dans ces cas, en
Python, on obtient la valeur None. Si un noeud n'a pas de fils, childNodes renvoie logiquement une liste vide.
Enfin les attributs d'un élément sont accessibles grâce à la méthode attributes (qui fournit donc un ensemble de noeuds de type 2).
Premiers exemples de programmes Python & DOM

Accéder à un fils textuel

from xml.dom.minidom import parse
import sys

xmlfilename = sys.argv[1]
dom = parse(xmlfilename)

titres = dom.getElementsByTagName("titre")
premier = titres[0]
texte = premier.childNodes[0]

print texte.nodeValue

Obtenir des attributs

from xml.dom.minidom import parse
import sys

xmlfilename = sys.argv[1]
dom = parse(xmlfilename)

sites = dom.getElementsByTagName('site')

for site in sites:

attrs = site.attributes
urlnode = attrs['url']
print urlnode.nodeValue

Lire un fichier plat

from xml.dom.minidom import parse
import sys

xmlfilename = sys.argv[1]
dom = parse(xmlfilename)

racine = dom.documentElement;
fils = racine.childNodes

print 'racine=',racine.nodeName

for f in fils:
if f.nodeType==1:
print f.nodeName,'=',f.childNodes[0].nodeValue

Modifier le DOM

Un nouveau DOM
impl = getDOMImplementation()
newdoc = impl.createDocument(None,"laracine",None)
top_element = newdoc.documentElement

Définir un noeud ou un attribut

new_element = newdoc.createElement('nomelement')
new_element.setAttribute('nomattribut','valeurattribut')

copie = noeud.cloneNode(True)
copie.removeAttribute('nomattributasupprimer')

Placer un noeud dans la structure

top_element.appendChild(new_element)
Produire du XML
produire du XML à partir d'un noeud n : n.toxml.
PrettyPrint(newdoc)

Pour aller plus loin...

•Recommandations DOM du W3C ;

•tutoriel du W3 Schools ;
•récapitulatif synthétique de DOM par BENJAMIN HABEGGER (format PDF).