[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XSL-List Digest V3 #507

Subject: Re: XSL-List Digest V3 #507
From: "Dave Gomboc" <dave@xxxxxxxxxxxxxx>
Date: Mon, 12 Feb 2001 17:23:01 -0700
 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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.