[xsl] Re: XSL-List Digest V3 #507

Subject: [xsl] Re: XSL-List Digest V3 #507
From: "Dave Gomboc" <dave@xxxxxxxxxxxxxx>
Date: Mon, 12 Feb 2001 17:23:01 -0700
> Date: Sun, 11 Feb 2001 15:20:01 -0000
> From: "Michael Kay" <mhkay@xxxxxxxxxxxx>
> Subject: RE: [xsl] 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
> when compared with allowing each implementor to invent a different
> 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