Comme le rappelle le site formats-ouverts.org, OOXML est le format bureautique de Microsoft, Office OpenXML. Il a été reconnu comme un standard ECMA en décembre 2006 (...). OOXML est désormais proposé à l'ISO pour l'établir comme standard ISO selon une procédure appelée fast track (elle est plus rapide que celle habituelle). OOXML est un concurrent direct d'ODF le format d'Open Office, déjà normalisé à l'ISO.
L'AFNOR doit désormais déterminer sa position sur cette procédure et ce format le 5 février.
Pour sa part, l'APRIL considère que la procédure accélérée n'est pas justifiée, et que la date limite du 5 février 2007 est largement prématurée, compte tenu des risques et des incertitudes qui grèvent lourdement le standard proposé et qui sont incompatibles avec la mission des instances nationales et internationales de normalisation.
Hier, le député Bernard Carayon a posé une question écrite au ministre délégué à l'Industrie pour connaître avec précision la composition du groupe de travail chargé d'examiner les spécifications d'OOXML et la position de l'État français sur ce dossier (notamment au regard de l'arrivée annoncée du Référentiel Général d'Interopérabilité ou RGI).
NdM : lire également sur le site de l'AFUL : L'AFUL appelle l'AFNOR et les organisations de normalisation francophones à s'opposer à l'usage de la procédure accélérée dans l'examen d'une deuxième norme bureautique à l'ISO.
Aller plus loin
- La lettre de l'APRIL à l'AFNOR [pdf] (32 clics)
- Guerre des formats : quelle est la position de la France ? (1 clic)
- Question du député Carayon (1 clic)
- Dernières dépêches sur le RGI (0 clic)
# L'AFNOR est une ruine !
Posté par Pierre Jarillon (site web personnel) . Évalué à 10.
Quant à l'AFNOR, cette organisation qui est chargée par le ministre de l'industrie de représenter la France auprès de l'ISO, elle est théoriquement composée de personnes représentatives de l'industrie française... En réalité on y trouve un représentant d'IBM, deux de HP, trois de Microsoft... C'est à dire que l'on confie à l'industrie américaine le soin de dire ce qui est bon pour nous.
Monsieur le Ministre, on vous a trompé, c'est du moins ce que je veux croire. La solution serait de suspendre immédiatement l'AFNOR et de penser à remplacer cette structure archaïque par un organisme représentatif et adapté à notre époque.
En effet, il n'est pas admissible par exemple de payer 37,05 ¤ pour avoir le droit de connaître la norme "Sécurité des machines - Arrêt d'urgence". Que diriez-vous de payer la même chose pour connaître chaque article du code civil ou du code pénal ?
D'autre part que penser du comportement de France Telecom dont les représentants à l'AFNOR ne se prononcent pas au sujet de OOXML ? Cela mériterait bien quelques sanctions, non ?
L'AFNOR est une ruine. Ruine archéologique car son mode de fonctionnement est révolu et une ruine pour ceux qui veulent connaître les normes.
# Course poursuite
Posté par _PhiX_ . Évalué à 4.
Lequel des deux, entre la décision de l'AFNOR et les prescriptions du RGI, l'emporte en cas de conflit et de contradiction ?
[^] # Re: Course poursuite
Posté par Mes Zigues . Évalué à 4.
Par contre, la question qui d'une norme AFNOR et du RGI l'emporte, la question est excellente.
Légalement, une norme AFNOR doit obligatoirement être utilisée dans les appels d'offre. La puissance publique peut s'en passer à condition de s'expliquer devant le juge si besoin (mais pour cela une plainte doit être posée ce qui est relativement rare).
Que se passe-t-il si face à un standard conseillé(?) par le RGI il existe une norme AFNOR ?
De mémoire, c'est déjà le cas avec les formats bureautiques pour lesquels il existe la norme ISO "ODA/ODIFF" (ie SGML) qui avait été reprise dans la collection française.
[^] # Re: Course poursuite
Posté par Guillaume Rossignol . Évalué à 3.
Ensuite pour l'opposition NF et RGI.
Il y a t-il vraiment une possibilité de contradiction, dans la mesure ou la norme de l'afnor decrit un processus à suivre pour pouvoir dire qu'on respecte cette norme, alors que les RGI fixe les normes qui doivent être utilisées ?
Et une derniere question, je suis allé faire un saut sur le site de l'AFNOR histoire de voir à quoi ressemblaient les normes... On peut se procurer légalement et gratuitement les textes des normes ? Parce que payer pour une norme, sa me fait un peu comme si on devait payer pour pouvoir consulter les codes juridiques (autrement dit, je trouve sa douteux, mais il y a peu etre une bonne raison).
[^] # Re: Course poursuite
Posté par Doum . Évalué à 3.
Si vous trouvez une norme non payante, faites-moi signe ! J'ai toujours dû payer, et cher.
# Un peu de contexte
Posté par CamilleM . Évalué à 4.
Pour une bonne vue d'ensemble du problème :
http://www.grokdoc.net/index.php/EOOXML_Contacts
http://www.grokdoc.net/index.php/EOOXML_objections
http://www.grokdoc.net/index.php/EOOXML_at_JTC-1
# Précisions
Posté par TImaniac (site web personnel) . Évalué à 1.
Déjà le fast-track, c'est 6 mois, c'est pas le 5 février que l'AFNOR doit donner son avis sur l'OpenXML en soit.
Le 5 février, c'est la date butoir à laquelle chaque participant du comité de normalisation doit donner son avis sur l'éventuelle "contradiction" de la proposition faite par rapport aux autres standards ISO existant, bref, est-ce que l'OpenXML est potentiellement en conflit avec d'autres standards ISO.
Là dessus les avis sont partagés, évidemment du côté des défenseurs de l'ODF, c'est un format contradictoire avec la norme ISO existante ODF puisque les 2 formats décrivent grosso modo la même chose : des formats pour suites offices.
Pour MS, c'est pas contradictoire, pour eux il est tout à fait possible d'implémenter OpenXML en parallèle des autres standards comme l'ODF. Ils prennent un exemple pour eux plus "réaliste" de contradiction : une nouvelle norme sans fil qui demande une certaine plage de fréquence empêchant d'utiliser une autre norme sans fil basée sur les mêmes fréquences (bref, incompatibilité).
Après il va rester 5 mois pour discuter technique et specification à proprement parlé, si la première étape passe bien évidemment.
Il est également bon de préciser que la procédure "fast-track" n'est pas spécialement plus rapide, elle prend 6 mois en tout, quand l'ODF a été certifié ISO... en 7 mois.
http://opendocumentfellowship.org/node/296
http://blogs.msdn.com/brian_jones/archive/2007/01/29/explana(...)
[^] # Re: Précisions
Posté par Laurent Godard . Évalué à 9.
Bon, là c'est un peu raccourci ....
Il y a en fait 3 étapes à l'aboutissement de la norme OpenDocument :
1. Utilisation du formalisme XML dans la bureautique : Pour OpenDocument, les prémices, c'est 1999, implémentation dans OOo/staroffice en octobre 2000 (OOo 1.0). Depuis des années d'expériences et des implémentations multiples avec tous les retours et cycles itératifs (convergents) pour améliorer; Ou en était la bureautique XML de MsOffice à cette époque ?
2. La standardisation OASIS, commencée en 2003, OpenDocument standardisé en 2005. Le comité technique regroupe plusieurs éditeurs logiciels/bureautique et non pas un seul ce qui traduit bien entend une volonté d'ouverture et de standardisation.
3. La normalisation ISO. Le processus a suivi toutes les étapes normales du processus ( http://www.iso.org/iso/en/widepages/stagetable.html ) et donc une revue sur le fond par des organismes autres que ceux standardisant (ce qui est saint puisque la conclusion est forcement orientée). A noter, que rien que les phases de revues techniques font 7 mois (étapes 40.20 et 50.20). Donc toutes les étapes administratives sont à rajouter (et ca peut être long). Dans le cas du fast-track, il n'y a pas de revue sur le fond mais simplement une vérification a prosteriori
Donc le processus de normalisation s'étale sur près de 6 à 7 ans pour OpenDocument. Pour le format de MsOfficeXML, c'est 2003 pour un embryon de bureautique xml (mouais ...) et Mai 2005 (iirc) pour le début de l'Ecma ... et la précipitation, ca se voit : un document de plus de 6000 pages, là ou un autre visant aux même objectifs en fait 10 fois moins, traduit au mieux un manque flagrant de recul et de synthèse (il est quelquefois plus rapide de réinventer sa propre roue que d'essayer d'intégrer celles déjà normalisée - si odf fait 600 pages, c'est qu'il utilise astucieusement les renvois à d'autres normes, non ?) au pire une volonté délibérée d'imposer ses propres formats (non normalisés, non standardisés) en profitant de sa force déploiement (la sortie de vista nous rappelle le chiffre de 95% des PC).
Donc, pour conclure,,le processus n'est pas le même puisque dans le cas de OpenDocument, l'iso a revu techniquement (étapes 40 et 50) alors que le fastrack demande une confiance sur les travaux et conclusions de l'organisme de standardisation (ecma) qui, rappelons le encore, a pour un de ses objectifs premiers la compatibilité avec l'existant d'un éditeur et non l'établissement d'une norme (ouverte) pour la bureautique fédérant de multiples éditeurs.
Mon jugement est forcement orienté, mais à ma décharge celles de la partie adverse également. J'espère ne pas faire autant de FUD, et si c'est le cas, j'en suis sincèrement désolé.
[^] # Re: Précisions
Posté par Pierre Jarillon (site web personnel) . Évalué à 6.
Si le document OOXML (nom choisi pour prêter à confusion ?) est 10 fois plus gros que l'ODF, c'est parce qu'il prend en compte la compatibilité avec des formats plus anciens et les bugs des logiciels qui allaient avec. Cette énormité n'est rien d'autre qu'une mesure anti-concurrentielle.
Le document ODF est très bien rédigé et ne comporte aucune astuce qui pourrait rendre difficile de l'utiliser. A contrario, ce n'est pas le cas de Microsoft qui soit noie le compétiteur dans de monstrueuses spécifications (OOXML), soit ne publie rien (MS Office), soit publie un document incomplet qu'il ne respecte pas (RTF).
En résumé, Microsoft ne mérite pas notre confiance.
# stand microsoft à solution linux 2007
Posté par CyrrusSmith (site web personnel) . Évalué à 3.
Je les ai suivi et j'ai tenté de dialoguer avec le type du stand.
Celui ci n'était pas en état de le faire. Trop en colère intérieurement.
Je lui ai quand répondu qu'il ne falait pas s'étonner de telles réactions quand son entreprise s'attaquait régulièrement à notre démocratie en faisant passer des lois scélérate, et que finalement un peu de papier hygiènique sur son stand était peu de choses.
[^] # Re: stand microsoft à solution linux 2007
Posté par ome . Évalué à 2.
[^] # Re: stand microsoft à solution linux 2007
Posté par Vador Dark (site web personnel) . Évalué à 6.
Après, on en pense ce qu'on veut, mais pour ma part je trouve ça très moyen comme réaction. Bon, ceci dit, c'est assez drôle je l'accorde, mais bon au final ça fait plus de mal que de bien amha.
[^] # Re: stand microsoft à solution linux 2007
Posté par psychoslave__ (site web personnel) . Évalué à 1.
[^] # Re: stand microsoft à solution linux 2007
Posté par ome . Évalué à 2.
[^] # Re: stand microsoft à solution linux 2007
Posté par hervé Couvelard . Évalué à 3.
Lorsque tu as fait une énorme connerie chez ms -> stand microsoft à solution linux;
[^] # Re: stand microsoft à solution linux 2007
Posté par Pol' uX (site web personnel) . Évalué à 3.
Adhérer à l'April, ça vous tente ?
[^] # Re: stand microsoft à solution linux 2007
Posté par ome . Évalué à 2.
Et Transparent l'écran bleu s'il-vous-plaît avec Vista.
A propos: ils n'ont pas déposé un brevet pour l'écran bleu? Ou le droit d'auteur leurs suffit-il?
# L'OOXML, c'est bon, mangésen
Posté par chtitux (site web personnel) . Évalué à 3.
Microsoft s'apprête à lancer un nouveau format, avec des specs ouvertes (au moins normalisées), basé sur un langage normalisé (XML).
Cependant, un autre format présente déjà toutes ses catactéristiques : l'ODF.
Celui ci est basé sur XML, est normalisé, etc.
Bon. Quelle est la ou les différences entre les deux.
J'ai cru lire sur le net que l'OOXML semble plus proche de la façon de construction des documents de MS Office que d'OpenOffice.org
En gros, intégrer un doc OOXML sera plus compliqué à codé sur OpenOffice [que ne l'est déjà ODF].
Mais existe-t-il d'autres arguments ? MS a déjà annoncé de faire payer des royalties sur son format ?
[^] # Re: L'OOXML, c'est bon, mangésen
Posté par BAud (site web personnel) . Évalué à 5.
Sans parler de la volonté affichée d'avoir _son_ standard plutôt que d'avoir contribué à celui "pour tous" ? Cela n'est pas sans rappeler le syndrôme NIH... sans l'excuser pour autant.
[^] # Re: L'OOXML, c'est bon, mangésen
Posté par Gniarf . Évalué à 8.
* OOXML contiendra une fonction volontairement bugguée dans quelques rares cas pourris extrèmes (1900) pour garantir la rétrocompatibilité avec Office 97 de y'a 10 ans
* ODF ne contiendra pas cette fonction du tout parce qu'ils n'ont pas pensé à la mettre
en gros :
* Microsoft a documenté SON format et pas un format idéal et universel, ou de consensus (comme l'est par exemple la norme SQL 92). va falloir se coltiner les merdes qui vont avec
* ODF est incomplet/imprécis, surtout si on s'éloigne de l'application phare, le traitement de texte cloné sur Word.
on n'est pas sorti de l'auberge, faut pas croire.
[^] # Re: L'OOXML, c'est bon, mangésen
Posté par Pierre Jarillon (site web personnel) . Évalué à 1.
Il m'avait expliqué il y a environ 4 ans que la convergence avec ODF était difficile en raison de concepts différents. Je lui ai donc demandé cette année comment il avait résolu cela. Certaines fonctions ont été converties facilement car les concepts étaient communs, d'autres ont été refaites et quand les concepts étaient trop différents, les deux ont été inclus dans la norme. Résultat, tout le monde sauf Microsoft converge vers l'ODF
Ce n'est assurément pas cet esprit de convergence qui anime Microsoft, bien au contraire.
[^] # Re: L'OOXML, c'est bon, mangésen
Posté par olgk . Évalué à 1.
# Un autre son de cloche
Posté par olgk . Évalué à 4.
Et encore une autre vision, évidemment complètement biaisée, mais qui vaut le coup pour entendre ce qu'en disent tous les partis, celle de Brian Jones, qui s'occupe d'OpenXML chez Microsoft: http://blogs.msdn.com/brian_jones/archive/2007/01/29/explana(...) (son blog a beaucoup d'entrées intéressantes sur OOXML, et le débat ODT/OpenXML).
[^] # Re: Un autre son de cloche
Posté par reno . Évalué à 3.
[^] # Re: Un autre son de cloche
Posté par fleny68 . Évalué à 3.
Au lieu de cela, on a des normes W3C pour les fichiers Web, des normes ISO pour ceux de la bureautique, et les parties communes ne sont utilisées qu'en interne dans la description des standards mais pas dans le format de fichier. Résultat des logiciels largement peu compatibles. Par exemple le filtre d'import SVG de OOo a été incapable de m'afficher correctement le SVG généré par Geonext là ou Firefox 1.5 s'en tirait bien. Ce qui est quand même ennuyeux.
On a vraiment l'impression que les gens d'OOo ont standardisé leur propre format de fichier. Résultat l'import/export du SVG dans OOo Draw est le truc qui leur manque le plus. Conséquence qui frise le ridicule quand on s'appuie sur les standards.
Ceal dit la critique sur ce que ODF aurait du utiliser n'enlève rien à la critique de OOXML, et à la grande qualité de la lettre de l'APRIL.
Ce n'est pas parce qu'ODF ne fait pas les choses au mieux que cela justifie qu'OOXML les fasse encore pire. Et MS peut proposer une révision de ODF officielle pour l'améliorer si quelque chose lui manque. SVG en est à sa troisième version, non?
# Analyse du document de 6000 page via un processus collaboratif.
Posté par fleny68 . Évalué à 4.
Les résultats sont chez Groklaw [2], et semblent etre la source des critiques reprises par l'APRIL:
Je ne sais pas si l'info est déjà passée ici, mais je trouvais ça bien de le préciser.
[1] http://www.robweir.com/blog/2007/01/linuss-law-applied-to-st(...)
[2] http://www.groklaw.net/article.php?story=20070123071154671
[^] # Re: Analyse du document de 6000 page via un processus collaboratif.
Posté par fleny68 . Évalué à 3.
http://www.robweir.com/blog/2006/01/how-to-hire-guillaume-po(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.