JSON改：XMLとの比較 - 檜山正幸のキマイラ飼育記 (はてなBlog)

昨日に引き続き、ショー君への業務連絡兼解説兼雑談。

XMLでデータ記述するときの問題点

XMLは本来、文書記述形式として構想されたものです。少なくとも、XMLの先祖であるSGMLは明白に文書記述形式だったし、その最もメジャーな応用はインターネット用文書の記述（つまり、HTML）でした。

しかし、ソフトウェアに関連するデータの記述にもXMLが多用されるようになりました。データ記述となると、どうもXMLには不都合があります。

空白の処理で悩む！
テキストをまとめる／区切る方法がタグ以外にない（簡潔な囲み記号／区切り記号がない）。
タグ／属性の名前を考えるのが苦痛となるときがある。
手書きする場合、タイピング量が多く、間違いやすい。
プログラミング言語とは、構文のテイストが異なり違和感がある。

例えば、JSONで["banana", "orange", "apple"]と表現されるデータをXMLで書くにはどうしますか？

<fruits>
  <fruitItem>banana</fruitItem>
  <fruitItem>orange</fruitItem>
  <fruitItem>apple</fruitItem>
</fruits>

fruitsとかfruitItemとかのタグ名を考え、そのタグで囲ったり区切ったり、あー、面倒だ*1。しかも、fruits要素の最初には、「改行、空白、空白」というテキストデータが入り込みます -- それがイヤなら整形をしないことです。

JSON構文なら、上に列挙した問題点は解決します。もちろん、これをもって、「XMLよりJSONが優れている」と言うのはフェアな評価ではなく、「用途によってはXMLが最良の選択とはなり得ない」だけのことです。

その名前は用途・目的・意義か、それともデータ型か

<person name="米倉花子" age="23" />では、タグ名／属性名がデータ全体／各データ項目の用途・役割・意義を表現しています。これを例えば、<element string="米倉花子" int="23" />と書いてしまうと意味（セマンティクス）が失われてしまいます。一方、文字列型、整数型を制限（restrict）して、name型、age型を定義可能（ときに定義すべき）なので、nameとageは型名だという解釈もあり得ます。

もうひとつ例を出しましょう：<report date="2006-05-24">だと、属性dateの用途・役割・意義はその名前から推測可能です（おそらく「書いた日」でしょう）が、名前"date"は、属性値のデータ型（date型）だという解釈もありえます。しかし、<report created="2006-05-10" lastUpdate="2006-05-24">なら、名前"created"、"lastUpdate"は用途・役割・意義です。

今度はHTMLからの例：<span class="promotionWords">おしゃれな水筒型尿瓶プチシービン</span> -- これだと、タグ名spanには何の意味もありません（フォーマティングの情報ですね）。class属性の値"promotionWords"が内容テキストの用途・目的・意義（尿瓶＜しびん＞のキャッチコピー）を示唆してます。そしてこのケースでは、promotionWordsというデータ型（プログラミング言語における型）があるとは考えにくいでしょう。

とまー、XMLでは、「用途・役割・意義」と「（値の）データ型」の指定方法の原則が決まってなくて、解釈も曖昧になりがちです。このことは、強い型付けを行うプログラミング言語と一緒に使うときに困ります。JSON改では、オブジェクト（レコードorマップ）、配列（リスト）、文字列、数値の直前に型名を添えることができるので、必要なら強い型付け情報（strong typing information）をインスタンスに埋め込むことができます。

// 不要な型情報をあえて入れると
person {
  name : string "米倉花子",
  age : int 23
}

// name型、age型が定義されているなら
person {
  name : name "米倉花子",
  age : age 23
}

// データ型がdateである項目が2つ
report {
  created : date "2006-05-10" ,
  lastUpdate : date "2006-05-24",
  ... 
}

// spanの例？ あれはいかにもHTML的であり
// データ記述の範疇外

僕の想定している利用場面では、型情報を直接的にアノテート（必要に応じて付加）できることは重要です。一方で、型情報を常に強要するのは行き過ぎで、型情報がなければソフトウェアが推測すべきです。

あと、それから

データ記述言語へのもうひとつの要求は、メモリ内にあるオブジェクト構造を、そのまま素直に（しかし高水準で）シリアライズできる能力です。これに関しては、XMLもJSONもイマイチです。が、わずかな工夫と変更で改善できるでしょう。後日の話題とします。

*1:属性値に空白区切りで"banana orange apple"と詰め込む方法もありますけどね。