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


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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

Subject: Re: [office] Change tracking requirements comments

On 18.03.2012 23:53, André Rebentisch wrote:
My apologies, I'll have an important meeting tomorrow but still let me ask a stupid question:

Am 18.03.2012 22:55, schrieb Svante Schubert:

 2. It does not work out, if two ODF applications declare to support
    change-tracking, but define different functionality. There should be
    one minimum set being defined for a minimum of interoperability.
    Like implement the minimum of this feature or leave it.

What exactly do you have in mind with regard to change tracking:
* app-time "undo support" --> application driven
* saved revisions (incl auto-save) -> document driven
Collaboration events, undo, change-tracking are all of the same kind, see

Support for the former can be documented via n revisions in a strict "document driven" way that would be 100% interoperable.

Each revision is a diff to the xml files etc.  We know that XMLdiff solutions exist cmp e.g http://msdn.microsoft.com/en-us/library/aa302294.aspx
but since it is no beauty contest ordinary diff functionality would do.
If we use an ODF XML base approach instead of using an abstraction layer (as operations on high level ODF components), we will get an interoperability problem in the future when browsers want to collaborate with ancient ODF applications. For collaboration we need in the end a lingua franca  to communicate on the same level of understanding. The obvious choice for this level are the well known entities as paragraph, heading, section, table, etc.

An advantage of a "content agnostic" stricly document driven approach
is a high degree of interoperability.
I agree, although on a higher abstraction level than the ODF XML. For instance, the browser is HTML centric and instead of mapping all ODF to HTML and back it is much more straight forward to have a JS library taking those events and mapping them to adapt directly the model of the application. Much leaner and works as well on small devices.
For list of examples for the change-tracking I had in mind, please take a look at http://www.oasis-open.org/committees/document.php?document_id=45463&wg_abbrev=office-collab

For more app-time related changes you may want to model a "document processing machine" and define a set of API functionalities. App-time changes would usually also extend to app-specific issues (e.g. set the paintbrush colour to green) while document driven changes would only extend those changes which alter the document ("add red rectangle")
We are currently focusing on document changes not on application commands. For instance, application could react/behave different with similar user interaction. Best example is a user text selection starting within the mid a heading and ending in the mid following paragraph. If the user presses delete it will result in Libre|OOo to delete the text and merge heading and paragraph, while in MS Office only the text is delete and there are still two different entities of heading and paragraph. No problem for change-tracking/collaboration as both scenarios are mappable to commands - in MS Office the user have to trigger the merge explicitly.
BTW this use case, I had in the back of my mind, when I added the example on slide 13 of the MCT presentation, see

--- A

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

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