one of the biggest advantages of an XML based language is that it looks easy to implement

no really, there are a ton of validating parsers available which will diagnose the syntax related compile errors and give you the AST for free

the execution is also simply iterating over said AST and keeping a map of the functions and variables

Code Is Data.

Or rather, programs are data. A source file is just a specific serialization of this program. This idea is e.g. common in homoiconic languages like Lisp. Such a language tears down the barriers between the program code, and the data it is operating on. This can be extremely powerful and expressive, although I would not call the appearance of Lisp code “beautiful” or “easy to read”.

XML is the structured data serialization format to the current-day enterprise programmer. There are large toolchains established around XML processing.

• Defining a language meant to operate on XML in XML can be interesting because of this Homoiconicity. An example is XSLT. In theory, this allows metaprogramming, but no sane person would do this, right?
• Templating languages are interested in having little seperation between data and code. Using an XML document as a template/program is interesting when the output is XML or HTML.
• Storing code of a general purpose language in XML can still be interesting. Storing an Abstract Syntax Tree serialized to XML instead of source code is viable when this code is manipulated via an IDE, where it is presented in a more human-readable form, e.g. for visual programming. This is not unlike Smalltalk environments, where the “source code” is just a representation of the actual bytecode image.

Interestingly, XML documents are sometimes used for templating code … *shudder* (dependency injection). I ascribe this to the ubiquity of XML in some toolchains / the mindshare XML has as a go-to structured data format.

I’ll concentrate on XSLT rather than XML-based languages in general.

There’s a history here, of course. XSLT was conceived as a successor to DSSSL, the styling language for SGML, and tried to get right what DSSSL had got wrong. One of the major problems with DSSSL was perceived as being its (Scheme-like) syntax, and there was a widespread feeling that the solution lay in using the same syntax for the stylesheet and the data; after all, the idea was that a stylesheet should consist largely of structured data rather than program logic, and much of that data would consist of proforma (“template”) data for adding to the result tree, with some parameterization.

XSLT is often perceived as being excessively verbose. For XSLT 1.0, which many people are unfortunately still using, that’s probably true, but the problem was largely solved with XSLT 2.0, which is often a lot more concise that other ways of solving the same problem.

There are certainly drawbacks. You’re pretty well obliged to use a purpose-designed editor (but then, most programmers use syntax-directed editors for every language, don’t they?). The language isn’t quite as composable as it might be (though again, XSLT 2.0 largely fixes that). But there are also significant advantages:

1. XSLT is widely used by non-programmers, and for them it’s very much a plus that they only have to learn one syntax, not two. Remember, it’s all the little details like how to handle character encoding and escaping of special characters.

2. The ability to process XSLT code using XSLT is a lot more useful than you might imagine. Nearly all big XSLT projects take advantage of this capability, and it can bring very big benefits. For example, I saw one online banking system that had a couple of hundred forms in its UI, each generated by its own stylesheet, but the stylesheets were generated from a common library of code giving great reuse and consistency of look and feel.

3. There’s a benefit that I wouldn’t have expected, which is that the use of a constrained syntactic framework like XML forces the language designers to maintain a level of lexical consistency as the language evolves and at the same time provides great extensibility. The XQuery WG is always debating how to extend the language without breaking compatibility or introducing quirks; XSLT has no such problems, because it’s basically a question of defining new elements and attributes.

I could see something like that being handy in an XML-heavy environment (think XSLT), where you presumably already have decent XML editors and it might be useful to be able to generate code using the same toolset. It also might make it easier to write correctness verifiers or other tools to ensure that the code follows certain standards or rules (e.g., a schema defines where the business logic has to go, and/or ensures that all variables are initialized in a consistent fashion).

XSLT is the only XML Programming language that I have used, I haven’t had the chance/opportunity to get into the others.

we have one main Application that shoots out one XML file to a Database, and several other Applications can take that file and apply an XSLT file to it to extract the data that those other applications need, this alleviates the need for exporting a new set of Data for each new application that comes along. I think that is a major plus. you only have to code one XSLT file for the new application to decode the information that is already being produced rather than having to produce new information for a new application.

I realize that I haven’t touched on any of the other languages that you have listed, but I have given you an idea of a good place for the use of such a language. still not sure if I completely answered or even partially answered your question. but hopefully I have given some insight.

XML makes almost no sense absent historical and political context. SGML was even harder to write, read, and maintain, but it had the ISO stamp of approval put on it in 1986 which made it perhaps the first data declaration language to have such an imprimatur.

It was sufficiently useful and documented to inspire Tim Berners-Lee to use it as the foundation of HTML in the early 1990s. Remember, he was intending to create a world wide web and basing it on an extant ISO standard would help further that considerably.

Then in the late 1990s with the web quite well entrenched, the World Wide Web Consortium started an initiative for standard structural markup for data interchange. The hype-factor surrounding XML reached unprecedented levels of “we’re not sure what to do with this, but I bet it’ll be really cool”.

As it stands, what XML is mostly good for is structured data interchange between disparate systems. As amon has noted, there are some specific domains where it has broader utility. I’m just glad that it is now possible to encode graffiti in a standardized markup so that in the future, kids won’t have to risk life and prosecution but instead do their tagging with paint-wielding remotely-controlled drones.