Conceptualizing Change Marking

[robert_weir at us.ibm.com]

Hi Michiel,

I'm supportive of any attempt to improve ODF in this area.  So you have my 
thanks for your efforts in putting together this proposal.

When you are ready to make a specific technical proposal, could you send 
it to the OASIS ODF TC's public comment list as well? 

Thanks,

-Rob

sc34wg6-bounces at vse.cz wrote on 07/27/2010 11:42:31 AM:


> Hi Dennis,
> 
> thanks for the link. I'll have a detailed look at it (I am currently
> at the IETF, where 
> we just launched a grant programme for work on an important new internet 

> security standard called DNSSEC). Looks interesting, especially for 
blind
> users of Office products (where visual metaphors fail).
> 
> > So there are two problems, as I see it.  First, the ODF specifications 
need
> > to be repaired so that the specified places where change history is 
supposed
> > to work already are supported by correct specifications.  The second 
matter,
> > which we should keep separate, is any addition of further 
change-tracking
> > features for cases that the repaired ODF specification does not 
handle.
> 
> I would agree that technically these are different problems, yet if 
> the second 
> problem is solved by the only solution to the first problem it is 
> reduced back to 
> one problem. I would argue that this is the case.
> 
> The current specification of track changes in ODF 1.0 is defect in 
> that applications
> can't rely on it for interoperability; the fact that various 
> applications have 
> each extended the specified behaviour with additional mechanisms to 
track 
> a small subset of change types with limited success illustrates that. 
KOffice
> is able to deal with mixed type changes (deletion of text spanning part 
of 
> a list and text paragraphs for instance) using ODF RDF metadata, which 
many 
> other applications cannot deal with (but which works for KOffice users 
among
> each other). OpenOffice.org does something different, and so does 
AbiWord etc.
> There is no reasonable choice to make among these different mechanisms 
> that would not discriminate others, so as I see it there is nothing 
> to describe
> that 'works'.  The fact is that the conceptual model itself is 
> incomplete which 
> resulted in different non-interoperable extensions deployed out there 
> - making the current specification technically broken beyond repair. 
> 
> After careful research we did not see any way to unite the various 
features 
> from different applications within the model in an interoperable way- 
making 
> a new model inevitable for repair. The new model does not suffer anyof 
these 
> complications, and will work for all applications. It provides a generic 
and 
> robust mechanism that captures all use cases from all applications we 
were 
> aware of - including spreadsheets and presentations for that matter. I 
would 
> love to hear if there are any ODF applications out there that have any 
change 
> they cannot track with this new part of the specification. I cannot 
> imagine any 
> repaired version of the current model for all versions of ODF that would 
deal 
> with all use cases. By moving to another mechanism we get all the extra 
> functionality for free with the repair, which is an extremely nice 
bonus. 
> 
> Of course for interoperability with legacy applications the deprecated 
legacy 
> application defined behaviour and formatting may be used (and could be 
> described by each of the vendors), but for the ODF standard the most 
> obvious thing to do is not to go into a lot of controversy for adopt a 
> non-broken mechanism into the standard - and just deprecate the
> old broken one in favor of a working one as soon as possible.
> 
> Best,
> Michiel Leenaars
> Director of Strategy
> NLnet foundation
> 
> VP OpenDoc Society
> _______________________________________________
> sc34wg6 mailing list
> sc34wg6 at vse.cz
> http://mailman.vse.cz/mailman/listinfo/sc34wg6