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

[David.Rosenborg@xxxxxxxxxx]

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