Les cinq caractères '<' U+2C, '>' U+2E, '&' U+26, ''' U+27 et '"' U+22 ont une signification particulière dans les documents XML. Les deux caractères '<' et '>' servent à délimiter les balises, ainsi que les commentaires et les instructions de traitement. Le caractère '&' marque le début des références aux entités générales. Pour introduire ces caractères dans le contenu du document, il faut utiliser des sections littérales ou les entités prédéfinies. Les caractères ''' et '"' servent également de délimiteurs, en particulier pour les valeurs des attributs. Dans ces cas, il faut encore avoir recours aux entités prédéfinies pour les introduire.

Le traitement XML des caractères d'espacement est simple dans un premier temps. Chaque caractère d'espacement est équivalent à un espace et plusieurs espaces consécutifs sont encore équivalents à un seul espace. C'est le comportement habituel des langages de programmation classiques. Dans un second temps, le traitement des caractères d'espacement par une application est commandé par l'attribut xml:space. Les caractères d'espacement sont l'espace ' ' U+20, la tabulation U+09 ('\t' en notation du langage C), le saut de ligne U+0A ('\n' en C) et le retour chariot U+0D ('\r' en C).

Les fins de lignes sont normalisées par l'analyseur lexical (parser en anglais). Ceci signifie que les différentes combinaisons de fin de ligne sont remplacées par un seul caractère U+0A avant d'être transmises à l'application. Cette transformation garantit une indépendance vis à vis des différents systèmes d'exploitation. Les combinaisons remplacées par cette normalisation sont les suivantes.

Les deux caractères U+85 et U+2028 ne peuvent être correctement décodés qu'après la déclaration de l'encodage des caractères par l'entête. Leur usage dans l'entête est donc déconseillé.

Les identificateurs sont utilisés en XML pour nommer différents objets comme les éléments, les attributs, les instructions de traitement. Ils servent aussi à identifier certains éléments par l'intermédiaire des attributs de type ID. XML distingue deux types d'identificateurs: les jetons et les noms XML. La seule différence est que les noms XML doivent commencer par certains caractères particuliers. Dans la terminologie XML, les jetons sont appelés NMTOKEN pour name token.

Les caractères autorisés dans les identificateurs sont tous les caractères alphanumériques, c'est-à-dire les lettres minuscules [a-z], majuscules [A-Z] et les chiffres [0-9] ainsi que le tiret '-' U+2D, le point '.' U+2E, les deux points ':' U+3A et le tiret souligné '_' U+5F. Un jeton est une suite quelconque de ces caractères. Un nom XML est un jeton qui, en outre, commence par une lettre [a-zA-Z], le caractère ':' ou le caractère '_'. Les deux caractères '-' et '.' ainsi que les chiffres ne peuvent pas apparaître au début des noms. Il n'y a pas, a priori, de limite à la taille des identificateurs mais certains logiciels peuvent en imposer une dans la pratique.

Le caractère ':' est réservé à l'utilisation des espaces de noms. De fait, il ne peut apparaître qu'une seule fois pour séparer un préfixe du nom local dans les noms des éléments et des attributs. Les espaces de noms amènent à distinguer les noms ayant un caractère ':', appelés noms qualifiés et les autres, appelés par opposition noms non qualifiés.

Les noms commençant par les trois lettres xml en minuscule ou majuscule, c'est-à-dire par une chaîne de [xX][mM][lL] sont réservés aux usages internes de XML. Ils ne peuvent pas être utilisés librement dans les documents mais ils peuvent cependant apparaître pour des utilisations spécifiques prévues par la norme. Les noms commençant par xml: comme xml:base font partie de l'espace de noms XML.

Quelques exemples d'identificateurs sont donnés ci-dessous.

La norme XML 1.1 prévoit que tout caractère Unicode de catégorie lettre peut apparaître dans les identificateurs. Il est, par exemple, possible d'avoir des noms d'éléments avec des caractères accentués. Il est cependant conseillé de se limiter aux caractères ASCII de [a-zA-Z] pour assurer une meilleure compatibilité. Beaucoup de logiciels ne gèrent pas les autres caractères dans les identificateurs.

Chaque caractère possède un point de code sur 32 bits mais un document ne contient pas directement ces points de code des caractères. Ce codage serait inefficace puisque chaque caractère occuperait 4 octets. Chaque document utilise un codage pour écrire les points de code des caractères. Il existe différents codages dont le codage par défaut UTF-8. Certains codages permettent d'écrire tous les points de code alors que d'autres permettent seulement d'écrire un sous-ensemble comme le BMP. Le codage utilisé par un document est indiqué dans l'entête de celui-ci. Les principaux codages utilisés par les documents XML sont décrits ci-dessous.

Le tableau suivant donne la suite d'octets pour le mot Hétérogène pour quelques codages classiques. Comme les points de code de x00 à xFF d'Unicode coïncident avec le codage des caractères de ISO-8859-1, le codage en UTF-16 est obtenu en insérant un octet nul 00 avant chaque octet du codage en ISO-8859-1. Le codage en UTF-32 est obtenu en insérant dans le codage en UTF-16 deux octets nuls avant chaque paire d'octets.

Les logiciels manipulant des documents XML doivent obligatoirement gérer les codages UTF-8 et UTF-16. Les autres codages sont facultatifs. Il est essentiel que le codage d'un document soit indiqué dans l'entête du document. Si un navigateur interprète, par exemple, la suite d'octets du codage UTF-8 du mot Hétérogène comme un codage en ISO-8859-1, il affiche la chaîne Hétérogène.

Bien que certains codages ne permettent pas de coder tous les points de code, il est néanmoins possible d'insérer n'importe quel caractère Unicode en donnant explicitement son point de code avec une des deux syntaxes suivantes. Ces syntaxes peuvent être utilisées pour n'importe quel point de code même si celui-ci peut être écrit avec le codage du document. Elles sont, en particulier, pratiques lorsque les éditeurs de texte affichent mal certains caractères. Les deux syntaxes prennent les formes &#point de code décimal; ou &#xpoint de code hexadécimal;. Le caractère Euro '€' peut par exemple être inséré par € ou €. Pour ces deux syntaxes, c'est le point de code du caractère qui est écrit en décimal ou en hexadécimal et non pas sa transcription dans le codage du document.

Certaines ligatures comme le caractère 'œ' U+153 sont considérées par Unicode comme un seul caractère plutôt que comme la fusion des deux caractères 'oe'. Il s'ensuit que les deux mots cœur et coeur sont, a priori, considérés comme distincts. Ce problème est résolu par l'utilisation de collations lors du traitement des documents. Une collation est une collection de règles qui établissent des équivalences entre des caractères ou des suites de caractères. Une collation peut, par exemple, déclarer que le caractère 'œ' U+153 est équivalent aux deux caractères 'oe' ou que la lettre 'ß' U+DF est équivalente aux deux lettres 'ss'. Une collation établit aussi l'ordre des caractères utilisé pour l'ordre lexicographique. Elle peut, par exemple, déclarer que le caractère 'é' se place entre les caractères 'e' et 'f'. La collation par défaut est basée sur les points de code des caractères. Le caractère 'é' U+E9 se trouve, pour cette collation, après le caractère 'z' U+7A et le mot zèbre est donc avant le mot étalon dans l'ordre lexicographique.

Le même caractère peut avoir plusieurs points de code. Cette ambiguïté provient du fait qu'Unicode a été construit en fusionnant plusieurs codages et qu'il tente de rester compatible avec chacun d'eux. Le caractère 'µ' est en même temps le caractère U+B5 qui provient de Latin-1 et le caractère U+3BC qui provient du bloc des caractères grecs. D'autres caractères peuvent avoir un point de code mais peuvent, en même temps, correspondre à une suite de plusieurs points de code. Le caractère 'ö' est, par exemple, le caractère U+F6 mais il correspond également à la suite U+6F U+308 formée du caractère 'o' suivi du caractère spécial tréma '¨' U+308. Ce codage multiple conduit à des problèmes, en particulier pour la comparaison des chaînes de caractères. Pour palier à ce problème, Unicode introduit des normalisations qui transforment les différents codages en un codage canonique. La normalisation la plus standard est la normalisation C. Celle-ci transforme, par exemple, la suite de caractères U+6F U+308 en le caractère 'ö' U+F6. La normalisation d'une chaîne de caractères peut être obtenue avec la fonction XPath normalize-unicode().

Un URI appelé URI de base est souvent attaché à un document ou à un fragment d'un document XML. Cet URI est généralement une URL. Il sert à résoudre les URL contenues dans le fragment de document, qu'elles soient relatives ou absolues. Cette résolution consiste à combiner l'URL de base avec ces URL pour obtenir des URL absolues qui permettent de désigner des documents externes.

Pour comprendre comment une URL de base se combine avec une URL, il faut d'abord comprendre la structure d'une URL. La description donnée ci-dessous se limite aux aspects indispensables pour appréhender la résolution des URL. Chaque URL se décompose en trois parties.

Figure 2.2. Structure d'une URL

La combinaison d'une URL de base base avec une autre URL url pour former une URL complète est réalisée de la façon suivante qui dépend essentiellement de la forme de la seconde URL url.

Les exemples ci-dessous illustrent les différents cas. On suppose que l'URL base est fixée égale à l'URL http://www.somewhere.org/Teaching/index.html. Pour chacune des valeurs de l'URL url, on donne la valeur de l'URL obtenue par combinaison de l'URL base avec l'URL url.

L'entête utilise une syntaxe <?xml ... ?> semblable à celle des instructions de traitement bien qu'elle ne soit pas véritablement une instruction de traitement. L'entête XML a la forme générale suivante.

<?xml version="..." encoding="..." standalone="..."?>

L'entête doit se trouver au tout début du document. Ceci signifie que les trois caractères '<?xml' doivent être les cinq premiers caractères du document, éventuellement précédés d'une marque d'ordre des octets.

Cette entête peut contenir trois attributs version, encoding et standalone. Il ne s'agit pas véritablement d'attributs car ceux-ci sont réservés aux éléments mais la syntaxe identique justifie ce petit abus de langage. Chaque attribut a une valeur délimitée par une paire d'apostrophes ''' ou une paire de guillemets '"'.

L'attribut version précise la version d'XML utilisée. Les valeurs possibles actuellement sont 1.0 ou 1.1. L'attribut encoding précise le codage des caractères utilisé dans le fichier. Les principales valeurs possibles sont US-ASCII, ISO-8859-1, UTF-8, et UTF-16. Ces noms de codage peuvent aussi être écrits en minuscule comme iso-8859-1 ou utf-8. L'attribut standalone précise si le fichier est autonome, c'est-à-dire s'il existe des déclarations externes qui affectent le document. La valeur de cet attribut peut être yes ou no et sa valeur par défaut est no. Les déclarations externes peuvent provenir d'une DTD externe où d'entités paramètres. Elles peuvent affecter le contenu du document en donnant, par exemple, des valeurs par défaut à des attributs. La valeur de l'attribut standalone influence également la prise en compte des caractères d'espacement dans les contenus purs lors de la validation par une DTD.

L'attribut version est obligatoire et l'attribut encoding l'est aussi dès que le codage des caractères n'est pas le codage par défaut UTF-8. Quelques exemples d'entête XML sont donnés ci-dessous.

<?xml version="1.0"?>
<?xml version='1.0' encoding='UTF-8'?>
<?xml version="1.1" encoding="iso-8859-1" standalone="no"?>

Lorsqu'un document est scindé en plusieurs fragments dans différents fichiers inclus par des entités externes ou par XInclude, chacun des fragments peut commencer par une entête. L'intérêt est de pouvoir spécifier un codage des caractères différent.

La déclaration de type définit la structure du document. Elle précise en particulier quels éléments peut contenir chacun des éléments. Cette déclaration de type peut prendre plusieurs formes suivant que la définition du type est interne, c'est-à-dire incluse dans le document ou externe. Elle a la forme générale suivante qui utilise le mot clé DOCTYPE.

<!DOCTYPE ... >

La forme précise de cette déclaration est explicitée au chapitre consacré aux DTD.

Figure 2.3. Composition d'un élément

Un élément est formé d'une balise ouvrante, d'un contenu et de la balise fermante correspondante. La balise ouvrante prend la forme <name> formée du caractère '<' U+3C, du nom name de l'élément et du caractère '>' U+3E. Des attributs peuvent éventuellement être ajoutés entre le nom et le caractère '>'. La balise fermante prend la forme </name> formée des deux caractères '</' U+3C et U+2F, du nom name de l'élément et du caractère '>'. Les noms des éléments sont des noms XML quelconques. Ils ne sont pas limités à un ensemble fixé de noms prédéfinis comme en HTML. Le contenu d'un élément est formé de tout ce qui se trouve entre la balise ouvrante et la balise fermante (cf. figure). Il peut être constitué de texte, d'autres éléments, de commentaires et d'instructions de traitement.

Dans la balise ouvrante, le caractère '<' doit être immédiatement suivi du nom de l'élément. En revanche, il peut y avoir des espaces entre le nom et le caractère '>'. La balise fermante ne peut pas contenir d'espace.

Figure 2.4. Élément avec un contenu vide

Lorsque le contenu est vide, c'est-à-dire lorsque la balise fermante suit immédiatement la balise ouvrante, les deux balises peuvent éventuellement se contracter en une seule balise de la forme <name/> formée du caractère '<', du nom name et des deux caractères '/>'. Cette contraction est à privilégier lorsque l'élément est déclaré vide par une DTD.

Figure 2.5. Imbrication des éléments

Comme chaque élément possède une balise ouvrante et une balise fermante, les balises vont nécessairement par paire. À toute balise ouvrante correspond une balise fermante et inversement. L'imbrication des balises doit, en outre, être correcte. Si deux éléments tag1 et tag2 ont un contenu commun, alors l'un doit être inclus dans l'autre. Autrement dit, si la balise ouvrante <tag2> se trouve entre les deux balises <tag1> et <tag1/>, alors la balise fermante </tag2> doit aussi se trouver entre les deux balises <tag1> et <tag1/> (cf. figure).

<parent>
  <sibling1> ... </sibling1>
  <sibling2> ... </sibling2>
  <self>
    <child1> ... <desc1></desc1> ... <desc2></desc2> ... </child1>
    <child2> ... </child2>
    <child3> ... <desc3><desc4> ... </desc4></desc3> ... </child3>
  </self>
  <sibling3> ... </sibling3>
</parent>

Figure 2.6. Liens de parenté

Dans l'exemple ci-dessus, le contenu de l'élément self s'étend de la balise ouvrante <child1> jusqu'à la balise fermante </child3>. Ce contenu comprend tous les éléments child1, child2 et child3 ainsi que les éléments desc1, desc2, desc3 et desc4. Tous les éléments qu'il contient sont appelés descendants de l'élément self. Parmi ces descendants, les éléments child1, child2 et child3 qui sont directement inclus dans self sans élément intermédiaire sont appelés les enfants de l'élément self. Inversement, l'élément parent qui contient directement self est appelé le parent de l'élément self. Les autres éléments qui contiennent l'élément self sont appelés les ancêtres de l'élément self. Les autres enfants sibling1, sibling2 et sibling3 de l'élément parent sont appelés les frères de l'élément self. Ces relations de parenté entre les éléments peuvent être visualisées comme un arbre généalogique (cf. figure).

Tout le corps du document doit être compris dans le contenu d'un unique élément appelé élément racine. Le nom de cet élément racine est donné par la déclaration de type de document si celle-ci est présente. L'élément bibliography est l'élément racine de l'exemple donné au début du chapitre.

  ...            ]  Commentaires et instructions de traitement  ⌉
<root-element>   ]  Balise ouvrante de l'élément racine         |   Corps
  ...            ⌉  Éléments, commentaires et                   |    du
  ...            ⌋  instructions de traitement                  |  document
</root-element>  ]  Balise fermante de l'élément racine         |
  ...            ]  Commentaires et instructions de traitement  ⌋

Les caractères spéciaux '<', '>' et '&' ne peuvent pas être inclus directement dans le contenu d'un document. Ils peuvent être inclus par l'intermédiaire des entités prédéfinies.

Il est souvent fastidieux d'inclure beaucoup de caractères spéciaux à l'aide des entités. Les sections littérales, appelées aussi sections CDATA en raison de leur syntaxe, permettent d'inclure des caractères qui sont recopiés à l'identique. Une section littérale commence par la chaîne de caractères '<![CDATA[' et se termine par la chaîne ']]>'. Tous les caractères qui se trouvent entre ces deux chaînes font partie du contenu du document, y compris les caractères spéciaux.

<![CDATA[Contenu avec des caractères spéciaux <, > et & ]]>

Une section CDATA ne peut pas contenir la chaîne de caractères ']]>' qui permet à l'analyseur lexical de détecter la fin de la section. Il est en particulier impossible d'imbriquer des sections CDATA.

Les balises ouvrantes peuvent contenir des attributs associés à des valeurs. L'association de la valeur à l'attribut prend la forme attribute='value' ou la forme attribute="value" où attribute et value sont respectivement le nom et la valeur de l'attribut. Chaque balise ouvrante peut contenir zéro, une ou plusieurs associations de valeurs à des attributs comme dans les exemples génériques suivants.

<tag attribute="value"> ... </tag>
<tag attribute1="value1" attribute2="value2"> ... </tag>

Voici ci-dessous d'autres exemples concrets de balises ouvrantes avec des attributs. Ces exemples sont respectivement tirés d'un document XHTML, d'un schéma XML et d'une feuille de style XSLT.

<body background='yellow'>
<xsd:element name="bibliography" type="Bibliography">
<a href="#{$node/@idref}">

Lorsque le contenu de l'élément est vide et que la balise ouvrante et la balise fermante sont contractées en une seule balise, celle-ci peut contenir des attributs comme la balise ouvrante.

<hr style="color:red; height:15px; width:350px;" />
<xsd:attribute name="key" type="xsd:NMTOKEN" use="required"/>

Le nom de chaque attribut doit être un nom XML. La valeur d'un attribut peut être une chaîne quelconque de caractères délimitée par une paire d'apostrophes ''' ou une paire de guillemets '"'. Elle peut contenir les caractères spéciaux '<', '>', '&', ''' et '"' mais ceux-ci doivent nécessairement être introduits par les entités prédéfinies. Si la valeur de l'attribut est délimitée par des apostrophes ''', les guillemets '"' peuvent être introduits directement sans entité et inversement.

<xsl:value-of select="key('idchapter', @idref)/title"/>
<xsl:if test='@quote = "&apos;"'>

Comme des espaces peuvent être présents dans la balise après le nom de l'élément et entre les attributs, l'indentation est libre pour écrire les attributs d'une balise ouvrante. Aucun espace ne peut cependant séparer le caractère '=' du nom de l'attribut et de sa valeur. Il est ainsi possible d'écrire l'exemple générique suivant.

<tag attribute1="value1" 
     attribute2="value2"
     ...
     attributeN="valueN">
  ...
</tag>

L'ordre des attributs n'a pas d'importance. Les attributs d'un élément doivent avoir des noms distincts. Il est donc impossible d'avoir deux occurrences du même attribut dans une même balise ouvrante.

Le bon usage des attributs est pour les meta-données plutôt que les données elles-mêmes. Ces dernières doivent être placées de préférence dans le contenu des éléments. Dans l'exemple suivant, la date proprement dite est placée dans le contenu alors que l'attribut format précise son format. La norme ISO 8601 spécifie la représentation numérique de la date et de l'heure.

<date format="ISO-8601">2009-01-08</date>

C'est une question de style de mettre les données dans les attributs ou dans les contenus des éléments. Le nom complet d'un individu peut, par exemple, être réparti entre des éléments firstname et surname regroupés dans un élément personname comme dans l'exemple ci-dessous.

<personname id="I666">
  <firstname>Gaston</firstname> 
  <surname>Lagaffe</surname>
</personname>

Les éléments firstname et surname peuvent être remplacés par des attributs de l'élément personname comme dans l'exemple ci-dessous. Les deux solutions sont possibles mais la première est préférable.

<personname id="I666" firstname="Gaston" surname="Lagaffe"/>

Il existe quatre attributs particuliers xml:lang, xml:space, xml:base et xml:id qui font partie de l'espace de noms XML. Lors de l'utilisation de schémas, ces attributs peuvent être déclarés en important le schéma à l'adresse http://www.w3.org/2001/xml.xsd.

Contrairement à l'attribut xml:id, les trois autres attributs xml:lang, xml:space et xml:base s'appliquent au contenu de l'élément. Pour cette raison, la valeur de cet attribut est héritée par les enfants et, plus généralement, les descendants. Ceci ne signifie pas qu'un élément dont le père a, par exemple, un attribut xml:lang a également un attribut xml:lang. Cela veut dire qu'une application doit prendre en compte la valeur de l'attribut xml:lang pour le traitement l'élément mais aussi de ses descendants à l'exception, bien sûr, de ceux qui donnent une nouvelle valeur à cet attribut. Autrement dit, la valeur de l'attribut xml:lang à prendre en compte pour le traitement d'un élément est celle donnée à cet attribut par l'ancêtre (y compris l'élément lui-même) le plus proche. Pour illustrer le propos, le document suivant contient plusieurs occurrences de l'attribut xml:lang. La langue du texte est, à chaque fois, donnée par la valeur de l'attribut xml:lang le plus proche.

<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
<book xml:lang="fr">
  <title>Livre en Français</title>
  <chapter>
    <title>Chapitre en Français</title>
    <p>Paragraphe en Français</p>
    <p xml:lang="en">Paragraph in English</p>
  </chapter>
  <chapter xml:lang="en">
    <title>Chapter in English</title>
    <p xml:lang="fr">Paragraphe en Français</p>
    <p>Paragraph in English</p>
  </chapter>
</book>

Ce qui a été expliqué pour l'attribut xml:lang vaut également pour deux autres attributs xml:space et xml:base. C'est cependant un peu différent pour l'attribut xml:base car la valeur à prendre en compte doit être calculée à partir de toutes les valeurs des attributs xml:base des ancêtres.

<p xml:lang="fr">Bonjour</p>
<p xml:lang="en-GB">Hello</p>
<p xml:lang="en-US">Hi</p>

<img src="element.png" alt="Élément"/>

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<book xml:base="http://www.somewhere.org/Teaching/index.html">
  <chapter xml:base="XML/chapter.html">
    <section xml:base="XPath/section.html"/>
    <section xml:base="/Course/section.html"/>
    <section xml:base="http://www.elsewhere.org/section.html"/>
  </chapter>
</book>

Les commentaires sont délimités par les chaînes de caractères '<!--' et '-->' comme en HTML. Ils ne peuvent pas contenir la chaîne '--' formée de deux tirets '-' et ils ne peuvent donc pas être imbriqués. Ils peuvent être présents dans le prologue et en particulier dans la DTD. Ils peuvent aussi être placés dans le contenu de n'importe quel élément et après l'élément racine. En revanche, ils ne peuvent jamais apparaître à l'intérieur d'une balise ouvrante ou fermante. Un exemple de document XML avec des commentaires partout où ils peuvent apparaître est donné ci-dessous.

<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>
<!-- Commentaire dans le prologue avant la DTD -->
<!DOCTYPE simple [
  <!-- Commentaire dans la DTD -->
  <!ELEMENT simple (#PCDATA) >
]>
<!-- Commentaire entre le prologue et le corps du document -->
<simple> 
  <!-- Commentaire au début du contenu de l'élément simple -->
  Un exemple simplissime
  <!-- Commentaire à la fin du contenu de l'élément simple -->
</simple>
<!-- Commentaire après le corps du document -->

Les caractères spéciaux '<', '>' et '&' peuvent apparaître dans les commentaires. Il est en particulier possible de mettre en commentaire des éléments avec leurs balises comme dans l'exemple ci-dessous.

<!-- <tag type="comment">Élément mis en commentaire</tag> -->

Les instructions de traitement sont destinées aux applications qui traitent les documents XML. Elles sont l'analogue des directives #... du langage C qui s'adressent au compilateur. Elles peuvent apparaître aux mêmes endroits que les commentaires à l'exception du contenu de la DTD.

Les instructions de traitement sont délimitées par les chaînes de caractères '<?' et '?>'. Les deux caractères '<?' sont immédiatement suivis du nom XML de l'instruction. Le nom de l'instruction est ensuite suivi du contenu. Ce contenu est une chaîne quelconque de caractères ne contenant pas la chaîne '?>' utilisée par l'analyseur lexical pour déterminer la fin de l'instruction. Le nom de l'instruction permet à l'application de déterminer si l'instruction lui est destinée.

Bien que le contenu d'une instruction puisse être quelconque, il est souvent organisé en une suite de paires param="value" avec une syntaxe imitant celle des attributs. Il incombe cependant à l'application traitant l'instruction de parser le contenu de celle-ci pour en extraire la liste des paires.

Les fichiers sources DocBook de cet ouvrage contiennent des instructions de traitement de la forme suivante. Ces instructions indiquent le nom du fichier cible à utiliser par les feuilles de styles pour la conversion en HTML.

<?dbhtml filename="index.html"?>

Une feuille de style XSLT peut être attachée à un document XML par l'intermédiaire d'une instruction de traitement de nom xml-stylesheet comme ci-dessous.

<?xml-stylesheet href="list.xsl" type="text/xsl" title="En liste"?> 

L'entête XML <?xml version=... ?> ressemble à une instruction de traitement de nom xml avec des paramètres version, encoding et standalone. Elle utilise en effet la même syntaxe. Elle n'est pourtant pas une instruction de traitement et elle ne fait pas partie du document.

L'exemple suivant contient uniquement un prologue avec l'entête XML et un élément de contenu vide. Les balises ouvrante <tag> et fermante </tag> ont été contractées en une seule balise <tag/>. Ce document n'a pas de déclaration de DTD.

<?xml version="1.0"?>
<tag/>

L'exemple aurait pu encore être réduit en supprimant l'entête XML mais celle-ci est fortement conseillée. Le retour à la ligne après l'entête aurait aussi pu être supprimé sans changer le contenu du document.

Cet exemple contient une déclaration de DTD qui permet de valider le document. Cette DTD déclare l'élément simple avec un contenu purement textuel.

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<!DOCTYPE simple [
  <!ELEMENT simple (#PCDATA)>
]>
<simple>Un exemple simplissime</simple>

Lorsque la DTD est incluse dans le document, sa déclaration prend la forme suivante où son contenu est encadré par des caractères crochets '[' et ']'.

<!DOCTYPE root-element [ declarations ]>

Les déclarations declarations constituent la définition du type du document. Dans l'exemple suivant de DTD, le nom de l'élément racine est simple. La DTD déclare en outre que cet élément ne peut contenir que du texte (Parsed Characters DATA) et pas d'autre élément.

<!DOCTYPE simple [
  <!ELEMENT simple (#PCDATA)>
]>

Lorsque la DTD est externe, celle-ci est contenue dans un autre fichier dont l'extension est généralement .dtd. Le document XML se contente alors de donner l'adresse de sa DTD pour que les logiciels puissent y accéder. L'adresse de de la DTD peut être donnée explicitement par une URL ou par un FPI (Formal Public Indentifier). Les FPI sont des noms symboliques donnés aux documents. Ils sont utilisés avec des catalogues qui établissent les correspondances entre ces noms symboliques et les adresses réelles des documents. Lorsqu'un logiciel rencontre un FPI, il parcourt le catalogue pour le résoudre, c'est-à-dire déterminer l'adresse réelle du document. Les catalogues peuvent contenir des adresses locales et/ou des URL. Ils constituent donc une indirection qui facilite la maintenance. Lorsqu'un document, une DTD par exemple, est déplacé, il suffit de modifier les catalogues plutôt que tous les documents qui référencent le document.

  type//owner//desc//lang

  -//W3C//DTD XHTML 1.0 Strict//EN
  -//OASIS//DTD Entity Resolution XML Catalog V1.0//EN
  ISO/IEC 10179:1996//DTD DSSSL Architecture//EN

  urn:publicid:-:W3C:DTD+XHTML+1.0+Strict:EN

<!DOCTYPE root-element PUBLIC "fpi" "url">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<!DOCTYPE root-element SYSTEM "url">

<!DOCTYPE bibliography SYSTEM 
    "http://www.omega-one.org/~carton/Enseignement/bibliography.dtd">

<!DOCTYPE bibliography SYSTEM "bibliography.dtd">

Il est possible d'avoir simultanément une DTD externe adressée par URL ou FPI et des déclarations internes. La DTD globale est alors formée des déclarations internes suivies des déclarations externes. La déclaration prend alors une des deux formes suivantes On retrouve un mélange de la syntaxe des DTD externes avec les mots clés SYSTEM et PUBLIC et de la syntaxe des DTD internes avec des déclarations encadrées par les caractères '[' et ']'.

<!DOCTYPE root-element SYSTEM "url" [ declarations ]>
<!DOCTYPE root-element PUBLIC "fpi" "url" [ declarations ]>

Il n'est pas possible de déclarer plusieurs fois le même élément dans une DTD. Lorsque la DTD est mixte, tout élément doit être déclaré dans la partie interne ou dans la partie externe mais pas dans les deux. En revanche, il est possible de déclarer plusieurs fois le même attribut. La première déclaration a priorité. Il est ainsi possible de donner une nouvelle déclaration d'un attribut dans la partie interne puisque celle-ci est placée avant la partie externe.

Les entités paramètres peuvent également être déclarées plusieurs fois dans une même DTD et c'est encore la première déclaration qui l'emporte. La DTD suivante déclare l'entité paramètre book.entries égale à la chaîne vide. Cette entité est ensuite utilisée dans la déclaration de l'élément book. Cette déclaration laisse la possibilité au document principal d'ajouter des enfants à l'élément book en donnant une nouvelle valeur à l'entité book.entries. La première ligne de cette DTD est une entête XML qui permet de déclarer le codage des caractères.

<?xml version="1.0" encoding="iso-8859-1"?>
<!-- DTD externe -->
<!-- Entité paramètre pour les enfants à ajouter à l'élément book -->
<!ENTITY % book.entries "">
<!ELEMENT bibliography (book)+>
<!ELEMENT book (title, author, year, publisher, isbn %book.entries;)>
<!ATTLIST book key NMTOKEN #REQUIRED>
<!ATTLIST book lang (fr | en) #IMPLIED>
<!ELEMENT title     (#PCDATA)>
<!ELEMENT author    (#PCDATA)>
<!ELEMENT year      (#PCDATA)>
<!ELEMENT publisher (#PCDATA)>
<!ELEMENT isbn      (#PCDATA)>

Le document suivant a une DTD mixte dont la partie externe est la DTD précédente. La partie interne de la DTD contient la déclaration de l'élément url. Elle contient également des nouvelles déclarations de l'entité paramètre book.entries et de l'attribut lang de l'élément book, qui devient ainsi obligatoire.

<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
<!DOCTYPE bibliography SYSTEM "mixed.dtd" [
  <!-- Ajout d'un enfant url à l'élément book -->
  <!ENTITY % book.entries ", url?">
  <!-- Redéclaration de l'attribut lang de l'élément book -->
  <!-- L'attribut devient obligatoire -->
  <!ATTLIST book lang (fr | en) #REQUIRED>
  <!-- Déclaration de l'élément url -->
  <!ELEMENT url (#PCDATA)>
]>
<bibliography>
  <book key="Michard01" lang="fr">
    <title>XML langage et applications</title>
    <author>Alain Michard</author>
    <year>2001</year>
    <publisher>Eyrolles</publisher>
    <isbn>2-212-09206-7</isbn>
    <url>http://www.editions-eyrolles/livres/michard/</url>
  </book>
  <book key="Marchal00" lang="fr">
    <title>XML by Example</title>
    <author>Benoît Marchal</author>
    <year>2000</year>
    <publisher>Macmillan Computer Publishing</publisher>
    <isbn>0-7897-2242-9</isbn>
  </book>
</bibliography>

Comme la valeur donnée à l'entité paramètre book.entries est la chaîne ", url?" (sans les guillemets '"'), la déclaration de l'élément book dans le fichier mixed.dtd devient équivalente à la déclaration suivante qui autorise un enfant url optionnel.

<!ELEMENT book (title, author, year, publisher, isbn, url?)>

Les entités générales sont les entités les plus courantes et les plus utiles puisqu'elles peuvent être utilisées dans le corps du document.

<!ENTITY name "fragment">
<!ENTITY name SYSTEM "url">
<!ENTITY name PUBLIC "fpi" "url">

<tag meta="attribute: &name;">Content: &name;</tag>

    <xsl:when test="contains($string, '&quot;')">

<!ENTITY aka   "also known as">
<!ENTITY euro  "&#x20AC;">
<!ENTITY rceil '<phrase condition="html">&#x2309;</phrase>
                <phrase condition="fo" role="symbolfont">&#xF8F9;</phrase>'>

<price currency="Euro (&euro;)">30 &euro;</price>

<!DOCTYPE book [
  <!-- Entités internes -->
  <!ENTITY mci "Michel Colucci &aka; 'Coluche'">
  <!ENTITY aka "also known as">
]>
<book>&mci;</book>

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE book [
  <!-- Entités externes -->
  <!ENTITY chapter1 SYSTEM "chapter1.xml">
  <!ENTITY chapter2 SYSTEM "chapter2.xml">
]>
<book>
  <!-- Inclusion du fichier chapter1.xml -->
  &chapter1;
  <!-- Inclusion du fichier chapter2.xml -->
  &chapter2;
</book>

Les entités paramètres sont des entités qui peuvent uniquement être utilisées à l'intérieur de la DTD. La terminologie est historique et provient de SGML. Ces entités ont le même rôle que les entités générales. Elles sont surtout utilisées pour apporter de la modularité aux DTD. La déclaration d'une entité paramètre prend une des trois formes suivantes où name est le nom de l'entité, fragment est un fragment de document, fpi et url sont un FPI et une URL.

<!ENTITY % name "fragment">
<!ENTITY % name SYSTEM "url">
<!ENTITY % name PUBLIC "fpi" "url">

La seule différence avec la déclaration d'une entité générale est la présence du caractère '%' entre le mot clé ENTITY et le nom de l'entité déclarée. Comme pour les entités générales, l'entité est dite interne lorsqu'elle est déclarée avec la première syntaxe. Elle est dite externe lorsqu'elle est déclarée avec une des deux dernières syntaxes. Les règles pour l'utilisation des apostrophes ''' et des guillemets '"' sont identiques à celles pour les valeurs d'attributs ou les entités générales.

L'entité name ainsi déclarée peut être référencée, c'est-à-dire utilisée, par %name; où le nom de l'entité est encadré les caractères '%' et ';'. Les entités paramètres peuvent uniquement être utilisées au sein de la DTD. Lorsque l'entité est interne, elle peut être utilisée dans les déclarations d'éléments, d'attributs et d'autres entités. Cette utilisation est limitée à la partie externe de la DTD. Lorsque l'entité est externe, elle est utilisée en dehors des déclarations pour inclure des déclarations provenant du document référencé par l'entité. L'exemple suivant définit deux entités paramètres idatt et langatt permettant de déclarer des attributs id et xml:lang facilement.

<!-- Déclaration de deux entités paramètres -->
<!ENTITY % idatt   "id ID #REQUIRED">
<!ENTITY % langatt "xml:lang NMTOKEN 'fr'">

<!-- Utilisation des deux entités paramètres -->
<!ATTLIST chapter %idatt; %langatt;>
<!ATTLIST section %langatt;>

Les entités paramètres ajoutent de la modularité qui est surtout nécessaire dans l'écriture de DTD de grande taille. Dans l'exemple précédent, l'attribut id pourrait être remplacé partout par un attribut xml:id en changeant uniquement la définition de l'entité paramètre idatt. Un autre exemple d'utilisation des entités paramètres est donné avec les DTD mixtes. Les entités externes permettent d'inclure une partie de DTD provenant d'un document externe comme dans l'exemple suivant.

<!-- Entité paramètre pour inclure la DTD principale -->
<!ENTITY % main SYSTEM "main.dtd">
<!-- Inclusion du fichier main.dtd -->
%main;

Le contenu d'un élément est pur lorsqu'il ne contient aucun texte et qu'il est uniquement constitué d'éléments qui sont ses enfants. Ces enfants peuvent, à leur tour, avoir des contenus textuels, purs ou mixtes. Un élément de contenu pur peut donc indirectement contenir du texte si celui-ci fait partie du contenu d'un de ses descendants. La déclaration d'un élément de contenu pur détermine quels peuvent être ses enfants et dans quel ordre ils doivent apparaître. Cette description est indépendante du contenu de ces enfants. Elle dépend uniquement des noms des enfants. Le contenu de chaque enfant est décrit par sa propre déclaration. Une déclaration d'élément prend la forme suivante.

<!ELEMENT element regexp>

Le nom de l'élément est donné par l'identifiant element. L'expression rationnelle regexp décrit les suites autorisées d'enfants dans le contenu de l'élément. Cette expression rationnelle est construite à partir des noms d'éléments en utilisant les opérateurs ',', '|', '?', '*' et '+' ainsi que les parenthèses '(' et ')' pour former des groupes. Les opérateurs ',' et '|' sont binaires alors que les opérateurs '?', '*' et '+' sont unaires et postfixés. Ils se placent juste après leur opérande, c'est-à-dire derrière le groupe auquel ils s'appliquent.

Le nom d'un élément signifie que cet élément doit apparaître dans le contenu. Les opérateurs principaux sont les deux opérateurs ',' et '|' qui expriment la mise en séquence et le choix. Un contenu est valide pour une expression de la forme block-1, block-2 s'il est formé d'un contenu valide pour block-1 suivi d'un contenu valide pour block-2. Un contenu est valide pour une expression de la forme block-1 | block-2 s'il est formé d'un contenu valide pour block-1 ou d'un contenu valide pour block-2. Les trois opérateurs '?', '*' et '+' permettent d'exprimer des répétitions. Un contenu est valide pour une expression de la forme block? s'il est vide ou formé d'un contenu valide pour block. Un contenu est valide pour une expression de la forme block* (respectivement block+) s'il est formé d'une suite éventuellement vide (respectivement suite non vide) de contenus valides pour block. La signification des cinq opérateurs est récapitulée par la table suivante.

Ces définitions sont illustrées par les exemples suivants.

<!-- Fichier "standalone.dtd" -->
<!ELEMENT list (item)+>
<!ELEMENT item (#PCDATA)>

<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
<!DOCTYPE list SYSTEM "standalone.dtd">
<list>
  <item>Item 1</item>
  <item>Item 2</item>
</list>

<!ELEMENT item ((item1, item2) | (item1, item3))>

<!ELEMENT item (item1, (item2 | item3))>

<!ELEMENT item ((item1, item2)*, item1)>

La déclaration de la forme suivante indique qu'un élément peut uniquement contenir du texte. Ce texte est formé de caractères, d'entités qui seront remplacées au moment du traitement et de sections littérales.

<!ELEMENT element (#PCDATA)>

Dans l'exemple suivant, l'élément text est de type #PCDATA.

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE texts [
  <!ELEMENT texts (text)*>
  <!ELEMENT text  (#PCDATA)>
]>
<texts>
  <text>Du texte simple</text>   
  <text>Une <![CDATA[ Section CDATA avec < et > ]]></text>   
  <text>Des entités &lt; et &gt;</text>   
</texts>

La déclaration de la forme suivante indique qu'un élément peut uniquement contenir du texte et les éléments element1, …, elementN. C'est la seule façon d'avoir un contenu mixte avec du texte et des éléments. Il n'y a aucun contrôle sur le nombre d'occurrences de chacun des éléments et sur leur ordre d'apparition dans le contenu de l'élément ainsi déclaré. Dans une telle déclaration, le mot clé #PCDATA doit apparaître en premier avant tous les noms des éléments.

<!ELEMENT element (#PCDATA | element1 | ... | elementN)*>

Dans l'exemple suivant, l'élément book possède un contenu mixte. Il peut contenir du texte et des éléments em et cite en nombre quelconque et dans n'importe quel ordre.

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE book [
  <!ELEMENT book (#PCDATA | em | cite)*>
  <!ELEMENT em   (#PCDATA)>
  <!ELEMENT cite (#PCDATA)>
]>
<book>
  Du <em>texte</em>, une <cite>citation</cite> et encore du <em>texte</em>.
</book>

La déclaration suivante indique que le contenu de l'élément element est nécessairement vide. Cet élément peut uniquement avoir des attributs. Les éléments vides sont souvent utilisés pour des liens entre éléments.

<!ELEMENT element EMPTY>

Des exemples d'utilisation d'éléments de contenu vide sont donnés à la section traitant des attributs de type ID, IDREF et IDREFS.

<!ELEMENT ref EMPTY>
<!ATTLIST ref idref IDREF #REQUIRED>

Dans un souci de portabilité, il est conseillé de contracter les balises ouvrante et fermante lorsqu'un élément est déclaré de contenu vide et de le faire uniquement dans ce cas.

La déclaration suivante n'impose aucune contrainte sur le contenu de l'élément element. En revanche, ce contenu doit, bien entendu, être bien formé et les éléments contenus doivent également être déclarés. Ce type de déclarations permet de déclarer des éléments dans une DTD en cours de mise au point afin de procéder à des essais de validation. En revanche, ces déclarations sont déconseillées dans une DTD terminée car elles conduisent à des modèles de documents trop laxistes.

<!ELEMENT element ANY>

Le type d'un attribut détermine quelles sont ses valeurs possibles. Les DTD proposent uniquement un choix fini de types pour les attributs. Le type doit en effet être pris dans la liste suivante. Les types les plus utilisés sont CDATA, ID et IDREF.

Le type le plus général est CDATA puisque toutes les valeurs correctes d'un point de vue syntaxique sont permises. Cet type est très souvent utilisé car il est approprié dès qu'il n'y a aucune contrainte sur la valeur de l'attribut.

Les types NMTOKEN et NMTOKENS imposent respectivement que la valeur de l'attribut soit un jeton ou une suite de jetons séparés par des espaces. Il est aussi possible d'imposer que la valeur de l'attribut soit dans une liste fixe de jetons. Il est impossible, avec une DTD, de restreindre les valeurs d'un attribut à une liste fixe de valeurs qui ne sont pas des jetons.

L'utilisation des trois types NOTATION, ENTITY et ENTITIES est réservée à l'usage des entités externes non XML et elle n'est pas détaillée dans cet ouvrage. L'utilisation des trois types ID, IDREF et IDREFS est développée à la section suivante.

Il est fréquent qu'il existe des liens entre les données d'un document XML. Il peut s'agir, par exemple, de références à d'autres parties du document. Les attributs de types ID, IDREF et IDREFS s'utilisent conjointement pour matérialiser ces liens au sein d'un document. Un attribut de type ID permet d'identifier de façon unique un élément du document. Les éléments ainsi identifiés peuvent alors être référencés par d'autres éléments grâce aux attributs de types IDREF et IDREFS. Ces attributs créent ainsi des liens entre des éléments ayant les attributs de types IDREF ou IDREFS et des éléments ayant les attributs de type ID. Ce mécanisme permet uniquement de créer des liens entre des éléments d'un même document. La norme XLink généralise ce mécanisme. Elle permet de créer des liens entre deux, voire même plus de fragments de documents XML provenant éventuellement de documents différents.

La valeur d'un attribut de type ID doit être un nom XML. La valeur de cet attribut doit être unique dans tout le document. Ceci signifie qu'un autre attribut de type ID d'un autre élément ne peut pas avoir la même valeur pour que le document soit valide. Un élément ne peut avoir qu'un seul attribut de type ID.

Les attributs de type ID sont utilisés par la fonction XPath id() qui retourne les nœuds identifiés par la valeur de leur attribut de type ID.

La valeur d'un attribut de type IDREF doit être un nom XML. Ce nom doit, en outre, être la valeur d'un attribut de type ID d'un (autre) élément pour que le document soit valide. La valeur d'un attribut de type IDREFS doit être une suite de noms séparés par des espaces. Chacun de ces noms doit, en outre, être la valeur d'un attribut de type ID d'un élément pour que le document soit valide.

Le document suivant illustre l'utilisation des attributs de type ID, IDREF et IDREFS qui est faite par DocBook pour les références internes. Son contenu est scindé en sections délimitées par les éléments section. Chacun de ces éléments a un attribut id de type ID. Le contenu des éléments section est constitué de texte et d'éléments ref et refs ayant respectivement un attribut idref de type IDREF et un attribut idrefs de type IDREFS. Ces éléments permettent, dans le contenu d'une section, de référencer une (par ref) ou plusieurs (par refs) autres sections. Il faut remarquer que les éléments ref et refs n'ont jamais de contenu. Ils sont déclarés vides en utilisant le mot clé EMPTY. Il appartient à l'application qui génère le document final d'ajouter du contenu qui peut être, par exemple, le numéro ou le titre de la section référencée.

<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
<!DOCTYPE book [
  <!ELEMENT book    (section)*>
  <!ELEMENT section (#PCDATA | ref | refs)*>
  <!ATTLIST section id ID #IMPLIED>
  <!ELEMENT ref     EMPTY>
  <!ATTLIST ref     idref  IDREF  #REQUIRED>
  <!ELEMENT refs    EMPTY>
  <!ATTLIST refs    idrefs IDREFS #REQUIRED>
]>
<book>
  <section id="sec0">Une référence <ref idref="sec1"/></section>
  <section id="sec1">Des références <refs idrefs="sec0 sec2"/></section>
  <section id="sec2">Section sans référence</section>
  <section id="sec3">Une auto-référence <refs idrefs="sec3"/></section>
</book>

Les attributs de type ID et IDREF permettent également de structurer un document. Si l'adresse et d'autres informations sont ajoutées à l'éditeur dans le document bibliography.xml, celles-ci sont recopiées dans chaque livre publié par l'éditeur. Cette duplication de l'information est bien sûr très mauvaise. Une meilleure approche consiste à scinder la bibliographie en deux parties. Une première partie contient les livres et une seconde partie les éditeurs avec les informations associées. Ensuite, chaque livre se contente d'avoir une référence sur son éditeur. Un attribut id de type ID est ajouté à chaque élément publisher de la seconde partie. Chaque élément publisher contenu dans un élément book est remplacé par un élément published ayant un attribut by de type IDREF.

<?xml version="1.0" encoding="iso-8859-1"?>
<bibliography>
  <books>
    <book key="Michard01" lang="fr">
      <title>XML langage et appplications</title>
      <author>Alain Michard</author>
      <year>2001</year>
      <isbn>2-212-09206-7</isbn>
      <url>http://www.editions-eyrolles/livres/michard/</url>
      <published by="id2680397"/>
    </book>
    <book key="Marchal00" lang="en">
      <title>XML by Example</title>
      <author>Benoît Marchal</author>
      <year>2000</year>
      <isbn>0-7897-2242-9</isbn>
      <published by="id2680427"/>
    </book>
    ...
  </books>
  <publishers>
    <publisher id="id2680397">
      <name>Eyrolles</name>
      <address>Paris</address>
    </publisher>
    <publisher id="id2680427">
      <name>Macmillan Computer Publishing</name>
      <address>New York</address>
    </publisher>
    ...
  </publishers>
</bibliography>

Beaucoup d'applications ne prennent pas en compte la DTD pour traiter un document. Il leur est alors impossible de savoir quels attributs sont de type ID, IDREF ou IDREFS. Elles utilisent souvent la convention qu'un attribut de nom id est implicitement de type ID. Une meilleure solution consiste à utiliser l'attribut xml:id qui est toujours de type ID (de type xsd:ID en fait).

Chaque déclaration d'attribut précise une valeur par défaut pour celui-ci. Cette valeur par défaut peut prendre une des quatre formes suivantes.

Beaucoup d'applications ne prennent pas en compte la DTD pour traiter un document XML. Ce comportement pose problème avec les valeurs par défaut et les valeurs fixes (utilisation de #FIXED) des attributs. Si l'attribut est absent pour un élément du document, l'application va considérer que l'attribut n'a pas de valeur bien que la DTD déclare une valeur par défaut. L'utilisation des valeurs par défaut est donc à éviter pour une portabilité maximale.

Voici quelques exemples de déclarations d'attributs avec, pour chacune d'entre elles, des valeurs valides et non valides pour l'attribut.

La première différence entre les schémas et les DTD est d'ordre syntaxique. La syntaxe des DTD est une syntaxe héritée de SGML qui est différente de la syntaxe XML pour le corps des documents. En revanche, la syntaxe des schémas est une syntaxe purement XML. Un schéma est, en effet, un document XML à part entière avec un élément racine xsd:schema et un espace de noms.

Les DTD manquent cruellement de précision dans la description des contenus des éléments. Cette lacune se manifeste surtout au niveau des contenus textuels et des contenus mixtes. Il est, par exemple, impossible d'imposer des contraintes sur les contenus textuels des éléments. Le seul type possible pour les contenus textuels est #PCDATA qui autorise toutes les chaînes de caractères. Les types pour les attributs sont un peu plus nombreux mais ils restent encore très limités. À l'inverse, les schémas possèdent une multitude de types prédéfinis pour les contenus textuels. Ces types couvrent les chaînes de caractères, les nombres comme les entiers et les flottants ainsi que les heures et les dates. Ces types peuvent, en outre, être affinés par des mécanismes de restriction et d'union. Il est possible de définir, à titre d'exemple, des types pour les entiers entre 1 et 12, les flottants avec deux décimales ou les chaînes d'au plus 16 caractères ne comportant que des chiffres et des tirets '-'.

Les DTD sont encore plus limitées dans la description des contenus mixtes. La seule possibilité est d'exprimer que le contenu d'un élément est un mélange, sans aucune contrainte, de texte et de certains éléments. Les schémas comblent cette lacune en permettant d'avoir des contenus mixtes aussi précis que les contenus purs qui décrivent l'ordre et les nombres d'occurrences des enfants d'un élément.

Dans une DTD, le contenu pur d'un élément est décrit directement par une expression rationnelle. Les schémas procèdent en deux étapes. Ils définissent des types qui sont ensuite associés aux éléments. Les schémas se distinguent des DTD par leurs possibilités de définir de nouveaux types. Il est d'abord possible de construire des types explicitement à la manière des DTD. Il existe ensuite des mécanismes permettant de définir un nouveau type à partir d'un autre type, soit prédéfini, soit déjà défini dans le schéma. Ce nouveau type est obtenu soit par extension soit par restriction du type de départ. L'extension consiste à enrichir le type en ajoutant du contenu et des attributs. La restriction consiste, à l'inverse, à ajouter des contraintes pour restreindre les contenus valides. Ces deux mécanismes permettent ainsi de construire une véritable hiérarchie de types semblable à l'approche orientée objet des langages comme Java ou C++.

Les schémas autorisent des facilités impossibles avec les DTD. La première est la possibilité d'avoir plusieurs éléments locaux avec des noms identiques mais avec des types et donc des contenus différents. Dans une DTD, un élément a une seule déclaration qui décrit ses contenus possibles pour toutes ses occurrences dans un document. Une deuxième facilité est formée des mécanismes de substitution de types et d'éléments. À titre d'exemple, un schéma peut prévoir qu'un élément puisse se substituer à un autre élément. Ces substitutions fonctionnent de pair avec la hiérarchie des types.

Les DTD ont une modularité très limitée et l'écriture de DTD d'envergure est un exercice difficile. Les seuls dispositifs mis à disposition des auteurs de DTD sont l'import de DTD externes et les entités paramètres. Les schémas possèdent plusieurs mécanismes destinés à une plus grande modularité. Le premier d'entre eux est la possibilité, pour les schémas, de définir des types par extension et restriction. Il existe également les groupes d'éléments et les groupes d'attributs.

Les DTD proviennent de SGML et sont antérieures aux espaces de noms. Pour cette raison, elles ne les prennent pas en compte. La déclaration d'un élément se fait en donnant le nom qualifié de l'élément avec le préfixe et le nom local. Ceci impose, dans les documents, d'associer l'espace de noms à ce même préfixe. Ceci est contraire à l'esprit des espaces de noms où le préfixe est juste une abréviation interchangeable pour l'URI de l'espace de noms. Les schémas, au contraire, prennent en compte les espaces de noms. Un schéma déclare d'abord un espace de noms cible. Les éléments et les attributs sont ensuite déclarés, dans le schéma, avec leur nom local. Un document qui mélange des éléments et des attributs provenant d'espaces de noms différents peut encore être validé à l'aide des différents schémas pour les espaces de noms.

L'élément racine xsd:schema peut avoir les attributs suivants. Ceux-ci permettent de spécifier l'espace de noms cible du schéma et de préciser quelques comportements par défaut du schéma.

Dans l'exemple suivant, le schéma déclare que l'espace de noms cible est identifié par l'URI http://www.omega-one.org/~carton et que tous les éléments doivent être qualifiés dans les documents valides. L'espace de noms par défaut est déclaré égal à l'espace de noms cible afin de simplifier l'écriture du schéma.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema targetNamespace="http://www.omega-one.org/~carton"
            elementFormDefault="qualified"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns="http://www.omega-one.org/~carton">
  ...

Il est possible dans un document de donner explicitement le schéma devant servir à le valider. On utilise un des attributs schemaLocation ou noNamespaceSchemaLocation dans l'élément racine du document à valider. Ces deux attributs se trouvent dans l'espace de noms des instances de schémas identifié par l'URI http://www.w3.org/2001/XMLSchema-instance. L'attribut schemaLocation est utilisé lors de l'utilisation d'espaces de noms alors que l'attribut noNamespaceSchemaLocation est utilisé lorsque le document n'utilise pas d'espace de noms

La valeur de l'attribut schemaLocation est une suite d'URI séparés par des espaces. Ces URI vont par paires et le nombre d'URI doit donc être pair. Le premier URI de chaque paire identifie un espace de noms et le second donne l'adresse du schéma à utiliser pour les éléments et attributs dans cet espace de noms. L'espace de noms identifié par le premier URI doit donc être l'espace de noms cible du schéma donné par le second. La valeur de l'attribut schemaLocation prend donc la forme générale suivante

schemaLocation="namespace1 schema1 namespace2 ... namespaceN schemaN"

où namespacei est l'espace de noms cible du schéma schemai.

Le logiciel qui effectue la validation se base sur la valeur de l'attribut schemaLocation pour chercher la définition de chaque élément ou attribut dans le schéma correspondant à son espace de noms.

La valeur de l'attribut noNamespaceSchemaLocation est simplement l'URL d'un unique schéma qui doit permettre de valider l'intégralité du document. Il n'est, en effet, pas possible de distinguer les éléments qui n'ont pas d'espace de noms.

Dans l'exemple suivant, le document déclare que le schéma se trouve dans le fichier local bibliography.xsd et que l'espace de noms cible de ce schéma est identifié par l'URI http://www.omega-one.org/~carton/.

<?xml version="1.0" encoding="iso-8859-1"?>
<bibliography xsi:schemaLocation="http://www.omega-one.org/~carton/
                                  bibliography.xsd"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  ...

L'élément xsd:annotation permet d'ajouter des commentaires dans un schéma. Il peut être enfant de l'élément xsd:schema pour des commentaires globaux. Il peut également être enfant des éléments xsd:element, xsd:attribute pour ajouter des commentaires aux déclarations d'éléments et d'atttributs ainsi que de xsd:simpleType et xsd:complexType pour ajouter des commentaires aux définitions de type. Contrairement aux commentaires XML, ces commentaires font partie à part entière du schéma XML et constituent sa documentation.

<xsd:annotation>
  <xsd:documentation xml:lang="fr">
    Commentaire en français
  </xsd:documentation>
  <xsd:appInfo>
    Information destinée aux applications
  </xsd:appInfo>
</xsd:annotation>

La déclaration la plus simple d'un élément prend la forme suivante.

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

où element et type sont respectivement le nom et le type de l'élément. Ce type peut être un des types prédéfinis comme xsd:string ou xsd:integer ou encore un type défini dans le schéma. L'exemple suivant déclare l'élément title de type xsd:string. Le nom du type doit être un nom qualifié comme ici par le préfixe xsd associé à l'espace de noms des schémas. Cette règle s'applique aussi lorsque le type est défini dans le schéma.

<xsd:element name="title" type="xsd:string"/>
<xsd:element name="title" type="tns:Title"/>

Lorsque le type est simple, il est possible de donner une valeur par défaut ou une valeur fixe à l'élément comme dans les deux exemples suivants. Il faut pour cela donner des valeurs aux attributs default ou fixed de l'élément xsd:element.

<xsd:element name="title" type="xsd:string" default="Titre par défaut"/>

<xsd:element name="title" type="xsd:string" fixed="Titre fixe"/>

Lors de la déclaration d'un élément, il est possible de décrire explicitement le type. La déclaration du type est alors le contenu de l'élément xsd:element. Le type est alors local et sa déclaration prend alors une des deux formes suivantes où element est le nom de l'élément déclaré.

<xsd:element name="element"> 
  <xsd:simpleType>
  ...
  </xsd:simpleType>
</xsd:element>

<xsd:element name="element"> 
  <xsd:complexType>
  ...
  </xsd:complexType>
</xsd:element>

Un élément global, c'est-à-dire dont la déclaration par xsd:element est enfant direct de l'élément xsd:schema, peut être utilisé par des définitions de type. Ces définitions de type se contentent de faire référence à l'élément global de la façon suivante. Ce mécanisme permet une certaine modularité dans l'écriture des schémas puisqu'il évite des répétitions.

<!-- Déclaration globale de l'élément title -->
<xsd:element name="title" type="Title"/>
...
<!-- Définition d'un type global ou local -->
<xsd:complexType ... >
  ...
  <!-- Utilisation de l'élément title -->
  <xsd:element ref="title"/>
  ...
</xsd:complexType>

Les deux attributs name et ref ne peuvent pas être présents simultanément dans l'élément xsd:element. Par contre, l'un des deux doit toujours être présent soit pour donner le nom de l'élément défini soit pour référencer un élément déjà défini.

Deux éléments définis non globalement dans un schéma peuvent avoir le même nom tout en ayant des types différents. Il s'agit en fait d'éléments différents mais ayant le même nom. Cette possibilité est absente des DTD où tous les éléments sont globaux et ne peuvent avoir qu'un seul type. Le schéma suivant définit deux éléments de même nom local mais de types xsd:string et xsd:integer. Le premier élément apparaît uniquement dans le contenu de l'élément strings alors que le second apparaît uniquement dans le contenu de l'élément integers. C'est donc le contexte qui permet de distinguer les deux éléments de nom local.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  ...
  <xsd:element name="strings">     
    <xsd:complexType>
      <xsd:sequence>
        <!-- Déclaration du premier élément local -->
        <xsd:element name="local" type="xsd:string" maxOccurs="unbounded"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>    
  <xsd:element name="integers">
    <xsd:complexType>
      <xsd:sequence>
        <!-- Déclaration du second élément local -->
        <xsd:element name="local" type="xsd:integer" maxOccurs="unbounded"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>    
</xsd:schema>

Un document valide pour le schéma précédent est le suivant.

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<lists>
  <strings>
    <local>Une chaîne</local>
    <local>A string</local>
  </strings>
  <integers>
    <local>-1</local>
    <local>1</local>
  </integers>
</lists>

D'autres exemples de schémas déclarant plusieurs éléments de même nom mais de types différents sont donnés pour les restrictions de types complexes à contenu complexe.

Les schémas possèdent de nombreux types prédéfinis. Certains, comme xsd:int et xsd:float, proviennent des langages de programmation, certains, comme xsd:date et xsd:time, sont inspirés de normes ISO (ISO 8601 dans ce cas) et d'autres encore, comme xsd:ID, sont hérités des DTD. Ces types autorisent l'écriture de schémas concis et très précis. Beaucoup d'entre eux pourraient être redéfinis par restriction de types de base mais leur présence comme types de base simplifie le travail.

5.5.1.3. Types pour les dates et les heures

Quelques types des schémas imposent des formats standards pour écrire les dates et les heures. Ils s'appuient sur la norme ISO 8601. Leur grand intérêt est d'imposer une écriture normalisée pour les dates et les heures et d'en faciliter ainsi le traitement.

xsd:time

Heure au format hh:mm:ss[.sss][TZ], par exemple 14:07:23. La partie fractionnaire .sss des secondes est optionnelle. Tous les autres champs sont obligatoires. Les nombres d'heures, minutes et de secondes doivent être écrits avec deux chiffres en complétant avec 0. L'heure peut être suivie d'un décalage horaire TZ qui est soit Z pour le temps universel soit un décalage commençant par + ou - comme -07:00.

xsd:date

Date au format YYYY-MM-DD, par exemple 2008-01-16. Tous les champs sont obligatoires.

xsd:dateTime

Date et heure au format YYYY-MM-DDThh:mm:ss comme 2008-01-16T14:07:23. Tous les champs sont obligatoires.

xsd:duration

Durée au format PnYnMnDTnHnMnS comme P1Y6M, P1M12DT2H et P1YD3H10S.

xsd:dayTimeDuration

Durée au format PnDTnHnMnS comme P7DT4H3M2S.

xsd:yearMonthDuration

Durée au format PnYnM comme P1Y6M.

xsd:gYear

Année du calendrier grégorien au format YYYY comme 2011.

xsd:gYearMonth

Année et mois du calendrier grégorien au format YYYY-MM comme 1966-06 pour juin 1966.

xsd:gMonth

Mois du calendrier grégorien au format MM comme 01 pour janvier.

xsd:gMonthDay

Jour et mois du calendrier grégorien au format MM-DD comme 12-25 pour le jour de Noël.

xsd:gDay

Jour (dans le mois) du calendrier grégorien au format DD comme 01 pour le premier de chaque mois.

Figure 5.2. Hiérarchie des types atomiques

Les types simples définissent uniquement des contenus textuels. Ils peuvent être utilisé pour les éléments ou les attributs. Ils sont introduits par l'élément xsd:simpleType. Un type simple est souvent obtenu par restriction d'un autre type défini. Il peut aussi être construit par union d'autres types simples ou par l'opérateur de listes. La déclaration d'un type simple a la forme suivante.

<xsd:simpleType ...>
  ...
</xsd:simpleType>

L'élément xsd:simpleType peut avoir un attribut name si la déclaration est globale. La déclaration du type se fait ensuite dans le contenu de l'élément xsd:simpleType comme dans l'exemple suivant.

<xsd:simpleType name="Byte">
  <xsd:restriction base="xsd:nonNegativeInteger">
    <xsd:maxInclusive value="255"/>
  </xsd:restriction>
</xsd:simpleType>

Les types complexes définissent des contenus purs (constitués uniquement d'éléments), des contenus textuels ou des contenus mixtes. Tous ces contenus peuvent comprendre des attributs. Les types complexes peuvent seulement être utilisés pour les éléments. Ils sont introduits par l'élément xsd:complexType. Un type complexe peut être construit explicitement ou être dérivé d'un autre type par extension ou restriction.

La construction explicite d'un type se fait en utilisant les opérateurs de séquence xsd:sequence, de choix xsd:choice ou d'ensemble xsd:all. La construction du type se fait directement dans le contenu de l'élément xsd:complexType et prend donc la forme suivante.

<!-- Type explicite -->
<xsd:complexType ...>
  <!-- Construction du type avec xsd:sequence, xsd:choice ou xsd:all -->
  ...
</xsd:complexType>

Si le type est obtenu par extension ou restriction d'un autre type, l'élément xsd:complexType doit contenir un élément xsd:simpleContent ou xsd:complexContent qui précise si le contenu est purement textuel ou non. La déclaration d'un type complexe prend alors une des deux formes suivantes.

<!-- Type dérivé à contenu textuel -->
<xsd:complexType ...>
  <xsd:simpleContent>
    <!-- Extension ou restriction -->
    ...
  </xsd:simpleContent>
</xsd:complexType>

<!-- Type dérivé à contenu pur ou mixte -->
<xsd:complexType ...>
  <xsd:complexContent>
    <!-- Extension ou restriction -->
    ...
  </xsd:complexContent>
</xsd:complexType>

Le contenu d'un élément est pur lorsqu'il ne contient que des éléments qui, eux-mêmes, peuvent à leur tour contenir du texte et/ou des éléments. Il est, au contraire, mixte lorsqu'il contient du texte autre que des caractères d'espacement en dehors de ses enfants. La construction de types pour les contenus mixtes est très facile et très souple avec les schémas. L'attribut mixed de l'élément xsd:complexType permet de construire un type avec du contenu mixte. Il faut, pour cela, lui donner la valeur true.

Le contenu d'un élément est valide pour un type déclaré mixte si le contenu devient valide pour le type non mixte correspondant lorsque tout le texte en dehors des enfants est supprimé. Dans l'exemple suivant, l'élément person doit contenir, un élément firstname et un élément lastname dans cet ordre. Puisque son type est déclaré mixte, il peut en outre contenir du texte comme ci-dessous.

<xsd:element name="person">     
  <xsd:complexType mixed="true">
    <xsd:sequence>
      <xsd:element name="firstname" type="xsd:string"/>
      <xsd:element name="lastname"  type="xsd:string"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>

Le document suivant est valide pour le schéma précédent. En revanche, il ne le serait pas sans la valeur true donnée à l'attribut mixed dans le schéma. Le contenu de l'élément person est valide car si on retire le texte en dehors de ses enfants firstname et lastname (texte en gras ci-dessous), on obtient un contenu valide pour le type sans mixed="true". Il serait, par exemple, impossible de changer l'ordre des enfants firstname et lastname car ce type spécifie qu'ils doivent apparaître dans cet ordre.

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<person>
  Prénom : <firstname>Albert</firstname>,
  Nom : <lastname>Einstein</lastname>.
</person>

Le schéma précédent n'a pas d'équivalent dans les DTD. Dès que le contenu d'un élément est déclaré mixte dans une DTD, il n'y a plus aucun contrôle sur l'ordre et le nombre d'occurrences de ses enfants. Le schéma suivant donne un exemple de contenu mixte équivalent à un contenu mixte d'une DTD.

<xsd:element name="book"> 
  <xsd:complexType mixed="true">
    <xsd:choice minOccurs="0" maxOccurs="unbounded">
      <xsd:element ref="em"/>
      <xsd:element ref="cite"/>
    </xsd:choice>
  </xsd:complexType>
</xsd:element>

L'exemple précédent est équivalent au fragment suivant de DTD.

<!ELEMENT book (#PCDATA | em | cite)* >

Si un type complexe déclare uniquement des attributs, le contenu de l'élément doit être vide. Par exemple, le type suivant déclare un type Link. Tout élément de ce type doit avoir un contenu vide et un attribut ref de type xsd:IDREF. Il s'agit en fait d'une extension du type vide par ajout d'attributs.

<xsd:element name="link" type="Link"/>
<xsd:complexType name="Link">
  <xsd:attribute name="ref" type="xsd:IDREF" use="required"/>
</xsd:complexType>

Le fragment de document suivant est valide pour le schéma précédent.

<link ref="id-42"/>

L'opérateur xsd:sequence définit un nouveau type formé d'une suite des éléments énumérés. C'est l'équivalent de l'opérateur ',' des DTD. Les éléments énumérés peuvent être soit des éléments explicites, soit des éléments référencés avec l'attribut ref soit des types construits récursivement avec les autres opérateurs. Dans l'exemple suivant, un élément book doit contenir les éléments title, author, year et publisher dans cet ordre.

<xsd:element name="book">
  <xsd:complexType>
    <xsd:sequence>
      <xsd:element name="title"     type="xsd:string"/>
      <xsd:element name="author"    type="xsd:string"/>
      <xsd:element name="year"      type="xsd:string"/>
      <xsd:element name="publisher" type="xsd:string"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>

Cette déclaration est équivalente à la déclaration suivante dans une DTD.

<!ELEMENT book (title, author, year, publisher)>

Le fragment de document ci-dessous est valide pour la déclaration de l'élément book.

<book>
  <title>XML langage et applications</title>
  <author>Alain Michard</author>
  <year>2001</year>
  <publisher>Eyrolles</publisher>
</book>

Un autre exemple de type construit avec l'opérateur xsd:sequence est donné comme exemple de type mixte. Le nombre d'occurences de chaque élément dans la séquence est 1 par défaut mais il peut être modifié par les attributs minOccurs et maxOccurs.

L'opérateur xsd:choice définit un nouveau type formé d'un des éléments énumérés. C'est l'équivalent de l'opérateur '|' des DTD. Dans l'exemple suivant, le contenu de l'élément publication doit être un des éléments book, article ou report. Ces trois éléments sont référencés et doivent donc être définis globalement dans le schéma.

<xsd:element name="publication">
  <xsd:complexType>
    <xsd:choice>
      <xsd:element ref="book"/>
      <xsd:element ref="article"/>
      <xsd:element ref="report"/>
    </xsd:choice>
  </xsd:complexType>
</xsd:element>

Cette déclaration est équivalente à la déclaration suivante dans une DTD.

<!ELEMENT publication (book | article | report)>

Un autre exemple de type construit avec l'opérateur xsd:choice est donné comme exemple de type mixte. Il est bien sûr possible d'imbriquer les opérateurs xsd:sequence et xsd:choice. Dans l'exemple suivant, l'élément book contient soit un seul élément author soit un élément authors contenant au moins deux éléments author. Cette dernière contrainte est imposée par la valeur 2 de l'attribut minOccurs.

<xsd:element name="book" minOccurs="1" maxOccurs="unbounded">
  <xsd:complexType>
  <xsd:sequence>
    <xsd:element name="title" type="xsd:string"/>
    <xsd:choice>
      <xsd:element name="author" type="xsd:string"/>
      <xsd:element name="authors">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element name="author" type="xsd:string" 
                         minOccurs="2" maxOccurs="unbounded"/>
          </xsd:sequence>
        </xsd:complexType>
      </xsd:element>
    </xsd:choice>
    <xsd:element name="year" type="xsd:string"/>
    ...
  </xsd:sequence>

Le document suivant est valide pour le schéma précédent.

<?xml version="1.0" encoding="iso-8859-1"?>
<bibliography>
  <!-- Livre à un seul auteur -->
  <book key="Michard01" lang="fr">
    <title>XML langage et applications</title>
    <author>Alain Michard</author>
    <year>2001</year>
    <publisher>Eyrolles</publisher>
  </book>
  <!-- Livre à deux auteurs -->
  <book key="ChagnonNolot07" lang="fr">
    <title>XML</title>
    <authors>
      <author>Gilles Chagnon</author>
      <author>Florent Nolot</author>
    </authors>
    <year>2007</year>
    <publisher>Pearson</publisher>
  </book>
</bibliography>

L'opérateur xsd:all n'a pas d'équivalent dans les DTD. Il définit un nouveau type dont chacun des éléments doit apparaître une fois dans un ordre quelconque. Dans la déclaration ci-dessous, les éléments contenus dans l'élément book peuvent apparaître dans n'importe quel ordre.

<xsd:element name="book">
  <xsd:complexType>
    <xsd:all>
      <xsd:element name="title"     type="xsd:string"/>
      <xsd:element name="author"    type="xsd:string"/>
      <xsd:element name="year"      type="xsd:string"/>
      <xsd:element name="publisher" type="xsd:string"/>
    </xsd:all>
  </xsd:complexType>
</xsd:element>

Le document suivant est un document valide où l'élément book a la déclaration précédente. L'ordre des enfants de l'élément book peut être variable.

<?xml version="1.0" encoding="iso-8859-1"?>
<bibliography>
  <book key="Michard01" lang="fr">
    <author>Alain Michard</author>
    <title>XML langage et applications</title>
    <publisher>Eyrolles</publisher>
    <year>2001</year>
  </book>
  <book key="Zeldman03" lang="en">
    <title>Designing with web standards</title>
    <author>Jeffrey Zeldman</author>
    <year>2003</year>
    <publisher>New Riders</publisher>
  </book>
  ...
</bibliography>

L'utilisation de l'élément xsd:all doit respecter quelques contraintes qui limitent fortement son intérêt. Un opérateur xsd:all ne peut pas être imbriqué avec d'autres constructeurs xsd:sequence, xsd:choice ou même xsd:all. D'une part, les seuls enfants possibles de xsd:all sont des éléments xsd:element. D'autre part, l'élément xsd:all est toujours enfant de xsd:complexType ou xsd:complexContent.

Les attributs minOccurs et maxOccurs des éléments apparaissant sous l'opérateur xsd:all ne peuvent pas avoir des valeurs quelconques. La valeur de l'attribut minOccurs doit être 0 ou 1 et la valeur de l'attribut maxOccurs doit être 1 qui est la valeur par défaut. Les attributs minOccurs et maxOccurs peuvent aussi apparaître comme attribut de xsd:all. Dans ce cas, leurs valeurs s'appliquent à tous les éléments xsd:element enfants de xsd:all. Les valeurs autorisées pour minOccurs sont 0 et 1 et la seule valeur autorisée pour maxOccurs est 1.

Dans la déclaration suivante de l'élément book, ses enfants peuvent apparaître dans n'importe quel ordre et chacun d'eux peut avoir 0 ou 1 occurrence.

<xsd:element name="book">
  <xsd:complexType>
    <xsd:all minOccurs="0">
      <xsd:element name="title"     type="xsd:string"/>
      <xsd:element name="author"    type="xsd:string"/>
      <xsd:element name="year"      type="xsd:string"/>
      <xsd:element name="publisher" type="xsd:string"/>
    </xsd:all>
  </xsd:complexType>
</xsd:element>

L'opérateur xsd:union définit un nouveau type simple dont les valeurs sont celles des types listés dans l'attribut memberTypes.

Le type IntegerOrUnbounded défini ci-dessous pourrait être le type de l'attribut maxOccurs tel qu'il pourrait apparaître dans un schéma pour les schémas. Les valeurs de ce type sont soit un entier positif ou nul du type xsd:nonNegativeInteger soit l'unique chaîne unbounded du type Unbounded. Ce dernier type est obtenu par restriction du type xsd:string.

<xsd:attribute name="maxOccurs" type="IntegerOrUnbounded"/>
<xsd:simpleType name="IntegerOrUnbounded">
  <xsd:union memberTypes="xsd:nonNegativeInteger Unbounded"/>
</xsd:simpleType>
<xsd:simpleType name="Unbounded">
  <xsd:restriction base="xsd:string">
    <xsd:enumeration value="unbounded"/>
  </xsd:restriction>
</xsd:simpleType>

Les types paramètres de l'opérateur d'union peuvent aussi être anonymes. Ils sont alors explicités directement dans le contenu de l'élément xsd:union comme dans l'exemple suivant qui conduit à une définition équivalence à celle de l'exemple précédent.

<xsd:simpleType name="IntegerOrUnbounded">
  <xsd:union memberTypes="xsd:nonNegativeInteger">
    <xsd:simpleType>
      <xsd:restriction base="xsd:string">
        <xsd:enumeration value="unbounded"/>
      </xsd:restriction>
    </xsd:simpleType>
  </xsd:union>
</xsd:simpleType>

L'opérateur xsd:list définit un nouveau type simple dont les valeurs sont les listes de valeurs du type simple donné par l'attribut itemType. Il ne s'agit pas de listes générales comme dans certains langages de programmation. Il s'agit uniquement de listes de valeurs séparées par des espaces. Ces listes sont souvent utilisées comme valeurs d'attributs. Les valeurs du type simple donné par itemType ne peuvent pas comporter de caractères d'espacement qui perturberaient la séparation entre les valeurs. L'exemple suivant définit des types pour les listes d'entiers et pour les listes de 5 entiers.

<!-- Type pour les listes d'entiers -->
<xsd:simpleType name="IntList">
  <xsd:list itemType="xsd:integer"/>
</xsd:simpleType>
<!-- Type pour les listes de 5 entiers -->
<xsd:simpleType name="IntList5">
  <xsd:restriction base="IntList">
    <xsd:length value="5"/>
  </xsd:restriction>
</xsd:simpleType>

Les attributs minOccurs et maxOccurs permettent de préciser le nombre minimal ou maximal d'occurrences d'un élément ou d'un groupe. Ils sont l'équivalent des opérateurs ?, * et + des DTD. Ils peuvent apparaître comme attribut des éléments xsd:element, xsd:sequence, xsd:choice et xsd:all. L'attribut minOccurs prend un entier comme valeur. L'attribut maxOccurs prend un entier ou la chaîne unbounded comme valeur pour indiquer qu'il n'y a pas de nombre maximal. La valeur par défaut de ces deux attributs est la valeur 1.

L'utilisation des attributs minOccurs et maxOccurs est illustrée par l'équivalent en schéma de quelques fragments de DTD

L'opérateur xsd:any permet d'introduire dans un document un ou des éléments externes au schéma, c'est-à-dire non définis dans le schéma. Le nombre d'éléments externes autorisés peut-être spécifié avec les attributs minOccurs et maxOccurs. La validation de ces éléments externes est contrôlée par l'attribut processContents qui peut prendre les valeurs strict, lax et skip. La valeur par défaut est strict. Lorsque la valeur est strict, les éléments externes doivent être validés par un autre schéma déterminé par l'espace de noms de ces éléments pour que le document global soit valide. Lorsque la valeur est skip, les éléments externes ne sont pas validés. La valeur lax est intermédiaire entre strict et skip. La validation des éléments externes est tentée mais elle peut échouer.

Le schéma suivant autorise zéro ou un élément externe dans le contenu de l'élément person après l'élément lastname.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="person">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="firstname" type="xsd:string"/>
        <xsd:element name="lastname"  type="xsd:string"/>
        <xsd:any processContents="lax" minOccurs="0"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

Le document suivant est valide pour le schéma précédent.

<?xml version="1.0" encoding="utf-8"?>
<person>
  <firstname>Elizabeth II Alexandra Mary</firstname>
  <lastname>Windsor</lastname>
  <title>Queen of England</title>
</person>

L'attribut namespace de l'élément xsd:any permet de préciser les espaces de noms auxquels doivent appartenir les éléments externes. Sa valeur doit être une suite d'URI identifiant des espaces de noms séparés par des espaces. Les valeurs particulières ##any, ##other, ##local et ##targetNamepspace peuvent aussi apparaître dans la liste des espaces de noms. La valeur par défaut ##any n'impose aucune restriction sur l'espace de noms des éléments externes. Les valeurs ##targetNamepspace et ##other autorisent respectivement des éléments dont l'espace de noms est égal ou différent de l'espace de noms cible du schéma. La valeur ##local autorise des éléments ayant des noms non qualifiés et n'appartenant donc à aucun espace de noms.

Dans le schéma suivant, l'élément externe ajouté dans le contenu de l'élément person doit appartenir à l'espace de noms XHTML.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="person">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="firstname" type="xsd:string"/>
        <xsd:element name="lastname"  type="xsd:string"/>
        <xsd:any processContents="lax" namespace="http://www.w3.org/1999/xhtml"
                 minOccurs="0"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

Le document suivant est valide pour le schéma précédent.

<?xml version="1.0" encoding="utf-8"?>
<person>
  <firstname>Victor</firstname>
  <lastname>Hugo</lastname>
  <html:ul xmlns:html="http://www.w3.org/1999/xhtml">
    <html:li>Romancier</html:li>
    <html:li>Poète</html:li>
    <html:li>Dramaturge</html:li>
  </html:ul>
</person>

Il existe également un élément xsd:anyAttribute pour autoriser des attributs externes au schéma.

Cette section aborde deux aspects techniques de la validation du contenu d'éléments purs. Ces deux aspects sont la présence des caractères d'espacement et le déterminisme des contenus. Ils ont déjà été abordés pour les DTD.

Lorsque le contenu d'un élément d'un élément pur est validé, les caractères d'espacement qui se trouvent hors de ses enfants sont ignorés. Ceci autorise l'indentation des documents XML sans perturber la validation.

Le contenu des éléments purs et mixtes doit être déterministe. Ceci signifie que la présence d'une balise ouvrante dans le contenu doit complètement déterminer d'où provient celle-ci dans la définition du type. Cette restriction est identique à celle portant sur les expressions définissant le contenu d'un élément pur dans une DTD. Le schéma suivant n'est pas valable car le contenu de l'élément item n'est pas déterministe. Une balise ouvrante <item1> peut provenir de la première ou de la seconde déclaration d'élément item1.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="item">
    <xsd:complexType>
      <xsd:choice>
        <xsd:sequence>
          <xsd:element name="item1" type="xsd:string"/>
          <xsd:element name="item2" type="xsd:string"/>
        </xsd:sequence>
        <xsd:sequence>
          <xsd:element name="item1" type="xsd:string"/>
          <xsd:element name="item3" type="xsd:string"/>
        </xsd:sequence>
      </xsd:choice>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

Les déclarations d'attributs se placent normalement dans les définitions de types complexes qui peuvent être globaux ou locaux. Les types simples ne peuvent pas avoir d'attributs. La définition d'un type complexe se compose de la description du contenu suivie de la déclaration des attributs. L'ordre de déclarations des attributs est sans importance puisque l'ordre des attributs dans une balise n'est pas fixe.

Dans l'exemple suivant, le type complexe List déclare deux attributs form et lang. Les déclarations de ces deux attributs se situent après la description du contenu du type List constitué d'une suite d'éléments item. Le type de l'attribut form est le type prédéfini xsd:string alors que le type de l'attribut lang est le type global et simple Lang défini dans la suite du schéma.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:complexType name="List">
    <!-- Contenu du type List -->
    <xsd:sequence maxOccurs="unbounded">
      <xsd:element name="item" type="xsd:string"/>
    </xsd:sequence>
    <!-- Déclaration des attributs locaux form et lang du type List -->
    <xsd:attribute name="form" type="xsd:string"/>
    <xsd:attribute name="lang" type="Lang"/>
  </xsd:complexType>
  <!-- Type global et simple Lang pour l'attribut lang -->
  <xsd:simpleType name="Lang">
    <xsd:restriction base="xsd:string">
      <xsd:length value="2"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:element name="list" type="List"/>
</xsd:schema>

Le fragment de document suivant est valide pour le schéma précédent.

<list form="long" lang="en">
  <item>Item 1</item>
  <item>Item 2</item>
</list>

Un attribut peut aussi être global lorsque sa déclaration par xsd:attribute est enfant direct de l'élément xsd:schema. Cet attribut peut alors être ajouté à différents types complexes. La définition du type utilise l'élément xsd:attribute avec un attribut ref qui remplace les deux attributs name et type. Cet attribut ref contient le nom de l'attribut global à ajouter. La déclaration globale d'un attribut est justifiée lorsque celui-ci a des occurrences multiples. Elle accroît la modularité des schémas en évitant de répéter la même déclaration dans plusieurs types.

Le schéma suivant déclare un attribut global lang de type xsd:language. Cet attribut est ajouté à deux reprises dans le type global Texts et dans le type anonyme de l'élément text.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <!-- Déclaration de l'attribut global lang -->
  <xsd:attribute name="lang"  type="xsd:language"/>
  <xsd:element   name="texts" type="Texts"/>
  <xsd:complexType name="Texts">
    <xsd:sequence>
      <xsd:element name="text" maxOccurs="unbounded">
        <xsd:complexType>
          <xsd:simpleContent>
            <xsd:extension base="xsd:string">
              <!-- Ajout de l'attribut lang au type anonyme -->
              <xsd:attribute ref="lang"/>
            </xsd:extension>
          </xsd:simpleContent>
        </xsd:complexType>
      </xsd:element>
    </xsd:sequence>
    <!-- Ajout de l'attribut lang au type Texts -->
    <xsd:attribute ref="lang"/>
  </xsd:complexType>
</xsd:schema>

Lorsqu'un schéma déclare un espace de noms cible, les attributs globaux appartiennent automatiquement à cet espace de noms. Ceci signifie d'abord qu'ils doivent être référencés par leur nom qualifié dans le schéma. L'ajout d'un attribut de nom name à un type complexe prend alors la forme suivante où le préfixe tns est associé à l'espace de noms cible du schéma.

<xsd:attribute ref="tns:name"/>

Cela signifie aussi qu'ils doivent avoir un nom qualifié dans les documents instance comme dans l'exemple suivant.

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<tns:texts tns:lang="fr" xmlns:tns="http://www.omega-one.org/~carton/">
  <text>Texte en français</text>
  <text tns:lang="en">Text in english</text>
</tns:texts>

Par défaut, un attribut est optionnel. Il peut être présent ou absent. Il peut aussi être rendu obligatoire ou interdit en donnant la valeur required ou prohibited à l'attribut use de l'élément xsd:attribute. L'attribut use peut aussi prendre la valeur optional. Cette valeur est très peu utilisée car c'est la valeur par défaut. La valeur prohibited est utile dans les restrictions de types pour modifier l'utilisation d'un attribut.

Les valeurs optional et required de l'attribut use sont donc équivalentes à #IMPLIED et #REQUIRED utilisés dans les déclarations d'attributs des DTD. Dans l'exemple suivant, les attributs lang, xml:id et dummy sont respecivement optionnel, obligatoire et interdit.

<xsd:attribute name="lang"   type="xsd:NMTOKEN" use="optional"/>
<xsd:attribute name="xml:id" type="xsd:ID"      use="required"/>
<xsd:attribute name="dummy"  type="xsd:string"  use="prohibited"/>

Le schéma suivant donne une utilisation réaliste de la valeur prohibited pour l'attribut use. Le type Date déclare un attribut format optionnel. Le type Date-8601 est une restriction du type Date. L'attribut format devient interdit et ne peut plus apparaître.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:complexType name="Date">
    <xsd:simpleContent>
      <xsd:extension base="xsd:date">
        <!-- Attribut format optionnel dans le type Date -->
        <xsd:attribute name="format" type="xsd:string"/>
      </xsd:extension>
    </xsd:simpleContent>
  </xsd:complexType>
  <xsd:complexType name="Date-8601">
    <xsd:simpleContent>
      <xsd:restriction base="Date">
        <!-- Attribut format interdit dans le type Date-8601 -->
        <xsd:attribute name="format" type="xsd:string" use="prohibited"/>
      </xsd:restriction>
    </xsd:simpleContent>
  </xsd:complexType>
  <xsd:element name="date" type="Date-8601"/>
</xsd:schema>

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:complexType name="Date">
    <xsd:simpleContent>
      <xsd:extension base="xsd:date">
        <!-- Attribut format optionnel dans le type Date -->
        <xsd:attribute name="format" type="xsd:string"/>
      </xsd:extension>
    </xsd:simpleContent>
  </xsd:complexType>
  <xsd:complexType name="Date-8601">
    <xsd:simpleContent>
      <xsd:restriction base="Date">
        <!-- Attribut format interdit dans le type Date-8601 -->
        <xsd:attribute name="format" type="xsd:string" use="prohibited"/>
      </xsd:restriction>
    </xsd:simpleContent>
  </xsd:complexType>
  <xsd:element name="date" type="Date-8601"/>
</xsd:schema>

Le fragment de document suivant est valide pour ce schéma. L'attribut format ne peut pas être présent dans l'élément date.

<date format="iso-8601"/></date>

Comme pour les éléments, il est possible de donner une valeur par défaut ou une valeur fixe à un attribut. La valeur de l'attribut default ou de l'attribut fixed de l'élément xsd:attribute permet de spécifier cette valeur. Il va de soi qu'une valeur par défaut n'est autorisée que si l'attribut est optionnel. Il est également interdit de donner simultanément une valeur par défaut et une valeur fixe. L'attribut fixed est équivalent à #FIXED utilisé dans les déclarations d'attribut des DTD. Dans le premier exemple suivant, la valeur par défaut de l'attribut lang est fr et dans le second exemple, sa valeur est fixée à la valeur en.

<xsd:attribute name="lang" type="xsd:NMTOKEN" default="fr"/>

<xsd:attribute name="lang" type="xsd:NMTOKEN" fixed="en"/>

De même qu'il existe un élément xsd:any pour autoriser des éléments externes, il existe aussi un élément xsd:anyAttribute pour autoriser des attributs externes au schéma. Il possède également les attributs processContents et namespace pour contrôler la validation et l'espace de noms des attributs externes ajoutés dans les documents.

Dans le schéma suivant, l'élément person peut avoir des attributs appartenant à l'espace de noms identifié par l'URI http://www.omega-one.org/~carton/.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="person">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="firstname" type="xsd:string"/>
        <xsd:element name="lastname"  type="xsd:string"/>
      </xsd:sequence>
      <xsd:anyAttribute processContents="lax"
                        namespace="http://www.omega-one.org/~carton/"/>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

Le document suivant est valide pour le schéma précédent.

<?xml version="1.0" encoding="utf-8"?>
<person tns:id="id42" xmlns:tns="http://www.omega-one.org/~carton/">
  <firstname>Victor</firstname>
  <lastname>Hugo</lastname>
</person>

L'extension d'un type simple ne permet pas de changer le contenu mais permet uniquement d'ajouter des attributs pour donner un type complexe à contenu simple. C'est en fait la seule façon d'obtenir un tel type s'il on exclut l'extension ou la restriction d'un type qui est déjà dans cette catégorie. Lors d'une extension d'un type simple, l'élément xsd:extension est toujours enfant d'un élément xsd:simpleContent. Les déclarations des attributs qui sont ajoutés sont placées dans le contenu de l'élément xsd:extension.

Le fragment de schéma suivant définit un type Price qui étend le type prédéfini xsd:decimal en lui ajoutant un attribut currency de type xsd:string

<xsd:complexType name="Price">
  <xsd:simpleContent>
    <xsd:extension base="xsd:decimal">
      <!-- Attribut ajouté -->
      <xsd:attribute name="currency" type="xsd:string"/>
    </xsd:extension>
  </xsd:simpleContent>
</xsd:complexType>
<xsd:element name="price" type="Price"/>

Le fragment de document suivant est valide pour le schéma précédent.

<price currency="euro">3.14</price>

Il est possible d'étendre un type complexe à contenu simple pour lui ajouter de nouveaux attributs. On obtient alors un nouveau type complexe à contenu simple qui possède les attributs du type de base et ceux déclarés par l'extension. L'extension d'un tel type est similaire à l'extension d'un type simple. L'élément xsd:extension est encore enfant d'un élément xsd:simpleContent. Les déclarations des attributs qui sont ajoutés sont placées dans le contenu de l'élément xsd:extension.

Dans le schéma suivant, le type Price est étendu en un type LocalType qui possède un nouvel attribut country de type xsd:string.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <!-- Type de base complexe à contenu simple -->
  <xsd:complexType name="Price">
    <xsd:simpleContent>
      <xsd:extension base="xsd:decimal">
        <!-- Attribut ajouté au type xsd:decimal -->
        <xsd:attribute name="currency" type="xsd:string"/>
      </xsd:extension>
    </xsd:simpleContent>
  </xsd:complexType>
  <!-- Extension du type de base -->
  <xsd:complexType name="LocalPrice">
    <xsd:simpleContent>
      <xsd:extension base="Price">
        <!-- Attribut ajouté au type Price -->
        <xsd:attribute name="country" type="xsd:string"/>
      </xsd:extension>
    </xsd:simpleContent>
  </xsd:complexType>
  <xsd:element name="price" type="LocalPrice"/>
</xsd:schema>

Le fragment de document suivant est valide pour le schéma précédent. Comme l'ordre des attributs est sans importance, l'attribut country aurait pu être placé avant l'attribut currency.

<price currency="euro" country="France">3.14</price>

L'extension d'un type complexe à contenu complexe consiste à ajouter du contenu et/ou des attributs. Le contenu est ajouté après le contenu du type de base. L'ajout d'attribut est semblable au cas des types complexes à contenu simple.

Dans le schéma suivant le type Fullname étend le type Name en lui ajoutant un élément title et un attribut id.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <!-- Type de base -->
  <xsd:complexType name="Name">
    <xsd:sequence>
      <xsd:element name="firstname" type="xsd:string"/>
      <xsd:element name="lastname"  type="xsd:string"/>
    </xsd:sequence>
  </xsd:complexType>
  <!-- Extension du type de base -->
  <xsd:complexType name="Fullname">
    <xsd:complexContent>
      <xsd:extension base="Name">
        <xsd:sequence>
          <!-- Ajout de l'élément title après firstname et lastname -->
          <xsd:element name="title" type="xsd:string"/>
        </xsd:sequence>
        <!-- Ajout de l'attribut id -->
        <xsd:attribute name="id" type="xsd:ID"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  ...
</xsd:schema>

L'élément title est ajouté après le contenu du type Name qui est constitué des deux éléments firstname et lastname. Le document suivant est valide pour le schéma précédent.

<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
<names>
  <fullname id="id40">
    <firstname>Alexander III Alexandrovich</firstname>
    <lastname>Romanov</lastname>
    <title>Tsar of Russia</title>
  </fullname>
  <fullname id="id52">
    <firstname>Elizabeth II Alexandra Mary</firstname>
    <lastname>Windsor</lastname>
    <title>Queen of England</title>
  </fullname>
</names>

Les schémas définissent un certain nombre de types de base. Tous les autres types simples sont obtenus par restriction directe ou multiple de ces différents types de base. La restriction des types simples est effectuée par l'intermédiaire de facettes qui imposent des contraintes aux contenus. Toutes les facettes ne s'appliquent pas à tous les types simples. On donne d'abord quelques exemples de restrictions classiques à l'aide des principales facettes puis une liste exhaustive des facettes.

<xsd:element name="year"> 
  <xsd:simpleType>
    <xsd:restriction base="xsd:integer">
      <xsd:minInclusive value="1970"/>
      <xsd:maxInclusive value="2050"/>
    </xsd:restriction>
  </xsd:simpleType>
</xsd:element>

<year>1966</year>

<xsd:attribute name="date">
  <xsd:simpleType>
    <xsd:restriction base="xsd:date">
      <!-- Date après le 31 décembre 2001 exclus -->
      <xsd:minExclusive value="2001-12-31"/>
    </xsd:restriction>
  </xsd:simpleType>
</xsd:attribute>

<event date="2006-06-24">...</event>

<xsd:element name="language" type="Language"/> 
<xsd:simpleType name="Language">
  <xsd:restriction base="xsd:language">
    <xsd:enumeration value="de"/>
    <xsd:enumeration value="en"/>
    <xsd:enumeration value="fr"/>
  </xsd:restriction>
</xsd:simpleType>

<language>en</language>

<xsd:simpleType name="ISBN">
  <xsd:restriction base="xsd:string">
    <xsd:pattern value="\d-\d{2}-\d{6}-[\dX]"/>
    <xsd:pattern value="\d-\d{3}-\d{5}-[\dX]"/>
    <xsd:pattern value="\d-\d{4}-\d{4}-[\dX]"/>
    <xsd:pattern value="\d-\d{5}-\d{3}-[\dX]"/>
  </xsd:restriction>
</xsd:simpleType>

<isbn>2-311-01400-6</isbn>

<xsd:simpleType name="Identifier">
  <xsd:restriction base="xsd:string">
    <xsd:pattern value="[:_A-Za-z][-.:_0-9A-Za-z]*"/>
  </xsd:restriction>
</xsd:simpleType>

<identifier>tns:id-42</identifier>

Les types complexes à contenu simple sont toujours obtenus par extension d'un type simple en lui ajoutant des attributs. La restriction d'un de ces types peut porter sur le type simple du contenu ou/et sur les attributs. Il est possible de remplacer le type du contenu par un type obtenu par restriction. Il est aussi possible de changer le type d'un attribut ou de modifier son utilisation. Un attribut optionnel peut, par exemple, devenir obligatoire. La restriction d'un type complexe à contenu simple donne toujours un type complexe à contenu simple.

Par défaut, le nouveau type complexe défini est identique au type de base. Pour modifier le type du contenu, l'élément xsd:restriction contient un élément xsd:simpleType qui donne explicitement le nouveau type du contenu. Ce type doit être obtenu par restriction du type qui définit le contenu du type de base.

Dans le schéma suivant, un type Base est défini par extension du type simple xsd:string en lui ajoutant un attribut format. Le type Derived est ensuite obtenu en restreignant le type du contenu aux chaînes d'au plus 32 caractères.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <!-- Type de base -->
  <xsd:complexType name="Base">
    <xsd:simpleContent>
      <xsd:extension base="xsd:string">
        <xsd:attribute name="format" type="xsd:string"/>
      </xsd:extension>
    </xsd:simpleContent>
  </xsd:complexType>
  <!-- Restriction du type de base -->
  <xsd:complexType name="Derived">
    <xsd:simpleContent>
      <xsd:restriction base="Base">
        <!-- Nouveau type pour le contenu du type Derived -->
        <xsd:simpleType>
          <xsd:restriction base="xsd:string">
            <xsd:maxLength value="32"/>
          </xsd:restriction>
        </xsd:simpleType>
      </xsd:restriction>
    </xsd:simpleContent>
  </xsd:complexType>
  <xsd:element name="base"    type="Base"/>
  <xsd:element name="derived" type="Derived"/>
</xsd:schema>

Dans le fragment de document ci-dessous, les deux éléments base et derived ont des contenus valides pour le schéma précédent.

<base format="string">Une chaîne très longue de plus de 32 caractères</base>
<derived format="string">Une de moins de 32 caractères</derived>

La restriction peut aussi changer les types des attributs et leur utilisation. Les attributs dont certaines propriétés changent sont redéclarés dans le nouveau type. Les autres restent implicitement inchangés. Le type d'un attribut peut être remplacé par un type obtenu par restriction. Ce type peut, bien sûr, être nommé ou anonyme. L'utilisation des attributs peut aussi être restreinte. Un attribut optionnel peut devenir interdit avec use="prohibited" ou obligatoire avec use="required". L'inverse est en revanche interdit. Il est également impossible d'ajouter de nouveaux attributs. Si un attribut possède une valeur par défaut ou une valeur fixe, celle-ci ne peut être ni modifiée ni supprimée.

Dans le schéma suivant, le type de base Base possède plusieurs attributs dont le type dérivé Derived modifie l'utilisation.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <!-- Type de base -->
  <xsd:complexType name="Base">
    <xsd:simpleContent>
      <xsd:extension base="xsd:string">
        <xsd:attribute name="decimal"  type="xsd:decimal"/>
        <xsd:attribute name="string"   type="xsd:string"/>
        <xsd:attribute name="optional" type="xsd:string"/>
        <xsd:attribute name="required" type="xsd:string" use="required"/>
        <xsd:attribute name="fixed"    type="xsd:string" fixed="Fixed"/>
      </xsd:extension>
    </xsd:simpleContent>
  </xsd:complexType>
  <!-- Restriction du type de base -->
  <xsd:complexType name="Derived">
    <xsd:simpleContent>
      <xsd:restriction base="Base">
        <!-- Restriction du type de l'attribut -->
        <xsd:attribute name="decimal" type="xsd:integer"/>
        <!-- Le nouveau type doit être dérivé du type initial -->
        <xsd:attribute name="decimal" type="xsd:string"/>
        <!-- Restriction du type de l'attribut avec un type anonyme -->
        <xsd:attribute name="string">
          <xsd:simpleType>
            <xsd:restriction base="xsd:string">
              <xsd:maxLength value="32"/>
            </xsd:restriction>
          </xsd:simpleType>
        </xsd:attribute>
        <!-- Restriction de l'utilisation de l'attribut -->
        <xsd:attribute name="optional" type="xsd:string" use="required"/>
        <!-- Impossible d'étendre l'utilisation de l'attribut -->
        <xsd:attribute name="required" type="xsd:string"/>
        <!-- Impossible de changer ou supprimer la valeur fixe -->
        <xsd:attribute name="fixed"    type="xsd:string"/>
        <!-- Impossible d'ajouter un nouvel attribut -->
        <xsd:attribute name="newattr"  type="xsd:string"/>
      </xsd:restriction>
    </xsd:simpleContent>
  </xsd:complexType>
  ...
</xsd:schema>

Il est encore possible de changer simultanément le type du contenu et certaines propriétés des attributs. Dans le schéma suivant, le type est restreint au chaînes d'au plus 32 caractères et le type xsd:decimal de l'attribut decimal est remplacé par le type xsd:integer qui est bien un type dérivé de xsd:decimal.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <!-- Type de base -->
  <xsd:complexType name="Base">
    <xsd:simpleContent>
      <xsd:extension base="xsd:string">
        <xsd:attribute name="decimal"   type="xsd:decimal"/>
        <xsd:attribute name="unchanged" type="xsd:string"/>
      </xsd:extension>
    </xsd:simpleContent>
  </xsd:complexType>
  <!-- Restriction du type de base -->
  <xsd:complexType name="Derived">
    <xsd:simpleContent>
      <xsd:restriction base="Base">
        <xsd:simpleType>
          <!-- Nouveau type pour le contenu du type Derived -->
          <xsd:restriction base="xsd:string">
            <xsd:maxLength value="32"/>
          </xsd:restriction>
        </xsd:simpleType>
        <!-- Restriction du type de l'attribut -->
        <xsd:attribute name="decimal"  type="xsd:integer"/>
        <!-- Attribut unchanged inchangé -->
      </xsd:restriction>
    </xsd:simpleContent>
  </xsd:complexType>
  <xsd:element name="base"    type="Base"/>
  <xsd:element name="derived" type="Derived"/>
</xsd:schema>

Dans le fragment de document ci-dessous, les deux éléments base et derived ont des contenus valides pour le schéma précédent.

<base decimal="3.14">Une chaîne très longue de plus de 32 caractères</base>
<derived decimal="3">Une de moins de 32 caractères</derived>

La restriction d'un type complexe permet d'imposer des contraintes aussi bien au contenu qu'aux attributs. La restriction doit rester fidèle au principe que tous les contenus possibles du type restreint doivent être valides pour le type de base. Il est, par exemple, possible de changer le type d'un élément en un type restreint ou de changer le nombre d'occurrences d'un éléments ou d'un bloc avec les attributs minOccurs et maxOccurs. Les restrictions portant sur les attributs sont identiques à celles possibles pour un type complexe à contenu simple.

Le nouveau type est défini en écrivant sa définition comme s'il s'agissait d'une première définition. Dans le schéma suivant, le type Shortname est obtenu par restriction du type Name. La valeur de l'attribut maxOccurs pour l'élément firstname passe de unbounded à 1. L'attribut id devient obligatoire.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="names">
    <xsd:complexType>
      <xsd:choice maxOccurs="unbounded">
        <xsd:element name="name"      type="Name"/>
        <xsd:element name="shortname" type="Shortname"/>
      </xsd:choice>
    </xsd:complexType>
  </xsd:element>
  <!-- Type de base -->
  <xsd:complexType name="Name">
    <xsd:sequence>
      <!-- Nombre illimité d'occurrences de l'élément firstname -->
      <xsd:element name="firstname" type="xsd:string" maxOccurs="unbounded"/>
      <xsd:element name="lastname"  type="xsd:string"/>
    </xsd:sequence>
    <xsd:attribute name="id" type="xsd:ID"/>
  </xsd:complexType>
  <!-- Restriction du type Name -->
  <xsd:complexType name="Shortname">
    <xsd:complexContent>
      <xsd:restriction base="Name">
        <xsd:sequence>
          <!-- Nombre limité d'occurrences de l'élément firstname -->
          <xsd:element name="firstname" type="xsd:string" maxOccurs="1"/>
          <xsd:element name="lastname"  type="xsd:string"/>
        </xsd:sequence>
        <!-- Attribut id obligatoire -->
        <xsd:attribute name="id" type="xsd:ID" use="required"/>
      </xsd:restriction>
    </xsd:complexContent>
  </xsd:complexType>
</xsd:schema>

Le document suivant est valide pour le schéma précédent.

<?xml version="1.0" encoding="iso-8859-1"?>
<names xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <name>
    <firstname>Elizabeth II</firstname>
    <firstname>Alexandra</firstname>
    <firstname>Mary</firstname>
    <lastname>Windsor</lastname>
  </name>
  <shortname id="id-42">
    <firstname>Bessiewallis</firstname>
    <lastname>Warfield</lastname>
  </shortname>
</names>

Il est aussi possible de restreindre un type complexe en remplaçant le type d'un élément par un type dérivé. Dans l'exemple suivant, le type de l'élément integer est xsd:integer dans le type Base. Ce type est remplacé par le type xsd:nonNegativeInteger dans le type Restriction. Le schéma suivant déclare deux éléments locaux de même nom integer mais de types différents.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:complexType name="Base">
    <xsd:sequence>
      <xsd:element name="integer" type="xsd:integer"/> 
    </xsd:sequence>
  </xsd:complexType>
  <xsd:complexType name="Restriction">
    <xsd:complexContent>
      <xsd:restriction base="Base">
        <xsd:sequence>
          <xsd:element name="integer" type="xsd:nonNegativeInteger"/>
        </xsd:sequence>
      </xsd:restriction>
    </xsd:complexContent>
  </xsd:complexType>
  ...
</xsd:schema>

Une restriction d'un type complexe à contenu complexe peut aussi supprimer un des choix possibles dans un élément xsd:choice. Dans l'exemple suivant, le choix integer a été supprimé dans le type Float.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <!-- Type de base -->
  <xsd:complexType name="Number">
    <xsd:choice>
      <xsd:element name="integer" type="xsd:integer"/> 
      <xsd:element name="float"   type="xsd:float"/> 
      <xsd:element name="double"  type="xsd:double"/> 
    </xsd:choice>
  </xsd:complexType>
  <!-- Restriction du type de base -->
  <xsd:complexType name="Float">
    <xsd:complexContent>
      <xsd:restriction base="Number">
        <xsd:choice>
          <!-- Suppression de l'élément integer -->
          <xsd:element name="float"   type="xsd:float"/> 
          <xsd:element name="double"  type="xsd:double"/> 
        </xsd:choice>
      </xsd:restriction>
    </xsd:complexContent>
  </xsd:complexType>
  ...
</xsd:schema>

Le document suivant est valide pour le schéma précédent. Il utilise une substitution de type avec l'attribut xsi:type pour changer le type de l'élément number en Float.

<?xml version="1.0" encoding="iso-8859-1"?>
<numbers xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <number>
    <integer>42</integer>
  </number>
  <number xsi:type="Float">
    <!-- Élément integer impossible -->
    <integer>42</integer>
    <float>3.14</float>
  </number>
</numbers>

L'annihilation est un mécanisme qui permet de mettre aucun contenu à un élément alors que le type de l'élément prévoit que le contenu est normalement non vide. Cette notion correspond à l'absence de valeur telle qu'elle existe dans les bases de données.

Le schéma doit d'abord autoriser le mécanisme en donnant la valeur true à l'attribut nillable de l'élément xsd:element. La valeur par défaut de cet attribut est false. Le document doit ensuite, explicitement, déclarer que l'élément n'a pas de valeur en donnant la valeur true à l'attribut xsi:nil qui est dans l'espace de noms des instances de schémas. Le contenu de l'élément doit alors être vide. Dans le schéma suivant, l'élément item est déclaré annihilable.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="list">     
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="item" nillable="true"
                     maxOccurs="unbounded" type="xsd:integer"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

Le document suivant est valide pour ce schéma. L'élément item peut avoir un contenu vide si on lui ajoute un attribut xsi:nil avec la valeur true.

<?xml version="1.0" encoding="iso-8859-1"?>
<list xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <!-- Contenu normal -->
  <item>123</item>
  <!-- Contenu vide non autorisé -->
  <item></item>
  <!-- Contenu annihilé -->
  <item xsi:nil="true"></item>
  <!-- Contenu nécessairement vide : aucun espace -->
  <item xsi:nil="true">   </item>
  <item>789</item>
</list>

Un type peut remplacer, dans une instance de document, un autre type dont il dérive directement ou non. Soit, par exemple, un élément elem déclaré d'un type BaseType. Si un type ExtentedType a été défini par extension ou restriction du type BaseType, il est possible, dans une instance de document, de mettre un élément elem avec un contenu de type ExtentedType. Pour que le document reste valide, l'élément elem doit avoir un attribut xsi:type qui précise le type de son contenu. Cet attribut est dans l'espace de noms des instances de schémas. La substitution de type est autorisée par défaut. Aucune déclaration n'est nécessaire dans le schéma pour qu'elle puisse avoir lieu dans les documents. La substitution de type peut, en revanche, être forcée ou bloquée par les attributs abstract et block. Dans l'exemple suivant, un type Name est d'abord déclaré puis un type Fullname étend ce type en ajoutant un élément title et un attribut id.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema targetNamespace="http://www.omega-one.org/~carton/"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns="http://www.omega-one.org/~carton/">
  <xsd:element name="name" type="Name"/>
  ...
  <xsd:complexType name="Name">
    <xsd:sequence>
      <xsd:element name="firstname" type="xsd:string"/>
      <xsd:element name="lastname"  type="xsd:string"/>
    </xsd:sequence>
  </xsd:complexType>
  <xsd:complexType name="Fullname">
    <xsd:complexContent>
      <xsd:extension base="Name">
        <xsd:sequence>
          <xsd:element name="title" type="xsd:string"/>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:ID"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
</xsd:schema>

Le document suivant est valide pour ce schéma.

<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
<tns:names xmlns:tns="http://www.omega-one.org/~carton/"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <!-- Élément name avec le type tns:Name -->
  <tns:name>
    <firstname>Bessiewallis</firstname>
    <lastname>Warfield</lastname>
  </tns:name>
  <!-- Élément name avec le type tns:Fullname -->
  <tns:name id="id52" xsi:type="tns:Fullname">
    <firstname>Elizabeth II Alexandra Mary</firstname>
    <lastname>Windsor</lastname>
    <title>Queen of England</title>
  </tns:name>
</tns:names>

L'attribut xsi:type peut aussi changer le type d'un élément en un autre type obtenu par restriction du type original. Dans l'exemple suivant, un type Byte est déclaré par restriction du type prédéfini xsd:nonNegativeInteger. Cet type est équivalent au type xsd:byte prédéfini dans les schémas.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema targetNamespace="http://www.omega-one.org/~carton/"
            xmlns="http://www.omega-one.org/~carton/"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="value" type="xsd:integer"/>
  ...
  <xsd:simpleType name="Byte">
    <xsd:restriction base="xsd:nonNegativeInteger">
       <xsd:maxInclusive value="255"/>
    </xsd:restriction>
  </xsd:simpleType>
</xsd:schema>

Le document suivant est valide pour ce schéma. Il est possible de changer le type de l'élément value en xsd:nonNegativeInteger car ce type prédéfini dérive du type prédéfini xsd:integer. Cet exemple illustre aussi l'utilisation indispensable des espaces de noms. Il est, en effet, nécessaire de déclarer trois espaces de noms : celui des éléments du document, celui des schémas pour le type xsd:nonNegativeInteger et celui des instances de schémas pour l'attribut xsi:type.

<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
<tns:values xmlns:tns="http://www.omega-one.org/~carton/"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <tns:value>-1</tns:value>
  <tns:value xsi:type="xsd:nonNegativeInteger">256</tns:value>
  <tns:value xsi:type="tns:Byte">255</tns:value>
</tns:values>

Il est possible de spécifier qu'un élément peut être remplacé par un autre élément dans les documents instance. Ce mécanisme est différent de l'utilisation de l'attribut xsi:type puisque c'est l'élément même qui est remplacé et pas seulement le type. Le type de l'élément substitué doit avoir un type dérivé du type de l'élément original.

La substitution d'élément se distingue en plusieurs points de la substitution de type. Elle est évidemment beaucoup plus forte car elle affecte les éléments qui peuvent apparaître dans les documents. Pour cette raison, elle doit explicitement être prévue par le schéma par l'intermédiaire de groupes de substitution qui décrivent quel élément peut être remplacé et par quels éléments. En revanche, le document ne signale pas la substitution comme il le fait pour une substitution de type avec l'attribut xsi:type.

Ce mécanisme est mis en œuvre en créant un groupe de substitution. Un groupe est formé d'un élément chef de groupe (group head en anglais) et d'autres éléments qui se rattachent au chef de groupe. Le chef de groupe peut être remplacé dans un document instance par n'importe quel autre élément du groupe. Le chef de groupe n'est pas identifié directement. En revanche, tous les autres éléments déclarent leur rattachement au groupe avec l'attribut substitutionGroup dont la valeur est le nom du chef de groupe. Les groupes de substitution peuvent être bloqués par l'attribut final. Dans l'exemple suivant, le chef de groupe est l'élément integer. Les éléments positive et negative peuvent être substitués à l'élément integer.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <!-- Chef de groupe -->
  <xsd:element name="integer"  type="xsd:integer"/>
  <!-- Autres éléments du groupe -->
  <xsd:element name="positive" type="xsd:positiveInteger"
                               substitutionGroup="integer"/>
  <xsd:element name="negative" type="xsd:negativeInteger"
                               substitutionGroup="integer"/>
  <xsd:element name="integers">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="integer" maxOccurs="unbounded"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>    
</xsd:schema>

Le document suivant est valide pour ce schéma. L'élément integers contient des éléments positive et negative remplacent des éléments integer.

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<integers>
  <integer>0</integer>
  <!-- Élément positive se substituant à un élément integer -->
  <positive>1</positive>
  <!-- Élément negative se substituant à un élément integer -->
  <negative>-1</negative>
  <integer>-42</integer>
</integers>

Depuis la version 1.1 des schémas, l'attribut substitutionGroup de xsd:element peut contenir plusieurs noms d'éléments. Un élément peut ainsi appartenir à plusieurs groupes de substitution alors que c'était impossible avec la version 1.0.

Les substitutions peuvent être utilisées en cascade. Un élément membre d'un groupe de substitution peut, lui-même, être chef d'un autre groupe de substitution. Les membres de ce dernier groupe peuvent bien sûr remplacer leur chef de groupe mais aussi son chef de groupe. Dans le schéma suivant, l'élément head est le chef d'un groupe comprenant l'élément subs. Cet élément subs est, à son tour, chef d'un groupe de substitution comprenant l'élément subsubs. Cet élément subsubs peut dont remplacer l'élément subs mais aussi l'élément head.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <!-- L'élément chef de groupe -->
  <xsd:element name="head" type="xsd:string"/>
  <!-- Un élément subs pouvant se substituer à head -->
  <xsd:element name="subs" type="xsd:string" substitutionGroup="head"/>
  <!-- Un élément subsubs pouvant se substituer à subs et à head -->
  <xsd:element name="subsubs" type="xsd:string" substitutionGroup="subs"/>
  <xsd:element name="heads">     
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="head" maxOccurs="unbounded"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>    
</xsd:schema>

Le document suivant est valide pour le schéma précédent.

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<heads>
  <head>Élément head original</head>
  <subs>Substitution de head par subs</subs>
  <subsubs>Substitution de head par subsubs</subsubs>
  <head>Autre élément head original</head>
</heads>

Les définitions circulaires de groupes de substitution sont interdites. Un chef de groupe ne peut pas être membre d'un groupe dont le chef serait lui même membre d'un de ses groupes. Les déclarations suivantes ne sont donc pas valides.

  <xsd:element name="head" type="xsd:string" substitutionGroup="subs"/>
  <xsd:element name="subs" type="xsd:string" substitutionGroup="head"/>

Les groupes de substitution permettent, quelquefois, de compenser les lacunes de l'opérateur xsd:all. Il est, en effet, possible de simuler un opérateur xsd:choice avec un élément abstrait et un groupe de substitution.

Dans le schéma suivant, l'élément number est abstrait. Il doit nécessairement être remplacé, dans un document, par un élément de son groupe de substitution, c'est-à-dire par un élément integer ou par un élément double. Il y a donc le choix entre un élément integer ou un élément double. Le type de l'élément number est xsd:anyType pour que les types xsd:integer et xsd:double des éléments integer et double puissent en dériver.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="properties">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="property" maxOccurs="unbounded"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="property">
    <xsd:complexType>
      <xsd:all>
        <xsd:element name="key" type="xsd:string"/>
        <xsd:element ref="number"/>
        <xsd:element name="condition" type="xsd:string" minOccurs="0"/>
      </xsd:all>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="number"  type="xsd:anyType" abstract="true"/>
  <xsd:element name="integer" type="xsd:integer" substitutionGroup="number"/>
  <xsd:element name="double"  type="xsd:double"  substitutionGroup="number"/>
</xsd:schema>

Il existe différents moyens de contrôler les substitutions de types et d'éléments. Les types et éléments abstraits introduits par l'attribut abstract permettent de forcer une substitution en empêchant un type ou un élément d'apparaître dans un document. Les attributs block et final permettent, au contraire, de limiter les substitutions et les définitions de types dérivés.

Les trois attributs abstract, block et final s'appliquent aussi bien aux declarations d'éléments qu'aux définitions de types. Il faut prendre garde au fait que leurs significations dans ces deux cas sont proches mais néanmoins différentes.

Le tableau suivant récapitule les utilisations des trois attributs abstract, block et final pour les types et les éléments.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <!-- Type de base : restriction du type xsd:string -->
  <xsd:simpleType name="ShortString">
    <xsd:restriction base="xsd:string">
      <!-- Facette fixée -->
      <xsd:maxLength value="32" fixed="true"/>
    </xsd:restriction>
  </xsd:simpleType>
  <!-- Restriction du type ShortString -->
  <xsd:simpleType name="VeryShortString">
    <xsd:restriction base="ShortString">
      <!-- Facette modifiée -->
      <xsd:minLength value="2"/>
      <!-- Facette impossible à modifier -->
      <xsd:maxLength value="16"/>
    </xsd:restriction>
  </xsd:simpleType>
</xsd:schema>
...

<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
<strings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <string>Une chaîne assez courte</string>
  <string xsi:type="VeryShortString">Très courte</string>
</strings>

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <!-- Type de base abstrait -->
  <xsd:complexType name="Price" abstract="true">
    <xsd:simpleContent>
      <xsd:extension base="xsd:decimal">
        <xsd:attribute name="currency" type="xsd:string"/>
      </xsd:extension>
    </xsd:simpleContent>
  </xsd:complexType>
  <!-- Type dérivé concret -->
  <xsd:complexType name="InternPrice">
    <xsd:simpleContent>
      <xsd:restriction base="Price">
        <xsd:attribute name="currency" type="xsd:string" use="required"/>
      </xsd:restriction>
    </xsd:simpleContent>
  </xsd:complexType>
  <!-- Élément price de type abstrait -->
  <xsd:element name="price" type="Price"/>
  <!-- Élément interprice de type concret substituable à price -->
  <xsd:element name="internprice" type="InternPrice" substitutionGroup="price"/>
  <xsd:element name="prices">     
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="price" maxOccurs="unbounded"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<prices xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <!-- Élément de type Price non autorisé -->
  <price>78.9</price>
  <!-- Substitution de type -->
  <price xsi:type="InternPrice" currency="euro">12.34</price>
  <!-- Substitution d'élément -->
  <internprice currency="dollar">45.56</internprice>
</prices>

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema targetNamespace="http://www.omega-one.org/~carton/"
            xmlns="http://www.omega-one.org/~carton/"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="value" type="Abstract"/>
  <xsd:element name="values">     
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="value" maxOccurs="unbounded"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>    
  <xsd:complexType name="Abstract" abstract="true"/>
  <xsd:complexType name="Derived1">
    <xsd:complexContent>
      <xsd:extension base="Abstract">
        <xsd:sequence>
          <xsd:element name="string" type="xsd:string"/> 
        </xsd:sequence>
        <xsd:attribute name="att" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:complexType name="Derived2">
    <xsd:complexContent>
      <xsd:extension base="Abstract">
        <xsd:sequence>
          <xsd:element name="string"  type="xsd:string"/> 
          <xsd:element name="integer" type="xsd:integer"/>
        </xsd:sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
</xsd:schema>

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<tns:values xmlns:tns="http://www.omega-one.org/~carton/"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <!-- Élément value de type Abstract impossible -->
  <tns:value xsi:type="tns:Derived1" att="avec un attribut">
    <string>Une chaîne</string>
  </tns:value>
  <tns:value xsi:type="tns:Derived2">
    <string>Un entier</string>
    <integer>-1</integer>
  </tns:value>
</tns:values>

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <!-- Un élément value abstrait -->
  <xsd:element name="value" type="xsd:string" abstract="true"/>
  <!-- Un élément other pouvant se substituer à value -->
  <xsd:element name="other" type="String27" substitutionGroup="value"/>
  <!-- Type obtenu par restriction de xsd:string -->
  <xsd:simpleType name="String27">
    <xsd:restriction base="xsd:string">
      <xsd:length value="27"/>
    </xsd:restriction>
  </xsd:simpleType>
  ...

<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
<values xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <!-- Élément value impossible -->
  <value>Une chaîne d'une autre longueur</value>
  <!-- Élément value impossible même avec une substitution de type -->
  <value xsi:type="String27">Une chaîne de 27 caractères</value>
  <!-- Substitution d'élément -->
  <other>Une chaîne de même longueur</other>
</values>

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="value" type="Base"/>
  <!-- Élément du même type dans le groupe de substitution -->
  <xsd:element name="sametype" type="Base"   substitutionGroup="value"/>
  <!-- Élément d'un type dérivé dans le groupe de substitution -->
  <xsd:element name="subst" type="Extension" substitutionGroup="value"/>
  ...
  <!-- Type de base ne pouvant pas être substitué dans les documents -->
  <xsd:complexType name="Base" block="#all">
    <xsd:sequence>
      <xsd:element name="integer" type="xsd:integer"/> 
    </xsd:sequence>
  </xsd:complexType>
  <!-- Type obtenu par extension du type de base -->
  <xsd:complexType name="Extension">
    <xsd:complexContent>
      <xsd:extension base="Base">
        <xsd:attribute name="att" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <!-- Type obtenu par restriction du type de base -->
  <xsd:complexType name="Restriction">
    <xsd:complexContent>
      <xsd:restriction base="Base">
        <xsd:sequence>
          <xsd:element name="integer" type="xsd:nonNegativeInteger"/>
        </xsd:sequence>
      </xsd:restriction>
    </xsd:complexContent>
  </xsd:complexType>
</xsd:schema>

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<values xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <value>
    <integer>-1</integer>
  </value>
  <!-- Substitution autorisée avec le même type --> 
  <sametype>
    <integer>-1</integer>
  </sametype>
  <!-- Élément substitué d'un type dérivé impossible -->
  <subst att="Un attribut">
    <integer>-1</integer>
  </subst>
  <!-- Élément value de type Extension impossible -->
  <value xsi:type="Extension" att="Un attribut">
    <integer>1</integer>
  </value>
  <!-- Élément value de type Restriction impossible -->
  <value xsi:type="Restriction">
    <integer>1</integer>
  </value>
</values>

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <!-- Type de base ne pouvant pas être substitué par une extension -->
  <xsd:complexType name="List" block="extension">
    <xsd:sequence>
      <xsd:element name="item" type="xsd:string" maxOccurs="unbounded"/>
    </xsd:sequence>
  </xsd:complexType>
  <!-- Restriction du type de base -->
  <xsd:complexType name="ShortList">
    <xsd:complexContent>
      <xsd:restriction base="List">
        <xsd:sequence>
          <!-- Nombre limité d'éléments item -->
          <xsd:element name="item" type="xsd:string" maxOccurs="8"/>
        </xsd:sequence>
      </xsd:restriction>
    </xsd:complexContent>
  </xsd:complexType>
  <!-- Extension de la restriction du type de base -->
  <xsd:complexType name="AttrShortList">
    <xsd:complexContent>
      <xsd:extension base="ShortList">
        <!-- Ajout d'un attribut -->
        <xsd:attribute name="length" type="xsd:integer"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="list" type="List"/>
</xsd:schema>

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<!-- Type ShortList possible mais type AttrShortList impossible -->
<list xsi:type="ShortList" 
      xsi:type="AttrShortList" length="3"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <item>Premier item</item>
  <item>Deuxième item</item>
  <item>Troisième item</item>
</list>

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="integer"  type="xsd:integer" 
                               block="restriction extension"/>
  <!-- Élément avec le même type -->
  <xsd:element name="sametype" type="xsd:integer" 
                               substitutionGroup="integer"/>
  <!-- Élément avec un type obtenu par restriction -->
  <xsd:element name="positive" type="xsd:positiveInteger" 
                               substitutionGroup="integer"/>
  ...
</xsd:schema>

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<integers xmlns:xsd="http://www.w3.org/2001/XMLSchema"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <integer>0</integer>
  <!-- Substitution par un élément de même type -->
  <sametype>1</sametype>
  <!-- Substitution de type impossible -->
  <integer xsi:type="xsd:positiveInteger">1</integer>
  <!-- Substitution d'élément avec un type dérivé impossible -->
  <positive>1</positive>
</integers>

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="integer"  type="xsd:integer" block="substitution"/>
  <!-- Élément avec le même type -->
  <xsd:element name="sametype" type="xsd:integer" 
                               substitutionGroup="integer"/>
  <!-- Élément avec un type obtenu par restriction -->
  <xsd:element name="positive" type="xsd:positiveInteger" 
                               substitutionGroup="integer"/>
  ...
</xsd:schema>

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<integers xmlns:xsd="http://www.w3.org/2001/XMLSchema"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <integer>0</integer>
  <!-- Substitution de type -->
  <integer xsi:type="xsd:positiveInteger">1</integer>
  <!-- Substitution d'élément avec le même type impossible -->
  <sametype>1</sametype>
  <!-- Substitution d'élément avec un type dérivé impossible -->
  <positive>1</positive>
</integers>

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  ...
  <!-- L'attribut final="#all" empêche les restrictions et extensions -->
  <xsd:complexType name="Base" final="#all">
    <xsd:sequence>
      <xsd:element name="integer" type="xsd:integer"/> 
    </xsd:sequence>
  </xsd:complexType>
  <!-- Extension du type Base impossible -->
  <xsd:complexType name="Extension">
    <xsd:complexContent>
      <xsd:extension base="Base">
        <xsd:attribute name="att" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <!-- Restriction du type Base impossible -->
  <xsd:complexType name="Restriction">
    <xsd:complexContent>
      <xsd:restriction base="Base">
        <xsd:sequence>
          <xsd:element name="integer" type="xsd:nonNegativeInteger"/>
        </xsd:sequence>
      </xsd:restriction>
    </xsd:complexContent>
  </xsd:complexType>
</xsd:schema>

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <!-- Type de base bloquant les extensions -->
  <xsd:complexType name="List" final="extension">
    <xsd:sequence>
      <xsd:element name="item" type="xsd:string" maxOccurs="unbounded"/>
    </xsd:sequence>
  </xsd:complexType>
  <!-- Restriction du type de base -->
  <xsd:complexType name="ShortList">
    <xsd:complexContent>
      <xsd:restriction base="List">
        <xsd:sequence>
          <!-- Nombre limité d'éléments item -->
          <xsd:element name="item" type="xsd:string" maxOccurs="8"/>
        </xsd:sequence>
      </xsd:restriction>
    </xsd:complexContent>
  </xsd:complexType>
  <!-- Extension de la restriction du type de base -->
  <xsd:complexType name="AttrShortList">
    <xsd:complexContent>
      <xsd:extension base="ShortList">
        <!-- Ajout d'un attribut -->
        <xsd:attribute name="length" type="xsd:integer"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="list" type="List"/>
</xsd:schema>

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<list length="3" xsi:type="AttrShortList"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <item>Premier item</item>
  <item>Deuxième item</item>
  <item>Troisième item</item>
</list>

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="integer"  type="xsd:integer" final="extension"/>
  <!-- Élément avec un type obtenu par restriction de xsd:integer -->
  <xsd:element name="positive" type="xsd:positiveInteger" 
                               substitutionGroup="integer"/>
  <!-- Élément avec un type obtenu par extension de xsd:integer -->
  <!-- Impossible dans le groupe de substitution de integer -->
  <xsd:element name="attributed" type="Attributed"
                                 substitutionGroup="integer"/>
  <!-- Type obtenu par extension de xsd:integer -->
  <xsd:complexType name="Attributed">
    <xsd:simpleContent>
      <xsd:extension base="xsd:integer">
        <xsd:attribute name="att" type="xsd:string"/>
      </xsd:extension>
    </xsd:simpleContent>
  </xsd:complexType>
  ...
</xsd:schema>

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<integers>
  <integer>0</integer>
  <!-- Substitution élément -->
  <positive>1</positive>
  <!-- Élément attributed impossible -->
  <attributed att="Un attribut">-1</attributed>
</integers>

L'élément xsd:group permet de définir un groupe d'éléments dont le nom est donné par l'attribut name. L'élément xsd:group doit être enfant de l'élément racine xsd:schema du schéma. Ceci signifie que la portée de la définition du groupe est le schéma tout entier. Le contenu de l'élément xsd:group est un fragment de type nécessairement inclus dans un élément xsd:sequence, xsd:choice ou xsd:all.

Un groupe peut être employé dans la définition d'un type ou la définition d'un autre groupe. L'utilisation d'un groupe est équivalente à l'insertion de son contenu. L'intérêt d'un groupe est de pouvoir l'utiliser à plusieurs reprises et de factoriser ainsi les parties communes à plusieurs types. L'utilisation d'un groupe est introduite par un élément xsd:group avec un attribut ref qui donne le nom du groupe à insérer.

Dans le schéma suivant, le groupe FirstLast est défini puis utilisé dans la définition du groupe Name et du type Person ainsi que dans la définition du type anonyme de l'élément character.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:group name="FirstLast">
    <xsd:sequence>
      <xsd:element name="firstname" type="xsd:string"/>
      <xsd:element name="lastname"  type="xsd:string"/>
    </xsd:sequence>
  </xsd:group>
  <xsd:group name="Name">
    <xsd:choice>
      <xsd:element name="name" type="xsd:string"/>
      <!-- Insertion du contenu du groupe FirstLast -->
      <xsd:group   ref="FirstLast"/>
    </xsd:choice>
  </xsd:group>
  <xsd:complexType name="Person">
    <xsd:sequence>
      <xsd:element name="surname" type="xsd:string"  minOccurs="0"/>
      <!-- Insertion du contenu du groupe Name -->
      <xsd:group   ref="Name"/>
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="characters">
    <xsd:complexType>
       <xsd:sequence>
	 <xsd:element name="character" maxOccurs="unbounded">
	   <xsd:complexType>
	     <xsd:sequence>
               <!-- Insertion du contenu du groupe Name -->
	       <xsd:group   ref="Name"/>
	       <xsd:element name="creator" type="Person" 
			    minOccurs="0" maxOccurs="unbounded"/>
	     </xsd:sequence>
	   </xsd:complexType>
	 </xsd:element>
       </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

Le document suivant est valide pour le schéma précédent.

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<characters>
  <character>
    <firstname>Gaston</firstname>
    <lastname>Lagaffe</lastname>
    <creator>
      <firstname>André</firstname>
      <lastname>Franquin</lastname>
    </creator>
  </character>
  <character>
    <name>Astérix</name>
    <creator>
      <surname>Al Uderzo</surname>
      <firstname>Albert</firstname>
      <lastname>Uderzo</lastname>
    </creator>
    <creator>
      <firstname>René</firstname>
      <lastname>Goscinny</lastname>
    </creator>
  </character>

Un groupe est en fait un fragment de type qui peut être utilisé à l'intérieur de la définition de n'importe quel type. En revanche, il ne peut pas servir comme type dans la déclaration d'un l'élément. À l'inverse, un type peut servir dans la déclaration d'éléments mais il ne peut pas être directement inclus par un autre type.

Les groupes sont en fait un mécanisme d'abréviation. Ils permettent d'accroître la modularité des schémas en évitant de recopier plusieurs fois le même fragment dans les définitions de différents types.

Les groupes d'attributs jouent, pour les attributs, un rôle similaire aux groupes d'éléments. Ils permettent de regrouper plusieurs déclarations d'attributs dans le but d'une réutilisation. L'élément xsd:attributeGroup permet de définir un groupe d'attributs dont le nom est donné par l'attribut name. L'élément xsd:attributeGroup doit être enfant de l'élément racine xsd:schema du schéma. Ceci signifie que la portée de la définition du groupe est le schéma tout entier. Le contenu de l'élément xsd:attributeGroup est constitué de déclarations d'attributs introduites par l'élément xsd:attribute.

Dans l'exemple suivant, le groupe d'attributs LangType regroupe les déclaration des deux attributs lang et type.

<xsd:attributeGroup name="LangType">
  <xsd:attribute name="lang" type="xsd:language"/>
  <xsd:attribute name="type" type="xsd:string"/>
</xsd:attributeGroup>

Un groupe d'attributs peut être employé dans la définition d'un type ou la définition d'un autre groupe d'attributs. L'utilisation d'un groupe est équivalente à l'insertion de son contenu. L'utilisation d'un groupe est introduite par un élément xsd:attributeGroup avec un attribut ref qui donne le nom du groupe à insérer.

Le groupe d'attributs LangType peut être employé de la façon suivante dans la définition d'un type complexe nommé ou anonyme. Tout élément du type SomeType défini ci-dessous pourra avoir les attributs lang et type déclarés dans le groupe LangType.

<xsd:complexType name="SomeType">
  <!-- Contenu -->
  ...
  <xsd:attributeGroup ref="LangType"/>
</xsd:complexType>

Il est possible d'utiliser successivement plusieurs groupes d'attributs pour déclarer les attributs d'un type mais il faut une occurrence de xsd:attributeGroup pour chaque groupe utilisé.

<xsd:attributeGroup ref="AttrGroup1"/>
<xsd:attributeGroup ref="AttrGroup2"/>

Un groupe d'attributs peut aussi être utilisé dans la définition d'un autre groupe d'attributs. Le nouveau groupe défini contient tous les attributs du ou des groupes référencés en plus des attributs qu'il déclare explicitement. Ce mécanisme est semblable à l'héritage des classes dans les langages de programmation orientés objet.

<xsd:attributeGroup name="LangTypeClass">
  <xsd:attributeGroup ref="LangType"/>
  <xsd:attribute name="class" type="xsd:string"/>
</xsd:attributeGroup>

Le schéma à l'adresse http://www.w3.org/2001/xml.xsd déclare les quatre attributs particuliers xml:lang, xml:space, xml:base et xml:id. Il définit également un groupe d'attributs xml:specialAttrs permettant de déclarer simultanément ces quatre attributs. Un exemple d'utilisation de celui-ci est donné dans la partie sur l'import de schémas. Cet exemple montre que les noms des groupes d'éléments et des groupes d'attributs sont des noms qualifiés dans l'espace de noms cible du schéma.

Une contrainte d'unicité spécifie que dans le contenu d'un élément donné, il ne peut exister qu'un seul élément ayant une propriété fixée. Cette propriété est très souvent la valeur d'un attribut mais elle peut aussi être formée des valeurs de plusieurs enfants ou attributs. Cette notion est similaire à la notion de clé des bases de données. Elle généralise les attributs de types ID dont la valeur est unique dans tout le document.

Une contrainte d'unicité est donnée par un élément xsd:key ou xsd:unique. Les contraintes introduites par ces deux éléments se présentent de la même façon et ont des sémantiques très proches. L'élément xsd:key ou xsd:unique doit être enfant d'un élément xsd:element qui déclare un élément. Cet élément qui contient la contrainte définit la portée de celle-ci. Les contraintes d'unicité ainsi que les contraintes d'existence doivent être placées après le type de la déclaration.

Chaque élément xsd:key ou xsd:unique possède un attribut name uniquement utilisé par les contraintes d'existence introduites par xsd:keyref et qui peut donc être ignoré pour l'instant. Il contient un élément xsd:selector et des éléments xsd:field possédant chacun un attribut xpath. L'élément xsd:selector détermine sur quels éléments porte la contrainte. La valeur de son attribut xpath est une expression XPath qui sélectionne des éléments concernés. Les éléments xsd:field déterminent quelle est la valeur qui doit être unique. Cette valeur est constituée de plusieurs champs à la manière d'un objet dans les langages de programmation. La valeur de l'attribut xpath de chacun des éléments xsd:field spécifie un champ de la valeur de la clé d'unicité. La contrainte donnée par un élément xsd:key impose que chacun des champs déterminé par les éléments xsd:field soit présent et que la valeur ainsi constituée soit unique pour les éléments sélectionnés par xsd:selector dans le contenu de l'élément définissant la portée. Au contraire, la contrainte donnée par un élément xsd:key n'impose pas que chacun des champs déterminé par les éléments xsd:field soit présent. Elle impose seulement que les éléments ayant tous les champs aient une valeur unique.

Dans l'exemple, la contrainte est décrite au niveau de l'élément bibliography pour exprimer que l'attribut key de book doit être unique dans le contenu de l'élément bibliography.

<!-- Déclaration de l'élément bibliography de type Bibliography -->
<xsd:element name="bibliography" type="Bibliography">
  <!-- Unicité des attributs key des éléments book dans bibliography -->  
  <xsd:key name="dummy">
    <xsd:selector xpath="book"/>
    <xsd:field    xpath="@key"/>
  </xsd:key>
</xsd:element>

Une contrainte décrite avec xsd:key implique que les champs impliqués soient nécessairement présents et non annulables. Une contrainte décrite avec xsd:unique est au contraire seulement vérifiée pour les éléments dont tous les champs spécifiés dans la contrainte sont présents.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="groups">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="group" maxOccurs="unbounded"/>
      </xsd:sequence>
    </xsd:complexType>
    <!-- Unicité des attributs num des éléments group -->
    <xsd:unique name="group.num">
      <xsd:selector xpath="group"/>
      <xsd:field    xpath="@num"/>
    </xsd:unique>
  </xsd:element>
  <xsd:element name="group">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="person" maxOccurs="unbounded">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="firstname" type="xsd:string"/>
              <xsd:element name="lastname"  type="xsd:string"/>
            </xsd:sequence>
            <xsd:attribute name="id" type="xsd:string"/>
          </xsd:complexType>
        </xsd:element>
      </xsd:sequence>
      <xsd:attribute name="num" type="xsd:integer"/>
    </xsd:complexType>
    <!-- Unicité des attributs id des éléments person -->
    <xsd:key name="person.id">
      <xsd:selector xpath="person"/>
      <xsd:field    xpath="@id"/>
    </xsd:key>
  </xsd:element>
</xsd:schema>

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<groups>
  <group num="1">
    <person id="AC">
      <firstname>Albert</firstname>
      <lastname>Cohen</lastname>
    </person>
    <person id="VH">
      <firstname>Victor</firstname>
      <lastname>Hugo</lastname>
    </person>
  </group>
  <group num="2">
    <person id="AC">
      <firstname>Anders</firstname>
      <lastname>Celsius</lastname>
    </person>
    <person id="SH">
      <firstname>Stephen</firstname>
      <lastname>Hawking</lastname>
    </person>
  </group>
</groups>

    <xsd:key name="person.names">
      <xsd:selector xpath="person"/>
      <xsd:field    xpath="firstname"/>
      <xsd:field    xpath="lastname"/>
    </xsd:key>

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<groups>
  <group num="1">
    <person id="AC">
      <firstname>Albert</firstname>
      <lastname>Cohen</lastname>
    </person>
    <person id="VH">
      <firstname>Victor</firstname>
      <lastname>Hugo</lastname>
    </person>
    <person id="AC">
      <firstname>Anders</firstname>
      <lastname>Celsius</lastname>
    </person>
    <person id="AE">
      <firstname>Albert</firstname>
      <lastname>Einstein</lastname>
    </person>
  </group>
</groups>

    <xsd:key name="person.id">
      <xsd:selector xpath="person"/>
      <xsd:field    xpath="@id"/>
    </xsd:key>
    <xsd:key name="person.names">
      <xsd:selector xpath="person"/>
      <xsd:field    xpath="firstname"/>
      <xsd:field    xpath="lastname"/>
    </xsd:key>

    <xsd:unique name="all.id">
      <xsd:selector xpath="* | group/*"/>
      <xsd:field    xpath="id"/>
    </xsd:unique>

Une contrainte d'existence spécifie que dans le contenu d'un élément donné, il doit exister un élément ayant une propriété fixée. Comme pour les contraintes d'unicité, cette propriété est très souvent la valeur d'un attribut mais elle peut aussi être formée des valeurs de plusieurs enfants ou attributs. L'idée générale est de référencer un élément par une valeur appelée clé et que cet élément doit exister. Cette idée généralise les attributs de types IDREF et IDREFS des DTD.

Ces contraintes sont introduites par un élément xsd:keyref qui doit être enfant d'un élément xsd:element. Comme pour les contraintes d'unicité, cet élément dans lequel se trouve la contrainte définit la portée de celle-ci.

Chaque élément xsd:keyref possède des attributs name et refer. L'attribut name donne le nom de la contrainte. La valeur de l'attribut refer doit être le nom, c'est-à-dire la valeur de l'attribut name, d'une contrainte d'unicité qui est associée à cette contrainte d'existence. L'élément xsd:keyref contient un élément xsd:selector et des éléments xsd:field possédant chacun un attribut xpath. L'élément xsd:selector sélectionne sur quels éléments porte la contrainte. La valeur de son attribut xpath est une expression XPath qui sélectionne des éléments concernés. Les éléments xsd:field déterminent les différents champs de la valeur servant de clé. La contrainte donnée par un élément xsd:keyref impose que pour chaque élément sélectionné, il existe un élément sélectionné par la contrainte d'unicité associée qui a la même valeur. La contrainte d'unicité reférencée par l'attribut refer doit se trouver dans le même élément que xsd:keyref ou dans un de ses descendants.

Dans l'exemple suivant, la contrainte d'unicité idchapter impose que la valeur d'un attribut id d'un élément chapter soit unique. La contrainte d'existence idref utilise cette contrainte idchapter pour imposer que la valeur d'un attribut idref de tout élément ref soit aussi la valeur d'un attribut id d'un élément chapter. Ceci signifie que tout élément ref référence, par son attribut idref, un chapitre qui existe bien dans le document.

    <!-- Unicité des attributs id des éléments chapter -->
    <xsd:key name="idchapter">
      <xsd:selector xpath="chapter"/>
      <xsd:field    xpath="@id"/>
    </xsd:key>
    <!-- Existence des références idref des éléments ref -->
    <xsd:keyref name="idref" refer="idchapter">
      <xsd:selector xpath=".//ref"/>
      <xsd:field    xpath="@idref"/>
    </xsd:keyref>

Dans l'exemple précédent, la valeur d'un des attributs xpath est l'expression .//ref qui sélectionne tous les descendants de nom ref de l'élément courant. Cette expression est en fait une abréviation de l'expression ./descendant-or-self::node()/ref.

Voici un exemple de document XML représentant une liste de commandes. Chaque commande concerne un certain nombre d'articles qui sont référencés dans le catalogue donné à la fin.

<?xml version="1.0" encoding="iso-8859-1"?>
<list period="P2D">
  <orders>
    <order date="2008-01-08" time="17:32:28">
      <product serial="101-XX" number="12"/>
      <product serial="102-XY" number="23"/>
      <product serial="101-ZA" number="10"/>
    </order>
    <order date="2008-01-09" time="17:32:28">
      <product serial="101-XX" number="32"/>
    </order>
    <order date="2008-01-09" time="17:32:29">
      <product serial="101-XX" number="32"/>
    </order>
  </orders>
  <catalog>
    <product serial="101-XX">Product n° 1</product>
    <product serial="101-ZA">Product n° 2</product>
    <product serial="102-XY">Product n° 3</product>
    <product serial="102-XA">Product n° 4</product>
  </catalog>
</list>

Le schéma correspondant impose trois contraintes suivantes sur le fichier XML.

Le début de ce schéma XML est le suivant.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="list">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="orders"  type="Orders"/>
        <xsd:element name="catalog" type="Catalog"/>
      </xsd:sequence>
      <xsd:attribute name="period" type="xsd:duration"/>
    </xsd:complexType>
    <!-- Unicité du couple (date,heure) -->
    <xsd:unique name="dummy">
      <xsd:selector xpath="orders/order"/>
      <xsd:field    xpath="@date"/>
      <xsd:field    xpath="@time"/>
    </xsd:unique>
    <!-- Unicité du numéro de série -->
    <xsd:key name="serial">
      <xsd:selector xpath="catalog/product"/>
      <xsd:field    xpath="@serial"/>
    </xsd:key>
    <!-- Existence dans le catalogue de tout produit commandé -->
    <xsd:keyref name="unused" refer="serial">
      <xsd:selector xpath="orders/order/product"/>
      <xsd:field    xpath="@serial"/>
    </xsd:keyref>
  </xsd:element>

  <!-- Suite du schéma -->
  ...

Pour une utilisation plus simple, il est possible d'ignorer les espaces de noms. Il est alors possible de valider des documents dont tous les éléments n'ont pas d'espace de noms. Il suffit, pour cela, que les noms des éléments du document ne soient pas qualifiés (sans le caractère ':') et que l'espace de noms par défaut ne soit pas spécifié.

Si l'attribut targetNamespace de l'élément xsd:schema est absent, tous les éléments et types définis dans le schéma sont sans espace de noms. Il faut cependant déclarer l'espace de noms des schémas pour qualifier les éléments des schémas (xsd:element, xsd:complexType, …).

Pour spécifier un espace de noms cible dans lequel sont définis les éléments, l'attribut targetNamespace de l'élément xsd:schema doit contenir l'URI associé à cet espace de noms. La valeur de l'attribut elementFormDefault de l'élément xsd:schema détermine quels éléments sont effectivement définis dans l'espace de noms.

La valeur par défaut de l'attribut elementFormDefault est unqualified. Quand la valeur de elementFormDefault est unqualified, seuls les éléments définis globalement, c'est-à-dire quand l'élément xsd:element est directement enfant de l'élément xsd:schema sont dans l'espace de noms cible. Les autres éléments sont sans espace de noms. Dans le schéma suivant, l'élément global name est dans l'espace de noms identifié par l'URI http://www.omega-one.org/~carton/ alors que les deux éléments locaux firstname et lastname sont sans espace de noms.

<?xml version="1.0" encoding="iso-8859-1"?>
<!-- unqualified est la valeur par défaut de elementFormDefault -->
<xsd:schema targetNamespace="http://www.omega-one.org/~carton/"
            elementFormDefault="unqualified"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="name">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="firstname" type="xsd:string"/>
        <xsd:element name="lastname"  type="xsd:string"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

Le document suivant est valide pour le schéma précédent.

<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
<tns:name xmlns:tns="http://www.omega-one.org/~carton/">
  <firstname>Gaston</firstname>
  <lastname>Lagaffe</lastname>
</tns:name>

Si la valeur de l'attribut elementFormDefault est qualified, tous les éléments sont dans l'espace de noms cible. Dans le schéma suivant, les trois éléments name, firstname et lastname sont dans l'espace de noms http://www.omega-one.org/~carton/.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsd:schema targetNamespace="http://www.omega-one.org/~carton/"
            elementFormDefault="qualified"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="name">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="firstname" type="xsd:string"/>
        <xsd:element name="lastname"  type="xsd:string"/>
      </xsd:sequence>
    </xsd:complexType>
 </xsd:element>
</xsd:schema>

Le document suivant est valide pour le schéma précédent.

<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
<tns:name xmlns:tns="http://www.omega-one.org/~carton/">
  <tns:firstname>Gaston</tns:firstname>
  <tns:lastname>Lagaffe</tns:lastname>
</tns:name>