L'assertion "c'est impossible d'implémenter correctement" sur une dépêche qui annonce un logiciel libre qui l'implémente, je trouve ça assez cocasse.
L'affirmation «OOXML est techniquement impossible à mettre en œuvre correctement» provient d'un constat vérifié par les réviseurs lors du processus de standardisation. C'est un fait avéré, pas une opinion ni une croyance.
Que OnlyOffice la mette en œuvre ne démontre pas que l'affirmation est fausse. Rien ne dit que ses développeurs ont pu le faire correctement. Il faudrait d'ailleurs leur demander leur avis sur la facilité ou la difficulté de cette mise en œuvre, non? Ils ont peut-être réussi à faire en sorte que tous les "écarts de formatage" soient "mineurs", justement.
Et tant qu'on y est, pourquoi, justement, constate-t-on encore des écarts de formatage? Si c'est une norme bien formée, aucun écart de formatage ne devrait être constaté. Ceci dit, les écarts de formatage ne veulent absolument rien dire par rapport à la norme: un écart de formatage peut très bien être dû à un bug de rendu du programme.
En d'autres termes, juger de la [bonne] mise en œuvre d'une norme (qu'elle soit correcte ou bâclée) sur la seule base du rendu graphique est plutôt léger comme argumentation.
OnlyOffice n'implémente peut être pas parfaitement la norme, mais ça n'indique rien sur sa qualité.
Ton raisonnement est renversé (i.e. à rebours)! C'est la [non-] qualité de OOXML qui la rend impossible à mettre en œuvre correctement, point. C'est parce que cette spécification est bancale, incorrecte, de mauvaise qualité, buggée, si tu veux, qu'une mise en œuvre correcte est impossible.
Le format OOXML dans OnlyOffice est le format natif, interne. Le logiciel n'impose aucunement de n'utiliser que ce format [...]
On avait bien compris, tu sais. Ce n'est pas de cela dont il est question ici mais plutôt de la légitimité accordée tacitement à OOXML par un public non connaisseur.
Le format interne on n'est pas obligé de s'en soucier.
Ben si, justement, c'est là que tu te trompes.
Qu'est-ce qui permet d'affirmer qu'il existe une manière univoque, déterministe et complète de convertir un document, dont le format interne est OOXML (et quelle version, d'ailleurs?) vers n'importe quoi d'autre, pour ne parler que de ça? Et vice-versa? Perso, je n'en ai aucune idée. Et toi?
Pour répondre à cette question, posons la question aux développeurs de Only Office. On verra bien ce qu'ils ont à répondre...
7. Microsoft’s OOXML "pseudo-standard" format (.docx etc)
See Why you should never use Microsoft’s OOXML pseudo-standard format[attention: lien d'origine non disponible] where Italo Vignoli of The Document Foundation, the organization responsible for developing LibreOffice, talks about "the dirty tricks Microsoft uses to break interoperability and keep users locked into their platform".
It includes " ... each version of MS Office since 2007 has a different and non standard implementation of OOXML, which is defined as "transitional" because it contains elements which are supposed to be deprecated at standard level, but are still there for compatibility reasons. Although LibreOffice manages to read and write OOXML in a fairly appropriate way, it will be impossible to achieve a perfect interoperability because of these different non standard versions."
See MS Office 2007 OOXML file format (docx, xslx, pptx, ppsx) for a discussion of OOXML and why many consider OOXML is a deliberate attempt by Microsoft to make it almost impossible for other vendors to read or write fully compliant OOXML files. The "standard" is 6,000 pages long and it is estimated a full import or export filter would take 50 to 500 person-years to write.
And after you have done all that work, all it takes is for Microsoft to make another not-part-of-the-standard change or addition to the so called "standard" ... and your interface no longer works.
Ce qui donne en français:
7. Le format "pseudo-standard" OOXML de Microsoft (.docx etc.)
Voir le lien [Pourquoi vous ne devriez jamais vous servir du format pseudo standard OOXML de Microsoft] où Italo Vignoli de la Document Fondation, l'organisation responsable du développement de LibreOffice, parle des "coups fourrés de Microsoft visant à bousiller l'interopérabilité et à rendre captifs les utilisateurs de leur plate-forme."
Il inclut «... chaque version de MS Office depuis 2007 possède une mise en œuvre différente et non standard de OOXML, définie "transitionnelle" parce qu'elle contient des éléments supposés obsolètes au niveau du standard, bien que toujours présents pour des raisons de compatibilité. Même si LibreOffice se débrouille pour lire et écrire OOXML de manière relativement appropriée, il sera impossible d'arriver à une parfaite interopérabilité à cause de ces différentes versions non standard.»
Voir le fil [Le format Office 2007 OOXML (docx, xlsx, pptx, ppsx)] pour une discussion sur OOXML et pourquoi beaucoup considèrent que OOXML est une tentative délibérée de Microsoft pour rendre quasiment impossible la tâche de lecture/écriture de fichiers OOXML entièrement conformes par d'autres vendeurs. Le "standard" fait 6000 pages et on estime que l'écriture d'un filtre d'import/export complet prendrait entre 50 et 500 années-personne!
Et après avoir développé tout cet effort, tout ce qu'il suffit à Microsoft est de faire une ajoute ou tout autre modification hors-standard à ce prétendu "standard"... et votre interface cesse de fonctionner.
Aussi, dans le document présentant Italo Vignoli:
Actually, Microsoft is using OOXML specifications, but is not using them consistently between software versions as the nature of the standard would request. So, we have OOXML 2007 Transitional, OOXML 2010 Transitional and OOXML 2013 Transitional, in addition to OOXML 2013 Strict (which is not the default choice of Microsoft Office 2013, and therefore non one is using it).
MS Office users are not aware of this situation, and are producing a "rainbow" of document versions which are a problem for interoperability.
Et en français:
En fait, Microsoft se sert des spécifications OOXML mais pas de manière cohérente entre les différentes versions [de leurs suites] logicielles, comme l'exigerait la nature du standard. Nous avons donc un OOXML 2007 Transitionnel, un OOXML 2010 Transitionnel et un OOXML 2013 Transitionnel, en plus du OOXML 2013 Strict (qui n'est d'ailleurs pas le choix par défaut dans Microsoft Office 2013, d'où personne ne l'utilise) [Note: à l'heure de l'écriture de ce document, bien sûr. Question: Comment la situation a-t-elle évolué depuis?]
Les utilisateurs de MS Office sont non conscient de cette situation et produisent une "palette" de versions de documents qui posent un problème d'interopérabilité.
Là-dessus, ce n'est pas moi qui le dit, hein.
En d'autres termes, OOXML est en quelque sorte une bombe à retardement d'interopérabilité, un format qui ne peut pas être mis en pratique de manière conforme et qui ne peut que poser des problèmes d'interopérabilité sur le long terme.
[^] # Re: on est obligé ?
Posté par FantastIX . En réponse à la dépêche ONLYOFFICE version 10 est disponible. Évalué à 8. Dernière modification le 21 juin 2019 à 15:48.
L'affirmation «OOXML est techniquement impossible à mettre en œuvre correctement» provient d'un constat vérifié par les réviseurs lors du processus de standardisation. C'est un fait avéré, pas une opinion ni une croyance.
Que OnlyOffice la mette en œuvre ne démontre pas que l'affirmation est fausse. Rien ne dit que ses développeurs ont pu le faire correctement. Il faudrait d'ailleurs leur demander leur avis sur la facilité ou la difficulté de cette mise en œuvre, non? Ils ont peut-être réussi à faire en sorte que tous les "écarts de formatage" soient "mineurs", justement.
Et tant qu'on y est, pourquoi, justement, constate-t-on encore des écarts de formatage? Si c'est une norme bien formée, aucun écart de formatage ne devrait être constaté. Ceci dit, les écarts de formatage ne veulent absolument rien dire par rapport à la norme: un écart de formatage peut très bien être dû à un bug de rendu du programme.
En d'autres termes, juger de la [bonne] mise en œuvre d'une norme (qu'elle soit correcte ou bâclée) sur la seule base du rendu graphique est plutôt léger comme argumentation.
Ton raisonnement est renversé (i.e. à rebours)! C'est la [non-] qualité de OOXML qui la rend impossible à mettre en œuvre correctement, point. C'est parce que cette spécification est bancale, incorrecte, de mauvaise qualité, buggée, si tu veux, qu'une mise en œuvre correcte est impossible.
On avait bien compris, tu sais. Ce n'est pas de cela dont il est question ici mais plutôt de la légitimité accordée tacitement à OOXML par un public non connaisseur.
Ben si, justement, c'est là que tu te trompes.
Qu'est-ce qui permet d'affirmer qu'il existe une manière univoque, déterministe et complète de convertir un document, dont le format interne est OOXML (et quelle version, d'ailleurs?) vers n'importe quoi d'autre, pour ne parler que de ça? Et vice-versa? Perso, je n'en ai aucune idée. Et toi?
Pour répondre à cette question, posons la question aux développeurs de Only Office. On verra bien ce qu'ils ont à répondre...
En tout cas, ceux de LibreOffice l'ont déjà fait voir le lien dans le commentaire de raphj:
Ce qui donne en français:
Aussi, dans le document présentant Italo Vignoli:
Et en français:
Là-dessus, ce n'est pas moi qui le dit, hein.
En d'autres termes, OOXML est en quelque sorte une bombe à retardement d'interopérabilité, un format qui ne peut pas être mis en pratique de manière conforme et qui ne peut que poser des problèmes d'interopérabilité sur le long terme.