[xsl] Re: FXPath - A comment on EXSL

Subject: [xsl] Re: FXPath - A comment on EXSL
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Wed, 28 Feb 2001 19:03:17 +0000
Hi David,

> Fortunatly, not everything in life is XML :-)

Wow, we really are on different planets ;)

> Yes, and I think user defined extension functions sits almost right
> in the middle of the two. I think that's why we can find sensible
> arguments for choosing either syntax for this purpose. However, as
> you know, I think most of the extension functions will deal with
> XPath types and should therefore be implemented in an XPath fashion.

I think that this means that you anticipate that most functions won't
produce RTFs/generate new nodes (something that I'm inclined to agree
with, although interestingly two of the use cases [gen:range and
gen:tokens] do).

> Now, about variables: I don't think it's too awkward for a language
> that have the notion of variables to also have a way of defining
> them.

It depends how you view XPath. I think I really see XPath as an
expression language for use *within* another language (i.e. XSLT). To
me, variable values are part of the XPath context, along with a
function library, the context node and so on.  They're things that are
set at the next level up in the application and 'passed in' to the
expression.  A bit like stylesheet parameters, if you like.

But I guess this might be something that applies to XPath but doesn't
apply to the superset that is FXPath.

> The result of instantiating a set of XSLT instructions is a result
> tree fragment. As I see it, you change that definition in EXSL by
> allowing arbitrary XPath types to be the result of such an
> instantiation.

That's a fair point, but what we're doing with
exsl:function/fx:function is a bit weird anyway. I think that we're
both doing basically the same thing: the result of instantiating
fx:function should be a result tree fragment, but you're returning
something else from it. If you placed your FXPath in an attribute
value (where it belongs! ;) then your fx:return would be 'breaking the
same rules' as exsl:return. Without fx:return, then by rights
fx:function should just be producing a text node!

I don't really see the distinction between the two approaches on this
front, but perhaps it's because I read the above before I read:

> You could argue that EXSL does not change the behaviour of XSLT
> instructions, but then the exsl:return must act as an escape
> function.

Ah, here you're talking about using exsl:return within xsl:when,
xsl:otherwise and xsl:for-each, with the 'return' returning (escaping)
from the function.

I agree that the processing model of XSLT doesn't include this kind of
functionality (and probably shouldn't). The way I view it is that the
instantiation of the content of exsl:function generates an RTF
consisting of one (or more) exsl:return elements. The first of the
exsl:return elements is taken, and its select attribute is evaluated
to give the result of the function.

Perhaps that's still not acceptable.

> Yes, my spec is still underspecified, its a version 0.1 ...

Oh, so's "mine" :) These aren't criticisms, they're just comments on
where I think you could improve it.  I'm looking for the same kind of
comments on the EXSLT one.

> Yes, tokenisation should be mentioned. If I've not overlooked
> something, the FXPath grammar can be parsed with a single token
> lookahead. This is what's currently needed for XPath 1.0.

OK, great. So if you (or future XPath extenders) were to introduce new
keywords then it would just involve making sure that they don't
conflict with existing function names (and presumably operators).

>> Finally, I'm interested that you didn't go for some of the XPath
>> 2.0 possibilities, especially document(...)/key(...). Any
>> particular reason?
> One step at a time :-) The doc:key function looks messy both in
> FXPath and in EXSL.

I agree about doc:key. Part of the reason I included it as a use case
is that it would look so much nicer if xsl:for-each were allowed
within exsl:function.  I've just banged my head against getting nodes
from other documents using key() so many times that I really want to
see a better way of doing it as soon as possible.



Jeni Tennison

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

Current Thread