Je me souviens avoir ralé ici sur le fait qu'à une époque on mettait du XML partout, et de m'etre fait bien rembarrer (mais c'était à l"époque ou on pouvait encore débattre). Le temps m'a donné raison (un peu comme sur les dérives sécuritaires qui rognent de plus en plus les libertés individuelles et le droit à la vie privée). Au final on voit d moins en moins d'outils qui utilisent XML pour les fichiers de configuration.
Pour quoi faire ? Juste parce que espace de nom, c'est bien ?
Les espaces de nom ce n'est pas forcement utile, et dans la plupart des cas ou j'ai utilisé yaml, ils n'apportent rien. Je ne dis pas que c'est inutile, je dis juste que ce n'est pas forcement necessaire. As-tuun exemple de cas oules espaces de nom auraient pu te simplifier la vie ?
XPPq is a command-line tool which transforms an XML file to another XML file, following directives inserted directly in the source XML file. This directives allow to handle macros, to affect value to variables and to test their values, to include files… In a glance, XPPq aims to be to XML what CPP is to C/C++.
Je ne pense pas que yaml soit fait pour traiter ce genre de problème. Et ça ne me choque pas d'utiliser xml pour manipuler xml (c'est cohérent avec l'écosystème).
C'est que YAML ou JSON sont souvent présentés comme une alternative à XML pour les fichiers de configuration. En ce qui me concerne, je trouve l'écriture de fichiers de configuration beaucoup plus simple en XML qu'en YAML ou JSON à cause de XPPq. Or, mettre en œuvre l'équivalent de XPPq pour YAML ou JSON me semble certes pas impossible, mais beaucoup plus compliqué à cause de l'absence d'espaces de noms.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
Effectivement je me suis mal exprimé. La syntaxe est relativement simple, mais c'est effectivement la lisibilité qui pose problème. Et quand tu as des structures un peu compliquées à manipuler, ça devient problématique de gérer "à ma main".
XML, c'est bien pour faire de l'échange de données entre systèmes. Ca permet aussi de transformer lesdits documents (xslt par exemple) d'un format à un autre. l'utilisation de xml pour les documents de type (open/libre/ms)office est appropriée. Idem pour SVG (je m'amuse parfois d'ailleurs à créer des documents svg "à la main" pour des besoins simples et spécifiques - mais j'utilise un outil tel que Inkskape pour des trucs un peu plus complexe).
Par contre, pour des fichiers de configuration, je maintiens que d'autres formats sont mieux adaptés (plus lisibles, donc meilleure maintenabilité).
Posté par abriotde .
Évalué à 2.
Dernière modification le 29 juin 2023 à 14:08.
Non, XML, ce n'est pas bien pour l'échange de données entre système.
Ce n'est pas bien pour l'humain, c'est trop verbeux et illisible sans un outils dédié (pour formater et plier/déplier).
Ce n'est pas bien pour la machine, elle plante à la moindre erreur (Comparé au CSV ou au YAML) et c'est très lourd et complexe à parser (Comparé au CSV, JSON, YAML, ProtoBuf et autres).
Ce n''est pas bien pour la planète, car le final est verbeux et donc lourd.
Après c'est certains, son avantage, c'est qu'il est bien connu et implémenté par à peu près tous les langages et Framework. Il est bien standardisé et tous respectent à peu près le standard si bien qu'il sera lu.
Le problème du JSON, c'est pour mettre des commentaire (le XML n'est pas top non plus la dessus), sinon, c'est le même en mieux (plus léger)
Certes YAML est moins bien supporté et à quelques particularités tordu, mais il à l'avantage d'être simple, lisible/modifiable par l'humain et la machine efficacement, il est donc bien mieux pour des fichiers de configurations et autres choses simple. D'ailleurs même un non informaticien, saura plus facilement lire/modifier un YAML qu'un XML.
Pour du transfert de données entre machine, pour moi, c'est du ProtoBuf (si l'humain n'intervient pas) et du JSON sinon. C'est beaucoup plus efficace (et donc rapide).
le human-readable a toujours été une vaste blague de XML… non, les points forts de XML sont :
des échanges inter-systèmes informatiques standardisés (et extensibles dans le temps : ajouter un champ ne remet pas en cause l'interface, chaque système prenant en compte les évolutions en fonction des besoins respectifs)
une DTD permettant de renforcer / décrire la teneur des échanges (bon, ça le serait si c'était bien utilisé :/)
un nommage des champs clairement identifié permettant de vérifier la conformité/complétude du message (si la DTD est bien faite /o\), mais bon ça devient vite verbeux à cause des balises ouvrantes/fermantes
Je ne vais pas parler des défauts, car bon, à ce compte, ASN.1 est plus efficace ;-) (pour de la gestion d'échanges de messages)
Pour de la gestion de format de document, comment dire XML… moui, bon, pourquoi pas, au moins les balises seront censées prendre moins de place que le contenu…
Je pense qu'il manque l'explication probable de pourquoi il y a des hypes technologiques qui finissent par passer un peu de mode pour être utilisés +/- là où la valeur ajoutée est réelle, car comme il le dit lui même, la quasi totalité des outils ayant eu une forte hype sont utilisés par la suite sur le long terme.
Déjà il y a évidemment un effet d'entrainement, tu vois qu'une nouvelle technologie émerge, tu veux t'en servir à toute les sauces. Mais je pense qu'il y a une explication au delà de ça. Par exemple quand on a un marteau, tout problème devient un clou. On le voit typiquement avec certains programmeurs qui ne se mettent jamais à jour : ils utiliseront toujours les vieilles méthodes et vieux outils pourtant inadaptés pour répondre au nouveau besoin car en fait ils ne cherchent pas à apprendre autre chose.
Ici c'est pareil, quelqu'un voit un truc de nouveau qui apporte des changements utiles dans certains contextes il va essayer de généraliser son usage car il manque de recul dessus. Il essaye de voir ce qu'on peut faire avec. Cela a aussi un effet bénéfique à terme, les gens peuvent se former plus vite et identifier les limites de ces outils car il aura été mis en place dans des tas et des tas de contextes même si finalement ce n'était pas le plus adapté. Et avec un peu de recul on identifie là où ça fait sens. Il faut du temps pour gagner en expérience pour prendre du recul, d'où cet aspect cyclique je suppose.
Je me pose une question : y a-t-il d'autres domaines que l'IT ou on voit ce genre de phénomène ? Je suis sur que oui mais là dans l'immédiat, je ne vois pas de réponse … Peut-être pour l'énergie : le tout électrique ? pour l'électricité, le tout "éolien/solaire/renouvelable ?" ? le "tout nucléaire" ? le "tout plastique" ?
En fait en y réfléchissant, en ce moment on est aussi beaucoup "anti" : on se rend compte des effets négatifs d'une technologie et on la combat à l'extrême pour la tuer, sans se poser de question pragmatique. Et j'ai l'impression qu'on a aussi les mêmes phénomènes vis à vis d'idéologies (je pense par exemple à des dérives telles que les dérives sécuritaires, radicalisations dans certains mouvements, …).
Tout phénomène de mode est sujet à une contre offensive au moment de l'émergence de la dite mode, ou pour la faire reculer après un certains temps quand on passe à une autre mode.
Suffit de voir les levers de boucliers à chaque fois, dont certains sont de la pure résistance au changement.
Très certainement mais dans l'informatique tout va plus vite, alors c'est plus flagrant.
Mais si tu parles de l'automobile, en France (au moins), on a eu comme doctrine le tout diesel, et maintenant on en sort pour adopter le tout électrique à batteries.
Dans l'énergie, on a eu le tout nucléaire, et aujourd'hui on a des gens qui prônent le tout renouvelable. Mais comme on parle de temps beaucoup plus long, ça se voit moins fort.
# Ca me fait sourire cet article .....
Posté par totof2000 . Évalué à 3.
Je me souviens avoir ralé ici sur le fait qu'à une époque on mettait du XML partout, et de m'etre fait bien rembarrer (mais c'était à l"époque ou on pouvait encore débattre). Le temps m'a donné raison (un peu comme sur les dérives sécuritaires qui rognent de plus en plus les libertés individuelles et le droit à la vie privée). Au final on voit d moins en moins d'outils qui utilisent XML pour les fichiers de configuration.
[^] # Re: Ca me fait sourire cet article .....
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Ça a été remplacé par JSON et YAML qui font… la même chose en moins bien.
On aurait peut-être mieux fait de garder XML, en fait. Avec ses fonctionnalités innovantes comme par exemple:
[^] # Re: Ca me fait sourire cet article .....
Posté par totof2000 . Évalué à 4. Dernière modification le 27 juin 2023 à 12:26.
Ca veut dire quoi "en moins bien ?"
Sinon .. syntaxe simple de yaml, ça me fait bien rire …
[^] # Re: Ca me fait sourire cet article .....
Posté par Claude SIMON (site web personnel) . Évalué à 3.
Ben déjà il leur manque les espaces de noms…
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Ca me fait sourire cet article .....
Posté par totof2000 . Évalué à 2.
Pour quoi faire ? Juste parce que espace de nom, c'est bien ?
Les espaces de nom ce n'est pas forcement utile, et dans la plupart des cas ou j'ai utilisé yaml, ils n'apportent rien. Je ne dis pas que c'est inutile, je dis juste que ce n'est pas forcement necessaire. As-tuun exemple de cas oules espaces de nom auraient pu te simplifier la vie ?
[^] # Re: Ca me fait sourire cet article .....
Posté par Claude SIMON (site web personnel) . Évalué à 1.
https://epeios.q37.info/tools/xppq/
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Ca me fait sourire cet article .....
Posté par totof2000 . Évalué à 2.
Quel est le rapport avec yaml ?
Description
XPPq is a command-line tool which transforms an XML file to another XML file, following directives inserted directly in the source XML file. This directives allow to handle macros, to affect value to variables and to test their values, to include files… In a glance, XPPq aims to be to XML what CPP is to C/C++.
Je ne pense pas que yaml soit fait pour traiter ce genre de problème. Et ça ne me choque pas d'utiliser xml pour manipuler xml (c'est cohérent avec l'écosystème).
[^] # Re: Ca me fait sourire cet article .....
Posté par Claude SIMON (site web personnel) . Évalué à 2.
C'est que YAML ou JSON sont souvent présentés comme une alternative à XML pour les fichiers de configuration. En ce qui me concerne, je trouve l'écriture de fichiers de configuration beaucoup plus simple en XML qu'en YAML ou JSON à cause de XPPq. Or, mettre en œuvre l'équivalent de XPPq pour YAML ou JSON me semble certes pas impossible, mais beaucoup plus compliqué à cause de l'absence d'espaces de noms.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Ca me fait sourire cet article .....
Posté par totof2000 . Évalué à 3.
Oups … Je pensais "syntaxe simple de xml" ça me fait bien rire.
[^] # Re: Ca me fait sourire cet article .....
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 4.
Ben c'est relativement simple, pour la partie que je maîtrise à peu près en tout cas. Par contre, c'est pas toujours bien lisible.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Ca me fait sourire cet article .....
Posté par totof2000 . Évalué à 4.
Effectivement je me suis mal exprimé. La syntaxe est relativement simple, mais c'est effectivement la lisibilité qui pose problème. Et quand tu as des structures un peu compliquées à manipuler, ça devient problématique de gérer "à ma main".
XML, c'est bien pour faire de l'échange de données entre systèmes. Ca permet aussi de transformer lesdits documents (xslt par exemple) d'un format à un autre. l'utilisation de xml pour les documents de type (open/libre/ms)office est appropriée. Idem pour SVG (je m'amuse parfois d'ailleurs à créer des documents svg "à la main" pour des besoins simples et spécifiques - mais j'utilise un outil tel que Inkskape pour des trucs un peu plus complexe).
Par contre, pour des fichiers de configuration, je maintiens que d'autres formats sont mieux adaptés (plus lisibles, donc meilleure maintenabilité).
[^] # Re: Ca me fait sourire cet article .....
Posté par abriotde . Évalué à 2. Dernière modification le 29 juin 2023 à 14:08.
Non, XML, ce n'est pas bien pour l'échange de données entre système.
Après c'est certains, son avantage, c'est qu'il est bien connu et implémenté par à peu près tous les langages et Framework. Il est bien standardisé et tous respectent à peu près le standard si bien qu'il sera lu.
Le problème du JSON, c'est pour mettre des commentaire (le XML n'est pas top non plus la dessus), sinon, c'est le même en mieux (plus léger)
Certes YAML est moins bien supporté et à quelques particularités tordu, mais il à l'avantage d'être simple, lisible/modifiable par l'humain et la machine efficacement, il est donc bien mieux pour des fichiers de configurations et autres choses simple. D'ailleurs même un non informaticien, saura plus facilement lire/modifier un YAML qu'un XML.
Pour du transfert de données entre machine, pour moi, c'est du ProtoBuf (si l'humain n'intervient pas) et du JSON sinon. C'est beaucoup plus efficace (et donc rapide).
[^] # Re: Ca me fait sourire cet article .....
Posté par BAud (site web personnel) . Évalué à 2.
le human-readable a toujours été une vaste blague de XML… non, les points forts de XML sont :
Je ne vais pas parler des défauts, car bon, à ce compte, ASN.1 est plus efficace ;-) (pour de la gestion d'échanges de messages)
Pour de la gestion de format de document, comment dire XML… moui, bon, pourquoi pas, au moins les balises seront censées prendre moins de place que le contenu…
# Je pense qu'il loupe une possible explication
Posté par Renault (site web personnel) . Évalué à 5.
Je pense qu'il manque l'explication probable de pourquoi il y a des hypes technologiques qui finissent par passer un peu de mode pour être utilisés +/- là où la valeur ajoutée est réelle, car comme il le dit lui même, la quasi totalité des outils ayant eu une forte hype sont utilisés par la suite sur le long terme.
Déjà il y a évidemment un effet d'entrainement, tu vois qu'une nouvelle technologie émerge, tu veux t'en servir à toute les sauces. Mais je pense qu'il y a une explication au delà de ça. Par exemple quand on a un marteau, tout problème devient un clou. On le voit typiquement avec certains programmeurs qui ne se mettent jamais à jour : ils utiliseront toujours les vieilles méthodes et vieux outils pourtant inadaptés pour répondre au nouveau besoin car en fait ils ne cherchent pas à apprendre autre chose.
Ici c'est pareil, quelqu'un voit un truc de nouveau qui apporte des changements utiles dans certains contextes il va essayer de généraliser son usage car il manque de recul dessus. Il essaye de voir ce qu'on peut faire avec. Cela a aussi un effet bénéfique à terme, les gens peuvent se former plus vite et identifier les limites de ces outils car il aura été mis en place dans des tas et des tas de contextes même si finalement ce n'était pas le plus adapté. Et avec un peu de recul on identifie là où ça fait sens. Il faut du temps pour gagner en expérience pour prendre du recul, d'où cet aspect cyclique je suppose.
[^] # Re: Je pense qu'il loupe une possible explication
Posté par totof2000 . Évalué à 3.
Je me pose une question : y a-t-il d'autres domaines que l'IT ou on voit ce genre de phénomène ? Je suis sur que oui mais là dans l'immédiat, je ne vois pas de réponse … Peut-être pour l'énergie : le tout électrique ? pour l'électricité, le tout "éolien/solaire/renouvelable ?" ? le "tout nucléaire" ? le "tout plastique" ?
En fait en y réfléchissant, en ce moment on est aussi beaucoup "anti" : on se rend compte des effets négatifs d'une technologie et on la combat à l'extrême pour la tuer, sans se poser de question pragmatique. Et j'ai l'impression qu'on a aussi les mêmes phénomènes vis à vis d'idéologies (je pense par exemple à des dérives telles que les dérives sécuritaires, radicalisations dans certains mouvements, …).
[^] # Re: Je pense qu'il loupe une possible explication
Posté par Renault (site web personnel) . Évalué à 4.
Tout phénomène de mode est sujet à une contre offensive au moment de l'émergence de la dite mode, ou pour la faire reculer après un certains temps quand on passe à une autre mode.
Suffit de voir les levers de boucliers à chaque fois, dont certains sont de la pure résistance au changement.
[^] # Re: Je pense qu'il loupe une possible explication
Posté par Maclag . Évalué à 3.
Très certainement mais dans l'informatique tout va plus vite, alors c'est plus flagrant.
Mais si tu parles de l'automobile, en France (au moins), on a eu comme doctrine le tout diesel, et maintenant on en sort pour adopter le tout électrique à batteries.
Dans l'énergie, on a eu le tout nucléaire, et aujourd'hui on a des gens qui prônent le tout renouvelable. Mais comme on parle de temps beaucoup plus long, ça se voit moins fort.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.