Re: XSLT 1.1 comments
> | 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" I'm sorry, but I don't see how the paragraph I quoted translates into your three bullet points. You don't even mention "external object" in your bullet points. I am talking about the oddness of the language that selectes one aspect of external objects as "implementation-dependent" when clearly everything about external objects is "implementations dependent". BTW, I think this is about as powerful argument as one needs that they do not belong in the XSLT spec. > 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. Again, what is so special about parameters in this case? Everything to do with them is implementation (dependent. > | 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 this is true, then the "language bindings" should be removed from the spec, since they are otiose. > -> 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. Why does this contract belong in the XSLT spec? There are many perfectly good places to publish ECMA conventions. > 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. Ditto. > 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. But Unicorn and Microsoft can sort this out without any help from the XSLT WG. Why can't the Java implementors do so as well? > If both Microsoft and Unicorn produce conformant XSLT 1.1 processors, > then these stylesheets with ECMAScript extension would run > interchangeably on both. And what if C++ or Visual Basic, and not ECMA, is the most convenient language for the unified extensions? > 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. Again, I see no gain over XSLT 1.0, which allows all these advantages properly layered. > | 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. Absolutely false. See my last message responding to Francis Norton for the mechnism to sort things out without xsl:script. > | 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. Have you considered that the reason this hasn't happened is because XSLT 1.0 is only a year old? In fact, all you have to do is nix xsl:script, and move the Java and ECMA "bindings" to the appropriate W3C NOTE, and your rebuttal instantly vanishes. > | 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. Again, why is the spec necessary for this? XSLT is not a Java convenience library. It is a language of its own right, and intersections with other languages should be dealt with in a properly layered manner. > | 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"> ??? Don't you mean <xsl:script language="unicorn-and-microsoft:ecmascript"> Again, it offers nothing new to Unicorn, Microsoft or Python or Perl XSLT implementors. It does offer to Java official standing as an XSLT extension language in the spec. -- Uche Ogbuji Principal Consultant uche.ogbuji@xxxxxxxxxxxxxxx +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA Software-engineering, knowledge-management, XML, CORBA, Linux, Python 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