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

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

Well, I planned to implement this feature for a while. Now that there
is someone needing this functionality I might as well do it. Will let
you know when I have something to try. BTW, are you already using ACE
in your project?



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

Hm, I don't know about this. The idea of the query language I had is
that it is a light-weight mechanism with minimal or no support in the
generated code. What you are talking about is some sort of a non-
trivial, schema-guided document merge facility with a lot of questions
that I don't have good answers to, e.g.:

1. How do we distinguish parts that need to be replaced/updated compared
   to those that need to be added. I guess ID/key/keyref mechanisms
   can be used here but it could be too restrictive a requirement.

2. When some parts are inserted, in which order does it happen wrt
   existing parts?

3. For the remove operation, all one needs are IDs of parts to be
   removed. Creating (valid) documents with fake data seems like
   an overkill to me.

I underhand you want to handle such merges generically without knowing
which individual parts need to be updated. I, however, don't see
a clear picture of how this can be done yet. Maybe we should think
about a mechanism that would allow generic navigation/modification
of the tree (higher-level than DOM but lower-lever than static typing).


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

Ok, that sounds great.

-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/20060516/7ce7d5d4/attachment.pgp