Quelles sont les faiblesses de XML? [fermé]

StackOverflow https://stackoverflow.com/questions/3580819

Question

Lecture StackOverflow et écouter les podcasts par Joel Spolsky et Jeff Atwood, je commence à croire que de nombreux développeurs détestent en utilisant XML ou au moins essayez d'éviter d'utiliser XML autant que possible pour le stockage ou l'échange de données .

D'autre part, j'aime utiliser XML beaucoup pour plusieurs raisons:

  • sérialisation XML est mis en œuvre dans la plupart des langues modernes et est extrêmement facile à utiliser ,
  • Être plus lent que sérialisation binaire, sérialisation XML est très utile quand il vient à en utilisant les mêmes données de plusieurs langages de programmation ou où il est destiné à être lu et compris, même pour le débogage, par un humaine (JSON, par exemple, est plus difficile à comprendre),
  • supports XML unicode , et lorsqu'il est utilisé correctement, il n'y a aucun problème avec codage différent, caractères, etc.
  • Il y a beaucoup d'outils qui le rend facile de travailler avec des données XML. XSLT est un exemple, le rendant facile à présent et de transformer les données. XPath est un autre, ce qui rend facile à rechercher des données,
  • XML peut être stocké dans certains serveurs SQL, qui permet aux scénarios lorsque des données qui est trop compliqué pour être facilement stockées dans des tables SQL doit être sauvé et manipulé; données JSON ou binaires, par exemple, ne peuvent pas être manipulées par SQL directement (sauf manipulant des chaînes, ce qui est fou dans la plupart des situations),
  • XML ne nécessite aucune application à installer. Si je veux que mon application à utiliser une base de données, je dois installer un serveur de base de données d'abord. Si je veux que mon application à utiliser XML, Je n'ai pas installer quoi que ce soit ,
  • XML est beaucoup plus explicite et extensible que, par exemple, les fichiers de registre de Windows ou INI,
  • Dans la plupart des cas, il y a aucun problème CR-LF , grâce au niveau d'abstraction fourni par XML.

Ainsi, en tenant compte de tous les avantages de l'utilisation de XML, pourquoi tant de développeurs détestent l'utiliser? À mon humble avis, le seul problème avec c'est que:

  • XML est trop bavard et nécessite beaucoup plus de place que la plupart des autres formes de données, en particulier en ce qui concerne l'encodage base64.

Bien sûr, il existe de nombreux scénarios dans lesquels XML ne correspond pas du tout. Le stockage des questions et des réponses de SO dans un fichier XML sur le côté serveur sera tout à fait tort. Ou, lors de l'enregistrement d'une vidéo AVI ou un tas d'images JPG, XML est la pire chose à utiliser.

Mais que d'autres scénarios? Quelles sont les faiblesses de XML?

Pour les personnes qui considèrent que cette question est une vraie question:

Contrairement aux questions comme une nouvelle inventions , ma question une question très claire et clairement expliquer ce que invite les faiblesses d'autres personnes l'expérience lors de l'utilisation XML et pourquoi ils ne l'aiment pas. Il n'invite pas à discuter, par exemple, si XML est bon ou mauvais . Ni ne nécessite de longues discussions; ainsi, les réponses actuelles reçues jusqu'à présent sont courts et précis et fournir suffisamment d'informations que je voulais.

Mais est un wiki, car il ne peut y avoir uniques bonne réponse à cette question.

Selon SO, « pas une vraie question » est une question où «Il est difficile de dire ce qui est posée ici. Cette question est ambiguë, vague, incomplète, ou rhétorique et ne peut répondre raisonnablement dans son courant former. "

  • Ce qui est demandé ici : Je pense que la question elle-même est très claire, et plusieurs paragraphes du texte ci-dessus rend encore plus clair,
  • Cette question est ambiguë, vague, incomplète : Encore une fois, il n'y a rien d'ambigu, ni vague, ni incomplète,
  • ou rhétorique : it est pas: la réponse à ma question n'est pas quelque chose d'évident,
  • et ne peut pas être raisonnablement répondu :. Plusieurs personnes ont déjà donné de grandes réponses à la question, montrant que la question peut répondre raisonnablement

Il semble également tout à fait évident de noter les réponses et déterminer la réponse acceptée. Si la réponse donne de bonnes raisons de ce qui est mal avec XML, il y a des chances que cette réponse sera votée en place, puis acceptée.

Était-ce utile?

La solution

Quelques faiblesses:

  • Il est un peu difficile d'associer les fichiers XML et des ressources externes, ce qui explique pourquoi les nouveaux formats de documents Office utilisent une enveloppe zip qui comprend un fichier xml squelette et les fichiers de ressources regroupés. L'autre possibilité d'utiliser l'encodage base64 est très bavard et ne permet pas un bon accès aléatoire, ce qui apporte un au point suivant:
  • L'accès aléatoire est difficile. Aucune des deux modes traditionnels de la lecture d'un fichier xml -. Construire un DOM ou la lecture de style avant uniquement SAX permettent un accès réellement aléatoire
  • accès en écriture simultanées à différentes parties du fichier est difficile, ce qui explique pourquoi son utilisation dans les manifestes exécutables Windows est sujette aux erreurs.
  • Qu'est-ce que l'encodage fait une utilisation de fichier xml? Strictement parlant vous deviner l'encodage d'abord, puis lire le fichier et vérifiez l'encodage était juste.
  • Il est difficile de portions de version d'un fichier. Par conséquent, si vous voulez fournir versioning granulaire, vous avez besoin de partager vos données. Ce n'est pas seulement un problème de format de fichier, mais aussi en raison du fait que les outils fournissent généralement la sémantique par fichier -. Outils de contrôle de version, les outils de synchronisation comme DropBox, etc

Autres conseils

<xml>
    <noise>
        The
    </noise>
    <adjective>
        main
    </adjective>
    <noun>
        weakness
    </noun>
    <noise>
        of
    </noise>
    <subject>
        XML
    </subject>
    <noise>
        ,
    </noise>
    <whocares>
        in my opinion
    </whocares>
    <noise>
        ,
    </noise>
    <wildgeneralisation>
        is its verbosity
    </wildgeneralisation>
    <noise>
        .
    </noise>
</xml>

Je ne suis pas la bonne personne à demander, comme je suis un grand fan de moi-même xml. Cependant, je peux vous dire une des principales plaintes que je l'ai entendu:

Il est dur à travailler avec. Ici, des moyens durs qu'il prend une API et sachant que vous aurez besoin d'écrire du code relativement bien pour analyser votre xml. Bien que je ne dirais pas que c'est vraiment si difficile, je ne peux qu'être d'accord qu'une langue qui est faite pour décrire des objets, est accessible plus facilement lorsque vous utilisez un langage des objets supports créés dynamiquement.

Je pense qu'en général, la réaction est tout simplement parce que XML est galvaudé.

Cependant, s'il y a un mot que je déteste XML, avec une passion, est namespaces. La perte de productivité autour des problèmes d'espace de noms est horrible.

XML descend de SGML, le grand-grand-papa des langages de balisage. Le but de SGML et par XML d'extension est texte annoter . XML se débrouille bien et dispose d'une large gamme d'outils qui augmentent sa facilité pour une variété d'applications.

Le problème, comme je le vois, est que XML est fréquemment utilisé, et non au texte de annoter, mais pour représenter données structurées , ce qui est une différence subtile mais importante. Sur le plan pratique, des données structurées doit être concis pour diverses raisons. La performance est une évidence, en particulier lorsque la bande passante est limitée. Ceci est probablement l'une des principales raisons pour lesquelles JSON est si populaire pour les applications web. représentation de structure de données Concise sur le moyen de fil une meilleure évolutivité.

Malheureusement, JSON est pas très lisible sans rembourrage supplémentaire des espaces, ce qui est presque toujours omis. D'autre part, si vous avez déjà essayé de modifier un grand fichier XML à l'aide d'un éditeur de ligne de commande, il peut être très gênant aussi bien.

Personnellement, je trouve que YAML frappe un bel équilibre entre les deux extrêmes. Comparer les éléments suivants (copié à partir de yaml.org avec des modifications mineures).

YAML: 

invoice: 34843
  date: 2001-01-23
  billto: &id001
    given: Chris
    family: Dumars
    address:
      lines: |
        458 Walkman Dr.
        Suite #292
      city: Royal Oak
      state: MI
      postal: 48046
  shipto: *id001
  product:
  - sku: BL394D
    quantity: 4
    description: Basketball
    price: 450.00
  - sku: BL4438H
    quantity: 1
    description: Super Hoop
    price: 2392.00
  tax : 251.42
  total: 4443.52
  comments: >
    Late afternoon is best.
    Backup contact is Nancy
    Billsmer @ 338-4338.

XML: 

<invoice>
   <number>34843</number>
   <date>2001-01-03</date>
   <billto id="id001">
      <given>Chris</given>
      <family>Dumars</family>
      <address>
        <lines>
          458 Walkman Dr.
          Suite #292
        </lines>
        <city>Royal Oak</city>
        <state>MI</state>
        <postal>48046</postal>
      </address>
   </billto>
   <shipto xref="id001" />
   <products>
      <product>
        <sku>BL394D</sku>
        <quantity>4</quantity>
        <description>Basketball</description>
        <price>450.00</price>
      </product>
      <product>
        <sku>BL4438</sku>
        <quantity>1</quantity>
        <description>Super Hoop</description>
        <price>2392.00</price>
      </product>
   </products>
   <tax>251.42</tax>
   <total>4443.52</total>
   <comments>
    Late afternoon is best. Backup contact is Nancy Billsmer @ 338-4338
   </comments>
</invoice>

Ils représentent tous deux les mêmes données, mais le YAML est plus de 30% plus petit et sans doute plus facile à lire. Que préféreriez-vous avoir à modifier avec un éditeur de texte? Il existe de nombreuses bibliothèques disponibles pour analyser et émettre YAML (à savoir snakeyaml pour les développeurs Java).

Comme pour tout, le bon outil pour le bon travail est la meilleure règle à suivre.

Mon problème méchant préféré est avec les formats de sérialisation XML qui attribue l'utilisation - comme XAML.

Cela fonctionne: 

<ListBox ItemsSource="{Binding Items}" SelectedItem="{Binding CurrentSelection}"/>

Cela ne: 

<ListBox SelectedItem="{Binding CurrentSelection}" ItemsSource="{Binding Items}"/>

XAML désérialisation attribue des valeurs de propriété en tant qu'elles sont lues à partir du flux XML. Ainsi, dans le second exemple, lorsque la propriété SelectedItem est attribué, n'a pas encore été fixée la ItemsSource du contrôle et la propriété SelectedItem est affecté à un élément qui existe encore savoir.

Si vous utilisez Visual Studio pour créer vos fichiers XAML, tout sera cool, parce que Visual Studio maintient l'ordre des attributs. Mais modifier votre XAML dans certains outil XML qui croit que la recommandation XML quand il dit que l'ordre des attributs est non significatif, et le garçon êtes-vous dans un monde de souffrance.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top