RE: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1

[Uche Ogbuji <uche.ogbuji@fourthought.com>]

> If I read this correctly, the problem is not
> the script element but the perceived requirement
> that Java (a Sun product) and JavaScript (a
> Netscape/AOL product) are required to be supported,
> thus engendering a product bias into a language
> neutral specification?

Actually, from the petition text:

"Success of this extension mechanism has brought about request for change
by several parties. One change is the official Java and Javascript
extension function binding. Although this petition does not specifically
challenge this addition, some question the wisdom of this decision. An
official binding could encourage wholesale importation of constructs from
Java and Javascript into XSLT without thought as to how those
constructs would or should be supported in XSLT proper. A second change,
the addition of xsl:script, is what we challenge with this petition."

The Java and Javascript language bindings are a slightly different, if
closely linked issue to the xsl:script issue.

My main objection to the Jav and ECMA bindings are that they pollute the
main XSLT spec and are given unseemly prominence therein, rather than
being completely relegated to an appendix, as in the DOM binding.
(Incidentally, someone has pointed out our comment on the DOM binding in
the petition text.  This is an error that escaped editing.  Besides my
wonder as to whether the DOM WG would give published prominence to other
bindings, I don't have any problem with the way DOM has provided Java and
ECMA bindings in the appendix).

But the petition itself is mostly aimed at xsl:script, and the harm it can
introduce by prematurely mixing up the clean layering between XSLT proper
and conforming extensions.

> Same problem with X3D.  The retort is
> that "We don't insist that an implementor
> support Java.  We insist that if they support
> Java, they use this binding."

The problem with xsl:script is that it makes it very easy to just dump the
Java right into the XSLT itself, causing a maintenance problem for users
and unfortunate pressure for XSLT implementers to implement language
scripts for the more popular languages.

What's so much the worse is that it's premature.  XSLT is very young for
such invasive tinkering.  The WG cites complaints by extension users about
incompatabilities between processors, but no effort has been made to
address this issue without the drastic resort of xsl:script.  If XSLT
implementers have users clamoring for standardized extensions, they can
band together to produce these.  I think that the other end of the
spectrum: sophisticated XSLT users who want to write their own extensions
in one Java processor and have them ported to another, are a much rarer
breed, and that the Java implementers can standardize this separately from
XSLT itself.

> The further
> explanation has been unofficially that failing
> to support Java has seriously hurt the acceptance
> of VRML.  In VRML, the required support was
> for EcmaScript and VrmlScript.  Neither satisfied
> the developers who wanted object-oriented language
> extensibility.

Well, XSLT 1.0 is *very* successful.  I don't think anyone can say that a
100,000 volt zap is required to keep it alive.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +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