This is the mail archive of the mailing list .

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

RE: RDDL as a delivery vehicle for XSLT extensions?

I present an alteranative to xsl:script at the bottom that 
satisfies your reason and also is more portable.

> The primary reason is to allow users to write extension functions 
> that are portable between one XSLT processor and another, as opposed 
> to the current situation where extensions written for Saxon don't 
> work with Xalan. I still find it hard to understand why this should 
> be thought such an undesirable objective.

This is a worthy goal.  However, xsl:script does not allow a Java
extension written for Saxon to work with Uche's or Alexey's processors
since they are not Java based.  I think the scope of the requirement
should be either broadened to take into account non-java XSLT processors 
and perhaps other W3C technologies or dropped.  

How to broaden?  Let's start with the example in the current WD.

  xmlns:xsl="" version="1.0"
  <xsl:script implements-prefix="date" language="java"
  <xsl:template match="/">
      <xsl:value-of select="date:format(/order/date,'MM/DD/YY')"/>

Assume that "com.example.datestuff.DateRoutines" becomes very
popular indeed, copied everwhere in all of your stylesheets.
It would now be near impossible for your stylesheets to be moved 
over to a XSLT processor which did not support java xsl:script.
Certainly you could go through each of them and add the 
requisite Python or VB code...  but you _must_ admit.  There
is significant "lock-in" here.  Your stylesheets are _not_ 


Now, consider the following.

  <xbind:function name="format">
    <xbind:param  name="date"   type="string" />
    <xbind:param  name="format" type="string" />
    <xbind:return type="string" />
       This function formats a date in ISO 8601 
       according to the format string.
    <xbind:implementation language="javascript">

<exsl:script implements-prefix="date"
  xbind="a-language-independent-uri-that-refers-to-functionality" />

How is this different?

  1.  This language uses an opaque identifer that is
      language independent.  This identifier can be 
      associated in a python based XSLT processor,
      for example, to find the required functionality
      even if such functionality is not included as 
      code within the xbind document... 

  2.  This binding syntax tells the W3C processor exactly
      what to expect from the imported function.  Much like
      a Visual Basic "Declare" style to import C functions
      from a DLL into the visual basic function space.

  3.  This clear description (Call it XMLIDL?) can be used
      by others to at least try and produce an implementation
      in another language...

  4.  This is a seperate W3C specification, and thus xbind
      can be used by DOM, XQUERY, or any other language that
      needs to call-out to other programming languages.
  5.  The above xbind module could actually be stuffed away
      in RDDL or similar format so that the binding 
      information can be queried.  In fact the language
      independent URI could be a URL to fetch the xbind:module.

  6.  If the processor knows the xbind name, then the xbind
      module isn't even needed, as the functionality can
      be built-in.

In short, there are other options if portability of extension
fuunctions are the prime concern.   If simple importation of
Java constructs is the goal, then xsl:script as it stands
is perfect.

Kind Regards,


 XSL-List info and archive:

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