incubator-deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tong Li <liton...@us.ibm.com>
Subject Re: Sketch of CIMI model layer
Date Thu, 03 Nov 2011 12:44:28 GMT
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
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message