- Tous les cours
- Conditions d'utilisation
- À propos de ces cours
- Contact

# Cours de XML - Initiation aux Schema XML

version 1.34, dernière mise à jour le 11 mars 2008.

Chercher dans le cours :

## Table des matières (TdM)

1. I. Introduction
   1. Limitations des DTD
   2. Apports des schémas

1. II. Les premiers pas
   1. Introduction
   2. Structure de base

1. III. Déclarations d'éléments et d'attributs
   1. Déclarations d'éléments
   2. Déclarations d'attributs
      1. Déclaration simple
      2. Contraintes d'occurences
      3. Regroupements d'attributs
      4. Déclaration d'élément ne contenant que du texte avec un (ou plusieurs) attribut(s)
   3. Déclaration et référencement

1. IV. Les types de données
   1. Introduction
   2. Types simples
      1. Généralités
      2. Bibliothèque de types intégrés
      3. Listes
      4. Unions
   3. Les types complexes
      1. Introduction
      2. Séquences d'éléments
      3. Choix d'élément
      4. L'élément all
      5. Indicateurs d'occurences
      6. Création de type complexe à partir de types simples
      7. Exercice : Déclaration d'éléments
      8. Exercice : Déclaration d'attributs
      9. Exercice : Déclaration de types

1. V. Espaces de nom
   1. Introduction
   2. Comment lier un fichier XML à un schéma ?

1. VI. Les dérivations
   1. Introduction
   2. Restriction de type
      1. Généralités
      2. Exemples

1. VII. Diverses autres fonctionnalités
   1. Inclusion de schémas
   2. Documentation
   3. Attribut null

Retour au menu

## Contenu du cours

### I. Introduction

#### 1. Limitations des DTD

Lors de son lancement, `XML` a été perçu comme une réelle chance pour les développeurs d'avoir à disposition un langage simple d'utilisation, portable sans difficulté d'une machine -et d'une application- à une autre, et libre de droits. Dans les premiers temps, un fichier `XML`, si on voulait le standardiser en utilisant un vrai langage général de description, devait dépendre d'une `DTD`. Mais ce format de description, hérité de `SGML`, souffre de nombreuses déficiences.

1. Premièrement, les `DTD` ne sont pas au format `XML`. Cela signifie qu'il est nécessaire d'utiliser un outil spécial pour manipuler un tel fichier, différent de celui utilisé pour l'édition du fichier `XML`.

2. Deuxièmement, les `DTD` ne supportent pas les « espaces de nom » (nous reviendrons sur cette notion). En pratique, cela implique qu'il n'est pas possible d'importer des définitions de balises définies par ailleurs dans un fichier `XML` défini par une `DTD`.

3. Troisièmement, le « typage » des données (c'est-à-dire la possibilité de spécifier par exemple qu'un attribut ne doit être qu'un nombre entier) est extrêmement limité.

>Retour à la TdM

#### 2. Apports des schémas

Conçu pour pallier les déficiences pré-citées des `DTD`, `XML Schema` propose des nouveautés en plus des fonctionnalités fournies par les DTD :

- Le typage des données est introduit, ce qui permet la gestion de booléens, d'entiers, d'intervalles de temps... Il est même possible de créer de nouveaux types à partir de types existants.

- La notion d'héritage. Les éléments peuvent hériter du contenu et des attributs d'un autre élément..

- Le support des espaces de nom.

- Les indicateurs d'occurrences des éléments peuvent être tout nombre non négatif (rappel : dans une `DTD`, on est limité à 0, 1 ou un nombre infini d'occurences pour un élément).

- Les schémas sont très facilement concevables par modules.

>Retour à la TdM

### II. Les premiers pas

#### 1. Introduction

Le but d'un schéma est de définir une classe de documents `XML`. Il permet de décrire les autorisations d'imbrication et l'ordre d'apparition des éléments et de leurs attributs, tout comme une `DTD`. Mais il permet aussi d'aller au-delà.

Un premier point intéressant est qu'un fichier `Schema XML` est un document `XML`. Cela permet à un tel document d'être manipulé de la même manière que n'importe quel autre fichier `XML`, et en particulier par une feuille de style `XSL`. Par exemple, il est notamment possible d'automatiser la création d'une documentation à partir d'un schéma, fondée sur les commentaires et explications qui s'y trouvent. C'est d'ailleurs chose facile avec l'éditeur oXygen, via le menu Modules d'extension>Schema Documentation, à partir d'un exemple de schéma, de produire la documentation correspondante.

Le vocabulaire de `XML Schema` est composé d'environ 30 éléments et attributs. Ce vocabulaire est, a priori de manière bizarrement récursive et « auto-référente », défini dans un Schéma. Mais il existe également une DTD.

>Retour à la TdM

#### 2. Structure de base

Comme tout document `XML`, un `Schema XML` commence par un prologue, et a un élément racine.

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"> <!-- déclarations d'éléments, d'attributs et de types ici -->
</xsd:schema>

L'élément racine est l'élément `xsd:schema`. Pour le moment, oubliez l'attribut `xmlns:xsd` (dont le rôle est le même que celui que nous avons déjà rencontré lors du cours sur les feuilles de style), et qui fait référence à l'espace de noms utilisé pour l'écriture du fichier. Il faut simplement retenir que tout élément d'un schéma doit commencer par le préfixe `xsd.`

Nous allons voir, par la suite, comment déclarer éléments et attributs à l'aide d'un schéma.

>Retour à la TdM

### III. Déclarations d'éléments et d'attributs

#### 1. Déclarations d'éléments

Un élément, dans un schéma, se déclare avec la balise `<xsd:element>`. Par exemple,

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"> <xsd:element name="contacts" type="typeContacts" />
<xsd:element name="remarque" type="xsd:string" />
<!-- déclarations de types ici -->
</xsd:schema>

Le schéma précédent déclare deux éléments : un élément `contacts` et un élément `remarque`. Chaque élément est « typé » -c'est-à-dire qu'il doit respecter un certain format de données. L'élément `contacts` est ainsi du type `typeContacts`, qui est un type complexe défini par l'utilisateur. L'élément remarque quant à lui est du type `xsd:string` qui est un type simple prédéfini de `XML Schema`.

Chaque élément déclaré est associé à un type de données via l'attribut `type`. Les éléments pouvant contenir des élément-enfants ou posséder des attributs sont dits de type complexe, tandis que les éléments n'en contenant pas sont dits de type simple. Nous reviendrons plus loin sur cette notion de type de données.

>Retour à la TdM

#### 2. Déclarations d'attributs

##### a. Déclaration simple

À la différence des éléments, un attribut ne peut être que de type simple. Cela signifie que les attributs, comme avec les `DTD`, ne peuvent contenir d'autres éléments ou attributs. De plus, les déclarations d'attributs doivent être placées après les définitions des types complexes, autrement dit, après les éléments `xsd:sequence`, `xsd:choice` et `xsd:all` (voir plus loin). Pour mémoire, rappelons que dans une `DTD`, l'ordre des déclarations n'a pas d'importance.

L'exemple suivant montre la déclaration d'un attribut `maj` de type `xsd:date` (un autre type simple) qui indique la date de dernière mise à jour de la liste des contacts.

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"> <xsd:element name="contacts" type="typeContacts" />
<xsd:element name="remarque" type="xsd:string"> <!-- déclarations de types ici -->
<xsd:complexType>
<!-- déclarations du modèle de contenu ici -->
<xsd:attribute name="maj" type="xsd:date" />
</xsd:complexType>
</xsd:element>
</xsd:schema>

>Retour à la TdM

##### b. Contraintes d'occurences

Tout comme dans une `DTD`, un attribut peut avoir un indicateur d'occurences.

L'élément `attribute` d'un `Schema XML` peut avoir trois attributs optionnels : `use`, `default` et `fixed`. Des combinaisons de ces trois attributs permettent de paramétrer ce qui est acceptable ou non dans le fichier `XML` final (attribut obligatoire, optionnel, possédant une valeur par défaut...). Par exemple, la ligne suivante permet de rendre l'attribut `maj` optionnel, avec une valeur par défaut au 11 octobre 2003 s'il n'apparaît pas (le format de date est standardisé : cette date s'écrit donc à l'anglo-saxonne année-mois-jour ; cela permet en outre de plus facilement classer les dates).

<xsd:attribute name="maj" type="xsd:date" use="optional" default="2003-10-11" />

Quand l'attribut `fixed` est renseigné, la seule valeur que peut prendre l'attribut déclaré est celle de l'attribut `fixed`. Cet attribut permet de "réserver" des noms d'attributs pour une utilisation future, dans le cadre d'une mise à jour du schéma.

Le tableau suivant présente une comparaison entre le format `DTD` et le `XML Schema`.

DTD | Attribut `use` | Attribut `default` | Commentaire
--- | --- | --- | ---
#REQUIRED | required | - |
"blabla" #REQUIRED | required | blabla |
#IMPLIED | optional | - |
"blabla" #IMPLIED | optional | blabla |
- | prohibited | - | Cet attribut ne doit pas apparaître

Table 1. Contraintes d'occurences fixables par les attributs `use` et `default`.

Il est à noter que la valeur de l'attribut `default` doit être conforme au type déclaré. Par exemple...

<xsd:attribute name="maj" type="xsd:date" use="optional" default="-43" />

... produirait une erreur à la validation du schéma.

Un autre type de déclaration d'attributs dans les `DTD`, la liste de choix, est possible grâce à une restriction de type ; nous y reviendrons.

>Retour à la TdM

##### c. Regroupements d'attributs

`XML Schema` propose une fonctionnalité supplémentaire, permettant de déclarer des groupes d'attributs (groupes auxquels il est possible de faire appel lors d'une déclaration d'éléments). Cela permet d'éviter de répéter des informations de déclarations.

>Retour à la TdM

##### d. Déclaration d'élément ne contenant que du texte avec un (ou plusieurs) attribut(s)

Un tel élément est de type complexe, car il contient au moins un attribut. Afin de spécifier qu'il peut contenir également du texte, on utilise l'attribut `mixed` de l'élément `xsd;complexType`. Par défaut, `mixed="false"`; il faut dans ce cas forcer `mixed="true"`. Par exemple,

<xsd:element name="elt">
<xsd:complexType mixed="true">
<xsd:attribute name="attr" type="xsd:string" use="optional" />
</xsd:complexType>
</xsd:element>

>Retour à la TdM

#### 3. Déclaration et référencement

La procédure précédente de déclaration d'éléments peut amener à une structure de type « poupée russe » des déclarations. Pour des raisons de clarté, il est beaucoup plus avantageux d'ordonner ces déclarations, ainsi qu'on peut le voir sur cet exemple (on ne fera pas attention, pour le moment, aux « définitions de type »).

Il est recommandé de commencer par déclarer les éléments et attributs de type simple, puis ceux de type complexe. On peut en effet faire référence, dans une déclaration de type complexe, à un élément de type simple prélablement défini. Par exemple...

<xsd:element name="livre">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="auteur" type="xsd:string" />
<xsd:element name="pages" type="xsd:positiveInteger" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>

... est plus difficile à maintenir que...

<xsd:element name="pages" type="xsd:positiveInteger" />
<xsd:element name="auteur" type="xsd:string" />
<xsd:element name="livre">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="auteur" />
<xsd:element ref="pages" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>

>Retour à la TdM

### IV. Les types de données

#### 1. Introduction

Ainsi que nous l'avons déjà brièvement signalé, `XML Schema` permet de spécifier des types de données bien plus finement que le langage `DTD`. Il distingue notamment types simples et types complexes.

>Retour à la TdM

#### 2. Types simples

##### a. Généralités

Les types de données simples ne peuvent comporter ni attributs, ni éléments enfants. Il en existe de nombreux, prédéfinis, mais il est également possible d'en "dériver" de nouveaux (nous reviendrons plus loin sur cette fonctionnalité). Enfin, il est possible de déclarer des "listes" de types.

>Retour à la TdM

##### b. Bibliothèque de types intégrés

Nombreux sont les types prédéfinis dans la bibliothèque de types intégrés de `XML Schema.` la figure suivante en donne la hiérarchie, et leur liste détaillée figure sur le site du W3C.

Les types de données les plus simples (les chaînes de caractères) que permettaient les DTDs sont conservés, mais d'autres ont fait leur apparition. On pourra envisager, par exemple, dans un schéma décrivant un bon de commande, la déclaration d'un attribut `quantite` :

<xsd:attribute name="quantite" type="xsd:positiveInteger" use="default" value="1" />

... qui force la valeur de l'attribut à un être un entier positif. Un bon de commande `XML` suivant ce schéma, ayant une commande spécifiant `quantite="-3"` sera alors automatiquement refusé par le système. Un document respectant un tel schéma peut dès lors être enregistré directement dans une base de données, sans contrôle supplémentaire sur ce point.

>Retour à la TdM

##### c. Listes

Les types listes sont des suites de types simples (ou atomiques). `XML Schema` possède trois types de listes intégrés : `NMTOKENS`, `ENTITIES` et `IDREFS`. Il est également possible de créer une liste personnalisée, par « dérivation » de types existants. Par exemple,

<xsd:simpleType name="numéroDeTéléphone">
<xsd:list itemType="xsd:unsignedByte" />
</xsd:simpleType>

Un élément conforme à cette déclaration serait `<téléphone>01 44 27 60 11</téléphone>`.

Il est également possible d'indiquer des contraintes plus fortes sur les types simples ; ces contraintes s'appellent des « facettes ». Elles permettent par exemple de limiter la longueur de notre numéro de téléphone à 10 nombres. Nous reviendrons sur les facettes.

>Retour à la TdM

##### d. Unions

Les listes et les types simples intégrés ne permettent pas de choisir le type de contenu d'un élément. On peut désirer, par exemple, qu'un type autorise soit un nombre, soit une chaîne de caractères particuliers. Il est possible de le faire à l'aide d'une déclaration d'union. Par exemple, sous réserve que le type simple `numéroDeTéléphone` ait été préalablement défini (voir précédemment), on peut déclarer...

<xsd:simpleType name="numéroDeTéléphoneMnémoTechnique">
<xsd:union memberTypes="xsd:string numéroDeTéléphone" />
</xsd:simpleType>

Les éléments suivants sont alors des "instances" valides de cette déclaration :

<téléphone>18</téléphone>
<téléphone>Pompiers</téléphone>

>Retour à la TdM

#### 3. Les types complexes

##### a. Introduction

Un élément de type simple ne peut contenir pas de sous-élément. Il est nécessaire pour cela de le déclarer de type complexe. On peut alors déclarer des séquences d'éléments, des types de choix ou des contraintes d'occurences

>Retour à la TdM

##### b. Séquences d'éléments

Nous savons déjà comment, dans une `DTD`, nous pouvons déclarer un élément comme pouvant contenir une suite de sous-éléments dans un ordre déterminé. Il est bien sûr possible de faire de même avec un schéma.

On utilise pour ce faire l'élément `xsd:sequence`, qui reproduit l'opérateur `,` du langage `DTD`. Ainsi...

<xsd:complexType>
<xsd:sequence>
<xsd:element name="nom" type="xsd:string" />
<xsd:element name="prénom" type="xsd:string" />
<xsd:element name="dateDeNaissance" type="xsd:date" />
<xsd:element name="adresse" type="xsd:string" />
<xsd:element name="adresseElectronique" type="xsd:string" />
<xsd:element name="téléphone" type="numéroDeTéléphone" />
</xsd:sequence>
</xsd:complexType>

... est équivalent à une déclaration d'élément, dans une `DTD`, où apparaîtrait `(nom, prénom, dateDeNaissance, adresse, adresseElectronique, téléphone)`.

>Retour à la TdM

##### c. Choix d'élément

On peut vouloir modifier la déclaration de type précédente en stipulant qu'on doive indiquer soit l'adresse d'une personne, soit son adresse électronique. Pour cela, il suffit d'utiliser un élément `xsd:choice` :

<xsd:complexType name="typePersonne">
<sequence>
<xsd:element name="nom" type="xsd:string" />
<xsd:element name="prénom" type="xsd:string" />
<xsd:element name="dateDeNaissance" type="xsd:date" />
<xsd:choice>
<xsd:element name="adresse" type="xsd:string" />
<xsd:element name="adresseElectronique" type="xsd:string" />
</xsd:choice>
</sequence>
<xsd:element name="téléphone" type="numéroDeTéléphone" />
</xsd:complexType>

Ce connecteur a donc les mêmes effets que l'opérateur `|` dans une `DTD`.

>Retour à la TdM

##### d. L'élément all

Cet élément est une nouveauté par rapport aux `DTD`. Il indique que les éléments enfants doivent apparaître une fois (ou pas du tout), mais dans n'importe quel ordre. Cet élément `xsd:all` doit être un enfant direct de l'élément `xsd:complexType`. Par exemple...

<xsd:complexType>
<xsd:all>
<xsd:element name="nom" type="xsd:string" />
<xsd:element name="prénom" type="xsd:string" />
<xsd:element name="dateDeNaissance" type="xsd:date" />
<xsd:element name="adresse" type="xsd:string" />
<xsd:element name="adresseElectronique" type="xsd:string" />
<xsd:element name="téléphone" type="numéroDeTéléphone" />
</xsd:all>
</xsd:complexType>

... indique que chacun de ces éléments peut apparaître une fois ou pas du tout (équivalent de l'opérateur `?` dans une `DTD`), et que l'ordre des éléments n'a pas d'importance (cela n'a pas d'équivalent dans une `DTD`).

>Retour à la TdM

##### e. Indicateurs d'occurences

Dans une `DTD`, un indicateur d'occurence ne peut prendre que les valeurs 0, 1 ou l'infini. On peut forcer un élément `sselt` à être présent 378 fois, mais il faut pour cela écrire `(sselt, sselt..., sselt, sselt)` 378 fois. `XML Schema` permet de déclarer directement une telle occurence, car tout nombre entier non négatif peut être utilisé. Pour déclarer qu'un élément peut être présent un nombre illimité de fois, on utilise la valeur `unbounded`. Les attributs utiles sont `minOccurs` et `maxOccurs`, qui indiquent respectivement les nombres minimal et maximal de fois où un élément peut apparaître. Le tableau suivant récapitule les possibilités :

Dans une `DTD` | Valeur de `minOccurs` | Valeur de `maxOccurs`
--- | --- | ---
`*` | 0 | `unbounded`
`+` | 1 (pas nécessaire, valeur par défaut) | `unbounded`
`?` | 0 | 1 (pas nécessaire, valeur par défaut)
rien | 1 (pas nécessaire, valeur par défaut) | 1 (pas nécessaire, valeur par défaut)
impossible | nombre entier n quelconque | nombre entier m quelconque supérieur ou égal à n

Table 2. Liste des indicateurs d'occurence.

>Retour à la TdM

##### f. Création de type complexe à partir de types simples

Il est possible également de créer un type complexe à partir d'un type simple.

On peut avoir besoin de définir un élément contenant une valeur simple, et possédant un attribut, comme `<poids unite="kg">67</poids>`, par exemple. Un tel élément ne peut pas être déclaré de type simple, car il contient un attribut. Il faut dériver un type complexe à partir du type simple `positiveInteger` :

<xsd:complexType name="typePoids">
<xsd:simpleContent>
<xsd:extension base="xsd:positiveInteger">
<xsd:attribute name="unite" type="xsd:string" />
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>

L'élément `xsd:simpleContent` indique que le nouvel élément ne contient pas de sous-élément.

#### Exercice 1. Déclaration d'éléments

##### Énoncé

##### Correction

#### Exercice 2. Déclaration d'attributs

##### Énoncé

##### Correction

#### Exercice 3. Déclaration de types

##### Énoncé

##### Correction

>Retour à la TdM

### V. Espaces de nom

#### 1. Introduction

La notion d'espace de nom est complexe ; elle permet à un document `XML` quelconque d'utiliser les balises définies dans un schéma donné... quelconque. Nous avons déjà utilisé cette notion :

- dans les feuilles de style `XSL`, où nous utilisions des éléments préfixés par `xsl`, après avoir écrit `<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">`

- dans un schéma, où nous utilisions des éléments préfixés par `xsd`, après avoir écrit `<xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema">`.

Cela signifie que l'espace de nom auquel ces balises font référence, là où elles sont définies , est un schéma particulier que l'on peut consulter.

>Retour à la TdM

#### 2. Comment lier un fichier XML à un schéma ?

Nous n'allons pas ici entrer dans les détails de la notion d'espace de nom, mais simplement apprendre à valider un document `XML` d'après un `Schema XML`. On utilise pour ce faire le préfixe `xmlns`.

- Nous avons déjà vu le cas, équivalent à une `DTD` de type `PUBLIC`, où le schéma est... public. Un schéma est en effet un document `XML`, et on trouve dans son élément racine l'attribut `xmlns:xsd="http://www.w3.org/2001/XMLSchema"`. Cela signifie que dans le document, tous les éléments commençant par `xsd` sont référencés à cette URL. Donc si on a déposé un schéma à l'adresse http://www.monsite.org/collection_schemas/biblio, on peut l'appeler par `<xsd:biblio xmlns="http://www.monsite.org/collection_schemas/biblio">`.

- Dans le cas d'une référence locale, correspondant à une `DTD` de type `SYSTEM`, on fait référence au schéma dans le document `XML` en utilisant l'attribut `noNamespaceSchemaLocation`, par `<biblio xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="lien_relatif_vers_le_schema">`. Par exemple,

  `<biblio xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="biblio10.xsd">`.

>Retour à la TdM

### VI. Les dérivations

#### 1. Introduction

Les types simples et complexes permettent déjà de faire plus de choses que les déclarations dans le langage `DTD`. Il est possible de raffiner leur déclaration de telle manière qu'ils soient une "restriction" ou une extension d'un type déjà existant, en vue de préciser un peu plus leur forme. Nous allons nous limiter dans ce cours d'initiation à la restriction des types simples.

>Retour à la TdM

#### 2. Restriction de type

##### a. Généralités

On peut appliquer une dérivation aussi bien à un type simple, qu'à un type complexe. La dérivation par restriction permet de créer de nouveaux types simples à partir des types simples prédéfinis par le format `XML Schema`. On utilise pour ce faire des facettes, qui sont des contraintes supplémentaires appliquées à un type simple particulier.

Une facette permet de placer une contrainte sur l'ensemble des valeurs que peut prendre un type de base. Par exemple, on peut souhaiter créer un type simple, appelé `MonEntier`, limité aux valeurs comprises entre 0 et 99 inclus. On dérive ce type à partir du type simple prédéfini `nonNegativeInteger`, en utilisant la facette `maxExclusive`.

<xsd:simpleType name="monEntier">
<xsd:restriction base="nonNegativeInteger">
<xsd:maxExclusive value="100" />
</xsd:restriction>
</xsd:simpleType>

Il existe un nombre important de facettes qui permettent de :

- fixer, restreindre ou augmenter la longueur minimale ou maximale d'un type simple

- énumérer toutes les valeurs possibles d'un type

- prendre en compte des expressions régulières

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

- fixer la précision du type...

>Retour à la TdM

##### b. Exemples

On peut utiliser cette fonctionnalité pour reproduire ce qui, dans les `DTD`, permettait de limiter les valeurs de certains attributs. Ainsi...

<xsd:attribute name="jour" type="typeJourSemaine" use="required" />
<xsd:simpleType name="typeJourSemaine">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="lundi" />
<xsd:enumeration value="mardi" />
<xsd:enumeration value="mercredi" />
<xsd:enumeration value="jeudi" />
<xsd:enumeration value="vendredi" />
<xsd:enumeration value="samedi" />
<xsd:enumeration value="dimanche" />
</xsd:restriction>
</xsd:simpleType>

Pour limiter la longueur d'une chaîne :

<xsd:simpleType name="typeMotLangueFrancaise">
<xsd:restriction base="xsd:string">
<xsd:length value="21" />
</xsd:restriction>
</xsd:simpleType>

Plus complexe, on peut utiliser des expressions régulières, qui permettent de spécifier quels sont les caractères autorisés, à l'aide de l'élément `xsd:pattern`. Par exemple...

<xsd:simpleType name="typeAdresseElectronique">
<xsd:restriction base="xsd:string">
<xsd:pattern value="(.)+@(.)+" />
</xsd:restriction>
</xsd:simpleType>

Dans cet exemple, `(.)+` signifie que l'on peut mettre n'importe quel caractère au moins une fois, et qu'entre les deux chaînes doit impérativement apparaître le caractère `@`.

Un numéro ISBN est un référent international pour une publication. Il s'agit d'un numéro à 10 ou 13 chiffres. On peut le déclarer ainsi :

<xsd:simpleType name="typeISBN">
<xsd:restriction base="xsd:string">
<xsd:pattern value="[0-9]{10}" />
</xsd:restriction>
</xsd:simpleType>

Bien sûr, toutes les facettes ne sont pas acceptées par tous les types. Il serait fastidieux ici d'en donner la liste ; elle est accessible sur le site du W3C à l'adresse http://www.w3.org/TR/xmlschema-0/#SimpleTypeFacets.

>Retour à la TdM

### VII. Diverses autres fonctionnalités

#### 1. Inclusion de schémas

Un `Schema XML` a rapidement tendance à devenir verbeux. Autrement dit, il devient rapidement suffisamment long pour que sa complexité apparente rebute l'œil humain. Il est alors plus raisonnable de le scinder en plusieurs morceaux, chacun chargé de définir précisément tel ou tel sous-domaine du schéma. Il est en effet possible d'inclure plusieurs schémas dans un seul, à l'aide de l'élément `xsd:include`. Cela offre de plus l'énorme avantage de modulariser un schéma, et donc de pouvoir sans difficulté importer certaines parties à partir de schémas déjà existants. Nul besoin de réinventer la roue, ou de procéder à de massifs « copier/coller », en ayant besoin de tout reprendre à zéro à chaque fois que l'on fait une mise à jour.

Supposons par exemple que nous ayons défini le schéma d'une bibliographie dans le cadre plus général de l'écriture d'un mémoire. Ce `Schema XML` est stocké à l'URL http://www.monsite.org/schemas/biblio.xsd. Nous avons besoin d'une bibliographie pour une autre aplication -par exemple, dresser la liste d'un ensemble de ressources pour un site Web de e-formation. Nous pouvons inclure le schéma précédemment écrit à l'aide de la commande...

<xsd:include schemaLocation="http://www.monsite.org/schemas/biblio.xsd" />

Il s'agit d'une sorte de « copier-coller » du contenu de la bibliographie dans le schéma en cours d'écriture. La seule condition est que le `targetNameSpace` soit le même dans le `Schema XML` inclus et dans le `Schema XML` importateur.

>Retour à la TdM

#### 2. Documentation

`XML Schema` permet, outre l'utilisation des commentaires comme tout format `XML`, l'adjonction de documentation aux éléments.

La documentation à l'intention des lecteurs humains peut être définie dans des éléments `xsd:documentation`, tandis que les informations à l'intention de programmes doivent être incluses dans des éléments `xsd:appinfo`. Ces deux éléments doivent être placés dans un élément `xsd:annotation`. Ils disposent d'attributs optionnels : `xml:lang` et `source`, qui est une référence à une URI pouvant être utilisée pour identifier l'objectif du commentaire ou de l'information.

Les éléments `xsd:annotation` peuvent être ajoutés au début de la plupart des constructions. Voir par exemple le schéma biblio10.xsd déjà donné.

>Retour à la TdM

#### 3. Attribut null

Il est toujours préférable de pouvoir indiquer explicitement qu'un élément est non renseigné plutôt que d'omettre cet élément. La valeur null des bases de données relationnelles est utilisée dans ce but. `XML Schema` intègre un mécanisme similaire permettant d'indiquer qu'un élément peut être non renseigné.

Nous déclarons maintenant l'élément `courriel` comme pouvant être `null` à l'aide de l'attribut nullable du vocabulaire de `XML Schema` :

<personne>
<nom>Jean Dupont</nom>
<courriel xsi:null></courriel>
</personne>

Cet attribut doit toujours être préfixé par `xsi`. Quant à l'élément portant cet attribut, il peut contenir d'autres attributs, mais pas de sous-élément.

>Retour à la TdM

## Historique de ce document

- Le 11 mars 2008, version 1.34. Corrections de syntaxe et de fautes de frappe.
- Le 22 janvier 2008, version 1.33. Remplacement de la figure illustrant les types intégrés.
- Le 7 août 2007, version 1.32. Correction d'une erreur dans un exemple de déclaration de type d'attribut.
- Le 2 février 2007, version 1.31. Correction de fautes de frappe.
- Le 12 juillet 2005, version 1.30. Réécriture des exemples.
- Le 11 mars 2005, version 1.22. Corrections typographiques.
- Le 7 février 2005, version 1.21. Correction d'un lien.
- Le 18 janvier 2005, version 1.20. Réécriture partielle.
- Le 24 juin 2004, version 1.12. Corrections de liens.
- Le 16 juin 2004, version 1.11. Ajout des corrections des exercices.
- Le 31 mars 2004, version 1.10. Corrections typographiques et ajout d'une remarque sur la déclaration d'un élément de type texte contenant un (ou plusieurs) attribut(s).
- Le 28 mars 2004, version 1.00. Création du cours

## Bibliographie

### De l'auteur (G. Chagnon)

- XML, publié par Pearson Education en septembre 2007. Livre de cours et exercices écrit en collaboration avec Florent Nolot (Université de Reims). Consulter la fiche sur Eyrolles. Consulter la fiche sur Amazon.

## Conditions d'utilisation et licence

Cette création est mise à disposition par Gilles Chagnon sous un contrat Creative Commons.

Retour au menu