Cours XML

Département Hypermédia
XML
(eXtensible Markup Language)
Cours préparé et présenté par :
Abderrazak MKADMI
amkadmi@gmail.com
© 2004-2012
TABLE DES MATIÈRES
INTRODUCTION GENERALE 5
1. OBJECTIF ET DEFINITIONS 5
1.1. DEFINITION 5
1.2. ORIGINE 6
1.3. HISTORIQUE 7
2. LES LIMITES DE HTML 7
3. LES APPORTS DE XML 8
3.1. EXTENSIBILITE ET STRUCTURE : 8
3.2. STRUCTURE TYPE : MODULARISATION ET REUTILISATION 8
CHAPITRE 1 : LES DOCUMENTS XML 10
1. LES REGLES D'ECRITURE 10

2. LA STRUCTURE DU DOCUMENT 10
1. LE PROLOGUE 11
2.2. L'ARBRE D'ELEMENTS 13
3. LES ATTRIBUTS, LES ENTITES, LES SECTIONS LITTERALES 14
3.1. PRESENTATION 14
3.2. LES ATTRIBUTS 15
3-3 LES ENTITES PARAMETRIQUES 16
3-4 LES ENTITES DE CARACTERES 17
3.5 LES ENTITES INTERNES 17
3.6 LES SECTIONS LITTERALES 17
3.7 LES ENTITES EXTERNES 17
3.8 LES ENTITES NON-XML 18
3.9 RECAPITULATIF SUR LES ENTITES 19
4. CONSEIL D'ECRITURE 19
5. DOCUMENT BIEN FORME ET DOCUMENT VALIDE: LA DTD 20
5.1 REFERENCE A UNE DTD DANS UN DOCUMENT XML 20
5.2 DECLARATION INTERNE ET EXTERNE DE LA DTD 22
6 LES DIFFERENTS FORMATS DE DECLARATIONS 22
6.1. LES ELEMENTS 22
6.2 EXEMPLE RECAPITULATIF 23
6.3 LA LISTE D’ATTRIBUTS 24
6.4 LES ENTITES PARAMETRES 25
6.5 LES SECTIONS INTERNES ET EXTERNES 25
7. LES DOMAINES DE NOMS (NAMESPACES) 26
CHAPITRE 2 : XML SCHEMA 27
1. INTRODUCTION AUX SCHEMAS XML (XML SCHEMA) 27

2. LA DECLARATION D'UN SCHEMA 31
2.1. LES ELEMENTS 31
2.2 LES ATTRIBUTS 32
3 LES TYPES SIMPLES 33
3.1 LES TYPES DE BASE INTEGRES 33
3.2 LES LISTES 33
3.3 LES UNIONS 34
4 LES TYPES COMPLEXES 34
4.1. LE CONNECTEUR DE SEQUENCE 34
4.2. LE CONNECTEUR DE CHOIX 35
4.3. L'ELEMENT ALL 35
4.4 LES CONTRAINTES D’OCCURRENCES SUR ELEMENT 35
5 LES TYPES DE CONTENUS 36
6. LES DERIVATIONS DE TYPES 37
6.1. DERIVATION PAR RESTRICTION 37
6.2 DERIVATION PAR EXTENSION 38
6.3. NOTIONS COMPLEMENTAIRES 39
7. LES ESPACES DE NOMS 40
8 REFERENCEMENT D'UN SCHEMA 40
CHAPITRE 3 : XPATH ET XLL 41
1. INTRODUCTION 41
2. XPATH: LE LANGAGE DE NAVIGATION 41
2.1. LA SELECTION D'OBJETS 41
2.2 LES AXES NODAUX 42
3. LES LIENS XML: XLINK ET XPOINTER 43
3.1 LES LIENS XLINK 43
3.2. LES POINTEURS XML: XPOINTER 46
CHAPITRE 4 : LES FEUILLES DE STYLE 47
1. LES FEUILLES DE STYLES: XSL ET CSS 47

2. XSL 47
2.1. PRESENTATION 47
2.2. XSL ET LE W3C 47
3. XSLT: LA TRANSFORMATION 48
3.1. DOCUMENT REGULIER VERSUS DOCUMENT NON REGULIER 48
3.2. LE DOCUMENT XSLT ET SON REFERENCEMENT 53
3.3. LES REGLES DE TRANSFORMATION 53
3.4. SELECTION DE REGLE ET PARCOURS DE L'ARBRE 54
3.5. LA GENERATION DE NOEUDS 55
3.6 FUSION DE FEUILLES DE STYLES 55
3.7. FORMAT DE SORTIE 55
3-8 RECAPITULATION (PARTIELLE) DES ELEMENTS DE BASE DE LA SYNTAXE XSLT 56
4. XSL-FO: LE FORMATAGE 58
4.1 XSL-FO PAR L’EXEMPLE 58
CHAPITRE 5 : LE MODELE DE DOCUMENT 60
1. INTRODUCTION 60
2. LE DOM ET LE W3C 61
3. LA PROGRAMMATION DU DOM 61
4. INTERFACE SAX 62
5. DOM VERSUS SAX 64
CHAPITRE 6 : FORMULAIRES XML : XFORMS 65

1- XFORMS VS FORMULAIES HTML 65
2- XFORMS : COMPOSANTS 65
2-1 MODELE DE DONNEES 65
2-2 INTERFACE UTILISATEUR 67
2-3 LIENS ENTRE INTERFACE ET MODELE 68
CHPITRE 7 : XML ET LES BASES DE DONNEES 70
1- INTRODUCTION 70
2- CORRESPONDANCES ENTRE SGBDR ET XML 71
2-1 SGBDR 71
2-2 LANGAGE SQL 72
2-3 XML VS SGBDR : STRUCTURE 72
2-4 XML VS SGBDR : RELATIONS 73
3- EXPORTATION DES BASES DE DONNEES RELATIONNELLES VERS XML 76
4- EXPORTATION DES DONNEES XML VERS UNE BASE DE DONNEES RELATIONNELLE 77
5- LE LANGAGE DE REQUETE XML : XQUERY 78
5-1 PRESENTATION ET OBJECTIF 78
5-2 LES BASES DE XQUERY 79
CHAPITRE 8 : CHAMPS D’APPLICATION ET STANDARDS XML 83
1. CHAMP D'APPLICATIONS 83
4.1 COMMERCE ELECTRONIQUE ET ECHANGE DE DONNEES INFORMATISEES (EDI) 83
1.2 GESTION ELECTRONIQUE DE DOCUMENTS (GED) : 83
1.3 INTEROPERABILITE DE SYSTEMES D'INFORMATIONS HETEROGENES 83
1.4 PERSONNALISATION DE LA RELATION CLIENT (CRM): 83
2. LES STANDARDS 83
2.1. INTRODUCTION 83
2.2. MATHML (MATHERNATICAL MARKUP LANGUAGE) 84
2.3. SVG (SCALABLE VERCTOR GRAPHICS) 85
2.4. SMIL (SYNCHRONIZED MULTIMEDIA INTEGRATION LANGAGE) 86
2.5. RDF (RESOURCE DESCRIPTION FRARNEWORK) 87
CONCLUSION 89
BIBLIOGRAPHIE 90
LIVRES 90
SITES INTERNET 90
OUTILS 90
SITE OFFRANT DES DTDS STANDARDS 91
SITES DE LOGICIELS EN LIGNE 91
GLOSSAIRE 92
Introduction générale
INTRODUCTION GENERALE
XML (eXtensible Markup Language) est un nouveau langage normalisé de balisage
numérique, permettant de décrire la structure hiérarchique d'un document. Non propriétaire et
indépendant des plate-formes et des systèmes d'exploitation, XML est une solution
incontournable pour la représentation et l'échange de documents sur Internet. Il offre de
nombreuses fonctionnalités en matière de publication électronique, d'e-commerce et de
personnalisation des transactions.
Ainsi, XML est devenu le langage universel d’échange de données informatiques, qu’il
s’agisse de les stocker, de les échanger, de les traiter ou de les afficher.
« L’apparition de XML a été prédominante. Grâce à lui, il est possible de séparer les
données de leur structure. Cela permet notamment de stocker ces informations sur le web de
façon qu’elles soient exploitées automatiquement par différents serveurs et de présenter le
résultat final, sous forme de service web, par exemple, à l’utilisateur (...). L’avenir appartient
aux entreprises capables d’exploiter les données et de les visualiser. 1»
Je vais essayer, à travers ce cours, de présenter sommairement ce méta-langage, ainsi que
quelques langages dérivés, tout en décrivant les techniques qui permettent de présenter un
document XML sur un navigateur, à savoir les feuilles de style. J’essaierai aussi de présenter
les DTD qui permettent de valider un document par rapport à un méta-modèle, tout en faisant
la différence entre les DTD et les schémas XML qui viennent répondre à certaines
insuffisances des premières. Plusieurs exemples seront présentés pour faciliter la
compréhension.
Le cours est composé donc d’une introduction générale et de 7 chapitres complétés par une
conclusion, une bibliographie et un glossaire. Ces chapitres sont :
1- Les documents XML : structure et DTDs
2- Les schémas XML
3- La navigation XPath et les liens XLL
4- Les feuilles de style
5- Le modèle de document : DOM & SAX
6- Les formulaires XML (XForms)
7- XML et les bases de données
1. OBJECTIF ET DEFINITIONS
1.1. DEFINITION
XML peut être considéré comme une généralisation de HTML où, au lieu d'avoir un jeu de
balises prédéfinies ayant une signification prédéfinie, l'auteur peut "inventer" à volonté ses
propres balises.
Le but de XML est de faciliter le traitement automatisé de documents et de données. L'idée
est de pouvoir structurer les informations de telle manière qu'elles puissent être à la fois lues
par des personnes sur le web et traitées par des applications qui exploiteront de manière
automatisée les informations en question.
L'objectif majeur de XML donc est d'étendre les fonctionnalités de HTML afin de faciliter les
échanges de documents sur le WEB. Pour cela les acteurs du W3C (World Wide Web
1
ABRAMATIC, Jean-François (W3C). - Entretien à Décision Micro, le 6 juin 2001
Abderrazak MKADMI Cours XML 5

Consortium) souhaitaient définir un langage bénéficiant des principales fonctionnalités de

SGML (Standard Generalized Markup Language) tout en étant plus simple à apprendre et à
utiliser que ce dernier.
Ces évolutions comprennent :
• la définition libre de nouvelles balises et de nouveaux attributs,
• le support de structure complexe de documents,
• la vérification de la structure d'un document par rapport à une grammaire type définie
dans un document appelé DTD (Document Type Definition),
• la séparation entre le contenu (document XML) et la mise en page (feuille de style
CSS ou XSL).
XML peut donc être défini comme étant un langage de description et d'échanges de
données structurés.
Exemple de document XML
Description XML des informations carte de visite
<cartes>
<personne>
<nom>Mkadmi</nom>
<prenom>Abderrazak</prenom>
<bureau>
<laboratoire>PARAGRAPHE</laboratoire>
<adresse>
<rue>2, rue de la Liberté</rue>
<code postal>93526</code postal>
<ville>SAINT-DENIS</ville>
</adresse>
<téléphone>(33) 1 49 40 67 89</téléphone>
</bureau>
</personne>
</cartes>
1.2. ORIGINE
Les objectifs étaient donc
d'étendre les fonctionnalités du langage HTML qui est limité,
d'offrir un standard équivalent à SGML auxquels les acteurs du W3C reprochaient les
éléments suivants :
- il est trop complexe pour être implémenté dans des navigateurs,
- il impose que tout document soit conforme à une structure type spécifiée et
validée,
- il ne possède pas de mécanismes de liens évolués.
Mais les concepts de SGML (séparation entre contenu et forme, garantie d'une plus grande
pérennité, indépendance vis à vis des évolutions technologiques et des médias ; écran,
imprimantes, ...) ont pu être validés par de nombreux industriels en particulier sur la gestion
de documentation.
Les objectifs qui ont guidé le groupe de travail XML :
- Utilisable sur l'infrastructure Internet

- Supporter une grande variété d'applications

- Être compatible avec SGML
- Facile à traiter un document XML par programme
- Fournir un balisage compréhensible par l'homme
- La concision dans le balisage n'est pas importante
- Rendre l'écriture d'un document facile
- Livrer une spécification formelle et concise (42 pages)
- Rédiger la spécification rapidement (18 mois)
1.3. HISTORIQUE
1996: groupe de travail au sein du W3C
1998 : publication de recommandations pour la version 1.0 de XML
XML est une recommandation du W3C en date du 10 Février 1998, référencée à :
http://www.w3.org/TR/1998/REC-xml-19980210
Quelques standards gérés par le W3C :
• XSL (eXtensible Stylesheet Language) : XSLT + XSLFO : Règles de transformation et de
présentation de documents XML,
• XLL (eXtensible Linking Language Xlink + Xpointer : Liaison et adressage entre
documents,
• XPath (utilisé pour XSLT et XPointer) : Expression de la navigation dans des documents
XML,
• DOM (Document Object Model) : API d'accès et de manipulation de documents XML sous
forme d'objets,
• XML Schema : Définition de la structure des documents XML en XML,
• XQL (eXtensible Query Language) : Requêtes pour la recherche d'information dans un arbre
XML.
2. LES LIMITES DE HTML

En fait HTML est très bien adapté à la création de sites simples. Son apprentissage est aisé et
les sites ainsi développés sont simples à manipuler. Cependant l'évolution des besoins a fait
évoluer les simples documents hypertextes vers des documents dont le contenu est généré
dynamiquement à partir de bases de données. HTML a alors très vite montré ses limites
Un balisage prédéfini dans la norme,
Beaucoup de balises de description de formes (br, b, center, etc.) et peu de balises à
caractères sémantiques (title, address, dl, etc.),
Une dépendance très forte du contenu et de la forme : Les documents HTML se
voulaient indépendant de toute problématique technologique. Les utilisateurs ont
aujourd'hui besoin d'un langage permettant un affichage utilisant au mieux les
capacités des navigateurs actuels sans que les documents créés ne soient pour autant
liés à leurs évolutions.
Une évolution en 1997 avec l'apparition des CSS (Cascading Style Sheets) et en 1998
avec HTML 4.0 a permis de repousser cette limite mais cela ne repose que sur le bon
vouloir des développeurs. Rien n'empêche de continuer à utiliser HTML de la même
façon qu'auparavant.

Une interopérabilité limitée : on ne sait pas extraire une information particulière d'un
document HTML, ce qui limite l'échange d'informations avec d'autres applications
ainsi que les possibilités de recherche sémantique sur le contenu d'un site ou d'un
document.
Une gestion des liens trop simples : Deux types de liens dans HTML : le lien "Link"
(lien vers un autre élément, par exemple une feuille de style) et le lien "a" (lien vers
une autre page). Dans la pratique le "l" n'est presque pas utilisé mis à part pour la
gestion des feuilles de style CSS. Aujourd'hui rien n'empêche d'utiliser un lien "a" là
où un lien "link" aurait été plus adapté.
Des recherches lourdes et des réponses très nombreuses, rendant leurs traitements
difficiles car il n'y a pas de notion de sémantique dans l'information recherchée.
Aujourd'hui la recherche des ouvrages d'un auteur particulier se fait en recherchant sur
une chaîne de caractères qui peut apparaître sous n'importe quelle forme sur les sites.
Les réponses pourront donc inclure les ouvrages recherchés mais aussi toutes
informations faisant référence à l'auteur. XML permettra de faire la recherche en
spécifiant des mots clés de recherche du type AUTEUR=" xxxxx ". Ce qui limitera les
réponses ramenées aux seules pages contenant une information de ce type.
3. LES APPORTS DE XML
3.1. EXTENSIBILITE ET STRUCTURE :

Dans XML, il est possible de définir ses propres balises. Ce qui permet d'améliorer la lisibilité
et les possibilités de traitement.
Exemple :
<date>15 novembre 2002</date>
<date>
<annee>2002</annee>
<mois>11</moi>
<jour>15</jour>
</date>
Ce découpage permettra d'afficher la date sous différents formats sans avoir à effectuer de
traitement complexe. Par contre si l'on désire pouvoir systématiser certains traitements sur les
dates et les rendre opérationnelles sur l'ensemble des navigateurs, cela suppose de définir une
norme sur le format de la date.
Exemple
<date format ="ISO-8601">2000-11-02</date>
3.2. STRUCTURE TYPE : MODULARISATION ET REUTILISATION

La définition de nouvelles balises permettra de structurer l'information sous une forme ou une
autre afin de permettre le traitement et l'échange de données de façon beaucoup plus
importante qu'avec HTML.
Les domaines du commerce électronique, des échanges de données informatisés (EDI), les
transactions financières sont directement concernés par ces nouvelles fonctionnalités.

Cependant, il est important qu'il n'y ait pas d'ambiguïté sur la structure et la sémantique des
différentes données échangées entre des particuliers ou des entreprises. C'est pourquoi XML
propose des structures types de documents (les DTD).
En outre, ces dernières ouvre la porte vers des outils (API ou logiciel) permettant de
manipuler ces différentes structures.

Chapitre 1 : Les documents XML
CHAPITRE 1 : LES DOCUMENTS XML
1. LES REGLES D'ECRITURE

Il faut noter que la casse des caractères dans un document XML est importante (la
casse est discriminante), alors que de façon générale les espaces, tabulations et
retours de chariots ne le sont pas.
Comme en HTML, les espaces, tabulations, retours et sauts à la ligne sont considérés
comme des séparateurs et sont générés par le parseur sous forme d'espace simple.
Il est possible d'insérer des commentaires dans les documents XML, en utilisant la
syntaxe suivante:

un commentaire s'écrit entre <!- - et - - > et ne peut contenir le caractère tiret'-'.
Les instructions pour les applications sont comprises entre <? et ?> Exemple : <?
XXXXXX ?>
Un nom (ou Token) commence par une lettre et peut contenir : Lettre, Chiffre, (point),
(tiret), '_' (tiret souligné), ':' (deux points)
Tous les mots commençant par XML ou xml sont réservés.
2. LA STRUCTURE DU DOCUMENT
Il existe deux types de documents XML : le document bien formé et le document valide.
Un document bien formé est un document respectant la syntaxe XML.
Un document valide est un document bien formé qui respecte une structure type définie dans
une DTD.
Le document XML se compose de :
• un prologue (facultatif mais conseillé),
• un arbre d'éléments qui constitue le contenu du document,
• des commentaires et des instructions de traitement.
Déclaration XML
<?xml version= " 1.0 " encoding= " ISO-8859-1 " standalone = " yes " ?>
<?xml-stylesheet type = " text/xsl " href= " test.xsl " ?>
Instruction de traitement
< !DOCTYPE formation [
< !ENTITY organisme " EDIFRANCE ">
PROLOGUE
< !ELEMENT formation (date, titre, societe, programme) > Partie

< !ELEMENT date ( #PCDATA) > déclarative
< !ELEMENT titre ( #PCDATA) >
< !ELEMENT societe ( #PCDATA) >
< !ELEMENT programme ( chapitre+) >
< !ELEMENT chapitre ( #PCDATA) >
< !ATTLIST chapitre numero NMTOKEN #REQUIRED >
]>
<formation>
<date/>
<titre>
OCUMENT
< ![CDATA[<XML> - Développement ]]>

Abderrazak MKADMI
</titre> Cours XML 10
<societe>Organisée par &organisme ;</societe>
< !- -Programme du séminaire - ->
1. LE PROLOGUE
Le prologue des documents XML joue trois rôles importants:
1. Préciser qu'il s'agit d'un document XML

2. Identifier le jeu de caractères utilisé
3. Identifier la grammaire (DTD) utilisée
Les trois éléments sont facultatifs, mais il est en général préférable d'include la déclaration
XML qui contient les deux premiers éléments d'information.
Si aucun jeu de caractères n'est spécifié, une application XML doit supposer qu'il s'agit du jeu
de caractères Unicode, encodé en UTF-8 ou en UTF-16.
Si aucune DTD n'est identifiée, le document est considéré bien formé. Si une DTD est
spécifiée, le document est alors valide (s'il respecte les règles dictées dans la DTD bien sûr).
Le prologue peut contenir donc :

une déclaration XML,
des instructions de traitement,

une déclaration de DTD.

2.1.1. La déclaration XML
. Exemple
< ?xml version= "1.0 " encoding = "ISO-8859-1" standalone = "yes" ?>
Dans cet exemple, il y a trois parties :
L'identification du document XML est nécessairement au début du document et a la
forme suivante :
<?xml version="1.0"?> : Version du langage utilisé
L'encodage, s'il est spécifié, se retrouve dans l'instruction de traitement qui identifie le
document XML:
<?xml version="1.0" encoding="ISO-8859-1"?>
Dans cet exemple, il s'agit d'un document XML dont le jeu de caractères est l'ISO-Latin
1 (norme ISO 8859-1), et donc pas l'Unicode. Dans l'exemple précédent, le jeu de
caractères était l'Unicode, avec encodage UTF-8 ou UTF-16, soit la valeur par défaut
standalone='Yes' veut dire que toutes les recherches de déclarations se feront

uniquement dans le document.
Un document XML commence donc généralement par la balise <?xml version="1.0" ?>
qui peut avoir quelques attributs supplémentaires:
Nom de
valeurs possibles explications
l'attribut
(obligatoire) indique le numéro de
version 1.0 version du standard auquel le document
se conforme.
UTF-8, UTF-16, ISO-10646-
UCS-2, ISO-10646-UCS-4, ISO- nom de l'encodage de caractères
encoding
8859-1 à ISO-8859-9, ISO-2022- employé dans le fichier
JP, Shift_JIS, EUC-JP
si le document XML fait référence à
une DTD ou à des entités définies dans
standalone yes, no
un autre fichier, il faut mettre "no".
Sinon, on utilise "yes".
L'encodage est important car il permet au parseur de savoir comment interpréter le
document. Sans cette information, il y a une erreur provoquée lors de la rencontre
d’un caractère accentué.
2.1.2. Les instructions de traitement
<?nom param1 param2 ... ?> le nom est une application ou une fonction que l'on appelle en
lui passant des paramètres.
Les instructions de traitement sont surtout utilisées par les applications qui génèrent du code
XML comme les éditeurs XML ou par les applications qui interprètent le code XML comme
les navigateurs.
…

2.1.3. Déclaration de type de document (DTD)

La DTD peut être référencée de la façon suivante:
<!DOCTYPE racine PUBLIC "identificateur public" "uri de la
DTD">
Ici, "racine" identifie l'élément qui contient tous les autres dans le document, la mention
PUBLIC et la chaîne de caractères qui suit, optionnelles, précise un identificateur public pour
cette DTD, et enfin la chaîne de caractères qui la suit, obligatoire, précise la localisation de la
DTD à l'aide d'une URI.
Très souvent, un appel à une DTD sera de la forme suivante:
<!DOCTYPE racine SYSTEM "racine.dtd">
La déclration d’une DTD de cette façon signifie que la DTD est dans un fichier nommé
"racine.dtd" et qui se situe dans le même répertoire que le document.
Soulignons également qu'il est possible d'inclure la DTD à l'intérieur du document lui-même,
de la façon suivante:
<!DOCTYPE racine [
<!ELEMENT racine EMPTY>
]>
Dans cet exemple, la DTD est incluse dans le document (fournie entre crochets). Il s'agit d'une
pratique assez rare, mais cette technique est aussi utilisée pour déclarer des entités.
2.2. L'ARBRE D'ELEMENTS

Les éléments sont les objets les plus importants des documents XML. En effet,
fondamentalement, les documents XML sont des hiérarchies strictes d'éléments. Ainsi, il
existe toujours un (et un seul) élément supérieur qui contient tous les autres. De plus, un
élément peut contenir d'autres éléménts ou du texte (un type particulier d'élément), et se situe
à l'intérieur d'un seul élément.
Chaque élément est défini de la façon suivante :
<nom> contenu de l'élément </nom>
Le nom indiqué par les balises d'ouverture et de clôture
doit commencer par une lettre,
peut comporter des chiffres, des lettres, les caractères moins (-), tiret souligné ('_'),
point ('.')
la casse est discriminante
le nom ne peut commencer par XML que ce soit en minuscule, majuscule ou en
combinaison des deux.
L'arbre d'éléments décrit la structure hiérarchique d'un élément. Les éléments les plus fins
sont dits éléments terminaux.
2-2-1 Élément racine :
Un élément racine est le premier élément déclaré dans un document XML, qui contient tous
les autres éléments. Dans notre exemple, l'élément PRODUIT est l'élément racine de notre
document.

Exemple
< ?xml version='1.0' ?>
<PRODUIT>
<TOPIC>
<TITLE>Création d’un répertoire de schémas XML</TITLE>
<AUTHOR>Abderrazak MKADMI</AUTHOR>
<PUBLISHER>EDIFRANCE</PUBLISHER>
</TOPIC>
<TOPIC>
<TITLE>Les bases de données relationnelles</TITLE>
<AUTHOR>Imad Saleh</AUTHOR>
<PUBLISHER>Eyrolles</PUBLISHER>
</TOPIC>
</PRODUIT>
Comme nous avons vu, un seul élément racine est autorisé par document.
L’exemple ci-dessous par exemple est incorrect car il comporte plusieurs éléments père :
< ?xml version='1.0' ?>
<TOPIC>
<TITLE>Création d’un répertoire de schémas XML</TITLE>
<AUTHOR>Abderrazak MKADMI</AUTHOR>
<PUBLISHER>EDIFRANCE</PUBLISHER> Syntaxe
</TOPIC> incorrecte
<TOPIC>
<TITLE>Les bases de données relationnelles</TITLE>
<AUTHOR>Imad Saleh</AUTHOR>
<PUBLISHER>Eyrolles</PUBLISHER>
</TOPIC>
2.2.2 Élément vide
Un élément vide est un élément dont le contenu entre la balise d'ouverture et la balise de
fermeture est vide (<baliseDOuverture suiteDAttributs></baliseDOuverture
suiteDAttributs>); il peut être abrégé <baliseDOuverture suiteDAttributs /> (il ne faut pas
croire qu'un élément vide ne contient pas d'information; les informations qu'il contient sont
dans ses attributs).
Un élément vide s’écrit sous la forme suivante :
<exemple></exemple> ou <exemple/>
3. LES ATTRIBUTS, LES ENTITES, LES SECTIONS LITTERALES
3.1. PRESENTATION
L'arbre d'éléments XML peut contenir différents objets :
• Des attributs : les éléments peuvent contenir des informations complémentaires
stockées sous forme d'association nom=valeur. Ces informations permettront
d'effectuer des traitements spécifiques (par des applications, des navigateurs ou des
feuilles de style XSL) en utilisant des critères distincts des données affichées. Cela
permet par exemple de gérer des liens.

Des entités : une entité est un objet disposant d'un nom et d'un contenu. Cet objet peut
être interne (une chaîne de caractère), externe en format XML (autre fichier XML) ou
non (fichier WORD par exemple). Une entité pourra être référencée sur un attribut.
Des sections littérales : une section littérale est une chaîne de caractères non
interprétée par le parseur XML. Cela permet ainsi d'inclure des caractères spéciaux.
Par exemple pour inclure des exemples de syntaxes XML dans une page XML.
Des données : toutes chaînes de caractères ne répondant pas aux éléments ci-dessus.
3.2. LES ATTRIBUTS

Les attributs sont toujours associés aux éléments. Ils viennent en quelque sorte les qualifier.
Ils sont toujours spécifiés dans la balise d'ouverture de l'élément.
3-2-1 utilisation
<exemple attribut= 'valeur'>
Le nom d'attribut respecte les mêmes règles que les noms d'éléments. La valeur est exprimée
en des quotes ou des apostrophes et ne peut contenir les caractères ^, % et &.
Exemple :
<?xml version ="1.0" ?>
<article>
<editeur nom ="EYROLLES">
<ed-adresse>
<rue>1, rue Thénard</rue>
<cp>75005</cp>
<ville>Paris</ville>
</ed-adresse>
</editeur>
<editeur=nom="First Interactive">
<ed-adresse>
<rue>13, rue Buffon</rue>
cp>75005</cp>
<ville>Paris</ville>
</ed-adresse>
</editeur>
<topic>
<title>XML : le guide de l’utilisateur</title>
<author>Elliotte Rusty Harold</author>
<editeur nom="EYROLLES"></editeur>
</topic>
<topic>
<title>Moteurs de recherche pour le web</title>
<author>Alfred, Emily Glossbrenner</author>
<editeur nom="First Interactive"></editeur>
</topic>
</article>
Dans l'exemple ci-dessus, l'utilisation des attributs permet de simplifier l'écriture puisqu'elle
n'oblige pas à réécrire les informations complètes sur un éditeur lorsque plusieurs ouvrages y
font référence. Il pourrait être, cependant, nécessaire d'effectuer un traitement supplémentaire
(lors des impressions par exemple) afin de remplacer l'attribut par les informations
correspondantes.
3.2.2. Utilisation des caractères spéciaux
Pour inclure des caractères spéciaux dans les données, il est nécessaire d'utiliser l'une des
écritures suivantes :

• &# suivi du numéro décimal du caractère dans les pages UNICODE

• &#x suivi du numéro hexadécimal du caractère dans les pages UNICODE.
Exemple :
&#38 et &#x26 sont équivalents à &
&#x2200 est équivalent à ∀
En outre il existe aussi des entités prédéfinies pour les caractères utilisés par XML:
&gt pour >,
&lt pour <,
&amp pour &
&apos pour ',
&quot pour ''
3.2.4. Les attributs prédéfinis
Il existe un certain nombre d'attributs prédéfinis. C'est le cas par exemple de l'attribut
xml:lang qui permet de définir la langue du document.
Exemple
<p xml :lang = 'fr'>Exemple</p>
Cet attribut est hérité par l'ensemble des éléments fils de l'élément sur lequel il est défini.
Autres attributs prédéfinis :
xml :space='preserve' ou xml :space='default' permet d'indiquer si les caractères
d'espacement (espace, tabulation, rupture de ligne, ligne blanche) sont préservés ou si
l'application peut appliquer le traitement par défaut.
3-3 LES ENTITES PARAMETRIQUES

Servent à définir des symboles qui seront utilisés ailleurs dans la DTD. Ce sont en quelque
sorte des raccourcis d'écriture : partout où une entité est mentionnée, elle peut être remplacée
par la chaîne de caractères qui lui est associée. Ce mécanisme s'apparente à un mécanisme de
"macro"2.
Exemple tiré de la spécification du langage HTML:
<!ENTITY % heading "H1|H2|H3|H4|H5|H6">
• l'exemple ci-dessus a pour effet d'indiquer au système que toute occurence de
%heading; doit être remplacée par H1|H2|H3|H4|H5|H6
La définition d'une entité peut elle-même faire référence à d'autres entités. La substitution est
alors effectuée récursivement. Par exemple, avec les définitions supplémentaires suivantes:
<!ENTITY % list "UL | OL">
<!ENTITY % preformatted "PRE">
<!ENTITY % block
"P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT | BLOCKQUOTE | FORM |
HR | TABLE | FIELDSET | ADDRESS">
L'entité %block; sera définie comme "P | H1 | H2 | H3 | H4 | H5 | H6 | UL | OL | PRE | DL |
DIV | NOSCRIPT | BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS"
2
Les entités paramétriques ne peuvent pas être utilisées en dehors d'une DTD

3-4 LES ENTITES DE CARACTERES

Servent à donner un nom facilement lisible à des caractères qui ne sont peut-être pas
représentables dans l'alphabet utilisé, ou qui ne sont pas disponibles au clavier.
Exemple tiré de la spécification du langage HTML:
<!ENTITY nbsp " ">
<!ENTITY iexcl "¡">
Les entités de caractères définies dans une DTD peuvent être utilisées dans un document
XML référençant cette DTD à l'aide de la notation &NomEntité;
3.5 LES ENTITES INTERNES

Les entités internes permettent de remplacer une valeur par une abréviation. Cette abréviation
est appelée Entité Interne et doit être déclarée dans la déclaration du document.
Exemple : entité interne
<?xml:stylesheet href=" 3b-EntiteInterne.xsl" type="text/xsl" ?>
<!DOCTYPE catalogue [
<!ENTITY INTER "Internet " >
]>
<catalogue>
<stage>
<intitule>XML et les bases de données</intitule>
<grp-produit>&INTER; </grp-produit>
</stage>
</catalogue>
Lors de la référence à l’entité interne, son nom est préfixé par & et suffixé par ;.
L’ordre de déclaration des entités est sans importance.
3.6 LES SECTIONS LITTERALES

Les sections littérales permettent de créer des chaînes contenant des caractères spéciaux.
Exemple
<exemple>contenu :
< ! [CDATA [ <TITLE>l’EDI et l’Internet</TITLE>]]>
</exemple>
C’est l’utilisation des délimiteurs < ! [CDATA [ et ]]> qui détermine le contenu de la section
littérale. Cette dernière ne sera pas interprétée. Cela signifie que l’élément « exemple »
contient :
« contenu : <TITLE>l’EDI et l’Internet</TITLE> ».
3.7 LES ENTITES EXTERNES

3.7.1 l’adressage par URL
Exemple d’une entité externe
<?xml:stylesheet href=" 3b-EntiteExterne.xsl" type="text/xsl" ?>

<!DOCTYPE catalogue [
<!ENTITY INTER " Internet ">
<!ENTITY Obj_Xmlp SYSTEM "3b_OBJ_XMLP.xml">
]>
<catalogue>
<stage>
<grp-produit>&INTER; </grp-produit>
&Obj_Xmlp;
</stage>
</catalogue>
Les fichiers .xml référencés n’ont pas à contenir de prologue. En effet, celui-ci est inclu dans
le document principal.
C’est le mot clé SYSTEM qui indique qu’il s’agit d’une référence de type URL.
3.7.2. Adressage par identificateur public (FPI3)
L'adressage par identificateur public permet de réaliser une indirection via un fichier externe
(fichier catalogue).
<!ENTITY nom PUBLIC "FPI" "URL">
Le mot clé PUBLIC indique qu'il s'agit d'un FPI. IL est possible d'ajouter une URL qui sera
utilisée lorsque l'application ne pourra pas résoudre l'identificateur public.
Exemple :
Code pour référencer les entités prédéfinies XHTML
< ! - - character entity set. Typical invocation :
< ! ENTITY % HTMLlat1 PUBLIC
"-//W3C//ENTITIES Latin 1 for XHTML//EN"
http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent>
%HTMLlat1 ;
-->
Le FPI est de la forme: préfixe//auteur//description//CodeLangue
3.7.2.1. Résolution des identificateurs publics :
La résolution des adressages par FPI se fait de la façon suivante :
1. recherche d'un fichier catalogue à partir d'une variable d'environnement de type PATH,
2. Recherche dans le fichier catalogue d'une entrée correspondante au FPI,
3. Récupération de l’URL associée à l'identificateur,
4. Si l'identificateur n'est pas trouvé, utilisation de l’URL par défaut.
3.7.2.2. Avantages
L'utilisation de ce mode d'adressage augmente la maintenabilité de l'application en
permettant une réutilisation des liens. Lorsqu'une URL change, il n'y a que le fichier
catalogue à modifier que tous documents XML prennent en compte la modification.
3.8 LES ENTITES NON-XML
3
Format Public Identifier

La déclaration de telles entités nécessite la définition préalable du format de l’entité, c’est à

dire de l’application capable d’interpréter cette entité.
Exemple
< !DOCTYPE article [
< !NOTATION perso SYSTEM "winword.exe" >
< !ENTITY exemple SYSTEM "Nonxml.test" NDATA perso >
]>
<article>
<title test = 'exemple' >
</article>
La référence à une entité non-XML ne peut se faire qu’au niveau d’un attribut. Il n’est pas
possible de référencer une entité non-XML dans la valeur d’un élément.
3.9 RECAPITULATIF SUR LES ENTITES

1. nom est une référence à une entité interne ou externe XML
<TEST>&nom</TEST> Autorisé
<TEST>Ceci est &nom ;</TEST> Autorisé
<TEST attribut=&nom ;></TEST> Autorisé
<TEST attribut =&nom ;>exemple</TEST>
Autorisé
2. nom est une référence à une entité externe non-XML

<TEST attribut ='nom'></TEST> Autorisé
<TEST>'nom'</TEST> Non Autorisé
4. CONSEIL D'ECRITURE
1. élément versus attribut
Il n'est pas toujours facile de choisir entre élément et attribut, car il n'y a pas de règles
absolues car tout peut se réduire à des éléments sans attributs.
Les critères de choix sont liés à :
• La structure de l'information
- Structurée ou non structurée multi-lignes éléments
- Non structurée attribut
• Qui et comment est exploitée l'information
- Homme ou machine et type d'application
• L'ordre de l'information a-t-il une importance
- Ordre important éléments
- Ordre non important attribut
(Le parseur traite et restitue les attributs sans règle imposée)
2 Inclure les méta-données sous forme d'attributs dans un élément vide
exemple
<exemple>
<meta cat = 'Exemple'
num='7.3'

auteur='Mkadmi'
date_cre='2002-11-15'
date_mod=' '>
</meta>
</exemple>
3 Utiliser des marquages méta-typographiques pour indiquer les éléments devant
bénéficier de mise en forme particulière. Ce marquage n'indiquant pas la mise en forme à
réaliser.
Exemple
<p>Dans l’&apos ;exemple suivant le texte important est indiqué entre des
marqueurs<me>spéciaux</me></p>
L’élément me indique ici le texte qui doit bénéficier d'une mise en forme particulière,
mais n’indique nullement quelle mise en forme il faut appliquer.
5. DOCUMENT BIEN FORME ET DOCUMENT VALIDE: LA DTD

Un document bien formé est un document respectant la syntaxe XML.
Un document valide est un document bien formé qui respecte une structure type
définie dans une DTD.
La DTD (Document Type Definition) est un composant optionnel du prologue XML,
permet de différencier la notion de document bien formé ou valide
Un document bien formé est conforme aux règles syntaxiques du langage XML
Un document valide est conforme à la grammaire définie par la DTD
On choisit d'associer une DTD à un document si l'on veut vérifier sa validité
La DTD permet de spécifier la structure logique d'un document
C'est le parseur XML qui fonctionne en mode validant ou non, suivant son paramétrage
ou la référence à une DTD
La DTD n'est pas décrite en XML, elle utilise sa propre syntaxe
L'écriture d'une DTD est la transposition d'un modèle de données (type MCD Merise ou
modèle d'objets UML) au format XML.
5.1 REFERENCE A UNE DTD DANS UN DOCUMENT XML

< ! DOCTYPE nom SYSTEM ‘nomfichier.dtd’>
Dans ce cas le fichier DTD ne contient pas la déclaration < !DOCTYPE …>.

Exemple : le fichier xml

< ?xml version = ''1.0'' ?>
< ?xml : stylesheet href = ''DTDexterne.xsl'' type = ''texte/xsl'' ?>
< !DOCTYPE catalogue SYSTEM ''DTDexterne.dtd''>

<catalogue>
<stage id = ''XMLPres''>
<prerequis>connaître les langages SQL et HTML</prerequis>
</stage>
<stage id = ''XML Prog''>
<intitule>XML programmation</intitule>
<prerequis>avoir suivi le stage de XML et les bases de données</prerequis>
</stage>
</catalogue>
Exemple : la DTD : fichier DTDexterne.dtd
< ! ELEMENT catalogue (stage)*>
< ! ELEMENT stage (intitule, prerequis)>
< ! ELEMENT intitule (#PCDATA)>
< !ELEMENT prerequis (#PCDATA) | xref )*>
< !- - déclaration de xref comme élément vide - ->
< ! ELEMENT xref EMPTY>
< !- - déclaration de l’attribut ID -->
< ! ATTLIST stage id ID #REQUIRED >
< ! – déclaration de l’attribut xref de type IDREF - ->
< ! ATTLIST xref xref IDREF #REQUIRED >
Cependant, la définition de la DTD peut se faire dans le document XML lui même en
incluant dans le prologue l’ensemble des déclarations de la DTD.
< ?xml version = ''1.0'' ?>
< ?xml : stylesheet href = ''DTDexterne.xsl'' type = ''texte/xsl'' ?>
< !DOCTYPE catalogue [

< ! ELEMENT catalogue (stage)*>
< ! ELEMENT stage (intitule, prerequis)>
< ! ELEMENT intitule (#PCDATA)>
< !ELEMENT prerequis (#PCDATA) | xref )*>
< !- - déclaration de xref comme élément vide - ->
< ! ELEMENT xref EMPTY>
< !- - déclaration de l’attribut ID -->
< ! ATTLIST stage id ID #REQUIRED >
< ! – déclaration de l’attribut xref de type IDREF - ->
< ! ATTLIST xref xref IDREF #REQUIRED >
]>

<catalogue>
<stage id = ''XMLPres''>
<prerequis>connaître les langages SQL et HTML</prerequis>
</stage>
<stage id = ''XML Prog''>
<intitule>XML programmation</intitule>
<prerequis>avoir suivi le stage de XML et les bases de données</prerequis>
</stage>
</catalogue>
5.2 DECLARATION INTERNE ET EXTERNE DE LA DTD

Un document XML peut contenir à la fois une référence à une DTD et une déclaration
interne d’élément.
Dans ce cas si un élément est déclaré dans la DTD et dans le document, c’est toujours la
déclaration interne qui prévaut.
6 LES DIFFERENTS FORMATS DE DECLARATIONS

C’est la définition du contenu type d’un document (sa grammaire).
Il existe quatre types de déclarations :
Des éléments,
Des listes d’attributs,
Des entités
Des notations
6.1. LES ELEMENTS

Exemple
< ! ELEMENT livre (titre, editeur ?, auteur, chapitre+, prix, critique*) >
Cet exemple définit l'élément livre suivi de son modèle de contenu :
• titre : information obligatoire présente une seule fois (1, 1),
• editeur? : le ? signifie que cette information est facultative (0, 1),
• chapitre+ : le + signifie que l'élément peut être répété (1,N),
• critique* : * signifie que l'élément est facultatif et qu'il peut être répété (0,N).
Autres exemples
< !ELEMENT livre (titre, editeur ?, auteur, (titre_chapitre, corps_chapitre)+, prix, critique*)
>
(titre_chapitre, corps_chapitre)+ indique que le couple (titre_chapitre, corps_chapitre) est
obligatoire et peut être répété.
<ELEMENT livre (titre, editeur ?, auteur, chapitre+, prix, critique*)>
< !ELEMENT chapitre (titre_chapitre, corps_chapitre)>
indique que l’élément chapitre est obligatoire, peut être répété et que chaque chapitre est
constitué des éléments titre_chapitre et corps_chapitre dans cet ordre.
< !ELEMENT livre (titre, editeur | auteur, prix, critique*)>

editeur | auteur : indique que ces éléments sont obligatoires et que l’ordre est indifférent.
6.1.1. Déclaration d'un élément de données
La déclaration d'un élément fils (niveau le plus fin) se fait de la façon suivante
< !ELEMENT nom (#PCDATA)>
L'élément nom peut contenir toute donnée XML (y compris des sections littérales) mais
ne peut pas contenir des données non-XML.
6.1.2. Déclaration d'un élément à modèle mixte
Cette définition autorise la mixité entre données et élément.
< !ELEMENT chapitre (#PCDATA | p | exemple)* >
Un chapitre peut contenir des données (#PCDATA) et/ou un élément nomme p et/ou un
élément nommé exemple. Ces éléments étant facultatifs et pouvant apparaître plusieurs
fois.
6.1.3. Déclaration d'un contenu libre: ANY
Il est possible d'indiquer que le contenu d'un élément est libre (donnée ou autres
éléments) en précisant le mot clé ANY
< ! ELEMENT chapitre ANY >
Cette déclaration peut être très pratique en phase de conception car elle permet de définir
des structures et de les affiner au fur et à mesure de l'avancement du projet.
6.1.4 Déclaration d'un Elément vide
< !ELEMENT chapitre EMPTY>
6.2 EXEMPLE RECAPITULATIF

Exemple 1 : DTD d’un ouvrage
< ! DOCTYPE article [
< ! ELEMENT article (topic)* >
< ! ELEMENT titre (#PCDATA) >
< ! ELEMENT editeur (#PCDATA) >
< ! ELEMENT auteur (#PCDATA) >
< ! ELEMENT prix (#PCDATA) >
< ! ELEMENT pages (#PCDATA) >
]>
Exemple 2 : DTD d’un catalogue de formation

< ! DOCTYPE catalogue [
< ! ELEMENT catalogue (stage) * >
< ! ELEMENT stage (intitule, duree, population, objectif,
desc_jour+) >
< ! ELEMENT desc_jour (num ?, desc, tp*) >
< ! ELEMENT intitule (#PCDATA | p)* >
< ! ELEMENT duree (#PCDATA) >
< ! ELEMENT population (#PCDATA) >
< ! ELEMENT objectif (#PCDATA | p)* >
< ! ELEMENT num (#PCDATA) >
< ! ELEMENT desc (#PCDATA | p)* >

< ! ELEMENT tp (#PCDATA | p)* >

< !-- déclaration de l’élément paragraphe -->
< ! ELEMENT p (#PCDATA)>
]>
6.3 LA LISTE D’ATTRIBUTS

Comme cela été vu au chapitre sur la syntaxe XML, un attribut est un couple nom=valeur. La
définition des attributs dans une DTD va permettre de spécifier les attributs qui pourront ou
devront être associés à un élément, et éventuellement leurs valeurs par défaut.
Cette déclaration se fait par : < !ATTLIST nom-élément déclaration-attribut>
La déclaration d'attributs peut être répétée et se fait sous la forme suivante :
nom-attribut type valeur-défaut
Six types d'attributs sont reconnus :
CDATA pour indiquer que la valeur de l'attribut est une séquence de caractères (y
compris des entités de caractères)
ID pour indiquer que la valeur de l'attribut est un symbole commençant par
une lettre et ne contenant que des lettres, des chiffres, ou les caractères - _
: et . (la valeur doit être unique sur l'ensemble d'un document)
IDREF pour indiquer que la valeur de l'attribut est un symbole défini comme
valeur de l'attribut ID d'un autre élément de document
IDREFS comme IDREF, mais plusieurs valeurs séparées par des espaces sont
autorisées
ENTITY pour utilisateurs avancés (pas abordés dans le cadre de ce cours)
ENTITIES
NMTOKEN
NMTOKENS
énumération une énumération de valeurs possibles se fait en mettant entre parenthèses
les valeurs séparées par des |. Exemple:
<!ATTLIST TD
valign (top|middle|bottom|baseline) #IMPLIED
... >
Et il existe 4 valeurs par défaut :
indique que l'application traitant le document
Le symbole prédéfini #IMPLIED
fournira la valeur par défaut
indique l'auteur du document doit définir
Le symbole prédéfini #REQUIRED
l'attribut en question
Le symbole prédéfini #FIXED suivi d'une indique que l'attribut ne peut prendre que la
valeur (chaîne de caractères entre guillemets) valeur mentionnée
Une des valeurs d'une énumération, ou une

indique qu'en l'absence d'indication explicite,
chaîne de caractères compatibles avec le type
l'attribut prendra la valeur indiquée ici
associé à l'attribut

6.4 LES ENTITES PARAMETRES

Les entités paramètres sont identiques sur le principe aux entités internes. Cependant une
entité paramètre n’est référençable qu’à l’intérieur même de la DTD où elle est déclarée.
< !ENTITY % nom 'valeur' >
Exemple
< !ENTITY % Fr 'Franc' >
< !ENTITY % Eu 'Euro' >
< !ATTLIST PRIX unite (% Fr ; | %Eu ;) ''%Eu ; '' >
6.5 LES SECTIONS INTERNES ET EXTERNES

Le découpage des DTD en sections permet de mettre en œuvre un découpage modulaire de la
déclaration. Dans la pratique, une DTD est fréquemment composée d’une déclaration incluant
toutes les structures (éléments, attributs, entités) spécifiques à l’auteur, et de liens à des
déclarations externes incluant les structures types communes à plusieurs documents.
Exemple : Fichier sectionExterne.dtd
< !ELEMENT catalogue (stage)* >
< !ELEMENT stage (intitule, description, session*) >
< !ELEMENT intitule (#PCDATA) >
< !ENTITY % planning SYSTEM « planning.dtd » >
%planning ;
Exemple : Fichier planning.dtd
< !ELEMENT session (debut, fin) >
< !ELEMENT debut (#PCDATA) >
< !ELEMENT fin (#PCDATA) >
Exemple : Fichier SectionExterne.xml
< ?xml version= « 1.0 » encoding « ISO-8859-1 » ?>
< ?xml : stylesheet href= « SectionExterne.xsl » type= « text/xsl » ?>
< !DOCTYPE catalogue SYSTEM « SectionExterne.dtd »>
<catalogue>
<stage>
<intitule>XML – Présentation</intitule>
<description>exemple</description>
<session>
<debut>15/11/2002</debut>
<fin>13/12/2002</fin>
</session>
<session>
<debut>10/01/2003</debut>
<fin>19/04/2003</fin>
</session>
</stage>
<stage>
<intitule>XML et bases de données</intitule>
<description>exemple</description>
</stage>
</catalogue>

7. LES DOMAINES DE NOMS (NAMESPACES)

Un des objectifs de XML est l'interopérabilité. Pour cela on suppose que chacun doit essayer
de s'appuyer sur des DTD standards afin de faciliter la compréhension des structures de
documents.
Il est donc courant d'utiliser plusieurs DTD pour construire un document XML.
Des conflits de noms peuvent alors survenir si deux éléments portent des noms identiques
dans deux DTD différentes (par exemple fn=fonction dans MathML, fn=foot notes dans
Basic-Text).
Pour éliminer ces conflits de noms, on a recours aux domaines de noms (ou appelés aussi
espaces de nommage). Le principe consiste préfixer chaque nom d'élément par un nom qui
identifie le domaine auquel il fait référence (par exemple math:fn pour l'élément
mathématique fn et text:fn pour l'élément bas de page).
Les avantages de cette structuration :
• Les espaces de noms permettent de lever les ambiguïtés sur des éléments de DTD
différentes qui porteraient le même nom (nom de produit, nom de personne, ..),
• Les espaces de noms favorisent la modularité des documents XML et les sources multiples
de ces derniers,
• Les espaces de nom permettent, indirectement, de rendre plus lisible un document XML
contenant des informations de sources diverses.
Les Namespaces ont un statut de recommandation du 14 Janvier 1999, dont les spécifications
sont disponibles à:
http://www.w3.org/TR/1999/REC-xml-names-19990114
Un espace de noms est déclaré à l'aide de l'attribut xmlns :
Soit en déclarant l'espace de nom dans l'élément :
<ElementDuDocument xmlns=UriDTDaImporter">
Exemple d’utilisation sans préfixe
<seminaire xmlns=«http://www.edifrance.org/seminaire»>
Soit en associant un préfixe pour une utilisation plus fine :
<ElementDuDocument xmlns:Préfixe='UriDTDalmporter">
Exemple d’utilisation avec préfixe
<seminaire xmlns :sem=«http://www.edifrance.org/seminaire»>
….
<sem :date/>
Quand on déclare plusieurs espaces de noms, l'espace de nom par défaut est celui sans
préfixe.
La portée d'une déclaration est limitée au sous-arbre dans lequel la déclaration a été faite.

Chapitre 2 : Les schémas XML
CHAPITRE 2 : XML SCHEMA
1. INTRODUCTION AUX SCHEMAS XML (XML SCHEMA)

XML fût pressenti dès son arrivée comme une technologie qui allait révolutionner l'échange
de données. Cependant, les DTD, comme langage de schéma utilisé pour spécifier le contenu
et la structure de documents XML, souffrent de quelques déficiences :
Les DTD ne sont pas écrites en XML, ce qui signifie que les technologies existantes
pour manipuler des documents XML telles que DOM ou SAX ne peuvent être utilisées
pour « parser » des schémas de documents.
Les DTD ne supportent pas les espaces de nom ce qui rend impossible l’import de
schémas externes afin de réutiliser du code existant.
Les DTD n'offrent qu'un typage très limité des données.
Conscient de ces fgrandes limitations, le W3C a proposé un nouveau langage de définition de
schéma de documents qu’est XML Schema.
Conçu pour palier aux déficiences pré-citées des DTD, XML Schema propose, en plus des
fonctionnalités fournies par les DTD, plusieurs nouveautés à savoir :
Un grand nombre de types de données intégrées comme les booléens, les entiers, les
intervalles de temps, etc. De plus, il est possible de créer de nouveaux types par ajout
de contraintes sur un type existant.
Des types de données utilisateurs qui nous permettent de créer notre propre type de
données nommé.
La notion d'héritage : Les éléments peuvent hériter du contenu et des attributs d'un
autre élément. C'est sans aucun doute l'innovation la plus intéressante de XML
Schema.
Le support des espaces de nom.
Les indicateurs d'occurrences des éléments peuvent être tout nombre non négatif.
Une grande facilité de conception modulaire de schémas.
XML Schema a un statut de recommandation du 2 Mai 2001, dont les spécifications sont
disponibles à :
http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/

XML Schema par l’exemple

Je vais présenter en ce qui suit un fichier XML, avec la DTD et le schéma XML qui vont
avec. Ces trois fichiers sont édités et générés par l’outil XML SPY.
Exemple de description XML d’une arborescence de fichiers
<?xml version="1.0" encoding="UTF-8"?>
<racine>
<repertoire nom="XML" date_modif="25-02-2001" heure_modif="14:12">
ressources XML (exemples, outils, spécifications, ...)
<repertoire nom="exemples" date_modif="25-02-2001" heure_modif="14:14">
exemples de fichiers XML
</repertoire>
<fichier nom="séminaire.xml" taille="2" unite_taille="ko" date_modif="12-02-
2001" heure_modif="14:12">
Description XML du cours CXML
</fichier>
<fichier nom="XMLSPY.xml" taille="2" unite_taille="ko" date_modif="12-02-
2001" heure_modif="15:12"/>
<repertoire nom="outils" date_modif="25-02-2001" heure_modif="16:09"/>
</repertoire>
<repertoire nom="Schema" date_modif="19-02-2001" heure_modif="14:12">
<repertoire nom="DTD" date_modif="19-02-2001" heure_modif="15:12">
Ressources sur les DTD
<fichier nom="XMLSPY.exe" taille="8" unite_taille="Mo" date_modif="28-01-
2001" heure_modif="12:12">
Version d'évaluation
</fichier>
<fichier nom="cooktop.msi" taille="4" unite_taille="Mo" date_modif="21-02-2001"
heure_modif="09:12">
CookTop (éditeur XML, XSLT, DTD) gratuit au format MS
</fichier>
</repertoire>
<repertoire nom="XML Schema" date_modif="25-02-2001" heure_modif="16:09"/>
</repertoire>
<fichier nom="ebXML.pdf" taille="246" unite_taille="KO" date_modif="24-03-2001"
Spécifications ebXML
</fichier>
</racine>
DTD associée à l’arborescence

<!ELEMENT racine (repertoire | fichier*)>
<!ELEMENT repertoire (#PCDATA | fichier | repertoire)*>
<!ATTLIST repertoire
nom CDATA #REQUIRED
date_modif CDATA #REQUIRED
heure_modif CDATA #REQUIRED
>

<!ELEMENT fichier (#PCDATA)>

<!ATTLIST fichier
nom CDATA #REQUIRED
taille CDATA #REQUIRED
unite_taille (Ko | Mo | To) #REQUIRED
date_modif CDATA #REQUIRED
heure_modif CDATA #REQUIRED
>
XML schema associé à l’arborescence

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:element name="fichier">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="nom" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="XMLSPY.exe"/>
<xs:enumeration value="XMLSPY.xml"/>
<xs:enumeration value="ebXML.pdf"/>
<xs:enumeration value="séminaire.xml"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="taille" use="required">
<xs:simpleType>
<xs:enumeration value="2"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="unite_taille" use="required">
<xs:simpleType>
<xs:enumeration value="KO"/>
<xs:enumeration value="MO"/>
<xs:enumeration value="ko"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="date_modif" use="required">
<xs:simpleType>
<xs:enumeration value="12-02-2001"/>

</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="heure_modif" use="required">
<xs:simpleType>
<xs:enumeration value="12:12"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="racine">
<xs:complexType>
<xs:sequence>
<xs:element ref="repertoire" maxOccurs="unbounded"/>
<xs:element ref="fichier"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="repertoire">
<xs:complexType mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="fichier"/>
<xs:element ref="repertoire"/>
</xs:choice>
<xs:attribute name="nom" type="xs:string" use="required"/>
<xs:attribute name="date_modif" use="required">
<xs:simpleType>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="heure_modif" use="required">
<xs:simpleType>
</xs:restriction>
</xs:simpleType>

</xs:attribute>
</xs:complexType>
</xs:element>
</xs:schema>
2. LA DECLARATION D'UN SCHEMA

Comme tout document XML, un schéma XML débute par un prologue et est suivi par le corps
document.
Les déclarations d'éléments et d'attributs se font à l'intérieur de la balise <xsd:schema>, qui
est la racine du document et contient des informations relatives à l'espace de nom du schema
de XML Schema, pour validation du document XML.
Déclaration d’un schéma
<xsd :schema
<xmlns :xsd= http://www.w3.org/2000/10/XMLSchema >
……………………………
</xsd :schema>
Tout élément appartenant aux langage XML Schéma doit être préfixé par "xsd:",
l'espace de nom réservé par le W3C.
Comme nous l'avons vu dans la partie consacrée aux DTD, un document XML est composé
principalement d'éléments (les balises du document) qui peuvent comporter des attributs.
XML Schema va permettre de déclarer ces éléments et ces attributs.
La déclaration d'éléments ou attributs va pouvoir se faire de différentes manières en fonction
de la nature de l'élément et/ou de l'attribut :
• Element ou attribut de type simple prédéfinis par le W3C
• Element ou attribut de type simple prédéfini par l'utilisateur
• Element ou attribut de type complexe
Exemple de déclarations simples
<xsd :element name ="nom" type ="xsd :string "/>
<xsd :attribute name ="taille" type ="xsd :integer "/>
2.1. LES ELEMENTS

Un élément, au sens d'XML, est en fait une balise. Un élément est déclaré de la façon suivante
dans un schéma :
Déclaration d’éléments
<xml version = «1.0 » encoding = «ISO-8859-1 » ?>
<xsd :schema xmlns :xsd = http://www.w3.org/2000/10/XMLSchema>
<xsd :element name ="nom" type ="typeNom "/>
<xsd :attribute name ="remarque" type ="xsd :integer "/>
……
</xsd :schema>

Chaque élément déclaré est associé à un type de données via l'attribut type. L'élément nom est
de type typeNom, qui est un type complexe défini par l'utilisateur. L'élément remarque est du
type xsd:string qui est un type simple prédéfini de XML Schema.
Les éléments pouvant contenir des sous-éléments ou porter des attributs sont dits de types
complexes, tandis que les éléments ne contenant pas de sous-éléments sont dits de types
simples.
2.2 LES ATTRIBUTS

Un attribut est un qualificatif qui s'applique à un élément. À la différence des éléments qui
peuvent être de type complexe ou simple, les attributs peuvent être uniquement de type
simple. En conséquence, les attributs ne peuvent pas contenir d'autres éléments ou attributs.
Les déclarations d'attributs et références à un groupe d'attributs doivent apparaître à la fin des
définitions de types complexes.
Déclaration d’attributs
<xml version = «1.0 » encoding = «ISO-8859-1 » ?>
<xsd :schema xmlns :xsd = http://www.w3.org/2000/10/XMLSchema>
….
<xsd :complexType name = « typeContacts »>
< ! – déclaration du modèle de contenu ici -->
<xsd :attribute name= « maj » type = « xsd :date »/>
</xsd :complexType>
</xsd :scheama>
2.2.1 les contraintes d’occurrence sur attribut
Tout comme dans les DTD, les attributs peuvent avoir des contraintes d'occurrences.
L'élément attribute de XML Schema peut avoir deux attributs optionnels use et value.
Exemple
<xsd :attribute name = « date-modif » type = « xsd :date »
use = « default » value = « 2002-11-15 »/ >
<xsd :attribute name = « numero » type = « xsd :NMTOKEN »
use = « required »/ >
• use permet de définir une contrainte sur l'attribut
required : l'attribut est obligatoire
optional : l'attribut est optionnel
fixed : attribut optionnel mais si présent sa valeur est celle spécifiée par value.
default : attribut optionnel mais valeur par défaut spécifiée par value.
prohibited : attribut ne doit pas apparaître
• value permet de définir une valeur qui doit être conforme au type déclaré dans l'attribut
2.2.2. Les groupe d'attributs
XML Schema permet la définition de groupes d'attributs. L'utilisation d'un groupe d'attributs
permet d'améliorer la lisibilité et facilite la maintenance d'un schéma
• un groupe d'attributs peut être défini à un seul endroit.
• il peut être référencé dans plusieurs déclarations et définitions.
Ces caractéristiques des groupes d'attributs les rendent semblables aux entités paramétriques
des DTD.

3 LES TYPES SIMPLES

Le document XML Schema fournit deux types de définition de type de données : simple et
complexe.
Les types simples incluent les types de base inclus dans la bibliothèque standard des XML
Schema, les listes et les unions.
3.1 LES TYPES DE BASE INTEGRES

XML Schema apporte la notion, comme pour les langages, de type de bases prédéfinis et qui
sont assez évolués.
Il s’agit d’une nouveauté importante, puisque les DTD se contentaient de types de données
plutôt limités (PCDATA, CDATA …).
Les types de données simples les plus courants sont représentés : chaînes de caractères,
entiers, dates, réels, etc. Les types de données des DTD ont été repris par XML Schema pour
des raisons de compatibilité ascendante.
3.2 LES LISTES

Les types listes sont des suites de types atomiques. XML Schema possède 3 types de listes
intégrés qui sont NMTOKENS, ENTITIES et IDREFS. En plus de ces listes intégrées, nous
pouvons créer de nouveaux types de listes par dérivation de types atomiques existants.
Toutefois la création de types de liste à partir de listes ou de types complexes n’est pas
permise, ceci afin d’éviter des schémas trop complexes.
Exemple de définition de liste pour un attribut

<xsd :attribute name = « unite-taille » use = « required »>

<xsd :simpleType>
<xsd :restriction base = « xsd :NMTOKEN »>
<xsd :enumeration value = « KO »/>
<xsd :enumeration value = « MO »/>
<xsd :enumeration value = « GO »/>
</xsd :restriction>
</xsd :simpleType>
</xsd :attribute>
3.3 LES UNIONS

XML Schema permet la définition d’éléments union. Les éléments peuvent avoir des
contenus variables sur des types différents.
Exemple de contenu variable pour l’ISBN
<xsd :simpleType name = « isbnType »>
<xsd :union>
<xsd :simpleType>
<xsd :restriction base = « xsd :string »>
<xsd :pattern value = « [0-9]{10} »/>
</xsd :restriction>
</xsd :simpleType>
<xsd :simpleType>
<xsd :restriction base = « xsd :NMTOKEN »>
<xsd :enumeration value = « TBD »/>
<xsd :enumeration value = « NA »/>
</xsd :restriction>
</xsd :simpleType>
</xsd :union>
</xsd :simpleType>
4 LES TYPES COMPLEXES

Les types de données simples ne permettent pas aux éléments de contenir des sous-éléments.
Pour cela, XML Schema définit le type de données complexes, pouvant être créé par un
auteur de schéma.
Un type de données complexe peut être caractérisé par son modèle de contenu ; c'est-à-dire
comment ses sous-éléments sont susceptibles d'apparaître. Un type complexe est défini à
l'aide de l'élément <xsd:complexType name="..."> qui pourra contenir, entre autres, une
séquence d'éléments, une série d'attributs, etc.
XML Schema propose un ensemble de connecteurs permettant de représenter n'importe quel
modèle de contenu exprimable à l'aide d'une DTD :
• Le connecteur de séquence
• Le connecteur de choix
• L'élément All (ANY dans les DTD)
4.1. LE CONNECTEUR DE SEQUENCE

Le connecteur de séquence permet de définir un type complexe comportant des suites
d'éléments. Le connecteur séquence définit une liste ordonnée de sous éléments

Pour pouvoir rendre des éléments optionnels, il faut appliquer des contraintes d'occurrences
sur les éléments.
Définition d’une séquence pour l’élément racine
<xsd :element>
<xsd :complexType>
<xsd :sequence>
<xsd :element ref = « repertoire »/>
<xsd :element ref = « fichier »/>
</xsd :sequence>
</xsd :complexType>
</xsd :element>
Le connecteur de séquence de XML Schema reproduit donc fidèlement l'opérateur
de séquence des DTD(,)
4.2. LE CONNECTEUR DE CHOIX

Le connecteur de choix permet de définir un type complexe comportant des éléments
variables. Il n'autorise qu'un seul de ses fils soit présent dans le document instance.
Pour pouvoir autoriser l'un ou l'autre ou les deux, il faut appliquer des contraintes
d'occurrences sur l'élément xsd: choice.
Définition d’une alternative pour le répertoire
<xsd :choice minOccurs = « 0 » maxOccurs = « unbounded »>
<xsd :element ref = « repertoire »/>
<xsd :element ref = « fichier »/>
</xsd :choice>
Le connecteur de choix de XML Schema a donc les mêmes caractéristiques que
l'opérateur ou (|) des DTD
4.3. L'ELEMENT ALL

L'élément all représente un connecteur supplémentaire par rapport aux DTD. Il permet à ses
éléments fils d'apparaître une fois (ou pas du tout) et dans n'importe quel ordre.
Définition d’un type contenant le connecteur all
<xsd :complexType name = « typeNom »>
<xsd :all>
<xsd :element name = « nom » type = « xsd :string »/>
<xsd :element name = « prenom » type = « xsd :string »/>
</xsd :all>
</xsd :complexType >
Le connecteur all doit apparaître comme fils unique du plus haut niveau du modèle de
contenu, c’est à dire comme fils unique de l’élément complexType.
Les fils de l’élément peuvent apparaître au plus une fois.
4.4 LES CONTRAINTES D’OCCURRENCES SUR ELEMENT

Les DTD ont des contraintes d’occurrences limitées à 0,1 ou l’infini.
XML Schema est beaucoup plus souple puisque tout nombre entier non négatif peut être
utilisé pour fixer la valeur du nombre maximum et/ou minimum d’occurrences.

Lorsqu’ils sont définis localement, les éléments d’un schéma peuvent comporter les attributs
minOccurs et maxOccurs.
La valeur spéciale « unbounded » peut être donnée à l’attribut maxOccurs pour spécifier
qu’un élément peut apparaître un nombre illimité de fois.
La valeur par défaut est de 1 pour les deux attributs minOccurs et maxOccurs, donc
présence obligatoire et une seule fois.
5 LES TYPES DE CONTENUS

XML Schema permet de différencier les types de contenu :
Des éléments et attributs sans sous éléments ou attributs, et ne contenant donc que des
valeurs :
Xsd :simpleType
<xsd :attribute name="unite_taille" use="required">

<xsd :simpleType>
<xsd :restriction base="xsd :NMTOKEN">
<xsd :enumeration value="KO"/>
<xsd :enumeration value="MO"/>
<xsd :enumeration value="GO"/>
</xsd :restriction>
</xsd :simpleType>
</xsd :attribute>
Des éléments ayant des sous-éléments et/ou des attributs :
xsd : complexType
<xsd :element name="racine">
<xsd :complexType>
<xsd :sequence>
<xsd :element ref="repertoire">
<xsd :element ref="fichier">
</xsd :sequence>
</xsd :complexType>
</xsd :element>
Des éléments à contenu vide avec seulement des attributs :
xsd : complexType
<xsd :complexType="typeDate">
<xsd :attribute name="jour" type="xsd :byte"/>
<xsd :attribute name="mois" type="xsd :byte"/>
<xsd :attribute name="annee" type="xsd :byte"/>
</xsd :complexType>
Des éléments à contenu simple, avec texte et attributs :
xsd :simpleContent
<xsd:element name="internationalPrice">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:decimal">

<xsd:attribute name="currency" type="xsd:string"/>

</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
Des éléments ayant des sous éléments et/ou attributs et du texte, c’est à dire le type
mixte des DTD :
xsd :complexType mixed = “true”
<xsd:element name="letterBody">
<xsd:complexType mixed="true">
<xsd:sequence>
<xsd:element name="salutation">
<xsd:complexType mixed="true">
<xsd:sequence>
<xsd:element name="name" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="quantity" type="xsd:positiveInteger"/>
<xsd:element name="productName" type="xsd:string"/>
<xsd:element name="shipDate" type="xsd:date" minOccurs="0"/>

</xsd:sequence>
</xsd:complexType>
</xsd:element>
On peut également, pour l’élément complexType avoir le paramètre content =
« valeur » :
- elementOnly : uniquement des sous éléments
- textOnly : uniquement du texte simple
- mixed : sous éléments combinés avec texte simple
- empty : pas de sous éléments
6. LES DERIVATIONS DE TYPES

XML Schema propose deux techniques de dérivations de types : la première appelée
dérivation par restriction du type ancêtre, et la seconde appelée dérivation par extension du
type ancêtre.
Ces deux mécanismes de dérivation s'appliquent aussi bien aux types de données simples que
complexes, ce qui les rend très puissants.
6.1. DERIVATION PAR RESTRICTION

Les différents types de restrictions sont appelés "facettes", et XML Schema dispose de
nombreuses facettes en standard. Ces facettes permettent de définir des contraintes telles que
longueur, valeurs extrêmes, précision, durée, liste de valeurs possibles, ...
Il existe un nombre important de 'facettes' qui permettent de
• fixer la longueur d'un type simple, restreindre sa longueur maximale et minimale,
• énumérer toutes les valeurs possibles d'un type,
• gérer des expressions régulières,

• fixer la valeur minimale ou maximale d'un type (voir ci-dessus),

ci
• fixer la précision du type, ...
Les verbes associés sont, dans l'espace de nom xsd :
- minExclusive, minInclusive, maxExclusive, maxInclusive
m
- precision, scale, length, minLength,maxLength encoding
- period, duration, enumeration, pattern
• pattern permet de préciser une expression régulière.
6.2 DERIVATION PAR EXTENSION

XTENSION
Le mécanisme de dérivation par extension de XML Schema est plus proche conceptuellement
du mécanisme d’héritage des langages orientés objet. Il permet par exemple de rajouter des
éléments ou des attributs au modèle complexe de base. Il permet également de définir des
types d’éléments contenant les données communes (attributs
(attributs et/ou éléments et/ou texte) à
plusieurs éléments.
< !—Définition
Définition d’un type des données communes pour repertoire et fichier--
fichier >
<xsd :complexType name=”typeconteneur” mixed= “true”>
<xsd:attribute name = “nom”
“ ” type = “xsd:string” use = “required”/>
“required”/
<xsd:attribute name = “date_modif”
“ ” type = “xsd:string” use = “required”/>
<xsd:attribute name = “heure_modif”
“ ” type = “xsd:time” use = “required”/>
</xsd:comlexType>

<! – Définition de l’élément repertoire par extension - - >

<xsd :element name = « repertoire »>
<xsd :complexType mixed = « true »>
<xsd:complexContent mixed= “true”>
<xsd:extension base= “typeconteneur”>
<xsd:choice minOccurs = “0” maxOccurs = “unbounded”>
Attributs <xsd:element ref= “repertoire”/>
spécifiques <xsd:element ref = “fichier”/>
</xsd:choice>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<! – Définition de l’élément fichier par extension - - >
<xsd :element name = “fichier”>
<xsd :complexType mixed = « true »>
<xsd:complexContent mixed= “true”>
<xsd:extension base= “typeconteneur”>
<xsd:attribute name = “taille” type= “xsd:integer” use= “required”/>
xsd:attribute name = “unite_taille” use= “required”/>
<xsd:simpleType>
<xsd:restriction base= “xsd:NMTOKEN”>
<xsd:enumeration value= “KO”/>
Attributs <xsd:enumeration value= “MO”/>
<xsd:enumeration value= “GO”/>
spécifiques </xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
6.3. NOTIONS COMPLEMENTAIRES

XML Schema apporte bien d'autres notions telles que :
• Groupes de substitutions : remplacement d'élément par d'autres éléments,
• Elements et types abstraits : forcer à utiliser uniquement les éléments ou types dérivés,
• Types anonymes : pour éviter d'avoir à définir et nommer des éléments référencés une seule
fois,
• Inclusion de XML Schema : pour la modularisation et réutilisation de XML Schema dans un
même espace de noms,
• Redéfinition de types : pour la surcharge des types simple, complexes, attribut ou groupe
d'attributs issus du schéma externe,
• Importation de types : pour la modularisation et réutilisation de XML Schema d'espaces de
noms différents,
• Contraintes référentielles : contrôle d'unicité à un niveau, de clé primaire et de clé étrangère.

7. LES ESPACES DE NOMS

Depuis l'introduction des espaces de nom, la validation de documents XML utilisant des
espaces de nom est devenue plus compliquée car les DTD ne les supportent pas. XML
Schema comble cette lacune en ayant une intégration complète des espaces de nom.
Le support des espaces de noms est une des motivations qui a conduit au développement de
XML Schema, donc son support est complet. Chaque schéma est lié à un espace de nom
particulier (ou à l'absence d'espace de nom) .
Il faut définir au moins un schéma par espace de nom à spécifier.
L'attribut targetNamespace permet de spécifier l'espace de nom par défaut
<xsd :schema
xmlns :xsd = http://www.w3.org/2000/10/XMLSchema
targetNamespace = http://www.edifrance.org/formation
>
Il est fortement conseillé d'utiliser l'attribut facultatif targetNamespace.
8 REFERENCEMENT D'UN SCHEMA

L'association d'un document XML à un XML Schema se fait grâce à deux attributs de XML
Schema-instance
Sans définition d'espace de noms
---> xsi: noNamespaceSchemaLocation=" Nom FichierSchema.xsd"
<racine xmlns :xsi = « http://www.w3.org/2000/10/XMLSchema-instance »
xsi :noNamespaceSchemaLocation = « core_component.xsd »
(Référence qui contient le schéma)
avec définition d'un espace de nom
---> xsi:SchemaLocation=" URI EspaceDeNom NomFichierSchema.xsd"
<racine xmlns :xsi = « http://www.w3.org/2000/10/XMLSchema-instance »
xsi :SchemaLocation=http://www.edifrance.org/formation core_component.xsd

Chapitre 3: La navigation et les liens XML
CHAPITRE 3 : XPATH ET XLL
1. INTRODUCTION
Il existe une grande variété de spécifications liées à XML, dont XPath et XLL sont deux
composantes connexes :
• XPath qui permet d'exprimer la navigation dans un arbre XML avec des expressions sous
forme de patterns utilisées par XSLT et XPointer.
• XLL (XML Linking Language) qui est un ensemble de deux spécifications :
- XLink pour décrire les liens entre documents
- XPointer pour définir un endroit précis dans un document cible d'un lien, en utilisant
XPath.
XPath a un statut de recommandation du 16 Novembre 1999, dont les spécifications sont
disponibles à : http://www.w3.org/TR/1999/REC-xpath-19991116
XLink a un statut de recommandation du 27 Juin 2001, dont les spécifications sont
disponibles à : http://www.w3.org/TR/2001/REC-xlink-20010627
XPointer a un statut de candidate recommandation du 11 Septembre 2001, dont les
spécifications sont disponibles à : http://www.w3.org/TR/2001/CR-xptr-20010911
2. XPATH: LE LANGAGE DE NAVIGATION

Si un document XML contient en même temps des données et des informations permettant
d'identifier la structure et le sens de ces données, il est alors utile de pouvoir s'appuyer sur
cette information pour désigner une partie d'un document XML.
C'est utile lorsque l'on réalise des applications de présentation, par exemple, pour faire une
table des matières où l'on ne veut sélectionner que des titres. C'est également utile lorsqu’on
veut réaliser des hyperliens sur des documents que l'on ne peut pas modifier pour leur ajouter
des ancres et que l'on souhaite pourtant désigner (par exemple, le deuxième alinéa du
troisième chapitre d'un document).
Du coup, il est nécessaire d'avoir un langage de désignation d'objets dans un document ; c’est
l'objectif de XPath. Du point de vue du W3C, l'objectif de XPath est aussi de devenir un
standard de base, réutilisable dans des recommandations de plus haut niveau.
XPath exploite la structure d'un document dans la navigation par :
Une écriture de type "chemins d'accès", comme les URL
Des axes de parcours
Des tests sur les valeurs des objets de l'arbre (élément, attribut,...)
Des fonctions prédéfinies sur les nœuds et les chaînes de caractères
Deux choses importantes dans l'utilisation des expressions XPath :
- La recherche d'une correspondance à un motif est contextuelle
- Tous les éléments correspondants sont renvoyés
2.1. LA SELECTION D'OBJETS

XPath permet d'exprimer la sélection des différents objets d'un document XML

Sélection des éléments

- / racine du document
- . nœud courant
- repertoire tous les éléments <repertoire> enfant du nœud courant
- racine/fichier tous les éléments <fichier> avec <racine> comme parent
- repertoire//fichier tous les éléments <fichier> avec <repertoire> comme ancêtre
- //repertoire tous les éléments <repertoire> avec racine comme ancêtre
- * tous les noeuds de type éléments
- repertoire | fichier tous les éléments <repertoire> ou <fichier>
Ces expressions sont des 'écritures abrégées des écritures directes contenant
la spécification des axes nodaux. Les écritures directes sont plus verbeuses
Recherche d'attribut
- @ Nom l'attribut nom du nœud (élément) courant
- fichier/ @Nom l'attribut nom de l'élément <fichier> fils
-@* tous les attributs de l'élément courant
Sélection des commentaires, textes, et processing instructions

- comment() les commentaires
- text() les nœuds texte
- pi() les nœuds processing instruction
- node() les nœuds autres que racine
Les tests
- repertoire[fichier] les éléments <repertoire> contenant un sous-élément <fichier>
- *[@taille] les éléments contenant un attribut taille
- //repertoire[@nom = "XML"] les éléments <repertoire> de la racine ayant pour
attribut nom = "XML"
2.2 LES AXES NODAUX

XPath permet au travers de la notion d’axes nodaux, de référencer des sous-arbres
complexes type frères, parent, ….
L’expression d’un axe dans une expression XPath doit être suivie du symbole double :: .
Quelques exemples
- child::repertoire tous les éléments <repertoire> enfant du nœud contextuel
- child::* tous les éléments enfant du nœud contextuel
- child::text() tous les nœuds textuels du nœud contextuel
- child::node() tous les enfants du nœud contextuel, quelque soit leur type
- attribute::name l'attribut name du nœud contextuel
- attribute::* tous les attributs du nœud contextuel
- descendant:: repertoire tous les descendants <repertoire> du nœud contextuel
- ancestor::fichier tous les ancêtres <fichier> du nœud contextuel
- ancestor-or-self::fichier
tous les ancêtres <fichier> du nœud contextuel et le nœud
contextuel lui-même si c'est un <fichier>
- descendant-or-self::repertoire
tous les descendants <repertoire> du nœud contextuel et le
nœud contextuel lui-même si c'est un <repertoire>

- self::repertoire le nœud contextuel si c'est un élément <repertoire>, et rien

dans le cas contraire
- child::*/child::repertoire
tous les petits enfants <repertoire> du noeud contextuel
- /descendant:: repertoire
tous les éléments <repertoire> descendants du document
contenant le nœud contexuel
Quand cela est possible, c'est à dire dans les cas simples, préférez l'écriture abrégée
associée
- self::node() .
- parent::node() ..
- child::nom nom
- attribute::nom @nom
- /descendant-or-self::node() //
3. LES LIENS XML: XLINK ET XPOINTER

Il existe deux types de liens XML:
• le lien XLink permet de relier des ressources entre elles,
• le lien XPointer permet de mettre en oeuvre un mécanisme d'adressage dans une
structure de document.
Les liens XML offrent les possibilités suivantes :
• faire référence à des fragments d'un document sans être obligé d'y insérer quelques
informations que ce soit,
• créer des liens ayant plusieurs cibles,
• créer des liens typés,
• créer des liens vers des positions absolues ou relatives (les pointeurs),
3.1 LES LIENS XLINK

XLink est le résultat d’une volonté d’obtenir des outils de liaisons entre deux documents
XML, plus puissants que ceux de HTML.
Xlink définit deux types de liens :
- Liens simples associant deux ressources, donc compatibles HTML : ces liens
sont de type unidirectionnel ;
- Liens étendus, associant plus de deux ressources : ces liens peuvent être bi-
directionnels, multi-directionnels et externes aux ressources liées.
Xlink ne définit pas la façon de traiter ces liens. Ce sont les applications, qui exploitent ces
liens, qui devront en définir le rendu.
3.1.1 Les liens simples
Les liens simples sont des liens associant exactement deux ressources dont l’une est locale et
l’autre est distante.
Xlink permet de décrire le comportement du lien au travers d’attributs facultatifs :
xlink :show={"replace" | "new"| "embed"}
- replace la cible du lien remplace le contenu actuel
- new ouverture d’une nouvelle instance pour afficher la cible du lien

- embed la cible du lien est incluse dans le document actuel

xlink :actuate={"onRequest" | "onLoad"}
- onRequest lien traversé lors d’une demande explicite (Lien HTML)
- onLoad lien traversé au chargement du document (image HTML)
Lien Type HTML
<descriptif xmlns :xlink = http://www.w3.org/1999/xlink/
xlink :type= "simple"
xlink :href="XDV Detail.xml"
xlink :title="Descriptif détaillé"
Descriptif détaillé du cours XDV
</descriptif>
Lien type référencement d’image
<image xmlns : xlink = http://www.w3.org/1999/xlink/
xlink :type= "simple"
xlink :href= "images/logo.gif"
xlink :show= "embed"
xlink :actuate= "onLoad"/>
3.1.1 Les liens étendus
Un lien étendu est un lien qui associe un nombre arbitraire de ressources. Ces ressources
pouvant être locales ou distantes.
Exemple :
<go xlink : type= « arc» xlink:from= "A" xlink:to= "B" />
• Un lien étendu est représenté par plusieurs éléments XML avec des rôles qui peuvent être
différents :
- xlink:type="locator" décrit les ressources éloignées participant dans la liaison
- xlink:type="ressource" décrit les ressources locales qui participent à la liaison
- xlink:type="arc" décrit les règles de parcours entre les ressources
- xlink:type="title" décrit de manière lisible la liaison
• La cible du lien est distante car elle est située en dehors de celui-ci, que ce soit dans le même
document ou non.
Un lien en ligne possède au moins une ressource locale.
Un lien hors ligne (out-of-line) n'a aucun élément local.
• C'est la puissance des liens XML, permettant de lier des ressources dans un document
externe et qui permet par exemple :
- L'ajout de lien de et vers des documents en lecture seule
- Plusieurs enchaînements d'un même diaporama
- Page de synthèse de l'actualité provenant des différents sites
Pour définir un lien étendu, il faut définir
• La ressource interne au document qui définit ce lien
- xlink :type="ressource" décrit les ressources locales qui participent à la liaison
- xlink:label="nomlabel" identifiant nommé de la ressource locale
• La localisation de chacune des ressources associées à ce lien

- xlink: type=" locator" décrit les ressources locales qui participent à la liaison
- xlink:href="URI' URI de la ressource liée
- xlink:label="nomlabel" identifiant nommé de la ressource locale
• L'association entre source et destination
- xlink:type="arc" décrit les ressources locales qui participent à la liaison
- xlink:from="nomiabel" identifiant nommé du départ du lien
- xlink:to="nomiabel" identifiant nommé de l'arrivé du lien
Un lien en ligne possède au moins une ressource locale.
Association en ligne des URI des sites FAQ XML
<faq-xml xmlns:xlink=http://www.w3.org/1999/xlink/namespace/
xlink:type="extended"
xlink:title="Liens vers les sites FAQ XML étrangers">
<nomlien xlink:type="resource"
xlink:label="local">
Sites FAQ XML
</nomlien>
<site xlink:type="local"
xlink:href=http://www.xml.fr/FAQ.xml
xlink:label="fr"
xlink:title="Version française"/>
xlink:href=http://www.xml.us/FAQ.xml
xlink:label="us"
xlink:title="Version américaine"/>
xlink:href=http://www.xml.ca/FAQ.xml
xlink:label="ca"
xlink:title="Version canadienne"/>
<site xlink:type="arc"
xlink :from="local"
xlink:to="fr"/>
xlink :from="local"
xlink:to="us"/>
xlink :from="local"
xlink:to="ca"/>
</faq-xml>
Les valeurs pour la description du lien, xlink :from et xlink :to doivent être des labels
Exemple de définition de lien étendu hors ligne
Fichier de lien externe
<doc_base
xmlns:xlink=http://www.w3.org/1999/xlink
xlink:type="extended">
<doc
xlink:type="locator"
xlink:href="mondoc.xml"

xlink:label="label_doc">
</doc>
<base
xlink:type="locator"
xlink:href="mabase.xml"
xlink:label="label_base">
</base>
<loadbase
xlink:type="arc"
xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase"
xlink:from="label_doc"
xlink:to="label_base"
</loadbase>
</doc_base>
3.2. LES POINTEURS XML: XPOINTER

En plus de la notation offerte par XPath, il y a différentes façons de repérer un emplacement
au sein d'un document XML. Un pointeur est constitué d'une référence absolue suivie ou non
d'une série de renvois relatifs.
Les références absolues
La référence absolue est indiquée par le préfixe # ou |. Elle peut prendre les valeurs suivantes :
• root() : la racine du document
• origin() : le document en cours. Cette référence doit être suivie d'autres références.
• id(valeur) : l'élément dont l'attribut de type ID à la valeur indiquée.
Les références relatives
La référence relative suit une référence absolue et elle en est séparée par un point (.).C'est une
expression XPath.
Exemple : Lien sur le document en cours
#id ("XML") .child (1, session) renvoie la 1ère occurrence de l'élément session situé sous
l'élément identifié par "XML". L'élément session doit
être un élément de niveau immédiatement inférieur.
#id ("XML") .descendant (1, session) renvoie la 1ère occurrence de l'élément session situé à
un niveau quelconque sous l'élément identifié par
"XML"
#root () .string (1, "XML") renvoie la 1ère occurrence contenant la chaîne de caractère
"XML"
#root () .string (1, "XML") .following (l, session) renvoie la 1 ère occurrence de session
qui suit l'élément contenant la chaîne de caractère
"XML"
Exemple : Lien sur un autre document :
http://monsite.fr/page.xml#id("XML").child(l,session)
http://monsite.fr/page.xml|id("XML").child(l,session)

Chapitre 4: Les Feuilles de style
CHAPITRE 4 : LES FEUILLES DE STYLE
1. LES FEUILLES DE STYLES: XSL ET CSS

XSL (eXtended Stylesheet Language) et CSS (Cascading StyleSheets) sont deux outils
apparemment redondants mais en réalité très complémentaires.
CSS est apparu en 1997 et proposait de dissocier la mise en page du contenu du document
HTML. Il introduisait entre autres, dans la version 2, la notion de type de média permettant de
gérer des mises en pages différentes en fonction du média (imprimante, écran, ...). Par contre
elle n'est supportée que par les dernières versions des navigateurs.
XSL est le format de feuille de style défini pour les documents HTML. Il offre des
fonctionnalités similaires à CSS en y ajoutant d'autres fonctionnalités dont la transformation
de données. Malheureusement XSL n'est pas encore totalement supporté par les navigateurs, y
compris les dernières versions.
De fait aujourd'hui, si l'on souhaite malgré tout utiliser les feuilles de styles XSL sans pour
autant être contraint par les limites des navigateurs actuels, il est possible d'opérer la mise en
forme sur le serveur et de générer un document au format HTML qui sera envoyé au
navigateur.
2. XSL
2.1. PRESENTATION
XSL est une famille de spécifications comprenant :
o XSLT (XSL Transformation) pour le parcours et la transformation d'un document
source XML vers un autre document XML,
o X-Path et les patterns pour la navigation dans l'arbre XML source,
o XSL-FO (XSL Formatting objects) pour décrire la présentation d'un document.
Au départ, il n'y avait pas cette séparation, et c'est pourquoi le terme générique XSL désigne
aussi bien la phase de transformation que celle de formatage.
2.2. XSL ET LE W3C

XSLT 1.0 et XPATH 1.0 ont un statut de recommandation du 16 Novembre 1999, dont les
spécifications sont disponibles à :
http://www.w3.org/TR/1999/REC-xslt-19991116
http://www.w3.org/TR/1999/REC-xpath-19991116
XSL, qui contient la partie XSL-FO, a un statut de recommandation du 21 Novembre 2000,
dont les spécifications sont disponibles à :
http://www.w3.org/TR/2001/REC-xsl-20011015
La feuille XSL est donc la feuille de style associée au document XML. Elle contient les règles
de transformation, de présentation et de mise en forme des données.
La feuille XSL intègre des fonctionnalités plus puissantes que la feuille de style CSS. Elle
permet en effet de préciser des règles d'enchaînements, des conditions, des calculs, etc. .

3. XSLT: LA TRANSFORMATION
XSLT (XML Stylesheet Language Transformation) a pour objectif de définir un langage pour
effectuer des transformations sur des arbres XML.
La transformation produit en sortie un fichier XML de préférence XHTM, WML, SVG, ...
Elle s'applique sur un arbre XML provenant :
- d'un fichier XML,
- d'un message (flux) XML.
XSLT permet de gérer, a partir d'une source unique d'informations, des fichiers adaptés aux
différents canaux de visualisation (PC, Mobile, WebTV, … )
Feuille Fichier
XSLT HTML
Processeur
XSLT
Fichier
Flux XML
WML
XSL permet de réaliser différentes opérations telles que :

- Remplacement de balise
- Numérotation automatique (liste, chapitre, page, etc.)
- Génération automatique de table de matières, d'index, etc.
- Définition de macros
- Recherche et sélection d'éléments dans un document
- Ajout de chaînes de caractères
- Application de mise en forme paramétrée
- Etc.
3.1. DOCUMENT REGULIER VERSUS DOCUMENT NON REGULIER

Nous pouvons distinguer, de part leur nature et leur traitement spécifique en XSLT, la notion
de document régulier ou non régulier.
Les documents XML réguliers :
- Leur structure est la répétition d'un élément type
- La profondeur de l'arbre est déterminée
Les documents XML non réguliers
- Leur structure est constituée d'une imbrication arbitraire d'un ensemble d'éléments
- La profondeur de l'arbre est inconnue
3.1.1 Document régulier
Voici un exemple de fichier XSLT produisant en sortie un document HTML 4.0

< ?xml version = « 1.0 » encoding = « ISO-8859-1 » ?>

<xsl :stylesheet version = « 1.0 » xmlns= http://www.w3.org/1999/XSL/Transform>
<xsl :output method=« html» version=« 4.0 » encoding=« ISO-8859-1» indent=« yes »/>
<xsl :template match= « / »>
<html>
<head>
</head>
<body>
<table>
<xsl :for-each select= « cartes/personne »>
<tr>
<td>
<xsl :value-of select= « nom »/>
</td>
<td>
<xsl :value-of select = « .//pays »/>
</td>
</tr>
</xsl : for-each>
</table>
</body>
</html>
</xsl :template>
</xsl :stylesheet>
Voici un exemple de fichier XML sur lequel va être appliqué un processus de
transformation, au travers de la référence à la feuille de style XSLT

<?xsl:stylesheet type="text/xsl" href="cartes.xslt"?>
<cartes>
<personne>
<nom>Mkadmi</nom>
<prenom>Abderrazak</prenom>
<bureau>
<adresse>
<code_postal>93526</code_postal>
<pays>France</pays>
</adresse>
<telephone>(33)149406789</telephone>
<fax>(33)14558787865</fax>
</bureau>
</personne>
<personne>
<nom>SALEH</nom>
<prenom>Imad</prenom>
<bureau>

<adresse>
<code_postal>93526</code_postal>
<pays>France</pays>
</adresse>
<telephone>(33)149406789</telephone>
<fax>(33)14558787865</fax>
</bureau>
</personne>
</cartes>
Voici un exemple de fichier HTML généré par la transformation

<html>
<head>
<META http-equiv= « Content-Type » content = « text/html ; charset=UTF-16 »>
</head>
<body>
<table>
<tr>
<td>MKADMI</td>
<td>Abderrazak</td>
<td>France</td>
</tr>
<tr>
<td>SALEH</td>
<td>Imad</td>
<td>France</td>
</tr>
</table>
</body>
</html>
Voici le résultat dans le navigateur
MKADMI Abderrazak France

SALEH Imad France

3.1.2 Document non régulier

Voici un exemple de fichier XSLT produisant en sortie un document HTML 4.0
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<html>
<head />
<xsl:apply-templates/>
</html>
</xsl:template>
<xsl:template match="racine">
<body bgcolor="silver">
<table>
</table>
</body>
</xsl:template>
<xsl:template match="repertoire">
<tr>
<td valign="top">Repertoire : </td>
<td>
<xsl:value-of select="@nom"/>
<table>
</table>
</td>
</tr>
</xsl:template>
<xsl:template match="fichier">
<tr>
<td valign="top">Fichier : </td>
<td>
<xsl:value-of select="@nom"/>
</td>
</tr>
</xsl:template>
</xsl:stylesheet>
Voici un exemple de fichier XML sur lequel va être appliqué un processus de

transformation, au travers de la référence à la feuille de style XSLT
< ?xml-stylesheet type="text/xsl" href="repertoire.xslt" ?>
<racine>
<repertoire nom="XML" date_modif="25-02-2001" heure_modif="14:12">
ressources XML (exemples, outils, spécifications, ...)
<repertoire nom="exemples" date_modif="25-02-2001" heure_modif="14:14">
</repertoire>
<fichier nom="séminaire.xml" taille="2" unite_taille="ko" date_modif="12-02-
2001" heure_modif="14:12">

Description XML du cours CXML

</fichier>
<fichier nom="XMLSPY.xml" taille="2" unite_taille="ko" date_modif="12-02-
2001" heure_modif="15:12"/>
</repertoire>
<repertoire nom="Schema" date_modif="19-02-2001" heure_modif="14:12">
<repertoire nom="DTD" date_modif="19-02-2001" heure_modif="15:12">
<fichier nom="XMLSPY.exe" taille="8" unite_taille="Mo" date_modif="28-01-
2001" heure_modif="12:12">
Version d'évaluation
</fichier>
<fichier nom="cooktop.msi" taille="4" unite_taille="Mo" date_modif="21-02-2001"
CookTop (éditeur XML, XSLT, DTD) gratuit au format MS
</fichier>
</repertoire>
<repertoire nom="XML Schema" date_modif="25-02-2001" heure_modif="16:09"/>
</repertoire>
<fichier nom="ebXML.pdf" taille="246" unite_taille="KO" date_modif="24-03-2001"
Spécifications ebXML
</fichier>
</racine>
Voici le résultat sur le navigateur
Repertoire : XML
ressources XML (exemples, outils,
spécifications, ...)
Repertoire : exemples
Fichier : séminaire.xml
Fichier : XMLSPY.xml
Repertoire : outils
Repertoire : Schema
Repertoire : DTD
Repertoire : outils
Fichier : XMLSPY.exe
Fichier : cooktop.msi
Repertoire : XML Schema
Fichier : ebXML.pdf

3.2. LE DOCUMENT XSLT ET SON REFERENCEMENT

Une feuille de style XSLT est un document XML qui commence par l'en-tête XML délimitée
par : <xsl:stylesheet> ... </xsl:stylesheet>
Comme IE5 est basé sur le Working Draft de XSL, certaines incompatibilités avec la
recommandation peuvent être rencontrées (pas de règles implicites, extensions propres à
Microsoft) et le référencement en est différent.
- pour MSXML 3 ou 4 (IE6) ou les autres outils répondant à la recommandation
<xsl :stylesheet version = « 1.0 »
xmlns :xsl = « http://www.w3.org/1999/XSL/Transform » >
….
</xsl :stylesheet>
- pour IE5 sans mise à jour de MSXML (1 ou 2)
<xsl :stylesheet xmlns :xsl = « http://www.w3.org/TR/WD-XSL» >
….
</xsl :stylesheet>
Une feuille de style XSLT peut-être associée à un document XML à l'aide d'une instruction de
traitement XML particulière
< ?xml-stylesheet… ?>
Les parseurs XML reconnaissent cette instruction et provoquent, lors du parsing du document
XML, l'appel du processeur de transformation s'il existe.
Exemple de référencement d’une feuille de style :
< ?xml-stylesheet type = « text/xsl » href = « cartes.xslt » ?>
Les parseurs XML reconnaissent cette instruction et provoquent, lors du parsing du document
XML, l’appel du processeur de transformation s’il existe.
3.3. LES REGLES DE TRANSFORMATION

Les feuilles de styles XSLT sont fondées sur des structures nommées modèles (templates). Un
template précise ce qui doit être recherché dans l'arbre source, et ce qui doit être placé dans
l'arbre résultat, la transformation.
<xsl:template> définit une règle de transformation
<xsl:template match= "expression">
instructions XSLT
éléments XML
texte littéral
</xsl: template >

Exemple de génération HTML

<xsl :template match = « / »>
<html>
<head>
</head>
<xsl :apply-templates/>
</html>
</xsl :template>
Tout ce qui n'est pas préfixé par <xsl : …>, est généré tel que dans l'arbre résultat, d'où le
processus de transformation.
Match est une expression de sélection de nœuds sur lesquels s'applique la règle. Elle peut-être
exprimée en XPath, dont voici quelques exemples :
/ racine du document
repertoire tous les éléments <repertoire>
* tous les nœuds de type éléments
repertoire fichier tous les éléments <repertoire> ou <fichier>
racine/fichier tous les éléments <fichier> avec <racine> comme parent
repertoire//fichier tous les éléments <fichier> avec <repertoire> comme ancêtre
@nom l'attribut nom du nœud (élément) courant
fichier/@nom l'attribut nom de l'élément <fichier>
fichier[@ nom="XML"] les éléments <fichier> dont l'attribut nom vaut "XML"
comment() les commentaires
text() les nœuds texte
node() les nœuds autres que racine(*)
3.4. SELECTION DE REGLE ET PARCOURS DE L'ARBRE

Le processeur de transformation recherche les règles qui correspondent au nœud courant
(match) et en cas de multiples règles, le processeur choisit la plus prioritaire.
La priorité est définie de manière explicite ou implicite
- Explicite grâce à l'attribut "priority" de l'élément <xsl:template>
- Implicite grâce à des priorités par défaut attribuées aux patterns
Les processeurs réagissent différemment si deux règles peuvent s'appliquer à un
nœud.
Le parcours de l'arbre est réalisé au travers de l'ordre <xsl:apply-templates> qui sélectionne
les descendants du nœud courant avec lesquels le traitement continue.
L'élément <xsl:apply-templates> permet de descendre dans l'arbre, en précisant au
processeur de traiter les éléments fils du nœud courant.
L'attribut select permet de décrire, comme l'attribut match de l'élément <xsl:template>, une
expression XPath afin de restreindre le traitement aux nœuds enfants. Sans attribut select, tous
les sous-éléments, les textes et commentaires sont sélectionnés.
L'élément <xsl:value-of select= "expression"> récupère la valeur d'un objet en entrée, pour
la renvoyer en sortie.
Les processeurs XSLT ont deux règles implicites pour garantir le parcours récursif de l'arbre
et la production des nœuds texte en l'absence de règle applicable à ce nœud.
Règles implicites

<xsl :template match = « * | / »>

<xsl :apply-templates/>
</xsl :template>
<xsl :template match = « text () « >

<xsl :value-of select = « . »/>
</xsl :template>
Ces règles implicites doivent être écrites explicitement pour les transformations basées sur
MSXML 1 &2 (WD).
3.5. LA GENERATION DE NOEUDS

Pour générer un élément et ses attributs, il faut utiliser les mots suivants :
• <xsl:element name="NomElement"> ... </xsl:element>
• <xsl:attribute name="NomAttribut">Valeur</xsl: attribut>
Pour générer les objets autres que les éléments XML, il faut utiliser les éléments suivants :
<xsl:pi> génération d'instruction de traitement
<xsl:comment> génération de commentaires
<xsl:text> génération de nœud de type texte
Par défaut, <xsl:text> préserve les espaces en sortie et permet de transformer ou non, en
fonction de l'attribut 'disable-output-escaping', les méta-caractères & et < en '&' et
'<'.
XSLT permet de copier un nœud de l'arbre source vers l'arbre destination par <xsl:copy>. Si
l'on référence un attribut, il y a copie de son nom et sa valeur.
Les attributs de l’élément et ses nœuds fils ne sont pas copiés implicitement.
3.6 FUSION DE FEUILLES DE STYLES

XSLT permet de traiter, comme pour les DTD et XML Schema, la modularisation des feuilles
de styles par deux techniques
- <xsl:import> pour importer une feuille de styles référencée par l'attribut
href="NomFeuilleDeStyle.xslt" pour spécifier l’URI de la feuille
<xsl:import> doit être en tête des instructions xsl après <xsl:stylesheet>
- <xsl:include > pour inclure, à l'endroit où cette instruction apparaît, la feuille de style
référencée par l'attribut
href=" Nom FeuilleDeStyle.xslt" pour spécifier l’URI de la feuille
<xsl:include> peut être n'importe où au premier niveau, mais après <xsl:import>
3.7. FORMAT DE SORTIE

XSLT permet de spécifier le format de sortie pour le document produit par le processeur
<xsl:output > avec comme attributs :
- method = "xml" | "html" | "text" pour l'interprétation de l'arbre résultat
- version="valeur"
- encoding ="CodeCaractères" pour le jeu de caractères utilisé
- omit-xml-declaration = "yes" | "no" pour générer en xml la déclaration

- standalone = "yes" | "no" pour l'attribut dans la déclaration xml

- doctype-public = "FPIFichierDTD" pour générer une instruction
<!DOCTYPE ... PUBLIC "FPIFichierDTD">
- doctype-system = "URIFichierDTD" pour générer une instruction
<!DOCTYPE SYSTEM "URIFichierDTD">
- cdata-section-elements = "NomElements" pour générer une section CDATA
- indent = "yes" |"no" pour l'indentation de l'arbre (traitement optionnel)
Pour l'attribut method, voici les correspondances :
- xml : les caractères tels que &, &It; sont générés tels que, en sortie
- html : pour du HTML classique avec la possibilité de générer'<' pour
javascript sans le remplacer par l'entité &It;
- text: seules les valeurs chaînes de l'arbre sont générées.
3-8 RECAPITULATION (PARTIELLE) DES ELEMENTS DE BASE DE LA

SYNTAXE XSLT4
Une feuille de style XSL est un document XML dont l'élément racine est xsl:stylesheet
stipule ce qui doit être produit en sortie pour tout élément du
document XML qui correspondrait au critère indiqué par
l'attribut match. Ce qui se trouve entre la balise d'ouverture
et la balise de fermeture de l'élément xsl:template servira à
Règles "chablon" produire la sortie correspondant l'élément XML qui aura
<xsl:template match="Critère"> satisfait au critère indiqué.
...
Le critère peut être plus ou moins précis et correspond à un sous-
</xsl:template>
ensemble de la spécification XPath.
Si l'élément auquel s'applique ce chablon contient des sous-
éléments qui doivent eux aussi être traités, il faudra imbriquer une
règle xsl:apply-templates à l'intérieur de l'élément xsl:template.
stipule que toutes les règles portant sur des sous-éléments de

<xsl:apply-templates />
l'élément courant doivent être appliquées.
stipule que, parmi les règles portant sur des sous-éléments
<xsl:apply-templates de l'élément courant, seules doivent être appliquées celles
select="Critère" /> qui portent sur les sous-éléments correspondants au critère
indiqué.
permet une itération sur tous les éléments satisfaisant le
<xsl:for-each select="Critère">
critère indiqué. Le contenu de l'élément xsl:for-each doit
...
stipuler ce qui doit être produit pour chaque occurrence
</xsl:for-each>
d'éléments sélectionnés.
produit en sortie le contenu de l'élément stipulé par le
critére. Si l'attribut select est omis, c'est l'élément courant qui
<xsl:value-of select="Critère" />
est utilisé. xsl:value-of est généralement utilisé quand le
contenu de l'élément sélectionné est du texte simple.
<xsl:copy> produit en sortie un élément de nom identique à l'élément
4
Bertrand Ibrahim. – Introduction à XML. - http://cui.unige.ch/eao/www/xml/Plan.html

... courant, mais sans y mettre encore de contenu ou d'attributs.

</xsl:copy> Le contenu de l'élément xsl:copy doit donc stipuler comment
le contenu de l'élément de sortie doit être "rempli". Cela sera
typiquement fait avec <xsl:apply-templates />
Cet élément est pratique à utiliser quand on utilise dans le
document XML des éléments dont le nom correspond à des
balises HTML.
<xsl:if
exécute les règles imbriquées dans l'élément xsl:if
test="ExpressionBooléenne">
uniquement si l'expression booléenne fournie est évaluée à
...
vrai.
</xsl:if>
<xsl:choose>
<xsl:when test="ExpressionBoo
léenne">
...
</xsl:when>
<xsl:when test="ExpressionBoo fonctionne d'une manière similaire au xsl:if, mais permet de
léenne"> tester plusieures conditions et de prévoir une alternative
... quand toutes les conditions échouent.
</xsl:when>
<xsl:otherwise>
...
</xsl:otherwise>
</xsl:choose>
<xsl:element
produit en sortie un élément du nom indiqué par l'attribut
name="NomElementSortie">
name. Des éléments xsl:attribute peuvent être imbriqués pour
...
ajouter des attributs à l'élément produit en sortie.
</xsl:element>
<xsl:attribute produit en sortie un attribut qui sera inséré dans l'élément de

name="NomAttribut"> sortie courant. Le contenu de l'élément xsl:attribute servira à
... définir la valeur que prendra l'attribut produit en sortie.
</xsl:attribute> Un contenu typique de l'élément xsl:attribute est <xsl:value-of />
produit en sortie un élément du nom indiqué avec un attribut

dont la valeur sera le résultat de l'expression fournie. Le
contenu de l'élément d'entrée servira à définir le contenu de
l'élément de sortie.
Eléments de résultat litéraux: Cette notation correspond à un raccourci d'écriture. Elle est
équivalente à:
<NomElement
NomAttribut="{UneExpression}"> <xsl:element name="NomElement">
... <xsl:attribute name="NomAttribut">
</NomElement> <xsl:value-of select="UneExpression" />
</xsl:attribute>
...
</xsl:element>
Dans cet exemple, UneExpression peut être par exemple le nom

d'un sous-élément de l'élément courant ou le signe @ suivi du

nom d'un attribut de l'élément courant.
généralement imbriqué dans un xsl:apply-templates ou un

xsl:for-each, trie les éléments concernés avant de les traiter,
<xsl:sort select="Critère" plutôt que de les traiter dans l'ordre d'apparition dans le
order=...> document XML.
L'attribut order doit valoir "ascending" ou "descending"
4. XSL-FO: LE FORMATAGE
XSL-FO (XML Stylesheet Language Formatting Objects) a pour objectif de définir un
langage pour formater les données.
Il s'agit d'une application XML permettant de décrire la mise en page des données en sortie de
traitement. Le formatage permet de décrire une mise en page en vue d'une génération vers :
Navigateur, PDF, RTF, PostScript,....
Pour l'instant, il existe des outils qui permettent de générer un fichier au format PDF ou RTF,
à partir du document XML : pour le PDF, l'application FOP de James Tauber disponible sur le
site : http://xml.apache.org/fop/
Pour le RTF, l'application jfor disponible sur le site : http://www.jfor.org/
Flux XML
XSL-FO
Processeur
XSLT
Feuille
XSLT Feuille
RTF
Processeur
FO Feuille
PDF
4.1 XSL-FO PAR L’EXEMPLE

Voici un exemple de fichier XSL-FO et la visualisation du fichier PDF résultat, produit par
FOP
Exemple de document XSL-FO produit par une feuille de style XSLT sur un document
XML
<fo :root xmlns :fo=http://www.w3.org/XSL/Format/1.0>
<fo :layout-master-set>
<fo :simple-page-master page-master-name="only">
<fo :region-body/>
</fo :simple-page-master>
</fo :layout-master-set>
<fo :page-sequence>

<fo :sequence-specification>
<fo :sequence-specifier-single page-master-name="only"/>
</fo :sequence-specification>
<fo :flow>
<fo :block font-size="20pt" font-family="serif">
Hydrogen
</fo :block>
<fo :block font-size="20pt" font-family="serif">
Helium
</fo :block>
</fo :flow>
</fo :page-sequence>
</fo :root>
Hydrogen
Helium

Chapitre 5: Le modèle de document
CHAPITRE 5 : LE MODELE DE DOCUMENT
1. INTRODUCTION
Le Modèle Objet de Document (DOM) est une interface de programmation d'applications
(API) pour des documents HTML et XML. Il définit la structure logique des documents et la
manière dont un document est accédé et manipulé.
Dans la spécification DOM, le terme "document" est utilisé au sens large - XML est de plus
en plus utilisé pour représenter tout type d'informations stockées sur tout type de systèmes. La
plupart d'entre elles auraient été traditionnellement vues comme des données plutôt que des
documents. Cependant, XML représente ces données comme des documents, et DOM peut
être utilisé pour gérer ces données.
Avec le Modèle Objet de Document, les programmeurs peuvent construire des documents,
naviguer dans leur structure, et ajouter, modifier, ou supprimer soit des éléments, soit du
contenu. Tout ce qui peut être trouvé dans un document HTML ou XML peut être accédé,
changé, détruit, ou ajouté en utilisant le Modèle Objet de Document,
Le DOM fournit une interface de programmation objet (API) indépendante des langages de
programmation, de sorte que des implémentations DOM puissent être écrites dans le langage
de votre choix.
Le DOM est en général ajouté comme couche intermédiaire entre le parseur XML et
l’application qui a besoin des Informations du document. Le parseur lit les données du
document XML, les transmet à un DOM qui va être utilisé par une application de plus haut
niveau.
Application
DOM
Parseur XML
< -- >
_____
_____
Document XML
Les spécifications existent en 2 versions,

• DOM level 1
- Core : interface de base et leurs applications aux documents XML
- HTML: interfaces applicables aux documents HTML (HTML 4)

• DOM level 2
- Complète la version Core pour la gestion des espaces de noms
- DOM CSS : prise en charge des feuilles de style
- DOM Events : Modèle d'événements
- DOM Filters and Iterators : filtrage d'éléments et traitements itératifs
- DOM Range : isoler et traiter des fragments de documents.
2. LE DOM ET LE W3C
Le W3C gère les spécifications liées au DOM
• DOM level 1 a un statut de recommandation du 01 Octobre 1998, dont les spécifications
sont disponibles à:
http://www.w3.org/1998/REC-DOM-Level-1-19981001
• DOM level 2 Core, Views, Style, Event et Range ont un statut de recommandation du 13
Novembre 2000, dont les spécifications sont disponibles à: http://www.w3.org/2000/REC-
DOM-Level-2-Core-20001113
http://www.w3.org/TR/2000/REC-DOM-Level-2-Views-20001113
http://www.w3.org/TR/2000/REC-DOM-Level-2-Slyle-20001113
http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113
http://www.w3.org/TR/2000/REC-DOM-Level-2-Traversal-Range-20001113
• DOM level 3 est au statut de Working Draft.
3. LA PROGRAMMATION DU DOM
DOM représente un document XML comme un arbre d'objets, chaque noeud est un type
dérivé de type Node.
• Offre les méthodes nécessaires au parcours et construction de l'arbre.
La racine de l'arbre est de type Document
• Accès au type de document et sa DTD
• Offre les méthodes nécessaires à la création des différents types d'éléments
• Contient un seul objet fils de type Element qui est la racine du document
Chaque élément est de type Element
• Accès au nom de l'élément
• Offre les méthodes nécessaires au traitement des attributs
• Accès aux éléments fils par leur non
Une liste de nœuds de type NodeList
• Récupération de la taille de la liste et accès à chaque nœud
Les nœuds de type Text, Comment et CDATASection dérive du type CharacterData
• Offre les méthodes nécessaires aux traitements des chaînes de caractères
Les attributs sont du type Attr, qui n'appartiennent pas à l'arbre DOM, mais sont liés aux
éléments
• Récupération du nom et de la valeur

Il existe une interface d'accès à une collection de nœud d'après un nom unique, c'est le type
NamedNodeMap
• Offre les méthodes nécessaires à la lecture, écriture et suppression
Les autres types de nœuds sont :
• Entity pour une entité générale
• EntityReference pour une référence à une entité dans une donnée XML
• Processinglnstruction pour représenter les instructions de traitement.
La spécification DOM ne propose pas de méthode pour :
- charger en un document XML sous forme de représentation mémoire DOM,
- sauvegarder une représentation mémoire DOM sous forme de document XML,
- méthode pour générer un document à partir d’un arbre XML et d’un arbre
XSLT.
Les interfaces des langages et outils en proposent.
Exemple de chargement en mémoire d’un document XML dans IE5
Création mémoire d’un document XML et XSLT dans IE5
var sourceXML = "arboSPY-Deplier.xml" ;
var styleXSLT = "arboSPYdeplie.xslt" ;
source = new ActiveXObject ("Microsoft.XMLDOM") ;

style = new ActiveXObject ("Microsoft.XMLDOM") ;
source.async = false ;
style.async = false ;
source.load (sourceXML) ;
style.load (styleXSLT) ;
Exemple de chargement de mémoire d’un document XML dans IE5
Génération d’un document HTML à partir d’un arbre XML et d’un arbre XSLT dans IE5
If ( ! style.documentElement)
htmlCode = "Feuille de style incorrecte (" + source.parseError.reason + ")" ;
elseif ( ! source.documentElement)
htmlCode = "Document XML incorrect (" + source.parseError.reason +")" ;
else
htmlCode = source.transformNode (style) ;
with (parent.resultat.document)
{
open() ;
write (htmlCode) ;
close () ;
}
4. INTERFACE SAX
SAX (Simple API for XML) est une recommandation de fait (plutôt qu’être une spécification
développée par un organisme de standardisation, il s’agit du fruit de la collaboration de
développeurs de parseurs XML, autour d'un groupe de discussion sur internet (Celle liste de
diffusion est nommée XML-Dev). Son objectif est de fournir une API simple et standard pour
accéder au contenu d'un document.

Contrairement à DOM, elle est basée sur une approche événementielle, et une lecture
séquentielle du document XML :
• On trouve des notions de début et fin de document, d'élément, d'attribut,
• Permet de récupérer les informations lues par le parseur XML.
SAX, contrairement à DOM, n'implémente pas d'arbre en mémoire, donc orienté traitement de
gros document XML.
Les spécifications de SAX, qui ne sont pas gérés par le W3C sont disponibles
http://www.megginson.com///SAX/index.html
Il existe deux versions de SAX :
• SAXI (11 Mai 1998) supportée par tous les parseurs XML en Java, mais sans espaces de
noms,
• SAX2 (05 Mai 2000), ajoute espaces de noms et configuration des parseurs SAX et son
utilisation en Java.
Exemple de programme SAX qui affiche le nom des balises ouvrantes et fermantes lors de
la lecture séquentielle d’un document XML
import org.xml.sax.Parser ;
import org.xml.sax.DocumentHandler ;
import org.xml.sax.helpers.ParserFactory ;
import org.xml.sax.HandlerBase;
import org.xml.sax.AttributeList;
public class MyHandler extends HandlerBase {

// création d’une classe contenant les méthodes associées aux événements
public void startElement (String name, AttributeList atts) {
System.out.println (“Début : “ + name);
}
public void endElement (String name) {
System.out.println (“Fin : “ + name);
}
}
public class SAXApp {
static final String parserClass = “com.microstar.xml.SAXDriver”;
public static void main (String args[])

throws Exception {
// création du parseur
Parser parser = ParserFactory.makeParser (parserClass);
// création d’un handler d’événement document
DocumentHandler handler = new MyHandler() ;
// enregistrer un listener pour ce handler
Parser.setDocumentHandler (handler) ;
For (int i = 0 ; i < args.length ; i++) {
Parser.parse (args[i]); // Lecture séquentielle du document
}
}
}

5. DOM VERSUS SAX

Souvent, les parseurs DOM sont basés sur des parseurs SAX qui sont chargés de
l’implémentation de l’arbre DOM en mémoire.
- SAX est une API de plus bas niveau, orienté évènementielle, donc
parfaitement bien adapté au gros document XML.
- L’approche DOM, voire XSLT, repose sur la manipulation d’arbre, nécessitant
l’instanciation de celui-ci avant tout traitement.
Le problème de SAX est qu’il n’est pas géré par le W3C, et que sur le site des spécifications
SAX, on ne trouve pas des spécifications mais des implémentations : SAX pour JAVA, SAX
pour Python, …

Chapitre 6: Les Formulaires XML
CHAPITRE 6 : FORMULAIRES XML : XFORMS

XForms représente la nouvelle génération de formulaires sur le Web, après les formulaires
HTML. L’idée est d’aller au-delà des formulairers HTML, et de séparer l'aspect interface
utilisateur et le modèle de données sous-jacent. En effet, le même composant de formulaire
peut avoir des représentations très différentes suivant le navigateur et la plateforme utilisés
pour "afficher" un document, permettant ainsi d'adapter la représentation aux caractéristiques
de la plateforme, qu’il s’agisse d’une feuille de papier ou d’un périphérique manuel (un
téléphone portable, par exemple).
1- XFORMS VS FORMULAIES HTML

Pour pouvoir faire cette comparaison, je vais essayer de présenter un formulaire HTML
pour voir à quoi ressemble –t-il et en quoi XForms diffère-t-il ?
<form name="form1" method="post" action="identifier.php">
<table>
<tr><td>Nom :<input name="nom" type="text" size="30"></td></tr>
<tr><td>Prénom :<input name="prenom" type="text" size="30"></td></tr>
<tr><td>Fonction :<input name="fonction" type="text" size="30"></td></tr>
<tr><td>Login :<input name="login" type="text" size="30"></td></tr>
<tr><td>Mot de passe :<input name="passe" type="password" size="30"></td></tr>
</table>
</form>
Selon cet exemple, on voit bien qu’un formulaire HTML respecte en général un schéma
qui contient trois types d’entrées encadrées par une balise FORM. ACTION renvoit au
script de traitement de ce formulaire. Ceci est parfait pour des ordinateurs de bureau, mais
pour des terminaux légers, exemple un portable, il serait impossible de répondre à une
telle question (en l’absence d’une interface texte). C’est seulement en séparant la
présentation du frontal, que ça serait possible de modifier la question selon le type de
terminal utilisé.
La spécification XForms vient répondre à cette question en définissant trois aspects
permettant de séparer clairement le but du formulaire de sa présentation : le modèle de
données, l'interface utilisateur et le protocole d'envoi.
2- XFORMS : COMPOSANTS
2-1 MODELE DE DONNEES

Le modèle de données est subdivisé en deux parties: les structures de données, d'une part,
et les extensions (contraintes, dépendances, calculs), de l'autre. Il définit des types de
données de manière très similaire au formalisme de schéma XML : String, Boolean,
Number, Monetary Values, Date, Time of Day, Duration, URI, Binary. Chaque type de
donnée a des "facettes" qui lui sont associées. Ces facettes représentent des détails du type
(p.ex. précision, format, valeur par défaut, masque, etc.) et sont fournies sous la forme soit
d'attributs, soit de sous-éléments. Par exemple:
<xform:string name="Nom" />

<xform:date name="DateParution" min="now" />
<xform:date name="DateNaissance" max="now"/>

Contrairement aux schémas XML pour lesquels, les facettes sont statiques, les facettes
XForms peuvent être dynamiques, et correspondre ainsi à des contraintes qui évoluent en
cours d'exécution (par ex. bornes inférieures et supérieures d'un élément de formulaire qui
changent en fonction de ce que l'utilisateur aura tapé dans d'autres champs).
Exemple
<xform:date name="HeureDepart" max="HeureArrivee" />

<xform:date name="HeureArrivee" min="HeureDepart" />
2-1-1 Données structurées

Types énumérés : Basés sur le type string, en énumérant la liste des valeurs possibles.
<xform:string name="nationalité" enum="closed">
<xform:value>Tunisien</value>
<xform:value>Français</value>
<xform:value>American</value>
</xform:string>
Structures hétérogènes : Permet de regrouper un certain nombre de champs pour former une
entité.
<xform:group name="client">
<xform:string name="Nom"/>
<xform:string name="rue"/>
<xform:string name="ville"/>
<xform:string name="pays"/>
<xform:string name="codePostal"/>
</xform:group>
Unions : Permet de déclarer différentes façons de fournir la même information. Exemple:
<xform:union name="genre">
<xform:string enum="closed">
<xform:value>féminin</value>
<xform:value>masculin</value>
</xform:string>
<xform:string enum="closed">
<xform:value>F</value>
<xform:value>M</value>
</xform:string>
</xform:union>
Variantes : Permet de déclarer des structures différentes en fonction de la valeur d'un champ.
<xform:switch name="address">
<xform:case locale="fr" condition="property(locale) is 'FR'">
<xform:string name="canton"/>
</xform:case>
<xform:case locale="us" condition="property(locale) is 'US'">
<xform:string name="street"/>
<xform:string name="city"/>

<xform:string name="state"/>
<xform:string name="zipCode"/>
</xform:case>
<xform:case locale="default">
<xform:string name="pays"/>
</xform:case>
</xform:switch>
Structures homogènes : Permet de répéter une structure en plusieurs exemplaires.
<xform:array name="auteurs" minOccurs="1" maxOccurs="unbounded">
<xform:string name="auteur" />
</xform:array>
2-1-2 Langage de contraintes dynamiques
Les contraintes dynamiques sont définies par des expressions faisant référence à divers
éléments du document. Ces éléments peuvent être référencés à l'aide de la notation définie
dans XPath. Pour éviter des problèmes dus à l'utilisation de caractères spéciaux, les opérateurs
utilisés dans les expressions sont des mots:
opérateur signification
not expr inverse le résultat de l'expression
le résultat sera le résultat de la première expression si
if cond then expr1 else expr2 la condition est vraie, sinon celui de la deuxième
expression
expr1 is expr2 retourne vrai si les deux expressions sont égales
retourne vrai si expr1 est une valeur comprise entre
expr2 et expr3. Les expressions doivent être du même
expr1 is within(expr2,expr3)
type de base (numérique, string, date, temps, valeur
monétaire)
expr1 is before expr2 expr1 est inférieure à expr2
expr1 is below expr2 idem
expr1 is after expr2 expr1 est supérieure à expr2
and, or et xor opérateurs booléens
plus, minus, times et over opérateurs arithmétiques
string1 plus string2 concaténation de chaînes de caractères
nombre% valeur divisée par 100
number(), sum(), floor(), ceiling(),
fonctions numériques
average(), min(), max()
string(), concat(), starts-with(),
contains(), substring-before(), substring-
fonctions de manipulation de chaînes de caractères
after(), substring(), string-length(),
normalize-space() et translate()
heure actuelle du système sous forme de chaîne de
now()
caractères
submit() envoi au serveur
2-2 INTERFACE UTILISATEUR

Cette section décrit les balises à utiliser pour décrire l'interface utilisateur, les propriétés de
style permettant la mise en page des éléments interactifs de formulaires, ainsi que le
mécanisme faisant le lien entre l'interface utilisateur et le modèle de données.
2-2-1 Eléments interactifs
Elément Catégorie Description
élément non modifiable par l'utilisateur et affichant une
output anyControl
valeur généralement calculée à partir d'autres éléments
élément de saisie de texte. Les attributs rows et cols
textbox anyNavControl
indiqueront les dimensions (en caractères).
checkbox anyNavControl case à cocher
élément de sélection simple contenant un élément <item
value="..."> pour chaque valeur possible. La propriété de
exclusiveSelect anyNavControl
style list-ui peut prendre une des valeurs radio, checkbox,
menu ou listbox pour définir l'apparence de l'élément
élément de sélection multiple contenant, comme l'élément
multipleSelect anyNavControl
exclusiveSelect, des éléments item.
élément permettant de lancer une action. L'attribut action
button anyNavControl
peut contenir une contrainte dynamique.
élément provoquant l'envoi des données du formulaire.
submit button
L'attribut action a pour valeur par défaut submit().
reset pas encore défini
suspend pas encore défini
D'autres éléments interactifs seront bientôt définis.
2-2-2 Eléments de mise en page
Elément Description
élément pouvant contenir d'autres éléments de formulaire. La propriété de style
layout indique la direction selon laquelle les éléments contenus sont répartis
groupbox (horizontal, vertical ou inherit). La propriété field-align indique l'emplacement
de l'étiquette (sous-élément <caption>) d'un élément par rapport à l'élément
interactif même (left, right, top, bottom, center, justify ou inherit).
2-3 LIENS ENTRE INTERFACE ET MODELE

Le lien entre éléments de l'interface et l'instance de données est réalisée à l'aide d'expressions
dans le langage de contraintes dynamiques.
Chaque élément interactif de formulaire peut avoir un attribut ref qui prend pour valeur une
expression dans le langage de contraintes dynamiques. Cet attribut indique quelle partie de
l'instance de données l'élément interactif définit.
Exemple:
<xform:textbox ref="EmpruntLivre/Emprunteur/NomFamille">
</xform:instance>

L'élément <xform:instance> sert à définir la valeur intiale de l'instance de données associée à

un formulaire. Ses sous-éléments devraient être modifiés par le logiciel employé par
l'utilisateur lorsque celui-ci interagit avec les éléments interactifs du formulaire.
S'il y a plusieurs formulaires indépendants dans le même document, l'élément <xform:xform
id="NomDuFormulaire"> permet de déclarer un formulaire et l'attribut xform:xform permet
d'associer un élément interactif à un formulaire déclaré. Exemple:
<xform:textbox xform:xform=ref="EmpruntLivre/Emprunteur/NomFamille">
<xform:xform id="b">
<xform:model>
...
</xform:model>
<xform:instance>
<EmpruntLivre>
<Emprunteur>
<NomFamille>...</NomFamille>
</Emprunteur>
</EmpruntLivre>
</xform:instance>
</xform:xform>
L'élément <xform:model> sert à définir le modèle de données associé à un formulaire, un peu
comme une déclaration de type dans un langage de programmation. Si une instance est
explicitement déclarée, elle doit être conforme au modèle associé au formulaire.
L'élément <xform:bind id="..." ref="..."> permet d'établir un lien entre modèle, instance et
interface lorsque ces différentes parties ne sont pas directement imbriquées dans le même
élément <xform:xform>.

Chapitre 7: XML et les bases de données
CHPITRE 7 : XML ET LES BASES DE DONNEES
1- INTRODUCTION
XML est devenu dans peu de temps le format standard de structuration et d’échange de
données le plus populaire. Ce métalangage est capable d’être le format du stockage, du
transport et d’affichage des données. Parallèlement, les bases de données relationnelles
constituaient depuis un bon moment et constituent toujours le moyen le plus utilisé pour le
stockage des données dans la plupart des entreprises, et ce pour leur capacité de mettre à
disposition d’un grand nombre d’utilisateurs des données avec un accès rapide et un bon
niveau de sécurité.
Les SGBDRs sont donc des outils qui s'adossent traditionnellement à un système de gestion
de base de données (SGBD) pour organiser les éléments d'information (fichiers, textes,
images, etc.) au sein d'une structure de tables liées entre-elles. Une galaxie de contenus
structurés qu'ils rendent accessibles depuis une application cliente par le biais de langages de
requêtes - exécutées via des interfaces (telles que ODBC et JDBC). Pour l'heure, le
vocabulaire le plus utilisé pour l'interrogation de bases de données demeure le langage SQL
(pour Structured Query language).
Avec la montée en puissance du XML, les éditeurs positionnés sur ce créneau tentent
d'évoluer : la plupart d'entre eux ont mis en place des mécanisme permettant d'intégrer à leur
produit des documents dans ce format. Certains ajoutant d'ores et déjà une couche de
structuration XML à leur référentiel propriétaire (c'est notamment le cas d'Oracle).
Aux côtés de ces acteurs traditionnels, plusieurs éditeurs proposent des applications XML
natives. Schématiquement, ce type d'outils s'articulent autour d'un référentiel de contenu qui
repose sur les briques du langage XML relatives à la description et à la structuration de
données (DTD, XML Schema, etc.). Côté logiciel client, les langages de requêtes qu'ils
supportent sont également décrits à l'aide de vocabulaires XML. Il s'agit principalement de
XQuery et de XPath.
Pour ces raisons et pour les avantages qu’offrent ces deux moyens, à savoir XML et les
SGBDs, plusieurs auteurs pensent que « l’utilisation combinée de ces deux méthodes offre
également au programmeur un grand nombre de possibilités. D’une part, les bases de
données relationnelles apportent une gestion et des fonctionnalités de sécurité fiables…
d’autre part, dans la mesure où le langage XML est composé uniquement de texte, il peut
facilement être transmis sur un réseau, et d’une plate-forme à l’autre… de plus, il peut
facilement être traduit d’un langage à l’autre»5.
Plusieurs raisons donc nous poussent à associer XML et les bases de données : stocker des
documents XML dans une base de données ou utiliser un contenu d’une base de données au
format XML :
- XML fournit une méthode de représentation des données structurées sans ajout
d’informations,
- XML permet la réutilisation des données par des systèmes d’héritage,
- XML peut être utilisé par des outils déjà disponibles (Feuilles de style : XSLT et
serveurs XML : ex : Biztalk…),
5
WILLIAMS, Kevin & BRUNDAGE, Michael & DENGLER, Patrick, et al. – XML et les bases de données. –
Eyrolles, 2001

- XML, en contenant les données et la structure, permet facilement la transmission et la

représentation des données,
- Les bases de données sont plus adaptées que XML pour des utilisations internes de
recherche.
Je vais essayer, à travers ce cours d’expliquer, à partir du livre « XML et les bases de
données » comment peut-on profiter des avantages de ces deux mondes.
2- CORRESPONDANCES ENTRE SGBDR ET XML

Avant de présenter le détail de différentes méthodes de convertir les tables de bases de
données relationnelles en documents XML, et vice versa, je vais essayer de présenter
brièvement qu’est ce que c’est un SGBD et qu’est ce qu’un langage SQL utilisé par ces
SGBDs.
2-1 SGBDR
Un SGBD représente un ensemble coordonné de logiciels qui permet de décrire, mémoriser,
manipuler, traiter les ensembles de données constituant la base. Il assure également la sécurité
et la confidentialité des données dans un environnement ou de nombreux utilisateurs ayant des
besoins variés peuvent interagir simultanément sur ces ensembles de données.
Un SGBDR est un logiciel supportant le modèle relationnel dont toute information de la base
de données est représentée par des valeurs dans des tables. Dans ce système, il n'y a pas de
pointeurs visibles par l'utilisateur entre les tables. De plus, un système dit relationnel doit
supporter les opérateurs relationnels de restriction, projection et jointure naturelle sans
limitations liées à des considérations internes telles que par exemple la jointure unique sur
attributs indexés.
Un SGBD est dit complètement relationnel si de plus il satisfait les deux conditions
suivantes :
- il réalise tous les opérateurs de base de l'algèbre relationnelle, sans restriction d'usage liée à
des contraintes internes,
- les deux contraintes d'intégrité de base du modèle relationnel doivent être supportées
d'unicité comme le numéro de sécurité social et la deuxième est la contrainte référentielle.
Un SGBD relationnel contient généralement:
- un langage commun de description et de manipulation des données,
- des commandes qui permettent le contrôle sémantique des données : gestion des vues
partielles, autorisation et contrôle d'accès, intégrité sémantique des valeurs de données,
- des instructions qui assurent la cohérence physique des données par la gestion des
transactions, des accès concurrents et des reprises sur pannes,
- des algorithmes internes qui gèrent les méthodes d'accès aux données ou encore qui
permettent des évaluations de la navigation,
- des utilisateurs, tels que générateurs de rapports, interfaces graphique, générateurs
d'application.
Les avantages principaux des systèmes de gestion de base de données sont résumés dans ce
qui suit :
Indépendance physique,
Indépendance logique,
Manipulation des données par des non informaticiens,

Efficacité d'accès aux données,

Administration centralisée des données,
Non redondance des données,
Cohérence des données,
Sécurité des données.
Cependant, ces SGBDs limités pour trois raisons essentielles :
- ils sont conçus pour gérer des données de gestion, c'est à dire structurées de manière
régulière, bien souvent sous forme de tables. Beaucoup de données ne peuvent donc
être gérées par un SGBD de la génération présente : c'est le cas des textes, des images,
des résultats de mesures…,
- les SGBD actuels ne permettent que de retrouver les données stockées dans la base. Ils
ne sont guère capables de raisonner afin de déduire à partir de données et de lois
générales connues, de nouvelles données,
- les SGBD actuels qui se disent de plus en plus "user friendly" - c'est à dire amis de
l'utilisateur- sont loin de présenter des interfaces simples, accessibles par des non
informaticiens.
2-2 LANGAGE SQL

SQL (Structured Query Language) est un langage de définition de données (LDD, ou en
anglais DDL Data Definition Language), un langage de manipulation de données (LMD, ou
en anglais DML, Data Manipulation Language), et un langage de contrôle de données (LCD,
ou en anglais DCL, Data Control Language), pour les bases de données relationnelles.
Le langage SQL permet donc de :
- créer des tables dans une base de données relationnelle, ainsi que d'en modifier ou en
supprimer.
- sélectionner, insérer, modifier ou supprimer des données dans une table d'une base de
données relationnelle.
- définir des permissions au niveau des utilisateurs d'une base de données. On parle de
DCL (Data Control Language).
2-3 XML VS SGBDR : STRUCTURE

Nous allons commencer par une modélisation des données provenant d’une base de données
relationnelle pour voir après les possibilités de les stocker dans un document XML.
Dans une base de données, il y a des différentes tables qui stockent chacune un ensemble de
données liées à une entité déterminée. Une table représentant une adresse postale d’une
personne par exemple peut être schématisée comme suit :
Prenom Nom Rue Ville Code_postal Pays
Abderrazak Mkadmi 18 rue la Antony 92160 France
fontaine
Cette table est créée, par le biais du langage SQL, comme suit :
Create table PERSONNE (Prenom VARCHAR(35), Nom VARCHAR (35), Rue VARCHAR
(35), Ville VARCHAR (35), Code_postal VARCHAR (9), Pays VARCHAR (35)) ;
Parallèlement, en XML, les données peuvent être regroupés dans un élément décrivant une

entité déterminée (exemple : adresse). Pour présenter par exemple l’entité présentée ci-dessus
dans une table d’une base de données, nous pouvons créer un élément « Personne » qui
contiendra toutes les données stockées dans la table « PERSONNE ».
XML permet deux moyens de représenter ces données : en utilisant des éléments ou des
attributs (comme c’est vu dans le cours précédant sur XML).
En utilisant des éléments, nous pouvons présenter l’élément « Personne » comme suit :
<Personne>
<Prenom>Abderrazak</Prenom>
<Nom>MKADMI</nom>
<Rue>18 rue la Fontaine</Rue>
<Ville>Antony</Ville>
<Code_postal>92160</Code_postal>
<Pays>France</Pays>
</Personne>
En utilisant des attributs, l’élément « Personne » peut être présenté comme suit :
<Personne
Prenom= »Abderrazak »
Nom= « MKADMI »
Rue= « 18 rue la Fontaine »
Ville= « Antony »
Code_postal= « 92160 »
Pays= « France »/>
2-4 XML VS SGBDR : RELATIONS

Dans une base de données relationnelle, une association entre deux entités d’informations est
assurée par une relation entre deux tables. Pour pouvoir présenter cette relation dans un
document XML, je vais d’abord présenter cette structure dans une base de donnée, à travers
ces deux tables :
Table : PROPRIETAIRE_MODELE
ID_Proprietaire Prenom_Owner Nom_Owner Tel_Owner Email_Owner Ville_Owner
Clé
primaire Clé
étrangère
Table : MODELEXML
ID_Modele Designation_Modele Version Date_Version Mots_Cles ID_Proprietaire
Le script qui permet de créer ces deux tables est le suivant :

CREATE TABLE PROPRIETAIRE (ID_Proprietaire BIGINT(100)
NOT NULL, Prenom_Owner VARCHAR(255) NOT NULL,
Nom_Owner VARCHAR(255) NOT NULL, Tel_Owner
VARCHAR (25) NOT NULL, Email_Owner VARCHAR (255),
Ville_Owner VARCHAR (35) PRIMARY KEY (ID_Proprietaire));
CREATE TABLE MODELEXML (ID_Modele BIGINT(100) NOT NULL ,

Designation_Modele VARCHAR(255)

NOT NULL, Version VARCHAR(255) NOT NULL,

Date_Version DATE NOT NULL, Mots_Cles TEXT,
ID_Proprietaire BIGINT (100), PRIMARY KEY (ID_Modele),
FOREIGN KEY (ID_Proprietaire) REFERENCES PROPRIETAIRE
(ID_Proprietaire));
En XML, cette association des deux tables peut être illustrée par une imbrication en
éléments fils de la table référence.
< !ELEMENT PROPRIETE_MODELE (MODELEXML+)
< !ATTLIST PROPRIETE_MODELE
Prenom_Owner CDATA #REQUIRED
Nom_Owner CDATA #REQUIRED
Tel_Owner CDATA #REQUIRED
Email_Owner CDATA #REQUIRED
Ville_Owner CDATA #REQUIRED>
<!ELEMENT MODELEXML EMPTY>
<!ATTLIST MODELEXML
Designation_Modele CDATA #REQUIRED
Version CDATA #REQUIRED
Date_Version CDATA #REQUIRED
Mots_Cles CDATA #REQUIRED
Ceci illustre bien les relations de type un à un ou un à plusieurs en XML.

Cependant, il y a des relations plus complexes (relation plusieurs à plusieurs par exemple) qui
peuvent être présentés à l’aide de pointeurs :

Table : PROPRIETAIRE_MODELE
ID_Proprietaire Prenom_Owner Nom_Owner Tel_Owner Email_Owner Ville_Owner
Clé
primaire Clé
étrangère
Table : MODELEXML
ID_Modele Designation_Modele Version ID_Organisation Mots_Cles ID_Proprietaire
Clé Primaire
Clé
étrangère
Table : ORGANISATION
ID_Organisation Nom_Org Acronyme_Org Tel_Org Site_Web_Org Ville_Org
Clé
primaire
Le script qui permet de créer cette troisième table est le suivant :

CREATE TABLE PROPRIETAIRE (ID_Proprietaire BIGINT(100)
NOT NULL, Prenom_Owner VARCHAR(255) NOT NULL,
Nom_Owner VARCHAR(255) NOT NULL, Tel_Owner
VARCHAR (25) NOT NULL, Email_Owner VARCHAR (255),
Ville_Owner VARCHAR (35), PRIMARY KEY (ID_Proprietaire));
CREATE TABLE ORGANISATION (ID-Organisation BIGINT (100)

NOT NULL, Nom_Org VARCHAR (35),
Acronyme_Org VARCHAR (35), Tel_Org VARCHAR (25),
Site_Web_Org VARCHAR (255), Ville_Org VARCHAR (255),
PRIMARY KEY (ID_Organisation));
CREATE TABLE MODELEXML (ID_Modele BIGINT(100) NOT NULL,

Designation_Modele VARCHAR(255)
NOT NULL, Version VARCHAR(255) NOT NULL,
Date_Version DATE NOT NULL, Mots_Cles TEXT,
ID_Proprietaire BIGINT (100), PRIMARY KEY (ID_Modele),
FOREIGN KEY (ID_Proprietaire) REFERENCES PROPRIETAIRE
(ID_Proprietaire), FOREIGN KEY (ID_Organisation) REFRENCES
ORGANISATION (ID_Organisation));
Pour présenter cette relation plus complexe en XML, nous pouvons créer le modèle de
données suivant :
< !ELEMENT DONNEES_MODELE (PROPRIETE, ORGANISATION+)
<!!ELEMENT PROPRIETE_MODELE (MODELEXML+)
< !ATTLIST PROPRIETE_MODELE
Prenom_Owner CDATA #REQUIRED
Nom_Owner CDATA #REQUIRED

Tel_Owner CDATA #REQUIRED

Email_Owner CDATA #REQUIRED
Ville_Owner CDATA #REQUIRED>
<!ELEMENT MODELEXML EMPTY>
<!ATTLIST MODELEXML
IDREFORGANISATION IDREF #REQUIRED
Designation_Modele CDATA #REQUIRED
Version CDATA #REQUIRED
Date_Version CDATA #REQUIRED
Mots_Cles CDATA #REQUIRED
<!ELEMENT ORGANISATION EMPTY
<!ATTLIST ORGANISATION
ID_Organisation ID #RQUIRED
Nom_Org CDATA #REQUIRED
Acronyme_Org CDATA #REQUIRED
Tel_Org CDATA #REQUIRED
Site_Web_Org CDATA #REQUIRED
Ville_Org CDATA #REQUIRED
3- EXPORTATION DES BASES DE DONNEES RELATIONNELLES VERS XML

Plusieurs raisons justifient l’étude des possibilités d’exporter des bases de données
relationnelles existantes vers XML. Il faut savoir tout d’abord que la plupart des entreprises
stockent actuellement leurs données commerciales dans des bases de données relationnelles.
Ces raisons sont résumées par les auteurs du livre « XML et les bases de données » en ce qui
suit :
« - le partage de ces données avec d’autres systèmes ;
- l’interopérabilité avec des systèmes incompatibles ;
- l’utilisation de données réelles par des applications faisant appel à XML ;
- les transactions entre entreprises ;
- la pérennité des objets grâce à XML ;
- le regroupement de données éparses »6
Par ailleurs, pour développer des structures XML à partir d’une base de données relationnelle,
plusieurs étapes doivent être évoquées :
Déterminer les données de la base de données à exporter dans une structure XML. Ceci
suppose une définition des tables et des colonnes concernées par cette exportation, qui
peuvent bien sûr varier selon notre besoin. Cette étape a pour but de déterminer toutes
les tables et les relations entre elles qui vont être envoyées à la structure XML ;
Créer l’élément racine qui doit être ajouté à la DTD qui doit contenir tous les éléments et
les attributs nécessaires au stockage des informations. Cet élément racine va englober
la représentation XML de données ;
Créer les éléments de la DTD, comme nous avons vu dans les exemples ci-dessus, chaque
table de la base de données représente un élément XML. Après avoir créé l’élément,
il faut le déclarer à l’aide du mot clé EMPTY : ex :
<!ELEMENT ORGANISATION EMPTY>
Créer les attributs correspondants aux colonnes de clés non étrangères de la table d’une
base de données, tout en leur spécifiant à l’aide des mots clés CDATA,
6
WILLIAMS, Kevin & BRUNDAGE, Michael & DENGLER, Patrick, et al. – XML et les bases de données. –
Eyrolles, 2001

#REQUIRED (Obligatoire) ou #IMPLIED (Facultatif) selon que la colonne initiale

de la table peut être NULL ou non ;
Déclarer un identifiant ID pour chaque élément créé tout en lui attribuant le type ID et
#REQUIRED. Pour être significatif, le nom de cet identifiant est conseillé d’être le nom de
l’élément suivi par ID;
Créer les attributs correspondants aux colonnes de clés étrangères (pour représenter les tables
de référence) : deux méthodes peuvent être suivies pour représenter ces associations dans une
structure XML : « Nous pouvons créer des structures hiérarchiques ce qui nous permet
d’utiliser l’imbrication (en imbriquant des informations associées à l’intérieur des éléments
parents). Si nous souhaitons garder des structures XML distinctes, à l’image des tables d’une
base de données, une seconde option consiste à utiliser un ID pour pointer vers une structure
correspondante qui dispose d’un attribut IDREF »7.
Ajouter un contenu à l’élément racine (qu’on lui a attribué EMPTY au départ). Exemple :
< !ELEMENT DONNEES_MODELE (PROPRIETE, ORGANISATION+)>
- Définir les relations pour les insérer dans la structure XML :
o Pour les relations un à un ou les relations un à plusieurs, ajouter le ou les
éléments fils, en tant que contenu d’éléments de l’élément père, avec la
cardinalité adéquate ;
o Pour les relations plusieurs à un, ajouter un attribut IDREF ou IDREFS à
l’élément coté parent qui pointe vers l’ID de l’élément côté fils ;
- Ajouter les éléments manquants (éléments ciblés par IDREF(S)) comme contenu de
l’élément racine de DTD ;
- Supprimer les IDs qui n’ont pas de référence (qui n’ont pas d’IDREF(S) pointant vers
eux), et que nous avons créés lors du développement de la structure XML.
4- EXPORTATION DES DONNEES XML VERS UNE BASE DE DONNEES

RELATIONNELLE
Nous avons vu, dans les paragraphes précédents qu’il y a plusieurs raisons justifiant
l’exportation des bases de données relationnelles vers des structures XML, maintenant, nous
allons voir que l’inverse est aussi vrai. En d’autres termes, plusieurs raisons justifient
l’exportation des données XML vers une base de données relationnelle, la plus importante est
celle liée à la recherche documentaire. En effet, si XML est un bon moyen de transparence et
de représentation de document, les bases de données relationnelles s’avèrent un moyen très
puissant en matière de requêtes et de précision et de sécurité des données. Il se peut donc que
nous aurons besoin d’une quantité déterminée de données d’une certaine structure XML, et
pas de la totalité, le meilleur moyen donc est de transférer cette quantité de données vers une
base relationnelle qui nous assure une réponse précise à nos requêtes.
Pour pouvoir faire ce transfert, il faut passer par une modélisation des divers types de contenu
d’éléments et d’attributs possibles en XML.
Nous pouvons synthétiser cette opération, sans entrer dans les détails, dans les points
suivants :
Pour la déclaration des éléments :
- Créer une clé primaire pour chaque table créée dans la base, en ajoutant un entier
AUTO_INCREMENT ;
- Créer pour chaque élément structurel une table dans la base de données. Si l’élément
constitue la racine de DTD ou un seul élément père, créer une table pour la clé
étrangère qui référencera cet élément père ;
7
op cit p.9

- Créer une table intermédiaire qui exprime la relation entre le père et l’enfant, si ce
dernier apparaît une ou plusieurs fois ;
- Créer une colonne pour chaque élément contenant que du texte et apparaissant qu’une
seule fois dans l’élément père dans la table représentant l’élément père, tout en
définissant la taille nécessaire … Si l’élément contenant du texte apparaît plusieurs
fois dans l’élément père, il faut créer une table pour stocker ses valeurs, ainsi que la
clé étrangère renvoyant à l’élément père. Si cet élément peut apparaître plus d’une fois
dans plusieurs éléments, il faut créer une table intermédiaire pour exprimer la relation
entre chaque père et chaque enfant ;
Pour les éléments de contenu mixte, créer une table et insérer des lignes, tout en précisant
une clé, puis créer deux tables, une pour l’élément et une pour relier les différentes parties de
cet élément, et dans la table des sous éléments, inclure une clé étrangère qui pointe vers la
table de l’élément principal ;
Pour la déclaration des attributs :
pour chaque attribut de type CDATA, ajouter une colonne à la table correspondant à
l’élément associé à cet attribut, tout en lui définissant une chaîne de longueur variable et une
taille maximale. Ex : pour : Code_Postal CDATA #REQUIRED, on met : Code_Postal
VARCHAR (10) ;
pour chaque attribut de type ÉNUMÉRÉ, ajouter une colonne à la table correspondant à
l’élément associé à cet attribut, tout en lui définissant un type : ENUM. Ex : pour un élément
Role_Affaire
< !ELEMENT Role_Affaire EMPTY>
< !ATTLIST Role_Affaire
Type_Role_Affaire (client | fournisseur | distributeur) #REQUIRED
On crée la table suivante :
Create table Role_Affaire (Type_Role_Affaire ENUM (client, fournisseur,
distributeur))
Gérer les attributs de type ID et IDREF qui servent successivement à identifier de manière
unique les éléments à l’intérieur de document XML (pour les ID) et renvoyer à d’autres
éléments dont les attributs ID correspondent (pour les IDREF). Pour le premier attribut, nous
pouvons le définir comme une clé primaire dans la base de données ou simplement le garder
pour le relier à tout IDREF pointant vers lui. Quant au deuxième, on le représente par une clé
étrangère qui fait référence à la clé primaire de l’élément vers lequel l’attribut pointe. Si
l’attribut IDREF pointe vers plusieurs types d’élément, on le représente par une clé de
référence de table indiquant la table à laquelle la clé correspond ;
Pour les attributs de type NMTOKEN, NMTOKENS, ENTITY, ENTITIES, créer pour
chacun d’eux une colonne dans la table correspondant à l’élément stockant la valeur de
l’attribut ;
Enfin, vérifier les résultats, s’il y a des conflits entre les noms, et changer les noms de façon à
résoudre ce problème.
5- LE LANGAGE DE REQUETE XML : XQUERY
5-1 PRESENTATION ET OBJECTIF

Les systèmes de bases de données relationnelles sont devenus très performants, surtout pour
maintenir des gros volumes de données. Avec un standard tel que SQL, il semble dérisoire de
vouloir définir un nouveau contexte de requêtes.
Toutefois, dans un contexte où les données sont déjà structurées par XML, il peut se révéler
intéressant de disposer d'un langage permettant de faire des requêtes directement sur cette

structure de données. C'est le but des langages de requête XML (XML Query Language) dont
le W3C vise la standardisation. L'interrogation des BD relationnelles reçoit donc un
traitement particulier, comme nous avons vu plus haut. Souvent, un schéma SQL peut être
traduit en une perspective XML où chaque tableau devient un document, chaque colonne
devient un élément du document et chaque valeur de cellule comme le contenu d'élément. Les
interrogations SQL, les regroupements (GROUP BY, HAVING), les unions (joins), peuvent
être convertis en syntaxe XQuery comme des expressions FLWR (FOR, LET, WHERE,
RETURN).
XML Query Language, le langage de requête XML est à XML ce que SQL pour les bases de
données relationnelles. Il représente le standard le plus important produit par le W3C, dans
lequel une interrogation est représentée comme une expression.
5-2 LES BASES DE XQUERY

L'élement de base donc du langage XQuery, comme cité ci-dessus est l'expression. En
XQuery, tout est une expression qui renvoit une valeur. Le langage reconnait de nombreuses
sortes d'expressions qui peuvent être construites à partir de mots-clés, de symboles ou
d'opérandes. Je vais essayer de présenter les différents types d'expressions définies par le
W3C à savoir :
expression de chemin (path),
constructeurs d'éléments,
expressions FLWR (, LET, WHERE, RETURN),
expressions mettant en jeu des opérateurs et des fonctions (UNION, INTERSECT,
EXCEPT),
expressions conditionnelles (IF…THEN…ELSE),
et expressions qui testent ou modifient les types de données.
Ces diverses expressions peuvent être utilisées soit directement, soit dans des blocs emboîtés.
5-2-1 Expressions de chemin
Elles sont basées sur la synthaxe de XPath, le standard XML pour décrire des "chemins" dans
un document XML:
Exemple : pour trouver tous les titres de chapitres dans un document livres.xml :
document("livres.xml")//chapitre/titre
pour trouver tous les livres publiés par Eyrolles après 1991:
document("biblio.xml")//livre[editeur = "Eyrolles" AND @annee > "1991"]
5-2-2 Constructeurs d'éléments
Utilisés quand une requête doit créer de nouveaux éléments. Les accolades { } permettent de
placer une expression au sein d'un constructeur.
Génère un élement <livre> dont un sous élément est <titre> et qui contient l'attribut "année"
:
<livre>
{ $b/@annee }
{ $b/titre }
</livre>
La variable $b est rattachée à une autre partie de la requête. Quand l'ensemble de la requête
est lancé, le constructeur ci-dessus donnera un résultat sous la forme suivante:

<livre annee="2002">
<titre>XML et les bases de données</title>
</livre>
5-2-3 Expressions FLWR
Prononcée "flower", une expression FLWR (For, Let, Where, Return) est similaire à la
construction SELECT-FROM-WHERE de SQL (avec qui elle partage certaines capacités), et
compose le squelette de l'expression XQuery. Une expression FLWR consiste à :
une clause FOR : attache une ou plusieurs variables à une séquence de valeurs
renvoyées par une autre expression (généralement une expression de chemin), et
boucle dans les valeurs ;
une clause LET : attache aussi une ou plusieurs variables à une séquence, mais sans
itération ;
une clause WHERE : contient un ou plusieurs prédicats qui filtrent ou limitent le jeu
de noeuds générés par les clauses FOR/LET.
une clause RETURN : génère le résultat de l'expression FLWR. Elle contient
généralement un ou plusieurs éléments constructeurs et/ou des références à des
variables, et est executée une fois pour chaque noeud renvoyé par les clauses
FOR/LET/WHERE.
<resultats>
{
FOR $t IN distinct(document("prix.xml")/prix/livre/titre)
LET $p := avg(document("prix.xml")/prix/livre[titre=$t]/prix)
WHERE (document("biblio/xml")/livre[titre=$t]/editeur) = "Eyrolles"
RETURN
<resultat>
{ $t }
<moy>
{ $p }
</moy>
</resultat>
}
</resultats>
En plus des fonctions internes, XQuery fournit un mécanisme permettent à l'utilisateur de
créer ses propres fonctions.
5-2-4 Expressions conditionnelles
XQuery autorise l'utilisation des expressions IF/THEN/ELSE:
<utilisateur>
{ $u/numero }
{ $u/nom }
{
IF (empty($b))
THEN <status>inactif</status>
ELSE <status>actif</status>
}
</utilsateur>
5-2-5 Expressions quantifiées

Cette expression est exprimée par SOME et EVERY. Avec SOME, il est possible de
déterminer si au moins un noeud d'un bloc de noeuds correspond à un prédicat. L'expression
EVERY permet quant à elle de tester si tous les noeuds d'un bloc correspondent à un prédicat.
Le code suivant fait la liste des utilisateurs ayant parié sur tous les jeux :
<parieur>
{
FOR $u IN document("utilisateur.xml")//utilisateur_tuple
WHERE
EVERY $item IN document("jeux.xml")//jeu_tuple SATISFIES
SOME $b IN document("paris.xml")//pari_tuple SATISFIES ($jeu/numjeu
= $b/numjeu AND $u/numutilisateur = $b/numutilisateur)
RETURN
$u/nom
}
</parieur>
5-2-6 Expressions servant à tester ou modifier des types de données
XQuery utilise à la fois les types de données standards (basés sur le système de typage de
XML Schema: nombres, booléens, chaînes, dates, temps, durées...) et les types de données
utilisateur. Les expressions INSTANCEOF et TYPESWITCH/CASE sont utilisées pour tester
si une occurence est d’un type donné.
5-2-7 Constantes et variables
Constantes et variables sont les expressions les plus basiques de XQuery. Les constantes
prennent la forme de représentations littérales de valeurs:
"Journal du Net"
42
true
"2002-11-04"
La requête suivante affiche le livre dont le numéro est 2017 :
let $numlivre := "2017"
return document("livres.xml")//livre[numlivre=$numlivre]
Dans cet exemple, "2017" est la constante, et $numlivre la variable.
5-2-8 Opérateurs
On retrouve dans XQuery les mêmes opérateurs que dans les autres langages.
Les opérateur arithmétiques:

let $prix := document("commande.xml")//achat[numachat='0021']/prix
let $quantite := document("commande.xml")//commande[@num='001']/achat/quantite
let $taux := document("commande.xml")//achat[numachat='0021']/taux
return
<resultat>
<prixunite> { $prix div $quantite } </prixunite>
<taxe> { $prix * $taux } </taxe>
<total> { $prix + $prix * $taux } </total>
</resultat>
Les opérateurs de comparaison:
for $element in document("donnees.xml")//element

return
<resultat>
{ $element/numElement }
<niveau>
{ IF ( $element/prix >= 500 ) THEN 3 ELSE
IF ( $element/prix >= 200 ) THEN 2 ELSE
IF ( $element/prix <= 50 ) THEN 0 ELSE 1 }
</niveau>
</resultat>
Les opérateurs booléens
for $element in document("donnees.xml")//element
return
<resultat>
{$element/numElement}
<niveau>
{ if ( $element/prix >= 500 and $element/prix < 10000 ) then 3 else
if ( $element/prix >= 200 and $element/prix < 500 ) then 2 else
if ( $element/prix <= 200 and $element/prix > 50 ) then 1 else 0 }
</niveau>
</result>

Chapitre 8 : Champs d’application et standards XML
CHAPITRE 8 : CHAMPS D’APPLICATION ET STANDARDS XML
1. CHAMP D'APPLICATIONS
XML est un format ayant des objectifs très larges :
4.1 COMMERCE ELECTRONIQUE ET ECHANGE DE DONNEES
INFORMATISEES (EDI)
En définissant des formats de documents standard, les entreprises pourront échanger tous
types d'informations et les intégrer dans leurs propres systèmes d'information. XML permettra
ainsi des échanges entre un nombre plus important de partenaires à un coût plus faible tout en
permettant des développements avec des outils modernes (Java, ActiveX).
1.2 GESTION ELECTRONIQUE DE DOCUMENTS (GED) :
La mise en place des documentations sur les sites intranet a rapidement montré ses limites.
Sans des outils permettant d'indexer, d'organiser et de structurer le contenu des documents
accessibles, il est très difficile aujourd'hui d'utiliser et de retrouver les informations
pertinentes. XML apporte des solutions grâce aux structures de documents et aux nombreux
langages de description de contenu qui lui sont associés.
1.3 INTEROPERABILITE DE SYSTEMES D'INFORMATIONS HETEROGENES
Le développement d'applications dans des architectures hétérogènes est une problématique
importante de ces dernières années. Pour répondre à ces besoins, de nombreuses solutions
existent allant des applications Client/Serveur aux applications intranet en passant par les
outils Corba (EJB - Enterprise Java Beans) ou DCOM (ActiveX). XML va permettre, via
différents standards (DOM, WIDL, ...), d'étendre les possibilités des applications Internet
actuelles.
1.4 PERSONNALISATION DE LA RELATION CLIENT (CRM8):
En permettant le développement d'applications WEB dynamiques accessibles aussi bien en
Internet qu'en intranet, XML offre des solutions efficaces dans le développement d'une
application de CRM.
2. LES STANDARDS
2.1. INTRODUCTION
La spécification XML est mise en oeuvre sous forme d'applications, c'est à dire de langages
de descriptions dérivés.
XML est un méta-langage de description, servant à créer des langages plus spécialisés. C'est
par exemple le domaine des mathématiques, des graphiques 2D, du multimédia, ...
Comme les standards connexes (XPath, XLL), ces applications dérivées peuvent devenir des
recommandations du W3C.
MathML (Mathematical Markup Language) pour la description et communication
d'informations mathématiques et scientifiques sur le Web,
SVG (Scalable Verctor Graphics) pour la description en XML des graphiques en 2D,
8
Customer Relationship Management

SMIL (Synchronized Multimedia Integration Langage) pour la gestion fine des

ressources multimédia sur le Web,
RDF (Resource Description Framework) pour associer des descripteurs à toutes
ressources XML afin d’en faciliter la recherche…
2.2. MATHML (MATHERNATICAL MARKUP LANGUAGE)
MathML vient du constat que la mise à disposition sur le web de documents scientifiques
contenant des formules et des équations mathématiques représente une gageure en utilisant le
langage HTML. Ce langage permettra de fournir un support aux communications
scientifiques.
Il a été conçu par le groupe W3C pour pouvoir inclure des données mathématiques de manière
simple. La version 2.0 inclut également les extensions du DOM nécessaire à la manipulation
de ces objets.
MathML version 2.0 a un statut de recommandation du 21 Février 2001, dont les
spécifications sont disponibles à : http://www.w3.org/TR/2001/REC-MathML2-20010221
Aujourd'hui ni Internet Explorer ni Navigator ne supportent MathML. Seul le navigateur
Amaya, du W3C, le supporte.
Formule en MathML et visualisation dans le navigateur Amaya
< ?xml version="1.0" encoding="UTF-8" ?>
< !DOCTYPE math PUBLIC "-//W3C//DTD MathML 2.0//EN"
http://www.w3.org/TR/MathML2/dtd/mathml2.dtd>
<math style="color : #000000 ; font-family :times ; font-size :24pt ; text-
align :center ">
<mrow>
<mi>y</mi>
<mo>=</mo>
<mfrac>
<mn>1</mn>
<msqrt>
<mrow>
<msup>
<mi>x</mi>
<mn>2</mn>
</msup>
<mo>+</mo>
<mn>1</mn>
</mrow>
</msqrt>
</mfrac>
</mrow>
</math>
1
Y=
X² + 1

2.3. SVG (SCALABLE VERCTOR GRAPHICS)

SVG (Scalable Vector Graphic) est une application XML dont l'objet est la description
d'objets graphiques en 2 dimensions. Le SVG permet de gérer trois types d'objets graphiques
• les formes vectorielles (courbes, lignes, polygones, etc.),
• les textes,
• et les images.
Ces objets graphiques peuvent être groupés, transformés, et être dotés de styles. Au moyen
d'un langage de scripts, il est possible d'avoir accès au DOM et de réaliser des cartes
dynamiques offrant de nombreuses fonctionnalités.
SVG version 1.0 a un statut de candidate recommandation du 02 Novembre 2000, dont les
spécifications sont disponibles à :
http://www.w3.org/TR/2000/CR-SVG-20001102/
Un plug-in est nécessaire pour que votre navigateur puisse afficher ce fichier SVG, sauf
Amaya qui le gère en natif.
Il a été développé par Adobe, et est téléchargeable gratuitement à l'adresse suivante
http://www.adobe.com/svg/main.html
Formes géométriques en SVG

< !DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20001102//EN"
http://www.w3.org/TR/2000/CR-SVG-20001102/DTD/svg-20001102.dtd>
<svg width= "300%" height="300%">
<desc>
Test des formes géométriques avec SVG
</desc>
<g>
<path d="M78.5 18 L132 114 L25 114 z"
style="stroke :rgb(0,255,0) ;stroke-width :10 ;
fill :rgb(0,255,255) "/>
<ellipse cx="106.5" cy="194" rx="44.5" ry="38"
style="fill :rgb(255,0,0) "/>
<rect x="183" y="35" width="88" height="81" rx="0" ry="0"
style="fill:rgb(255,255,0) "/>
</g>
</svg>

2.4. SMIL (SYNCHRONIZED MULTIMEDIA INTEGRATION LANGAGE)

SMIL (Synchronized Multimedia Integration Langage) est une application du XML dont
l'objet est la synchronisation des fichiers multimédias sur internet.
SMIL va utiliser les vidéos encodées préalablement en tant que ressources au même titre que
les fichiers audio, les images ou les fichiers textes, voir même le Flash pour Real Player.
SMIL nous permet de connaître la qualité de la connexion de l'internaute visiteur, les options
de langues de son système. SMIL permet donc de synchroniser des flux Audio et Vidéos en
fonction des paramètres de chaque internaute.
SMIL version 1.0 a un statut de recommandation du 15 Juin 1998, dont les spécifications sont
disponibles à :
http://www.w3.org/TR/1998/REC-smil-19980615
Aujourd'hui, seul Real Player sait gérer le SMIL convenablement, et le navigateur xsmiles
Une page SMIL est composée de 2 éléments principaux :
- Une entête qui définit toutes les régions nécessaires à l'affichage,
- Un corps qui contient toutes les instructions de synchronisation.
Définition des régions d’affichage
< !DOCTYPE smil PUBLIC "-//W3C//DTD SMIL 1.0//EN"
http://www.w3.org/TR/REC-smil/SMIL.dtd>
<smil>
<head>
<meta name="author" content= "Daniel Duchaussoy"/>
< meta name="title" content= "Demo SMIL"/>
<meta name="copyright" content="2000 Daniel Duchaussoy"/>
<meta name="abstract" content="Demo SMIL pour ma page perso"/>
<switch>
< ! - - définition des régions pour les internautes haut débit - ->
<layout system-bitrate="80000">
<root-layout background-color="black" height="525" width="772" />
<region id="fondg" left="0" top="0" height="525" width="772"
z-index="0" />
<region id="videog" left="106" top="130" height="240" width="320"
z-index="1" />
</layout>
< ! - - définition des régions pour les internautes bas-débit - ->
<layout>
<root-layout background-color="black" height="403" width="593" />
<region id="fondg" left="0" top="0" height="403" width="593"

z-index="0" />
<region id="videog" left="73" top="92" height="144" width="192"
z-index="1" />
</layout>
</switch>
</head>
Définition du corps avec instructions de synchronisatrion

<body>
<switch>
< !- - video pour haut-débit en fdrançais - ->
<par system-bitrate="80000" system-language="fr"
<video src="video_high_fr.rm" region="videog" title="Demo SMIL" />
<seq>
<img src="background1.jpg" dur="0 :03 :00.0" region="fondg" fill="remove" />
<img src="background2.jpg" region="fondg" fill="freeze" />
</seq>
</par>
< !—video pour bas-débit en français - ->
<par system-language="fr">
<video src="video_low_fr.rm" region"video" title="Demo SMIL" />
<seq>
<img src= background1.jpg" dur="0 :03 :00.0" region="fondg" fill="remove" />
</seq>
</par>
< !—video pour haut-débit en anglais - ->
<par system-bitrate="80000"
<video src="video_height_fr.rm" region"video" title="Demo SMIL" />
<seq>
</seq>
</par>
< !—video pour bas-débit en anglais - ->
<par>
<video src="video_height_fr.rm" region"video" title="Demo SMIL" />
<seq>
</seq>
</par>
</switch>
</body>
</smil>
2.5. RDF (RESOURCE DESCRIPTION FRARNEWORK)

RDF (Resource Description Framework) propose de définir un cadre formel de définition de
metadonnées avec comme objectifs :
• rendre plus pertinent le traitement automatisé des informations contenues sur le Web, par la
possibilité de fournir aux outils de traitement une information plus sémantique que les seuls
mots contenus dans un document,
la capacité de rendre plus "intelligente" l'information nécessaire aux moteurs de recherche et,
plus généralement, nécessaire à tout outil informatique analysant de façon automatisée des
pages Web,

• fédérer les vocabulaires et syntaxes de description de Métadonnées existantes dans un cadre

(framework) commun :
RDF permettra de répondre précisément à une requête de type : "recherche de documents
ayant Tim Berners-Lee comme auteur".
RDF a un statut de recommandation du 22 Février 99, dont les spécifications sont disponibles
à : http://www.w3.org/TR/1999/REC-rdf-syntax-19990222
Dans ses principes de base, RDF dissocie trois types d'objets :
• une ressource (document ou extrait de document),
• des propriétés,
• des valeurs (chaîne descriptive ou document).
Une ressource est définie par des propriétés. L'association d'une ressource à une propriété par
une valeur de propriété est une déclaration RDF Ainsi, il est possible de décrire, avec RDF,
des phrases du type
"http://www.edifrance.org" est créé par l'"association EDIFRANCE"
- "http:// www.edifrance.org" est la ressource ;
- "est créé" est une propriété dont la valeur est "association EDIFRANCE".
La syntaxe utilisée par RDF étant XML, la déclaration précédente pourra s’écrire :
<rdf :RDF xmlns :rdf = http://www.w3.org/1999/02/22-rdf-syntax-ns#>
<rdf :description about =”http://www.edifrance.org”>
<createur>EDIFRANCE</createur>
</rdf :description>
</rdf :RDF>
Pour que la syntaxe RDF soit compréhensible, la signification doit être connue par la
standardisation des propriétés et la définition des Schémas RDF.
Dublin core est un schéma RDF qui définit les propriétés : Title, Creator, Subject,
Description, ...
RDF laisse aux personnes définissant leurs Métadonnées le choix du ou des vocabulaire(s)
utilisé(s). il serait, par exemple, possible de définir plusieurs propriétés "créateur", une,
compatible avec le Dublin Core, spécification de Métadonnées extrêmement généraliste et
une, compatible avec un modèle privé, recensant tous les créateurs dans une base de données
ad hoc.

Conclusion
CONCLUSION
XML est un méta-langage de description des données permettant de définir des formats de
documents. Ces formats possèdent les caractéristiques suivantes:
• Ce sont des documents textuels utilisant la norme Unicode,
• Le modèle de base est hiérarchique,
• XML est une norme de l'industrie,
• L'information dans les documents est auto-descriptive
L'ensemble de ces caractéristiques fait en sorte que la norme XML permet de représenter des
documents structurés, elle assure la pérennité de l'information et facilite les échanges de
données.
XML permet de définir des langages spécifiques à savoir : XLL, XPath, XQuery, RDF,
… à travers une méta-syntaxe, à laquelle doivent se conformer ces langages,
XML ne s’intéresse pas au formatage de données, il en décrit la structure et la sémantique,
Les informations liées à la présentation des données doivent être décrites dans une feuille
de style qui permet au navigateur de savoir comment contrôler le format des éléments,
Le XSL (Extensible Style Language) est le langage utilisé pour définir les feuilles de style
qui seront associées aux documents XML. C'est le fichier XSL qui permettra de définir
que tel élément XML doit être affiché avec telle fonte, de telle couleur, etc. Ces décisions
seront, grâce à XSL, prises par le créateur du document qui aura ainsi un meilleur contrôle
sur l'apparence de son document,
Une DTD est un composant facultatif associé à un document XML spécifiant le contenu
autorisé et la structure des éléments. Si on utilise une DTD, le document sera dit "valide";
c'est-à-dire qu'il fera appel à cette DTD et s'y conformera. Si on n'utilise pas de DTD, le
document XML devra être "bien formé"; il ne devra comporter aucune ambiguïté dans le
balisage,
Un schéma XML est une DTD plus développée. Il est conçu pour palier aux déficiences
des DTD. XML Schema propose, en plus des fonctionnalités fournies par les DTD, des
nouveautés à savoir le grand nombre de types de données, la notion d'héritage, le support
des espaces de nom… et le grand apport de ce dernier est qu’il est écrit en langage XML,
XForms doivent devenir la prochaine génération de formulaires, étandant et simplifiant la
fourniture de formulaires indépendants de l’interface utilisateur.
XQuery est donc le nouveau langage qui permet au XML d'atteindre son plein potentiel
dans la gestion de données en provenance de bases de données et autres documents au
format XML.
« Il est à prévoir que l'usage d'XML va déborder largement le WWW, en provoquant la
convergence de deux mondes informatiques jusqu'ici séparés ; celui des documents et
celui des données. Il est très probable qu'il va de ce fait devenir très rapidement la
lingua franca de l'informatique, parlée tout autant par les SGBD que par les outils de
bureautique et de documentation, par les logiciels de gestion aussi bien que par les
applications techniques et scientifiques et qu'il va considérablement simplifier
l'Échange de Données Informatisé (EDI).
On n'a donc pas fini d'entendre parler de XML ! 9»
9
LAZINIER, Emmanuel. XML expliqué aux débutants. - http://www.chez.com/xml/initiation/

Bibliographie
BIBLIOGRAPHIE
LIVRES
WILLIAMS, Kevin & BRUNDAGE, Michael & DENGLER, Patrick, et al. – XML et les
bases de données. – Eyrolles, 2001
HAROLD, Eliotte Rusty. – XML : le guide de l’utilisateur. – Eyrolles, 2000
BERNADAC, Jean-Christophe & KNAB, François. - Construire une application XML. -
Eyrolles
MICHARD, Alain. - XML Langage et applications. – Eyrolles. -
(http://www.eyrolles.com/xml)
SITES INTERNET
Des références sur html : htlp://www.allhtml.com/langages/html.php3
Des références sur html4:
• http://oxygen.citeweb.net/
• http://www.w3.org/tr/rec-html40
Le site de l'éditeur O'Reilly : htlp://www.xml.com/pub
Les rapports techniques du consortium W3C : http://www.w3.org/tr
Des références sur xml :
• l'incontournable: http://www.w3c.org
• le site XML français: http://xmlfr.org
• Spécification XML annotée: xml.com/axml/axml.html
• Tutoriaux SUN: java.sun.com/xml
• Le site de référnce de Robin Cover: www.oasis-open.org/cover
• Site généraliste "business": xml.com
• Infos sur les softs commerciaux: xmlsoftware.com
• Infos sur des freewares: www.garshol.priv.no/download/xmltools
• et ...www.google.com
• www.w3.org/tr/rec-xml
• http://www.xmltechno.com
• http://www.chez.com/xml/liens/liens-en-1.htm
LAZINIER, Emmanuel. - XML expliqué aux débutants. -
http://www.chez.com/xml/initiation/
Bertrand Ibrahim. – Introduction à XML. - http://cui.unige.ch/eao/www/xml/Plan.html
Des références sur XML-QL:
http://www.w3.org/TR/NOTE-xml-ql/
OUTILS
Microsoft :
- notepad XML : http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnxml/html/xmlpaddownload.asp
- parser XML : http://msdn.microsoft.com/xml/default.asp
Modélisation et développement, éditeur DTD :
- http://www.opentext.com/near_and_far/
- http://www.eyrolles.com/xml

Bibliographie
Validation de syntaxe XHTML:

http://validator.w3.org/
Validation de syntaxe de schémas:
http://www.w3.org/2001/03/webdata/xsv
Validation de syntaxe de feuille de style CSS:
http://jigsaw.w3.org/css-validator/validator-uri.html
Validation de syntaxe XML (ne semble par reconnaître les déclarations d'espaces de noms
xmlns:xx="...")
http://www.stg.brown.edu/service/xmlvalid/
Validation de syntaxe XML (offre le choix entre validation basée sur la DTD ou traitement
des espaces de noms)
http://www.cogsci.ed.ac.uk/~richard/xml-check.html
Vérificateur de syntaxe XML (vérifie juste que le document est bien formé)
http://www.xml.com/xml/pub/tools/ruwf/check.html
Validation de syntaxe XML (nécessite Internet Explorer?? je n'ai pas pu le faire fonctionner)
http://msdn.microsoft.com/downloads/samples/internet/xml/xml_validator/
SITE OFFRANT DES DTDS STANDARDS

Dublin-core : article scientifique :
http://purl.oclc.org/dc/documents/rec-dces-19990702.htm
SITES DE LOGICIELS EN LIGNE

• Liste de logiciels SGML et XML gratuits :
http://www.oasis-open.org/cover/publicSW.html#xmlTools

Glossaire
GLOSSAIRE
BizTalk Framework XML d'échange de données dans un contexte d'intégration d'applications

ou de commerce interentreprises. Les schémas XML produits à l'aide de ce framework
seront enregistrés sur le site www.biztalk.org
BPML (Business Process Modeling Language) : De la même façon que XML fournit un
format de représentation des données, BPML est un métalangage de modélisation des
processus collaboratifs qu'engage une entreprise avec ses partenaires sur internet.
www.bpmi.org
cXML (Commerce XML) Cette spécification XML, élaborée par Ariba, se propose de
standardiser la gestion des catalogues électroniques et des transactions commerciales
exécutée travers d'une place de marché sur internet. www.cxml.org
DOM (Document Object Model) : Le modèle objet de documents définit une API
(indépendante des langages de programmation) permettant de manipuler et de
parcourir un document représenté sous la forme d'arborescence orientée objet (un
noeud de l'arbre est un objet). www.w3.org/DOM
DTD (Document Type Definition) : La définition de type de documents décrit la structure

d'un document XML, c'est-à-dire l'ordre, l'imbrication et le caractère obligatoire ou
facultatif des éléments qui le composent. On déclare la DTD dans le document XML
ou dans un fichier externe. Elle cède désormais sa place aux schémas XML.
ebXML (Electronic Business XML Initiative) : Les Nations unies (UN/Cefact) et l'organisme
Oasis sont à l'origine de ce framework XML, qui permettra à deux partenaires de
s'échanger sur internet des messages s'inscrivant dans le cadre de l'intégration de leurs
processus collaboratifs. www.ebxml.org
ebXML Messaging Services: Cette spécification comprend un ensemble de services et de

protocoles permettant à deux entités applicatives de s'échanger des données sur les
protocoles de transport d'internet - SMTP et notamment HTTP. L'en-tête des messages
est décrit en XML, tandis que son corps peut renfermer différents formats numériques
- XML, Mime, etc. www.ebxml.org/toc.htm.
ebXML Registry : Cet annuaire référence tous les éléments (schémas XML, documents,
description de processus, modèles UML, etc. ) nécessaires à une entreprise désirant
engager une collaboration commerciale sur internet, basée sur le framework XML
ebXML, avec l'un de ses partenaires. www.ebxml.org/toc.htm
eCo Framework : Framework XML d'échange de données. Défini par CommerceNet, celui-
ci se propose de rassembler dans une même spécification les apports de différents
standards XML (OBI, ICE, OFX, OTP, etc.).
www.commerce.net/projects/currentprojects/eco
HDML (Handheld Device Markup Language) : S'appuyant sur une syntaxe XML, ce langage,
développé par Openwave (ex-Phone. coin), est utilisé pour créer et diffuser un contenu
de type hypertexte sur des terminaux mobiles caractérisés par de fortes contraintes
d'affichage.

Glossaire
OAGIS 7. 0 (Open Applications Group Intégration Spécification) : Cette spécification de

POAG définit la structure de plus de cent soixante-dix messages XML (DTD) relatifs
aux contenus échangés (catalogue électronique, ordre de commande, notification de
livraison, etc. ) sur internet entre plusieurs partenaires. www.openapplications.org
OASIS (Organization for the Advancement of Structured Information Standards,
anciennement SGML Open) est une association fondée en 1993, qui s’est fixé pour but
d’accélérer l’adoption par le marché d’applications et de plates-formes basées sur les
standards XML et SGML.
OBI (Open Buying on the Internet) : Le but de cette spécification est de standardiser toutes
les étapes relatives à la gestion des achats sur internet. www.openbuy.org
RDF (Resource Description Framework) : Fournit un moyen de créer et d'échanger les
métadonnées décrivant les ressources du web (tout ce qui est caractérise par un URI -
Unique Resource Identifier). Avec RDF, le web devient sémantique.
www.w3.org/RDF.
RosettaNet : Framework XML d'échange de données visant, à l'origine, le secteur de la high
tech et désormais étendu à l'ensemble de l'industrie. Il comprend un dictionnaire
stockant tous les éléments utiles à l'exécution d'une transaction commerciale sur
internet (description des produits et des partenaires, etc. ). Il propose un protocole
d'échange nommé PIP (Partner Interface Process). www.rosettanet.org
SAX (Simple API for XML) : Type d'analyseur (parser) XML, dit événementiel.
Contrairement à un analyseur DOM, qui lit un document XML en bloc, un analyseur
SAX renvoie les éléments d'un document au fur et à mesure de leur lecture.
www.megginson.com/SAX.
SMIL (Synchronized Multimedia Integration Language) : Permet l'intégration d'un ensemble
d'objets multimédias indépendants au sein d'une même présentation. Avec SMIL, un
auteur peut décrire le comportement temporel de sa présentation et son aspect sur un
écran, et il peut associer des hyperliens à des objets multimédias.
www.w3.org/TR/REC-smil
SOAP (Simple Object Access Protocol) : Ce protocole permet d'invoquer un objet distant en
communiquant les informations nécessaires à l'appel (nom de la méthode et de ses
paramètres d’entrée) dans un message au format XML et via HTTP. La réponse à la
requête est, elle aussi, renvoyée dans une structure XML.
www.w3.org/TR/2000/NOTE-SOAP-20000508
SVG (Scalable Vector Graphics) : Langage de description en XML des graphiques en deux
dimensions. www.w3.org/TR/2000/CR-SVG-20001102
UDDI (Universal Description Discovery and Integration) : Cet annuaire offre des mécanismes
d’enregistrement et de recherche de services web développés et publiés par les
entreprises du monde entier. UDDI fournit des données sur l'auteur de services web
(adresse, contact, etc. ), sur leur catégorie d'appartenance (taxonomie) et sur les
moyens techniques permettant de les invoquer. www.uddi.org
UIML (User Interface Markup Language) : Langage universel de description de la
localisation et du design des éléments présents dans une interface graphique (listes,
boutons, menus, etc. ). Une interface utilisateur ainsi représentée de façon générique
pourra ensuite être adaptée à divers systèmes d'exploitation. www.uiml.or2

Glossaire
VML (Vector Markup Language) : Définit un format d'encodage des informations graphiques
vectorielles, auquel s'ajoutent des balises décrivant la manière dont ces informations
sont affichées. www.w3.org/TR/1998/NOTE-VML-9980513.html.
WebDAV (Web Distributed Authoring and Versioning) : Ce standard constitue une série
d'extensions au protocole HTTP 1. 1. Il permet de disposer d'une infrastructure
d'édition et de partage (verrouillage, gestion de versions, etc. ) de documents résidant
sur des serveurs web distants. Les informations liées aux propriétés du document - les
métadonnées - sont décrites en XML. www.webdav.org/specs
WML (Wireless Markup Language) : Il s'agit du langage de description - basé sur une
syntaxe XML - du contenu diffusé sur les terminaux mobiles conformes au protocole
WAP (wireless Application Protocol). www.w forum.org.
World Wide Web Consortium (W3C) Organisme de standardisation des protocoles
internet. Le W3C est organisé par groupes de travail. Chaque groupe de travail
réfléchit à un thème précis (HTML, XML...) et propose des spécifications aux
membres du consortium. Les membres du W3C votent. Si le vote est positif, la
spécification devient une recommandation.
WSDL (Web Services Description Language) : Ce langage permet d'exposer dans un format
XML la signature d'un composant applicatif - on parle de service web - accessible sur
internet. Cette signature inclut les opérations exposées par le service web en question,
le type de ses paramètres d'entrée et de sortie, l'adresse réseau à laquelle on pourra
l'invoquer, etc. www.w3.org/TR/2001/NOTE-wsdl-20010315
xCBL (XML Common Business Library) : Cette spécification XML, élaborée par
Commerce0ne, se propose de standardiser la gestion des catalogues électroniques et
des transactions commerciales exécutées au travers d'une place de marché sur internet.
www.xcbl.org
XHTML (eXtensible Hypertext Markup Language) : Il s'agit d'une reformulation de HTML 4
en XML. Ce langage s'appuie sur trois DTD définissant le langage HTML.
www.w3.orR/TR/xhtmll
XLANG Schedule : Ce langage permet de décrire en XML les processus collaboratifs conçus
avec l'outil BizTalk Orchestration Designer. www.microsoft.com/biztalk
XLink (XML Linking Language) : Ce langage, basé sur une syntaxe XML, permet d'insérer
dans un document XML des éléments de description de liens entre objets. Ces liens
peuvent être plus unidirectionnels, comme les hyperliens de HTML (« -A HREF... »)
ou plus complexes (liens entre plus de deux documents ou auxquels on associe des
métadonnées, etc. www.w3.ore/TR/xlink.
XML (eXtensible Markup Language) : Ce métalangage permet la création de langage de
balisage. Il est extensible. Autrement dit, tout auteur peut structurer le contenu de ses
documents XML à l'aide de balises qu'il aura lui-même définies. Contrairement à
HTML, XML sépare la structure du contenu d'un document de sa présentation.
www.w3.org/XML.
XML Namespaces (domaine ou espace de noms) : Permet de qualifier les éléments et les
attributs d'un document XML en leur associant des espaces de noms identifiés par une
adresse URI (Uniform. Resource Identifier). Tous les éléments appartenant à un
espace de noms sont préfixés par son identifiant, suivi du signe «:» (-personne : nom-
Martin-/personne : nom-). www.w3.or2/TR/REC-xml-names.

Glossaire
XML Schema : Cette spécification permet de créer des schémas XML, lesquels remplacent et
pallient les lacunes des DTD en termes de définition de type de données, d'espaces de
noms (namespaces) et des relations entre les éléments d'un document XML et ses
attributs. Contrairement à une DTD, un schéma XML est un document XML.
www.w3.org/XML/Schema.
XML-RPC (XML Remote Procedure Call) : Ce protocole a inspiré SOAP. Il permet à une
application d'appeler une fonction applicative distante, la requête étant transportée sur
HTTP et son corps décrit en XML. www.xml-rpc.com
XP (XML Protocol) : Ce protocole permet à deux entités applicatives distantes d'interopérer.
Élaboré par le W3C, il prévoit de décrire en XML à la fois la requête d'invocation d'un
service applicatif distant et l'enveloppe dans laquelle sera véhiculée cette requête sur
HTTP. www.w3.org/2000/xp
XPath (XML Path Language) : Ce langage permet d'accéder à un élément d'un arbre XML. Il
a été conçu pour être utilisé conjointement avec XSLT et XPointer.
www.w3.org/TR/xpath.
XPointer (XML Pointer Language) : Décrit la façon de désigner un document ou un élément
à l'intérieur d'un document. C'est avec cette syntaxe que l'on construit un URI (Unique
Resource Identifier) en XML. Un élément désigné à l'aide de XPointer est accessible
via XPath. www.w3.org/XML/Linkinz.
XSL (eXtensible Stylesheet Language) : Langage de description de feuille de style. Il est
composé de XSL-FO (Formatting Objects), un vocabulaire qui permet d'appliquer un
style à un document XML, et de XSLT, un langage de transformation de document
XML. www.w3.org/Style/XSL
XUL (eXtensible User Interface Language) : Langage basé sur XML permettant de décrire les
éléments composant une interface utilisateur, tels que les fenêtres graphiques, les
boîtes de dialogue, les menus, les barres de défilement, etc.
www.mozilla.org/xpfe/xptoolkit/xulintro.html

Langue

Cours XML

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Cours XML

Titre original :

Transféré par

Droits d'auteur :

Département Hypermédia

Cours préparé et présenté par :

CHAPITRE 1 : LES DOCUMENTS XML 10

1. LES REGLES D'ECRITURE 10

CHAPITRE 2 : XML SCHEMA 27

1. INTRODUCTION AUX SCHEMAS XML (XML SCHEMA) 27

CHAPITRE 3 : XPATH ET XLL 41

CHAPITRE 4 : LES FEUILLES DE STYLE 47

1. LES FEUILLES DE STYLES: XSL ET CSS 47

CHAPITRE 5 : LE MODELE DE DOCUMENT 60

CHAPITRE 6 : FORMULAIRES XML : XFORMS 65

CHPITRE 7 : XML ET LES BASES DE DONNEES 70

CHAPITRE 8 : CHAMPS D’APPLICATION ET STANDARDS XML 83

Abderrazak MKADMI Cours XML 5

Consortium) souhaitaient définir un langage bénéficiant des principales fonctionnalités de

Abderrazak MKADMI Cours XML 6

- Supporter une grande variété d'applications

2. LES LIMITES DE HTML

Abderrazak MKADMI Cours XML 7

3. LES APPORTS DE XML

3.1. EXTENSIBILITE ET STRUCTURE :

3.2. STRUCTURE TYPE : MODULARISATION ET REUTILISATION

Abderrazak MKADMI Cours XML 8

Abderrazak MKADMI Cours XML 9

CHAPITRE 1 : LES DOCUMENTS XML

1. LES REGLES D'ECRITURE

< !ELEMENT formation (date, titre, societe, programme) > Partie

< ![CDATA[<XML> - Développement ]]>

Le prologue des documents XML joue trois rôles importants:

1. Préciser qu'il s'agit d'un document XML

Le prologue peut contenir donc :

Abderrazak MKADMI Cours XML 11

une déclaration de DTD.

standalone='Yes' veut dire que toutes les recherches de déclarations se feront

Abderrazak MKADMI Cours XML 12

2.1.3. Déclaration de type de document (DTD)

2.2. L'ARBRE D'ELEMENTS

Abderrazak MKADMI Cours XML 13

3. LES ATTRIBUTS, LES ENTITES, LES SECTIONS LITTERALES

Abderrazak MKADMI Cours XML 14

3.2. LES ATTRIBUTS

Abderrazak MKADMI Cours XML 15

• &# suivi du numéro décimal du caractère dans les pages UNICODE

3-3 LES ENTITES PARAMETRIQUES

Abderrazak MKADMI Cours XML 16

3-4 LES ENTITES DE CARACTERES

3.5 LES ENTITES INTERNES

3.6 LES SECTIONS LITTERALES

3.7 LES ENTITES EXTERNES

Abderrazak MKADMI Cours XML 17

3.8 LES ENTITES NON-XML

Abderrazak MKADMI Cours XML 18

La déclaration de telles entités nécessite la définition préalable du format de l’entité, c’est à

3.9 RECAPITULATIF SUR LES ENTITES

2. nom est une référence à une entité externe non-XML

Abderrazak MKADMI Cours XML 19

5. DOCUMENT BIEN FORME ET DOCUMENT VALIDE: LA DTD

5.1 REFERENCE A UNE DTD DANS UN DOCUMENT XML

Abderrazak MKADMI Cours XML 20

Exemple : le fichier xml

< !DOCTYPE catalogue SYSTEM ''DTDexterne.dtd''>

< !DOCTYPE catalogue [

Abderrazak MKADMI Cours XML 21

5.2 DECLARATION INTERNE ET EXTERNE DE LA DTD