[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: FXPath v0.3 + SAXON Implementation

Subject: Re: FXPath v0.3 + SAXON Implementation
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Wed, 7 Mar 2001 14:34:33 +0000
fx templates
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'
          and
          set:for-all ($node-set [position () != 1], $expr)))
  </xsl:script>

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

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.