I just figured it out, i think.

in the second occurence, i was inside a template which was applied to the
result of a xt:node-set call. 
apparently such results have a different document root, so paths with
"//" don't match any more, usage of id() fails, and so on.

I can't say this is a bug, since this is a non-standard extension after all.
saxon has the same, er, feature.

I haven't figured out how to do the equivalent of xt:node-set() with
xalan/lotusxsl yet (suggestions anyone?), so i can't say what it does.

i can say that result tree fragments continue to ruin my life :).

-mda

--On Sunday, December 19, 1999 10:35 PM -0800 Ray Waldin <rwaldin@xxxxxxxxxxx> wrote:

> "Mark D. Anderson" wrote:
>> i've got a sizable template in which this:
>>    <xsl:value-of select="//core:type[@id='publisher_type']/@id"/>
>> 
>> works correctly when in my main template, but finds no nodes when in
>> a later template.
>> 
>> with my understanding, any path starting with "//" should produce
>> the same thing regardless of where it is located, at least as long
>> as it doesn't use any variables in it, and there is no use of xsl:document
>> above it.
> 
> I'm only guessing here, but could it be that the namespace prefix core: maps to
> different namespaces uris at these two points?  That's somewhat variable, isn't
> it?
> 
> For example:
> 
> <xsl:template match="main" xmlns:core="something">
>     <xsl:value-of select="//core:type[@id='publisher_type']/@id"/>
> </xsl:template>
> 
> vs...
> 
> <xsl:template match="later" xmlns:core="something-else">
>     <xsl:value-of select="//core:type[@id='publisher_type']/@id"/>
> </xsl:template>
> 
> or worse...
> 
> <xsl:template match="worse">
>     <xsl:value-of select="//core:type[@id='publisher_type']/@id"/>
> </xsl:template>
> 
> I know it's a stretch, but these three templates return different results for
> the same document.
> 
> -Ray




 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list