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

エンタープライズじゃないっつー香具師も統一的に語るべ。

関連スレは>>2以降に。

関連スレ:
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/

関連スレじゃなくて関連サイトだった。。。orz

Post XMLでも特にデータ向け記法のスレってことでいいですか？
文章向け記法(各種Wiki Notation, POD, etc.)は扱わないと。

structured text の話も混ぜて良いなら smart ascii の類いを是非

reStructuredText?

痛いな。
Ruby遊びにかまけてて、
XMLの動向ろくにおっかけなかった人物が、
なんか中途半端な考えに嵌ってる気がする。

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

こーゆー中途半端な事を
後から恥ずかしげもなく言い出せる、ってのが
遅れてきた奴らには神に見えるんだろうな・・・

>>7
strict さがさほど求められていない用途には
XML Schema や Relaxer はコスト高すぎ。
あんなの使う気がしないじゃん。

さすがXML厨。

コスト高すぎてXML使えません

>>4
含めてもいいね。POD vs roff vs RTF vs TeX、いずれも構造化テキストだし。
各種 Wiki 記法比較なんかするのもありでいいや。どうせ伸びないし。

>>8
Relaxer はアプリケーション名。その文脈だと RelaxNG じゃ?

で、JSON なんだが、とりあえず業務で使うならこれだな。
カスタムタグ作れば Struts とも親和性高し。ECMAScript で eval() すればパーズできてしまうのは好都合だね。
XSS のことを考えるとやや怖いもんがあるけど。

じゃ、業務で使った結果の報告よろ。

既にXMLという冗長かつ汎用的（とはとても言い難い）なデータ記述法があるというのに
なんでわざわざマイナーな記法を流行らそうとか思うのかね

1996頃、JavaScriptの新しいバージョンが登場した頃、
「JavaScriptでデータベース作ろう」という不思議な流行があった。

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

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

JSONって、その系統のソリューションじゃねぇの？全然調べてねぇけどｗ

>>11
細かいようだがroffは構造を持ってないぞ。

TeXもroffも、それ自体は印刷方法を指定するマークアップ言語。

ただしLaTeXや manマクロ等は、構造化文書寄り

SXMLはともかく、JSONてXMLに変換できるの？
あ、YAMLは興味ない

言語の構造が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ＭＬの欠点、利点から学んだ新たな???????言語が登場。

となる未来がやってくるのではないかと予測。

＞SGMLがあまりにも難しかったために普及しなかった。

XMLも十分面倒臭いよ

めんどくさい≠むずかしい

面倒さが問題を難しくする

XMLがその典型

--- YAML ---
構造は インデント で表す
リストは ダッシュ で表記する
（キー・値）ペアは コロン で区切る

--- !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.

インデントという時点で2chではヤバくて使えない

--- 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.

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>

こりゃ、Perlの連想配列と一緒だな。
・・・orz

そういえばポスト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

>>20
> ＞SGMLがあまりにも難しかったために普及しなかった。
>
> XMLも十分面倒臭いよ

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

書くのが面倒くさい？

その問題はツールなどを使えば大抵は解決すると思われる。

>>27
それを見るとどうみてもXMLのほうが
読みやすく感じる。

PostXMLといい切るにはXML並の読みやすさが必要なんじゃないかという気がする
がどうだろう？

>>31
読みやすさよりも、使いやすさだね。
XML ほどの汎用性は求めず、特定用途での扱いやすさを優先している。
バベルの塔の崩壊と言葉の混乱ってやつかと。

JSON は Javascript のサブセットなので
Javascript Engine が直接解釈できるのが肝なんだと思う。
例えば Perl やらで作ったウェブアプリケーションが
JSON を吐けば XML でデータを送るよりも
ブラウザが高速に処理してくれる。

>>32
それはつまり、
ポストXMLというには無理があると？

ちなみに 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で出来た事を今更。。。

だからって、普通スクリプト言語をデータベースとして使ったりはしないだろ

おまえの発言は、常に前レスのコピーだから相手にしたくなくなる

JASON凄い

YXMLｶｺｲｲ

SEXPRは神

>>35
そうですね。お話の続きをどうぞ

>>34
実行時まで発見されないっていう認識は勉強不足だな。

たとえばSEXPRはS式なわけよ。
読み込み段階でS式と同じチェックは行われるし、
実行前にいくらでもフィルターを通す事も自在。
S式だから当然quoteも使えるということを忘れてはならない。

あぁーこれだから・・・。
あんた主張すべきポイント、間違えてるよ

構造に間違いがあっても、静的にチェックできない
つうのがポストXMLの特徴の一つなんだろ。

「構造に間違いがあるかないか、保証する仕組みを外した」くらいの表現のほうがいいか。

XML スキーマに相当する物ってこと?

validatedでないつうこと

>>40
読み込んでからチェックすればいいじゃん。
何不都合でも？

>>40-44

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

問題ありありだろ。

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

ここでスルー出来るかどうかでこのスレの行く末が決まるな。

んーつうか、XML の用途すべてを置き換えるようなものじゃないだろ。
共存していけばいい。

>>45
SXMLをreaderに組み込めば読み込み中にもチェックできますが何か？
何を問題にしてるの？

JSONの話題しか振ってないのに、
いつの間にか SXMLの話にすり変わって、
挙句にvalidated XMLもわからなそうなの
が食いついてるので、萎えた。

掲示板とはそういうもんだ

ここにも頭おかしいのが粘着してるのか。

＞JSONの話題しか振ってないのに、

おまえの都合の良い脳内補完機能には呆れた

お前が馬鹿だというのがよく判った。

ここでスルー出来るかどうかでこのスレの行く末が決まるな。

お前が荒しだという事がよく判る。

>>45 + >>47に賛成。

お話の続きをどうぞ。

well-formedはチェックするだろ．

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

>>1のリンク先は一切読んでないけど、
このスレの流れ的には、どうやらそーゆー用途みたいね。

で、>>34後半なわけですよ、経験上。

1. 当然 validate もサポートしているよん
2. validate 処理なんて簡単に書けるから要らん
3. XML と相互変換可能だから、一旦 XML に直して validate する
4. validate する必要無い用途で使うから気にすんな
5. validate は悪

誰か分類してくれ
1 か 4 が多そうだが

>>34＝>>59が軽くスルーされているのが気になる。

>>60
用途次第。多数決で決めるもんではないし

ちゃんとレスを読んでくれ
荒れる遠因だから

ごめん、>>60の意図がわからん。
自分で判断せず、周りの意見を聞きたいという事か？

あと>>34＝>>59の意見を無視する理由を教えてくれ。

意図が理解出来ないならレス付けるなよ
紛らわしいから

頭悪そうなレスだな。いい加減にしろ

おそらく>>60の脳内には
(各種XML代替構文についてvalidationへの対応状況を、誰か調べて次の1〜5に分類して一覧にしてくれ)
という一文が隠れているのだろう。それは>>60を読めば判る。

意図不明なのは、>>60の調査結果を示していないこと。

他は知らんが JSON なら eval すれば valid かどうかわかるでしょ。

>>67
それは構文間違いが無いという意味でしょ
意図したデータ構造であるかは eval するだけじゃ分からないと思うけど

すま。わかるのは well-formed かどうかか。
interoperability は重視していないってことなんだろう。

>>69 俺もそれ考えてた。

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

LAML は validator あるみたいね

ttp://www.cs.auc.dk/~normark/scheme/tools/dtd-parser/man/dtd-parser.html

http://www-6.ibm.com/jp/developerworks/xml/020208/j_x-matters14.html

XMLで十分

>>32
XMLパースを簡単に行えるライブラリが公開されたので
通信データにJSONを使うメリットはなくなったのでは？

JKL.ParseXML - XML→JSON展開クラス
http://www.kawa.net/works/js/jkl/parsexml.html
JKL.ParseXMLを試してみた
http://mizzy.org/program/jklParseXML.html

>>74
XMLとJSON(っつうか連想配列)のセマンティクスは微妙にずれてるから
JKL.ParseXMLのAPIも結構苦労の跡が見える。

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

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

結局扱いたいデータがXMLに向いているか、JSONに向いているか
ケースバイケースで使い分ければいいんじゃね？

>>75
> XMLとJSON(っつうか連想配列)のセマンティクスは微妙にずれてるから

どこ？多重度のあたり？

あと、属性か要素か、っつうのもアレだな

>>76,77
そんなとこ。

あと、RDB -> CGI(スクリプト言語) -> JSON-RPC は楽だよ。
スクリプト言語のRDBインターフェースはクエリの結果を大抵
連想配列とリストで返すから、JSONに変換するだけでブラウザに
返信できる。

ああ。7〜8年位前に、
典型的なDBメンテ型の情報系アプリで、
そんなんを冗談で検討した覚えがあるな。

確かJava DAO使ったOO設計やろうとしてる所で
Perl5 DBI使ったCGIに慣れてる香具師が
DB連想配列とCGIパラメータ連想配列の間で
データをコピペしてHTMLにベタに展開するコード書いてきたんで、
そんなら DBデータをJavaScriptのコードに即変換して、
JavaScriptでHTMLを描画しろよ、と。(DHTML〜XSL〜Ajax以前の時代)

昔からあるしJSONとかより全然読みやすいしXMLより
書くのがだいぶ簡単なのにSOXが流行らない理由が分からない。

ボヘミアンと貴族の闘争。

ってなに？

>>81
知らなくてもいい。

>>82が知らないだけ。

>>81
サッカーのチェコ対オランダ戦。

>>84
どっちがボヘミアン？

>>85
ボヘミア＝チェコ西部の地方

ぐぐって見たんだがSXMLの
<tag attribute="Attribute">
　<contents>こんにちは世界</contents>
</tag>
の標準的な記法って
(tag (@ (attribute "Attribute")
　　　(contents "こんにちは世界"))

でO.K?

@が非常に判別しにくい(tagと見分けがつきにくい)
のだけれど

S式パーサがあればXMLなんて不要。
どうしようもなく冗長なXMLを使ってる馬鹿は考えを改めた方がいい。

http://pc8.2ch.net/test/read.cgi/tech/1140006937/

http://61.197.151.26/20060725863648/omote/img200606/2006062521_1136191292.swf