Ist XML überbewertet?

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.

byto

Wenn man nur in der RDBMS Welt denkt, mag das zutreffen. Aber Es gibt noch 1-2 Schichten ausserhalb relationaler Datenbanken. Und dort wird mit Objektgraphen hantiert und nicht mit irgendwelchen relationalen Modellen.

Wenn es nur darum geht, Daten von einer DB in eine andere zu schauffeln, dann nimmt man am besten gar kein Textformat - auch nicht die von Dir propagierten CSVs. Dann kann ich das ganze auch gleich von den DBs über Views und Stored Procedures regeln.

volkard

Der XMüll war doch auch flach! Erst die Leute(-Tabelle), dann die Vereine(-Tabelle) mit Fremdschlüssel auf die LeuteID.
Als einen Versuch in Unflachheit würde ich es annehmen, wenn in den Leuten angegeben worden wäre, in welchen Vereinen sie sind. Aber so war's die alte relationale Datenbank mit einem Goldkettchen.

*john 0

Zuerst wolltest Du nicht glauben, daß es überhaupt möglich sei, und nein lamentierst Du über RDBMS, die auch heute noch essentiell sind.

byto schrieb:

Wenn man nur in der RDBMS Welt denkt, mag das zutreffen.
Aber Es gibt noch 1-2 Schichten ausserhalb relationaler Datenbanken. Und dort wird mit Objektgraphen hantiert und nicht mit irgendwelchen relationalen Modellen.

Das ist auch meist der Grund, warum viele Anwendungen langsam sind! Schlußendlich laufen die meisten Enterprise Anwendungen auf Basis von RDBMs, und es wird oftmals mit Gewalt an der Struktur der Datenbank vorbei entworfen. Man benutzt dann das RDBMs nur als teures ineffizientes Datengrab.

byto schrieb:

Wenn es nur darum geht, Daten von einer DB in eine andere zu schauffeln,
dann nimmt man am besten gar kein Textformat - auch nicht die von Dir
propagierten CSVs. Dann kann ich das ganze auch gleich von den DBs über
Views und Stored Procedures regeln.

Eben dies ist in vielen Fällen nicht möglich, weil man keinen Zugriff
auf das RDBMs bekommt, so daß man Austauschformate benötigt. Hierfür ist XML nur bedingt geeignet, zumindest in der meist verwendete Form.

Mal ein anderes Beispiel: HDF5 ist eine Library aus dem HPC-Bereich, da wird ein XML Header geschrieben und die Daten schlußendlich effektiv abgelegt. Wenn man GB bis zu TB Daten ablegen muß, dann braucht man ein effizientes Datenformat.

Prof84

Marc++us schrieb:

Ich habe jetzt wieder Verschiedenes verstanden.

Kleine Anekdote:

XML-Protokoll zwischen zwei Lieferanten. Lieferant A implementiert das Protokoll so, daß er nur mit den ihm wichtigen(!) Attributen klarkommt. Sendet Lieferant B mal ein XML-Telegramm (das wohlgeformt) ist mit anderen Attributen - Crash. Komplette Anlage down. Hat den XML-Parser anscheinend über Stringparsing realisiert.

Ja, das wird immer gern genommen. Der Eine hat einen SAX-Parser, der Andere einen DOM-Parser und dann knallt's. Für den Einen ist der Prozess wichtig, für den Anderen die Struktur. Ist eigentlich kein XML Problem. Zu dem Thema musste ich schon so manchen Managerfilter reinigen.

XML per Email zu schicken ist immer riskant, weil so die Kindersicherung umgangen wird (Authentification). Da muss ich ausnahmsweise die T-Loser in Darmstadt loben mit ihren AAA und SAML:
http://en.wikipedia.org/wiki/AAA_protocol
http://de.wikipedia.org/wiki/Security_Assertion_Markup_Language

Kunden- und Versorgungsmanagement hat was von einen Kindergarten:
@Kind: "Nicht anfassen! Ist heiß!"
@Kunde: "Ändern Sie bloß nicht eigenmächtig die Konfiguration!"
... und was passiert?!

@Kind: "Nicht über die Straße rennen!"
@Kunde: "Gehe Sie bloß nicht zu dem. Der hält sich nicht an die Spezifikation. Können Sie später alles wieder abreißen!"
... und was passsiert?!

Früher haben ganze Völkerstämme von Account-Managern von ihren Projektleitern eine gezogen bekommen, weil sie ihre Aufsichtspflicht vernachlässigt haben. Aber heute gibt es XML mit den 'Rutsch mir doch' & 'Leck mich' Effekt.

Marc++us schrieb:

Kleine Anekdote:

XML-Protokoll zwischen zwei Lieferanten. In der Spec steht das XML-Protokoll formatiert, zur besseren Lesbarkeit. Kommunikationstest. Nichts geht. Nach längerer Fehlersuche stellt man fest, daß Lieferant B DIE ZEILENUMBRÜCHE ERWARTET. Ohne den Zeilenumbruch an der richtigen Stelle funzt der XML-"Parser" nicht.

Ja, da hat jemand wohl Scheiße beim XSLT gebaut:
http://msdn.microsoft.com/en-us/library/aa468566.aspx

Oder aus der Hüfte geschossen aus 3-4 XML im Tool ein XSD ziehen, dann die gesammte SOA & EAI Entwicklung dagegen anlehnen und sich dann wundern, dass zwei Monate später die gesamte sechsstöckige Außenmauer nach Vorne umfällt. Da sind nebenan die Vodafone- und T-Mobile-Cowboys ganz gut drin.

Marc++us schrieb:

Maschinendatenkonsistenzprüfung:

Voraussetzung ist eine ordentliche Simulation des Tools. XML ist in diesem Szenario gar nix. Es ist nicht wertschöpfend in dieser Konfiguration, da jede Vereinbarung über das Datenformat die gleiche Information transportiert hätte. Begründung der Notwendigkeit liegt also in einer anderen Dimension.

Genau das ist der Clou: Du brauchst eine abgegrenzte Sprache, im abgegrenzten Kontext und normalizierten Datenformat, um ein Analyse-Tool zu entwickeln. Wie soll der Kunde Dir denn so seinen Querdenkerfaktor vermitteln?!

Marc++us schrieb:

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"

Wie denn über Einkauf? Wenn er über 10.000 Rupien pro Stück ausgeben soll kommen ihm die Tränen. Und wehe Du brauchst mal einen Deutschen. - Kommt sofort Dagobert Duck im seiner alten Schrott-Büchse runter ...

Thema Attribute in XML:
Ich habe gestern mal eine kleine Volkszählung bei meiner Professorenherde geführt. Anscheinend bestimmt die Primärwaffe bei den Hochsprachen den Style und den Umgang mit XML. Die OO-Künstler bekommen scheinbar eine sauber Balance zwischen Tags und Attributen hin. Die LISP- und Haskell-Künstler pfeiffen auf Attribute (außer Header). Und die Prolog-Helden haben immer kurze nicht redundante XML's, aber meterlange XPATH-Ausdrücke im Style.

Man scheint sein Lieblingsparadigma auch in XML durchzuziehen. Interessant! ähm ich meinte "Faszinierend!"

byto

byto schrieb:

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.

~john schrieb:

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

~john schrieb:

Zuerst wolltest Du nicht glauben, daß es überhaupt möglich sei, und nein lamentierst Du über RDBMS, die auch heute noch essentiell sind.

Warum lügst Du jetzt rum? Unter solchen Voraussetzungen ist jede weitere Diskussion mit Dir sinnlos...

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

Wer im Glashaus sitzt sollte nicht mit Steinen werfen.