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

.filmor

minhen schrieb:

Extensible Markup Language W3C Recommendation schrieb:

This document specifies a syntax created ... for use on the World Wide Web ...

!

XML ist meiner Meinung nach ne tolle Sache, aber (im Allgemeinen) nicht für Konfigurationsdateien, sondern eher für etwas, was in irgendeiner Weise mit Browsern in Berührung kommen könnte.

Bezüglich den XML Conformance Tests kann ich den Link nachreichen: http://www.oasis-open.org/committees/xml-conformance/

rüdiger schrieb:

Daher findet man oft Parser, die entweder immer zu wenig können oder viel zu viel.

Deiner Meinung nach ist es also die "Schuld" von XML, dass sich darum weitere Standards gebildet haben? Dem kann man doch absolut zustimmen. Ich würde sogar so weit gehen HTTP die Schuld an "Buzzword-Technologien" wie SOAP zu geben ...

rüdiger schrieb:

Und für das eigentliche Thema, Konfigurationsdateien braucht man eher ein sinnvolles Mapping von Datenstrukturen in der Programmiersprache zu Datenstrukturen im Textformat und da ist XML eben nicht optimal für

Wie ich eigentlich bereits erwähnt habe, ist das sehr wohl möglich, so "unoptimal" XML auch dafür sein mag.

http://jakarta.apache.org/commons/digester/ schrieb:

Many Jakarta projects read XML configuration files to provide initialization of various Java objects within the system. There are several ways of doing this, and the Digester component was designed to provide a common implementation that can be used in many different projects.

Basically, the Digester package lets you configure an XML -> Java object mapping module, which triggers certain actions called rules whenever a particular pattern of nested XML elements is recognized. [...]

.filmor schrieb:

XML ist meiner Meinung nach ne tolle Sache, aber (im Allgemeinen) nicht für Konfigurationsdateien, sondern eher für etwas, was in irgendeiner Weise mit Browsern in Berührung kommen könnte.

Ich würde dir ja gerne Beispiele für C++ Projekte nennen, die sich für eine XML Konfigurationsdatei entschieden haben, aber das ist nicht mein Metier. Stattdessen kann ich dir halt Hibernate Mapping Dateien, Spring Konfigurationsdateien, etc. empfehlen, die allesamt mit XML gut beraten sind.

DEvent

Ohman was für'n Diskussion. Dabei ist es doch ganz einfach:
Ini-Dateien sind nirgendwo standardisiert, jeder Programmierer denkt sich sein eigenes Format aus. Zumindest habe ich noch nie von einem ini-Standard gehört.

Wenn du ohne groß nachdenken Daten abspeichern willst, würde ich XML nehmen, weil es genug Leute gibt, die sich tagtäglich mit dem Standard beschäftigen und Parser bauen. Dabei hast du den Vorteil das sich das XML-Format abwärts- und aufwärstkompatibel bleibt. Das heißt du kannst einen x belieben Parser nehmen und kannst Daten in deine Config-Datei schreiben und lesen.

Dabei hast du noch den Vorteil das XML eine Baumstruktur ist, Attribute hat, namespaces usw.

Also kurzum: Ini-datei: Kein Standard, XML: Standard.

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

Was soll da passieren? Bis auf die Tatsache das die Config-Datei ziemlich unübersichtlich ist.

Also ich find's unübersichtlich. Da steht so ein [global] bis wohin gilt das wohl? Ausserdem kann man die einzelnen Einstellungen mischen, also in Zeile 50 eine Zeile printer-Setting, in Zeile 10 dann socket options und in Zeile 100 irgendwas vom cd-rom.

XML wäre da weitsaus übersichtlicher.

DEvent schrieb:

Was soll da passieren? Bis auf die Tatsache das die Config-Datei ziemlich unübersichtlich ist.

Naja, und glaubst der Parser wird sie übersichtlicher "sehen"? Bevor du jetzt fragst, ob es dem Parser nicht schei*egal sein kann, wie übersichtlich eine Datei ist, denk einfach noch ein wenig weiter.

Blue-Tiger

DEvent schrieb:

Ohman was für'n Diskussion. Dabei ist es doch ganz einfach:
Ini-Dateien sind nirgendwo standardisiert, jeder Programmierer denkt sich sein eigenes Format aus. Zumindest habe ich noch nie von einem ini-Standard gehört.

Wenn du ohne groß nachdenken Daten abspeichern willst, würde ich XML nehmen, weil es genug Leute gibt, die sich tagtäglich mit dem Standard beschäftigen und Parser bauen. Dabei hast du den Vorteil das sich das XML-Format abwärts- und aufwärstkompatibel bleibt. Das heißt du kannst einen x belieben Parser nehmen und kannst Daten in deine Config-Datei schreiben und lesen.

Dabei hast du noch den Vorteil das XML eine Baumstruktur ist, Attribute hat, namespaces usw.

Also kurzum: Ini-datei: Kein Standard, XML: Standard.

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

Was soll da passieren? Bis auf die Tatsache das die Config-Datei ziemlich unübersichtlich ist.

Also ich find's unübersichtlich. Da steht so ein [global] bis wohin gilt das wohl? Ausserdem kann man die einzelnen Einstellungen mischen, also in Zeile 50 eine Zeile printer-Setting, in Zeile 10 dann socket options und in Zeile 100 irgendwas vom cd-rom.

XML wäre da weitsaus übersichtlicher.

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.

THX 1138

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*

# An HTML'ized description of all settings (based on comments in this file,
# with alphabetical table of settings and with table of settings by category)
# is available at http://www.hippo.ru/~hvv/lynxcfg_toc.html
#
### The conversion is done via the scripts/cfg2html.pl script.
### Several directives beginning with '.' are used for this purpose.

.h1 Auxiliary Facilities
# These settings control the auxiliary navigating facilities of lynx, e.g.,
# jumpfiles, bookmarks, default URLs.

.h2 INCLUDE
# Starting with Lynx 2.8.1, the lynx.cfg file has a crude "include"
# facility.  This means that you can take advantage of the global lynx.cfg
# while also supplying your own tweaks.
#
# You can use a command-line argument (-cfg /where/is/lynx.cfg) or an
# environment variable (LYNX_CFG=/where/is/lynx.cfg).
# For instance, put in your .profile or .login:
#
#   LYNX_CFG=~/lynx.cfg; export LYNX_CFG   # in .profile for sh/ksh/bash/etc.
#   setenv LYNX_CFG ~/lynx.cfg             # in .login for [t]csh
#
# Then in ~/lynx.cfg:
#
#   INCLUDE:/usr/local/lib/lynx.cfg
#           ^^^^^^^^^^^^^^^^^^^^^^^ or whatever is appropriate on your system
# and now your own tweaks.
#
# Starting with Lynx 2.8.2, the INCLUDE facility is yet more powerful.  You can
# suppress all but specific settings that will be read from included files.
# This allows sysadmins to provide users the ability to customize lynx with
# options that normally do not affect security, such as COLOR, VIEWER, KEYMAP.
#
# The syntax is
#
#   INCLUDE:filename for <space-separated-list-of-allowed-settings>
#
# sample:
.ex
#INCLUDE:~/lynx.cfg for COLOR VIEWER KEYMAP
# only one space character should surround the word 'for'.  On Unix systems ':'
# is also accepted as separator.  In that case, the example can be written as
.ex
#INCLUDE:~/lynx.cfg:COLOR VIEWER KEYMAP
# In the example, only the settings COLOR, VIEWER and KEYMAP are accepted by
# lynx.  Other settings are ignored.  Note:  INCLUDE is also treated as a
# setting, so to allow an included file to include other files, put INCLUDE in
# the list of allowed settings.
#
# If you allow an included file to include other files, and if a list of
# allowed settings is specified for that file with the INCLUDE command, nested
# files are only allowed to include the list of settings that is the set AND of
# settings allowed for the included file and settings allowed by nested INCLUDE
# commands.  In short, there is no security hole introduced by including a
# user-defined configuration file if the original list of allowed settings is
# secure.

jede Menge Kommentar, was will man mehr?

und einfach zu parsen ist es auch, so what?

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