Supplément sur les schémas
Utilisation de types dérivés à la place d'un type de base
Partout, dans un document XML, où un certain type d'élément est autorisé, on est en droit d'utiliser un type dérivé de ce type là. Il faudra juste indiquer explicitement le type utilisé à l'aide de l'atribut xsi:type. Par exemple, si un document XML utilise un schéma dans lequel le type JourDeSemaine est dérivé par restriction du type xsd:string, un élément devant normalement être de type xsd:string pourra être déclaré de type JourDeSemaine de la façon ci-dessous, permettant ainsi d'être plus précis quant au type de contenu attendu (dans notre cas, on veut que le titre soit un jour de la semaine):
<titre xsi:type="JourDeSemaine">Mardi</titre>
L'intérêt, ici, est qu'une faute de frappe dans le jour de la semaine sera détectée par un outil de validation, alors qu'autrement la faute aurait passé inaperçue. Une autre possibilité d'utilisation de ce mécanisme est lorsque plusieurs variantes d'un type de base existent et que l'on veut permettre l'utilisation, dans le document XML, de n'importe laquelle des variantes.
Groupes
L'élément de schéma <xsd:group> permet de regrouper un certain nombre de déclarations comme une seule entité. Par exemple, si dans une déclaration d'alternatives (<xsd:choice>), certaines alternatives sont composées de plusieurs éléments, ces éléments doivent être regroupés pour ne pas être considérés chacuns comme une des alternatives. Dans l'exemple ci-dessous, l'élément destinataire peut contenir soit un élément pseudo soit la séquence d'éléments prenom et nom.
<xsd:element name="destinataire">
<xsd:complexType>
<xsd:choice>
<xsd:element name="pseudo" type="xsd:string"
/>
<xsd:group>
<xsd:sequence>
<xsd:element name="prenom"
type="xsd:string" />
<xsd:element name="nom" type="xsd:string"
/>
</xsd:sequence>
</xsd:group>
</xsd:choice>
</xsd:complexType>
</xsd:element>
L'élément de schéma <xsd:attributeGroup> permet de regrouper un certain nombre de déclarations d'attributs, soit pour améliorer la lisibilité, soit pour réutiliser ce même groupe à plusieurs endroits d'un schéma. Par exemple:
<xsd:attributeGroup name="DateEtLieu">
<xsd:attribute name="date" type="..." />
<xsd:attribute name="lieu" type="..." />
</xsd:attributeGroup>
permet de définir la version avec attributs de l'élément article ainsi:
<xsd:element name="article" >
<xsd:complexType>
... <!-- les attributs doivent être déclaré
après les sous-éléments -->
<xsd:attribute name="titre" type="xsd:string" />
<xsd:attribute name="auteur" type="xsd:string" use="required"
/>
<xsd:attributeGroup ref="DateEtLieu" />
</xsd:complexType>
</xsd:element>
Groupes de substitution
Les déclarations
<xsd:element name="enfant" type="PersonneType" />
<xsd:element name="fille" type="PersonneType" substitutionGroup="enfant"
/>
<xsd:element name="garçon" type="PersonneType"
substitutionGroup="enfant" />
permettent d'utiliser un élément fille ou garçon partout où un élément enfant serait normalement autorisé. L'élément substituable (enfant) doit être déclaré au niveau global, c-à-d qu'il ne doit pas être déclaré en tant que sous-élément d'un autre élément.
Types et éléments abstraits
L'utilisation de l'attribut abstract="true" dans la définition d'un type ou d'un élément permet d'indiquer que le type ou l'élément en question ne peut pas être utilisé tel quel, mais qu'il ne peut être utilisé que dans une dérivation ou un groupe de substitution. Par exemple, dans les déclarations ci-dessous, l'élément enfant ne peut pas être utilisé dans un document XML. Seuls les éléments fille et garçon peuvent l'être.
<xsd:element name="enfant" type="PersonneType" abstract="true" />
<xsd:element name="fille" type="PersonneType" substitutionGroup="enfant"
/>
<xsd:element name="garçon" type="PersonneType"
substitutionGroup="enfant" />
Restrictions de dérivations, restrictions de l'utilisation de dérivations
Si l'on désire éviter qu'un type donné ne soit utilisé pour dériver de nouveaux types à l'aide des mécanismes de restriction et/ou d'extension, la déclaration du type peut comporter l'attribut xsd:final pouvant prendre une des valeurs restriction, extension, ou #all. Cela empèchera respectivement de restreindre, d'étendre, ou de dériver d'une façon ou de l'autre le type ainsi déclaré.
Si l'on désire éviter que les dérivations d'un type donné ne soient utilisées en lieu et place du type donné, on peut utiliser l'attribut xsd:block (pouvant prendre les mêmes valeurs que l'attribut xsd:final) pour l'indiquer. Une substitution de type ne pourra alors pas avoir lieu si elle est du genre mentionné par l'attribut xsd:block. Par exemple, la déclaration
<xsd:element name="titre" type="xsd:string" block="restriction" />
dans un schéma empèchera d'utiliser
<titre xsi:type="JourDeSemaine">Mardi</titre>
dans un document XML utilisant ce schéma pour restreindre le contenu du titre.
Modularisation
Il existe trois mécanismes pour répartir de nombreuses et complexes déclarations:
- inclusion: l'élément <xsd:include schemaLocation="...UneURL..." /> est équivalent à avoir le contenu du fichier se trouvant à l'URL désignée en lieu et place de l'élément <xsd:include ...>. Le fichier inclus sert à définir le même espace de nom que le schéma où l'inclusion est faite.
- importation: l'élément <xsd:import schemaLocation="...UneURL...">, venant en tout premier après la balise d'ouverture d'un schéma, permet d'utiliser les définitions du schéma défini à l'URL en question dans le schéma où l'importation est faite.
- redéfinition: l'élément <xsd:redefine schemaLocation="...UneURL..."> a un effet très similaire à celui de l'inclusion, mais permet de redéfinir certains des types du schéma externe en conservant le même identificateur de type
Bertrand Ibrahim
