On Tue, May 12, 2009 at 12:43 PM, Roger Menday <roger.menday@uk.fujitsu.com>wrote:
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