[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic