Eclipse marche vraiment pas mal. Que ce soit pour l'édition de XSD ou de fichier plus classiques.
Le problème c'est que beaucoup de gens semblent utiliser XML pour stocker trois valeurs qui serait tout aussi bien en CSV.
L'interet d'XML c'est les outils qu'il y a autour et qu'ils sont facile à modifier. Pas de parser a réinventer, XPath, XQuery, XSLT, Xinclude, pas mal d'API pour la serialization automatique etc. C'est pas parfait mais ca fait gagner un temps fou de développement et pour faire évoluer les fichiers. Pour des fichiers de conf c'est plus douteux, mais au moins ca permet d'avoir une complétion "universelle".
Par contre si c'est pour faire communiquer deux processus proprio avec des contraintes de performance alors ca vaut peut être le coût de réinventer la roue. Et c'est la que se place "Protocol Buffers".
Récemment j'ai fait des stats sur les résultats des test unitaires et fonctionnels des 10 000 derniers builds d'un projet. Chaque résultat d'un build est stocké dans un ou plusieurs fichier XML, et le schema a évolué 3/4 fois. Apres 10 minutes d'XSLT j'avais tout reformaté en un gros fichier CSV, uploadé ca sur un cluster Hadoop DFS et commencé a sortir des stats avec Pig.
Je n'ai réinventé aucun outil. Du logiciel qui pond le fichier, à celui qui le transforme. Et une expression XPath reste toujours plus parlante qu'une série de grep | cut | awk | cut | sort | uniq. Et franchement, y'a plus intéressant à faire que de la manipulation de fichier dans l'informatique !
[^] # Re: Personnelement, je ne trouve pas le xml lisible
Posté par ckyl . En réponse au journal Google offre un format de donnée sous licence Apache. Évalué à 4.
Le problème c'est que beaucoup de gens semblent utiliser XML pour stocker trois valeurs qui serait tout aussi bien en CSV.
L'interet d'XML c'est les outils qu'il y a autour et qu'ils sont facile à modifier. Pas de parser a réinventer, XPath, XQuery, XSLT, Xinclude, pas mal d'API pour la serialization automatique etc. C'est pas parfait mais ca fait gagner un temps fou de développement et pour faire évoluer les fichiers. Pour des fichiers de conf c'est plus douteux, mais au moins ca permet d'avoir une complétion "universelle".
Par contre si c'est pour faire communiquer deux processus proprio avec des contraintes de performance alors ca vaut peut être le coût de réinventer la roue. Et c'est la que se place "Protocol Buffers".
Récemment j'ai fait des stats sur les résultats des test unitaires et fonctionnels des 10 000 derniers builds d'un projet. Chaque résultat d'un build est stocké dans un ou plusieurs fichier XML, et le schema a évolué 3/4 fois. Apres 10 minutes d'XSLT j'avais tout reformaté en un gros fichier CSV, uploadé ca sur un cluster Hadoop DFS et commencé a sortir des stats avec Pig.
Je n'ai réinventé aucun outil. Du logiciel qui pond le fichier, à celui qui le transforme. Et une expression XPath reste toujours plus parlante qu'une série de grep | cut | awk | cut | sort | uniq. Et franchement, y'a plus intéressant à faire que de la manipulation de fichier dans l'informatique !