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