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

[minhen]

Rhombicosidodecahedron schrieb:

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

Wie kommst du darauf?

[jemand aus dem wald]

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?

[jemand aus dem wald]

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.

[darthdespotism]

Blue-Tiger schrieb:

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

Es würde wohl reichen, kann aber zu schwehr auffindbaren Bugs führen wenn irgendwo ein schlusstag fehlt.

Enthalten die Schlusstags den namen lässt sich das meist automatisch prüfen

[rüdiger]

minhen schrieb:

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.

Wie gesagt, es gibt alternative Formate, die leichter zu parsen sind (und leichter in eine Vernünftige Datenstruktur konvertierbar sind) und nach meiner Meinung auch leichter lesbar sind

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.

Einen Link hab ich nicht mehr. OASIS XML Compliance Test heißt das Ding, wenn du danach googeln willst.

[c.rackwitz]

ich bin fuer buzzword bingo.

[minhen]

rüdiger schrieb:

Wie gesagt, es gibt alternative Formate, die leichter zu parsen sind (und leichter in eine Vernünftige Datenstruktur konvertierbar sind) und nach meiner Meinung auch leichter lesbar sind

Mal angenommen du hättest recht, so ist die einzige brauchbare Alternative, die du genannt hast, YAML. Und auch das kann XML leider (noch?) nicht das Wasser reichen. Dabei geht's noch nicht mal darum, ob

YAML Working Draft schrieb:

This specification is a draft reflecting consensus reached by members of the yaml-core mailing list.

als Spezifikation und Standardisierungsorganisation besser oder schlechter ist als

Extensible Markup Language W3C Recommendation schrieb:

This document specifies a syntax created by subsetting an existing, widely used international text processing standard (Standard Generalized Markup Language, ISO 8879:1986(E) as amended and corrected) for use on the World Wide Web. It is a product of the XML Core Working Group as part of the XML Activity. (...) This document is a W3C Recommendation.

sondern darum, dass XML schlicht produktiver ist. Eine Infrastruktur, die sich mit der von XML verlgeichen lassen könnte, fehlt bei YAML einfach. Die Gründe dafür stecken ja auch schon in den Zitaten. Das ist ein Punkt, der nicht zu verachten ist. Das kann sich in Zukunft vielleicht auch für YAML verbessern, aber Stand jetzt fährt man mit XML schlicht "sicherer" und bequemer.

[Blue-Tiger]

minhen schrieb:

rüdiger schrieb:

Wie gesagt, es gibt alternative Formate, die leichter zu parsen sind (und leichter in eine Vernünftige Datenstruktur konvertierbar sind) und nach meiner Meinung auch leichter lesbar sind

Mal angenommen du hättest recht, so ist die einzige brauchbare Alternative, die du genannt hast, YAML. Und auch das kann XML leider (noch?) nicht das Wasser reichen. Dabei geht's noch nicht mal darum, ob

YAML Working Draft schrieb:

This specification is a draft reflecting consensus reached by members of the yaml-core mailing list.

als Spezifikation und Standardisierungsorganisation besser oder schlechter ist als

Extensible Markup Language W3C Recommendation schrieb:

This document specifies a syntax created by subsetting an existing, widely used international text processing standard (Standard Generalized Markup Language, ISO 8879:1986(E) as amended and corrected) for use on the World Wide Web. It is a product of the XML Core Working Group as part of the XML Activity. (...) This document is a W3C Recommendation.

sondern darum, dass XML schlicht produktiver ist. Eine Infrastruktur, die sich mit der von XML verlgeichen lassen könnte, fehlt bei YAML einfach. Die Gründe dafür stecken ja auch schon in den Zitaten. Das ist ein Punkt, der nicht zu verachten ist. Das kann sich in Zukunft vielleicht auch für YAML verbessern, aber Stand jetzt fährt man mit XML schlicht "sicherer" und bequemer.

Es geht hier immer noch um Konfigurationsdateien, nicht um die eierlegende Wollmilchsau um alle moeglichen strukturierten Texte abzuspeichern. Und da brauch ich keine grosse Infrastruktur

[SideWinder]

Das schöne an XML ist, dass du nur das benutzt was du benötigst. Wie gesagt: Leichter als mit TinyXML kann ichs mir kaum vorstellen

MfG SideWinder

[rüdiger]

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

Ich fand die XML-Infrastruktur eher dürftig. Zwar gibt es für viele Dinge zusätzliche Spezifikationen, aber ich hatte in vielen Fällen das Problem dafür passende Implementierungen zu finden. Vor allem gibt es für alles verschiedene Spezifikationen, was auch die Interoperabilität einschränkt oder einige Dinge sind gar nicht finalisiert und ändern sich regelmäßig (dabei die ganzen anderen Buzzword-Technologien, wie SOAP, XML-Schemas (die eh nicht sinnvoll benutzbar sind, weil die Implementierungen dafür grotten lahm, komplex und gigantisch sind), XQuery etc.). Dann benötigen viele Technologien extra Parser (zB DTD, XPath, XQuery), was die ganzen XML-Implementierungen aufbläht. Daher findet man oft Parser, die entweder immer zu wenig können oder viel zu viel.

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 (Attribute sind bei so etwas schädlich, was auch wieder so ein "historischer" Ballast aus dem Markup-Bereich ist).

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

[jemand aus dem wald]

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.