智恵子は東京に空が無いといふ
宣伝
ネットマナーなる幻想
そろそろ徒委記にリンク集が出来ても良ささうな頃合ですね。閑話休題。「無断リンクはネットマナー違反ではないか」云々について、特定の人を対象とせず、久樹の個人的な立場から考へてみる。
そもそも、Webリソースの利用法について、制作者の意向を重んじるべきだといふ派と、利用者の意向を重んじるべきだといふ派の対立こそが、所謂「ネットマナー」対立の構図なのだと、久樹は考へてをります。
この議論では、既に結論が出されてをり、結局のところ利用者がリソースをどう利用しようと、どのみち制作者は有効な手立ては打てないとされてをり、ここには、著作権法の立ち入る隙はありません。何故なら、現在のWebの仕組みとして、リソースの利用法は常にオープンであることを原則としてゐるからです。
久樹は、制作者が何といはうと、（制作者を除く）万人に有益な利用法を曲げる気はありませんし、その旨はサイト上で宣言してゐます。それについてどこかのサイトで取り上げて罵らうと、（名誉毀損等に抵触しない限りは）その人の勝手であり、久樹は一々制限を加へる気はありません。といふか、私はそこまで暇ぢやない。
といふか、制作者の意向を尊重するなんて事は、マナー云々以前から、久樹の個人的な理念と公共の利益を踏まえて配慮出来る範囲でなら、昔から最大限に取り扱つてゐます。でなければ、検索サイトを拒否してゐるサイトには無断リンクをしないなんて処置はしない（当然、私はしたくないのだけど）
そしてこれは、「ネットマナー」なる怪しげなルールに依るものではなく、あくまでも「制作者の意向」と「利用者の意向」の妥協点に過ぎないわけです。この妥協点は、事例によつて当然前後するものですから、「ネットマナー」なる画一的なルールが成り立つわけがない。要は優先順位の問題だと、久樹は考へます。
ところで、「ネットマナー」支持者は、掲示板やチャット運営上などの特殊な事例と、所謂「無断リンク」といふ一般的な事例をしばしば混合して扱ひます。会話を中心としたローカルな場である掲示板やチャットであれば、相手の意向に最大限配慮する精神が優先されても良いでせう。しかし、情報を中心としたグローバルな場であるWeb全体においては、相手の意向はあくまでも意向として留めておくべきです。これを恣意的に混合してゐるのであれば、それこそネットマナー支持者は「議論のマナー」に違反してゐるといへます。
MFT、ついに参加曲公開！
最近FFT方面で目立つた動きがなくて寂しい思ひをしてをりましたが、MUSiC FANTASY TACTICS 2 にてついに参加曲が公開され、いよいよFFT+A2も開催が近づいてきたなあといふ気がやうやくいたしてまゐりました。
今回も前回にも増して素晴らしい曲ばかりですので、是非お聞きになられることをお奨めいたします。
痛すぎ…
口内炎が口の中に三つ出来る。
そして喉には得体の知れない白いぶつぶつが出来る（母はヘルパンギーナと推察する）
口の病気は体調の悪さを如実に表しますなあorz
XBELと似て異なる新たな言語を考へてみる
先日の書き方があまりにも雑で、しかも憶測と事実を交へた書き方であつたために、誤解を与へる（筆者自身まで混乱するやうな）悪文でしたので、もう少し冷静に書き足してみやうと思ひますので、今までの下書きは一旦破棄します。
今回の目的は、XBELにあつた問題点を解決した上で、多種類あるアドレスの情報を一元のフォーマットで互換出来る言語を考へてみやう。といふものです。「標準アドレス情報記述言語」（Standard Address Information Description Language）と称してSAIDELとでも言ひませうか。…さいでる？ 変に関西風な名前ですね。基本構造は以下の通り。
<saidel
（名前空間宣言）
>
<title>月夜同舟</title>
<dcterms:abstract>要約</dcterms:abstract>
<folder id="ID" uritype="http">
<title>タイトル</title>
<folder id="ID">
<title>タイトル</title>
<address href="URL" id="ID">
<title>タイトル</title>
<dc:date>日付</dc:date>
</address>
</folder>
〜云々〜
</saidel>
前回考へてゐたmeta要素を再び廃止したのは、不明名前空間要素の処理は、実はそこまで難しくない事が分かり、ならmeta要素のやうな面度な記述をする必要は無いと思はれたからです。
固有の要素はsaidel（ルート）要素、folder（構造化）要素、address（アドレス登録）要素、そしてtitle（タイトル情報）要素のみです。つまるところ、石川さんが提唱するSDFのやうに、構造化と最低限必要な情報のみを定義し、後はほぼ全てを拡張に任せるといふやり方。アドレスは必ずスキーム（http mailto ftp fileなど）から記述することによつてアドレスタイプを判別します（このやり方がベストかどうかは不明）
中でも、Dublin Core関連の語彙は最も良く用ゐられるでせう。SAIDEL対応UAには、最低限Dublin Core基本要素を知つてゐることが望ましく、出来れば精密化要素も知つてゐればなお記述メタ情報の幅が広がります。
ただ、記述情報の幅といふ考へを持つと、じやあいつそのことRDFで定義してしまつた方が色々と都合が良いのではないか？ といふ気が、個人的にはします。RDFなら、例えばDublin Coreの精密化要素を知らなくても、RDFのモデルを辿る事で基本要素にたどり着き、最低限の情報だけでも共有する事が出来る。やうな気がします。
やたら「気がする」を連呼してゐるのは、久樹がRDFを良く知らないからです。知らないものに口を出すわけにはいかない。勉強した後で、もう一度振り返つてみる事にして、取り敢へず、今のところ、久樹はこれが一番まともな形だと思ひます。
（RDFでいへば、RSSの考へ方を少し変へるだけで、十分にアドレス情報の互換として使へるやうな気がするのです。智識量が不足してゐるなあ）
XBEL再考を再考する
この記事の内容は現在推奨されません。削除はしない方針ですが、まあ、あまり見ないでやつてください。
以前、XBELの改善案として私が提案したサンプルコード（下参照）ですが、改めて、これを互換性といふ点のみを強調して考へると、実は少し困つた事が起こつてしまひます。（といふか、さう気づいた）
<xbel （名前空間宣言） > <title>月夜同舟</title> <desc>久樹 アマテル、及び弓状列島「高天原」の総合リンク集です。</desc> <folder id="ID" folded="yes"> <title>タイトル</title> <folder id="ID" folded="no"> <title>タイトル</title> <bookmark href="URL" id="ID" modified="2005-4-18"> <title>タイトル</title> <dc:date>2005-07-20</dc:date> </bookmark> </folder> 〜云々〜 </xbel>
このXBEL文章を、例へばDublin Coreを知らないブラウザが読み込み、新たに<ns:element attr="××"/>といふメタ情報を追加する時に未対応の名前空間の要素を完全に無視した場合、どうなるか。
<xbel （名前空間宣言） > <title>月夜同舟</title> <desc>久樹 アマテル、及び弓状列島「高天原」の総合リンク集です。</desc> <folder id="ID" folded="yes"> <title>タイトル</title> <folder id="ID" folded="no"> <title>タイトル</title> <bookmark href="URL" id="ID" modified="2005-4-18"> <title>タイトル</title> <ns:element attr="××"/> </bookmark> </folder> 〜云々〜 </xbel>
と、結果は上やうに、無視したDublin Coreの情報が揮発してしまふ事になります。これは、互換言語としてあまりにも致命的です。
このやうな事態を防ぐためには、XSLTにて全てのノードを一律処理した上で対応した名前空間の要素を別処理するといふ、あまりにも回りくどい処理が必要になつてしまひます。これでは使へない。XBELのinfo要素は、その点を考慮した作りになつてゐるのでせう。（しかし、それなら、どうしてわざわざinfo要素内にて属性を別名前空間で定義させるやうにしたのでせう。全て一律の名前空間に所属してゐないと、どの道処理がややこしいと思ふのですが…）
この問題を解決する方法は、実はHTMLの時代からありました。さう、meta要素です。
この要素は、名前空間など存在しなかつた時代から、独自にメタ情報を拡張出来るやうに定義されてゐます。それにならつて書けば、次のやうになるでせう。
<xbel （名前空間宣言） > <title>月夜同舟</title> <desc>久樹 アマテル、及び弓状列島「高天原」の総合リンク集です。</desc> <folder id="ID" folded="yes"> <title>タイトル</title> <folder id="ID" folded="no"> <title>タイトル</title> <bookmark href="URL" id="ID" modified="2005-4-18"> <title>タイトル</title> <meta name="独自の要素名" content="要素の内容" namespace="名前空間uri"/> </bookmark> </folder> 〜云々〜 </xbel>
かうすることで、要素の内容と、要素名と、その要素の所属する名前空間の情報が、同一の名前空間での要素で記述する事が出来ます。
あるいはcontent属性ではなく、そのまま要素のテキストノードでも良いでせう。そのはうが、含める情報の幅が広がりますし、複製もXSTLのcopy-of要素で簡単に行へます。
颱風5号消滅
颱風5号、福健省に上陸したところでついに力尽きた模様。
2005年07月20日 15時
<実況>
大きさ --
強さ --
熱帯低気圧
存在地域 華中
中心位置 北緯 28度 0分(28.0度)
東経 118度 0分(118.0度)
進行方向、速さ 北北西 ゆっくり
中心気圧 996hPa
中心付近の最大風速 -----
今夜から新潟
今夜の大阪発で新潟県長岡に行きます。なんだかここ1ヶ月で旅行三昧ですね。
当初予定では月曜の朝に帰る予定でしたが、何と「汚れの巣」のオフ会らしいので、日曜日の夜（21時40分）に帰られるやう変更いたしました。
どうぞ、へたれな奴ですが、よろしくお願ひいたします。
颱風5号その後
颱風といふものは、基本的に水温が26℃以上の海水域にゐる間は発達し、それ以下になると衰退いたします。勢力を強くするためには、最低でも28℃以上の海水域を通ることが望ましい。
さういふ中で、昨日の海水温の具合（気象庁：海水温分布図）
そして今日の颱風の具合。
2005年07月14日 21時
<実況>
大きさ --
強さ 強い
存在地域 マリアナ諸島
中心位置 北緯 19度35分(19.6度)
東経 141度25分(141.4度)
進行方向、速さ 西 25km/h( 13kt)
中心気圧 965hPa
中心付近の最大風速 35m/s( 70kt)
25m/s以上の暴風半径 全域 110km ( 60NM)
15m/s以上の強風半径 南西側 370km (200NM)
北東側 260km (140NM)
XBEL改造案
XBELの規格に、どうしても納得がいかない。具体的には次の通り。下書きなので、久樹も考へながら書いてをります。
- 名前空間を定義してゐない（参考：XBELで名前空間が定義されてゐないのはをかしいのではないか）
- XML言語でスキーマを定義してゐない（DTDだけでは力不足）
- 互換情報の記述方法が回りくどい。
- 総じて、XBEL単独で使う事、そしてブックマークの互換という役割しか考慮されてゐない。
- 久樹は、そもそも「メールアドレス、ブックマーク、リンク集、ISBN、住所」のやうな『収集した重複しないアドレスデータ（例へばURIとか）』という、本質的に同じデータを扱ふフォーマットは一本化した方が良いのではないかと思ふ。
- 当然「公開されたURL」と「非公開のメールアドレス」を混合して管理することは間違つてゐる。しかし、そのフォーマットを統一する事自体には、意味があるんぢやないかと思ふ。
- そして、XBEL（といふか、XML）には、その可能性が秘められてゐると思ふ。
といふわけで、かういふ構造で良いぢんやないのか。
現行
<xbel （名前空間宣言） > <title>月夜同舟</title> <desc>久樹 アマテル、及び弓状列島「高天原」の総合リンク集です。</desc> <folder id="ID" folded="yes"> <title>タイトル</title> <folder id="ID" folded="no"> <title>タイトル</title> <bookmark href="URL" id="ID" modified="2005-4-18"> <title>タイトル</title> <info> <metadata 〜何か別名前空間で定義した属性〜 owner="〜定義したURL〜"/> </info> </bookmark> </folder> 〜云々〜 </xbel>
改善案
<xbel （名前空間宣言） > <title>月夜同舟</title> <desc>久樹 アマテル、及び弓状列島「高天原」の総合リンク集です。</desc> <folder id="ID" folded="yes"> <title>タイトル</title> <folder id="ID" folded="no"> <title>タイトル</title> <bookmark href="URL" id="ID" modified="2005-4-18"> <title>タイトル</title> <何か別の名前空間で定義した要素（例えばDublin Coreとか）/> </bookmark> </folder> 〜云々〜 </xbel>
結局のところ
改善といひつつ、実は一つしか変えてゐない。つまり、メタデータは独自だらうが拡張だらうが全部同列で扱へといふこと。もちろん、名前空間を定義し、Schemaも定義する。そして、各自独自の名前空間を持つて勝手に要素を定義して記述しても良い事にする。要は、XBELにおいて「info/meta〜」でやつてゐたことを簡単にしただけ。
しかし、XSLT変換の面倒と処理工程数を考慮すれば、要素の階層は出来るだけ単純であるべきである。しかも、XBELでは拡張は属性に限定されてゐる。これも良くわからない。そもそも記述するのはすべてメタデータなのだから、知らない名前空間は全部無視すれば良いだけである。
後は、ルート要素にaddresstype属性でも設けて「mail」とか「isbn」みたいに指定して、それぞれtitle要素、name要素みたいなのを記述していけば、統一フォーマットとして使へるんぢやないだらうか？
――ただ、ここまで書いて思ふのが、例へば「住所と一緒に家族構成やその名前なども一緒に管理する」みたいな要望には、いくら拡張の提案をしたところで、答へきれないのではないかといふ気もする。RSSの例みたいに、モジュールといふ形である程度拡張を提案しておけば随分違ふだらうが。……うむむ。
何はともあれ、少なくとも、URLの管理だけでもDublin Coreぐらゐ簡単に利用出来るやうにして欲しい。といふのが久樹の思ひ。
といふわけで、とつととXBELは捨てて、ローカルはかういふ方向でいかうと思ひます。別にいくらローカルで組まうが、XSLTを使へば簡単にスタンダードなフォーマットに変換出来るのがXMLの強みでもある。そりあ、スタンダードなフォーマットが優れてゐれば、それに越した事はないのだけれど。
颱風5号発生
今年は割りと少ないですね。不作年？
2005年07月12日 18時
<実況>
大きさ --
強さ --
存在地域 南鳥島の西南西 約340km
中心位置 北緯 23度25分(23.4度)
東経 150度50分(150.8度)
進行方向、速さ 西 ゆっくり
中心気圧 1004hPa
中心付近の最大風速 18m/s( 35kt)
15m/s以上の強風半径 全域 220km (120NM)
XML周辺規格で公開がクローズといふのもどうだらうと思ふ
#XSLTオフ会で哀さんから、「颱風用のXMLマークアップが云々とか言つてたけど、BMLといふ規格もあるらしいよ」と教へて戴き、さつそく資料に当たらうとしたら、以下の記述を発見。
社団法人電波産業会（ARIB：Association of Radio Industries and Business）によって規定されたデジタルテレビ放送向けのコンテンツ記述言語。BMLは、XHTMLをベースにして、表示制御はテレビ組込みのCSS指定書式とし、コンテンツから表示制御をかなり排除したものとなっている。そのため、見かけはHTMLに近いが、ほとんどの場合、作り直さないと使えない。また、拡張性の高いB-XMLも制定されている。
（中略）
なお、文字コードとしては日本語EUCを独自拡張したものを用い、BMLで独自に拡張された文字が存在することから、B-XMLは、Unicodeに存在しない文字の使用を認めないXMLとは整合しない可能性もある。
BMLの仕様書はインターネット上で公開されておらず、紙に印刷されたものを社団法人電波産業会より購入しなければならない。
言ひたいことは分からなくも無いが、どうかと思ふ。
帝都物語〜2005年夏〜
つれつれと感想などを、纏まりもなく書いてみる。
帝都まで
その日は会社の宴会を早々に抜け出し、JR尼崎まで戻る時間もなかつたので、阪神尼崎から三ノ宮で乗り換へて神戸に戻る。ただ、常時JR新快速感覚の久樹に言はせれば、関西の私鉄は全体的に駅が多すぎる。駅を多く作るのは地下鉄部分だけであるべきだと思ふ。閑話休題。
出発5分前ぐらゐにバスに搭乗。実質着の身着のまま帝都物語を始めることになる。おまけに、ポケットから携帯電話が消滅してゐるといふ信じられない事態が発生。（後に確認したところ、地下鉄海岸線で落してゐたらしい。勿論既に回収済み）行つたこと無い、自信無い、情報も無いと途方に暮れつつ、結局どうしようも無いので「ま、何とかなるか」と結論付ける。
最低ランクのバスだけに、かなりキツイ移動だつた。といふか、緊張の上に後ろの客の鼾がうるさく、全く眠る事なく2005年7月9日午前5時41分、初めて帝都の土を踏む。既に脳ミソぷー状態。午前辺りはまともに思考が働きませんでした。
やたら寒い。東京は北海道より寒いと聞くが、本当に寒い。おまけに曇りで空が見えない。空が無い
なんて言へない状態。
その後、東京駅で迷子になりさうになつたり、皇居を少しだけ歩いたり、11月のFFT+Aに備へて町屋の下見をしたりして、ぶらぶらと山手線沿ひを彷徨ふ。
そして山手線に快速がない事に非常に驚く。各駅停車はやつぱり遅い。しかもドア閉まるのまで遅すぎ。隣で新幹線が走る。そしてエスカレータで止まる人も多い。おまけに左側に止まる。違和感だらけ。
XMLマスター ベーシックV2受験
待ち合はせの場所に、5分前ぐらゐに到着。途端、バナナを買ひ忘れた事に気付く。慌てふためき辺りを探すが、東京と言ふ街は何でも手に入りさうに見えて、存外手に入らないものも多いらしく、已む無く断念。
ボーっと待つてゐると、PaGeさんにもしかして某チャンネルの人ですか？
と声をかけられる。久樹が「某xの人です」と答へると見事にコンタクト（謎）に成功。続いて砂糖さん、哀さん、石川さんが到着。時間が際どく心配してゐたが、北村さんも無事に間に合ふ。で、何故か哀さんだけが久樹を一発で当ててしまふ。本人曰く雰囲気がドジッ子ッぽさう
……同属共感？
何はともあれ、XMLマスターV2受験。といふか、その前に狭い会場で5人もの人間が受付で写真は撮るわバナナは食ふわとひたすら迷惑な受験者と化す。受付嬢の白い目が何ともかんとも。
試験そのものの感想は以下の通り。
- 入室して手続きを終へるといきなり試験が始まる。心の準備はもつと前からしておく事
- よりにもよつて一問目からXSLT変換の問題が出され、無茶苦茶焦る
- 問題はPC画面をチェックボックス又はラジオボタンによる4〜5択選択形式。但し問題によつては資料といふ別ウインドウを開く必要がある
- 正直ユーザインターフェイスは最悪に近い。ウインドウをアクティブにする為にクリックすると、それだけで回答のチェックが入つたりする
- 問題自体はXMLSchema XSTL DTDが中心。周辺規格やXMLについての基礎知識、NameSpaceについても多少出題された
- 途中からXMLSchemaを読むのが嫌になつてくる
- あとでマークしておいた問題の再検討も出来る。が、そんな気力は残つてゐない
- 必要な情報と不要な情報を混ぜて出題されるため、問題の意図を如何に読み取るかが肝心。正直、先に選択肢を見てから問題を読み出しても良いぐらゐ
- で、肝心の久樹は、得点率84％で合格。ただ、一緒に受けた人は全員90％台で、結構悲しいかつたり。98％ッて何よ…orz
- 多少XSLTを弄つた経験のある人なら、DTDとXMLSchemaさへ勉強してれば合格出来ると思ふ。同じ結果を出す別のやり方を知つてゐるかを問ふ問題が多い
- といふか、XML歴実質数ヶ月の久樹でも合格出来るやうな試験です。ええ
と、まあ、ともあれ、全員合格出来て良かつたです。
#xsltオフ会
試験終了後、Piroさん、ろばQさん、kiyoさんとハチ公前にて合流。総勢9人、渋谷の町で昼食難民と化す。さらに、何とか入り込んだロイヤルホストにて1時間以上追加注文もなく水を飲みながら9人でだべる迷惑集団と化す。アハハハ。
改めて全員の自己紹介をした後、それぞれが各自言ひたいことを言ひたい人と喋りあひ、トピックが飛びまくる全体は誰にも把握出来ない展開に。Piroさんの魔改造品が登場したり、ふぁいあふぉっくす娘を書いて全員を萌えさせたり。その後秋葉原のメイド喫茶でまただべる。何故か注文したアイスココアが受付されてをらず、しかも追加注文したのに全然来ないといふ謎事態になつたり。
その後哀さん、Piroさん、kiyoさん、cho45さんと別れて、次はどこに行こうかと思案中。何気なく久樹が提案したカラオケが満場一致で通り、そのまま直行。
Pageさんが激しく、北村さんと石井さん
石川さんが情熱的で、ろばQさんが意外性で、ぢやあ久樹は何なのと聞かれても、ネタに走つたり真面目に歌つたりして、一人だけ一貫性を欠いてゐたやうな気がしないでもない。
1時間半歌つた後、近くの居酒屋で夕食。ろばQさんがIT業界の裏話を喋る喋る。久樹も心地好い疲労＋α（「α」が何かは問はないやうに）に乗じて、侃々諤々と意見を交はす。ただ、石川さんと北村さんが多少話題から外されてゐたやうな感じで、ちよつと申し訳なかつたです。
ともあれ、名残惜しさ200％でありながら、時間が来たので解散して東京駅に戻る。そしてバスの途中の休憩場（甲府インター）で土砂降りに巻き込まれるなどがあつたものの、6時13分、無事に神戸に着き、帝都物語の幕を下ろす。
最後に
皆様、本当に楽しい一日をありがたうございました。やつぱり一泊しとききや良かつたと今更ながらに思ひます。次の機会があれば、ブルジョワ路線で、新幹線をつかひますよ。夜行バスは、もうたくさんだ（苦笑）
今夜から帝都に逝きます
各方面の皆様、よろしくお願いいたします。
XBELでは何故名前空間が定義されてゐないのか
以前から疑問に思つてゐたのですが、何故XBELには公開識別子が定義されてゐる一方で、名前空間が定義されてゐないのでせうか。
XBELには「folder」「title」といつた、他のXML言語との衝突が容易に予想される要素名が使はれてをり、それを区別するためには名前空間を利用するしかないはずである。にもかかはらずそれを定義してゐないといふことは、XBELでは他の言語と併用される事を想定してゐないのでせうか。だとしたら、XML応用言語としてをかしい発想ではないだらうか。拡張性あつてこそのXMLであり、拡張性を殺せば、XMLとしての価値の大半を失すると言はざるを得ないと思ふ。