RE: XSLT 2.0 and <script>

a general comment, 
 
<script/> is not just inefficient, but introduces potential
'side-effects' into the xslt transformation which introduces all sorts
of fun problems for both XSLT processor implementators, as well as
creating non-portable xslt. 
 
The idea that XSLT does not have such an element means that it is more
reliable, simple, and stable...not the opposite. 
 
XSLT primary purpose is to transform data into another set of data, not
as a programming language...using XSLT in conjunction with other
programming languages means that marshaling data code usually moves
across to XSLT, though this doesnt mean that XSLT should become
responsible or 'host' another languages functionality.....though XSLT
2.0 is looker more like a programmatic language its main job is still to
transform data, and I think that the editors have done a good balancing
act.
 
Is it possible to describe a scenario or use case that absolutely
requires <script/> ?
 
reviewing the xslt list archives will reveal quite a few threads along
this line.
 
cheers, Jim
 

-----Original Message-----
From: xsl-editors-request@w3.org [mailto:xsl-editors-request@w3.org] On
Behalf Of Yusuf Simonson
Sent: 17 January 2004 14:08
To: xsl-editors@w3.org
Subject: XSLT 2.0 and <script>


Why is it that the XSLT 1.1 spec supports <script> but not 2.0?  While
inefficient, I find myself extremely handicapped without support for the
<script> tag.
 
There are some things that XSLT will never be able to do to preserve its
stability, reliability and simplicity.  Why not allow for scripts to
handle to handle the rest?
 
- Yusuf Simonson