«前の日記(2003-05-07) 最新 次の日記(2003-05-09)» 編集

Matzにっき


2003-05-08 [長年日記]

_ [格言]Quote of the Day

[ruby-talk:70817]より:

THANK YOU MATZ for a scripting language where parts don't snap off
the objects and choke small children.
-- Rasputin

お子さまにも安心なRubyをどうぞ、ってか。

_ [家族]風邪再来

次女が熱を出した。また風邪かしら。 この冬から春にかけてわが家はたびたび風邪に襲われている。 これで何度目か。

_ [プレゼン]IPSJ-HI 103

来週金曜日に開催される「第103回ヒューマンインタフェース研究発表会」のプレゼンテーション資料を書きはじめる。

昨年松江で開かれたソフトウェアシンポジウム2002のキーノートを聞いた中小路先生が呼んでくださったのだ。 タイトルは「インタフェースとしての言語のデザイン:Ruby」というもの。 プログラミング言語はユーザインタフェースであるという(私にとってはいつもの)話をすることになる。 ユーザインタフェースという観点から見た言語デザインが一般のインタフェースのデザインに役に立つように還元できるといいなあ、と思っているのだが、はたして。

プレゼンテーション資料は公開する予定。

_ [YAML]XMLとYAML

YAMLの方が1024倍良いという主張をより明確にしたい。

まず、前提から。前にも述べたがあらゆる局面でYAMLがXMLより優れていると主張するつもりはない。 YAMLは基本的には構造データ表現フォーマットである。 文章のマークアップの領域でXMLと競うのは無意味だ。「YAMLの方が良い」という主張は当然「汎用データ表現」、 今月のLinux Magazineで使った用語を使えば「メタ・データフォーマット」として、という意味だ。

では、そのような前提のもとに、なぜYAMLが優れているか。

  • データ量

    XMLを採用するとデータが膨らむのは多くの人が経験している通りだ。 その理由はテキスト形式を採用していることもあるが、なによりもあのタグ形式が原因だ。 XMLってなんであんなに冗長なんだろう。その点、YAMLは記号とインデントで表現がコンパクトである。

  • 可読性

    YAMLの表現がコンパクトであると言うことは、すなわち読みやすさにつながる。 もちろん、YAMLだって万能ではないので、読みにくいYAMLは当然あるわけだが、 YAMLで読みにくい構造データは、当然XMLでも読みにくい。逆は必ずしも成立しない。

  • 柔軟性

    XMLとYAMLを比較すると、XMLの方が圧倒的に柔軟性が高い。 XMLはスキーマによってあらゆる構造が表現可能だし、 「構造データも表現できる柔軟性がある」というだけで、構造データ表現専用というわけではない。 一方、YAMLにもYOD(YAML OK Document)というドキュメント形式があるが、 やはり構造データ表現のためのフォーマットと考えるべきだ。 YAMLは「XML+スキーマ」と同等の位置づけになるだろう。

    柔軟性がある方とない方を比べたら、ある方が良いように感じられるかもしれない。 しかし、なんでもできるツールが使いやすいツールとは限らない。 むしろ目的に適合したツールの方が優れたツールである可能性のほうが高いだろう。 また、過度の柔軟性は人間に優しくないことを覚えておくべきだ。

  • 使いやすく、現実に即したAPI

    XMLを解析するAPIとしてはDOMやSAXがある。 しかし、構造データ表現のためには整形式では情報が足りない。 XMLを読み込んで取り出したノードからプログラム側で適切に型変換してやる必要がある。 XMLスキーマには型情報が含まれる(らしい)が、お手軽にXMLスキーマを使えるAPIってあったっけ。 一方、YAMLはロードとセーブのふたつのAPIでとりあえず利用できます。 YAMLデータは型情報を含んでいますから、型変換を気にする必要はありません。

「XMLは現代のS式」と呼ばれることがある。 どのような構造データもとりあえず表現できるという点ではその通りだろう。 しかし、一般人に広く知られてしまったという点でS式より罪は深い。 『図解で分かるS式とLisp』なんて本は今までもこれからも出版されないだろうし。

追記: 「YAMLが良い」という主張にもうひとつ暗黙の前提があるのに気がついた。それは「人間が読み書きする可能性がある」という点だ。人間の目に触れないならYAMLである必然はないものね。

本日のツッコミ(全8件) [ツッコミを入れる]
_ なひ (2003-05-09 16:32)

「お手軽にXMLスキーマを使えるAPI」ですが、<br>「型付き構造データ表現」が前提であればSOAPがそれです。<br><br>前提として上がっている「人間が読み書きする可能性がある」「マークアップでない」「汎用データ表現」「構造データ表現」「メタ・データフォーマット」と、比較のために上がっている項目の対応が薄いように思います。型とかAPIとか。<br><br>XMLとYAMLを直接比較することの無意味さについての主張:[ruby-talk:67253]と[ruby-talk:54657]

_ なひ (2003-05-09 16:34)

「続く」とのことなのでツッコミしてみました。<br>Linux Magazineを立ち読みしにいかなきゃ。

_ まつもと (2003-05-09 17:10)

私は言語屋なんで、言語としての側面だけから比較しているのかもしれません。が、型とかAPIは「人間が読み書きする」「マークアップでない」「構造データ表現」を行う「メタ・データフォーマット」に必須だと思っていますから、私の観点からは関係は薄くないです。<br><br>「SOAPがそれ」というのはまったくもってその通りだと思いますが、不幸なことにYAMLが向いている分野で(単なるXMLでなく)SOAPを使おうという話にはなかなかならないですよね。私はSOAPについては表面的な知識以下しか持ってないので、断言するのは危険ですが。<br><br>最後に[ruby-talk:54657]の「複雑なデータならどっちも扱いにくい」ってのはあんまりフェアな比較とは思えないんですが。いや、なひさんが想定しているケースでは複雑なケースが発生しやすく、私が想定しているケース(設定ファイルやテストデータ)ではほとんど発生しないってことなのかな。

_ なひ (2003-05-09 18:00)

「人間が読み書きする」<br>「YAMLが向いている分野で(単なるXMLでなく)SOAPを使おうという話にはなかなかならない(ターゲット)」<br>「設定ファイルやテストデータ」<br>という話が、<br>「構造データ表現フォーマット」「汎用データ表現」「メタ・データフォーマット」<br>という用語から受ける広い範囲と、なひ的にどうもマッチしないんですよね。<br><br>なひとしては、「人間が読み書きする」という前提をより強く押し出して、<br>「構造データ表現フォーマット」「汎用データ表現」「メタ・データフォーマット」<br>という前提をもう少し狭めてもらえると、型やAPIの話がでてくることや、<br>「YAMLのほうが1024倍マシ」という主張に納得できます。<br>設定ファイルにはYAMLのほうが1024倍マシ。<br><br>という辺りには落ちますか? あるいは、「構造データ表現フォーマットであるからには、<br>人間の読み書きが容易であるのが超重要」みたいな主張があるでしょうか。

_ まつもと (2003-05-09 18:11)

「人間が読み書きする」を「構造データ表現フォーマット」「汎用データ表現」「メタ・データフォーマット」 と論理andしていただければ良いのではないかと。つまりほぼ合意ですね。^^;;;<br><br>「構造データ表現フォーマットであるからには、人間の読み書きが容易であるのが超重要」みたいな主張はないんですけど、YAMLが無理せずカバーできる範囲内ならば、YAMLの方がコンパクトでよいくらいにはYAMLに肩入れしてます。XMLの方がはるかにカバーする領域が広いので、YAMLに無理がある領域なら迷わずXMLを使うでしょう。<br><br>もともとYAMLとXMLはカバーしている範囲が少々重なっているだけなのに、わざわざこうした強調を行うのは、YAML(のようなもの)の方がずっと良い場合にもXMLが使われている事例があまりに多いのと、YAMLがまだまだ無名なので宣伝したいという下心があるわけです。<br><br>...なんて議論をツッコミで行うべきなんでしょうか。まだ流儀がわからないんですけど。

_ まつもと (2003-05-09 18:21)

あ、でも、私にはあんまり経験と想像力がないんで、「構造データ表現フォーマット」「汎用データ表現」「メタ・データフォーマット」 でXMLの方がYAMLよりも良いケースって思いつかないです。Streaming APIがないからデータが大きいとつらいとかかなあ。

_ たかはし (2003-05-09 20:20)

YAMLはencodingとしてはUnicode(UTF-*)しかサポートしてないはずですけど、「人間が読み書きする構造データ表現フォーマット」をEUC-JPやShift_JISで書きたくなったりはしませんか?

_ なひ (2003-05-09 20:22)

ほぼ合意して、かつ下心についても、<br>適材適所の判断ができない開発者が増えてきたと感じているなひは、<br>強く応援したいと思うところだったんですが、<br>その次のを読んでやっぱり出てきました。<br><br>なひも流儀はよくわかりません。とりあえず他ではあんまりこういう長々した<br>ツッコミは見ませんね。^^;<br><br>型付きオブジェクトグラフのことを、SOAPではSOAP Data Modelと呼びます。<br>SOAPフォーマットはこれをXML Instanceとしてシリアライズしたフォーマットです。<br>YAMLではGraph modelがそれ(SOAP Data Model)に当たります。<br>このSOAP Data ModelとGraph modelに関しては、<br>基本的にYAMLが後を追いかけたこともあって(というとData::Denterな人が怒るかな)、<br>だいたい同じ表現力があります。<br>というわけで、「型付きオブジェクトグラフのデータ表現フォーマット」という点では、<br>どちらが良い(向いている)ケース、というのはそれほどないでしょう。<br><br>とすると、残る比較は、それらのシリアライズフォーマットの向き不向きで、<br>細かな検討項目を省いて大雑把な目安を述べると、<br>小さい、シンプルなものには、テキストとして編集しやすいYAMLが、<br>でかくて、複雑なものには、変更時の強さの点でXMLが向いている、<br>というのがなひの感覚です。<br>* attributeを利用すると、ちょっとしたグラフ上の変更なら、<br> シリアライズフォーマット上の変更インパクトが小さくて済む。<br> <foo>bar</foo><br> =><br> <foo targetId="foo_3">bar</foo><br><br> foo: bar<br> =><br> foo:<br> targetId: foo_3<br> content: bar<br><br>* グラフ上で終端ノード→非終端ノードへの変更時に、以下同じ。<br> <foo><bar/><baz/></foo><br> =><br> <foo><bar>1</bar><baz/></foo><br><br> foo: [ bar, baz ]<br> =><br> foo:<br> - bar: 1<br> - baz<br><br>ちなみにYAMLにもStreaming APIがあります。<br>[ruby-talk:54657]に書いたとおり、不要な汎用性を削って、<br>いいとこどりしたものです。

お名前:
E-mail:
コメント:
[]

«前の日記(2003-05-07) 最新 次の日記(2003-05-09)» 編集

track feed Matzにっき Creative Commons License This work is licensed under a Creative Commons License.