Unterschiede (Vor- und Nachteile) vom XML gegenüber Ini-Dateien

Hallo

Der Titel sagt eigentlich schon alles. Ich verwende für meine Programme immer ini-Dateien und sehe immer öfter auch XML. Wo ist da der Vorteil?

chrische

lolz

Wenn ein normaler Benutzer auch mal die config Datei ändern soll, dann würd ich auch zur ini raten die sind ja doch sehr intuitiv

Aber wenn das gar nicht unbedingt das Ziel ist und du eh schon ne XML-Bibliothek im Programm hast, dann würd ich je nachdem auch XML benutzen, ist halt doch flexibler.

rüdiger

XML ist nicht für Konfigurations-Dateien gedacht!

XML ist schwer zu parsen und für Menschen schwer zu lesen/verstehen.

(der eigentliche Sinn von XML ist einfach die Markierung von Textstellen in langen Texten und nicht die eines Datenformates!)

darthdespotism

XML ist an sich sowohl auf- als auch abwärtskompatibel.

XML zu parsen braucht bei mir nicht so viel mehr Quellcode als bei ini-Dateien
Du spaarst aber schon ein paar Zeilen Code.

Warum XML schwehr von Menschen gelesen werden kann muss mir noch jemand erklären.

XML als Dateiformat ist auch außerhalb der Textgestaltung nicht selten oder?
YafRay - SVG ...

rüdiger

darthdespotism schrieb:

XML zu parsen braucht bei mir nicht so viel mehr Quellcode als bei ini-Dateien
Du spaarst aber schon ein paar Zeilen Code.

Einen XML-Parser zu schreiben ist keine leichte Aufgabe. Besorg dir einfach mal mehrere Parser und einen XML-Compliance-Test (von OASIS gibt es zB einen) und überprüf mal, wieviele Parser den bestehen (und wir groß die sind).

Warum XML schwehr von Menschen gelesen werden kann muss mir noch jemand erklären.

Bei großen Dokumenten mit ein wenig Markup ist das okay, dafür wurde XML ja auch eigentlich entworfen. Aber gerade Maschinengenerierter Code wird schnell unleserlich.

XML als Dateiformat ist auch außerhalb der Textgestaltung nicht selten oder?
YafRay - SVG ...

SVG ist doch ein Paradebeispiel dafür, das XML in solchen Bereichen nicht ideal ist. Quasi jedes Attribut hat eine eigene Meta-Syntax...

Hallo

Ich würde da für mich jetzt hören, dass es nicht unbedingt Sinn macht zu XML zu wechseln, sondern der ini-Datei treu zu bleiben.

chrische

darthdespotism

Wenn du ini klar kommst und das bereits hast würde ichs behalten.

Was mir gerade noch pro-XML gekommen ist:
Verschachtelung / Unterelemente lassen sich in XML ganz gut darstellen in ini wirds da wohl komplexer.

@ rüdiger Ich wette mein "XML"-Parser würde an den test vollständig versagen - ich habe in der aktuellen version noch probleme wenn vor und nach den tags nicht immer ein Whitespace ist - aber die recht primitive Welt meines Spiels lässt sich in der XML-ähnlichen strucktur schön strukturieren; den Zweck erfüllt er wunderbar

Gleicher Gedanke wie im Folgepost

Edited<<

minhen

rüdiger schrieb:

(der eigentliche Sinn von XML ist einfach die Markierung von Textstellen in langen Texten und nicht die eines Datenformates!)

Unsinn. XML ist historisch aus dieser Verwendung hervorgegangen, aber das bedeutet dummerweise nicht, dass XML nur dafür geeignet wäre. Wenn du jemals XML mit gemischtem Inhalt, also Elemente mit Tags und Zeichendaten auf der selben Ebene, verarbeiten musstest, wirst du wissen, dass das keinesfalls die schönste Verwendung von XML ist. Stattdessen wird mit XML ganz allgemein eine logische Struktur zum Speichern von Daten definiert. Und diese Struktur eignet sich hervorragend für Datenstrukturen wie Listen und Bäume. Letztlich ist jedes XML-Dokument als Datenstruktur ein Baum. Und genau in diesem Sinn wird XML heutzutage auch verwendet.

Rhombicosidodecahedron

Ini ist besser wenn du keine Hyrachien darstellen willst.

Wenn du nur Übersetzungstexte hast:

[english]
IDI_EXIT = &Ende
IDI_CANCEL  = Abbre&chen
...

ist Ini besser.

Ist das, was du abbilden möchtest etwas komplizierter, sehr viele Verschachtelungen, unterschiedliche Unterelemente und so gut wie gar keine Querverweise ist es besser XML zu verwenden.
Beispiel: (fast) jede Internetseite

Mit freundlichen Grüßen
Rhombicosidodecahedron

(mist zu spaet)

minhen

Rhombicosidodecahedron schrieb:

... so gut wie gar keine Querverweise ...

Wie kommst du darauf?

INI Files sind ja nicht mal plattformunabhängig.

XML ist schwer zu parsen.

Im Vergleich zu einer simplen "Name=Wert" Konfigurationsdatei vielleicht schon, allerdings ist das auch relativ egal, nachdem es ohnehin einen Überfluss an XML Parsern gibt, die frei verfügbar sind. Es soll sogar Sprachen geben, in denen XML sozusagen out-of-the-box verfügbar ist.

Aber gerade Maschinengenerierter Code wird schnell unleserlich.

Da musst du aber auch Beispiele nennen, denn ich hab beispielsweise mit generierten Hibernate Mapping Dateien kein Problem.

rüdiger

darthdespotism schrieb:

ich habe in der aktuellen version noch probleme wenn vor und nach den tags nicht immer ein Whitespace ist

lol da siehst du es ja, wie schwer es ist XML vernünftig zu parsen und ich wette du hast noch nicht mal namespaces eingebunden.

@minhen
Natürlich ist ein Format zum Abspeichern von Baumdaten sinnvoll. Ich finde nur XML nicht dafür sonderlich geeignet. Die Syntax ist für die Technik zu komplex, was sinnvolles parsen verhindert und eine sinnvolle Darstellung als Datenstruktur in einer Programmiersprache (Attribute sind für die Technik zB sinnlos, erschweren aber die Darstellung als Datenstruktur). Das es historisch eine Markup-Sprache ist merkt man einfach. Die redundanten Schluss-Tags stammen eben daher, das man nach hunderten Zeilen Text einfach mit dem menschlichen Auge zuordnen kann, welcher Tag geschlossen wird. Aber das macht bei einem Daten-Format (nicht im Sinne von Markup-Format) wenig sinn.

Und dann bietet XML ja auch relativ wenig an, dafür das es so komplex ist.

jemand aus dem wald schrieb:

INI Files sind ja nicht mal plattformunabhängig.

Wie kommst du darauf?

XML ist schwer zu parsen.

Im Vergleich zu einer simplen "Name=Wert" Konfigurationsdatei vielleicht schon, allerdings ist das auch relativ egal, nachdem es ohnehin einen Überfluss an XML Parsern gibt, die frei verfügbar sind. Es soll sogar Sprachen geben, in denen XML sozusagen out-of-the-box verfügbar ist.

XML-Parser gibt es wie Sand am Meer, das ist richtig. Aber zieht man dann die Parser ab, die XML nicht richtig umsetzen (da es einfach zu kompliziert ist, ist die Umsetzung nicht leicht und viele Parser fallen bei Tests wie denen von OASIS durch), bleiben schon mal wenige übrig.

Hat man dann noch einen extra Wunsch, wie Validierung, bleiben einem kaum noch Parser übrig und die die über bleiben haben dann auch unansehnliche Größen.

CMatt

XML-Parser gibt es wie Sand am Meer, das ist richtig. Aber zieht man dann die Parser ab, die XML nicht richtig umsetzen (da es einfach zu kompliziert ist, ist die Umsetzung nicht leicht und viele Parser fallen bei Tests wie denen von OASIS durch), bleiben schon mal wenige übrig.

Hat man dann noch einen extra Wunsch, wie Validierung, bleiben einem kaum noch Parser übrig und die die über bleiben haben dann auch unansehnliche Größen.

Kleine erinnerung an das Thema: er will ne Wahl ziwschen ini und XML treffen. Er braucht weder namespaces, noch XPath, noch Validierung noch nen 101% kompatiblen Parser, noch irgend welche anderen XML spezialfeatures.
tinyXML mit seinen 3 files tuts als ini ersatzt auch, ist also rein technisch komplett egal was ob XML oder ini, der aufwand ist der selbe. Ich personlich nehme für irgend welche settings immer XML (die mini version ohne xls, namespace, ..) da ich
a) tinyXML schon kenne und zu faul bin nach nem ini parser zu googlen oder die doku zu WritePrivateProfileString zu lesen
b) ich settings gern als baum abspeichere, auch im file, nicht nur logisch, mit tabs und so und das sieht bei ini schrecklich aus / geht nicht.

c.rackwitz

XML ist baumstruktur.
lisp ist baumstruktur.

welches ist wohl lesbarer?
welches kann man ausfuehren?
welches ist besser "erforscht"?
welches ist einfacher zu parsen?

was sinnvolles parsen verhindert und eine sinnvolle Darstellung als Datenstruktur in einer Programmiersprache

Das ist allerdings ein wenig zu allgemein formuliert, da beispielsweise Commons Digester die Abbildung einer XML Datei auf einen Objektgraphen ermöglicht. Attribute dienen übrigens dazu zwischen Daten und Metadaten differenzieren zu können.

Und dann bietet XML ja auch relativ wenig an, dafür das es so komplex ist.

Jetzt scheint es also auch komplex in der Verwendung zu sein, denn ansonsten kann ich deine Aussage nicht nachvollziehen (bzw. um meine Aussage zu korrigieren: Ich kann sie auch gemäßg dem Falle, dass meine Annahme richtig ist, nicht nachvollziehen.)

Wie kommst du darauf?

Konkretes Beispiel: Öffne einfach /etc/samba/smb.conf (oder eine andere Konfigurationsdatei deiner Wahl, die sozusagen das INI Format benutzt) mit Notepad.

XML-Parser gibt es wie Sand am Meer, das ist richtig. Aber zieht man dann die Parser ab, die XML nicht richtig umsetzen (da es einfach zu kompliziert ist, ist die Umsetzung nicht leicht und viele Parser fallen bei Tests wie denen von OASIS durch), bleiben schon mal wenige übrig.

Ich dachte eigentlich, dass klar herausgeht, dass ich eigentlich nur Sprachen verwende in denen XML eine Selbstverständlichkeit ist. Fehlende Unterstützung für XML ist für mich ein Armutszeugnis der jeweiligen Sprache und nicht von XML selbst (selbst PHP "kennt" XML out-of-the-box). Dein Argument ist für mich also ohne jegliche Praxisrelevanz, da es mir persönlich egal ist wieviele schlechte XML Parser es gibt.

Hat man dann noch einen extra Wunsch, wie Validierung, bleiben einem kaum noch Parser übrig und die die über bleiben haben dann auch unansehnliche Größen.

Einerseits wollen wir also Extrawünsche und andererseits wollen wir nichts dafür "bezahlen" (in Form von größeren Parsern). Nein, jetzt mal im Ernst, natürlich kann ein XML Parser unterschiedlich aufwendig implementiert werden, da es unterschiedliche APIs zum Zugriff gibt (DOM, SAX, ..), zusätzliche Abfragesprachen (XPath, XQuery, ..) und sonstige Tools oder Standards "drumherum" gibt (XSLT, ..), aber auch hier kann ich absolut keinen Kritikpunkt an XML ausfindig machen (vor allem, wenn ich bedenke, dass du andererseits auch behauptet hast, dass XML eigentlich wenig "kann").

rüdiger

CMatt schrieb:

Kleine erinnerung an das Thema: er will ne Wahl ziwschen ini und XML treffen. Er braucht weder namespaces, noch XPath, noch Validierung noch nen 101% kompatiblen Parser, noch irgend welche anderen XML spezialfeatures.

Warum sollte er dann XML nehmen?

Es gibt ja auch zahlreiche Alternativen, wie YAML, OGDL, S-Exps (und TDL :)) und mehr.

Ich personlich nehme für irgend welche settings immer XML (die mini version ohne xls, namespace, ..) da ich
a) tinyXML schon kenne und zu faul bin nach nem ini parser zu googlen oder die doku zu WritePrivateProfileString zu lesen

Das ist ja auch in Ordnung. Oft machen wir irgend welche Dinge, weil wir keine Minute drüber nachdenken wollen und da will ich ja auch gar nichts gegen Sagen (hehe, nicht nach dem Code den ich gerade gefrickelt habe ;)). Aber wenn sich der Thread-Ersteller die Mühe macht extra einen Thread zu erstellen, will er das ja sicher durchdenken.

(Vor allem sehe ich keinen Sinn das er XML nehmen sollte, wenn für ihn Ini offensichtlich ausreicht. Immerhin hat hier ja auch niemand behauptet, das XML einfacher zu parsen und handhaben sei. Es geht ja offensichtlich nur darum, das man in Ini-Dateien keine anderen Daten-Formate als a=b speichern kann)

hustbaer

Ich denke die wichtigste Frage ist ob es "Unterobjekte" gibt, also eben ob die Daten "baumartig" sind (falls es das Wort gibt ).

Bäume lassen sich zwar per naming-conventions auch in einem INI File abbilden, aber das wird sehr schnell sehr unübersichtlich.

byto

rüdiger schrieb:

Das es historisch eine Markup-Sprache ist merkt man einfach. Die redundanten Schluss-Tags stammen eben daher, das man nach hunderten Zeilen Text einfach mit dem menschlichen Auge zuordnen kann, welcher Tag geschlossen wird. Aber das macht bei einem Daten-Format (nicht im Sinne von Markup-Format) wenig sinn.

Und wie willst Du anders die Hierarchien beschreiben ohne solche End-Tags?

Blue-Tiger

hustbaer schrieb:

Ich denke die wichtigste Frage ist ob es "Unterobjekte" gibt, also eben ob die Daten "baumartig" sind (falls es das Wort gibt ).

Bäume lassen sich zwar per naming-conventions auch in einem INI File abbilden, aber das wird sehr schnell sehr unübersichtlich.

Also die INI-files von Unreal-Tournament find ich sehr uebersichtlich, obwohl sie geschachtelt sind.
Der riesengrosse Vorteil von INI-Dateien gegenueber XML-Dateien als Konfigurationsdateien ist, dass sie wesentlich leichter (von Menschen) versteh- und lesbar sind. Und dass die INI-Dateien dabei "flacher" sind, ist nur von Vorteil.

byto schrieb:

rüdiger schrieb:

Das es historisch eine Markup-Sprache ist merkt man einfach. Die redundanten Schluss-Tags stammen eben daher, das man nach hunderten Zeilen Text einfach mit dem menschlichen Auge zuordnen kann, welcher Tag geschlossen wird. Aber das macht bei einem Daten-Format (nicht im Sinne von Markup-Format) wenig sinn.

Und wie willst Du anders die Hierarchien beschreiben ohne solche End-Tags?

Na der Endtag muss nicht nichmal den Tagnamen enthalten, ein einfaches </> statt eines </foobar> reicht doch aus.

minhen

rüdiger schrieb:

lol da siehst du es ja, wie schwer es ist XML vernünftig zu parsen und ich wette du hast noch nicht mal namespaces eingebunden.

Was kein Problem ist. Denn Namespaces sind kein Teil der XML-Spezifikation. Um ein beliebiges XML-Dokument (selbst eines mit mehreren Namespaces) erstellen und verarbeiten zu können, muss ein XML-Prozessor diese zusätzliche Spezifikation nicht erfüllen. Die XML-Spezifikation sagt in dem Punkt auch klipp und klar: ein XML-Parser muss lediglich einen Doppelpunkt als Teil eines Namens akzeptieren, mehr nicht. Damit ist das Ziel, dass jeder alle XML-Dokumente parsen können soll, bereits erreicht. Man kann's kaum glauben, aber die Sache ist eben durchaus durchdacht. Die Namensräume selbst werden für einen Parser erst dann wichtig, wenn mehrere XML-Dokumente kombiniert werden. XML lässt sich relativ zum gebotenen Umfang eigentlich einfach verarbeiten. Das geht sogar so weit, dass die XML-Spezifikation höchstpersönlich bei XML-konformen Prozessoren zwischen "validating" und "non-validating" Parsern unterscheidet und Spielregeln definiert um die Interoperabilität zu gewährleisten. Ein non-validating Processor ist einfacher zu implementieren, gewährleistet aber auch das grundlegende Ziel: jedes beliebige XML-Dokument parsen zu können und der Anwendung Zugriff auf dessen Inhalt zu ermöglichen. XML ist einfach zu parsen. Natürlich nicht so einfach wie eine INI-Datei - aber der Vergleich verbietet sich ohnehin. Erstens haben beide unterschiedliche Einsatzgebiete und zweitens bietet XML eben auch mehr.

Die redundanten Schluss-Tags stammen eben daher, das man nach hunderten Zeilen Text einfach mit dem menschlichen Auge zuordnen kann, welcher Tag geschlossen wird. Aber das macht bei einem Daten-Format (nicht im Sinne von Markup-Format) wenig sinn.

Stimmt nicht ganz. Die redundanten Schluss-Tags sind in der Tat für das menschliche Auge gedacht. Aber das macht eben auch für ein Datenformat Sinn. Und zwar genau dann, wenn das Format "offen" und "zugänglich" sein soll. Das ist nebenbei ein Designziel von XML gewesen. Es ist mit voller Absicht das Gegenteil eines binären Formates. Die Verarbeitungsmöglichkeit soll bei XML nämlich eben nicht von einer Anwendung abhängen, die die Daten erst einmal in eine verständliche Form bringt und interpretiert. Stattdessen soll das Format eben wirklich offen sein.

Tim Bray schrieb:

This goal was motivated simply by the perception that textual formats are more open, more useful, and more pleasant to work with than binary formats. One of the substantial benefits of XML is that no matter how bad a day your tools are having, you can always pull an XML document into Emacs or Notepad or whatever your favorite editor is, and get useful work done.

XML-Parser gibt es wie Sand am Meer, das ist richtig. Aber zieht man dann die Parser ab, die XML nicht richtig umsetzen (da es einfach zu kompliziert ist, ist die Umsetzung nicht leicht und viele Parser fallen bei Tests wie denen von OASIS durch), bleiben schon mal wenige übrig.

Kannst du da bitte einen Link zu geben? Ich finde nur Tests für das OpenDocument-Format und nicht für XML-Konformität.