Re: [xsl] FXPath v0.3 + SAXON Implementation

Subject: Re: [xsl] FXPath v0.3 + SAXON Implementation
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Wed, 7 Mar 2001 14:34:33 +0000
Hi David,

> The major change to the FXPath document is that the fx:function
> element has been split in two: fx:define and fx:template-function.
> The reason for the split is to make a clearer distinction between
> functions implemented with FXPath and functions implemented with
> XSLT instructions. The fx:define element uses FXPath syntax only,
> where as the fx:template-function has the same content and
> processing model as a named xsl:template with a few exceptions.

Ooh, very interesting. I do think the split makes it a lot cleaner, in
particular because it shows really marks out FXPath is a neat new
language that's particularly good at dealing with node set
manipulation and so on.

It seems to me that the natural progression, if XSLT 1.1 does
eventually include xsl:script, is to have FXPath as one of the
possible languages.  This would involve adding a bit more syntax to
the FunctionDefinition expression, to enable it to give the name of
the function without a surrounding fx:define and perhaps to isolate
particular functions to make it easier to parse a load of these
functions in a single element.

  <xsl:script implements-prefix="set" language="fx:fxpath">
     function for-all ($node-set := /.., $expr := '.') ->
       (not ($node-set) or
         ($value := string (com:eval ($node-set [1], $expr));
          $value and $value != 'false'
          set:for-all ($node-set [position () != 1], $expr)))

I'm a lot happier with the if and reduce statements now that the
brackets are required around the expressions they use :)
I really like the idea of using an attribute on fx:template-function
to indicate the type of value that the contained RTF should be coerced
to. I hope you won't mind if I add that possibility to the set of
options for exsl:function?

I think it would be very useful, though, if you *could* coerce to a
boolean value by converting the result tree fragment to a string and
then to a boolean.  So if any text was generated within the template
function, it would result in true(); if no text were generated, it
would result in false().

Actually, the structure of fx:template-function is pretty much the
same as a named template - the semantics of the parameters are
different, but otherwise it's the same. Perhaps, rather than
introducing a new element, it would be simpler to add an extension
attribute, fx:result-type, to xsl:template to allow it to be called as
a function (provided it has a name, of course). I like that option
because it makes it a easier to make utility function/templates
available without repeating lots of code.
As far as I can tell, the only gap in functionality would be if you
needed a function that returns existing nodes *and* require the
functionality of programming statements that aren't supported by
FXPath. Now that you have function call steps, I can't think of any
use cases that couldn't be achieved, though some of them might be only
achievable fairly inefficiently (I'm thinking in particular of
functions involving returning node subsets based on sorted position,
which exsl:function as it currently stands also has problems with).



Jeni Tennison

 XSL-List info and archive:

Current Thread