[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Re: Towards a more modular ODF?
Hello Rob, Le 25 juil. 2011 à 14:59, robert_weir@us.ibm.com a écrit : > Patrick Durusau <patrick@durusau.net> wrote on 07/25/2011 06:35:13 AM: > >> From: Patrick Durusau <patrick@durusau.net> >> To: ODF TC List <office@lists.oasis-open.org> >> Date: 07/25/2011 06:38 AM >> Subject: [office] Re: Towards a more modular ODF? >> >> Rob, >> >> As you know, I have no problems with the general idea of a more modular >> ODF, particularly when it comes to following other standards as part of >> becoming more modular. >> >> And I think everyone would like to see the next version of ODF, whether >> an ODF 1.3 or ODF-Next, quicker than we reached ODF 1.2. >> >> But before we debate the merits of being more modular, which would take >> in the concerns about dependencies, where to make divisions, how that >> impacts the standards process (do we have >> committee-specification-draft-ODF-part-20?) and other concerns, >> shouldn't we ask if being more or less modular is really the problem? >> > > I'm not suggesting that there is "one problem" only, with "one solution". > Clearly, this is complex. > >> That is are we assuming more modular = greater speed and less modular = >> less speed? >> >> I don't see any evidence for either proposition at this point. >> > > > For example, with ODF 1.2, OpenFormula. It had an early start and could > easily have been delivered as a "module" in 2008 or 2009. We had the > resources and the draft spec. But we had to wait for the rest of ODF 1.2 > to catch up. Yes, in the end, OpenFormula took just as long as everything > else in ODF 1.2, but this was largely a case of a task taking all > available time allowed to it. If OpenFormula could have been delivered as > a standalone part for ODF 1.2, we would have done that work earlier. There > was certainly demand for it earlier. I'm in total agreement with you on that. > > >> For example, if being more modular would result in faster action, we >> should be able to point to some supposed separate "module" that is ready > >> to go to ODF 1.3 in the relatively near future. That is some part of ODF > >> whose progress is being retarded by the progress on some other part. >> >> Can you name one? I can't. >> > > For 1.3, security enhancements to the Packaging part is something that > could be delivered faster as a module than the 2-year proposed schedule > for ODF 1.3 as a whole. > > Change tracking is interesting example. In the generic form, it would > work well as a module. But in the form that extends our current approach, > it would cut across all modules. > > I'd also look at other multi-part standards, say ISO/IEC 29500. That > shows some of the benefits and liabilities of a modular approach. Where > they had cross-cutting changes, that went across several parts, it > exploded their work. But it also allowed finer-grained changes to a > single part. It is not a panacea. Some schemas and specs lend themselves > to modularization more than others. > > >> To give us a basis for deciding on more or less modularity, let me >> suggest an addition to our current roadmap. >> >> Instead of the current file a bug/proposal by date X methodology, as a >> TC let's develop a set of features for ODF 1.3/ODF-Next. >> >> So that like software projects, open source and otherwise, there is a >> set of targets and the question becomes one of tracking the resources >> that are devoted to meeting those targets. >> >> Then if some part of those targets begins to lag, we can either decide >> to devote more resources to it or try to separate it out so it doesn't >> delay the next release. >> >> Being more specific about that features we want for the next release may > >> (no guarantees) prompt others to devote resources to make those features > >> a reality. >> >> So, rather than take up your modular question now, my suggestion is that > >> we develop requirements for ODF 1.3/ODF-Next and start putting resources > >> along side those requirements. To put us more on a traditional software >> project basis. >> > > This is the question of having a time-boxed schedule or a feature-boxed > schedule. But we don't need to be so rigid about this either way. For > example, we can have time-boxed CSD's (every 6 months) while having the > final CSD (the eventual CS) be feature-boxed. I know this sounds expensive but how about "testing" this modular approach with the 1.3/1.4? We can always reassess this method in due time and revert back to the former one if necessary. I'm in favor of experimenting responsibly, so let's go ahead with a modular approach. :-) Best, Charles. > >> Hope you are at the start of a great week! >> >> Patrick >> >> -- >> Patrick Durusau >> patrick@durusau.net >> Chair, V1 - US TAG to JTC 1/SC 34 >> Convener, JTC 1/SC 34/WG 3 (Topic Maps) >> Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 >> Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) >> >> Another Word For It (blog): http://tm.durusau.net >> Homepage: http://www.durusau.net >> Twitter: patrickDurusau >> >> >> --------------------------------------------------------------------- >> 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 >> > > > --------------------------------------------------------------------- > 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 > Charles-H. Schulz Associé / Founding Partner, Ars Aperta
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]