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

[Shawn <sgrover@open2space.com>]

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

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

If you consider "making the NEXT version" the final one, or the 
definitive version, well, you might have a point - you need to take 
time, care, and lots of consideration to get something "perfect".  But 
the technology industry is moving too fast.  Perfect is near impossible, 
or transitory.  I'd rather simply accept that there will be another 
version of the standard down the road.  Our comments/findings on the 
CURRENT standard will make THAT standard better. And related 
applications.  (hopefully)

To me, this process provides the best of all cases.  Review is done. 
Standard improves.  Applications improve.  The public has more faith in 
conformance/interoperability. Etc.  But we have not delayed anything, 
and we did not get hung up on what "might" be.  Rather we focused on 
what "is".

My thoughts.

Shawn