Re: Designs for XSLT functions (Was: Re: RE: syntax su
Hi Jeni, > So you would advocate having the development of exsl:function include > adding exsl:if()? Yes, but the conditional construct cannot be an extension function since a function call in XPath evaluates all its parameter *before* entering the function. In an if-statement it is crucial that only the predicate and one and only one of the clauses get evaluated. This means that the conditional construct must be introduced as a new special form in the core XPath language. It could be syntactically like a function as you suggest e.g. "if ($pred, $true, $false)". However you could possibly (and preferably I think) use a ternary operator like "$pred ? $true : $false" or even better "if $pred then $true else $false" Now, this isn't really the issue here, I'm just saying that the conditional construct can take one of many forms. > 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: Well, I think your example doesn't fall far from what's my experience of the 80/20 rule here. Of course most functions would be more complicated than returning simple numbers but the majority (80% to be precise :-) wouldn't be that more complicated. Most of the situations where I've felt a need for an xsl:function construct can be related to recursive string transformations. In fact, to cope with these situations, I'd be satisfied if I could call a named template in XPath. So what I'm saying is that most of the cases would be satisfied by this pattern (returning an RTF): <xsl:function name="my:func"> <xsl:param name="a"/> ... <xsl:result> <!-- Do stuff --> </xsl:result> </xsl:function> Of course in this pattern you would have full access to xsl:choose and alike. This works fine for strings and RTFs, however, xsl:function would open a whole new world of other possibilities like recursively building up node sets using '|' as the connecting operator. And in those situations I would be happy with a simple XPath conditional primitive. In fact, as I've implied, I think most of those cases would come out more terse and readable than using xsl:chooe etc. > [Aside: Of course as soon as we have exsl:function we can do: > > <exsl:function name="my:if"> [ snip ] > </exsl:function> > > How great is that going to be!] Sorry, this won't work, see my first paragraph. > "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." Taking on the hat as an implementor (and user too for that matter) I'd prefer static constraints rather than runtime constraints. > 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: [ snip ] This is addressed in XPath 2.0 Req: 2.1 > 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: [ snip ] Yes, that would be nice, and in my proposal you would have to rely on RTF to node set conversion to solve this, which could be costly in some cases. However, as an implementor I'd prefer some declarative solution to this rather than allowing preemptive returns from a for-each loop. Cheers, </David> David Rosenborg Pantor Engineering AB 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