Zur Verteidigung von YAML

 (opensource.posit.co)
1 Punkte von GN⁺ 21 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • YAML 1.2 ist ein einrückungsbasiertes Serialisierungsformat für von Menschen geschriebene verschachtelte Konfigurationsdateien und muss von Kritik an seiner Unzuverlässigkeit unterschieden werden, die aus älteren Erfahrungen mit PyYAML stammt
  • Konfigurationsdateiformate haben sich als Reaktion auf die Grenzen früherer Generationen verändert, etwa die Flachheit von INI, die Ausführlichkeit von XML oder das Fehlen von Kommentaren und mehrzeiligen Strings in JSON
  • TOML ist in flachen Strukturen wie pyproject.toml und Cargo.toml klar, aber bei tiefen verschachtelten Strukturen steigt durch Pfadwiederholungen und Tabellen-Arrays der Aufwand beim Lesen und Bearbeiten
  • Das YAML 1.2 Core Schema behandelt yes, no, on, off, y, n als Strings und entfernt sexagesimale Zahlen sowie Timestamps als Kerntyp, wodurch frühere Probleme mit impliziter Typinferenz reduziert werden
  • py-yaml12 ist ein YAML-1.2-Parser und -Formatter für Python, der durch eine Rust-Implementierung sichere Standardwerte, 100% Konformität mit der yaml-test-suite und eine mit der PyYAML-C-Erweiterung konkurrenzfähige Performance bietet

Problemstellung

  • In den letzten Jahren hat sich die Stimmung bei Konfigurationsdateiformaten in Richtung „YAML ist schlecht, TOML ist gut“ verschoben, doch die Bewertung von YAML muss Geschichte, Änderungen der Spezifikation und den Stand der Werkzeuge im Jahr 2026 zusammen betrachten
  • Die Kritik an YAML war lange berechtigt, und selbst vorsichtige Nutzer erlebten unerwartetes Verhalten, aber die Spezifikation hat sich verändert und das Tooling-Ökosystem holt auf
  • Die heutige Kritik an YAML lässt sich nur verstehen, wenn man auch die Abstammungslinie von Konfigurationsformaten betrachtet; es ist ein wiederkehrender Verlauf, in dem das nächste Format die Übertreibungen des vorherigen korrigieren soll

Eine kurze Geschichte der Konfigurationsdateiformate

  • INI-Dateien kamen Anfang der 1980er mit MS-DOS und frühem Windows auf und waren ein flaches, leicht lesbares, von Menschen editierbares Format mit Schlüssel-Wert-Paaren, Abschnitten in eckigen Klammern und Semikolon-Kommentaren
  • Für damalige Anforderungen wie Gerätetreiberkonfiguration, Schriftpfade oder Anwendungseinstellungen reichte INI aus, hatte aber strukturelle Grenzen: mehr als eine Ebene Verschachtelung war nicht möglich, und mangels formaler Spezifikation implementierten Parser jeweils eigene Dialekte
  • XML wurde Ende der 1990er in der Enterprise-Softwarewelt breit übernommen und bot beliebige Hierarchien, Schemata, Namespaces, Transformationen und eine selbstbeschreibende Struktur, doch reale Konfigurationsdateien wurden sehr ausführlich und damit schwer von Hand wartbar
  • JSON entstand als leichtgewichtigere Reaktion auf XML und ersetzte auf Basis der Einfachheit von JavaScript-Objektliteralen in den späten 2000ern und frühen 2010ern XML in Web-APIs, hat als Konfigurationsformat aber Einschränkungen wie fehlende Kommentare, fehlende mehrzeilige Strings und das Verbot nachgestellter Kommata
  • YAML erschien 2001, TOML 2013, um die von JSON hinterlassene Lücke zu schließen; YAML bietet mit einrückungsbasierter Syntax beliebige Verschachtelung, mehrere Dokumente, Referenzen und benutzerdefinierte Typen, während TOML auf ein „standardisiertes INI“ mit expliziten Typen und formaler Spezifikation zielt
  • Jedes neue Format einer Generation nahm die Übertreibungen des vorigen zum Ausgangspunkt, und viele der heutigen Probleme mit YAML sind weniger ein Resultat des Formatdesigns selbst als eines bestimmten Spezifikationsstands und der daran gebundenen Parser

Die Probleme, die gegen YAML sprachen

  • Die Kritik an YAML ist kein konstruiertes Problem, sondern beruht auf realen Erfahrungen, die Programmierer über viele Jahre gemacht haben
  • Das bekannteste Beispiel ist das Norway-Problem: In YAML 1.1 wurde der unquotierte Skalar NO als boolesches false interpretiert, sodass no in einer Liste von Ländercodes zu einem Falschwert wurde 
    countries:
  - dk
  - fi
  - is
  - no
  - se

    ["dk", "fi", "is", false, "se"]
  • Dieselbe Regel galt auch für yes, on, off, y, n und verschiedene Groß-/Kleinschreibungsvarianten; Port-Mappings wie 22:22 wurden als sexagesimale Ganzzahlen gelesen, Versionsnummern wie 10.23 nicht als Strings, sondern als Fließkommazahlen, und datumsähnliche Werte als Timestamps interpretiert
  • Auch die in Data-Science- und Machine-Learning-Code natürlichen Variablennamen n und y konnten unter den impliziten Bool-Regeln von YAML 1.1 statt als String-Schlüssel als Schlüssel False und True interpretiert werden 
    {"variables": {"x": "features", False: "sample_size", True: "target"}}
  • Die aggressive implizite Typinferenz von YAML 1.1 sollte Lesbarkeit fördern, indem etwa unquotiertes true als Bool gelesen wird, führte in realen Konfigurationsdateien aber zu größerer Unvorhersehbarkeit
  • Konfigurationsdateien werden oft selten bearbeitet und häufig von anderen Personen als dem ursprünglichen Autor geändert; dadurch können stille Fehlinterpretationen monatelang systemweit weitergetragen werden, was unerwartetes Verhalten in diesem Bereich besonders schwer erträglich macht
  • Auch die Komplexität der gesamten YAML-Spezifikation wirkte belastend; die YAML-1.2.2-Spezifikation ist ein umfangreiches Dokument mit 10 Kapiteln und Abschnitten mit vierstufiger Nummerierung
  • Es gibt viele Darstellungsformen für mehrzeilige Strings, und Anker sowie Aliase bilden ein mächtiges Referenzsystem, das für die meisten Konfigurationsaufgaben konzeptionell schwerer wirkt als nötig
  • Sicherheitsprobleme rund um tag-basierte Objektdeserialisierung, insbesondere die Schwachstellen von yaml.load() in Python, wurden zu einem bekannten Angriffsvektor; diese Kritikpunkte waren für YAML 1.1 und das damalige Tooling-Ökosystem gültig

Was TOML gut macht

  • TOML ist in flachen oder nur leicht verschachtelten Konfigurationsstrukturen sauber, gut lesbar und eindeutig
  • Die TOML-Syntax wirkt vertraut für alle, die INI-Dateien kennen, ergänzt aber explizite Typen, eine formale Spezifikation und verschachtelte Tabellen über punktgetrennte Schlüssel
  • pyproject.toml und Cargo.toml sind typische Beispiele, in denen TOML gut passt, weil sie meist gut definierte Abschnitte mit ein oder zwei Ebenen Tiefe und vorhersagbarem Inhalt haben
  • In TOML stehen Strings immer in Anführungszeichen, sodass no nicht mehrdeutig als Bool oder Wort gelesen werden kann; Ganzzahlen, Fließkommazahlen und Datumswerte sind erstklassige Typen, und Kommentare funktionieren wie erwartet
  • Die Übernahme durch PEP 518 im Python-Packaging-Ökosystem und der Einsatz von Cargo in der Rust-Community sprechen dafür, dass TOML für diesen Problemraum eine passende Wahl ist
  • Die TOML-Spezifikation ist kurz genug, dass ein kompetenter Programmierer an einem Wochenende einen kompatiblen Parser schreiben kann, was zu einem großen, gut getesteten und konsistenten Parser-Ökosystem geführt hat
  • TOML kennt keine Entsprechung zur Versionsspaltung zwischen YAML 1.1 und 1.2; TOML 1.0 ist überall einfach TOML 1.0

Wo TOML sperrig wird

  • Wenn eine Konfigurationsdatei Tiefe ausdrücken muss, ist TOML bei Verschachtelung auf punktgetrennte Abschnittsüberschriften ([servers.alpha]) oder Tabellen-Arrays ([[products]]) angewiesen, was mit zunehmender Tiefe schwerer lesbar wird
  • Martin Vejnár von PyTOML lehnte es ab, seine Bibliothek zu einer Abhängigkeit von pip werden zu lassen, und begründete das unter anderem mit der Erfahrung, dass die TOML-Syntax bei komplexeren Konfigurationsschemata unschön und schwer lesbar wird
  • In YAML vermittelt die Einrückung die Hierarchie auf einen Blick, während in TOML in jeder Abschnittsüberschrift der vollständige Pfad wiederholt werden muss 
    services:
  web:
    image: nginx:latest
    environment:
      DB_HOST: postgres
      DB_PORT: 5432
    resources:
      limits:
        memory: 512M
        cpu: "0.5"

    [services.web]
image = "nginx:latest"

[services.web.environment]
DB_HOST = "postgres"
DB_PORT = 5432

[services.web.resources.limits]
memory = "512M"
cpu = "0.5"
  • Leser von TOML müssen aus einer Folge flacher qualifizierter Namen die Baumstruktur im Kopf rekonstruieren; laut Messungen in der StrictYAML-Dokumentation benötigt eine TOML-Datei für dieselben Daten wegen wiederholter Pfadpräfixe etwa 50% mehr Zeichen
  • Python hat schon vor langer Zeit gezeigt, dass Einrückung als Struktur keine Schwäche, sondern eine Stärke ist, weil sie eine Klasse von Bugs beseitigt, bei der visuelle Struktur und grammatische Struktur auseinanderfallen
  • YAML erbt diese Vorteile der Einrückungsstruktur, während TOML keine Einrückung verlangt und die Beziehung zwischen Schlüsseln und enthaltenen Tabellen daher nicht in der physischen Anordnung der Datei, sondern nur in den Abschnittsüberschriften steckt
  • In tief verschachtelten Konfigurationsdateien ist TOML schwer zu scannen und nur mit Mühe sicher zu bearbeiten

Änderungen in YAML 1.2

  • Die YAML-1.2-Spezifikation wurde 2009 veröffentlicht, die klärende Überarbeitung 1.2.2 im Oktober 2021 abgeschlossen
  • Im YAML 1.2 Core Schema werden nur true, false sowie True, False, TRUE, FALSE als Boolesche Werte erkannt; yes, no, on, off, y, n sind normale Strings
  • Die sexagesimalen Zahlenliterale, die das 22:22-Problem verursachten, wurden vollständig entfernt, und Timestamps sind kein Kerntyp mehr; im Core Schema ist ein unquotiertes 2026-05-05 daher kein automatisch erkanntes Datum, sondern ein String
  • JSON ist zu einer strikten und korrekten Teilmenge von YAML 1.2 geworden; jedes gültige JSON-Dokument wird als YAML identisch geparst
  • Die Regeln zur Tag-Interpretation sind strenger und klarer, und auch die Spezifikation selbst ist verständlicher formuliert und wird öffentlich auf GitHub gepflegt
  • Das YAML, das viele Menschen kritisiert haben, ist YAML 1.1; die Spezifikation, die heute die Sprache prägt, ist das sicherere und besser vorhersagbare YAML 1.2
  • Das Problem ist, dass die YAML-Erfahrung der Nutzer nicht durch die Spezifikation, sondern durch Parser vermittelt wird, und für die meisten Python-Nutzer ist dieser Parser PyYAML, das YAML 1.1 implementiert und seine Kernsemantik seit 2006 nicht grundlegend verändert hat

Die Landschaft der Python-YAML-Parser

  • PyYAML ist die de-facto-Standardbibliothek für YAML in Python, kapselt für Performance die C-Bibliothek LibYAML und bietet zusätzlich einen reinen Python-Fallback
  • PyYAML wird jede Woche millionenfach heruntergeladen und ist Abhängigkeit zahlloser Pakete, implementiert aber YAML 1.1 und ist damit die Wurzel vieler Erfahrungen im Python-Ökosystem nach dem Muster „YAML hat Ländercodes als Boolesche Werte geparst“
  • Im PyYAML-Repository gibt es über 200 offene Issues und mehr als 100 offene Pull Requests; das Projekt wird zwar gepflegt, bewegt sich aber langsam, und ein Major-Release-Wechsel zur Semantik von YAML 1.2 ist bislang nicht Realität geworden
  • ruamel.yaml unterstützt YAML 1.2 und bietet Round-Trip-Bearbeitung mit Erhalt von Kommentaren, Flow-Style und Schlüsselreihenfolge; für kommentartreue oder formatbewusste Bearbeitung ist es viel mächtiger als PyYAML
  • ruamel.yaml ist jedoch im Standard-Round-Trip-Modus vorwiegend in reinem Python implementiert und daher deutlich langsamer als der C-basierte Fast Path von PyYAML; hinzu kommt eine Packaging-Historie mit Namespace-Paket-Problemen und Abhängigkeitsketten, die Deployment-Pipelines verwirrten
  • StrictYAML implementiert eine absichtliche Teilmenge von YAML und entfernt sämtliche implizite Typinferenz, Tags, Anker und Flow-Style
  • StrictYAML steht philosophisch eher TOML als vollständigem YAML nahe: ein sicheres, einfaches Format mit YAML-Einrückungssyntax, aber Python-exklusiv, ohne Implementierungen in anderen Sprachen und ohne Anspruch auf Spezifikationskonformität
  • In dieser Landschaft fehlte bislang eine Bibliothek, die schnell ist, vollständige YAML-1.2-Konformität bietet und sich leicht als Ersatz für die Standardoberfläche von PyYAML einsetzen lässt

Vorstellung von py-yaml12

  • py-yaml12 ist ein YAML-1.2-Parser und -Formatter für Python, implementiert in Rust für Geschwindigkeit und Korrektheit
  • py-yaml12 baut auf der Rust-YAML-Bibliothek saphyr auf und bietet eine kleine, fokussierte API mit parse_yaml(), read_yaml() zum Laden sowie format_yaml() und write_yaml() zur Serialisierung

  • Einfachheit

    • Für die meisten Anwendungsfälle ist es so ausgelegt, durchgängig nur mit grundlegenden Python-Builtins wie dict, list, int, float, str und None zu arbeiten
    • Im allgemeinen Pfad gibt es keine speziellen Dokumentklassen oder benutzerdefinierten Knotentypen, und da YAML 1.2 eine Obermenge von JSON ist, wird jedes gültige JSON identisch geparst
    • py-yaml12 erreicht 100% Konformität mit der von der Community gepflegten Sammlung aus Edge-Case- und Konformitätstests yaml-test-suite
    • Das no in einer regions-Liste wird unter dem YAML-1.1-Verhalten von PyYAML stillschweigend zu False, bleibt unter dem YAML-1.2-Verhalten von py-yaml12 aber wie von der Spezifikation verlangt der String "no"
    • Auch die Datei-APIs sind direkt: Schreibt man ein Python-Dictionary auf die Platte und liest es wieder ein, erhält man dasselbe Objekt in einem verlustfreien Round-Trip
    • Für fortgeschrittene YAML-Funktionen wie getaggte Werte gibt es einen Wrapper-Typ Yaml, der bei gewöhnlichen Konfigurationsaufgaben aber optional bleibt

  • Sicherheit

    • Die Standardwerte von py-yaml12 zielen nicht nur auf Bequemlichkeit, sondern auch auf Sicherheit; PyYAML verfolgt hier den gegenteiligen Ansatz, indem Tags wie Befehle behandelt werden, sodass schon das Lesen einer YAML-Datei beliebigen Python-Code ausführen kann
    • Wird eine YAML-Datei, die den Python-object-apply-Tag-Namensraum von PyYAML per Alias anspricht, mit yaml.load(f, Loader=yaml.Loader) eingelesen, wird Python-Code ausgeführt, noch bevor ein normales Dictionary zurückgegeben wird
    • Im Beispiel sieht das Parsing-Ergebnis wie {'debug': False, 'retries': 3} aus, aber zuvor wurde bereits die Umgebungsvariable YAML_PAYLOAD_RAN auf '1' gesetzt, sodass man die Ausführung am Ergebnis allein nicht erkennt
    • py-yaml12 führt Tags, die nicht explizit gewählt wurden, nicht aus, sondern behandelt sie als Daten; nicht verarbeitete Tags werden als Yaml-Wrapper mit Wert und Tag zurückgegeben

  • Geschwindigkeit

    • Die Benchmarks von py-yaml12 vergleichen Lese- und Schreibperformance bei Dateigrößen von Kilobyte bis Megabyte mit dem reinen Python-Standardpfad von PyYAML, mit den LibYAML-basierten CSafeLoader und CSafeDumper sowie mit ruamel.yaml
    • Da die zentrale Parsing- und Formatting-Logik in kompiliertem Rust statt in interpretiertem Python implementiert ist, liefert py-yaml12 bei voller YAML-1.2-Konformität eine Performance, die mit der C-Erweiterung von PyYAML konkurrieren kann
    • Unter den aktuellen Python-Bibliotheken gibt es nur wenige Optionen, die vollständige YAML-1.2-Konformität und Performance auf dem Niveau der PyYAML-C-Erweiterung zugleich bieten

Fazit

  • Die übliche Debatte YAML gegen TOML ist eher eine Debatte gegen eine problematische Form eines Formats, die so nicht mehr existiert; die Kritik war real, aber historisch geprägt
  • Kritik an YAML zielt oft auf YAML 1.1, wie es über PyYAML erlebt wurde, nicht auf die Spezifikation und ein korrekt implementiertes YAML 1.2
  • TOML bleibt eine gute Wahl für flache, überschaubare Konfigurationen, und pyproject.toml passt gut in diese Rolle, aber die Behauptung, YAML sei grundsätzlich unsicher oder unvorhersehbar, hält gegenüber einem kompatiblen YAML-1.2-Parser nicht stand
  • Die wichtige Frage ist nicht abstrakt, welches Format das beste ist, sondern welches Format mit welchen Werkzeugen für eine konkrete Aufgabe gut passt
  • Für komplexe, tief verschachtelte, von Menschen geschriebene Konfigurationsdateien ist YAML 1.2 mit modernem Parser eine starke Antwort, und Formate verbessern sich, indem jede Generation die rauen Kanten der vorherigen ausbessert
  • Unter Python lässt sich mit pip install py-yaml12 eine moderne, spezifikationskonforme YAML-Erfahrung ausprobieren
  • In R bietet r-yaml12 dieselben Vorteile: vollständige YAML-1.2-Konformität, Rust-basierte Performance und sichere Standardwerte wie beim Python-Paket

Verwandte Beiträge

1 Kommentare

 
GN⁺ 21 시간 전
Lobste.rs-Kommentare

  • Die Erklärung, YAML sei entstanden, um Lücken von JSON zu schließen, wirkt seltsam. Soweit ich mich erinnere, kam YAML aus der Perl-Community und ist möglicherweise ähnlich alt oder sogar älter als JSON.
    Bei einem Blick in die tatsächliche Geschichte fand ich einen interessanten Beitrag von Ingy dot Net, einem der YAML-Schöpfer, der den Ursprung auf den Zeitraum zwischen November 1999 und Januar 2001 datiert.
    Und laut diesem Artikel zur Geschichte von JSON tauchte eine primitive JSON-Form erstmals im April 2001 auf, als Nachrichten vom Server zum Client über versteckte iframes und <script>-Tags geschickt wurden; zu einem eigenständigen Format wurde es erst 2002, als Douglas Crockford json.org veröffentlichte.
    Daher war YAML entweder etwas früher dran als JSON oder entwickelte sich, großzügig betrachtet, ungefähr zeitgleich. Es ist nicht korrekt zu sagen, YAML sei als Reaktion auf JSON oder zur Schließung von JSON-Lücken entstanden; YAML war in Wirklichkeit eine Reaktion auf XML. Auch JSON begann aus dem praktischen Grund, Daten direkt in <script>-Tags einzubetten, aber dass es als einfachere Alternative zu XML populär wurde, lässt sich schwer bestreiten.
    Auch der Text selbst zeigt Spuren, als wäre er von einem LLM geschrieben, und das vorgestellte Projekt wirkt ebenfalls irgendwie vibe-coded.

    • Es stimmt, dass YAML ursprünglich eine Reaktion auf XML und eine Alternative dazu war.
    • Als der Text zunächst die Komplexität von YAML kritisiert und später die neue YAML-Spezifikation lobt, hatte ich ebenfalls einen LLM-Verdacht. Er kritisiert die 1.2.2-Spezifikation als auf Ebene 4 tief und lang, sagt später aber, 1.2.2 sei zwar immer noch groß, jedoch viel weniger komplex als 1.1.
      Die einzelnen Sätze klingen plausibel, aber insgesamt bleibt es verwirrend. Auch dass TOML als Sprache mit Spezifikation verteidigt wird, während YAML dafür kritisiert wird, eine komplexe Spezifikation zu haben, wirkt etwas seltsam. Da fragt man sich fast, ob YAML ursprünglich gar keine Spezifikation hatte und TOML schon.
    • Als Ergänzung zu dieser Geschichte: Crockford arbeitete ursprünglich mit Data-E, einer Teilmenge von E, und Data-E stellte nur einfache Daten dar. Die Autoren von E wechselten von dem Versuch, ihre eigene Sprache voranzubringen, dazu, ECMAScript capability-safe zu machen; infolgedessen landeten mehrere Ideen aus E, etwa WeakMap, in ECMAScript.
      JSON ist faktisch eher ECMAScript-artiges Data-E. Auf der archivierten Data-E-Seite sieht man, dass auch sie auf XML reagierten.
    • Wenn man den Text wohlwollend neu interpretiert, könnte man sagen, dass nicht die Entwicklung von YAML, sondern die Verbreitung von YAML eine Reaktion auf die Grenzen von JSON war. Ich persönlich habe YAML auch erst kennengelernt, nachdem JSON bereits weit verbreitet war. Daten, die diese Wahrnehmung stützen, habe ich allerdings nicht.

  • Mit Inline-Tabellen sieht das „schlechte“ TOML-Beispiel so aus:

    [services.web]  
image = "nginx:latest"

environment = {  
  DB_HOST = "postgres",  
  DB_PORT = 5432,  
}

resources.limits = {  
  memory = "512M",  
  cpu = "0.5",  
}

    Das sieht völlig in Ordnung aus, und wenn es ums Zeichen-Zählen geht, wirkt es sogar kürzer als das YAML-Beispiel.

  • Wenn das Ziel des Artikels die Verteidigung von YAML ist, liegt es vielleicht außerhalb des Rahmens, aber TOML 1.1 und die neuen Inline-Tabellen hätten ruhig ebenfalls behandelt werden können. Sie lösen drei Dinge, die ich an JSON nicht mochte: unquotierte Schlüsselnamen, Kommentar-Strings und abschließende Kommata.

    • Man kann vielleicht sagen: „Kritik an YAML greift heute ein Format an, das in den problematischen Formen gar nicht mehr existiert“, aber dann gegen eine alte TOML-Version zu argumentieren, ist auch etwas merkwürdig.
      Python 3.15 unterstützt TOML 1.1, und die Übernahme von TOML 1.1 scheint deutlich besser zu laufen als die von YAML 1.2. Einen TOML-1.0-Parser auf 1.1 zu aktualisieren, dürfte fast trivial sein, aber ein Upgrade von YAML 1.1 auf 1.2 vermutlich nicht. Auf yaml.org finde ich nicht einmal leicht eine Änderungsliste, nur zwei riesige Spezifikationen.
      Dinge wie das „Norway Problem“ sind für mich eher eine kleine Fußnote unter den Gründen, warum ich YAML nicht mag; in Wirklichkeit mag ich es nicht, weil es schwer zu bearbeiten ist, bedeutungstragenden Whitespace verwendet und insgesamt ziemlich komplex ist.

  • Ich denke, YAML, JSON und TOML haben jeweils ihren eigenen Bereich. Die Lücke, die ich lange als unbesetzt empfand, wird von https://kdl.dev/ gefüllt.
    JSON = Datenaustausch mit beliebig tiefer Verschachtelung
    YAML = flaches Containerformat für mehrzeilige Strings
    TOML = fast flache Konfigurationsdateien
    KDL = Ruby-artige DSL als Daten dargestellt

    • Bei neuen Projekten, die Konfiguration brauchen, habe ich mich ebenfalls auf KDL eingependelt. Es beseitigt viele irrelevante Trennzeichen-Syntaxen und Einrückungsregeln.
    • KDL ist wirklich gut. Ich suche ständig nach Gelegenheiten, es zu verwenden. Wie bei XML gibt es Situationen, in denen Markup viel lesbarer wird, wenn Attribute und Kindknoten gemeinsam vorkommen können; gut daran ist, dass es diese Option mit einer leichtgewichtigen Syntax bietet.
    • Als ich das Beispiel sah, dachte ich sofort: „Das sieht aus wie SDLang“ — und das war kein Zufall. Danke für den Hinweis auf KDL.

  • Ich mag YAML wegen Dingen wie dem Norway problem nicht. YAML 1.2 hat das etwas reduziert, aber wegen unquotierter Strings sind Zeichenketten wie "", "Null", "true", "FALSE" immer noch problematisch, und man braucht einen Encoder, der YAML versteht. Die allgemeine Komplexität mag ich auch nicht, aber der eigentliche Grund, warum ich YAML hasse, ist dieser:

    tab characters must not be used in indentation
    Wenn Einrückung Bedeutung trägt, ist es okay, das Mischen von Tabs und Leerzeichen oder deren inkonsistente Verwendung zu verbieten. Der Ansatz von Python 3 wirkt ziemlich gut
    Indentation is rejected as inconsistent if a source file mixes tabs and spaces in a way that makes the meaning dependent on the worth of a tab in spaces; a TabError is raised in that case.
    Aber YAML scheint das einzige Dateiformat zu sein, das Einrückung erlaubt oder verlangt und dabei nicht sowohl Tabs als auch Leerzeichen unterstützt
    Man könnte sagen, dass Make keine Leerzeichen unterstützt, aber .RECIPEPREFIX lässt sich auf einen anderen Wert als Tab setzen. Man kann sogar sagen, dass ein Tab in Make keine Einrückung ist, sondern ein Marker, den Make verwendet

    • Ich finde es gerade nicht, aber ich erinnere mich, ein Zitat gelesen zu haben, in dem Guido van Rossum sagte, dass, wenn er Python von Grund auf neu machen würde, eines der Dinge, die er auf jeden Fall ändern wollte, das Verbot echter Tab-Zeichen für Einrückung wäre
      Auch PEP-8 empfiehlt nachdrücklich, keine Tabs für Einrückung zu verwenden

      Tabs should be used solely to remain consistent with code that is already indented with tabs.
      -- https://peps.python.org/pep-0008/#tabs-or-spaces

    • Zur Referenz sagt auch die NestedText-Spezifikation Folgendes

      Only ASCII spaces are allowed in the indentation. Specifically, tabs and the various Unicode spaces are not allowed.

  • Die Logik „Nicht YAML ist schlecht, sondern YAML 1.1 war schlecht, und die meisten Parser sind nun einmal 1.1-Parser“ greift meiner Meinung nach nicht so gut, wie der Artikel es gern hätte
    YAML, das diszipliniert eingesetzt wird, mag ich, und ich freue mich auch über neue High-Performance-Parser für YAML 1.2, aber wenn die „schlechte“ Version immer noch mehrheitlich verwendet wird, würde ich wohl etwas anderes nehmen. Wenn ich nicht kontrollieren kann, welcher Parser verwendet wird, und deshalb nicht darauf vertrauen kann, dass mein YAML korrekt interpretiert wird, dann ist YAML insgesamt immer noch in einem „schlechten“ Zustand
    Alle sollten auf 1.2 umsteigen, aber bis dahin finde ich es okay, YAML mit Vorsicht zu behandeln

  • Bei dem Satz „Die YAML-vs.-TOML-Debatte ist meist eine Debatte, die ein Format angreift, das in seiner problematischen Form praktisch nicht mehr existiert; die Beschwerden sind real, aber historisch“ möchte ich angesichts von GitHub Actions und Kubernetes laut aufschreien

  • Die Verteidigung ist stark. Trotzdem ist TOML bei sehr einfachen Dokumenten lesbarer, und es ist leichter, Leute dazu zu bringen, TOML statt YAML zu verwenden
    Leider gibt es bei der öffentlichen Entwicklerwahrnehmung von Tools eine lange Trägheit. Die Leute lesen irgendeine Geschichte, entscheiden sich dann, und wechseln zu einem anderen Tool, das sich öffentlich nichts zuschulden kommen ließ

    • Das gilt nicht mehr, sobald die Organisation über 2 Ebenen hinausgeht, einschließlich Arrays. Ab diesem Punkt macht Einrückung die Struktur viel leichter verständlich

  • Ich wünschte, der im Ruby-Interpreter enthaltene YAML-Parser würde YAML 1.2.2 unterstützen
    Aber ich weiß nicht recht, wie man die neuere Version als Standard einführt, ohne das Ökosystem kaputtzumachen

  • Es wäre schön, wenn Konfigurationsdateiformate standardisierte Schemata angeben könnten. Dann könnte ein Editor eine beliebige Konfigurationsdatei ansehen und auf vertippte Schlüssel oder Typinkompatibilitäten hinweisen
    Außerdem sollte dokumentiert werden können, wofür Schlüssel gedacht sind, etwa über Hover-Hinweise, und gültige Schlüssel sollten sich leicht per Autovervollständigung anbieten lassen. Noch besser wäre Unterstützung für einfache Assertions oder Verträge, um ungültige Werte abzufangen. Zum Beispiel sollte ein Schlüssel "color" auf /#[a-fA-F0-9]{6}/ passen
    Im Idealfall sollte man damit auch automatisch Datenstrukturen für Konfigurationsdateien erzeugen können

    • Das beschreibt einfach XML ganz direkt
      Es gibt mehrere Formate für Validierungsspezifikationen wie XSD oder Relax NG, und ich bin mit XML-DTD am vertrautesten, deshalb kann ich zu den anderen nicht viel sagen
    • Bei JSON-Dateien ist es ziemlich üblich, eine $schema-Eigenschaft als Top-Level-Key zu setzen und damit auf eine JSON-Schema-Datei zu verweisen, die das richtige Schema definiert. Im Wesentlichen ist das XSD für JSON. Gute Editoren können darauf basierend meist Autovervollständigung und rote Wellenlinien anbieten
      Das Gute ist, dass TOML und YAML im Wesentlichen nur JSON mit anderer Syntax sind, sodass man in der Regel auch JSON-Schema-Dateien zusammen damit verwenden kann