Change tracking in the proposed ODF 1.2 standard

[robert_weir at us.ibm.com]

sc34wg6-bounces at vse.cz wrote on 08/26/2011 06:58:02 AM:

> From: "MURATA Makoto (FAMILY Given)" <eb2m-mrt at asahi-net.or.jp>
> To: sc34wg6 at vse.cz
> Date: 08/26/2011 07:19 AM
> Subject: Re: Change tracking in the proposed ODF 1.2 standard
> Sent by: sc34wg6-bounces at vse.cz
> 
> > 
> > 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.
> 
> (My personal opinion)
> 
> I translated that part of ODF 1.0.  In the Japanese SC34 mirror, 
> I did not propose to submit a defect report about this topic.  But this
> does not mean that I was happy.   I thought that the DR process is not
> for "redesign change tracking from scratch".  Such a radical comment is
> more approprate for CD or DIS ballots.
> 

It is not necessary to "redesign change tracking from scratch".  We have 
two proposals we're looking at now.  One, from Microsoft, proposes 
incremental additions to the existing change tracking mechanisms.  No 
redesign.  And then there is the DeltaXML proposal, which is a more 
generic approach.  We have not yet decided which approach to take.

One consideration is the impact each proposal would have on the evolution 
of ODF.  For example, if we add a new content element, the generic 
approach would automatically support change tracking of that new content 
type.  The incremental approach would require that we specify how change 
tracking would work for each new content type we add. 

I agree that the generic proposal would be a redesign.  But the 
incremental approach is something that could certainly be handled via 
corrigenda or amendments.  You did the same with IS 29500, right?  DIS 
29500 had broken change tracking for mathematical equations.  It was fixed 
in one of the many corrigenda and amendments (I don't recall which one).

In any case, if an NB has a specific concern with any part of IS 26300, 
I'd encourage the submission of a defect report. 

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/20110826/651c5245/attachment.bin>