Flanker (./80) :
Implémenté… seulement partiellement…
http://testsuite.opendocumentfellowship.org/

Certains de leurs tests ont été effectués avec KOffice 1.5.2, on en est à la 1.6.3, la gestion de l'ODF a beaucoup évolué!
Les développeurs de KFormula disent aussi qu'ils passent plus de testcases MathML que OO.o Math maintenant.

Tu te fous de moi ? Là tu parles d'options qui n'existent que pour la compatibilité, et qui ne doivent pas être utilisées pour créer de nouveaux documents…

Mais l'ODF propose de vraies options qui gèrent non seulement les cas "oui" et "non" de ces hacks de compatibilité, mais aussi tous les autres réglages possibles (alors que "Open" XML code un réglage en dur et permet de choisir un autre réglage codé en dur avec le hack de compatibilité).

Qu'en est-il de l'accessibilité

L'accessibilité, n'est-ce pas un problème de l'application, pas des documents?

des règles pour les créations de formules dans les tableurs (et oui, pour l'instant, une formule mathématique est définie comme une chaîne, tu peux écrire n'importe quoi et c'est considéré comme valide en ODF )

Déjà c'est faux: http://www.openmalaysiablog.com/2006/11/the_formula_iss.html

Maintenant, en pratique, OO.o et KOffice gèrent aussi des formules qui ne sont pas définies là-dedans, mais c'est parce que les formules sont censées être compatibles Excel et qu'ils n'allaient pas documenter Excel! Mais il y a ça: http://wiki.oasis-open.org/office/About_OpenFormula. Drafts actuels disponibles ici: http://www.oasis-open.org/committees/documents.php?wg_abbrev=office-formula.

des métadonnées

La testsuite vers laquelle tu as mis le lien toi-même montre que les métadonnées sont spécifiées (et aussi la section du standard: Section 3.1), donc franchement tu es de mauvaise foi.

les tables de façon native dans les présentations (et non sous la forme d'un tableur importé)

"Natif" ou "importé" ne fera plus aucune différence avec la librairie Flake de KOffice 2.0 (actuellement en version alpha 2). Au lieu d'importer un document entier comme avec OLE, UNO ou KParts, Flake permet d'importer n'importe quel "shape" défini par n'importe quelle application KOffice dans n'importe quelle autre sans qu'on voie la différence (parce que les shapes "natifs" sont importés de la même manière).

Rien n'empêche une autre application de gérer ces importations de la même manière.

Dans OpenXML, aucune balise n'est définie comme étant « Application Defined ».

C'est vrai, à la place ce n'est pas défini du tout.

Quant aux "application-defined" de ODF, c'est parce que l'ODF définit le contenu du document, pas l'affichage qui est un problème de l'application. Or ZoomFactor est un problème d'affichage. C'est stocké dans le document pour qu'une application puisse s'en rappeler entre enregistrements (c'est ça la raison pour laquelle ces tags application-defined existent!), mais il est évident qu'un zoom de 150% n'aura pas le même rendu sur une TI-89 que sur un écran 29". Mais ce n'est pas grave, le facteur zoom, chacun peut le régler comme il veut dans les menus sans changer le contenu du document!

Sinon, tu peux regarder également du côté des énumérations (1,2,3, …) que tu peux très bien écrire avec plein de systèmes de numérations différents avec Office (en toutes lettres, en chiffres romains, japonais, chinois, …). Tout est clairement défini pour OXML, alors que pour ODF, non seulement le choix est beaucoup plus restreint, mais c'est ambigu (ODF utilise seulement les 3 premiers nombres pour définir la numérotation, et ce n'est pas toujours suffisant).

Ah bon? Tu proposes de compter comment? 1, 2, 3, 5, 8, 13, 21, ...?
Énumérer les 3 premiers nombres, ça permet d'utiliser les caractères numéraux Unicode plutôt que des IDs codés en dur (de type 1=arabe, 2=romain, ...).

Faut dire qu'ils sont tellement objectifs

Ce n'est pas parce que le site n'est pas objectif que les problèmes de brevets qu'il soulève ne sont pas réels!