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

["David Rosenborg" <david.rosenborg@xxxxxxxxxx>]

Hi Jeni,

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

FXPath and fx:function doesn't change any rules, it has its own
set of rules, infact a superset of the rules that XPath has. And as I said,
the body of fx:function is not an XSLT template that gets instantiated,
no more than the value of a select attribute, which doesn't get
instantiated either.

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

The text is never instantiated, only evaluated (see above).

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

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

This is what I mean:
Maybe the word syntactic was a bit harsh, I think 'structural' is more
appropriate. I interpret your description as a multiple step process:

1. Instantiate the body of exsl:function to get an RTF with exsl:returns. Also
   you would need to either expand references to non-global variables visible at
   the point of eaxh exsl:return. Alternatively you can include the variable
   definitions in the RTF.

    This step is what I call a structural transformation which is normally associated with macros,
   only that macros are expanded statically.

2. Find the first exsl:return/@select in the RTF and parse its value into an XPath expression.
3. Evaluate the XPath expression to get the result value.

(2 and 3 could of course be done simultaneously depending on your implementation.)

I'm not saying you couldn't implement this model, I just mean that it is rather peculiar
and that it is unnecessary complex and more complicated than the FXPath approach.

Cheers,

</David>

David Rosenborg
Pantor Engineering AB



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