Svante,
Thanks for your comments. I look forward to seeing your
preliminary specification for CCT and we should have time to
discuss that over the coming months while the report is being
considered by the community. It is difficult to engage in
discussions without knowing more detail about your CCT proposal.
In terms of the SC requirement, we have a one sentence definition
already in our statement of purpose, “The SC is asked to prepare a
draft specification of a markup vocabulary that can accurately
describe any incremental change to the content and structure of
documents - typically made in multiple editing sessions by
different authors.”
Regarding your comment about scope in your last paragraph, I have
said previously that it would be useful work to develop a detailed
definition of these edit operations, this will be useful whatever
we do in future. Certainly take the ECT table as an initial basis
and then we need the next level of detail, e.g. what is 'Add' in
basic text content, does it include add paragraph, add list, add
text etc.
Robin
On 18/10/2011 22:15, Svante Schubert wrote:
Hi Robin,
I have read your change tracking analysis with interest,
especially I like your idea of using a SWOT analysis.
Not like John and Thorsten, I will respond without editing the
original document, but providing a personal view.
SC Requirement
The current mission objective of our SC in one sentence, would
come down to:
"Find the optimal way of serializing/saving run-time changes of
ODF applications"
Aside of the above prioritized objective, we have collaboration as
part of our goals in our charter
and of course interoperability of ODF applications as overall goal
and reason for writing the ODF specification.
SC Status
The finding of the optimum solution for CT is ongoing. All have
advantages (unlike you, I am also considering designs without
formal proposal)
- GCT aims to win the price for the most generic and smallest
specification change and additional interoperability with
other XML formats. ODF applications using ODF XML DOM during
run-time have an advantage.
- ECT aims to win the price for the smallest code-change for
applications implementing ODF 1.0 / 1.1 change-tracking
Now I would like to add one new half-fictional proposal, which is
interesting as rumor says there is some EU funding involved and
the result might come back to us sooner or later:
- GIT
is being used to track all the changes within the zip, by
adding a .git directory. This concept works for source code
revision control.
This approach aims to win the price for the best coverage of
changes within the package.
And finally what was only drafted, but yet not formally proposed
- CCT
aims to win the price for interoperability with change
tracking.
Discussion of different Approaches
I would like to assume that every approach is able to cover change
tracking in general.
Instead the focus will be on interoperability.
Interoperability is the reason for the TC's existence. Our first
requirement is to establish interoperability between ODF
applications.
An ODF application that would like to support ODF change-tracking
should be able get all necessary informations about the minimum
required set to cover change-tracking with other ODF applications.
Similar to ODF OpenFormula there might be multiple different sets
in the end. At least there has to be an initial minimum set to
guarantee full interoperability with other CT supporting ODF
applications.
This change set will define automatically the mandatory part (of a
mime type) already required by the ODF
TC charter: "establishing a
set of 'core' elements and attributes to be supported by all
implementations"
Do we have common agreement that we need to establish this
first mandatory set here at the SC?
If we have agreement, this criteria is instantly a k.o. criteria
for the GIT approach, as it is not fine granular enough to allow
the creation of ODF changes.
In addition it mandates the remaining approaches to identify
supported ODF changes, e.g. "moveColumn".
GCT eases the implementation for run-time XML based ODF
applications and gives in its original form little impact on the
specification as its neglects the semantic of ODF changes.
But as none XML run-time ODF applications such as Libre/OpenOffice
need to know what XML changes would have to be implemented first,
GCT have to define this set (but ECT and CCT as well).
Now there is a different requirement on the roadmap of this SC -
collaboration.
Although the SC agreed on the priority in implementing CT,
collaboration will be the next on our list.
Allow me to give one exemplary user scenario of ODF collaboration.
Two ODF applications would like to collaborate in real-time. One
is a browser with special _javascript_ support, one is an ancient
Office (e.g. Libre/OOo).
Both ODF applications are able to save their run-time states to
identically ODF documents, although one is using an internal
HTML/CSS model, the other a ODF related C++ model.
As the real-time changes should be fine granular and fast similar
to Google Docs, we need make the changes fine granular and
efficient. Change-events based on a common model comes first to
mind (see CCT).
Sending ODF GIT patches to the browser, or ODF XML changes made
from GIT or ECT will be painful to map to the HTML/CSS core via
_javascript_. Instead similar components in each application (e.g.
table) have ways to exchange state, e.g. moveColumn.
It seems there are several design solutions possible for CT, but
only one design works well for collaboration.
Now it should be noted, that there is a direct relation-ship
between CT and collaboration.
The difference between serializing change tracking and
collaboration change-events is only the aggregation level.
While change tracking only saves the differences between the start
and end of the session, collaboration change-events still embraces
any intermediate changes.
It is therefore possible to map one to the other.
It comes down to the following question:
Which commercial project would choose a design for its first week,
when it does not fit next week's requirement?
We might of course add a second redundant implementation for the
similar functionality (CT/collab), but more efficient
implementations and more interoperability between CT and collab
will provide us only the CCT approach.
To me this a k.o. to GCT and ECT.
The next step would be to find the first change tracking milestone
to be implemented by all ODF applications.
Office user require interoperability with all office documents,
therefore we should aim for interoperability with OOXML CT,
therefore the ECT scenarios from Microsoft seem to be a good
starting point.
Regards,
Svante
--
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd "Change control for XML"
T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com
http://www.deltaxml.com
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK
|