2002 年 6 月の日記

reicha ネタ。knu さんがようやく Perl のない 5-CURRENT に移ったとの事で、それに伴い togawa さんが ZZ ガンダム "アニメじゃない" の歌詞を変えて perlがない～，perlがない～，ほんとのこーとさ～と歌っていたので、悪ノリ。

Perl が無い

10 日分のログをチェックして、アンテナ一覧を作り直してみたり。

量が多かったので、別リソースに分けました。いつの間にこんなに……。

触らずしてアレが駄目、コレが駄目などと言える訳が無い。自分の手による十分な情報収集無く言っていても、それは単に偏見なだけだし。

私が Mozilla がダメと言っている理由は、こうした情報収集に基づくもの。もっとも、じゃあ代わりに何があるかといったら、機能的には最高だし、ユーザとして使うには Mozilla が一番いいというのも事実。

FreeBSD で使うには重過ぎるけど、Windows では十分すぎるほど軽快なので、速度的な不満は全くありません。

じゃあ、どの辺りが悪いのかと言うと、もうちょっと突っ込んだ設計思想を持って欲しかったとか、コーディング規約のきつさとか。

XPCOM 以外でのテンプレート使用禁止などは、開発効率を落とすだけだと思うのですが。

NSPR の思想も分かるけど、その上にもう一枚、Netscape Common Platform みたいな感じでプラットフォームを構築しちゃうような、そんな感じにしても良かったんじゃないかな。JavaVM みたいに。

まぁ、一番ダメなのはコードの汚さが最たるものだと思いますが。

この辺りについては、オープンになっていない IE/Opera については語る事が出来ないわけで。

ソースが公開されているものという意味では、Amaya、w3m、Lynx 辺りがあるわけですが、Amaya は Mozilla よりもさらに輪をかけてコードが汚く、まぁ、奴ら開発者じゃないしな、という辺りで諦めたくなる感じのものです。

w3m の場合は、元がビューアである、という点からあまり贅沢は言えないという気もしますが、WWW ブラウザという観点から見る場合、現行のパーサを捨てて新しく作り直さないと、今後の機能拡張を見据えた場合にはかなり辛いものがあります。

この辺りを踏まえて言っている駄目という言葉と、IE は FreeBSD には無いから駄目という言い方の駄目などは、全く別の意味を持っているわけで、その辺りは理解して欲しい心。

今度は「データベース屋」の發想としか思はれないそうで、随分と世間一般で言うデータベース屋という言葉の使い方と違うなぁ、と思ったり。

もう、これ以上は何も言う気も起きないですね。

「データベース屋」の發想、と云ふ言葉にしか反應しない邊、館長も以下略。

この様に言われているという事は、一つ一つ反応が欲しかった、ということでしょうか。

私にとっては ISO-HTML の話は今更なにを、という感じなのですが。

ISO/IEC 15445:2000が成立した歴史的經緯も全部承知してゐる。「ISO-HTML」が本質的に構造化を志向し、「フラットな構造」とは無縁である、と云ふ事くらゐ、俺は知つてゐる。でなければ、俺はaddress要素の配置問題に理窟を附けようとしなかつた筈だ。

これでは「フラットでリニアな構造」というスローガンにフラットという単語を入れた理由になっていません。

フラットな構造にはなりえないということについては 3 月 12 日の日記 / ISO-HTML ってにて述べ済みです。

當方は、「HTML文書はテキストにマーク附けする事で成立する」と云ふ大前提を根據にしてゐるから、データの話をしてゐる。當方を非難する所謂「XHTML派」は、「XHTMLの方がパーサは簡單になる」と主張する。それはパーサとかユーザエージェントとかのプログラムの話であつて、データの話ではない。

HTML の仕様では拡張性が無いが XHTML では拡張性があるため、要素に論理的な意味を割り付けて拡張する事が出来る優位点、開いたら閉じるというだけで、書いてある通りに理解するだけの XML ベースである XHTML と、暗黙的な文書構造を想定した上で記述する必要がある ISO-HTML ではより XHTML の方が、データを作成する上でも理解しやすい、ということについては 3 月 10 日の日記 / XHTML or ISO/JIS-HTML?にて述べ済みです。

さらにこれに加え、ソフトウェア的にも有利になる点も述べられているだけでしょう。

所謂「XHTML v.s. ISO-HTML」の對立は、「プログラム主體の論理 v.s. データ主體の論理」の對立なのであつて、話が噛合ふ筈がない。

今までの事から、単に今まで私が書いてきたものを読んでいないだけでしょう。

私にとっては今までの繰り返しに過ぎず、反応する理由も必要性も見受けられなかったので反応しなかったまで。

これより先の部分については敢えて反応する必要も無いでしょう。

ですから、この部分を読んだところで、私にとっては私がデータベース屋? そりゃ本当のデータベース屋に対して失礼でしょという思いしか無いだけです。

「プログラム的に駄目なら全部駄目」と斷言して欲しかつた。機能だのユーザの觀點だの――事実なる觀念だの――を持出して貰ひたくなかつた。事實と言つたら、殆どのユーザは御仕着せのInternet Explorerで十分の筈で、Mozillaを今更奬める理由は存在しなくなる。

はぁ、Internet Explorer なんて存在しない環境が当たり前で生きてますから、そんな選択肢自体存在しません。

こんな話は、Mozilla や w3m がサポートしているプラットフォームと、Microsoft Internet Explorer がサポートしているプラットフォームの差異を考えれば当たり前の事。なお、IE は Solaris/HP-UX のサポートをとっくに切っていますので、現在は Windows 系列と Mac OS 系列以外ありません。

ところで、どんなに穴を塞いでもまだどこかに空いてそうな、中の挙動がどんなに安全と言われても信じる事が出来ないような、そんなソフトを薦めるって方が変だと思いますが。

本來の姿と言はれても、それは事實の話ではなく、イデアの話になるのではないかと。あなたの目の前に存在するISO-HTML準據の文章は、事實として「フラット」な構造になつてゐるのではないですか。

目の前にある ISO HTML 適合文書ということでは、おそらく野嵜さんの HTML 文書を見るのが一番速いのでしょうけど、マークアップを見た限りでは全くフラットには見えません。

まず大見出し (h1 要素) があり、メインコンテンツのリストがあり、説明のリストがあり、俺は馬鹿だから反省しないと言う、次段の見出しがあり、その下に日付を持つ見出しと、その見出しに伴う一連の文があります。

これらの後に、文書的には俺は馬鹿だから反省しないの見出しと同レベルに他の文書へのリンクが並び、文書が終了します。

こうして見ると、h1、h2、h3、p 要素などにより見出しや本文、この他引用部といった文書構造が的確にマークアップされています。

私にはこれがフラットとはとても見えません。

まともな文書であれば見出しや段落などを見出しや意味段落などにより分割されていたりするのは当たり前の事で、これらはたとえマークアップされていなくても文書構造を持っていて、マークアップはあくまでそれらをソフトウェアに理解させるために明示させてやる過程に過ぎません。

暗黙的なものを明示する作業がマークアップであり、たとえ暗黙的であってもその文書自体には元々持っている文書構造は依然として存在しているわけで、元々の文書からして文書構造が平坦で存在しない訳ではありません。

野嵜さんの言うフラットとは、文書ツリー的に同じレベルに要素が並んでいる == フラットである、という解釈なのでしょうか。それにしても、リスト項目と文書は同レベルに存在しない (リスト項目 li は ul/ol の下に入っている) 訳で、かつ先頭にいきなりメインコンテンツのリンクが div 要素として挿入されていて、やはりこれは文書ツリーのレベルとしてもフラットには見えません。

野嵜さんの言うフラットな構造とはなんですか?

必死に修復させて解釈すると云ふ言ひ方に、それこそ意圖的な惡意を覺えるそうです。

HTML では html 要素自体、開始タグが省略可能ですが、これを存在するものとして解釈しなければなりません。暗黙的な要素足りうるのは、この他にも body 要素やなどもあります。tbody 要素は開始タグが無い場合は無いものとして見る、ですか。

当然、開始タグのみで終了タグが省略された場合にも適切に解釈する必要があります。これらを適切に修正する処理が必要となります。これが必死に修復して解釈する処理です。こうした文書は HTML Spec. を満たした適切な文書と呼ぶ事に問題はありません。野嵜さんはこの点を考慮されていますか。

XHTML は well formed XML である事が必須で、こうした省略は一切許可されません。これにより、暗黙的なマークアップは完全に排除され、パーサはあるがままに解釈するだけで良くなります。

当然のことながら、こうした処理をしなくて済む分、パーサの負担は軽くなるため、WWW ブラウザの解釈部分にかかっていた処理時間は軽減され、ユーザにとってもメリットがあります。

XHTML と XML を混ぜて話をしているのは、それを混ぜても問題が無い場合です。

なお、XHTML 1.1 や XHTML Basic では、モジュールによる要素拡張は仕様の範囲内です。従って、モジュール導入により変更された場合でも、依然として XHTML 文書として成り立ちえます。それも XHTML の利点ですから。

とりあえず誤ったレッテル貼りは止めてください。野嵜さん自身、他の人が野嵜さんにレッテル貼るの責めていた筈。

敢えて言うなら、私は仕様第一主義。それがどんな腐ったものでも、そのもの (データ形式、インタフェース等) を使う上で、仕様が存在するならそれに従う。それだけです。

その仕様に満足が行かないなら、同じ目的を満たす事が出来る他のものを探すなり、現在の仕様を変える努力をしたらいいだけ。

私が想定している環境は世間一般ではないそうで。それがどうかしましたか?

私が 6/2 Mozilla で述べているのは、なぜ私が Mozilla は駄目と言っているのかの理由であって、Mozilla を一般に薦めている言葉でもなんでもなく、単に私が駄目だと言いながらも Mozilla を使っている理由を述べているに過ぎません。

当然世間一般の人に対して言っている訳ではありませんし。そもそも Mozilla 駄目と言いつつ Mozilla を弄っている私の日記を見ている方々は *BSD Diary Links をチェックされている方々ですので。

そもそも生活環境がどっぷり Windows で Microsoft に何の疑いも持っていない、なんて人は念頭にないんですよ。日記分の referrer log を見ても、筆頭は *BSD Diary Links ですし。

というか、想定している読者層がそっち (どっち) な日記だしねぇ。

全くもって、コンパイラのせいです。

GCC3 とは言いません。gcc 2.95.x になるだけで、かなり楽になります。

想定しているプラットフォームで、このコンパイラしかない、というのであればしょうがないのですが、そうではない環境であれば、ある程度昔のコンパイラなんて切ってくれよ、と思うのですけど。Microsoft Visual C++ 1.5 とか。こんなの、もうどうでもいいじゃない。VC6 以降にしておいてくれよ。

C++ protability guide (Mozilla.org) を見て、これでザクザクとコードが書ける C++ プログラマが居たら見てみたいかも。

テンプレート使用禁止、静的コンストラクタ使用禁止、例外処理使用禁止、RTTI 使用禁止、名前空間使用禁止……これは何言語を使ってるんだ、と頭が痛くなるのですよね。テンプレート禁止が個人的には一番痛い。

C プログラマの方がまだ書けそうかと言うと、XPCOM 使ったコードの部分はガリガリに書かれているため、少なくとも COM を理解しているプログラマじゃないと無理だし。

こう書き換えたらいいよね、とか思いついても、コーディング制約で蹴られる事がままあって、正直面倒。C++ 使ってて、自分でクラス毎のリスト管理のコード書くなんて馬鹿らしすぎ。

見出し順序が出てくる順序を強制するようにしようとしたけど要素名が W3C Spec. との互換性が崩れるので、しょうがないから Pre-HTML を作ったわけで、Pre-HTML to HTML の過程の中で落とされてしまう明示的な文書構造が暗黙的になる段階で負けてると思うのは気のせいかな。

W3CのHTML 4.01に基いて話をしますと。

• リスト項目のulとolとは、HTMLの中で例外的に構造を明示するやうに定義されてゐます。
• dl/dt/ddは、dt/ddをdlで包むやうにマーク附けするやうに定義されてゐる一方、dtとddは單に並べられるやうになつてをります。
• h1からh6、p、hrは、文章の意味によつて階層構造の存在する事を暗示としますが、その暗示的な階層構造を明示しなくとも、DTDには違反しません。

全然意味がわかりませんが。

順序に意味があるリスト (orderd list/ol 要素) と順序に関係が無いリスト (unordered list/ul 要素) が例外的に構造を明示しているわけではありません。そう解釈しているとしたら、解釈が誤っているでしょう。

現行の定義リストのマークアップは、一組の dt/dd 要素を一つの dl 要素に含めたら何の問題もありません。

繰り返しになりますが、マークアップという行為はソフトウェア的に構造を明示するためのものです。暗示している段階で駄目です。

あと、hr 要素は単に水平線。なんの論理的意味も持ちません。

話題は逸れますが、現行の ol 要素は一連の項目に順序という規則性が重要である場合に利用するもので、番号が表示できれば ul 要素でいい、というのは解釈が間違っていると言えるでしょう。

たとえば料理の際の手順などをマークアップする場合には、野菜、肉、調味料などの投入順序を間違えたら、目的の料理は出来上がらないでしょう。

これに対して、食材のリストなどは、順序が変わったところで問題は無く、こうしたものは ul 要素でマークアップする事になります。

そして、以前近藤さんは、div id="diary_20010630a" class="leaf"のやうな形で「一つの記事」を記述してゐまして、それは「フラットでないHTML」と云ふ近藤さんの持説から考へれば筋が通つてゐたのですが(一方、h2とdivは平行して記述されてゐたので、不徹底の憾みはあつた)、2002年1月以降、divとh3とを平行に記述するやう、近藤さんは形式を變へてゐます。

変えていますね。それがどうかしましたか。

当初各項目毎に見出しが無かったため、たまに付けたい時に title 属性で付けていましたが、各項目毎に見出しを付けるようにしよう、正しく見出しとしてマークアップしよう、と思ったためマークアップの仕方を変更しました。

その点に関して、どういう疑問が挿し挟まる余地があるのかわかりません。

過去のものに関して変更していないのは、その必要が感じられないからです。

ついでに申し上げておくと、XHTML 1.1準據の文書としては、近藤さんのHack Or Die 2002/ 6 - Ancient libraryが目の前にあるので、參照するのに便利なので參照しますが、divでpの群をグループ化してゐるこの文書ですら、headの中はmeta/link/titleの羅列であります――と云ふ指摘は餘り意味がないやうな氣もしますが、少くとも、まともな文書はフラットではありえない @ 闇黒日記 2002/ 6/ 3と云ふh3要素と、それに引續く本來の姿と言はれてもと云ふ引用から始まる一聯の段落群とは、單に並んでゐるに過ぎません。

head 要素の中には文書のメタ情報や連結情報などのプロパティが入っていますから、それが head 要素によってグループ化されているだけでしょう。

単純に XHTML 1.1 Spec. 準拠で拡張していないだけですから、metagroup 要素や linkgroup 要素などは存在しないわけで、その点に問題があるとは思えませんが。

まともな文書というのは、一部の文章を言っているわけではなく、一つのファイル、もしくは一連のファイルから成り立ちます。そのツリー構成の一部だけを取り上げてフラットでしょ、というのは、#PCDATA 部分の数文字を取り上げてツリー構造を構成していないじゃないか、と言っているのと一緒。

文書構造的に同グループに属する要素が同列に存在するのは当たり前の話です。

モジュールの追加は DTD で書くのは面倒なので、元を XML Schema にしてくれると良いのだけど。XML Schema の方が読みにくそうですが。;)

近藤さんは3月に、以下のやうに書いてをられます。

複雑な HTML をまともに解釈できない手抜きパーサや適切な HTML を出力できない手抜きオーサリングツールによって生成された腐った HTML を必死に修復させて解釈するよりも、XML ベースでソフトウェア的に完全に一定のルールで出力させることで、HTML を何らかの形で処理する場合に、あらゆるソフトで容易になるという大きな利点を考えないのはどうかと思われます。

この文章を見れば、「DTDから見て妥當でない贋のHTML文書」(所謂「謎文書」)について近藤さんが書いてゐる事は、自明であります。

あぁ、そうですね。

でも、訂正する必要は無いですね。2002 年 6 月 3 日 まともな文書はフラットではありえないで書いた通り、パーサの仕事は XML アプリケーションに比べ、SGML アプリケーションでは増大します。

明示する事がマークアップの本来の目的である以上、暗黙的なマークアップを許容する必要などは無いわけですから 6 月 3 日に書いた通りの文書に反応していただければ十分です。

それから、しつこく申し上げますが、XHTML準據だからその文書は良いデータである、と決め附ける譯にはいきません。見出しであるべき文字列をtableで裝飾し、Navigator系のブラウザで適當なレンダリングのなされるやうに全體をやはりtableでレイアウトしてゐるやうな、CSS的に見ればレガシーな種類の文書でも、HTML 4.01 Transitionalとして正當とされる事はありますし、XHTML 1.0 Transitionalとしてもやはり正當とされる事はあり得ます。

特定のデータ形式に沿っていれば良いデータという事はありません。

誕生日に、常に問い合わせをした日付が帰ってくるようなデータは良いデータとは言えるわけが無いですから。

良い文書というのは、その文書の内容自体で判断されるべきです。

しかし、良いデータというのは、HTML に置いては、文書がもっている情報を適切に明示しているものを指します。これは紛れも無い事実です。

この点において、HTML 4/XHTML 1.0 では不足の点も多いですが、class 属性の利用によってある程度の幅が出てきます。XHTML 1.1/XHTML Basic などでは、足りなかったらそもそも拡張したらいい、という話になります。

しかし、繰り返しになりますが、ISO-HTML の場合には見出し順序を強制するために暗黙的な論理構造が発生します。この点において、Pre-HTML でない ISO-HTML には致命的な欠点が存在する事となります。

Pre-HTML であれば、この問題点は解消しますから、何の問題もないかと思いますが。

というのが今までに言っている事。ISO-HTML は Pre-HTML で無くなった段階でマークアップ言語としては失敗していると思われます。なにせ、UA に特別な負担を強いなければならない構造になっているのですから。暗黙的な div[1-6] の検出をソフトウェア側で対処しなければならない時点で駄目。

視覺系のUser Agentは、XHTML文書にしろHTML文書にしろ、取敢ず文書を頭から讀込んで、最後まで全部讀み通します。HTML文書がリニアな構造である所以です。現行のNavigatorもInternet Explorerも、HTML文書を扱ふ場合、頭から順にタグの記述を見て單純にキャンバスに並べてゐるやうです。例外は、推測ですが、Operaで、こいつはXML文書を眞面目にパースしてゐるやうです。所謂「日本語」非對應の時代に「日本語」のXML文書を喰はせたら、解釋出來ないとエラーを出して呉れたんで、さう推測するんですが。

application/xhtml+xml な文書を食わせた場合の IE は XML 文書としてパースしていた筈。application/xhtml+xml を返すようにしたにゃおりんの回顧録が、IE に食わせるといきなりパースエラーを出していたのは記憶に新しいところです。

Mozilla の場合は XHTML だと判断 (DOCTYPE で XHTML と認識とか) されると、そのまま XML モード直行です。この辺りはソースにコメントで書いてあったと記憶しています。

XML 解釈モードに入れずに解釈させている場合には、単にパースエラーを出さずに自動修正機能を有効にして解釈しているだけでしょう。

Opera が XML をまともに解釈しているとしたら、未知の要素にも反応するなどの機能が必要だったりするかと思いますがどうなんでしょうね。

認識するのであれば、W3C 内部で XHTML 2.0 の策定用テストスートとして利用されても不思議ではないと思うのですが。

なお、Shift-JIS の文書であれば、2 バイト目に &、<、> などと同じコードを持つ漢字が出てくる場合などがありますから、日本語非対応時代にパースエラーが出ていた場合、単にこれによって解釈に失敗していた可能性は否めません。

敢へて言ふなら、私は仕樣第一主義。但し、データの作成に都合が良ければ。パーサやら現實のユーザエージェントやらは知りません。仕樣があつて公開されてゐるんだから、パーサやらユーザエージェントやらはそれに從へば良い。

UA は対応したければ対応したらいいだけの話で、需要がなければ対応する必要も無いのですが。

W3C HTML に加えて ISO/JIS HTML に別途対応する必要があるかと言うと、ISO-HTML の仕様に沿って、暗黙的な論理構造をわざわざ解釈する位なら、すっぱり切り捨てて XHTML 1.1/XHTML Basic に対応したほうが楽な事は確か。まともな XML パーサを載せれば終わりですし。

ISO-HTMLがいかに駄目な仕樣かを力説されても、仕樣としてあるものは仕方がない。XMLの觀點から見て、どれ程「面妖」な制約が附いてゐようとも、その制約下でデータを作成して何が惡いんですか。ISO/IEC 15445:2000の制約に挑戰する(と言ふよりは、その制約下で出來るオーサリングの限界に挑戰する)のは、パズルみたいで面白い。

それだけです。

であれば、他人の評価結果が正当に低く評価されていたとしても、気にせず淡々と使ったらよろしいかと。

繰り返しになりますが、野嵜さんの言うフラットな構造ってなんですか。

Mozillaの件に關しては、何と言ふか、想定している読者層と言つてゐる時點で話にならねえなと思ひました。

對象を限定したければ勝手にすればよろしいのですが、全世界に公開したリソースで、あらゆる種類の讀者に語つてゐるかのやうな調子で、實は特定の讀者をターゲットに、極めて限定された條件下での話をするのは、よろしくないのではないですか。

正字正かなを読解できるという特定の讀者をターゲットに、極めて限定された條件下での話をするのは問題があるのでしょうか。問題が無いのだとしたら、もっと広い相手を対象としている話に問題がある訳が無く。

そもそも誰も読まないような本だって、自費出版で不特定多数に対して販売する事に問題があるわけも無いし、他人が作成するリソースが自分の目的に合っていないから、と文句を付けるのも変な話。

了解。

既に「付き合いいいねぇ」と呆れられたりしてたり。私も時間の無駄でしかないので、もう終了。

忘れないうちに。jus 第 98 回勉強会: Mozilla についてのアナウンスが出ています。

第 99 回、第 100 回講師の方々との、所属のギャップが……。ま、いいけど。

えーと、CBUG の方は今度勉強会やるときにでも、多少内容を変えて (追加して) できれば、と思っています。

2 時間弱話せるくらいの資料が間に合うといいけど～(汗)。

えぇい、波田野さん告知しすぎじゃあ。そんなに告知しまくらなくても良いわぁ。

くぅ、何処からか (何処) の圧力、の仕返しだなぁ……。

箱から煙草を一本取り出してもう喫う気満々の人に「いいかな」なんて訊かれたら、断り辛くてしょうがない。そもそも、断ってくれればまだいいほうだし。僕の同級生達は、先輩達は、名も知らぬアカの他人の喫煙者諸氏は、さて、素直に煙草を引っ込めてくれるでしょうか。逆に根性焼きを入れられたりして。

名も知らぬ赤の他人はともかく、同級生や先輩諸氏にはそれこそ伝えておくべきでは。

会う頻度が高い人に程、自分がタバコに弱いということを伝えておくべき。まともな人なら、座る場所から考えてくれますし、控えたり、少なくとも煙を吐く向きを多少考えたりしてくれるでしょう。

しかし、居酒屋なんかでは、なんであんなに煙が嫌いな人の方向に、狙ったように煙が流れていきますかね。

喫煙者はタバコが有害である事、副流煙によって他人を傷つけている事を認識していますので、可能なのであれば、副流煙を他人に吸わせずに済むのであれば、それが最良である事を認識しています。認識していないタコはタバコを吸う資格などありません。

自分がタバコに弱いことを伝えただけで壊れる人間関係だったら、多分壊したほうが幸せです。

Mozilla 1.0 Release 出ちゃいましたね。

勉強会に間に合うとは思わなかったなぁ。

数日前から Ragnarok Online を始めてみたり。Ultima Online と違ってまったりしてますねぇ。

とりあえず、普通にやってると物価が結構高いな……とか思いながら、魔術師でやってます。IRC では「茨の道を ;)」と言われてちと悲しかったり。

とりあえず、Mozilla の資料作り終わるまで封印したほうがいいかも。(^^;

その後は Mozilla の IPv6 化が終わるまで、やろか。うぅ。

リクエスト (何) があったので、とりあえず Web technologies cultist group のリンク集を作ってみました。

XML + XSL = ウマーというデータにしたので、メンテは楽っぽい感じ。追加とかは、Web をあまり歩き回らない私には辛いかも。ということで、リクエストよろしく。> 該当者 (誰)

関連スレ (何) は #某方面周辺:*.jp @ IRCnet とか、W3C メーリングリストということで。

ADSL 回線不調スギ。工事の連絡など来てませんよ?

ここ 24 時間で 6 回落ちって多過ぎですよ。しっかりせいっ。

明大ならともかく、名大じゃ無理っす。

ってことで、行きません。

先日 mergemaster の際にミスって、Majordomo がまともに動いていなかったことが判明。復旧しました。

道理で、mozilla@alib.jp に流したアナウンスが流れてこないわけだ。

なんか要請されちゃってるみたいなので作りました。所要時間80分強……いちおう全身作ってあるですよ。あと Web 技術信者集団への参加の意志を表明。

ありがとうございました。感謝感激。

バナーは alt text に惹かれて適当に選択しましたが、あれでよかったのでしょうか。(汗)

w3m で見ていたので、図柄はチェックしていません。

うちの「レナ姫のWeb研究室」みたいに、同じWeb技術とは言え、W3Cの潮流とはややかけ離れた仕様を扱っているサイトは、どのような扱いをされるのでしょうか？

Web 技術ですから。CGI、WebDAV、SOAP なんかもアリだと思ってます。

ところで、バナーと思わしき画像が 200 × 41 pixels だったので、他の画像とサイズがずれるので設定していません。何か理由があっての事なのでしょうか? ^^; > 高さ 41 ピクセル

項目を追加したりとか、経典へのリンクをすっきりさせたりとか、ふにふに。

XSLT Spec. 邦訳版が消されていて、思わず「これだから企業サイトは……」などと思ってみたり。

Mozilla 勉強会資料作らなきゃ……と思いつつ、どんどん部屋が綺麗になったり。危険な兆候。

Sylpheed 0.7.7 リリース!

ついに POP3/IMAP4 の TLS 対応が入り、NNTP over SSL も実装され、Sylpheed からの通信は全て暗号化可能に。

従来でも POP3/SSL と IMAP4/SSL は実装されていたものの、これでようやく TLS 対応になったので、設定をデフォルトポートのままにしておけます。

良かった～。

古林さんの作成された XHTML Primary では、確かに見出し順序の規則化は行われていると思います。

しかし、私には要素の出現順序の強制は行われていても、そこに階層構造が定義されているようには見えません。

XML 文書の場合、well formed で解釈される事もある、というか、それが利点の一つであるため、この場合には順序の妥当性は当然保証されませんし、スキーマによって提供される情報も失われるため、例えスキーマによって構造に対しての情報が提供されていたとしても XML パーサが well formed な解釈しかしなかった場合には、スキーマから提供されるべき構造情報は失われてしまい、その結果、ISO Pre-HTML で表現される暗黙的な div[1-6] 要素の範囲は XML パーサに伝わらなくなります。

XML 文書としては、この点は致命的な欠点ではないでしょうか。

XML 文書として記述するのであれば、それこそ div[1-6] 要素をそのまま記述し、XSL 変換によって ISO-HTML へ持っていく方が良いように思えます。もちろん、XML を解釈するソフトウェアに対してはオリジナルの div[1-6] 要素を含んだ XML 文書を渡す事で、明確な構造情報を渡せます。

XHTML Primary は XML 文書なのですから、どうせならその方向で作ったほうが良いように思えます。

XML 文書がスキーマを常に要求してしまっては、XML の求めた方向性から考えると、逸れてしまっている様に思います。

DTD が圧倒的に表現性能が低いのは周知の事実な訳で、個人的には XML Schema との比較もして欲しかったかも。

XML Schema については結構期待しているのですが、時間が取れなくて把握しきっていません。

既に実装系が存在しているので、現段階でもある程度利用は可能だと思っていますが……。

日これにあったリンクより、女子高生のカーネル領域における言語的透過性。うはは、おもしれ～。

#alib にねぎ支障来襲。

参加者の傾向が非常に混沌としていて、全くもって訳のわからんチャンネル化している辺り、なんとも。

MSX の話題とかで盛り上がってしまう辺り、近い年代の人が多いなぁ、と思ったり。

任意の要素を自由に指定する。その為の XPath とか思いました。

まぁ、p 要素に id 振る、でもいいのですが。h[1-6] 要素に id の方が素直だとは思いますが。

分かりやすい説明が。うーむ、ダメですね、XML Schema (笑)。

キーボードがどうの、xkanon がどーの話してみる。

今野さん、ports 突っ込みませんか?(笑)

XML in Mozilla: Other Supported XML W3C Recommendations and other specifications and related technologies explained elsewhere 辺りを見ると、既に Mozilla/Netscape 7 では実装済みですね。

ということで、UA は既にありますよ (笑)。

しかし、ぷろじぇくと、みすじら。読んでると RO やりたくなってしまう。危険危険。

#alib で、基本的なコーディング規則についての話で盛り上がる。こういうコードだとどうよ? とか、インクリメント書く場合ってどうするよ、とか。

なんだかんだ言っても、結局みんな同じようなルールだったり、似たような感覚だったり。

ある程度コード書いてると、みんな同じような経験をして、同じような結論に達するものなんだな、と再認識。

しかし、libc に retrun とか言う関数突っ込んで、しかも main を呼ぶ、とか言うのはさすがに鬼だと思います～。> 今野さん

結論は n=n++;、これ最凶なのは言うまでもなく。

djb 教にも通じるけど、Simple is best の言葉に尽きるのよね。

コンピュータ屋つて、何でコンピュータに樂をさせる事ばかり考へるんですかね。

コンピュータ屋というより，プログラマではないでしょうか。コンピュータに楽させると言うより，コーディングで楽したがるだけですが。

仕事で付合いのあるSEさんはそんなことないですよ。できるだけ人の労力を減らそうとします。

以前，打ち合わせにプログラマさんが同席した際，「元データにはこれこれこういう情報を完備してないと困る」，とプログラマさんが言ったところ，「そんなの機械的に判断出来るんだから，プログラムでフラグ付加すればいいでしょ」とたしなめられていました。

単体プログラムしか見てないプログラマはともかく，システム全体を見ているSEとかは，ちゃんと考えているンじゃないですかね。

必要なデータが完備されてなかったら、そりゃどうやっても困るのではないでしょうか。機械的に判断できる、の範囲に依ると思いますので、状況によってその言葉の意味は変わると思います。SE が把握していない範囲のデータが必要だったのかもしれませんし、単に機械的に算出できる範囲だったのかもしれません。

機械的に算出できる、の範囲がデータから何度も繰り返し計算すると 1 レコードに対する計算量が 10 分程度で、毎日 500 件程度回さなくてはならず、毎回計算するにはあまりにも負荷が高い、など、場合によっても変化します。

まともなプログラマは負荷を掛けなくてもいい場所に負荷を掛けたりしない筈ですから、一概に言い切れる話じゃないです。

とてもじゃないけど、現状の実装では使いにくくてたまらないと思います。

XML 文書ツリーをドラッグ & ドロップで自動的に埋め込んでくれる様な、そんなオーサリングツールでもないと、使う気はしないでしょう。

ちなみに、w3m-m17n で見ようとしたら Not Acceptable。がーん (笑)。

そういや、application/xhtml+xml 受け付ける設定になってないか。

w3m でも xhtml+xml を正しくパースしてくれるようにしたいなぁ。BSD ライセンスな XML パーサじゃないと w3m には入れたくないし。

なんか意図していない方向に解釈された様な。書き方が悪かったかな。

作業用データを保存しなくても毎回計算できるだろ、というのは場合によるよね、とか、そういう感じです。

ところで，必要なデータがなくてもできる機械的判断って？って、何です?

どうせ組み込み用の資料も書くなら、やっぱサンプルコードも付けたいよね、ということで、GTK を使ったサンプルコードを書いてみる。

……あの、簡単とか言う世界を超えてませんか。すっげー、楽。

Mozilla のプロファイルをテスト用のプロファイルディレクトリにコピーし、そのディレクトリをプロファイルディレクトリとして指定。シンボリックリンクでも良かったかな。

後はコードをビルドして、実行して、ウィンドウマネージャに全画面表示 + 最前列表示を覚えさせる。

おおっ、これでプレゼン用ソフトが出来上がりましたよ?(笑)

気合入れて XHTML 1.1 + CSS + JavaScript で書くと、本当にプレゼンソフト作れそうな気がしてくるな、これは。

ちなみに、書いたコードはたかだか 746byte で、実行バイナリは 6662byte。こんな程度で表示するだけの最小限のものならできてしまいました。

この程度なら、誰でも書けますね (笑)。

今考えているのは、サイト管理情報を一つ XML データで作ってしまうことなんてどうかな、と考えています。

そこで書かれた文書の構造情報を元に、該当文書のサイトナビゲーション情報を埋め込むと共に、サイトマップも作成できる感じです。

ant 辺りと相性良さそうな気もするけど、どうでしょうね。

ant/make 一発で、サイト全体の更新し直しもできる、と。

CVS で commit するタイミングで自動的にこれもできるといいかなぁ、と考えているのですが、どうやったらうまく処理できるんだろう。

Mozilla の勉強会資料作成も一応終わったし、RO も少しやって剣士 httpd (なんつー名前だ……ちなみに魔術師は inetd) が Lv.26 まで行ったので、とりあえず Mozilla 弄りに戻ってみる。

勉強会ではどう話すかとかのシナリオ考えてないけど、まぁ、その場のノリで。

PR_GetHostBy* を使っている場所を grep -iR で抜き出していて、XPInstall 内で gethostbyname とか見つけて、「そういえば XPInstall は NSPR 使わない単体モジュールだったな」という事を思い出したので、とりあえずここだけ先にやってしまおう、と思い立ってソースを開く。

ん～……あの～、IPv4 しか想定していないこのコードは何ですか? 何故に AF_INET しか考えてませんか。

sprintf(cmd, "PASV\r\n"); ……万歳。ぐれいと。なんだ、XPInstall って、他のモジュールと違って思いっきり書き換える必要があるんじゃないか。がっくし。

とりあえず、参考資料とかメモ。ソースのパスについては基本的に FreeBSD。

要は、XPInstall 書いた奴出てこい! って感じ。

XPInstall 辺りを見ていてまた発見。mozilla/xpinstall/wizard/libxpnet/src/nsFTPConn.cpp の 98 行目辺り。

    /* issue USER command on control connection */
    err = IssueCmd("USER anonymous\r\n", resp, kRespBufSize, mCntlSock);

    /* issue PASS command on control connection */
    ERR_CHECK(IssueCmd("PASS -linux@installer.sbg\r\n", resp, kRespBufSize, mCntlSock));

わーい、またかよ。

参考に lib/libfetch/ftp.c 見てると、こっちは (当然ながら) しっかりやってる。

そりゃユーザ名取得したりとかしてるとその分コード増えるけどさ。でも、そういうもんじゃないでしょ。

ユーザ名取るとか、ホスト名取るとかが Windows でほげ、とか言うなら、それこそそういう部分こそが NSPR で吸収されるもんじゃないのかな。

俺達には Valid な e-mail アドレスが必要なんだ、じゃないよ、まったく。

あー、libfetch をそのまま使いたくなっちゃいますよ、これ (苦笑)。

社内イントラのスケジュール管理ツールのところに、火曜日 15:30 から全員がサッカー観戦のスケジュールが設定されてた。ふざけんな。

見たかったら録画するなり、会社休むなりしたらいいだろうが。

そもそもスケジュールに入れるにしても、自分だけとか、明らかに見たがる人間だけにしときゃいいだろうに。

なんで見る気が欠片も無いどころか、嫌がってる人間まで入れるかな。

日本がさっさと負けてくれたらこういうアホな事されずに済むのかな、と思うと、さっさと負けてくれと心の奥底から思いたくなる。はぁ。

丁度社長と話すタイミングがあったので、その時にちゃんと直接言ってあります。ですから、社長がなぜそのような判断をしたのかも理解していますし、その点では納得しています。

スケジュールの割り当てに関しては、それが何の確認も無しに入れられた事を責めているわけではありません。その点は理解して欲しいところです。

それをさせてしまう様な熱狂的な雰囲気を作り出したり、そういった行為が普通に許されてしまうようなワールドカップとかのイベントが嫌なのです。

興味がないだけで帰れだの死ねだの言われるような、そんな事が許されるようなものが嫌なだけなので。

失敗。やっぱり先にシナリオをきっちり考えておくべきだった。

でも、これで次にどうしたらいいかはちょっと掴めたかな。

一応、Mozilla のどの辺りが良くて、どの辺りが悪いのかという最低ラインは説明できたからいいとしようかな。

でも、ソースコードを覗くと匂い立つように感じられる Mozilla のコーディングに対するポリシーの汚さが説明できなかったのは残念。

anonymous FTP のパスワードをハードコーティングするなよう。適当に自動生成しろよぅ。

やっぱ再戦は CBUG 勉強会、かな。

朝 7 時まで仕事して、起きてから会社行って仕事して～。

なーんにも無い日。

Apache 1.3.26 + IPv6 に入れ替えたりとか、その程度しか今日は何もしてないような。

ちっと Java 環境も整えないとね、という事で入れてみたのが Xalan-J。試してみたところ、xsltproc では出てこなかった XSL スタイルシートの問題が……いやぁ、やっぱまともなものを使わないと駄目ってことかな。

というよりも、手抜きをせずにしっかり仕様通り書けって事ですか。

とりあえず Xalan でも通るように日記用 XSL スタイルシートを書き換えてみたものの、採用は見送り。

現在 Perl + xsltproc で自動化している処理を完全に Java に置き換えるまではこのままにしておくつもり。

Java のお勉強がてら、もちっとまともな日記管理用のコード書こう。

しかし、JDBC 使ってデータベースに落としたほうが何かと便利かも。うむむ…… Relaxer 使って (略) が一番良いかも。

延び延びになっていた会社の健康診断が今日ようやく。

なんか結局、一日中狸森の廃教会前でだべってるだけだった様な感じに……。

回避が低い上にレベルがまだまだ低い状態で壁になっていたので芋やポーションをほとんど使いきってしまっている辺りがちょっと悲しかったですが。

でも、アイテムクリアの前に装備品、特にアクセサリ関係が高騰してしまい、プロンテラの街中では商人からは 140,000z 程度でやり取りされているグローブが 80,000z で入手できたのでラッキーではあったかも。

家に帰ってからずっと昨日と同じ場所でだべり……いかん、これはいかんっ。

せめて Mozilla でも弄りながらやろう (いや、それも間違い)。

ちなみに、だべってる内容はゲーム中の話とかばかりです。結婚式イベント見に行こうね～、とか、○○さんは女好きだ～、とか。

通勤時にゆっくり読んでいた奇貨居くべし、をようやく読了。

やはり宮城谷昌光さんの作品は期待を裏切らない出来で良い。色々と考えさせられる点がありました。やっぱり地道に一歩一歩やらんとね。

千里の道も一歩から。ローマは一日にしてならず。当たり前の事だけど。

すごく後ろ向きな気分になりながらの OpenSSH 祭り。なんだかな。

Linux 2.4.x 系で導入された netfilter のお勉強。

とりあえず、管理を簡単にするためのコードを書かないと～。

前に ipfw でどーよ、という話 (謎) はありましたが、今回は netfilter/iptables で。

これはこれでおもしろそうかな。ipchain の後継である現在の実装を知ることができる、という感じで。知っておくことに越したことはないし。

今日は BELL"Z のライブ～という事で、仕事が終わってから速攻で渋谷に移動。

到着してみても誰も来ていないみたいで、とりあえず五反田さんに連絡を取ってみると秋葉原との事。あの～、開場 5 分前なんですが～ (汗)。

やあ 3 と太田さんと合流すると、現場でチケットを買っているにら～んさんも一緒に居ました。

ライブは……あ～、ネタ最高。というか、やばい (笑)。

カップ麺はちと……きついでしょ、2 つ一気食いは。(^^;

終わってからは五反田さんとも合流して居酒屋で飲み。うま～。

あの金額であの内容は安すぎ。

今日は RO 内で結婚式イベントがあったので参加してみました。

途中で割り込みプロポーズが入ったり、じゃあ、と W 結婚式に入ろうとした途端新郎新婦 4 人が落ちたりと大騒ぎ。結婚式の直後にいきなり新郎 1 人が死亡。そのまま RO 引退という忙しい流れ。

それなりに楽しかったかな。

一緒に行った女アコさんがブーケ拾ってたけど、誰と結婚するのかな～。

1 日頑張ってみた。100,000z 稼げた。

なるほど、今のレートだとグローブくらいは 1 日で買えるのね。

週末頑張れば、ネックレスとかも買える気がする。