最短のXML入門とメタ言語：XMLを学ぼう（1）
XMLとはなにか、どんな仕組みなのか。注目されつつもその実体はなかなか分かりにくい。そうした疑問を技術的な側面から、毎回ズバリと解説するのがこの連載だ。第1回では、XMLとはなにか、という問いに簡潔に答え、さらにXMLの本質であるメタ言語について、その意義と役割について明らかにしていく。
最短のXML入門
まず、せっかちな読者のために、最短のXML入門を手っ取り早く書いてしまおう。
XMLはメタ言語である。メタ言語とは、言語を記述するための言語という意味である。言語というのは、Webページを記述するHTMLやC言語などである。つまり、XMLの本質は、こういった言語を作るために、言語の構造を記述する手段を提供するものである。これで分かる通り、XMLの本当のユーザーは、新しい言語を自分で作る人達である。
新しい言語を自分で作ると言っても、好き勝手な文法を自分で決められるわけではない。基本構造は、XMLがあらかじめ規定したものがあり、その範囲内での構造を自由に決めることができる。ユーザーが自由にできるのは、要素や属性を定めることと、その並び順の有効な範囲を定めることだ。
■一単位の情報「要素」
要素（element）というのは、<要素名>で始まり、</要素名>で終わる一単位の情報である。HTMLを知っている人なら、お馴染みの構造と言える。ただし、HTMLと異なり、終了タグ(</要素名>)は省略できないのがXMLの決まりだ。そして、XMLを使うということは、要素名を自分で定めるということを意味する。
内容が存在しない要素は、HTMLではただ<要素名>と書いたが、XMLでは、<要素名/>と、要素名の後に"/"を付加するルールになっている。
■付加的な情報「属性」
属性（attribute）は、開始タグの中に書き込む付加的な情報である。例えば、<img src="a.jpg">と書いた中で、src="a.jpg"の部分が属性にあたる。srcが属性名で、a.jpgが属性の値である。このように属性は必ず属性名と値のペアで登場する。
さて、要素や属性の名前を自分で考えたとして、それをコンピュータに伝えるにはどうしたらよいのか。そのためには、スキーマというものを記述する。スキーマも一種の言語であり、それを記述するルールが存在する。XML用のスキーマにはいくつかの種類がある。主要なものとしては、XML 1.0仕様書の一部として記述されているDTD（Document Type Definition）、W3Cが制定作業中のXML Schema、日本発のスキーマ言語RELAX(REgular LAnguage description for XML)などがある。
通常は、このスキーマで定めたルールに従って要素や属性を記述したXML文書を作成する。作成されたXML文書は、スキーマと照合して、本当にルール通りに記述されているか自動的にチェックすることができる。このチェックを行うツールを、バリデータ（Validater）と呼ぶ。
いちいち形式的な手順を踏むだけのメリットがない場合には、スキーマを書かずにXMLを使うという選択もあり得る。これは、整形式のXML文書というものを使うことによって実現する。整形式のXML文書というのは、要素や属性に関するチェックを一切行わない形式のXML文書のことで、スキーマの指定なしに利用できる。とはいえ、何を書いても許されるということではない。当然、機械的なスキーマ言語を書かないというだけで、どんな要素がどんな意味を持つのかは、あらかじめ考えておかねば、意味のあるXML文書は書けない。これは、スキーマを日本語で書く、と考えれば分かりやすいだろう。もちろん、日本語で書かれたスキーマでは、バリデータによるチェックはできない。XML文書が定めたルールに沿って書かれているかをチェックするには人間が目で見て行うしかない。だが、最初のサンプルでは、なるべくカンタンに済ませるために、日本語でスキーマを書くということを考えてみよう。
では、こんなスキーマを考えてみよう。
- ルート要素名（最初と最後に書かれ全体を挟むタグ名）としては、<doc>を使う
- 段落を記述するために、<p>というタグ名を使用する
- <doc>の内容としては<p>だけを許す。ただし何個出現してもよい
- <p>の内容としては文字列だけを許す
このルールを「シンプルサンプル言語」と呼ぶことにしよう。
シンプルサンプル言語でXMLを考えてみる
このサンプルには実用性はあまりないが、明確な文法を定めているという意味で1つの言語と呼ぶに値する資質を備えているのである。つまり、XMLを利用して新しい言語を生み出した、といえるのである。
では次は、XMLを利用して生み出されたシンプルサンプル言語を利用して、文書を記述してみよう。プログラム言語の入門などでは、最初に"Hello! World!"と書かせるのが習わしなので、シンプルサンプル言語を使って、"Hello! World!"という文を含む文書を作成してみよう。
正解は以下のようになる。
<doc><p>Hello! World!</p></doc>
おそらく、HTMLの書き方を知っている人であれば、上記のスキーマとこれを見比べれば何がどうなっているのか、すぐに分かると思う。このルールに従った他のXML文書を作成することも難しくないだろう。
■XML宣言も付け加えよう
さて、多くの場合、確実にXMLの定めるルールに従って記述されていることを示すために、XML宣言と呼ばれる行を先頭に付け加える。これを付け加えたサンプルは以下のようになる。
<?xml version='1.0' encoding='UTF-8'?> <doc><p>Hello! World!</p></doc>
XML宣言の記述は、作法としてこう書くことが決まっているもので、自分で記述する場合に変えてよいのは、encodingで指定される名前のみである。ここには、その文書がどんな文字エンコーディングスキームで記述されているかを記述する。文字エンコーディングスキームというのは、要するに使用する文字コードの種類のことであり、シフトJISやEUC-JPなどが該当する。つまり、これを明示的にXML宣言に書き込むことによって、文字コードを間違えることによって起こる文字化けを回避できるというわけだ。ここでは、JIS TR X 0015:1999 XML 日本語プロファイル（W3Cのテクニカルレポートとしても公開されている）が、Unicodeの文字エンコーディングスキームの一種であるUTF-16またはUTF-8の利用を推奨しているため、"UTF-8"を指定したサンプルを示している。もちろん、このサンプルを実際に保存して試す場合は、UTF-8形式で保存しなければならない。シフトJISなどで保存してはならない。
このサンプルは、バージョン5.0以降のInternet Explorerで、直接閲覧することができる。実際にWebブラウザから、どのように見えるかを体験したい方は、このサンプル体験文書をご覧あれ。
さて、ここまでで最小限度XMLについて説明すべきことは説明した。
■XMLを使うというのは、言語を設計することだ
結論をまとめると、本当の意味でXMLを使うというのは、新しい言語を設計し、スキーマを記述することを意味する。スキーマが定まれば、それに沿って文書を記述することができる。それは、XMLを使っているというよりも、XMLによって生み出された言語を使っている、と表現する方が適切と言える。誰もが言語を生み出す立場に立つわけではないから、本当の意味でXMLを使う必要に迫られる人は少数派かもしれない。しかし、今後、さまざまな言語がXMLを使って作成されることが予想されるため、XMLで作られた言語を利用するユーザーは、圧倒的な多数派となるだろう。その場合、XMLの基本ルールを知っているのと、知らないのでは、それらの言語の習得や活用に大きな差が生じる。それを考えれば、XMLを学んでおく価値は誰にでもあると言える。
つまりそれってどういう意味?
さて。ここまでの解説を読んだ率直な感想として、「難しい」「わかんねぇ」「どんな意味がある?」「こんなもの使い物にならない」「小難しいこと言わずにECに使う方法教えろ」というような否定的な感想を持った方々が多数派だと思う。それはもっともだと思う。筆者も、この解説は分かりにくいと思う。
しかし、ここに書いた最短のXML入門は、XMLの短く要約された解説としては適切だと筆者は考えている。
どちらの意見も間違っていないとすれば、結論は1つしかない。
XMLは分かりにくいのである。
そんなに難しいのなら、XMLを勉強するのはやめよう、と考えるのは早計だ。ここでは、どうして分かりにくいかを、吟味してみようではないか。ちょっとした発想の転換で、スラスラ理解できるような性質のものならば、ここで立ち去るのは、損である。
メタ言語であるという意味
XMLがそもそも分かりにくい理由は、XMLがメタ言語であるという事実に由来すると考えてよいだろう。なぜなら、メタ言語というものをコンピュータユーザーが意識することなど、これまで一度もなかったと言っても過言ではないからだ。メタ言語は言語を作り出す手段だから、これまで、それを使うのは言語を設計する特別な少数の人達だけだった。例えば、プログラム言語として有名なC言語の処理系（コンパイラ）の多くは、yaccと呼ばれるコンパイラコンパイラ言語で記述されている。コンパイラコンパイラ言語とは、コンパイラを記述するコンパイラ言語のことで、一種のメタ言語である。世界中にC言語を知っているプログラマが何千万人いるかは知らないが、彼らはC言語がyaccによって作られたことを知る必要はまったくないし、事実、ほとんどのC言語プログラマはそのことを知らない。C言語の処理系を作るために実際にyaccを使っているユーザーは全世界で十人ぐらいしか居ないだろう。その十人以外は、知る必要はないし、彼らにそれを伝える必要もない。つまり、プロフェッショナルでも知らなくて当然というぐらい、特殊な知識なのである。
このような背景があるために、メタ言語が、世間の話題になることは滅多にない。話題になるのは、メタ言語によって作られた言語の方で、それを作るために使われた言語の方は、まず話題にならない。その好例が、HTMLであろう。HTMLはSGMLというメタ言語によって作られた言語であるが、これだけHTMLが普及していながら、それがSGMLによって作られたことを知っている人は少数派だし、SGMLが何かを理解している人に至っては、本当に少ないのが現実だ。
だから、ふつうの状況であれば、XMLのようなメタ言語が話題になることはない。それを勉強しようとする人が街にあふれ、書店に解説書が並ぶようなこともない。それは、コンピュータサイエンスを専攻する学生や、プログラム言語などの基本ソフトウェアを開発するエンジニアや、一部のマニアだけが注目するものであったのだ。
だが、現実に、XMLに関して注目する人は多く、XMLを学びたいと考える人も多い。XMLブームとでもいうべきものが、現実に起こってしまったのだ。
■XMLは安上がりでカンタンに見える
もちろんブームが起きたことには、それなりの理由がある。インターネットの急速な普及によって、さまざまな情報をインターネット上で公開、交換しようという機運が高まってきたが、既存のHTML等では表現能力が足りないし、かといって、それまでそれぞれの業界や企業などが使っていたフォーマットはまちまちなので、交換性が保証できない。特定の組織や技術に依存しない中立の情報交換用のフォーマットに対する強いニーズが存在したのだ。その状況にジャストミートするかのように登場したのが、XMLである。XMLがほかのどんな試みよりも人々の心を捉えたのは、以下の2つの条件を満たしていたからだと考えられる。
- 分野ごとに特化した新しい言語を安上がりに作ることができる
- HTMLに似ていてカンタンそうに見える
この条件がいかに人の心を動かしたのかを、順番を追って考えてみよう。最初に、「インターネット時代には、分野ごとに特化した情報交換言語が必要」という認識があったと言える。だが、新しい言語を生み出す作業は大変な困難を伴い、時間も金もかかるのである。
そこに登場したのが、XMLである。XMLを使えば、ゼロから言語を作るよりも、短期間で安く新しい言語を作れる。これだけなら、単なるコストダウン効果しか無いわけで、大ブームになるにはインパクトが足りない。だが、それに加えて、カンタンそうに見えるという条件が加わると、インパクトは十分だ。XMLで記述された文書は、HTMLそっくりに見えるため、現実にそうである以上に、XMLはカンタンであるかのように、人々の目に映ってしまったのである。
かくしてXMLは大ブームとなってしまったのだ。
ここで重要なことは、メタ言語について真面目に取り組んだことがある人間が、非常に少ないということだ。
しかし、ブームである以上は、それに関する報道が行われる。すると、よく理解していない状態でいい加減な情報を書くライターも出てくる。それを真に受けて、さらに解説を書く者もいる。XMLとは何かという、ごくシンプルな情報ですら、報道ごとに違うことを言っていたりするほど混乱を来しているのである。
さて、どうすれば、この混乱から脱出できるのだろうか?
XMLは難しいから、天才以外はすべてXMLから手を引くべきなのだろうか?
そうではない。
混乱の根底にあるのは、メタ言語という概念に、大多数の人々が慣れていないことがある。しかし、メタ言語という概念そのものが難しいわけではない。
比喩を使って説明しよう。自動車の世界を例にすれば、メタ言語とは、設計図を書く手段にあたる。そして言語は設計図にあたる。実際に作成される文書は、実際の自動車そのものにあたる。
■設計と製造を取り違えるな
混乱が起きた原因は、設計図と自動車を取り違えたことにあると言える。もちろん、現実の世界で、設計図と自動車を取り違えるなどということはありえない。しかし、設計者と製造者を勘違いすることはあり得る。例えば、「この素晴らしいスーパーカーは真田志郎さんの作品です」と言われたとき、その真田志郎さんが設計したのか、それとも実際に自動車を製造したのか、戸惑うことはあるだろう。それと同じように、XMLを用いて開発された素晴らしいアプリケーションを指さして、「この素晴らしいシステムは、XMLで作られたものです」と言われたときに、XMLで設計したのか、XMLで製造したのか、混乱することはあり得るだろう。しかし、設計手段としてのメタ言語というものが存在するという予備知識が無い方が多数派であるコンピュータ業界では、このセンテンスは容易に誤解される。つまり、XMLは、他の多くの言語と同じように製造の手段だと思い込み、そのように報道されてしまうわけだ。
そして、製造の手段だと思い込んだ人達がXMLを学ぼうとすると、製造方法を期待しているにも関わらず、設計方法を教えられてしまい、混乱してしまうのである。
この混乱から脱出する方法は難しくない。XMLは自動車で言うところの製造の手段ではなく、設計の手段だと考えれば良いのである。
私は言語を設計する必要などないんですが……
ここまで読んで、「言語なんて設計する立場じゃないし、私には関係ないよ」と思った方も多いと思う。このまま読むのを中断して帰ってしまおうかと思ったかもしれない。
だが、その判断は、まだちょっと早い。
まず、XMLという技術が出現したことによって、新しい言語を作るためのコストが劇的に下がったという事実を認識していただきたい。これが何を意味するのか。これまで、既存の言語では帯に短したすきに長し、ということで不満があった人や組織も多い。そういう組織が、コストダウンによって、新しい言語を作ろうとする動きが出てくるだろうし、実際にそういう事例もある。あなたの所属する組織が、これまで自前の言語を作ったことがないとしても、この先も同じとは限らない。また、昨今のインターネットの普及により、紙媒体で行われていた組織間の情報交換が電子化される動きも活発だ。それらの情報を自動的に処理したいと思うなら、単なるワープロ文書を交換するだけでは駄目で、きちんとしたデータ設計を行った交換用フォーマットが必要とされる。これにより、従来、コンピュータ言語に無縁であった多くの職場で、新しい言語を作る機運が高まっている。
それでもまだ、そういう職場とは縁がないという人もいるだろう。どう間違っても自分が言語を作る側にまわるはずがない。
だが、たとえ言語を作る側にまわることがなくても、XMLと無縁では居られないのだ。
例えば自動車の場合、設計図に関する勉強が必要なのは、設計者だけだろうか?そんなことはない。製造の現場で実際に物を作る場合、設計図を読める人間が居なければ、仕事が進められないはずだ。
それと同じように、今後、コンピュータを扱う現場では、XMLを理解する必要性が発生してくる。
本当にそんなことがあるのか、と思う人も多いかもしれない。
だが、企業間電子商取引のような変革が進めば、自ら望まなくても、XMLで作られた言語で記述されたデータを受け取る立場になり得る。しかし、狭い業界の特定分野専用の言語に、懇切丁寧な初心者用の解説書が出版されることはあり得ない。つまり誰かに解説してもらうことが期待できないことも多いということだ。その時に、XMLに関する知識を持っているのと持っていないのでは、仕事の円滑さに大きな差が生じるだろう。
つまり、いくらかでもコンピュータに関わる者であれば、知っておく価値がある基礎素養、それがXMLなのである。
次回以降、この連載でやること
この連載の目的は、XMLについて学ぶということだ。だが、この意味を狭い意味に捉えるつもりはまったくない。
比喩として設計図と自動車の例を上げたが、設計図というのは、自動車の構造だけしか描けないわけではない。実際には船にも飛行機にも設計図がある。それと同じように、XMLも、様々な言語の設計に使用できる。電子出版のような文書も書ければ、リレーショナルデータベース的なデータの記述にも使用できる。それどころか、XMLでプログラム言語を作るという試みすら存在するのである。
「そんないろいろ使えてもしょうがない」と思うかもしれない。「私のやっている分野だけ詳しく説明してよ」と言う人もいるかもしれない。だが、XMLはビジネスチャンスの宝庫である。だれも思い付いたことがないような新しいXMLの応用をだれが考え出すか分からない。もしアイデアが浮かんだら一攫千金のチャンスである。会社を辞めてベンチャービジネスを起こすことも可能だ。そういう意味で、幅広い応用分野を知ることには、大きな価値があると考える。
また、XMLはXMLだけで完結する技術ではない。XMLをより良く利用するために、その周辺にはさまざまな技術が存在している。例えば、スキーマ言語、スタイルシート、リンク言語、グラフィック言語、マルチメディア言語、などがある。これらの言語を部品のように活用することによって、新しい言語を設計する場合の手間と時間を大幅に減らすことができる。すでにある言語で実現されている機能をあらためてもう一度設計する必要などないのだ。これらの言語についても、XMLを活用するための重要な要素として、順次紹介していきたい。
それでは次回、また会おう。
Copyright © ITmedia, Inc. All Rights Reserved.