Wenn XML so schlecht ist… warum verwenden so viele Leute es? [geschlossen]


37

Ich verstehe den Zweck von XML, aber ich höre immer Leute, die sich darüber beschweren, wie SCHLECHT es ist. Ich verstehe nicht wirklich, was daran so schlimm ist? Normalerweise höre ich die Begriffe "aufgebläht" und "langsam" herumwerfen.

Aber ich denke als Programmierer, wofür verwenden Sie es hauptsächlich? Und halten Sie es wirklich für "schlecht" ... denn wenn ja, wird es von sehr vielen Menschen zum Transportieren von Daten verwendet ...


1
Ihre Antwort ist in der Frage. Die Leute benutzen es immer noch, weil die Leute es benutzt haben, und die Optionen sind (1) den gesamten Code umzuschreiben, der es vor JSON und YAML benutzt hat, oder (2) es aufzusaugen und das Dumme zu tun. Auch viele Menschen setzen immer noch Gewaltzyklen fort. Das beweist nicht den inhärenten Wert der Praxis.
Parthian Shot

5
Testen Sie JSON für ein aktuelles Dokument (Manpage, Knuth, Hamlet usw.). Sie werden dann verstehen, warum XML wichtig ist. Dies ist ein Bereich, in dem JSON nervt (probieren Sie es aus). Es ist fraglich, eines im Design-Space des anderen zu verwenden. Die Probleme bei der Verwendung von XML im JSON-Bereich sind hauptsächlich Ausführlichkeit und Geschwindigkeit, während die Probleme bei der Verwendung von JSON im XML-Bereich in der Regel Portabilität (versuchen Sie, mit einem Freund zusammenzuarbeiten, der ein Buch in JSON erstellt hat, aber auf seine eigene Weise), Integrität und Aktualität umfassen Interpretationsprobleme, deren Behebung viel menschlichen Aufwand erfordert. Verwenden Sie das richtige Werkzeug für Ihre Arbeit.
TextGeek

XML ist nur schlecht, weil viele Leute es für Dinge missbrauchen, für die es nicht entwickelt wurde. Wenn Sie nicht möchten, dass Ihre Daten leicht erweiterbar sind (dh, das Schema wird von mehreren Parteien verwendet, die zusammenarbeiten müssen, anstatt zentral von einer maßgeblichen Partei vorgegeben zu werden), und wenn Ihre Daten kein Dokument sind (dh wenn DOM dies tun würde) Wenn Ihre Daten schlecht abstrahiert wurden, ist XML für diese Anwendungen nicht geeignet. Wenn Ihre Problemdomäne unter das fällt, für das XML entwickelt wurde, stimmt nichts anderes mit XML überein. JSON, YAML usw. eignen sich nur schlecht für den Bereich, für den XML wirklich entwickelt wurde.
Lie Ryan

Antworten:


90

XML eignet sich hervorragend für das, was es sein soll - ein plattformneutrales, für Menschen lesbares Datenübertragungsprotokoll mit einigen Funktionen zur Durchsetzung der Datenvalidierung auf niedriger Ebene. Ich bezweifle, dass jemand, der XML auf diese Weise verwendet, eine echte Beschwerde hat. Ist es das schnellste Drahtformat? Nein, aber es gibt schlechtere Möglichkeiten. Ist es so schnell wie das Lesen Ihres benutzerdefinierten Binärformats? Nein, aber Ihre Geschäftspartner können es in jedem Stapel lesen, den sie verwenden.

Das Problem ist jedoch, dass Menschen - insbesondere die als Unternehmensarchitekten bekannte Rasse - böse sind und gute Dinge nehmen und sie schlecht machen. Im Fall von Xml war Xml zu Beginn dieses Jahrhunderts der universelle Hammer für jedes IT-Problem. Streuen Sie ein wenig Design von Committee ein, und Sie haben schreckliche Monstrositäten wie SOAP und oXML . Weder von denen auf Feinde, egal Freunde oder Kollegen gewünscht werden sollte.


15
+1 - Jeder, der sich jemals mit EDI befasst hat, wünscht sich nur, XML wäre erfunden worden, bevor dieses Chaos auftrat.
Scott Whitlock

12
+1 Entspricht fast genau meinen Gedanken. Ich möchte nur hinzufügen, dass zum Speichern von einfachen und einfachen Daten, auch wenn es sich um hierarchische Daten handelt (aber nicht zu tief, die mit nichts gut harmonieren ), bestimmte Formate genauso gut funktionieren - insbesondere JSON und YAML. Letzteres ist in Bezug auf die menschliche Lesbarkeit unglaublich.

11
Um jwz zu paraphrasieren: "Es gibt eine bestimmte Art von Programmierer, der jedes Problem untersucht und sagt:" Ich weiß, ich werde XML verwenden. " Jetzt hat er zwei Probleme. "
Adam Crossland

13
Bitte sag mir, oXML war als Witz gedacht, wie Brainfuck oder Whitespace oder LOLCODE.
DSIMCHA

9
@Shamim Hafiz, SOAP ist definitiv eines der schlimmsten Monster, die jemals von der Menschheit gezüchtet wurden.
SK-logic

24

XML ist nur ein Werkzeug, das es in vielen Varianten und Anwendungen gibt. XML zeichnet sich in einigen Dingen aus und in anderen. Ich denke, eines der Probleme ist, dass die Leute "Enterprise" XML gesehen haben, das unnötig komplex mit Namespaces und Mist ist (SOAP, irgendjemand?). Der Trick beim Entwerfen von XML-Formaten für den Menschen besteht darin, Daten eine echte Bedeutung zu verleihen, ohne sie für das Lesen zu überfordern.

Eines der Dinge, mit denen die Leute Probleme haben, ist, dass XML manchmal ein Zeichen oder eine fehlende Klammer verschluckt. Es gibt jedoch auch einen Vor- und einen Nachteil. Der Vorteil ist, dass Sie keine Mehrdeutigkeiten wie bei HTML haben, bei denen verschiedene Fälle von semi-ungültiger Syntax unterschiedlich interpretiert werden können.

Der Nachteil ist, dass es etwas schwieriger zu schreiben und zu lernen ist. Ich stimme zu, es muss argumentiert werden, dass das Web nicht so schnell zu groß geworden wäre, wenn HTML so streng wie XML wäre, aber ich würde auch argumentieren, dass wir uns freuen würden, wenn es heute so wäre. :)

Verwenden Sie es auch nicht für alles, nur weil Sie den Sinn und das Urteilsvermögen haben, es angemessen anzuwenden. Wenn Sie nur XML haben, sind Sie in der Regel immer eine XSLT-Transformation, die nicht Ihren Vorstellungen entspricht. :)

Ich würde argumentieren, dass das Format nur dann wirklich wichtig ist, wenn Menschen damit interagieren müssen. Wenn Sie ein Programm schreiben, das etwas serialisiert und irgendwohin sendet, wo es von einem anderen Ihrer Programme verwendet werden soll, wen interessiert es dann, wie es aussieht, solange es so effizient wie möglich ist? Verwenden Sie ein Binärformat oder Hasen und Einhörner für alles, was mir wichtig ist.

Vorteile von XML

  • Deckt viele Randfälle ab, die YAML und JSON nicht haben
  • Es gibt hervorragende Tools zum Parsen und Validieren von XML in einer Reihe verschiedener Plattformen und Sprachen
  • XML kann einfach und leistungsstark in ein anderes Format umgewandelt werden (durch Dinge wie XSLT)
  • Angemessene XML-Dokumente sind für den Menschen einfach zu lesen und zu bearbeiten. Sag mir nicht, JSON ist einfacher, es ist nicht :)
  • XML ist zu einem gewissen Grad selbstbeschreibend, dh es enthält direkt Informationen zu seiner Struktur und Bedeutung (im Gegensatz zu den meisten Binärformaten).
  • Behandelt die Codierung
  • Whitespace-Agnostiker, der die plattformübergreifende Verwendung erleichtert
  • Bricht ab, wenn es nicht wohlgeformt ist (Stellt sicher, dass die Daten strukturell korrekt sind)
  • Es ist nicht SGML

Nachteile

  • Ausführlich
  • Es ist nicht so schnell wie binär zu analysieren
  • Bricht ab, wenn es nicht wohlgeformt ist (stürzt Ihre Anwendung ab)

Gute Verwendungen

  • Konfigurationsdateien
  • Datenaustauschformate
  • Versionssichere Dateiformate
  • Dokumente in Datenbanken speichern

Nicht so gut verwendet

  • Datenübertragungsformate
  • Objekte serialisieren
  • Speichern relationaler Daten in Datenbanken
  • Dateiformat für leistungsstarke E / A-Szenarien

13
Ich bezweifle, dass "Konfigurationsdateien" unter "Verwendung" stehen sollten. Sie sind keine Daten, sondern Anweisungen.
daknøk

3
Ich bin mit @ daknøk hier - ich kann nicht zählen, wie oft ich sehr viel Zeit damit verbracht habe, einen Konfigurationsfehler in einer hunderte Zeilen langen XML-Datei herauszufinden, die die Abhängigkeitsinjektion angibt, die auf einem kleinen Tippfehler basiert ein XML-Attribut.
Gjallar

3
Wenn schlechte Daten eine App zum Absturz bringen, sind es dann die Daten, die ein Problem haben?
James Snell

4
Jedes Dateiformat, das fehlerhaft oder beschädigt ist, kann zum Absturz beschädigter Software führen. XML ist hier also nicht der Schuldige ... nur Ihre Anwendung. Ansonsten gute Post.
Thomas Eding

3
Könnten Sie auf "Deckt viele Randfälle ab, die YAML und JSON nicht haben" erweitern?
Trevor Hickey

14

Jeff Atwood hat einen ziemlich guten Blogeintrag bei XML: The Angle Bracket Tax, wenn Sie möchten, dass eine Quelle darüber spricht.

Die häufigsten Verwendungen, die ich dafür habe, sind:

  • Dienstleistungen miteinander zu reden. Beispielsweise muss eine Website, die ein Content-Management-System verwendet, einige Daten an ein Kundenbeziehungs-Management-System senden, und dies erfolgt mit XML.

  • Konfigurationsspeicher. Web.config und app.config sind gängige Beispiele, aber nAnt-Skripte können auch XML verwenden.

Ich denke nicht, dass es optimal ist, aber das allein macht es für mich nicht schlecht.


11

Zwei Gründe:

  1. Es gibt eine Menge schlechter Programmierer. XML mag schlecht sein, aber es ist auch einfach (zumindest oberflächlich) und macht es sehr einfach, schlechte Software zu schreiben. Sorta wie VB.
  2. Viele Leute, die diese Entscheidungen treffen, sind keine Programmierer, sondern Unternehmenstypen, die nur gehört haben, dass "jeder XML verwendet", und daher entscheiden, dass auch ihr Produkt XML verwenden soll.

Was für ein absurder und völlig nutzloser Punkt. 1) XML ist alles andere als schlecht und es hat absolut nichts mit der Qualität der Software zu tun, die Leute schreiben, ob sie es wählen oder nicht. Ich habe ziemlich gute VB-Programmierer gesehen, was bedeutet, dass wenn Sie VB verwenden, Sie tatsächlich schlechte Software schreiben Einfach albern, weil es eine völlige Trennung zwischen der Art und Weise, wie Sie Software schreiben, und der Art und Weise gibt, mit der Sie sie schreiben. 2) Eine weitere falsche Annahme ist, dass die Wahl von XML großartig ist und die meisten Leute, die es zum Guten oder Schlechten wählen, sicherlich Programmierer sind. XML ist kein Wundermittel, aber es ist gut für bestimmte Dinge.
Eyal Solnik

2
@EyalSolnik: Einige Leute denken, wenn sie mit einem Problem konfrontiert werden: "Ich weiß, ich werde XML verwenden."<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
Nur weil die Leute etwas missbrauchen, heißt das nicht, dass die Technologie selbst schlecht ist. Sie können das gleiche Syndrom an vielen Orten beobachten.
Eyal Solnik

8

Normalerweise höre ich die Begriffe "aufgebläht" und "langsam" herumwerfen.

Es ist nicht die kompakteste Syntax, aber eindeutig die ausdrucksstärkste. Für Menschen lesbar? hängt davon ab, wie Sie Ihre Sprache gestalten. Die meisten Benutzer entwerfen keine Sprache für XML, sondern serialisieren Objekte nur als XML.

… Warum benutzen so viele Leute es?

Es ist allgegenwärtig. Sie können eine XML-Datenbank mit XQuery abfragen, die Ergebnisse mit XSLT als XHTML oder Atom transformieren, Atom oder ein anderes XML-Format von anderen Webdiensten abrufen, XML von Benutzern mit XForms abrufen, mit XMLSchema, Relax NG oder Schematron validieren und verarbeiten XProc, speichern Sie es mit XQuery Update wieder in der Datenbank. Alle diese Tools verstehen XML, sodass keine Zuordnung zwischen verschiedenen Darstellungen erforderlich ist.

XML ist keine Serialisierungstechnologie, sondern ein allgemeiner Informationssatz.


... und wir fragen uns seit Jahren, warum SOAP um Himmels willen auf XML basiert.
JensG

6

Hier verwenden wir es für den Datenaustausch zwischen verschiedenen Systemen verschiedener Hersteller mit unterschiedlichen internen Darstellungen. Wir bauen ein XML-Transformations- / Austauschsystem auf, um die Daten hin und her zu transportieren. Dafür funktioniert es gut.

XML ist von Natur aus nicht schlecht, aber ich gebe zu, dass das Entwerfen einer "guten" Lösung mit XML nicht trivial ist.


5

"Die Essenz von XML ist folgende: Das Problem, das es löst, ist nicht schwer und es löst das Problem nicht gut." - Phil Wadler, POPL 2003

Meine persönliche Meinung ist, dass Sie, solange Sie sich nicht um Validierung, Schemata, XSLTs und den Rest hässlicher Dinge kümmern und die Größe der Dateien klein halten (ansonsten wird das Parsen langsam), einige gute Verwendungen von XML finden können (ein Beispiel) dient zur Konfiguration Ihrer Anwendung anstelle der Verwendung von INI-Dateien.


4

Nach meiner Erfahrung beschweren sich die Leute hauptsächlich über die Art und Weise, wie sie eingesetzt werden, nicht über die Technologie selbst.

Die aufgeblähten und langsamen Teile, über die sich die Leute beschweren, sind normalerweise die Bibliotheken / Methoden, die zum Abrufen von Informationen verwendet werden.

Ich verwende es zum Speichern kleiner Mengen strukturierter Informationen, die ich auf der Festplatte speichern möchte (ohne Datenbank oder binäre Serialisierung), oder um sie an eine andere Anwendung weiterzuleiten (die im Wesentlichen auch SOAP beschreibt).


2

Es ist gut, weil:

Es ist eine Standard- "Schnittstelle" , mit der mehrere heterogene Systeme kommunizieren können. Und ist "menschlich" lesbar (versuchen Sie es mit 5 MB XML)

Es ist schlecht, weil:

Sein aufgeblähtes, größeres = mehr Bandbreite = mehr $$

Es gibt andere Gründe, jeder hat eine andere Beschwerde ...


4
@ Darknight: Ich fordere den lesbaren Menschen heraus, indem ich Xml- Entities auf dich wirfe ... (persönlicher Ärger)
Matthieu M.

1
Ich denke nicht, dass XML von Natur aus aufgebläht ist - aber Implementierungen davon sind es. Ich finde XML-RPC besonders ungeheuerlich, wenn es um unnötiges Aufblähen geht.
HorusKol

3
@ HorusKol: <advanceAcceptanceIndicator>Y</advanceAcceptanceIndicator>Das Verhältnis Daten / Aufschlag ist so gering ... ich nenne das "aufgebläht". JSon zum Beispiel wäre nur die Hälfte aufgebläht: advanceAcceptanceIndicator: "Y". Es gibt auch die Tatsache, dass Text zwischen Tags gültig ist. Wenn Sie also XML lesen, müssen Sie entscheiden, was Sie mit dieser Cruft tun möchten \n\t\t\t, und die Lösung besteht im Allgemeinen darin, sie einfach zu ignorieren, da Sie anfangs nie wirklich daran interessiert waren.
Matthieu M.

1
@ HorusKol: Es würde, aber ich habe nie gesagt, dass es ein boolescher Wert ist, es ist einfach ein einzelnes Zeichen :) Die Verwendung des Attributs hier ( value?) Wäre wahrscheinlich auch überlegen, da die Leute versucht sein könnten, Leerzeichen zwischen zwei einzufügen Stichworte.
Matthieu M.

1
"Seine aufgeblähte, größere Größe = mehr Bandbreite = mehr $$" Ich denke, die Komprimierung wurde noch nicht erfunden, wo Sie sich gerade befinden.
Andy

2

Wie bei jeder anderen Technologie gibt es viele verfügbare Tools und Bibliotheken.

Ich mag XML nicht, vor allem, weil es irre ist, wenn Leute sagen, es ist von Menschen lesbar, sie scherzen, denke ich, oder sie haben nie wirklich eine XML gelesen, als man versucht hat, XML in ein Attribut einzubetten ... die XML-Entities machen es wirklich unleserlich. Darüber hinaus ist es erstaunlich, wie viel Speicherplatz aufgrund des redundanten End-Tags und der Möglichkeit, freien Text und Daten zu mischen, verschwendet wird ...

Aber:

  • XML kann angegeben werden (xsd) und es stehen Tools zur Verfügung, die die Konformität von XML-Daten überprüfen
  • Viele Tools (Texteditoren und ähnliches) unterstützen XML
  • Viele Bibliotheken (in fast jeder Programmiersprache) unterstützen XML

Es hat auch den Vorteil, dass es meistens Vorrang hat. Wenn Sie bereits Web-Services in XML bereitstellen und nach einem neuen Service gefragt werden, geschieht dies wahrscheinlich in XML, da Sie das wissen.


5
XML ist lesbarer als binäre oder positions- oder kommagetrennte Daten.
FrustratedWithFormsDesigner

Nur für einen naiven Benutzer. Wenn ich ein paar hundert Datensätze visuell nach Datensätzen durchsuchen muss, bei denen einige Daten fehlen, suche ich lieber nach leeren Spalten in einem Block von Datensätzen mit fester Länge, als durch einen Morast von Elementen und Attributen zu waten, um nach einem leeren Tag zu suchen.
TMN

1
@FrustratedWithFormsDesigner: Es hängt wirklich von den vorliegenden Daten ab. XML bettet die Art der Informationen in die Nähe der eigentlichen Informationen ein. Wenn Sie sich funktionierende Programmiersprachen ansehen, sehen Sie Dinge wie (Haskell): data Person = Person { surname :: String, firstName :: String, age :: Int }Wenn ich dann sehe, dass Person "Doe" "John" 42es auch lesbar ist, und vermeiden Sie viel Cruft, aber es ist näher an durch Kommas getrennten.
Matthieu M.

1
Ok, Ihr Beispiel war ohne das Markup einfacher zu lesen, aber es können einfache Beispiele (ich würde sagen, weniger als 8 oder 9 Datenelemente) erstellt werden, um alle Formen zu unterstützen (außer vielleicht binär). Datenfeeds vom Mainframe werden als durch Positionen getrennte Zeichenfolgen (und die meisten bestehen nur aus numerischen Codes) erstellt und sind nach der Umwandlung in XML viel einfacher zu lesen, zu debuggen und zu verwalten. Wie Sie sagten, kann es abhängen ...
FrustratedWithFormsDesigner

@FrustratedWithFormsDesigner: Ja, das ist genau mein Punkt :) Es hängt davon ab, aber da XML ein so umfangreiches Ökosystem bietet und es einfacher ist, nur einen Satz von Tools / Bibliotheken zu verwalten, wird XML normalerweise für alles verwendet. Persönlich bevorzuge ich JSon gegenüber XML, aber auch ohne Einrückung ist es chaotisch: p
Matthieu M.

-1

XML ist eine schlechte Wahl für Dateien, die von Menschen gepflegt werden müssen. Es gibt keine visuelle Trennung zwischen dem Markup und dem Inhalt, was das Lesen erschwert. Es ist mühsam, ohne einen speziellen Editor richtig zu schreiben. Jeder Fehler in einem XML-Dokument ist schwerwiegend. Ein XML-Dokument kann nicht teilweise verarbeitet werden. Wenn eine XML-Datei ungültig ist, ist die resultierende Fehlermeldung häufig nicht hilfreich.

Für jede Datei, die von einem Menschen gepflegt werden muss, würde ich JSON, YAML oder Quellcode in einer interpretierten Sprache (Python, Ruby, Groovy usw.) bevorzugen. Wir haben festgestellt, dass die Verwendung von Groovy MarkupBuilder eine großartige Möglichkeit zum Erstellen von XML-Konfiguration für Legacy-Code ist. Eine andere gute Wahl ist das Erstellen einer domänenspezifischen Sprache. Mit Ruby, Groovy und vielen anderen Sprachen ist dies recht einfach.


8
Ich denke, Sie vermissen den Punkt von XML, das Markup ist Inhalt. Der Zweck von XML ist es, die Bedeutung Ihrer Daten zu beschreiben. Wenn Sie beispielsweise eine Telefonnummer als Festnetznummer oder Mobiltelefonnummer kennzeichnen, wird der Kontext hinzugefügt, den andere möglicherweise verwenden. Oder fügen Sie überhaupt ein Telefon-Tag um den Text hinzu (möglicherweise können Sie diese Nummer auf einem Mobiltelefon anrufen). In Bezug auf Ihre anderen Punkte stimme ich ebenfalls nicht zu. Das Erstellen von XML-Dokumenten ist normalerweise recht einfach. Fehlermeldungen beziehen sich immer auf die Form und ich werde jeden Tag die Bearbeitung von XML per Hand über JSON übernehmen
Homde,

@ Konrad Ihr Telefon Beispiel wäre gültig für HTML.
Florian F

"Jeder Fehler in einem XML-Dokument ist schwerwiegend. Ein XML-Dokument kann nicht teilweise verarbeitet werden." Ja, das ist eine große Entsprechung zu XML.
Andy

@Andy Es ist ziemlich nutzlos, wenn das XML vom Menschen geschrieben wurde und die Anwendung nur "falsch" sagt. Ein menschlicher Redakteur muss die Zeile kennen, in der der Fehler erkannt wurde.
Kevin Cline

Eine beliebige Anzahl von Werkzeugen gibt genau an, in welcher Zeile und häufig auf welchem ​​Zeichen der Fehler erkannt wird. XML-Tools in NotePad ++ zum Beispiel. .Net wird Ihnen genau sagen, wo Ihre .config-Datei auch falsch ist. Wenn Sie über eine API sprechen, besteht einer der Vorteile von XML darin, dass der API-Entwickler auch eine XSD bereitstellen kann, die neben der Gewährleistung einer gültigen XML-Syntax auch Aufschluss darüber gibt, ob Elemente vorhanden sind, die nicht dazugehören Sei nur eines dieser Elemente usw. Handgeschriebener Json ist viel einfacher zu vermasseln.
Andy

-2

Das Parsen ist relativ einfach und gleichzeitig für den Menschen lesbar.

Und einige nette Parser (zB Xerces {c ++}) sind leicht verfügbar.


2
Nun, es ist einfach, solange die Dokumente klein sind. Wenn Sie Dokumente analysieren müssen, die zu groß sind, um in den Speicher zu passen, werden die Dinge düster.
TMN

Ich würde den Teil der menschlichen Lesbarkeit in Frage stellen. Das Lesen von XML ist viel zu aufwändig als das Lesen einer entsprechenden JSON-Datei.
cmaster
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.