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
> liton...@us.ibm.com
>
> "mar...@redhat.com" <mandr...@redhat.com> wrote on 11/03/2011 05:46:53 AM:
>
>> From: "mar...@redhat.com" <mandr...@redhat.com>
>> To: deltacloud-dev@incubator.apache.org
>> Cc: lut...@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, lut...@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
>>
