Modélisation de XML : choix de structures pour la représentation des données

Erwan Amoureux

Quelques exemples de l'utilisation de XML en tant que structure de données.

Commentez

Un remerciement spécial pour avoir épluché mon orthographe et ma ponctuation à Benj.

- Titre : Modélisation de XML : choix de structures pour la représentation des données

- Auteur : Erwan Amoureux

- Parution : 18 janvier 2011

- Mise à jour : 12 juillet 2020

- Licence : Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright ® 2010 Erwan Amoureux. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Règles de création de documents XML

- I-A. Exemple 1 : sémantique

- I-B. Exemple 2 : de l'usage des attributs

- I-C. Exemple 3 : une structure ordonnée

- I-D. Exemple 4 : hiérarchie et arborescence

- II. Utilisations de multiples XML

- II-A. Problématique du XML unique

- II-B. Organisation des XML

I - Règles de création de documents XML

XML est utilisé à son profit maximum pour des flux/documents ayant une certaine temporalité ou à usages multiples. Sur des mécanismes de simple passage d'objet, on lui préfèrera d'autres technologies, comme JSON dans de nombreuses implémentations AJAX. Bien plus qu'un simple flux, il permet à son utilisateur de construire une structure de données dont l'utilisation pourra évoluer. Il est en ceci très proche des bases de données relationnelles où le schéma de la base se fonde, non sur l'utilisation qui en est faite, mais sur la structure même de la donnée. S'il a le même avantage, il en a aussi les contraintes : toute construction d'un XML se doit de comporter une analyse minimum sur sa forme et les relations entre les données contenues. Les exemples qui suivent ne prétendent pas être exhaustifs, mais donnent quelques pistes en la matière.

I-A - Exemple 1 : sémantique

Le nom des balises d'un flux XML se doit d'avoir un sens, d'être compréhensible par quelqu'un n'ayant qu'un minimum de connaissances fonctionnelles du sujet ; de même que dans une base de données relationnelle, on choisira des noms descriptifs pour les tables et leurs champs.
Exemple :

xml

<?xml version="1.0"?>
<a>
<p>
<pr>Claude</pr>
<no>Bernard</no>
<num>4475</num>
</p>
</a>

On supposera que pr correspond au prénom et no au nom, mais qu'en est-il de num ?
Est-ce un numéro de téléphone interne ? Un matricule ? Un code de bureau ?
Ce type d'erreur peut coûter très cher en maintenance ou en développement, en particulier lors de passage de connaissance. Un format XML est fait pour être utilisé par de nombreuses personnes, son sens doit être le plus clair possible.

xml

<?xml version="1.0"?>
<annuaire>
<personne>
<prenom>Claude</prenom>
<nom>Bernard</nom>
<numTel>4475</numTel>
</personne>
</annuaire>

I-B - Exemple 2 : de l'usage des attributs

Un autre exemple, malheureusement fréquent, qu'il ne faut pas suivre : miser l'ensemble des informations sur le nom d'une balise.

En règle générale on considérera qu'un nom de balise est là pour indiquer la nature de l'information contenue, ses attributs pour la différencier des autres. La donnée brute est contenue dans la balise, les éléments permettant de la traiter dans les attributs.
Quelques exemples classiques d'utilisation d'attributs :

- identifiant ;

- langue du texte ;

- options d'affichage.

Par exemple à ceci :

xml

<personnes>
<homme>..</homme>
<femme>..</femme>
</personnes>

on préfèrera :

xml

<personnes>
<personne sexe="M">..</personne>
<personne sexe="F">..</personne>
</personnes>

Pour prendre un exemple moins caricatural et assez fréquent :

xml

<?xml version="1.0"?>
<annuaire>
<personne>
<prenom>Claude</prenom>
<nom>Bernard</nom>
<TelFixe>0136784478</TelFixe>
<TelPort>0675789078</TelPort>
</personne>
</annuaire>

Cette version risque en plus de devoir être modifiée, si la personne a un fixe personnel et professionnel. Verra-t-on alors apparaître TelFixePerso, TelFixePro ? Ceci posera un problème par la suite. En effet, dans tous les traitements liés au XML, de la validation à la transformation tout est centré sur l'élément et donc principalement sur son nom.

Rajouter un nouvel élément n'est donc jamais neutre.

Il est toujours préférable d'ajouter une nouvelle valeur d'attribut, celle-ci pouvant se permettre d'être plus exhaustive

xml

<?xml version="1.0"?>
<annuaire>
<personne>
<prenom>Claude</prenom>
<nom>Bernard</nom>
<Tel type="fixe personnel">0136784478</Tel>
<Tel type="fixe professionnel">0136778945</Tel>
<Tel type="portable personnel">0675789078</Tel>
</personne>
</annuaire>

I-C - Exemple 3 : une structure ordonnée

Dans un XML l'ordre des éléments est une information en soi.
Contrairement au SGBDR et au SQL, où si aucun ordre n'est spécifié dans la requête, on ne peut prévoir l'ordonnancement du résultat. Celui par défaut sur un XML est celui de sa déclaration dans le fichier texte (hormis le cas des attributs). Si on gère donc de façon pertinente les différents types de mises à jour d'un fichier XML, l'ordre du fichier devient une donnée et on n'est plus obligé de le coder via un élément ou un attribut.

xml

<?xml version="1.0"?>
<donnees>
<ligne num="1">..</ligne>
<ligne num="2">..</ligne>
<ligne num="3">..</ligne>
<ligne num="4">..</ligne>
</donnees>

Il faut savoir que les langages et outils de sélections sur XML permettent tous :

- de récupérer le énième élément ;

- de connaître le nombre d'éléments et/ou de sélectionner automatiquement le dernier.

De fait l'attribut num ici n'est indispensable que si trois conditions sont présentes :

- si l'ordre est une information pertinente ;

- si le fichier peut être modifié ;

- si la création/modification ne garantit pas une séquence valide des éléments.

I-D - Exemple 4 : hiérarchie et arborescence

Un des pires exemples d'utilisation XML est sans aucun doute celui où sa nature arborescente est inutilisée. Cette dernière permet en effet de stocker naturellement des informations de ce type (document, hiérarchie, organisation d'entreprises) sans passer par les systèmes d'associations des structures.
Continuer d'appliquer une solution de forme tabulaire à un document XML n'est malheureusement pas un cas rare, mais aussi un de ceux qui posent les plus graves problèmes de traitements par la suite.
Un exemple trop fréquemment appliqué :

xml

<?xml version="1.0" encoding="UTF-8"?>
<livre>
<chapitre num="1">
<titre>A</titre>
<corps>....</corps>
</chapitre>
<chapitre num="1.1">
<titre>AA</titre>
<corps>....</corps>
</chapitre>
<chapitre num="1.1.1">
<titre>AAA</titre>
<corps>....</corps>
</chapitre>
<chapitre num="1.1.2">
<titre>AAB</titre>
<corps>....</corps>
</chapitre>
<chapitre num="1.2">
<titre>AB</titre>
<corps>....</corps>
</chapitre>
<chapitre num="2">
<titre>B</titre>
<corps>....</corps>
</chapitre>
<chapitre num="2.1">
<titre>BB</titre>
<corps>....</corps>
</chapitre>
</livre>

Cette donnée est naturellement arborescente. Cette forme séquentielle impose de lourds traitements pour pouvoir repasser dans un format arborescent. De plus, des instructions spécifiques , en particulier en XSLT (xsl:number) permettent l'équivalent de numérotation de l'attribut num. Dans le domaine de la donnée, toute donnée superflue ou répétée est équivalente à du bruit et introduit un risque d'erreur supplémentaire en cas de modification.

Le format d'un tel document devrait donc être au minimum :

xml

<?xml version="1.0" encoding="UTF-8"?>
<livre>
<chapitre num="1">
<titre>A</titre>
<corps>....</corps>
<chapitre num="1.1">
<titre>AA</titre>
<corps>....</corps>
<chapitre num="1.1.1">
<titre>AAA</titre>
<corps>....</corps>
</chapitre>

<chapitre num="1.1.2">
<titre>AAB</titre>
<corps>....</corps>
</chapitre>
</chapitre>
<chapitre num="1.2">
<titre>AB</titre>
<corps>....</corps>
</chapitre>
</chapitre>
<chapitre num="2">
<titre>B</titre>
<corps>....</corps>
<chapitre num="2.1">
<titre>BB</titre>
<corps>....</corps>
</chapitre>
</chapitre>
</livre>

Mais comme nous l'avons vu dans la partie précédente, la numérotation des chapitres est redondante par rapport à la structure du fichier ci-dessous.

xml

<?xml version="1.0" encoding="UTF-8"?>
<livre>
<chapitre>
<titre>A</titre>
<corps>....</corps>
<chapitre>
<titre>AA</titre>
<corps>....</corps>
<chapitre>
<titre>AAA</titre>
<corps>....</corps>
</chapitre>
<chapitre>
<titre>AAB</titre>
<corps>....</corps>
</chapitre>
</chapitre>
<chapitre>
<titre>AB</titre>
<corps>....</corps>
</chapitre>
</chapitre>
<chapitre>
<titre>B</titre>
<corps>....</corps>
<chapitre>
<titre>BB</titre>
<corps>....</corps>
</chapitre>
</chapitre>
</livre>

II - Utilisations de multiples XML

Au niveau des traitements, que se soit DOM, XQuery (langage de requêtes) ou XSLT (langage de transformation), tous permettent d'atteindre différents fichiers ainsi que des mécanismes de sélection. Il peut donc être plus pertinent d'opérer une partition des données en fonction des problématiques.

II-A - Problématique du XML unique

Dans une application vous n'êtes pas obligé de stocker toutes vos données dans un seul fichier XML.
Un fichier unique posera différents problèmes, entre autres :

- problème de volumétrie si le travail nécessite un chargement en mémoire ;

- mise à jour, lecture et autres traitements plus longs (toujours fonction de la taille mémoire occupée) ;

- sécurité des données, tous vos utilisateurs n'ont pas forcément les mêmes niveaux de visibilité ;

- manque de lisibilité et complexité accrue, en particulier si différents ensembles fonctionnels y sont regroupés.

II-B - Organisation des XML

Par rapport aux problèmes évoqués précédemment, certains doivent être traités prioritairement.
En priorité, gérer les problèmes d'accès sécurité s'ils existent. Il est difficile et pas forcément fiable d'essayer de limiter l'accès d'une application à une partie d'un fichier.
Ensuite il vous faudra gérer l'aspect fonctionnel de vos données. Comme pour un SGBDR, cela revient à réorganiser en priorité vos données, non selon l'utilisation que vous en faîtes à un instant t, mais selon leurs natures et leurs relations.
Enfin, s'il existe encore, gérer le problème volumétrique.
Si on traite ce problème en dernier c'est qu'il peut, en plus d'être réglé par les deux précédentes réorganisations, être soulagé par une solution technologique. En effet, de nombreuses solutions s'orientent vers des solutions partiellement SAX ou orientée streaming, ce qui permet de moins se préoccuper de la taille. Si cela ne convient pas, il faut s'inspirer des solutions de partitionnement sur les SGBD. Trouver une distinction qui soit aussi physique que logique : année, mois, entreprise, produits… Il existe des types d'API comme Cocoon qui utilisent des technologies comme Xlink, permettant de gérer ces fichiers comme des ensembles.
Si vous appliquez ces traitements et que vous voyez exploser le nombre de vos fichiers XML il est peut-être temps de regarder du côté d'une solution base de données XML native ou au moins de les intégrer à un SGBDR comme le permettent Oracle,DB2,SQL Server…