[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1

• From: "Clark C. Evans" <cce@c...>
• To: Robin Berjon <robin@k...>
• Date: Fri, 02 Mar 2001 00:10:47 -0500 (EST)

On Thu, 1 Mar 2001, Robin Berjon wrote:
> My quarrel with xsl:script is that it *immediately* ties an extension to an
> implementation language. This implies either that all implementations will
> have to support the same (set of) languages and thus resort to the usual
> LCD of programming languages (ecmascript) or that stylesheet authors will
> have to include xsl:scripts of equivalent functionality in several
> different languages with every stylesheet that they want to be portable.
> That's just insane.

Hmm.  What do you think of...

<xbind:module
  name="a-language-independent-uri-that-refers-to-functionality">
  <xbind:function name="format">
    <xbind:param  name="date"   type="string" />
    <xbind:param  name="format" type="string" />
    <xbind:return type="string" />
    <xbind:comment>
       This function formats a date in ISO 8601
       according to the format string.
    </xbind:comment>
    <xbind:implementation
       language="java"
       package="java:com.example.datestuff.DateRoutines#format"
    />
    <xbind:implementation language="javascript">
      ...
    </xbind>
  </xbind:function>
</xbind:module>

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

How is this different from xsl:script?

  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.

Clark

• Follow-Ups:
  • Re: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1
    • From: Robin Berjon <robin@k...>

• References:
  • Re: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1
    • From: Robin Berjon <robin@k...>

• Prev by Date: re: PSVI
• Next by Date: What Ordering Does XQuery Need? (was:Re: Why not reinvent the wheel?)
• Previous by thread: Re: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1
• Next by thread: Re: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1
• Index(es):
  • Date
  • Thread