[occi-wg] Voting result

[Tim Bray]

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

>