Sam, Painting this as a mere difference between angle brackets or curly braces trivializes or avoids the central problem: the very tools you cite as advantages of XML are, in my opinion, merely symptoms of the complexity inherent in using XML, especially in the so-called "enterprise environment". The question of maturity seems to be entirely about those same tools, rather than about any concerns about JSON being a moving target (it isn't). Sun has provided a compelling example of how to use JSON in the construction of a simple, RESTful cloud interface, yet all your arguments against it are nebulous. What _specific_ thing is it you believe meets these criteria: 1) Is a concrete requirement of the core interface 2) Is possible with XML (without dragging in the very baggage that has sunk so many other "enterprise" protocols based on it) 3) Is not possible with JSON I am not talking nice-to-haves, here. I mean real, protocol can't function without it stuff, because if the core protocol _can_ function without a feature, why on earth would you put it in? I recommend the following exercise: divide the features into "definitely need right now", "might need at some point", "definitely won't need". Discard all but the first category in creating the core protocol, compare the result to the Sun API, smile with recognition, adopt it as the base, move on. Ben On Wed, May 6, 2009 at 4:42 PM, Sam Johnston <samj@samj.net> wrote:
Morning all,
So I've been on the road for the last half a dozen hours watching somewhat of a debate has kick off as to whether we should continue to use angle brackets (XML) to dice our data or start from scratch with curly braces (JSON). Sure it's understandable given the previous mess<http://stage.vambenepe.com/archives/700>(whereby literally dozens of different "standards" were born only to end up dead and dying) but that's essentially what it boils down to and it does feel a lot like we've taken a trip back to 2006<http://www.oreillynet.com/xml/blog/2006/12/and_the_winner_of_the_json_vs.html>. As one person pointed out in private it's clear there is now a good deal of backlash against "XML/SOAP/complexity" - apparently enough to consider wiping the slate clean of many years of hard (albeit thus far largely futile) work.
I'm not particularly religious about the matter either way (my only vested interest is in the time I've volunteered to date and what little I have left in which to deliver results) but I do think the model is *far* more important and worthy of detailed discussion than the protocol. I've seen neither XML nor Atom impinge on anything we've needed to codify so far and once you have to reach for a library (as you do in both cases) the machines could talk pig latin to each other for all we care. The primary (and only valid IMO) objection to XML is that it tends to be abused more often than not, but zero examples of such abuse in our designs have been given and we've agreed to limit ourselves to an essentially flat structure (that must be able to be cleanly represented in alternative formats including JSON and TXT) so this is a non-issue anyway.
Looking at the practicalities, XML is very mature with plenty of expertise and tools (from editors to application accelerators/firewalls) available for it while JSON is a rapidly developing new kid on the block (or is at least perceived to be by enterprise users - and perception/marketing is half of the battle). There are a lot of things we can do today with XML that we can't [and may never be able to] do with JSON such as transparently embedding supporting formats like OVF (which like it or not is going to have its time in the sun), transforming it to whatever format(s) we like in a mechanical, platform independent fashion and serialising, encrypting and signing it (for storage, queueing, etc).
Atom itself is already arguably the single most successful "cloud" standard with Google using it for pretty much every public facing interface (protocol buffers are used under the covers for efficiency) and every feed on the web is using it (or something like it). There is a good deal of overlap with whatever domain specific language we might have invented ourselves (I know because I tried this before [re]discovering Atom) and it is a better fit than you might first think - feel free to go through the exercise if you need to see for yourself. In terms of the future it's also far more extensible in that adding new resources et al to a domain specific language would almost certainly require us to reconvene to create OCCI 2.0, while extensions can be safely implemented (and validated) without risk to the rest of the spec; this is not something I see as being particularly well handled with JSON now or any time soon. Furthermore, things we currently take for granted behind the scenes with XML (like being able to pass around a DOM object and have different components update it as necessary before handing the result to a renderer) are not possible unless you happen to be writing JavaScript (one of the only languages where JSON is a first class citizen rather than a third party extension).
Given the current plan is to support multiple formats (even if we only actually require one of them) while maintaining the ability to move losslessly between them, there is nothing stopping us from shifting our weight to the other foot if and when JSON matures. The web never mandated the use of a single format so I don't see why we should start now (though telling implementors they must support all of them is a tall order). In terms of reaching a loose consensus I think the EH/GG guys will be satisfied if we can get clean[er] transforms, Sun ought to be happy if we follow their methodologies if not their exact protocol (e.g. single entry point, "buttons" for state changes, etc.), Google may well get on board if we make it easy for them and I'll be satisfied if I don't have to throw away a substantial base of work already completed as well as the opportunity to use the myriad existing XML/Atom/GData tools and clients (remembering a domain specific language starts with exactly zero implementations).
Of course if someone *does* have a particularly strong fetish for curly braces and cares to rewrite the spec as well as a reference implementation and a bunch of transforms by next week then be my guest.
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg