Le dilemme de la propriété d’un élément
Lorsqu’on construit un modèle de document xml, on est confronté à dilemme:
Cette propriété doit-elle être un attribut ou bien un sous-élément ?
La réponse à cette question est lourde de conséquences en cas d’erreur, car un changement de statut dans l’avenir obligera à modifier le modèle et posera de gros problèmes aux logiciels qui utilisent le format que l’on aura modifié. Le fonctionnement interne du logiciel devra être modifié, et il devra transcoder les documents entre l’ancien format et le nouveau.
Exemple d’un changement de modèle:
Dans l’élément « a », on a une propriété « value1 » que l’on écrit sous la forme simple d’un attribut:
<a value1="100" value2="200"/>
Plus tard on décide que cette propriété pourrait être plus complexe dans certains cas.
On la transforme donc en un sous-élément de « a »:
<a value2="200"> <value1> <pixel> <x>10</x> <y>20</y> </pixel> </value1> </a>
La propriété « value1 » ayant changé de structure, on doit donc transcoder tous les documents qui suivent ce modèle.
Palliatif
Il existe une astuce pour pallier à cet inconvénient, en gardant la propriété sous forme d’attribut mais en lui donnant une syntaxe plus complexe:
<a value1="pixel x=10 y=20" value2= "200">
L’ennui, c’est qu’on se retrouve avec une syntaxe particulière pour chaque attribut un peu complexe, ce qui est précisément l’inverse de ce qu’on recherche en xml: une syntaxe régulière et vérifiable par n’importe quel outil xml.
Et en XAML ?
Il est intéressant de noter que les concepteurs du langage XAML, le principal descripteur d’interface graphique utilisateur sous Windows, ont choisit de laisser le choix aux programmeurs qui écrivent un document XAML.
Voici un élément XAML représentant un contrôle graphique, TextBox, qui affiche et permet d’éditer un texte simple.
On peut exprimer le texte dans un attribut:
<TextBox Text="mon texte"/>
Ou bien dans un sous-élément XML:
<TextBox> <TextBox.Text>mon texte</TextBox.Text> </TextBox>
En fait, pour l’élément TextBox, le Texte est son contenu principal, on peut donc aussi l’exprimer comme la valeur de l’élément XML:
<TextBox>mon texte</TextBox>
On peut dire que les concepteurs du XAML ont rendu leur langage assez souple pour faciliter la vie des utilisateurs (développeurs) et leur permettre d’écrire le code le plus court possible selon le cas.
Certains pourraient critiquer ce choix, qui assimile allègrement les concepts d’attribut, de sous-élément et de valeur. Mais, au fond, est-ce que ça n’est pas le signe qu’ici le Texte a tout simplement une seule signification, être la propriété principale de l’élément TextBox, et que si XML a plusieurs façons d’exprimer cela, c’est peut-être sa faute à lui ?
Je trouve que le XAML met bien en valeur les incohérences du XML, en s’y adaptant tant bien que mal.
Et ailleurs ?
Il existe des méta-langages textuels qui ne font pas de distinction entre propriétés simples et propriétés complexes.
Par exemple en JSON:
{ "a" : { "value1":"100", "value2":"200" } }
peut devenir, lorsqu’on choisit de rendre la propriété « value1 » plus complexe:
{ "a" : { "value1": { "Pixel" : { "x":"10", "y":20 } } , "value2":"200" } }
J’ai pu apprécier la différence lorsque j’ai un écrit un sérialiseur généraliste (UniversalSerializer).
En JSON, j’ai pu écrire un modèle de données en arbre très vite.
Alors qu’en XML, il m’a fallu cogiter longuement pour de nombreuses propriétés d’éléments, au risque de devoir modifier mon modèle plus tard, avec tous les inconvénients que ça suppose.
Le problème du XML
En fait, la syntaxe XML ne permet pas l’imbrication des balises.
Pour obtenir l’équivalent de ce que j’ai écrit plus haut en JSON, il faudrait que le XML permette ceci:
<a <value1><Pixel><x>10</x><y>20</y></value1> value2="200"/>
Ce qui bien entendu est strictement interdit en XML: un élément (une balise en fait) ne peut pas contenir une autre balise (c’est à dire un signe « <« ).
Dans cet exemple imaginaire et impossible, on voit que le vrai problème du XML, c’est justement qu’il propose deux façons d’exprimer la propriété d’un élément: attribut et sous-élément.
Cette particularité est non seulement inutile d’un point de vue structurel, mais elle rend le concept même du XML plutôt irrégulier. Un comble pour un langage qui se veut à la fois simple et très régulier.
Tout système régulier où une chose peut être exprimée de deux façons a forcément un problème.
Hors, les attributs et les sous-éléments sont justement la base du XML. Tout le reste de sa structure en découle ou s’y adapte.
La seule façon de résoudre le problème serait de supprimer les attributs, de permettre l’imbrication des balises, et, tant qu’on y est, de ne pas permettre de contenu/valeurs dans les éléments.
Toute structure se réduirait à un arbre.
Autant dire que ce serait tout simplement un autre langage que le XML.
Que faire ?
On peut très bien décider de continuer à utiliser un langage à syntaxe bancale, sans se poser de questions, par habitude ou par nécessité. Et continuer d’en subir les défauts: sémantique discutable, problème d’évolution des modèles, transcodage à revoir régulièrement, etc.
D’ailleurs on a de bonnes raisons de continuer: il existe une masse énorme de standards, de formats de fichiers, basés sur le XML, dans tous les domaines, et dans les principaux logiciels.
Et puis, les habitudes ont la vie dure. Et on peut se consoler en se disant qu’on a à notre disposition toute une infrastructure, des milliers de logiciels et de bibliothèques qui gèrent, éditent, vérifient, transcodent le code xml.
Ou bien on peut se mettre en quête d’autre chose, un méta-format de donnée plus intéressant.
Reste à savoir lequel, et s’il restera ou deviendra un standard sur lequel on peut miser.
Personnellement, j’ai beaucoup travaillé avec le XML, bien qu’avec une maitrise modeste de ses possibilités, et je sens que le passage à autre chose sera long et difficile (beaucoup de programmes à modifier, et d’habitudes à changer).
Par ailleurs, il existe un autre problème au XML, et en fait à tous les méta-langages textuels comme JSON, c’est leur incapacité à gérer efficacement de gros fichiers, surtout lorsqu’il faut y insérer ou y retirer des informations.
Beaucoup ont proposé des versions binaires de XML, aucune n’a l’air de devenir un standard reconnu.
D’ailleurs, à partir d’une certaine complexité et d’une certaine taille, les bases de données semblent incontournables.. et toujours aussi peu lisibles par le commun des mortels.