atom feed7 messages in net.java.dev.jsr235.issues[Issue 11] Clarification: XML Change...
FromSent OnAttachments
kgoodsonFeb 7, 2008 3:18 am 
kgoodsonFeb 7, 2008 3:19 am 
kgoodsonMar 27, 2008 10:15 am 
radupApr 23, 2008 8:07 pm 
radupMay 16, 2008 3:17 pm 
radupMay 28, 2008 3:38 pm 
radupJun 4, 2008 5:03 pm 
Subject:[Issue 11] Clarification: XML Change Summary & Deleted Items
From:kgoodson (kgoo@dev.java.net)
Date:Feb 7, 2008 3:19:28 am
List:net.java.dev.jsr235.issues

https://jsr235.dev.java.net/issues/show_bug.cgi?id=11

------- Additional comments from kgoo@dev.java.net Thu Feb 7 11:19:51 +0000
2008 ------- Comment by 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". Comment by 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. Comment by 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.