
On May 8, 2009, at 12:21 PM, Sam Johnston wrote:
I'm still far from convinced that JSON meets the minimum requirements to be in the running in the first place and nobody has addressed this point except to tell me to go back to square one and formally define them. Even the JSON junkies concede that while "XML documents can contain any imaginable data type", "JSON does not have a <[CDATA[]]> feature" so unless we want to contribute to the creation of a circus of cloud standards rather than provide the coherence of a loose framework on which to build, this point at the very least needs to be addressed.
What on earth does CDATA have to do with anything? JSON can carry arbitrary textual payloads without any extra effort. Oh, here's a dirty secret: both XML and JSON are lousy "wrapper" formats. If you have different kinds of things, you're usually better off letting them stand alone and link back and forth; that hypertext thing. I have not been to the mat with the OCCI use cases so I'm not going to argue that they contain things that can't be done in JSON. We didn't find any in our use-cases, but that may not be relevant here. The disconnect here that's fascinating, looking in from outside, is between the people who feel that having multiple message formats is a problem and those who feel it's essential.
Definitely, the arguments have been enlightening but there are still some big knowledge gaps. Mechanical transformations are another point that the JSON crowd have been totally silent about, likely because there is no solution that doesn't involve delving into the details of programming (something which is strictly out of bounds).
One of the reasons that us single-data-format people feel that way is that it moves the transformation problem out of scope. Less work is good. I guarantee that the in-memory object model of our cloud infrastructure app doesn't look anything like either XML, or the JSON in the Sun REST API, or any other conceivable protocol format. An implementor is going to have to transform between protocol and application semantics anyhow; I just don't want to have to do it more than once. -T