Re: Leventhal's challenge misses the point

["Larry Fitzpatrick" <lef@xxxxxxxxxxxx>]

Hi,

> 
> Perhaps a "side effect free" subset of JavaScript plus any needed DOM and
> CSS enhancements would prove to be easier to use and as robust/safe as
> XSL's declarative approach.

A powerful design technique is to use an xsl "metascript" to process configuration 
information (xml of course) and generate the XSLT "script" to process the data. This 
allows one to build applications that handle multiple classes of data transformations,
and where each class handles an arbitrarily large number of schema-dependent 
transformations. 

This is really easy to do with XSLT.  I don't know CSS, is this easy to do with CSS? 
(for data not targeted at a browser?)

In a 3gl world, the analog to this design option is to programmatically generate code
that gets evaled to do the real work. Perhaps I'm skittish, but I wouldn't choose this design option 
with a more procedural (than xsl) programming language -- even with my fave 3gl (python) -- 
except under duress.  In a 3gl, the more rational design choice to solve this class of problem
is to implement the equivalent a specialized interpreter for a specialized 
transformations -- lo and behold, that is exactly embedded XSLT!  So...

Why aren't the DOM and embeddable XSLT completely complementary in the context of a
3gl like python, java, c++?  

lef



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