La guerre des formats bureautique est-elle finie ?

Posté par (page perso) . Modéré par Mouns.
Tags : aucun
0
21
juin
2008
Bureautique
Après l'acceptation du format MS-OOXML (Microsoft Office OpenXML) par l'ISO, deux formats bureautique ouverts et normalisés s'opposaient.

Cette situation inquiétante s'est dénouée en quelques mois :
  1. Dénonçant des irrégularités dans la procédure de décision, quatre pays ont fait appel de la décision de l'ISO : le Venezuela, l'Afrique du Sud, le Brésil et l'Inde ;
  2. Microsoft a annoncé que la prochaine mise à jour de sa suite bureautique Microsoft Office utiliserait nativement le seul format vraiment ISO OpenDocument (ODF) et ne prendrait plus en charge MS-OOXML ;
  3. Suite aux appels des quatre pays sus-mentionnés, l'ISO a alors suspendu la publication de la norme MS-OOXML.
Retour sur la saga de ces formats.

Acte premier : OpenDocument, enfin une norme de format bureautique.

Mai 2005 : L'OASIS (association d'entreprises pour la promotion de formats ouverts basés sur XML) normalise OpenDocument Format.

Ce format est issu d'OpenOffice.org, mais a été rédigé par un comité ouvert. C'est donc le premier format de bureautique ouvert de l'histoire, ce qui met fin à des décennies de cauchemars d'incompatibilités et de conservation des documents. De nombreuses entreprises soutiennent ce format, qui est utilisé par d'autres suites bureautiques, notamment IBM Lotus Symphony, KDE KOffice, Gnome Office avec Gnumeric/Abiword et plus récemment Microsoft Office, par l'ajout d'un greffon.

Mai 2006 : l'ISO normalise ODF (OpenDocument Format, créé par OpenOffice.org).

OpenDocument devient ainsi le premier format bureautique normalisé de l'histoire, ISO 26300:2006. Le chemin est tout tracé vers un unique format commun à toutes les suites bureautiques.

De plus en plus d'organisations et pays demandent en effet un format normalisé et ouvert pour les échanges de documents.

Acte II : OpenXML, un concurrent !

Décembre 2006 : l'ECMA normalise Office OpenXML, de Microsoft.

MS-OOXML, issu d'un développement interne de Microsoft, est ainsi le second format bureautique ouvert. Il est utilisé nativement par Microsoft Office 2007, dernière version de la suite bureautique la plus utilisée au monde. En revanche, aucune suite bureautique ne l'utilise, ce qui n'est pas surprenant pour un jeune développement interne.

Novell, √©diteur d'une distribution Linux et partenaire de Microsoft, r√©dige un greffon de prise en charge de MS-OOXML pour OpenOffice.org. Ce greffon utilise la technologie Microsoft .Net, qui s'√©loigne de celles utilis√©es par OpenOffice.org. Ce greffon n'est mis √† disposition que pour les syst√®mes de Microsoft et de Novell, et ne sera jamais inclus dans le d√©veloppement principal d'OpenOffice.org. De plus, ce logiciel qui m√©riterait un grand rayonnement n'est pas mis en valeur, ne dispose ni d'un site d√©di√©, ni d'une documentation accessible, et il semble difficile de d'en obtenir les sources, et m√™me de conna√ģtre la licence sous lequel il est publi√©.

Mars 2007 : Microsoft présente MS-OOXML à l'ISO, pour une normalisation accélérée. La guerre des formats bureautique commence donc vraiment.
<http://linuxfr.org/2007/03/13/22209.html>

Septembre 2007 : MS-OOXML est refusé par l'ISO. De nombreuses irrégularités de la part de Microsoft sont dénoncées dans la procédure de vote. La procédure de normalisation continue plus lentement, en tenant compte des avis émis par les organismes membres de l'ISO.

Avril 2008 : l'ISO accepte MS-OOXML. Encore plus d'irrégularités sont à déplorer, notamment des changements d'avis au dernier moment d'organismes pourtant partisans de la non-normalisation.

Maintenant, deux formats bureautiques normalisés et ouverts s'opposent ouvertement, ce qui nous éloigne de l'objectif d'un format commun interopérable.

Acte trois : la chute d'OpenXML

Mai 2008 : Microsoft annonce que la prochaine mise à jour de Microsoft Office apportera une gestion native d'ODF et un retrait de celui de MS-OOXML.

Mai 2008 : en une semaine, le Vénézuela, l'Afrique du Sud, le Brésil et l'Inde font appel sur la décision de l'ISO.

Juin 2008 : suite à ces appels, l'ISO interrompt la publication de la norme MS-OOXML. MS-OOXML sera peut-être publié en tant que norme après résolution de ces appels, donc dans plusieurs mois.

Juin 2008 : un représentant de Microsoft, Stuart McKee, explique qu'ODF a gagné la guerre des normes de formats ouverts de bureautique.

√Čpilogue : la victoire de l'interop√©rabilit√©

La situation actuelle correspond donc précisément à l'objectif initial d'OpenDocument : un unique format bureautique ouvert et normalisé, destiné à être utilisé par toutes les suites bureautique du marché. Cela garantit donc, au moins dans ce domaine, une concurrence loyale et une garantie de pérennité des documents.

Aller plus loin

  • # Mais bien s√Ľr ...

    Post√© par (page perso) . √Čvalu√© √† 10.

    Il faudrait arrêter de dire des âneries ...:
    http://www.theinquirer.net/gb/inquirer/news/2008/06/20/odf-clearly-won-microsoft-exec

    Microsoft n'est pas près de lâcher le morceau. Encore un peu de graissage de patte et l'OOOXML sera reparti de plus belle ...
    • [^] # Re: Mais bien s√Ľr ...

      Post√© par (page perso) . √Čvalu√© √† 3.

      Toutafai ! Microsoft n'abandonne pas son format, il rajoute juste un meilleur support de l'ODF. Cependant ce revivement de situation est assez exceptionnel et j'avoue avoir eu du mal à y croire venant de Microsoft...

      Dans tout les cas, c'est un bon point pour l'ODF, c'est indéniable.

      Sinon, par contre, j'ai pas tout compris quand au support du "peut-être futurement normalisé" OOXML. Il garde leur implémentation non standard ou feront un effort pour supporter la version ISO (si elle sort) ?
      • [^] # Re: Mais bien s√Ľr ...

        Post√© par . √Čvalu√© √† 5.

        Ils vont passer a la version ISO, c'est la toute la confusion.

        MS ne va rien enlever du tout, ils ont simplement annonce que l'update de Office pour supporter la version ISO viendra dans la prochaine version et pas dans le service pack.
    • [^] # Re: Mais bien s√Ľr ...

      Post√© par . √Čvalu√© √† 10.

      Salut

      De toute façon je crois qu'il faudra juger sur les faits et non sur des effets d'annonce.
      Si la prochaine version n'implémente que ODF alors oui c'était vrai sinon si il a les 2 et bien là faudra voir comment ils l'ont implémenté (partiel ou total), si ils dénigrent ou pas ODF ou OOXML etc. etc.

      patience, patience...
      mais surtout vigilance...

      Thierry
      • [^] # Re: Mais bien s√Ľr ...

        Post√© par (page perso) . √Čvalu√© √† 5.

        Je me souviens avoir envoy√© des dessins SVG d'Inkscape √† un gars qui travaillait avec Adobe Illustrator. Curieusement il n'a jamais r√©ussi √† les lire correctement, il y a toujours eu des probl√®mes : la faute √† Inkscape ou √† Illustrator ? Dans le doute, l'utilisateur standard dira que c'est Inkscape, gratuit donc forc√©ment moins bien‚Ķ (pour ma part, je ne sais pas !) √áa me rappelle IE/Firefox face aux pages ¬ę optimis√©es pour IE ¬Ľ, qui a raison, qui a tord ? C'est facile de rejouer le m√™me sc√©nario malheureusement.
        • [^] # Re: Mais bien s√Ľr ...

          Post√© par (page perso) . √Čvalu√© √† 2.

          Quand un fichier est écrit dans un format normalisé comme svg, les problèmes d'intéropérabilité sont la faute des logiciels qui ne gèrent pas correctement la norme.

          Inkscape rajoute des informations qui lui sont propres dans les svg par défaut, mais ils n'empêche en rien l'intopérabilité, on peu enregistrer dans un format svg uniquement.

          Bref, dans ton cas avec illustrator, soit inkscape ne gère pas bien le SVG, soit c'est illustrator, ou les deux. \o/

          Mon avis partiale et totalement infondé c'est que illustrator ne gère pas bien le svg.
          • [^] # Re: Mais bien s√Ľr ...

            Post√© par . √Čvalu√© √† 3.

            inskape propose l'enregistrement en "svg Inkscape" et "svg simple" (ainsi que leurs variantes svgz compressés. A priori je serai tenté de dire qu'il vaut mieux utiliser le second choix quand on souhaite le partager à l'utilisateur d'une autre appli...
  • # Et le RGI ?

    Post√© par . √Čvalu√© √† 0.

    C'est une excellente nouvelle, puisque cela signifie certainement que le RGI sera finalement signé ?
    • [^] # Re: Et le RGI ?

      Post√© par . √Čvalu√© √† 0.

      La DGME est morte, arrêtez de pleurer pour le RGI.
      • [^] # Re: Et le RGI ?

        Post√© par . √Čvalu√© √† 4.

        Le Référentiel Général d'inter-opérabilité
        Un document qui donne les règles de création, de diffusion et d'archivage des documents émis par l'administration.
        Il n'est pas respecté et de nombreux responsables des services informatiques n'en n'ont pas connaissance.
        Actuellement, à la DGI les poste de travail sont obligatoirement sous Windows XP avec Office 2000 et IE6.
        Il est préconisé dans le RGI de faire des document en HTML ou et PDF... il sont fait en RTF.
        Un partie de l'IntraNet (application interne) avait été développé en utilisant SVG ... la dernière version a été corrigé et utilise dorénavant VML (compatible uniquement avec IE).

        Le RGI ne semble pas avoir évolué depuis 2006.

        J'en ai récupéré une version sur Internet il y a quelques mois (dans un format inconnu tout juste lisible)
        • [^] # Re: Et le RGI ?

          Post√© par (page perso) . √Čvalu√© √† 5.

          Le RGI est toujours disponible sur le site de http://www.synergies-publiques.fr/article.php?id_article=746 en particulier le volet technique http://synergies.modernisation.gouv.fr/IMG/pdf/Referentiel_G(...) qui contient les références aux formats de documents.

          Pour ceux qui n'auraient pas tout suivi, un résumé et les liens essentiels vous attendent sur http://pjarillon.free.fr/rgi/
        • [^] # Re: Et le RGI ?

          Post√© par . √Čvalu√© √† 4.

          > Il est préconisé dans le RGI de faire des document en HTML ou et PDF... il sont fait en RTF.

          Il est interdit de migrer vers un format bureautique autre que odf à partir des format traditionnellement utilisé.

          PDF concerne les documents informatif, pas les document de travail
          HTML est déconseillé XHTML est recommandé


          >Un partie de l'IntraNet (application interne) avait été développé en utilisant SVG ... la dernière version a été corrigé et utilise dorénavant VML (compatible uniquement avec IE).

          Quel logiciel exactement? Parce que je n'ai pas souvenir d'un marché sans une compatibilité IE/Firefox (à moins que ça ne soit un développement 100% interne, mais ça c'est comme les poissons volant, ça existe, mais ça n'est pas la majorité).

          >Le RGI ne semble pas avoir évolué depuis 2006.

          Putain, si: le passage de la recommandation de xmlshema à relaxng pour les spécifications de format xml

          >J'en ai récupéré une version sur Internet il y a quelques mois (dans un format inconnu tout juste lisible)

          En PDF....
          • [^] # Re: Et le RGI ?

            Post√© par . √Čvalu√© √† 3.

            > Il est préconisé dans le RGI de faire des document en HTML ou et PDF... il sont fait en RTF.
            Il est interdit de migrer vers un format bureautique autre que odf à partir des format traditionnellement utilisé.


            Si le document a été créé originellement en RTF et qu'il est resté en RTF alors il n'y a pas eu de migration. Et si un document d'un autre format a été converti en RTF, tant que ce nouveau document n'en constitue pas la nouvelle version officielle, on ne peut pas parler de migration.

            Enfin à quoi bon avoir établi les préconisations du RGI si elles ne deviennent pas des obligations accompagnées de sanctions en cas de violation ?
          • [^] # Re: Et le RGI ?

            Post√© par . √Čvalu√© √† 1.

            Bonjour,

            Un partie de l'IntraNet (application interne) avait été développé en utilisant SVG ... la dernière version a été corrigé et utilise dorénavant VML (compatible uniquement avec IE).

            Quel logiciel exactement? Parce que je n'ai pas souvenir d'un marché sans une compatibilité IE/Firefox (à moins que ça ne soit un développement 100% interne, mais ça c'est comme les poissons volant, ça existe, mais ça n'est pas la majorité).


            Il s'agit d'un développement purement interne, LEONARD, qui permet de documenter les chaines de logiciels tournant sur Grands Systèmes. C'est un produit sympa (avec quelques manques), il impose une certaine rigueur entre les études et la recette pour mise en exploitation, et c'est bien ! Ce logiciel, s'il était portable, pourrait servir à d'autres service de développement Grands Systèmes, comme il s'agit d'un développement payé par le contribuable, il devrait (à mon avis) être mis en "open source" pour aussi bénéficier des évolutions proposées par la communauté, la DGI restant chef de projet.

            C'est hors sujet, mais sait-on s'il y a des contributions extérieures sur le logiciel SPIP dans sa version AGORA développée par l'administration ?

            Cordialement,
            • [^] # Re: Et le RGI ?

              Post√© par . √Čvalu√© √† 3.

              > C'est hors sujet, mais sait-on s'il y a des contributions extérieures sur le logiciel SPIP dans sa version AGORA développée par l'administration ?

              Maintenance jusqu'en mai 2008 (sic), et analyse post mortem de ce qu'il ne faut pas faire:
              http://www.agora2spip.agora.gouv.fr/Modes-de-contribution-a-(...)
            • [^] # Re: Et le RGI ?

              Post√© par . √Čvalu√© √† 4.

              > il devrait (à mon avis) être mis en "open source" pour aussi bénéficier des évolutions proposées par la communauté, la DGI restant chef de projet.

              Pour l'√Čtat, la mise √† disposition √† d'autres services (concr√®tement, c'est surtout √ßa) passe par admisource: http://admisource.gouv.fr/ (tient, y'a encore un terme ad√®le qui traine).

              Ensuite les contributions ext√©rieures ne viennent pas exactement spontan√©ment, ce serait plut√īt des services pour qui le logiciel est d√©j√† utile (donc non portable et sp√©cifique IE, √ßa exclut pas mal de chose), et qui ont la m√™me d√©marche sur leur contributions (puisque √ßa demande du temps de transf√©rer le d√©veloppement sp√©cifique, l'int√©r√™t √©tant de ne pas maintenir une branche s√©par√© comme spip-agora (m√™me si le fork est parfois utile, quand le chef de projet a tendance a prendre de mauvaise d√©cision par exemple)).
  • # ODF pose certains probl√®mes

    Post√© par . √Čvalu√© √† 4.

    Sans vouloir comparer avec OpenXML qui ne fait que compliquer les choses et sans chercher à troller, la situation n'est pas des plus satisfaisante pour les utilisateurs d'ODF.

    On nous parle de norme ISO pour ODF, mais celle-ci ne s'applique pour le moment qu'à la version 1.0 du format ODF qui a déjà été supplantée dans OpenOffice.org par la 1.1 depuis un an. Et voilà que depuis quelques temps déjà on nous parle de la future version 1.2...

    Un format pour devenir une norme exploitable, devrait au moins perdurer quelques années sans évoluer, il me semble.
    • [^] # Re: ODF pose certains probl√®mes

      Post√© par . √Čvalu√© √† 7.

      Dans ce cas pourquoi se donner la peine de créer le PDF 1.8 puisque le PDF 1.7 est déjà une norme ISO !
    • [^] # Re: ODF pose certains probl√®mes

      Post√© par . √Čvalu√© √† 3.

      Il me semble que l'evolution est au cahier des charges . De toute façon un format ouvert est toujours accessible aux developpeurs (a tous les développeurs)
      http://iw-linux.over-blog.com/
    • [^] # Re: ODF pose certains probl√®mes

      Post√© par . √Čvalu√© √† 7.

      html 3, 3.2, 4, xhtml 1, html5, css 1, css2, css 3, etc... Je dois en oublier beaucoup.

      Notons bien que ODF 1.1 et ODF 1.2 ont la compatibilité ascendante avec ODF 1.0. C'est trivial pour convertir du ODF 1.[12] en ODF 1.0 et encore plus pour convertir du ODF 1.0 en ODF 1.[12] (il n'y a pratiquement rien à faire).

      Il ne faut pas se laisser abuser par la succession de versions d'ODF. ODF est un format bien né dont la pérennité ne peut être remise en cause (en tout cas aujourd'hui)
      Mais ODF a aussi besoin d'évoluer. ODF 1.2 sera normalisé ISO. Il sera facile (et FIABLE !) de convertir les fichiers ODF 1.0 en ODF 1.2. Les programmes qui supportent ODF 1.2, supporteront "naturellement" ODF 1.0 (c'est facile à faire).
      Convertir du .doc en MS-OOXML, c'est la merde. Mais ça n'a rien à voir avec ODF.

      > On nous parle de norme ISO pour ODF, mais celle-ci ne s'applique pour le moment qu'à la version 1.0 du format ODF qui a déjà été supplantée

      Non. ODF 1.1 n'est qu'une extension d'ODF 1.0. ODF 1.1 ne remplace pas ODF 1.0, il l'ettend.
      • [^] # Re: ODF pose certains probl√®mes

        Post√© par . √Čvalu√© √† 4.

        Ou l'autre façon de dire...
        ODF ne pose pas de problème, il gère très très bien les évolutions.
        Tous les standards évoluent. Fort heureusement.
        Ce qui compte, c'est comment l'évolution est prise en compte, es-ce que la base du format est solide, etc.
        Pour ODF, ça roule.
        • [^] # Re: ODF pose certains probl√®mes

          Post√© par . √Čvalu√© √† 2.

          Heureusement que les standards évoluent, mais pourquoi si vite alors que l'on recherche justement une certaine pérennité en choisissant un format de fichier ?

          Notons bien que ODF 1.1 et ODF 1.2 ont la compatibilité ascendante avec ODF 1.0.

          Cela ne veut pas pour autant dire qu'un fichier ODF 1.2 sera correctement interprété par OpenOffice.org version 2.0.0 par exemple, même si ça n'est pas un problème en soit je l'avoue.

          Par contre apprendre que seul ODF 1.0 est une norme ISO d'un c√īt√© et de se rendre compte qu'OpenOffice.org n'utilise pas cette norme est tout de m√™me plus probl√©matique. Quelle est l'utilit√© d'avoir des normes si les logiciels les plus r√©pandus ne les mettent pas en Ňďuvre compl√®tement ?

          Mais peut-être que j'attache trop d'importance à cet organisme qu'est l'ISO...
          • [^] # Re: ODF pose certains probl√®mes

            Post√© par (page perso) . √Čvalu√© √† 4.

            L'évolution rapide des "normes" est lié au caractère même de l'informatique : tout va vite. Cf les diverses normes Wifi (b, g, n ...), l'USB qui va bientôt passer à la norme "3", le firewire ...

            Dans d'autres secteurs les normes évoluent aussi rapidement (agro-alimentaire par exemple.)
          • [^] # Re: ODF pose certains probl√®mes

            Post√© par . √Čvalu√© √† 5.

            > Par contre apprendre que seul ODF 1.0 est une norme ISO d'un c√īt√© et de se rendre compte qu'OpenOffice.org n'utilise pas cette norme est tout de m√™me plus probl√©matique.

            Ce que tu ne comprends pas, est que ODF 1.1 (ou 1.2) utilise ODF 1.0 !
            OOo 2.0 ouvrira du ODF 1.2. Il n'interprétera pas ce qu'il ne comprend pas (accessibilité, nouvelle formule, signature, etc). C'est comme le web (et les navigateurs).
            Oui, tout n'est pas parfait. Mais c'est un mal nécessaire.

            Il n'en sera peut-être pas de même pour ODF 2.0 (qui n'est toujours pas planifié).

            > Mais peut-être que j'attache trop d'importance à cet organisme qu'est l'ISO...

            Je ne crois pas. La standardisation est très importante (ISO ou pas).
            Par contre, la certification ISO n'est pas un élément suffisant. MS-OOXML est certifié (ou presque), ce n'est pas suffisant. La pérennité du format est mise en cause, sa solidité, son évolutivité, la capacité à se l'approprier, etc aussi.
            • [^] # Re: ODF pose certains probl√®mes

              Post√© par . √Čvalu√© √† 4.

              Ce que tu ne comprends pas, est que ODF 1.1 (ou 1.2) utilise ODF 1.0 !

              "utilise" certes oui puisque ODF 1.x vient compl√©ter cette norme, mais quelle est l'int√©r√™t de se r√©f√©rer √† une norme quand on ne s'y tient pas strictement et que pour des raisons l√©gitimes, je le reconnais, il est n√©cessaire de l'√©tendre afin de mettre en Ňďuvre de nouvelles fonctionnalit√©s (dans OpenOffice.org par exemple).

              Ce qui me gène, c'est que de nombreux outils se prétendent ainsi de la norme ODF mais qu'en réalité ils l'agrémentent à leur sauce, pour aboutir à des documents qui au final ne sont pas transposables à 100% quand on change d'outil. Ce devrait pourtant être l'objectif premier de l'implémentation d'une norme, assurer une compatibilité parfaite et totale.

              Certes ODF a peut être été rédigé trop rapidement, et même si on peut espérer une stabilisation d'ici quelques temps, il est quand même regrettable que ce processus ne soit pas plus rapide.

              Quelques reproches faits par les développeurs de Gnumeric à l'encontre de l'ODF (en milieu de page): http://www.gnome.org/projects/gnumeric/announcements/1.8/gnu(...)
              • [^] # Re: ODF pose certains probl√®mes

                Post√© par . √Čvalu√© √† 3.

                > "utilise" certes oui puisque ODF 1.x vient compl√©ter cette norme, mais quelle est l'int√©r√™t de se r√©f√©rer √† une norme quand on ne s'y tient pas strictement et que pour des raisons l√©gitimes, je le reconnais, il est n√©cessaire de l'√©tendre afin de mettre en Ňďuvre de nouvelles fonctionnalit√©s (dans OpenOffice.org par exemple).

                Si t'as une solution non simpliste à ce problème (mauvais exemple : faut faire de suite un format parfait pour les 30 ans à venir), donne la.

                > Certes ODF a peut être été rédigé trop rapidement

                Non. Il suffit de regarde MS-OOXML pour s'en convaincre. Rapporté au nombre de page, ODF a été ratifié ISO 20 fois moins vite !

                > Quelques reproches faits par les développeurs de Gnumeric à l'encontre de l'ODF

                Il n'y a jamais eu, Il n'y a pas, il n'y aura jamais de format parfait. √Čvidemment les critiques doivent √™tre prise en compte afin de faire les choses au mieux (et non parfaitement car c'est impossible).
                • [^] # Re: ODF pose certains probl√®mes

                  Post√© par . √Čvalu√© √† 3.

                  Si t'as une solution non simpliste à ce problème (mauvais exemple : faut faire de suite un format parfait pour les 30 ans à venir), donne la.

                  Il serait peut être temps qu'au niveau international, les Etats s'investissent davantage dans ce problème afin de construire une société de l'information qui soit à même de pérenniser ce qu'elle produit et ce qui fera son histoire.

                  > Certes ODF a peut être été rédigé trop rapidement
                  Non. Il suffit de regarde MS-OOXML pour s'en convaincre. Rapporté au nombre de page, ODF a été ratifié ISO 20 fois moins vite !


                  Comparer ODF à OOXML ne constitue sans doute pas un bon argument :-)
                  Mais si on se réfère aux besoins que vient combler ODF 1.2, n'étaient-ils déjà pas à envisager lors de la conception de ODF 1.0 ? Par exemple la signature de document. Mais d'autres limitations ont été soulevées: http://fr.wikipedia.org/wiki/OpenDocument#Limitations

                  Il n'y a jamais eu, Il n'y a pas, il n'y aura jamais de format parfait.

                  Non bien s√Ľr, mais certains formats imparfaits perdurent plus que d'autres: ASCII. C'est ce que j'attends d'un format de fichier: qu'il me facilite la vie. Mais on peut reporter les reproches sur les logiciels qui utilisent souvent la derni√®re version d'un format de fichier lors de la phase d'enregistrement sans proposer de le stocker dans une version plus ancienne toute aussi compatible...
    • [^] # Re: ODF pose certains probl√®mes

      Post√© par . √Čvalu√© √† 3.

      Il me semble que ODF 1.2 inclue ODF 1.0 donc cela ne pose pas de probleme. De plus il semblerait que pour ODF 1.2 Microsoft ait enfin change son comportement et ait decide de participer au comite. Wait and see.
  • # acid test pour odf?

    Post√© par . √Čvalu√© √† 10.

    Je me demandais s'il allait exister un test dans le même genre que le test acid pour les navigateurs web.

    Parce que odf est un standard iso soit. Mais si tout le monde s'amuse a l'implémenter "à sa sauce" ca risque de devenir le bordel le plus complet.... et se retrouver avec un odf MSOffice illisible sur OOo et inversement. Après on peut toujours dire c'est la faute a machin, mais l'utilisateur s'en fout tout ce qu'il voit c'est que son fichier texte/tableur est illisible par son voisin/amis/client/fournisseur.

    Il serrait bon, je trouve, d'avoir un document pour chaque extension (une pour le fichier texte, une pour le tableur, etc.) a ouvrir pour tester la compatibilité du format qui est normalisé iso avec celui implémenté dans le soft en question.

    De plus on se retrouve avec un argument de vente : c'est plus "je supporte tel ou tel format". C'est "j'ai un score de xxxxx points au test odf". Ca permettrai en plus a l'utilisateur de voir quand quel mesure il risque, ou non, d'avoir des problèmes de compatibilité.
    • [^] # Re: acid test pour odf?

      Post√© par . √Čvalu√© √† 4.

      En effet, ce serait sans doute utile, quoi que...

      Je crains qu'il nous refasse le coup du HTML, si c'est pour que l'ODF Ms Office ne passe pas parfaitement sous OOo, on va encore se faire avoir.

      Embrace, extend and extinguish, le retour...
      • [^] # Re: acid test pour odf?

        Post√© par . √Čvalu√© √† 4.

        si c'est pour que l'ODF Ms Office ne passe pas parfaitement sous OOo, on va encore se faire avoir.

        Bein justement non M$ Office va supporter odf. Je suppose qu'il vont le supporter parce que une grande quantité d'administration le réclame et qu'il ne vont pas le faire parce qu'une envie soudaine d'interopérabilité les démanges. Il vont implanter odf dans leur suite ca va leur permettre de dire "gardez nous on supporte un format standard". Mais s'il se pointe avec une suite qui a 2 sur 10 a odf, on va leur répondre "non mais vous vous fouttez ne notre gueule?"

        Et grace a ca je pense qu'on gagne sur les deux tableaux :

        1/ M$ Office obtient un truc genre 2/10 :
        On leur dis non ca c'est pas une implémentation correcte et on passe a OOo

        2/ M$ Office obtient un truc genre 9/10 :
        Certaine administration/société/particulier vont garder M$ Office parce qu'il est standard mais au moins s'il m'envoie un fichier texte je le lis parfaitement sur mon OOo qui lui a eu une note de 8 ou 9 sur 10 aussi. Et réciproquement si moi j'envoie un fichier a quiconque.

        Dommage que je n'ai aucune compétence dans le domaine sinon je m'y serrai bien essayé.
    • [^] # Re: acid test pour odf?

      Post√© par . √Čvalu√© √† 2.

      Il y a eu mais c'est plus a jour depuis longtemps enfin d'apres ce que j'avais pu voir. Pour un lien chercher dans les trolls sur Microsoft OXML.
    • [^] # Re: acid test pour odf?

      Post√© par . √Čvalu√© √† 9.

      Je soupçonne Microsoft de nous refaire le coup de Java.
      Il supporteront 100% ODF, mais les utilisateurs utiliseront tellement d'extensions MSWord involontairement que d'autres traitements de texte ne pourront pas les relire. MS pourra tout lire mais pas les autres.
      Comme la suite MS est majoritaire, les utilisateurs seront convaincus que les autres sont buggués.

      Mais j'ai peut être simplement un mauvais fond...
    • [^] # Re: acid test pour odf?

      Post√© par (page perso) . √Čvalu√© √† 7.

      Ou alors, développer une suite de tests que tous les lecteurs ODF doivent passer pour être déclarés compatibles. Cela aurait l'avantage d'éviter les éventuelles dérives de Microsoft sur le standard (comme ils l'ont fait avec HTML).
      • [^] # Re: acid test pour odf?

        Post√© par . √Čvalu√© √† 1.

        Bonjour,
        "une suite de tests que tous les lecteurs ODF...", Oui, c'est une solution, mais de repasser par l'organisme de normalisation pour chaque évolution est un frein à l'innovation.
        Il faudrait un comité restreint qui reçoit les propositions d'évolution nombre pair de participants, le proposant n'ayant pas le droit de vote qui doit accepter les amendements proposés pat une majorité de votants. (les temps de réponses devant être inférieur à 6 mois, alors qu'il faut souvent plusieurs années pour une normalisation)
        • [^] # Re: acid test pour odf?

          Post√© par . √Čvalu√© √† 5.

          mais de repasser par l'organisme de normalisation pour chaque évolution est un frein à l'innovation.

          Je vois pas ou on a parler de repasser par l'organisme de normalisation ni d'évolution.

          On parle la de créer un outil qui vérifie que le logiciel est bien conforme à la norme. Je ne vois pas pourquoi on devrais retourner devant l'organisme. Ou alors si, peut etre pour valider l'outil de test, comme ca c'est l'organisme qui dis que pour qu'un logiciel soit déclaré conforme il doit passer le test truc.

          Dans l'industrie on a des normes (je pense aux norme anti-feu par exemple) dans lesquelles il y a des tests a réaliser. Pour un produit, il ne suffit pas de dire "je suis conforme" pour avoir le droit de porter le logo qui va bien. Le produit doit passer les test décrits dans la norme dans un laboratoire indépendant pour etre qualifié.

          Si OOo ou MS Office prétendent supporter odf qui vérifie?

          Pour reprendre l'exemple de ma norme anti-feu:
          On peut imaginer prendre une barre de matière de 200mm de diamètre apporter la flamme d'un briquet et dire : " ha, vous voyez ? ca brule pas ! je suis conforme" alors que le norme parle elle d'une éprouvette de diamètre 10mm et d'une flamme de chalumeau ( en fait je sais plus j'ai plus les chiffres en tete mais c'est dans l'idée. on est d'accord?)

          Je vois pas ou se trouve le "frein" a l'évolution.

          On réinvente rien, on vérifie que le logiciel xxx respecte le document qui est déja validé.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.