RE: [office-collab] Wiki updates: Requirements and Use Cases

[Doug Mahugh <Doug.Mahugh@microsoft.com>]

I’ve reviewed the list of requirements and use cases on the wiki, and it looks like a great start. Thanks for pulling this together, Robin.

Regarding use cases, the list is quite comprehensive and seems close to complete. One thing I did was to compare that list to the various things that ISO/IEC 29500 change tracking covers, and they line up pretty well but there are a few areas that may be worth adding to our list.  One broad general category would be changes to document layout, as opposed to document content. For example, changes to a document’s page size, orientation, or number of columns (Part 1, Section 17.13.5.32 sectPrChange), or changes to a table’s properties such as column width (Part 1, Section 17.13.5.33 tblGridChange). These sorts of changes can have a significant effect on the user’s perception of a document even if the document text has not changed, and they’re the sorts of things that people often tweak in multi-user collaborative editing scenarios, so it would be useful to be able to manage those changes in the same way that content changes are managed.

Another observation on the use cases list is that it’s currently a list of specific types of content that could be inserted, deleted or moved (which is an important first step), but I think it would be useful to think about some of the ways these atomic operations are typically combined in collaborative editing scenarios, and how people tend to work with changes from multiple users. For example, a common scenario might be for user A to insert a paragraph, users B and C make changes to that paragraph, and then the editor/originator of the document might want to include A’s paragraph with some of C’s changes and none of B’s changes.  (We all know people like B. )  I don’t have a specific proposal for how we capture such multi-step scenarios, but I assume we’d all agree that we want to end up with an approach that allows for the most common ones.

A few thoughts on the Requirements page …

One thing that struck me was the combination of “1.5 Can convert from existing change tracking mechanism to new one” and “2.2 Interoperability with other formats.” These two requirements may be at odds with one another: is it actually possible to define change tracking in a way that maps to the existing approach as well as the approach used in OXML, for example? I think that we should take into consideration the magnitude of existing usage of ODF and OXML change tracking, and prioritize accordingly, in the interest of maximizing the opportunities for use of the new approach we’re designing. I’m sure there are other perspectives on this, but it’s probably a conversation worth having.

“2.4 Track all possible types of change” is a very broad statement, and we’ve already discussed some exceptions to it (such as the issues surrounding cached and recalculated values in spreadsheet formulas, for example). I think we should modify this requirement to something like “Track appropriate types of changes” or something similar.

“2.6 Proven implementations” seems a good requirement once we decide upon a specific approach, but I think we should be clear that we’re designing an approach first, and then we’ll need to see implementations of it. I’m a little concerned by the fact that some SC members appear to be actively implementing the DeltaXML proposal (per Ben’s questions) or considering the details of how to do so (per Frank’s comments). Would everyone agree that we should not be rushing to implement a specific proposal prior to this SC agreeing upon a design? If so, then I think we need to work through the high-level concepts first, and then look at how various approaches (including the DeltaXML proposal) can support our collective vision of how ODF change tracking should work. I’d hate to see us start making design compromises in the interest of compatibility with a specific proposal that we’ve not yet analyzed, discussed, or agreed upon.

“3.1 Future-proof” is an appealing concept, but the concept of assuring that no additional work would be needed on change tracking when new ODF features are added sounds problematic to me. Can we really decide, in this SC, that all of ODF’s future evolution will be constrained by the design we come up with for change tracking in ODF v-Next? Would we even want to decide this? I think that we (and all other stakeholders in ODF maintenance) are unlikely to adhere to such a constraint, and for that reason I’d rather say “minimal additional work needed” instead of “no additional work needed.”

What do others think?

Regards,
Doug

-----Original Message-----
From: Robin LaFontaine [mailto:robin.lafontaine@deltaxml.com] 
Sent: Wednesday, January 19, 2011 4:02 AM
To: office-collab@lists.oasis-open.org
Subject: [office-collab] Wiki updates: Requirements and Use Cases

Wiki updates: Requirements and Use Cases

We have updated the wiki (1) to include a summary of the Requirements (derived from (2)) and also all the Use Cases that we have to date.

The wiki provides a list of all the Use Cases, and the actual files are posted in a zip file in a new Use Cases folder in the documents section (3). For each use case, the zip file contains the ODT documents. In most cases this is two documents ('before change' and 'after change'), but for some use cases it is more than two. The document samples contain text to describe the change, so they are intended to be self-documenting.

The Requirements and the Use Cases both have reference numbers against each item, to make it easier for e-mail discussion on any individual item.  The zip file for the Use Cases has also been annotated with the numbers for easier cross-referencing.

The Use Cases zip file does not contain any worked solutions, but if you want to access the original submission which includes worked solutions and code to demonstrate that they work, then this is in the office comments e-mail (4). This does not contain the new Uses Cases I ('Other' 
section).

In addition to the Use Cases above, we also have Rob Weir's comments in his e-mail dated 6th January 2011 (5), and I will reply to that separately because I think there are some points that need further discussion.

If you are aware of any other use cases or requirements, please add these to the wiki as soon as possible.

(1) Wiki with Requirements and Use Cases:
http://wiki.oasis-open.org/office/Advanced%20Document%20Collaboration

(2) Original ADC Requirements Summary email:
http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201012/msg00019.html

(3) Documents including Use Cases zip:
http://www.oasis-open.org/apps/org/workgroup/office-collab/documents.php

(4) Original submission with proposed solutions http://lists.oasis-open.org/archives/office-comment/201007/msg00011.html

(5) Use cases email from Rob Weir
http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201101/msg00000.html

--
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd  "Change control for XML"
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 from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php