Subject: Re[2]: [xsl] XSLT 1.1 comments From: Steven.C.Kienle@xxxxxxxxxx Date: Tue, 13 Feb 2001 08:34:39 -0500 |
OK, just to give another opinion. I am a customer of XSLT, not a developer of an XSLT processor. An xsl:script tag isn't worthless, but it is dangerous to me as a developer. There are times where C, EMCAScript, Java, etc. would give me an ability to implement a descrete function more concisely than XSLT directly. I like that, and it would be useful at times. But, and this can be a huge but, as soon as I do that, I would _never_ blindly assume that the function so written would work in any other XSLT processor, at least without some serious tests. It doesn't matter what the WD or RD would say about this. The problem is simple, I can trust an XSLT processor which has been out for a while to implement XSLT properly. How long would I need to wait before I can ensure that it has the correct bindings to C, Java, EMCAScript, etc. to work without side effects. For a processor written in Java, yes, I can make some reasonable assumptions about Java based xsl:script blocks, but what about EMCAScript based ones? For a processor written in C, what assumptions can I make about even the C based xsl:script blocks? In that case the XSLT processor has to include a C interpreter, or ensure that the OS it is running on has a C compiler available..... So, basically, I am saying that it isn't a silver buller. And, as a customer of the XSLT spec, I would put any xsl:script blocks I use in my code in the same class as all XSLT processor extensions. Use it if necessary, but assume it will take some testing and possibly recoding to convert to another XSLT processor. Steve XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
namespace for xxx:script (was: [xsl, David Carlisle | Thread | RE: [xsl] XSLT 1.1 comments, DPawson |
[xsl] Need for a technique, Paul Terray | Date | Re: [xsl] XSLT 1.1 comments, Elliotte Rusty Harol |
Month |