La taille du fichier, on s'en fout pas mal, ça passe très très bien à la compression (c'est du texte très redondant)
Un fichier compressé, c'est un binaire. L'intérêt d'origine d'XML, c'est d'être utilisable sur un réseau sans trop en chier, chose que le texte ASCII ( sur 7 bits, donc ) fait très bien, contrairement au binaire.
Compresser un fichier XML, c'est un non-sens, parce qu'on perd l'un de ses intérêts principaux... mais tout le monde le fait, parce qu'XML c'est verbeux...
Dit autrement, compresser XML, c'est prouver qu'on à pas réfléchit avant d'utiliser d'XML.
"Les devs ont la flemme d'écrire un parseur" -> "les devs ont l'intelligence de réutiliser des parseurs déja déboggués"
Ou alors, les devs se sont tapé l'écriture d'un parseur XML à la main et on la flemme d'en écrire un autre. Le fait que celui déjà écrit soit débogué est une assertion trompeuse, car les dev ne font pas tous ni toujours des tests unitaires couvrant à 100% leur code.
La structure hiérarchique imposée par le xml permet de rationnaliser le stockage des données, à définir des noms de champs signifiants, etc.
Certes, mais XML est loin d'être le seul à définir des noms signifiants. En fait, INI le fait aussi. ( vendredi...)
Pour le reste, je te rejoins, oui, le problème c'est bien le dev qui choisit XML... ou plutôt le type qui écrit le cahier des charges du dev ( ça peut être le dev, mais pas toujours ).
[^] # Re: Sans être fan du tout
Posté par freem . En réponse au journal XML c'est de la daube!!!. Évalué à -8.
Un fichier compressé, c'est un binaire. L'intérêt d'origine d'XML, c'est d'être utilisable sur un réseau sans trop en chier, chose que le texte ASCII ( sur 7 bits, donc ) fait très bien, contrairement au binaire.
Compresser un fichier XML, c'est un non-sens, parce qu'on perd l'un de ses intérêts principaux... mais tout le monde le fait, parce qu'XML c'est verbeux...
Dit autrement, compresser XML, c'est prouver qu'on à pas réfléchit avant d'utiliser d'XML.
Ou alors, les devs se sont tapé l'écriture d'un parseur XML à la main et on la flemme d'en écrire un autre. Le fait que celui déjà écrit soit débogué est une assertion trompeuse, car les dev ne font pas tous ni toujours des tests unitaires couvrant à 100% leur code.
Certes, mais XML est loin d'être le seul à définir des noms signifiants. En fait, INI le fait aussi. ( vendredi...)
Pour le reste, je te rejoins, oui, le problème c'est bien le dev qui choisit XML... ou plutôt le type qui écrit le cahier des charges du dev ( ça peut être le dev, mais pas toujours ).