[occi-wg] Simple JSON rendering for OCCI

[Andre Merzky]

Quoting [Alexis Richardson] (May 12 2009):
> 
> Andy
> 
> It's not completely obvious to me how people can interoperate on just
> a model, nor how normative renderings can be plural.

That is indeed difficult to define, IMHO.  My (biased)
example is the SAGA spec in OGF (Simple API for Grid
Applications): the API specification is language neutral,
but several renderings for Java, C++, Python etc exist, and
will be normative in their own right (spec documents are
WIP).

The abstract specification includes a number of syntactic
and (more so) semantic guidelines which MUST be  followed by
the renderings, to maintain common nouns, verbs and
attributes (no surprise, he?).  But language specific
deviations are allowed, were sensible (error handling,
booststrapping, etc).

Interopn can indeed only effectively defined for the
individual renderings.  We believe, however, that
implementations of different renderings are assumed
interoperable, if the respective test suites result in the
same backend operations.

For SAGA, that is difficult to prove - the API is too large
for that.  For OCCI, with its limites set of
nouns/verbs/attribs, that may very well be possible.

FWIW, other APIs in OGF went a similar route, most notably
DRMAA.  Their original spec is in C, but after several
renderings emerged for Java, Python, etc, a language neutral
spec (IDL) was created to derive these bindings from.
Interop again is defined via test suites.

Note: a different to OCCI is that neithe SAGA nor DRMAA talk
about protocols, but *only* about client side APIs, rendered
in higher level programming languages.  

My $0.02,

  Andre.


> alexis
> 
> 
> On Tue, May 12, 2009 at 11:53 AM, Edmonds, AndrewX
> <andrewx.edmonds at intel.com> wrote:
> > I'd (again) agree with this and would re-iterate Alexander's (Papaspyrou) earlier point on approach and process:
> >
> > "The canonical way to cope with this issue [formats] (which, by the way, has proved right many times in the past) in many WGs within OGF is to separate this step not only in design, but also in specification: have an abstract "modeling" part in the spec which clearly defines the semantics the data, and one or more normative renderings for the abstract model."
> >
> > It would also seem to me that although we have the noun-verb-attribute reasoning it might need to be expressed in an easier form to communicate, say graphically.
> >
> > Andy
> >
> > -----Original Message-----
> > From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] On Behalf Of Roger Menday
> > Sent: 12 May 2009 11:43
> > To: Richard Davies
> > Cc: occi-wg at ogf.org
> > Subject: Re: [occi-wg] Simple JSON rendering for OCCI
> >
> >
> >
> > On 12 May 2009, at 11:20, Richard Davies wrote:
> >
> >>> Therein lies the problem - there are no "standard tools" nor any
> >>> way to
> >>> specify a cross-platform mechanical transform for JSON (at least
> >>> not yet).
> >>
> >> Yes, I agree with you there - if we're going with multiple formats
> >> it'll be
> >> easier to define XML -> JSON than JSON -> XML.
> >
> > Hi Richard,
> >
> > Rather than transforming across the actual formats, there seems to be
> > a interest in defining a model and then describe how to render onto
> > various data formats. So, rendering-down, rather then transforming-
> > across. (?)
> >
> > The data formats discussion is a tricky one to resolve, as there's
> > things to like in each of JSON, ATOM and key-value. That said, the
> > "compliant, but non-interoperable implementations through supporting
> > multiple representations" is a strong argument for a single format.
> > Whatever that may be ...
> >
> > regards
> > Roger
> >
> >>
> >> Richard.
> >> _______________________________________________
> >> occi-wg mailing list
> >> occi-wg at ogf.org
> >> http://www.ogf.org/mailman/listinfo/occi-wg
> >
> >
> > Roger Menday (PhD)
> > <roger.menday at uk.fujitsu.com>
> >
> > Senior Researcher, Fujitsu Laboratories of Europe Limited
> > Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE, U.K.
> > Tel: +44 (0) 208 606 4534
> >
> >
> > ______________________________________________________________________
> >
> >  Fujitsu Laboratories of Europe Limited
> >  Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
> >  Registered No. 4153469
> >
> >  This e-mail and any attachments are for the sole use of addressee(s) and
> >  may contain information which is privileged and confidential. Unauthorised
> >  use or copying for disclosure is strictly prohibited. The fact that this
> >  e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield does
> >  not guarantee that it has not been intercepted or amended nor that it is
> >  virus-free.
> > _______________________________________________
> > occi-wg mailing list
> > occi-wg at ogf.org
> > http://www.ogf.org/mailman/listinfo/occi-wg
> > -------------------------------------------------------------
> > Intel Ireland Limited (Branch)
> > Collinstown Industrial Park, Leixlip, County Kildare, Ireland
> > Registered Number: E902934
> >
> > This e-mail and any attachments may contain confidential material for
> > the sole use of the intended recipient(s). Any review or distribution
> > by others is strictly prohibited. If you are not the intended
> > recipient, please contact the sender and delete all copies.
> > _______________________________________________
> > occi-wg mailing list
> > occi-wg at ogf.org
> > http://www.ogf.org/mailman/listinfo/occi-wg
> >
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg



-- 
Nothing is ever easy.