[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: FXPath v0.3 + SAXON Implementation
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
|
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
|