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 [1];
> if nl [2] 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