[occi-wg] Format: 4 distinct decisions

[Richard Davies]

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