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"
  }

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

yeah, the point isn't so much to make it readable, but to allow you to write JSON (as a python dev I love the interoperability with JSON) and then use the capabilities of the DataPower to do stuff with it.

I expect many people were doing this by hand since JSON has replaced XML in a lot of peoples minds, and IBM has created a way to standardize it to make it easier to work with other teams.

That doesn't make this mess any saner, if the point was to apply XML tools to JSON, why not convert to an existing XML dialect with equivalent expressive power, e.g. XMLRPC's serialisation format (which provides a strict superset of JSON capabilities (if you include the nil extension))?

The obvious problem being that you might not have control over the source of the data. JSONx means you can apply xml tools to json sources, period.

I'm not sure what you're trying to say. The source of the data is irrelevant, XMLRPC w/ nil (and other pre-existing formats I'm sure) are strict supersets of JSON, any JSON document can be converted back and forth between XMLRPC and JSON without data loss. So XMLRPC (or something else with similar capabilities) would give you exactly the same ability to apply XML tools to "JSON sources".

I've never understood the reasoning behind using a textual serialization format that's not human readable.

If you don't want it to be readable, make the darn thing binary and go for efficiency.

There's a difference between prioritizing readability and simply being readable.

Please explain the trade off, I can't see myself debugging an unindented XML file without an appropriate reader. Exactly like a binary file.

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.

Yep. The rest of it is, well, xml, and it's not going to be as clean looking as json , but why do I need to see the word json at the start and stop of every element? It could at least be abbreviated to just 'j'?

On the plus side I bet the output gzip's up rather nicely in transit assuming you're HTTP GET'ting this data....

Replace `xmlns:json="http://...` with `xmlns:j="http://...`.

Actually, just remove the colon and the prefix entirely. It becomes surprisingly readable:

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

> On the plus side I bet the output gzip's up rather nicely in transit assuming you're HTTP GET'ting this data....

The XML is 901 bytes, gzip yields 401 (44.5%)

Of course the original JSON is 303 bytes and JSON is already pretty compressible, to 215 bytes (71%) in this case.

> but why do I need to see the word json at the start and stop of every element?

Because of what I just mentioned. If they had set the root namespace directly you wouldn't have to declare the namespace prefix on every element.

I don't know why you were downvoted. Setting the root namespace provides exactly the effect of dropping "json:" from everything.

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

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

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

Of course not, it's either embedded in a CDATA section or the characters are escaped to the relevant entities: http://www.w3.org/TR/xml/#syntax

> The ampersand character (&) and the left angle bracket (<) must not appear in their literal form, except when used as markup delimiters, or within a comment, a processing instruction, or a CDATA section. If they are needed elsewhere, they must be escaped using either numeric character references or the strings " &amp; " and " &lt; " respectively. The right angle bracket (>) may be represented using the string " &gt; ", and must, for compatibility, be escaped using either " &gt; " or a character reference when it appears in the string " ]]> " in content, when that string is not marking the end of a CDATA section.

They'd probably escape out the angle brackets with entities. Sorry, Bobby Tables.

Probably, well hopefully, sure. But I want to know whether they did, and whether the technique is fragile.

I don't really understand why you are being down voted for a technical question. It seems like answering it without giving a downvote as a snarky "ISN'T IT OBVIOUS?" would be sufficient.

well, IBM does sell storage solutions.