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

[Steve Muench <Steve.Muench@oracle.com>]

| Ok.  However, the use-by-reference is still language specific
| which, IMHO, breaks portability.  From the appendix:
| 
|   <xsl:stylesheet  
|     xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"
|     xmlns:date="uri.any">
|     <xsl:script implements-prefix="date" language="java"
|       src="java:com.example.datestuff.DateRoutines"/>
|     <xsl:template match="/">
|       <OrderDate>
|         <xsl:value-of select="date:format(/order/date,'MM/DD/YY')"/>
|       </OrderDate>
|     </xsl:template>
|   </xsl:stylesheet>
| 
| It is very clear to me that the above stylesheet will work
| if and *only* if the the XSLT processor has built-in java
| capabilities.

Right. It's also very clear to a processor that doesn't
support extension functions in Java that it cannot support this.
Easy answer, therefore, to the function-available('date:CurrentDate').

|  So, although you may be right about not 
| "embedding Java", this is close enough to the same concern, 
| it is an "embedded Java package name".

| I'd like to see instead a module based extension facility
| that is not language dependent. 

I (personally, not speaking for the WG here) don't happen to
be a believer in some kind of look-it-up-and-magically-download-
the-right-(trusted?)-implementation-from-some-central-website-
for-the-language-my-processor-can-support-for-the-chip-architecture-
and-OS-that-I'm-currently-running-(while-I'm-using-this-on-a-plane)
scheme to download and run the "right" implementation of some function.

You either supply the implementation along with the
stylesheet (embedded or in external objects), or
the processor has it built in.

<xsl:script>'s whole purpose in life is binding
one or more specific implementations of extension 
functions to a namespace.

If you don't want to *bind* and implementation to
the namespace, then by your lack of doing this
you are depending on your processor's having this
function as a built-in extension. You just go ahead
and use the function-available('yourpref:yourfunction') and
use the yourpref:yourfunction() in expressions as
you do in XSLT 1.0 and *hope* that your processor
has a way to locate an implementation.

| > The contracts that the XSLT engine has with the extension
| > function implementation is completely the responsibility
| > of each language binding. The language bindings are
| > relegated to appendices.
| 
| Doesn't sound like this would encourage portability
| among processors written in different languages.

It enables and encourages XSLT implementors who care about
a particular language and who care about cross-processor
portability of user-written XSLT extension functions 
in that language to agree on all the language-binding
specific details amongst themselves. No more, no less.

The only requirements it places on their boundless
creativity is that they agree:

  -> On a QName to use to uniquely identify this 
     extension function language binding, and
  
  -> The language-specific details of implementing
     functions using that binding.

______________________________________________________________
Steve Muench, Lead XML Evangelist & Consulting Product Manager
BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG
Author "Building Oracle XML Applications", O'Reilly
http://www.oreilly.com/catalog/orxmlapp/