RE: [office] A few thoughts on ODF change tracking

[Cherie Ekholm <cheriee@exchange.microsoft.com>]

I would agree with the sentiments expressed by others over the last few days that it's best to move a deep look at change tracking to ODF-Next. We had some of our CT experts take a preliminary look at the DeltaXML proposal, and they have identified some issues that need to be discussed. I'll add those to the JIRA comments shortly. We'd like to help with CT in ODF-Next and ensure that the interop story among ODF vendors is good as well as insuring good interop between ODF and OOXML.

I would also take a cautious view to fixing current flaws at this point in the process. If there are small fixes that are clear wins, we should consider those. But if fixes break existing good functionality or backwards compat, might hinder work we do in ODF-Next to get CT right, or add complexity, this is not the right point in the process to make those types of fixes. There comes a time in every project where you have to make those hard decisions to either let the project go out the door, or slip the schedule to get something "just right". This would seem to be that time for ODF 1.2.

Cherie

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
Sent: Wednesday, September 22, 2010 6:38 AM
To: 'Michael Brauer'; robert_weir@us.ibm.com
Cc: 'Patrick Durusau'; office@lists.oasis-open.org
Subject: RE: [office] A few thoughts on ODF change tracking

I think it is important, in this back and forth, to differentiate between the DeltaXML proposal which is in many ways a new feature that would deprecate what is attempted in ODF 1.0/.../ODF 1.2, and a defect which we know we have.  Knowingly letting such a significant defect remain in the specification is a different problem. 

I don't think anyone on the ODF TC is proposing taking up the DeltaXML proposal, because it is so far reaching.  However we still have the defect to deal with in a responsible way, as we discussed on the last call.  

I am hopeful that Oliver's researches will be helpful in that regard.  In particular, it seems to me that it is currently impossible to create an interoperable implementation of the current feature without consultation and mimicry/reverse-engineering of code that is asserted to be a conforming implementation.  We already know that implementers have gotten it wrong as well and some implementers won't touch the feature because they can't tell what it is.

That, for me, is a far more serious matter than deferral of a proposed feature that supplants or expands the attempted specification of tracked changes in ODF 1.0/1.1 and now 1.2.

 - Dennis

[Note: I can imagine that consultation of language in the DeltaXML proposal might give us useful terms and concepts for expressing the specification of the ODF 1.2 tracked changes as limited to the scope of the current specification.  I don't consider that the same thing as taking up the DeltaXML proposal and I am not assuming that to be necessary at this point without first understanding what was envisioned for the tracked-changes features in the scope of ODF 1.0 and as perpetuated into ODF 1.2.]

-----Original Message-----
From: Michael Brauer [mailto:michael.brauer@oracle.com]
Sent: Tuesday, September 21, 2010 23:51
To: robert_weir@us.ibm.com
Cc: Patrick Durusau; office@lists.oasis-open.org
Subject: Re: [office] A few thoughts on ODF change tracking

[ ... ]


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php