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

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>

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



Jeni Tennison

 XSL-List info and archive:

Current Thread