Subject: RE: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1 From: "David LeBlanc" <whisper@xxxxxx> Date: Thu, 1 Mar 2001 14:07:29 -0800 |
I see that there is no place to disagree with this petition, and I do so disagree! So long as it's not a proprietary language and it's either light-weight enough to move around the web readily or so broadly installed as to be ubiquitous (like javascript for better or worse), then I favor a script tag. Note that since Java is still esentially a proprietary language, that would preclude it's being a choice for me. I would much rather see bindings for Unicode aware vendor neutral languages like Javascript, Python, Tcl and (soon) Pearl (last I heard, Pearl's support for unicode was still in the future). Of course, this will never happen given the membership of the W3C and their proprietary language interests (i'm surprised that VB isn't a mandated language). Regards, Dave LeBlanc > -----Original Message----- > From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx > [mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx]On Behalf Of No xsl:script > Petitioners > Sent: Wednesday, February 28, 2001 10:06 PM > To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx > 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 > > > > > > > > > > > > > > > > > > > > > > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] ANNOUNCE: Petition to wit, Clark C. Evans | Thread | RE: [xsl] ANNOUNCE: Petition to wit, Adam Van Den Hoven |
Re: [xsl] ANNOUNCE: Petition to wit, Eric van der Vlist | Date | RE: [xsl] avoiding repeated items, Tim Watts |
Month |