2008年10月アーカイブ

XSLT 1.0の言う所の結果ツリーフラグメントを使わないように、XSLT文書を書き直しました。今まで結果ツリーフラグメントをノードセットに再評価してxsl:for-eachをかけていた所はすべて、デリミタで分けられた文字列を再帰で順番に処理するようになりました。どちらがより負荷が大きいのか判りませんが、何れにせよこの程度なら大したものではなかったようです。

さて、このように書き直した事で、IE 6.0以降やSablotronだけでなく、libxsltやFirefox 2.0以降でも変換できるようになった為、Firefox 2.0以降の場合も変換をクライアントに委譲する事にしました。そう言えばOperaもdocument関数が実装されるんだったな、と思って調べてみた所、Opera 9.50から正式に実装されていたようです。これならOperaでも丸投げできる、と思っていた所、案の定残念な事にOperaではdocument関数がうまく機能していないようです。

はて、こんな事でOpera 9.50のChangelogにAdded support for XSLT document() function.などと載せるものだろうか......と思い、少々実験した所、次の事が判りました。

XSLT文書と同階層のelements.xmlに対して、document( 'elements.xml' )

問題無く読めます。

XSLT文書の親階層のelements.xmlに対して、document( '../elements.xml' )

問題ありません。

XSLT文書の親階層のdataディレクトリの中のelements.xmlに対して、document( '../data/elements.xml' )

読めません。

/reference/xhtml11/dataのelements.xmlに対して、document( '/reference/xhtml11/data/elements.xml' )

勿論読めません。

......何この不思議実装。Operaの開発チームの人達は、スタイルシートとデータを別のディレクトリに置くって事を誰一人しなかったのか。それともこんな事が起こるのは僕の所だけ?

document関数が失敗する事によって変換すべてが失敗する事はありませんが、document関数が空のノードセットしか返してくれないので、結局document関数は使えません。これはdocument関数の振る舞いがおかしいと言うよりは、単にフルパスの解決に失敗しているだけのように思えるので、もしバグであれば簡単に直りそうですが......どこに言えばいいんだろ。ちょっと探してみるか。

追記: レポートの為にもう少し詳しく現象を調べようとした所、どうやらdocument関数の戻り値が必要になった時点でGETリクエストは送っている模様。しかし戻り値は空のまま。というより、XSLTプロセッサ自体がその時々で挙動が変わったりして(何に依存しているのかはもう調べるの面倒)、不安定。ひょっとしたら根の深い問題なのかも知れない。やっぱりOperaは保留。

今手許で使えそうなXSLTプロセッサ。XSLT 2.0をサポートするXSLTプロセッサは、Java VM上で動くSaxonだけしか今の所無いらしいので(知らないだけかも)、多分すべてXSLT 1.0に準拠しているはず。従って、xsl:param、xsl:variable要素の内容はResult Tree Fragmentsになります(ここではノードセットと結果ツリーフラグメントで書きました)。

で、例によって、XSLT 1.0では結果ツリーフラグメントに対して文字列操作しか許されないんですが、WWWWARDで使っているXSLT文書では結果ツリーフラグメントをノードセットに評価し直すという(XSLT 1.0勧告には無い、各実装の独自拡張の)機能を使っているんですね。別にこれはそういう機能がある事を知ってから使い始めた訳ではなく、「こう書けると綺麗だ」と思って書いたら使えて、あとで確認してみると独自拡張だったという......(あんまりよろしくない経緯)。それはともかく、IEに搭載されているXSLTプロセッサや、PHP 4のSablotronではこれが使えます。しかし、libxsltでは使えない。無論XSLT 1.0でこれをするのは邪道なので使えないのがあるべき姿なのかも知れませんけど......。

現在s26.xrea.comサーバに入っているPHPのバージョンは4.4.8だそうです。Sablotronも使えるようになっています。よって今は問題無いんですが、PHP4のサポートは2007-12-31に終わっています。何れPHP5が取って代わるでしょうが、そのPHP5はSablotronを標準装備していません(PECLに移されたって書いてあるけど、見つからない)。代わりにlibxsltが手厚くサポートされているようですが、前述の通り、libxsltはこの「結果ツリーフラグメントのノードセットとしての再評価」を許していないようです(そういう事をしようとすると、それより深い所の変換がすべてキャンセルされる)。

行くべき道は......

• ほっとく。これは楽で良い。......じゃなくて。
• XSLT文書を書き直す。XSLT 1.0の機能のみをサポートするプロセッサで変換できるように。元々結果ツリーフラグメントの再評価なんてやりだしたのは、綺麗に書けるからであって、必要不可欠だったからではなかった、はず......(うろ覚え)。尤も単なる文字列処理だけでやろうとすると、若干トリッキーになるか、再帰が深くなるかしそうだけど、許容範囲かな。
• XSLT 2.0プロセッサ全盛時代の到来を待つ。テンポラリツリーならノードセット操作も問題無し。唯一の問題は、それがいつ来るのか。ひょっとしてもう来てたりして(時事に疎い)。......無いか。夢か。

という訳で、今の内に書き直すべきでしょうか。PHP5+libxsltで変換できると、ローカルマシンでFirefoxを使って変換結果確認ができるので若干幸せなんですよね。若干。

さあ、それは良いとしても......libxsltって、xsl:templateのpriority属性は無視なんですかね? てっきりlibxsltではxsl:importが使えないと思っていた時(今さっき)に、xsl:includeを使ってなんとかしようと思ったら、priorityが違っても"duplicate name!"って怒られたのですが......いや、これはさっきまでテンプレートルールの衝突の解決方法を知らなかったなんちゃってXSLTユーザの苦情じゃないですね、はい。

公開から随分時間が経ったようですが、Movable Type 4を導入してみました。

以前はMovable Type 3を入れており、当然バージョン4が出たのも知っていたのですが、無償の個人ライセンスがバージョン4になってもある事を知らず、今までずっとバージョン3を使っていたのです(探し方が悪かったのか、あるいは公開当初は有料ライセンスの差別化の為に用意されていなかったのか)。

インストール時に"Can't locate object method "lowercase_jcode" via package "MT::I18N::default" (perhaps you forgot to load "MT::I18N::default"?)at lib/MT/I18N/default.pm line 110."などと言われて動かなかったトラブルはhttp://www.movabletype.jp/faq/cant-locate-object-method-lowe.htmlで解消され、ドキュメントに書いてあった手順も大体踏みましたが、まだまだ慣れません。むしろMovable Type 3にも慣れていたとは言い難いような。とりあえずあちこち触るしかないですね。

面倒くさいMovable Type 4へのバージョンアップをしようと思い立った理由は、4.2以降に付いたらしいコミュニティ機能(掲示板など)に帰せられる所が大きかったりします。AntiSpamなんちゃらが付いているMovable Typeなら、世の掲示板のように荒れない掲示板がお手軽に準備できるんじゃないかな、と思いまして。

何で掲示板なんかを欲しいと思ったかというと、現在水面下で妄想中の(まだ全然具体的なものはできあがってませんが)企画で必要になりそうだった為です。その企画の方向性はWWWとは殆ど関係無かったりしますが......別アカウントは取れそうにないしなあ。しかし50MBは少ないなあ。

ちょっとアカウント名(w4ard)とサイト名(WWWWARD)の幅を狭めすぎたかと後悔しています。