Re: Designs for XSLT functions (Was: Re: [xsl] RE: syntax sugar for call-template)

Subject: Re: Designs for XSLT functions (Was: Re: [xsl] RE: syntax sugar for call-template)
From: David.Rosenborg@xxxxxxxxxx
Date: Tue, 20 Feb 2001 12:40:33 +0100
Hi Jeni,

> I take your argument, and especially for a different syntax to a
> function based if(). I think it's likely that XPath 2.0 will support
> such things - it's on their list of requirements. However, I'd like to
> focus the discussion on things that we (the community) can achieve
> rather than things that only the WG can achieve.

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.

> I think I'd personally rather have a "simple things should be easy,
> hard things should be possible" rule than a 80/20 rule when designing
> this.

I thought that was what the 80/20 rule was about. In fact, nothing in my
proposal prevents you from doing the hard things (modulo preemtive returns
from for loops). The 80/20 statement was about syntax not functionality.

> > Sorry, this won't work, see my first paragraph.
> 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.

> Hmm... perhaps rather than imagining it as a preemptive return we can
> imagine it building up exsl:return elements within a result node set.
> So essentially the result of calling an exsl:function is a number of
> exsl:return instructions.  The first one of those is chosen and the
> select expression (or the content) is evaluated to give the value of
> the function.  Of course implementers would be free to optimise by
> stopping the function when the first exsl:return is generated.

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.
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.

* XSLT Instructions: Tree construction, template application
* XPath: Node selection, processing of primitive types.

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
Now, this is maybe sliding off topic, Sorry :-)



David Rosenborg
Pantor Engineering AB

 XSL-List info and archive:

Current Thread