あけましておめでとうございます。(遅い!)
新年一発目のブログ。昨日途中まで書いたかなり渾身のネタがあるんだけど先に今朝飛び込んできたHeroku関連のニュースを。
なんかHerokuのPlatform APIのスキーマ定義がJSONフォーマットで公開されたらしい。
https://blog.heroku.com/archives/2014/1/8/json_schema_for_heroku_platform_api
実際にどういう定義になっているかは上記ブログ内にあるcurlコマンドを叩けば確認できます。(こんなの認証不要のテキストコンテンツとして普通にhttpで公開しちゃえば良いと思うんだけど)
ていうか「JSON Schema」っていうJSONのスキーマ定義言語があるんですね。
どのくらい流行っているのかは謎ですけど。。。
こういうのって必要だとは思うけど元々XML界隈にいた身としてはなんかXML SchemaとRelaxの不毛な戦争を思いだします。(^^;
JSON Schemaについてなんの予備知識なしで定義インスタンスを見てもなんとなく意味がわかるので、仕様自体はとてもシンプルなんだと思います。少なくともXML Schemaよりは100倍読みやすいです。
ただ、何か違和感があります。。。。
。。。。
ちょっと考えて、スキーマを定義するためのキーと定義されるスキーマのキーがひとつのJSONの中に混在していて見分けがつかないせいだと気がつきました。
definitions以下の定義が、
"definitions": { "created_at": {...}, "description": {...}, ... }
のようになっていて、「type」とか「description」とかの一般的なキー、かつJSON Schema自体も使用しているものが現れた場合に混乱するんですね。
構造化を優先するなら
"definitions": [ { "name" : "created_at", ...}, { "name" : "description", ...}, ... ]
の方が良いんじゃないかなぁという気もしますが、その思考を進めていくとだんだんXML Schemaのようになっていく気もするのであんまり深入りしない方が良いでしょう。(^^;
(JSONがXMLに取って代わった理由の一つに「名前空間が無い」というのがあると思っています。)
このスキーマをベースに各種言語のモデルを自動生成することはできると思いますが、それをやる場合僕ならやっぱりXSLTが使いたいですね。
JSONに対してXSLTを適用する方法って何かあるんでしたっけ???