Lisez-moi S.V.P. 

A. Construction des modules de schéma

Sommaire

Cette annexe est normative.

Les modules XHTML sont mis en œuvre comme des schémas XML. Lorsque ces schémas XML sont assemblés d'une manière spécifique (décrite à la section Développement de schémas avec des modules définis et étendus), le schéma final est la représentation d'un type de document complet. Cette représentation peut alors servir à la validation des instances du type de document.

Les clés de la combinaison de ces composantes de schéma en un schéma significatif et cohésif sont les règles utilisées pour définir les schémas XML particuliers. Cette section définit ces règles. S'ils observent ces règles, les créateurs de langages de balisage peuvent être sûrs que leurs modules s'interfaceront proprement avec d'autres modules compatibles avec XHTML.

Les modules conformes à ces règles doivent aussi satisfaire aux exigences de conformité définies à la section Conformité du module à la famille XHTML pour prétendre au titre de modules de la famille XHTML.

A.1. Modèles de contenu nommés

Cette spécification range les modèles de contenu nommés en catégories et les nomme systématiquement en utilisant les suffixes suivants :

.content
Les définitions de groupe de modèles emploient le suffixe .content lorsqu'elles servent à représenter le modèle de contenu d'un type d'élément.
.class
Les définitions de groupe de modèles emploient le suffixe .class lorsqu'elles servent à représenter des éléments de la même classe.
.mix
Les définitions de groupe de modèles emploient le suffixe .mix lorsqu'elles servent à représenter une collection de types d'élément de classes différentes.
.extra
Les définitions de groupe de modèles emploient le suffixe .extra lorsqu'elles servent à étendre les autres groupes ci-dessus.
.export
Les définitions de groupe de modèles ajoutent le suffixe .export lorsqu'elles doivent être utilisées par un langage hôte comme base d'extension du modèle de contenu lié (par exemple, le modèle de contenu xhtml.Flow.mix pourrait avoir un xhtml.Flow.mix.export qui définit une collection d'éléments à inclure dans une redéfinition de xhtml.Flow.mix par un langage hôte).
.type
Les définitions de type complexe nommées emploient le suffixe .type lorsqu'elles servent à représenter le type d'un élément. Les types contiennent habituellement les composantes .attlist et .content.
.attlist
Les groupes d'attributs emploient le suffixe .attlist lorsqu'ils servent à représenter les attributs d'un élément spécifique.
.attrib
Les groupes d'attributs emploient le suffixe .attrib lorsqu'ils servent à représenter une ou plusieurs spécifications d'attribut complètes au sein d'une déclaration .attlist.

Par exemple, dans HTML 4, l'entité paramètre %block; représente la collection hétérogène des types d'éléments qui sont des éléments de type bloc (block-level elements). Dans cette spécification, le modèle de contenu nommé corollaire est xhtml.Block.mix.

Lors de la définition des modèles de contenu nommés dans les classes décrites ici, les modules devraient définir la portée (scope) des noms des définitions de groupe de modèles et de groupe d'attributs en utilisant des préfixes uniques (cette recommandation utilise le préfixe xhtml.. Par exemple, le modèle de contenu de l'élément myelement dans le module mymodule se nommerait mymodule.myelement.content. D'autres systèmes (schemes) sont possibles. Quel que soit le système utilisé, les créateurs de modules devraient s'efforcer d'attribuer un nom unique aux modèles de contenu nommés qu'ils définissent afin que ces modèles de contenu nommés n'entrent pas en conflit avec d'autres et que les méthodes d'interface des modules soient claires pour leurs utilisateurs.

A.2. Définition de l'espace de noms d'un module

XHTML impose que les éléments et attributs déclarés dans un module soient dans un espace de noms défini [XMLNAMES]. L'identification de cet espace de noms est une adresse URI arbitraire. XHTML n'impose pas qu'un module déclare son espace de noms cible avec l'attribut targetnamespace. XHTML Modularization utilisant XML Schema a adopté une approche « liaison tardive » (late binding) sur l'association à un espace de noms. Cela permet de développer des modules dits « caméléons », où les éléments et attributs d'un module peut être incorporés dans plus d'un espace de noms.

A.2.1. Déclarations d'élément globales et locales

Alors que XML Schema permet la définition de déclarations d'élément globales et locales, pour être compatibles avec les définitions DTD de XHTML Modularization, les mises en œuvre des modules ne doivent pas déclarer d'éléments locaux.

A.2.2. Déclarations d'attribut globales et locales

Alors que l'approche définie ici permet la définition de déclarations d'attribut aussi bien globales que locales, les créateurs de schémas devraient examiner les conséquences de telles définitions sur une instance de document. Les attributs globaux doivent toujours être explicitement préfixé dans une instance de document en déclarant un préfixe d'espace de noms de la forme xmlns:préfixe, tandis que les attributs locaux, qui dépendent de la mise en œuvre du schéma, peuvent être explicitement préfixé.

A.3. Importation des composantes de schéma d'un espace de noms externe

Un schéma XML fournit des définitions qui appartiennent à un espace de noms cible donné. Un schéma doit utiliser l'élément import pour inclure les composantes d'un schéma XML qui utilise un espace de noms cible différent. L'élément import dans XML Schema nécessite un attribut namespace et un attribut schemaLocation optionnel. Plusieurs modules (inclus dans un type de document), qui importent des composantes du même espace de noms externes mais fournissent des valeurs URI d'emplacement de schéma différentes, produiront un schéma pilote invalide. Pour éviter ces problèmes, la modularisation exige des modules qui importent des schémas externes, qu'ils ne fournissent pas d'attribut schemaLocation, afin que le fichier pilote du type de document puisse importer ces schémas avec l'attribut schemaLocation.

A.4. Définitions et espaces de noms des types de données

Alors que les éléments et attributs d'un module ne devraient pas se trouver dans un espace de noms avant d'être utilisés par un langage de balisage, les types de données dont dépend un module devront peut-être s'y trouver. Cela est particulièrement important si les types de données doivent être partagés avec d'autres langages de balisage. Si le module a des types de données que l'on souhaite partager avec d'autres modules, on devrait définir un espace de noms pour ces types de données, placer les définitions des types de données dans un « module » séparé et lier ce module à l'espace de noms. Dans XHTML Modularization, par exemple, nous utilisons l'espace de noms http://www.w3.org/1999/xhtml/datatypes/.

A.5. Redéfinitions des modèles de contenu

Les modules changent très souvent le modèle de contenu des éléments définis par d'autres modules. Par exemple, le module XHTML Intrinsic Events ajoute des attributs d'événement aux éléments définis par le module Forms. Il est également possible que plusieurs modules changent le modèle de contenu d'un seul élément défini par un module tiers, par exemple les deux modules XHTML Intrinsic Events et Client-Side Image Map ajoutent des attributs aux éléments du module Forms.

XML Schema permet de modifier un modèle de contenu déclaré à l'aide de l'élément redefine. Alors que XML Schema soutient l'utilisation d'un élément redefine qui redéfinit le modèle de contenu nommé et la définition d'un type, le langage ne soutient pas directement la redéfinition de la déclaration d'un élément ou d'un attribut.

Pour gérer les redéfinitions du modèle de contenu d'un élément, tous les modèles de contenu sont définis avec un identificateur .content. Cet identificateur peut aisément être redéfini lors de la création d'un module pilote.