レベル: 中級 Elliotte Rusty Harold (elharo@metalab.unc.edu), Adjunct Professor, Polytechnic University
2008年 2月 05日 XML にはどんな未来が待っているのかを Elliotte Rusty Harold が予言します
進歩の車輪はゆっくりと回転しますが、回転は続いています。水晶玉は少し曇っているかもしれませんが、XML の将来の概要は明確になりつつあります。正確なタイムラインは多少不確かですが、XML が進む先は不確かではありません。XML の将来は Web と共にあり、もっと具体的には Web パブリッシングと共にあります。
そう言わなければならないのは少し変に思えるかもしれません。結局のところ、Web とはパブリッシングそのものではないのでしょうか。Web は何よりもまず、情報を公開するための機構として設計されました。それ以外に Web ができることには何があるのでしょう。非常にたくさんのことができます。この 3 年間、従来の Web サイトよりもかなり高度な Web アプリケーションへの関心が爆発的に高まりました。ワード・プロセッサーやスプレッドシート、ゲーム、ダイヤグラム・ツール、そしてさらに多くのものが、すべてブラウザーの中に移行しつつあります。この傾向は、Web ブラウザーでのローカル・ストレージによってオフラインでの作業が次第に可能になるにつれ、この先の 1 年も加速する一方でしょう。しかし XML は相変わらず Web 1.0 でのパブリッシングにしっかりと根を張っており、それはやはり重要なことです。
夢占い
今年は、いくつかの夢が実現されようとしています。Sun の夢であった、ネットワークに展開されたアプリケーションが、今起こりつつあります (ただし驚くべきことに、そうしたアプリケーション用に選ばれた言語は JavaScript™ であり、Java™ ではありません)。これは最大の機会損失です。つまり Sun はこれを 10 年前に実現できたはずなのです。しかし残念ながら Sun は、それを実現するためのクライアント側での経験やビジョン、あるいは関心を持っていませんでした。そして今や Sun は、追いつくための (そして敗北に至る) ゲームに必死になっています。
オペレーティング・システムをブラウザーで置き換えるという Netscape の夢も、今年実現されようとしています。Netscape は、これがやがて実現するというビジョンを持っていました。しかし残念なことに、それを実現させるためのビジネス上の手腕や芸術的センスは持ち合わせていませんでした。とはいえ、Netscape の直接の後継である Firefox と Mozilla Foundation は、どちらも、このまったく新しい世界をもたらす上での重要な役割を演じています。
Microsoft® にとっては、歴史は浅いが機知に富んだ競争相手が彼らを追い越すという悪夢も現実になりつつあります。Microsoft は Sun と Netscape に気を取られすぎ、Google が Office と Windows の領域に進出してきたことに気が付きませんでした。GMail や Google Docs、その他さまざまなソースからの類似のアプリケーションによって、基礎となるオペレーティング・システムが急速に重要でなくなりつつあります。
確かにブラウザーを実行するために相変わらずオペレーティング・システムは必要ですが、それがどのオペレーティング・システムなのか、次第に誰も気にしなくなっており、それはこの 10 年間、PC が Microsoft Windows® を実行しさえすれば誰も PC のメーカーを気にしなくなっているのと同じことです。今や Google が実行できさえすれば、オペレーティング・システムのメーカーなど誰も気にしないでしょう。Windows による独占的な支配は、まだ完全にその支配を明け渡すほどにまではなっていませんが、Microsoft はいわば空になった城の門を守っているような状態です。
こうした状況と XML はどう関係するのか
 |
evalJSON() という選択肢
もちろん私は evalJSON() について知っています。私がこれまで見たいくつかの Ajax アプリケーションから判断すると、どうやら私は Ajax アプリケーションを作成している大多数の開発者よりも evalJSON() には慣れているようです (eval() よりも便利なオプションが何年も前から利用できるようになっているにもかかわらず、大多数の開発者が eval() を使い続けています) |
|
XML も大々的に宣伝された技術ですが、こうした状況とはほとんど無関係です。Ajax (Asynchronous JavaScript + XML) という旗の下で反乱者が横行しており、Ajax の x はXML を表しますが、Ajax で XML を使う人は誰もいません。この頭字語が作られるのとほぼ同時に、Web 開発者は XML を生の JavaScript コードで置き換え、それをデータとして渡し、eval() を使って実行する、ということを始めました。このためセキュリティーがかなり問題になっています。
これはいくつかの API のうちの 1 つに問題があるためであり、データ・フォーマットが問題なのではありません。もっと具体的に言うと、1 つの API、DOM (Document Object Model) が問題なのです。大部分の開発者は DOM を最初に習い、その後、DOM に代わるものを習いません。彼らは DOM と XML とを区別することができません。従って、十分に根拠のある、DOM に対する嫌悪感と、根拠のない、XML に対する嫌悪感とを混同してしまいます。DOM は、API における最小公分母ではなく、最悪の公分母なのです。実際試してみると、XML 処理用の API として、これ以上悪いものは設計できないほどです。しかし開発者は、新しいものを習うことに対して非常に抵抗するものです。Java コミュニティーの外では JDOM と dom4j がいくらかの進歩を遂げていますが、それらよりも優れ、それらに代わる E4X や Amara XML Toolkit などはほとんど知られていないままであり、しかも盛んに抵抗を受けています。また JSON (JavaScript Serialized Object Notation) の天才的技術は JSON の最大の弱点でもあります。JSON は実行可能な JavaScript コードなので、JavaScript プログラマーは JSON を使うために何も新しいことを習う必要がありません。もっとセキュアなデータ転送フォーマットであったら、受け入れられることはなかったでしょう。
|
頻繁に使用される頭字語
- API: application programming interface
- HTML: Hypertext Markup Language
- SGML: Standard Generalized Markup Language
- W3C: World Wide Web Consortium
- XML: Extensible Markup Language
|
|
DOM は XML にとっての重荷です。DOM は、XML がもっと広くソフトウェア開発に採用される上での最大の障害です。XML はプログラミングにおいて、この 2,000 ポンドの碇を引きずりながら、進めるところまで進んできました。W3C (World Wide Web Consortium) とブラウザー・ベンダーが DOM を非推奨とし、まともな代替手段で置き換えない限り (できれば、まともな代替手段がいくつかあって欲しいものです。すべてを 1 つの API で行おうとすることが、DOM がこれほど悪いものになっている大きな理由です)、XML はソフトウェア開発、特に Web ソフトウェア開発で使われることはなくなってきました (しかも重要なソフトウェア開発は次第に Web ソフトウェア開発のみとなりつつあります)。W3C は、必要な場合には、実際に作業をする開発者の要求に応え、不適切な仕様を非推奨にする必要があります。
XML は役割を終えたのでしょうか。いえ、私は XML には明るく重要な将来があると信じています。単にその将来というものが、古典的なソフトウェア開発にも Web ソフトウェア開発にもあまり関係のない将来であるにすぎません。2008年とそれ以降、XML がどこに向かおうとしているのかを理解するためには、1997年、あるいはさらに前にさかのぼり、XML の起源を調べる必要があります。
XML の起源
まず、少なくとも XML が登場した頃には、XML をソフトウェア開発に使うことは想定されていなかったことを理解する必要があります。初期の仕様、つまり XML 1.0 や XPath、XSLT (Extensible Stylesheet Language Transformation)、XML での名前空間、XHTML (Extensible Hypertext Markup Languag)、そして DOM はどれも、ソフトウェア開発者の要求には焦点を当てていませんでした。もし XML がソフトウェア開発用に設計されていたとしたら、(JSON が結局サポートすることになったのと同じように) リストやマップやデータ型などをサポートしていたはずです。しかし XML は、むしろ出版用に、もっと具体的には Web ページの出版用に設計されたのです。
XML は、XML よりも 20 年も前からある、SGML として知られる技術から派生したものです。それとほとんど同じ頃、IBM® の Codd は、ごく小さな、順序付けられていない小片にデータを断片化することでデータを構成する方法を検討しており、また同じく IBM の Charles F. Goldfarb と Edward Mosher、そして Raymond Lorie は、テーブルとして表現したのでは意味をなさない、順序付きの大規模な文書群を構成する方法を検討していました。Codd は、在庫や財務記録などのビジネス・データについて考えており、Goldfarb と Mosher、そして Lorie は、アニュアル・レポートなどのビジネス文書や航空機の技術マニュアルなどについて考えていました。
SGML は出版に関する問題を解決するためのものでした。その問題とは、プロセッサーが異なり、文字セット、自然言語、オペレーティング・システム、さらにはベンダーまでも異なる各種プラットフォームにまたがり、何万ページにもわたる可能性のある文書を、どのように作成し、管理し、更新し、出力し、検索し、そして読み取るかといったものです。SGML はそういった問題に対処する必要のあった政府や軍に関係する機関で一定の成功を収め、また O'Reilly など何社かの技術系出版社は時折 SGML を使用していました。しかし全体として見ると、出版業界の人達にとってさえ、SGML は大部分の人の要求に対してあまりにも大きすぎ、複雑すぎました。
SGML の最大の成功である HTML は、SGML の最大の失敗でもありました。HTML は SGML の応用を想定されたものでしたが、ブラウザーやエディター、あるいは Web ページなどの作成者は、ほとんど誰も、何の頭字語か以上には SGML について知りませんでした。(多くの人は SGML が何の頭字語であるかすら知りませんでした。) 拡張機能が無計画に導入され、それに伴って、HTML は SGML に準拠する必要があるという主張は急速に無視されるようになりました。当時存在した、いくつかの高価な SGML ツールでさえ、1996年頃の Web 上に存在していた現実の HTML を処理することはできませんでした。
XML は、この状況を修正するために考え出されました。XML は一方で、誰もが同意でき、忠実に実装できる、妥当で標準的な 1 つのサブセットにまで SGML を単純化することを意図していました。この単純化した仕様によって、SGML を使用していなかった幅広い人達に採用してもらえることを望んでいたのです。この点で XML は、ほぼ成功を収めました。
その一方、XML は、ブラウザー間での互換性のなさや動作の違いといった面倒な問題の少ない、適格な Web の基礎になるはずのものでした。この点では、XML はほとんど失敗しました。XML と XHTML は、ブラウザーが処理しなければならない、HTML の方言をもう 1 つ導入したにすぎず、しかもタグ・スープを置き換えるという目標には近づくことすらできていません。
成功であれ失敗であれ、XML が目的としていたものは、出版、つまり本やマニュアル、そして最も重要な Web ページの出版です。XML は出版用途以外のソフトウェア開発用には最適化されておらず、そのように作られてもいません。構成ファイルやリモート・プロシージャー・コール、オブジェクトのシリアライズ、データベースのダンプなど、開発指向の課題に XML を使用することは想定されておらず、計画もされていませんでした。そのため、そうした作業に XML が必ずしも適しているわけではないことは驚くべきことではありません。とはいえ XML は、それまで開発者が手にできなかったものを実際に彼らに提供しました。つまりデータ・フォーマットはプラットフォームや言語に依存せず、国際化に対応しており、しかも高品質で無料のパーサーを容易に、いくらでも入手することができます。こうして開発者が手に入れたものは非常に魅力的であり、int や float などのデータ型がなく、リストやマップなどの基本的なデータ構造がないことをプログラマーが無視するのも無理はありません。
しかし、そうした作業は XML では想定されていなかったため、その面を元に XML を判断したり、その面から XML の最大の強みや将来の展望を見たりすることは正しくありません。それを探すには、元々 XML の目的であった領域、つまり出版、特に Web 出版に戻る必要があります。Web での出版には以下の 3 つの部分があります。
読者の部分に関しては完了しています。読者はブラウザーです。主なブラウザーはすべて、現在は XML をサポートしています。しかし作成と公開の部分、そしてその両者の接続に関しては、まだ始まったばかりです。
オーサリング
文書を公開できるようになるには、まず文書を作成する必要がありますが、この部分での戦いは終わっています。XML は勝利しました。主なオフィス・スイートは、現在はどれもデフォルトで、圧縮した XML で文書を保存します。そうしたオフィス・スイートには、Microsoft Office、OpenOffice、StarOffice、WordPerfect Office、そして Lotus® Notes® があります。Adobe® Illustrator® などのグラフィック・アプリケーションでさえ、現在は文書を XML で保存することができます。最も目立つ例外に Apple の iWork がありますが、これも今年のうちには XML で保存できるようになります。
|
マークアップ中心のエディターの終焉
XML が登場したばかりの頃には、多くのベンダーが、ツリー形式のコントロールで埋め込み文書を作成できる、マークアップ中心のエディターをリリースしました。これには、既製のさまざまなツリー・コンポーネント (Swing での JTree など) を使って非常に容易にコーディングを行えるという利点がありました。しかしこうしたエディターにとって明らかに分が悪かったことは、XML 文書をツリーとして読んだり作成したり編集したりすることを望む人は誰もいない、ということでした。これらのツールは惜しまれることもなく市場からほとんど追いやられました。 |
|
これによって明らかな変化が起きましたが、その変化が完全に理解されているわけではありません。その大きな理由は、XML がユーザーから見えないところにあるためです (実際、見えないところにあるべきなのです)。スプレッドシートの典型的なユーザーは、Excel® が永続的な Excel データをディスク上にどう配置するかの詳細を知る必要はなく、また気にする必要もありません。しかしテキスト型による XML の構造のおかげで、サードパーティーにとってはフォーマットのリバース・エンジニアリングやアプリケーションとの相互運用がずっと容易になります。たとえ OpenOffice XML のように XML ボキャブラリーのドキュメンテーションが貧弱で脈絡のない場合でさえ、それまでの、内容を理解できないバイナリー・フォーマットよりも約 1000 倍も作業しやすいのです。もしフォーマットが、もう少し合理的であり、またプラットフォームやレガシー・アプリケーションの制約がそれほど強くない場合には (例えば OpenDoc フォーマットの場合など)、さらに作業がしやすくなります。
2008年には、オフィス文書にどの XML ボキャブラリーを使うかに関して、相変わらずたくさんの議論が行われ、そしてどちらの側にも少なからぬ論客が見られるでしょう。私は、Microsoft は OOXML を ISO 標準として宣言させるという努力を 2月にあきらめるのではないかと思っていますが、確かな話ではありません。いずれにせよ、その兆しは現れています。Microsoft Office は OpenOffice や iWork その他の競合にマーケット・シェアを奪われ続けるでしょう。
それは Office が悪い製品だからでも、クローズド・ソースだからでもなく、単純にマーケット・シェアを下げる以外に行く先がないからです。Office が成長する余地はどこにも残っていません。唯一の疑問は、どの程度までシェアを落とすか、どの程度の速さでシェアを落とすかのみです。Microsoft による支配に対する最も差し迫った脅威は、さらに多くの政府がオランダやノルウェーにならい、OpenDoc やオープン・ソースのソリューションを強制するという動きです。それよりは Microsoft にとって脅威の程度は低いものの、それでも懸念される事項は、非常に低価格の PC が普及してきていることによって Windows と Office がシステム全体のコストの 50% 以上になってしまう点です。Microsoft は既に、ある程度この状況を意識し始めており、低価格版の Office である Student and Teacher Edition を用意し、教職にある人や家族の中に学生がいる人、過去 1 世紀以内に小学校に通った人、あるいは先生と思われる人のために A 列車 (訳注: ニューヨーク市地下鉄 8 番街急行線の通称) でドアを押さえてあげたことのある人などが入手しやすいようにしています (訳注: 途中から冗談になっているようですが、そのまま訳してあります)。しかし、左手は右手がしていることを知らないという古典的なケースそのままに、Microsoft は Office の違法コピー防止にも力を入れています。それによって安易な違法コピーは減少するかもしれませんが、より多くのユーザーをオープン・ソースのオフィスに追い立てることにもなります。
今や私達のオフィス文書はすべて XML なので、それらの文書を 1 つのフォーマットから別のフォーマットに変換することは信じられないほど容易になるはずです。2008年は、XML ファミリーの中でおそらく最も大きな影響を与えた技術、XSLT が生まれて 10 年目です。XSLT はその最新の 2.0 バージョンで、より一層強力になりました。非常に近いうちに、自分がどのフォーマットを使っているかを人々が気にしなくなるほど、競合フォーマット間での変換が非常に単純になるでしょう。いくつかのスタイルやマクロはうまく変換できないかもしれませんが、そうした機能はいずれにせよ大部分の文書では使われていません。ベンダーによる、文書フォーマットの面からの囲い込みは、はるかに小さな問題になります。
もちろん、最も重要な変換は、OpenDoc から OOXML への変換でもなければ、その逆変換でもなく、重要なのは OpenDoc または OOXML のいずれかから XHTML へという変換です。OpenOffice や Microsoft Office の HTML エクスポート機能は、どれもひどいものです。この不始末を何とかしてくれるサードパーティーに期待しましょう。それよりも最も重要なことは、企業の個々の開発者やウェブマスターが彼らのサイトのカスタム・テンプレートを公開し始めているのを探すことです。それらを利用できるようになると、普通の人は慣れた Microsoft Word で文書を作成し、その文書をローカルのコンテンツ管理システムに直接アップロードできるようになり、編集ツールやレビュー・ツールが文書自体に埋め込まれることになります。マシンがすべてのマークアップを生成してくれるため (人間は慣れた GUI インターフェースを見ることになり)、何もしなくても整形式にしてくれます。2008年の終わりには、まだ Web の大部分は整形式ではないでしょうが、整形式の Web の割合は現在よりも高くなっているはずです。
また XSLT と XML によるオフィス・フォーマットは、大量の隠れたデータを公開してくれることでしょう。無数のビジネス文書が、過去 10 年、あるいはそれ以上、読まれないままファイル・システムの中で放置されていました。それらの大部分は明らかに今日では重要ではありませんが、一部の文書は、誰も検索できないために忘れられていた重要な情報を含んでいます。企業の開発者は、まず新しい XML ベースのフォーマットへの変換を自動化し、次に XSLT と XQuery を使ってデータを発見しやすくすることで、既存の Office 文書から情報を抽出し、再利用するようになるでしょう。
もし、オーサリング・ツールが Word や OpenOffice Writer など従来のオフィス・プログラムだとしたら、そのツールを保持するためにサーバー上には何を置くのでしょう。またクライアントからサーバーへ、コンテンツをどのように移動するのでしょう。ここで、2007 年に 1.0 がリリースされた最も重要な 2 つ、APP (Atom Publishing Protocol: Atom 出版プロトコル) と XQuery が登場します。
Atom 出版プロトコル
従来、技術者ではない人を Web 用の文書を作成できるように訓練する際には 2 つの困難な問題がありました。彼らにセマンティックなマークアップを教えること、そして FTP の使い方を示すことです。(技術者ではないユーザーの多くが標準の「ファイルを開く」というダイアログ・ボックスすら使えないことを思い出してください。彼らは何から何まで、マイドキュメント・フォルダーあるいはデスクトップ上に保存します。もし誤って他の場所にファイルを置いてしまうと、彼らは途方に暮れてしまいます。プログラマーは階層構造を理解できますが、多くのユーザーは、そうした抽象的な考え方ができません。)
最初にあげた問題は OpenOffice や Microsoft Word などの、XML 対応のワード・プロセッサーで解決することができます。2 番目に挙げた問題は、Atom 出版プロトコルによって解決できます。HTTP が Web のブラジングで果たした役割と同じ役割を、APP は Web オーサリングで果たします。つまり APP は、さまざまな個々のクライアントやサーバーが事前の合意や共有概念モデルなしに使用できる、標準的なプロトコルとしての役割を果たすのです。
個々のソフトウェア・ベンダーは、さまざまなサーバー上にある APP サービスと通信する、独自のオーサリング・ツールを作成することができます。そうしたツールは、Word や OpenOffice などの製品用のカスタムのエディターやプラグインにすることができます。コンテンツのアップロードは、現時点でローカルのハード・ドライブにファイルを保存するのと同じくらい簡単で、場合によってはもっと簡単になるでしょう。新しい文書の作成に必要なものは、POST のための URL とユーザー名、パスワードのみです。(ウィキのようなサイトでは、ユーザー名とパスワードも必要ないかもしれません。) 文書を編集するためには、その文書の URL 以外に必要なものはなくなります。
XML をどこに置くのか
さて、2008年に XML を作成する方法 (Word または OpenOffice) がわかり、それをサーバーに送る方法 (APP) がわかりました。最後の問題は、こうした素晴らしい XML をどこに置くかです。
従来、この問題には 2 つの答えがありました。最初の答えは、XML をファイル・システムに保存する方法です。2 番目の答えは、リレーショナル・データベースの BLOB (Binary Large Object) の中に入れる方法です。どちらも間に合わせの方法であり、Web サイトの場合にはあまりうまく機能しません。
ファイル・システムは単純で信頼性が高く、よく理解されている技術ですが、検索機能は貧弱、もしくは話にならないほどです。ファイル・システムは同じデータを何カ所にも重複して置きがちであり、ファイル・システムの中に保持されている文書の内部構造をまったく理解せず、またサブ文書という粒度を提供することができません。
リレーショナル・データベースは、特定の順序を持たない、しかも大量の繰り返しのない小さなデータ・チャンクに対しては、素晴らしいデータ・ストアです。しかし XML は、そのどちらでもありません。任意のリレーショナル・テーブルを XML 文書に変換することは容易です (単に各行を要素にし、各フィールドを属性または子要素にするだけです) が、逆は容易ではありません。多くの XML 文書は、意味のある順番や、意味のある空白、混合コンテンツ、繰り返し現れるが異なるコンテンツ、ネスト方法を予測できないネスト要素、などの特徴を持っているため、リレーショナル・テーブルはデータ・ストアとしては不向きです。特に、HTML や XHTML のページなどの Web ページは、こうした特徴をすべて持っています。確かに HTML や XML の文書をリレーショナル・データベースに保管することはできますが (MySQL はそれ以外にはほとんど使われていないようです)、整然と保管できるわけでもなく、高速な処理ができるわけでもありません。もし文書を多くの小さな部分に断片化すれば、データの検索、選択、そして並べ替えが可能になります。しかしそうすると、満足できるパフォーマンスを得るために多大な費用をかける羽目になります。また SQL クエリーは、本来の目的とは異なる比較的単純なことを行うためにページ半分以上にもわたる複雑なロジックを含むものになってしまうため、管理と開発も悪夢のようになります。
リレーショナル・データベースに代わる方法は、各文書を BLOB に保管する方法です。この方法は処理が高速で単純です。しかしデータの一部分のみを選択したり、さまざまな文書を組み合わせたりすることはできなくなります。アプリケーション・ロジックは PHP や Ruby、あるいは他のサーバー・サイドのフレームワークに任され、データベースは少し分離特性が優れたファイル・システムのように使うことになるのです。
私達に必要なものは、典型的な Web 文書の階層構造を処理できるように設計されたデータベースであり、Web 文書を分割して保管するデータベースではありません。そのようなデータベースが、今や初めて、さまざまな規模で存在するようになりました。それらは安定しており、いつでも使用可能です。ローエンドのものとしては、eXist と Berkeley DBXML がどんどん良いものになってきています。ハイエンドのものとしては、導入コストを負担できる余裕のある大手出版社が、高価で高速処理が可能な Mark Logic などの XML データベースへの転換を進めています。また IBM DB2® 9 pureXML™ などの混成ソリューションによって、文書と表データとを混在させたいユーザーの間で XQuery の採用が進むでしょう。
こうした初期の製品と比較して、新しい種類のデータベースはさらに安定し、よりスケーラブルで、一層信頼性が高くなっています。最も重要なことは、現在ではそうしたデータベースが、何年もの開発の後に、ついにリリースされた標準言語、XQuery 1.0 を共有していることです。アプリケーションを 1 つのデータベースから別のデータベースに移植できるという可能性は過大評価されがちです。しかし、開発者のスキルをあるサーバーから別のサーバーに移植する必要性も、同じ程度に過小評価されています。問い合わせ言語に関して 6 種類の異なる方言を学び、さらにそれを 6 カ月ごとに再度学びたい、などという人はいません。今では、そんなことをする必要はないのです。
XQuery の更新作業は順調に進んでおり、おそらく 2008年には完成しないでしょうが、(新しいドラフトごとに少しユーザーのコードを変更することをいとわない限り) 既に実装に耐えるほど十分に安定しています。この状況はこの 1 年を通じて改善され続けるでしょう。
そして最後に、2008年には javax.xml.xquery がリリースされるでしょう。これは Java プログラムを XQuery エンジンとデータベースに接続するための標準の API です。javax.xml.xquery は XQuery 用の JDBC と考えることができます。javax.xml.xquery を使うことで、XQuery を Java コードに混在させることができます。2009年の Java ７ リリースまで、javax.xml.xquery が Java クラス・ライブラリーの標準的な一部になることはないかもしれませんが、既に一部の製品ではサポートされており、サポートする製品はさらに増えるはずです。
何をする必要があるのか
XQuery の実動準備がいよいよ整い、また APP もブレイクする準備ができています。もし私が時間や費用を XML に投資するとしたら、私はこの 2 つの技術に焦点を絞るでしょう。世界が、さらにもう 1 つのコンテンツ管理システムやブログ・エンジン、あるいは掲示板を必要とすることはないかもしれません。しかしコンテンツを XML 専用のデータベースを使って保管、検索し、またそうしたコンテンツを APP を使って公開するのであれば、既存のコンテンツ管理システムやブログ・エンジン、あるいは掲示板を確実に使用することができるのです。
また私は、もう 1 つの開発ツールを望みたいと思います。XML がソフトウェア開発で使われることはなくなってきたと言いましたが、まだ XML を有効に生かせるところは残っているかもしれません。JSON の教訓は、多くのアプリケーションでは XML によって実現される柔軟なデータ構造を必要としておらず、望んでもいないということです。例えば、リストとマップをエンコーディングするための基本的な XML フォーマットが型付きのデータを含められると考えてみてください。それはリスト 1 のように簡単なものかもしれません。
リスト 1. XML のための基本的なデータ・フォーマット
<data xmlns="http://www.w3.org/data">
<list>
<string>Foo</string>
<int>17</int>
<year>1999</year>
<list>
<map>
<entry>
<string>Boston</string><string>Red Sox</string>
</entry>
<entry>
<string>New York</string><string>Yankees</string>
</entry>
</map>
</data>
|
そしてさらに、Java や JavaScript、Python、Perl、Ruby などの言語を使っていくつかの単純なライブラリーを作成し、それらのライブラリーはこのような XML 文書を言語固有のデータ構造に構文解析できるとしましょう。セキュリティーの問題がなく、XML によって実現される高い柔軟性を備えた JSON を再発明することは可能でしょうか。どこかにマニアはいませんか。
参考文献 学ぶために
製品や技術を入手するために
- XML 専用のデータベース、eXist を入手してください。この、完全に XML 技術で構成されたオープン・ソースのデータベース管理システムで XQuery を試してみてください。eXist では XML のデータ・モデルに従って XML データを保管することができ、また効率的で索引ベースの XQuery 処理を行うことができます。
- 皆さんの次期開発プロジェクトを IBM trial software で構築してください。developerWorks から直接ダウンロードすることができます。
議論するために
著者について | 
| | Elliotte Rusty Haroldはニューオーリンズ出身であり、時たま、おいしいgumbo（オクラ入りのスープ）を食べに帰っています。ただし現在はニューヨークのブルックリン近郊のProspect Heightsに、妻のBethと猫のCharm（charmed quarkからとりました）とMarjorie（義理の母の名前からとりました）と一緒に住んでいます。彼はPolytechnic Universityのコンピューター・サイエンスの非常勤教授として、Java技術とオブジェクト指向プログラミングを教えています。彼の Cafe au Lait Webサイトは、インターネット上で最も人気のある独立系Javaサイトの一つです。また、そこから派生したCafe con Lecheは、最も人気のあるXMLサイトの一つです。彼の次の著作、『
Refactoring HTML』が今年の春に Addison Wesley から出版される予定です。 |
記事の評価
| 
