Subject: Re: [xsl] [exsl] Draft 0.1 - call for comments From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx> Date: Mon, 26 Feb 2001 15:41:09 +0000 |
Hi Dave, > 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. What an interesting idea! I was imagining that common extension functions like set:intersection would become part of a community standard, and that when they were then processors that supported them natively could recognise the expanded name of the function and use whichever implementation they had for it. But of course that picture only works if the relevant function is part of some community standard in the first place. There will probably always be functions that are specific to a particular processor and you're right that it would be very nice to take advantage of those built-in extension functions. Just to indicate the other alternative - you could have a function that tested whether a particular function was available and then choose the relevant implementation, e.g.: <exsl:function name="my:intersection"> <xsl:param name="node-set1" select="/.." /> <xsl:param name="node-set2" select="/.." /> <xsl:choose> <xsl:when test="function-available('exsl:intersection')"> <exsl:return select="exsl:intersection($node-set1, $node-set2)" /> </xsl:when> <xsl:when test="function-available('saxon:intersection')"> <exsl:return select="saxon:intersection($node-set1, $node-set2)" /> </xsl:when> <xsl:otherwise> <exsl:return select="set:intersection($node-set1, $node-set2)" /> </xsl:otherwise> </xsl:choose> </exsl:function> > 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. I worried that might get a little dangerous - who's to say that saxon:intersection doesn't produce an RTF with information about crossroads, for example ;) I think it's far safer to indicate the mappings on a name-by-name basis. > 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. Yeah - I borrowed set:leading() from Saxon and then couldn't think of another word for 'following' :) Actually, if they were renamed set:preceding/set:following then I should probably change the semantics of set:following so that it didn't include the first relevant node, only the nodes after it... Cheers, Jeni --- 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] [exsl] Draft 0.1 - call f, Dave Hartnoll | Thread | Re: [xsl] [exsl] Draft 0.1 - call f, David Carlisle |
[xsl] Path for a DTD : proposition, Paul Terray | Date | RE: [xsl] Path for a DTD : proposit, DPawson |
Month |