Enfin une norme pour la bureautique : OpenDocument 1.0

Posté par . Modéré par Nÿco.
Tags :
0
26
mai
2005
Bureautique
Cela faisait quelques temps qu'on en parlait, c'est désormais chose faite : le 1er mai dernier, un message sur la liste de diffusion de l'OASIS annonçait que la version 1.0 du format de document OpenDocument, déjà utilisé par les logiciels de la suite bureautique OpenOffice, était désormais un standard de l'OASIS.

Les autres suites bureautiques libres n'ont quant à elles pas attendu cette nouvelle pour intégrer le format OpenDocument puisque la pré-version 1.4 de KOffice utilise OpenDocument par défaut et la version 2.3 de AbiWord propose aussi le support (pour le moment expérimental) de ce format.

En outre, c'est un grand pas en avant pour l'interopérabilité dans le domaine de la bureautique ; jusqu'à présent la suite Microsoft Office et ses formats propriétaires et fermés dominait le marché. Pour le moment, Microsoft, lui-même membre de l'OASIS, n'a toujours pas réagi officiellement sur le sujet.

Enfin, cette standardisation était un pas indispensable pour l'adoption du format OpenDocument par les instances européennes qui, en plus du format OpenDocument, ont décidé d'auditer le format de la suite Microsoft Office 2003 (voir http://formats-ouverts.org/blog/2004/09/27/132-LeuropeVeutDesFormatsOuverts ).

NdM : c'est le format de la suite bureautique Libre OpenOffice.org qui a été pris comme référence à ce travail de normalisation. C'est également le format de Star Office de Sun, mais aussi bientôt un format géré par KOffice, la suite bureautique de KDE. C'est donc une des grandes nouvelles de ces dernières années dans le domaine des formats ouverts car il n'existait pas de norme dans la bureautique.

NdM : Merci à jcs et à tuiu pol pour cette dépêche Ancienne version de la news :
On en parlait depuis longtemps, cette fois c'est fait : ce lundi 23 mai l'organisme de normalisation OASIS (Organisation for the Advancement of Structured Information Standards) a annoncé que ses membres ont approuvé l'Open Document Format for Office Application (Open Document) v1.0 comme standard.

(Traduction libre) « OpenDocument fournit un schéma simple de XML pour le texte, les bilans, les diagrammes, et les documents graphiques. Il se sert des normes existantes, telles que le HTML, SVG, XSL, SMIL, XLink, XForms, MathML, et Dublin Core, dans la mesure du possible. OpenDocument a été conçu comme concept de paquet, lui permettant d'être employé comme format de fichier de défaut pour des applications de bureau sans augmentation de la taille des fichiers ou de la perte d'intégrité de données. »


Extrait de la FAQ :

What is the current state of the specification?

OpenDocument 1.0 is an approved OASIS Standard, a status that signifies the highest level of ratification.

Who owns OpenDocument?

OpenDocument is owned by OASIS, a not-for-profit organization dedicated to the open development of public XML standards. OpenDocument is maintained by an OASIS Technical Committee made up of XML, document management and office application experts.

How much will it cost to use OpenDocument?


OpenDocument is royalty-free. It can be used without charge by anyone.

Who benefits from this work and how?

An open document format for office applications protects content, whether it is an 800-page airplane specification or a legal contract, from being locked into an application- or vendor-specific file format. Additionally, it lets application users participate in the benefits of XML file formats without having to change their habits and without requiring additional knowledge or education.



Attention toutefois :

au début de l'année, l'OASIS était sur le point d'accepter les brevets logiciels dans leurs standards (un peu comme le W3C à l'époque). AFUL, APRIL, FSF France et OpenOffice.org d'un côté et Groklaw de l'autre avaient alors réagi.
  • # Adoption

    Posté par . Évalué à 9.

    Comme toujours, le succès de ce format va dépendre de l'adoption de l'export OpenDocument dans les suites bureautiques "classiques". Le fait que ça soit le format d'OpenOffice va bien sûr faciliter la communication, mais d'un autre côté, c'est quand même un bon argument pour que les "concurrents" ne l'adoptent pas (vous voyez à qui je pense?).

    OpenDocument risque donc d'être LE format bureatique du libre, mais rien que du libre, et c'est bien dommage.

    Il va falloir attendre quelques mois pour voir foisonner les petits scripts de conversion, latex2opendoc, html2opendoc, opendoc2rtf, etc etc. De leur efficacité dépendra l'adoption du format par les utilisateurs...
    • [^] # Re: Adoption

      Posté par (page perso) . Évalué à 10.

      Quand les institutions européennes exigeront des documents au format OpenDocument uniquement pour toute demande de subvention, bourses, les propals, etc, ce format sera forcément démocratisé. (Voir le deuxième lien pour plus d'info).
      Dès lors, les suites bureautiques propriétaires devront le supporter, sous peine de voir leurs clients passer à des suites bureautiques alternatives qui gèrent ce format.
      • [^] # Re: Adoption

        Posté par . Évalué à 3.

        Ce jour la j'espère qu'il y aura un client léger pour lire les documents OpenDocument, parce qu'ouvrir OOo/StarOffice/Koffice pour lire un mail (ou une autre connerie) c'est pas top ;)
        • [^] # Re: Adoption

          Posté par (page perso) . Évalué à 3.

          Koffice ça va encore. :-)
          • [^] # Re: Adoption

            Posté par . Évalué à 1.

            Tiens Gof je savais pas que tu étais inscrit ici :P

            Au moins KOffice lui son interface est plus léger que OpenOffice.org et intégré au reste de KDE :)

            Vivement la version finale de la branche 1.4 pour le support OpenDoc.
        • [^] # Re: Adoption

          Posté par . Évalué à 2.

          je crois qu'il y a un debut de support dans gnumeric/abiword
        • [^] # Re: Adoption

          Posté par . Évalué à 3.

          Ce sera peut-etre un jour dans Evince.
          • [^] # Re: Adoption

            Posté par (page perso) . Évalué à 2.

            ...et less ?
            • [^] # Re: Adoption

              Posté par . Évalué à 4.

              ou un equivalent de catdoc (on me souffle a l'oreille qu'il exite deja des outils pour extraire le texte du xml, il reste plus qu'a ajouter une formatation simple et ca devrait etre bon).
        • [^] # Re: Adoption

          Posté par . Évalué à 3.

          Salut,

          Il y a aussi Visioo-Writter, tres tres jeune.
          Les devellopeurs ne demandent que des conseils pour avancer, c'est leurs premier projets.
          http://visioo-writer.tuxfamily.org/

          @+
          HL
        • [^] # Re: Adoption

          Posté par . Évalué à 2.

          c'est une super nouvelle : je n'utilise que OpenOffice pour le moment car il est très complet, et supporte le mieux les import / export vers msoffice (j'avais testé abiword à l'époque, sur un gros document rtf à moi, il plantait). Par contre OOo est très lourd, et je voulais tester de nouveaux logiciels, à utiliser selon la machine que j'ai à disposition. Abiword semble de mieux en mieux notamment, mais pour le moment n'exporte pas le format OOo qu'il a importé, si bientôt l'interoperativité est totale, on pourra communiquer avec tous ces logiciels...

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: Adoption

          Posté par (page perso) . Évalué à 0.

          Ce jour la j'espère qu'il y aura un client léger pour lire les documents OpenDocument,
          vi ou emacs ?
          • [^] # Re: Adoption

            Posté par (page perso) . Évalué à 1.

            >Ce jour la j'espère qu'il y aura un client léger pour lire les documents OpenDocument,
            >vi ou emacs ?


            Clients légers, je commence à avoir des doutes, clients utilisable sous console, c'est déjà plus réaliste.

            A l'ére du giga-octect de mémoire tout est relatif

            Le poids des archives complétes (sources + docs+ ressources) sous gentoo (j'ai classé par ordre alphabétique pour ne pas faire de Troll :-) :

            * app-editors/emacs
            Latest version available: 21.4
            Size of downloaded files: 23,249 kB
            * app-editors/vim
            Latest version available: 6.3.068
            Size of downloaded files: 4,746 kB
            * app-editors/xemacs
            Latest version available: 21.4.15-r3
            Size of downloaded files: 10,441 kB

            Pour comparaison (je triche un peu, les gentooiste trouveront la faille :-)
            * app-office/openoffice-bin
            Latest version available: 1.1.4-r1
            Size of downloaded files: 78,564 kB
            * app-editors/nano
            Latest version available: 1.3.7
            Size of downloaded files: 985 kB

            A noter que l'executable de nano fait 116ko sur ma machine.

            Quand on se rappelle qu'on faisait du turbo-c ou turbo pascal sous dos avec 640ko avec une ide qui était déjà trés agréable (mais en caractéres).

            Que sur mon amiga, j'avais 1mo de ram et que je n'ai jamais autant programmé parce que je considérais qu'il fallait dépasser les limites.

            Alors dire qu'emacs ou vim c'est du client léger, rien que la taille de l'archive n'est pas téléchargeable avec un modem 56ko.

            Après on aime ou on aime pas, mais plus rien n'est léger en 2005, il faut quand même des procs à >100mhz et >16mo de ram pour faire marcher quelquechose.

            Tiens un gars qui fait son serveur web en circuit logique à 3mhz et qui a un meilleur temps de réponse que la plupart des serveurs web "pro", ça c'est même de l'ULM
            http://64.142.4.132/(...)

            Je ne dis pas qu'avant c'était mieux, je dis que l'informatique est devenue obèse parce qu'on ne cherche plus l'optimisation.

            On a la puissance, pourquoi pas, c'est plus zolis, on aplus d'aide contextuelle, c'est pas forcément un mal, et ça améliore même la productivité parfoit
            mais arrétons de se leurrer en parlant de "léger"
    • [^] # Re: Adoption

      Posté par . Évalué à 1.

      De toutes façons, il y aura des problèmes avec les brevets logiciels, si ce n'est pas avec des brevets existants, les USA préparent une réforme des brevets et si elle a lieu, il sera possible pour Microsoft et les autres de déposer des brevets sur des points clef des technologies utilisées dans le logiciel libre sans qu'il y ait encore moyen de les invalider via le priort art.
      • [^] # Re: Adoption

        Posté par . Évalué à 5.

        Bon, ça ne resterait que les USA...
        Espérons que l'UE ne tombera pas dans le panneau.
    • [^] # Re: Adoption - "plugin" Msword

      Posté par (page perso) . Évalué à 7.

      Dites, est-ce si difficile de créer un filtre pour Word par exemple ? Ca ressemble a un plugin, dans mes souvenir a l'installation de Word on peux cocher les filtres d'import/export que l'on souhaite, pourquoi ne pas proposer un filtre Word pour OOo/OpenDocument ?
    • [^] # Re: Adoption

      Posté par . Évalué à 2.

      Le fait que ce soit ouvert, documenté, fait que la solution OpenOffice peut être plus intéressante que MS Office dans un projet ou le logiciel de bureautique n'est qu'un brique parmi d'autres.

      Mais du coup, c'est l'occasion de faire rentrer ce format dans une entreprise.
      • [^] # Re: Adoption

        Posté par . Évalué à 4.

        Encore faut-il pouvoir les ouvrir avec word pour avoir une chance de les faire entrer en entreprise... La majorité des entreprises est équippée en microsoft et il en faudra beaucoup pour que les décideurs prennent l'OASIS au sérieux si ce n'est pas supporté par Microsoft.

        Je bosse dans une banque, et dans ce genre d'endroit, l'ouverture aux nouveautés est directement conditionnée par la compatibilité avec les produits déjà achetés. Pas de révolution possible, les évolutions étant déjà un luxe souvent inacceptable. Si on ne peut ouvrir les documents OASIS avec MS Office, il n'y a malheureusement pas l'ombre d'une chance de les voir adoptés chez nous.
        • [^] # Re: Adoption

          Posté par (page perso) . Évalué à 2.

          Ni chez 99% des utilisateurs d'une suite bureautique...
        • [^] # Re: Adoption

          Posté par (page perso) . Évalué à 7.

          Encore faut-il pouvoir les ouvrir avec word pour avoir une chance de les faire entrer en entreprise...

          Très mauvais raisonnement ! C'est justement en envoyant des documents avec des nouveaux formats que l'on oblige son correspondant à se procurer le plugin ou le programme qui permet de les lire.
          Ce procédé qui a été employé par Word, Acrobat, Flash, ... Alors, il faut renvoyer l'ascenseur. De cette façon, on peut espérer stopper le rouleau compresseur de Microsoft.
          • [^] # Re: Adoption

            Posté par (page perso) . Évalué à 2.

            Oui, c'est tout a fait ce que l'on dit, tant qu'il n'y aura pas de plugin word pour ouvrir et même mieux enregistrer au format OOo ou OpenDocument, les gens continuerons à s'échanger des .doc, même crées par OOo
            • [^] # Re: Adoption

              Posté par . Évalué à 5.

              De toute façon, pour que les gens changent, ils faut une pression
              suffisante. Si je reçois 1 fichier au format .zgk, je remande qu'on
              me trouve un autre format. Si j'en reçois 15, je cherche un outil
              pour gérer les .zgk (que ce soit un plugin pour truc ou un
              programme indépendant).

              Supposons que l'état impose le format .zgk pour sa gestion interne
              et toutes les communications avec l'extérieur, cela crée une
              pression important pour quiconque veut communiquer avec l'état.
              À partir de cela, un certain nombre de boites vont trouver un moyen
              d'utiliser le format .zgk. Ensuite, ils utiliseront naturellement le
              même logiciel ou plugin pour communiquer avec d'autres boites qui,
              elles, ne travaillent pas directement avec l'état. De proche en
              proche, un certain nombre de boites vont utiliser ce format. On peut
              aussi imaginer que les personnes qui se retrouvent à travailler tous
              les jours avec des .zgi, vont aussi l'utiliser chez elles. On verra
              apparaître des emails: « regarde mes photos de vacances » au
              format .zgk et assez vite, tout le monde gèrera le .zgk.

              C'est comme tout, il faut une masse critique. L'état peut l'imposer
              et comme ils semblent chasser les coûts, il est possible qu'ils
              utilisent vraiment openoffice.org et donc les formats associés.
          • [^] # Re: Adoption

            Posté par . Évalué à 3.

            Très mauvais raisonnement ! C'est justement en envoyant des documents avec des nouveaux formats que l'on oblige son correspondant à se procurer le plugin ou le programme qui permet de les lire.

            La première migration à faire, c'est celle des institutions publiques. Si eux-même n'utilisent pas des logiciels compatibles OASIS, ça ne sera qu'un mouvement de bureaucratie inutile et coûteux que de réclamer des documents au format OASIS si c'est ensuite pour devoir les reconvertir en word pour usage interne.

            Une fois la migration effectuée, là on pourra envisager d'exiger des fichiers au formats OASIS, pas avant.

            Mais il y a fort à parier que les entités communiquant avec le gouvernement prendront des convertisseurs et bosseront en interne sous word plutôt que de faire la migration.

            En tout cas, sii c'est pour faire une conversion word=>OASIS d'un côté et faire OASIS=>word de l'autre, c'est débile.

            Le gouvernement n'a pas vocation à stopper le rouleau compresseur Microsoft.
            • [^] # Re: Adoption

              Posté par . Évalué à 9.

              Le gouvernement n'a pas pour vocation d'engraisser une
              boite de Redmond.
              • [^] # Re: Adoption

                Posté par . Évalué à 1.

                Le gouvernement est un consommateur au même titre qu'une entreprise. C'est tout... et imposer des standards de documents qui ne sont utilisés nulle part (ou disons plutôt par une minorité très minoritaire), c'est limite du totalitarisme...
                • [^] # Re: Adoption

                  Posté par . Évalué à 1.

                  Sauf, comme on le voit bin ici, si le choix d'un format au détriment d'un autre est un choix politique. Jusqu'à preuve du contraire, un gouvernement a le droit de faire des choix politiques... (troll sur la constitution européenne en vue, toussa toussa, mais les meilleurs trolls ne sortent pas de leur grotte le lundi matin).
  • # dépêche

    Posté par . Évalué à 8.

    Oula merci à ceux qui ont modérés/édités la dépêche d'origine : elle a considérablement été améliorée :)
    • [^] # Re: dépêche

      Posté par (page perso) . Évalué à 3.

      Ne te diminue pas, tu y as fortement contribué en plantant la petite graine qui a permi d'étoffer... (snif, c'est beau...) Merci à toi ! ;-)
  • # Extensions des fichiers : od[tgpsicfmh]

    Posté par . Évalué à 8.

    J'allais poser la question sur les extensions de fichier qui serons employées, mais j'ai finalement trouvé tout seul en cherchant un peu !
    Alors les voilà pour ceux que ça intéresse aussi :
    odt pour les documents de texte.
    odg pour les documents graphiques (dessin).
    odp pour les documents de présentation.
    ods pour les documents de tableurs.
    odi pour les images.
    odc pour les graphes.
    odf pour les formules.
    odm pour les documents globaux de texte.
    odh pour les documents html.

    La traduction est approximative et peu-être pas très exacte. L'original se trouve dans le PDF http://www.oasis-open.org/committees/download.php/12572/OpenDocumen(...) (p 697-698)
    • [^] # Re: Extensions des fichiers : à propos du format

      Posté par . Évalué à 3.

      Si j'ai bien compris, c'est juste un renommage des formats d'OpenOffice ou il y a eu des modifications faisant qu'il serait impossible de lire un odt avec OpenOffice 1 ?
    • [^] # Re: Extensions des fichiers : od[tgpsicfmh]

      Posté par . Évalué à 4.

      > odh pour les documents html.

      A quoi cela peut-il bien servir ??
      • [^] # Re: Extensions des fichiers : od[tgpsicfmh]

        Posté par . Évalué à 5.

        > odh pour les documents html.

        A quoi cela peut-il bien servir ??


        Peut être à mettre tout un document web (page Html + Css + images) dans un seul document odh ?

        Mais ce n'est qu'un hypothèse.
    • [^] # Re: Extensions des fichiers : od[tgpsicfmh]

      Posté par . Évalué à 10.

      Ils auraient du s'appeler DocumentOpen à la place de OpenDocument, ça aurait fait:

      dot pour les documents de texte (et donc des document dot dot).
      dog pour les documents graphiques (en plus c'est marrant, genre:"envoie-moi le dog faut que je le retouche").
      dop pour les documents de présentation (et P'tit Dop?).
      dos pour les documents de tableurs (le retour du fils de vengeance du DOS?).
      doi pour les images.
      doc pour les graphes. (oui bon là ça pose problème)
      dof pour les formules.
      dom pour les documents globaux de texte.
      doh pour les documents html (mais où est homer?).
      • [^] # Re: Extensions des fichiers : od[tgpsicfmh]

        Posté par (page perso) . Évalué à 10.

        /mode gros gros lourd/
        -j'ai besoin de l'image... tu me fais un doi, stp ?
        -tu veux pas un whisky d'abord ?
        /mode off/

        ----------------------------------------------------------------------------------------->[]
        • [^] # Re: Extensions des fichiers : od[tgpsicfmh]

          Posté par . Évalué à 2.

          J'ai pas compris tout de suite, mais c'est vrai que c'est très "mode gros lourd".
          explication: je prononce doï en fait, comme oï (punk toussa), donc "d-ou-oy". Ça permet de différencier de doa (DocumentOpen Archive? Animation? Association? ...).
      • [^] # Re: Extensions des fichiers : od[tgpsicfmh]

        Posté par . Évalué à 9.

        Gageons que la fameuse Comission Générale de Terminologie et de Néologie accédera à ta requête en utilisant les termes Document Ouvert {t,g,p,s,i,c,f,m,h}, si bien sûr elle trouve des traductions farfelues pour chacun.
        • [^] # Re: Extensions des fichiers : od[tgpsicfmh]

          Posté par . Évalué à 2.

          J'ai épuisé mes 25 votes aujourd'hui, donc je peux pas te plusser, mais le c½ur y est!

          note pour plus tard: Je sais que c'est con, mais ma proposition rendrait la "terminologie" OpenDocument bien plus "concrète", et acceptable plus facilement par le commun des mortels. Reste à justifier cette inversion d'ordre, qui n'est pas intuitive en anglais (mais logique en francais/espagnol/italien/...). Desfois l'acceptation d'une norme passe par sa logique et sa simplicité (en l'occurrence 3 lettres réduisible à un seul son, et non pas des trucs barbarres du genre "o-d-t"!). Même en anglais ça marche (=un seul son), donc pourquoi pas le proposer à l'"OpenDocument Fondation" (enfin le truc qui normalise quoi)? Quand on voit la note de mon commentaire (10 actuellement), ça veut bien dire quelque chose, nan?
      • [^] # Re: Extensions des fichiers : od[tgpsicfmh]

        Posté par (page perso) . Évalué à 2.

        euh, dot est déjà pris par MS Word (c'est le format des modèle de document (DOcument Template), donc c'est pas une super bonne idée...
        Enfin de toute façon sous Linux la plupart des navigateurs de fichiers détermine le type d'un fichier à son type mime et non à son extension, et sous Windows l'utilisateur ne voit pas l'extension (par défaut), donc bon, même si les version od* sont moins facile à prononcer, ils ont l'avantage d'être très peu utilisés.
        • [^] # Re: Extensions des fichiers : od[tgpsicfmh]

          Posté par . Évalué à 7.

          Enfin de toute façon sous Linux la plupart des navigateurs de fichiers détermine le type d'un fichier à son type mime et non à son extension [...]

          Le problème avec les fichiers .od* ( et .sx* ) c'est que ce sont des archives Zip. Si tu supprimes le suffixe, ton navigateur te propose d'ouvrir le document avec ton gestionnaire d'archives :-/
          • [^] # Re: Extensions des fichiers : od[tgpsicfmh]

            Posté par (page perso) . Évalué à 2.

            Un problème ? un avantage oui, c'est bien le principe : reposer sur des trucs ouverts et relativements courants/standards.
            Quand au zip avec une autre extension c'est assez courant (.jar et .xpi par exemple) pour qu'un de plus ou moins n'y change pas grand chose.
            • [^] # Re: Extensions des fichiers : od[tgpsicfmh]

              Posté par (page perso) . Évalué à 3.

              Dans ce cas précis c'est un problème : en l'absence d'extension il n'est pas possible de déterminer la nature du document "zippé". Il faut donc judicieusement choisir l'extension et, si possible, en choisir une non utilisée afin d'éviter les confusions.
            • [^] # Re: Extensions des fichiers : od[tgpsicfmh]

              Posté par . Évalué à 3.

               Un problème ? un avantage oui, [...] 

              Effectivement, ma remarque était mal formulée et pouvait prêter à confusion. J'aurais du m'exprimer ainsi :

              « Il n'est pas possible de déterminer le format d'un fichier OpenOffice/OpenDocument à l'aide de son type mime. Les fichiers en question sont des archives Zip et la présence d'une extension est donc nécessaire. »

               [...] c'est bien le principe : reposer sur des trucs ouverts et relativements courants/standards. 

              On peut « reposer sur des trucs ouverts et relativement courants/standards » sans pour autant tout mettre dans une archive Zip et devoir bricoler avec les extensions. Le premier exemple qui me vient à l'esprit est le format des paquets Debian ( .deb ) [1] ; une simple archive ar dans laquelle le premier fichier archivé permet d'obtenir un magic number spécifique.

              [1] $ man 5 deb ou http://www.annodex.net/cgi-bin/man/man2html?5+deb(...)
        • [^] # Re: Extensions des fichiers : od[tgpsicfmh]

          Posté par (page perso) . Évalué à 2.

          dot est également pris par graphviz, d'ailleurs.
  • # J'adore OpenOffice.org, mais...

    Posté par . Évalué à 10.

    OpenDocument (...) se sert des normes existantes, telles que le HTML, SVG, XSL, (...) dans la mesure du possible.

    Malheureusement, la gallerie de OpenOffice.org 2.0 (m104) ne permet toujours pas d'utiliser les "OpenClipart.org" au format SVG... ce qui est franchement dommage quand on voit le peu d'objets disponibles par défaut.

    C'est limite hors sujet... mais y'a les "moinssages" au besoin ;-)
  • # Est-ce suffisant pour une bonne interopérabilité

    Posté par . Évalué à 10.

    Pour moi, OpenDocument est une promesse de pouvoir utiliser de façon transparante l'application de mon choix tout en travaillant en collaboration.

    Or, je vois deux failles dans cette approche.

    1: Il me semble bien que OpenDocument permet d'utiliser des champs « propriétaires » spécifiques à une application (foreing elements chaptitre 1.5).

    Supposons que ce format devienne obligatoire ou imposé pour des réponses à appel d'offre.
    Or supposons qu'un éditeur ce veux pas de cette compatibilité (il cherche à verrouiller l'utilisation de son logiciel que ses super marketeux sont arrivé a vendre comme des petits pains).
    Mais cette éditeur souhaite quand même obtenir le label « OpenDocument » pour pouvoir le vendre à des société qui l'exige.
    Il peut utiliser un format 100% Valide en OpenDocument en utilisant de façon intensive des champs « propriétaires » quitte à utiliser ses champs même pour des propriété triviaux qu'il aurait pu décrire en utilisant des champs de la norme (genre mettre le texte dans un « foreing element » mais codé en rot13). Les autres softs ne pourront pas le lire car ils ne pourront pas interpréter correctement des propriétés indispensables.
    De plus, il peut même décrédibiliser openOffice et consort en se permettant de lire leurs fichiers alors qu'eux ne peuvent pas (</mauvaise fois on>quelle bouse ce oo, il ne peut même pas lire ce fichier openDocument valide alors que mon magicOffice y arrive sans problème <mauvaise fois off>)

    2: Je ne vois comment traiter correctement l'écart de fonctionnalité entre les soft (même entre des soft qui « jouent le jeux »)

    OpenDocument est un format intégrant le maximum de fonctionnalité. Chaque suite bureautique n'utilise qu'une partie de celle-ci. Mais si la suite A utilise une propriété qui à un impact sur le fichier, rien n'assure que la suite B saura l'interpréter correctement. Et si cette propriété m'est indispensable pour la bonne compréhension du document, j'ai un problème. Prenons par exemple une transition dans une diapositive qui me permet de faire apparaître un élément graphique de manière particulièrement éclairante pour ma présentation. Je créé mon document sous Oo. Je l'envoie à mon client. Il le lit sous KOffice et n'y comprend rien.

    Je ne peut donc pas envoyer un document (même si c'est OpenDocument) à une personne en étant sur qu'il puisse tout lire, le modifier et me le renvoyer sans problème.


    En conclusion :
    Si mes peurs sont justifiées, je vais être déçus. Bien que cela soit une grande avancée dans l'interopérabilité, pour moi, cela ne permet pas d'avoir un document d'échange éditable sans soucis. Et je pense que cela à été sur-vendu et que la déception qui pourrai en suivre serai très dommageable.

    __
    Je me suis laché pour mon premier post
    • [^] # Re: Est-ce suffisant pour une bonne interopérabilité

      Posté par . Évalué à 3.

      Je suis convaincu :)

      Les informations spécifiques ne devraient concerner que les fonctionnalités impossibles à implémenter dans OpenDocument. Ainsi, tout passerait "le mieux possible", tout en préservant des informations mineures si on a la chance de l'ouvrir avec la même appli. J'imagine que ces champs "propriétaires" sont là pour permettre de garder un format OpenDocument natif, tout en faisant évoluer les capacités du logiciel.

      Si on peut utiliser ces champs pour y mettre des choses qui devraient être ailleurs, alors c'est la porte ouverte à tous les abus, parce que 1) certains ne vont pas se priver d'y mettre tout et n'importe quoi pour se rendre incompatibles avec le reste du marché, et 2) certains vont trouver de bon ton de lire ces champs pour se rendre compatibles avec le premier "tricheur", je ne vous raconte pas le bordel.

      En ce qui concerne la perte d'information dans les softs les moins évolués, j'ai des doutes. En effet, le XML est particulièrement bien adapté à ça : un champ qu'on ne connait pas, on ne le lit pas, et il reste tel quel. Donc on enregistre, et l'information persistera. Alors oui, ça ne "passera" pas pareil, mais au moins, il n'y aura pas de perte lors des aller-retours. Enfin ça, c'est dans un monde idéal, quand même...
    • [^] # Re: Est-ce suffisant pour une bonne interopérabilité

      Posté par (page perso) . Évalué à 3.

      >Or supposons qu'un éditeur ce veux pas de cette compatibilité (il cherche à verrouiller l'utilisation de son logiciel que ses super marketeux sont arrivé a vendre comme des petits pains).

      oui MAIS supposons que les organismes public qui exige le format OpenDocument n'est pas asser d'argent (les organisme public sont TOUJOURS en manque d'argent)pour acheter la super suitedelamortquituetcompletementferme et utilise plutot le logiciel libreparcequecestgratuit.

      alors l'entreprise qui voudra echanger des fichiers avec les organismes public devront se conformer au logiciel libre (et n'acheterons pas magic office)

      et l'experience montre que les organisme public se mettent au logiciel libreparcequecestgratuit (munich,mairie du 13eme, gendarmerie, ...)
  • # un viewer rapide ?

    Posté par (page perso) . Évalué à 5.

    Tout ça, c'est très bien, mais si j'envois mon fichier opendoc à quelqu'un qui n'a pas Openoffice sur sa machine, ça risque d'un peu l'embêter d'installer toute la suite juste pour visualiser ce document.

    Il faudrait donc écrire un visualisateur léger qui tourne sous toutes les plate-formes...

    Note : le "léger" est là pour éliminer Openoffice et Acrobat Reader !
  • # Ceci n'est pas une norme

    Posté par . Évalué à 5.

    Le titre est un attrape couillon, Opendocument n'est pas encore une norme, ce n'est qu'un standard, adopté par un organisme de standardisation, important certe, mais ce n'est pas une norme.

    Une des caractéristiques d'une norme, en droit fanrçais, est d'être opposable dans les appels d'offres. Pour cela, le texte doit être publié, avec un niveau norme, soit par le CEN (comme ça c'est pareil dans tous les payes européens) soit par l'AFNOR (la publication à l'ISO n'impose rien au niveau français).

    Pour le moment, rien n'oblige (ni n'interdit) un acheteur public à mettre dans son appel d'offres l'obligation que les logiciels bureautiques achetés produisent des fichiers conformes à Opendocument.

    Quelqu'un aurait-il des information sur l'adoption d'Opendocument par les instances européennes ou françaises ?

    Pour mémoire, il existe 2 normes internationales (ISO) concernant le format des documents : ODA et SGML.
    • [^] # Re: C'est une norme !

      Posté par (page perso) . Évalué à 4.

      Les anglophones n'ont qu'un mot : standard. Ils font donc la confusion entre deux notions, comme ils la font avec le mot free. Le pire est qu'ils nous exportent leur confusion.

      En français, nous avons deux mots : norme et standard.
      Le standard est décrété par le fabricant - Modèle standard.
      La norme est publiée et gérée par un organisme indépendant de ceux qui l'appliquent.

      Le W3C comme OASIS publient des normes, Le PDF est un standard créé et géré par Adobe.

      Je ne parle pas des standards des documents Microsoft, le seul à ma connaissance qu'ils ont publié, le RTF n'est pas respecté.
      • [^] # Re: C'est une norme !

        Posté par (page perso) . Évalué à 0.

        > Je ne parle pas des standards des documents Microsoft, le seul à ma connaissance qu'ils ont publié, le RTF

        Euh, faudrait se renseigner un peu et arrêter le FUD, non ?
      • [^] # Re: C'est une norme !

        Posté par . Évalué à 1.

        D'où la définition quand on parle avec des anglo saxon :
        standard de jure (ayant valeur juridique) pour les normes officielles (AFNOR, ISO, CEN, DIN, BSI, JIS...)
        standard de facto pour les textes produits ailleurs (soit par un consortium - OASIS, W3C... dans ce cas on va plutôt qualifier le standard d'ouvert- soit par un industriel dans ce cas on va plutôt qualifier le standard de fermé).

Suivre le flux des commentaires

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