Came across something unexpected while doing the if/else hack to supply a
node to generate-id.
I have <xsl:key match="stuff | morestuff"
use="generate-id(ancestor::tr[predicate] |
ancestor::tr[not(predicate)]/preceding-sibling::tr[predicate])"/>
Some data
<wrapper>
<tr pred="true" id="A">
<stuff/>
<stuff/>
</tr>
<tr pred="true" id="B">
<stuff/>
<stuff/>
</tr>
<tr pred="true" id="C">
<stuff/>
<stuff/>
</tr>
<tr pred="false">
<morestuff/>
</tr>
</wrapper>
So here stuff should take the id of the tr parent and morestuff shouldl
take the id of the tr with id C.
Given that generate-id given a nodeset only considers the first node I
thought wayhay that will work but it didn't until I included a first node
predicate explicitly like so.
xsl:key match="stuff | morestuff" use="generate-id(ancestor::tr[predicate]
| ancestor::tr[not(predicate)]/preceding-sibling::tr[predicate][1])"/>
***
Should such be necessary?. Only tried it running version 1.0 on XSLTProc
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--