オーバーフローぎみにスタックされている雑(?)用のなかに、ショー君への業務連絡があるのだけど、考えてみると、これは公開形式でもなんら問題ないのだよね。ってわけで、原則、この日記に書きます＞ショー君
JSONもいいよね
JSONは、簡略で便利なフォーマット。僕はXML好きだけど、用途によってはJSONのほうが良いこともあります。とか言って、実は構文を勘違いしていたのだけどさ（「謝罪と訂正：JSONの構文を間違えていた」参照）、ダハハハハ。
JSON形式の基本表現はstring、number、boolean、nullで、これを元に2種類の構造的データを組み立てます。その2種類とはオブジェクトと配列です。「オブジェクト」「配列」は、JavaScriptに由来する用語法で、一般的には、マップ（あるいはレコード）とリストと言ったほうが適切でしょう。
object ::= '{' '}' | '{' members '}'
members ::= string ':' value | members ',' string ':' valuearray ::= '[' ']' | '[' elements ']'
elements ::= value | elements ',' value
型情報を持ったJSON
XMLとJSONのあいだで変換をするライブラリが既に存在します。しかし、自然な変換法があるわけではなくて、タグ名や内容のJSONエンコーディングには付加的な規約が必要です。例えば：
<greeting mode="friendly">Hello<smil/></greeting>↓ タグ名は@tag、内容は@content
{"@tag" : "greeting",
"mode" : "friendly",
"@content" : ["Hello", {"@tag" : "smile"}]
}
JSONと非常によく似た（事実上同じと言ってよい）データ構造（とその表現構文）に素性＜そせい＞構造（feature structure）があります。素性構造には、型付き（typed）素性構造と呼ばれるスタイルがあって、型名を添えることができます。こんな感じ：
// personが型名
person {
"name" : "米倉花子",
"age" : 23,
"mailAddress" : "hanako-y@hoge.example.jp"
}
XMLのタグ名を型名として型付きJSON（とりあえずそう呼ぶ）でエンコードするなら：
greeting {
"mode" : "friendly",
"@content" : ["Hello", smile{}]
}
どこでもタグ
JSONの波括弧の直前にタグ（型名）を付加できると、表現力が増します。もちろんこれは、JSONのお手軽さや簡略さを損ねる拡張なので、いいか悪いかは議論のあるところですが、とりあえずやってみるという方向で考えるとして；タグ（型名）は、波括弧（つまりオブジェクト）の前だけじゃなくて、角括弧（配列、リスト）、二重引用符（文字列）、数字／符号／小数点（数値）の前に付けてもいいですよね。例えば：
// 平面内の折れ線
polygonalLine [
point{"x":0, "y":0},
point{"x":1, "y":0},
point{"x":1, "y":2},
point{"x":0, "y":3}
]// personの項目も型付けするなら
person {
"name" : "米倉花子",
"age" : age 23,
"mailAddress" : mail"hanako-y@hoge.example.jp",
"otherContacts" : [tel"03-9999-0000"]
}
データ型を示唆するタグは省略可能で、そのときは型を推測する（あるいは事前に分かっている）ことになります。
ついでに（あるいは悪のり）
僕がJSON構文を勘違いしていた箇所は、オブジェクト（名前／値ペアの集合）の名前にも引用符が必要な点です。名前に空白や特殊文字が入ってない（つまり、名前文字列）なら引用符を省略したほうが書きやすく見やすいですよね。それと、空列を特殊な名前とみなして欲しいですね*1。引用符省略と空な名前が許されると、次のような表現が可能です。
greeting {
mode : "friendly",
"" : ["Hello", smile{}]
}
もともと名前がなかったXML内容の名前を考える必要がなくなります。特別な名前を予約してもいいのですが、これが一番簡単な解決策でしょう。（名前空間を考慮しないなら）XMLインスタンスは自然に、拡張したJSON内に埋め込めます。
何が問題なのか／何をしたいのか
これは、「JSONを拡張したい」とか「XMLの代替構文が欲しい」とかが主たる動機ではありません。交換用の構文が食い違うと困ったことになる、ひどい目に遭うのはヨーク承知してますから。
外部形式（交換形式）のハナシではないのです。リテラル表現が貧弱なプログラミング言語で困っているのが動機です。趣味的にリテラルが好きなんですが、現実にもリテラル不足は問題なんですよ、エーッ。
