Subject: Re: [xsl] Re: FXPath - A comment on EXSL From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx> Date: Thu, 1 Mar 2001 15:56:16 +0000 |
Hi David, > 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. Then shouldn't you change xsl:param and xsl:variable to fx:param and fx:variable? Aren't those elements being instantiated to get the behaviour you want from them? I think I don't understand the technicalities of the term 'instantiation'. I thought it meant 'running' a particular construct to make it do the thing that it does. So you 'instantiate' an xsl:variable element to make it assign a value to a variable. > 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. Ah, gotcha. So there's a major problem to do with expanding references to local variables with that model; the expression within the exsl:return element's select attribute has to be evaluated in the context at which the exsl:return element is declared. Very good point. I think I'm going to change exsl:return to exsl:result for the next draft, as discussed with Uche, so what about this instead: When an extension function that is defined using EXSLT is called, the content of the exsl:function element is instantiated. It is an error for the instantiation of the content of the exsl:function element to result in the generation of result nodes if an exsl:result element is instantiated during the instantiation of the content of exsl:function. When an exsl:result element is instantiated, the expression contained in its select attribute is evaluated and this becomes the result of the function. It is an error if the instantiation of the rest of the exsl:function involves the instantiation of another exsl:result element (or the generation of any result nodes, as above). The XSLT processor may signal this error; if it does not signal the error, then it may recover by ignoring later exsl:result elements. The instantiation of an exsl:result element does not halt the execution of the function. For example, it is possible to generate messages following the instantiation of the exsl:result element: <exsl:function name="my:func"> <exsl:result select="'foo'"> <xsl:message>my:func called with result 'foo'</xsl:message> </exsl:function> > 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. Complexity's in the eye of the beholder ;) Coming from an authoring/tutoring background, I see having to learn more programming constructs as unnecessarily complex whereas exsl:result giving the result of the function from wherever it is seems intuitive (though not particularly declarative, which is why I've been trying to come up with a more declarative model for it). Thanks, Jeni --- Jeni Tennison http://www.jenitennison.com/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Re: FXPath - A comment on, David Rosenborg | Thread | Re: [xsl] Re: FXPath - A comment on, David Rosenborg |
RE: [xsl] A theoretical question, Ray Lukas | Date | [xsl] divide info in several output, Aniceto López |
Month |