Change tracking in the proposed ODF 1.2 standard

Thu Aug 25 23:17:45 CEST 2011

Absolutely.

Francis

> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton at acm.org]
> Sent: 25 August 2011 21:29
> To: francis at franciscave.com; 'SC 34/WG 6 mailing list'
> Subject: RE: Change tracking in the proposed ODF 1.2 standard
> 
> And ditto for those of us affiliated with liaison bodies, of course.
> 
>  - Dennis
> 
> -----Original Message-----
> From: sc34wg6-bounces at vse.cz [mailto:sc34wg6-bounces at vse.cz] On Behalf
> Of Francis Cave
> Sent: Thursday, August 25, 2011 11:54
> To: SC 34/WG 6 mailing list
> Subject: RE: Change tracking in the proposed ODF 1.2 standard
> 
> 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
> Convenor
> 
> 
> 
> > -----Original Message-----
> > From: sc34wg6-bounces at vse.cz [mailto:sc34wg6-bounces at vse.cz] On
> Behalf
> > Of robert_weir at us.ibm.com
> > Sent: 23 August 2011 16:27
> > To: sc34wg6 at vse.cz
> > Subject: Re: Change tracking in the proposed ODF 1.2 standard
> >
> > 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
> >
> 
> 
> _______________________________________________
> sc34wg6 mailing list
> sc34wg6 at vse.cz
> http://mailman.vse.cz/mailman/listinfo/sc34wg6