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] Errata: Substantive Schema Change in 15.27.22?


"Andreas J. Guelzow" <aguelzow@math.concordia.ab.ca> wrote on 09/22/2008 
12:27:18 PM:
> 
> On Mon, 2008-09-22 at 09:52 -0400, robert_weir@us.ibm.com wrote:
> > 6) If any TC member knows of an ODF 1.0 implementation that would 
require 
> > modification in order to remain compliant with the proposed schema 
change, 
> > then they should speak up and say so.  We can always take this change 
out. 
> >  But, for example, if implementations generally do not implement this 
> > attribute, or if they silently have already made the spelling 
correction 
> > in their implementations, then this may not be a problem.  By having 
> > review on the TC as well as a 15-day public review, we give any 
> > implementation, whether represented on the TC or not, a fair 
opportunity 
> > to make this point.
> 
> What about ODF 1.0 implementations that do not exist yet? Is it
> understood that any new ODF 1.0 implementation will have no follow the
> errata?
> 

The OASIS's Approved Errata process says:  "Once approved, the Approved 
Errata shall be with the specification it corrects, in any publication of 
that specification."

Of course, it is possible that someone creates a new implementation based 
on a pre-errata version of ODF 1.0 that they downloaded a year ago. 

But the intent is:

1) The TC's work should be thoroughly reviewed before submitting it for 
approval at Committee Specification and above.
2) That, combined with the 60-day public review at Committee Specification 
stage, should find any critical technical flaws in the text.
3) Once approved as an OASIS Standard, we can fix minor (Not Substantive) 
errors via the Errata process
4) But if some more serious technical flaw is found, especially one that 
would require modifying existing conformant implementations,  it should be 
fixed in a new version of the standard.

Note that a new version does not necessarily mean ODF 1.2.  If we found a 
set of critical technical errors in ODF 1.0, we could always make an ODF 
1.01 version and send that through the approval process.  I'm not 
recommending this, but that is the route for dealing with changes that 
impact conformance.


-Rob





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