RE: [office] Proposal for Advanced Document Collaboration Subcommittee

[robert_weir@us.ibm.com]

Cherie Ekholm <cheriee@exchange.microsoft.com> wrote on 11/05/2010 
05:02:23 PM:
> 
> RE: [office] Proposal for Advanced Document Collaboration Subcommittee
> 
> 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. 
>

Great.  More help is always welcome.
 
> 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.
>

DeltaXML is not mentioned at all in the proposal.  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 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.
> 

The help you were proposing was from John Haug, right?  So far as I can 
tell he is not currently working on ODF 1.2 items?  He certainly is not a 
member of the TC.  And the new members joining are also not working on ODF 
1.2 items.

You mention OpenFormula, but in that case, we did exactly the same thing. 
We created the subcommittee for interested members (mainly new members) to 
make progress while the rest of us were "still tied up" with ODF 1.1 work. 
 The fact that change tracking may take longer than expected is an 
argument for starting sooner, not for delaying.

But I'd be happy to remove the suggested delivery date, since a date is 
not required to form a subcomittee.  As far as I can tell, members of this 
TC don't really pay much attention to deadlines.. ;-)

And remember, a SC only can only create working drafts.  It has no ability 
to approve work at a Committee Draft or higher level.  In the end it is up 
to the full ODF TC to review and advance suitable drafts.  The main effect 
of a SC is to partition off a mailing list for specialized discussions, so 
the ODF TC is not overloaded with conversations that not all TC members 
are interested in, or for conversations that are not relevant for the 
current TC deliverable.

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

The proposed deadline was only for the change tracking draft.  I think 
that was sufficiently clear by the description "A draft specification for 
change tracking, including Relax NG schema's".  No other deliverable had a 
deadline proposed.

Or was there something that you see that suggests the SC would try to 
finish other items on a "short deadline"?

As for the other items, there in fact has been a good amount of 
discussion, on and off the list.  We have members interested in pursuing 
these items.  But I'll let them speak for themselves.

Finally, I think you misunderstand the purpose of the ODF-Next SC 
(formally called the "Requirement" SC).  It is not to do technical 
discussion or to draft specifications for ODF-Next.  The Requirements SC 
has the purpose of "to gather requirements, to categorize these 
requirements by theme, to prioritize these requirements, and to submit a 
report to the ODF TC on a recommended set of work items for the next major 
version of ODF".  I wish it had made better program on these goals, but 
I'm not letting that block progress that other TC members wish to make in 
specific areas.

I'd like to avoid proliferation of subcommittees by creating many of them, 
especially where the technical requirements have such a degree over 
overlap.  For example, consider that change tracking, real time 
collaborative editing, and similar scenarios have overlapping concerns.

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.

Regards,

-Rob