D'après wikipédia, L'objectif initial de XML est de faciliter l'échange automatisé de contenus complexes (arbres, texte riche...) entre systèmes d'informations hétérogènes (interopérabilité) .
Même pour ça, c'est mauvais, qui n'a pas eu à faire des transformations XSL enchaînées avec les "&" qui se transforment ou pas en "&" aux mauvais endroits me lance la première pierre.
j'ai beaucoup utilisé XML dans sa période "hype" au boulot entre 2000 et 2005, et en vrac les inconvénients majeurs :
1) un fichier xml ne peut pas se traiter en flux à cause de la balise "racine" (il faut construire l'arbre en mémoire, ou comptabiliser les noeuds avec SAX), alors que le CSV (certes format pourri antédiluvien) ou tout autre format "plat", je peux lire 1000 lignes un jour et reprendre à la 1001 le lendemain et la mémoire occupée est seulement la ligne courante.
Maintenant parlons de millions de lignes de données à passer dans un batch...
Ce n'est pas un bon format d'échange de données en masse.
Ces fichiers ne sont pas vraiment "parcourable" avec les outils standards linux (cf remarques dans les posts au dessus), et pour ceux qui feront la remarque "il y a des outils adaptés", oui, chez moi sur mon ordi, j'installe ce que je veux, en entreprise/client, on fait avec ce qu'il y a d'installé quand on n'est pas l'administrateur, et selon les versions OS et les outils installés, et bien vous risquez de n'avoir que du "notepad de base" niveau fonctionalités.
1bis) Quand vous devez mettre en relation plusieurs balises pour interpréter le fichier XML (rassembler des champs différents pour fabriquer une requête SQL par exemple), et bien là, il faut passer par DOM, et le fichier sera intégralement chargé en mémoire avec la création de tous les noeuds du DOM, et c'est très loin d'être gratuit.
Si en plus les fonctionnels ont pris un malin plaisir à éclater les données a l'opposé dans le fichier et que vous avez des données en masse, j'ai du monter une JVM à 16Go pour pouvoir échanger des fichiers de millions d'enregistrement.
2) il y a beaucoup trop de symboles spéciaux ("<,<!,>,&,..." contrairement au "\" des fichiers textes), du coup, comme je le disais plus haut, des transformations XSL sur XML en chaîne ne sont pas stables, et c'est parfait pour arracher les derniers cheveux qui vous restent sur la tête, parce qu'un caractère spécial sera transformé en entité et la série de transformation deviendra un fichier inutile (déjà vu des <root> [= ] )
et les <![CDATA[]]> qui rajoutent un bon paquet de merde.
C'est un format fragile rien que pour ça.
3) validation du schéma, maintenant on a json et yaml qui ont l'équivalent et ce sont des formats plus léger en taille et à la lecture, donc ce n'est plus un argument.
4) et puis surtout, il faut des outils prévus pour, là on a notepad++ chez le client, j'ai pu ajouter le plugin XML, mais sans plugin, c'est indigeste à la lecture et on peut facilement oublier une balise sans un analyseur de syntaxe.
Pour résumer, lourd, fragile, instable et il faut des outils spéciaux qui ne sont pas forcément installés chez le client.
J'en ai bouffé du XML, j'étais un "expert", et bien je ne veux même plus entendre parler de XML sur des nouveaux développement.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par darkleon . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 7.
Même pour ça, c'est mauvais, qui n'a pas eu à faire des transformations XSL enchaînées avec les "&" qui se transforment ou pas en "&" aux mauvais endroits me lance la première pierre.
j'ai beaucoup utilisé XML dans sa période "hype" au boulot entre 2000 et 2005, et en vrac les inconvénients majeurs :
1) un fichier xml ne peut pas se traiter en flux à cause de la balise "racine" (il faut construire l'arbre en mémoire, ou comptabiliser les noeuds avec SAX), alors que le CSV (certes format pourri antédiluvien) ou tout autre format "plat", je peux lire 1000 lignes un jour et reprendre à la 1001 le lendemain et la mémoire occupée est seulement la ligne courante.
Maintenant parlons de millions de lignes de données à passer dans un batch...
Ce n'est pas un bon format d'échange de données en masse.
Ces fichiers ne sont pas vraiment "parcourable" avec les outils standards linux (cf remarques dans les posts au dessus), et pour ceux qui feront la remarque "il y a des outils adaptés", oui, chez moi sur mon ordi, j'installe ce que je veux, en entreprise/client, on fait avec ce qu'il y a d'installé quand on n'est pas l'administrateur, et selon les versions OS et les outils installés, et bien vous risquez de n'avoir que du "notepad de base" niveau fonctionalités.
1bis) Quand vous devez mettre en relation plusieurs balises pour interpréter le fichier XML (rassembler des champs différents pour fabriquer une requête SQL par exemple), et bien là, il faut passer par DOM, et le fichier sera intégralement chargé en mémoire avec la création de tous les noeuds du DOM, et c'est très loin d'être gratuit.
Si en plus les fonctionnels ont pris un malin plaisir à éclater les données a l'opposé dans le fichier et que vous avez des données en masse, j'ai du monter une JVM à 16Go pour pouvoir échanger des fichiers de millions d'enregistrement.
2) il y a beaucoup trop de symboles spéciaux ("<,<!,>,&,..." contrairement au "\" des fichiers textes), du coup, comme je le disais plus haut, des transformations XSL sur XML en chaîne ne sont pas stables, et c'est parfait pour arracher les derniers cheveux qui vous restent sur la tête, parce qu'un caractère spécial sera transformé en entité et la série de transformation deviendra un fichier inutile (déjà vu des <root> [= ] )
et les <![CDATA[]]> qui rajoutent un bon paquet de merde.
C'est un format fragile rien que pour ça.
3) validation du schéma, maintenant on a json et yaml qui ont l'équivalent et ce sont des formats plus léger en taille et à la lecture, donc ce n'est plus un argument.
4) et puis surtout, il faut des outils prévus pour, là on a notepad++ chez le client, j'ai pu ajouter le plugin XML, mais sans plugin, c'est indigeste à la lecture et on peut facilement oublier une balise sans un analyseur de syntaxe.
Pour résumer, lourd, fragile, instable et il faut des outils spéciaux qui ne sont pas forcément installés chez le client.
J'en ai bouffé du XML, j'étais un "expert", et bien je ne veux même plus entendre parler de XML sur des nouveaux développement.