構文のことは忘れて、JSON, S式, XMLのデータモデルを比較する

データをシリアライズするには、独自のフォーマットを定めるよりも、基本的な定義済みの構造を組み合わせてフォーマットを作るほうが望ましい場合が多いです。 そのような仕組みとしてJSON, S式, XMLなどが存在しますが、これらは 「基本的な構造」として何を選ぶか、という観点からそれぞれに個性を持っています。 本記事では、具体的な構文のことは基本的に忘れて、各フォーマットが採用するデータモデルの違いに焦点を絞って比較します。 JSON data JSON = Value data Value = -- Compounds Array [Value] | Object (Map String Value) -- Scalars | Null | Boolean Boolean | String String -- UCS-2 | Number IntegerOrFloat -- no NaNs

[turanukimaru]

xml の利点は schema を別で定義し検証できる事や element が identity を持ち ref で参照できることで object graph の表現力と厳密さが（無駄に）段違いに高い。ただ最近通信の Json 大きすぎてこれもう xml のが安全じゃね？みたいな

[honma200]

これはHaskell？Rustもこんな感じで書けるの？

[n314]

データモデルなら、XMLはXMLそのものじゃなくてDTDがメインじゃないのかな。S式ってライブラリある？別の環境とやり取りするのでなければ、大抵はその言語専用のシリアライズ機構を使うのでは。

[azzr]

Haskellの型定義って、コンストラクタと保持されるデータの型が混じっていて、読むのに慣れが必要だな… ／HTTPのStructured Field Valuesとの比較はどうだろう。

[for-my-internet-demo]

JSON もschemaだのswaggerになると「うまくやってくれるツール」枯れてそうで意外とない

[tmatsuu]

わいわい

[yarumato]

“XML ... 制限つきのS式 + 属性マップ。属性マップは構造をネストさせられない。　YAML ... オブジェクトグラフ。実際には単なるJSONのシンタックスシュガーとして使われることが多い。”

[remonoil]

ふーんJSONでいいじゃん

[kogule]

こういう文脈で S 式を語られるとメチャクチャ違和感があるな。非真正リストももちろん使用されるし，少なくとも Lisp にとっての S 式ではないな。

[xlc]

JSON以外を使おうとする「意識高い系」がいるとプロジェクトが混乱するので困る。

[pascal256]

後で読む