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


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


-Rob


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