Re: Designs for XSLT functions (Was: Re: RE: syntax su
Hi David, > Even though I think I have a slightly different focus, there is > nothing that prevent us from introducing a conditional construct in > the @select of a xsl:result element. It's just a matter of > specification: we cannot call it XPath 1.0. There is no restricion > on what you can do in an extension or top level element. True enough. >> Oh, well I'm excited by it anyway. I *think* that because we're >> dealing with a side-effect-free language it shouldn't matter that >> both the true and false results are evaluated, aside from in terms >> of speed. And mainly I'm just thinking of things like: >> >> my:if(@foo = 'yes', 'true', 'false') >> >> where that doesn't matter much. > > I does matter when you are writing recursive functions. If the > if-statement represent the stop condition in a recursion, it is > crucial that the recursive call is only evaluated if the stop > condition isn't satisfied. Otherwise the recursion could go on for > ever. Very good point. Thank you. I think the upshot of this is that unless we introduce a proper construct like (test ? true : false) that only evaluates the relevant expression, we *have* to enable xsl:if/xsl:choose to be specified within function declarations. An exsl:if() function will not be sufficient. > I was thinking about a declarateive XPath construct to acheive this. > In fact this touches the essence of my proposal: XPath expressions > and template instructions are totaly different beeings. They are > pretty ortogonal and I don't see wy we shouldn't keep it that way. Mainly because there are some things that you can't do in XPaths that you can do with XSLT instructions, like conditional statements :) > In my opinion, trying to mix them may lead to confusion and is > harder to implement. If XPath is too limited to write node set > functions I'd rather see extensions to XPath than trying to solve > the problem by mixing it with XSLT instructions. So would I. In the long long long term, there shouldn't be any extension functions because everything that's usefully done within an XPath should be in the XPath core. However, excepting the ability to write whatever we like in extension element attributes, we are currently only able to introduce extension functions. Of course, working on creating common extension functions that do all the node set manipulation we need to do is a very worthwhile aim. In fact if you have the energy and feel strongly enough then I urge you to lead the process of doing so. IMO the process of creating common extension functions will become easier when we have a means of defining extension functions in XSLT (and [sorry Uche] in other languages). Implementers that have the time to build in support for these common extensions will be able to do so. We will be able to use our own definitions for those that don't. > To strecht the XPath extensions even further and simplify > pure XPath functions we could introduce a variable binding primitive: > An XPath expression could be prepended by a series of variable binding > clauses e.g: > > Expr := VarBinding* OrExpr > VarBinding := QName ':=' Expr ';' > > Then you could write a max function as (assuming the if-then-else syntax): > > <xsl:function name="my:max"> > <xsl:param name="nl"/> > <xsl:result select=" > first := nl ; > if nl  then > max-of-rest := my:max (nl [position () > 1]); > if $first > $max-of-rest then $first else $max-of-rest > else > $first "/>> > </xsl:function> > > Now, this is maybe sliding off topic, Sorry :-) :) You might be interested at looking at the syntax used in XQuery. 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