OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

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

Subject: Re: [oiic-formation-discuss] ODF version in the charter, was Re: [oiic-formation-discuss] My perspective. display perferct?

On Wed, Jul 2, 2008 at 8:34 PM, Shawn <sgrover@open2space.com> wrote:
> Peter Dolding wrote:
>> Draft usage is normally a special loop hole for TC operation.   Its
>> only and I repeat only for disputed sections of the standard.
> And we know how often EVERY corporation/organization follows the letter of
> the law/standard/etc.  :)
>> Sections as a TC test create you can see that you cannot create a
>> valid test case that protects compatibility between implementations.
>> Like a section that allows applications to add a stack of undocumented
>> information that can be abused.   Now if what information can be there
>> is defined in the draft you test for what is in the draft and give
>> warning messages on anything not so far in the next draft of ODF.
> Here, you nicely describe what a test is.  Pass if the info has been
> documented or allowed for in the standard.  Fail if it has not.  But at this
> stage, it doesn't really matter if it is the draft version of the standard,
> or the official version.  It's just a pass/fail of a test.
> But suppose for a moment that a Draft does not address this situation. So
> now the OIIC process needs to fail this.  But then if the draft later
> changes to allow the situation, then the OIIC process needs to change to
> pass this AND any related items that were also affected.  I don't know about
> you, but I'd rather not try to hit this moving target.  I'd much rather wait
> until things stabilize (i.e. an "official", non-draft version).
Detecting that the section is in the draft and warning the implementer
about that there keys are not there or are there and they need to pay
close attention to the standard now.  Or risk failing the next lot of
tests around prevents complaints when we do drop the hammers on them
and fail them for them.  Ie you were warned here that this could be a
issue you did nothing its your problem.

Really even if the draft still does not address it all.

I should have said warning messages on all the stuff from the draft
that has been referred to due to a currently existing loop hole that
is exploited.

Changes in the draft does not change the warning.  Only 1 reference
look to the draft has to be done until its released.
>> Of course you cannot fail applications on a draft alone.  We are here
>> to help implementers warning them of trouble coming is fine.
> I think it would be fairly obvious.  If the developer does something that is
> NOT in the standard, chances are they will run into trouble.  If they NEED
> to do something that isn't in the standard... well, that's a conversation
> for the ODF TC, not the OIIC TC.
>> Locking out all draft usage reduces the quality of our overall testing.
> -1 (simply meaning I disagree with this particular statement)
> A draft eventually stabilizes and becomes the next version of the standard.
>  At that point, the OIIC TC has something stable to work with.  The OIIC
> process is initiated, and completed.  And then the findings of the OIIC can
> be applied to the NEXT draft of the standard (if needed), or the NEXT
> version of the application.  The quality of testing does not suffer at all.
>  Rather the quality of the standard AND the testing improve with each
> iteration.
Reduces the quality of our overall testing because we have more
implementer complaining and risk them not doing the testing they

Its a fine line between being standard only and being useful.   If we
are useful to implementers to prevent them running into upcoming
standard changes the more likely testing will be run to find out if
there are any issues they really need to be aware of due to the useful

Three levels of test.  Pass Fail and Warn like all computer compliers.
 Warn are areas that could cause cross implementation issues yet are
not forbid by standard at this stage.   Warn could be spitting out a
lot of places on ODF at moment "sorry what this <whatever> is not
documented as in use by anyone another implementation could interface
with this key incorrectly".

Really the Warn message should exist either way.   If its in Draft
standard referred to so implementer knows that some work is being done
in that section its more of a niceness.   Warn messages most likely
will turn into future Pass or Fail messages.  Also what we get
warnings on can be feedback into the standard development process.
The feedback loop of tc to standard body on what implementers are upto
in the real world not just what they are saying they are upto.  Yes it
can cause a few blow ups when implementers are doing different to what
they are telling the standard body..

Peter Dolding

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