[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XSL-List Digest V3 #507
> Date: Sun, 11 Feb 2001 15:20:01 -0000 > From: "Michael Kay" <mhkay@xxxxxxxxxxxx> > Subject: RE: XSLT 1.1 comments > > > introducing the need for language bindings only reduces general > > interoperability while giving a small boost to > > interoperability between small axes of implementations. > > > I don't understand. How can defining a Java language binding which > implementors are at liberty to implement or not, reduce interoperability > when compared with allowing each implementor to invent a different Java > language binding, which is the current situation at XSLT 1.0? > > Mike Kay The difference is one of developer expectation. Currently, it is very clear that features provided for executing code written in other languages are extensions to XSLT proper. The concern is that by defining specific language bindings in XSLT's W3C standard (in the xsl: namespace, no less!), future developers will view uses of these languages to complement their XSLT as normal rather than exceptional, and as a good practice rather than one that should be avoided when it is reasonable to do so. Feared consequence one is that developers new to XSLT will not bother to learn how to use XSLT fully and effectively, because an easy workaround exists in their favourite procedural language. This will lead to an over-reliance upon script extensions, leading to feared consequence number two, which is that support for additional languages (e.g. ECMAScript, Java) will be required de facto to execute a large percentage of XSLT code. Feared consequence three is that advancements in the XSLT language itself will occur more slowly, because the normalisation of using extension functions undermines the need to improve the XSLT language itself. Sure, the extension function will work on any processor that supports such-and-such, but XSLT interoperability is reduced in the long term, because people who use processors that don't support such-and-such end up with a large porting effort ahead. You might think that these concerns are unfounded, but please take a look at the number of "portable" applications written using the MFC, then reconsider. If interoperability between Java implementations of XSLT processors is your goal, then a standardised language binding for Java makes sense. If interoperability between _ALL_ conformant XSLT processors is your goal, though, then it is not at all clear to me, and indeed highly debatable, that the establishment of such a binding is a step in the right direction. Dave Gomboc 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
|