サイトのRSSを公開してはや9ヶ月。その利用状況はどのようになっているのだろうと思い、RSSファイルに対するアクセス解析をすることにした。
わはははは。夏休み特別企画ということで、自作自演対談を実現したぞ（￣△￣；。聞き手は、1年前のおいら（以下「2002」）。おいらの何もかもお見通しの「2002」は、いったいどんな話を引き出してくれるのやら。心配ですなぁ（￣△￣；。
2002 おばんです。いやー「グランド・ウェブ！ ファンキー ヘタレ・ロード」が1年以上も続いてるなんて驚いたね。
（￣△￣； 更新は相変わらずボチボチだけどねぇ（￣△￣；。
2002 最近何やってるの？ グランド・ウェブのサイトは随分発展しているみたいだね。
（￣△￣； 「スカンクワークス」と「グランド・ウェブ！ ファンキー 井戸端会議」（以下「井戸端会議」）つー、2つのコンテンツを持ってる。一応自分の中で微妙に性格付けをしているんだ。
2002 へー。
（￣△￣； 「井戸端会議」はそれほどこの界隈【どこ】に詳しくなくても、それなりにウェブの動向やトピックを楽しめる。「スカンクワークス」はもうちょっとコアな話題かな。
2002 読んでる人ってどちらも同じ人かい？
（￣△￣； 微妙に違う予感がする。「さとみかん」で括られている人たちは「スカンクワークス」に反応しているっぽいし、Blog指向のある人たちや、さとみかん方面の中でもはてなにコンテンツを持っている人はどちらかと言うと「井戸端会議」のネタに反応するねぇ。
2002 さとみかん方面の人以外で反応をくれている人のサイトって見てる？
（￣△￣； FOAFやり始めてから外の世界を見てみる必要性を感じ始めて、はてなあんてなにアカウントをとってみた。反応をくれてるサイトを「ヘタレアンテナ（￣△￣；」に登録して巡回するようにしたんだ。違う世界を見てるようで楽しいな。
2002 登録しているサイトは、どの方面？ 去年はUNIXやLinuxユーザーの日記サイトをよく見てたようだけど。
（￣△￣； 本当はセマンティックウェブ方面の日記とか情報源を追加したいんだが、日本語で読めるサイトが少ないような気がするんだ。おいらのアンテナだとKotaさんの「vanguard」と「RNA」というRSSアンテナを配付している「semblog.org」くらいだよ。今は主にモジラ関係やネットウォッチをしている人、スラドで見かけた人のサイトが中心。
2002 海外のサイトも登録されているけど、英語は超苦手じゃなかったっけ。
（￣△￣； あ、相変わらず苦手なんだな。海外のサイトは「RDFweb」というFOAFプロジェクトのサイトがひとつ。あとIanという人のblog「Hixie's Natural Log」を捕捉してる。この人は昔モジラ関係の開発をしていて、最近オペラソフトウェアに入ったCSSの達人らしいんだ。
2002 海外のblogはどう？
（￣△￣； うーん、それほど多く見てるわけじゃないから雰囲気がよく判らない。最初、海外版CSSコミュニティみたいなものがないかどうかを期待したんだけど、そういうのは存在しないかもしれないね。技術的な活動はWikiやXOOPSを使ったフォーラムが中心になっているみたいだし。
2002 最近セマンティックウェブにご熱心なようだけど、つまり、その、どうよ。
（￣△￣； 少ない手間で情報入手の選択肢をいろいろ提供できるのは、決して悪いことじゃないと思ってるんだ。例えばRSSで更新情報の要約を提供すれば、携帯電話からの巡回も決して夢ではなくなる。ゲートウェイを1つ用意すればいいわけだからね。
2002 でも、メタ情報の提供って面倒じゃない？
（￣△￣； 現時点のおいらの環境では面倒。だけど、手間を少なくするためのアプローチはこの界隈でもどんどん進んでる。けんたろうさんやDACさんが日記サイトのRSSを吐き出すためのスクリプトを組んだり、ありみかさとみさんがXSLTとMac OS Xの日本語要約エンジンを使った要約自動作成装置の作成方法を公開したりしてるわけで。
2002 ちみは何か自動化しないの？
（￣△￣； いわゆる「プログラム脳」ではないので、理解に時間がかかってるんだな。XSLTなんかは「プログラムでない」から覚えられたわけで。一応 document関数を使った自動作成はやりたいわけだが、取りかかるためのモチベーションがイマイチ（￣△￣；。XSLTというのは、コンテンツを構成する「ドキュメント」「ロジック」「プレゼンテーション」という3要素のうちの「ロジック」に当たる部分を担当するわけだが、このロジックのみを抜き取って考えるのが意外と難しい。
2002 なぜ？
（￣△￣； なんというか、抽象的というか幕を一枚挟んだ先のものをいじっている感じ。CSSが一般ユーザに難しいと思われているのも、セレクタという抽象的ものを使っているからなのかなぁと考えている。XMLが人間が扱うものでないと言われるのも、本来こういったものはコンピュータが適切な操作インターフェースを提供して分かりやすく扱えるようにするべきだからなのかなぁーと。
2002 StrictなHTMLって相変わらず流行っていないような気がするんだけど、正直どう見てる？
（￣△￣； 流行ってるとか流行ってないとかで判断するものじゃないと思うな。「誰もやってないからやらない」じゃなくて、「やったほうがいい」というものであることは確かなんだから。SEOの一般化やセマンティックウェブの知名度アップによって、少しずつ風向きは変わりつつあるし。
2002 そう言えば朝日新聞がすごいHTML講座をやったそうだね。
（￣△￣； Beという初心者向けのITコーナーで3週間の連載になった「夏休みホームページ作り」という記事の話だね。先日スラッシュドットジャパンの「デタラメなHTML入門＠朝日新聞土曜版」というトピックでも話題になってたよ。
2002 間違いが多いのを「初心者のため」と開き直ったって聞いているけど（￣△￣；。
（￣△￣； それは言い過ぎかもしれないけど、目的のために手段を選ばなかった印象はあるよね。内容自体はW3CのHTMLには存在しない<color>要素を使ってみたりとか、なかなかアグレッシブ（使い方間違えています）な記事だったよ。21世紀にもなって、あんなHTML講座を見るとは思わなかった。
2002 こうなってしまうのは何が悪いんだろうね。この分野で信頼できる人に頼むだけのコネがなかったんだろうか？
（￣△￣； それもあるだろうけど、やはり制作に関する環境が未成熟ということがあるかな。よく引き合いに出されるけど、電子メールの世界でもいろんなMUAが存在する以上、標準仕様への準拠は強く求められる。ましてやいまやネット社会の基盤にさえなってしまっているからね。情報を伝えるインフラとして電子メールの信頼性は、標準準拠という面が一役買っているような気もする。
2002 だけど電子メールは手書きでソースは書かないでしょ。ちみはいちいちテルネットでポート25にアクセスしてSMTPコマンドを打ってるのかい？ ウェブというか、HTMLと比較する意味は？
（￣△￣； だから、素人がコードを打つ必要なんてなくなっちゃっているってこと。だけどHTMLの場合、未だに人が手書きしているし、それを不要にするオーサリングソフトだって買うとなると2万円位するし、おまけに吐き出すコードはしっちゃかめっちゃかでしょ。こんな状態で、訳わかんないまま自分の知っていることだけでHTMLの記事を書く人が氾濫して、その入門を読んだ人がまた誰かに訳の分かんない状態でHTMLを教える、と。
2002 あー、ちみがここ数日言い続けている「不幸の再生産」ってやつね。
（￣△￣； この連鎖が止まらないと、いつまでも状況は変わらない。書き方レベルで混乱して足踏みしてしまっているウェブは、すでに使い方やコミュニケーションでの活用云々の領域に踏み込んでいる電子メールに大きく水をあけられてるなぁーと。ウェブも足踏みからこのレベルに移行できれば、もっと有意義な使い方ができるようになるのに。ここが「未成熟」と考えているあたりかな。
2002 うーん、言いたいことは分かる。だけどメーラーはOSに標準でついてくるけど、HTMLを作るソフトはウィンドウズやマックに標準でついてこないもんなぁ。その代わり、ウェブベースのフリーのビルドサービスをやっているとこは増えてきているよね。
（￣△￣； そうだね。はてなダイアリーやブロガーを使った無料サービスが増えてくれば、HTMLを気にせずに済むようになる。そうなれば朝日のメチャメチャなHTML講座も不要だ。逆にヘビーなHTMLユーザーに対しては、こうしたツールのコーティングに関して、どしどし情報を出したり、意見を出してほしいという貢献の要望が強まってくるかもね。
2002 ちみ自身はウェブ系のプロダクトに貢献していくつもりはないの？ モジラとかブログツールとか。
（￣△￣； いや、人目に付かないところでこっそりやってる活動はあるけど。それより、面白い提案を考えたり標準準拠に取り組むためのごもっともな理由を考えたりと、そういう方向で意見を言っていきたいなぁと。
2002 つまり、「ヘタレなので最前線に出ていくのは勘弁して下さい（￣△￣；」と言いたいわけですか。
（￣△￣； だから逝ってないでしょ（￣△￣；。
マック用のRSSリーダーというとほとんどの場合「ネットニュースワイアー ライト」が紹介される。まあ、無償の割によくできたソフトだ。
こいつの上位製品として無印の「ネットニュースワイアー」というソフトも存在する。RSSリーダーの部分に加え、ブログエディタや「Notepad」という名のアウトラインプロセッサーなんかを内蔵している。ネットを巡回するだけでなく、自分の情報発信もこれひとつで済ませてしまおうというなんだか凶悪な製品だ。
「ネットニュースワイアー ライト」＋「ムーバブルタイプ」の組み合わせに対して利点といえるのは、他のウェブログへのポインターを素早く記述できる点かもしれない。RSSベースの巡回を行い、気になったニュースは内容を閲覧、自分のサイトで紹介するなら記事の見出しから「Post to 〜」を選ぶだけで、RSSに埋め込まれた要約とサイトへのリンクを投稿記事に埋め込んでくれる。あとは、ログイン後と同じように編集画面で記事を書いていくだけだ。
「Notepad」は拾ってきた情報をストックしたり、原稿を書いたりする場所と考えればいい。URLにコメントをつけてリスト化しておいたり、考えたことを並べておいたりと、普段から情報の引き出しを用意しておきたい人向けの機能かもしれない。
ま、一部国際化がうまく行ってなくて文字化けが起きている箇所があったりするわけで、全面的にまだ使えるツールではなさそう。第一、これだけの多機能ソフトであったりすると、日本語版でない点も少々気後れの要因になったりする。英語、見なれてないんだわさ（￣△￣；。
こういった専用ツールは、パソコンのエディタで書いているときと同じ感覚、ネットとの連携という利点の両方を持ち合わせている点でなかなか良いかなという気もする。ただ、まだまだネット巡回のメインソフトはブラウザーだったりするので、ブラウザーにこういう機能があるとうれしいような気もした。モジラやオペラのサイドバーで動くブログエディタって、ないんですかね。
毎回毎回しょうもない文章を交えながらウェブの世界を親しみやすく紹介する「グランド・ウェブ！ ファンキー ヘタレ・ロード」。だがXMLを積極的に取り入れ、効率的なページ作りを早くから進めてきたことは意外と知られていない。同サイトのウェブ構築事情を聞くために、我々取材班（誰？）は、あのー（￣△￣；氏のもとを訪れることにした。
あのー（￣△￣；氏の制作機材はシンプルなものだ。昨年末に入れたというADSLのインターネット回線に、メルコ製の無線LAN装置、アップル製のノートパソコンという組み合わせだ。ノートパソコンにはMac OS Xが組み込まれており、プレーンテキストを素早くマークアップしたり、AAなど特殊な文字表現をウェブで問題のないように処理するためのスクリプトが用意されている。
あのー（￣△￣；氏の作業スクリプトの一例。AAなど半角仮名交じりのテキストをユニコードの文字参照に置き換えるツール「Kanaref」（メモルさん作）。ただし、あのー（￣△￣；氏のMac OS X 10.2環境ではコンパイルに失敗するそうで、Mac OS X 10.1でコンパイルしたバイナリーを使い続けているとか。
「制作において最重点に考えているのは、いかに自動化を進めるかということ。だけど、すべてをスクリプトで作ってしまうと、おいらのような素人は何かを変更しようとしたときに手も足も出なくなる。だからいかに早く標準に適した分かりやすいフォーマットに文書を移行するかが課題になります」とあのー（￣△￣；氏は語る。
さまざまなスクリプトによってマークアップされたテキストはそのままXMLファイルに貼り付けられる。あのー（￣△￣；氏のXMLファイルは自信が定義したフォーマットを採用しているが、定義された語彙はXML標準に従っている。そのため、XSLTを通していろいろな形式に変換が可能だという。
「今はXHTMLに変換するだけですが、将来的にはサイトの更新情報を提供しているRSSファイルに変換したり、特定の情報だけを集めて目次を作成していきたいですね」
あのー（￣△￣；氏によると、XHTMLへの変換という用途だけでもXMLを利用する恩恵は大きいという。ページのリニューアルをする際にも、XSLTを書き換えるだけで数十ページのマークアップを変更できるとのことだ。
こうしたXML化の推進は「ウェブ標準化」に対しても大きく貢献しているという。XMLを通した処理を行うことでマークアップの正規化が進み、結果として問題のあるマークアップの発生を抑えられるようになる。自然とどんなブラウザーに対しても、優しいマークアップになってくるのだという。また、XMLの論理表現とCSS（スタイルシート）のクラス名命名の関係もわかりやすく整理でき、データ表現に一貫性を持たせるのも容易になるそうだ。
「こうした方法は、どのようなタグでマークアップするかといった悩みから制作者を解放します。特にコンテンツでの情報発信を最重要に考えている人にとっては、ブログツールよりもマークアップが正確で、HTMLの手書きよりも効率のよい方法として一考の価値があるのではないでしょうか」とあのー（￣△￣；氏は語ります。
このような利便があっても、新たに覚える点が多いのは敷居の高さにもつながる。導入に関する苦労をあのー（￣△￣；氏はどう捉えているのだろうか。
「とにかく簡単なことから初めてみることですね。初めは見出しと本文だけの簡単なマークアップから作り始めて、それをHTMLに変換する練習をする。または、RSSのように多くの人が使っているXMLの応用フォーマットを自分でも書いてみて、XMLのニュアンスを自分でも覚えていってみるとか。すべてを初めから自分一人で覚えていこうというのはかなり難しいと思います。最近はXMLに取り組む人が増えてきていて、情報も増えてきているので、敷居は徐々に低くなっていると思いますね」
「最近ではXHTMLやRSSを採用するウェブツールが徐々に増えてきていて、『どこで使っているの？』といった声はあまり聞かなくなりましたね。『とにかくXMLを使っていこうと』いう時期は過ぎつつあるので、これからは『どう使えば便利になるのか、楽しくなるのか』を探していきたいですね」と、あのー（￣△￣；氏はこれからのウェブ制作へのXML応用にかける意気込みを語って締めくくってくれました。
RSSからXHTMLへの変換というのは去年の11月にやっている。ところがXMLファイルから概要を拾い上げてRSSを生成するのは、まだ手をつけていなかった。なぜかというと、複数ファイルにまたがる処理をどうしようかで悩んでいたのだ。
その後、ありみかさとみさんが2月の時点でロケーションパスにdocument関数を使うという方法を紹介していたが、頭の中でXSLT変換の対象となるXMLファイルにはどういう内容を用意すればいいのか（つまり「複数のファイルを対象に処理する」という頭だった）がまったく整理できていたかったため、どういうXSLTを書けばいいのか、どうプロセッサーに渡せばいいのか、まるで何をすればいいのかわからなかった次第。
さて、もう一度document関数に関する資料を読み直し、考えを整理した。その結果、以下のような流れで処理を行うことにした。
まず、サマリーリストを生成するための「create-summary-list.xsl
」では、フラットなリストスタイルのXMLを作成することにする。独自の名前空間「localrss」を用意して、リストタイプとして「localrss:neta」という要素を並べ、要素内容にrssのdescription要素になるテキスト、他の要素はlocalrss:neta要素の属性に突っ込むことにした。
作成する内容が比較的単純なため、処理も単純。localrss:neta要素の内容となる処理を「/anoh:doc/anoh:content/anoh:day/」以下を対象にひたすら並る。その処理をxsl:for-each要素で繰り返し、xsl:sort要素で新しい順に並べ直す。これを3ヶ月分用意するわけだ。
ただ現段階で前月／前々月のファイルは、<xsl:for-each select="document('http://localhost/works/03-07.xml')/anoh:doc/anoh:contents/anoh:day">といった形で決めうちにしている。元々の原稿が書かれているXMLファイルには前月のファイル名を記載しているので、これを使えるとよかったのだがロケーションパスにそういった指定を突っ込めるものなのだろうか？
サマリーリスト「summary-list.xml」は、これをRSS化するためのXSLTファイル「create-rss.xsl
」で処理する。サマリーリストの構造がフラットなため、XSLT側もroot以下にテンプレートを突っ込む処理と、実際のRSSの構造を定義しながら各々の処理を記述する部分の2つというおおざっぱな構造となった。
ただ、RSSの表示数を15に抑えるという目的があるため、処理に少々工夫が必要。for-each要素に何回処理したテンプレートかを認識させないとならない。そこで、for-each要素のロケーションパスに[position() <= $rssnum]という関数と条件処理を突っ込み、$rssnum変数で指定した15番目以内にあるlocalrss:neta要素のみを処理するように仕組んだ。
あとはXalanに受け渡す入出力ファイルの指定をシェルスクリプトで記述していく。スカンクワークスのXHTML作成からRSS生成、RSSのXHTML化までを組み込んだので、作業はだいぶ楽になるはず（ただ、エラーがでたときにスクリプトを止める処理が入っていない）。
半年も悩んだ割に、作ってしまえば簡単だったんだが、本当にこんな力業でいいのか、が気になるところ。毎月内容を書き換えないとならない部分もあるので、この部分を今後どう自動化していくかも課題だったりする。
昔聞いたことがある。欧米の初等教育では、作文の授業でまず文章構造の作り方を教えるのだという。ある程度の構造がはっきりしてれば、それに自分の言いたいことを当てはめていくだけなので文章の作成は楽になるかもしれない。日本ではどうなのだろう。予備校の授業でいうところの「小論文」の授業あたりがこれにあたるかもしれない。
この文章の構造化をパソコン上で楽に行うためのツールとして、アウトラインプロセッサーが用意されている。そのインターフェースは、タブを使ってリスト上に並べるものが一般的。マイクロソフトワードのアウトラインモードもこの形式。そのほかにも、ダイアグラムを使ってとりあえず記述しておき、あとから矢印を使って各ダイアグラムの前後関係を整理するものもあるし、曼陀羅模様のように関係のあるトピックを近くに関連づけて整理していくものも存在する。
で、今回はアウトラインプロセッサーを語るわけではなく、こいつとXMLについて語ってみようと思うわけだ。構造化という観点でXMLとアウトラインプロセッサーは考え方が似ている。
従来、文書をHTMLに書き出すソフトが多かったが、一律でhn要素やリスト要素で書き出すため、書き出し後にその都度HTMLを修正する必要があった。最近はXMLで書き出すソフトが増えてきたため、必要なXSLTファイルを用意すれば、自分の望むHTMLに変換することが可能になった。
以前アウトラインプロセッサーについて調べていたときに、「HAPPY Macintosh Developing TIME!」が3月16日「勝手に OmniOutliner ファンクラブ」にて、マック用の「オムニアウトライナー」というソフトのXML書き出し機能について紹介している。
オムニアウトライナーは独自のXMLと OPML という形式のXMLの書き出しが可能だ。前者は本文の構造に加えて書式などソフトウェア独自の情報を含んだもの。後者は構造の記述を中心にしたコンパクトなセットを目指しているようだ。前述のサイトの記述によると、開発元のオムニグループでは独自XML形式からマイクロソフトワードで読み込める形式に変換するアップルスクリプトの紹介なども提供しているそうだ。
OPMLについてもう少し調べてみた。OPMLはユーザーランドソフトウェアが2001年3月に、自社のアウトラインプロセッサーのために開発したフォーマットの模様。この仕様を公開することにより、多くのドキュメントとの互換性をねらったものと考えられる。
構造は非常にシンプル。ルート要素となるopml要素以下に、メタデータを格納したhead要素と実データを格納したbody要素に2分される。body要素の中身はoutline要素でひたすら階層化していく。各階層に含まれるテキストデータはtext属性の内容としてマークアップするようだ。
OPMLのDTDが用意されているのでこれを見てみる。とは言っても、実はあまり読み方をあまり理解していないんだけどね（￣△￣；。
body要素直下にはoutline要素が必ず存在する必要があり、そこに含まれるoutline要素は0回以上出現することになっている。つまり、body要素以下にoutline要素が展開され、そのoutline要素中に下位のoutline要素を含むか、それともbody要素直下のoutline要素を空要素としてマークアップすることになる。
outline要素に含まれる属性はtextのほかtype、isComment、isBreakpointが用意されている。このほかに%OthersAttributesというのが用意されているんだが、これの定義を見ると内容が空になっている。なんだろう、これ。
んなわけで、実際どう使われているんだろうと思い、実際にデータを書き出してみることにした。OPMLのウェブサイトにOPMLをサポートしたツールの一覧が載っているが、日本で見かけるのはオムニアウトライナーだけのようだ。実際に下記の図のようなデータを作成してみた。
横に2列、そしてトップレベルのノードに注釈を入れるという、アウトラインプロセッサーらしくないデータ記述だが、文書中の構造を記述するなりいろいろリッチな情報にしておく意味はあるのかもしれないと考えたわけ。それをopmlで書き出してみた
。送信時のマイムタイプはtext/xmlかtext/x-opmlを考えてるようだ。
opmlで吐き出されたドキュメントには見出しや本文の区別がないため、XHTMLに変換する際にXSLT側で順序や深さをベースにどこが見出しなのかを考える必要がある。ただ、こういったドキュメントに対応できるのも、XSLTの魅力なのかなとも考えている。
ちなみにRSSをまとめて出力するためにOPMLで記述するという使い方があるらしい。今年の4月の「blog.bulknews.net」の「OPML for Bulknews」という記事で、bulknews.netが出力しているRSSのリストをOPMLで公開
している旨が書かれている。
確かに「rss opml」というキーワードで検索をかけると、opmlファイルを読み込むRSSツールやopmlを支持する話題などが出てくる。RSSを捕捉するアンテナツール「RNA」も8月8日のビルドからOPMLの出力をサポートしたようだ。まずはこの分野で普及していっているのだろうか。
8月上旬に行われたさとみかんの編成更新（テレビ局みたいですな（￣△￣；）によって、はてなに借りてる「ヘタレアンテナ（￣△￣；」で捕捉してたサイトの多くを、さとみかん経由でチェックできるようになった。
もともと、さとみかんで捕捉されていないサイトを定期的にチェックするための補足的な意味合いで使っていたので、さとみかんにあるなら少し内容を整理しようかなっと。ただ今度は、さとみかんから外されたときにURLがわからなくなってしまうと困るな、と思っていた。
今日、詳しく設定画面を見たら非表示の設定があることを知った。これで増えすぎて「うーん」ってな状態になっていたサイトを少し整理でき、24まで表示数を減らした。
本当は自分でも細かく制御できるアンテナを動かしたり、サイドバーに入れたりしたいんだが、おいら自身がCGIにからきし弱い、レン鯖でCRONを解放していないなど、あれこれ理由があってどうにもこうにも。今RNAをテスト的に動かしているのだけど、これでうまく収まるかなぁ。
オペラ社から6系列のファイナルとなるオペラ 6.03が出た。オペラ社の発表によれば、次は年末に出るバージョン7（今だと7.2系列？）ということになる。
昨年秋のパブリックベータの登場以来、あーだこうだと言われるどころか存在すら無視され続けられ、その悲惨な状況はオムニウェブやiCabの比ではないイメージすらあったわけだが、ちと状況を整理したい。
幸運なことに、ありみかさとみさんの「ねこめしにっき」に、オペラに関する記録がいっぱい残っている。これをありがたく借用することに（￣△￣；。
最初のパブリックベータは2002年の9月末。とりあえず「仕様を固めましたので出しました」的な感が強く、少なくとも国内での反応は最悪。海外での反応は、ニュースグループなどを見る限りそんなにボロクソには言われていなかったので、どうやら日本語表示時のパフォーマンスが致命的だった模様。ほかに問題を感じたのは、レンダリングエンジンの抱えるCSSおよびJavaScript周りのバグ、マックらしからぬ操作性、そしてウィンドウズ版と全く異なる機能インターフェース（オペラの特徴であるMDIがない、右ボタンを多用するマウスジェスチャーの大幅な省略、ホットリストの挙動が違うなど）。
次のパブリックベータは11月。日本語表示時のパフォーマンスをやや改善したほか、新たにリンクバーを実装しJavaScript周りの仕様を一部改訂、ウィンドウズ版オペラ7で実装される予定だったものが先行させたかたちとなった。この前後、ウィンドウズ向けにオペラ7のパブリックベータが公開され、6系列はメインテナンスモードに入る（つまりマック版に関しても、新たな変化を望みにくい状況になった）。
そして12月に入り、最後のベータ版が登場。日本語表示のパフォーマンスは大幅に引き上げられたが、それでも当時のインターネットエクスプローラと比べて「まぁまぁいい勝負」の程度。当時、マックの次期標準ブラウザーと目されていた「キメラ」（現：カミーノ）と比べると、圧倒的に差を付けられていた始末。またその後、インターネットエクスプローラも最終版5.2.3で大幅な速度向上を果たしている。
さらにこの時期、マイクロソフト社とアップル社の間に交わされた標準ブラウザーに関する契約が切れた（参考：最も愛したブラウザー〜ちと気が早いがIE:macメモリアル）ことにより、オペラ社がマックに興味を示していることが伺われる記事を目にするようになった。
この件に関してオペラ社がアップル社に対しどんな提案をしていたのか、——例えば、オペラそのものをバンドルするのか、それともアップル社製品にオペラのエンジンを提供するのか、それとも以前のマックのように複数のブラウザーをバンドルするのか——は定かではないが、これ以降オペラ社のアップル社に対する姿勢は非常に過激なものになってくる。逆にオペラ社側もアップル社の動きが見えないことに対して、いらだちを募らせていたのだろうということも推測できる。
そしてこの月の中旬、痺れを切らしたかのように突然の正式版リリース。正直「これは……」という出来であったのは確かだったが、マウスジェスチャーやツールバー上の検索窓など、のちにマック用のソフトでも見られるようになる機能が、初めてインターネットエクスプローラやネットスケープ以外のブラウザーを知った人たちから意外と評価されていたのが、おいらにとってもものすごく意外だった。それがオペラのブラウザーに対する芸術性（参考：State of the Art）を理解するきっかけになったし、かく言うおいらも、Google検索窓とカスタムパネルのためだけに、処理速度を我慢してまでオペラを使っていたようなものだった。
その後アップル社よりサファリが登場、オペラ社はマック撤退をほのめかす発言を繰り返す。アップルの純正アプリを退けたソフトはトーストくらいしか知らないので、ある意味「撤退やむなし」とも思っていたが、5月に6.02というバージョンにて日本語版を投入。英語版の投入から実に半年が経過していた。プレスリリースによると「マック用の組込用途の需要が増えたので」というのが開発継続の決定を後押ししたらしい。確かにマックで利益を出すメドがついたというのは開発継続の大きな理由にはなるが、それを声を大にして言うとはマカをなめてんのか、お前ら……（￣△￣；。
今回の6.03はMac OS X 10.3対応がメインのため、特に何か期待できるわけではない模様。そりゃ組み込み用に提供しているのに、10.3で問題が起きたら大変だろうし。実際、6系列で直されなかった問題は、おいらが把握しているだけでも以下の通り。
なんか、激しくグレーゾーンの問題が多いので、公言するのもあほくさいんだけど、覚え書きとして。あとは、ありみかさんの検証を参考にしてくだされ。次は、なんかその、せめてウィンドウズ版と同品質のものを望みたいわけで（￣△￣；、せめて.switchユーザーを悲しませないようなものであってほしいかなぁ。
というわけで、オペラに関しては次期バージョンが出てくる冬まで一休み。当面のメインブラウザーをモジラ ファイアーバードにしようと計画。オペラを使っていた理由でもあるツールバー上の検索窓、そしてサイドバーが用意されているのがひとつ。もうひとつはクライアントサイドXSLTを実装した「モジラより軽いブラウザー」である点が採用の理由。「クライアントサイド」の利点がわからない？ ふふふふ、秘密（￣△￣；。
OS X版はここ最近ようやく提供されるようになったので情報が少ない。かといって開発が急ピッチに進んでいる段階なのであまり見逃したくないという気持ちも働き、ナイトリーベースで追っていくことに。以下セットアップに関して。
モジラと比べると、非常にやりたいことが明確で分かりやすいブラウザーのように感じる。いまのところは非常に満足。
おいらは書類をウェブと紙の両方に出力する状況に迫られることがある。そうなるとテキストをワードで整形して印刷、FAXを使ってよそに流したりするわけだ。その一方で別の人に頼んでHTMLにしてもらう行程を踏んでいる。つまり最近は公私ともにHTMLを手書きしてないわけなんだが（￣△￣；。
話がずれた。この印刷物とHTMLを平行して作るという作業が、正直なかなか面倒くさい。なんとかならんかなー、と調べてたらおもしろそうなものがあることに気がついた。「XSL-FO」だ。
XSL-FOは専用のプロセッサーと組み合わせて使う、レイアウトされたドキュメントを生成するためのマークアップを行う言語なのだそうだ。どういうことかというと、「おいらのオペラにはMDIが装備されていない」みたいな文があったとする。通常HTMLでは文全体をパラグラフとして「<p>おいらのオペラにはMDIが装備されていない</p>」マークアップし、そのパラグラフに対してレイアウトのテンプレートとなるスタイルシートを設定する。12ピクセルの太い文字で表示させるのであれば次のようにCSSで宣言することになる。
XSL-FOもその形式を踏襲しているが、スタイルシートをXMLの形式で記述、つまり要素と属性値の形でスタイルを指定する。簡単に書くと次のようになる。
みたいな記述になる。むろん、直接装飾内容をマークアップしなくてもスタイルをテンプレート化させて、任意のブロックに任意のテンプレートを当てることも可能なようだ。
これのマークアップを処理するためのプロセッサーが存在する。著名なものにはApache.orgの「FOP」というツールがあるそうだ。XSL-FO形式で作成したドキュメントを読み込み、XMLやHTML、PDFなどの形式に変えられるという。書類が定型であれば、提携のXMLを作成し、XSLTを使ってXSL-FOに変換、HTMLとPDFを書き出す、といった流れをスクリプト化しておけばだいぶ作業が楽になる予感がする。
妙におもしろいなと思ったのは、文書の装飾を構造化しているという点。要するにXMLは文書を構成する様々な要素を役割ごとに分離する方向を目指していると考えることもできるわけだ。これでおいらは構造を変換するテンプレートを作る「XSLT」、語彙についての定義を提供する「RDF」（RSSやFOAFはその応用）、そしてレイアウトを定義する「XSL-FO」という3つのXMLのソリューションを知ることになるわけだ。
というわけで、XSL-FOの取得はおいらにとって必然性の高いものになりつつある。来月はこれをがんばってみようという次第だ。
22日から30日までの8日間のウェブサーバーのアクセスログを使って、http://anoh.s10.xrea.com/semdata/update.rdfにアクセスしたクライアントを分析してみた。RSSリーダーは定期的にリロードされることが多いので、ユニークホスト別で抽出。有効データ131ホストをベースに、使っていたホスト数を比較した。
| 順位 | クライアント名 | ホスト数 |
|---|---|---|
| 1 | SharpReader 0.9.x | 45 |
| 2 | FreedReader | 22 |
| 3 | Mozilla Firebird 0.6.x | 16 |
| 4 | RSS Reader Panel | 11 |
| 5 | NetNewsWire 1.0.3 | 7 |
| 6 | MSIE 6.0 | 5 |
| 7 | Mozilla/4.0 | 4 |
| 8 | lwp-trivial/1.35 | 3 |
| 9 | FeedDamon | 2 |
| 9 | Opera7.x | 2 |
| 9 | WWW Tracker/0.5.5 | 2 |
| 9 | MagpieRSS | 2 |
| 13 | FeedValidator/1.21 | 1 |
| 13 | Googlebot/2.1 | 1 |
| 13 | Hatena Antenna/0.4 | 1 |
| 13 | http://www.almaden.ibm.com/cs/crawler | 1 |
| 13 | Java/1.4.1_01 | 1 |
| 13 | libwww-perl/5.64 | 1 |
| 13 | Mozilla/3.01 (compatible;) | 1 |
| 13 | MSIE 5.0 | 1 |
| 13 | Syndirella/0.9b | 1 |
ウェブサービス系は、リモートホストがどうしても少ない値にまとめられてしまうので、はてなアンテナとかは仕方のないところ。おいらが知らないものもいくつか入っているので列挙していきたい。
まず、FreedDaemonは、ウィンドウズ用のRSSクライアント。アウトルック2003風の横3ペイン型のインターフェースを採用している。また、ここの8月29日付のブログFeedDemon's XSL-based Previewによると、プレビューのスタイルをXSLで定義している模様。
MagpieRSSはPHP向けのRSSパーサらしい。RSS 0.9および1.0に対応。
Syndirellaはウィンドウズ向けでGNUライセンスベースの.NETアプリケーションなのだそうだ。要約の表示方法はカスタマイズが可能。先日紹介したOPMLもサポートしている模様。
これほどの数のホストがRSSファイルを捕捉していたのは驚きだが、それ以上にRSSを扱えるツールの多さにも驚いたところ。これらのツールの普及に伴い、RSS自体の普及が進んでいくことを望みたいところ。
駅前の割と大きめの本屋に行ったら、XML関連の書籍がすべて撤去されていた。一緒のコーナーにおかれていたLinux関連の書籍は、相変わらず売れていないように見えるわりに、全然撤去される気配が見えないのと対象的。
雑誌コーナーでもXMLを扱ったものがなくなっていたので、これで近所でXML関連の書籍を手に入れたり、内容を確認したりすることができなくなったわけだ。うーん、東京まで出かけるしかないのかなぁ。書籍だけは実際に目を通してから買いたいので、通販とかしたくない。
![[Valid RSS]](/common/valid-rss.png "Validate my RSS feed")
![[Valid XHTML 1.1]](/common/noa.png "This page is Valid XHTML 1.1")
