Re: [office-collab] Merge-enabled Change Tracking (MCT) evaluation

[Svante Schubert <svante.schubert@gmail.com>]

On 14.02.2012 18:04, Robin LaFontaine wrote:

Following presentation by Svante today, participants in the call suggested the following activities:

1. Svante will update the presentation document because there appeared to be a number of errors in the examples and these need to be correct in order to be used as examples of how MCT works.

Another draft was just uploaded.

2. Svante will write up details of the path notation being used. This is not XPath/XPointer but is based on components in the ODF.

As drafted in slide 6 the ODF XML tree will be mapped to a ODF component tree, where characters are the smallest components.
After all root elements of components are identified the mapping from component paths to XPath to content.xml elements can be applied in praxis.

The ODF Component reference is a simplification of XPath. Each number refers to the sibling number of a component in a hierarchy. For example, "/1/2/3" refers to the first component in the document, its second child component and within the second child the third component.

Only Tables will have an additional path which reflects the cell references notations widely used.

3. Patrick, Tristan and Thorsten will work on some examples, using the six Use Cases that were selected for detailed examination of ECT and GCT. Svante will provide some further documentation giving details of the operations to be used for these, then Patrick, Tristan and Thorsten will encode the tracked changes in MCT. Svante will also produce a 'correct' example for each.

The basic idea is that the given operations (that will be serialized) would be specified. Not only the according XML change, which seems more some straight forward work, but more interesting as well general behavior, as if I split a paragraph, what are the properties of second new paragraph?

Like the creation of the list, was only selecting a sequence of paragraphs and every paragraph will become a list item (slide 12).
It does not matter if applications behave different, like the selection and deletion example (slide 13) shows. See notes for details.

The idea for collaboration/change-tracking is to avoid unnecessary sending/serializing of information, that could be agreed on. Like what is an empty text/spreadsheet/etc. document?What are the basic style sets someone could refer to, as "Heading 1". We might still define custom sets as "OOo 3.x, KOffice or MS Office 2010 flavor". The more we agree on defaults, the less we have to collab chit-chat over the wire and the more we have interoperability.

4. We will have a further call to discuss in 2-3 weeks time. Meanwhile the TC is looking at requirements so our work is in parallel.

5. The objective is to have sufficient understanding so that we can review Svante's changes to the consensus report and update this as necessary with the findings of the SC.

6. Any other technical questions to the mailing list over the next few weeks.

I would enjoy feed-back. The feed-back of the presentation really already helped a lot!

Thanks,
Svante

Robin
 

-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd  "Experts in information change"
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

--------------------------------------------------------------------- To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org For additional commands, e-mail: office-collab-help@lists.oasis-open.org