Ist XML überbewertet?

Blue-Tiger

volkard schrieb:

Nachdem Ihr meinen XML-Paste aus einer *.docx überlebt habt, hier der finale Schwachsinn:
http://pastebin.com/m132fba2f

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.

nurf

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.

Scheppertreiber

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.

illuminator

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.

Blue-Tiger

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?)

Scheppertreiber

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!?

volkard

_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.

PRIEST

Ich finde XML sehr gut für Katalogbildung.. für einen Datenaustausch reicht aber auch meist JSON

Bitsy

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.

Scheppertreiber

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

TGGC

volkard schrieb:

XML-Lerner schrieb:

Ist XML überbewertet?

Ja.

Dito. f'`8k

Gruß, TGGC (Was Gamestar sagt...)

Tyrdal

@Zwutz

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.

Scheppertreiber

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 Byte

Das 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).

byto

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.

Scheppertreiber

Klar kann das passieren. Es war ja nur ein Beispiel.

Warum sollte jemand eine automatisierten Prozess ändern ? Das Schema
kann genauso falsch sein, die Daten müssen auch interpretiert werden
oder woher weißt Du was mit LIEFERSCHEINNUMMER gemeint ist ?

Es geht auch nicht um 20 MB ...

byto

volkard schrieb:

_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.

Du hast natürlich vollkommen recht!

zwutz

Tyrdal schrieb:

@Zwutz

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.

Ich denke mal, dass viele XML einfach falsch verwenden (von mir teilweise auch, muss ich zugeben. Einen XML-Parser hat man meist schon rumliegen, was man von anderen Textformaten nicht unbedingt behaupten kann). JSON zum Beispiel ist in vielen Fällen besser geeignet, wenn es um den reinen Datenaustausch geht (das Lieferscheinbeispiel wär in JSON wohl besser lösbar)

XML wird, wenn ich das richtig verstanden habe, vor allem dann praktisch, wenn man neben den eigentlichen Daten auch zusätzliche Informationen ablegen will, z.B. wie der Empfänger damit weiterarbeiten soll.

Beispiel:

JSON:
{
  "lieferschein": {
    "nummer"      :    "00000815"
    "datum"       :    1256633179
    "empfänger"   : {
      "name"        :    "Dr. Foo"
      "vorname"     :    "Hans"
      "plz"         :    "01337"
      "ort"         :    "Musterdorf"
      "straße"      :    "Baumstraße 3"
    }
  }
}

XML:
<lieferschein>
  <nummer length="8">815</nummer>
  <datum format="dd.mm.YYYY">1256633179</datum>
  <empfänger>
    <name sortkey="foo">Dr. Foo</name>
    <vorname sortkey="hans">Hans</vorname>
    <plz>01337</plz>
    <ort>Musterdorf</plz>
    <straße>Baumstraße 3</straße>
  </empfänger>
</lieferschein>

ok, json mag lesbarer sein (vor allem durch den großzügigen Einsatz von Leerraum), dafür hat xml den Vorteil, dass man auch Informationen hinterlegen kann wie die Daten verarbeitet werden sollen.

Scheppertreiber

xml den Vorteil, dass man auch Informationen hinterlegen kann wie die Daten verarbeitet werden sollen.

Aha. Und wo steht das ?

Schau Dir mal Deine Beispiele an, was ein Overhead an sich ständig wiederholendem Text
der keinen Informationsgewinn bringt. Es reicht, die Daten EINMAL zu definieren.

zwutz schrieb:

Einen XML-Parser hat man meist schon rumliegen, was man von anderen Textformaten nicht unbedingt behaupten kann).

Und? Lisp-Parser gibt es seit der Steinzeit, und niemand verwendet die. Obwohl schon einige bemerkt haben, dass S-Expressions das gleiche sind wie XML.

Also noch ein Format, damit ihr euch streiten könnt:

SEXP:
(lieferschein
  (nummer "00000815")
  (datum  1256633179)
  (empfänger
    (name "Dr. Foo")
    (vorname "Hans")
    (plz "01337")
    (ort "Musterdorf")
    (straße "Baumstraße 3")))