Re: [oiic-formation-discuss] Implementation vs. result (CDRF, profiles, et al.)

[jose lorenzo <hozelda@yahoo.com>]

--- On Wed, 6/18/08, Dave Pawson <dave.pawson@gmail.com> wrote:

> From: Dave Pawson <dave.pawson@gmail.com>
> Subject: Re: [oiic-formation-discuss] Implementation vs. result (CDRF, profiles, et al.)
> To: oiic-formation-discuss@lists.oasis-open.org
> Date: Wednesday, June 18, 2008, 2:58 PM
> 2008/6/18 Simon Calderson <caldersons@yahoo.co.uk>:
> 
> > I think we need to focus on what this new TC is
> seeking to achieve, not how it will decide to achieve
> things. In particular, specifying in too much detail what
> its outputs should be, or what format it outputs should be
> in, is extremely dangerous. What we want/need/desire is
> great interoperability between ODF implementations (for
> some definition of such).
> 
> From my reading so far, the only viable route is via
> compliance testing.
> I haven't seen any other definition of interop that is
> viable and
> based on the standard.

The text describing the interop rules is very important. You can't test everything by a long shot. Having an evolving test suite is very valuable for testing the boundary cases. ["Boundary cases" depend also on implementations and is not always revealed through the existing formal test suite, especially since you can code around (without fixing the issue for other cases) any anticipated tests.] Without a thorough standard, adding and adjusting tests (desirable to grow coverage and fix testsuite bugs) would mean effectively constantly changing the standard with every test change. It's also good to be able to identify issues after the fact. We need clear rules for that. Tests might be incorrect in subtle ways as per the rules. Something must be the final word. Tests are subservient to the rules whenever rules are deemed to be the "standard."

Maybe you meant: besides the rules, testing is the most important. [..apologize if you meant that, but too much eagerness to code tests when rules might be missing is ok but should not lead to the rules not being written. The primary value is in the (testable) rules.]

Between two sets of rules that are about the same, the one that can be tested better is to be preferred.

Also, I think tests should be written as the rules are written as a way to test the quality of the rules as early as possible.

[All "off topic" discussions that relate to building the interop framework are useful gains so long as the primary task of writing the TC charter continues.]