OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-collab] Suggestions for moving forward to resolveissues


On Thu, 2011-04-21 at 10:36 -0600, Robin LaFontaine wrote:

> A1. To resolve the issue over implementation, please could those who
> currently feel that the GCT is impossible/difficult/expensive to
> implement talk to those who have already done implementations? Perhaps
> the question to answer is: what restrictions could be put in place to
> make it easier to implement the GCT?

I have the impression that there aren't any truly independent
implementation of this by two (or more) editing applications. While
there appear to be two implementations they seem to have been developed
in close cooperation (as far as this feature is concerned.).
The difficulty I see with regard to implementation is how to adress the
general situation when I one just encounters a valid ODF file with
change tracking. The fact that the gct is so general a reading
implementation would need to be able to be similarly genral when reading
the file.


> Clearly change tracking is a big challenge, and implementing it is
> never going to be easy. The question is whether it is that much harder
> in the generic format than the extended one. Given the above
> implementations, and given the fact that OpenOffice and LibreOffice
> are probably closer to ODF, is it really an impossible problem? Can
> someone articulate why it is difficult, and how it could be easier?

I am really not sure what the closeness of OpenOffice and LibreOffice to
ODF has anything to do with this.

Perhaps I misunderstood the Koffice and Abiword implementation work, so
are you saying that these were completely independent implementations
(ie. without any significant communication between the two
implementation groups)? 
> 
> 
> 2. Scope: should all changes be tracked or only those that editing
> applications currently track?
> 
> There seem to be two viewpoints:
> 
> V1. Editor Feature viewpoint: CT should support the features in
> editors, no more and no less. Therefore editor application programmers
> need to agree on what these are and then they can be implemented in
> ODF.
> 
> V2. Document Version viewpoint: CT should support changes to the ODF
> representation of a document, so it should be possible to roll-back to
> any previous version. It should be possible to track any change even
> if a particular application cannot handle the change.

I don't see how this is possible. I f I have a sequence of changes
A(recent), B(older), C(oldest) and I don't understand B how could I ever
want to roll back to C!? In fact if I perform some editing how could I
ever justify to resave B into a new file when I don't understnd the
meaning or effect of B on a different application? 
> 
Andreas
-- 
Andreas J. Guelzow, PhD, FTICA
Mathematical & Computing Sciences
Concordia University College of Alberta



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]