RE: XSLT 2 backwards compatibility (wsd: Normalize / S

>   I think most of us have control of our target environments, so
>   portability comes last compared to functionality, performance and
>   maintainability.
> 
> Ah maybe that's the main difference. Not sure if its my TeX 
> background, but I place portability above all three of those. 
> the reason I want to write code in a standard language is 
> that I know wat happens when someone else runs it in some 
> other place. I don't really care if there is a non-portable 
> extension that makes it go ten times as fast. I might (but 
> probably wouldn't) use it in private projects but I wouldn't 
> use it in code that's freely distributed.

Ok I will plays devils advocate here...

1.  xslt that runs on the client needs to be portable, because there is
no control over the client environment - however, its likely to be IE
with msxml until the others catch up.  Msxml doesn't support xslt 2.0,
and Ive heard there's no plans to support it, so the backwards
compatibility issues wont apply here.

2.  xslt that runs on the server / within an app doesn't need to be
portable, as there is control over the target environment.  In this
situation a 10x improvement in performace is definitely preferred over
portability.  Should the need arise to change processors, it does take
that much work to alter the processor specific stuff.

3.  If your xslt is freely distributed, and the processor it runs on is
freely distributed, wheres the problem!  Its all free, and it runs 10x
as fast :)

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list