Re[2]: XSLT 1.1 comments

  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