Ist XML überbewertet?
-
Der XML-Hype hat doch stark abgenommen. Vor ein paar Jahren war der ja wirklich unerträglich und jeder musste alles in irgend eine Form in XML verpacken. Die ganzen Buzzwordprädiger wollten alle mit einer "XML Konfigurationsdatei" aufwarten. XML an sich finde ich gar nicht so schlimm. Es hat eben seinen Zweck als Markupsprache und es existieren mehr oder minder brauchbare Technologien um XML. Es ist jedoch nicht sinnvoll als Datensprache und dafür wurde es eben immer missbraucht.
Für das speichern von Daten gibt es aber mittlerweile brauchbare etablierte alternative Formate, wie JSON.
-
Wenn man nicht gerade Bücher schreibt hat XML einen verdammt grottiges Protokoll/Nutzdaten-Verhältnis. Der einzige Grund es zu nutzen wäre für, daß bereits viele Tools dafür erhältlich sind, ich also Zeitsparen kann beim entwickeln.
-
Blue-Tiger schrieb:
@TheCockatrice: abgesehen vom letzten Satz (den ich nich richtig finde, man kann das XML ja noch schnell durch gzip rennen lassen) verstehe ich nicht, was du sagen willst?
tl;dr: Eigentlich wären wir mit einem Binärformat glücklicher. Wir würden zwar über den unleserlichen Schmarrn fluchen, hätten aber keine Probleme mit unpackbarkeit. Ein Binärformat hätte sich aber nie im Leben durchgesetzt, weil man es nicht mit Emacs bearbeiten kann.
-
TheCockatrice schrieb:
Eigentlich wären wir mit einem Binärformat glücklicher. Wir würden zwar über den unleserlichen Schmarrn fluchen, hätten aber keine Probleme mit unpackbarkeit.
das hier z.b: http://en.wikipedia.org/wiki/Type-length-value
aber ich denke, XML lässt sich sehr gut komprimieren, weil es ja unkomprimiert für sehr wenig informationen viele-viele bytes braucht.
-
Das Binärformat ist noch besser komprimierbar, weil von Anfang an weniger Daten da sind, die man komprimieren muss. Zwischen einem 16bit-Wort und "<value>5194</value>" liegen doch Welten.
-
Ja fricky, das gefällt mir auch entschieden besser.
Vielleicht sogar eine Norm, die die gesamte Datenstruktur vorne in der Datei ablegt, sodaß man später seeken kann für das was man braucht!
XML mag ich nicht. Ich mag es überhaupt nicht, wenn ich mich in halbgegessene Modeerscheinungen einarbeiten soll.
Da wird immer von der Wiederverwendbarkeit der OOP geredet - praktisch kommt man dazu aber überhaupt nicht, weil es ja direkt 'proprietär' ist, und 'Normen' grundsätzlich von anderen gemacht werden. Das verleidet einem so langsam alles!
-
Einen leichte Rückbesinnung zu Binärformaten scheint es ja zu geben, wenn man sich Bison oder BERT anschaut. Binärformate haben halt einen besonders schlechten Ruf, weil viel zu oft die Entwickler einfach
fwrite(&einestruct, ...);gemacht haben. An und für sich spricht nichts dagegen, warum diese nicht genauso flexibel wie Textformate sein sollen. Eben mit der einzigen Ausnahme, dass man die nicht mit einem Texteditor bearbeiten kann. Aber wie volkards Beispiel zeigt ist dies für viele Bereiche in denen XML eingesetzt wird ohnehin nicht bedeutsam.TheCockatrice schrieb:
Ein Binärformat hätte sich aber nie im Leben durchgesetzt, weil man es nicht mit Emacs bearbeiten kann.
Klar kann man das mit Emacs http://www.gnu.org/software/emacs/manual/html_node/emacs/Editing-Binary-Files.html
:p
-
Bitsy schrieb:
XML mag ich nicht. Ich mag es überhaupt nicht, wenn ich mich in halbgegessene Modeerscheinungen einarbeiten soll.
Da wird immer von der Wiederverwendbarkeit der OOP geredet - praktisch kommt man dazu aber überhaupt nicht, weil es ja direkt 'proprietär' ist, und 'Normen' grundsätzlich von anderen gemacht werden. Das verleidet einem so langsam alles!Was genau gefällt Dir denn nicht an XML? Klar, über die Syntax lässt sich streiten. Aber ansonsten isses doch super, dass es einen quasi Standard gibt, zu dem massig Tools existieren, so dass man sich ums Serialisieren, Deserialisieren und Parsen nicht mehr selbst kümmern muss.
Und was genau hat Wiederverwendbarkeit der OOP mit XML zu tun? Bist du angepisst, weil es mit XML + seinen Tools schon fertige Lösungen gibt und Du es daher nicht mehr selbst programmieren darfst?
So ist das heute nun mal. Man kann entweder jedes mal das Rad neu erfinden oder man benutzt die fertige Lösung von jemand anderem.
-
Gegenfrage: Was genau hat serialiseren mit XML zu tun?
Natürlich muß man nicht immer das Rad neu erfinden, aber 4-eckige Räder wie XML sollte man schon verbessern. Was mir nicht gefällt hab ich ja schon geschrieben. XMl ist wie Politik: viel Text, wenig Inhalt.
-
Tyrdal schrieb:
XMl ist wie Politik: viel Text, wenig Inhalt.
und was ist, wenn genau das gewünscht ist, man also eine für den Menschen les- und bearbeitbare Datei haben will?
Binärdateien sind platzsparender, das stimmt, aber dafür ist die Struktur fest vorgegeben, sei es durch Feldgrößen oder irgendwelche Stoppcodes. Wenn man selbst der einzige Nutzer der Datei ist aber nicht weiter schlimm
XML hat dann einen Vorteil wenn man eine Baumstruktur abbbilden will oder das Ergebnis an andere Programme weitergeben will bzw mit den Ergebnissen anderer Programme arbeiten muss. Da einigt man sich nur aufs Schema (das muss, das darf, das sollte drin sein) und der Rest ist egal.
Für alles sollte man XML auch nicht einsetzen. Für simple Konfigurationsdateien einer Anwendung ist ini immernoch besser geeignet. Und wer keinen Wert auf Lesbarkeit legt und dafür auf den Speicherplatz achten will, gibts immernoch Binärdateien
-
Tyrdal schrieb:
Gegenfrage: Was genau hat serialiseren mit XML zu tun?
Dachte eigentlich, das sollte klar sein, wenn man über XML diskutiert. So what, siehe:
- XML Data Binding
- SOAP
- Burlap
- usw.Natürlich muß man nicht immer das Rad neu erfinden, aber 4-eckige Räder wie XML sollte man schon verbessern. Was mir nicht gefällt hab ich ja schon geschrieben. XMl ist wie Politik: viel Text, wenig Inhalt.
Ich sagte ja schon, dass die Syntax nicht so glücklich ist. Aber das spielt für viele Anwendungsfälle keine gravierende Rolle. Und es gibt ja längst effizientere Alternativen, siehe JSON.
-
Nachdem Ihr meinen XML-Paste aus einer *.docx überlebt habt, hier der finale Schwachsinn:
http://pastebin.com/m132fba2f
-
Ist doch super. Das passt prima in ne HTTP Message und lässt sich somit problemlos durch die meisten Firewalls kommunizieren.
-
byto schrieb:
Ist doch super. Das passt prima in ne HTTP Message und lässt sich somit problemlos durch die meisten Firewalls kommunizieren.
Äh, HTTP ist egal was es transportiert. XML, Binärdaten, eigene Formate, offene Formate etc.
-
volkard schrieb:
Nachdem Ihr meinen XML-Paste aus einer *.docx überlebt habt, hier der finale Schwachsinn:
http://pastebin.com/m132fba2fKein gutes Beispiel, abgelehnt.
XML-Beispiele von Leuten, die XML nicht verstanden haben und Binaerdaten in XML kapseln, disqualifizieren sich selbst. Genauso wie schlecht geschriebener N00b-Code kein Argument dafuer ist, dass Sprache Foo eine unterlegene Programmiersprache ist.
-
Blue-Tiger schrieb:
Kein gutes Beispiel, abgelehnt.
XML-Beispiele von Leuten, die XML nicht verstanden haben und Binaerdaten in XML kapseln, disqualifizieren sich selbst. Genauso wie schlecht geschriebener N00b-Code kein Argument dafuer ist, dass Sprache Foo eine unterlegene Programmiersprache ist.Danke, mit dieser Aussage könnte man diesen Thread eigentlich schließen, denn ein Großteil der Posts hier sind ...
1. XML ist ein Dateiformat, nicht mehr nicht weniger. Es dient primär zum Austausch zwischen verschiedenen Systemen.
Was ein Programmierer nun damit anstellt?
Viele scheitern schon beim rekursiven Parsen.Low-Level-Vorteile von XML hat hier noch keiner von den Binär-Junkies genannt.
Wie stelle ich fest, ob meine Datei vollständig ( auf Festplatte ) ist ?Bei XML erledigt das der Parser ( Tags sind nicht geschlossen ).
Eine billige Binär-Applikation würde hier schon bestimmt abschmieren.2. XML-Erweiterungen:
DTDs sind zwar nicht schön, aber ein mächtiges Werkzeug.
XSL dürfte hier den wenigsten bekannt sein.
Mit XSL-T kann man eigene XML-Dokumente in beliebige Formate konvertieren, z.b. anderes XML, SQL, C++, PHP, HTML.
Heißt also, benutzt man schon XML in irgendeiner Form, ist der Aufwand ein anderes XML-Format zu unterstützen minimal. Denn man muß nur die Transformation programmieren.Es gibt Projekte, die nutzen XSL-T um sowohl SQL-Schema als auch C++-Klassen zu genieren.
-
Wir bekommen in der Firma Daten mit PDFs um das zu archivieren.
Vorher waren es csv-Dateien, jetzt ist es XML. Der Inhalt ist der gleiche,
das Datenvolumen um das 50fache höher. Dank dem Hype ein echter Fortschritt.
Dann noch tags mit Umlauten, eine DTD gibt es nicht und verstanden hat der
Kunde eigentlich auch nicht was er macht.*schluchz* Zum Haareraufen und unnötige Arbeit / Kosten.
Was nutzt ein Konzept wenn ...
Und was juckt's die Eiche wenn sich die Sau dran kratzt.
-
Ich arbeite gerne mit XML.
Bei einem Projekt wurde die Anforderungen während der Entwicklung der Software weiterentwickelt und ständig kam etwas neues hinzu. Beinahe jeden Tag hat mir ein Entwickler des Kunden neue Testdatensätze mit zusätzlich Strukturen im XML geschickt - und ich konnte wenn ich noch nicht so weit war trotzdem mit diesen neuen Daten testen. Und wenn ich mal mit dem Einlesen weiter war als er mit dem Erzeugen, hab ich mir einfach selber etwas zusammengeschrieben.
Ich weiß nicht wie das mit einem Binärformat ähnlich effizient hätte laufen sollen.Die XML-Struktur ließ sich auch gut visualisieren, was Dokumentation und Debugging sehr einfach machte. Eine einfach Validierung anhand eines XSD ist auch super praktisch - damit wurden viele Datenfehler recht früh gefunden.
-
Hypothese: durch die scheinbar leichte Zugaenglichkeit (plus den Hype) von XML verwenden es auch Leute, die eigentlich nicht die noetige Vorbildung haben. Das Ergebnis ist sind unsaubere Formate und Dokumente (So wie's frueher mit HTML oder Basic-Dialekten auch passiert ist).
(Daran ist aber nicht XML per se Schuld, IMO.)
Scheppertreiber: Hmmm... jo, das ist bloed. Aber besser als PDFs find ich das Format schon, da es leichter bearbeitbar/durchsuchbar ist. Vielleicht zahlt sich das spaeter mal aus, und was das Datenvolumen angeht: ist wiegesagt leicht komprimierbar. Aber wenn die Daten auch in CSV passen: warum nicht einfach in eine Datenbank damit? (oder verwendet ihr XML nur fuer den Datenaustausch?)
-
Hai Blautiger,
ich verwende XML nicht freiwillig
Der Kunde will das.
Wir bekommen PDFs und zusätzlich die zugehörigen Buchungssätze. Was in den
Buchungssätzen steht kann ich genausogut aus dem PDF lesen (ein geniales Format,
ich mag es einfach
).Bei Datenmengen um 100 Tsd Blatt pro Tag merke ich wie das jetzt aufgebläht ist.
Der Informationsgehalt ist, nebenbei, der gleiche.