Re: [office] change tracking extension

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

Hi Peter, TC members!

Although the change-tracking subcommittee is the correct place to
address this question. I will put the TC on CC and do a quick common
answer so the reply is tracked.
Any further discussion should happen on the subcommittee list - see
https://lists.oasis-open.org/archives/office-collab/201404/maillist.html .

Some comments below:

Am 10.04.2014 11:49, schrieb Peter Rakyta:
> Dear TC members!
>
> As you might know, I develop an extension implementing the merge
> enabled change tracking proposed by Svante. Recently I have made
> further progress in the development. However I would like to address
> several questions in order to bring closer the specification and
> implementation.
>
Great to hear about your progress on your extension.
> -- I have uploaded an odt
> (https://www.oasis-open.org/committees/document.php?document_id=52714&wg_abbrev=office)
> containing the currently supported change types with simple user cases
> of the related xml tags in the undo.xml. I would like to ask you to
> revise these tags. 
A more detailed review will follow on the SC list - 
https://lists.oasis-open.org/archives/office-collab/201404/msg00000.html)
> Regarding style changes I kept the possibility of representing them
> explicitly in the xml, since automatic style names are still
> unreachable through the UNO, and the user-generated styles are not
> enough to thoroughly track style changes. (In the linked odt both
> bold/italic textparts correspond to the same "text body" style.) Hence
> I suggest to keep this possibility also in the standard. What do you
> think?
The automatic style concept is just an implementation detail of ODF. It
is an indirection (bridge) to access the styles being attached to a
component. The format changes are being applied directly to the
component, without any styles. Although the problem of UNO API is an
implementation problem, the style name is of no interest anyway (not
even in ODF). Only the format is of interest. We will talk about it next
Wednesday.
>
> -- I think in order to get usable change tracking system, we need also
> to export data on the author, creation time, and other metadata (like
> a comment). May be these data should be also a part of the
> specification to ensure different implementations would handle these
> data the same way. What do you think? Currently my extension makes
> revisions of a document, means, that particular OTs (changes) are
> grouped under changesets (like an SVN). (An example for the XML
> representation of a changeset is also shown in the linked odt.)
You are absolutely right! Similar to a version control system of source
code - I just would rather point out a decentralized one, as git or
Mercurial - changes are being grouped.
It is always easier to me to start to think of a real-time (RT)
collaboration scenario and break down to a change-tracking one. For
example, think of the TC members as mail correspondents starting a RT
session on your document. We should be able to set mile stones to the
document, comment and group our changes. Another example, if company
members are working on a contract, than there is a certain version that
was sent to the customer. This needs to be marked. In addition if one of
the users goes offline, like sitting in a train driving in a tunnel (or
wants to work on the document offline over the week-end) the offline
work is going to be saved similar to a branch. Absolutely similar as we
have branches in our software repository. With a main branch and feature
branches. The latter make most sense, when we think about very complex
documents, as the ODF specification, where JIRA issues exist from the
ISO National bodies. Each issue result in a change of the specification.
Those changes can be marked as changes belonging to this issue, where a
group of issues belong to a certain country.
I fully agree with you. Metadata makes a lot of sense and will not be
avoided, are just being omitted at the beginning to avoid another step
of complexity distracting the reader/TC member from the core problem of
defining and undoing the changes (action and reverse action).

Happy Easter!
Svante
>
> Best Regards,
> Peter
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php