On behalf of the select committee, some notes and comments:
On 07/19/2012 04:40 AM, Robin
Questions/comments concerning the Select Committee
report on Change Tracking
The question facing the TC isn't use cases, although they are useful
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
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
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 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
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
both eternally simple XML and user centric changes.
Camilla addressed this issue in a previous post.
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
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
It doesn't mix with the current content. The change tracking is kept
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".
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”
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 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!
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