Re: Efficiency Issues

> My mind thinks of devilish plans to give away most of 
> the Business Logic or complex calculations to Java and receive it in 
> the XSL end and continue with display as usual. Would this kind of 
> Java object invocation lead to any performance issues??

As was recently discussed in this group, using extension functions
within an XSLT transformation brings side effects and could at times
result in unexpected/undesired anomalies.

About efficiency: reasoning that using a compiled (in this concrete
case Java) program is faster than an interpreted one (in this case an
XSLT transformation) is correct but only if all other conditions are
equal.

A compiled implementation will not magically make faster a program that
implements not the best algorithm and/or uses not the efficient data
structures. Just a few days ago we had the example when an XSLT
transformation using the FXSL function str-filter() significantly
outperformed for string of moderate or greater length another one,
which relied on the ***built-in*** function translate.

Therefore, finding and applying the most efficient algorithm/data
structures has higher precedence than the choice of compiled over
interpreted programming language for the implementation.

Just my 2c.

Cheers,
Dimitre Novatchev.




__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

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