Ist XML überbewertet?

TGGC

volkard schrieb:

XML-Lerner schrieb:

Ist XML überbewertet?

Ja.

Dito. f'`8k

Tyrdal

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

Tyrdal

@Zwutz
Genau das mein ich. Das JSON Beispiel ist um Längen besser lesbar als das XML und zudem auch noch kürzer (wenn auch ein wenig länger als csv);

TGGC

byto schrieb:

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.

Das XML schreibt ja auch keiner per Hand. Und wenn man die Lieferscheinnummer in die falsche Spalte reinschreiben kann, dann kann man sie genausogut auch ins falsche Tag reinschreiben. Da nuetzen dir deine Schemas auch nichts. f'`8k

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

byto

CSV = flach, XML & JSON = hierarchisch

Ergo hinkt der Vergleich.

byto schrieb:

CSV = flach, XML & JSON = hierarchisch

stimmt, z.b. ist eine csv-datei nur eine einzelne tabelle, während eine xml-datei eine ganze datenbank sein kann. kommt immer drauf an was man will, manchmal ist csv auch ganz praktisch.

µngbd: endlich mal eine sinnvolle anwendung für die lisp-syntax *fg*

zwutz

Scheppertreiber schrieb:

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.

Wie würdest du denn (X)HTML-Seiten beschreiben?

Stell dir vor, du bist ein Druckdienst. Der Kunde schickt dir eine Stylesheetdatei, eine Schemadatei und danach 200k XML-Dateien.
Die XML-Dateien enthalten die Daten, was die Daten darstellen und eventuelle weitere Informationen, die direkt mit den Daten zusammenhängen bzw. sich von XML-Datei zu XML-Datei unterscheiden (Datumsformat, etc), die Stylesheet-Datei enthält die Informationen, wie die Daten allgemein dargestellt werden sollen, also unabhängig von den darin enthaltenen Informationen (Farbe, Ausrichtung, Schrift, etc). Die Schemadatei enthält Informationen zur Fehlerkontrolle, also welche Daten drin sein dürfen bzw. müssen, sogar in welchem Format das Datum vorliegt kann darin festgelegt werden
Du fütterst deinen XML-Parser dann nur mit der Stylesheet-Datei und kannst die 200k Dateien dann direkt druckfertig parsen und anhand der Schemadatei kann gleich noch auf Fehler überprüft werden

Würde er Binärdaten schicken müsstet ihr euch erstmal auf ein Format einigen oder du dürftest jedesmal den Parser anpassen. PDF ist auch nicht recht klein (hat dafür aber andere Vorteile, z.B. das Einbetten von Schriften) und JSON ist für solche Fälle definitiv nicht gedacht

XML mag überbewertet sein, nutzlos und in allen Bereichen ersetzbar ist es deswegen lange nicht

zwutz schrieb:

Würde er Binärdaten schicken müsstet ihr euch erstmal auf ein Format einigen oder du dürftest jedesmal den Parser anpassen.

binärdaten kann man in textformaten z.b. als 'base64' unterbringen. sowas wird oft gemacht und stellt keinen vor probleme.

Scheppertreiber

Genau das macht der Kunden.

Was leider nicht bedeutet, daß keine Fehler drinnen sind

Immer diese Diskrepanz zwischen Theorie und Praxis ...

byto

;fricky schrieb:

zwutz schrieb:

Würde er Binärdaten schicken müsstet ihr euch erstmal auf ein Format einigen oder du dürftest jedesmal den Parser anpassen.

binärdaten kann man in textformaten z.b. als 'base64' unterbringen. sowas wird oft gemacht und stellt keinen vor probleme.

Und dann? Hast Du immernoch ein Binärformat ohne feste Struktur.

XML ist halt ein Standard für einen weit verbreiteten Anwendungsfall, nämlich die Kommunikation und Datenübermittlung über Systemgrenzen hinweg. Natürlich lässt sich über die Details streiten (z.B. die Syntax der XML-Tags). Das ändert aber nichts daran, dass XML und verwandte Technologien (XSD, XSL, XPath, ...) grundsätzlich gut und wichtig sind.

Proprietäre Insellösungen können ja wohl schlecht als ernsthafte Alternative für so einen Standard genannt werden.

byto

Scheppertreiber schrieb:

Immer diese Diskrepanz zwischen Theorie und Praxis ...

Die Praxis zeigt in vielen Fällen, dass es funktioniert. Aber es gibt natürlich immer DAUs, die mit Technologien nicht zurecht kommen. Damit muss man dann leider leben.
Lösungsvorschlag meinerseits: Definier doch ein striktes XSD-Schema für Eure XML-Struktur. Kommt dann eine Datei im falschen Format, kannst Du den schwarzen Peter weiterschieben.

nman

;fricky schrieb:

µngbd: endlich mal eine sinnvolle anwendung für die lisp-syntax *fg*

Zum Glück gibt es Dich und c++.de und somit nach fünfzig Jahren endlich eine gute Anwendung für die Lisp-Syntax, sonst hätten wir Ärmsten bestimmt noch weitere fünfzig Jahre gewartet. Hoch fricky! Unser Erlöser!

Scheppertreiber

Hi byto,

da spielen auch noch andere Faktoren wie Laufzeit eine Rolle.

Klar kann ich einen XML-Parser einsetzen ...

Im Extremfall kann ich auf die Buchungssätze ganz verzichten und parse das PDF.
Lesen und ablegen muß ich es eh. Ich bin dafür, XML da einzusetzen wo es sinnvoll
und vertretbar ist. Es hat aber halt auch Nachteile.

Tags mit Umlauten sind lustig. XML mit dem IE anschauen ist lustig. Was man da manchmal
an Daten bekommt reizt zu Lachkrämpfen