気象庁XML利活用セミナーでわかったこと

12日に開かれた気象庁ＸＭＬ利活用セミナーにいってきました。なぜか誰もつだっていませんでしたが大変な人気だったと思います。また気象庁が一般公衆に公開情報の二次利用を例示するなど、画期的なことだと思います。

まあそういったことはおいといて、そこで新たにわかったことをメモしておきましょう。他人事のようなというか、ユーザ目線で書いていて異様に思われるかもしれませんが、私は中の人ではありません。 私も気象庁XMLについては迷えるユーザの一人です。

Report直下Body要素のXSD規定がゆるすぎる件

気象庁防災XMLフォーマットの中核となる文書はフォーマット仕様（ワードPDF）、辞書（エクセルPDF）、XSDスキーマだといいます。辞書と XSDスキーマは本質的には同じことを書いたものでヒューマンリーダブルなのが辞書ですが、実際に規格策定者は辞書だけ見ているので、注釈は辞書にしかはいっておらず、辞書をリファレンスにする（仕様はその辞書の読み方を説明する）ことが想定されているというあたりは、まあ ISO 19139 にかぎらず世間でよくある光景です。

それでも、構文規則として機械検証可能なXSDを頼りに読もうという人も多いと思いますが、ルート要素 jmx:Report の3番目の子が

<xs:any maxOccurs="1" minOccurs="1" namespace="##other" processContents="lax"/>

（日本語訳すると「なんでもあり」）と書いてあるので途方にくれるという意見があるんだそうです。

しかし今回、 jmx_mete:Body, jmx_seis:Body, jmx_volc:Body のいずれかだけが用いられる現状運用であると明言されました。これで、追っていくことができるようになるので、すこしは安心感が持てるものとおもいます。XSDをダウンロードして使う人は、choice とか any の名前空間列挙になおしたらいいでしょう。

（追記：辞書やXSDの役割は、気象庁XML全体がとりうる構造の規定と各要素の注釈ですが、それとは別に個々の情報種類ごとにきまった構造があります。それは解説資料が規定するもので、プロファイルといってもいいという説明が腑に落ちました。残念ながら、このプロファイルこそが機械可読版があるとアプリケーション開発に大きく力になるはずなのですが、辞書を簡略化したようなフォーマットで書かれていて場所によってスタイルが違い、また「データ作成者が変化範囲を限定することでアプリケーション開発者が備えるべきことが減って助かる」という発想が希薄だったと思われる節があります。ひとつには XSD は名前空間毎に別ファイルなのでファイル管理が面倒になるということもあり、 Relax NG か Schematron を使えば改善できると思います。試しに台風でつくってみたRNCがこちらになります。）

運用整理表は重要

運用整理表は、どんな種類のデータがあるのか一覧することができるとても便利な表です。これに気付かないと、よくわからないので全部受信してしばらく貯めてから /Report/Control/Title を抽出して「ほんとうにこれで全部かなあ」と言いつつアプリ開発、とかいった闇雲になりますが、脱することができます。

ついでに、たぶんほとんどの方に通じないと思われるので、方言的事項の説明

• 「ナントカ管理表」、は「ナントカ一覧表」のことです。
• 管理部の「管理」はちょっと違っていて、通信処理、とか、キーといって説明しようとしているのは、せんじつめれば処理または配信先の振り分けのことです。/Report/Control 以下はそのための情報です。/Report/Head と /Report/Body が処理されるべきペイロードです。

サンプルデータ整理表の＃数字

サンプルデータ整理表の備考欄に一部 #3④ のような記号が入っていますが、これは項番毎にいくつかのシナリオに沿って継起すべきサンプルが揃えてあって（#3がシナリオ3番）、その4番目という意味だそうです。

Google Alert Hub は5日おきに登録確認をしてくる件

だそうです。あくまで現状の運用と理解するべきだと思います。

Google Alert Hub が POST にも認証情報を入れてくれている件

現行の配信スキームでは、 受信サブスクライバに PubSubHubbub （PuSH）ハブからのアクセスが来た時、その内容が真正の気象庁起源のものであるか知るすべは、AtomフィードURL と hub.verify_token パラメタしかありません。

残念ながら、hub.verify_token パラメタは HTTP GET メソッドによる登録確認時だけで、POST メソッドでフィードが送り込まれる段階では、Atom フィード URL の先頭マッチに拠らざるを得ないということに PuSH プロトコル上はなっていたのでした。

ところが、Google Alert Hub では、POST メソッドのリクエストヘッダ HTTP_X_HUB_SIGNATURE として hub.verify_token をキーにして HTTP リクエストボディから得た HMAC-SHA1 ハッシュ値が与えられるらしいです。PHP での認証コード例が示されたわけですが、いくらなんでもPHPばかりは御助けを…とお考えの諸兄は ruby OpenSSL::HMAC みたいなのは結構あるので適当にぐぐってがんばっていただきたいと思います。