Welche Configuration File Formate benutzt Ihr in euren Projekten?

Dravere

Aus Anwendersicht empfinde ich YAML als benutzungsfreundlicher. Aus Programmierersicht gefällt mir JSON wegen der eher strikteren Regeln besser. JSON ist ja auch, wie bereits erwähnt, gültiges YAML 1.2.

Meistens setze ich JSON ein, vor allem weil meine Konfigurationsdateien nicht von jedermann bearbeitet werden müssen, heisst nicht wirklich hochgradig benutzungsfreundlich sein müssen, und weil JSON, zumindest meiner persönlichen Erfahrung nach, eine deutlich bessere Unterstützung hat. YAML sehe ich eher selten im Einsatz. Zudem hatte ich schon Einsatzorte, wo ich zumindest damals, weder YAML noch JSON Parser mit den richtigen Feature-Unterstützung zur Verfügung hatte und man ein JSON Parser schneller schreibt als einen YAML Parser. Die strikteren Regeln sind da sehr hilfreich.

XML kommt bei mir eigentlich so gut wie nie mehr zum Einsatz, wenn ich nicht aus externen Gründen dazu gezwungen bin (z.B. bestehende Schnittstellen).

Grüssli

"JSON" ausgeschrieben heißt "JavaScript Object Notation"... es mag jetzt dumm klingen, aber ich benutze es nicht, weil es "JavaScript" im namen hat (und ja, ich weiß, dass javascript != java [ich habe mit beiden keine guten erfahrungen gemacht] ist).

yaml (spricht man das eigentlich "y - a - m - l" oder "jammel" aus?) sieht auf den ersten blick recht gut aus.

xml bietet bestimmt mehr features, aber dafür ist es überladen... keine ahnung, wer das heute noch einsetzt? im grunde könnten doch json oder yaml xml ersetzen?

ich lehne mich jetzt mal weit aus dem fenster und sage: yaml ist in den meisten fällen die beste lösung.

Kellerautomat

Whitespace-sensitive *wuerg*

xml wird afaik nur von java programmierern benutzt

SideWinder

sequel schrieb:

xml wird afaik nur von java programmierern benutzt

Hin und wieder ist es schon etwas peinlich hier im Forum zu sein

Kleiner Edit:
http://programmers.stackexchange.com/questions/61198/if-xml-is-so-bad-why-do-so-many-people-use-it
(aber da gibt's sicher bessere Artikel, nur freut's mich jetzt nicht lange googlen)

MfG SideWinder

Dravere

HTML... ne scherz ^^ schrieb:

"JSON" ausgeschrieben heißt "JavaScript Object Notation"... es mag jetzt dumm klingen, aber ich benutze es nicht, weil es "JavaScript" im namen hat (und ja, ich weiß, dass javascript != java [ich habe mit beiden keine guten erfahrungen gemacht] ist).

Dann bist du dumm
JSON ist grundsätzlich gültiges Javascript. Aber was solls? Wieso darf man das nicht auch für etwas anderes verwenden? Zudem ist es wirklich eine sehr gute Syntax. Man braucht auch gar keinen Javascript Parser dafür. Ich kenne niemanden, der für JSON einen Javascript Parser verwendet. Nicht mal in Javascript verwendest du eval für das Lesen von JSON Daten, da dies ein Sicherheitsrisiko darstellen würde. Es gibt somit extra JSON Parser in Javascript selbst.

JSON und Javascript sind somit schlussendlich in ihrer Anwendung komplett unterschiedliche Dinge.

HTML... ne scherz ^^ schrieb:

yaml (spricht man das eigentlich "y - a - m - l" oder "jammel" aus?)

Man spricht es "jammel" aus. Siehe englische Wikipedia:
http://en.wikipedia.org/wiki/YAML

Ist ja ursprünglich auch die Abkürzung für "Yet Another Markup Language". Inzwischen heisst es "YAML Ain't Markup Language".

HTML... ne scherz ^^ schrieb:

xml bietet bestimmt mehr features, aber dafür ist es überladen... keine ahnung, wer das heute noch einsetzt? im grunde könnten doch json oder yaml xml ersetzen?

Mir ist nicht bekannt, was man in XML machen könnte, was z.B. in JSON nicht geht. XML ist vielleicht höchstens etwas mehr standardisiert mit Zusatzstandards. Heisst XPath, XSL, XSLT, XML-RPC, etc. Es gibt aber durchaus auch JPath, JSONPath, JsonT, JSON-RPC, JSON-Schema, etc. Zum Teil gibt es aber auch mehrere davon und das Zeug ist noch nicht so vollständig standardisiert. Gibt halt noch ein paar Konkurrenzformate und es benötigt wohl noch etwas Zeit, bis sich hier klare Standards etablieren.

Für binäre Format gibt es übrigens noch BSON.

Grüssli

volkard

SideWinder schrieb:

sequel schrieb:

xml wird afaik nur von java programmierern benutzt

Hin und wieder ist es schon etwas peinlich hier im Forum zu sein

Naja, man muss zugeben, dass XML während des Hypes verdammt oft benutzt wurde, auch wo es völlig unpassend gewesen wäre. Zum Beispiel als Speicherformat der eigenen Anwendung (insbesondere des eigenen Spiels), die sicher nur auf x86 bleibt, und das überhaupt nie von Fremden gelesen werden soll und darf. Das gipfelte in XML-Formaten, die nur ein Element haben, das eine verschlüsselte Zip-Datei als DATA hat. Helau. Chef hat XML gefordert; wir haben es erfüllt.

SideWinder schrieb:

Kleiner Edit:
http://programmers.stackexchange.com/questions/61198/if-xml-is-so-bad-why-do-so-many-people-use-it
(aber da gibt's sicher bessere Artikel, nur freut's mich jetzt nicht lange googlen)

Eben. "Xml is great for what it was designed to be -- a platform neutral, human readable data transfer protocol with some capabilities to enforce data validation at low levels."
Passt.

Human-Writable Config-Dateien würde ich zum Beispiel anders machen. Hängt aber vavon ab, wie oft der Human writen soll. Ganz wenig -> XML zum, Beispiel. Ist der Human der Chef, kriegt er einen Klicki-Bunti-Dialog und das Format ist völlig egal. Als Open-Source-Webserver wäre XML für Config-Dateien das sofortige und abschließende Argument, den Server zu löschen und einen anderen zu probieren.
Je nachdem halt.

Dravere

Also ich empfinde XML nicht mal als lesbar. Ein JSON oder YAML File kannst du deutlich einfacher lesen. Vor allem unterstützt XML eigentlich nicht mal ein Pretty Print. Weil die Whitespaces, welche du für das Pretty Print verwendest, als Daten des Dokumentes interpretiert werden. Zum Glück geht glaub ich niemand so streng nach dem Standard. Aber es kann zum Teil zu Problemen beim Austausch von XML Dokumenten kommen:

<node>
  <node>
    Dies ist ein Text,
    der über mehrere Zeilen geht.
  </node>
</node>

<node>
  <node>
Dies ist ein Text,
der über mehrere Zeilen geht.
  </node>
</node>

<node>
  <node>Dies ist ein Text,
der über mehrere Zeilen geht.
  </node>
</node>

<node>
  <node>Dies ist ein Text,
der über mehrere Zeilen geht.</node>
</node>

Korrekt nach Standard:

<node><node>Dies ist ein Text,
der über mehrere Zeilen geht.</node></node>

Juche!

Grüssli

hustbaer

@Dravere
Korrekt nach Standard sind die alle, nur hat der DOM-Tree der laut Standard daraus entstehen muss eben bei allen nen anderen Inhalt.

max mustermann schrieb:

wie würde dann sowas in lua oder python aussehen? erschliest sich mir nicht ganz

In einfachen Fällen auch nicht großartig anders. Beispiel (Lua):

terminal = "xterm"
editor = os.getenv("EDITOR") or "vi"

Man kann problemlos einfachere Key-Value-Paare machen, aber hat ebenso die Möglichkeit mehr einzubauen, wenn man möchte.

sequel schrieb:

xml wird afaik nur von java programmierern benutzt

Genau. Wie war das doch gleich? Java ist eine DSL zur Konvertierung von (ganz viel) XML in lange Stacktraces? Irgendwie so jedenfalls.

SideWinder

Diesen Whitespace-Kram kriegt man übrigens gebacken indem man ein ordentliches Schema schreibt, etwas was man auf jeden Fall getan haben soll.

MfG SideWinder

Dravere

hustbaer schrieb:

@Dravere
Korrekt nach Standard sind die alle, nur hat der DOM-Tree der laut Standard daraus entstehen muss eben bei allen nen anderen Inhalt.

Ja, hast recht, war etwas unsauber formuliert. Mich stört darin aber eben, dass diese Whitespaces zu den Daten des Dokumentes gehören. Und wenn du nun ein Dokument erstellen willst, welches wirklich nur aus den Daten besteht, dann kannst du diese Whitespaces nicht verwenden, wodurch nur das letzte Beispiel gültig ist. Dieses Problem hast du dagegen mit JSON oder YAML nicht.

SideWinder schrieb:

Diesen Whitespace-Kram kriegt man übrigens gebacken indem man ein ordentliches Schema schreibt, etwas was man auf jeden Fall getan haben soll.

Wäre wünschenswert. Das Problem was du hier aber hast: Es werden Fehler gemacht. Dadurch hast du einfach zusätzliche Fehlerquellen. Auch hast du zusätzliche Komplexität. Mit JSON oder YAML ist das einfach von Haus aus schon korrekt. Whitespaces für Pretty-Printing werden ignoriert.

Ich persönlich sehe ehrlich gesagt keinen Grund mehr XML einzusetzen, ausser wegen irgendwelchen Kompatibilitätsgeschichten. Mir sind bis heute von niemandem Vorteile von XML (als Technologie selbst, also nicht wegen Unterstützung und solchem Kram) gegenüber JSON oder YAML genannt worden.

Grüssli

Christoph

JSON hat übrigens den Nachteil, dass es keine Kommentare gibt. Damit wird das ganze sehr unbequem für den User, der die Konfigurations-Datei vielleicht direkt bearbeiten möchte.

ipsec

XML hat den Vorteil, dass es gleich eine Validierung eingebaut hat (mittels DTDs oder Schemas). Ich würde aber auch eher nicht meinen, dass das ein essentielles Feature für Anwendungskonfigurationen ist. Aber es ist manchmal vielleicht trotzdem nett, einen Validierer nicht selbst schreiben zu müssen.

Weitere Vorteile sind Möglichkeiten zur Transformation mit XSLT oder Abfrage mit XPath. Wozu selbst schreiben, wenn es das schon gibt? Aber auch hier wird man das wohl eher in anderen Bereichen gebrauchen können.

was meint ihr eigentlich alle mit "Schema"?

Dravere

Christoph schrieb:

JSON hat übrigens den Nachteil, dass es keine Kommentare gibt. Damit wird das ganze sehr unbequem für den User, der die Konfigurations-Datei vielleicht direkt bearbeiten möchte.

Kommt auf die Art von Konfigurationsdatei an. Gewisse sind ja auch selbstbeschreibend. Aber ja, YAML ist eben deutlich benutzungsfreundlicher.

ipsec schrieb:

XML hat den Vorteil, dass es gleich eine Validierung eingebaut hat (mittels DTDs oder Schemas). Ich würde aber auch eher nicht meinen, dass das ein essentielles Feature für Anwendungskonfigurationen ist. Aber es ist manchmal vielleicht trotzdem nett, einen Validierer nicht selbst schreiben zu müssen.

Weitere Vorteile sind Möglichkeiten zur Transformation mit XSLT oder Abfrage mit XPath. Wozu selbst schreiben, wenn es das schon gibt? Aber auch hier wird man das wohl eher in anderen Bereichen gebrauchen können.

Das hast du alles ganz sicher auch mit JSON. Ein Pendant für XSLT und Schema gibt es auch in YAML. Ob es für YAML auch ein Pendant zu XPath gibt, weiss ich nicht. Aber sollte es eigentlich auch geben...

wtf is schema? schrieb:

was meint ihr eigentlich alle mit "Schema"?

Eine Beschreibung vom Aufbau des Dokumentes. Also Dinge wie:
"Es hat ein Knoten mit dem Namen xyz, welcher Kindknoten von zzz enthalten kann, die wiederrum ganze Zahlen enthalten, usw."
Und das natürlich definiert über eine formale Sprache. Bei XML wäre dies eben DTD oder das neuere XSD.

Grüssli

hustbaer

@Dravere
Für mich persönlich hat XML vor allem den Vorteil, dass es das Format ist auf das sich sozusagen "die Community geeinigt hat". Das hat mit dem was XML kann oder nicht kann, wie praktisch es in der Handhabung ist etc. nicht viel zu tun.
Für meinen Geschmack ist der Standard viel zu komplex und viel zu wenig Einsteigerfreundlich. Ich verwende trotzdem XML in meinen Projekten. Einfach weil es am breitesten unterstützt wird, und am meisten Leute damit klarkommen.

JSON wäre hier der wesentlich einfachere Standard gewesen. Die Grammatik + sämtliche Regeln die man braucht um einen vollständigen JSON Parser zu schreiben haben auf einer A4 Seite platz. JSON wäre hier gegenüber XML ganz klar und um Längen im Vorteil. Auch ist die Verbreitung von JSON ziemlich hoch, der Tool-Support gut etc. Wäre also meine 2. Wahl nach XML. Bei Projekten wo ich alleine dran arbeite und wo Integration mit anderen Projekten/Tools kein grosses Thema ist könnte ich mir sogar vorstellen es selbst zu verwenden.

Was YAML angeht... ich weiss nicht. JSON ist wirklich einfach. Wenn man 1x ein JSON Dokument gesehen hat das sämtliche JSON Features verwendet, weiss man wie man JSON schreiben muss. Bei YAML ist das nicht gegeben. YAML kann man zwar auf Anhieb lesen, und es ist dabei sogar noch übersichtlicher als JSON, aber wenn es darum geht ein konformes YAML Dokument schreiben zu wollen muss man erst wieder die Doku wälzen.
Die Verwendung von Spaces zur Einrückung finde ich dabei auch nicht hilfreich. Ist bloss ein Punkt wo die alte Tabs vs. Spaces Geschichte wieder Verwirrung stiften kann.
Und spätestens bei der Sache mit den Datentypen hört YAML auf einfach zu sein.

hustbaer

Dravere schrieb:

hustbaer schrieb:

@Dravere
Korrekt nach Standard sind die alle, nur hat der DOM-Tree der laut Standard daraus entstehen muss eben bei allen nen anderen Inhalt.

Ja, hast recht, war etwas unsauber formuliert. Mich stört darin aber eben, dass diese Whitespaces zu den Daten des Dokumentes gehören. Und wenn du nun ein Dokument erstellen willst, welches wirklich nur aus den Daten besteht, dann kannst du diese Whitespaces nicht verwenden, wodurch nur das letzte Beispiel gültig ist. Dieses Problem hast du dagegen mit JSON oder YAML nicht.

Was XML macht hat aber auch Vorteile.
z.B. kann man dadurch ein XML Dokument mit einem Programm bearbeiten ohne die Formatierung zu ändern. Einrückungen, Kommentare etc. finden alle ihren Platz im DOM-Tree, und das Programm kann genau entscheiden was beibehalten und was verworfen/neu gemacht werden soll.

(BTW: es nervt mich immer wieder wenn Tools das nicht machen. Wenn man mit Visual Studio Code Analysis Rule Files bearbeitet wird da z.B. alles vernichtet was an "nicht-Nutzdaten" drinnen steht. U.a. auch die Kommentare die ich dazuschreiben wollte warum eine bestimmte Rule deaktiviert ist.)

Bei JSON bzw. YAML geht das nicht. Zumindest nicht wenn du das Dokument in ein Objekt parsen willst, die Änderungen dann am Objekt vornehmen und daraus wieder ein JSON/YAML Dokument erstellen.

ps: Mir sind die Nachteile des XML-Wegs natürlich auch klar. Wenn man ein reines Datenobjekt will, muss man erst das Objekt laden und dann die ganzen Metadaten rauswerfen. Oder eben ein Schema verwenden. Dass das DOM dadurch komplizierter wird ist auch klar.

SideWinder

Mir sind bis heute von niemandem Vorteile von XML...

Alleine schon die Festsetzung des darunterliegenden Zeichensatzes müsste doch für Cross-System-Kommunikation interessant sein. Afaik hast du das in JSON/YAML nicht.

Aber ja, einige haben die Komplexität von XML schon zurecht angekreidet. Ich muss mich derzeit auf einer ziemlichen low-level Ebene mit XML beschäftigen und habe da schon einige "uff"-Effekte erlebt. JSON /könnte/ es hier besser machen, das ist aber noch lange nicht gesagt.

Für ein simples Config-File oder neumoderne APIs bei denen sowieso nur noch UTF-8 zum Einsatz kommt reicht JSON allemal.

MfG SideWinder

Dravere

hustbaer schrieb:

Für mich persönlich hat XML vor allem den Vorteil, dass es das Format ist auf das sich sozusagen "die Community geeinigt hat".

Ich habe das Gefühl, dass sich dies aber langsam ändert. Habe aber dazu keine Fakten, das ist eine rein subjektive Sicht.

hustbaer schrieb:

Was YAML angeht... ich weiss nicht. JSON ist wirklich einfach. Wenn man 1x ein JSON Dokument gesehen hat das sämtliche JSON Features verwendet, weiss man wie man JSON schreiben muss. Bei YAML ist das nicht gegeben. YAML kann man zwar auf Anhieb lesen, und es ist dabei sogar noch übersichtlicher als JSON, aber wenn es darum geht ein konformes YAML Dokument schreiben zu wollen muss man erst wieder die Doku wälzen.

Bin ich mit dir vollständig einverstanden. Einzig eines möchte ich hier anmerken. Jemand der eine Konfiguration ändern möchte, wird kaum ein YAML File neu erstellen müssen, sondern Dinge in einem bestehenden File ändern gehen. Und Änderungen zu machen gehen sehr einfach und sollte eigentlich problemlos klar sein. Bei YAML ist meiner Meinung nach wirklich nur das neue Erstellen ein Problem, also wo man gerne mal wieder die Doku zu rate zieht.

YAML ist somit etwas komplexer zum parsen und für denjenigen, welcher die Konfigurationsdatei erstellt, ebenfalls etwas mühsamer. Aber für denjenigen, welcher die Konfigurationsdatei nur ändert, ist YAML von Vorteil im Gegensatz zu JSON.

SideWinder schrieb:

Alleine schon die Festsetzung des darunterliegenden Zeichensatzes müsste doch für Cross-System-Kommunikation interessant sein.

Meinst du das encoding Attribute im XML Header, welches im Zeichensatz des im encoding Attribute angegebenen Zeichensatzes enkodiert ist?

SideWinder schrieb:

Afaik hast du das in JSON/YAML nicht.

RFC 4627 - Kapitel 3 schrieb:

JSON text SHALL be encoded in Unicode. The default encoding is UTF-8.

Since the first two characters of a JSON text will always be ASCII characters [RFC0020], it is possible to determine whether an octet stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking at the pattern of nulls in the first four octets.
00 00 00 xx  UTF-32BE
00 xx 00 xx  UTF-16BE
xx 00 00 00  UTF-32LE
xx 00 xx 00  UTF-16LE
xx xx xx xx  UTF-8

Falls du eine andere Enkodierung verwenden willst, kannst du gerne auch so ein Hinweis auf die Enkodierung enkodiert in der verwendeten Enkodierung machen

Oder du machst es einfach gleich, wie es im XML Standard bereits erklärt wird:
http://www.w3.org/TR/REC-xml/#sec-guessing

Du schaust dir die ersten Bytes an und ratest.

Grüssli