Ist XML überbewertet?
-
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.
-
rüdiger schrieb:
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.
Müssen HTTP Bodies nicht zumindest Base64 kodiert sein!?
-
_byto schrieb:
Müssen HTTP Bodies nicht zumindest Base64 kodiert sein!?
Dann wäre http-downloads ja so langsam wie mail also langsamer als ftp. Das wäre mir aufgefallen.
-
Ich finde XML sehr gut für Katalogbildung.. für einen Datenaustausch reicht aber auch meist JSON
-
byto schrieb:
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.
Was aber, wenn man bereits Räder da liegen hat, weil man sie schon vor langer Zeit erfunden hat, nun aber ständig von der Arbeit abgehalten wird, weil permanent irgendwelche (überge)wichtige Hansel mit Zeug ankommen, bei dem man sich recht tief einarbeiten muß, um etwas halbwegs vernünftig fertigzustellen (so ja offensichtlich der allgemeine Tenor s.o.) - was man selbst bald in Nullzeit erledigt hätte.
EDIT: Ich habe noch keine Fremdbibliothek erhalten, aus der ich keine Bugs rausholen oder umgehen mußte. Meine eigenen finde ich schneller.
-
Bitsy schrieb:
byto schrieb:
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.
Was aber, wenn man bereits Räder da liegen hat, weil man sie schon vor langer Zeit erfunden hat, nun aber ständig von der Arbeit abgehalten wird, weil permanent irgendwelche (überge)wichtige Hansel mit Zeug ankommen, bei dem man sich recht tief einarbeiten muß, um etwas halbwegs vernünftig fertigzustellen (so ja offensichtlich der allgemeine Tenor s.o.) - was man selbst bald in Nullzeit erledigt hätte.
EDIT: Ich habe noch keine Fremdbibliothek erhalten, aus der ich keine Bugs rausholen oder umgehen mußte. Meine eigenen finde ich schneller.
Siehe da, ein Praktiker
-
volkard schrieb:
XML-Lerner schrieb:
Ist XML überbewertet?
Ja.
Dito. f'`8k
Gruß, TGGC (Was Gamestar sagt...)
-
und was ist, wenn genau das gewünscht ist, man also eine für den Menschen les- und bearbeitbare Datei haben will?
Wieso sollte man Unmengen Tags lesen wollen? Vor allem wenn im schließenden Tag dat gleiche steht wie im Öffnenden. Ich für meinen Teil bin am Inhalt interessiert und was das angeht hat Scheppertreiber ja schon ein passendes Beispiel gebracht. Kurz: Es gibt bessere Textformate, die auch Bäume darstellen können.
-
Mal wieder die Praxis:
Die weiter oben aufgeführten Buchungssätze sind alle gleichartig, haben also
den gleichen Aufbau. Ich muß also wissen, was in jedem (ich nenne das mal Feld)
vorhanden und was mit diesem Datum zu tun ist.Der Aufwand ist in XML identisch, ich muß auch wissen, was mit dem Inhalt zu
tun ist. tag hin, tag her. Ob da "<LIEFERSCHEINNUMMER>" vor jeder Lieferscheinnummer
steht oder ob das eine Spaltenüberschrift oder einfach eine Konvention ist.XML: "<LIEFERSCHEINNUMMER>08/15</LIEFERSCHEINNUMMER>" 46 Byte
csv: "08/15;" 6 ByteDas ist angewandte Datenökonomie, vor Allem wenn die Daten per ftp reinkommen und
bis zur Frühstückspause bereit stehen sollen.Bei EINEM Buchungssatz kein Problem, bei 100.000 sieht's anders aus.
(das Beispiel ist echt. Und nur EINE Angabe - es sind ca. 30).
-
CSV hat keine klare Struktur. Das schreibt jeder, wie er grade lustig ist. Übermorgen vertauscht jemand Spalte Lieferscheinnummer mit Spalte Artikelgruppennummer und Dein Parser fliegt Dir um die Ohren.
Bei XML definierst Du ein XSD-Schema und kannst sofort feststellen, ob die XML-Datei valide ist. Strukturfehler sind somit schonmal ausgeschlossen.
Ja, die XML Tags wirken aufgebläht. Aber das ist meistens kein wirkliches Problem. Habe kürzlich eine 20 MB große XML Datei eingelesen und verarbeitet. Der Code war dank fertiger Tools in wenigen Minuten geschrieben. Die Funktion lief dann in ~1.2 Sekunden durch. Da war dann noch Zeit für ne Pause bis zur Frühstückspause.
