Re: Re: FXPath - A comment on EXSL
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format