Re: [office] Re: Towards a more modular ODF?

[robert_weir@us.ibm.com]

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.


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

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