Subject: Re: [xsl] Re: FXPath - A comment on EXSL From: "David Rosenborg" <david.rosenborg@xxxxxxxxxx> Date: Thu, 1 Mar 2001 15:00:47 +0100 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Re: FXPath - A comment on, Jeni Tennison | Thread | Re: [xsl] Re: FXPath - A comment on, Jeni Tennison |
Re: [xsl] Re: FXPath - A comment on, Jeni Tennison | Date | [xsl] A theoretical question, mcarrasc mcarrasc |
Month |