Ce document est une traduction de la recommandation XML Schema du W3C, datée du 2 mai 2001. Cette version traduite peut contenir des erreurs absentes de l'original, introduites par la traduction elle-même. La version originelle en anglais, seule normative, se trouve à l'adresse http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/.

Traduction :

Copyright © 1998 W3C (MIT, INRIA, Keio), tous droits réservés. Les règles du W3C sur la responsabilité, les marques commerciales, les droits des auteurs et les licences des logiciels sont applicables.

Remarque de la traduction: L'entité caractère nécessaire au "oe" ligaturé n'étant pas supportée par certains navigateurs, ce caractère sera écrit oe.



 
W3C

XML Schema tome 1 : Structures

Recommandation du W3C du 2 mai 2001

Cette version :
http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
(en XML (avec sa propre DTD et feuille de style XSL) et HTML), avec fourniture séparée du schema et de la DTD des schémas qui y sont décrits.
Dernière version :
http://www.w3.org/TR/xmlschema-1/
Version précédente :
http://www.w3.org/TR/2001/PR-xmlschema-1-20010330/
Editeurs:
Henry S. Thompson (University of Edinburgh) mailto:ht@cogsci.ed.ac.uk
David Beech (Oracle Corporation) mailto:David.Beech@oracle.com
Murray Maloney (for Commerce One) mailto:murray@muzmo.com
Noah Mendelsohn (Lotus Development Corporation) mailto:Noah_Mendelsohn@lotus.com

Résumé

XML Schema tome 1 : Structures est la spécification du langage de définition de XML Schema, qui offre les fonctions pour spécifier les structures et les contraintes de contenu de documents XML 1.0, y compris ceux qui font usage des espaces de noms de XML. Le langage des Composant de schéma i-même écrit en XML 1.0 et utilise des espaces de noms, est une réécriture significative et une extension considérable des possibilités fonctionnelles des DTD de XML 1.0. Cette spécification est directement liée à XML Schema tome 2 : Types de données.

Statut de ce document

Cette section décrit le statut de ce document au moment de sa publication. D'autres documents, plus récents, peuvent supplanter ce document. Le W3C en gère la liste des mises à jour.

Ce document a été contrôlé par des personnes concernées par le sujet, membres du W3C ou autre, et a été validé par le directeur du W3C en tant que recommandation. Il s'agit donc d'un document stable qui peut être utilisé comme document de référence. Le statut de "Recommandation du W3C" sert à attirer l'attention sur la spécification et à en promouvoir largement le déploiement ; cela dans le but d'améliorer le fonctionnement et l'interopérabilité du Web.

Ce document a été produit par le groupe de travail du W3C sur XML Schema dans le cadre général de l'activité XML du W3C. Les objectifs du langage XML Schema sont présentés dans les spécifications de XML Schema. Les auteurs de ce document sont les membres du groupe de travail sur XML Schema et les 3 tomes de cette recommandation ont chacun leurs propres éditeurs.

Cette version intègre les remarques correctives faites sur les versions antérieures.

Vous voudrez bien faire remonter les erreurs trouvées dans ce document à www-xml-schema-comments@w3.org (archive) (note de la traduction : ou directement à la traduction française mentionnée en début de document). Une liste des erreurs connues de la version anglaise de cette spécification est disponible à l'adresse http://www.w3.org/2001/05/xmlschema-errata.

La seule version normative du présent document est l'anglaise. Des informations concernant ses traductions sont disponibles à l'adresse http://www.w3.org/2001/05/xmlschema-translations.

Une liste complète des recommandations actuelles du W3C et d'autres documents techniques est disponible à l'adresse http://www.w3.org/TR/.

Table of contents

1 Introduction
1.1 But
2 Structure conceptuelle
3 Descriptions détaillées des composants de schéma
4 Schémas et espaces de noms : accès et assemblage
5 L'évaluation de la validité des schémas

Annexes

A Le schéma des schémas (partie normative)
B Références bibliographiques (partie normative)
C Récapitulatif des données produites par l'évaluation (partie normative)
D Unités et propriétés obligatoires des ensembles d'information (partie normative)
E Graphe des composants d'un schéma (partie non-normative)
F Glossaire (partie non-normative)
G La DTD des schémas (partie non-normative)
H Analyse de la contrainte d'attribution de particule unique (partie non-normative)
I Références (partie non-normative)
J Remerciements (partie non-normative)

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].

next sub-section 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.

previous sub-section next sub-section 1.2 Dépendances avec d'autres Spécifications

La définition de XML Schema tome 1 : Structures dépend des spécifications suivantes : [XML-Infoset], [XML-Namespaces], [XPath] et [XML Schema tome 2 : Types de données].

Reportez-vous à l'annexe normative Eléments et propriétés requis des ensembles d'information (§D) pour avoir une liste récapitulative des unités d'information et propriétés de [XML-Infoset] exigées comme pré-requises par la présente recommandation pour les programmes validant.

previous sub-section 1.3 Terminologie et conventions d'écriture

Ce chapitre présente la typographie et les mises en valeur utilisées dans ce document.

Les termes spéciaux sont définis dès leur introduction dans le texte par le mot "Définition" écrit entre crochets. Par exemple [Définition :]  un terme est quelque chose utilisé avec une signification particulière. Le mot "Définition" est explicitement mentionné et le terme défini est écrit en gras. La fin de la définition n'est pas particulièrement indiquée dans le texte, qu'il soit affiché ou imprimé. Les termes officiels utilisés dans le texte sont encadrés par des points en début et fin de terme et renvoient à leurs définitions, par exemple : ·terme·.

Les exemples non-normatifs sont encadrés et accompagnés d'une petite explication :

Exemple
<schema targetNamespace="http://www.example.com/XMLSchema/1.0/mySchema">
Suivi d'une explication de l'exemple.

La définition de chaque sorte de composant de schéma est constitué de sa liste de propriétés et types de contenus possibles ; les propriétés sont suivies de la description de leur sémantique :

Composant de schéma : Exemple
{exemple de propriété}
Définition de la propriété.

Dans le corps de la recommandation, les références aux propriétés des composants de schéma, repérables grâce aux accolades qui les encadrent, sont des liens qui conduisent à leur définition, par exemple {exemple de propriété}.

La correspondance entre une unité d'information de type élément (par exemple, ce cas n'est qu'un des aspects de la représentation XML d'un schéma) et un ou plusieurs composants de schéma est présentée sous forme de tableaux. Cela est suivi d'un récapitulatif des correspondances entre les propriétés du composant et celles de l'élément d'information. Quand il y a plusieurs possibilités de composants et que le choix de l'un d'eux est déterminé par son contexte d'utilisation, nous présentons un tableau récapitulatif par contexte. Les correspondances des propriétés que nous spécifions sont normatives, comme le sont les illustrations de la représentation XML des unités d'information de type élément.

Dans la représentation XML, les noms d'attributs en gras (par exemple count dans l'encadré ci-dessous) indique qu'il est obligatoire, les autres étant optionnels. Quand la définition de la valeur d'une unité d'information de type attribut est du type énumération, les valeurs autorisées sont écrites les unes derrières les autres, séparées par le caractère barre verticale (voir l'exemple de l'attribut size ci-après) ; si l'un de ces valeurs est la valeur par défaut, elle est reprise après le caractère "deux points" (exemple du mot medium ci-dessous) . Quand une unité d'information de type attribut a une définition de type simple préfabriqué dans [XML Schema tome 2 : types de données], un hyperlien à sa définition est fourni.

Le contenu autorisé d'un élément d'information est montré sous la forme d'un fragment de grammaire, en utilisant les opérateurs de Kleene ?, * et +. Chaque nom d'élément alors présent est un lien à sa propre illustration.

Remarque : Les illustrations sont dérivées automatiquement du schéma des schémas (partie normative) (§A). Dans le cas d'un conflit apparent, le schéma des schémas (partie normative) (§A) fait foi, dans ce sens que, avec les ·contraintes de représentation des schémas·, il fournit l'expression normative de la forme de la représentation XML.
Vue synthétique de la représentation XML : unité d'information de type élément example 

<example
  count = integer
  size = (large | medium | small) : medium>
  Content: (all | any*)
</example>

Composant de schéma example
Propriété Représentation
{exemple de propriété} Description de ce à quoi correspond la propriété, par exemple la valeur de [l'attribut] size

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 :

Apports de la validation de schémas dans l'ensemble d'information par l'unité d'information example
[nouvelle propriété]
La valeur que prend la propriété.

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)).

next sub-section 2.1 Aperçu de XML Schema

Un schéma XML consiste en des composants qui sont par exemple des définitions de types et des déclarations d'éléments. Celles-là peuvent à leur tour être utilisées pour contrôler la validité des unités d'information de type élément et attribut à condition qu'elles soient bien formées (tel que défini dans le dictionnaire terminologique de XML [XML-Infoset]) et pour spécifier des compléments d'information sur ces unités et leurs descendants. Ces compléments d'information prennent la forme d'informations explicitement écrites là où elles étaient implicites dans le document original. Il s'agit par exemple des informations de normalisation, de valeurs par défaut des attributs et des éléments et des définitions de type des unités d'information de type élément et attribut.

L'évaluation de la validité du schéma a deux aspects :

1 la validité locale qui consiste à savoir si une unité d'information de type élément ou attribut est conforme par rapport aux contraintes exprimées dans les composants correspondant du schéma XML ;
2 la validation globale de l'unité, synthèse qui combine la validité locale avec les évaluations de validité des descendants, quand il y en a, et qui ajoute à l'ensemble des informations les compléments appropriés.

Tout au long de cette spécification, [Définition:]  le mot valide et ses formes dérivées font référence à la clause 1 ci-dessus, la résolution de la validité locale par rapport au schéma.

Tout au long de cette spécification, [Définition :]   le mot évaluation fait référence à la totalité du processus de validation locale, l'évaluation de la validité de schéma et les rajouts à l'ensemble d'information.

previous sub-section next sub-section 2.2 Modèle de données abstrait de XML Schema

Cette spécification repose sur [XML 1.0 (Second Edition)] et [XML-Namespaces]. Les concepts et les définitions en rapport avec XML utilisés ci-après sont encadrés au niveau abstrait par des unités d'information comme cela est défini dans [XML-Infoset]. Par définition, cette utilisation de l'ensemble d'information fournit a priori des garanties sur la qualité de la forme (telle que définie dans [XML 1.0 (Second Edition)]) et sur la conformité de l'espace de noms (telle que définie dans [XML-Namespaces]) pour tous les candidats à ·l'évaluation· et pour tous les ·documents de type schéma·.

De la même manière que [XML 1.0 (Second Edition)] et [XML-Namespaces] peuvent être décrits en terme d'unités d'information, XML Schemas peut être décrit en terme de modèle de données abstrait. Ce faisant, cette spécification définit rigoureusement les informations qui doivent être à la disposition de tout programme de traitement de XML Schema se disant conforme. Le modèle abstrait des schémas est seulement conceptuel et ne présage d'aucune implémentation physique ou représentation particulière. Pour faciliter l'interopérabilité et le partage des données de type schéma, un format d'échange normatif en XML est fourni.

[Définition :]   Composant de schéma est le terme générique utilisé pour désigner les blocs de construction qui constituent le modèle de données abstrait du schéma. [Définition :]   Un schéma XML est un ensemble de ·composants de schéma·. Il y a au total 13 sortes de composants répartis en trois groupes. Les composants principaux, qui peuvent (cas des définitions de types) ou doivent (cas des déclarations d'éléments et d'attributs) avoir des noms, sont ceux-ci :

Les composants secondaires, qui doivent avoir des noms, sont :

Finalement, les composants "assistant" fournissent de petites parties d'autres composants ; ils ne sont pas indépendants de leur contexte :

Durant la ·validation·, [Définition :] les composants de type déclaration sont associés aux unités d'information en train d'être ·validées· par un nom (qualifié).

D'un autre côté, [Définition :] les composants de définition définissent des composants internes de type schéma qui peuvent être utilisés dans d'autres composants.

[Définition :]  Les déclarations et les définitions peuvent avoir et être identifiées par des noms de type NCName conformes à la spécification [XML-Namespaces].

[Définition :]  Plusieurs sortes de composants ont un espace de noms cible qui est soit ·absent· soit un nom d'espace de noms, également défini dans [XML-Namespaces]. ·L'espace de nom cible· sert à identifier l'espace de noms à l'intérieur duquel l'association entre le composant et son nom existe. Dans le cas de déclarations, cela, à son tour, détermine le nom de l'espace de noms des unités d'information de type élément (par exemple) qu'il peut ·valider·.

Remarque : au niveau abstrait, il n'y a aucune obligation à ce que les composants d'un schéma partagent le même ·espace de noms cible·. Tout schéma utilisé dans ·l'évaluation· de documents qui contiendraient des noms provenant de plusieurs espaces de noms inclura nécessairement des composants ayant différents ·espaces de noms cibles·. Cela contraste avec ce qui se passe avec la représentation XML des composants dans laquelle les définitions et les déclarations apportées par tous les fragments de documents de type schéma participent à la constitution d'un seul et même espace de noms cible.

La ·Validation·, définie en détail au chapitre Descriptions détaillées des composants de schéma (§3), est une relation entre des unités d'information et des composants de schéma. Par exemple, une unité d'information de type attribut peut se ·valider· par rapport à la déclaration d'attribut qui lui correspond, une liste d'unités d'information de type élément peut se ·valider· par rapport au modèle de contenu qui lui correspond, etc. Les chapitres suivants introduisent brièvement les différentes sortes de composants du modèle de données abstrait, ainsi que d'autres fonctions principales du modèle abstrait et la manière avec laquelle ils contribuent à la ·validation·.

2.2.1 Composants de définition des types

Le modèle abstrait fournit deux sortes de composants de définition des types : un pour le type simple et l'autre pour le type complexe.

[Définition :]  Cette spécification utilise la phrase définition de types pour les cas où il n'y a pas de distinction à faire entre les types simples et les types complexes.

Les définitions de types forment en final une hiérarchie n'ayant qu'une seule racine. Les sous-chapitres ci-dessous tout d'abord décrivent les caractéristiques de cette hiérarchie et ensuite fournissent une introduction aux définitions des types simples et complexes eux-mêmes.

2.2.1.1 Hiérarchie des définitions de types

[Définition :]  La ·définition du type ur· étant un cas particulier mis à part, toute ·définition de type· est , par construction, soit une ·restriction· soit une ·extension· d'une autre définition de type. Le graphe de ces relations forme un arbre connu sous le nom de hiérarchie des définitions de types.

[Définition :]  Une définition de type dont les déclarations ou les facettes sont dans une relation biunivoque avec celles d'une autre définition de type, chacune des déclarations ou facettes de la première restreignant tour à tour leur homologue de l'autre définition, est appelée restriction. Les restrictions peuvent, par exemple, se concrétiser par la réduction d'une gamme de valeurs ou une réduction des choix possibles. Les membres d'un type restreint (A) par rapport à un type (B) sont toujours des membres valides du type B.

[Définition :]  La définition d'un type complexe A qui permet d'avoir des contenus d'élément ou d'attribut en plus de ceux autorisés par un autre type spécifié est une extension.

[Définition :]  La définition du type ur est présente dans chaque ·schéma XML·, elle est la racine de la hiérarchie des définitions de types de ce schéma. La définition du type ur, dont le nom est anyType, a comme seule caractéristique qu'elle peut agir aussi bien comme définition de types simples que de types complexes, d'après le contexte. Plus précisément, les ·restrictions· de la définition de type ur peuvent elles-mêmes être des définitions de type simple ou complexe.

[Définition :]  Une définition de type utilisée comme base d'une ·extension· ou d'une ·restriction· est connue sous le nom de définition du type de base de cette définition.

2.2.1.2 Définition du type simple

La définition d'un type simple A est un ensemble d'une part de contraintes mises sur les chaînes de caractères et d'autre part d'informations sur les valeurs qu'elles représentent, applicable à la ·valeur normalisée· d'une unité d'information de type attribut ou élément (à condition que l'élément n'ait pas d'élément enfant). De manière informelle, cela veut dire qu'un type simple ne s'applique qu'à des valeurs d'attributs et au contenu textuel d'éléments.

Chaque définition de type simple, qu'elle soit préfabriquée (c'est à dire, définie dans [XML Schema tome 2 : Types de données]) ou qu'elle soit définie par l'utilisateur, est une ·restriction· de la ·définition d'un type de base· simple. Pour les types primitifs préfabriqués, il s'agit de la version simple de la ·définition du type ur·, dont le nom est anySimpleType. Celui-là, à son tour, est également considéré comme étant une restriction de la ·définition du type ur·. Un type simple peut très bien être constitué de membres étant des listes d'unités elles-mêmes contraintes par d'éventuelles autres définitions de types simples ou de membres définis comme étant le résultat de l'union des ensembles de membres d'autres définitions de types simples. Les définitions des types simples qui sont des listes et des unions sont aussi considérées comme étant des restrictions de ·la définition du type simple ur·.

Pour avoir des informations détaillées sur les définitions de types simples, nous vous renvoyons au chapitre Définitions des types simples (§3.14) et à [XML Schema tome 2 : Types de données]. La dernière référence définit aussi un large inventaire de types simples préfabriqués.

2.2.1.3 Définition des types complexes

La définition d'un type complexe est un ensemble composé de déclarations d'attributs et d'un type de contenu, applicable respectivement aux [attributs] et aux [enfants] d'une unité d'information de type élément. Le type de contenu peut spécifier que les [enfants] ne contiennent ni unité d'information de type élément ni caractère (cela signifie qu'ils sont vides), ou que leur contenu est une chaîne de caractères d'un type simple particulier ou encore qu'il est constitué d'une séquence d'unités d'information de type élément conforme à un groupe modèle particulier, cela avec ou sans unité d'information de type caractère.

Chaque définition de type complexe est soit

soit

soit

L'extension d'un type complexe est obtenue soit en rajoutant des particules de modèle de contenu à la fin des définitions du modèle de contenu du type d'origine soit en rajoutant des déclarations d'attributs soit les deux.

Remarque : Cette spécification limite l'extension au seul rajout de définitions à la fin de la définition de type d'origine. Cette décision simplifie grandement le développement des applications qui doivent développer les types dérivés des types de base. Il se pourrait que des versions futures de la spécification autorisent d'autres formes d'extensions, nécessitant alors de la part des programmes des transformations plus complexes pour calculer ces types dérivés.

Pour avoir des informations détaillées sur la définition de types complexes, nous vous renvoyons au chapitre Définitions des types complexes (§3.4).

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.

2.2.2.1 Déclaration d'élément

Une déclaration d'élément est l'association d'un nom avec : la définition d'un type (simple ou complexe), une valeur par défaut (qui est optionnelle) et un ensemble (qui peut être vide) de définitions de contrainte d'identité. L'association est soit de portée globale soit limitée au champ d'application de la définition de type complexe qui la contient. Une déclaration supérieure d'élément ayant le nom 'A' est largement comparable à la paire de déclarations (<!ELEMENT et <!ATTLIST) connue avec les DTD comme dans l'exemple ci-après, où les définitions des types associés au nom A se trouvent à la place des trois points :

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

Les déclarations d'éléments participent à la ·validation· en tant qu'élément de référence servant à ·valider· un groupe modèle quand leurs composants de type et leurs valeurs par défaut sont contrôlés par rapport à une unité d'information de type élément dont le nom et l'espace de noms correspondent et quand est déclenchée la ·validation· de la définition de la contrainte d'identité.

Pour de plus amples informations sur les déclarations d'éléments, reportez-vous au chapitre Déclaration d'élément (§3.3).

2.2.2.2 Groupe de substitution d'éléments

En XML 1.0, le nom et le contenu d'un élément doit correspondre à l'élément type référencé dans le modèle de contenu correspondant.

[Définition :]  Au travers du nouveau mécanisme des groupes de substitution d'élément, XML Schema fournit un modèle plus puissant supportant la substitution d'un élément nommé par un autre. Toute déclaration supérieure d'élément peut servir d'élément définissant, ou tête, d'un groupe de substitution d'éléments. D'autres déclarations supérieures d'éléments, indépendamment de l'espace de noms cible, peuvent faire partie du groupe de substitution dont le chef de file est cet élément. Dans un modèle de contenu qui y est autorisé, une référence au chef de file ne limite pas la ·validation· à ce seul élément mais l'étend à tous les éléments qui ont un homologue dans le groupe de substitution.

Tous les membres dans ce cas doivent avoir des définitions de types qui sont soit les mêmes que la définition de type de l'élément chef de file ou qui en sont soit des restrictions soit des extensions. Par conséquent, bien que les noms des éléments puissent varier considérablement au fur et à mesure que de nouveaux espaces de noms et membres du groupe de substitution sont définis, le contenu des éléments membres est strictement limité d'après la définition de type de l'élément chef de file du groupe de substitution.

Remarquez que les groupes de substitution d'éléments ne sont pas représentés comme étant des composants séparés. Ils sont spécifiés par le biais de la valeur d'une des propriété des déclarations d'éléments (reportez-vous au chapitre Déclaration d'élément (§3.3)).

2.2.2.3 Déclaration d'attribut

Une déclaration d'attribut est une association entre un nom et une définition de type simple, complétée d'une information d'occurrence et (optionnellement) d'une valeur par défaut. L'association est soit globale soit locale à la définition de type complexe qui la chapeaute. Les déclarations d'attributs participent à la ·validation· en tant qu'élément de référence servant à ·valider· la définition d'un type complexe, quand leur occurrence, valeurs par défaut et composants de type sont contrôlés par rapport à une unité d'information de type attribut dont le nom et l'espace de noms correspondent.

Pour avoir des informations détaillées sur ces déclarations d'attributs, référez-vous au chapitre Déclarations d'attributs (§3.2).

2.2.2.4 Déclaration de notation

Une déclaration de notation est une association entre un nom et un identifiant de notation. Pour qu'une unité d'information de type attribut soit ·valide· par rapport à une définition de type simple de NOTATION, la déclaration de sa valeur doit avoir été initialement associée à une déclaration de notation.

Pour avoir des informations détaillées sur les déclarations de notations, reportez-vous au chapitre Déclarations des notations (§3.12).

2.2.3 Composants d'un groupe modèle

Les composants d'un groupe modèle, d'une particule et d'un caractère générique participent d'une certaine façon à la partie de la définition d'un type complexe qui concerne le contrôle du contenu d'une unité d'information de type élément.

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 :

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.4 Composants de définition de contrainte d'identité

Une définition de contrainte d'identité est une association entre un nom et une ou plusieurs variétés de contraintes d'identités en rapport avec l'unicité et le référencement. Toutes les variétés utilisent des expressions [XPath] pour cibler les unités d'information concernées par les contraintes spécifiques et qui doivent être uniques, former une clé ou être une référence ·valide· à l'intérieur d'un espace spécifié. Une unité d'information de type élément est ·valide· par rapport à une déclaration d'élément ayant de telles contraintes d'identité si et seulement si elles sont satisfaites pour tous les descendants de l'unité d'information élément visés par les contraintes.

Pour avoir des informations détaillées sur les définitions de contrainte d'identité, reportez-vous au chapitre Définitions de la contrainte d'identité (§3.11).

2.2.5 Composants de définition d'un groupe

Il y a deux sortes de définitions qui sont pratiques pour permettre la réutilisation de parties de définitions de types complexes : les définitions de groupes modèles et les définitions de groupes d'attributs.

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.2.6 Composants de type annotation

Une annotation est une information qui peut être exploitée tout aussi bien par des humains que par un mécanisme mécanique. Mais l'interprétation de ce type d'information n'est pas définie dans cette spécification.

Pour avoir des informations détaillées sur les annotations, reportez-vous au chapitre annotations (§3.13).

previous sub-section next sub-section 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.

previous sub-section next sub-section 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é.

previous sub-section next sub-section 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.

previous sub-section next sub-section 2.6 Balisage relatif au schéma des documents étant validés

2.6.1 xsi:type
2.6.2 xsi:nil

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.6.2 xsi:nil

XML Schema tome1 : Structures introduit un mécanisme permettant d'indiquer explicitement si un élément doit être accepté comme ·valide· quand il est vide même si cela n'est pas exigé par son type ou même se contente de l'autoriser. Un élément peut être ·valide· tout en n'ayant pas de contenu à condition qu'il soit porteur de l'attribut xsi:nil ayant la valeur vrai. Un élément ainsi labellisé doit être vide mais peut être porteur d'attributs si cela est permis par le type complexe qui lui est associé.

2.6.3 xsi:schemaLocation, xsi:noNamespaceSchemaLocation

Les attributs xsi:schemaLocation et xsi:noNamespaceSchemaLocation peuvent être utilisés dans un document pour fournir des indications concernant l'emplacement physique des documents contenant les schémas susceptibles d'être utilisés à l'occasion d'une ·évaluation·. Reportez-vous au chapitre Comment sont localisées les définitions de schéma sur le Web (§4.3.2) pour connaître les détails quant à l'utilisation de ces attributs.

previous sub-section 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

next sub-section 3.1 Introduction

Les chapitres qui suivent fournissent tous les détails quant à l'assemblage de tous les composants de schéma, avec leur représentation XML et leurs contributions à ·l'évaluation·. Chaque chapitre est dévolu à un seul composant, au travers de différents sous-chapitres qui sont :

  1. Les propriétés : valeurs et signification
  2. La représentation XML et les correspondances avec les propriétés
  3. Les contraintes de représentation
  4. Les règles de validation
  5. Les contributions à l'ensemble d'information résultant de la validation de schéma
  6. Les contraintes sur les composants eux-mêmes

Les sous-chapitres immédiatement ci-dessous introduisent les conventions et la terminologie utilisée tout au long des chapitres sur les composants.

3.1.1 Composants et Propriétés

Les composants sont définis au travers de leurs propriétés dont chacune est à son tour définie en donnant la fourchette de valeurs qu'elle peut prendre. Cela peut être compris comme définissant un schéma comme étant un arbre d'objets étiquetés où la racine est un composant schema, les sommets sont soit un composant de schéma soit un littéral (chaîne de caractères, booléen, nombre) et où chaque branche étiquetée est une propriété. Le graphe n'est pas acyclique : aucune copie d'un composant ayant le même nom et se trouvant dans le même ·espace de symboles· ne peut exister, ce qui impose d'avoir parfois des chaînes de propriétés ré-entrantes. L'égalité des composants pour les besoins de cette spécification est toujours définie comme étant l'égalité des noms (y compris les espaces de noms cibles) à l'intérieur des espaces symboles.

Remarque : Un schéma et ses composants tels que définis dans ce chapitre sont une forme idéalisée de l'information nécessaire à un programme validant : les mises en application n'ont aucune obligation particulière quant à la manière de les fournir. En particulier, aucune implication particulière entre l'inclusion littérale versus l'indirection ne découle de l'utilisation d'un langage tel que "des propriétés . . . ayant . . . des composants comme valeurs".

[Définition :]  Tout au long de cette spécification, le terme absent est utilisé comme étant une valeur de propriété distincte pour dénoter l'absence d'utilisation de cette propriété.

Toute propriété qui ne serait pas identifiée comme optionnelle est obligatoirement présente ; les propriétés facultatives qui ne sont pas présentes sont sensées être ·absentes·. Toute propriété identifiée comme ayant un ensemble, un sous-ensemble ou une liste de valeurs peut avoir une valeur vide sauf si cela est explicitement exclu : cela n'est pas la même chose que d'être ·absent·. Toute valeur de propriété identifiée comme sur-ensemble ou sous-ensemble d'un ensemble quelconque peut être égale à cet ensemble, sauf si un sur-ensemble ou un sous-ensemble propre est explicitement demandé. Dans cette spécification, on entend par 'string' une séquence de caractères ISO 10646 reconnus comme Caractères XML légaux dans [XML 1.0 (Second Edition)].

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.1.3 La correspondance entre les représentations XML et les composants

A chaque sorte de composant de schéma correspond une représentation normative XML. Les chapitres ci-dessous décrivent les correspondances entre les propriétés de chaque sorte de composant de schéma d'un côté et les propriétés des unités d'information de la représentation XML de l'autre, avec des contraintes propres à cette représentation et qui viennent se rajouter à celles du Schéma des schémas (partie normative) (§A).

La forme utilisée pour représenter les correspondances est une relation qui part d'une représentation XML pour aller à un composant de schéma, et le chemin inverse, celui des correspondances à partir du modèle abstrait, peut être construit à partir de là.

En discutant des représentations XML vers les composants de schéma ci-dessous, la valeur de la propriété d'un composant est souvent déterminée par la valeur d'une unité d'information de type attribut qui est elle-même l'un des [attributs] d'une unité d'information de type élément. Puisque les documents de type schéma sont contraints par le Schéma des schémas (§A), il y a toujours une définition de type simple associée à tout élément d'information de type attribut. [Définition :]  La phrase valeur réelle est utilisée pour faire référence au membre de l'espace de valeur de la définition de type simple associée à une unité d'information de type attribut qui correspond à sa ·valeur normalisée·. Cela sera souvent une chaîne de caractères, mais peut tout aussi bien être un entier, un booléen, une référence d'URI, etc. Ce terme est aussi occasionnellement utilisé pour ce qui concerne des unités d'information de type élément ou attribut d'un document en cours de ·validation·.

Beaucoup de propriétés ci-après sont susceptibles d'avoir des valeurs contenant d'autres composants de schéma ou des ensembles de composants. Pour les besoins de la clarté du texte, les définitions de ce chapitre supposent que (à moins que la propriété ne soit explicitement identifiée comme facultative) toutes ces possibilités de valeurs sont effectivement présentes. Quand les composants de schéma sont construits à partir de représentations XML qui impliquent une référence par un nom à d'autres composants, la supposition faite ci-dessus peut être violée si une ou plusieurs références ne peuvent pas être ramenées. Cette spécification adresse de manière uniforme la question des composants manquant au chapitre Sous-composants manquant (§5.3) : aucune mention relative à la manière de gérer le cas des composants manquant ne sera trouvée dans les descriptions individuelles des composants ci-après.

Une référence en avant vers des définitions nommées et des déclarations est autorisée, cela se faisant à l'intérieur ou entre des ·documents de type schéma·. Avant que le composant correspondant à la représentation XML contenant une référence en avant soit réellement nécessaire à la ·validation·, un composant de nom approprié peut avoir été rendu disponible pour décharger la référence : reportez-vous au chapitre sur les Schémas et les espaces de noms : accès et assemblage (§4) pour les détails.

3.1.4 Normalisation des espaces blancs pendant la validation

Tout au long de cette spécification, [Définition :]  la valeur initiale d'une unité d'information de type attribut est la valeur de la [valeur normalisée] de la propriété de cette unité. De manière similaire, la valeur initiale d'une unité d'information de type élément est la chaîne de caractères composée, dans l'ordre, du [code du caractère] de chaque unité d'information de type caractère des [enfants] de cette unité d'information de type élément.

La définition ci-dessus signifie que les commentaires et les instructions de traitement, même au milieu du texte, sont ignorées dans tous les cas de ·validation·.

[Définition :]  La valeur normalisée d'une unité d'information de type attribut ou élément est une ·valeur initiale· dans laquelle l'espace blanc, si il existe, a été normalisé d'après la valeur de la facette whiteSpace de la définition du type simple utilisé dans sa ·validation· :

preserve
Aucune normalisation n'est faite, la valeur est la ·valeur normalisée·
replace
Toutes les occurrences de #x9 (tabulation), #xA (début de ligne) et #xD (retour chariot) sont remplacées par le code #x20 (espace).
collapse
En plus des remplacements spécifiés ci-dessus dans le cas replace, les séquences contiguës de #x20 sont ramenées à un seul #x20, et les espaces initiaux et finaux sont détruits.

Il y a trois règles de validation alternatives qui peuvent fournir un complément nécessaire à ce qui vient d'être écrit, il s'agit des clauses : Attribut localement valide (§3.2.4) (clause 3), Elément localement valide (type) (§3.3.4) (clause 3.1.3) et Elément localement valide (type complexe) (§3.4.4) (clause 2.2).

Ces trois niveaux de normalisation correspondent aux traitements respectifs de XML 1.0 pour les contenus d'éléments, les contenus d'attributs de type CDATA et les contenus d'attributs composés d'unités lexicales. Reportez-vous au chapitre Normalisation des valeurs d'attributs dans [XML 1.0 (Second Edition)] pour y retrouver les cas replace et collapse pour les attributs. Etendre ces cas au contenu des éléments est nécessaire pour garantir une ·validation· uniforme de la sémantique des types simples, qu'ils soient utilisés pour des valeurs d'attributs comme pour des valeurs de contenu d'éléments. Faire le traitement deux fois dans le cas des attributs dont la [valeur normalisée] a déjà été sujette au remplacement ou déjà compressée (cas collapse) sur la base de l'information présente dans la DTD est nécessaire pour garantir un traitement des attributs totalement indépendant de la capacité réelle ou supposée des outils de production de l'ensemble d'information à prendre en compte les informations fournies par la DTD.

Remarque : Même quand l'information provenant de la DTD a été strictement respectée et que la normalisation des valeurs d'attributs a été faite, la définition ci-dessus d'une ·valeur normalisée· ne change pas le fait que des normalisations supplémentaires soient nécessaires. C'est le cas par exemple quand des valeurs d'attributs contiennent des références d'entités caractères et que leur remplacement produit des caractères d'espaces blancs autres que ceux se trouvant dans la ·valeur initiale· de l'attribut.

previous sub-section next sub-section 3.2 Déclarations d'attributs

Les déclarations d'attributs servent à :

Exemple
<xs:attribute name="age" type="xs:positiveInteger" use="required"/>
Représentation XML d'une déclaration d'attribut.

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 :

Composant de schéma : Déclaration d'attribut
{nom}
Un NCName comme cela est défini dans [XML-Namespaces].
{espace de noms cible}
Soit cette propriété est ·absente· soit sa valeur est un nom d'espace de noms, tel que défini dans [XML-Namespaces].
{définition de type}
Une définition de type simple.
{portée}
Facultatif. Soit global ou une définition de type complexe.
{contrainte de valeur}
Facultatif. Une paire composée d'une valeur et soit default soit fixed.
{annotation}
Facultatif. Une annotation.

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.2.2 Représentation XML des composants de schéma pour les déclarations d'attributs

La représentation XML d'un composant de schéma pour une déclaration d'attribut est l'unité d'information de type élément <attribute> . Elle spécifie pour un attribut une définition de type simple soit par référence soit explicitement et peut fournir une information par défaut. Les correspondances entre la propriété de l'unité d'information et les propriétés du composant sont les suivantes :

Vue synthétique de la représentation XML : unité d'information de type élément attribute 

<attribute
  default = string
  fixed = string
  form = (qualified | unqualified)
  id = ID
  name = NCName
  ref = QName
  type = QName
  use = (optional | prohibited | required) : optional
  {tout attribut ayant un espace de noms différent de celui du schéma . . .}>
  Content: (annotation?, (simpleType?))
</attribute>

Si l'unité d'information de type élément <attribute> a <schema> comme parent, le composant de schéma correspondant est comme suit :
 Composant de schéma :Déclaration d'attribut
Propriété Représentation
{nom} La ·valeur réelle· de [l'attribut] name
{espace de noms cible} La ·valeur réelle· de [l'attribut] targetNamespace de l'unité d'information parent de type élément <schema>, cette propriété est ·absente· s'il n'y a pas cet attribut.
{définition de type} La définition du type simple correspondant à l'unité d'information [enfant] de type élément <simpleType>, si il existe, sinon la définition du type simple ·ramenée· par la ·valeur réelle· de [l'attribut] type, si il est présent, sinon la ·définition du type simple ur·.
{portée} global.
{contrainte de valeur} si il y a un [attribut] default ou fixed, alors cette propriété est une paire composée de la ·valeur réelle· (par rapport à la propriété {définition de type}) de cet [attribut] et l'une des deux valeurs default ou fixed, en fonction du cas, sinon cette propriété est ·absente·.
{annotation} L'annotation correspondant à l'unité d'information [enfant] de type élément <annotation>, si elle est présente, sinon cette propriété est ·absente·.
Sinon si l'unité d'information de type élément <attribute> a <complexType> ou <attributeGroup> comme ascendant et que [l'attribut] ref est absent, alors, ce cas correspond à l'utilisation de l'attribut ayant les propriétés suivantes (à moins que use='prohibited', auquel cas l'unité correspond à rien du tout) :
Composant de schéma : attribut utilisé
Propriété Représentation
{présence} true si [l'attribut] use est présent avec required comme ·valeur réelle·, sinon false.
{déclaration d'attribut} Reportez-vous aux correspondances des déclarations d'attributs immédiatement ci-après.
{contrainte de valeur} si il y a un [attribut] default ou fixed alors cette propriété est une paire composée de la ·valeur réelle· (par rapport à la {définition de type} de la {déclaration d'attribut}) de cet [attribut] et de l'une des deux valeurs default ou fixed, en fonction du cas de figure, sinon cette propriété est ·absente·.
Composant de schéma Déclaration d'attribut
Propriété Représentation
{nom} La ·valeur réelle· de [l'attribut] name
{espace de noms cible} Si form est présent et que sa ·valeur réelle· est qualified ou si form est absent mais que la ·valeur réelle· de l'attribut attributeFormDefault de l'ascendant <schema> est qualified, alors cette propriété est la ·valeur réelle· de [l'attribut] targetNamespace de l'unité d'information parent de type élément <schema> ou elle est ·absente· si il n'y en a pas ; elle est ·absente· dans tous les autres cas.
{définition de type} La définition de type simple correspondant à l'unité d'information [enfants] de type élément <simpleType>, quand il y en a, sinon la définition du type simple ·ramenée· par la ·valeur réelle· de [l'attribut] type si il est présent Sinon la valeur est ·définition du type simple ur·.
{portée} Si l'unité d'information de type élément <attribute> a <complexType> comme ascendant, alors cette propriété est la définition du type complexe correspondant à cette unité et, si ce n'est pas le cas (l'unité d'information de type élément <attribute> est à l'intérieur d'une définition <attributeGroup>), cette propriété est ·absente·.
{contrainte de valeur} ·absente·.
{annotation} Cette propriété est l'annotation correspondant à l'unité d'information [enfants] de type élément <annotation> si elle existe, sinon la propriété est ·absente·.
Sinon (l'unité d'information de type élément <attribute> a <complexType> ou <attributeGroup> comme ascendant et [l'attribut] ref est présent), il correspond à un attribut utilisé avec les propriétés suivantes (sauf si use='prohibé', auquel cas l'unité correspond à rien du tout) :
 Composant de schéma attribut utilisé
Propriété Représentation
{présence} true si [l'attribut] use est présent avec required comme ·valeur réelle·, sinon faux.
{déclaration d'attribut} la déclaration d'attribut (supérieur) ·ramenée· par la ·valeur réelle· de [l'attribut] ref
{contrainte de valeur} si il y a un [attribut] default ou fixed, alors cette propriété est une paire composée de la ·valeur réelle· (relativement à la {définition de type} de la {déclaration d'attribut}) de cet [attribut] et l'une des deux valeurs default ou fixed, en fonction du cas de figure, et sinon la propriété est ·absente·.

Les déclarations d'attributs peuvent apparaître au niveau supérieur d'un document de type schéma ou à l'intérieur d'une définition de types complexes, soit comme déclaration complète (locale), soit par référence aux déclarations supérieures, ou à l'intérieur de définitions de groupes d'attributs. Pour avoir des déclarations complètes, qu'elles soient locales ou supérieures, l'attribut type est utilisé quand la déclaration fait appel à la définition d'un type simple préfabriqué ou prédéclaré. Sinon un type anonyme <simpleType> est fourni en ligne.

L'option par défaut quand aucune définition de type simple n'est référencée ou fournie est l'utilisation de la simple ·définition du type ur· qui n'impose aucune contrainte du tout.

Les unités d'information de type attribut ·validées· par une déclaration supérieure doivent être qualifiées de {l'espace de noms cible} de cette déclaration (si celle-là est ·absente·, l'unité n'a pas à être qualifiée). Le contrôle pour savoir si les unités d'information de type attribut ·validées· par une déclaration locale doivent être qualifiées de manière similaire ou non dépend de [l'attribut] form dont la valeur par défaut est fournie par [l'attribut] attributeFormDefault de l'élément englobant <schema>, via sa détermination {d'espace de noms cible}.

Les noms des déclarations supérieures d'attributs ont leur propre ·espace de symboles·. Les noms des déclarations d'attributs de portée locale résident dans un espace de symboles local à la définition qui les contient.

3.2.3 Contraintes portant sur la représentation XML des déclarations d'attributs

Contraintes de représentation des schémas : Représentation correcte de la déclaration d'attribut
En plus des conditions imposées sur les unités d'information de type élément <attribute> par le schéma des schémas, toutes les conditions suivantes doivent être remplies :
1 default et fixed ne doivent pas être simultanément présents.
2 Si default et use sont tous les deux présents, use doit avoir optional comme ·valeur réelle·.
3 Si le parent de l'unité n'est pas <schema>, alors toutes les conditions suivantes doivent être remplies :
3.1 L'un des deux attributs ref ou name doit être présent, mais pas les deux à la fois.
3.2 Si ref est présent, alors aucun des <simpleType>, form et type ne doit être présent.
4 type et <simpleType> ne doivent pas être présents ensemble.
5 La déclaration d'attribut correspondant doit satisfaire aux conditions exposées au chapitre Contraintes portant sur le composant de schéma de déclaration d'attribut (§3.2.6).

3.2.4 Règles de validation d'une déclaration d'attribut

Règle de validation : attribut localement valide
Pour qu'une unité d'information de type attribut soit localement ·valide· toutes les conditions suivantes doivent être remplies :
1 La déclaration ne doit pas être ·absente· (référez-vous au chapitre Sous-composants manquant (§5.3) pour savoir quand cela cesse d'être le cas).
2 Sa {définition de type} ne doit pas être absente.
3 La ·valeur normalisée· de l'unité doit être localement ·valide· pour cette {définition de type} comme dans le chapitre Chaîne de caractère valide (§3.14.4).
4 La ·valeur réelle· de l'unité doit correspondre à la valeur de la {contrainte de valeur}, si elle est présente et qu'elle est fixed.
Règle de validation : évaluation de la validité de schéma (attribut)
L'évaluation de la validité de schéma d'une unité d'information de type attribut dépend de sa seule ·validation·.

[Définition :]  Pendant la ·validation·, des associations entre les unités d'information [enfants] de type attribut et élément et des [attributs] d'un côté et les déclarations d'attributs et d'éléments de l'autre sont établies comme un effet de bord. De telles déclarations sont appelées déclarations contextuelles. Reportez-vous à la clause 3.1 du chapitre Elément localement valide (type complexe) (§3.4.4) pour les déclarations d'attributs et à la clause 2 du chapitre Série d'éléments localement valide (Particule) (§3.9.4) pour les déclarations d'éléments.

Pour que la validité de schéma d'une unité d'information de type attribut soit évaluée, toutes les conditions suivantes doivent être remplies :

1 Une déclaration d'attribut effective (c'est à dire qui n'est pas ·absente·) doit être connue pour cette unité, plus précisément l'une de celles qui suivent :
1.1 Une déclaration qui a été établie comme étant sa ·déclaration contextuelle· ;
1.2 Une déclaration ramenée par son [nom local] et son [nom d'espace de noms] tel que cela est défini au chapitre Résolution des QName (instance) (§3.15.4), à condition que sa ·déclaration contextuelle· ne soit pas skip.
2 Sa ·validité· par rapport à cette déclaration doit avoir été évaluée comme pour un Attribut localement valide (§3.2.4).
3 Les deux clauses 1 et 2 d'un attribut localement valide (§3.2.4) doivent être satisfaites.

[Définition :]  En ce qui concerne les attributs, il n'y a aucune différence entre l'évaluation et la stricte évaluation, donc si ce qu'il y a ci-dessus est vérifié, l'unité d'information de type attribut est strictement évaluée.

3.2.5 Contributions des déclarations d'attributs à l'ensemble d'information

Contribution à l'ensemble d'information du schéma : résultat de l'évaluation (attribut)
Si la validité de schéma d'une unité d'information de type attribut a été évaluée comme cela est décrit au chapitre Evaluation de la validité de schéma (attribut) (§3.2.4), alors, dans l'ensemble d'information résultant de la validation de schéma, cette unité a les propriétés suivantes :
Contributions à l'ensemble d'information issu de la validité de schéma des unités d'information de type attribut
[contexte de validation]
L'ascendant le plus proche ou l'unité d'information de type élément ayant une propriété [information de schéma].
[validité]
Un des cas suivants :
1 Si elle était ·strictement évaluée·, alors un des cas suivants :
1.1 Si elle était ·valide· tel que cela est défini au chapitre Attribut localement valide (§3.2.4), alors la valeur est valid;
1.2 Sinon la valeur est invalid.
2 Sinon la valeur est notKnown.
[tentative de validation]
Un des cas suivants :
1 Si elle était ·strictement évaluée·, alors la valeur est full ;
2 Sinon la valeur est none.
[spécification de schéma]
infoset. Reportez-vous au chapitre Valeur d'attribut par défaut (§3.4.5) pour les autres valeurs possibles.
Contribution à l'ensemble d'information du schéma : Echec de la validation (attribut)
Si la ·validité· locale, telle que définie ci-dessus dans Attribut localement valide (§3.2.4), d'une unité d'information de type attribut a été évaluée, alors dans l'ensemble d'information résultant de la validation de schéma l'unité a la propriété suivante :
Contributions à l'ensemble d'information issu de la validité de schéma des unités d'information de type attribut
[schema error code]
Un des cas suivants :
1 Si l'unité n'est pas ·valide·, alors la valeur est une liste. Les applications espérant fournir des informations comme par exemple les causes identifiées de l'échec de ·validation· sont encouragées à produire un ou plusieurs codes d'erreur (référez-vous à l'annexe Tableaux des résultats (§C)) ci-joint.
2 Sinon cette contribution est ·absente·.
Contribution à l'ensemble d'information du schéma : Déclaration d'attribut
Si une unité d'information de type attribut est ·valide· par rapport à une déclaration d'attribut comme cela est décrit au chapitre Attribut localement valide (§3.2.4) alors dans l'ensemble d'information résultant de la validation de schéma l'unité d'information de type attribut peut, en fonction des options du programme de traitement, avoir la propriété suivante :
Contributions à l'ensemble d'information issu de la validité de schéma des unités d'information de type attribut
[déclaration d'attribut]
Une ·unité isomorphe· à la déclaration du composant lui-même.
Contribution à l'ensemble d'information du schéma : attribut validé par type
Si la clause 3 du chapitre Attribut localement valide (§3.2.4) s'applique à une unité d'information de type attribut, dans l'ensemble d'information résultant de la validation de schéma l'unité d'information de type attribut a la propriété suivante :
Contributions à l'ensemble d'information issu de la validité de schéma des unités d'information de type attribut
De plus, l'unité a l'un des d'ensembles de propriétés optionnels suivants :
Contributions à l'ensemble d'information issu de la validité de schéma des unités d'information de type attribut
[définition de type]
Une ·unité isomorphe· au composant de {définition de type} de la déclaration d'attribut qui lui correspond.
[définition de type de membre]
Si et seulement si cette définition de type a une {variante} de valeur union, alors sa valeur est une ·unité isomorphe· à ce membre de l'ensemble des {définitions de type de membre} qui ·validait· réellement la [valeur normalisée] de l'unité de type attribut.
ou
Contributions à l'ensemble d'information issu de la validité de schéma des unités d'information de type attribut
[type de la définition de type]
simple.
[espace de noms de la définition de type]
{l'espace de noms cible} de la ·définition de type·.
[anonymat de la définition de type]
true si le {nom} de la ·définition de type· est ·absent·, sinon la valeur est false.
[nom de la définition de type]
Le {nom} de la ·définition de type·, si il n'est pas ·absent·. Si il est ·absent·, les programmes validant peuvent, sans y être toutefois obligés, attribuer à la définition une valeur unique.
Si la {variante} de la ·définition de type· est union, alors [Définition :]  ce membre de l'ensemble des {définitions de types de membres} qui ·validait· réellement la ·valeur normalisée· de l'unité de type attribut est appelé la définition réelle de type de membre, il y a trois propriétés additionnelles :
Contributions à l'ensemble d'information issu de la validité de schéma pour des unités d'information de type attribut
La première option (·unité isomorphe·) ci-dessus est fournie pour les applications telles que des programmes d'interrogation qui ont besoin d'accéder à la totalité des détails concernant ·l'évaluation· d'une unité, comme par exemple l'accès à la hiérarchie des types ; la seconde option est destinée aux programmes plus légers pour lesquels la représentation détaillée de la hiérarchie des types pourrait s'avérer être une surcharge inutile.

Aussi, si la déclaration a une {contrainte de valeur}, l'unité aura la propriété suivante :

Contributions à l'ensemble d'information issu de la validité de schéma des unités d'information de type attribut
Si l'unité d'information de type attribut n'était pas ·strictement évaluée·, les valeurs ne seront pas celles spécifiées ci-dessus mais celles-là :
1 La valeur de la propriété [valeur normalisée par le schéma] de l'unité sera la ·valeur initiale· de l'unité ;
2 Les propriétés [définition de type] et [définition de type de membre], ou leurs alternatives, seront basées sur la ·définition du type simple ur·.

3.2.6 Contraintes des composants de schéma de déclarations d'attributs

Toutes les déclarations d'attributs (référez-vous au chapitre Déclarations d'attributs (§3.2)) doivent satisfaire les contraintes suivantes :

Contraintes des composants de schéma : propriétés correctes de déclarations d'attributs
Toutes les conditions suivantes doivent être remplies :
1 Les valeurs des propriétés d'une déclaration d'attribut doivent être telles que décrites dans le tableau de propriétés du chapitre Le composant de schéma de déclaration d'attributs (§3.2.1), modulo l'impact du chapitre Sous-composants manquant (§5.3).
2 Si il y a une {contrainte de valeur}, la représentation lexicale canonique de sa valeur doit être ·valide· en ce qui concerne la {définition de type} telle que définie au chapitre Chaînes de caractères valides (§3.14.4).
3 Si la {définition de type} est ou est dérivée de ID alors il ne doit pas y avoir de {contrainte de valeur}.
Contraintes des composants de schéma : Interdiction de xmlns
Le {nom} d'une déclaration d'attribut ne doit pas être xmlns.
Remarque : Le {nom} d'un attribut est du type ·NCName·, ce qui interdit implicitement les déclarations d'attributs de la forme xmlns:*.
Contraintes des composants de schéma : préfixe xsi: interdit
{l'espace de noms cible} d'une déclaration d'attribut, locale ou supérieure, ne doit pas être http://www.w3.org/2001/XMLSchema-instance (sauf si il s'agit de l'une des quatre déclarations préfabriquées données dans le prochain chapitre).
Remarque : Cela renforce le statut particulier de ces attributs qui, non seulement n'ont pas besoin d'être déclarés pour être autorisés dans les instances, mais de plus ne doivent pas être déclarés. Cela retire également toute tentation d'essayer de fournir des valeurs globales ou fixées comme par exemple xsi:type ou xsi:nil, ce qui serait sérieusement trompeur puisque ces valeurs n'auraient strictement aucun effet.

3.2.7 Déclarations d'attributs préfabriquées

Quatre déclarations d'attributs sont présentes, par définition, dans chaque schéma :

Déclaration d'attribut de l'attribut 'type'
Propriété Value
{nom} type
{espace de noms cible} http://www.w3.org/2001/XMLSchema-instance
{définition de type} La définition du type simple QName préfabriqué
{portée} global
{contrainte de valeur} ·absente·
{annotation} ·absente·
Déclaration d'attribut de l'attribut 'nil'
Propriété Value
{nom} nil
{espace de noms cible} http://www.w3.org/2001/XMLSchema-instance
{définition de type} La définition du type simple préfabriqué boolean
{portée} global
{contrainte de valeur} ·absente·
{annotation} ·absente·

Déclaration d'attribut de l'attribut schemaLocation
Propriété Value
{nom} schemaLocation
{espace de noms cible} http://www.w3.org/2001/XMLSchema-instance
{définition de type} Une définition de type simple anonyme, comme suit :
Propriété Value
{nom} ·absente·
{espace de noms cible} http://www.w3.org/2001/XMLSchema-instance
{définition du type de base} La ·définition du type simple ur· préfabriqué
{facettes} ·absente·
{variante} list
{définition du type unité} La définition du type simple préfabriqué anyURI
{annotation} ·absente·
{portée} global
{contrainte de valeur} ·absente·
{annotation} ·absente·

Déclaration d'attribut de l'attribut noNamespaceSchemaLocation
Propriété Value
{nom} noNamespaceSchemaLocation
{espace de noms cible} http://www.w3.org/2001/XMLSchema-instance
{définition de type} La définition du type simple préfabriqué anyURI
{portée} global
{contrainte de valeur} ·absente·
{annotation} ·absente·

previous sub-section next sub-section 3.3 Déclarations d'éléments

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

Exemple
<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>
Représentations XML de plusieurs déclarations d'élément différentes

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 :

Composant de schéma : déclaration d'élément
{nom}
Un NCName comme cela est défini au chapitre [XML-Namespaces].
{espace de noms cible}
La propriété est soit ·absente· soit est un nom d'espace de noms, tel que défini dans [XML-Namespaces].
{définition de type}
Soit une définition de type simple soit une définition de type complexe.
{portée}
Facultatif. Soit global soit une définition de type complexe.
{contrainte de valeur}
Facultatif. Une paire composée d'une valeur et de l'une des deux mots-clés default ou fixed.
{annulable}
Un booléen.
{définitions de la contrainte d'identité}
Un ensemble de définitions de contraintes.
{groupe de substitution affilié}
Facultatif. Une définition d'élément supérieur.
{groupes de substitution exclus}
Un sous-ensemble de {extension, restriction}.
{substitutions rejetées}
Un sous-ensemble de {substitution, extension, restriction}.
{abstrait}
Un booléen.
{annotation}
Facultatif. Une annotation.

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.3.2 La représentation XML du composant de schéma de déclaration d'élément

La représentation XML du composant de schéma d'une déclaration d'élément est l'unité d'information de type élément <element>. Elle spécifie la définition de type d'un élément soit par référence soit explicitement et peut fournir des informations sur les occurrences et les valeurs par défaut. Les correspondances entre les propriétés de l'unité d'information et celles du(des) composant(s) qui lui correspond(ent) sont celles-ci :

Vue synthétique de la représentation XML : unité d'information de type élément element

<element
  abstract = boolean : false
  block = (#all | Liste de (extension | restriction | substitution))
  default = string
  final = (#all | Liste de (extension | restriction))
  fixed = string
  form = (qualified | unqualified)
  id = ID
  maxOccurs = (nonNegativeInteger | unbounded)  : 1
  minOccurs = nonNegativeInteger : 1
  name = NCName
  annulable = boolean : false
  ref = QName
  substitutionGroup = QName
  type = QName
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?, ((simpleType | complexType)?, (unique | key | keyref)*))
</element>

Si l'unité d'information de type élément <element> a <schema> comme parent, le composant de schéma correspondant est comme suit :
Composant de schéma :Déclaration d'élément
Propriété Représentation
{nom} La ·valeur réelle· de [l'attribut] name.
{espace de noms cible} La ·valeur réelle· de [l'attribut] targetNamespace de l'unité d'information parent de type élément <schema> ; la propriété est ·absente· si ce parent n'existe pas.
{portée} global.
{définition de type} La définition de type correspondant aux unités d'information [enfants] de type élément <simpleType> ou <complexType>, si l'un d'eux est présent, sinon il s'agit de la définition de type ·ramenée· par la ·valeur réelle· de [l'attribut] type, sinon il s'agit de la {définition de type} de la déclaration d'élément ·ramenée· par la ·valeur réelle· de [l'attribut] substitutionGroup, si il est présent, sinon c'est la ·définition du type ur·.
{annulable} La ·valeur réelle· de [l'attribut] nillable, si il est présent, sinon false.
{contrainte de valeur} Si il y a un [attribut] default ou fixed, alors la valeur de cette propriété est une paire composée de la ·valeur réelle· (par rapport à la {définition de type}, si celle-là est une définition de type simple, ou au {type de contenu} de la {définition de type}, si celle-là est de type simple, ou autre par rapport à la définition du type simple préfabriquée string) de cet [attribut] et l'une des deux valeurs default ou fixed, en fonction du cas de figure, sinon cette propriété est ·absente·.
{définitions des contraintes d'identité} Un ensemble constitué des définitions des contraintes d'identité correspondant à toutes les unités d'information [enfants] de type élément <key>, <unique> et <keyref>, si ces unités existent, sinon l'ensemble est vide.
{groupe de substitution affilié} La déclaration d'élément ·ramenée· par la ·valeur réelle· de [l'attribut] substitutionGroup, si il est présent, sinon cette propriété est ·absente·.
{substitutions rejetées} Un ensemble dépendant de la ·valeur réelle· de [l'attribut] block, si il est présent, sinon de la ·valeur réelle· de [l'attribut] blockDefault de l'ascendant ou de l'unité d'information de type élément <schema>, si une telle unité existe, sinon de la chaîne de caractère vide. Cela s'appelle le EBV (qui signifie effective block value, valeur de bloc effective). Alors la valeur de cette propriété est celle du cas approprié parmi les cas suivants :
1 Si EBV est la chaîne de caractères vide, alors la valeur est l'ensemble vide ;
2 Si EBV est #all, alors la valeur est {extension, restriction, substitution} ;
3 Sinon la valeur est un ensemble dont les membres sont tirés de l'ensemble ci-dessus, chacun étant présent ou absent selon que la ·valeur réelle· (qui est une liste) contient ou non une unité nommée équivalente.
Remarque :Bien que [l'attribut] blockDefault de l'élément <schema> puisse inclure des valeurs autres que extension, restriction ou substitution, ces valeurs sont ignorées dans la résolution des {substitutions rejetées} pour les déclarations d'éléments (mais elles sont utilisées ailleurs).
{groupes de substitution exclus} Comme pour les {substitutions rejetées} ci-dessus, mais en utilisant les [attributs] final et finalDefault à la place des [attributs] block et blockDefault et l'ensemble utile étant{extension, restriction}.
{abstrait} La ·valeur réelle· de [l'attribut] abstract, si il est présent, sinon la valeur est false.
{annotation} L'annotation correspondant à l'unité d'information [enfant] de type élément <annotation> si elle est utilisée, sinon cette propriété est ·absente·.
Sinon si l'unité d'information de type élément <element> a <complexType> ou <group> comme ascendant et si [l'attribut] ref est absent, alors les composants de schéma correspondant sont ceux qui suivent (sauf si minOccurs=maxOccurs=0, auquel cas l'unité correspond à aucun composant du tout) :
Composant de schéma : Particule
Propriété Représentation
{nombre d'occurrences minimum} La ·valeur réelle· de [l'attribut] minOccurs si il est présent, sinon 1.
{nombre d'occurrences maximum} la valeur est unbounded si [l'attribut] maxOccurs vaut unbounded, sinon la valeur est la ·valeur réelle· de [l'attribut] maxOccurs si il est présent, sinon 1.
{terme} Une déclaration (locale) d'élément comme donné ci-dessous.
Une déclaration d'élément comme dans le premier cas ci-dessus, à l'exception de son {espace de noms cible} et de sa {portée} qui définis ci-après :
Composant de schéma : Déclaration d'élément
Propriété Représentation
{espace de noms cible} Si l'attribut form est présent et que sa ·valeur réelle· est qualified, ou si form est absent mais que la ·valeur réelle· de l'attribut elementFormDefault de l'élément ascendant <schema> est qualified, alors cette propriété est la ·valeur réelle· de [l'attribut] targetNamespace de l'unité d'information de type élément parent <schema>, ou ·absent· si il n'y en a pas, sinon cette propriété est ·absente·.
{portée} Si l'unité d'information de type élément <element> a <complexType> comme ascendant, cette propriété prend comme valeur la définition complexe correspondant à cette unité, sinon (cas où l'unité d'information de type élément <element> est à l'intérieur d'une définition <group> nommée), cette propriété est ·absente·.
Sinon (cas où l'unité d'information de type élément <element> a <complexType> ou <group> comme ascendant et que [l'attribut] ref est présent), le composant de schéma correspondant est comme suit (sauf si minOccurs=maxOccurs=0, auquel cas l'unité correspond à aucun composant du tout) :
Composant de schéma : Particule
Propriété Représentation
{nombre d'occurrences minimum} La ·valeur réelle· de [l'attribut] minOccurs si il est présent, sinon 1.
{nombre d'occurrences maximum} Prend la valeur unbounded si [l'attribut] maxOccurs est égal à unbounded, sinon la ·valeur réelle· de [l'attribut] maxOccurs si il est présent, sinon 1.
{terme} La déclaration (supérieure) d'élément ·ramenée· par la ·valeur réelle· de [l'attribut] ref

<element> est la représentation d'une déclaration d'élément dont la définition de type peut être spécifiée soit par référencement soit en étant directement incluse.

Des <element> directement utilisés sous <schema> produisent des déclarations d'éléments globales ; quand <element> est à l'intérieur de <group> ou de <complexType>, cela produit soit des particules qui contiennent des déclarations d'éléments globales (si il y a un attribut ref) soit des déclarations locales. Pour avoir des déclarations complètes, qu'elles soient de niveau supérieur ou locales, l'attribut type sert à faire appel à une définition de type préfabriquée ou pré-déclarée (quand cela est autorisé). Sinon, un type anonyme simple <simpleType> ou complexe <complexType> est intégré au corps de la déclaration.

Les unités d'information de type élément ·validées· par une déclaration supérieure doivent être qualifiées par rapport à {l'espace de noms cible} de cette déclaration (si celle là est ·absente·, alors l'unité ne doit pas être qualifiée). La condition qui permet de savoir si les unités d'information de type élément ·validées· par une déclaration locale doivent être pareillement qualifiées est fournie par [l'attribut] form dont la valeur par défaut est fournie par [l'attribut] elementFormDefault de l'élément englobant <schema>, via la détermination de son {espace de noms cible}.

Comme cela a pu être noté ci-dessus, les noms des déclarations supérieures d'éléments sont dans un ·espace de symboles· distinct des espaces de symboles des noms des définitions de types, aussi il peut y avoir (sans que cela soit toutefois nécessaire) une définition de type simple ou complexe ayant le même nom qu'un élément de niveau supérieur. Comme avec les noms d'attributs, les noms des déclarations d'éléments de portée locale sans {espace de noms cible} résident dans les espaces de symboles locaux à la définition de type qui les contient.

Remarquez que le paragraphe ci-dessus autorise d'avoir deux niveaux de valeurs par défaut pour les définitions de type non spécifiées. Un <element> sans définition de type, ni par inclusion ni par référencement, correspondra à une déclaration d'élément qui a la même définition de type que la tête de son groupe de substitution quand il y en a un d'identifié, sinon ce sera la ·définition du type ur·. La conséquence très importante de ce qui vient d'être écrit est que la déclaration d'élément minimum et valide, c'est à dire celle qui ne contient que l'attribut name et aucun contenu, est aussi la plus générale, validant toutes les combinaisons possibles de texte et de contenu formé de sous-éléments et autorisant l'usage de n'importe quel attribut.

Reportez-vous au chapitre ci-dessous Représentation XML du composant de schéma de définition de la contrainte d'identité (§3.11.2) pour <key>, <unique> et <keyref>.

Exemple
<xs:element name="unconstrained"/>

<xs:element name="videElt">
 <xs:complexType>
  <xs:attribute ...>. . .</xs:attribute>
 </xs:complexType>
</xs:element>

<xs:element name="contextOne">
 <xs:complexType>
  <xs:sequence>
   <xs:element name="myLocalElement" type="myFirstType"/>
   <xs:element ref="globalElement"/>
  </xs:sequence>
 </xs:complexType>
</xs:element>

<xs:element name="contextTwo">
 <xs:complexType>
  <xs:sequence>
   <xs:element name="myLocalElement" type="mySecondType"/>
   <xs:element ref="globalElement"/>
  </xs:sequence>
 </xs:complexType>
</xs:element>
Le premier exemple ci-dessus déclare un élément dont le type, par défaut, est la ·définition du type ur·. Le deuxième utilise une définition anonyme de type complexe directement incluse.

Ces deux derniers exemples illustrent l'utilisation des déclarations locales d'éléments. Les instances de myLocalElement à l'intérieur de contextOne seront contraintes par myFirstType alors que celles se trouvant à l'intérieur de contextTwo seront contraintes par mySecondType.
Remarque :La possibilité d'exprimer que des éléments de même nom puissent avoir des attributs et un contenu différents en fonction de leur contexte d'apparition dans les instances de documents est une nouveauté de XML Schema qui va bien au delà des possibilités permises à l'origine par les DTD in XML 1.0.
Exemple
 <xs:complexType name="facet">
  <xs:complexContent>
   <xs:extension base="xs:annotated">
    <xs:attribute name="value" use="required"/>
   </xs:extension>
  </xs:complexContent>
 </xs:complexType>

 <xs:element name="facet" type="xs:facet" abstract="true"/>

 <xs:element name="encoding" substitutionGroup="xs:facet">
  <xs:complexType>
   <xs:complexContent>
    <xs:restriction base="xs:facet">
     <xs:sequence>
      <xs:element ref="annotation" minOccurs="0"/>
     </xs:sequence>
     <xs:attribute name="value" type="xs:encodings"/>
    </xs:restriction>
   </xs:complexContent>
  </xs:complexType>
 </xs:element>

 <xs:element name="period" substitutionGroup="xs:facet">
  <xs:complexType>
   <xs:complexContent>
    <xs:restriction base="xs:facet">
     <xs:sequence>
      <xs:element ref="annotation" minOccurs="0"/>
     </xs:sequence>
     <xs:attribute name="value" type="xs:duration"/>
    </xs:restriction>
   </xs:complexContent>
  </xs:complexType>
 </xs:element>

 <xs:complexType name="datatype">
  <xs:sequence>
   <xs:element ref="facet" minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:attribute name="name" type="xs:NCName" use="optional"/>
  . . .
 </xs:complexType>
Un exemple extrait d'une version antérieure du schéma des types de données. Le type facet est défini et l'élément facet est déclaré pour l'utiliser. L'élément facet est abstrait -- il est seulement défini pour servir de tête de file au groupe de substitution. Deux éléments supplémentaires sont déclarés, chacun étant membre du groupe de substitution facet. Finalement un type est défini qui fait référence à facet, autorisant ainsi soit period soit encoding (ou tout autre membre du groupe).

3.3.3 Contraintes portant sur la représentation XML de déclaration d'élément

Contraintes de représentation des schémas : Représentation correcte de la déclaration d'élément
En plus des conditions imposées sur l'unité d'information de type élément <element> par le schéma des schémas : Toutes les conditions suivantes doivent être remplies :
1 default et fixed ne doivent pas être présents ensemble.
2 Si le parent de l'unité n'est pas <schema>, alors Toutes les conditions suivantes doivent être remplies :
2.1 Au moins l'un des deux attributs ref et name doit être présent, mais pas les deux en même temps.
2.2 Si ref est présent, alors aucun des <complexType>, <simpleType>, <key>, <keyref>, <unique>, nillable, default, fixed, form, block et type ne doit être présent, c'est à dire que seuls sont autorisés minOccurs, maxOccurs et id en plus de ref, et bien sûr <annotation>.
3 La présence de type et incompatible avec celle de <simpleType> et <complexType>.
4 La particule correspondante et/ou les déclarations d'éléments doivent satisfaire aux conditions exposées aux chapitres [spécification de schéma]raintes portant sur les composants de schéma de déclaration d'élément (§3.3.6) et Contraintes portant sur le composant de schéma de type particule (§3.9.6).

3.3.4 Règles de validation des déclarations d'élément

Règle de validation : Elément localement valide (élément)
Pour qu'une unité d'information de type élément soit localement ·valide· par rapport à une déclaration d'élément, toutes les conditions suivantes doivent être remplies :
1 La déclaration ne doit pas être ·absente·.
2 La déclaration ne doit pas être {abstraite}.
3 L'un des cas ci-dessous doit être vérifié :
3.1 Si la déclaration n'est pas {annulable}, alors aucune unité attribut de l'unité élément ne doit avoir un [nom d'espace de noms] égal à http://www.w3.org/2001/XMLSchema-instance et un [nom local] de valeur nil.
3.2 Si la déclaration est {annulable} et qu'il existe une unité d'information de type attribut dont la ·valeur réelle· est true , alors toutes les conditions suivantes doivent être remplies :
3.2.1 L'unité d'information de type élément ne doit contenir ni caractère ni unité d'information [enfant].de type élément.
3.2.2 Aucune {contrainte de valeur} ne doit avoir la valeur fixed.
4 Si il existe une unité d'information de type attribut parmi les [attributs] de l'unité d'information de type élément dont le [nom d'espace de noms] est égal à http://www.w3.org/2001/XMLSchema-instance et dont le [nom local] est type, alors toutes les conditions suivantes doivent être remplies :
4.1 La ·valeur normalisée· de cette de cette unité d'information de type attribut doit être ·valide· par rapport au type simple préfabriqué QName, comme cela est défini au chapitre Chaîne de caractères valide (§3.14.4) ;
4.2 Le ·nom local· et le ·nom d'espace de noms· (tel que cela est défini au chapitre Interprétation du QName (§3.15.3)), de la ·valeur réelle· de cette unité d'information de type attribut doivent ramener une définition de type, tel que défini dans Résolution de QName (instance) (§3.15.4) -- [Définition :]  qui s'appelle la définition de type local ;
4.3 La ·définition de type local· doit être une dérivée valide de la {définition de type}, étant donné soit l'union des deux ensembles {substitutions rejetées} et {substitutions prohibées} de la {définition de type} telle que définie au chapitre Dérivation correcte de type (complexe) (§3.4.6) (si il s'agit d'une définition de type complexe) soit l'ensemble des {substitutions rejetées} tel que défini dans Dérivation correcte de type (simple) (§3.14.6) (si il s'agit d'une définition de type simple).

[Définition :]  La phrase définition de type réel est utilisée ci-dessous. Si les trois clauses ci-dessus sont satisfaites, elle doit être comprise comme faisant référant à la ·définition de type local· et, dans le cas contraire, à la {définition de type}.

5 Un des cas suivants doit être vérifié :
5.1 Si la déclaration a une {contrainte de valeur}, que l'unité n'a aucun [enfant] de type élément ou caractère et que la clause 3.2 n'est pas vérifiée, alors toutes les conditions suivantes doivent être remplies :
5.1.2 L'unité d'information de type élément ayant la représentation lexicale canonique de la valeur de la {contrainte de valeur} utilisée comme sa propre ·valeur normalisée· doit être ·valide· par rapport à la ·définition de type réel· tel que cela est défini au chapitre Elément localement valide (type) (§3.3.4).
5.2 Si la déclaration n'a pas de {contrainte de valeur} ou si l'unité a des [enfants] de type élément ou caractère ou si la clause 3.2 est vérifiée, alors toutes les conditions suivantes doivent être remplies :
5.2.1 L'unité d'information de type élément doit être ·valide· par rapport à la ·définition de type réel· tel que cela est défini au chapitre Elément localement valide (type) (§3.3.4).
5.2.2 Si il y a une {contrainte de valeur} ayant comme valeur fixed et que la clause 3.2 n'est pas vérifiée, alors toutes les conditions suivantes doivent être remplies :
5.2.2.1 L'unité d'information de type élément ne doit avoir aucune unité d'information [enfant].de type élément.
5.2.2.2 Un des cas suivants doit être vérifié :
5.2.2.2.1 Si le {type de contenu} de la ·définition de type réel· est mixed, alors la ·valeur initiale· de l'unité doit correspondre à la représentation lexicale canonique de la valeur de la {contrainte de valeur}.
5.2.2.2.2 Si le {type de contenu} de la ·définition de type réel· est une définition de type simple, alors la ·valeur réelle· de l'unité doit correspondre à la représentation lexicale canonique de la valeur de la {contrainte de valeur}.
6 L'unité d'information de type élément doit être ·valide· par rapport à chacune des {définitions de contrainte d'identité} comme cela est décrit au chapitre Contrainte d'identité satisfaite (§3.11.4).
7 Si l'unité d'information de type élément est la ·racine de validation·, elle doit être ·valide· comme cela est décrit au chapitre Racine de validation valide (ID/IDREF) (§3.3.4).
Règle de validation : élément localement valide (type)
Pour qu'une unité d'information de type élément soit localement ·valide· par rapport à une définition de type, toutes les conditions suivantes doivent être remplies :
1 La définition de type ne doit pas être ·absente· ;
2 La définition de type ne doit pas être {abstraite} ;
3 Un des cas suivants doit être vérifié :
3.1 Si la définition de type est une définition de type simple, alors toutes les conditions suivantes doivent être remplies :
3.1.1 les [attributs] de l'unité d'information de type élément doivent être vides, à l'exception de ceux dont le [nom de l'espace de noms] est identique à http://www.w3.org/2001/XMLSchema-instance et dont le [nom local] est type, nil, schemaLocation ou noNamespaceSchemaLocation.
3.1.2 L'unité d'information de type élément ne doit avoir aucune unité d'information [enfant] de type élément.
3.1.3 Si la clause 3.2 du chapitre Elément localement valide (élément) (§3.3.4) n'est pas vérifiée, alors la ·valeur normalisée· doit être ·valide· par rapport à la définition de type comme cela est défini au chapitre Chaîne de caractère valide (§3.14.4).
3.2 Si la définition de type est une définition de type complexe, alors l'unité d'information de type élément doit être ·valide· par rapport à la définition de type comme cela est décrit au chapitre Elément localement valide (type complexe) (§3.4.4) ;
Règle de validation : racine de validation valide (ID/IDREF)
Pour qu'une unité d'information de type élément qui est la ·racine de validation· soit ·valide· toutes les conditions suivantes doivent être remplies :
1 Dans la [table des ID/IDREF] de l'unité, aucune [relation] de type ID/IDREF doit être l'ensemble vide.
2 Dans la [table des ID/IDREF] de l'unité, aucune [relation] de type ID/IDREF ne doit avoir plus d'un membre.

Reportez-vous au chapitre Tableau des ID/IDREF (§3.15.5) pour y trouver la définition de la [relation] de type ID/IDREF.

Remarque : La première clause ci-dessus s'applique quand il y a une référence à un ID indéfini. La seconde s'applique quand plusieurs ID ont été définis. Ces deux cas sont dissociés pour garantir que des codes d'erreur distincts leurs seront attribués (référez-vous au chapitre Tableaux des résultats (partie normative) (§C)).
Remarque :Bien que cette règle ne s'applique qu'à la ·racine de validation·, en pratique les programmes de traitement, et en particulier ceux qui font du streaming, peuvent espérer détecter et signaler le cas de la clause 2 quand il survient.
Remarque : Cette reconstruction de la fonctionnalité des ID/IDREF de [XML 1.0 (Second Edition)] est imparfaite dans ce sens que si la ·racine de validation· n'est pas l'élément racine d'un document XML, les résultats ne seront pas nécessairement les mêmes que ceux qui seraient obtenus avec un analyseur lexico-syntaxique validant le même document mais à partir d'une DTD comprenant des déclarations équivalentes.
Règle de validation : Evaluation de la validité de schéma (élément)
L'évaluation de la validité de schéma d'une unité d'information de type élément dépend de sa ·validation· et de ·l'évaluation· de ses unités d'information enfants de type élément et leurs unités d'information de type attribut associées, quand il y en a.

Aussi, pour que la validité de schéma d'une unité d'information de type élément soit évaluée, toutes les conditions suivantes doivent être remplies :

1 L'une des conditions suivantes doit être remplie :
1.1 Toutes les conditions suivantes doivent être remplies :
1.1.1 On doit connaître sa déclaration d'élément, c'est à dire que l'une des propositions suivantes est vraie :
1.1.1.1 Une déclaration a été stipulée par le programme de traitement (référez-vous au chapitre Evaluation de la validité de schéma (§5.2)).
1.1.1.2 Une déclaration a été identifiée comme étant sa ·déclaration contextuelle·.
1.1.1.3 Toutes les conditions suivantes sont remplies :
1.1.1.3.1 Sa ·déclaration contextuelle· n'est pas la valeur skip.
1.1.1.3.2 Son [nom local] et son [nom d'espace de noms] ramènent une déclaration d'élément comme cela est défini au chapitre Résolution de QName (instance) (§3.15.4).
1.1.2 Sa ·validité· par rapport à cette déclaration doit avoir été évaluée comme cela est décrit au chapitre Elément localement valide (élément) (§3.3.4).
1.1.3 Si cette évaluation impliquait l'évaluation d'un Elément localement valide (type) (§3.3.4), la clause 1 ici-même doit être satisfaite.
1.2 Toutes les conditions suivantes doivent être remplies :
1.2.1 On doit connaître sa définition de type, c'est à dire que l'une des propositions suivantes est vraie :
1.2.1.1 une définition de type a été stipulée par le programme de traitement (référez-vous au chapitre Evaluation de la validité de schéma (§5.2)).
1.2.1.2 Toutes les conditions suivantes sont remplies :
1.2.1.2.1 Il y a une unité d'information de type attribut parmi les [attributs] de l'unité d'information de type élément dont le [nom de l'espace de noms] est identique à http://www.w3.org/2001/XMLSchema-instance et dont le [nom local] est type.
1.2.1.2.2 La ·valeur normalisée· de cette unité d'information de type attribut est ·valide· par rapport au type simple préfabriqué QName, tel que cela est défini au chapitre Chaîne de caractère valide (§3.14.4).
1.2.1.2.3 Le ·nom local· et le ·nom de l'espace de noms· (tel que défini au chapitre Interprétation de QName (§3.15.3)), de la ·valeur réelle· de cette unité d'information de type attribut ramènent une définition de type, tel que défini au chapitre Résolution de QName (instance) (§3.15.4) -- [Définition :]  appelez cette définition de type la définition de type local.
1.2.1.2.4 Si il y a aussi une définition de type propre au programme de traitement, la ·définition de type local· doit être une dérivée valide de cette définition de type étant donné soit {substitutions prohibées}, tel que défini dans Dérivation correcte de type (complexe) (§3.4.6) (si il s'agit d'une définition de type complexe), soit l'ensemble vide, tel que cela est défini au chapitre Dérivation correcte de type (simple) (§3.14.6) (si il s'agit d'une définition de type simple).
1.2.2 La ·validité· de l'unité d'information de type élément par rapport à la ·définition de type local· (si elle est présente et est une dérivée valide) ou la définition de type propre au programme de traitement (si aucune ·définition de type local· n'est présente) a été évaluée comme cela est décrit au chapitre Elément localement valide (type) (§3.3.4).
2 La validité de schéma de toutes les unités d'information de type élément parmi ses [enfants] a été évaluée comme cela est décrit au chapitre Evaluation de la validité de schéma (élément) (§3.3.4) et la validité de schéma de toutes les unités d'information de type attribut parmi ses [attributs] a été évaluée comme cela est décrit au chapitre Evaluation de la validité de schéma (attribut) (§3.2.4).

[Définition :]  Si l'un des cas de la clause 1 ci-dessus est vérifié, alors l'unité d'information de type élément a été strictement évaluée.

Si l'unité ne peut pas être ·strictement évaluée·, parce que ni la clause 1.1 ni la clause 1.2 ci-dessus ne sont satisfaites, [Définition :]  la validité de schéma d'une unité d'information de type élément peut être grossièrement évaluée si sa ·déclaration contextuelle· est ignorée par une ·validation· utilisant à la place la ·définition du type ur· comme cela est décrit au chapitre Elément localement valide (type) (§3.3.4).
Remarque : En général, si la clause 1.1 ci-dessus est vérifiée, la clause 1.2 ne l'est pas et vice versa. Toutefois, quand [l'attribut] xsi:type est impliqué, la clause 1.2 devient prioritaire comme cela est mis en évidence au chapitre Elément localement valide (élément) (§3.3.4).
Remarque :Le {nom} et {l'espace de noms cible} ne sont pas mentionnés ci-dessus parce qu'ils sont contrôlés lors de la phase de ·validation· des particules, comme cela est décrit au chapitre Série d'éléments localement valide (Particule) (§3.9.4).

3.3.5 Contributions des déclarations d'éléments à l'ensemble d'information

Contribution à l'ensemble d'information du schéma : Résultats de l'évaluation (élément)
Si la validité de schéma d'une unité d'information de type élément a été évaluée comme cela est décrit au chapitre Evaluation de la validité de schéma (élément) (§3.3.4), alors dans l'ensemble d'information résultant, elle a les propriétés suivantes :
Contributions à l'ensemble d'information issu de la validité de schéma pour les unités d'information de type élément
[contexte de validation]
L'unité d'information ascendant de type élément la plus proche ayant une [information de schéma] (ou l'unité élément elle-même si elle est porteuse de cette propriété).
[validité]
Un cas parmi les suivants :
1 Si l'unité a été ·strictement évaluée· alors un des cas suivants :
1.1 Si toutes les conditions suivantes sont vraies
1.1.1
1.1.1.1 la clause 1.1 du chapitre Evaluation de la validité de schéma (élément) (§3.3.4) est vérifiée et l'unité est ·valide· comme cela est défini au chapitre le chapitre Elément localement valide (élément) (§3.3.4) ;
1.1.1.2 la clause 1.2 du chapitre Evaluation de la validité de schéma (élément) (§3.3.4) est vérifiée et l'unité est ·valide· comme cela est défini au chapitre Elément localement valide (type) (§3.3.4).
1.1.2 Aucun [enfant] ni aucun [attribut] ne contient d'unité d'information (respectivement de type élément ou attribut) dont la [validité] a la valeur invalid.
1.1.3 Aucun [enfant] ni aucun [attribut] ne contient d'unité d'information (respectivement de type élément ou attribut) ayant une ·déclaration contextuelle· de type mustFind dont [validité] a la valeur unknown.
, alors la valeur est valid ;
1.2 Sinon la valeur est invalid..
2 Sinon la valeur est notKnown.
[tentative de validation]
L'un des cas suivants :
1 Si l'unité a été ·strictement évaluée· et que tous ses [enfants] et [attributs] n'ont que des unités d'information (respectivement de type élément ou attribut) dont la [tentative de validation] est full, alors sa valeur est full ;
2 Si l'unité n'a pas été ·strictement évaluée· et que tous ses [enfants] et [attributs] n'ont que des unités d'information (respectivement de type élément ou attribut) dont la [tentative de validation] est none, alors sa valeur est none ;
3 Sinon la valeur est partial.
Contributions à l'ensemble d'information de schéma : Echec de la validation (élément)
Si la ·validité· locale, telle que définie au chapitre Elément localement valide (élément) (§3.3.4) ci-dessus et/ou au chapitre Elément localement valide (type) (§3.3.4) ci-dessous, d'une unité d'information de type élément a été évaluée, alors l'ensemble d'information résultant de la validation de schéma contient, pour l'unité en question, la propriété suivante :
Contributions à l'ensemble d'information issu de la validité de schéma pour des unités d'information de type élément
[code d'erreur de schéma]
L'un des cas suivants :
1 Si l'unité n'est pas ·valide·, alors la valeur est une liste. Les applications qui souhaitent fournir des informations comme par exemple les raisons de l'échec de la ·validation· sont encouragées à enregistrer un ou plusieurs codes d'erreurs (référez-vous à l'annexe Récapitulatif des résultats (§C)) ci-après.
2 Sinon cette contribution est ·absente·.
Contribution à l'ensemble d'information de schéma : Déclaration d'élément
Si une unité d'information de type élément est ·valide· par rapport à une déclaration d'élément comme cela est décrit au chapitre Elément localement valide (élément) (§3.3.4) alors, dans l'ensemble d'information résultant de la validation de schéma, l'unité doit, en fonction des options du programme de traitement, avoir l'un des cas de contribution suivants :
Contributions à l'ensemble d'information issu de la validité de schéma pour les unités d'information de type élément
[déclaration d'élément]
une ·unité isomorphe· au composant de la déclaration lui-même
soit
Contributions à l'ensemble d'information issu de la validité de schéma pour les unités d'information de type élément
[nil]
vrai si la clause 3.2 du chapitre Elément localement valide (élément) (§3.3.4) ci-dessus est satisfaite Sinon la valeur est faux
Contribution à l'ensemble d'information du schéma : Elément validé par type
Si une unité d'information de type élément est ·valide· par rapport à une ·définition de type· comme cela est décrit au chapitre Elément localement valide (type) (§3.3.4), alors, dans l'ensemble d'information résultant de la validation de schéma, elle aura la propriété suivante :
Contributions à l'ensemble d'information issu de la validité de schéma pour des unités d'information de type élément
[valeur normalisée par le schéma]
La valeur correspond à l'un des cas suivants :
1 Si la clause 3.2 des chapitres Elément localement valide (élément) (§3.3.4) et Valeur de l'élément par défaut (§3.3.5) ci-dessus n'est pas vérifiée et que la ·définition de type· ou son {type de contenu} est une définition de type simple, alors la ·valeur normalisée· de l'unité est utilisée comme valeur ·validée·.
2 Sinon cette contribution est ·absente·.
De plus, l'ensemble de propriétés de l'unité est l'un des ensembles suivants :

Soit
Contributions à l'ensemble d'information issu de la validité de schéma pour des unités d'information de type élément
[définition de type]
Une ·unité isomorphe· au composant correspondant dans la ·définition de type·.
[définition de type de membre]
Si, et seulement si il s'agit de la définition d'un type simple dont la {variante} est union, ou si il s'agit de la définition d'un type complexe dont le {type de contenu} est une définition de type simple dont la {variante} est union, alors la contribution est une ·unité isomorphe· au membre de l'ensemble des {définitions de type de membre} de l'union qui ·validait· réellement la ·valeur normalisée· de l'unité élément.
ou
Contributions à l'ensemble d'information issu de la validité de schéma pour des unités d'information de type élément
[type de la définition de type]
simple ou complex, en fonction de la ·définition de type·.
[espace de noms de la définition de type]
{l'espace de noms cible} de la ·définition de type·.
[anonymat de la définition de type]
vrai si le {nom} de la ·définition de type· est ·absent·, sinon faux.
[nom de la définition de type]
Le {nom} de la ·définition de type·, si il n'est pas ·absent·. Si il est ·absent·, les programmes de traitements des schémas peuvent, sans y être obligés, fournir à la définition une valeur unique.
Si la ·définition de type· ou le {type de contenu} sont de type simple dont la {variante} est union, alors en appelant [Définition :] la définition réelle de type de membre, ce membre de l'ensemble des {définitions de type de membre} qui ·validait· réellement la ·valeur normalisée· de l'unité de type élément, il y a trois propriétés additionnelles :
Contributions à l'ensemble d'information issu de la validité de schéma pour des unités d'information de type élément
La première alternative (·unité isomorphe·) ci-dessus est fournie aux applications comme par exemple des programmes d'interrogation qui ont besoin d'avoir accès à la totalité des détails concernant ·l'évaluation· d'une unité, par exemple la hiérarchie des types ; la seconde est pour les programmes plus légers pour lesquels représenter les parties significatives de la hiérarchie des types sous la forme d'unités d'information pourrait être d'une lourdeur significative.

Si la déclaration a une {contrainte de valeur}, la propriété suivante s'applique :
Contributions à l'ensemble d'information issu de la validité de schéma pour des unités d'information de type élément
Remarquez que si un élément est ·grossièrement évalué·, alors la [définition de type] et la [définition de type de membre], ou leurs alternatives, sont basées sur la ·définition du type ur·.
Contribution à l'ensemble d'information du schéma : Valeur de l'élément par défaut
Si la ·validité· locale, telle que définie au chapitre Elément localement valide (élément) (§3.3.4) ci-dessus, d'une unité d'information de type élément a été évaluée, alors, la propriété suivante s'applique :
Contributions à l'ensemble d'information issu de la validité de schéma pour des unités d'information de type élément
[spécification de schéma]
L'un cas des cas suivants :
1 Si l'unité est ·valide· par rapport à une déclaration d'élément tel que cela est décrit au chapitre Elément localement valide (élément) (§3.3.4) et que la {contrainte de valeur} est présente mais que la clause 3.2 du chapitre Elément localement valide (élément) (§3.3.4) n'est pas satisfaite et que l'unité d'information n'a pas d'[enfant] de type élément ou caractère, alors cette contribution prend la valeur schema. De plus, l'ensemble d'information résultant de la validation de schéma utilise la représentation lexicale canonique de la {contrainte de valeur} comme [valeur normalisée par le schéma] de l'unité.
2 Sinon la contribution est infoset.

3.3.6 Contraintes des composants de schéma de déclaration d'élément

Toutes les déclarations d'éléments (référez-vous au chapitre déclaration d'élément (§3.3)) doivent satisfaire les contraintes suivantes.

Contraintes des composants de schéma : propriétés correctes de la déclaration d'élément
Toutes les conditions suivantes doivent être remplies :
1 Les valeurs des propriétés d'une déclaration d'élément doivent être telles que décrites dans le tableau de propriétés au chapitre Composant de schéma de déclaration d'élément (§3.3.1), modulo l'impact des sous-composants manquant (§5.3).
2 Si il y a une {contrainte de valeur}, la représentation lexicale canonique de sa valeur doit être ·valide· par rapport à la {définition de type} tel que cela est défini au chapitre Valeur d'élément par défaut valide (immédiate) (§3.3.6).
3 Si il y a une {groupe de substitution affilié}, la {définition de type} de la déclaration d'élément doit être une dérivée valide de la {définition de type} du {groupe de substitution affilié}, en tenant compte de la valeur du {groupe de substitution exclu} du {groupe de substitution affilié}, tel que cela est défini au chapitre Dérivation correcte de type (complexe) (§3.4.6) (si la {définition de type} est complexe) ou au chapitre Dérivation correcte de type (simple) (§3.14.6) (si la {définition de type} est simple).
4 Si la {définition de type} ou le {type de contenu} de la {définition de type} sont, ou sont dérivés, d'un type ID alors il ne doit pas y avoir de {contrainte de valeur}.
Remarque : L'utilisation du type ID comme définition de type pour des éléments va au delà de ce que permettait de faire XML 1.0 et devrait être évité quand la compatibilité descendante est attendue.

Les contraintes suivantes définissent des relations auxquelles il est fait appel ailleurs dans cette spécification.

Contraintes des composants de schéma : Validité des éléments par défaut (immédiate)
Pour qu'une chaîne de caractères soit une valeur par défaut valide par rapport à une définition de type, l'un des cas suivants doit être vérifié :
1 Si La définition de type est celle d'un type simple, alors la chaîne de caractères doit être ·valide· par rapport à cette définition tel que cela est défini au chapitre Chaîne de caractère valide (§3.14.4).
2 Si La définition de type est celle d'un type complexe, alors toutes les conditions suivantes doivent être remplies :
2.1 Son {type de contenu} doit être une définition de type simple ou la valeur mixed.
2.2 L'un des cas suivants doit être vérifié :
2.2.1 Si le {type de contenu} est une définition de type simple, alors la chaîne de caractères doit être ·valide· par rapport à cette définition de type simple tel que cela est défini au chapitre Chaîne de caractère valide (§3.14.4).
2.2.2 Si le {type de contenu} est mixed, alors la particule du {type de contenu} doit pouvoir être ·vide· tel que cela est défini au chapitre Particule pouvant être vide (§3.9.6).
Contraintes des composants de schéma : Groupe de substitution correct (transitif)
Pour qu'une déclaration d'élément (appelez là D) ayant une contrainte de blocage (un sous-ensemble de {substitution, extension, restriction}, la valeur d'un ensemble de {substitutions rejetées}, ) soit valablement substituable à une autre déclaration d'élément (appelez là C) toutes les conditions suivantes doivent être remplies :
1 La contrainte de blocage ne doit pas contenir la valeur substitution.
2 Il existe une chaîne de {groupes de substitution affilié} de D à C, c'est à dire que, soit le {groupe de substitution affilié} à D est C, soit le {groupe de substitution affilié} du {groupe de substitution affilié} à D est C, etc . . .
3 L'ensemble de toutes les {méthodes de dérivation} impliquées dans la dérivation de la {définition de type} de D à partir de la {définition de type} de C n'interfère pas avec l'union des contraintes de blocage, des {substitutions prohibées} de C (si C est complexe sinon cela est un ensemble vide) et de l'ensemble des {substitutions prohibées} (respectivement l'ensemble vide) de toute {définition de type} intermédiaire au cours de la dérivation de la {définition de type} de D à partir de celle de C.
Contraintes des composants de schéma : Groupe de substitution
[Définition :]  Chaque déclaration d'élément de la {déclaration d'élément} d'un schéma définit un groupe de substitution, sous-ensemble de cette {déclaration d'élément}, de la manière suivante :
1 La déclaration d'élément elle-même est dans le groupe ;
2 Le groupe est fermé par rapport au {groupe de substitution affilié}, c'est à dire que, si l'une des déclarations d'élément de la {déclaration d'élément} a un {groupe de substitution affilié} dans le groupe, alors elle est aussi dans le groupe lui-même.

previous sub-section next sub-section 3.4 Définitions d'un type complexe

Les définitions de types complexes servent à :

Exemple
<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>
La représentation XML d'une définition de type complexe.

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 :

Composant de schéma : Définition d'un type complexe
{nom}
Facultatif. Un NCName comme cela est défini au chapitre [XML-Namespaces].
{espace de noms cible}
Soit cette propriété est ·absente· soit c'est un nom d'espace de noms, tel que défini dans [XML-Namespaces].
{définition du type de base}
Cette propriété est soit la définition d'un type simple soit la définition d'un type complexe.
{méthode de dérivation}
Soit extension soit restriction.
{terminal}
Un sous-ensemble de {extension, restriction}.
{abstrait}
Un booléen
{attributs utilisés}
Un ensemble d'utilisations d'attributs.
{attribut générique}
Facultatif. Un caractère générique.
{type de contenu}
Soit empty, soit la définition d'un type simple soit une paire composée d'un ·modèle de contenu· (c'est à dire une Particule (§2.2.3.2)) et l'une des deux valeurs mixed ou elements-only.
{substitutions prohibées}
Un sous-ensemble de {extension, restriction}.
{annotations}
Un ensemble d'annotations.

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 :

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 :

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.4.2 représentation XML de la définition d'un type complexe

La représentation XML d'un composant de schéma de définition d'un type complexe est l'unité d'information de type élément <complexType>.

La représentation XML de la définition d'un type complexe ayant une définition de type simple comme {type de contenu} est singulièrement différente de celle des autres {types de contenu} et cela se reflète dans la présentation ci-dessous, qui présente en premier les éléments impliqués dans le premier cas, puis ceux du second cas. La correspondance des propriétés est montrée une fois dans chaque cas.

Vue synthétique de la représentation XML: unité d'information de type élément complexType 

<complexType
  abstract = booléen : false
  block = (#all | List of (extension | restriction))
  final = (#all | List of (extension | restriction))
  id = ID
  mixed = booléen : false
  name = NCName
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?, (simpleContent | complexContent | ((group | all | choice | séquence)?, ((attribute | attributeGroup)*, anyAttribute?))))
</complexType>

Quelque soit la variante choisie pour le contenu de <complexType>, les correspondances de propriété suivantes s'appliquent :
 Composant de schéma :Définition d'un type complexe
Propriété Représentation
{nom} La ·valeur réelle· de [l'attribut] name si il est présent, sinon cette propriété est ·absente·.
{espace de noms cible} La ·valeur réelle· de [l'attribut] targetNamespace de l'unité d'information de type élément <schema> si elle est présente, sinon la propriété est ·absente·.
{abstrait} La ·valeur réelle· de [l'attribut] abstract si il est présent, sinon la propriété prend la valeur false.
{substitutions prohibées} Un ensemble correspondant à la ·valeur réelle· de [l'attribut] block si il est présent et sinon prend la ·valeur réelle· de [l'attribut] blockDefault de l'ascendant ou de l'unité d'information de type élément <schema>, si il est présent, et sinon c'est une chaîne vide. Appelez cela la EBV (pour "effective block value" : valeur effective du bloc). Alors sa valeur est celle d'un des cas suivants :
1 Si la EBV est la chaîne vide, alors la valeur est l'ensemble vide ;
2 Si la EBV est #all, alors la valeur est l'ensemble {extension, restriction};
3 Sinon la valeur est un ensemble composé des membres issus de l'ensemble ci-dessus, chacun étant présent ou absent en fonction de la présence dans la ·valeur réelle· (qui est une liste) d'une unité ayant un nom équivalent.
Remarque : Bien que [l'attribut] blockDefault de <schema> puisse inclure des valeurs autres que restriction ou extension, celles-là sont ignorées lors de la recherche des {substitutions prohibées} pour les définitions de types complexes (elles sont utilisées ailleurs).
{terminal} Comme pour l'ensemble des {substitutions prohibées} ci-dessus, mais en utilisant les [attributs] final et finalDefault à la place des [attributs] block et blockDefault.
{annotations} Les annotations correspondant à l'unité d'information de type élément <annotation> des [enfants], quand il y en a, des [enfants] <simpleContent> et <complexContent> quand il y en a et dans leurs [enfants] <restriction> et <extension> quand il y en a. Dans tous les autres cas, la propriété est ·absente·.
Quand l'option <simpleContent> est choisie, les éléments suivants sont appropriés et les correspondances des propriétés restantes sont celles présentées ci-dessous. Remarquez que soit <restriction> soit <extension> doivent être choisis comme contenu de <simpleContent>.

<simpleContent
  id = ID
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?, (restriction | extension))
</simpleContent>

<restriction
  base = QName
  id = ID
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?, (simpleType?, (minExclusive | minInclusive | maxExclusive | maxInclusive | totalDigits | fractionDigits | length | minLength | maxLength | enumeration | whiteSpace | pattern)*)?, ((attribute | attributeGroup)*, anyAttribute?))
</restriction>

<extension
  base = QName
  id = ID
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?, ((attribute | attributeGroup)*, anyAttribute?))
</extension>

<attributeGroup
  id = ID
  ref = QName
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?)
</attributeGroup>

<anyAttribute
  id = ID
  namespace = ((##any | ##other) | List of (anyURI | (##targetNamespace | ##local)) )  : ##any
  processContents = (lax | skip | strict) : strict
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?)
</anyAttribute>

 Composant de schéma : Définition de type complexe ayant un contenu simple
Propriété Représentation
{définition du type de base} La définition de type ·ramenée· par la ·valeur réelle· de [l'attribut] base
{méthode de dérivation} Si l'option <restriction> est choisie, alors cette propriété vaut restriction et sinon (l'option <extension> est choisie) prend la valeur extension.
{attributs utilisés} L'union des ensembles des attributs utilisés définie comme suit :
1 L'ensemble des attributs utilisés correspondant aux [enfants] <attribute> quand il y en a.
2 Les {attributs utilisés} des groupes d'attributs ·ramenés· par les ·valeurs réelles· de [l'attribut] ref des [enfants] <attributeGroup> quand il y en a.
3 Si la définition de type ·ramenée· par la ·valeur réelle· de [l'attribut] base est une définition de type complexe, alors la valeur est l'ensemble des {attributs utilisés} de cette définition de type, sauf si l'option <restriction> est choisie, auquel cas certains membres de l'ensemble des {attributs utilisés} de cette définition de type peuvent ne pas être inclus, à savoir ceux dont les {nom} et {espace de noms cible} de la {déclaration d'attribut} sont les mêmes que ceux d'un des cas suivants :
3.1 les {nom} et {espace de noms cible} de la {déclaration d'attribut} d'un attribut utilisé de l'ensemble obtenu par les clauses 1 ou 2 ci-dessus  ;
3.2 ce qu'auraient été les {nom} et {espace de noms cible} de la {déclaration d'attribut} d'un attribut utilisé dans l'ensemble obtenu par la clause 1 ci-dessus mais pour la ·valeur réelle· de [l'attribut] use de l'élément <attribute> approprié parmi les [enfants] de <restriction> qui sont prohibés.
{attribut générique} [Définition  :]  le caractère générique local est défini comme étant l'un des cas suivants :
1 Si un élément <anyAttribute> est présent, alors le caractère générique est basé sur les ·valeurs réelles· des [attributs] namespace et processContents et des [enfants] <annotation>, exactement comme pour le caractère générique correspondant à un élément <any> présenté au chapitre Représentation XML des composants de schéma pour les caractères génériques (§3.10.2);
2 Sinon la propriété est ·absente·.
[Définition  :]  le caractère générique complet est défini comme l'un des cas suivants :
2 Si un ou plusieurs [enfants] <attributeGroup> ont un {attribut générique}, alors l'un des cas suivants s'applique :
2.1 Si l'élément <anyAttribute> est présent, alors c'est un caractère générique dont le {type de validation} et {l'annotation} sont ceux du ·caractère générique local· et dont la {contrainte d'espace de noms} est l'intersection de la {contrainte d'espace de noms} du ·caractère générique local· et des {contraintes d'espace de noms} de tous les {attributs génériques} présents (non-·absents·) des éléments [enfants] <attributeGroup> tel que cela est défini au chapitre Intersection des attributs génériques (§3.10.6).
2.2 Si aucun élément <anyAttribute> n'est présent, alors c'est un caractère générique dont les propriétés sont les suivantes :
{type de validation}
Le {type de validation} du premier {attribut générique} présent (non-·absent·) d'un groupe d'attributs parmi les groupes d'attributs correspondant aux éléments [enfants] <attributeGroup>.
{contrainte d'espace de noms}
L'intersection des {contraintes d'espace de noms} de tous les {attributs génériques} présents (non-·absents·) des groupes d'attributs correspondant aux éléments [enfants] <attributeGroup> tel que cela est défini au chapitre Intersection des attributs génériques (§3.10.6).
{annotation}
Cette propriété est ·absente·.
La valeur est alors déterminée par l'un des cas suivants :
1 Si l'option <restriction> est choisie, alors la valeur est celle du ·caractère générique complet· ;
2 Si l'option <extension> est choisie, alors [Définition :]  le caractère générique de base est défini comme étant l'un des cas suivants :
2.1 Si La définition de type ·ramenée· par la ·valeur réelle· de [l'attribut] base est une définition de type complexe ayant un {attribut générique}, alors c'est cet {attribut générique}.
2.2 Sinon il est ·absent·.
La valeur est alors déterminée par l'un des cas suivants :
2.1 Si le ·caractère générique de base· est présent (non-·absent·), alors c'est l'un des cas suivants :
{type de contenu}
1 Si la définition de type ·ramenée· par la ·valeur réelle· de [l'attribut] base est une définition de type complexe (dont le propre {type de contenu} doit être une définition de type simple, reportez-vous au chapitre ci-dessous) et que l'option <restriction> est choisie, alors en partant de :
1.1 soit la définition du type simple correspondant à l'élément <simpleType> [enfant] de <restriction> si il existe ;
1.2 soit la définition du type simple du {type de contenu} de la définition de type ·ramenée· par la ·valeur réelle· de [l'attribut] base
la valeur de cette propriété est une version restreinte de cette définition de type simple obtenue via des composants facettes correspondant aux unités d'information de type élément concernées qui sont des [enfants] de l'élément <restriction> (c'est à dire les unités qui spécifient des facettes, quand il y en a), tel que cela est défini au chapitre Restriction du type simple (facettes) (§3.14.3);
2 Sinon si la définition de type ·ramenée· par la ·valeur réelle· de [l'attribut] base est une définition de type complexe (dont le propre {type de contenu} doit être une définition de type simple, reportez-vous au chapitre ci-dessous) et que l'option <extension> est choisie, alors la valeur est le {type de contenu} de la définition de ce type complexe ;
3 Sinon (La définition de type ·ramenée· par la ·valeur réelle· de [l'attribut] base est une définition de type simple et l'option <extension> est choisie), alors la propriété est cette définition de type simple.
Quand l'option <complexContent> est choisie, les éléments suivants sont appropriés (en plus des éléments <attributeGroup> et <anyAttribute> qui ne sont pas répétés ici) et les correspondances additionnelles de propriétés sont celles indiquées ci-après. Remarquez que l'un des deux éléments <restriction> et <extension> doit être choisi comme contenu de <complexContent>, mais leurs modèles de contenu sont différents du précédent (quand ils sont des enfants de <simpleContent>).
Les correspondances de propriétés ci-dessous sont aussi utilisées dans le cas où la troisième option (ni <simpleContent> ni <complexContent>) est choisie. Ce cas est compris comme étant un raccourci pour des restrictions de contenu complexe de la ·définition du type ur· et les détails des correspondances devraient être modifiés en conséquence.

<complexContent
  id = ID
  mixed = booléen
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?, (restriction | extension))
</complexContent>

<restriction
  base = QName
  id = ID
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?, (group | all | choice | séquence)?, ((attribute | attributeGroup)*, anyAttribute?))
</restriction>

<extension
  base = QName
  id = ID
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?, ((group | all | choice | séquence)?, ((attribute | attributeGroup)*, anyAttribute?)))
</extension>

Composant de schéma :Définition de type complexe ayant un contenu complexe
Propriété Représentation
{définition du type de base} La définition de type ·ramenée· par la ·valeur réelle· de [l'attribut] base
{méthode de dérivation} Si l'option <restriction> est choisie, alors cette propriété est restriction, sinon (l'option <extension> est choisie) elle est égale à extension.
{attributs utilisés} L'union des ensembles des attributs utilisés déterminée comme suit :
1 l'ensemble des attributs utilisés correspondant aux [enfants] <attribute> quand il y en a.
2 L'ensemble des {attributs utilisés} des groupes d'attributs ·ramenés· par les ·valeurs réelles· de [l'attribut] ref des [enfants] <attributeGroup> quand il y en a.
3 L'ensemble des {attributs utilisés} de la définition de type ·ramenée· par la ·valeur réelle· de [l'attribut] base, sauf si l'option <restriction> est choisie, auquel cas certains membres de l'ensemble des {attributs utilisés} de cette définition de type pourraient ne pas être inclus, à savoir ceux dont les {nom} et {espace de noms cible} de la {déclaration d'attribut} sont les mêmes que dans l'un des cas suivants :
3.1 Les {nom} et {espace de noms cible} de la {déclaration d'attribut} d'un des attributs utilisés de l'ensemble obtenu par les clauses 1 ou 2 ci-dessus  ;
3.2 Ce qu'auraient été les {nom} et {espace de noms cible} de la {déclaration d'attribut} d'un des attributs utilisés de l'ensemble obtenu par la clause 1 ci-dessus mais pour la ·valeur réelle· de [l'attribut] use de l'élément approprié <attribute> parmi les [enfants] de <restriction> qui sont prohibés.
{attribut générique} Comme ci-dessus pour l'option <simpleContent>.
{type de contenu} L'un des cas suivants :
1 Si l'option <restriction> est choisie, alors l'un des cas suivants :
1.1 Si l'une des assertions suivantes est vraie :
1.1.1 Il n'y a aucun élément <group>, <all>, <choice> ou <séquence> parmi les [enfants]  ;
1.1.2 Il y a un élément <all> ou <séquence> parmi les [enfants] et aucun autre [enfant] propre à l'exception de l'élément <annotation> ;
1.1.3 Il y a un élément <choice> parmi les [enfants] et aucun autre [enfant] propre à l'exception de l'élément <annotation> et la ·valeur réelle· de son [attribut] minOccurs est 0;
, alors la propriété est empty ;
1.2 Sinon la valeur est une paire composée de :
1.2.1 l'un des cas suivants :
1.2.1.1 Si [l'attribut] mixed est présent sur l'élément <complexContent>, alors la valeur est mixed si sa ·valeur réelle· est true, sinon la valeur est elementOnly;
1.2.1.2 Si [l'attribut] mixed est présent sur l'élément <complexType> et si sa ·valeur réelle· est true, alors la valeur est mixed ;
1.2.1.3 Sinon la valeur est elementOnly.
1.2.2 La particule correspondant aux éléments <all>, <choice>, <group> ou <séquence> parmi les [enfants].
2 Si l'option <extension> est choisie, alors [Définition :]  le contenu explicite est empty si l'une quelconque des sous-clauses de la clause 1.1 ci-dessus s'applique, sinon est la particule correspondant aux éléments <all>, <choice>, <group> ou <séquence> parmi les [enfants] et prend alors la valeur d'un des cas suivants :
2.1 Si le ·contenu explicite· est empty, alors la valeur est le {type de contenu} de la définition de type ·ramenée· par la ·valeur réelle· de [l'attribut] base
2.2 Si la définition de type ·ramenée· par la ·valeur réelle· de [l'attribut] base a un {type de contenu} empty, alors la valeur est une paire composée soit de mixed soit de elementOnly (déterminé comme cela est décrit dans la clause 1.2.1 ci-dessus) et du ·contenu explicite· lui-même ;
2.3 Sinon la valeur est une paire composée soit de mixed soit de elementOnly (déterminé comme cela est décrit dans la clause 1.2.1 ci-dessus) et d'une particule dont les propriétés sont les suivantes :
{nombre d'occurrences minimum}
1
{nombre d'occurrences maximum}
1
{terme}
Un groupe modèle dont le {connecteur} est sequence et dont les {particules} sont celles du {type de contenu} de la définition de type ·ramenée· par la ·valeur réelle· de [l'attribut] base suivi par le ·contenu explicite·.
Remarque : Mis à part les conditions simples de cohérence imposées ci-dessus, contraindre les définitions de types identifiées restrictions à en être réellement, c'est à dire à ·valider· un sous-ensemble des unités ·validées· par la définition du type de base, est imposé au chapitre Contraintes sur les composants de schéma de définition d'un type complexe (§3.4.6).
Remarque : La seule fonction permanente de la valeur prohibited de [l'attribut] use de l'élément <attribute> se trouve dans l'établissement de la correspondance entre un type complexe défini par restriction et sa représentation XML. Cela empêche d'hériter de l'utilisation d'un attribut utilisé de nom identique à partir de la {définition d'un type de base}. Un tel élément <attribute> ne correspond à aucun composant et de là découle le fait qu'il n'y ait aucune interaction explicite ou héritée avec des caractères génériques dans la mise en oeuvre des Règles de validation de la définition d'un type complexe (§3.4.4) ou des Contraintes sur les composants de schéma de définition d'un type complexe (§3.4.6).

Une attention minutieuse à la syntaxe concrète ci-dessus révèle qu'une définition de type n'a besoin d'avoir rien de plus qu'un nom, c'est à dire que, par exemple, la seul définition <complexType name="anyThing"/> est autorisée.

Exemple :
<xs:complexType name="length1">
 <xs:simpleContent>
  <xs:extension base="xs:nonNegativeInteger">
   <xs:attribute name="unit" type="xs:NMTOKEN"/>
  </xs:extension>
 </xs:simpleContent>
</xs:complexType>

<xs:element name="width" type="length1"/>

  <width unit="cm">25</width>

<xs:complexType name="length2">
 <xs:complexContent>
  <xs:restriction base="xs:anyType">
   <xs:sequence>
    <xs:element name="size" type="xs:nonPositiveInteger"/>
    <xs:element name="unit" type="xs:NMTOKEN"/>
   </xs:sequence>
  </xs:restriction>
 </xs:complexContent>
</xs:complexType>

<xs:element name="depth" type="length2"/>

  <depth>
   <size>25</size><unit>cm</unit>
  </depth>

<xs:complexType name="length3">
 <xs:sequence>
  <xs:element name="size" type="xs:non-positive-integer"/>
  <xs:element name="unit" type="xs:NMTOKEN"/>
 </xs:sequence>
</xs:complexType>
Trois approches pour définir le type d'une longueur (length) : l'une avec un contenu formé de caractères de données contraints par une référence à un type de données préfabriqué et un attribut, les deux autres en utilisant deux éléments. length3 est l'option abrégée de length2 : elles correspondent à des composants identiques de définition de types.
Exemple :
<xs:complexType name="personName">
 <xs:sequence>
  <xs:element name="title" minOccurs="0"/>
  <xs:element name="forename" minOccurs="0" maxOccurs="unbounded"/>
  <xs:element name="surname"/>
 </xs:sequence>
</xs:complexType>

<xs:complexType name="extendedName">
 <xs:complexContent>
  <xs:extension base="personName">
   <xs:sequence>
    <xs:element name="generation" minOccurs="0"/>
   </xs:sequence>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

<xs:element name="addressee" type="extendedName"/>

  <addressee>
   <forename>Albert</forename>
   <forename>Arnold</forename>
   <surname>Gore</surname>
   <generation>Jr</generation>
  </addressee>
Une définition de type pour des noms propres et une définition dérivée par extension qui ajoute un seul élément ; une déclaration d'élément faisant référence à la définition dérivée et une instance ·valide· juste après.
Exemple
<xs:complexType name="simpleName">
 <xs:complexContent>
  <xs:restriction base="personName">
   <xs:sequence>
    <xs:element name="forename" minOccurs="1" maxOccurs="1"/>
    <xs:element name="surname"/>
   </xs:sequence>
  </xs:restriction>
 </xs:complexContent>
</xs:complexType>

<xs:element name="who" type="simpleName"/>

   <who>
    <forename>Bill</forename>
    <surname>Clinton</surname>
   </who>
Une définition simplifiée d'un type dérivé par restriction du type de base de l'exemple précédent, en éliminant un enfant facultatif et obligeant un autre à apparaître exactement une fois puis un élément déclaré par référence à cette définition et enfin un exemple d'instance ·valide·.
Exemple
<xs:complexType name="paraType" mixte="true">
 <xs:choice minOccurs="0" maxOccurs="unbounded">
  <xs:element ref="emph"/>
  <xs:element ref="strong"/>
 </xs:choice>
 <xs:attribute name="version" type="xs:number"/>
</xs:complexType>
Un autre exemple de la forme abrégée, avec l'attribut mixte apparaissant sur l'élément complexType lui-même.

3.4.3 Contraintes portant sur la représentation XML de la définition d'un type complexe

Contraintes de représentation des schémas : Représentation correcte de la définition d'un type complexe
En plus des conditions imposées sur les unités d'information de type élément <complexType> par le schéma des schémas, toutes les conditions suivantes doivent être remplies :
1 Si l'option <complexContent> est choisie, la définition de type ·ramenée· par la ·valeur réelle· de [l'attribut] base doit être une définition de type complexe ;
2 Si l'option <simpleContent> est choisie, la définition de type ·ramenée· par la ·valeur réelle· de [l'attribut] base doit être soit une définition de type complexe dont le {type de contenu} est une définition de type simple soit, mais seulement si l'option <extension> est aussi choisie, une définition de type simple ;
3 Le composant de définition de type complexe correspondant doit satisfaire aux conditions exposées au chapitre Contraintes sur les composants de schéma de la définition d'un type complexe (§3.4.6);
4 Si l'une des deux clauses 2.1 ou 2.2 des spécifications de correspondance ci-dessus de {l'attribut générique} est satisfaite, l'intersection doit être exprimable, tel que cela est défini au chapitre Intersection des attributs génériques (§3.10.6).

3.4.4 Règles de validation de la définition d'un type complexe

Règle de validation : Elément localement valide (type complexe)
Pour qu'une unité d'information de type élément soit localement ·valide· par rapport à une définition de type complexe toutes les conditions suivantes doivent être remplies :
1 Elle ne doit pas être {abstraite}.
2 Si la clause 3.2 du chapitre Elément localement valide (élément) (§3.3.4) n'est pas vérifiée, alors un des cas suivants doit être vérifié :
2.1 Si le {type de contenu} est empty, alors elle ne contient ni caractère ni unité d'information [enfant] de type élément.
2.2 Si le {type de contenu} est une définition de type simple, alors elle n'a aucune unité d'information [enfant] de type élément et sa ·valeur normalisée· est ·valide· par rapport à cette définition de type simple comme cela est défini au chapitre Chaîne de caractère valide (§3.14.4).
2.3 Si le {type de contenu} est elements-only, alors elle n'a aucune unité d'information [enfant] de type caractère autre que celles dont le [code du caractère] est défini comme étant l'espace blanc de la spécification [XML 1.0 (Second Edition)].
2.4 Si le {type de contenu} est elements-only ou mixed, alors la séquence de ses unités d'information [enfants] de type élément, quand il y en a, prise dans cet ordre, est ·valide· par rapport à la particule de {type de contenu}, tel que cela est défini au chapitre Série d'éléments localement valide (particule) (§3.9.4).
3 Pour chacune des unités d'information de type attribut de ses [attributs], mais à l'exception de celles dont le [nom d'espace de noms] est identique à http://www.w3.org/2001/XMLSchema-instance et dont le [nom local] est type, nil, schemaLocation ou noNamespaceSchemaLocation, l'un des cas suivants doit être vérifié :
3.1 Si l'un des {attributs utilisés} a une {déclaration d'attribut} dont les {nom} et {espace de noms cible} correspondent au [nom local] et au [nom d'espace de noms] de l'unité d'information de type attribut (où un {espace de noms cible} ·absent· est considéré être identique à un [nom d'espace de noms] n'ayant aucune valeur), alors l'information attribut doit être ·valide· par rapport à cet attribut utilisé comme cela est décrit au chapitre Attribut localement valide (utilisation) (§3.5.4). Dans ce cas la {déclaration d'attribut} de l'attribut en question est la ·déclaration contextuelle· de l'unité d'information de type attribut en ce qui concerne l'évaluation de la validité de schéma (attribut) (§3.2.4) et le Résultat de l'évaluation (attribut) (§3.2.5).
3.2 Sinon toutes les conditions suivantes doivent être remplies :
3.2.1 Il doit y avoir un {attribut générique}.
3.2.2 L'unité d'information de type attribut doit être ·valide· par rapport à lui tel que cela est défini au chapitre Unité valide (caractère générique) (§3.10.4).
4 La {déclaration d'attribut} de chaque attribut de l'ensemble des {attributs utilisés} dont la {présence} est obligatoire correspond à l'une des unités d'information de type attribut de l'ensemble des [attributs] de l'unité d'information de type élément tel que cela est décrit dans la clause 3.1 ci-dessus.
5 [Définition :]  les IDentifiants génériques sont l'ensemble de toutes les unités d'information de type attribut qui vérifient la clause 3.2 et dont la ·validation· résultait en une ·déclaration contextuelle· de valeur mustFind ou bien aucune ·déclaration contextuelle· du tout et dont les [nom local] et [nom de l'espace de noms] ramènent (tel que cela est défini au chapitre résolution de QName (instance) (§3.15.4)) une déclaration d'attribut dont la {définition de type} est, ou est dérivé, de l'IDentifiant. Alors toutes les conditions suivantes doivent être remplies :
5.1 Il ne doit pas y avoir plus d'une unité dans l'ensemble des ·IDentifiants génériques·.
5.2 Si l'ensemble des ·IDentifiants génériques· n'est pas vide, aucun attribut de l'ensemble des {attributs utilisés} ne doit avoir sa {définition de type} de {déclaration d'attribut} être, ou être dérivée, de l'IDentifiant.
Remarque : Cette clause sert à garantir que même via les attributs génériques aucun élément n'aura plus d'un attribut de type ID et cela s'applique même quand un élément n'a pas, de par sa déclaration, d'attribut de type ID, alors la règle dit qu'un attribut générique validé ne doit permettre de lui en allouer qu'un. Cela étant, si un élément a un type dont les déclarations d'attributs contiennent un attribut de type ID, alors soit il aura cet attribut soit il n'aura aucun attribut de type ID.
Remarque : Quand un {attribut générique} est présent, cela n'introduit aucune ambiguïté par rapport à la manière dont les unités d'information de type attribut qui ont un attribut est membre de l'ensemble des {attributs utilisés} et pour lesquelles les correspondances entre nom et espace de noms cible sont ·évalués·. Dans de tels cas l'attribut utilisé prend toujours la priorité et l'·évaluation· de telles unités est établie ou échoue totalement sur la base de l'attribut utilisé et de sa {déclaration d'attribut}. Cela découle des détails de la clause 3.

3.4.5 Contributions de la définition d'un type complexe à l'ensemble d'information

Contribution à l'ensemble d'information de schéma : Valeur d'attribut par défaut
Pour chaque attribut de l'ensemble des {attributs utilisés} dont la {présence} est optionnelle et dont la {contrainte de valeur} est présente (elle n'est pas ·absente·) mais dont la {déclaration d'attribut} ne correspond pas à l'une des unités d'information de type attribut de l'ensemble des [attributs] de l'unité d'information de type élément comme cela est décrit à la clause 3.1 du chapitre Elément localement valide (type complexe) (§3.4.4) ci-dessus, l'ensemble d'information résultant de la validation de schéma a une unité d'information de type attribut dont les propriétés ci-dessous sont ajoutées à l'ensemble des [attributs] de l'unité d'information de type élément.
[nom local]
Le {nom} de la {déclaration d'attribut}.
[nom de l'espace de noms]
{l'espace de noms cible} de la {déclaration d'attribut}.
[valeur normalisée par le schéma]
La représentation lexicale canonique de la valeur de la {contrainte de valeur}.
[valeur par défaut du schéma]
La représentation lexicale canonique de la valeur de la {contrainte de valeur}.
[contexte de validation]
L'ascendant le plus proche ou l'unité d'information de type élément porteuse de la propriété [information de schéma].
[validité]
valid.
[tentative de validation]
full.
[spécification de schéma]
schema.
Les unités ajoutées doivent soit avoir une [définition de type] (et une [définition de type de membre] quand cela est justifié), soit avoir des variantes moins exigeantes, comme cela est précisé au chapitre Attribut validé par type (§3.2.5).

3.4.6 Contraintes des composants de schéma de définition de types complexes

Toutes les définitions de types complexes (référez-vous au chapitre Définitions de types complexes (§3.4)) doivent satisfaire les contraintes suivantes.

Contraintes des composants de schéma : Exactitudes des propriétés de la définition d'un type complexe
Toutes les conditions suivantes doivent être remplies :
1 Les valeurs des propriétés d'une définition de type complexe doivent être celles décrites dans le tableau des propriétés du chapitre Définition d'un composant de schéma de type complexe (§3.4.1), modulo l'impact des sous-composants manquant (§5.3).
2 Si la {définition du type de base} est une définition de type simple, la {méthode de dérivation} doit être par extension.
3 Les définitions circulaires sont interdites, excepté pour la ·définition du type ur·. Cela étant, il doit être possible d'atteindre la ·définition du type ur· en suivant de manière répétitive la {définition du type de base}.
4 Deux déclarations d'attributs distinctes de l'ensemble des {attributs utilisés} ne doivent pas avoir simultanément les mêmes {noms} et {espaces de noms cible}.
5 Deux déclarations d'attributs distinctes de l'ensemble des {attributs utilisés} ne doivent pas avoir des {définitions de type} qui sont, ou sont dérivées, du type ID.
Contraintes des composants de schéma : Dérivation valide (extension)
Si la {méthode de dérivation} est par extension, l'un des cas suivants doit être vérifié :
1 Si la {définition du type de base} est une définition de type complexe, alors toutes les conditions suivantes doivent être remplies :
1.1 La {définition du type de base} ne doit pas être {terminale} pour l'extension.
1.2 Son ensemble des {attributs utilisés} doit être un sous-ensemble de l'ensemble des {attributs utilisés} de la définition du type complexe lui-même, c'est à dire que, pour chaque attribut utilisé de l'ensemble des {attributs utilisés} de la {définition du type de base}, il doit y avoir un attribut de l'ensemble des {attributs utilisés} de la définition du type complexe lui-même dont la {déclaration d'attribut} a les mêmes {nom}, {espace de noms cible} et {définition de type} que sa déclaration d'attribut.
1.3 Si il a un {attribut générique}, la définition de type complexe doit aussi en avoir un et la définition de la {contrainte d'espace de noms} de {l'attribut générique} du type de base doit être un sous-ensemble de la définition de la {contrainte d'espace de noms} de {l'attribut générique} du type complexe, tel que cela est défini au chapitre Sous-ensemble du caractère générique (§3.10.6).
1.4 L'une des conditions suivantes doit être vérifiée :
1.4.1 Le {type de contenu} de la {définition du type de base} doit avoir la même définition de type simple que celui de la définition du type complexe lui-même .
1.4.2 Toutes les conditions suivantes doivent être remplies :
1.4.2.1 Le {type de contenu} de la définition du type complexe lui-même doit préciser une particule.
1.4.2.2 L'une des conditions suivantes doit être vérifiée :
1.4.2.2.1 Le {type de contenu} de la {définition du type de base} doit être empty.
1.4.2.2.2 Toutes les conditions suivantes doivent être remplies :
1.4.2.2.2.1 Les deux {types de contenu} doivent être soit mixte soit elements-only.
1.4.2.2.2.2 La particule de la définition du type complexe doit être une ·extension valide· de la particule de la {définition du type de base}, tel que cela est défini au chapitre Particule valide (extension) (§3.9.6).
1.5 Il doit être en principe possible de dériver la définition du type complexe en deux temps, en premier une extension et en second une restriction (potentiellement inerte), de cette définition de type parmi ses ascendants dont la {définition du type de base} est la ·définition du type ur·.
Remarque : Cette exigence garantit que rien de ce qui pourrait être enlevé par une restriction sera ensuite rajouté par une extension. Il est facile de contrôler si l'extension en question est la seule extension de sa dérivation ou si il n'y a pas de restriction exceptée la première de la ·définition du type ur·.

Construire la définition de type intermédiaire pour contrôler cette contrainte est quelque chose de direct : tout d'abord, il faut réordonner la dérivation pour mettre en premier toutes les étapes de l'extension, ensuite on la ramène à une seule extension. Si la définition résultante peut être la base d'une restriction valide pour la définition souhaitée, alors la contrainte est satisfaite.
2 Si la {définition du type de base} est une définition de type simple, alors toutes les conditions suivantes doivent être remplies :
2.1 Le {type de contenu} doit être la même définition de type simple.
2.2 La {définition du type de base} ne doit pas être {terminale} pour l'extension.
[Définition :]  Si cette contrainte de Dérivation valide (extension) (§3.4.6) vient de la définition d'un type complexe, c'est une extension valide de sa {définition du type de base}.
Contraintes des composants de schéma : Dérivation valide (restriction, complexe)
Si la {méthode de dérivation} est restriction toutes les conditions suivantes doivent être remplies :
1 La {définition du type de base} doit être une définition de type complexe qui ne doit pas être {terminale} pour la restriction.
2 Pour chaque attribut utilisé (appelez le R) de l'ensemble des {attributs utilisés} l'un des cas suivants doit être vérifié :
2.1 Si il y a un attribut de l'ensemble des {attributs utilisés} de la {définition du type de base} (appelez la B) dont la {déclaration d'attribut} a les mêmes {nom} et {espace de noms cible}, alors toutes les conditions suivantes doivent être remplies :
2.1.1 L'une des conditions suivantes doit être vérifiée :
2.1.1.1 la {présence} de B n'est pas obligatoire.
2.1.1.2 la {présence} de R est imposée.
2.1.2 La {définition de type} de la {déclaration d'attribut} de R doit être une dérivée valide de la {définition de type} de B étant donné l'ensemble vide tel que cela est défini au chapitre Dérivation correcte de type (simple) (§3.14.6).
2.1.3 [Définition :]  la contrainte de valeur effective d'un attribut utilisé est sa {contrainte de valeur}, si elle existe sinon la {contrainte de valeur} de sa {déclaration d'attribut}. Alors l'une des conditions suivantes doit être vérifiées :
2.1.3.1 la ·contrainte de valeur effective· de B est ·absente· ou default.
2.1.3.2 la ·contrainte de valeur effective· de R est fixed avec la même chaîne de caractères que B.
2.2 Sinon la {définition du type de base} doit avoir un {attribut générique} et {l'espace de noms cible} de la {déclaration d'attribut} de R doit être ·valide· par rapport à ce caractère générique, tel que cela est défini au chapitre Noms d'espaces de noms autorisés par les caractères génériques(§3.10.4).
3 Pour chaque attribut de l'ensemble des {attributs utilisés} de la {définition du type de base} dont la {présence} est obligatoire, il doit y avoir un attribut ayant une {déclaration d'attribut} avec les mêmes {nom} et {espace de noms cible} que sa {déclaration d'attribut} de l'ensemble des {attributs utilisés} de la définition de type complexe en question dont la {présence} est obligatoire.
4 Si il y a un {attribut générique}, toutes les conditions suivantes doivent être remplies :
4.1 La {définition du type de base} doit aussi en avoir un.
4.2 La {contrainte d'espace de noms} de {l'attribut générique} de la définition du type complexe doit être un sous-ensemble de la {contrainte d'espace de noms} de {l'attribut générique} de la {définition du type de base}, tel que cela est défini au chapitre Sous-ensemble du caractère générique (§3.10.6).
5 L'un des cas suivants doit être vérifié :
5.1 Si le {type de contenu} de la définition du type complexe est une définition de type simple, alors l'une des conditions suivantes doit être vérifiée :
5.1.1 Le {type de contenu} de la {définition du type de base} doit être une définition de type simple de laquelle le {type de contenu} est une ·restriction valide· tel que cela est défini au chapitre Dérivation valide (restriction, simple) (§3.14.6).
5.1.2 La {définition du type de base} doit être mixed et avoir une particule qui puisse être ·vide· tel que cela est défini au chapitre Particule pouvant être vide (§3.9.6).
5.2 Si le {type de contenu} du type complexe lui-même est empty , alors l'une des conditions suivantes doit être vérifiée :
5.2.1 Le {type de contenu} de la {définition du type de base} doit aussi être empty.
5.2.2 Le {type de contenu} de la {définition du type de base} doit être de l'un des deux types elements-only ou mixed et avoir une particule ·vide· comme cela est défini au chapitre Particule pouvant être vide (§3.9.6).
5.3 Si le {type de contenu} de la {définition du type de base} est mixed ou si le {type de contenu} de la définition du type complexe lui-même est de type elements-only, alors la particule de la définition du type complexe lui-même doit être une ·restriction valide· de la particule du {type de contenu} de la {définition du type de base} comme cela est défini au chapitre Particule valide (restriction) (§3.9.6).
[Définition :]  Si cette contrainte de dérivation valide (restriction, complexe) (§3.4.6) tient de la définition d'un type complexe, c'est une restriction valide de sa {définition d'un type de base}.
Remarque : Pour restreindre à empty une définition de type complexe ayant une définition de base de type simple, utilisez une définition de type simple ayant une valeur fixed de la chaîne vide : cela permet de conserver l'information de type.

La contrainte suivante définit une relation utilisée ailleurs dans cette spécification.

Contraintes des composants de schéma : Dérivation correcte de type (complexe)
Pour qu'une définition de type complexe (appelez la D, comme dérivée) soit une dérivée valide d'une définition de type (appelez la B, comme base) étant donné un sous-ensemble de l'ensemble {extension, restriction} toutes les conditions suivantes doivent être remplies :
1 Si B et D ne sont pas la même définition de type, alors la {méthode de dérivation} de D ne doit pas être dans le sous-ensemble.
2 L'une des conditions suivantes doit être vérifiée :
2.1 B et D doivent être la même définition de type.
2.2 B doit être la {définition du type de base} de D.
2.3 Toutes les conditions suivantes doivent être remplies :
2.3.1 La {définition du type de base} de D ne doit pas être la ·définition du type ur·.
2.3.2 L'un des cas suivants doit être vérifié :
2.3.2.1 Si la {définition du type de base} de D est complexe, alors elle doit être une dérivée valide de B étant donné le sous-ensemble comme cela est défini par cette contrainte.
2.3.2.2 Si la {définition du type de base} de D est simple, alors elle doit être une dérivée valide de B étant donné le sous-ensemble tel que cela est défini au chapitre dérivation correcte de type (simple) (§3.14.6).
Remarque :Cette contrainte est utilisée pour contrôler que lorsque un type est utilisé dans un contexte où un autre type était attendu (soit via xsi:type ou un groupe de substitution), le type utilisé est réellement dérivé du type attendu et que cette dérivation n'implique pas une forme de dérivation exclue par le type attendu.

3.4.7 Définitions préfabriquées de types complexes

Il y a une définition de type complexe presque équivalente à la ·définition du type ur·et qui est présente dans tout schéma par définition. Ce type complexe a les propriétés suivantes :

définition du type complexe de type ur
Propriété Valeur
{nom} anyType
{espace de noms cible} http://www.w3.org/2001/XMLSchema
{définition du type de base} lui-même
{méthode de dérivation} restriction
{type de contenu} Un couple formé de la valeur mixed et d'une particule ayant les propriétés suivantes :
Propriété Value
{nombre d'occurrences minimum} 1
{nombre d'occurrences maximum} 1
{terme} un groupe modèle ayant les propriétés suivantes:
Propriété Valeur
{connecteur} sequence
{particules} une liste contenant une particule ayant les propriétés suivantes:
Propriété Valeur
{nombre d'occurrences minimum} 0
{nombre d'occurrences maximum} unbounded
{terme} un caractère générique ayant any comme propriété de {contrainte d'espace de noms}
{attributs utilisés} L'ensemble vide
{attribut générique} La {contrainte d'espace de noms} est any
{terminal} L'ensemble vide
{substitutions prohibées} L'ensemble vide
{abstrait} false

Spécifier un contenu mixte ayant un caractère générique non-contraint comme spécification de modèle de contenu et d'attribut produit la ·définition du type ur·, à savoir que chaque définition de type complexe est (éventuellement) une restriction de la ·définition du type ur· : ses permissions et exigences sont les moins restrictives que possible.

Remarque : Cette spécification ne fournit aucun inventaire de définitions préfabriquées de types complexes pour une utilisation dans les schémas utilisateurs. Une bibliothèque préliminaire de définitions de types complexes est disponible qui inclut à la fois des définitions de types mathématiques (par exemple le type rational) et utilitaire (par exemple le type array). En particulier, il y a une définition de type text recommandée pour être utilisée comme définition de type des déclarations d'éléments ayant pour but d'être utilisée avec du texte libre comme modèle de contenu, de même que cette bibliothèque contient quelques types pour les aspects internationalisation. Pour plus de détails, reportez-vous au document de type schéma qui contient une bibliothèque de types à son nom d'espace de noms : http://www.w3.org/2001/03/XMLSchema/TypeLibrary.xsd.

previous sub-section next sub-section 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.

Exemple
<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>
     
Des représentations XML qui impliquent toutes des attributs utilisés, illustrant quelques unes des possibilités permettant d'en contrôler les occurrences.

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 :

Composant de schéma : attribut utilisé
{présence}
Un booléen.
{déclaration d'attribut}
Une déclaration d'attribut.
{contrainte de valeur}
Propriété facultative. Une paire composée d'une valeur et soit la valeur default soit la valeur fixed.

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.5.2 La représentation XML du composant d'attribut utilisé

Un attribut devient utilisé quand l'attribut use de l'élément <attribute> est utilisé. Cela à son tour correspond à deux composants dans chaque cas, un attribut utilisé et sa {déclaration d'attribut} (bien que vous pouvez remarquer que cette dernière ne soit pas nouvelle quand l'utilisation de l'attribut est une référence à une déclaration d'attribut supérieure). La correspondance est décrite au chapitre Représentation XML du composant de schéma de déclaration d'attribut (§3.2.2).

3.5.3 Contraintes portant sur la représentation XML du composant d'un attribut utilisé

N'existe pas en tant que tel.

3.5.4 Règles de validation de l'utilisation d'un attribut

Règle de validation : attribut localement valide (utilisation)
Pour qu'une unité d'information de type attribut soit ·valide· pour un attribut utilisé, sa ·valeur normalisée· doit correspondre à la représentation lexicale canonique de la valeur utilisée de la {contrainte de valeur} de l'attribut, si elle est présente et fixed.

3.5.5 Contributions d'un attribut utilisé à l'ensemble d'information

N'existe pas en tant que tel.

3.5.6 Contraintes sur le composant de schéma d'un attribut utilisé

Tous les attributs utilisés (référez-vous au chapitre utilisations des attributs (§3.5)) doivent satisfaire les contraintes suivantes.

Contraintes des composants de schéma : attribut utilisé correctement
Toutes les conditions suivantes doivent être remplies :
1 Les valeurs des propriétés d'un attribut utilisé doivent être conformes à celles décrites dans le tableau des propriétés au chapitre Composant de schéma d'un attribut utilisé (§3.5.1), modulo l'impact des sous-composants manquant (§5.3).
2 Si la {déclaration d'attribut} a une {contrainte de valeur} fixed, alors si l'attribut utilisé a lui-même une {contrainte de valeur}, elle doit aussi être fixed et sa valeur doit correspondre à celle de la {contrainte de valeur} de la {déclaration d'attribut}.

previous sub-section next sub-section 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>).

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

<xs:complexType name="myelement">
    . . .
    <xs:attributeGroup ref="myAttrGroup"/>
</xs:complexType>
Différentes représentations XML de définitions de groupes d'attributs. L'effet est identique à une déclaration d'attribut directement faite dans la définition du type complexe myelement.

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 :

Composant de schéma : Définition d'un groupe d'attributs
{nom}
Un NCName tel que défini dans [XML-Namespaces].
{espace de noms cible}
Cette propriété est soit ·absente· soit est un nom d'espace de noms, tel que défini dans [XML-Namespaces].
{attributs utilisés}
Cette propriété est un ensemble d'attributs utilisés.
{attribut générique}
Facultatif. Un caractère générique.
{annotation}
Facultatif. Une annotation.

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.6.2 Représentation XML du composant de schéma de définition d'un groupe d'attributs

La représentation XML du composant de schéma de définition d'un groupe d'attributs est une unité d'information de type élément <attributeGroup>. Elle permet de nommer un groupe constitué de déclarations d'attributs et d'un attribut générique afin d'être ensuite utilisé par référence dans la représentation XML des définitions de types complexes et d'autres définitions de groupes d'attributs. Les correspondances entre les propriétés de l'unité d'information et celles du composant lui correspondant sont les suivantes :

Vue synthétique de la représentation XML : unité d'information de type élément attributeGroup

<attributeGroup
  id = ID
  name = NCName
  ref = QName
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?, ((attribute | attributeGroup)*, anyAttribute?))
</attributeGroup>

Quand <attributeGroup> est un enfant de <schema> ou de <redefine>, il s'agit alors de la définition d'un groupe d'attributs comme ci-dessous. Quand il apparaît comme enfant de <complexType> ou <attributeGroup>, cela ne correspond à aucun composant en tant que tel.
 Composant de schéma :Définition d'un groupe d'attributs
Propriété Représentation
{nom} La ·valeur réelle· de [l'attribut] name
{espace de noms cible} La ·valeur réelle· de [l'attribut] targetNamespace de l'unité d'information parent de type élément schema.
{attributs utilisés} C'est le résultat de l'union de l'ensemble des attributs utilisés correspondant aux éléments [enfants] <attribute>, quand il y en a, et de l'ensemble des {attributs utilisés} des groupes d'attributs ·ramenés· par les ·valeurs réelles· des [attributs] ref des [enfants] <attributeGroup>, quand il y en a.
{attribut générique} Comme pour le ·caractère générique complet· tel que cela est décrit au chapitre Représentation XML des définitions de types complexes (§3.4.2).
{annotation} L'annotation correspondant à l'unité d'information de type élément <annotation> des [enfants], si il y en a, sinon, cette propriété est ·absente·.

L'exemple ci-dessus illustre un motif récurrent dans la représentation XML des schémas : Le même élément, dans ce cas attributeGroup, sert à la fois pour définir et incorporer par référence. Dans le premier cas l'attribut name est obligatoire, dans le second l'attribut ref est obligatoire et l'élément doit être vide. Ces deux cas sont mutuellement exclusifs et sont aussi conditionnés par le contexte : la forme de la définition, avec un attribut name, doit intervenir au niveau supérieur d'un schéma, alors que la forme par référence, avec un attribut ref, doit intervenir à l'intérieur d'une définition de type complexe ou de la définition d'un groupe d'attributs.

3.6.3 Contraintes portant sur la représentation XML de la définition d'un groupe d'attributs

Contraintes de représentation des schémas : Représentation correcte de la définition d'un groupe d'attributs
En plus des conditions imposées aux unités d'information de type élément <attributeGroup> par le schéma des schémas, toutes les conditions suivantes doivent être remplies :
1 La définition du groupe d'attributs correspondant, si il existe, doit satisfaire aux conditions exposées au chapitre Contraintes des composants de schéma de définition d'un groupe d'attributs (§3.6.6).
2 si l'une des deux clauses 2.1 et 2.2 des spécifications de correspondance du chapitre Représentation XML des définitions de types complexes (§3.4.2) pour {l'attribut générique}, tel que référencé ci-dessus, est satisfaite, alors l'intersection doit pouvoir être exprimée, tel que cela est défini au chapitre Intersection des attributs génériques (§3.10.6).
3 Une référence de groupe circulaire est interdite en dehors d'un <redefine>. Cela étant, à moins que le parent de cette unité d'information de type élément soit <redefine>, alors il ne doit se trouver parmi les [enfants], quand il y en a, aucun élément <attributeGroup> ayant un [attribut] ref dont la résolution ramène le composant correspondant à cet <attributeGroup>.

3.6.4 Règles de validation de la définition d'un groupe d'attributs

N'existe pas en tant que tel.

3.6.5 Contributions de la définition d'un groupe d'attributs à l'ensemble d'information

N'existe pas en tant que tel.

3.6.6 Contraintes des composants de schéma de définition d'un groupe d'attributs

Toutes les définitions des groupes d'attributs (référez-vous au chapitre des Définitions de groupes d'attributs (§3.6)) doivent satisfaire la contrainte suivante.

Contraintes des composants de schéma : Exactitudes des propriétés de la définition d'un groupe d'attributs
Toutes les conditions suivantes doivent être remplies :
1 Les valeurs des propriétés de la définition d'un groupe d'attributs doivent être telles que décrites dans le tableau des propriétés du chapitre Composant de schéma de définition d'un groupe d'attributs (§3.6.1), modulo l'impact des sous-composants manquant (§5.3) ;
2 Deux membres distincts de l'ensemble des {attributs utilisés} ne doivent pas avoir de {déclarations d'attributs} ayant les mêmes {noms} et {espaces de noms cible}.
3 Deux membres distincts de l'ensemble des {attributs utilisés} ne doivent pas avoir de {déclarations d'attributs} dont les {définitions de types} sont ou sont dérivées de ID.

previous sub-section next sub-section 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.

Exemple
<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>
Un groupe modèle minimal est défini et utilisé par référence, d'abord comme modèle de contenu à part entière puis comme une des possibilités d'un modèle de contenu de type choice.

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 :

Composant de schéma : Définition d'un groupe modèle
{nom}
Un NCName tel que défini dans [XML-Namespaces].
{espace de noms cible}
Cette propriété est soit ·absente· soit est un nom d'espace de noms, tel que défini dans [XML-Namespaces].
{groupe modèle}
Un groupe modèle.
{annotation}
Facultatif. Une annotation.

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.7.2 Représentation XML du composant de schéma de définition d'un groupe modèle

La représentation XML du composant de schéma de définition d'un groupe modèle est l'unité d'information de type élément <group>. Elle permet de nommer un groupe modèle pour qu'il puisse être utilisé par référence dans les représentations XML des définitions de types complexes et des groupes modèles. Les correspondances entre les propriétés de l'unité d'information et celles du composant qui lui correspond sont les suivantes :

Vue synthétique de la représentation XML : Unité d'information de type élément group 

<group
  name = NCName>
  Content: (annotation?, (all | choice | séquence))
</group>

Si [l'attribut] name est utilisé (ce qui signifie que le parent de l'unité est <schema> ou <redefine>), alors l'unité est un composant de définition d'un groupe modèle qui a les propriétés suivantes :
 Composant de schéma :Définition d'un groupe modèle
Propriété Représentation
{nom} La ·valeur réelle· de [l'attribut] name
{espace de noms cible} La ·valeur réelle· de [l'attribut] targetNamespace de l'unité d'information de type élément parent schema.
{groupe modèle} Un groupe modèle qui est le {terme} d'une particule correspondant à l'un des connecteurs [enfants] <all>, <choice> ou <séquence> (il doit y en avoir un).
{annotation} L'annotation correspondant à l'unité d'information de type élément <annotation> des [enfants], quand il y en a, sinon cette propriété est ·absente·.
Sinon l'unité utilise [l'attribut] ref et renvoie à une particule ayant les propriétés suivantes (sauf si minOccurs=maxOccurs=0, auquel cas l'unité correspond à aucun composant du tout):
 Composant de schéma : Particule
Propriété Représentation
{nombre d'occurrences minimum} la ·valeur réelle· de [l'attribut] minOccurs, si il est présent, sinon vaut 1.
{nombre d'occurrences maximum} unbounded, si [l'attribut] maxOccurs est égal à unbounded, sinon prend la ·valeur réelle· de [l'attribut] maxOccurs, si il est présent, sinon vaut 1.
{terme} Le {groupe modèle} de la définition du groupe modèle ·ramené· par la ·valeur réelle· de [l'attribut] ref

Le nom de ce chapitre est légèrement trompeur en cela que le deuxième cas, anonyme, ci-dessus (avec un attribut ref et sans attribut name) n'est pas vraiment un groupe modèle nommé, mais une référence à un tel groupe modèle nommé. Remarquez aussi que dans le premier cas (celui qui est nommé) ci-dessus aucune référence n'est faite à minOccurs ou maxOccurs : la raison en est que le schéma des schémas n'autorise pas leur utilisation sur l'enfant d'un <group> nommé. Cela, à son tour, parce que les valeurs prises en compte sont celle du {nombre d'occurrences minimum} et du {nombre d'occurrences maximum} des particules qui font référence à la définition au groupe modèle nommé.

Etant donné les contraintes sur son apparition dans les modèles de contenu, un connecteur <all> ne devrait apparaître uniquement comme étant la seule unité des [enfants] d'une définition d'un groupe modèle nommé ou d'un modèle de contenu : reportez-vous au chapitre Contraintes sur les composants de schéma d'un groupe modèle (§3.8.6).

3.7.3 Contraintes portant sur la représentation XML d'une définition de groupe modèle

Contraintes de représentation des schémas : Représentation correcte de la définition d'un groupe modèle
En plus des conditions imposées sur les unités d'information de type élément <group> par le schéma des schémas, la définition de groupe modèle correspondant, quand elle existe, doit satisfaire aux conditions exposées au chapitre Contraintes sur les composants de schéma d'un groupe modèle (§3.8.6).

3.7.4 Règles de validation de la définition d'un groupe modèle

N'existe pas en tant que tel.

3.7.5 Contributions de la définition d'un groupe modèle à l'ensemble d'information

N'existe pas en tant que tel.

3.7.6 Contraintes des composants de schéma de définition d'un groupe modèle

Toutes les définitions de groupes modèles (référez-vous au chapitre Définitions des groupes modèles (§3.7)) doivent satisfaire la contrainte suivante.

Contraintes des composants de schéma : Exactitudes des propriétés de la définition d'un groupe modèle
Les valeurs des propriétés d'une définition d'un groupe modèle doivent être celles décrites dans le tableau des propriétés du chapitre Composant de schéma de définition d'un groupe modèle (§3.7.1), modulo l'impact des sous-composants manquant (§5.3).

previous sub-section next sub-section 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.

Example
<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>
Représentations XML de trois sortes de groupes modèles, la troisième imbriquée dans la seconde.

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 :

Composant de schéma : Groupe modèle
{connecteur}
L'une des valeurs all, choice or sequence.
{particules}
Une liste de particules
{annotation}
Facultatif. Une annotation.

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 :

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.8.2 Représentation XML des composants de schéma d'un groupe modèle

Les représentations XML des composants de schéma d'un groupe modèle sont les unités d'information de type élément <all>, <choice> ou <séquence>. Les correspondances entre les propriétés de ces unités d'information et celles du composant qui leur correspond sont les suivantes :

Vue synthétique de la représentation XML : unités d'information de type élément all, choice et sequence

<all
  id = ID
  maxOccurs = 1 : 1
  minOccurs = (0 | 1) : 1
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?, element*)
</all>

<choice
  id = ID
  maxOccurs = (nonNegativeInteger | unbounded)  : 1
  minOccurs = nonNegativeInteger : 1
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?, (element | group | choice | séquence | any)*)
</choice>

<séquence
  id = ID
  maxOccurs = (nonNegativeInteger | unbounded)  : 1
  minOccurs = nonNegativeInteger : 1
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?, (element | group | choice | séquence | any)*)
</séquence>

chacune des unités ci-dessus correspond à une particule contenant un groupe modèle ayant les propriétés suivantes (sauf si minOccurs=maxOccurs=0, auquel cas l'unité correspond à aucun composant du tout):
 Composant de schéma : Particule
Propriété Représentation
{nombre d'occurrences minimum} La ·valeur réelle· de [l'attribut] minOccurs, si il est présent, sinon 1.
{nombre d'occurrences maximum} unbounded, si [l'attribut] maxOccurs vaut unbounded, sinon la ·valeur réelle· de [l'attribut] maxOccurs, si il est présent, sinon prend la valeur 1.
{terme} Un groupe modèle comme décrit ci-dessous :
 Composant de schéma : Groupe modèle
Propriété Représentation
{connecteur} all, choice ou sequence en fonction de l'unité d'information de type élément.
{particules} Un lot ordonné de particules correspondant aux unités [enfants] <all>, <choice>, <séquence>, <any>, <group> et <element>.
{annotation} L'annotation correspondant à l'unité d'information de type élément <annotation> des [enfants], quand il y en a, sinon cette propriété est ·absente·.

3.8.3 Contraintes portant sur la représentation XML des groupes modèles

Contraintes de représentation des schémas : Représentation correcte du groupe modèle
En plus des conditions imposées aux unités d'information de type élément <all>, <choice> et <séquence> par le schéma des schémas, les particules et groupes modèles correspondant doivent satisfaire aux conditions exposées aux chapitres Contraintes sur les composants de schéma d'un groupe modèle (§3.8.6) et Contraintes portant sur le composant de schéma de type particule (§3.9.6).

3.8.4 Règles de validation d'un groupe modèle

Règle de validation : Série d'éléments valide
[Définition :]  Une partition d'une série est une série de sous-séries, tout ou partie d'entre elles pouvant être vides, de sorte qu'en concaténant toutes les sous-séries on obtienne la série de départ.

Pour qu'une série (potentiellement vide) d'unités d'information de type élément soit localement ·valide· par rapport à un groupe modèle, l'un des cas suivants doit être vérifié :
1 Si le {connecteur} est sequence, alors il doit y avoir une ·partition· de la série en n sous-série où n est la longueur de l'ensemble des {particules} de telle manière que chaque sous-série, dans l'ordre, soit ·valide· par rapport à la particule correspondante de l'ensemble des {particules} de départ comme cela est défini au chapitre Série d'éléments localement valide (particule) (§3.9.4).
2 Si le {connecteur} est choice, alors une des particules de l'ensemble des {particules} doit être présente de sorte que la série soit ·valide· par rapport à cette particule comme cela est défini dans Série d'éléments localement valide (particule) (§3.9.4).
3 Si le {connecteur} est all, alors il doit y avoir une ·partition· de la série en n sous-séries où n est la longueur de l'ensemble des {particules} de départ, de sorte qu'il y ait des correspondances une à une entre les sous-séries et les {particules} et que chaque sous-série soit ·valide· par rapport à la particule correspondante comme cela est défini dans Série d'éléments localement valide (particule) (§3.9.4).

Rien de ce qui est écrit ci-dessus ne doit être interprété comme excluant les groupes dont l'ensemble des {particules} est vide : bien qu'aucune séquence ne puisse être ·valide· par rapport à un tel un tel groupe quand le {connecteur} est choice, la séquence vide est ·valide· par rapport aux groupes vides quand les {connecteurs} sont séquence ou all.
Remarque : La définition ci-dessus est implicitement non-déterministe et ne devrait pas être prise comme une recette de cuisine dans les mises en pratique de la spécification. Remarquez en particulier que quand le {connecteur} est all, la série de particules est réduite à une liste de déclarations locales ou supérieures (reportez-vous au chapitre Contraintes sur les composants de schéma d'un groupe modèle (§3.8.6)). Une implémentation plus simple est possible qui consiste à interpréter littéralement la définition ci-dessus ; de manière informelle, le contenu est ·valide· quand chaque élément déclaré apparaît exactement une fois (ou au plus une fois, si le {nombre d'occurrences minimum} vaut 0) et que chacun d'eux est ·valide· par rapport à sa déclaration correspondante. Les éléments peuvent apparaître dans n'importe quel ordre.

3.8.5 Contributions d'un groupe modèle à l'ensemble d'information

N'existe pas en tant que tel.

3.8.6 Contraintes sur les composants de schéma d'un groupe modèle

Tous les groupes modèles (référez-vous au chapitre Groupes modèles (§3.8)) doivent satisfaire les contraintes suivantes.

Contraintes des composants de schéma : justesse d'un groupe modèle
Toutes les conditions suivantes doivent être remplies :
1 Les valeurs des propriétés d'un groupe modèle doivent être conformes à celles décrites dans le tableau des propriétés du chapitre Le composant de schéma d'un groupe modèle (§3.8.1), modulo l'impact des Sous-composants manquant (§5.3).
2 Les groupes circulaires sont interdits. Cela étant, à l'intérieur d'un ensemble de {particules} d'un groupe il ne doit y avoir, à aucun niveau de profondeur, aucune particule dont le {terme} soit le groupe lui-même.
Contraintes des composants de schéma : limitation du groupe all
Quand un groupe modèle a le {connecteur} all toutes les conditions suivantes doivent être remplies :
1 Une des conditions suivantes doit être vérifiée :
1.1 Il apparaît comme le groupe modèle d'une définition d'un groupe modèle.
1.2 Il apparaît dans une particule dont le {nombre d'occurrences minimum}={nombre d'occurrences maximum}=1, et cette particule doit faire partie d'une paire qui constitue le {type de contenu} d'une définition de type complexe.
2 Le {nombre d'occurrences maximum} de toutes les particules de l'ensemble des {particules} du groupe doit être 0 or 1.
Contraintes des composants de schéma : Cohérence de la déclaration d'élément
Si l'ensemble des {particules} contient directement, indirectement (c'est à dire, à l'intérieur de l'ensemble des {particules} d'un groupe modèle contenu, et récursivement) ou ·implicitement·, deux particules ou plus dont les déclarations d'élément ont des {nom} et {espace de noms cible} identiques, alors les définitions de types correspondant à ces éléments doivent avoir la même définition supérieure, c'est à dire que toutes les conditions suivantes doivent être remplies :
1 toutes leurs {définitions de type} doivent avoir un nom présent (non- ·absente·).
2 toutes leurs {définitions de type} doivent avoir le même nom.
3 toutes leurs {définitions de type} doivent avoir le même espace de noms cible.

[Définition :]  Une liste de particules contient implicitement une déclaration d'élément si un membre de la liste contient cette déclaration d'élément dans son ·groupe de substitution·.
Contraintes des composants de schéma : Attribution de particule unique
Un modèle de contenu doit être formé de telle manière que, pendant la ·validation· d'une séquence d'unités d'information de type élément, la particule, contenue directement, indirectement ou ·implicitement·, avec laquelle on essaie de ·valider· l'une après l'autre chaque unité de la séquence doit pouvoir être identifiée sans avoir à examiner le contenu ou les attributs de chaque unité et sans avoir besoin de faire appel aux informations relatives aux autres unités du reste de la séquence.
Remarque : Cette contrainte est équivalente à celle de [XML 1.0 (Second Edition)] et SGML. Etant donné la présence de groupes de substitution d'élément et de caractères génériques, l'expression concise de cette contrainte est difficile, reportez-vous au chapitre Analyse de la contrainte d'attribution de particule unique (partie non-normative) (§H) pour plus d'informations.
Remarque : parce que la propriété {espace de noms cible} des déclarations d'éléments de portée locale est facultative, la portée des déclarations n'est pas utile pour imposer l'une quelconque des deux contraintes qui précèdent.

Les contraintes qui suivent définissent des relations qui sont utilisées ailleurs dans cette spécification.

Contraintes des composants de schéma : Nombre réel d'occurrences (connecteurs all et sequence)
Le nombre réel d'occurrences d'une particule dont le {terme} est un groupe dont le {connecteur} est all ou sequence est une paire constituée d'un minimum et d'un maximum, comme suit :
minimum
Le produit du {nombre d'occurrences minimum} de la particule et de la somme du {nombre d'occurrences minimum} de chaque particule de caractère générique ou de déclaration d'élément de l'ensemble des {particules} du groupe et de la partie minimum de la Nombre réel d'occurrences de chacune des particules de groupe de l'ensemble des {particules} du groupe (ou 0 si le lot de {particules} n'existe pas).
maximum
unbounded si le {nombre d'occurrences maximum} de chaque particule de caractère générique ou de déclaration d'élément de l'ensemble des {particules} du groupe ou si la partie maximum de la porté totale réelle de l'une quelconque des particules de groupe de l'ensemble des {particules} du groupe sont unbounded, ou si l'une d'entre elle est différente de zéro et que le {nombre d'occurrences maximum} de la particule elle-même est unbounded, sinon cette valeur est le produit du {nombre d'occurrences maximum} de la particule et de la somme du {nombre d'occurrences maximum} de chaque particule de caractère générique ou de déclaration d'élément de l'ensemble des {particules} du groupe et la partie maximum du nombre réel d'occurrences de chacune des particules de groupe de l'ensemble des {particules} du groupe (ou 0 si le lot de {particules} n'existe pas).
Contraintes des composants de schéma : Nombre réel d'occurrences (choice)
Le nombre réel d'occurrences d'une particule dont le {terme} est un groupe dont le {connecteur} est choice est une paire de valeurs minimum et maximum définies comme suit :
minimum
C'est le produit du {nombre d'occurrences minimum} de la particule et du minimum du {nombre d'occurrences minimum} de chaque particule de caractère générique ou de déclaration d'élément de l'ensemble des {particules} du groupe et la partie minimum du nombre réel d'occurrences de chaque particule de groupe de l'ensemble des {particules} du groupe (ou 0 si le lot {particules} n'existe pas).
maximum
unbounded si le {nombre d'occurrences maximum} de chaque particule de type caractère générique ou déclaration d'élément du lot de {particules} du groupe ou si la partie maximum du nombre réel d'occurrences de chacune des particules de groupe du lot de {particules} du groupe est unbounded, ou quand il y en a une différente de zéro et que le {nombre d'occurrences maximum} de la particule elle-même soit unbounded, sinon la valeur est celle du produit du {nombre d'occurrences maximum} de la particule et du maximum du {nombre d'occurrences maximum} de chaque particule de type caractère générique ou déclaration d'élément du lot de {particules} du groupe et la partie maximum du nombre réel d'occurrences de chacune des particules de groupe du lot de {particules} du groupe (ou 0 si le lot {particules} n'existe pas).

previous sub-section next sub-section 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.

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

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

<xs:any maxOccurs="unbounded"/>
     
Représentations XML qui impliquent toutes des particules, illustrant quelques unes des possibilités permettant de contrôler les occurrences.

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 :

Composant de schéma : Particule
{nombre d'occurrences minimum}
Un entier positif.
{nombre d'occurrences maximum}
Soit un entier positif soit la valeur unbounded.
{terme}
Un terme d'un groupe modèle ou un caractère générique ou une déclaration d'élément.

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}.

3.9.2 Représentation XML du composant de schéma de type particule

Les particules correspondent aux trois éléments (<element> et <group> quand ils sont utilisés directement sous <schema> et <any>) avec lesquels on peut utiliser les attributs minOccurs et maxOccurs. Ce qui, à son tour, correspond à deux composants dans chaque cas, une particule et son {terme}. Les correspondances sont respectivement décrites des chapitres Représentation XML du composant de schéma de déclaration d'élément (§3.3.2), Représentation XML des composants de schéma d'un groupe modèle (§3.8.2) et Représentation XML des composants de schéma pour les caractères génériques (§3.10.2).

3.9.3 Contraintes portant sur la représentation XML des particules

N'existe pas en tant que tel.

3.9.4 Règles de validation d'une particule

Règle de validation : Série d'éléments localement valide (particule)
Pour qu'une succession (qui est potentiellement vide) d'unités d'information de type élément soit localement ·valide· par rapport à une particule, l'un des cas suivants doit être vérifié :
1 Si le {terme} est un caractère générique, alors toutes les conditions suivantes doivent être remplies :
1.1 La longueur de la série doit être supérieure ou égale au {nombre d'occurrences minimum}.
1.2 Si le {nombre d'occurrences maximum} est un nombre, la longueur de la série doit être inférieure ou égale au {nombre d'occurrences maximum}.
1.3 Chaque unité d'information de type élément dans la série doit être ·valide· par rapport au caractère générique tel que cela est défini au chapitre Unité valide (caractère générique) (§3.10.4).
2 Si le {terme} est une déclaration d'élément, alors toutes les conditions suivantes doivent être remplies :
2.1 la longueur de la série doit être supérieure ou égale au {nombre d'occurrences minimum}.
2.2 Si le {nombre d'occurrences maximum} est un nombre, la longueur de la série doit être inférieure ou égale au {nombre d'occurrences maximum}.
2.3 Pour chaque unité d'information de type élément de la série l'une des conditions suivantes doit être vérifiée :
2.3.1 La déclaration d'élément est locale (c'est à dire que sa {portée} ne doit pas être global), elle n'est pas {abstraite}, le [nom de l'espace de noms] de l'unité d'information de type élément est identique à celui de {l'espace de noms cible} de la déclaration de l'élément (où ·l'absence· de {l'espace de noms cible} est considérée être identique à un [nom de l'espace de noms] sans valeur) et le [nom local] de l'unité d'information de type élément correspond au {nom} de la déclaration d'élément.

Dans ce cas, la déclaration d'élément est la ·déclaration contextuelle· de l'unité d'information de type élément par rapport à L'évaluation de la validité de schéma (élément) (§3.3.4) et au Résultat de l'évaluation (élément) (§3.3.5).
2.3.2 La déclaration d'élément est supérieure (c'est à dire que sa {portée} est global), elle n'est pas {abstrait}, le [nom de l'espace de noms] de l'unité d'information de type élément est identique à {l'espace de noms cible} de la déclaration d'élément (où une ·absence·de {l'espace de noms cible} est interprétée comme étant identique à un [nom de l'espace de noms] sans valeur) et le [nom local] de l'unité d'information de type élément correspond au {nom} de la déclaration d'élément.

Dans ce cas la déclaration d'élément est la ·déclaration contextuelle· pour l'unité d'information de type élément en ce qui concerne L'évaluation de la validité de schéma (élément) (§3.3.4) et le Résultat de l'évaluation (élément) (§3.3.5).
2.3.3 La déclaration d'élément est supérieure (c'est à dire que sa {portée} est global), son ensemble des {substitutions rejetées} ne contient pas substitution, le [nom local ] et le [nom de l'espace de noms] de l'unité d'information de type élément ramènent une déclaration d'élément, tel que défini dans Résolution de QName (instance) (§3.15.4) -- [Définition :]  cette déclaration est la déclaration de substitution et la ·déclaration de substitution· ainsi que les {substitutions rejetées} de la déclaration d'élément de la particule sont bien remplaçables pour la déclaration d'élément de la particule comme défini au chapitre Groupe de substitution correct (transitivité) (§3.3.6).
3 Si le {terme} est un groupe modèle, alors toutes les conditions suivantes doivent être remplies :
3.1 Il y a une ·partition· de la séquence en n sous-séries de sorte que n soit supérieur ou égal au {nombre d'occurrences minimum}.
3.2 Si le {nombre d'occurrences maximum} est un nombre, n doit être inférieur ou égal au {nombre d'occurrences maximum}.
3.3 Chaque sous-série de la ·partition· est ·valide· par rapport à ce groupe modèle comme défini dans le chapitre Série d'éléments valide (§3.8.4).
Remarque : Les clauses 1 et 2.3.3 n'inter-réagissent pas : une unité d'information de type élément validable par une déclaration ayant un groupe de substitution de tête dans un espace de noms différent n'est pas validable par un caractère générique qui reçoit l'espace de nom de tête mais pas le sien propre.

3.9.5 Contributions d'une particule à l'ensemble d'information

N'existe pas en tant que tel.

3.9.6 Contraintes portant sur le composant de schéma de type particule

Toutes les particules (référez-vous au chapitre Les particules (§3.9)) doivent satisfaire les contraintes suivantes.

Contraintes des composants de schéma : Particule juste
Toutes les conditions suivantes doivent être remplies :
1 Les valeurs des propriétés d'une particule doivent être telles que décrites dans le tableau des propriétés du chapitre Composant de schéma de type particule (§3.9.1), modulo l'impact des sous-composants manquant (§5.3).
2 Si le {nombre d'occurrences maximum} n'est pas unbounded, c'est à dire que c'est une valeur numérique, alors toutes les conditions suivantes doivent être remplies :
2.1 le {nombre d'occurrences minimum} ne doit pas être supérieur au {nombre d'occurrences maximum}.
2.2 le {nombre d'occurrences maximum} doit être supérieur ou égal à 1.

Les contraintes suivantes définissent des relations appelées ailleurs dans cette spécification.

Contraintes des composants de schéma : particule valide (extension)
[Définition :]  pour qu'une particule (qu'on appelle E, comme extension) soit une extension valide d'une autre particule (qu'on appelle B, comme base) l'une des conditions suivantes doit être vérifiée :
1 Il s'agit des mêmes particules.
2 Le {nombre d'occurrences minimum}={nombre d'occurrences maximum}=1 de E et son {terme} est un groupe de type sequence dont le premier membre de l'ensemble des {particules} est une particule dont toutes les propriétés, récursivement, sont identiques à celles de B, à l'exception des {annotations}.

L'approche que nous présentons ici pour définir un type par restriction d'un autre est conçue pour garantir que les types définis de cette manière forment un sous-ensemble du type qu'ils restreignent. Cela est accompli en requérant une mise en correspondance claire entre les composants de la définition d'un type de base et ceux de la version restreinte. Les mises en correspondance autorisées sont présentées ci-dessous via un ensemble de définitions récursives, en approfondissant les cas les plus évidents, par exemple le cas où une déclaration d'élément (restreinte) correspond à une autre déclaration d'élément (de base) ayant les mêmes nom et type mais avec le même ou un plus grand nombre d'occurrences.

Remarque : L'approche par les correspondances structurelles pour garantir la relation de sous-ensemble présentée ici est nécessairement verbeuse mais a l'avantage d'être contrôlable d'une manière directe. Le groupe de travaille sollicite vos retours sur les difficultés de la mise en pratique et sur comment d'autres approches pourraient être viables.
Contraintes des composants de schéma : particule valide (restriction)
[Définition :]  pour qu'une particule (on l'appelle R, comme restriction) soit une restriction valide d'une autre particule (on l'appelle B, comme base) l'une des conditions suivantes doit être vérifiée :
1 Il s'agit des mêmes particules.
2 en fonction du type de particule (cf le tableau ci-dessous) toutes les conditions suivantes doivent être respectées :
2.1 Toute particule de déclaration supérieure d'élément (dans R ou B) qui est un {groupe de substitution affilié} d'une ou plusieurs autres déclarations d'éléments est traitée comme si c'était un groupe de type choice dont le {nombre d'occurrences minimum} et le {nombre d'occurrences maximum} sont ceux de la particule et dont l'ensemble des {particules} consiste en une particule ayant un {nombre d'occurrences minimum} et un {nombre d'occurrences maximum} de 1 pour la déclaration supérieure d'élément et pour chacune des déclarations de son ·groupe de substitution·.
2.2 Toute les occurrences injustifiées de <séquence>, <choice> et <all> sont ignorées quand l'absence de justification est comprises comme suit :
<sequence>
L'une des conditions suivantes est remplie :
2.2.1 L'ensemble des {particules} est vide.
2.2.2 Toutes les conditions suivantes doivent être remplies :
2.2.2.1 La particule à l'intérieur de laquelle cette <sequence> apparaît a un {nombre d'occurrences maximum} et un {nombre d'occurrences minimum} of 1.
2.2.2.2 L'une des conditions suivantes doit être vérifiée :
2.2.2.2.1 L'ensemble des {particules} de <séquence> n'a qu'un seul membre.
2.2.2.2.2 La particule à l'intérieur de laquelle cette <séquence> apparaît est elle-même un élément de l'ensemble des {particules} d'une <séquence>.
<all>
L'une des conditions suivantes est remplie :
2.2.1 L'ensemble des {particules} est vide.
2.2.2 L'ensemble des {particules} n'a qu'un membre.
<choice>
L'une des conditions suivantes est remplie :
2.2.1 L'ensemble des {particules} est vide et la particule à l'intérieur de laquelle ce <choice> apparaît a un {nombre d'occurrences minimum} de 0.
2.2.2 Toutes les conditions suivantes sont remplies :
2.2.2.1 La particule à l'intérieur de laquelle ce <choice> apparaît a un {nombre d'occurrences maximum} et un {nombre d'occurrences minimum} de 1.
2.2.2.2 L'une des conditions suivantes est remplie :
2.2.2.2.1 L'ensemble des {particules} de <choice> n'a qu'un membre.
2.2.2.2.2 La particule à l'intérieur de laquelle ce <choice> apparaît est elle-même un élément de l'ensemble des {particules} d'un <choice>.
Particule de base
elt any all choice séquence
Particule dérivée elt NameAnd- TypeOK NSCompat Recurse- AsIfGroup Recurse- AsIfGroup RecurseAs- IfGroup
any Interdit NSSubset Interdit Interdit Interdit
all Interdit NSRecurse- CheckCardinality Recurse Interdit Interdit
choice Interdit NSRecurse- CheckCardinality Interdit RecurseLax Interdit
seq- uence Interdit NSRecurse- CheckCardinality Recurse- Unidered MapAndSum Recurse
Contraintes des composants de schéma : Série correcte d'occurrences
Pour que la série d'occurrences d'une particule soit une restriction valide d'une autre série d'occurrences toutes les conditions suivantes doivent être remplies :
1 Son {nombre d'occurrences minimum} est supérieur ou égal au {nombre d'occurrences minimum} de l'autre.
2 L'une des conditions suivantes doit être vérifiée :
2.1 Le {nombre d'occurrences maximum} de l'autre est égale à unbounded.
2.2 Les deux {nombres d'occurrences maximum} sont des chiffres et celui de la particule est inférieur ou égal à l'autre.
Contraintes des composants de schéma : Restriction correcte de particule (Elt:Elt -- NameAndTypeOK)
Pour que la particule d'une déclaration d'élément soit une ·restriction valide· de celle d'une autre déclaration d'élément toutes les conditions suivantes doivent être remplies :
1 Les {noms} et {espaces de noms cibles} des déclarations sont les mêmes.
2 Soit B est {annulable} soit R ne l'est pas.
3 La gamme d'occurrences de R est une restriction valide de la gamme d'occurrence de B comme défini au chapitre Gamme correcte d'occurrences (§3.9.6).
4 Soit la {contrainte de valeur} de la déclaration de B est ·absente·, soit elle n'est pas fixed, soit la {contrainte de valeur} de la déclaration de R est fixed avec la même valeur.
5 L'ensemble des {définitions de contrainte d'identité} de la déclaration de R est un sous-ensemble de celui de B, si ils existent.
6 L'ensemble des {substitutions rejetées} de la déclaration de R est un sur-ensemble de celui de B.
7 La {définition de type} de R est une dérivée valide étant donné l'ensemble {extension, list, union} de la {définition de type} de B comme cela est défini aux chapitres Dérivation correcte de type (complexe) (§3.4.6) et Dérivation correcte de type (simple) (§3.14.6), en fonction du cas approprié.
Remarque : La contrainte ci-dessus sur la {définition de type} signifie qu'en dérivant un type par restriction, toutes les définitions de types contenues doivent elles-mêmes être explicitement dérivées par restriction à partir des définitions de types correspondantes dans la définition de base.
Contraintes des composants de schéma : Dérivation correcte d'une particule (Elt:Any -- NSCompat)
Pour que la particule d'une déclaration d'élément soit une ·restriction valide· de celle d'un caractère générique toutes les conditions suivantes doivent être remplies :
1 {l'espace de noms cible} de la déclaration d'élément est ·valide· par rapport à la {contrainte d'espace de noms} du caractère générique comme défini au chapitre Noms d'espaces de noms autorisés par les caractères génériques(§3.10.4).
2 La gamme des occurrences de R est une restriction valide of celle de B comme cela est défini au chapitre Gamme correcte d'occurrences (§3.9.6).
Contraintes des composants de schéma : Dérivation correcte d'une particule (Elt:All/Choice/Sequence -- RecurseAsIfGroup)
Pour que la particule d'une déclaration d'élément soit une ·restriction valide· d'une particule de groupe (all, choice ou sequence) une particule de groupe de la variété correspondant à celle de B, ayant le {nombre d'occurrences minimum} et le {nombre d'occurrences maximum} égaux à 1 et l'ensemble des {particules} réduit à une seule particule, la même que celle de la déclaration d'élément, doit être une ·restriction valide· du groupe comme cela est défini aux chapitres Dérivation correcte d'une particule (All:All,Sequence:Sequence -- Recurse) (§3.9.6), Dérivation correcte d'une particule (Choice:Choice -- RecurseLax) (§3.9.6) et Dérivation correcte d'une particule (All:All,Sequence:Sequence -- Recurse) (§3.9.6), en fonction de la nature du groupe : all, choice ou séquence.
Contraintes des composants de schéma : Dérivation correcte d'une particule (Any:Any -- NSSubset)
Pour que la particule d'un caractère générique soit une ·restriction valide· de celle d'un autre caractère générique toutes les conditions suivantes doivent être remplies :
1 La gamme des occurrences de R doit être une restriction valide de celle de B tel que cela est défini au chapitre Gamme correcte d'occurrences (§3.9.6).
2 La {contrainte d'espace de noms} de R doit être un sous-ensemble de la {contrainte d'espace de noms} de B tel que cela est défini au chapitre Sous-ensemble du caractère générique (§3.10.6).
Contraintes des composants de schéma : Dérivation correcte d'une particule (All/Choice/Sequence:Any -- NSRecurseCheckCardinality)
Pour qu'une particule de groupe soit une ·restriction valide· de celle d'un caractère générique toutes les conditions suivantes doivent être remplies :
1 Chaque membre de l'ensemble des {particules} du groupe est une ·restriction valide· du caractère générique tel que cela est défini au chapitre Particule valide (restriction) (§3.9.6).
2 Le nombre réel d'occurrences du groupe, telle qu'elle est définie aux chapitres Nombre réel d'occurrences (all et sequence) (§3.8.6) (si le groupe est all ou sequence) et Nombre réel d'occurrences (choice) (§3.8.6) (si c'est un groupe de type choice) est une restriction valide du nombre des occurrences autorisées de B tel que cela est défini au chapitre Gamme correcte d'occurrences (§3.9.6).
Contraintes des composants de schéma : Dérivation correcte d'une particule (All:All,Sequence:Sequence -- Recurse)
Pour qu'une particule d'un groupe all ou sequence soit une ·restriction valide· d'une autre particule de groupe ayant le même {connecteur} toutes les conditions suivantes doivent être remplies :
1 Le nombre des occurrences autorisées de R est une restriction valide de celui de B tel que cela est défini au chapitre Gamme correcte d'occurrences (§3.9.6).
2 Il y a une correspondance fonctionnelle de ·conservation de l'ordre· totale entre les particules de l'ensemble des {particules} de R et celles de l'ensemble des {particules} de B de manière à ce que toutes les conditions suivantes soient vérifiées :
2.1 Chaque particule de l'ensemble des {particules} de R est une ·restriction valide· de la particule de l'ensemble des {particules} de B à laquelle elle correspond tel que cela est défini au chapitre Particule valide (restriction) (§3.9.6).
2.2 Toutes les particules de l'ensemble des {particules} de B qui ne sont pas mises en correspondance avec une particule de l'ensemble des {particules} de R sont ·vidables· tel que cela est défini au chapitre Particule pouvant être vide (§3.9.6).
Remarque : Bien que la ·validation· sémantique d'un groupe de type all ne dépende pas de l'ordre de ses particules, les groupes de type all dérivés sont contraints de faire correspondre l'ordre de leur base afin de simplifier le contrôle de validité de la dérivation.
[Définition :]  Une mise en correspondance fonctionnelle totale est conservatrice de l'ordre si chaque particule r de l'ensemble R correspond à une particule b de la série B qui suit (sans nécessairement que ce soit le suivant immédiat) la particule de la gamme B en relation avec le prédécesseur de r, si il existe, où "prédécesseur" et "suivant" sont définis en référence à l'ordre des listes qui forment R et B.
Contraintes des composants de schéma : Dérivation correcte d'une particule (Choice:Choice -- RecurseLax)
Pour que la particule d'un groupe de type choice soit une ·restriction valide· de la particule d'un autre groupe du même type toutes les conditions suivantes doivent être remplies :
1 Le nombre des occurrences autorisées de R est une restriction valide de celui de B tel que cela est défini au chapitre Gamme correcte d'occurrences (§3.9.6);
2 Il y a ·conservation totale de l'ordre· dans la correspondance fonctionnelle entre les particules de l'ensemble des {particules} de R et celui de B de sorte que chaque particule de l'ensemble des {particules} de R soit une ·restriction valide· de la particule de l'ensemble des {particules} de B à laquelle elle correspond comme cela est défini au chapitre Particule valide (restriction) (§3.9.6).
Remarque : Bien que la ·validation· sémantique d'un groupe de type choice ne dépende pas de l'ordre de ses particules, les groupes de type choice dérivés sont priés d'avoir le même ordre que celui de leur groupe de base afin de simplifier le contrôle de la justesse de la dérivation.
Contraintes des composants de schéma : Dérivation correcte d'une particule (Sequence:All -- RecurseUnidered)
Pour que la particule d'un groupe de type sequence soit une ·restriction valide· de celle d'un groupe de type all toutes les conditions suivantes doivent être remplies :
1 La gamme des occurrences de R est une restriction valide de celle de B comme cela est défini au chapitre Gamme correcte d'occurrences (§3.9.6).
2 Il y a une correspondance fonctionnelle totale entre les particules de l'ensemble des {particules} de R et celles de l'ensemble des {particules} de B de sorte que toutes les conditions suivantes soient vérifiées :
2.1 Aucune particule de l'ensemble des {particules} de B est en correspondance avec plus d'une particule de l'ensemble des {particules} de R ;
2.2 Chaque particule de l'ensemble des {particules} de R est une ·restriction valide· de la particule de l'ensemble des {particules} de B à laquelle elle correspond comme cela est défini au chapitre Particule valide (restriction) (§3.9.6);
2.3 Toutes les particules de l'ensemble des {particules} de B qui ne sont pas mises en correspondance avec une quelconque particule de l'ensemble des {particules} de R sont ·vidables· comme cela est défini au chapitre Particule pouvant être vide (§3.9.6).
Remarque :Bien que cette clause autorise le réordonnancement, à cause des limites sur les contenus des groupes de type all le processus de validation peut quand même être déterministe.
Contraintes des composants de schéma : Dérivation correcte d'une particule (Sequence:Choice -- MapAndSum)
Pour que la particule d'un groupe de type sequence soit une ·restriction valide· de celle d'un groupe de type choice toutes les conditions suivantes doivent être remplies :
1 Il y a une relation fonctionnelle totale entre les particules de l'ensemble des {particules} de R et celles de l'ensemble des {particules} de B de sorte que chaque particule de l'ensemble des {particules} de R soit une ·restriction valide· de la particule de l'ensemble des {particules} de B qui lui correspond comme cela est défini au chapitre Particule valide (restriction) (§3.9.6).
2 Le couple constitué du produit du {nombre d'occurrences minimum} de R et de la longueur de son ensemble de {particules} et unbounded si le {nombre d'occurrences maximum} est unbounded ou sinon le produit du {nombre d'occurrences maximum} de R et de la longueur de son ensemble de {particules} doit être une restriction valide du nombre des occurrences autorisées de B comme cela est défini au chapitre Gamme correcte d'occurrences (§3.9.6).
Remarque : Cette clause est, en principe, plus restrictive que absolument nécessaire, mais en pratique couvrira tous les cas souhaités et est plus facile à spécifier que la version totalement générale.
Remarque : Ce cas permet le déroulement séquentiel des séquences itérées de type "ou" (choice). Cela peut être particulièrement pratique quand le "ou" est de type implicite, provoquée par l'utilisation d'un groupe de substitutions.
Contraintes des composants de schéma : Particule pouvant être vide
[Définition :]  pour qu'une particule soit vidable les conditions suivantes doivent être respectées :
2 Son {terme} est un groupe et la partie minimum du nombre réel d'occurrences de ce groupe, comme cela est défini aux chapitres Nombre réel d'occurrences (all et sequence) (§3.8.6) (si le groupe est de type all ou sequence) et Nombre réel d'occurrences (choice) (§3.8.6) (si c'est un type choice), est 0.

previous sub-section next sub-section 3.10 Caractères génériques

Afin d'exploiter pleinement le potentiel d'extensibilité offert par XML et les espaces de noms, il faut offrir plus de possibilités que ce que les DTD permettent de faire pour la flexibilité des modèles de contenus et des déclarations d'attributs. Un caractère générique permet de réaliser des ·validations· d'unités d'information de type élément et attribut qui dépendent de leur nom d'espace de noms, cela restant indépendant de leur nom local.

Exemple
<xs:any processContents="skip"/>

<xs:any namespace="##other" processContents="lax"/>

<xs:any namespace="http://www.w3.org/1999/XSL/Transform"/>

<xs:any namespace="##targetNamespace"/>

<xs:anyAttribute namespace="http://www.w3.org/XML/1998/namespace"/>
Représentations XML des quatre types de caractères génériques de base plus un attribut générique.

3.10.1 Le composant de schéma d'un caractère générique

Le composant de schéma d'un caractère générique a les propriétés suivantes :

Composant de schéma : Caractère générique
{contrainte d'espace de noms}
L'une des valeurs suivantes : any; une paire composée de not et d'un nom d'espace de noms ou ·absent·, ou un ensemble dont les membres sont soit des noms d'espaces de noms soit ·absents·.
{type de validation}
La propriété prend l'une des valeurs skip, lax ou strict.
{annotation}
Facultatif. Une annotation.

La {contrainte d'espace de noms} permet la ·validation· des unités de type élément et attribut qui :

  1. (any) ont n'importe quel espace de noms ou ne sont pas qualifiées ;
  2. (not et un nom d'espace de noms) ont n'importe quel espace de noms autre que celui spécifié ou ne sont pas qualifiées ;
  3. (not et ·absent·) sont qualifiées par un espace de noms ;
  4. (un ensemble dont les membres sont soit des noms d'espaces de noms ou sont ·absents·) ont n'importe lequel des espaces de noms spécifiés et/ou, cas où ·l'absence· est utilisée dans l'ensemble, sont non qualifiées.

Le {type de validation} permet de contrôler l'impact sur ·l'évaluation· des unités d'information autorisées par les caractères génériques, de la manière suivante :

strict
Soit une déclaration supérieure est disponible pour l'unité soit l'unité a un attribut de typage xsi:type, et l'unité doit être ·valide· dans les deux cas de figure.
skip
Aucune contrainte du tout : l'unité doit simplement être bien-formée XML.
lax
Si l'unité, ou n'importe laquelle de ses unités [enfants] si l'unité est du type élément, a une déclaration unique parfaitement identifiée, elle doit être ·valide· par rapport à cette définition, c'est à dire, ·validée· là où vous le pouvez, mais c'est sinon sans conséquence quand ce n'est pas possible.

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

3.10.2 Représentation XML des composants de schéma pour les caractères génériques

La représentation XML du composant de schéma pour un caractère générique sont les unités d'information de type élément <any> ou <anyAttribute> . Les correspondances entre les propriétés de l'unité d'information <any> et celles des composants qui lui correspondent sont les suivantes (référez-vous à <complexType> et <attributeGroup> pour plus d'informations sur les correspondances pour <anyAttribute>) :

Vue synthétique de la représentation XML :Unité d'information de type élément any 

<any
  id = ID
  maxOccurs = (nonNegativeInteger | unbounded)  : 1
  minOccurs = nonNegativeInteger : 1
  namespace = ((##any | ##other) | List of (anyURI | (##targetNamespace | ##local)) )  : ##any
  processContents = (lax | skip | strict) : strict
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?)
</any>

Une particule contenant un caractère générique, ayant les propriétés suivantes (sauf si minOccurs=maxOccurs=0, auquel cas l'unité correspond à aucun composant du tout) :
Composant de schéma : Particule
Propriété Représentation
{nombre d'occurrences minimum} La ·valeur réelle· de [l'attribut] minOccurs, si il est présent, sinon vaut 1.
{nombre d'occurrences maximum} unbounded, si [l'attribut] maxOccurs est égal à unbounded, sinon la ·valeur réelle· de [l'attribut] maxOccurs, si il est présent, sinon vaut 1.
{terme} Un caractère générique comme donné ci-dessous :
Composant de schéma : Caractère générique
Propriété Représentation
{contrainte d'espace de noms} Dépendant de la ·valeur réelle· de [l'attribut] namespace: si cet attribut est absent, alors la valeur est any, sinon elle est déterminée comme suit :
##any
any
##other
une paire constitué du mot clé not et de la ·valeur réelle· de [l'attribut] targetNamespace de l'unité d'information ascendante de type élément <schema> si elle est présente, sinon cette valeur est ·absente·.
Sinon
un ensemble dont les membres sont des noms d'espaces de noms séparés par les délimiteurs espace des chaînes de caractères, sauf :
1 si la sous-chaîne ##targetNamespace est utilisée, le membre correspondant est la ·valeur réelle· de [l'attribut] targetNamespace de l'unité d'information ascendant de type élément <schema> si elle est présente, sinon cette valeur est ·absente·.
2 si la sous-chaîne ##local est utilisée, le membre correspondant est ·absent·.
{type de validation} La ·valeur réelle· de [l'attribut] processContents, si il est présent, sinon la valeur est strict.
{annotation} L'annotation correspondant à l'unité d'information [enfants] de type élément <annotation> , si il y en a, sinon cette propriété est ·absente·.

Les caractères génériques sont sujets aux mêmes contraintes d'ambiguïté (Attribution de particule unique (§3.8.6)) que les autres particules du modèle de contenu : Si, à l'intérieur du modèle de contenu d'un type, un élément instance peut simultanément correspondre soit à une particule explicite et un caractère générique soit à un caractère générique parmi deux, alors cela signifie que ce modèle est faux.

3.10.3 Contraintes portant sur la représentation XML des caractères génériques

Contraintes de représentation des schémas : Représentation correcte des caractères génériques
En plus des conditions imposées sur les unités d'information de type élément <any> par le schéma des schémas, la particule et le groupe modèle correspondants doivent satisfaire aux conditions exposées aux chapitres Contraintes sur les composants de schéma d'un groupe modèle (§3.8.6) et Contraintes portant sur le composant de schéma de type particule (§3.9.6).

3.10.4 Règles de validation des caractères génériques

Règle de validation : Unité valide (caractère générique)
Pour qu'un élément ou une unité d'information de type attribut soient localement ·valides· par rapport à une contrainte de caractère générique leurs [noms d'espaces de noms] doivent être ·valides· par rapport à la contrainte du caractère générique comme cela est défini au chapitre Noms d'espaces de noms autorisés par les caractères génériques(§3.10.4).

Quand cette contrainte s'applique, l'un des cas suivants doit être vérifié :
Règle de validation : Noms d'espaces de noms autorisés par le caractère générique
Pour qu'un nom d'espace de noms ou son ·absence· soient ·valides· par rapport à une contrainte fournie par un caractère générique (la valeur de la {contrainte d'espace de noms}) l'une des conditions suivantes doit être vérifiée :
1 La contrainte doit être any.
2 Toutes les conditions suivantes doivent être remplies :
2.1 La contrainte est un couple constitué de not et d'un nom d'espace de noms ou ·absent· ([Définition :]  on l'appelle le test d'espace de noms).
2.2 La valeur ne doit pas être identique au ·test d'espace de noms ·.
2.3 La valeur ne doit pas être ·absente·.
3 La contrainte est un ensemble et la valeur est identique à l'un des membres de l'ensemble.

3.10.5 Contributions des caractères génériques à l'ensemble d'information

N'existe pas en tant que tel.

3.10.6 Contraintes sur les composants de schéma des caractères génériques

Tous les caractères génériques (référez-vous au chapitre Caractères génériques (§3.10)) doivent satisfaire à la contrainte suivante.

Contrainte des composants de schéma : Exactitudes des propriétés des caractères génériques
Les valeurs des propriétés d'un caractère générique doivent être telles que décrites dans le tableau des propriétés du chapitre Composant de schéma d'un caractère générique (§3.10.1), modulo l'impact des sous-composants manquant (§5.3).

Les contraintes suivantes définissent une relation utilisée ailleurs dans cette spécification.

Contraintes des composants de schéma : Sous-ensemble du caractère générique
Pour qu'une contrainte d'espace de noms (on l'appellera sub) soit un sous-ensemble de celle d'un autre espace de noms (qu'on appellera super) l'une des conditions suivantes doit être vérifiée :
1 super doit être any.
2 Toutes les conditions suivantes doivent être remplies :
2.1 sub doit être une paire composée de not et d'un nom d'espace de noms qui peut être ·absent·.
2.2 super doit être une paire composée de not et de la même valeur.
3 Toutes les conditions suivantes doivent être remplies :
3.1 sub doit être un ensemble dont les membres sont des noms d'espaces de noms qui peuvent être ·absents·.
3.2 L'une des conditions suivantes doit être vérifiée :
3.2.1 super doit être le même ensemble ou en être un sur-ensemble.
3.2.2 super doit être une paire composée de not et d'un nom d'espace de noms qui peut être ·absent· et cette valeur ne doit pas être dans l'ensemble de sub.
Contraintes des composants de schéma : Union d'attributs génériques
Pour que la valeur d'une {contrainte d'espace de noms} d'un caractère générique soit l'union de deux autres valeurs du même genre (appelons les O1 et O2) : un des cas suivants doit être vérifié :
1 Si O1 et O2 sont la même valeur, alors la valeur de l'union est cette valeur.
2 Si l'une des deux valeurs O1 ou O2 a pour valeur any, alors any est la valeur de l'union.
3 Si les deux valeurs O1 et O2 sont des ensembles constitués de noms d'espaces de noms qui peuvent être ·absents·, alors la valeur de l'union est celle de la réunion des deux ensembles.
4 Si les deux sont des négations de différents noms d'espaces de noms, alors l'intersection n'est pas exprimable.
5 Si soit O1 soit O2 est une paire composée de not et d'un nom d'espace de noms et que l'autre est un ensemble composé de noms d'espaces de noms qui peuvent être ·absents·, alors l'un des cas suivants doit être vérifié :
5.1 Si l'ensemble inclut le nom de l'espace de noms exclu, alors any doit être la valeur de l'union.
5.2 Si l'ensemble n'inclut pas le nom de l'espace de noms exclu, alors la valeur de l'union est celle de celui de O1 et O2 qui est composé de not et d'un nom d'espace de noms.
Dans le cas où il y a plus de deux valeurs, l'intersection est déterminée en identifiant successivement l'intersection des valeurs prises deux à deux comme ci-dessus (en supposant que les unions successives sont exprimables).
Contraintes des composants de schéma : Intersection d'attributs génériques
Pour que la valeur d'une {contrainte d'espace de noms} d'un caractère générique soit l'intersection intentionnelle de deux valeurs du même genre (nous les appelons O1 et O2) : l'un des cas suivants doit être vérifié :
1 Si O1 et O2 représentent la même valeur, alors la valeur résultante est cette valeur.
2 Si l'une des deux valeurs O1 ou O2 vaut any, alors la valeur résultante est l'autre.
3 Si l'une des deux valeurs O1 ou O2 est une paire composée de not et d'un nom d'espace de noms et que l'autre soit un ensemble composé de noms d'espaces de noms qui peuvent être ·absents·, alors la valeur résultante est cet ensemble, diminué du nom de l'espace de noms exclu si cet ensemble le contenait.
4 Si les deux valeurs O1 et O2 sont des ensembles constitués de noms d'espaces de noms qui peuvent être ·absents·, alors la valeur résultante est l'intersection de ces ensembles.
5 Si les deux sont des exclusions de plusieurs noms d'espaces de noms, alors l'intersection de ces ensembles ne peut pas être exprimée.
Dans le cas où il y a plus de deux valeurs, l'intersection est déterminé en identifiant les intersections successives des valeurs prises deux à deux comme ci-dessus (en supposant que les unoins successives sont exprimables).

previous sub-section next sub-section 3.11 Définition de la contrainte d'identité

Les composants de définition de la contrainte d'identité offrent la possibilité d'exprimer des contraintes d'unicité et de référencement par rapport au contenu de plusieurs éléments et attributs.

Exemple
<xs:key name="fullName">
 <xs:selector xpath=".//person"/>
 <xs:field xpath="forename"/>
 <xs:field xpath="surname"/>
</xs:key>

<xs:keyref name="personRef" refer="fullName">
 <xs:selector xpath=".//personPointer"/>
 <xs:field xpath="@first"/>
 <xs:field xpath="@last"/>
</xs:keyref>

<xs:unique name="nearlyID">
 <xs:selector xpath=".//*"/>
 <xs:field xpath="@id"/>
</xs:unique>
Représentations XML des trois définitions des contraintes d'identité.

3.11.1 Le composant de schéma de définition de la contrainte d'identité

Le composant de schéma de définition de la contrainte d'identité a les propriétés suivantes :

{nom}
Un NCName comme cela est défini dans [XML-Namespaces].
{espace de noms cible}
Soit cette propriété est ·absente· soit c'est un nom d'espace de noms, tel que défini dans [XML-Namespaces].
{catégorie de la contrainte d'identité}
L'une des valeurs key, keyref ou unique.
{sélecteur}
Une forme restreinte d'une expression XPath ([XPath]).
{champs}
Un ensemble non-vide de formes restreintes d'expressions XPath ([XPath]).
{clé référencée}
Obligatoire si la {catégorie de la contrainte d'identité} est keyref, si non, cette propriété est interdite. La valeur est une définition de contrainte d'identité qui aurait comme {catégorie de la contrainte d'identité} l'une des deux valeurs key ou unique.
{annotation}
Facultatif. Une annotation.

Les définitions de contraintes d'identité sont identifiées par leur {nom} et leur {espace de noms cible} ; les identités des définitions des contraintes d'identité doivent être uniques à l'intérieur d'un ·schéma XML·. Reportez-vous au chapitre Références aux composants de schéma au travers des espaces de noms (§4.2.3) pour avoir des informations détaillées sur le traitement des identifiants de composants quand un schéma est importé dans un autre.

De manière informelle, la {catégorie de la contrainte d'identité} fixe le rôle joué par la contrainte d'identité :

Ces contraintes sont spécifiées parallèlement aux spécifications qui portent, de leur côté, sur les types des attributs et des éléments concernés, c'est à dire que quelque chose qui est déclaré comme étant du type 'nombre entier' peut aussi servir de clé. Chaque déclaration de contrainte a un nom, qui existe dans un seul et même espace de symboles réservé aux contraintes. Les conditions d'égalité ou d'inégalité qu'on utilise pour le contrôle de ces contraintes s'appliquent aux valeurs des champs sélectionnés, de sorte que, par exemple, 3.0 et 3 seraient des clés conflictuelles si elles étaient toutes les deux des nombres, mais ne sont pas conflictuelles si ce sont des chaînes de caractères, ou si l'une était une chaîne de caractères et l'autre un nombre. Les valeurs de types différents peuvent seulement être égales quand un type est dérivé de l'autre et que la valeur comparée se trouve dans l'espace commun aux deux.

Les compléments au mécanisme des ID/IDREF de XML sont :

Le {sélecteur} sert à spécifier une forme restreinte d'expression XPath ([XPath]) relative aux instances de l'élément déclaré. Il permet d'isoler l'ensemble des noeuds éléments subordonnés (c'est à dire contenu à l'intérieur de l'élément déclaré) sur lesquels s'applique la contrainte.

L'ensemble des {champs} sert à spécifier des expressions XPath qui vont s'appliquer relativement aux éléments isolés par le {sélecteur}. Cela permet d'identifier un seul noeud (de type élément ou attribut) dont le contenu ou la valeur, obligatoirement de type simple, est utilisé dans la contrainte. Il est possible de spécifier une liste ordonnée d'ensembles de {champs}, afin de pouvoir traiter le cas des clés, références de clés et contraintes d'unicité multivaluées.

Afin de réduire les difficultés de mise en oeuvre, en particulier celles des programmes de traitement de données en flot continu, seul un sous-ensemble des expressions XPath est autorisé pour les {sélecteurs} et les {champs}. Les détails sont donnés au chapitre Contraintes du composant de schéma de définition de la contrainte d'identité (§3.11.6).

Remarque : La provision fonctionnelle relative aux champs multivalués mentionnée va au delà de ce qui est supporté avec xsl:key.

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

3.11.2 Représentation XML du composant de schéma de définition de la contrainte d'identité

La représentation XML du composant de schéma de définition de la contrainte d'identité est une unité d'information de type élément qui est <key>, <keyref> ou <unique>. Les correspondances entre les propriétés de ces unités d'information et celles du composant auquel elles correspondent sont les suivantes :

Vue synthétique de la représentation XML : Unité d'information de type élément unique 

<unique
  id = ID
  name = NCName
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?, (selector, field+))
</unique>

<key
  id = ID
  name = NCName
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?, (selector, field+))
</key>

<keyref
  id = ID
  name = NCName
  refer = QName
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?, (selector, field+))
</keyref>

<selector
  id = ID
  xpath = un sous-ensemble d'expressions XPath, reportez-vous au chapitre ci-dessous
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?)
</selector>

<field
  id = ID
  xpath = un sous-ensemble d'expressions XPath, reportez-vous au chapitre ci-dessous
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?)
</field>

Composant de schéma : Définition de la contrainte d'identité
Propriété Représentation
{nom} La ·valeur réelle· de [l'attribut] name
{espace de noms cible} La ·valeur réelle· de ['attribut] targetNamespace de l'unité d'information parent de type élément schema.
{catégorie de la contrainte d'identité} L'une des valeurs key, keyref ou unique, en fonction de l'unité choisie.
{sélecteur} Une expression XPath restreinte correspondant à la ·valeur réelle· de [l'attribut] xpath de l'unité d'information [enfant] de type élément <selector>
{champs} Un ensemble d'expressions XPath restreintes correspondant aux ·valeurs réelles· des [attributs] xpath des unités d'information [enfants] de type élément <field>, dans l'ordre.
{clé référencée} Si l'unité est de type <keyref>, c'est la valeur de la définition de la contrainte d'identité ·ramenée· par la ·valeur réelle· de [l'attribut] refer, sinon cette propriété est ·absente·.
{annotation} L'annotation correspondant à unité d'information [enfant] de type élément <annotation>, quand il y en a, sinon cette propriété est ·absente·.
Exemple
<xs:element name="vehicle">
 <xs:complexType>
  . . .
  <xs:attribute name="plateNumber" type="xs:integer"/>
  <xs:attribute name="state" type="deuxLetterCode"/>
 </xs:complexType>
</xs:element>

<xs:element name="state">
 <xs:complexType>
  <xs:sequence>
   <xs:element name="code" type="deuxLetterCode"/>
   <xs:element ref="vehicle" maxOccurs="unbounded"/>
   <xs:element ref="person" maxOccurs="unbounded"/>
  </xs:sequence>
 </xs:complexType>

 <xs:key name="reg">
<!-- les véhicules sont reconnus par leur
            plaque à l'intérieur des Etats Unis -->
  <xs:selector xpath=".//vehicle"/>
  <xs:field xpath="@plateNumber"/>
 </xs:key>
</xs:element>

<xs:element name="root">
 <xs:complexType>
  <xs:sequence>
   . . .
   <xs:element ref="state" maxOccurs="unbounded"/>
   . . .
  </xs:sequence>
 </xs:complexType>

 <xs:key name="state"> <!-- La clé des Etats est leur code -->
  <xs:selector xpath=".//state"/>
  <xs:field xpath="code"/>
 </xs:key>

 <xs:keyref name="vehicleState" refer="state">
  <!-- tout véhicule se réfère à son Etat -->
  <xs:selector xpath=".//vehicle"/>
  <xs:field xpath="@state"/>
 </xs:keyref>

 <xs:key name="regKey">
<!-- La clé des véhicules est une paire composée de l'Etat et de la plaque -->
  <xs:selector xpath=".//vehicle"/>
  <xs:field xpath="@state"/>
  <xs:field xpath="@plateNumber"/>
 </xs:key>

 <xs:keyref name="carRef" refer="regKey">
<!-- les voitures des gens forment une référence -->
  <xs:selector xpath=".//car"/>
  <xs:field xpath="@regState"/>
  <xs:field xpath="@regPlate"/>
 </xs:keyref>

</xs:element>

<xs:element name="person">
 <xs:complexType>
  <xs:sequence>
   . . .
   <xs:element name="car">
    <xs:complexType>
     <xs:attribute name="regState" type="deuxLetterCode"/>
     <xs:attribute name="regPlate" type="xs:integer"/>
    </xs:complexType>
   </xs:element>
  </xs:sequence>
 </xs:complexType>
</xs:element>
Un élément state est défini, qui contient un enfant code et plusieurs enfants vehicle et person. Un vehicle, à son tour, a un numéro minéralogique plateNumber en attribut qui est un entier ainsi qu'un attribut state pour l'Etat. Les codes d'Etat servent de clés aux Etats à l'intérieur du document. Le numéro minéralogique des véhicules (l'attribut plateNumber) servent de clé à l'intérieur des Etats et state et plateNumber sont définis comme étant des clés pour les vehicles dans tout le document. De plus, un élément person a un enfant qui s'appelle car, de type vide, et porteur des attributs regState et regPlate, qui sont alors considérés comme faisant ensemble référence aux vehicles via la contrainte carRef. La condition de correspondance entre la valeur de l'attribut state d'un véhicule est celle de l'élément code de la balise state ne peut pas être exprimée ici.

3.11.3 Contraintes portant sur la représentation XML de définition de la contrainte d'identité

Contraintes de représentation des schémas : Représentation correcte d'une définition de contrainte d'identité
En plus des conditions imposées sur les unités d'information de type élément <key>, <keyref> et <unique> par le schéma des schémas, la définition de la contrainte d'identité correspondante à chaque cas doit satisfaire aux conditions exposées au chapitre Contraintes du composant de schéma de définition de la contrainte d'identité (§3.11.6).

3.11.4 Règles de validation de la définition de la contrainte d'identité

Règle de validation : Contrainte d'identité satisfaite
Pour qu'une unité d'information de type élément soit localement ·valide· par rapport à la contrainte d'identité, toutes les conditions suivantes doivent être remplies :
1 Le {sélecteur}, ayant l'unité d'information de type élément comme noeud contextuel, se ramène à un ensemble de noeuds (tel que défini dans [XPath]). [Définition :]  cela est appelé ensemble des noeuds cibles.
2 Chaque noeud de ·l'ensemble des noeuds cibles· est un noeud d'élément parmi les descendants du noeud contextuel.
3 Pour chaque noeud de ·l'ensemble des noeuds cibles· tous les ensembles de {champs} ayant ce noeud comme noeud contextuel se ramènent soit à un ensemble de noeuds vide soit à un ensemble de noeuds ayant un seul membre, obligatoirement de type simple. [Définition :]  la séquence des valeurs de type déterminé (tel que défini dans [XML Schema tome 2 : Types de données]) de la [valeur normalisée par le schéma] des unités d'information de type attribut et/ou élément de ces ensembles ordonnés de noeuds s'appelle la séquence clé du noeud.
4 [Définition :]  Le sous-ensemble de ·l'ensemble des noeuds cibles· pour lequel tous les ensembles de {champs} se ramènent à un singleton composé d'un noeud d'élément ou d'attribut de type simple s'appelle ensemble des noeuds qualifiés. L'un des cas suivants doit être vérifié :
4.1 Si la {catégorie de la contrainte d'identité} est unique, alors aucun des membres de ·l'ensemble des noeuds qualifiés· ont des ·séquences clés· dont les membres sont égaux deux par deux, au sens de l'égalité telle que définie au chapitre Egalité dans [XML Schema tome 2 : Types de données].
4.2 Si la {catégorie de la contrainte d'identité} est key, alors toutes les conditions suivantes doivent être remplies :
4.2.2 Aucun des membres de ·l'ensemble des noeuds qualifiés· pris deux à deux ont des ·séquences clés· dont les membres sont égaux par paire, comme cela est défini au chapitre Egalité in [XML Schema tome 2 : Types de données].
4.2.3 Aucun élément membre de la ·séquence clé· de l'un quelconque des membres de ·l'ensemble des noeuds qualifiés· n'a été évalué comme étant ·valide· par rapport à une déclaration d'élément {annulable}.
4.3 Si la {catégorie de la contrainte d'identité} est keyref, alors pour chaque membre de ·l'ensemble des noeuds qualifiés· (on l'appellera membre des clés de référence), il doit y avoir une ·table des noeuds· associée à la {clé référencée} dans la [table des contraintes d'identité] de l'unité d'information de type élément (référez-vous au chapitre Table des contraintes d'identité (§3.11.5), qui doit être vue comme logiquement prioritaire par rapport à la clause de cette contrainte, voir ci-après) et il doit y avoir une entrée dans cette table pour laquelle la ·séquence clé· est égale au membre de la ·séquence clé· du membre des clés de référence, comme cela est défini au chapitre Egalité dans [XML Schema tome 2 : Types de données].
Remarque : L'utilisation de la [valeur normalisée par le schéma] dans la définition de la ·séquence clé· ci-dessus signifie que les valeurs de contrainte default et fixed peuvent jouer un rôle dans les ·séquences clés·.
Remarque : Bien que cette spécification définisse une contribution à l'ensemble d'information résultant de la validation de schéma qui pourrait permettre aux programmes de traitement concernés par les schémas de mettre en pratique la clause 4.2.3 vue ci-dessus au chapitre Déclaration d'élément (§3.3.5), ceux-là ne sont pas obligés de la produire. Cette clause peut être interprétée comme si, en l'absence de contribution à l'ensemble d'information, la valeur {d'annulation} appropriée doit être disponible.

3.11.5 Contributions de la définition de la contrainte d'identité à l'ensemble d'information

Contribution à l'ensemble d'information du schéma : table des contraintes d'identité
[Définition :]  Une contrainte d'identité éligible d'une unité d'information de type élément est telle que les clauses 4.1 ou 4.2 du chapitre Contrainte d'identité satisfaite (§3.11.4) sont vérifiées par rapport à cette unité et cette contrainte, ou est telle que n'impote laquelle des unités d'information [enfants] de type élément de cette unité a une [table des contraintes d'identité] ayant une entrée pour cette contrainte.

[Définition :]  Une table des noeuds est un ensemble de paires composées d'une ·séquence clé· et d'un noeud élément.

Chaque fois qu'une unité d'information de type élément a une ou plusieurs ·contraintes d'identité éligibles·, alors elle aura, dans l'ensemble d'information résultant de la validation de schéma, la propriété suivante :
Contributions à l'ensemble d'information issu de la validité de schéma des unités d'information de type élément
[table des contraintes d'identité]
Une unité d'information de type relation de contrainte d'identité pour chaque ·contrainte d'identité éligible·, ayant les propriétés suivantes :
Contributions à l'ensemble d'information issu de la validité de schéma pour les unités d'information de type relation de contrainte d'identité
[définition]
La ·contrainte d'identité éligible·.
[table des noeuds]
Une ·table des noeuds· ayant une entrée pour chaque ·séquence clé· (appelez la k) et noeud (appelez le n) tels que l'une des conditions suivantes soit vérifiée :
1 Il y a une entrée dans l'une des ·tables des noeuds· associée à la [définition] d'une unité d'information de type relation de contrainte d'identité dans au moins l'une des [tables des contraintes d'identité] de l'unité d'information [enfants] de type élément de l'unité d'information de type élément dont la ·séquence clé· est k et le noeud est n  ;
ayant considéré que deux entrées n'ont pas la même ·séquence clé· mais des noeuds distincts. Les conflits potentiels sont résolus en n'incluant aucune entrée conflictuelle qui devrait son inclusion à la clause 1 ci-dessus. Remarquez que si toutes les entrées en conflit surgissent de la clause 1 ci-dessus, cela signifie qu'aucune entrée n'apparaîtra pour la ·séquence clé· responsable du conflit.
Remarque : La complexité de ce qui est écrit ci-dessus vient du fait que les contraintes d'identité keyref peuvent être définies sur des domaines différents de celui inclus de la contrainte d'identité qu'elles référencent, ou que les domaines peuvent être les mêmes mais s'auto-inclure à un certain niveau de profondeur. Dans d'autres cas la ·table des noeuds· pour la contrainte d'identité référencée a besoin de se propager par le haut, avec des conflits de résolution.

L'unité d'information de type relation de contrainte d'identité, contrairement à d'autres de cette spécification, est essentiellement un mécanisme interne de comptabilité. Il est introduit pour supporter la définition de la Contrainte d'identité satisfaite (§3.11.4) ci-dessus. En conséquence, les programmes de traitement conformes peuvent, sans y être toutefois obligés, les exposer via les propriétés de la [table des contraintes d'identité] dans l'ensemble d'information résultant de la validation de schéma. En d'autres termes, les contraintes ci-dessus peuvent être interprétées en disant que la ·validation· des contraintes d'identité se poursuit comme si ces unités de l'ensemble d'information existaient.

3.11.6 Contraintes du composant de schéma de définition de la contrainte d'identité

Toute définition de contrainte d'identité (référez-vous au chapitre définitions de contrainte d'identité (§3.11)) doit satisfaire la condition suivante.

Contraintes des composants de schéma : Exactitudes des propriétés de la définition d'une contrainte d'identité
Toutes les conditions suivantes doivent être remplies :
1 Les valeurs des propriétés d'une définition de contrainte d'identité doivent être telles que décrites dans le tableau des propriétés du chapitre Composant de schéma de définition de la contrainte d'identité (§3.11.1), modulo l'impact des sous-composants manquant (§5.3).
2 Si la {catégorie de la contrainte d'identité} est keyref, la cardinalité de l'ensemble des {champs} doit être égale à celle de l'ensemble des {champs} de la {clé référencée}.
Contraintes des composants de schéma : Valeur correcte du sélecteur
Toutes les conditions suivantes doivent être remplies :
1 Le {sélecteur} doit être une expression XPath valide, tel que défini dans [XPath].
2 L'une des conditions suivantes doit être vérifiée :
2.1 Les expressions XPath du {sélecteur} doivent se conformer aux règles de production suivantes :
Expressions XPath du sélecteur
[1]    Selector    ::=    Path ( '|' Path )*
[2]    Path    ::=    ('.//')? Step ( '/' Step )*
[3]    Step    ::=    '.' | NameTest
[4]    NameTest    ::=    QName | '*' | NCName ':' '*'
2.2 Elle doivent être des expressions XPath impliquant l'axe des enfants dont une forme abrégée est donnée ci-dessus.
Contraintes des composants de schéma : Valeur correcte des champs
Toutes les conditions suivantes doivent être remplies :
1 Chaque membre de l'ensemble des {champs} doit être une expression XPath valide, tel que défini dans [XPath].
2 L'une des conditions suivantes doit être vérifiée :
2.1 Elle doit être conforme à la règle de production donnée c-dessus pour le Sélecteur, avec toutefois la modification suivante :
Règle de production de Path des expressions XPath de l'ensemble de champs
[5]    Path    ::=    ('.//')? ( Step '/' )* ( Step | '@' NameTest )
Cette règle diffère de la précédente en permettant, à l'étape finale, d'adresser un noeud d'attribut.
2.2 Elle doit être une expression XPath impliquant les axes enfant et/ou attribut dont des formes abrégées sont données ci-dessus.

previous sub-section next sub-section 3.12 Déclarations des notations

Les déclarations de notation reprennent un principe qui existait déjà en XML 1.0 sous la forme des déclarations de NOTATION.

Exemple
<xs:notation name="jpeg" public="image/jpeg" system="viewer.exe">
Représentation XML d'une déclaration de notation.

3.12.1 Le composant de schéma de déclaration d'une notation

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

Composant de schéma : Déclaration de notation
{nom}
Un NCName comme cela est défini dans [XML-Namespaces].
{espace de noms cible}
Cette propriété est soit ·absente· soit prend comme valeur un nom d'espace de noms conforme à ce qui est défini dans [XML-Namespaces].
{identifiant système}
Cette propriété est facultative si {l'identifiant publique} est présent. Sa valeur est une référence d'URI.
{identifiant publique}
Facultatif si {l'identifiant système} est présent. Un identifiant publique conforme à ce qui est défini dans [XML 1.0 (Second Edition)].
{annotation}
Facultatif. Une annotation.

Les déclarations des notations ne participent pas à la ·validation· en tant que tel. Elles sont référencées au cours de la ·validation· des chaînes de caractères comme étant des membres du type simple NOTATION.

Reportez-vous au chapitre sur les Annotations (§3.13) pour avoir plus de renseignements sur le rôle des {annotation}.

3.12.2 Représentation XML du composant de schéma de déclaration de notation

Le composant de schéma de la représentation XML d'une déclaration de notation est l'unité d'information de type élément <notation>. Les correspondances entre les propriétés de cette unité d'information et les propriétés du composant qui lui correspond sont les suivantes :

Vue synthétique de la représentation XML : Unité d'information de type élément notation

<notation
  id = ID
  name = NCName
  public = anyURI
  system = anyURI
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?)
</notation>

Composant de schéma : Déclaration d'une notation
Propriété Représentation
{nom} La ·valeur réelle· de [l'attribut] name
{espace de noms cible} La ·valeur réelle· de [l'attribut] targetNamespace de l'unité d'information parent de type élément schema.
{identifiant système} La ·valeur réelle· de [l'attribut] system, si il est présent, sinon cette propriété est ·absente·.
{identifiant publique} La ·valeur réelle· de [l'attribut] public
{annotation} L'annotation correspondant à l'unité d'information de type élément <annotation> des [enfants], quand il y en a, sinon cette propriété est ·absente·.
Exemple
<xs:notation name="jpeg"
             public="image/jpeg" system="viewer.exe" />

<xs:element name="picture">
 <xs:complexType>
  <xs:simpleContent>
   <xs:extension base="xs:hexBinary">
    <xs:attribute name="pictype">
     <xs:simpleType>
      <xs:restriction base="xs:NOTATION">
       <xs:enumeration value="jpeg"/>
       <xs:enumeration value="png"/>
       . . .
      </xs:restriction>
     </xs:simpleType>
    </xs:attribute>
   </xs:extension>
  </xs:simpleContent>
 </xs:complexType>
</xs:element>

<picture pictype="jpeg">...</picture>

3.12.3 Contraintes portant sur la représentation XML d'une déclaration de notation

Contraintes de représentation des schémas : Représentation correcte d'une déclaration de notation
En plus des conditions imposées sur les unités d'information de type élément <notation> par le schéma des schémas, la définition correspondant à une notation doit satisfaire aux conditions exposées au chapitre Contraintes sur les composants de schéma d'une déclaration de notation (§3.12.6).

3.12.4 Règles de validation d'une déclaration de notation

N'existe pas en tant que tel.

3.12.5 Contributions d'une déclaration de notation à l'ensemble d'information

Contribution à l'ensemble d'information du schéma : validé avec notation
Chaque fois qu'une unité d'information de type attribut est ·valide· par rapport à une NOTATION, dans l'ensemble d'information résultant de la validation de schéma son unité d'information parent de type élément a la propriété suivante :
Contributions à l'ensemble d'information issu de la validité de schéma pour les unités d'information de type élément
[notation]
Une ·unité isomorphe· à la déclaration de la notation dont les {nom} et {espace de noms cible} correspondent au ·nom local· et au ·nom d'espace de noms· (tel que défini dans Interprétation de QName (§3.15.3)) de la ·valeur réelle· de l'unité attribut
ou une paire composée de propriétés comme suit :
Contributions à l'ensemble d'information issu de la validité de schéma pour les unités d'information de type élément
[notation système]
La valeur de {l'identifiant système} de cette déclaration de notation.
[notation publique]
La valeur de {l'identifiant publique} de cette déclaration de notation.
Remarque : Pour la compatibilité, un seul de ces attributs devrait apparaître sur un élément donné. Dans le cas où il y en a plusieurs, cette spécification ne définit pas lequel d'entre eux fournit la ou les propriétés ci-dessus.

3.12.6 Contraintes sur les composants de schéma d'une déclaration de notation

Toutes les déclarations de notation (référez-vous au chapitre déclarations des notations (§3.12)) doivent satisfaire la contrainte suivante.

Contraintes des composants de schéma : Déclaration correcte de notation
Les valeurs des propriétés d'une déclaration de notation doivent être telles que décrites dans le tableau des propriétés du chapitre Composant de schéma de déclaration d'une notation (§3.12.1), modulo l'impact des sous-composants manquant (§5.3).

previous sub-section next sub-section 3.13 Annotations

Les annotations permettent d'introduire dans les composants de schéma des annotations destinées tant aux humains qu'aux programmes de traitement.

Exemple
<xs:simpleType fn:note="special">
  <xs:annotation>
   <xs:documentation>A type for experts only</xs:documentation>
   <xs:appinfo>
    <fn:specialHandling>checkForPrimes</fn:specialHandling>
   </xs:appinfo>
  </xs:annotation>
     
Représentations XML de trois sortes d'annotations.

3.13.1 Le composant de schéma pour les annotations

Le composant de schéma pour les annotations a les propriétés suivantes :

Composant de schéma : annotation
{information applicative}
Une série d'unités d'information de type élément.
{information pour l'utilisateur}
Une série d'unités d'information de type élément.
{attributs}
Une série d'unités d'information de type attribut.

Les {informations pour l'utilisateur} sont prévues pour un usage humain, les {informations applicatives} pour un traitement automatique. Dans les deux cas, une provision est faite pour une référence d'URI facultative mais prévue pour venir compléter l'information locale, comme la valeur de l'attribut source des unités d'information de type élément correspondantes. La ·validation· n'implique pas le déréférencement de ces URI, quand elles sont présentes. Dans le cas d'une {information pour l'utilisateur}, une information doit être donnée quant au type de langage humain qui s'y trouve être utilisé, cela se fait en utilisant l'attribut xml:lang.

Les {attributs} garantissent que lorsque les auteurs de schéma tirent partie de la prévision faite pour pouvoir rajouter des attributs provenant d'espaces de noms autres que l'espace de noms des schémas XML à des documents de type schéma, ceux-là sont disponibles à l'intérieur des composants correspondant à l'unité élément où ces attribuent apparaissent.

Les annotations ne participent pas à la ·validation· en tant que tel. Etant considéré qu'une annotation elle-même satisfait toutes les ·Contraintes des composants de schémas· elle ne peut pas affecter la ·validation· des unités d'information de type élément.

3.13.2 Représentation XML du composant de schéma pour les annotations

Le principe des annotations, au niveau des schémas comme des composants, et dont le contenu est prévu tant pour les humains que pour les programmes, est prévu en début de presque tous les éléments principaux des schémas, et n'importe où au niveau supérieur des schémas. La représentation XML du composant de schéma correspondant à l'annotation est l'unité d'information de type élément <annotation>. Les correspondances entre les propriétés de cette unité d'information et les propriétés du composant qui lui correspond sont les suivantes :

Vue synthétique de la représentation XML : Unité d'information de type élément annotation

<annotation
  id = ID
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (appinfo | documentation)*
</annotation>

<appinfo
  source = anyURI>
  Content: ({any})*
</appinfo>

<documentation
  source = anyURI
  xml:lang = language>
  Content: ({any})*
</documentation>

 Le composant de schéma : Annotation
Propriété Représentation
{information applicative} Une série d'unités d'information [enfant] de type élément <appinfo>, dans l'ordre, quand il y en a, sinon la série est vide.
{information pour l'utilisateur} Une série d'unités d'information [enfant] de type élément <documentation>, dans l'ordre, quand il y en a, sinon la série est vide.
{attributs} Une série d'unités d'information de type attribut, à savoir celles autorisées par l'attribut générique de la définition de type pour l'unité <annotation> elle-même ou pour les unités englobantes qui correspondent au composant à l'intérieur duquel le composant annotation se trouve.

Le composant annotation correspondant à l'élément <annotation> dans l'exemple ci-dessus aura une unité élément dans chacun de ses ensembles {informations pour l'utilisateur} et {informations applicative} et une unité attribut dans sa série {d'attributs}.

3.13.3 Contraintes portant sur la représentation XML des annotations

Contraintes de représentation des schémas : représentation correcte d'une définition d'annotation
En plus des conditions imposées sur les unités d'information de type élément <annotation> par le schéma des schémas, l'annotation correspondante doit satisfaire aux conditions exposées au chapitre Contraintes sur les composants de schéma pour les annotations (§3.13.6).

3.13.4 Règles de validation des annotations

N'existe pas en tant que tel.

3.13.5 Contributions d'une annotation à l'ensemble d'information

N'existe pas en tant que tel : la question du rajout des annotations dans l'ensemble d'information résultant de la validation de schéma est couverte par les contributions à l'ensemble d'information résultant de la validation de schéma des éléments englobant.

3.13.6 Contraintes sur les composants de schéma pour les annotations

Toutes les annotations (référez-vous au chapitre Annotations (§3.13)) doivent satisfaire la contrainte suivante.

Contraintes des composants de schéma : annotation correcte
Les valeurs des propriétés d'une annotation doivent être telles que décrites dans le tableau des propriétés du chapitre Composant de schéma pour les annotations (§3.13.1), modulo l'impact des sous-composants manquant (§5.3).

previous sub-section next sub-section 3.14 Définitions de types simples

Remarque : Ce chapitre est une combinaison de versions non-normatives de parties normatives de [XML Schema tome 2 : Types de données], à des fins de références croisées locales et de parties normatives en rapport avec l'interfaçage entre composants de schéma défini dans cette spécification et la définition du composant de type simple.

Les définitions de types simples permettent de contraindre les unités d'information [enfants] de type caractère qui sont utilisées dans les unités d'information de type élément et attribut.

Exemple
<xs:simpleType name="farenheitWaterTemp">
 <xs:restriction base="xs:number">
  <xs:fractionDigits value="2"/>
  <xs:minExclusive value="0.00"/>
  <xs:maxExclusive value="100.00"/>
 </xs:restriction>
</xs:simpleType>
Représentation XML d'une définition de type simple.

3.14.1 (partie non-normative) Le composant de schéma de définition d'un type simple

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

Composant de schéma : définition de type simple
{nom}
Facultatif. Un NCName défini dans [XML-Namespaces].
{espace de noms cible}
Soit cette propriété est ·absente· soit il s'agit d'un nom d'espace de noms, tel que défini dans [XML-Namespaces].
{définition du type de base}
Une définition de type simple, qui peut être la ·définition du type simple ur·.
{facettes}
Un ensemble de facettes contraignantes.
{facettes fondamentales}
Un ensemble de facettes fondamentales.
{terminal}
Un sous-ensemble de l'ensemble {extension, list, restriction, union}.
{variante}
L'un des éléments de l'ensemble {atomic, list, union}. En fonction de la valeur de la {variante}, des propriétés supplémentaires sont définies comme suit :
atomic
{définition de type primitif}
Une définition d'un type simple primitif préfabriqué (ou la ·définition du type simple ur·).
list
{définition du type unité}
Une définition de type simple.
union
{définitions de type de membre}
Une série non-vide de définitions de type simples.
{annotation}
Facultatif. Une annotation.

Les types simples sont identifiés par leurs {nom} et {espace de noms cible}. A l'exception des types simples anonymes (ceux qui n'ont pas de {nom}), puisque les définitions de types (c'est à dire à la fois de types simples et complexes) doivent être identifiées de manière unique à l'intérieur d'un ·schéma XML·, aucune définition de type simple peut avoir le même nom qu'une autre définition de type, qu'elle soit simple ou complexe. Les {noms} et {espaces de noms cible} des types simples sont utilisés pour pouvoir être référencés à partir des instances (référez-vous au chapitre xsi:type (§2.6.1)) et pour être utilisés dans la représentation XML des composants de schéma (spécifiquement dans les éléments <element> et <attribute>). Reportez-vous au chapitre Références aux composants de schéma au travers des espaces de noms (§4.2.3) pour connaître les détails relatifs à l'utilisation des identifiants de composants quand un schéma est importé dans un autre.

Remarque : Le {nom} d'un type simple n'est pas ipso facto le [nom (local)] des unités d'information de type élément ou attribut ·validées· par cette définition. La connexion entre un nom et une définition de type est décrite dans les chapitres Déclaration d'éléments (§3.3) et Déclarations d'attributs (§3.2).

Une définition de type simple qui n'est pas {terminale} peut être utilisé comme {définition de type de base} pour d'autres types dérivés par extension ou restriction, ou comme {définition du type unité} dans la définition d'une liste ou dans l'ensemble des {définitions de type de membre} d'une union ; les valeurs explicites extension, restriction, list et union pour empêcher les dérivations supplémentaires par extension (pour donner un type complexe) ou restriction (pour donner un type simple) et leur utilisation dans la construction des listes et des unions respectivement.

La {variante} détermine si le type simple correspond à un type atomic, list ou union comme cela est défini dans [XML Schema tome 2 : Types de données].

Comme cela est décrit au chapitre Hiérarchie des définitions de types (§2.2.1.1), chaque définition de type simple est une ·restriction· d'un autre type simple (la {définition du type de base}), qui est la simple ·définition du type ur· si et seulement si la définition de type en question est l'un des types de données primitif préfabriqué, ou une définition de type list ou union. Chaque type atomic est finalement une restriction d'exactement une de ces {définitions de types primitifs} simples préfabriqués.

Les {facettes} pour chaque définition de type simple sont sélectionnées parmi celles définies dans [XML Schema tome 2 : Types de données]. Pour les définitions du type atomic, elles sont réduites au jeu approprié à la {définition du type primitif} correspondant. Par conséquent, la valeur du blanc et du blanc lexical (c'est à dire ce qui est ·validé· par tout type simple atomic) est déterminé par la paire ({définition de type primitif}, {facettes}).

Comme spécifié dans [XML Schema tome 2 : Types de données], les définitions de type simple list ·valident· les unités lexicales séparées par des espaces, chacune d'elle étant conforme à une définition spécifiée d'un type simple : la {définition du type unité}. Le type unité spécifié ne doit pas être lui-même un type list et doit être l'un des types identifiés dans [XML Schema tome 2 : Types de données] comme un type unité adapté pour le type simple list. Dans ce cas les {facettes} s'appliquent à la liste elle-même et sont réduites à celles appropriées aux listes.

Une définition de type simple union ·valide· les chaînes de caractères qui satisfont au moins une des définitions de l'ensemble des {définitions de type de membre}. Comme dans le cas de list, les {facettes} s'appliquent à l'union elle-même et sont réduites à celles appropriées au cas union.

Comme discuté au chapitre Hiérarchie des définitions de types (§2.2.1.1), la ·définition du type ur· fonctionne comme un type simple quand il est utilisé comme ·définition d'un type de base· pour des types de données primitifs préfabriqués et pour les définitions des types list et union. Elle est considérée comme ayant un espace lexical sans contrainte et un espace de valeurs résultant de l'union des espaces de valeurs de tous les types de donnés primitifs préfabriqués et de l'ensemble de toutes les listes de tous les membres des espaces de valeurs de tous les types de données primitifs préfabriqués.

La ·définition du type ur· simple ne doit pas être nommée comme c'est le cas pour toute ·définition du type de base· de n'importe lequel des types simples définis par les utilisateurs : comme elle n'a aucune facette contraignante, cela serait incohérent.

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

3.14.2 (partie non-normative) Représentation XML du composant de schéma de définition d'un type simple

Remarque : Ce chapitre reproduit une version de l'information se trouvant dans [XML Schema tome 2 : Types de données], cela à des fins de références croisées locales à ce document.
Vue synthétique de la représentation XML : l'unité d'information de type élément simpleType

<simpleType
  final = (#all | (list | union | restriction))
  id = ID
  name = NCName
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?, (restriction | list | union))
</simpleType>

<restriction
  base = QName
  id = ID
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?, (simpleType?, (minExclusive | minInclusive | maxExclusive | maxInclusive | totalDigits | fractionDigits | length | minLength | maxLength | enumeration | whiteSpace | pattern)*))
</restriction>

<list
  id = ID
  itemType = QName
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?, (simpleType?))
</list>

<union
  id = ID
  memberTypes = Liste de QName
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?, (simpleType*))
</union>

Composant de schéma : Définition d'un type simple
Propriété Représentation
{nom} La ·valeur réelle· de [l'attribut] name si il est présent, sinon cette propriété est ·absente·.
{espace de noms cible} La ·valeur réelle· de <schema> si il est présent, sinon cette propriété est ·absente·.
{définition du type de base} La valeur est celle de l'un des cas suivants :
1 Si l'option <restriction> est choisie, alors la valeur est celle de la définition de type ·ramenée· par la ·valeur réelle· de [l'attribut] base de <restriction>, si il est présent, sinon la valeur est celle de la définition de type correspondant à l'élément <simpleType> parmi les [enfants] de l'élément <restriction>.
2 Si les options <list> ou <union> sont choisies, alors la valeur est la ·définition d'un type ur simple·.
{terminal} La valeur est similaire à celle des {substitutions prohibées} des définitions de types complexes mais en utilisant les [attributs] final et finalDefault à la place des [attributs] block et blockDefault, l'ensemble utile étant {extension, restriction, list, union}.
{variante} Si l'option <list> est choisie, alors la valeur est list, sinon si l'option <union> est choisie, alors la valeur est union, et enfin si l'option <restriction> est choisie, alors la valeur est la {variante} de la {définition du type de base}.
Si la {variante} est atomic, les correspondances de propriétés additionnelles suivantes s'appliquent également :
Composant de schéma : Définition du type simple atomique
Propriété Représentation
{définition de type primitif} La définition du type primitif préfabriqué à partir duquel la {définition du type de base} est dérivée.
{facettes} Un ensemble de composants facettes ·constituant une restriction· de l'ensemble des {facettes} de la {définition du type de base} par rapport à un ensemble de composants facettes correspondant aux unités d'information [enfants] de type élément de <restriction> (c'est à dire ceux avec des facettes spécifiées, quand il y en a), tel que défini dans le chapitre Restriction du type simple (facettes) (§3.14.3).
Si la {variante} est list, les correspondaces de propriétés additionelles suivantes s'appliquent aussi :
Composant de schéma : Définition du type simple list
Propriété Représentation
{définition du type unité} La valeur est celle d'un des cas suivants :
1 Si l'option <list> est choisie, alors la valeur est celle de la définition de type ·ramenée· par la ·valeur réelle· de [l'attribut] itemType de <list>, si il est présent, sinon la valeur est celle de la définition de type correspondant à l'élément [enfant] <simpleType> de <list>.
2 Si l'option <restriction> est choisie, alors la valeur est celle de la {définition du type unité} de la {définition du type de base}.
{facettes} Si l'option <restriction> est choisie, la valeur est un ensemble de composants facettes ·constituant une restriction· de l'ensemble des {facettes} de la {définition du type de base} en rapport avec un ensemble de composants facettes correspondant aux unités d'information [enfants] de type élément de l'élément <restriction> (c'est à dire celles qui spécifient des facettes, quand il y en a), tel que cela est défini au chapitre Restriction du type simple (facettes) (§3.14.3), sinon la valeur est un ensemble vide.
Si la {variante} est union, les correspondances de propriétés additionelles suivantes s'appliquent aussi :
Composant de schéma : Définition du type simple union
Propriété Représentation
{définitions de type de membre} la valeur est celle d'un des cas suivants :
1 Si l'option <union> est choisie, alors [Définition  :]  les membres explicites sont définis comme étant les définitions de types ·ramenées· par les unités de la ·valeur réelle· de [l'attribut] memberTypes, quand il y en a, suivi des définitions de types correspondant aux éléments [enfants] <simpleType> de l'élément <union>, quand il y en a. La ·valeur réelle· est alors formée en remplaçant toute définition de type union dans les ·membres explicites· par les membres de leur ensemble de {définitions de type de membre}, dans l'ordre.
2 Si l'option <restriction> est choisie, alors la valeur est l'ensemble des {définitions de type de membre} de la {définition du type de base}.
{facettes} Si l'option <restriction> est choisie, la valeur est un ensemble de composants facettes ·constituant une restriction· de l'ensemble des {facettes} de la {définition du type de base} par rapport à un ensemble de composants facettes correspondant aux unités d'information [enfants] de type élément de l'élément <restriction> (c'est à dire ceux qui spécifient des facettes, quand il y en a), tel que cela est défini au chapitre Restriction du type simple (facettes) (§3.14.3), sinon la valeur est l'ensemble vide.

3.14.3 (partie non-normative) Contraintes portant sur la représentation XML de la définition d'un type simple

Contraintes de représentation des schémas : Représentation correcte d'une définition de type simple
En plus des conditions imposées sur les unités d'information de type élément <simpleType> par le schéma des schémas, toutes les conditions suivantes doivent être remplies :
1 La définition de type simple correspondante, si elle existe, doit satisfaire aux conditions exposées au chapitre Contraintes sur les composants de schéma de définition d'un type simple (§3.14.6).
2 Si l'option <restriction> est choisie, un de ses [enfants] doit être soit [l'attribut] base soit l'élément <simpleType>.
3 Si l'option <list> est choisie, la définition doit avoir un [enfant] qui est soit [l'attribut] itemType soit l'élement <simpleType>.
4 Une définition circulaire de type union est interdite. Cela étant, si l'option <union> est choisie, il ne doit pas y avoir une seule des entrée de [l'attribut] memberTypes quelqu'en soit la profondeur qui se ramène au composant correspondant à l'élément <simpleType>.
Contraintes de représentation des schémas : Restriction du type simple (facettes)
Pour qu'une définition de type simple (appelez la R) soit une restriction d'une autre définition de type simple (appelez la B) grâce à un ensemble de facettes (appelez la S) toutes les conditions suivantes doivent être remplies :
1 La {variante} et la {définition de type primitif} de R sont les mêmes que ceux de B.
2 L'ensemble des {facettes} de R est l'union de S et de l'ensemble des {facettes} de B, en ayant éliminé les doublons. Pour éliminer les doublons, quand une facette de la même sorte est présente à la fois dans S et dans l'ensemble des {facettes} de B, celle qui est dans l'ensemble des {facettes} de B n'est pas inclue, cela est vrai à l'exception des facettes énumeration et motif, pour lesquelles plusieurs occurrences ayant des valeurs distincts sont autorisés.

[Définition :]  si la clause 2 ci-dessus est vérifiée, l'ensemble des {facettes} de R est une restriction de celui de B par rapport à S.

3.14.4 Règles de validation de la définition d'un type simple

Règle de validation : Chaîne de caractère valide
Une chaîne de caractères est localement ·valide· par rapport à une définition de type simple si elle a une validité de schéma par rapport à cette définition comme cela est défini au chapitre Type de données valide dans [XML Schema tome 2 : Types de données].

3.14.5 Contributions de l'ensemble d'information de la définition d'un type simple

N'existe pas en tant que tel.

3.14.6 Contraintes sur les composants de schéma de définition d'un type simple

Toute définition de type simple (référez-vous au chapitre Définition de types simples (§3.14)) doit satisfaire les contraintes suivantes.

Contraintes des composants de schéma : Exactitudes des propriétés de la définition d'un type simple
Toutes les conditions suivantes doivent être remplies :
1 Les valeurs des propriétés de la définition d'un type simple doivent être telles que décrites dans le tableau des propriétés du chapitre Définition des types de données, modulo l'impact des sous-composants manquant (§5.3).
2 Les définitions circulaires sont interdites. Cela étant, it doit être possible d'atteindre un type de données primitif préfabriqué ou la ·définition du type simple ur· en suivant de manière répétitive la {définition du type de base}.
3 La {définition du type de base} ne doit pas être {terminale} pour la restriction.
4 Si la {définition du type de base} n'est pas la ·définition du type simple ur·, toutes les conditions suivantes doivent être remplies :
4.1 La définition doit être une ·restriction valide· telle que cela est défini au chapitre Dérivation valide (restriction, simple) (§3.14.6).
4.2 Si la {variante} n'est pas atomic, alors un des deux cas suivants doit être vérifié :
4.2.1 Si la {variante} est list, alors la {définition du type de base} ne doit pas être {terminale} pour les list.
4.2.2 Si la {variante} est union, alors la {définition du type de base} ne doit pas être {terminale} pour l'union.
Contraintes des composants de schéma : Dérivation valide (restriction, simple)
Le cas approprié parmi les cas suivants doit être vérifié :
1 Si la {variante} est atomic, alors toutes les conditions suivantes doivent être remplies :
1.1 La {définition du type de base} doit être celle d'un type simple atomique ou d'un type de données primitif préfabriqué.
1.2 La {définition du type de base} ne doit pas être {terminale} pour la restriction.
1.3 Pour chaque facette de l'ensemble des {facettes} il doit y avoir une facette du même type dans l'ensemble des {facettes} de la {définition du type de base} dont la valeur doit être une restriction valide de la facette en question tel que défini dans [XML Schema tome 2 : Types de données].
2 Si la {variante} est list, alors toutes les conditions suivantes doivent être remplies :
2.1 La {définition du type unité} doit avoir une {variante} de valeur atomic ou union (auquel cas toutes les {définitions du type membre} doivent être atomic).
2.2 Seules les composants facettes length, minLength, maxLength, pattern et enumeration sont autorisés dans l'ensemble des {facettes}.
2.3 Si la {définition du type de base} n'est pas la ·définition du type simple ur·, alors toutes les conditions suivantes doivent être remplies :
2.3.1 La {définition du type de base} doit avoir une {variante} ayant la valeur list.
2.3.2 La {définition du type de base} ne doit pas être {terminale} pour la restriction.
2.3.3 Pour chaque facette de l'ensemble des {facettes} il doit y avoir une facette du même genre dans l'ensemble des {facettes} de la {définition du type de base} dont la valeur doit être une restriction valide de la facette en question tel que défini dans [XML Schema tome 2 : Types de données].
3 Si la {variante} est union, alors toutes les conditions suivantes doivent être remplies :
3.1 Les {définitions de type de membre} doivent toutes avoir comme {variante} les types atomic ou list.
3.2 Seules les composants facettes pattern et enumeration sont autorisés dans l'ensemble des {facettes}.
3.3 Si la {définition du type de base} n'est pas la ·définition du type simple ur·, alors toutes les conditions suivantes doivent être remplies :
3.3.1 La {variante} de la {définition du type de base} doit être union.
3.3.2 La {définition du type de base} ne doit pas être {terminale} pour la restriction.
3.3.3 Pour chaque facette de l'ensemble des {facettes} il doit y avoir une facette du même genre dans l'ensemble des {facettes} de la {définition du type de base} dont la valeur doit être une restriction valide de la facette en question tel que défini dans [XML Schema tome 2 : Types de données].
[Définition :]  Si la contrainte exprimée au chapitre Dérivation valide (restriction, simple) (§3.14.6) tient d'une définition de type simple, alors il s'agit d'une restriction valide de la ·définition de son type de base·.

La contrainte suivante définit des relations exploitées ailleurs dans cette spécification.

Contraintes des composants de schéma : Dérivation correcte de type (simple)
Pour que la dérivée (appelée D comme dérivée) de la définition d'un type simple (appelée B comme base) soit valide étant donné un sous-ensemble de {extension, restriction, list, union} (parmi lequel seul restriction est réellement utile) l'une des conditions suivantes doit être vérifiée :
1 Il s'agit de la même définition de type.
2 Toutes les conditions suivantes doivent être remplies :
2.1 restriction n'est pas dans le sous-ensemble, ou sa propre {définition du type de base} n'est pas {terminale} pour la restriction ;
2.2 L'une des conditions suivantes doit être vérifiée :
2.2.2 La ·définition du type de base· de D n'est pas la ·définition du type simple ur· et est une dérivée valide de B étant donné le sous-ensemble, tel que défini par cette contrainte.
2.2.3 La {variante} de D est list ou union et B est la ·définition du type simple ur·.
2.2.4 La {variante} de B est union et D est une dérivée valide à partir d'une définition de type de l'ensemble des {définition du type membre} de B étant donné le sous-ensemble, tel que défini par cette contrainte.

3.14.7 Définition d'un type simple préfabriqué

Une définition de type simple presque équivalente à la version simple de la ·définition du type ur· se trouve dans chaque schéma par définition. Elle a les propriétés suivantes :

définition d'un type simple de type ur
Propriété Valeur
{nom} anySimpleType
{espace de noms cible} http://www.w3.org/2001/XMLSchema
{définition du type de base} ·la définition du type ur·
{terminal} L'ensemble vide
{variante} Cette propriété est ·absente·

Les définitions de types simples pour tous les types de données primitifs préfabriqués, à savoir string, booléen, float, double, number, dateTime, duration, time, date, gMonth, gMonthDay, gDay, gYear, gYearMonth, hexBinary, base64Binary, anyURI (référez-vous au chapitre Types de données primitifs dans [XML Schema tome 2 : Types de données]), tant pour les ·définitions du type ur· simples que complexes (comme cela a déjà été décrit), sont présents par définition dans tous les schémas. Tous sont dans {l'espace de noms cible} de XML Schema (nom de l'espace de noms http://www.w3.org/2001/XMLSchema), ont une {variante} atomic et un ensemble de {facettes} vide et ne s'appuient que sur la ·définition du type ur· simple comme ·définition de type de base· et eux-mêmes comme {définition de type primitif}.

De manière similaire, les définitions de types simples de tous les types dérivées préfabriqués (référez-vous au chapitre Types de données dérivés de [XML Schema tome 2 : Types de données]) sont présents par définition dans tous les schémas avec des propriétés conformes à ce qui est spécifié dans [XML Schema tome 2 : Types de données] et avec la représentation XML telle que décrite dans l'annexe Schéma des schémas (§A).

previous sub-section 3.15 Les schémas dans leur ensemble

Un schéma est constitué d'un ensemble de composants de schéma.

Exemple
<xs:schema
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://www.example.com/example">
  . . .
</xs:schema>
Représentation XML d'un squelette de schéma.

3.15.1 Le schéma lui-même

Au niveau abstrait, le schéma lui-même se limite à un concept de conteneur pour les composants de schéma.

Composant de schéma : schema
{définitions de types}
Un ensemble de définitions nommées de types simples et complexes.
{déclarations d'attributs}
Un ensemble de déclarations nommées d'attributs au niveau supérieur.
{déclarations d'éléments}
Un ensemble de déclarations nommées d'éléments au niveau supérieur.
{définitions de groupe d'attributs}
Un ensemble de définitions nommées de groupes d'attributs.
{définitions de groupe modèle}
Un ensemble de définitions nommées de groupes modèles.
{déclarations des notations}
Un ensemble de déclarations des notations.
{annotations}
Un ensemble d'annotations.

3.15.2 Représentations XML des schémas

Un schéma est représenté en XML par un ou plusieurs ·documents de type schéma·, c'est à dire, une ou plusieurs unités d'information de type élément <schema>. Un ·document de type schéma· contient les représentations d'un ensemble de composants de schéma, comme des définitions de types et des déclarations d'éléments, qui ont le même {espace de noms cible}. Un ·document de type schéma· qui a une ou plusieurs unités d'information de type élément <import> correspond à un schéma ayant des composants dans plusieurs {espaces de noms cible}. Reportez-vous au chapitre Contraintes d'importation et sémantique (§4.2.3).

Vue synthétique de la représentation XML : Unité d'information de type élément schema

<schema
  attributeFormDefault = (qualified | unqualified) : unqualified
  blockDefault = (#all | List of (extension | restriction | substitution))  : ''
  elementFormDefault = (qualified | unqualified) : unqualified
  finalDefault = (#all | List of (extension | restriction))  : ''
  id = ID
  targetNamespace = anyURI
  version = token
  xml:lang = language
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: ((include | import | redefine | annotation)*, (((simpleType | complexType | group | attributeGroup) | element | attribute | notation), annotation*)*)
</schema>

Composant de schéma : schema
Propriété Représentation
{définitions de types} Les définitions des types simples et complexes correspondant à toutes les unités d'information [enfants] de type élément <simpleType> et <complexType>, si elles existent, plus toute définition inclue ou importée, reportez-vous aux chapitres Assembler un schéma pour un seul espace de noms cible à partir de plusieurs documents de définition de schémas (§4.2.1) et Références aux composants de schéma au travers des espaces de noms (§4.2.3).
{déclarations d'attributs} Les déclarations d'attributs de niveau supérieur correspondant à toutes les unités d'information [enfants] de type élément <attribute>, quand il y en a, plus toute déclaration inclue ou importée, reportez-vous aux chapitres Assembler un schéma pour un seul espace de noms cible à partir de plusieurs documents de définition de schémas (§4.2.1) et Références aux composants de schéma au travers des espaces de noms (§4.2.3).
{déclarations d'éléments} Les déclarations d'éléments de niveau supérieur correspondant à toutes les unités d'information [enfants] de type élément <element>, quand il y en a, plus toute déclaration inclue ou importée, reportez-vous aux chapitres Assembler un schéma pour un seul espace de noms cible à partir de plusieurs documents de définition de schémas (§4.2.1) et Références aux composants de schéma au travers des espaces de noms (§4.2.3).
{définitions de groupes d'attributs} Les définitions de groupes d'attributs correspondant à toutes les unités d'information [enfants] de type élément <attributeGroup>, quand il y en a, plus toute définition inclue ou importée, reportez-vous au chapitre Assembler un schéma pour un seul espace de noms cible à partir de plusieurs documents de définition de schémas (§4.2.1) et Références aux composants de schéma au travers des espaces de noms (§4.2.3).
{définitions des groupes modèles} Les définitions des groupes modèles correspondant à Toutes les unités d'information [enfants] de type élément <group>, quand il y en a, plus toute définition inclue ou importée, reportez-vous aux chapitres Assembler un schéma pour un seul espace de noms cible à partir de plusieurs documents de définition de schémas (§4.2.1) et Références aux composants de schéma au travers des espaces de noms (§4.2.3).
{déclarations des notations} Les déclarations des notations correspondant à toutes les unités d'information [enfants] de type élément <notation>, quand il y en a, plus toute déclaration inclue ou importée, reportez-vous au chapitre Assembler un schéma pour un seul espace de noms cible à partir de plusieurs documents de définition de schémas (§4.2.1) et Références aux composants de schéma au travers des espaces de noms (§4.2.3).
{annotations} Les annotations correspondant à toutes les unités d'information [enfants] de type élément <annotation>, quand il y en a.

Remarquez qu'aucune des unités d'information de type attribut montrées ci-dessus ne correspond directement aux propriétés des schémas. Les attributs blockDefault, finalDefault, attributeFormDefault, elementFormDefaultet targetNamespace sont utilisés dans les sous-chapitres ci-dessus parce qu'ils fournissent des informations globales applicables à plusieurs correspondances entre représentation et composant. Les autres attributs (id et version) sont pour la commodité des utilisateurs et cette spécification ne leur définit aucune sémantique.

La définition du modèle de données abstrait du schéma présentée au chapitre Modèle de données abstrait de XML schema (§2.2) clarifie le fait que la plupart des composants ont un {espace de noms cible}. La plupart des composants correspondant à des représentations à l'intérieur d'une unité d'information de type élément <schema> donnée auront un {espace de noms cible} qui correspondra à l'attribut targetNamespace.

Comme la chaîne de caractère vide n'est pas un nom d'espace de noms autorisé, fournir une telle chaîne à l'attribut targetNamespace est incohérent et ne signifie pas la même chose que de ne pas la spécifier du tout. La forme du document de type schéma correspondant à un ·schéma· dont les composants n'ont pas {d'espace de noms cible} est celle pour laquelle l'attribut targetNamespace n'a pas été spécifié du tout.

Remarque : La recommandation sur les espaces de noms XML se limite à la syntaxe des éléments et des attributs dans les instances de documents ; elle ne fournit par conséquent aucun cadre de travail direct pour la gestion des noms des définitions de types, de groupes d'attributs etc. Néanmoins, la spécification applique sans distinction de cas, à tous les composants de schéma, la possibilité d'avoir un espace de noms cible, c'est à dire pas uniquement aux déclarations mais aussi aux définitions.

Bien que l'exemple de schéma de ce début de chapitre pourrait être un document XML complet avec l'élément <schema> comme élément principal du document, ce même élément pourrait très bien apparaître à l'intérieur d'autres documents. En vérité il n'existe aucune obligation pour qu'un schéma corresponde à un quelconque document (textuel) : il peut correspondre à une unité d'information de type élément construite 'manuellement', par exemple via une API conforme à DOM.

A part les éléments <include> et <import> qui ne correspondent pas directement à un quelconque composant de schéma, chacune des unités d'information de type élément pouvant apparaître dans le contenu de <schema> correspond à un composant de schéma et toutes, à l'exception de <annotation>, sont nommées. Les chapitres ci-dessous présentent tour à tour chacune de ces unités, exposant les composants auxquels elles peuvent correspondre.

3.15.2.1 Les références aux composants de schéma

Le référencement des composants de schéma depuis un document de type schéma est géré de manière uniforme, que le composant corresponde à une unité d'information de type élément se trouvant dans le même document de type schéma ou qu'il soit importé (se référer au chapitre Références aux composants de schéma au travers des espaces de noms (§4.2.3)) d'un schéma externe (qui peut, sans y être obligé, correspondre à un véritable document de type schéma). La forme de toutes ces références est un ·QName·.

[Définition :]  Un QName est un nom pouvant être qualifié par un espace de noms tel que défini dans [XML-Namespaces]. Quand un QName (Nom Qualifié) est utilisé pour la représentation XML des composants de schéma ou de leur référencement, il s'agit du QName correspondant au type simple QName tel qu'il est défini dans [XML Schema tome 2 : Types de données].

[Définition :]  Un NCName est un nom sans double point tel que défini dans [XML-Namespaces]. Quand un NCName est utilisé pour la représentation XML des composants de schéma dans cette spécification, il s'agit du NCName correspondant au type simple NCName tel qu'il est défini dans [XML Schema tome 2 : Types de données].

Dans chacune des représentations XML exposées dans les chapitres qui suivent, un attribut a le type QName si et seulement si il est vu comme référençant un composant de schéma.

Example
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
            xmlns:xhtml="http://www.w3.org/1999/xhtml"
            xmlns="http://www.example.com"
            targetNamespace="http://www.example.com">
  . . .

  <xs:element name="elem1" type="Address"/>

  <xs:element name="elem2" type="xhtml:blockquote"/>

  <xs:attribute name="attr1"
                type="xsl:quantity"/>
  . . .
</xs:schema>
La première de ces déclarations est probablement une référence locale, c'est à dire une référence à une définition de type correspondant à une unité d'information de type élément <complexType> placée quelque part ailleurs dans le document de type schéma, les deux autres font référence à des définitions de types qui viennent de schémas qui sont dans d'autres espaces de noms et supposent que ceux-là ont été déclarés pour cette importation. Reportez-vous au chapitre Références aux composants de schéma au travers des espaces de noms (§4.2.3) pour avoir plus de détails sur l'importation.
3.15.2.2 Les références aux composants de schéma à partir d'ailleurs

Les noms des composants de schéma tels que des définitions de types et des déclarations d'éléments ne sont pas du type ID  : ils ne sont pas uniques à l'intérieur d'un schéma, seulement à l'intérieur d'un espace de symboles. Cela signifie que des identifiants simples de fragments ne marcheront pas toujours pour référencer des composants de schéma à partir d'un monde extérieur au contexte des documents de type schéma.

Il n'y a actuellement aucune prévision de faite spécialement pour la definition de l'interprétation des identifiants de fragments par le type MIME text/xml, qui est le type MIME pour les schémas, afin de référencer les composants de schéma en tant que tel. Cependant, [XPointer] fournit un mécanisme qui correspond bien aux notions d'espaces de symboles telles qu'elles sont conçues dans la représentation XML des composants de schéma. Un identifiant de fragment de la forme #xpointer(xs:schema/xs:element[@name="person"]) identifiera de manière unique la représentation d'une déclaration supérieure d'élément ayant le nom person et d'autres identifiants similaires de fragments peuvent évidemment être construits pour d'autres espaces de symboles globaux.

Des identifiants courts de fragments peuvent aussi être utilisés dans certains cas, c'est à dire quand une DTD ou un schéma XML sont disponibles pour le schéma en question et qu'il a été prévu un attribut id de type ID pour toutes les représentations primaires et secondaires des composants du schéma.

C'est aux applications de savoir spécifier si elles interprètent les références de niveau document de l'une ou l'autre des variantes exposées ci-dessus comme appartenant à l'unité d'information concernée (c'est à dire sans reconnaissance particulière de la relation entre les documents de type schéma et les composants de schéma) ou comme étant au composant de schéma correspondant.

3.15.3 Contraintes portant sur la représentation XML des schémas

Contraintes de représentation des schémas : interprétation de QName
Quand le type d'une unité d'information de type attribut d'un document impliqué dans un processus de ·validation· est identifié comme étant un ·QName·, sa ·valeur réelle· est composée d'un [Définition :]  nom local et d'un [Définition :]  nom d'espace de noms. Sa ·valeur réelle· est déterminée à partir de sa ·valeur normalisée· et des [espaces de noms dans le périmètre] de l'unité d'information de type élément la contenant en suivant [XML-Namespaces] de la manière suivante :

L'un des cas suivants doit être vérifié :
1 Si sa ·valeur normalisée· est préfixée, alors toutes les conditions suivantes doivent être remplies :
1.1 Il doit y avoir un espace de noms parmi les [espaces de noms dans le périmètre] dont le [préfixe] corresponde au préfixe.
1.2 Son ·nom d'espace de noms· est le [nom de l'espace de noms] de cet espace de noms.
1.3 Son ·nom local· est la partie de sa ·valeur normalisée· après le deux-points (':').
2 Sinon la valeur est (cas où la ·valeur normalisée· n'est pas préfixée) toutes les conditions suivantes doivent être remplies :
2.2 Un des cas suivants doit être vérifié :
2.2.1 Si il y a un espace de noms parmi les [espaces de noms dans le périmètre] dont le [préfixe] n'a pas de valeur, alors son ·nom d'espace de noms· est le [nom de l'espace de noms] de cet espace de noms.
2.2.2 Sinon la valeur de son ·nom de l'espace de noms· est ·absente·.

En l'absence de la propriété [espaces de noms dans le périmètre] dans l'ensemble d'information pour le document de type schéma en question, les programmes de traitement doivent reconstruire l'information équivalente en fonction des nécessités, en utilisant les [attributs d'espaces de noms] de l'unité d'information de type élément englobante et ses ascendants.

[Définition :]  chaque fois que l'expression verbale se ramener à, quel qu'en soit sa forme, est utilisée dans ce chapitre en relation avec un ·QName· se trouvant dans un document de type schéma, la définition Résolution de QName (document de type schéma) (§3.15.3) doit être comprise ainsi :

Contraintes de représentation des schémas : Résolution de QName (document de type schéma)
Pour qu'un ·QName· se ramène à un composant de schéma d'un genre spécifié toutes les conditions suivantes doivent être remplies :
1 Ce composant est un membre de la valeur de la propriété du schéma qui correspond au document de type schéma à l'intérieur duquel le ·QName· apparaît, c'est à dire que l'un des cas suivants doit être vérifié :
1.1 Si le genre spécifié est une définition de type simple ou complexe, alors la propriété est l'ensemble des {définitions de types}.
1.2 Si le genre spécifié est une déclaration d'attribut, alors la propriété est l'ensemble des {déclarations d'attributs}.
1.3 Si le genre spécifié est une déclaration d'élément, alors la propriété est l'ensemble des {déclarations d'éléments}.
1.4 Si le genre spécifié est un groupe d'attributs, alors la propriété est l'ensemble des {définitions de groupes d'attributs}.
1.5 Si le genre spécifié est un groupe modèle, alors la propriété est l'ensemble des {définitions des groupes modèles}.
1.6 Si le genre spécifié est une déclaration de notation, alors la propriété est l'ensemble des {déclarations des notations}.
2 son {nom local} correspond au ·nom local· du ·QName· ;
3 son {espace de noms cible} est identique au ·nom de l'espace de noms· du ·QName· ;
4 son ·nom d'espace de noms· est soit l'espace de noms cible du document de type schéma contenant le ·QName· soit ce document de type schéma contient une unité d'information de type élément <import> dont la ·valeur réelle· de [l'attribut] namespace est identique à ce ·nom d'espace de noms·.

3.15.4 Règles de validation pour les schémas dans leur ensemble

Comme cela a été clairement exposé au chapitre Détails sur les composants de schéma (§3), le référencement de composants par leur nom, tant au niveau des composants de schéma que de la ·validation·, n'est normalement pas impliqué. Dans quelques cas cependant, des noms qualifiés apparaissant dans des unités d'information en cours de ·validation· doivent être ramenés à des composants de schéma par un processus de lookup. La contrainte suivante s'applique alors à ces cas :

Règle de validation : résolution de QName (instance)
Une paire composée d'un nom local et d'un nom d'espace de noms (à moins que ce dernier soit ·absent·) se ramenant à un composant de schéma d'un type spécifié dans le contexte de la ·validation· par appel de la propriété appropriée du schéma étant utilisé pour ·l'évaluation·. Chacune de ces propriétés indexent les composants par leur nom. La propriété à utiliser est déterminée par la sorte de composant spécifié, c'est à dire qu'un des cas suivants doit être vérifié :
1 Si le genre spécifié est une définition de type simple ou complexe, alors la propriété est l'ensemble des {définitions de types}.
2 Si le genre spécifié est une déclaration d'attribut, alors la propriété est l'ensemble des {déclarations d'attributs}.
3 Si le genre spécifié est une déclaration d'élément, alors la propriété est l'ensemble des {déclarations d'éléments}.
4 Si le genre spécifié est un groupe d'attributs, alors la propriété est l'ensemble des {définitions de groupes d'attributs}.
5 Si le genre spécifié est un groupe modèle, alors la propriété est l'ensemble des {définitions des groupes modèles}.
6 Si le genre spécifié est une déclaration de notation, alors la propriété est l'ensemble des {déclarations des notations}.
Le composant résultant est l'entrée dans la table dont le {nom local} correspond au nom local de la paire et dont {l'espace de noms cible} est identique au nom de l'espace de noms de la paire.

3.15.5 Contribution à l'ensemble d'information du schéma

Contribution à l'ensemble d'information du schéma : Information de schéma
Les composants d'un schéma fournissent une profusion d'informations sur la base de ·l'évaluation·, qui peut s'avérer utile pour les traitements ultérieurs. Refléter la structure des composants sous une forme facilement exploitable dans l'ensemble d'information résultant de la validation de schéma, est le sens de cette spécification dont l'un des objectifs est de rendre cette information disponible.

En conséquence, [Définition :]   par unité isomorphe à un composant, on signifie une unité d'information dont le type est équivalent à celui du composant, qui a une propriété par propriété d'origine du composant, qui a le même nom et dont la valeur est soit la même valeur atomique soit une unité d'information correspondant à la valeur de son composant, récursivement, si nécessaire.

Les programmes de traitment doivent ajouter à l'unité d'information de type élément sur laquelle s'est faite ·l'évaluation·, dans l'ensemble d'information résultant de la validation de schéma, la propriété suivante :
Contributions à l'ensemble d'information issu de la validité de schéma pour les unités d'information de type élément
[information de schéma]
Un ensemble d'unités d'information de type information de schéma de l'espace de noms, une pour chaque nom de l'espace de noms qui apparaît comme étant {l'espace de noms cible} de tout composant de schéma du schéma utilisé pour cette évaluation et une pour ·l'absence· quand un quelconque composant de schéma n'a pas {d'espace de noms cible}. Chaque unité d'information de type information de schéma de l'espace de noms a les propriétés et valeurs suivantes :
Contributions à l'ensemble d'information issu de la validité de schéma pour les unités d'information de type information de schéma d'espace de noms
[espace de noms du schéma]
Un nom de l'espace de noms sinon la valeur est ·absente·.
[composants de schéma]
Un ensemble (qui peut être vide) d'unités d'information de type composants de schéma, chacune étant une ·unité isomorphe· à un composant dont {l'espace de noms cible} est la propriété cible [espace de noms du schéma] ci-dessus, issue du schéma utilisé pour ·l'évaluation·.
[documents de type schéma]
Un ensemble (qui peut être vide) d'unités d'information de documents de type schéma, ayant des propriétés et des valeurs comme suit, pour chaque document de type schéma qui aura fourni des composants au schéma et dont l'attribut targetNamespace correspond à la propriété cible [espace de noms du schéma] décrite ci-dessus (ou dont l'attribut targetNamespace était ·absent· mais dont les composants auront contribué à cet espace de noms en ayant été inclus via l'élément <include> par un document de type schéma ayant cet attribut targetNamespace comme cela est décrit au chapitre Assembler un schéma pour un seul espace de noms cible à partir de plusieurs documents de définition .2.1)):
Contributions à l'ensemble d'information issu de la validité de schéma pour les unités d'information de documents de type schéma
[emplacement du document]
Soit un URI référence, quand il y en a un de disponible soit la propriété est ·absente·
[document]
Une unité d'information de type, quand il y en a une de disponible soit la propriété est·absente·
L'ensemble des {composants de schéma} est fourni par les programmes de traitement qui souhaitent fournir un seul point d'accès aux composants du schéma utilisé pendant ·l'évaluation·. Les programmes de traitement plus légers sont libres de laisser cet ensemble vide, mais si il est fourni, il doit contenir au minimum tous les composants de niveau supérieur (c'est à dire nommés) qui sont réellement présents dans ·l'évaluation·, soit directement soit indirectement (cas d'un composant anonyme qui apparaît réellement mais est contenu à l'intérieur d'un composant nommé qui n'apparaît pas).
Contribution à l'ensemble d'information du schéma : Matrice des ID/IDREF
Dans un ensemble d'information résultant de la validation de schéma, un ensemble d'unités d'information de type relation ID/IDREF est associé à l'unité d'information de type élément ·racine de validation· :
Contributions à l'ensemble d'information issu de la validité de schéma pour les unités d'information de type élément
[matrice des ID/IDREF]
Un ensemble (qui peut être vide) d'unités d'information de type relation ID/IDREF , comme spécifié ci-dessous.
[Définition :]  l'ensemble d'unités eligibles est constitué des unités d'information de type attribut ou élément pour lesquelles toutes les conditions suivantes sont vraies :
1 son [contexte de validation] est la ·racine de validation·;
2 elle a été ·validée· avec succès par rapport à une déclaration d'attribut comme cela est décrit au chapitre Attribut localement valide (§3.2.4) ou une déclaration d'élément comme cela est décrit au chapitre Elément localement valide (élément) (§3.3.4) (en fonction du cas approprié) dont la {définition de type} attribut ou la {définition de type} élément (respectivement) est l'une des définitions de types simples préfabriqués ID, IDREF ou IDREFS ou d'un type dérivé de ces définitions.

Alors il y a une relation ID/IDREF dans la [matrice des ID/IDREF] pour chaque chaîne de caractère distincte qui correspond à l'un des deux cas suivants :
1 la ·valeur réelle· d'un membre de ·l'ensemble des unités éligibles· dont la définition de type est, ou est dérivée, de ID ou IDREF;
2 l'une des unités de la ·valeur réelle· d'un membre de ·l'ensemble des unités éligibles· dont la définition de type est ou est dérivée de IDREFS.
Chaque relation ID/IDREF a les propriétés suivantes :
Contributions à l'ensemble d'information issu de la validité de schéma pour les unités d'information de type relation ID/IDREF
[id]
La chaîne de caractères identifiée ci-dessus.
[relation]
Un ensemble constitué de chaque unité d'information de type élément pour laquelle toutes les assertions suivantes sont vraies :
2 elle a une unité d'information de type attribut dans l'ensemble de ses [attributs] ou une unité d'information de type élément dans ses [enfants] qui fut ·validée· par la définition de type simple préfabriquée ID ou un type dérivée de cette définition dont la [valeur normalisée par le schéma] est [l'id] de cette relation ID/IDREF.
L'effet très net des définitions ci-dessus est d'avoir une entrée pour chaque chaîne de caractères utilisée comme identifiant, que ce soit par déclaration ou par référence, associée à ces éléments, si c'est le cas, qui implique réellement d'avoir cet identifiant. Reportez-vous au chapitre Racine de validation valide (ID/IDREF) (§3.3.4) ci-dessus pour connaître la règle de validation qui contrôle réellement la présence d'erreurs dans ce cas.
Remarque : L'unité d'information de type relation ID/IDREF, au contraire de la plupart des autres aspects de cette spécification, est essentiellement un mécanisme interne de gestion. Il est introduit pour supporter la définition faite au chapitre Racine de validation valide (ID/IDREF) (§3.3.4) ci-dessus. En conséquence, les programmes de traitement conformes peuvent, mais n'y sont pas obligés, l'exposer dans l'ensemble d'information résultant de la validation de schéma. En d'autres termes, la contrainte ci-dessus peut être interprétée comme étant une ·évaluation· se faisant comme si une telle unité d'ensemble d'information existait.

3.15.6 Contraintes sur les schémas dans leur ensemble

Toutes les schémas (référez-vous au chapitre Les schémas dans leur ensemble (§3.15)) doivent satisfaire la contrainte suivante.

Contraintes des composants de schéma : Exactitudes des propriétés de schéma
Toutes les conditions suivantes doivent être remplies :
1 Les valeurs des propriétés d'un schéma doivent être telles que décrites dans le tableau des propriétés du chapitre Le schéma lui-même (§3.15.1), modulo l'impact des sous-composants manquant (§5.3) ;
2 Chacun des ensembles de {définitions de types}, {déclarations d'éléments}, {définitions de groupes d'attributs}, {définitions des groupes modèles} et {déclarations des notations} ne doit pas contenir deux ou plus composants de schéma ayant le même {nom} et {espace de noms cible}.

4 Schémas et espaces de noms : accès et assemblage

Ce chapitre définit les mécanismes qui permettent à cette spécification d'établir les conditions préalables à ·l'évaluation·, à savoir l'accès à un ou plusieurs schémas. Ce chapitre expose également en détail la relation entre les schémas et les espaces de noms, tout comme les mécanismes de modularisation des schémas, incluant les possibilités d'incorporation des définitions et des déclarations d'un schéma dans un autre, y compris le cas où des modifications sont faites au passage.

Le chapitre sur la conformité (§2.4) décrit trois niveaux de conformité pour les programmes validant et le chapitre sur L'évaluation de la validité des schémas (§5) fournit une définition formelle de ·l'évaluation·. Ce chapitre expose en détail l'architecture à 3-niveaux découlant des trois niveaux de conformité qui sont :

  1. Le noyau de ·l'évaluation·, se rapportant aux composants de schéma et aux unités d'information des instances ;
  2. La représentation du schéma : les connexions entre les représentations XML et les composants de schéma, y compris les relations entre les espaces de noms et les composants de schéma ;
  3. Les directives pour l'interopérabilité des schémas XML sur le web : les connexions instance->schéma et schéma->schéma pour le WWW.

Le niveau 1 spécifie comment un schéma constitué de composants de schéma peut être utilisé dans ·l'évaluation· d'une unité d'information de type élément instance. Le niveau 2 spécifie l'utilisation des éléments <schema> dans des documents XML tels que la représentation standard en XML de l'information de schéma dans un large éventail de systèmes informatiques et d'environnements d'exécution. Pour supporter l'interopérabilité sur le World Wide Web en particulier, le niveau 3 fournit un ensemble de conventions pour le référencement des schémas sur le Web. Les chapitres ci-dessous contiennent les détails de chacun de ces trois niveaux.

next sub-section 4.1 Niveau 1: Résumé du noyau de l'évaluation de la validité du schéma

L'objectif fondamental du noyau de ·l'évaluation· est de définir ce que signifie ·l'évaluation· d'une seule unité d'information de type élément (mais en incluant ses descendants) par rapport à une définition de type complexe. Tous les programmes validant doivent implémenter ce noyau d'une manière qui se conforme exactement à cette spécification.

·l'évaluation· est définie en référence à un ·schéma XML· (récepteur qu'il ne s'agit pas d'un ·document de type schéma·) constitué (au moins) de l'ensemble des composants de schéma (définitions et déclarations) nécessaires à cette ·évaluation·. Cela n'est pas une définition circulaire, mais plutôt une observation à posteriori : aucune unité d'information de type élément ne peut être pleinement évaluée que si tous les composants rendus nécessaires par un quelconque aspect de son ·évaluation· (potentiellement récursive) sont présents dans le schéma.

Comme il l'est spécifié ci-dessus, chaque composant de schéma est associé directement or indirectement à un espace de noms cible mais peut faire également l'objet d'une association explicite sans espace de noms. Pour les documents ayant plusieurs espaces de noms, les composants de plusieurs espaces de noms cibles devront cohabiter dans un schéma.

Les programmes de traitement ont la possibilité soit d'assembler (voire d'optimiser ou pré-compiler) le schéma tout entier avant de commencer une étape ·d'évaluation· soit de ne l'assembler qu'au fil de l'eau, au fur et à mesure que les composants individuels sont nécessaires. Dans tous les cas, il est obligatoire :

Remarque : le noyau de ·l'évaluation· est défini en termes de composants de schéma du niveau abstrait et aucune référence n'est faite quant à la syntaxe de définition du schéma (c'est à dire la manière de représenter l'élément <schema>). Bien que la plupart des programmes ne feront que lire les schémas de ce format, d'autres pourraient très bien agir à partir soit de formes compilées, soit de représentations orientées programmation comme cela est possible avec quelques langages de programmation, etc...

L'obligation que les programmes de traitement concernés par les schémas ont, en tout cas en ce qui concerne le noyau de ·l'évaluation·, est de mettre en application une ou plusieurs options de ·l'évaluation· fournies ci-après au chapitre Evaluation de la validité de schéma (§5.2). Ni le choix de l'unité d'information de type élément pour cette ·évaluation·, ni celui des moyens utilisés pour initier ·l'évaluation· ne font partie du domaine d'application de cette spécification.

Bien que ·l'évaluation· soit définie récursivement, elle est aussi prévue pour pouvoir être mise en application dans des programmes de traitement à flot continu de données. Ceux-là peuvent choisir d'assembler le schéma de manière incrémentale pendant le traitement, par exemple, au fur et à mesure que de nouveaux espaces de noms sont rencontrés. La conséquence des exigences de base du noyau vues ci-dessus sur ce mode de fonctionnement est qu'il doit donner une sortie ·d'évaluation· identique à celle qui résulterait de l'évaluation qui aurait été réalisée en ayant préalablement assemblé le schéma en totalité.

previous sub-section next sub-section 4.2 Niveau 2 : documents de type schémas, espaces de noms et assemblage

Les sous-chapitres du chapitre Détails sur les composants de schéma (§3) définissent une représentation XML pour les définitions de types, les déclarations d'éléments etc., en spécifiant leur espace de noms cible et en les collectant dans des documents de type schéma. Les deux chapitres suivants traitent de l'assemblage complet d'un schéma pour une ·évaluation· à partir de sources multiples. Ils ne doivent pas être interprétés comme une forme de substitution de texte, mais plutôt comme des mécanismes de gestion de la répartition des définitions des composants de schéma, en ayant une sémantique appropriée aux schémas.

Remarque : L'architecture du noyau de ·l'évaluation· impose de pouvoir disposer d'un schéma complet ayant toutes les déclarations et définitions nécessaires. Cela peut impliquer de résoudre à la fois des références de type instance->schéma et d'autres de type schéma->schéma. Comme cela a déjà pu être observé plus haut au chapitre Conformité (§2.4), il est admis que les mécanismes précis qui gèrent ces liens doivent pouvoir évoluer dans le temps. En prévision de cela, cette spécification observe un principe conceptuel qui consiste à considérer les mécanismes de référencement schéma->schéma et ceux de référencement instance->schéma sur deux plans parallèles.
Remarque : Dans les chapitres ci-après, le terme "schemaLocation" recouvre une fonctionnalité qui appartient en réalité au niveau 3. Pour plus de facilité de lecture, il est documenté avec les mécanismes du niveau 2 d'import et d'inclusion, avec lesquels il est étroitement associé.

4.2.1 Assembler un schéma pour un seul espace de noms cible à partir de plusieurs documents de définition

Les composants d'un schéma pour un seul espace de noms cible peuvent être assemblés à partir de plusieurs ·documents de type schéma·, en clair plusieurs unités d'information de type élément <schema> :

Vue synthétique de la représentation XML : Unité d'information de type élément include

<include
  id = ID
  schemaLocation = anyURI
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?)
</include>

Une unité d'information <schema> peut contenir un nombre quelconque d'éléments <include> dont l'attribut schemaLocation, qui est concrètement une référence d'URI, identifie d'autres ·documents de type schéma·, c'est à dire d'autres unités d'information <schema>.

Le ·schéma XML· correspondant à <schema> ne contient pas seulement les composants correspondant aux définitions et déclarations [enfants], mais contient également tous les composants de tous les ·schémas XML· appelés par <include>. Les documents de type schéma qui sont inclus de la sorte doivent soit (a) avoir le même targetNamespace que le document les incluant, ou (b) ne pas avoir du tout cet attribut, auquel cas le document de type schéma qui est inclus est transféré dans l'espace de noms cible du document de type schéma l'incluant.

Contraintes de représentation des schémas : Contraintes et sémantique de l'inclusion
En plus des conditions imposées sur les unités d'information de type élément <include> par le schéma des schémas, toutes les conditions suivantes doivent être remplies :
1 Si la ·valeur réelle· de [l'attribut] schemaLocation est ramenée avec succès, l'une des conditions suivantes doit être vérifiée :
1.1 Il ramène une ressource qui est un (un fragment de) document XML (de type application/xml ou text/xml ayant une déclaration XML de préférence, mais cela n'est pas obligé), qui, à son tour, correspond à l'unité d'information de type élément <schema> d'un ensemble d'information bien formé, qui, à son tour, correspond à un schéma valide.
1.2 Il ramène une unité d'information de type élément <schema> d'un ensemble d'information bien formé, qui, à son tour, correspond à un schéma valide.

Dans les deux cas, si on appelle SII l'unité <schema> incluse, I le schéma valide et SII’ l'unité <schema> parent de l'unité où se trouve l'élément <include>.

2 L'une des conditions suivantes doit être vérifiée :
2.1 SII a un [attribut] targetNamespace et sa ·valeur réelle· est identique à la ·valeur réelle· de [l'attribut] targetNamespace de SII’ (qui doit avoir un tel [attribut]).
2.2 Ni SII ni SII’ n'ont [d'attribut] targetNamespace.
2.3 SII n'a pas [d'attribut] targetNamespace (mais SII’ en a un).
3 Un cas parmi les suivants doit être vérifié :
3.1 Si l'une des deux clauses 2.1 et 2.2 ci-dessus est satisfaite, alors le schéma correspondant à SII’ ne doit pas uniquement inclure les définitions et les déclarations appropriées de ses propres [enfants], mais aussi les composants identiques à tous les ·composants de schéma· de I.
3.2 Si la clause 2.3 ci-dessus est satisfaite, alors le schéma correspondant à l'élément <schema> parent de l'unité incluse doit non seulement avoir les définitions ou les déclarations appropriées de ses propres [enfants], mais aussi les composants identiques à tous les ·composants de schéma· de I, excepté le fait que partout où le nom de l'espace de noms cible ·absent· serait apparu, c'est la ·valeur réelle· de [l'attribut] targetNamespace de SII’ qui devra être utilisée. En particulier, cette valeur remplace ·absent· aux endroits suivants :
3.2.1 {l'espace de noms cible} des composants de schéma nommés, tant au niveau supérieur (dans le cas de définitions de types et de déclarations d'attributs et d'éléments imbriquées dont la valeur de l'attribut code était qualified) que de manière imbriquée à l'intérieur de définitions ;
3.2.2 La {contrainte d'espace de noms} d'un caractère générique, qu'elle soit exclue ou non ;

Ce n'est pas une erreur si la ·valeur réelle· de [l'attribut] schemaLocation n'arrive pas du tout à ramener l'information recherchée, dans ce cas l'inclusion correspondante n'est pas réalisée. Par contre, c'est une erreur quand l'information est ramenée mais que le reste de la clause 1 n'est ensuite pas satisfait. Un échec de la résolution peut très bien produire un résultat ·d'évaluation· moins complet, évidemment.

Remarque : Comme cela a été exposé au chapitre Sous-composants manquant (§5.3), les ·QName· utilisés dans les représentations XML peuvent échouer dans leur ·résolution·, rendant les composants incomplets et inutilisables à cause de sous-composants manquants. Pendant la construction du schéma, les mises en application de la spécification sont susceptibles de conserver en mémoire des valeurs de ·QName· en guise de référence, au cas où un traitement ultérieur fournirait l'information référencée. Les ·noms d'espaces de noms· cibles de type ·absent· qui se trouvent dans de telles références pas encore résolues issues de composants inclus doivent aussi être converties si la clause 3.2 est satisfaite.
Remarque : Le point ci-dessus est écrit de manière très précise afin que plusieurs inclusions du même document de type schéma ne constituent pas une violation de la clause 2 du chapitre Exactitudes des propriétés des schémas (§3.15.6), et les applications sont autorisées, voire encouragées, à éviter les inclusions répétitives du même document de type schéma afin de ne pas avoir à se retrouver obligées de gérer l'identité des composants individuellement.

4.2.2 Inclure des définitions de composants en les modifiant

Afin d'apporter un certain niveau de support en prévision de la nécessaire gestion des révisions et du versionnement des schémas, il est possible d'incorporer des composants correspondant à un document de type schéma en les modifiant. Les modifications sont définitives, c'est à dire, que seuls la version redéfinie des composants est utilisée, même quand ils sont référencés par d'autres composants incorporés, qu'ils soient eux-mêmes redéfinis ou non.

Vue synthétique de la représentation XML : unité d'information de type élément redefine 

<redefine
  id = ID
  schemaLocation = anyURI
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation | (simpleType | complexType | group | attributeGroup))*
</redefine>

Une unité d'information <schema> peut contenir n'importe quel nombre d'éléments <redefine>. L'attribut schemaLocation, qui contient une référence d'URI, pointe un ·document de type schéma·, c'est à dire contenant l'unité d'information <schema>.

Le ·schéma XML· correspondant à <schema> ne contient dès lors pas seulement les composants correspondant à ses propres définitions et déclarations [enfants], mais aussi tous les composants redéfinis ·des documents de type schéma identifiés par l'éléments <redefine>. Ceux-là doivent soit (a) avoir le même attribut targetNamespace que le document de type schéma les redéfinissant, soit (b) ne pas avoir cet attribut du tout, auquel cas le document de type schéma redéfini est transféré dans l'espace de noms cible du document de type schéma le redéfinissant.

Les définitions propres à l'élément <redefine> lui-même ne sont que les redéfinitions des composants du schéma pointé par l'élément <redefine>. C'est à dire :

Il n'est pas obligé de redéfinir tous les composants du document de type schéma pointé par l'éléments <redefine>.

Ce mécanisme est sensé fournir une approche déclarative et modulaire à la modification des schémas, avec des fonctionnalités pas différentes à l'exception des limites de ce qui aurait été possible de faire par une copie massive et une redéfinition des éléments via une étape d'édition. En particulier redéfinir un type n'est pas garanti contre les effets de bords : cela peut avoir des conséquences imprévues sur d'autres définitions de types qui seraient basées sur celle redéfinie, cela peut aller jusqu'au point où ces définitions deviennent elles-mêmes mal-formées.

Remarque : L'aspect "définitif" de la redéfinition renforce la nécessité d'avoir des implémentations permettant d'avoir des mécanismes de construction de composants basés sur une approche souple ou 'juste-à-temps', cela pour éviter de devoir imposer un ordre d'écriture des définitions et des références dans les documents de type schéma.
Exemple
v1.xsd:
 <xs:complexType name="personName">
  <xs:sequence>
   <xs:element name="title" minOccurs="0"/>
   <xs:element name="forename" minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
 </xs:complexType>

 <xs:element name="addressee" type="personName"/>

v2.xsd:
 <xs:redefine schemaLocation="v1.xsd">
  <xs:complexType name="personName">
   <xs:complexContent>
    <xs:extension base="personName">
     <xs:sequence>
      <xs:element name="generation" minOccurs="0"/>
     </xs:sequence>
    </xs:extension>
   </xs:complexContent>
  </xs:complexType>
 </xs:redefine>

 <xs:element name="author" type="personName"/>
  
Le schéma correspondant à v2.xsd contient tout ce qui est spécifié dans v1.xsd, à la différence du type redéfini personName, plus tout ce qui est propre à v2.xsd. D'après ce schéma, le contenu des éléments sous la contrainte de personName peuvent finir par l'élément generation. Cela n'est pas uniquement vrai pour l'élément author mais également pour l'élément addressee.
Contraintes de représentation des schémas : Contraintes et sémantique de la redéfinition
En plus des conditions imposées sur les unités d'information de type élément <redefine> par le schéma des schémas toutes les conditions suivantes doivent être remplies :
1 Si il y a des unités d'information [enfants] de type élément (exceptés les enfants <annotation>) alors la ·valeur réelle· de [l'attribut] schemaLocation doit être ramenée avec succès.
2 Si la ·valeur réelle· de [l'attribut] schemaLocation est ramenée avec succès l'une des conditions suivantes doit être vérifiée :
2.1 il ramène une ressource qui est un (un fragment de) document XML (référez-vous à la clause 1.1), qui, à son tour, correspond à une unité d'information de type élément <schema> constituant un ensemble bien formé d'informations, qui, à son tour, correspond à un schéma valide.
2.2 Il ramène une unité d'information de type élément <schema> constituant un ensemble bien formé d'informations, qui, à son tour, correspond à un schéma valide.

Dans les deux cas, on appelle SII l'unité <schema> qui est redéfinie, I le schéma valide et SII’ l'unité <schema> parent de l'unité redéfinissante <redefine>.

3 L'une des conditions suivantes doit être vérifiée :
3.1 SII a un [attribut] targetNamespace et sa ·valeur réelle· est identique à la ·valeur réelle· de [l'attribut] targetNamespace de SII’ (qui doit avoir un tel [attribut]).
3.2 Ni SII ni SII’ n'ont [d'attribut] targetNamespace.
3.3 SII n'a pas [d'attribut] targetNamespace (mais SII’ en a un).
4 L'un des cas suivants doit être vérifié :
4.1 Si l'une des deux clauses 3.1 et 3.2 ci-dessus est satisfaite, alors le schéma correspondant à SII’ ne doit pas seulement inclure les définitions et déclarations de ses propres [enfants], mais également les composants identiques à tous les ·composants de schéma· de I, à l'exception de ceux explicitement redéfinis (référez-vous au chapitre Redéfinition individuelle de composants (§4.2.2) ci-dessous).
4.2 Si la clause 3.3 ci-dessus est satisfaite, alors le schéma correspondant à SII’ ne doit pas seulement inclure les définitions et déclarations de ses propres [enfants], mais aussi les composants identiques à tous les ·composants de schéma· de I, à l'exception de ceux explicitement redéfinis (référez-vous au chapitre Redéfinition individuelle de composants (§4.2.2) ci-dessous), excepté que partout où le nom de l'espace de noms cible est ·absent· alors qu'il aurait dû apparaître, la ·valeur réelle· de [l'attribut] targetNamespace de SII’ est utilisée (référez-vous à la clause 3.2 du chapitre Contraintes et sémantique de l'inclusion (§4.2.1) pour plus de détails).
5 A l'intérieur des [enfants], chaque élément <simpleType> doit avoir un élément [enfants] <restriction> et chaque élément <complexType> doit avoir une restriction ou une extension parmi ses grands-[enfants] pour lesquels la ·valeur réelle· de [l'attribut] base doit être la même que la ·valeur réelle· de son propre attribut name augmentée de l'espace de noms cible ;
6 Pour chaque élément <group> se trouvant dans un des [enfants], l'un des cas suivants doit être vérifié :
6.1 Si il contient lui-même un <group>, à quelque niveau que ce soit, pour lequel la ·valeur réelle· de [l'attribut] ref est la même que celle de son propre attribut name augmentée de l'espace de noms cible, alors toutes les conditions suivantes doivent être remplies :
6.1.1 Il ne doit avoir exactement qu'un seul tel groupe.
6.1.2 Les ·valeurs réelles· des deux [attributs] minOccurs et maxOccurs de ce groupe doivent être 1 (Sinon, il doivent être ·absents·).
6.2 Si il n'a pas un tel auto-référencement, alors toutes les conditions suivantes doivent être remplies :
6.2.1 La ·valeur réelle· de son propre attribut name augmentée de l'espace de noms cible doit être ·ramenée· avec succès et doit se ramener à la définition d'un groupe modèle de I.
6.2.2 Le {groupe modèle} de la définition du groupe modèle qui lui correspond par la Représentation XML du composant de schéma de définition d'un groupe modèle (§3.7.2) doit être une ·restriction valide· du {groupe modèle} de la définition de ce groupe modèle dans I, conformément à ce qui est défini dans Particule valide (restriction) (§3.9.6).
7 Pour chaque élément <attributeGroup> se trouvant à l'intérieur d'un des [enfants], l'un des cas suivants doit être vérifié :
7.1 Si son contenu contient un élément <attributeGroup> dont la ·valeur réelle· de [l'attribut] ref est la même que la ·valeur réelle· de son propre attribut name augmentée de l'espace de noms cible, alors il ne doit y avoir exactement qu'un seul tel groupe.
7.2 Si il n'a pas un tel auto-référencement, alors toutes les conditions suivantes doivent être remplies :
7.2.1 La ·valeur réelle· de son propre attribut name augmentée de l'espace de noms cible doit être ·ramenée· avec succès et se ramener à la définition d'un groupe attribut de I.
7.2.2 L'ensemble des {attributs utilisés} et {l'attribut générique} de la définition du groupe d'attributs qui lui correspond via le Composant de schéma de définition d'un groupe d'attributs (§3.6.2) doivent être des ·restrictions valides· de l'ensemble des {attributs utilisés} et de {l'attribut générique} de la définition de ce groupe d'attributs dans I, tel que défini dans les clause 2, 3 et 4 du chapitre Dérivation valide (restriction, complexe) (§3.4.6) (où les références à la définition d'un type de base sont comprises comme étant des références à la définition du groupe d'attributs dans I).
Remarque : Un groupe d'attributs redéfini par restriction via la clause 7.2 correspond à un groupe d'attributs dont l'ensemble des {attributs utilisés} ne contient que des attributs dont l'utilisation correspond aux éléments <attribute> explicitement présents parmi les [enfants] de la version redéfinie (par l'élément <redefine>) de <attributeGroup>. Aucun héritage du groupe d'attributs redéfini par <redefine> n'intervient. Son {attribut générique} est, de manière similaire, purement basé sur la présence explicite de l'élément <anyAttribute>.
Contraintes de représentation des schémas : Redéfinition individuelle de composants
A chaque membre (différent de l'élément <annotation>) de l'ensemble des [enfants] de <redefine> correspond un ou deux composants de schéma issus du schéma qui contient l'élément <redefine> :
1 Les unités d'information [enfants] <simpleType> et <complexType> correspondent chacune à deux composants :
1.1 L'un correspond à l'unité de la définition supérieure ayant le même name dans le document de type schéma redéfini par <redefine> comme cela est défini au chapitre sur les Détails des composants de schéma (§3), excepté que son {nom} est ·absent· ;
1.2 L'autre correspond à l'unité d'information elle-même, comme cela est défini au chapitre sur les Détails sur les composants de schéma (§3), excepté que sa {définition du type de base} est le composant défini à la clause 1.1 ci-dessus.

Ce couple garantit que les contraintes de cohérence sur les définitions de types sont respectées tout en conservant le résultat souhaité, à savoir que les références à des noms de composants redéfinis dans les deux cas de schéma (celui qui est redéfini et celui qui redéfinit) ramènent le composant redéfini comme cela est précisé dans la clause 1.2 ci-dessus.

2 Les [enfants] <group> et <attributeGroup> correspondent chacun à un seul composant, comme cela est défini au chapitre Détails sur les composants de schéma (§3), excepté que, quand un auto-référencement basé sur un [attribut] ref ayant la même ·valeur réelle· que celle de l'attribut name de l'unité augmentée de l'espace de noms cible est ramené, alors un composant correspondant à l'unité de la définition supérieure de ce nom et du genre de celui utilisé dans I est utilisé.

Dans tous les cas il doit y avoir une unité de définition supérieure du nom et du genre dans le document de type schéma redéfini par <redefine>.

Remarque : Le texte ci-dessus est minutieusement écrit de manière à ce que plusieurs redéfinitions du même document de type schéma faites par <redefine> ne provoquent pas une violation de la clause 2 du chapitre Exactitudes des propriétés de schéma (§3.15.6), mais les applications sont autorisées, et même encouragées, à éviter la redéfinition successive d'un même document de type schéma par <redefine> afin de ne pas avoir à se retrouver obligées de gérer l'identité des composants individuellement (bien que cela devra être fait pour les redéfinitions individuelles elles-mêmes).

4.2.3 Les références aux composants de schéma à travers les espaces de noms

Comme cela est décrit au chapitre sur le Modèle de données abstrait de XML Schema (§2.2), chaque composant de niveau supérieur est associé à un espace de noms cible (ou, explicitement, avec aucun). Ce chapitre expose le mécanisme précis par lequel une référence à un composant étranger est faite, c'est à dire, un composant ayant un espace de noms cible différent de celui du composant le référençant. Ce chapitre donne la syntaxe de ce mécanisme sous la forme de définitions de schéma XML.

Deux points sont requis : il faut premièrement mettre en place un moyen d'adressage du composant étranger et deuxièmement il faut transmettre un signal spécifique aux programmes validant pour leur indiquer qu'un document de type schéma contient de telles références :

Vue synthétique de la représentation XML : Unité d'information de type élément import

<import
  id = ID
  namespace = anyURI
  schemaLocation = anyURI
  {tout attribut ayant un espace de noms différent de celui du schéma. . .}>
  Content: (annotation?)
</import>

L'unité d'information de type élément <import> identifie les espaces de noms utilisés dans des références externes, c'est à dire celles identifiées par leur ·QName· comme venant d'un espace de noms différent (ou aucun) que le targetNamespace du document de type schéma récepteur. La ·valeur réelle· de son [attribut] namespace indique que le document de type schéma récepteur peut contenir des références qualifiées à des composants de schéma de cet espace de noms (via un ou plusieurs préfixes déclarés porteurs de déclarations d'espace de noms standard). Si cette attribut est absent, alors l'import permet d'avoir des références non qualifiées à des composants n'ayant pas d'espace de noms cible. Remarquez que les composants qui sont importés n'ont pas besoin d'être de la forme d'un ·document de type schéma·; le programme de traitement est libre d'accéder ou de construire des composants en utilisant les moyens de ses propres choix.

La ·valeur réelle· de l'attribut schemaLocation, si il est présent, donne un indice sur l'emplacement où se trouve la version sérialisée d'un ·document de type schéma· ayant des déclarations et des définitions pour cet espace de noms (ou aucun). Quand il n'y a pas [d'attribut] schemaLocation, l'auteur du schéma laisse le soin de l'identification de ce schéma soit à l'instance, soit à l'application soit enfin à l'utilisateur, cela via les mécanismes décrits ci-dessous dans le chapitre sur le Niveau 3: document de type schéma accès et interopérabilité avec le Web (§4.3). Quand un attribut schemaLocation est présent, il ne peut contenir qu'une seule référence d'URI à propos de laquelle l'auteur du schéma certifie qu'elle ramènera une version sérialisée d'un ·document de type schéma· contenant le ou les composants dans l'espace de noms importé et référencé par ailleurs dans le document de type schéma récepteur.

Remarque : Puisque les deux [attributs] namespace et schemaLocation sont facultatifs, l'écriture sous la forme <import/> est autorisée. Cela permet simplement d'utiliser une référence non qualifiée à des composants étrangers n'ayant pas d'espace de noms cible en s'affranchissant de devoir donner un quelconque indice quant à leur emplacement.
Exemple
Le même espace de noms peur être utilisé à la fois pour un travail réel et pendant le travail de définition de composants étrangers :
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:html="http://www.w3.org/1999/xhtml"
        targetNamespace="uri:mywork" xmlns:my="uri:mywork">

 <import namespace="http://www.w3.org/1999/xhtml"/>

 <annotation>
  <documentation>
   <html:p>[Some documentation for my schema]</html:p>
  </documentation>
 </annotation>

 . . .

 <complexType name="myType">
  <séquence>
   <element ref="html:p" minOccurs="0"/>
  </séquence>
  . . .
 </complexType>

 <element name="myElt" type="my:myType"/>
</schema>
En traitant les références comme des ·QNames·, l'espace de noms cible et l'espace de noms étant différent pour les schémas XML (sauf cas du schéma des schémas), et en l'absence d'une redéclaration massive de l'espace de noms par défaut, alors doivent être explicitement qualifiés soit les références internes aux noms définis dans un document de type schéma soit les éléments de déclaration et définition du schéma eux-mêmes. Cet exemple utilise la première option mais la plupart des autres exemples de cette spécification a utilisé la seconde.
Contraintes de représentation des schémas : Contraintes et sémantique de l'importation
En plus des conditions imposées sur les unités d'information de type élément <import> par le schéma des schémas toutes les conditions suivantes doivent être remplies :
1 Un des cas suivants doit être vérifié :
1.1 Si [l'attribut] namespace est présent, alors sa ·valeur réelle· doit être différente de celle de [l'attribut] targetNamespace de l'élément <schema> englobant.
1.2 Si [l'attribut] namespace est absent, alors l'élément <schema> englobant doit avoir un [attribut] targetNamespace
2 Si la stratégie de référencement du schéma de l'application, en utilisant les ·valeurs réelles· des [attributs] schemaLocation et namespace, fournit un référent, comme cela est défini au chapitre sur la Stratégie de repérage des documents de type schéma (§4.3.2), l'une des conditions suivantes doit être remplie :
2.1 Le référent est une ressource qui est un (un fragment de) document XML (référez-vous à la clause 1.1), qui, à son tour, correspond à une unité d'information de type élément <schema> d'un ensemble d'information bien-formé, qui, à son tour, correspond à un schéma valide.
2.2 Le référent est une unité d'information de type élément <schema> d'un ensemble d'information bien-formé, qui, à son tour, correspond à un schéma valide.

Dans les deux cas on appelle SII l'unité <schema> et I le schéma valide.

3 L'un des cas suivants doit être vérifié :
3.1 Si il y a un [attribut] namespace, alors sa ·valeur réelle· doit être identique à celle de [l'attribut] targetNamespace de SII.
3.2 Si il n'y a pas [d'attribut] namespace, alors SII ne doit avoir aucun [attribut] targetNamespace

Ce n'est pas une erreur si la stratégie de référencement du schéma de l'application échoue. C'est une erreur si elle résout le référencement mais que le reste de la clause 2 ci-dessus échoue. L'échec de la recherche d'un référent peut tout à fait causer la production d'un résultat ·d'évaluation· très incomplet, bien évidemment.

Les ·composants de schéma· (c'est à dire les {définition de types}, les {déclarations d'attributs}, les {déclarations d'éléments}, les {définitions de groupes d'attributs}, les {définitions des groupes modèles}, les {déclarations des notations}) du schéma correspondant à l'unité d'information de type élément <schema> contenant elle-même une ou plusieurs unités d'information de type élément <import> ne doit pas seulement inclure les définitions et les déclarations de ses [enfants], mais aussi, et ceci pour chaque unité d'information de type élément <import> qui satisfait la clause 2 ci-dessus, l'ensemble des ·composants de schéma· identiques à tous les ·composants de schéma· de I.

Remarque : Le texte ci-dessus est écrit avec précision de manière à ce que plusieurs importations du même document de type schéma n'entraînent pas une violation de la clause 2 du chapitre sur les Exactitudes des propriétés de schéma (§3.15.6), mais les applications sont autorisées, voire même encouragées, à éviter les importations successive du même document de type schéma afin de ne pas avoir à se retrouver obligées de gérer l'identité des composants individuellement. En considérant que [l'attribut] schemaLocation n'est qu'une indication, les applications sont libres d'ignorer toutes les unités <import> après la première pour un espace de noms donné, cela indépendamment de la ·valeur réelle· de schemaLocation, mais le risque est alors de passer à côté d'une information utile quand les valeurs de schemaLocation évoluent.

previous sub-section 4.3 Niveau 3: accès et interopérabilité sur le Web des documents de type schéma

Les niveaux 1 et 2 fournissent le cadre de travail pour ·l'évaluation· et les définitions XML de schémas pour un grand nombre d'environnements. Avec le temps, les standards et les conventions relatifs au support de l'interopérabilité des mises en oeuvre de XML Schema sur le World Wide Web pourront évoluer. Le niveau 3 de conformité définit les fonctions minimum obligatoires pour tout programme validant ouvert au cas des ressources réparties sur le Web : on s'attend à ce que, avec le temps, d'autres standards (par exemple XML Packages) touchant directement les questions de l'interopérabilité sur le Web et dans d'autres environnements voient le jour et il ne faudrait alors pas avoir besoin de publier une nouvelle version de cette spécification.

4.3.1 Standards pour la représentation des schémas et la récupération de documents de type schéma sur le Web

Pour répondre au besoin d'interopérabilité, les ·documents de type schéma· sérialisés (comme toute ressource du Web) peuvent être identifiés par un URI et récupérés en utilisant les mécanismes standard du Web (par exemple http, https, etc.) Ces documents sur le Web doivent être des parties de documents XML (référez-vous à la clause 1.1) et représentés sous la forme standard définie par XML schema (décrite par le niveau 2), c'est à dire comme des unités d'information de type élément <schema>.

Remarque : il arrivera souvent qu'un document de type schéma soit en réalité un document XML 1.0 complet ayant <schema> comme élément racine. Il existera également des cas où les unités <schema> seront contenues dans d'autres documents et seront référencées comme fragments via une notation XPointer.
Remarque : Les différences entre logiciels serveurs et les politiques d'administration des sites web rendent difficile une quelconque recommandation d'une approche particulière aux requêtes de récupération de ·documents de type schéma· sérialisés. Une entête Accept de application/xml, text/xml; q=0.9, */* est peut-être un point de départ raisonnable.

4.3.2 Comment sont repérées les définitions de schéma sur le Web

Comme cela est décrit dans le chapitre Niveau 1: Résumé du noyau de l'évaluation de la validité du schéma (§4.1), les programmes validant sont responsables de la collecte des composants de schéma (définitions et déclarations) nécessaires à ·l'évaluation·. Ce chapitre introduit un ensemble de conventions normatives visant à faciliter l'interopérabilité des instances et schémas récupérés et traités sur le Web.

Remarque : comme cela est discuté dans la chapitre Niveau 2 : documents de type schémas, espaces de noms et assemblage (§4.2), des mécanismes de collecte indépendant du Web peuvent exister mais ceux-là sont en dehors du périmètre de cette spécification.

Les programmes validant supportant le Web sont libres de prendre en charge ·l'évaluation· par rapport à n'importe quel schéma arbitraire de n'importe laquelle des manières exposées au chapitre sur L'évaluation de la validité de schéma (§5.2). Cependant, il est pratique de pouvoir déterminer le schéma à utiliser sur la base d'une convention commune. En conséquence, un programme général de validation (c'est à dire ceux qui ne sont pas spécialisés dans un seul ou un ensemble de schémas prédéterminés) se chargeant de ·l'évaluation· d'un document sur le web doit se comporter comme suit :

L'assemblage du schéma complet pour son utilisation dans ·l'évaluation· est discuté au chapitre sur le Niveau 2 : document de type schémas, espaces de noms et assemblage (§4.2) ci-dessus. Les moyens utilisés pour repérer les documents de type schéma appropriés dépendent des programmes de validation et des applications, et sont soumis aux exigences suivantes :

  1. Les schémas sont représentés sur le Web sous la forme spécifiée ci-dessus dans le chapitre sur les Standards pour la représentation des schémas et la récupération de documents de type schéma sur le Web (§4.3.1) ;
  2. L'auteur d'un document utilise des déclarations d'espace de noms pour indiquer les interprétations qu'il souhaite avoir des noms qui s'y trouvent ; il peut y avoir ou non de schéma récupérable via le nom de l'espace de noms. En conséquence, que le programme de validation soit ou ne soit pas capable par lui-même de traiter ces cas de déréférencement, il doit toujours permettre à l'utilisateur de pouvoir modifier ce comportement par défaut.
    Remarque : L'expérience suggère qu'il n'est pas systématiquement sûr ou ne serait-ce que souhaitable, d'un point de vue des performances, de considérer le deréférencement des noms d'espaces de noms comme une question évidente. La communauté des utilisateurs et/ou les accords entre consommateur et fournisseur peuvent être à l'origine de conditions favorables pour qu'un tel déréférencement soit une stratégie raisonnable par défaut : Cette spécification autorise sans toutefois exiger que des communautés particulières puissent établir et mettre en oeuvre de telles conventions. Les utilisateurs sont toujours libres de fournir des noms d'espaces de noms comme information de repérage des schémas sur le web alors que le déréférencement est souhaité : voir ci-après.
  3. D'un autre côté, dans le cas où un auteur (humain ou mécanique) crée un document par rapport à un schéma particulier et qu'il certifie que tout ou partie du document est conforme à ce schéma, les [attributs] schemaLocation et noNamespaceSchemaLocation (de l'espace des noms réservés aux instances de XML Schema, c'est à dire, http://www.w3.org/2001/XMLSchema-instance, soit xsi:schemaLocation et xsi:noNamespaceSchemaLocation) sont fournis. Le premier attribut enregistre la garantie de l'auteur sous la forme d'une paire de référence d'URI (une pour le nom de l'espace de noms et l'autre pour l'information de repérage du schéma livrant des noms à ce nom d'espace de noms). Le deuxième attribut fournit de la même manière une référence d'URI servant d'information de repérage d'un schéma n'ayant pas [d'attribut] targetNamespace.

    A moins d'être pilotés autrement, par exemple par l'application appelante ou une option sur la ligne de commande, les programmes validant doivent essayer de déréférencer chacune des URI de repérage des schéma se trouvant dans la ·valeur réelle· de l'ensemble des [attributs] xsi:schemaLocation et xsi:noNamespaceSchemaLocation, référez-vous aux details ci-après.

  4. Les [attributs] xsi:schemaLocation et xsi:noNamespaceSchemaLocation peuvent apparaître sur n'importe quel élément. C'est cependant une erreur si l'un d'eux apparaît après la première apparition d'une unité d'information de type élément ou attribut à l'intérieur d'une unité d'information de type élément initialement ·validée· avec le [nom de l'espace de noms] qu'elle adresse. D'après les règles du chapitre sur le Niveau 1: Résumé du noyau de l'évaluation de la validité du schéma (§4.1), le schéma résultant peut être superficiellement assemblé, tout en étant par ailleurs stable sur l'ensemble du processus ·d'évaluation·. Bien que les attributs de repérage du schéma peuvent apparaître sur n'importe quel élément et peuvent être traités par un processus incrémental au fur et à mesure de leur découverte, leur effet sur ·l'évaluation· est essentiellement global. Les définitions et les déclarations restent actives au delà des frontières de l'élément où l'association a été déclarée.
Exemple
Plusieurs associations de schémas peuvent être déclarées en utilisant un seul attribut. Par exemple considérez une feuille de style :
 <stylesheet xmlns="http://www.w3.org/1999/XSL/Transform"
            xmlns:html="http://www.w3.org/1999/xhtml"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="http://www.w3.org/1999/XSL/Transform
                                http://www.w3.org/1999/XSL/Transform.xsd
                                http://www.w3.org/1999/xhtml
                                http://www.w3.org/1999/xhtml.xsd">
Les noms des espaces de noms spécifiés via l'attribut schemaLocation peuvent, sans que cela soit nécessaire, être identiques à ceux qualifiant réellement l'élément sur lequel on va trouver, au niveau de la balise ouvrante, une utilisation de ce même attribut ou au niveau des autres attributs de cet élément. Par exemple, comme ci-dessus, toute l'information de repérage du schéma peut être déclarée sur l'élément racine du document, si on le souhaite ainsi, indépendamment de l'endroit ou les espaces de noms sont réellement utilisés.
Contraintes de représentation des schémas : Stratégie de repérage des documents de type schéma
Etant donné un nom d'espace de noms (il peut y en avoir aucun) et (optionnellement) une référence d'URI issue de xsi:schemaLocation ou xsi:noNamespaceSchemaLocation, le programme validant peut mettre en application n'importe quelle combinaison des stratégies suivantes, dans n'importe quel ordre :
1 Ne rien faire, par exemple, parce qu'un schéma contenant les composants destinés au nom de l'espace de noms spécifié est déjà connu du système ou parce qu'il est joué d'avance que les efforts pour localiser les schémas seront vains (cas des systèmes embarqués par exemple) ;
2 En s'appuyant sur l'URI de repérage, identifier un schéma existant, soit comme une ressource qui est un document XML ou une unité d'information de type élément <schema>, dans un hypothétique référentiel de schéma local ;
3 En s'appuyant sur le nom de l'espace de noms, identifier un schéma existant, soit comme une ressource qui est un document XML ou une unité d'information de type élément <schema>, dans un hypothétique référentiel de schéma local ;
4 Essayer de résoudre l'URI de repérage, repérer une ressource sur le web qui est, ou contient, ou référence un élément <schema> ;
5 Essayer de résoudre le nom de l'espace de noms pour repérer une telle ressource.

Chaque fois que c'est possible, des configurations et/ou des options d'exécution des programmes permettant de choisir et/ou ordonner les stratégies mises en oeuvre doivent être fournies aux utilisateurs.

De nouvelles conventions ou de nouvelles options relatives à l'interopérabilité avec le web peuvent voir le jour dans le futur sans que cela remette en cause cette spécification. Par exemple, le W3C est actuellement en train de réfléchir sur de nouvelles propositions faites pour normaliser la présentation des ressources ayant un rapport avec des documents et/ou des espaces de noms particuliers : Cela viendrait typiquement se rajouter aux mécanismes décrits ici au niveau 3. Cette architecture facilite aussi l'innovation au niveau 2 : par exemple, il serait possible dans le future de définir un standard supplémentaire pour la représentation des composants de schéma qui autoriserait, par exemple, des définitions de types à être spécifiées morceau par morceau, plutôt que d'un seul bloc.

5 L'évaluation de la validité des schémas

L'architecture relative aux schémas permet de traiter un grand nombre de cas différents de documents XML : la validité de schéma n'est pas un prédicat binaire.

Cette spécification fait la distinction entre les erreurs de construction et de structure d'un schéma d'un côté avec celles liées aux résultats de la validation de schéma d'un autre côté.

next sub-section 5.1 Erreurs de construction et de structuration d'un schéma

Avant de pouvoir tenter une ·évaluation·, il est obligatoire de disposer d'un schéma. Les applications spécifiques sont libres de définir leur propres règles d'association d'un schéma à une ·évaluation· particulière, mais les programmes validant généralistes doivent implémenter la stratégie exposée au chapitre sur la Stratégie de repérage des documents de type schéma (§4.3.2), en commençant par l'interprétation des espaces de noms déclarés dans les documents ·évalués· et les ·valeurs réelles· des [attributs] xsi:schemaLocation et xsi:noNamespaceSchemaLocation qui s'y trouvent éventuellement, conjointement au traitement de l'information relative à l'identification du schéma ou à sa localisation ; information qui peut être spécifiquement fournie par les utilisateurs, via une option de l'application, quand elle le permet.

Une erreur doit être générée quand un schéma et les composants de l'une quelconque de ses propriétés, récursivement, échouent à satisfaire les contraintes correspondantes à celles exposées dans chacun des derniers sous-chapitres des sous-chapitres du grand chapitre sur les Détails sur les composants de schéma (§3).

Si un schéma est dérivé d'un ou plusieurs schémas (c'est à dire, une ou plusieurs unités d'information de type élément <schema>) basés sur les règles de correspondance exposées au chapitre sur les Détails sur les composants de schéma (§3) et à celui sur les Schémas et les espaces de noms : accès et assemblage (§4), deux conditions additionnelles existent alors :

  • Une erreur doit être générée si l'un quelconque des schémas n'est pas complètement valide par rapport au schéma des schémas (§A). C'est à dire que, appliquant une validation de schéma au schéma en question, la [tentative de validation] de l'unité d'information de type élément <schema> doit être full ou partial et cette unité d'information doit être [valide].
  • Une erreur doit être générée quand l'un quelconque de ces schémas est ou contient une quelconque unité d'information de type élément qui viole l'une quelconque des contraintes de représentation de schéma appropriée telles qu'elles sont récapitulées à l'annexe Contraintes de représentation des schémas (§C.3).

Les trois cas décrits ci-dessus sont les seuls types d'erreur que cette spécification définit. Par rapport aux programmes de contrôle de structure des schémas et des éditeurs de schémas, cette spécification n'impose aucune règle quant au comportement que doivent avoir les programmes après qu'ils aient détecté une erreur. Toutefois, faire une ·évaluation· d'entités de type schéma qui ne respecteraient pas toutes les exigences de cette spécification serait incohérent. En conséquence, les programmes validant conformes à cette spécification doivent refuser ·l'évaluation· de tels schémas.

previous sub-section next sub-section 5.2 Evaluation de la validité de schéma

Si un schéma remplit les conditions exprimées au chapitre sur les Erreurs de construction et de structuration d'un schéma (§5.1), alors la validité de schéma d'une unité d'information de type élément a un sens et peut être évaluée. Trois approches sont possibles :

1 L'utilisateur ou l'application choisit une définition de type complexe à partir de l'ensemble des {définitions de types} du schéma et lance l'évaluation de la validité de schéma (élément) (§3.3.4) (clause 1.2);
2 L'utilisateur ou l'application choisit une déclaration d'élément à partir de l'ensemble des {déclarations d'éléments} du schéma, contrôle que ses {nom} et {espace de noms cible} correspondent aux [nom local] et [nom de l'espace de noms] de l'unité et lance l'évaluation de la validité de schéma (élément) (§3.3.4) (clause 1.1) ;
3 Le programme commence l'évaluation de la validité de schéma (élément) (§3.3.4) sans qu'aucune déclaration ni définition ne lui soit spécifiée et une évaluation soit ·stricte· soit ·souple· s'ensuit, la nature de l'unité d'information et le schéma déterminent si il s'agit d'une déclaration d'élément (par nom) ou d'une définition de type (via xsi:type) ou autre chose.

Le résultat de cet effort, dans tous les cas, sera visible au niveau de l'ensemble des [tentatives de validation] et de la [validité] de l'unité d'information de type élément, de ses [attributs] et de ses [enfants], récursivement comme cela est défini aux chapitres sur les Résultats de l'évaluation (élément) (§3.3.5) et sur les Résultats de l'évaluation (attribut) (§3.2.5). Il appartient aux applications de décider ce qui constitue un résultat réussi.

Remarquez que chaque unité d'information de type élément et attribut participant à ·l'évaluation· auront aussi un [contexte de validation] qui renvoie à l'unité d'information de type élément sur laquelle commença ·l'évaluation·. [Définition :]  Cette unité, qui est l'unité d'information de type élément sur laquelle commença ·l'évaluation·, est appelée la racine de validation.

Remarque : Cette spécification n'est pas en train de redéfinir la notion d'élément racine de XML 1.0 tant au niveau des schémas que des instances. Une fonctionnalité comparable est mise en place, via la clause 2 ci-dessus, au moment du lancement de ·l'évaluation·.
Remarque : Cette spécification ne normalise en rien les ·évaluations· réalisées par couches successives. Il doit cependant être clair en lisant le texte ci-dessus que si un programme validant redémarre une ·évaluation· à partir de l'ensemble d'information issu d'une validation de schéma précédente, quelques unes des contributions qui s'y trouvent peuvent être écrasées. Le redémarrage est cependant parfois utile, particulièrement sur un noeud dont la [tentative de validation] est none, auquel cas il y a trois cas évidents pour lesquels la surcharge d'information après relance de l'évaluation est utile :
  • ·l'évaluation· n'a pas été tentée à cause d'un échec de ·validation·, mais les déclarations et/ou les définitions sont disponibles pour au moins quelques uns des [enfants] ou des [attributs]  ;
  • ·l'évaluation· n'a pas été tentée parce qu'une définition ou une déclaration nommée manquait, mais que le programme de validation a pu récupérer après avoir fait des efforts supplémentaires.
  • ·l'évaluation· n'a pas été tentée parce qu'elle a été sautée, mais le programme de traitement a au moins quelques déclarations et/ou définitions disponibles pour au moins quelques uns des [enfants] et des [attributs].

previous sub-section next sub-section 5.3 Sous-composants manquant

Au début du chapitre sur les Détails sur les composants de schéma (§3), une attention particulière est apportée au fait que la plupart des modèles de composants de schéma ont des propriétés elles-mêmes ayant comme valeur d'autres composants ou ensembles de composants, mais que lorsque des composants de schéma sont construits sur la base d'une correspondance directe avec des unités d'information de type élément, alors ces propriétés correspondent habituellement à des QNames dont la ·résolution· peut échouer, résultant en une ou plusieurs valeurs ·absentes· ou contenant des ·absences· là où un composant était requis.

Si à tout moment pendant ·l'évaluation·, une unité d'information de type élément ou attribut est en train d'être ·validée· par rapport à un composant de n'importe quel type dont n'importe laquelle de ces propriétés a ou contient une telle valeur ·absente·, le comportement de la ·validation· doit être modifiée de la manière suivante :

De part la spécification même de la propriété [tentative de validation] du Résultat de l'évaluation (élément) (§3.3.5), si la situation décrite ci-dessus arrive, la [tentative de validation] du document dans son entier aura une valeur qui ne pourra en aucun cas être full.

previous sub-section 5.4 Responsabilités des programmes validant

Les programmes validant sont responsables du traitement (de différentes manières) de documents XML, de schémas et de documents de type schéma et, en fonction du niveau de conformité (tel que cela est défini au chapitre sur la Conformité (§2.4)) qu'ils supportent, doivent respecter fidèlement les conditions présentées ci-dessus.


A Le schéma des schémas (partie normative)

La définition de XML Schema pour XML Schema tome 1 : Structures est elle-même présentée ici comme partie normative de la spécification et comme un exemple représentatif de XML Schema en se définissant lui-même à partir des constructions que la spécification définit. Les noms des types, éléments, attributs et des groupes du langage XML Schema définis ici évoquent leur propos mais ne sont que rarement verbeux.

Il y a des annotations dans des commentaires mais une version commentée plus complète aurait nécessité l'utilisation des moyens documentaires intégrés ou d'hyperliens vers des annotations externes pour lesquels aucun outil n'est vraiment disponible à ce jour.

Puisqu'un schéma conforme à XML Schema tome 1 : Structures est un document XML, il contient des déclarations XML et de document type optionnelles fournies ici par souci de fournir une information la plus complète que possible. L'élément racine schema définit un nouveau schéma. Puisque celui-là est un schéma pour XML Schema tome 1 : Structures, l'attribut targetNamespace référence l'espace de noms de XML Schema lui-même.

<?xml version='1.0' encoding='UTF-8'?>
<!-- XML Schema schema for XML Schemas: Part 1: Structures -->
<!DOCTYPE xs:schema PUBLIC "-//W3C//DTD XMLSCHEMA 200102//EN" "XMLSchema.dtd" [

<!-- fournit des informations de type ID même pour les analyseurs lexico-syntaxiques qui ne font que lire
     le sous-ensemble interne -->
<!ATTLIST xs:schema          id  ID  #IMPLIED>
<!ATTLIST xs:complexType     id  ID  #IMPLIED>
<!ATTLIST xs:complexContent  id  ID  #IMPLIED>
<!ATTLIST xs:simpleContent   id  ID  #IMPLIED>
<!ATTLIST xs:extension       id  ID  #IMPLIED>
<!ATTLIST xs:element         id  ID  #IMPLIED>
<!ATTLIST xs:group           id  ID  #IMPLIED> 
<!ATTLIST xs:all             id  ID  #IMPLIED>
<!ATTLIST xs:choice          id  ID  #IMPLIED>
<!ATTLIST xs:sequence        id  ID  #IMPLIED>
<!ATTLIST xs:any             id  ID  #IMPLIED>
<!ATTLIST xs:anyAttribute    id  ID  #IMPLIED>
<!ATTLIST xs:attribute       id  ID  #IMPLIED>
<!ATTLIST xs:attributeGroup  id  ID  #IMPLIED>
<!ATTLIST xs:unique          id  ID  #IMPLIED>
<!ATTLIST xs:key             id  ID  #IMPLIED>
<!ATTLIST xs:keyref          id  ID  #IMPLIED>
<!ATTLIST xs:selector        id  ID  #IMPLIED>
<!ATTLIST xs:field           id  ID  #IMPLIED>
<!ATTLIST xs:include         id  ID  #IMPLIED>
<!ATTLIST xs:import          id  ID  #IMPLIED>
<!ATTLIST xs:redefine        id  ID  #IMPLIED>
<!ATTLIST xs:notation        id  ID  #IMPLIED>
]>
<xs:schema targetNamespace="http://www.w3.org/2001/XMLSchema" blockDefault="#all" elementFormDefault="qualified" version="Id: XMLSchema.xsd,v 1.48 2001/04/24 18:56:39 ht Exp " xmlns:xs="http://www.w3.org/2001/XMLSchema" xml:lang="EN">

 <xs:annotation>
   <xs:documentation source="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/structures.html">
   Le schéma correspondant à ce document est normatif,
   respectant les contraintes syntaxiques qu'il exprime dans le langage
   XML Schema. La documentation (à l'intérieur d'éléments &lt;documentation>)
   ci-dessous, n'est pas normative, mais met plutôt en exergue des aspects importants de
   la recommandation du W3C dont ce schéma fait partie</xs:documentation>
 </xs:annotation>

 <xs:annotation>
   <xs:documentation>
   L'élément simpleType et tous ses membres sont définis
   dans datatypes.xsd</xs:documentation>
 </xs:annotation>

 <xs:include schemaLocation="datatypes.xsd"/>

 <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd">
   <xs:annotation>
     <xs:documentation>
       Donne accès aux groupes d'attributs xml: pour l'attribut xml:lang
       référencé dans les éléments 'schema' et 'documentation' ci-dessous.
     </xs:documentation>
   </xs:annotation>
 </xs:import>

 <xs:complexType name="openAttrs">
   <xs:annotation>
     <xs:documentation>
       Ce type est étendu par pratiquement tous les types de schéma
       pour permettre aux attributs provenant d'autres espaces de noms d'être
       rajoutés aux schémas utilisateurs.
     </xs:documentation>
   </xs:annotation>
   <xs:complexContent>
     <xs:restriction base="xs:anyType">
       <xs:anyAttribute namespace="##other" processContents="lax"/>
     </xs:restriction>
   </xs:complexContent>
 </xs:complexType>

 <xs:complexType name="annotated">
   <xs:annotation>
     <xs:documentation>
       Ce type est étendu par tous les types qui permettent d'avoir des annotations
       autres que &lt;schema&gt; lui-même
     </xs:documentation>
   </xs:annotation>
   <xs:complexContent>
     <xs:extension base="xs:openAttrs">
       <xs:sequence>
         <xs:element ref="xs:annotation" minOccurs="0"/>
       </xs:sequence>
       <xs:attribute name="id" type="xs:ID"/>
     </xs:extension>
   </xs:complexContent>
 </xs:complexType>

 <xs:group name="schemaTop">
  <xs:annotation>
   <xs:documentation>
   Ce groupe est pour les éléments 
   qui apparaissent librement au niveau supérieur des schémas.
   Tous leurs types sont une extension du type de base "annotated".</xs:documentation>
  </xs:annotation>
  <xs:choice>
   <xs:group ref="xs:redefinable"/>
   <xs:element ref="xs:element"/>
   <xs:element ref="xs:attribute"/>
   <xs:element ref="xs:notation"/>
  </xs:choice>
 </xs:group>
 
 <xs:group name="redefinable">
  <xs:annotation>
   <xs:documentation>
   Ce groupe est destiné aux éléments
   qui peuvent s'auto-redéfinir (se référer à &lt;redefine> ci-dessous).</xs:documentation>
  </xs:annotation>
  <xs:choice>
   <xs:element ref="xs:simpleType"/>
   <xs:element ref="xs:complexType"/>
   <xs:element ref="xs:group"/>
   <xs:element ref="xs:attributeGroup"/>
  </xs:choice>
 </xs:group>

 <xs:simpleType name="formChoice">
  <xs:annotation>
   <xs:documentation>
   Un type utilitaire reservé à un usage interne</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:NMTOKEN">
   <xs:enumeration value="qualified"/>
   <xs:enumeration value="unqualified"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:simpleType name="reducedDerivationControl">
  <xs:annotation>
   <xs:documentation>
   Un type utilitaire reservé à un usage interne</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:derivationControl">
   <xs:enumeration value="extension"/>
   <xs:enumeration value="restriction"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:simpleType name="derivationSet">
  <xs:annotation>
   <xs:documentation>
   Un type utilitaire reservé à un usage interne</xs:documentation>
   <xs:documentation>
   #all ou un sous-ensemble(pouvent être empty de {extension, restriction}</xs:documentation>
  </xs:annotation>
  <xs:union>
   <xs:simpleType>    
    <xs:restriction base="xs:token">
     <xs:enumeration value="#all"/>
    </xs:restriction>
   </xs:simpleType>
   <xs:simpleType>
    <xs:list itemType="xs:reducedDerivationControl"/>
   </xs:simpleType>
  </xs:union>
 </xs:simpleType>

 <xs:element name="schema" id="schema">
  <xs:annotation>
    <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-schema"/>
  </xs:annotation>
  <xs:complexType>
   <xs:complexContent>
    <xs:extension base="xs:openAttrs">
     <xs:sequence>
      <xs:choice minOccurs="0" maxOccurs="unbounded">
       <xs:element ref="xs:include"/>
       <xs:element ref="xs:import"/>
       <xs:element ref="xs:redefine"/>
       <xs:element ref="xs:annotation"/>
      </xs:choice>
      <xs:sequence minOccurs="0" maxOccurs="unbounded">
       <xs:group ref="xs:schemaTop"/>
       <xs:element ref="xs:annotation" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
     </xs:sequence>
     <xs:attribute name="targetNamespace" type="xs:anyURI"/>
     <xs:attribute name="version" type="xs:token"/>
     <xs:attribute name="finalDefault" type="xs:derivationSet" use="optional" default=""/>
     <xs:attribute name="blockDefault" type="xs:blockSet" use="optional" default=""/>
     <xs:attribute name="attributeFormDefault" type="xs:formChoice" use="optional" default="unqualified"/>
     <xs:attribute name="elementFormDefault" type="xs:formChoice" use="optional" default="unqualified"/>
     <xs:attribute name="id" type="xs:ID"/>
     <xs:attribute ref="xml:lang"/>
    </xs:extension>
   </xs:complexContent>
  </xs:complexType>

  <xs:key name="element">
   <xs:selector xpath="xs:element"/>
   <xs:field xpath="@name"/>
  </xs:key>

  <xs:key name="attribute">
   <xs:selector xpath="xs:attribute"/>
   <xs:field xpath="@name"/>
  </xs:key>

  <xs:key name="type">
   <xs:selector xpath="xs:complexType|xs:simpleType"/>
   <xs:field xpath="@name"/>
  </xs:key>
 
  <xs:key name="group">
   <xs:selector xpath="xs:group"/>
   <xs:field xpath="@name"/>
  </xs:key>
 
  <xs:key name="attributeGroup">
   <xs:selector xpath="xs:attributeGroup"/>
   <xs:field xpath="@name"/>
  </xs:key>
 
  <xs:key name="notation">
   <xs:selector xpath="xs:notation"/>
   <xs:field xpath="@name"/>
  </xs:key>

  <xs:key name="identityConstraint">
   <xs:selector xpath=".//xs:key|.//xs:unique|.//xs:keyref"/>
   <xs:field xpath="@name"/>
  </xs:key>

 </xs:element>

 <xs:simpleType name="allNNI">
  <xs:annotation><xs:documentation>
   for maxOccurs</xs:documentation></xs:annotation>
  <xs:union memberTypes="xs:nonNegativeInteger">
   <xs:simpleType>
    <xs:restriction base="xs:NMTOKEN">
     <xs:enumeration value="unbounded"/>
    </xs:restriction>
   </xs:simpleType>
  </xs:union>
 </xs:simpleType>

 <xs:attributeGroup name="occurs">
  <xs:annotation><xs:documentation>
   pour toutes les particules</xs:documentation></xs:annotation>
  <xs:attribute name="minOccurs" type="xs:nonNegativeInteger" use="optional" default="1"/>
  <xs:attribute name="maxOccurs" type="xs:allNNI" use="optional" default="1"/>
 </xs:attributeGroup>

 <xs:attributeGroup name="defRef">
  <xs:annotation><xs:documentation>
   pour un élément, un groupe et un groupe attribut,
   qui, tous les deux, définissent et référencent</xs:documentation></xs:annotation>
  <xs:attribute name="name" type="xs:NCName"/>
  <xs:attribute name="ref" type="xs:QName"/>
 </xs:attributeGroup>

 <xs:group name="typeDefParticle">
  <xs:annotation>
    <xs:documentation>
   'complexType' utilise ceci</xs:documentation></xs:annotation>
  <xs:choice>
   <xs:element name="group" type="xs:groupRef"/>
   <xs:element ref="xs:all"/>
   <xs:element ref="xs:choice"/>
   <xs:element ref="xs:sequence"/>
  </xs:choice>
 </xs:group>
 
 

 <xs:group name="nestedParticle">
  <xs:choice>
   <xs:element name="element" type="xs:localElement"/>
   <xs:element name="group" type="xs:groupRef"/>
   <xs:element ref="xs:choice"/>
   <xs:element ref="xs:sequence"/>
   <xs:element ref="xs:any"/>
  </xs:choice>
 </xs:group>
 
 <xs:group name="particle">
  <xs:choice>
   <xs:element name="element" type="xs:localElement"/>
   <xs:element name="group" type="xs:groupRef"/>
   <xs:element ref="xs:all"/>
   <xs:element ref="xs:choice"/>
   <xs:element ref="xs:sequence"/>
   <xs:element ref="xs:any"/>
  </xs:choice>
 </xs:group>
 
 <xs:complexType name="attribute">
  <xs:complexContent>
   <xs:extension base="xs:annotated">
    <xs:sequence>
     <xs:element name="simpleType" minOccurs="0" type="xs:localSimpleType"/>
    </xs:sequence>
    <xs:attributeGroup ref="xs:defRef"/>
    <xs:attribute name="type" type="xs:QName"/>
    <xs:attribute name="use" use="optional" default="optional">
     <xs:simpleType>
      <xs:restriction base="xs:NMTOKEN">
       <xs:enumeration value="prohibited"/>
       <xs:enumeration value="optional"/>
       <xs:enumeration value="required"/>
      </xs:restriction>
     </xs:simpleType>
    </xs:attribute>
    <xs:attribute name="default" type="xs:string"/>
    <xs:attribute name="fixed" type="xs:string"/>
    <xs:attribute name="form" type="xs:formChoice"/>
   </xs:extension>
  </xs:complexContent>
 </xs:complexType>
 
 <xs:complexType name="topLevelAttribute">
  <xs:complexContent>
   <xs:restriction base="xs:attribute">
    <xs:sequence>
     <xs:element ref="xs:annotation" minOccurs="0"/>
     <xs:element name="simpleType" minOccurs="0" type="xs:localSimpleType"/>
    </xs:sequence>
    <xs:attribute name="ref" use="prohibited"/>
    <xs:attribute name="form" use="prohibited"/>
    <xs:attribute name="use" use="prohibited"/>
    <xs:attribute name="name" use="required" type="xs:NCName"/>
   </xs:restriction>
  </xs:complexContent>
 </xs:complexType>

 <xs:group name="attrDecls">
  <xs:sequence>
   <xs:choice minOccurs="0" maxOccurs="unbounded">
    <xs:element name="attribute" type="xs:attribute"/>
    <xs:element name="attributeGroup" type="xs:attributeGroupRef"/>
   </xs:choice>
   <xs:element ref="xs:anyAttribute" minOccurs="0"/>
  </xs:sequence>
 </xs:group>

 <xs:element name="anyAttribute" type="xs:caractère générique" id="anyAttribute">
  <xs:annotation>
   <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-anyAttribute"/>
  </xs:annotation>
 </xs:element>

 <xs:group name="complexTypeModel">
  <xs:choice>
      <xs:element ref="xs:simpleContent"/>
      <xs:element ref="xs:complexContent"/>
      <xs:sequence>
       <xs:annotation>
        <xs:documentation>
   Cette branche est un raccourci pour
   &lt;complexContent>
   &lt;restriction base="xs:anyType">
   ...
   &lt;/restriction>
   &lt;/complexContent></xs:documentation>
       </xs:annotation>
       <xs:group ref="xs:typeDefParticle" minOccurs="0"/>
       <xs:group ref="xs:attrDecls"/>
      </xs:sequence>
  </xs:choice>
 </xs:group>

 <xs:complexType name="complexType" abstract="true">
  <xs:complexContent>
   <xs:extension base="xs:annotated">
    <xs:group ref="xs:complexTypeModel"/>
    <xs:attribute name="name" type="xs:NCName">
     <xs:annotation>
      <xs:documentation>
      Sera restreinte à required ou forbidden</xs:documentation>
     </xs:annotation>
    </xs:attribute>
    <xs:attribute name="mixte" type="xs:booléen" use="optional" default="faux">
     <xs:annotation>
      <xs:documentation>
      Interdit si l'enfant simpleContent est choisi.
      Peut être écrasée en mettant un enfant de type complexContent.</xs:documentation>
    </xs:annotation>
    </xs:attribute>
    <xs:attribute name="abstract" type="xs:booléen" use="optional" default="faux"/>
    <xs:attribute name="final" type="xs:derivationSet"/>
    <xs:attribute name="block" type="xs:derivationSet"/>
   </xs:extension>
  </xs:complexContent>
 </xs:complexType>
 
 <xs:complexType name="topLevelComplexType">
  <xs:complexContent>
   <xs:restriction base="xs:complexType">
    <xs:sequence>
     <xs:element ref="xs:annotation" minOccurs="0"/>
     <xs:group ref="xs:complexTypeModel"/>
    </xs:sequence>
    <xs:attribute name="name" type="xs:NCName" use="required"/>
   </xs:restriction>
  </xs:complexContent>
 </xs:complexType>
 
 <xs:complexType name="localComplexType">
  <xs:complexContent>
   <xs:restriction base="xs:complexType">
    <xs:sequence>
     <xs:element ref="xs:annotation" minOccurs="0"/>
     <xs:group ref="xs:complexTypeModel"/>
    </xs:sequence>
    <xs:attribute name="name" use="prohibited"/>
    <xs:attribute name="abstract" use="prohibited"/>
    <xs:attribute name="final" use="prohibited"/>
    <xs:attribute name="block" use="prohibited"/>
   </xs:restriction>
  </xs:complexContent>
 </xs:complexType>
 
 <xs:complexType name="restrictionType">
  <xs:complexContent>
   <xs:extension base="xs:annotated">
    <xs:sequence>
     <xs:choice>
      <xs:group ref="xs:typeDefParticle" minOccurs="0"/>
      <xs:group ref="xs:simpleRestrictionModel" minOccurs="0"/>
     </xs:choice>
     <xs:group ref="xs:attrDecls"/>
    </xs:sequence>
    <xs:attribute name="base" type="xs:QName" use="required"/>
   </xs:extension>
  </xs:complexContent>       
 </xs:complexType>

 <xs:complexType name="complexRestrictionType">
  <xs:complexContent>
   <xs:restriction base="xs:restrictionType">
    <xs:sequence>
     <xs:element ref="xs:annotation" minOccurs="0"/>
     <xs:group ref="xs:typeDefParticle" minOccurs="0"/>
     <xs:group ref="xs:attrDecls"/>
    </xs:sequence>
   </xs:restriction>
  </xs:complexContent>       
 </xs:complexType>

 <xs:complexType name="extensionType">
  <xs:complexContent>
   <xs:extension base="xs:annotated">
    <xs:sequence>
     <xs:group ref="xs:typeDefParticle" minOccurs="0"/>
     <xs:group ref="xs:attrDecls"/>
    </xs:sequence>
    <xs:attribute name="base" type="xs:QName" use="required"/>
   </xs:extension>
  </xs:complexContent>       
 </xs:complexType>

 <xs:element name="complexContent" id="complexContent">
  <xs:annotation>
   <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-complexContent"/>
  </xs:annotation>
  <xs:complexType>
   <xs:complexContent>
    <xs:extension base="xs:annotated">
     <xs:choice>
      <xs:element name="restriction" type="xs:complexRestrictionType"/>
      <xs:element name="extension" type="xs:extensionType"/>
     </xs:choice>     
     <xs:attribute name="mixte" type="xs:booléen">
      <xs:annotation>
       <xs:documentation>
       Ecrase toute initialisation faite sur un parent de type complexe.</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    </xs:extension>
   </xs:complexContent>
  </xs:complexType>
 </xs:element>

 <xs:complexType name="simpleRestrictionType">
  <xs:complexContent>
   <xs:restriction base="xs:restrictionType">
    <xs:sequence>
     <xs:element ref="xs:annotation" minOccurs="0"/>
     <xs:group ref="xs:simpleRestrictionModel" minOccurs="0"/>
     <xs:group ref="xs:attrDecls"/>
    </xs:sequence>
   </xs:restriction>
  </xs:complexContent>
 </xs:complexType>

 <xs:complexType name="simpleExtensionType">
  <xs:complexContent>
   <xs:restriction base="xs:extensionType">
    <xs:sequence>
     <xs:annotation>
      <xs:documentation>
      Pas de référence au groupe typeDefParticle</xs:documentation>
     </xs:annotation>
     <xs:element ref="xs:annotation" minOccurs="0"/>
     <xs:group ref="xs:attrDecls"/>
    </xs:sequence>
   </xs:restriction>
  </xs:complexContent>
 </xs:complexType>

 <xs:element name="simpleContent" id="simpleContent">
  <xs:annotation>
   <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-simpleContent"/>
  </xs:annotation>
  <xs:complexType>
   <xs:complexContent>
    <xs:extension base="xs:annotated">
     <xs:choice>
      <xs:element name="restriction" type="xs:simpleRestrictionType"/>
      <xs:element name="extension" type="xs:simpleExtensionType"/>
     </xs:choice>
    </xs:extension>
   </xs:complexContent>
  </xs:complexType>
 </xs:element>
 
 <xs:element name="complexType" type="xs:topLevelComplexType" id="complexType">
  <xs:annotation>
   <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-complexType"/>
  </xs:annotation>
 </xs:element>


  <xs:simpleType name="blockSet">
   <xs:annotation>
    <xs:documentation>
    Un type utilitaire reservé à un usage interne</xs:documentation>
    <xs:documentation>
    #all ou un sous-ensemble (pouvant être vide) de {substitution, extension,
    restriction}</xs:documentation>
   </xs:annotation>
   <xs:union>
    <xs:simpleType>    
     <xs:restriction base="xs:token">
      <xs:enumeration value="#all"/>
     </xs:restriction>
    </xs:simpleType>
    <xs:simpleType>
     <xs:list>
      <xs:simpleType>
       <xs:restriction base="xs:derivationControl">
        <xs:enumeration value="extension"/>
        <xs:enumeration value="restriction"/>
        <xs:enumeration value="substitution"/>
       </xs:restriction>
      </xs:simpleType>
     </xs:list>
    </xs:simpleType>
   </xs:union>  
  </xs:simpleType>

 <xs:complexType name="element" abstract="true">
  <xs:annotation>
   <xs:documentation>
   L'élément element peut être utilisé soit
   au  niveau supérieur pour définir une relation globale à un élément type,
   soit à l'intérieur d'un modèle de contenu pour référencer soit un élément soit un type
   défini globalement ou déclarer localement une relation à un éément type.
   La forme ref est interdite au niveau supérieur.</xs:documentation>
  </xs:annotation>

  <xs:complexContent>
   <xs:extension base="xs:annotated">
    <xs:sequence>
     <xs:choice minOccurs="0">
      <xs:element name="simpleType" type="xs:localSimpleType"/>
      <xs:element name="complexType" type="xs:localComplexType"/>
     </xs:choice>
     <xs:group ref="xs:identityConstraint" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attributeGroup ref="xs:defRef"/>
    <xs:attribute name="type" type="xs:QName"/>
    <xs:attribute name="substitutionGroup" type="xs:QName"/>
    <xs:attributeGroup ref="xs:occurs"/>
    <xs:attribute name="default" type="xs:string"/>
    <xs:attribute name="fixed" type="xs:string"/>
    <xs:attribute name="nillable" type="xs:booléen" use="optional" default="faux"/>
    <xs:attribute name="abstract" type="xs:booléen" use="optional" default="faux"/>
    <xs:attribute name="final" type="xs:de dérivation"/>
    <xs:attribute name="block" type="xs:blockSet"/>
    <xs:attribute name="form" type="xs:formChoice"/>
   </xs:extension>
  </xs:complexContent>
 </xs:complexType>
 
 <xs:complexType name="topLevelElement">
  <xs:complexContent>
   <xs:restriction base="xs:element">
    <xs:sequence>
     <xs:element ref="xs:annotation" minOccurs="0"/>
     <xs:choice minOccurs="0">
      <xs:element name="simpleType" type="xs:localSimpleType"/>
      <xs:element name="complexType" type="xs:localComplexType"/>
     </xs:choice>
     <xs:group ref="xs:identityConstraint" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="ref" use="prohibited"/>
    <xs:attribute name="form" use="prohibited"/>
    <xs:attribute name="minOccurs" use="prohibited"/>
    <xs:attribute name="maxOccurs" use="prohibited"/>
    <xs:attribute name="name" use="required" type="xs:NCName"/>
   </xs:restriction>
  </xs:complexContent>
 </xs:complexType>
 
 <xs:complexType name="localElement">
  <xs:complexContent>
   <xs:restriction base="xs:element">
    <xs:sequence>
     <xs:element ref="xs:annotation" minOccurs="0"/>
     <xs:choice minOccurs="0">
      <xs:element name="simpleType" type="xs:localSimpleType"/>
      <xs:element name="complexType" type="xs:localComplexType"/>
     </xs:choice>
     <xs:group ref="xs:identityConstraint" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="substitutionGroup" use="prohibited"/>
    <xs:attribute name="final" use="prohibited"/>
    <xs:attribute name="abstract" use="prohibited"/>
   </xs:restriction>
  </xs:complexContent>
 </xs:complexType>

 <xs:element name="element" type="xs:topLevelElement" id="element">
  <xs:annotation>
   <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-element"/>
  </xs:annotation>
 </xs:element>

 <xs:complexType name="group" abstract="true">
  <xs:annotation>
   <xs:documentation>
   type de groupe pour les groupes explicite, les groupes nommés de niveau supérieur
   et les références de groupes</xs:documentation>
  </xs:annotation>
  <xs:complexContent>
   <xs:extension base="xs:annotated">
    <xs:group ref="xs:particle" minOccurs="0" maxOccurs="unbounded"/>
    <xs:attributeGroup ref="xs:defRef"/>
    <xs:attributeGroup ref="xs:occurs"/>
   </xs:extension>
  </xs:complexContent>
 </xs:complexType>
 
 <xs:complexType name="realGroup">
  <xs:complexContent>
   <xs:restriction base="xs:group">
    <xs:sequence>
     <xs:element ref="xs:annotation" minOccurs="0"/>
     <xs:choice minOccurs="0" maxOccurs="1">
      <xs:element ref="xs:all"/>
      <xs:element ref="xs:choice"/>
      <xs:element ref="xs:sequence"/>
     </xs:choice>
    </xs:sequence>
   </xs:restriction>
  </xs:complexContent>
 </xs:complexType>

 <xs:complexType name="namedGroup">
  <xs:annotation>
   <xs:documentation>
    Ceci devrait être une dérivation de realGroup,
    mais c'est trop compliqué pour le moment</xs:documentation>
  </xs:annotation>
  <xs:sequence>
     <xs:element ref="xs:annotation" minOccurs="0"/>
     <xs:choice minOccurs="1" maxOccurs="1">
      <xs:element name="all">
       <xs:complexType>
        <xs:complexContent>
         <xs:restriction base="xs:all">
          <xs:group ref="xs:allModel"/>
          <xs:attribute name="minOccurs" use="prohibited"/>
          <xs:attribute name="maxOccurs" use="prohibited"/>
         </xs:restriction>
        </xs:complexContent>
       </xs:complexType>
      </xs:element>
      <xs:element name="choice" type="xs:simpleExplicitGroup"/>
      <xs:element name="sequence" type="xs:simpleExplicitGroup"/>
     </xs:choice>
    </xs:sequence>
    <xs:attribute name="name" use="required" type="xs:NCName"/>
    <xs:attribute name="ref" use="prohibited"/>
    <xs:attribute name="minOccurs" use="prohibited"/>
    <xs:attribute name="maxOccurs" use="prohibited"/>
 </xs:complexType>

 <xs:complexType name="groupRef">
  <xs:complexContent>
   <xs:restriction base="xs:realGroup">
    <xs:sequence>
     <xs:element ref="xs:annotation" minOccurs="0"/>
    </xs:sequence>
    <xs:attribute name="ref" use="required" type="xs:QName"/>
    <xs:attribute name="name" use="prohibited"/>
   </xs:restriction>
  </xs:complexContent>
 </xs:complexType>

 <xs:complexType name="explicitGroup">
  <xs:annotation>
   <xs:documentation>
   groupe type pour les trois sortes de groupes</xs:documentation>
  </xs:annotation>
  <xs:complexContent>
   <xs:restriction base="xs:group">
    <xs:sequence>
     <xs:element ref="xs:annotation" minOccurs="0"/>
     <xs:group ref="xs:nestedParticle" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="name" type="xs:NCName" use="prohibited"/>
    <xs:attribute name="ref" type="xs:QName" use="prohibited"/>
   </xs:restriction>
  </xs:complexContent>
 </xs:complexType>
 
 <xs:complexType name="simpleExplicitGroup">
  <xs:complexContent>
   <xs:restriction base="xs:explicitGroup">
    <xs:sequence>
     <xs:element ref="xs:annotation" minOccurs="0"/>
     <xs:group ref="xs:nestedParticle" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="minOccurs" use="prohibited"/>
    <xs:attribute name="maxOccurs" use="prohibited"/>
   </xs:restriction>
  </xs:complexContent>
 </xs:complexType>
 
 <xs:group name="allModel">
  <xs:sequence>
      <xs:element ref="xs:annotation" minOccurs="0"/>
      <xs:element name="element" minOccurs="0" maxOccurs="unbounded">
       <xs:complexType>
        <xs:annotation>
         <xs:documentation>valeurs restreintes des particules max/min</xs:documentation>
        </xs:annotation>
        <xs:complexContent>
         <xs:restriction base="xs:localElement">
          <xs:sequence>
           <xs:element ref="xs:annotation" minOccurs="0"/>
           <xs:choice minOccurs="0">
            <xs:element name="simpleType" type="xs:localSimpleType"/>
            <xs:element name="complexType" type="xs:localComplexType"/>
           </xs:choice>
           <xs:group ref="xs:identityConstraint" minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
          <xs:attribute name="minOccurs" use="optional" default="1">
           <xs:simpleType>
            <xs:restriction base="xs:nonNegativeInteger">
             <xs:enumeration value="0"/>
             <xs:enumeration value="1"/>
            </xs:restriction>
           </xs:simpleType>
          </xs:attribute>
          <xs:attribute name="maxOccurs" use="optional" default="1">
           <xs:simpleType>
            <xs:restriction base="xs:allNNI">
             <xs:enumeration value="0"/>
             <xs:enumeration value="1"/>
            </xs:restriction>
           </xs:simpleType>
          </xs:attribute>
         </xs:restriction>
        </xs:complexContent>
       </xs:complexType>    
      </xs:element>
     </xs:sequence>
 </xs:group>

  <xs:complexType name="all">
   <xs:annotation>
    <xs:documentation>
   Seuls des éléments sont autorisés à l'intérieur</xs:documentation>
   </xs:annotation>
   <xs:complexContent>
    <xs:restriction base="xs:explicitGroup">
     <xs:group ref="xs:allModel"/>
     <xs:attribute name="minOccurs" use="optional" default="1">
      <xs:simpleType>
       <xs:restriction base="xs:nonNegativeInteger">
        <xs:enumeration value="0"/>
        <xs:enumeration value="1"/>
       </xs:restriction>
      </xs:simpleType>
     </xs:attribute>
     <xs:attribute name="maxOccurs" use="optional" default="1">
      <xs:simpleType>
       <xs:restriction base="xs:allNNI">
        <xs:enumeration value="1"/>
       </xs:restriction>
      </xs:simpleType>
     </xs:attribute>
    </xs:restriction>
   </xs:complexContent>
  </xs:complexType>

 <xs:element name="all" id="all" type="xs:all">
  <xs:annotation>
   <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-all"/>
  </xs:annotation>
 </xs:element>

 <xs:element name="choice" type="xs:explicitGroup" id="choice">
  <xs:annotation>
   <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-choice"/>
  </xs:annotation>
 </xs:element>

 <xs:element name="sequence" type="xs:explicitGroup" id="sequence">
  <xs:annotation>
   <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-sequence"/>
  </xs:annotation>
 </xs:element>

 <xs:element name="group" type="xs:namedGroup" id="group">
  <xs:annotation>
   <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-group"/>
  </xs:annotation>
 </xs:element>

 <xs:complexType name="wildcard">
  <xs:complexContent>
   <xs:extension base="xs:annotated">
    <xs:attribute name="namespace" type="xs:namespaceList" use="optional" default="##any"/>
    <xs:attribute name="processContents" use="optional" default="strict">
     <xs:simpleType>
      <xs:restriction base="xs:NMTOKEN">
       <xs:enumeration value="skip"/>
       <xs:enumeration value="lax"/>
       <xs:enumeration value="strict"/>
      </xs:restriction>
     </xs:simpleType>
    </xs:attribute>
   </xs:extension>
  </xs:complexContent>
 </xs:complexType>

 <xs:element name="any" id="any">
  <xs:annotation>
   <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-any"/>
  </xs:annotation>
  <xs:complexType>
   <xs:complexContent>
    <xs:extension base="xs:wildcard">
     <xs:attributeGroup ref="xs:occurs"/>
    </xs:extension>
   </xs:complexContent>
  </xs:complexType>
 </xs:element>

  <xs:annotation>
   <xs:documentation>
   Type simple pour la valeur de l'attribut 'namespace' de
   'any' et 'anyAttribute'</xs:documentation>
  </xs:annotation>
  <xs:annotation>
   <xs:documentation>
   La valeur est
              ##any      - - tout WFXML/attribut non-conflictuel du tout

              ##other    - - tout WFXML/attribut non-conflictuel d'espace de nom autre que l'espace de nom cible
                              
              ##local    - - tout WFXML/attribut non qualifié non-conflictuel 

              une ou     - - tout WFXML/attribut non-conflictuel venant des espaces de noms listés
              plusieurs        
              références URI
              (séparées par des blancs)

    ##targetNamespace ou ##local peuvent apparaître dans la liste ci-dessus,
        pour faire référence, respectivement, à l'espace de noms cible du schéma 
        englobant ou à l'espace de noms cible absent</xs:documentation>
  </xs:annotation>

 <xs:simpleType name="namespaceList">
  <xs:annotation>
   <xs:documentation>
   Un type utilitaire réservé à un usage interne</xs:documentation>
  </xs:annotation>
  <xs:union>
   <xs:simpleType>
    <xs:restriction base="xs:token">
     <xs:enumeration value="##any"/>
     <xs:enumeration value="##other"/>
    </xs:restriction>
   </xs:simpleType>
   <xs:simpleType>
    <xs:list>
     <xs:simpleType>
      <xs:union memberTypes="xs:anyURI">
       <xs:simpleType>
        <xs:restriction base="xs:token">
         <xs:enumeration value="##targetNamespace"/>
         <xs:enumeration value="##local"/>
        </xs:restriction>
       </xs:simpleType>
      </xs:union>
     </xs:simpleType>
    </xs:list>
   </xs:simpleType>
  </xs:union>
 </xs:simpleType>

 <xs:element name="attribute" type="xs:topLevelAttribute" id="attribute">
  <xs:annotation>
   <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-attribute"/>
  </xs:annotation>
 </xs:element>

 <xs:complexType name="attributeGroup" abstract="true">
  <xs:complexContent>
   <xs:extension base="xs:annotated">
    <xs:group ref="xs:attrDecls"/>
    <xs:attributeGroup ref="xs:defRef"/>
   </xs:extension>
  </xs:complexContent>
 </xs:complexType>
 
 <xs:complexType name="namedAttributeGroup">
  <xs:complexContent>
   <xs:restriction base="xs:attributeGroup">
    <xs:sequence>
     <xs:element ref="xs:annotation" minOccurs="0"/>
     <xs:group ref="xs:attrDecls"/>
    </xs:sequence>
    <xs:attribute name="name" use="required" type="xs:NCName"/>
    <xs:attribute name="ref" use="prohibited"/>
   </xs:restriction>
  </xs:complexContent>
 </xs:complexType>

 <xs:complexType name="attributeGroupRef">
  <xs:complexContent>
   <xs:restriction base="xs:attributeGroup">
    <xs:sequence>
     <xs:element ref="xs:annotation" minOccurs="0"/>
    </xs:sequence>
    <xs:attribute name="ref" use="required" type="xs:QName"/>
    <xs:attribute name="name" use="prohibited"/>
   </xs:restriction>
  </xs:complexContent>
 </xs:complexType>

 <xs:element name="attributeGroup" type="xs:namedAttributeGroup" id="attributeGroup">
  <xs:annotation>
   <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-attributeGroup"/>
  </xs:annotation>
 </xs:element>

 <xs:element name="include" id="include">
  <xs:annotation>
   <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-include"/>
  </xs:annotation>
  <xs:complexType>
   <xs:complexContent>
    <xs:extension base="xs:annotated">
     <xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/>
    </xs:extension>
   </xs:complexContent>
  </xs:complexType>
 </xs:element>

 <xs:element name="redefine" id="redefine">
  <xs:annotation>
   <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-redefine"/>
  </xs:annotation>
  <xs:complexType>
   <xs:complexContent>
    <xs:extension base="xs:openAttrs">
     <xs:choice minOccurs="0" maxOccurs="unbounded">
      <xs:element ref="xs:annotation"/>
      <xs:group ref="xs:redefinable"/>
     </xs:choice>
     <xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/>
     <xs:attribute name="id" type="xs:ID"/>
    </xs:extension>
   </xs:complexContent>
  </xs:complexType>
 </xs:element>

 <xs:element name="import" id="import">
  <xs:annotation>
   <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-import"/>
  </xs:annotation>
  <xs:complexType>
   <xs:complexContent>
    <xs:extension base="xs:annotated">
     <xs:attribute name="namespace" type="xs:anyURI"/>
     <xs:attribute name="schemaLocation" type="xs:anyURI"/>
    </xs:extension>
   </xs:complexContent>
  </xs:complexType>
 </xs:element>

 <xs:element name="selector" id="selector">
  <xs:annotation>
   <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-selector"/>
  </xs:annotation>
  <xs:complexType>
  <xs:complexContent>
   <xs:extension base="xs:annotated">
     <xs:attribute name="xpath" use="required">
      <xs:simpleType>
       <xs:annotation>
        <xs:documentation>Un sous-ensemble des expressions XPath pour une
        utilisation dans les sélecteurs</xs:documentation>
        <xs:documentation>
         Un type utilitaire réservé à un usage interne
       </xs:documentation>
       </xs:annotation>
       <xs:restriction base="xs:token">
        <xs:annotation>
         <xs:documentation>Le motif suivant à comme objectif de permettre 
               l'usage d'expressions XPath conformes aux règles de
               production suivantes :
          Selector    ::=    Path ( '|' Path )*  
          Path    ::=    ('.//')? Step ( '/' Step )*  
          Step    ::=    '.' | NameTest  
          NameTest    ::=    QName | '*' | NCName ':' '*'  
          child:: est aussi autorisé
         </xs:documentation>
        </xs:annotation>
        <xs:pattern value="(\.//)?(((child::)?((\i\c*:)?(\i\c*|\*)))|\.)(/(((child::)?((\i\c*:)?(\i\c*|\*)))|\.))*(\|(\.//)?(((child::)?((\i\c*:)?(\i\c*|\*)))|\.)(/(((child::)?((\i\c*:)?(\i\c*|\*)))|\.))*)*">
        </xs:pattern>
       </xs:restriction>
      </xs:simpleType>
     </xs:attribute>
   </xs:extension>
  </xs:complexContent>
 </xs:complexType>
 </xs:element>

 <xs:element name="field" id="field">
  <xs:annotation>
   <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-field"/>
  </xs:annotation>
  <xs:complexType>
  <xs:complexContent>
   <xs:extension base="xs:annotated">
     <xs:attribute name="xpath" use="required">
      <xs:simpleType>
       <xs:annotation>
        <xs:documentation>
        Un sous-ensemble des expressions XPath pour un usage dans des champs
        </xs:documentation>
        <xs:documentation>
         Un type utilitaire réservé à un usage interne
       </xs:documentation>
       </xs:annotation>
       <xs:restriction base="xs:token">
        <xs:annotation>
         <xs:documentation>Le motif suivant à comme objectif de permettre 
               l'usage d'expressions XPath conformes aux règles de
               production suivantes, comme pour les formules de sélection,
               à la modification suivante près :
          Path    ::=    ('.//')? ( Step '/' )* ( Step | '@' NameTest ) 
         </xs:documentation>
        </xs:annotation>
        <xs:pattern value="(\.//)?((((child::)?((\i\c*:)?(\i\c*|\*)))|\.)/)*((((child::)?((\i\c*:)?(\i\c*|\*)))|\.)|((attribute::|@)((\i\c*:)?(\i\c*|\*))))(\|(\.//)?((((child::)?((\i\c*:)?(\i\c*|\*)))|\.)/)*((((child::)?((\i\c*:)?(\i\c*|\*)))|\.)|((attribute::|@)((\i\c*:)?(\i\c*|\*)))))*">
        </xs:pattern>
       </xs:restriction>
      </xs:simpleType>
     </xs:attribute>
   </xs:extension>
  </xs:complexContent>
 </xs:complexType>
 </xs:element>

 <xs:complexType name="keybase">
  <xs:complexContent>
   <xs:extension base="xs:annotated">
    <xs:sequence>
     <xs:element ref="xs:selector"/>
     <xs:element ref="xs:field" minOccurs="1" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="name" type="xs:NCName" use="required"/>
   </xs:extension>
  </xs:complexContent>
 </xs:complexType>

 <xs:group name="identityConstraint">
  <xs:annotation>
   <xs:documentation>Les trois sortes de contraintes d'identité,
                     toutes ayant soit le même type que 'keybase' soit en étant dérivées.
   </xs:documentation>
  </xs:annotation>
  <xs:choice>
   <xs:element ref="xs:unique"/>
   <xs:element ref="xs:key"/>
   <xs:element ref="xs:keyref"/>
  </xs:choice>
 </xs:group>

 <xs:element name="unique" type="xs:keybase" id="unique">
  <xs:annotation>
   <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-unique"/>
  </xs:annotation>
 </xs:element>
 <xs:element name="key" type="xs:keybase" id="key">
  <xs:annotation>
   <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-key"/>
  </xs:annotation>
 </xs:element>
 <xs:element name="keyref" id="keyref">
  <xs:annotation>
   <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-keyref"/>
  </xs:annotation>
  <xs:complexType>
   <xs:complexContent>
    <xs:extension base="xs:keybase">
     <xs:attribute name="refer" type="xs:QName" use="required"/>
    </xs:extension>
   </xs:complexContent>
  </xs:complexType>
 </xs:element>

 <xs:element name="notation" id="notation">
  <xs:annotation>
   <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-notation"/>
  </xs:annotation>
  <xs:complexType>
   <xs:complexContent>
    <xs:extension base="xs:annotated">
     <xs:attribute name="name" type="xs:NCName" use="required"/>
     <xs:attribute name="public" type="xs:public" use="required"/>
     <xs:attribute name="system" type="xs:anyURI"/>
    </xs:extension>
   </xs:complexContent>
  </xs:complexType>
 </xs:element>

 <xs:simpleType name="public">
  <xs:annotation>
   <xs:documentation>
   Un type utilitaire réservé à un usage interne
</xs:documentation>
   <xs:documentation>
   Un identifiant publique, comme pour l'ISO 8879</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:token"/>
 </xs:simpleType>

 <xs:element name="appinfo" id="appinfo">
   <xs:annotation>
     <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-appinfo"/>
   </xs:annotation>
   <xs:complexType mixte="true">
     <xs:sequence minOccurs="0" maxOccurs="unbounded">
       <xs:any processContents="lax"/>
     </xs:sequence>
     <xs:attribute name="source" type="xs:anyURI"/>
   </xs:complexType>
 </xs:element>

 <xs:element name="documentation" id="documentation">
   <xs:annotation>
     <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-documentation"/>
   </xs:annotation>
   <xs:complexType mixte="true">
     <xs:sequence minOccurs="0" maxOccurs="unbounded">
       <xs:any processContents="lax"/>
     </xs:sequence>
     <xs:attribute name="source" type="xs:anyURI"/>
   <xs:attribute ref="xml:lang"/>
   </xs:complexType>
 </xs:element>

 <xs:element name="annotation" id="annotation">
   <xs:annotation>
     <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-annotation"/>
   </xs:annotation>
   <xs:complexType>
    <xs:complexContent>
     <xs:extension base="xs:openAttrs">
      <xs:choice minOccurs="0" maxOccurs="unbounded">
       <xs:element ref="xs:appinfo"/>
       <xs:element ref="xs:documentation"/>
      </xs:choice>
      <xs:attribute name="id" type="xs:ID"/>
     </xs:extension>
    </xs:complexContent>
   </xs:complexType>
 </xs:element>

 <xs:annotation>
  <xs:documentation>
   notations pour usage à l'intérieur des schémas de XML Schema</xs:documentation>
 </xs:annotation>

 <xs:notation name="XMLSchemaStructures" public="structures" system="http://www.w3.org/2000/08/XMLSchema.xsd"/>
 <xs:notation name="XML" public="REC-xml-19980210" system="http://www.w3.org/TR/1998/REC-xml-19980210"/>
 
 <xs:complexType name="anyType" mixte="true">
  <xs:annotation>
   <xs:documentation>
   Ce n'est pas le véritable type ur,
   mis une approximation aussi proche que nous pouvons
   obtenir avec une représentation XML</xs:documentation>
  </xs:annotation>
  <xs:sequence>
   <xs:any minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:anyAttribute/>
 </xs:complexType>
</xs:schema>
Remarque : Et cela et la fin du schéma pour XML Schema tome 1 : Structures.

B Références bibliographiques (partie normative)

XML 1.0 (Second Edition)
Extensible Markup Language (XML) 1.0, Second Edition, Tim Bray et al., eds., W3C, 6 octobre 2000. Se référer à http://www.w3.org/TR/2000/REC-xml-20001006
XML-Infoset
XML Information Set, John Cowan and Richard Tobin, eds., W3C, 16 mars 2001. Se référer à http://www.w3.org/TR/2001/WD-xml-infoset-20010316/
XML-Namespaces
Namespaces in XML, Tim Bray et al., eds., W3C, 14 janvier 1999. Se référer à http://www.w3.org/TR/1999/REC-xml-names-19990114/
XML Schema Requirements
XML Schema Requirements, Ashok Malhotra and Murray Maloney, eds., W3C, 15 février 1999. Se référer à http://www.w3.org/TR/1999/NOTE-xml-schema-req-19990215
Schémas XML tome 2 : Types de données
XML Schema Part 2: Datatypes, Paul V. Biron and Ashok Malhotra, eds., W3C, 2 mai 2001. Se référer à http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes.html
XPath
XML Path Language, James Clark and Steve DeRose, eds., W3C, 16 novembre 1999. Se référer à http://www.w3.org/TR/1999/REC-xpath-19991116
XPointer
XML Pointer Language (XPointer), Eve Maler and Steve DeRose, eds., W3C, 8 janvier 2001. Se référer à http://www.w3.org/TR/2001/WD-xptr-20010108/

C Tables de résultats (partie normative)

Pour faciliter la production de rapports d'erreurs homogènes et des échecs de ·validation·, ce chapitre présente sous forme de tables et fournit des noms uniques pour toutes les contraintes présentées dans ce document. Chaque fois que ces contraintes ont des constitutants numérotés, les rapports doivent utiliser le nom donné ci-dessous en plus du numéro du constitutant, les deux séparés par un point ('.'). Par exemple cos-ct-extends.1.2 doit être utilisé pour reporter une violation de la clause 1.2 du chapitre Dérivation valide (extension) (§3.4.6).

next sub-section C.1 Règles de validation

cvc-assess-attr
évaluation de la validité de schéma (attribut)
cvc-assess-elt
évaluation de la validité de schéma (élément)
cvc-attribute
attribut localement valide
cvc-au
attribut localement valide (utilisation)
cvc-complex-type
élément localement valide (type complexe)
cvc-datatype-valid
Type de donnée valide
cvc-elt
élément localement valide (élément)
cvc-enumeration-valid
énumération valide
cvc-facet-valid
facette valide
cvc-fractionDigits-valid
nombre fractionaire valide
cvc-id
racine de validation valide (ID/IDREF)
cvc-contrainte d'identité
contrainet d'identité satisfaite
cvc-length-valid
dimension valide
cvc-maxExclusive-valid
valeur maximum exclue valide
cvc-maxInclusive-valid
valeur maximum inclue valide
cvc-maxLength-valid
dimension maximum valide
cvc-minExclusive-valid
valeur minimum exclue valide
cvc-minInclusive-valid
valeur minimum inclue valide
cvc-minLength-valid
dimension minimum valide
cvc-model-group
série d'éléments valide
cvc-particle
série d'éléments localement valide (particule)
cvc-pattern-valid
motif valide
cvc-resolve-instance
résolution d'un nom qualifié (instance)
cvc-simple-type
chaîne de caractères valide
cvc-totalDigits-valid
nombre total valide
cvc-type
élément localement valide (type)
cvc-caractère générique
unité valide (caractère générique)
cvc-caractère générique-namespace
caractère générique admet le nom de l'espace de noms

previous sub-section next sub-section C.2 Contributions de l'ensemble d'information résultant de la validation de schéma

Propriétés de l'unité d'information de type attribut :
[déclaration d'attribut] (déclaration d'attribut)
[définition de type de membre] (attribut validé par type)
[définition anonyme de type de membre] (attribut validé par type)
[nom de la définition de type de membre] (attribut validé par type)
[espace de noms de la définition de type de membre] (attribut validé par type)
[valeur par défaut de schéma] (attribut validé par type)
[code d'erreur de schéma] (échec de validation (attribut))
[valeur normalisée par le schéma] (attribut validé par type)
[spécifié par le schema] (résultat d'évaluation (attribut))
[définition de type] (attribut validé par type)
[définition anonyme de type] (attribut validé par type)
[nom de la définition de type] (attribut validé par type)
[espace de noms de la définition de type] (attribut validé par type)
[type de la définition de type] (attribut validé par type)
[validation essayée] (résultat d'évaluation (attribut))
[contexte de la validation] (résultat d'évaluation (attribut))
[validité] (résultat d'évaluation (attribut))
Propriétés de l'unité d'information de type élément :
[déclaration d'élément] (déclaration d'élément)
[tableau d'ID/IDREF] (tableau d'ID/IDREF)
[tableau de contrainte d'identité] (tableau de contrainte d'identité)
[définition de type de membre] (élément Validé par type)
[définition anonyme de type de membre] (élément Validé par type)
[nom de la définition de type de membre] (élément Validé par type)
[espace de noms de la définition de type de membre] (élément Validé par type)
[nil] (déclaration d'élément)
[notation] (validé avec une notation)
[notation publique] (validé avec une notation)
[notation système] (validé avec une notation)
[valeur par défaut de schéma] (élément validé par type)
[code d'erreur de schéma] (échec de validation (élément))
[information de schéma] (information de schéma)
[valeur normalisée par le schéma] (élément validé par type)
[spécifié par le schema] (valeur par défaut de l'élément)
[définition de type] (élément validé par type)
[définition anonyme de type] (élément validé par type)
[nom de la définition de type] (élément validé par type)
[espace de noms de la définition de type] (élément validé par type)
[type de la définition de type] (élément validé par type)
[validation essayée] (résultat d'évaluation (élément))
[contexte de la validation] (résultat d'évaluation (élément))
[validité] (résultat d'évaluation (élément))
Propriétés de l'unité d'information de type relation d'ID/IDREF :
[relation] (tableau d'ID/IDREF)
[id] (tableau d'ID/IDREF)
Propriétés de l'unité d'information de type relation de contrainte d'identité :
[définition] (tableau de contrainte d'identité)
[tableau de noeuds] (tableau de contrainte d'identité)
Propriétés de l'unité d'information de schéma de type espace de noms  :
[composants de schéma] (information de schéma)
[documents de schéma] (information de schéma)
[espace de noms de schéma] (information de schéma)
Propriétés d'unité d'information de type document de schéma :
[emplacement du document] (information de schéma)
[document] (information de schéma)

previous sub-section next sub-section C.3 Contraintes de représentation de schémas

schema_reference
stratégie de emplacement des documents de schémas
src-annotation
représentation correcte de la définition de l'annotation
src-attribute
représentation correcte de la déclaration d'attribut
src-attribute_group
représentation correcte de la définition d'un groupe attribut
src-ct
représentation correcte de la définition d'un type complexe
src-element
représentation corrcte de la déclaration d'élément
src-expredef
redéfinition d'un composant individuel
src-contrainte d'identité
représentation correcte de la définition de la contrainte d'identité
src-import
contrainte et sémantique de l'importation
src-include
contrainte et sémantique de l'inclusion
src-list-itemType-or-simpleType
attribut itemType ou enfant simpleType
src-model_group
représentation corrcte d'un groupe modèle
src-model_group_defn
représentation corrcet de la définition d'un groupe modèle
src-multiple-enumerations
énumérations multiples
src-multiple-patterns
motifs multiples
src-notation
représentation correcte de la définition d'une notation
src-qname
interprétation d'un QName
src-redefine
constraintes et sémantique de la redéfinition
src-resolve
résolution d'un QName (document schéma)
src-restriction-base-or-simpleType
attribut de base ou enfant simpleType
src-simple-type
représentation correcte de la définition d'un type simple
src-single-facet-value
valeur d'une seule facette
src-union-memberTypes-or-simpleTypes
attributs MemberType ou enfants simpleType
src-caractère générique
représentation correcte du caractère générique
st-restrict-facets
restriction du type simple (facettes)

previous sub-section C.4 Contraintes des composants de schéma

ag-props-correct
propriétés de la définition du groupe attribut correctes
an-props-correct
annotation correcte
a-props-correct
propriétés de la déclaration d'attribut correctes
au-props-correct
utilisation correcte de l'attribut
c-fields-xpaths
valeur correcte des champs
cos-all-limited
group All limité
cos-applicable-facets
facettes applicables
cos-aw-intersect
intersection d'un attribut générique
cos-aw-union
union d'un attribut générique
cos-choice-range
étendue totale effective (choix)
cos-ct-dérivé-ok
dérivation correcte de type (complexe)
cos-ct-extends
dérivation valide (extension)
cos-element-consistent
déclaration d'élément régulière
cos-equiv-class
groupe de substitution
cos-equiv-dérivé-ok-rec
groupe de substitution correct (transitif)
cos-group-vidable
particule pouvant être vide
cos-list-of-atomic
liste de valeurs atomiques
cos-no-circular-unions
unions non circulaires
cos-nonambig
attribution de particule unique
cos-ns-sous-ensemble
sous-ensemble d'un caractère générique
cos-particle-extend
particule valide (extension)
cos-particle-restrict
particule valide (restriction)
cos-seq-range
étendue totale effective (groupes "all" et "sequence")
cos-st-dérivé-ok
dérivation correcte de type (simple)
cos-st-restricts
dérivation valide (restriction, simple)
cos-valid-default
valeur par défaut de l'élément valide (immédiate)
c-props-correct
propriétés de la définition de la contrainte identité correctes
c-selector-xpath
valeur correcte de la formule de sélection
ct-props-correct
propriétés de la définition du type complexe
derivation-ok-restriction
dérivation valide (restriction, complexe)
enumeration-required-notation
valeur requise de la facette énumération pour NOTATION
enumeration-valid-restriction
restriction valide de l'énumération
e-props-correct
propriétés de la déclaration d'élément correctes
fractionDigits-totalDigits
fractionDigits inférieur à ou égale à totalDigits
length-minLength-maxLength
longueur et longueur minimum ou longueur maximum
length-valid-restriction
restriction valide de la dimension
maxExclusive-valid-restriction
restriction valide de la valeur maximum exclue
maxInclusive-maxExclusive
maximum inclus et maximum exclu
maxInclusive-valid-restriction
restriction valide de la valeur maximum inclue
maxLength-valid-restriction
restriction valide de la dimension maximum
mgd-props-correct
propriétés de la définition du groupe modèle correctes
mg-props-correct
groupe modèle correct
minExclusive-less-than-equal-to-maxExclusive
valeur minimum exclue <= valeur maximum exclue
minExclusive-less-than-maxInclusive
valeur minimum exclue < valeur maximum inclue
minExclusive-valid-restriction
restriction valide de la valeur minimum exclue
minInclusive-less-than-equal-to-maxInclusive
valeur minimum inclue <= valeur maximum inclue
minInclusive-less-than-maxExclusive
valeur minimum inclue < valeur maximum exclue
minInclusive-minExclusive
valeur minimum inclue et valeur minimum exclue
minInclusive-valid-restriction
restriction valide de la valeur minimum inclue
minLength-less-than-equal-to-maxLength
longueur minimum <= longueur maximum
minLength-valid-restriction
restriction valide de la dimension minimum
no-xmlns
xmlns interdit
no-xsi
xsi: interdit
n-props-correct
déclaration de notation correcte
p-props-correct
particule correcte
range-ok
gamme correcte d'occurrence
rcas-MapAndSum
dérivation correcte de particule (sequence:choice -- MapAndSum)
rcas-NameAndTypeOK
restriction correcte de particule (Elt:Elt -- NameAndTypeOK)
rcas-NSCompat
dérivation correcte de particule (Elt:Any -- NSCompat)
rcas-NSRecurseCheckCardinality
dérivation correcte de particule (All/Choice/Sequence:Any -- NSRecurseCheckCardinality)
rcas-NSSubset
dérivation correcte de particule (Any:Any -- NSSubset)
rcas-Recurse
dérivation correcte de particule (All:All,Sequence:Sequence -- Recurse)
rcas-RecurseAsIfGroup
dérivation correcte de particule (Elt:All/Choice/Sequence -- RecurseAsIfGroup)
rcas-RecurseLax
dérivation correcte de particule (Choice:Choice -- RecurseLax)
rcas-RecurseUnordered
dérivation correcte de particule (Sequence:All -- RecurseUnordered)
sch-props-correct
propriétés du schéma correctes
st-props-correct
propriétés de la définition du type simple correctes
totalDigits-valid-restriction
restriction valide de totalDigit
whiteSpace-valid-restriction
restriction valide des espaces blancs
w-props-correct
propriétés du caractère générique valides

D Unités de l'ensemble d'information requises et propriétés (partie normative)

Cette spécification impose, comme condition préalable à ·l'évaluation·, un ensemble d'information tel que défini dans [XML-Infoset] supportant au moins les unités d'information et propriétés suivantes :

Unité d'information de type attribut
[nom local], [nom de l'espace de noms], [valeur normalisée]
Unité d'information de type caractère
[code du caractère]
Unité d'information de type élément
[nom local], [nom de l'espace de noms], [enfants], [attributs], [espaces de noms dans le champ d'application] ou [attributs d'espace de noms]
Unité d'information de type espace de noms
[préfixe], [nom de l'espace de noms]

Cette spécification ne provoque aucune altération destructive de l'ensemble d'information mis en entrée : toutes les contributions à l'ensemble d'information spécifiées dans ce document lui sont additives.

L'objectif de cette annexe est de satisfaire aux exigences de Conformité à la spécification [XML-Infoset].

E Graphe des composants d'un schéma (partie non-normative)

Notation Declaration Schema Component Schema Component Element Declaration Schema Component Identity Constraint Definition Schema Component Model Group Definition Schema Component Simple Type Definition Schema Component Complex Type Definition Schema Component Particle Schema Component Model Group Schema Component Attribute Use Schema Component Wildcard Schema Component Attribute Declaration Schema Component Attribute Group Definition Schema Component Schema Components Diagram of schema components

F Glossaire (partie non-normative)

Le glossaire qui suit doit profiter aux lecteurs de la version imprimée de ce document : il rassemble toutes les définitions qui apparaissent dans le texte ci-dessus.

Absent
Tout au long de cette spécification, le terme absent est utilisé comme une propriété particulière dénotant l'absence
Valeur actuelle
La phrase valeur actuelle est utilisée en référence au membre de l'espace de valeurs de la définition de type simple associée avec une unité d'information de type attribut qui correspond à sa ·valeur normalisée·
Evaluation
le mot évaluation est utilisé en référence à l'ensemble du processus de validation locale, l'évaluation de la validité de schéma et l'augmentation de l'ensemble d'information
Définition du type de base
Une définition d'un type utilisé comme la base pour une ·extension· ou une ·restriction· est connue comme étant la définition du type de base de cette définition
Nom du composant
Des déclarations et des définitions peuvent avoir et être identifiées par des noms, de type NCNames tels qu'ils sont définis dans [XML-Namespaces]
Conformité à la représentation XML des schémas
Les programmes de traitement de ·conformité minimale· qui acceptent les schémas représenté sous la forme de documents XML comme décrit au chapitre Niveau 2 : documents de type schéma, espaces de noms et assemblage (§4.2) sont dit de plus fournir une conformité à la représentation XML des schémas.
Modèle de contenu
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 un modèle de contenu
Déclaration contextuelle
Pendant la ·validation·, des associations entre des unités d'information de type élément et attribut parmi les [enfants] et les [attributs] d'un côté, et des déclarations d'éléments et d'attributs d'un autre côté, sont établies comme un effet de bord. Ces déclarations sont appelées des déclarations contextuelles
Déclaration
Les composants de déclaration sont associés par un nom (qualifié) à des unités d'information en train d'être ·validés·
Définition
Les composants de définition définissent les composants de schéma internes qui peuvent être utilisés dans d'autres composants de schéma
Groupe de substitution d'élément
Au travers des nouveaux mécanismes des groupes de substitution d'élément, les schémas XML fournissent un modèle plus puissant supportant la substitution d'un élément nommé par un autre
Extension
Une définition de type complexe qui permet d'avoir un contenu d'élément ou d'attribut qui vient s'ajouter à un autre déjà autorisé par une autre définition de type est dit être an extension
Terminal
le type complexe est dit être terminal parce qu'aucune dérivation ultérieure n'est possible
Conformité totale
Les programmes de traitement qui garantissent une conformité totale sont ceux qui sont capable d'être opérationnels en réseau et qui ne sont pas seulement à la fois ·conformité minimale· et ·en conformité avec la représentation XML des schémas·, mais qui de plus sont capable d'accéder à des documents de schéma distribués sur le World Wide Web d'après le chapitre sur la Représentation des schémas sur le World Wide Web (§2.7) et celui sur Comment les définitions de schémas sont repérées sur le Web (§4.3.2).
Contient implicitement
Une liste de particules contient implicitement une déclaration d'élément si un membre de la liste contient cette déclaration d'élément dans son ·groupe de substitution·.
Valeur initiale
la valeur initiale de plusieurs unité d'information de type attribut est la valeur de la propriété ·valeur normalisée· de cette unité. Parallèlement, la valeur initiale d'une unité d'information de type élément est la chaîne de caractères composée de, dans l'ordre, le [code du caractère] de chaque unité d'information de type caractère des [enfants] de cette unité d'information de type élément.
Unité isomorphe à un composant
Une unité isomorphe à un composant est une unité d'information qui a un type équivalent à celui du composant, une propriété par propriété du composant, le même nom et comme valeur soit la même valeur atomique soit une unité d'information identique ou équivalente à celle du composant, cela récursivement, si nécessaire.
Evaluation vague
la validité de schéma d'une unité d'information de type élément peut être vaguement évalué quand sa ·déclaration contextuelle· n'est pas sautée en ·validation· eu égard à ·définition du type ur· comme pour les éléments localement valide (type) (§3.3.4)
Conformité minimale
Les programmes de traitement qui sont d'un niveau de conformité minimale implémentent complètement et correctement les ·contraintes des composants de schéma·, les ·règles de validation· et les ·contributions à l'ensemble d'information de schéma· contenus dans cette spécification
NCName
Un NCName est nom qui ne contient pas le caractère ":" (ndlt : NCName signifie en angalis Non-Colonized Name), tel que défini dans [XML-Namespaces]. Quand un tel nom est utilisé dans cette spécification en relation avec la représentation XML des composants de schéma, cela se réfère au type simple NCName tel que défini dans [Schémas XML tome 2 : Types de données]
Valeur normalisée
La valeur normalisée d'une unité d'information de type élément ou attribut est une ·valeur initiale· dont l'espace blanc, quand il y en a, ont été normalisés d'après la valeur de la facette espace blanc de la définition du type simple utilisée dans sa ·validation·.
Partition
On définit une partition d'une série comme étant une série de sous-séries, toutes ou partie pouvant être vides ; la condition étant que la concaténation toutes les sous-séries on retrouve la série originale.
QName
Un Nom qualifié (QName) est un nom pouvant recevoir en option une qualification d'espace de noms, comme cela est définit dans [XML-Namespaces]. Quand un QName est utilisé en relation avec la représentation XML des composants de schéma ou à leur référencement, dans cette spécification, cela fait référence au type simple QName tel qu'il est définit dans [Schémas XML tome 2 : Types de données]
Se ramener à
Quand l'expression (ou ses formes françaises dérivées) se ramener à est utilisée dans ce document par rapport à un nom de type ·QName· d'un document de type schéma, c'est la définition se trouvant au chapitre résolution d'un QName (document schéma) (§3.15.3) doit être comprise.
Restriction
Une définition de type dont les déclarations ou les facettes sont dans une relation un-à-un avec celles d'une autre définition de type spécifiée, avec chacune à son tour restreignant les possibilités de celle qui lui correspond, on parle de restriction
Composant de schéma
Composant de schéma est le terme générique pour désigner les blocs de construction qui renferment le modèle de données abstrait du schéma.
Contraintes des composants de schéma
Les contraintes sur les composants de schéma eux-mêmes, c'est à dire les conditions que les composants doivent satisfaire pour être des vrais composants. Dispersées dans les six sous-chapitres qui traitent des différents types de composants dans le grand chapitre Descriptions détaillées des composants de schéma (§3) et sont récapitulées à l'annexe Contraintes des composants de schéma (§C.4)
Document de type schéma
Un document de cette forme (c'est à dire l'unité d'information de type élément <schema>) est un document de type schéma
Contribution à l'ensemble d'information de schéma
Il s'agit des rajouts d'information réalisés par le processus de validation exprimés sous la forme de composants de schéma, c'est une conséquence des processus de ·validation· et/ou ·d'évaluation·. Ceux-là sont spécifiés dans les cinquièmes sous-chapitres du grand chapitre Descriptions détaillées des composants de schéma (§3) et sont récapitulées à l'annexe Contributions de l'ensemble d'information résultant de la validation de schéma (§C.2)
Contrainte de représentation des schémas
Il s'agit des contraintes de représentation XML des composants de schéma qui vont au delà de celles exprimées au chapitre Le schéma des schémas (partie normative) (§A). On les trouve dans les troisièmes sous-chapitres de chaque sous-chapitre du grand chapitre Descriptions détaillées des composants de schéma (§3) et sont récapitulées à l'annexe Contraintes de représentation de schémas (§C.3)
Espace de symboles
Cette spécification introduit le terme d'espace de symboles pour identifier un ensemble de noms, chacun d'eux étant unique par rapport aux autres dans cet espace.
Espace de noms cible
Plusieurs sortes de composant ont un espace de noms cible, qui est soit ·absent· soit a comme valeur est un nom d'espace de noms également défini dans [XML-Namespaces]
Définition de type
Cette spécification utilise la phrase définition de type dans les cas où il n'est pas besoin de faire le distinguo entre types simples et types complexes.
Hiérarchie des définitions de types
Excepté pour le cas spécial de la ·définition du type ur·, chaque ·définition de type· est, par construction, soit une ·restriction· soit une ·extension· d'une autre définition de type. Le graphe résultant ces relations est un arbre dont le nom est Hiérarchie des définitions de types
Définition du type ur
Le cas spécial de la définition du type ur est présent dans chaque ·schéma XML·, et lui sert de racine à la hiérarchie des définitions de types.
Valide
Le mot valide et ses formes dérivées sont utilisées pour faire référence à la clause 1 ci-dessus, qui traite de la détermination de la validité locale des schémas.
Racine de validation
Cette unité, qui est l'unité d'information de type élément à partir de laquelle commence ·l'évaluation·, est appelée la racine de validation
Règles de validation
Les contributions de ·validation· associées aux composants de schéma. Décrites dans chaque quatrième sous-chapitre du grand chapitre Descriptions détaillées des composants de schéma (§3) et récapitulées à l'annexe Règles de validation (§C.1)
Extension valide
Si cette contrainte Dérivation valide (extension) (§3.4.6) vient de la définition d'un type complexe, c'est une extension valide de sa {définition du type de base}
Restriction valide
Si cette contrainte Dérivation valide (restriction, complexe) (§3.4.6) vient de la définition d'un type complexe, c'est une restriction valide de sa {définition du type de base}
Schéma XML
Un schéma XML est un ensemble de ·composants de schéma·

G La DTD des schémas (partie non-normative)

La DTD qui correspond à ce document XML Schema tome 1 : Structures est fournie ci-dessous. Remarquez d'ores et déjà qu'elle n'impose absolument pas que l'élément schema soit la racine d'une instance de cette DTD.

Bien que cette DTD ne soit pas normative, tout document XML qui valide par rapport à cette DTD (tout en considérant les redéfinitions qui y sont faites des entités paramètres 'p' et 's' appropriées à sa déclaration d'espace de noms de l'espace de nom des schémas XML) a de fortes chances d'être également valide vis à vis de XML Schema (sauf cas des documents multipliant les noms d'espaces de noms). En conséquence, écrire des documents contenant des schémas XML avec cette DTD, de les éditer avec des éditeurs structurés pour XML 1.0 (éditeurs à base de DTD), de leur attribuer le DOCTYPE des documents dont l'objet est d'être des schémas XML et de les valider ensuite par rapport à un analyseur lexico-syntaxique XML, est une démarche de développement raisonnable que l'on encourage les auteurs de suivre en attendant que les éditeurs natifs XML soient plus répandus.

<!-- DTD for XML Schemas: Part 1: Structures
     Public Identifier: "-//W3C//DTD XMLSCHEMA 200102//EN"
     Official Location: http://www.w3.org/2001/XMLSchema.dtd -->
<!-- Id: XMLSchema.dtd,v 1.30 2001/03/16 15:23:02 ht Exp  -->
<!-- A l'exception des cas ayant plusieurs espaces de noms
     en préfixe pour l'espace de noms du schéma XML, tout document XML qui ne serait
     pas valide par rapport à cette DTD (tenant compte des redéfinitions 
     des entités paramètres 'p' et 's' nécessaires à sa déclaration d'espace de noms
     de XMl Schema) aurait de fortes chances de ne pas être un schéma valide. -->

<!-- L'élément simpleType et ses parties constituantes
     sont définies dans XML Schema tome 2: Types de données -->
<!ENTITY % xs-datatypes PUBLIC 'datatypes' 'datatypes.dtd' >

<!ENTITY % p 'xs:'> <!-- peut être réécrit dans le sous-ensemble interne
                         d'un document de type schéma pour établir un 
                         nouveau préfixe d'espace de noms -->
<!ENTITY % s ':xs'> <!-- si l'entité paramètre %p est définie
                         (comme par exemple as foo:) alors vous devez
                         aussi définir l'entité paramètre %s comme étant le
                         suffixe pour la déclaration d'espace de noms (par exemple :foo) -->
<!ENTITY % nds 'xmlns%s;'>

<!-- Définit tous les noms d'éléments, avec préfixe optionnel -->
<!ENTITY % schema "%p;schema">
<!ENTITY % complexType "%p;complexType">
<!ENTITY % complexContent "%p;complexContent">
<!ENTITY % simpleContent "%p;simpleContent">
<!ENTITY % extension "%p;extension">
<!ENTITY % element "%p;element">
<!ENTITY % unique "%p;unique">
<!ENTITY % key "%p;key">
<!ENTITY % keyref "%p;keyref">
<!ENTITY % selector "%p;selector">
<!ENTITY % field "%p;field">
<!ENTITY % group "%p;group">
<!ENTITY % all "%p;all">
<!ENTITY % choice "%p;choice">
<!ENTITY % sequence "%p;sequence">
<!ENTITY % any "%p;any">
<!ENTITY % anyAttribute "%p;anyAttribute">
<!ENTITY % attribute "%p;attribute">
<!ENTITY % attributeGroup "%p;attributeGroup">
<!ENTITY % include "%p;include">
<!ENTITY % import "%p;import">
<!ENTITY % redefine "%p;redefine">
<!ENTITY % notation "%p;notation">

<!-- annotation elements -->
<!ENTITY % annotation "%p;annotation">
<!ENTITY % appinfo "%p;appinfo">
<!ENTITY % documentation "%p;documentation">

<!-- La personnalisation des entités pour la déclaration de liste d'attribut
     de chaque type d'élément.
     Définit l'un de ceux-ci one si votre schéma tire profit de la possibilité
     anyAttribute='##other' du schéma des schémas -->

<!ENTITY % schemaAttrs ''>
<!ENTITY % complexTypeAttrs ''>
<!ENTITY % complexContentAttrs ''>
<!ENTITY % simpleContentAttrs ''>
<!ENTITY % extensionAttrs ''>
<!ENTITY % elementAttrs ''>
<!ENTITY % groupAttrs ''>
<!ENTITY % allAttrs ''>
<!ENTITY % choiceAttrs ''>
<!ENTITY % sequenceAttrs ''>
<!ENTITY % anyAttrs ''>
<!ENTITY % anyAttributeAttrs ''>
<!ENTITY % attributeAttrs ''>
<!ENTITY % attributeGroupAttrs ''>
<!ENTITY % uniqueAttrs ''>
<!ENTITY % keyAttrs ''>
<!ENTITY % keyrefAttrs ''>
<!ENTITY % selectorAttrs ''>
<!ENTITY % fieldAttrs ''>
<!ENTITY % includeAttrs ''>
<!ENTITY % importAttrs ''>
<!ENTITY % redefineAttrs ''>
<!ENTITY % notationAttrs ''>
<!ENTITY % annotationAttrs ''>
<!ENTITY % appinfoAttrs ''>
<!ENTITY % documentationAttrs ''>

<!ENTITY % complexDerivationSet "CDATA">
      <!-- #all ou une liste d'éléments séparés par des blancs issues
            de dérivation Choice -->
<!ENTITY % blockSet "CDATA">
      <!-- #all ou une liste d'éléments séparés par des blancs issues
                   de dérivation Choice + 'substitution' -->

<!ENTITY % mgs '%all; | %choice; | %sequence;'>
<!ENTITY % cs '%choice; | %sequence;'>
<!ENTITY % formValues '(qualified|unqualified)'>


<!ENTITY % attrDecls    '((%attribute;| %attributeGroup;)*,(%anyAttribute;)?)'>

<!ENTITY % particleAndAttrs '((%mgs; | %group;)?, %attrDecls;)'>

<!-- Ceci est utilisé dans le tome 2 -->
<!ENTITY % restriction1 '((%mgs; | %group;)?)'>

%xs-datatypes;

<!-- La recopie ci-après est faite pour produire un modèle de contenu non-ambigüe
     qui permet d'avoir des annotations n'importe où -->
<!ELEMENT %schema; ((%include; | %import; | %redefine; | %annotation;)*,
                    ((%simpleType; | %complexType;
                      | %element; | %attribute;
                      | %attributeGroup; | %group;
                      | %notation; ),
                     (%annotation;)*)* )>
<!ATTLIST %schema;
   targetNamespace      %URIref;               #IMPLIED
   version              CDATA                  #IMPLIED
   %nds;                %URIref;               #FIXED 'http://www.w3.org/2001/XMLSchema'
   xmlns                CDATA                  #IMPLIED
   finalDefault         %complexDerivationSet; ''
   blockDefault         %blockSet;             ''
   id                   ID                     #IMPLIED
   elementFormDefault   %formValues;           'unqualified'
   attributeFormDefault %formValues;           'unqualified'
   xml:lang             CDATA                  #IMPLIED
   %schemaAttrs;>
<!-- Remarquez que la déclaration xmlns n'est PAS dans le schéma des schémas,
     parce que au niveau de l'ensemble d'information où le schéma agit,
     xmlns(:prefix) n'est PAS un attribut! -->
<!-- La déclaration de xmlns est pratique pour les auteurs de schémas -->
 
<!-- L'attribut id ici et dessous doit être utilisé dans des références externes
     à partir de données différentes de celles de type schéma
     utilisant de simples identifiants de fragments.
     Ce n'est PAS utilisé pour faire des références de schéma à schéma, que ce soit
     interne ou externe. -->

<!-- un type est une spécification de contenu nommée qui permet d'avoir des
     déclarations d'attributs-->
<!-- -->

<!ELEMENT %complexType; ((%annotation;)?,
                         (%simpleContent;|%complexContent;|
                          %particleAndAttrs;))>

<!ATTLIST %complexType;
          name      %NCName;                        #IMPLIED
          id        ID                              #IMPLIED
          abstract  %booléen;                       #IMPLIED
          final     %complexDerivationSet;          #IMPLIED
          block     %complexDerivationSet;          #IMPLIED
          mixte (vrai|faux) 'faux'
          %complexTypeAttrs;>

<!-- le mot particleAndAttrs est un raccourci pour un type racine -->
<!-- le modèle mixte est interdit dans le cas du contenu simple,
     surchargé si le contenu complexe en a un également. -->

<!-- Si anyAttribute apparaît dans un ou plusieurs attributeGroups
     référencés et/ou explicites, l'intersection des permissions est utilisée-->

<!ELEMENT %complexContent; (%restriction;|%extension;)>
<!ATTLIST %complexContent;
          mixte (vrai|faux) #IMPLIED
          id    ID           #IMPLIED
          %complexContentAttrs;>

<!-- la restriction devrait utiliser la brache définie ci-dessus, pas celle qui est simple
     de part2; l'extension devrait utiliser la totalité du modèle  -->

<!ELEMENT %simpleContent; (%restriction;|%extension;)>
<!ATTLIST %simpleContent;
          id    ID           #IMPLIED
          %simpleContentAttrs;>

<!-- la restriction devrait utiliser la branche simple de part2,
     pas celle définit ci-dessus ; l'extension devrait avoir aucune particule  -->

<!ELEMENT %extension; (%particleAndAttrs;)>
<!ATTLIST %extension;
          base  %QName;      #REQUIRED
          id    ID           #IMPLIED
          %extensionAttrs;>

<!-- un élément est déclaré soit :
 par un nom et un type (soit emboîté soit référencé via l'attribut type)
 soit par une référence à une déclaration d'élément existante -->

<!ELEMENT %element; ((%annotation;)?, (%complexType;| %simpleType;)?,
                     (%unique; | %key; | %keyref;)*)>
<!-- simpleType ou complexType seulement si il n'y a aucun attirbut type|ref -->
<!-- ref est interdit au niveau supérieur -->
<!ATTLIST %element;
            name               %NCName;               #IMPLIED
            id                 ID                     #IMPLIED
            ref                %QName;                #IMPLIED
            type               %QName;                #IMPLIED
            minOccurs          %nonNegativeInteger;   #IMPLIED
            maxOccurs          CDATA                  #IMPLIED
            nillable           %booléen;              #IMPLIED
            substitutionGroup  %QName;                #IMPLIED
            abstract           %booléen;              #IMPLIED
            final              %complexDerivationSet; #IMPLIED
            block              %blockSet;             #IMPLIED
            default            CDATA                  #IMPLIED
            fixed              CDATA                  #IMPLIED
            form               %formValues;           #IMPLIED
            %elementAttrs;>
<!-- type et ref sont mutuellement exclusifs.
     name et ref sont mutuellement exclusifs, l'un d'eux est requis -->
<!-- En l'absence du type AND les attributs ref et type ont comme valeur par défaut
     le type du groupe de substitution, si il existe, sinon le type ur,
     c'est à dire sans aucune contrainte -->
<!-- les caractéristiques default et fixed sont mutuellement exclusives -->

<!ELEMENT %group; ((%annotation;)?,(%mgs;)?)>
<!ATTLIST %group; 
          name        %NCName;               #IMPLIED
          ref         %QName;                #IMPLIED
          minOccurs   %nonNegativeInteger;   #IMPLIED
          maxOccurs   CDATA                  #IMPLIED
          id          ID                     #IMPLIED
          %groupAttrs;>

<!ELEMENT %all; ((%annotation;)?, (%element;)*)>
<!ATTLIST %all;
          minOccurs   (1)                    #IMPLIED
          maxOccurs   (1)                    #IMPLIED
          id          ID                     #IMPLIED
          %allAttrs;>

<!ELEMENT %choice; ((%annotation;)?, (%element;| %group;| %cs; | %any;)*)>
<!ATTLIST %choice;
          minOccurs   %nonNegativeInteger;   #IMPLIED
          maxOccurs   CDATA                  #IMPLIED
          id          ID                     #IMPLIED
          %choiceAttrs;>

<!ELEMENT %sequence; ((%annotation;)?, (%element;| %group;| %cs; | %any;)*)>
<!ATTLIST %sequence;
          minOccurs   %nonNegativeInteger;   #IMPLIED
          maxOccurs   CDATA                  #IMPLIED
          id          ID                     #IMPLIED
          %sequenceAttrs;>

<!-- un groupement anonyme d'un modèle ou
     une définition supérieure de groupe nommé ou une référence à l'une de ces entités -->

<!-- Remarquez que si order est 'all', le groupe est interdit à l'intérieur.
     Si order est 'all' CE groupe doit être seul (ou seul référencé) au
     niveau supérieur d'un modèle de contenu -->
<!-- Si order est 'all', on a minOccurs==maxOccurs==1 sur l'élément ou any
     qui se trouve à l'intérieur -->
<!-- Devrait autoriser minOccurs=0 à l'intérieur de order='all' . . . -->

<!ELEMENT %any; (%annotation;)?>
<!ATTLIST %any;
            namespace       CDATA                  '##any'
            processContents (skip|lax|strict)      'strict'
            minOccurs       %nonNegativeInteger;   '1'
            maxOccurs       CDATA                  '1'
            id              ID                     #IMPLIED
            %anyAttrs;>

<!-- l'espace de noms est interprété comme suit :
                  ##any      - - tout WFXML non-conflictuel du tout

                  ##other    - - tout WFXML non-conflictuel de l'espace de nosm autre
                                  que targetNamespace

                  ##local    - - tout WFXML/attribut non-conflictuel non-qualifié
                  un ou      - - tout WFXML non-conflictuel des
                  plusieurs        espaces de noms listés
                  références d'URIs

                  ##targetNamespace ##local peuvent apparaître dans la liste ci-dessus,
                    avec une signification évidente -->

<!ELEMENT %anyAttribute; (%annotation;)?>
<!ATTLIST %anyAttribute;
            namespace       CDATA              '##any'
            processContents (skip|lax|strict)  'strict'
            id              ID                 #IMPLIED
            %anyAttributeAttrs;>
<!-- namespace est interprété comme pour 'any' ci-dessus -->

<!-- simpleType seulement si il n'y a pas d'attribut type|ref -->
<!-- ref est interdit auniveau supérieur, name iff au niveau supérieur -->
<!ELEMENT %attribute; ((%annotation;)?, (%simpleType;)?)>
<!ATTLIST %attribute;
          name      %NCName;      #IMPLIED
          id        ID            #IMPLIED
          ref       %QName;       #IMPLIED
          type      %QName;       #IMPLIED
          use       (prohibited|optional|required) #IMPLIED
          default   CDATA         #IMPLIED
          fixed     CDATA         #IMPLIED
          form      %formValues;  #IMPLIED
          %attributeAttrs;>
<!-- type et ref sont mutuellement exclusifs.
     name et ref sont mutuellement exclusifs, un est éxigé -->
<!-- le mode par défaut pour l'attribut use est optional quand imbriqué, rien sinon -->
<!-- default et fixed sont mutuellement exclusifs -->
<!-- le type attr et le contenu simpleType sont mutuellement exclusifs -->

<!-- un attributeGroup est une collection nomée de déclarations d'attributs, ou une
     référence à une telle collection -->
<!ELEMENT %attributeGroup; ((%annotation;)?,
                       (%attribute; | %attributeGroup;)*,
                       (%anyAttribute;)?) >
<!ATTLIST %attributeGroup;
                 name       %NCName;       #IMPLIED
                 id         ID             #IMPLIED
                 ref        %QName;        #IMPLIED
                 %attributeGroupAttrs;>

<!-- ref iff no content, no name.  ref iff not top level -->

<!-- mécanismes pour de meilleures références-->
<!ELEMENT %unique; ((%annotation;)?, %selector;, (%field;)+)>
<!ATTLIST %unique;
          name     %NCName;       #REQUIRED
          id       ID             #IMPLIED
          %uniqueAttrs;>

<!ELEMENT %key;    ((%annotation;)?, %selector;, (%field;)+)>
<!ATTLIST %key;
          name     %NCName;       #REQUIRED
          id       ID             #IMPLIED
          %keyAttrs;>

<!ELEMENT %keyref; ((%annotation;)?, %selector;, (%field;)+)>
<!ATTLIST %keyref;
          name     %NCName;       #REQUIRED
          refer    %QName;        #REQUIRED
          id       ID             #IMPLIED
          %keyrefAttrs;>

<!ELEMENT %selector; ((%annotation;)?)>
<!ATTLIST %selector;
          xpath %XPathExpr; #REQUIRED
          id    ID          #IMPLIED
          %selectorAttrs;>
<!ELEMENT %field; ((%annotation;)?)>
<!ATTLIST %field;
          xpath %XPathExpr; #REQUIRED
          id    ID          #IMPLIED
          %fieldAttrs;>

<!-- mécanismes de combinaison de schémas -->
<!ELEMENT %include; (%annotation;)?>
<!ATTLIST %include;
          schemaLocation %URIref; #REQUIRED
          id             ID       #IMPLIED
          %includeAttrs;>

<!ELEMENT %import; (%annotation;)?>
<!ATTLIST %import;
          namespace      %URIref; #IMPLIED
          schemaLocation %URIref; #IMPLIED
          id             ID       #IMPLIED
          %importAttrs;>

<!ELEMENT %redefine; (%annotation; | %simpleType; | %complexType; |
                      %attributeGroup; | %group;)*>
<!ATTLIST %redefine;
          schemaLocation %URIref; #REQUIRED
          id             ID       #IMPLIED
          %redefineAttrs;>

<!ELEMENT %notation; (%annotation;)?>
<!ATTLIST %notation;
          name        %NCName;    #REQUIRED
          id          ID          #IMPLIED
          public      CDATA       #REQUIRED
          system      %URIref;    #IMPLIED
          %notationAttrs;>

<!-- Annotation contient soit une information pour une application
     ou des commentaires -->
<!-- En ayant leur déclarations ici, elles sont disponibles aussi bien pour des types de données que
     pour toutes les structures d'éléments -->

<!ELEMENT %annotation; (%appinfo; | %documentation;)*>
<!ATTLIST %annotation; %annotationAttrs;>

<!-- l'utilisateur doit définir des éléments annotation 
     dans le sous-ensemble interne pour que ça marche -->
<!ELEMENT %appinfo; ANY>   <!-- trop rstrictif -->
<!ATTLIST %appinfo;
          source     %URIref;      #IMPLIED
          id         ID         #IMPLIED
          %appinfoAttrs;>
<!ELEMENT %documentation; ANY>   <!-- trop restrictif -->
<!ATTLIST %documentation;
          source     %URIref;   #IMPLIED
          id         ID         #IMPLIED
          xml:lang   CDATA      #IMPLIED
          %documentationAttrs;>

<!NOTATION XMLSchemaStructures PUBLIC
           'structures' 'http://www.w3.org/2001/XMLSchema.xsd' >
<!NOTATION XML PUBLIC
           'REC-xml-1998-0210' 'http://www.w3.org/TR/1998/REC-xml-19980210' >

H Analyse de la contrainte d'attribution de particule unique (partie non-normative)

Une spécification de l'import, l'attribution de particule unique (§3.8.6), qui ne ferait pas appel à un modèle de traitement serait difficile. La prétention de ce qui suit est uniquement de servir de guide, pas de prétendre être complet.

[Définition :]  Deux particules qui ne sont pas des groupes se chevauchent si

ou

ou

ou

Un modèle de contenu viole la contrainte d'attribution unique quand il contient deux particules qui se ·chevauchent· et qui vérifient l'une des deux conditions suivantes :

  • ce sont les {particules} d'un groupe de type choice ou all

ou

Deux particules peuvent ·valider· des unités d'information adjacentes si des écarts infimes les séparent pendant la transformation mécanique la plus directe d'un modèle de contenu.

Une formulation précise de cette contrainte peut aussi être exprimée en termes de suite d'opérations de transformation appliquées de manière mécanique dont les grandes lignes consistent à transcrire le modèle de contenu, mécaniquement et comme cela se fait habituellement, en utilisant des transitions infinitésimales pour les valeurs optionnelles et non-limitées de maxOccurs, dérouler les autres séries d'occurrences numériques et traiter les têtes des groupes de substitution comme si il s'agissait d'une alternative à tous les éléments du groupe, en n'utilisant pas les éléments QNames comme étiquettes intermédiaires mais plutôt des paires composées des éléments QNames et des positions dans le modèle. Déterminer cette mécanique, considérer comme étant opaques les valeurs intermédiaires des caractères génériques. Ensuite, vous pouvez remplacer toutes les étiquettes intermédiaires formées des couples (QName, position) par les seuls éléments QNames. Si, dans e résultat, on a des états avec une ou plusieurs fois la même étiquette QName, ou un état intermédiaire étiqueté par un QName et un caractère générique qui le subsumes, ou deux caractères génériques dont l'intersection n'est pas vide, alors le modèle ne satisfait pas à la contrainte d'attribution unique.

I Références (partie non-normative)

DCD
Document Content Description for XML (DCD), Tim Bray et al., eds., W3C, 10 août 1998. Se référer à http://www.w3.org/TR/1998/NOTE-dcd-19980731
DDML
Document Definition Markup Language, Ronald Bourret, John Cowan, Ingo Macherius, Simon St. Laurent, eds., W3C, 19 janvier 1999. Se référer à http://www.w3.org/TR/1999/NOTE-ddml-19990119
SOX
Schema for Object-oriented XML, Andrew Davidson et al., eds., W3C, 1998. Se référer à http://www.w3.org/1999/07/NOTE-SOX-19990730/
SOX-2
Schema for Object-oriented XML, Version 2.0, Andrew Davidson, et al., W3C, 30 juillet 1999. Se référer à http://www.w3.org/TR/NOTE-SOX/
XDR
XML-Data Reduced, Charles Frankston and Henry S. Thompson, 3 juillet 1998. Se référer à http://www.ltg.ed.ac.uk/~ht/XMLData-Reduced.htm
XML-Data
XML-Data, Andrew Layman et al., W3C, 05 janvier 1998. Se référer à http://www.w3.org/TR/1998/NOTE-XML-data-0105/
XML Schema: Primer
XML Schema Part 0: Primer, David C. Fallside, ed., W3C, 2 mai 2001. Se référer à http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/primer.html

J Remerciements (partie non-normative)

Les personnes suivantes ont concrètement participé à l'élaboration de ce document :

  • David Fallside, IBM
  • Scott Lawrence, Agranat Systems
  • Andrew Layman, Microsoft
  • Eve L. Maler, Sun Microsystems
  • Asir S. Vedamuthu, webMethods, Inc

Les éditeurs remercient les membres du groupe de travail sur XML Schema, les membres des autres groupes de travail du W3C et les experts de l'industrie d'autres forums qui ont contribué directement ou indirectement au processus de création ou au contenu de ce document. Le groupe de travail remercie particulièrement les sociétés Lotus Development Corp. et IBM pour avoir fourni les moyens de faire les téléconférences.

Les membres actuels du groupe de travail sur XML Schema sont :

Jim Barnette, Defense Information Systems Agency (DISA); Paul V. Biron, Health Level Seven; Don Box, DevelopMentor; Allen Brown, Microsoft; Lee Buck, TIBCO Extensibility; Charles E. Campbell, Informix; Wayne Carr, Intel; Peter Chen, Bootstrap Alliance and LSU; David Cleary, Progress Software; Dan Connolly, W3C (staff contact); Ugo Corda, Xerox; Roger L. Costello, MITRE; Haavard Danielson, Progress Software; Josef Dietl, Mozquito Technologies; David Ezell, Hewlett-Packard Company; Alexander Falk, Altova GmbH; David Fallside, IBM; Dan Fox, Defense Logistics Information Service (DLIS); Matthew Fuchs, Commerce One; Andrew Goodchild, Distributed Systems Technology Centre (DSTC Pty Ltd); Paul Grosso, Arbortext, Inc; Martin Gudgin, DevelopMentor; Dave Hollander, Contivo, Inc (co-chair); Mary Holstege, Invited Expert; Jane Hunter, Distributed Systems Technology Centre (DSTC Pty Ltd); Rick Jelliffe, Academia Sinica; Simon Johnston, Rational Software; Bob Lojek, Mozquito Technologies; Ashok Malhotra, Microsoft; Lisa Martin, IBM; Noah Mendelsohn, Lotus Development Corporation; Adrian Michel, Commerce One; Alex Milowski, Invited Expert; Don Mullen, TIBCO Extensibility; Dave Peterson, Graphic Communications Association; Jonathan Robie, Software AG; Eric Sedlar, Oracle Corp.; C. M. Sperberg-McQueen, W3C (co-chair); Bob Streich, Calico Commerce; William K. Stumbo, Xerox; Henry S. Thompson, University of Edinburgh; Mark Tucker, Health Level Seven; Asir S. Vedamuthu, webMethods, Inc; Priscilla Walmsley, XMLSolutions; Norm Walsh, Sun Microsystems; Aki Yoshida, SAP AG; Kongyi Zhou, Oracle Corp.

Le groupe de travail sur XML Schema a bénéficié de la participation et des contributions d'un certain nombre de gens extérieurs au groupe de travail, et certains d'entre eux sont cités ci-dessous. Leurs noms de société d'appartenance fournis sont ceux valides a moment de leur contribution au groupe de travail.

Paula Angerstein, Vignette Corporation; David Beech, Oracle Corp.; Gabe Beged-Dov, Rogue Wave Software; Greg Bumgardner, Rogue Wave Software; Dean Burson, Lotus Development Corporation; Mike Cokus, MITRE; Andrew Eisenberg, Progress Software; Rob Ellman, Calico Commerce; George Feinberg, Object Design; Charles Frankston, Microsoft; Ernesto Guerrieri, Inso; Michael Hyman, Microsoft; Renato Iannella, Distributed Systems Technology Centre (DSTC Pty Ltd); Dianne Kennedy, Graphic Communications Association; Janet Koenig, Sun Microsystems; Setrag Khoshafian, Technology Deployment International (TDI); Ara Kullukian, Technology Deployment International (TDI); Andrew Layman, Microsoft; Dmitry Lenkov, Hewlett-Packard Company; John McCarthy, Lawrence Berkeley National Laboratory; Murata Makoto, Xerox; Eve Maler, Sun Microsystems; Murray Maloney, Muzmo Communication, agissant au nom de Commerce One; Chris Olds, Wall Data; Frank Olken, Lawrence Berkeley National Laboratory; Shriram Revankar, Xerox; Mark Reinhold, Sun Microsystems; John C. Schneider, MITRE; Lew Shannon, NCR; William Shea, Merrill Lynch; Ralph Swick, W3C; Tony Stewart, Rivcom; Matt Timmermans, Microstar; Jim Trezzo, Oracle Corp.; Steph Tryphonas, Microstar