Pour installer un petit serveur Jabber (Prosody), j'ai eu à tripoter un
fichier de conf en xml. Je n'y connais pas grand chose, mais je me
demandais quel est l'intérêt d'utiliser ce format plutôt qu'un bête
fichier texte à éditer ? C'est une vraie question.
Par ailleurs, chaque fois que je cherche de la doc quand je veux faire
un truc un peu moins basique que d'habitude, je tombe sur le wiki
d'Ubuntu qui m'a bien aidé plus d'une fois. Je le trouve en fait assez
remarquable.
--
Olivier -- "On est comme tous les artistes, on croit à notre produit."
-+-groupe Début de Soirée-+-
Pour installer un petit serveur Jabber (Prosody), j'ai eu à tripoter un fichier de conf en xml. Je n'y connais pas grand chose, mais je me demandais quel est l'intérêt d'utiliser ce format plutôt qu'un bête fichier texte à éditer ? C'est une vraie question.
C'est étrange, parce que ayant également installé Prosody il y a deux semaines pour remplacer Ejabberd, je n'ai eu à éditer, ni vu, aucun fichier de configuration écrit en XML. Par contre, j'ai édité le fichier de configuration principal qui est lui en Lua, oui.
Mais ça n'a rien à voir. De quel fichiers parles-tu, par curiosité ?
Sinon, pour répondre à ta question, je ne vois aucun intérêt à utiliser XML pour de la configuration. Et, lorsque c'est possible ( ça a pour le moment toujours été le cas ), j'évite d'utiliser ces logiciels qui analysent leur configuration en XML.
Par ailleurs, chaque fois que je cherche de la doc quand je veux faire un truc un peu moins basique que d'habitude, je tombe sur le wiki d'Ubuntu qui m'a bien aidé plus d'une fois. Je le trouve en fait assez remarquable.
Et donc ? :-)
-- Vivien MOREAU
On 2010-10-17, olive wrote:
Pour installer un petit serveur Jabber (Prosody), j'ai eu à tripoter un
fichier de conf en xml. Je n'y connais pas grand chose, mais je me
demandais quel est l'intérêt d'utiliser ce format plutôt qu'un bête
fichier texte à éditer ? C'est une vraie question.
C'est étrange, parce que ayant également installé Prosody il y a deux
semaines pour remplacer Ejabberd, je n'ai eu à éditer, ni vu, aucun
fichier de configuration écrit en XML. Par contre, j'ai édité le fichier
de configuration principal qui est lui en Lua, oui.
Mais ça n'a rien à voir. De quel fichiers parles-tu, par curiosité ?
Sinon, pour répondre à ta question, je ne vois aucun intérêt à utiliser
XML pour de la configuration. Et, lorsque c'est possible ( ça a pour le
moment toujours été le cas ), j'évite d'utiliser ces logiciels qui
analysent leur configuration en XML.
Par ailleurs, chaque fois que je cherche de la doc quand je veux faire
un truc un peu moins basique que d'habitude, je tombe sur le wiki
d'Ubuntu qui m'a bien aidé plus d'une fois. Je le trouve en fait assez
remarquable.
Pour installer un petit serveur Jabber (Prosody), j'ai eu à tripoter un fichier de conf en xml. Je n'y connais pas grand chose, mais je me demandais quel est l'intérêt d'utiliser ce format plutôt qu'un bête fichier texte à éditer ? C'est une vraie question.
C'est étrange, parce que ayant également installé Prosody il y a deux semaines pour remplacer Ejabberd, je n'ai eu à éditer, ni vu, aucun fichier de configuration écrit en XML. Par contre, j'ai édité le fichier de configuration principal qui est lui en Lua, oui.
Mais ça n'a rien à voir. De quel fichiers parles-tu, par curiosité ?
Sinon, pour répondre à ta question, je ne vois aucun intérêt à utiliser XML pour de la configuration. Et, lorsque c'est possible ( ça a pour le moment toujours été le cas ), j'évite d'utiliser ces logiciels qui analysent leur configuration en XML.
Par ailleurs, chaque fois que je cherche de la doc quand je veux faire un truc un peu moins basique que d'habitude, je tombe sur le wiki d'Ubuntu qui m'a bien aidé plus d'une fois. Je le trouve en fait assez remarquable.
Et donc ? :-)
-- Vivien MOREAU
Nicolas George
olive , dans le message <i9f3km$16ud$, a écrit :
Pour installer un petit serveur Jabber (Prosody), j'ai eu à tripoter un fichier de conf en xml. Je n'y connais pas grand chose, mais je me demandais quel est l'intérêt d'utiliser ce format plutôt qu'un bête fichier texte à éditer ? C'est une vraie question.
L'avantage évident, c'est qu'il existe des bibliothèques fiables qui les lisent correctement. Ce n'est pas du tout évident si on veut avoir une gestion raisonnable des chaînes de caractères, y compris l'échappement des délimiteurs.
olive , dans le message <i9f3km$16ud$1@talisker.lacave.net>, a écrit :
Pour installer un petit serveur Jabber (Prosody), j'ai eu à tripoter un
fichier de conf en xml. Je n'y connais pas grand chose, mais je me
demandais quel est l'intérêt d'utiliser ce format plutôt qu'un bête
fichier texte à éditer ? C'est une vraie question.
L'avantage évident, c'est qu'il existe des bibliothèques fiables qui les
lisent correctement. Ce n'est pas du tout évident si on veut avoir une
gestion raisonnable des chaînes de caractères, y compris l'échappement des
délimiteurs.
Pour installer un petit serveur Jabber (Prosody), j'ai eu à tripoter un fichier de conf en xml. Je n'y connais pas grand chose, mais je me demandais quel est l'intérêt d'utiliser ce format plutôt qu'un bête fichier texte à éditer ? C'est une vraie question.
L'avantage évident, c'est qu'il existe des bibliothèques fiables qui les lisent correctement. Ce n'est pas du tout évident si on veut avoir une gestion raisonnable des chaînes de caractères, y compris l'échappement des délimiteurs.
JKB
Le 17 Oct 2010 17:56:56 GMT, Nicolas George <nicolas$ écrivait :
olive , dans le message <i9f3km$16ud$, a écrit :
Pour installer un petit serveur Jabber (Prosody), j'ai eu à tripoter un fichier de conf en xml. Je n'y connais pas grand chose, mais je me demandais quel est l'intérêt d'utiliser ce format plutôt qu'un bête fichier texte à éditer ? C'est une vraie question.
L'avantage évident, c'est qu'il existe des bibliothèques fiables qui les lisent correctement. Ce n'est pas du tout évident si on veut avoir une gestion raisonnable des chaînes de caractères, y compris l'échappement des délimiteurs.
Et qu'est-ce qui empêche de faire la même chose avec un fichier plat et lisible par un être humain normalement constitué ? D'ailleurs ces bibliothèques existaient il y a une quinzaine d'années et doivent toujours exister dans des systèmes libres.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le 17 Oct 2010 17:56:56 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :
olive , dans le message <i9f3km$16ud$1@talisker.lacave.net>, a écrit :
Pour installer un petit serveur Jabber (Prosody), j'ai eu à tripoter un
fichier de conf en xml. Je n'y connais pas grand chose, mais je me
demandais quel est l'intérêt d'utiliser ce format plutôt qu'un bête
fichier texte à éditer ? C'est une vraie question.
L'avantage évident, c'est qu'il existe des bibliothèques fiables qui les
lisent correctement. Ce n'est pas du tout évident si on veut avoir une
gestion raisonnable des chaînes de caractères, y compris l'échappement des
délimiteurs.
Et qu'est-ce qui empêche de faire la même chose avec un fichier plat
et lisible par un être humain normalement constitué ? D'ailleurs ces
bibliothèques existaient il y a une quinzaine d'années et doivent
toujours exister dans des systèmes libres.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le 17 Oct 2010 17:56:56 GMT, Nicolas George <nicolas$ écrivait :
olive , dans le message <i9f3km$16ud$, a écrit :
Pour installer un petit serveur Jabber (Prosody), j'ai eu à tripoter un fichier de conf en xml. Je n'y connais pas grand chose, mais je me demandais quel est l'intérêt d'utiliser ce format plutôt qu'un bête fichier texte à éditer ? C'est une vraie question.
L'avantage évident, c'est qu'il existe des bibliothèques fiables qui les lisent correctement. Ce n'est pas du tout évident si on veut avoir une gestion raisonnable des chaînes de caractères, y compris l'échappement des délimiteurs.
Et qu'est-ce qui empêche de faire la même chose avec un fichier plat et lisible par un être humain normalement constitué ? D'ailleurs ces bibliothèques existaient il y a une quinzaine d'années et doivent toujours exister dans des systèmes libres.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Aeris
JKB wrote:
Et qu'est-ce qui empêche de faire la même chose avec un fichier plat et lisible par un être humain normalement constitué ? D'ailleurs ces bibliothèques existaient il y a une quinzaine d'années et doivent toujours exister dans des systèmes libres.
Il est justement souvent très difficile de faire un langage lisible et en même temps facilement analysable sans erreur par un programme.
Un fichier plat pose énormément de problèmes, parmis lesquels ceux citer plus haut: gestion des échappements, délimiteurs de paramètres de configuration, gestion des paramètres multilignes, caractères spéciaux...
Sans parler qu'il est difficile de structurer un fichier plat, qui n'est rien de plus qu'une bouillie de lignes, à l'inverse de XML ou des autres langages structurés (JSON, YAML...) qui ordonnent et trient les informations.
JKB wrote:
Et qu'est-ce qui empêche de faire la même chose avec un fichier plat
et lisible par un être humain normalement constitué ? D'ailleurs ces
bibliothèques existaient il y a une quinzaine d'années et doivent
toujours exister dans des systèmes libres.
Il est justement souvent très difficile de faire un langage lisible et en
même temps facilement analysable sans erreur par un programme.
Un fichier plat pose énormément de problèmes, parmis lesquels ceux citer
plus haut: gestion des échappements, délimiteurs de paramètres de
configuration, gestion des paramètres multilignes, caractères spéciaux...
Sans parler qu'il est difficile de structurer un fichier plat, qui n'est
rien de plus qu'une bouillie de lignes, à l'inverse de XML ou des autres
langages structurés (JSON, YAML...) qui ordonnent et trient les
informations.
Et qu'est-ce qui empêche de faire la même chose avec un fichier plat et lisible par un être humain normalement constitué ? D'ailleurs ces bibliothèques existaient il y a une quinzaine d'années et doivent toujours exister dans des systèmes libres.
Il est justement souvent très difficile de faire un langage lisible et en même temps facilement analysable sans erreur par un programme.
Un fichier plat pose énormément de problèmes, parmis lesquels ceux citer plus haut: gestion des échappements, délimiteurs de paramètres de configuration, gestion des paramètres multilignes, caractères spéciaux...
Sans parler qu'il est difficile de structurer un fichier plat, qui n'est rien de plus qu'une bouillie de lignes, à l'inverse de XML ou des autres langages structurés (JSON, YAML...) qui ordonnent et trient les informations.
JKB
Le Sun, 17 Oct 2010 22:06:22 +0200, Aeris écrivait :
JKB wrote:
Et qu'est-ce qui empêche de faire la même chose avec un fichier plat et lisible par un être humain normalement constitué ? D'ailleurs ces bibliothèques existaient il y a une quinzaine d'années et doivent toujours exister dans des systèmes libres.
Il est justement souvent très difficile de faire un langage lisible et en même temps facilement analysable sans erreur par un programme.
Un fichier plat pose énormément de problèmes, parmis lesquels ceux citer plus haut: gestion des échappements, délimiteurs de paramètres de configuration, gestion des paramètres multilignes, caractères spéciaux...
Je ne vois pas pourquoi. J'ai écrit plusieurs 'parser' de fichiers autrement plus complexes qu'un bête fichier plat avec des caractères spéciaux. Il suffit de définir une syntaxe et de passer le truc dans une moulinette écrite une fois pour toute. En fait, je ne vois pas ce qui pose problème à un fichier texte et qui n'en poserait pas à un fichier XML (sauf que les routines pour XML ont été écrites et qu'il ne faut pas réinventer la roue et patati et patata !).
Un fichier XML, c'est une plaie dès qu'il devient complexe et qu'il faut le modifier à la main !
Sans parler qu'il est difficile de structurer un fichier plat, qui n'est rien de plus qu'une bouillie de lignes,
Mauvaise syntaxe, changer de syntaxe. Je peux te montrer des fichiers plats parfaitement structurés (comme il en existe d'autres qui sont illisibles).
à l'inverse de XML ou des autres langages structurés (JSON, YAML...) qui ordonnent et trient les informations.
Mouais. Pas convaincu.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Sun, 17 Oct 2010 22:06:22 +0200,
Aeris <aeris@imirhil.fr> écrivait :
JKB wrote:
Et qu'est-ce qui empêche de faire la même chose avec un fichier plat
et lisible par un être humain normalement constitué ? D'ailleurs ces
bibliothèques existaient il y a une quinzaine d'années et doivent
toujours exister dans des systèmes libres.
Il est justement souvent très difficile de faire un langage lisible et en
même temps facilement analysable sans erreur par un programme.
Un fichier plat pose énormément de problèmes, parmis lesquels ceux citer
plus haut: gestion des échappements, délimiteurs de paramètres de
configuration, gestion des paramètres multilignes, caractères spéciaux...
Je ne vois pas pourquoi. J'ai écrit plusieurs 'parser' de fichiers
autrement plus complexes qu'un bête fichier plat avec des caractères
spéciaux. Il suffit de définir une syntaxe et de passer le truc dans
une moulinette écrite une fois pour toute. En fait, je ne vois pas
ce qui pose problème à un fichier texte et qui n'en poserait pas à
un fichier XML (sauf que les routines pour XML ont été écrites et
qu'il ne faut pas réinventer la roue et patati et patata !).
Un fichier XML, c'est une plaie dès qu'il devient complexe et qu'il
faut le modifier à la main !
Sans parler qu'il est difficile de structurer un fichier plat, qui n'est
rien de plus qu'une bouillie de lignes,
Mauvaise syntaxe, changer de syntaxe. Je peux te montrer des
fichiers plats parfaitement structurés (comme il en existe d'autres
qui sont illisibles).
à l'inverse de XML ou des autres
langages structurés (JSON, YAML...) qui ordonnent et trient les
informations.
Mouais. Pas convaincu.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Sun, 17 Oct 2010 22:06:22 +0200, Aeris écrivait :
JKB wrote:
Et qu'est-ce qui empêche de faire la même chose avec un fichier plat et lisible par un être humain normalement constitué ? D'ailleurs ces bibliothèques existaient il y a une quinzaine d'années et doivent toujours exister dans des systèmes libres.
Il est justement souvent très difficile de faire un langage lisible et en même temps facilement analysable sans erreur par un programme.
Un fichier plat pose énormément de problèmes, parmis lesquels ceux citer plus haut: gestion des échappements, délimiteurs de paramètres de configuration, gestion des paramètres multilignes, caractères spéciaux...
Je ne vois pas pourquoi. J'ai écrit plusieurs 'parser' de fichiers autrement plus complexes qu'un bête fichier plat avec des caractères spéciaux. Il suffit de définir une syntaxe et de passer le truc dans une moulinette écrite une fois pour toute. En fait, je ne vois pas ce qui pose problème à un fichier texte et qui n'en poserait pas à un fichier XML (sauf que les routines pour XML ont été écrites et qu'il ne faut pas réinventer la roue et patati et patata !).
Un fichier XML, c'est une plaie dès qu'il devient complexe et qu'il faut le modifier à la main !
Sans parler qu'il est difficile de structurer un fichier plat, qui n'est rien de plus qu'une bouillie de lignes,
Mauvaise syntaxe, changer de syntaxe. Je peux te montrer des fichiers plats parfaitement structurés (comme il en existe d'autres qui sont illisibles).
à l'inverse de XML ou des autres langages structurés (JSON, YAML...) qui ordonnent et trient les informations.
Mouais. Pas convaincu.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Baton Rouge
On Mon, 18 Oct 2010 07:58:47 +0000 (UTC), JKB wrote:
Sans parler qu'il est difficile de structurer un fichier plat, qui n'est rien de plus qu'une bouillie de lignes,
Mauvaise syntaxe, changer de syntaxe. Je peux te montrer des fichiers plats parfaitement structurés
des exemples SVP, car j'aimerai trouver mon bonheur en moins lourd que le XML pour des data.
-- Travailler plus pour gagner plus pour quoi faire ? Pour finir par divorcer parce qu'on est pas souvent à la maison ou faire un malaise vagal et creuser le trou de la sécu ?
On Mon, 18 Oct 2010 07:58:47 +0000 (UTC), JKB
<jkb@koenigsberg.invalid> wrote:
Sans parler qu'il est difficile de structurer un fichier plat, qui n'est
rien de plus qu'une bouillie de lignes,
Mauvaise syntaxe, changer de syntaxe. Je peux te montrer des
fichiers plats parfaitement structurés
des exemples SVP, car j'aimerai trouver mon bonheur en moins lourd que
le XML pour des data.
--
Travailler plus pour gagner plus pour quoi faire ?
Pour finir par divorcer parce qu'on est pas souvent à la maison ou faire un malaise vagal et creuser le trou de la sécu ?
On Mon, 18 Oct 2010 07:58:47 +0000 (UTC), JKB wrote:
Sans parler qu'il est difficile de structurer un fichier plat, qui n'est rien de plus qu'une bouillie de lignes,
Mauvaise syntaxe, changer de syntaxe. Je peux te montrer des fichiers plats parfaitement structurés
des exemples SVP, car j'aimerai trouver mon bonheur en moins lourd que le XML pour des data.
-- Travailler plus pour gagner plus pour quoi faire ? Pour finir par divorcer parce qu'on est pas souvent à la maison ou faire un malaise vagal et creuser le trou de la sécu ?
Aeris
JKB wrote:
Un fichier plat pose énormément de problèmes, parmis lesquels ceux citer plus haut: gestion des échappements, délimiteurs de paramètres de configuration, gestion des paramètres multilignes, caractères spéciaux...
Je ne vois pas pourquoi. J'ai écrit plusieurs 'parser' de fichiers autrement plus complexes qu'un bête fichier plat avec des caractères spéciaux. Il suffit de définir une syntaxe et de passer le truc dans une moulinette écrite une fois pour toute. En fait, je ne vois pas ce qui pose problème à un fichier texte et qui n'en poserait pas à un fichier XML (sauf que les routines pour XML ont été écrites et qu'il ne faut pas réinventer la roue et patati et patata !).
Comme tu le dis, ça réinvente la roue, et encore qu'en partie. Ton parser maison aura toutes les chances d'être bien moins modulable et clair qu'un fichier XML qui contient les mêmes données (surtout que cf dernier point). Rajouter un niveau d'imbrication dans le XML a toutes les chances d'être rétrocompatible avec l'ancien fichier (les nouvelles balises seront ignorées), déplacer un contenu au travers de l'arbre ne cassera pas le fichier (les requètes xpath restent toujours valables). J'en doute beaucoup plus sur ton parser maison.
Un fichier XML, c'est une plaie dès qu'il devient complexe et qu'il faut le modifier à la main !
Tout comme un parser maison devient extrèmement plus compliqué à maintenir dès que la structure devient complexe, et encore pire la gueule du fichier final (et les bugs qui vont avec)
Surtout que sur le XML, il y a pléthores d'éditeurs XML qui valident en même temps ton fichier et te guide dans la saisie, avec par exemple de l'autocomplétion ou du WYSIWYG (comme l'excellent ExxEditor [1]).
Sans parler qu'il est difficile de structurer un fichier plat, qui n'est rien de plus qu'une bouillie de lignes,
Mauvaise syntaxe, changer de syntaxe. Je peux te montrer des fichiers plats parfaitement structurés (comme il en existe d'autres qui sont illisibles).
Un fichier plat structuré, j'appelle ça du XML (ou en tout cas à un XSLT près :)). Et certes, faire du XML illisible, c'est possible, mais je pense qu'on a largement moins de chance d'y parvenir qu'avec un langage maison.
Après si on veut du light, y'a d'autres langages que XML, JSON par exemple, le tout étant de rester dans les langages structurés et non pas plat.
Mais partir de 0 et redéfinir son propre format, parser et syntaxe, c'est non seulement inutile mais en plus fortement risqué (bug, évolutivité, maintenance, compréhension...).
à l'inverse de XML ou des autres langages structurés (JSON, YAML...) qui ordonnent et trient les informations.
Un fichier plat pose énormément de problèmes, parmis lesquels ceux citer
plus haut: gestion des échappements, délimiteurs de paramètres de
configuration, gestion des paramètres multilignes, caractères spéciaux...
Je ne vois pas pourquoi. J'ai écrit plusieurs 'parser' de fichiers
autrement plus complexes qu'un bête fichier plat avec des caractères
spéciaux. Il suffit de définir une syntaxe et de passer le truc dans
une moulinette écrite une fois pour toute. En fait, je ne vois pas
ce qui pose problème à un fichier texte et qui n'en poserait pas à
un fichier XML (sauf que les routines pour XML ont été écrites et
qu'il ne faut pas réinventer la roue et patati et patata !).
Comme tu le dis, ça réinvente la roue, et encore qu'en partie.
Ton parser maison aura toutes les chances d'être bien moins modulable et
clair qu'un fichier XML qui contient les mêmes données (surtout que cf
dernier point).
Rajouter un niveau d'imbrication dans le XML a toutes les chances d'être
rétrocompatible avec l'ancien fichier (les nouvelles balises seront
ignorées), déplacer un contenu au travers de l'arbre ne cassera pas le
fichier (les requètes xpath restent toujours valables). J'en doute beaucoup
plus sur ton parser maison.
Un fichier XML, c'est une plaie dès qu'il devient complexe et qu'il
faut le modifier à la main !
Tout comme un parser maison devient extrèmement plus compliqué à maintenir
dès que la structure devient complexe, et encore pire la gueule du fichier
final (et les bugs qui vont avec)
Surtout que sur le XML, il y a pléthores d'éditeurs XML qui valident en même
temps ton fichier et te guide dans la saisie, avec par exemple de
l'autocomplétion ou du WYSIWYG (comme l'excellent ExxEditor [1]).
Sans parler qu'il est difficile de structurer un fichier plat, qui n'est
rien de plus qu'une bouillie de lignes,
Mauvaise syntaxe, changer de syntaxe. Je peux te montrer des
fichiers plats parfaitement structurés (comme il en existe d'autres
qui sont illisibles).
Un fichier plat structuré, j'appelle ça du XML (ou en tout cas à un XSLT
près :)).
Et certes, faire du XML illisible, c'est possible, mais je pense qu'on a
largement moins de chance d'y parvenir qu'avec un langage maison.
Après si on veut du light, y'a d'autres langages que XML, JSON par exemple,
le tout étant de rester dans les langages structurés et non pas plat.
Mais partir de 0 et redéfinir son propre format, parser et syntaxe, c'est
non seulement inutile mais en plus fortement risqué (bug, évolutivité,
maintenance, compréhension...).
à l'inverse de XML ou des autres
langages structurés (JSON, YAML...) qui ordonnent et trient les
informations.
Un fichier plat pose énormément de problèmes, parmis lesquels ceux citer plus haut: gestion des échappements, délimiteurs de paramètres de configuration, gestion des paramètres multilignes, caractères spéciaux...
Je ne vois pas pourquoi. J'ai écrit plusieurs 'parser' de fichiers autrement plus complexes qu'un bête fichier plat avec des caractères spéciaux. Il suffit de définir une syntaxe et de passer le truc dans une moulinette écrite une fois pour toute. En fait, je ne vois pas ce qui pose problème à un fichier texte et qui n'en poserait pas à un fichier XML (sauf que les routines pour XML ont été écrites et qu'il ne faut pas réinventer la roue et patati et patata !).
Comme tu le dis, ça réinvente la roue, et encore qu'en partie. Ton parser maison aura toutes les chances d'être bien moins modulable et clair qu'un fichier XML qui contient les mêmes données (surtout que cf dernier point). Rajouter un niveau d'imbrication dans le XML a toutes les chances d'être rétrocompatible avec l'ancien fichier (les nouvelles balises seront ignorées), déplacer un contenu au travers de l'arbre ne cassera pas le fichier (les requètes xpath restent toujours valables). J'en doute beaucoup plus sur ton parser maison.
Un fichier XML, c'est une plaie dès qu'il devient complexe et qu'il faut le modifier à la main !
Tout comme un parser maison devient extrèmement plus compliqué à maintenir dès que la structure devient complexe, et encore pire la gueule du fichier final (et les bugs qui vont avec)
Surtout que sur le XML, il y a pléthores d'éditeurs XML qui valident en même temps ton fichier et te guide dans la saisie, avec par exemple de l'autocomplétion ou du WYSIWYG (comme l'excellent ExxEditor [1]).
Sans parler qu'il est difficile de structurer un fichier plat, qui n'est rien de plus qu'une bouillie de lignes,
Mauvaise syntaxe, changer de syntaxe. Je peux te montrer des fichiers plats parfaitement structurés (comme il en existe d'autres qui sont illisibles).
Un fichier plat structuré, j'appelle ça du XML (ou en tout cas à un XSLT près :)). Et certes, faire du XML illisible, c'est possible, mais je pense qu'on a largement moins de chance d'y parvenir qu'avec un langage maison.
Après si on veut du light, y'a d'autres langages que XML, JSON par exemple, le tout étant de rester dans les langages structurés et non pas plat.
Mais partir de 0 et redéfinir son propre format, parser et syntaxe, c'est non seulement inutile mais en plus fortement risqué (bug, évolutivité, maintenance, compréhension...).
à l'inverse de XML ou des autres langages structurés (JSON, YAML...) qui ordonnent et trient les informations.
