ここ3ヶ月間、XMは徐々に形を整えてきました。XMで私が目指したことは、XMLおよびXSLTを使用する低コストのWebパブリッシング・ソリューションを開発することでした。多くのWebマスターたちは、XMLおよびXSLTの使用に尻込みしています。それは、これらがあまりに複雑に見えるためです。私は、XMがこれらのテクノロジーを近づきやすいものにしてくれることを期待しています。
現行バージョンで誇れるものとして、変更されたファイルだけにスタイル・シートを適用する使いやすいメカニズムと、サイト・リンクの管理および保守を行うリンク管理があります。最新のXMでは、複数のスタイル・シートもサポートするようになり、しかもそれらに簡単にパラメーターを渡すことができます。このように備わった機能は大したものではありませんが、XMは、実際のWebサイトのパブリッシングに関する限定されたテストで、効果があることが確かめられました。私は、XMの助けを借りて、3つの異なるWebサイトを保守してきましたが、XMは十分な働きを示してくれました。
XMには改善の余地がまだたくさんありますが、今月は、1つの重要な新規機能だけを追加することにします。来月は、「XMLの実践」コラムの表舞台に別のプロジェクトを登場させる予定ですので、この先数ヶ月はそれに焦点を絞ることにします。もちろんこのプロジェクトに飽きてしまったわけではありませんが、磨きをかけるためには、何がうまく行ったのか、また、どこを改善する必要があるのかなど、さらに多くのフィードバックが必要なのです。XMについては、さらにフィールド・テストを行う予定です。それとともに、読者(そう、あなたです) からのフィードバックが集まることも期待しています。しかし、何もせずに立ち止まっているわけにはいきませんので、次回のコラムでは新規プロジェクトとしてSAXハンドラー・コンパイラーを立ち上げることにします。
今月XMに対して加える改善は、ファイル・リストを自動的にコンパイルする機能です。これは、ダウンロード・ページと目次の保守に役立つはずです。
なぜ今、別のプロジェクトに移るのでしょうか? 理由はたくさんあります。編集者と交わした、一連のオープン・ソースのXMLアプリケーションの作成プロセスを記述するコラムを書くという約束を果たすために、時間を割く必要があることも確かです。しかし、さらに重要な理由は、XMに関するフィードバックを集める必要があるということです。
私は、基本的にはユーザー・インターフェース開発のつもりでXMと取り組んできました。XMはGUIではありませんが、私の当初の目的は、必ずしもユーザー・フレンドリーなツールではないXSLTプロセッサーを利用し、これをXMに組み込むことによって、Webマスターにとって近づきやすいものにすることでした。基本的にXMは、TrAXを媒介とした、実現可能なユーザー・インターフェースの1つです。
ユーザー・インターフェース開発には、多くのプロトタイピングと試行錯誤が欠かせません。ユーザーからのフィードバックに勝るものはありません。たとえば、私は最初、XMには1つのスタイル・シートだけをサポートさせようと考えていました。この方法は理論的には正しいのですが(1つのスタイル・シートで多数のXMLボキャブラリーを処理することは可能です)、試してみると、私が期待していたほど便利ではないことが分かりました。そこで、別の戦略を採用してみたところ、たいへん満足のいく結果が得られました。読者の中には、私がさらに時間を割いてXMの設計を前進させなかったことに、驚きを表した人々がいました。この説明により、私がこの最初のプロジェクトのプロトタイピングを唐突に始めた理由を理解していただけると期待しています。
これまで私は、XMを2つのWebサイトでテストしてみました。1つはananas.org、もう1つは現在も開発中の別のサイトです。この経験は役に立ちましたが、この2つのサイトから学べることは限られています。将来の開発の方向を決めるためには、さらにフィードバックが必要です。私の会社Pineapplesoftがかかわっている、他のいくつかのWebサイトでもXMを使用するつもりでいますが、読者にも、このソフトウェアを試す機会を提供し、気付いた点を報告していただきたいと思います。進行中のターゲットをテストすることはできないでしょうから、数か月中断して皆さんのご意見に耳を傾けることには、意味があるはずです。
そういう訳ですから、どうか皆さんのWebサイトでXMを試してみてください。現在Webサイトをお持ちでない方は、Geocitiesなどのサービスにサイン・アップしてフリー・スペースを取得し、個人ページを開設するか、地元での交流のためのサイトを構築するかしてください。
このセクションでは、XMのインストールおよびテストを行うための方法を要約します (特定の機能に関する詳細については、XMを紹介したコラム XMの紹介: 手ごろなコンテンツ・マネージャー を参照してください)。問題が発生したときには、ananas-discussionメーリング・リストに報告してください ( 参考文献 を参照)。
最初に、最新バージョンのXMをダウンロードする必要があります。通常は、最新のバージョンはCVSリポジトリーからアクセスすることができます。しかし、Windowsのバッチ・ファイルとコンパイル済みクラスを含む、パッケージ化されたバージョンのほうが便利だと思います。このパッケージ化されたバージョンをダウンロードし、unzipしてください。 参考文献 にすべてのリンクが記載されていますので、参照してください。
次の3つのディレクトリーを作成してください。
- 最初のディレクトリーは、使用するXMLファイルが入るソース・ディレクトリーsrc です。
- 2番目のディレクトリー rules にはXSLTスタイル・シートが入ります。最も一般的に使用するスタイル・シートには、default.xslという名前を付けてください。そのほかのスタイル・シートは、処理命令を介して参照されます。
- 3番目のディレクトリーは、結果ディレクトリー publish です。XMがHTMLファイルを収容するのに使用されます。
いくつかのXMLファイルと、少なくとも1つのスタイル・シートを用意してください。次のように、srcと publish の2つのディレクトリーをパラメーターとして渡して、XMを実行してください。
java org.ananas.xm.Console src publish |
パッケージ化されたバージョンには、ananas.org Webサイトのソース・コードがサンプルとして含まれています。ヒントとして利用してください。
先月、ディレクトリー読み取り機能について触れましたが、今回はこれについて詳しく説明します。この機能は、索引ページ(ダウンロード・セクションなどのように、主としてファイルへのリンクからなるページ)または目次や用語集などのページで役に立ちます。Webマスターならご存じでしょうが、大量のリンクのリストを手作業で保守するのは、非常に退屈な作業です。
ダウンロード・セクションを用意する場合、Webマスターは、ファイルを選択して用意するだけでなく、実際のファイルへリンクする1つ以上のページの作成も行わなければなりません。ファイルが使用可能になったり、古いファイルが削除されたりしたときに、新規リンクの更新を忘れてしまいがちです。同様に、1つの文書が複数のページにまたがっている場合、Webマスターは、その文書のすべてのページへリンクする目次を作成する必要があります。この場合にも、目次ページの保守では間違いが起こりやすく、セクションが抜けているという通知を受けることは珍しくありません。用語集でも、基本的に同じ問題が起こります。
編集者やWebマスターが人間である限り、長々としたデータ・リストの保守を得意としないことは明らかです。こうした退屈な作業は、コンピューターやXMのディレクトリー読み取りに任せるに限ります。ディレクトリー読み取りを行うと、XMはファイルのリストを含むXML文書を作成し、XSLTスタイル・シートを使用してその文書を適切なWebページに変換します。このXML文書は リスト1 のようになります。この方法の最大の利点は、XMが実行のたびにファイル・システムからそのディレクトリーを読み取るため、リンク・ページが常に最新の状態に維持されるように保証されることです。
余談ですが、私はこれを (JSPまたはそれに類似したテクノロジーを使用する)動的なWebサイトと、Webマスターがすべての文書を手作業で更新する必要のある純粋に静的なサイトとの間に位置する、興味深い中立地帯であると考えています。XMは、静的サイトを構築しますが、ソフトウェアを使用することにより、最も退屈なページの作成と保守を自動化できます。
ディレクトリー読み取り自体は DirectoryReader クラスが行います。このクラスは、このコラムに含まれる他のすべてのリストとともに、オンラインで入手することができます( 参考文献 を参照)。効率を高めるために、DirectoryReader はXML文書をディスクには書き込まず、代わりに、SAXイベントを起動してこの文書を記述させます。
これは、特別な手間をあまりかけずに一時ファイルの作成と構文解析を省略する、ちょっとした最適化です。より一般的な設定を行うのであれば、DirectoryReaderに一時ファイルへのXML文書の保管を行わせるという方法があります。この場合、文書はパーサーを介してXSLTプロセッサーに送り込まれます。この様子を図1に示します。
図1. DirectoryReaderによるXML文書の作成
ただし、DirectoryReader
をコーディングする際には、おそらく開始タグ、終了タグ、および属性を書くメソッドも使用できると思います。したがって、あまり手間をかけなくても、ディレクトリーをContentHandler
の
startElement()、endElement()、startPrefixMapping()、およびendPrefixMapping()
に呼び込むことができます。これらがどのように機能するのかは、
実用的なXML: 処理命令およびパラメーター
の中の、
LinkFilter
クラスの作成に関する記述を参照してください。
DirectoryReader は、このソリューションを使用してSAXパーサーをシミュレートします。このファイルがディスクに書き込まれることはありません。ファイルは、直接XSLTプロセッサーに送り込まれます。図2に示すように、すべてのことがメモリー内で行われますので、このほうがやや効率がよくなります。
図2. パーサーをバイパスするDirectoryReader
XSLTプロセッサーの立場からは、DirectoryReader も通常のSAXパーサーも違いはありません。私の立場からは、DirectoryReaderには二重の利点があります。まず、このほうがやや効率がよいこと、そして、おそらくはこちらのほうが重要ではないかと思いますが、読者にもすぐに分かるとおり、XMLフィルターを使用して実際のXML文書の中にディレクトリー文書を組み込むほうが簡単であることです。
ここで注意を添えておきますが、これはXMLが単なる構文ではなく、標準データ・モデルであることも表しています。SAXのイベントの流れは、XML文書を適切に記述するようになっています。読者は、ファイルをディスクに書き込んだり、XMLの構文に気をつかったりすることはありませんが、この文書はデータ・モデルに従っていますので、間違いなくXML文書です。
リスト2 は、文書を作成する DirectoryReader.read() です。これは、標準のJava Fileオブジェクトを使用してディレクトリーを読み取り、各プロパティーの属性をFile オブジェクト内に作成します。このメソッドの作成には、前のコラムで紹介したContentHandlerExtractor が役立ちました。
DirectoryReader は、完全なXML文書を作成するか、あるいは別の文書に組み込まれる文書を作成するように設計されています。この振る舞いは、embeddedプロパティーが制御します。唯一の相違点は、DirectoryReader が startDocument()および endDocument() を呼び出すかどうか、ということだけです。
DirectoryReader には、File によって定義された属性のほかに、isMarked という属性が備わっています。isMarkedは、現在のファイルを識別するために使用されます。スタイル・シートで isMarked属性を使用して、現在のファイルへのリンクを除去することができます。
Webマスターは、DirectoryReader を呼び出すために、XML文書を作成して、ファイル・リストが必要となる個所に特別なxm:Directory エレメントを挿入しなければなりません。ananas.orgのホーム・ページであるリスト3では、xm:Directoryエレメントによってプロジェクトのリストが置き換えられています。このリスト自体は、サブディレクトリーのリストを基に、スタイル・シートによって作成されています。
リスト3. ananas.orgのホーム・ページ
<?xml version="1.0"?>
<?xm-xsl-param name="sponsor" value="ananas"?>
<article xmlns="http://www.psol.com/2001/docbook"
xmlns:xm="http://www.ananas.org/2001/XM/Walk">
<articleinfo>
<title>ananas.org</title>
<subtitle>open-source software for the 'Working XML' column</subtitle>
<author><firstname>Benoît</firstname><surname>Marchal</surname>
<affiliation><orgname>Pineapplesoft sprl</orgname></affiliation></author>
<copyright>
<year>2001</year>
<holder><ulink href="http://www.marchal.com/">Benoît</ulink></holder>
</copyright>
</articleinfo>
<simpara><citetitle pubwork="journal">ananas.org</citetitle> is the
companion Web site for the <citetitle pubwork="series">Working XML
</citetitle> column by <author><firstname>Benoît</firstname>
<surname>Marchal</surname></author>. <citetitle pubwork="series">
Working XML</citetitle> is published on <citetitle pubwork="journal">
<ulink href="http://www.ibm.com/developerWorks">developerWorks</ulink>
</citetitle>.</simpara>
<simpara>The source for the <citetitle pubwork="series">Working XML
</citetitle> column is being distributed through this site. Currently
the following projects are available:</simpara>
<xm:Directory dir="." markSource="true"/>
</article>
|
WalkFilter は xm:Directory エレメントをインターセプトし、それらを DirectoryReaderへの呼び出しによって置き換えます。LinkFilter と同じように、WalkFilter はXMLFilter としてインプリメントされています。しかし、WalkFilter がXMLファイルをプリプロセスするのに対し、LinkFilterはHTML文書をポストプロセスするように設計されています。
WalkFilter
は単純です。
リスト4
に示されているように、WalkFilter は、startElement() 内に
xm:Directoryがあるかどうかをテストします。WalkFilter には、xm:Directory
エレメントの内容を廃棄するための論理が追加されています。明らかに、そのような内容がフィルターを通っては困るのです。
私は、WalkFilter と DirectoryReader をともに xm 接頭部にマップしているのですが、これらのネーム・スペースは異なっています。WalkFilterのほうが、より一般的なネーム・スペース (http://www.ananas.org/2001/XM/Walk)を使用します。データベース、ディレクトリー・サービス、およびEメール 用に同じようなリーダーを将来追加しようと考えているからです。2つのネーム・スペースは、スタイル・シート内の2つのエレメントを区別するのに役立ちます。
xm:Directory 内のパスは、文書のディレクトリーを基点とした相対パスですので、WalkFilterでは、文書へのパスが必要です。SAXは、呼び出し元がディレクトリーを設定できるように、標準のプロパティー・メカニズムを提供します。WalkFilterは、同じことを行うために、setProperty() メソッドと getProperty() メソッドをインプリメントしています。
最後に行う作業は、moverから WalkFilter を使用することです。TRaXを使用すれば、フィルターを介してXML文書をプリプロセスするのは、さほど難しくありません。SAXSourceのコンストラクターの1つが、パラメーターとして XMLReader を (当然、XMLFilterも) 処理します。これによりXMLFilterが使用可能な場合は、StylingMover を少し変更するだけで、このコンストラクターを使用することができます。リスト5からも分かるように、変更は最小限にとどまっています。
リスト5. StylingMoverによるXMLファイルのプリプロセス
if(xmlFilter != null)
{
try
{
xmlFilter.setProperty(SOURCE_FILE,sourceFile);
}
// it's OKay if it does not recognize the property, it
// just means it's not one of our filter
catch(SAXNotRecognizedException e)
{ }
source = new SAXSource(xmlFilter,JAXPHelper.toInputSource(sourceFile));
}
else
source = new StreamSource(sourceFile);
transformer.transform(source,result);
|
ただし、重大な問題が1つあります。WalkFilter が入力文書を変更してしまうため、ファイルの最終変更日時を基にして、そのファイルのスタイルを変更すべきかどうかを判定することはできなくなります。たとえば、 リスト3 が変更されていないとしても、ディレクトリーが変更されている場合には、文書のスタイルを変更する必要があります。
あるディレクトリーの最終変更日時をJavaで検出する方法が、私には思い付きません(対処方法をご存じの方は、メーリング・リストに載せてください)。唯一の安全な解決策は、XMの実行時に必ず文書のスタイルを変更して、スマート・ビルドを無効にしてしまうことです。この方法は、小さなサイトではうまくいくでしょうが、大規模サイトで使用すると、問題がありそうです。妥協策として、xm:Directoryタグの付いたファイルを別の方法で拡張することにしました (.xm を選びました)。
リスト6 は、MoversSupervisor から抜粋したものです。これを見てお分かりのように、StylingMoverが2回登録されています。1回は通常のXMLファイルを登録するためで、もう1回はXM固有のファイルを登録するためです。XM固有ファイルの登録では、WalkFilterによるプリプロセスが行われています。
リスト7 は、ananas.orgのスタイル・シートからの抜粋です。これを リスト3 に適用すると、プロジェクトのリストが作成されます。このスタイル・シートは、各プロジェクト・ディレクトリーにindex.xml ファイルが含まれていることを想定しています。スタイル・シートは、このファイルをロードし、そのタイトルとサブタイトルを抜き出して、ハイパーリンクを作成しようと試みます。これは、ディレクトリー読み取りを使用して目次を作成する方法を示しています。
しかし、落とし穴が1つあります。デフォルトでは、XSLTプロセッサーは、スタイル・シート・ディレクトリーにある文書をロードするようになっています。XMは、まったく別のディレクトリーにスタイル・シートを置きますので、XSLTプロセッサーはindex.xml 文書を検出してくれません。
私は、x-source: という新しいURLフォーマット (このx- は、標準のURLフォーマットではないことを表すものです)を考案しました。これは、スタイル・シートではなく現行の文書を基準にしてファイル名を解決します。そして、 リスト8 に示すように、ReferenceResolver クラスを修正して、これらの x-source: URLを認識し、処理するようにしました。プロセッサーがReferenceResolver を使用して文書とスタイル・シートをロードすることは、覚えておいででしょう。
これで、XMの最初のリリースは出来上がりです。このプロジェクトを通じて、私たちはSAXAPIとTrAX APIの興味深い機能を学ぶことができました。すでに申し上げたように、ぜひこのパッケージをダウンロードして、読者自身でテストしてみてください。
-
このプロジェクトのコードは、
ananas.org
からダウンロードすることができます。developerWorksのこのリンクをたどって、
CVS repository
に移動してください。またananas-discussionメーリング・リストおよびXMのパッケージ化バージョンにもアクセスできます。ぜひメーリング・リストに参加して、プロジェクトに知恵を貸してください。
-
ご希望の場合は、
ZIPファイル
も入手可能です。
-
XMは、XSLTプロセッサーとして
Xalan
を、またXMLパーサーとして
Xerces-J
を使用します。もともとは、XalanはIBMのLotusソフトウェアによって開発されたもので、またXercesはIBMによって開発されたものです。IBMはそれらのコードをApache
Foundationに寄贈しています。
-
XMを使って作成したWebサイトを掲載するためのWebスペースを必要とする方は、無料の
Geocities
に申し込んでください。ホスト・サービスのための料金を払ってもよいという方のためには、
Pair Network
が信頼性の高いホスト・サービスを低料金で提供してくれます。

Benoit Marchal氏は、ベルギーのナミュールを拠点にしたコンサルタントおよび著述家です。彼の著作には、XML by Example(Que社、邦訳: インプレス社「実例で学ぶXML」) と、Applied XML Solutions とがあります。Gamelanにコラムを寄せています。 Ben氏は、1998年にPineapplesoft Linkを設立したときに、e-zineの発行についてじかに学びました。www.marchal.com のサイトで、彼のe-zineを購読したり、彼の最新プロジェクトを詳しく見ることができます。