XML ベースのファイルフォーマットに移行することで、Officeで作成される多くのファイルは、サイズが小さくなり、また壊れにくくなると、Microsoftでは説明している。
XML は一般的に冗長度が非常に高い file format なのでXML ベースのファイルフォーマットに移行することで
、サイズが小さく
成ると言うのにはちょっと驚いた (本当に application/xml
な (
として読める) XML では余りに冗長度が高いので、実際のところは OpenOffice の様に application/xml を圧縮した file になったり、或いは XML Binary の一種になると思うのですが (憶測))。plain/texttext/plain
次期 MS-Office が XML を採用する事も、次期 MS-Office の data file size が小さくなる事も別段驚きではないが、XML file に移行する事で file size が小さくなるとはどうしても思えない。正しくはXML ペースの file format に移行すると同時に現在のデータ形式を見直した結果 size が小さくなるのではないかと思うがどうなのだろうか。
まず最初に。勘違いしている人が多そうなので改めて (参考: 2001年03月17日のろばQ日記)、この種の baton も chain mail と同じように人から人へ伝播しますが、chain mail とは (chain mail が嫌忌される理由となっているリソースの消費の仕方が) 明らかに違います (それはそれとして新たに baton 形式の質問をマナー違反にしたい、と言うのは個人の勝手なのでご自由に……)。
で、chainmail では無いのですがそれはそれとしてろばQはこの baton 系の質問がどうしても好きになれません。一言で言えば質問者が質問を投げっぱなしで、解答する価値がないと言う事 (特に集計などしないなら回答者がそれぞれ自分の言いたい事に合わせた書式で書けば良い。因みに、これは多くの n 個の質問にも言える)。
まぁ、それはそれで、質問するのは質問者の勝手だし、その上で回答するのも回答者の勝手なんですが、例えばバトンを渡してきた相手を明記する書式にする (リレー形式なんだから辿りたくなるのが人情という物)、回答をもう少し定形で答えるような形にし、機械的に集計し易くする (そして実際に集計する)、など質問が伝播したり、せっかくかなりの数の回答が集まったりする訳なので、最初の出題者はそれを活用する事を念頭に置いていただきたい所。
なお、Musical baton に関しては、真琴さんによる Musical Baton の泥臭いまとめ が出来、さらに神崎先生が Musical Baton記述のスキーマを作った為、前述のろばQの不満の半分は概ね解消 (って言うか神崎先生は凄いなぁ)。
と、難癖を付けてみたが、最終的にはなかまはずれの国
の風野先生が我々しゃにかまえる国の人の心情をも見事に言い表して下さっているので引用させて頂きます。
こういうときになかまはずれの国の住人がとる態度は決まっている。仲間に入れてもらってうれしい、という顔をしないことを心がけ、面倒だけど仕方ない、仲間に入ってやるか、というそぶりをつくろうのである。というわけで、私もそういう態度で答える。
というわけで、私もそう言う態度で答える
。
で、長すぎる前置きは兎に角として (散々言っておいてそれか > 拙者) 哀さんの Musical Baton でご指名を頂いたので Musical Baton に答えてみる。
4900 曲弱、総演奏時間 10.8日 (但し、ドラマや落語、講談などを含む)。
特になし。
新旧問わずその場の気分で聞く。最近は iTunes で全曲を shuffle 再生。
なお、鋼の錬金術師 COMPLETEは CCCD (CD ではない) ので厳密には該当せず。
歌や音楽がない生活と言うのは考えられませんが、特に思い入れのある歌や曲は無し。
その上で無理やり選ぶと以下の5曲。
君が代は、ろばQの国の国歌だから。仮に日本の国歌が変わったり、ろばQが他国民になっりした場合入れ替わります。
特に渡したい (この質問集に答えて欲しい) 相手も居ないのでこの場で募集。
まぁ、答えたい人は baton が有ろうが無かろうが勝手に答えればいいのですが、baton の体裁を整えたい方は連絡を下さればろばQが改めて指名させて頂きます。
Musical baton の Musical を単純に Videogame に置き換えただけの Videogame baton も哀さんの Videogame Baton でご指名を頂いて回ってまいりましたので答えてみます。
Musical baton 以上にネタ baton なので (参照: ゲームで渡す、VIDEOGAME BATON。最初の設問者自身が単純に置き換えただけの設問に対して文句を付けている)、空気を読まずにマジレスを。
この baton は Video game (所謂テレビを画像の出力装置としたゲーム) の質問ちゃうんか、と早速空気を読まずにマジレスしてみる。
それはそれとして PC に install している computer game のは 10 title 程 (computer には PS2 も含めた)。
ちなみに、video game の volume をろばQは title 単位で数えましたが、一般的にはどう数えるんでしょうか。また、仮に title 単位の場合、5 in one みたいなゲーム (例えばナムコミュージアム) や新作リメイクにオリジナルモードを収録した場合とか (例えばスターブレイドα)、果たしてどのように数えるのか気になる所。
あ、パッケージ単位で数えればいいのか。
思い入れのあるゲームが多く、どうにも 5 つには収まらないが、無理やり選んでみる。
選べませんでした (しかし、まだまだ色々忘れている気がする……)。
先日行われた日韓首脳会談の時、日韓併合は合法だったか、と言う話が出た。その時ろばQは詳しくないなりに合法だったと聞いていると主張し、相手も詳しくないなりに合法かどうかは解からないが日韓併合が正しかったとは思えないと主張した。
それはそれで良いのだが、相手方は続けて日韓併合が正しくなかったと思うので合法ではなかったと解釈するべきだと言い始めた。いやそのりくつはおかしい。
日韓併合は合法だったかどうかは、当然ながら当時の法の解釈やら運用やら手続きやらに照らして判断されるべき事であって、論者が日韓併合を肯定 (否定) したいかどうかと言うのは関係がない。件の話は日韓首脳会談に併せてより広範な日韓関係についての話題の中で出たものだったので単純に合法性 (違法性) の判断のみに拘るべきではないかも知れないが、だとしても合法であっても日韓併合は肯定できないと主張すべきである。
何か感情的に肯定 (否定) したい、納得したい (できない) と言う場合、下手な理屈をつけて相手を説得しようとすべきではない。その理屈がたまたま物事の本質を突いていたり、或いは相手がそれで納得してくれれば良いが、そうでない場合理屈の不備を指摘されたり、示した利点や欠点を否定されると納得せざるを得なくなる。その後に及んで (自分が理屈で云々主張しておきながら) 理屈の上ではそうだが感情的に納得できないなどと言い出そうものなら只の我が侭以外のなにものでもないのだから、だったら最初から私はそれが好きなんだ (嫌いなんだ) と情に訴えた方がまだ増しである。少なくとも論破はされる事がない (不戦敗にはなるが)。
蛇足と成るが、ろばQは何かを肯定 (否定) したい感情に理屈をつけるべきではないとは主張していないし、過去に主張した覚えもない。
2001年の秋からInternet Draftとして検討されてきた Scripting Media Types が、ようやくInformational RFC になるとアナウンスされた
(スクリプトの MIME タイプが RFC となって公式登録へ) との事で、本 site も本日付けで対応 (フライングスタート)。
具体的には拡張子 js
を text/javascript
、es
を application/ecmascript
として配信するように設定し、前者を過去の UA での動作を希望する場合に用い、後者を厳格な解釈を希望する場合に用いる事に。但し、text/javascript
は obsolete との事なので将来的には拡張子 js
を application/javascript
に変更するか、或いは全面的に application/ecmascript
への移行を検討中。
因みに、2005年06月29日現在 script が動かないと閲覧そのものが困難に成るような 文書はありませんので (動くと便利だと思って仕込んではいるのですが、実際閲覧者にとって便利かどうかも怪しい所)、ろばQ個人としては仕様に厳格なMIME 型を適用した結果 script が動かないなら動かないでまぁいいか、と言う感じ。