[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: [ODFPlugfest] change tracking
From:       Pierre Stirnweiss <pstirnweiss () googlemail ! com>
Date:       2009-11-25 23:24:25
Message-ID: 200911260024.26298.pierre.stirnweiss_gen () gadz ! org
[Download RAW message or body]

Hi Bart, Hi Patrick,

I am the main author of the change tracking (as of yet preliminary) support 
for KOffice. Our new release sees our first installment of change tracking in 
KOffice.

Since I haven't got much time to elaborate this week, I'll give you a rough 
brain dump of what I encountered and some of the puzzlement I have regarding 
ODF change tracking. I should have more time to elaborate a bit more next week 
if you have questions or remarks. I'll also try to post my remarks on the link 
Patrick provided.

I will start by how to handle nested/overlapping change regions.
It is not clear first if nested regions are allowed at all (even if logic 
would tell they should). Then the treatment of overlapping regions is not 
described: can a change region (let's say formatting) overlap two different 
(let's say insert) regions (or one insert region and the base documents), or 
should all nested regions be fully contained in the parent region (in which 
case, an overlapping region would be split in two). This can have an impact on 
the implementation, specially with regard to accept/reject changes: when one 
of the "parent" change is rejected, should the whole child change be also 
rejected, or just the portion corresponding to that parent. If the later, 
should the remaining part of the child change be a "new" change (with new time 
stamp and eventually new author) or keep the old metadata even if it is not 
anymore the original recorded change.

On the same subject of nested changes. How to treat a change done by user B in 
the middle of changes done by user A. For example, user A inserts a paragraph. 
Then, user B modify the formatting of a word of that paragraph. Here it seems 
clear that the change from user B is a child of the change from user A: if the 
insert change of user A is rejected, the format change of user B will be gone 
with it. But should this rule also apply if user B also inserts a sentence, 
let's say at the beginning of the paragraph user A inserted?

A further unclarity I have is the uniqueness of a change region. According to 
the spec, the "tracked-changes/change-region" is uniquely identified by its 
change-id. However, what is exactly meant by a "tracked-change/change-region". 
Is it merely one timestamp/author/type? or is it relating to a unique 
continuous region of the text. This is relevant in the following scenario for 
example: user A insert a sentence in the doc. This creates one continuous 
region of the type insert change. Then user B insert a word in the middle of 
this sentence. What becomes the insert change of user A: two regions referring 
to the same tracked-change id, but separated? or do they become two distinct 
tracked-changes?

For paragraphs: should the document be saved as <change-start><p> or as 
<p><change-start>. Both actually are different things, yielding "a priori" a 
different behaviour if the change is rejected (in one case the line feed 
should be removed, not in the other). But then how to treat the first 
paragraph of the document.

How do we handle lists? can the whole <text:list> be inside a <change-
start><change-end>? is it at list item level? within the <text:p> of each 
item? is a list an insert change or a format change if I have a couple of 
words (in the original document) i turn into a list? how to handle rejecting 
of the change?

same with tables. I haven't really looked into this. but how do we capture 
that the user inserted a row, or merged two cells,...

We have not yet fully implemented complicated deleted change (with several 
<text:p>,..., but the whole process of removing the leading <text:p> and 
trailing </text:p> in some cases but not other, or the case of a heading 
("adapt the end tags to match their new counterpart") seems very artificial 
and unnatural to me. As a mechanical engineer I always tried to keep in mind 
the motto of one of my design teacher: "if the mechanism does not look sleek, 
it won't work properly". Well in that case, it does not look sleek. I am not 
sure how to make this simpler however.

What is the correct level of granularity of a change? on insertion of a long 
piece of text with several paragraphs, should we have one insert region or one 
per paragraph? when doing several formatting of the same piece of text, should 
we record one formatting or several? If I insert a text and then delete it, 
should we save the changes at all?

Formatting change. it is not foreseen to keep the information of what 
formatting change happened, merely the fact that a formatting was applied. 
This make rejecting this change impossible. Is it desirable to save a 
reference to the previous format (and save it as auto-style or even named-
style, even if it is not used anywhere anymore?).

In general, there isn't much room for applications to add their own metadata 
to a changed region (that is a British understatement coming from a French).

A minor quirk I also faced was that at first my saved documents wouldn't 
validate against the relax-ng scheme because my <tracked-changes> group was 
not the first child of the <office:text> (we had the <text:page-sequence> 
before). As soon as I saved the <tracked-changes> before the <text:page-
sequence> my docs validated properly. This is not documented in the spec. It 
may also be a problem in the validating process.


These are the things I am thinking out of the top of my head. I am sure that 
there are other things that will pop up later. I will keep you informed of 
them.

As a conclusion, I have the feeling that in ODF, change tracking is at its 
infancy. The spec isn't very detailed and leave quite a lot of things opened 
to interpretation. I think it is bound to develop in the future as 
collaboration features are becoming more and more pro-eminent. I am not sure 
that all of the above should be set in stone (perhaps be user configurable, or 
have the user make the decision) or that they even belong to the spec per say. 
I think there is a great opportunity to develop a really good spec on change 
tracking if we all collaborate from the start. It seems we are all (apart from 
Microsoft) quite at the beginning of the change tracking support in our 
applications. Coordinating our progress so that we have coherent behaviour and 
saving syntax would be beneficial to all. I'd personally would welcome such 
collaboration. Microsoft return of experience, should they be willing to offer 
it, would also be extremely beneficial there.

Thanks,

Pierre Stirnweiss


>Greetings!

>Hanssens Bart wrote:
>> Hi,
>>
>> first of all congrats to the KOffice team for releasing a new version :-)
>>
>> As I also mentioned on the OIC list, implementing change tracking seems to  
be
>> a real challenge.
>>
>> So I'd like to know - especially from the KOffice, Dialogika and Microsoft 
teams -
>> where the ODF spec isn't as clear as it should (in other words, when 
writing the
>> code, when did you had to guess / look at existing ODF documents or OOo as
>> a hint ?) 
>>
>>   
>As the ODF editor let me second Bart's call!
>
>I would dearly love to know where we haven't been as clear as necessary.
>
>The problem areas that jump out at you as implementers on a first pass, 
>just aren't as obvious to those of us editing the text.
>
>The ODF TC is about to release the first public review version of ODF 
>1.2 (all drafts are public, this one is just a particular step in the 
>OASIS process). Comments should be submitted via the public comment 
>list: 
>http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=office
>
>Thanks!
>
>Patrick
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]