Recommendation XML schema
De Belgif.
Usefull links : XML cluster, XML-based standards, List of recommendations.
Disclaimer : this is still a draft recommendations. It has not yet been approved by the Belgif!
Orientations techniques
Le numéro de version XML
L'attribut "version" indique la version du langage XML utilisée dans le fichier XSD.
|
Recommandation n°1 : L'attribut version prend la valeur : 1.0. |
Le Jeu de caractères (« encoding »)
Problématique : XML privilégie l'utilisation d'Unicode (et ISO 10646) :
UNICODE permet d'encoder la plupart des caractères spécifiques pour de très nombreuses langues.
Cela est rendu possible par l'utilisation d'un encodage de référence de chaque caractère sur 2 octets (65536 possibilités).
Concrètement, le jeu UNICODE est habituellement sérialisé en UTF-8 ou UTF-16.
En UTF-16, chaque caractère UNICODE est directement sérialisé sur 2 bytes (conformément à sa référence unique) mais cela fournit alors des fichiers volumineux qui ne sont pas lisibles avec n'importe quel éditeur (supportant plutôt ANSI+extensions code pages).
En UTF-8, les caractères les plus fréquents (lettres non accentuées, etc.) sont toujours encodés sur 1 seul byte comme en ANSI (l'encodage le plus fréquent), d'autres (reconnus par un préfixe) sur 2 bytes, et certains même sur 3 bytes.
- avantage: compatibilité avec ANSI si l'on n'utilise pas de caractères accentués.
Dans les deux cas, UTF-8 ou UTF-16, il faut disposer d'un éditeur supportant Unicode pour pouvoir travailler de façon confortable (ex. c'est le cas de notepad sous Windows XP, mais pas sous Windows 3.x)
L'alternative est de travailler avec un jeu de caractère alternatif à Unicode, comme ISO-8859-1 (ou -15 avec l'euro):
- avantage : supporté par tous les éditeurs Texte pour autant que l'OS soit configuré dans la même "région" en terme d'encodage
- inconvénient : évolutivité vers les caractères plus internationaux (comme le grec) compromise.
Il faudra que le système accepte d'autres jeux de caractères en entrée (même si les réponses sont fournies en ISO-8859-15)
Choix : Nos systèmes sont destinés à gérer des informations en langue française, en langue néerlandaise et (parfois) en anglais, c'est-à-dire comportant des lettres accentuées. Par conséquent, le jeu de caractères défini par la norme ISO-8859-1 (ou-15) est plus adapté en tenant compte des remarques ci-dessus. Il est alors possible d?écrire directement dans un document XML des caractères accentués.
L'utilisation du jeu ISO-8859-1 à la place de UTF-8 impose les contraintes suivantes :
- Insérer une indication XML indiquant le jeu de caractères utilisé
<?xml version="1.0" encoding="ISO-8859-1" ?>
- Utiliser un parseur XML capable d'interpréter ce jeu de caractères.
|
Recommandation n°2 : L'attribut encoding prend la valeur : ISO-8859-1 |
Les espaces de noms
La mise en oeuvre des espaces de noms vise d'une part à répondre aux objectifs de modélisation autonome des domaines et d'autre part à masquer la complexité inhérente à cette utilisation dans les documents produits et reçus par les applications ou leurs systèmes sous-jacents.
|
Recommandation n°3 :
|
Le choix attributs vs éléments
Description :
En théorie, les deux solutions (élément ou attributs) peuvent s'envisager indifféremment pour les éléments élémentaires d'une structure.
En pratique, il est cependant essentiel de se fixer la règle suivante:
Incorporation dans des éléments de tous les éléments textuels destinés à être lus (texte seul ou "mixed content" si on y supporte des marqueurs comme le gras, l'italique) et utilisation d'attributs pour tous ce qui est codifié mais n'est pas destiné à être affiché tel quel (ex. codes devant faire l'objet d'un lookup) ou ajoute de l'information de marquage complémentaire.
Exemple
<Langue isocode="fr"/>
ou
<Langue>français</Langue>
Cela est particulièrement important lorsque l'on pense à l'utilisation de moteur d'indexation plein texte, qui travailleront typiquement sur le texte obtenu par la fonction X-Path "text()": le contenu des attributs n'est pas retourné par cette fonction, le contenu textuel au sein des élements est, lui, incorporé.
|
Recommandation n°4 : Le choix retenu est que tous les attributs du modèle, quels qu'ils soient, seront représentés par des éléments XML. Les attributs d'un élément XML se justifient par la volonté de donner des particularités (ou de l'information) à cet élément (Par exemple : sa langue, son origine, sa norme, la manière de l'utiliser, ?). |
La représentation des données élémentaires
Les données élémentaires représentent les structures atomiques à partir desquelles les structures plus complexes (classes, messages) sont construites.
Les types XML de données correspondant sont construits sous forme de types simples XML construient à partir des types pré-construits XML auxquels peuvent s'appliquer des contraintes (facettes).
Le tableau suivant en présente la mise en œuvre :
| Type de données | Définition | Type pré-construit XML | Facettes | Nom du type XMLPattern |
|---|---|---|---|---|
| Numérique | Chaîne de nombre de taille maximum ="max" sans espace ni ponctuation | String | MaxLenght, pattern | xs:string, pattern: [0-9]* |
| Alphanumérique | Chaîne de nombre et de lettres de taille maximum ="max" sans espace ni ponctuation | String | MaxLength, pattern | xs :string, pattern : [0-9a-zA-Z]* |
| Date | Date sous le format AAAA/MM/JJ | Date | xs:date | |
| Année | Année sous le format AAAA | GYear | xs:gYear | |
| Booléen | Choix de deux valeurs possibles (0 ou 1) | Boolean | xs:boolean |
L'ensemble des types déclarés sera regroupé dans un même fragment réutilisable de schéma XML (par exemple :"simple_type.xsd"). Il doit être inclus (directive "xsd:include") dans les classes utilisant ces données.
Exemple de donnée élémentaire :
<xs:element name="DonneeElementaire" type="SonType"> </xs:element> <xs:simpleType name="SonType"> <xs:restriction base="xs:string"> <xs:maxLength value="50" /> <xs:pattern value="[0-9a-zA-Z]*" /> </xs:restriction> </xs:simpleType>
Le nommage des éléments et attributs XML
Choix/Règle :
La règle de désignation des noms déléments et/ou attributs XML, à partir des noms issus de l'activité de modélisation consiste à concaténer les différents mots en mettant en majuscule la première lettre de chaque mot et en minuscule les autres lettres. L'objectif est de limiter la longueur des noms de manière à maximiser la charge utile dans un document XML. Voici une remarque suite à l'application de cette règle.
Cette note provient du cahier des charges du projet « Helios ».
Une simulation effectuée par nos soins donne une charge utile comprise [10, 25]% du poids du document XML. La norme d'usage est de 1/3 (~33%).
Remarque :
Cette optimisation ne doit cependant pas compromettre la compréhension humaine de la signification de l'élément: les acronymes et abréviations qui ne sont pas de notoriété publique seront par exemple évités.
La règle est "Un utilisateur business qui visualise une représentation graphique du schéma est à même de se faire une idée des termes utilisés" sur base de leur contexte.
Il n'est par contre pas nécessaire de reprendre pour chaque élément de l'information qui serait inutilement redondante avec son contexte.
Ex.
<Eleve> <Nom>Jef Kazak</Nom> </Eleve>
plutôt que
<Eleve> <NomDeLEleve>Jef Kazak</NomDeLEleve> </Eleve>
Les caractères réservés
Un certain nombre de caractères sont interdits dans les données contenues dans un élément XML. Afin de distinguer les balises et le contenu d'un élément, on remplace les caractères suivants par, au choix, l'entité prédéfinie correspondante, ou l'unicode décimal ou hexadécimal :
| Caractère remplacé | Entité prédéfinie | Unicode décimal | Unicode héxa |
|---|---|---|---|
| < | < | < | < |
| > | > | > | > |
| & | & | & | & |
| ' | ' | ' | ' |
| " | " | " | " |
Les caractères retour chariot (
), nouvelle ligne (
), tabulation (	) et espace ( ) sont normalement préservés et transmis correctement à l'application par le parseur XML, hormis les combinaisons 
 et 
 transformées en un unique 
 (pour éviter des problèmes liés aux plates-formes hétérogènes).
Les caractères tabulation (	) sont interdits dans les données contenues dans les éléments. Les caractères retour chariot et retour ligne sont autorisés.
La transformation des classes UML en XML
Les règles de transformation d'un diagramme de classe en schéma XML sont exprimées comme suit :
- Une classe UML est représentée comme un élément XML, contenant toutes les classes immédiatement dépendantes.
- Un attribut UML est représenté comme un élément XML englobant une valeur.
Un type ou un élément ?
En cas de doute, toujours créer un type !
Cela permettra au moins de pouvoir réutiliser ce type pour un autre élément.
Techniques de construction des schémas XML
Introduction
Ce chapitre présente les techniques mises en oeuvre pour l'implémentation XML dans les applications d'un organisme.
Ces techniques portent sur les points suivants :
- Implémentation de composants réutilisables. Chaque composant donne lieu à l'élaboration d'un schéma XML et constitue une unité de livraison et de maintenance.
- Définition des règles d'assemblage des composants par domaine fonctionnel.
- Aggrégation des différents domaines fonctionnels pour former un espace de publication des schémas décrivant les structures de nos applications.
- Mise en place d'une organisation des schémas (entrepôt) en vue de publication.
La construction des composants réutilisables
Nos applications se représentent par une forte diversité de structures, obéissant à des grammaires indépendantes mais reprenant des blocs communs. L'approche préconisée consiste à construire les différentes syntaxes par assemblage de blocs. Chaque bloc fait l'objet d'une description autonome sous forme de schémas XML. Une telle approche offre une grande souplesse quant à la réutilisation des blocs. Un bloc réutilisable est constitué sous forme de schéma XML. Il ne déclare pas d'espace de nom pour faciliter la réutilisation. Le présent document introduit les types de blocs réutilisables suivants :
- Types de bases, utilisés pour les données élémentaires.
- Référentiels de codification, spécifiques par domaine.
- Classes XML pour la modélisation des différents blocs.
Les différents blocs sont placés dans un répertoire de dépôt, en vue de leur réutilisation.
Les types de base
Les types de base définissent une structure atomique de donnée. Le principe retenu est de masquer dans les schémas appelant le mode de construction des types de base utilisés. Pour cela, la démarche mise en oeuvre consiste à :
- Identifier les différents types de données élémentaires existant dans la description fonctionnelle des applications.
- Etablir la modélisation XML correspondante. Afin d'éviter une trop grande multiplicité de schémas, ces types seront regroupés dans un même schéma (par exemple : « Simple_Type_1.1.xsd »).
Pour permettre l'utilisation d'un type de base par un schéma appelant, ce dernier doit effectuer l'instruction
<xs:include schemaLocation="Simple_Type_1.1.xsd"/>
avant la déclaration des éléments constitutifs du schéma.
Le référentiel de codification
La modélisation fonctionnelle de nos applications met en évidence la ré-utilisation de codes (table des codes fédéraux par exemple), c'est à dire des valeurs restreintes à un ensemble fini. Ces champs sont valorisés de façon contextuelle à un domaine (par exemple : code pays, codes rues). Le principe est de masquer dans les schémas appelants le mode de construction de ces données. Pour cela, la démarche mise en oeuvre doit consister à :
- Identifier les différents codes communs à toutes les applications existant dans la description fonctionnelle de nos applications, domaine par domaine.
- Etablir la modélisation XML correspondante. Les types ainsi modélisés sont regroupés par domaine dans un même schéma (par exemple "CommunCodePays_1.1.xsd").
Remarques : Dans le cas où un schéma de codification ne serait pas de la responsabilité de l'organisme, le schéma appelant indiquera uniquement une dépendance à la source authentique. Il sera inutile de publier ce fichier mais seulement d'indiquer l'organisme responsable des codes. Par contre en interne nous devrons réaliser l'étape 2 de la mise en œuvre ci-dessus pour pouvoir valider le XML reçu ou envoyé.
La modélisation en Classe UML
Ce point est recommandé mais non obligatoire. Chaque bloc fonctionnel (suite séquentielle d'attributs UML) donne lieu à la constitution d'un schéma XML (classe XML) ayant pour objet de déclarer un type de données dont la description correspond au bloc. La démarche mise en œuvre doit consister à :
- Identifier les blocs à partir de la description fonctionnelle de nos applications.
- Modéliser sous forme de schéma. Les classes sous le nom de Class_{nomdelaclasse}_1.1.xsd.
Chaque classe XML incorpore (directive xs:include) le schéma Simple_Type_1.1.xsd et le cas échéant le schéma Commun_ {NomduDomaine}_1.1.xsd..
L'assemblage par domaine fonctionnel
La modélisation XML de nos applications est effectuée par domaine fonctionnel. Les règles d'assemblage consistent à :
- Affecter un répertoire au domaine fonctionnel, qui contiendra les schémas utilisés par ce domaine.
- Effectuer un clonage (opération de « copier coller ») à partir du répertoire de dépôt des schémas nécessaires à la modélisation du domaine.
- Attribuer un espace de nom au domaine fonctionnel (par exemple « http://www.belgium.be/[NOM DE DOMAINE]/CoursGeneraux ».
- Construire le schéma racine du domaine pour chacun des deux protocoles (Aller et Retour). Le nom de ce schéma est Belgium_NomduDomaineAller pour le protocole Aller (idem pour le retour). Ce schéma déclare un type de donnée correspondant à la portion de structure Belgium spécifique du domaine. Il déclare l'espace de nom du domaine et assemble les différents blocs nécessaires par « inclusion » (directive xs:include) dans le bloc d'en-tête du schéma.
La construction du répertoire des messages Belgium
Les schémas XML décrivant les messages sont construits de la manière suivante :
- Chaque objet (métier ou transverse) identifié est décrit sous forme d'un schéma XML. Les schémas ainsi produits sont neutres en terme de NameSpace (non déclaration d'espaces de noms cible, non déclaration d'espace de noms qualifiés par défaut) dans un objectif de réutilisation. La terminologie XML qualifie ces composants de « composants caméléons ». Le sous-répertoire « Schémas neutres » regroupe l'ensemble de ces composants.
- Chaque domaine fonctionnel de nos applications (Enseignement fondamentale, Enseignement supérieur) regroupe un ensemble de composants issus, par clonage (« copier coller »), du répertoire « Schéma Neutres ». Ces composants sont regroupés dans un sous-répertoire de nom « {NS_DF}/V{x}/{Ensemble de schémas}.xsd » avec :
- NS_DF : NS_{Nom du Domaine Fonctionnel}{Requête|Réponse} (NS pour NameSpace).
- Vx : V{numéro de version pour le Domaine Fonctionnel}. Par exemple lors de la première publication du Protocole d'Echange Standard, il s'agit de la version '1'.
- Chaque domaine déclare un NameSpace(désignation d'un ensemble de balises XML) correspondant au domaine fonctionnel.
- Chaque domaine réalise une inclusion (directive xs:include) des schémas constitutifs du domaine. L'ensemble des schémas ainsi inclus héritent du NameSpace du schéma racine.
- Chaque domaine positionne l'indicateur « ElementFormDefault » à « unqualified », de sorte que les instances d'éléments ne seront pas qualifiées (la référence aux NameSpace sera masquée dans les déclarations de balise) dans les documents instances, à l'exception de l'élément racine du document.
Les schémas XML décrivant les structures de nos applications, sont stockés à la racine du sous-répertoire Publication. Ils incorporent (instruction xs:import) les schémas racines des différents domaines fonctionnels de nos applications. Les structures déclarent le NameSpace « http://www.belgium.be/ ».
Bibliographie
- Programme Hélios Ministère français de l'économie et des finances Direction Générale de la Comptabilité publique : cahier des charges publié en mai 2004.
- Projet FEDOX IRISA : [[1]]
- XML Schema Best Practice - Roger L. Costello de xfront : [[2]]
- Consortium World Wide Web W3C : [[3]]
- XML Schéma des standards du gouvernement de la Grande-Bretagne [[4]]
