Re: [oiic-formation-discuss] (1)(d) A list of deliverables, withprojected completion dates.

[Sander Marechal <sander.marechal@tribal-im.com>]

Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
>> 2) An Acid-style test of ODF implementations, i.e., feature and 
>> rendering-oriented, essentially highlighting ODF features that are not 
>> widely implemented (or implemented correctly) but are desired (by whom???)
> 
> As for "not widely implemented": Most vendors implement those features
> that are important for their users. If a feature is not widely
> implemented, then this is a hint that the feature is maybe not so
> important. I think we should focus on those features actually that are
> widely used rather than on test cases where we know that the features
> are not widely implemented.

Going back to the original ACID tests, I understand the "not widely
implemented" means features that most of the browsers did not support,
but which were very much wanted by web developers to create better
websites. The problem with web development was (and is) that there was a
huge gap between the features implemented by the vendors (especially
Microsoft up to IE6) and the W3C specs and features that the developers
actually wanted. Plus a long list of well known bugs that never got
fixed (e.g. all of Internet Explorer's hasLayout bugs). The main thing
that web developers want is simply to write a medium-complex website
that works reliably across different browsers. It's a mayor PITA to make
browser-specific changes for all the major browsers.

I think that the gap between spec and implementation for ODF is much
smaller. I think an ODF ACID test should focus less on the unimplemented
features (since most of the features are implemented) and more on the
parts that cause the interoperability problems between ODF applications
because features are implemented differently or are simply buggy. Like
web developers, ODF authors simply want to write a document and have it
work correctly across all mayor ODF applications. They don't want to
worry that they can't use feature X in OOo because it displays badly in
KOffice2 or causes the ODF import filter in MS-Word to throw errors.

IIRC the features tested in the original ACID tests were selected based
on the experience of the web developers, not by stepping through the
spec and going through all the features. Perhaps we need to do the same.
Start round-tripping complex documents through all the major ODF
applications and see where they fail. Scout the blogs and bugtrackers of
these applications for known bugs. Perhaps even create a website where
people can report interoperability issues they find in real life. Then
use these to build an ODF ACID test.