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


My recollection of the proposal for the time-based approach was specifically to support idea that features would be implemented and the presence of stable CSDs would provide time for provisional implementations.  I am also in favor of approved supplements.

There are ways to stage provisional implementations to avoid conflicts and premature adoption.

For example, I have proposed extensions to protection-key provisions.  I made sure that it is an extension.

If I were involved in a provisional implementation, I would not use the identifiers introduced in the draft.  Instead, I would use a private-agreement identifier for trial use in a producer.  In the consumer, I would design the code to accept the private-agreement identifier (URI, attribute value, attribute name, element name) as well as the one specified in the CSD.  That way, I don't have to rev a release in order to move over to the official, standardized provision.  Of course, the provisional implementation is in ODF 1.2 documents, not ODF 1.3 ones, and throwing the switch to emit ODF 1.3 documents is a different matter.  For ODF 1.3 documents, one presumably cannot continue to produce the provisional case.

If the CSD provision ended up in the final specification (however that is done modularly) and there is no breaking change to it, everything just works out over time.  If there are breaking changes, I would expect that the approved form would use *different* identifiers so they are not misunderstood as equivalent to the trial use based on the earlier CSD provisions.

This is also an admirable practice that should be used whenever breaking changes are made to an existing provision too.  We have the opportunity to be more careful about that for ODF 1.3.

 - Dennis

-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
Sent: Saturday, July 23, 2011 12:09
To: office@lists.oasis-open.org
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

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



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