Re: using xsl:key to generate list of back references

["Sebastian Rahtz" <sebastian.rahtz@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

David Marston/CAM/Lotus writes:
 >  <xsl:for-each select="key('targets','')">
 > 
 > >and somehow access the indices of the key structure. Is this
 > >unreasonable of me? The processor has all the information I want,
 > >right to hand, but it forces me to send it off on a wild goose chase...
 > 
 > You need to be able to force the gathering of all the @target nodes
 > that will populate your "targets" keyspace, but the processor may be
 > implemented with lazy capture or evaluation of the nodes.

Good point. I agree, it scuppers me

 Also, how do
 > you want to deal with the provision (in Section 12.2):
 > 
 > "There can be multiple keys in a document with the same node, same
 > key name, but different key values." In other words, more than one
 > value can be looked up in the keyspace to return the same node.

not sure why this bothers me? if I get duplicate nodes, so be it. but
anyway, your earlier point makes me realize i was not thinking it through.

 > Overall, there's no doubt about the strength of the demand for a
 > grouping capability keyed to uniqueness within some set of values.

I think the Muenchism strand demonstrates that the
`index'-based approach has virtues over and above the simpler Saxon
"group" approach, because the same index can be re-used. Whether this
means the XSLT group should look at keys some more, as opposed to
"group", I do not know. 

Am I the only person who wishes that someone from the W3C or XSL group 
would ever raise their head over parapet and say what the timescale
for an XSL revision might be? Yes, I know XSLT 1.0 is only 6 months
old, but an XSLT 1.1 at end of 2000 would be a nice thought.

Sebastian


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