Petition to withdraw xsl:script from XSLT 1.1

Date:      Thu, 1 Mar 2001 01:05:42 -0500 (EST)
From:      "No xsl:script Petitioners" <no-xsl-script@clarkevans.com>
To:        xsl-list@lists.mulberrytech.com
Subject:   [xsl] 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

Prepared by Robin Cover for The XML Cover Pages archive.

SEARCH Advanced Search ABOUT Site Map CP RSS Channel Contact Us Sponsoring CP About Our Sponsors NEWS Cover Stories Articles & Papers Press Releases CORE STANDARDS XML SGML Schemas XSL/XSLT/XPath XLink XML Query CSS SVG TECHNOLOGY REPORTS XML Applications General Apps Government Apps Academic Apps EVENTS LIBRARY Introductions FAQs Bibliography Technology and Society Semantics Tech Topics Software Related Standards Historic	Petition to withdraw xsl:script from XSLT 1.1 Date: Thu, 1 Mar 2001 01:05:42 -0500 (EST) From: "No xsl:script Petitioners" <no-xsl-script@clarkevans.com> To: xsl-list@lists.mulberrytech.com Subject: [xsl] 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 Prepared by Robin Cover for The XML Cover Pages archive.