[occi-wg] Simple JSON rendering for OCCI

Tue May 12 08:21:57 CDT 2009

Andre,
Maybe we should bang heads together?

andy

-----Original Message-----
From: Alexis Richardson [mailto:alexis.richardson at gmail.com]
Sent: 12 May 2009 13:54
To: Andre Merzky
Cc: Edmonds, AndrewX; Roger Menday; occi-wg at ogf.org
Subject: Re: [occi-wg] Simple JSON rendering for OCCI

Andre, Andy,

If you guys think you can provide a formal equivalent of a canonical
interop rendering of the format, that might well be useful because it
would provide a means to specify and check conformance.

I still think there can be only one interop format - I think Chris put
it very well.

alexis

On Tue, May 12, 2009 at 1:41 PM, Andre Merzky <andre at merzky.net> wrote:
> 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.
>
-------------------------------------------------------------
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.