[occi-wg] Voting result

Fri May 8 14:21:12 CDT 2009

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 at 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.
>
> http://www.ogf.org/pipermail/occi-wg/2009-May/000451.html
>

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 at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090508/3f4665ce/attachment.html 