Listen Print Discuss
JSON on the Web, or: The Revenge of SML

JSON on the Web, or: The Revenge of SML

by Simon St. Laurent
July 05, 2006

Back when XML seemed all new and shiny, suggestions that it might in fact be too large, too complicated, or even slightly broken went over rather badly. The xml-dev list rang with battles over whether further simplifications were a good idea (since we'd just lost all that SGML capability), and whether a "Simple Markup Language" could even be useful. In the end, the controversy quieted. Then XML.com editor Edd Dumbill wrote at the end of a response piece that "doubtless the acid test for SML will be that of time." Six and a half years later, it may finally be time.

YAML Emerges from SML

The SML project faded into quiet for a while, producing Common XML (yes, I was one of the writers), a set of guidelines for using XML conservatively, while a group of SML folks found common ground with another effort, gave up on XML syntax, and produced YAML (YAML Ain't a Markup Language).

YAML files are pretty simple, using indentation (spaces only!) to identify containment, and using dashes, colons, brackets, and commas much like they are used in scripting languages. The full specification, including 23 pages of introduction and tutorial, is 85 pages long--longer than the XML it sought to replace, but incorporating much more information on processing and handling. They even offer a quick reference card.

Okay, so YAML came to fruition, even though it fell completely off the radar of the more XML-obsessed. Did it go anywhere?

Related Reading

XML Pocket Reference

XML Pocket Reference
By Simon St. Laurent, Michael Fitzgerald

There are a number of implementations for a variety of languages, and YAML seems to have penetrated into Ruby thought pretty well. There's a YAML Cookbook for Ruby. YAML is built into Ruby on Rails, is used for its configuration files, and drives developers to write cheerful blog posts with titles like "YAML Rules the Config File and Data Serialization Universe."

Even Simpler

YAML clearly isn't XML, but I'm not sure that it was quite what developers had in mind when they started out looking for Simple Markup Language. It supports a lot of structures beyond the basic, labeled nested-nodes approach described in the early SML presentations, and the 85 pages of the YAML spec includes a tremendous amount of data structure functionality.

Was there an uprising among disgruntled SML followers shocked by how large YAML had turned out to be?

No--there didn't need to be one. (There was a brief thread in 2002, but that seemed to work out happily.)

As it turned out, there was a similar effort going on simultaneously, with a similar but less ambitious set of goals: to represent JavaScript data structures. Actually, the goals were a little broader, as the result is used by many languages, but there was a common thread of belief that XML was way too much for what they wanted. It also had the advantage of building right on an existing programming language, JavaScript, and could easily describe itself as JavaScript Object Notation (JSON).

JSON still supports more than the single structure SML had offered--it has two basic data structures: name-value pairs, and lists. It also offers a few data types, from strings to chars to various types of numbers. They have a few examples to show how much lighter it is than XML. Look at the JSON carefully!

It's a subset of YAML, as it turns out. Well, not a perfect subset at first, but with the departure of JavaScript comments, it's very close. JSON can be a perfect subset of YAML, if colons and commas are followed by spaces. (The current Internet Draft states that "Insignificant white space is allowed before or after any of the six structural characters," but doesn't mandate it. There are also lots of toolkits for using JSON in a variety of languages, so it isn't limited to JavaScript or YAML environments.

(And if you'd like a perversely exciting possible combination of technologies, explore this call for "something like RELAX NG-Compact used as a validation schema language for YAML and JSON.")

Takeoff

Both YAML and JSON are finding happy homes with growing numbers of programmers. YAML's use in Ruby on Rails may well catapult it into broader use for configuration files, as the many developers exploring Rails take what they learn there to other projects.

JSON, on the other hand, is heading directly for the territory that XML had marked as its target ten years ago: the Web. While Ajax may mean Asynchronous JavaScript and XML, the XML part doesn't actually have to be XML. Anything that can serve as a neutral data transfer format between the client and the server will work.

Ajax applications have used XML, HTML, and plain text for that communication, but JSON is coming up fast. If a server sends JSON, converting that JSON into JavaScript objects is quick and painless, and the results are easier to navigate and process than XML. It has the advantage of speed, of escaping the "thou shalt communicate only with thy original server" rule (with a more formal proposal claiming better security), and good support in a number of toolkits. You can even (of course) convert back and forth between JSON and XML if you want to.

It's too soon to tell if JSON will overtake XML for the cases where it's most useful: data structures that don't need a tremendous amount of type information. I'm guessing XML will continue to be useful for documents, and that applications that want huge amounts of enforced structure will stick with the more sophisticated (and complicated) type structures offered by W3C XML schemas. Still, it's good to see XML getting some heavy competition after all of these years, and hopefully it'll reawaken some innovative thinking on the XML side. As Rick Jelliffe concluded in an early article on SML, "it is good to see some creativity and ingenuity at work. There is nothing wrong with that recipe."

Comment on this articleShare your experiences in our forums.
(* You must be a member of XML.com to use this feature.)
Comment on this Article

Titles Only Titles Only Newest First
  • Is JASON presentation (UI) neutral?
    2006-07-12 08:25:35 johnreynolds [Reply]

    Let me explain my concern a bit...


    I think it's very important to develop Web Services that are completely decoupled from a specific User Interface/View/Presentation Layer: A Web Service should be the (potential) basis for user interfaces constructed with any display technology (Swing, DHTML, etc.)


    My impression of JASON is that it usually transmits data that is embedded in DHTML layout. Is that correct?


    Thanks,


    -JohnR

    • Is JASON presentation (UI) neutral?
      2006-07-12 15:24:35 Simon St.Laurent [Reply]

      JSON itself is just data, without HTML. The usual way of processing it is for the JavaScript on a DHTML page to turn it into an object structure and then use that object structure to create some HTML, but there's no necessary connection to presentation.

  • Why JSON moves us forward
    2006-07-11 01:05:44 rjelliffe [Reply]

    JSON is useful because it stretches an existing format to reduce the syntactic and semantic gap between data and programs. Since SML did no attempt any of these, and since JSON did not come out SML, JSON is no more "the Revenge of SML" than it is "the Revenge of RTF." The revenge of IDL perhaps?


    Rick

    • Why JSON moves us away from XML - fortunately!
      2006-07-12 15:31:59 Simon St.Laurent [Reply]

      You seem to be splitting historical hairs to avoid a conclusion you never wanted to reach: that SML was a good idea, motivated by a mismatch between what programmers wanted to do with XML and what XML was offering.


      It's true that JSON isn't SML, and that YAML didn't feed directly into JSON. Nonetheless, YAML's emergence from SML and JSON's parallel development both seem to be recognition that maybe markup (ala SGML and XML) isn't the best way to share data between programs, and that other structures are often a better idea.


      I've long wanted programmers to work with something that fits their needs better than XML, as the efforts to make XML address data transfer have mostly created an incredible bloating. I had hopes for ASN.1 at various times, but JSON and YAML (for heavier-duty work) seem like the right answers to that set of problems in a way that XML, even XML augmented with zany Post-Schema-Validation-Infosets, can never be.

      • Why JSON moves us away from XML - fortunately!
        2006-07-24 19:19:59 rjelliffe [Reply]

        Sour grapes? Simon, don't make up bogus historical connections then complain if someone points that out! You titled your article "The Revenge of SML" as if JSON technically or historically has anything to do with SML.


        You are right that SML bifurcated into Common XML and YAML. But Common XML does not get rid of markup and so is nothing to do with JSON. And YAML, like JSON, has larger syntax and more object types than DTD-less XML: YAML (and JSON) ended up solving far different problems than were articulated for SML early.


        Indeed, that was the problem with SML wasn't it: aesthetic minimalists, interoperability fans, visual minimalists, low-power-device people and people who needed basic datatyping, got together under the banner of "simplicity" only to find that they actually needed other things: YAML for example is more complex than XML in its typing, and is not a markup language in the sense that non-SGML people think that a markup language means angle brackets.


        Why not say that JSON is revenge of SGML over XML, in the sense that it embodies a concern with terseness and desire for infix operators.

        • Why JSON moves us away from XML - fortunately!
          2006-07-24 20:21:00 Simon St.Laurent [Reply]

          I dunno, Rick - it seems to me that JSON proves that the SML people had a point in the first place, and that the YAML people who followed them had an even better point.


          I don't care much whether it's angle brackets or curly braces. I'm just happy that people who just want to ship data structures around have found a home more appropriate to them than XML ever really could be.


          (And with luck, JSON's success will lead more people to YAML, and eventually we'll have people working in toolsets that were actually designed for their tasks instead of repurposed from another field.)

  • Pay per view: XML vs. JSON
    2006-07-10 10:39:16 JSON [Reply]

    I think you nailed it: JSON is not about replacing XML it has it's own niche. Still, it would be nice to see more tool support: JSON native to Databases or JSonPath / JSLT transformations.
    ALOT of so-called Ajax toolkits do not use XML - they use JSON because it is JavaScript. The next round of browsers make make this moot by having XML as an true object using E4X.
    I think JSON is a great discovery by Douglas Crockford, but I put up http://JSON.Com up for anyone to use, but I have not had any takers so far.
    When do you think it will reach critical mass?