Lambda the Ultimate

inactiveTopic XSLT Extensions Revisited
started 2/21/2001; 6:56:31 AM - last post 3/1/2001; 3:41:20 AM
Chris Rathman - XSLT Extensions Revisited  blueArrow
2/21/2001; 6:56:31 AM (reads: 1866, responses: 6)
XSLT Extensions Revisited
This gives a summary of the extensions being proposed in the next version of XSLT 1.1. Lots of good links in the article for anyone interested in figuring out where XSLT is headed in the future.

XSLT has seen quite a few extensions that are specific to the implementation and vendors, causing incompatibilities. Reminds me of HTML and CSS (with all their inconsitencies).

The main source of controversy cited is the introduction of the <xsl:script> tag. Personally, I'd rather have XSL promoted to a full fledged functional scripting language rather than have to fight the battle of embedded script within a script (the bane of ASP and JSP).
Posted to xml by Chris Rathman on 2/21/01; 6:59:23 AM

Chris Rathman - Re: XSLT Extensions Revisited  blueArrow
2/21/2001; 7:05:21 AM (reads: 1293, responses: 0)
I noticed that the O'Reilly OnJava page is mining LtU for it's news bits. Just wish that they would link us on those snippets (The link sends you to the meerkat mining interface).

Ehud Lamm - Re: XSLT Extensions Revisited  blueArrow
2/21/2001; 7:44:56 AM (reads: 1265, responses: 0)
Personally, I'd rather have XSL promoted to a full fledged functional scripting language rather than have to fight the battle of embedded script within a script

I know how you feel, but let's pursue this one step further. Isn't your approach going to lead to more and more general purpose languages, each with its onw syntax and semantics, causing lock-in? Isn't better to have more specialized languages, that connect well?

This is the same issue as modularization, components etc. No?

Chris Rathman - Re: XSLT Extensions Revisited  blueArrow
2/22/2001; 3:20:43 PM (reads: 1285, responses: 0)
We can always use more programming languages? :-)

My view is that XSL is a programming language of sorts that's useful for certain operations that isolate the data model (xml) from the presentation (html/wap/etc...). A couple of judicious extensions here and there, and I don't see why you need to embed translation time code (javascript/vbscript/etc...) into the script. To me, insertion of embedded script with XSL kind of defeats the whole purpose of XSL in the first place.

If you are going to limit the role of XSL, then it would be preferable to use a template type scheme that externalizes the objects/functions from the script itself. Kind of the JSP/JavaBeans/Servlet type arrangement. Of course, this would require some standardization efforts along the lines of external object models that probably is beyond reach.

Ehud Lamm - Re: XSLT Extensions Revisited  blueArrow
2/24/2001; 2:39:46 PM (reads: 1248, responses: 0)
Over on Scripting News:

This reminds me of another project I heard about a few months ago, to do a XMLization for scripting languages. Basically it would define an XML mapping for loops, tests, assignment, procedure calls, basically every feature that every Algol-like language supports. Then scripting engines could output this format, and the scripts could run in any compatible scripting environment. While I haven't given this a lot of thought, it seems do-able, and powerful, and quite interesting. Think of how much we'd learn about other languages.

Oleg - Re: XSLT Extensions Revisited  blueArrow
2/26/2001; 10:18:44 AM (reads: 1227, responses: 0)
A web page referenced below gives a critique of one such language -- XEXPR -- and offers two systematic ways of assigning an executable semantics to XML. One is to assign an executable semantics, reduction rules, to an abstract syntax tree representation of an XML document. The other approach is to start with an extant programming language and to introduce rules to pretty-print its abstract syntax tree into the XML format. Both approaches are especially easy if the programming language is Scheme. The concrete syntax of Scheme is basically its abstract syntax as well. On the other hand, SXML -- an abstract syntax for XML -- has a representation that parses not only as Scheme "data" but also as a Scheme "expression" (by R5RS syntax definitions). In SXML, abstract syntaxes of Scheme and XML unify.

More details and examples of such pretty-printing (along with the working code) are available at http://pobox.com/~oleg/ftp/Scheme/xml.html#executable-XML

See also http://pobox.com/~oleg/ftp/Scheme/SXML-short-paper.html for XPath and a XSLT in Scheme style.

Ehud Lamm - Re: XSLT Extensions Revisited  blueArrow
3/1/2001; 3:41:20 AM (reads: 1204, responses: 0)
XSLT experts petition against script element:

The XSLT specification clearly states XSLT is not intended as a completely general-purpose XML transformation language. XSLT is a special purpose language and should be maintained as such. Much like structured query language, we think the general purpose languages should embed XSLT, not the other way round.