TidBITS-J#355/25-Nov-96 TidBITS-J#355/25-Nov-96今週号は、クリスマスプレゼントの提案のお願い、AOL ユーザーにとって の重大情報、Microsoft 社から出た新しいインターネットソフトの簡単な 報告を載せてある。また、Adam が（個人用 Web サーバを中心に）Web サー バ市場の現状を吟味し、Matt Deatherage 氏が Apple 社の Meta-Content Format（MCF）という情報を管理・閲覧する新たな方法を細かに調査・分析 している。
目次：
Copyright 1996 TidBITS Electronic Publishing. All rights reserved.
問い合わせは <info@tidbits.com> へ、感想は <editors@tidbits.com> へ。
今回の TidBITS のスポンサーは：
（翻訳：：尾高 里華子 <odaka@iprolink.ch>）
ShrinkWrap の作者 Chad Magendanz 氏 <chad@halcyon.com> と彼の妻 Galen は、予定日よりも早く彼らの非ソフトウェア作品第一号、Quinn Pierce Magendanz をリリースした。この場を借りて、彼らにお祝いを述べ たいと思う。Chad は、既に My First C Compiler（ TidBITS-321 参照） を購入したとの噂もあり、Macintosh プログラミングの殿堂に Internet Config で知られるただの Quinn の仲間ができる日も近いかもしれない。 [ACE]
何か良いプレゼントはありませんか? クリスマスシーズンは、商業化し てしっまているとは言え、私たちはこのシーズンが大好きだ。我々のク リスマスの恒例行事に参加しようと思う方は、お薦めのコンピュータ関連 ギフトのアイデア（贈りたいものでも欲しいものでも）を 1 パラブラフに まとめて、96 年 12 月 2 日までに私 <ace@tidbits.com> 宛に送って頂き たい。皆さんから寄せられたアイディアをまとめた記事を TidBITS-357 か TidBITS-358 に掲載するつもりだ。また、特別お買得商品を用意した いとも思っている。[ACE]
AOL が料金詐欺 -- AOL は、96 年 12 月 1 日から導入する新たな課金 方式で、自分の首を絞めてしまっている。この新しい方式は（インターネッ トへのアクセスを含めた）AOL のサービスを月 19.95 ドルで無制限に受け られるというものである（一部のユーザーにとっては悪い話ではない）。 だが AOL は、加入者が特別に別のオプションを選択しない限り、既存の 全ての アカウントにこの新しい課金方式を適用するつもりであるとい うことを申し訳程度に書いて、特定のフォーラムにひっそりと置いておい ただけだ。言い換えれば、新しい課金方式は嫌だと AOL に伝えない限り、 自動的に新料金で請求が来てしまうのだ。AOL の典型的ユーザーにとって、 これは月 10 ドルの値上げと同じでことある。
州の検事総長グループがこの件を審議中し、先週ワシントン州の検事総長、 Christine Gregoire 氏が、加入者がサービスを受ける前に料金の変更に関 する情報を積極的に知らされるべきだという旨の AOL の同意書を公開し た。加入者は、97 年 3月 31 日までにこの新課金方式に対する明確な同意 をすることになり、96 年 12 月 1 日の期限前までに AOL を利用していな い新規加入者は、新料金と既存の申し込みのオプションの差額が返還され るだろう。とはいえ、AOL は 96 年 12 月 1 日に新料金を適用するように 変更しているところなので、AOL のアカウントをお持ちの方は、意志を表 明しない限りは請求金額が上がるだろう。[GD]
Microsoft 社の新インターネットソフト -- Microsoft 社は、最近新 しい Mac 用インターネットソフトを 2 つリリースした。Internet Mail and News 1.0 と Internet Explorer 3.0 の第一期ベータ版である。 Internet Mail and News の方は、（John Norstad 氏の NewsWatcher と Marco Piovanelli 氏のテキストエンジン WASTE を部分的に使った）独立 したアプリケーションであり、Internet Explorer のメール機能と Usenet ニュース機能の代りとなる。インターフェースは Windows から脱却して おらず、Eudora のような円熟したプログラムとは張り合うすべも無いが、 スピーディーでかつ、ニュースグループ用のサブジェクト・フィルタ、ド ラッグ ドロップテキスト編集、メールフォルダの簡単管理といったそこ そこの機能を備えている。ダウンロードサイズは約 800K だ。
<http://www.microsoft.com/ie/launch/imn.htm>
<http://www.microsoft.com/ie/download/ieadd.htm>
Microsoft Internet Explorer for Macintosh 3.0b1 の方は、4 MB という 比較的スリムなメモリ・パーティション（ただし、システムの一時メモリ はものすごく使う）で済み、設定可能なツールバー、ビルトイン・ビデオ、 オーディオ、HTML 3.2 のスタイルシートのサポート、Netscape のプラグ イン、（QuickDraw 3D での）VRML を備えている。さらに、Apple 社の Java 用 MacOS Runtime と（間もなく出る）Metrowerks 社と共同開発した Microsoft Java VM のどちらでも使える Java もサポートしている（ただ し、Java を使うとさらにシステムメモリが 4 MB 必要になる）。これまで のところ、ベータ版に関する評判は、ものすごくまちまちである。ダウン ロードサイズは、約 5 MB だ。[GD]
<http://www.microsoft.com/ie/mac/>
by Adam C. Engst <ace@tidbits.com>
（翻訳：齊藤 聡 <akkun@ca2.so-net.or.jp>）
最近の Macintosh の Web 業界、特にサーバ側のことについて、プレスリ リースがものすごい勢いで飛び交っている。しかし、Web サーバは一個人 向けではないと考えるのはやめにして、さほど遠くない将来にそれを使用 する自分の様子についてのニュースを読んでいただきたい。
WebSTAR 2.0 登場 -- 今週の大きなニュースは Macintosh 市場で指折り の Web サーバである StarNine 社の WebSTAR 2.0 のリリースであった。 StarNine 社は、処理速度、セキュリティ、新技術という 3 つの基本的な 点について WebSTAR 2.0 を改善した。
<http://www.starnine.com/webstar/webstar.html>
すでに軽快な WebSTAR の 2 から 3 倍も向上した処理速度は新しい 2 種 類のキャッシュ法によってもたらされている。キャッシュ処理について詳 しくない人のために言うと、RAM に情報を記憶することによって 2 回目以 降のデータへのアクセスが最初のデータアクセスに比べて大きく高速化す る。WebSTAR 2.0 は“スマートな”データキャッシュを採用している。こ れは、アクセスされているファイルをつねにモニタし、キャッシュされる ことで最も効果的なファイルを決めるプログラムのことである。一方、他 の Web サーバはキャッシュを行うためのマニュアルのインターフェースを 備えているものだが、Web 管理者はキャッシュされたファイルのリストの 整備を絶えず行う必要がある。データキャッシュと同じくらい重要なもの に、WebSTAR の新しいファイル情報のキャッシュ機能がある。Mac のサー バにとって最も大きなボトルネックの一つは低速な Macintosh のファイル システムにある。RAM にファイル情報をキャッシュすることで、WebSTAR はファイルシステムによる遅れを完全に回避する。ファイル情報のキャッ シュにかかる容量は報告では 1 ファイルあたりわずか 500 バイトである。 それなりの大きさのサイトなら、莫大な RAM を消費することもない。
WebSTAR 2.0 のセキュリティは WebSTAR の基本パッケージに WebSTAR/SSL を同梱し、さらに 2 つのセキュリティ機能を追加したことにより改善され ている。以前には、IP アドレスによりサイト全体のアクセスを制限でき た。しかし、フォルダへのアクセスの制限はユーザー名とパスワードによ るしかなかった。WebSTAR 2.0 では IP アドレスによるフォルダへのアク セス制限が可能になっている。例えば、もしだれかが個人的なインターネッ トサービスプロバイダからイントラネットのサイトをヒットしたときには ユーザー名とパスワードによる制限に戻れるようにもなっている。以前の セキュリティ上の別の問題点は WebSTAR が WebSTAR の階層のどこに置か れた CGI でも起動してしまうというものだった。だれかがトロイの木馬 CGI をアップロードし、どんな Web ブラウザからでもそれを起動すること ができてしまう。現在、WebSTAR 2.0 では、普通のセキュリティ方法でロッ クできる特別なフォルダに置かれた CGI だけしか起動できない。最後に、 WebSTAR のユーザー名／パスワード用データベースは現在何万人ものユー ザーをサポートしている。
新しい技術については、WebSTAR 2.0 は Java 仮想マシンを内蔵している。 そのおかげでプログラマは CGI やプラグインを Java で作成できる。性能 は C で書かれた CGI やプラグインと同等ではないが、開発時間はより短 縮でき、Java 特有の技術を使うことができる。Java プログラムの安定性 と性能についての心配は、WebSTAR の仮想マシンが全くインターフェース に関わらないのでかなり小さくなる - Java ベースの CGI やプラグインは サーバレベルでデータを扱うためだけのものだ。
新しいバージョンは標準的な“サーバ側インクルード”機能を持っている。 これは HTML ドキュメントに動的なページを創作するための特別なタグを Web ページ制作者に埋め込むことができるようにするものだ。NetCloak や CometPage のような非常に多くの製品がすでにこの目的のためにあるが、 WebSTAR のサーバ側インクルード機能は他の CGI またはプラグインをコー ルすることができ、ユーザー定義のタグを使うことができる。
プラグインといえば、StarNine 社は WebSTAR 2.0 に重要なプラグインを いくつかバンドルしている（上で挙げた機能のいくつかはプラグインでも 実装されている）。その中でも最も有用なのは、私の考えでは、ログファ イルを“巻く”ものである。ログファイルを新しい場所にコピーし、もと のものをリセットするものだ。Web 管理者は Star Trek のようなインター フェースを持つリモート管理プラグインや Web ブラウザからではなくサー バから電子メールを送るプラグインを賞賛するだろう。
アップグレード料金は、1996 年 12 月 31 日まで企業ユーザー向けには 149 ドル、教育関係ユーザー向けには 99 ドルである。新しいパッケージ は 499 ドルという価格に据え置かれている。
<http://store5.starnine.com/upgrade/upgrade.html>
MultiHomie を使う -- WebSTAR 2.0 の別の改善点は HTTP 1.1 のホスト ヘッダ情報にアクセスすることだ。このサポートの関係はサードパーティ のプラグインが WebSTAR により境界のないマルチホーミングを提供するた めに機能できていることによる。以前は、Open Door Networks 社の HomeDoor が Macintosh 上では最良のマルチホーミングのための製品であっ た。しかしユーザーの Web ブラウザに現れるマシン名がユーザーがタイプ した URL の名前と同じでなかった。ClearInk 社の 75 ドルのシェアウェ アプラグインである（サイトライセンス可能）MultiHomie は、この問題を 持たず、ホストのヘッダ情報を送るのに十分に新しい Web ブラウザに適切 な URL を返す。真のマルチホーミングが Mac 上で欠如しているという点で やかましく不平を言うあらゆる人にとって、WebSTAR 2.0 と MultiHomie の組み合わせは検討する価値がある。
<http://www.clearink.com/fun_stuff/plugins/multihomie/>
Open Door 社の戦略 -- WebSTAR 2.0 のリリースに対して、Open Door Networks 社は WebSTAR 2.0 にアップグレードする人を対象に（1997 年 3 月 1 日までの）特別価格を発表した。HomeDoor、LogDoor（リアルタイ ムでログを解析するアプリケーション）および MailDoor（Apple Internet Mail Server に複数ドメイン機能を追加する）の価格を 40 ドル引き下げ て 80 ドルにするという。加えて、Open Door 社は 1997 年の第 1 四半期 に MultiHomie のトランスペアレント・マルチホーミング機能を提供する という HomeDoor の新バージョンを発表した。
<http://www.opendoor.com/wsupgrade.html>
Microsoft 社、Personal を得る -- 驚くべき動きとしては、Microsoft 社と ResNova 社は、Microsoft 社が ResNova 社の Web サーバ製品、パー ソナル Web サーバ WebForOne とそのフル機能版 Boulevard、を獲得した と発表した。それに関連して、社長の Alex Hopmann、プロダクトマネジャ の Lauren Antonoff を含む ResNova 社の社員 5 名が San Jose の Microsoft 社の Internet Platform and Tools division に移籍した。ま た、ResNova 社は自社の NovaServer 電子掲示板システムの買い手を探し ている。
Microsoft 社は WebForOne のベータ版を Personal Web Server と改名し てリリースする計画である。Personal Web Server には最終的に Microsoft Internet Explorer がバンドルされるだろう。これは普通でないように思 われるかもしれないが、Microsoft 社がすでに Personal Web Server for Windows 95（Microsoft 社のネーミングの創造性にはびっくり仰天だ！） と名付けられた無料の Windows 95 製品を持っているのだから、それはお なじみのやりかたなのだ。Microsoft 社は Mac 用のフル機能版 Web サー バをリリースする計画はないと主張している。
私は何度か個人的な Web サーバについて話してきているが、この動きから この分野の競争がいっそう過熱するのではないかとみられる。Apple 社は RushHour graphics Web server の開発元である Maxum Development 社と Mac OS に同梱するための個人用 Web サーバを開発する契約を結んだ。 StarNine 社は Personal WebSTAR のベータ版を所有している。これは基本 的には Chuck Shotton 氏のオリジナル MacHTTP を現在の規格に合わせた ものである。そしてもちろん、Mac 用の多数の Web サーバがある。これに は、Peter Lewis 氏の 10 ドルのシェアウェア NetPresenz や Chris Hawk 氏の無料の Quid Pro Quo がある。これは料金だけが個人的 Web サーバで あると考えられるだろう。
<http://www.maxum.com/>
<http://www.starnine.com/software/software.html>
<http://www.share.com/peterlewis/netpresenz/index.html>
<http://www.slaphappy.com/>
私は以下のことを希望したい。上述の個人用 Web サーバのメーカーが、文 書の翻訳や専用線を使わないインターネット接続に有効に使えるような個 人用 Web サーバに傾注するようになってほしいのである（ TidBITS-316 および TidBITS-318 を参照）。それはいくつかの革新と単なる Web 広告 主義ではないものを目にする好機である。
by Matt Deatherage <mattd@gcsf.com>
（翻訳：杉浦 雄一郎 <yuichiro@activewave.com>）
（翻訳：高島 均 <hitak@can.bekkoame.or.jp>）
（翻訳：尾高 修一 <odaka@iprolink.ch>）
最近のほとんどの Apple 社首脳陣によるスピーチにおいて、HotSauce と 呼ばれる技術研究（当初は Project X と呼ばれていた）について触れられ ている。HotSauce は、共通のテーマによって記述することのできるデータ の集まり（Yahoo による Web サイトの分類や Usenet ニュースグループな どに見られる階層的なデータの集まり）を移動可能な 3D 空間として表現 するものだ。
Apple は昨年から HotSauce を御披露目していたのだが、ここに来て Apple 首脳陣は HotSauce を単に大化けする可能性を秘めたユーザーインター フェースとしてだけではなく、データの閲覧方法を革命的に変えてしまう 基底技術として言及している。さて、HotSauce の凄さはどこにあるのだろ うか。それは 3D による表現方法やブラウザウィンドウ内で表示できる Netscape Navigator プラグインにあるのではないし、HotSauce で使うデー タの作成プログラムにあるわけでもない。それはデータファイルのフォー マット、つまりデータについての情報を記述する方法にあるのだ。Apple はこのフォーマットを MCF（Meta-Content Format の略）と呼んでいる。 この記事では誇大宣伝をフィルターにかけた上で、MCF とデータベースの 関係は、HTML とテキストの関係と相似しているという Apple による最近 の主張に、果たして MCF がどこまで迫っていいるのかを検証することにす る。
メタ・コンテンツ？ ほとんどの人は情報ビジネスが“コンテンツプロバ イダ”と呼ばれることにようやく慣れてきたばかりなのに、今度は“メタ ・コンテンツ”なんて言葉を理解するように求められている。バリバリの ギーク（テクノオタッキー）用語のように聞こえる言葉だが、実はそれほ ど恐れるほどのものではない。
『The American Heritage Dictionary』の定義では、“meta-”という接頭 辞は「超える、超越する、包括的」などの意味となっているが、エンジニ ア達はこの接頭辞をプロセスについて言及するプロセスという意味で使う ことを好む。例えばジョークについてのジョークは「メタ・ユーモア」で、 他の言語を記述するために産まれた言語は“メタ言語”といった具合だ。 このコンセプトは 1979 年ピューリッツァ賞を受賞した Douglas Hofstadter 氏著『Goedel, Escher, Bach: An Eternal Golden Braid』で 詳しく論じられている。この本はエンジアリングまたは科学マニアにとっ ては必読の書だろう。とにかくこの伝統に従うと、メタ・コンテンツは他 のコンテンツを記述するコンテンツということが言える。
MCFという言葉は Apple の R.V. Guha 氏（HotSauce と MCF の両方の責任 者）によって定義された言葉で、コンテンツについての幅広い情報を記述 するための言語を意味する。メタ・コンテンツの簡単な例としては、電子 メールのヘッダが挙げられる。ヘッダによりメッセージに関する情報を得 ることができるが（いつ誰が送ったか、どういう経路で届いたか、返信は どこに出すべきかなど）、ヘッダ自体はメッセージではない。メールを送 る人はヘッダを送りたいわけではなく、メッセージのコンテンツ（内容） を送りたいわけだ。
なぜコンテンツを記述するのか 電子メールのヘッダは電子メールのコン テンツを記述するためのシンプルな 言語 と言うことができる。この目 的においては、言語とは有効な表現を定義するための単純なルールの集ま りを指す。この「有効な表現」ということは、例えば数学における一般的 な言語では“4+4”は有効な表現（式）だが、“76#98+A!”は有効ではな いというのと同じことだ。もし、電子メールにヘッダがなかったとしたら 不便なことだろう。その場合、送信者はメッセージの本文にヘッダ情報を 入れてあげなければならない。さもないと受信者は本文を見も知ないかも 知れないし、署名がなくてはメッセージがどこから来たのか知る手がかり がないことになる（偽署名が使われたらさらに混乱するだろう）。
従ってコンテンツについての記述をするということは有益な作業と言えよ う。実際のところ、メタ・コンテンツのようなものがなければ、大量のコ ンンテンツの海をナビゲートするのは不可能に近い。数百万人という人が Web ページを探すのに、分野・クラス別に使いやすく整理された（独断的 と言えなくもない）Yahoo を使用している。もちろん AltaVista を使って 大量の Web ページをコンテンツで探すこともできるわけだが、コンテンツ による検索は情報をブラウズするのにはあまり有効でない場合が多い。例 えば Macintosh の雑誌（magazine）を探したい場合、Yahoo を辿っていけ ば該当の Web サイトを 30 ほどリストアップしたページに行き着く。しか し AltaVista で“Macintosh magazine”という言葉を検索すると、 Macworld の求人情報、MacToday サイトのページが数十ページ、イタリア 語版 Byte 誌のバックナンバーの記事などからなる40万ヒットほどの検索 結果が返ってきてしまう。未加工テキストの検索機能は数千倍という検索 結果を得られるのだが、それは Yahoo の限定的な情報ほど有益ではないの だ。
<http://www.yahoo.com/>
<http://altavista.digital.com/>
ひとたびあるコンテンツへの適切な記述がなされれば、そのメタ・コンテ ンツは、効果的かつ効率的に検索することができ満足いく結果を生むだろ う。大きな問題点は、今までのところ、人間からでなければ適切なメタ・ コンテンツが生み出されないことだ。この点においてテクノロジーは進歩 してきている - Apple は Macworld Boston でテキスト書類からその要 点を一つの文に抜き出す技術のデモを行った - ものの、いまだ人間のほう がはるかに上手にやってのけるのである。出版社が図書館司書の一助とし てその本の蔵書カード目録への記載事項を提供することはよく行われてい る - これがなければ図書館ではカバー広告や目次から本の内容を知るしか なく、実際に本を読み適切に目録を作成する司書を雇えるだけの十分な資 力を備えている図書館はまれなのである。
同様に、Web の出版は Web ページの要約を自ら行う方向に向かっている。 偽る気持ちがなければの話だが、作者本人の方が Yahoo にいる誰かよりも より正確に自分のぺ−ジを 25 語で記述できるだろうし、テキスト検索シ ステムなどよりははるかに正確にできるはずだ。HTML 3.2 規格には META という予約語が含まれていて、これを使えば Web ページにメタ・コンテン ツ情報を加えることができ、自動索引作成やその他のメタ・コンテンツ作 成作業が容易となるのだ。
<http://www.w3.org/pub/WWW/MarkUp/Wilbur/>
だがどうして MCF なのか？ -- 個々にそれぞれが作成したメタ・コンテ ンツでも有用なものではあるが、何十万にも及ぶ一連のコンテンツを記述 するとすれば何か規格というものが必要となるだろう。蔵書カード目録の 例をコンピュータ化する場合で考えてみよう。ある本のカードを見たとき カード上ではその本に 27 人の著者がいる（恐らくは名作選だろう）こと を簡単に見つけることができる。その情報をデータベースに入力しようと するとして、ところがそこにはわずか 3 人分の「著者」欄しかないとなる と、そこではたと困ってしまう。24 人分の著者を無視するか、それらを例 えば「説明」欄のような無関係なところに入力するかしかないのである。 いずれにせよ、それら 24 人の著者名からの検索は失敗に終わるだろう （著者名に対して説明欄を検索する人などいるだろうか？）。大規模なメ タ・コンテンツ・システムは、柔軟でなければならない。実際、議会図書 館で使用されている MARC 形式はタグ付のデータで構成されていて、あら ゆる個々の登録物について好きなだけ著者タグと著者名を持たせることが でき、その制限は個々のコンピュータの記憶容量のみである。
それならば Web のコンテンツの記述についてもまた MARC のような既存の 形式を用いればよいのではないか？ MARC は開かれた規格ではない。それ ぞれの登録物が含む内容を差し示すために使われる「タグ」は実際は番号 であって、いくつかの例外はあるが、未発表の番号は MARC 委員会の決定 に留保されている。さらに、MARC の記録はバイナリーデータを含んでい て、人間には容易に解読できないのだ。これに対して、Guha 氏の MCF 形 式はより HTML に近いものとなっている。HTML の場合、Web ページ作者は 自分自身のタグを考案することができる。あるブラウザがそのタグの解釈 法を知らない場合でも、単にそれを無視するだけである。ブラウザが解釈 できさえすればそのページ上にしゃれた新機能を盛り込むことができるの だ。Netscape 社は Navigator のリリースに際してほぼ毎回こうしたタグ の拡張を行っている。
Apple は MCF が同様に受け入れられることを望んでいる。それはオブジェ クトやその特性を定義する簡素でテキストをベースとした形式である。オ ブジェクト個々について記述する特性の種類に制限がなく、すべての特性 を記述する必要やすべてのオブジェクト間の関連を含ませる必要もないの だ。HotSauce での MCF の実装はオブジェクト個々について 2 〜 3 の特 性を扱っているのみで、これらは“親”オブジェクト、“子”オブジェク ト、親オブジェクトとの関連にしたがって子オブジェクトを 3-D インター フェース上のどこに配置するかであって、単にそれだけである。下記の URL で MCF に関する白書を入手できる。
<http://applenet.apple.com/hotsauce/text/mcf.html>
Apple は MCF をインターネットにおけるコンテンツ記述の規格として検討 するよう Internet Engineering Task Force （IETF）に提示していて、筆 者は同じレベルに至っている対抗馬の存在を知らない。仮に IETF が MCF を規格として認めたならば、ひと揃いの標準的な記述データ属性（“名称” や“URL”のような共通的なものや恐らくは“説明”、“作者”、その他の 類似タグなど）を想定することができるが、さらに特別なデータを含むこ ともできるだろう。
MCF は何をしてくれるのか? -- これを読みながら今にも「ふん。たいし いたことないな」と言いたいと思っている方のために付け加えておくと、 規格というものはたいていつまらないものなのだ。おもしろいのはそれを もとにしてできることなのだ。
HTML を思い浮かべていただきたい。テキストがどう見えるべきかを別のテ キストを使ってマークアップするというのは、まあ、馬鹿げたアイデアだ。 これはテキストのスタイルを示すには決してコンパクトな方法とはいえな い（<STRONG> タグが複数の文字を必要とするのに対して、“太字”という コマンドは 1 バイト未満で表すことができる）。HTML ソースは読みにく いうえ、高度なページ記述には向いていない。
しかし、HTML はコンピュータが簡単に処理することができるし、すでにご 承知の通り拡張も可能で、あるページの語句と別のページの語句をリンク するハイパーテキストの可能性が Web ブラウザの登場につながり、それが 今日の World Wide Web へとつながったのだ。これはなかなかたいしたこ とといえる。
MCF も同じ特徴を備えている。作成するのも使うのも簡単で、コンピュー タにも楽に扱うことができる。私は MCF によって記述されたデータの集合 体をナビゲートすることができる MCF“ブラウザ”（ほかに良い言葉がな いので）プログラムが現れると予想している。Apple の HotSauce Web サ イトにはこのような MCF ファイル集が多数用意してある。この MCF ファ イル集は以前の Project X というコードネームに由来する“X Space”と いう名前がついている。Apple の Netscape 用 HotSauce プラグインがあ れば、Web ブラウザでこれらの X Space の中を飛び回ることができる。
<http://applenet.apple.com/hotsauce/>
また、スタンドアロンの HotSauce アプリケーションをダウンロードして X Space を眺めることもできる。これには最近プラグインに追加された 3D 方式と 2D の Finder 風ビューを選ぶことができる。後者は Finder のファ イル名表示のように、フォルダとクリックすると中身を表示する三角形を 備えている。データを記述している MCF ファイルそのものには変更はな く、プログラムが表示する方法が異なるだけだということに注意していた だきたい。
この点が最も重要な部分だ。一つだけの形式で大量のデータを記述すれば、 後はプログラマーが考え付くかぎりの方法でデータを表示することができ る。現在の HotSauce のビジュアルなインターフェースは、3D レンダリン グの時代においては特に目を見張るというものではないが、これは単にデー タを見る一つの方法にすぎないのだ。同じデータを見るために別のインター フェースを作ることは比較的容易だ。
もしあらゆる Web サイトがサイトそのものの構造を MCF で記述していた ら、どんなサイトでも中を飛び回り、最も意味のある情報だけを探し出す ことが可能になる。そのために必要な情報を盛り込んでいるかどうかわか らないサイトマップを使う必要はなくなる。（そもそもサイトマップが使 い物になるかどうかも問題だ。Web サイトマップの中には情けないほど不 適切なものもある。）また、サイトが Finder のウインドウでもあるかの ように探すこともできる。MCF を表示する Live Object があれば、この機 能をどんな OpenDoc コンテナにも加えることができる。
同じ MCF ブラウザ／ビュワー OpenDoc パートで自分のハードディスクや Yahoo の Web ページ集、それに MCF で記述してあるあらゆる Web サイト の中を見ることができるのだ。MCF で記述されているデータベースでさえ 見ることができる（巨大データベースを自分のハードディスクのように見 ることができるのだ!）。つまり、ほとんど何でも見ることができるように なるのだ。
Apple の首脳陣が HTML がテキストに対して果たした役割を MCF はデータ ベースに対して果たすと言っているのはこのためだ。もし世界全体が IETF 規格なり何なりで MCF を採用したら、これは本当になるかもしれない。
競合するメタ・コンテンツ規格 -- ほかにもコンテンツを記述するため の規格を作る動きはあったが、いずれの場合も Apple のような企業の後ろ 盾はない。しかも、Apple の MCF 発案者、R.V. Guha 氏は、暫定規格を 持っている Dublin Core グループをはじめとして、同様の可能性を調査し ている各種委員会の活動をふまえて MCF を提唱しているのだ。MCF はまだ 幼いが、Dublin Core グループは図書館の目録に近い構造になっており、 もう少しアカデミックな傾向を持っている。シンタックスを定義する作業 を行えば、Dublin Core の持つ利点が MCF で表現できないことはないと Guha 氏の白書は述べている。
Microsoft 社の Nashville プロジェクトは? Nashville というのは Microsoft 社の“Internet Add-On Pack”のコードネームで、Windows 95 と Windows NT 用に間もなく出荷される見通しだ（最近では“Active Desktop”とも呼ばれているらしい）。これは業界各誌では「ブラウザをオ ペレーティングシステムに内蔵」するものといわれており、ハードディス クをハイパーリンク付きの Web ページとして表示する方法を持っていると されている。私が調査した限りでは、まさにそのとおりらしい。
Nashville にできないことは、Web ページとハードディスクの両方の内容 をメタ・コンテンツ形式で記述し、MCF 的な技術を使って両方を眺めるこ とだ。Nashville は Microsoft Internet Explorer 4.0 と一部コードを共 有することによって、Windows の desktop プログラム（いわば Windows 版 Finder）に代わる（あるいは追加する）ものなのだ。もう少し馴染みの ある Macintosh 用語で説明すると、Nashville では、Web ブラウザが別の ブラウザプログラムを起動することなく Finder で Web のウインドウを開 くことができ、ファイルのアイコンや Finder のウインドウだけでなく、 ライブの Web コンテンツをデスクトップに表示することができるのだ。Web ページや文書に Finder 風のフレームを埋め込むこともできる。
Microsoft は ActiveX コントロールを使うことによって、メタ・コンテン ツ・フォーマットを使わずにファイルやフォルダを Internet Explorer の ウインドウ内に表示するという方法を取っている。ブラウザそのものはハー ドディスクのことは何も知らず、単に ActiveX を知っているだけで、ハー ドディスクのことを知っている ActiveX コンポーネントを持っているだけ なのだ。（さきほどの例で言えば、OpenDoc は MCF のことは知らず、MCF Live Object があらゆる OpenDoc 文書にその機能を与えることができる− これが Microsoft が Nashville で ディスク用 ActiveX コントロールを 使ってやっていることだ。）
Nashville の技術はなかなか良い。しかし、将来の Macintosh の OS は OpenDoc によってこれよりも先に進むことができる。というのは、OpenDoc はどんな Live Object でも埋め込むことができるが、Nashville は Web ブラウザのウインドウやフレームに ActiveX コントロールを埋め込むこと しかできないように見受けられるからだ。（たとえば、Microsoft の説明 を読んだ限りでは、Web のコンテンツを埋め込んだ大きなスプレッドシー トを作ることはできないが、スプレッドシートのコンテンツを埋め込んだ 大きな Web ページを作ることはできる。）
Nashville は IETF が MCF を本格的に検討する前にリリースされるだろう が、この 2 つは競合する規格ではないため、世間一般の認知度以外に特に 問題にはならないだろう。Microsoft は MCF に対抗しようとはしておら ず、もし MCF が成功すれば、多分その他のインターネット関連企業ととも に採用するだろう。
データへのアクセスはもはや問題ではないが、利用価値のあるデータを探 すことは情報源の拡散とともに極めて困難になってきている。MCF は成長 しつつあるインターネットを多少なりとも手に負えるようにしてくれる可 能性を秘めており、なぜ Apple が興奮しているかが私には理解できる。
[この記事は Macintosh の世界のニュース、製品やイベントをカバーする 日刊の Macintosh パブリケーションである MDJ からの転載だ。Mac に関 する示唆深いニュースが足りないと感じている方は、MDJ の無料お試し購 読をお薦めしたい。無料の setext 版または Acrobat PDF 版の MDJ Recap #1 については、<http://www.gcsf.com/> にある MDJ Web サイトをご覧頂 きたい。]
非営利、非商用の出版物およびウェブサイトは、フルクレジットを明記すれば記事を転載またはウェブページにリンクすることが できます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありませ ん。書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017
｜ 
｜ 