OASIS Open Document Format for Office Applications (OpenDocument) TC

Hopefully you are able to all find some time before Monday's call to read through the draft requirements for change tracking as posted on the wiki: http://wiki.oasis-open.org/office/Change%20Tracking%20Meta%20Requirements We can streamline the call a bit if you raise any priority issues or concerns you have,especially for the items after 9, which is as far as we got last week. Some quick comments from me: 10, on ordering.  A user most typically expects to view the tracked changes in order of the document's presentation, i.e., "visual document order". Do any apps have a UI for doing this in chronological order of the changes?  Interesting idea, but I don't think that I would optimize for that scenario. 12, 13, 15, 20, 21 and 27 seem to all be variations on a common concern:  ODF is a standard for a document format.  It is not a standard for a word processor or other editor, beyond some formatting and layout guidance.  In particular we have not defined the permissible editing operations for an editor.  I think this is the key question. 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.  It is an interesting approach, for an application to take.  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. -Rob

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. > 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. Best, André

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/

Thanks for pushing this further on the list, Rob. I would love to map every requirement to a scenario (if the comment/explanation is not already the scenario). Some might differentiate between end user scenarios and application vendor scenarios (which would finally map to a user scenario), but this is not important IMHO. But we might think about some classification of scenarios, like marking interoperability, metadata, efficiency scenarios. Grouping might have the nice side effect, we might group similar scenarios together, finding easier duplicates. More important, when reading we should prioritize the requirements into three groups: 1, 2 and 3. Where 1 is the most urgent group with certain scope of our next release and 2 like a maybe for next release and 3 with a worthwhile, but follow up requirement. The latest requirement list counts 38 columns. Having a closer look 33-38 are draft report questions, which are worth to be answered and should remain for now, but should be mapped to scenarios. I started to copy paste everything from the wiki into an ODF spreadsheet and added priorities as described above. I will upload it, so anyone, could adapt the document according to their own priorities as note for the upcoming call. Again the spreadsheet is not meant as data duplication to the wiki, which is our main data store, but as a simple working utility. (see http://www.oasis-open.org/committees/document.php?document_id=45468&wg_abbrev=office ) Svante On 17.03.2012 20:31, robert_weir@us.ibm.com wrote: Hopefully you are able to all find some time before Monday's call to read through the draft requirements for change tracking as posted on the wiki: http://wiki.oasis-open.org/office/Change%20Tracking%20Meta%20Requirements We can streamline the call a bit if you raise any priority issues or concerns you have,especially for the items after 9, which is as far as we got last week. Some quick comments from me: 10, on ordering.  A user most typically expects to view the tracked changes in order of the document's presentation, i.e., visual document order . Do any apps have a UI for doing this in chronological order of the changes?  Interesting idea, but I don't think that I would optimize for that scenario. 12, 13, 15, 20, 21 and 27 seem to all be variations on a common concern:  ODF is a standard for a document format.  It is not a standard for a word processor or other editor, beyond some formatting and layout guidance.  In particular we have not defined the permissible editing operations for an editor.  I think this is the key question. 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.  It is an interesting approach, for an application to take.  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. -Rob

On 18.03.2012 17:33, Svante Schubert wrote: More important, when reading we should prioritize the requirements into three groups: 1, 2 and 3. Where 1 is the most urgent group with certain scope of our next release and 2 like a maybe for next release and 3 with a worthwhile, but follow up requirement. I forgot to mention the scenarios for the request of priorities: The complete set of ODF can hardly be implemented in one step due its amount of feature-set. IMHO a quick adoption of future technology could be best archived by collecting the most demanding use cases - like the set the extended change-tracking proposal defined and define it as first mandatory set. 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. Note: There might be further sets than three at all, like three sets for each mime type or even more. Best, Svante

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 or * saved revisions (incl auto-save) -> document driven ? 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. An advantage of a "content agnostic" stricly document driven approach is a high degree of interoperability. 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") --- A

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 or * saved revisions (incl auto-save) -> document driven ? Collaboration events, undo, change-tracking are all of the same kind, see http://lists.oasis-open.org/archives/office-collab/201107/msg00017.html 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 http://www.oasis-open.org/apps/org/workgroup/office-collab/download.php/45161/latest Best, Svante --- A --------------------------------------------------------------------- To unsubscribe, e-mail: office-unsubscribe@lists.oasis-open.org For additional commands, e-mail: office-help@lists.oasis-open.org

On 17/03/2012 19:31, robert_weir@us.ibm.com wrote: 12, 13, 15, 20, 21 and 27 seem to all be variations on a common concern:  ODF is a standard for a document format.  It is not a standard for a word processor or other editor, beyond some formatting and layout guidance.  In particular we have not defined the permissible editing operations for an editor.  I think this is the key question. I agree this is a key question, and I think you mean that in a document format it is not appropriate to define the editing operations... but this is a contentious issue I believe (understandably). Are we trying to track editing operations or changes to the document (see 35)? Robin -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Experts in information change T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK

On 19.03.2012 13:01, Robin LaFontaine wrote: On 17/03/2012 19:31, robert_weir@us.ibm.com wrote: 12, 13, 15, 20, 21 and 27 seem to all be variations on a common concern:  ODF is a standard for a document format.  It is not a standard for a word processor or other editor, beyond some formatting and layout guidance.  In particular we have not defined the permissible editing operations for an editor.  I think this is the key question. I agree this is a key question, and I think you mean that in a document format it is not appropriate to define the editing operations... Not appropriate like against habit or good manners? ;) It seems quite the opposite, as for optimal interoperability a document format not only have to define how to serialize, but how to visualize and how to interact. We might call it the specification of model, view and behavior. Honestly how do we optimize the serializing and of run-time changes, without knowing what a run-time change might be? How can we ever be interoperable? but this is a contentious issue I believe (understandably). Are we trying to track editing operations or changes to the document (see 35)? This seems like a riddle question as they are pretty much related, as actio and reactio. As in general first there is a run-time editing operation, resulting into a document change, when being saved. For instance, if an application is saving its state into a new document after each editing operation, the delta between two sequent documents is the document change, caused by the editing operation. The remaining question is how to optimize this serialization of change to be able to undo it in terms of efficiency. While the GCT & ECT approach, is declaring every ODF XML change within the XML files, I tend to serialize only a queue of editing operation in a separate file, referring implicitly to the ODF spec, where the repeating boilerplate is being once defined instead writing it down in every document for every occurrence of an operation. Svante Robin -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Experts in information change T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK --------------------------------------------------------------------- To unsubscribe, e-mail: office-unsubscribe@lists.oasis-open.org For additional commands, e-mail: office-help@lists.oasis-open.org