触って理解してみよう、XMLの意義

インフォテリア株式会社井下田久幸（いげたひさゆき）

いままさに脈動を打っているXMLの技術。XMLは文書データを表現するものとして有効で、注目を集めているが、どうもそれだけではとどまらないようだ。
XMLがB2Bの世界でも大きく成長しようとしている。
いままでEDIという名前で企業間システム（B2B）は実装されてきた。本当にXMLがこの世界に技術革新をもたらすのだろうか？
実は、同じような感覚を十数年前、宅配トラックのルート決定の技術で味わったことがある。いまでは当たり前のこととなっているが、「ハブ」の技術である。
「ハブ」の技術とは、これまで配達元、配達先と複数ある取引間を直接結び配送を行っていたものを一旦センターに集約し、整理してから目的先に配送することである。個々の配送を取り上げれば無駄に思える部分もあるが、全体的に見れば最も効率的なやり方と言える。

同じことが配送する「物」ではなくて、「情報」でも起ころうとしている。（図１）当然背景としてインターネットの技術の進歩、普及があることは否めない。ここで「データ」と表現せずに「情報」といったのは、そのデータ自身に意味があり独立性があるからだ。
単なる「データ」の場合には伝送されるデータ自身には「０」と「１」の集合程度の意味でしかなく、送り元と送り先が予め規定している取り決めによって、それぞれでアプリケーションが「データ」を「情報」に変換している。
これがいままでの企業間取引の実態であり、その中で最も実績を築いてきた方法が、EDIという仕組みであった。

業界に対して影響力のある企業であれば、EDIを実施するためにこうした「データ」の取り決めを標準化し、他の企業もこれに倣い、ある程度のB2Bが実現できるのかも知れない。
　＞しかし実態は、このやり方では「普及」といえるところまではいっていない。

インターネットの普及として重要なポイントは、従来の「系列」や「グループ」といったクローズドな繋がりに捕らわれず、様々な企業と最適の取引を行ったり、最適なビジネスモデルを作り上げることにある。また、インターネットを活用することで企業の規模に関わらず参入できたり、異業種への参入も容易になったりする可能性を秘めている。企業を測る指標が、配送業ではトラックの数だったり、銀行では支店の多さだったものが、いまでは逆にコストとなりマイナスの効果になったりしている。
インターネットが急速に普及し、企業のビジネスモデルも大きく変化する中で求められていることは、インターネットを通して「ダイナミック」に情報交換できる市場の創出である。

ここで「ダイナミック」（動的）と言ったのは、従来型のEDIが反対の意の「スタティック」（静的）だからである。「取引先」、「取引内容」、「アプリケーション連携」といったことが動的に変化し、取引できる市場が求められている。
B2Bの世界で技術革新が起こり、そして普及するためには、「ハブ」となるインターネット市場が確立し、どんな企業でも参入でき、「ダイナミック」に「情報交換」ができることである。
そのため「ハブ」を通るデータには、ある程度の汎用性、独立性、標準が求められる。
これを実現するのが、「XML」である。

ではなぜXMLなのか？
いくつか簡単な比較やサンプルを使用しながら、見ていこうと思う。

固定長データ対 XML

高校時代プラモデルのようなマイコン「TK-80」と出会い、コンピュータにのめり込んでいき、如何に少ないバイト数でプログラムするかとか、迷路作成などのパズル的な問題にプログラミングで解こうと躍起になっていた筆者にとって、就職して企業システム開発に携わった時にショッキングだったのは企業レベルでのプログラミングの単調さと、データ量の多さであった。
最初に携わったのは損保業界の基幹業務だった。データをパラメータ渡しぐらいにしか馴染んでいなかった筆者が、目にした損保の申込書のデータは3,000バイトもあり（当時の感覚で）膨大であった。
しかも損保の申込書は「データ量は膨大にも関わらず記入される有効データはごくわずか」という特徴を持っていた。特約項目など、様々なお客様のニーズに対応するために用意された例外項目のためにも、全てデータとして設けなければならなかったためである。１トランザクションあたり１パラメータに3,000バイトも渡されるデータではあるが、ほとんどブランクという無駄なデータが渡ってくるのである。
この時代にXMLなどはまだ存在しなかったが、筆者にとってはこの時がXML（の考え方）との最初の出会いであった。

当時どうしたかと言えば、わずかの記入率のデータに対してその頭に「項目コード」と「：」を付けて、記入されない項目に対しては省くことで、データ量を圧縮したのである。そしてプログラムの送り元と送り先とで「項目コード編集SUB」というものを用意して、3,000バイトへのデコード処理を行った。
XMLでいえば、この「項目コード」と「：」が「タグ」であり、「項目コード編集SUB」がXMLパーサーである。

一般的にXMLについて書かれた書籍では、「データをXMLで表現するとタグが付いて、通常のテキストデータよりデータ長が大幅に増える」と、デメリットとして挙げているものをよくお見受けするが、必ずしもそうではないと思っている。
要は企業データに対する記入率（有効率）に依存するものであって、それよりもマルチメディア・データが普及し、コンピュータの処理速度が大幅に向上している今日にとっては、テキスト・データの長短など影響のない、誤差範囲と言えるのではないであろうか。

ちなみに、同じ表現力を持つデータをビットマップとパワーポイントとXMLとで表現してみた。（図2）

XMLの魅力の１つは、テキストベースであるということである。サイズはいまのコンピュータの技術レベルでは関係ない。テキストベースということの最大の魅力は３つある。

■オープンプラットフォームに対応しているデータフォーマットということ。
バイナリーデータと異なり、UNIXマシンでもWindowsマシンでも互換性がある。

■コンピュータだけでなく、人間にも可読であること。
ブラウザー上で人間に見させ易いというだけではない。何かの時に人間が判別できることの意義は大きい。コンピュータ・トラブルなどやデバッグの生産性などシステムの裏側に控えている人には魅力的なデータフォーマットである。

■歴史的データの互換性もあること。
システムの裏側に控えている人だけではない。ユーザーにとっても同じである。例えば、１０年前に保管していたワープロのデータがいま読める人はどのくらいいるだろうか？

データの保存といった観点でもテキストベースであることの意義は大きい。

カンマ区切り（CSV）対 XML

固定長のテキストと比べて、サイズ的にも、データの区切りという意味においてもメリットを持っているのが「カンマ区切りのテキスト」である。拡張子が「CSV」と付けられることからよく「CSVファイル」とも呼ばれている。
CSVファイルは、ExcelやRDBなどのエクスポートされた時のテキストフォーマットとしてもよく使用されている。企業間のデータのやりとりでもCSV形式が活用されているケースは意外と多い。

ただしCSVの最大の欠点は、データの間を「カンマ（，）」で区切っているだけなので、相手側の企業と、一番目は何のデータ、二番目は何のデータと予め順番と意味を決めておかないと使い物にならないということである。またデータの構造もカンマで区切られただけでは、全くわからないというのも不便である。
ExcelのデータやRDBのデータのように、全てが「行」というデータの繰り返し構造であるならば問題ないのだが、交換される企業データの中にはヘッダーの部分もあれば、フッターの部分もある。また繰り返し構造以外にも木構造のように複雑な形態をとるものも多い。

こういった汎用的、実用的なデータをテキストイメージで対応しようとなると、CSVでは物足りない。
その意味ではXMLは、次のような特徴から企業間のデータ交換に相応しいデータフォーマットといえる。

データの前に「タグ」を設けることによって、データが何の意味のデータかコンピュータに伝えることができる。
データの順番がくずれても「タグ」により送り元、送り先で正しくマッピングさせることができる。
「タグ」の始まりと「タグ」の終わりの間に「タグ」を入れる、入れ子構造をとることによって、「木構造」のような複雑なデータ構造もテキストイメージで表現させることができる。
たとえ、送り元と送り先の「タグ」の命名が異なっても、１対１でマッピングさせることによりダイナミック（柔軟）に企業間のデータ交換が可能である。（これについては後述）

RDBやExcel 対 XML

ここまでの点でデータ交換におけるXMLの優位性について異論を唱える人はそれほどいないと思う。
実用段階で考慮すべきポイントとなるのは、既存の資産とXMLの関係である。
各企業内ではデータをRDBで格納しているケースがほとんどである。
いままでの論点から考えるとこれらのデータを伝送上に載せるときにはXMLに変換していかなくてはならない。

よく逆説的にデータベースそのものをXMLのフォーマットで格納してみよう、という提案もあるが、ここは現実的に既存の資産（データ）を生かしつつXMLによる企業間システムの構築を検討するという立場に絞って考えてみたい。

RDBの構造は、一般的にデータベース→テーブル→列という構造をとっている。行はOccursつまり繰り返し構造を表している。XMLへの変換を考えた場合、このデータベース名、テーブル名、列名がそのままXMLのタグ名に置き換えて変換することが可能であることに着眼できる。（図3の自動変換）

XMLに置き換わったからといってこのままではまだユーザーの求めるXMLの構造になっていないので、次なる作業は、データベースから自動変換したXMLと目的のXMLの構造変換、およびタグ名のマッピングと変換である。（図３のマッピング変換）

このように考えると、実は後者の作業である構造変換とタグ名の変換はW3Cの規格であるXSLTで実現することができる。（図３のマッピング・ルール。XSLTに関しては次々節で解説）データベース＝XML変換は、このようにXMLのデザインで一貫して行うことが可能であり、最もスマートなやり方であろう。

ＨＴＭＬ対ＸＭＬ

さて、いままでのところで触れて来なかった、XMLの大事な特徴についてここで触れることにする。

実はセミナーでの講演やイベントでの交流などの場を通して、お客様に最も一番聞かれる質問が「HTMLとXMLの違い」についてである。
もともと「SGML」という規格から派生してできたものであり、兄弟のような規格である。似ていて混乱する人が多いのも当然であろう。

HTMLもXMLもどちらもテキストベースでデータの前に「タグ」を使用している点で同じである。
ではどこが違うのだろうか？

HTMLでは「タグ」でそのデータの表現形式を表わし、データが何であるかは表さない。
ＸＭＬでは「タグ」でそのデータの意味を表すが、表現形式は別の方式を使う。
HTMLではデータの終わりに付ける「終了タグ」の省略は許すが、ＸＭＬでは「終了タグ」は必須である。これはコンピュータにＸＭＬを処理させる上で非常に効率的な優位点である。
HTMLではデータの構造上の制約やデータの種類について制限を設けることはできないが、XMLではDTDや他のXMLスキーマにより、ある程度データの制約を設けることができる。
HTMLでは単純なリンクの機能があるが、XMLでは複雑なリンクを貼ったり、アンカー点のないところにもポイントしたり可能である。
例えば、アンカー点のついていない既存のHTML文書の途中のある文字にリンクさせたりができる。

など、いろいろ相違点はある。ただXMLの場合はまだ策定中の関連規格もあり、さらにいろいろな相違点が出てくるだろう。

重要なポイントは１だろう。
HTMLは、対人間ということが意識されていて、「タグ」では表現の方法しか記述されていない点が特徴である。だから例えば内容が「1,234」だった場合、これを強調して表現するのか、何色のどんなフォントで表示するのかはHTMLでわかっても、これが金額なのか、個数なのか、IDなのか意味がわからない。人間にはなかには想像でわかる項目もあるかも知れないが、コンピュータではそうはいかない。いや、データの意味を明記しない限り、人間でも重大な誤解を生む危険性が潜んでいる。
B2Bの市場において大事な点は、人間だけでなくコンピュータにも介在させて、半自動的にデータ交換をさせる点である。そうなると「タグ」には「表現形式」ではなくて、「データの意味」を記す必要がある。そうなるとXMLが相応しいということになる。

データと表現形式の分離、その意義

さて、XMLでは「表現形式」はしないかというと、そうではない。
本記事では詳細は述べないが、「XML」に付属させる形で「XSL」というデータを添付することで表現も表すことが可能である。この「XSL」はXML関連規格の名前の１つで、「XML Style Language」の略である。
XMLはデータそのものを表すXMLのデータと「ＸＳＬ」と呼ばれる表現形式を分離させたという大きな特徴を持っている。

分離させることによって受ける恩恵は大きい。
同じ１つのXMLの文書を何通りかの表現で表すことが可能だからである。
同じ内容をそれぞれの表現媒体に合わせて、その数の分だけ作成する必要はないのである。

１つのXMLの文書を元に、「XSL」を表現媒体に合わせて用意するだけで、例えばWebブラウザーに表示させたり、ｉモードに表示させたり、または他のPDA端末に表示させたりが可能である。

図２で使用した名刺の例でも、XMLファイルはそのままでXSLを複数用意することで、様々な見栄えに変化させることができる。（図4）
図５は１つのXMLのファイルを３つのXSLのファイルで、表現を変えてみたものである。

興味深いのは、フォントやサイズの変更といった表現の変更だけでなく、レイアウトの変更や表示可否の選択、表示内容の選択（図６では日本語と英語の切り替え）といったことも可能な点だ。

話を「データと表現形式の分離」からB2Bの話に戻すが、ここで興味深い事実がある。
「XSL」の規格は、実はW3Cから最終版の「勧告」としてまだ出ていない。
「XSL」の規格では、その中で「XSLT」という規格が分離して、こちらが先に「勧告」済となっている。「XSLT」とは「XSL Transformation」の略で、ＸＭＬフォーマットの変換の規定をしたものだ。このXML変換を利用してXSLでは表現を表そうというわけだ。
ところが「XSL」の規格がなかなか決まらないうちに「XSLT」がどんどん実用として使われて来てしまっている。
その理由はB2Bにおいて、XMLのフォーマット変換が非常に有効であるからだ。

B2Bにおいて企業間がデータ交換をするには、お互い意味を理解しコンピュータで処理可能なものとするために、データの意味の規定を行う必要がある。
これがXMLでいう「タグ」の名前の標準化であり、構造上の規定である。この役目を担うのが次節で説明する「XMLスキーマ」であるが、この標準化を進めるためには、まずは誰かがイニシアティブをとらなければならない。
それが業界のリーダーであっても、標準化団体であっても構わない。
大事なことは、これらの標準が複数登場した場合にもインターネット上でアメーバの如く融合することができる点である。具体的な仕組みとしては、それぞれの標準が規定した「タグ」の名前を相手方に合わせて変換したり、相手方の標準に合わせて変換する必要が生じる。
こうした変換は、XSLTという仕様の存在により可能となっている。この変換の仕組みはB2Bのそれぞれの企業が連絡をとるとき、または「ハブ」同士が連絡をとるとき、効力を発揮する。

DTDとXMLスキーマ言語

XMLには「タグ」の規定を守れば自由に記述できる「Well-formedなXML」もあれば、データの種類や構造について規定を行う「Well-formedでないXML」の２種類がある。
自由に記述できるＸＭＬも魅力的であるが、B2Bにおいてはある程度規定されたXMLも魅力である。それはある程度データのValid CheckをXMLの処理部分（XMLパーサーの部分）でできるからであり、アプリケーションではデータのもっと業務よりのチェックに専念できるからである。B2Bでデータの規定を行うにあたって格好となる規定が、「XMLスキーマ言語」である。

「XMLスキーマ言語」で最も代表的な言語は、SGMLから引き継いでいる「DTD」である。今後標準となっていくだろうと言われるものに「XML-Schema」と呼ばれるものがあり、現在W3Cで規定を進めている。他にもマイクロソフトで進めている「XDR」（XML Data Reduced）や、日本IBM所属の村田真さん推奨の「RELAX」などいくつかの「XMLスキーマ言語」が存在する。
これらは方言みたいなもので、今後どの言語が主流になるかは不明であるが、以下の理由で、企業間システムにおいてはDTDは「XML-Schema」または他の方言に吸収されていくだろうと見られている。

DTD自身がXMLのフォーマットになっていない。XMLを処理する上で、統一されたフォーマットで処理できないのは、プログラムの効率上望ましくない。
DTDでは、「整数」、「不動小数点数」、「文字データ」、「日付データ」などといったータの種類を細かく規定できない。また構造上も繰り返しがMAX何回までといったきめ細かな定ができない。
DTDでは、「名前空間」（ネームスペース）と呼ばれるXMLの規定に完全に対応できていない。「名前空間」というのは、部品化された複数のXMLのファイルを使用したりする時に、同じ名前の「タグ」名が出てきて競合するために「接頭語」を付けて競合を避けるための規定である。

大事なポイントセキュリティとXML

インターネットを企業レベルで普及させるための技術として流行している言葉に、「XML」以外に「PKI」という言葉があるのをご存知だろうか？
「Public Key Infrastructure」の略で、いわゆる公開鍵暗号技術のことである。
昔の「秘密鍵」のようにお互いが秘密裏に「秘密鍵」を保持し合い、その鍵で文書を暗号化するのと違い、「公開鍵」の技術は、「秘密鍵」は自分だけが秘密に保持し、「公開鍵」は一般に公開してしまう。相手に暗号化した文書を送りたい場合は、相手が公開した「公開鍵」で暗号化すれば、他の誰もその「公開鍵」では複合化できず、「秘密鍵」を持っている送り先しか複合化できないといった便利な暗号化の技術のことである。
この技術は逆に応用すると、自分の持つ「秘密鍵」で文書の最後に署名を付けておけば、相手方には「公開鍵」によってその文書が送り元の文書であることを証明できるし、また内容が改竄されてないことも確認できる。これを電子署名と呼んでいる。

インターネット上のB2Bの世界では、金銭的なやり取りはもちろんのこと、オープンな企業間やりとりの市場の中で、特定の相手同士だけで秘密文書をやりとりしたりする必要性が生じてくる。
こういった背景の中で、XMLのフォーマットで作成されたデータをPKIの技術で暗号化／電子署名することの必要性が求められている。

XMLの世界では、次の２通りの暗号化の方法が考えられる。

XML文書全体を暗号化する
XML文書の中の一部を暗号化する（図5）

前者においては、既にSSLの技術を使うなど実用段階である。
後者においては、XMLの標準推進組織である「W3C」(Worldwide Web Consotium）で現在「XML Signature」という名前の標準名で制定中であり、PKIを使用した暗号化や部分署名が可能である。

このこともあって世の中には、まだPKIを実装したXML関連の製品は見当たらないが、今後不可欠な技術であり、これを実装した製品がデファクトとして普及していく可能性を秘めているといえる。
XMLに期待を寄せている者にとっては、XML＋暗号化／電子署名の技術は、待ち遠しい融合技術である。

エピローグ

「XML」という言葉は、コンピュータ業界の中で普及する用語として、今年、来年あたりは横綱級になると思われる。セミナーで「XML」とタイトルに載せれば満員になるし、雑誌で「XML特集」と載せれば完売する。
大手ベンダーを含め各社「XML対応」をうたい始めてもいる。
市場調査のデータを見ても、B2B-ECと呼ばれている市場は2003年には70兆円弱（出展：通産省、アンダーセンコンサルティング）といわれているし、その中でXMLは主流なデータフォーマットとして使用されることになるだろう。

さて冒頭にも述べたが、今年第４四半期から来年度にかけてB2B-ECと言われている市場で最も期待されているのは、XMLをベースとしたものである。この「市場」で「ハブ」の役目を担うのがXMLであり、それを実現する製品がいま期待されている。

XML ｂａｓｅｄ B2B-ECが実現すれば、まるで築地の市場がインターネット上に再現されたかのように思えるであろう。

XMLをリードするインフォテリアでは、そろそろXMLのコア製品だけでなく、こういったB2B-EC市場形成を支援するような製品の開発といった期待にも、応えていかなければならないと認識している。

乞うご期待。

日時: 2001年07月25日 00:00 | 　| TrackBack

« １つ前のコラム |XMLノート：コラムの最新リストへ戻る| １つ後のコラム »

このページのトップ