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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format