Jon Bosak, Sun Microsystems
最終改訂 1997年3月10日
日本語訳: 岡部恵造(FXIS)、楠裕行(FXIS)、藤岡慎弥(沖ビジネス)、村田真(FXIS)
世界中の読者に向けて、お金をかけずに簡単に電子文書を配布できることから、World Wide Webは驚くべき成長を示しました。しかし、Webがより大規模で複雑になるにつれて、大規模商用出版のために必要な拡張性・構造・データチェック機能を持たないメディアであるということの限界を感じる人も出てきました。また、Webクライアントに強力なデータ処理機能を組み込むJavaアプレットの能力を生かすためには、現在の文書データの配送方法では限界があるということも明らかになりました。
商用Web出版のための要求に取り組み、分散文書処理の新しい領域にWeb技術を適用するため、World Wide WebコンソーシアムはExtensible Markup Language(XML)を開発しました。XMLは、現状のHypertext Markup Language(HTML)を越える機能を必要とするアプリケーションで利用されるためのマーク付け言語です。本稿[0]は、XMLの開発について述べ、XMLによって可能になる、Javaベースの新しいWebアプリケーションについて論じます。
Web上のほとんどの文書は、HTMLで格納され配送されています。HTMLは、ハイパーテキスト、マルチメディア、小規模でそこそこ単純な文書の表示に適した簡単な言語です。文書の形式を定義/利用するための標準システムであるSGML(Standard Generalized Markup Language, ISO 8879)が、HTMLのベースになっています。
SGMLによって、Web上の文書はそれ自身の”文法”を表現することができます。つまり、文書中で使用されているタグセットや、それらのタグが表している構造的な関係を定義することができます。HTMLアプリケーションは、一つの言語仕様（SGMLによって記述されている”文法”）に従って、小規模の固定されたタグセットだけを使用するアプリケーションです。小規模のタグセットに固定することによって、ユーザは文書から言語仕様を切り離し、アプリケーションを容易に構築できます。しかし、この容易さは、拡張性・構造・検証といったいくつかの重要な点で、HTMLを厳しく制限するという犠牲のもとに実現されているのです。
HTMLとは対照的なところに、汎用的なSGMLがあります。汎用的なSGMLのアプリケーションとは、どんな複雑さを持つ仕様（SGMLで書かれた言語仕様）でも扱えるアプリケーションであり、HTMLでは失われてしまった拡張性・構造・正当性検証といった特質を実現します。SGMLでは、ユーザ自身が文書形式を定義すること、大規模で複雑な文書を扱うこと、大規模情報リポジトリを管理することができます。しかし、SGMLのフルセットは、Webアプリケーションには必要のないオプション機能を数多く含んでいます。SGMLのフルセットは、現在のWebブラウザ・ベンダーにとって費用対効果の面で魅力がないということがすでに分かっています。
World Wide Webコンソーシアム(W3C)は、 SGMLの有益な機能をWeb上で容易で簡単に利用するための一連の仕様を作り上げることを目指して、SGMLワーキンググループを創設しました。この取り組みの現状については、W3CのSGML活動ページ [1]を参照してください。 W3CのSGML活動の目標は、どんな深さや複雑さでも扱える自己記述型のデータ構造であっても、そうした構造を必要とするアプリケーションに配布できるようにすることです。
取り組みの最初のフェーズは、特にWebアプリケーションのために、SGMLを単純化してサブセット仕様を作成することです。XML（Extensible Markup Language）と呼ばれるこのサブセットは、言語としての拡張性・構造・正当性検証といった重要な利点を維持したまま、SGMLよりも学習や実装がずっと容易であるように設計されています。
以下の3つの大きな点でXMLはHTMLと異なっています：
XMLの設計目標は、もっとも表現力に富み、もっとも教えやすく、実装がもっとも容易であるようにすることです。言語は、既存のHTML文書に対して下位の互換性を持っていませんが、W3CのHTML3.2仕様に準拠した文書は、SGML文書やデータベースから生成された文書と同じように、容易にXMLに変換することができます。
公開の議論のために、XML1.0の最初のワーキング・ドラフト[2]が既にリリースされています。XML文書にハイパーテキストリンクやスタイルシートの機構を関連付けるための方法を含んでいるような完全な仕様は、1997年4月に開催される第6回World Wide Webカンファレンスでリリースされます。（訳注: 1997年6月の時点において、ハイパーテキストリンクのドラフトは存在するが、スタイルシートの部分は存在しません。）
XMLが受け入れられていくのは、HTMLの制限された世界では実現できないアプリケーションが存在するからです。そのようなアプリケーションは、大きく四つのタイプに分けることができます：
こうしたアプリケーションでも、XML以外の選択肢がないわけではありません。HTML文書中に「スクリプト要素」としてベンダー固有のコードを埋め込み、ベンダー固有のブラウザ・プラグインやJava appletと一緒に配送するという選択肢です。しかし、XMLを支える哲学では、データはそれを作成した人に属していると考えています。情報を提供する人は、特定のスクリプト言語、オーサリング・ツール、配布エンジンに縛られるべきではありません。標準化されていて、ベンダー独立で、公平な球技場（市場）を提供するデータ形式を使えば、最も大きな恩恵を受けることができます。この市場では、さまざまなオーサリングツールや配布ツールは自由に競争するでしょう。
家庭での健康管理に関する連邦機関のための情報システムが、最初のタイプのXMLアプリケーションの例です。
家庭での健康管理は、数十億ドルに及ぶアメリカの医療産業の中心的な部分であり、健康管理の比重が病院から家庭での治療へと移行するにつれて、その重要性は増し続けています。患者の治療費用を負担する連邦機関と健康管理組織は、記録管理を要求しているため、この業界では情報管理が必須となっています。
家庭での健康管理に関する連邦機関に加入しているふつうの患者は、患者の医療履歴および医師・病院・薬局・保険会社からの請求書データの二つの形で収集される大量の紙ベースの履歴資料として、情報システムに入力されます。これらの資料を連邦機関のデータベースに手入力することが、患者をシステムに登録するときの最大の作業となっています。
医療情報にかかわる人たちは、 Webの登場によって、この負担を軽減するような電子的な手段が見つかるかもしれないと考えました。残念なことに、既存のWebアプリケーションのモデルは、満足のいくソリューションを構築するには本質的に不十分なものでした。病院は、政府機関に対して次のようなソリューションを提供しはじめました：
知識のある読者は、この“ソリューション“を笑うでしょう。しかし、実際にこれは冗談ではないのです。これは、高度な医療情報システムを早くから採用していることで知られている米国のある大病院からの実際の提案なのです。
この“ソリューション“をもう少し精巧にしたバージョンを考えてみましょう。まず印刷出力をするのではなく、オペレータがWebブラウザから患者データを読み取って、別のウィンドウにある、政府機関が提供する帳票ベースのインタフェースにオンラインで直接キー入力するというのはどうでしょうか。このバージョンと前のものとの唯一の違いは、印刷出力に必要な紙を節約していることです。問題の核心への取り組みは何もなされていません。本当のソリューションは、次のようになるでしょう：
しかし、このソリューションは、以下の三つの理由により HTMLの制限のもとでは実現不可能です：
患者の治療記録をスムースに交換する方法として、技術的には可能なものが一つあります。それは、すべての病院と健康管理局に、政府によって押し付けられた単一の標準システムを使うように要求することです（実際にこのようなアプローチが提案されました）。しかし、営業を停止する病院が毎日のようにあり、多くの健康管理機関が深刻な財政困難に陥っているいま、すでにある多様なシステムをただ一つの新システムにリプレースせよと要求するような計画は、まったく現実的ではありません。
異なるシステムの間での交換を可能にするもう一つの方法は、業界統一交換形式を採用し、データを送り出すすべてのシステムの単一の出力形式、データを受け取るすべてのシステムの単一の入力形式として用いることです。事実、これこそがもともとSGMLが設計された目的であり、XMLはこの伝統を引き継いでいるのです。
航空、通信、コンピュータ業界といった多くの業界が、データ交換を実行するために共通交換(Hub)言語を長い間、利用してきました。そのためのプロセスは、これまでによく理解されています。普通、業界大手は、標準コンソーシアムを編成して、文書型定義(DTD)を開発します。DTDとは、タグセットやマーク付け言語の文法を定義する方法です。このDTDは、売れ筋の編集ツールを使って業界標準言語でマーク付けされた文書と一緒に送信されますので、データを受信する標準アプリケーションは、文書の正当性を検証してから処理することができます。
XMLソリューションは、システム独立、ベンダー非依存であり、10年以上のSGML実装の経験によって有効であることが証明されています。XMLは、この有効性が証明された手法を、Web上のデータ交換に拡張しているだけに過ぎません。面白いことに、XML1.0の最初のドラフトがリリースされたのと同じ日に、健康管理ソフトウェア%ベンダーの標準組織であるHL7が、この例で取り上げた問題を確実に解決するために、SGML推進組織を設置して、健康管理マーク付け言語を開発するという発表をしました。
これまで各業界で行われてきた取り組みでは、機能豊富なマーク付け言語でデータを取り込むことが、データを交換するという直接の要求以上の利益をしばしばもたらすということが分かっています。例えば、上手に設計された標準の患者データシステムでは、日常の健康診断でもともと収集される情報が、<アレルギー>とか<薬品反応>のようなタグを付けて管理されており、遠方の街から担ぎ込まれた意識不明の患者にペニシリンのアレルギーがあるということを救急医療室のスタッフに警告することができるようになるでしょう。このシナリオでは、アプリケーションの領域ごとに固有のタグが定義できるというXMLの能力が必須です。なぜなら、何千ページという患者の医療履歴全体の中で、「ペニシリン」という言葉がどこかに現れるというだけでは充分ではなく、<アレルギー>という要素の中に現れてこそ、警告を出すことができるからです。
この健康管理の例は、問題が広範囲に及び、巨額のお金がからむというだけで重要なのではなく、たいへん広い範囲の将来のWebアプリケーションのパラダイムの例になるからこそ重要なのです。そのようなアプリケーションでは、異なった形式でデータを内部的に表現するシステムの間にWebクライアント（あるいは、クライアント上で動作するJavaアプリケーション）が介在することによって、情報の欠落のないデータ交換が可能になることでしょう。そのようなデータ交換方法は、業界やその他の団体で標準化できます。このようなアプリケーションの例を手当たり次第に挙げてみます:
二番目のタイプのアプリケーションの例は、半導体業界によって設計されたデータ配布システムです。
大手の各半導体製造業者は、製造しているすべてのICについての数テラ・バイトにもおよぶ技術データを維持しています。このデータの交換を可能にする、業界専用のSGMLマーク付け言語を設計するために、業界コンソーシアム（Pinnacles Group）が数年前にIntel、National Semiconductor、Philips、Texas Instrument、日立によって結成されました。コンソーシアムは、1995年にその仕様を完成し、会員会社はプロセスの実装フェーズにいま取り組んでいます。
人によっては、HTMLの人気が高まるにつれて、Pinnaclesの会員はその方向を見直すだろうと思うかもしれません。しかし、実際には、会員はHTMLの限界を理解しており、最初の戦略に間違いはなかったと確信しています。業界専用のSGMLマーク付け言語を作り、豊富なパラメータを持ったデータ・ストリームとして半導体についてのデータを表現すれば、判読可能な文書としてデータをたんに表示するだけではなく、設計プロセスを高度化するインテリジェントなアプリケーションが可能になるだろうというのが、彼らの元々の考えでした。この手法が分散Java appletの概念ととても相性のよいものであるということが最近分かってきました。近い将来には、技術者が製造業者のWebサイトにアクセスし、特定のICについての表示可能なデータだけをダウンロードするのではなく、これらの回路をさまざまに組み合わせたときのモデル化をするJava appletをダウンロードできます。
半導体アプリケーションは、XMLの利点を示す良いデモンストレーションです。なぜなら：
ときには重要な正当性検証も、この種のアプリケーションでは必ずしも重要とは限らないことに注意してください。これは、アプリケーションのほうで、データが構造上完全であるということをデータベースに入力する前にチェックしているからです。可能な限り効率的に処理するため、正当性検証を必要としないアプリケーションでは、検証をオプションにできるように、XMLは設計されています。
ヘルスケア（健康医療関連産業）の例のときもそうですが、半導体アプリケーションが重要なのは、単にその市場が大きいからというだけではありません。巨大な広がりをもつ、Javaベースの将来のWebアプリケーションの事例となっているからこそ重要なのです。標準化されたデータをクライアント上で面白い方法で操作するようなアプリケーションのほとんどすべてがこのようなアプリケーションです。おそらく、そうしたアプリケーションのもっとも明らかな例は、次のようなものでしょう：
この最後のタイプに分類されるアプリケーションの先駆者的存在が、 SGMLマーク付け言語、「ソリューション交換標準（Solution Exchange Standard）」です。これは、昨年6月に60社以上のハードウェア、ソフトウェア、通信業界の会社が参画するコンソーシアムによって発表された標準で、ベンダー、システム・インテグレータ、企業内のヘルプ・デスクが技術サポートについての情報をお互いに円滑に交換することを目指しています。その発表の中では次のように述べられています。
この標準は柔軟であるように設計されてています。この標準は、どのようなプラットホーム、ベンダー、アプリケーションにも依存しないので、データを送受信するシステムがなんであるかに関係なく、ソリューション情報の交換のために利用することができるます。[...中略...]さらに、この標準は将来長期にわたって利用されるように設計されています。SGMLは成長や拡張の余地を提供してくれるので、この標準は、急速に変化するサポート環境に容易に適応できるのです。
このようなアプリケーションは、SGMLのサブセットとしてXMLを設計するとき特に重要視されています。データを操作するアプレット間のインターオペラビリティを一般消費者が期待するようになればなるほど、また、大量の計算を必要とする仕事が自分のWebサーバ上で直接サポートするという現実に情報プロバイダが直面すればするほど、このようなアプリケーションの重要性はますます増大していくでしょう。
XMLアプリケーションの三番目のタイプは、データをWebサーバから別の書式で再度ダウンロードしなくても、データを別のビューに切り換えてユーザが表示できるようなアプリケーションです。
このタイプのアプリケーションでまず最初に作られたものの一つが、ダイナミックに生成される目次です。今なら、オブジェクト指向データベース上に構築されたWebサーバを使って、大規模データの目次をユーザに提供することができます。目次の一部分をマウスでクリックすると目次が展開され、より詳細なレベルの文書構造が表示されます。この種のダイナミックな目次は、実行時に文書の階層構造から直接生成させることができます。残念なことに、この目次の展開や収縮時にWebサーバでの処理が必要なため、このプロセスはほとんどのユーザ環境で、うんと遅くなっています。もし、各目次のビューをサーバで生成せずに、構造化された全目次をクライアント上へダウンロードすれば、この問題は抜本的に解決できます。そうすれば、クライアント上で処理を行うことができ、ユーザはより高速に目次を展開、収縮、操作することができます。
Sunのあるグループは実際に、JavaベースのHTMLヘルプ・ブラウザの一部分にこのソリューションを実現したのですが、HTMLに制限があるためこのチームは頭をひねっていくらかの回避策を見つけなければなりませんでした。このアプリケーションでは、非標準のタグを使って目次を手作業で作成しています（通常のHTMLでは構造が欠如しているため、文書から直接に信頼できる目次を生成させることは不可能です）。そしてその非標準なマーク付けがWebのブラウザからは見えないようにするため、目次の部分をHTMLページのコメント中に埋め込みました。そして、HTMLの文書とともにダウンロードされるJavaアプレットが、その隠されたマーク付けを解読し、クライアントベースの目次の機能を提供するようにしたのです。
実際に、このアプリケーションは非常にうまく動作し、その設計者の見事な才能と基本概念の正しさの両方を実証しました。しかし、XMLの環境であれば、目次を手作業で作成することも、それが見えないように隠すことも必要ではありません。その代わりに、標準的なXMLのエディタを使って構造化されたデータ内容を作成し、その内容をもとに実行時に目次を生成できるようにしておいて、ブラウザにダウンロードします。ブラウザは、ダウンロードされたJavaアプレットか、標準セットのJavaHelpクラス・ライブラリのいずれかを使い、目次を自動的に生成して表示します。
XMLでは、意味や構造を持ったデータを取り込んだり送り出したりすることが可能になったため、ユーザは、クライアント側での操作だけでデータをさまざまな形で見ることができるようになります。例えば：
創造力豊かなWeb設計者なら、十分に構造化されたデータをWebのクライアント側に標準的な手段で送ることができるということを、さまざまに活用するでしょう。このリストは、そのための単なるヒントにすぎません。
HTMLで簡単に表現できるものよりもさらに構造化されたデータを、インテリジェントなWebエージェントが大いに必要とするようになったとき、XMLのアプリケーションの未来の領域が拓かれます。おそらく、このタイプの最初の椒?附瘍蜴繞鱸鈑社のMatthew Fuchs氏が、そのようなアプリケーションが必要とする重要な要件をまとめています。つまり、「情報はそれ自身について知っている必要があり、情報は私のことを知っている必要がある」。
500チャネルもある有名なケーブルTVシステムについて、ある一人のユーザのためのTVガイドを作るとしましょう。このようなTVガイドでは、すべてのプロバイダの情報を対象とし、このユーザの好みやその他の特性（教育水準、興味、職業、年齢、視覚の鋭敏さ）が、ベンダーに依存しない標準的な形式で指定されていることが必要になります。（明らかにこれは、業界標準のマーク付けシステムを作るという仕事です）。さらに、このユーザがおそらく最も興味を持つだろうと思われる番組をエージェントが頭脳的に選べるように、番組自体が記述されていなければなりません。この2番目の要求を実現するには、特定の番組の個々の属性（テーマのカテゴリ、視聴者のカテゴリ、主演俳優、長さ、制作日、批評、特集、言語など）を表わす多くの特殊なタグを使用する標準化されたシステムが必要です。情報の選択機能が個々のユーザに合わせてカスタマイズされるような個人向けの新聞やその他多くのアプリケーションに対しても、まったく同様の要求が当てはまります。
こうしたアプリケーションはまだ先の話ですが、私たちの生活でますます重要な役割りを果たすようになることは明らかですし、実現にはXMLのようなデータが必要となることも明らかです。このようなアプリケーションは、相互運用性を持ちますし、オープンな市場においてインテリジェントなWebエージェントは効果的に競争することができます。
XMLの本体以外の部分とはいえ、強力なリンク付けとスタイルシートの機構は、W3CのSGML活動の欠かせない部分です。XMLがHTMLを越えているのと同じく、これらの機構も現在のHTMLベースの方法を越えています。
HTMLという名前やHTMLをとりまくすべての宣伝にもかかわらず、このいわゆる「ハイパーテキスト・マーク付け言語」は、いままでハイパーテキスト・システムの概念と結び付けられてきた機能のうち、ごくわずかの部分を実装しているに過ぎません。最も単純なリンク付け、すなわち文書中に直接書き込まれたロケーションへの単一方向のリンク、に対応しているだけです。これは1970-80年代に構築され、有効であると実証されたシステムとは大きくかけ離れています。
XMLの制定活動の中で想定されている真のハイパーテキスト・システムには、最高水準のハイパーテキストリンク付け機能のすべてをサポートする標準化された記法が存在します：
XMLとともに使用される標準ハイパーテキストの基本メカニズムに関する仕様書の最初のドラフトは、1997年4月の第6回World Wide Webカンファレンスでリリースされる予定です。（訳注: 予定通り、リリースされました。）
現在のCSS（カスケード・スタイルシート）についての活動では、HTMLの比較的低レベルの要求をうまく満足させるスタイルの仕組みを提供しています。しかし、拡張可能な構造化されたマーク付けによって実現可能となった、とても広範囲のレンダリング技術をサポートすることはできません。XMLに対応するのは、次のようなスタイルシート・プログラム言語です：
そのような言語は、「文書・スタイル・セマンティックス仕様言語 Document Style Semantics and Specification Language（DSSSL, ISO/IEC 10179）」という新しい国際規格としてすでに存在しています。1996年4月に公開されたDSSSLは、XML文書の将来のスタイルシート用言語です。XMLのアプリケーションと共に使用されるDSSSLのサブセット[3] の最初の仕様書はすでに公開されています。この仕様書はXMLの制定活動の一つとして、今後もさらに開発が続けられてゆくことでしょう。
HTMLは、簡単な文書を出版するためのマーク付けとして、またダウンロード可能なスクリプト配送用の封筒として、充分にその役目を果たしています。しかし、より多くの情報を必要とする標準化されたJavaアプリケーションに対応するには、標準化され、拡張可能で、構造化された言語と、同じように拡張されたリンク付けとスタイルシートの仕組みを開発していかなければなりません。W3Cは、オープンな標準的環境の中でこうした目標を達成可能にするため、SGML活動の中で一連の仕様書を積極的に開発しています。
著者は、この文書作成の最初に貢献していただいたDavenportグループの同僚に感謝いたします。アプリケーションの実例については、1996年8月23日にシアトルで開催された「GCA情報技術週間」のワークショップ「SGMLとDSSSLのインターネットでの応用」に参加された方々のご協力を得て、明確化し拡張することができました。とくに、Tim Bray、Kurt Conrad、Steve DeRose、Matt Fuchs、Murray Maloney等の各氏による、ワークショップへの絶大なる貢献に対して深くお礼を申し上げます。
この報告書はHTML3.2で書かれ、プリントアウトするためJadeのDSSSLエンジン[4]でフォーマットしました。印刷された節（セクション）番号、ヘッダー、脚注、目次は、HTMLのソース[5]の一部ではなく、DSSSLのスタイルシート[6]によって記述されているように自動的に生成されたものです。
この文書は、XMLの目標を理解する上できわめて重要なものです。ぜひ日本語に訳すべきだということは以前から分かっていましたが、Jon Bosak氏の重厚な文章を日本語にするのは、われわれには実に大変な作業でした。まだ満足のいかない点も多いのですが、できるだけ早く公開すべきだという思いが打ち勝ちました。誤訳や改良すべき点については、識者の方のご批判を待ちたいと思います。
[0] http://sunsite.unc.edu/pub/sun-info/standards/xml/why/xmlapps.ps.zip
[1] http://www.w3.org/pub/WWW/MarkUp/SGML/Activity
[2] http://www.w3.org/pub/WWW/TR/WD-xml-961114.html
[3] http://sunsite.unc.edu/pub/sun-info/standards/dsssl/dssslo/dssslo.htm
[4] http://www.jclark.com/jade/
[5] http://sunsite.unc.edu/pub/sun-info/standards/xml/why/xmlapps.htm
[6] http://sunsite.unc.edu/pub/sun-info/standards/dsssl/stylesheets/html32/html32hc.dsl