Lambda the Ultimate

inactiveTopic New Language: XEXPR
started 11/22/2000; 12:14:07 AM - last post 11/25/2000; 1:46:52 PM
andrew cooke - New Language: XEXPR  blueArrow
11/22/2000; 12:14:07 AM (reads: 735, responses: 5)
New Language: XEXPR
Seen at HTP. A scripting language for XML. Functional; elements of the language are themselves XML tags; on the official W3C site. Can't work out if it's been implemented, though.

I'm confused - how does this fit with whatever was being used in a discussion here a few weeks ago to do calculations within XML?
Posted to "" by andrew cooke on 11/22/00; 12:15:38 AM

Chris Rathman - Re: New Language: XEXPR  blueArrow
11/22/2000; 7:43:20 AM (reads: 821, responses: 0)
Haven't had time to really explore the language but I did read enuf (and have enuf expertize in the area) to know what it's role is supposed to be.

The stuff we were doing in XSL is designed to generate formatted pages - be it HTML, PostScript, or another XML document. The thing about XSL is that it's a pure filter and translate mechanism. The translate process runs once and generates a document in the desired format. Once the XSL translation occurs, it's mission is complete.

That leaves you with the problem of having documents viewed by the client having programmatic logic built. Currently JavaScript is the most widely used client side scripting language. What you find, however, is that XML (and documents generated thru XSL) have a tuff time coping with JavaScript - not being xml compliant, the parsing of the document becomes much more problematic.

The attempt with XEXPR is to have an XML compliant language to be used for client side scripting purposes. Things like sophisticated manipulation of images, better GUI control, as well as client side validation are the target. If you're familiar with PHP or ASP, you might think of XSL as fulfilling the role of the server page engine and XEXPR as taking the role of embedded JavaScript.

It is a little more complicated than this in that XSL can be pushed off to the client to run when the page is loaded. Also it's possible to have server side XEXPR just like we have server side javascript.

As for a general opinion, I would say that on the one hand I really need a better long term solution to embedded scripting than JavaScript. But I do have a couple of reservations. Embedded XML scripts in an XML document can really cause grief in trying to decide what's 'data' and what's 'script'. The one thing that JavaScript has going for it is that it doesn't look like HTML. The transition to and from script to dcoument is easier to clue in on.

This situation would really get complicated if you have server side documents using XEXPR for page generation and the output document has embedded XEXPR. On one project I did a while back in ASP (MS Active Server Pages), we explored using JavaScript on both the server and client side, hoping to keep the number of languages to a minimum.

We ended up with a jumble that was hard to follow in that you had a hard time reading where the heck you were at anytime. The result was that we shifted to VBScript on the server and left JavaScript on the client. Telling the difference between the two languages was relatively easy and it provide an instant focus on where the heck the logic was to take place.

Oh well, getting too long winded on the subject. Thanks for the link. I'll try to dig around and see if there's any reference implementations - mostly, though, you'll probably have to wait for the various browsers to adopt the standard which may be awhile.

andrew cooke - Re: New Language: XEXPR  blueArrow
11/22/2000; 8:22:26 AM (reads: 741, responses: 0)

Strangely, it seems to be missing support for lists (which would be like nested tags, I guess). At least, there doesn't seem to be a way of building lists or taking the head and tail. Seems an odd omission - or is it possible?

Ehud Lamm - Re: New Language: XEXPR  blueArrow
11/24/2000; 8:44:15 AM (reads: 702, responses: 0)
I am not up to speed on all of this, so take my comments with a grain of salt.

I am starting to get to the conclusion that XML or no XML, programming should be done using a good general purpose language. Then you don't have to worry aobut how to create a random number (etc. etc.). Hacking the restricted special purpose languages (XSL etc.) is great un, but I am not sure if it is the right way to go, for a real project.

This is good, on the one hand, since programming should be done by people who know what they are doing, and with mature tools. Even then, the results are not always what you'd wish for.

On the other hand, the result will be that if you want portability (and XML is, among other things, about portability) you should use Java. This is a sad outcome...

andrew cooke - Re: New Language: XEXPR  blueArrow
11/25/2000; 5:04:05 AM (reads: 705, responses: 0)
There's an alternative, which is to let the special-purpose languages access a common set of services. So Mondrian can call anything in the Microsoft toolkit, for example, when running on .NET. This seems, to me, to be the really good thing about .NET - it appears to offer otherwise "obscure" languages the ability to compete on features. Of course, there's the obvious drawback of being locked into Windows.

I guess Java byte code is the equivalent to .NET for wider platforms, but I have the impression that because it was designed to support just Java it is more restrictive. But really, I have no clue :-)

As far as this XML language goes, I can't see why they didn't simply map Scheme directly, using XML tags rather than parentheses. That would give an easy route for implementation and allow this kind of interfacing.

Ehud Lamm - Re: New Language: XEXPR  blueArrow
11/25/2000; 1:46:52 PM (reads: 730, responses: 0)
If I understand you correctly, this exactly the same advantage as using things like COM (and DLLs, and code libraries etc. etc.)

Indeed some language envs. have good support for this. I recall someone saying the in Dylan you can magically see any COM interface installed on your system, inside the IDE (not sure which one. Guess the Functional Objects impl.?). It just scans the DLLs and let you see what's there. GNATCOM allows you the same thing in Ada. Indeed the XML4J and other Java code are, it seems, the 'standard' way to go about using XML and DOM.

As to Scheme and XML: There's always DSSSL (or have I missed one S?), and other lisp like markup languages.