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: Wed, 21 Feb 2001 13:02:01 +0100
Hi Jeni,

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

Sorry, you lost me there, how do you mean these things are related?

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

What do you mean by legal? My proposal is certainly legal XSLT 1.0.
In fact, if we loosen the concept of legality a bit I could argue that
changing the constraints on XSLT instuctions would be illegal
unless you put them in a new namespace. (Strictly speaking
they are legal since there are no constraints what so ever on the
contents of an extension or top level element). What I'm saying is that
if you changed your proposal to use exsl:choose, exsl:for-each etc
then this would be better since then you would be defining
a completly new languge to deal with node set (and other primitive
XPath types) functions. This instead of trying to retrofit XSLT
instructions into something they were not designed for.

> 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 admit this can lead to some confusion, though I think the confusion
would be an order of magnitude smaller than that caused by
retrofitted XSLT instructions.

> The main reason that I disagree with your proposal is that I am
> *certain* that it *doesn't* cover all the possible cases.

Since you, in my opinion, haven't got even halfway setting the semantics
of you proposal I think claims for full coverage are too early to make.
(well you didn't explicilty claim it, I just sensed an implicit comparison).
In fact, I don't see any proposal that could cover all possible cases.
(mostly because "all possible cases" is a bit underspecified :-)

I suggest that you start with a small, clean and well defined core.
Use it for a while. Discover what's missing. Design equally
clean and well defined improvements and add them to your language.
Going for the big bang directly can be devastating.

> For example, I cannot see a way to create the key function that I want to 
> using your restricted syntax. Show me how to create a key function
> with the arguments:
>   my:key(string, object, node-set, node-set?)

No, I cannot, though I would be glad to do a test implementation of the
document (...)/key (...) functionality found in XPath 2.0. (now, my 
is not in public domain so it wouldn't help you much, sorry :-)

I think this raises an important issue:

It has been said earlier on this thread that one purpose of this effort
is to explore new functionality that could possibly make its way to
new versions of XSLT and XPath. Maybe I'm blind, but
I just can't see the logic in evaluating new possible extensions to
XPath by trying to implement them with retrofitted XSLT instructions.
For the XSLT part it's OK, but for XPath it just doesn't make sense.

It seems like many of you think XPath is untouchable, holy ground,
whereas XSLT is not. I don't really see why you are making that
distinction. Albeit we would have to go over an extension
function call to test new XPath constructs from arbitary places
in our stylesheets, this doesn't justify not implementing XPath
extensions in XPath rather than in XSLT instructions.
(The function call is necessary since the experimental XPath may
only appear as a descendant to an extension or top level element)

> 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.
Well, sorry,  the mutal-disagreement-escape won't stop me from arguing :-)



David Rosenborg
Pantor Engineering AB

 XSL-List info and archive:

Current Thread