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

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

  • From: Evan Lenz <elenz@x...>
  • To: "Bullard, Claude L (Len)" <clbullar@i...>,Uche Ogbuji <uche.ogbuji@f...>, xml-dev@l...
  • Date: Thu, 01 Mar 2001 11:42:47 -0800

xsl script
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


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
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

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.