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

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

• From: Charles Reitzel <creitzel@m...>
• To: Robin Berjon <robin@k...>
• Date: Fri, 02 Mar 2001 12:27:50 -0500 (EST)

At 05:05 PM 3/2/01 +0100, Robin Berjon wrote:
>
>I'm not complaining about Ecmascript/Javascript. I'm
>not complaining about the idea of making XSLT extensible 
>through language bindings either, that's imho a good thing.

I got you. Perhaps I was responding to other postings as well.


>Someone wanting to use extended functionality would simply 
>link in the appropriate ecmascript library, ...

I agree that you don't usually want to in-line substantial amounts of code.
But for a couple wee routines, you can't beat it.


>That works well. My only grievance (apart from the fact that
>ecmascript is a real pain to use) is that these extensions 
>are wired directly to ecmascript, and that's a pity. It 
>works ok for SVG because all one does is manipulate a DOM,
>and that's somethings ecmascript isn't too bad at. 

DOM manipulation via Javascript will be a valuable and important use of
<xsl:script> and is sufficient justification for the feature.  I think it is
there for all the HTML/Javascript warriors who, presumably, will be working
on XSLT stylesheets in the not-too-distant future.

Also, it doesn't seem wired to Javascript so much as scripting languages.
VBScript probably already works on IE. Perl and Python won't be far behind.


>People won't use ecmascript in XSLT if they want say
>powerful formatting functions. They'll use something less
>portable and less simplistic (eg Java). I think there's a
>strong case for making the implementation of the extension
>separate from the stylesheet, as described in Clark's xbind
>example.

Point taken.  It sounds like you want the original formatting objects.  But
couldn't you achieve the separation you desire by modularity?  I.e. each
library would have an "include" stylesheet that declares its extensions?


>I don't think the argument "it works for HTML/SVG/whatever" 
>holds for XSLT. It's a totally different kind of markup 
>language, and throwing script into
>it simply because it works elsewhere might not be so wise.

I think XSLT will be put to many uses that we may not anticipate - including
building web pages.  Why shouldn't stylesheet developers use a familiar,
effective mechanism?

I think this argument might be falling into the category of
giving-us-enough-rope-to-hang-ourselves.  I think that you'd like XSLT less
if it didn't.  <xsl:script> is probably one of the less dangerous features
of XSLT.  You might not approve, but plenty of people code JSPs, which are
probably an uglier embedding of Java than <xsl:script>.  Again, if you don't
like it, don't use the feature.

take it easy,
Charles Reitzel

• Follow-Ups:
  • Re: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1
    • From: Robin Berjon <robin@k...>

• Prev by Date: Binding XSLT script functions to implementation (was ANNOUNCE: Petition...)
• Next by Date: Re: XQuery: is FLWR a <xsl:foreach/> ?
• Previous by thread: Re: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1
• Next by thread: Re: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1
• Index(es):
  • Date
  • Thread