それは、ファイルをどう解析/デコード/アンマーシャルするかによるね。「一般的な」YAMLパーサーを使うと、noはfalseに変換されるけど、パーサーがデータ構造の型を知ってたり、特定の文字列を置き換えないように指示できたり、フックがあればnoを文字列として扱えるんだ。だから、リンターがパーサーとは違う動作をすることもあるかもね。

Ansibleはドキュメントの金字塔ってわけじゃないよ。ドキュメントは更新されてるし維持されてるけど、基盤となるインターフェースが一貫してないから、それがドキュメントにも影響してる。なぜそうなってるのか不思議だよね、たぶんスタイルガイドなしで異なるアイデアを持った開発者がいるからだろうけど。とはいえ、Ansibleは素晴らしいツールだよ、これらの特異性を許せるならね。

これって本当に過去10年間の問題だったの？確か仕様のバージョン1.2が2009年に修正したはずなんだけど。

ほとんどの問題は、基本的に文字列を引用符で囲むことで解決されるよね。そうそう、私も最初にそう思った。個人的にはYAMLは気にしないけど、文字列を引用する習慣はつけてる。だって、JSONではキーと文字列の両方を引用してるから、YAMLではキー/値ペアごとに約2つのダブルクォートを節約できるってことだし、これが重要な指標ならね。

JSONでは仕様の一部としてやってないけど、ポストプロセッシングとしてやるのを止めるものはないよ。例えば、OpenAPIでは特別な$refキーを使って、ポストプロセッサがそこに参照されている値を入れ替えるんだ。これはjsonnetやcue、hclがやってることと実質的に同じだけど、ポストプロセッサじゃなくてプリプロセッサとしてね。

そうだね、これがデフォルトでyamllintによって強制されてる。 "なんでこんなトリビアルな設定ファイルフォーマットにリンターが必要なんだよ"って叫ぶのはとても公平だし、こういう足元をすくうような問題はYAMLを避ける正当な理由だよ。でも全体的に、YAMLの不安定さは解決しやすい問題だし、YAMLを使う理由があって、リンターを追加するのが可能なコンテキストがあれば、そんなに大したことじゃないと思う。投稿でも示唆されてるけど、実際に確立された普遍的な代替手段はないしね。TOMLは良いデフォルトだけど、かなり単純なものにしか使えない。個人的には「Nixを使えばいい」ってアプローチが好きだけど、どこにでもNixインタープリターを置けるわけじゃないし。Cueはほとんどのユースケースにはオーバースペックだと思う。要するに、結論は「YAMLを使うな」じゃなくて、「YAMLの足元をすくう問題に気をつけて、代替手段を知っておけ」ってことだね。

記事から: > YAMLの問題の多くは、引用されていない文字列のように見えるものが異なる動作をすることから生じている。これは簡単に避けられる: すべての文字列を常に引用すること。

22:22が文字列として引用される必要があるって、俺にはすごく直感に反するな。機能的にはK-Vペアなのに。YAML自体も辞書の構文で:を使ってるし！

この二つの原則、(1) YAMLは引用を必要とすべきで、(2) YAMLの値は再帰/アンカーにあるっていうのが、YAMLの存在理由や人々が使う理由と根本的に逆だと思う。YAMLの特徴は、明示的な開始や - もっと重要なのは - 終了の区切りがない「簡単さ」にあるんだよね。これは、構造のためのホワイトスペースの区切りと、値のためのヒューリスティック解析を組み合わせて実現されてる。後者は根本的に欠陥があるけど、YAMLファンはその欠陥を価値あるトレードオフだと思ってる。もし区切りを必須にするなら、YAMLは存在理由を失うと思う。再帰やアンカーは、ほとんど使われないオプションの追加機能で、一部のパーサーはサポートすらしてない。もしそれがYAMLの主な価値だったら、もっと普及してるはず。ちなみに、俺はYAMLが嫌いで、存在しなければいいのにと思ってるけど、なぜ存在するのかは理解してるし、そのニーズを満たす代替案についてはあまり良い提案がないんだ。TOMLも欠陥があるし。

Jsonnetは結構いいけど、ライブラリのサポートがちょっとイマイチだね。例えば、yaml用の良いライブラリがあって、ラウンドトリップ処理ができるから、プログラム的にyamlを修正してもコメントを保持できるんだ。yamlには確かに欠点もあるし（正直言ってバカみたいなものもあるけど）、いろんな面でうまくいってるから、評価されるべきだと思う。