Sorry, not been able to answer during Easter time. Keeping it short
as I hope for movement on the Plugfest this week.
In the end we have to pick a proposal like we choose a new gadget
(phone or TV). We compare what we need, with what each solution is
offering compared to its price.
In our terms, the TC is providing the spec for ODF implementors. ODF
implementors will than provide an ODF solution to end users, who are
requiring change-tracking.
The ODF implementations mainly need to be able to receive sufficient
information from the XML (what, where, when, who) to undo/roll-back
changes.
They decide on a proposal in regard of
- Their implementation costs:
- Easiness of XML reading and information recognition for
their ODF app (e.g. recognize the change was an "insert row"
of a certain table)
In other words: How much does it cost to "wire" the change
information read from the document to their application model.
- Efficiency of XML encoding:
- Amount of additional XML to read (Does it scale? E.g. is the
insert of a row in a 10 row table similar to a 1000 row
table?)
- Can the changes be read independently from the content?
(e.g. ODF spec has changes, but an ODF app is only interested
in the changes, does not want to parse the huge content)
- Are there scenario with conflicts (e.g. xml:id within ECT
basket or multiple users change an ODF XML attribute in GCT)
- Additional positive side-effect, e.g. for MCT:
- Documents can be easily merged, identifying merge-conflicts
(user A edit a table cell, user B deleted the table)
- Change information can be reused for real-time collaboration
- Changes can be saved for a signed document without breaking
the signature. Required for work-flow scenarios.
- The components (e.g. table, heading, section, image, etc.)
and their operations identified to break up complexity can be
used for profile creation (e.g. ODF subset mappable to HTML)
- Document mappings to other formats are able to be defined on
the new high level changes. "Insert table row" works for all
document formats HTML, OOXML, docbook, etc.
- Time of delivery
- When are the possible changes been specified by the TC.
Note: That GCT needs to specify possible changes to allow
interoperability.
Finally, we should be aware that the decision we will make, will
most likely stick to the ODF standard for ever, blocking other
approaches, because ODF 1.3 in OASIS + ISO will take about 2-5 years
and once standardized it is hard to remove again. This means for
application: the implementation of GCT (or ECT) for change-tracking
and MCT for collaboration/merging would become quite a burden as two
implementations will raise the complexity of the format and
implementation costs of the vendors, while MCT would be sufficient
for both.
But as I said, the Plugfest will be a good place to discuss this
face to face.
Best,
Svante
On 04.04.2012 13:28, Robin LaFontaine wrote:
Rob asked for ideas on this, so let me put out a strawman
for discussion.
1. There are three possible approaches that have been put
forward:
ECT: Extended Change Tracking, based on extending the current
functionality to cover ODT.
GCT: Generic Change Tracking, provides a generic approach based
on a representation of any change to the XML and applies to all
of ODF.
MCT: Merge-enabled Change Tracking, based on an external
representation of changes to allow merging/collaboration as well
as change tracking.
2. The ODF user community is demanding something better than the
current CT abilities, and so something needs to be done in this
area: the TC therefore has a responsibility to solve this. We
are probably reaching the point where failing to decide how to
move forward is worse than making the wrong decision on how to
move forward - simply because delay provides nothing useful to
the user community, whereas a non-optimal way forward will at
least provide an improvement.
3. Each approach has its own rationale, strengths and
weaknesses. The 'consensus report' outlines these for ECT and
GCT and work is ongoing to include MCT in this report (though
there is no point in doing this unless the TC knows what it will
then do with the report!).
4. Having three approaches is a problem because there is no
obvious way forward, but also an opportunity to choose what is
best for ODF.
5. How would any organisation normally make a choice in a
similar situation? Work out what is required and then determine
which choice is best to meet the requirements (bearing in mind
also how much work is needed and who will do it, i.e.
resources). I do not think such a task is best done by a
committee - it is a job for a small number of experts who have
to answer to the committee and wider community.
6. So here is one possible way forward: the TC asks a task group
of three trusted/respected experts, none of whom are proponents
of one particular approach, to review the current approaches and
recommend to the TC which approach or combination of approaches
or new approach should be adopted. There is quite a lot of
useful material on which to base such a recommendation.
Robin
--
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd "Experts in information change"
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
---------------------------------------------------------------------
To
unsubscribe, e-mail: office-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: office-help@lists.oasis-open.org
|