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] Implementation vs. result (CDRF, profiles,et al.)

Hash: SHA1


Craig A. Eddy

Shawn wrote:
> jose lorenzo wrote:
>> 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.]
> Can we have some clarification of what we are proposing to test?
> Are we testing how other applications read/write the ODF standard?
> Are we testing how the standard works in other applications?
> (subtle but important distinction here) Are we testing how to use
> ODF with OOXML/protocol of choice All the above?
> This was alluded to in an earlier post, but I think this issue gets
>  to the core.
> If we are ONLY testing how well other applications utilize the
> existing standard, then a whole lot of conversation just
> disappears.  We no longer need to care about W3C CRF, OOXML, etc.
> These would by definition be out of scope.
> I don't think we are hear to solve the "interoperability quagmire".
>  I believe all we need to worry about is a) how well various
> applications conform to, or utilize the ODF standard. b) identify
> problem areas that need to be brought to the attention of the ODF
> TC (if that's the right place for changing the ODF standard).  I
> doubt we are here to change the standard itself. There are other
> TC's for that job.
> If that is the given "goal" of this TC, then we only need to worry
> about how to test the conformity, and how to identify problem
> areas.  Which takes us square back to defining profiles and tests.
>  All other discussion becomes OT.  More specifically, we only need
> to worry about drafting the charter to allow these activities, and
> to avoid clouding the issue with the other interpretations of
> "interop".
> Soooo, am I on the right track here, or should I go back to lurking
>  now?? :)
> Shawn
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail:
> oiic-formation-discuss-unsubscribe@lists.oasis-open.org For
> additional commands, e-mail:
> oiic-formation-discuss-help@lists.oasis-open.org
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


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