[occi-wg] JSON Rendering

[Gary Mazz]

On 2/22/2012 9:52 AM, Feldhaus, Florian wrote:
> Hi Gary,
>
> Am 22.02.2012 um 16:54 schrieb Gary Mazz:
>
>> Hi
>>
>> What phases of the life cycle are these referring ?
>>
>> 1) To the provider's capabilities definition ?
> no, but in my opinion the entity rendering should be similar to the capability definition.
If they are different, any differences,  this needs to be clearly 
defined and differences clearly noted. It effects usability
>
>> 2) The consumer's request for service ?
> yes, in my opinion the rendering should have the same structure (e.g. "collection" or "entity" with an array of the elements, even if there is only one element in the array) for
> GET /
> GET /compute/
> GET /compute/123
>
> With Ralfs implementation, there is currently a difference between GET / or GET /compute/ and GET /compute/123 The latter one is only the rendering of the entity without it being embedded in an collection or entity array.
I agree with you on this topic, minimize any differences to ease 
implementations.
>
>> 3) The instantiation of a consumer's implementation ?
> It should be the same. Ralf already described it in 5.2.1 Client POST request. There is currently a collection array.
>
>> 4) The consumer's configuration at the service provider ?
> What do you mean with configuration?
At a provider, a consumer can upload an OVF file with a complex 
"configuration" of VMs. As a consumer, I can instantiate any number of 
VMs. I can also download my set of configured VMs in an OVF file with 
the associated disk images. The OVF is a definition file of the VM 
configurations.
>
>> 5) All of the above ?
> No.
>
>> I raise the questions based on the appropriateness of the parent object's term to use cases. We may want to consider naming the parent object in the examples so we can assess the approach in terms of use cases.
>>
>> My personal preference is to have a "Collection" with a name property.
> I don't like the idea of having a name property. The current way with having keys named "kind", "mixins" is fine for me.
We would have to use a mixin, I wanted to see what your thoughts were on 
the taxonomy (structure) of the JSON data. One issue we have never 
addresses is the intuitiveness of the data and the challenges faced by 
implementers accessing the data in the native forms.. If the data 
structures are convoluted and difficult to understand, it poses an 
barrier to widespread adoption.
>
>> How would this look with hierarchical or peered collections  ?
> I'm not sure about hierarchical collections. In general, we have the approach to show all entities below a given path, right? Thus GET /compute/florian/ would show a subset of the resources shown by GET /compute/
>
> I haven't head much discussion regarding hierarchies. Currently I don't see anyone using them. It might be handy to have a way of discovering hierarchies without retrieving all resources. Something like a directory listing. Any thoughts on this?
Ahh... Vmware's new administration products allows you to organize 
virtual machines in arbitary groups, a very desirable feature when 
assessing costs and risks.

>
>> cheers,
>> gary
>>
>> On 2/22/2012 8:16 AM, Feldhaus, Florian wrote:
>>> Hi all,
>>>
>>> I'm continuing with the work on the JSON rendering (I attached the latest version).
>>>
>>> I'm currently reviewing the rendering of entities. I was wondering, if we could use "Collection" for rendering single entities as well. On the other hand, we might as well drop the Collection completely and just use an array of entity renderings. I would prefer using the term entities, as the rendering is then similar to the rendering of the categories (with "kinds" and "mixing"). What do you think?
>>>
>>> e.g. instead of using
>>> { "collection":
>>>   [
>>>    { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } },
>>>    { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } }
>>>   ]
>>> }
>>>
>>> we could use either:
>>> { "entities":
>>>   [
>>>    { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } },
>>>    { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } }
>>>   ]
>>> }
>>>
>>> or just:
>>> [
>>>   { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } },
>>>   { "kind: { … }, "mixing": { … }, "actions": { … }, "attributes": { … } }
>>> ]
>>>
>>> Cheers,
>>> Florian
>>>
>>>
>>>
>>> -------------------------------------------------------------------------------
>>> GWDG - Gesellschaft für wissenschaftliche
>>> Datenverarbeitung mbH Göttingen
>>> Am Fassberg 11, 37077 Göttingen
>>>
>>> Fon: 0551 39-20364
>>> Fax: 0551 201-2150
>>> E-Mail: florian.feldhaus at gwdg.de
>>> WWW: www.gwdg.de
>>> -----------------------------------------------------------------------------------
>>> Geschäftsführer: Prof. Dr. Ramin Yahyapour
>>> Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger
>>> Sitz der Gesellschaft: Göttingen
>>> Registergericht: Göttingen
>>> Handelsregister-Nr. B 598
>>> -----------------------------------------------------------------------------------
>>>
>>>
>>>
>>> _______________________________________________
>>> occi-wg mailing list
>>>
>>> occi-wg at ogf.org
>>> https://www.ogf.org/mailman/listinfo/occi-wg
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/occi-wg