Change tracking in the proposed ODF 1.2 standard
robert_weir at us.ibm.com
robert_weir at us.ibm.com
Tue Aug 23 17:26:35 CEST 2011
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
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 9435 bytes
Desc: S/MIME Cryptographic Signature
More information about the sc34wg6