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は保留。
コメントする