[occi-wg] Simple JSON rendering for OCCI

[Roger Menday]

Hi Alexander,

> Actually, I still don't see a problem here.
>
> If we have an abstract rendering, which formally specifies the  
> semantics of the data, and normative renderings which formally  
> define the mapping to concrete formats (JSON, CSV, etc.), then it is  
> trivial to put a converter (say, XSLT in the XML case) between them  
> to map the data.
>

The approach taken by Exhibit to modeling [1] is interesting, and IMO,  
the noun-attribute-verb approach taken by OCCI so far, is about right  
(although yet to be convinced on the verb part).

So, identify the resources. Then for each resource there are simple  
properties and properties which link to other resources. That's the  
basis of the class model. Give every resource a HTTP URI. A rendering  
is always flat data structure, as it only ever describes the *current*  
resource. In key-value terms: the key is the name of the property and  
the value is either the string, float, etc, or a http uri to another  
resource. How this looks in json or xml too, is clear (?), and it is  
simple too, and could also be specified (?). However, we decide on  
only *1*. Key-value (i.e. www-form-urlencoded) is interesting as a  
rendering as its fits nicely with HTML forms.  ([2] is somehow  
relevant to the above.)

Roger

[1] http://simile.mit.edu/wiki/Exhibit/Understanding_Exhibit_Database
[2] http://www.tbray.org/ongoing/When/200x/2009/01/29/Name-Value-Pairs

> The same thing can be done for all other renderings as well,  
> provided that the semantics of the data and renderings are fixed.
>
> -Alexander
>
> Am 12.05.2009 um 15:31 schrieb Alexis Richardson:
>
>> On Tue, May 12, 2009 at 2:30 PM, Chris Webb <chris.webb at elastichosts.com 
>> > wrote:
>>> Alexis Richardson <alexis.richardson at gmail.com> writes:
>>>
>>>> I still think there can be only one interop format - I think  
>>>> Chris put
>>>> it very well.
>>>
>>> I didn't make quite that strong a statement! It's fine to have  
>>> multiple
>>> interop formats but you can't have *optional* interop formats.  
>>> Clients can't
>>> rely on anything optional: they have to use one of the compulsory  
>>> renderings
>>> if they want their code to be portable across cloud providers.
>>
>> Maybe we are talking about different things.
>>
>> I am talking about the format for the data exchanged between client  
>> and cloud.
>>
>>
>>
>>
>>> Cheers,
>>>
>>> Chris.
>>>
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/occi-wg
>
> -- 
> Alexander Papaspyrou
> alexander.papaspyrou at tu-dortmund.de
>
> <Alexander Papaspyrou.vcf>
>


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.