Goto (trpg-xml ML) HTML Log homepage
Date: Thu, 29 Jul 1999 09:49:33 +0900
From: skoba@vox.tutkie.tut.ac.jp (KOBAYASHI Satoshi)
Subject: [trpg-xml:00029] Re: シナリオ DTD 感謝
Sender: skoba@caine.vox.tutkie.tut.ac.jp
To: trpg-xml@trpg.net
Message-Id: <199907290049.AAA22048@caine.vox.tutkie.tut.ac.jp>
In-Reply-To: Your message of Thu, 29 Jul 1999 00:20:16 +0900. <199907281518.AAA13275@pk.highway.ne.jp>
X-Mail-Count: 00029
小林＠豊橋技術科学大学です。
In Subject : [trpg-xml:00026] Re: シナリオ DTD 感謝
Message-ID : <199907281518.AAA13275@pk.highway.ne.jp>
梶田晃一 さん wrote:
>
> 小林さん、御意見とDTDの提案ありがとうございます。
> 梶田です。
>
> まずは小林さんの質問と御意見に対して一つずつ答えていきたいと思います。
>> SGMLの場合なんですが、属性というはそのタグを解釈した上での表現
>> であるとか、あるいは解釈した上でのアプリケーションの動作を制御するとか
>> のためのものと、私は理解していますので。
>
>
> 後者の「アプリケーションの動作を制御する為」というのはある程度わかりやすいと
> 思うのですが、前者の「タグを解釈した上での表現」とはどの程度のモノなのかが
> 感覚としても実際のレベルでも理解できていません。
えーと、「アプリケーションの動作を制御する為」に含めても良いんです。
適切な例ではないかもしれませんが、HTML での FONT タグの size とかface
属性など、あるいはDIV タグの align属性とかは、表現の指定になってますよ
ね。そういう例が頭にあったもので、「動作を制御」だけではなく「表現」と
いうのも書いといたほうが良いと思ったわけです。
> 上にも書いた通り、私が書いたときには
>
> 「タグがたくさん並ぶのは好きではない」とか
> 「あまり深く考えていない」とか
>
> でDTDを書いていますから、その辺りはまさに書き方の違いでしょうね。
いや、たしかにタグがたくさん並ぶと、書くのが面倒という問題はあります。
ただ、どうせ近い内に、一般にもxmlエディタとか出てくると思うんです。
すると、dtd を読み込ませることでタグを書くのも楽になるだろうと思うので、
タグの数はあまり気にしなくても良いのではないかとも思うのですが。
>> > <date version ="18-Jul-1999"></date>
>>
>> これは難しいとこですね。version をタグ内に入れるか、
>> タグで挟むか...私としては、やはりタグで挟むほうが良いと思うのですが。
>
> これも上の要素、属性の表示区別問題ですね。
>
>
>> あと、"data" というのと、"version" というのは意味が違いますよね?
>> ここでは、なぜ date の属性として version があるのでしょうか?
>
> これに関しても個人的な意見を示すと
>
> ・日付が更新されているのと改版がされているのは在る意味同期が
> 取れているのではないのか。
> （日付だけ進んで、改版されていないのはおかしいって言う意味で）
> ・これまた深く考えていない
>
> って所です。
>
> 最初は二つを別の情報として管理しようと思いましたが、進み方が
> それぞれ異なったりしていてはおかしいと思い、一方の情報だけでも
> 良いのではと減らしました。
>
> でも、良く考えるとおかしな表記はDTDとかで注意するのではなく、
> DTDを利用するアプリケーションとかで注意すべき（エラーを返すべき）
> 問題なのかもしれないですね。
> そう考えると、表現できる事は大いに越した事はないですからね。
考えてみたんですが、 version としてある日時を指定するのはあまりお
かしなことではありませんよね。何年何月何日バージョンとかいう表記はちょ
こちょこ目にしますから。するとタグは version にして、属性として
date あるいは number を持つとか、あるいは version タグで、
日付あるいはバージョン番号を囲むとかというほうが分かりやすいような
気がします。
>> > <hints><paragragh>シナリオをやる時には電気を薄暗くしてみると・・・
>> ></paragragh></hints>
>>
>> <hints>も、通常の文章のように書きますか?
>> えーと、つまりですね、 hints という言葉からは何となく箇条書のような
>> イメージを受けちゃうんですね、私だけだとは思いますが...
>
> そうですね。
> 要素 "hints" に関しては実際、どのようなことを書くのか見えてこなかった為
> かなり中途半端な作りだと思います。（どれも中途半端ですが）
>
> 逆に小林さんはどのようなヒントをここで示していくのでしょうか？
> 出来れば教えていただきたいです。
どこどこのシーンでは、これこれに気をつけることというような、
GMへの注意を列挙するような感じをイメージしてしまいます。
>> えーと、それから全般的なことですが、XMLにも閉じタグ無し...という
>> ような書き方がありませんでしたっけ? <?...?> だったか、 </.../> だったか
>> のような気がするんですが。
>
> 閉じタグ無しって言うのが「空要素 EMPTY」の事でしたら
>
> <要素名 属性 />
>
> と言うのが書き方です。
> ではなぜ、それを書かないかといいますと月刊ジャバワールド1999年6月号の記事で
>「（前略）複数の表記が可能であるとすると、二つの文章が同じないかどうか
> 比較したい場合などには、少し不便です。（中略）そこでジェームズ・クラーク氏が
> Canonical XML（規範的なXML）というものを定義しています。
> （http://www.jclark.com/xml/canonxml.html）
> （中略）
> 具体的な内容は、例えば次のようになっています。
> ・<○○/>でなく<○○></○○>を使う。
> ・属性はUnicode順にソートする。
> ・UTF-8でエンコードする。
> ・&、<、>、6quot;、	、 、 を使用する。
> ・無視する事が可能な空白も無視しないでそのまま扱う。
> (後略) 」
>
>と言うものが在りました。XML初心者でかつJava好きな私はこの記事でXMLをやろうと
>心に決めた事も在り、出来るなら上の規範を守っていきたいと思ったわけです。
>
>（最初の一つ以外はどうすれば良いのかわからないので、やっていません。(笑)）
>
> ですので、空要素を簡単に表記しないのはとても個人的な事です。
複数の文章が同じかどうかということで、何をもって同じと言いたいのか
によって条件は異なります。文章の見た目がまったく同じかどうかを、例えば
diff で見るような場合は、上記箇条書が効いてくると思います。しかし、実
際には、内容が同じなら良いわけで、文字コードの差とか タグの <xx/>を使
う使わないというのは本質的ではないと思います。つまり、それらは結局パー
ザの問題のような気がします。パーザがcanonial な出力を出せれば良いわけ
ですよね。ですから、上記箇条書は、人間に対しての「すべし」ではないと思
います。人間に対しての「すべし」は、「dtd に従ってね」というとこでしょ
う。もちろん、それすらも xml エディタが吸収するのが良いわけですが。
ともかく、 <xx/> = <xx> </xx> については了解しました。
>> それからですね、梶田さんは、何のためにXMLでシナリオを書こうとお考
>> えでしょうか? もしかしたら、そこのところを詰めておかないと、あとで大変
>> になりかねないなぁと思いますので...
> そして今XMLで表記したいものが以下のようなものです。
>
> 1.シナリオ
> 1.1 セッション内ストーリー(時間的な流れ)
> 1.2 セッション内登場キャラクター
> 1.3 セッション内アイテム
> 1.4 セッション内場所
> 1.5 セッション内情報
>
> 1.6 セッションをGMがどう仕切るかの流れ
> 1.7 セッションに参加する人物
> 1.8 セッションで使用するアイテム(フィギア、画像等)
> 1.9 セッション外情報（セッション時間等）
>
> 2.セッション結果
>
> 3.シナリオ作成の為のデータベース
> 3.1 キャラクター表
> 3.2 行動表（前の行動が次の行動を示すようなもの）
> 3.3 アイテム表
> 3.4 場所表
> 3.5 情報表
>
> そしてこれらを統合環境的なアプリケーションで纏めてみたいと思っています。
私の場合、データベースとしての目的が主になっています。もちろん、シ
ナリオそのものの記述もあるわけですが、シナリオの記述そのものをデータベー
スとして使えるような記述方法として xml (SGML) に魅力を感じたわけです。
> （というより、出来るなら統合的なDTDをここで作れたらと思っているのですが、
> どの様に話を進めていったら良いのでしょうか？
> このまま提案ばかりで良いのかな？）
うーん、やっぱりもっと意見が欲しいですねぇ ^^;。
-----