Re: [exsl] Draft 0.1 - call for comments

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