I was looking at wikipedia - Category:XML-based programming languages.

Why would someone take this approach for designing a language?
What are the advantages of it?

I can only think of disadvantages.

  • hard to maintain
  • hard to read
  • hard to write
  • 2
    One typically has some other program (visual interface or such) that a non-programmer uses to do something, that is then stored as XML and processed as XML.
    – user40980
    Commented Oct 3, 2013 at 20:11
  • 2
    I agree with your drawbacks. Use Coldfusion and the arguments you make against it are abundantly clear.
    – Rig
    Commented Oct 3, 2013 at 20:27
  • @Rig: Although Coldfusion isn't actually in that list that OP links to. Commented Oct 3, 2013 at 20:33
  • I suppose a possible advantage would be that such a system could use XQuery and XPath queries and expressions to make writing self-modifying code easier. Whether or not self-modifying code that functions via XPath/XQuery is actually a good thing can be debated... Commented Oct 3, 2013 at 20:45
  • 1
    @Mhd.Tahawi: If your program code is written as valid XML, your program could use XPath/XQuery to perform reflection on itself. Used with XSLT, it might be possible to design an XML-based programming language that uses XSLT to write programs that can modify themselves. I'm not sure I'd want to have to deal with such a program but it might be cool from a novelty point-of-view. Commented Oct 7, 2013 at 13:41

6 Answers 6


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

  • 3
    "Seem" is the keyword here. Truth is, those advantages are either pretty small or non-existing, but it certainly seems like that when you've never created a language implementation. Parsing is computationally expensive but actually one of the simpler parts to implement (parser generators or hand-written) and design (syntax is cheap). And once you have the AST, how you proceed is not influenced by how you parse - meaning if execution is simple, it remains simple if you choose different syntax (obviously, only if you keep the semantics).
    – user7043
    Commented Oct 4, 2013 at 14:19
  • @delnan Exactly. The only thing XML seems to give you for free is the easy part. I say "seems" because it's not actually giving you anything it's either just pushing it off onto the user or some sort of (probably complicated) custom GUI.
    – Evicatos
    Commented Oct 4, 2013 at 17:12

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.

  • 1
    Conflating code with data is not an advantage; it's a security hole at the language level. The classic example is SQL injection: every time some site gets hacked and millions of dollars worth of damage is done and tens of thousands of users have to order new credit cards due to a SQL injection exploit, the fundamental reason is because some developer somewhere set up a query in some way that did not properly segregate data from code. Throwing around fancy words like "homoiconicity" does not change this fundamental fact. Commented Oct 3, 2013 at 21:54
  • 5
    @MasonWheeler I do not disagree at all that proper escaping is neccessary from a security perspective for every templating system, but this doesn't have anything to do with the question, my answer, or data-code separation. I do not freak out about those rwx scripts I have, which are data for my editor, but executable code for my shell.
    – amon
    Commented Oct 3, 2013 at 22:07
  • 1
    The fact that you try to respond to this in terms of escaping in the first place--which is and always has been the wrong way to prevent SQL injection--and not in terms of separation of code from data via Parameters--which is the only correct way to do it--shows that you really don't understand the problem. And that's why SQL injection attacks keep happening: people keep not understanding why these things are important and how to do them right. Commented Oct 3, 2013 at 22:55
  • 7
    @MasonWheeler: your critics of "conflating code with data" is correct when getting data from external sources and creating code from that (which is, by the way, in no way special for XML). But this answer has a complete different focus, it is about the metaprogramming aspect.
    – Doc Brown
    Commented Oct 4, 2013 at 6:15
  • 6
    @MasonWheeler, injection is executing data that should not execute. Homoiconicity means code and data are much alike, in literal form and in programmatic manipulation. A homoiconic languages may securely manipulate and execute (code generated from) trusted data, be it hard-coded in your source code or otherwise. In e.g. Common Lisp, you can include data in generated code without it being executed, such as (eval `(foo (quote ,data))). Your argument about parameters vs. escaping may be right, but you missed the point.
    – acelent
    Commented Oct 4, 2013 at 9:15

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.

  • 2
    No, the questions asks why XSLT should be XML itself. The toolchain you have described could have been implemented just as well with a Perl or Python script that parses the output XML, and generates some output from that. The interesting design decision about XSLT is not that it can transform XML, but rather that it doesn't use curly braces⸮
    – amon
    Commented Oct 3, 2013 at 21:30
  • or semi-colons? I see what you are saying. any language could really parse that information out of the XML Document, so the question would be "why would they need an XML Transformation language", right?
    – Malachi
    Commented Oct 3, 2013 at 21:48
  • No, an XML transformation language makes sense (if you're doing a lot of XML transformation). There are plenty of things XSLT does to support XML processing (such as the ability to easily traverse and query the DOM tree), but being XML itself is not among those things.
    – user7043
    Commented Oct 4, 2013 at 14:26
  • I was trying to clarify the question with my last comment @delnan I understand and agree that XSLT is a Nice tool to have.
    – Malachi
    Commented Oct 4, 2013 at 14:53

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.