I could include multiple statements and allow returns like this: ["function", "byId", ["id"], [["return" ["call", "document", "getElementById", ["id"]]]]] (ba

I could include multiple statements and allow returns like this: ["function", "byId", ["id"], [["return" ["call", "document", "getElementById", ["id"]]]]] (basically lisp syntax substituting JS array notation.) My point is that JSON is capable of being terse, and XML is not. XML attributes are unordered, so you have to use child nodes, which have to be named. The best you could do is: <func><sig name="byId"><arg name="id"/></sig><body><return><call object="document" method="getElementById"><args><variable name="id"></args></call></return></body></func> Which is significantly longer than a positional JSON serialization. XML is also harder to implement a parser for, and existing libraries tend to be difficult to use (python etree and ruby's implementations are a much better direction). Now, someone else's raw XML is often easy to understand, whereas my array based JSON format would clearly require domain knowledge. Because of this, I prefer JSON for small network requests that are consumed by scripting languages. For larger, disk files, the overhead of XML is marginalized, and the extra formatting might help in hand editing and error correction. As for Greenspunning, I think its a perspective issue. The example was one of code serialization, so the lisp syntax is particularly well suited to the problem. Programmers also have the domain knowledge, so the less verbose format is still easy to understand.