XML Schema tome 1 : Structures

1 Introduction

Ce document expose la partie structurante (XML Schema tome 1 : Structures) du langage de définition de XML Schema.

Le chapitre 2 présente le cadre conceptuel (§2) de XML Schema, comprenant une introduction à la nature des schémas XML et au modèle de données abstrait qui s'y rapporte, on y trouve également des définitions terminologiques générales.

Le chapitre Descriptions détaillées des composants de schéma (§3) donne tous les détails de la sémantique de chaque composant du modèle abstrait et leurs représentations XML, en faisant référence à la DTD et au schéma XML d'un document de type schéma XML, les correspondances précises entre le vocabulaire des éléments et des attributs de la représentation physique et les composants et les propriétés du modèle abstrait y sont également spécifiées.

Le chapitre 4 qui présente les Schémas et les espaces de noms : accès et assemblage (§4) contient la description des relations entre documents et schémas, l'import, l'inclusion et la redéfinition des déclarations et des définitions et les critères fondamentaux de validité des schémas.

Le chapitre 5 qui concerne l'évaluation de la validité des schémas (§5) contient la description des considérations générales qui gouvernent l'évaluation de la validité de schéma des documents et les responsabilités des programmes validant.

Les chapitres normatifs des annexes portent, entre autres, sur le schéma des schémas (§A) pour la représentation physique des schémas en XML et les références bibliographiques (§B).

Les chapitres non-normatifs des annexes portent, entre autres, sur la DTD des schémas (§G) et le glossaire (§F).

L'objectif primordial de ce document est d'être la référence de la définition du langage. En cela, et bien qu'il contienne quelques exemples, il n'est pas fondamentalement conçu pour être un guide méthodologique à utiliser comme aide au démarrage à la conception et aux fonctionnalités de modèles XML. Au lieu de cela, il contient plutôt une définition complète et minutieuse du modèle conceptuel propre à servir de guide aux développeurs qui implémenteront la norme. Pour ceux qui ont besoin d'une aide au démarrage, il est conseillé de lire d'abord le tome non-normatif de la recommandation [XML Schema tome 0 : introduction].

1.1 But

Le but de XML Schema tome 1: structures est de définir la nature des schémas XML et des parties qui les composent, fournissant un inventaire exhaustif des balises XML servant à monter des représentations physiques des modèles et définir en quoi concerne l'application de modèles à des documents XML.

Le but d'un modèle (note de traduction : ou 'schéma', nous utilisons indifféremment dans ce document l'un ou l'autre de ces deux termes) conforme à cette recommandation est de définir et décrire une classe de documents XML. Cela se fait via des composants de modélisation qui permettent de définir les contraintes et documenter la signification, l'utilisation et les relations de dépendances des constituants d'un document XML : les types de données, les éléments et leurs contenus, les attributs et leurs valeurs. Les schémas permettent également de spécifier des informations complémentaires au document, comme par exemple la normalisation et la gestion des valeurs par défaut des attributs et des éléments. Les schémas offrent des facilités pour être auto-documentés. C'est ainsi que XML Schema tome1 : structures peut être utilisé pour définir, décrire et cataloguer des vocabulaires XML spécifiques à différentes classes de documents.

Toute application utilisant des données XML bien formées peut utiliser le formalisme de modèles ici décrits pour exprimer des contraintes de contenu, syntaxiques et structurelles applicables aux instances de documents. Le formalisme de XML Schema tome 1 : Structures offre un niveau suffisamment pratique d'expression de contraintes pour pouvoir être décrit et implémenté dans une grande variété d'applications XML. Toutefois, le langage défini par cette spécification n'essaie pas de fournir toutes les possibilités dont n'importe quelle application pourrait avoir besoin. Certaines d'entre elles pourraient avoir besoin de disposer de contraintes dont l'expression n'est pas prévue dans ce langage et par conséquent avoir besoin de gérer en plus leurs propres règles de validations.

<schema targetNamespace="http://www.example.com/XMLSchema/1.0/mySchema">

Les références à des éléments dans le texte sont des liens à l'illustration qui correspond comme dans l'exemple ci-dessus, mis en valeur par des signes inférieurs et supérieurs, par exemple <example>.

Les références aux propriétés des unités d'information comme cela est défini dans [XML-Infoset] sont balisées sous la forme de liens au chapitre correspondant et sont mises en valeur par des crochets , par exemple [enfants].

Les propriétés des unités d'information que cette spécification définit sont présentées comme suit :

Les références aux propriétés des unités d'information définies dans cette spécification sont balisées sous la forme de liens vers l'endroit où elles sont introduites comme dans l'exemple ci-dessus. La propriété est alors mise en valeur par des crochets, par exemple [nouvelle propriété].

La mise en valeur suivante est utilisée pour les commentaires non-normatifs de ce document :

Remarque : commentaires généraux destinés à tous les lecteurs.

Suivant les règles de [XML 1.0 (Second Edition)], à l'intérieur du texte de cette spécification, les verbes pouvoir et devoir sont définis comme suit :

pouvoir

Les documents conformes et les programmes validant peuvent faire ce qui est écrit mais ne sont toutefois pas tenus de le faire.

devoir

Les documents conformes et les programmes validant doivent se comporter comme cela est décrit  ; sinon, le système devra produire une erreur.

Remarquez que cette spécification fournit une définition des erreurs et de la manière dont les programmes conformes doivent réagir par rapport aux erreurs (référez-vous au chapitre L'évaluation de la validité des schémas (§5)) qui est infiniment plus complexe que celle de [XML 1.0 (Second Edition)].

2 Cadre conceptuel

Ce chapitre donne un aperçu du modèle abstrait des structures de XML Schema. Le chapitre Détails des composants de schéma (§3) fournit les détails de ce modèle dont la représentation XML normative des composants du modèle abstrait. Les lecteurs dont l'objectif principal est d'apprendre à écrire des documents de type schéma peuvent commencer par lire le tutorial [XML Schema tome 0 : Introduction] et de consulter seulement ensuite les sous-chapitres intitulés Représentation XML de ... qui contiennent tous les détails de la spécification (ces sous-chapitres sont ceux du grand chapitre Détails sur les composants de schéma (§3)).

2.2.2 Composants de déclaration

Il y a trois types de composants de déclarations (élément, attribut et notation) qui sont décrits dans les sous-chapitres ci-dessous. Nous présentons également la fonction du groupe de substitution d'élément qui s'utilise pour les déclarations d'éléments.

<!ELEMENT A . . .>
<!ATTLIST A . . .>

2.2.3.1 Groupe modèle

Un groupe modèle est une contrainte exprimée sous la forme d'un fragment de grammaire qui s'applique à des listes d'unités d'information de type élément. Il est constitué d'une liste de particules, comme des déclarations d'éléments, des caractères génériques et des groupes modèles. Il y a trois sortes de groupes modèles :

• Séquence (les unités d'information de type élément correspondent aux particules selon l'ordre séquentiel défini) ;
• Et (les unités d'information de type élément correspondent aux particules, dans n'importe quel ordre);
• Ou (l'unité d'information de type élément correspond à l'une des particules).

Pour avoir les informations détaillées sur les groupes modèles, reportez vous au chapitre Groupes modèles (§3.8).

2.2.3.2 Particules

Une particule est un terme de la grammaire des contenus d'éléments qui correspond soit à une déclaration d'élément soit à un caractère générique soit à un groupe modèle et à des contraintes d'occurrence. Les particules participent à la ·validation· en tant qu'élément de référence servant à ·valider· des définitions de types complexes, dans lesquelles leur rôle et de permettre à tout moment la présence de zéro à n unités ou séquences d'information de type élément, en fonction de leurs contenus et des contraintes d'occurrence.

[Définition :]  Une particule peut être utilisée dans une définition de type complexe pour contraindre la ·validation· des [enfants] d'une unité d'information de type élément ; une telle particule est appelée modèle de contenu.

Remarque : Les ·modèles de contenu· de XML Schema tome 1 : Structures sont comparables tout en étant plus expressifs à ceux de [XML 1.0 (Second Edition)]  ; la nouveauté par rapport à [XML 1.0 (Second Edition)], est que XML Schema tome 1 : Structures applique le principe des ·modèles de contenu· à la ·validation· des modèles de contenu mixte alors que [XML 1.0 (Second Edition)] en limitait l'usage aux seuls contenus constitués uniquement d'éléments.

Pour avoir des informations détaillées sur ces particules, reportez-vous au chapitre Particules (§3.9).

2.2.3.3 Utilisation des attributs

L'utilisation d'un attribut joue un rôle similaire à celui d'une particule mais pour des déclarations d'attributs : une déclaration d'attribut à l'intérieur de la définition d'un type complexe est encapsulée par un attribut utilisé qui permet de spécifier si il est obligatoire ou optionnel et si sa valeur existe par défaut et si elle est fixée.

2.2.3.4 Caractère générique

Un caractère générique est un type spécial de particule qui correspond à des unités d'information de type attribut et élément qui dépendent de leur nom d'espace de noms, indépendamment de leurs noms locaux.

Pour avoir des informations détaillées sur les caractères génériques, reportez-vous au chapitre Caractères génériques (§3.10).

2.2.5.1 Définition de groupes modèles

Une définition de groupe modèle est une association entre un nom et un groupe modèle, en permettant ainsi la réutilisation dans plusieurs autres définitions de types complexes.

Pour avoir des informations détaillées sur les définitions des groupes modèles, reportez-vous au chapitre définitions des groupes modèles (§3.7).

2.2.5.2 Définition d'un groupe attribut

Une définition de groupe attribut est une association entre un nom et un ensemble de déclarations d'attributs, en permettant ainsi la réutilisation dans plusieurs autres définitions de types complexes.

Pour avoir des informations détaillées sur ces définitions de groupes d'attributs, reportez-vous au chapitre définitions de groupes d'attributs (§3.6).

2.3 Contraintes et règles de validation

La spécification [XML 1.0 (Second Edition)] décrit deux types de contraintes qui peuvent porter sur des documents XML : l'une porte sur la qualité de la forme et l'autre sur la validité. De manière informelle, la contrainte de qualité de la forme est celle imposée par la définition même de XML (tel que par exemple les règles d'utilisation des caractères < et > et celles d'imbrication des éléments) tandis que les contraintes de validité sont des contraintes supplémentaires qui s'appliquent à la structure du document par rapport aux règles édictées dans une DTD.

Le chapitre précédent est centré sur les questions de ·validation·, c'est à dire sur les contraintes imposées aux unités d'information spécifiées par les composants de schéma. En fait, cette spécification fournit quatre sortes différentes d'expressions normatives portant sur les composants de schéma, leur représentation XML et leurs contributions à la ·validation· des unités d'information :

Contraintes des composants de schéma

[Définition :] Les contraintes des composants de schéma eux-mêmes sont des conditions auxquelles ils doivent satisfaire. Ces contraintes sont systématiquement présentées dans le sixième sous-sous-chapitre de chaque sous-chapitre du chapitre Détails sur les composants de schéma (§3) et sont récapitulées dans l'annexe Contraintes des composants de schéma (§C.4).

Contraintes portant sur la représentation des schémas

[Définition :] Il s'agit de contraintes portant sur la représentation XML des composants de schéma qui vont au-delà de celles exprimées au chapitre sur le Schéma des schémas (partie normative) (§A). Systématiquement présentées dans le troisième sous-sous-chapitre de chaque sous-chapitre du chapitre Détails sur les composants de schéma (§3) et sont récapitulés dans l'annexe Contraintes de représentation des schémas (§C.3).

Règles de validation

[Définition :]  Il s'agit des contributions à la ·validation· associées aux composants de schéma. Situées dans le quatrième sous-sous-chapitre de chaque sous-chapitre du chapitre Détails sur les composants de schéma (§3) et récapitulées dans l'annexe règles de validation (§C.1).

Contributions à l'ensemble d'information du schéma

[Définition :]  Il s'agit des compléments aux ensembles d'information apportés par une ·validation· ou une ·évaluation· et exprimés par des composants de schéma. Situés dans le cinquième sous-sous-chapitre de chaque sous-chapitre du chapitre Détails sur les composants de schéma (§3) et récapitulés dans l'annexe Contributions de l'ensemble d'information résultant de la validation de schéma (§C.2).

Le dernier des points précédents, celui portant sur les contributions à l'ensemble d'information du schéma, n'est pas aussi nouveau qu'il n'y paraît. Le processus de validation de XML 1.0 apporte aussi ces compléments d'information, par exemple en insérant les valeurs par défaut des attributs initialement absents dans l'instance et en exploitant implicitement les informations de typage pour la normalisation ou l'accès (en guise d'exemple pour ce dernier cas, considérez l'effet du type NMTOKENS sur l'espace blanc des attributs et la sémantique ID/IDREF). En incluant à cette spécification les contributions à l'ensemble d'information des schémas, elle rend explicite certaines dispositions implicites de XML 1.0.

2.4 Conformité

Cette spécification décrit trois niveaux de conformité pour les programmes de traitement validant. Le premier niveau est obligatoire pour tous les programmes. Le support des deux autres dépend des environnements applicatifs pour lesquels le programme est prévu.

[Définition :] Les programmes de traitement qui ont un niveau de conformité minimale doivent complètement et correctement mettre en application les ·Contraintes des composants de schéma·, les ·règles de validation· et les ·contributions à l'ensemble d'information du schéma· contenues dans cette spécification.

[Définition :] Les programmes de traitement qui acceptent les schémas représentés sous la forme de documents XML tels qu'ils sont décrits au chapitre Niveau 2 : documents XML de type schéma, espaces de noms et assemblage (§4.2) sont de plus dits fournir une conformité avec la représentation XML des schémas. Ces programmes de traitement doivent, quand ils traitent des documents de type schéma, complètement et correctement exécuter toutes les ·contraintes de représentation des schémas· décrites dans cette spécification et doivent adhérer exactement aux spécifications du chapitre Détails sur les composants de schéma (§3) pour faire correspondre le contenu de tels documents à des ·composants de schéma· et les utiliser lors de la ·validation· et de ·l'évaluation·.

Remarque : En faisant la distinction entre les exigences de conformité relatives à la syntaxe concrète des documents XML de type schéma, cette spécification admet que les programmes de traitement puissent utiliser des schémas qui sont soit enregistrés sous la forme de représentations binaires optimisées, soit créés dynamiquement en les considérant comme langage de programmation de données structurées soit compilés pour donner des programmes exécutables en C ou Java. De tels programmes de traitement peuvent être dits avoir un niveau de ·conformité minimale· sans être nécessairement en ·conformité avec la représentation XML des schémas·.

[Définition :] les programmes de traitement complètement conforme sont ceux qui permettent de fonctionner en réseau et qui vont au delà de la ·conformité minimale· et de la ·conformité avec la représentation XML des schémas· en étant capables d'aller chercher des schémas sur le World Wide Web d'après la Représentation des schémas sur le World Wide Web (§2.7) et le chapitre sur Comment les définitions des schémas sont repérées sur le Web (§4.3.2). .

Remarque : Bien que cette spécification ne fournisse que ces trois niveaux de conformité en standard, on anticipe le fait que d'autres conventions puissent être établies dans le futur. Par exemple, le World Wide Web Consortium réfléchit à des conventions pour mettre à disposition sur le Web une variété de ressources relatives à des documents et des espaces de noms particuliers. Si de tels développements devaient conduire à de nouvelles formes de représentation des schémas, ne serait-ce que pour pouvoir y accéder à partir du Web, alors de nouveaux niveaux de conformité pourraient être établis et baptisés à ce moment là. Il n'y aura alors pas besoin de modifier ou de republier cette spécification pour définir ces nouveaux niveaux de conformité.

Reportez-vous au chapitre sur les Schémas et les espaces de noms : accès et assemblage (§4) pour une explication plus détaillée des mécanismes supportant ces niveaux de conformité.

2.5 Noms et espaces de symboles

Comme cela a été présenté au chapitre Modèle de données abstrait de XML (§2.2), la plupart des composants de schéma ont des ·noms· (ce n'est pas une obligation). Si tous ces noms étaient mis en commun, alors il serait impossible d'avoir, par exemple, une définition de type simple et une déclaration d'élément ayant le même nom "title" en même temps et dans le même ·espace de noms cible·.

Par conséquent [Définition :]  Cette spécification introduit la notion d'espace de symboles pour dénoter une collection de noms dans laquelle chacun est unique vis à vis des autres. Un espace de symboles est similaire au concept non-normatif de partition d'espace de noms introduit dans [XML-Namespaces]. Par ·espace de noms cible·, il y a un seul espace symbole distinct des autres par type de composant de définition et de déclaration identifié au chapitre Modèle de données abstrait de XML (§2.2). A l'exception de celles se trouvant à l'intérieur d'un espace de noms cible, les définitions de types simples et complexes partagent un même espace de symboles. Les noms sont uniques à l'intérieur d'un espace de symboles donné mais un même nom peut apparaître dans plusieurs espaces de symboles sans qu'il y ait conflit. Par exemple, le même nom peut apparaître à la fois dans une définition de type et une déclaration d'élément, sans conflit ou relation particulière entre les deux.

Les déclarations d'attributs et d'éléments de portée locale sont des cas particuliers au regard des espaces de symboles. Chaque définition de type complexe définit ses propres espaces de symboles pour les déclarations locales d'attributs et d'éléments, distincts les uns des autres comme de tout autre espace de symboles. Ainsi, par exemple, deux définitions de types complexes ayant le même espace de noms cible peuvent contenir toutes les deux une même déclaration locale d'un attribut de nom non-qualifié "priority" ou une même déclaration locale d'élément de nom "address", sans qu'il y ait de conflit ou une relation nécessaire entre les deux.

2.6 Balisage relatif au schéma des documents étant validés

La représentation XML de composants de schéma utilise un vocabulaire identifié par le nom d'espace de noms http://www.w3.org/2001/XMLSchema. Pour simplifier le texte et les exemples présents dans cette spécification, on y utilise systématiquement le préfixe xs: pour faire référence à cet espace de nom ; en réalité, n'importe quel préfixe pourrait être utilisé.

XML Schema tome 1: Structures a aussi plusieurs attributs préfabriqués destinés à être utilisés directement dans tout document XML. Ces attributs sont dans un espace de noms différent, qui a le nom d'espace de noms http://www.w3.org/2001/XMLSchema-instance. Pour simplifier le texte et les exemples de cette spécification, on utilise systématiquement le préfixe xsi: pour référencer cet espace de noms ; en réalité, n'importe quel préfixe aurait pu être utilisé. Tous les programmes de traitement des schémas ont des déclarations d'attributs appropriées pour ces attributs préfabriqués, reportez-vous au chapitre Déclaration d'attribut de l'attribut 'type' (§3.2.7), Déclaration d'attribut de l'attribut 'nil' (§3.2.7), Déclaration d'attribut de l'attribut 'schemaLocation' (§3.2.7) et Déclaration d'attribut de l'attribut 'noNamespaceSchemaLocation' (§3.2.7).

2.6.1 xsi:type

La définition de type simple (§2.2.1.2) ou la définition de type complexe (§2.2.1.3) utilisée dans la ·validation· d'un élément est habituellement déterminée par une référence aux composants de schéma. Une unité d'information de type élément dans une instance peut, cependant, déclarer explicitement son type en utilisant l'attribut xsi:type. La valeur de cet attribut est un ·QName· ; reportez-vous au chapitre Interprétation des noms qualifiés (QName) (§3.15.3) pour connaître la manière dont un ·QName· est associé à une définition de type.

2.7 Représentation des schémas sur le World Wide Web

Sur le World Wide Web, les schémas sont conventionnellement représentés comme des documents XML (ayant de préférence un type MIME application/xml ou text/xml, mais regardez la clause 1.1 du chapitre Contraintes et sémantique de l'inclusion (§4.2.1)), conformes aux spécifications du chapitre Niveau 2 : Documents de type schéma, espaces de noms et assemblage (§4.2). Pour plus d'informations sur la représentation et l'utilisation des documents de type schéma sur le World Wide Web reportez-vous aux chapitres Standards pour la représentation des schémas et récupération de documents de type schéma sur le Web (§4.3.1) et Comment sont localisées les définitions de schéma sur le Web (§4.3.2).

3 Détails sur les composants de schéma

3.1.2 Représentations XML des composants

L'objectif principal de XML Schema tome1 : Structures est de définir un ensemble de composants de schéma qui imposent des contraintes aux contenus des instances et augmentent les ensembles d'information lors de la validation ou de l'évaluation. Bien qu'aucune représentation externe des schémas ne soit obligatoire dans ce but, de telles représentations seront évidemment largement utilisées. Pour répondre à ce besoin de manière adaptée et interopérable, cette spécification fournit une représentation normative des schémas en XML qui se charge de cette question dans chaque cas de composant de schéma. [Définition :]  Un document de cette forme (c'est à dire une unité d'information de type élément <schema> ) est un document de type schéma. Tant pour le document de type schéma dans sa globalité que pour ses constituants, les chapitres ci-dessous définissent des correspondances entre les unités d'information de type élément (dont les déclarations sont dans le Schéma des schémas (§A) et la DTD des schémas (§G)) et les composants de schéma. Toutes les unités d'information de type élément de la représentation XML d'un schéma doivent être dans l'espace de noms des schémas XML, c'est à dire que leur [nom d'espace de noms] doit être http://www.w3.org/2001/XMLSchema. Bien qu'une manière commune de créer l'ensemble d'information XML qui est lui-même ou contient des ·documents de type schéma· sera d'utiliser un programme de validation lexico-syntaxique XML (parser), cela n'est pas obligatoire : tout mécanisme capable de construire des ensembles d'informations conformes à ceux définis dans le dictionnaire terminologique de XML [XML-Infoset] est un point de départ possible.

Deux aspects de la représentation XML des composants présentée dans les chapitres qui suivent sont communs à toutes les représentations :

1. Toutes autorisent les attributs qualifiés par des noms d'espaces de noms autres que l'espace de noms des schémas XML lui-même : ils apparaissent comme des annotations dans le composant de schéma correspondant ;
2. Toutes permettent d'avoir une <annotation> comme premier enfant à des fins de lisibilité de la documentation et/ou de traitement par un programme.

3.2 Déclarations d'attributs

Les déclarations d'attributs servent à :

• ·valider· localement les valeurs d'une unité d'information de type attribut utilisant une définition de type simple ;
• spécifier les valeurs fixes ou par défaut des unités d'information de type attribut.

<xs:attribute name="age" type="xs:positiveInteger" use="required"/>

3.2.1 Le composant de schéma de déclaration d'attribut

Le composant de schéma de déclaration d'attribut a les propriétés suivantes :

La propriété {nom} doit correspondre à la partie locale des noms des attributs étant ·validés·.

La valeur de l'attribut doit être conforme à la {définition de type} fournie.

Quand la propriété {espace de noms cible} est présente (elle n'est donc pas ·absente·), elle sert à la ·validation· des unités d'information de type attribut qualifiées par un espace de nom (qui doit être explicitement préfixé d'une forme de type caractère du niveau des documents XML). L'·absence· de cette propriété ·valide· les unités qui ne sont pas qualifiées (c'est à dire sans préfixe).

La propriété {portée} permet de connaître, quand la valeur est global, les déclarations d'attributs disponibles pour une utilisation dans n'importe quelle définition de type complexe, dans tout le schéma. Les déclarations de portée locale sont disponibles pour une utilisation uniquement à l'intérieur des définitions de types complexes identifiées par la propriété {portée}. Cette propriété est ·absente· dans le cas où les déclarations sont à l'intérieur des définitions de groupes d'attributs : leur portée sera déterminée quand elles seront utilisées dans la construction de définitions de types complexes.

{contrainte de valeur} reproduit les fonctions des valeurs d'attributs par défaut et #FIXED de XML 1.0 . default spécifie que l'attribut doit apparaître sans condition particulière dans l'ensemble d'information résultant de la validation de schéma, la valeur fournie étant celle utilisée chaque fois que l'attribut n'est pas réellement présent ; fixed indique que la valeur de l'attribut, si il est présent, doit être égal à la valeur de la contrainte fournie et, si il est absent, prend la valeur fournie par défaut. Remarquez que ce sont des valeurs qui sont fournies et/ou contrôlée et non des chaînes de caractères.

Reportez-vous au chapitre Annotations (§3.13) pour les informations sur le rôle de la propriété {annotation}.

Remarque : Une présentation plus complète et plus formelle de la sémantique des propriétés {nom}, {espace de noms cible} et {contrainte de valeur} est fournie en même temps que d'autres aspects de la ·validation· du type complexe (référez-vous au chapitre Elément localement valide (type complexe) (§3.4.4)).

La spécification [XML-Infoset] fait le distinguo entre des attributs nommés tels que xmlns ou xmlns:xsl et les attributs ordinaires, identifiant les deux premiers comme étant des [attributs d'espace de noms]. En conséquence, il est inutile et en fait impossible que les schémas contiennent des déclarations d'attributs correspondant à une telle déclaration d'espace de noms, reportez-vous pour cela au chapitre Interdiction de xmlns (§3.2.6). Rien n'est fourni dans cette spécification pour fournir une valeur par défaut à une déclaration d'espace de noms.

3.3 Déclarations d'éléments

Une déclaration d'élément sert à :

• La ·validation· locale des valeurs d'une unité d'information de type élément utilisant une définition de type ;
• Spécifier les valeurs fixées ou par défaut pour des unités d'information de type élément ;
• Etablir des relations de contrainte d'unicité et de référence entre les valeurs des éléments et des attributs ;
• Contrôler les possibilités de substitution des éléments par le mécanisme des ·groupes de substitution d'élément·.

<xs:element name="PurchaseOrder" type="PurchaseOrderType"/>

<xs:element name="gift">
 <xs:complexType>
  <xs:sequence>
   <xs:element name="birthday" type="xs:date"/>
   <xs:element ref="PurchaseOrder"/>
  </xs:sequence>
 </xs:complexType>
</xs:element>

3.3.1 Le composant de schéma de déclaration d'élément

Le composant de schéma de déclaration d'élément a les propriétés suivantes :

Le {nom} doit correspondre à la partie locale des noms des unités d'information de type élément étant ·validés·.

Une {portée} de valeur global identifie les déclarations d'élément disponibles pour une utilisation dans tous les modèles de contenu du schéma. Les déclarations de portée locale sont disponibles pour une utilisation qui se limite au type complexe identifié par la {portée}. Cette propriété est ·absente· dans le cas de déclarations se trouvant à l'intérieur de groupes modèles nommés : leur portée réelle est alors déterminée au moment de leur utilisation dans les définitions de types complexes.

{l'espace de noms cible} est utilisé (quand il n'est pas ·absent·) lors de la ·validation· des unités d'information de type élément qualifiées par un espace de noms. ·L'absence· de {l'espace de noms cible} ·valide· les unités d'information non-qualifiées.

Une unité d'information de type élément est ·valide· si elle satisfait à la {définition de type}. Pour une telle unité, les contributions à l'ensemble d'information du schéma proviennent de la {définition de type} et sont ajoutées à l'unité d'information de type élément correspondante dans l'ensemble d'information résultant de la validation de schéma.

Si le paramètre {annulable} est true, cela signifie qu'un élément peut être ·valide· si il est porteur d'un attribut qualifié d'espace de noms ayant un [nom local] nil issu de l'espace de noms http://www.w3.org/2001/XMLSchema-instance et la valeur true (référez-vous au chapitre xsi:nil (§2.6.2)) même en ayant aucun contenu de type textuel ou composé de sous-éléments alors que son {type de contenu} pourrait le demander voir même l'exiger. Les détails formels concernant la ·validation· des éléments sont décrits au chapitre Elément localement valide (Elément) (§3.3.4).

La {contrainte de valeur} définit quelle est la valeur par défaut ou la valeur fixée d'un élément. Si default est spécifié et si l'élément en cours de ·validation· est vide alors la forme canonique de la valeur de la contrainte fournie devient la [valeur normalisée par le schéma] de l'élément ·validé· dans l'ensemble d'information résultant de la validation de schéma. Si fixed est spécifié, alors le contenu de l'élément doit être soit vide, auquel cas fixed se comporte comme default, soit correspondre à la valeur de la contrainte fournie.

Remarque : la fourniture de valeurs par défaut pour les contenus d'éléments va au delà de ce qu'il est possible de faire avec les DTD de XML 1.0 et est légèrement différent du système des valeurs par défaut pour les attributs. En particulier, un élément ayant une{contrainte de valeur} non vide dont la définition de type simple inclue la chaîne de caractères vide dans son espace lexical ne recevra néanmoins jamais cette valeur, parce que la {contrainte de valeur} l'ignorera.

Les {définitions de contraintes d'identité} servent à exprimer les contraintes d'unicité et de référencement pour des valeurs d'éléments et d'attributs mis en relation. Reportez-vous au chapitre Définitions de la contrainte d'identité (§3.11).

Les déclarations d'élément sont membres du groupe de substitution, quand il existe, identifié par {l'affiliation du groupe de substitution}. L'appartenance comme membre est une relation transitive mais pas symétrique ; une déclaration d'élément est membre de tout groupe utilisant son {groupe de substitution affilié}.

Un ensemble de {groupes de substitution exclus} vide permet à une déclaration d'être nominée comme pouvant être une {affiliation de groupe de substitution} utilisée dans d'autres déclarations d'éléments ayant la même {définition de type} ou des versions dérivées de ce type. Sinon l'ensemble des {groupes de substitution exclus} exclue explicitement les déclarations d'éléments dont les {définitions de type} sont respectivement soit des extensions soit des restrictions . Si les deux valeurs sont spécifiées, cela interdit le référencement de la déclaration à partir d'autres déclarations via {l'affiliation d'un groupe de substitution}.

L'ensemble des {substitutions rejetées} permet de déterminer si une déclaration d'élément utilisée dans un ·modèle de contenu· sera empêchée d'avoir des éléments de ·validation· supplémentaires (a) ayant un xsi:type (§2.6.1) identifiant une extension ou une restriction du type de l'élément déclaré, et/ou (b) issus d'éléments de ·validation· qui sont dans le groupe de substitution dont l'élément déclaré est le chef de file. Si l'ensemble des {substitutions rejetées} est vide, alors tous les membres des types dérivés et des groupes de substitution sont autorisés.

Les déclarations d'élément {abstraites} peuvent apparaître dans des modèles de contenu seulement quand la substitution est autorisée ; de telles déclarations peuvent elles-mêmes n'être jamais utilisées pour ·valider· un contenu d'élément.

Reportez-vous au chapitre Annotations (§3.13) pour avoir les informations sur les possibilités des {annotations}.

3.4 Définitions d'un type complexe

Les définitions de types complexes servent à :

• Contraindre des unités d'information de type élément en leur fournissant des Déclaration d'attributs (§2.2.2.3) pilotant la forme et le contenu des [attributs]
• Contraindre une unité d'information [enfant] de type élément à être vide, ou à se conformer à un modèle de contenu mixte ou limité à des sous-éléments, ou encore contraindre une unité d'information [enfant] de type caractère à se conformer à une définition de type simple spécifiée.
• Utiliser les mécanismes du chapitre Hiérarchie des définitions de types (§2.2.1.1) pour dériver un type complexe à partir d'un autre type simple ou complexe.
• Spécifier les ·contributions à l'ensemble d'information résultant de la validation de schéma· pour les éléments.
• Limiter les possibilités de dérivation des types additionnels à partir d'un type complexe donné.
• Contrôler le droit à substituer, dans une instance, des éléments d'un type dérivé par des éléments déclarés dans un modèle de contenu d'un type complexe particulier.

<xs:complexType name="PurchaseOrderType">
  <xs:sequence>
   <xs:element name="shipTo" type="USAddress"/>
   <xs:element name="billTo" type="USAddress"/>
   <xs:element ref="comment" minOccurs="0"/>
   <xs:element name="items"  type="Items"/>
  </xs:sequence>
  <xs:attribute name="orderDate" type="xs:date"/>
 </xs:complexType>

3.4.1 Le composant de schéma de la définition d'un type complexe

Le composant de schéma correspondant à la définition d'un type complexe a les propriétés suivantes :

Les définitions de types complexes sont identifiées par leurs {nom} et {espace de noms cible}. Excepté pour les définitions anonymes de types complexes (celles qui n'ont pas de {nom}), puisque les définitions de types (aussi bien des types simples que complexes) doivent être identifiées de manière unique à l'intérieur d'un ·schéma XML·, aucune définition d'un type complexe ne peut avoir le même nom qu'une autre définition de type simple ou complexe. Le {nom} et {l'espace de noms cible} du type complexe sont fournis pour pouvoir y faire référence depuis les instances (référez-vous au chapitre xsi:type (§2.6.1)) et pour les utiliser dans la représentation XML des composants de schéma (spécifiquement dans <element>). Reportez-vous au chapitre Les références aux composants de schéma au travers des espaces de noms (§4.2.3) pour connaître les règles applicables à l'utilisation des identifiants de composants quand un schéma est importé dans un autre.

Remarque : Le {nom} d'un type complexe n'est pas ipso facto le [nom (local)] des unités d'information de type élément ·validées· par cette définition. Le rapport entre un nom et une définition de type est décrit au chapitre déclaration d'élément (§3.3).

Comme cela est décrit au chapitre Hiérarchie des définitions de types (§2.2.1.1), chaque type complexe est dérivé d'une {définition du type de base} qui est elle-même soit la définition d'un type simple (§2.2.1.2) soit celle d'un type complexe (§2.2.1.3). La {méthode de dérivation} spécifie la technique de dérivation utilisée à savoir soit extension soit restriction (référez-vous au chapitre Hiérarchie des définitions de types (§2.2.1.1)).

Un type complexe qui n'est pas {terminal} peut être utilisé comme {définition de type de base} pour d'autres types dérivés soit par extension soit par restriction ; les valeurs explicites extension et restriction permettent de se protéger des dérivations ultérieures par extension et restriction respectivement. Si toutes les valeurs sont spécifiées, alors [Définition :]  le type complexe est terminal, parce qu'aucune dérivation supplémentaire n'est possible. Cette caractéristique n'est pas héritée, c'est à dire qu'une définition de type dérivée par restriction à partir de la définition d'un type terminal en extension n'est pas elle-même, en l'absence de tout attribut le spécifiant explicitement, terminale elle-même pour quoi que ce soit.

Les types complexes {abstraits} ne peuvent pas être utilisés comme {définitions de type} pour la ·validation· d'unités d'information de type élément. Il s'ensuit qu'ils ne doivent pas être référencés à partir de l'attribut xsi:type (§2.6.1) dans une instance de document. Les types complexes abstraits peuvent être utilisés comme des {définitions de types de base}, ou même comme des {définitions de types} de déclarations d'éléments, étant supposé dans chaque cas que la définition concrète d'un type dérivé soit utilisée pour la ·validation·, soit via l'attribut xsi:type (§2.6.1) soit au moyen d'un groupe de substitution.

L'ensemble des {attributs utilisés} est formé des définitions des différentes utilisations des attributs utilisés dans le type complexe. Reportez-vous aux chapitres Elément localement valide (type complexe) (§3.4.4) et Attribut localement valide (§3.2.4) pour connaître les détails sur la ·validation· des attributs.

Les {attributs génériques} fournissent une spécification plus flexible pour la ·validation· des attributs qui ne sont pas explicitement inclus dans l'ensemble des {attributs utilisés}. De manière informelle, les valeurs spécifiques des {attributs génériques} sont interprétées comme suit :

• any : l'ensemble des [attributs] peut inclure des attributs ayant n'importe quel nom, qu'il soit qualifié ou non.
• un ensemble dont les membres sont soit des noms d'espaces de noms soit sont ·absents· : l'ensemble des [attributs] peut alors inclure tout attribut des espaces de noms spécifiés et si ·absent· est également inclu dans l'ensemble, alors tout attribut non qualifié est aussi autorisé.
• 'not' suivi d'un nom d'espace de noms : l'ensemble des [attributs] ne peut pas contenir d'attributs provenant de l'espace de noms exclu par le 'not'.
• 'not' suivi de ·absent· : l'ensemble des [attributs] ne peut pas inclure d'attributs non qualifiés.

Reportez-vous au chapitre Elément localement valide (type complexe) (§3.4.4) et Noms d'espaces de noms autorisés par les caractères génériques(§3.10.4) pour connaître les détails formels sur la validation des attributs génériques.

Le {type de contenu} détermine la ·validation· des [enfants] des unités d'information de type élément. De manière informelle :

• Un {type de contenu} ayant la valeur remarquable empty ·valide· les éléments qui n'ont aucun [enfant] quelque en soit le type, caractère ou élément.
• Un {type de contenu} qui est une définition de type simple (§2.2.1.2) ·valide· les éléments qui n'ont comme [enfants] que des caractères.
• Un {type de contenu} dont la valeur est elements-only ·valide· les éléments ayant des [enfants] conformes au ·modèle de contenu· fourni.
• Un {type de contenu} dont la valeur est mixed ·valide· les éléments dont les [enfants] de type élément uniquement (c'est à dire en ignorant volontairement les autres [enfants] tels que ceux de type caractère) sont conformes au ·modèle de contenu· fourni.

L'ensemble des {substitutions prohibées} détermine si une déclaration d'élément apparaissant dans un ·modèle de contenu· est protégé contre le rajout soit d'unités d'information de type élément participant à la ·validation· et ayant un attribut xsi:type (§2.6.1) ramenant une définition de type complexe obtenue par extension ou restriction, soit des unités d'information de type élément d'un groupe de substitution dont la définition de type est dérivée de manière similaire : si l'ensemble des {substitutions prohibées} est vide, alors toutes ces substitutions sont autorisées, sinon, si il liste une ou plusieurs méthodes de dérivation, celle-là sont interdites.

Reportez-vous au chapitre Annotations (§3.13) pour avoir plus d'informations sur le rôle des {annotations}.

3.5 Attribut utilisé

un attribut utilisé est un composant utilitaire qui contrôle l'occurrence et le comportement par défaut des déclarations d'attributs. Il joue, pour les déclarations d'attributs des types complexes, le même rôle que les particules pour les déclarations d'éléments.

<xs:complexType>
 . . .
 <xs:attribute ref="xml:lang" use="required"/>
 <xs:attribute ref="xml:space" default="preserve"/>
 <xs:attribute name="version" type="xs:number" fixed="1.0"/>
</xs:complexType>
     

3.5.1 Le composant de schéma d'un attribut utilisé

Le composant de schéma d'un attribut utilisé a les propriétés suivantes :

La {présence} précise si la présence d'une unité d'information de type attribut est simplement autorisée ou si elle est exigée.

La {déclaration d'attribut} fournit la déclaration d'attribut elle-même, qui, à son tour, permettra de déterminer la définition du type simple utilisé.

La {contrainte de valeur} permet d'avoir une spécification locale d'une valeur par défaut ou fixée. Cela doit être cohérent avec celle de la {déclaration d'attribut}, en ce sens que si la {déclaration d'attribut} spécifie une valeur fixée, la seule {contrainte de valeur} possible est alors cette même valeur.

3.6 Définition d'un groupe d'attributs

Un schéma permet de nommer le groupe des déclarations d'attributs de telle manière qu'elles puissent être incorporées comme groupe dans des définitions de types complexes.

Les définitions des groupes d'attributs ne participent pas à la ·validation· en tant que tel, mais l'ensemble des {attributs utilisés} et {l'attribut générique} d'une ou plusieurs définitions de types complexes peuvent être construites en tout ou partie par référence à un groupe d'attributs. Ainsi, les définitions de groupes d'attributs fournissent un remplaçant au mécanisme des entités paramètres de XML. Les définitions de groupes d'attributs sont initialement fournies pour pouvoir y faire référence à partir de la représentation XML des composants de schéma (référez-vous aux éléments <complexType> et <attributeGroup>).

<xs:attributeGroup name="myAttrGroup">
    <xs:attribute . . ./>
    . . .
</xs:attributeGroup>

<xs:complexType name="myelement">
    . . .
    <xs:attributeGroup ref="myAttrGroup"/>
</xs:complexType>

3.6.1 Le composant de schéma de définition d'un groupe d'attributs

Le composant de schéma de définition d'un groupe d'attributs a les propriétés suivantes :

Les groupes d'attributs sont identifiés par leurs {nom} et {espace de noms cible} ; l'identité d'un groupe d'attributs doit être unique à l'intérieur d'un ·schéma XML·. Reportez-vous au chapitre Les références aux composants de schéma au travers des espaces de noms (§4.2.3) pour l'utilisation des identifiants de composants quand un schéma est importé dans un autre.

L'ensemble des {attributs utilisés} est un ensemble constitué des attributs utilisés, où les occurrences peuvent avoir des spécifications locales de valeurs par défaut et de valeurs fixées.

{L'attribut générique} permet à un attribut générique d'être inclus dans un groupe d'attributs. Reportez-vous au chapitre ci-dessus Définitions de types complexes (§3.4) pour connaître quelle est l'interprétation des attributs génériques pendant la ·validation·.

Reportez-vous au chapitre Annotations (§3.13) pour avoir des informations sur le rôle de la propriété {annotation}.

3.7 Définition d'un groupe modèle

La définition d'un groupe modèle associe un nom et des annotations facultatives à un Groupe modèle (§2.2.3.1). En faisant référence au nom, la totalité du groupe modèle peut ainsi être incorporée dans un {terme}.

Les définitions des groupes modèles sont fournies en premier lieu pour pouvoir y faire référence à partir de la Représentation XML des définitions de types complexes (§3.4.2) (référez-vous aux éléments <complexType> et <group>). De cette façon, les définitions des groupes modèles remplacent l'utilisation des entités paramètre de XML.

<xs:group name="myModelGroup">
 <xs:sequence>
  <xs:element ref="someThing"/>
  . . .
 </xs:sequence>
</xs:group>

<xs:complexType name="trivial">
 <xs:group ref="myModelGroup"/>
 <xs:attribute .../>
</xs:complexType>

<xs:complexType name="moreSo">
 <xs:choice>
  <xs:element ref="anotherThing"/>
  <xs:group ref="myModelGroup"/>
 </xs:choice>
 <xs:attribute .../>
</xs:complexType>

3.7.1 Le composant de schéma de définition d'un groupe modèle

Le composant de schéma de définition d'un groupe modèle a les propriétés suivantes :

La définition d'un groupe modèle est identifiée par ses {nom} et {espace de noms cible} ; l'identité d'un groupe modèle doit être unique à l'intérieur d'un ·schéma XML·. Reportez-vous au chapitre sur les Références aux composants de schéma au travers des espaces de noms (§4.2.3) pour connaître les règles qui s'appliquent aux identifiants de composants quand un schéma est importé dans un autre.

Les définitions de groupes modèles ne participent pas directement à la ·validation· mais le {terme} d'une particule peut renvoyer, en tout ou partie, sur le groupe modèle d'une définition de groupe modèle.

Le {groupe modèle} est le groupe modèle (§2.2.3.1) auquel la définition du groupe modèle fournit un nom.

Reportez-vous au chapitre Annotations (§3.13) pour avoir plus d'informations sur les caractéristiques de la propriété {annotation}.

3.8 Groupes modèles

Quand les [enfants] d'une unité d'information de type élément ne sont ni vides ni formés de références à des définitions de types simples (Définition de type simples (§3.14)), alors la séquence des unités d'information de type élément [enfants] qui forme le contenu peut être spécifiée de manière précise avec un groupe modèle. A partir du moment où le {terme} d'une particule peut être un groupe modèle et qu'un groupe modèle peut contenir des particules, un groupe modèle peut indirectement contenir d'autres groupes modèles ; la grammaire des modèles de contenu est, par conséquence, récursive.

<xs:all>
 <xs:element ref="cats"/>
 <xs:element ref="dogs"/>
</xs:all>

<xs:sequence>
 <xs:choice>
  <xs:element ref="left"/>
  <xs:element ref="right"/>
 </xs:choice>
 <xs:element ref="landmark"/>
</xs:sequence>

3.8.1 Le composant de schéma des groupes modèles

Le composant de schéma des groupes modèles a les propriétés suivantes :

Ce composant permet de définir, respectivement, un modèle de contenu constitué d'une séquence (sequence), d'un choix exclusif (choice) ou d'un ensemble non-ordonné (all) de {particules} . Cela, à son tour, détermine si les unités d'information de type élément [enfants] ·validées· par le groupe modèle doivent :

• (sequence) correspondre, dans l'ordre, aux {particules} spécifiées ;
• (choice) correspondre à exactement une des {particules} spécifiées ;
• (all) contenir zéro ou une fois chacune des {particules}. Les éléments peuvent apparaître dans n'importe quel ordre. Dans ce cas, pour réduire les difficultés d'implémentation, {particules} est limité à ne contenir que des déclarations d'éléments locales ou supérieures dont le {nombre d'occurrences minimum}=0 ou 1 et le {nombre d'occurrences maximum}=1.

Quand deux particules ou plus contenues directement ou indirectement dans le lot de {particules} d'un groupe modèle ont comme {terme} des déclarations d'éléments de même nom, les définitions de types de ces déclarations doivent être les mêmes. Par 'indirectement', on entend les particules d'un lot de {particules} d'un groupe qui serait lui-même le {terme} d'une particule directement contenue dans un autre groupe, et ainsi de suite récursivement.

Reportez-vous au chapitre Annotations (§3.13) pour avoir les informations détaillées sur le rôle des {annotations}.

3.9 Les particules

Comme cela fut décrit dans le chapitre Groupes modèles (§3.8), les particules contribuent à la définition des modèles de contenu.

<xs:element ref="egg" minOccurs="12" maxOccurs="12"/>

<xs:group ref="omelette" minOccurs="0"/>

<xs:any maxOccurs="unbounded"/>
     

3.9.1 Le composant de schéma de type particule

Le composant de schéma de type particule a les propriétés suivantes :

En général, plusieurs unité d'information de type élément [enfants], potentiellement avec des caractères de données entre les [enfants] pour le cas des modèles mixed, peuvent être ·validées· par rapport à une seule particule. Quand le {terme} est une déclaration d'élément ou un caractère générique, le {nombre d'occurrences minimum} détermine le nombre minimum de fois qu'un tel élément [enfant] peut apparaître. Le nombre de ces enfants doit être plus grand que ou égal au {nombre d'occurrences minimum}. Si le {nombre d'occurrences minimum} vaut 0, alors l'apparition d'une occurrence de cet enfant est facultative.

A nouveau, quand le {terme} est une déclaration d'élément ou un caractère générique, le nombre d'apparition de cet élément [enfant] doit être inférieur à ou égal à toute spécification numérique du {nombre d'occurrences maximum} ; si la valeur de {nombre d'occurrences maximum} est unbounded, alors il n'y a pas de limite supérieures au nombre de fois que l'enfant peut apparaître.

Quand le {terme} est un groupe modèle, le nombre des occurrences permises est déterminé par une combinaison du {nombre d'occurrences minimum} et du {nombre d'occurrences maximum} et celles de l'ensemble des {particules} du {terme}.