Ist XML überbewertet?

Marc++us

Prof84 schrieb:

habe ich noch Altkunden, die sich ganze Zwergenarmeen halten, um händisch von einem Tool in das Nächste Daten zu übertragen, sich dann noch beschweren, dass sie über einen Monat brauchen um ein neuen Tarif anzulegen und es ständig knallt.

"get better dwarfs"

Gsemmel schrieb:

XML hat sich so weit verbreitet, weil die Leute es lieben Sachen baumartig zu strukturieren...

ja, das ist z.b. auch das erfolgsrezept von spielen wie 'tetris'. man appelliere einfach an den menschlichen ordnungssinn.

Marc++us schrieb:

...Komplette Anlage down. Hat den XML-Parser anscheinend über Stringparsing realisiert.
...Ohne den Zeilenumbruch an der richtigen Stelle funzt der XML-"Parser" nicht.

ist aber kein prinzipielles problem von XML, wenn leute selbstgestickte, schrottige parser verwenden.

Scheppertreiber

... gabz zu schweigen von schrottigen XML-Generatoren

Scheppertreiber schrieb:

... gabz zu schweigen von schrottigen XML-Generatoren

jaja, immer dieses 'not invented here'-syndrom. dabei gibts, gerade was XML angeht, viele fertige und 1000fach getestete open-source lösungen, z.b. von 'apache'. aber nein, da fummeln sie sich lieber selber parser und generatoren hin und meckern dann rum, dass XML mist ist. *fg*

Scheppertreiber

Klar. Aber wer hat Recht ? Der Kunde ?

byto

Dass man sich bei bestimmten Kunden häufig mit technischen Krücken rumschlagen muss, ist ja nichts Neues. Das ist ja nun keine Eigenheit von XML. Nächstes Mal ist es ein grottiges DB-Schema oder ein inkonsistentes Pflichtenheft.

Wer Recht hat? Natürlich Du als schlauer Entwickler, der es besser weiss. Aber das musst Du dem Kunden ja so nicht sagen.

Scheppertreiber

So ist es. Rache per Rechnung

Nee, XML ist nicht für den Unsinn verantwortlich der damit angestellt wird. Das Einzige
was mich daran stört ist die aufgeblähte Syntax mit den Monster-Tags. Es bläst die Datenmenge
unnötig auf. Speziell das Ende-Tag hätte etwas sparsamer ausfallen können.

EXDW

ausgeblaeht ?

variante 1:

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

variante 2:

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

variante 3:

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

to be continued...

fuer ne machine is das alles egal #gg
wenn man sich auf etwas einigt kann xml schon schlank sein

volkard

815;1256633179;"foo";"Dr. Foo";"hans";"Hans";01337;"Musterdorf";"Baumstraße 3"

CSV 79 Byte gegenüber 275 des "optimierten" XML. Ist an sich egal, aber wage es nicht, XML "schlank" zu nennen.

EXDW

doch - das behaupte ich (man bermerkt das "kann")

dein beispiel angepasst:

csv:
815;1256633179;"foo";"Dr. Foo";"hans";"Hans";01337;"Musterdorf";"Baumstraße 3"

xml:
<item>815;1256633179;"foo";"Dr. Foo";"hans";"Hans";01337;"Musterdorf";"Baumstraße 3"</item>

der vorteil von dem "ausgeblaehten" xml ist gegenueber dem csv das die elemente in der reihenfolge geaendert werden koennen ohne das sich das ergebnis aendert
und es koennen weitere informationen dabei sein
in dein csv beispiel fehlt zb die laenge, das format und der sort key

bau diese information mal in dein csv ein

byto

volkard schrieb:

815;1256633179;"foo";"Dr. Foo";"hans";"Hans";01337;"Musterdorf";"Baumstraße 3"
CSV 79 Byte gegenüber 275 des "optimierten" XML. Ist an sich egal, aber wage es nicht, XML "schlank" zu nennen.

Für Schnittstellen und hierarchische Daten leider ungeeignet. Morgen vertauscht jemand plötzlich stillschweigend zwei Spalten in der CSV. Schon funktioniert die Schnittstelle nicht mehr. Im schlimmsten Fall fällts nicht mal auf.

Edit: Und wenn Du das XML schon "optimierst", dann mach doch einfach die Tagnamen kürzer. Schon ist die XML deutlich kleiner.

volkard

Mr Evil schrieb:

in dein csv beispiel fehlt zb die laenge, das format und der sort key

sortkey war drin.

Mr Evil schrieb:

bau diese information mal in dein csv ein

leider kein bedarf.

der csv-leser wird aber beim datum "1256633179" auch aussteigen, fürchte ich.

volkard

byto schrieb:

Für Schnittstellen und hierarchische Daten leider ungeeignet. Morgen vertauscht jemand plötzlich stillschweigend zwei Spalten in der CSV. Schon funktioniert die Schnittstelle nicht mehr. Im schlimmsten Fall fällts nicht mal auf.

csv kann man auch schreiben mit spaltennamen in der ersten zeile. ätsch.
und übermorgen ändert jemand einen attributnamen und xml steigt aus. das ist doch kein argument, daß etwas als schnittstelle besser funktioniert, weil es vielleicht noch geht, obwohl der sender stillschweigend sich nicht mehr an absprachen hält.
außerdem werden die daten, die in einer normalisierten relationalen datenbank lagen, oft erst nach xml gezwängt (schaut mal, hierarchisch!), indem komplexe multi-tabellen-abfragen gemacht werden, und beim empfänger die strukturen wieder in flachen tabellen abzulegen, ist dann sogar mit programmieraufwand verbunden.

SideWinder

Ich benutze XML auch, mag es aber auch nicht sonderlich. Die richtig brauchbaren Formate sind doch alles andere als menschenlesbar, und die anderen entweder sinnlos oder aufgebläht.

Hab ich glatt vergessen meine Frage zu stellen: Aber welche Alternativen gibt es? JSON ist ja nun auch nicht gerade was man sich wünscht. Fehlt da nicht etwas in der IT-Branche?

MfG SideWinder

Mr Evil schrieb:

fuer ne machine is das alles egal #gg

kommt auf die maschine an. so manche ist mit einem XML-parser überfordert. und so viel speicher, um darin irgendwelche baumstrukturen zu halten, haben auch nicht alle.

Mr Evil schrieb:

wenn man sich auf etwas einigt kann xml schon schlank sein

nö, xml ist höllisch fett und aufgebläht, aber dafür sehr flexibel und universell einsetzbar.

^^btw, es gibt noch schlechtere formate:

[ProcessData]
FabricationDate=19.10.2009
ExpirationDate=19.04.2010
ActTemp=180.15
ActForce=83.02
SealingSpeed=10
SealingTemp=180
SealingForce=75
PersCode=Standard
ChargeCode=
TotalCounter=0100098536
CheckSum=15001
[ProcessData]
FabricationDate=19.10.2009
ExpirationDate=19.04.2010
ActTemp=180.37
ActForce=77.39
SealingSpeed=10
SealingTemp=180
SealingForce=75
PersCode=Standard
ChargeCode=
TotalCounter=0100098537
CheckSum=15019
[ProcessData]
FabricationDate=19.10.2009
...

^^das spuckt so'n folienschweissgerät aus. irgendwie an windows-ini angelehnt, einfach furchtbar. da ist mir XML doch 1000mal lieber.

byto

volkard schrieb:

byto schrieb:

Für Schnittstellen und hierarchische Daten leider ungeeignet. Morgen vertauscht jemand plötzlich stillschweigend zwei Spalten in der CSV. Schon funktioniert die Schnittstelle nicht mehr. Im schlimmsten Fall fällts nicht mal auf.

csv kann man auch schreiben mit spaltennamen in der ersten zeile. ätsch.
und übermorgen ändert jemand einen attributnamen und xml steigt aus.

XML bietet Dir aber die Möglichkeit, einen klaren Contract in Form einer XSD (meinetwegen auch DTD) zu definieren. Du kannst also nicht stillschweigend die Struktur der XML ändern, ohne dass es bei der Validierung sofort auffällt.

außerdem werden die daten, die in einer normalisierten relationalen datenbank lagen, oft erst nach xml gezwängt (schaut mal, hierarchisch!), indem komplexe multi-tabellen-abfragen gemacht werden, und beim empfänger die strukturen wieder in flachen tabellen abzulegen, ist dann sogar mit programmieraufwand verbunden.

Und was ist für Dich die Alternative? Wenn ich Daten aus mehreren Tabellen per SQL joine, dann kriege ich ein flaches Resultset mit vielen redundanten Daten. Diese Redundanzen können durch eine Überführung in eine hierarchische Struktur entfernt werden. Der Empfänger dieser hierarchischen Struktur (z.B. in Form einer XML) kann dann damit machen was er will. Du hast natürlich recht, dass diese Daten dann oft wieder in ein relationales Schema kommen. Aber das Schema wird idR anders aussehen als das ursprüngliche Schema, sofern es sich um ein anderer System handelt.

Und wie würde die Alternative über CSV hier aussehen? Willst Du pro Table eine CSV schicken? Oder das gejointe Resultset in eine CSV pressen samt der redundanten Daten? Beides erscheint mir wenig sinnvoll.

SideWinder

XML hat da die schöneren Ansätze, aber es schrecken schon die vielen Übelkeiten ab die man da verbrochen hat. Da gibt es zig verschiedene Standards, Attribute und Daten in Elementen, zuviel Bloat, DTD obwohl XML-Schema, Namensräume die jeder frei Schnauze benennt und eine angeblich natürliche Lesbarkeit die bei Gott bei vielen Formaten nicht gewährleistet ist und man sich fragen muss wofür man das mitschleppt, usw. usf. Das ganze schreit direkt nach XML2, aber wie beim Web und XHTML2 ists bereits zu spät.

MfG SideWinder

byto

;fricky schrieb:

kommt auf die maschine an. so manche ist mit einem XML-parser überfordert. und so viel speicher, um darin irgendwelche baumstrukturen zu halten, haben auch nicht alle.

SAX Parser sind schnell und brauchen wenig Speicher. Aber klar, man kann immer eine geeignet langsame Maschine finden, die mit einer beliebigen Technologie überfordert ist. In der Praxis hat das aber imo wenig Relevanz.

Der Overhead durch die XML-Syntax ist sicherlich eine Schwachstelle. Aber die ist häufig irrelevant, weil es praktisch häufig (nicht immer!!1) einfach keine Rolle spielt, ob eine Datei nun 10MB oder 10.2MB groß ist.

Scheppertreiber

byto schrieb:

Der Overhead durch die XML-Syntax ist sicherlich eine Schwachstelle. Aber die ist häufig irrelevant, weil es praktisch häufig (nicht immer!!1) einfach keine Rolle spielt, ob eine Datei nun 10MB oder 10.2MB groß ist.

volkard schrieb:
CSV 79 Byte gegenüber 275 des "optimierten" XML. Ist an sich egal, aber wage es nicht, XML "schlank" zu nennen.

Bei 1 Mio Datensätzen ist das relevant. Immerhin Faktor 3.5.
Es ist definitiv ein Unterschied ob ich 1 oder 3.5 x Megabytes übertrage.