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


Hello Rob,


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

Best,
Charles.


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