モデル・ドリブン複合ドキュメント開発

Eclipseで複合XMLドキュメントを構築する

Eclipse Modeling Frameworkと基本のECoreモデルを使用して関数スキーマとそれらの接続を表現するオープン・スタンダード・ベースのアプローチによって、名前空間が混在するドキュメントを作成するための柔軟なツールを作成しましょう。これらのモデルを使用すると、結合された関数スキーマ定義に忠実でありながら、ディレクテッド編集体系を提供する、インスタンス・ドキュメントの自動シリアル化のための動的環境を実現できます。

Kevin Kelly, Senior Technical Staff Member, IBM

Kevin E. Kellyは、IBMのシニア・ソフトウェア・エンジニアとして、ソフトウェア標準化に従事しています。W3CのXForms Working Groupと、W3CのCompound Document Format Working Groupのメンバーとして、XMLベースでモデル駆動の手法に基づいた高速で効率的な標準の採用を図るべく、クライアント技術と新興のオープン・スタンダード・ベース技術に集中した活動を行っています。IBMに入社する前には、8年間 Rational Softwareを扱っており、UMLモデリングとJava技術に関した業務を行ってきました。Mercer Universityにて学位を、またUniversity of Montanaで修士を取得しています。



Jan Kratky, Lead, Workbench strategy for IBM internal tooling, IBM

Jan Kratky氏はJava1.0のリリース以来開発に携わっています。彼はIBMの内部ツールのワークベンチ戦略のリーダーです。



Keith Wells, Advisory Software Engineer, IBM

Keith Wellsは、IBM RTPキャンパスのソフトウェア開発者です。過去数年以来、Emerging TechnologiesおよびEmerging Technologies Toolkitに取り組んでいます。



2005年 7月 22日

複合ドキュメント

W3Cは複合ドキュメント・フォーマット(CDF:Compound Document Formats)ワーキング・グループを開始しました。CDFワーキング・グループは、Webアプリケーションおよび複合ドキュメント・ワークショップから発展したものであり、複合ドキュメントの標準化と複数フォーマットの組み合わせの動作の仕様にまつわる問題を検討し、拡張性と相互運用性を備えたWebのニーズに応えることを目的としてます。

CDFワーキング・グループは、XHTMLとSVG Tinyを含むかもしれないモバイル・デバイス用のリッチ・メディア・プロファイルなど、CDFプロファイルとなる特定の名前空間の語彙の組み合わせに焦点を合わせています。その他の例としては、XHTMLとXForms、あるいはXHTMLとX+Vプロファイルを使用するVoiceXMLのサブセットなどの組み合わせがあります。

複合ドキュメントの定義

詳細について

この記事に記載されているテクノロジーの詳細については、「参考文献」の関連リンクを参照してください。

名前空間は、名前の集合を一意に識別して、由来は異なるが名前が同じ複数のオブジェクトが混在するときにあいまいさがないようにします。XML名前空間は、要素タイプと属性名の集合であり、それらが属する一意なXML名前空間の名前によって一意に識別されます。XMLドキュメントでは、要素タイプまたは属性名は2つの部分から成る名前を持つことができます。すなわち、名前空間の名前と要素または属性の名前です。

Compound Document by Inclusion(CDI)は、複数の名前空間のXMLマークアップを組み合わせて、1つの物理的ドキュメントにします。1つの名前空間内でのXMLマークアップの記述である多くの標準が存在し、増え続けています。XHTML、XForms、VoiceXML、MathMLは、このような標準の代表例であり、それぞれが独自の名前空間を持っています。これらの仕様はそれぞれ、リッチ・コンテンツ開発の1つの局面に焦点を合わせています。たとえば、XFormsはデータの収集と送信に焦点を合わせ、VoiceXMLは音声に、MathMLは数学的表記の表示に焦点を合わせています。

コンテンツ作成者にとって、これら多くの標準は、それぞれ便利で重要なものです。しかし、ドキュメント作成に真の柔軟性とパワーをもたらすのは、これら任意の数の標準の要素の組み合わせです。ドキュメントは、Webブラウザーでの表示を目的として、しかも、入力フォーム、スケーラブルなグラフィック、そしてちょっとした数学的表記をすべて同じページに含むように作成されることがあります。XHTML、XForms、SVG、MathMLは、それぞれがこのようなニーズに応えるものであり、これらを組み合わせることで、1つのマルチ名前空間ドキュメントを作成することができます。

簡単な例として、XHTMLとMathMLを組み合わせた複合ドキュメントを考えてみましょう。リスト1の名前空間宣言には、下記の番号付き宣言に対応するコメントが付けられています。

リスト1. 単純な複合ドキュメント
<?xml version="1.0" encoding="iso-8859-1"?>
<xhtml:html xmlns:xhtml="http://www.w3.org/1999/xhtml"><!-- 1 -->
<xhtml:body>
<xhtml:h1>A Compound document</xhtml:h1>
<xhtml:p>A simple formula using MathML in XHTML.</xhtml:p>
<mathml:math xmlns:mathml="http://www.w3.org/1998/Math/MathML"><!-- 2 -->
<mathml:mrow>
<mathml:msqrt>
<mathml:mn>49</mathml:mn>
</mathml:msqrt>
<mathml:mo>=</mathml:mo>
<mathml:mn>7</mathml:mn>
</mathml:mrow>
</mathml:math>
</xhtml:body>
</xhtml:html>
  1. XHTML名前空間宣言リスト1の各XHTML要素は、xhtml:という名前空間プレフィックスで修飾されています。
  2. MathML名前空間宣言リスト1の各MathML要素は、mathml:というプレフィックスで修飾されています。

図1は、リッチ・コンテンツのためにXHTMLとMathMLを組み合わせたリスト1の単純な複合ドキュメントの表示版です。

図1. 表示された単純な複合ドキュメント
図1. 表示された単純な複合ドキュメント

複合ドキュメントは、リスト1のように、複数の名前空間を含む単一のドキュメントで構成できます。これが、「埋め込みによる複合ドキュメント」(Compound Document by Inclusion:CDI)です。しかし、複合ドキュメントは、特定の名前空間のドキュメントが別の名前空間の別のドキュメントを参照するという複数のドキュメントで構成することもできます。たとえば、ルート(最上位)ドキュメントは、ページの定義と書式設定のためのXHTMLコンテンツを含んでいるかもしれません。この親XHTMLドキュメントは、XHTMLの<object>タグの使用によって、別の名前空間の別の文書を参照することができます。これを必要な数のドキュメントで繰り返すことができます。ルート・ドキュメントと参照される個別ドキュメントの集合を「参照による複合ドキュメント」(Compound Document by Reference:CDR)といいます。図2は、単純なCDRドキュメントです。XHTMLルート・ドキュメントの中に別のSVG子ドキュメントの参照が含まれ、それらの子ドキュメントは3色の円に対応するマークアップを含んでいます。

図2. 参照による複合ドキュメント
図2. 参照による複合ドキュメント

そして、もちろん、CDIとCDRの両方のハイブリッドである複合ドキュメントも可能です。


モデル・ドリブン開発

略語

CDI — Compound Document by Inclusion(埋め込みによる複合ドキュメント)
CDR — Compound Document by Reference(参照による複合ドキュメント)
DTD — Data Type Definition(データ型定義)
EMF — Eclipse Modeling Framework(Eclipseモデリング・フレームワーク)
MathML — Mathematical Markup Language(数学用マークアップ言語)
MDA — Model Driven Architecture(モデル・ドリブン・アーキテクチャー)
MDD — Model Driven Development(モデル・ドリブン開発)
MOF — Meta-Object Facility(メタオブジェクト・ファシリティー)
MG — Object Management Group(オブジェクト・マネジメント・グループ)
PIM — Platform Independent Model(プラットフォーム独立モデル)
PSM — Platform Specific Model(プラットフォーム特定モデル)
SMIL — Synchronized Multimedia Integration Language(同期マルチメディア統合言語)
SVG — Scalable Vector Graphics(スケーラブル・ベクター・グラフィックス)
UML — Unified Modeling Language(統一モデリング言語)
VoiceXML — Voice eXtensible Markup Language(音声拡張可能マークアップ言語)
W3C — World Wide Web Consortium(ワールド・ワイド・ウェブ・コンソーシアム)
X+V — XHTML + Voice profile(XHTML + Voiceプロファイル)
XHTML — eXtensible HyperText Markup Language(拡張可能ハイパーテキスト・マークアップ言語)
XMI — XML Model Interchange(XMLモデル交換)
XML — eXtensible Markup LanguageXML — eXtensible Markup Language(拡張可能マークアップ言語)
XUL — XML User interface Language(XMLユーザー・インターフェース言語)

モデル・ドリブン開発(Model Driven Development:MDD)は、より良いソフトウェアをより短時間で開発するためのアプローチであり、テクニックのセットです。オブジェクト・マネジメント・グループ(Object Management Group:OMG)は、このMDDの概念をモデル・ドリブン・アーキテクチャー(Model Driven Architecture:MDA)と呼び、MDDを支援する一群の標準を開発しました。このプロセスは、ソフトウェア開発の要件段階の早期にビジネス・ロジックを定義することから始まります。このビジネス・ロジックは、ビジネス・ロジックの抽象に基づく統一モデリング言語(Unified Modeling Language:UML)でモデル化することができます。その結果としての1つ以上のモデルが、実装を生成するコード生成のための基本となります。

MDDを使用する理由は、いくつかあります。

  • 開発プロセスのスピードアップ
  • ビジネス・ロジックがプラットフォームに依存しない
  • ビジネス・ロジックが変更されると、モデルも変更される
  • 専門知識は、ソフトウェアにではなくビジネス・モデルに適用される
  • ソフトウェア開発のコスト削減

モデルは、UML、XML Model Interchange、Essential Meta Object Facility、W3C XML Schemaなど、さまざまな形式で表すことができます。

Eclipseでのモデル・ドリブン開発

Eclipseはオープン・ソース・ツール統合プラットフォームであり、おもにJava開発環境として使用されています。ツール統合プラットフォームとして、Eclipseは増え続ける多様なエディターとユーティリティー群を備え、その1つがEclipse Modeling Framework(EMF)です。

EMFは、Eclipse Open Source Projectのツール・サブプロジェクトです。EMFは、モデリングおよびデータ統合フレームワークであると同時に、Eclipse用プラグインを作成するためのコード生成フレームワークでもあります。EMFは、モデルを記述して、それらのモデルのランタイム・サポートを提供するメタ言語、ECoreを使用します。EMFは、Essential MOF(EMOF)と呼ばれるOMG Meta Object Facility 2.0(MOF)のサブセットに基づいてモデルを記述するメタ言語、ECoreを使用します。EMFモデルは、XML Model Interchange(XMI)ドキュメントとして存続します。EMFは、モデルの表示とコマンド・ベースの編集を提供し、EMFモデルに基づくインスタンス・ドキュメントを操作およびシリアル化するための基本エディターでもあります。EMFモデルは、注釈付きJavaコード、XMLドキュメント、またはUMLモデルから作成できます。

EMFは、EclipseではMDDのバックボーンの役目を果たします。


複合ドキュメント・ツーリング

CDRの作成と編集は、既存のXMLエディターで行うことができます。他のドキュメントの参照では、<xhtml:object>タグなど、汎用の参照メカニズムが使用されるからです。ただし、CDI用のエディターがディレクテッド編集体系を提供するためには、参照する別のドキュメントのインスタンスを検証する方法だけでなく、それ以上の知識が必要です。複合ドキュメントをサポートするエディターは、ある名前空間のタグの子として挿入できる別の名前空間のタグについて具体的な情報を必要とします。このようなクロス名前空間関係は、双方向であり、再帰的であってもかまいません。複合ドキュメント・プロファイルは、混合名前空間のセットについて、どのタグを他のどのタグの下に挿入できるかを定義します。XHTML/X+V(VoiceXMLのサブセット)やXHTML/MathML/SVGなど、現在、いくつかの明示的な複合ドキュメント・プロファイルがあります。

具体的な例として、特定のXHTMLタグの子タグとして、どのXFormsタグが存在できるか、またその逆を定義しなければならないXHTML+XForms複合ドキュメント・プロファイルを考えてみましょう。このプロファイルの要件の1つは、リスト2に示されているように、xhtml:div要素は子としてxforms:repeat要素を持つことができ、それは別のxhtml:div要素を子として持つことができ、さらにそれはxforms:input要素を子として持つことができるということです。

リスト2. XHTMLとXFormsの入れ子タグ
<xhtml:div>
<xforms:repeat model="model_PostalAddress"
id="repeat_AddressLine_model_PostallAddress"
nodeset="/hrxml:PostalAddress/hrxml"DeliveryAddress/hrxml:AddressLine">
<xhtml:div>
<xforms:input ref="." model="model_PostalAddress">
<xforms:label>Address Line</xforms:label>
</xforms:input>
</xhtml:div>
</xforms:repeat>
</xhtml:div>

このタグの入れ子は、xsd:anyとxsd:anyAttributes以上のメカニズムによって明示的に定義する必要があります。なぜなら、検証およびディレクテッド・エディターと、ブラウザー用のレンダリング・コードを作成するユーザー・エージェント・インプリメンターは、ドキュメントの構造をあいまいさのない形で検証し、ガイドするために、また、処理およびレンダリング・エンジンを構築するために、より明示的な詳細を必要とするからです。

複合ドキュメント・ツーリングのユーザー

複合ドキュメントの作成および編集ツールを考えるときには、2種類のユーザーに対応する必要があることを忘れないでください。すなわち、複合ドキュメント・スキーマ・アーキテクトインスタンス・ドキュメント作成者です。

複合ドキュメント・スキーマ・アーキテクトは、定義済みのプロファイルを使用して、特定の名前空間の語彙を組み合わせる方法の定義を効率的に表現したいと考えます。これは、複合ドキュメント・プロファイルの実装を構築する人です。

インスタンス・ドキュメント作成者は、プロファイルを利用したいとは思いますが、プロファイルの構築や編集には興味がありません。インスタンス・ドキュメント作成者は、プロファイルに従った整形式で妥当なインスタンス・ドキュメントを、できればディレクテッド・エディターと構成体ごとに修正する操作体系で作成したいだけです。この操作体系では、限られた数の選択肢が、プロファイルに従った妥当な文脈対応の選択肢としてエディターに与えられます。

オープン・モデリング・テクノロジーであるEMFは、当然、複合ドキュメント・プロファイルの定義に最適です。EMF ECoreモデルを使用してEclipseベースのエディターを作成し、ドキュメントの作成とシリアル化に利用できます。

複合ドキュメント・ツーリングのためのモデル・ドリブン・アプローチは、プロファイルに含まれるそれぞれの関数型名前空間(XHTML、XForms、SVGなど)のプラットフォーム独立モデル(PIM)から始まります。PIMは、実装の詳細を考慮しない高水準の抽象であり、モデル化されるものの目的だけを表現します。PIMは、W3C XML Schema、RELAX NG、Schematron、MOF、UMLモデルなど、さまざまな形式を取ることができます。プロファイル・スキーマすべてのPIMが作成できたら、それらをすべて同じ正規型のプラットフォーム特定モデル(PSM)に変換することができます。たとえば、PSMのすべてをXML Schema、UMLモデル、またはEMF ECoreモデルにすることができます。次に、プロファイルは、モデル間のクロス・モデル参照を作成し、ある名前空間のタグを別の名前空間のタグによって参照できる場所(すなわち挿入できる場所)を表現することによって実現されます。たとえば、XHTML+XFormsのプロファイルでは、<xforms:model>タグを<xhtml:head>タグの下に挿入できることを定義する必要があるでしょう。図3は、このPSM XHTML+XFormsプロファイルの注釈をXHTML PIMモデルのheadクラスとXForms PIMモデルのmodelクラスの間のUML集約関係として示しています。

図3. UMLでのPSMクロス・モデル関係
図3. UMLでのPSMクロス・モデル関係

PSMをEMF ECoreモデルに変換することができ、これはUMLモデルまたはXML SchemaからEMF付属ツールを使用して作成できます。図3の例では、集約関係がPSM ECoreモデルのEReferenceになっています。これらのモデルの作成と、これらのモデル間の参照としてのプロファイルの実現は、複合ドキュメント・スキーマ・アーキテクトの役割です。その後、複合ドキュメント・プロファイルを実現するこれらのPSMモデルを使用して、ディレクテッド・エディターを派生し、それをインスタンス・ドキュメント作成者が使用して、プロファイルに忠実なインスタンスを作成し、編集します。図4は、PIMからPSMへ、そしてシリアル化されたインスタンス・ドキュメントへのXHTML+XForms+XMLイベントのプロファイルです。

図4. モデル・ドリブンな複合ドキュメント・エディター・プロファイル作成
図4. モデル・ドリブンな複合ドキュメント・エディター・プロファイル作成

モデル・ドリブン・アプローチは、特定の名前空間の機能的なPIMを作成するための効率的な方法であり、そのPIMを使用して複数の名前空間の組み合わせのPSMを作成して、プロファイルを表すことができます。PIMモデルは、異なる組み合わせで何度でも再利用して、必要な数のプロファイルを形成することができます。Eclipse EMF ECoreモデルの使用は、複合XMLドキュメント・エディターでのインスタンス・ドキュメント作成のためのディレクテッド編集およびシリアル化を実現するための理想的な方法です。

Compound XML Document Editor

Compound XML Document EditorIBM alphaWorksで入手可能)は、ECoreモデルを使用してモデル・ベースの複合ドキュメント構造体を派生する動的エディター・フレームワークです。

Javaコードを書かなくても、インスタンスがXMLにシリアル化される任意のタイプをCompound XML Document Editorフレームワークに追加することができます。Compound XML Document Editorはモデル・リポジトリーを使用し、そこにECoreモデルが格納されます。ECoreモデルをCompound XML Document Editorモデル・リポジトリーにドロップして、Compound XML Document Editorを起動すると、これらのECoreモデルからインスタンス・ドキュメントを作成したり、動的に編集することができます。必要なだけ多くのモデルと複合ドキュメント・プロファイルに対応できるモデル・リポジトリーを作成することができます。

実行時に個々のモデルを交換したり、モデル・リポジトリー全体を交換することができます。さらに、その場でECoreモデルに変更を加えることができ、変更はエディターとシリアル化されたインスタンス・ドキュメントに直ちに反映されます。

Compound XML Document Editorには、XHTML、XForms、XML Events、SVG、SMIL、VoiceXML、XUL、MathML、およびXLink用のECoreモデルが付属しています。図5は、XHTMLがルート・ドキュメントの場合に、デフォルトのモデル・リポジトリーで可能なプロファイルの組み合わせを示しています。これには、複数の他の名前空間の要素と属性が可能なプロファイルが含まれています。

図5. デフォルトのモデル・リポジトリー
図5. デフォルトのモデル・リポジトリー

Compound XML Document Editorは基本のEMFモデルを使用し、タグ挿入の際に許される右クリック・オプションを制限することによって、ディレクテッド編集体系を提供します。これを図6に示します。プロファイルは、EMFエディターによって重視され、EMFエディターはPSMモデルに問い合わせて、その複合ドキュメント・プロファイルに従った妥当なエントリーだけを許します。要素属性はプロパティー・シートのプロパティーとして表されます。

図6. ディレクテッド編集
図6. ディレクテッド編集

ドキュメントを作成したら、ドキュメントで使用された複合ドキュメント・プロファイルをサポートするブラウザーであれば、構成可能な右クリック・メニュー・オプションから直接表示することができます(図7参照)。

図7. レンダリング・オプション
図7. レンダリング・オプション

図8は、X-Smilesブラウザーで表示されたACORDスキーマに基づくAutomobile Loss Reporting(自動車損害報告書)の保険フォームを示しています。

図8. X-Smilesで表示されたXForm
図8. X-Smilesで表示されたXForm

まとめ

Compound XML Document Editorは標準準拠のモデル・ドリブンな複合ドキュメント開発フレームワークであり、動的な複合文書作成とシリアル化をサポートしています。Compound XML Document Editorはモデル・ドリブン開発の概念とEclipse EMFを利用して、柔軟な複合ドキュメントとそれを定義するプロファイルの開発を支援します。

謝辞:Simon JohnstonとSteve Speicherに感謝します。

参考文献

学ぶために

製品や技術を入手するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=XML, Open source
ArticleID=241482
ArticleTitle=モデル・ドリブン複合ドキュメント開発
publish-date=07222005