[xsd-users] Partial update of in-memory structures & network transfer.

[Moss, David R (SELEX Comms) (UK Christchurch)]

Boris,

> That would be:
> 
> car_t car = ...
> ACE_OuputCDR ocdr;
> 
> ocdr << car;
> 
> // One can extract binary representation of car from ocdr now.
> 
> ACE_InputCDR icdr (ocdr);
> car_t car_copy (icdr);
> 
> Is this something that would be useful to you? I could probably
implement
> this in a couple of days if you are interested.

This definitely sounds like something we could try out if it's not
diverting you from your planned development :-)


> Again, the system needs to know that wheels are identified by id's:
> 
> update<wheel_t> u (wheel_t::pressure, where (eq (wheel_t::id));
> u.run (masterCar.chassis ().wheels (), pressureChange.chassis
().wheels
> ());

This also sounds very useful. The key thing is to keep the mechanism
generic - if some xml fragment has been streamed into an ACE_OuputCDR
object (for example), all that is known is that the root is car_t so how
best to discover that an update of wheel_t is required? Obviously we can
send an replace / insert / remove tag with the fragment to decide on the
required xsd operation but we don't really want to have to know about
the structure beneath the root to perform that operation. Ideally:

car_t masterCar ...;	// main data
car_t carPart ...;	// from network / some other source.

replace< car_t > r;			// could also be insert or
remove.
r.run( masterCar, carPart );

then if the schema changed beneath the root, no code change would be
required. If the schema enforced that wheels have a unique id would that
help?

We need to think a bit more about the details at this end but would
certainly be willing to work with you on prototypes etc. 

Cheers,
Dave.

Dave Moss
SELEX Communications
Grange Road
Christchurch 
Dorset  BH23 4JE
United Kingdom
Tel: + 44 (0) 1202 404841
Email: david.r.moss at selex-comm.com


> -----Original Message-----
> From: Boris Kolpackov [mailto:boris at codesynthesis.com]
> Sent: 14 May 2006 09:46
> To: Moss, David R (SELEX Comms) (UK Christchurch)
> Cc: xsd-users at codesynthesis.com
> Subject: Re: [xsd-users] Partial update of in-memory structures &
network
> transfer.
> 
> Hi David,
> 
> Moss, David R (SELEX Comms) (UK Christchurch) <david.r.moss at selex-
> comm.com> writes:
> 
> > ...
> >
> > there could be a point at runtime where the in-memory model contains
the
> > following data:
> >
> > <car>
> >    <engine>
> >       <oil>5</oil>
> >    </engine>
> >
> >    <chassis>
> >       <wheel id="1">
> >          <tyre>1</tyre>
> >          <pressure>1</pressure>
> >          <rim>1</rim>
> >       </wheel>
> >       <wheel id="2">
> >          <tyre>2</tyre>
> >          <pressure>2</pressure>
> >          <rim>2</rim>
> >       </wheel>
> >       <exhaust>5</exhaust>
> >    </chassis>
> > </car>
> >
> >
> > ...
> >
> > <car>
> >    <chassis>
> >       <wheel id="3">
> >          <tyre>3</tyre>
> >          <pressure>3</pressure>
> >          <rim>3</rim>
> >       </wheel>
> >    </chassis>
> > </car>
> >
> >
> >
> > The first issue here is how to stream data to and from xsd objects -
is
> > your planned work to allow serialisation to (and from?!) compact
binary
> > formats for over-the-wire transfer something that would be able to
> > address this?
> 
> Yes, that's exactly the type of a situation serialization to/from a
> compact
> representation is supposed to address. The idea so far is to
(optionally)
> generate serialization operators (to) and c-tors (from). Also they
will
> be operator and c-tor templates in order to accommodate any stream
type
> you want to use:
> 
> 
> class car_t
> {
>   template <typename S>
>   car_t (S& is);
> };
> 
> temlate <typename S>
> S&
> operator<< (S& os, car_t const&);
> 
> 
> Then one will only need to wrap their stream type to expose interface
> compatible with those expected by the generated templates. I was also
> planning to provide a sample implementation for the ACE CDR streams.
> 
> 
> > It would be nice if something like this could be done:
> >
> > // Get the data from the network
> > BYTE* pCarFragment =...
> >
> > // Put the fragment into an xsd object - the main car object knows
where
> > // a wheel lives.
> > //
> > car_t car;
> > pCarFragment >> car;
> >
> 
> That would be:
> 
> car_t car = ...
> ACE_OuputCDR ocdr;
> 
> ocdr << car;
> 
> // One can extract binary representation of car from ocdr now.
> 
> ACE_InputCDR icdr (ocdr);
> 
> car_t car_copy (icdr);
> 
> 
> Is this something that would be useful to you? I could probably
implement
> this in a couple of days if you are interested.
> 
> 
> > Next, given that it will be possible to do something like that, it
would
> > be possible to build / update some master data record from separate
> > sources:
> 
> I think what you are suggesting is some sort of a query language. The
> simplified version that you describes below has a few problems,
biggest
> of which is that you assume that "the system" somehow knows which
> parts are new and which ones need to be updated, removed, etc (i.e.,
> it knows, for example, that wheels are identified by the id
attribute).
> One will need to provide such information explicitly:
> 
> car_t car = ...
> car_t fragment = ...
> 
> update<wheel_t> u (where (eq (wheel_t::id));
> u.run (car.chassis ().wheels (), fragment.chassis ().wheels ());
> 
> 
> > A mechanism to allow data to be removed or updated would also be
> > required:
> >
> > Change the tyre pressure:
> > <car>
> >    <chassis>
> >       <wheel id="2">
> >          <pressure>99</pressure>
> >       </wheel>
> >    </chassis>
> > </car>
> >
> > car_t pressureChange = ...
> >
> > car_t masterCar = ...
> >
> > masterCar.Update( pressureChange );
> 
> Again, the system needs to know that wheels are identified by id's:
> 
> update<wheel_t> u (wheel_t::pressure, where (eq (wheel_t::id));
> u.run (masterCar.chassis ().wheels (), pressureChange.chassis
().wheels
> ());
> 
> 
> > When the in-memory validation is available it would also be possible
to
> > do
> >
> > bool isValid = masterCar.valid();
> >
> > to check that the overall content was correct against the schema (I
seem
> > to remember reading something to this effect on this forum!).
> 
> Right, that the plan so far.
> 
> 
> > I realise this is quite a philosophical email and there probably
aren't
> > any solid answers ( other than "what?!"  :-) ), but it's something
to
> > think about...
> 
> Yes, I've been thinking about the query language for a while now. This
> is, however, quite a big chunk of work and will require a lot more
> thinking than what I sketched above. Also, there seem to be a lot of
> overlap with the standard algorithms so we need to think carefully to
> make sure we don't reinvent the wheel here.
> 
> In other words, if there is somebody who really needs it and is
prepared
> to go through the process of working out details, trying prototypes,
etc,
> we can go ahead and start working on this.
> 
> hth,
> -boris