OASIS Open Document Format for Office Applications (OpenDocument) TC

For discussion on the list. I know that many/most of us are heads-down on 
the ODF 1.2 endgame right now.  But I have heard from a number of 
individuals who are interested in starting work immediately to refine the 
DeltaXML change tracking proposal.  Since they are willing to join the TC, 
and this is a priority area for them, I think it would be a good idea to 
create a SC where this work could be advanced at its own pace, 
independently of our work on ODF 1.2.

Also, in order to avoid a proliferation of subcommittees, I've written the 
scope broadly enough to encompass some adjacent areas within the "advanced 
collaboration" sphere, especially areas that I know are of interest to one 
or more members of the TC.

I am willing to chair the SC, but I also would be more than happy to yield 
to a suitable alternative volunteer.

-Rob

---------------------------------------------------------------------------------------

Name
----
Advanced Document Collaboration Subcommittee (slug = office-collab)


Statement of Purpose
--------------------

Many ODF documents do not involve collaboration.  They are created by a 
single user, edited by a single user, and then perhaps presented or shared 
with multiple users, or maybe even just converted to PDF for distribution.

However, collaboration-based document scenarios are also common, including 
review and comment and change tracking as well as emerging work in 
real-time collaborative editing, in-context document collaboration, 
persistence of structured document fragments, and so on.

In order to bring together technical experts in these areas, and for them 
to evaluate trends, investigate opportunities and draft enhancements to 
ODF in these areas, we are proposing a dedicated subcommittee for this 
topic.

The initial priority for the Subcommittee will be change tracking. 
Reliable and user friendly revision management is critical for 
professional document workflows in corporate and public sector 
environments, and as such an important feature of Open Document Format. 
The SC is asked to prepare a draft specification of a markup vocabulary 
that can accurately describe any incremental change to the content and 
structure of documents - typically made in multiple editing sessions by 
different authors.


List of Deliverables
--------------------

1. A draft specification for change tracking, including Relax NG schema's 
(target Jan 31th, 2011)

2. A description on how to apply change tracking markup to the various 
versions of the OpenDocument Format (ODF) as a host format.

3. A set of test documents that will allow implementers to validate their 
implementations.

4. A document that describes in detail how the existing change tracking 
mechanism in ODF can be converted to the new markup.

5. Other proposals, draft specifications and in-scope work related to the 
subcommittee's Purpose.


Chair
-----

TBD

Rob,

Just came up for air and saw your post.

Do you think the charter should mention the role of meta-data in
revisions?

Just so they can tend to that while working on pure change tracking sort
of issues? 

And that might attract people interested in the annotation side of
document work as well. 

Don't want it to get too broad but thought that might be a useful
addition.

Hope you are having a great day!

Patrick

On Thu, 2010-11-04 at 12:24 -0400, robert_weir@us.ibm.com wrote:
> For discussion on the list. I know that many/most of us are heads-down on 
> the ODF 1.2 endgame right now.  But I have heard from a number of 
> individuals who are interested in starting work immediately to refine the 
> DeltaXML change tracking proposal.  Since they are willing to join the TC, 
> and this is a priority area for them, I think it would be a good idea to 
> create a SC where this work could be advanced at its own pace, 
> independently of our work on ODF 1.2.
> 
> Also, in order to avoid a proliferation of subcommittees, I've written the 
> scope broadly enough to encompass some adjacent areas within the "advanced 
> collaboration" sphere, especially areas that I know are of interest to one 
> or more members of the TC.
> 
> I am willing to chair the SC, but I also would be more than happy to yield 
> to a suitable alternative volunteer.
> 
> -Rob
> 
> ---------------------------------------------------------------------------------------
> 
> Name
> ----
> Advanced Document Collaboration Subcommittee (slug = office-collab)
> 
> 
> Statement of Purpose
> --------------------
> 
> Many ODF documents do not involve collaboration.  They are created by a 
> single user, edited by a single user, and then perhaps presented or shared 
> with multiple users, or maybe even just converted to PDF for distribution.
> 
> However, collaboration-based document scenarios are also common, including 
> review and comment and change tracking as well as emerging work in 
> real-time collaborative editing, in-context document collaboration, 
> persistence of structured document fragments, and so on.
> 
> In order to bring together technical experts in these areas, and for them 
> to evaluate trends, investigate opportunities and draft enhancements to 
> ODF in these areas, we are proposing a dedicated subcommittee for this 
> topic.
> 
> The initial priority for the Subcommittee will be change tracking. 
> Reliable and user friendly revision management is critical for 
> professional document workflows in corporate and public sector 
> environments, and as such an important feature of Open Document Format. 
> The SC is asked to prepare a draft specification of a markup vocabulary 
> that can accurately describe any incremental change to the content and 
> structure of documents - typically made in multiple editing sessions by 
> different authors.
> 
> 
> List of Deliverables
> --------------------
> 
> 1. A draft specification for change tracking, including Relax NG schema's 
> (target Jan 31th, 2011)
> 
> 2. A description on how to apply change tracking markup to the various 
> versions of the OpenDocument Format (ODF) as a host format.
> 
> 3. A set of test documents that will allow implementers to validate their 
> implementations.
> 
> 4. A document that describes in detail how the existing change tracking 
> mechanism in ODF can be converted to the new markup.
> 
> 5. Other proposals, draft specifications and in-scope work related to the 
> subcommittee's Purpose.
> 
> 
> Chair
> -----
> 
> TBD
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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 
> 

Patrick Durusau 

Aren't we jumping the gun with forming a subcommittee to address a
specific new feature group for ODF-Next. Shouldn't we first finish
ODF1.2 and then see which feature suggestions for the next ODF version
are suggested by TC members?

Andreas

 
-- 
Andreas J. Guelzow 

Certainly, I would be jumping the gun if I stopped working on ODF 1.2 and 
started working on ODF-Next.  But we do have some new members, just 
joining now, who are not working on ODF 1.2, and are interested in getting 
a head-start on the changing tracking proposal.

And note, we created the Metadata SC and the Formula SC when we were only 
half-way through the ODF 1.1 work.  At that time as well, it was a way of 
taking advantage of the enthusiasm of new participants (like David 
Wheeler) while the rest of us finished up ODF 1.1 work, a release mainly 
focused on accessibility.

So I think there is some precedent for this.

But I certainly wouldn't want to presume to speak for the TC on what the 
contents of ODF-Next should be, at least not at this point.  But does 
anyone have any doubt whether change tracking should be a priority? 

-Rob

"Andreas J. Guelzow" 

On Thu, 2010-11-04 at 14:44 -0600, robert_weir@us.ibm.com wrote:
> But does 
> anyone have any doubt whether change tracking should be a priority?

Asked this way my answer would be "yes".

If you had asked:
" But does anyone have any doubt whether change tracking will be a
priority?"
I would have to answer "unfortunately, no".

Andreas


>  

As I commented in an earlier thread about change tracking, Microsoft is happy to help create a draft proposal for change tracking in ODF-Next. John Haug from my team would be a good fit here, and we're glad to get him involved in coordinating any contributions we can make in this area. 

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.

I am very concerned about the proposed timeline. While there may be new folks ready to work on it now, there are also likely to be folks still tied up with existing 1.2 work who want to contribute here. We also have the most holiday-heavy part of the year coming up between now and the proposed end date, January 31. It seems odd to rush something that is likely to be every bit as detailed as OpenFormula, perhaps even more so. I'm not suggesting another multi-year effort, but I am saying that the committee should take the time necessary to do good work rather than rushing through and taking the risk of turning out something that might end up being difficult to adequately implement, untestable, or given to less than decent interoperability. Rather than having a deadline of January 31, I'd suggest May 31 or June 30. That keeps the timeframe short, but gives a few more months of quality working time for the subcommittee. If there is an unspoken concern here that there needs to be work in progress to show JTC1 SC34, then having a subcommittee working on change tracking with a deadline of May or June 2011 should satisfy that concern.

My last concern about the proposal is the nebulous "other" collaboration scenarios. Change tracking is an issue that's been well understood as a problem and received a lot of discussion. By contrast, there has been no substantive discussion at all of other ODF-Next features by the ODF TC since August, and no activity in the subcommittee that was formed expressly to discuss ODF-Next. If the idea is to get the change tracking proposal done in a timely manner, why clutter the subcommittee with other unspecified work on a short deadline? If this subcommittee is going to be formed, let's make it about change tracking.

To that end, I'd suggest revising the proposal as following:

Name
----
Advanced Document Collaboration Subcommittee (slug = office-track)


Statement of Purpose
--------------------

Many ODF documents do not involve change tracking.  They are created by a single user, edited by a single user, and then perhaps presented or shared with multiple users, or maybe even just converted to PDF for distribution.

However, collaboration-based document scenarios are also common, and change tracking has emerged as one of the most-requested areas of ODF improvement. In order to bring together technical experts in this area, and for them to evaluate trends, investigate opportunities and draft enhancements to ODF in these area, we are proposing a dedicated subcommittee for this topic.

The purpose for the Subcommittee will be change tracking. 
Reliable and user friendly revision management is critical for professional document workflows in corporate and public sector environments, and as such an important feature of Open Document Format. 
The SC is asked to prepare a draft specification of a markup vocabulary that can accurately describe any incremental change to the content and structure of documents - typically made in multiple editing sessions by different authors.


List of Deliverables
--------------------
0. A design draft detailing the possible solutions for change tracking in ODF-Next (target: January 31, 2011)

1. A draft specification for change tracking, including Relax NG schema's (target June 30th, 2011)

2. A description on how to apply change tracking markup to the various versions of the OpenDocument Format (ODF) as a host format.

3. A set of test documents that will allow implementers to validate their implementations.

4. A document that describes in detail how the existing change tracking mechanism in ODF can be converted to the new markup.


Cherie Ekholm
Senior Standards Professional
Microsoft Office Standards & Interoperability



                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
Sent: Thursday, November 04, 2010 1:45 PM
To: Andreas J. Guelzow
Cc: office@lists.oasis-open.org
Subject: Re: [office] Proposal for Advanced Document Collaboration Subcommittee

Certainly, I would be jumping the gun if I stopped working on ODF 1.2 and started working on ODF-Next.  But we do have some new members, just joining now, who are not working on ODF 1.2, and are interested in getting a head-start on the changing tracking proposal.

And note, we created the Metadata SC and the Formula SC when we were only half-way through the ODF 1.1 work.  At that time as well, it was a way of taking advantage of the enthusiasm of new participants (like David
Wheeler) while the rest of us finished up ODF 1.1 work, a release mainly focused on accessibility.

So I think there is some precedent for this.

But I certainly wouldn't want to presume to speak for the TC on what the contents of ODF-Next should be, at least not at this point.  But does anyone have any doubt whether change tracking should be a priority? 

-Rob

"Andreas J. Guelzow" 

Cherie Ekholm 

It is correct, Rob, that you did not mention DeltaXML in the proposal. DeltaXML was, however, the only option you mentioned in introducing the proposal, which is why I suggested clarifying that multiple options will be looked at and the one that best suits where ODF-Next should go will be what is chosen. 

While John will be working on this from our side, it's quite possible that there are others who are still currently working on 1.2 who will also want to contribute. That was, in part, my reason for suggesting a different deadline. The other reason was the holiday schedule as I noted in the earlier mail. I have no objection to a new SC being set up to overlap the end of 1.2 work. I simply wanted to make sure that a feature like change tracking, which, as you note in your email and others, overlaps many other areas of ODF, doesn't get short shrift from an SC trying to hit a deadline with an artificially short timeline. While it may be true that this committee doesn't often hit deadlines, that doesn't mean the participants don't try, and when the deadlines are put in proposals, that gives them a bit more weight, or should.

I don't believe I do misunderstand the purpose of the Requirements subcommittee. I also don't think I misstated that the work of that committee hasn't been done. It would be great to get the discussions of those other items going on that SC so that they could be categorized, prioritized and some goals other than change tracking could be created. The collaboration ideas are interesting. Our discussions of a shorter timeline or a staggered timeline should be part of the consideration in thinking about those issues. 

No, you can't ignore many of the collaboration items you list when defining change tracking. However, you also don't need to define any new work to get change tracking right - you only need to account for the possibility of adding various types of new features. That said, I'm not wedded to the idea of separating those from the change tracking SC, but I would like to see them defined by the Requirements SC and voted on by the TC first. It seems like we've set up the Requirements SC to do the work of evaluating and recommending what should go into ODF-Next, so we should use that SC rather than having other SCs duplicate that work. If we include additional work beyond change tracking in this new SC, that would should be defined before that new SC is created.

John is not currently a member of the TC. He will be joining this week.

Cherie
________________________________________
From: robert_weir@us.ibm.com [robert_weir@us.ibm.com]
Sent: Saturday, November 06, 2010 12:24 PM
To: Cherie Ekholm
Cc: John Haug; office@lists.oasis-open.org
Subject: RE: [office] Proposal for Advanced Document Collaboration Subcommittee

Cherie Ekholm 

On 8 November 2010 07:43, Cherie Ekholm 

On 8 November 2010 07:43, Cherie Ekholm 

Bob Jolliffe 

Rob

On 9 November 2010 00:50,  

Bob Jolliffe 

Bob Jolliffe 

Rob

On 9 November 2010 00:50,  

Bob Jolliffe 

On Saturday, November 06, 2010 20:24:22 pm robert_weir@us.ibm.com wrote:
> An example::  Real-time collaborative editing needs to track changes as
> well, because it sends changes over the wire.  So it would be beneficial
> if we design change tracking in a way that this would work naturally.  One
> could, as an example, decide to store complete versions of the changed
> document, and rely on runtime intelligence of the editor to generate,
> on-the-fly the change tracks.  This would satisfy the core change tracking
> needs perfectly.  But it would not be something that one could easily use
> for real-time collaborative editing and similar scenarios.  So I'd argue
> that we want to be discussing these common technical concerns together,
> not separately, since the choice of the exact change tracking solution has
> a large impact on how some other scenarios are done, and how hard it will
> be for ODF implementations to support these and related scenarios.
> 
> Some commonalities (not exhaustive) are:
> 
> 1) the need to identify content at a sub-document level.
> 
> 2) the need to identify the styles relevant to content at a sub-document
> level
> 
> 3) the need to identify metadata relevant to content at a sub-document
> level
> 
> 4) the need to idetify extension content relevent to content at a
> sub-document level
> 
> 5) The need to associate content, styles, metadata and extensions at a
> sub-document level
> 
> 6) The need to package and exchange and merge coherent sub-document
> fragments
> 
> If these discussions no not occur together, among the same parties, then
> the overall solution will likely be needless complex and hard to
> implement.

Change tracking (CT) is very comparable to real-time collaborative editing 
(RTCE). The biggest difference from a user point of view is the time between 
edits and the possible visibility of other people's caret in your document.

Etherpad, Google Docs and Abiword and probably others have already implement 
RTCE. Yet these programs cannot collaborate amongst each other. I would like 
the subcommittee to have a scope that encompasses both forms of collaborative 
editing.

In RTCE, CT would play the role of visualizing a differences that have come 
from concurrent edits in  a document and cannot be merged by one of the merge 
algorithms. In a nutshell, CT is RTCE without the automatic merging of changes 
in live documents.

I agree that DeltaXML is certainly not the only option under consideration for 
this use case. There are two implementations of it underway and these may help 
the committee in determining if DeltaXML would fit with the desired use-cases. 
As such this subcommittee would advice or prepare information for the ODF-Next 
committee on this part of the functionality.

Tasking the SC to come up with a sanctioned protocol for RTCE now would go too 
far, but I do think the existing protocols and their compatibility with TC 
should be considered and combination scenarios made explicit in the 
recommendations of the SC so that future effort- and specification duplication 
can be avoided.

Cheers,
Jos

  
  


Jos,


I have more experience of Change Tracking (CT) than real-time
collaborative editing (RTCE) but I have always understood them to be
different problems. That said, they are related and I am OK for RTCE to
be taken into account in the work of the SC. I am in agreement with you
that it should not be a requirement that the RTCE protocol problem is
solved, rather that RTCE be considered in the CT solution.


Robin



Jos van den Oever wrote:
201011081728.01292.jos@vandenoever.info" type="cite">
  
On Saturday, November 06, 2010 20:24:22 pm robert_weir@us.ibm.com wrote:
  
  

    
An example::  Real-time collaborative editing needs to track changes as
well, because it sends changes over the wire.  So it would be beneficial
if we design change tracking in a way that this would work naturally.  One
could, as an example, decide to store complete versions of the changed
document, and rely on runtime intelligence of the editor to generate,
on-the-fly the change tracks.  This would satisfy the core change tracking
needs perfectly.  But it would not be something that one could easily use
for real-time collaborative editing and similar scenarios.  So I'd argue
that we want to be discussing these common technical concerns together,
not separately, since the choice of the exact change tracking solution has
a large impact on how some other scenarios are done, and how hard it will
be for ODF implementations to support these and related scenarios.

Some commonalities (not exhaustive) are:

1) the need to identify content at a sub-document level.

2) the need to identify the styles relevant to content at a sub-document
level

3) the need to identify metadata relevant to content at a sub-document
level

4) the need to idetify extension content relevent to content at a
sub-document level

5) The need to associate content, styles, metadata and extensions at a
sub-document level

6) The need to package and exchange and merge coherent sub-document
fragments

If these discussions no not occur together, among the same parties, then
the overall solution will likely be needless complex and hard to
implement.
    
  
  

Change tracking (CT) is very comparable to real-time collaborative editing 
(RTCE). The biggest difference from a user point of view is the time between 
edits and the possible visibility of other people's caret in your document.

Etherpad, Google Docs and Abiword and probably others have already implement 
RTCE. Yet these programs cannot collaborate amongst each other. I would like 
the subcommittee to have a scope that encompasses both forms of collaborative 
editing.

In RTCE, CT would play the role of visualizing a differences that have come 
from concurrent edits in  a document and cannot be merged by one of the merge 
algorithms. In a nutshell, CT is RTCE without the automatic merging of changes 
in live documents.

I agree that DeltaXML is certainly not the only option under consideration for 
this use case. There are two implementations of it underway and these may help 
the committee in determining if DeltaXML would fit with the desired use-cases. 
As such this subcommittee would advice or prepare information for the ODF-Next 
committee on this part of the functionality.

Tasking the SC to come up with a sanctioned protocol for RTCE now would go too 
far, but I do think the existing protocols and their compatibility with TC 
should be considered and combination scenarios made explicit in the 
recommendations of the SC so that future effort- and specification duplication 
can be avoided.

Cheers,
Jos



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

  



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