[xsl] RE:"*NEVER* use for-each" and more evils of xsl:script

[Joerg Pietschmann <joerg.pietschmann@xxxxxx>]

Well, some more notes regarding the for-each issue.
We got a quick start with XML in the following way:
1. Some Web designers design a megacool HTML page which is used
   as an example.
2. Someone else (read: me) cleans up the mess the design tools write
   out as HTML and convert it into an XSLT-file by inserting 
   xsl:value-of and xsl:for-each in the appropriate places
3. String it all together.
Voila! Made a prototype in a few hours...

The problem is, even very minor changes in the HTML-Layout or in the
source XML structure usually cause a rewrite of the stylesheet from
scratch. There are better ways to waste time. So i convinced someone
else to start writing a stylesheet bottom-up using xsl templates.
The first results were anything but megacool, the webdesigners
were somewhat dissapointed because the thought their ideas went into
the bit bucket, and the stylesheet writer got a habit of constantly
muttering threats against me, the W3C, the XSLT-designers, various
tool vendors, the management and other entities. However, this
approach proved much more robust, and, as a side effect, the resulting
HTML is much smaller and renders significantly faster, and users
report an improved usability.

I think this is related to xsl:script evils. Embedding scripts in
XSL is not evil per se, and it will certainly solve a lot of problems.
However, if abused it *will* become a maintenance problem, and abuse
is easy. I'd bet we will soon see stylesheets which have more code
embedded in xsl:script than xsl code, and there will be abominations
like
<xsl:stylesheet>
  <xsl:script>
    // some hundred lines of script code
  </xsl:script>
  <xsl:template match="/">
    <xsl:value-of select="script:doitall()"/>
  </xsl:template>
</xsl:stylesheet>
This and other lists will be swamped with requests for optimisation hints
for code involving scripts which would be cleaner, more elegant and much
more performant coded in pure XSLT.
I know this because i'm teaching parts of web designer courses. Most of
the students are shockingly clueless about what they are going to do at
the beginning. Then they are force-fed HTML and a procedural language
(JavaScript), which is hard enough to grasp for them. When i come to
teach them about the wonders of XML and XSL, i have first to talk them
out of several DHTML induced misbehaviours ("glitz is more important then
content"). Getting them to grasp functional programming style would require
another few month of intensive teaching. If xsl:script is available, they
will fall back into trained patterns using a procedurall language at the
slightest glance of difficulties with pure XSLT, even if this requires much
more work and code.

Embedded script pose also a long term threat to maintainability even if the
script language is reasonably well standardised, because tool vendors usually
add "value-enhancing" functionality and market it aggressively. This functionality
is often used in the initial hype, but often enough such an enhancement is
discontinued after a few versions of the tool because a standardised replacement
got into the language, the feature simply proved to be redundant, or the vendor
got another idea of value-enhancement and changed the spec. Witness all the
problems with SQL in this area. It will be hard enough to deal with extension
functions in XSLT, which have the advantage of being easily recognisable because
of the separate name space.

I can also imagine that debugging and profiling facilities for embedded scripts
will be somewhat problematic. Even if they are deemed unecessary for initial
development, such facilities are indispensable later in the maintenance phase.
Everybody who was assigned to a PL/SQL-project should know what i mean.

Having said this, well, the only motive for withholding xsl:script would be to
prevent innocent users from shooting themselves. However, as everybody, including,
but not limited to, the evil empire, already hand out shotguns, we could legalise
shotguns as well. A useful compromise might be to label shotguns as dangerous
shotguns: put the script tag in another namespace, say
"http://www.w3c.org/2000/XSL/Transform/Script"; or ".../ProblematicExtensions".
Other potential problematic elements like eval might go there as well. I think
splitting XSLT into a core and an some standardised extensions would relax a
lot of tensions.
BTW xsl:output is not a problematic extension, because the concept of outputting
the results to a file is easy to comprehend and orthogonal to the way the
stylesheet is processed.

Regards
J.Pietschmann
--

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