Change tracking in the proposed ODF 1.2 standard

Francis Cave francis at
Thu Aug 25 20:53:57 CEST 2011

I believe it should be assumed that any opinion expressed in an email to this list is the opinion of the individual expert and not necessarily that of a National Body, unless it is made explicit that what is being expressed is a National Body position.

Francis Cave

> -----Original Message-----
> From: sc34wg6-bounces at [mailto:sc34wg6-bounces at] On Behalf
> Of robert_weir at
> Sent: 23 August 2011 16:27
> To: sc34wg6 at
> Subject: Re: Change tracking in the proposed ODF 1.2 standard
> sc34wg6-bounces at 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
> Change tracking has existed in ODF since its initial OASIS (2005) and
> 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

More information about the sc34wg6 mailing list