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

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

Hi Michael,

Good points from you and Rob. Regarding submitting an alternative proposal, we’ll consider this possibility after the requirements phase is completed and the SC has made decisions on the scope of what’s needed. AS Rob points out, there are two obvious paths forward at the moment (refining the DeltaXML proposal or refining the existing text in ODF 1.2), and I’d say it’s not clear yet (to me, anyway) whether the best solution will be one of those paths or a third rail. Er, path. :)

Regards,
Doug

From: Michael Brauer [mailto:michael.brauer@oracle.com] 
Sent: Tuesday, January 25, 2011 7:42 AM
To: Doug Mahugh
Cc: robert_weir@us.ibm.com; office-collab@lists.oasis-open.org; Tristan Mitchell
Subject: Re: [office-collab] Wiki updates: Requirements and Use Cases

Hi Doug,

I agree to Rob. So, we have the proposal from DeltaXML. My point was that I find it obvious and reasonable that those TC members who have worked out this proposal  check whether it meets the requirements that the  SC defines, and that they if required adapt it. I would find it strange if they stop any work on their proposal until the SC has defined all requirements.

But of course, the fact that TC members work on a proposal does not imply that this proposal is already accepted, or that the TC may not get alternative proposals. However, if you intent to submit an alternative proposal, it would be fair if you let the SC know that.

Best regards

Michael

On 24.01.2011 19:15, robert_weir@us.ibm.com wrote: 
Hi Doug,

If you have a concrete proposal, feel free to make it.  Otherwise I think 
it is natural that we consider the two specifications that we have in 
front of us:

1) The existing ODF 1.2 change tracking specification (essentially our 
default position, if we do nothing)

2) The deltaXML proposal

Other proposals are welcome, of course.

In parallel we're also gathering requirements and use cases:

http://wiki.oasis-open.org/office/Advanced%20Document%20Collaboration

I think your feedback so far on the high-level ramifications of a 
particular model is valuable.  It is good to separate the important model 
issues from the issues of mere notation.   So I think we're having the 
right kinds of discussions.

I know that we're not following a pure "waterfall model" development, but 
I think there is some value to iteration, of looking at requirements, 
specification and implementation together and iterating until you've 
satisfied all constraints.  Such a loosely-structured approach might not 
scale to extremely large efforts, but I'm not overly concerned with it 
being used for this SC's modest efforts.

Before you joined the TC, we had a similar situation with OpenFormula.  A 
3rd party group -- the Open Document Fellowship -- noting the lack of a 
detailed formula specification in ODF 1.0, drafted one on their own.  They 
contributed the draft to the ODF TC and some of their members joined as 
well.  We elected the author of that specification as SC Chair.  We worked 
on the draft in a SC until it was ready for inclusion in ODF 1.2.  The end 
result appears to have satisfied all.  We're we appreciative of the 
specification contributed by the Fellowship?  Yes.  But did we take it 
as-is and refuse to change it?  Hell, no.  We spent a couple of years 
working on the draft, including work to make sure the spec was 
implementable by legacy applications.  I'm hoping we can do something 
similar for change tracking, albeit at a faster pace, as befits a much 
shorter specification.

Regards,

-Rob


Doug Mahugh <Doug.Mahugh@microsoft.com> wrote on 01/24/2011 12:03:15 PM:
  
Michael,

    
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.

I agree that this should be a requirement, but I don’t understand 
the perspective that including such a requirement would be starting 
from scratch “again.” Isn’t that where we’re at in the process, at 
the initial requirements-gathering stage? Your comment seems to 
imply that there has already been a requirements-gathering process, 
but I’m not aware of any such process that has taken place in this 
SC, the ODF TC, or any other open and public group. You also mention
the concept of modifying the DeltaXML proposal, but that seems to 
presume that this SC is actively working from that proposal and 
massaging it into our final recommendation. If that’s your view, 
it’s not clear to me how or when we arrived at that position.

When this SC was formed, the Statement of Purpose asked us to 
“prepare a draft specification of a markup vocabulary that can 
accurately describe any incremental change to the content and 
structure of documents,” and the first deliverable of the SC was to 
be "a draft specification for change tracking, including Relax NG 
schema." So I’m assuming that this is still our top priority, and 
not something that has already been handled for us by a private 
group prior to the creation of the SC.

I also recall this exchange between Cherie and Rob during the 
initial discussion of the scope of the SC:

Cherie:
    
The first purpose of any subcommittee created to do this work, 
      
however, should be to examine the all the practicable options 
available for creating robust change
    
tracking in ODF. That includes not simply looking at the DeltaXML 
      
proposal and massaging it, but also looking at other alternatives 
including reworking the existing
    
ODF change tracking (as some TC members have suggested), looking 
      
into change tracking methods used in other standards, and starting 
from scratch to create a
    
change tracking that is targeted  to the ODF standard and focused 
      
on the business needs of ODF users.

Rob:
    
DeltaXML is not mentioned at all in the proposal [for creation of 
      
this SC].  It talks of the need to "investigate opportunities and 
draft enhancements to ODF".
    
So I think that is sufficiently open to allow consideration of all 
      
options.
  
I continue to believe that the proposal this SC develops should be 
something created in response to the requirements the SC gathers. 
You said “even if we would have a complete list of requirements, at 
some point in time someone would have to start with an initial  
proposal," and I agree, but I think the development of such a 
proposal should take place after the requirements-gathering phase, 
and not before.

Regards,
Doug

From: Michael Brauer [mailto:michael.brauer@oracle.com] 
Sent: Monday, January 24, 2011 5:38 AM
To: Doug Mahugh
Cc: Tristan Mitchell; office-collab@lists.oasis-open.org
Subject: Re: [office-collab] Wiki updates: Requirements and Use Cases

Hi Doug,

On 21.01.2011 21:28, Doug Mahugh wrote: 
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. 


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


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 
    

  

-- 

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