Re: using xsl:key to generate list of back references
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format