TImaniac a écrit 6420 commentaires

Ben le but du minitel était de former un réseau de terminaux permettant d'accéder à des serveurs qui fournissaient et controlaient toutes les données.
Internet est à l'opposé un réseau ouvert ou chaque noeud est joignable et où chacun peut partager l'information.
Le minitel 2.0, c'est tout ce qui vise à faire ressembler internet au minitel : centralisation des données, contrôle des données, limitation de l'accès aux données, filtrage, etc.

50% ? euh, IE6, c'est entre 10 et 20% (selon les stats) de parts de marché aujourd'hui... faudrait peut être arrêter avec IE6 non ?

Oué enfin il est pas très frais ton poisson, depuis Visual Studio 2005, l'utilisation de ces fonctions génère un warning "Deprecated".

Si si, ils font ce qu'ils veulent avec ODF comme avec OOXML, ils les modifient s'ils en ont envie. Je vois pas de différence de ce point de vue entre ODF et OOXML.

Et tu veux être indépendant comment du fournisseur si tu peux pas changer ?

Euh, c'est la licence d'une CTP, "pre-release software", la licence des CTP de MS est souvent comme ça...

"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...

Le but est effectivement de parler l'interopérabilité avec des applications tierces, mais dans le but d'être interopérable avec MS Office. C'est marqué sur le site ECMA clairement :
"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(...)

Eh pas de ma faute, suffit de lire le mot dans son contexte, à savoir une page entière où il n'est question que de support entre produits MS.
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.

Ben pour les tableurs, y'a les fonctions (somme, etc.), OOo et MS Office ont un sous-ensemble à peu prêt en commun mais certaines fonctions ne sont supportés que dans l'un ou l'autre des produits.
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 ?

Mais pour M$ c'est uniquement une plaquette commerciale.
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.

je l'ai déjà fais 10 fois quitte à faire le gros lourd et toi t'en redemande :)
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.

Arrêter de jouer les Rabbi Jacob :) en répndnt à une question par une autre question.
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...

ouverture est un mot passe partout qui veut dire tout et n'importe quoi.
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é...

Curieuse définition.
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.

Pondre du WMF n'est pas risqué, interpréter du WMF implique d'implémenter GDI.
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)

Go-oo par exemple le fait très bien.

Et donc ?
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.

l faudrait me montrer que Java et MPEG4 étaient imposés.
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.

Oué sorti de son contexte, ca paraît bizzare, mais dans le texte que tu pointes ca paraît logique : ils parlent d'interopérabilité entre produits Microsoft. Les produits référencés sont les différentes générations de Microsoft Office, il n'est nullement vendu l'interopérabilité comme le fait ODF :
ODF frees documents from their applications-of-origin, enabling them to be exchanged, retrieved, and edited with any OpenDocument-compliant software or tool.

c'est pas essentiel pour un utilisateur, mais c'est essentiel pour le développeur : ca veut dire qu'il peut pas valider correctement les documents produits par son implémentation.
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.

Dans mes souvenirs, la norme ODF parlait de MPEG4 et Java, niveau brevets on a vu mieux comme contenus...
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

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.
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 !"

Oué un peu comme ODF qui autorise tout et n'importe quoi comme format d'image, un manque d'exhaustivité qui fait vraiment tâche dans un format d'interopérabilité. Un peu comme la balise video d'HTML5 : on a pas les couilles d'imposer un format, alors on utilise le consensus mou qui plaît à tous les participants de la petite sauterie et qui au final nuit à l'utilisateur.

aucun rapport.
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.

Une beta me paraît étonnant, sachant qu'aujourd'hui le blog annonce plutôt une CTP pour juillet...
http://blogs.technet.com/office2010/default.aspx