Subject: Re: [xsl] [exsl] Draft 0.1 - call for comments From: "Dave Hartnoll" <themainman@xxxxxxx> Date: Mon, 26 Feb 2001 13:54:39 -0000 |
> I've put together a draft document that summarises our recent > discussions on user-defined extension functions written in XSLT at: > > http://www.jenitennison.com/xslt/exsl.html > > Comments on it should be sent here, to XSL-List with [exsl] at the > start of the subject line. > > The main part of the document specifies the extension elements and > functions (viz exsl:function, exsl:return and exsl:node-set()) that > we've been talking about. Several outstanding issues are highlighted, > but comments on other areas are welcome. It would be particularly > helpful to hear from implementers. I like this very much. As a further extension to exsl:function, I think it would be useful to be able to specify that the XSLT function should only be used if an appropriate built-in function is not available. In some cases, you might want to do the reverse, and override a built-in extension function. e.g. <exsl:function name="set:intersection" prefer="saxon:intersection"> <exsl:function name="set:intersection" prefer="saxon:intersection xt:intersection my-processor:intersection"> <exsl:function name="set:intersection" override="saxon:intersection"> In the first example, any calls to set:intersection would call the built-in saxon:intersection. In the last example, calls to saxon:intersection would call the XSLT function instead. The real benefit would be that the namespace prefix could be omitted from the prefer or override attribute values to affect any extension function of that name on a particular implementation. <exsl:function name="set:intersection" prefer="intersection"> <exsl:function name="set:intersection" override="intersection"> or, perhaps: <exsl:function name="set:intersection" prefer="*:intersection"> <exsl:function name="set:intersection" override="*:intersection"> or, even better? <exsl:function name="set:intersection" prefer-builtin="true()"> <exsl:function name="set:intersection" override-builtin="true()"> In this way, implementors could supply *some* extension functions and users could get the benefit of increased speed wherever it's available without being concerned about which extensions are implemented in the current version of the software. For larger projects, a single xsl:include could add exsl:functions for all currently defined extensions with a prefer-builtin on each of them to improve performance. Obviously, it would be up to the implementor to know that built-in functions match the semantics of those published for any given exsl namespace. > Appendix B gives loads of use cases of functions that could be > implemented under this scheme, many of them borrowed from Saxon, which > demonstrate the strengths (and weaknesses) of the scheme described in > the document. If you have more use cases, then please let us know > about them and, preferably, their solution. I suggest that the set:leading/set:following function pair be renamed set:preceding/set:following to more closely follow the XPath preceding/following axis pair. Dave Hartnoll. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] [exsl] Draft 0.1 - call f, Jeni Tennison | Thread | Re: [xsl] [exsl] Draft 0.1 - call f, Jeni Tennison |
Re: [xsl] Re: [exsl] Re: Draft 0.1 , cutlass | Date | Re: [xsl] [exsl] Draft 0.1 - call f, Jeni Tennison |
Month |