SSブログ

光学薄膜設計ソフトの設計 その32 - なぜXML? [考え中 - 光学薄膜設計]

前回まで、答え合わせのために計算エンジンを単独で(GUI無しに)動かすことにした。そのために入力の形式を考えてみた。その結果XMLを使うことにしたけど、もうちょっとなんでXMLなのか、を考えることにする。

歴史をちょっとだけ

XMLはもとはと言えば1979年のGMLにさかのぼるらしい。Knuth先生のTeXが77年なのでちょっとあとだけど、文章とは別の情報をその中に埋め込むと言う「マークアップ」の考え方は共通している。でも形式は全然違ってしまった。GMLはそのあとSGMLとして標準化される。

SGML

SGMLでは基本的に

<タグ>データ</タグ>
という形式が使われ、これを入れ子にして木構造を表した。このスタイルがずっと続くことになる。

HTML

ずっとあと、といっても1989年にCERNのBerners-LeeがHTTPというプロトコルとHTMLという文書形式を考え出して、それを実際に動作する環境を実装した。CERNでは文書システムにSGMLを使っていたらしい。HTMLは同じマークアップの考え方でSGMLの形式をそのまま使った。ちなみにBerners-Leeのクライアント(ブラウザ)の実装はWorldWideWebと言う名前でNeXT(Mac OSXの前身)の上にObjective-Cで書かれていた。今でもソースをダンロードすることができる。idが省略されたり、appkitだけがインポートされたり(NeXTの当時はFoundationが分離されていなかった)と今とはちょっと見かけが違うけど、まさしくObjective-Cである。非常に小さなソースで特に表示にまつわる部分のコードは極端に少ない。これが20年以上前のものと言うのは面白い。

HTTP/HTMLはNCSA Mosaicというポータブル(Cで書かれていた)でフリーなブラウザが作られて移植され爆発的に広がった。ちなみに僕もかなり長い間(HP-UX上の)X Window版とMac版のMosaicを使っていた(Netscapeをみんなが使うようになった頃、自分のマシンのMosaicで表示させたページを人が見て「なにこれ、地球が回ってる」と言われた。Mosaicはサーバからの応答を待つ間すみっこのアイコンの地球がアニメーションでまわった)。

HTMLのぐちゃぐちゃ

HTMLはそれからどんどん拡張され、どんどんぐちゃぐちゃになって行った。もともとのSGMLは文書が特定のハードやOSに依存するのを避けるために作られたのに、HTMLはOS依存、機種依存、バージョン依存を深めていった。またHTMLはもともと文書の構造を表現するものでその構造に従って表示されるものだったのに、表示や見かけを制御するためのタグがどんどん増えて行った。それに伴ってHTMLのサーバ(送り出し側)も矛盾するタグやそもそも入れ子になっていない、閉じていないなどというシンタクスのレベルの問題を持つ文書が現れ、さらにクライアント(ブラウザ側)はそれでもなんとか表示しようと解釈の問題を持ち込んだりしてさらにぐちゃぐちゃになった。

XML

そのぐちゃぐちゃを横目で見ながら、SGMLを使いやすくしようと言う動きがでた。SGMLは大きな仕様だったので、シンプルであることがまず目指されたらしい。XMLはHTMLとは独立な動機で始まったけど僕はHTMLの混乱が反面教師として働いていると思う。

シンプルで厳密なXMLが逆にHTMLに影響を与えてぐちゃぐちゃのHTMLはうんざりでもうやってらんねーと言う人たちがXHTMLを作った。そりゃそうだわ。これはXMLのフォーマットでHTMLと同じようにタグに意味を持たせたもので内容と表示は分離され、シンタクスを厳密にして解釈の問題が発生しないようにした。他にもサイトの中身のサマリをやり取りするためのRSSはXMLのフォーマットそのものになっている。

冗長なXML

XMLはSGMLをもとにしているので、表現は冗長である。

<タグ>データ</タグ>
は、たとえば適当なデリミタとしてスペースを使って
<タグ データ>
としても同じことが表現できる(パースもこっちの方が簡単)。にもかかわらずこうなっている理由は僕にはよくわからない。

unixとデータ形式

外部データ形式としてのテキスト

昔からunixは、外部データ形式(データファイルなどの中身)はテキストであるべし、と言う思想があった。これは

  • 可搬である(エンディアンやビット幅などによらない)
  • 人間が直接読める
  • テキストエディタで編集でき、専用のエディタが不要
  • オープンである(バイナリではどんな情報が埋め込まれているかわからない)
というシンプルな理由からだった。unixではシステムが利用する設定ファイルなどはすべて(passwdファイルなどを例外として)テキストでvi等のエディタで直接編集して使うようになっている。

しかしプログラムで利用するためにはテキストを読み込み、それを内部形式に変換し、書き出すときはまたテキストに変換するということをしなければならない。特に読み込んで解釈して変換する部分はプログラミングの重荷になった。

yacc/lex

そこでyacc/lexが作られた。これは文法を記述するとテキストを読み込んで内容を解釈するコードを書いてくれると言うすごいもので、これを使ってインタプリタやコンパイラのコードまで作ることができる。

yacc/lexのおかげで、そこそこ複雑な形式のテキストファイルでも簡単に内部形式に変換できるようになった。逆にデータの構造を表現するための文法はソフトウェアそれぞれで違ってしまい、ユーザはいちいち勉強し直す必要があったり、あるソフトではスペースや改行が区切りに解釈されるのに違うソフトでは無視される、などということが起こってきた。

Mac OSXとXML

Macもその基礎はunixそのものなので基本的な外部データ形式はテキストである。しかし他のunixとちがってそれを意識することはないようにエンドユーザからは隠蔽されている。従ってそれがどんな文法なのかは普通は知らなくても問題ない。

しかしMac OSX用のプログラムを書こうと思うと気にしなければならなくなる。そして書き始めるとOSXでは単なるテキストよりはXMLが多く使われていることがわかる。

プロパティリストとNSUserDefaults

プロパティリスト(propertyListあるいはplist)と呼ばれる、NSArrayやNSDictionaryといった基本的なオブジェクトをファイルとして外部に出力するためのフォーマットがある。これは現状デフォルトではXML形式になる。

プロパティリストには

  1. ASCII
  2. XML
  3. バイナリ
という3つの形式がある。ASCIIはNeXTStep時代から使われているものでold-styleとも呼ばれる。

XMLが新しい標準のプロパティリストの形式で、アプリケーション本体の情報が書かれている*.app/contents/info.plistは代表的なものである。バイナリはまさしくバイナリで先頭のbplist00という8バイト以降はテキストエディタでは読めない。

また、NSUserDefaultsは10.3まではXMLで保存していた。ホームディレクトリのライブラリの中にあるPreferencesディレクトリはNSUserDefaultsが使うデフォルトのディレクトリでアプリケーションの設定などの情報をプロパティリストで保存してある。ちなみに10.4からはなぜかバイナリに変更された。plutilというプロパティリストの形式を変換するコマンドラインユーティリティ(/usr/bin/にあるのでターミナルを開いてplutilと打てばNo files specified.のあとにヘルプが表示される)がある。まあ、普通の人には関係ない。

汎用のXMLパーサは?

こうやってMac OSXではたくさん使われているにもかかわらず、10.4でNSXMLDocumentなどのクラスがFoundationに入るまでは汎用のXMLパーサがなかった。当時はexpatなどのライブラリを別途インストールする必要があった。昔、僕は会社で使うあるデータの形式をXMLにしてプリ/ポストプロセスをMacに書いた(処理本体はある有名なソフトウェア)。そのときexpatを使ったけどexpatはCベースでobjective-Cに比べれば難しく、バカちょんで使うと言うわけにはなかなかいかなかった。

10.4(Tiger)になってObjective-Cベースのパーサが標準で手に入り、ずっと便利になった。そのために追加されたクラスはあとで整理する。

それで?

ということでWWWとローカルなファイルの両方がXMLの形式で表現されるようになってきた。そしてやっとobjective-Cで使えるパーサが手に入った。これから新しくソフトを作るなら自前の文法を決めてパーサを作って、ということをする必要はなくなった。ということでなぜXMLか、という疑問に対する答えはほとんど自明である。

しかし、もちろんデメリットもある。

XMLは大きくて読みづらい

XMLはテキストの上に冗長なため大きいのと、まさしくそのせいで非常に読みづらい。大きなXMLファイルの中の必要な部分をテキストエディタで探そうとしたら大変。<タグ>というのが字面として重くて内容が埋まってしまう。結局、頻繁な編集には専用のエディタが必要になってしまう。

専用データ形式としての可搬性とは?

また可搬性も今回の場合のような専用のデータ形式としてはあまり意味がない。あまり汎用性のないデータにとって、データを共有するための形式で書いたからと言って急に他所から使われるようになると言うことは当然ない。

パースの後の処理

XMLでは入れ子を簡単に表現できるが、それを解析した後は、例えば再帰呼び出しで簡単に書けるかといえばそうではない。構造が入れ子になっているだけで、その意味は入れ子のレベルごとに違っている。XMLのパーサを使ってそれに従った内部データ構造を作ろうとすると非常に汚い(読みづらい)コードになりがちである。

可塑性

またかなり固い形式(シンタクスが厳しくそのチェックが備わっている)ということは逆に言えば可塑性に乏しいと言うことで、一旦タグを決めてしまってから拡張しようとすると面倒なことになる場合が多い。これは先のきれいなコードを書くことの難しさと相まってちょっとした変更が大事になってしまう、ということが往々にしてある。

とはいうものの、

そう、とはいうものの、せっかくFoundationに標準的に入ったのだから試しに使ってみよう。

ということでデータファイルの形式を決めると言うことは、XMLのタグを作ってその意味を決める、ということと同じになる。次回はそれを具体的に進める。


nice!(0)  コメント(0)  トラックバック(0) 

nice! 0

コメント 0

コメントを書く

お名前:
URL:
コメント:
画像認証:
下の画像に表示されている文字を入力してください。

トラックバック 0

献立03/10献立03/11 ブログトップ

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。