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

[Robin Berjon <robin@knowscape.com>]

At 15:05 01/03/2001 -0800, Steve Muench wrote:
>| >The 'src' attribute purports no magic beyond the standard URI mechanism.
>| 
>| And, to paraphrase, how is that not look-it-up(DNS,locator
>| services,repositories,etc)-and-magically-download(HTTP,FTP,etc)-the-right(Co
>| ntent-negociation,browser/processor sniffing,etc)-(trusted?)-etc-etc-etc ?
>
>It's uri-specific, and generic to all URI's, not URI's
>being used by XSLT or in particular URI's being used
>by the <xsl:script> element. That is, it's not XSLT 
>processor specific "magic" which is the way I interpreted
>the various suggestions that an XSLT processor would
>"look up and find" it's own extension function implementations.
>
>If you are saying that there is an:
>
>   rddl://....
>
>URI protocol scheme that's RDDL aware, then <xsl:script> would
>already support it by virtue of its being a valid URI.

Good. In fact, I think we agree at some level. RDDL is just an xhtml
document (for human consumption) containing extra rddl information for rddl
aware processors. I'm not aware of plans to use an rddl:// scheme (I rather
thought that it would simply be over http as most html documents) but I
didn't follow the discussion to its full depth.

I'm not criticizing the src attribute on xsl:script per se, but as I said
the tieing of the implementation of an extension to a given language. Yes
one can include a dozen <xsl:script language='Java' src='.../ext.jar'/>,
<xsl:script language='Perl' src='.../ext.pl'/> and so forth in order to
write portable style sheet, but that is impractical and puts all the weight
on the style sheet writer which is imho a bad idea. We could (and in the
event that this thing sees the light of day, think we will) implement
processors that can understand <xsl:script language='RDDL'
src='http://foo.com/ext.html'/> and that's a possible (and perhaps even
good) solution to the src thing.

However it still leaves open the fact that embedding code will tie
extensions to an implementation. No one will ever start including multiple
implementations in a single style sheet. At best it'll look like what one
sees in browsers nowadays with javascript. Has the XSL WG forgotten the
browser wars ? Just because it cooled down doesn't mean it won't happen
again, especially when browser-side xml starts to flourish.

<xsl:script language='MS-ecmascript-with-some-VB'>
blabla
</xsl:script>
<xsl:script language='Sun-ecmascript-with-some-Java'>
blabla
</xsl:script>
etc...

If the above pseudo example doesn't scare the hell out of you then chances
are you probably haven't spent enough time around the poor people that have
to create portable html nowadays (or worse, a year or two ago). My team of
web guys has learnt XSLT over the past few months and they're thrilled.
They just love it, and they've been productive as never before. I pointed
them to the 1.1 draft when it came out and the immediate reaction I got is
"are they serious about that xsl:script thing ? Well, at least the good
times will have lasted a few months". 

This is just begging for trouble. I don't think encouraging bad practice is
a good idea.

-- robin b.
James Joyce -- an essentially private man who wished his total indifference
to public notice to be universally recognized. -- Tom Stoppard