http://www.microsoft.com/office/preview/developers/ecmafaq.m(...)
La question à regarder est : " Why is Microsoft offering a new standard, rather than simply supporting the file format for the Open Office product (sometimes called ODF)? "
Leur réponse est relativement pertinente d'un point de vue strictement technique. Mais le fait de casser du sucre sur le dos de Sun, qui n'a pas été le seul industriel impliqué dans ODF, ça c'est vraiment de la propagande gratuite.
Je veux bien admettre que l'ODF n'est pas 100% compatible avec les formats MS Office existants et/ou futurs et ne supporte pas (à ma connaissance) les mécanismes MS de gestion de droits (protection de l'information). Mais la réponse montre bien que la bataille ODF / OpenXML n'est qu'une escarmouche de plus entre Sun et MS...
Boh, remarquez: du moment qu'on a les specs, rien n'interdit de se faire un filtre XSLT pour transformer de l'ODF en OpenXML et vice versa.
Journal Pourquoi Office 12 ne supporte pas OpenDocument
26
jan.
2006
# Oui mais non
Posté par Ludovic Gasc . Évalué à 9.
Donc oui il aurait beaucoup mieux valu que tout le monde est le même format.
Il ne faut pas se leurrer, s'ils sont passé au format XML dans ms office, c'est que surement certains clients lorgnaient sur open office car il leur était possible de retraiter l'odt avec un parseur XML.
[^] # Re: Oui mais non
Posté par blobmaster . Évalué à 10.
on utilise un format "neutre" (et ouvert) mais cela n'empêche pas d'utiliser les formats spécifiques des logiciels de dessins.
Ce qu'il faut c'est un format d'échange. Mais un format unique pour tous les logiciels n'est pas forcément souhaitable en ce sens que cela risque de limiter l'ajout de fonctionnalités nouvelles. Je suis d'accord avec le fait que les fonctionnalités nouvelles en bureautique ne sont plus franchement pertinentes, mais néanmoins, il existe des gens pour en avoir besoin (envie¿) et qu'il est donc normal que des logiciels différents proposant des
fonctionnalités différentes utilisent des formats de fichiers différent.
Latex ne sera jamais (je crois)en XML pourtant il sera (est déjà?) possible de générer des .odf depuis des .tex .
Ce qu'il faut c'est un format d'échange. Et la position dominante de MSOffice sur le marché est un vrai problème (le seul?).
Les possibilités de filtrage du XML seront sûrement un plus pour l'échange de fichiers bureautique mais je suis pas sur que ce soit la seule raison du passage à OOo (coût. sécurité, indépendance...).
De plus si OOo lis les fichiers MSO et OOo
alors que MSO ne lis que les fichiers MSO, que choisiront les gens pour communiquer avec les autres ?
[^] # Re: Oui mais non
Posté par Frédéric COIFFIER . Évalué à 10.
[^] # Re: Oui mais non
Posté par Milo . Évalué à 6.
[^] # Re: Oui mais non
Posté par blobmaster . Évalué à 3.
Les .pdf sont annotables et "surlignables" et même rééditable (un logiciel proprio les inverses). Une rapide recherche permet d'en trouver sans mettre de liens "pub" ici.
Sauf l'édition des calques (la couche alpha d'un .png et l'enchaînement des calques du gifs) , qui ne me semble pas à la portée de tous, les images sont plus simples à modifiées.
[^] # Re: Oui mais non
Posté par 桃白白 . Évalué à 6.
Kword aussi \o/
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Oui mais non
Posté par 桃白白 . Évalué à 4.
[^] # Re: Oui mais non
Posté par blobmaster . Évalué à 2.
lol s'écrit lol
Tus as écris \o/
ce qui pour moi veux dire hourra !
</chieur>
sinon merci pour avoir mis en lumière la fonctionnalité que je ne connaissais pas (alors que j'utilise Kword).
Je suis en train de l'essayer en ce moment.
J'espère qu'elle est stable et ne fais pas plan
[^] # Re: Oui mais non
Posté par 桃白白 . Évalué à 2.
Pour moi aussi, c'était un houra second degré.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
# mon avis
Posté par TImaniac (site web personnel) . Évalué à 1.
Faut bien voir que les formats des suites offices ne sont pas des formats d'échanges de données "génériques". Les formats sont étroitement liés aux fonctionnalités des softs pour lesquels ils sont créés. Créer un filtre de transformation d'un format dans l'autre sera forcement imparfait et des informations seront forcement perdues.
Vu à quoi ressemble d'ODF, il aurait été idiot pour MS de le supporter natif. (un filtre import/export je dis pas). Comme il aurait été idiot que OOo utilise le format de MS en natif (au risque d'avoir un clone fonctionnel sans possibilité d'innovation).
L'idée serait peut être de réfléchir à un format d'interopérabilité (un vrai, pas ODF), qui soit assez relativement générique, et où les éditeurs de suite Office seraient réellement impliquées. Bref un format qui ne permettent pas d'avoir une compatibilité à 100% des fonctionnalités, mais qui permette au moins d'échanger un contenu, en laissant chaque acteur faire évoluer son propre format (et donc évoluer les fonctionnalités de leurs softs).
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 1.
[^] # Re: mon avis
Posté par Bruce Le Nain (site web personnel) . Évalué à 2.
http://developpeur.journaldunet.com/tutoriel/out/060124-open(...)
Aurais tu des explications ?
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 1.
Tu prends n'importe quel différence entre les 2 suites OOo et MS Office, ca te fait autant de problème potentiels dans les 2 formats (MS et ODF).
Un format interopérable doit être indépendant et reprendre les points communs, quitte à ne pas être aussi puissant que format dédié à chaque soft. Mais ca demande la création d'un vrai standard par les principaux acteurs.
De toute façon le format ODF ne pose pas de problème uniquement à MS, il pose aussi problème aux autres suite office, comme KOffice, qui ne peut supporter tout le format, ce qui en montre clairement les limites.
[^] # Re: mon avis
Posté par Eric P. . Évalué à 5.
Personne ne demande a Microsoft d'utiliser le format ODT comme format par defaut !
C'est normal qu'il garde son propre format pour pouvoir ajouter des innovations sans etre bloque. Ce qu'on lui demande est de pouvoir exporter/importer, out-of-the-box, le format ouvert ODT (de la meme facon que OOo pourra exporter/importer au format MS).
Mais non, Microsoft a refuse, et a prefere comme a son habitude ne gerer que son propre format ouvert. Comme ca il est a peu pres sur que c'est ce format qui sera utilise et que Word conservera sa position "en avance" (d'un point de vue marketing c'est tres avantageux que son format soit le format courant).
Le support de l'ODT ne posait pas de probleme:
- La rapidite ? c'est important pour le format par defaut qu'on utilise en interne mais ce n'est pas critique pour un format d'echange, qu'on utilise qu'a l'exportation.
- Les fonctionnalites non supportees ? Rien de plus normal, comme tu le dis le format d'echange est un sous-ensemble des fonctionnalites. Et pour un traitement de texte 99% des fonctionnalites courantes sont gerees a la fois par OOo et Office, et sont disponibles dans le format OOo.
Le probleme est different pour KWord qui a une architecture tres differente des deux autres (frame-based). Et pourtant ils ont fait l'effort et ont a present un support tres bon de ODT.
Saura-tu reconnaitre un jour que ce n'est pas une attitude tres ouverte de la part de Microsoft de ne pas supporter l'ODT en plus de ses formats ?
Excusez l'absence d'accents dans mes commentaires, j'habite en Australie et n'ai pas de clavier francais sous la main.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 2.
Euh... le journal pointe une FAQ (Frequently != personne) :
Why is Microsoft offering a new standard, rather than simply supporting the file format for the Open Office product (sometimes called ODF)?
Donc si, des gens se demande pourquoi MS a besoin d'un autre format que ODF.
Ce qu'on lui demande est de pouvoir exporter/importer, out-of-the-box, le format ouvert ODT
Justement ce que j'ai voulu montrer : c'est pas possible. Aussi vrai qu'il n'est pas possible que OOo gère intégralement MS Office à moins d'être fonctionnelement identique. Je vois pas l'intérêt qu'à MS à supporter "partiellement ODF" sachant qu'il sera perpétuellement critiqué justement pour ce côté "partiel" (lié à l'ODF lui même, pas à MS pourtant). En refusant d'utiliser l'ODF, ils se démarquent du courant que veut faire passer Sun : "l'ODF est un standard". En n'incluant aucun support pour l'ODF, MS montre clairement son opposition à ce format. MS implémentera donc le support de l'ODF peut être un jour, non pas parcque c'est un standard, mais parqu'il y aura beaucoup de demande de la part de ses clients (comme ils le font pour le PDF qu'ils se décident à supporter face aux demandes)
Comme ca il est a peu pres sur que c'est ce format qui sera utilise et que Word conservera sa position "en avance"
Evidemment. Et Sun tu crois qu'il tente de faire quoi en "standardisant" l'ODF ? Exactement pareil. La décision de MS est donc tout à fait logique.
La rapidite ? c'est important pour le format par defaut qu'on utilise en interne mais ce n'est pas critique pour un format d'echange, qu'on utilise qu'a l'exportation.
Si l'ODT devenait un standard de fait (comprendre répendu), t'aurais d'un côté la suite MS Office qui se coltinerait à chaque fois la lecture puis l'écriture avec en permanence une conversion : résultat lenteurs permanente (je prends l'exemple con d'un document qui circule dans une boîte où ce n'est pas comme tu dis le format d'échange mais directement le document de travail). De l'autre côté t'aura la suite OOo qui gère nativement le format et qui sera clairement avantagé.
Le problème de l'ODF, c'est de vouloir faire d'un format de travail un format d'échange. C'est avantager exclusivement une suite Office, il est tout à fait normal que MS refuse celà.
Et pour un traitement de texte 99% des fonctionnalites courantes sont gerees a la fois par OOo et Office, et sont disponibles dans le format OOo.
99% ! Genre ! Et c'est moi qui suis de mauvaise foi. Alors pourquoi OOo ne gère pas intégralement le format XML Office 2003 qui est documenté ?
Pourquoi KOffice a de nombreux problèmes à gérer le format ODF ?
S'il y a des facilités entre OOo et MS Office, c'est uniquement parcque OOo essai de "copier" MS Office (fonctionnelement) contrairement à KOffice : si comme tu dis 99% des fonctionnalités étaient identiques, on aurait 2 produits identiques : quel es l'intérêt ? Chaque concurrent (Sun, KOffice, MS) ont besoin d'avoir une liberté pour innover, et pour cela il faut un format neutre qui soit un vrai format d'échange, bref qui ne soit pas le format de travail de OOo.
Sun a voulu imposer son format tout seul, bien, bah qu'il démontre qu'il est interopérable en écrivant un plugin à Word qui fait l'import/export.
[^] # Re: mon avis
Posté par Quentin Delance . Évalué à 2.
Tu as des sources SVP ?
Sinon le plugin en question il ressemble tout betement a OOo. Ben oui OOo sait lire et ecrire les formats Office et Open Document. 100 % des fonctionnalites pour Open Document (logique) pour les formats Office je ne sais pas (donc je ne balance pas de chiffres) mais en ce qui concerne la lecture je constate qu'OOo me relit bien (pas parfaitement certes mais tres bien quand meme) les documents Office.
Donc de son cote Sun a prouve ce qu'il devait prouver (entre parentheses il n'a pas le choix car il doit coller au standard de fait). Pour MS on attend toujours, mais bon tant que plusieurs pays ou grosses entreprises n'auront pas fait la migration, il n'y a rien a attendre de leur part (meme pb pour le respect des normes du W3C qui ne devient interessant que maintenant que la part de marche de IE diminue).
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 0.
Des sources de ? Du fait que le format a était fait par Sun tout seul ? Ben pas vraiment de sources mais un constat :
Specif avant de rentrer à l'OASIS fait par Sun - Specif à la sortie de l'OASIS = aucune modification.
En gros les membres ont votés, et ils ont approuvé le format de Sun, sans rien toucher. Yahoo.
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=o(...)
Sinon le plugin en question il ressemble tout betement a OOo. Ben oui OOo sait lire et ecrire les formats Office et Open Document. 100 % des fonctionnalites pour Open Document (logique) pour les formats Office je ne sais pas (donc je ne balance pas de chiffres) mais en ce qui concerne la lecture je constate qu'OOo me relit bien (pas parfaitement certes mais tres bien quand meme) les documents Office.
Ben vas-y fait le plugin, comme ca tous les utilisateurs d'office pourront enfin lire nos documents ODF qu'on fait sous notre OS libre.
[^] # Re: mon avis
Posté par Quentin Delance . Évalué à 1.
Je dirai quand meme qu'il faut reconnaitre a SUN d'avoir standardise son format. Sans cela, il est probable que M$ n'aurait meme pas pense a commencer a essayer de tenter de la faire.
Sinon pour le plugin on ne se comprend pas.
Sun a fait sa part de boulot en faisant le "plugin office" dans OOo.
Reste a M$ a faire la sienne avec le "plugin OOo" dans Office.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 2.
Je penses que MS comme SUN cherche à standardisé leurs formats respectifs pour "appater" des clients potentiels. Le logo "standard" étant vendeur.
Sinon pour le plugin on ne se comprend pas.
Sun a fait sa part de boulot en faisant le "plugin office" dans OOo.
Reste a M$ a faire la sienne avec le "plugin OOo" dans Office.
A la différence prêt que SUN avait un intérêt à supporter le format MS : utiliser les millions de documents existant dans ce format. MS n'a aucun intérêt à utiliser le format OOo. Si SUN croît que son format peut servir de standard d'interopérabilité et qu'il gagnerait à être supporter par MS Office, c'est à lui de le démontrer.
[^] # Re: mon avis
Posté par yoho (site web personnel) . Évalué à -3.
[^] # Re: mon avis
Posté par pasBill pasGates . Évalué à 2.
[^] # Re: mon avis
Posté par Aiua . Évalué à 2.
Ils n'aiment pas qu'on leur pique leur technique ?
On parle bien de la société à la base de RTF pour mieux le pourrir ensuite ?
Non franchement, Microsoft est opposé à tout format/standart qui n'est pas le sien, ils utilisent un format qu'ils ne maîtrisent pas complêtement que qd ils y sont contraints, je ne vois pas cela comme quelque chose de positif personnellement.
Et franchement, critiquer Sun sur ces points là, ça me fait doucement rigoler, leur apport au logiciel libre est légèrement plus convaincant que celui de MS...
[^] # Re: mon avis
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Raison pour laquelle ils ont choisi d'en faire leur format par défaut dans la prochaine version, probablement ...
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 2.
Un exemple qui montre clairement que l'OASIS n'a pas fait son boulot (ou alors l'OASIS ne sert à rien) :
http://software.newsforge.com/article.pl?sid=05/09/09/192250(...)
[^] # Re: mon avis
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Euh, autant tu as donné d'autres arguments censés, autant là, tu tombes dans le FUD de bas de gamme.
Deux postes plus haut, tu disais :
il pose aussi problème aux autres suite office, comme KOffice, qui ne peut supporter tout le format, ce qui en montre clairement les limites.
Et là, on tombe dans le « ouais, mais si ça se trouve, ils y arriveront pas ». Avant de dire que Koffice a des problèmes avec ODF, attends qu'ils les ai vraiment.
Ton exemple montre un truc qui n'est pas couvert par ODF. Soit. C'est un peu comme si tu disais que HTML, c'est nul, parce que ça ne dit pas comment décoder un .jpg. Il y a un manque, mais visiblement les gens en sont conscient et ne pensent pas que ça soit du rôle de ODF de gérer ça.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 2.
Ben justement ils ont eu le problème des formules. Ils ont en partis contourné le problème en s'accordant avec OOo, mais reste qu'à la base l'ODF posait problème.
J'ai justement mis ce lien comme argument, je vois pas où est le FUD.
Ton exemple montre un truc qui n'est pas couvert par ODF.
D'où les lacunes du format ODF : avoir un format de document pour un tableur en ayant de grosses lacunes sémantique sur les formules c'est quand même balo, quoiqu'ils en disent:) KOffice se retrouvait dans l'impossibilité de ganratir l'interopérabilité de ses formules avec celles de OOo parcque l'ODF était mal foutu sur ce point là, ce que je voulais démontrer.
it. C'est un peu comme si tu disais que HTML, c'est nul, parce que ça ne dit pas comment décoder un .jpg
Non c'est comme si je disasis que l'HTML c'est nul parcque je sais pas comment créer un hyperlien. Ca sert à rien de dire "oué mais non c'est pas à l'ODF de gérer ca", les formules sont un des points clés d'un document de tableur, au même titre que les hyperliens sont des points clés du HTML.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 2.
Non on peut pas en parler parcque le format OpenXML de MS utilise un zip comme ODF :)
Cela m'etonnerait un chouilla (non je ne vais pas verifier je n'ai pas signe le NDA sur le format puis j'y connais rien au XML) vu qu'elle est cense fonctionner qu'avec un seul logiciel les autres voulant l'utiliser ayant interet a avoir la meme semantique et les memes formules que la suite office de MS sinon le meme probleme se posera.
Comprend rien à ton raisonnement. En tout cas les formules sont définis dans le draft qu'ils ont soumis à l'ECMA. Pour t'en convaincre, ben t'as qu'à vérifier, y'a pas de NDA et ca parle pas XML :-p
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 2.
Euh MS a proposé un draft, c'est du concrêt, et une beta de Office12, c'est du concrêt, pas de la théorie.
surtout que tu arretes pas d'appeler le format "theorique" de MS comme etant un standard alors que les suites offices lbres concurrentes de MS ne peuvent pas l'implementer
J'ai jamais dis ca... tu vois où que j'ai dis que le format de MS était un standard ? J'ai dis qu'il avait 2 formats de travails ouvert, et qu'il y en avait un qui se prétendait être un standard (sachant que le 2ème veut faire pareil). Pour moi y'a pas de standard, juste des formats normalisés et ouvert. Il manque toujours un standard dans l'histoire.
pour l'instant c'est la seule critique valable que j'ai pu lire sur ce format
Y'a aussi les macros par exemple. Va faire un tour sur google si tu veux trouver des problèmes :)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: mon avis
Posté par pasBill pasGates . Évalué à 2.
T'inquietes, on est pas seul :
http://linuxfr.org/comments/366876.html#366876
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: mon avis
Posté par pasBill pasGates . Évalué à 0.
Si un jour OO devient repandu, ca va changer par contre.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 2.
Vas y pointe moi le commentaire où je parle de standard MS OpenXML
[^] # Re: mon avis
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
L'article que tu cites explique justement que ce n'est pas dans ODF. C'est clairement un manque, il va falloir qu'il soit comblé, point. Ton argument plus haut, c'était que Koffice n'arriverait pas à implémenter la totalité d'ODF. C'est du FUD, pur et simple.
> Non c'est comme si je disasis que l'HTML c'est nul parcque je sais pas comment créer un hyperlien.
Ben il me semble justement que la syntaxe des URL est une RFC séparée, non ?
Si j'écris
<a href="foobar://toto.com/">mon texte</a>
C'est de l'HTML correct d'après la norme? En tous cas, ça valide en XHTML strict ...
Est-ce que ça fait de l'HTML un mauvais format ?
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 2.
Bah oui, par des lacunes sémantiques du format ODF, KOffice était incapable d'interprêter les formules contenues dans le format ODF. Le format ODF offrait bien dès le départ la possibilité d'y mettre des formules, c'est juste qu'ils ont "oublié" d'en préciser la sémantique.
Donc oui si tu veux ils auraient pu implémenter l'ODF si tu veux, techniquement le document aurait été "compliant" et respeter le schema Relax NG. J'ai FUDé si tu veux. J'aurais du dire : "KOffice n'arrive pas à lire tous les fichiers OpenDocument créés avec OOo (ce qui est balo pour un format soit disant d'interopérabilité).
Tu veux un autre exemple ?
Les macros. Pareil, le format ODF est trop laxiste, et on va se retrouver avec des différences entre KOffice et OOo à moins qu'ils se mettent d'accord encore une fois sur une extension du format ODF. Bon cela reste moins important que les formules dans le format tableur.
http://software.newsforge.com/article.pl?sid=05/09/09/164025(...)
C'est de l'HTML correct d'après la norme? En tous cas, ça valide en XHTML strict ...
Euh, dans la doc officielle du W3C le champs href est décrit comme devant contenir une URL. C'est donc écrit noir sur blanc dans les spécif le format à adopté, qu'il soit décrit dans une RFC séparée on s'en balance, le fait est que c'est clairement définies. Après si la DTD que tu utilises n'arrive pas à vérifier la syntaxe de ton URL c'est un autre problème.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: mon avis
Posté par a_jr . Évalué à 5.
Justement, pourquoi pas ODF ?
Pourquoi MS aurait-il "le droit" d'avoir son propre format, etroitement lie aux fonctionnalite du soft pour lequel il est cree et pourquoi Sun n'aurait-il pas ce meme droit ?
Pour rappel, jusqu'a aujourd'hui, le format d'interoperabilite, c'est le RTF. Pas genial !
Le bonjour chez vous,
Yves
[^] # Re: mon avis
Posté par Yoy . Évalué à 2.
Mes document openoffice 1 (et notamment les tableaux insérés dans des documents writer) n'ont pas le même rendu et la même mise en page dans openoffice 2
[^] # Re: mon avis
Posté par Charles-Victor DUCOLLET . Évalué à 2.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . Évalué à 2.
Euh... t'as lu mon post en entier ? L'ODF est étroitement lié aux fonctionnalités de OOo. Il n'est donc pas adapté à servir de standard d'interopérabilité. Sun a tout à fait le droit d'avoir ce format, c'est même ce que je préconise, OOo doit avoir un format supportant toutes les fonctionnalités d'OOo. Mais qu'on arrête de l'appeler "pompeusement" standard tout en y trouvant un gage d'interopérabilité avec d'autres suites Office qui n'ont pas les mêmes fonctionnalités.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: mon avis
Posté par a_jr . Évalué à 2.
Oui, du moins aujourd'hui.
Oui aussi. Lequel ? ODF aujourd'hui. Mais demain... ?
Bah non. Soit il est standard, et donc n'evolue pas 100% selon les desirs de Sun, soit c'est le format d'OOo et dans ce cas il ne restera pas standard pour pouvoir evoluer avec OOo.
Donc en resumant, aujourd'hui, ODF = standard <= OOo
Demain, ODF = standard, et OOo utilisera un ODF modifie selon leurs besoins.
A titre d'illustration, regardez ce qu'il est advenu du Java qui avait ete certifie ISO. Resultat, meme Sun a propose des version ulterieures qui ne sont pas compatibles avec le standard.
Sun ne manquera donc pas d'implementer des extensions de format pour OOo qui ne seront pas compatibles ODF.
La seule chose qu'on puisse esperer, c'est que ODF soit le successeur du RTF.
Le bonjour chez vous,
Yves
[^] # Re: mon avis
Posté par Frédéric COIFFIER . Évalué à 7.
Sais-tu par hasard comment on va pouvoir assurer la compatibilité entre les applications utilisant des fichiers ODF scriptés ?
# compatibilité, performance, test
Posté par Bruce Le Nain (site web personnel) . Évalué à 4.
Comment peuvent ils parler de compatibilité ascendante quand on sait pertinament qu'on ne pourra pas ouvrir un doc office 2003 avec office 95 (vu qu'on ne peut pas ouvrir un doc office 97 avec 95) ?
Intrinsic support for integrating customer-defined XML data. This enables new levels of innovation as documents generate and transport information in unique XML styles not defined by Microsoft or the document standard, but defined by the business processes of an organization.
Leur truc génial dont ils parlent, des feuilles de styles non définis par microsoft mais personnalisé, avec du xml, ça me rappelle quelque chose... ah oui, le XML et les feuilles de style...
High performance. The Microsoft OpenXML formats put a high priority on the speed of opening, closing, and working with documents, to roughly reflect or improve upon the performance of the past binary formats, rather than degrade the performance due to parsing XML.
* Donc pour rendre les choses plus rapides il faut parser du xml qui n'est pas du xml ? Ou bien faire un décompresseur/parseur plus performant, ou un format de compression adapté au logiciel ?
Robust Testing. The OpenXML formats for Microsoft Word and Excel have been part of Office 2003 and have undergone extensive real-world testing and usage, by customers and developers.
Ce n'est pas une justification pour ne pas utiliser ODF, n'importe quel format peut être robust-testé. Techniquement parlant. Après il y a toujours l'aspect "je veux imposer mon format à moi le mien"
[^] # Re: compatibilité, performance, test
Posté par tene . Évalué à 3.
Point de vue compatibilité: oui tous les documents word 95 (ou avant) ne s'ouvre pas parfaitement dans les nouvelles versions), c'est un problème, c'est historique, et c'est mal... le problème se pose également pour OpenOffice! Je ne vois pas le problème à dire: "on ne veut pas changer radicalement de format, les anciens doc restent important pour nous". Qu'aurais-tu dit s'ils avaient adopté l'attitude inverse? (désolé, les docs existants sont plus exploitables, faut passer par la nouvelles versions, ou la solution XYZ d'import qui perdra certaines caractéristiques de vos docs).
L'insertion de donnée XML tierce dans le document doit être prévu par ton format:: comment l'ajouter? un fichier à part, un arbre XML dans le XML, comment signaler au traitement de texte de les utiliser, etc... non ce n'est pas une fonctionnalité "géniale" digne d'un prix nobel, mais il précise que c'est un de leur requirement, OpenOffce n'a pas ce requirement.
Concernant la rapidité, il y'a assez de bench entre OpenOffce et Office pour voir qu'Office va généralement plus vite pour se lancer et surtout ouvrir de gros document. Est-ce mal de leur part de dire qu'ils ne veulent pas perdre cette rapidité et encore moins à cause du parsing XML (basiquement un integer se lit plus vite en binaire que s'il est sous la format <monnombre>14</monnombre).
N'importe quel format peut êter robust-testé, en dehosr du fait que ce raisonnement tiens un peu du "donnez moi des resources infinies je vous fait le logiciel idéal" (c'est oublier qu'avec 9 femmes, tu ne feras jamais un bébé en 1 mois). Mais ils parlent de "real-world usage", quel est la base existante de doc OpenDocument?
Perso, ça me saoule de voir ms critiqué pour ça, ils ont leur défaut, leur politique commerciales douteuses, leur produit buggé, etc... mais leur reprocher de ne pas avoir pris OpenDocument parce que c'est le truc hype du moment, je trouve ça injustifié, de plus leurs arguments tiennent la route (ce qui ne veut pas dire qu'ils sont la bible en mieux). Et il n'y a pas de raison que le format OpenDocument, défini de la même façon que le format Offce (autrement dit: on se calque sur nos fonctionnalités) soit assurément meilleurs.
Perso, ce que je regrette, et certains en parlent plus haut, c'est de ne pas voir naitre un vrai standard, pensé, réfléchi pour couvrir les besoins de façon générique, et non un truc existant, historique, sur lequel on va coller l'autocollant "standard". On sera après en droit de se poser les questions de respect de ses standard (on le voit avec le HTML maintenant), et de clairement reprocher à l'un ou l'autre de ne pas le respecter correctement. Par contre on aurait un format d'échange de documetn éditable, plus riche que le RTF (qui se fait vieux) et pouvant idéalement évoluer indépendememnt du produit.... mais bon je rêve.
[^] # Re: compatibilité, performance, test
Posté par TImaniac (site web personnel) . Évalué à 4.
Forcement tu prends le cas extrême. Mais leur intention est bien d'intégrer dans Office 2000/XP/2003 des filtres d'import/export vers leur nouveau format.
Leur truc génial dont ils parlent, des feuilles de styles non définis par microsoft mais personnalisé, avec du xml, ça me rappelle quelque chose... ah oui, le XML et les feuilles de style...
Tu dis n'importe quoi. Ils ne parlent pas de feuille de style à aucun moment. Essaye d'utiliser InfoPath dans Office 2003, tu comprendras mieux après de quoi ils parlent.
* Donc pour rendre les choses plus rapides il faut parser du xml qui n'est pas du xml ? Ou bien faire un décompresseur/parseur plus performant, ou un format de compression adapté au logiciel ?
La manière dont est structurée un document XML influence énormément les performances des outils qui l'utilise. Si un grand nombre de transformations est nécessaire pour passer de la représentation XML à la représentation métier de l'appli, tu peux mettre un temps fou à charger les gros documents. Suffit de voir le temps nécessaire pour charger un document MS Office dans OpenOffice.org : non pas que OOo est mal codé et super lent, c'est juste que OOo doit "transformer" un format dans un autre.
Ce n'est pas une justification pour ne pas utiliser ODF, n'importe quel format peut être robust-testé.
Non mais c'est une justification pour utiliser
Techniquement parlant. Après il y a toujours l'aspect "je veux imposer mon format à moi le mien"
Il est à peu prêt normal qu'ils préfèrent choisir un format dont ils ont testé la robustesse dans leurs applications à eux (donc entre autre testé en interne) que de se baser sur un truc nouveau inconnu pour eux. OOo fait exactement pareil en utilisant leur propre format : ils le maîtrise et c'est stratégique.
[^] # Re: compatibilité, performance, test
Posté par Bruce Le Nain (site web personnel) . Évalué à 3.
[^] # Re: compatibilité, performance, test
Posté par Charles-Victor DUCOLLET . Évalué à 1.
bon, ok, tu t'est planté a la traduction mais le foutage de geule est bien là !
Sinon, pour le reste, CF commentaire à moi plus haut !
[^] # Re: compatibilité, performance, test
Posté par Bruce Le Nain (site web personnel) . Évalué à 2.
# Pouf, pouf ...
Posté par esdeem . Évalué à 2.
Ca fait un bail que cette page existe.
Je note tout de même un un petit détail :
In conclusion, the formats are significantly different, with different design points and strengths.
La question est : c'est politiquement correcte ou c'est du cynisme de leur part?
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
# A quoi sert-il de créer Opendocument/OpenXML
Posté par Mes Zigues . Évalué à 1.
XML est une galaxie dans laquelle on peut compter CSS et XSLT-FO.
XML est conçu pour les documents, un document a une organisation hiérarchique, XML est un langage balisé hiérarchique et opendocument définit une structure à plat qui est un non-sens (je ne sais pas pour openXML).
Les balises du documents sont définies par l'utilisateur (titre 1, normal, liste puce.. ou conformément à une DTD), les mise en formes utilisent une grammaire CSS ou XSL-FO, l'interface (le traitement de texte) devant masquer la complexité de ces langages.
Une DTD ou un schéma est nécessaire, pour les métadonnées (version, auteur, générateur...) le Dublin Core est là et les attributs et instructions de traitement associés aux balises utilisateur (c'est une formule mahématique, un dessin, ce qui doit être indexé, que la partie qui suis est calculé -ie l'index- comment elle est calculé...) plein de choses utiles mais qui n'ont pas de sens dans la présentation qui ont justement été prévues par XML (voir http://www.yoyodesign.org/doc/w3c/xml11/ ).
Les défintions de Opendocument et OpenXML devraient se limiter à ce complément.
Avec un tel principe, pas besoin de connaître la DTD du document pour l'afficher, puisse que à chaque balise est associé une présentation (CSS ou XSL-FO) un logiciel de rendu suffit (Gecko), pour éditer, vous avez besoin de l'éditeur comprenant les balises spécifiques. Pour que la concurrence puisse s'exercer la DTD/schéma doit être publique.
Mais pourquoi faire simple quand on peut faire compliqué ?
[^] # Re: A quoi sert-il de créer Opendocument/OpenXML
Posté par Mithfindel (site web personnel) . Évalué à 1.
Parce que XML pur à la mano, c'est bien pour le geek^Wprogrammeur^Wdéveloppeur qui a envie de se coltiner sa XSL / CSS - non que je dénigre ceci puisque je le pratique. Sans compter que si chacun fait son format dans son coin sans demander aux autres, même en rendant DTD et schéma publics, aucune appli ne fera d'effort pour supporter les autres. Donc se mettre d'accord pour au moins utiliser un format d'échange n'est pas une idée débile du tout.
[^] # Re: A quoi sert-il de créer Opendocument/OpenXML
Posté par Mes Zigues . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.