Schéma XML - les types simples

Dans le chapitre précédent, nous avons vu comment décrire les éléments simples et les attributs. Nous avons également appris que les valeurs possibles sont des valeurs dites de types simples comme par exemple un nombre entier ou une chaîne de caractères.

Dans ce chapitre, nous allons voir en détails les 4 grandes catégories des types simples, à savoir les chaînes de caractères, les dates et les nombres. Il manque une catégorie, me direz-vous. Vous avez raison ! Une quatrième catégorie intitulée “divers”, regroupe les autres types simples qu’il est possible d’utiliser.

Les types chaînes de caractères

Le tableau récapitulatif

Plus en détails

Le type string

Le type string est l’un des premiers types que nous ayons vu ensemble. Il représente une chaîne de caractères et peut donc contenir un peu tout et n’importe quoi. Il est cependant important de noter que certains caractères spéciaux comme le & doivent être écrits avec leur notation HTML.

Une liste des caractères spéciaux et de leur notation HTML est disponible ici.

Bien que nous ayons déjà vu plusieurs exemples ensemble, je vous en propose un nouveau afin que ce type n’ait plus aucun secret pour vous. Soit la règle de Schéma XML suivante :

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

Les différentes lignes XML ci-dessous sont alors valides :

<string>France</string>

<string>Site du zéro !</string>

<string>&amp;</string>

Le type normalizedString

Le type normalizedString est basé sur le type string et représente une chaîne de caractères normalisée, c’est-à-dire, une chaîne de caractères qui peut contenir tout et n’importe quoi à l’exception de tabulations, de sauts de ligne et de retours chariot. Dans la pratique, il n’est pas interdit de les écrire, mais ils seront automatiquement remplacés par des espaces.

Puisque le type normalizedString est basé sur le type string, toutes les règles du type string s’appliquent également au type normalizedString. Ainsi, les caractères spéciaux comme le & doivent être écrits avec leur notation HTML.

Je ne le préciserai pas à chaque fois, mais cette règle est toujours vraie. Un type hérite toujours de toutes les règles du type sur lequel il se base.

Le type token

Le type token est basé sur le type normalizedString et représente une chaîne de caractères normalisée sans espace au début ni à la fin. Une nouvelle fois, dans la pratique, il n’est pas interdit de les écrire. Les espaces présents au début et à la fin seront automatiquement supprimés.

Le type language

Le type language est basé sur le type token et représente, comme son nom le laisse deviner, une langue. Cette langue doit être identifiée par 2 lettres (selon la norme ISO 639 dont la liste est disponible par sur wikipedia). Ces 2 caractères peuvent éventuellement être suivi d’un code pays (selon la norme ISO 3166 dont la liste est une nouvelle fois disponible sur wikipedia).

Considérons la règle suivante :

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

Les différentes lignes XML ci-dessous sont alors valides :

<langue>fr</langue>

<langue>en</langue>

<langue>en-GB</langue>

<langue>en-US</langue>

Le type NMTOKEN

Le type NMTOKEN est basé sur le type token et représente une chaîne de caractères “simple”, c’est-à-dire une chaîne de caractères sans espace qui ne contient que les symboles suivants :

• Des lettres.
• Des chiffres.
• Les caractères spéciaux .-_ et :

Si la chaîne de caractères contient des espaces au début ou à la fin, ils seront automatiquement supprimés.

Afin d’assurer une compatibilité entre les Schémas XML et les DTD, il convient de n’utiliser le type NMTOKEN que pour un attribut.

Le type NMTOKENS

Le type NMTOKENS représente une liste de NMTOKEN séparés par un espace. Une nouvelle fois, afin d’assurer une compatibilité entre les Schémas XML et les DTD, il convient de n’utiliser le type NMTOKENS seulement pour un attribut.

Soit la règle suivante issue d’un Schéma XML :

<xsd:attribute name="list" type="xsd:NMTOKENS" />

Les différentes lignes XML ci-dessous sont alors valides :

<balise list="A:1_B C-2.">contenu de la balise</balise>

<balise list="AZERTY 123456 QSDFGH">contenu de la balise</balise>

Le type Name

Le type Name est basé sur le type token et représente un nom XML, c’est-à-dire une chaîne de caractères sans espace qui ne contient que les symboles suivants :

• Des lettres.
• Des chiffres.
• Les caractères spéciaux .-_ et :

La différence avec le type NMTOKEN est qu’une chaîne de caractères de type Name doit obligatoirement commencer par une lettre, ou l’un des 2 caractères spéciaux suivants : _ et :

Le type NCName

Le type NCName est basé sur le type Name. Il hérite donc de toutes les règles du type Name auxquelles une nouvelle règle doit être ajoutée : le type NCName ne peut pas contenir le caractère spécial :

Le type ID

Le type ID est basé sur le type NCName, il hérite donc de toutes les règles de ce type. Comme son nom le laisse deviner, un ID représente un identifiant. Il doit donc contenir des valeurs uniques. A ce titre, il est impossible de lui définir une valeur fixe ou par défaut.

Comme pour d’autres types vu précédemment, un ID ne doit être utilisé qu’avec les attributs afin d’assurer une compatibilité entre les Schémas XML et les DTD.

Le type IDREF

Le type IDREF fait référence à un ID existant dans le document XML. Tout comme le type ID, il est basé sur le type NCName et hérite donc de toutes les règles de ce type. Puisque le type ID n’est utilisable qu’avec des attributs, il en est naturellement de même pour le type IDREF.

Le type IDREFS

Si le type NMTOKENS représente une liste de NMTOKEN séparés par un espace, le type IDREFS représente lui une liste de IDREF séparés par un espace.

Afin d’assurer une compatibilité entre les Schémas XML et les DTD, il convient de n’utiliser le type IDREFS que pour un attribut.

Illustrons son utilisation avec un exemple :

<xsd:attribute name="enfants" type="xsd:IDREFS" />

<personne num="P1">Paul</personne>
<personne num="P2">Marie</personne>

<personne enfants="P1 P2">Jeanne</personne>

Le type ENTITY

Le type ENTITY permet de faire référence à une entité le plus souvent non XML et déclaré dans des fichiers DTD. Ce type est basé sur le type NCName, il hérite donc de toutes ses règles.

Une nouvelle fois, afin d’assurer une compatibilité entre les Schémas XML et les DTD, il convient de n’utiliser le type ENTITY que pour un attribut.

Une nouvelle fois, je vous propose d’illustrer son utilisation par un exemple :

<xsd:attribute name="marque" type="xsd:ENTITY" />

<!ENTITY samsung "Samsung">
<!ENTITY apple "Apple">

<telephone marque="apple">iPhone</telephone>
<telephone marque="samsung">Galaxy SII</telephone>

Le type ENTITIES

Finalement, le dernier type que nous verrons dans cette catégorie est le type ENTITIES. Il permet de faire référence à une liste d’ENTITY séparés par un espace.

Puisque c’était déjà le cas pour le type ENTITY, le type ENTITIES n’échappe pas à la règle et ne doit être utilisé qu’avec un attribut.

Les types dates

Le tableau récapitulatif

Plus en détails

Le type duration

Le type duration, comme son nom le laisse deviner, représente une durée. Cette durée s’exprime en nombre d’années, de mois, de jours, d’heures, de minutes et de secondes selon une expression qui n’est pas des plus simples à savoir PnYnMnDTnHnMnS.

Je vous propose de la décortiquer :

• P marque le début de l’expression.
• nY représente le nombre d’années (year) où n est un nombre entier.
• nM représente le nombre de mois (month) où n est un nombre entier.
• nD représente le nombre de jours (day) où n est un nombre entier.
• T permet de séparer la partie date de l’expression de sa partie heure.
• nH représente le nombre d’heures (hour) où n est un nombre entier.
• nM représente le nombre de minutes (minute) où n est un nombre entier.
• nS représente le nombre de secondes (second) où n est un nombre entier ou décimal.

L’expression peut être précédée du signe - dans le cas où l’on souhaite exprimer une durée négative. Bien évidemment, tous les champs ne doivent pas forcément être renseignés. Ainsi, il est possible de ne renseigner que les heures, les minutes, etc. Dans le cas où l’expression n’exprime qu’une date, le symbole T ne doit plus figurer.

Je vous accorde que toutes ces règles ne sont pas faciles à assimiler, c’est pourquoi je vous propose de voir quelques exemples :

<xsd:element name="duree" type="xsd:duration" />
<!-- 42 ans et 6 minutes -->
<duree>P42YT6M</duree>

<!-- -2 heures -->
<duree>-PT2H</duree>

<!-- 2 jours -->
<duree>P2D</duree>

<!-- 10.5 secondes -->
<duree>PT10.5S</duree>

Le type date

Le type date permet d’exprimer une date. A l’image du type duration, une date s’exprime selon une expression bien spécifique à savoir YYYY-MM-DD.

Une nouvelle fois, je vous propose de décortiquer tout ça :

• YYYY représente l’année (year) sur 4 chiffres ou plus.
• MM représente le mois (month) sur 2 chiffres.
• DD représente le jour (day) également sur 2 chiffres.

Dans le cas où l’on souhaite exprimer une date avant Jésus-Christ, un signe - peut-être placé devant l’expression.

Voyons ensemble quelques exemples :

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

<!-- 13 janvier 1924 -->
<madate>1924-01-13</madate>

<!-- 12 décembre 34 avant JC -->
<madate>-0034-12-12</madate>

<!-- 4 novembre 12405 -->
<madate>12405-11-04</madate>

Le type time

Le type time permet d’exprimer une heure. Encore une fois, une expression bien spécifique doit être respectée : hh:mm:ss.

Pour continuer avec nos bonnes habitudes, décortiquons ensemble cette expression :

• hh représente les heures (hour) sur 2 chiffres.
• mm représente les minutes (minute) sur 2 chiffres.
• ss représente les secondes (second) sur 2 chiffres entiers ou à virgule.

Voici quelques exemples :

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

<!-- 10 heures et 24 minutes -->
<monheure>10:24:00</monheure>

<!-- 2,5 secondes -->
<monheure>00:00:02.5</monheure>

Le type dateTime

Le type dateTime peut être considéré comme un mélange entre le type date et le type time. Ce nouveau type permet donc de représenter une date ET une heure. Une nouvelle fois, une expression particulière doit être respectée : YYYY-MM-DDThh:mm:ss.

Je ne vais pas spécifiquement revenir sur cette expression. En effet, comme vous pouvez le constater, il s’agit des expressions du type date et du type time séparées par la lettre T. Je vous laisse vous référer aux types date et time pour les règles à appliquer. 😉

Le type gYear

Le type gYear représente une année sur 4 chiffres ou plus. Dans le cas où l’on souhaite exprimer une année avant Jésus-Christ, un signe - peut-être placé devant l’expression.

Le type gYearMonth

Le type gYearMonth représente une année et un mois. Comme pour tous les types que nous venons de voir dans ce chapitre, le type gYearMonth doit respecter une expression particulière : YYYY-MM.

Vous l’aurez compris, les règles sont toujours les mêmes. Je vous laisse donc vous reporter au paragraphe traitant du type date pour plus d’informations. 😉

Le type gMonth

Le type gMonth représente un mois sur 2 chiffres précédés du symbole –.

Non, ce n’est pas une erreur de frappe, le symbole est bien –. Voyons un exemple :

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

<!-- mars -->
<mois>--03</mois>

<!-- décembre -->
<mois>--12</mois>

Le type gMonthDay

Le type gMonthDay représente un mois et un jour. Une nouvelle fois, une expression particulière doit être utilisée afin d’exprimer ce nouveau type : –MM-DD.

Une nouvelle fois, les règles sont les mêmes que celles que nous avons déjà utilisé précédemment notamment pour le type date et le type gYearMonth.

Le type gDay

Finalement, nous allons terminer ce chapitre avec le type gDay qui représente un jour sur 2 chiffres précédés du symbole —.

Afin de terminer ce chapitre en beauté, voici quelques exemples :

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

<!-- le troisième jour du mois -->
<journee>---03</journee>

<!-- le douzième jour du mois -->
<journee>---12</journee>

Les types numériques

Le tableau récapitulatif

Plus en détails

Le type float

Comme vous avez déjà pu le lire dans le tableau récapitulatif, le type float représente un nombre flottant sur 32 bits et conforme à la norme IEEE 754. Je suis parfaitement conscient que cette définition est incompréhensible pour la plupart des gens, c’est pourquoi nous allons grandement la simplifier.

Le type float a été emprunté aux langages de programmation comme le langage C et est encore aujourd’hui utilisé dans des langages plus récents comme Java ou C#. Il représente un nombre flottant, c’est-à-dire un nombre entier ou décimal, se trouvant entre les valeurs 3.4x10^-38 et 3.4x10^38.

A cette plage de valeurs, 3 autres peuvent être ajoutées :

• -INF pour moins l’infini.
• +INF pour plus l’infini.
• NaN pour Not a Number, c’est-à-dire pour désigner une valeur non numérique.

Il est tout à fait possible d’écrire un nombre de type float avec des exposants. Il convient alors d’utiliser la notation E ou e.

Pour mieux comprendre toutes ces règles, je vous propose de regarder ensemble quelques exemples :

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

<nombre>42</nombre>

<nombre>-42.25</nombre>

<nombre>3E4</nombre>

<nombre>10e-5</nombre>

Le type double

Le type double est très proche du type float, si ce n’est qu’il représente un nombre flottant sur 64 bits et conforme à la norme IEEE 754 au lieu des 32 bits du type float. Concrètement, cette différence se traduit par le fait qu’un nombre de type double se trouve entre les valeurs 1.7x10^-308 et 1.7x10^308.

Comme pour le type float, les 3 valeurs suivantes peuvent être ajoutées à la liste :

• -INF pour moins l’infini.
• +INF pour plus l’infini.
• NaN pour Not a Number, c’est-à-dire pour désigner une valeur non numérique.

On retrouve également la règle de l’exposant. Je vous laisse vous référer à la définition du type float pour plus de détails.

Le type decimal

Comme son nom le laisse deviner, le type decimal représente un nombre décimal, c’est-à-dire un nombre qui peut-être entier ou à virgule. Ce nombre peut-être positif ou négatif et donc être précédé du symbole + ou -. Dans le cas d’un nombre où la partie entière est égale à zéro, il n’est pas obligatoire de l’écrire.

Voyons tout de suite quelques exemples afin d’illustrer cette définition :

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

<nombre>42</nombre>

<nombre>-42.25</nombre>

<nombre>+.42</nombre>

<nombre>00042.420000</nombre>

Le type integer

Le type integer est basé sur le type decimal et représente un nombre entier, c’est-à-dire un nombre sans virgule. Comme pour le type décimal, un nombre de type integer peut être précédé par le symbole + ou -.

Le type long

Le type long est basé sur le type integer si ce n’est qu’un nombre de type long doit forcément être compris entre les valeurs -9 223 372 036 854 775 808 et 9 223 372 036 854 775 807.

Le type int

Le type int est basé sur le type long si ce n’est qu’un nombre de type int doit forcément être compris entre les valeurs -2 147 483 648 et 2 147 483 647.

Le type short

Le type short est basé sur le type int si ce n’est qu’un nombre de type short doit forcément être compris entre les valeurs -32 768 et 32 767.

Le type byte

Le type byte est basé sur le type short si ce n’est qu’un nombre de type byte doit forcément être compris entre les valeurs -128 et 127.

Le type nonPositiveInteger

Basé sur le type integer, le type nonPositiveInteger représente un nombre entier qui n’est pas positif. Concrètement, cela correspond à un nombre négatif ou au nombre zéro.

Voyons ensemble un exemple :

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

<nombre>-42</nombre>

<nombre>0</nombre>

<nombre>-00042</nombre>

Le type negativeInteger

Basé sur le type nonPositiveInteger, le type negativeInteger représente un nombre entier strictement négatif, c’est-à-dire strictement inférieur à zéro.

Le type nonNegativeInteger

Basé sur le type integer, le type nonNegativeInteger représente un nombre entier qui n’est pas négatif, c’est-à-dire un nombre supérieur ou égal à zéro.

Soit l’exemple suivant :

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

<nombre>42</nombre>

<nombre>0</nombre>

<nombre>+00042</nombre>

Le type positiveInteger

Basé sur le type nonNegativeInteger, le type positiveInteger représente un nombre entier strictement positif, c’est-à-dire strictement supérieur à zéro.

Le type unsignedLong

Le type unsignedLong est basé sur le type nonNegativeInteger et représente un entier compris entre les valeurs 0 et 18 446 744 073 709 551 615.

Le type unsignedInt

Le type unsignedInt est basé sur le type unsignedLong et représente un entier compris entre les valeurs 0 et 4 294 967 295.

Le type unsignedShort

Le type unsignedShort est basé sur le type unsignedInt et représente un entier compris entre les valeurs 0 et 65 535.

Le type unsignedByte

Le type unsignedByte est basé sur le type unsignedShort et représente un entier compris entre les valeurs 0 et 255.

Les autres types

Le tableau récapitulatif

Plus en détails

Le type boolean

Le type boolean, comme son nom le laisse deviner, représente un booléen. Pour ceux qui ignorent de quoi il s’agit, un booléen permet d’indiquer l’un des 2 états suivant : vrai ou faux.

Si 2 états sont possibles, 4 valeurs sont en réalités acceptées :

• true qui représente l’état vrai.
• false qui représente l’état faux.
• 1 qui représente l’état vrai.
• 0 qui représente l’état faux.

Conscient que cette notion n’est pas forcément facile à comprendre lorsque c’est la première fois qu’on la rencontre, je vais tenter de l’illustrer avec un exemple. Notre exemple va nous permettre, via un attribut, de savoir si une personne est un animal ou pas.

<xsd:attribute name="animal" type="xsd:boolean" />

<!-- Victor Hugo n'est pas un animal -->
<personne animal="false">Victor Hugo</personne>

<!-- Zozor est bien un animal -->
<personne animal="true">Zozor</personne>

Le type QName

Le type QName représente un nom qualifié. C’est un concept qui s’appuie sur l’utilisation des espaces de nom.

Le type NOTATION

Le type NOTATION permet d’identifier et décrire du contenu XML ou non comme par exemple une image.

Le type anyURI

Comme son nom l’indique, le type anyURI représente une URI (Uniform Resource Identifier). Une URI est une chaîne de caractères qui permet d’identifier une ressource.

On distingue généralement 2 types d’URI :

• Les URL (Uniform Resource Locator) est probablement la forme d’URI la plus connue et je suis sûr que ce nom vous parle. En effet, les URL sont utilisés pour décrire l’adresse d’une ressource sur un réseau.
• Les URN (Uniform Resource Name) sont quant à eux utilisés pour identifier une ressource dans un espace de noms. Je ne vais pas m’attarder sur les URN car nous reviendrons plus tard dans ce cours sur la notion des espaces de nom.

Une URI permet d’identifier une ressource de manière relative ou absolue.

Voyons ensemble quelques exemples :

<xsd:attribute name="adresse" type="xsd:anyURI"/>

<!-- URI absolu -->
<image adresse="http://www.siteduzero.com/bundles/common/images/spreadsheetV32.png" />

<!-- URI relatif -->
<image adresse="../bundles/common/images/spreadsheetV32.png"/>

Le type base64Binary

Le type base64Binary représente une donnée binaire au format Base64. Vous trouverez plus d’informations à ce sujet sur Wikipedia.

Comme de nombreux types que nous avons vu, le type base64Binary impose le respect de plusieurs règles :

• Seules les lettres (majuscules ou minuscules), les chiffres et les symboles + / et = sont autorisés.
• Le nombre de caractères qui composent la chaîne doit être un multiple de 4.

Dans le cas où le symbole = est utilisé, de nouvelles règles doivent être respectées :

• Il ne peut apparaître qu’en fin de chaîne, une fois ou deux.
• Dans le cas où il est utilisé qu’une seule fois, il doit forcément être précédé des caractères A Q g ou w.
• Dans le cas où il est utilisé 2 fois, il doit forcément être précédé des caractères A E I M Q U Y c g k o s w 0 (zéro) 4 ou 8.

Le type hexBinary

Le type hexBinary représente une donnée binaire au format hexadecimal.

Si comme pour le type base64Binary quelques règles sont à respecter, elles sont bien plus simples dans le cas du type hexBinary. Ainsi, seuls les lettres entre A et F (majuscules ou minuscules), ainsi que les chiffres sont autorisés.

En résumé

• Il existe 4 grandes familles de types simples.
• Ces familles permettent d’être très précis quant à la description des éléments simples et des attributs.

Ce cours vous plait ?

Retrouvez ce cours en livre physique sur Amazon !