incubator-deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "marios@redhat.com" <mandr...@redhat.com>
Subject Re: Sketch of CIMI model layer
Date Thu, 03 Nov 2011 14:28:43 GMT
On 03/11/11 14:44, Tong Li wrote:
> Marios,
> 	In the spec,for xml, it is normally a list of singulars like
> <volume>...</volume><volume></volume>. For json, it will be "volumes":
> [something, somethingelse].
> I think that was what we discussed.  the spec does not have the notion like
> <volumes><volume/><volume/></volumes>
> 
yes that's right. I meant, if it will help us to bridge the difference
between the way json and xml are serialised for 'array' attributes (like
<volume>(s) ) then we can try and re-introduce wrappers for those
elements in the xml (i.e. raise an issue to change the spec itself),

marios

> Thanks.
> 
> Tong Li
> Emerging Technologies & Standards
> Building 501/B205
> litong01@us.ibm.com
> 
> "marios@redhat.com" <mandreou@redhat.com> wrote on 11/03/2011 05:46:53 AM:
> 
>> From: "marios@redhat.com" <mandreou@redhat.com>
>> To: deltacloud-dev@incubator.apache.org
>> Cc: lutter@redhat.com, Doug Davis/Raleigh/IBM@IBMUS
>> Date: 11/03/2011 05:47 AM
>> Subject: Re: Sketch of CIMI model layer
>>
>> On 03/11/11 01:08, lutter@redhat.com wrote:
>>> This patch is a first attempt at a CIMI model layer. Such a layer is
> needed
>>> to deal with deserialization (and possibly serialization) of CIMI model
>>> objects from (to) XML/JSON, and to give us a place to stash business
> logic
>>> connected to model classes.
>>>
>>> This patch is solely for discussion, it most definitely will not work;
> at a
>>> minimum there are various 'require' that are missing.
>>>
>>> There's two things that make such a model layer interesting:
>>>
>>>   * The need to deal with differences between the JSON and XML
>>>     representation; I believe they are all mechanical, though the CIMI
>>>     draft does not set out any explicit rules. The main rule is that an
>>>     array of things in JSON is represented as { 'things': [ ..
> array .. ] }
>>>     whereas the XML uses a sequence of <thing/> elements
>>
>> I recall discussion a while back about whether we need to include
>> wrappers for 'array' elements in the xml serialization... i.e.
>>
>> <volumes>
>>    <volume href="xs:anyURI"
>>           attachmentPoint="xs:string" protocol="xs:string" />
>>    <volume href="xs:anyURI"
>>           attachmentPoint="xs:string" protocol="xs:string" />
>> <volumes/>
>>
>> (not sure but may have been in relation to mantis #1195). I wonder
>> whether this needs to be revisited if it will help to bridge the
>> difference between json+xml 'arrays' and help with our deserialization.
>> The spec doees currently include 'cardinality characters' after items to
>> indicate:
>>
>> "?" (0 or 1)
>> "*" (0 or more)
>> "+" (1 or more)
>>
>> e.g. the xml serialization of the volume attribute for machine template:
>>
>>  <volume href="xs:anyURI"
>>           attachmentPoint="xs:string" protocol="xs:string" /> *
>>
>> but I don't think that's enough metadata to help us; it does tell us
>> that there may be more of this <thing> but we still need to search
>> through the xml doc to find all occurrences.
>>
>>
>>>   * see if we can really have a Base.to_xml; the two big issues to
> settle
>>>     are
>>>       (1) indicate which attributes go into XML attributes and which
> ones
>>>           go into elements, e.g.
>>>             ref :foo, :xml_attr => true
>>
>> we could in theory maintain the list of 'entities' though we would need
>> to maintain and update it with the spec... - machine, machine template,
>> volume, network, job, meter etc ... any <thing> that's not an entity is
>> by default an xml attribute. Having said that, the spec does include
>> extensibility mechanisms whereby cloud providers can extend the model by
>> defining new resource types, though these are advertised with
>> 'EntityMetadata' resource (but this last point is a recommendation only).
>>
>>>
>>>       (2) for attributes that are not scalars, do (1) recursively; in
>>>           particular, allow associating a class with the members of an
>>>           array
>>>
>>>             array :things, :class => Thing
>>>
>>>           where Thing itself is a subclass of Base
>>>
>>>   * some type specific validation (a 'ref' should look like a URI, we
> could
>>>     add types to 'scalar' and make sure integers look like integers
> etc.)
>>>
>>>   * a unit test or two
>>>
>>> Another sidenote: since the CIMI API isn't terribly HTML friendly
> (e.g.,
>>> POST's all have XML or JSON bodies), I wonder if the HTML frontend
>>> shouldn't be a JS app that communicates with the server via JSON only.
>>>
>>> David
>>


Mime
View raw message