L’essence du XML : le problème qu’il résout n’est pas difficile et il ne le résout pas correctement

[Hinault Romaric]

L’essence du XML : le problème qu’il résout n’est pas difficile et il ne le résout pas correctement
qu'est-ce qui manque le plus au langage


Normalisé par le W3C, le langage XML (Extensible Markup Language) a été largement adopté comme format d’échange de données entre différents systèmes, plateformes et organisations.

Mais, le langage a quelques faiblesses qui font souvent l’objet de plusieurs discussions et de rejet par certains. « The Essence Of Xml », l’un des documents fondamentaux sur le langage écrit par Philip Wadler et Jérôme Siméon procède à une analyse de celui-ci.

Selon le document, les deux propriétés clés nécessaires pour n’importe quel format sont les suivants :

• self describing : le document XML devrait être suffisant pour obtenir les données sans ambigüité ;
• round tripping : la conversion de la représentation interne des données dans un logiciel (comme un objet à l’intérieur d’une application Java, des structures dans une solution C, des lignes d’une table Oracle, etc.) au format XML et vice-versa, devrait produire les mêmes données. En d’autres termes : data == DecodeFromXML(EncodeToXML(data)).

Pour les auteurs du document, un exemple de format de données avec ces deux propriétés est Lisp EssExpressions (expressions symboliques de la communauté de développeurs Lisp), et XML est loin d’implémenter correctement celles-ci.

Selon Walder et Siméon, l’essence du XML se résume simplement à : « le problème qu’il résout n’est pas difficile et il ne le résout pas bien ».


Source : The Essence Of Xml (au format PDF)


Et vous ?

Êtes-vous d’accord avec cette conclusion ?

Que pensez-vous du langage ? Qu'est-ce qui lui manque le plus ?

Quelle est l’essence du XML pour vous ?

[thelvin]

Ils ont raison. Personnellement j'utilise peu XML pour le cas d'utilisation qu'ils présentent. Il n'a pas ces défauts pour moi, et il résout mes problèmes presque aussi bien que possible. Mais je suis un extraterrestre.
Tout le monde utilise XML pour le cas d'utilisation qu'ils présentent, et il a effectivement les défauts montrés, qui gâchent tout.

Le vrai problème de XML c'est qu'il n'a pas de concurrent sérieux, qui copie sa syntaxe pour la lisibilité, qui soit bien intégré, mais qui soit dédié uniquement à ce pour quoi l'industrie s'en sert : des données organisées en séquence et en arbre. Un tel format pourrait auto-décrire les données de la manière présentée, ce qui résoudrait du même coup le round tripping.

[Xinu2010]

Envoyé par thelvin

Le vrai problème de XML c'est qu'il n'a pas de concurrent sérieux, qui copie sa syntaxe pour la lisibilité, qui soit bien intégré, mais qui soit dédié uniquement à ce pour quoi l'industrie s'en sert : des données organisées en séquence et en arbre. Un tel format pourrait auto-décrire les données de la manière présentée, ce qui résoudrait du même coup le round tripping.

Quid de json ?

[thelvin]

Envoyé par Xinu2010

Quid de json ?

Pas sérieux.

- Bien comme format d'échange, il est totalement nul pour tout ce qui est ressource un peu statique et qui doit être modifiée par des humains. XML est mal utilisé pour ça, mais JSON est juste risible.

- C'est moins important, mais il n'est pas lisible au format texte, du moins pas si on mêle tableaux et objets, ou si on va à une profondeur de quatre ou plus. D'ailleurs à cette profondeur, si on mêle objets et tableaux, même un visualiseur de JSON n'arrangera pas beaucoup les choses.

[dufoli]

Certes le xml est loin d'être parfait et est de plus très verbeux.
Je ne vois pas cela comme un langage mais comme un "format" permettant de représenter des données hiérarchisés.

Je ne vois pas beaucoup d'alternative a ce niveau là.

Pour la configuration avant on avait les fichiers ini et c'était 100 fois plus limité.
Pour la transmission de donnée hiérarchisés, le xml est un format bien plus structuré et lisible que les fichiers plats (texte longueur fixe ou avec séparateur) qui nécessitait un champ type pour séparer entête et ligne.

Bref, faut pas oublié d'où on vient...

Pour finir le JSON est la seul alternative que je connaisse et qui est utilisé à ma connaissance.
Beaucoup d'API REST proposent d'ailleurs le choix entre XML ou JSON.
XML est plus riche que JSON mais bien plus verbeux... Donc ça reste un choix en fonction de ce que l'on a a faire....

[kolodz]

Quand je survole le document en question et que je compare avec la réalité. Il y a trois choses qui me viennent en tête :

• Un XML qui as une DTD à jours, c'est déjà beaucoup demander.
• Un service qui vérifie qu'on lui donne des XML valide par rapport à sa DTD, c'est encore plus rare.
• Croire que le type, qui décide comment est structuré un XML, connait la théorie des langages, relève du fantasme.

Le problème ne vient pas du langage, mais de son utilisation.
Pour ce qui est du fond, je pense que je lirai cette publication plus tard.

Quelle est l’essence du XML pour vous ?

Format de représentation trans-langage, trans-application neutre par rapport à celle-ci.
Lisible par un humain.
Souple.

Que pensez-vous du langage ? Qu'est-ce qui lui manque le plus ?

Des utilisateurs sérieux.

Êtes-vous d’accord avec cette conclusion ?

D'un point de vue théorique, je ne sais pas. D'un point de vue pratique, le langage fonctionne et on a la plus part du temps *:

data == DecodeFromXML(EncodeToXML(data))

Donc, j'avoue que la conclusion n'est pas intéressante.

Cordialement,
Patrick Kolodziejczy.

* : Quand ce n'est pas le cas, un humain peut lire les données et retrouver les données d'origine.

[abriotde]

Quid de json ?
Pas sérieux.

Pour moi le défaut n°1 de XML est sa lourdeur. Je lui préfère le CSV quand ce c'est possible ou le json, le fichier properties et sinon la base de donnée Mysql qui s'exporte très bien (vers une autre du même type).

Pour stocké 1Ko octet de donné on obtient souvent 5Ko, que l'on peut compressé ce qui ne résout que le problème de la taille (On passe à 2Ko) car après le chargement est très très long (Décompression en plus d'un parsing complexe à développer et qui pour simplifier est entièrement stocké en mémoire). Json résout tous ces problème (Il est un peu moins lisible (et encore)) il est deplus dans certains langages (Javascript - PHP et d'autres) possible de faire data==decodeJson(EncodeJson(data)) et d'un point de vue parsing, comme le fichier est moins volumineux il est de facto plus vite lu.

Mais surtout pour envoyer certaines données le csv est ce qu'il y a de plus rapide à chargé. On le charge ligne par ligne, il ne prends donc pas d'espace mémoire, on peut même stocké un gros fichier directement et efficacement en base (MySQL au moins)

Dire que le XML peut tout stocker est une abération tout comme dire qu'il y a un langage pour tout faire. Il faut s'adapter aux besoins.

[tralloc]

XML pour moi est un langage très intéressant, je m'en sert pour des importations/exportations de données principalement, ou pour de la config.

Lire qu'on peut utiliser du CSV à la place me fait doucement rire, le CSV est beaucoup moins puissant puisqu'il n'est pas arborescent, autrement dit ce n'est pas comparable. Mais il est vrais que les exportateurs de bases de données par exemple produisent un XML qui pourrait ressembler à du CSV, donc inintéressants, et que pour avoir quelque chose de correct il faut en créer soi même la structure.

Le problème soulevé du format principalement pour des nombres et des caractères spéciaux sur l'encodage/décodage du XML est réel, mais c'est toujours contournable, il suffit de bien prévoir ses programmes et voir quel type de données on va avoir, comment vont-elles être écrites, à partir de là on peut tout faire, ça demande du travail OK.

Pour le "Self describing" : je ne comprend pas, je pense que c'est un langage tellement souple qu'on peut en faire ce qu'on en veut, tant qu'on sait ce qu'on fait, on peut bien si on le souhaite incorporer des langages de description.

Au niveau des DTD je pense qu'on oublie le XMLSchema qui est plus facile à aborder à mon sens, je trouve ça très lourd et je ne l'utilise que pour des langages XML spécifiques (xslt, xsl-fo), je n'en produit pas moi même ça ne sert à rien dans le cas d'une utilisation "pour soi-même".
J'aurais beaucoup plus de reproches à faire au XSLT qu'au XML... mais ce n'est pas le sujet.

En ce qui concerne le JSON je pense que c'est un concurrent intéressant, mais que je connais peu.

[rambc]

Envoyé par thelvin

- Bien comme format d'échange, il est totalement nul pour tout ce qui est ressource un peu statique et qui doit être modifiée par des humains. XML est mal utilisé pour ça, mais JSON est juste risible.

Un exemple ?

Envoyé par thelvin

- C'est moins important, mais il n'est pas lisible au format texte, du moins pas si on mêle tableaux et objets, ou si on va à une profondeur de quatre ou plus. D'ailleurs à cette profondeur, si on mêle objets et tableaux, même un visualiseur de JSON n'arrangera pas beaucoup les choses.

Il est bien connu que XML est très facile à lire...

[_skip]

Je suis d'accord avec kolodz sur le fond, surtout sur l'aspect des utilisateurs sérieux. Mon entreprise demande un fichier XML aux clients, tout est mis à disposition pour bien faire : un schéma xsd, un service de validation en ligne et pourtant 80% des utilisateurs (majoritairement des développeurs web) nous sortent un fichier mal formé au premier essai.

Les erreurs type sont les suivantes :
- Mauvais encodage des &
- Utilisation d'entité html dans le contenu
- UTF-8 dans l'entête alors que ce c'est du ISO8859.
- Non respect des séquence d'apparition

Le problème étant que plein de gens se contentent d'écrire du
string += "<element>" + value + </element>
sans penser que ça leur sauterait à la figure, car un fichier xml avec une dizaine d'éléments, ça paraît très simple à fabriquer or c'est un format exigeant.

Enfin ceci mis à part, tout n'est pas rose côté XML. Si je reprend les arguments.

self describing : le document XML devrait être suffisant pour obtenir les données sans ambigüité ;

Je suis d'accord avec eux, c'est un gros problème lorsqu'on travaille avec des flux externes d'autres entreprises. Normalement on se dit qu'on doit pouvoir à partir d'un échantillon pouvoir fabriquer un parser. C'est le cas, sauf qu'au fil des jours on finit toujours par tomber sur le truc qu'on pouvait pas deviner.
Du style

• Ah flûte, je savais pas que l'élément catégory était facultatif
• Ah flûte, je savais pas que lorsqu'il n'y avait pas de prix on mettait N/A comme valeur
• Ah tiens, cet élément est présent mais vide (""), ça veut dire null?

Et il faut qu'après 2-3 semaines sans soucis on ait un gros plantage de l'importation parce que ce qu'on a pas pu imaginer arrive.
Les outils pour pallier à ça sont les schémas. Manque de pot ils exigent de voir dans le fichier final leurs préfixes sur lesquels tous les parseurs avec lesquels j'ai travaillés sont impitoyables, ce sont des fichiers externes et franchement, ils sont souvent juste 10x trop complexes pour ce qu'on voudrait leur faire faire.

Les schémas me donnent l'impression d'être parti d'une très bonne idée puis d'avoir été poussés à l'extrême, avec plein de choses pas croyables comme les groupes de substitution et du pseudo héritage machin truc. Alors que pour 90% des échanges de fichiers, tout ce qu'on aurait voulu c'est les minOccurs et maxOccurs avec le type de donnée.

round tripping : la conversion de la représentation interne des données dans un logiciel (comme un objet à l’intérieur d’une application Java, des structures dans une solution C, des lignes d’une table Oracle, etc.) au format XML et vice-versa, devrait produire les mêmes données. En d’autres termes : data == DecodeFromXML(EncodeToXML(data)).

Là aussi, car il y a plein de façons de représenter les données.
Pour les types simples, cela peut être

Code :

<product id="12">

Ou alors

Code :

1
2
3
<product>
<id>12<id>
</product>

Pour les collections :

Code :

1
2
3
4
<product>
<category>Computer</category>
<category>Hardware</category>
</product>

Ou alors

Code :

1
2
3
4
5
6
7
8
<product>
 <categories>
    <category>Computer</category>
    <category>Hardware</category>
 </categories>
</product>
</product>

En fait c'est plutôt dommage qu'on n'ait pas choisi de se cantonner à une représentation standard.

Plus subjectivement

XML permet beaucoup de chose, peut être trop,
par exemple ceci :

<hello>
bon<hi>salut</hi>jour
</hello>

cela rend les API de lecture séquentielle style SAX merdiques parce que franchement tout et n'importe quoi peut arriver n'importe quand.
Je pense que le XML pourrait être simplifié, ou une déclinaison de ce format rétro-compatible pourrait exister.

Les contraintes de cette déclinaison pourraient être les suivantes :

• Pas d'attributs
• Obligation d'élément de groupe pour les collection
• premier élément optionnel serait <schema> avec une description des types et des contraintes d'apparition sous forme [x,y] des éléments
• deuxième élément serait <data> avec les données

Les avantages seraient les suivants :

• Les API de lecture et d'écriture seraient simples comme bonjour. Un noeud, une valeur ou une collection.
• La validation serait 100 fois moins compliquée à décrire et à implémenter de façon automatique à la lecture que dans le cas d'un schéma
• La porte serait ouverte à la génération automatique de classes pour la lecture

En gros ce serait une façon simple de répondre à un problème très courant, très commun qui rend XML pénible là où ce n'est vraiment pas nécessaire.
On aurait des arbres simples, elements-only, très lisibles et validables sans sortir le bazooka.

Parfois je me demande même s'il ne faudrait pas écrire une spec, un exemple d'API puis le proposer.

[el_slapper]

Il y a plein de manières de représenter les données, d'un format purement utilitaire(le fichier plat à positions fixes), à un format totalement descriptif(ceux qui ont moddé les jeux paradox, genre Europa Universalis, sauront de quoi je parle).

Un format totalement utilitaire est hyper-facile à coder, et très complexe à manipuler à la main(sauf si on a un éditeur dédié). Un format totalement descriptif est le mieux possible pour la modification manuelle, mais est fatalement casse-tête à coder(on est à la limite d'un compilateur).

XML, c'est entre les deux : ça essaye d'être facilement manipulable informatiquement ET à la main. Fatalement, il y a des surprises. C'est lié à la nature même du XML. Ce qui est une force d'un coté est une faiblesse de l'autre. Ca n'est pas un mauvais système, mais il faut en accepter les limites : il est moyen partout.

[Bktero]

Ce papier a 10 ans et la fameuse phrase n'est pas la conclusion du papier mais son introduction. Est-ce que cela voudrait dire que depuis 10 ans, on sait que XML n'est pas bon mais qu'aucun nouveau format ou version améliorée de XML n'est sorti ?

J'ai assez peu utilisé XML dans ma vie, pour des choses assez simple comme des fichiers de configurations. On peut ainsi facilement vérifier grâce au schéma XSD que le fichier est valide et que l'utilisateur n'a pas mis n'importe quoi. C'est bien plus simple qu'avec un fichier plat. Je le trouve assez pratique pour de nombreuses raisons évoquées par kolodz, avec qui je partage aussi les constats, et je rejoins par la même _skip et notamment son premier paragraphe.

[Freem]

Envoyé par dufoli

Pour la configuration avant on avait les fichiers ini et c'était 100 fois plus limité.

Marrant ça...
Parce que sur ma machine, la configuration est entièrement en fichiers textes classiques, plus simples même que le format INI.
Pourtant, je n'ai rien à reprocher niveau souplesse de configuration, et je n'ai que louages pour la simplicité de changer la config... On peut même utiliser des logiciels de contrôle de version !

Franchement, XML pour de la configuration, c'est ridicule, parce que ton fichier de configuration deviens (comparé à du texte brut):
_ lourd à lire par l'homme
_ très ardu/long à modifier par l'homme
_ lourd en place sur le disque dur
_ lourd à parser pour la machine

XML pour de la configuration, ça sert à fabriquer des bloatwares.

Envoyé par dufoli

Pour la transmission de donnée hiérarchisés, le xml est un format bien plus structuré et lisible que les fichiers plats (texte longeur fixe ou avec séparateur) qui necessitait un champ type pour séparer entete et ligne.

Sinon, pour la transmission de données sur une même machine, avec le même endianness, le binaire, avec un format correctement défini - chose qui me semble nécessaire, de documenter ce que l'on génère, que ce soit avec XML, JSON, IFF ou n'importe quoi d'autre - , ça marche pas trop mal.
Bon, certes, transmettre les choses en dehors des réseau, ce n'est plus trop à la mode.

Via les réseaux, là, ok, XML à un intérêt. D'ailleurs, c'est peut-être pour ça que son ancêtre SGML est aussi l'ancêtre du HTML, utilisé massivement sur le web.

De tous les usages que je connaît du XML, le seul qui me semble valide c'est la transmission de donnée via un réseau, avec les problème d'endianness que cela comporte.
XML Règle ce problème, étant donné qu'il s'agit de texte, encodé sur 1 octet. D'ailleurs, il peut même être encodé sur 7 bits, ce qui permet une forme de compression, à condition que l'on accepte d'utiliser l'encodage ASCII au lieu d'UTF8 ou autre.
Cet usage me semble très pertinent, cependant il semble que JSON soit tout aussi puissant de ce point de vue, voire plus, à ce que j'ai pu lire à leurs sujets respectifs (principalement wikipédia et mon propre cerveau, d'ailleurs, pour éviter les trolls de blog).

Envoyé par dufoli

Bref, faut pas oublié d'ou on vient...

Pour finir le JSON est la seul alternative que je connaissent et qui est utilisé a ma connaisance.
Beaucoup d'API REST propose d'ailleur le choix entre XML ou JSON.
XML est plus riche que JSON mais bien plus verbeux... Donc ca reste un choix en fonction de ce que l'on a a faire....

Il ne faut surtout pas oublier que certaines solutions du passé ont été supprimées car on les a supposées trop faibles, hors, ce n'était que le développeur qui était trop faible dans nombre de cas:
_ trop faible pour écrire une doc correcte
_ trop faible pour suivre rigoureusement une procédure

Envoyé par kolodz

Quand je survole le document en question et que je compare avec la réalité. Il y a trois choses qui me viennent en tête :

• Un XML qui as une DTD à jours, c'est déjà beaucoup demander.
• Un service qui vérifie qu'on lui donne des XML valide par rapport à sa DTD, c'est encore plus rare.
• Croire que le type, qui décide comment est structuré un XML, connait la théorie des langages, relève du fantasme.

Le problème ne vient pas du langage, mais de son utilisation.

Je n'aurai pas pu mieux dire.
Utiliser XML pour ce pour quoi il est fait EST pertinent.
Utiliser XML pour sauvegarder un document word où une configuration, puis compresser le fichier pour gagner de la place ne l'est pas.


Pour ceux qui vont m'objecter que dans un fichier de configuration plat, on ne peux pas avoir de structure en arbre... J'ai une chose à dire.
Un système de fichier, ça ne comporte pas que des fichiers, mais aussi des dossiers.
Hors, le système dossier/fichier, est une structure arborescente. S'il est vraiment nécessaire d'avoir une structure en arbre pour une configuration, alors utilisez le système de fichier.

• C'est portable (chaque langage sait gérer les systèmes de fichiers, excepté C++ mais C++ peut utiliser boost::filesystem qui marche très bien),
• efficace (pas de parsing à la con, ni de compression),
• économe en place,
• permet de manipuler la configuration avec de vulgaires scripts shell/batch/powershell (ou même en ligne de commande),
• utilisable avec un outil de contrôle de versions,
• et en plus, ce n'est plus vous qui ferez le boulot, mais l'OS.

Si le fait d'avoir une arborescence à copier pour filer la conf à quelqu'un vous gêne, qu'a cela ne tienne, il existe le format .tar => 0 compression donc rapide à lire/écrire, et ça transforme votre arborescence en fichier unique.
Effet secondaire, le fichier .tar sera même encore plus petit que le dossier racine de la configuration! (Ben oui, on se passe de la notion de blocs)

[laerne]

Envoyé par Freem

Pour ceux qui vont m'objecter que dans un fichier de configuration plat, on ne peux pas avoir de structure en arbre... J'ai une chose à dire.
Un système de fichier, ça ne comporte pas que des fichiers, mais aussi des dossiers.
Hors, le système dossier/fichier, est une structure arborescente. S'il est vraiment nécessaire d'avoir une structure en arbre pour une configuration, alors utilisez le système de fichier.

• C'est portable (chaque langage sait gérer les systèmes de fichiers, excepté C++ mais C++ peut utiliser boost::filesystem qui marche très bien),
• efficace (pas de parsing à la con, ni de compression),
• économe en place,
• permet de manipuler la configuration avec de vulgaires scripts shell/batch/powershell (ou même en ligne de commande),
• utilisable avec un outil de contrôle de versions,
• et en plus, ce n'est plus vous qui ferez le boulot, mais l'OS.

Si le fait d'avoir une arborescence à copier pour filer la conf à quelqu'un vous gêne, qu'a cela ne tienne, il existe le format .tar => 0 compression donc rapide à lire/écrire, et ça transforme votre arborescence en fichier unique.
Effet secondaire, le fichier .tar sera même encore plus petit que le dossier racine de la configuration! (Ben oui, on se passe de la notion de blocs)

Utiliser un fichier pour chaque nœud de l'arborescence, c'est certainement pas économe en mémoire. Autant directement tout enregistrer dans un tar.

Moi pour la configuration je préfère utilisé un parseur tout fait et prévu pour, comme libconfig (http://www.hyperrealm.com/libconfig/)
(Chercher "configuration file library", il y en a des tonnes !)

[_skip]

Bon faut quand même pas tirer loin le bébé avec l'eau du bain

Envoyé par Freem

Franchement, XML pour de la configuration, c'est ridicule, parce que ton fichier de configuration deviens (comparé à du texte brut):
_ lourd à lire par l'homme
_ très ardu/long à modifier par l'homme
_ lourd en place sur le disque dur
_ lourd à parser pour la machine

XML pour de la configuration, ça sert à fabriquer des bloatwares.

- Lourd à lire par l'homme, non, regarde un fichier de config de filezilla par exemple, c'est pas du tout dur à comprendre.
- Long à modifier, je vois pas en quoi changer une valeur en XML est plus dur que modifier une entrée dans un fichier texte.
- Lourd en place, sachant que souvent, qu'il fasse 1 octet ou 4096 il occupera peut être bien la même place. Puis est-ce vraiment l'argument de poids dans une machine ou 1To de disque est devenu la norme?
- Lourd à parser... Ca c'est vrai, mais est-ce significatif sachant qu'un fichier de configuration est généralement suffisamment petit et lu et écrit d'une traite?

Envoyé par Freem

XML Règle ce problème, étant donné qu'il s'agit de texte, encodé sur 1 octet. D'ailleurs, il peut même être encodé sur 7 bits, ce qui permet une forme de compression, à condition que l'on accepte d'utiliser l'encodage ASCII au lieu d'UTF8 ou autre.

Malheureusement, cette condition est souvent bien trop restrictive de nos jours où on parle que d'internationalisation. Là j'opterai plus pour une solution style protocol buffer.

Pour ceux qui vont m'objecter que dans un fichier de configuration plat, on ne peux pas avoir de structure en arbre... J'ai une chose à dire.
Un système de fichier, ça ne comporte pas que des fichiers, mais aussi des dossiers.

Hors, le système dossier/fichier, est une structure arborescente. S'il est vraiment nécessaire d'avoir une structure en arbre pour une configuration, alors utilisez le système de fichier.

Lourdeur, lenteur, difficulté à lire, difficulté à modifier, plein de possibles erreurs IO à gérer, pleins d'arbre de répertoire à explorer en depth first, gestion d'erreur et tout ça. Ca a juste tous les problèmes que tu as mentionnés au début de ton post dont certains en x10.

J'aurai mieux compris si tu avais cité un truc comme le format utilisé par Xorg dans ses xorg.conf.

[Freem]

Envoyé par _skip

- Lourd à lire par l'homme, non, regarde un fichier de config de filezilla par exemple, c'est pas du tout dur à comprendre.
- Long à modifier, je vois pas en quoi changer une valeur en XML est plus dur que modifier une entrée dans un fichier texte.
- Lourd en place, sachant que souvent, qu'il fasse 1 octet ou 4096 il occupera peut être bien la même place. Puis est-ce vraiment l'argument de poids dans une machine ou 1To de disque est devenu la norme?
- Lourd à parser... Ca c'est vrai, mais est-ce significatif sachant qu'un fichier de configuration est généralement suffisamment petit et lu et écrit d'une traite?

Tu parles de filezilla.xml?
Parce que, la, franchement... Allez, je le quote:

Envoyé par filezilla.xml

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<FileZilla3>
<Settings>
<Setting name="Use Pasv mode">1</Setting>
<Setting name="Limit local ports">0</Setting>
<Setting name="Limit ports low">6000</Setting>
<Setting name="Limit ports high">7000</Setting>
[...]
<Setting name="Disable update check">0</Setting>
<LastServer>
<Host>xxx.xxx.xxx.xxx</Host>
<Port>xx</Port>
<Protocol>0</Protocol>
<Type>0</Type>
<User>xxxxxx</User>
<Pass> </Pass>
<Logontype>1</Logontype>
<TimezoneOffset>0</TimezoneOffset>
<PasvMode>MODE_DEFAULT</PasvMode>
<MaximumMultipleConnections>0</MaximumMultipleConnections>
<EncodingType>Auto</EncodingType>
<BypassProxy>0</BypassProxy>
</LastServer>
</Settings>
</FileZilla3>

Pas dur à lire, non. Mais quel est l'intérêt de XML ici? Un ini classique aurait été plus adapté, amha, pour une liste de clé/valeurs, avec une seule section ...
Par contre, lourd à modifier... ça, oui. Il est plus rapide de taper "<MaximumMultipleConnections>0</MaximumMultipleConnections>" ou "MaximumMultipleConnections=0"?
Évidemment, je suppose qu'il existe des éditeurs spécialisés dans la modifications de fichiers XML... mais bon, quel intérêt dans le fichier ci-dessus?
Autre point, qui est arrivé à un collègue grand fanatique de l'XML: l'évolutivité. Ton fichier XML quand il faut faire évoluer les arborescences parce que le programme à changé, c'est assez pénible, d'autant qu'il avait un truc plus ou mois dynamique (en même temps, je n'ai jamais compris pourquoi il utilisais XML dans son cas, une configuration de scripts T-SQL, mais peu importe).

Lourd en place, je te l'accorde, de nos jours ça ne veux plus dire grand chose.
Par contre, je crois sincèrement que je pleurerai si sur le linux de mon netbook, tout le répertoire /etc ne contenait que des fichiers XML.
Une erreur de choix sur une application peut passer inaperçue, mais sur un système entier... pas vraiment.

Envoyé par _skip

Malheureusement, cette condition est souvent bien trop restrictive de nos jours où on parle que d'internationalisation. Là j'opterai plus pour une solution style protocol buffer.

Je ne vois pas ce que tu entends par protocol buffer?

Envoyé par _skip

Lourdeur, lenteur, difficulté à lire, difficulté à modifier, plein de possibles erreurs IO à gérer, pleins d'arbre de répertoire à explorer en depth first, gestion d'erreur et tout ça. Ca a juste tous les problèmes que tu as mentionnés au début de ton post dont certains en x10.

Les erreurs d'IO seront de toute façon présentes tant qu'on interagira avec des fichiers. La différence étant que, la, il est possible de ne pas perdre toute la conf pour une seule erreur d'IO.

La lenteur, c'est vrai, vu que les accès disques sont lents et du coup si les fichiers sont éparpillés sur le disque, la tête bouge énormément. Merci de m'avoir rappelé ce point: sur une installation d'OS sur une seule partition, ce serait un sacré problème.
Sur ce point XML gagne à l'échelle d'un programme unique, puisque n'étant qu'un fichier unique il sera statistiquement moins éparpillé. Cela dis, le problème ne se pose plus si le système de fichier est réservé à la conf, non? (et si on doit parler de machines modernes, il semblerait que ssd est à l'honneur pour les disques systèmes, et qu'il supprime ces ennuyeux problèmes de fragmentation)
Cependant... a l'échelle d'un système entier, XML perd, puisqu'il augmente beaucoup plus la fragmentation de façon naturelle: chaque modification de configuration risque d'engendrer une scission du fichier. Et si le système ne comprend que du XML en guise de configuration... je pense que ça ralentira très vite la vitesse.
Certes, certains systèmes de fichiers ont une faible fragmentation, mais elle existe malgré tout. (avec les extX, il suffit de voir quand il fait une vérif automatique tous les N montages: il affiche les blocs contigus, et je suis persuadé qu'il en profite pour dé-fragmenter...)

Difficulté à lire/modifier... "cd truc;bidulepad machin" puis modifier la valeur en question? Pour déplacer un arbre, une simple commande de déplacement règle le souci.

Plein d'arbres... effectivement, ce ne serait pas malin d'utiliser un tel système pour un outil qui requiert de nombreux arbre (autrement dit, pour un fichier destiné à l'échange, type word pour reprendre mon exemple).
Mais jusqu'a présent, j'ai toujours réussi à avoir des fichiers de configuration de taille réduite. Sûrement parce que j'aime spécialiser mes outils et que la conf en deviens du coup souvent triviale (quitte à les appeler ensuite via un super-outil pour pas que ça se voie qu'ils sont présent).
Cela dis, je sais que parfois on a pas le choix... malgré tout, que XML soit la meilleure solution m'intrigue vraiment? Je veux bien qu'on m'indique un cas ou ça saute aux yeux que c'est le meilleur, pour voir.
Je me ferai un plaisir d'en discuter, et peut-être de changer mon avis sur XML au passage.

Et tu as cité 2 fois la gestion d'erreurs a moins que tu ne parlais des erreurs internes de la config, et dans ce cas... ok, mais les lib xml n'ont-elles donc pas de gestion d'erreur? J'ai du mal a y croire.
Ce n'est pas parce que l'on manipule des fichiers de texte "simples" qu'on ne doit pas utiliser de librairies non plus.
Et il en existe, au moins en C++: boost::serialization, boost::program_option permettent de s'occuper respectivement des fichiers d'échange et des fichiers de config (pas encore testé pour le 2nd, cela dis, juste lu la doc vite fait). S'il en existe en C++, je doute fort qu'il n'y en ait pas en JAVA ou .NET...

Envoyé par _skip

J'aurai mieux compris si tu avais cité un truc comme le format utilisé par Xorg dans ses xorg.conf.

Ca, ça me rappelle ceci: http://xkcd.com/963/
Je suis plutôt content du fait que xorg détecte automatiquement la meilleure configuration, sans fichier de conf, sur mes machines. Je me souviens d'avoir tenté de mettre le nez dans ce fameux xorg.conf à mes débuts sur la debian stable précédente...

Si je résume ce post, XML est plus léger en termes d'accès disque et risque moins d'erreurs d'IO que ce que j'ai indiqué, mais à la première erreur d'IO il pète entièrement (et puis, j'ai perdu l'habitude des fichiers corrompus... ça fait très longtemps que ça m'est arrivé, y compris sous windows). A côté de ça, je pense qu'un système de fichier dédié à la configuration réduit considérablement le problème des accès disques multiples et de la fragmentation du système.

Pour ce qui est des sauvegardes de données, c'est évident que ce système de dossiers est mauvais: je ne pensais pas que quelqu'un envisagerais ça une seule seconde, mais j'aurai dû être plus clair.
De ce point de vue, je trouve que boost::serialization offre une solution intéressante pour C++. Je pense que les autres langages ont leur propres systèmes de sérialisation qui permettent de générer un format sûrement moins difficile à parser et plus léger que XML.
Voire même de laisser le choix à l'utilisateur... (comme boost qui offre plusieurs options, dont le texte brut, le binaire, et XML, mais il est à noter que XML implique une augmentation du nombre de lignes de code. Toutes sont portables...)
Au final, je trouve aussi que lire à l'oeil un fichier de données exportées... ce n'est pas nécessairement une bonne chose. Si on peut lire, on peut modifier. Et si on peut modifier, certains vont le faire et tout péter. Après, qui est-ce qui doit réparer?

[tontonnux]

Et que pense-vous de Yaml ?

[_skip]

Envoyé par Freem

Tu parles de filezilla.xml?
Parce que, la, franchement... Allez, je le quote:

C'était peut être pas le meilleur exemple, cependant les arguments tiennent, c'est pas dur à modifier. Maintenant je pensais plutôt au fichier qui contient les définitions de tes serveurs enregistrés. Càd qui peut contenir N groupes d'options (url, username, type auth, etc...)

Et là encore tu vas me dire que tu peux t'en sortir avec des sections, et c'est vrai.

Par contre, je crois sincèrement que je pleurerai si sur le linux de mon netbook, tout le répertoire /etc ne contenait que des fichiers XML.
Une erreur de choix sur une application peut passer inaperçue, mais sur un système entier... pas vraiment.

Je ne milite pas en ce sens, je suis d'ailleurs le premier à utiliser des fichiers .properties chaque fois que cela est possible. Car ça se traduit par un simple ensemble de tuples Clé-valeur et ça se parse comme d'un rien.
Cependant, le problème de ces notations c'est lorsque tu as des collections et des sous-collections de propriété, ça devient fastidieux et tu ressens le besoin d'une structure hiérarchisée.

Je ne vois pas ce que tu entends par protocol buffer?

Je pensais à ceci
http://code.google.com/p/protobuf/

Cela peut résoudre la plupart des problèmes que tu as mentionnés pour les échanges de données sous format binaires. En maintenant la plupart des avantages du binaire, en gardant une bonne partie de l'interopérabilité + la prise en charge automatique du format des messages. Je le citais car je pensais que c'était une meilleure approche que d'aller jusqu'à passer par du XML en pur ASCII.
Si tu connaissais pas, jette un oeil, c'est un compromis intéressant.

Les erreurs d'IO seront de toute façon présentes tant qu'on interagira avec des fichiers. La différence étant que, la, il est possible de ne pas perdre toute la conf pour une seule erreur d'IO.

Dans le cas de ton application qui persiste sa config, il est probable que tu choisisses de détruire totalement une arborescence pour la recréer plutôt que d'analyser la différence entre l'ancienne et l'actuelle (ce qui dans les 2 cas te demandera 10x plus de code que de sérialiser dans un seul fichier).
Et là si tu crashes au milieu ou si tu rencontres un problème de droit sur un répertoire, t'es mort. Dans le cas d'un fichier unique, il y a quelque chose de très simple, écrire dans un fichier temporaire puis ensuite renommer le fichier vers sa destination finale (quasiment 100% safe).

Cela dis, je sais que parfois on a pas le choix... malgré tout, que XML soit la meilleure solution m'intrigue vraiment? Je veux bien qu'on m'indique un cas ou ça saute aux yeux que c'est le meilleur, pour voir.
Je me ferai un plaisir d'en discuter, et peut-être de changer mon avis sur XML au passage.

Personne peut te demander ça. Comme j'ai décrit dans le pavé plus haut, il y a des flaws évidents, et lire et écrire un arbre XML avec validation et tout ça demande beaucoup de code qu'on aurait pu/du simplifier énormément. Je disais juste que t'y allait un peu fort en disant que c'était dans tous les cas une mauvaise idée pour enregistrer de la configuration (ou par extension, des états).
Je peux en revanche te dire de jeter un oeil du côté des outils de génération de code. Du style mappers objet relationnel, ou il y a plein de schémas, tables, de colonnes, de connexions et que tout ce qui est généré comme classes pour ce petit monde peut être customisé (override des noms, des types etc...), un fichier XML pour configurer ce genre d'outil ou de multiples références internes peuvent exister, c'est encore pas le pire.

Il y a aussi les cas de l'échange de données, lorsque lesdites données passent très mal en CSV (genre il faudrait extraire une fois en dry-run pour voir combien de colonne il faut avant d'être en mesure de générer le fichier).

Et tu as cité 2 fois la gestion d'erreurs a moins que tu ne parlais des erreurs internes de la config, et dans ce cas... ok, mais les lib xml n'ont-elles donc pas de gestion d'erreur? J'ai du mal a y croire.

Je parlais surtout par rapport à ton idée d'utiliser l'arborescence du système de fichier, pour les raisons citées plus haut et la difficulté à recouvrer d'un état d'échec au beau milieu de l'écriture.

Ca, ça me rappelle ceci: http://xkcd.com/963/
Je suis plutôt content du fait que xorg détecte automatiquement la meilleure configuration, sans fichier de conf, sur mes machines. Je me souviens d'avoir tenté de mettre le nez dans ce fameux xorg.conf à mes débuts sur la debian stable précédente...

J'ai aussi déjà démarré sur un écran noir après avoir joué avec ce fichier. Ce n'est pas le format qui fait que ce soit de la daube à éditer pour le coup. Je voulais juste parler d'un format proche du texte, qui n'est pas du XML et qui permet la représentation de données non-flat (c'est à dire les sections avec leurs collections de propriétés et des références) et qui ne tombe pas dans cette logique de multi-répertoire à outrance.

[GrandFather]

XML, c'est certes un langage de balise d'apparence presque trivial, mais c'est surtout une nébuleuse d'outils, d'API, de frameworks, de langages développés spécifiquement pour lui. Les possibilités sont phénoménales, toute la difficulté revient à en faire l'usage le plus optimal possible ; mais la tentation du « marteau en or », l'outil prétendument universel qu'on met à toutes les sauces - jusqu'à l'indigestion - n'existe pas que pour XML, mais pour tous les outils de développement à fort potentiel. Enfin, ce débat est un peu dépassé... Depuis 13 ans que la spécification existe, on a depuis fait un peu le tour de ce qui était intéressant ou non de traiter avec XML.

Ainsi, XML n'apporte pas vraiment grand chose dans le domaine des fichiers de configuration, alors qu'il est devenu un standard pour les transferts de données entre systèmes (où il a fait ses preuves). Il y a d'autres domaines d'application où XML est incontournable, et qui n'ont pas encore été abordés dans ce fil, ce sont ceux de la bureautique et de la gestion documentaire. L'accession de ODF et OpenXML au rang de normes a vraiment changé la donne.

[polymorphisme]

Bonjour,

- Bien comme format d'échange, il est totalement nul pour tout ce qui est ressource un peu statique et qui doit être modifiée par des humains. XML est mal utilisé pour ça, mais JSON est juste risible.

J'en pense pas moins, JSON est une abréviation de XML qui peut s'avérer pratique effectivement pour un échange de données et JSON cela s'arrête là.

Préférer un format CSV au format XML ou l'inverse pour des raisons personnelles de goût me laisse sans voix Il est clair que CSV n'a pas les mêmes spécificités que XML. Chacun de ces formats ne peut juste être utiliser pour leurs spécificités propres.

Et il est clair qu'il existe des domaines tel que la gestion documentaire où le XML est roi.
Comment créer un dictionnaire, un thésaurus, un livre sans XML ? Je souhaite bon courage à ceux qui voudraient s'en passer.

Enfin, la bestiole data == DecodeFromXML(EncodeToXML(data))
me fait penser à Infoset, qui est le standard traitant de l'information extraite d'un fichier XML et il me semble que cela fonctionne plutôt bien.

Je crois que XML à apporter de nombreuses améliorations dans divers domaines
et que cela va continuer.