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