- 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.