Nachdem mal wieder ein Blogpost YAML wegen des Norwegen-Problems verrissen hatte, wollte PJB wissen, was die Spezifikation tatsächlich sagt. Herausgekommen ist eine lange Standards-Archäologie auf Basis des yaml-core-Mailinglistenarchivs, das er mit selbst geschriebenen Python-Skripten von SourceForge scrapte und in Thunderbird lud.

Die Spec-Spur ist eindeutig. Der Entwurf vom Dezember 2001 kannte noch verpflichtende implizite Typisierung, doch bis Oktober 2002 drehten die Autoren die Richtung. YAML 1.0 (Januar 2004) und 1.1 (Januar 2005) beschreiben Tag-Auflösung als anwendungsspezifisch. YAML 1.2 (Juli 2009) definierte erstmals Schemas und empfiehlt ein Core-Schema, das weder yes/no-Booleans noch 60er-Basis-Integer enthält.

Die Mails zeigen, dass die Autoren die Risiken kannten. Von 2003 bis 2007 betonten sie mehrfach, generische Loader sollten alle Skalare als Strings behandeln, das Type-Repository sei eine Portabilitätsempfehlung, und PyYAMLs implizite Typisierung sei ein Relikt aus der Zeit vor Oktober 2002.

Der Schaden entstand nachgelagert. Die Ruby-Bibliothek Syck bekam die Wende nie mit und landete im August 2003 mit dem alten kaputten Verhalten in Rubys Standardbibliothek. In einer Mail vom Juni 2006 gab ein Spec-Autor zu, man wisse um Sycks Fehler, wolle Why aber nicht die Laune verderben. Für Tausende Ruby-Entwickler lud YAML fortan "no" als Boolean, und die Realität schlug die Spezifikation.

PJBs eigene Praxis folgt der Spec-Intention: In Space Station 14 werden YAML-Knoten gegen ein Modell im Code geparst, und Booleans werden nur dort konvertiert, wo sie erwartet werden. Sein Fazit: Die Spec ist nicht ganz unschuldig, denn ohne Implementierungen ist sie bedeutungslos, aber kein Einzelner trägt Schuld. Es war ein Zugunglück in Zeitlupe, gesteuert von ein paar leidenschaftlichen Nerds auf einer Mailingliste. Sein Endurteil über YAML selbst: es ist in Ordnung.