Richard, I am and have pretty much always been for option (a) - one core format for interop with supporting formats for integration. More than half of our use cases are actually integration, which is to say that interop is the exception rather than the rule. This makes sense when you consider that every cloud deployment needs integration but far fewer will ever actually need/want to move. That being the case I think there is an extremely strong case for making multiple formats as easy to support as possible (enter XSLT). There's an option missing which has been pushed on the list: "(c) Exactly one wire format. Period." Tim Bray's in that camp which is enough for me to say that it should be represented, even though I don't necessarily agree with the logic. Sam On Wed, May 13, 2009 at 4:40 PM, Richard Davies < richard.davies@elastichosts.com> wrote:
If OCCI will specify a wire format, then:
Decision 2: Should OCCI-compliance require implementation of a single core wire format (any others are optional) or multiple core wire formats: a) Exactly one wire format is specified as core. A cloud must implement this alone to claim OCCI-compliance. Additional wire formats may be specified, but these are optional alternative renderings for easier integration with various external systems and cannot be relied upon for interoperability. b) Multiple wire formats as specified as core. A cloud must implement all of these to claim OCCI-compliance.
Perspective of myself and Alexis: OCCI should have a single core wire format, since this is sufficient to ensure interoperability between OCCI-compliant clouds and minimizes the burden of OCCI-compliance. Additional alternative wire formats may be specified where these will aid integration with different types of system, but these will not be required to claim OCCI-compliance. These alternative wire formats may take different views on decision 3 and 4 from the core (e.g GData XML, GData JSON, Plain JSON and Plain XML can all coexist as alternative wire formats carrying the same nouns, verbs and attributes). _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg