Open6
設定ファイルのフォーマット考察

今回の主な考慮対象設定ファイル
- 通常のアプリケーションの設定ファイル
- IaCなどの設定ファイル
例) Ansible, Terraform, Kubernetes - CI/CD 設定ファイル
例) GitHub Actions

考慮事項
- 人間
- 読み書きしやすい
- 直観的であること
- コンピューター
- シリアライズ/デシリアライズで表現が崩れにくい
- 両方
- 仕様が複雑すぎない
- エコシステムの充実度
- スキーマ
スキーマは個人的には必須としたい。
また、必ずしもRead/Writeのフォーマットは同一である必要がないのかもしれない。

各フォーマット考察
JSON
Pros.
- エコシステムが充実している
- JSON Schema
Cons.
- 設定ファイルとして使うには冗長
- 人間が書くには面倒な制約が多い
コメント、ケツカンマ...
YAML
Pros.
- 可読性が高い
- 比較的書きやすい
- エコシステムが充実している
ただし、全ての仕様を実装されていないものも少なくない印象
Cons.
- 仕様が複雑
タグ、マップキー、エイリアス...
JSONで表現できるだけの機能仕様になればよい?
-> 適当な JSON Schema 読ませたらできそう。 - インデントが仕様に盛り込まれている。
- 一般ユーザーの認知度が低め
XML
Pros.
- 一時期はデファクトスタンダードであったこともあり、エコシステムが充実している。
- HTML風のため、比較的読み書きの難易度は低い(複雑な機能を利用していなければ)
Cons.
- 冗長
- 仕様が複雑
名前空間、スキーマ...
INI
Pros.
- 構文が単純
- 人が読みやすい
- 一般ユーザーの認知度が高め
Cons.
- 仕様が各実装依存(共通化されているものが存在しない?)
独自拡張なども良く見る - 表現できるデータに限界がある
TOML
Pros.
- 最初から設定ファイルとして考えられているフォーマット。
- 可読性が高い
Cons.
- 一般ユーザーの認知度が低い
一般ユーザー向けの設定ファイルとして適切でないかもしれない - エコシステムの充実度が低め
Schema
Jsonnet, Cue
調査中...
少なくとも、Kubernetesのような複雑な設定ファイル以外ではオーバースペックと思われる。

まとめ
現状では正解はないと思った。
ITエンジニア向けなら TOML は良い選択のひとつか。
個人的な好みもあるが、同じ表現ならTOMLよりYAMLのほうが読みやすいと感じる
一般向けは何がよいのだろう。。
今後できそうなこと
- 設定ファイルとしてTOMLを積極的に利用することや、エコシステムへの貢献
- JSON+コメントのみの表現可能なYAMLフォーマット仕様
疑問: JSONの範囲外の機能として、YAMLストリームはよく使われている印象だけれど、制限された仕様ではどうあるべきなのだろう。 - 完全新フォーマットの考察

新フォーマット仕様書いてみた。

上記の記事を読んだデータフォーマットとしてのYAMLの感想
- YAMLの文字列は原則
"
で囲う
数値や真偽値やタグやアンカー、エイリアスなど、その他に文字列として扱われない値がありパーサーによっての違いを把握するのは難しい。 - キーに文字列以外使わない。
文字列の特性については同上 - YAMLでJSON以上の表現をしないほうがよさそう
- YAMLでテンプレート処理をしない