Discussion :

[grunt2000]

Bonjour,


Ca y est. Au plaisir d'ouvrir un livre Java récent et de découvrir qu'un mot-clé supplémentaire (pour les pratiquants, une annotation) dans mon code source saura remplacer un fichier XML dont la présence était auparavant obligatoire, je me dis que nous sortons peut être d'une période où tout n'était qu'XML. Jusqu'à l'indigestion.

Il y en eu partout et pour tout. Si pour l'échange de données entre systèmes il avait des atouts certains, je défends la thèse qu'il a été utilisé abusivement. Le paramétrage des composants, par exemple, est trop souvent passé par lui.

Et cela a mené à des situations extrêmes. Il devenait parfois plus délicat de réussir son XML de paramétrage ou de compilation que le propre code source que l'on voulait faire fonctionner. Java J2EE - mais est-il le seul? - nous a pendant des lustres gratifiés de mille fichiers XML à produire pour tout et n'importe quoi. Une source de gêne certaine.

Maven 2, qui sert à la construction de projets et qu'il est de bon ton de trouver merveilleux (alors je vais essayer de l'écrire aussi: "C'est bien ma veine!"), a atteint à mes yeux des sommets de farfeluterie et d'obscurité dans ses fichiers pom.xml, décrivant les travaux qu'il avait à mener.

Et aujourd'hui vient (ou revient) le paramétrage par script, fondé sur un langage dédié à l'application que l'on veut paramétrer. Je pense que c'est la bonne solution.
Il assurera une meilleure clarté et une évolution plus facile si ces langages se fondent sur des grammaires claires.

Mais il est tard. Je pense que bien qu'XML ait eu beaucoup d'atouts, il a été utilisé souvent d'une manière qui a généré de la complexité. Qu'il est un révolutionaire des années 2000 dont on a le droit de tirer un bilan, d'utiliser "notre droit d'inventaire", comme on dit.


Qu'en pensez-vous?

Grunt.

[yann2]

Salut

Je suis complètement d'accord avec toi. Le XML est une plaie !! Il parait que c'est human readable/writeable mais, la réalité est autre. Autant, il est pratique pour échanger des données entre deux programmes (indépendant de la plate forme utilisé et des librairies dispo pour n'importe quelle plate forme), autant il est monstrueux quand on doit aller taper dedans à la mano.

Allez, en vrac:

• struts
• spring
• web.xml (JEE)
• hibernate
• etc.

Et, c'est vrai, il est terriblement simple de faire une erreur dans un fichier XML. Je me rappellerai toujours de cette virgule manquante dans un fichier de conf struts qui me donnait une jolie page blanche (plus qu'à modifier le fichier et relancer le serveur).

Les annotations nous permettent de mettre les meta informations directement dans le fichier source. Je ne sais pas si c'est un plus mais, c'est bien plus clair que cet amas de < et > et &quot;

Pour info, avant l'arrivée des annotations il y avait la possibilité d'utiliser XDoclet http://xdoclet.sourceforge.net/xdoclet/index.html

J'ai toujours penser qu'un fichier XML ne doit pas être saisie à la main mais :

• être généré
• offrir une interface graphique permettant de visualiser/éditer le fichier xml

Yann

[Hephaistos007]

En même temps, il faut bien des fichiers de configurations. Plusieurs solutions s'offrent à nous :

• un fichier à base de texte (dans la même veine que Property en Java)
• un dialecte XML
• un langage de scripting dédié

La solution 1 a été abandonnée pour sa faible structuration. Le solution 2 est un consensus entre 1 et 3. La solution 3 est logiquement la meilleure mais encore faut-il que les éditeur développent l'outillage qui va avec. Le coup des annotations, je suis à 100% pour, mais cela ne peut probablement pas être aussi expressif que les solutions 1,2 et 3.

[lollancf37]

En même temps, il faut bien des fichiers de configurations. Plusieurs solutions s'offrent à nous :

• un fichier à base de texte (dans la même veine que Property en Java)
• un dialecte XML
• un langage de scripting dédié

La solution 1 a été abandonnée pour sa faible structuration. Le solution 2 est un consensus entre 1 et 3. La solution 3 est logiquement la meilleure mais encore faut-il que les éditeur développent l'outillage qui va avec. Le coup des annotations, je suis à 100% pour, mais cela ne peut probablement pas être aussi expressif que les solutions 1,2 et 3.

La solution 1 n'a pas été abondonnée, c'est vrai que c'est peu pratique sur les projets conséquents mais de la a dire que sa faible structuration rend cette solution inéficace c'est un peu abusé. C'est simplement qu'il est plus facile de gerer des métadonné avec XML qu'avec un simple fichier texte et que de plus en plus on travail avec des métadonnées.

En ce qui concerne la solution 3 (un language de script dédié), si les éditeurs utilisait des languages script déja existant et batissait des structure de configuration solide, je pense que cela serait beaucoup mieux.

Je ne pense pas aussi que XML est un consensus entre les deux. La solution script offre beaucoup plus de possibilité que le XML, a mon avis, les deux ne sont pas comparable meme si l'on peut utilisé XML pour de la configuration.

Il y a aussi la solution de parametrage via BDD, je pense ici a une base de données de type SQLite meme si je prefere que ma conf. soit mise dans de bon vieux fichier texte.

Pour ma part je suis d'accord avec yann2 quand il dit que le XML devrait etre généré et pas ecrit a la main. Le XML c'est quelque chose d'excellent pour la transmission de données ou la description de données de maniere général cependant des que l'on y ajoute le facteur humain c'est tout de suite moins attirant et ce pour pleins de raisons (protocole obscure, redondances, dépendances obscure ...).

[icareo]

Tout à fait d'accord avec toi.
Je lisais justement un article intéressant l'autre jour qui m'a fait réaliser (ou presque) l'abus :

It's all so easy. So easy, indeed. So easy to burn megabytes of RAM parsing XML infosets just to pull a few elements out of them.

(tiré de Writing Faster Managed Code: Know What Things Cost )

... c'est vrai qu'on a un peu tendance à oublier ce que représentent les quantités de RAM occupées (vite monstrueuses pour des petites applis managées) en comparaison avec les standards d'autrefois. (que je n'ai pas connu, soit dit en passant !)


Je m'applique depuis à employer plus souvent la "solution 1 ou 3" (suivant complexité des objets à stocker)

[davcha]

Json.

[Cyrilange]

En tant que développeur .NET je pense que l'XML ne doit être utilisé que pour l'interopérabilité et le polymorphisme d'objets stockés dans une base de données.

Pour ce qui est des fichiers de configuration, cela peut vite devenir un vrai casse tête avec des problème de syntax, de "case sensitive" et de bric à brac de sous ensembles et de propriétés anarchiques.

Bref, XML c'est bien, mais pas à toutes les sauces.

[alain.couthures]

Je suis ce qu'on appelle un XML Geek!

Je travaille à l'international avec des personnes impliquées dans les travaux du W3C et je n'ai pas du tout le sentiment que le XML va s'arrêter.

On constate plutôt un emballement où il apparait que plus tout est fait en XML plus on a de valeur ajoutée.

OK ce n'est pas pour demain mais pour après-demain.

C'est une vraie remise en cause des valeurs des langages de 3ème génération et cela va demander d'arrêter de "pisser du code" et de réfléchir à la place !!

XML n'est qu'une notation, la programmation déclarative est derrière tout ça.

[dtrosset]

Si par programmation déclarative il faut comprendre quelque chose du genre de XSLT, alors il faudra trouver autre chose pour transformer du XML. Ce XSLT est véritablement imbuvable. C'est ce qui m'a fait changer ma chaîne d'outils de documentation. J'utilisais DocBook, du XML, XSLT, de XML, et puis FOP, encore du XML.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DocBook --[XSLT]--> HTML + FOP --> PDF

J'ai changé pour des outil plus simples à apréhender, plus simples à configurer et à personnaliser, avec lesquels j'écris simplement du text, et qui sont pour finir encore plus puissants, sans XML.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

reStructuredText --> HTML + Latex --> PDF

Didier

[Morbo]

Pour nuancer cette expérience, je suis au contraire très satisfait de XSL-T! Même si j'ai pris un peu de temps à comprendre cette approche déclarative, je l'utilise maintenant facilement.

Pour ma chaine documentaire, j'utilise XML de bout en bout.
C'est du WorldML à la base avec des références aux données possibles graphiquement via un XSD générique.
La rédaction peut donc être faites par des acteurs non technique.
Des formulaires web générés dynamiquement et pour finir du PDF via FOP.
L'intérêt étant l'évolutivité, une source xml initialement statique, peut plus tard être générée dynamiquement via nouveau un XSL-T, qui lui même peu être généré, ....

Néanmoins, dtrosset je serais très intéressé d'étudier une autre approche. Si tu as des liens, je prend!

[Erwy]

Si par programmation déclarative il faut comprendre quelque chose du genre de XSLT, alors il faudra trouver autre chose pour transformer du XML. Ce XSLT est véritablement imbuvable.

Pas l'avis d'Ooo.
Ooo, pour tout ce qui est changement de format, n'est qu'une grosse librairie de feuille XSLT, que vous enregistrier en .DOC, .TXT ,PDF ou autre, vous transformez le fomat D'Ooo (qui est du xml) en votre cible via une feuille XSLT (qui transforme du XML en n'importe quel format texte).
Ooo vous permet aussi d'ajouter vos propres filtres XSLT.
Cela vous permet donc de lire/écrire/modifier vos fichier XML sous Ooo si vous maitrisez ce langage.

[thelvin]

Moi aussi je trouve que XML est utilisé à torts et à travers, et comme j'en fais les frais comme tout le monde, je comprends ce ras-le-bol général. Oui, XML, il faudrait passer à autre chose, ne pas rester dans le statu quo.

Mais XML est un bon outil, juste très mal utilisé.

Je vois de nombreuses objections :

- XML est trop compliqué !

Balivernes. Utilisez ce dont vous avez besoin, ignorez le reste. On apprend à le faire une fois, c'est vite fait, et ça marche pour la vie.
Le jour où vous en aurez besoin, du reste, vous serez contents que ça soit au moins possible en XML.

- JSON c'est plus lisible !

Balivernes. JSON n'est plus lisible que XML que là où un properties ou équivalent, ou un CSV, serait encore plus lisible.

- JSON c'est mieux !

J'aime beaucoup JSON, mais il ne gère pas les flux (ouais, ouais, ok, il les gère mal, pas pas.) Il est beaucoup plus limité. Son intérêt, c'est qu'il s'intègre encore mieux que XML, qu'il gère les données hiérarchiques et séquentielles, qu'il est très léger, et assez lisible. Splendide format de communication.

- YAML c'est mieux !

YAML est mon petit chéri, mais il ne gère pas les flux (cherchez pas d'excuse, il les gère pas.) Par rapport à XML, il s'intègre moins bien, et il est plus limité. Parfait là où il suffit et si on sait bien l'intégrer.

- XML est étudié pour être lisible par un humain mais ça sert à rien !

Foutaises. Pour un programmeur, cela permet de résoudre de nombreuses problématiques de gestion de données, à partir de rien, en quelques heures, rien qu'en se reposant sur les APIs XML.
Quand on ne sait pas se servir d'un bon outil, on ne dit pas qu'il ne sert à rien.

- XML est trop lourd !

XML est lourd, c'est sûr. Mais ce n'est pas si souvent qu'on en a quelque chose à f***e.
Utiliser php ou Java ou C# ou je sais pas quoi, c'est plus lourd que du C bas niveau. Mais pas inutile.

- XML comme configuration c'est trop compliqué !

On est d'accords. Ne le faites pas, à moins d'avoir une bonne raison.

(Je crois que j'ai fait le tour de mes objections.)

[ezmac]

en theorie XML est un bon moyen pour échanger des données, mais il es trop lourd (les balises pèsent presque plus que les données).

il n'y a aucun bénéfice a que ça soi lisible par un humain (c'est impossible sauf parser).

structure trop compliquée, comme l'on l'a dit içi, c'est presque un nouveau job à part entière.

et ce qui est fou est que les balises ne sont pas standardisées à niveau mondial (rajoutez un dictionnaire).

+ 1 pour JSON.... je l'utilise internement, mais je me suis fai taper sur les doits car il fallait que ce-là soit tout du xml.

[briegel]

Un format super, dans certaines circonstances : dans une application web, qui doit générer du contenu et le stocker, le XHTML est stocké dans un doc XML, le nombre de balises est très réduit par rapport au contenu, on évite le XSS sans efforts, je ne parle même pas des injections (SQL), et quand on veut récupérer le contenu, il suffit de copier bêtement le bon noeud et tout son contenu.

Alors personnellement, j'ai pas trouvé plus efficace que le XML pour cette utilisation.

Si je devais avoir un grand nombre de variables courtes à stocker, je ne penserais même pas à XML...