Re: [office-collab] Wiki updates: Requirements and Use Cases (resend)

[Michael Brauer <michael.brauer@oracle.com>]

Hi Doug,

On 21.01.2011 21:28, Doug Mahugh wrote:

91D8426D0DE09F4C9E09E1605E7FF08E27CFA8A7@TK5EX14MBXC118.redmond.corp.microsoft.com" type="cite">

Hi Tristan,

Thanks for the feedback. I generally agree, although I think we're still looking at the implementation work differently.

I agree that implementation can be a useful step in analyzing the viability of a proposal. But this SC has never discussed the various architectural decisions that went into the DeltaXML proposal, and I think that we should build consensus on those sorts of high-level issues first, before we consider the details of possible prototype implementations.

For example, the CT stack concept allows only for accepting or rejecting changes in the order that they were made in the document. But in my own experience of how people use change tracking functionality, it is more common to go through the document and accept or reject individual changes in a different order -- perhaps in the order they appear within the flow of the document, or perhaps some other order dictated by the specific collaboration task at hand. Some changes really do stack (deleting text that was previously inserted) but that’s  an application UI issue, not a file format issue. Forcing the user to accept/reject changes in a particular order (which is essentially random, determined by the order in which collaborators happened to edit the document) seems to make change tracking more akin to a revision history, with fixed versions of the document available from specific points in time.
  

Isn't this just another requirement. Something like: It must be possible to accept or reject change in any order unless a change depends on another one which first would have to be accepted or rejected?

I don't know if the current proposal supports that, but if not, why not just modify the proposal so that it supports this requirement, too? During the development of a specification, it may of course happen that a particular requirement is not met initially. But I think that does not mean that we need to start from scratch again.
Actually, even if we would have a complete list of requirements, at some point in time someone would have to start with an initial  proposal, would have to check whether it meats all requirements, and if not, would have to modify it (or think about the importance of the requirement) until it meets all requirements.

Having that said: The current proposal seems provide a very solid basis for our discussion, and I'm glad that we received a proposal which contains already as much details as the current proposal does.

91D8426D0DE09F4C9E09E1605E7FF08E27CFA8A7@TK5EX14MBXC118.redmond.corp.microsoft.com" type="cite">

If we have implementers building change-tracking functionality that doesn't allow for the same sorts of flexibility that users have come to expect from alternative change-tracking approaches, I think that starts to limit the SC's options in the future.  We could later decide that arbitrary ordering of accept/reject operations is allowed, of course, but that feels to me like a fundamental aspect of the DeltaXML proposal, and I'd imagine that implementers would find it difficult to make such a change without re-doing a lot of their work.
  

We had a similar discussion in the main TC recently. Actually, whoever implements a proposal or draft does that on its own risk, and the existence of such an implementation of course does not provide that argument that a specification must not be changed. But implementations of proposals actually help us to verify that a particular proposal does work in practice. I'm therefore glad hat there are volunteers for early implementations of the change tracking proposal.

Best regards

Michael

91D8426D0DE09F4C9E09E1605E7FF08E27CFA8A7@TK5EX14MBXC118.redmond.corp.microsoft.com" type="cite">

I just offer that as one of many examples of philosophical/architectural issues that are built into the DeltaXML proposal, may have long-term repercussions, and have never been discussed or analyzed by this SC. I think we need to have those discussions first, in keeping with Requirement 3.3 (high degree of consensus).  Then, after we have reached consensus on a proposed approach, test implementations could be a useful step to help analyze the viability of that proposal.

- Doug

-----Original Message-----
From: Tristan Mitchell [mailto:tristan.mitchell@deltaxml.com] 
Sent: Friday, January 21, 2011 3:16 AM
To: Doug Mahugh
Cc: office-collab@lists.oasis-open.org
Subject: Re: [office-collab] Wiki updates: Requirements and Use Cases

Hi Doug,

Thanks for your comments on this, some very useful points. I have responded inline below.

On 21 Jan 2011, at 00:00, Doug Mahugh wrote:

  

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.
    

Yes, I think that the scope for changes needs to be broader than just document content. Adding layout-specific use cases is a good idea, I will add them shortly.

  

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. J)  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.
    

I agree that this is something that needs consideration and discussion although I'm not sure that it falls within the work of designing a change-tracking format. As long as the changes (and the relevant information such as editor, time etc) are recorded, the processing of the changes to form the next version of the document is surely the responsibility of an application, not the format itself.

  

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.
    

As far as requirement 1.5 goes, I think this would only be a one-way conversion i.e. converting from the existing change-tracking mechanism to the new one. The resultant document would of course have the same limitations as the existing change-tracking format in that it would only represent those changes that can currently be tracked. Converting back the other way is not necessary and indeed need not be possible. The conversion would either be performed via an application's internal model in a load-save cycle and/or could be written as an XSLT script to generate the new format. If we limit conversion to this direction only, I see no reason why interoperability with other formats would need to be compromised.

  

“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.
    

I agree that we already have some cases of information that should not be tracked but this doesn't mean that it can't be. A generic XML change-tracking solution would have the capability of tracking any kind of XML change. An ODF specific change-tracking format could then take the generic format and limit it only to those places relevant to ODF i.e. not tracking cached values etc.
One potential stumbling block here (already pointed out by Rob Weir) is tracking changes in referenced objects such as images. It would be possible (at least in an ODF Zip package) for the XML pointing to an image file to remain precisely the same but for the actual image to be different. We do need to consider how this type of change would be tracked. Note that in the flat single XML file version of ODF, the image would be represented within the XML and changes to the encoded value could be recorded.

  

“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.
    

I understand your concerns here but I think that implementation is a useful step in analysing the viability of a proposal. There are some XSLT scripts for the DeltaXML proposal that show that for a tracked sequence of changes it is possible to get back to any of the intermediate document versions within that sequence but these only go part way to proving it as a solution. Determining whether the proposal can be implemented in an application using an internal model will be very  useful in deciding whether to use it as the final solution or not.


  

“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.”

    

Again I think that a generic XML change-tracking solution would allow us to be future-proof. If any XML change could be represented then any new ODF constructs added in the future could be tracked without any modification to the change-tracking format itself. However, it may be necessary to consider the change-tracking format when specifying new elements, particularly if the new constructs are items that should not be tracked (e.g. calculated values etc).

Regards,
Tristan

  

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/archi
ves/201012/msg00019.html

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

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

(5) Use cases email from Rob Weir
http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archi
ves/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


    

--
Tristan Mitchell, DeltaXML Ltd "Change control for XML"
T: +44 1684 869 035 E: tristan.mitchell@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK







  

--

Michael Brauer | Oracle Office Development
Phone: +49 40 23646 500 | |
Oracle Office Global Business Unit

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

Oracle is committed to developing practices and products that help protect the environment