CAP (Common Alerting Protocol, ITU-T X.1303bis) について

# Common Alerting Protocol

- あらゆる種類の緊急情報（気象警報、災害情報、避難勧告、有事情報など）の形式
- 単純かつ汎用：多数の伝達手段を効率的に
- OASISが策定、ITU-T勧告となった
- ふつうはXMLで表現される

# 「単純かつ汎用」とは

- 緊急情報ならば共通に用いられるデータ構造を簡潔に標準化
- 個別応用分野の情報は key-value 構造に限定
- だから効率的
    - どんな情報でもCAP対応伝達手段には流せる
    - 後年のシステム改修が最小化できる（よく考えて整備・運用すれば）

# タグ構造概要

あくまで一般論としては

* 木構造に従って必須要素だけ説明すれば使えるような気がしてきます。
* 意味のわからない要素、何を書いていいのか困る要素はありません。
* CAP 標準に収まらない情報を収容する余地もあります。

すばらしい整理です。

![CAP document object model](http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os_files/image002.jpg)
（oasis-open.org より）

* XML 文書のルートは `alert` 要素。名前空間は `urn:oasis:names:tc:emergency:cap:1.2`
* `alert` 直下には
    * 必須の単純型子要素 `identifier`, `sender`, `sent`(Sent Date/Time), `status`, `msgType`
    * つまりおおむね配信管理情報、振り分け先を決めるための情報（つまりGTSでいえば[ヘッダ](https://qiita.com/e_toyoda/items/9893b4386084528f2af5)に相当する）
    * 下位構造としては任意個の `info` （普通はひとつ）
* `info` の下には防災情報そのものを置く
    * 必須の単純型子要素 `category`, `event`, `urgency`, `severity`, `certainty`
    * 任意だけどよく使いそうなのは `expires`, `headline`, `description`, `web` など
    * 下位構造とては、任意個の `resource`, 任意個の `area`, 任意個の `parameter` が記載できる
* `resource` は添付ファイル
    * ふつうは添付ファイルを別にウェブにおいて `uri` で指示する
    * データ放送などで URI 参照が無理な場合は添付ファイルそのものを base64 encoding して `derefUri` に入れる
* `area` は位置情報
    * 必須なのはテキスト記述 `areaDesc` だけですが
    * 経緯度ポリゴン `polygon`, 経緯度及び半径による円 `circle`, または何らかの符号表による位置情報コード `geocode` が記載できるし普通は必須に近いものと考えられている
* `parameter` は key-value 形式の拡張情報

個別詳細は http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html みてください。以下目立ったところを。

# alert/identifier は一意

文書にはさらりと a number or string uniquely identifying this message とだけ書いてあるんですけど、これはすばらしいことですね。

まあ、防災情報システムでありがちな、冗長性ある経路でプッシュ型通信するならば必ず重複排除を考えなければならないので当然のことだし、インターネット文明ではたとえば RFC822 の message-id のように古くから重複排除の方法が用意されてきたのを普通に引き継いでいるんですけどね。

異なる文明圏では景色が違うわけで、GTS のような電文送達システムでは[ヘッダ](https://qiita.com/e_toyoda/items/9893b4386084528f2af5)は一意ではありません。同じヘッダ行で内容が異なる電文が複数あり得るし、しかも冗長経路があると同一電文が複数回入電することが避けられないので、電文全体の比較をもって重複排除をしなければなりません。電文長が短く制約されているうちはよかったのですが段々厳しくなってきます。それはあきらめるとしても、一意識別子のないメッセージからCAPを生成しようとしたら、その場でUUID生成などするしかないわけですね。

# alert/sent で Z は禁止

ちょっと面白いのが、alert/sent が xsd:dateTime 型なんですけどタイムゾーン Z が禁止になっているんです。 `2002-05-24T16:49:00-00:00` と書けと。まあ Java なんかで解読する時に条件分岐が多いとしんどいんでしょうかね。

# alert/status 符号表

|符号|意味|
|:--|:--|
|`Alert`|Actionable by all targeted recipients|
|`Exercise`|Actionable only by designated exercise participants; exercise identifier SHOULD appear in `<note>`|
|`System`|For messages that support alert network internal functions|
|`Test`|Technical testing only, all recipients disregard|
|`Draft`|A preliminary template or draft, not actionable in its current form|

# 防災情報内容のレベル化

防災情報内容 alert/info にレベル的な要素が３つあり、単線的ではなく、緊急性、重大性、確度の３次元で仕分けができるようになっています。

まあもっとも、 [WMO Severe Weather Information Centre 2.0](https://severe.worldweather.wmo.int/v2/) では CAP Severity だけを使ってポリゴン色塗りをしているので、特に重要なのは severity なのでしょう。

## alert/info/urgency 符号表

|符号|意味|
|:--|:--|
|`Immediate`|Responsive action SHOULD be taken immediately|
|`Expected`|Responsive action SHOULD be taken soon (within next hour)|
|`Future`|Responsive action SHOULD be taken in the near future|
|`Past`|Responsive action is no longer required|
|`Unknown`|Urgency not known

## alert/info/severity 符号表

|符号|意味|
|:--|:--|
|`Extreme`|Extraordinary threat to life or property
|`Severe`|Significant threat to life or property
|`Moderate`|Possible threat to life or property
|`Minor`|Minimal to no known threat to life or property
|`Unknown`|Severity unknown

## alert/info/certainty 符号表

|符号|意味|
|:--|:--|
|`Observed`|Determined to have occurred or to be ongoing
|`Likely`|Likely (p > ~50%)
|`Possible`|Possible but not likely (p <= ~50%)
|`Unlikely`|Not expected to occur (p ~ 0)
|`Unknown`|Certainty unknown

# alert/info/headline は160文字以下が目安

たぶんSMS配信が念頭にあるのでしょう。日本だったらツイッターですかね。

# リファレンス
- OASIS http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html
- ITU-T https://www.itu.int/rec/T-REC-X.1303bis/en