Hi Florian,
regarding an ODF 1.0 errata:
When approving an errata, section 3.5 of the TC Process[1] requires that
we are
"Confirming by Full Majority Vote that the proposed corrections do not
constitute a Substantive Change."
where "substantive changes" are defined in section 1 as follows:
""Substantive Change" is a change to a specification that would require
a compliant application or implementation to be modified or rewritten in
order to remain compliant.".
So, regardless whether we maybe should have allowed the attribute
combination in question already in ODF 1.0, we must include this
combination only if we believe that this does not require that any
existing implementation is changed. If we believe that existing
implementations must be changed, then we must not include the new
combination into an ODF 1.0 errata.
Best regards
Michael
[1] http://www.oasis-open.org/committees/process.php
Florian Reuter wrote:
> Hi,
>
> I think the right thing to do is to:
> a) add the two "X" to ODF1.2
> b) add the two missing "X" to the ODF1.0/1.1 erata, since this is not a new feature, but an error in ODF1.0/1.1
> c) define what should happen if the combination is not valid in ODF1.2
> d) add an erata for ODF1.0/ODF1.1 to define what should happen if the combination is not valid
>
> Then we should start the more general discussion of what an application should do if it finds something "undefined",
> because: Whats the point of having a specification which has undefined behaviour.
>
> What we should *not* do IMHO is: Add the two "X" to ODF1.2 and leave it "undefined" for ODF1.0/1.1, since I believe its
> not a new feature in ODF1.2 but rather an error in ODF1.0/ODF1.1.
>
> Additionally we should spend at least a second reviewing the other combinations. It would be bad if we would find out in
> a couple of days that we need to chance it again..
>
> ~Florian
>
>
>>>> Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems