Subject: Re: [xsl] [exsl] Draft 0.1 - call for comments From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx> Date: Mon, 26 Feb 2001 09:44:29 +0000 |
Hi Francis, Thanks for your comments. Just to address those that I disagree with... :) > [Issue: exsl:reference-of] damn - I didn't follow this one either - > is it not also possible to create node-sets? > > [Issue: Multiple exsl:return error] Why can't the values of multiple > exsl:return elements simply be unioned together as a node set? These are fairly similar, but not quite the same. The first allows you to gradually build up node sets within a variable value. For example: <xsl:variable name="first-five-alphabetical"> <xsl:for-each select="$nodes"> <xsl:sort /> <xsl:if test="position() >= 1 and position() <= 5"> <exsl:reference-of select="." /> </xsl:if> </xsl:for-each> </xsl:variable> That you could then return with: <exsl:return select="$first-five-alphabetical" /> The question David C. raised with regard to this is "if we need it here, why haven't we needed it before?" There are more declarative ways of doing the above, including: <exsl:return select="$nodes[sort:position($nodes) >= 1 and sort:position($nodes) <= 5]" /> Having multiple exsl:return values being unioned together is roughly similar except that you don't have the intermediate variable: <xsl:for-each select="$nodes"> <xsl:sort /> <xsl:if test="position() >= 1 and position() <= 5"> <exsl:return select="." /> </xsl:if> </xsl:for-each> One problem with this is that it may be confusing for people who are used to 'return' actually returning from a function (perhaps a reason for calling it exsl:result rather than exsl:return if this functionality is permitted). As before, there are other ways of doing the above, including recursive ones, so it is not absolutely required. > [Issue: exsl:node-set name] um, what's wrong with node-set()? > Compatible with existing implementation - or so compatible it might > be confusing? Nothing's wrong with exsl:node-set(). Some implementations use nodeset() or NodeSet() or various other things instead, that's all. > [Issue: Type tests] well, if we're going to add any type > functionality, having it in this read-only area,for XPath 1.0 data > types only, would cause the least baggage. Is the string / node-set > decidability problem sufficiently hard to work round to justify > this? I was thinking about things like the 'other document' functions at the end of Appendix B. The document() function's first argument can be a string or a node set, but with the 'other document' functions it has to be a node set to get the desired behaviour, and there's no way to test whether the right type of argument has been passed or not, nor to fail with a nice error message if it isn't. So the work around is to restrict the types that are acceptable to the function, which is fair enough, just might be a little confusing in these kinds of functions. 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] [exsl] Draft 0.1 - call f, Francis Norton | Thread | Re: [xsl] [exsl] Draft 0.1 - call f, Francis Norton |
Re: [xsl] using parameters in filte, David Carlisle | Date | Re: [xsl] Concat ( Again ), Samuzeau Pascal |
Month |