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

THX 1138 schrieb:

Section "Screen"
Identifier "Default Screen"
Device "Geforce"
Monitor "iiyama ProLite E1900S"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480"
EndSubSection
EndSection

Na, also das geht ja gar nicht, denn da ist viel zu viel Balast dabei, der nur das menschliche Auge unterstützen soll. Ich denke dabei an diese ganzen EndSections, etc..

THX 1138

ja, echt die luxus variante

DEvent

Blue-Tiger schrieb:

Hmmmm... Also wie ein INI-File auszusehen hat weiss wohl jeder, dazu brauchts ja dann wohl keinen Standard Im Gegensatz zu XML, was kompliziert (sprich: umfangreich) genug ist um einen Standard zu brauchen. Wenn ich's mir aussuchen koennt, wo ich als Benutzer lieber rumfrickel, dann definitiv in INI-Files. Your mileage may vary.

Ja das war mein Punkt.
Muss er jetzt, aus irgendeinem Grund, eine andere Lib einsetzen, die INI-Files liest/schreibt, dann muss er seine Config-Datei neu schreiben.

hätte ich das nur früher gewusst, dass XML fast besser geht als Java

darthdespotism

THX 1138 schrieb:

Oh my god (musst ich jetzt einfach mal sagen)

Wo ist euer Problem? Er will Konfigurationen speichern
Section "Screen"
    Identifier     "Default Screen"
    Device         "Geforce"
    Monitor        "iiyama ProLite E1900S"
    DefaultDepth    24
    SubSection     "Display"
        Depth       24
        Modes      "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480"
    EndSubSection
EndSection
Selbsterklärend und "human-readable" *bingo*

Und was ist da jetzt das Problem stat Section ... EndSection da <> rum zu machen

<screen>
    <Identifier value="Default Screen"/>
    <Device value="Geforce"/>
    <Monitor value="iiyama ProLite E1900S"/>
    <DefaultDepth value=24/>
    <display>
        <Depth value=24/>
        <Modes value="1280x1024 | 1280x960 | 1152x864 | 1024x768 | 800x600 | 640x480"/> 
    </display>
<screen>

Und das könnte man dann bestimmt noch anpassen

DEvent

@darthdespotism
argh, Daten in den Attributen?? Seit wann sind die Daten worauf des ankommt Metadaten? Vor allem bei Modes ist es sowas von falsch.

<display>
    <depth>24</depth>
    <modes>
        <mode>1280x1024</mode>
        <mode>1280x960</mode>
        <mode>1152x864</mode>
        <mode>1024x768</mode>
        <mode>800x600</mode>
        <mode>640x480</mode>
    </modes>
</display>

minhen

rüdiger schrieb:

@minhen
Warum ist YAML die einzige alternative? Warum fährt man "sicherer" mit XML? Welche Infrastruktur meinst du?

Na schau dir doch mal die von dir genannten Alternativen an. Bei XML habe ich XML als Kern-Technologie, die einfach zu implementieren und gut zu handhaben ist. Wie ich eben am Beispiel der Namensräume auch erst ausgeführt habe, führen die zusätzlichen Möglichkeiten bei XML keinesfalls zu Einschränkungen der Interoperabilität wie du behauptest. Man hat einfach nur im Bezug auf Interoperabilität besonders durchdachte zusätzliche Möglichkeiten. Und für ein und die selbe Sache gibt es entgegen deiner Behauptung auch nicht verschiedene Spezifikationen. Aber es gibt gut ausgearbeitete Spezifikationen. Daran scheitern schon die meisten deiner "Alternativen". Ganz davon abgesehen, dass YAML, OGDL, noch nicht einmal stabile und finale Spezifikationen besitzen. Die Spezifikation von XML ist schon seit Jahren endgültig und entsprechend gut umgesetzt und verbreitet. Was du über XML sagst ist durch deine Alternativen geradezu absurd. Im Gegensatz zu diesen ist XML auch ein endgültiger, internationaler Standard. Das garantiert dir dann doch deutlich mehr Zukunftssicherheit als das, was eine Mailing-List als Arbeitsentwurf für eine Spezifikation (-> YAML) zusammengeschustert hat.
Von der Infrastruktur will ich eigentlich gar nicht erst anfangen. Wenn ich mag, kann ich XML-Dateien beliebig bündeln und zusammenwürfeln (Namensräume), ich kann XML-Dokumente von einem Format in ein anderes transformieren (XSLT), ich kann ihnen eine eigenständige optische Erscheinung geben (CSS, XSL-FO), ich kann eindeutige Verweise auf sehr einfache Weise innerhalb der Dokumente verwenden (id, xml:id), ich kann auch eindeutige Verweise auf externe Dokumente setzen (XLink), ich kann bestimmte Bereiche der Dokumente adressieren (XPath), ich kann große XML-Dokumente als Datenbank sehen (XQuery), ich kann die Struktur von XML-Dokumenten eindeutig definieren - für Konfigurationsdateien ist hier auch die Definition von Default-Werten ziemlich interessant - (DTD, XML Schema) und vor allem kann ich XML-Dokumente als Objekte in meinen Programmen verwenden (DOM).
All diese Technologien sind zusätzliche Möglichkeiten. Die Kerntechnologie XML wird dadurch in keinster Weise eingeschränkt. Ich kann diese Möglichkeiten nutzen, wenn sie mir sinnvoll erscheinen, und ich kann sie schlicht ignorieren und nicht verwenden wenn ich sie nicht brauche. Das gilt sowohl für die reine Anwenderseite als auch für das Entwickeln von Parsern. Ein Parser muss keine der genannten zusätzlichen Techniken unterstützen. Einzige Ausnahmen sind ein Teil der DTDs und die IDs, welche zum XML-Kern gehören. Wie am Beispiel der Namensräume schon ausgeführt, die zusätzlichen Möglichkeiten zerstören in keinster Weise die Interoperabilität als XML. Wie ebenfalls schon gesagt: der Kram ist eben gut durchdacht. Und zwar auch so weit, dass die jeweiligen Spezifikationen die Bereich sehr gut definieren. Die Sachen sind absolut eindeutig definiert. Da gibt's keine Unsicherheiten und kein Rätselraten. Die XML-Spezifikation gibt sogar Algorithmen an, die ich als Parserbauer nur abzutippen brauche.
Wie sieht's bei deinen "Alternativen" aus? Sind die ebenfalls so durchdacht und wohl definiert? Sind sie ebenfalls so offen und erweiterbar, was die Möglichkeiten angeht? (Antwort ist beide Male nein, hab mir die Spezifikationen angesehen)

Das ist aber noch nicht einmal das, was ich mit Infrastruktur meine. XML ist purer Text, im schlimmsten Fall reicht also ein billig einfacher Texteditor bereits für die Arbeit mit XML aus. Im weniger schlimmen Fall ein moderner Browser. XML, DOM, XSLT, XPath, CSS wird zum Beispiel von diesen Browsern unterstützt. Natürlich gibt es noch unzählige weitere Programme und Editoren für die Arbeit mit XML. Infrastruktur eben. Aber auch ganz normale Programme arbeiten mit XML ob es jetzt ein Microsoft Word oder meine MySQL-Datenbank ist, beide exportieren und importieren vergnügt XML. Solche Dinge machen einem das Leben natürlich schon angenehmer. Das wichtigste Argument für einen Entwickler dürfte aber die Unterstützung bei der Programmiersprache seiner Wahl sein. Und da ist XML eben auch unschlagbar. Parser für XML gibt es unzählige, einige davon auch mit Unterstützung der anfangs genannten zusätzlichen Möglichkeiten. Ein internationaler Standard eben. Von einer solchen Unterstützung wie ich es bei der Entwicklung von XML von allen Seiten bekomme, kann man bei deinen Alternativen nur träumen. Bei denen ist es bereits ein absoluter Glücksfall, wenn es überhaupt einen Parser für die gewünschte Sprache gibt.

THX 1138 schrieb:

und einfach zu parsen ist es auch, so what?

Erstens mal werden die wenigsten einen Parser schreiben wollen, zweitens ist das keine INI-Datei und drittens ist es nicht einfacher zu parsen als XML. Einfaches Beispiel:
Bei XML hab ich bei Knoten immer Tags als Begrenzung (</?[^>]+>) und bei Attributen immer doppelte Hochkommata als Begrenzung ("[^"]+"). (Die regulären Ausdrücke nicht als echten XML-Parser verstehen sondern als einfachste Möglichkeit ranzukommen.) Bei der Beispiel-Konfigurationsdatei dagegen ist einmal ein doppeltes Hochkomma die Begrenzung und einmal, bei Zahlen, gibt es überhaupt keine Begrenzung. Einfach sieht für mich anders aus und bedeutet keine Extrafälle bei Begrenzungen und erst recht keine Extrafälle die auch noch vom Inhalt des zu begrenzenden abhängen. Sowas ist doch schrecklich.

Bisher habe ich mich ja überhaupt nicht zum Thema Konfigurationsdateien geäußert, da ich INI auch für die bessere Wahl hielt, sofern man nicht schon einen XML-Parser an Bord hat. Aber je mehr die INI-Verteidiger hier sagen, desto offensichtlicher wird, dass auch als Konfigurationsdatei XML eine bessere Wahl ist. Sei es die Beliebigkeit, nicht-Standardisierung von INI, die fehlende Möglichkeit für Standard-Werte oder Sonderfälle beim Parsen. Bei XML habe ich diese Probleme nicht und stattdessen volle Unterstützung seitens der "Infrastruktur".
Gratulation! Anfangs war ich ja, wie gesagt, gar nicht der Meinung, dass XML besser geeignet sei und habe nur dem Unsinn, der im Zusammenhang mit XML hier verzapft wird, widersprochen. Aber jetzt habt ihr mich davon überzeugt, dass XML auch bei Konfigurationen die bessere Wahl ist

Anmerkung: bei xml kannst du auch einfache hochkommata als attributbegrenzer benutzen (aber nicht mischen). sonst stimmt natürlich alles

c.rackwitz

'(screen (identifier "Default Screen")
         (device "Geforce")
         (monitor "iiyama ProLite E1900S")
         (defaultdepth 24)
         (display (depth 24)
                  (modes (1280 1024)
                         (1280 960)
                         (1152 864)
                         (1024 768)
                         (800 600)
                         (640 480))))

http://steve.yegge.googlepages.com/the-emacs-problem

Artchi

Hem, ich würde heute keines von beiden (ini oder xml) benutzen. Sondern würde auf eine Scriptsprache wie lua zugreifen. Die ist ideal dafür und ursprünglich sogar dafür entwickelt worden. ini und xml sind in meinen Augen bzgl. Configurationsleistungen (also was sie effektiv können) gleichwertig. Wobei ich xml für Config überhaupt nicht verstehen kann. Es ist nur formal "besser". xml halte ich für Datenaustausch zwischen unterschiedlichen Systemen und Anwendungen für sehr nützlich, mehr auch nicht.

Jedenfalls könnte man mit lua in der Config-Datei auch Bedingungen u.ä. einbauen. Z.B. wenn eine bestimmte Bildschirmauflösung nicht vorhanden ist, wird eine andere gewählt. Sowas müsste man ohne scriptsprache im C++-Programm vorhersehen bzw. einbauen. Die Möglichkeiten der Configuration würden auch autom. steigen. Bei XML und INI ist es immer stur, der Anwender kann eigentlich nichts viel bewirken, außer Attribute ändern. Einen Wirklichen Einfluss hat er mit beiden nicht. Deshalb halte ich die Diskussion Ini vs XML für akademisch.

darthdespotism

Also wenn hier für einige XML schon zu schwehr zum Parsen ist, eine Skripsprache ist sicher nicht leichter.

Meiner bescheidenen Meinung nach hat jede Version seine Berechtigung, je nachdem was ausgedrückt werden soll.

ini für nicht verschachtelte, einfache Configurationsdateien, XML wenn mehr struktur nötig ist und eine Skriptsprache wenn dynamik nötig ist.

In meinem aktuellen Projekt (2D-Spiel) werden sowohl ini als auch xml-files verwendet, im nächsten gibts dann auch Skriptunterstützung überall wos nötig ist.

Hallo,

Artchi schrieb:

Jedenfalls könnte man mit lua in der Config-Datei auch Bedingungen u.ä. einbauen. Z.B. wenn eine bestimmte Bildschirmauflösung nicht vorhanden ist, wird eine andere gewählt. Sowas müsste man ohne scriptsprache im C++-Programm vorhersehen bzw. einbauen. Die Möglichkeiten der Configuration würden auch autom. steigen. [...]

Prinzipiell hast du natürlich Recht, allerdings ist diese zusätzliche Flexibilität meiner Ansicht nach bereits eine Art Gratwanderung, denn letztendlich müsste ja sozusagen eine auf Plugins basierende Architektur vorhanden sein, um deinen Anforderungen gerecht zu werden. Ansonsten hat der Benutzer ja auch nur jene Möglichkeiten der Konfiguration, die ihm der Entwickler einräumt und eine derartige Modularisierung ist auch absoluter Overhead für die meisten Anwendungen.

Artchi schrieb:

Einen Wirklichen Einfluss hat er mit beiden nicht. Deshalb halte ich die Diskussion Ini vs XML für akademisch.

Es ging auch nie darum, wann dem Benutzer mehr Möglichkeiten eingeräumt werden, sondern (meiner Ansicht nach) wie sich die Möglichkeiten besser strukturieren lassen.

Ich persönlich verwende solch einfache Property Dateien (bzw. INI Dateien, oder wie auch immer man sie nennen mag) eigentlich nur für einfachste Schlüssel=Wert Zuweisungen, die sich konsequent durchziehen, wie beispielsweise Lokalisierungsdateien, die halt eine Nachricht in einer bestimmten Sprache enthalten.

# Messages_de_DE
hello_world=Hallo Welt

# Messages_en_US
hello_world=Hello World

Falls allerdings eine Sammlung von Konfigurationsoptionen benötigt wird, die nicht eine ähnlich starke Kohäsion aufweist, verwende ich eine eine XML Datei mit beispielsweise einzelnen Sektionen, die gegebenenfalls oben angeführte Property Dateien importieren.

Ich würde gleich alles in C++ Code speichern, da kannst da alles machen.

darthdespotism

KETRAXONTOR schrieb:

Ich würde gleich alles in C++ Code speichern, da kannst da alles machen.

Für einfache Programme vielleicht sinnvoll.

Aber:

Der User kann nichts anpassen
Nach jeder Anpassung muss der Quellcode neu compiliert werden
Modifizierungen (Fremdsprachliche Versionen ...) sind viel komplizierter als sie sein müssten
Andere können bestimmt andere Einschränkungen aufzählen
...

DEvent

schrieb:

# Messages_de_DE
hello_world=Hallo Welt

# Messages_en_US
hello_world=Hello World
Falls allerdings eine Sammlung von Konfigurationsoptionen benötigt wird, die nicht eine ähnlich starke Kohäsion aufweist, verwende ich eine eine XML Datei mit beispielsweise einzelnen Sektionen, die gegebenenfalls oben angeführte Property Dateien importieren.

Wie unterscheidest du ob hello_world nun _de_DE ist oder _en_US? Durch die Kommentare?
Grade dazu eignet sich XML doch super:

<sprachen>
    <item name="hellow_word" language="en_US">Hello World</item>
    <item name="hellow_word" language="de_DE">Hallo Welt</item>
</sprachen>

@c.rackwitz: genau das hat minhen gemeint. Einmal wird "" als Begrenzer eingesetzt, einmal nichts. Dann wird sogar no-name-Tags eingesetzt

(1280 1024)
(1280 960)
(1152 864)
(1024 768)
(800 600)
(640 480)

An dem Parser will ich nicht arbeiten wollen.

Regexps suck for processing XML.

Das wundert mich jetzt aber extrem. Ist das wahr und ich verstehe noch weniger von regexps als ich dachte?

Artchi

Wie unterscheidest du ob hello_world nun _de_DE ist oder _en_US? Durch die Kommentare?

Speichert man in unterschiedliche Dateien ab, somit ist eine Einteilung gegeben:

Dateien:
texte_de_DE.properties
texte_en_US.properties

Hat er nur nicht explizit angegeben. Bei Programmstart wird je nach locale die entsprechende Datei geladen.

Artchi schrieb:

Hat er nur nicht explizit angegeben. Bei Programmstart wird je nach locale die entsprechende Datei geladen.

Danke, dass du das ergänzt hast. Ich dachte eigentlich, dass es klar ist, aber ich hätte wohl im Code Block explizit die Dateiendung anführen sollen, um die letzten Zweifel restlos zu beseitigen.

c.rackwitz

DEvent:
lern scheme, dann wirst du merken, warum mein beispielcode sinn macht.
code und daten sind potentiell das gleiche. die daten koennen sich selbst "ausfuehren". modes z.b. koennte seine argumente eben so interpretieren. kein thema. kannst du mit xml nicht.

rexen und xml suckt, weil rexen und ungeparster quellcode suckt. deswegen gibts refactoring tools mit code-awareness. die schnibbeln nicht einfach nur am text rum, die sind sich der semantik bewusst. rexen sind sich der semantik hinter spitzen klammenr und slashes (=xml) nicht bewusst.

z.b. koennen rexen keine rekursiven klammernpaare matchen. geht nicht. dazu brauchst du was maechtigeres als rexen: z.b. PEGs oder normales BNF. sind eigentlich auch nur rexen, aber mit rekursion. und die brauchst du um rekursion zu matchen.
alle baumstrukturen sind inherent rekursiv. deswegen kannst du mit rexen da nix gross ausrichten.

scheme/lisp parser sind mit die einfachsten parser fuer irgendeine sprache die es gibt. und wenn du erstmal einen hast, dann hast du nicht nur einen config parser, du hast potentiell ein ganzes scripting system.

lies doch einfach mal, was der stevey da geschrieben hat. und lern scheme. mit "sicp" und "plt scheme". ist wichtig. glaub mir.

ernsthaft. lern scheme.

hustbaer

Weils hier gerade inetwa dazupasst: kennt jmd. denn eine gute XML Library für C++? Wobei "gut" im Sinne von einfach zu verwenden -- muss nicht allen Schnickschnack können, Validierung etc. bräuchte ich alles nicht.
Das Interface sollte halt einfach und halbwegs modern sein, also wenn geht mit std::string/wstring arbeiten etc. - keine Zeiger zurückgeben die man selbst löschen muss etc.

SideWinder

hustbaer schrieb:

Weils hier gerade inetwa dazupasst: kennt jmd. denn eine gute XML Library für C++? Wobei "gut" im Sinne von einfach zu verwenden -- muss nicht allen Schnickschnack können, Validierung etc. bräuchte ich alles nicht.
Das Interface sollte halt einfach und halbwegs modern sein, also wenn geht mit std::string/wstring arbeiten etc. - keine Zeiger zurückgeben die man selbst löschen muss etc.

TinyXML

MfG SideWinder