Vorteile/Nachteile von XML

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


  >
>

[Medium]

Vom Grundsatz her kann XML nun erstmal wirklich nichts, was ich nicht auch mit meinem eigenen hübschen kleinen Binärformat auch erreichen könnte - allem Geschwafel zum Trotz was XML so alles toll machen soll. Mit Binary XML ist sogar innerhalb dieser Rahmen eine solche Variante bereits geschaffen worden.

Der für mich EINZIG gültige Vorteil ist, dass es ein fix und fertig standardisiertes Format ist, dass extrem weit verbreitet ist. Endianess? Egal. Bits einer FPU? Egal. Und vor allem kann man fast sicher in nahezu jeder ernsthaften DV Umgebung etwas finden, um mit einem XML Dokument etwas sinnvolles anzustellen, und sei es nur schon, dass in praktisch jeder halbwegs wichtigen Programmierumgebung fertige Lösungen existieren.

Fazit: Das für mich einzig hervorhebbare Pro-Argument von XML ist fast rein kaufmännischer Natur, lässt man mal aussen vor, dass sich auch so mancher Codehacker über etwas abgenommene Arbeit freuen könnte . Aber rein vom "was kann es mehr, was ich nicht auch selbst erdenken könnte"-Standpunkt aus, nö. Fällt mir nix ein.