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] Change Tracking: next steps

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
  1. Their implementation costs:
    1. 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.
  2. Efficiency of XML encoding:
    1. 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?)
    2. 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)
    3. Are there scenario with conflicts (e.g. xml:id within ECT basket or multiple users change an ODF XML attribute in GCT)
  3. Additional positive side-effect, e.g. for MCT:
    1. Documents can be easily merged, identifying merge-conflicts (user A edit a table cell, user B deleted the table)
    2. Change information can be reused for real-time collaboration
    3. Changes can be saved for a signed document without breaking the signature. Required for work-flow scenarios.
    4. 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)
    5. 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.
  4. Time of delivery
    1. 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.


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 La Fontaine, Director, DeltaXML Ltd  "Experts in information change"
T: +44 1684 592 144  E: robin.lafontaine@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

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