Ok first let's degooglify this, especially now we know Microsoft are behind it as well:

On Wed, May 13, 2009 at 4:41 PM, Richard Davies <richard.davies@elastichosts.com> wrote:
Decision 3: For the core wire format(s), what meta-model should be adopted
in rendering the nouns, verbs and attributes (i.e. a framework/style within
which the nouns, verbs and attributes are rendered and any framework
services are added):
a) Minimal/no meta-model: Nouns, verbs and attributes are rendered as
  directly as possible over HTTP in a very basic REST style.
b) AtomPub meta-model: Nouns, verbs and attributes are rendered as Atom
  objects and carried according to Atom conventions with AtomPub services.
c) Other?

For a) you still need a meta-model, you may just end up writing one yourself.
 
Perspective of myself and Alexis: For the core wire format, OCCI should
minimize the meta model so that the specification of the core wire format is
as small as possible, and hence interoperability between OCCI-compliant
clouds is easiest to demonstrate, test and debug.

It's a leap of faith to claim the one which is "as small as possible" is also "easiest to demonstrate, test and debug" - this will rarely be the case (framing, error checking, documentation, etc. always adds [good] fat).

I agree though with the assertion that "the core wire format [should be] as small as possible", and would go so far as to say that even resources should be extensions (there's no reason people shouldn't be able to use OCCI for bare hypervisors or storage and network devices - an all-in-one protocol is sure to cause problems there). That is, the core protocol should provide a skeleton and nothing more... OCCI without resources would be like HTTP without the verbs where implementors would take only the ones they need (as is basically the case today), including ones they define themselves (like EH's IP addresses that I maintain are unnecessary).

A useful data point is that Microsoft started going down something like the POX (Plain Old XML) path with web3s and this is what they had to say about their about face adoption of AtomPub:

The fact is when we listened to the community of Web developers the feedback was overwhelmingly clear that people would prefer if we worked together with the community to make AtomPub work for the scenarios we felt it wasn’t suited for than Microsoft creating a competing proprietary protocol.

Here's what one innocent bystander had to say (better than I would have):

I’m confident this is for the best. In addition to Atom/APP being existing standards (with an accompanying abundance of existing tooling), Microsoft will also gain the evolutionary advantages of the hypermedia as the engine of application state constraint, which Web3S opted to replace with a schema-driven application model. Kudos to everybody involved in that decision.

The world doesn't need YAFP (yet another protocol) - it's got more than it can handle already - and even if it did I don't think this is the best group to define it (hello IETF)... besides we've got better/more important things to be doing than reinventing wheels.

As such I'd definitely go for (b) (almost) every time. If we had a small, static set of stuff to do (think Twitter) then I might go for (a), but we don't and we can't even hope to predict everything people will want/need to do (besides, Twitter supports Atom, JSON and POX for most operations).

Sam