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

[David dot Rosenborg at pantor dot com]

Hi Jeni,

> So it would be plausible for us to specify an exsl:if() function that
> we want them implementers to implement and to write into that
> specification that the second argument must only be evaluated if the
> first argument is true, and the third argument must only be evaluated
> if the first argument is false.
> 
> I like this a lot more than introducing syntax (even in an extension
> element's attribute) that isn't valid XPath 1.0 syntax.

It would by syntactically XPath 1.0 but not semantically, so you can
still not call it XPath 1.0. And if you are considering leaving
the pure XPath 1.0 track it would be a small step implementationwise
to have another syntax, though the particular syntax isn't that
important here I think. One thing to consider though: if it
by definition doesn't behave like an extension function, it probably
shouldn't look like one.

I think the important thing is that you have dedicated numerous of
postings to try figuring out what should be allowed and not
in the body of an exsl:function and in my opinion you haven't got
close to the end. I'd say it isn't trivial to know that we've
covered all the possible cases. Whereas with my proposal,
the definition is straightforward and the implementation is
straightforward. But maybe that's too boring :-)
I don't see how messing around with XSLT instruction semantics
can be any more fruitful than a couple of simple add-ons to XPath
in a well defined place: exsl:result/@select. But then, the beauty is
in the eye of the beholder :-)

Cheers,

</David>

David Rosenborg
Pantor Engineering AB



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list