注意 これは間違ってるかもしれない。実際に実装を使って確かめたわけじゃない。今はめんどくさくて確かめたくないので覚書的なもの。

変数バインドエレメント (xsl:param, xsl:variable) では select でノードセット格納するときと、子要素にテンプレートを書いてごちゃるのとでは違うらしい。後者は結果ツリーフラグメント (Result Tree Fragment) になる。これはルートノードを含む。(select の場合でもルートノードを含むように選択すればルートノードは含まれる。例えば document() を単体で使えば必ずルートノードがノードセットの入る)

<xsl:variable name="foo" select="/bar"/>
<xsl:apply-templates select="$foo"/>
<xsl:variable name="foo">
<xsl:copy-of select="/bar"/>
</xsl:variable>
<xsl:apply-templates select="$foo"/>

前者の場合、ルートノードを含まないノードセットなので、無限ループに陥らずにちゃんとなる。後者の書き方によって $foo に格納されるのは結果ツリーフラグメントで、結果ツリーフラグメントはルートノードを含むので、(現在適用しているスタイルシートの match="/" にマッチして) 無限ループ。

結果ツリーフラグメントをノードセットと混同するとエラい目にあう。例えば Mozilla がクラッシュしたりとか。

  • 結果ツリーフラグメントは、結果ツリーの断片 (フラグメント) を表す。結果ツリーフラグメントは、ルートノードを1つだけ含むノード集合と同様に扱われる。
  • 変数バインドエレメントが select アトリビュートを持たず、コンテンツが空でない場合 (つまり、変数バインドエレメントが1つまたは複数の子ノードを持っている場合)、変数バインドエレメントのコンテンツが変数の値になる。変数バインドエレメントのコンテンツはテンプレートであり、このテンプレートをインスタンス化すると、変数の値が得られる。この値は結果ツリーフラグメントであり、このフラグメントはテンプレートをインスタンス化して生成した一連のノードを子に持つルートノードを1つだけを含むノード集合と同等である。

あっていれば xsl:param にノード集合を渡す。 はノード集合ではなく正確には結果ツリーフラグメントだ。まぁ扱い方的はあまり変わらないけれど……

ってことは <xsl:param name="ggg" select="'unke'"/><xsl:param name="ggg">unke</xsl:param> は違うんだ。実際これらを <xsl:value-of select="$ggg"/> とかやると文字列に変換されるので同じように見えるだけか。この場合前者の方が変換がなくてほんの少し高速かな。

  1. トップ
  2. web
  3. 結果ツリーフラグメント
  1. トップ
  2. xslt
  3. 結果ツリーフラグメント
  1. トップ
  2. xml
  3. 結果ツリーフラグメント

XPathXPath という名前だけでも誤解を招く。Path というだけにディレクトリパスとかを連想する。まぁ、ディレクトリパスとは類似点が多い。UNIX ファイルシステムにおけるルートディレクトリ (名前ナシ) と、ルートノード (展開された名前ナシ) とか、それに省略形による表記を使うとパット見ディレクトリを特定するためのディレクトリパスとなんら変わらない。‘/’ を区切りに使うのが紛らわしい。カレントディレクトリXSLT における カレントノード を混同しやすい。XPath にはカレントノードなんてものはない。コンテキストノード。

XPath は文字列とか数値も表現しえるので、ただたんにどっかのノードを特定する言語ではない。(とはいえ W3C 仕様書には XPath は、XML ドキュメントの一部をアドレッシングするための言語であり とか書いてあって紛らわしい)

だめだもう寝る。

  1. トップ
  2. xpath
  3. XPath の紛らわしさ
  1. トップ
  2. web
  3. XPath の紛らわしさ
  1. トップ
  2. xml
  3. XPath の紛らわしさ

IE (Gecko, Opera, etc) を無視するのと、音声ブラウザを無視するのはおなじ。

  1. トップ
  2. web
  3. IE