This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re[2]: XSLT 1.1 comments
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re[2]: [xsl] XSLT 1.1 comments
- From: Steven dot C dot Kienle at am dot pnu dot com
- Date: Tue, 13 Feb 2001 08:34:39 -0500
- Reply-To: xsl-list at lists dot mulberrytech dot com
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