Bonjour,

j'ai un cas concret dans mon SI où l'on doit définir un format de fichier unique comme source d'alimentation standardisée. (c'est un projet assez global quand même)
-> Je précise bien, c'est le format de transfert de données "légèrement" relationnelles de BDD à BDD : c'est des paquets de 100.000 enregistrements 100.000 "fiches" qu'on envoi, pas un bête fichier de conf, ni un descripteur de véhicule spacial, ni un métalangage de compilation transquantique, ni un remplacement temporaire de BDD ...

Avant, on avait un fichier plat qui faisait (mal) le boulot. (mal, parce que même avec un fichier plat, il y avait moyen de faire des conneries)

Pour des raisons politiques, on va avoir du xml.
La question, c'est : ca apporte quoi ? (par rapport à un fichier plat, type csv)

Donc, avec ma non-connaissance, ca donne :

Avantages :
- c'est hiérarchique (oui, oui, et c'est génial d'ailleurs ... Bon, dans notre SI, on remarque que le schéma de donné ne vole pas très haut non plus, c'est souvent du 1-1)
x c'est auto-descripteur, donc universel (mais un fichier plat aussi peut être auto descripteur avec l'entête des colonnes)
x c'est un format universel, trivialement lisible ou ecrivable par tous les outils (mais pas mieux qu'un fichier plat ... On peut pas faire plus simple qu'un fichier plat)
- inutile de croiser les lignes pour lire un enregistrement hiérarchique complet (ca, c'est pratique ... Il fallait forcément une BDD pour régénérer la hiérarchie d'un plat : il fallait recroiser les lignes)
x il est très robuste pour envoyer des données universelles (sauf qu'on envoi pas nos données à l'univers, on s'appelle pas google. Globalement on envoi toujours la même chose)
- le format un peu plus complexe permet de retirer certaines décisions de ceux qui ne maîtrisent pas le sujet. (notamment avec un xsd qui part directement d'une équipe technique vers une équipe technique)
- le format plus complexe permet d'éliminer des possibilités d'âneries (exemple : l'ajout des colonnes blanches "au cas où" )

Inconvénients :
- c'est 3 fois plus volumineux, 10 fois plus difficile à traiter, surtout sur de gros volumes (inconvénient minime, je l'accorde)
- c'est illisible par un humain contrairement au fichier plat (et ce n'est plus minime, ca interdit la source d'alimentation "humains" sans utiliser un outil supplémentaire, lequel est généralement moins cool qu'excel) (petit bémol : les fichiers plat trop gros redeviennent illisibles)
- c'est plus difficile à lire qu'un fichier plat (selon les outils, à commencer par le spécifique : ya plein d'api, certes, mais ca restera toujours plus difficile que du csv)
- ya 5 fois plus de possibilités de faire des conneries avec du xml (les attributs qui vont se retrouver dans les données, la hiérarchie mal foutue, les attributs encore plus mals nommés, xsd abusivement contraignant, 50% des réunions à recommencer avec une explication du format, et 50% des décisions prises avec incompréhension du format, erreurs structurelles à la création du format ...). Je dis pas que c'est compliqué, c'est aussi simple que faire du vélo. Mais faire un fichier plat, c'est aussi simple que marcher, et ya encore 5% des gens qui ne peuvent pas marcher.
x le xml ne règle pas tous les problèmes : il faut toujours un mapping en entrée & sortie, lequel peut toujours être faux, et un fichier xml peut toujours être fonctionnellement incorrect (avec à la fois un "name" et un "nom" par exemple), donc il faut toujours le valider. (mais ce ne sont pas un inconvénient nouveau)

Ca, c'est ce que je vois (et que je trouve sur Wikipedia)
Maintenant, du xml, on en fera, et les inconvénients, si je les ai ratés, on les découvrira sur le tas. Par contre, si j'ai oublié des avantages, on risque de passer à coté.
- documentation de mapping automatique ?
- possibilités d'évolutions vers une plus grande intelligence et/ou de meilleurs outils et/ou de meilleures ressources ?
- effet constructif sur le long terme des contraintes ? (du style UTF8 ?)

Merci !

Pour moi un fichier csv c'est bien pour un tableau. Un fichier XML c'est pas un tableau (même si tu peux avoir qu'un root node et plein de nodes identiques en dessous ce qui revient à un tableau).

Je rejoint Je@nb,   mais par expérience je dirais que le transfert de fichier au format XML tant de plus en plus à supplanter  le format old school CSV. Celui-ci (le csv) etait très pratique à une époque ou l'on devait transferer des données de systèmes complétement différents (monde windows => as400,   monde IBM ==> DOS...etc..).

Maintenant tous les cahiers des charges d'interface que nous rédigeons à la boite, le format est EXCLUSIVEMENT du xml. Car justement ce format permet un controle beaucoup plus stricte des données et de hiérarchiser les données.
Et contrairement à ce que tu penses, un ficher xml n'est pas plus dur ni à lire ni à charger pour peu que l'on utilise les outils adéquat. Quant au mapping d'entrée/sortie, un bon "vieux" ETL et le tour est joué.  

Merci pour ces réponses.
En gros vrobaina, tu veux dire qu'il ne faut pas hésiter à utiliser le xml même pour envoyer un fichier tout bête avec 2 champs, pour ses possibilités d'évolutions, et éviter de trainer encore des cvs au milieu des xml ...
 
Qu'un ETL mange du xml comme du cvs, je n'en doute pas, mais c'est plutôt le reste qui m'ennuit.
Je peux utiliser quoi pour demander à Mme Michu de faire ses saisies dans xml ?

tu fais à madame Michu, une jolie page web, dans laquelle elle pourra saisir les informations. Tu pourra controler ces informations. En cas d'erreur tu demande à Mme Michu de resaissir les données erronées et si tout est Ok, alors c'est ton prog qui va générer le fichier XML.