This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Re: FXPath - A comment on EXSL
- To: <xsl-list at lists dot mulberrytech dot com>
- Subject: Re: [xsl] Re: FXPath - A comment on EXSL
- From: "David Rosenborg" <david dot rosenborg at pantor dot com>
- Date: Thu, 1 Mar 2001 15:00:47 +0100
- Cc: "Jeni Tennison" <mail at jenitennison dot com>
- References: <002001c0a11a$77335b90$1cd796c1@TYPHOON> <23102790555.20010228121956@jenitennison.com> <001a01c0a195$087c5960$6500000a@KENNY> <150126991273.20010228190317@jenitennison.com> <002301c0a24a$7172c340$6500000a@KENNY> <11192631890.20010301131718@jenitennison.com>
- Reply-To: xsl-list at lists dot mulberrytech dot com
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