Si XML est si mauvais… pourquoi tant de gens l'utilisent? [fermé]

37

Je comprends le but de XML, mais j'entends toujours les gens se plaindre de sa mauvaise réputation? Je ne comprends pas vraiment ce qui est si mauvais à ce sujet? J'entends d'habitude les termes "ballonné" et "lent" ballottés.

Mais je suppose qu'en tant que programmeurs, vous l'utilisez principalement. Et considérez-vous vraiment que c'est "mauvais" ... parce que, si c'est le cas, beaucoup de gens l'utilisent pour le transport de données ...

programming-practices xml
la source
1
Votre réponse est dans la question. Les gens l'utilisent toujours parce que les gens l'utilisaient, et les options sont (1) réécrire tout le code qui l'a utilisé avant JSON et YAML, ou (2) le sucer et faire la bêtise. Beaucoup de gens perpétuent également des cycles de violence. Cela ne prouve pas la valeur inhérente de la pratique.
Parthian Shot
5
Essayez JSON pour un document réel (page de manuel, Knuth, Hamlet, etc.). Vous comprendrez alors pourquoi XML est essentiel. C'est un espace où JSON est nul (allez-y, essayez). L'utilisation de l'une ou de l'autre dans l'espace de conception de l'autre est discutable. Les problèmes liés à l’utilisation de XML dans l’espace JSON sont principalement la verbosité et la rapidité, tandis que les problèmes liés à l’utilisation de JSON dans l’espace XML impliquent généralement une portabilité problèmes d’interprétation qui nécessitent beaucoup d’efforts humains à résoudre. Utilisez le bon outil pour votre travail.
TextGeek
XML est seulement mauvais parce que beaucoup de gens en abusent pour des raisons pour lesquelles ils n’ont pas été conçus Si vous n'avez pas besoin que vos données soient facilement extensibles (c'est-à-dire que le schéma est utilisé par plusieurs parties qui ont besoin d'interopérer, plutôt que dicté de manière centralisée par une partie faisant autorité), et si vos données ne sont pas un document (c'est-à-dire si DOM ont été une mauvaise abstraction de vos données), alors XML ne convient pas à ces applications. Lorsque votre domaine problématique relève de la raison pour laquelle XML est conçu, rien d'autre ne correspond à XML. JSON, YAML, etc. sont mal adaptés à l’espace pour lequel XML est réellement conçu.
Lie Ryan

Réponses:

90

Le XML est idéal pour ce à quoi il a été conçu - un protocole de transfert de données lisible par un humain, neutre pour la plate-forme, doté de fonctions permettant de valider la validation des données à un niveau bas. Je doute que quiconque utilise Xml de cette manière ait une véritable plainte. Est-ce le format de fil le plus succint? Non, mais il y a des options pires. Est-ce aussi rapide que de lire votre format binaire personnalisé? Non, mais vos partenaires commerciaux peuvent le lire dans la pile qu'ils utilisent.

Le problème, cependant, est que les humains - en particulier la race connue sous le nom d'architectes d'entreprise - sont méchants et prennent de bonnes choses et les rendent mauvaises. Dans le cas de XML, le début de ce siècle a vu Xml comme le marteau universel pour tous les problèmes informatiques. Saupoudrez un petit motif de la part du comité et vous vous retrouverez avec des monstruosités horribles comme SOAP et oXML . Ce qui ne devrait être souhaité ni sur des ennemis, ni sur des amis, ni sur des collègues.

Wyatt Barnett
la source
15
+1: quiconque a déjà eu à traiter avec EDI souhaite que XML ait été inventé avant que ce désordre ne se produise.
Scott Whitlock
12
+1 Correspond presque exactement à mes pensées. J'ajouterais simplement que pour stocker des données simples et simples, même s'il s'agit d'une hiérarchie (mais pas trop, cela ne se mélange pas bien avec quoi que ce soit ), certains formats fonctionnent tout aussi bien, notamment JSON et YAML. Ce dernier est à mon sens impressionnant en ce qui concerne la lisibilité humaine.
11
Pour paraphraser jwz: "Il existe un certain type de programmeur qui se penchera sur tous les problèmes et dira:" Je sais, je vais utiliser XML. " Maintenant, il a deux problèmes. "
Adam Crossland
13
S'il vous plaît, dites-moi que oXML était conçu comme une blague, comme Brainfuck, Whitespace ou LOLCODE.
Dsimcha
9
@Shamim Hafiz, SOAP est définitivement l’une des pires monstosités jamais créées par l’humanité.
SK-logic
24

XML est juste un outil qui vient dans beaucoup de saveurs et utilise. XML excelle dans certaines choses et aspire les autres. Je pense qu'un des problèmes est que les gens ont vu un XML "d'entreprise" inutilement complexe, avec des espaces de noms et de la merde éparpillés (SOAP, ça vous tente?). La difficulté pour concevoir des formats XML pour les humains consiste à donner un sens réel aux données sans les rendre lues à lire.

L’un des problèmes que rencontrent les gens est que XML étouffe parfois un caractère ou un crochet manquant. Il y a cependant un avantage et un inconvénient à cela. L'avantage est que vous n'avez pas d'ambiguïté comme vous avez avec HTML, où différents cas de syntaxe semi-invalide peuvent être interprétés différemment.

L'inconvénient est qu'il est un peu plus difficile à écrire et à apprendre. Je conviens qu’il ya lieu de dire que le Web n’aurait pas été aussi grand si le code HTML était aussi strict que le XML, mais je dirais aussi que nous serions heureux de le faire aujourd’hui. :)

Aussi, ne l'utilisez pas pour tout simplement parce que vous pouvez, avoir le sens et le jugement pour l'appliquer correctement. Si tout ce que vous avez est XML, vous avez tendance à toujours être une transformation XSLT loin de ce que vous voulez. :)

Je dirais que le format ne compte vraiment que lorsque les humains doivent interagir avec lui. Si vous écrivez un programme qui sérialise quelque chose et l'envoie quelque part où il doit être consommé par un autre de vos programmes, qui se soucie de son apparence tant que c'est aussi efficace que possible? Utilisez un format binaire ou des lapins et des licornes pour tous mes soucis.

Avantages de XML

  • Couvre beaucoup de cas marginaux que YAML et JSON ne font pas
  • Il existe d’excellents outils d’analyse et de validation de XML dans un grand nombre de plates-formes et de langages différents.
  • XML peut facilement et puissamment être transformé en un autre format (via des choses comme XSLT)
  • Les documents XML raisonnables sont faciles à lire et à modifier pour les humains; ne me dis pas que JSON est plus facile, ce n'est pas :)
  • XML se décrit lui-même dans une certaine mesure, c’est-à-dire qu’il contient directement des informations sur sa structure et sa signification (contrairement à la plupart des formats binaires)
  • Manipulation de l'encodage
  • Agnostique des blancs, ce qui facilite l'utilisation multiplateforme
  • Se casse s'il n'est pas bien formé (garantit que les données sont structurellement correctes)
  • Ce n'est pas SGML

Les inconvénients

  • Verbeux
  • Ce n'est pas aussi rapide d'analyser que binaire
  • Se casse s'il n'est pas bien formé (bloque votre application)

Bonnes utilisations

  • Fichiers de configuration
  • Formats d'échange de données
  • Formats de fichier résilients de version
  • Stockage de documents dans des bases de données

Pas si bons usages

  • Formats de transfert de données
  • Sérialiser des objets
  • Stocker des données relationnelles dans des bases de données
  • Format de fichier pour les scénarios d'E / S hautes performances
Homde
la source
13
Je doute que les "fichiers de configuration" soient dans "bonnes utilisations". Ce ne sont pas des données, mais des instructions.
mardi
3
Je suis avec @ daknøk ici - je ne peux pas compter le nombre de fois où j'ai dû passer énormément de temps à identifier un bogue de configuration dans un tas de lignes de fichier XML qui spécifie l'injection de dépendance, qui était basée sur une petite faute de frappe dans un attribut XML.
Gjallar
3
Si de mauvaises données bloquent une application, est-ce que ce sont les données qui posent problème?
James Snell
4
Tout format de fichier mal formé / corrompu risque de bloquer les logiciels endommagés. Donc, XML n'est pas le coupable ici ... juste votre application. Sinon, bon post.
Thomas Eding
3
Pourriez-vous développer "Couvre beaucoup de cas marginaux que YAML et JSON ne font pas"?
Trevor Hickey
14

Jeff Atwood a un très bon billet sur XML: The Angle Bracket Tax à ce sujet si vous voulez une source en parler.

Les utilisations les plus courantes que j'ai pour cela sont:

  • Les services se parlent. Par exemple, un site Web utilisant un système de gestion de contenu doit envoyer des données à un système de gestion de la relation client, à l'aide de XML.

  • Stockage de configuration. Web.config et app.config étant des exemples courants, les scripts nAnt peuvent également utiliser du code XML.

Je ne pense pas que ce soit optimal mais cela seul ne le rend pas mauvais pour moi.

JB King
la source
11

Deux raisons:

  1. Il y a énormément de mauvais programmeurs. XML est peut-être mauvais, mais il est aussi simple (au moins superficiel) et rend très facile l’écriture de mauvais logiciels. Sorta comme VB.
  2. La plupart des personnes qui prennent ces décisions ne sont pas des programmeurs, mais des types d'entreprise qui ont seulement entendu dire que "tout le monde utilise XML" et qui ont décidé qu'ils souhaitaient que leur produit utilise également XML.
Maçon Wheeler
la source
Quels points absurdes et totalement inutiles. 1) XML est loin d’être mauvais et n’a absolument rien à voir avec la qualité du logiciel que les gens écrivent qu’ils le choisissent ou non, j’ai vu de très bons programmeurs VB, ce qui implique que si vous utilisez VB, vous écrivez réellement un mauvais logiciel. juste idiot parce qu'il y a un décalage complet entre la façon dont vous écrivez un logiciel et ce que vous utilisez pour l'écrire. 2) Encore une autre fausse hypothèse: choisir XML est une bonne chose et la plupart des gens qui la choisissent pour le meilleur ou pour le pire sont certainement des programmeurs. XML n'est pas une solution miracle, mais c'est bon pour certaines choses.
Eyal Solnik
2
@EyalSolnik: Certaines personnes, face à un problème, se disent «Je sais, je vais utiliser XML».<Problem:Worsening> <Problem:TimeDescription>Now</Problem:TimeDescription> <Problem:Posessive>they have</Problem:Posessive> <Problem:Quantity>many, many</Problem:Quantity> <Problem:WorseningDescription>more problems</Problem:WorseningDescription> </ProblemWorsening>
Mason Wheeler
3
Ce n’est pas parce que les gens abusent que quelque chose ne signifie pas que la technologie elle-même est mauvaise que vous pouvez voir le même syndrome dans de nombreux endroits.
Eyal Solnik
8

J'entends d'habitude les termes "ballonné" et "lent" ballottés.

Ce n'est pas la syntaxe la plus compacte, mais c'est clairement la plus expressive. Lisible par l'homme? Cela dépend de la façon dont vous concevez votre langue. La plupart des gens ne conçoivent pas de langage XML, ils se contentent de sérialiser des objets au format XML.

… Pourquoi tant de gens l'utilisent-ils?

C'est omniprésent. Vous pouvez interroger une base de données XML avec XQuery, transformer les résultats avec XSLT en XHTML ou Atom, obtenir le format Atom ou un autre format XML à partir d'autres services Web, obtenir le code XML des utilisateurs utilisant XForms, le valider avec XMLSchema, Relax NG ou Schematron, le traiter avec XProc, enregistrez-le dans la base de données avec XQuery Update. Tous ces outils comprennent le langage XML, il n'est donc pas nécessaire de mapper des représentations différentes.

XML n'est pas une technologie de sérialisation, c'est un ensemble d'informations à usage général.

Max Toro
la source
... et nous nous demandons depuis des années pourquoi, pour chrissakes, SOAP a été construit sur XML.
JensG
6

Ici, nous l'utilisons pour l'échange de données entre différents systèmes réalisés par différents fournisseurs avec différentes représentations internes. Nous construisons un système de transformation / échange XML pour transférer les données dans les deux sens. Cela fonctionne bien pour cela.

XML n'est pas intrinsèquement mauvais, mais je reconnais que concevoir une "bonne" solution à l'aide de XML n'est pas trivial.

FrustratedWithFormsDesigner
la source
5

"L'essence de XML est la suivante: le problème qu'il résout n'est pas difficile, et cela ne résout pas bien le problème." - Phil Wadler, POPL 2003

Mon opinion personnelle est que tant que vous ne vous souciez pas de la validation, des schémas, des XSLT et du reste des trucs laids et que vous gardez la taille des fichiers réduite (sinon, l'analyse devient lente), vous pouvez trouver de bonnes utilisations de XML (un exemple sert à configurer votre application au lieu d’utiliser des fichiers INI).

Sakis
la source
4

D'après mon expérience, les gens se plaignent principalement de la façon dont ils sont utilisés, pas de la technologie elle-même.

Les bits lents et lents sur lesquels les gens se plaignent sont généralement les bibliothèques / méthodes utilisées pour extraire les informations.

Je l'utilise pour stocker de petites quantités d'informations structurées que je souhaite stocker sur disque (sans base de données ni sérialisation binaire), ou transmis à une autre application (qui décrit également SOAP).

Steven Evers
la source
2

C'est bon parce que:

C'est une "interface" standard que plusieurs systèmes hétérogènes peuvent utiliser pour communiquer avec. Et est "humain" lisible (en quelque sorte, essayez de regarder 5 MB XML)

C'est mauvais parce que:

Sa taille gonflée et plus grande = plus de bande passante = plus $$

Il y a d'autres raisons, tout le monde a un reproche différent ...

Nuit noire
la source
4
@Darknight: Je conteste l' humain lisible en vous lançant des entités Xml ... (pseudo personnel)
Matthieu M.
1
Je ne pense pas que XML est intrinsèquement gonflé - mais ses implémentations le sont. Je trouve XML-RPC particulièrement flagrant.
HorusKol
3
@HorusKol: <advanceAcceptanceIndicator>Y</advanceAcceptanceIndicator>Le ratio données / balisage est si bas ... J'appelle cela "gonflé". JSON, par exemple, ne serait que la moitié gonflée: advanceAcceptanceIndicator: "Y". Il existe également le fait que le texte entre les balises est valide. Par conséquent, lors de la lecture de XML, vous devez décider quoi faire avec cette procédure crue \n\t\t\t, et la solution consiste généralement à simplement l'ignorer, car cela ne vous a jamais vraiment intéressé.
Matthieu M.
1
@HorusKol: Oui, mais je n'ai jamais dit que c'était une valeur booléenne, mais il se trouve qu'il ne s'agit que d'un seul caractère :) L'utilisation d'attribut ici ( value?) Serait probablement supérieure aussi, car les gens pourraient être tentés d'insérer des espaces entre deux Mots clés.
Matthieu M.
1
"Sa taille plus large et gonflée = plus de bande passante = plus de $$" Je suppose que la compression n'a pas encore été inventée là où vous êtes.
Andy
2

Comme pour toute autre technologie: il existe de nombreux outils et bibliothèques.

Je n'aime pas le XML, surtout parce que c'est génial, quand les gens disent que c'est lisible par l'homme, ils plaisantent, je pense, ou n'ont jamais vraiment lu un xml quand on a essayé d'incorporer du xml dans un attribut ... les entités xml le rendent vraiment illisible. En outre, il est étonnant de constater combien d'espace est gaspillé à cause de la balise d'extrémité redondante et de la possibilité de mélanger du texte libre et des données ...

Mais:

  • XML peut être spécifié (xsd) et des outils sont disponibles pour vérifier la conformité des données XML.
  • de nombreux outils (éditeurs de texte et autres) prennent en charge XML
  • beaucoup de bibliothèques (dans à peu près tous les langages de programmation) supportent xml

Il a également l'avantage de la préséance, la plupart du temps. Lorsque vous fournissez déjà des services Web au format XML et que vous demandez un nouveau service ... cela se fera probablement au format XML, car c'est ce que vous savez.

Matthieu M.
la source
5
XML est plus lisible que les données binaires ou délimitées par des virgules ou des positions.
FrustratedWithFormsDesigner
Seulement pour un utilisateur naïf. Si je dois analyser visuellement quelques centaines d'enregistrements pour en trouver un qui en manque, je préférerais beaucoup rechercher des colonnes vierges dans un bloc d'enregistrements de longueur fixe plutôt que de parcourir une multitude d'éléments et d'attributs à la recherche d'un tag vide.
TMN
1
@FrustratedWithFormsDesigner: cela dépend vraiment des données disponibles. XML intègre la nature de l'information à proximité de l'information proprement dite. Si vous examinez les langages de programmation fonctionnels, vous verrez des choses telles que (Haskell) :, data Person = Person { surname :: String, firstName :: String, age :: Int }si je vois alors Person "Doe" "John" 42qu'il est aussi lisible, et évite beaucoup de choses cruelles, pourtant elles sont plus proches des virgules.
Matthieu M.
1
Ok, votre exemple était plus facile à lire sans le balisage, mais des exemples triviaux (je dirais moins de 8 ou 9 éléments de données) peuvent être réalisés pour prendre en charge tous les formulaires (sauf peut-être binaire). Les flux de données à partir du grand système sont créés en tant que chaînes délimitées par des positions (il s’agit pour l’essentiel de codes numériques). Ils sont beaucoup plus faciles à lire, à déboguer et à gérer après avoir été transformés en XML. Comme tu l'as dit, ça peut dépendre ...
FrustratedWithFormsDesigner
@FrustratedWithFormsDesigner: Oui, c'est exactement ce que je veux dire. Cela dépend, mais comme il existe un écosystème aussi riche pour XML et qu'il est plus facile de ne gérer qu'un seul ensemble d'outils / bibliothèques, les utilisateurs utilisent généralement XML pour tout. Personnellement, je préfère JSon au XML, mais encore une fois sans indentation, c'est compliqué: p
Matthieu M.
-1

XML est un mauvais choix pour les fichiers qui doivent être conservés par des humains. Il n'y a pas de séparation visuelle entre le balisage et le contenu, ce qui rend la lecture difficile. Il est fastidieux d’écrire correctement sans éditeur spécial. Toute erreur dans un document XML est fatale; un document XML ne peut pas être traité partiellement. Lorsqu'un fichier XML n'est pas valide, le message d'erreur résultant est souvent inutile.

Pour tout fichier devant être géré par un humain, je préférerais utiliser un code JSON, YAML ou un code source dans un langage interprété (Python, Ruby, Groovy, etc.). Nous avons constaté que l’utilisation de Groovy MarkupBuilder constitue un excellent moyen de créer une configuration XML pour le code existant. Un autre bon choix consiste à créer un langage spécifique à un domaine. c'est assez facile à faire avec Ruby, Groovy et beaucoup d'autres langues.

Kevin Cline
la source
8
Je pense que vous manquez le point de XML, le balisage est contenu. Le but de XML est de décrire la signification de vos données. Par exemple, si vous avez un numéro de téléphone, le marquer comme un numéro de téléphone fixe ou un numéro de téléphone ajoute un contexte que d'autres peuvent utiliser. Vous pouvez également ajouter une étiquette de téléphone autour du texte (vous pouvez appeler ce numéro sur un téléphone portable). En ce qui concerne vos autres points, je suis également en désaccord. La création de documents XML est généralement assez simple. Les messages d'erreur sont toujours liés à wellformedness et je vais prendre l'édition XML à la main sur JSON tous les jours
Homde
@ Konrad votre exemple de téléphone serait valable pour HTML.
Florian F
"Toute erreur dans un document XML est fatale; un document XML ne peut pas être traité en partie." Oui, c'est un gros par rapport au point de XML.
Andy
@Andy C'est assez inutile si le XML a été écrit par un humain et que l'application dit simplement "faux!". Un éditeur humain doit connaître la ligne où l'erreur a été détectée.
kevin cline
N'importe quel nombre d'outils vous dit exactement sur quelle ligne et souvent sur quel caractère l'erreur est détectée. Outils XML dans NotePad ++ par exemple. .Net vous dira exactement où votre fichier .config est également faux. Si vous parlez d'une API, l'un des avantages du XML est que le développeur de l'API peut également fournir un XSD, ce qui, outre le fait de garantir une syntaxe XML valide, peut également vous indiquer si certains éléments n'appartiennent pas à la liste, s'il le faut. être un élément de cet élément, etc. Json manuscrit est beaucoup plus facile à bousiller.
Andy
-2

L'analyse est relativement facile tout en étant lisible par l'homme.

Et quelques bons analyseurs (par exemple Xerces {c ++}) sont facilement disponibles.

Simon
la source
2
Eh bien, c'est facile tant que les documents sont petits. Si vous devez analyser des documents trop volumineux pour tenir raisonnablement dans la mémoire, la situation devient sombre.
TMN
Je remets en question la partie de la lisibilité humaine. Lire un fichier XML par rapport à un fichier JSON équivalent nécessite beaucoup trop d’efforts.
cmaster