JSONx is an IBM standard format to represent JSON as XML

[namecast]

From the department-of-redundancy-department....

The output syntax is even more glorious than you'd think:

<?xml version="1.0" encoding="UTF-8"?> <json:object xsi:schemaLocation="http://www.datapower.com/schemas/json jsonx.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:json="http://www.ibm.com/xmlns/prod/2009/jsonx"> <json:string name="name">John Smith</json:string> <json:object name="address"> <json:string name="streetAddress">21 2nd Street</json:string> <json:string name="city">New York</json:string> <json:string name="state">NY</json:string> <json:number name="postalCode">10021</json:number> </json:object> <json:array name="phoneNumbers"> <json:string>212 555-1111</json:string> <json:string>212 555-2222</json:string> </json:array> <json:null name="additionalInfo" /> <json:boolean name="remote">false</json:boolean> <json:number name="height">62.4</json:number> <json:string name="ficoScore"> > 640</json:string> </json:object>

...and no, I'm not joking, and don't call me Shirley.

[donpdonp]

The xml namespace descriptors are bulky. The rest looks efficient, for xml, and almost readable with some indentation.

  <?xml version="1.0" encoding="UTF-8"?>
  <json:object xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
               xmlns:json="http://www.ibm.com/xmlns/prod/2009/jsonx"
               xsi:schemaLocation="http://www.datapower.com/schemas/json jsonx.xsd">
    <json:string name="name">John Smith</json:string>
    <json:object name="address">
      <json:string name="streetAddress">21 2nd Street</json:string>
      <json:string name="city">New York</json:string>
      <json:string name="state">NY</json:string>
      <json:number name="postalCode">10021</json:number>
    </json:object>
    <json:array name="phoneNumbers">
      <json:string>212 555-1111</json:string>
      <json:string>212 555-2222</json:string>
    </json:array>
    <json:null name="additionalInfo"/>
    <json:boolean name="remote">false</json:boolean>
    <json:number name="height">62.4</json:number>
    <json:string name="ficoScore"> &gt; 640</json:string>
  </json:object>

translated (by hand) into JSON gives

  {
    "name": "John Smith",
    "address": { "streetAddress": "21 2nd Street",
                 "city": "New York",
                 "state": "NY",
                 "postalCode": 10021
               },
    "phoneNumbers": ["212 555-1111", "212 555-2222"],
    "additionalInfo": null,
    "remote": false,
    "height": 62.4,
    "ficoScore": " > 640"
  }

[duaneb]

I don't think JSONx is built for readability, so that actually seems like a very reasonable way to convert to XML.

[xienze]

It would look a lot more reasonable if they had set the root namespace instead of leaving it separate and requiring every element to be prefixed.

[pbreit]

Not sure what you mean, the result looks fairly restrained to me.

[tiles]

I'm surprised it doesn't use any of RDF's ordering attributes for arrays and objects.

[sp332]

But what if the original JSON had a string that looks like XML? Does {"endTag": "</json:string>"} become <json:string> </json:string> </json:string> ?

[rasz_pl]

well, IBM does sell storage solutions.

[dyoo1979]

Wait, this can't be right for purely technical reasons: what would this to do a string containing vertical tab characters?

Such strings are illegal in XML. I see nothing in the "JSONx Conversion Rules" that addresses the problem that the strings representable in XML are a smaller set than those in JSON.

[edit] Yup, confirmed. The documentation says: "The \b (backspace) and the \f (form feed) characters are not supported in XML and, subsequently, are not supported in JSONx." So not only does this JSON->XML thing seem obtuse, but it's partial.

I wrote a rant about this point a few days ago. Seems more well timed than I had hoped. https://plus.google.com/117593568781545916065/posts/ViNzo5Jj...

[dragonwriter]

> So not only does this JSON->XML thing seem obtuse, but it's partial.

If it wasn't partial, it would be useful -- allowing existing XML tools to easily consume and/or produce JSON tools by applying a JSON -> XML on input and/or XML -> JSON on output would be valuable.

But when the conversion is restricted to an XML-1.0-compatible-subset of JSON, the value drops considerably.

[laydros]

I worked on the Datapower team soon after IBM acquired the product. Its a very cool device.

But I read the headline and threw up in my mouth a little.

[edwingustafson]

Most likely they developed this format to store JSON in DB2 or to manipulate JSON with existing XML-based tools.

[the_mitsuhiko]

That's exactly what this is: http://www.ibm.com/developerworks/library/x-db2JSONpt1/

[thrush]

This is SO SO important. I've had to convert JSON to XML and vice versa so many times in order to transfer data to and from legacy code components. No, I don't think an ideal world involves any sort of communication where one side speaks JSON and the other speaks XML, but the current world very much needs a standardization like this.

[dragonwriter]

Insofar as the world needs a JSON->XML conversion standard, it needs one that handles all legal JSON, which this doesn't (it could if it used the same approach to target XML 1.1 instead of XML 1.0, or it could if it used a slightly more complex representation of JSON strings in the XML 1.0, but instead it chose to be a conversion for a restricted XML-1.0-friendly subset of JSON.)

[lovelearning]

They missed a golden chance to name it "Enterprise JSON".

[peterwwillis]

What, is this supposed to be funny? You try converting completely different formats into one another without a standard, and see the kinds of fucked up bug reports you get.

[valarauca1]

WebSphere! Experience everything wrong with Enterprise Software Development for the simple price of $100,000 per seat, per core, per year :D

[JonnieCache]

Oh good, you can convert it back to JSON with an XSLT.

[drivingmenuts]

I just had a flashback.

XSLT really is the seventh circle of Hell.

[powdahound]

Reminds me of the "JSON Encodings for XMPP" specification. :) http://xmpp.org/extensions/xep-0295.html

[Norm--]

And now the next trick I will perform is turning XML into JSON

[OhhHeyTyler]

https://gist.github.com/DavidJFelix/e5f16d4d1f8760bc3b39

buddy of mine made JSHOL on a whim which creates html from json

[DonHopkins]

Does it support EBCDICTF8 (Extended Binary Coded Decimal Interchange Code Transformation Format Eight) for encoding Unicode as 8 bit EBCDIC?

[kra34]

but where can you buy their complicator gloves?

[CamperBob2]

You get a free pair with every turboencabulator purchase.

[marcofiset]

Wait.... what ?

[angersock]

Well, they did get a license from Crockford to use JSON for evil, so mission accomplished I guess?

[neilellis]

They killed a 1000 unicorns to make this you know.

I can hear the screams in my sleep.

[kevinSuttle]

How recent is the introduction of this format interchange?

[easytiger]

April Fools?

[dapatil]

Why?

[kttmrt]

Why?

[mrweasel]

Same reason as SOAP/WSDL: there's good money in consulting so it would be stupid to do something that to simple, people might be able to solve their own problems.

Honestly I get that there an advantage in respect to tooling and this might ease integration into existing system, but I can't help feel that this is introducing an extra level of complexity that you would only find acceptable if you at IBM customer level scale.

The ability to introduce at least some type safety seems nice though.

[danbruc]

Because there are already tool chains to handle XML with features not (widely) available for JSON, for example validation (XSD) and transformation (XSLT).

[dragonwriter]

To use existing XML 1.0 tools on data that comes in as JSON.

It may be somewhat problematic that it doesn't actually support all JSON, because the characters that are permitted (even with escapes) in XML 1.0 text do not include all characters that can appear in JSON values, so if you use it on legal JSON that isn't constrained to be XML 1.0 compatible, it will do something wrong (the docs aren't clear on whether it will fail or just drop the offending characters), so the only place that it seems safe to use is in a constrained internal environment where you control "JSON" to mean "JSON using XML-1.0-safe characters".

[Scuds]

ENTERPRISE READY!