掲示板スクリプトデータフォーマット規定を作ろう
■ このスレッドは過去ログ倉庫に格納されています
この規定を定めることにより掲示板間のデータファイルの共有や
乗り換えが容易にできるようになります。
0160nobodyさん
02/12/01 13:03ID:1d1Iul5n表示方法をHTMLに限定すれば、それでいいんだけどね。
0161nobodyさん
02/12/01 13:29ID:vHw2oSY+016249
02/12/01 13:39ID:???>その上に乗せるコンテンツはこれからもっと進化(複雑化)していくだろうから、
それはレイヤが違うじゃんよ。今の議論は「掲示板データ構造」つまり
抽象化された「書き込み」という単位からなるデータ構造の取り扱いが
主題で、それがCSVなりCMTで十分と言っているわけだ。
そこに載せるデータストリーム(「書き込み」の実装)として
何を持ってくるかはまた別の話だろう。
>>156
XSLTによるマルチモーダル対応ってのはITバブルの頃に糞ベンチャーが
よくやってたテーマなんだが、俺はかなり疑問に思っている。
というのも、フォーマットレベル(例えばCHTMLとか)への変換はOKとして、
例えば画面サイズに由来する制約とか、一度に転送できる容量の
制約だとかは根本的にXSLTでは対応できないんじゃないか？
(XSLTより下のレイヤ、つまりXML生成時の対応が必要なんじゃん？ってことね)
結局マルチモーダル間の機械(XSLT)による完全対応はムリ、っていう結論だったと
記憶しているのだが。
最近の動向は知らんので認識に誤りがあったら指摘してくれ。
0163nobodyさん
02/12/01 13:46ID:vHw2oSY+0164nobodyさん
02/12/01 14:24ID:???>制約だとかは根本的にXSLTでは対応できないんじゃないか？
お前がそれをXSLTでやろうとしたなら神と認めます(w
0165nobodyさん
02/12/01 14:43ID:???・掲示板スクリプトデータフォーマット規定を作ろう
→書き込みの元データをXML形式で保存する方向で。
・掲示板書き込み内容のメタデータの規定を作ろう
→CMTで十分では。
0166nobodyさん
02/12/01 15:24ID:???って事を考えた場合に、CMTよりXMLの方が理にかなっている。
>それはレイヤが違うじゃんよ。
と、書いてあるけれど、他のDTDとかschemaを持ち出して書き込み内容を拡張できるってことでは、
CMTとかとは比べ物にならない拡張性を持っていると思う。
0167nobodyさん
02/12/01 15:25ID:UEbx5mYR0168nobodyさん
02/12/01 15:27ID:???016949
02/12/01 16:04ID:???>「例えば内容にsvgが入った場合どうなるか」
>って事を考えた場合に、CMTよりXMLの方が理にかなっている。
objection. 「理にかなっている」具体的な根拠は？
書き込みのbodyとして任意のバイナリストリームが許されるなら
body部を含む全体のフォーマットは何でもいいじゃん。何でもいいなら既存のでいいじゃん。
>>それはレイヤが違うじゃんよ。
>と、書いてあるけれど、他のDTDとかschemaを持ち出して書き込み内容を拡張できるってことでは、
>CMTとかとは比べ物にならない拡張性を持っていると思う。
「拡張性」にちょっと幻想を抱きすぎな気配。そもそも「拡張性」とは何か？
フォーマットを介してネゴシエーションを行う２者間に事前の合意がない限り、
一方が勝手にフォーマットを「拡張」しても意味がない（機械が勝手に一方の
「拡張」に対応してくれるわけではなく、そこには必ず人の介在が存在する。）
DTDを変更するということは「別のフォーマット」を策定するのと同じことで、
そのような状況下では「XML上で」という括りの持つ意味は
「テキストファイル形式で」という括りの持つそれとほとんど大差ない。
で、書き込みのbody部はともかく「掲示板データ構造」の進化は今後見込まれるのかね？
0170nobodyさん
02/12/01 16:19ID:UEbx5mYR＞ 一方が勝手にフォーマットを「拡張」しても意味がない（機械が勝手に一方の
それに関してはgracefullyにdegradeした形で解釈できるっていうメリットがあるでしょ。
0171nobodyさん
02/12/01 17:13ID:???掲示板作者としては、出尽くした感のある普通の掲示板から脱却して
それぞれ独自の機能をつけようと努力してると思います。
既存の掲示板フォーマットとしては統一されていると便利だとは思いますが、
これからユニークな掲示板を作ろうとしている人にとっては、フォーマットが
規定されてしまっていると足かせになりかねないかと思います。
XMLなら独自の意味づけで、このへんも融通が利くのでしょうか？
0172nobodyさん
02/12/01 17:19ID:???XMLなら適当にタグふやしたらいいんじゃない？
対応してない板ではそのタグを無視すればいいんだし。
増えた分で標準化できそうなものは規定にとりこめばいい
0173nobodyさん
02/12/01 17:24ID:???HTMLへの変換には(ほとんどのケースで)XSLTを使用します。
多分同じデータでもXSLTによってまったく違う表現ができると思われます。
>書き込みのbody部はともかく「掲示板データ構造」の進化は今後見込まれるのかね？
IPv6に対応とか、そういうことなら今後の展開はまったく予想できない。
0174nobodyさん
02/12/01 17:31ID:???>機械が勝手に一方の「拡張」に対応してくれるわけではなく、そこには必ず人の介在が存在する。
XML文章として認識されればそれで十分だろ？
0175nobodyさん
02/12/01 17:40ID:???（中略）難しい
0176nobodyさん
02/12/01 17:42ID:???ファイルのフォーマットを決めようって話じゃないよね？
なんかごちゃまぜになってる人がいる気がして。
0178nobodyさん
02/12/01 17:59ID:???荒らしてやってください。
できればメールも送ってやってください。
ＨＰ： ttp://ime.nu/members.goo.ne.jp/home/yamato-r/
メール：mailto:[email protected]
0179nobodyさん
02/12/01 18:00ID:???XMLを使った掲示板のサンプルを晒しやがってくれませんか？(;´Д｀)
0181nobodyさん
02/12/01 20:07ID:vHw2oSY+0182nobodyさん
02/12/01 20:39ID:hXhWchhyメールみたく
Subject: 題名
Date: 2003 12 1
（空行）
本文・・
・・
本文終わり
--
ちゅうか、思ったんだけど、なんで皆ニュースグループ使わないんだよ。
0183nobodyさん
02/12/01 21:05ID:???XMLを使った掲示板のサンプルスクリプトを晒しやがってくれませんか？
ていうかむしろそういう掲示板スクリプトを配布しているサイトのアドをきぼん。
といい直してみますた(;´Д｀)
018449
02/12/01 21:08ID:???>IPv6に対応とか、そういうことなら今後の展開はまったく予想できない。
なんでIPレイヤの変更をアプリケーションレイヤが関知しますか？
つうかそもそもなんで層化してるかわかってるのか？
>>175=181
MIMEが任意のバイナリストリームを取れなかったらどういうことになるか理解できる？
0185nobodyさん
02/12/01 23:02ID:vHw2oSY+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<svg width="400" height="350" xmlns="http://www.w3.org/2000/svg">
<desc>text element</desc>
<text x="20" y="80" font-family="MS-Gothic" font-size="40" fill="green" >
任意のバイナリストリームﾏﾝｾｰ
</text>
</svg>
0186nobodyさん
02/12/01 23:19ID:???氏ねや
0187nobodyさん
02/12/01 23:46ID:AABAJ9Cj0188XML厨
02/12/02 00:19ID:???XMLのスレ発見だぜ！みんなにも知らせてこなくっちゃ！
0190nobodyさん
02/12/02 16:19ID:???0193nobodyさん
02/12/02 22:25ID:???かなりの電波を発しているので、見るときは気をつけてください。
また、ヒッキーで２ｃｈを荒らすことを生きがいとしているさびしい奴なので、
できれば彼に励ましのメールを送ってやってください。
ＨＰ： http://members.goo.ne.jp/home/yamato-r/
メール：[email protected]
0194nobodyさん
02/12/02 23:21ID:???>>>176
>XMLで規定を作ろうとすると、そうならざるおえない。
じゃなくて、今までは保存形式と送信形式が別々だったものを統一できるんだろ。
49が
>>174にどう答えるのか非常に楽しみ
019549
02/12/03 00:26ID:???>>187
それはまさに>>151の可搬性で言っているところの「下位互換性」の維持に関する
メリットなんだが、このメリットに関しては小さな疑問と大きな疑問の２つが存在する：
小さな疑問: CMTの仕様書を読んでみたが、これも識別子を追加することで
アイテムの拡張ができそう（というか更新履歴を見る限り実際している）だがどうか？
（例えばHTTPのようなkey=value形式のフォーマットと比較した場合、互換性に関する
XMLのメリットって何？）
大きな疑問: >>151で言っている通り、そもそも「掲示板データ構造」に今後進歩ってあるの？
>>194=174
>XML文章として認識されればそれで十分だろ？
とだけ言われてもなあ。何に十分なの？
well-formedあるいは更新されたDTDでvalidなXMLだったら
古いプログラムも人工知能よろしく追加ノードに勝手に対応してくれるってこと？
0196nobodyさん
02/12/03 00:38ID:???（XML厨は視界狭いみたいだな）
0197nobodyさん
02/12/03 01:30ID:YmZ1Amf/0198nobodyさん
02/12/03 01:39ID:YmZ1Amf/XMLならもっとリッチな内容を含みうるというのもあるだろうか。
そういえば記事内容をXMLでどうするかっていう議論はまだ出てなかったっけ。
0199nobodyさん
02/12/03 01:42ID:YmZ1Amf/多様性は増すことはあっても減ることはないだろうと普通の考えは思うね。
その辺は>>171が書いてるけど。
0200nobodyさん
02/12/03 02:09ID:YmZ1Amf/「CSVで十分」-「CMTで十分」-「XMLで十分」
とか並べるとして、CSVとCMTでもだいぶ違うから
どういう立場で主張するかというのをはっきりさせたほうが
議論がしやすいだろうと思った。
0201nobodyさん
02/12/03 02:39ID:???CSV、2ch の .dat、など。
順序に意味があって、決まった区切りでフィールドを並べていくもの
多くは行指向と言ってもいいかも。
CMT、RFC 2822/822、.ini:
key と value のペアを並べていく。場合によっては「セクション」
「カテゴリ」のようなものがある。
多くは行指向と言ってもいいかも。
XML などの mark up 系:
木構造をベタに展開したもの。
行指向ではないことが多いかと。
あとは、(lex+) yacc のお世話になるようなものがあるけど、ここでは
省きますか。
0202nobodyさん
02/12/03 02:39ID:???把握してる香具師は存分に語ってください。
漏れは決めるべきことが決まっていればどんな形でもかまわんなー。
ただ、データとしての美しさよりも、
掲示板のような負荷の高いものはパフォーマンスと
クライアントへの配慮(あつかいやすさ)が重要だと思う。
0203nobodyさん
02/12/03 05:04ID:Yy0QufYv0204まともな神経の持ち主
02/12/03 07:30ID:???0205nobodyさん
02/12/03 07:33ID:???単純にflashでも、htmlでも対応出来る。これしか思い浮かばない。
あとメンテが楽とか。
誰か代わりに>202に語ってくれ。
0207nobodyさん
02/12/03 09:40ID:8ebcifH1どこをどう読んだら「今時改行できない掲示板なんてあんの？」ていう
レスが出るのかわかんない。
0208ＣＭＴ厨
02/12/03 09:51ID:???CMTは改行を複数含む文字列をメッセージとして扱うことができるんだけど。
「改行区切り」ってどういう意味？何を「区切ってん」の？（藁
0209nobodyさん
02/12/03 10:31ID:8ebcifH10210nobodyさん
02/12/03 10:34ID:8ebcifH10211ＣＭＴ厨
02/12/03 11:03ID:???…
その「区切り」はコンピュータの処理上なんかイミがあんのか…
>>198がダウトっつってんのは、アンタの言う「改行区切りの文字列」と
XMLのノードが持つ値との間に本質的な差が無いってことだよ。ワカル？
0213nobodyさん
02/12/03 17:13ID:???>>XML文章として認識されればそれで十分だろ？
>だけ言われてもなあ。何に十分なの？
>ell-formedあるいは更新されたDTDでvalidなXMLだったら
>古いプログラムも人工知能よろしく追加ノードに勝手に対応してくれるってこと？
掲示板に関する規定作ったところでプログラムが意味解釈してくれる訳じゃないぞ
schema書けば、要素の内容のデータ型については定義可能だが、
あくまで処理装置が意味解釈をしている訳ではない。
古いプログラムが勝手に対応してくれないから"Adobe® SVG Viewer"
みたいなもんが必要になるんだろ？
と、電波を飛ばしてみる
0214nobodyさん
02/12/03 17:36ID:???ＸＭＬは，インターネット上でそのまま利用可能であること。
ＸＭＬは，広範多様なアプリケーションをサポートすること。
ＸＭＬは，ＳＧＭＬと互換的であること。
ＸＭＬ文書を処理するプログラムを書くことは，簡単であること。
ＸＭＬにおける任意的な機能の数は絶対的最小限に，理想的には０にとどめられるべきである。
ＸＭＬ文書は，人間が読み書きでき，相当程度に明快であるべきである。
ＸＭＬの設計は，迅速に準備されるべきである。
ＸＭＬの設計は，形式的かつ簡潔であること。
ＸＭＬ文書は，作成しやすいこと。
ＸＭＬマークアップの簡潔さは，最低限の重要性しかない。
0215nobodyさん
02/12/03 17:44ID:???掲示板ログフォーマットと一緒くたに考える必要ないんじゃない？
アプリで使う分には拡張性もあるし使いやすいだろうけど、掲示板ログとしては処理が大きくなって向かないと思う。
0216nobodyさん
02/12/03 17:46ID:???0217nobodyさん
02/12/03 17:59ID:IQRudvo/>>1で、1がCMTの宣伝のためにスレを立てる、>>5でCMTの宣伝をするために、
メール欄にスペースを入力してIDを隠す、
>>2-3で、普通に2get＆応援。
>>4で、「XML」の単語が出てくる、>>1焦りだす、
>>5で、CMTフォーマットを披露、見事に無視される。
(再びCMTの単語がスレに搭乗するのが>>46ってのが…)
>>6- XMLやCSVについて利点などの面で話し合い。
「<>カカレタラデータハカイサレルヨ」…①
「またXML厨か」
等の電波が飛び交うがほとんど無視される。
(てか、"<>"を書かれてデータが破壊されるなら、①の書き込みをした時点で、
このスレのdatを破壊した気分になってたのだろうか？もしかして期待した？)
まぁ、>>1の今後に期待。
0218nobodyさん
02/12/03 18:02ID:IQRudvo/0219nobodyさん
02/12/03 18:30ID:G6bUnBgc俺はCMTはそこそこよくできた規格と思うけど
XMLでやるならそっちがベターだと思うよ。
>>211は「XMLならもっとリッチな内容を含みうる」の意味がわかってない。
＞「改行区切りの文字列」とXMLのノードが持つ値との間に本質的な差が無い
って全然違うでしょ。
（「XMLのノードが持つ値」っていうのは要素の内容のことか？）
単に要素の内容に<hoge>text</hoge>みたいなものしか使わないなら確かにそうだろうが
<hoge>a<foo>b</foo>c</hoge>ならどうよ。
>>211はXMLをkey/valueを別のやりかたで書き換えたもの程度にしか理解してないんじゃないのか。
0220nobodyさん
02/12/03 18:32ID:G6bUnBgc「改行を複数含む文字列」だけでどうするかとか、そういう例を考えればいい。
0221nobodyさん
02/12/03 18:35ID:G6bUnBgc46は俺だが49ではない。
0222nobodyさん
02/12/03 18:36ID:???0224nobodyさん
02/12/03 20:19ID:???それは関係ないよね。
データの中身の解釈はまた別のレイヤの話だと思う。
0225nobodyさん
02/12/03 21:57ID:???1.XML関係のモジュールが入ってるサーバが少ない
=>ツリー構造が生かせない
2.XSL経由でデータを送ると全てユニコードになってしまう
=>ユニコード用のライブラリがみあたらない
(Jcode.pmが入っているサーバが少ない)
CSVとXMLの比較の例
例：データからメールアドレスを取り出す(スクリプトはperl)
CSV
データ：no,name,date,mail,pwd
スクリプト：(undef,undef,undef,$mail) = split(/,/,$_);
XML
データ：<data no="no" name="name" date="date" mail="mail" pwd="pwd">
スクリプト：$_ =~ /mail="(..+?)"/; $mail = $1;
0226nobodyさん
02/12/03 22:12ID:???CSV
split関数の方が処理が早い。
データ構造が簡単なので扱いやすい。
XML
欲しい要素に直接アクセスできる。
(データの要素が増えてもスクリプトに手を加える必要がない)
っていうかむしろ
>>56みたいな議論をするのがこのスレの本来の目的なのではないかと思ってみたり。
>>1も予想外の展開なのかっ？
0227nobodyさん
02/12/03 22:18ID:8ebcifH1そんなことないでしょ。
<xsl:output encoding="Shift_JIS"/>
＞ XML
＞ データ：<data no="no" name="name" date="date" mail="mail" pwd="pwd">
＞ スクリプト：$_ =~ /mail="(..+?)"/; $mail = $1;
こんなことやるつもりなの？
0229nobodyさん
02/12/03 22:27ID:???しょちゅうバージョンアップがある規格は見通しがもてていない証拠
0230nobodyさん
02/12/03 22:29ID:???<xsl:output encoding="Shift_JIS"/>
はなぜか無視されるようです。
>こんなことやるつもりなの？
一例ですから？
0232nobodyさん
02/12/03 22:35ID:???ユーザーに送信する時に、読み取ってマークアップすれば、
>>1の
>この規定を定めることにより掲示板間のデータファイルの共有や
>乗り換えが容易にできるようになります。
は可能だろ？
乗り換えるときにもデータを共有するときにも、一度CGI通してマークアップしなきゃだけど…
0233231-232
02/12/03 22:37ID:???<xsl:output encoding="Shift_JIS"/>
はformのエンコーディングには関係ないよ
http://qa.xml.gr.jp/data/xsl/files/0014.xml
0234nobodyさん
02/12/03 22:40ID:8ebcifH10235nobodyさん
02/12/03 22:40ID:???正規表現じゃいけないですか。
これくらいしか思い浮かばなかったんですが
もっといい方法があれば教えて欲しいです。切実に。
>>231
?
0236nobodyさん
02/12/03 22:43ID:???いいたいことあるならはっきりかけよう。スレ汚してるだけじゃん。
0238nobodyさん
02/12/04 01:04ID:4LjPmisD<data>
<mail>
</mail>
</data>
perlの正規表現でどう処理してるの？
023949
02/12/04 01:11ID:???まあエンコード戦略がしっかりしてさえいれば、
スタックの必要な文脈自由文法に基づくパースよりも
正規表現でさくっとできるパースは優れている、かもね。
>>213
わかってると思うけど>>195は>>194=174に対する皮肉ね。
なんか発散しているようなので問題をまとめると、
「掲示板データ構造」が
Ｓ＝（Ｖ，Ｅ）（Ｖは各書き込みのノード、ＥはＶ間の二項関係）
で表現＊し得る＊ものであり続けるならば、
わざわざXMLを導入するメリットはない（それこそCSVで十分だ。）
さて、この「掲示板データ構造」の本質的な変化は今後起こり得るだろうか？
起こり得るとしたら、どんなものが想定されるかな？
（一部の理解の悪い人たちへの注釈：
書き込みのbody部がいくらリッチになろうが、
それは「掲示板データ構造」の本質に影響を与えることはない。
アンカーでもsvgでも動画でもなんでもbody部としてエンコードしてしまえば
「改行区切りの文字列 (>>198)」となって終了）
0240nobodyさん
02/12/04 02:16ID:???<item><n>名前</n><e>メアド</e><d>日付</d><m>本文</m><t>タイトル</t></item>
<item><n>名前</n><e>メアド</e><d>日付</d><m>本文</m><r>親番号</r></item>
<item><n>名前</n><e>メアド</e><d>日付</d><m>本文</m><r>親番号</r></item>
・
・
・
($n,$e,$d,$m,$r) = (split(/<.+?><.+?>/,$str))[1..5];
0241nemui
02/12/04 03:24ID:???だったら、パース処理を書くのが楽な CSV なり CMT のほうがいいじゃない、っ
てことになる。
でもパース処理なんて毎度書くのもどうだろう。単純な split やパターンマッ
チによる key, value の抜き出しで処理するのが面倒な構造が必要になった場
合はいやになる。もちろん、split で済むようなものなら、それですませてす
まえばいい。
あと、CSV とか key value な表現形式だけど、複雑な構造を encoding する
場合、具体的にどうやるかってことになると一般的でかつ、明確な合意っての
はないような気もする。なにか作るたびに、通信当事者間で、そのあたりの約
束事を作りこんでいかなくてはならない。で、そういうところで変なバグを
誘発する原因は高くなる。
0242nemui
02/12/04 03:25ID:???低限、DOM tree 程度のデータ構造は得られるであろう、という期待は持てる。
さらに XML-RPC なり SOAP なりを使う、ってレベルにまで通信当事者間で合
意がもっていければ、メソッド名と、引数の並びさえ決めればいいよね、って
あたりにまで持っていけるかもしれない。理想的には、どういうデータがネッ
ト上を流れるかは気にすることすら必要ない (SunRPC とか IIOP とかあるじゃ
ねぇか、なんて言われればそれまでだろうけど)。
XML だから特別に優れているというわけじゃないし、昔からいろいろあった。
まぁ、効率は悪いが、そこそこ使えなくはないから、長いものにまかれちゃえ
ばいいや、という割り切りで XML を使うかな、ってところじゃないですかね。
0243nobodyさん
02/12/04 08:03ID:C+9zfYjxCMTはそういう仕様じゃないでしょ。
というかアンカーなりSVGなりのエンコード方法を独自に新しく規定するの？ばかばかしい。
それならXML使ったほうがいいでしょ。
0244nobodyさん
02/12/04 08:09ID:C+9zfYjx0245nobodyさん
02/12/04 08:22ID:???0247nobodyさん
02/12/04 12:14ID:???1.5ｃｈや１ｃｈみたいなとこだと入れ子になるかも
CSVや<>で十分って人は拡張性についてはどうなの？
要素が増えたら後ろにつければいいってだけ？
列順をかえられないのでだんだんみにくい並び順に
なると思うけど。
規定フォーマットなんだから互換性が重要なんだし
XMLで定義してインポート時に自分の板にあった形式に
変換かければいいんじゃないの？
0248nobodyさん
02/12/04 16:57ID:5qCfRWF7>アンカーでもsvgでも動画でもなんでもbody部としてエンコードしてしまえば
TEXT要素(まだ決定した名前ではないが)の内容に動画バイナリを直に
(orエンコードして)書き込むなんて、まさに馬鹿がやることだろ？
181 ：nobodyさん ：02/12/01 20:07 ID:vHw2oSY+
要素の内容に任意のバイナリストリームを持ってくるなんて馬鹿な発言をしたのは誰ですか？
0249nobodyさん
02/12/04 17:19ID:LH+eBnJjアンカーつきのハイパーリンクを表現したかったら
<p>まじやばい情報は<a href="hoge.com">ここ</a>をクリック！</p>
みたいになるでしょ。
0250nobodyさん
02/12/04 17:37ID:???0251235
02/12/04 18:09ID:???データ=>XML
HTML文章の構造=>XSL
デザイン=>CSSなど
処理=>CGI
のように分担できるところがよさげです。
上のように作業を分担すれば、掲示板をより手軽にかつ安全にカスタマイズできるのではないかと思います。
>>233
情報ｻﾝｸｽ
>>237
XMLパーサーが入っていないレンタルサーバが多いのでなんともです。
>>238
1行につきデータ1単位という、CSV形式の方針をそのまま使えばいいのでは。
データ
<data><mail>mail</mail></data>
<data><mail>mail</mail></data>
処理(perlの場合)
while(<IN>){
$_ =~ /<mail>(.+?)<\/mail>/;
&subrutine($1);
}
これだとスタックがいらないのでよいのではないかと。主旨がずれていたらすまそ。
0252nobodyさん
02/12/04 19:13ID:???0253nobodyさん
02/12/04 19:21ID:???それじゃCSVと対して変わらない、
<data><mail>
</mail></data>
<data><mail(属性)>mail</mail></data>
・
・
・
には引っかからない、素直にパーサー使うべきだよ。
0254nobodyさん
02/12/04 20:24ID:???CSVや<>で十分派も納得させられるじゃないか。
0255251
02/12/04 20:59ID:???perlでモジュールを使わずにXMLを扱う方法はこれしか思い浮かばなかったのですが
実際のところどうなんでしょうか。
どこがやヴぁいのかよくわからないですが、
1.根本的に何かが違う。
2.処理速度が遅い。
3.その他
4.漏れの存在自体が危険
特に1だとどうしようもありませんが・・・
具体的にどこを改善すればよいのか教えてもらえると助かります。
0256nobodyさん
02/12/04 21:20ID:???2.むしろ拡張性を犠牲にすればこっちのほうが早い
3.子要素は？ <mail><mail></mail></mail>だとどうなる？ その他もろもろ
4.まぁ、XMLの勧告書を読んでから出直せ
025749
02/12/04 22:03ID:???書き込み間の関係と書き込み本体は互いに直交させておくべきと考えてるヤシはいないのね。
構造自体をグラフとして議論できる奴もいない、と。そんな連中が集まって勧告とはね･･･。
まあ頑張ってください。寿命の長い規格になるとよいですね（微笑
>>243
MIME
>>248
「アンカーでも」って書いてますが何か？
それと、あと５年もすれば動画も掲示板のありふれたコンテンツの一つになると思いますが、
そういう掲示板はサポート対象外ってことですね。なるほど。
0258nobodyさん
02/12/04 22:12ID:???>例えば画面サイズに由来する制約とか、一度に転送できる容量の
>制約だとかは根本的にXSLTでは対応できないんじゃないか？
画像サイズまで対応できないって電波飛ばしてた意味がやっとわかった。
■ このスレッドは過去ログ倉庫に格納されています