Cart
|
[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
 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
