On Thu, 2011-11-03 at 11:46 +0200, mar...@redhat.com wrote:
> 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.
No, I don't think it would make much of a difference; with XmlSimple,
the current form without wrappers is actually more convenient. With or
without wrappers there will be a small difference between XML and JSON
handling for arrays.
The issue really isn't so much that there is this small difference
between JSON and XML, but that the rules for the JSON/XML correspondence
aren't spelled out. Sections 4.1.9 and 4.1.10 in the WIP talk a little
bit about that, but a slightly more formal (structural induction or so)
set of rules would definitely ease the mind of any implementor. BTW,
4.1.10 contradicts the examples later on, like the one on page 37 for a
MachineTemplate - 4.1.10 talks about a wrapper property, whereas the
examples don't have one.
In summary: no wrappers is perfectly fine, explicit rules, especially
ones that could be used for JSON <-> XML transformation would be useful.
> 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.
Yes, though it's not a big deal; XmlSimple behaves like that by default,
and even with XPath it would just be a matter of writing
xmldoc.("/machineTemplate/volume")
> > * 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.
I believe we need some sort of explicit schema/metadata anyway (and
schema here can really be sth defined in the Ruby code, doesn't have to
be XSD/RNG): when we start a Machine, we take in a MachineTemplate; that
means we need to create some sort of internal representation of a
Machine from scratch. In theory, that could be a hash, or 15 different
variables (@machine_name, @machine_disks, ...) that we pull together in
the output template.
For code sanity and testability though it's much preferrable to have a
class dedicated to representing a Machine, so that we can have some
simple validation logic there (are all mandatory attributes filled ? Do
the things that should be URI's look like URI's ? ...) so that we can
fail early instead of producing invalid output.
Yes, the fact that things need to be updated with the spec will lead to
major gymnastics, and might be an argument for keeping the metadata
external to the code (one set of text files for v1, one for v2), but I
think we should cross that bridge when we get to it. For now, expressing
the metadata with a DSL seems the simplest, and sufficient, solution.
> 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).
Luckily, for this, we only need to produce _an_ implementation of the
spec. How many optional features/extensions ours supports is up in the
air, and for now, we'll just focus on getting the smallest thing that
might possibly work together.
David
