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


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



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