Après un énième billet dénonçant YAML à cause du problème norvégien, PJB a vérifié ce que la spécification dit réellement. Il en tire une longue archéologie des standards, fondée sur l'archive de la liste yaml-core, extraite de SourceForge avec ses propres scripts Python et chargée dans Thunderbird.

La piste de la spec est nette. Le brouillon de décembre 2001 imposait encore un typage implicite obligatoire, mais dès octobre 2002 les auteurs avaient changé de cap. YAML 1.0 (janvier 2004) et 1.1 (janvier 2005) décrivent la résolution des tags comme propre à chaque application. YAML 1.2 (juillet 2009) a enfin défini des schémas et recommande un schéma Core sans booléens yes/no ni entiers en base 60.

Les e-mails montrent que les auteurs connaissaient les risques. De 2003 à 2007, ils ont répété que les chargeurs génériques devaient traiter tous les scalaires comme des chaînes, que le dépôt de types était une recommandation de portabilité, et que le typage implicite de PyYAML était un vestige d'avant octobre 2002.

L'échec s'est produit en aval. La bibliothèque Ruby Syck n'a jamais reçu la consigne et est entrée en août 2003 dans la bibliothèque standard de Ruby avec l'ancien comportement défectueux. Dans un e-mail de juin 2006, un auteur de la spec admettait connaître les erreurs de Syck sans vouloir gâcher la fête de Why. Pour des milliers de développeurs Ruby, YAML chargeait « no » comme un booléen, et la réalité a battu la spec.

La pratique de PJB suit l'intention de la spec : dans Space Station 14, les nœuds YAML sont analysés selon un modèle dans le code, et les booléens ne sont convertis que là où ils sont attendus. Sa conclusion : la spec n'est pas entièrement innocente car sans implémentations elle ne vaut rien, mais personne n'est en faute. C'était un accident de train au ralenti, mené par quelques nerds passionnés sur une liste de diffusion. Son verdict final sur YAML : c'est correct.