Inception-Style Nested Data Formats

Dan Harper had a great tweet this week where he discovered and then called out a new format from IBM called "JSONx."

"JSONx is an IBM standard format to represent JSON as XML"

Oh my. JSONx is a real thing. Why would one inflict this upon the world?

Well, if you have an existing hardware product that is totally optimized (like wire-speed) for processing XML, and JSON as a data format snuck up on you, the last thing your customers want to hear is that, um, JSON what? So rather than updating your appliance with native wire-speed JSON, I suppose you could just serialize your JSON as XML. Send some JSON to an endpoint, switch to XML really quick, then back to JSON. And there we are.

But still, yuck. Is THIS today's enterprise?

In 2003 I wrote a small Operating System/Virtual Machine in C#. This was for a class on operating systems and virtual CPUs. As a joke when I swapped out my memory to virtual memory pages on disk, I serialized the bytes with XML like this:

8

Hilarious, I thought. However, when I showed it to some folks they had no problem with it.

DTDD: Data Transformation Driven Development?

That's too close to Enterprise reality for my comfort. It's a good idea to hone your sense of Code Smell.

Mal Sharmon tweeted in response to the original IBM JSONx tweet and pointed out how bad this kind of Inception-like nested data shuttling can get, when one takes the semantics of a transport and envelope, ignores them, then creates their own meaning. He offers this nightmarish Gist.

--
Http Response Code: 200 OK
-- 







{"errorCode":"ItemExists","errorMessage":"EJPVJ9161E: Unable to add, edit or delete additional files for the media with the ID fc276024-918b-489d-9b51-33455ffb5ca3."}

Here we see an HTML document returned presumably is the result of an HTTP GET or POST. The response, as seen in headers, is an HTTP 200 OK.

Within this HTML document, is a META tag that says, no, in fact, nay nay, this is not a 200, it's really a 409. HTTP 409 means "conflict," and it usually means that in the context of a request. "Hey, I can't do this, it'll cause a conflict, try again, user."

Then, within the BODY OF THE HTML with a Body tag that includes a CSS class that itself includes some explicit semantic meaning, is some...wait for it....JSON. And, just for fun, the quotes are HTML entities. &quote;

What's in the JSON, you say?

{
    "errorCode": "ItemExists",
    "errorMessage": "EJPVJ9161E: Unable to add, edit or delete additional files for the media with the ID fc276024-918b-489d-9b51-ffff5ca3."
}

Error codes and error messages that include an unique error code that came from another XML document downstream. Oh yes.

But why?

Is there a reason to switch between two data formats? Sure, when you are fully aware of the reason, it's a good technical reason, and you do it with intention.

But if your system changes data formats a half-dozen times from the moment leaves it's authoritative source on its way to the user, you really have to ask yourself (a half-dozen times!) WHY ARE WE DOING THIS?

Are you converting between data formats because "but this is our preferred format?" Or, we had nowhere else to stick it!

Just because I can take a JSON document, HTML encode it, tunnel it with a SOAP envelope, BASE64 that into a Hidden HTML input, and and store it in a binary database column DOES NOT MEAN I SHOULD.

Sometimes there's whole teams who exist only as a data format transformation as they move data to the next team. 

Sound Off

What kinds of crazy "Data Format Inception" have you all seen at work? Share in the comments!

P.S. I can't find the owner of the BMW picture above, let me know so I can credit him or her and link back!