converted to 1.6 markup
|No differences found!|
Change Summary Serialization
The 2.1 specification adds a fair amount of detail on the format of serialization of change summaries.
Currently XMLHelper.save() delegates the work of serialization to the EMF XMI code. Now that the SDO 2.1 spec says things about compliant serialization were going to have to move away from that, at least for the change summary itself.
The (de)serialization we are concerned with here is that provided by the XMLHelper.save() and load() operations. Scope does not include object serialization
There's a lot of stuff that the EMF code currently does for us, but its a bit back boxish; so how much replacement of non change summary stuff are we going to have to do, and what scope is there for specialization that permits us to override the serialization behaviour that is key to this feature.
Performance is important custom serialization or make use of SAX/StAX or the like? Does the generated code offere any scope for customizeed behaviour or is there just one implem for ch sumaaries embedded in dynamic or static SDOs?
could be ChSumImpl itself (toXMLString()?)
could be a visitor (elegant but perhaps a bit slow?)
Should we use canonicalized XML in order to compare the execution results with expectations, if so, what tools can we use for this.