Danke erstmal für die rege Beteiligung.
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.
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
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.
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).
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.
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
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
...
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
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ß.
Wozu soll es denn Konventionen geben?
Der Eindeutigkeit halber.
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?
automatische Speicherverwaltung (der Programmierer muß sich um nix kümmern)
... ist das dein Ernst?
viele Umgebungen (Delphi, PHP, JS, ...) haben schon passende
DOM-Parser integriert, welche natürlich alle Kompatibel sind
Das ist in der Tat ein Pluspunkt.
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
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?
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.
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.