Schema  - Schéma

L'objectif des Schema est de définir des contraintes sur des classes de documents conformes à un même modèle. À la différence des DTD, qui ne définissaient que les relations entre les différents composants d'un document, les Schema peuvent typer les données et, par là-même, en documenter leur sens et, donc, leur utilisation.

L'objectif n'est pas d'avoir un langage extensible permettant d'exprimer n'importe quelle contrainte : seules, les contraintes consensuelles sont exprimables. Celles-ci doivent pouvoir être validées par un parser et être mises en jeu pour assister à la création d'information, surtout dans les éditeurs.

Enfin, les Schema ne s'intéressent pas à la validation d'un document XML (d'un fichier) en tant que tel. Un outil validant se basera sur la représentation en arbre d'objets typés et valués, désérialisée selon le standard Infoset. Cette volonté permet de rendre le processus de validation indépendant d'une syntaxe de codage quelconque d'un document.

Les spécifications sur les Schema sont divisées en deux parties : une sur les structures [ recommandation XML Schema Part 1: Structures] et une sur les types de données [ recommandation XML Schema Part 2: Datatypes]. Pour mieux comprendre ces deux recommandations, une introduction est aussi proposée [ recommandation XML Schema Part 0: Primer].

D'un point de vue structurel, un Schema se définit comme étant l'assemblage, sous forme d'arbre XML, d'un ensemble de composants. Il en existe 12, dont les principaux sont :

• composants de définition de types, les simples ou les complexes :

  ils permettent de typer des éléments pour leur affecter un modèle de contenu. Il en va de même pour les attributs. Ainsi, une adresse de livraison et une adresse de facturation relèveront toutes deux d'un même type adresse.

  C'est en utilisant les types simples que seront définis, dans la partie "datatypes" ( [ recommandation XML Schema Part 2: Datatypes]), des types de base comme les chaînes de caractères, les nombres, les URI ou encore toutes sortes de dates.

  Une définition de "type" peut être réalisée en restriction ou en extension d'une définition existante. Par exemple, le type adresse précédent peut être restreint à des adresses françaises, en jouant sur la définition de la valeur du code pays. Une limite du mécanisme d'extension est que l'on ne peut rajouter des éléments qu'à la fin d'un type pré-existant et que l'on ne peut pas les modifier.

  D'un point de vue programmation, les notions de types de données permettent de se reposer sur ces types de données pour effectuer des traitements partagés à différents éléments du même type. Ceci simplifie beaucoup les méthodes de programmation, tout en nécessitant d'avoir toujours accès au modèle, en même temps que l'on effectue les traitements.

• composants de déclaration : éléments, attributs et notations

  Ces composants permettent de déclarer, comme avec les DTD, des éléments, avec leurs modèles de contenus, et ainsi que des attributs. Pour ce faire, et dans le but de factorisation précédemment expliqué, les déclarations peuvent se reposer sur des composants de définition de type.

• composants groupes : pour la factorisation d'informations de modèles de contenus ou d'attributs.

  Ces composants permettent de définir des modèles qui seront souvent réutilisés, soit pour définir des composants de déclaration, soit pour définir des composants de définition de types. Dans les DTD traditionnelles, ces groupes étaient formalisés par des entités paramètres, qui permettaient, par exemple, de définir tous les composants blocks (paragraphes, listes, remarques, etc.) nécessaires lors de la définition de modèles de contenus.

D'un point de vue typage de données, la spécification [ recommandation XML Schema Part 2: Datatypes] propose un ensemble important de types et une façon d'étendre ces types, pour une application donnée, à des choses plus complexes.

Finalement, un Schema est un modèle d'information défini sous forme électronique (comme l'était une DTD), mais avec des outils de modélisation plus puissants. Dans la sphère XML, le Schema pourra être utilisé comme outil de validation interactif de données, lors de la création de celles-ci, dans un éditeur, voire, plus tard, dans des XForms, sur Internet.

Des limites ? En lisant les listes de discussion, on peut trouver beaucoup de limitations exprimées sur ces possibilités de validation. Par exemple, d'aucuns parlent du fait de ne pas pouvoir valider un modèle de contenu en fonction d'une valeur d'attribut d'un élément englobant. C'est toute l'ambiguïté de l'utilisation des Schema qui est alors posée : est-ce un langage de programmation permettant d'exprimer des contraintes de validation ou est-ce un langage de définition de modèles ?

En avancant dans le sens de l'utilisation de modèles pour des activités d'ingéniérie, et grâce aux nouvelles possibilités de typage, on peut avoir plusieurs DTD et Schema, fonctionnant sur une même classe de documents et, par des définitions de typage, déclencher dessus des processus applicatifs ad hoc. C'est ce qu'avaient fort bien compris les concepteurs de l'ICADD, pour rendre accessibles les documents aux non-voyants. Dans leurs spécifications, ils expliquent comment, en jouant seulement sur les attributs d'une DTD, on peut ajouter automatiquement de l'information aux documents, au moment de leur parsing, pour le plus grand profit des non-voyants qui pourront parcourir n'importe quel type de documents en se basant sur ces repères.

Liste des types définis dans les schémas.