For a rather complex internal web project of Geode (a company I'm part of since its inception), a few years ago I started working on an XML-based scripting language called GXI, mostly used for building web pages. Over the last 6 months I've become the main developer of this language, and right now I'm spending some time to extend and enhance it, so I decided it was about time to blog about it.
Why XML? We came to this idea because we have a set of servers that communicate by exchanging XML, and we already have a system allowing us to execute a few commands (each returning and XML document) and apply an XSLT transformation to them, to produce web pages. For example, my old site delphi.newswhat.com is still based on that version of the old version of our architecture. The trouble is pages are quite hard to customize, and it is almost impossible to base further processing on the outcome of the first of a set of commands. That's one of the reasons we started working on a language and its interpreter.
Why XML for the language? Although I've seen many voices critical of the XML syntax for a language, as it is far less natural than traditional langauges. It made sense for our architecture, but the more I use it the more I think it makes a lot of sense overall. If your aim is to generated tag-based content (and this is what HTML is about) working in a tag-based environment is quite nice. In GXI, we can intersperse language statements (assignments, conditional operations, loops, commands processing) with the tags part of the structure of the final document, which can either be XML (generally to be turned into HTML via XSLT) or directly HTML. This means that a source code file is an XML document, exactly like the documents representing the application data. It also means you can dynamically produce source code files by manipulating data with an XSLT file, same process used for producing the output. This is terribly powerful!
What are the drawbacks? For one, we had to come out, develop and maintain our own language, although writing an XML-based parser is far easier than writing a generic language parser. Had we used an existing open source language, we could have saved some effort. But from what I see around, XML is still not natively supported by most scripting languages, and not so commonly used to build web sites (as I think it should be). In our language we have a native "nodeset" data type, representing an XML document or a fragment. We can use XPath and XSLT as native nodeset operations. I've not seen any other language with this power, although LINQ is going into the same direction (at least in part).
Do you remember the Charlotte project, that of a language to "glue" web services? Our language is exactly in that space. It can call external web services, via REST or SOAP, invoke internal commands (implemented in Delphi and bound to the program, generic enough that you seldom need to change them), do some processing, and produce XML-documents, JavaScript (yes, we generate client-side code dynamically!), HTML pages, and PDF files.
In other words, when I look to other scripting languages, even popular ones, I see they tend to use a very traditional model, which in my opinion is not always the best choice. In our case (and in the case of other XML-based languages) there is a radical shift that can take a while to get used to, but you end up with a lot of power. At least this has been my experience.
Finally, what is the status of the project? Right now it is a proprietary language part of a rather complex XML-based architecture. I think we have three options. the first is to keep it for ourselves for our projects and those of our partners. The second is to create a lightweight version of our architecture, with Delphi plugins, and sell this engine, which will be easier to use than our current architecture. The third is to open source the language and keep the remaining portions of the architecture for us, as right now we cannot give away 5 years of work and a rather large investment.
That is, if there is any interest in this area and no one decides to buy our technology and take it to the market. In each case, I'll be happy to hear from you. And if you are curious and want to see a few examples I can post some snippets of our internal language tutorial.