4. XML Schema

4.1. Introduction

La norme XML Schema est encore une norme W3C, écrite dans le but de remplacer les DTD. XML Schema possède trois avantages sur DTD :

c’est une façon plus complète et plus précise de spécifier des documents XML ;
on peut étendre un schéma par un autre schéma, à l’image des classes ;
le schéma lui-même est écrit en XML, répondant à un méta-schéma.

Cette norme est actuellement de plus en plus utilisée. Cela dit, pour des raisons de compatibilités ascendantes, les DTD restent encore très présentes.

4.2. Un premier schéma

Écrivons un schéma pour spécifier nos marins.

Exemple 14. Un premier exemple de XML schéma pour marin.xml

 <?xml version="1.0"?>

 <xsd:schema  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
             xmlns:galilee="http://www.galilee.org"
             targetNamespace="http://www.galilee.org"
>

	 <xsd:element  name="marin">
		 <xsd:complexType>
			 <xsd:sequence>
				 <xsd:element  name="nom"     type="xsd:string"/>
				 <xsd:element  name="prenom"  type="xsd:string"/>
			 </xsd:sequence>
		 </xsd:complexType>
	 </xsd:element>

 </xsd:schema>

La première remarque que l’on peut faire, est qu’un schéma XML est lui-même un document XML. Le nœud racine est le nœud schema, appartenant à l’espace de noms http://www.w3.org/2001/XMLSchema, préfixé par xsd. L’attribut targetNamespace indique que les éléments spécifiés dans ce schéma appartiennent à l’espace de noms http://www.galilee.org. Ce schéma doit être sauvegardé dans un fichier particulier, on peut par exemple le nommer marin.xsd.

4.3. Attacher un document XML à un schéma

Comment déclare-t-on que notre document XML marin est attaché au schéma enregistré dans marin.xsd ? Les choses se font en fait en deux temps.

On déclare tout d'abord que notre document XML marin.xml est attaché à ce schéma XML. En fait, ce que l'on déclare, c'est qu'une espace de noms est lui-même spécifié par un schéma XML, et que notre document est attaché à cet espace de noms.
Puis on écrit notre schéma, par exemple dans un fichier marin.xsd, dans lequel on indique que les objets attachés à ce schéma doivent vivre dans l'espace de noms spécifié.

On doit donc modifier la déclaration de notre document marin de la façon suivante.

Exemple 15. Attacher marin.xml à un XML schéma

<?xml version="1.0"?>

 <galilee:marin  xmlns:galilee="http://www.galilee.org"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xsi:schemaLocation=
                     "http://www.galilee.org 
                     http://www.galilee.org/ns/marin.xsd">

         <galilee:nom>Surcouf</galilee:nom>
         <galilee:prenom>Robert</galilee:prenom>
 </xsd:marin>

On sait que ce fichier est attaché au schéma disponible à l'URL http://www.galilee.org/ns/marin.xsd par la définition de l'attribut xsi:schemaLocation, qui comporte deux éléments : l'URI de l'espace de nom et l'URL du schéma XML correspondant.

4.4. Types simples

Les éléments d’un XML schema peuvent être de type simple ou complexe. Un élément simple est un élément qui ne possède pas de sous-éléments. Un élément complexe en possède. De plus, un type simple ne peut pas posséder d’attribut. Un élément, même s’il ne possède aucun sous-élément, ou aucun contenu, est de type complexe s’il possède au moins un attribut. Un élément de type simple se définit simplement par la déclaration suivante.

Exemple 16. Déclaration d'un élément de type simple

<xsd:element  name="nom"  type="xsd:string"/>

Un élément simple possède juste un nom et un type. Notons que ce type est une référence à un élément XML, se trouvant dans l’espace de noms http://www.w3.org/2001/XMLSchema, désigné par le préfixe xsd en l’occurrence. Il s’agit effectivement d’un type standard et unique pour tous les schémas XML que l’on peut imaginer, et correspondant à une chaîne de caractères. Le schéma XML de base déclare ainsi un certain nombre de types standard, dont voici les plus courants.

Exemple 17. Principaux types standard XML Schema

xsd:string
xsd:decimal
xsd:integer
xsd:boolean
xsd:date
xsd:time

De même que pour les DTD, il est possible de fixer une valeur par défaut pour les types simples, ainsi qu’une valeur fixée.

Exemple 18. Valeurs par défaut et valeur fixée pour un type simple

<xsd:element  name="nom"     type="xsd:string"  default="Surcouf"/>
 <xsd:element  name="prenom"  type="xsd:string"    fixed="Robert"/>

Notons tout de suite qu’il est possible de référencer un type en provenance de n’importe quel schéma lors de la définition d’un type simple, y compris d’un type défini dans le schéma courant. Nous verrons un exemple dans la suite.

4.5. Attribut

Un attribut lui-même est défini à partir d’un type simple dans le cas d’un XML schema. La syntaxe de définition d’un attribut ressemble à celle d’un élément simple.

Exemple 19. Définition d’un attribut

<xsd:attribute  name="age"  type="xsd:int"/>

De la même façon que pour les types simples, on peut déclarer une valeur par défaut pour un attribut, ou une valeur fixée, en ajoutant un attribut default ou fixed à l’élément xsd:attribute.

4.6. Restriction sur une déclaration

Un des points intéressants de la déclaration sous forme de XML Schema, est que l’on peut contraindre les valeurs des éléments et attributs que l’on définit. Montrons comment il est possible de déclarer que l'âge de nos marins doit être un entier positif, qui ne peut pas dépasser 150.

Exemple 20. Déclarations de restrictions sur l’âge

<xsd:attribute  name="age">
	 <xsd:simpleType>
		 <xsd:restriction  base="xsd:integer">
			 <xsd:minInclusive  value="0"/>
			 <xsd:maxInclusive  value="150"/>
		 </xsd:restriction>
	 </xsd:simpleType>
 </xsd:attribute>

Notons que l'on ne peut déclarer des restrictions que sur des éléments de type simpleType. Pour déclarer nos restrictions sur le type age, il faut utiliser le sous-élément restriction de simpleType. Cet élément prend lui-même d'autres sous-éléments dont minInclusive et maxInclusive. Dans notre cas, les restrictions sont énoncées sur le type standard integer. Tous les types peuvent être utilisés ici, pas seulement les types standard. Il existe de nombreux types de restrictions disponibles, on se reportera à la spécification pour en avoir la liste exhaustive. Dans cet exemple, on déclare le type de age par un sous-élément de l’élément attribute. Cette déclaration est légale. Toutefois, on peut aussi déclarer un tel type différemment, en donnant un nom au simpleType, et en y faisant référence dans la déclaration de notre attribut, comme dans l’exemple suivant.

Exemple 21. Déclaration nommée de restriction sur l’âge

<xsd:simpleType  name="ageType">
	 <xsd:restriction  base="xsd:integer">
		 <xsd:minInclusive  value="0"/>
		 <xsd:maxInclusive  value="150"/>
	 </xsd:restriction>
 </xsd:simpleType>

 <xsd:attribute  name="age"  type="ageType"/>

Dans cet exemple, on crée un type simple nommé ageType, et l’on y fait référence dans la déclaration de notre attribut. Cette deuxième façon de faire présente deux avantages :

il est possible d’utiliser notre déclaration ageType dans autant de types simples que l’on veut ;
cela permet de séparer la définition des types d’une part et leur utilisation, éventuellement de l’écrire dans un fichier séparé.

4.7. Types complexes

Un type complexe peut posséder des sous-éléments, et des attributs. Dès l’instant que l’on souhaite créer des éléments possédant des sous-éléments, ou possédant des attributs, alors ils doivent être définis par des types complexes. Il existe quatre types d’éléments complexes :

les éléments vides ;
les éléments ayant un contenu textuel ;
les éléments possédant des sous-éléments ;
les éléments ayant à la fois un contenu textuel et des sous-éléments.

Tous ces éléments peuvent en plus avoir ou non des attributs.

4.7.1. Élément sans contenu

Écrivons un élément sans contenu.

Exemple 22. Exemple d'un élément XML sans contenu

<marin  id="2"/>

Le schéma pour un tel élément est très simple. Il s’agit bien sûr d’un élément de type complexe.

Exemple 23. Schéma XML pour un élément vide

<xsd:complexType  name="marinType">
	 <xsd:attribute  name="id"  type="xsd:integer"/>
 </xsd:complexType>

Cet élément ne comporte pas de contenu ni de sous-élément, il n’y a donc pas lieu de préciser de sous-élément simpleContent ou complexContent.

4.7.2. Contenu textuel

Voici un exemple d'élément possédant un contenu textuel. Écrivons un schéma pour cet élément.

Exemple 24. Élément avec attribut et contenu entier

<longueur  unite="cm">10</longueur>

Cet élément peut prendre des valeurs entières, et possède un attribut unite. Il s’agit d’un contenu simple (pas de sous-éléments), extension du type entier. On peut donc l’écrire de la façon suivante.

Exemple 25. Schéma pour un élément avec attribut et contenu entier

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

4.7.3. Contenu composé de sous-éléments

Les sous-éléments sont spécifiés les uns après les autres, dans l’ordre dans lequel ils doivent apparaître, à la manière des DTD. On peut de plus préciser leur cardinalité. Reprenons l’exemple de notre élément marin, qui doit obligatoirement posséder un unique nom, un unique prénom, et autant de commentaires que l’on souhaite. Un commentaire est un élément complexe, possédant un contenu textuel et un attribut qui indique la langue dans laquelle ce commentaire est écrit. Voici donc son schéma.

Exemple 26. Schéma pour l'élément commentaire

<xsd:complexType  name="commentaireType">
	 <xsd:simpleContent>
		 <xsd:extension  base="xsd:string">
			 <xsd:attribute  name="lang"  type="xsd:string"/>
		 </xsd:extension>
	 </xsd:simpleContent>
 </xsd:complexType>

Notons qu’il existe un type lang présent dans l’espace de nom standard, défini comme pouvant prendre des valeurs normalisées, désignant les langues existantes. On aurait tout à fait pu l’utiliser à la place de xsd:string. On peut à présent créer notre schéma pour un élément marin, s’appuyant sur le commentaireType.

Exemple 27. Schéma pour un élément comportant des sous-éléments

<xsd:complexType  name="marinType">
	 <xsd:complexContent>
		 <xsd:sequence>
			 <xsd:element  name="nom"          type="xsd:string" 
							    minOccurs="1"  maxOccurs="1"/>
			 <xsd:element  name="prenom"       type="xsd:string" 
							    minOccurs="1"  maxOccurs="1"/>
			 <xsd:element  name="commentaire"  type="commentaireType" 
							    minOccurs="0"/>
		 </xsd:sequence>
	 </xsd:complexContent>
 </xsd:complexType>

Ce contenu complexe contient une séquence. Une séquence est composée d’éléments qui doivent apparaître dans cet ordre dans le document XML final. On remarquera deux choses sur ce schéma :

la référence interne à un type défini ailleurs dans le schéma : commentaireType ;
la spécification de la cardinalité, par l’utilisation des attributs minOccurs et maxOccurs de l’élément element.

Il est également possible de créer des éléments en tant que tel, à l’extérieur de séquences, et d’y faire référence ensuite dans les séquences. De la même façon que la définition de types internes, cela permet de réutiliser la définition d’un élément susceptible d’être utilisé dans plusieurs séquences différentes. Voyons cela sur le même exemple.

Exemple 28. Schéma pour un élément comportant des sous-éléments nommés

<xsd:element  name="nom"     value="xsd:string"/>
 <xsd:element  name="prenom"  value="xsd:string"/>

 <xsd:complexType  name="marinType">
	 <xsd:complexContent>
		 <xsd:sequence>
			 <xsd:element  ref="nom"     minOccurs="1"  maxOccurs="1"/>
			 <xsd:element  ref="prenom"  minOccurs="1"  maxOccurs="1"/>
			 <xsd:element  name="commentaire"  type="commentaireType" 
							    minOccurs="0"/>
		 </xsd:sequence>
	 </xsd:complexContent>
 </xsd:complexType>

4.7.4. Indicateurs

Sans le dire, nous avons utilisé un élément, sequence, qui appartient à une famille appelée les indicateurs . Les indicateurs permettent de préciser la façon dont les sous-éléments s’organisent dans un document XML. Il existe trois types d’indicateurs : les indicateurs d’ordre, les indicateurs d’occurrence et les indicateurs de groupe. Les indicateurs d’ordre sont les suivants :

l’indicateur sequence, présentés dans nos exemples, impose que les éléments apparaissent dans l’ordre spécifié par le schema ;
l’indicateur choice : permet à l’un des éléments d’être présent ;
l’indicateur all : impose que tous les éléments soient présents une et une seule fois, mais dans n’importe quel ordre.

Les indicateurs d’occurrence sont au nombre de deux, ils viennent en tant qu’attributs de sequence :

maxOccurs : indique le nombre maximal de sous-éléments de ce type (peut prendre la valeur unbounded) ;
minOccurs : indique le nombre minimal de sous-éléments de ce type (peut prendre la valeur 0).

Enfin les indicateurs de groupe, au nombre de deux également :

les groupes d’éléments : group ;
les groupes d’attributs : attributeGroup.

Les groupes permettent de déclarer des blocs de sous-éléments. Un élément xsd:group doit nécessairement contenir au moins un sous-élément all, choice ou sequence. On peut ensuite insérer ce groupe dans un autre sous-élément. Les groupes d’attributs fonctionnent de la même façon, sauf qu’ils définissent des blocs d’attributs réutilisables. On les utilise en tant que sous-éléments de complexType, afin de définir les attributs de nos éléments.

Exemple 29. Définition et utilisation d’un groupe

<xsd:group  name="PersonneGroup">
	 <xsd:sequence>
		 <xsd:element  name="nom"     type="xsd:string"/>
		 <xsd:element  name="prenom"  type="xsd:string"/>
	 </xsd:sequence>
 </xsd:group>

 <xsd:complexType  name="MarinType">
	 <xsd:sequence>
		 <xsd:group  ref="PersonneGroup"/>
		 <xsd:element  name="naissance"  value="xsd:date"/>
	 </xsd:sequence>
 </xsd:complexType>

4.7.5. Éléments composés de sous-éléments et de contenu

Ces éléments se définissent simplement par l’ajout d’un attribut mixed="true" à l’élément complexType de déclaration. Notons que ce contenu textuel ne peut pas être contraint par la déclaration du schéma. On ne peut donc employer cette approche si l’on souhaite écrire des contraintes sur le contenu textuel de l’élément que l’on spécifie.

4.8. Contraindre un contenu simple

Il existe trois types de contenu simple :

les types atomiques : ce sont des mots ou des nombres (par exemple), qui sont pris en tant que tel, et que l’on ne peut pas diviser ;
les types liste : ce sont des liste d’atomes, séparés par des espaces ;
les types union : qui peuvent être des listes de valeurs choisies dans un ensemble, ou une union d’ensembles. Par exemple, une taille de vêtement pourra être une valeur numérique comprise entre deux 2 et 60, ou bien l’un des mots « small », « medium », « large ».

Chaque nouveau type que l’on peut définir, se définit à partir d’un type existant, en utilisant une des extensions suivantes :

une restriction d’un type existant. Ce type existant sera le type de base de cette restriction. On peut construire comme cela des types entiers (par exemple), ne pouvant prendre des valeurs que dans un intervalle ou dans un ensemble défini.
une liste de types existants (atomique ou liste). Ces types sont appelés « item type ». On peut construire comme cela des listes séparées par des espaces.
une union d’un ou plusieurs types. Ces types sont appelés « membres » de cette union.

4.8.1. Type union

Voyons un exemple de schéma définissant un type union. L’union que l’on souhaite coder autorise les entiers compris entre 2 et 60, ou bien des chaînes de caractères pouvant prendre les valeurs « small », « medium » ou « large ».

Exemple 30. Schéma pour un type union

<xsd:simpleType  name="sizeType">
	 <xsd:union>
		 <xsd:simpleType>
			 <xsd:restriction  base="xsd:integer">
				 <xsd:minInclusive  value="2"/>
				 <xsd:maxInclusive  value="60"/>
			 </xsd:restriction>
		 </xsd:simpleType>
		 <xsd:simpleType>
			 <xsd:restriction  base="xsd:token">
				 <xsd:enumeration  value="small"/>
				 <xsd:enumeration  value="medium"/>
				 <xsd:enumeration  value="large"/>
			 </xsd:restriction>
		 </xsd:simpleType>
	 </xsd:union>
 </xsd:simpleType>

On aurait pu définir cette union différemment, en définissant tout d’abord deux types simples : DressSizeType et SMLSizeType, correspondant respectivement au premier type simple et au second, que nous avons définis dans cet exemple. Avec ces deux types simples, la définition de notre union devient le cas suivant.

Exemple 31. Schéma d’union référençant des types existants

<xsd:simpleType  name="sizeType">
	 <xsd:union  memberTypes="DressSizeType SMLSizeType"/>
 </xsd:simpleType>

4.8.2. Écrire une restriction sur une union

On peut écrire des restrictions sur une union telle que celle que l’on vient de créer. Voyons ceci sur un exemple.

Exemple 32. Restriction sur une union existante

<xsd:simpleType  name="smallSizeType">
	 <xsd:restriction  base="sizeType">
			 <xsd:enumeration  value="2"/>
			 <xsd:enumeration  value="4"/>
			 <xsd:enumeration  value="6"/>
			 <xsd:enumeration  value="small"/>
	 </xsd:restriction>
 </xsd:simpleType>

Enfin notons que lorsqu’une union est définie par plusieurs types, comme c’est le cas de notre exemple, on peut préciser à quel type l’élément que l’on écrit appartient. C’est ce que l’on fait sur ce dernier exemple.

Exemple 33. Association d’un élément à un type interne d’une union

<size  xsi:type="DressSizeType">12</size>

Dans ce cas, l’élément size appartient au type sizeType, mais on décide de le restreindre au type interne DressSizeType, ce qui est légal. Cela permet de le valider plus précisément.

4.8.3. Type Liste

Comme il a déjà été dit, un type liste est un ensemble de valeurs atomiques dans un même élément, séparée par des espaces. On définit une liste en définissant le type de ses éléments, de la façon suivante.

Exemple 34. Schéma pour un type liste

<xsd:simpleType  name="smallSizeType">
	 <xsd:list  itemType="DressSizeType"/> 
 </xsd:simpleType>

Écrivons un élément suivant ce schéma.

Exemple 35. Élément de type liste

<availableSizes>10 12 14</availableSizes>

On aura remarqué que l'attribut memberTypes de l'élément xsd:union est de type liste. On peut appliquer des restrictions sur une liste, que l'on appelle des facets . Il existe trois types de facets :

les length facets : cela consiste à restreindre le nombre d’éléments d’une liste ;
les enumeration facets : cela consiste à demander que les éléments d’une liste soient dans un ensemble fixé par le schéma ;
les pattern facets : cela consiste à demander que les éléments d’une liste correspondent à une expression régulière fixée par le schéma.

Voyons des exemples pour tous ces cas. On peut restreindre le nombre d’éléments dans une liste, par l’utilisation des contraintes length, minLength et maxLength.

Exemple 36. Schéma pour un length facet

<xsd:simpleType  name="AvailableSizesType">
	 <xsd:restriction>
		 <xsd:simpleType>
			 <xsd:list  itemType="SMLSizeType"/> 
		 </xsd:simpleType>
		 <xsd:maxLength  value="3"/>
	 </xsd:restriction>
 </xsd:simpleType>

Notons que sans aucune restriction de ce type, le nombre minimal d’éléments dans une liste est 0, ce qui rend légales vis-à-vis du schéma les listes vides, ou composées uniquement d’espaces. Voici le schéma qu’il faut écrire pour contraindre les éléments d’une liste à appartenir à un ensemble de tokens fixé.

Exemple 37. Schéma pour un enumeration facet

<xsd:simpleType  name="AvailableSizesType">
	 <xsd:restriction>
		 <xsd:simpleType>
			 <xsd:restriction  base="xsd:token">
				 <xsd:enumeration  value="small"/>
				 <xsd:enumeration  value="medium"/>
				 <xsd:enumeration  value="large"/>
			 </xsd:restriction>
		 </xsd:simpleType>
	 </xsd:restriction>
 </xsd:simpleType>

Notons que si l’on avait mis les éléments enumeration en tant que sous-éléments de simpleType plutôt que de restriction, on restreignait la liste complète à ne prendre que les trois valeurs small , medium et large . On interdisait par exemple à la liste de prendre la valeur « small medium ». Enfin on peut fixer un pattern facet en ajoutant un sous-élément pattern à l’élément restriction.

Exemple 38. Schéma pour un pattern facet

<xsd:simpleType  name="VectorType">
	 <xsd:restriction>
		 <xsd:simpleType>
			 <xsd:list  itemType="xsd:unisgnedInt"/>
		 </xsd:simpleType>
		 <xsd:pattern  value="((\d+\s*){3})*"/>
	 </xsd:restriction>
 </xsd:simpleType>

Dans cet exemple, on souhaite stocker des coordonnées de vecteurs à composantes entières et positives. On contraint notre chaîne de caractères à contenir autant de groupes de 3 entiers séparés par des espaces, que l’on souhaite.

4.8.4. Remarques

Plusieurs remarques doivent être faites sur l’utilisation de ces techniques en XML :

Il est dangereux de manipuler de telles listes lorsque les tokens peuvent eux-mêmes contenir des espaces. Dans notre exemple sur les tailles de vêtement, on voit tout de suite les problèmes qui se poseraient si l’on souhaitait créer une taille « extra large ».
En termes de design, on peut toujours remplacer une liste séparée par des espaces, par autant de sous-éléments. Le résultat sera plus lourd (en nombre de caractères), mais sera aussi plus facilement évolutif. Les deux écritures ne sont effectivement pas tout à fait équivalentes : dans le deuxième cas, on peut par exemple ajouter des attributs à nos éléments, ce qui est impossible dans le premier cas.
Les listes de listes ne sont pas légales en XML Schema. En revanche, les listes d’union le sont.