Rather than transforming across the actual formats, there seems to be
a interest in defining a model and then describe how to render onto
various data formats. So, rendering-down, rather then transforming-
across. (?)

These are both valid alternatives but given our ultimate aim is to reduce costs it makes [a lot] more sense to have a primary format which supports mechanical transforms than to externalise the development to implementors (and then expect the results to be interoperable).

The data formats discussion is a tricky one to resolve, as there's
things to like in each of JSON, ATOM and key-value. That said, the
"compliant, but non-interoperable implementations through supporting
multiple representations" is a strong argument for a single format.
Whatever that may be ...

How does one representation for integration (e.g. desktop clients, RightScale-style management services, live migrations, etc.) and multiples for convenience (e.g. web interfaces, cron jobs, failover scripts, reporting, etc.) not satisfy everybody's needs in a risk-free fashion?

Sam