«前の日記(2005-01-12) 最新 次の日記(2005-01-14)» 編集

Matzにっき


2005-01-13 [長年日記]

_ [言語]私はなぜXMLを愛していないか 〜 言語屋の視点から

これまでのあらすじ(笑)

XMLは「Javaアプリケーションのスクリプト言語」としての地位を、知らぬ間に獲得しているようだ。 今やXMLは広く受け入れられている。 しかし、私にはXMLは「濫用」されているように思われる。

正直なところ、今さらあれこれ言ってもしかたがないとは自分でも思っているのだが、 やはり技術が不適切に利用されているように思える局面を見ると口出ししてしまうのだ。

しかし、さすがの私もXMLが全面的によくないと思っているわけではない。 元々の目的、つまりマークアップ言語としては十分な機能と仕様を持っていると思うし、 そういう目的に利用されているのを見て、どうこう言おうとは思わない。 自分ではきっと使わないだろうけど、それは別の話。

しかし、データ表現の手段としてのXMLには、いくつか欠点がある。 人によっては「どうでも良い」と思うだろうし、実際、そう思えるからこそXMLが選択されているのだろうが。

その欠点とは、まず第一に「冗長なこと」である。

以前のエントリへのTさんのコメントには

私はXMLの冗長なところがいいのかな、と。冗長だから人間が誤るのを訂正してくれるわけです。

とあったが、私は全く同意しない。

ある人間が入力したXMLファイルに間違いがある。それは少しも珍しいことではない。 人間は誤るものだ。で、その誤りを検出する方法は、結局は以下のいずれかではないだろうか。

  • インデントのずれ
  • XMLパーザでwell-formedでないことが検出される
  • XMLバリデータで正当でないことが検出される

さて、重要なのはこのいずれもがXMLの冗長性、つまりSGML風の<xml>〜</xml>的タグに依存しないということである。ということは、このタグによる冗長性は単に無駄ということではないだろうか。 あのタグに利点があるとしたら、私に思いつくのは「テキストに埋没しない」ことだけであり、 つまりマークアップとして使う時にしか意味がない。

Paul Grahamを引用するならば「簡潔さは力」である。ということは、「冗長性は悪」である。 こと言語に関する限り。よって、XMLは優れた言語ではありえない。

「人間は書かない」、「人間は読まない」から、という反論を見たことがあるような気がするが、 「人間は書かない」、「人間は読まない」データならば別にXMLである必要はない。 ただ、現状ではライブラリが揃っているので安易な選択であることは認める。

もうひとつ、私には欠点に思える点は、XMLは型のない言語である点である。

古代には言語はタイプレスであった。アセンブラには整数しかない(最近のは浮動小数点数もあるけど)。 その数が、単なる整数なのか、アドレスなのか、あるいは文字を表現しているのかは、 コンテキストあるいはその数を処理するプログラムによって決まったものだ。

しかし、それは人間にとっては都合が悪いので、計算モデルとして型が導入された。 BCPLは「型なし」であったが、Cでは型が導入された、というように。

スクリプト言語の世界では、長らく型(と人間性)が軽視されてきたので、Awk(数と文字列に区別がない)、 Perl(静的型(スカラーとアレイとハッシュは静的に区別される)と型なし(スカラーには型の区別がない)のハイブリット)やTcl(根源的には全て文字列)のような「型なし言語」が生き残っていたが、それらすら、オブジェクト指向の導入などでなんらかの「型」を取り込んでいる。

このようにプログラミング言語の世界では、長い長い時間をかけて苦労して「型なし」を追放してきたのに、 ここでいきなりXMLが「型なし」を復活させてくれているのだ。なんてこった。 XMLはスキーマなしでは、どの属性が数値なのか、どのデータが文字列なのか区別することはできない。 できるのは「ノード」と「テキスト(文字列)」の区別だけだ。

もちろん、XML SchemaやらRELAXやらを導入すれば型の表現はできる。 しかし、「スキーマなしで操作できる」のがXMLの良さではなかったのか。 DOMでデータを取り出してきても、その(型の)解釈は個々のプログラムに任せられてしまう。 要するに、アプリケーションのロジックの中に分散して埋没してしまうということだ。

せめて、古典LispのS式程度(ノード、整数、浮動小数点数、文字列、シンボル)程度の型が、 スキーマなしで表現できれば、こんなことにはならなかったのに。これを濫用といわずして何を。

_ [Ruby]Looking for Japanese allies

Sick (YAML for Ruby) の開発者としても知られるwhy the lucky stiffからメールが来た。

全文を引用する。

Hi, matz.

I recently started a Ruby blog which is growing quickly. Lots going on, lots to talk about. However, I'd really like to find a fresh voice from Japan to join in. I think many of us outside of Japan are dying to hear more about what is happening there. And I'm sure many Japanese Rubyists are struggling to get their work translated.

Since you are immersed in the Ruby scene, I'm wondering if you know anyone there who would like to blog in English. I'm looking for someone who can uncover neat software, translate important information from your blog, and perhaps even help us to understand some of the Japanese tech culture.

I think it could be a great opportunity for a Japanese blogger to be heard by an international audience and to make friends outside of Japan.

Thankyou so much, matz. My warmest good luck to you.

_why

要するに、

  • 最近、Rubyについて扱うRedHandedという Ruby関連のBlogを始めた。
  • 我々、日本の外のRubyistは日本の情報を知りたくてしかたがない。
  • だれか英語でわれわれのBlogを一緒に書いてくれる人を紹介してくれないか。
  • その人には、ナイスなソフトウェアの紹介や、Matzにっきなどからの情報の転送、 それから日本のtech cultureについても教えてほしい
  • それって日本のBlog人にとっても、海外にコネクションを作る良い機会だと思うよ

ということだ。だれか、挑戦する人はいないだろうか? そんなにいっぱい書く必要もなければ、完璧な英語を使う必要もないと思う。 少々の勇気とちょっとの時間でけっこうなことがなしとげられそうに思うのだが。

いかがでしょう。希望者は私にメールするか、ツッコミで連絡を。

本日のツッコミ(全15件) [ツッコミを入れる]
_ iwaim (2005-01-14 04:18)

大雑把にわけて<br>1, マークアップ言語としてのXML<br>2, データ表現の手段としてのXML<br>3, プログラミング言語としてのXML<br>ということですか。で、matz さんは 1 はいいけど他はどうかな?と。<br># というように理解しました。<br>私は 3 はちょっとどうかな?と思いますが、2 は parser などがあって楽だから許容しちゃいます。ある意味では思考の停止なのかも知れませんが。<br>「スキーマなしで操作できる」ことが良さかどうかは意見がわかれるところのようです。XML方面で「ボヘミアンと貴族の階級闘争」と呼ばれているものです。参考まで。<br># もちろん、仕様としては、それは特徴の一つにはなっています。

_ うえの (2005-01-14 06:03)

開始タグ・終了タグに現れるXMLの冗長性は、<br>1. 通信プロトコルとしてのスタビリティーの確保するため<br>2. 人間がごく一般的なテキストエディタで編集できるようにするため (メモ帳でS式書いてるとカッコの対応が分からなくなるよね)<br>3. どの言語処理系からも等しく距離をおくため<br><br>型を導入しなかった理由は、<br>1. 構文を簡潔にするため<br>2. 言語(処理系)に依存した要素を徹底的に排除するため (intは32bit? floatの表現はどうする?)<br>3. 無意味な機能拡張を抑止するため (intがある→floatも欲しい→…)<br><br>…と、去年の夏くらいに某学会の某講演を聞いたときのメモに残っています。<br><br>どちらとも、1番目と2番目の理由は自然に理解できる一方、3番目の理由は面白く感じました。すなわち、敢えて冗長な構文にしてどの言語からも距離を置く事で、どのコミュニティーにもそれなりにウケることを狙った。敢えて型とかいう機能追加の嵐の可能性を根こそぎ省くことで、機能てんこもりで使えないものに堕するのを回避しようとした。<br>後者に関してはもっといい落としどころもありそうですが、標準化会議をちゃっちゃと切り上げて一番おいしいタイミングで世の中に公表するためには、潔く切り捨てちゃうというのは非常に有効な手だと思います。<br><br>技術的優位性よりも社会的戦略を優先した設計と、それが実際に成功している事実は、非常に興味深い気がするのですが、いかがでしょう。

_ mad-p (2005-01-14 06:30)

XMLなんてひとえにinteroperabilityだけのためにあるのでは?<br>逆に言うと、他の人と交換しないなら必要ないものですね。<br><br>誰かが「no more private text format」とか言ってました。<br>Makefileと、httpd.confと、crontabと、みんなplain textなのに、<br>それぞれsyntaxが違う。いちいちparser作んなきゃなんない。<br>XMLを使えば、少なくともparserは必要ない。<br>DTDを提供しておけば、syntax checkはツールがやってくれる。<br>……というような話でした。<br><br>まあ、ちょっとしたデータにいちいちXMLはオーバーキルだとは思いますね。<br>__END__の後ろに数行書き足すような用途だと特に。

_ babie (2005-01-14 09:33)

丁度、Matz日記の[Ruby][言語]カテゴリの英語への翻訳を、ruby-lang.orgメンテ募集で提案しようと思ってました。<br>1人だとちょっと不安なので、他に誰か居ないか探してみます。

_ まつもと (2005-01-14 09:34)

順番にコメントします。<br><br>iwaimさん。<br><br>前にも書きましたが、「(データ表現としてのXMLは)parserなどあって楽だから許容しちゃいます」という態度は現実的だと思います。<br><br>「ボヘミアンと貴族」について言えば、私の意見は「貴族はXML以外の何かを使えば?」です。<br>もっとも基本的な型さえ局面によって解釈が変化するほどボヘミアンなのもどうかと思うのですが。<br><br>うえのさん。<br><br>6つの理由があげられましたが、「冗長性の1番(通信プロトコルとしてのスタビリティーの確保するため)」は、本当にそれで確保できるのか(あるいはできないのか)、ぜんぜん理解できないので保留するとしても、残りの理由はいずれもどうかしています。<br><br> * 人間がごく一般的なテキストエディタで編集できるようにするため (メモ<br> 帳でS式書いてるとカッコの対応が分からなくなるよね)<br><br> 確かにそうですが、冗長なタグを使っても事態は改善しません。適切なイ<br> ンデントが行われなければむしろ悪くなると思いますし、逆に適切なイン<br> デントを行えるならばS式でも問題ないでしょう。<br><br> * どの言語処理系からも等しく距離をおくため<br><br> 正気とは思えません。SGMLやHTMLとは距離を置かなくても良いのに、他の<br> 言語から距離を置くとはどういうことか。<br><br> * 構文を簡潔にするため<br> * 言語(処理系)に依存した要素を徹底的に排除するため (intは32bit?<br> floatの表現はどうする?)<br> * 無意味な機能拡張を抑止するため (intがある→floatも欲しい→…)<br><br> これらによって、_X M L は_簡潔になったかもしれませんが、結局アプリ<br> ケーションは数字の列から整数への変換などを個別に行う必要があります<br> から、不利益が管理されない状態でユーザに押しつけられただけという気<br> がします。<br><br>こういうのを見るとLarry Wallの言葉を思い出しますね。<br><br> ミニマリズム(Minimalism)<br> 「小さいことは美しい」という信念。しかし逆説的なことに、小さい言語で<br> 書くとプログラムは大きくなり、反対に大きな言語で書くとプログラムはプ<br> ログラムは小さくなる。考えてみよう。<br><br>この辺を強調されても、結局はXMLの設計者が利己的で無責任だっただけ、のように聞こえます(「聞こえる」だけで、そうだとは断言しませんが)。まあ、議論が長引いて結論が出ないのを嫌ったのだと想像はつきますけど。<br><br>私は「技術的優位性よりも社会的戦略を優先した設計」を好みません。「大衆」にはウケるかもしれませんが。<br>いつもとは限らないのですが、そういう設計は技術的な禍根を残すと思います。<br><br>mad-pさん。<br><br>> XMLなんてひとえにinteroperabilityだけのためにあるのでは?<br>> 逆に言うと、他の人と交換しないなら必要ないものですね。<br><br>そうだったら良かったのですが。今のXMLの使われ方を見ると「ひとえにinteroperabilityだけのためにある」とは言えないように思います。「ひとえにinteroperabilityだけのためにある べ き」でしたら、賛成します。

_ 通りすがり (2005-01-14 20:25)

有名な文書なのでおそらく読んでいらっしゃるでしょうが。<br><br>XML is not S-Expressions<br>http://www.prescod.net/xml/sexprs.html

_ まつもと (2005-01-14 22:30)

読んでませんでした。> 通りすがりさん<br><br>この文章の要旨は<br><br> * 冗長性によってエラーが早く正確に見つかる<br> * 周辺技術(XPointer,XQuery,XSLTなど)によって違いが生まれる<br><br>ということなのだと思います。前者は、私が「分からない」と言った「冗長性の1番(通信プロトコルとしてのスタビリティーの確保するため)」に対応するのだと思います。なるほどそういうことはあるでしょう。<br>もっとも、プログラミング言語の多くがその冗長性を採用していない事実(fiやend ifを使う言語はいまや少数派)を考えるとそれほど重要ではなさそうに思います。<br><br>後者については _現状では_ 事実ですが、それはXMLでなければ実現できないものではないでしょう。<br>ただ、「現状すでにツールが揃っているので便利」というのは、私も認めています。<br><br>なにより問題なのは、彼が「ドキュメント表現(マークアップ)に向いているものはデータ表現にも向いている」という暗黙の前提を(おそらくは無意識に)持っていることです。たとえば、「For example, the canonical documentation of the Scheme and Lisp standards is maintained not in S-expression syntax but in LaTeX syntax. 」(S式がドキュメントマークアップに も 向いているとは限らない)や、「So in my opinion, XML's syntax is wildly better than S-expressions as a language to integrate the worlds of documentation and data. 」という表現からうかがえます。<br><br>ところで、「XMLがタイプレス言語である」ということは、XMLはPerlやTclのような同じタイプレス言語との相性が良いということを意味するはずで、むしろJavaのような(静的で)強い型を持つ言語には向かないように思います。<br><br> 「型なし言語XML」 http://naoya.dyndns.org/~naoya/mt/archives/001544.html<br><br>「JavaがXMLとの相性が良い」と言われているのは、「ただ単にツールが多い」というだけで、言語的な相性はむしろ最悪のように思います。

_ KL (2005-01-15 00:15)

>XML is not S-Expressions<br>>http://www.prescod.net/xml/sexprs.html<br><br>S式だと(LaTeXやXMLと異なり)閉じ括弧に名前が無いのでバリデータプログラムは文書の最終端まで読んでから括弧の対応を計算する必要があり、つまり文書が長大になればなるほどXMLの冗長性には意味がある、そしてこの効率性は「SGML風の<xml>〜</xml>的タグに依存」する(あるいはLaTeX風でもOK)、と書いてありますね。<br><br>そうしてみるとまつもとさんの<br><br>>>* どの言語処理系からも等しく距離をおくため<br>> 正気とは思えません。SGMLやHTMLとは距離を置かなくても良いのに、他の<br>> 言語から距離を置くとはどういうことか。<br><br>とのコメントは覆らざるをえないのかなと思ったのですがどうでしょう。また<br><br>>もっとも、プログラミング言語の多くがその冗長性を採用して<br>>いない事実(fiやend ifを使う言語はいまや少数派)を考えるとそれほど重要ではなさそうに思います。 <br><br>という点も、プログラムをメモリにロードしてしばらく動かすというより、大量のXML文書データを処理するという観点からすると、効率性が重要となるように思います。

_ まつもと (2005-01-15 00:48)

いくらなんでも「文書の最終端まで読んでから括弧の対応を計算する」なんてことはしないと思いますよ。ですから、その点については覆ることはないと思います。ただ、S式っぽい「非冗長な記法」は間違いがあった時の発見が遅れるのは事実ですから、その点はメリットだと思います。<br><br>もっとも<br><br> * 人間が直接編集する誤りを含むような文章はそれほど大きくならない<br><br> * あまり長大なデータなら人間は直接処理しない<br><br>ので、間違いの検出が早いかどうかが、言語の簡潔性を犠牲にするほど重要かどうかは、私には疑問です。

_ まつもと (2005-01-15 00:49)

あ、上記の「文章」は「データ」の間違いです。<br><br>今回はデータ表現以外の分野での比較を(私は)行っていませんから。

_ MMX (2005-01-15 09:14)

XMLの混合内容モデルを使わない data-oriented な人々は<br>バイナリーXMLとかを立ち上げようとしてます。<br>SGML → XML の成功体験の エッセンス<br>(高機能複雑なほうが「偉い」わけじゃない) を <br>バイナリーの ASN.1 → ?? でやろうとしてます。<br>Fast Infoset and Respect-based Standards<br>http://www.oreillynet.com/lpt/wlg/6206

_ まつもと (2005-01-15 10:01)

Fast Infosetは、私たちが数年前IPAに提案した(そして、落とされた(笑))「XMLツリーデータの別表現」のアイディアに似ています。ASN.1など既存のスタンダードへの "respect" を前面に出さなかったのが敗因でしょうか。

_ ma2 (2005-01-17 10:55)

何人かでやるなら負担も分散されて良いのではないでしょうか > 英語blog<br>それなら僕も手伝えるかなあ。

_ T (2005-02-27 03:02)

すごい遅レスで申し訳ないですけど、念のため。<br><br>誤らないの意味を誤解されたようです。<br>XMLデータなんて人間は書いたり読んだりしませんけど、プログラマーは設計したり、処理したりします。この時に誤らないためってことです。<br>XMLをS式に変換することはわけもないことですが、S式からXMLに直すには、データに対する名前付けが必要です。<br>データフォーマットもプログラムも似たような物で、コードを見ただけで、その使い方がわかる方がはうれしいわけです。<br>Javaでクラス名が冗長なのはそういう理由です。タイピングに時間はかかりますけどね。<br>XMLが冗長なのもそういう理由です。処理に時間かかりますけどね。<br>LinuxMagazineに名前は重要って書いてあったような気がしますけど・・・・まさにそんな感じです。<br><br>ついでに、タイプレスであることはスキーマ?(私はメタ情報と読んでますけど)を導入すればいいので、この点にこだわってる意味がよくわかりません。<br>Lispっていうのは、プログラムである前に木構造のデータなわけです。それがプログラムとして意味を持つのは、そこにメタな情報を付加するからです。この、メタな情報と、フォーマット(木構造)の情報が、まとまて名前をつけるか、分けて名前をつけるかの違いだと思います。

_ まつもと (2005-02-27 23:47)

Tさんのように現在のXMLに満足している人がいらっしゃることは別に構いませんし、それはそれでアリだと思いますが、私はXMLのことを「なんとか使える技術」であっても「優れた技術」であるとは思えないというだけのことです。<br><br>冗長性については、意味があるケースがないとは言いません。たとえばPaul Prescodの指摘するエラーが早く見つかるというのは確かに利点ではあると思います。しかし、そのXMLの冗長性がコストに見合うほどかと言われると疑問が残ります。処理コストも高いし、決して読みやすくもないですし。<br><br>「プログラマーが設計したり処理したり」するのに役立つというのはもっとよく分かりません。S式で構造を表現する時にも、おそらくは先頭のシンボルで「意味」を表現するでしょうから、XMLだけが「名前重要」を体現しているとは言えないんじゃないかと。<br><br>「分からない」って言っているだけで否定しているわけではないんですが。<br><br>タイプレスであることについては「スキーマ(メタ情報)があるからいい」ということのようですが、とすると、(かつて?)XMLの利点とされていた「well-formedで(スキーマなしに)処理できる」という点は、もはや関係ないって主張ですかね。<br><br>それもひとつの立場だと思いますが、スキーマを必須とするなら別にXMLである必要性はないわけですよね。現時点でツールがそろっているという点以外には。<br><br>私は「言語(or データフォーマット)としてのXMLの優位性」について考察しているので、「XMLのフォーマットとしての優位性はともかく、ツールがそろっているからいいじゃん」という主張は(否定しませんが)私の考察には役立たないのです。

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

«前の日記(2005-01-12) 最新 次の日記(2005-01-14)» 編集

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