Licence CC 0

JSON, YAML, TOML, XML,... Ou comment se compliquer la vie

Dernière mise à jour :
Auteur :
Catégories :
Temps de lecture estimé : 10 minutes

Bonjour à tous,

Ces dernières années, j’ai pu constater une net augmentation de l’emploi de formats de ficher textuels complexes. Alors, l’existence et l’emploi de tels formats n’est certainement pas chose nouvelle, il suffit de penser au XML et a son dérivé le plus usité, le XHTML, pour s’en convaincre.

En revanche, l’emploi de ce type de fichier semble devenue à présent quasi systématique, alors pourtant que ces formats sont loin d’être les plus simples aussi bien à lire que parser.

Afin d’illustrer mon propos, je vous propose de prendre trois exemples d’utilisation qui peuvent parfaitement être remplacé par l’emploi du format INI (j’ai choisi ce format parce qu’il est connu et un minimum structuré, cela étant ce n’est bien entendu pas le seul possible) :

  1. L’utilisation de YAML par Ansible ;
  2. L’utilisation du XML par Openbox ;
  3. L’utilisation du JSON par Zeste de Savoir.

Ansible

Ansible est un logiciel qui permet d’effectuer des actions à distances sur plusieurs machines à la fois. Cela est réalisé via des connexions en SSH et l’exécution d’instructions en Python. Chaque action à effectuer est décrite à l’aide d’une entrée rédigée en YAML.

L’exemple ci-dessous spécifie que les fichiers etc/apt/sources.list et etc/apt/preferences présents sur la machine source (donc celle qui exécute Ansible) doivent être déplacées vers la ou les machines de destinations aux emplacements /etc/apt/sources.list et /etc/apt/preferences avec les permissions indiquées.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
- name: Copy configuration files
  copy:
    src: '{{ item }}'
    dest: '/{{ item }}'
    owner: root
    group: root
    mode: 0644
  with_items:
    - etc/apt/sources.list
    - etc/apt/preferences

Or, dans ce cas ci, le format YAML fait-il sens ? Est-il nécessaire de se farcir une syntaxe exigeante en termes d’éléments (chaînes, dictionnaires, listes, etc.), d’indentation (si vous ne mettez pas le bon nombre d’espaces, c’est mort) et de parsing ? Eh bien, pas vraiment, non.

Techniquement, la même chose est possible avec le format INI, sans s’ennuyer avec toutes cette lourdeur syntaxique.

1
2
3
4
5
6
7
8
9
[Copy configuration files]
MODULE=copy
SRC={{ item }}
DEST=/{{ item }}
OWNER=root
GROUP=root
MODE=0644
WITH_ITEMS=etc/apt/sources.list
WITH_ITEMS=etc/apt/preferences

Avait-on besoin du YAML ? Visiblement, non.

Openbox

Openbox est un gestionnaire de fenêtre minimaliste disponible sous GNU/Linux et *BSD, offrant de nombreuses possibilités. Il est souvent utilisé pour concevoir des environnements graphiques peu gourmand en ressources. Parmi ses fichiers de configuration, on retrouve un certain rc.xml qui permet de régler différents aspects, des raccourcis claviers au positionnement par défaut de certaines fenêtres.

Voici un court exemple de ce fichier en rapport avec configuration des raccourcis claviers.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
  <keyboard>
    <chainQuitKey>C-g</chainQuitKey>
    <keybind key="W-d">
      <action name="ToggleShowDesktop"/>
    </keybind>
    <keybind key="A-F4">
      <action name="Close"/>
    </keybind>
    <keybind key="W-m">
      <action name="ShowMenu">
        <menu>root-menu</menu>
      </action>
    </keybind>
    <keybind key="A-Tab">
      <action name="NextWindow">
        <finalactions>
          <action name="Focus"/>
          <action name="Raise"/>
          <action name="Unshade"/>
        </finalactions>
      </action>
    </keybind>
    <keybind key="W-e">
      <action name="Execute">
        <command>pcmanfm</command>
      </action>
    </keybind> 
    <keybind key="W-t">
      <action name="Execute">
        <command>urxvt -bg black -fg grey +sb -fn 'xft:Monospace:pixelsize=16'</command>
      </action>
    </keybind>
    <keybind key="XF86AudioRaiseVolume">
      <action name="Execute">
        <command>amixer set Master 1%+</command>
      </action>
    </keybind>
    <keybind key="XF86AudioLowerVolume">
      <action name="Execute">
        <command>amixer set Master 1%-</command>
      </action>
    </keybind>
  </keyboard>

Et voici le même, au format INI.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
[keybind]
KEY=W-d
ACTION=ToggleShowDesktop

[keybind]
KEY=A-F4
ACTION=Close

[keybind]
KEY=W-m
ACTION=ShowMenu
MENU=root-menu

[keybind]
KEY=A-Tab
ACTION=NextWindow
FINALACTION=Focus
FINALACTION=Raise
FINALACTION=Unshade

[keybind]
KEY=W-e
ACTION=Execute
COMMAND=pcmanfm

[keybind]
KEY=W-t
ACTION=Execute
COMMAND=urxvt -bg black -fg grey +sb -fn 'xft:Monospace:pixelsize=16'

[keybind]
KEY=XF86AudioRaiseVolume
ACTION=Execute
COMMAND=amixer set Master 1%+

[keybind]
KEY=XF86AudioLowerVolume
ACTION=Execute
COMMAND=amixer set Master 1%-

À nouveau, le XML était-il indispensable ou particulièrement nécessaire pour un tel fichier de configuration ? J’en doute.

Zeste de Savoir

Zeste de Savoir emploie le format JSON afin de représenter la structure d’un contenu via le fichier manifest.json que vous retrouvez à la racine des archives ZIP de vos contenus. Par exemple, voici le fichier manifest.json produit pour ce billet.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
{
    "licence":"CC 0",
    "slug":"json-yaml-toml-xml-ou-comment-se-compliquer-la-vie",
    "introduction":"introduction.md",
    "title":"JSON, YAML, TOML, XML,... Ou comment se compliquer la vie",
    "description":"",
    "version":2,
    "children":[
        {
            "slug":"ansible",
            "text":"ansible.md",
            "title":"Ansible",
            "object":"extract"
        },
        {
            "slug":"openbox",
            "text":"openbox.md",
            "title":"Openbox",
            "object":"extract"
        },
        {
            "slug":"zeste-de-savoir",
            "text":"zeste-de-savoir.md",
            "title":"Zeste de Savoir",
            "object":"extract"
        }
    ],
    "type":"OPINION",
    "conclusion":"conclusion.md",
    "object":"container"
}

Ce format si agréable à lire était-il indispenable ? Probablement pas. :p

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
[json-yaml-toml-xml-ou-comment-se-compliquer-la-vie]
LICENCE=CC-0
INTRODUCTION=introduction.md
TITLE=JSON, YAML, TOML, XML,... Ou comment se compliquer la vie
DESCRIPTION=
VERSION=2
TYPE=OPINION
CONCLUSION=conclusion.md

[json-yaml-toml-xml-ou-comment-se-compliquer-la-vie:ansible]
TEXT=ansible.md
TITLE=Ansible

[json-yaml-toml-xml-ou-comment-se-compliquer-la-vie:openbox]
TEXT=openbox.md
TITLE=Openbox

[json-yaml-toml-xml-ou-comment-se-compliquer-la-vie:zeste-de-savoir]
TEXT=zeste-de-savoir.md
TITLE=Zeste de Savoir

Alors, mon propos ici n’est pas de réaliser une ode au format INI, ni de prétendre que tous les choix techniques présentés ici sont foncièrement mauvais et encore moins d’affirmer connaître la complexité inhérente de chacun de ces trois projets.

Toutefois, trop souvent, le choix du format semble réalisé « par défaut », c’est-à-dire qu’on prend ce qui semble être le plus souvent utilisé ou dans le vent et pour le reste, « osef ». Or, foncièrement, les formats complexes que sont le JSON, le YAML, le TOML ou le XML ne sont finalement véritablement nécessaires que dans de rares cas où il est assez difficile de faire autrement (par exemple, le choix du XHTML pour les pages web n’est a priori pas déconnant, sans que cela soit parfait évidemment).

Donc, s’il vous plaît amis développeurs : quand vous devez stocker des données, choisissez un format textuel simple, le parsing se fera sans difficultés et votre vie et celle de vos utilisateurs n’en sera que meilleure. :ange:

11 commentaires

En fait, je vois deux situations :

  1. Un humain est censé lire et modifier le fichier, et là, en effet la question d’utiliser un format textuel simple est importante.
  2. Aucun humain n’est censé lire et modifier le fichier, et là on s’en fout complètement de savoir si le fichier est lisible ou non. Le choix doit donc se faire sur des critères techniques.

Or, le cas n°2 est beaucoup, beaucoup plus fréquent. Et le JSON, le YAML, le XML et d’autres ont des avantages techniques majeurs :

  • Ils sont normalisés : quelque soit le langage de programmation utilisé, un fichier bien formé sera correctement lu si un parseur non buggé est disponible.
  • Ils sont structurés1, et donc permettent donc un mapping direct avec des structures techniques.
  • JSON et XML ont des parseurs extrêmement performants dans à peu près tous les langages imaginables.
  • JSON a des parseurs natifs et efficace pour les applications web et mobile (mais pas XML2).
  • XML, avec un parseur bien conçu (donc pas tous), peut être lu et traité sans avoir à monter tout le fichier ou toute sa représentation en mémoire.
  • XML arrive avec tout un ecosystème qui peut être bien pratique selon ce qu’on veut faire (XSLT, XPath, validation…).
  • Et sans doute plein d’autres trucs auxquels je ne pense pas.

J’ajoute enfin que ce n’est pas parce qu’un format est simple qu’il est facile et efficace à parser. Le plus bel exemple pour ça est CSV : ça a l’air tellement simple qu’on est tenté de le parser « à la main » (sans utiliser de bibliothèque dédiée). Jusqu’au moment où on découvre que 1. le format n’est pas normalisé correctement (rien que le séparateur ,, ou ; si de fichier est issu d’un Excel français) et 2. dès que les champs contiennent des " ou des sauts de ligne (oui, c’est possible, et si vous lisez le fichier ligne par ligne, sans traitement spécifique vous êtes mort), ça devient galère.


  1. Nativement et correctement structurés, pas de bricolage comme dans [json-yaml-toml-xml-ou-comment-se-compliquer-la-vie:ansible]

  2. Curieusement, au moins jusqu’en 2016, il était compliqué de faire lire du XML à un appareil iOS sans sortir toute une artillerie de libs improbables… je n’ai pas d’information plus récente. 

Salut,

Mes exemples se basent effectivement sur des cas où un utilisateur est amené à modifier le fichier à la main (même si c’est plus discutable pour le manifest.json, une intervention manuelle peut être requise) et où la lisibilité et la simplicité du format est dès lors importante. Toutefois, à supposer même que le fichier ne soit pas amené à être modifié à la main, le choix d’un format simple reste de mon point de vue important.

  • Ils sont normalisés : quel que soit le langage de programmation utilisé, un fichier bien formé sera correctement lu si un parseur non buggé est disponible.
SpaceFox

La normalisation du langage est surtout importante dans le cas où il y a un souci d’interopérabilité important (à nouveau, le cas du XHTML est probablement le plus emblématique puisque ce dernier doit pouvoir être interprété de la même manière par tous les navigateurs, entre autres). Or, c’est rarement le cas pour pas mal de logiciels, les trois exemples que je donne ici ne sont pas concernés par une telle problématique.

  • Ils sont structurés[^structure], et donc permettent donc un mapping direct avec des structures techniques.
SpaceFox

Le format INI ne prévoit effectivement pas par défaut de hiérarchie entre les sections, je l’ai donc un peu amendé pour que cela soit le cas. Cela étant dit, je l’ai choisi pour l’exemple, d’autres solutions sont possibles.

  • JSON et XML ont des parseurs extrêmement performants dans à peu près tous les langages imaginables.
SpaceFox

De ce côté, vu leur usage massif, j’espère bien qu’ils ont des parsers performants. ;)
Cela étant, que ces formats complexes disposent ou non de parsers performants, le parsing d’un format simple sera toujours moins gourmand en ressources (sauf s’il est codé avec les pieds, mais c’est pas la question).

J’ajoute enfin que ce n’est pas parce qu’un format est simple qu’il est facile et efficace à parser. Le plus bel exemple pour ça est CSV : ça a l’air tellement simple qu’on est tenté de le parser « à la main » (sans utiliser de bibliothèque dédiée). Jusqu’au moment où on découvre que 1. le format n’est pas normalisé correctement (rien que le séparateur ,, ou ; si de fichier est issu d’un Excel français) et 2. dès que les champs contiennent des " ou des sauts de ligne (oui, c’est possible, et si vous lisez le fichier ligne par ligne, sans traitement spécifique vous êtes mort), ça devient galère.

SpaceFox

Mon propos dans ce billet est avant tout de dénoncer l’emploi de formats complexes comme fichiers de configuration ou de stockage de données alors que le plus souvent cela n’est pas nécessaire et inutilement complexe. Le choix d’un langage normalisé ne doit à mon sens se faire que si le programme se doit d’être interopérable. Si ce n’est pas le cas, alors ce sont pour moi ces deux points qui doivent être réunis :

  1. Si l’utilisateur doit le modifier, qu’il puisse le faire sans se prendre la tête ;
  2. Le parsing doit être simple et efficace.
+0 -0

Mon propos dans ce billet est avant tout de dénoncer l’emploi de formats complexes comme fichiers de configuration ou de stockage de données alors que le plus souvent cela n’est pas nécessaire et inutilement complexe.

alors petite expérience personnelle:

Au boulot on a une plateforme "legacy" qui est en java et on utilise au besoin soit le format de base de java soit le format ini pour faire les configurations.

En face on a les "nouveaux" programmes qui sont en go et qui utilisent toml pour les confs statics et json+s3 (pour le stockage) pour les configuration qui sont éditable par les clients.

Pour les confs statiques voici ce que le toml nous a apporté :

  • pouvoir intégrer très facilement la configuration d’un objet issu d’une lib : comme le format est structuré hiérarchiquement il suffit de dire "dans ma conf principale j’ai une section qui correspond aux paramètres de la lib" et ça marche
  • pour valider les types aussi c’est 10 fois moins verbeux : si tu fais pas gaffe tu fais tout le temps des fautes de frappe qui changent le type et un format structuré fait que tu n’as pas à faire la vérif à la main : la désérialisation va fail et tu vas pouvoir corriger rapidement

D’ailleurs c’est encore plus intéressant avec json car on peut ajouter des schemas json qui nous permettent de faire des validations encore plus poussées, un peu comme pour le xml d’ailleurs.

Au début j’étais comme toi : du xml pour confiugrer c’est relou, du json pour stocker c’est imbittable. Et puis je suis arrivé dans le "monde réel" (trade mark, copyrighté jusqu’en 9999 etc etc.) où il y a des bugs dans les données d’entrées, des erreurs humaines, disques réseau qui lâchent en pleine écriture et avoir un moyen de repérer des erreurs, parfois de les corriger, souvent de rollback facilement est devenu une nécessité que les fichiers ini n’ont pas. Et pour avoir eu un pb bien grave sur les confs statiques qu’on a réparé à la main en urgence je peux te dire que ça nous a bien fait chier quand le paramètre de conf qui pilote une tâche qui a lieu tous les deux jours a fait foirer ladite tâche 36h après la remise en route, va-t-en savoir ce qui bug quand c’est comme ça.

+0 -0

Personnellement j’utilise le XML au boulot car il a des avantages que les autres formats n’ont pas (dont l’INI, que j’aime pourtant bien aussi) :

  • On peut avec un fichier XSD à côté s’assurer que le fichier d’entrée est correcte et ne possède pas de cas bizarres qui n’a pas été prévus. Idéal pour un système dont l’entrée est fondamental pour ne pas charger une connerie (et donc faire n’importe quoi avec).
  • C’est très facile de vérifier si le XML est à priori entier ou pas. Juste en vérifiant si la balise mère a été fermée à la fin, on peut être sûr que l’enregistrement a été fait entièrement (je travaille en embarqués, si l’alimentation coupe pendant l’enregistrement d’un fichier, c’est bien de le voir très vite).
  • Le XML est verbeux mais la syntaxe de base (donc pas de namespace par exemple) est simple sans avoir besoin trop d’XP. Un technicien qui n’en a jamais vu peut rapidement modifier ou remplir un fichier XML avec quelques indications, le JSON et YALM demandent selon moi plus d’efforts (car moins verbeux et moins intuitifs).
  • Le XML permet différents moyens d’être parsés, tous avec leurs avantages et inconvénients (en terme de ressources nécessaires, ou de complexité de code derrière) : XPath, DOM ou séquentiel. C’est une belle souplesse.

Amateur de Logiciel Libre et de la distribution GNU/Linux Fedora. #JeSuisArius

+2 -0

Le format INI ne prévoit effectivement pas par défaut de hiérarchie entre les sections, je l’ai donc un peu amendé pour que cela soit le cas. Cela étant dit, je l’ai choisi pour l’exemple, d’autres solutions sont possibles.

Du coup, t’as juste recréé TOML, le typage en moins. Si il y a une telle pléthore de format texte, c’est bien parce qu’il y a des besoins variables. INI est une vraie plaie à parser parce qu’outre l’absence de standard, il n’y a aucun typage des données. Si tu as un champ bidule=12, c’est la chaîne "12" ou bien le nombre 12 ? Du coup, pour les fichiers de config minimaux à destination des humains, j’aime bien TOML. La syntaxe pour les sous sections est un peu lourde, mais sur une structure qui reste simple avec peu de niveaux, ça le fait bien.

I don’t mind that you think slowly, but I do mind that you are publishing faster. — W. Pauli

+3 -0
  • On peut avec un fichier XSD à côté s’assurer que le fichier d’entrée est correcte et ne possède pas de cas bizarres qui n’a pas été prévu. Idéal pour un système dont l’entrée est fondamentale pour ne pas charger une connerie (et donc faire n’importe quoi avec).
Renault

Vraie question ici (et idem pour la suivante) : ce n’est pas dupliquer le boulot de procéder de la sorte en plus d’augmenter le risque d’erreur ? Je veux dire, finalement tu dois parser un fichier XSD et un fichier XML, en ayant à chaque fois un risque d’entrées invalides et/ou d’erreur de parsing.

  • C’est très facile de vérifier si le XML est à priori entier ou pas. Juste en vérifiant si la balise mère a été fermée à la fin, on peut être sûr que l’enregistrement a été fait entièrement (je travaille en embarqués, si l’alimentation coupe pendant l’enregistrement d’un fichier, c’est bien de le voir très vite).
Renault

Le résultat ne serait pas le même en ajoutant par exemple une section finale oligatoire ?

1
2
[End]
STATUS=SUCCESS
  • pouvoir intégrer très facilement la configuration d’un objet issu d’une lib : comme le format est structuré hiérarchiquement il suffit de dire "dans ma conf principale j’ai une section qui correspond aux paramètres de la lib" et ça marche
artragis

Tu veux dire un mapping plus ou moins direct entre une structure de données et le format textuel, genre comme ceci ?

1
2
3
4
struct array {
        size_t size;
        int data[*];
};
1
2
3
array:
  - size: 6
  - data: [ 0, 1, 2, 3, 4, 5 ]
  • pour valider les types aussi c’est 10 fois moins verbeux : si tu fais pas gaffe tu fais tout le temps des fautes de frappe qui changent le type et un format structuré fait que tu n’as pas à faire la vérif à la main : la désérialisation va fail et tu vas pouvoir corriger rapidement
artragis

Mmm… Est-ce que tu peux détailler ce point s’il te plaît ? En quoi la validation des types est-elle moins verbeuse en JSON ou YAML par exemple ?

D’ailleurs c’est encore plus intéressant avec json car on peut ajouter des schemas json qui nous permettent de faire des validations encore plus poussées, un peu comme pour le xml d’ailleurs.

artragis

Même vraie question qu’à Renault ici : ce n’est pas dupliquer le boulot que d’employer un fichier de schéma et un fichier de données sachant que les deux doivent être analysés et validés ?

Au début j’étais comme toi : du xml pour configurer c’est relou, du json pour stocker c’est imbittable. Et puis je suis arrivé dans le "monde réel" (trade mark, copyrighté jusqu’en 9999 etc etc.) où il y a des bugs dans les données d’entrées, des erreurs humaines, disques réseau qui lâchent en pleine écriture et avoir un moyen de repérer des erreurs, parfois de les corriger, souvent de rollback facilement est devenu une nécessité que les fichiers ini n’ont pas. Et pour avoir eu un pb bien grave sur les confs statiques qu’on a réparé à la main en urgence je peux te dire que ça nous a bien fait chier quand le paramètre de conf qui pilote une tâche qui a lieu tous les deux jours a fait foirer ladite tâche 36h après la remise en route, va-t-en savoir ce qui bug quand c’est comme ça.

artragis

Je t’avoue que je n’ai pas suivi ce passage. ^^"

Du coup, t’as juste recréé TOML, le typage en moins.

adri1

Heu… Le TOML est quand même nettement plus évolué que ça. ^^"
Par ailleurs, ce que j’emploie reste de l’INI, j’emploie juste une extension pour désigner des sous-sections, ce qui est parfois employé avec ce format sauf que cela prend plutôt la forme [A.B.C] ou [A\B\C]. Enfin, comme je l’ai dit, j’ai pris l’INI en exemple parce qu’il est connu, mais d’autres choix sont parfaitement possibles.

Si tu as un champ bidule=12, c’est la chaîne "12" ou bien le nombre 12 ?

adri1

A priori, c’est à toi de le déterminer et de vérifier tes entrées en conséquence.

Édité par Taurre

+0 -0

Tu veux dire un mapping plus ou moins direct entre une structure de données et le format textuel, genre comme ceci ?

c’est ça;

Mmm… Est-ce que tu peux détailler ce point s’il te plaît ? En quoi la validation des types est-elle moins verbeuse en JSON ou YAML par exemple ?

Tout dépendra du langage ou de la lib (typiquement tu as pas de validation de type en python) mais si tu tentes de désérialiser un JSON pour le mapper dans un objet bien typé, l’immense majorité des libs t’enverra une erreur en te disant quel field est mauvais.

Avec un simple ini, il faut faire soit même les checks (donc une ligne par field). En plus comme il y a un typage faible "32" est sensé être identique à 32 et donc même avec une bonne lib tu auras des pbs in fine car les conversions c’est pas une science exacte.

Je t’avoue que je n’ai pas suivi ce passage. ^^"

pour faire simple

  • avec une donnée structurée, on découvre rapidement les erreurs (humaines, logicielles, materielles)
  • avec une donnée structurée, tu peux corriger l’erreur d’une manière bien plus robuste que les sempiternelles "valeur par défaut"

Vraie question ici (et idem pour la suivante) : ce n’est pas dupliquer le boulot de procéder de la sorte en plus d’augmenter le risque d’erreur ? Je veux dire, finalement tu dois parser un fichier XSD et un fichier XML, en ayant à chaque fois un risque d’entrées invalides et/ou d’erreur de parsing.

je dirais que non : le schéma de validation est packageable, et testable unitairement, tu auras donc la possibilité d’être certain de son fonctionnement. Le fichier de conf, lui, il est ouvert à tout le monde. l’utilisateur est sensé le modifier alors que le fichier de validation ne doit pas être touché, c’est un fichier de dev.

+0 -0

Vraie question ici (et idem pour la suivante) : ce n’est pas dupliquer le boulot de procéder de la sorte en plus d’augmenter le risque d’erreur ? Je veux dire, finalement tu dois parser un fichier XSD et un fichier XML, en ayant à chaque fois un risque d’entrées invalides et/ou d’erreur de parsing.

Pour moi, c’est exactement comme dire qu’un test duplique le boulot. ;)

C’est vrai dans l’exécution, mais en pratique ça réduit les problèmes et les rend compréhensible et éventuellement tracable.

Édité par unidan

+0 -0

Vraie question ici (et idem pour la suivante) : ce n’est pas dupliquer le boulot de procéder de la sorte en plus d’augmenter le risque d’erreur ? Je veux dire, finalement tu dois parser un fichier XSD et un fichier XML, en ayant à chaque fois un risque d’entrées invalides et/ou d’erreur de parsing.

En général le parsing (surtout du XSD) est généré de bout en bout par une bibliothèque. Le risque d’erreurs est faible. L’intérêt du XSD est qu’il est en général écrit une fois lors de la conception du programme. Le XML peut changer par le problème lui même (s’il doit sauvegarder des données) ou par l’utilisateur s’il doit configurer un truc. Le fichier XML est donc peu fiable en terme de validité contrairement au XSD qui est normalement écrit et testé une fois pour toute. Cela apporte une garantie assez forte que le fichier XML en entrée ne sera utilisée que s’il est valide car l’erreur peut arriver très facilement en cas d’écriture qui merde (coupure de courant au mauvais moment) ou un utilisateur qui n’a pas fait gaffe.

Le résultat ne serait pas le même en ajoutant par exemple une section finale oligatoire ?

On pourrait mais ce n’est pas une méthode standard non plus et l’absence de format de validation est un problème. Car il est intéressant d’avoir la garantie que le champs config/hardware/name contienne un nom valide (donc Produit 1, 2 ou 3 mais pas 4 ou 5 qui n’existent pas forcément) ou que le champs config/harwarde/temp/range/min soit forcément plus petit que l’équivalent max et que la plage de valeur pertinente c’est entre 150 et 250.

Bien sûr, avec un ini tu peux le faire, mais c’est manuel, avec risque d’erreur, et si cela change demain tu dois changer le programme et le recompiler (et refaire des tests) alors qu’avec le XSD tu gagnes beaucoup de temps avec des garanties de fonctionnement fortes.

Et l’avantage du XML est que si demain le langage du projet change pour X ou Y raisons, l’adaptation sera rapide. Si tu as tout fait à la main, tu dois tout refaire aussi. D’ailleurs sur mon projet actuel le périphérique et un serveur doivent synchroniser le fichier de configuration du périphérique. Avec le même XSD nous pouvons vérifier des deux côtés que le fichier est correct. Et si changement il y a à faire dedans, changer le XSD commun est suffisant. Avec ton fichier INI il faudrait changer beaucoup plus de code des deux côtés avec risque d’erreurs à la clé.

Je n’ai rien contre le format INI, que j’affectionne pour nombres d’usages, mais le XML ou JSON ont leur intérêt et des cas d’usages aussi. Il n’y a rien d’universellement parfait. Le tout est de choisir convenablement en fonction de ses besoins.

Amateur de Logiciel Libre et de la distribution GNU/Linux Fedora. #JeSuisArius

+3 -0

A priori, c’est à toi de le déterminer et de vérifier tes entrées en conséquence.

C’est… exactement le problème que je soulève. Tu peux pas écrire un parser de fichier INI sans savoir par quoi il va être consommé. Inversement, tu ne peux pas te reposer sur un parser existant quand tu écris ton code. Et enfin, pour l’UX c’est pas terrible si t’es obligé de vérifier dans la doc le type des entrées.

I don’t mind that you think slowly, but I do mind that you are publishing faster. — W. Pauli

+0 -0

Merci pour vos précisions. :)

Je vois donc l’idée du XSD et des schémas en général : déléguer la vérification des données à une bibliothèque dédiées, en partant du principe qu’il y a peu de risque d’erreurs (en tous les cas moins que dans les autres cas) le schéma étant rédigé durant le développement et la bibliothèque tierce maintenue par une équipe (normalement) compétente.

C’est… exactement le problème que je soulève.

adri1

Ah ! Ok, au temps pour moi. ^^"

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte