Re: [xsl] Re: FXPath - A comment on EXSL

Subject: Re: [xsl] Re: FXPath - A comment on EXSL
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Thu, 1 Mar 2001 13:17:18 +0000
Hi David,

>> 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.
>
> I agree fully with this, and I didn't mean to say that variable
> binding primitives were missing from XPath. I just ment that if they
> had been there it wouldn't have been a strange thing. And
> introducing them in FXPath is equally natural.

IMO, introducing variable binding in FXPath places it on another plane
from XPath. A single FXPath is an order of magnitude more powerful and
efficient than a single XPath can ever be. Personally, I don't want to
have XPath be that powerful - I'd rather keep it light. But that's not
an objection to FXPath because, as you've said, FXPath is an
XPath-based language for defining extension functions, not a proposed
replacement for XPath.

>> 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!
>
> Hm, in FXPath the result is not necessarily an RTF, in fact that's
> the whole point of it. And I don't see how placing the FXPath insde
> an attribute changes anything. Maybe I should clarify that the body
> of an fx:function is not an XSLT template.

Maybe.  The stuff I wrote above was in response to you saying that:

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

I thought that when you wrote this you were objecting to the fact that
exsl:function instantiated a set of XSLT instructions and didn't
necessarily produce a result tree fragment.  The point I was making
was that fx:function also instantiates a set of XSLT instructions and
therefore by rights should produce a result tree fragment (from your
argument).

The fact is that to define useful extension functions in anything
resembling XSLT you really have to be able to return something other
than a result tree fragment. Since returning anything other than a
result tree fragment from the instantiation of a set of XSLT
instructions breaks the rules, you have to change the rules if you
want this functionality.

You can change the rules to say that the result is the evaluation of
the text that's instantiated (as you do) or the evaluation of an
attribute on an element that's instantiated (as I do), but it doesn't
really matter - you're still changing the rules.

>> 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.
>
> Acceptable for you maybe as a conceptual outline, but from an
> implementors point of view this sound like some sort of
> transformation on the syntactic level ,a.k.a. macros, taking place
> at runtime. It leads my thoughts to self modifying code, which can
> be pretty hairy.

I've probably not thought it through in the way that an implementer
would, but I don't really grasp your argument here.  In FXPath, you
instantiate some text, and then say that this text is evaluated to
give the result of the function.

With exsl:function/exsl:return I say that I instantiate some
attributes, get you to pick the first of these attributes, and then
say that the value of this attribute is evaluated to give the result
of the function.

The only substantial difference as far as I can see is the 'picking
the first of the attributes', which implies that the XSLT
implementation must be able to filter a result tree fragment and
discard things that aren't allowed within it. I think that XSLT
implementations currently do this, for example by discarding element
nodes instantiated within attribute content or attribute nodes
instantiated after element content.

So I don't understand where the transformation on the syntactic level
is taking place at run time?

Cheers,

Jeni

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



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


Current Thread