☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆
XMLテクノロジー通信
第9号(2004/2/18)
☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆
小泉内閣が観光立国を標榜し、“観光”をより一層重要なことと認識し、関連する
産業を日本の基幹産業として高めようとしていることは、みなさん周知のことでしょう。
観光資源を保全し、より魅力を引き出すこと、観光客への周知し、かつ利便性を高める
ことが重要です。後者は、ITを最大限活用することが必要です。XMLコンソーシアムにて
TravelXMLの標準化が一区切りを迎えます。その意義は極めて高いと考えます。今号
は、標準化活動を支える中心的なお二人の方にTravelXMLをご紹介いただきます。
編集長 日本ユニシス 牧野 友紀
----------------------------------------------------------------------
<次回XMLテクノロジー部会定例ミーティング>
日時：2004年2月19日(木) 13:30～17:00
場所：日本ユニシス本社6階Aルーム
地図：http://www.unisys.co.jp/com/honsha.html
<次回応用技術部会定例ミーティング>
日時：2003年2月26日(木) 14:00～
場所：NTTコムウェア本社 17階第2,3会議室
地図：http://www.nttcom.co.jp/about/corporate/map/map_shinagawa.html
----------------------------------------------------------------------
●目次
★［特別寄稿］TravelXML1.1.1勧告に寄せて 佐藤 進
★［特別寄稿］旅行業界における電子商取引の標準 ― TravelXML 遠城 秀和
★［Webサービス］Webサービスについて思うこと 倉沢 良明
★［セマンティックWeb］メタデータや表のスキーマ構造を必要なだけオントロジーで
定義しましょう 野村 直之
★［複合コンテンツ］財務情報の為のXBRL(インスタンス作成編) 加藤 上直
★［セキュリティ］SAML概略 坂田 匡通
----------------------------------------------------------------------
●TravelXML1.1.1勧告に寄せて
日本旅行業協会IT推進担当 佐藤 進
日本旅行業協会とXMLコンソーシアムで開発を進めていましたTravelXMLもいよいよ
第一フェーズの全仕様が勧告になります。
これからはひたすら啓蒙・普及活動に驀進してゆきます。
すでに日本の代表的旅館が加盟している（社）国際観光旅館連盟からも連盟としての
標準仕様として採択され、旅行業と共同で普及をしてゆくための土台ができあがりつつ
あります。
とは言うものの旅行業はEDIの導入が早かったため、レガシーなシステムがまだまだ現
役で動いている業界です。また、それらのシステムがまさにオープン系への移行をしてい
る真っ最中でもあります。このようなタイミングで、またSARSやらイラク戦争、テロなどで
旅行業は不況のどん底にあります。大手から中小企業までに趣旨を理解させ、ひっぱ
ってゆくことは並大抵のことではできません。
これからさらに第二フェーズを早期に公開することにより全体のメリットを強調できるよう
になります。
成功するか失敗するか、業界全体の浮沈をかけて取り組んでゆきたいと燃えておりま
す。
----------------------------------------------------------------------
●旅行業界における電子商取引の標準 ― TravelXML
TravelXML標準化部会リーダー NTTデータ 遠城 秀和
標準規格「TravelXML」の共同開発
社団法人日本旅行業協会（http://www.jata-net.or.jp/）とＸＭＬコンソーシアムは、旅
行業界内における電子商取引（BtoB）を推進するためにXMLを利用した各種旅行商品
取引の標準規格「TravelXML」を共同で開発する検討を平成１５年２月より開始しまし
た。日本旅行業協会は、ＩＴ推進特別委員会内に標準化ワーキンググループを設置し、
各企業の現システム上の取引手順、電文などに関する調査を実施し、XMLコンソーシ
アムは、TravelＸＭＬ標準化部会を設置し、取引に使用する情報項目のXML化、スキー
マの作成、ドキュメントの整備を進めました。旅行業界の知識を持った業界団体とXML
というIT技術を持った団体とがお互いを補完しあうことで最新の技術を用いつつ迅速に
業界標準を開発することができるのです。
TravelXMLの勧告
現在のTravelXMLでは、従来各旅行会社で個別に定義されている旅行業EDIを整理
統合し標準仕様化しています。通信手段としてのインターネットとXMLを採用することに
よって、国内海外の宿泊施設、ツアーオペレータ、旅行業者などをリアルタイムで結び、
業界全体のシステムの効率化による業務スピードの向上と、コストダウン、そしてお客
様へのサービス向上を目的としています。
標準化の第一フェーズとしては、以下の３つの商取引について標準化を行い、平成１６
年２月１６日（予定）に勧告を一般公開した。（勧告はXMLコンソーシアムのTravelXML
標準化部会のページよりダウンロード可能です。）
①「海外手配データ」、②「国内在庫照会・予約・手配データ」、③「商品在庫照会、予
約通知(国内/海外)」
今後、両団体では実際の利用が早期に開始できるよう、普及・啓蒙活動を実施する予
定です。
TravelXMLの第2フェーズ
また、TravelXMLの第二フェーズとしては次の仕様の開発を続け、将来的には旅行産
業全体での標準化を目指しています。
①｢決済データ｣ 、②｢商品内容データ｣、③｢国内施設情報・タリフ情報｣、④｢海外施
設情報・渡航手続・見積/タリフデータ｣、⑤｢提供企業情報｣
一方欧米ではOTA（Open Travel Alliance）を中心として個人の個別予約のための標
準化が進められています。TravelXMLでは旅行業者の大量仕入れを前提としたパッケ
ージ旅行・団体旅行の商取引を扱っており、相互利用が考えられます。そこで
TravelXMLとOTAとの整合性の検討も進め、将来的には規格の融合も目指していきた
いと考えています。
----------------------------------------------------------------------
●Webサービスについて思うこと
キヤノン 倉沢 良明
私は、昨年から、テクノロジー部会のWebサービスWGに参加させて戴きました。
新年度がスタートしてからしばらくの間、技術マップなど技術面のテーマが中心の定例
会では、残念ながら『いすを暖めるだけ』の参加でした。しかし、昨年の秋、EAやSOAの
話がスタートすると、何処からか元気が出てくるのです。
そこで、なぜ元気が出てくるのかを考えてみました。
実は、私は1973年の入社、勤務地や所属部門はかなり替わりましたが、ずっとITに関
連した職場で30年余を過ごしてきました。私がコンピュータに始めて触れた70年代は、
コンピュータ導入が本格化した時期で、受発注・経理などバッチ処理による定型業務処
理が対象で、要員削減、スピードアップ、情報精度の向上などが狙いでした。
73年に、私が最初に親しんだコンピュータはメモリーが64K、Diskは30MBが4台、磁
気テープ装置が2台、それに、ラインプリンターが1台、確か、こんな構成でした。本体は、
１ｍ X 2ｍ X 3ｍ弱と今では想像もつかない巨体でしたが、ホストのメモリーは全部で、
６４ｋ、OSが30Kを使用しユーザプログラムが使用できるメモリーはたった34Kだけでし
た。その頃は、人手で行っていた処理をEDP処理に移管するわけですから、IT化の効
果は、結構簡単に出せた時代です。しかし、メモリーが非常に少ない当時は、処理プロ
グラムの大きさを如何に小さく抑えるか、そして、如何に標準化・効率化を進めるかが、
大きな課題でした。
課題解決の為に、以下のような対応を取っていました。
①複数のプログラムに共通な処理はサブルーチンを作成する。
②伝票番号管理など特殊なDiskアクセスは、EXCPを使用したサブルーチンで対
応する。（FCPは容量が大きいので、メモリー節約の為にEXCPを使用）
③サブルーチンは、限りなく小さなプログラムとする。
④マッチング・メンテナンスなど処理パターンごとにプログラムフローの標準マニュ
アルを作成し、最適なフローにより効率的なプログラム開発を行う。
⑤パラメータベースの汎用プログラムにより無駄なプログラム開発をさける。
30年前の対応ですが、これらはWebサービス、SOAに共通していると思いませんか?
私は、15年程前にプログラム開発の現場を引退しましたが、少なくとも100本以上の
プログラムを開発したと思います。意外に思われるかもしれませんが、私がゼロからプロ
グラム開発を行ったのは最初の数年間だけ。ですから、ゼロからコーディングした本数
は、10本にも満たないと思います。実は、ほとんどのプログラム開発は、処理パターンが
同じプログラム、または、既に開発済みのルーチンを集めて、必要となる差分をコーディ
ングすると言う開発方式で対処したのです。
このプロセスも、Webサービス、SOAに共通していると思いませんか?
IT化は、まず、販財給等の定型業務のシステム化に始まり、非定型業務であるオフ
ィスワークへと対象が移行し、現在は、ビジネス（ワーク）フローが対象になっています。
IT化の歴史は、IT化による競争企業との戦いの歴史であり、ＩＴの目的は、いつの時代
でも同じでした。メモリー等のハード、Windows、D/Bなどのソフト、通信・ネットワークの
急速な進歩により、ITの活用対象は、たいへん広がったのですが、本質は、何も変わっ
ていません。コンピュータ処理の効率化・共通化、システムの効率的な開発・運用を行
う為、各社のIT部門は、それぞれの時代で与えられたハード・ソフト、ネットワーク等の
インフラを最大限に活用してきたのです。マクロ、サブルーチン、標準プログラミング技法、
オブジェクト指向、４GL,スクリプト言語など、30年の間に登場した様々な手法は、全て、
情報処理のためのツール(ソリューション)に過ぎないのです。IT部門は、いつでも、その
時代の最新の技術を活用し、競争企業との戦いでの勝利を目指し、業務やオフィスワ
ークのシステム化、効率的なシステム化の為のプログラムの共通化、部品化などの標
準化に取り組んできていたのです。ですから、（多くの方は気付いていないのですが）
Webサービスの為に必要な｢ビジネスプロセスを部品化｣する為の情報が、我々の周り
には既に存在しているのです。ほとんど全ての会社のIT部門は、Webサービスの部品
化の為のすばらしい『ぬか床』を持っていると言っても過言ではないでしょう。
このように考えると、XMLテクノロジー通信7号のIBM丸山さんの提言、『ビジネスプ
ロセスの部品化と再利用は、社内の業務処理の標準化などを通して今までも試みられ
てきています。Webサービスは、この部品化と再利用のプロセスを効率化するための、
ITが提供するソリューションなのです』の重みが、とても、よく理解できます。
さて、EAやSOAの話になると、なぜ、元気が出てくるのか、わかってきました。
きっと、私のITでの経験、積み重ねが、『WebサービスやSOAは、君が、今までにやっ
てきた事と同じだ。違いは、ハードやブロードバンドなどインフラのパワーアップとソフトの
進歩だけだ。昔の経験を生かすチャンスだ！･･･』と、ささやき始め、それが、私の元気
の源になっているのだと思います。
ぜひ、Webサービス、SOA等の推進に、積極的に今までのIT経験を生かしたいと考え
ます。
----------------------------------------------------------------------
●メタデータや表のスキーマ構造を必要なだけオントロジーで定義しましょう
リコー 野村 直之
先のXML Consortium Dayで申し上げたかったことは、煎じ詰めるとこの題目のよう
になります。
http://www.xmlconsortium.org/seminar/d05/prog_2.html
↑この『用語集オントロジー』の講演に先立って、聴衆の方々からの厳しいご批判を
次のように予想していました：
「SemanticWebの概要紹介や、新しいアプリケーション(ピン・ポイント検索等)も結構。
でも、真に機械間で理解、融通し 合って今日から明日にかけての現実的な問題を解
決してくれるような用途はどんなもの？ メタデータがあれば有用そうなのは
ストレートにわかるから、今度はオントロジーなるものが本当に役に立つのか、
納得させて欲しいなぁ。」
回答例：
それでは日常使われる「表構造」や、オブジェクト指向設計で階層的に羅列した項
目間の関係を機械が「理解」できるように、オントロジーを使って記述してみましょ
う。例えば、ある用語集の素材をみて、こんな疑問が生じました： 「なにやら見出し語のと
ころに、英文字３つの略号RSSというのがあって、その「説明文」と称して、"RDF Site
Summary"って書いてある。けど、これは略称(acronym)とその書き下し綴りなのでは？ こう
してみると各項目の記述って全然統一が取れていない。フルネームであり、英訳であ
り、説明文でもあるなら、そんならそうと記述しておかないと『使えない』よ！」
この疑問に答えて、例えばRDFによって表のスキーマ間の２項関係、もしくは、表
の個々の要素間、要素とスキーマ（縦横いずれか）間の関係、あるいは、外部のリ
ソース（別の百科事典や仕様書、ソースコード）との関係を記述してやったとします。す
ると、人間向けに簡略化してまとめた（構造化した）表を、曖昧さなく解釈できるように
なり、また今後の拡張や、様々な計算用途に使え、１つの構造化データを何１０倍にも活
かすことができるようになるのではないでしょうか？ 主となる項目と従属的に定まる
／求まる項目（例えば人口密度＝人口／面積）とを予め識別しておくことも大切で
す。もっぱらスキーマ間の関係だけで記述できるようであれば（除、例外的関係）、こ
のオントロジー開発の記述量は、個々のメタデータ記述なんかよりはずっと少なくて
済むので経済的ですし。
なかなか深い理解に訴えつつ簡潔に書くのは難しい、と、非力さを痛感します。上
記リンク上にあるPDFファイルの図や表のサンプルをもう１度眺めて頂けると幸いで
す。
最後になりましたが、今回、とても嬉しいことがありました。講演の際にも熱心な
ご質問をくださったジャーナリストの石田さん(クロッシング・フィンガーズ)という方
が、実に素晴らしい記事にまとめてくださったのです：
http://pcweb.mycom.co.jp/articles/2004/01/26/xml/
この頁下方の「関連記事」含めて、当日いらした方も、いらっしゃらなかった方
も、一度目を通して頂けると幸いです。
なお、「メタデータ記述の作業量の多さ」の問題点の解決方法については、当日ご
質問に答えて２つの回答をいたしました。加えて、もう１つ、同列で扱われるべき解
決法がありますので、本稿の締めくくりとして列挙させていただきます：
（１）（構造化が中途の）データそのものの自動解析 (含、パタン認識、自然言語
処理、統計手法、パターンのアナロジー・補完処理)
（２） XHTMLやSVG等のコンテンツ記述言語を、一定の制約ルールを守って書くよう
にし、内在するメタデータをXSLT変換等で変換・抽出できるようにする
（３） 別の本来業務（というよりもっと小さな単位の個々のタスク）をこなす際に
ユーザが通常行う、マウス操作他のインタラクション（システムとの対話）から変
換・抽出
つまるところ、「作ったら作った分だけの御利益」しかないなんて嬉しくも何と
もないですもんね。
----------------------------------------------------------------------
●財務情報の為のXBRL(インスタンス作成編)
ネクストソリューション 加藤 上直
XBRLインスタンス作成方法についての内容です。
XBRLインスタンス作成の要点は幾つかありますが、今回は「Namespace」と「コンテキス
ト」についてお話させていただきます。
・Namespace
XBRLインスタンスはNamespaceを利用しています。以下に代表的なNamespaceを挙げ
ます。
【jp-bs】・・・日本版-貸借対照表
【jp-pl】・・・日本版-損益計算書
【jp-sc】・・・日本版-製造原価明細書
【jp-cf】・・・日本版-キャッシュフロー報告書
【jp-sr】・・・日本版-利益処分計算書
・コンテキスト
XBRLインスタンスには「コンテキスト」と呼ばれる個所が存在します。
このコンテキストは要素に付属情報を付ける事が目的です。
通常、要素名は「勘定科目」等のみを意味するものですので、XBRLJapanで進められて
いるボキャブラリもタグ名を規定する事にあります。
しかし、実際のデータは要素名だけではなくその他に多くの情報も付属しなければなり
ません。
記述例１）
<jp-pl:Sales>1000000000</jp-pl:Sales>
【jp-bs:】は日本版-損益計算書のNamespaceを指定しており【Sales】は「売上高」を意
味しています。
しかしこれでは「日本版-損益計算書の売上高」を意味する事は分かるのですが、この
売上高は「今月の売上高」なのか、「昨年度の売上高」なのか、「上半期の売上」なの
か、また通貨単位は「円」なのか「米＄」なのか「ユーロ」なのか、さらには、どの団体・企
業の売上の数値なのかという事は分かりません。
そこで、それらの情報はまとめて記載しておき、属性値を用いて情報を付加する手法を
XBRLでは採用しており、その情報をまとめた部分をコンテキストと呼んで、XBRLインス
タンスの最下部に通常記載されています。
記述例２）
<jp-pl:Sales numericContext="c1">1000000000< /jp-pl:Sales >
<!--コンテキストの記述(ここではNamespaceを【xbrli】としています)-->
<xbrli:numericContext id="c1" precision="14" cwa="false">
<xbrli:entity>
<xbrli:identifier scheme="http://www.nextsolution.co.jp/">
NEXTSOLUTION Co., Ltd
</xbrli:identifier>
</xbrli:entity>
<xbrli:period>
<xbrli:startDate>2002-04-01</xbrli:startDate>
<xbrli:endDate>2003-03-31</xbrli:endDate>
</xbrli:period>
<xbrli:unit>
<xbrli:measure>ISO4217:JPY</xbrli:measure>
</xbrli:unit>
</xbrli:numericContext>
・コンテキストと関連付け
コンテキストの各項目が持つ値の型により以下の２つがあります。
【numericContext】 (数値コンテキスト：数値情報に関する付属情報を定義)
【nonNumericContext】 (非数値コンテキスト：数値情報に関する付属情報を定義)
「<jp-pl:Sales numericContext="c1">1000000000< jp-pl:Sales >」の属性の記述して
ある属性部分の「numericContext="c1"」は、指定するコンテキストの「id属性」を指して
います。
この場合は、「<xbrli:numericContext id="c1"」の属性値「id="c1"」を指定していて、
「<jp-pl:Sales>」の付属情報は「<xbrli:numericContext id="c1"」に記載されている事
を示しています。
また属性が「<jp-ta-bs:NoteBalanceSheetOthers nonNumericContext="s1">」と記載
されていた場合は、<xbrli:nonNumericContext id="s1">のコンテキストを指定する事に
なります。
・コンテキスト内のタグ（注1：コンテキストのタグはここに挙げた以外にも存在します）
【entity】－【identifier】・・・データに関する企業・団体を示している。「scheme」属性を
用いてURIを指定。
【period】・・・期間／日時を意味する。以下の子タグが存在する。
【startDate】・・・開始日
【endDate】・・・終了日
【instant】・・・時点
【duration】・・・期間
【forever】・・・永遠
【unit】－【measure】・・・通貨単位を定義する。単位要素としてはISO4217標準通貨表
記法(日本円は[ISO4217:JPY])を用いる。
この事項を踏まえて、上記の記述例２）は以下の意味になります。
【ネクストソリューション株式会社の2002年4月1日～2003年3月31日までの売上高の数
値は「1,000,000,000円」である。】
----------------------------------------------------------------------
●SAML概略
日立製作所 坂田 匡通
今回は、SAML（Security Assertion Markup Language)についてご紹介します。
・SAMLの概略
SAMLとは、認証・属性・認可といったユーザに関するアイデンティティ情報を異なる組
織間で交換するためのフレームワークで、OASISにおいて標準化が進められています。
SAMLを用いることで、一度の認証で複数のWebサイトが利用できるシングルサインオン
(SSO：Single Sign-On)や、ユーザの属性に応じたパーソナライズドサービスを提供でき
ることが期待されています。
SAMLの特徴として、特定の認証方式に依存しないことが挙げられます。SAMLでは
ID/Passwordなどの認証トークンそのものではなく、「○○さんが××サイトで認証され
た。」という認証結果だけをサイト間で交換します。これにより認証方式がパスワード認
証であっても、生体認証であっても関係なく、共通のフレームワークでSSOサービスを実
現することができます。
・SAMLの標準化動向
SAMLは2002年11月にバージョン1.0、2003年9月にバージョン1.1がリリースされており、
４つの仕様から構成されています。
- SAMLアサーション : 認証、属性、許可情報のXML記述
- SAMLプロトコル : アサーションを交換するための交換プロトコル
- SAMLバインディング: トランスポートプロトコルにどのように乗せるかを規定
- SAMLプロファイル : SSOなどのサービスを実現するための一連のプロセス規定
現在はバージョン2.0の検討が進められており、Liberty Allianceの機能を反映した仕
様となるようです。導入される機能の候補として以下の機能などが挙がっています。
- ID連盟化およびプライバシや匿名性の確保
- グローバルログアウト、グローバルタイムアウトの導入
- SAMLやWebサービスを扱える高機能端末に対応したプロファイル
- XMLファイアーウォールなどのMid Tierでの利用プロファイル
- B2B, A2Aに対応したBackOfficeプロファイル
- SASLサポート
詳しい標準化の最新動向はOASISのページに掲載されています。
(http://www.oasis-open.org/committees/security)
また、WS-SecurityにおいてもSAMLをセキュリティトークンの一つとして利用したSAML
プロファイルが検討されており、WebサービスにおいてもSAMLの利用が期待されています。
----------------------------------------------------------------------
●編集後記
メルマガ第9号をお届けしました。いつものことながら、投稿者の皆さんありがとうござ
いました。先日のXMLコンソーシアムDayでも今月号で扱っているSOAやSemanticWeb、
TravelXML、セキュリティ、XBRLなどなどに関する発表が行われ大変好評でした。
読者の皆さんもメルマガでの情報収集に加えてコンソーシアムDayや部会ミーティングで
のFace-to-faceの議論に参加され、そこで得た知見をご活用いただけたらと思います。
近々では、ユーザー視点からXML活用の方向性を探る『ＸＭＬコンソーシアム ユーザー
シンポジウム2004』が今月25日に開催されます(詳細は
http://www.xmlconsortium.org/seminar/u01/annai.html)。興味をお持ちのかたの参
加をお待ちしています。(天野)
----------------------------------------------------------------------
編集員：日本ユニシス 牧野 友紀
NTTソフトウェア 奥山 信輔
日本IBM 天野 富夫
リコー、法政大学大学院ITPC 野村 直之
日本ユニシス 小林 茂
発行：XMLコンソーシアムXMLテクノロジー部会，応用技術部会
感想、問合せ：XMLテクノロジー部会リーダーML
mailto: leader-tech@xmlconsortium.org