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

RE: ANNOUNCE: Petition to withdraw xsl:script from XSL

Subject: RE: ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1
From: "David LeBlanc" <whisper@xxxxxx>
Date: Thu, 1 Mar 2001 14:07:29 -0800
david pawson disagree criticism
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:  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

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
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.