トップページ⇒tech
89コメント29KB

【ポストXML】 SXML / YAML / JSON を語るスレ

■ このスレッドは過去ログ倉庫に格納されています
000112005/05/15(日) 21:26:27
エンタープライズじゃないっつー香具師も統一的に語るべ。

関連スレは>>2以降に。
000212005/05/15(日) 21:27:35
関連スレ:
YAML (YAML Ain't Markup Language):
- 本家: >
http://www.yaml.org/
- YAMLはXMLに改良を加える: >
http://www.ibm.com/jp/developerworks/xml/030124/j_x-matters23.html
- Matzにっき(2004-05-07): >
http://www.rubyist.net/~matz/?date=20030507#p02
- Matzにっき(2004-05-08): >
http://www.rubyist.net/~matz/20030508.html#p04

JSON (JavaScript Object Notation):
- 本家: >
http://www.json.org/
- matzにっき(2005-03-02): >
http://www.rubyist.net/~matz/20050302.html#p07

SXML (S-exp-based XML): >
- SSAX: >
http://ssax.sourceforge.net/
- XML用の代替構文を調査する: >
http://www.ibm.com/jp/developerworks/xml/030117/j_x-syntax.html
- XML is not S-Expressions: >
http://www.prescod.net/xml/sexprs.html

関連スレ:
- 【必須?】XML技術【使ってる?】: >
http://pc8.2ch.net/test/read.cgi/tech/1090253584/l50
- Ajaxでも語りませんか: >
http://pc8.2ch.net/test/read.cgi/php/1110287963/
000312005/05/15(日) 21:37:11
関連スレじゃなくて関連サイトだった。。。orz
0004デフォルトの名無しさん2005/05/15(日) 21:55:18
Post XMLでも特にデータ向け記法のスレってことでいいですか？
文章向け記法(各種Wiki Notation, POD, etc.)は扱わないと。
0005デフォルトの名無しさん2005/05/15(日) 22:07:52
structured text の話も混ぜて良いなら smart ascii の類いを是非
0006デフォルトの名無しさん2005/05/16(月) 02:02:14
reStructuredText?
0007デフォルトの名無しさん2005/05/16(月) 04:46:07
痛いな。
Ruby遊びにかまけてて、
XMLの動向ろくにおっかけなかった人物が、
なんか中途半端な考えに嵌ってる気がする。

・・・XMLの型が中途半端って、
XML SchemaやRelaxerの出現以前で止まってたのか・・・

こーゆー中途半端な事を
後から恥ずかしげもなく言い出せる、ってのが
遅れてきた奴らには神に見えるんだろうな・・・
0008デフォルトの名無しさん2005/05/16(月) 08:05:34
>>7
strict さがさほど求められていない用途には
XML Schema や Relaxer はコスト高すぎ。
あんなの使う気がしないじゃん。
0009デフォルトの名無しさん2005/05/16(月) 10:17:09
さすがXML厨。
0010デフォルトの名無しさん2005/05/17(火) 00:35:06
コスト高すぎてXML使えません
001112005/05/18(水) 03:28:28
>>4
含めてもいいね。POD vs roff vs RTF vs TeX、いずれも構造化テキストだし。
各種 Wiki 記法比較なんかするのもありでいいや。どうせ伸びないし。

>>8
Relaxer はアプリケーション名。その文脈だと RelaxNG じゃ?
001212005/05/18(水) 03:31:37
で、JSON なんだが、とりあえず業務で使うならこれだな。
カスタムタグ作れば Struts とも親和性高し。ECMAScript で eval() すればパーズできてしまうのは好都合だね。
XSS のことを考えるとやや怖いもんがあるけど。
0013デフォルトの名無しさん2005/05/18(水) 03:56:07
じゃ、業務で使った結果の報告よろ。
0014デフォルトの名無しさん2005/05/18(水) 22:55:21
既にXMLという冗長かつ汎用的（とはとても言い難い）なデータ記述法があるというのに
なんでわざわざマイナーな記法を流行らそうとか思うのかね
0015デフォルトの名無しさん2005/05/18(水) 23:39:57
1996頃、JavaScriptの新しいバージョンが登場した頃、
「JavaScriptでデータベース作ろう」という不思議な流行があった。

中身は、「JavaScriptの連想配列への代入文」という形で小さなデータベースを転送し、
JavaScript自体で検索・表示を行うという、単純なもの。

当時は、なんじゃこりゃ？素人うざー、とか思ったものだが、
同時期に出てきた JavaScipt DOM (ReadOnly)と共に、
1997年の XML誕生を予感させる出来事だった。

JSONって、その系統のソリューションじゃねぇの？全然調べてねぇけどｗ
0016デフォルトの名無しさん2005/05/20(金) 17:04:52
>>11
細かいようだがroffは構造を持ってないぞ。
0017デフォルトの名無しさん2005/05/20(金) 17:17:10
TeXもroffも、それ自体は印刷方法を指定するマークアップ言語。

ただしLaTeXや manマクロ等は、構造化文書寄り
0018デフォルトの名無しさん2005/05/20(金) 23:31:04
SXMLはともかく、JSONてXMLに変換できるの？
あ、YAMLは興味ない
0019デフォルトの名無しさん2005/05/21(土) 01:41:56
言語の構造がXMLよりは優れているか劣っているかどうかの違いはともかく、
SXML, YAML, JSONは視覚的に見てもXMLより読みにくい感がある。

とはいえこれは見た目の問題なので


XML風な記号を用いられたSXML, YAML, JSONが出れば
SXML, YAML, JSONに対する理解が広く得られ、
ポストXMLの地位を確率できるのではないかと思う。

SGMLがあまりにも難しかったために普及しなかった。
そこでHTMLが登場したが初心者にはよいが高度な使い方をすると
あまりにも安直なマークアップ言語になるという別の問題が山積み、
そこでSGMLとＨＴＭＬの欠点、利点から学んだXMLが登場。

という経緯を積むように


SXML, YAML, JSONがあまりにも難しかったために普及しなかった。
そこでXMLが登場したが初心者にはよいが高度な使い方をすると
あまりにも安直な言語になるという別の問題が山積み、
そこでSXML, YAML, JSONとXＭＬの欠点、利点から学んだ新たな???????言語が登場。

となる未来がやってくるのではないかと予測。
0020デフォルトの名無しさん2005/05/21(土) 01:43:48
＞SGMLがあまりにも難しかったために普及しなかった。

XMLも十分面倒臭いよ
0021デフォルトの名無しさん2005/05/21(土) 01:50:20
めんどくさい≠むずかしい
0022デフォルトの名無しさん2005/05/21(土) 01:53:50
面倒さが問題を難しくする

XMLがその典型
0023デフォルトの名無しさん2005/05/21(土) 02:00:24
--- YAML ---
構造は インデント で表す
リストは ダッシュ で表記する
（キー・値）ペアは コロン で区切る
0024デフォルトの名無しさん2005/05/21(土) 02:01:03
--- !clarkevans.com/^invoice
invoice: 34843
date : 2001-01-23
bill-to: &id001
　　given　: Chris
　　family : Dumars
　　address:
　　　　lines: |
　　　　　　458 Walkman Dr.
　　　　　　Suite #292
　　　　city　　: Royal Oak
　　　　state　 : MI
　　　　postal　: 48046
ship-to: *id001
product:
　　- sku　　　　 : BL394D
　　　quantity　　: 4
　　　description : Basketball
　　　price　　　 : 450.00
　　- sku　　　　 : BL4438H
　　　quantity　　: 1
　　　description : Super Hoop
　　　price　　　 : 2392.00
tax　: 251.42
total: 4443.52
comments: >
　　Late afternoon is best.
　　Backup contact is Nancy
　　Billsmer @ 338-4338.
0025デフォルトの名無しさん2005/05/21(土) 02:12:10
インデントという時点で2chではヤバくて使えない
0026デフォルトの名無しさん2005/05/21(土) 02:22:55
--- JSON ---

An object is an unordered set of name/value pairs. An object
begins with { (left brace) and ends with } (right brace).
Each name is followed by : (colon) and the name/value pairs
are separated by , (comma).

An array is an ordered collection of values. An array begins
with [ (left bracket) and ends with ] (right bracket).
Values are separated by , (comma).

A value can be a string in double quotes, or a number, or
true or false or null, or an object or an array. These
structures can be nested.

A string is a collection of zero or more Unicode characters,
wrapped in double quotes, using backslash escapes. A
character is represented as a single character string.
0027デフォルトの名無しさん2005/05/21(土) 02:24:17
JSONでの表現

{"menu": {
　"id": "file",
　"value": "File:",
　"popup": {
　　"menuitem": [
　　　{"value": "New", "onclick": "CreateNewDoc()"},
　　　{"value": "Open", "onclick": "OpenDoc()"},
　　　{"value": "Close", "onclick": "CloseDoc()"}]}}}

これと等価なXMLは↓

<menu id="file" value="File" >
　<popup>
　　<menuitem value="New" onclick="CreateNewDoc()" />
　　<menuitem value="Open" onclick="OpenDoc()" />
　　<menuitem value="Close" onclick="CloseDoc()" />
　</popup>
</menu>
0028デフォルトの名無しさん2005/05/21(土) 02:32:21
こりゃ、Perlの連想配列と一緒だな。
・・・orz
0029デフォルトの名無しさん2005/05/21(土) 08:22:01
そういえばポストXMLのスレなのにSOXは対象外なのか？
一応テンプレっぽいのを書いておく。

SOX (Simple Outline XML)
- 本家:>
http://www.langdale.com.au/SOX/
- YukiWiki:>
http://www.hyuki.com/yukiwiki/wiki.cgi?SOX
- IBM dW XML用の代替構文を調査する:>
http://www-6.ibm.com/jp/developerworks/xml/030117/j_x-syntax.html
0030デフォルトの名無しさん2005/05/21(土) 08:34:34
>>20
> ＞SGMLがあまりにも難しかったために普及しなかった。
>
> XMLも十分面倒臭いよ

それでも普及しているよ。
設定ファイルではよく使われるようになった。
CSVよりも読みやすくLISPよりも読みやすい。
<と>を使ったタグで囲っているのがかなり見やすい。

書くのが面倒くさい？

その問題はツールなどを使えば大抵は解決すると思われる。
0031デフォルトの名無しさん2005/05/21(土) 08:36:15
>>27
それを見るとどうみてもXMLのほうが
読みやすく感じる。

PostXMLといい切るにはXML並の読みやすさが必要なんじゃないかという気がする
がどうだろう？
0032デフォルトの名無しさん2005/05/21(土) 08:56:04
>>31
読みやすさよりも、使いやすさだね。
XML ほどの汎用性は求めず、特定用途での扱いやすさを優先している。
バベルの塔の崩壊と言葉の混乱ってやつかと。

JSON は Javascript のサブセットなので
Javascript Engine が直接解釈できるのが肝なんだと思う。
例えば Perl やらで作ったウェブアプリケーションが
JSON を吐けば XML でデータを送るよりも
ブラウザが高速に処理してくれる。
0033デフォルトの名無しさん2005/05/21(土) 09:05:44
>>32
それはつまり、
ポストXMLというには無理があると？
0034デフォルトの名無しさん2005/05/21(土) 11:23:43
ちなみに Perl5の連想配列の初期化はこんな感じね。(ミスがあったら指摘してね)

%assoc =
{menu=> {
　id=> "file",
　value=> "File:",
　popup=> {
　　menuitem=> [
　　　{value=> "New", onclick=> CreateNewDoc},
　　　{value=> "Open", onclick=> OpenDoc},
　　　{value=> "Close", onclick=> CloseDoc}]}}}

で、この手の定義の問題点は・・・というと、
Lispのデータと同様、構造体としての型定義がないから、

・データ記述にミスがあっても、実行時まで発見されない
・処理プログラムの方も、いわゆる car/cdr的な判りにくいものになりがち

という所。なんだ、10年前にPerl5で出来た事を今更。。。
0035デフォルトの名無しさん2005/05/21(土) 15:00:36
だからって、普通スクリプト言語をデータベースとして使ったりはしないだろ
0036デフォルトの名無しさん2005/05/21(土) 15:02:56
おまえの発言は、常に前レスのコピーだから相手にしたくなくなる
0037デフォルトの名無しさん2005/05/21(土) 15:04:47
JASON凄い

YXMLｶｺｲｲ

SEXPRは神
0038デフォルトの名無しさん2005/05/21(土) 15:05:24
>>35
そうですね。お話の続きをどうぞ
0039デフォルトの名無しさん2005/05/21(土) 15:30:19
>>34
実行時まで発見されないっていう認識は勉強不足だな。

たとえばSEXPRはS式なわけよ。
読み込み段階でS式と同じチェックは行われるし、
実行前にいくらでもフィルターを通す事も自在。
S式だから当然quoteも使えるということを忘れてはならない。
0040デフォルトの名無しさん2005/05/21(土) 15:38:52
あぁーこれだから・・・。
あんた主張すべきポイント、間違えてるよ

構造に間違いがあっても、静的にチェックできない
つうのがポストXMLの特徴の一つなんだろ。
0041デフォルトの名無しさん2005/05/21(土) 15:39:37
「構造に間違いがあるかないか、保証する仕組みを外した」くらいの表現のほうがいいか。
0042デフォルトの名無しさん2005/05/21(土) 15:46:51
XML スキーマに相当する物ってこと?
0043デフォルトの名無しさん2005/05/21(土) 15:54:05
validatedでないつうこと
0044デフォルトの名無しさん2005/05/21(土) 16:21:04
>>40
読み込んでからチェックすればいいじゃん。
何不都合でも？
0045デフォルトの名無しさん2005/05/21(土) 20:06:16
>>40-44

んなvalidatedでないコードが
ポストXML？

問題ありありだろ。

そんなコードや文書データが出回ったら
大変なことになるだろ。

0046デフォルトの名無しさん2005/05/21(土) 20:11:23
ここでスルー出来るかどうかでこのスレの行く末が決まるな。
0047デフォルトの名無しさん2005/05/21(土) 20:24:03
んーつうか、XML の用途すべてを置き換えるようなものじゃないだろ。
共存していけばいい。
0048デフォルトの名無しさん2005/05/21(土) 20:46:12
>>45
SXMLをreaderに組み込めば読み込み中にもチェックできますが何か？
何を問題にしてるの？
0049342005/05/21(土) 21:26:10
JSONの話題しか振ってないのに、
いつの間にか SXMLの話にすり変わって、
挙句にvalidated XMLもわからなそうなの
が食いついてるので、萎えた。
0050デフォルトの名無しさん2005/05/21(土) 21:27:53
掲示板とはそういうもんだ
0051デフォルトの名無しさん2005/05/21(土) 21:29:39
ここにも頭おかしいのが粘着してるのか。
0052デフォルトの名無しさん2005/05/21(土) 23:00:50
＞JSONの話題しか振ってないのに、

おまえの都合の良い脳内補完機能には呆れた
005328=342005/05/21(土) 23:03:18
お前が馬鹿だというのがよく判った。
0054デフォルトの名無しさん2005/05/21(土) 23:10:59
ここでスルー出来るかどうかでこのスレの行く末が決まるな。
0055デフォルトの名無しさん2005/05/21(土) 23:12:15
お前が荒しだという事がよく判る。
0056デフォルトの名無しさん2005/05/21(土) 23:15:01
>>45 + >>47に賛成。

お話の続きをどうぞ。
0057デフォルトの名無しさん2005/05/22(日) 00:30:42
well-formedはチェックするだろ．

DTD-validとかスキーマとかに照らしてチェックする
ってのは今のところ守備範囲外なんでないの？

0058デフォルトの名無しさん2005/05/22(日) 00:34:17
>>1のリンク先は一切読んでないけど、
このスレの流れ的には、どうやらそーゆー用途みたいね。
0059デフォルトの名無しさん2005/05/22(日) 00:35:43
で、>>34後半なわけですよ、経験上。
0060デフォルトの名無しさん2005/05/22(日) 00:39:23
1. 当然 validate もサポートしているよん
2. validate 処理なんて簡単に書けるから要らん
3. XML と相互変換可能だから、一旦 XML に直して validate する
4. validate する必要無い用途で使うから気にすんな
5. validate は悪

誰か分類してくれ
1 か 4 が多そうだが
0061デフォルトの名無しさん2005/05/22(日) 00:40:54
>>34＝>>59が軽くスルーされているのが気になる。

>>60
用途次第。多数決で決めるもんではないし
0062デフォルトの名無しさん2005/05/22(日) 00:42:58
ちゃんとレスを読んでくれ
荒れる遠因だから
0063デフォルトの名無しさん2005/05/22(日) 00:45:40
ごめん、>>60の意図がわからん。
自分で判断せず、周りの意見を聞きたいという事か？

あと>>34＝>>59の意見を無視する理由を教えてくれ。
0064デフォルトの名無しさん2005/05/22(日) 00:55:31
意図が理解出来ないならレス付けるなよ
紛らわしいから
0065デフォルトの名無しさん2005/05/22(日) 01:03:03
頭悪そうなレスだな。いい加減にしろ
0066デフォルトの名無しさん2005/05/22(日) 01:11:28
おそらく>>60の脳内には
(各種XML代替構文についてvalidationへの対応状況を、誰か調べて次の1〜5に分類して一覧にしてくれ)
という一文が隠れているのだろう。それは>>60を読めば判る。

意図不明なのは、>>60の調査結果を示していないこと。
0067デフォルトの名無しさん2005/05/22(日) 01:17:17
他は知らんが JSON なら eval すれば valid かどうかわかるでしょ。
0068デフォルトの名無しさん2005/05/22(日) 01:20:52
>>67
それは構文間違いが無いという意味でしょ
意図したデータ構造であるかは eval するだけじゃ分からないと思うけど
0069デフォルトの名無しさん2005/05/22(日) 01:27:55
すま。わかるのは well-formed かどうかか。
interoperability は重視していないってことなんだろう。
0070342005/05/22(日) 01:43:11
>>69 俺もそれ考えてた。

あともう一つ考えてた事があって、
明示的な文書型定義(DTD, XML Schemaのようなもの)が与えられていなくとも、
(同じ型の)複数の文書から、フォーマットを推定でき、大体の推定で処理ができる事もあるかもな、
という考え。ぶっちゃけ、HTMLを適当に処理して情報抽出するアダプターとか、検索サービスの収集ｴﾝｼﾞﾝとか。
0071デフォルトの名無しさん2005/05/22(日) 02:18:00
LAML は validator あるみたいね

ttp://www.cs.auc.dk/~normark/scheme/tools/dtd-parser/man/dtd-parser.html
0072デフォルトの名無しさん2005/05/22(日) 03:08:50
http://www-6.ibm.com/jp/developerworks/xml/020208/j_x-matters14.html
0073デフォルトの名無しさん2005/05/23(月) 00:00:04
XMLで十分
0074デフォルトの名無しさん2005/05/24(火) 23:13:26
>>32
XMLパースを簡単に行えるライブラリが公開されたので
通信データにJSONを使うメリットはなくなったのでは？

JKL.ParseXML - XML→JSON展開クラス
http://www.kawa.net/works/js/jkl/parsexml.html
JKL.ParseXMLを試してみた
http://mizzy.org/program/jklParseXML.html
0075デフォルトの名無しさん2005/05/25(水) 18:08:43
>>74
XMLとJSON(っつうか連想配列)のセマンティクスは微妙にずれてるから
JKL.ParseXMLのAPIも結構苦労の跡が見える。

単にキー：値のネストした構造体をやりとりしたい場合はどっちでも
いいと言えるし、そうでない場合はJavaScript側でもdomを使って
アクセスした方が楽なケースもあるだろう。

前者だった場合XMLの方が冗長で無駄が多いような希ガス。

結局扱いたいデータがXMLに向いているか、JSONに向いているか
ケースバイケースで使い分ければいいんじゃね？
0076デフォルトの名無しさん2005/05/25(水) 18:28:23
>>75
> XMLとJSON(っつうか連想配列)のセマンティクスは微妙にずれてるから

どこ？多重度のあたり？
0077762005/05/25(水) 18:30:50
あと、属性か要素か、っつうのもアレだな
0078752005/05/26(木) 13:03:08
>>76,77
そんなとこ。

あと、RDB -> CGI(スクリプト言語) -> JSON-RPC は楽だよ。
スクリプト言語のRDBインターフェースはクエリの結果を大抵
連想配列とリストで返すから、JSONに変換するだけでブラウザに
返信できる。
0079デフォルトの名無しさん2005/05/26(木) 14:30:26
ああ。7〜8年位前に、
典型的なDBメンテ型の情報系アプリで、
そんなんを冗談で検討した覚えがあるな。

確かJava DAO使ったOO設計やろうとしてる所で
Perl5 DBI使ったCGIに慣れてる香具師が
DB連想配列とCGIパラメータ連想配列の間で
データをコピペしてHTMLにベタに展開するコード書いてきたんで、
そんなら DBデータをJavaScriptのコードに即変換して、
JavaScriptでHTMLを描画しろよ、と。(DHTML〜XSL〜Ajax以前の時代)
0080デフォルトの名無しさん2005/10/13(木) 00:16:44
昔からあるしJSONとかより全然読みやすいしXMLより
書くのがだいぶ簡単なのにSOXが流行らない理由が分からない。
0081デフォルトの名無しさん2005/11/23(水) 16:29:54
ボヘミアンと貴族の闘争。

ってなに？
0082デフォルトの名無しさん2005/11/26(土) 08:15:06
>>81
知らなくてもいい。
0083デフォルトの名無しさん2005/11/26(土) 17:15:09
>>82が知らないだけ。
0084デフォルトの名無しさん2005/11/27(日) 06:54:53
>>81
サッカーのチェコ対オランダ戦。
0085デフォルトの名無しさん2005/11/27(日) 12:32:36
>>84
どっちがボヘミアン？
0086デフォルトの名無しさん2005/11/27(日) 16:40:31
>>85
ボヘミア＝チェコ西部の地方
0087デフォルトの名無しさん2005/12/08(木) 03:58:44
ぐぐって見たんだがSXMLの
<tag attribute="Attribute">
　<contents>こんにちは世界</contents>
</tag>
の標準的な記法って
(tag (@ (attribute "Attribute")
　　　(contents "こんにちは世界"))

でO.K?

@が非常に判別しにくい(tagと見分けがつきにくい)
のだけれど
0088デフォルトの名無しさん2006/02/15(水) 22:17:00
S式パーサがあればXMLなんて不要。
どうしようもなく冗長なXMLを使ってる馬鹿は考えを改めた方がいい。

http://pc8.2ch.net/test/read.cgi/tech/1140006937/
0089hosyu2006/07/26(水) 15:08:54
http://61.197.151.26/20060725863648/omote/img200606/2006062521_1136191292.swf　
■ このスレッドは過去ログ倉庫に格納されています