|
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.
| 
New Language: XEXPR