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

Sebastian Rahtz writes:
>What bothers me is the (relative) inelegance of

<xsl:for-each
  select="//ptr[generate-id(.)=generate-id(key('targets',@target)[1])]">

[based on <xsl:key name="targets" match="ptr" use="@target"/>]
>when what I really want to say is something like

 <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. 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.

I could see a question about "ptr" nodes that don't have an @target.
If the proposed shortcut were implemented, some feature-creeper
would come along and request that there be an option to get one
extra slot for the unkeyed nodes.

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


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