Cart
[Home] [By Thread] [By Date] [Recent Entries]
At 08:05 AM 10/9/01, DaveP wrote:
Which as you point out, indicates that XSLT has no means of using keys (simply) on idrefs, to find 'reverse' links. Yes, it's rather ungainly ain't it? Either to extend the key function in some way to handle idrefs, or to permit a key definition to take in all attributes of type idrefs? (I could see the problem where I have a CDATA attribute with spaces, but surely idrefs are a bit special?) I think it'd be a tall order to get much consensus on IDREFS being so special that the definition of key() should be stretched that far (even broken, since it makes its functionality very different depending on a DTD's being parsed). This would be a source of much confusion, I imagine, and also complaints since many users simply wouldn't understand or accept the rationale for the design. Rather, if the saxon:tokenize approach works, why not do it that way? The introduction of a node-set() function makes it much more conceivable in XSLT 2.0 to introduce arbitrary node sets on demand. So XSLT 2.0 needs an equivalent to saxon:tokenize. I guess I'd better test this approach to see if it works.... Cheers, Wendell
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
