Re: Designs for XSLT functions (Was: Re: RE: syntax su
Hi David, > Yes, my proposal relies on a conditional construct in XPath. I think > it's more worthwile to try and get such a thing in as early as > possible than to try and figure out a intuitive and concise > definition of how the mix of XPath and arbitrary template > instructions should behave. So you would advocate having the development of exsl:function include adding exsl:if()? I think that the only real objection I would have to this is that conditional constructs in XPath can only go so far and get incredibly messy if they're more that a little complex. For example: <xsl:choose> <xsl:when test="foo"> <xsl:choose> <xsl:when test="bar"><xsl:return select="0" /></xsl:when> <xsl:otherwise><xsl:return select="1" /></xsl:otherwise> </xsl:choose> </xsl:when> <xsl:when test="baz"><xsl:return select="2" /></xsl:when> <xsl:otherwise><xsl:return select="3" /></xsl:otherwise> </xsl:choose> is: <xsl:return select="exsl:if(foo, exsl:if(bar, 0, 1), exsl:if(baz, 2, 3))" /> Admittedly it's not particularly pretty in XSLT, but if you replace numbers with complex string manipulation and add a few more xsl:whens in different places and so on then I think the XPath-only version becomes pretty unworkable. My personal opinion - I'm very willing to be shouted down. [Aside: Of course as soon as we have exsl:function we can do: <exsl:function name="my:if"> <xsl:param name="cond" /> <xsl:param name="true" /> <xsl:param name="false" /> <xsl:choose> <xsl:when test="$cond"><exsl:return select="$true" /></xsl:when> <xsl:otherwise><exsl:return select="$false" /></xsl:otherwise> </xsl:choose> </exsl:function> How great is that going to be!] > I think your example with xsl:for-each shows that this isn't > straight forward. You would have to recursively allow and dissalow > constructs for descendants of a xsl:function. That's true. It would be good to hear from implementers whether it's hard to implement a check of this kind of conditional content. On the other hand, we shouldn't be restricted to only allowing content models that are easy to represent in DTDs - half of XSLT would disappear if we were! :) A line that says: "It is an error if the result of instantiating the content of exsl:function involves the creation of any nodes. A processor may signal this error; if it does not signal the error, it must recover by ignoring the nodes." would, I think, cover the 'no result tree nodes' commandment. Oh, and I've thought of a couple of reasons to have xsl:for-each. Firstly, as we know, key() and id() are restricted to finding nodes in the current tree. If I want to use an extension function that retrieves keyed nodes in a particular document then I need to be able to do: <exsl:function name="my:key"> <xsl:param name="key-name" /> <xsl:param name="key-value" /> <xsl:param name="file-name" /> <xsl:param name="base-node" select="/" /> <xsl:for-each select="document($file-name, $base-node)"> <exsl:result select="key($key-name, $key-value)" /> </xsl:for-each> </exsl:function> Another example is if I want to use the built-in sort algorithms to find, for example, the first value alphabetically in a node set: <exsl:function name="my:first-alphabetical"> <xsl:param name="nodes" /> <xsl:for-each select="$nodes"> <xsl:sort /> <xsl:if test="position() = 1"> <exsl:result select="." /> </xsl:if> </xsl:for-each> </exsl:function> Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/ 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