Richard, Thanks for taking the time to gather the information and summarise it. On Fri, May 8, 2009 at 5:41 PM, Richard Davies < richard.davies@elastichosts.com> wrote:
The list has thankfully gone quiet, so I've recounted the votes since my previous post. We are now at:
10 JSON, 5 XML, 2 TXT
This isn't even a loose consensus, especially if you drop the "me too" votes lacking arguments and the curious pointer to the GoGrid API which supports<http://wiki.gogrid.com/wiki/index.php/API:Anatomy_of_a_GoGrid_API_Call#Output_Formats>all of JSON, XML *and* TXT. 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 <http://www.json.org/xml.html> 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. We all agree that anything but the most basic specification of compute, storage and network resources is out of scope, but we then give no option but to have clients talk multiple APIs developed by multiple SSO's (almost certainly with completely different formats and structures). Am I the only one who sees a complete and utter clusterf--k in the making (think WS-* redux JSON edition)? I don't consider this as a vote for a decision, but do think it has drawn
out a lot of opinions and shown the lay of the land more clearly - in the light of the votes, the only two viable options are:
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). It's worth mentioning that I well appreciate the advantages of JSON but this is about choosing the right tool for the job - XML may be a sledgehammer but everyone's got one and you can't drive a nail with a screwdriver. - Single-format: JSON
- Multi-format: JSON + XML + ?TXT
The list has also been fairly evenly split on whether multiple format support makes sense or not (independent of the choice of the single format).
The point is that there is significant support for multiple formats so multiple formats should be supported even if only as a convenience for disparate audiences (see Ben Black's comments on this topic). Trim the formats and you trim the audience and with it the potential for success. I definitely think we need to focus on one and give mechanical transforms as a convenience for the others though, which essentially addresses Ben's concerns about interoperability problems.
I see three conclusions going forward:
1) Continue our specification in terms of the model (nouns, verbs, attributes, semantics of these, how these are linked together) with both JSON and XML renderings of this being explored on the wiki. We can decide later if we run with both or just JSON.
There is no "later"... I need to have my presentation for Prague submitted and a coherent format to discuss with SNIA by Wednesday. That's not to say the model is perfect but it doesn't have to be for us to move on - the wrinkles will iron themselves out with people cutting code between OGF 26 (in under 3 weeks) and OGF 27 (in under 6 months). There is huge value in raising awareness/familiarity amongst potential users as early as possible (release early, release often and all that). I'll be promoting OCCI in London and Paris in the coming weeks too, provided I still believe it's going to work. There is still work here - e.g. verbs and attributes on networks have not
been specified, nor have we agreed fully the _model_ of how we link servers to storage and networks.
Thanks to Alexander Papaspyrou, Andy Edmonds: http://www.ogf.org/pipermail/occi-wg/2009-May/000461.html http://www.ogf.org/pipermail/occi-wg/2009-May/000444.html
The model is extremely simple - a compute resource can have zero or more network resources and zero or more storage resources. It gets hairy when you start considering that all three can be virtualised in which case there will be use cases which require going back to the physical devices, and that's why we need to support absolutely flexible linking between resources (something that Atom is particularly good at). 2) The JSON vs. XML debate is not just about angle-brackets vs.
curly-brackets.
I'm unconvinced that this has been demonstrated and still see it as 100% religion and bikeshed painting. Were we abusing XML then fair enough, but we're not - any simpler and it's plain text.
Amongst the XML supporters, I have seen little opposition to a GData/Atom meta-model around the nouns/verbs/attributes. [Tim Bray, who co-chaired the IETF Atom working group, felt it was the wrong choice, but then he doesn't support using XML at all in this context]
I'm less and less convinced that we're trying to solve the same problem here... the public cloud interfaces are extremely light (too light in places) but functional while the private cloud stuff is overkill. There is middle ground and we need to find it if hybrid clouds are to be a reality.
However, many(/all?) of the JSON supporters seem to want a lighter meta-model around the nouns/verbs/attributes. For instance, they would probably prefer fixed actuator URLs to passing these in the feed, and would likely transmit flatter hashes of noun attributes rather than following Atom conventions the structure of links, attributes, etc. within an object.
Thanks to Ben Black, Andy Edmonds: http://www.ogf.org/pipermail/occi-wg/2009-May/000395.html http://www.ogf.org/pipermail/occi-wg/2009-May/000420.html
My conclusion from this is that we should not develop the JSON rendering in terms of an XSLT transform from the XML rendering, and should not go for "GData-JSON". We will need these automatic transforms eventually, but we should develop the JSON rendering in its own right, thinking about what works well for JSON, and then later work out how we'll auto transform back and forth.
See above re "later".
Do the 10 JSON supporters agree with this, or have I misjudged it and there is actually strong support for GData-JSON?
By GData-JSON you of course mean a generic XML to JSON<http://www.bramstein.com/projects/xsltjson/>transformation which results in functional but ugly <http://code.google.com/apis/gdata/json.html> JSON. I'm unconvinced that a "pretty" protocol is a requirement provided it is still accessible/approachable - this works for Google so it will work for us, and it's trivial while your proposed alternative is very far from it. That said, work on Atom to JSON<http://www.ibm.com/developerworks/library/x-atom2json.html>has already been done and an " application/atom+json<http://www.intertwingly.net/blog/2007/01/15/application-atom-json>" RFC would be hugely beneficial for many audiences. I'd suggest JSON be a convenience primarly for web developers and that a generic XML to JSON transform be used while an Atom to JSON transform is developed (that's something I'd happily to contribute to separately).
Myself and Chris would be happy to lead developing the JSON rendering it its own right if people agree with my statements above and hence that it does need independent development (from the same set of nouns/verb/attributes and semantics).
That's all well and good but anyone can write a "rendering" - it's the "renderer" that's hard work. If you and Chris are volunteering to get us to the point we are already with XML, by Wednesday, then we've got something to talk about. The "ugly" JSON is just fine for developers and most importantly, it works with whatever resource you throw at it (be it a Gmail "contact" or a "compute" resource). There is enormous potential value in giving Google an short path to standardisation (for Google, their competitors and most importantly, cloud computing users). This will become increasingly important/apparent as people start to realise that infrastructure is boring "keeping the lights on" work and the true value is further up the stack.
3) I suggest we(/I!) stop discussing TXT for now. If we go multi-format then we should probably have it, but Chris has demonstrated how it can be trivially transformed back and forth from JSON.
I agree there's a valid use case for TXT (sysadmins, cron jobs, etc.) and I've demonstrated<http://www.w3.org/2005/08/online_xslt/xslt?xslfile=http%3A%2F%2Focci.googlecode.com%2Fsvn%2Ftrunk%2Fxml%2Focci-to-html.xsl&xmlfile=http%3A%2F%2Foccitest.appspot.com>that there's an extremely compelling argument for [X]HTML too. I can see both CSV and PDF transforms being useful for reporting as well. The point is that there are many different audiences to satisfy and we can trivially satisfy them all, quickly, if we stick with lightweight XML. Move to JSON and there's serious doubt as to whether we'll even be able to deliver on our charter (e.g. playing nice with others). Something you haven't covered in your summary is the strong consensus to keep the model and protocol separate. That's something that I for one would like to see more of going forward and I specifically don't want to see the model spilling over into the protocol if it will limit its potential application and complicate/specialise mechanical transformation. Sam Cheers,
Richard.
==========================================
JSON: 10 - Alexis Richardson http://www.ogf.org/pipermail/occi-wg/2009-May/000405.html - Andy Edmonds http://www.ogf.org/pipermail/occi-wg/2009-May/000420.html - Ben Black http://www.ogf.org/pipermail/occi-wg/2009-May/000395.html - Krishna Sankar http://www.ogf.org/pipermail/occi-wg/2009-May/000455.html - Mark Masterson http://www.ogf.org/pipermail/occi-wg/2009-May/000440.html - Michael Richardson (private mail to me) - Randy Bias? (JSON listed first at http://wiki.gogrid.com/wiki/index.php/API:Anatomy_of_a_GoGrid_API_Call) - Richard Davies http://www.ogf.org/pipermail/occi-wg/2009-May/000409.html(split EH vote) - Tino Vazquez? http://www.ogf.org/pipermail/occi-wg/2009-May/000411.html - Tim Bray http://www.ogf.org/pipermail/occi-wg/2009-May/000418.html
XML: 5 - Chuck W http://www.ogf.org/pipermail/occi-wg/2009-May/000448.html - Gary Mazz http://www.ogf.org/pipermail/occi-wg/2009-May/000470.html - Kristoffer Sheather http://www.ogf.org/pipermail/occi-wg/2009-May/000430.html - Sam Johnston http://www.ogf.org/pipermail/occi-wg/2009-May/000381.html - William Vambenepe http://www.ogf.org/pipermail/occi-wg/2009-May/000396.html
TXT: 2 - Andre Merzky http://www.ogf.org/pipermail/occi-wg/2009-May/000447.html - Chris Webb http://www.ogf.org/pipermail/occi-wg/2009-May/000409.html(split EH vote)
Single: 3 - Benjamin Black http://www.ogf.org/pipermail/occi-wg/2009-May/000457.html - Tim Bray http://www.ogf.org/pipermail/occi-wg/2009-May/000418.html - Richard Davies (revised in light of Tim Bray's comments)
Multi: 3 - Gary Mazz http://www.ogf.org/pipermail/occi-wg/2009-May/000458.html - Marc-Elian Begin http://www.ogf.org/pipermail/occi-wg/2009-May/000439.html - Sam Johnston http://www.ogf.org/pipermail/occi-wg/2009-May/000445.html _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg