測候時

報79.5-62012

報

告気象庁防災情報 XML フォーマットの詳細と策定経緯

杉山善昭 *1・竹田中村

政道 *5・長谷川目

康生 *2・山腰昌樹 *4・平原裕一 *3・清本隆寿 *6・横井真司 *4・
貴子 *7

次‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 54

1

はじめに

2

気象庁 XML 策定・普及体制 ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 54

3

XML について4

XML スキーマ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 57

5

辞書と XML スキーマ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 66

6

気象庁 XML の概要 ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 67

7

全体構造の解説 ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 68

8

個別要素の解説 ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 80

9コード表 ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 99‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 57

10バージョン管理 ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 100

11

その他の議論 ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 122

12

XML 関連ツール ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 125

13

他仕様との関係について ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 131

14

渉外活動 ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 132

15

まとめ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 134

16

謝辞 ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 136

参考文献 ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 137
用語集 ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 138
付録 ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 140*1 予報部業務課*2 予報部予報課*5 仙台管区気象台技術部地震火山課*3 観測部気象衛星課*4 地震火山部地震予知情報課*6 地球環境・海洋部海洋気象課海洋気象情報室－ 53 －*7 総務部総務課広報室

測

候

時

報

79.5-6

はじめに＊

1

2012

化の対応には数年掛かる」，「短期間に対応するの気象庁防災情報 XML フォーマット（以下「気であればコード化する方がよい」，「地震火山関象庁 XML」という．）は，従来の情報ごとに異係の電文はコード化が主流であり気象庁としてなる電文形式に対する後継フォーマットとして，の電文形式に係る方向性を明確にすべき」など，

XML 技術を採用した気象庁としての新しい提供

XML 技術の導入に係る気象庁としての方針が問形式である．

われることとなった．旧形式の気象警報・注意報

平成 22 年度からの市町村を単位とした気象警

XML 電文の提供開始後も，「共通化した XML で報の発表などの計画を控えて，より詳細で高度化ないと困る」，「地震情報も含めた気象庁全体で本された防災情報の提供様式を検討すべき時節の到線は XML だと宣言して欲しい」といった要望が来と捉え，「気象情報部外提供推進委員会」（委員

引き続き寄せられた．

長：総務部参事官．以下「委員会」という．）の情報処理技術を積極的に業務へ取り込んできた

下に，部外における気象情報の更なる有効活用に

気象庁であるが，この時の経験から，新しい技術資する提供形式の検討・決定を目的とした「気象を導入し情報内容を高度化しても，利用者の対応

情報提供形式検討部会」（部会長：総務部企画課に配慮しなければ情報を使ってもらうことができ

企画調整官）を設置し，約 3 年にわたる仕様策定ないということを強く認識することとなった．

作業を行った．策定にあたっては，昨今の技術革また，この頃，既に米国では“CAP”（第 13.1

新の激しい中でも 10 年程度は利用可能なフォー

節参照）という名の XML を用いた警報等の伝達マットとすることを目指し，XML 技術の専門家が開始されていた．組織や事象に捕らわれず，米が集う XML コンソーシアムの協力を仰ぐととも

国政府内のマルチハザードを伝達するための統一に，利用者からの声を検討に反映させるなど，従的な提供形式として，具体的な実装や利活用が進前のフォーマット策定過程にない取り組みを行っんでいた．このような国際動向も気象庁 XML をた．これらの成果が，気象庁 XML の仕様や運用策定する上での大きな背景となった．

指針として結実した．
ここでは，気象庁 XML の策定・普及過程にお2.2

庁内体制始動・仕様策定

ける業務的・技術的観点などの様々な議論を取り気象庁が，情報の内容や提供手段ではなく提供

まとめるとともに，その際に気付いた点や反省点

形式（フォーマット）について，気象から地震・などを記述することにより，今後の気象庁 XML

津波・火山などまでの数多くの防災情報を対象との管理・運営に資することを期待する．

して，一体的に整理するとともに一つの仕様として策定したのは今回が初めてであるといえる．こ2

気象庁 XML 策定・普及体制

2.1

＊＊

こでは，このような初めての取り組みについて，部会における検討経緯などを含め気象庁 XML の

背景

気象庁で XML を採用した最初の情報は，気象策定までの流れを整理する．

警報・注意報であり，平成 16 年 3 月に遡る．これは，検討体制の発足は冒頭のとおり気象情報提供形

XML1.0 が勧告された平成 10 年（1998）から数式検討部会が設置された平成 19 年 3 月 27 日であ

年経ち，様々な業界において XML が具体的業務

る．同部会では，既に多様な分野で応用が盛んに実装されていった時期である．

あることなどを理由に XML に的を絞って具体的

当時，気象警報・注意報・予報の改善・拡充

な技術検討を進めるとともに，気象庁の電文のの一環として平成 15 年度から報道機関等へ XML

XML 化による利便性を探求した．検討を進める

化のメリット等を説明していた．その際，「XMLほどに作業が具体化され，技術的にも深い議論を

*第1章

山腰

** 第 2 章

第 2.1 節～第 2.4 節

山腰， 第 2.5 節～第 2.6 節

杉山－ 54 －

測

候

時

報

79.5-62012

するようになっていった．場所や時間などの形式

利用），TravelXML（旅行業に利用）で，XML 技を議論する中で，形式の共通性を意識するばかり

術による情報の標準化についての実績があり，複に情報の意味するところが異なってしまうのでは

数のテーマ別部会により XML を主軸とした実装

ないかなどといった議論もあった．

寄りの研究・開発・検証を行っている団体であっ同部会での約 1 年の検討を経て，平成 20 年 1
月 7 日の委員会で気象庁 XML の策定に向けたロたことから，気象庁 XML の策定における最適な協力団体であった．

ードマップが決定された．具体的には，提供形式

XML コンソーシアムから得た協力のうち主なを XML としたこと，これを気象庁 XML としてものを紹介する．策定作業全般にわたり，庁内の仕様の作成を行うために庁内に作業グループ（以個々の電文の XML 化を担当する WG メンバーと下「WG」という．）を発足させるとともに後述の間では定常的な勉強会を行うとともに，担当者の XML コンソーシアムの協力を得ること，大きの考えをレビューしていただいた．また，気象庁

な業務変革等とスケジュールを整合させることなXML 公開前の市場製品に対する動作検証は，当どをまとめた部会の中間報告を承認した．この内

庁単独では実現しない XML コンソーシアムなら容を 2 月 1 日に気象庁の決意表明として報道発表

ではの技術協力であった．XML コンソーシアム

した．

では，会員企業に対して協力メンバーを募集し，その後，ロードマップに沿って各方面の利用者に対して方針説明等を行いつつ，仕様書の作成を

各種プラットフォーム上での検証結果を取りまとめ，その結果をホームページ等で公開した．

進めていった．仕様書の具体化においては，利用

このように，システム市場を代表する方々の評

者の理解や準備を促すため，事前にドラフト版を価・検証結果の公表を含め，策定作業の各段階に作成し意見募集を行った（平成 20 年 5 月 16 日及おいて協同して公表することにより，利用者や開び平成 21 年 1 月 27 日委員会決定）．このような発者に対する気象庁 XML への移行に向けた訴求

利用者からの意見等に対応した後，XML 電文のに効果があったと考えている．

提供開始をおよそ 1 年後に控えた平成 21 年 5 月
15 日に気象庁 XML の仕様初版を公開した．

2.4

関連機関等の動き

気象庁の活動と時を同じくして，防災関係の情
2.3

報共有化の動きが加速していた．

XML コンソーシアムの協力

気象庁は情報の内容に対しては専門家である

内閣府の防災担当部門と科学技術政策担当部門

が，提供形式とした XML 技術については業界動がともに進めていた「社会還元加速プロジェクト」

向などの客観的な情報収集が必要と考えた．また，の一つ「きめ細かい災害情報を国民一人ひとりに多くの情報を一元的に従来の提供形式から XML

届けるとともに災害に役立つ情報通信システムの形式へ変更するためには，気象庁内多数の担当者構築」を目標とした各種検討がある．例えば，情の技術力向上を図るとともに，利用者が実装する報の規格化が必要であるとして，当時，文部科学際に必要となる IT 技術・開発者の目線を必要と省における災害関連のメタ情報の XML 化や国土していた．このような観点から，気象庁 XML の

交通省における河川管理情報の XML 化などの取策定には XML の専門家からの協力が重要だと考り組みをレビューし，どのように災害リスク情報

えていたところ，日本における XML の利活用のを共有・促進するかを議論しはじめたところであ促進を目指す非営利団体の XML コンソーシアム

った．ここで時を得て気象庁 XML の検討状況をに，部会事務局である企画課担当者の 1 通の問い説明できたため，具体的な取り組みであり先駆的

合わせメールがたどり着き，これが以降 3 年間にな事例であると多くの防災関係機関からも XML

わたる協力関係の始まりとなった．XML コンソ

化を歓迎された．

ーシアムは，これまでに ContactXML（住所録にまた，デジタル放送への切替えを契機にメディ利用），ContentsBusinessXML（コンテンツ取引にア向けの XML 規格（TVCML[1] 等）が検討され－ 55 －

測

候

時

報

79.5-62012

るとともに，自治体における一般行政情報の共通

2.6

資料の公開

化（第 13.3 節参照）が進められていた．

一連の報道発表や意見募集のみならず，今回のこのように，防災関係機関における XML 技術

気象庁 XML の各種仕様等の情報については専用をキーワードとした情報共有化は必然の流れであのホームページを「気象庁防災情報 XML フォー

ったといえる．

マット 情報提供ページ」（http://xml.kishou.go.jp/）（以下「気象庁 XML の HP」という．）として公2.5

普及・活用促進体制開している．

気象庁 XML の仕様は平成 21 年 5 月 15 日に公

これまで，気象庁で利用している各種フォーマ

開されることとなり，策定から普及へと軸足を移ットに関する情報については技術情報として，気すことになった．このため，公開前日に当たる 5

象業務支援センター経由等で利用者提供を行っ

月 14 日の委員会において，気象情報提供形式検てきたが，今回の気象庁 XML に関しては気象庁

討部会は改組し，気象庁防災情報 XML フォーマXML の HP 上で，一般国民向けにオープンな形

ット普及・活用促進部会として，これまでの活動で公開することとなった．これは XML 技術が汎を引き継ぎつつ新たな活動段階へと踏み出した．

用的であり関連技術がオープンな市場技術である活動の方向性としては，これまで XML のフォー

こと，気象庁 XML の普及には関連情報の広い公マットがいかにあるべきかを検討してきたところ開が必要であることなどから，また XML コンソ

から，具体的なサンプルや解説資料の充実などをーシアムからの強い提言もあって，このような形基盤作業として，各種部外機関に対する気象庁

で公開することとした．

XML の説明，売り込みを図ることが主たる活動

当初，技術資料は以下のものを公開していた．

となった．

・気象庁防災情報 XML フォーマット仕様書

また，活動主体が普及・活用促進へと移るのに・同辞書・スキーマファイル

併せる形で，これまで協力頂いた XML コンソー

・コード管理表・個別コード表

シアムにおいても気象庁 XML をいかに活用する・サンプル電文かという観点で研究テーマの選定が行われた．具

議論を進めていく中で，仕様書だけでは説明が体的には，当時 XML コンソーシアムにおいて活できないデータ部分の運用等の説明や，外部から動していたビジネス・イノベーション研究部会とスタイルシート（XSLT）の提供の要望が深まった．

SOA 部会を中心として気象庁 XML の利活用業務

このことから，平成 22 年 5 月 14 日に以下の資料

モデルの策定とシステム設計，Web サービス実を追加公開した．

証部会と次世代 Web 活用部会，及び関西部会に・気象庁防災情報 XML フォーマット運用指針

より同業務モデルのデモ実装が実施された．これ・サンプルスタイルシート

らは平成 22 年 3 月 17 日，18 日の XML コンソー

その後も引き続き詳細について検討を進めていシアム Week においてその成果が発表された．

ったが，その過程で，気象庁 XML の運用の共通

なお，XML コンソーシアムは平成 22 年 3 月

化としての観点から，一部電文の運用については

31 日をもって，10 年間にわたる活動を終了して他の電文と調整がとれていないことが明確化しいる．また，気象庁防災情報 XML フォーマット

た．このことは，各業務に基づき違う運用を行っ

普及・活用促進部会も，運用開始とともに運用管ている XML 化対象電文を，気象庁 XML として理が主たる業務となることから，平成 23 年 5 月

統一する作業として，必ずしも理想通りにはいか

9 日に気象庁防災情報 XML フォーマット運用管ないことを示した．一方で，この運用の違いは，

理・利活用促進部会に改組して，維持運営を中心

丁寧に説明すれば明らかに異質な運用とまではいに業務を担っている．

えないことから，仕様書や辞書，サンプル電文のみでは利用者に対する情報が不足していると考え，新たに電文ごとの解説資料を作成することと－ 56 －

測

候

時

報

79.5-62012

し，平成 22 年 9 月 15 日に以下の資料を追加公開

ることにより，作成側では XML インスタンス作

した，

成の際のひな形と妥当性検証（バリデーション）

・電文ごとの解説資料

機能を，利用側では XML インスタンスの設計図

基礎資料の提供としては，これらを提示するこを受けることができるようになることである．ことにて現在（平成 24 年 10 月）まで至っている．

のことは，二者間における情報伝達の重要なインターフェース情報となることを意味する．なお，
XML の構造定義に関する議論の一つとしては，＊

3

XML についてXML（Extensible Markup Language） は 文 書 の「ボヘミアンと貴族の階級闘争」[5] を参照のこと．

電 子 化 技 術 SGML（Standard Generalized Markup
Language）のサブセットとして，1998 年 2 月に（2）気象庁 XML における W3C XML Schema の採W3C（World Wide Web Consortium） よ り 勧 告 さ用（仕様 2.1 項）

れた．XML は現在，構造化された文書や直列化

XML スキーマ言語には代表的なものとして（Serialized）されたデータの保存形式として，最DTD[6]，W3C XML Schema [7]，RELAX NG[8]も一般的な方式・言語の一つである．

の 3 種類がある．DTD については名前空間を適XML には次のような特徴がある．

切に扱えない問題があることから除外するが，気・要素のネスティング（入れ子構造）によって，

象庁 XML で採用する XML スキーマ言語として，

ツリー構造による擬似多次元情報の表現が可

W3C XML Schema と RELAX NG のいずれを採用

能するかについては様々な議論があった．結論とし・基本的に自由度の高い表現記法て，RELAX NG は ISO/IEC 19757-2 として国際規・DOM（Document Object Model）や SAX（Simple

格にもなっているが，処理可能なプロセッサーはAPI for XML）といった標準 API のほか，デW3C XML Schema の方が多いことから，気象庁

ータバインディング技術などが充実しているXML ではこちらを採用することとした．

・XML データを直接取り扱うことが可能なデータベースや言語（XQuery）などが発達し（3）XML スキーマと XML 文書構造てきている

XML スキーマ言語は XML 文書構造を定義す

・SOAP など Web サービスの基盤技術として利る言語であり，基本的にはあらゆる XML イン

用されており，疎結合システム間連携に幅広

スタンスの構造を定義できる．しかしながら，く利用されているXML スキーマ言語の構文上，構造定義しづらい

詳細については，たのしい XML[2] ，リファXML インスタンスがある．このような XML イ

レ ン ス と し て atmarkIT の XML 用 語 辞 典 [3] ，ンスタンスは，構造定義が可能であっても XML

w3schools.com[4] などが参考になる．

スキーマ処理系による実装不安定性（汎用ライブ
ラリー等が正しく動作しない）がある場合や，不4XML スキーマ＊＊具合の原因となる場合もありうる上，そもそも構XML スキーマ言語

造定義しづらいことは XML スキーマ言語の理念（1）XML スキーマ言語と相いれない構造となっている場合が多い．このXML スキーマ言語とは，XML 文書構造を定義

ことから，本章において解説している XML スキ

する各種言語である．XML の構造を定義する意

ーマの利用形態が元となって，XML インスタン

義については幅広い議論があるが，一般的には，スの構造が決定されている部分が多々ある．このXML の構造や値の基底型等の構造情報を提供す

ため，気象庁 XML の構造を本質的に理解するた

4.1

*第3章

杉山

** 第 4 章

杉山， 第 4.2 節

杉山・竹田， 第 4.3 節（4）項－ 57 －

竹田

測

候

時

報

めには本章について理解しておく必要がある．

79.5-62012

全ての要素と型は使い回しが利かないため，

なお，気象庁 XML の策定の過程においては，XML インスタンスに沿った形で構造を定義する

XML スキーマにより XML インスタンスの構造こととなり，ネスティング構造（入れ子・親子構を決めるのみならず，XML スキーマを作成して造）の階層についても XML インスタンスに近いみた結果，XML スキーマ上で表現の難しいもの

ものとなる．（第 1 図リスト b）

については XML インスタンスの構造の方を修正

なお，ロシア人形とはマトリョーシカのこと．

している場合が多い．このような策定過程を経たところだが，一般論としても，XML インスタン（2）Salami Slice 型（サラミスライス）ス構造の決定に当たっては，XML インスタンス

全ての要素の定義がグローバルで，型の定義がの検討，XSLT 等を用いた XML インスタンスのローカルとなっているものである．

利用，XML インスタンスの構造を定義する XML

全ての要素の定義がルート要素の schema 要素

スキーマの作成の 3 つの作業を繰り返し実施し直下に定義されているため，スキーマ定義上のどて，それぞれの問題点を整理・修正していくこと

こからでも定義された要素が利用できる．どこかが必要になるかと思われる．

らでも要素の利用が可能であるということは，インスタンス全体で要素名の一意性が求められる

4.2

デザインパターンこととなり，このことから，XML インスタンス

W3C XML Schema による XML スキーマのデザから見た場合，同じ要素名は必ず同じ構造とな

インパターンとして，大きく分けて 4 種類の記る．また，要素定義がグローバルとなることか法がある．これらの記法は，W3C XML Schemaら，XML インスタンスの階層構造にかかわらず，に お け る 要 素（element） と 型（complexType，XML スキーマでは一定以上のネスティングが発

simpleType）の定義がグローバルとなっているか，生しない．（第 1 図リスト c）

それともローカルとなっているかによって XML
スキーマ内での参照の方法が変わることから，そ（3）Venetian Blind 型（ベネチアン・ブライ
ンド）の典型的な記法として整理されたものである．
グローバルな定義とは，要素又は型の宣言がSalami Slice 型とは反対に，全ての要素の定義

XML スキーマのルート要素である schema 要素直がローカルで，型の定義がグローバルとなってい下にて定義されるものである．このように定義さるものである．

れた要素又は型は，XML スキーマのいずれの場

全ての型の定義がルート要素の schema 要素直所でも要素参照及び型参照にて利用すること（呼下に定義されているため，スキーマ定義上のどこび出すこと）が可能である．一方，ローカルな定からも定義された型が利用できる．型名では一意

義とはグローバルな定義の子孫として定義される性が求められるが，XML インスタンスから見る

要素又は型である．このように定義された要素又と型名は見えず，また，ある一つの型に対して要は型は，定義した要素及び型の子孫でのみ要素参素名称を複数割り当てることが可能であることか

照及び型参照にて利用が可能となる．このようなら，要素名による構造上の制限は発生しない．こ参照の可能範囲を有効に利用し，記法として利活のことは，XML 設計上の自由度が制限されない

用しやすくしたものが以下のデザインパターンでことを意味する．また，型定義がグローバルとなある．なお，型とはオブジェクト指向でいうとこることから，XML インスタンスの階層構造にかろのクラス，要素はインスタンスの定義に近い．

かわらず，XML スキーマでは一定以上のネステ
ィングが発生しない．（第 1 図リスト d）（1）Russian Doll 型（ロシア人形）
全ての要素と型の定義がローカルとなっているものである．

（4）Garden of Eden（エデンの園）
全ての要素と型の定義がグローバルとなってい－ 58 －

測

候

時

報

79.5-62012���a�����XML<?xml version="1.0" encoding="UTF-8" ?><Report xmlns="http://xml.kishou.go.jp/testxml/"><Title>�����</Title><DateTime>2009-01-09T02:25:34Z</DateTime><Head><Headline>������</Headline></Head></Report>���b�Russian Doll�
<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:test="http://xml.kishou.go.jp/testxml/"
elementFormDefault="qualified"targetNamespace="http://xml.kishou.go.jp/testxml/"><xs:element name="Report"><xs:complexType><xs:sequence><xs:element maxOccurs="1" minOccurs="1" name="Title"
type="xs:string"/><xs:element maxOccurs="1" minOccurs="1"
name="DateTime" type="xs:dateTime"/><xs:element maxOccurs="1" minOccurs="1" name="Head"><xs:complexType><xs:sequence><xs:element maxOccurs="1" minOccurs="1"
name="Headline" type="xs:string"/></xs:sequence></xs:complexType></xs:element></xs:sequence></xs:complexType></xs:element></xs:schema>���c�Salami Slice�<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:test="http://xml.kishou.go.jp/testxml/"
elementFormDefault="qualified"targetNamespace="http://xml.kishou.go.jp/testxml/"><xs:element name="Report"><xs:complexType><xs:sequence><xs:element maxOccurs="1" minOccurs="1"
ref="test:Title"/><xs:element maxOccurs="1" minOccurs="1"
ref="test:DateTime"/><xs:element maxOccurs="1" minOccurs="1"
ref="test:Head"/></xs:sequence></xs:complexType></xs:element><xs:element name="Title" type="xs:string"/><xs:element name="DateTime" type="xs:dateTime"/><xs:element name="Head"><xs:complexType><xs:sequence><xs:element maxOccurs="1" minOccurs="1"
ref="test:Headline"/></xs:sequence></xs:complexType></xs:element><xs:element name="Headline" type="xs:string"/></xs:schema>

第 1 図 スキーマの各デザインパターンの見本
リスト b ～ e はリスト a：サンプル XML に対する XML スキーマ．リスト b：Russian Doll 型ではサンプル XMLと同じ入れ子構造となる．リスト c：Salami Slice 型では要素定義をグローバル化しているため，xs:schema 直下には要素定義（下線）しか現れない．リスト d：Venetian Blind 型では型定義をグローバル化しているため，xs:schema
直下には型定義（下線）しか現れないが，ルート要素になりうるものは要素定義が出現する．リスト e：Garden of
Eden 型では要素定義も型定義もグローバル化しているため，いずれも xs:schema 直下にしか現れない．

－ 59 －

測

候

時

報

79.5-62012

リストd：Venetian Blind型<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:test="http://xml.kishou.go.jp/testxml/"
elementFormDefault="qualified"targetNamespace="http://xml.kishou.go.jp/testxml/"><xs:element name="Report" type="test:type.report"/><xs:complexType name="type.report"><xs:sequence><xs:element maxOccurs="1" minOccurs="1" name="Title"
type="xs:string"/><xs:element maxOccurs="1" minOccurs="1" name="DateTime"
type="xs:dateTime"/><xs:element maxOccurs="1" minOccurs="1" name="Head"
type="test:type.head"/></xs:sequence></xs:complexType><xs:complexType name="type.head"><xs:sequence><xs:element maxOccurs="1" minOccurs="1“
name="Headline“
type="xs:string"/></xs:sequence></xs:complexType></xs:schema>

リストe：Garden of Eden型<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:test="http://xml.kishou.go.jp/testxml/"
elementFormDefault="qualified"targetNamespace="http://xml.kishou.go.jp/testxml/"><xs:complexType name="type.report"><xs:sequence><xs:element maxOccurs="1" minOccurs="1"
ref="test:Title"/><xs:element maxOccurs="1" minOccurs="1"
ref="test:DateTime"/><xs:element maxOccurs="1" minOccurs="1"
ref="test:Head"/></xs:sequence></xs:complexType><xs:complexType name="type.head"><xs:sequence><xs:element maxOccurs="1" minOccurs="1"
ref="test:Headline"/></xs:sequence></xs:complexType><xs:element name="Report" type="test:type.report"/><xs:element name="Title" type="xs:string"/><xs:element name="DateTime" type="xs:dateTime"/><xs:element name="Head“
type="test:type.head"/><xs:element name="Headline“
type="xs:string"/></xs:schema>

第1図るものである．

続き

ローバルとなることから，XML インスタンスの

Salami Slice 型と同様，スキーマ定義上のどこ

階層構造にかかわらず，一定以上のネスティングからも定義された要素が利用でき，XML インスが発生しない．一般的に機械可読性が高く，人間

タンスから見た場合，同じ要素名は必ず同じ構造

可読性は著しく低い．（第 1 図リスト e）となる．また，スキーマ定義上のどこからも定義

IDE ソフトウェアの NetBeans 等のプラグイン

第1図 スキーマの各デザインパターンの見本（続き）された型が利用できる．要素定義及び型参照がグ
では，XML の構造設計の際に，これらのデザイ－ 60 －

測

候

時

報

79.5-62012

ンパターンを選んで XML スキーマの自動出力が番 を 決 め た 上 で sequence グ ル ー プ 要 素 と可能となっている．

minOccurs 属性値の 0 の指定により，実質的

気象庁ではこれらのデザインパターンの内，ベに利用可能であること．逆に順番を完全に不ネチアン・ブラインド型を採用した．記述や読解定とすることによる不具合の発生の可能性がの平易さ，型の再利用などのメリットもあるが，高いこと．

ベネチアン・ブラインド型の記法は辞書（第 5.1

・all グループ要素で可能なことは，sequence グ節参照）の記載や XML スキーマの自動生成におループ要素と minOccurs 属性値の 1 の指定にいて，非常に親和性が高かったことも大きな理由

より，実質的に利用可能であること．

である．

・choice グループ要素についてはライブラリー

なお，気象庁 XML の全ての辞書において要素等の実装上，適切に扱われるかどうかに不安の定義をローカルに定義しているわけではなく，があるという XML コンソーシアムからの助

全ての電文に共通して利用する基本要素や部品を言があったこと．

定義している共通辞書（基本要素）では，要素名も全ての電文で共通のものを用いるべきとの考（2）単純型派生データ型の利用制限

え方により，グローバルの要素定義もしている．

単 純 型 派 生 デ ー タ 型 は list 型，restriction 型，

また，将来の拡張のため，共通辞書（追加要素）

union 型の 3 つの型がある．list 型については，空でも追加される要素を予め W3C XML Schema の

白文字区切りによる要素値の列挙が可能であるこ

any 要素で定義した部分から参照されるよう，要とから，XML 要素の繰り返し構造を省くことに

素定義をグローバルに行っている．

より XML 全体のデータ容量を減らすことが可能であり，当初は list 型の多用を検討していた．しW3C XML Schema 構文における注意点

かしながら，要素値の取扱いについては要素の繰

W3C XML Schema による各種構造等を示す構り返しによって実施すべきであり，また，その値

文について，気象庁 XML 策定の際の注意点を以の取扱いにおいては XML 外の処理系（ライブラ

下にまとめる．

リーや実装）を利用しなければいけないことから，

4.3

list 型は極力避けるべきという XML コンソーシ（1）コンテンツモデルの組立て

アムからの助言を参考として，list 型は基本的にコンテンツモデルとは，個々の要素等の出現が利用していない．list 型を限定的に利用している

どのようになるかといったモデルを示す．

のは以下の場合である．

こ の コ ン テ ン ツ モ デ ル に お い て，W3C XML

・2 つ以上出現する事例は少ない場合．例外的

Schema で は，sequence グ ル ー プ 要 素，choice グに利用する場合でも，列挙されている個々のループ要素，all グループ要素の 3 つのグループ

要素値を分解せずに一連の文字要素として取要素が指定できる．これらのうち，記載順序順にり扱っても問題とならない場合．

出現することが求められる sequence グループ要・非常に多数の要素値を示さなければならない素については利用するが，いずれかの出現を選択場合で，要素値の示す情報の業務的な重要度

する choice グループ要素，及び全ての要素を必が余り高くない場合．

須とする all グループ要素については以下の理由

・他の規格により list 型が指定されている場合．

により利用しないこととした．

restriction 型，union 型における利用制限は行っ

・要素が出現する順序は事前に知り得た方が不具合の発生を抑止できること．

ていない．
なお，union 型においては，XML コンソーシア

・気象業務全般及びシステム的に XML の各要

ムによる動作検証の際，SOAP 通信ソフトウェア

素の出現順を定めることが可能であること．

である Axis と Axis2 において自動生成されたコ・choice グ ル ー プ 要 素 で 可 能 な こ と は， 順

ードがコンパイルできない，及び実行時バイン－ 61 －

測

候

時

報

79.5-62012

ドができない不具合が発生した．これは Axis とら れ た 名 前 空 間 の リ ス ト， 任 意 の 名 前 空 間 のAxis2 側の既知の問題ではあるが，修正される見

要 素 を 示 す「##any」， こ の ス キ ー マ が 属 し て込みが当分ないことから，利用者側でスキーマを

い る 名 前 空 間 以 外 の 要 素 を 示 す「##other」， こ

改変して動作するようにするなど，これらは利用のスキーマが属している名前空間の要素を示者処理側で対応する必要がある．なお，このことす「##targetNamespace」，名前空間で修飾されは XML コンソーシアムにおいて動作検証を実施て い な い 要 素 を 示 す「##local」 が 指 定 で き る．

した際の結果として判明したことから，同報告にnamespace 属性と次項の Unique Particle Attribution

おいてもこの内容を解説している．

制約は関連が大きいので，辞書の作成者は合わせて理解する必要がある．

（3）オブジェクト指向的構造要素

processContents 属性については，要求された名オブジェクト指向的構造要素には，abstract 属

前空間のスキーマを取得し，それらの名前空間か性や ﬁnal 属性がある．抽象型であることを示す

らの要素を検証する必要がある「strict」，要求さabstract 属性や派生型の禁止を示す ﬁnal 属性を利れた名前空間のスキーマを取得し，それらの名前

用することにより，オブジェクト指向におけるデ空間からの要素を検証するが，スキーマを取得でータ構造をそのまま XML 化するために用いるこきない場合でもエラーとしない「lax」，XML プとが可能である．しかしながら，バージョン管理

ロセッサーは，指定した名前空間からの要素を検の運用と XML 構造のオブジェクト指向と併せた証しない「skip」が指定できる．processContents

データモデルを実験的に構築してみたが，運用及属性は，公開するときにはバージョン管理も考慮

び実装系における処理が想定通り動作しなかった

して「lax」を指定しているが，辞書やサンプル

ことから，これらオブジェクト指向的構造要素の電文の作成段階においては厳密に妥当性検証をす

利用はしないこととした．

るために「strict」を指定し厳密に行うことが望ましい．

（4）any 要素
一般的に XML の要素の追加や変更を行う場合，

any 要素の具体的利用の検討については，第 10章にとりあげる．

新しいスキーマを事前に配布，周知することとなる．一方，例えば平成 23 年の東日本大震災後の（5）Unique Particle Attribution 制約

電力不足等の対応のために「高温注意情報」を急Unique Particle Attribution（UPA）制約は，イン遽開始したように，気象庁の防災情報は，緊急的スタンス上のある要素について，XML スキーマ

対応として，新しい電文の配信や要素を追加した上の定義が複数の方法にて解釈できる状態になっ

電文の配信を実現する必要がある．これら対応てはいけないという制約を示す．具体的には，第の実現のため，気象庁 XML では未定項目として

2 図のような XML スキーマがある場合に，同図W3C XML schema における any 要素を利用するこの XML インスタンスについては XML スキーマととしている．

上の要素定義を行っている 2 行のいずれにでも解

any 要 素 は，W3C XML schema に お い て ワ イ

釈できるが，UPA とはこのように二重解釈が絶ルドカードとして任意の要素の出現を定義する

対にされない状態を示す．W3C XML Schema はものである．any 要素は属性として，最大出現回

UPA 制約を遵守するように要請している．

数を示す maxOccurs 属性，最小出現回数を示す

UPA 制約は XML 設計上，配慮が必要なポイ

minOccurs 属性のほかに，出現する要素の定義がン ト で あ る．W3C XML schema に は any 要 素 となされている名前空間を指定する namespace 属

いう，任意の要素の出現（ワイルドカード）を性，妥当性検証の方法を指定する processContents

定義する構文があるが，この any 要素の周辺で属性をとることができる．

は UPA 制約違反が発生しやすいため注意が必要

namespace 属 性 に つ い て は， ス ペ ー ス で 区 切である．具体的には第 3 図リスト a に示すとお－ 62 －

測

候

時

報

79.5-62012

り，any 要素により出現する要素の属する名前空反を回避する手段としては次のようなものがあ間 指 定（namespace 属 性 ） を「 任 意 」（“##any”）

る．

や「 こ の ス キ ー マ が 属 し て い る 名 前 空 間 」

・namespace 属

性を“##any”や（“##targetNamespace”）とする場合に多発する（名“##targetNamespace”にしない（第 3 図リス

前空間指定省略時は「任意」扱い）．UPA 制約違ト b）．

リストa：XMLスキーマ<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:test="http://xml.kishou.go.jp/testxml/"
elementFormDefault="qualified"targetNamespace="http://xml.kishou.go.jp/testxml/"><xs:element name=“a"><xs:complexType><xs:sequence><xs:element maxOccurs="1" minOccurs=“0" name=“b"
type="xs:string"/><xs:element maxOccurs="1" minOccurs=“0" name=“b"
type="xs:string"/></xs:sequence></xs:complexType></xs:element></xs:schema>

リストb：サンプルXML<?xml version="1.0" encoding="UTF-8"?><a><b>xyz</b></a>

第 2 図 Unique Particle Attribution（UPA）制約違反となる例
リスト a の XML スキーマでは要素 <b> が最小出現数 0 以上として 2 回定義しているため（下線部），リスト b のUnique Particle Attribution（UPA） 制約違反となる例
サンプル XML の <b>第2図
要素がいずれの定義に一致するかが不明瞭となっている．

リストaのXMLスキーマでは要素<b>が最小出現数0以上として2回定義しているため（下線部） ，リストbのサ
ンプルXMLの<b>要素がいずれの定義に一致するかが不明瞭となっている．

リストa：UPA制約違反となるXMLスキーマ<xs:element name="Name" minOccurs="1" maxOccurs="1" type="xs:string" /><xs:element name="Code" minOccurs="0" maxOccurs="1" type="xs:string" /><xs:any minOccurs="0" maxOccurs="unbounded" processContents="lax" />リストb：名前空間の指定で回避<xs:element name="Name" minOccurs="1" maxOccurs="1" type="xs:string" /><xs:element name="Code" minOccurs="0" maxOccurs="1" type="xs:string" /><xs:any minOccurs="0" namespace="##other" maxOccurs="unbounded" processContents="lax" />リストc：出現回数の指定で回避<xs:element name="Code" minOccurs="0" maxOccurs="1" type="xs:string" /><xs:element name="Name" minOccurs="1" maxOccurs="1" type="xs:string" /><xs:any minOccurs="0" maxOccurs="unbounded" processContents="lax" />リストd：入れ子構造を1段階掘り下げて回避（XMLインスタンスも変更）<xs:element name="Name" minOccurs="1" maxOccurs="1" type="xs:string" /><xs:element name="Code" minOccurs="0" maxOccurs="1" type="xs:string" /><xs:element name="OptionElement" minOccurs="0" maxOccurs="1"type="jmx_wb:type.OptionElement" /><xs:complexType name="type.OptionElement"><xs:sequence><xs:any minOccurs="0" maxOccurs="unbounded" processContents="lax" /></xs:sequence></xs:complexType>第 3 図 UPA 制約違反の回避方法
リスト a が違反となる XML スキーマ．リスト b ～ d が回避する代表的な手法．XML スキーマの minOccurs 属性
第3図 UPA制約違反の回避方法
値は当該要素の最小出現回数，maxOccurs
属性値は最大出現回数を定義する．その他の構文については W3C XML
リストaが違反となるXMLスキーマ．リストb〜dが回避する代表的な手法．XMLスキーマのminOccurs属性値
Schemaの仕様書を参照．
は当該要素の最小出現回数，maxOccurs属性値は最大出現回数を定義する．その他の構文については

W3C XML Schemaの仕様書を参照）．
－ 63 －

測

候

時

報

79.5-62012

・any 要素とする前後に出現する要素（兄弟要り要素追加における UPA 制約違反を回避したと素）の出現回数を固定する（第 3 図リスト c）．

しても，メジャーバージョンアップによる XML・any 要素の出現場所を一段階深掘りして単独

スキーマの整理の段階で再び UPA 制約に抵触すの子要素となるようにする（第 3 図リスト d）．

る可能性が高い．これを回避するためには整理の気 象 庁 XML で は， 名 前 空 間 を 指 定 す る

段階で他の名前空間により拡張したものを，定義

か「このスキーマが属している名前空間以外」

元の名前空間に備え付け直す等の大規模な対応を（“##other”）のいずれかになるようにしている．

する必要がある（第 4 図）．

なお，UPA 制約は根深く，“##other”指定によa 要素辞書に要注意
UPA XMLインスタンス<jmx̲hoge:TemperaturePart><jmx̲eb:Temperature>14.5</jmx̲eb:Temperature></jmx̲hoge:TemperaturePart>×

W3C XML Schema【jmx̲hoge】<xsd:sequence><xsd:element ref="jmx̲eb:Temperature" minOccurs="0" maxOccurs="1"/><xsd:any minOccurs="0" maxOccurs="unbounded" namespace= ##other /></xsd:sequence>

Temperatureの名前空間が"jmx̲hoge"と異なり，"jmx̲eb"となっていることから，ベースとなっている
XMLの名前空間と異なる．このため，anyのnamespace="##other"に抵触することに加えて，一つ前の要素がminOccurs="0"(省略可)となっていることから，スキーマから見るとjmx̲eb:Temperatureをどちらにあたるのかが曖昧となる．
<jmx̲hoge:TemperaturePart><jmx̲eb:Temperature>14.5</jmx̲eb:Temperature></jmx̲hoge:TemperaturePart>【jmx̲hoge】<xsd:sequence><xsd:element ref="jmx̲eb:Temperature" minOccurs="1" maxOccurs="1"/><xsd:any minOccurs="0" maxOccurs="unbounded" namespace= ##other /></xsd:sequence>○jmx̲eb:Temperatureがanyのnamespace="##other"に抵触するが，一つ前の要素がminOccurs="1"となっていることから，スキーマから見てanyではないことが判別できる．
b 拡張後マイナーバージョンアップに要注意
UPA XMLインスタンス<jmx̲hoge:TemperaturePart><jmx̲eb:Temperature>14.5</jmx̲eb:Temperature><jmx̲eb̲add01:Humidity>30</jmx̲eb̲add01:Humidity></jmx̲hoge:TemperaturePart>×

W3C XML Schema【jmx̲hoge】(Ver1.00)<xsd:sequence><xsd:element ref="jmx̲eb:Temperature" minOccurs="1" maxOccurs="1"/><xsd:any minOccurs="0" maxOccurs="unbounded" namespace= ##other /></xsd:sequence>【jmx̲hoge】(Ver1.01)<xsd:sequence><xsd:element ref="jmx̲eb:Temperature" minOccurs="1" maxOccurs="1"/><xsd:element ref="jmx̲eb̲add01:Humidity" minOccurs="0" maxOccurs="1"/><xsd:any minOccurs="0" maxOccurs="unbounded" namespace= ##other /></xsd:sequence>

Ver1.00からマイナー拡張したVer1.01(名前空間は変更せず)のスキーマを作成したが，拡張部分である
jmx̲eb̲add01:Humidityの出現回数がminOccurs="0"(省略可)となっていることから，スキーマから見ると
jmx̲eb̲add01:Humidityがanyにあたるのかが曖昧となる．

<jmx̲hoge:TemperaturePart><jmx̲eb:Temperature>14.5</jmx̲eb:Temperature><jmx̲eb̲add01:Humidity>30</jmx̲eb̲add01:Humidity></jmx̲hoge:TemperaturePart>○【jmx̲hoge】(Ver1.00)<xsd:sequence><xsd:element ref="jmx̲eb:Temperature" minOccurs="1" maxOccurs="1"/><xsd:any minOccurs="0" maxOccurs="unbounded" namespace= ##other /></xsd:sequence>【jmx̲hoge】(Ver1.01)<xsd:sequence><xsd:element ref="jmx̲eb:Temperature" minOccurs="1" maxOccurs="1"/><xsd:element ref="jmx̲eb̲add01:Humidity" minOccurs="1" maxOccurs="1"/><xsd:any minOccurs="0" maxOccurs="unbounded" namespace= ##other /></xsd:sequence>jmx̲eb̲add01:Humidityがanyのnamespace="##other"に抵触するが，一つ前の要素がminOccurs="1"となっていることから，スキーマから見てanyではないことが判別できる．

○<jmx̲hoge:TemperaturePart><jmx̲eb:Temperature>14.5</jmx̲eb:Temperature><jmx̲eb̲add01:Humidity>30</jmx̲eb̲add01:Humidity></jmx̲hoge:TemperaturePart>【jmx̲hoge】(Ver1.00)<xsd:sequence><xsd:element ref="jmx̲eb:Temperature" minOccurs="1" maxOccurs="1"/><xsd:any minOccurs="0" maxOccurs="unbounded" namespace= ##other /></xsd:sequence>

そもそもマイナーバージョンアップのスキーマを作成しない．

第4図XML フォーマットの拡張時等に発生しやすい UPA 制約違反とその回避例－ 64 －

測

候

時

報

c 要素の拡張は親タグごと
UPA XMLインスタンス○

79.5-62012

W3C XML Schema【jmx̲hoge】(Ver1.00)<xsd:sequence><xsd:element name="TemperaturePart" minOccurs="0" maxOccurs="unbounded"
type="jmx̲hoge:type.TemperaturePart"/><xsd:element name="AnyE lementP art" minOccurs="0" maxOccurs="unbounded"
type="j mx̲hoge:type.AnyE lementP art"/></xsd:sequence><xsd:complexType name="type.TemperaturePart"><jmx̲hoge:TemperaturePart><jmx̲eb:Temperature>14.5</jmx̲eb:Temperature></jmx̲hoge:TemperaturePart><jmx̲hoge:AnyElementPart><jmx̲eb:WindSpeed>14.5</jmx̲eb:WindSpeed></jmx̲hoge:AnyElementPart><jmx̲hoge:AnyElementPart><jmx̲eb̲add01:Humidity>14.5</jmx̲eb̲add01:Humidity></jmx̲hoge:AnyElementPart><xsd:sequence><xsd:element ref="jmx̲eb:Temperature" minOccurs="1" maxOccurs="unbounded"/></xsd:sequence></xsd:complexType><xsd:complexType name="type.AnyE lementP art"><xsd:sequence><xsd:any minOccurs="1" maxOccurs="unbounded" namespace= ##other /></xsd:sequence></xsd:complexType>

anyを入れる箱としての親要素を用意し，それの出現個数を任意とすると，安定した拡張性が望める．
基本バージョン(ver1.00)の要素辞書(jmx̲eb)を追加することも出来るし，追加バージョン(ver1.01)の要素
辞書(jmx̲eb̲add01)を追加することも出来る．
【jmx̲hoge】(Ver1.10)<xsd:sequence><xsd:element name="TemperaturePart" minOccurs="0" maxOccurs="unbounded"
type="jmx̲hoge:type.TemperaturePart"/><xsd:element name="AnyE lementP art" minOccurs="0" maxOccurs="unbounded"
type="j mx̲hoge:type.AnyE lementP art"/></xsd:sequence><xsd:complexType name="type.TemperaturePart">※<jmx̲hoge:TemperaturePart><jmx̲eb:Temperature>14.5</jmx̲eb:Temperature></jmx̲hoge:TemperaturePart><jmx̲hoge:AnyElementPart><jmx̲eb:WindSpeed>14.5</jmx̲eb:WindSpeed></jmx̲hoge:AnyElementPart><jmx̲hoge:AnyElementPart><jmx̲eb̲add01:Humidity>14.5</jmx̲eb̲add01:Humidity></jmx̲hoge:AnyElementPart><xsd:sequence><xsd:element ref="jmx̲eb:Temperature" minOccurs="1" maxOccurs="unbounded"/></xsd:sequence></xsd:complexType><xsd:complexType name="type.AnyE lementP art"><xsd:sequence><xsd:choice><xsd:element ref="j mx̲eb:W indL ocation" minOccurs="1" maxOccurs="1"/><xsd:element ref="j mx̲eb̲add01:H umidity" minOccurs="1" maxOccurs="1"/><xsd:any minOccurs="1" maxOccurs="unbounded" namespace= ##other /></xsd:choice></xsd:sequence></xsd:complexType>jmx̲hoge:AnyElementPart以下に現れる要素として，後から追加されたjmx̲eb:WindSpeedとjmx̲eb̲add01:Humidityを明確にするためのマイナーバージョンアップ(名前空間は同じ)は行える．
ただし，厳密に定義するためにはxsd:choiceを辞書として記述できないといけないことから，現状では対応できていない．

【jmx̲hoge2】(Ver2.00)<xsd:sequence><xsd:element name="TemperaturePart" minOccurs="0" maxOccurs="unbounded"
type="jmx̲hoge2:type.TemperaturePart"/>< xsd : e le me n t n a me = " W in d S p e e d P a r t " min Oc c u r s= " 0 " ma xOc c u r s= " u n b ou n d e d "t y p e = " j mx̲ h oge 2 : t y p e . W in d S p e e d P a r t " / >< xsd : e le me n t n a me = " H u mid it y P a r t " min Oc c u r s= " 0 " ma xOc c u r s= " u n b ou n d e d "t y p e = " j mx̲ h oge 2 : t y p e . H u mid it y P a r t " / ><xsd:element name="AnyE lementP art" minOccurs="0" maxOccurs="unbounded"
type="j mx̲hoge2:type.AnyE lementP art"/></xsd:sequence><xsd:complexType name="type.TemperaturePart">○<xsd:sequence><xsd:element ref="jmx̲eb:Temperature" minOccurs="1" maxOccurs="unbounded"/></xsd:sequence><jmx̲hoge2:TemperaturePart><jmx̲eb:Temperature>14.5</jmx̲eb:Temperature></jmx̲hoge2:TemperaturePart><jmx̲hoge2:WindSpeedPart><jmx̲eb:WindSpeed>14.5</jmx̲eb:WindSpeed></jmx̲hoge2:WindSpeedPart><jmx̲hoge2:HumidityPart><jmx̲eb̲add01:Humidity>14.5</jmx̲eb̲add01:Humidity></jmx̲hoge2:HumidityPart></xsd:complexType><xsd:complexType name="type.W indSpeedP art"><xsd:sequence><xsd:element ref="jmx̲eb:WindSpeed" minOccurs="1" maxOccurs="unbounded"/></xsd:sequence></xsd:complexType><xsd:complexType name="type.H umidityP art"><xsd:sequence><xsd:element ref="jmx̲eb̲add01:Humidity" minOccurs="1" maxOccurs="unbounded"/></xsd:sequence></xsd:complexType><xsd:complexType name="type.AnyE lementP art"><xsd:sequence><xsd:any minOccurs="1" maxOccurs="unbounded" namespace= ##other /></xsd:sequence></xsd:complexType>メジャーバージョンアップを図り，WindSpeedPartもHumidityPartも新設して新たな名前空間を与える．

第4図－ 65 －

続き

測

候

時

報

辞書と XML スキーマ＊

5
5.1

辞書

79.5-62012のとおり XML スキーマを厳密に定義しないことによる利点があるためである．

気象庁 XML は，これまで各業務が独自に定め

辞書の書き方，XML スキーマの自動生成ツーてきた情報の形式を統一して作成する標準フォー

ルに関する詳細については第 12.1 節を参照頂き

マットであるため，可能な限り構造の共通化を行

たい．

った．XML スキーマは，前述のとおり妥当性検証等の機能による共通化の作業の効率化や，利用

5.2

者側のシステム開発の自動化など機械処理においXML スキーマは XML の構造を適切かつ厳密て利用価値が高いが，本質的に機械可読のためのに表現することが可能となる．更に XML インス形式であり，人間による作業においては利用しづ

タンスの妥当性検証により，その XML インスタらい．

ンスが XML スキーマに適合しているかを厳密に

気象庁 XML の策定作業において，各担当者がXML スキーマとオフライン仕様

確認することができる．

W3C XML Schema について十分な知識があるわ

このことは非常に強力な妥当性の検証機とな

けではなかったことや，利用者も気象庁 XML のる反面，XML スキーマを厳密に定義することは，構造について理解しやすいよう，人間可読性を重XML 構造の変更といったバージョンアップや，視するため，マイクロソフトエクセル形式による状況変化に伴うとりうる値（enumeration）の追加

辞書を XML スキーマとともに作成することとしにおいても，強力な妥当性検証により不適合とのた．なお，社会的にはこの「辞書」を「XML 要判断を下される可能性が高いことを示す．また，

素辞書」「項目表」と呼ぶ場合もある．

その対応のためにシステム改修が多数発生するこ辞書は単に人間にとって読みやすくするだけでなく，次の観点でも利用する．
・大規模な XML 構造，多種の XML 構造を整理するため．

とが予測される．XML 電文に紐付く業務の大きな変更であればシステム改修が発生するのは当然と言えるが，業務や修正点の規模に関わらず一律
システム修正が必要となるのは当庁の本意ではな

・現モデルを新モデルにマッピングする際に，い．このため，XML の構造変化とならないとり

各項目を摺り合わせる（ハーモナイゼーショ

うる値の変更等において XML スキーマの変更とンともいう．）目的で利用するため．

ならないよう，XML スキーマにおいてその値を・XML スキーマは原則人間が読むものではな

反映しない運用とし，一方で値の確認が必要な人い（機械可読形式）ので，人が整理して理解のためにその内容が分かるようにした仕様を提示するため．

できるようにした．このような仕様をオフライン

気象庁 XML の辞書形式は，親要素定義，個別仕様と呼ぶこととし，気象庁 XML においては仕の各子要素定義，属性定義，要素値・属性値のと様書本文や辞書，運用指針等によりオフライン仕りうる値のそれぞれにおいて，1 行ずつ記載して様を明確化している．

いく形式となっている．また，XML スキーマのこのように，気象庁 XML では XML スキーマ

定義と辞書の構造に関する定義については必ず対ではなく，オフライン仕様により定義している要応している．これは辞書を元として XML スキー

件も多い．しかしながら，何もかもをオフライン

マをツールにより自動生成しているからである．

仕様とすると今度は曖昧な仕様となりかねない．

一方，子要素や属性のとりうる値については，辞

このため，XML スキーマで定義するか，オフラ

書上の「とりうる値」列に記載されている値であイン仕様で定義するかについては要件個別に検討っても，XML スキーマには反映しないことが可を行っている．具体的な使い分けについて，以下

能な仕様となっている．この点については，次項にまとめる．

*第5章

杉山－ 66 －

測

候

時

報

79.5-62012

なお，運用指針 Ver1.2 ではマイナーバージョ（1）とりうる値
とりうる値（enumeration）については，前項のとおり，XML スキーマで定義可能な値であるが，ンアップでも変更履歴を記載となっているが実際にはしていない．詳細は第 10.2 節参照．

オフライン仕様として辞書やコード表にて示している場合が多い．基本的に以下のいずれかの場合（2）import 要素の次に出現するコメントアウト

は XML スキーマによる enumeration として定義

import 要 素 の 次 に 出 現 す る コ メ ン ト 記 載 にし，それ以外は XML スキーマ側ではとりうる値「Network Schema Location」として，コメントアの基底型を，オフライン仕様側ではとりうる値等

ウトした import 要素行が並ぶ．これは通常の有詳細を定義としている．

効な import 行が XML スキーマの名前空間と同名・出現する値が明らかに確定している場合．

のローカルに保存されているスキーマファイルを・とりうる値に追加・変更が発生するような業

読み込む設定となっているのに対して，コメン

務変更自体の想定が大規模であり，いずれにトアウトした import 要素にはインターネットにせよシステム改修を伴うことが想定される場より取得可能な XML スキーマファイルの取得先

合．

を記述している．システム的にインターネット

・利用者による重要な検索キーとして利用されからスキーマファイルを取得したい場合は，当該 URL にアクセスするようにしておけばよいが，ることが想定される場合．

取得できない場合にシステムが停止するリスクを（2）any 構文のとりうる名前空間値

考えると推奨はせず，あくまでスキーマの所在位

W3C XML schema の any 要 素（ 第 4.3 節（4）置を示しているものとして理解した方がよい．

項参照）では namespace 属性により出現する任意の要素を指定できるが，これについては以下のル（3）Enumeration's コメント記載

ールによって，XML スキーマ側とオフライン仕

末 尾 に「Enumeration's」 と し て コ メ ン ト し た
simpleType 要素行が並ぶ．これは辞書からスキー様側とで定義を変えている．
・属する名前空間以外の名前空間全てを許容する場合（namespace 属性値“##other”），XML

マを自動生成する際に，とりうる値（enumeration）
として定義した値の一覧となる．

スキーマ側は namespace 属性値を“##other”
気象庁 XML の概要＊とする定義のみを記載するが，オフライン仕6様では想定している名前空間全てを併せて列

気象庁 XML は，気象庁における各種防災情報を一元的に取り扱うための情報基盤として，電文挙する．

フォーマットに XML 形式を採用し，仕様と管理5.3を一元化している．

XML スキーマの注釈について

気象庁 XML の XML スキーマには注釈情報と情報はフォーマットの運用管理を明確化するたして以下の 3 点が含まれている．

め，構造化と併せる形で名前空間を分けている．

（1）documentation 要素値

具体的には，電文全体を「管理部」「ヘッダ部」「内

annotation 要素下の documentation 要素値には，容部」に分け，管理部を含めた全体構造で 1 つ，対象となるスキーマに関連する以下の情報を含めヘッダ部で 1 つ，内容部に当たる気象要素固有のている．

情報構成に対して 3 つ，及び共通気象要素と拡張・気象庁防災情報 XML フォーマットの一部でしている．これら名前空間を示す URL に対応すある旨の表記と権利表記．
・更新履歴（バージョン情報，日時，変更概要）*第6章

用でそれぞれ 1 つずつの計 7 つの名前空間を利用

杉山－ 67 －

る形で，気象庁 XML の HP を開設しており，最

測

候

時

報

79.5-6

2012

新の XML スキーマも同 URL から入手可能とな

ISO/IEC 10646（UCS） と す る．」（ 原 文 は 英 語 ）っている．

となっており，また W3C による XML 日本語プ

「管理部」は電文に関するメタ情報を提供する．

ロファイル [9]（JIS でも TR X 0015:2002 にて規「ヘッダ部」は防災情報を各電文共通的に取得可定）においても「文字符号化スキームは UTF-16

能な部分であり，この部分は電文間で画一的な処

か UTF-8 を推奨する．」（原文は英語）となって理により同等の情報を適切に取得できるようにしいることから，将来性等を考慮して UTF-8 を利ている．これにより，情報の主たる部分について用することとした．

その選別処理や取得処理は共通化が可能となってまた，UTF-8 には半角カナと NEC 特殊文字，

いる．「内容部」は情報固有の詳細な情報を含め

及び IBM 拡張文字が含まれるが，運用指針 6 項るところであり，この部分についてはむしろ情報にあるとおり，これらは使用しない．

ごとに独立した構成となっている．しかしながUTF-8 は Unicode のエンコーディング形式のら，電文間に共通する気象要素については共通辞一つであるが，この Unicode においてはシステ

書（追加要素）及びそれらを組み合わせた型（サム・ソフトウェア間における変換表相違問題があブセット）を共用して処理の流用・統一化が図れる．これは Unicode が似た形象の文字を複数定義るようにしている．

しており，また Shift_JIS や EUC（Extended Unix

使われる値や型も可能な限り共通化を図っていCode）における各文字と Unicode 上での文字の対る．一般的に使われる時刻情報や地理空間情報に応について，規格としては説明しなかったことについてはそれぞれ W3C XML Schema の Datatypes

より，システムやソフトウェア間で変換ルールが: dateTime 型 [7] と ISO6709 といった国際的な規一致しなくなったためである．具体的には大きく格を利用することで共通化している．また，気象

分けて CP932 に代表されるマイクロソフト系と要素値を示す要素の構造についても，示す気象要

JIS 系に分かれ，この間で変換ルールが異なるこ素に関係なく持ちうる属性が同じであり，同じ意と か ら，Shift_JIS・EUC → Unicode，Unicode →味を持つように共通化している．

Shift_JIS・EUC のように変換を 2 度行うと問題とこのような大構造の共通化のほか，詳細部分の共通化を図るほか，バージョン管理や名前空間管

なりやすい．Shift_JIS を例とすると，具体的な影
響は次のとおりとなる．（第 1 表，第 5 図）理の方針を事前に示すことにより，フォーマット

・Shift_JIS → Unicode を行う場合には特段の問そのものの運用管理体系を分かりやすくし，利用

題は発生しない．ただし，システム・ソフト者における拡張等の準備を行えるようにもしておウェアによる変換ルールの差異により，作成

り，これらの対応により利用者における気象庁

される Unicode のコード値は個々に異なる場

XML の処理が平易となるよう考慮している．

合が発生する．またこのため，判定・文字列解析を行う場合はどのコード値かを意識する

7＊

全体構造の解説

7.1

必要はある．
・Unicode → Shift_JIS を 行 う 場 合， 変 換 元 の

基本構造（1）文字コード（仕様 1.3.1 項）

Unicode コード値に対応する変換テーブルで

文字コードは「UTF-8」を使う．

変換する場合は問題が発生しないが，対応す当初の庁内の議論においては，これまで利用

る変換テーブルでない場合，Shift_JIS に変換

してきた歴史的経緯から Shift_JIS（JIS X 0208 附

できないコード値が存在することからその文

属書 1 シフト符号化表現）が優勢であったが，字は文字化け（一般的には“?”や“〓”にXML 規格 [6] 2.2 項において「使用できる文字は，なる）となる．例えば U+00A5 から Shift_JIS

タブ（Tab）・復帰（CR）・改行（LF）・Unicode・に変換するテーブルは CP932 にはなく JIS 規*第7章

杉山， 第 7.1 節（8）項

杉山・竹田，－ 68 －

測

第1表

字

候

時

報

79.5-6

2012

Unicode とシフト JIS の変換におけるマッピングの差異の例

文

シフトJIS

JIS規格(Java/nkf等)

CP932(Windows変換)¥

0x5C(YEN SIGN/円記号)

U+00A5(YEN SIGN)~

0x7E(OVERLINE/
オーバライン)
0x815C(EM DASH/
ダッシュ(全角))
0x8160(WAVE DASH/
波ダッシュ)
0x8161(DOUBLEVERTICAL LINE/双柱)0x817C(MINUS SIGN/
負符号，減算記号)
0x8191(CENT SIGN/
セント記号)
0x8192(POUND SIGN/
ポンド記号)
0x081CA(NOT SIGN/
否定)

U+203E(OVERLINE)

U+005C(REVERSESOLIDUS)
U+007E(TILDE)

U+2014(EM DASH)

U+2015(HORIZONTAL BAR)

U+301C(WAVE DASH)

U+FF5E(FULLWIDTHTILDE)
U+2225(PARALLEL TO)

�
〜
‖
−
￠
￡
￢

U+2016(DOUBLEVERTICAL LINE)
U+2212(MINUS SIGN)
U+00A2(CENT SIGN)
U+00A3(POUND SIGN)
U+00AC(NOT SIGN)

U+FF0D(FULLWIDTHHYPHEN-MINUS)
U+FFE0(FULLWIDTHCENT SIGN)U+FFE1(FULLWIDTHPOUND SIGN)U+FFE2(FULLWIDTHNOT SIGN)

第1表 UnicodeとシフトJISの変換におけるマッピングの差異の例

シフトJIS “〜” 0x8160
シフトJIS “〜” 0x8160

シフトJISでやりとりしても問
シフトJISでやりとりしても問題は発生しない
題は発生しない

PCからサーバーに送信
JIS “ ”PCからサーバーに送信
0x8160JIS

シフトJIS “〜” 0x8160
シフトJIS “〜”
PC 0x8160
JavaなどでUnicodeに変換
JavaなどでUnicodeに変換

JIS“ ”“〜”0x8160
JIS系なのでU+FF5Eでは無い
UnicodeU+301C
JIS系なのでU+FF5Eでは無い
Unicode “〜” U+301C
Unicode(UTF-8等)のまま
Java
UnicodeUnicode(UTF-8等)のまま
WindowsPCに送信
WindowsPCに送信
Unicode “〜” U+301C
JIS
U+FF5E
Unicode“ “〜”
U+301C
Unicode” U+301C
WindowsでシフトJISに変換
WindowsでシフトJISに変換

Unicode(UTF-8 ) Windows系なのでU+FF5EでWindows系なのでU+FF5Eでないと変換できない???
シフトJIS WindowsPCないと変換できない
シフトJIS ???
Unicode “ ” U+301C
Windows

JIS

第5図 UnicodeとシフトJISの相互変換による文字化け発生の原因
第5図 UnicodeとシフトJISの相互変換による文字化け発生の原因

Windows

U+FF5E

JIS ???
第5図

Unicode とシフト JIS の相互変換による文字化け発生の原因－ 69 －

測

候

時

報

79.5-62012

格にしかないことから，JIS 規格変換テーブ

旧形式府県天気予報 XML[11] では，以下の理ルを用いるか，個別に U+00A5 → U+005C に由により key-value 型（Map 型）の構造を多用しする文字個別処理をした上で CP932 によるていた（第 6 図）．

処理を行う必要がある．

・要素名を固定，属性値を可変とすることによ・Unicode → Unicode の 場 合， つ ま り Unicode

り XML 構造を固定しつつ拡張性，汎用性をの文字を Unicode の処理・表示系で取り扱う
場合は，一般的にマイクロソフト系，JIS 系

高めることが可能である．
・XML 構造を固定することによりスキーマのにかかわらず Unicode の全ての文字列につい更新を極力無くすことが可能である．

て，表示するための字体がシステムに用意さ・リレーショナルデータベースへの格納においれていることから，コード値の違いによらず，てはシンプルな構造とすることがベターであ

画面等では問題なく表示することが可能となる．

る．この場合，見た目上は似て非なる文字が表示されていることから，判定・文字列解析を行う場合はどのコード値かを意識する必要

しかしながら，XML コンソーシアムとの議論
では以下の意見が出された．
・要素値の意味を属性値に持たせる場合，属性はある．

値抜きでは全く理解できず洗練性が低く見え

変 換 ル ー ル に 関 す る 詳 細 は JIS TR X
0015:1999[10] を参照のこと．

る．
・値を取得するために属性値を検索キーとする

このことについて，実装後に各電文における作

ことに変わりなく，プログラム等の改修が必

成コード値を確認した．この結果，問題となる文要なことには差がない．

字についてはおおむね使用しないか使用禁止文字

・スキーマの更新は，XML のバージョン管理となっていたが，ダッシュ“―”，波ダッシュ“～”，をバリデーションにより可能とするという観

負記号“－”の 3 文字については，電文単位では点もあることから，むしろ利点と見て積極的統一された利用となるものの，電文間ではマイクに利用する考え方もある．

ロソフト系，JIS 系，使用しないと利用状況が個

・属性値を多用する構造が多く見られたのは別にばらばらとなった．このことから，運用指針

DTD を利用していた経緯によるところが多6.2 項にもあるとおり，利用状況を説明すること

く，最近は要素での構造化に主流が移っていにより，利用者におけるシステム動作不良の軽減

る．

を図ることとした．
なお，将来的にはコード値の統一が望ましい．

これらの議論により，XML コンソーシアムからの意見を重要視して，気象庁 XML では key旧形式府県天気予報系XMLの例<property name="特定域風"><t><v k="地域名">石巻地域/陸上</v><v k="風向">西</v><v k="風速">4</v>

<v k="地域名">石巻地域/海上</v><v k="風向">南西</v><v k="風速">4</v></t>:（2）改行コード（仕様 1.3.1 項）
改行コードは「改行」（LF：0x0A）を使う．
なお，XML 規格 [6]2.11 項では「入力された（文書実体を含む）外部解析対象実体の中の全ての行末（連続する 2 文字 #xD #xA，及び #xA を後ろに伴わない #xD）を，解析を行う前に XML プロ
セサが単一の #xA に変換することによって正規化する処理とする．」（原文は英語）となっている．
（3）要素と属性の使い分け（仕様 1.3.2 項）
基本的に要素名により構造化を行い，属性については要素値に対するメタデータを与える．

第 6 図 Key-Value Store 型（KVS 型 ）XML 格 納 形 式の例
例は旧形式府県天気予報系 XML（名前空間“ http://
第6図 Key-Value Store型（KVS型）XML格納形式の例
adess.kishou.go.jp/xml10”）より．要素 v の属性 k の値
例は旧天気予報系XML（名前空間 http://adess.kishou.go.jp/xml10が Key にあたり，その Key の示す値が v の要素値とな
Keyにあたり，そのKeyの示す値がvの要素値となる．
る．

－ 70 －

測

候

時

報

value 型を採用しないこととした．

79.5-62012語）となっており，URI で非 ASCII 文字を用い

要素名により構造化することにより，属性値にる場合は %-escaped する必要がある（IETF RFC

ついてはメタデータを与える．考え方として，属3986[13]）ことからも，日本語及び URI 記法に変性値がなくても構造上理解できるようなもののみ

換した日本語を利用しない．

を属性値とすることとした．具体的には以下のとおりである．

要素値，属性値については言語の制限を設けな
い．

・要素値の単位，コード体系
・要素値に対する補足的・付加的情報（5）要素のネスティング（仕様 1.3.3 項関連）

・要素値に関する人間可読的な情報要素のネスティング（入れ子）については，基要素値の単位，コード体系については，基本的になくても理解できるよう，常に同じ情報種別の本的に以下のルールによる．
ア

地理空間，時間空間，防災・観測要素のそXML 電文における同じ構造の要素下においてはれぞれは並行概念として構造化し，親子関係

同じ属性値が出現することを原則とする．ただし，としない．

この原則について，実際はかなり緩く運用されてこれらの概念はそもそもお互いに独立している

おり，同一要素名において単位系を示す属性値をものであるが，これまでは情報の特性に合わせて複数併記して，同一物理値の別表現として併用し親子関係としてきたものが多い．今回の気象庁ている電文もある．（第 7 図）

XML においては，汎用性を高めること，及び検索時にどの要素で検索する場合でも同等の DOM（4）XML 構造と言語（仕様 1.3.3 項関連）

ツリーの走査により検索できるよう，これらは並要素名，属性名については英数字を用いる．そ行概念として構造化する（第 9 図）．

れぞれ，それら要素・属性を意味する英語によるイ

地理空間において，行政区画や防災上の区こととし，複数単語からなる場合については，要画構成を元とした親子関係を原則として行わ

素名は Upper Camel Case，属性名は Lower Camel

ない．

Case により記述する（第 8 図）．英単語は読みやいわゆる気象庁予報警報規程における地方予報

すさを重視し原則として省略しない．ただし，頻区，府県予報区，一次細分区等の区画構成の上級，繁に出現し，かつ文字数が多い単語についてのみ，下級といった区画構成の概念を，そのまま XML

誤解を生じない範囲での省略形の利用を認める．

における親子関係としない（第 9 図）．このよう

この場合，単語の省略を行っていることを明示すな構成は取扱い上，一見合理的に見えるが，実際る．

に情報の取扱いを検討した場合には，以下のとお名前空間については，W3C 勧告 XML 名前空

りとなることが多い．

間 1.1[12] 2.3 項「%-escaped された文字を名前空・その場の状況により利用者が欲している区域

間で使用しないことを強く推奨する」（原文は英構成の粒度は必ず決まっており，親子階層を台風指示報より<jmx_eb:WindSpeed type="最大風速" unit="ノット" condition="中心付近" description="中心付近の最大
風速３５ノット">35</jmx_eb:WindSpeed><jmx_eb:WindSpeed type="最大風速" unit="m/s" condition="中心付近" description="中心付近の最大
風速１８メートル">18</jmx_eb:WindSpeed><jmx_eb:WindSpeed type="最大瞬間風速" unit="ノット" description="最大瞬間風速５０ノット">50</jmx_eb:WindSpeed><jmx_eb:WindSpeed type="最大瞬間風速" unit="m/s" description="最大瞬間風速２５メートル">25</jmx_eb:WindSpeed>

第 7 図 単位系の使い分けにより同一物理値の別表現として併用している例
unit 属性値によりノットで値を取得する場合と，m/s で値を取得する場合で併用している．ただし，出現順序等は固定しているので，値を取り間違う等は発生しない．

第7図 単位系の使い分けにより同一物理値の別表現として併用している例．
unit属性値によりノットで値を取得する場合と，m/sで値を取得する場合で併用している．ただし，出現順序等は固定しているので，値を取り間違う等は発生しない．
－ 71 －

測

報

e

el

時

as

C am C

候

clipart by illpop.com

第8図

Camel Case の図

掘り下げて走査する利点がない．
・利用者が欲している区域構成の粒度が決まっていることから，むしろ粒度別に取りまとめた方が利用しやすい場合がある．
・全体的に見て，深掘り構造は利用者としてもXML 技術としても取り扱いづらい．
このため原則としては区域構成を元とした親子関係は行わない．逆に実際の取扱い上，上記利点・欠点がむしろ逆となる場合は，例外的に親子関係とした構造化としても構わない．
ウ

同一要素を繰り返す場合，取り扱いの平易化やインスタンスの明確化を図るために，上位に繰り返しを束ねる要素を置く．この場合の束ねる要素名は束ねられる要素名を複数形化した単語とする（第 10 図リスト a）．

繰り返し出現する要素の XML 的取扱いのデファクトスタンダードはない．例えば，JavaEE における servlet deployment descriptor（配備記述子：
いわゆる web.xml）においては，単純に必要な回数分同一要素を繰り返して記述する（第 10 図リ
スト b）．一方，XSLT の for-each 構文や DOM に
対する iterator を考えると繰り返される要素はひとくくりとしてグルーピングした方が取扱いは平易となる．いずれも観点が違うだけなのでどちらが良い悪いはないが，利用しやすさと構造把握の平易さを優先し，親要素にて束ねるものとする．
（6）呼び出した要素の名前空間の属し方
共通要素をまとめた要素辞書（第 7.2 節（2）項参照）のように，ある構造の中で他の名前空間

79.5-62012

リストa：親子関係としてきた例（旧形式気象警報・注意報XML）<area code="8500" name="佐賀県"><area code="8510" name="南部"><area code="8511" name="佐賀多久地区"><kind level="注意報" name="雷" type="継続"><property endTime="２７日昼過ぎ" name="雷"overTime="にかけて 以後も続く"/><addition name="付加事項">竜巻</addition></kind><kind level="注意報" name="強風" type="継続"><property direction1="南" endTime="２７日昼過ぎ"
name="風" peakTime="２６日昼過ぎ"><content areaName="陸上" name="最大風速"
unit="メートル">１２</content><content areaName="海上" name="最大風速"
unit="メートル">１２</content></property></kind><kind level="注意報" name="波浪" type="継続"><property endTime="２７日明け方" name="波"><content name="波高“
unit="メートル">１．５</content></property></kind></area><area code="8512" name="鳥栖地区">:リストb：並行概念とした例（気象庁XML）<Item><Kind><Name>波浪注意報</Name><Code>16</Code><Status>発表</Status><Property><Type>波</Type><AdvisoryPeriod><EndTime><Date>３日</Date><Term>夕方</Term></EndTime><OverTime>にかけて 以後も続く</OverTime></AdvisoryPeriod><PeakTime><Date>２日</Date><Term>夜のはじめ頃</Term></PeakTime><WaveHeightPart><Base><jmx_eb:WaveHeight type="波高" unit="m“
description="２．５メートル“>2.5</jmx_eb:WaveHeight></Base></WaveHeightPart></Property></Kind><Area><Name>富山市</Name><Code>1620100</Code></Area><ChangeStatus>警報・注意報種別に変化有</ChangeStatus></Item>:

第 9 図 要素のネスティング構造
リスト a は旧形式気象警報・注意報 XML，リスト
b は気象庁 XML．リスト a では地域を示す area 要素
第9図 要素のネスティング構造
が細分区構造に併せてネスティング構造をしている上
リストaは旧気象警報・注意報XML形式，リストbは気象庁XML形式．リストaでは地に，警報・注意報の種別を示す kind 要素がその子要素が細分区構造に併せてネスティング構造をしている上に，警報・注意報の種別ををなして，更に property 要素にて時間情報を補足しての子要素をなして，さらにproperty要素にて時間情報を補足している．リストbでは注意報を大枠で表すKind要素と地理的情報であるArea要素から成り立ち，Kind要
いる．リスト b では大きく分けて警報・注意報を大枠
意報を示すName要素と詳細情報であるPropertyの下に各種時刻情報を含めていで表す Kind 要素と地理的情報である Area 要素から成れは並行要素となっており，ネスティング構造とはなっていない．
り立ち，Kind 要素の中で警報・注意報を示す Name 要
素と詳細情報である Property の下に各種時刻情報を含めている構造で，それぞれは並行要素となっており，
ネスティング構造とはなっていない．

－ 72 －

測

候

時

報

79.5-62012���a����XML<Headline><Text> ������������������������������������
�������������</Text><Information type="����"><Item><Kind><Name>���</Name></Kind><Areas codeType="���������"><Area><Name>�������</Name><Code>211</Code></Area><Area><Name>�������</Name><Code>212</Code></Area><Area><Name>�����</Name><Code>220</Code></Area><Area><Name>�����</Name><Code>222</Code></Area></Areas></Item><Item>:
���b� JavaEE����������web.xml�
<servlet><servlet-name>default</servlet-name><servletclass>org.apache.catalina.servlets.DefaultServlet</servletclass><init-param><param-name>debug</param-name><param-value>0</param-value></init-param><init-param><param-name>listings</param-name><param-value>false</param-value></init-param><load-on-startup>1</load-on-startup></servlet><servlet><servlet-name>jsp</servlet-name><servletclass>org.apache.jasper.servlet.JspServlet</servlet-class><init-param><param-name>fork</param-name><param-value>false</param-value></init-param><init-param><param-name>xpoweredBy</param-name><param-value>false</param-value></init-param><load-on-startup>3</load-on-startup></servlet><servlet-mapping><servlet-name>default</servlet-name><url-pattern>/</url-pattern></servlet-mapping><servlet-mapping><servlet-name>jsp</servlet-name><url-pattern>*.jsp</url-pattern></servlet-mapping>

第 10 図 繰り返し構造の例
リスト a は気象庁 XML，リスト b は JavaEE における配備記述子の例．リスト a では，複数の Aera 要素を束ねる目的で Areas 要素が出現している．リスト b では，servlet 要素や init-param 要素，servlet-mapping 要素が複数回の並行出現がされているが束ねられていない．

－ 73 －

測

候

時

報

79.5-62012に属する要素又は型を利用する際，利用したい

的手法は現在の所ないようである．一例として要素の名前空間が呼び出した側に属するのか呼ISO2955（Information processing – Representation

び出された側に属するのかは検討する点となるof SI and other units in systems with limited character（第 11 図）．XML スキーマ（辞書）の記述についsets）もあるが，これでも 2 乗分の 1 を示す表記て，呼び出した側の名前空間に要素が属する場として「m-2」と「1/m2」の両方が認められてい合，呼び出した側の当該要素を定義する element

るなど，画一性に欠ける．また，気象庁としては要素の type 属性値（基底型）が呼び出された側

SI 単位系に限らず慣用的に用いられている単位の complexType 要素の型名（親要素）とする型参系も用いる必要がある．このことから，以下の記照となり，呼び出された側の名前空間に要素が属法を元に，その都度定めていくこととする．

する場合，呼び出される側で予め要素を定義した・原則として，SI 単位系を用い，単位を示す一上で，呼び出した側はその要素名を element 要素

般的な英数字表記を用いる（“m/s”等）．

の ref 属性値とする要素参照を用いる．

・SI 単位系でなくとも一般的なものはその英数

気象庁 XML では，気象要素等を示す要素名は，

字表記を用いる（“kt”等）．

それを呼び出した状態に属するのではなく，一連・乗数を示す接頭辞も用いる（“cm”等）．

の要素の定義として呼び出される側にまとまって・一般的でないもの，英数字表記が誤解を招きおく方が自然であるとして，一律呼び出された側やすいものは日本語で表記する（“メートル”に属するようにしている．

等）．
・同一の単位系については気象庁 XML 内で同（7）単位表記（仕様 1.3.9 項）

一の表記とする．

物理量を示す各単位をテキスト表記する一元��������
jmx_mete������

いずれにしても，同一の意味を示す単位が違う

��

���

type.TemperaturePart1

jmx_eb:Temperature

jmx_eb:type.Temperature

Temperature

jmx_eb:type.Temperature

Temperature

type.Temperature �������������
�������
���������������������
��������������������
���������
�����������������������
�����������
���������

type.TemperaturePart2

jmx_eb���������

��������

type.Temperature
type
����
refID

���������
<jmx_mete:Property>�������������������������������������������������
��������������������
��������
<jmx_mete:Property>���������������������������������������������������
��������������������
第 11 図�����������

���������
���������������

�����������
������������
������������
��������������
�����������
�����������
��

名前空間が呼び出される側に属する場合と呼び出す側に属する場合の例－ 74 －

測

候

時

報

79.5-62012

表現とならないように管理を徹底する必要があ

タグ（空要素），“xsi:nil="true"”表記があり，基る．

底型として許容する特殊な値として，“NaN”（非数），“INF”（正の無限大），“-INF”（負の無限大）（8）特定の値の表現などがある．これらと W3C XML Schema におけ

台風や低気圧の移動速度や移動方向を表すとき

る各データタイプにおける対応状況表を第 2 表にに，通常は「1 時間におよそ 20 キロの速さで西まとめる．なお，“xsi:nil="true"”を利用した空タ

北西へ進んでいます」といった表現をする．これ

グ表記については実装間の差があり，属性値が取を XML で表現すると例えば次のように記述できれない実装と取れる実装があったことから，属性る．

値を利用する要素では利用しないことが望ましい
ことが判明した（詳細は第 11.1 節）．

<Direction> 西北西 </Direction>

これらの状況を踏まえ，対応方針として以下の<Speed unit="km/h">20</Speed>

4 案を検討した．具体例については第 12 図，メ
リットデメリットについては第 3 表にまとめる．

ところが，台風情報や全般海上警報では，移動速度が 5 ノット以下の時に移動方向が定まる場合
は移動速度に「ゆっくり」と表現し，移動方向が定まらない場合は移動速度に「ほとんど停滞」と表現する．上記の移動速度を示す Speed 要素の値
は，通常の場合であれば数値のため，型は ﬂoat型（浮動小数点型）と定義しておくのが適切であるが，「ゆっくり」や「ほとんど停滞」は ﬂoat 型
ではないため，辞書で Speed 要素の値を ﬂoat 型
で定義してしまうと，「ゆっくり」や「ほとんど停滞」を表現できない（妥当性検証が成功しない）．

案1

負の最大値等特殊な値に意味を持たせる．
案2

親要素を作成し，その下に値の要素と状況の要素と 2 つを用意して利用する．
案 2’親要素を作成せず，単に値の要素と状況の要素と 2 つを用意して利用する．
案3

実質的な基底型と string 型を union で組

み合わせる．
案4

値を属性値とし，可視化すべき情報や状況を示す文言を要素値とした構造にする．

一方，「ゆっくり」や「ほとんど停滞」を表現するためだけに Speed 要素の値を string 型（文字列

案 1 については本議論の直前に，当時運用して型）で定義すると，速度の値としては間違った文

いた電文の処理において利用者のシステムがダミ

字列も妥当性検証で妥当とされてしまうので，適ー値を任意の値として読み取ってしまい，社会的切ではない．観測データの欠測に関しても同様で，に大きな影響を与える誤作動をした事例があった

次の例のとおり，欠測について，気象要素についことや“NaN”は計算を成功させない値という強ては空要素とし，Aqc 要素のように別の要素で状い意味を持つことからも，利用者のシステムにお態を表すという案もあった．

ける「処理の安定性」（プログラムの完全性）に不安があった．案 2，案 2’については，特定の<Snow>

値とする場合に，値を格納してきた要素そのもの<Depth unit = "cm "></Depth>が省略となり，逆に処理の安定性に欠けるので<Aqc> 欠測 or 計画休止 </Aqc>

はないかという意見があった．案 3 は空タグを</Snow>

許容する基底型を XML スキーマ union 構文により自作するというものであるが，java 処理系など

このように特定の値の処理については手法もが XML の要素値を変数に自動バインディングす

様々にあることから，XML コンソーシアムと担る際，基底型が string 型になってしまいメリット

当者により議論を行った．

を生かせないという問題がある．案 4 についてはある要素値として許容する特殊な値としては空－ 75 －

一見きれいな格納ができるように見えるものの，

測

第2表

候

時

報

79.5-62012

特殊な値とデータタイプ

����
�����

stringshort�
×������������������� ���
���
��
NaN
×
�
INF
×
���
���������������� ���������� ����������������
�����������
����������

int
×
���
×
×
���

long
×
���
×
×
���

float
×
���
�
�
���

double
×
���
�
�
���

�1 �������������������
���<Aelement>-2147483648</Aelement>�2 �����������������������������������
���<PlumeHeight><AvobeSeaLevel unit=“FT”>5800</AvobeSeaLevel><Condition>����</Condition></PlumeHeight>

�2�����������������������������������
(<SpeedValue>�<SpeedCondtion>�)���<PlumeHeightAvobeSeaLevel unit="FT">5800</PlumeHeightAvobeSeaLevel><PlumeHeightCondition>����</PlumeHeightCondition>

�3 ��������string��union�������
�4 �������������������������������������
���<Speed unit="m/s" value="10.0">��������</Speed><Speed unit="m/s">��</Speed>

第 12 図第3表

特定の値に対する処理案の例

特定の値に対する処理案のメリット・デメリット．

案

方法

メリット

デメリット
負の最大値という特殊な値を使うことの危険性がある．
特定の値に意味を持たせることの社会性に疑問がある．

案１

負の最大値等特殊なスキーマ的にはシンプル．
値に意味を持たせる

案２

親要素を作成し，そ スキーマ的にはシンプル．
の下に値の要素と状 個別の要素値の取得に特殊な処理が不要． 大量のデータがあると表現が冗長的となる．
況の要素と２つを用 誤った値を使う余地もなく，問題が発生する 値の要素が無いことの社会性に疑問がある．
意して利用する可能性は低い．

値と状況の組み合わせが要素名でしか判別
親要素を作成せず， スキーマ的にはシンプル．
できないことの社会性に疑問
単に値の要素と状況 個別の要素値の取得に特殊な処理が不要．
案２’
二つの値を併せて一つの状況を説明するなの要素と２つを用意し 誤った値を使う余地もなく，問題が発生する
ど，情報によっては利用に制限がある．
て利用する
可能性は低い．
値の要素が無いことの社会性に疑問がある．

案３

案４

実質的な基底型と見た目が非常にすっきりとする．
スキーマ的には煩雑となる．
string型をunionで組 誤った値を使う余地もなく，問題が発生する
個別の要素値の取得に特殊な処理が必要．
み合わせる
可能性は低いこの形式の社会性に疑問がある．
値を属性値とし，可 スキーマ的にはシンプル．
数値は数値として利用することを前提として視化すべき情報や状 見た目はすっきりとする．
きたが，「可視化された情報」が要素値とな況を示す文言を要素 誤った値を使う余地もなく，問題が発生するることから全体を同じポリシーで再検討しな値とした構造にする 可能性は低い．
ければいけない．

－ 76 －

測

候

時

報

79.5-62012

unit 属性の示す対象が要素値ではなく属性（例で案 5：

言えば value 属性値）となり，属性間の修飾とな< 要 素 type="" unit="" refID="" 状 態 ="" 数 値="">ることに違和感があるという意見があった．
これらのことを検討した結果，要素の自動バインディング自体は必須の要件でないことと，一度検討の結果，案 1 の方法を採用することとし，処理を作成すれば安定的に運用できることから，基本要素は，種別を示す type 属性，単位を示す

要素辞書（第 7.2 節（2）項参照）を含め，原則

unit 属性，参照番号を示す refID 属性に加え，状として案 3 を採用した．

態などを示す condition 属性，文字列表現を示す

また，特定の値を表現した場合の意味等の表現

description 属性からなる次のような基本形が決めに際しては，当初電文により違った属性や構造をられ，これらの属性は，要素ごとに必要なものを使っていた．数値の例外的処理を検討するに当た設定することとなった．

り，それまでに作成されたサンプル電文に使われていた属性や子要素を分類した結果，第 4 表のよ○基本形

うに，「例外の状態を示す属性や要素」，「数値の<ElementA代替となる文字列」にまとめられると考えた．ま

type="T"

同一基本要素の種別

た，基本要素辞書においては，要素ごとに属性がunit="U"単位

異なるのは避けるべきと考え，統一の仕方についrefID="R"

時系列の際の参照番号て次のとおり 5 つの構造案を検討した．

condition="C"

値の状態

description="D"

文字列表現> 値 </ElementA>

案 1：< 要素 type="" unit="" refID="" 状態 ="" 代替文
字列 ="">

これらの議論をまとめて，特定の値を表現する

案 2：

場合には要素値は空タグで，その意味等を決めら< 要素 refID="">

れた属性値により示すものとした．すなわち，特<Type></Type>定の値の表現は，空タグを許容する integer 型で<Unit></Unit>

ある nullableinteger 型（共通辞書（基本要素）上< 状態 ></ 状態 >のグローバル型定義）と，同様の ﬂoat 型である

< 代替文字列 ></ 代替文字列 >nullableﬂoat 型（同）により XML スキーマ上の定</ 要素 >

義として規定し，その意味等に当たる移動速度の

案 3：「ゆっくり」や観測データの「欠測」などの表現は，< 要素 type="" unit="" refID="">

condition 属性や description 属性によりオフライン< 要素 + 状態 >仕様であるコード表や電文ごとの解説資料上の定< 要素 + 代替文字列 >義として規定している．この場合の属性値につい

案 4：ては第 7.2 節（2）項にまとめる．

< 要素 type="" unit="" refID="">< 要素 + 代替文字列 状態 ="">

第4表

基本要素の属性や子要素の分類

例外の状態を示す属性や要素 condition 属性，aqc 属性，bound 属性，PlumeHeightCondition 要素
数値の代替となる文字列

altString 属性，remark 属性，bound 属性

要素固有の属性

Coordinate 要素の datum 属性－ 77 －

測

候

時

報

79.5-6

2012（9）インデントのための空白文字列

た．このため，一部の情報名称においてはヘッダ

XML インスタンスにおいて，見やすさを向上

部と内容部で同一の気象要素等を表現しているこするためのインデントとして空白文字列を入れるとがあるが，この点についてはシステム的に矛盾ことがある．このような空白文字列を一般的には，した情報が入ることがないように注意した上で，無 視 で き る 空 白 文 字 列（Ignorable White Space）

共通化に伴う許容点とした．なお，XML スキーと呼んでいる．気象庁 XML においても，提示しマ仕様上，内容部を示す要素は要素名も任意となたサンプル電文では多用しているところである

るが，運用上は各名前空間に属する“Body”名が，実際の XML 電文中では利用していないことの要素とする．

が多い．
実際の XML インスタンスにおいて，処理ソフ（2）要素辞書（仕様 1.3.10 項）

トウェアが無視していいかどうかはインスタンス

名前空間接頭辞を“jmx_eb”（“eb”は element

だけでは判別できず，XML スキーマによって判

basis の略）として定義している辞書を要素辞書断することとなる．

と呼んでいる．要素辞書は各情報において共通的に用いられる地理空間要素や，気圧，気温，風向，

7.2

全体構造

風速，湿度，震度，マグニチュードといった物理（1）管理部・ヘッダ部・内容部（仕様 1.2.1 項）

量について，情報の種類によらずに利用できるよ

気象庁 XML はルート要素（“Report”）の直下

う要素コンポーネントとしてひとまとめにし，共に管理部を示す“Control”要素，ヘッダ部を示通化したものである．

す“Head”要素，内容部を示す“Body”要素の共通化に当たっては同じ物理量を同じ要素とす

3 要素から成り立つ．3 要素のそれぞれの意味はるだけではなく，各コンポーネント間においても仕様書に記載されているとおりであるが，そもそ

属性名称と意味が共通化するようにしている．共もは情報をサマリー的情報としたヘッダ構造と本通化している属性名とその意味等を第 5 表のとお体構造に分ける 2 分割構造に，気象庁内部の従来りまとめる．

の電文通信手順（いわゆる気象庁 TCP/IP ソケッ

また，時刻・時間表現においては仕様 1.3.4 項

ト手順・GTS 手順）においてデータ種類コードにあるとおり，W3C XML Schema にて定義され等で利用していた情報を伝送系の情報として加えている dateTime 型，若しくは duration 型を用いて 3 要素としたものである．特に，これまでの気ることとなっており，要素辞書等における各コン

象庁の電文ではコンテンツとして示す時刻・地域

ポーネント・各要素が示す時刻・時間表現におい

情報と伝送情報として示す時刻・地域情報が明確ても同様となっている．これら時刻・時間表現にに分離できておらず，情報の運用に困難な状況がおいても第 6 表のとおり共通化された属性名とそ発生していた．気象庁 XML では，伝送系におけの意味が利用されている．

る時刻情報・発表官署情報と，コンテンツとしての業務的な各種時刻情報・地域情報を分離した．

（3）追加辞書

これにより，業務系情報の充実化を図れると同時

名 前 空 間 接 頭 辞 を“jmx_add”（“add” はに，伝送系という形で情報作成者の主観が入らな

addition の略）として定義している辞書を追加辞

い信頼性の高い情報とに分離することが可能とな書と呼んでいる．追加辞書はバージョンアップのった．この効果として，運用指針 2.1.3.4 項にあ際に要素追加の短中期的影響を少なくするため，

るとおり，情報の訂正，取消等の運用において，汎用的に用いる辞書である．利用の仕方について

これまでの旧来の方法を整理し，情報運用の明確は第 10.3 節にまとめる．

化，システム化対応が可能となった．また，ヘッダ部については各電文において共通的に取り扱えるように，出現要素や内容を画一化することとし－ 78 －

測

第5表

候

時

報

79.5-62012

共通化された属性名と意味等

���

���

type

����������������������������������������
���������������type�����������������������
����������������������������������������
�������������������

unit����������������7.1(7)���������������������
���������XML������������������������������
�����type�����unit����“m/s”�“���”�������������
���������������������������������type�����
�����������unit���������������������������
������������������������������������

refID���������������������������������������

condition����������������������������������������
�����������������

����������������������������������������
description ���������������������������������������������
��

第6表

���

significant

時刻・時間表現における共通化された属性名と意味等�������������������������������������������� � � � � � � � � � � � dateTime � � � � � � � � � � � � � � � � � � � � �significant�����������������������������������
�����������
������������������������������
���������������������������������
������������������������������������
���������������������������������������
������������������������������������������
���������������������������������������������
���������������������������������������������������
������������ISO8601�������������������������
���������������������7�������������������
�������������

precision����������������duration�����significant����������
�������������������������

dubious������������������������������

－ 79 －

測

候

時

報

8.1

2012

として，配信システムにおける設定を Status 要素

個別要素の解説＊

8

79.5-6

管理部の個別要素

によって分けられないかという議論もあったが，管理部の各要素は業務的な利用というよりも，試験用の設定では運用状態の確認にならないこと

システム的な自動処理系，配信系で必要となる情から，Status 要素を判断して配信を分けることが報を取りまとめている．

適切かどうかという観点もあり，結果として現状のとおり「試験」は一通りのみとした．

(1）DateTime 要素（仕様 1.6.4 項，運用指針
2.1.3 項）

なお，旧来の電文を気象庁 XML の形式により配信することを想定し，WMO 形式に則った運用

DateTime 要素は発表時刻を示す要素である．

種別情報（いわゆる BBB 部）の記述を含めてい旧来の気象庁における情報提供手段では，共通のるが，後方互換のためだけに利用するものであり，

時刻要素が「観測時刻」という位置づけとなって運用開始当初から気象庁 XML の各電文を含め，おり，電文の実発信時刻を示すとは限らない．ここれから気象庁 XML 形式として新たに策定するのため，時刻自体が何を示すのかは電文の情報種

電文においてこの形式を利用することはない．

別によることとなり，また同一時刻表記の電文が複数流通する情報も多々あった．今回，一つ(3）EditorialOffice 要素と PublishingOfficeの XML 電文の中で種々の時刻表記を複数種類系

要素（仕様 1.6.1 項）

統立てて利用できるよう用意したことから，この処 理 系， 配 信 系 の 検 索 キ ー と し て は

DateTime 要素については純粋にシステム発信時

EditorialOfﬁce 要素を用いる．このため気象庁本刻という位置づけとなった．これは，いわゆるタ庁発信の電文において，EditorialOfﬁce 要素は統

イムスタンプとして，電文の順序整理に信用でき一して「気象庁本庁」として発表する．一方，るという非常に重要な意味を持つ．このため，こPublishingOfﬁce 要素は業務的な発表官署の定義の部分については人為的な誤びゅうが起きないよであることから，気象庁本庁内部部局間であってう（運用指針 2.1.3.6 項），適切にシステム設計をも統一しない．具体的な記述内容については運用行う必要がある．

指針別紙 2 を参考のこと．また，PublishingOfﬁce
要素は複数部署の W3C XML Schema の list 型記(2）Status 要素（仕様 1.6.1 項）

法を認めている．これは文字列を空白文字によりStatus 要素は通常の電文，訓練電文，試験電文

列挙する形式である．気象庁内の複数の部署によを区別する運用種別を示す要素である．従来電文る共同発表や，気象庁と都道府県や他の機関と共では分野横断的には取り入れることのできなかっ

同で発表している防災気象情報では，発表機関をたもので，気象庁 XML で初めて統一的に導入しlist 型で列挙することにより，これらの発表機関

た運用に関する情報である．このような Status 要

を個別表示等において分類する必要がある場合は素を電文全体に対して意味を持つ管理部に含める

空白文字を区切り文字（デリミタ）として値を取ことにより，運用利用して良い情報かどうかを平得すれば良く，特段分類する必要がない場合は空易に判断することが可能となる．また，運用利用

白文字も含めて 1 連の文字列として取り扱うことに際しても，システム的な動作確認を行うことをができる．

目的とする「試験」状態と業務的な確認を行うことを目的とする「訓練」を分けることも行った．

8.2

ヘッダ部の個別要素

当初，試験状態についてはその影響範囲を更にヘッダ部は各業務共通となる管理情報，及び警限定して「部内試験」「部外試験」「特定部外試験」

報事項等を統一的に取り扱うのに必要な情報を取*第8章

第 8.1 節・第 8.2 節（2）項（4）項～（7）項

第 8.2 節（1）項・第 8.3 節～第 8.4 節

竹田，第 8.5 節

杉山，第 8.2 節（3）項
清本，第 8.6 節－ 80 －

中村

横井・中村・竹田，

測

候

時

報

りまとめている．

79.5-62012に お け る 観 測 日 に つ い て は，「2008-03-22」 形式の型であるビルトインデータ型の date 型で表（1）各時刻・時間要素（仕様 1.6.4 項）記する方法と，観測日時は時刻を 0 時 0 分とし

日付時刻表記をする要素は W3C XML Schema

た dateTime 型の要素と組となるビルトインデーのビルトインデータ型である dateTime 型を用い

タ型の duration 型をとった要素の値に 1 日を示て定義されていたが，検討を進めると，dateTime

す「P1D」を入れる方法とが提案された．その型では表現できない事例が出てきた．

後，火山観測報電文のように様々な有効桁で日付

生物季節観測電文の検討において，時刻が情報

時刻を表記する必要が生じたことから，ビルトの性質上意味をなさない「観測日」を記述する必

インデータ型として定義された time 型，date 型，

要が生じた．例えば 2008 年 3 月 22 日に観測しgYearMonth 型等の dateTime 型以外の基底型を用た 場 合，「ISO8601:2004」 で は「2008-03-22」 といることについての議論も行った．
しかしながら，いうような表現が可能であるが，dateTime 型で

気象庁 XML を利用する立場から考えると，java

は「2008-03-22」のような表現は妥当（valid）とでは日時を取得する場合に dateTime 型以外の型はならないため，日時表現か辞書の基底型のどちでは実装に依存する可能性があることや，XML

らかに修正が必要である．また，火山観測報電文

コンソーシアムからも，dateTime 型以外を利用すでは，火山現象の時刻が第 7 表のように，観測精ることは勧められないとの助言があり，日付時刻

度により電文に表現する有効桁が変わる情報もあを格納する要素の型は dateTime 型のみを用いるる．更に天候情報では，「警戒期間9 月 6 日頃こととなった．

からの約 1 週間」の「9 月 6 日頃」のような前後

天候情報等で出てくる「頃」の扱いについても

1 日程度の日付時刻の曖昧さがある場合に，「頃」検討を行った．異常天候早期警戒情報では，例えを用いて現象の開始や終了についての「曖昧さ」

ば，「警戒期間を考慮した時刻の幅を持たせたいものがある．

表現しているとき，「9 月 6 日には，当日を含め当初の検討段階において，生物季節観測電文

第7表

9 月 6 日頃からの約 1 週間」とた前後 1 日，都合 3 日間程度の幅がある」という観測精度により時刻の有効桁が変わる火山観測報電文の事例

情報種別 とりうる値
解説
現在運用中の電文における用法
観測 火山観測報 "10日12時14分" 火山現象の時刻が特定で 火 山：北海道駒ケ岳
日 時：2007年01月10日12時14分
きる．
（100314UTC）
現 象：噴火観測 火山観測報 "10日12時10分頃" 火山現象がその時刻近辺 火 山：北海道駒ケ岳で発生しているが，時刻を 日 時：2007年01月10日12時10分
特定できない．その幅につ （100310UTC）頃
いても，特定できない場合 現 象：噴火したもようもある．
観測 火山観測報 "10日12時頃"
火山現象がその時刻近辺 火 山：北海道駒ケ岳で発生しているが，時刻を 日 時：2007年01月10日12時00分
特定できない．その幅につ （100300UTC）頃
いても，特定できない場合 現 象：噴火したもようもある．
観測 火山観測報 "１0日頃"
火山現象がその時刻近辺 火 山：北海道駒ケ岳で発生しているが，時刻を 日 時：2007年01月10日頃
特定できない．その幅につ 現 象：噴火したもよう
いても，特定できない場合もある．
観測 火山観測報 "時刻不明"
火山現象の時刻が断定で 火 山：北海道駒ケ岳
きない．
日 時：不明現 象：噴火したもよう－ 81 －

備考

現象が日界をまたいでいる可能性がある場合を想定．属性xsi:nil
で記述可能．

測

候

時

報

意味の「曖昧さ」に応じた処理をしてもらうこと

79.5-6（2）InfoType 要素（仕様 1.6.2 項，運用指針を想定した DateTimePrecision 要素を導入する案
があった．

2012

2.1.3.4 項）
情報の運用形態については，運用指針 2.1.3.4 項，
及び同別紙 2 に詳しく記述している．

<DateTime signiﬁcant="yyyy-mm-dd">

InfoType 要素の運用は，これまで旧来の気象庁

2008-09-06T00:00:00+09:00</DateTime>の情報提供手段では，どの電文を対象にしている<Duration>P7D</Duration>のか，どこを修正しているのか等が体系的に取り<DateTimePrecision>P3D</DateTimePrecision>

まとめられておらず，結局は人間可読的な補足メ
ッセージにて詳細を伝えるような状況であった．

提案された DateTimePrecision 要素は，その後

気象庁 XML では，これまでシステム利用し辛かの議論で DateTime 要素の precision 属性の形で基った情報の訂正や取消といった運用も整理した上本要素の基本形として取り入れられている．

で XML 構造化する改善ができた．運用指針では

日付時刻の曖昧さを表現する方法については，
基本要素の基本形という意味では上記のように技各電文の複合一意キー制約となる要素の確認や運用定義などを整理しまとめた．

術的に整理されつつあったが，最後に，ヘッダ部での日付時刻表記の型と内容部の日付時刻表記の（3）EventID 要 素（ 仕 様 1.7 項， 運 用 指 針型の共通化について議論があった．気象庁 XML
は，気象・地震・津波・火山等現象ごとの防災情報についてフォーマットを統一して提供すること

2.1.3.5 項）
情報の識別情報については，仕様 1.7 項及び運用指針 2.1.3.5 項にて解説している．

で，防災情報の利用者がそれらを有効に処理し，特殊気象報や生物季節観測報告気象報におい活用できる環境を整えることを目指して策定されて，情報のカテゴリーは，検討当時に国内気象通

たフォーマットである．このため，ヘッダ部につ

報式によって規定されていた電文形式のカテゴ

いては，dateTime 型と duration 型の基本的な型をリーを踏襲し，管理部の Title が同一であっても，用いることにより利用者が属性値による特殊な処

異なる観測項目を送信することにしている．この理をする必要のないようにしたいという意見があため，EventID 要素に発表日時分と観測項目を付る一方，内容部の要素における「曖昧な日付時刻」

加する対応をとり，どの観測項目を発表しているも含め柔軟な表記を認めた上でヘッダ部も同じ形

かを分離できるようにした．

式として日付時刻の表記については統一して共通

また，特殊気象報（風），特殊気象報（気圧）に扱うべきとの議論があった．結果として，ヘッの場合，XML 電文を発信する観測担当官署が，ダ部は体系的な整理を優先して属性値は利用しな自官署と担当区域内の特別地域気象観測所の観測いこととし，内容部は属性値を用いて簡潔な表記

データの両方を所掌している関係上，EventID 要

を行うこととした．内容部の日付時刻表記につい素に，更に「現象を観測した気象官署の国際地点ては，全ての情報で共通に利用する型として基番号」を付加することになった．このような対応

本要素辞書に DateTime 型を定義し，情報に応じは土砂災害警戒情報においても必要であり，例て「種別」を表す type 属性，「有効部分」を表す

えば管理部の EditorialOfﬁce 要素が「札幌管区気signiﬁcant 属性，「幅（時間）」を表す precision 属性，

象台」となる土砂災害警戒情報は「石狩・空知「あいまいさ」を表す dubious 属性を共通化した

地方土砂災害警戒情報」と「後志地方土砂災害

上で必要な属性を用いることとなった．これら表

警戒情報」の 2 種類あるというように，管理部記の関係について第 13 図にまとめる．

の Title 要素，管理部の Status 要素及び管理部の－ 82 －

測

候

時

報

79.5-6

2012

時間

XML

DateTime 公式発表時刻

事象の予測時刻

電文の無効

電文の有効期間

事象の予測期間

TargetDura�onTargetDTDubious

ReportDateTime

TargetDateTime

ValidDateTime

時間

XML

DateTime 公式発表時刻

電文の無効

事象の観測時刻 電文の有効期間
事象の観測・予測期間

TargetDura�onTargetDTDubious

TargetDateTime

ReportDateTime

ValidDateTime

第 13 図 時刻・時間要素関係図
上段が予測に，下段が観測に対する例．
DateTime は 電 文 の 実 送 信 時 刻 を 示 す 管 理 部 の 要 素．ReportDateTime，
TargetDateTime，TargetDuration，ValidDateTime，TargetDTDubious は ヘ ッ ダ部の要素．

－ 83 －

測

候

時

報

79.5-62012

EditorialOfﬁce 要素の組み合わせで独立した情報

して同じというだけではなく，各要素の出現回数

単位が決まらないため，ヘッダ部の EventID 要素

やとりうる値が両電文間で同じ事，つまりフォーにヘッダ部の Title 要素と同じ「石狩・空知地方

マット形式の運用が同じ方針であるということを土砂災害警戒情報」や「後志地方土砂災害警戒情示している．このように情報の形質が近いものに報」という文字列を入れることで対応している．

ついてはフォーマット形式の運用単位が同じとな

一方，火山関連情報における独立した情報のることから，そのようなものを取りまとめるため，運用として，EventID 要素の設定には課題があっ

InfoKind 要素にてその運用型を示している．これ

た．情報の利用者にとっては，独立した情報としは電文処理系として，InfoKind 要素値が同じものて「ある火山の一連の噴火に関連する情報」を示

は同じ処理系で解析・加工処理が可能であり，出すことが有用と考えられる．しかし，「一連の噴火」

力時の分類において管理部 Title 要素を活用するについては必ずしも明確に区別できるものではなことを想定している．

く，噴火しない場合や終了しないまま次のステー

InfoKindVersion 要素の値について，数字がマイジを迎える場合，複数年にまたがる場合もある．

ナーバージョンアップによる増加となっている限

このことから，「一連の噴火」による区別は行わ

り，前方互換する．「気象庁防災情報 XML フォ

ず，独立した情報としては，「ある火山の噴火にーマットバージョン管理表（フォーマット別）」

関連する情報」を単位とすることとし，EventID

によって，InfoKind 要素別の最新バージョンと更要素に「火山コード」を実装して識別することと新履歴が判別できるが，各電文単位で利用する場

した．また，噴火に関する火山観測報では，現在

合は最新バージョンでなくても，「気象庁防災情も個々の噴火の発生が観測された場合の情報とし

報 XML フォーマットバージョン管理表（資料別）」て発表していることから，火山コードに加えて，の情報名称別で最新の InfoKindVersion 要素の値

この個々の「噴火」の識別が必要である．本来はよりも上位のバージョン番号に対応しているソフ

ID として「噴火時刻」を付加するところである

トウェアであれば，当該電文の処理が可能となる．

が，その時刻自身の訂正もありうることから，観バージョンアップに関しては第 10 章にまとめ

測後に最初に発表した電文の発信時刻を EventID

る．

要素の値として付加することとした．なお，桜島
等では，ある爆発的な噴火について第 1 報，第 2（5）Information 要素

報で発表したり，噴火開始から継続する「一連のInformation 要素は防災気象情報の個別事項を大噴火活動」として発表している火山観測報の情報

きな粒度でひとくくりにする要素である．

もあるが，一連の事象としてシステム上で識別でInformation 要素の type 属性は防災気象情報事

きるだけのアルゴリズムが構築できていないこと

項の種別を示す．Information 要素同士は情報利用から，現時点ではこれまでと同様に訂正報，取消としては排他的観点に立つことが多い．例えば気報を除いて電文ごとに EventID 要素値を割り振る

象警報・注意報の情報を利用する場合，利用者はこととした．

大きな細分区単位としてみるのか，市町村単位としてみるのかのいずれかでのみ利用し，同時にそ（4）InfoKind 要素，InfoKindVersion 要素（仕様 2.3 項，運用指針 1 章）の情報を利用したり重ね合わせたりする人は少ない．つまり，type 属性値が“気象警報・注意報（一InfoKind 要素は管理部 Title 要素と異なり，フ次細分区域等）”として検索・取得するか，“気象ォーマット形式の運用単位での整理を行う情報で警報・注意報（市町村等）”として検索・取得すある．例えば，管理部 Title 要素で「府県気象情るかは利用時・検索時の段階で決まっており，両報」と「地方潮位情報」とは，地理的・気象学的方を利用する人は少ないということである．逆にな概念が違うのみでフォーマット形式は全く同じ

いえば，XML 構造の設計として Information 要素

である．この同じというのは，XML スキーマとで情報を分離することを検討する場合，その際の－ 84 －

測

候

時

報

79.5-62012

粒度は，使用時にこのような排他的に利用するこ

8.3

共通要素（基本要素辞書）とを想定する程度の粒度と考えればよい．

（1）地理空間情報の拡張

なお，設計当初，警報事項を示すために本要素

地理空間情報 の 表記 について， 気象庁 XML

名は“Warning”としていたが，防災気象情報と仕 様 ド ラ フ ト 版 の 段 階 で は， 地 震 分 野 辞 書 のして汎用的に利用することを考えて，現在の名称

Coordinate 要素に，その値は国際標準規格であるへと変更した．

「ISO6709」を用いることとなっていた．
一方，全般海上警報の電文を検討する過程で，（6）Item 要素

低気圧の位置など地理空間情報を利用する事項がItem 要素は防災気象情報要素である Kind 要素

出てきた．ドラフト版で地理空間情報を利用すると，その対象地域・地点全体要素である Areas 要

ものは，地震の震源など「点」を表すものだけで素をまとめた親要素である．ここで重要なのはあったが，全般海上警報では前線のように複数のKind 要素と Areas 要素の関係が兄弟要素であり，点を結んでできる「曲線や直線」，海上濃霧警報

親子関係を築いていないことである．これは，のように座標で指定した「閉曲線，多角形，領域」

XML の構造上，防災気象情報要素の下位概念とといった，点ではない地理空間情報を利用する事

して対象地域・地点全体要素があるわけでも，ま項があり，拡張が必要となった．

たその逆でもないことから，この 2 つを親子関係

ISO6709 には複数の地点の表記方法も規定されとするのではなく，兄弟関係とした方が適切であていたので，「点」を表す Coordinate 要素に加え，るとの考えからである．これにより，防災気象情

スキーマとしては同じ型ではあるが，「曲線」「直報要素と対象地域・地点全体要素との間で，1:1，線」を表す Line 要素，「閉曲線」「多角形」「領1:N，N:1，N:N の複数の関係を築くことができる域」を表す Polygon 要素を加えた．また，全般海ことから，各情報の特性に合わせてこれらの運用

上警報における警報の対象区域は重要な警報事項

パターンを定めていく．なお，一般的には利用がであるため，ヘッダ部で対象領域を示す Area 要

煩雑になるので，N:N は利用していない．

素において記述する必要が出てきた．このため，ドラフト版では地震分野辞書で定義されていた（7）Area 要素

Coordinate 型を気象関連の電文でも利用できるよ

Area 要素は対象地域や地点を示す要素である．

う，共通辞書へと移行した．その後，全般海上警

子要素として対象地域・地点名称を示す Name 要報の対象領域に対応するため，Area 要素の Code素，同コード値を示す Code 要素，地理空間情報（第要素の出現回数は「0 回か 1 回出現」に変更する

8.3 節（1）項参照）で表現される jmx_eb:Circleと と も に，Coordinate 要 素，Line 要 素，Polygon

要 素，jmx_eb:Coordinate 要 素，jmx_eb:Line 要 素

要素や予報円を示す Circle 要素もとれるように拡及び jmx_eb:Polygon 要素がある．XML では数字張した．

の取得と文字の取得の間でプログラム的な処理量が変わらないことから，人間可読的な Name 要素

8.4

を長期継続的に利用する方の要素として推奨する（1）気象分野個別辞書の構造こととし，そのために気象庁 XML においては当気 象 分 野 辞 書 で は，Body 要 素 の 子 要 素 と し

該 Name 要素の出現回数を必須 1 回とし，地理空て TargetArea 要 素，Notice 要 素，Warning 要

間情報で対象地域や地点を表現する場合はコード

素，MeteorologicalInfos 要 素，Comment 要 素，を示すことができないため Code 要素については

OfﬁceInfo 要素，AdditionalInfo 要素をとることが省略可とした．

できる．この中で，TargetArea 要素は対象地域，

内容部の個別要素（気象分野個別辞書）

Notice 要素はお知らせの文章，Comment 要素は文章，OfﬁceInfo 要素は担当部署に関する事項，
AdditionalInfo 要素は電文の個別付加事項という－ 85 －

測

候

時

報

79.5-62012

ように個別の事項について利用する要素である．
一 方，Warning 要 素，MeteorologicalInfos 要 素はいずれも防災気象情報の個別事項を大きな粒度でひとくくりにする要素である．警報事項を示す
Warning 要素の構造はヘッダ部の Information 要素と同じように Item 要素を子要素としてとり，type
属性による排他的な利用についても同様の考え方である．
MeteorologicalInfos 要 素 は 予 報 や 観 測 等 の 警
報事項以外の防災気象情報全般について利用する大きな粒度でひとくくりにする要素で，子要
素としてある時刻の予報事項や観測事項を示す MeteorologicalInfo 要 素 と， 予 報 事 項 や 観 測
事項を時系列で示す TimeSeriesInfo 要素をとる．
MeteorologicalInfo 要素の構造は，ほぼ Warning 要素と同じであるが，予報や観測の時刻を特定する
子要素が追加されている．MeteorologicalInfos 要
素の type 属性は予報・観測の種別を示し，ヘッ
ダ部の Information 要素や Warning 要素のように領域の粒度といった排他的な観点のみで分けられているとはいえないため，必要な気象情報に応じて検索することとなる．TimeSeriesInfo 要素については次項で解説する．
（2）時系列表現
気象分野の防災気象情報では気象要素の観測や��� 1 ������� ��������������� � � �������� � ���� �� �� ����� ��� � ��� ��� �� ������ �������
��� ������� � �������� � �������

������
����������� � � ��������� � ���� ��� �� ������������� ���� ���� ���� ���
�����
�
��
� ����� ��� ������ ������� � ����� ��� ������ � ������� � ����� ��� ���������
������ � ���� � �� �������������� ��� �� � ���� ������� �� �� ��������� ���� ���� � ���� ��� ��
�
�����
�
��
� ����� � ������� ��� ��� ������ �� ������� � ����� ��� ���� ����� ��� ��� ��� ��� ����������� � ����� ��� ������ � ������� � ����� ��� ������������� �� �� �������������� �� ��� �� ����������� ���� ���� � ���� ��� ��
��
�����
�
��
� �������� ������� � ����� ��� �������� � ����� ��� �����

予想を時系列で提供しているものがある．例えば，夜」「明日」「明後日」といった時間順に同じ種類

明日

北の風 後 やや強く 晴れ 昼前 から くもり�� ����� ������ ������� ���
��
��
���
���
���
���
���
���

�������

の予報を並べて時系列で記述している（第 14 図）．
北の風 雨 夜 くもり�������

������

府県天気予報は，次のカテゴリー予報のように「今

今日

�����
��������
�����

����

�������

�������

明後日 北の風 後 東の風 くもり 時々 晴れ�������

府県天気予報の気象庁 XML 形式は，既に部外提供を行っていた旧形式（府県天気予報の独自形�������式）の XML 電文（第 15 図）を参考にした．旧形式の府県天気予報は，天気，風，波のカテゴリ
ー予報の部分は「今日」「明日」「明後日」という

第 14 図順序で，降水確率等は「今夜の 18 時から 24 時」「明日の 0 時から 6 時」「明日の 6 時から 12 時」－ 86 －

����
����
����
����
����
����
����
����
����
����
����
����
����
����
����
����

���
���
����
����
����
����
�����
����
����
����
�����
����
������
��������
��������
�������
������
��������
��������
�������
������
��������
��������
�������
������
��������
��������
�������

府県天気予報かな漢字電文例

測

候

時

報

79.5-6

2012「明日の 12 時から 18 時」「明日の 18 時から 24 時」<?xml version="1.0" encoding="Shift_JIS" ?><report xmlns="http://adess.kishou.go.jp/xml10" lang="ja"><head><title>������(11 ���)</title><dateTime>2012-02-14T02:00:00Z</dateTime><type>��</type><editorialOffice>������</editorialOffice><publishingOffice>���</publishingOffice><additionalInfo><v k="������">����������������</v></additionalInfo></head><body><feature name="�������" isTimeSeries="true"
isSpaceSeries="false"><propertySuffix><property name="�����"><v k="�� 1">m</v><v k="�� 2">m</v><v k="������ 1">m</v><v k="������ 2">m</v></property></propertySuffix><dateTime value="2012-02-14T02:00:00Z"><time><t>PT0H PT13H</t><t>PT13H PT37H</t><t>PT37H PT61H</t></time><location name="���/����"><property name="������"><t>313</t><t>111</t><t>201</t></property><property name="�����"><t><v k="�� 1">�</v><v k="��� 1">�</v><v k="�� 2">���</v><v k="��� 2" /><v k="�� 3" /><v k="�����" /><v k="�������" /><v k="������" /></t><t><v k="�� 1">��</v><v k="��� 1">�� ��</v><v k="�� 2">���</v><v k="��� 2" /><v k="�� 3" /><v k="�����" /><v k="�������" /><v k="������" /></t><t><v k="�� 1">���</v><v k="��� 1">��</v><v k="�� 2">��</v><v k="��� 2" /><v k="�� 3" /><v k="�����" /><v k="�������" /><v k="������" /></t></property><property name="����"><t><v k="�� 1">�</v><v k="��� 1" /><v k="���" /><v k="�� 2" /><v k="��� 2" /><v k="�����" /><v k="������ 1" /><v k="������� 1" /><v k="�������" /><v k="������ 2" /><v k="������� 2" /></t>

第 15 図の順序でという具合に，t 要素の順序を用いて時系列的表現を記述していた．
府県天気予報の気象庁 XML 形式では，旧形式の時系列表現を準用し，更に要素と日時の対応を明確化するために TimeDeﬁne 要素と timeId 属性
による時系列表現を検討した．TimeDeﬁne 要素は対象時間を定義する要素で，天気などの気象要素について時間軸に沿って列挙されている値について，timeId 属性を介して対象時間と結びつける方法である（第 16 図）．
気象要素の値を格納する部分について，その後の議論では，時間の参照だけでない可能性がある
ので属性名を“timeId”ではなく“refID”にするなどの変更が加えられ，気象庁 XML の仕様に採用されている．
気象情報は時系列で表現できるものが多いた
め，この表現方法は他の電文においても有効に活用されている．また，まだ時系列的表現は他の個別辞書にて利用されていないが，新たに利用する
場合には，本構造に準ずることが望ましい．

<TimeDefine><Time timeId="1"><TargetDateTime>2008-06-25T08:00:00+09:00</TargetDateTime><TargetDuration>PT7H</TargetDuration><Name>��</Name></Time><Time timeId="2"><TargetDateTime>2008-06-25T15:00:00+09:00</TargetDateTime><TargetDuration>PT24H</TargetDuration><Name>��</Name></Time><Time timeId="3"><TargetDateTime>2008-06-26T15:00:00+09:00</TargetDateTime><TargetDuration>PT24H</TargetDuration><Name>���</Name></Time></TimeDefine><Item><Area><Name>����</Name><Code>4410</Code></Area><WeatherSentence><Value timeId="1">��� ���� ��� �</Value><Value timeId="2">� �� ���</Value><Value timeId="3">��� �� �</Value></WeatherSentence></Item>

第 16 図 旧形式府県天気予報 XML を参考にした気象庁 XML の時系列表現案

旧形式府県天気予報 XML の例－ 87 －

測

候

時

報

79.5-6（3）気象予報情報の時間的変化の表現
気象現象には時間とともに状態が変化するも2012

合わせて表す．
・地域天気は，「地域名，時間指定，地域天気のがある．例えば，府県天気予報では，「くもりの種類」の順で表現する．

夜遅く雨」や「北東の風 後 北の風」のように気このような気象状況が変化する状況の表記につ象要素の時間的変化について表現する必要があ

いても，気象分野辞書を用いる電文で共通化する

る．「地方天気分布予報，府県天気予報及び地域必要が出てきた．

時系列予報の実施細目について（通知）」（平成「変化前」，「変化後」の記載がある要素の記述

22.5.27 気業第 64 号．以下本項において「通知」

方法について第 8 表の案を示し検討を行った．案という．）に，例えば，「天気」について次のよう

1，案 2，案 3，案 5 については，「変化前」，「変化後」に定められている．

などの変化傾向を属性や要素のとりうる値として

・府県天気予報の表現は，「基本天気 + 地域天気」
として表す．

示す方法をとった．一方，案 4 ではより通知の定
めていることに従うよう，変化前若しくは卓越し・基本天気は，予報区内で卓越天気（ある時間た現象を示すものとして「Primary」を気象要素

帯で予報区内の多数を占める天気）の経過を名の前に付加した要素を，変化後を示すものとし簡潔に表す．基本天気は「晴れ」，「くもり」，て「Change」を気象要素名の前に付加した要素「雨」，「雪」，「雨か雪」，「雪か雨」の天気予を用いる方法を検討した．具体的には，「くもり報用語と現象が発生する期間を示す「一時」，

夜遅く雨」の「くもり」のように，天気における「時々」，「後」や時間細分の用語等とを組み

基本天気の最初の天気予報用語は PrimaryWeather���������������������������
第 8 表 「変化前」「変化後」の記載がある要素の記述方法

���<Content><WindDirection><Type>�������</Type><Value unit="�����">��</Value></WindDirection><WindDirection><Type>�������</Type><Value unit="�����">�</Value></WindDirection></Content>���<Content type="�������"><WindDirection unit="�����">��</WindDirection></Content><Content type="�������"><WindDirection unit="�����">�</WindDirection></Content>

���

���

���

<Content><Type>�������</Type><WindDirection unit="�����">��</WindDirection></Content><Content><Type>�������</Type><WindDirection unit="�����">�</WindDirection></Content><Content><PrimaryWindDirection><KanjiBase8WindDirection>��</KanjiBase8WindDirection></PrimaryWindDirection><ChangeWindDirection><KanjiBase8WindDirection>�</KanjiBase8WindDirection></ChangeWindDirection></Content><WindDirection target=”�������” unit=”�����”>��</WindDirection><WindDirection target=”�������” unit=”�����”>�</WindDirection>－ 88 －

測

候

時

報

79.5-6

2012

要素で，「くもり夜遅く雨」の「夜遅く雨」のよ

この案に対して，Complex や Simple を冠した

うに，現象が発生する期間を示す「夜遅く」と組

要素名は気象要素ではなく技術的なもので要素み合わされて使われる天気予報用語の「雨」は名の原則から外れることとなるため導入はやめ

ChangeWeather 要素で表現するというものである．

るべき，要素名は気象要素を示したものにすべ「くもり夜遅く雨」の案 4 での表記を次に示す．

き，Primary 要素や Change 要素については，航空
気象通報式の変化傾向を示す用語である BECMG<Content>（Becoming）や TEMPO（Temporary）を利用して<PrimaryWeather>

はどうかとの提案があり，結果として，卓越や<BaseWeather> くもり </BaseWeather>

変化前には Base 要素，変化後は Becoming 要素，</PrimaryWeather>

一時的な現象には Temporary 要素を利用するとい<ChangeWeather>

った次の修正を行った．

<BaseWeather> 夜遅く 雨 </BaseWeather>

・同一の要素は ElementAPart 要素でくくる．

</ChangeWeather>

・変化状況は，卓越若しくは変化前を Base 要</Content>素， 断 続 現 象 を Temporary 要 素， 変 化 後 を
Becoming 要素でくくって表現する．

XML コンソーシアムとの議論を受けて，基本・区域の一部の状況を表現する場合は，Base 要

要素の構造は案 5 を基本として採用し，「変化前」，

素，Temporary 要素，Becoming 要素の中では「変化後」の記載がある要素の記述方法は基本要

Local 要素でくくる．

素の要素名や属性に「変化前」や「変化後」の記・一部領域で領域全体（Item 要素下の Area 要

述をするのではなく，案 4 の構造の考え方をする

素で示される領域）と同じ予報表現をする必という方向性が示されたことから，再度次のよう要がある場合は ElementAPart 要素の子要素に気象要素の記述方法を検討したとして SubArea 要素でくくる．

・ 変 化 前， 変 化 後 を 表 す 項 目 は そ れ ぞ れPrimary 要素，Change 要素でくくる．

この修正を反映した「くもり夜遅く雨」の記述
は次のようになる．

・地域を分けて記載する場合は Local 要素でく<WeatherPart>

くる．
・Primary 要素，Change 要素，Local 要素を用い<Sentence> くもり 夜遅く 雨 </Sentence>

る項目は“Complex[ 要素名 ]”要素で，用い<Base>

ない項目は“Simple[ 要素名 ]”要素でくくる．

<Weather> くもり </Weather>

この案で「くもり夜遅く雨」を表現すると次の</Base><Becoming>

ようになる．

<TimeModiﬁer> 夜遅く </TimeModiﬁer><ComplexWeather><Weather> 雨 </Weather><Sentence> くもり 夜遅く 雨 </Sentence></Becoming><Primary></WeatherPart><Weather> くもり </Weather></Primary>（4）辞書策定における全体調整<Change>

当初，気象分野個別辞書の作成は予報課所掌の<TimeModiﬁer> 夜遅く </TimeModiﬁer>

電文における共通化を中心に行っていたが，そ<Weather> 雨 </Weather>の後，予報課以外の所掌の電文との調整を行っ</Change>

た．生物季節観測電文との調整では，平年差，</ComplexWeather>

昨 年 差 に つ い て，IndividualAddition 要 素（ 後 に－ 89 －

測

候

時

報

79.5-62012

AdditionalInfo に名称を変える）の子要素に生物記述されていた（第 17 図）．一方，同じ時期に季節観測の独自要素を追加する方法とした．ま

府県天気予報と府県週間天気予報の構造を統一

た，Item 要素の対象地域は Area 要素で定義されできないかを検討しており，TimeSeriesInfo 要素ていたが，気象分野個別辞書に定義されていたの後に MeteorologicalInfos 要素を記述したいとい

Area 要素は，面的な領域の表記には適していた

う要望があった．気象庁 XML は要素の出現順序

が観測所のような様々な属性情報のある地点の表は固定という方針であることから，1 か月予報

記には適していなかったため，Area 要素のかわ等季節予報の要素の順序との調整が必要になっりに観測所の情報を記述する Station 要素を Item

た．また，電文の内容をいくつかの部分の集合と要素の子要素に追加するなどの調整を行った．紫して分けて記述する場合には，MeteorologicalInfo

外線情報電文では，この時点で環境分野個別辞書

要 素 や TimeSeriesInfo 要 素 を 複 数 使 っ て 記 述 すとして検討されていたが，気象分野個別辞書とのる こ と が で き る が，MeteorologicalInfo 要 素 は共通化も視野に入れるため，同じ型でありながらMeteorologicalInfos 要素の子要素のため問題はな

Observation 要素と Forecast 要素に分けて観測と予

く と も，TimeSeriesInfo 要 素 は Body 要 素 の 直 接報を区別していたものを，同じ気象情報という意の子要素であるため，複数の TimeSeriesInfo 要素

味の MeteorologicalInfos 要素に統一するなど，比を記述すると Body 要素に子要素が増えてしまう較的大きな辞書の変更を行った．

ことが気がかりとなっていた．そこで，構造の大その後，季節予報電文と気象分野個別要素のきな変更となってしまうが，TimeSeriesInfo 要素調整を行った．季節予報の例として，1 か月予報

を MeteorologicalInfos 要素の子要素へと変更する

におけるかな漢字電文では，特に注意を要することとした．MeteorologicalInfos 要素を複数利用

事項，気象要素の予測，次回の発表予定等の順

すれば，時系列的な記述とある時刻の気象情報ので記述されており，当初の XML 電文でもかな漢

記述の順序を XML 化対象電文と同様の順序で記

字電文とほぼ同じ順序で，「特に注意を要する事述できる．

項」はヘッダ部に，「週ごとの気温経過」を除く

このようにして，気象分野の電文について，関予測については内容部の MeteorologicalInfos 要素

係部課と協力しながら，全ての気象分野の電文がに，「週ごとの気温経過」は TimeSeriesInfo 要素共通化された構造で記述できるように調整した．

に，「次回発表予定等」は AdditionalInfo 要素に－ 90 －

測

候

時

報

<?xml version="1.0" encoding="utf-8" ?><Report xmlns="http://xml.kishou.go.jp/jmaxml/"
xmlns:jmx="http://xml.kishou.go.jp/jmaxml/"><Control><Title>�������</Title><DateTime>2008-03-07T05:25:00Z</DateTime><Type>��</Type><EditorialOffice>�������</EditorialOffice><PublishingOffice>�������</PublishingOffice></Control><Head xmlns="http://xml.kishou.go.jp/jmaxml/informationBasis/"><Title>����������</Title><ReportDateTime>2008-03-07T14:30:00+09:00</ReportDateTime>79.5-6

2012<TimeDefine timeId="2"><DateTime>2008-03-15T00:00:00+09:00</DateTime><Duration>P7D</Duration></TimeDefine><TimeDefine timeId="3"><DateTime>2008-03-22T00:00:00+09:00</DateTime><Duration>P14D</Duration></TimeDefine></TimeDefines><Item><Kind><Name>����</Name><Property><Type>�����������������</Type><ProbabilityValuesPart><jmx_eb:ProbabilityValues refID="1"
kind="��"><TargetDateTime>2008-03-08T00:00:00+09:00</TargetDateTime><jmx_eb:ProbabilityOfBelowNormal unit="%"<TargetDuration>P1M</TargetDuration>>10</jmx_eb:ProbabilityOfBelowNormal><ID></ID><jmx_eb:ProbabilityOfNormal
unit="%"<InfoStatus>��</InfoStatus>>10</jmx_eb:ProbabilityOfNormal><Serial></Serial><jmx_eb:ProbabilityOfAboveNormal unit="%"<Condition>��</Condition>>80</jmx_eb:ProbabilityOfAboveNormal><InfoKind>����</InfoKind></jmx_eb:ProbabilityValues><InfoKindVersion>1.0</InfoKindVersion><jmx_eb:ProbabilityValues refID="2" kind="��"><Headline><jmx_eb:ProbabilityOfBelowNormal unit="%"<Text>��������������������������
>20</jmx_eb:ProbabilityOfBelowNormal>������������</Text><jmx_eb:ProbabilityOfNormal
unit="%"</Headline>>30</jmx_eb:ProbabilityOfNormal></Head><jmx_eb:ProbabilityOfAboveNormal unit="%"<Body xmlns="http://xml.kishou.go.jp/jmaxml/body/meteorology/">50</jmx_eb:ProbabilityOfAboveNormal></jmx_eb:ProbabilityValues>
xmlns:jmx_eb="http://xml.kishou.go.jp/jmaxml/elementBasis/"><jmx_eb:ProbabilityValues refID="3" kind="��"><TargetArea codeType="�������"><Name>�����</Name><jmx_eb:ProbabilityOfBelowNormal unit="%"<Code>11</Code>>20</jmx_eb:ProbabilityOfBelowNormal></TargetArea><jmx_eb:ProbabilityOfNormal
unit="%"<Notice>���� �����������</Notice>>30</jmx_eb:ProbabilityOfNormal><MeteorologicalInfos type="�����"><jmx_eb:ProbabilityOfAboveNormal unit="%"<MeteorologicalInfo>>50</jmx_eb:ProbabilityOfAboveNormal><DateTime significant="yyyy-mm-dd"</jmx_eb:ProbabilityValues></ProbabilityValuesPart>>2008-03-08T00:00:00+09:00</DateTime></Property><Duration>P1M</Duration></Kind><Name>������</Name><Area codeType="�������"><Item><Name>�����</Name><Kind><Code>11</Code><Name>����</Name></Area><Property></Item><Type>����������������������
</TimeSeriesInfo>��������������</Type><AdditionalInfo><ClimateFeaturePart><ClimateForecastAddition><jmx_eb:ClimateFeature><NextForecastSchedule target="�����"><jmx_eb:GeneralSituationText>������<Text>����� ������ ��������</Text>
���������������������������������
�������������������
<DateTime>2008-03-14T14:30:00+09:00</DateTime></jmx_eb:GeneralSituationText></NextForecastSchedule><jmx_eb:SignificantCliamteElement kind="<NextForecastSchedule target="�����">��"><Text>�������� ���</Text><jmx_eb:Text>��������������
<DateTime>2008-03-25T14:00:00+09:00</DateTime>�����</jmx_eb:Text></NextForecastSchedule><jmx_eb:ProbabilityOfAboveNormal<NoticeOfSchedule/>
unit="%">60</jmx_eb:ProbabilityOfAboveNormal><AdditionalNotice/></jmx_eb:SignificantCliamteElement></ClimateForecastAddition></jmx_eb:ClimateFeature></AdditionalInfo></ClimateFeaturePart></Body></Property></Report></Kind><Area codeType="�������"><Name>�������</Name><Code>14</Code></Area></Item></MeteorologicalInfo></MeteorologicalInfos><TimeSeriesInfo type="�������"><TimeDefines><TimeDefine timeId="1"><DateTime>2008-03-08T00:00:00+09:00</DateTime><Duration>P7D</Duration></TimeDefine>

第 17 図当初作成していた季節予報の気象庁 XML 案－ 91 －

測

8.5

候

時

報

79.5-62012

内容部の個別要素（地震・津波分野個別

来の津波注警報電文の第 1 報に用いられるコード

辞書）

電文では震源要素は記載されなかったが，津波注（1）地震津波情報のコード電文と運用の課題

警報発表前にはおおむね震度速報などが発表され

地震火山分野では，平成 11 年 3 月から開始さるため，地震津波情報の利用者からすると他の情れた量的津波予報導入に伴う津波予報区の細分報を用いることで震源に近い領域がおおむね把握

化，平成 8 年以降からの震度観測点の増加，地方できていた．しかし，この津波注警報発表の迅速公共団体や関係機関の震度観測点の取り込みなど

化では，事前情報が何もない中でいきなり津波注に伴う情報発表量の大幅な増加に適切に対応する警報が発表されるため，テロップなどの誤発表をため，いわゆる人間可読式のかな漢字電文だけで行わないよう，震源の位置を津波注警報に加えてなく，機械可読式の電文をコード電文として作成

ほしいという強い要望が報道機関から行われた．

し，平成 7 年 4 月から運用を行ってきた．

しかし，これにこたえて従前からの電文に震源要コード電文は各情報について定型のフォーマッ

素を追加すると，津波注警報のコード電文を利用トを作り，各要素については英数字や記号を用いしている全ユーザに対して改修作業が必要になって内容を示すものである．例えば，津波注意報・てしまうため，従前の電文内容には変更を加えず，警報（以下「津波注警報」という．）の本文を示

震源要素を付加した津波注警報電文（データ種類

す接頭辞は“T FR”であり，北海道太平洋沿岸

コード：ツナミヨホウ 6）を新たに作成し，配信

中部の津波予報区は“101”のような 3 桁の数字することで要望に対応することとした．これによで示される，というものである．

り，津波注警報電文のデータ種類コードは 6 種類

コード電文は XML 電文と同様に，定められたとなり，このように電文数を増加させると電文作要素を取得する際には便利であり，かつかな漢字

成及び配信にタイムラグが生じるおそれがあるこ

電文と比べて伝送量が小さく抑えられるため，規とや，またどの機関にどの電文を配信すべきか，

模の大きな地震や津波など大量の情報を一度に処という配信管理の負荷が上昇することになった．

理する上では便利である．しかし，その反面，震源要素の緯度経度の桁数は 0.1 度単位でしか表記（2）XML 形式への検討できないといったように定型のフォーマットから

地震火山部では，緊急地震速報の技術開発及び外れる表現をとることはできない．また，情報内

実用化検討に際して，一部関係機関から XML 形

容の変更や追加などが発生する場合には，コード式による情報配信の対応を強く要請されたことも電文のフォーマット形式も変更することになるあり，平成 14 年頃から XML 形式の検討を行っが，XML 電文とは異なり同情報を利用する全ユてきた．平成 16 年 7 月 8 日から 9 日に掛けて，ーザに対してソフト改修が必要となってしまうと本庁内の緊急地震速報及び地震津波情報の担当者

いう問題点があった．コード電文では，情報内容

が半ば自主的に集まり「緊急地震速報の XML 化の変更に際して，全ユーザに大幅な処理改修が発に関する打ち合わせ」を行い，XML フォーマッ

生しないように，予備として定義していたフラグトの検討を行った．同打ち合わせでは，緊急地震の値に意味を持たせることや，ヘッダを別にした

速報の XML フォーマットを検討するのが主目的

新規電文を準備して追加変更したフォーマットをであったが，それだけでなく地震津波情報や地震提供することなどの回避策を用いて運用を行って火山部の全情報まで拡張しても耐えられるようきた．

なフォーマットの策定について，平成 15（2003）

例としては，津波注警報発表の迅速化を平成

年十勝沖地震で発表された地震津波情報を素材と18 年 10 月 2 日より開始した際のデータ種類コーして様々な検討がなされた．現在の XML 形式にド追加が挙げられる．この迅速化は，緊急地震速

よる地震津波情報の内容部の構造は，おおむね同報を活用して地震発生後最速 2 分程度で津波注警

打ち合わせで行われた議論の結果を反映したもの

報を発表できるようにするというものである．従である．

－ 92 －

測

候

時

報

79.5-6

2012（3）XML 形式による地震津波情報の特徴

る．津波注警報や津波情報は震源要素が途中アから変更されることになり，それまで発表さ情報の一連番号による識別管理

かな漢字電文及びコード電文の利用者からは，れた地震情報との紐付けができなくなる．

従来から「発表される情報がどの地震に対応してかな漢字電文及びコード電文では地震を一意にいるものか分からないので対処してほしい」とい識別する情報が盛り込まれていないために，利用う意見・要望が度々行われていた．有感地震がほ

者が地震を識別する場合には地震発現時（地震がとんど発生しないような通常時においては，地震検知された時刻），震源位置やマグニチュードな発生の順番に各種地震情報が発表されるため，情どで識別することができると個別に説明を行って報と地震の整合性を判別するのは容易である．しいた．しかし，
上記の識別処理を行ったとしても，かし，例えば平成 23（2011）年東北地方太平洋

地震発現時は 1 分単位でしか表記されないため，

沖地震発生後などのように大小様々な規模の余震

似たような場所で 1 分以内に 2 つ以上有感地震がや他の地域の地震が多発するような状況下では，発生すると地震の識別ができなくなるという点で今受信した地震津波情報はどの地震に対するもの問題がある．また，上記の識別は利用者ソフトウなのかを判別することは容易でない．特に，下記ェアによるものとなるため，利用者が個々に識別のような状況下においては，情報と対応する地震を行うよりも情報発信者である気象庁が識別を行の判別が困難になると考えられる．

った上で情報発信を行うことが望ましい．以上の・余震の地震情報を発表した後に規模の大きなような問題があったため，最近作成された新しい地震（本震）の地震情報の更新を行うような，情報である緊急地震速報では，地震発現時刻（秒発表する地震情報の震源要素が時間順に並ば単位）から生成される地震 ID と呼ばれるデータ

ない場合．

を付して地震イベントの識別に使用していた．気・震度 3 程度の地震が発生してその 2,3 分後に象庁 XML においても，EventID 要素にこの地震

例えば震度 5 弱以上の規模の大きな地震が発

ID を付して全地震津波情報に適用し，上記の課

生するような場合．この時，自動処理で生成

題解決を図った．

される震度速報は両方の地震で発表される

しかし，自動処理で生成される緊急地震速報及が，その後の地震情報は情報伝達の混乱を避び震度速報では，例えば本来は複数個に分離されける目的で，規模の大きな地震だけしか発表

るべき地震を一つに統合することや，若しくはそされないことがある．

の逆に一つの地震を複数個に分離して処理するこ・津波注警報，津波情報が発表される場合．地ともある．人手を介して作成される地震津波情報

震情報の発表はおおむね地震発生後 30 分程の EventID 要素は一致するように処理を行ってい

度以内で一旦終了するが，津波注警報，情報るが，システムで自動的に作成され，発表までのの発表は短くても 30 分から 1 時間程度は掛

時間の猶予が短い緊急地震速報や震度速報と地かるため，いつまでも過去の地震情報の震源

震 ID が一致しないことがありうる．また，地震要素が情報に入ってくる．また，規模の大き津波情報の処理は東京，大阪の 2 中枢で独立並行な余震や別領域で発生する規模の大きな地震

して処理を行っている．この 2 中枢では同じ地震の発生により，津波注警報がグレードアップ

波形を用いてほぼ同じ処理を行っているが，地震し，また該当予報区が拡大することも考えら

波形の伝送やシステムの処理サイクルなどの数十れる．このような場合は津波を発生させる要

ミリ秒や数百ミリ秒といった僅かな差異が秒単位因となる地震が複数個存在することになる．

で生成される地震 ID に影響を及ぼすことがあり，・地震津波情報では即時的に決定した震源要素

東京と大阪で同じ地震を処理しても地震 ID が異を速報値として用いているが，規模の大きななる場合が少なからず存在する．現状で，地震地震などの場合は地震発生後数時間程度で震ID の一意性について上記のような問題点はあり，源要素を精査して暫定値に修正することがあシステム改修だけでなかなか解決できる問題では－ 93 －

測

候

時

報

79.5-62012

ないものの，より一意性が確保できるようにする

津波情報や震度情報では，多数の予報区や観測ために今後も処理を検討する必要があるだろう．

点のデータが記載されるため，データ量が多くなりがちである．検索性を高めるなどの利便性を向イ

種別

例えば，震源・震度に関する情報では，震源要上させるためにも，津波や震度において構造化を積極的に取り入れている．

素（震源の位置，マグニチュードなど），震度（都また，津波注警報等で表現される予報値と観測

道府県，細分区域，市町村，データ未入電と予想値については，例えば予測震度と観測震度や予想される市町村），付加文（地震，津波，震度，防される津波の高さと最大波の高さなどといったよ

災に関する事項など）で構成されている．各情報

うにほぼ同じ値や形式をとることから，予報値とはこのような様々な要素を集められて作成され観測結果を表現する観測値の構造を同じ表現形式

る．しかし，地震に関する情報の要素として，例にすることで，比較を容易に行うことができる．

えば震源要素，津波，震度などと大きな項目で区分することができる．このように，地震津波情報

エ

は独立性のある情報区分（これを種別と呼んでい地震津波情報では，ヘッダ部と内容部で予報区る）にまとめ，これらを組み合わせることで情報や細分区域を表現する方法が異なる．ヘッダ部でを作成している．内容部直下の要素が主な種別を

は，予報区や細分区域が注警報階級や震度順に記

意味しており，上記で挙げた Tsunami 要素（津波），

述されており，内容部では，その逆に都道府県やIntensity 要素（震度），Earthquake 要素（震源要素），

予報区，細分区域などの地域別に記述されている．

Comments 要素（付加文）のほかに，単独で用い

気象警報・注意報と異なり，地震津波情報は原られることが多い EarthquakeCount 要素（地震回則として全国の津波や震度に関わる要素が含まれ数），NextAdvisory 要素（次回の情報発表時刻），ており，利用者の利用用途も様々であると思われ

社会的影響度の大きな Naming 要素（命名）など

るが，上記のようにヘッダ部と内容部の構造の記を配置している．

述方法が異なるため，用途に応じて使い分けるこ

ヘッダ部と内容部の活用についてとが可能となっている．例えば中央省庁や民放キ
ウ

構造化

ー局など全国の状況が必要な利用者にとっては，

コード電文では，震度の情報部分は細分区域のヘッダ部を見れば細かな予報区単位ではないもの

震度，市町村の震度，観測点の震度をそれぞれ列のどの地域にどのような津波注警報が発表されて挙する形式となっている．この形式では，全国のいるかを大まかに把握することができる．一方で，震度分布を知ることはできるが，例えば茨城県南各都道府県や市区町村単位の報道機関，防災機関

部の各観測点の震度分布やつくば市など特定の市などが自らの当該地域の状況を把握する場合は，区町村の震度を検索する，といったような，細分内容部の該当する要素配下を取得すれば細かな情区域や市区町村，各観測点の連携を必要とする検報まで含めて必要な要素全てを取得することがで索を電文だけで行うことはできない．コード電文

きる．

で上記の検索を可能にするためには，関係する細このように考えると，ヘッダ部は全国を俯瞰的分区域，市区町村，観測点の各コードの関連性をに把握するために利用し，内容部は都道府県や予全て把握しておく必要がある．

報区単位などで細部まで含めた内容を抽出するた

しかし，XML 形式では，ツリー状に表記する
構造化テキストを利用することができる．震度デめに用いるのが望ましい活用法であると考えられる．

ータを細分区域，市区町村，観測点とツリー状に構造化したため，各コード表の関連性を知らなくオとも，XSLT で簡単な記述を行うだけで上記の検近年のネットワークの帯域の増大，低価格化は索は実現することができる．

電文種別の統合

目覚ましいものがあるが，コード電文の運用をは－ 94 －

測

候

時

報

79.5-62012

じめた頃は十分な帯域を確保することが困難であ

修正情報の要素を用意することで更新状況が把握

り，大量のデータが入った電文を配信すると相応できるようにした．これにより，以前に発表されの大きな遅延が発生する危険性があった．一方でた情報を取得できなかったとしても，修正情報を

地震津波情報についてはその情報の性質から常に取得することが可能となった．

緊急性が求められるため，情報内容によっては似

この修正情報は，
震度観測点以外にも都道府県，

通った内容の情報を分割してデータ量を削減する

細分区域，市町村の最大震度や津波の高さについなどの工夫を行っていた．例えば，震源・震度にても記載できるようにした．

関する情報と各地の震度に関する情報（前者は震度 3 以上が観測された際に観測された地域を示（4）個別要素の説明

し，後者は各震度観測点の震度を全て示す）や津

第（3）項イに記載したとおり，内容部の要素

波到達予想時刻・予想される津波の高さに関するは種別ごとに独立している．各種の注警報，情報

情報と各地の満潮時刻・津波到達予想時刻に関すはこれらの種別を組み合わせることで作成される情報（前者は津波注警報と各予報区の津波の高る．

さ及び各予報区への到達予想時刻を示し，後者はア

津波注警報と予報区及び各潮位観測点への到達予

緊急地震速報で震度の予測を行い，その後の震震度（Intensity）

度速報及び地震情報において，観測された震度

想時刻と満潮時刻を示す）がそうである．
気象庁 XML では，データ伝送の環境は十分整の値を発表するために主に用いられる．Intensityっているという前提のもと，これらの重複した情

要 素 内 で は， ま ず Forecast 要 素（ 予 報， 警 報 ）報を統合して一つの情報として整理した．

と Observation 要素（観測）に区別されている．
Forecast 要素と Observation 要素の構造及び用いらカ

れるコード表は同一としている．

修正情報

規模の大きな地震が発生すると，震源近傍の自Forecast 要素は緊急地震速報で使用されること

治体などの震度観測点においては回線輻輳等の影から現在は地方，都道府県，細分区域までの分解

響により，観測点から気象庁への震度データの伝能しか持たない．ただし，気象庁 XML の仕様上送に相当の時間を要することがある．そのため，は市区町村や観測点まで持っているため，将来的地震情報を発表した後に，より大きな震度が入電に市区町村単位で予測震度を発表するような場合することとなり，震度観測点の更新という形で地でも，仕様を大きく変更する必要がない．一方，

震情報を複数回発表することがある．コード電文

Observation 要素は地震情報で各観測点の震度までは，情報として分かりやすさや取得の容易さをで発表するため，都道府県，細分区域，市区町村，

別にすれば情報として必要な要素はおおむね網羅

観測点というようにより細分化された構造を持っされていたが，観測値の追加や修正といった修正ており，これらはツリー構造で表記されている．

情報については表現されていなかった．情報の受そのため，通常は下位の領域のデータは上位の領け手側からすると，修正情報がないためにどの観域で括られる要素の中に全て記述されている．

測点が追加されたか，上方又は下方に修正された

ただし，飛び地などで同一市区町村であってもかを把握するためには，前に発表された情報と比

複数の細分区域にまたがるような場合は例外とな較を行う必要がある．しかし，本項アで示したよる．例えば，長崎県佐世保市は長崎県南西部と長うな問題もあるため，前に発表された情報との比崎県五島列島の 2 つの細分区域にそれぞれの佐世

較を情報の受け手側が行うことは大変困難であっ保市の震度が分かれて記述されることになる．
規模の大きな地震が発生して震源近傍の観測点

た．
上記のような事情から，震度観測点の追加などの震度の入電が遅れると，当該市区町村及び観測を示す情報付加はかねてより防災機関，報道機関

点は「震度 5 弱以上と推定されるが入電していな等から強く要望されていた．気象庁 XML では，い」（いわゆる震度 5 弱以上未入電）という扱い－ 95 －

測

候

時

報

79.5-62012になる．従来のコード電文では，市区町村の観測ては“不明”や“（震源の深さが）600km より深い”

最大震度が 4 であっても，震度が入電していないなどとなることもある．このような不定形の表現

震度観測点が「震度 5 弱以上未入電」と判定されについては condition 属性値で表現している．

ると，最大震度「震度 5 弱以上未入電」という値

震源の位置を示す震央地名については，津波注のカテゴリーに当該市区町村が記述される．気象

警報や地震情報で用いられる通常の震央地名以外

庁 XML でもこの点はコード電文と同じ運用となに緊急地震速報（警報）で用いられる短縮表記さるが，震度情報は都道府県や細分区域等のツリーれた震央地名（例えば北海道道東），海外で発生構造となることから，当該市区町村の最大震度にした地震の詳細な震央地名（例えば「詳しい震源「震度 5 弱以上未入電」の値が記述される．

の位置はケルマデック諸島です。」）の 3 種類が運用されている．これらの 3 つの震央地名は一つのイ

津波（Tsunami）

震源位置に対して複数の震央地名を返すものであ

津波注警報・津波予報で各予報区の区分（カテるため，統合して一つのコード体系に整理するこゴリー）を決定し，各種津波情報で予想される津とは困難である．そのため，従来通り 3 つの震央

波の高さ，到達予想時刻，各種潮位観測点や津波

地名に要素をそれぞれあてて使い分けしている．

計の観測値を示している．
津波は震度と異なり，GPS 波浪計や沖合に整エ

付加文（Comments）

備された海底津波計の観測値を元に該当する沿岸

付加文は発表した注警報，情報に付属して注意部で予測される津波の高さを情報として発表する

喚起や補足を行うために用いられ，地震津波情報

ことがある（例えば，気仙沼広田湾沖などの名称）．

では頻度の高い表現を定型付加文と呼び，コード

このような名称に該当する沿岸部は津波予報区の化して運用してきた．気象庁 XML では，これま

ごく一部にとどまること，若しくは複数の津波予で用いられてきた付加文を整理し，注警報のため

報区にまたがるなど，津波予報区とは直接の関連の付加文要素，予報のための付加文要素，観測値がないことが多い．そのため，予報区を示す要素のための付加文要素，用途限定しない付加文要素，を用いた構造化表記とせずに別の要素で明瞭に分不定形な付加文要素と区分することとした．

離することにした．以上より，津波は Forecast 要

なお，かな漢字電文では表示位置などの工夫が素（予報，注警報，予想される津波の高さ，第一なされてきたが，気象庁 XML は従来のコード電波到達予想時刻），Estimation 要素（GPS 波浪計

文同様に視覚的な表示情報は含んでいない．そのや沖合津波計などによる推定値），Observation 要

ため，望ましい利用方法として表示例を示すこと

素（第一波到達時刻，最大波到達時刻，津波の高が必要と思われる．

さなどの津波の各種観測値）の 3 つに区別される．
また，震度と同様，Forecast 要素と Observation 要

オ

素の構造及び用いられるコード表は同一である．

東海地震に関連する情報に特化するための要素

津波についての細分化単位は全国を 66 に区分

東海地震情報（Tokai）

を設けている．

した津波予報区のみである．津波予報区は例えば
東京湾内湾のように複数の都道府県境にまたがるカこともあるため，震度のような枝の多いツリー構

地震が多発するなどして，地震情報の発表が追造ではない．

地震回数（EarthquakeCount）

いつかないような場合，毎時間若しくは数時間おきに有感地震や無感地震の回数を情報として発表

ウ

震源（Earthquake）

震源位置（緯度，経度，深さ）やマグニチュー

することがある．EarthquakeCount 要素で時間ごとの地震回数を記載できるようにする．

ド，震央地名などを記載している．震源位置やマ
グニチュードは通常，数値が入るが，場合によっ－ 96 －

測

キ

候

時

報

余震確率（Aftershock）

79.5-62012

噴火警報・予報と火山の状況に関する解説情報

規模の大きな地震が発生した後に余震が多発しについては，従来の電文においてコード部を付けて，その発生様式がいわゆる「本震－余震型」でて発表していたが，気象庁 XML としての検討に推移するような場合には余震確率を発表すること

あたっては，このコード部の内容を整理しつつ，がある．余震確率の確率表現や期間などを定型と

前述のような問題点を対処できるようにした．まして要素化し，情報文本文や解説，補足などをテた，火山現象に関する海上警報については，船舶

キスト文で記述できるようにしている．

向けの送信という制限からその電文の大きさが限定される特殊な性質を有することに留意が必要で

ク

その他の種別あるが，伝達するべき内容は警戒事項等が中心で重要度が高く，データの抜き出しができた方が良いと思われる要素について，種別を作成していあることから，発表する要素としては噴火警報・予報と共通化を目指した．

る．「平成 23（2011）年東北地方太平洋沖地震」

噴火に関する火山観測報については，観測したなどのような命名（Naming 要素）や次回の情報

内容を端的に伝えるという他の火山関連電文とは発表予定時刻（NextAdvisory 要素）などがある．

やや異なる性質を有する．ただ，旧形式電文においても，本文中ではあるものの，噴煙高度等主な

8．6

内容部の個別要素（火山分野個別辞書）

観測項目について項目別に記述していたことか（1）従来の火山関連電文の問題点とその対応方針

ら，これらの項目を主な要素としつつ，他の気象

平成 19 年 12 月から噴火警報・予報及び噴火警

観測報と整合をとりながら，将来的に追加される

戒レベルの運用が始まったが，これらの旧形式電可能性のある項目も考慮して，その必要とする要文における対応については，準備期間が短かった

素を検討した．

こともあり，噴火警戒レベルについてコード部になお，火山関連電文において，主たる防災気象

組み込んだ点を除き，従来の火山情報の形式を踏要素については，ヘッダ部と内容部の両方に記述

襲することとなった．このため，警戒事項や予報することとした．

区としての対象市町村は本文中に記述することとなり，これら警戒事項や対象市町村をシステムで（2）火山関連電文における個々の要素について

自動化処理として読み取らせるには本文中の文字

火山関連電文における管理部やヘッダ部の特徴

列解析を行う必要があった．また，噴火に関するについては，第 8.2 節においてまとめている．火

火山観測報や火山現象に関する海上警報・予報の山分野個別辞書における個々の要素の特徴につい

電文についてもコード部がなかったことから，自ては，第 9 表にまとめる．

動化処理には同様の対応を行う必要があった．このことから，火山関連電文の気象庁 XML 対応にあたっては，これらの問題点を踏まえた上での仕様策定を目指した．

－ 97 －

測

第9表

候

時

報

79.5-62012

火山分野個別辞書の個々の要素の特徴����������������

�������������������������������������������
���������������������������������
���������������������
��������������������������������
���������������������������������
����������������������
����������

��������������������������������������
����������������������
���������������������������

����������
�����������������

��������������������������������
�������

�������������������

��������������������������������
����������������������������������
������������������������������
���������������������������������������
��������������������������������
�������������

�������������������
�������������������������

����������������������������
���������������������������������

��������������������

��������������������������������
������������������������������

��������������������������������
�������������������������
��������������������������������
�������������������

����������������������

���������������������������������
��������������������

������������

�����������������������������

�����������������
����������������

��������������������������������
���������������������
��������������������������������
���������������������

－ 98 －

測

候

時

報

コード表＊

9
9.1

79.5-62012

法の一つの資料でもある．このため，どの要素値・

コード表の公開

属性値のとりうる値にどのコード表が利用され，

気象庁 XML に関する技術情報については気象またその際のバージョンがどのようになっている

庁 XML の HP にて公開しているが，今回，気象かという情報は，妥当性確認における重要な情報庁 XML の解析に必要なコード表についても同様ともいえる．このことから，各コード表と，コーに公開した．これは，とりうる値（enumeration）

ド表を利用する要素・属性などコード表関連のメの妥当性確認方法として，XML スキーマによりタ情報を整理して提示するため，コード管理表を

バリデーションを行う方法もあるが，このことに作成した．コード管理表にはコード値に対するメ

よる XML スキーマの長大化によるデメリットを

タ情報の提供のほか，辞書・XML スキーマの運

考えると，必ずしも XML スキーマによるものだ

用とコード表の運用を結びつける目的も持ち合わけである必要はなく，オフライン仕様やテーブル

せている．

（コード表）の提供による方法なども手段として

コード表の管理において，1 つのコード表を複検討対象とする必要がある．また，いずれの方法

数部局が担当している場合は，バージョン管理上でも妥当性を確認できる環境が整えられていればのデグレード（バージョンダウン）が起きないよ

良いという XML コンソーシアムの助言があった．

うに関係者間で協力して行う．基本的にはコード

このことに，「気象庁 XML の解析に必要な情報

値を業務上管理している管理者よりは，その値をは全て公開すべき」という全体的な考え方も加え利用している利用者側で管理することを基本とすて，コード表を公開することとした．

る．これは，利用者側でメタ情報を付加する可能

なお，コード表の公開にあたっては，コード表性が高いことからである．いずれにしても，気象に関連する情報の特性に留意する．具体的には，

庁 XML のコード表のためだけの別管理体系とな

公開を前提としていない詳細な住所情報などがあらないようにするため，業務整理を行い，各業務る．ただし，地点情報に位置情報は必要であるこにおける管理体系との整合性を図れるようにすとから，粒度を下げる等により，必要最小限の情る．

報は付加できるように努力する．
9.3

コード表の統合

コード表の管理（運用指針 1.2 項）

気象庁 XML における統一的な利用に当たってコード値は運用指針 1.2 項にあるとおり，辞書・は，コード表についても例外とすべきではなく，XML スキーマとは独立して管理される．これは，情報の利用範囲や業務などに応じて，コード表の辞書・XML スキーマの変更は基本的に気象庁の統合に際して検討を行ってきた．結果として，統業務変更によるものであるのに対して，コード値

合されたコード表は多くないが，その成果の一つには地点を示すコードなど，他機関に依存するもとして市町村を示すコード表がある．本来，市町のや定常業務として定期的に変更する運用上の値

村単位を示すコード表として，全国地方公共団体という場合が多く，辞書や XML フォーマットのコード（JIS X 0402）があるが，火山関連情報で変更とコード値の変更とでは変更頻度や変更に伴利用する八丈支庁などの行政区分や島単位の地

うシステムへの影響度などが全く異なることか

域，気象警報・注意報で現地の防災上の理由によら，同等に扱わないことが望ましいことによる．

る同一市町村内での地域分割などには対応できてコード表はコード値そのものの持つ意味や関連いない．このことから，全国地方公共団体コード

するメタ情報との関連を示すテーブルであるが，の完全互換利用はできず，準拠した上で一部のみ

コード表公開の趣旨である妥当性確認の観点から拡張した気象庁独自のコード表を作成して，気象すれば，XML スキーマによらない妥当性確認方

警報・注意報から，地震や火山関係情報まで共通

9.2で利用している．
*第9章

杉山－ 99 －

測

候

時

10.1

79.5-62012

マ例 4）の 4 種類の対応について UPA 制約に関バージョン管理＊10

報

要素の追加に関する議論（1）要素の追加と UPA 制約

する技術的検討を行った．
共通辞書（基本要素）で定義している基本要

当初，気象庁 XML では，将来の拡張のために素については原則として要素参照（第 7.1 節（6）W3C XML Schema の any 要素を用いる方法（第項参照）により利用することとしているが，この4.3 節（4）項参照）を広く利用することとしてい場合，共通辞書（基本要素）のバージョンアップ

たが，Unique Particle Attribution（UPA）制約（第を行うと，全ての電文が影響を受ける．このため，

4.3 節（5）項参照）により問題となることが判明

any 要素を使って未定項目を設定する場合，共通したため，将来の拡張について精査する必要が生辞書との関連も含めて整理する必要がある．しかじてきた．

しながら，共通辞書（基本要素）については，基そこで，Temperature 要素が既に定義されてい本的な辞書なので，any 要素を用いて要素を増やるときに，未定義の Humidity 要素を兄弟要素とすようなことはせず，名前空間の変更により追加

して追加しなければいけなくなったときを事例と要素を表現する方針となった．このため，4 種類

して，第 10 表のとおり，any 要素を属する名前の事例のうち，スキーマ例 2 が他の事例よりも良空間のみに制限する方法（スキーマ例 1），any 要

い候補となりそうであった．

素を別名前空間のみに制限する方法（スキーマ例

一方，第 8.4 節（3）項で検討した気象要素の2），any 要素の出現場所を一段階掘り下げる方法

型に従い，どのような気象要素にもなれる「部品（スキーマ例 3），any 要素をやめる方法（スキーの any」として anyElementPart 要素の導入につい第 10 表スキーマ例
理想要素の追加における any 要素の利用方法による影響

スキーマ例の概要 バージョンアップ後の電文<jmx_mete:○○Part><jmx_eb:Temperature>14.5</jmx_eb:Temperature><jmx_eb:Humidity>50</jmx_eb:Humidity ></jmx_mete:○○Part>

対応例①<jmx_mete:○○Part><jmx_eb:Temperature>14.5</jmx_eb:Temperature><jmx_mete:Humidity>50</jmx_mete:Humidity >any要素を別名前空 </jmx_mete:○○Part>
スキーマ例２間のみに制限対応例②<jmx_mete_V11:○○Part><jmx_eb:Temperature>14.5</jmx_eb:Temperature><jmx_eb:Humidity>50</jmx_eb:Humidity ></jmx_mete_V11:○○Part><jmx_mete:○○Part><jmx_eb:Temperature>14.5</jmx_eb:Temperature>
any要素の出現場<jmx_mete:Addition>
スキーマ例３ 所の階層を一段階<jmx_mete:Humidity>50</ jmx_mete:Humidity >深くする</jmx_mete:Addition></jmx_mete:○○Part><jmx_mete_V2:○○Part>
any要素の利用をや <jmx_eb:Temperature>14.5</jmx_eb:Temperature>
スキーマ例４める<jmx_eb:Humidity>50</jmx_eb:Humidity ></jmx_mete_V2:○○Part>

第 10.1 節・第 10.7 節

W3C XML Schemaの枠組
みでは不可能である．
jmx_eb:Temperature要素の出現回数が0回以上であるため，UPA制約違反になる．

any要素を属する名
スキーマ例１
前空間のみに制限* 第 10 章

影響

竹田， 第 10.2 節～第 10.6 節－ 100 －

杉山

対応例①ではHumidity要
素が既にjmx_ebで定義してあるのにjmx_meteでも新たに定義する必要がある．
対応例②では親要素を別空間のanyで定義するする必要がある．
Humidity要素が既に
jmx_ebで定義してあるのに
jmx_meteでも新たに定義する必要がある．

jmx_meteとは名前空間が変わってしまう．

測

候

時

報

79.5-62012て検討した（第 18 図）．anyElementPart 要素によ加要素）を用いた辞書のバージョンアップに関する対応は，スキーマの any 要素を利用しないといる検討を行った．この方法は，共通辞書（追加要う意味でスキーマ例 4 の対応に当たる．この案素）以外の辞書については名前空間と辞書のバーについて検討したところ，anyElementPart 要素のジョンを一致させ，共通辞書（追加要素）は名前

type 属性のとり得る値は検索のキーとなる事項で空間と辞書のバージョンを別に管理し，未定項目あるため，辞書において列挙して記載すべきであとして想定していた箇所に要素を追加する場合はること，又，各要素を示すのは属性値ではなく要

名前空間の変わらない共通辞書（追加要素）に対素名として表現すべきという原則からも外れるこ

して新たに定義を加えることでバージョンアップ

とが意見として出され，anyElementPart 要素のよ

前後の互換性を確保するというものである．また，

うな属性値を利用して何にでもなれる要素を用意

XMLDic2Schema ツール（第 12.1 節参照）を利用した未定項目の定義はできないこととした．

して辞書から作成したスキーマによりバージョン

議論の過程ではこのような anyElementPart 要

アップ前後の電文の妥当性検証も行った．更に，素 の 提 案 も あ っ た が， 最 終 的 に は W3C XML

気象庁 XML 電文の利用者には，辞書のバージョ

Schema の any 要素を利用してバージョンアップ

ンの変更があってもシステムの対応を極力抑えたを実現することが適切と判断した．そこで，anyい利用者もいれば，より厳密に運用したい利用者

要素を利用してバージョンアップするとき，バーもいると考え，前者は any 要素の processContents

ジョンアップ前後で妥当性検証が想定通りできる

属性を“lax”として，後者は“strict”として妥かどうかの検討を行い，スキーマ例 2 の事例につ当性検証を行うことを新たに想定して互換性の検いて，バージョンアップに伴う妥当性検証への影証を行った．

響について議論を重ねた．この結果，辞書のバー

このように，共通辞書（追加要素）の検討をきジョンと妥当性検証のための名前空間の関連につっかけとして，名前空間，スキーマ，インスタン

いて更なる技術的検討が必要なことが分かった．

ス（電文）がバージョンアップ前後でどのようになるか，妥当性検証の結果はどのようになるべきかなど，運用と互換性の検討を行った（第 20 図）．

（2）追加要素辞書
前項の議論は既存の辞書を変更してバージョン

また，第 19 図の案と同様に気温だけの電文かアップする方法であったが，any 要素を別名前空ら構造や湿度が追加されていくというバージョン

間のみに制限するスキーマ例 2 の方法では，既存アップについて，前項のスキーマ例 2 の方法（以の辞書ではない辞書に新しい要素の定義をするこ

下「案 A」とする．）でバージョンアップするととができる．このため，個別辞書の any 要素の利きの妥当性検証を行った（第 21 図）．このバージ用と併せて，バージョンアップに伴うスキーマとョンアップの方法は，バージョンアップ前の辞

電文の妥当性検証に関する互換性（以下本項に書の内容は全て含み，要素を追加した新しい辞

おいて「互換性」という．）を満たす方法を検討

書を，バージョンアップ前の辞書と違う名前空し，更に第 19 図にまとめたように共通辞書（追間で新たに作成するというバージョンアップの33 type.AnyElementPart
34
type
35
Sentence36
Base37
Temporary38
Becoming
39
SubArea40
jmx_eb:AnyElement
41
Time
42
Remark第 18 図xs:string
xs:tokentype.BaseAnyElement
type.BaseAnyElement
type.BaseAnyElement
type.SubAreaAnyElement
jmx_eb:type.AnyElement
xs:dateTime
xs:string

anyElementPart 型の案－ 101 －

1 ��
? �������
? ���������
* ����* ���* ��* �����? ��? ���������

測

候

時

報

79.5-6

2012

方法である．この方法について検証を行ったとこなる．また，未定項目として any 要素を使うが，ろ，any 要素の processContents 属性を“lax”としとり得る名前空間は共通辞書（追加要素）の名前て処理すればメジャーバージョンが同じであれば空間に限定した．このことで，共通辞書（追加要前方互換，後方互換が保たれるようである．しか素）以外の辞書において UPA 制約の影響を受けし，“strict”として処理する場合は，スキーマのずに未定項目をより柔軟に配置できるようになる

import 要素において指定されるファイルが実際にとともに，要素の追加においては共通辞書（追加存在しないとエラーとなる．このことは，スキー要素）以外の辞書のバージョンアップが不要となマが整理されるメジャーバージョンアップまでのり，メジャーバージョンアップとなる事態を抑え将来に渡り必要なスキーマファイルについて，そられる．更に，案 B によるバージョンアップでのファイルを対象とした全ての import 要素を想作成した共通辞書（追加要素）（第 11 表）を見る

定しなければならないことから，結果としてこのと分かるが，マイナーバージョンアップを行う場

バージョンアップの方法が難しいことが確認され合には，これまでに定義している行は変更を行わた．

ず，必ず最後の行に新しい定義を行うことにより，一 方， 第 19 図 の 案 で は， 辞 書 の Ver1.1 と共通辞書（追加要素）で運用を厳密化した事項をVer1.2 で processContents 属 性 を“lax” と し て 妥

満たせることから，マイナーバージョンアップに当性検証しても電文の Ver1.4 がエラーとなって伴う管理も容易である．

しまい，後方互換が保たれないという問題があっ

こ の 検 討 を 踏 ま え る と， 案 A に お け る ス キ

た．このことから，スキーマ例 2 をヒントに，第ーマの import 要素の問題については，Ver1.1 の19 図の案の方法において，共通辞書（追加要素）

import 要 素 を Ver1.0 に，Ver1.2 の import 要 素 をの運用を厳密化することで後方互換性を確保できVer1.1 にと，新規に作成するスキーマには必ず次る方法（以下「案 B」とする．）が提案された（第のバージョンのスキーマファイルを記載すれば解22 図）．共通辞書（追加要素）で運用を厳密化し決できるとの意見があった．これについて再検証た事項は次の部分である．

した結果，any 要素の processContents 属性を“lax”「追加要素辞書」の前バージョンの定義にはとして処理すれば前方互換，後方互換が保たれ，子要素や属性の追加・削除などの変更を行わ

processContents 属性を“strict”として処理すればず，新たな要素を追加する．

マイナーバージョンアップで要素が追加された電この制限を加えることで，電文に構造のない

文はエラーとなり，案 B と同様の結果となった．

湿度を記述するため HumidityPart 要素を共通辞

これら案 A と案 B について，メリットとデメ書（追加要素）に追加（第 22 図の Ver1.2）した

リットをまとめたものが第 12 表である．

後，新たに構造のある湿度を記述（第 22 図の結果として，案 A も案 B も互換性では同様の

Ver1.3）する必要が生じた場合，同じ湿度を表結果となったが，案 A は名前空間で厳密に管理す要素にも関わらず HumidityPart 要素とは別にするのでバージョン管理が明確になるというメリ

HumidityPart2 要素を定義しなければならないもットがあるものの，若干高度なスキーマの知識がのの，any 要素の processContents 属性を“lax”と必要となることから，今後の運用・管理を考慮しして処理すれば前方互換，後方互換が保たれ，まて，W3C XML Schema の知識のない担当者でもた，processContents 属性を“strict”として処理す管理が容易な案 B を採用することとした．なお，

ればマイナーバージョンアップで要素が追加され二つの案の詳細な検討によりスキーマのバージョ

た電文は妥当性検証でエラーとなり，システムがン管理に関して明確かつ深い知見が得られたこと想定していない要素による悪影響を妥当性検証でで，辞書やスキーマの運用管理に関する各規定に防ぐことができることから，想定通りの互換性とおいてもこれら知見が反映されている．

－ 102 －

測

候

時

報

79.5-62012�������������
� jmx_mete ������Property ��������AdditionalInfo ����������������
�any�������������������������������
����Property ������������������������ Ver1.0������������
�����������������������������������������������
���������������������
������� ���������
��

���

���

���

���

�����

��

�����

�����

�����

�����

��

�� �������

��

��

��

��

��

�� �������

��

��

��

��

��

�� �������

��

��

��

��

��

�� �������

��

��

��

��

��

�� �������

��

��

��

��

��

�� �������

��

��

��

��

��

� ������������������������������������
����� Ver1.0��������
<InfoKindVersion>1.0</InfoKindVersion>

Property ��<Property><TemperaturePart><jmx_eb:Temperature type="��" unit="�">14.5</jmx_eb:Temperature></TemperaturePart></Property>

����<AdditionalInfo></AdditionalInfo>����� Ver1.1��������
<InfoKindVersion>1.1</InfoKindVersion>

Property ��� type ������������������*��������
<Property><TemperaturePart><jmx_eb:Temperature type="��" unit="�">14.5</jmx_eb:Temperature><jmx_eb:Temperature type="����" unit="�">10.5</jmx_eb:Temperature></TemperaturePart></Property>

����<AdditionalInfo></AdditionalInfo>����� Ver1.2��������
<InfoKindVersion>1.2</InfoKindVersion>

Property ��������

<Property><TemperaturePart><jmx_eb:Temperature type="��" unit="�">14.5</jmx_eb:Temperature><jmx_eb:Temperature type="����" unit="�">10.5</jmx_eb:Temperature></TemperaturePart><HumidityPart><jmx_eb:Humidity type="����" unit="%">50</jmx_eb:Humidity>

第 19 図 バージョンアップに伴うスキーマと電文の妥当性検証に関する互換性の確認資料
any 要素を利用した未定項目の絞り込みと併せたもの．（別添資料は省略）－ 103 －

測

候

時

報

79.5-62012</HumidityPart></Property>

����<AdditionalInfo></AdditionalInfo>����� Ver1.3��������
<InfoKindVersion>1.3</InfoKindVersion>

Property ��<Property><TemperaturePart><jmx_eb:Temperature type="��" unit="�">14.5</jmx_eb:Temperature><jmx_eb:Temperature type="����" unit="�">10.5</jmx_eb:Temperature></TemperaturePart><HumidityPart><jmx_eb:Humidity type="����" unit="%">50</jmx_eb:Humidity></HumidityPart></Property>����� TestAddition �����

<AdditionalInfo><TestAddition>���������</TestAddition></AdditionalInfo>����� Ver1.4��������
<InfoKindVersion>1.4</InfoKindVersion>

Property ������ Base ��� Temporary ��������

<Property><TemperaturePart><jmx_eb:Temperature type="��" unit="�">14.5</jmx_eb:Temperature><jmx_eb:Temperature type="����" unit="�">10.5</jmx_eb:Temperature></TemperaturePart><HumidityPart><Base><jmx_eb:Humidity type="����" unit="%">50</jmx_eb:Humidity></Base><Temporary><jmx_eb:Humidity type="����" unit="%">20</jmx_eb:Humidity></Temporary></HumidityPart></Property>

����<AdditionalInfo><TestAddition>���������</TestAddition></AdditionalInfo>����� Ver2.0����������
<Report xmlns="http://xml.kishou.go.jp/jmaxml2/" xmlns:jmx="http://xml.kishou.go.jp/jmaxml2/"><Schema><Head><Name>�������</Name><Version>2.0_0</Version><URI>http://xml.kishou.go.jp/jmaxml2/informationBasis/</URI></Head><Body><Name>�����</Name><Version>2.0_0</Version><URI>http://xml.kishou.go.jp/jmaxml2/body/meteorology/</URI></Body></Schema><Head xmlns="http://xml.kishou.go.jp/jmaxml2/informationBasis/"
xmlns:jmx_eb="http://xml.kishou.go.jp/jmaxml2/elementBasis/">第 19 図続き－ 104 －

測

候

時

報

79.5-62012<Body xmlns="http://xml.kishou.go.jp/jmaxml2/body/meteorology/"
xmlns:jmx_eb="http://xml.kishou.go.jp/jmaxml2/elementBasis/"
xmlns:jmx_add="http://xml.kishou.go.jp/jmaxml2/addition/">��������
<InfoKindVersion>2.0</InfoKindVersion>

Property ����������� jmx_mete � jmx_eb ���<Property><TemperaturePart><jmx_eb:Temperature type="��" unit="�">14.5</jmx_eb:Temperature><jmx_eb:Temperature type="����" unit="�">10.5</jmx_eb:Temperature></TemperaturePart><HumidityPart><Base><jmx_eb:Humidity type="����" unit="%">50</jmx_eb:Humidity></Base><Temporary><jmx_eb:Humidity type="����" unit="%">20</jmx_eb:Humidity></Temporary></HumidityPart></Property>

AdditionalInfo ����������� jmx_mete ���<AdditionalInfo><TestAddition>���������</TestAddition></AdditionalInfo>���������� �����������������������������������
���jmx� ���������������������������Schema ������� Addition �����������jmx_mete
� Property ��� AdditionalInfo ��������##other�������������� any �����������jmx_add� ����������������������������������������������
�����������������������������������������������
����������������� �� Ver1.0� �� ������ Ver1.0
� �� Ver1.1� �� ������ Ver1.0
� �� Ver1.2� �� ������ Ver1.1� �� Ver1.3� �� ������ Ver1.2
� �� Ver1.4� �� ������ Ver1.3
� �� Ver2.0� �� ������ Ver2.0���������������� ������������������XMLDic2Schema������������� jmx_add ��������������jmx_mete �����������������������
<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:jmx_eb="http://xml.kishou.go.jp/jmaxml/elementBasis/"
xmlns:jmx_add="http://xml.kishou.go.jp/jmaxml/addition/"
xmlns:jmx_mete="http://xml.kishou.go.jp/jmaxml/body/meteorology/" elementFormDefault="qualified"targetNamespace="http://xml.kishou.go.jp/jmaxml/body/meteorology/"><xs:import namespace="http://xml.kishou.go.jp/jmaxml/elementBasis/" schemaLocation="jmx_eb.xsd"/><xs:import namespace="http://xml.kishou.go.jp/jmaxml/addition/" schemaLocation="jmx_add.xsd"/>

第 19 図－ 105 －

続き

測

候

時

報

79.5-62012� ���������������������������������XMLDic2Schema���processContents ����lax������������strict��������������������
�������������
<xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="lax"/><xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="strict"/>��� �������
�����������

���������

���������

��������

��������

��������

��������

��������

���������

��������

�������������

����������

����������

����������

������������� �������

��

��

��

��

��

��

��

��

��

��

�� �������

��

��

��

��

��

��

��

��

��

��

�� �������

��

��

��

��

��

��

��

��

��

��

�� �������

��

��

��

��

��

��

��

��

��

��

�� �������

��

��

��

��

��

��

��

��

��

��

�� �������

��

��

��

��

��

��

��

��

��

��

���������������

第 19 図続き－ 106 －

測

候

時

報

79.5-62012���������������������
��
��

�
�
�
�

ts1����

ts1_p1�����Ver.1.00�

�Ver.1.00�

<xs:element name=“Doc" type="ts1:type.doc"/><xs:complexType name="type.doc"><xs:sequence><xs:element minOccurs="0" maxOccurs="1"
ref="ts1_p1:AP"/></xs:sequence></xs:complexType></xs:element><xs:complexType name="type.P"><xs:simpleContent><xs:extension base="xs:float"><xs:attribute name=“p" type=“xs:string"/></xs:extension></xs:simpleContent></xs:complexType><xs:element name=“AP“ type="ts1_p1:type.P"/><xs:element name=“BP“ type="ts1_p1:type.P"/>

�Ver.1.00�
<Doc><ts1_p1:AP>12.5</ts1_p1:AP>�����������
</Doc>

�
�
�
�
�
�

�����������������
��������any”������� � ��������×
��
��

�
�
�
�

ts1, ts1_p1
�Ver.1.00�

�Ver.1.01�

�ts1<xs:sequence><xs:element minO...="0" maxO...="1" ref="ts1_p1:AP"/></xs:sequence>�ts1<xs:sequence><xs:element minO...="0" maxO...="1" ref="ts1_p1:AP"/><xs:element minO...="0" maxO...="1" ref="ts1_p1:BP"/></xs:sequence>�ts1_p1���ts1_p1<xs:element name=“AP“ type="ts1_p1:type.P"/><xs:element name=“BP“ type="ts1_p1:type.P"/>

�
�
�
�
�
�
�

�

�Ver.1.00�

�Ver.1.01�

<Doc><ts1_p1:AP>12.5</ts1_p1:AP></Doc><Doc><ts1_p1:AP>12.5</ts1_p1:AP><ts1_p1:BP>25.0</ts1_p1:BP></Doc>

����������������
��������any”������� � ����������×

�
�
�
�

ts2
ts1_p1

ts1
ts1_p1�����Ver.1.00�

�Ver.2.00�…���

�ts1<xs:sequence><xs:element minO...="0" maxO...="1" ref="ts1_p1:AP"/></xs:sequence>�ts2<xs:sequence><xs:element minO...="0" maxO...="1" ref="ts1_p1:AP"/><xs:element minO...="0" maxO...="1" ref="ts1_p1:BP"/></xs:sequence>�ts1_p1���ts1_p1<xs:element name=“AP“ type="ts1_p1:type.P"/><xs:element name=“BP“ type="ts1_p1:type.P"/>

�
�
�
�
�
�
�

�

�Ver.1.00�

�Ver.2.00�

<Doc><ts1_p1:AP>12.5</ts1_p1:AP></Doc><Doc><ts1_p1:AP>12.5</ts1_p1:AP><ts1_p1:BP>25.0</ts1_p1:BP></Doc>

第 20 図バージョンアップにおける運用と互換性のまとめ－ 107 －

測

候

時

報

79.5-62012�����������������
��������any”������ � �����������
����

ts1, ts1_p1
�Ver.1.00�

�Ver.1.00�

�ts1
�ts1
<xs:sequence>��<xs:element minO...="1" maxO...="1" ref="ts1_p1:AP"/><xs:any minO...="0" maxO...="unbounded"namespace="other"/></xs:sequence>�ts1_p1�ts1_p1<xs:element name=“AP“ type="ts1_p1:type.P"/>��<xs:element name=“BP“ type="ts1_p1:type.P"/>

�
�
�
�

�

�

�Ver.1.00�

�Ver.1.01�

���������
<Doc><ts1_p1:AP>12.5</ts1_p1:AP><ts1_p1:BP>25.0</ts1_p1:BP></Doc><Doc><ts1_p1:AP>12.5</ts1_p1:AP></Doc>

�
�
�
�
�
�

�����������������
��������any”������ � �����������
��
��

�
�
�
�

ts1, ts1_p1
�Ver.1.00�

�Ver.1.00�

�ts1<xs:sequence><xs:element minO...="1" maxO...="1" ref="ts1_p1:AP"/><xs:any minO...="0" maxO...="u..." namespace="other"/></xs:sequence>

�ts1
��

�Ver.1.00�

�Ver.1.01��ts1_p1<xs:element name=“AP“ type="ts1_p1:type.P"/><xs:element name=“BP“ type="ts1_p1:type.P"/>

�ts1_p1<xs:element name=“AP“ type="ts1_p1:type.P"/><xs:element name=“BP“ type="ts1_p1:type.P"/><xs:element name=“AX“ type="ts1_p1:type.X"/>

�
�
�
�
�
�
�

�

�Ver.1.00�

�Ver.1.01�

<Doc><ts1_p1:AP>12.5</ts1_p1:AP></Doc><Doc><ts1_p1:AP>12.5</ts1_p1:AP><ts1_p1:BP>25.0</ts1_p1:BP></Doc>

���������

����������������
��������any”������ � �����������
��
��

�
�
�
�

ts1, ts1_p1 + ts1_p1_00

ts1, ts1_p1
�Ver.1.00�

���

�ts1
<xs:sequence><xs:element minO...="1" maxO...="1" ref="ts1_p1:AP"/><xs:any minO...="0" maxO...="u..." namespace="other"/></xs:sequence>�ts1_p1<xs:element name=“AP“ type="ts1_p1:type.P"/><xs:element name=“BP“ type="ts1_p1:type.P"/>

�ts1
���ts1_p1���ts1_p1_00<xs:element name=“AX“ type="ts1_p1_00:type.X"/>��

�Ver.1.00�
�
�
�
�
�
�

�Ver.1.01�

���������
<Doc><ts1_p1:AP>12.5</ts1_p1:AP><ts1_p1_00:AX>100.0</ts1_p1_00:AX></Doc><Doc><ts1_p1:AP>12.5</ts1_p1:AP></Doc>

第 20 図続き－ 108 －

測

候

時

報

79.5-62012�������������
� jmx_mete ������Property ��������AdditionalInfo ����������������
�any�������������������������������
����Property ������������������������ Ver1.0������������
�����������������������������������������������
���������������������������� ���������
��

���

���

���

���

�����

��

�����

�����

�����

�����

��

�� �������

��

��

��

��

��

�� �������

��

��

��

��

��

�� �������

��

��

��

��

��

�� �������

��

��

��

��

��

�� �������

��

��

��

��

��

�� �������

��

��

��

��

��

� ������������������������������������
����� Ver1.0��������
<InfoKindVersion>1.0</InfoKindVersion>

Property ��<Property><TemperaturePart><jmx_eb:Temperature type="��" unit="�">14.5</jmx_eb:Temperature></TemperaturePart></Property>

����<AdditionalInfo></AdditionalInfo>����� Ver1.1��������
<InfoKindVersion>1.1</InfoKindVersion>

Property ��� type ������������������*��������
<Property><TemperaturePart><jmx_eb:Temperature type="��" unit="�">14.5</jmx_eb:Temperature><jmx_eb:Temperature type="����" unit="�">10.5</jmx_eb:Temperature></TemperaturePart></Property>

����<AdditionalInfo></AdditionalInfo>����� Ver1.2��������
<InfoKindVersion>1.2</InfoKindVersion>

Property ��������

<Property><TemperaturePart><jmx_eb:Temperature type="��" unit="�">14.5</jmx_eb:Temperature><jmx_eb:Temperature type="����" unit="�">10.5</jmx_eb:Temperature></TemperaturePart><jmx_mete11:HumidityPart><jmx_eb11:Humidity type="����" unit="%">50</jmx_eb11:Humidity>

第 21 図 バージョンアップに伴うスキーマと電文の妥当性検証に関する互換性の確認資料
any 要素を別名前空間のみに制限する方法．（別添資料は省略）－ 109 －

測

候

時

報

79.5-62012</jmx_mete11:HumidityPart></Property>

����<AdditionalInfo></AdditionalInfo>����� Ver1.3��������
<InfoKindVersion>1.3</InfoKindVersion>

Property ��<Property><TemperaturePart><jmx_eb:Temperature type="��" unit="�">14.5</jmx_eb:Temperature><jmx_eb:Temperature type="����" unit="�">10.5</jmx_eb:Temperature></TemperaturePart><jmx_mete11:HumidityPart><jmx_eb11:Humidity type="����" unit="%">50</jmx_eb11:Humidity></jmx_mete11:HumidityPart></Property>����� TestAddition �����

<AdditionalInfo><jmx_mete12:TestAddition>���������</jmx_mete12:TestAddition></AdditionalInfo>����� Ver1.4��������
<InfoKindVersion>1.4</InfoKindVersion>

Property ������ Base ��� Temporary �������� HumidityPart2 �����
<Property><TemperaturePart><jmx_eb:Temperature type="��" unit="�">14.5</jmx_eb:Temperature><jmx_eb:Temperature type="����" unit="�">10.5</jmx_eb:Temperature></TemperaturePart><jmx_mete11:HumidityPart><jmx_eb11:Humidity type="����" unit="%">50</jmx_eb11:Humidity></jmx_add:HumidityPart><jmx_mete13:HumidityPart2><jmx_mete13:Base><jmx_eb11:Humidity type="����" unit="%">50</jmx_eb11:Humidity></jmx_mete13:Base><jmx_mete13:Temporary><jmx_eb11:Humidity type="����" unit="%">20</jmx_eb11:Humidity></jmx_mete13:Temporary></jmx_mete13:HumidityPart2></Property>

����<AdditionalInfo><jmx_mete12:TestAddition>���������</jmx_mete12:TestAddition></AdditionalInfo>����� Ver2.0����������
<Report xmlns="http://xml.kishou.go.jp/jmaxml2/" xmlns:jmx="http://xml.kishou.go.jp/jmaxml2/"><Schema><Head><Name>�������</Name><Version>2.0_0</Version><URI>http://xml.kishou.go.jp/jmaxml2/informationBasis/</URI></Head><Body><Name>�����</Name><Version>2.0_0</Version><URI>http://xml.kishou.go.jp/jmaxml2/body/meteorology/</URI></Body></Schema>

第 21 図続き－ 110 －

測

候

時

報

79.5-62012<Head xmlns="http://xml.kishou.go.jp/jmaxml2/informationBasis/"
xmlns:jmx_eb="http://xml.kishou.go.jp/jmaxml2/elementBasis/"><Body xmlns="http://xml.kishou.go.jp/jmaxml2/body/meteorology/"
xmlns:jmx_eb="http://xml.kishou.go.jp/jmaxml2/elementBasis/"
xmlns:jmx_add="http://xml.kishou.go.jp/jmaxml2/addition/">��������
<InfoKindVersion>2.0</InfoKindVersion>

Property � � � � � � � � � � � jmx_mete � jmx_eb � � � � � � � HumidityPart2 � � �
HumidityPart ������������������������ Ver1 �� HumidityPart ���<Property><TemperaturePart><jmx_eb:Temperature type="��" unit="�">14.5</jmx_eb:Temperature><jmx_eb:Temperature type="����" unit="�">10.5</jmx_eb:Temperature></TemperaturePart><HumidityPart><Base><jmx_eb:Humidity type="����" unit="%">50</jmx_eb:Humidity></Base><Temporary><jmx_eb:Humidity type="����" unit="%">20</jmx_eb:Humidity></Temporary></HumidityPart></Property>

AdditionalInfo ����������� jmx_mete ���<AdditionalInfo><TestAddition>���������</TestAddition></AdditionalInfo>���������
�����������������������������������
���jmx_mete
Property ��� AdditionalInfo ��������##other�������namespace������ any��������
�� Ver1.0
�� Ver1.1
�� Ver1.2
�� Ver1.3
�� Ver1.4
�� Ver2.0

�
�
�
�
�
�

������ Ver1.0������ Ver1.0������ Ver1.1
���
���
���

���������������
���������XMLDic2Schema_alfa2.0_fat.jar�������������-a normal -e normal�����������xs:any ��� namespace ����������������enumeration ������� union ����������������
�XMLDic2Schema��� processContents ����lax������������strict���������������������������������
<xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="lax"/><xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="strict"/>���processContents � strict ��������������������������������
������jmx_mete ���� jmx ������������������������������
���������
<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:jmx="http://xml.kishou.go.jp/jmaxml/"
xmlns:jmx_ib="http://xml.kishou.go.jp/jmaxml/informationBasis/"
xmlns:jmx_mete="http://xml.kishou.go.jp/jmaxml/body/meteorology/"

第 21 図－ 111 －

続き

測

候

時

報

79.5-62012

xmlns:jmx_mete11="http://xml.kishou.go.jp/jmaxml/body/meteorology/1.1/"
elementFormDefault="qualified" targetNamespace="http://xml.kishou.go.jp/jmaxml/"><xs:import namespace="http://xml.kishou.go.jp/jmaxml/body/meteorology/" schemaLocation="jmx_mete.xsd"/><xs:import namespace="http://xml.kishou.go.jp/jmaxml/informationBasis/" schemaLocation="jmx_ib.xsd"/><xs:import namespace="http://xml.kishou.go.jp/jmaxml/body/meteorology/1.1/" schemaLocation="jmx_mete11.xsd"/>���������
��
Ver1.0��
Ver1.0��
Ver1.1��Ver1.1��Ver1.2��Ver1.2��Ver1.3��Ver1.3��Ver2.0��
Ver2.0lax

strictlax

strictlax

strictlax

strictlax

strict�� Ver1.0

�

�

�

�

�� Ver1.1

�

�

�

�

�� Ver1.2

�

×

�

�

�� Ver1.3

�

×

�

×

�� Ver1.4

�

×

�

×

�� Ver2.0

×

×

×

×

���������������

第 21 図続き－ 112 －

測

候

時

報

79.5-62012�������������
� jmx_mete ������Property ��������AdditionalInfo ����������������
�any�������������������������������
����Property ������������������������ Ver1.0�����������
�����������������������������������������������
����������������������������� ���������
��

���

���

���

���

��

�����

�����

�����

�����

�����

��

�� �������

��

��

��

��

��

�� �������

��

��

��

��

��

�� �������

��

��

��

��

��

�� �������

��

��

��

��

��

�� �������

��

��

��

��

��

�� �������

��

��

��

��

��

� ������������������������������������
����� Ver1.0��������
<InfoKindVersion>1.0</InfoKindVersion>

Property ��<Property><TemperaturePart><jmx_eb:Temperature type="��" unit="�">14.5</jmx_eb:Temperature></TemperaturePart></Property>

����<AdditionalInfo></AdditionalInfo>����� Ver1.1��������
<InfoKindVersion>1.1</InfoKindVersion>

Property ��� type ������������������*��������
<Property><TemperaturePart><jmx_eb:Temperature type="��" unit="�">14.5</jmx_eb:Temperature><jmx_eb:Temperature type="����" unit="�">10.5</jmx_eb:Temperature></TemperaturePart></Property>

����<AdditionalInfo></AdditionalInfo>����� Ver1.2��������
<InfoKindVersion>1.2</InfoKindVersion>

Property ��������

<Property><TemperaturePart><jmx_eb:Temperature type="��" unit="�">14.5</jmx_eb:Temperature><jmx_eb:Temperature type="����" unit="�">10.5</jmx_eb:Temperature></TemperaturePart><jmx_add:HumidityPart><jmx_add:Humidity type="����" unit="%">50</jmx_add:Humidity>

第 22 図 バージョンアップに伴うスキーマと電文の妥当性検証に関する互換性の確認資料
共通辞書（追加要素）の運用を厳格化する方法．（別添資料は省略）－ 113 －

測

候

時

報

79.5-62012</jmx_add:HumidityPart></Property>

����<AdditionalInfo></AdditionalInfo>����� Ver1.3��������
<InfoKindVersion>1.3</InfoKindVersion>

Property ��<Property><TemperaturePart><jmx_eb:Temperature type="��" unit="�">14.5</jmx_eb:Temperature><jmx_eb:Temperature type="����" unit="�">10.5</jmx_eb:Temperature></TemperaturePart><jmx_add:HumidityPart><jmx_add:Humidity type="����" unit="%">50</jmx_add:Humidity></jmx_add:HumidityPart></Property>����� TestAddition �����

<AdditionalInfo><jmx_add:TestAddition>���������</jmx_add:TestAddition></AdditionalInfo>����� Ver1.4��������
<InfoKindVersion>1.4</InfoKindVersion>

Property ������ Base ��� Temporary �������� HumidityPart2 �����
<Property><TemperaturePart><jmx_eb:Temperature type="��" unit="�">14.5</jmx_eb:Temperature><jmx_eb:Temperature type="����" unit="�">10.5</jmx_eb:Temperature></TemperaturePart><jmx_add:HumidityPart><jmx_add:Humidity type="����" unit="%">50</jmx_add:Humidity></jmx_add:HumidityPart><jmx_add:HumidityPart2><jmx_add:Base><jmx_add:Humidity type="����" unit="%">50</jmx_add:Humidity></jmx_add:Base><jmx_add:Temporary><jmx_add:Humidity type="����" unit="%">20</jmx_add:Humidity></jmx_add:Temporary></jmx_add:HumidityPart2></Property>

����<AdditionalInfo><jmx_add:TestAddition>���������</jmx_add:TestAddition></AdditionalInfo>����� Ver2.0����������
<Report xmlns="http://xml.kishou.go.jp/jmaxml2/" xmlns:jmx="http://xml.kishou.go.jp/jmaxml2/"><Schema><Head><Name>�������</Name><Version>2.0_0</Version><URI>http://xml.kishou.go.jp/jmaxml2/informationBasis/</URI></Head><Body><Name>�����</Name><Version>2.0_0</Version><URI>http://xml.kishou.go.jp/jmaxml2/body/meteorology/</URI></Body></Schema>

第 22 図続き－ 114 －

測

候

時

報

79.5-62012<Head xmlns="http://xml.kishou.go.jp/jmaxml2/informationBasis/"
xmlns:jmx_eb="http://xml.kishou.go.jp/jmaxml2/elementBasis/"><Body xmlns="http://xml.kishou.go.jp/jmaxml2/body/meteorology/"
xmlns:jmx_eb="http://xml.kishou.go.jp/jmaxml2/elementBasis/"
xmlns:jmx_add="http://xml.kishou.go.jp/jmaxml2/addition/">��������
<InfoKindVersion>2.0</InfoKindVersion>

Property � � � � � � � � � � � jmx_mete � jmx_eb � � � � � � � HumidityPart2 � � �
HumidityPart ������������������������ Ver1 �� HumidityPart ���<Property><TemperaturePart><jmx_eb:Temperature type="��" unit="�">14.5</jmx_eb:Temperature><jmx_eb:Temperature type="����" unit="�">10.5</jmx_eb:Temperature></TemperaturePart><HumidityPart><Base><jmx_eb:Humidity type="����" unit="%">50</jmx_eb:Humidity></Base><Temporary><jmx_eb:Humidity type="����" unit="%">20</jmx_eb:Humidity></Temporary></HumidityPart></Property>

AdditionalInfo ����������� jmx_mete ���<AdditionalInfo><TestAddition>���������</TestAddition></AdditionalInfo>���������� �����������������������������������
���jmx� ���������������������������Schema ������� Addition ������������������������� import ���������� Body �� any �����
http://xml.kishou.go.jp/jmaxml/body/meteorology/� http://xml.kishou.go.jp/jmaxml/addition/�������������
<xs:import namespace="http://xml.kishou.go.jp/jmaxml/addition/" schemaLocation="jmx_add.xsd"/>

���jmx_mete
� Property ��� AdditionalInfo ��������http://xml.kishou.go.jp/jmaxml/addition/�����
��������� any ��������
���jmx_add� ����������������������������������������������
�����������������������������������������������
����������������� �� Ver1.0� �� ������ Ver1.0
� �� Ver1.1� �� ������ Ver1.0
� �� Ver1.2� �� ������ Ver1.1� �� Ver1.3� �� ������ Ver1.2
� �� Ver1.4� �� ������ Ver1.3
� �� Ver2.0� �� ������ Ver2.0���������������� �������������������������������������
�XMLDic2Schema_alfa2.0_fat.jar�������������-a uri -e normal����������

第 22 図－ 115 －

続き

測

候

時

報

79.5-62012

�XMLDic2Schema��� processContents ����lax������������strict�������
��������������������������
<xs:any maxOccurs="unbounded" minOccurs="0" namespace="http://xml.kishou.go.jp/jmaxml/addition/" processContents="lax"/><xs:any maxOccurs="unbounded" minOccurs="0" namespace="http://xml.kishou.go.jp/jmaxml/addition/" processContents="strict"/>��� �������� � � �������� ���������� ��������� ��������� ��������� ��������� ��������� ��������� ��������� ��������

�������������

����������

����������

����������

������������� �������

��

��

��

��

��

��

��

��

��

��

�� �������

��

��

��

��

��

��

��

��

��

��

�� �������

��

��

��

��

��

��

��

��

��

��

�� �������

��

��

��

��

��

��

��

��

��

��

�� �������

��

��

��

��

��

��

��

��

��

��

�� �������

��

��

��

��

��

��

��

��

��

��

���������������
第 22 図
第 11 表案 B によるバージョンアップで作成した共通辞書（追加要素）

�� jmx_add
�
��

���

続き

��� http://xml.kishou.go.jp/jmaxml/addition/
���

1 type.HumidityPart
2
Humidity
3 type.Humidity
45678 (element)
HumidityPart
9 (element)
TestAddition
10 type.HumidityPart2
11
Sentence12
Base13
Temporary
14
Becoming
15
SubArea16
Humidity
17
Time
18
Remark19 type.SubAreaHumidity
20
AreaName
21
Sentence22
Base
23
Temporary24
Becoming
25
Local
26
Humidity
27
Time
28
Remark29 type.BaseHumidity
30
TimeModifier
31
Humidity
32
Local
33
Time
34
Remark
35 type.LocalHumidity
36
AreaName
37
Sentence
38
Humidity
39
Time
40
Remark41 (element)
HumidityPart242 (end)

��

type
unit
refID
condition

���
type.Humidity
xs:float
xs:string
xs:string
xs:unsignedByte
xs:string
type.HumidityPart
xs:string

��
��

��

* ��
1
?
?
?
1

��
��
���������
1 ���������

xs:tokentype.BaseHumidity
type.BaseHumidity
type.BaseHumidity
type.SubAreaHumidity
type.Humidity
xs:dateTime
xs:string? �������
? ���������
* ����
* ���
* ��
* ��
? ��
? ���������

xs:token
xs:tokentype.BaseHumidity
type.BaseHumidity
type.BaseHumidity
type.LocalHumidity
type.Humidity
xs:dateTime
xs:string? �����
? �������
? ���������
* ����
* ���
* ��
* ��
? ��
? ���������

xs:tokentype.Humidity
type.LocalHumidity
xs:dateTime
xs:string? ��������
* ��
* ��
? ��
? ���������

xs:token
xs:tokentype.Humidity
xs:dateTime
xs:string
type.HumidityPart2? �����
? �������* ��? ��? ���������

－ 116 －

1�����������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������
���������

測

候

時

報

79.5-62012

第 12 表 バージョンアップに伴うスキーマと電文の妥当性検証に関する互換性の確認
案 A と案 B のまとめ．

�

����

��

�����
�����������������������������������
������������������� ������������������������������
������
�������
�����������������������

������������������������� ����������������������������������
������������������� ���������
������������������������
�������
������������������������������
������������������

10.2

辞書・XML スキーマのバージョン管理（仕とすることとした．特に，リビジョン番号のみの変更となるような XML スキーマの互換性が維様 2.3 項，運用指針 1.1 項）
前節における検討が行われる前の当初におい持される変更においては，「XML スキーマのバーて，バージョン番号は XML 電文として配信されジョンは変更されない」という認識で整理がされる電文（XML インスタンス）に対応する XML

た．また，いずれの変更においても，XML スキ

スキーマのバージョン番号として記述することをーマの注釈行にて変更履歴を記述することとし想定していた．しかしながら，前項における議論た．なお，運用開始後，実際にリビジョン番号を等を経た結果，バージョン番号は XML インスタ変更するバージョンアップを行った際に，何も変ンスの運用に対して管理番号を振ることとした．

更が無い XML スキーマを注釈行の追記だけで変これら辞書・XML スキーマのバージョン管理に更してよいかという議論を行い，追記しないこと

ついては，仕様 2.3 項においてバージョンアップ

に変更した．このため，変更履歴の記述についてとバージョン番号の考え方，及び共通辞書（追加は再検討を行っている．

要素）による対応について概要を，運用指針 1.1
項でバージョンアップの内容に応じたバージョン
番号や業務的運用について，具体的に解説をして10.3

共通辞書（追加要素）の使い方（仕様2.3.1 項，運用指針 1.1.2.3 項）

共通辞書（追加要素）を用いたバージョンアッいる．
また，バージョン番号の付与ルールについては，

プについては，運用指針 1.1.2.3 項にてマイナー

当初から「上位バージョン番号」+“.”+「下位バージョンアップ 3 として解説している．マイナ

バージョン番号」+“_”+「リビジョン番号」のーバージョンアップ 3 は，主として以下のような「A.B_C」形式を案として取り入れていたが，こ状況を想定いる．
・特定の電文のみにおいて，全く新しい要素をれをそのまま踏襲して，・上位バージョン番号は，メジャー番号のうち追加する．

名前空間を変えるような大きな変更の際に利・他の電文には影響を与えない．

用する．

本バージョンアップにおいて，辞書・XML ス

・下位バージョン番号は，メジャー番号のうち新しい XML スキーマが古い XML インスタンスに対して互換するような名前空間を変更

キーマを具体的に以下のとおり対応する．
・ 共 通 辞 書（ 追 加 要 素 ） の XML ス キ ー マ（jmx_add.xsd）に改変を行う．

しない XML スキーマの変更の際に利用する．

・同 XML スキーマの注釈行においてバージョ・リビジョン番号は，XML スキーマの互換性

ン番号の増加（マイナー番号）と変更内容のが必ず維持されるような変更及びインスタン

解説を付記する．
・共通辞書（追加要素）を取り込む側の XML

スの運用のみの変更の際に利用する．

－ 117 －

測

候

時

報

スキーマに改変はない．

79.5-62012においても，名前空間定義の変更が発生すること・ 対 象 と す る 特 定 電 文 に つ い て は，“jmx_ib:

から，これまでとは互換性がなくなる．このた

InfoKindVersion”のバージョン番号の増加（マめ，メジャーバージョンアップ 2 の実施について

イナー番号）を行う．

は，事案がある電文関係に限らず，“jmx_mete”，

・それ以外の電文について改変はない．

“jmx_seis”，“jmx_volc”，“jmx_eb”等全てにおいこの対応の結果，利用者における電文の運用はて要素の拡充・改変等を検討し，一斉整理する機

以下のとおりとなる．

会として期間を掛けて実施する．

・対象となる特定の電文の利用者で追加要素を利用せずにすませる利用者については，

10.6

基本的に特段の対応をしなくても利用可能

XML インスタンスと XML スキーマのライ
フサイクル（“processContents="lax"” の 定 義 に よ り 正 誤バージョン管理として，XML インスタンスとが判定できなくてもエラーとならない対応がXML スキーマにおけるバージョン番号の変移を可能）．

第 23 図にまとめる．

・対象となる特定電文の利用者で追加要素を利用する利用者については，共通辞書（追加要10.7

素）の XML スキーマ（jmx_add.xsd）の差し

初めての気象庁 XML のバージョンアップは，替えをするとともに，当該要素に関わる処理

指定河川洪水予報の電文の様式変更に伴い平成

プログラムを改修する．なお，一部のシステ

22 年 8 月 6 日に実施した．

ムでは XML スキーマの差し替えなしで動作バージョンアップ対応の事例

指定河川洪水予報は，国土交通省及び都道府県

する可能性がある．

と共同で実施していることから，その改善には気・対象となる特定電文以外の利用については，

象庁内の調整のほかに，国土交通省等の部外機関との調整が必要であるため，気象庁 XML の仕様

対応不要．

検討とは別に検討・調整がされた．新たな洪水予
メジャーバージョンアップ 1 の XML イン

報の様式については，平成 22 年 2 月頃に調整がスタンス運用（運用指針 1.1.2.4 項）

まとまりつつあった．そこで，指定河川洪水予報

メジャーバージョンアップ 1 において，対応すの改善内容を気象庁 XML に反映するよう，辞書

る XML スキーマは名前空間を維持したまま改変の一部追加・変更等を行うこととしたいとの要望される．一方で運用指針 1.1.2 項のとおり，変更

が予報課から上がった．これまで議論してきたメで影響を受けない電文については，そのままのバ

ジャーバージョンアップの影響度や重要性から勘ージョン番号を維持する．このため，変更電文以

案すると，現時点でメジャーバージョンアップを外のその他の電文利用者にとっては新 XML スキ行うことは極力避けるべきである．このため，どーマファイルを更新する必要は原則としてない．

うしても現在の辞書で記述できない事項について

ただし，バージョンの管理は“jmx_ib:InfoKind”

は，共通辞書（追加要素）に定義してマイナーバ

単位で実施していることから，後日その他の電文ージョンアップができるかどうか検討し，それでにおける変更があった場合に，以前の変更部分もも対応できない場合は，個別辞書（気象分野）の含めて対応が必要となる可能性はある．

Body 要素の子要素の AdditionalInfo 要素の中に記10.4

述する方法をとるべきであった．
10.5

メジャーバージョンアップ 2 について
（運用指針 1.1.2.5 項）

そこで，とりうる値の変更のみで辞書の変更を伴わない案 1（第 24 図）と辞書の変更を伴う案

メジャーバージョンアップ 2 は名前空間の変更

2（第 25 図）を予報課にて作成し，関係者間でのが発生することから，互換性が一切維持されな検討を行った．この結果，本件バージョンアップ

い．これは内容的には変更が発生されない管理部

時点で気象庁 XML は正式運用開始前であること－ 118 －

－ 119 －�������������

���������������������

第 23 図Ver1.01����������������
<xsd:element name="Humidity" minOccurs="0" maxOccurs="1" type="xsd:float"/>����Ver1.01

jmx_hoge

Ver1.01

jmx_hoge_add01

Ver1.00

jmx_hoge

Ver2.00���������
��������������
�����������

<jmx_hoge:TemperaturePart><jmx_hoge:Temperature>14.5</jmx_hoge:Temperature><jmx_hoge_add01:Humidity>14.5</jmx_hoge_add01:Humidity></jmx_hoge:TemperaturePart>�������Ver1.00�������add01�������
�������

����������������
<xsd:element name="Humidity" minOccurs="0" maxOccurs="1" type="xsd:float"/>����������
<xsd:sequence><xsd:element name="Temperature" type="xsd:float" minOccurs="0"
maxOccurs="1"/><xsd:any minOccurs="0" maxOccurs="unbounded" namespace=”##other”/></xsd:sequence>Ver2.00

jmx_hoge2

Ver2.00

jmx_hoge2����<jmx_hoge2:TemperaturePart><jmx_hoge2:Temperature>14.5</jmx_hoge2:Temperature>����������������������������������������������������������
<jmx_hoge2:Humidity>14.5</jmx_hoge2:Humidity></jmx_hoge2:TemperaturePart>���������������
<xsd:sequence><xsd:element name="Temperature" type="xsd:float" minOccurs="0"
maxOccurs="1"/><xsd:element name="TemperatureQC" type="xsd:float" minOccurs="0"
maxOccurs="1"/><xsd:element name="Humidity" type="xsd:float" minOccurs="0" maxOccurs="1"/><xsd:any minOccurs="0" maxOccurs="unbounded" namespace=”##other”/></xsd:sequence>���������������������������������������������
�������������������������

バージョンアップにおける XML インスタンスと XML スキーマの番号管理<jmx_hoge:TemperaturePart><jmx_hoge:Temperature>14.5</jmx_hoge:Temperature><jmx_hoge_add01:Humidity>14.5</jmx_hoge_add01:Humidity></jmx_hoge:TemperaturePart>

XML������������
���������������
���������������
��������������

jmx_hoge

Ver1.01

jmx_hoge_
add01

�

�

����

��

��

��

��

����
����
���

79.5-6��������������������������������
������������������������������������
��������������

報

����

<jmx_hoge:TemperaturePart><jmx_hoge:Temperature>14.5</jmx_hoge:Temperature></jmx_hoge:TemperaturePart>����������
<xsd:sequence><xsd:element name="Temperature" type="xsd:float" minOccurs="0"
maxOccurs="1"/><xsd:any minOccurs="0" maxOccurs="unbounded" namespace=”##other”/></xsd:sequence>�時Ver1.00

jmx_hoge

Ver1.00

jmx_hoge����������������������

����

候

�
�
�
�
�
�
�
�

�
�
�
�
�
�

��

��

測
2012

測

候

時

報

79.5-6<MeteorologicalInfos type="�������"><MeteorologicalInfo><DateTime significant="yyyy-mm-ddThh">2010-02-27T09:00:00+09:00</DateTime><Item><Kind><Property><Type>����</Type><Text type="������">����(�������)</Text><Text type="������">����(�������)</Text><Text type="�������">0�0.5m ��</Text></Property></Kind><Area><Name>�����</Name></Area></Item><Item><Kind><Property><Type>����</Type><Text type="������">����(�������)</Text><Text type="������">����(�������)</Text><Text type="�������">0.5�1.0m ��</Text></Property></Kind><Area><Name>�����</Name></Area></Item><MeteorologicalInfos type="����"><MeteorologicalInfo><DateTime significant="yyyy-mm-ddThh:mm">2010-02-27T09:00:00+09:00</DateTime><Item><Kind><Status>��</Status><DateTime type="��">2010-02-27T09:00:00+09:00</DateTime><Property><Type>��</Type><WaterLevelPart><jmx_eb:WaterLevel type="��" unit="m"condition="��">143.00</jmx_eb:WaterLevel><jmx_eb:WaterLevel
type="���">2</jmx_eb:WaterLevel></WaterLevelPart></Property></Kind>2012<Kind><DateTime type="1 ���">2010-02-27T10:00:00+09:00</DateTime><Property><Type>��</Type><WaterLevelPart><jmx_eb:WaterLevel type="��" unit="m"condition="��">144.80</jmx_eb:WaterLevel><jmx_eb:WaterLevel
type="���">3</jmx_eb:WaterLevel></WaterLevelPart></Property></Kind><Kind><DateTime type="2 ���">2010-02-27T11:00:00+09:00</DateTime><Property><Type>��</Type><WaterLevelPart><jmx_eb:WaterLevel type="��" unit="m"condition="��">145.00</jmx_eb:WaterLevel><jmx_eb:WaterLevel
type="���">4</jmx_eb:WaterLevel></WaterLevelPart></Property></Kind><Kind><DateTime type="3 ���">2010-02-27T12:00:00+09:00</DateTime><Property><Type>��</Type><WaterLevelPart><jmx_eb:WaterLevel type="��" unit="m"condition="��">144.80</jmx_eb:WaterLevel><jmx_eb:WaterLevel
type="���">3</jmx_eb:WaterLevel></WaterLevelPart></Property></Kind><Station><Name>�������</Name><Code type="�����">00000</Code><Location>����������������
</Station></Item>

第 24 図 指定河川洪水予報のバージョンアップにおける変更案 1
とりうる値の変更のみで辞書の変更を伴わない方法．

から，影響が少ないのであれば，電文の様式は可の管理に関する留意事項として，次の 2 点が挙げ

能な限り理想に近い形式が望ましいとの方針によられた．

り，辞書の変更を伴うメジャーバージョンアップ
として対応することとなった．

一点目は，予報課が示した案 2 で，共通辞書（基本要素）の type.WaterLevel 型（第 25 図の A 部分）

この方針に基づき，共通辞書（基本要素）と個には，他の基本要素にない level 属性と difference

別辞書（気象分野）の改変を含むバージョンアッ属性が追加されているが，共通辞書（基本要素）

プの方法について検討を行った．この中で，指定は汎用的に使うことを目的とするため，属性値に河川洪水予報だけでなく，今後のバージョンアッ

関しては原則として他の要素と共通とするというプの際にも留意しなければならない一般的な辞書方針である．

－ 120 －

測

候

時

報

79.5-6<MeteorologicalInfos type="�������"><MeteorologicalInfo><DateTime significant="yyyy-mm-ddThh">2010-02-27T09:00:00+09:00</DateTime><Item><Kind><Property><Type>����</Type><FloodAssumptionTable><Area><Name>���</Name><Code>0000000000</Code></Area><FloodAssumptionPart><FloodAssumptionArea>�����</FloodAssumptionArea><AttainmentTime>����(�������)</AttainmentTime><AssumptionFlood>0�0.5m ��</AssumptionFlood><AttainmentDeepestTime>����(�������)</AttainmentDeepestTime></FloodAssumptionPart><FloodAssumptionPart><FloodAssumptionArea>�����</FloodAssumptionArea><AttainmentTime>����(�������)</AttainmentTime><AssumptionFlood>0.5�1.0m ��</AssumptionFlood><AttainmentDeepestTime>����(�������)</AttainmentDeepestTime></FloodAssumptionPart><MeteorologicalInfos type="����"><TimeSeriesInfo><TimeDefines><TimeDefine timeId="1"><DateTime>2010-02-27T09:00:00+09:00</DateTime><Duration>PT1H</Duration><Name>��</Name></TimeDefine>2012<TimeDefine timeId="3"><DateTime>2010-02-27T11:00:00+09:00</DateTime><Duration>PT1H</Duration><Name>����</Name></TimeDefine><TimeDefine timeId="2"><DateTime>2010-02-27T10:00:00+09:00</DateTime><Duration>PT1H</Duration><Name>����</Name></TimeDefine><TimeDefine timeId="4"><DateTime>2010-02-27T12:00:00+09:00</DateTime><Duration>PT1H</Duration><Name>����</Name></TimeDefine></TimeDefines><Item><Kind><Property><Type>��</Type><WaterLevelPart>A<jmx_eb:WaterLevel type="��" unit="m" refID="1"
level="2" condition="��"difference="��">143.00</jmx_eb:WaterLevel><jmx_eb:WaterLevel type="��" unit="m" refID="2"
level="3" condition="��">144.80</jmx_eb:WaterLevel><jmx_eb:WaterLevel type="��" unit="m" refID="3"
level="4" condition="��">145.00</jmx_eb:WaterLevel><jmx_eb:WaterLevel type="��" unit="m" refID="4"level="3" condition="��">144.80</jmx_eb:WaterLevel></WaterLevelPart></Property></Kind><Station><Name>�������</Name><Code type="�����">00000</Code><Location>����������������
</Station></Item>

第 25 図 指定河川洪水予報のバージョンアップにおける変更案 2
辞書の変更を伴う方法．

二点目は，独自の拡張を行っていることに対す変更の内容が決められ，部会においても運用指針

る留意事項である．「以上」や「未満」の表現はの「メジャーバージョンアップ 1（名前空間を継異常天候早期警戒情報を参考にできること，○時

続）」で対応することが承認された．この結果，

間後というのは W3C XML Schema のビルトイン

共通辞書（基本要素）と個別辞書（気象分野）のデータ型における datetime 型や duration 型で示す

バージョンは「1.1」とし，これに併せて共通辞べき情報であるなど，既に同様の内容の表記を行

書（ヘッダ部）のとりうる値の追加も行われ，こっている情報がある場合は，共通の構造や基底型

ちらのバージョンは「1.0c」とした．

を使うべきとの意見である．
上記のような議論を経て，指定河川洪水予報の－ 121 －

測

候

時

報

79.5-6

その他の議論＊

11
11.1

2012

するアプリケーションが適切に作成できるか

xsi:nil の取り扱い

どうかの確認ツールとなる．

“xsi:nil="true"”の取り扱いにおいては実装間のなお，利用者に提供するのは辞書ファイルのみ差があり，同記述がある要素の属性値が取得できとし，XML スキーマについては提供しないことる実装とできない実装がある．W3C XML Schemaを想定していた．これは XML スキーマが XMLの仕様 [7] の Primer（入門書）編 2.9 項によると「こインスタンスに一対一対応する原則に対して，「厳の nil の仕組みは要素値のみに適用され，属性値

密な辞書」に対応する XML スキーマを提供するには適用されない．“xsi:nil="true"”の要素は要素

ことは，XML インスタンスに対応する XML ス

内容を持つことができず，属性値は持つことがで

キーマが複数存在することとなり，原則が崩れてきる．」（原文は英語）となっている．しかしなが混乱することを回避するためである．

ら，.NET Framework 2.0 で は「XML ド キ ュ メ ン

このように「厳密な辞書」の作成・提供を前提

トをオブジェクトに逆シリアル化するとき : xsi:に検討を進めていたところであるが，以下の問題

nil="true" と指定された XML 要素が存在すると，があった．

XmlSerializer クラスでは，対応するオブジェクト

・「厳密な辞書」の有効的な記法の策定が困難．

に null 参照が代入され，他のすべての属性は無「厳密な辞書」は「ゆるい辞書」の部分集合視されます．」[14] となっており，また動作試験となるように記述する必要があるため，それによっても取得できないことが確認できている．

を確認しながら辞書の作成を行うこととなる

その他，JDK1.6[15] 付属 xjc[16] でも同様に属性が，そのために有効なエクセルシートの記法

値が取得できず，逆に DB2[17] ではできること

等について何種類か試作したが，現実的に利を動作確認した．このように，仕様では取れるこ用可能なものが作成できなかった．

とが正しいにもかかわらず，一般的なソフトウェ

・相互の辞書のバージョン管理が困難．

アにおいて実装の動作が異なることが判明したこ「厳密な辞書」の改定に当たっては必ず「ゆとから，xsi:nil を利用する要素においては他の属

るい辞書」の最新バージョンに対して部分集性をとらないこととしている．

合となるように策定する必要があるが，マスターとなる「ゆるい辞書」のバージョンが上

11.2

厳密な辞書

がった場合に，旧バージョンから新バージョ

気象庁 XML としてまとめた辞書は，構造とンへの置き換えを適切に行うための手法が検XML スキーマの共通化を目的の一つとしている

討できなかった．

ことから，個別の情報種別単位としてみると，自・辞書間，スキーマ間の差分検出が困難．

由度の幅が広すぎて業務アプリケーションの設「厳密な辞書」と「ゆるい辞書」の間で，適計・実装上は不要となる部分も多い．このため，切に部分集合となっていることを確認する作共通化した「ゆるい辞書」ではなく，個々の情報業が必要となる．これについては辞書の記法

種別に応じて，いわば共通化した辞書の個別運用により確認する方法もあるが，同様に XMLを示す「厳密な辞書」の作成について検討を行っ

スキーマ間でも部分集合となっているかを確た．この「厳密な辞書」を公開する利点について認できることが望ましい．そのための一つのは次のとおりとなる．

方法としては XML スキーマ間で差分を検出

・利用者から見ると各情報種別の運用が一目でする方法の開発となる．また，XML スキー

判別でき，適切な業務アプリケーションの開マ間での差分検出が可能となれば，辞書の記発に役立つ．

法に拠らず最終確認を XML スキーマ間で行・作成者から見ると電文の設計図であり，作成* 第 11 章

杉山， 第 11.4 節

うという手法もとれる．このため，XML ス

竹田・杉山－ 122 －

測

候

時

報

79.5-62012

キーマ間での差分検出の方法を検討してみた

気象警報・注意報，緊急地震速報，津波警報を中が解決に至らなかった．これは XML スキー

心とした検討であったため，ヘッダ部の「Warning

マ同士，若しくはオブジェクト化した際の要素」（現在の Information 要素）において，Kind

Document オブジェクト同士として，比較す要素に対応する警報事項としての「何が」と，る手法が検討できなかったからである．

Area 要素に対応する対象地域としての「どこに」このことから，「厳密な辞書」の作成を断念し，が明確となっていた．しかしながら，その後ヘッ

気象庁 XML における個別情報種別における運用

ダ部については仕様にあるとおり「防災上重要なについては解説資料の形にて詳細な仕様・運用を警報等においては，有効期間（いつ），警報事項

提示している．もし，上記の差分の検出方法が可の種別（何が），対象地域（どこに）を入手する能となれば，「厳密な辞書」による管理手法につことが可能」となり，警報等の防災上重要な情報

いて改めて検討しても良い．

ではない場合はヘッダ部への情報の記述が必須ではなくなった．そこで対象となる地域情報を明確

11.3

化させる手法として 3 通りの提案がされた．

タグ付けの分解能

内容部においては各情報の特徴を生かすために，全体的な方針・理念の整合を必ずしも優先していない．このため，各情報や要素のタグ付けの仕方に粒度的な違いが見られる．例えば時刻的な概念の日本語において，開始時刻と終了時刻を別

案1

ヘッダ部に電文が対象とする地域を示す

TargetArea 要素を加える．
案2

内容部も含めて地域情報が必ず一意となるような形式にて記載する．
案3

編集官署名等も踏まえたオフライン的情の要素として規定するか，それとも時間情報とし報も含めて利用者側が総合的に判断する（現て一つの要素に「○○から××まで」とまとめて状のまま）．

しまうかの差などである．これら粒度的な分解能

案 1 については，単純に不要であるという意見については，情報を直接検討している担当者によが多く出た一方で，震源要素など地域情報の粒度っても認識が異なることから，一貫性をとるのが判断が困難かつ意味をなさないという意見もあっ

難しいところであるが，基本的には次のように考た．また，案 2 は旧形式府県天気予報（独自形式）える必要がある．

において利用している「広島県 / 府中市」や「千・プリミティブ型，準プリミティブ型として機葉県 / 北東部」のような「/」文字を分割記号（デ械的に値が取得できるのであれば，粒度は細リミタ）とした形式を用いることにより，地域情

かくしても良い．

報として必ず一意に定まるような形式を採用する

・そうでない場合（日本語記述等）は利用の仕こととして，内容部だけでも全国から地域が一意方によるが，日本語では用途が表示に限定さに定まることを目指したものである．しかしながれるので，余り粒度を細かくしない．

ら，これも冗長的となり不要であるという意見がXML 設計全体にいえることであるが，構造を出た上で，更に XML として要素を直接読み取れ検討するにあたっては，必ず利用スタイルを意識るメリットを使わず分割記号により解釈するといし，作成者側の視点よりも利用者側視点で考える

う理念の逆行性への批判，純粋に作成処理が複雑必要がある．また，その際にも「自分がレイアウになるといったデメリットが意見としてかなり多トするのに必要な情報」といった個人的な必要性

く出た．

ではなく，重複を省いて単純化することを意識す

これらの議論により，結果として案 3 のとおり，

る．特にデータ構造においてはデータベース設計

観測情報等の防災上重要ではない一部の情報につ技法における正規化の考え方も重要となる．

いては，管理部の編集官署名等の情報をオフライ
ン情報として判断した上で，地域情報を判断す

11.4

地域情報の一意性

ることとなっている．XML コンソーシアムから，

気象庁 XML 仕様ドラフト（Ver0.1）の作成時は，－ 123 －

オフラインでの判断が有ること自体は否定されな

測

候

時

報

79.5-62012

いとのコメントがあることからも，決して手法とを付ける必要がある．例えば市町村単位でコードして不適切なわけではないが，この方法について値を入れるところに，細分区単位のコード値が入は XML 的ではないこともあり，各電文同志の調れられないようにするような機能などである．

整が付くのであれば，将来的に整理・検討がされ最後にこのような簡略形式の作成・発信というても良い部分と思われる．

代替運用についてはめったに行わないことから作業手順上の問題を起こしやすいということであ11.5

システム障害時の対応（運用指針 4 章）

る．防災情報の作成システムとしては必ず地域冗（1）気象庁 XML の作成障害時の運用について

長性も含めてシステム構成を行っていることか

通常時に気象庁 XML の各電文を作成しているら，代替発信を行うような事態の想定はソフトウ

システムが障害となった際，当該システムによる

ェア不具合程度である．このことからも，代替運

バックアップ手段で対応できない場合は，他のシ用は可能な限り実施しないように，ソフトウェア

ステム・手順により気象庁 XML 電文の作成を行の動作確認・慣熟運用，ソフトウェアバージョン

うこととしている．このため，通常時の気象庁

アップ時の版管理・運用については慎重に実施す

XML と比べて簡略的な形式として発信する．

べきと考えている．

このような運用を定めるにあたっては 3 点注意（2）利用者システム・伝送システム等の障害時すべき点がある．

の運用について一つ目は部外に対して通常時には取得できることを説明している要素が，簡略的形式では存在し利用者システムや伝送システム等の障害時，つない・出現しない場合である．これは主として量まり気象庁側で各電文の作成は問題なくできてい

的・時間的な見積りをするために必要な値が入手るが，利用者側にオンラインで配信できない場合，できないこととなり，防災業務等において大きな他のオンライン手段をバックアップ手段として利影響を与えるのみならず，値があることを信用し用するか，FAX 等非オンライン機能によることて作成したシステムにおいては，動作不良の原因になる．このような場合，従前のかな漢字電文でとなりかねない．このため，まずは運用指針におは，例えば地火山情報ではコード行とその内容をいて全体方針として簡略形式の発表の可能性を示

示すかな漢字本文の両方が付いていたため，障害唆しており，各個別の電文においては実際にどの時等でも電文をそのまま印刷するだけで人間可読

ような簡略化を行うかを詳細に説明することとし

形式な情報提供ができていた．また，
このことは，ている．なお，そもそも省略してよい値であれば平時でも利用者におけるコード行の解釈・処理が必然性も少ないし値があることを信用できないと適切かどうかの確認を，同じ電文の本文部分で行いう観点もあることから，利用者における利用度

えていたことを意味する．一方で，XML 技術でを下げる結果となる懸念もある．

はスタイルシート（XSLT）を利用することによ

二つ目として XML 形式は機械可読形式であり，り XML から単純なテキスト文書を作成することは平易である．

事実上のバイナリーデータに近いものであるという認識を持つ必要がある部分である．つまり，これらの事情から，全内容をそのまま出力する

XML はテキストエディターでも編集できること

単純なスタイルシートを作成し，庁内及び利用者から，安易に書き換えたり作成したりしそうになに配布することとした．仕様は以下のとおりであるが，処理は機械的に実施されることからわずかる．

な手違いが利用者システムの誤動作へとつなが・ある事項・要素に対してコードと日本語と両方あるならばコードは不要とする．

り，発信できない被害から多数の利用者システムの誤動作という二次被害を生みかねないことであ・情報量として XML に含まれている内容が全る．このため，XML の代替作成機能は必ず各電て含まれるようにする．これは取扱いが分か

文仕様に従って作成されるように制限や支援機能らない値を作らないように網羅するためであ－ 124 －

測

候

時

報

79.5-6

る．

2012

た．また，辞書においてネスティングが多段階と・冗長的な修飾等は不要とし，着実な動作を目なると記述が困難となり，また XML スキーマの指す．改行・空白 1 文字等を利用して要素・自動作成上も利点がないこと，型の再利用・共通

内容の区切りを行うが，インデントや列位置化を目指していたこと，辞書の可読性も重視したを併せる必要はない．また HTML の場合はことから，出力される XML スキーマはベネチア

レイアウト情報がなくなっても理解できるよ

ン・ブラインド型（第 4.2 節参照）となるようにうにする．

した．参考までに開発環境・工数は第 13 表のとおり．
＊

なお，本ツールについては職務上作成したソフ

XMLDic2Schema

トウェアでもあることから著作権等の権利は気象（1）ツールによる管理手順

庁に帰属する．その他の利用条件等については明XMLDic2Schema ツ ー ル は，XML 要 素 辞 書 を確としておらず，庁外機関・団体等への提供は禁12

XML 関連ツール

12.1

XML スキーマに変換するツールとして作成した．

止している．

これは，気象庁の各情報担当職員は，その情報をどのように扱うべきか等の検討にあたってはエキ（3）開発上の問題点

スパートであっても，必ずしも IT のエキスパー

ツールの開発途中で大きく二つの問題点が発生

トではなく，今後何年もの XML スキーマの管理した．

を考えると，その時々の担当者に XML スキーマ

一つはとりうる値の列記に当たり，辞書上は値の記述方法を覚えて対応してもらうよりは，管理を全て見せたいが XML スキーマ上は省略したい

しやすいエクセル形式での辞書を XML スキーマ場合があることと，そもそもとりうる値に“*”に変換するツールを作成して担当者に配布した方を許容すると値の妥当性確認にならないという問が，管理上適切であると判断したからである．ま題，もう一つは任意の要素を許容する W3C XML

た，エクセル形式からツールによる作成というschema の any 要素において，出現する要素の属手段に基づいた記法の制限を掛けることにより，する名前空間指定（namespace 属性）を「任意」

XML エキスパートによる難解な XML スキーマ（“##any”）としてそのまま出力するとこれも妥当の作成等を抑止することもでき，今後の運営管理

性確認にならないという問題である（第 4.3 節（4）上も平易になるといった利点もある．

項参照）．

このため，電文担当者においてはエクセル形式

いずれの問題においても，電文担当者等の担当

で記法に従い辞書を作成・管理し，それらはツー

者が動作確認をする際には厳密に妥当性確認をしルにより XML スキーマに変換するものとして，担当者における管理や IT 知識の軽減を目指すと
ともに，本質的な辞書の構造等の検討・理解に力を注いでもらえるようにした．
（2）ツールの開発
ツールの開発にあたっては，XML コンソーシ
アムから辞書の書き方の一例を提示していただいたので，これを参考にした上で，XML スキーマ生成のためのプログラム上のアルゴリズムを検討し，これと照らし合わせて辞書の書き方を作成し* 第 12 章

第 12.1 節

杉山， 第 12.2 節

第 13 表XMLDic2Schema ツール開発環境と工数������������������版の開発
開発環境
・JDK1.4.2
・Eclipse3.0
・Jakarta poi 3.1
・Apache Xalan-J 2.7.1 (serializer.jar)
工数・完成状況・設計2人日 作成5人日 試験2.5人日
・コード：2000行弱・スタンドアローンのjarファイルとしてリリース

平原， 第 12.3 節～第12.4XMLDic2Schemaツール開発環境と工数
節 長谷川，第 12.5 節 竹田
第13表－ 125 －

測

候

時

報

79.5-62012

たいが，部外に対して仕様提示する場合には想定

データベースのように自分の知りたい情報を抽出した記法に従って出力したいという相反する問題

したり，ソートが可能であることも検証できた（第であることから，ツールにスイッチを作り，妥当

26 図）．

性確認のために厳しく出力するモードと，部外向けに出力するモードとを切り換えられるようにし

12.3

た．このツール仕様により，部外向けとして想定

気象庁 XML 各電文の構造の検討やサンプル電した記法については，結果として第 5.2 節のとお

文作成の作業を支援するため，出現要素の構造のりに XML スキーマを出力することになる．

みを解析・保持して，要素値は，出現順を問わず，

XML 出現タグ縮退表示ツール

なお，このスイッチの切替えにより作成される構造上の相当位置に一括して格納・表示するといXML スキーマが異なることから，生成した XML

う加工ツールを，Web で利用する CGI の形で用スキーマの利用については確認用，部外提供用等

意した（第 27 図）．これは，以下の場面で有用での適切な管理が必要となる．このためにも XMLあった．

スキーマに出力時のスイッチパラメーター等の出・最初に構造を検討する段階では，検証用の力を行う機能も付けている．

スキーマも存在していない．一方，気象庁
XML の実際のインスタンスは観測値などの（4）辞書の書き方

表現を中心に，同じ構造が繰り返し現れ，全このように，XMLDic2Schema ツールに併せて体として大きな量になることが多い．スキー

辞書の書き方は策定された．書き方（辞書記述要

マもない状況で，長大になりがちな実際に近領の抜粋版）を付録する．

い電文を検討・作成する作業において，構造の概観や簡便なチェックに用いることができ

12.2

防災情報 XML ビューア

た．

気象庁 XML の実用性を検証するため，XSLT・サンプル電文を作成する段階では，電文を生を使った防災情報 XML ビューアを作成した．ま成する処理系は存在していない．また，大量ずは紫外線観測データを対象に，管理部，ヘッダのサンプル電文を人手による作業で作成する部，内容部を表形式で表示するものを作り，次ににあたっては，必ずしも全ての作業環境にス

グラフ表示を作った．特別なソフトをインストー

キーマ検証の処理系を用意することができなルする必要がなく，インターネットエクスプロー

い．こうした状況において，手軽に利用でき

ラー等のブラウザさえあれば，視覚的に説得力のるチェックツールとして機能した．

ある表示が可能であることが検証できた．また，－ 126 －

測

候

時

報

79.5-62012�����������

�����������

�����������

�����������

����������

����������

�������������

�������������

������
第 26 図����

防災情報 XML ビューアの表示例

�26� ����XML���������

－ 127 －

測第 27 図

12.4

候

時

報

79.5-62012

XML 出現タグ縮退表示ツールの表示画面挙げられる．例えば「地方 1 か月予報」のかな漢

XSLT サンプル（1）XSLT サンプルについて

字電文には，以下のような部分がある．

平成 24 年 3 月から提供している「全内容出力
スタイルシート」（第 11.5 節（2）項参照）の提…

供に先立ち，気象庁 XML サンプル電文提供開始＜予報の対象期間＞

後の早い時期から，利用の一例を示す目的で「従1 か月：3 月 8 日（土）～ 4 月 7 日（月）…
来のかな漢字電文に近い表現を再現する」等の�27�
XML�����������������XSLT サンプルを一部の電文について用意した．
XML 電文においては，これに相当する情報を

このサンプルの用意にあたっては，利用者の確認作業のために，当時広く実装が普及している仕様，

以下のように示している．

すなわち XSLT 1.0 で用意することが重要と考えた．このため，EXSLT 等の拡張も利用していない．

…
<MeteorologicalInfo><DateTime significant="yyyy-mm-dd">2008-03-（2）実装上の問題「拡張なしの XSLT 1.0 で従来のかな漢字電文を

08T00:00:00+09:00</DateTime>

再現する」という実装を用意するにあたっては，<Duration>P1M</Duration>

いくつかの困難に直面した．その一つに，日付計…

算に係る機能が XSLT 1.0 に欠如していたことが－ 128 －

測

候

時

報

79.5-62012「地方 1 か月予報」は当該地方の向こう 1 か月

前者は元来，機械処理による生成を想定して作ら間の予報を伝えるものであって，「予報期間の終れたものではない．XSLT を用いて XML から平

わりが何曜日に当たるか」を伝えることはこの電文を生成することは簡単ではあるが，上記の例に

文の目的には含まれておらず，こうした部分は利見られるように，従来のかな漢字電文を再現する

用の便を想定して付加したものに過ぎない．したことには，単に「平文を生成する」こととは全くがって，XML 電文は予報期間の先頭と予報期間異なる困難があった．季節予報関係電文につい（この場合は「向こう 1 か月」）を持てば十分で，て従来のかな漢字電文を再現する XSLT サンプル

予報期間終わりの曜日を示したい場合には加工に（「1 か月」「3 か月」など数種類あるが，それらでよって表現上付加されるような利用形態が望まし共通のもの）は，1500 行を超える規模となった．

い．

一方，新しい応用例として第 28 図のような図にしかし，ある日付から「向こう 1 か月の終わり

よる表示の生成も試みたところ，その XSLT サンの日付」を求めることは簡単ではない．「1 か月」

プルは従来のかな漢字電文を再現するものよりもの日数は月によって異なるためである．また，期むしろ単純で，容易に実装できた．

間先頭の日付によっては翌月に対応する日付がな

幸い XSLT 処理系の普及に係る事情はここ数年

いことがあるため，例えば 3 月 30 日，3 月 31 日

で大きく変わり，本稿執筆時点（平成 24 年 10 月）のそれぞれを起点とした「向こう 1 か月の終わり」

では日付計算の可能な XSLT 処理系も広く普及しはともに 4 月 30 日になる，といったケースもあて，ここに示したような例が問題となるような状

る．更にその「曜日」を求めるためには，特定の況ではなくなっているようである．しかしながら，日付からの通算日数を扱う日付計算が必要にな

こうした問題に直面したことで従来のかな漢字電る．XSLT 1.0 にはこうした機能がなかったため，

文と XML 電文で見られた大きな隔たりの存在が特に期間終わりの曜日 1 文字のためだけに，300

明らかになったことの意味は小さくない．それは，行程度にわたる日付計算処理を実装する必要があった．
また，こうした処理を記述するプログラミング
言語として XSLT を見た場合，いくつかの極めて特徴的な性質がある．例えば「変数」と称するものは，処理の過程で値を変更できない．この特徴
は，いわゆるループ変数を利用する繰り返し処理が記述できないことを意味する．手続き呼出しに伴う仮引数への値設定は許されるので，繰り返し処理は手続きの再帰呼出しを利用する以外にない．このように，気象庁において広く利用されているいくつかの手続き型言語とは大きく異なる記述が必要だったことも作業を難しくした要因になった．
（3）新しい表現方法との比較
従来のかな漢字電文と XML 電文では，前者は利用者の便も視野に入れた完成品として考えられたもの，後者は機械処理による加工による幅広い利用を想定し情報の本質部分を抽出するように考第 28 図 気 象 庁 XML か ら 色 分 け の 図 を 作 成 す る
XSLT サンプルの適用例

えられたものと，その目的に違いがある．また，－ 129 －
�28� ���XML������������XSLT���������

測

候

時

報

79.5-62012

我々が伝えるべき情報の目的と手段，またそれにドし，インストールすれば，コマンドプロンプト

応じた表現のあり方について，改めて考えるべき上で次のように妥当性検証を実行できる．

観点があることを示唆するものである．
AltovaXML
12.5/validate XML 電 文 フ ァ イ ル jmx.

xsd

妥当性検証等に利用したツール（1）The Oracle Multi-Schema XML Validator
The Oracle Multi-Schema XML Validator（ 気 象また，スタイルシートによる変換も可能で，コ

庁防災情報 XML フォーマットの作成を行っていマンドプロンプト上で次のように XSLT による変た平成 20 年当時は「The Sun Multi-Schema XML換ができる．

Validator」の名称であった）は，執筆時点（平成24 年 10 月）で次の URL から入手できるコマン

AltovaXML -xslt1 スタイルシート

ドラインでスキーマによる妥当性検証を行うこと-in XML 電文ファイル -out 変換後ファイルができる検証ツールである．
AltovaXML は，XML コンソーシアムから紹介されたツールで，（1）項で紹介した MSV ととも

http://msv.java.net/に気象庁 XML の妥当性検証に利用した．また，インストールと実行も簡単で，入手した zip フ

サンプルスタイルシートの動作確認でも利用した．

ァイルを任意のフォルダに展開し，コマンドプロ
ンプト上で msv.jar に対して次のように java を実（3）XMLEditor.NET

行すれば妥当性検証ができる．

XMLEditor.NET は 執 筆 時 点（ 平 成 24 年 10月）で次の URL から入手できる XML エディタ

java -jar msv.jar jmx.xsd XML 電文ファイル

で，スキーマによる妥当性検証やスタイルシート
XMLDic2Schema と合わせて利用することで，（XSLT）による変換も行える．

辞書による構造の共通化の作業効率が格段に向上した．

http://www.xmleditor.jp/（2）AltovaXML

XMLDic2Schema ができるまでは，個別辞書（気AltovaXML は執筆時点（平成 24 年 10 月）で象分野）の XML スキーマをテキストエディター

次の URL から入手できるスキーマによる妥当性

で作成していたが，XMLEditor.NET の XML スキ

検証やスタイルシート（XSLT）による変換等がーマ生成機能によりサンプル電文から自動生成行える多機能な XML ツールである．

される XML スキーマを利用することで，効率的に XML スキーマの作成を図っていた．また，妥

http://www.altova.com/jp/altovaxml.html

当 性 検 証 に つ い て も，MSV や AltovaXML の ほか，XMLEditor.NET でも利用できる．更に，ス

上 記 URL か ら AltovaXML 2013 Community

タイルシートを利用して HTML へ変換する場合

Edition（執筆時点）のインストーラをダウンロー

は，ブラウザ機能によりすぐに確認できるため，
XMLEditor.NET を効果的に利用していた．

－ 130 －

測

候

時

報

79.5-62012

他仕様との関係について＊

13
13.1

も含めた合意が必要となる．

Common Alerting Protocol

・防災は主として国内体制によることから，国Common Alerting Protocol (CAP)[18] とは，防災・際規格が万能とはいえない．

治安等の公衆安全に関わる情報を伝達するため

しかしながら，CAP は国際規格であり，国内の XML プロトコル（フォーマット）であり，電における公衆安全における情報フォーマットとし子商取引やウェブサービスに関する標準化団体て今後利用される可能性もあるから，CAP とので あ る OASIS(Organization for the Advancement of

互換性については XML コンソーシアムの協力のStructured Information Standards) に よ り 仕 様 が 承下，検討を行い，以下のとおり整理された．

認されている．公衆安全ということで，気象分
野のみならず，テロや原子力事故等も考慮した

・気象庁 XML は CAP の各要素に対する変換は容易である．

全ての公衆安全に関する情報交換を想定してい・気象庁 XML から CAP への変換により情報がる．WMO では，全ての危険に対するあらゆるメ

大きく失われることから，元の情報への参照

ディア利用した伝達を考慮すると，CAP は望まが必要である．

しいフォーマットであると考えており，各国の取個別の電文を元に確認してみても，構造や考えり組み等について，2008 年，2009 年，2011 年に方が大きく変わることから，変換ルールの策定に

計 3 回ワークショップを開催している（2006 年

は情報の専門家による知見が必要とはなるが，変には国際通信連合（ITU）主催のワークショップ

換可能性についてはおおむね問題ないと考えられに WMO が参加という形式でも実施）．当庁ではる．このことから，気象庁 XML は CAP に変換

2008 年と 2011 年に企画課より気象庁 XML の取可能であり，互換性の観点から将来的におけるり組みと CAP との関係を同ワークショップにて

CAP への対応は問題なく可能であると考えてい

報告している．[19] [20] また，これまでの取り組

る．

みをより一層進めるため，2012 年に同じく WMO

なお，RSMC 東京（Regional Specialized Meteo-と ITU，OASIS により緊急警報政策ワークショ

rological Center：地区特別気象センター）におけップが開催され，当庁の緊急警報の伝達に関するる CAP への取り組みとして，台風アドバイザリ

取り組みについて，参事官より紹介した．[21]ーの CAP 版について，検討を行っている．

CAP は気象庁 XML へ取り組み始める段階で既に仕様が策定されていたことから，当初より

13.2

その他のフォーマット仕様

XML 化にあたっての仕様候補として検討してい気象分野における XML フォーマット関連としたが，次の理由により CAP 仕様は不採用とした．

て，公衆安全分野から ISO/TC 223（社会セキュ

・既に防災気象情報としての詳細化が進んでおリティ）[22] では，Tactical Situation Object（TSO）

り，また高度なコード化による処理の自動化という XML フォーマットの制定を進めている．

を進めている中，CAP は平文的文書に防災

この TSO は，CAP が単純化を目指しているのに上のメタ情報を加えた構造となっていること

対して詳細化を進めており，どちらかといえば気から，日本国内の利用形態としては，むしろ象庁 XML の理念に近い．例を挙げると，コード情報量が減ってしまうことになる．

として原子力関係の状態を示す定義がされている・量的予想，時系列値の表現ができない．

一方で霧雪なども定義されており，かなり細かい・CAP の要素には公衆安全の立場から，「発生定義がされている．

確率」「深刻度」といった要素が必須となっ

ま た，GIS に 関 す る 標 準 化 団 体 で あ る Openているが，これらは気象庁単独で決められる

Geospatial Consortium（OGC）では観測値や測量

ものではなく，値の設定には公衆安全関係者

値の標準化として，Observations and Measurements* 第 13 章

杉山－ 131 －

測

候

時

報

79.5-6

2012（O&M）[23] を 策 定 し て お り， こ れ は ISO/DIS

治体や国における導入実績が多くあることから，

19156 にもなっている．WMO では O&M を推奨

気象庁 XML を SOAP 通信するための通信手順にすることとしており [24]，航空分野から利用を計

おいては，実装が相互互換するように通信手順仕画している．

様を定めている．

このように，気象分野に関するフォーマット仕様としては，国際的に様々な仕様が広まってきて

13.4

全国地方公共団体コード

いることから，CAP と同様に，引き続き気象庁

市町村単位の地域を示すコード表として，全国地方公共団体コード（JIS X 0402）がある．しかXML との関連を整理していく必要がある．

しながら，第 9.3 節でも示したとおり，一部行政
区分や島単位の地域区分が規定されていない．ま13.3 （財）全国地域情報化推進協会（仕様た，全国地方公共団体コードの改定と当庁の業務

1.8 項）（財）全国地域情報化推進協会（APPLIC）で上のコード表の改定において，日時が異なる場合

は，「地方公共団体の情報システムの抜本的改革もある．このため，全国地方公共団体コードをそや，地方公共団体内外の地域における多数の情報のまま利用することは行わず，一般的な市町村にシステムをオープンに連携させるための基盤の構

ついては全国地方公共団体コードの値をそのまま築を推進するとともに，地方公共団体で共通利用準拠して利用し，特殊な地域情報としての利用にが可能な公共アプリケーション（防災，医療，教ついてはその趣旨にのっとった形で気象庁独自の育等）の整備等の促進」を目的として「地域情報拡張を行い，全体的なコード表としては気象庁管

プラットフォーム」を推進しており，これらの共理の独自のコード表として運営している．

通通信基盤である「プラットフォーム通信標準仕渉外活動＊様」[25] や，業務ユニットである「防災業務アプ

14

リケーションユニット標準仕様」[26] の策定等を

気象庁 XML の策定や普及・利活用推進にあたっては，渉外活動を積極的に行ってきた．この活行っている．

動履歴について，以下にまとめる．

政府の高度情報通信ネットワーク社会推進戦略
本部（ＩＴ戦略本部）において平成 21 年 7 月 6 日に決定した i-Japan 戦略 2015[27] では，電子政府・

14.1

電子自治体の推進のため「地域情報プラットフォ

気象庁 XML の策定にあたっては，活動の要点

ームを活用した国及び地方の連携のための基盤シにおいて報道発表を計 4 回行った．気象庁においステムの整備等を促進すること．」としており，て，業務の変更ではなく電文形式の変更という情地方における標準化を推奨する観点からも，気象報技術的な立場において，報道発表を行ったのは

庁 XML 仕様において「地域情報プラットフォー

極めて異例（おそらく初めて）である．

報道発表

ム標準仕様書」及び「防災業務アプリケーション

最初の報道発表は，気象庁が XML コンソーシ

ユニット標準仕様」の利活用を推奨している．まアムと協力して気象庁 XML の策定に当たるとた，「防災業務アプリケーションユニット標準仕いう内容で平成 20 年 2 月 1 日に，その後気象庁様」においても『気象情報については，気象庁がXML のドラフト版を公開した上で，これに対す策定する「気象庁防災情報 XML フォーマット」

る意見募集 1 回目を同年 5 月 22 日に，同意見をを推奨する』こととしている．

踏まえた上でのドラフト版最終案を公開した上で2012 年現在，気象庁 XML の仕様そのものと同じく意見募集 2 回目を平成 21 年 1 月 30 日に，

APPLIC の各仕様との間で直接関係のあるものは

気象庁 XML 公開版の策定について同年 5 月 15ない．しかしながら，通信仕様においては地方自日に，それぞれ XML コンソーシアムと共同で報* 第 14 章

杉山－ 132 －

測

候

時

報

79.5-62012

道発表を行った．これら意見の募集に際しては，る動作検証を実施した．この結果も踏まえて 1 月

1 回目の募集で 21 名，2 回目の募集で 18 名の意に 2 回目の意見募集を行った．

見の応募があり，それぞれに対して気象庁 HP 上
で回答を行った．意見においては，データ構造等（3）平成 21 年度～利活用推進の年～に対する意見のほか，運用上の質問や資料の充実

XML コンソーシアムによる 2 回目の動作検証の要望，データ提供に関する質問等があった．この結果も踏まえて，5 月 15 日に気象庁 XML の仕のように，情報形式に際して一般からの意見を受様公開となった．気象庁では，仕様も固まったこ

け付けるのも異例であるが，更にそれを踏まえとからサンプルや参考資料等の充実を図り，利活て形式の修正や資料の充実を図るなど，気象庁用を推進することとして改組も行うが，XML コ

XML の策定や情報提供はこれまでの進め方と異ンソーシアムでもこれまでの活動成果を踏まえ，なり，広く門戸を開いて実施してきた．

各部会の活動テーマとして気象庁 XML の利活用を挙げる．XML コンソーシアムの SOA 部会，ビ

14.2

XML コンソーシアム

ジネス・イノベーション研究部会，関西部会，次

第 2.3 節に挙げているとおり，XML コンソー

世代 Web 活用部会，Web サービス実証部会ではシアムとは平成 19 年から非公式・公式な幾多の気象庁 XML 関連テーマとして第 14 表のとおり

協力関係の下，気象庁 XML の策定や利活用の推活動した．

進に協力していただいた．ここでは気象庁 XML

また，同年度に発足した XML 設計技術検討部の策定そのもの以外も含めた各年度の活動関係に

会では，気象庁 XML の CAP との互換性についついてまとめる．

て検討したほか，本部会にて実施された XML 設
計技術勉強会では気象庁職員も参加させていただ（1）平成 19 年度～関係模索の年～

き，担当者の技量向上に貢献いただいた．

平成 19 年度当初は気象庁も電文の新形式を

このように，XML コンソーシアムは，気象庁

XML 形式とすることがまだ確定しておらず，こXML の策定後もその利活用推進への協力を継続のような状況から XML に照準を絞りこむため，し，そして，平成 22 年 3 月 31 日をもって XML

XML コンソーシアムに連絡をとり，打ち合わせ

コンソーシアムは資産継承・後継組織設立準備団

や勉強会を通じて，双方ともに協力関係を模索し体である XML コンソーシアムコミュニティに組ていく．2 月には共同して気象庁 XML の策定を織を移行しつつ活動を終了した．

行うことについて報道発表するまでに至り，その後，XML コンソーシアムの組織内公募に応じた（4）平成 22 年度～先端 IT 活用推進コンソーシ

会員会社により結成された第一次気象庁 XML 策
定支援チームとの合同会議・勉強会を繰り広げてアム出発の年～
XML コ ン ソ ー シ ア ム コ ミ ュ ニ テ ィ を 経 て，
XML コンソーシアムはその軸足を先端 IT 技術にいく．

変えて，先端 IT 活用推進コンソーシアム（AITC）（2）平成 20 年度～仕様策定の年～へと移り変わった．気象庁でも継続して XML 関

前年度から継続している合同会議・勉強会の成係の助言を受けられることを期待しつつ，新たな果として，5 月 22 日にドラフト版の発表を行った．

防災情報の利活用技術についての検討を続ける．

これ以降も，第二次気象庁 XML 策定支援チームと継続して合同会議・勉強会を実施し仕様の策定

14.3を進めていく．10 月には辞書の作成も完了した

一般社団法人情報処理学会は IT の実務家のたことから，改めて XML コンソーシアムの組織内めのシンポジウムとして 2004 年度からシンポジ

公募に応じた会員会社で構成された気象庁 XML

ウム「ソフトウェアジャパン」を開催しており，

検証協力メンバーにより，各ソフトウェアにおけ2010 年の IT フォーラムセッションでは，XML－ 133 －

ソフトウェアジャパン 2010

測第 14 表

部会名

候

時

報

79.5-62012

XML コンソーシアムの各部会研究概要

タイトル

解説

SOA部会／ビジネス・
イノベーション研究部会

防災情報XMLの利活用モデル

関西部会

気象庁防災情報XMLを活用した住民情
上記部会によるサービスモデルの実装
報サービス実証実験

次世代Web活用部会

Webサービス実証部会

ゴール指向分析手法（i*法）を活用したサービス・モデリングと実装設計

雨の言い回しに関して地方毎に異なる雨量を対応させる方法としてセマンティック
Web技術を利用した実装の試み

雨量情報のセマンティック処理

気象庁防災情報XML配信サーバをクラウド
を 使 っ て 実 装 ， 気 象 庁 防 災 情 報 XML を
Google App Engine で 大 量 配 信 す る 一 手
気象庁防災情報XMLを用いた実証実験 法，大規模災害発生時における安否確認をどう行うか：防災ステーション編・
Android編

コンソーシアムが「気象庁防災情報 XML を使っ電文の入手方法以外の全ての情報はこのページにた実証実験～災害から住民一人ひとりの命を守まとめてある．

るために～」と題して，これまで気象庁 XML に

気象庁 XML の HP にはもう一つ目的がある．

関して研究・実装してきた各種成果を発表した．

気象庁 XML の XML スキーマには，名前空間に[28]

よる URL の示唆と，XML スキーマ内に記載されている XML スキーマの入手先情報が存在する．

14.4

実際にこれら URL をインターネットに接続され

出版物

これまでに気象庁 XML 関連では 2 件の主筆原ている端末のブラウザ上でアクセスしてみると分かるが，これら URL のアクセスにより気象庁

稿を掲載しているので，以下に紹介する．

XML の情報及び XML スキーマを取得できるよ
うにするためにも，専用のページを立ち上げてい気象庁総務部企画課（2009）：気象庁の情報システムとデータ標準化の取り組み．行政 & 情報システム，る．

第 45 巻，第 4 号，pp.82-85．
長田泰典（2011）：防災気象情報を一人一人に届けるた

まとめ＊

15

めに－気象庁防災情報 XML フォーマットの策定

15.1－．デジタルプラクティス，Vol.2, No.1, pp.4-11．

気象庁 XML の策定にあたって，適切に検討・反省点調整しておくべきであったと考えている反省点を
14.5

気象庁 XML の HP

気象庁 XML の情報提供においては専用の HP

以下に挙げる．これらについては，大規模な改定の際に考慮していただきたい．

を立ち上げた（http://xml.kishou.go.jp）．これは情報の内容ではなくフォーマットそのものを説明す（1）“jmx_mete:MeteorologicalInfo”要素の子るページとしては異例であるが，これも XML コ

要素“name”要素値

ンソーシアムより提案された「XML を使うので個 別 辞 書 と な る こ と か ら， そ の 値 の 運 用 にあれば情報はオープンに」という考え方の実施でつ い て は 各 電 文 検 討 担 当 者 に 任 せ て い た が，もある．基本的に気象庁 XML の電文そのものや“jmx_mete:MeteorologicalInfo” の 要 素 の 子 要 素* 第 15 章

杉山－ 134 －

測

候

時

報

79.5-62012“name”要素値については，気象予報関係の電文用の趣旨から逸脱していないか．現状定義のだけでもその値の意味するところが微妙に異なっ流用が可能だからといって，趣旨の違うものており，統一感のない値となってしまっている．

を利用すると本来混ぜてはいけない機能が同居することとなり，利用者側では既存処理の（2）一意キーの導入

方に例外処理を含めなければいけなくなるな

当初から一意キーの導入については検討していど，動作不具合や処理の複雑化が発生するこたが，現状の電文と同じく複数の情報要素を組みととなる．趣旨が違うのであれば，拡張・追合わせることにより対応することで良いと考えて加を検討すべきである．

おり，また，地域冗長化しているシステムにおい・例えば複数の情報間における同一構造部分のては，地域間での疎結合性等から一意キーの連携ある要素・属性を見比べた際に，追加を検討を考慮しづらい点もあり，この点も含めて情報内している要素・属性の値が異質とならないか．

容への一意キーの導入は行わなかった．しかしな

値の名詞・形容詞等の分類が違う場合，表示がら，その後検討を進めていくと，CAP では一値・参照値として利用する場合と検索条件と意キーを導入する必要があるなど，当庁業務とししての条件値として利用する場合など，利用ては不要であっても他の情報との連携の観点からの方向性が違う場合は共存させてはいけなはあった方が望ましい場合もあり，互換性を考い．

えると一意キーを導入すべきであったと考える．

・追加する要素・属性は不必要に冗長的なもの

また，WMO にて検討されている CAP の運用にとなっていないか．例えば作成者の判断でお い て，OID（ITU-T Rec. X.660 (2008) | ISO/IEC

HP 等への掲載の際に便利なだけの値が含ま

9834-1:2009）の利用が提案されている [29] ことれていないか（日付情報の単純な日本語表記

から，一意キーを導入する場合は情報体系整理の等）．XML は機械処理を前提としていること観点からも適切な検討を行う必要がある．

から，オフライン仕様で処理できるところを不必要に構造化する必要がない場合も多い．

15.2

気象庁 XML の策定と今後の管理・コード表の改変によって対応できるところを

気象庁 XML の策定にあたって，まずは XML

要素・属性の追加により対応としていないか．

コンソーシアムの協力による助言，提言，指摘等

本来いずれでも対応できる場合も多いが，情により，XML 技術的に適切な仕様となったと考報構造上の無理がなければ，影響の少ないコえている．また，庁内的にも事務局，WG，連絡ード表の改変・オフライン仕様により対応す

担当者等各関係者が気象庁 XML をどのようにしることが望ましい．

ていくのかという前向きな方向性の下，様々な提・不必要なコード化がされていないか．XML

案や議論を経て各防災情報や電文の持つ構造を適化により「文字」でもコード的に適切な取得切に反映した現状の仕様となった．

ができるので，コード化は後方互換，多数の仕様の策定以降は仕様の管理が必要となる．管理においては，これら策定の経緯や議論を踏まえデータ群，文字表現が困難等でなければ不要である．

た上で，仕様の更新等を行っていく必要があるこ

・必要な部分の一意性が保たれているかどうか．

とから，特定の電文内での整合性を確認するのみ

例えば，表示値が自由で可変であるのは当然ならず，全体的な整合性を確認する必要がある．

であっても，検索条件として値を読み取って本文書はそのための経緯をまとめたものである．

判別する部分の文字・コード値の定義が曖昧

管理担当者は，これらを踏まえた上で，以下の点な場合に，利用者は独自の解釈をして誤動作に着眼して管理していただきたいと考えている．

の原因となりかねない．また，コード表はあ・現状の各要素・属性，XML スキーマ上の型

くまでコード値と実社会における値やメタ情等について，新たな利用形態がこれまでの利報を結びつけるものであり，コード値を羅列－ 135 －

測

候

時

報

79.5-62012

するのものではない．あるコード値が実社会

技術部会，SOA 部会，ビジネス・イノベーショにおける何かと一意に結びつくようにコードン研究部会，次世代 Web 活用部会，及び関西部

表から参照できなければならない．

会にて協力頂いた各位には，実際のソフトウェア

XML は自由度が高い故に，改変に当たってはにおける気象庁 XML の適合性や利活用の実証実

バランス感覚が重要であると考える．フォーマッ験等により，気象庁 XML の実運用・活用に道筋

トの改変は利用者への影響度が大きいことから，を示していただいたと感じています．策定支援チ

特にスキーマの変更を要するようなバージョンア

ーム及び検証協力メンバーを第 15 表に掲載いた

ップは慎重にすべきである．とはいえ，不必要なします．また，田原春美様，遠城秀和様には気象改変は避けつつも，新たな情報構造上必要であれ

庁と XML コンソーシアムを強く結びつけるため

ば，影響が最小限となるようにした上で，思い切ご尽力を注いでいただきました．著者が個人的にって追加対応等もすべきである．

相談に乗っていただいた荒本道隆様，松山憲和様，
小川直人様，芦田尚人様にも感謝いたします．

16

＊

謝辞

また，気象情報提供形式検討部会事務局，気

気象庁 XML の策定にあたっては XML コンソ

象庁防災情報 XML フォーマット普及・活用推進ーシアムに多大なる支援を頂きましたことについ部会事務局の各事務局員，WG 構成員，連絡調整て，ここに感謝いたします．特に，XML コンソ

員，オブザーバ，及び関係者の皆様には，気象庁

ーシアム気象庁 XML 策定支援チーム及び検証協

XML の策定に当たり多大なる貢献に感謝いたし

力メンバー，Web サービス実証部会，XML 設計

ます．

第 15 表XML コンソーシアム気象庁 XML 策定支援チーム及び検証協力メンバー

��������������� 50 �����������������
������������ ������ NTT ����� ��������
���������������� ������������������ �������������� ������������������� �� �������������� ������������� ��
PFU ������������ ������������� ����������� ���������������� 50 �����������������
����������
��������
�������������
�������������
���������
�������

* 第 16 章

杉山－ 136 －

�� ��
�� ��
�� ��
�� ����� ���� ��
�� ��

測

候

時

報

79.5-6

第 15 表続き

2012��������������� 50 �����������������
������������ ������ NTT ����� ��������
����������� ������������������ ������������������ ������������������ �������������� ������������������� �� �������������� ������������� ��
PFU ������������ ������������� ����������������� 50 �����������������
����������
��������
�������������
���������
PFU ����������
�������

参

考

文

�� ��
�� ��
�� ��
�� ������ ���� ���� ��

Malhotra（2004）：XML Schema．W3C．（http://

献[1] デジタル放送地域情報 XML 共通化研究会（2010）：
デジタル放送地域情報 XML 共通 XML フォーマッ

www.w3.org/2001/XMLSchema，2012 年参照）
[8] Murata, M.（2012）：RELAX NG home page．（http://
www.relaxng.org/，2012 年参照）

ト．（http://www.tvcml.jp/tvcml/，2012 年参照）
[2] 屋 内 恭 輔（2003-2005）： た の し い XML．（http://[9] Murata, M., Y. Komachi, A. Kawamata, M. Hiyama, K.

www6.airnet.ne.jp/manyo/xml/index.html，2012 年 参

Kamimura, Y. Okui. S. Imago, Y. Yamamoto, and K.

照）

Kazama（2005）：XML Japanese Proﬁle．W3C．
（http://[3] ITMedia Inc.（2012）：XML 用 語 辞 典．atmarkIT．
（

www.w3.org/Submission/japanese-xml/，2012 年参照）

http://www.atmarkit.co.jp/fxml/dictionary/indexpage/[10] JIS（1999）：XML 日本語プロファイル 解説．JIS

xmlindex.html，2012 年参照）

TR X 0015:1999（邦訳）．（http://www.y-adagio.com/[4] Refsnes Data（1999-2012）：w3schools.com．（http://
www.w3schools.com/，2012 年参照）

public/standards/tr_xml_jpf/kaisetsu.htm，
2012 年参照）[11] 気象庁予報部（2003）：注意報・警報の改善と天気[5] 川俣晶（2003）：XML における「ボヘミアンと貴族の階級闘争」を読み解く．atmarkIT．
（http://www.
atmarkit.co.jp/fxml/tanpatsu/24bohem/01.html，2012

予報の充実等について．配信資料に関する技術情報（気象編），第 153 号[12] Bray, T., D. Hollander, A. Layman, and R. Tobin（2004）：
Namespaces in XML 1.1．W3C．（http://www.w3.org/

年参照）[6] Bray, T., J. Paoli, C.M. Sperberg-McQueen, E. Maler,

TR/xml-names11，2012 年参照）

and F. Yergeau（2008）：Extensible Markup Language[13] Berners-Lee, T., R. Fielding, and L. Masinter（2005）：(XML) 1.0．W3C．（http://www.w3.org/TR/xml/，

RFC 3986: Uniform Resource Identiﬁer (URI): Generic2012 参照）

Syntax．IETF．（http://www.ietf.org/rfc/rfc3986.txt，[7] Fallside, D.C., P. Walmsley, H.S. Thompson, D. Beech,
M. Maloney, N. Mendelsohn, P.V. Biron, and A.

－ 137 －

2012 年参照）[14] Microsoft：Xsi:nil 属 性 バ イ ン デ ィ ン グ の サ ポ ー

測

候

時

報

79.5-6

2012

ト．MSDN．（http://msdn.microsoft.com/ja-jp/library/

BUILDING AND THE QUALITY MANAGEMENT

ybce7f69(VS.80).aspx，2012 年参照）

FRAMEWORK．CBS-Ext 2010，WMO-No.1070，[15] Oracle：Java Platform. Enterprise Edition (Java

pp.25．

EE) Technical Documentation．Oracle Technology[25] APPLIC 技術専門委員会（2012）：プラットフォー

Network．（http://download.oracle.com/javaee/，2012

ム通信標準仕様 V2.3．APPLIC．
（http://www.applic.

年参照）

or.jp/2012/tech/，2012 年参照）

[16] Oracle（2009）：JAXB Class Generator の 使 用．

[26] APPLIC 安心安全ワーキンググループ（2012）：防Oracle XML Developer's Kit プ ロ グ ラ マ ー ズ・ ガ

災業務アプリケーションユニット標準仕様 V1.1．

イ ド，11g リ リ ー ス 2．（http://docs.oracle.com/cd/

APPLIC．（http://www.applic.or.jp/2012/app/bousai/

E16338_01/appdev.112/b56264/adx_j_jaxb.htm，2012

index.html，2012 年参照）
[27] 高度情報通信ネットワーク社会推進戦略本部（ＩＴ年参照）[17] IBM： デ ー タ ベ ー ス (DB2)．（http://www-06.ibm.

戦略本部）（2009）：i-Japan 戦略 2015．（http://www.

com/software/jp/data/db2/，2012 年参照）

kantei.go.jp/jp/singi/it2/dai51/siryou3.pdf，2012 年 参[18] Jones, E. and A. Botterell（2005）：Common Alerting照）

Protocol, v.1.1. OASIS．（http://www.oasis-open.org/[28] 山本太基（2010）：気象庁防災情報 XML フォーマ

committees/download.php/15135/emergency-CAPv1.1-

ットについて．ソフトウェアジャパン 2010，一般

Corrected_DOM.pdf，2012 年参照）

社団法人情報処理学会，東京，日本．

[19] Yamakoshi, Y.（2008）：XML draft format for[29] Dubuisson, O.（2011）：Introduction to Object

warnings and advisories in Japan．WIS Common

Identifiers (OIDs) and their use by WMO．Common

Alerting Protocol (CAP,X.1303) Implementation

Alerting Protocol (CAP) Implementation Workshop，

Workshop，WMO，Geneva，Switzerland．

WMO，Geneva，Switzerland．

[20] Sugiyama, Y. and N. Washitake（2011）："Japandisaster Mitigation and prevention information XML

用

語

集

API：Application Programming Interface のformat" (JMX) is in operation!．Common Alerting

略．

Protocol (CAP) Implementation Workshop，WMO，OS，ソフトウェア，ライブラリー，サービ

Geneva，Switzerland．

ス等のある機能に対して，利用者・利用アプ[21] Kuma, K.（2012）：Disaster Prevention Information

リケーションがその機能を利用するためのイ

Provided by Japan Meteorological Agency．Emergency

ンターフェースを指す．API が標準化されてAlerting Policy Workshop，Environment Canada, other

いると，実装に関わらずプログラムが同一化・Canadian agencies, OASIS, WMO and ITU，Montreal，

統一化でき，また洗練された API は利用者

Canada．

がその機能の実装構造を知らなくても利用で[22] ISO：TC223 Societal security．（http://www.iso.org/

きるので重要となる．

iso/iso_technical_committee.html?commid=295786，

DOM・DOM ツリー：Document Object Model の略．
W3C から勧告されている XML 文書を扱う

accessed 2012）[23] Cox, S.（2010）：Geographic Information: Obser-

ための API．DOM は XML 構造に準じてツ

vations and Measurements．OGC．（http://portal.

リー構造として取り扱えるので，このことをopengeospatial.org/files/?artifact_id=41579，2012 年

DOM ツリーともいう．構造に沿って自由に

参照）

解析・拡張ができるが，実装においては処理[24] WMO（2010）：DECISION FOR THE OPEN

速度とメモリー使用量が多めとなってしまう

PROGRAMME AREA GROUP ON INFORMATION

欠点がある．原典は次の URL を参照．http://

SYSTEMS AND SERVICES, INCLUDING THE

www.w3.org/DOM/DOMTRWMO INFORMATION SYSTEM, CAPACITY-－ 138 －

測

候

時

報

79.5-6

IDE：Integrated Development Environment の略で，
統合開発環境を意味する．プロジェクト管理，

2012

変換できる．原典は次の URL を参照．http://
www.w3.org/TR/xslt

バージョン管理，ビルド・デバグ補助機能

かな漢字電文：主として Shift_JIS のいわゆるなどが付いている開発環境．Visual Studio や

全角（2 バイト文字）を利用した気象庁の電Eclipse が有名．

文形式の一つ．機械可読を目的としたコード

SAX：Simple API for XML の略．XML 文書を扱を付記した物もある．

うための API で，標準化団体による規定は

基底型：あるデータ（要素値や属性値など）がされていないが，事実上の標準化規格として属するクラスのこと．プリミティブ型又はプ利用されている．DOM と異なり，ツリー構

リミティブ型を元に制限や拡張等を与えたク

造として取り扱うのではなく，イベント駆動

ラスとなる．

型として取り扱う．構造に沿った自由な解析

コード電文：主として ASCII 文字のみを利用ができず，また XML の作成・拡張は全くでした気象庁の電文形式の一つ．フォーマット

きないが，ストリーム処理の一環となることを明確にして機械可読を目的としている．

から高速かつ省メモリーで動作する．原典は実装：ある機能を実現するために構成要素を具次の URL を参照．http://www.saxproject.org/

体化することを一般的に実装という．ソフト

SOAP：ソフトウェア同士がメッセージ交換すウェア分野では仕様・機能に対して実際に動るためのプロトコルで，XML を利用する．
W3C により標準化されている．

作するプログラムを示す．
名前空間：XML において，違う体系（個々のUNICODE：コンピュータ上の文字列を一貫した

XML スキーマ）に属する要素等が，お互い方式で符号化し取り扱うための標準規格．

に別の体系に属していることを明確化するた

UNICODE の符号化方式として UTF-8 が広くめに用いられる区分手法．URI により定義し，

使われている．

接頭辞と呼ばれる簡略化した文字とのマッピ

W3C：World Wide Web Consortium の略で，Worldング（“xmlns: 接頭辞 ="URI"”の記法）を通Wide Web（WWW）で使用される各種技術のじて，所属が一意に定まるように各要素を修標準化を推進する団体．

飾する．

XML：JIS による邦訳は「拡張可能なマーク付け

バ リ デ ー シ ョ ン（Validation）：XML で は言語」．第 3 章のほか，原典は次の URL を参DTD，各種 XML スキーマ等を用いて妥当性

照．http://www.w3.org/TR/xml/検証を行うことをバリデーションという．バXML インスタンス：一般的にオブジェクトの実

リデーションするソフトウェアをバリデータ

体をインスタンスというが，XML インスター（Validator）という．第 4 章を参照．

ンスは XML スキーマに対して XML の情報

平文：かな漢字電文に代表されるような，人間が自然言語として読むことを目的とした電文そのものを指すときにいう．
XML スキーマ：XML の文書構造を定義する手又は電文の一部分．機械可読を目的としたコ法の 1 つで，いわば設計図に当たる言語．第ード電文やコード行の対義語として用いる．

4 章を参照．

プリミティブ型：プログラミング言語においXML 電文：XML を利用した気象庁の電文形式て提供される基本的なデータ型．文字列型（string 型，token 型 ）， 整 数 型（integer 型 ），の一つ．
XSLT：Extensible Stylesheet Language

浮動小数点型（ﬂoat 型）などがこれにあたる．

Transformation の略．W3C から勧告されていメタ情報：主たる情報についての情報である．

る XML 文書を別の XML 文書等に変換する

具体的には主たる情報を要約したような情報ための言語・技術．単純な構造変換であれば，を示す．

XSLT によりプログラムを書かずに XML を－ 139 －

測

付録

候

時

報

79.5-62012

辞書記述要領（抜粋版）
平成 21 年 3 月 2 日

辞書記述要領1．項目表
���“jmaxml”

����

“uri”

��

���

���

��

���

���

����

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

type.A1

C11

xs:string****
type.A3
xs:string
*
##any

128

1

256

?
1

B11
B12

type.A2

type.A3

type.A4(element)
(end)

*

B21
B22

C12

B31
B32

B51

C13

1,3

xs:string
type.A1
type.A4?
*+

xs:intxs:string
xs:string
xs:string
type.A2

1(nil)
1

*
128

?
1

��
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…

�����

“c11a”“c11b”
RE”c11reg”*“b12a”

code.D2

code.D1

��
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…

共通事項：
・表の初段に当該表の示すスキーマの接頭辞と名前空間を記述する．関連する表間で，同じ名前空間を示す接頭辞は常に同じとする．インスタンス名の記述がある場合はインスタンス型表記を行うことを明示している．
・属性，基底型で，他の名前空間に属するものについては，必ず接頭辞を付ける．
・型を示す場合は "type." で，コード辞書を参照する場合は，"code." を用いる．
項番：
・辞書中の位置を一意に表せるように番号を記述する．
親要素：
・辞書の項目の名前を記述する．基本的に型名となる．
・辞書中で唯一の名前とする．
例）A1，A2，A3，A4 は親要素（項番 1，11，15，18）
・特別な識別子 "(element)" により，子要素の要素名で基底型の要素をグローバルに宣言する．
例）要素名 B51 を型 A2 としてグローバルに宣言する（項番 20）－ 140 －

測

候

時

報

79.5-62012

子要素：
・親要素に含まれる項目（element）の名前を記述する．
・同じ親要素内で原則，唯一な名前とする．辞書中で唯一の名前となれればより望ましい．
・子要素が他の名前空間接頭辞が付いた要素名となっている場合，他の名前空間の型に対する参照（Reference）であることを示す．
・例外的に任意の子要素も許容する場合は，子要素にアスタリスク（"*"）を記述し，許容する子要素の名前空間を基底型に記述する．（例：項番 10）
この場合で，許容する名前空間が複数ある場合は，基底型を識別子 "(namespace)" とすることにより，次行より列挙型とできる．
例）B11，B12 は A1 の子要素（項番 7，8），B21，B11 は A2 の子要素（項番 13，14），B31，B32 はA3 の子要素（項番 16，17）
属性：
・親要素の属性の名前を記述する．必ず親要素の次行からとする．
・同じ親要素内で唯一な名前とする．辞書中で唯一の名前となれればより望ましい．
例）C11 は親要素 A1 の属性（項番 2），C12 は親要素 A2 の属性（項番 12），C13 は親要素 A4 の属性（項番 19）
注 1）親要素，子要素，属性は各行に排他的に用いる．
注 2）属性は直前の親要素の属性（attribute）を表し，子要素は直前の親要素の項目（element）を表す．
注 3）親要素，子要素，属性，基底型の全てが空の行は表の最後以外には置かないものとする．
基底型：
・子要素および属性の基底型を記述する．
・子要素の基底型としては，XML Schema で定義されているビルトインデータ型または，辞書中で定義される親要素の名前もしくは他の名前空間により示される型を記述する．（例：項番 7，8，13，15，
16，20）
・属性の基底型としては，XML Schema で定義されているビルトインデータ型，もしくは他の名前空間により示される型やコード名を記述する．（例：項番 2，12，19）
・子要素および属性の基底型は必ず記述する．
・親要素の基底型は通常記述しないが，子要素が無く Text ノードのみで属性しか持たない型の場合（simpleContent 型）のみ，親要素の行に基底型を記述する．（例：項番 17）
・子要素から引き続く行の親要素，子要素，属性が空欄で，基底型が "*" の場合，直前の子要素の基底型を用いた列挙を表す．（例：項番 8，9）・属性から引き続く行の親要素，子要素，属性が空欄で，基底型が "*" の場合，直前の属性の基底型を用いた列挙を表す．（例：項番 2，3，4，5，6，）・任意の子要素から引き続く行の親要素，子要素，属性が空欄で，基底型が "*" の場合，直前の任意の子要素が許容する名前空間の列挙を表す．
・リスト型の表記を行う場合，基底型として "xs:list（リスト型の基底型）" フォーマットで記述すものとし，リスト型の基底型としてビルトインデータ型のみを許容する．
・コード辞書を参照する場合は，コード辞書の規定となるビルトインデータ型を記述する．

－ 141 －

測

候

時

報

79.5-62012

サイズ：・基底型に記載されているビルトインデータ型データのサイズを記述する．
・文字列型の場合，列長を記述する．数値型の場合，その型が規定している上下限を狭める場合に記述する．
・記述において，単独で記述する場合は上限を，それ以外は "（下限値 , 上限値）" の形式で，記述する．
・上限値が無期限，もしくは型の規定値の上限を示す場合は "*" を記述する．
出現回数：
・親要素の出現回数は記述しない．具体的な出現回数は親要素を参照する子要素中に定義される．
・子要素の出現回数は以下のように記述する．
必ず 1 回出現

1

0 回か 1 回出現？

1 回～無限大に出現＋

0 回～無限大に出現＊

N 回～ M 回出現

N,M

xsi:nil により省略可能（nil）

・属性の出現回数は以下のように記述する．
必ず 1 回出現

1

0 回か 1 回出現？

例）子要素の「1」の例は項番 8，17，子要素の「？」の例は項番 7，子要素の「1 回～無限大」の例
は項番 14，子要素の「0 回～無限大」の例は項番 13，子要素の「1 回～ 3 回」の例は項番 10．属性の「1」の例は項番 2，属性の「？」の例は項番 12，19．省略可能の例は項番 16．
意味：・親要素，子要素，属性の意味を簡潔に記述する．
とりうる値：
・子要素，属性がとりうる値を記述する．
・子要素の基底型が他の親要素の名前となる場合は省略する．
・列挙を表す場合，実際の文字列をダブルクォートで挟んで記述する．複数列挙する場合は，次の行に連ねて記述する．（例：項番 3，4，9）
・とりうる値として正規表現による記述を行う場合，識別子 "RE" を冠した上で正規表現型をダブルク
ォートで挟んで記述する．この場合，列挙している他のとりうる値の行の中で，任意の値表現を除いた最後に記述する．（例：項番 5）
・とりうる値として任意の値を表現する場合，とりうる値を "*" としてダブルクォートで挟んで記述する．この場合，列挙している他のとりうる値の行の中で，最後に記述する．（例：項番 6）
・コード辞書を参照する場合，"code." をつけて記述する．（例：項番 12，17）複数のコード辞書を参照する場合も，とりうる値の列挙と同様にする．また，とりうる値としてコード辞書の参照を行う
場合は，任意の値表現以外とは併用できない．

－ 142 －

測

候

時

報

79.5-62012

解説：・親要素，子要素，属性を説明する文章を記述する．
注 4）子要素がアスタリスク（"*"）だけの行は，例外的に任意の子要素も許容する理由を解説に記述する．
注 5）子要素，属性，許容する名前空間の列挙を表す行は，基底型を "*" とした上で，意味，とりうる値，
解説のみを記述する．
注 6）インスタンス記述のため，親要素，子要素，属性，基底型の全てが空の記述を認める．表の最後には親要素を "(end)" とした行を置くものとする．（例：項番 21）
2．XML Schema 生成の考え方
上記の項目表，コード表を元に XML Schema 生成の考え方を例示する．
前提条件：
・XML Schema の記述スタイルとしてベネチアンブラインドパターンをベースとする．
・親要素の名前は辞書中で唯一となっている．
・子要素，属性の名前は親要素内で唯一となっている．
・コードの名前は辞書中で唯一となっている．
・子要素は記述順に出現するとし，任意の順序は許容しない．
・他の名前空間に属する型，コード等については，必ず接頭辞を付ける．
生成規則：
・親要素からは，型定義（complexType）を生成する．
・親要素の名前からは，型定義の name 属性を生成する．
・親要素名として型を記載し，同一行にその基底型を表記した場合，子要素のない属性値付き要素（simpleContent）として拡張し，次行以降の属性のみを生成する．
・親要素が“（element）”の場合，name 属性を子要素とし，type 属性を基底型としてグローバルに
element 要素を生成する．
・子要素からは，親要素に対応する型定義中の要素定義（element）を生成する．
・子要素の名前からは，要素定義の name 属性を生成する．
・子要素の基底型からは，要素定義の type 属性を生成する．
・ 子 要 素 の 出 現 回 数 か ら は， 要 素 定 義 の minOccurs 属 性（"1"，"0"） と maxOccurs 属 性（"1"，"unbound"）を生成する．
・子要素の列挙からは，enumeration，そのとりうる値からは，enumeration の value 属性を生成する．
・子要素の名前に別の名前空間接頭辞が付いていた場合，基底型に記載の要素名に対して参照することとする．
・任意の子要素も許容する記述からは，要素定義に any の定義を生成する．この場合の基底型は許容
する名前空間とし，列挙した場合は xs:list 型とした上で，namespace 属性を生成する．
・属性からは，親要素に対応する型定義中の属性定義（attribute）を生成する．
・属性の名前からは，属性定義の name 属性を生成する．
・属性の基底型からは，restriction の base 属性を生成する．
・属性の出現回数からは，属性定義の use 属性（"required"，"optional"）を生成する．

－ 143 －

測

候

時

報

79.5-62012

・属性の列挙からは，enumeration，そのとりうる値からは，enumeration の value 属性を生成する．
・いずれの場合の列挙においても，任意の値を許容する記述を含む場合，辞書に記載されている列挙
型を生成せず，記述されている基底型の単純型として生成する．
・コード辞書を参照する場合，コード辞書に対する型への参照を生成せず，記述されている基底型の単純型として生成する．
・子要素として任意の子要素を許容する場合で，かつその子要素について許容する名前空間の列挙において，"##any"，もしくは "##other" を含む場合，辞書に記載されている名前空間の列挙を生成せず，記述されている "##any"，もしくは "##other" のみ許容するとして生成する．
・サイズは辞書のための情報とし，制限形式として生成しない．
上記生成規則を用いると辞書例から下記の XML Schema が生成される．
<?xml version="1.0" encoding="UTF-8"?><xs:schema
xmlns:xs=http://www.w3.org/2001/XMLSchema
xmlns:jmaxml="uri" elementFormDefault="qualiﬁed" targetNamespace=" uri "><xs:complexType name="type.A1"><xs:sequence><xs:element name="B11" minOccurs="0" maxOccurs="1" type="jmaxml:type.A3"/><xs:element name="B12" minOccurs="1" maxOccurs="1" type="jmaxml:enum.type.A1.B12"/><xs:any namespace="##any" minOccurs="1" maxOccurs="3" processContents="lax"/></xs:sequence><xs:attribute name="C11" use="required" type="jmaxml:enum.UNION.type.A1.C11.attr"/></xs:complexType><xs:complexType name="type.A2"><xs:sequence><xs:element name="B21" minOccurs="0" maxOccurs="unbounded" type="jmaxml:type.A1"/><xs:element name="B22" minOccurs="1" maxOccurs="unbounded" type="jmaxml:type.A4"/></xs:sequence><xs:attribute name="C12" use="optional" type="xs:string"/></xs:complexType><xs:complexType name="type.A3"><xs:sequence><xs:element name="B31" minOccurs="1" maxOccurs="1" nillable="true" type="xs:int"/><xs:element name="B32" minOccurs="1" maxOccurs="1" type="xs:string"/></xs:sequence></xs:complexType><xs:complexType name="type.A4"><xs:simpleContent><xs:extension base="xs:string"><xs:attribute name="C13" use="optional" type="xs:string"/>－ 144 －

測

候

時

報

79.5-62012</xs:extension></xs:simpleContent></xs:complexType><xs:element name="B51" type="jmaxml:type.A2"/><!-- --><!--Enumeration's --><!-- --><xs:simpleType name="enum.type.A1.C11.attr"><xs:restriction base="xs:string"><xs:enumeration value="c11a"/><xs:enumeration value="c11b"/></xs:restriction></xs:simpleType><xs:simpleType name="enum.pattern.type.A1.C11.attr"><xs:restriction base="xs:string"><xs:pattern value="c11reg"/></xs:restriction></xs:simpleType><xs:simpleType name="enum.ANY.type.A1.C11.attr"><xs:restriction base="xs:string"/></xs:simpleType><xs:simpleType name="enum.UNION.type.A1.C11.attr"><xs:union memberTypes="jmaxml:enum.type.A1.C11.attr jmaxml:enum.pattern.type.A1.C11.attr jmaxml:
enum.ANY.type.A1.C11.attr"/></xs:simpleType><xs:simpleType name="enum.type.A1.B12"><xs:restriction base="xs:string"><xs:enumeration value="b12a"/></xs:restriction></xs:simpleType></xs:schema>
以上により，次の XML データが許容される．
<?xml version="1.0" encoding="UTF-8" ?><B51 C12="code.D2 の各定義に従う " xmlns="uri/"><B21 C11="c11a"><B11><B31>128</B31><B32>code.D2 の各定義に従う </B32></B11>－ 145 －

測

候

時

報

79.5-62012<B12>b12a</B12><any>any な要素 </any></B21><B21 C11="c11b"><B12>b12a</B12><any>any な要素 1</any><any2>any な要素 2</any2></B21><B22>b22 の値その 1</B22><B22 C13="c13 の属性値 ">b22 の値その 2</B22></B51>
3．その他，辞書エクセルシートの書き方
・全てのシートを辞書として解析する．解析しないシートは名称を“#”で始める．
・名前空間表を用意し，シート名を“#ns”とする．シートには各辞書で用いる名前空間のうち，W3C
XML Schema 以外の名前空間について，その接頭辞とワールドワイドなスキーマ参照 URL，及びローカルスキーマ参照 URL を記述する．また，外部スキーマファイルを取り込む（xs:include）する
際には，“include フラグ”列に“include”と記述する．
なお，ローカルスキーマ参照 URL 以外は記載必須とし，同 URL 省略時のローカルスキーマ作成時には，シート名をファイル名とする．
・作成されるスキーマにおいて，冒頭に出力する注釈文について，“# 注釈”シートに記載する．また
名前空間別に管理される注釈文については，名前空間表に個別に記述することする．冒頭の注釈文
においては，「“# 注釈”シートの記述＋名前空間表の個別の記述」により出力される．
・共通項目表におけるエクセルシートのシート名を接頭辞とする．
4．参考事項・any 要素の namespace 属性について，特別の値として次のものがとれる．なお，列挙型と併用できるのは，“##other”と“##local”のみである．
“##any”

任意の名前空間に属する要素“##targetNamespace” このスキーマの名前空間に属する要素“##other”

このスキーマの名前空間以外の名前空間に属する要素“##local”

名前空間に属さない要素（非推奨）・ 別の名前空間に属する要素を作成する際は，要素名は呼び出される側の名前空間に属するようにする．そのために，次の 2 点の通りの設定を利用する．
1．別の名前空間接頭辞をつけた子要素を指定し，ref 参照要素を作成する．
2．別の名前空間の辞書において，当該子要素を親要素名“（element）”にてグローバル要素で宣言する．

－ 146 －