OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office] Questions/comments concerning the Select Committee report on Change Tracking


Robin,

On behalf of the select committee, some notes and comments:

On 07/19/2012 04:40 AM, Robin LaFontaine wrote:
Questions/comments concerning the Select Committee report on Change Tracking

1. "GCT and ECT were proposed and discussed as changes to the ODF format for change tracking, not collaboration. In fairness to those proposals and to create a common basis for comparison, the select committee choose to compare GCT, ECT and MCT as change tracking proposals only."

A sensible decision, in line with the TC terms of reference for the Subcommittee.


2. "Without implying a decision on syntax, the select committee chose the ETC's feature matrix as the basis for features to be supported by the new change tracking features of ODF (Annex A)."

Speaking as chair of the Subcommittee, there have been strong requests for change tracking in spreadsheets and the terms of reference of the Subcommittee was even wider than this. I note that you have added global operations and that seems very sensible, although useful operations such as text-to-table and vice versa will remain untrackable.


3. "GCT, ECT and MCT all chose different paths but with some minor differences all would satisfy the change tracking use cases."

Actually that is incorrect: ECT was unable to satisfy the use cases for spreadsheets. MCT to date has shown solutions for only a small set of use cases.
The question facing the TC isn't use cases, although they are useful illustrations.

The question facing the TC is what change tracking mechanisms meets present and future needs, across the widest set of implementation models. ODF is the basis for *interoperable interchange* of documents and *not* a processing model.



4. "Having said that, however, ECT adds detailed markup in an attempt to make change tracking “easier” which it may do in some view of the format. Lack of verbosity is not a goal for XML but as has been seen from practical experience, performance of XML editors can suffer from overly verbose XML."

This implies ECT was rejected on grounds of verbosity. I understand from our conference call that this is not the case so perhaps you could clarify this and be a bit more specific in identifying why ECT was not favoured.


Well ECT suffers from the same as GCT. Maybe not in it's current proposal, but in the future when we extend again and again we will end up with an XML format that is even more verbose than GCT. On the other hand ECT offers over GCT a set of changes more tuned to user actions and not to XML changes. At some point in the future the increasing complexity of EEECT XML (extended extended) will possibly be worse than the problems of not having to deal with user centric changes. We say possibly since user centric changes are a big win. Fortunately we don't have to choose (ECT would win) because MCT offers us
both eternally simple XML and user centric changes.


5. "GCT ... represents a great change to the ODF format. It would require a substantial overhead, both for XML and non-XML implementations of ODF. Particularly when compared to the operations proposal which we discuss below. The select committee cannot recommend GCT as the proposal to “fix” change tracking in ODF."

This statement that GCT has a more substantial overhead than MCT seems to be a bold declaration, given that MCT is some considerable way away from being fully defined. Please would you add an explanation of this for the record as you are asking the TC to base the future direction of ODF on this.

Also note that there are already two independent implementations of GCT which provide clear evidence that the overhead is not substantial. Have you dismissed this evidence, and if so please explain why?

Camilla addressed this issue in a previous post.

6. "MCT has been distracting with its emphasis on collaboration issues in a change tracking context. It does offer the cleanest proposal for tracking changes in ODF documents."

Please explain what you mean by "cleanest".

It doesn't mix with the current content. The change tracking is kept separate.

The current "content" of any document is available to an application that can read ODF. Even content changing unaware ones.

7. "The first point to be made is that once operations and addressing are defined, the MCT change tracking proposal only requires an understanding of existing ODF markup. As opposed to specification and parsing of additional, “change tracking” markup."

My understanding was that MCT would require a new set of markup (for operations and addressing) that would need to be defined for use in undo.xml. Each operation would have its own specific markup, which would need to be defined, parsed and understood by an application. Moreover, the application would need to understand and be tested against the definition of all the operations. Therefore, if that is correct, I suggest that this statement is somewhat misleading. Please provide a more detailed explanation of what you mean here.


I beg to differ.

Applications already address the components (to be specified) as they already have editing capabilities.

All MCT needs to specify is a set of operations (add/delete in my view) to be performed on the components already addressed by applications.

Applications will have their own internal models for how they translate the uniform addressing of MCT into their own addressing.

Thus, with a minimum of additional XML syntax, MCT leverages existing addressing capabilities of applications to provide an interchangeable tracking of changes.

True, MCT needs further specification but that could have already happened but for the distraction of collaboration issues (already noted) and various procedural and foot fault type issues.

The select committee was asked to make a recommendation and my colleagues devoted after work hours and weekends to that task. We were not charged with writing a history of every document, email and comment that has occupied the SC for more than a year without any definitive result. We were asked to make a recommendation/decision. We have done so.

Questions are more than welcome. Suggestions that the select committee was unaware of the issues, reported in a "misleading" fashion, etc., are not.

Hope everyone is looking forward to a great weekend!

Patrick
-- 
Patrick Durusau
patrick@durusau.net
Former Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]