Lisez-moi S.V.P. 

3. Définition de la conformité

Sommaire

Cette section est normative.

Afin d'assurer la portabilité maximale des documents de la famille XHTML entre les agents utilisateurs de la famille XHTML, cette spécification définit de manière rigide les conditions de conformité pour eux et pour les types de document de la famille XHTML. Bien que les définitions de conformité se trouvent dans cette section, celles-ci se rapportent à du texte normatif dans ce document, dans la spécification XHTML de base [XHTML1] et dans d'autres spécifications liées. On ne peut comprendre entièrement les conditions de conformité de XHTML qu'au travers d'une lecture complète de toutes les références normatives.

Les mots-clés « doit », « ne doit pas », « obligatoire », « devra », « ne devra pas », « devrait », « recommandé », « peut » et « optionnel » dans ce document doivent s'entendre comme décrit dans le document [RFC2119].

3.1. Conformité du type de document au langage hôte XHTML

Il est possible de modifier des types de document existants et définir entièrement de nouveaux types de document en utilisant les modules définis dans cette spécification et d'autres modules. Un tel type de document est conforme au langage hôte XHTML s'il satisfait aux critères suivants :

  1. Le type de document doit être défini à l'aide d'une des méthodes de mise en œuvre établies par le W3C. Pour l'instant celles-ci se limitent aux définitions DTD XML et aux schémas XML ;
  2. Le schéma qui définit le type de document doit avoir un identificateur unique, comme défini à la section Règles de nommage, qui commence par la séquence de caractères "XHTML" ;
  3. Le schéma qui définit le type de document doit au minimum inclure les modules Structure, Hypertext, Text et List définis par cette spécification ;
  4. Pour chaque module défini par le W3C qui est inclus, tous les éléments, attributs, types des attributs (y compris les listes obligatoires de valeurs énumérées) et les modèles de contenu minimaux obligatoires doivent être inclus (et éventuellement étendus) dans le modèle de contenu du type de document. Si les modèles de contenu sont étendus, tous les éléments et attributs (ainsi que leurs types ou toutes listes obligatoires de valeurs énumérées), qui sont obligatoires dans le modèle de contenu original, doivent continuer de l'être ;
  5. Le schéma qui définit le type de document peut définir des éléments et attributs supplémentaires. Toutefois ceux-ci doivent l'être dans leur propre espace de noms XML [XMLNAMES]. Si un module définit des éléments supplémentaires, les attributs définis dans les modules XHTML inclus sont disponibles pour une utilisation sur ces éléments, mais devraient être référencés par leur identificateur qualifié d'un espace de noms (par exemple, xhtml:class. La sémantique des attributs reste la même que lors d'une utilisation sur un élément de l'espace de noms XHTML.

3.2. Conformité du type de document à l'ensemble d'intégration XHTML

Il est également possible de définir des types de document qui sont fondés sur XHTML mais n'adhèrent pas à sa structure. Un tel document est conforme à l'ensemble d'intégration XHTML s'il satisfait à tous les critères suivants :

  1. Le type de document doit être défini à l'aide d'une des méthodes de mise en œuvre établies par le W3C. Pour l'instant celles-ci se limitent aux définitions DTD XML et aux schémas XML ;
  2. Le schéma qui définit le type de document doit avoir un identificateur unique, comme défini à la section Règles de nommage. Cet identificateur doit contenir la séquence de caractères "XHTML" mais ne doit pas commencer par elle ;
  3. Le schéma qui définit le type de document doit au minimum inclure les modules Hypertext, Text et List définis par cette spécification ;
  4. Pour chaque module défini par le W3C qui est inclus, tous les éléments, attributs, types des attributs (y compris les listes obligatoires de valeurs énumérées) et les modèles de contenu minimaux obligatoires doivent être inclus (et éventuellement étendus) dans le modèle de contenu du type de document. Si les modèles de contenu sont étendus, tous les éléments et attributs (ainsi que leurs types ou toutes listes obligatoires de valeurs énumérées), qui sont obligatoires dans le modèle de contenu original, doivent continuer de l'être ;
  5. Le schéma qui définit le type de document peut définir des éléments et attributs supplémentaires. Toutefois ceux-ci doivent l'être dans leur propre espace de noms XML [XMLNAMES]. Si un module définit des éléments supplémentaires, les attributs définis dans les modules XHTML inclus sont disponibles pour une utilisation sur ces éléments, mais devraient être référencés par leur identificateur qualifié d'un espace de noms (par exemple, xhtml:class. La sémantique des attributs reste la même que lors d'une utilisation sur un élément de l'espace de noms XHTML.

3.3. Conformité du module à la famille XHTML

Cette spécification établit une méthode pour définir des modules conformes à XHTML. Un module est conforme à cette spécification s'il satisfait à tous les critères suivants :

  1. Le type de document doit être défini à l'aide d'une des méthodes de mise en œuvre établies par le W3C. Pour l'instant celles-ci se limitent aux définitions DTD XML et aux schémas XML ;
  2. Le schéma qui définit le module doit avoir un identificateur unique, comme défini à la section Règles de nommage ;
  3. Si le module est défini avec une définition DTD XML, le module doit isoler ses noms d'entité paramètre à l'aide de préfixes uniques ou d'autres méthodes similaires ;
  4. La définition du module doit comporter une définition en langage courant (prose definition) qui décrit les exigences syntaxiques et sémantiques des éléments, attributs ou modèles de contenu que celle-ci déclare. Pour dissiper les doutes, s'il y a divergence entre la définition informelle d'un module et ses mises en œuvre de schéma, la définition en langage courant doit être privilégiée ;
  5. La définition du module ne doit pas réutiliser les noms d'élément qui sont définis dans d'autres modules établis par le W3C, sauf si le modèle de contenu et la sémantique de ces éléments sont soit identiques à l'original, soit une extension de l'original, ou si les noms d'élément réutilisés sont dans leur propre espace de noms XML (voir ci-dessous) ;
  6. Les éléments et attributs de la définition du module doivent appartenir à un espace de noms XML [XMLNAMES]. Si le module est défini par une autre organisation que le W3C, cet espace de noms ne doit pas être le même que celui dans lequel les modules du W3C sont définis.

3.4. Conformité du document à la famille XHTML

Un document conforme à la famille XHTML est une instance valide d'un type de document conforme au langage hôte XHTML. Pour dissiper les doutes, le comportement des agents utilisateurs, confrontés à des documents invalides, n'est pas défini.

3.5. Conformité de l'agent utilisateur à la famille XHTML

Un agent utilisateur conforme doit satisfaire à tous les critères suivants (comme défini dans [XHTML1]) :

  1. Pour la cohérence avec la recommandation XML 1.0 [XML], l'agent utilisateur doit analyser et évaluer la bonne forme (well-formedness) du document XHTML. Si l'agent utilisateur prétend être un agent utilisateur validant, il doit également valider les documents par rapport aux schémas qui y sont référencés ;
  2. Si l'agent utilisateur prétend gérer les facilités définies dans cette spécification ou exigées par référence normative, il doit le faire en cohérence avec les définitions des facilités ;
  3. Si l'agent utilisateur traite un document XHTML comme du [XML] générique, il doit seulement reconnaître les attributs de type ID (par exemple, l'attribut id sur la plupart des éléments XHTML) comme étant des identificateurs de fragment ;
  4. Si l'agent utilisateur est confronté à un élément qu'il ne reconnaît pas, il doit continuer à en traiter les sous-éléments (children) ;
  5. Si l'agent utilisateur est confronté à un attribut qu'il ne reconnaît pas, il doit ignorer complètement la spécification d'attribut (c'est-à-dire l'attribut et sa valeur) ;
  6. Si l'agent utilisateur est confronté à une référence d'entité (autre que l'une des entités prédéfinies) pour laquelle il n'a traité aucune déclaration (ce qui peut arriver si la déclaration se trouve dans le sous-ensemble externe que l'agent utilisateur n'aurait pas lu), la référence d'entité devrait être rendue par les caractères (commençant par l'esperluette « & » et finissant par le point-virgule) qui la constituent ;
  7. Au rendu du contenu, les agents utilisateurs confrontés à des caractères ou des références d'entité de caractère qui sont reconnus mais pas rendables (renderable) devraient afficher le document de telle façon que l'utilisateur se rende compte d'un rendu anormal ;
  8. Les caractères blancs (whitespace) sont définis comme dans [XML]. À l'entrée, tous les caractères blancs sont conservés — exactement comme si l'attribut xml:space, défini dans [XML], avait la valeur "preserve". Si la valeur de cet attribut est fixée à "default", c'est la même chose que si celle-ci était "preserve". Au rendu, les caractères blancs sont traités selon les règles de [CSS2].

3.6. Règles de nommage

Les types de document de langage hôte XHTML doivent adhérer à des conventions de nommage strictes afin que les logiciels et les utilisateurs puissent aisément déterminer la relation des types de document à XHTML. Les noms des types de document mis en œuvre comme des définitions de type de document XML sont définis par des identificateurs publics formels (formal public identifiers). Dans les identificateurs publics formels, les champs sont séparés par des séquences de deux caractères barre oblique (//). Les divers champs doivent être composés comme suit :

  1. Le champ de tête doit être "-" pour indiquer une ressource de définition privée ;
  2. Le deuxième champ doit contenir le nom de l'organisation chargée du suivi de l'élément nommé. Il n'existe aucun registre formel pour les noms de ces organisations. Chaque organisation devrait établir un nom unique. Par exemple, le nom utilisé par le W3C est "W3C" ;
  3. Le troisième champ contient deux constructions : la classe de texte publique suivie de la description de texte publique. Le premier atome dans le troisième champ est la classe de texte publique qui devrait adhérer à la norme ISO 8879, clause 10.2.2.1 Classe de texte publique. Seuls les documents conformes au langage hôte XHTML devraient commencer la description de texte publique par l'atome "XHTML". La description de texte publique devrait contenir la chaîne "XHTML" si le type de document est conforme à l'ensemble d'intégration. Le champ doit également contenir l'identificateur unique défini par l'organisation (par exemple, MyML 1.0). Cet identificateur devrait se composer d'un nom unique et d'un identificateur de version qui peut être mis à jour au fur et à mesure de l'évolution du type de document ;
  4. Le quatrième champ défini la langue dans laquelle l'élément est développé (par exemple, "EN").

Selon ces règles, le nom d'un type de document conforme au langage hôte XHTML serait -//MyCompany//DTD XHTML MyML 1.0//EN. Celui d'un module conforme à la famille XHTML serait -//MyCompany//ELEMENTS XHTML MyElements 1.0//EN. Celui d'un type de document conforme à l'ensemble d'intégration XHTML serait -//MyCompany//DTD Special Markup with XHTML//EN.

3.7. Évolution des modules XHTML

Chaque module défini dans cette spécification est pourvu d'un identificateur unique qui adhère aux règles de nommage de la section précédente. Avec le temps, le module peut évoluer. Une conséquence logique de cette évolution serait que certains aspects du module ne soient plus compatibles avec une définition précédente. Afin de s'assurer que les types de document définis par rapport aux modules établis dans cette spécification continuent de fonctionner, les identificateurs associés à un module qui change seront mis à jour. En particulier, l'identificateur public formel et l'identificateur de système (system identifier) seront modifiés en changeant l'identificateur de version inclus dans chaque. Les types de document qui voudront incorporer la fonctionnalité mise à jour devront être mis à jour de la même manière.

En outre, les anciennes versions du module resteront disponibles via leurs identificateurs uniques précédents. De cette façon, les types de document développés avec les modules XHTML continueront de fonctionner de manière cohérente avec leurs définitions originales, même si la collection s'étend et évolue. De la même façon, les instances de document écrites par rapport à ces types de document resteront valides avec les anciennes définitions des modules.

Les auteurs de modules et types de document de la famille XHTML sont invités à adopter une stratégie similaire afin d'assurer la continuité de fonctionnement des types de document fondés sur ces modules et des instances de document fondées sur ces types de document.