Vorteile/Nachteile von XML

[Assarbad]

Moin,

in den bisherigen Anwendungsgebieten wo ich XML benutzt (oder auch nur in meine Überlegungen eingeschlossen) habe war es meist nur um kurze strukturierte Nachrichten auszutauschen.

Ein Kollege wollte mich aber vor einiger Zeit überzeugen, daß XML absolut die erste Wahl bei sowas wie Zusammenfassungen eines Virenscans seien. Ich persönlich habe so meine Zweifel.

Es ist schließlich so, daß die meisten Parser einfach nicht damit klarkommen wenn ein XML-Element nicht geschlossen wurde. Stellt man sich nun vor, daß der Benutzer eine langwierige Aktion abbricht, kann man sicher dafür sorgen daß die Elemente geschlossen werden. Aber das klappt nicht immer, wenn bspw. etwas unvorhergesehenes passiert. Im Gegensatz zu SEH auf Win32 gibt es auf (den meisten) unixoiden Systemen keinerlei Möglichkeit einen Prozeß zu retten. Sogar longjmp ist dabei vielfach nicht hilfreich.

Im Zweifelsfall sitzt der Benutzer dann mit einer beschädigten XML-Datei da und weiß nicht wie weiter, weil das Anzeigeprogramm mit dem verkorksten XML nicht klarkommt. Dann sind all die tollen Vorteile (Maschinenlesbarkeit, Portabilität) auf einmal dahin ...

Selbst für IPC sehe ich - insofern es auf der gleichen Maschine passiert - keine wesentlichen Vorteile von XML gegenüber einem Record den ich über ne Pipe, MMF oder anderweitig übertrage. Zumindest die üblichen Probleme wie Bitreihenfolge und Bittigkeit sind schonmal nicht vorhanden.

Ein weiteres Problem welches ich mit XML sehe ist die Ambiguität. Es gibt keine verläßliche Konventionen wann ich besser ein Attribut und wann ich besser ein Kindelement einsetze. In einigen Notationen ist es sogar nicht unterscheidbar.

Das für mich eindringlichste Argument von XML aus der XML-Welt ist aber die Kompaktform von RELAX-NG, welche deutlich lesbarer (aber genauso maschinenlesbar) ist wie die XML-Form.

Also, nennt mir doch mal bitte eure persönlichen Argumente für XML (dagegen habe ich schon eigene ). Es geht hier also wirklich darum, vorzugsweise positive, Argumente für XML zu sammeln. Kurz: überzeugt mich mit Fakten

NB: bitte auch das jeweilige Anwendungsgebiet mit benennen, denn logischerweise macht sowas nur im Zusammenhang Sinn

[rollstuhlfahrer]

XML macht beim Datenaustausch schon Sinn, also auch nur da, wo es nicht bessere Lösungen wie Records gibt. Mal ein Beispiel: Dynamische Webseiten laden meist irgendwas nach. Wenn sie dann besonders Flash-lastig sind, ist das meist XML, weil Flash eben dieses XML besonders gut handhabt. Hat man jetzt mehr mit JavaScript zu tun, ist XML auch vorne mit dabei (weil man nicht immer ein eigenes Format einführen muss und der Browser das eh lesen kann), aber JSON ist da bei mir an Stelle 1, weil IE und Firefox das XML unterschiedlich abarbeiten. Bei JSON ist das wenigstens einheitlich.

Noch ein Argument für XML: Man kann einfache Strukturen abspeichern und sie auch wieder auslesen, ohne gleich eine Datenbank nehmen zu müssen, weil eine Datenbank in etwa so wäre, als würde man mit Kanonen auf Spatzen schießen. Dies gilt nur, solange man keine komplexen Abfragen haben möchte oder gar die Datenmenge sortiert und nach einem bestimmten Kriterium ausgewertet haben möchte.

Außerdem lässt XML das zu, was bei Records neben dem Speichern von langen Strings nur sehr bedingt möglich ist: Unterschiedliche Informationen. Wenn man jetzt eine einzige Konfigurationsdatei hat und sehr verschiedene Parameter speichern will, geht das mit XML besonders einfach (ja, INI gibts auch, das ist aber schon älter).

Bernhard

[Luckie]

Als Vorteil gegenüber was? Um Programmeinstellungen zu Speichern würde ich immer noch Ini-Dateien nehmen, weil man da meist eindimensionale Strukturen hat. So bald man aber mehrdimensionale oder sich wiederholende Strukturen hat bietet sich XML an. Konkretes Beispiel? Puh, fällt mir jetzt konkret nichts ein, kann ich dir aber sagen, wenn wir uns mal zu einem Bier treffen.

Als Nachteil sehe ich aber, dass XML meist recht viel Overhead hat und in einem Texteditor nicht immer einfach zu lesen ist im Gegensatz zu Ini-Dateien.

Dein Problem mit den kaputten XML-Dateien, wenn die Bearbeitung unterbrochen wurde, würde ich wie folgt lösen: Es wird eine Backup-Datei von der letzten heilen Datei angelegt. Ist die neue, editierte Datei fehlerhaft, wird auf das Backup zurückgegriffen. So greifen zwar nicht die Änderungen, aber das Programm funktioniert. Also ein ähnliches Vorgehen, wie bei Windows mit den ControlSets, wo man beim Booten die letzte funktionierende Konfiguration auswählen kann, wenn die aktuelle kaputt ist.

[himitsu]

Es ist nicht so, daß die Parser damit nicht klar kommen, wenn ein Tag nicht geschlossen wird.
Vielmehr ist es so, daß es laut XML-Spezifikation verboten ist, daß es offene Tags gibt und es ist vorgeschrieben, daß ein Parser in soeinem Fall einen Fehler auslösen soll.

Selbst mein Parser wirft in soeinem Fall eine Exception, obwohl man dieses auch geziehlt deaktivieren kann ... z.B. kann, in Bezug auf eine teilweise Kompatibilität zum HTML, das <br>-Tag als offen deklariert werden, wobei es dann auch immer offen sein muß.
PS: Seit XHTML ist es auch in HTML vorgeschrieben, daß das <br> als offen markiert sein muß, also <br/> ... als kompatibilität zum XML.

Selbst wenn der Programmierer Mist baut und etwas beim Speichern schief geht oder diese Bearbeitung vorzeitig abgebrochen wurde, dann schließt eine ordentliche XML-Lib immer alle offenen Tags.

Wenn beim Speichern etwas Schwerwiegendes passiert, dann ist es doch egal, ob XML oder was Anderes ... in allen Fällen ist die Datei defekt.
Aber notfalls kann man viele XML-Parser auch so einstellen, daß sie dennoch die XML auslesen und zugänglich machen, bis zum ersten schweren Fehler.

Wozu soll es denn Konventionen geben?
Es ist deine Entscheidung, ob du lieber ein Attribut oder nicht nutzt.
Die Aufteilung der Daten ist nicht vorgeschrieben, sondern nur deren Format.
Grundsätzlich kann man aber sagen, daß bei vielen und/oder großen Daten-Einheiten lieber auf SubNodes, anstatt auf Attribute gesetzt werden sollte.



Auch wenn die Vorteile schon mehrfach/ständig genannt wurden.
Vorteile:
- es ist ein genormtes und weit verbreitetes Datenformat
- automatische Speicherverwaltung (der Programmierer muß sich um nix kümmern)
- viele Umgebungen (Delphi, PHP, JS, ...) haben schon passende DOM-Parser integriert, welche natürlich alle Kompatibel sind
- man kann die Stucktur erweitern/ändern, ohne die Datei extra konvertieren zu müssen und bei einer Erweiterung bleiben oftmals alte Programme weiterhin lauffähig
- die Datei ist vom Menschen lesbar/änderbar, ohne spezielle Anzeigeprogramme

Nachteile:
- die Datei ist oftmals größer, als eine Binärdatei
- die Datei ist ganz leicht vom Menschen lesbar (Grundsätlich erstmal keine Geheimnisse)


@Luckie:
Eine XML-Datei, mit entsprechenden Einrückungen und Zeilenumbrüchen kann sogar besser lesbar sein, als eine INI.

[patti]

Wow, das passt ja wie die Faust aufs Auge zu der Vorlesung zu "XML", die ich heute gehört habe
Ich zitiere jetzt mal mehr oder weniger die Aussagen aus dieser Vorlesung:

XML eignet sich bei unstrukturierten, "semi-strukturierten" oder schemalosen Daten und eignet sich vor allem zum Austausch von Daten zwischen verschiedenen Anwendungen, da Meta-Daten zu den eigentlichen Daten immer mitgeliefert werden. Eine weitere Möglichkeit von XML ist die Darstellung/Präsentation der Daten in unterschiedlichen Formaten, was durch den Einsatz von XSL ("Stylesheets") ermöglicht wird. Als Hauptargumente für das XML-Format wurden in der Vorlseung angegeben:

Wiederverwendbarkeit
Zusammensetzung von XML-Dokumenten aus externen Entities, ohne diese zu replizieren
"Modularisierung" von Dokumenten
Verringerung des Datenvolumens und Vermeidung von Redundanz

Erweiterte Referenzierbarkeit
Wechselseitige Referenzierung zwischen Dokumenten
Zeiger auf mehrere Ziele möglich

Des Weiteren ist es durch den Einsatz von XPath möglich, Datenbank-ähnliche Abfragen zu erstellen und somit gezielt auf die gespeicherten Daten zuzugreifen.


Ich kann die einzelnen Punkte nicht bewerten, da ich mich leider bisher noch nie wirklich mit diesem Thema beschäftigt habe. Ich kann daher nicht sagen, was in der Praxis wirklich zutrifft.

mfg

[BUG]

Wenn du eine einfache Struktur für deine XML-Dokumente wählst, sollte es doch machbar sein, ein Tool zu schreiben, dass die von dir erstellte XML-Datei "repariert" (Tags schließen, nötige Elemente anhängen).

[Sir Rufo]

Also das Problem mit den nicht geschlossenen Tags würde ich ja mal nicht überbewerten.

Dafür kann man sich entsprechend sichere Speichermethoden schreiben (wie man das bei jedem Format machen sollte) und die Datei ist zu einem sehr hohen Prozentsatz konsistent.

Es gibt Fälle wo es nicht konsistent ist, aber wo man - ein entsprechendes Konzept vorausgesetzt - immer die letzte konsistente Version nehmen kann.

Vermutlich willst du (Assarbad) auf das serielle Schreiben der XML Datei raus, wo die Daten tatsächlich bei einem Absturz inkonsistent sind.
So sollte man das auch nicht machen.

[Assarbad]

Danke erstmal für die rege Beteiligung.

Zitat von Sir Rufo:

Es gibt Fälle wo es nicht konsistent ist, aber wo man - ein entsprechendes Konzept vorausgesetzt - immer die letzte konsistente Version nehmen kann.

Bei Konfigurationsdateien könnte das in der Tat klappen.

Zitat von Sir Rufo:

Vermutlich willst du (Assarbad) auf das serielle Schreiben der XML Datei raus, wo die Daten tatsächlich bei einem Absturz inkonsistent sind.
So sollte man das auch nicht machen.

Was schlägst du stattdessen vor? Im Speicher halten geht schonmal nicht, wenn wir davon ausgehen daß durchaus mehrere GiB als Logdatei ("nur Text") herauskommen können. XML neigt ja eher dazu das gegenüber einfachem Text aufzublähen

Zitat von BUG:

Wenn du eine einfache Struktur für deine XML-Dokumente wählst, sollte es doch machbar sein, ein Tool zu schreiben, dass die von dir erstellte XML-Datei "repariert" (Tags schließen, nötige Elemente anhängen).

Mmmhnja ... irgendwie dann auch frickelig.

Zitat von patti:

Wiederverwendbarkeit
Zusammensetzung von XML-Dokumenten aus externen Entities, ohne diese zu replizieren
"Modularisierung" von Dokumenten
Verringerung des Datenvolumens und Vermeidung von Redundanz

Solche kompletten Parser mit "Validation" sind aber relativ dick (Bsp. Xerces).

Zitat von patti:

Erweiterte Referenzierbarkeit
Wechselseitige Referenzierung zwischen Dokumenten
Zeiger auf mehrere Ziele möglich

Das ist mal ein interessanter Punkt. Daran habe ich noch nicht gedacht. Vielleicht läßt sich mit dem Ansatz das Problem so umformulieren, daß es wieder Sinn macht.

Zitat von himitsu:

Es ist nicht so, daß die Parser damit nicht klar kommen, wenn ein Tag nicht geschlossen wird.
Vielmehr ist es so, daß es laut XML-Spezifikation verboten ist, daß es offene Tags gibt und es ist vorgeschrieben, daß ein Parser in soeinem Fall einen Fehler auslösen soll.

Ja gut, Parser oder Spezifikation ist dem Endbenutzer eigentlich egal. Mir als Entwickler übrigens auch

Zitat von himitsu:

Selbst wenn der Programmierer Mist baut und etwas beim Speichern schief geht oder diese Bearbeitung vorzeitig abgebrochen wurde, dann schließt eine ordentliche XML-Lib immer alle offenen Tags.

Nicht wenn das Betriebssystem den Prozeß beendet ...

Zitat von himitsu:

Wenn beim Speichern etwas Schwerwiegendes passiert, dann ist es doch egal, ob XML oder was Anderes ... in allen Fällen ist die Datei defekt.

Transaktionsbasierte Datenbanken!

Naaah gut, ab Vista geht das auch mit XML

Zitat von himitsu:

Aber notfalls kann man viele XML-Parser auch so einstellen, daß sie dennoch die XML auslesen und zugänglich machen, bis zum ersten schweren Fehler.

Ich sehe, daß ich mich vermutlich mit derlei Alternativen auseinandersetzen muß.

Zitat von himitsu:

Wozu soll es denn Konventionen geben?

Der Eindeutigkeit halber.

Zitat von himitsu:

Es ist deine Entscheidung, ob du lieber ein Attribut oder nicht nutzt.
Die Aufteilung der Daten ist nicht vorgeschrieben, sondern nur deren Format.
Grundsätzlich kann man aber sagen, daß bei vielen und/oder großen Daten-Einheiten lieber auf SubNodes, anstatt auf Attribute gesetzt werden sollte.

Aha. Kann man das auch von einer Autorität außerhalb der DP haben?

Zitat von himitsu:

automatische Speicherverwaltung (der Programmierer muß sich um nix kümmern)

... ist das dein Ernst?

Zitat von himitsu:

viele Umgebungen (Delphi, PHP, JS, ...) haben schon passende DOM-Parser integriert, welche natürlich alle Kompatibel sind

Das ist in der Tat ein Pluspunkt.

Zitat von himitsu:

man kann die Stucktur erweitern/ändern, ohne die Datei extra konvertieren zu müssen und bei einer Erweiterung bleiben oftmals alte Programme weiterhin lauffähig

Es sei denn sie sind dusselig programmiert

Zitat von Luckie:

Puh, fällt mir jetzt konkret nichts ein, kann ich dir aber sagen, wenn wir uns mal zu einem Bier treffen.

Ach ja? Ist das ne Einladung?

Zitat von rollstuhlfahrer:

Noch ein Argument für XML: Man kann einfache Strukturen abspeichern und sie auch wieder auslesen, ohne gleich eine Datenbank nehmen zu müssen, weil eine Datenbank in etwa so wäre, als würde man mit Kanonen auf Spatzen schießen. Dies gilt nur, solange man keine komplexen Abfragen haben möchte oder gar die Datenmenge sortiert und nach einem bestimmten Kriterium ausgewertet haben möchte.

Hmm, womit wir wieder bei relativ kleinen Datenmengen sind.

Zitat von rollstuhlfahrer:

Außerdem lässt XML das zu, was bei Records neben dem Speichern von langen Strings nur sehr bedingt möglich ist: Unterschiedliche Informationen. Wenn man jetzt eine einzige Konfigurationsdatei hat und sehr verschiedene Parameter speichern will, geht das mit XML besonders einfach (ja, INI gibts auch, das ist aber schon älter).

Du meinst weil man Typen wie Bool, Ganzzahl oder Text (oder deren Kombinationen) einfach gemeinsam abspeichern kann? Guter Punkt.

[Luckie]

Zitat von Assarbad:

Zitat von Luckie:

Puh, fällt mir jetzt konkret nichts ein, kann ich dir aber sagen, wenn wir uns mal zu einem Bier treffen.

Ach ja? Ist das ne Einladung?

Ja, aber eigentlich wollte ich nur etwas Zeit schinden.

[stahli]

Mich hat XML zumindest zum speichern von komplexen Objekten nicht überzeugt. Ich fand zwar den Ansatz und die Möglichkeit, den XML-Experten zu nutzen, sehr interessant aber dann im Handling doch zu kompliziert und unflexibel.

Daher habe ich für meine Objekte eine eigene Dateistruktur festgelegt (ähnlich JSON). In dieser können sich die Objekte auch gegenseitig referenzieren.
Beim Laden einer Datei werden die Objekte dann wieder hergestellt. Dazu dienen ID´s, die in den Objekten und der Datei gespeichert sind.

Im Gegensatz zu XML können Knoten problemlos leer sein bzw. komplett fehlen. Die tatsächliche Struktur ist über die Objekte im Hauptspeicher definiert. Diese lesen dann (wenn vorhanden) ihre Daten aus der Datei.
Im Grunde wird die Datei etwa wie eine "mehrdimensionale Ini" genutzt. Dabei ist die Reihenfolge der Einträge nicht relevant, sondern lediglich die Struktur und "Feldnamen".

Binäre Daten (im Beispiel Picture) werden im Base64-Format abgelegt.

Nachteile des Konzepts sind, dass
- die Datei recht groß wird (allerdings dann auf Wunsch komprimiert wird)
- die Daten zur Laufzeit im Hauptspeicher gehalten werden
(wobei letzteres wie in meinem Fall natürlich auch explizit gewollt sein kann )

...oh, ich schwiff ab...


Für den Datenaustausch mit feststehenden Strukturen halte ich XML jedoch durchaus für nützlich und praktikabel.

Code:

!ProgramName=Olympic
!ProgramVersion=(V. 0.2.1-)
<TournamentEvent=20100906211710810-20100906211711470-0000000006
  Name=Test
  <State=20100914105207021-20100914105207611-0000000008
  >
  <Sport=20100827212547328-20100827212547942-0000000002
    Name=Badminton
    SportPlaceName=Feld
    <NumeratorList=20100827212547328-20100827212547942-0000000003
      <Numerator=20100827212547328-20100827212702853-0000000005
        Activate=True
        Definition=0..19:21;20..28:+2;29:30
        Name=Rallypoint
        PlanDuration=30
        PointName=Bälle
        WinSetCount=2
      >
      <Numerator=20100827212547328-20100827212808350-0000000006
        Activate=True
        Definition=0..14:15;14..16:17
        Name=alte Zählweise bis 15
        PlanDuration=40
        PointName=Bälle
        WinSetCount=2
      >
      <Numerator=20100827212547328-20100827212845934-0000000007
        Activate=True
        Definition=0..10:11;10..12:13
        Name=alte Zählweise bis 11
        PlanDuration=25
        PointName=Bälle
        WinSetCount=2
      >
    >

...

            <Member=20101025203449672-20101025203508688-0000000203
              Activate=True
              <Person=20101025203449672-20101025203508688-0000000204
                Birthday=01.01.1901
                eMail=[e-mail]
                FirstName=René
                Kind=m
                LastName=Preißler
                Picture=eJzt3edTFFu/L/B7/pP74t6qc8/z7GfvrUhO5iw5JxVzjtucA2IElSw55yQ554xIFA........
                <State=20101129225442228-20101129225526456-0000004171
                >
              >
            >
...


  >
>