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] Towards a more modular ODF


"Charles-H. Schulz" <charles-h.schulz@arsaperta.com> wrote on 07/24/2011 
10:14:58 AM:
> 
> 
> Le 23/07/2011 21:09, robert_weir@us.ibm.com a écrit :
> > "Andreas J. Guelzow" <andreas.guelzow@concordia.ab.ca> wrote on 
07/23/2011 
> > 02:38:55 PM:
> > 
> >> From: "Andreas J. Guelzow" <andreas.guelzow@concordia.ab.ca>
> >> To: <office@lists.oasis-open.org>
> >> Date: 07/23/2011 02:40 PM
> >> Subject: Re: [office] Towards a more modular ODF
> >>
> >> On Sat, 2011-07-23 at 11:39 -0600, robert_weir@us.ibm.com wrote:
> >>
> >>> One idea that I was brought up at the Plugfest was the idea of 
making 
> > ODF 
> >>> more modular,  meaning defining formal modules at the schema and 
> >>> specification level, and to standardize these modules independently, 

> > at 
> >>> whatever pace they naturally evolve.  We're partially down that road 

> >>> already with the three "parts" of ODF 1.2.  But since these are part 

> > of 
> >>> the same OASIS standard, we cannot evolve them at different paces. 
The 
> > 
> >>> rigidity of this monolithic approach impacts our work in OASIS and 
in 
> > ISO.
> >>>
> >> (...)
> >>>
> >>> I'd be interested in the TC's thoughts on this.  Is this worth 
aiming 
> > for? 
> >>>  Is it doable?  Or is it "boiling the ocean"? 
> >>
> >> I believe that the primary effect of restructuring the ODF standard 
once
> >> again would primarily result in a delay of ODF 1.3, 1.4 etc without 
any
> >> real gain. I see no reason why we can't work inside more or less 
defined
> >> modules but retaining a fixed release schedule and a monolithic
> >> standard.
> >>
> > 
> > I should mention also a related issue.  This is the problem of our 
> > standards cycle versus product cycles.  As you know, many open source 
> > projects have a "release early/release often" philosophy.  For 
example, 
> > LibreOffice seems to be dropping a release every month.  Other 
products do 
> > a release every few months.  Even commercial products have a cadence, 
> > e.g., Microsoft Office every 3 years or so.  If the standards cycle is 

> > much longer than a product's release cycle then we have the issue of 
> > features from specification drafts making it into released products. 
We 
> > know that this creates a window of confusion where documents with 
> > non-standardized features are being exchanged.  At the same time some 
open 
> > source products are implementing draft features, other vendors, like 
> > Microsoft, prefer to wait for the more stable published standards. 
There 
> > are several ways of addressing this constellation of issues, but one 
way 
> > to mitigate the effect is to reduce the time between a feature being 
> > specified and the time when the standard is published.  A more modular 

> > approach could do that. 
> > 
> > 
> >> As modules (eg. change tracking,...) reach a release ready state they
> >> can be inserted/incorporated into the monolithic standard and 
released
> >> as part of the next ODF version according to schedule. If a module 
isn't
> >> ready it would just not be incorporated for a release. 
> >>
> > 
> > That would work, but would what does it mean for implementors.  If 
some 
> > implement it, according to the draft specification, while others wait 
for 
> > final approval and publication, then that introduces other issues.
> > 
> 
> Short comment on the point above: that's something we (we, as in this
> ODF TC) cannot really control anyway. But back to the initial question:
> while we indeed all agree that 4 years are a bit too long, I wonder
> whether this is an issue that calls for more standards development
> resources or if it can work well based on your proposal. I have no
> strong opinion about this; on the one hand I feel this would cause more
> confusion, on the other I could see a "modular ODF specification being
> submitted to ISO in an almost incremental way" working smoothly because
> it would allow most of the TC to work on specific modules and refocusing
> on others when needed.
> I'd say that the real issue is to be able to bring and integrate more
> active developers to the TC; but I realize that I'm not entirely
> answering your question :)
> 

It depends on where you put the resources.  In a monolithic standard, the 
entire work progresses at the speed of the slowest task. In a modular 
approach, the parts progress at their own speed, so the easiest modules, 
or the modules with the most volunteers on them, progress the fastest. You 
can make the monolithic approach faster by adding resources, but only by 
adding resources to the slowest moving parts.  Or at least the slowest 
moving parts for which there is a consensus that the must be part of the 
specification revision.

-Rob


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