Pourquoi certaines personnes n'aiment pas XML ?

Bonjour tout le monde.

Ça fait longtemps que j'avais posté de nouveau sujet et j'ai cette question qui me trotte dans la tête:

Pourquoi certaines personnes n'aiment pas XML ?

J'ai eu une personne qui m'a donné une bonne raison une fois c'est que XML est un arbre et ne peut donc pas représenter des données qui se chevauchent comme pour une fresque historique. C'est une bonne raison mais ce n'est pas quelque chose dont on se sert tous les jours. Une autre raison plutôt bidon donnée par ceux qui préfèrent IRC à XMPP c'est que XML est plus verbeux et qu'il consomme donc plus de bande passante.

Pourquoi certaines personnes ne voit pas l'intérêt de n'avoir qu'un seul parseur partagé entre de nombreuses applications ?

Voila si quelqu'un a des idées là-dessus je suis tout ouïe.

Hello,

vu le nombre de langages qui s'appuient sur cette syntaxe et la foule d'application qui s'en servent j'aurai tendance a voir complètement à l'inverse.

Salut,

Personnellement je pense pas qu'il y a des gens qui aiment ou aiment pas le XML. Faut juste analyse et choisir la meilleure technologie pour l'application qu'on souhaite faire.

Typiquement, je préfére utiliser JSON pour communiquer des informations entres deux modules plutôt que XML et j'utiliserais XML pour un fichier d'import ou de config plutôt que JSON.

C'est juste du bon sens sur ce qu'on veut faire

A++

C'est comme toutes les technos : ça dépend comment et pour quoi on l'utilise. IL y a toujours des cas où ça se justifie et d'autres où ça ne se justifie pas.

Je n'ai pas dit que je n'aimais pas XML. Mais ce qui est certain c'est qu'on peut lui reprocher une certaine lourdeur et/ou d'être un peu trop verbeux, et de là en découle naturellement une possible surconsommation d'espace disque.


Dans le cas des fichiers de conf par exemple, vous serez quand même tous d'accord pour dire qu'il est plus facile de modifier « à la main » un fichier en texte brut (.ini, .conf, etc.) que du XML. Autre fait : pour des configurations complexes, on modifie majoritairement ces fichiers manuellement plutôt qu'en passant par des boîtes de dialogue interminables (ça va plus vite si on sait ce qu'on cherche à modifier, aussi). (Affirmation à contrôler, c'est un sentiment personnel non vérifié)
D'autant plus que, la particularité du XML soit la structure arborescente, n'y a pas vraiment de sens. J'ai jamais vu de fichier de conf à plus de trois niveaux (section, sous-groupe d'options, entrée/paramètre avec sa valeur). Donc à mon sens, sortir un char d'assaut pour écraser des moustiques, ça ne se justifie pas.

Côté stockage type BDD, suivant les données, pourquoi pas, ça peut s'avérer efficace. Par contre, je doute (à confirmer ou à infirmer) que XPath puisse être plus rapide que des requêtes SQL.


Un domaine où XML garde son intérêt à 100%, c'est quand même la structuration de documents à mon avis. Que ce soit du texte avec le XHTML, ou autre chose (il y a par exemple DAISY pour structurer un livre audio)... Parce que là on ne connaît pas le nombre de chapitres, sous-chapitres, sous-sous-chapitres, etc ... à l'avance. Donc il nous faut bien une structure arborescente qui puisse accepter un nombre infini et variable de niveaux.

Remarque, on pourrait se poser ces mêmes questions mais pour JSON...

Hello,

Hacken a écrit :

Personnellement je pense pas qu'il y a des gens qui aiment ou aiment pas le XML. Faut juste analyse et choisir la meilleure technologie pour l'application qu'on souhaite faire.

+1

Il se trouve qu'en ce moment je bosse sur une interface entre un ERP sur DB2 et une application sur Oracle. Les auteurs de l'ERP ont trouvé bien pratique de développer un module qui permet de générer et d'intégrer des fichiers xml. En l'occurrence j'aurais préféré de beaucoup pouvoir accéder directement aux tables de l'ERP via SQL ou à défaut utiliser des API pour plusieurs raisons :
* que j'ai besoin d'envoyer ou de recevoir des données je dois forcément passer par une phase fastidieuse de parsage.
* cette phase prend beaucoup de temps en raison du nombre très important de données (commandes de grandes surfaces), surtout côté ERP mais également du mien, alors qu'il s'agit de flux tendu.
* tout cela ajoute plein de surcouches qui multiplient les risques de problème (de connexion, de serveur qui tombe, etc.)


Et sinon (dans d'autres occasions) j'aime bien le xml !
Modifié par Heyoan (14 Feb 2009 - 13:55)

Heyoan a écrit :

Il se trouve qu'en ce moment je bosse sur une interface entre un ERP sur DB2 et une application sur Oracle. Les auteurs de l'ERP ont trouvé bien pratique de développer un module qui permet de générer et d'intégrer des fichiers xml. En l'occurrence j'aurais préféré de beaucoup pouvoir accéder directement aux tables de l'ERP via SQL ou à défaut utiliser des API pour plusieurs raisons :
* que j'ai besoin d'envoyer ou de recevoir des données je dois forcément passer par une phase fastidieuse de parsage.
* cette phase prend beaucoup de temps en raison du nombre très important de données (commandes de grandes surfaces), surtout côté ERP mais également du mien, alors qu'il s'agit de flux tendu.
* tout cela ajoute plein de surcouches qui multiplient les risques de problème (de connexion, de serveur qui tombe, etc.)


Et sinon (dans d'autres occasions) j'aime bien le xml !

Effectivement, pour toi c'est pas pratique mais j'imagine que ces données sont conservées un long moment (10 ans peut être?) et qu'on ne remplit pas la base de données jusqu'à ce qu'elle explose. Dans ce cas, archiver les données dans des fichiers .xml me semble plutôt adapté (pour retrouver la commande de canard en plastique du 20 mars 2001 par exemple).

J'ai adoré la simplicité d'apprentissage pour générer le xml en lui-même...

...j'ai été dégouté de la complexité de gestion quasi suicidaire pour un non-technicien de formation comme moi de XPath et XQuery.

Sinon, ben le xml, sans toutes les technologies de traduction (citées plus haut donc) est vraiment chouette puisqu'il vise la longévité des données (puisque très basiques) ainsi que le fait de la faire voyager sur n'importe quel appareil...

...Mais bon, encore une fois, avec xml sans XPath et Xquery on ne fait pas grand chose. Dommage. -___-

Le XML c'est bien à partir du moment où on en fait autre chose que de la simple sérialisation de donnée.

Pour ce genre d'opération, il y a mieux, pour tout le reste à partir du moment où on va devoir manipuler d'une façon ou d'une autre notre fichier, le XML montre son avantage avec tout un tas de librairie/protocole/recommandation basés dessus.
Modifié par tyx (16 Feb 2009 - 19:16)

Dans le lien donné par bzh on trouve ça à peu près vers le milieu du texte :

a écrit :
Les DTD (Document Type Definition) sont une autre façon de modéliser la structure d'un document, mais elles sont actuellement en voie d'obsolescence.

Quelqu'un peut nous en dire plus ?

Salut,

C'est quelque chose qu'on entend depuis quelques années déjà.

Mis à part les DTD, on trouve XML Schema et Relax NG.

Généralement, et sauf erreur de ma part, on définit une DTD pour tout ce qui est orienté document et XML Schema est plus utile lorsqu'il s'agit de contrôler les données d'une application.
L'un comme l'autre a son utilité puisqu'une DTD est bien plus simple à appréhender et peut, par exemple, définir des entités, ce qui s'avère très pratique pour la gestion des documents (ce que ne peut faire XML Schema). Ce dernier, quant à lui, peut contrôler les valeurs et leur type.

Pour ce qui est de Relax NG, il reprend les avantages d'une DTD et ceux de XML Schema, en apportant, si on le souhaite, une syntaxe compacte, ce pourquoi un nombre croissant de développeurs s'oriente sur celui-ci. Maintenant, je ne sais guère si c'est réellement exhaustif, auquel cas, on pourrait prétendre que XML Schema est, lui aussi, en voie d'obsolescence mais, AMHA, je pense que chacun de ces modes de définition a encore de beaux jours devant lui.

J'avais un œil sur ce fil depuis quelques jours déjà

Je ne suis pas un inconditionnel de XML. Quand je pense que ce format est plus adapté au stockage de mes données, je l'utilise. Mais souvent, un simple tableur est plus pratique...

À propos de DTD/XML Schema, il se trouve que je dois publier pas mal de contenus structurés; j'ai donc passablement pratiqué les deux. Les DTD sont pratiques pour les documents dont la structure n'est pas très complexe. Elles sont aussi très utiles pour les entités. En pratique, maintenant, j'écris un schéma pour décrire la structure du document (qui comporte par exemple des éléments pouvant posséder plusieurs collections possibles d'éléments enfants distinctes), pour décrire mes types de données (c'est quand même très très pratique pour éviter les erreurs à la saisie des dates, par exemple, et faciliter le traitement a posteriori avec XSLT). Et je "surcharge" le schéma avec une DTD interne, que j'incorpore à mes documents XML (c'est facile avec un gabarit), et dans laquelle je définis mes entités. Ça marche, et ça permet de bénéficier des avantages des deux formats
Modifié par Gilles (17 Feb 2009 - 11:40)

Gilles a écrit :
Je ne suis pas un inconditionnel de XML. Quand je pense que ce format est plus adapté au stockage de mes données, je l'utilise. Mais souvent, un simple tableur est plus pratique...

Pas compris.

Changaco a écrit :
Pas compris.

Si je veux exploiter les données stockées dans mon fichier XML, je suis obligé de passer par une moulinette XPath/XSLT. Dans le cas d'un traitement simple (tri de données, affichage sélectif...), je préfère stocker mes données dans un tableur, et lui faire faire les opérations. Il est conçu pour cela...

Mais dès qu'il s'agit de produire un document en sortie, et non plus seulement de changer de mode de présentation de mes données, alors je passe par XML/XSLT.

Pour illustrer, supposons que j'aie un bon de commande. Si je veux trier mes données par prix croissant à l'unité, et si je sais que je n'aurai rien de plus à faire avec elles, alors je les place dans un tableur. Si je sais que je vais devoir produire un bon de commande en PDF qui a l'air... d'un bon de commande, et que j'aurai à refaire ça à chaque commande, alors je stockerai mes données dans un document XML, dont la structure sera contrainte par une DTD ou un schéma, et appliquerai un petit coup de XSL-FO dessus.