|robe...@us.ibm.com||Nov 4, 2010 9:20 am|
|Patrick Durusau||Nov 4, 2010 10:23 am|
|robe...@us.ibm.com||Nov 4, 2010 12:41 pm|
|Andreas J. Guelzow||Nov 4, 2010 1:17 pm|
|robe...@us.ibm.com||Nov 4, 2010 1:41 pm|
|Andreas J. Guelzow||Nov 4, 2010 1:51 pm|
|Cherie Ekholm||Nov 5, 2010 2:02 pm|
|robe...@us.ibm.com||Nov 6, 2010 12:20 pm|
|Cherie Ekholm||Nov 7, 2010 11:43 pm|
|Bob Jolliffe||Nov 8, 2010 1:37 am|
|Jos van den Oever||Nov 8, 2010 8:27 am|
|robe...@us.ibm.com||Nov 8, 2010 4:46 pm|
|Bob Jolliffe||Nov 9, 2010 8:38 am|
|robe...@us.ibm.com||Nov 9, 2010 9:06 am|
|Robin LaFontaine||Nov 16, 2010 2:10 am|
|Subject:||RE: [office] Proposal for Advanced Document Collaboration Subcommittee|
|Date:||Nov 6, 2010 12:20:44 pm|
Cherie Ekholm <cher...@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.
--------------------------------------------------------------------- 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