Change tracking in the proposed ODF 1.2 standard

[robert_weir at us.ibm.com]

sc34wg6-bounces at vse.cz wrote on 08/22/2011 02:19:01 AM:

> Dear all,
> 

Alex, you sent this to the OASIS public comment list as well.  I'm 
assuming this is a personal comment and is not a comment from BSI IST/41. 
Unless I hear otherwise I'll process it per that assumption.


> As most of you know, the proposed ODF 1.2 standard has a big problem
> in its specification of document change tracking. There are numerous
> public statements – many from OASIS committee members – stating that
> this aspect of ODF as it stands is inadequate, non-interoperable 
> and/or un-implementable. This is borne out by the implementation 
> landscape in which there is poor interoperability between different 
> code bases.
> 

We're quite candid in our views on the ODF TC mailing list.  I think 
you'll find few harsher and more knowledgeable critics than those who are 
working day-to-day on a standard.  This on occasion reaches to hyperbole. 
I'd glad to see, by your comments, that this practice is not limited to 
OASIS. 

Change tracking has existed in ODF since its initial OASIS (2005) and ISO 
versions (2006).  In the five years since it was approved by JTC1 I don't 
recall receiving a single NB comment or defect report related to change 
tracking.  Please correct me if I missed something.  As you know, we have 
been trying very hard to respond to every NB comment received.

In OASIS ODF 1.2 has been out out for public review for a combined 270 
days.  We've received several comments from you related to typographical 
errors and other similar things, and these are very much appreciated. 
We've made many improvements based on comments that you, and many others, 
have sent.  Of course, we also appreciate comments sent on the very last 
day of the last public review for ODF 1.2, but these would be appreciated 
even more if they were in the form of specific technical comments, with 
reference to the specification.  Please correct me if I'm wrong, but I 
believe that is the recommended practice for reporting comments in JTC1 as 
well? 

Change tracking in ODF 1.0-ODF 1.2 is not perfect.  Neither is change 
tracking in OOXML.  They both have functional gaps.  (Have you tried 
change tracking in OOXML presentations, for example?)   The ODF TC has 
created a subcommittee to develop an enhanced specification for change 
tracking for ODF 1.3.  This committee has been meeting for several months 
now.  The intent is to extend the state-of-the-art with change tracking. 
We're taking a comprehensive view of change tracking.  We've created use 
cases and have been reviewing two different proposed approaches, with a 
third hybrid approach recently introduced. All of the major ODF 
implementers are involved in this effort.   You, and any other SC34 
expert, are welcome to join in this effort.  One of the approaches we're 
investigating is generic and could be applicable to enhancing OOXML change 
tracking as well.

One of our overall goals for the ODF 1.3 change tracking is to ensure that 
ODF 1.0-ODF 1.2 change tracking is mappable to any new schema.  We are 
sensitive of the need for ODF 1.3 editors to consistently interpret change 
tracking for earlier documents.  The current plan calls for us to provide 
a canonical mapping from the existing mechanism to the new change tracking 
mechanism.  So existing ODF 1.0-ODF 1.2 users and implementers are taken 
into account in this effort and will suffer nothing by implementing or 
using ODF 1.2.

Finally, I'd note also a little history on the evolution of ODF.  ODF 1.0 
was criticized for poor accessibility.   So we created a subcommittee of 
experts in OASIS, investigated and improved accessibility. The result was 
ODF 1.1, with accessibility that exceeded that in OOXML.  ODF 1.1 was then 
criticized for not having a spreadsheet formula language.  So we created a 
subcommittee, brought together the experts, and created OpenFormula, a 
specification that is more thorough and more accurate than what exists in 
OOXML.  You'll see this in ODF 1.2.  And now we're getting criticism for 
functional gaps in change tracking.  So we've created a subcommittee, 
brought in the experts, and are currently working on a specification that 
will once again advance the state-of-the-art.  ODF 1.3 will contain the 
outcome of this work.  You're welcome to join in this effort.  I'm sure 
you would have some insights that we would benefit from. 

Woody Allen once said, "Time is just nature's way of preventing everything 
from happening at once".  I think standards revisions are similar. 
Implementers, adopters and users cannot easily manage rare and monumental 
updates of standards.  The release of standards must bear some 
relationship to the upgrade and adoption cycle of the underlying 
technology.  The ODF TC has already heard NB concerns about the slow pace 
of ODF releases.  Where major application vendors have releases every 3 
years and open source projects release every 6 months or less, it is 
unacceptable to have 5 year standards cycles.  The fact that we are doing 
the ODF 1.1 amendment is one sign of that failure.  Let's not repeat this 
error.  Instead of holding back the good work in ODF 1.2, in things also 
demanded by NB's, and also demanded by users and adopters and 
implementers, like spreadsheet formulas, improved accessibility, RDF 
metadata, etc.,  let's move forward.  The vote of the ODF TC, the 
implementers both commercial and open source, and of our independent 
experts, was unanimous on this.


Regards,

-Rob


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 9435 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.vse.cz/pipermail/sc34wg6/attachments/20110823/41ea15f5/attachment.bin>