Re: [office] Change tracking requirements comments

[Svante Schubert <svante.schubert@gmail.com>]

Hi André,

comments below..

On 18.03.2012 01:27, André Rebentisch wrote:

Am 17.03.2012 20:31, schrieb robert_weir@us.ibm.com:

22, reuse of existing version control mechanisms -- I think this was
based on an observation that an application could simply embedded
something like git and have a very fully-featured way of tracking
versions, merging changes from different users, etc. 

The idea was to avoid a reinvention of the wheel:
-------------------------------------------------
* Multiple existing software stacks exist which efficiently implement
the functionality of plain text versioning. All the functionality for
versioning exists.
* The technical difficulties (e.g. digital signatures, multi-user
editing, branching etc.) are already implemented and maturated.
* Years and years of industry experience, both from an implementation
and the user side. All tech. options have been debated, researched and
tried out.
* Standardization efforts for versioning do exist.

In principle, you could unzip an ODF file, store it in any common
versioning solution, and zip a revision checkout to generate the ODF.
Proof of concept is implementation-wise trivial for developers.

I am with you as stated before [1] that the problem domain of change-tracking is quite similar to VCS.
The storage of none ODF data, e.g. binary image data could/should be handled by VCS technology, if there would be a standard we could refer to as Rob had mentioned.
On the other hand, for ODF changes I have an optimized handling in mind, which has a better merge and history ability than generic VCS can offer. In addition the solution in mind should be able to be reused for later collaboration. (You are not planning to sent VCS diffs over the wire for change-tracking, do you? Just remember the hammer and the nail tale ;) )

There is no interoperability among VCS. And there is no unless versioned data by GIT/Mercurial/Subversion is exchangeable, like if reading VCS repository of vendor 'A' with VCS client of vendor 'B' is possible.
AFAIK there is no VCS standard (aside of the voluntary carbon standard, which is close but not close enough). Nevertheless I have to investigate in the next weeks if an API standard is possible at all. It seems tempting as already many command line interface API calls are very likely (at least a subset). Perhaps the different architecture could be abstracted by a standardized VCS API subset, but which VCS application has the most flexible serialization model worth to be standardized? Lucky us, this has not to be solved nor discussed in this thread.

But we need to ensure
that as a standard ODF remains application neutral.  If there were an
actual standard for the storage of version control, info, then that
would be more interesting.

The approach would limit the challenge of the ODF TC to defining an
interface to a versioning provider: odfDAV.

For WebDAV a similar approach was followed.
http://tools.ietf.org/html/rfc3253
http://tools.ietf.org/html/rfc4918
etc. HTML and ODF are not a long way away from each other.

Problem: We have to find a solution for the serialization of changes. WebDAV (or even CMIS [2], see Apache Chemistry [3]) is about accessing the versioned data.

Best,
Svante

Best,
André

---------------------------------------------------------------------
To unsubscribe, e-mail: office-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: office-help@lists.oasis-open.org

[1] http://lists.oasis-open.org/archives/office-collab/201202/msg00037.html
[2] http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services
[3] http://chemistry.apache.org/