Re: FXPath - A comment on EXSL

Hi Jeni,

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

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.

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

Cheers,

</David>

David Rosenborg
Pantor Engineering AB



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