Subject: Re: [xsl] keys and idrefs - XSLT2 request? From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx> Date: Tue, 9 Oct 2001 17:57:30 +0100 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] keys and idrefs - XSLT2 r, Wendell Piez | Thread | RE: [xsl] keys and idrefs - XSLT2 r, Michael Kay |
Re: [xsl] keys and idrefs - XSLT2 r, Wendell Piez | Date | RE: [xsl] Basic: Diferrence between, Chris Bayes |
Month |