[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

On loss of integrity with xsl:script...

Subject: On loss of integrity with xsl:script...
From: Guy_Murphy@xxxxxxxxxx
Date: Tue, 11 May 1999 09:17:01 +0100
loss of integrity

OK, I'll admit up front that I'm firing from the hip here, as I haven't
followed up on the references Paul posted. So my comments here are at best
half-baked (but that's never stopped me).

I'm also *not* trying to reopen a Jihad on the inclusion of script tags in
XSL, I just want to introduce a point for possible comment.

I sort of understand the point around this whole "Turing complete" thing,
that if XSL drifts with a loss of its declarative nature, then we also
loose things like checking compatibility, and a loss of the granularity to
which we can easily validate in general.


What we are seeing is an increasing number of functions being brought into
XSL, and an increasing number of programatic rather than description
mechanism. We seem to be facing a creep away from a descriptive language in
order to cater for increased functionality, which although often marginal
in its usage, is vital when needed. Paul seem to give at least a firm basis
for concern that we might be loosing things in this process.

If however, we had a script tag, that we could escape to for those marginal
but essential tasks, might we not have exactly that, an escape. Something
outside of XSL? In this way XSL could retain its "purity", and be
implimented where needed in a robust, simple form, unadulterated, but still
catering for expedience outside of the XSL language itself with the script

This would seem to give us a pure, lean, highly optimisable language,
suitable for 90% of tasks, and a means for quick-and-dirty hacking for when
we just don't care.

It would also seem to cater for the two ends of usage....

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 [expletive deleted] 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.

Personaly I find myself playing both roles in my working life, so I'm
merely expressing how I might like to use XSL. There are times when I want
XSL to be highly optomised, and times when it doesn't matter. As things are
drifting, I'm not going to get either end of the stick, but a luke warm
compromise in the middle.



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

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.