OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [office] Proposal for Advanced Document CollaborationSubcommittee


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]