Subject: Re: [xsl] functions and XSLT From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx> Date: Tue, 13 Mar 2001 09:46:28 +0000 |
Hi Dave, As a first point - you should be looking at http://www.jenitennison.com/xslt/exslt/common rather than the old URL that you give for EXSLT. Sorry - I should have put up some redirection. > I'm quite pleased to see work such as that found in appendix B of > http://www.jenitennison.com/xslt/exsl.html. Common libraries created > by the user community will no doubt be of much use in the future. > The appropriate level of formality / informality that should be > involved is an issue that I feel has been neglected, though. The > intent seems to be more than to simply provide a web repository of > contributed code, but how much more is entirely unclear to me. The > C++ library group Boost.org (http://www.boost.org) has a formal > submission process, including peer code-review. Perhaps that's too > rigid? I don't have a good feel for what others are expecting. For > myself, I can say that if I'm going to use exsl library code, I'll > be examining it myself thoroughly unless I can be confident that a > couple of people other than the code's author already have. (Not > that this would be a bad thing to do in any case!) David C., Uche and I have been discussing this over the last week. David C.'s position is that anyone should be allowed to add a function to the repository, provided it comes with documentation and an implementation and that the name has not already been taken. This means that the repository can grow rapidly and with minimal red tape. However, it means that any particular module (i.e. namespace) might not be wholly implemented within a particular processor or by a particular third-party implementation. Uche's position is that the modules should be well-defined with implementers told to implement everything in a module or nothing at all. This means that authors can guarantee that certain functions will be available within a particular implementation. The implication of this is that the submission and discussion process has to be more formal, with functions only accepted with version changes to EXSLT. Yesterday, I suggested a complicated third way that would involve having a core of peer-reviewed, tried and tested functions within each module. Other functions could be added as per David's suggestion, so that they're available quickly, but these would only be moved into the core following review (on version changes). I think that we don't want to make it too complicated - the point about EXSLT is that it's *extensions* and it would be rather depressing if XPath 2.0 incorporated all the extension functions we've been talking about before we could standardise and implement them :) > The concept of subroutine is expressed in XSLT by the template. > Templates take parameters; templates define scope; templates > encapsulate algorithms; templates compute returned results. So why > is it that proposals to extend XSLT to allow the creation of > functions written in XSLT go to the trouble of inventing a new > syntax to define them? The reasoning is that templates cannot return node set values that have not been freshly generated. It is not possible to author set:intersection() [1] using a template. All you can get back otherwise is a *copy* of the nodes in the intersection or a new node set consisting of nodes that reference the nodes in the node set. It is also not possible to author functions that return boolean values (e.g. set:has-same-node() [2]) using a template as templates return result tree fragments, which are always boolean true. Since functions that return boolean values or node sets containing existing nodes are fairly useful, there's not a lot of point in having constructs for user-defined functions that don't allow you to do so. EXSLT uses exsl:result. Alexey's lambda expressions use 'xsl:return'. David Rosenborg's FXPath [3] has functions containing a string that is interpreted as (extended) XPath and evaluated. The reason that xsl:template is not used for any of these is because the functionality and content of a function-defining element then becomes very different from xsl:template. I think that we all feel that we shouldn't change the semantics or syntax of XSLT elements. Cheers, Jeni [1] http://www.jenitennison.com/xslt/exslt/sets/#function-set:intersection [2] http://www.jenitennison.com/xslt/exslt/sets/#function-set:has-same-node [3] http://www.pantor.com/fxpath --- 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] functions and XSLT, David Rosenborg | Thread | Re: [xsl] functions and XSLT, Colin Muller |
Re: [xsl] functions and XSLT, David Rosenborg | Date | RE: [xsl] Copy namespace definition, Michael Kay |
Month |