That is exactly right. Optionality has to be at the edges. On Tue, May 12, 2009 at 12:39 PM, Chris Webb <chris.webb@elastichosts.com> wrote:
Sam Johnston <samj@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. _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg