Re: keys and idrefs - XSLT2 request?

Hi Wendell,

> 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 agree. Speculating a bit - given all the talk of 'sequences' in the
XPath/XQuery documents, perhaps tokenising on whitespace will be
fairly automatic, especially if you have access to the DTD or XML
Schema and can work out that a particular value is a IDREFS, ENTITIES
or other 'list' type.

In other words, an XSLT 2.0 processor might look at the 'controls'
attribute, go "aha, an IDREFS attribute" and treat it as a sequence of
IDREF values. *If* that were the case, then:

<xsl:key name="control" match="process" use="@controls" />

would automatically work in the same way as when using tokenize (with
only one argument). However, of course this would be highly
backwards-incompatible, so perhaps we'll see something like:

<xsl:key name="control" match="process"
         use="cast as IDREFS(@controls)" />

or:

<xsl:key name="control" match="process"
         use="xf:IDREFS(@controls)" />

Which is all to say that I don't think we'll have to worry about
tokenising on whitespace in XPath 2.0. *But* we might want to ask for
tokenisation on other characters (e.g. commas) - I can't see a
xf:tokenize() function to create sequences in the F&O document...
         
Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


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