最近では XML を扱うことも多くなってきましたが、そもそもなぜマークアップ言語が Web で利用されているのかを今回は考えてみたいと思います。
Web の職業訓練学校に行っても、なぜか教えてもらえないこの疑問。こういう「そもそもなぜ？」という部分は マークアップ言語に限らず説明されることは少ないようです。その原因はきっと日本の教育というのが詰め込み型で、プロセスの理解を放棄している点にあると思います。方程式だけ覚えて、解答用紙に答えを書けば良い成績が得られるという教育では、創造のための思考法を習得できず、また「そもそもなぜ？」という疑問を持つ事自体いけない事のように扱われ、やがてそれは習慣になり、型通りのアウトプットしかできない人間が大量生産されるという残念な結果を産みます。
ただ、実際ぼくも誰かに教わったわけではなく、独学で理解してきたので間違っている点もあるかもしれません、なので「あー違うよそれ」っていう部分があればご指摘ください。
マークアップ言語は構造化言語とも呼ばれます
構造化言語と呼ばれる以上、構造化するための言語です。では構造とはそもそもなんのことなのでしょうか？
- 構造
- 一つのものを作り上げている部分部分の材料の組み合わせ方。また、そのようにして組み合わせてできたもの。仕組み。
簡単にいうと、仕組みや形に決まりを設けるといったことでしょうか。
つまり構造化言語とは、コンピュータで扱うためにデータの作り方に決め事をつくるための言語ということになります。
では実際の例を基にして考えていきましょう。
HTML はそもそも異なる OS で異なるフォーマットのデータを扱っていた時代にできたものらしいです。
その頃は例えば簡単な文書ファイルでさえ A という OS と B という OS で共有するのは非常に困難なことであったらしく、せっかくコンピュータでデータを管理しているのに、そのファイルはそのコンピュータでしか扱えず、「やあサム、こいつをランチの後で見といてくれよ」といってフロッピー等を渡しても、「オー、トーマスこのデータ俺のコンピュータじゃ開かなかったよ。えっ？ 何故昨日言わなかったかって。昨日はサンディとデートだったんだ」みたいなことが日常茶飯事だったに相違ありません。
極端なはなし、これでは紙の文書のほうがはるかにマシです。
そこで共有するためのフォーマットとして HTML が考えられたみたいです。
HTML という共有を前提とした単純なフォーマットをつくり、そのフォーマットを解析するための共通の決め事をつくります。その決め事に従って文書を作成すれば、トーマスがサムのせいで上司に大目玉を食らうこともなくなるわけです。
つまり HTML は世界で最も普及している人工言語。コミュニケーションツールであるわけです。
コミュニケーションにはルールが必要です。ひとつの国には一つの公用語というのがあります。日本で言えば日本語、イギリスで言えば英語です。ほかにも狭い道でひととすれ違う時にはお互いに道を譲り合う等、社会には様々なルールがあり、それらによって混乱や無意味な衝突がさけられているわけです。ブラウザで閲覧できる画像フォーマットが jpg や gif など、限られたものであるのも混乱を避けるためのルールです。
構造はなぜ必要なの？
前述のとおり、コンピュータによる解析を行うためです。
当初 HTML は非常に単純で、文書をただやりとりするためにつくられましたが、それが一般にも普及するに従って、もっと便利に、もっと楽しくする必要がでてきました。それらは全てがユーザーが望んだことではありません。それを望んだのは創造的なエンジニアやビジネスパーソンです。
なぜって、そうすると世界が変わるからです。そうすればもっとお金が儲かるからです、そうすれば人々の生活が豊かになると考えたからです。
HTML はよく「ユーザーには関係ないから」といわれ、ないがしろにされて、一時は table レイウトなんてものが流行りましたし、今でも div 要素ばかりのマークアップもみかけます。確かに、一見ユーザーには関係がなさそうですが、それは間違いです。より豊かな体験のため、もっと楽しい Web のための縁の下の力持ち、それが HTML であり、マークアップ言語です。
「コンピュータで解析って、うちのつくってるのはプログラムなんて入ってないから関係ないね」という考え方もあるようですが、ちょっと待ってください。 Web で公開している情報は、あなたの為に公開しているのでしょうか？ 公開されている情報は、みんなで共有するためではなかったでしょうか？ もしあなたが独裁者で、国民が飢えて死のうと何も思わないようなら、もう何も言えません。しかし良識と知性を兼ね備えた民主国家の国民であるなら、より多くのひとの利益が社会を豊かにし、それは必ず自分の生活を豊かにすることを識っているはずです。
例えばあなたの公開している情報の一部があるひとたちにとっては非常に価値の高いもので、彼らがそれを活用したいと思ったとします。彼らはプログラムを使い、その情報の一部を抽出し、常に最新の情報をどこかで利用しようと思っているかもしれません。
ところがあなたの HTML は見出しがどこで、どこが本文かわからない、哀しい table レイアウトだったとしたら、多くのひとはそこで断念せざるをえません。あなたの情報が産み出すはずだった価値は、もう二度と日の目をみないでしょう。
ぼくたちは現実でも Web でも、自分の知らないところで誰かに助けられ、誰かを助けています。それはひょっとすると大きな富を呼びこむきっかけになるかもしれませんし、あるいは名声を得るチャンスかもしれません。ところが最低限のルールすら守れなかったために、それは一生得る事のできないものになってしまうかもしれないのです。
他にも、非常に分かり易い例が JavaScript を使った DOM の操作です。 HTML 文書の DOM しかり XML での Ajax しかり、それはルールに従った構造があって初めて成り立つものです。
でも実際そんなことやってるとこ見た事ない
そうなんですよね。全くないわけでもないんですけど、例えば Google の検索結果などでは Microformats や RDFa などが活用されているわけですし。
大きな問題としては、現在の Web 上にあるドキュメントの多くが正しく構造化されていない点にあります。なので、今後より意味的に構造化（セマンティック）された HTML が増えれば活用例も増えていくと思われます。
仕組みや形に決まりを設けるっていうけど XML は自由じゃないの？
確かに、ルート要素があり、タグを閉じるというのが最低限のルールで、パーサ（構文解析器）によっては、 XML 宣言すら要らないものもあります。
しかしだからといって、勝手に、無数に新たなタグをつくっていくためにあるのではありません。そしてそれはあなたにとっても、あなたの情報を利用する誰かにとっても、非常に高いリスクを孕みます。
XML とは拡張可能な構造化言語と訳されます。拡張というくらいですから、基になるものがあり、それを拡張する目的のために考案されたと考えるべきでしょう。
では基になるものとは何でしょうか？
それは語彙（ボキャブラリ）と呼ばれるある目的を持った意味的な情報構造をつくるためのルールです。
では実際に語彙がどういったものであるのかを理解するために、 Atom を例に考えてみましょう。
Atom はブログなどで RSS を配信するのに使用されることで有名です。正確にいえば RSS は別の語彙になりますが、ややこしいので、ここでは Atom を RSS を配信するための語彙としてはなしを進めます。実際 RSS や Atom のはなしは一冊の本になるほどです。詳しい情報を知りたい方は「Web開発者のためのRSS & Atomフィード」という本がオライリーより出版されているので、そちらを読んでみてください。
さきほど語彙には目的があるといいました。 Atom の目的はコンテンツの配信（ RSS の配信）です。他にも Atom をインターフェースとしてブログにポストするといった使い方もありますが、ここではコンテンツ配信という機能ではなしを進めていこうと思います。
Atom の基本的な構造は以下のようになります。
<feed xmlns="http://www.w3.org/2005/Atom"> <title>Example Feed</title> <link href="http://example.org/"/> <updated>2003-12-13T18:30:02Z</updated> <author> <name>John Doe</name> </author> <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id> <entry> <title>Atom-Powered Robots Run Amok</title> <link href="http://example.org/2003/12/13/atom03"/> <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id> <updated>2003-12-13T18:30:02Z</updated> <summary>Some text.</summary> </entry> </feed>
本題ではないので説明はごく大雑把にすると feed がルート要素になります。その中には entry 要素があり、この中が記事の内容です。 title は記事のタイトルで link は記事の URL で updated は記事が更新された日時です。
このように、それぞれの要素には意味があり、要素の意味に基づいた情報がそこに記述されることによって、意味をもった構造というのができあがります。
構造にはルールがあり、そのルールに基づいた解析というのが行われます。こういったルールによってアプリケーション（この場合は RSS リーダー）は正しく動作することが保証されます。
このように、意味的に構造化され、構造の目的とルールを公開された語彙を基にグローバルな開発が可能になります。
電池等にも国際規格があり、大きさや形状が標準化されています。それによってぼくたちは規格の異なる大量の電池を買い込まずにすんでいるわけですから、標準化や規格化というのがどれだけの無駄を省くのかは容易に想像可能です。そしてその無駄な時間を新しいものの開発や、個人の趣味の時間に当てる事が可能になります。
もちろんベースにするのは Atom でなくても構いません。何が主な情報かによってそれは変わります。人物関係を主に記述したいのであれば FOAF をベースにするべきでしょうし、数式を記述するための MathML というのもあります。
XML の拡張
ベースに使う語彙は、必ずしも表現したい情報を全てカバーしているとは限りません。
そこで語彙の拡張という概念が役立ちます。
仮に Atom の中に自分オリジナルの語彙（タグと考えてもかまいません）を追加したいとします。仮になので、この際何のために行うかは気にしないでください。
Atom には Atom の語彙群があります。そのオリジナルを壊してしまえばアプリケーションは誤動作してしまうので、オリジナルの構造は保持します。
先ほどの Atom に自分でつくった参考文献を列挙するための要素を追加してみましょう。
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Example Feed</title>
<link href="http://example.org/"/>
<updated>2003-12-13T18:30:02Z</updated>
<author>
<name>John Doe</name>
</author>
<id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>
<entry>
<title>Atom-Powered Robots Run Amok</title>
<link href="http://example.org/2003/12/13/atom03"/>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2003-12-13T18:30:02Z</updated>
<summary>Some text.</summary>
<reference>
<li>参考文献の名前</li>
<li>参考文献の名前</li>
</reference >
</entry>
</feed>
これで一応拡張はされました。アプリケーションで利用される多くのパーサは理解不能な要素がでてきた場合には無視するので、問題がないようにおもわれます。
しかし今回は Atom では定義されていない reference と li という要素を追加していますが、もっと沢山の要素を追加していった場合には Atom で定義されている要素名とカブってしまう恐れもでてきます。そうなった場合、パーサはそれが Atom の要素なのか、追加された要素なのかが分かりません。それが基で誤操作してしまえば、拡張というのは非常に危険な行為になってしまうのですが。
それを解決する方法は既にあります。というか解決できているから拡張可能をうたっているわけです。
違う語彙で同じ名前の要素があり（衝突しているといったりします）、それらを別の物として識別する方法を名前空間といいます。
名前空間。なにやら学術的で難しそうに思うかもしれませんが、考え方としては単純です。
例えば、青森県に太郎さんというひとがいるとします。そして岡山県にも太郎さんがいて、彼らは共通の友人をもっていたとします。友人は太郎さんのはなしをする場合に、それが青森の太郎さんなのか、岡山の太郎さんなのかを分かってもらうために、「青森の太郎さん」と「岡山の太郎さん」という言い方をするでしょう。名前空間とはこれと同じ考え方です。実際には同じ地名に住んでいる場合も考えられるので、正確には地名は名前空間にはなりません。名前空間で実際に使用されるのは URI です。つまりグローバルな唯一の識別子です。
Atom の名前空間は http://www.w3.org/2005/Atom になっています。これは feed 要素の属性として宣言されているため feed 要素の中にある要素は全てこの名前空間に属します。
では今度は名前空間を宣言した上で同じ名前の要素を追加してみます。
<feed
xmlns="http://www.w3.org/2005/Atom"
xmlns:mytag="http://vosegus.org">
<title>Example Feed</title>
<link href="http://example.org/"/>
<updated>2003-12-13T18:30:02Z</updated>
<author>
<name>John Doe</name>
</author>
<id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>
<entry>
<title>Atom-Powered Robots Run Amok</title>
<link href="http://example.org/2003/12/13/atom03"/>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2003-12-13T18:30:02Z</updated>
<summary>Some text.</summary>
<mytag:link href="http://vosegus.org/myurl"/>
</entry>
</feed>
追加した名前空間は http://vosegus.org で接頭子（短縮した名前だと思ってください）を mytag としています。要素は <mytag:link href="http://vosegus.org/myurl"/> というのを追加してみました。
このようにして、名前空間を追加し、それに関連づけられた接頭子をタグの前につける事によって、 Atom の要素とは別物だと識別できる仕組みになっています。
そして Atom の名前空間には接頭子がないので、接頭子のないタグはすべて Atom の語彙として処理されます。
追加する語彙は新たに作成する必要がない場合もあります。そういった場合は既にある語彙の名前空間を宣言し、接頭子で関連づけを行えばいいわけです。
語彙をむやみに作成しない理由は単三電池の規格と同じです。同じ目的のものをそれぞれがバラバラにつくっていたのでは多くの無駄を産み、それは量が増えるほど開発コストを増大させ、グローバルな利用が困難になってしまいます。
そして、既にご存知かと思いますが、最も有名な語彙は XHML です。 XHTML は XML の語彙ひとつで、名前空間の利用により、拡張することが可能です。ただ、それをブラウザがどう解釈するのかはわかりませんが。
HTML が XML の語彙のひとつであると考えれば、何故意味的な構造にするべきかを理解するのは容易いと思います。