Conceptualizing Change Marking
robert_weir at us.ibm.com
robert_weir at us.ibm.com
Tue Jul 27 23:05:37 CEST 2010
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
More information about the sc34wg6
mailing list