新フォーマット「TOON」はJSONの代替になるか、海外で議論に
姉妹サイトの新着
海外の掲示板4chan /g/で、JSONの新たな代替フォーマットとして登場した「TOON」をめぐる議論が盛り上がっていた。発端は「JSONはもう古い、TOONが必要だ」という投稿で、スレでは配列のサイズを明示する仕様や、フィールド数が可変のデータをどう扱うかといった実装上の弱点が次々と指摘された。一方で「結局CSVに手間を加えただけ」「XMLに勝てる形式はまだ無い」といった意見や、Clojureのデータ形式EDNを推す声も上がり、新フォーマット一つをめぐって技術者たちの好みの違いがはっきり出たスレとなった。
それなら普通にCSVでいいじゃん
JSONの利点は全要素が同じフィールドを持たなくていいことなんだが
TOONはフィールド数が増減するノードをどう扱うんだ?
JSONのリクエストボディって非対称なフィールドが必要なケース多いぞ
>あーあ、でも省略記法が欲しいんだよなあ!!!!
なら自分でカスタム型を追加しろよ、このクソガキ
{"reviews"
#shorthand-maps
[["id" "customer" "rating" "omment" "verified"]
101 "Alex Rivera" 5 "Excellent!" true
102 "Brij Pandey" 5 "Game changer!" true
103 "Casey Lee" 3 "Average" false]}
NEONで聞いてみたら?
EDNだな
[:p
{:class "some-paragraph"}
"このテキストを見て "
[:strong "Becky"]
"!"]
https://github.com/weavejester/hiccup
TOONは読みづらい
#{:order "doesn't" :matter/LMAO}
これって結局、手間を増やしたCSVだろ。CSVがこの用途に使われないのには理由があるんだよ
手間を増やしたCSVなだけじゃなく、それより劣化してる
ルート要素で配列サイズを指定しなきゃいけないみたいだけど、これ別に要らないだろ
しかも実際の要素数と合わなかったらどうするんだ?少ない方で読むのか?nullで埋めるのか?エラー扱いにするのか?
他サイトの新着
EDNと同じことができるバイナリ形式、知ってるか?Nippyだよ
https://github.com/taoensso/nippy
こういうデータ形式はエージェント時代にはもう古いんだよ。エージェント同士のやり取りなんて.mdファイルで十分
それもEDNなら解決できる。nilを使えばいいし、キーごと無くしたいならプレースホルダーを定義すればいい(ユーザー定義でもカスタム型でもいい)
{"reviews"
#shorthand-maps
[_ ; プレースホルダーだ、EDNはコメントにも対応してるって言ったよな
["id" "customer" "rating" "omment" "verified"]
101 "Alex Rivera" 5 "Excellent!" true
102 "Brij Pandey" 5 _ true
103 "Casey Lee" 3 _ false]}
この話題の背景と論点
TOON(Token-Oriented Object Notation)は、JSONより少ないデータ量で同じ内容を表現できることを売りに登場した新しいシリアライズ形式で、LLMへの入力コストを抑える目的で近年注目されている。スレで意見が割れたのは、データを小さく詰め込むことを重視するか、JSON本来の「要素ごとにフィールドが違っても扱える柔軟性」や「人間がそのまま読み書きできる」利便性を優先するかという点だ。配列のサイズをあらかじめ書く仕様や、値が欠けたフィールドの扱いについては、実装上の弱点として複数のレスで指摘されている。また、Clojureのデータ形式EDNを推す声が目立ったが、EDNは柔軟な型やコメント機能を持つ一方、普及度の面でJSONに遠く及ばない点は本文では触れられていない。データの圧縮自体はWebサーバーのgzipなどでも実現できるため、TOONの優位性が本当に新しいものかどうかは読者の判断に委ねられる。
※本記事は海外掲示板 4chan /g/ (Technology) のスレッド「JSON is obsolete, we need TOON」から抜粋し、編集部で日本語に意訳したものです。訳文の責任は当サイトにあります。









まだコメントはありません。