Re: [xsl] XSLT 1.1 comments

["Steve Muench" <Steve.Muench@xxxxxxxxxx>]

| Uche Ogbuji wrote:
|
| "If an external object is passed to an extension function with an 
| expanded-name whose namespace URI is different from the namespace URI of the 
| expanded-name of the extension function that returned that external object, 
| the behavior is implementation-dependent."

All this means is that since:
  
  (*) XSLT 1.1 allows each extension function prefix
      to be implemented by one or more languages, and since

  (*) XSLT 1.1 allows a processor to freely pick from
      among multiple language implementations that might
      exist, which language it *chooses* (if any) to support,
      and since

  (*) XSLT 1.1 constrains the processor (once it's chosen
      which language implementation it prefers) to consistently
      pick the same language implementation for the same prefix
      for the duration of a single stylesheet "run"

that passing the return value of a function foo:function1()
into a function from a different namespace like bar:function2()
is implementation-defined because the chance exists that
namespace prefix "foo" is implemented in ECMAScript and namespace
"bar" is implemented in Java, but within one stylesheet run
all functions in namespace "foo" will be executed using the
same language and all functions in the "bar" namespace will
be executed using the same language.

| Uche Ogbuji wrote:
| >
| > > introducing the need for language bindings only reduces general
| > > interoperability while giving a small boost to
| > > interoperability between small axes of implementations.
| > >

XSLT 1.1 does not introduce the *need* for language bindings.
Extension functions continue to be a completely optional feature.
What it *does* say is that:

  -> if two conforming XSLT 1.1 processor implementations both
     have elected to implement the ECMAScript language for extension
     functions, then developers can expect that they'll implement
     the "contract" between the XSLT processor and the ECMAScript
     extension function implementations in a compatible way.

and similarly:

  -> if two conforming XSLT 1.1 processor implementations both
     have elected to implement the Java language for extension
     functions, then developers can expect that they'll implement
     the "contract" between the XSLT processor and the Java
     extension function implementations in a compatible way.

In XSLT 1.0, developers who today extend XSLT with extension
functions in ECMAScript using Alexey's Unicorn processor cannot
run them with Microsoft's MSXSL3 processor. They both support
ECMAScript extensions, but they do it in incompatible ways.

If both Microsoft and Unicorn produce conformant XSLT 1.1 processors,
then these stylesheets with ECMAScript extension would run 
interchangeably on both.

Of course, the ability to *avoid* using XSLT extension functions
remains exactly as in XSLT 1.1. So, for ultimately portability
there is no change at all: simply avoid extension functions.
This situation has surely not be made more complicated by XSLT 1.1. 
However, the lives of developers combining XSLT with ECMAScript
and Java extensions *has* improved because now even if they *do*
use extension functions, their stylesheets can still be portable
across implementations that implement extension function language.

The spec allows extension function implementations to be provided
in multiple languages, so a stylesheet developer can produce
a stylesheet with *BOTH* an equivalent ECMAScript and a Java extension
language implementation, and then, for example, a stylesheet that
uses extensions could run under SAXON (which might select to use
the Java extension function implementation) as well as Microsoft's
MSXSL3 and Unicorn which both might offer only ECMAScript language.

| In XSLT 1.0, the vendor of any particular XSLT processor can specify and
| implement the proprietary mechanism for building custom extensions.

This is precisely the problem. This ability to implement everything in
a totally proprietary way means nothing can ever be portable in the
extension function world.

| In XSLT stylesheets, these extensions appear as XPath extension functions.
| There are no platform-specific features contained in XSLT stylesheets
| themselves. Potentially, a stylesheet using extension function can be
| ported to any other XSLT processor, provided that this new processor
| implements the adequate mechanism for building custom extensions. Of
| course, extension functions must be re-implemented, but the XSLT
| stylesheet itself remains unchanged.

This is a rather theoretical argument. In practice, this has not
happened, even though I admit that it's technically possible.

| In XSLT 1.1, there is <xsl:script>, and there is Java as a standard
| language for extension development. This invites to create XSLT
| stylesheets containing mixed XSLT and Java code, which are portable only
| between Java-based XSLT processors.

All it does is allow developers who already are working in Java or
ECMAScript for extension functions, to suddenly no longer be restricted
to using their XSLT 1.1 compliant stylesheets with a single vendor's
XSLT Processor implementation.

| Well, XSLT 1.1 indeed DOES improve interoperability in comparison to
| XSLT 1.0 - for vendors and users of Java-based XSLT implementations. For
| vendors and users of non-Java XSLT processors XSLT 1.1 offers NOTHING in
| addition to XSLT 1.0.

This statement is not true.

In XSLT 1.1, since the <xsl:script> supports a 'language' attribute
that is a QName-but-not-NCName, all you need to do is invent a
convenient namespace prefix and then:

   <xsl:script language="unicorn:ecmascript">

can continue to be your proprietary implementation of ecmascript
extension functions. Or, you and five other vendors could get together
to come up with the standard binding for C-language extension functions
or Python-language extension functions, and then could all agree to
use:

   <xsl:script language="somePrefix:python">

   <xsl:script language="someOtherPrefix:c">

etcetera.

The language="java" is a shortcut for saying something like:

   <xsl:script xmlns:x=http://www.w3.org/2000/XSL/Transform/dom2-bindings
               language="x:java">

and language="ecmascript is a shortcut for saying something like:

   <xsl:script xmlns:x=http://www.w3.org/2000/XSL/Transform/dom2-bindings
               language="x:ecmascript">
 
______________________________________________________________
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/



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list