This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [exsl] Draft 0.1 - call for comments


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]