Ist XML überbewertet?

EXDW

volkard schrieb:

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.

ups
hatte ich gar nicht gesehen
was klar demonstrierte wie "lesbar" die csv variante ist #gg
fuer diesem beispiel hat csv deutliche probleme
-> man kann nichts automatisch ueberpruefen lassen ob es in ordnung ist (xsd)
-> man muss sich genau auf etwas einiges was gemacht wird (welche spalte, evtl noch welche row)
-> man kann ";" und aehnliche zeichen welche die spalten trennt dann nicht mehr als inhalt der felder verwenden
-> wenn man es weiter verwenden will muss man eigene sachen schreiben (XDocument, XmlDocument, XSLT transformationen)

xml hat zwar redundanzen - diese ergeben aber auch den komfort
zb das die nodes in einer willkuerlichen reihenfolge stehen koennen - das sie leichter validiert werden koennen - und das man jeden eintrag eine beliebiege zusatz information mit geben kann (die aber nicht zwingend da sein muss, bei csv wuerde es ein leeres feld ergeben) - und es ist menschen lesbarer

(man darf natuerlich nicht die bisher gut ausgebauten editoren und parser missachten, und durch die baum struktur ist es fuer editoren einfacher baeume auf und zu zu klappen)

byto

Scheppertreiber schrieb:

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.

Du glaubst doch nicht tatsächlich, dass man jede hierarchische XML Struktur als flache CSV darstellen kann und dieser Faktor 3.5 dann immernoch gilt!?

Wie willst Du denn sowas sinnvoll in eine flache CSV normalisieren:

<dokument>
  <person id="1">
    <vorname>Hans</vorname>
    <nachname>Meiser</nachname>
  </person>
  <person id="2">
    <vorname>Hans</vorname>
    <nachname>Wurst</nachname>
  </person>
  <verein>
    <mitglied ref="1" />
  </verein>
  <verein>
    <mitglied ref="1" />
    <mitglied ref="2" />
  </verein>
</dokument>

Edit: Es gibt sicherlich andere Formate, die weniger Overhead als XML erzeugen, aber CSV ist für mich keine brauchbare Alternative, ausser die Daten sind flach.

rüdiger schrieb:

Ne, SEXPs sind nicht das gleiche. XML ist eben eine Markupsprache und hat daher Attribute. Deshalb wird ja alles noch einmal extra kompliziert, wenn man XML als Datensprache missbraucht.

Ich habe immer wieder mal Schwierigkeiten, mich zwischen Attribut und Kindknoten zu entscheiden. Das muss wohl so sein.

byto schrieb:

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.

Aber wenn dein Toaster deinen Server verstehen soll, müssen sie dann doch die gleiche Sprache sprechen. Da kannst du natürlich dem Toaster einen besseren Prozessor spendieren, damit der XML-Parser läuft; aber man könnte vielleicht auch die Sprache einfacher halten.

BTW kann XML kann das Leben durchaus schöner machen. Mein Hobby: Webdesigner mit solchen Links in den Wahnsinn treiben:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.c-plusplus.net%2Fforum%2Fviewtopic-var-t-is-252877-and-start-is-80.html&charset=(detect+automatically)&doctype=Inline&group=0

EXDW

ich haette bei detei formaten gerne diese anforderungen:

- es soll bereits full tested editoren und reader geben
- ich moechte es mit jedem beliebigen text editor lesen und verstehen koennen
- ich moechte jedem eintrag eine beliebige anzahl an optionalen informationen mit geben
- ich moechte ungebunden sein welche reinfolge ich verwende (egal welche achse)
- ich moechte es mit einem beliebigen text editor editieren koennen ohne etwas zu zerstoeren
- trotzdem muss es eine moeglichkeit geben jemand zu zwingen ein bestimmtes format ein zu halten - zb bestimmte angaben zu machen

loesung: xml

um die vorzuege zu haben muss man halt mit den paar nachteilen leben - is doch immer und ueberall so

rüdiger

µngbd schrieb:

rüdiger schrieb:

Ne, SEXPs sind nicht das gleiche. XML ist eben eine Markupsprache und hat daher Attribute. Deshalb wird ja alles noch einmal extra kompliziert, wenn man XML als Datensprache missbraucht.

Ich habe immer wieder mal Schwierigkeiten, mich zwischen Attribut und Kindknoten zu entscheiden. Das muss wohl so sein.

Wenn man XML als Datensprache missbraucht, dann am besten ganz auf Attribute verzichten.

byto schrieb:

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

naja, wer weiss, wie schnell einiges wäre, wenn es nicht mit XML sondern mit einem kompakteren format hantieren würde, beispielsweise SOAP. warum soap xml-basiert ist, ist mir ein rätsel, das ist nichts als pure bandbreiten-verschwendung. XML ist ein vorschlaghammer. aber vorschlaghämmer sind nicht dazu da, reisszwecken in eine pinwand zu hauen.

Tyrdal

Das ist einfach zu beantworten: XML->Buzzword, SOAP->Buzzword => das muß zusammen, ergibt Synergieeffekte!

Blue-Tiger

rüdiger schrieb:

µngbd schrieb:

rüdiger schrieb:

Ne, SEXPs sind nicht das gleiche. XML ist eben eine Markupsprache und hat daher Attribute. Deshalb wird ja alles noch einmal extra kompliziert, wenn man XML als Datensprache missbraucht.

Ich habe immer wieder mal Schwierigkeiten, mich zwischen Attribut und Kindknoten zu entscheiden. Das muss wohl so sein.

Wenn man XML als Datensprache missbraucht, dann am besten ganz auf Attribute verzichten.

Yeah, Attribute sind fuer Metadaten da.

volkard

Blue-Tiger schrieb:

Yeah, Attribute sind fuer Metadaten da.

Also soll bei

<dokument> 
  <person id="1"> 
    <vorname>Hans</vorname> 
    <nachname>Meiser</nachname> 
  </person> 
  <person id="2"> 
    <vorname>Hans</vorname> 
    <nachname>Wurst</nachname> 
  </person> 
  <verein> 
    <mitglied ref="1" /> 
  </verein> 
  <verein> 
    <mitglied ref="1" /> 
    <mitglied ref="2" /> 
  </verein> 
</dokument>

jeweils id und ref raus? oder nur id raus und ref ist meta?

SideWinder

Weder noch, scheinen mir beides Meta-Daten zu sein. Die ID beschreibt als Primary Key die Person, ist aber nun aus Nicht-Informatiker-Sicht kein Attribut von Person. ref ohnehin Meta-Information.

MfG SideWinder

rüdiger

volkard schrieb:

Blue-Tiger schrieb:

Yeah, Attribute sind fuer Metadaten da.

Also soll bei

<dokument> 
  <person id="1"> 
    <vorname>Hans</vorname> 
    <nachname>Meiser</nachname> 
  </person> 
  <person id="2"> 
    <vorname>Hans</vorname> 
    <nachname>Wurst</nachname> 
  </person> 
  <verein> 
    <mitglied ref="1" /> 
  </verein> 
  <verein> 
    <mitglied ref="1" /> 
    <mitglied ref="2" /> 
  </verein> 
</dokument>

jeweils id und ref raus? oder nur id raus und ref ist meta?

tztztz, volkard. Du kennst dich gar nicht mit XML aus: <mitglied ref="1" /> ist doch totaaaaaaaal falsch. Dafür gibt es doch XLink und XPointer!

<dokument> 
  <person id="1"> 
    <vorname>Hans</vorname> 
    <nachname>Meiser</nachname> 
  </person> 
  <person id="2"> 
    <vorname>Hans</vorname> 
    <nachname>Wurst</nachname> 
  </person> 
  <verein> 
    <mitglied xmlns:xlink="http://www.w3.org/1999/xlink"
          xlink:type="simple"
          xlink:show="embed"
          xlink:actuate="onRequest"
          xlink:href="#xpointer(id(1))" /> 
  </verein> 
  <verein> 
    <mitglied xmlns:xlink="http://www.w3.org/1999/xlink"
          xlink:type="simple"
          xlink:show="embed"
          xlink:actuate="onRequest"
          xlink:href="#xpointer(id(1))" /> 
    <mitglied xmlns:xlink="http://www.w3.org/1999/xlink"
          xlink:type="simple"
          xlink:show="embed"
          xlink:actuate="onRequest"
          xlink:href="#xpointer(id(2))" />
  </verein> 
</dokument>

hey, aber so einfach geht das natürlich nicht. Wir müssen jetzt noch die ganze DTD schreiben, damit XPointer überhaupt weiß, dass wir mit id auch die id meinen :).

Zeus

Krass o.O

Shade Of Mine

rüdiger schrieb:

Wenn man XML als Datensprache missbraucht, dann am besten ganz auf Attribute verzichten.

QFT

spart eine menge ärger.

illuminator

TGGC schrieb:

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.

Das stimmt schon mal so nicht. Man muss es nur richtig machen.
Bei meinem letzten großen Projekt hatten Daten wie Kundennummer/Vertragsnummer, oder auch Namensfelder im XSD definierte Restrictions die festgelegt haben wie lang ein Namen z.B. maximal sein darf, welches Pattern eine Kundennummer haben muss etc.
Eine Musterprüfung zum Schutz vor falschen Datentypen oder Vertauschungen von verschieden struktuirerten Zahlen, Datumsformaten etc. bietet XML mithilfe von XSDs.

Der größte Vorteil war aber auch, dass man in neue Testdaten einfach neue Tags und Strukturen einfügen konnte ohne das die alten Testdaten unbrauchbar wurden.
Das freut vorallem die Leute die Testdaten erzeugen müssen.

----

In meinem aktuellen Projekt gibt es größere Mengen an Binärdatenstrukturen die auch noch lange zu Erstellung brauchen.
Und so kommt es hier öfters mal vor, dass ein binäres Element vergrößert und verkleinert und damit einer ganzer Satz exportierter Daten für die neue Softwareversion unbrauchbar wird.

Dann kotzt jemand weil er sich eine Stunde hinsetzen darf um alles neu zu exportieren.
Und ich kotze weil ich das Testen verchieben muss bis das passiert ist.

Wobei auch in dem Binärformat einige Maßnahmen ergriffen wurden um es XML-ähnlicher zu machen und so solche Situationen seltener zu machen.
Die Wahl auf eine Binärformat ist hier sowieso nur deswegen getroffen worden, weil Geschwindigkeit und Speicherplatz sehr kritische Faktoren sind.

*john 0

byto schrieb:

Wie willst Du denn sowas sinnvoll in eine flache CSV normalisieren:

<dokument>
  <person id="1">
    <vorname>Hans</vorname>
    <nachname>Meiser</nachname>
  </person>
  <person id="2">
    <vorname>Hans</vorname>
    <nachname>Wurst</nachname>
  </person>
  <verein>
    <mitglied ref="1" />
  </verein>
  <verein>
    <mitglied ref="1" />
    <mitglied ref="2" />
  </verein>
</dokument>

Da benutzt jemand viel zu lange XML

"table";"person"
"id";"vorname";"nachname"
1;"Hans";"Meiser"
2;"Hans";"Wurst"

"table";"verein"
"id"
1
2

"table";"person_verein_xref"
"id_person";"id_verein"
1;1
1;2
2;2

Und damit entspricht die Sache auch noch deutlich besser SQL, in dem eh die meisten Daten abgelegt werden. Aber ORMs vernebeln die Sicht auf Datenstrukturen in RDBMS zunehmend.

TGGC

illuminator schrieb:

Das stimmt schon mal so nicht. Man muss es nur richtig machen.
Bei meinem letzten großen Projekt hatten Daten wie Kundennummer/Vertragsnummer, oder auch Namensfelder im XSD definierte Restrictions die festgelegt haben wie lang ein Namen z.B. maximal sein darf, welches Pattern eine Kundennummer haben muss etc.

Aha. Weil diese Restriction in einer Datei mit der Endung xsd stehen (statt in einem txt, doc oder pdf) kann ploetzlich keiner etwas falsches mehr in das xml schreiben? f'`8k

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

byto

Die XSD ist idR in jeder XML Instanz verlinkt, so dass Parser per Default zunächst gegen das Schema validieren. Du merkst also direkt beim Einlesen der Datei, wenn sie nicht valide ist.

byto

~john schrieb:

byto schrieb:
Wie willst Du denn sowas sinnvoll in eine flache CSV normalisieren:
<dokument>
  <person id="1">
    <vorname>Hans</vorname>
    <nachname>Meiser</nachname>
  </person>
  <person id="2">
    <vorname>Hans</vorname>
    <nachname>Wurst</nachname>
  </person>
  <verein>
    <mitglied ref="1" />
  </verein>
  <verein>
    <mitglied ref="1" />
    <mitglied ref="2" />
  </verein>
</dokument>
Da benutzt jemand viel zu lange XML
"table";"person"
"id";"vorname";"nachname"
1;"Hans";"Meiser"
2;"Hans";"Wurst"

"table";"verein"
"id"
1
2

"table";"person_verein_xref"
"id_person";"id_verein"
1;1
1;2
2;2
Und damit entspricht die Sache auch noch deutlich besser SQL, in dem eh die meisten Daten abgelegt werden. Aber ORMs vernebeln die Sicht auf Datenstrukturen in RDBMS zunehmend.

Ich würde eher sagen, Du bist gefangen in der relationalen RDBMS Welt. Denn ich sehe absolut keinen Vorteil von dieser flachen Darstellung. Was habe ich davon, solche Daten rauszugeben? Dann kann ich gleich DB Views als Schnittstellen benutzen...

Im Sinne des Domain Driven Designs steht für mich die Struktur der Fachobjekte im Vordergrund und die ist nun mal hierarchisch bzw. graphenorientiert.

TGGC

byto schrieb:

Die XSD ist idR in jeder XML Instanz verlinkt, so dass Parser per Default zunächst gegen das Schema validieren. Du merkst also direkt beim Einlesen der Datei, wenn sie nicht valide ist.

Und weil in irgendeiner Datei evtl. der Dateiname einer anderen Datei steht, kann niemand mehr Unsinn in sein xml schreiben? f'`8k

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

*john 0

byto schrieb:

Denn ich sehe absolut keinen Vorteil von dieser flachen Darstellung. Was habe ich davon, solche Daten rauszugeben?

Man kann so die Daten sehr viel schneller parsen und verarbeiten, und das ist bei großen Datensätzen ein enormen Vorteil. Der XML Overhead verdeckt vollständig, daß man die Daten fast immer in einer SQL Datenbank ablegt. Man hat also nicht viel von so einer XML-Struktur.

Egal was für eine Struktur man verwendet, alle Beteiligten müssen die Kontrakte einhalten, die mit diesen Datenstrukturen verbunden sind. Ein einseitiges Ändern der Kontrakte ist vollkommen sinnlos und verletzt die Vereinbarungen, um welches Datenformat es sich schlußendlich handelt ist dabei vollkommen belanglos.

Unter Umständen kann XML sinnvoll sein, aber meist wird es mißbraucht um Datensätze für RDBMS auszutauschen und das ist schlichtweg suboptimal - Bloat. Dafür wurde XML auch gar nicht entworfen.