古城ホテル、シャトー・ウイスラーに進化はあるか 山崎俊一 2000/12/26

---

Happy New Year！！
ついにとうとう21世紀だって。
地球誕生から45億年。人類誕生から50万年かな。
よくも今日まで生き延びてきたものだと、心からお祝い申しあげます。
そういうタイミングでMicrosoft.NET（マイクロソフト・ドットネット）が登場するというのも不思議というか、興味深いことです。

PC「じゅうねん」周期律

　「十年一昔」って言葉がありますが、今から10年前、1991年といえば、Windows 3.xが登場し、ようやく32bit時代がスタートした節目の年。その後、NTが登場し、Windows 95が続き、インターネット爆発で今日に続いています。

　その1991年以前のPCは、16bitのMS-DOSで、キーボードをたたいて動かす時代でした。そのMS-DOSの誕生は、さらに10年前の1981年、IBM-PCと同時でした。

　1981年、1991年ときて、次は2001年。この10年周期律が正しいとすれば、次は.NETの10年でしょうか。

年	出来事と時代
1981年	いわゆるPCの誕生　→　DOSの時代
1991年	Windows登場　→　Winの時代
2001年	たぶん.NET登場　→　.NETの時代？？？
PC「じゅうねん」周期律

ウイスラーでぶっ飛ばせ

　現Windows 2000の次世代OS、そのまた次世代OSとして開発が進められているOSの開発コード、Whistler（ウイスラー）／Blackcomb（ブラッコム）とは、北米トップ・クラスのスキー場、Whistler−Blackcomb（カナダ・ブリティッシュ・コロンビア州）の名前です。ウイスラーとブラッコムという2つの山が並び、ブラック・ダイヤモンド（難度を示す◆印）続々のエクストリーム・コースから自然満喫の氷河ツアーまで楽しめます（詳細はWebページをご覧ください）。

　物理的なロケーションはバンクーバーの東、車で約2時間。成田、関空からでも10時間くらいの直行フライトなので、日本人スキー客もたくさん訪れます（ぼくも）。Microsoftがあるシアトルからも車で半日の距離で、ペンションでMicrosoftの開発者と同宿になったこともありました。

　上記Webページには、気温、雪質などのリアルタイム情報から、オンライン宿泊予約などひととおりが揃っています。ただ残念なことに、ウイスラーきっての定番ホテル、シャトー・ウイスラーは掲載されていません。リンクもありません。

Webサーファー絶滅への方策

古城風ホテル、シャトー・ウイスラーのホームページ

　シャトーは、ヨーロッパ古城風の女の子なら泣いて喜ぶ豪華ホテルで、しかも、冬季はバーゲン価格です。なのに掲載されていないという不条理の原因は、経営母体が違うから。フェアモント・ホテル・チェーンのページを自分で探して辿ることになります（シャトー・ウイスラーのホームページ。以前は同名の航空会社を含むカナディアン・パシフィック・グループ系列でした）。

　これってよくある話で、苗場プリンス vs. 民宿協会みたいなことかもしれません。地元資本としては、外様巨大資本を宣伝する理由はないのでしょうが、利用者には不便です。そのしわよせでもって、検索術とかWebサーフィンとかいってURLを探し回るのも、手間、ヒマの浪費でしかないと、ぼくには思えるのです。

　で、ちょっと整理してみます。

　異なる企業の、一見すると異なるWebページ上に、実は同種の情報が掲載されているとします。ホテルの料金でも株価でも話は共通です。

　それらを比較しようと思えば、第3のHTMLページを作り、<table>などとしてデータを並べることになります。愚かしいなあ、と誰もが思いつつ、その繰り返しで膨大なネット資源を費やし、でも実際、それで結構なビジネスが成立してしまったり、それがまたIT最先端などともてはやされてみたり、といったところが現状です。

じゃあ、どうするべえ？

　明らかに、ベターなソリューションは、データと表現の分離でしょう。

　Webページが宣伝、競争の場である以上、ページ自体の共通化は意味がありません。だけど、読む側では、たとえば料金とか施設とかゴンドラへの距離だとか並べて比較したいものです。そこで、ホテル業界あるいはスキー業界でそれぞれ共通の汎用データ構造を定義し、これに基づいたデータを公開することで、ページの束縛から独立できるはず。つまり、XMLです。

　理想を言えば、ひとつの画面に、シャトーと地元経営のコンドミニアム（ジャグジー付きメゾネット・スタイルなどが多い）の両方の部屋写真と料金を並べて見て決める、といった見方できるといいですね。そういうHTMLページは、ユーザーからアクセスがあったときに、それぞれのXMLレコードから生成されるのでしょうね。

　ついでに「◆◆◆（ブラック・ダイヤモンド×3個）」以上のコースだけ探すとか、Web検索のスタイルも変わることでしょう。現状、ただのプレーン・テキスト検索の限界は言うまでもありません。

　なんか駄法螺（だぼら）みたいですけど、でも「XMLが次世代Webの核心だろう」というのは、ほぼ業界の共通認識で、だから今、XMLは猛スピードで普及が進んでいます。なかでも（よくも悪くも）台風の目は、Microsoft.NETのXMLサポートです。

パッケージ・アプリケーションの終焉

　では、XMLはデータ互換、汎用性の玉手箱なのでしょうか。

　XMLが記述し、解析対象とするのはXMLのテキスト・データです。これは、文字どおり「文字どおり」の文字の並びで、そうであることが汎用データ交換を保証しています（これはSGML以来の伝統です）。

　また、そのデータ構造、つまり文書の種別はDTD（Document Type Definition：XMLドキュメントのデータ・エレメントを定義するドキュメント）として定義されます。だから、内容が何であれXML文書は拡張子.xmlファイルです。それ以外の内容を含む場合、たとえば画像ファイルはこんな書き方で解析対象外の外部実体とします。

<!ENTITY whistlerMovie         SYSTEM "../pivture/whistler.mpg"         NDATA mpg >

　この場合、XMLパーサは何もせず、ただ、アプリケーションに通知するだけ、その処理はアプリケーションの責任です。

　したがって、ファイル名の拡張子で文書の種別を固定したり、テキスト中に制御コードを埋め込んだりするMS-DOS時代のスタイルは、もうおしまいで、パッケージ内で閉じた構成も不都合です。なぜなら、DTDや外部実体は（ネット上あるいはローカルな）URLに置かれ、常に拡張、追加、変更可能というのが前提だからです。

　たとえば、上記で「NDATA　mpg2」ときたらどうするか。

　直裁に言えば、XML汎用アプリケーションはネットワーク上で拡張可能であるべきで、Web上のMPEG 2サービスを呼び出す、といった形でしょう。さらに、文書種別となると、ホテルだスキーだスノボだ飛行機だと、何でもかんでも無数に作れますから、パッケージ型アプリケーションの終焉、限界は言うまでもないことです。

とは、言うけれど

　以上、出発点は.NETでしたが、Web利用に限ってみればWindows 2000もほぼ共通で、すでにXMLエンジンが搭載されています。ただし、MSXML.DLLのCOMインタフェースで、OS上の拡張サービスをIEが呼び出す形なのですが、これを.NETは包含するとのことです。

　そんなこんなで、10年周期律の節目に.NETが登場してきたことに、なるほどと感じているワタクシなのですが、ただし、XMLの普及は時間がかかるという指摘もあります。ぼくだって、もし民宿協会の立場なら、そんなもんいらん、HTMLで何が悪い、と言うかもしれません。閉じておく方が好都合という判断もありますよね、確かに。

　困っちゃった。原稿が終らなくなっちゃった。そのへんはまたよくよく考えて、次回に書かせてもらいます。

---

山崎俊一（やまざき しゅんいち）
CD-ROMの標準化やSGMLの標準化作業に参加。ドキュメンテーションとコンピューティングの接点で古くより活躍する。またパーソナル・コンピュータの可能性にいち早く注目し、MacintoshやMS-DOS、Windowsのヘビーユーザーとして、コンピュータ関連雑誌、書籍などで精力的な執筆活動を展開、業界の隠れた仕掛人である。

「Opinion」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）