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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

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


Subject: Re: [office-collab] Question on GCT (if I have the abbreviations correct)


Patrick,
I have answered your questions below, though let me know if this is not clear.
Robin

On 23/04/2012 14:14, Patrick Durusau wrote:
Greetings!

Going over the proposals in hopes of meeting later this week for discussions!

And have a question.

On item 14, page 5 of the original GCT document, it reads:

  1. Text and/or elements may be moved (deleted from one place and added elsewhere) to one or more other locations in a document. The change history of an element is not moved with the element. Content that has been moved from position A to position B can be moved again from B but it is deleted from A and so cannot be moved from A in a later operation.


OK, so if:

The change history of an element is not moved with the element.

Does that mean a new change history starts at the new location with a new history?
Yes

Except that some history shows the deletion of an element (is that the end of the history?)
That would be the end of the history in the original position, i.e. position A. The history of the data in position B would begin with the addition (linked to the deletion in A to indicate a move)

And some other history shows the insertion of an element (is that the start of a history?)
Yes, that is at B as noted above.

Where there is a move (delete/add), how do those two histories connect to each other?
The connection is via attribute pair delta:move-id and delta:move-idref, see section 6.10 p18 in the GCT proposal. Note that a piece of content could be moved to multiple places, i.e. cut followed by several paste operations, the format would allow this. Hence the need to keep the history with the original deleted item, otherwise it would be duplicated which would be very hard to manage.

Thanks!

Hope everyone is having a great day!

Patrick

PS: on #5: "Where a document has more than one CT, the order of the CTs must be defined."

Shouldn't we go ahead and require that all CT have a defined order?
I think the answer is yes! The order of all must be defined because it is guaranteed that undoing in the reverse order always yields a valid document (provided all changes are tracked.. it may be possible to get an invalid document if not).

If we do, what happens if we exchange documents and I made changes on top of yours. Should we time stamp them? Associate with particular authors? Or is that covered in the ordering? That is every document has one change order?
The GCT proposal is scoped to one document with one history, though multiple editors are allowed, so your scenario is fine. Time stamp of each edit is in the format, also the author, this is in the delta:change-info element. This would define the order.


-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
OASIS Technical Advisory Board (TAB) - member

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau 

-- 
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd  "Change control for XML"
T: +44 1684 592 144  E: robin.lafontaine@deltaxml.com      
http://www.deltaxml.com      
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK


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