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: Thoughts on interop

Hi everyone.

Some thoughts I've had reviewing the last few days' discussion on this list. What strikes me is two things; a. a focus on replicating 'acid test' for ODF, and b. a focus on visual interop. I think both these things are mistaken.

To relate these issues back to the topic at hand, I'm not sure why the output of an interop TC would be of genuine use to end-users and ODF customers. The 'acid test' is a good example of an interop spec. designed such that browsers will fail; it's not a good example of a test which says much if anything about the overall conformity to a standard.. Indeed, it would be dangerous to moot such interop tests as a system of validation for ODF implementations - it's very easy to use such tests as a cudgel with which to bash vendors, when in reality with a complex standard you can create tests which even good implementations will fail (e.g., Firefox and Acid 3 - where the test was specifically designed to ensure it failed).

In my opinion, the output of any interop TC should be focussed primarily for the use of vendors to improve their implementations, not for others to judge implementation quality by (though invariably, in any event, they will be interpreted as such, I imagine). Using a "carrot" approach rather than "stick" makes it much more likely that vendors outside the "big guys" are going to want to participate, and allows the interop TC to focus on specific areas or features without putting all the pressure on the vendors whose implementations are weakest in those specific areas.

The audience of the interop TC ought to also include the ODF TC. I don't know if this has been mentioned already, but it's not like the ODF specification is in any way golden or perfect: the interop TC is certainly going to come to the conclusion that certain features (or lack of features) hinder interop, and it's only the ODF TC who are able to act on those suggestions.

So, my suggestion for audience would be the ODF TC, and ODF vendors. That makes the audience narrow and specific, and the output can then be tailored to their specific needs. Trying to address everyone's needs will address none of them well, and trying to use interop cases as an ODF quality mark is bound to fail.

Finally, I would like to see much more thought given to non-visual interop. As a good example, it seems that the formula ctte has already put a lot of effort into test cases to ensure mathematical consistency and correctness. Such a test system obviously would be of use to the interop TC, and from my point of view it's vastly more important that the information in a spreadsheet be correct than that the spreadsheet "looks" right. Ditto for documents - much more important that they can be shared and edited sanely on different implementations than that they look identical. 


Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

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