[occi-wg] Simple JSON rendering for OCCI

Tue May 12 07:54:17 CDT 2009

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