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

[Evan Lenz <elenz@xyzfind.com>]

Len Bullard wrote:
> 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?

Yes, it's all about perception. Each of these new extension mechanisms would
add nothing in terms of technical functionality to what is already available
in XSLT. They provide *convenience* in writing stylesheets that will work
with more processors, but still not all processors. While "more
interoperable", they will still not be Interoperable. That's the nature of
extensions.

My problem with xsl:script is that it makes extensions look like something
other than extensions. And despite all the arguments I've heard that say
that it will not encourage people to include procedural code when they
otherwise would not, I believe that it certainly will encourage them to do
so. I also believe that XSLT implementors who had not implemented such a
scripting functionality before (a la msxsl:script) will do so now, because
the W3C has given its blessing on it, and people will be expecting it.

What's ironic to me is that XSLT 2.0 will be taking away many of the reasons
why people resort to procedural code in the first place (inconvenient string
processing, etc.) by adding more convenient built-in functions, etc. Thus, I
see xsl:script as a short-term tactic that will take some headaches away but
not very forward-thinking or strategic.

It may always be necessary to have an extension mechanism. But whenever you
use extensions, you're giving up portability. I agree with Uche that
xsl:script creates a caste system of XSLT processors; such a caste may
eventually exist anyway, but it shouldn't be part of the XSLT spec, for all
the reasons I cite above.

XSLT is one of the most portable programming languages yet. I'd like to see
how long we can keep it that way.

Evan