I like John's idea in stepping back from the details of the proposals, examining instead their motivations and support. Our initial motivation is framed by the initial requirements list Robin once sent out. If I would have known what I know today, I would have added the following scenario: You work with your laptop in a train via WIFI on an office document with your colleagues. The colleagues using arbitrary ODF clients (e.g. OOo LibreOffice, KOffice, Abiword, MS Office, Webbased offices, mobile devices, etc.). The train enters a long tunnel, you loose WIFI, but you finish your idea you are currently writing on. You save your changes as ODF document to your hard disc as you take the opportunity for a break. Of course those changes should be saved in a standardized way using change-tracking. You close the laptop. After the break and with WIFI up again you decide to continue your work. You go up online and your last changes from the tunnel should be automatically synced with the latest from your colleagues. You continue your work. We have seen two technical stand-point in the SC by the two earlier proposals. There are a lot more possible proposals to enable change-tracking. For instance using the existing technology of a distributed revision control system as GIT (or Mercurial) within the package. Saving all the changes into a GIT folder. Another valid approach would be to add the change-tracking technology to the ZIP package. This is all feasible, some may say they all have their pro & cons. But if you look at the above scenario of real-time collaboration, there is only one efficient way to handle collaboration. By dispatching the status changes (diffs) among the participating ODF clients. Another requirement becomes apparent from the variety of the ODF clients being used. The required lingua franca of dispatched calls among them is certainly based on ODF, but have to hide (or abstract from) the ODF XML details, as only a few clients are aware of them naturally. ODF XML is not (and should not become) a requirement for ODF applications. The above scenario - where the user desires to be able to save collaboration changes via change-tracking and synchronize own changes back later - requires a (most efficient) compatibility between the change-tracking serialization and the dispatching of status changes among ODF clients. What can be closer than serializing the dispatched differences as change-tracking? That was the motivation behind my proposal. As we know that the Advanced Document Collaboration SC will have to deal with collaboration in the end, we should now not run into a dead end using a change-tracking approach that is inefficient for later use with collaboration. In the end ODF implementors have to sum up the run-time complexity and development efforts of both CT and collab, the complete SC's work. It would be fatal if the possible synergies of change-tracking and collaboration would be ignored. There are even huge advantages for change-tracking when designing it in harmony with collaboration taking advantage of synergies. The customers asked for change-tracking. We might even give them more, give them what they desire and provide the ability to automatically merge changed documents. Our SC's proceeding is directly dependent on the agreement of the above scenario and its conclusions. I think collaboration requirements are necessary for the evaluation of change tracking proposals, present or future extensions. We presently have no requirements to meet that need. They should be developed before adopting any change tracking proposal. Kind regards, Svante On 13.01.2012 02:48, John Haug wrote: I agree with the previous sentiments that it would be useful to examine the motivations and support behind elements of the two proposals, as opposed to details of the proposals themselves, including comments from externals on their needs and wishes, even if done in the context of the existing GCT & ECT proposals. I think that is one component of the larger task of determining the goals and constraints, and the relative importance of each of them , which necessarily involves debating and answering (as best as able) big questions that establish broad goals, rough direction and fencing (as in, deciding what you're not going to do is an important part of deciding what you are going to do).
http://lists.oasis-open.org/archives/office-collab/201104/msg00070.html Based on the results of that, I certainly endorse the notion of doing some co llaborative *design* work to arrive at the right approach on the whole for the various interest groups - implementers or some types of apps, implementers of different types, end users, etc. Perhaps in addition to being a +1 reply, pulling together in this way a few of the sentiments expressed gives us a sketch for how the SC proceed next. There's also been interest in the proposal Svante has discussed in the past, so taking a step back to debate high-level questions would let his ideas filter in without having to wait for a full-blown proposal document. (Which would just leave us with three very different proposal docs rather than two.) John
Original Message----- From: office-collab@lists.oasis-open.org [ mailto:office-collab@lists.oasis-open.org ] On Behalf Of Thorsten Behrens Sent: Thursday, January 12, 2012 9:40 AM To: Patrick Durusau Cc: office-collab@lists.oasis-open.org Subject: Re: [office-collab] WD04 comments [3 Thorsten] Patrick Durusau wrote: Maybe. Still, the report is missing another, quite fundamental contribution to the sc, that provides answers to some of the posed questions. Sorry, that went by a little fast. Which fundamental contribution? Or do you mean Svante's? Yes - it was said to somehow be a middle ground, plus addressing collaboration more cleanly, which is in the very name of the sc. :) I am anxious to see it but does that impact the priority we would assign to change tracking issues? I would think so. Change tracking has been a festering issue for years, I would hate to waste people's time with something that may change substantially in a month or two. Cheers,