Re: On loss of integrity with xsl:script...

Guy_Murphy@xxxxxxxxxx wrote:

>
> Task in the corporate sector like batch transformation of large data sets,
> where optomisation is crucial. Sticking to pure XSLT.
>
> And the K-Rad website where the designer just don't give a **** as long as
> it looks cool, sings, dances and has flashing lights. Resorting to hacked
> scripted functions etc. Doesn't need to be optimal (as it's a small data
> set), just pull all sorts of funky tricks.
>

I disagree slightly with the above comments. While I agree that the K-Rad
webdesigner will undoubtedly try to hack and bastardize XSL, I don't believe
that the corporate users will shy away from doing the same, simply because XSLT
might not completely meet their needs.

I've already found it necessary to pre-process my XML so that it makes good XSL
food, which is what I wanted to avoid in the first place. Who wants 10
different flavors of XML sitting around on their server?

If xsl:functions or xsl:scripts can give me the power to keep one flavor of XML
source and still create all the outputs that I need to deliver, I will use
them.

However, I would prefer a standardized programatic approach instead of an "add
your language here" script tag, if only for the sake of consitency. If this
means loosing granularity and validation, so be it. I would hate to have to
debug XSLT stylesheets that could have scripts in 10 different languages
embedded within them. Just imagine the cross platform problems that could arise
when you need to develop on NT but go into production on Solaris? XSLT needs to
be functional, portable, and consistent if it is to achieve success in the
corporate environment.

Rick Geimer
National Semiconductor
rick.geimer@xxxxxxx


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