[occi-wg] Simple JSON rendering for OCCI

[Chris Webb]

Sam Johnston <samj at samj.net> writes:

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

Something implicit here is worth highlighting: this route only leads to
interoperability if the extra formats are mandatory, not if they're
optional.

Otherwise, I can write an OCCI-compliant tool in bash which talks KEY VALUE
text, but it won't be able to connect to Richard's front-end (which only
understands JSON) or use another provider's front-end (which only
understands Atom).

The option of making one format mandatory and the others optional won't fly,
because in that case the only way you write code that's guaranteed to work
is to use the mandatory format, whereupon you've effectively converged on a
single rendering in all but name.

Cheers,

Chris.