Look Ma, No Tags
by Kendall Grant Clark
July 24, 2002
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.
Related Reading
Python & XML
By Christopher A.Jones, Fred L.Drake, Jr.
Table of Contents
Index
Sample Chapter
Read Online--Safari
YAML?
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.
[1] [2] Next