Cette derniere semaine, on a pas mal parle d'Office 2007 SP2 et son support soi-disant bancal d'ODF.
Vu que certains d'entre vous n'ont rien a faire au boulot, je me suis dit que j'allais demarrer un journal pour vous occuper un peu...
http://blogs.msdn.com/dmahugh/archive/2009/05/09/1-2-1.aspx
First, I fired up Symphony 1.2, and followed these steps:
Enter a numeric value of 1 in cell A1.
Format cell A2 as text, right-justified, then enter a 2 in that cell.
In cell A3, enter the formula =A1+A2.
...
One of the most interesting things I found in my testing of these two implementations was that although they write different markup for formulas, the exact same interoperability problem occurs regardless of which application is used to create the spreadsheet.
If you create the spreadsheet in Symphony 1.2, as I did, the table:table-cell element has a table:formula attribute with a value of "=[.A1]+[.A2]". And this formula will yield a result of 3 in Symphony and 1 in OpenOffice.org, as described above.
If instead you create the same spreadsheet in OpenOffice.org 3.1, when you open it in Symphony 1.2 you'll see of:=A1+A2 in cell A3. But after you manually correct the formula, this spreadsheet, too, will yield a result of 3 in Symphony and 1 in OpenOffice.org.
So these two ODF implementations do not have predictable formula interoperability, regardless of where you start. And these are not obscure implementations – they are the latest released versions of the implementations from IBM and Sun, the two companies that together chair the ODF TC.
Pour rapidement resumer le probleme : le manque de definition des formules d'ODF fait que des tableurs, pourtant bases sur le meme code a la base, interpretent la meme formule differemment.
Symphony genere un fichier ODF 1.0/1.1, qui lorsqu'il est lu par OOo 3.1 donne un resultat totalement different, et ce qui est triste est qu'aucun des 2 n'a tort, car il n'y a pas de definition formelle du comportement dans ODF 1.1...
Il faut donc croire que passer des feuilles de calcul entre Symphony 1.2 et OOo 3.1, alors que les 2 sont bases sur le meme code a la base, est pas conseille...
Journal Oui je sais, on est pas Vendredi
11
mai
2009
# Effectivement on est pas vendredi
Posté par Guillaume Rossignol . Évalué à -4.
Et puis on est sur linuxFR ici, alors quatre paragraphes en anglais, tu te rends compte.
Hum ? quoi ? le fond ? celui qu'on voit quand on finit le verre ?
Ah, pas celui là :/
Je ne dirai que : «Vive les formats ouverts qui permettent l'interopérabilité»
===> []
[^] # Re: Effectivement on est pas vendredi
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
L'important dans cette phrase n'est-ce pas : « ... qui permettent l'interopérabilité» ?
On utilise des standards ouverts pour permettre l'interopérabilité et essentiellement dans ce but. Dans le monde des bisounours, les standards ouverts sont parfaits et suffisants pour permettre l'interopérabilité. Dans la réalité, l'utilisation de standards ouverts n'est qu'une condition nécessaire et en aucun cas un but en soit. Deux points importants que ne semblent toujours pas avoir digérer les trolleurs de billou.
Sans vouloir relancer le troll : il me semble que tout le monde a compris que MS avait fait une belle implémentation quasi conforme du standard ODF avec en toile de fond une très nette volonté de non interopérabilité. Toutes les remarques, venant d'un camp comme de l'autre, dans les trolls précédents me semblent converger dans ce sens. J'ai donc beaucoup de mal à comprendre ce que les gens cherchent à démontrer dans les trolls de plusieurs centaines de messages précédents. Quelqu'un peut m'expliquer ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Effectivement on est pas vendredi
Posté par pasBill pasGates . Évalué à 10.
Un format auquel il manque de larges blocs empechant l'interop, alors qu'il se veut etre un format permettant l'interop, ne merite manifestement pas la denomination de standard, ca me semble evident.
Mettre la faute sur MS en particulier alors que visiblement meme 2 suites basees sur le meme code libre sont incapable de s'echanger correctement des documents du meme format n'est rien d'autre que de l'hypocrisie.
[^] # Re: Effectivement on est pas vendredi
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 10.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Effectivement on est pas vendredi
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Référence nécessaire.
Je vois bien Ishihara Shintarô, gouverneur de Tôkyô, dire de telles naiseries, mais pas plus. Il avait dit en 2004 ou 2005 que les Français ne savaient pas compter et qu'ils étaient nuls en maths (et je me suis fait interviewer par la télé japonaise où j'ai pu gentiment montrer qu'il disait de la merde en boite.)
Concernant les trous dans le standard, je vois deux choses.
1- Si c'est cassé, alors il faut patcher le standard. Le langage Scheme corrige rapidement les inconsistences de son standard, pourquoi ne le ferait-on pas ici aussi ?
2- Si personne ne corrige, qu'on ne reproche pas à l'un de volontairement implanter telle stratégie d'interprétation. Si ça se trouve, la mauvaise foi des autres les pousse à implanter l'autre stratégie afin de creuser un fossé.
3- (bonus !) J'imagine qu'il y a des méta-données, donc qu'on peut préciser dans le fichier quelle stratégie a été utilisée pour pallier ce problème.
Pour conclure :
Un programme fait ce qu'on a écrit, pas ce qu'on pensait avoir écrit. De même, un standard implanté qui ne se comporte pas comme on pensait l'avoir défini est la faute des concepteurs, aucunement des implanteurs.
Nous sommes donc d'accord : il faut retravailler le standard. Mais si MS pense à son fric et le libre a sa liberté, alors c'est au libre de faire un effort pour optimiser les échanges (et avoir l'interopérabilité optimale). MS ou d'autres boites ne vont pas obéir au libre pour ses beaux yeux.
[^] # Re: Effectivement on est pas vendredi
Posté par thedude . Évalué à 3.
Ben en fait, ca resoudrait pas grand chose.
Deux cas:
- La meta donnee est pas standardisee et c'est status quo avec la situation actuelle: faut se fader les differentes implem pour voir qui fait quoi et ce qu'il annonce
- La meta donnee est standardisee: bah si c'est pour standardise un hack, autant faire le boulot proprement et specifier ce que doit etre le comportement, plutot que de specifier ce que fait chaque implem.
De même, un standard implanté qui ne se comporte pas comme on pensait l'avoir défini est la faute des concepteurs, aucunement des implanteurs.
Ca se discute, en fonction de la qualite de definition du standard. Mais quand la definition est inexistante, oui, la faute incombe integralement au concepteur, notamment celui qui apres avoir explicitement dit aux vendors "pour les formules, faites comme vous'l' voul', c'est vous qui choise", gueule comme un putois sur certains vendors (mais pas tous) parce qu'ils ont fait commes ils voulaient.
[^] # Re: Effectivement on est pas vendredi
Posté par zebra3 . Évalué à 2.
Disons que MS ne vaut pas mieux qu'IBM alors, car bien qu'ayant toutes les cartes en main pour enfin paraître de bonne foi aux yeux du logiciel libre, en prenant l'implémentation d'OOo que l'on pourrait qualifier de « référence » en le sens où c'est la plus répandue (d'autant qu'en plus, MS est passé maître dans l'art d'utiliser des standard *de fait*), ils ont manifestement fait preuve de toute leur mauvaise foi et de leur dédain face à ce logiciel libre.
Que cela ne soit pas leur faute, soit. Mais cela montre bien qu'on ne peut guère leur faire confiance quant à l'interopérabilité (s'il était nécessaire de le faire une nouvelle fois).
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Effectivement on est pas vendredi
Posté par pasBill pasGates . Évalué à 8.
Je trouves quand meme assez gros la maniere dont vous evitez absolument de mettre la moindre faute sur ODF lui-meme ou OOo lui-meme, faudrait un minimum d'impartialite quand meme.
[^] # Re: Effectivement on est pas vendredi
Posté par Nicolas Boulay (site web personnel) . Évalué à -4.
"La première sécurité est la liberté"
[^] # Re: Effectivement on est pas vendredi
Posté par pasBill pasGates . Évalué à 2.
Pourtant c'est Symphony, base sur OOo et OOo 3.1
[^] # Re: Effectivement on est pas vendredi
Posté par modr123 . Évalué à 2.
[^] # Re: Effectivement on est pas vendredi
Posté par Misc (site web personnel) . Évalué à 3.
[^] # Re: Effectivement on est pas vendredi
Posté par zebra3 . Évalué à 2.
Non, au-delà de la comparaison, c'est le comportement de MS que je trouve dommage, parce que justement il y avait ici l'occasion de faire mieux qu'IBM et OOo lui-même sur ce point. Cela aurait été je pense un joli coup de pied aux idées reçues et aurait redoré l'image de MS aux yeux de la communtauté, preuve que cela commence à changer en son sein, ce qui n'est finalement pas le cas.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Effectivement on est pas vendredi
Posté par pasBill pasGates . Évalué à 3.
Etre compatible avec OOo 2.x et Symphony ou etre compatible avec OOo 3.x ?
Super comme choix... Resultat, MS a decide de pas jouer ce genre de jeu, et l'a dit bien clairement, de cette maniere aucun risque que l'utilisateur soit trompe par ce qu'il voit.
[^] # Re: Effectivement on est pas vendredi
Posté par Anthony Jaguenaud . Évalué à 4.
Après, pour le fond du sujet, j'aurais tendance à dire que la première implémentation, si elle est pas débile, devrait faire foi.
[^] # Re: Effectivement on est pas vendredi
Posté par jeffcom . Évalué à -1.
Et puis, entre nous, si on commence à écouter l'utilisateur final, on va finir par sortir un clone de Mac... ça le ferait pas... quoi que, Mac se fait bien du fric sur le dos du libre non ?
MS aimerait bien avoir l'image du libre, mais sans avoir à en prendre les saines habitudes. Sans dec, chez MS on fait du privateur et on le fait bien, et ça va pas changer de si tôt.
PS : on est pas vendredi, je sais, mais c'est pas moi qui ait commencé, et puis vendredi j'ai pas pu troller.
[^] # Re: Effectivement on est pas vendredi
Posté par fcartegnie . Évalué à 5.
S'il se souciaient d'autres choses que de leurs propres intêrets, le processus de standardisation aurait été réglo, et dans ce cas les problèmes auraient émergé par eux même.En 10 ans on a le temps d'aborder plus de sujets qu'en 6 mois.
Faut pas venir nous dire que ce n'est pas défini, alors que c'est eux même qui en biaisant le processus de normalisation on mené à cette situation.
[^] # Re: Effectivement on est pas vendredi
Posté par pasBill pasGates . Évalué à 2.
[^] # Re: Effectivement on est pas vendredi
Posté par pasBill pasGates . Évalué à 2.
Tu sais si Symphony va gagner un marche avec, je sais pas, le gouvernement du Japon, et prendre 150'000 postes ? Si oui, ben pas de bol pour l'interaction avec eux...
La meilleure solution est de rester neutre.
[^] # Re: Effectivement on est pas vendredi
Posté par Anthony Jaguenaud . Évalué à 2.
Dans ce cas, pourquoi avoir proposé une solution si elle n'est pas acceptable ?
Blague à part, j'aurais écris : "parfaite" ou "idéale".
Je comprends le sens de ton propos, ne pas privilégier une solution plutôt qu'une autre. Néanmoins, il eu quand même été intéressant d'avoir une consultation, juste au cas où une vrai majorité genre + de 70% préfère une solution elle aurait été implémentable. Voir même, proposer les deux en proposant une solution ou l'autre. Comme ça, vous mettiez le nez des utilisateurs devant des problèmes de leur format fétiche ;-)
[^] # Re: Effectivement on est pas vendredi
Posté par modr123 . Évalué à -2.
bon puisque que tu es specialiste de ce genre de programme
j'ai deux colonnes A et B et je voudrais que dans chaque cellule de C on ait C$i=A$i+B$i par exemple sans remplir tout a la main avec i variant de 1 a je sais pas quoi
[^] # Re: Effectivement on est pas vendredi
Posté par Éric (site web personnel) . Évalué à 10.
Si la "specification" ODF revient à dire "faites comme OOo" franchement elle ne vaut pas mieux à mes yeux que OOxml. Non, franchement, on peut reprocher à MS de ne pas avoir tenté une meilleure compatibilité avec OOo mais certainement pas dire que implémenter ODF c'est faire comme OOo. Ce serait le contraire de ce qu'est une spécification ça.
[^] # Re: Effectivement on est pas vendredi
Posté par zebra3 . Évalué à -2.
Et tout cela, je le voyais comme un moyen pour MS de montrer qu'on pouvait avoir confiance en lui, car ce n'est pas qu'un problème technique. Et c'est raté.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Effectivement on est pas vendredi
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
On peut ajouter aussi que le code de OOo est libre et donc que le comportement est plus simple à définir. Cela serait un comportement sain en attendant la standardisation n°2.
Les besoins c'est sans doute une fusion entre docx et ODF. Si on vire dans docx tout le "legacy" qui n'a rien à faire dans une norme et toutes les microsofteries (format de date non iso, nom de propriété différente pour le tableur, la présentation et le traitement de texte), etc... Cela pourrait faire un format opérable. Il faudrait aussi qu'ils maigrissent.
"La première sécurité est la liberté"
[^] # Re: Effectivement on est pas vendredi
Posté par dinomasque . Évalué à 10.
Paradoxalement pour tout le tintouin qui résulte de cette affaire, je crois qu'il faut remercier Microsoft d'avoir mis le doigt là ou ça fait mal. La publicité sur une faiblesse de la norme permettra probablement d'accroître les échanges à son propos lors des travaux de révision de la norme ODF.
BeOS le faisait il y a 20 ans !
[^] # Re: Effectivement on est pas vendredi
Posté par Philippe F (site web personnel) . Évalué à 4.
Il reste un gros travail de définition de suite de test pour valider l'interopérabilité des formats et leur utilisation correcte dans du code.
Pour participer à certains comités ISO ou à regarder d'autres efforts d'unification (xdg, browser et html, ...), la situation est pourtant assez courante et semble être un chemin naturel quoique désagréable de tout effort de coopération et de standardisation.
Ca commence toujours par merder avant de converger. C'est bien pour ça qu'on parle d'effort de standardisation parce que ce n'est pas du tout du tout naturel.
Cela dit, il semble que ODF aie suffisamment de monde derrière pour devenir un vrai standard, contrairement à OOXml qui n'a que Microsoft (ce que fait beaucoup de monde certe) et ne peut prétendre à ce type d'interopérabilité.
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 7.
Et en terme d'interopérabilité, c'est mieux qu'un format qui contient des balises binaires qui ne ne sont pas documentées voire fermées, non ?
[^] # Re: Effectivement on est pas vendredi
Posté par pasBill pasGates . Évalué à -2.
a) Les formules sont clairement definies
b) L'encryption est clairement definie
c) Il n'y a pas de balises binaires non definies
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 6.
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 2.
http://www.microsoft.com/downloads/details.aspx?FamilyId=AD0(...)
Voilà j'ai gagné quoi ?
De toute façon, Open XML se veut pas "le" format d'interopérabilité, il se veut le format XML ouvert et documenté de la suite de Microsoft. Moins ambitieux (prétentieux) qu'ODF, rempli pleinement son objectif.
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 1.
Un peu comme si on écoutait Vivaldi en mp3 en lisant le binaire sous Emacs.
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 1.
Même si un SDK est abscons pour les utilisateurs finaux, c'est une brique essentielle pour tous les développeurs.
De plus, contrairement à un autre format dont on ne citera pas le nom, qui ne valide même pas lui-même par rapport à son format de représentation, ce SDK permet de valider correctement un document OpenXML.
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 2.
De plus, contrairement à un autre format dont on ne citera pas le nom, qui ne valide même pas lui-même par rapport à son format de représentation,
Ca veut dire quoi en francais dans le texte ?
[^] # Re: Effectivement on est pas vendredi
Posté par Littleboy . Évalué à 2.
Ca fait reference a ca je suppose: http://www.griffinbrown.co.uk/blog/PermaLink.aspx?guid=f0384(...)
Ca fait pas tres net, mais compare a tous les autres problemes et manques dans ODF, ca merite pas d'y passer trop de temps.
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 1.
Ce que ca montre également, c'est qu'aucun des couillons qui a pondu le standard n'a pensé avant à valider un document contre le schéma officiel, qui est pourtant censé être la représentation la plus formelle...
Mon petit doigt me dit que globalement tous les implémenteurs s'imposent d'être compatible avec le standard ODF "de fait", à savoir OOo, l'objectif avoué étant de se serrer les coudes derrière ce leader pour lutter contre Microsoft.
Ils feraient mieux de prendre leur temps pour réaliser un vrai format, complet, et qui tient compte des besoins des utilisateurs, à savoir impérativement inclure MS dans la boucle pour que la compatibilité avec MS Office soit assurée.
Ah mais oui mais non, la stratégie, c'est pas l'utilisateur, la stratégie c'est les parts de marché d'IBM & Sun dans les administrations... il fallait vite un brouillon, pardon un standard qui soit ISO, quitte à virer le principal.
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 2.
Il fallait vite un brouillon, pardon un standard qui soit ISO, quitte à virer le principal.
Rappelles-moi quel format s'est fait recaler et quel format a fait le forcing pour le "fast track".
Rappelles-moi quel format a entamé la démarche de standardisation en premier.
Faudrait pas refaire l'histoire non plus.
Merci de rester factuel, c'est nettement plus intéressant.
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 2.
Bravo tu as montré que l'ISO est capable de standardiser n'importe quoi, que OOXML et ODF sont pas mieux dans la guegerre visant à décrocher le label tant convoité avant le concurrent.
C'est pas pour autant que ODF a pour principal accroche marketing l'interopérabilité, et bien obligé de constaté que dans ce sens sa standardisation est un non-sens total.
Que ce soit la même chose/pire/mieux pour OOXML ne change rien à ce fait, ca c'est factuel.
[^] # Re: Effectivement on est pas vendredi
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
OOxml voulait utiliser autres choses que les normes ISO pour les dates, les nombres, il voulait aussi garder le legacy word97 ! C'est n'importe quoi pour une norme.
Ensuite, une norme peut être incomplète comme toute spec. D'où le processus de révision.
"La première sécurité est la liberté"
[^] # Re: Effectivement on est pas vendredi
Posté par Metzgermeister . Évalué à 1.
[^] # Re: Effectivement on est pas vendredi
Posté par fcartegnie . Évalué à 0.
Tout comme explorer permet de valider les documents xhtml ? .....
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 2.
De toute façon, Open XML se veut pas "le" format d'interopérabilité, il se veut le format XML ouvert et documenté de la suite de Microsoft. Moins ambitieux (prétentieux) qu'ODF, rempli pleinement son objectif.
Page officielle
http://www.microsoft.com/france/office/livreblanc.mspx
Avantages clés
•Format ouvert, interopérable et en cours de standardisation. Les utilisateurs ont accès à leurs documents pendant des décennies. Les documents pourront être traités facilement avec tout type de système
Pour ce qui est de la "prétention", c'est clair et je crois me rappeler que la spec ODF était nettement plus concise qu'OOXML.
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 1.
ODF frees documents from their applications-of-origin, enabling them to be exchanged, retrieved, and edited with any OpenDocument-compliant software or tool.
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 2.
Faut arrêter de tourner autour du pot.
OOXML revendique autant l'interopérabilité qu'ODF et se veut son concurrent, point.
Ta notion d'interopérabilité est curieusement à géométrie variable:
http://linuxfr.org/comments/1031329,1.html
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 2.
Je suis d'accord, c'est un terme utilisé à mauvais escient par les marketeux de Microsoft.
Mais c'est risible que tu prennes leur discours au pied de la lettre.
OOXML revendique autant l'interopérabilité qu'ODF et se veut son concurrent, point
Ben je viens de montrer le contraire : Microsoft ne parle que d'échanger des docs entre produits MS Office, ODF parle d'être indépendant de tout vendeur alors que la réalité est tout autre.
Ta notion d'interopérabilité est curieusement à géométrie variable
? Comprend pas.
Pour moi OOXML et ODF ne sont pas des formats d'interopérabilité magique comme on aimerait en avoir un : un format qui puisse être ouvert dans MS Office, Symphony ou OOo sans problème.
Pour moi un tel format ne peut pas exister en pratique même s'il est séduisant sur le papier.
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 2.
Pour moi un tel format ne peut pas exister en pratique même s'il est séduisant sur le papier.
Tu peux developper ?
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 2.
Grosso modo les formats des suites offices sont pas vraiment de simple documents avec du contenu basic.
Ce sont des formats servant de support pour beaucoup de fonctions. Bref il y a une forme de bijection entre les fonctionnalités de ces suites et les formats sous-jacents.
Il est pour moi illusoire de croire qu'un format va sortir du lot qui rende tout le monde heureux : soit ce format est un dénominateur commun mais est alors réducteur, soit il privilégie un vendeur particulier.
Etant donné que les suites Offices se différencient de part leurs fonctionnalités et que les liens sont étroits avec le contenu, tout le monde veut que "son" format soit "le" standard, car il est évident que celui-ci aura un avantage décisif par rapport au concurrent. C'est pas pour rien qu'OOXML est basé sur MS Office et qu'ODF est basé sur OOo.
L'objectif est de séduire les administrations avec des arguments marketing "interop", blabla", "iso", "ouvert". Faut être naïf pour croire qu'on pourra en tant qu'utilisateur échanger des docs Office sans soucis.
Sun et IBM jouent la carte de l'interopérabilité pour séduire les administrations, MS réplique, tant mieux pour la pérénité des documents qui est améliorée (et pleins d'autres avantages), mais l'interopérabilité, c'est pas pour demain. Aucun des acteurs n'y a d'intérêt.
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 2.
Mais bon, si t'a un lien sur un des journaux où t'as développé je m'en contenterai.
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 2.
Si les 2 avaient exactement les mêmes fonctionnalités, bonjour l'intérêt concurrentiel.
Les concepteurs d'ODF sont tout à fait conscient de ce problème, et pour garder l'interopérabilité de façade, ils se cachent derrière 2 astuces (à la con) :
- "ouverture" au sens ou on laisse libre court à l'imagination de l'implémenteur (hem) pour mettre tout et n'importe quoi à tel ou tel endroit (formule, image, etc.)
- "non-obligatoire" : t'es pas obligé d'implémenter toute la norme pour prétendre être "compliant" avec le standard. L'utilisateur ne peut pas ouvrir son doc ou perd les 3/4 du contenu, mais c'est pas grave, le format est toujours interopérable, génial non ?
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 3.
C'est comme tout bon vieux xml , les balises que tu comprends pas tu les bypassent.
Là ce que tu remets en question, c'est l'intérêt des standards en général (denominateur commun) et des formats d'échange en particulier au prétexte qu'on ne peut viser la perfection.
Le gain, il est dans les 98 % que tu récupères sans effort.
[^] # Re: Effectivement on est pas vendredi
Posté par thedude . Évalué à 2.
Certes, mais que fais tu a la reecriture de ces dites balises que tu ne comprends pas?
C'est bien joli des les ignorer a la lecture, mais va falloir les garder dans un coin du document compile (raisonnablement faisable je pense, quoique pas forcement si trivial que ca), mais tu peux casser l'intergite du document en updatant une partie du document mais pas le reste.
Exemple de base:
J'ai un tag non compris qui reference une certaine cellule.
J'ignore ce tag, jusque la tout va bien.
L'utilisateur supprime la cellule referencee.
T'as une formule qui reference une cellule qui n'existe plus.
Bon, l'exemple est tres simpliste, mais dans une spreadsheet un tant soit peu complexe, tu peux imaginer les cas tordus que ca peut engendrer.
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 1.
Certes, mais que fais tu a la reecriture de ces dites balises que tu ne comprends pas?
Boaf, le but du jeu ce n'est pas de changer d'outil toutes les demi heure , c'est de s'assurer qu'on peut rester indépendant du fournisseur.
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 3.
Ce qui m'intéresse c'est de dire bye bye le jour où la dîme devient exorbitante.
[^] # Re: Effectivement on est pas vendredi
Posté par thedude . Évalué à 1.
l'interoperabilite d'odf, en fait, ca marche que quand tu restes sous la meme suite?
Merci de m'avoir fait rire.
Aller, un petit exemple ballot et pas courant du tout, une spreadsheet qui fait l'aller retour entre 2 boites partenaires pour edition, une utilise OOo et l'autre MSO. Ou Symphony, pour rester chez ODF.
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 3.
http://msdn.microsoft.com/en-us/library/dd440953.aspx
The Open XML Format SDK 1.0 addresses the structure of Open XML Formats, while the Open XML Format SDK 2.0 addresses the XML contained within each of the document parts. Open XML Format SDK 1.0 was published in June 2008 with a license that includes the right to use and distribute. With this license, you can build and deploy production solutions by using the Open XML Format SDK. Open XML Format SDK 2.0 (CTP) was published in September of 2008. This version of the Open XML Format SDK is pre-release software, so the APIs are currently under development. The license includes the right to use but not to distribute. For this reason, you should not use information in this SDK in deployed or production solutions.
Dommage, à un moment j'ai vraiment cru que M$ faisait un effort d'ouverture.
Je n'imaginais même pas accéder aux sources.
Remarque, ca fera toujours un peu de taf pour Miguel De Icaza de réécrire tout ca.
Bon, en attendant on va continuer avec les implémentations ODF aussi foireuses soient t'elles mais qui ont le mérite d'être ouvertes et donc réutilisables, modifiables, ....
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 1.
"implémentations ODF aussi foireuses soient t'elles mais qui ont le mérite d'être ouvertes et donc réutilisables, modifiables"
Modifiable ? Sun et IBM risquerait de te tomber dessus assez méchament...
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 2.
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 1.
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 2.
[^] # Re: Effectivement on est pas vendredi
Posté par Buf (Mastodon) . Évalué à 1.
C'est une version de développement, donc à destination des développeurs uniquement. MS ne veut pas que cette version non-finale soit utilisée pour autre chose, ils interdisent donc sa redistribution. Ça ne veut pas dire que ça sera pareil pour la version finale (ça serait vraiment stupide qu'elle ne soit pas redistribuable)
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 2.
Ca limite fortement l'adoption.
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 2.
http://social.msdn.microsoft.com/Forums/fr-FR/oxmlsdk/thread(...)
Mais j'ai encore pas pu mettre la main sur la license.
[^] # Re: Effectivement on est pas vendredi
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 2.
http://blogs.technet.com/office2010/default.aspx
[^] # Re: Effectivement on est pas vendredi
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 2.
Tu conviens donc qu'il y avait une implémentation.
Le "correcte" me parait plutôt relever de l'interprétation subjective.
En tout cas, en ce qui concerne OOXML, difficile de préjuger de la qualité d'un format qui n'est pas implémenté. Et je ne parle pas de l'interopérabilité qui implique qu'on dispose d'au moins 2 implémentations pour en mesurer la qualité.
[^] # Re: Effectivement on est pas vendredi
Posté par pasBill pasGates . Évalué à 2.
Il est tres clair qu'en 2006 OOo etait tres loin d'etre une implementation de reference ODF, il lui manquait des pans entiers.
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 1.
Dans mes souvenirs EMF/WMF faisait partie intégrante de la norme
Ca a changé depuis ? parce que question ouverture, la transcription d'appel à l'API Windows, j'ai connu mieux.
Un petit lien pour se rafraichir la mémoire
http://linuxfr.org/comments/862639.html#862639
Mais rassures moi, ce n'est pas le format par défaut pour les images vectorielles de la beta... pardon la ctp d'Office 2010
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 1.
Bref avec ODF, on peut y placer un format d'image libre visant une vraie interopérabilité et on ne se coupe pas des évolutions technologiques ou des clients qui ne visent pas l'interopérabilité ou qui ont des besoins spécifiques.
Que du bon
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 2.
Faudrait peut être regarder la poutre qu'on a dans l'oeil de temps en temps.
De toute façon, implémenter WMF n'est pas un risque de ce point de vue, MS s'est engagé à ne pas faire chier quelqu'un qui l'implémenterait (ce qui est totalement différent de FAT, désolé) :
http://www.microsoft.com/Interop/osp/default.mspx
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 2.
Concernant ODF, il faudrait me montrer que Java et MPEG4 étaient imposés.
Relis mon post plus haut. L'ouverture, à mon sens, c'est de pouvoir référencer du contenu libre ou fermé mais de n'imposer aucune restriction en imposant un contenu fermé sans alternative libre.
Donc j'attends,c'est quoi l'alternative à WMF en vectoriel pour OOXML: SVG ?
Ce n'est pas une question piège!
[^] # Re: Effectivement on est pas vendredi
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 2.
Pondre du WMF n'est pas risqué, interpréter du WMF implique d'implémenter GDI.
Puis-je reimplémenter l'API GDI sans souci ?
Par ailleurs puis-je faire évoluer WMF pour mes propres besoin pour concurrencer le format initial.
Puis-je disposer d'autre format d'image vectoriel en restant compatible OOXML ?
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 2.
Microsoft s'engage à ne pas t'enmerder pour une implémentation de WMF quelque soit ce que t'utilises dessous pour le faire.
Puis-je reimplémenter l'API GDI sans souci ?
On s'en tape que y'es une autre API à implémenter ou non, si c'est pour implémenter WMF, t'as pas de risque (de la part de Microsoft en tout cas)
Par ailleurs puis-je faire évoluer WMF pour mes propres besoin pour concurrencer le format initial.
Ben ca sera plus WMF, et Microsoft ne s'engage alors en rien. Mais ce qui compte, c'est que tes documents OOXML soient pérennes dans le temps.
Et puis bon si tu veux aller par là, si tu fais évoluer le format ODF, tu vas avoir des problèmes du même type avec Sun et IBM qui ont clairement dit pour le premier que son "autorisation" valait tant qu'ils étaient dans le process, et pour le second son autorisation est conditionné par la strict compatibilité avec le standard ODF (d'ailleur qui l'est ?)
Moi j'ai une autre question :
pourquoi ODF ne définit pas le format SVG comme format vectoriel de référence ? Pourquoi OOo n'implémente par par défaut le format SVG ? ("bug" que j'ai trouvé après avoir été content d'exporter un diagramme visio en svg en me disant youpi je vais le mettre dans ma présentation OOo)
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 2.
pourquoi ODF ne définit pas le format SVG comme format vectoriel de référence ? Pourquoi OOo n'implémente par par défaut le format SVG ? ("bug" que j'ai trouvé après avoir été content d'exporter un diagramme visio en svg en me disant youpi je vais le mettre dans ma présentation OOo)
Arrêter de jouer les Rabbi Jacob :) en répndnt à une question par une autre question.
Le SVG n'est peut-être pas assez abouti et aucune autre alternative standard viable n'existe, que sias-je ?
Mais si vous pouviez répondre à ma question plus haut:
Donc j'attends,c'est quoi l'alternative à WMF en vectoriel pour OOXML: SVG ?
pBpG m'a expliqué que le WMF est "obsolète", donc quelle est le nouveau format et est-ce qu'il y a les mêmes dispositions juridiques le concernant.
Est-il prévu de le standardiser ?
Merci à vous :)
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 2.
J'ai quand même joué le jeu en répondant à la plupart de tes questions avant :) et quand on "oublie" une question, c'est peut être tout bêtement qu'on a pas la réponse :)
Le SVG n'est peut-être pas assez abouti et aucune autre alternative standard viable n'existe, que sias-je ?
Et t'enmerde MS qui utilise WMF sachant que y'a pas d'alternative viable ???
Sinon niveau alternative à WMF, y'a EMF, m'enfin c'est juste une évolution du premier, est-ce que c'est également obsolète je sais pas...
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 2.
Et t'enmerde MS qui utilise WMF sachant que y'a pas d'alternative viable ???
J'emmerde pas, je me renseigne, mais vu comme vous éludez la question je me doute.
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 2.
C'est vrai que c'est plus anodin que ne pas s'être accordé sur la façon de convertir correctement une chaine en entier dans une formule de tableur.
[^] # Re: Effectivement on est pas vendredi
Posté par pasBill pasGates . Évalué à 1.
Quand a l'evolution de WMF, ditto ce que TImaniac a dit, tu t''enleves la couverture de brevets si tu fais ca, de meme que tu t'enleverais la couverture de brevets si tu faisais la meme chose avec ODF.
Puis-je disposer d'autre format d'image vectoriel en restant compatible OOXML ?
Il y a DrawingML
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 2.
http://en.wikipedia.org/wiki/Office_Open_XML#DrawingML
http://openxmldeveloper.org/articles/2683.aspx
J'en déduis que ce format est ouvert.
[^] # Re: Effectivement on est pas vendredi
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Le principe d'un bureau de création de norme, c'est l'unification. Pas de créer des bidules à chaque création de bidule plus gros !
"La première sécurité est la liberté"
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 2.
Non non, rien est imposé, comme tout le reste de la spec, tu peux te contenter d'implémenter les sections de base, faire un notepad et t'es "compliant". N'empêche que ton application peut pas lire la majorité des documents. C'est pas ca que veut l'utilisateur.
L'ouverture, à mon sens, c'est de pouvoir référencer du contenu libre ou fermé mais de n'imposer aucune restriction
Ca c'est la définition d'un format visant l'ouverture effectivement.
Mais c'est pas un format qui vise l'interopérabilité.
Un format qui vise l'interopérabilité, il doit être fermé, au sens exhaustivité.
L'ouverture n'est pas forcement un avantage pour les utilisateurs, et cela cache bien souvent un manquement dans la spec.
Imagine un format d'image qui laisse libre court à l'implémenteur de coder les couleurs... c'est ouvert non ? niveau interopérabilité, c'est à chier, le perdant c'est l'utilisateur.
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 2.
C'est formidable parce que OOXML a réussi le tour de force d'être à la fois les 2.
http://linuxfr.org/comments/1031323.html#1031323
Désolé mais tu peux très bien faire une recommandation sur un contenu standard en exhaustivité et autoriser les extensions.
Je pense que c'est ce que vise ODF et donc ta référence à Java et MPEG4 est malvenue.
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 4.
Ouvert peut vouloir dire :
- pleinement documenté
- librement utilisable
- non exhaustif, "ouvert" à toutes les extensions, mêmes proprio
OOXML et ODF sont les 3 à la fois, et les 2 premiers sont les seuls formes d'ouvertures qui soient vraiment utile pour l'utilisateur, les seules formes qui aillent dans le sens de l'interopérabilité.
Désolé mais tu peux très bien faire une recommandation sur un contenu standard en exhaustivité et autoriser les extensions.
Encore une fois, je suis d'accord, mais dans ce cas il ne faut pas prétendre que ce format vise également l'interopérabilité.
Le trou béant dans la spec ODF concernant les formules en est un magnifique exemple. Idem pour HTML5 et la balise video.
Je pense que c'est ce que vise ODF et donc ta référence à Java et MPEG4 est malvenue.
J'ai pas retrouvé concernant MPEG4, par contre concernant les applets Java c'est bien dans la spec ODF 1.1. D'ailleur c'est rigolo, les pro-ODF critique l'OOXML pour ne pas tenir compte des standards ISO existants (date, svg, toussa), pourtant y'a une spec ISO qui définie une machine virtuelle pour du code embarqué... bizzare c'est pas java mais un machin made-in-MS...
Tiens sinon on peut inclure des scripts dans n'importe quel langage dans l'ODF, la doc donne par exemple "javascript", mais on peut imaginer python ou je ne sais pas quoi... encore une jolie "ouverture" qui va garantir l'interopérabilité...
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 2.
Encore une fois, je suis d'accord, mais dans ce cas il ne faut pas prétendre que ce format vise également l'interopérabilité.
Je t'ai montré plus loin que c'est la même chose avec OOXML. Mais pour M$ c'est uniquement une plaquette commerciale. Mais ODF ne devrait pas être vendeur.
Tiens sinon on peut inclure des scripts dans n'importe quel langage dans l'ODF, la doc donne par exemple "javascript", mais on peut imaginer python ou je ne sais pas quoi... encore une jolie "ouverture" qui va garantir l'interopérabilité...
Ça peut pas être pire que les macros en VB, hein. Ca doit être intéressant d'ouvrir un vieux .doc écrit sous W98 avec des macros pour voir comme il récupère ca dans Office 2010. Je sens qu'on va s'amuser question interop aussi. Mais bon ils assurent la compat ascendante parfaite, puisque c''est leur unique ambition.
Sinon ECMAScript est normalisé lui .
Et Java est complètement ouvert aujourd'hui.
Enfin, je ne suis pas pro-ODF, juste curieux.
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 2.
MS parle d'interopérabilité entre suites Microsoft.
ODF parle d'interopérabilité indépendante des vendeurs.
C'est beaucoup plus prétentieux et totalement trompeur, suffit de voir le débat autour des formules où tout le monde devrait suivre le "vendeur" de référence, Sun.
MS a une ligne beaucoup plus "clair", OOXML est une traduction XML fidèle de son format office binaire, ils ne s'en cache pas, parcque de toute façon c'est l'objectif.
C'est d'ailleur ce qui m'a toujours fait dire que OOXML et ODF n'était pas réellement concurrents en ce sens qu'ils n'avaient pas les même objectifs.
Ça peut pas être pire que les macros en VB, hein.
Bah si, ca pourrait être du VB modifié vu qu'on peut y mettre ce qu'on veut :)
Un espèce de VB brainfucké t'imagine :)
Ca doit être intéressant d'ouvrir un vieux .doc écrit sous W98 avec des macros pour voir comme il récupère ca dans Office 2010.
Désolé, je peux pas tester :-p
Sinon ECMAScript est normalisé lui .
C'est bien là le hic, c'est qu'en plus il existe un foutu standard, et qu'ils préfèrent laisser la porte ouverte à tout et surtout n'importe quoi. C'est affligeant tellement c'est indispensable pour l'interopérabilité.
Et Java est complètement ouvert aujourd'hui.
Son développement est ouvert mais il est toujours pas standardisé. Y'a pourtant un standard qui existe, C#, avec sa machine virtuelle.
[^] # Re: Effectivement on est pas vendredi
Posté par Maclag . Évalué à 3.
On fait un grand foin en mettant le mot magique partout, et une fois qu'on s'est cassé les dents, on fait mine que non, pas du tout, c'est un malentendu, on n'a jamais dit ça.
Depuis le début, MS vend son OOXML en parlant d'intéropérabilité, et pas seulement entre produits MS!
Reprendre les arguments pour en changer l'interprétation maintenant, c'est d'une mauvaise foi qui devrait te faire rougir de honte!
Tu peux critiquer autant que tu veux le format ODF, les critiques sont à mes yeux pertinentes (c'est pas de la faute de MS si une partie des specs a été écrite à l'arrache).
Par contre, évite ce genre d'ânerie, ça décrédibilise tout le reste!
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 1.
Ou alors trouvez-moi un lien où Microsoft vente les mérites d'avoir un format interopérable indépendant de tout vendeur comme le fait ODF.
[^] # Re: Effectivement on est pas vendredi
Posté par Bozo_le_clown . Évalué à 2.
Non ! OOXML ne vise pas l'interopérabilité juste celle des versions de l'editeur.
et plus loin
mieux dans la guegerre visant à décrocher le label tant convoité avant le concurrent
Que l'on discute des mérites de chaque format ok, mais avoir le toupet de prétendre que ce n'est pas pour concurrencer un autre format d'interop.
Du coût, tu réinventes même le mot intéropérabilité. Chez moi ca s'appelle la compatibilité ascendante avec un format ouvert.
Mais tu as raison, comme en fait M$ ne vise pas l'interop mais juste le monopole et fait toujours comme si ils étaient le standard de fait, c'est plus facile, quand on est tout seul, d'être interopérable avec soi-même.
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 1.
"OpenXML was designed from the start to be capable of faithfully representing the pre-existing corpus of word-processing documents, presentations, and spreadsheets that are encoded in binary formats defined by Microsoft Corporation. The standardization process consisted of mirroring in XML the capabilities required to represent the existing corpus, extending them, providing detailed documentation, and enabling interoperability."
http://www.ecma-international.org/news/TC45_current_work/Ope(...)
[^] # Re: Effectivement on est pas vendredi
Posté par pasBill pasGates . Évalué à 1.
Et cela n'a rien a voir avec la transcription d'appels a Windows, tu remarqueras que nombre de softs sous Linux lisent WMF sans probleme.
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Effectivement on est pas vendredi
Posté par fcartegnie . Évalué à 2.
Dans le cas contraire, faire juste un document avec une extension MSWord et inclure le contenu du document dedans reste un "Open Document" valide. :/
[^] # Re: Effectivement on est pas vendredi
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 3.
Belle affirmation, quelqu'un monte en epingle un soucis d'interprétation/conversion automatique
de chaine vers entier, le détourne sur un problème de relecture de formule et utilise cet argument
pour justifier une suppression complète des formules issues des autres suites sur la sienne.....
Bel exemple de sarkozysme !
Parce que sauf erreur OOo et Symphony bien qu'ils ne stockent pas la formule de la même façon
arrivent a se relirent. Le seul soucis étant sur l'interprétation d'une cellule identifiée en tant que texte.
Hors Office arrive la dessus et lui ... il supprime les formules, sans avertissement et sans appel,
plus rigolo encore si jamais il lui arrive d'en enregistrer une il n'utilise aucun des formalismes
utilisés par les autres ...
[^] # Re: Effectivement on est pas vendredi
Posté par TImaniac (site web personnel) . Évalué à 1.
arrivent a se relirent.
Ben justement non...
Le seul soucis étant sur l'interprétation d'une cellule identifiée en tant que texte.
Ouf j'ai cru qu'il allait prouver son affirmation gratuite. Finalement OOo et Symphony sont bien incompatibles.
Hors Office arrive la dessus et lui ... il supprime les formules
Bah oué, c'est autrement plus malin : je garde le résultat (correct) et je vire la formule.
Franchement, en tant qu'utilisateur, je préfère que mon patron/client/collègue voit le bon résultat plutôt que d'être insidieusement trompé par un résultat erroné comme l'affiche OOo.
Et puis que fais OOo en voyant les formules générées par Microsoft ? Il les garde ? les interprête ? les vire ? Elles sont pas plus bonnes ou mauvaises pourtant... 2 poids, 2 mesures...
"il n'utilise aucun des formalismes utilisés par les autres ... "
Ben au moins, ils trompent par leurs utilisateurs, et la compatibilité est assurée avec 90% des documents produits par 90% des utilisateurs de suites office...
Ca me fait rire cette comparaison MS Office vs lerestedumondequiestunidansladversité.
Comme si les suites KOffice et autres Symphony était une priorité pour les utilisateurs niveau compatibilité... Ce que veulent les utilisateurs, c'est l'interopérabilité avec MS Office, que MS Office débarque après coup avec une version différente de OOo/Symphony n'y change rien : l'utilisateur il s'en branle du "c'est nous les premiers tu dois faire comme nous !"
[^] # Re: Effectivement on est pas vendredi
Posté par thedude . Évalué à 1.
le formule etant dumpees, modifier une cellule et recalculer la feuille donnera un resultat tout aussi faux, vu que les formules ne sont plus la.
Mais effectivement, ca me parait mieux d'afficher le resultat courant plutot qu'un obscur namespace xml suivi de la formule dans un format tout aussi obscur.
Toutes les suites donneront un result faux parce que le format est pourri.
Ya pas de bonne reponses: on a deux choix tout aussi mauvais l'un que l'autre, garder la formule en texte ou la dumper et afficher le resultat stocke.
Si la formule est la, c'est pour une bonne raison, c'est parce qu'on veut pouvoir modifier une cellule et affecter les autres.
Si le resultat est la, c'est pour une bonne raison, c'est parce qu'on ne veut pas se fader le calcul a la main.
Bref, les deux sont necessaires, et dans le cas d'odf on ne peut en avoir qu'un.
A moins d'integrer tous les moteurs de formules de toutes les suites dans un meme produit, ce qui defie un peu le concept d'interoperabilite.
C'est surtout ca qu'il faut retenir.
Un standard bacle ne peut assurer une quelconque interop, c'est ce que rob weir a montre au monde entier en voulant tirer a boulets rouges sur MS.
[^] # Re: Effectivement on est pas vendredi
Posté par pasBill pasGates . Évalué à 1.
Serieusement, faudra trouver mieux pour incendier MS et Office, eux au moins ne t'affiche pas un faux resultat, ils te disent clairement qu'ils ne savent pas comment l'interpreter.
Le fait qu'il manque des pans entiers a ODF pour etre un format interopable est un fait, personne ici ne peut nier qu'il est impensable d'avoir un standard pour suites office qui ne gere pas les formules, et partant de la ne permet pas l'interop entre tableurs.
Tout comme il est plus qu'evident que la partie encryption d'ODF a ete plus que mal definie et ne repond pas aux besoins de la moitie des gouvernements de la planete.
[^] # Re: Effectivement on est pas vendredi
Posté par Jerome Herman . Évalué à 9.
Je ne suis pas tout à fait sur qu'ils cherchent à démontrer quoi que ce soit, je pense que le but du jeu est plutôt de crier le plus fort possible que X ou Y a tort.
Dans le long troll précédent je placerais plutôt mon soutien du coté de chez Microsoft.
La façon dont je comprend les choses est qu'il y avait trois possibilités :
a) Forcer au maximum l'interroperabilité avec OOo.
b) Détruire toutes les fonctions non convertibles lors d'un enregistrement d'un format Excel vers un format ODF
c) Créer un moteur de calcul "d'import" et un moteur de calcul "d'export" distincts en plus du moteur existant.
En a) on s'attend à ce que le tableur se comporte de la façon la plus proche possible d'OOo. Or OOo et Excel ont des comportements différents sur un certain nombre de points. Notamment sur les recherches d'objectifs, les conversions dynamiques, les arrondis etc. Or il faut bien que l'on puisse importer un ODF, exporter vers ODF et modifier un fichier Excel/ODF avant de le sauvegarder en Excel/ODF... Donc :
- soit on met un boutton "comportement Excel/Comportement OOo" dans les icones, et on oublie l'idée même de faire des liens entre les feuilles Excel et des feuilles ODF.
- soit on fige le comportement dès le départ (ie à la création d'un fichier on vous demande quel comportement vous voulez et vous ne pouvez plus en changer, inutile de chercher à sauvegarder un fichier Excel au format ODF),
- soit on change complètement le fonctionnement natif d'Excel pour devenir celui de OOo en cassant au passage tout l'existant (c'est les clients qui vont être content)
En b) On laisse complètement tomber le support natif. A l'import on transforme la feuille ODF en une feuille Excel en modifiant formules et contenu des cellules (type, valeur) pour préserver le rendu final. A l'export on taille dans le lard. Tout ce qui dépasse est détruit, tout ce qui est ambigu génère un message d'alerte à la conversion et roule. Un gentil petit pop-up vient vous avertir que "attention la conversion risque de perdre des données" et c'est marre.
En c) C'est la fête au village Chaque feuille a un "comportement" rattaché. Un copier coller d'une feuille à l'autre nécessite un export/import, il y a plusieurs moteurs de calculs à maintenir en parallèle et les incohérences risquent d'être nombreuses. Ou alors on tente de n'avoir qu'un seul moteur de calcul mais qui interprête différamment suivant les cas en fonction de tel ou tel drapeau...
Dans tous les cas Microsoft va passer pour un méchant vilain pas beau qui soit n'es pas interropérable, soit pousse un standard castré pour dégouter les utiliseurs de l'utilisation d'ODF.
# Symphony ?
Posté par Axone . Évalué à 3.
[^] # Re: Symphony ?
Posté par pasBill pasGates . Évalué à 3.
[^] # Re: Symphony ?
Posté par khivapia . Évalué à 4.
[^] # Re: Symphony ?
Posté par Jean-Joseph THIBAULT (site web personnel) . Évalué à 2.
[^] # Re: Symphony ?
Posté par pix (site web personnel) . Évalué à -1.
# ce qui m'étonne le plus
Posté par nodens . Évalué à 2.
On voit bien le problème en tout cas (en fait personne n'a raison). Il est clair que l'absence de standard fait du mal. Ce qui est triste c'est que face à ces problèmes, il soit si compliqué et long de parvenir à une solution.
Une question qu'on pourrait se poser est : est-ce que si tous les softs en question étaient libres on serait dans une meilleure situation ?
(en ce qui me concerne je n'ai pas la réponse...)
[^] # Re: ce qui m'étonne le plus
Posté par syj . Évalué à 2.
Je suis sur qu'on peut trouver des tonnes et des tonnes de cas similaire entre deux implémentation MS Office ou d'Internet Explorer.
Et pourtant dans le cas de Microsoft, on a une même direction qui pourrait ou peut trancher sur le comportement à adopter entre deux version.
# La route est longue, mais la voie est libre!
Posté par jmelyn . Évalué à 2.
Dans notre cas, il s'agit d'interopérabilité entre plusieurs logiciels. L'on sent bien Microsoft contraint et forcé appliquer de façon bête et méchante ce qu'on lui impose. Je crois que l'interopérabilité commencera à fonctionner lorsque Microsoft l'aura décidé. Et ce changement ne peut survenir comme par magie, c'est tout une culture à faire évoluer.
Sincèrement, je n'ai jamais cru qu'Office marcherait sans accroc du premier coup; faut pas être naïf, on ne transforme pas un loup retord en chien coopératif et civilisé juste en sortant une nouvelle version de logiciel! Mais ce premier pas n'est pas anodin. Soyons patient, les personnes à l'intérieur de cette société finiront par accepter la coopération avec le monde extérieur, même pbpg! Bon, certains mettront plus de temps que les autres, surtout les anciens.
Pousser des cris d'orfraie me semble contre-productif et pousse (les gens de) Microsoft à se braquer. C'est un premier pas, inimaginable il y a encore quelques années, mais le chemin ne s'arrête pas là. Courage, et vive l'interopérabilité!
[^] # Re: La route est longue, mais la voie est libre!
Posté par pasBill pasGates . Évalué à 2.
Vu le temps qu'ils ont eu pour implementer ODF compare a MS, j'imagines que tu classes ca dans la categorie mauvaise volonte aussi ?
[^] # Re: La route est longue, mais la voie est libre!
Posté par jmelyn . Évalué à 0.
Je ne crois pas que tu puisses dire que vous (en tant que personnel de Microsoft) êtes heureux d'avoir le format ODF en plus des formats habituels. Et c'est votre droit le plus strict. Je comprends dès lors que la traduction en code du module ODF par Microsoft ne puisse être bien faite, c'est normal.
Si deux suites libres décident de se baser sur le même format de fichier, c'est un réel choix, pas une contrainte, donc il y a la volonté. Cela ne veut pas dire que ça marchera: Les codeurs sont-ils bons? Y en a-t-il assez? L'organisation est-elle efficiente? Personnellement je ne sais pas. Je peux te dire aussi que KOffice (de KDE) ne traduit pas parfaitement ODF, en tout cas pas de la même manière qu'OOo. Mais ce n'est pas non plus de la mauvaise volonté. Tu vois, je ne parle pas du format qui est ou n'est pas comme il faut, ça ne m'intéresse pas. Je me concentre sur les choix, les envies.
Que tu défendes la société pour laquelle tu travailles est habituel et la plupart de tes collègues doivent faire la même chose. Mais peux-tu admettre que le code aurait pu être meilleur s'il y avait eu la volonté de bien faire? Je ne te demande pas de renier Microsoft, juste de prendre du recul.
[^] # Re: La route est longue, mais la voie est libre!
Posté par pasBill pasGates . Évalué à 3.
A part des prejuges, tu as quoi pour affirmer que MS fait expres d'empecher l'interop ?
[^] # Re: La route est longue, mais la voie est libre!
Posté par totof2000 . Évalué à 8.
... un lourd passif ?
[^] # Re: La route est longue, mais la voie est libre!
Posté par fcartegnie . Évalué à 1.
Maaaaais non, tu vois bien qu'une norme d'inter-opérabilité, dérivée d'un format déjà implémenté ailleurs et utilisé dans le monde, çà passe inaperçu !
Les développeurs et les testeurs étaient juste pas au courant que des implémentations existaient, sinon ils se seraient assurés d'avoir un produit compatible avec les autres.
Tout comme ils sont pas au courant que leurs navigateurs et autre pourrissent le web depuis des années, ou même que le langage java avait déjà une machine virtuelle et un toolkit...
[^] # Re: La route est longue, mais la voie est libre!
Posté par smc . Évalué à 1.
En revanche, pour Microsoft, c'est l'inverse et on comprend l'intérêt qu'ils ont à maintenir le status quo et à garder la position dominante sur la bureautique avec Office; par ailleurs les actions passées de Microsoft parlent pour elles-mêmes et il est normal de faire attention au fameux embrace-extend-extinguish. Tu es comme d'habitude de mauvaise foi en accusant la "communauté" (au sens large) pour procès d'intention alors qu'elle a bien raison d'être doublement vigilants avec MS.
Les erreurs sont humaines, qu'elles viennent de MS ou d'IBM. Mais il y a deux facteurs différenciateurs:
- MS a une part de marché bien supérieure à IBM avec Office et il s'agit de sa responsabilité en tant que bon citoyen et utilisateur du format de ne pas vendre un produit comme étant compatible OpenDocument si des erreurs peuvent être trouvées en 5 minutes. Pourquoi ne pas communiquer avec la communauté OpenDoc et leur demander de tester avant de release ? Ils ne sont pas plus sympas avec IBM, juste moins vigilants (car une erreur dans Symphony touche moins de monde). Pense aux utilisateurs de Word qui vont utiliser OpenDoc en se disant "c'est mieux" et qui auront des problèmes dans 2 mises-à-jours quand MS corrigera le problème (à moins qu'ils décident de mettre en place une compatibilité ascendante avec leur bug, ce qui ne serait pas surprenant vu votre historique de pratiques d'ingénierie douteuses).
- La réaction de l'entreprise. Il ne s'agit pas de jouer au "blame game", il s'agit d'avoir des logiciels véritablement compatibles -- autant que faire se peut. J'aimerais bien voir quand et comment Microsoft va corriger le problème. Il est entièrement dans leur intérêt commercial (bien que malhonnête comme la majorité des stratégies de MS) de donner une mauvaise réputation au standard, de créer des incompatibilités, etc.
Au final, le véritable problème est le manque d'une test-suite pour OpenDocument. Mais maintenant que Microsoft est un membre impliqué de la communauté, je suppose qu'ils aideront à la concevoir, n'est-ce pas? :).
[^] # Re: La route est longue, mais la voie est libre!
Posté par beagf (site web personnel) . Évalué à 6.
De quel standard parle tu ? Le débat porte sur les formules, et celle-ci ne sont spécifiées nulle part dans les specs actuelles de l'ODF.
Tu es comme d'habitude de mauvaise foi en accusant la "communauté" (au sens large) pour procès d'intention alors qu'elle a bien raison d'être doublement vigilants avec MS.
Et pourtant ici Microsoft ne fait rien de pire que les autre et ça gueule uniquement contre Microsoft. Oui, ils ont un lourd passif et il faut surveiller ce qu'ils font sans prendre leur déclaration pour argent comptant. Mais ils ne faut pas non-plus ce ridiculiser avec des acusation fausses.
MS a une part de marché bien supérieure à IBM avec Office et il s'agit de sa responsabilité en tant que bon citoyen et utilisateur du format de ne pas vendre un produit comme étant compatible OpenDocument si des erreurs peuvent être trouvées en 5 minutes. Pourquoi ne pas communiquer avec la communauté OpenDoc et leur demander de tester avant de release ?
Dans tout ce qui à été présenté jusqu'a maintenant, la norme est parfaitement respectée, contrairement à ce qui est dit. Le formules n'éxiste pas dans la norme, donc MS fait la même chose qu'OOo, ils l'implémentent de la manière la plus simple pour eux en attendant la prochaine version d'ODT. (à ce moment là on verra s'ils implémentent un support de la nouvelle norme.)
Donc pour l'instant il n'y a pas eu d'erreur trouvée en 5min, juste une grosse lacune dans la norme que chacun bouche comme il veut.
Pour la communication, Microsoft à fait une réunion avec le BB d'ODT ou ils ont expliquer tout le bordel et ou personne n'a gueulé. Ils ont donc communiqué. Pour les tests, tu peut être sûr qu'ils les ont fais, mais ils ont testé ce qui était dans le standard. Il est normal que ce que le standard ne couvre pas ne soit pas forcément compatible.
Le XML est même fait pour cela, quand tu veut ajouter des infos supplémentaire tu fait un namespace séparé.
MS aurrait pus faire bien pire : «pas de formule dans un ODT puisque ce n'est pas supporter par le standard»
Le jour ou le standard sera complet, on peut espérer que microsoft l'implémentera completement et que cela permettra de convertir les vieux documents, tout comme on peut espéré que la même chose sera faite dans les suite libres.
Si ce n'es pas le cas, on aurra une bonne raison de gueuler.
[^] # Re: La route est longue, mais la voie est libre!
Posté par smc . Évalué à -2.
Non-argument. Si elles ne sont pas spécifiées, elles devraient l'être, c'est tout. Il s'agit de bon sens que de se conformer à l'implémentation de référence... Samba implémente plein de choses "non spécifiées" pour l'intérop.
Et pourtant ici Microsoft ne fait rien de pire que les autre et ça gueule uniquement contre Microsoft. Oui, ils ont un lourd passif et il faut surveiller ce qu'ils font sans prendre leur déclaration pour argent comptant. Mais ils ne faut pas non-plus ce ridiculiser avec des acusation fausses.
Parce que c'est Microsoft, ils ont des responsabilités, tout le monde n'est pas entreprise leader du logiciel.
Dans tout ce qui à été présenté jusqu'a maintenant, la norme est parfaitement respectée, contrairement à ce qui est dit. Le formules n'éxiste pas dans la norme, donc MS fait la même chose qu'OOo, ils l'implémentent de la manière la plus simple pour eux en attendant la prochaine version d'ODT. (à ce moment là on verra s'ils implémentent un support de la nouvelle norme.)
Tu parles uniquement de l'article de ce blog, il y a d'autres problèmes avec la compatibilité! Regarde les autres discussions un peu partout sur le Web avant de dire qu'ils font la même chose qu'OOo, c'est faux. Le billet de Microsoft est une réponse adhominem "vous nous accusez de pas respecter le standard, regardez IBM est pas interopérable".
Donc pour l'instant il n'y a pas eu d'erreur trouvée en 5min, juste une grosse lacune dans la norme que chacun bouche comme il veut.
Faux encore une fois. http://www.robweir.com/blog/2009/05/follow-up-on-excel-2007-(...)
Pour la communication, Microsoft à fait une réunion avec le BB d'ODT ou ils ont expliquer tout le bordel et ou personne n'a gueulé. Ils ont donc communiqué. Pour les tests, tu peut être sûr qu'ils les ont fais, mais ils ont testé ce qui était dans le standard. Il est normal que ce que le standard ne couvre pas ne soit pas forcément compatible.
Faux.
Le XML est même fait pour cela, quand tu veut ajouter des infos supplémentaire tu fait un namespace séparé.
MS aurrait pus faire bien pire : «pas de formule dans un ODT puisque ce n'est pas supporter par le standard»
Non-argument. OpenDocument est un dialecte XML qui définit une sémantique propre. Si tu ajoutes des tags et des namespaces, tu n'es plus du OpenDocument. Tu es toujours XML mais *c'est pas le but*.
Le jour ou le standard sera complet, on peut espérer que microsoft l'implémentera completement et que cela permettra de convertir les vieux documents, tout comme on peut espéré que la même chose sera faite dans les suite libres.
Si ce n'es pas le cas, on aurra une bonne raison de gueuler.
On en a déjà.
[^] # Re: La route est longue, mais la voie est libre!
Posté par beagf (site web personnel) . Évalué à 4.
Elle devrait l'être mais elles ne le sont pas ! Pourquoi ?
En attendant, l'implémentation de référence pour l'interopérabilitée c'est quoi ? Celle de OpenOffice 3.0, celle de la suite d'IBM ? Une autre ?
Le plus simple ce serait pas d'avoir un vrai standard pour pouvoir rééllement gueuler ?
Parce que c'est Microsoft, ils ont des responsabilités, tout le monde n'est pas entreprise leader du logiciel.
C'est marrant il y a des fois ou ça gueule contre le monopole de Microsoft et des fois ou le même monopole sert d'argument...
Donc l'argument reste le même, Microsoft ne fait rien de pire que les autres.
Tu parles uniquement de l'article de ce blog, il y a d'autres problèmes avec la compatibilité! Regarde les autres discussions un peu partout sur le Web avant de dire qu'ils font la même chose qu'OOo, c'est faux. Le billet de Microsoft est une réponse adhominem "vous nous accusez de pas respecter le standard, regardez IBM est pas interopérable".
Non, je parle de tous les argument qui ont été présentés sur Linuxfr. Si tu en as d'autre montre des sources.
Faux encore une fois. http://www.robweir.com/blog/2009/05/follow-up-on-excel-2007-(...)
Sauf que ici, le standard est parfaitement respecté. L'encodage différent des cellules n'apparait que dans le namespace particulier de microsoft et donc ils codent les céllules comme ils veulent.
Je dirais même que c'est bien plus intéligent de ne pas changer de codage dans ces parties la, comme ça ils utilisent le même code pour serialiser leurs formules dans ODT ou dans XLS, donc moins de risque de bug.
Il faut bien ce mettre dans le crane que les extention de microsoft sont dans un namespace différent de celui d'ODT donc ils y font ce qu'ils veulent.
Et avec un peu de bol, c'est purement temporaire le temps que le standard ODT 1.2 sortent et qu'ils l'implémentent. S'ils ne le font pas, alors là, oui, on pourra gueuler. Et on aurra raison.
Faux.
Va falloir argumenter un peu. Ce n'est pas parce que Rob Weir n'a pas voulut s'y pointer et gueuler à ce moment là, que ça ne c'est jamais produit.
Non-argument. OpenDocument est un dialecte XML qui définit une sémantique propre. Si tu ajoutes des tags et des namespaces, tu n'es plus du OpenDocument. Tu es toujours XML mais *c'est pas le but*.
Tu as vraiment compris le principe du truc ?
Dans ce cas là, il me semble que AUCUNE suite n'est actuellement capable de produire un vrai tableau ODT. A partir du moment ou tu implémente es formules tu es obligé de les stocker quelque part. Tu le fais ou ?
Si tu le fait dans le namespace ODT tu fout tout le systeme en l'air.
Si tu le fait dans un namespace séparé, c'est bien plus propre, et le jour ou la spec est complete, tu peut gentillement convertir les anciens document qui utilise l'ancien namespace vers le standard.
Au moin ici ils ne bloquent pas les évolution du format en reservant des noms dans le names space d'ODT.
[^] # Re: La route est longue, mais la voie est libre!
Posté par Axone . Évalué à 2.
Peut-être un bon gros bug, faudrait ouvrir un rapport de bug auprès des 2 projets et voir ce que les développeurs disent des 2 cotés.
[^] # Re: La route est longue, mais la voie est libre!
Posté par modr123 . Évalué à 2.
# C'est pas un peu le cas du DivX ?
Posté par gUI (Mastodon) . Évalué à -1.
Me trompé-je ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: C'est pas un peu le cas du DivX ?
Posté par Earered . Évalué à 10.
Xvid, DivX & co sont des algos de compression.
Le savoir faire se situe au niveau des algos, et il y a peu d'implémentation de décodeur (il doit implémenter toute la norme, alors que l'algo de compression n'est pas obligé d'utiliser toutes les fonctionnalités).
Le cas de MS est plus proche du problème avec le standard CSS et la propriété border-radius (les coins arrondis), la norme est trop flou donc personne ne l'implémente (et l'implémentation à venir utilise les propriétés CSS propriétaire, pour Firefox, c'est le moz-border-radius pour l'implémentation proposé).
C'est tout flou au niveau de la spec, donc soit on implémente pas, soit on fait comme les voisins.
MS est vilain parcequ'il n'ont pas fait comme les voisins.
Ce que cite pbpg est le deuxième lièvre qui a été levé dans les test d'intero :
Sun a été vilain aussi, OOo 3 utilise une version draft d'odf 1.2
Pas la peine de mettre symphony dans la boucle, l'incompatibilité existe entre OOo 2.4 et OOo 3.
Le problème est plus comparable avec la propriété de transparence de powerpoint 2003 qui donne des horreurs sous powerpoint 97.
Ce qui est attendu de MS c'est d'utilisé pour odf 1.1 un namesapce compatible et de mettre des acollades là ou il faut.
Ce qui est attendu de Sun c'est d'arreté de faire sa pute en forçant le passage à odf1.2 avec son implémentation pour que son implémentation devienne la norme (et de repasser à odf1.1 par défaut en attendant que les autres suites s'allignent sur odf1.2).
odf1.0/1.1 est normé (iso), et est tout ce qui intéresse les entreprises qui vendent aux gouvernement
Ce qui fait (je pense) qu'il y a plus de colère vis à vis de MS que de Sun (en dehors de l'habitude), est que MS peut vendre aux gouvernements avec un travail baclé, tout en bloquant les autres, alors que les innovations sans considérations de Sun pour les autres éditeurs de suite bureautique n'a pas de bénéfice concret évident et immédiat (donc on prete plus facilement de "mauvaises" intentions à MS, l'appat du gain, réduction du marché, plutôt qu'une petite part d'un plus gros gateau, càd la stratégie MS classique, qui lui est reproché par la plupart des tribunaux, pour ne pas s'inquiéter de l'avenir : 100% d'un petit marché plutôt que 90% d'un gros).
[^] # Re: C'est pas un peu le cas du DivX ?
Posté par beagf (site web personnel) . Évalué à 4.
Un namespace compatible avec quoi ?
Lo norme n'indique rien pour les formules !
A partir de ce moment, si tu veux respecter la norme et proposer les formules aux utilisateurs, tu doit les mettre dans un namespace different car ce que tu ajoute n'est pas la norme.
Et à partir du moment ou tu es dans ton namespace, les accolade tu ne les met que si tu veux.
Il y a surement plein de merdes bien plus pertinentes a critiquer dans l'implementation de ODF de la part de microsoft. Ressortir celle la ne fait que mettre de plus en plus en évidence la connerie monumetale qui a été faite en sortant ODF sans rien pour les formules.
En attendant, Microsoft ne fait rien de mal, ils font comme les autres : «Ils proposent la solution la plus simple a mettre en œuvre en attendant qu'une vrai norme sorte.»
# .
Posté par snt . Évalué à 10.
- Beaucoup de postes/articles sur ce sujet sont plus ou moins partisans : il ne faut pas oublier qu'IBM est une entreprise commerciale au même titre que Microsoft. J'essaye de lire chaque intervention en oubliant qui en est l'auteur. Pour limiter l'impact de mes préjugés et me concentrer sur le propos.
- La transparence a beaucoup progressé : les specs sont dispos gratuitement et perso j'aime bien la communication de Microsoft qui explique les choix qui ont été fait et pourquoi ( les développeurs qui ont déjà eu à implémenter des standards savent qu'on trouve toujours que les specs ne sont jamais assez précises. Dire ce qui n'est pas bon permet d'améliorer la version suivante ). De plus j'aime assez l'orientation précisée : dire quelles sont les priorités du développement et qu'une de ces priorités soit l'absence de mauvaise suprise : soit ça marche comme il faut, soit ça ne marche pas mais on ne prend pas la risque d'un choix qui pourrait laisser croire à l'utilisateur que ça a marché alors que les résultats sont faux.
- Le développement est un processus itératif : ceux qui s'attendent à ce qu'une implémentation soit parfaite à la 1ere version ne sont probablement pas développeurs. Il est donc encore un peu tôt pour prêter des intentions malsaines aux différents camps alors le support d'ODF est encore récente notamment chez Microsoft.
- Selon a peu près tout le monde ODF 1.2 comblera pas mal de lacunes. Je comprends l'impatience mais je trouve que dans l'ensemble les choses bougent plutot dans le bon sens.
- Qualifier son interlocuteur de "fanboy" décrédibilise plutôt l'auteur
- Moinsser sur linuxfr dès qu'on est pas d'accord n'est pas la plus belle preuve d'ouverture d'esprit
[^] # Re: .
Posté par ploum (site web personnel, Mastodon) . Évalué à 10.
T'es nouveau ici ?
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: . c'est si simple
Posté par GG (site web personnel) . Évalué à -3.
c'est si simple, dans le logiciel libre, quand "on" développe quelque chose, "on" sort une version alpha ou béta (dites de dev.) et ce genre de bug ou d'incohérence est remonté assez vite et peut être corrigé ou du moins, modifié.
En fait, il y a discussion tout au long du développement d'un logiciel libre.
Dans le cas qui nous intéresse, non. Si Microsoft prenait en compte les bugs de ses logiciels, ça se saurait.
Par exemple, depuis combien de temps les extensions des fichiers ne sont pas affichés, par défaut? (ça doit être le cas dans windows vista). Ah oui, c'est un choix par défaut... donc ce choix aurait du être changé depuis des années, parce qu'il existe depuis windows 98 (et probablement avant), et parce que ce choix par défaut favorise la propagation des virus.
L'objectif de Microsoft est de sortir une version, quelque soit son état, et temps pis si cela posera des problèmes, parce que cela ne leur pose pas de problème (et qu'ils continuent au contraire de vendre une version qui corrige un bug, et en invente des nouveaux).
Tout le monde se rappelle des mises à jours foireuses...
Tout le monde sait combien de temps les monstrueuses failles de sécurités sont restés sur Internet Exploreur 6, malgré les différents pack.
Tout le monde sait qu'Internet Explorer 7 en corrige une partie seulement, et introduit d'autres horreurs.
J'ai juste fait une recherche avec un moteur de recherche, et voilà (un exemple, juste un):
http://social.msdn.microsoft.com/Forums/fr-FR/securitefr/thr(...)
Il faudra combien de temps pour qu'un correctif soit en place? en 2010, on n'y sera encore.
Les failles de sécurité apparues avec Firefox ont été très vite corrigées, et c'était sur des version de développement (à l'exception de l'une, où une boite à attendu dans son coin que la version stable soit publiée pour faire sa pub).
On attends (sans espoir) que Microsoft soit un peu plus fair-play, la preuve, il y a des gens qui tests et remontent des bugs, mais visiblement Microsoft n'en a rien à battre, même ceux qui bossent chez Microsoft, ce qui prouve bien comment son considéré les utilisateurs/clients de Microsoft.
A+
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
# Type
Posté par Dysen . Évalué à 3.
C'est peut-être mon esprit de programmeur, mais vouloir additionner 2 types différents je trouve ça moyen.
[^] # Re: Type
Posté par 2PetitsVerres . Évalué à 0.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Type
Posté par Dysen . Évalué à 1.
[^] # Re: Type
Posté par pasBill pasGates . Évalué à 5.
Bonne chance pour savoir dans quel cas tu es quand tu recois une feuille de calcul ODF...
[^] # Re: Type
Posté par JoeltheLion (site web personnel) . Évalué à 5.
[^] # Re: Type
Posté par nodens . Évalué à 1.
MS met le doigt dessus, en fait peut-être un peu trop.... Je ne pense pas qu'il s'agisse là de casser volontairement l'interopérabilité. D'une, c'est mauvais pour leur business (ils ont plutôt intérêt à être inter-opérables, puisqu'ils ne sont pas les premiers à implémenter la norme, tant qu'ils ne sont pas dominant en tout cas), et de deux, c'est une excellente occasion de se faire bien voir : « regardez, on est victime de la non-finition de tel produit, bon il faut mettre de l'ordre dans tout ça, heureusement qu'on est là pour mettre des coups de pieds aux fesses ».
Il y a un problème technique (ou politique), ils le mettent en évidence, c'est tout à fait légitime, et plutôt une bonne chose. Par ailleurs ils s'en servent comme argument marketing, et quelque part c'est de bonne guerre...
Allez, un peu de recul : dans un cas comme ça entre Gnome et KDE, ou entre Webkit et Gecko, on aurait pas trollé à n'en plus finir peut-être ? Comme il n'y a pas de solution clairement juste techniquement, le fait que ça ne soit pas libre ne change pas grand chose : Dans un projet libre si il y avait eu un patch il n'aurait pas été appliqué, et ça aurait enflammé la toile pendant un moment jusqu'à ce que la norme sorte pour mettre tout le monde d'accord.
/me va refaire du pop-corn
[^] # Re: Type
Posté par e-t172 (site web personnel) . Évalué à 3.
# Heureux les épis murs ...
Posté par Benbben . Évalué à 2.
Pour partir au front comme ça, la fleur au fusil, en sachant que tu vas avoir mal, il faut être courageux.
C'est bô comme la bataille de Verdun au petit matin ;-)
[^] # Re: Heureux les épis murs ...
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Heureux les épis murs ...
Posté par thedude . Évalué à 2.
Alors on respire fort, on se calme un peu, on attends ODF1.2 avec openformula (at last!!!).
Et on attends les declarations/roadmap de MS a ce sujet, on fait de meme avec sun/ibm et une fois les premieres version d'ooo/symphony/office sorties, on ressort le mariage de maya et la on pourra enfin se faire un avis objectif sur l'interoperabilite reelle d'odf ainsi que la toute fraiche orientation interop' de la section office de MS.
# Dans ce cas le probleme est...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 1.
Resultat : l'utilisateur est content, mais il ne sait pas rellement la raison qui fait que son calcul est bon ou mauvais.
Les conversions implicites, c'est pratique, ca fait gagner du temps, mais c'est une faille dans le processus. Il suffit de voir le nombre de personnes qui codent :
flottant a = 3/2
afficher a
et qui s'etonnent lorsqu'ils constatent que le resultat est 1.
Je parle des developpeurs parce que c'est le milieu que je connais, et en general on fait des tests unitaires donc on constate rapidement l'erreur. Mais des gens qui manipulent des centaines ou des milliers de nombres, comment peuvent-ils verifier que leurs donnees ne sont pas mal interpretees ?
Il faudrait etre un peu plus rigoureux (et que les outils nous y aident) et tout rentrerait dans l'ordre.
p.s : desole pour l'absence d'accents, je me retrouve malgre moi avec un clavier qwerty :s
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Dans ce cas le probleme est...
Posté par thedude . Évalué à 2.
[^] # Re: Dans ce cas le probleme est...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
Le typage des donnees c'est un truc de bon sens, un truc de la vie de tous les jours : les secretaires, comme tu dis, quand elles rangent leurs couverts je suppose qu'elles mettent elles aussi les fourchettes avec les fourchettes et les cuilleres avec les cuilleres.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Dans ce cas le probleme est...
Posté par thedude . Évalué à 2.
C'est un detail particulierement technique d'implementation du a la facon dont les donnees sont traitees par les processeurs.
Mais humainement, ca n'a pas de sens.
Parce qu'on est capable naturellement de faire la difference entre 2 et STX (0x02 en ascii).
Au supermarche, tu additiones 2.45E et 1.75E pour faire tes courses et ca marche tres bien, ca te choque pas, pourtant t'as pas de var prix:int = 2.45; var currency:Currency=Currency.EURO; en entete de l'etiquette.
quand elles rangent leurs couverts je suppose qu'elles mettent elles aussi les fourchettes avec les fourchettes et les cuilleres avec les cuilleres.
Ca depend lesquelles, je suis sur que certaines sont aussi bordelique que moi.
Et leur tiroir ne refuse pas de se fermer si une cuillere se trouve parmi les fourchettes.
[^] # Re: Dans ce cas le probleme est...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Tu dis n'importe quoi : dans 2.45E, si je ne m'abuse, le type de donnee apparait : ce sont des euros (donc des nombres a virgule ; et en plus on sait qu'on ne va pas les additionner avec des dollars sans effectuer de conversion). Ca sert a rien d'ecrire la meme chose en beaucoup plus long avec des termes cabalistiques juste en dessous.
Et leur tiroir ne refuse pas de se fermer si une cuillere se trouve parmi les fourchettes.
J'ai surtout pas dit le contraire. Apres, si tu manges ta viande avec une cuillere, ce n'est pas de la faute du tiroir : la faute en incombe a celui qui a range les couverts et a celui qui a pris une cuillere sans verifier que ce n'etait pas une fourchette.
Ca veut dire que le format standard (le tiroir), bah il tient pas la route si les logiciels qui importent (celui qui prend une fourchette) et exportent (celui qui range les couverts) n'effectuent aucune verification sur les donnees transmises.
J'en arrive a ce que je disais : si on veut simplifier l'experience utilisateur tout en la fiabilisant, le typage des donnees il doit etre fait. Soit a la saisie, soit a l'export, soit a l'import (ca peut tout aussi bien etre simplement des avertissements, ca ne demande pas necessairement une operation de l'utilisateur).
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Dans ce cas le probleme est...
Posté par thedude . Évalué à 3.
Nan, parce que 2,001 ca veut dire 2 choses radicalement differentes de differents cotes de l'atlantique.
Ou pousser le concept jusqu'au bout, a savoir interdire addition int/float ou autres joyeusetes, comme le fait caml avec ses operateur entiers/flottants?
Bref, colonne typee string ou int, tu prends une string en entree dans les deux cas de toutes facons.
Juste que dans un cas, tu peux pas assurer l'existence de l'operation jusqu'a l'evaluation, mais ca change pas grand chose conceptuellement.
Note que je viens de tester dans excel, et c'est bien precise que c'est un format d'affichage, pas un type de donnees.
Ca donne des indices au tableur pour formatter la valeur suivant certaines conventions, mais le type est toujours inferee automatiquement.
Tu dis n'importe quoi : dans 2.45E, si je ne m'abuse, le type de donnee apparait : ce sont des euros (donc des nombres a virgule ; et en plus on sait qu'on ne va pas les additionner avec des dollars sans effectuer de conversion). Ca sert a rien d'ecrire la meme chose en beaucoup plus long avec des termes cabalistiques juste en dessous.
Ah bah si ca sert a rien, pourquoi tu veux forcer l'utilisateur a faire un String.parseInt(cellule) alors?
Parce que pour autant que je sache, l'operateur + sur une classe utilisateur est pas trivial (meme si ici, ca parait assez evident).
Bien la preuve que la notion de cast explicite obligatoire n'a rien de naturel: tu vois un 2, c'est le nombre 2, qu'il soit suiv par un symbole euro ou entoure de chaine (que tu ne vois meme pas dans le cas du tableur).
J'ai surtout pas dit le contraire. Apres, si tu manges ta viande avec une cuillere, ce n'est pas de la faute du tiroir : la faute en incombe a celui qui a range les couverts et a celui qui a pris une cuillere sans verifier que ce n'etait pas une fourchette.
Et? La viande, ca se mange tres bien avec une cuillere. C'est un peu moins pratique, mais ca marche.
Un peu comme parser un entier dans une string: c'est un peu plus chiant, mais c'est faisable.
si on veut simplifier l'experience utilisateur tout en la fiabilisant, le typage des donnees il doit etre fait.
Simplifier l'experience utilisateur?
Tu vas simplifier quoi en disant a l'utilisateur que 2+"2" est illegal mais que ooo veut bien convertir en 2+2?
L'utilisateur il est pas developpeur, c'est une notion qui lui passe au dessus du cigare et il s'en tamponne.
il voit un 2 dans une cellule et un autre 2 dans un autre cellule, additione les moi.
Il est capable de comprendre que 2 + toto n'a pas de sens par contre (et ca tombe bien, il s'etonnera pas de voir 2toto ou "erreur" dans la cellule ou il a demande ca).
Bref, le cast implicite sans emmerder l'utilisateur, ca fait bel et bien partie de la problematique du tableur.
[^] # Re: Dans ce cas le probleme est...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
Simplifier la verification des donnees, histoire qu'il n'ait pas a verifier que 1+2=3. Je parle de l'autre utilisateur, celui qui recupere le docu;ent, pas celui qui l'ecrit. L'utilisateur c'est pas uniquement celui qui cree le document.
Tu restes bloque sur la verification a la frappe ; comme je l'ai dit plus haut, ca peut tres bien etre une verification effectuee a l'import (donc il n'est pas question, la, d'enquiquiner le redacteur du document).
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Dans ce cas le probleme est...
Posté par 2PetitsVerres . Évalué à 3.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Dans ce cas le probleme est...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 1.
C'est un peu le même principe que l'écran de démarrage graphique de la majorité des distributions linux : tu as une barre de progression qui ne dit rien sinon l'état d'avancement, mais tu peux demander à afficher les opérations et résultats associés effectuées au démarrage.
Il suffit que le fonctionnement par défaut ne soit pas intrusif ; ça n'empêche pas de donner accès à des informations supplémentaires aux utilisateurs qui le souhaitent.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.