ReiOdaira 「XMLとは～ではない」と言う人は多くても「XMLとは～である」と言ってくれる人が少ないので私のような門外漢は未だにXMLの心が何なのかわかってない‥‥。
taroleo XMLの意義はこれで表現できないデータはない、というフォーマットを初めて広めたところ。
kunishi はぐらかしているわけではなくて、本当に、syntax 以外の部分は扱う人によって「心」が変わるのです
kunishi XMLに関する（笑えない）ジョークに「XMLに携わる技術者が10人集まると、XML名前空間の解釈は11個ある」というのがあります。10人とも解釈が違って、さらに妥協の産物としての解釈が1通りあるという意味
taroleo XMLが解決する問題は、データを表現するsyntax。データの意味ではない
kunishi これはXML名前空間についてですが、XMLについても同様のことが言えると思います
ReiOdaira @taroleo 「その先」の話も気になったり：http://twitter.com/taroleo/status/1057690640
taroleo XMLという形式そのものに意味があると勘違いして、10年くらいDB研究者は迷走しました
taroleo XMLのその先は、@kunishi 先生も言っていますが、データを作る人の「心」をいかに表すか
taroleo 僕自身は、XMLといえども、大部分がテーブルのような簡単な形式のデータで成り立っている、という道筋を提案しました
taroleo 研究でよく使われるXMarkのデータで、XML特有の部分って、ほんの数か所なんです。Relation + alphaで乗り切れる程度の。
taroleo XPathが必要なのは、そんなdocument-centricで、どうしても木で書かないと具合が悪い数か所に対してなのですが
taroleo そんなごちゃごちゃの部分に、pathとか、twigクエリをちまちま書くのは、非現実的です。
taroleo 逆に、pathクエリを除いた XQueryの意義というのは十分にあって
taroleo 再帰的に、構造を持ったデータを「組み立てる」言語として、役に立ちそうだなぁと。
taroleo と、長年XMLに関わってきて得た僕の結論なのですが
taroleo 誰か、叩いてくれないかな。木構造はこんなにすごいんだとか。
taroleo XPathは大事だ、とか。
ReiOdaira 村田真さんの話を聞いていて「XML、怖い‥‥」とか思って引いてしまう臆病な人。
taroleo あ、スキーマは大事なんですよ。XMLの裏側の「心」を表現するために taroleo でも、木でスキーマを組むことの意義は何だろう？と
ReiOdaira 人間が理解できるメタデータ構造なんて表とか木くらいしかない（ただし表で済む場面多し）んだからRDBとXMLで網羅されて人類は末永く幸せに暮らしましたとさ、めでたしめでたし‥‥と100年後の教科書に書かれるんだろか。
taroleo viewという概念でDBにはすでにある話。web でviewを使いたい。
kunishi 自宅から移動中で反応が遅くなりました
kunishi SIGMODの件は正直驚き。ただ一方で、そういうDB研究者がいてもおかしくないかな、とも思います。この件は後述
kunishi XQueryのconstructの部分が重要なのは同感なのだけど、そこはXSLT1.0で意図していたことの焼き直しだよね。syntaxとか表現能力とかは棚に上げると
taroleo ふとした拍子にいろいろ面白い話が聞ける。Twitter
kunishi さらに再帰的に組み立てるというのはSGMLのDSSSLにもさかのぼれます。もろSchemeです
kunishi XPathは、元々構造のないテキストに対して、ある部分を指し示す式を与えたと言う点が画期的だったんじゃないかな。あくまでテキスト対象
taroleo constructって、Schemeか！ purely-functional
taroleo データ構造中の位置を示すidentifierとか、pointerかぁ＜XPath
kunishi 構造のあるデータに対してはSQLというパワフルな体系があるわけだから、XPathがいいかと言われるとかなり怪しい
kunishi 村田さんは文書な人なので、SGMLの頃からのさまざまな経験（というか怨念？）があって、木重要と言っておられるのでしょう。檜山さんとかJames Clarkとか、SGML時代から文書に関わっている人はみなそう
kunishi 木でスキーマを組む意義ですか？身も蓋もなく言うと、DB研究者の飯の種の確保
kunishi DBモデリングの歴史って、Relationより能力が高くかつsemantic independentなモデルをいかに作るか、の繰り返しですよね。ネットワークモデル、階層モデル、OODB、演繹DB、XML DB
kunishi で、全部失敗してるわけです
kunishi Abiteboulがすごかったのは、OODBのようなcomposite dataへの関心、Web、(たぶんdraft段階だった)XMLなどを「半構造」という概念で抽象化したところ
kunishi そして、これくらいならそこそこsemantic independentなことができるだろうというレベルに問題を設定したことだと思うのです
kunishi DB屋って基本的にapplication independent, さらにはsemantic independentなのを是とする根底の発想があるのだと思います
ReiOdaira コンパイラの世界にも中間言語をquadruple（＝タプル）で表すかabstract syntax treeで表すかという宗教戦争がありましてですねぇ‥‥。
kunishi だからSIGMODでのDB研究者の反応って、理解できるんですよ。XMLに関して言えば、私は同意しないけど
kunishi あ、その話聞きたいです。コンパイラの講義でコード生成の部分は実感がなくて困ってるので
ReiOdaira べつに決着はついてないしつける必要もないし両方使ってるコンパイラ多いし。
kunishi いいチュートリアル資料とかありませんかねえ＞コンパイラの中間言語
kunishi サーベイでもいいです
ReiOdaira @kunishi ふつうの教科書に載ってる話以上のものとしてはMuchnickの"Advanced Compiler Design and Implementation"の付録に商用コンパイラで使われてる中間言語がたくさん解説してあったと思います。
ReiOdaira なんであんた商用コンパイラの中までこんなに知ってるの、というレベルで。
ReiOdaira 関数の中を大域的にデータフロー方程式グルグル回して最適化しようとおもうとquadrupleがいいけど、拡張基本ブロックくらいの範囲内でチョコチョコと参照を張り替えて最適化するならtreeのほうが楽なのかな。あんま同意しない人も多そうだが。
kunishi そういえば、XPathのsubclassをいろいろ考えるのもDB屋さんっぽいね。XPathはturing completeだから、SQLのような性質のいいsubclassで議論したいという
myui @ReiOdaira 素人にはastを全ての状況を考慮に入れ整合性保ちながら書き換えるのは、穴が出てしまいそうで、結構しんどい。木でポインタ辿るのもキャッシュヒットしないので遅そいし。組の方が楽そう。項書き換えちゃんと学ばないと。
myui まぁ、ループ周りの計算量に依存するとこ以外は問合せ処理では最適化しても、差は微々たるものなので、無視してよいような。パス評価式を分解したり、duplicate eliminationとかしなくてもバッファで当たるのでよいや、みたいな。というのは、とあるＤＢＰＬの話です。
myui parallel databaseのoperator parallelismの話はそろそろmapreduceとかに落ちてくのではないかな
myui 流石にapplication independentはないと思う。割と実用とは紳士に向き合っている分野なので。心持ちとして、semanticにはindependentだと思うけど。
ReiOdaira @myui コンパイラ用語で言うとcommon sub-expression eliminationやscalar replacementしなくてもCPUキャッシュに当たるのでよいや、ということですね。:-)
monizuka そういえば昔XPointerってあったね。
monizuka Codd の論文ではrelational model よりも三層独立の方が重要とも言われている。
というわけでまとめてみました。改めて見ると、DB&XML関係者総出演、という感じですねえ。一部個人宛のメッセージも混じっているんですが、そこを抜いてしまうと話が見えなくなる部分もあるので、あえて全部出してみました。ちょっと過激な発言も混じっていて、背景とか補足をしないといけないなあ、と思うんですけど、まとまった分量になりそうな気がするので、別エントリで書くことにします。
0 comments:
コメントを投稿