XMLプラグインは、これまでも数多く開発されてきましたし、今でも次から次に新しいものが登場しています。この記事で主に取り上げるのはXMLBuddyというプラグインです。このプラグインの多彩な機能セットには、XML文書開発に必要なほとんどの機能が用意されているからです。ただし、タスクの種類によっては、その他のプラグインのほうが豊富なユーザー・オプションを提供している場合もあるので、それらのプラグインについても少し触れておきます。もちろん、この記事では基本的なXML編集機能について説明しますが、Eclipseは、このXML機能に限らず、無数のツールや機能を手軽に利用するためのダイナミックなフレームセットであることをまず強調しておきたいと思います。
Eclipseにはすでに、XML構文を強調表示するだけの簡単なXMLエディターのソース・コードが用意されています。org.eclipse.ui.editors パッケージは、Eclipse Platform用の標準的なテキスト・エディターとファイル・ベースの文書プロバイダーを提供しており、そのパッケージに含まれているクラスを拡張したのがこのXMLエディターです。この簡単なXMLエディターをサンプル・コードとして利用し、独自のEclipse XMLプラグインを開発することもできます。ソース・コードの生成には、Eclipseプロジェクト・ウィザードを活用しなければなりません。また、そのソース・コードを自分でコンパイルする必要もあります。では、その方法をこれから見ていきましょう。
この簡単なXMLエディターを構築するには、「File」=>「New」を選択してから、「Project」を選択します。プロジェクト・ウィザードが表示されたら、「Plug-in Development」=>「Plug-in Project」を選択します。
Eclipse Platform Runtime Binaryにプラグイン開発環境が含まれていないと、「Plug-in Development」オプションが表示されません。その場合は、eclipse.orgのダウンロード・ページからEclipse Platform Plug-in SDKをダウンロードしてください(記事の末尾の参考文献にそのページのリンクがあります)。
「Next」をクリックします。プロジェクト名(たとえばorg.my.eclipse.xmleditor) を指定してから、「Next」をクリックします。「Plug-in Project Structure」画面ではデフォルト値をそのまま受け入れます。次に、「Create a plug-in project using a code generation wizard」オプションと、「Plug-in with an editor」オプションを選択します。これで、XMLエディターのソース・コードが自動的に生成されます。
今度はそのソース・コードをコンパイルします。「Next」をクリックしてから、次の「Simple Plug-in Content」画面で「Finish」オプションをクリックします。「Project」メニューから「Rebuild All」を選択してプロジェクトを構築してください。
次に、「File」=>「Export」を選択して、editor.jar ファイルを作成します。Eclipseを終了して、org.my.eclipse.xmleditor plugin ディレクトリー全体をコピーします。Eclipseを再び起動して、プロジェクトにXMLファイルを追加すれば、XML構文が強調表示される様子を確認できます(図1 を参照)。ただし、この簡単なXMLエディターでは、妥当性の検証や構文のチェックはできません。
図1. EclipseのXMLエディターに用意されている簡単な構文強調表示機能
Eclipse用の最も有名で最も先進的なXMLエディター・プラグインは、Bocaloco Softwareが開発したXMLBuddyです(参考文献にリンクがあります)。XMLBuddyは、EclipseにXML編集機能を追加するフリーウェア・プラグインで、ユーザー設定が可能な構文色分け機能、DTD対応のコード・アシスト機能、妥当性検証機能、同期アウトライン・ビュー機能などを搭載しています。また、WorkspaceにXMLパースペクティブを追加するという役割を果たしますし、XML文書とDTDのための新しいプロジェクト・テンプレートも用意しています。XMLBuddyのインストール方法は、その他のEclipse用プラグインのインストール方法と同じであり、プラグイン・アーカイブをEclipseのメイン・インストール・ディレクトリーの直下にある\eclipse\pluginsサブディレクトリーにunzipするだけで済みます。ただし、Eclipseの再起動が必要です。図2 はXMLBuddyの実行中の画面です。
図2. 実行中のXMLBuddy: メイン・エディター・ウィンドウ(XMLアウトライン・ビュー)
XMLはメタ・マークアップ言語です。XMLの要素は、開始タグと終了タグ、それにその両者に挟まれているデータから成っているため、構文強調表示機能だけでなく、いろいろな編集機能を必要とします。XMLBuddy (現行バージョンは0.2) は、Eclipseに以下のようなXML編集機能を追加します。
- 書式設定機能。XML文書の全体または一部を選択して書式を設定できます。
- 先進的な構文色分け機能。「Window」=>「Preferences」=>「XML」=>「Colors」メニューで、XMLコードの色分けを設定できます。色分けの設定は、通常のXML文書、DTD (内部サブセットと外部サブセットの両方)、JSPファイルに適用されます。図3 は、構文強調表示機能のデフォルト設定を変更する画面です。
図3. XML構文強調表示機能のデフォルト設定の変更
- XMLコード・アシスト機能。文書のDTDに基づいて、要素名や他のタグ名、属性名、属性値などを指定するためのアシスト機能です。
-
拡張文字符号化サポート機能。XMLBuddyは、XML 1.0仕様に準拠した
<?xmlという文書符号化宣言を自動検出し、見つかればそれを尊重します。また、すべてのXML文書についても、1つのファイルについても、デフォルトの符号化を指定できます(このあとのXMLコードの妥当性検証と文字符号化を参照)。 - アウトライン・ビュー機能。アウトライン・ビュー・ウィンドウには、文書内の要素構造が表示されます。デフォルトでは、編集作業と同時にアウトラインが自動的に更新されていきます。文書のロジックをざっと見渡したいときに便利な機能です。
- DTD生成機能。文書の内容からDTDを自動生成できます。また、XMLBuddyはインターネット・ベースのDTDをローカル・マシンにキャッシュするので、DTDと関連文書を1度ダウンロードするだけで何度でも使用できます。
XML文書で一番難しいのは、文書内部の妥当性 (文書ロジックの一貫性) のチェックです。まず必要なのは、すべてのタグや定義の配列や名前が正しいかどうかをチェックするための構文検証です。構文検証に合格してはじめて、XML文書は整形式であることが確認され、文書の論理構造の検証に入ることができるようになります。そのようなXML文書の妥当性を検証するプログラムをXMLパーサーといいます。
これから取り上げるEclipse用のXMLプラグインはすべて、XMLの妥当性検証を実行し、コード内の問題点やエラーを検出する機能を備えています。たとえば、XML文書を開く時点で、XMLパーサーによってエラーが表示されることがあります。その場合は、正確なエラー・コード、エラー・テキスト、さらにはエラーの原因箇所についての確認ができます。また、必要なときにXML文書の妥当性を検証することや、文書保存時の自動検証を設定しておくことも可能です。その逆に、妥当性検証エラー・タスクを全体としてオフにすることもできます。XMLBuddyプラグインは、システム提供のXMLパーサーを使用しますが、Eclipse Platformには、Xerces (XML4J) という最高クラスのXMLパーサーが用意されていることも忘れないでください(ダウンロード情報については、参考文献を参照)。もちろん、Xercesやシステム・パーサー以外は使えないということではありません。「Run」=>「External Tools」=>「Configure」を使って、他のXMLパーサーを指定することもできます。
XMLBuddyのもう1つの重要な機能は、さまざまな文字符号化のサポートです。たとえば、別々の言語 (ポーランド語と英語など)で書かれたXMLポータブル文書を処理する場合に役立つのがこの機能です。ポーランド語の文字符号化には主に3つの方法があることを考えれば、これは簡単な作業ではありません。第1にWindows 9x/2000で使用するWindows Latin-2 (CP1250)、第2にインターネットやUNIX系のシステム (Linuxなど) で使用するISO Latin-2 (ISO8859-2)、第3にMacOSとMacOS Xがあります。これらはすべて別々のポーランド語文字符号化標準を使用しています。
基本的に、XMLBuddyでは文字符号化の問題に2つの方法で対応しています。つまり、XML文書のファイル内容に基づいて符号化宣言を自動検出するか、文書にデフォルトの符号化を設定するかのいずれかです。デフォルトの符号化は、ワークスペース単位でもリソース単位でも設定できます。XML符号化設定を開くには、「Window」=>「Preferences」=>「XML」=>「Encoding」を選択します。
しかし、このような文字符号化対応については1つの問題が残ります。要するに、XMLの場合、ワークベンチ単位の1つの符号化ですべてに対応することは不可能だということです。XML文書は世界中のさまざまな場所から送られてくる可能性があります。先方から送られてくる文書の符号化をこちらで指定することは不可能な場合が多いですし、符号化の違いに基づいて作業の仕分けをすることもまず無理でしょう。1つの符号化設定が、たとえばJavaソース・ファイルにもXML文書にも適しているというケースはあまり考えられません。このように、1つのグローバル設定で対応しきれない場合のために、XMLBuddyには文書単位のプロパティーが用意されています。もちろん、プロジェクト内の各ファイルのプロパティーをいちいち設定するというのは、容易なことではありませんが、自動検出できない特殊な符号化を使っている文書や、符号化宣言のない文書が送られてきた場合には、プロパティーを設定する以外に方法はありません。ファイルの符号化プロパティーを開くには、そのファイルを右クリックしてから、「Properties」=>「XML」=>「Encoding」を選択します。図4 は、そのようにしてグローバルな文字符号化を設定する画面です。
図4. EclipseでXML文書のグローバルな文字符号化を設定する画面
XML SchemaとはXMLスキーマ定義言語の仕様であり、XML 1.0に準拠した文書の構造記述と内容制御のための方法を定めています。XMLの名前空間機能の利用に関する規定もあります。このスキーマ言語は、それ自体XML 1.0で記述するものであり、名前空間も利用します。XML 1.0のDTDの機能を実質的に再構築し、大幅に拡張したものが、このXML Schemaです。ここでは、DTDに数多くの制限があることを押さえておきましょう。
- 要件が複雑な場合に内容モデルを使いにくい。
- 名前空間のサポートがない。
- モジュール性と再利用のためのサポートが限られている。
- 拡張や宣言継承のサポートがない。
- DTDのサイズが大きくなると、書くのも読むのも更新するのも難しく、関連スキーマのセットを定義するのも難しい。
- 自己記述のための構造的なしくみが組み込まれていない(唯一存在するのは
<!-- comments -->だけ)。 - 属性や要素の文脈に基づく内容宣言や属性宣言ができない(XMLベースの多くの言語はその機能を用意しているが、DTDでは「適用範囲」を絞り込めない)。
- ID属性に関するしくみが初歩的である(つまり、一意性に関する有効範囲が存在しない)。
ところが、XML Schemaにもやはり欠点があります。
- XML Schemaは複雑なので、たまにXMLを使うといった程度のプログラマーにとっては難解すぎる。
- XML Schemaではルート要素になれる要素が1つに限定されていない(したがって、ごく簡単な文書の妥当性検証にも余分の情報が必要になる)。
- 混合内容を書くときに文字データに関する制約を設定できない。
- 属性や要素の文脈に基づく内容宣言や属性宣言ができない(これはDTDの大きな欠点でもある)。
- 宣言から切り離した形でデフォルトを指定できない。
- 要素のデフォルトは文字データに限定される(マークアップを組み込めない)。
XMLBuddyはDTDとXML Schemaの両方をほどよくサポートしていますが、XML Schemaの十分なサポートが必要な場合は、XSD-XML Infoset Browser for Javaプラグインを使用してください(参考文献にリンクがあります)。このプラグインは、W3C XML Schema仕様で定められているXML Schema Infoset Modelを実装したJavaリファレンス・ライブラリーであり、XML Schemaのチェック、作成、修正のためのコードを書くときに非常に便利です。XML Schemaの各コンポーネントを操作するためのAPIのほかに、XML SchemaのDOM対応表現を一連のXML文書として操作するためのAPIも用意しています。特に複数の開発者によるJavaとXMLの併用を可能にしているという点で、XMLベースのスキーマを識別したり作成したりするための標準的な方法を提供していると言えます。
図5. IBM XML SQCのインストール後に可能になるXML Schemaの妥当性検証
このXML Infoset Browserを補足する意味で必要なのが、IBM XML Schema Quality Checker (略してSQC) です(図5 を参照。参考文献にリンクがあります)。このSQCは、W3CのXML Schema言語で書かれたスキーマを入力として受け取り、Schema言語の不正な使用を検出するためのJavaプログラムです。最新のXML Schema仕様に準拠したスキーマを読み込み、XML Schemaのさまざまな制約に適合しているかどうか (妥当であるかどうか) を検証します。適合していない要素を検出すると、診断メッセージを出します。そのメッセージには、問題の解決方法が書かれている場合もあります。<include>、<import>、<redefine> のいずれかの要素情報項目によって多数のSchema文書を結合した形のスキーマについては、そのスキーマ全体のチェックを実行します。また、複数の単体XML Schemaを1回の実行でチェックするバッチ・モードもあります。
便利なXMLプラグインとしては、ほかにもTransclipseやEclipse Tidyがあります(参考文献にリンクがあります)。まず、TransclipseはXML変換用のプラグインです。JAXP準拠のXSLスタイルシート・プロセッサーによってXSLTベースのXML文書変換を実行し、ApacheのFormatting Objects Processor (FOP) によってXSL-FO文書を処理します。j2h (Java to HTML) プラグインの一部として組み込まれているわけですが、そもそもこのプラグインは、Javaソース・コードをHTML、XHTML、LaTeXに変換するもので、構文強調表示機能も付いています。一方、Eclipse Tidyプロジェクトは、XML/HTML文書の書式設定と印刷のためのプラグインを提供しています。その他の情報については、Eclipse用プラグイン・レジストリーの各カテゴリーをご覧ください(参考文献を参照)。
- Eclipse Platformコミュニティーへの参加や、Eclipse Platformのダウンロードについては、eclipse.org にアクセスしてください。Eclipse Platformのソース・コードのライセンス形式はCommon Public Licenseです。eclipse.orgでは、用語集、Eclipseプロジェクトの解説、技術的な記事やニュースグループなども用意しています。Eclipse Platformの白書には、Eclipseの主要なコンポーネントと機能の詳しい解説があります。
- Eclipse Platform Plug-in SDKのダウンロードについては、Eclipseプロジェクト・ダウンロード・ページをご覧ください。
- ApacheのXMLプロジェクト (Xercesパーサーなど) については、Apache.org にアクセスしてください。
-
XSD-XML Infoset Browser for Java のダウンロードについては、eclipse.orgにアクセスしてください。
-
XML Schema Quality Checker のダウンロードについては、IBMのalphaWorks サイトをご覧ください。
- Eclipse Platformの機能に関する入門記事を読みたい方は、Greg Adams氏とMarc Erickson氏によるdeveloperWorks 記事、「Eclipse Platformの利用」をご覧ください。
- Eclipse Platformによるアプリケーション開発の入門記事を読みたい方は、David Gallardo氏によるdeveloperWorks 記事、「Eclipse Platform入門」をご覧ください。
- 独自のEclipseプラグインの作成に興味がある方は、David Gallardo氏によるdeveloperWorks 記事、「Eclipseプラグインの開発」をご覧ください。
- 1人の開発者がXM (XMLとXSLTに基づく簡単なコンテンツ管理公開ソリューション)とEclipseを統合した方法を調べてみたい方は、Benoit Marchal氏によるdeveloperWorks 記事、「XMとEclipseの統合」をご覧ください。
- XMLに関する豊富な参考文献がW3CコンソーシアムのWebサイトにあります。
-
Transclipseプラグインのダウンロードについては、SourceForge.netにアクセスしてください。
-
Eclipse Tidyプロジェクトの入手についても、SourceForge.netにアクセスしてください。
-
j2h (Java to HTML) プラグインについてお調べください。
-
Eclipse用プラグイン・レジストリーを閲覧できます。
-
Eclipseユーザー とXML開発者 のための豊富な参考文献がdeveloperWorks にあります。
Studio B の製作者であるPawel Leszek氏は、独立ソフトウェア・コンサルタントであると同時に、Linux/Win/Mac OSのシステム・アーキテクチャーと管理を専門としています。彼は多数のオペレーティング・システム、プログラミング言語、ネットワーク・プロトコルの経験者で、特にLotus DominoとDB2に深い知識があります。また、Pawelは、LinuxWorld のシリーズ記事の著者であるとともに、ポーランド版PC World のLinux関連コラムニストでもあります。Pawelは、ワルシャワで妻とかわいい娘と一緒に暮らしています。質問やコメントを是非お寄せください。Pawelの連絡先は、pawel.leszek@ipgate.pl です。