Welcome Guest | My Membership | Login

Expanding Your Toolkit: JSON vs. XML


Article

Back in the stone age — the early 1980's — SGML was created to express document structure, so that complex documents could be electronically shared and rendered by cooperating government agencies and companies. "This part of the content is the title," "this part is a figure," "this is a legend under a figure," and so on.

Still in the stone age — in the 1990's — HTML arose to express less complex documents in a web-browser context. At the dawn of the modern era — the late 1990's — XML was created with the intent of finding a middle ground between the two. One that was both human-readable (plain text with Unicode support) and machine readable (sufficiently structured to be efficiently and unambiguously parsed). It was intended to be a practical compromise between completeness and simplicity.

Like it's parents, XML was conceived as a means of expressing a document . However, it was understood and desired that it could be used to express non-document data as well. XML's elegance comes from not having a rigidly fixed lexicon. It's all well and good to say <title> is a tile, and <p> is a paragraph, but how cool is it to say that <something> is a something? Without having to define an unworkably large universe of possibilities in advance and then deal with missing features, and force-fit messes they cause us to create, we can suddenly talk about <inventoryControlNumber> and <favoriteIceCream> just as easily as anything universally pre-defined.

If the call-a-thing-a-thing philosophy reminds you of JSON, it's not an accident. JSON was designed to be XML-light. We get to decide what terminology best suits the task at hand in JSON because that was one of the aspects that was kept from XML. This of course begs the question: So why do we need both XML and JSON? Good question.

The JSON and XML snippets in [Figure 1] convey the same core payload.

JSON:

{
    "employees": [
        {
            "firstName" : "Albert",
            "lastName"  : "Einstein"         },
        {
            "firstName" : "Albert",
            "lastName"  : "Schweitzer"
        }
    ]
}

XML:

<employees>
    <employee>
        <firstName>Albert</firstName>
        <lastName>Einstein</lastName>
    </employee>
    <employee>
        <firstName>Albert</firstName>
        <lastName>Schweitzer</lastName>
    </employee>
</employees>

You can see that JSON is a bit more compact without being any more obscure, so that looks like a win. In situations represented by the above example, it is. A huge set of real-life use cases are well served by JSON. It's terrific. No surprise that it is the data packaging system most in use on the web today. You might easily spend your entire career not needing anything more.

But.

For binary values — like images, sound, and video — JSON requires a to-string encoding and from-string decoding. Although easy enough to pull off for an occasional bit of multimedia content, when you have to scale this, it can add up to being expensive computationally, bloated, and there are transmission resources required.

XML can handle binary data expressed as text (just like JSON), or referred to by URL or other external access methods (just like JSON). But it can also manage your multimedia content as an embedded/in-line/raw/un-expanded binary data by employing a CDATA tag. Also, there is something called Xpath, which traverses the more complex trees common to XML for you, so you can find things like "/book/published/year/text()" without having to write any custom code. And, XML supports name space segregation, metadata (attributes), and externally or internally defined schema to describe how a payload is to be understood. Hmm. Getting interesting for more complex data scenarios, isn't it?

Oh, and you can XSL to filter and transform one XML "document" into another one more suited to a particular task.

And...

You must get the picture. Applications moving binary data or complex data hierarchies are usually better served by XML. When those requirements are not present, JSON is likely the better pick, due to its compactness, simplicity, familiarity, and widespread use by many of the web services you may interact with.

This brief article cannot provide a primer on XML. For those not familiar with it, I merely hope to have alerted you the fact that JSON has a more powerful ally able to do the heavy lifting that lies beyond JSON's reach. When your work calls for custom packaging of binary and or deeply hierarchical data, a solution leveraging XML will most likely be better than either JSON or a completely proprietary mechanism.

 

# # #          # # #          # # #

 

Related Articles

  • From the Inside July/August 2017

    We're already planning for the next Spectrum conference. If you haven't yet seen the information for the 2018 Spectrum, it will be April 23rd-26th at The Henderson in Destin, Florida. This is a new venue for the conference.

  • MultiValue Database and Framework Benchmarking

    Benchmarking has been a topic that's been around for several years, but nothing really has been provided to the MultiValue Community to use. I've heard many different reasons for the lack of benchmarking, so I'll go through a few of them.

  • The Six Million Dollar Open

    Company: International Spectrum

    The term extensible means that a language or format can be tweaked, adjusted, or expanded by the users. It can go beyond what the original designers had in mind. MvBASIC is extensible. The open command is an excellent candidate for an extensible makeover.

  • Expanding Your Toolkit: What is JSON?

    Moving data in and out of MultiValue requires us to understand all of the different ways that we may need to transform the inbound and outbound information. Bennett offers us a practical guide to JSON (JavaScript Object Notation).

  • JSON For Your MultiValue Web Site

    Company: Brian Leach Consulting, ltd Database: UniVerse

    Due to the nested nature of our MultiValue data, many developers are now familiar with XML and use it in their applications. However, there is another standard data-interchange format that provides the same nesting and associating abilities that makes the data readily available to other languages. Lighter weight and preferred by many Ajax developers, JavaScript Object Notation can become another valuable tool for use in your MultiValue-based web applications.


Return to top