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

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 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 version="1.0"?> 
<annuaire> 
    <personne> 
        <prenom>Claude</prenom> 
        <nom>Bernard</nom> 
        <numTel>4475</numTel> 
    </personne> 
</annuaire>

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 :

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

on préfèrera :

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

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

<?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 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>

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 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.

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 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 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 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>

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.

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…