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

["David LeBlanc" <whisper@xxxxxx>]

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