[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] change tracking extension
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]