Re: XSLT 1.1 comments

Steve Muench wrote:
> 
>   -> 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.
> 

and alternatively:

-> if two conforming XSLT 1.1 processor implementations both
   have elected to implement the C++ language for extension
   functions, then developers can expect that ...
       Really, what can we expect in this case?

>
> ... Microsoft's
> MSXSL3 and Unicorn which both might offer only ECMAScript language.
> 

They both are going to offer C# extensions as well. 

I am wondering - how will they manage to get interoperable
implementations? 

Maybe, XSLT 1.1 will help them?

> 
> | 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.
>
> ...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. ...

Well, and how this can improve *interoperability* of my software?

> 
> ... 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.
> 

This means that my original statement IS TRUE. Java implementors will
enjoy benefits from XSLT 1.1 standartization, while Python and C
developers will have to "get together to come up with standard binding
for ... extension functions ..."

Do you mean that we will have to form our own private consortium in
order to create/implement/promote standards for XSLT in non-Java world?


Kind regards,

Alexey

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