掲示板スクリプトデータフォーマット規定を作ろう
■ このスレッドは過去ログ倉庫に格納されています
この規定を定めることにより掲示板間のデータファイルの共有や
乗り換えが容易にできるようになります。
0334nobodyさん
02/12/06 03:46ID:???CMTですらオタクっぽくて全然使われてない。
0335nobodyさん
02/12/06 08:49ID:???ごっちゃになってるよな。
>>334
俺も既存の <> 区切りが処理が楽ちん(融通が利かないのは我慢)で好きだ。
CMTは元々出力を目的にしてるから、ログデータとしては考慮されてない模様。
XML厨な方に質問。
記事番号1、親記事、タイトル「あああ」、本文「いいい」
記事番号2、記事1への返信、タイトル「Re:あああ」、本文「ううう」
記事番号3、親記事、タイトル「AAA」、本文「BBB」
こんな感じの記事ログをXMLで保存するとしたら、おおよそどんな風になるの？
あくまで一例ってことでよろしく。
まず俺がXML勉強しるって感じですまんが。
0336お約束
02/12/06 09:26ID:???0337nobodyさん
02/12/06 09:32ID:???0338nobodyさん
02/12/06 09:52ID:71EnxhWl過去ログ嫁よ。
親子関係の表現には2通り可能ということで議論がある。
0339nobodyさん
02/12/06 09:54ID:71EnxhWl相手に向ける言葉としては批判でもなんでもないし皮肉として解釈するのも無理だな。
0340nobodyさん
02/12/06 10:05ID:???ここ数年は絶対ないな。負荷にうるさいもん。
XMLは、日本最大の掲示板が実用上採用しないだろうフォーマットである
という事実は、やはり意識しておいたほうがよさそう。
0341nobodyさん
02/12/06 10:25ID:71EnxhWl「匿名掲示板（仮）」はXML出力機能をもっていた。
http://kari.to/bbs/
http://kari.to/bbs/index.cgi?srd=194&style=xml
あといまの靴墨スクリプトはネイティブにXMLを採用している。
http://csmith.hp.infoseek.co.jp/xmlbbs/main/index.xml
0342nobodyさん
02/12/06 12:09ID:???「データファイルの共有や乗り換えが容易にできるように」
規定を決めることなので、各スクリプトがが普段持つ
データフォーマットとしてのものを決めるのでは無いことを
再認識していただいてこの後の議論を続けてください。
ようはフォーマット決めればその形式にエクスポートされたデータは
他のスクリプト使用時にインポートすればOKということだろ？
それようのバッチは作る必要があるけど。
0343nobodyさん
02/12/06 12:46ID:???0344nobodyさん
02/12/06 13:06ID:???<>形式で、行の最初をスキーマ定義にしとくってのはどうよ。
id<>parentid<>subject<>name<>email<>body<>(ユーザ要素)<>...
1<>0<>掲示板スクリプトデータフォーマット規定を作ろう<>nobodyさん<>age<>決めようぜ<>...
2<>1<>-<>nobodyさん<>sage<>2Get!!<>...
...
読み込むときは
@schema = split /<>/o,<LOG>;
@rows = ();
while (<LOG>) {
$i = 0;
my %item = map { ($schema[$i++] => $_) } split /<>/o;
push @rows,\%item;
}
こんな感じで。
0346nobodyさん
02/12/06 13:20ID:???print join("<>",@schema)."\n";
foreach $line (@rows) {
$i = 0;
print join("<>",map { $line->{$_} } @schema })."\n";
}
こんな感じかな？
あとはidとかemailとかbodyとか、それぞれ必須とか推奨とか
レベルが違うと思うけど、そんな感じの標準スキーマを決めればいいのかな？
0347nobodyさん
02/12/06 13:21ID:???0348nobodyさん
02/12/06 13:48ID:???foreach $line (@rows) {
foreach $k (keys %$line) {
$line->{$k} =~ s/</</gos;
$line->{$k} =~ s/>/>/gos;
$line->{$k} =~ s/\n/<br>/gos;
}
}
で、デコードはこの逆をすれば、
スキーマ要素によらず書き出すもの全部エンコード／デコードできるよね。
0349nobodyさん
02/12/06 13:50ID:???ｳﾂﾀﾞ。
0350342
02/12/06 15:13ID:???と、ずっと思ってたのだが、違うのか？
スクリプトでどういうデータ形式にするかは
作者次第だろ。すべてバイナリでもったりしたい奴も
いるかもしれないし。板の特性に合わせて作者が
考えるべきで、規定なんて決めてそれに従うような
風潮ができたら発想が狭くなるだけだと思うんだが…。
035156
02/12/06 17:08ID:???各設置人のスキルとか、鯖の負荷とか考えてやればいい。
書き込み処理
[
書き込みデータ受け取り
↓
CSVなりCMTなりのログデータ読み込み
↓
書き込み内容を末尾に追加、
↓
CSV(orCMT等)ファイルに記録、同時にXMLに書き直したものを別ファイルに保存
]
ってやればいいんでないの？
読み込み
[
XMLファイルリード
(and 鯖側で変換)
]
読み込み処理はこれだけで済む。
と、XMLファイルに記録するんじゃなくて、動的に生成するような事だと思っていたんだが、
鯖側の読み書きログまでXML形式にしようっていうと…
まぁ、そんなに激しい負荷のかかることじゃないからいいと思うけどね。
と、思いますた。
0352nobodyさん
02/12/06 17:20ID:???データの形式を決めるんだろ？
サーバー、クライアントがローカルに保存するデータの形式は各々が勝
手に決めればいいことだし、データ交換のための中間形式ならデータを
落としさえしなければ何だっていいってことになる。
現実には、転送用形式と別に交換用形式を用意する必要はないだろ。
0353nobodyさん
02/12/06 17:36ID:zJ8lEv59>ってことを >>195,>>239,>>285 で聞いている（がこの点に関する返答は
スレ内では未だにゼロだ。）
155
に
>そもそも、進化が終わった時点で規定された勧告ってW3Cでいくとどれくらいだろう…
W3Cにこだわる理由もたいしてわからんが、
進化の過程にあるものを定義するな(可搬性を議論するな)というなら、
世の中にHTML(XHTML)の可搬性を考えているやつはいないよな？
もっとわかり易く言うと、あれだ、テレビに付いてるビデオ端子、あれの可搬性(端子と流れる情報について)を考えたやつもいない筈だ。
テレビとビデオを繋ぐ方法は将来的に必ず進化するって事はわかりきってたし、今現実に進化してるからな。
ついでにXMLどころかSGMLも生まれなかっただろうな。
035449
02/12/06 21:08ID:???>進化の過程にあるものを定義するな(可搬性を議論するな)というなら、
>世の中にHTML(XHTML)の可搬性を考えているやつはいないよな？
HTMLはmachine-readableでないため(XML知ってるんだったら意味わかるよな？
ブラウザで読めるだろとかアホなこと言わないでくれよ)、
HTML(XHTML)の可搬性を考えるにあたって必ず考慮しなければならないことは、
「それが汎用の通信路で搬送され得るかどうか」
ということだけだ。その後の解釈はブラウザ任せだ。
画面が崩れてたって最終的なクライアント(人間)は読んでくれる。
>もっとわかり易く言うと、あれだ、テレビに付いてるビデオ端子、あれの可搬性(端子と流れる情報について)を考えたやつもいない筈だ。
>テレビとビデオを繋ぐ方法は将来的に必ず進化するって事はわかりきってたし、今現実に進化してるからな。
テレビ信号が守らなければならない最低限の規範
「特定の周波数帯に属する電気信号であること」
という合意があったからこそ、ビデオ端子の規格を決めることができた。
（つうかテレビ信号って全然進化してないと思うんだが･･･。）
今回の話は、machine-readableなデータ構造を決めようとしているにもかかわらず
「仕様の責任範囲はどこまでなのか」という議論がほとんどなされていない。
ツリーのみを前提としたフォーマットで一般のグラフ構造を記述することはできない。
データ構造における最低限の合意がない限り、そもそも可搬性を議論できようもないと思うのだが。
>ついでにXMLどころかSGMLも生まれなかっただろうな。
唐突すぎて論理の流れがわからないのでこういう結論に至った論理展開を激しく希望。
フィーリングとかじゃないよね？
0355nobodyさん
02/12/06 21:32ID:oYivAj3/0356nobodyさん
02/12/06 21:45ID:zJ8lEv59>(XML知ってるんだったら意味わかるよな？ブラウザで読めるだろとかアホなこと言わないでくれよ)
machine-readableだからディスプレイに表示できるんじゃないのか？
ブラウザで読めることの何処がアホですか？
>「仕様の責任範囲はどこまでなのか」という議論がほとんどなされていない。
タイトル読めよ
0357nobodyさん
02/12/06 21:49ID:???XMLで再定義された意味が無いな。
035849
02/12/06 21:50ID:???>>356
http://www.kanzaki.com/docs/sw/rdf-model.html
の最初の辺りを読め。
035949
02/12/06 21:51ID:???用語を間違えますた。素直に訂正してお詫び致します。
0360nobodyさん
02/12/06 21:54ID:zJ8lEv59おまえはせっかくHTMLでマークアップされたのに、
・何処から何処までが１段落なのか？
とかの、意味を処理装置が読み取ってそれに適した表示をすることを否定するのか？
036149
02/12/06 22:04ID:???(>>354のmachine-readableをmachine-understandableに読み替えてくれ（陳謝致します。))
それは否定しないが、別に段落表示がされなかったとしても
HTMLの最終的なクライアントは「人間」であるため、「文章の意味の送付」という
目的は達成される。従って最低限「文書の搬送が可能」でさえあればＯＫで、
それ以上の条件は「オプション」だとしても構わないわけだ。
だが、今回の話のようなデータ交換(EDI)となると話は違う。
機械が解釈できるためにはフォーマット以前の問題として
交換する情報の「データ構造」の合意がない限り不可能(人間が目で読むのとはわけが違う)だ、ということだ。
0362nobodyさん
02/12/06 22:07ID:zJ8lEv59P{
color:green;}
</style>
これを適用するためには意味解釈をしなくてはならないのではないか？
0363nobodyさん
02/12/06 22:11ID:zJ8lEv59「否定しない」
という言葉づかいはやめてくれ。
お前の肯定、否定でなにが変わるわけでもない。
>だが、今回の話のようなデータ交換(EDI)となると話は違う。
つまり、XHTMLを読むことはデータを交換(この場合受け取る)
ことでは無いとおっしゃるのか？
>交換する情報の「データ構造」の合意がない限り不可能
>(人間が目で読むのとはわけが違う)だ、ということだ。
schemaってものがありますが？
036449
02/12/06 22:12ID:???例えばそのcssを含むHTML文書が仮に白黒画面の端末上で表示されたとしても
「人間が理解できる文章がHTML文書の中に含まれている限り」
その文書の意味を人間に理解させるという目的は達成されているね？
つまり、その意味解釈機能は「文書の意味を人間に理解させる」という目的を
達成する上では必須ではない、ということだ。
0366nobodyさん
02/12/06 23:01ID:???そろそろ放置したほうが彼のためになります。
0367nobodyさん
02/12/06 23:06ID:zJ8lEv59>>>360で「否定するのか？」と聞かれたから
>「否定しない」と言ったまでだが。
すまんな、「否定しない"が"」が気に入らなかったんだ、
>HTMLの最終的なクライアントは「人間」であるため、
漏れは、HTMLは機械からみればただの文字列配列に過ぎないデータに
"その文字それぞれが、文章中でどのような意味を持つのか？"
をわからせるためのマークアップ言語だと思っているが、
最終的なクライアントに"プレーンテキストとしての意味"がわかれば最低限それで由？
>その文書の意味を人間に理解させるという目的は達成されているね？
それが"目的"なら(最低限、)プレーンテキストで十分だとおもうが？
>その意味解釈機能は「文書の意味を人間に理解させる」という目的を
>達成する上では必須ではない、ということだ。
達成する上"では"、な。
「文書の意味を人間に理解させる」だけがHTML(含むXHTML、特にXHTMLか？)
の目的じゃないだろ？
036849
02/12/06 23:19ID:???>「文書の意味を人間に理解させる」だけがHTML(含むXHTML、特にXHTMLか？)
>の目的じゃないだろ？
他にどんな目的があるかね？
ブラウザに表示するのも印刷するのも結局人間に理解させるためではないのかね？
0369nobodyさん
02/12/06 23:21ID:zJ8lEv59"意味"を"処理装置が読み取って"それに適した表示をする。
0370nobodyさん
02/12/06 23:22ID:zJ8lEv59最終的なクライアントが全てでは無いだろ？
037149
02/12/06 23:30ID:???顧客からの発注に対し、メーカーのシステムに在庫情報を問い合わせて
受注の可否を判断・通知するものとしよう。
このとき、商社のシステムは、「受注の可否を判断する」という＊目的＊で
メーカーのシステムと「在庫情報」の交換を行っている。
これがEDIだ。「在庫情報」は機械が解釈するため、その仕様に曖昧さは許されない（定義されていさえすれば多様性は許される。）
だがHTML(XHTML含む)の目的はこのようなクリティカルなデータ交換ではない。
今回の掲示板データフォーマット、ってのは機械が解釈できるようにするんだろ？
037249
02/12/06 23:32ID:???>最終的なクライアントが全てでは無いだろ？
全てだろう。というかこういう書き方をされると手間なので
最初に何が書きたいのかはっきりしてくれないか？
0373nobodyさん
02/12/06 23:43ID:???これは警告だ。
0374nobodyさん
02/12/07 00:02ID:IF9f0MTH>>最終的なクライアントが全てでは無いだろ？
>全てだろう。
最終的なクライアントとの間にもさまざまなクライアントが存在していて、
そういったクライアントが意味解釈をするためにも
(最終目的と途中の手段を取り違えている訳ではない)
HTMLでマークアップすることは意味あることだと考えるが？
>これがEDIだ。「在庫情報」は機械が解釈するため、その仕様に曖昧さは許されない
>（定義されていさえすれば多様性は許される。）
>だがHTML(XHTML含む)の目的はこのようなクリティカルなデータ交換ではない。
HTML(XHTML)でも"曖昧さのない情報交換"も"定義によって拡張された情報の交換"
も可能だろ？
0375279
02/12/07 00:08ID:???>と、漏れも当初は思っていたのだが、それにしては抽象化のできない奴が多過
>ぎると思ったので。
そこはあえて無視しているというか、過程を飛ばしている、という考えかた
も好意的に見れば可能でしょう。まー、2ch において、そのようなことをする
必要は必ずしもないが。
で、実際にこのスレがどうあれ、また、希望としてはどうあれ、世界をみわ
たせば、人それぞれの差というのは大きい。
そこから話がそれるかもしれないが、そういう差というのは抽象化の作業だ
けじゃなく、なんらかの規格を実装をする、という作業においても同じだ。
そういった点において、相対的にスキルの低い人間が実装した場合に限りな
く悲惨なものができあがってしまい、カオスを生み出した MIME は失敗だった
のではないだろうか、とか思ってる。
>>354
>「仕様の責任範囲はどこまでなのか」という議論がほとんどなされていない。
これはだいたい同意というか、おそらく漠然としたイメージを既に皆が
持っているからか、明示的というか、具体的に示されてはいなようだね。
>ツリーのみを前提としたフォーマットで一般のグラフ構造を記述することはできない。
「ツリーのみを前提としたフォーマット」って何?
たとえば、RDF ならば directed graph は表現できるように思えるけど。
graph theory はちゃんと勉強したことはないので変なこと言ってたらスマソ。
037649
02/12/07 00:32ID:???>最終的なクライアントが人間で無い例をあげてみてくれるか？
>>371にある商社のシステムは、最終的に商社のシステム＝機械が受注の可否を決定しているね。
>HTMLでマークアップすることは意味あることだと考えるが？
HTMLでマークアップすることに意味がないと言っているのではない。検索エンジンなども
HTMLのマークアップ情報を利用しているし、その意味では検索エンジン＝機械が解釈している、
ともいえる。
が、HTMLのマークアップはあくまで「あったらいいね（なくてもまあ、なんとかなる＝読める）」
という位置付けであることは理解していただけるだろうか。
それに対し、掲示板データフォーマットを決める際には、そのプレゼンテーション方法
(XMLにするかCSVにするかCMTにするかMIMEにするか)を決める前に、まず前提として
掲示板というものの「データ構造」を定義する必要がある、と（ずーっと上の方から）
主張しているのだが、わかっていただけるかな？
>HTML(XHTML)でも"曖昧さのない情報交換"も"定義によって拡張された情報の交換"
>も可能だろ？
交換するプレイヤーが全員合意できる約束事をHTML(XHTML)の上に載せれば十分可能だ。
ただ、それをHTMLの上に載せることにどれだけ意味があるのか不明だが。
037749
02/12/07 00:44ID:???>「ツリーのみを前提としたフォーマット」って何?
えっと、これはXMLのことではなくて、掲示板データ構造のことね。
例えば掲示板データフォーマットとして書き込み間の関係を記述するにあたって、
各記事がその親記事のIDを１つだけ持つ、という決めにした場合、
ルート記事があるという前提でそのフォーマットはツリー構造以外の
掲示板構造をサポートできないよね？（2chみたいなのは特殊なツリーとして
捉えることができるけど、例えば関連記事を複数指定できるようなのはムリ
ってことね）
で、そういう「どこまで変態的な掲示板まで認めることにするか」っていう合意が
ないと、結局フォーマットの規定なんてできないんじゃないか、と。
0378279
02/12/07 00:52ID:???>えっと、これはXMLのことではなくて、掲示板データ構造のことね。
了解。
で、「どこまで変態的な」だけど、とりあえずは過去から現在まで
見られた掲示板的なものをある程度サーベイするなどは必要だろうね。
パソ通にしてもホストシステムによりいろいろあったし、NetNews は
あるし、昨今の Web 掲示板、さらには日記システムや blog 系の
システムなんかも、一種の掲示板的使われかたがある。
さらには Wiki とか。
なんにしてもグラフで表現はできるね。では、そのグラフに対して
どのような制約を設定するか、だな。
0379279
02/12/07 01:13ID:???>>282
> バイナリをMIMEで持つのはいいとしても、
> いちいち変換するのは面倒じゃない？
> 単純に別ファイルとして保存してあるバイナリにリンク張るってのはダメなの？
1. message/external-body で
access-type に HTTP のようなものを指定し、
name に URL とかを書くようにする
2. text/html とか text/xml+xhtml (だったかな) ならば
img タグで URL を指定
3. HTTP で使われているみたいに、単にバイナリをたれながしてしまう。
Content-Length でデータの終端を見極める
1. や 2. は RFC 2046 の 5.2.3.6. に述べられているような、また、最近言
われる「Web バグ」のような問題を引き起こす可能性もあるので、安易な規定
や実装は危険。3. は Content-Length: はエラー処理が面倒。
0380nobodyさん
02/12/07 07:48ID:???0381nobodyさん
02/12/07 11:28ID:xRJXJ2LG0382nobodyさん
02/12/07 12:17ID:???0383nobodyさん
02/12/07 12:24ID:???0384nobodyさん
02/12/07 12:47ID:???定義されていない情報でも、独自に意味自体を解釈して
そのデータを解釈する能力がコンピューター等と比べて飛躍的に優れているだけ。
0385nobodyさん
02/12/07 19:31ID:???0386nobodyさん
02/12/07 19:42ID:???0388nobodyさん
02/12/07 20:59ID:???思わず納得してしまうような。
038956
02/12/07 21:04ID:KahB7D1v0390nobodyさん
02/12/07 22:12ID:???お前たちがあまりにも悲惨すぎるので
俺が有名所の掲示板サイトを巡って 書き込み間の関係 を
調べてきてやったよ。
他にあれば適当に追加してくれ。
記事の位置を表す 8タイプ
この記事は記事aへの返信です
この記事は記事a,記事b,記事c...への返信です
この記事は記事aへの１行レスです
この記事は記事aを評価します(+1点)
この記事は記事aの続きです
この記事はxスレに所属します
この記事はxカテゴリに所属します
この記事はx,y,z...カテゴリに所属します
0391nobodyさん
02/12/07 23:15ID:bSS0h4J9＞この記事はxスレに所属します
この2つは
＞この記事は記事aへの返信です
に還元できるんじゃない？
カテゴリって具体的にどういうの？
039349
02/12/08 00:39ID:???>なんにしてもグラフで表現はできるね。では、そのグラフに対して
>どのような制約を設定するか、だな。
うん。記事間の関係も、たとえば2chみたいな">>\d+"をレスに含めるような
スタイルもあれば、いわゆるスタンダードなツリー（書き込みに返信していくタイプ）もある。
1chのような１行レスもあるがこの１行レスは独立した「書き込み本体」なのか
それとも主たる書き込みに付随する要素なのか、という問題もあるな。
最初にいろいろ切り分けておかないと破綻するだろうな。
0395nobodyさん
02/12/08 02:08ID:???カテゴリは2chの板だと思ってほしい。
例えば「この記事はxカテゴリに所属します」を具体的に言うと
>>1はWEBプログラミング板への新規投稿です
…となる。
しかし板と記事とを同列に扱うと、後で無理が生じる恐れもあるため
記事とは言わずにカテゴリと書いた。
0396nobodyさん
02/12/08 02:41ID:rGDePQLzあと複数のカテゴリに所属するって言うのは具体的にどのサイトでやってるの。
0397nobodyさん
02/12/08 02:46ID:???390 の人じゃないけど、カテゴリを newsgroup とするなら、
NetNews のクロスポストとか。
パソ通のホストでも、そういうのをサポートしているところがある
(そこは Web からも見れるが、Web から見る限りはわからない)
0400 ◆kelobi3ito
02/12/08 02:57ID:ubKy2Te30401nobodyさん
02/12/08 04:47ID:???これがまさにこれから決めなきゃならない重要な問題だよね。
NetNewsは持ってるけど、2chは持ってないよね。
0402nobodyさん
02/12/08 09:29ID:ZeoNMGBo0403nobodyさん
02/12/08 10:33ID:???0405nobodyさん
02/12/08 14:26ID:gXokz3Fs0406nobodyさん
02/12/08 17:00ID:???で話が終わってしまうようなもんか。
0407Proxy Authentication Required
02/12/08 17:52ID:???0408nobodyさん
02/12/08 17:57ID:tCL4JfFlデータ読み出し書き出しのモジュールを配布すれば
もっと広まると思う。
0410nobodyさん
02/12/08 18:25ID:???掲示板のスキーマによるから XML の読み書きライブラリと変わらないんじゃない？
netnews も wiki も同じく扱える巨大汎用規格ならいいけどさ。
Web サービスの WSDL のように、
スキーマをプログラムにマッピングできる規格が必要かと。
0411nobodyさん
02/12/08 21:55ID:???0412nobodyさん
02/12/08 22:11ID:???素直に他の団体から勧告されるの待てよ。
041349
02/12/08 23:44ID:???>それが>>390じゃないの？
そうっすね。ただ、１行書き込みは「書き込みクラス」のメンバにした方が
パフォーマンス面でいい気もする、とか、そのあたりの議論が必要かと思いますた。
何にせよ話題がXMLから構造そのものに移行するということはよいことです。
どんな規格を策定するにせよ、最初にXMLありき、という態度は到底健全とは言えないので。
0414nobodyさん
02/12/09 02:12ID:???個々の掲示板にはそのサブセットを使うと。
だるいね。
0415nobodyさん
02/12/09 03:29ID:???0416nobodyさん
02/12/09 15:51ID:???掲示板におけるベストなフォーマットにしたい49+(以下略
0417nobodyさん
02/12/09 17:51ID:???0418nobodyさん
02/12/09 18:02ID:???要するに49だけが浮いているということですね。
0419nobodyさん
02/12/09 19:53ID:???0420nobodyさん
02/12/09 22:29ID:UMmT4V+m書き込み時に変換しておくことで読み込み時の負荷を減らすことができるけど、
書き込まれたデータはなるべくそのままの状態で保存しておくべきだと思う。
HTMLで表示することを前提にしちゃってるしね。
レスがつけられる掲示板で親記事の内容もtextarea内に表示する場合、
もう一度「<、>、"」を変換しなおさなくてはいけないし。
0423nobodyさん
02/12/10 00:10ID:???またずれ始めてるぞ。
あと、
もうわかったからあふぉな>>49叩きはやめろ。見ててマジでｳｾﾞｪから。
0424nobodyさん
02/12/10 00:22ID:???http://pc.2ch.net/test/read.cgi/php/1007014580/308
0425nobodyさん
02/12/10 06:01ID:FaxsMvKu0426nobodyさん
02/12/10 06:22ID:???042749
02/12/10 07:56ID:???>ありえそうな全パターンを列挙して規定とし、
>個々の掲示板にはそのサブセットを使うと。
>だるいね。
誰もそんなこと主張してないぜ。普通に優秀な奴らなら、想定される全パターンを盛り込む
規格を作るなんて楽勝（残念ながらこのスレの連中にはそれすら望むべくもないが。）
難しいのはそうして集まったパターンを経済的合理性に基づいて切り捨てていく作業だ。
W3Cの連中は基本的にこれができていないので
XML Schemaなんていうバカげたfatな規格ができてしまうんだな。
042849
02/12/10 08:04ID:???誤 残念ながらこのスレの連中には･･･
正 残念ながらこのスレに粘着してるXML厨の連中には･･･
0430nobodyさん
02/12/10 08:10ID:FaxsMvKu0431nobodyさん
02/12/10 10:46ID:???がいるけどさ、perlのモジュールなんて多くは単なるテキストなんだから、ホームに
コピーしてuse libすれよゴルァ、と思うんですがどうでっしゃろ。
0433nobodyさん
02/12/10 13:05ID:???「想定される」パターンは確かに誰でも盛り込めるけど、
その想定ができないパターンについてどうやって
拡張性をもたせるかも重要なんじゃないの？
■ このスレッドは過去ログ倉庫に格納されています