データ記述言語についての考察

JSON や YAML、TOML などのデータ記述言語について考察する。ツッコミがあれば気軽にどうぞ。

JSON

JSON の利点

• 仕様が簡潔
• 幅広く利用されている

JSON の欠点

• コメントを記述する方法が用意されていない
• 長いテキストを人間が編集しにくい
  • "長い\nテキスト" などとしなくてはいけない
• 数値型が貧弱
  • IEEE 754 の浮動小数点数に対応していない。
• ケツカンマ問題がある
• キーに文字列しか使えない

YAML

YAML の利点

• 強力な機能がたくさんある
• マルチドキュメントを扱える
• コメントが書ける
• 長いテキストも人間が見やすく書ける
• ケツカンマ問題がない
• それなりに広く使われている
• タグ機能を含めれば、順序つき map などを表現できる
• キーに文字列以外も使える

YAML の欠点

• 言語仕様が複雑でデカすぎる
  • 大抵の YAML パーサーにはバグがある
  • レフェレンスパーサーですら、バグがある気がする
• タグ機能を実装できていないものが多い
• 拡張子が .yaml 派と .yml 派で２つに分かれている。
  • RFC では .yaml を使いましょうということになっているし、私もそっちの方が明確だと思うので .yml を使っている人は特に理由がなければ .yaml を使いましょう。

TOML

TOML の利点

• 言語仕様が小さく、はっきりしている
  • JSON よりは大きいが、YAML と比べれば微々たるもの
  • なので、人間にも機械にも優しい
• Date Time を扱える
• コメントが書ける
• ネストが小さいときにとても書きやすい
• 長いテキストも人間が見やすく書ける
• インデントに頼らない
• それなりに広く使われている

TOML の欠点

• 空値がない
  • 厳格ともいえるが、空値が本当に必要な場面で困る
• ネストが深い構造を表そうとした途端に記述量がめちゃくちゃ増える
• YAML のような豊富な型は表せない。あくまで JSON 相当のものだけ
• キーに文字列しか使えない

３大フォーマットが終わったのでそれ以外を見ていく。

JSONC

JSONC の利点

• JSON からの変更が小さい。
  • ほとんど JSON と同じなので言語仕様がかっちりしていて良い
• コメントが書ける

JSONC の欠点

• JSON のコメントが書けない欠点以外は同じ

JSON5

JSON5 の利点

• コメントが書ける
• ケツカンマ問題がない
• IEEE754 の数値は表せる
• 16進数表現が使える
• 文字列を複数行にできる
• キーにダブルクォートを付けなくても良い

JSON5 の欠点

• 複数行にできるとはいえレイアウトが崩れるので長いテキストはまだ編集しにくい
• キーに文字列しか使えない

Hjson

Hjson の利点

• コメントが書ける
• 文字列にダブルクォートを付けなくても良い
• 複数行が書きやすい。
• ケツカンマ問題がない
• 言語仕様がしっかりしている
  • このパーサーの実装が仕様みたいなことにはなっていないので良い

Hjson の欠点

• キーに文字列しか使えない
• 数値型の扱いが JSON と同じで貧弱
• 書き方に慣れてないと意外とバグらせやすい

Braq と Paradict

利点

• コメントが使える
• 辞書・リストに加えて、集合がある
• バイナリデータように Base16 符号が使える
• DateTime, Date, Time が使える
• そもそもテキスト形式とバイナリ形式がある
• YAML のように文書連結ができる

欠点

• プロジェクトが若く、コミュニティが小さい
• IEEE 754 浮動小数点数が使えない

YAML は人間が書く分には良いのだが、言語仕様が複雑すぎて、完璧な YAML パーサーが存在しないせいで運用上怖いところがある。

TOML はネストが浅く、配列のない設定ファイルを書く分には最高である。ネストが深くなったり配列が出てきた途端に繰り返しが多くなって、手で書くには辛くなってくる。

TOML が JSON に劣る例

例えば以下のような JSON は

{
  "very long name": [
    {
      "apple": 10
    },
    {
      "banana": 20
    },
    {
      "lemon": 30
    },
    {
      "orange": 40
    },
    {
      "kiwi": 50
    }
  ]
}

TOML だと

[["very long name"]]
apple = 10

[["very long name"]]
banana = 20

[["very long name"]]
lemon = 30

[["very long name"]]
orange = 40

[["very long name"]]
kiwi = 50

となり、配列の大きさ × very long name を書かなければいけなくなる。

上記の例の YAML 版は以下の通りで書きやすい。

very long name:
  - apple: 10
  - banana: 20
  - lemon: 30
  - orange: 40
  - kiwi: 50

Hjson 版は以下の通りでそこそこ。

{
  "very long name":
  [
    {
      apple: 10
    }
    {
      banana: 20
    }
    {
      lemon: 30
    }
    {
      orange: 40
    }
    {
      kiwi: 50
    }
  ]
}

Braq/Paradict の例。YAML ほどではないが書きやすい。

"very long name": (list)
    (dict)
        apple = 10
    (dict)
        banana = 20
    (dict)
        lemon = 30
    (dict)
        orange = 40
    (dict)
        kiwi = 50

CUE の例。Hjson くらい。

"very long name": [{
	apple: 10
}, {
	banana: 20
}, {
	lemon: 30
}, {
	orange: 40
}, {
	kiwi: 50
}]

CUE

CUEの利点

• コメントができる
• プログラミングできる
  • 概ね Go を引っ張ってきてるように見える
• Schema が使えて validation できる
• モジュール機能がある
• それなりに使われていそう

CUE の欠点

• IEEE 754 浮動小数点数が使えない https://github.com/cue-lang/cue/issues/3168
• YAML ほど書きやすくない

KDL

"cuddle" と読む。つまり日本語だったらカドルと読む。

KDLの利点

• コメントができる
• Type annotation がある
• 文字列の複数行分割ができる
• KDL Query Language がある
• KDL Schema Language がある

KDL の欠点

• JSON より表現力が小さく、JSON compatible にするには JSON-in-KDL 記法を使わなければならない
  • これは痛い
• キーに文字列しか使えない
• IEEE 754 浮動小数点数が使えない

KDLで書くとこうなる。意外と書きやすい。が、JSON で言うところの {} とか [] とか {"-": 1} を扱おうとするとめんどくさい記法をしなければいけなくなる。

- {
  "very long name" {
    - apple=10
    - banana=20
    - lemon=30
    - orange=40
    - kiwi=50
  }
}

Julia の YAML パーサー YAML.jl がバグまみれで使い物にならないので困っている。

とりあえず YAML の処理をしようと思って Python の YAML パーサー PyYAML を使おうとしたが、これもなんかだかへんてこりんである。フォークの ruamel.yaml の方がまだ良さそう。

StrictYAML

StrictYAML is a type-safe YAML parser that parses and validates a restricted subset of the YAML specification.

YAML の部分集合と称しているが本当かどうかは分からない。