Posté par lasher .
En réponse au sondage XML est.
Évalué à 2.
[utilisations de XML]
« Et qu'est-ce que tu as utilisé d'autre que xml pour pouvoir comparer ? »
Java. :-) Plus sérieusement, j'ai utilisé ce que proposaient des langages compilés pour faire tout ce dont il est question, et XML, point. Je l'ai dit dès le départ, je ne connaissais pas YAML et JSON avant qu'on n'en parle ici. Je ne dis pas que XML est la panacée (en fait, je dis exactement le contraire dans le message auquel tu réponds), juste qu'effectivement pour l'échange de données, ainsi que la sérialisation, XML se prêtait bien à la chose (ah oui, et le stockage BDD aussi).
« Je ne savais pas que JavaScript avait besoin d'une machine virtuelle ? »
Mauvais terme de ma part. Un interpréteur.
« Si justement, ça change énormémént. Les balises énormément de bruit et alourdissent les transferts de données. »
Les balises sont redondantes, donc si compression il y a, et donc je ne vois pas en quoi ça alourdirait le transfert de données.
« La meilleure façon de compresser des données, c'est avant tout de ne pas y ajouter du bruit. Ensuite cela alourdit le déboggage des données elles-même. »
De toute manière, dès que tu as un format de données flexible et générique, tu es obligé de gagner en verbosité, XML ou pas XML. Les softs que je vois traiter de gros volumes XML utilisent leur propre représentation interne des arbres XML, et donc tout se fait en binaire. Le côté « chiant » d'XML c'est le parsing, je suis d'accord - ce qui se traduit aussi par les problèmes de transfert que tu évoques. Mais honnêtement, aussi fastidieux cela soit-il, le fait d'avoir le côté ouvrant/fermant permet justement d'être systématique dans le traitement de l'information (et de faire la validation, etc).
« C'est pas parce que c'est utilisé par tout le monde ou standardisé de fait/historiquement que c'est ce qu'il y a de meilleur. Les produits microsoft dominent le marché, je te laisse conclure. »
Je ne peux pas accepter cet exemple, car MS est tout seul à imposer sa vision, alors que pour XML, tu as un collège d'industriels et de chercheurs. Alors oui, ça veut aussi dire qu'on n'obtient pas une forme optimale (chaque participant veut insérer à tout prix SA fonctionnalité de la mort, et pour des raisons « politiques » on laisse faire - ou pas). Mais ça veut aussi dire que pas mal de paramètres sont pris en compte et que l'évolution ne se fait pas à la va-vite.
Pour le côté « standardisé de fait » : c'est justement parce qu'aucun standard n'avait su s'imposer qu'il était temps de faire quelque chose. Le C est un standard de fait dans l'industrie. Java aussi. Pourtant, le C se prête de moins en moins à la programmation généraliste je trouve (l'utilisation de langages de plus haut niveau permet de faire moins d'erreurs de programmation, avec un temps de développement plus réduit), et le Java à toutes les sauces est une aberration informatique.
De façon générale, je ne sais pas depuis quand YAML et JSON existent, mais au pifomètre je dirais « ils sont plus jeunes que XML ». Et quand une structure adopte un changement déjà assez radical en lui-même, tu ne peux pas t'attendre à ce qu'elle change du jour au lendemain (un peu comme la boite qui est pleine de développeurs C et qui ne va pas se mettre au CAML du jour au lendemain). Il faut aussi gérer l'inertie, et crier « XML SAPU » tout en oubliant que, comme tout format, d'autres lui succèdent en tirant partie de ses erreurs (alors que, comme quelqu'un l'a fait judicieusement remarquer, XML a aussi un lourd passif avec SGML), c'est un peu facile.
[^] # Re: une immondice infame
Posté par lasher . En réponse au sondage XML est. Évalué à 2.
« Et qu'est-ce que tu as utilisé d'autre que xml pour pouvoir comparer ? »
Java. :-) Plus sérieusement, j'ai utilisé ce que proposaient des langages compilés pour faire tout ce dont il est question, et XML, point. Je l'ai dit dès le départ, je ne connaissais pas YAML et JSON avant qu'on n'en parle ici. Je ne dis pas que XML est la panacée (en fait, je dis exactement le contraire dans le message auquel tu réponds), juste qu'effectivement pour l'échange de données, ainsi que la sérialisation, XML se prêtait bien à la chose (ah oui, et le stockage BDD aussi).
« Je ne savais pas que JavaScript avait besoin d'une machine virtuelle ? »
Mauvais terme de ma part. Un interpréteur.
« Si justement, ça change énormémént. Les balises énormément de bruit et alourdissent les transferts de données. »
Les balises sont redondantes, donc si compression il y a, et donc je ne vois pas en quoi ça alourdirait le transfert de données.
« La meilleure façon de compresser des données, c'est avant tout de ne pas y ajouter du bruit. Ensuite cela alourdit le déboggage des données elles-même. »
De toute manière, dès que tu as un format de données flexible et générique, tu es obligé de gagner en verbosité, XML ou pas XML. Les softs que je vois traiter de gros volumes XML utilisent leur propre représentation interne des arbres XML, et donc tout se fait en binaire. Le côté « chiant » d'XML c'est le parsing, je suis d'accord - ce qui se traduit aussi par les problèmes de transfert que tu évoques. Mais honnêtement, aussi fastidieux cela soit-il, le fait d'avoir le côté ouvrant/fermant permet justement d'être systématique dans le traitement de l'information (et de faire la validation, etc).
« C'est pas parce que c'est utilisé par tout le monde ou standardisé de fait/historiquement que c'est ce qu'il y a de meilleur. Les produits microsoft dominent le marché, je te laisse conclure. »
Je ne peux pas accepter cet exemple, car MS est tout seul à imposer sa vision, alors que pour XML, tu as un collège d'industriels et de chercheurs. Alors oui, ça veut aussi dire qu'on n'obtient pas une forme optimale (chaque participant veut insérer à tout prix SA fonctionnalité de la mort, et pour des raisons « politiques » on laisse faire - ou pas). Mais ça veut aussi dire que pas mal de paramètres sont pris en compte et que l'évolution ne se fait pas à la va-vite.
Pour le côté « standardisé de fait » : c'est justement parce qu'aucun standard n'avait su s'imposer qu'il était temps de faire quelque chose. Le C est un standard de fait dans l'industrie. Java aussi. Pourtant, le C se prête de moins en moins à la programmation généraliste je trouve (l'utilisation de langages de plus haut niveau permet de faire moins d'erreurs de programmation, avec un temps de développement plus réduit), et le Java à toutes les sauces est une aberration informatique.
De façon générale, je ne sais pas depuis quand YAML et JSON existent, mais au pifomètre je dirais « ils sont plus jeunes que XML ». Et quand une structure adopte un changement déjà assez radical en lui-même, tu ne peux pas t'attendre à ce qu'elle change du jour au lendemain (un peu comme la boite qui est pleine de développeurs C et qui ne va pas se mettre au CAML du jour au lendemain). Il faut aussi gérer l'inertie, et crier « XML SAPU » tout en oubliant que, comme tout format, d'autres lui succèdent en tirant partie de ses erreurs (alors que, comme quelqu'un l'a fait judicieusement remarquer, XML a aussi un lourd passif avec SGML), c'est un peu facile.