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: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Wed, 21 Feb 2001 09:47:01 +0000
Hi David,

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

Well OK, and I think that this is a good argument for not restricting
ourselves to only variables in the body of exsl:function.

Personally, I think that any kind of extensions to XPath are beyond
what can be legally done to extend XSLT. I am not sure that (other)
implementers would respond positively to the idea of having a
different, XPath-like syntax within a particular attribute in an
extension function. I also think that it would be hard to explain to
newbies why this particular attribute uses a slightly different
syntax (or rather why they can't use (.. ? .. : ..) in the rest of
their code.

> 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 :-)

Oh, certainly too boring ;)

The main reason that I disagree with your proposal is that I am
*certain* that it *doesn't* cover all the possible cases. For example,
I cannot see a way to create the key function that I want to create
using your restricted syntax. Show me how to create a key function
with the arguments:

  my:key(string, object, node-set, node-set?)

where the first two arguments are the normal arguments to key() and
the second two are the normal arguments to document() (but with the
third always a node-set rather than having the possibility of being a
string).  It should return the nodes that result from using the key
with the document(s).

I know that this will be possible in XPath 2.0.  All things will be
possible in XPath 2.0 :)  (Including some kind of conditional
construct.)

> 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 :-)

As you imply, I think we'll probably have to agree to disagree on
this. Personally, I find messing around with extension elements more
acceptable than messing around with XPaths.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/



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


Current Thread