レベル: 中級 Antoine Quint (antoine.quint@fuchsia-design.com), SVG Consultant and Research Scientist, Fuchsia Design
2003年 11月 18日 SVG（Scalable Vector Graphics）とXFormsは、電子出版に関連して開花しつつある技術ですが、別々の側面を扱っているように見えながら実は関連したものです。この入門編では2つの技術を概説し、2つを融合した場合の可能性（シナジー効果）に焦点をあてます。
この記事を書いている間にも2つの技術には信じがたいほどの動きがあり、最新の（あるいは次の）リリースによって、それぞれの応用分野でちょっとした革命を巻き起こしています。XFormsは、HTMLフォームの後継として長く待たれていたもので、単にXMLで洗練しただけのもの以上になっています。XFormsには、抽象化されたユーザ・インターフェース・レイヤを使ってXMLを編集できる機能があります。一方SVG（Scalable Vector Graphics）は、2回目のマイナー・バージョン・アップが完了間近であり、これが出来上がれば使用形態が劇的に広がり、かつてないほどの応用性、拡張性を持ったものになります。このシリーズでは、2つの技術がとった新しい考え方を紹介し、両者がどのように統合できるかを説明します。この入門編ではまずXFormsとSVGを分析し、両者がどのように関係し得るのかを説明するところから始めます。
XForms
XFormsはHTMLフォームの後継ですが、ユーザとの対話型アプリケーション開発でHTMLフォームが果たした重要な役割を見過ごすべきではありません。
HTMLフォームの略歴
この記事を読んでいるあなたはdeveloperWorks XMLゾーンの読者ですので、HTML（と、その後のXHTML）とそのフォーム機能について多少は実際的な知識があると言う前提で説明します。HTMLフォームでは、静的ドキュメントを要求するだけというレベルからはるかに進んで、クライアントとサーバ間での対話を可能にしました。HTMLフォームはWebコンテンツ開発者に提供された手段として非常に堅実なもので、予め用意されている各種の仕組み1行入力、複数行入力、ラジオ・ボタン、コンボ・ボックス、選択リスト・・・等）を使ってユーザが文字データをやり取りできます。現在のWebにHTMLフォームが大きな役割を果たした・・・、と言うのは控えめな言い方になりますが、それが本当に意味するところから目をそらすべきではありません。Webが驚異的な新通信媒体として新しい流れや全く新しい経済体系等々の発展に貢献した、とは単純に言えないのです。むしろWeb開発自体は宣伝されたほどバラ色ではありませんでした。フォームを使って対話を行う比較的単純なWebアプリケーションを作ったことのある開発者なら誰でも、問題をいくつでも挙げることができるでしょう。そうした問題のリストには間違いなく、XFormsが解決しようとしている問題が含まれているはずです。ユーザ・インターフェースにおける妥当性の検証と値の制限もその一部です。
HTMLの時代には、妥当性の検証はいつも頭の痛い問題でした。これを解決するために開発者がとった方法は、一般的に3つあるうちの1つでした。まず一番単純な方法として、（たいていの場合はPerlのようなスクリプト言語を使って）サーバで妥当性を検証させることでした。そうしたプログラムを書くのは骨の折れる仕事である上、フォームの検証過程でエラーが発生する度に新しいドキュメントを送り返す（かつ後で再処理する）必要があるので、解決方法としてはお粗末なものでした。2番目の方法は、クライアントで検証を行うものですが、完全にプラットフォーム依存のオブジェクト・モデルで、JavaScriptベースの妙技のようなスクリプトを使いこなさなければなりませんでした。3番目はその2つの組み合わせです。どの手法をとっても結局気が遠くなるような作業は相変わらず必要なので、結果は満足できるようなものではありませんでした。
ユーザ・インターフェースの面でもあまりパッとしたものではありませんでした。上に挙げたユーザ・インタフェースの仕組み（UIウィジェット）はどれも、最初は良いのですが、すぐに問題が出てきます。UIウィジェットの選択範囲は極めて狭く、入力機構を改善しようとすると、（例えばカレンダーで出発日を選ぶような場合）クライアントのスクリプトを賢いものにして、互換性の無さを承知で恐ろしいDHTMLを使う方法に頼らざるを得ませんでした。また各フォームのウィジェットの外観と振る舞いは、基本的に特定のプラットフォームに結びついていました。これはユーザ環境とうまく融合するには良かったのですが、完全カスタムのウィジェットが作れる可能性はほとんどありませんでした。またブランド・イメージやプラットフォームに依らない一貫したルック・アンド・フィールを目的としたグラフィックの修正も、簡単ではありませんでした。
フォームについての新しい解決方法に取り組むには、妥当性の検証とユーザ・インターフェース制御だけでも十分すぎるほど大きな問題ですが、デバイス依存性、アクセシビリティ、またXMLとの統合ができないことも無視できない問題でした。こうした問題すべてを考慮に入れた上で、W3Cは次世代のWebフォームとなるべきものの開発を始めたのです。
XML流のフォーム
今日では多くのWebアプリケーションがXMLを使っています。こうした中で、クライアントにまでXMLの力をもたらす（例えばXHTMLを使った）アプリケーションも次第に増えています。XFormsはXMLプラットフォームと緊密に連携しているので、こうした流れには最適なものです。XFormsはフォームのモデルと表示を完全に分離するという、根本的に新しい手法を持ち込んだのです。
フォームのモデルというのは基本的に、必要なデータが適切なユーザ・インタフェースを使用することに関して定義した、構造化されたプレースホルダです。XFormsではコンテンツ開発者がXMLを使ってモデルを規定します。これにより最適のカスタム文法を使って、ある目的に特化した構造を作ることができるのです。一旦モデルが定義できれば、残るのはユーザ・インターフェースとして、どの部分を見せるかを規定することだけになります。
XFormsでのユーザ・インターフェースの指定はいささか抽象的で、実際のUIがどう見えるべきかという直接的な指定はできません。代わりにコンテンツ開発者はXFormsに組み込みの要素を使います。高いレベルの表現で言えば、XForms要素は、モデル中のある要素（XPath表現で参照されます）に対してユーザがどのように値を入力したり選択したりするかを規定します。これをもっと具体的に説明するために、HTMLで「ユーザが日付の文字列を入力できるように、文字入力ウィジェットを描く」という例を考えてみてください。XFormsでは「私のモデルに適合する一つの値を選択する、正しいウィジェットをユーザに提供しなさい」となるのです。
それは素晴らしいことですが・・・、ではこれを使って昔からの問題を解決するには具体的にどうすれば良いのでしょう。XMLでモデルを定義するとどこがスマートなのかと言えば、（組み込みのW3C XML Schemaデータ型を使うにせよ、XForms自体のデータ型を使うにせよ）モデル中のどんな要素に対しても、実際にデータ型をバインドできると言う点でしょう。これにはいくつか利点があります。第一に、値が入力されるかウィジェットで選択されると、そのデータ型の条件に基づきXFormsの実装によって、この値に対する検証が自動的に行われるのです。さらに、そのモデル要素にはデータ型があるので、そのモデル要素をユーザ・インターフェース要素を用いて参照すれば、ユーザに適当な方法で値が表示されることも保証されるのです。ですから例えば、XFormsで「私のモデルに適合する一つの値を選択する、正しいウィジェットをユーザに提供しなさい」と言ったことを思い出してください。もし提供したい値が日付であれば、実装がそのヒントを認識してカレンダー・ウィジェットを表示することでしょう。
信じられないかも知れませんが、私はまだXFormsのごく表面的なことを説明したにすぎないのです。さらに詳しい資料については参考文献を見てください。先ほど述べたように、HTMLフォームの欠点の一つはスタイル化の能力が欠如していることです。XFormsでは、設定された外観を持つユーザ・インターフェース要素は一つもありません。こうした要素は（選択可能な項目の数のように）対話における制限を定義するだけだからです。データ型は実装に対するヒントとして機能し、ユーザに対して適当な入力ウィジェットを与えるのです。またXFormsの表示レイヤ、対話レイヤとしてSVGを利用することができます。SVGが最近どれくらい進歩しているか、こうした仮定に対してSVGの発展具合がどう関係するかを見ていきましょう。
SVG
XFormsとSVGの新しいフィーチャがもし融合できれば、多くの可能性が生まれます。
初期の頃・・・SVG 1.0
SVG 1.0は、2001年９月に勧告となり、それ以来、広範囲の産業で使われてきました。特筆すべき応用分野としては、地図作成とグラフィックスがあげられます。最近のSVGでは、オープンソース・プロジェクトを通じてSVG自体に関する開発が行われていますが、その開発はよりアプリケーション寄りで、再利用可能なSVGベースのUIウィジェット関連のライブラリを提供することを目標にしています。こうしたプロジェクトはすべて、対話型SVGの基礎として、スクリプト言語（通常はECMAScript）と（SVG専用の拡張を含む）DOMとを関連付けて使用しています。
こうしたライブラリのアーキテクチャは、（基礎はすべて同じなのですが・・・）それぞれ異なる方針をとっています。そうしたアーキテクチャを理解する一番単純な方法は、ライブラリにオブジェクト指向のECMAScript APIを提供することでした。ですから、私がSVGでコンボ・ボックスを作ろうと思ったら、SVGComboBoxクラスを提供することができるわけです。ユーザは、このクラスをインスタンス化し、パラメータに値を入れるいくつかのメソッドをコールし、描画を指示します。つまり、（SwingやWindForms、Aqua等の）伝統的フレームワークでの通常のUIツールキットとほとんど同じなのです。もちろん、こうしたライブラリを、（DOMスクリプトを記述している、ライブラリ内部を抽象化したAPIを提供することで）SVGの上に構築することもできるのですが、SVG言語自体との統合はほとんどありませんでした。さらに各コンポーネントのカスタムAPIを使うには学習が必要であり、XMLが持っている宣言性や意味付けなどの利点が何もありませんでした。
再利用可能なライブラリを提供するためのより賢明な方法としては、あるXMLをパブリックAPIとして機能させることでした。コンボ・ボックスの例に戻ると、ユーザに対して、（例えば<ui:comboBox>のような）私自身の名前空間で表現されたXML要素を提供することができます。私のライブラリの一部は、ロード時に文書全体を構文解析し、<ui:comboBox>があることをチェックし、次にSVGComboBoxオブジェクトを構築します。基本的に<ui:comboBox>要素は、SVGComboBoxインスタンス上の必要なすべてのメソッドをコールするための省略形として機能します。私のカスタム要素はDOMの一部なので、ユーザがDOMのAPIを使って、このカスタム要素にアクセスし、属性のうち一つ（たとえば横方向の位置やその内容など）をちょっと調整するような時に、変更イベントを受け取ることができます。SVG環境にはXML寄りの手法がよりふさわしいと信ずる多くの開発者は時が経つにつれ、この手法がより適切だと見なすようになりました。
ところがこの手法は、初めに考えられていたほど最適なものではないことが分かってきました。レンダリングは相変わらずドキュメント・ツリー内で行われており、これでは多くの場合に混乱が生じることが分かりました。何でも同じツリーに入れ込んでしまうことには危険が伴います。一番の危険性は互換性の問題です。元の構造が分からなくなり、それぞれがドキュメント・ツリーの中にある何かを前提としている、別々の拡張機能の相互運用に問題が出てくるのです。
SVG開発者の何人かは、SVGの上で拡張機能を構築する手法を議論してきました。W3CのSVGワーキング・グループが行っている規格の問題解決作業にとっては、この議論が有力な情報となりました。解決の最初の兆しがSVG 1.2と、RCCと呼ばれる新しいフィーチャに見られます。
広がる可能性： RCCとSVG 1.2
RCC(Rendering Custom Content) は、SVGでカスタムのXML文法を使うための基礎となる新しいフレームワークです。RCCフレームワークは、SVG実装において利用可能な技術や概念の上に構築された非常に軽量のレイヤを提供します。
RCCが開発者にとって喜ばしい理由の一つは、以前はほとんど隠れてしまっていたSGV 1.0の概念、シャドウ・ツリー（Shadow Tree）が見えるようになったことです。SGV 1.0でシャドウ・ツリーは、<use>や<pattern>、<marker>などの要素でSVG表現を拡張するために使われていました。これまでシャドウ・ツリーの操作は実装の中に隠れていましたが、RCCでは異なった文法によるどのような要素でもシャドウ・ツリーを持つことを可能にし、公開することも許すのです。SVG 1.2にはシャドウ・ツリーにアクセスするための新しいDOM APIができました。この結果、シャドウ・ツリーを普通のDOM APIで通常のドキュメント・ツリーを操作するのと同じように操作することができるようになるのです。例えば今、生成したグラフィックスと付随するイベント・リスナーのすべてが、閉じたツリー内にあるとしましょう。他の要素は（そのツリーに対して何かをすると問題が起きる可能性があることを十分承知の上で）本当に必要性が無い限り、そのツリーに偶然アクセスするようなことはありません。シャドウ・ツリーを使えば、ドキュメント・ツリーに残るのはカスタム要素だけで、他には何も残らないのです。
カスタム要素がDOMで記述でき、正当な方法でドキュメント・ツリーに統合できることも必要ですが、その要素が他のSVG要素と全く同じように振る舞うようにしたいなら、その要素がイベントに対応できるようにしておく必要があります。もう一つRCCに関連して素晴らしいのは、SVG 1.2にDOM Level 3 EventsとXML Events（参考文献）という、２つの新しい標準が加わったことです。DOM Level 3 Eventsを使えば、目的に特化した、カスタム・イベントが生成できます。ですから、ユーザが（シャドウ・ツリー内にある）要素のグラフィカルに表現されたウィジットを使って新しい値を選択すれば、私の<ui:comboBox>がselectイベントをディスパッチすることができるのです。
カスタム・イベントをディスパッチできるのは結構なことですが、こうしたイベントを監視（リスン）できることも必要です。これには以前からのDOM Level 2による方法で、EventTarget::addEventListener()メソッドを使うという手もあります。ただし、この方法は、プログラミングによって実現することを意味しており、所定の要素のイベントをリスンするには多くの場合、宣言的手法を採る方が望ましいと言えます。XMLイベントを使えば、（組込みであろうとカスタムであろうと）どんなイベントもリスンすることができます。うまく機能しない属性ベースの（例えばonMouseoverやそれに類似した）イベント・リスナーを使わなくても、標準的な宣言構文を使ってリスンすることができます。イベントの面では、RCCで定義された外部要素をバインドする機構に関連して、SVGに2つの新しい組込みイベントを導入します。このシリーズの次の記事で説明する予定ですが、RCCフレームワーク全体はもちろん、この2つのイベントは素晴らしいもので、SVG開発者が（通常のSVG要素とほとんど同じように振る舞う）カスタム要素を提供できるようになります。これによってSVGが新しいプログラミング・プラットフォームとして、あらゆるXMLアプリケーションに対応できる道が開けるのです。
まとめ
XFormsは、データ と 表示 を明確に分離することによって、HTMLフォームが持つ問題を解決する高度に抽象化されたXMLベースの解決手段です。一方SVG 1.2は、RCCフレームワークにカプセル化されたシャドウ・ツリーと巧みなイベント統合を備えており、さらなる拡張に向かいつつあるプラットフォームを提供します。こうしたことを念頭に置くと、RCCを使って非常にきれいにカスタムUI要素を作成でき、こうしたカスタム・コンポーネントをXForms的に再利用することで、変化に富んだユーザ・インターフェースが提供できるようになるのです。次回の記事ではRCCベースのSVGコンポーネントの作成に焦点を合わせ、その後の記事でXForms統合について説明して行きます。
参考文献
著者について  | | | Antoine Quintは独立のSVGコンサルタント兼研究者で、招聘専門家としてW3CのSVGワーキング・グループに参加しています。SVG関連の講演やセミナー講師も場所さえ良ければ喜んで引き受け、下請け仕事もしています。家はパリにあり、猫のStig Elmerと一緒に住んでいます。古くからの友人Robin Berjonと共著の著作を執筆中ですが、だいぶ遅れ気味です。 |
記事の評価
| 
