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

[Boris Kolpackov]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: Digital signature
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060514/44b57a5b/attachment.pgp