国立国会図書館が保有するデジタルアーカイブに加え、国や公共の機関、民間、個人のデジタルコンテンツを対象とした一元的な検索とコンテンツやサービスそのものへの案内をワンストップで提供することを目的としたサービス。

検索対象は近代デジタルライブラリーや国会図書館の蔵書目録などに加え、青空文庫なども対象になっているそうです。

ということで、ネット上ではいままで出てこなかった文献の検索などに威力を発揮しそうです。それだけでなくブックマーク機能もあるとのこと。早速ユーザ登録してみましたが、昨日の段階ではアクセスが殺到していたようでアクセスできないこともありました。今日は重いですが、比較的見ることができました。

何がすごいかというと、AJAX を多用したユーザインターフェースとか、ログイン画面のパーソナライズや閲覧データのブックマーク機能、ブックマークへのタグ付け、ブックマークの公開と、

国会図書館というイメージとはかけ離れた面白いサイトです。

検索も題名や索引だけでなく、書籍の全文検索や、連想検索があったり、辞書検索やキーワードランキングの公開などもしています。検索結果にもお薦めを紹介する「資料ピックアップ」が表示されたり、Wikipedia へのリンクが表示されたり、RSS の配信機能があったりと、考えられることをすべて詰め込んだ感じです。

残念なのは検索の精度が悪いことと、非常に重いこと。これが Google レベルとは言わなくても、もう少し快適になればかなり役立つサイトになるのではないかと思います。そのあたりは情報大航海プロジェクトにがんばって欲しいですね（ちょっと違うか）。

米ヤフー、電子メールソフトウェア企業のZimbraを買収へ:ニュース – CNET Japanから。Yahoo が AJAX グループウェアを提供する Zimbra を買収するとのこと。

Zimbra はオープンソースのWeb型グループウェアとしては AJAX を多用した動作で評判でした。Yahoo に買収されたことによりオープンソース版の開発が止まってしまう可能性もあります。日本でも feedpath が Zebra として提供していましたがどうなるんでしょうか。

Zimbraを際立たせているのは、リッチな電子メール機能を提供する「Zimlet」というウェブサービスのマッシュアップである。例えば、電子メールに含まれる飛行機のフライト情報にマウスカーソルを置くだけで、フライトの状況が確認できる。また、FedExの配送状況を追跡して地図、在庫やその他の情報を電子メールに取り込むこともできる。

Yahoo Mail の UI が AJAX で GMail のように強化されそうですね。

AJAX ツールキットの部分はすでに Kabuki という名前で Apache に寄贈されていますので問題ないと思いますが。こちらも YUI との統合の方向になるかもしれませんね。

さて、Yahoo が Zimbra を買収したことで、次の買収相手は Zoho ではないかとも囁かれています。Zoho 買収は Google のオンラインアプリケーション群と競合しますので、とてもあり得そうな気もします。

WordPress 2 以降ではアップロードした画像の記事への挿入も AJAX を使ってかなり便利になっています。しかし img 要素に画像の幅と高さが自動で入らないので、入るようにしてみました。これでブラウザが画像を読み込んでからレイアウトを再計算しなくて良くなるので、表示速度が若干拘束されるはずです。

試したのは WordPress ME 2.2.3 です。修正するのは wp-admin/upload.js ファイルです。修正箇所が多いのでファイルごと入れ替えてください。IE7 と Firefox 2 で動作確認しています。

以下、修正の考え方を説明します。読まなくても使えます。

239 行目付近の部分で img 要素の文字列を作っている箇所があります。ここで width と height が指定すれば良さそうです。しかし、this.currentImage.width と this.currentImage.height はサムネイル画像の、しかもサイズが合っていない値になります。

そこで、JavaScript の Image オブジェクトを使ってサムネイル画像またはフルサイズ画像を取得して、width と height を取得することにしました。しかし、Image オブジェクトは生成して src を指定してからすぐに width と height を参照しても 0 が返ってくるだけです。画像がまだ読み込まれていないからです。(キャッシュにある場合は値が返ってくる。)

そこで、Image オブジェクトの complete が true になるまで待てばよいのですが、JavaScript の宿命で wait や sleep に相当するものがありませんので、setTimeout ないし setInterval 関数を使って、ロジック部分を別関数化して呼び出す必要があります。これに伴い変数もグローバル変数にする必要がありました。

さらに何らかの理由で画像が取得できなかった場合でも無限待ち（ループ）に陥らないように制限もかける必要があり、大幅な変更になりました。

今の若い人はウェブ系のエンジニアであっても Netscape を知らないことに驚く。Netscape の歴史や栄枯盛衰については別の機会に語りたいけれども、彼らはオープン標準に本当に貢献してきたと思う。それは Firefox や Thunderbird というソースコードのことではない。それらのもとになった Netscape Navigator などをオープンソースにしたことも素晴らしいが、それ以外の規格・仕様のことだ。Netscape がどういうものを作り、残してきたか。

いうまでもなく、今日の Web では欠かせないAJAX の構成要素でもある。当初は LiveScript という名称だったがマーケティングの事情で JavaScript となったことは有名。現在は ECMAScript として標準化された。

セキュアなウェブアクセスを提供する SSL も今日欠かせないものになっている。彼らは新しい機能を追加するときにセキュリティについては徹底的に議論したという。（いま考えると弱い部分もあったけど。）

これも Netscape の発明。

RSS のベースとなった規格 RDF も Netscape が生み出した。もともと Apple の MCF を Netscape が XML に拡張し、標準化されたもの。当時は RDF はほとんど理解されず、注目を集めるのはブログがブームになった 2002 年以降のこと。

こうしてみると、Netscape が関わった多くの技術規格が今日必要不可欠なものになっている。他方、IE 擁する Microsoft が繰り出してきたものはどうであったか。例えば VBScript や ActiveX は非互換の問題しか生んでいない。もっともこれには Netscape 側も JavaScript Stylesheet (JSS) や、独自の HTML 要素の追加などのミスはあったが、Microsoft の方がひどかった。

過去の Netscape には革新的なブランドのイメージがあり、そのイメージは Google でもいまだに超えられていないと思う。Apple は革新的なイメージを出すのはうまいけど、何かオープン標準なものをつくっただろうか。

日本語サービスはなかったので知らない人も多いでしょうが、Start.com は AJAX を使ったポータルという実験的なサイトでした。

かつての Microsoft は microsoft.org を取得していなかったために他人に取られてしまうほどドメイン戦略に疎かったわけですが、近頃は passport.com、start.com、live.com など一級の英単語のドメインをふんだんに使っていますね。live.com が失敗したら次は何で来るのでしょうか。

Yahoo! Search Blog: Introducing Robots-Nocontent for Page Sections という記事を読んで考えたこと。この記事の結論は、Yahoo のクローラーが class="robots-nocontent" 属性のつけられた部分を重要視しないようになるよ、ということを言っています。一例を挙げると、

<div class="robots-nocontent">
  この部分はサイトのナビゲーションメニューで
  すべてのページに共通の部分だから、
  記事とは無関係な単語やキーワードも含まれているよ。
</div>

というような感じで使うことが想定されています。rel="nofollow" の考え方に近いです。このように特定のクラス名などを付与して、ウェブ全体で共通の意味づけをもたせようという考え方は Microformats といわれています。Technorati はこの Microformats を推進しています。今回の Yahoo の発表は、Yahoo が Microformats に対応していくという表明と考えられます。

現代 HTML の問題点

しかし、この発表には賛否両論が渦巻いています。そもそも検査エンジンのロボット（クローラー）のために、文章構造に本来必要のない class を追加することが HTML の本質に反している、という主張があります。

私はこの意見には賛成ですが、現代の HTML 文章が、本来想定されていた HTML と異なる使われ方をしているところにそもそもの問題があると思います。今日の HTML が文書内容だけでなくユーザインターフェース（UI）や広告、サイドバーガジェットなどを含んでしまっているということです。

10年前の HTML は、文書構造とデザインが一体化しており、誰もが table,td 要素を使ったレイアウトや font 要素を使った見出し・強調の表現に疑問を持っていませんでした。それが啓蒙活動の成果により、HTML と CSS によるデザインの分離という考え方が浸透し、確立されてきました。

しかし、UI の分離という点ではいまだに成し遂げられていません。そればかりか AJAX の登場で、HTML に UI が組み込まれる状況は加速しています。理想的には UI 部分を HTML から分離し、Mozilla の製品で使われている XUL など、他の言語で置き換えるという方向性が取られるべきだと思います。そもそも HTML が XHTML に進化したのも、名前空間を使って XML 文書に XML 文書を埋め込めるという XML ならではのメリットがあったからです。

セマンティックウェブの考えは普及したが、なぜ XML が使われないのか

セマンティックウェブの考え自体は広く普及していますが、XHTML を XML 文書として積極的に利用しようという考え方はあまり普及していません。これにはいくつかの理由があると考えられます。

一つにはすべての UA（すなわちウェブブラウザやクローラー）が、XML を解釈できないことがあります。また、多くのウェブデザイナーにとっては HTML はまだしも XML となると難易度が高い（と感じる）ことではないかと思います。技術者の中でも XML は苦手という人はいます。

例外的なのは RSS（のフォーマットである RDF）に Dublin Core を埋め込んでいる例でしょう。ブログに RSS を埋め込んでいる例もありますが、ほとんどの場合 HTML のコメント扱いされており、本来あるべき姿ではないと感じています。

XML の考え方は非常に有用なのですが、とっつきにくいというのが普及を妨げている要因だと思います。そこで、XML を使わずに HTML の範疇でセマンティックウェブに近づける試みが Microformats なのです。これなら HTML を理解したデザイナーも class 属性に決められた値を追加するだけですから簡単に取り組めます。

Microformats はその導入のしやすさから、注目を集めています。しかし、大局的にはセマンティックウェブへの取り組みを遅らせてしまうという可能性もあると私は考えており、導入には躊躇しています。

本来ならばウェブの文書を作成するツールが XML に対応し、またブラウザが XML に対応していけば Microformats のほとんどは不要になるはずです。それとも私はまだ理解していないだけで、Microformats は XML と共存して、もしくは相互補完してセマンティックウェブの普及に役立つのでしょうか。しかし Microformats は HTML のタグを拡張してきた苦い過去を彷彿とさせます。

本来 Yahoo が取るべき対応

なぜ Yahoo はウェブサイトの作成者に労を強いるのでしょうか。Google は以前からウェブ文書のなかからコンテンツの重要部分とそうでない部分の切り分けに成功しているように見えます。Google は力業で解決していますが、Yahoo にはそれが難しいのか、よりスマートな解決策をもとめているのか、あくまで補助的に参考にするだけなのか疑問です。

たとえば今回の Yahoo の取り組みも、スパマーに逆手に取られたらどうなるのか考えてみると、Google のように自動的に判別する技術はどのみち必要になってくると思います。

インターフェースが軽快

AJAX を採用しているのとサーバのレスポンスがきわめて良いため、livedoor Reader より快適に感じます。Goo がスクロール検索というのを始めたみたいですが、Google Reader は以前からそういうことができます。

タグに日本語が使えない

まだベータ版で UI が英語なのはしょうがないが、タグやフォルダ名に日本語が使えないのが困ります。それどころか記号も使えません。livedoor Reader の購読フィードを OPML で移した場合、半角英数字でつけたフォルダ名は移行されましたが、日本語のフォルダ名は無視されてしまいました。コンテンツ自体は日本語でも問題なく表示できます。

タグとフォルダの区別が分かりづらい

Google Reader では記事ごとにタグをつけることができますが、フォルダ名と同じタグを記事につけるとフォルダの一覧を開いたときに、その記事が紛れて表示されます。これは私だけかもしれませんが、これが混乱の元になります。

携帯用のアクセスページ

携帯で確認するためのページがあるのはうれしいですね。英語ですが。

検索ができない

何が不満かというと、Google なのに過去に読んだフィードの検索ができないということ。世の中にあるフィードをキーワード検索して購読することはできます。しかし、読んだフィードにせっかくスターやタグをせっせとつけたのに遡りたいときに素早く探すことができないのです。だってGoogle に期待するのはそこでしょう。Gmail しかり。スターをつけたものは左上の starred items から、タグもフォルダのツリーからたどれますが、やはりさっと検索したい。

Google Reader の既読記事を検索する方法によれば、購読リストを OPML ファイルで書き出して Google Co-op に登録するという技で検索機能を実現できるそうですが、タグづけとかスターが反映されるわけではないのが悲しいところ。結局のところ残したい記事は SBM にブックマークしてタグづけする方が便利そう。

そういう意味では日本語対応ということも含めて、国産の livedoor Reader + livedoor Clip の組み合わせが現状では一番便利かもしれません。

この php-json モジュール ですが、 配布元には SRPM もあるので、Red Hat 系の環境ならこちらをリビルドして入れる方がスマートですね。ビルドには php-devel がインストールされている必要があります。

wget http://www.aurore.net/projects/php-json/php-json-4.3.2_1.2.1-1.aurore.src.rpm
rpmbuil --rebuild --target=i686  php-json-4.3.2_1.2.1-1.aurore.src.rpm

で php-json の RPM ができます。 しかも、php.d/ ディレクトリの下にモジュールを読み込む設定ファイルも置いてくれるので、 php.ini をいじらなくても Apache を再起動するだけで使えるようになります。

rpm -ivh php-json-4.3.2_1.2.1-1.aurore.i686.rpm
service httpd restart

Cent OS 4.4 の PHP4 環境でも利用できました。

例えば、document.body.clientHeight が 0 を返すようになったとか。IE6 でも標準準拠モードでは document.body.clientHeight が使えませんでした。この場合は document.documentElement.clientHeight を使えば回避できました。IE7 では互換モードでもこの記述が必須になったのでしょうか。それとも 標準準拠モードで XML 宣言がある場合は、正しく認識されるようになったというほうが正しいかも。いままでの IE6 の挙動がおかしかったとはいえ、修正するのはやっかいですね。

もっとも、Firefox も含めて表示領域の高さを取得したい場合は、次のようなコードにすれば様々な環境に対応可能です。

var bodyHeight = window.innerHeight || document.documentElement.clientHeight || document.body.clientHeight;

AJAX などで JavaScript を多用していますが、互換性を確保するにはいろいろ知識が必要になります。こういった違いはライブラリで吸収してくれると有り難いし、その方向に行くのは確実です。ただ、いまは各種ツールキット、ライブラリが溢れていて、どれを使えばよいのか正直わかりません。将来的には違いを吸収してくれる洗練されたライブラリが出てくるでしょうが、しばらく様子見でしょう。

  if(options) {
    for (var key in options) {
      if(options.hasOwnProperty(key)) element[key] = options[key];
    }
  }

このような感じで、オブジェクトのプロパティをループで回して使う場合です。

さて、Safari の JavaScript の不備: Days on the Moonによると、Safari は 2.02 で hasOwnProperty に対応したようです。実際に Mac OS X 10.3 の Safari 1.3.2 では、次のようなエラーが表示されました。

  Value undefined (result of expression args.hasOwnProperty) is not object.

このエラーははてなブックマークでも出るものです。回避策がないものかと探していたところ、オブジェクト指向JavaScript: クロージャで遊んでみるという記事を見つけました。safariにはhasOwnPropertyメソッドが実装されていませんが、同等のメソッドを独自実装しています。と書かれていたのでソースを拝見したところ、Safari 用のコードが書かれていたので、ありがたくパクらせて拝借させていただきました。

/* for Older Safari */
if (!Object.hasOwnProperty) {
  Object.prototype.hasOwnProperty = function(it) {
    return (this[it] && !this.constructor.prototype[it]);
  }
}

これで古い Safari でも hasOwnProperty が使えるようになりました。