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] ODF 1.2 Single-Level Conformance and Floor << Ceiling Already

I must correct this flawed analysis.

OASIS is very clear about what kind of changes can be made to revisions of 
a standard.  In particular, Approved Errata may not contain Substantive 
Changes, where "Substantive Change" is defined as "a change to a 
specification that would require a compliant application or implementation 
to be modified or rewritten in order to remain compliant".

However, there is absolutely no prohibition against making a Substantive 
Change in a new version of an OASIS standard.  This is 100% legitimate 
from OASIS, ODF TC and even ISO rules.  (Heck, ISO would even allow 
breaking changes in Corrigenda, so they are even more permissive in this 

So the only "promise" is with regards to the ODF 1.0 and ODF 1.1 
standards.  OASIS will not allow us to change conformance there.  But we 
have full ability, under the rules, to make any change we wish in ODF 1.2. 

Now, if the ODF TC wishes to adopt a Standing Rule that sets out some 
additional guidelines for what kinds of changes will be made in what kinds 
of release, a major/minor scheme, a schedule of deprecation, etc., it has 
full authority to do so, provided it doesn't contradict OASIS rules.  But 
unless there is consensus to adopt such standing rules, we are 
unrestricted in how we change conformance in ODF 1.2, so long as the 
clause itself otherwise meets OASIS requirements. 

I want to make sure that this process question is clear to every TC 


"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 02/03/2009 
11:46:19 PM:
> I take this as a promise:
>    "Documents that conform to the OpenDocument specification
>     may contain elements and attributes not specified within
>     the OpenDocument schema. Such elements and attributes must
>     not be part of a namespace that is defined within this 
>     specification and are called foreign elements and attributes.
>     "Conforming applications either shall read documents that 
>     are valid against the OpenDocument schema if all foreign 
>     elements and attributes are removed before validation takes
>     place, or shall write documents that are valid against the 
>     OpenDocument schema if all foreign elements and attributes 
>     are removed before validation takes place.
>     "Conforming applications that read and write documents may 
>     preserve foreign elements and attributes."
> I do not see any reason to break a promise when there has been no 
> with it and it has been through three rounds of standardization, two at
> OASIS and one at ISO/IEC JTC1.  I can't imagine that this provision 
> to be noticed.  Also, considering the work there is to make ODF 1.2 as 
> as an ODF 1.2 that there can be with the means available, I see fussing 
> this as unnecessary breaking of something that does not appear to need
> fixing, especially since making strictly-conformant documents part of 
> normative specification provides a solid place for procurement
> specifications and selection of products by those who are now allergic 
> this provision.
> This promise has been on the books for a healthy period of time.  I 
> know what led to its being made, but it has been noteworthy all along. 
> far as I am concerned, it has neither helped nor hindered the 
achievement of
> interoperability among ODF implementations.  But it is a promise. 
> Whatever reconsideration that seems to be on the current agenda, I must
> assume this promise was not made lightly and that we should avoid its
> revocation without serious cause.  I do not believe there is any such 
> in evidence and we should let the precedent stand.
> I also expect that any suspected perpetrations under this provision will 
> noticed and objected to in broad public forums and any promulgation of
> specific foreign elements-attributes-values will receive careful 

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