All, I've just have a good phone conversation with Alexis, in which we agreed that the current formats discussion is actually addressing 4 independent questions simultaneously. I'd like to set these out individually, and get the group's opinion on each independent question individually rather than discussing them in combination as we have often done to date. Please can people follow up with their preference for each of decisions 1-4 independently. I would particularly appreciate the opinions of Randy and Tim as the other two cloud vendors involved in our mailing list, and of anyone else who may end up betting part of their business on OCCI. Cheers, Richard. =========================== Decision 1: Should OCCI specify wire format(s) or an abstract model: a) The OCCI API will be defined in terms of a specific rendering of the nouns, verbs and attributes to the actual bytes transferred on the wire. b) The OCCI API will be defined in terms of the abstract model (both nouns, verbs and attributes, and possibly also meta-model around these). Any implementation of this model is OCCI-compliant, regardless of the bytes on the wire. Perspective of myself and Alexis: OCCI should specify wire format(s), since this is the only way to guarantee in-practice interoperability between OCCI-compliant clouds. 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). Decision 3: For the core wire format(s), what meta-model should be adopted in rendering the nouns, verbs and attributes (i.e. a framework/style within which the nouns, verbs and attributes are rendered and any framework services are added): a) Minimal/no meta-model: Nouns, verbs and attributes are rendered as directly as possible over HTTP in a very basic REST style. b) GData meta-model: Nouns, verbs and attributes are rendered as GData objects and carried according to GData conventions with GData services. c) Other? Important*: This is an independent decision from decision 4 on syntax Perspective of myself and Alexis: For the core wire format, OCCI should minimize the meta model so that the specification of the core wire format is as small as possible, and hence interoperability between OCCI-compliant clouds is easiest to demonstrate, test and debug. Decision 4: For the core wire format(s), is XML or JSON the better syntax ('angle brackets vs. curly brackets') a) XML b) JSON Important*: This is an independent decision from decision 3 on meta-model Perspective of myself and Alexis: No strong view. We lean towards JSON, since it feels easier to make a tight specification and hence to easier to guarantee interoperability. Tightly specified use of XML might be equally good. * Decisions 3 and 4 are independent. Sam's GData XML http://www.ogf.org/pipermail/occi-wg/2009-May/000381.html is 3b with 4a. My Simple JSON http://www.ogf.org/pipermail/occi-wg/2009-May/000523.html is 3a with 4b. But equally it would be possible to specify GData JSON (3b, 4b) or Simple XML (3a, 4a).