Look Ma, No Tags
XML combines all the inefficiency of text-based formats with most of the unreadability of binary formats. -- Oren Tirosh, comp.lang.python
Silence is the mark of XML's ultimate success. The less people talk about XML, the more and more easily they use it, and the more using it is unremarkable, the more it can be said to have won in the market place of ideas. Think of XML as one of the basic utilities of the Web, say, electricity. In the most industrialized nations, unless electrical service is interrupted, it's not common to talk about it a lot. It's used just about everywhere, by just about everyone: all with the literal, end-user ease of flipping a switch. And people rarely point to it as a distinguishing factor: it's not the deal-clincher in very many, if any new home sales, for example.
Ordinariness is just one way of judging XML's success; other ways include the number of novel applications it provokes or abets, the horizontal ubiquity of its adoption, the number of competitors it makes obsolete. By each of these measures, XML is very successful.
Yet XML has inspired as many competitors as it has made obsolete, maybe more. There have been simplified or "core" XML alternatives (SML, discussed in XML.com's "SML: Simplifying XML" 1999 article), alternative syntaxes for XML (like SOX and SLiP), and even new competitors, including a very interesting one, YAML, which appears to be growing rather than fading away.
YAML -- short for: YAML Ain't Markup Language; rhymes with "camel" -- popped up on my radar screen last week as a result of an interesting thread on comp.lang.python about the uses and abuses of XML, a conversation which I commend to your attention on its own merits.
In rummaging around for a plain, concise description of YAML, I kept stubbing my toe on a felt need to define it by referring to XML in some way. That was a mistake. YAML stands on its own very nicely, even if its most immediate point of contrast is XML. In other words, if there were no XML, there could still be a YAML, but it would have a different public face. If the XML world tends to get divided into data and documents, a distinction which is probably more pedagogically useful than it is necessarily true, YAML corresponds more to the data part of XML than to the document part. As the YAML specification puts it, "YAML is more closely targeted at messaging and native data structures" than at structured documents.
Accordingly, my plain, concise description of YAML is that it's a processing model and a wiki-markup-esque way to represent relatively arbitrary, high-level language data structures.
Easy to Read, Easy to Write
First, a word about "wiki-markup-esque": YAML's syntax is very lightweight, especially compared to XML's, and though the specification doesn't list wiki text as one of its influences, YAML visually evokes wiki markup. The specification explicitly credits RFC 822 for syntactical influence. One of the YAML designers, Clark Evans, said recently that "Ward Cunningham's WikiWiki is a very cool concept and I'm sure we borrowed from it sub-consciously". The important point is that YAML is lightweight. But what do I mean by lightweight?
Consider, for example, a data structure I've been using in a Python project -- an IRC bot which needs a configuration file full of bindings: that is, a collection which relates IRC events, methods or functions, and regular expressions. After being parsed, the configuration file is represented as a Python list of tuples. I can write this structure literally in Python as follows:
[ ("PRIVMSG", "newUri", "^http://.*"), ("PRIVMSG", "deleteUri", "^delete.*"), ("PRIVMSG", "randomUri", "^random.*") ]
Representing a list of tuples in this way in Python imposes a space overhead of about 34 characters: that is, I have to type 34 characters, to represent the structure, beyond the data itself. That's not too bad.
Pages: 1, 2