Re: Towards a more modular ODF?

[Patrick Durusau <patrick@durusau.net>]

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?

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

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.

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