OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [sdo] [SDO-93]: Clarification: XML Change Summary & Deleted Items



Ron Barack [19/Jan/07 04:45 PM] 
Hi Blaise,

In the chapter on Change-Summary XML serialization, the spec talks about
each "deleted" object being in the list of the delete attribute and
being deep-copied into the change-summary. From this it's clear, at
least to me, that the only the root of the deleted tree should be in the
list: otherwise there would be no need for the deep copy, and items
lower down in the containment tree would be repeatedly copied. Anyway,
this is the definition that makes sense, and is of course the one used
in our implementation.

But the wording in the spec need to be changed. In the chapter I mention
above, and in 3.3.5 Serialization and Deserialization. Anyone reading
would think contained objects are also "deleted" but the spec means
"root of a deleted tree".


Blaise Doughan [22/Jan/07 05:48 PM] 
We have been investigating delete and detach further and now believe
that an XPath is required for each deleted object (not just the root
deleted object).

Assumption:
Deleted and detached objects are represented in the same way in the XML
representation of Change Summary. 

Consider the following object model (The root object A holds a
ChangeSummary):
A->B->C->D->E

Now suppose that the DataObject D is detached, and then C is deleted.
What does the XML representation look like? Also how does the
representation differ if D was not detached but C was deleted.

Proposed Solution:
Represent all deleted objects with an XPath in the "delete" attribute,
not just the deleted roots. If there is not a corresponding XPath in the
"delete" attribute then the DataObject was detached.


Radu Preotiuc [24/Jan/07 03:58 AM] 
My understanding of the spec was that there was no difference between
delete and detach from the perspective of the containment tree. In SDO
2.1, the idea that ChangeSummary represents the difference between the
containment tree at the time logging was turned on and the final
containment tree is clear, and since detach has the same effect as
delete on the containment tree I think the change summary should look
the same.

Again, this is interpreting the 2.1 spec, in 3.0 of course this may be
radically different.


Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]