ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1

Collegues, 

Earlier last month, Uche Ogbuji posted a very thoughtful
commentary [1] on XSLT 1.1.  His remarks resonated deeply with
many of us and sparked a long and serious discussion about 
xsl:script, as summarized [2] by Leigh Dodds.  It was suggested
during this discussion that Uche's analysis and conclusions 
regarding the inclusion of xsl:script were either too late [3]
or not backed by a sufficient user community.  In any case, 
both Scott Boag [4] and Steve Muench [5] encouraged formal
feedback to the W3C working group.

It is because of this encouragement that several of us got 
together, collected our thoughts on the topic, and have 
assembled the following petition.

  http://uche.ogbuji.net:8000/etc/no-xsl-script.xhtml

If you agree to the petition above, would you be so kind as to 
add your signature at bottom of the page.  We expect to wrap up
the signature period on the 15th of March and will send a formal 
copy to the XSLT WG at that time.  We sincerely hope that this 
user-driven feedback to the W3C will help advance the XSLT
specification. 

Respectfully yours,

  Clark C. Evans, Individual
  Peter Flynn, Individual
  Alexey Gokhberg, Unicorn Enterprises SA, XSLT implementer
  Francis Norton, Individual
  Uche Ogbuji, Fourthought, Inc, XSLT implementer
  Dave Pawson, Individual
  Tobias Reif, Individual
  Adam Van Den Hoven, Individual

P.S. 

For discussion purposes, an ASCII text version is included
below.  However, please note that the official version, 
which can be signed is found at:

  http://uche.ogbuji.net:8000/etc/no-xsl-script.xhtml

...

Petition to withdraw xsl:script from XSLT 1.1

XSLT provides an extension mechanism whereby additional
functionality can be identified with a URI reference and
implemented in a manner defined by a particular XSLT
processor.  This mechanism provides an opaque layer between
the extension function's usage and its implementation --
allowing for many implementations of an extension function
regardless of language or platform.  This extension facility
provides a rich playground where new features can be
prototyped and even put into production.  However, to
balance this much-needed flexibility, the syntax makes it
clear that such added functionality is, in fact, an
"extension" and therefore may not be portable across XSLT
implementations.

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.

As users and implementers of XSLT, we request that the W3C
withdraw section 14.4, Defining Extension Functions from the
current XSLT 1.1 working draft for the following reasons:

1. The XSLT specification clearly states XSLT is not
intended as a completely general-purpose XML transformation
language.  XSLT is a special purpose language and should be
maintained as such.  Much like structured query language, we
think the general purpose languages should embed XSLT, not
the other way round.

2. A primary objective of XSLT is to provide for portable
transformation of XML files.  As many developers will use
embedded scripts rather than learn the equivalent XSLT, the
distinction of what is and what is not XSLT will become
blurry and this will hurt portability and re-use.

3. XSLT is a new and growing language.  For targeted
languages like XSLT, there is a precedent (SQL) for keeping
the language small and growing it incrementally as
requirements become more clear.  This embedded scripting
mechanism is premature and the results could exacerbate the
already difficult problem of compatibility.  Further, it may
hinder the discovery of new functionality requirements.
XSLT is already a very successful language.  Let us first see
where standard bindings and standardized extensions take us.

4. Commonplace use of scripting interpreters may hurt XSLT
performance.  With built-in extension functions, side
effects can be managed by the implementer.  However, with
frequently used and unknown extension functions from varied
languages, potential side effects limit optimizations.

5. Easy distribution of extension functions, a reason
commonly cited for embedded scripting, can be addressed
separately and does not necessarily have to be solved with
the script metaphor, convenient as it may be.

6. Without embedding, it is clear that multi-platform
implementations of extension functions used by a stylesheet
are necessary for true portability.  The burden is clearly
on the user to ensure this coverage.  Things change with the
W3C's blessing of embedded Java and Javascript.  Regardless
of disclaimers written in specification, the average user
will assume that all XSLT processors must support Java
and/or Javascript.  Realistically this means that XSLT
vendors will be pressured to provide both Java and
Javascript support to meet customer expectations.

7. With the new extension function language binding clauses
and recent changes to the DOM specification, it appears that
the W3C strongly favors Java and Javascript over other
equally qualified languages.  We would prefer language
neutrality.

8. Under the current working draft there does not appear to
be a method by which XPath extension functions can be
written using XSLT.  Thus, extension functions written in
XSLT will be less standard then extension functions written
in Java or Javascript.

9. In discussion on the XSL mailing list, it was stated by a
member of the working group that the language binding and
xsl:script element are stop-gap measures to be used until
the full feature set of XSLT is attained.  However, concerns
over maintaining backwards compatibility will mean that
deprecating these features, which will surely find heavy use
in most applications, will be nearly impossible.  Further,
scripting will become the de facto mechanism for extending
the functionality of XSLT, not discussion of added
functionality by the XSL WG.

10.  XSLT is quickly becoming a building block for higher
level tools, such as XSL Formatting Objects and Schematron
and is currently being discussed in the context of XQuery.
W3C has done a very good job keeping XPath free from
platform and language entanglements, we hope that the W3C
will see the wisdom of continuing this pattern for XSLT.

Thus far, XML technologies are independent of language and
platform.  However, the closer any one XML technology gets
to language or platform dependency, the weaker is this
family's ability to span the gap between platforms in a
robust, efficient, and transparent nature.  If we focus on
growing XSLT proper, we can minimise and decouple the need
for language and platform specific scripting and extensions.
This could enable increasing levels of portability and
underscore the role of XSLT as the portable XML
transformation language.

References:

  Leigh Dodd's  summary [2] of the debate at XML-Deviant
  Uche Ogbuji's original comment[1], including criticism 
                of xsl:script
  Scott Boag,   XSLT working group member, affirms the WG's 
                interest in comments[4], and suggests conference 
                with XSLT implementers.
  Steve Muench, WG member, encourages more comment to the WG [5].

Respectfully yours,

  Clark C. Evans, Individual
  Peter Flynn, Individual
  Alexey Gokhberg, Unicorn Enterprises SA, XSLT implementer
  Francis Norton, Individual
  Uche Ogbuji, Fourthought, Inc, XSLT implementer
  Dave Pawson, Individual
  Tobias Reif, Individual
  Adam Van Den Hoven, Individual

To Sign this Petition Please Visit:

   http://uche.ogbuji.net:8000/etc/no-xsl-script.xhtml#sign

...

[1] http://www.biglist.com/lists/xsl-list/archives/200102/msg00501.html
[2] http://www.xml.com/pub/a/2001/02/14/deviant.html
[3] http://www.biglist.com/lists/xsl-list/archives/200102/msg00507.html
[4] http://www.biglist.com/lists/xsl-list/archives/200102/msg00611.html
[5] http://www.biglist.com/lists/xsl-list/archives/200102/msg00607.html

Received on Thursday, 1 March 2001 16:26:29 UTC