xsl:lambda was RE: W3C-transformation language petition

["Jonathan Borden" <jborden@xxxxxxxxxxxx>]

Chris Maden wrote:
>
>
> [Jonathan Borden]
> > Go with the flow (objects :-) The concepts remain the same, its only
> > the semicolons, commas and type of brackets that change.
>
> No, they're different in the expression language, too.  XSL doesn't
> have an expression language yet, but it's not likely to be Lispish
> (though it'll probably be side-effect-free).  It's not a big deal; I'm
> adaptable.  I think that Lisp lends itself better to structured data
> processing, but I also understand the political and marketing
> arguments that that many parentheses scare people.  I'll cope. (-:
>

	my first inclination was to suggest that a free Java DSSSL/Scheme
implementation might do for client side transformations what XSL does (or
might do) and more...

...but when you think about it, this might not be true... HTML is alot
closer to XML than Lisp in its syntax and HTML remains the most important
output format if we are concerned about client side applications.

what I am interested in doing is employing XSL as a client application
'language' for browser based client apps. So, what I need for XSL is to grow
into something akin to an XML based Scheme.  It already has a cons and car
and cdr and eq. XSL needs a lambda and defun and recursion. That's the stuff
that ought be between <xsl:eval> rather than Javascript.

Jonathan Borden
http://jabr.ne.mediaone.net


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