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.

[icareo]

+1 pour json.
plus lisible.
plus léger.

[Tommy31]

Il y a d'autres alternatives : yaml un langage textuel très orienté lisibilité, ou les protocols buffer de google par exemple.

[kassak]

YAML est un très bon format.
JSON est très efficace aussi.

C'est sûr que XML c'est lourd, très lourd...

[Jérémie A.]

Il y a d'autres alternatives : yaml un langage textuel très orienté lisibilité

Je trouve le YAML parfaitement imbuvable à côté de l'XML. Ce truc est une vraie horreur, et n'est clairement pas si lisible que ca. A force de vouloir simplifier les structures, on en perd justement en lisibilité. Bref, perso, XML ne me dérange pas du tout.

[Bruno PICART]

Ainsi est fait l'être humain : on lui donne un outil innovant : il l'utilise à outrance, dénature son contexte de prédestination et malheureusement obtient parfois des résultats totalement opposés à ce qu'il attendait.

XML est très bien : il est stardardisé, ouvert, structuré, et plein d'autres bonnes choses.



S'il est utilisé dans un autre contexte que le portage de données inter-applications, c'est alors que des défauts, passés quasiment inaperçus jusque là, apparaissent soudain.



Préférons donc le pragmatisme au dogmatisme.

[lollancf37]

Ainsi est fait l'être humain : on lui donne un outil innovant : il l'utilise à outrance, dénature son contexte de prédestination et malheureusement obtient parfois des résultats totalement opposés à ce qu'il attendait.

XML est très bien : il est stardardisé, ouvert, structuré, et plein d'autres bonnes choses.



S'il est utilisé dans un autre contexte que le portage de données inter-applications, c'est alors que des défauts, passés quasiment inaperçus jusque là, apparaissent soudain.



Préférons donc le pragmatisme au dogmatisme.

Je ne pense pas que l'on soit rentré dans le dogme, j'aimerai bien savoir ce qui t'as amene a cette conclusion. STP.

[jackncoke]

Je suis un grand adepte du XML mais il est vrai que sans designer la lisibilité peut être assez moyenne.
Le YAML offre plus de visibilité, il notamment fait ses preuves dans l'écriture de modèle de données (cf. logiciel d'écriture MERISE, PhpMyAdmin, TOAD, ...)
Symfony l'utilise à 200 % pour l'écriture de fichier de configuration et de schéma de base de données et je dois avouer qu'il est très pratique pour cela.
Cependant le XML reste quand même selon moi une écriture très simple, très standardisée qui n'est pas près de s'éteindre !

[Killing Joke]

Je partage complètement cet avis !

Le XML est devenu une plaie aujourd'hui (d'ailleurs on parle souvent de XM-Hell !), parce que, en effet, utilisé totalement abusivement, Spring en tête (il y a de bons concepts dans Spring mais beaucoup de mauvaises choses aussi) suivi de près par Maven qui est une des plus grosses fumisteries de ces dernières années (oui les POM.xml sont illisibles, mais en plus, on nous avait vendu une solution où il y aurait moins de répétitions à faire que dans des build.xml ANT, résultat, entre chaque projet Maven on passe quand même notre temps à copier/coller/paramétrer des blocs de config de plugins et de reports ...).

L'autre point qui m'agace au plus haut point c'est le chargement de configuration "auto-magic" avec un fichier pris dans le classpath (dans un jar, dans web/WEB-INF/classes, etc.), c'est insupportable comme mode de fonctionnement (heureusement que ce n'est pas utilisé par tout le monde), on ne sait jamais qu'est ce qui est pris en compte et activé : marre de tout ce bordel de configuration. Il serait temps que tout le monde revienne à un principe simple : faire simple !

[Morbo]

Je suis d'accord avec Bruno PICART, c'est parce que le XML a été à la mode, utilisé partout où il le pouvait sans raison, qu'il provoque un ras le bol général aujourd'hui.
Le XML, comme tout format text suffisamment intelligible, est adapté à la communication inter-logiciel, voir humaine. Rien de plus.

Et là où XML, à mon sens a de l'avance, c'est qu'il est possible de transformer du XML en XML (via XSL-T par ex) et cela indéfiniment et le nombre de formats autour d'XML.
Dès que l'on cherche à produire des documents et media web, travailler en XML est un atout car au final ce sont des formats basés sur du XML ou du XML permet d'en produire (xhtml, pdf, document MS Office depuis 2003, Open office, flux RSS, ....).

La gestion des espaces de nom qui permet de bien séparer les grammaires, donc des domaines. Ce qui relève de la logique, et ce qui relève des données.
Ce qui est stratégique en entreprise, c'est pas seulement les données, c'est aussi les règles "métier" qui régissent les applications. Il faut leur assurer une souplesse et une visibilité maximale
Si une règle métier change, je modifie un noeud XML, les xsl-t se chargent de présenter aux acteurs leurs vues appropriés, les programment sont impactés sans recompiler ou redéploiement.
On peut même imaginer mieux, je peux donner accès via des interfaces web à ces règles définis en XML, car des formulaires déduis en XForms sont accessible et des XSD valident leur contenu.

Sinon mon framework web préféré du moment, c'est Play! qui n'a aucune configuration xml .

[kapok]

Pour en manger à toutes les sauces actuellement (on stock même le xml directement en base...) avec une techno PHP.

Je pense que l'XML est vraiment trop verbeux, trop lourd, trop lent, ...
Son parsing est très peu optimisé (simple_load_xml ?...) et en général ce qui aurait pris 3 lignes de code pour obtenir une information en prend beaucoup plus avec du XML.

Le XML devrait être utilisé que pour les flux d'informations.

[Thorna]

Tout dépend de l'utilisation.
J'ai besoin d'un fichier, placé à un endroit tranquillement sécurisé, dans lequel je vais stocker en clair un compte, un nom de serveur et un paramètre. Ai-je vraiment besoin d'un fichier XML bien structuré, propre et tout? Ou du Json ou du Yaml ? Ou bien un bête fichier.ini avec ses 3 lignes, ses 3 signes "=" et sa balise de région est parfaitement lisible, parfaitement adapté et parfaitement suffisant ?
Si j'en crois les exemples qui foisonnent partout sur le net, il semble qu'XML soit l'obligation. Parce que c'est plus efficace ? Bien sûr que non : parce qu'on ne parle que de ça, parce que les exemples foisonnent, parce que les bibliothèques foisonnent aussi; alors que pour lire un .ini en utilisant une bibliothèque déjà écrite, il faut fouiller 5 minutes de plus.
Il n'y a rien de fataliste dans XML : c'est la mode du jour et, comme toutes les modes, c'est sujet à excès. Peut-être que c'est en train de changer !

[FloMo]

Personnellement, je trouve que pour tout ce qui est services web, JSON remplace allègrement XML dans la plupart des cas : c'est léger (et d'autant plus avec GZip) et bien supporté par majorité de langages. Je l'utilise en C, Objective-C, PHP et bien sûr JavaScript sans aucun soucis.

Après, sur de gros volumes de données, l'usage du XML peut être justifié :
- l'utilisation de données structurées pour décrire des documents (site web, livre ePub)
- les services nécessitant des recherches dans un gros volume d'informations (via XPath, qui est tout adapté)

Mais souvent, son usage des pas indispensable, en effet. On le voit d'ailleurs à la démocratisation du JSON dans les gros services web (Google, Facebook, Twitter)

[sevyc64]

Ai-je vraiment besoin d'un fichier XML bien structuré....Ou bien un bête fichier.ini

Tout dépend, dans ton cas. Si les modifications ne sont pas faites directement dans le fichier lui-même (via une interface de ton logiciel) ou alors uniquement par des personnes compétentes, alors le XML peut faire l'affaire tout comme les autres formats. Si le fichier peut directement être modifié, pourquoi pas par des personnes pas forcéments compétentes (client en télémaintenance par exemple) il est clair que le fichier ini est plus pratique à mon gout.

qui foisonnent partout sur le net, il semble qu'XML soit l'obligation

Ca c'est l'idée qu'à tenter de lancer Microsoft avec la sortie de Windows 98 et l'abandon du format ini (déclaré définitivement obsolète à ce moment là) au profit dans un premier temps de la base de registre puis du format xml présenté comme le remplaçant du format ini.
12 ans plus tard, le format ini existe toujours, les api de gestion de ce format sont toujours présentes dans Windows y compris dans W7, et même Microsoft lui-même continu de l'utiliser en 2010.
Comme quoi, si le format ini est probablement plus limité que le xlm, il est encore nettement suffisant et pratique pour toujours exister.

[Hikage]

Personnellement, je trouve que pour tout ce qui est services web, JSON remplace allègrement XML dans la plupart des cas : c'est léger (et d'autant plus avec GZip) et bien supporté par majorité de langages. Je l'utilise en C, Objective-C, PHP et bien sûr JavaScript sans aucun soucis.

Après, sur de gros volumes de données, l'usage du XML peut être justifié :
- l'utilisation de données structurées pour décrire des documents (site web, livre ePub)
- les services nécessitant des recherches dans un gros volume d'informations (via XPath, qui est tout adapté)

Mais souvent, son usage des pas indispensable, en effet. On le voit d'ailleurs à la démocratisation du JSON dans les gros services web (Google, Facebook, Twitter)

Simple question ? Existe-t-il un système de description d'un format Json ?
De spécifier quel champs sont obligatoire, présent, si il sont de type alphanumérique, numérique, devant correspondre à un pattern ou à une liste de valeur possible ?