La guerre des formats

3 semaines d’absences, et la guerre des formats bureautiques fait toujours rage, avec quelques éléments intéressant que je souhaite porter à votre connaissance.

La question centrale est la suivante: peut-on accepter que le format Microsoft Office Open XML soit considéré comme une norme ?
L’enjeu pour les utilisateurs est important puisqu’il est question de pouvoir rester maitre de ses documents bureautiques: Sans une norme bien définie, les documents ne sont utilisables qu’avec le logiciel commercial MS Office.
Problème: un service public peut-il raisonnablement mettre en ligne un document explicatif si pour consulter celui-ci il faut avoir acheter le logiciel d’un éditeur spécifique. En la matière, la transparence, l’égalité de traitement et le simple bon-sens impose d’utiliser un format de document ouvert, connu, expliqué, pour lequel plusieurs outils de lecture existent, couvrant tous les utilisateurs potentiels.

Le site http://www.noooxml.org/ donnes un argumentaire précis et détaillé, en français, dont je vous invite à lire la traduction, reproduite ci-après… lecture édifiante !

Réquisitoire contre OOXML

Ce document expose les raisons pour lesquelles le document DIS 29500 “Office Open XML” (OOXML) ne satisfait pas aux critères définis par l’ISO pour un standard international. Ce document examine seulement une petite partie des centaines de lacunes graves que nous avons découvertes et documentées.

1. Critères pour l’évaluation des normes

Qu’est-ce qu’une norme ? Plusieurs définitions pertinentes sont disponibles. L’ISO dit :

 

“[Un] document, établi par consensus, et approuvé par une organisation reconnue, qui fournit, pour un usage courant et répété, des règles, des directives ou des caractéristiques pour les activités ou leurs résultats, visant à atteindre le meilleur degré d’ordre dans un contexte donné.

NOTE : les normes devraient appuyer sur les résultats éprouvés de la science, de la technologie et de l’expérience, et viser le bénéfice maximal pour la communauté.”1

Les standards britanniques de la BSI sont:

“… une norme est une façon adoptée et reproductible de faire quelque chose. C’est un document publié qui contient une spécification technique ou d’autre critères précis destinés à être utilisés de façon cohérente comme règle, directive ou définition. Les normes aident à se simplifier la vie et à augmenter la fiabilité et l’efficacité des biens et des services utilisés. Ils sont censés être incitatifs – un condensé des meilleures pratiques plutôt que de la pratique commune. Les normes sont créées en assemblant les expériences et l’expertise de toutes les parties intéressées, telles que les fabricants, les revendeurs, les utilisateurs et les régulateurs d’un matériel, produit, procédé ou service particulier.”2

Les directives ISO/IEC JTC1 mentionnent:

“L’un des buts de la normalisation en Technologies de l’ Information est d’assurer que les produits disponibles sur le marché possèdent les caractéristiques d’ interopérabilité, de portabilité et d’ adaptabilité culturelle et linguistique. Pour cela, les normes développées devraient refléter les pré requis des Caractéristiques Stratégiques Communes suivantes :

  • Interopérabilité ;

  • Portabilité ;

  • Adaptabilité culturelle et linguistique.”3

D’après ce qui précède et d’après d’autres définitions nationales, quelques thèmes communs émergent pour la caractérisation des normes :

 

  1. Elles définissent des critères communs précis pour faire quelque chose de façon reproductible.

  2. Elles fournissent un niveau optimal d’ordre dans un contexte donné, censé être incitatif, donnant les résultats scientifiques, technologiques et expérimentaux éprouvés, un résumé des meilleures pratiques plutôt qu’un état des pratiques courantes.

  3. Elles encouragent l’ interopérabilité et la portabilité.

  4. Elles s’ adaptent aux différentes langues et cultures.

Ce document évalue la proposition DIS 29500 “Office Open XML” (OOXML) vis-à-vis de chacun de ces critères. Certains exemples spécifiques de problèmes avec la spécification OOXML sont mentionnés, mais ce ne sont qu’une poignée d’ exemples extraits d’une liste de plusieurs centaines. Le nombre élevé de problèmes sérieux posés par OOXML démontre son immaturité comme spécification et sa non-pertinence dans le cadre d’une procédure accélérée d’ adoption (Fast Track approval) comme norme ISO.

 

2. Précis, reproductible, commun

Ces critères demandent à une norme de fournir une description écrite détaillée permettant une pratique commune de la technologie.

Premièrement, la partie WordProcessingML d’OOXML liste un grand nombre de “paramètres de compatibilité” (Compatibility Settings)4 qui permettent à Microsoft de stocker les informations liées aux différents comportements des versions précédentes de ses applications. Ces paramètres ont des noms comme “footnoteLayoutLikeWW8”, “autoSpaceLikeWord95” et “useWord97LineBreakRules.”5 Cependant, la spécification OOXML ne fait que lister les noms de ces paramètres; elle ne les définit jamais. Microsoft seule connaît la signification de ces paramètres, mais elle refuse d’en donner une définition précise. Au lieu de cela, OOXML renvoie le lecteur aux versions historiques des applications :

“Pour reproduire fidèlement ce comportement, les applications doivent imiter le comportement de cette application, ce qui implique de nombreux comportements différents et ne peut pas être transcrit fidèlement par des mots dans ce standard Office Open XML. Si des applications souhaitent se conformer à ce comportement, elles doivent utiliser et dupliquer la sortie de ces [anciennes] applications.”

C’est clairement imprécis, et ne permet certainement pas la pratique commune et reproductible de ces fonctionnalités. Une application conforme à OOXML, si on lui fournit un document utilisant ces attributs, sera incapable de les interpréter correctement et de fournir un rendu fidèle à l’ original. De plus, comme ces attributs, sont simplement listés, mais pas définis, la capacité d’obtenir le bénéfice d’être “entièrement compatible avec les grands investissements existants dans les documents Microsoft Office6 (le but d’ OOXML selon ses auteurs) est par conséquent réservé uniquement à Microsoft. Le standard OOXML ne fournit pas une pratique commune et reproductible de ce bénéfice.

Deuxièmement, la partie WordProcessingML d’ OOXML énumère un grand nombre de styles de listes représentant des systèmes d’ écriture, des langues et des conventions métiers variées.7 Elles portent des noms conventionnels comme “chicago”, “ideographDigital”, “ideographLegalTraditional”, “koreanDigital2” ou “koreanLegal”. Ce ne sont que des appellations conventionnelles, sans définition précise. Les implémenteurs potentiels d’OOXML sont informés qu’il existe une chose appelée “énumération KoreanLegal”, mais ils ne savent pas ce que cela signifie ni comment la mettre en pratique dans leur application.

Par exemple, un implémenteur coréen potentiel ne saura que faire avec un style d’ énumération qui dit simplement “la séquence doit consister en caractères définis par le Manuel de Style Chicago”, sans référence à une édition (il en existe 15) ou une page. La spécification OOXML ne permet simplement pas l’utilisation commune et reproductible de ces fonctionnalités.

Troisièmement, la partie SpreadsheetML d’OOXML décrit un attribut “securityDescriptor” qui, selon la spécification8:

“…définit les comptes utilisateurs qui peuvent modifier cette zone sans fournir de mot de passe pour y accéder. La suppression de cet attribut devrait supprimer toutes les permissions et les interdictions accordées aux utilisateurs sur cette zone.”

C’est une fonction de sécurité importante, qui indique à l’application quels utilisateurs sont autorisés à modifier une zone sans mot de passe. Un programmeur potentiel cherchant à l’ implémenter aurait besoin de savoir comment ces comptes utilisateurs sont représentés dans le document. Sont-il séparés par des virgules, des points-virgules, des espaces? OOXML ne fournit pas ces détails (alors qu’il indique que plusieurs noms sont acceptés). De plus, il n’y a pas de concept universel d’ identité numérique. Nous avons tous plusieurs comptes utilisateurs, pour le courriel, les bases de données, les accès machines, les contrôleurs de domaines, les annuaires LDAP, etc. Lesquels sont utilisés ici ? Cette fonction n’est pas assez précisément définie pour permettre l’ interopérabilité, qui est en somme un autre terme pour l’usage commun et reproductible.

 

En résumé, de nombreuses parties d’ OOXML sont non définies ou sous-définies. La spécification fournit à Microsoft un cadre idéal pour représenter ses propres documents, mais elle ne garantit absolument pas à d’autres éditeurs un accès identique aux mêmes avantages. La question à poser est “est-ce qu’ OOXML définit un format de document assez précis pour permettre un usage commun et reproductible de ses bénéfices revendiqués ?”. Les trois exemples ci-dessus, et de nombreux autres, montrent qu’ OOXML ne satisfait pas à ce critère. OOXML manque de maturité comme standard, comme en témoigne l’absence d’ implémentations complètes indépendantes. Ceci, et l’ insuffisance des revues techniques préalables le rendent peu pertinent pour une soumission à une procédure rapide, et en font un mauvais candidat à la ratification comme norme internationale.

 

3. Incitatif, meilleures pratiques éprouvées

Une norme ISO ne devrait pas être l’enregistrement minutieux des caractéristiques d’un produit commercial issu d’une seule société, quelle que soit la domination de cette compagnie dans le domaine. D’après les définitions citées plus haut, une norme internationale devrait représenter le “résultat éprouvé de la science, de la technique et de l’industrie”. Une norme doit être “incitative”. En d’autres termes, elle ne devrait pas se contenter de refléter la pratique effective d’un éditeur. Elle doit tenter de fournir “un résumé des meilleures pratiques” basé sur un consensus d’experts. Elle doit diffuser les meilleures pratiques pour l’usage commun et reproductible d’une technologie donnée.

 

C’est par la normalisation que l’industrie enregistre ses meilleures pratiques. Le corpus existant de normes pour les documents et le balisage représente une référence des meilleures pratiques revues, approuvées et réellement implantées. Le travail du World Wide Web Consortium (W3C)9 est particulièrement pertinent dans le domaine des documents XML, puisque c’est lui qui maintient le coeur de la norme XML, ainsi que les standards liés, tels que XHTML, CSS2, XSL, XPath, XForms, SVG, MathML et SOAP. Ces standards représentent l’ ossature des technologies XML et basées sur XML.

 

Pourtant, OOXML n’ intègre qu’un très petit nombre des meilleures pratiques éprouvées de l’industrie. Pire, les implémenteurs potentiels d’OOXML doivent utiliser les formats propriétaires et historiques de Microsoft, même quand des standards W3C pertinents et supérieurs sont disponibles.

 

Par exemple, Vector Markup Language (VML) a été développé par Microsoft et proposé au W3C, où il a été évalué par le comité technique et finalement rejeté en 1998. L’industrie a préféré adopter le format SVG (Scalable Vector Graphics) qui a été standardisé par le W3C avant d’être largement adopté. SVG est la norme pour les graphiques vectoriels XML depuis presque dix ans. Pourtant, OOXML utilise le VML propriétaire, car Microsoft a intégré dans Internet Explorer et Office 2000 son VML propriétaire plutôt que le SVG standard.

 

Microsoft a reconnu que VML était un mauvais standard pour le graphique vectoriel :

 

“Le format VML est un format historique introduit à l’origine dans Office 2000, inclus et entièrement défini dans ce standard pour des raisons de rétro-compatibilité. Le format DrawingML est un format nouveau et plus riche créé dans le but de remplacer à terme tous les usages de VML dans les formats Office Open XML. VML doit être considéré comme obsolète, inclus dans Office Open XML uniquement pour des raisons historiques. Les nouvelles applications qui nécessitent un format de fichiers pour les dessins sont fortement encouragés à utiliser plutôt DrawingML”10

Au lieu d’utiliser le standard existant, SVG, OOXML inclut deux langages de balisage différents pour le graphisme vectoriel, le premier ayant été rejeté par le W3C en 1998, et le second développé par Microsoft seul. Cela représente une immense quantité de travail supplémentaire pour quiconque désire implémenter OOXML. Cela implique de supporter deux balisages différents pour la même fonctionnalité (aucun des deux n’étant standard), sans aucun bénéfice pour l’utilisateur. Le seul bénéficiaire de cette conception est Microsoft, qui intègre déjà VML dans MS Office.

 

De plus, le graphisme vectoriel, plus encore que le texte, est susceptible d’être imparfaitement converti par les traducteurs de format. Et donc, la prolifération de standards redondants pour le graphisme vectoriel – deux rien que dans OOXML – entraînera des problèmes de fidélité durant les conversions.

 

Est-ce que cela paraît incitatif ? Est-ce que cela valorise les meilleures pratiques ? Au contraire, les 600 pages de définition de VML ont été ajoutées à la spécification OOXML, sans que cela n’ apporte rien à personne en dehors de Microsoft, en créant des obstacles à tout autre qui voudrait implémenter OOXML.

 

Comme deuxième exemple, notez la définition des dates de tableur, qui doivent satisfaire la condition suivante :

 

“Pour des raisons historiques, une implémentation utilisant la date de 1900 comme base doit traiter 1900 comme si elle avait été une année bissextile… Par conséquent, pour les dates situées entre le 1er janvier et le 28 février, WEEKDAY doit retourner une valeur représentant le jour précédant immédiatement le jour correct. De la sorte, la date (factice) du 29 février aura une valeur jour-de-la-semaine suivant immédiatement le 28 février et précédant immédiatement le 1er mars.”11

En d’autres termes, le calendrier grégorien, référence pour le commerce, les sciences et les gouvernements dans le monde, est abandonné pour “des raisons historiques”. Les implémenteurs potentiels d’ OOXML devraient écrire des applications donnant des réponses incorrectes à des questions du type “quel jour de la semaine tombe le 1er février 1900 ?” s’ils veulent se conformer au standard OOXML. Cela pose des problèmes particuliers à la tâche (courante) d’ échange des données entre un tableur et une base de données relationnelle via SQL, un standard qui impose explicitement l’usage du calendrier grégorien.12

 

Comme troisième exemple, notez qu’ OOXML définit un nouveau type de chaîne appelée “Basic String” pour “un type de variante binaire de chaîne de base.”13 L’une des propriétés de ce nouveau type de chaîne est de permettre l’ encodage spécifique de caractères non-XML (caractères de contrôle). Pourtant, la présence de caractères non-XML dans un document XML casse l’ interopérabilité avec les outils prévus pour XML. L’ Internationalisation Activity du W3C confirme cette interprétation, par le passage suivant :

 

“Les codes de contrôle doivent être remplacés par le balisage approprié. Puisque XML fournit une manière standard d’ encoder les données structurées, la représentation des codes de contrôle autrement que par des balises réduirait à néant les avantages réels d’utiliser XML. L’utilisation des codes de contrôle dans HTML et XHTML n’est jamais pertinente, puisque ces langages balisés sont prévus pour représenter du texte, pas des données.”14

Quatrièmement, en plusieurs endroits15 OOXML utilise des “masques de bits” pour encoder plusieurs booléens (vrai/faux) dans un seul entier. Bien que cela ait été une pratique courante il y a 20 ans en langage C dans des environnements à mémoire contrainte, cet usage est considéré comme une très mauvaise pratique en XML. Il complique démesurément le traitement par les outils XML standard comme XSLT, puisqu’ils n’ intégrent pas les opérateurs booléens pour descendre au niveau du bit.

 

Cinquièmement, non seulement OOXML ne fournit pas un résumé des meilleures pratiques de la science et de l’industrie, mais en plus il ne fournit même pas un résumé des meilleures pratiques de Microsoft elle-même. OOXML recommande que les paramètres d’impression (nombre de pages à imprimer, orientation qualité d’impression, etc.) soient stockés dans un format binaire spécifique à la plate-forme. Par exemple dans Windows, leur recommandation est de stocker cela dans une structure appelée “DEVMODE”.16 Cela implique des paramètres d’impression dépendants de la plate-forme et interdit l’ interopérabilité. Pourtant, dans le même temps, la nouvelle spécification de Microsoft, “XML Paper Specification” (XPS) offre un élément PrintTicket dont Microsoft dit :

 

“La technologie PrintTicket est le successeur de l’ actuelle structure DEVMODE. C’est un document XML qui spécifie et stocke l’information sur le formattage et la configuration de l’impression… Par rapport au sous-système d’impression actuel, la technologie PrintTicket permet à tous les composants et clients du sous-système d’impression un accès transparent aux informations actuellement stockées dans les portions publique et privée de la structure DEVMODE, en utilisant un format XML bien défini.”17

Pourquoi OOXML utilise-t-il les paramètres d’impression inférieurs, binaires, dépendants de la plate-forme et de l’application, alors que la pratique recommandée par Microsoft elle-même est d’aller vers un “format XML bien défini” ?

 

Comme sixième exemple, notez qu’ OOXML définit plusieurs algorithmes cryptographiques18 non standards. Au lieu d’utiliser un algorithme ISO/IEC 10118-3:2004, ou l’un de ceux approuvés par le NIST dans leur liste FIPS-180 d’algorithmes conformes19 (et il en existe plusieurs communs aux deux listes, dont par exemple le SHA-256), OOXML spécifie un algorithme de hachage historique, probablement l’un de ceux utilisés dans une version ancienne de Microsoft Office. Cela correspond-il aux bonnes pratiques éprouvées de la science et de l’industrie ? Au contraire, Microsoft ne recommande même pas d’utiliser ces algorithmes. Au lieu de cela, elle fournit dans Office 2007 des protections basées sur des DRM, comme des extensions non documentées d’ OOXML. Puisque ce DRM n’est pas documenté, aucun autre éditeur n’a la possibilité d’utiliser ces fonctionnalités. Les documents chiffrés avec Office 2007 ne peuvent être lus nulle part ailleurs. Les implémenteurs potentiels d’OOXML n’ont accès qu’ aux fonctions de sécurité défectueuses et historiques d’OOXML, qui ne sont même pas conformes à FIPS-180. Ici encore, Microsoft garde ses meilleures pratiques pour elle-même, en laissant dans la spécification OOXML des fonctions de sécurité aléatoires.

 

En résumé, OOXML est un portage direct des formats de documents binaires d’un unique éditeur, qui évite de réutiliser les normes internationales existantes appropriées, ainsi que la meilleure technologie de Microsoft elle-même. Cela prouve qu’ OOXML ne représente pas les résultats éprouvés de la science et de l’industrie, et n’est pas incitatif. Bien qu’elle fournisse une technique pour lire des données dans un format d’un vendeur, on pourrait au mieux la qualifier de spécification technique. Puisqu’elle ne représente pas les meilleures pratiques éprouvées de l’industrie, un critère incontournable pour une norme ISO, la spécification OOXML ne devrait pas être approuvée comme norme internationale.

 

4. Interopérable & Portable

 

La portabilité et l’ interopérabilité sont deux “Caractéristiques Stratégiques Communes” de JTC120 et donc deux conditions nécessaires à toutes les normes approuvées par JTC1. Dans le domaine des formats de document, la question est de savoir si la spécification OOXML proposée peut être implémentée entièrement par des applications et sur des systèmes d’exploitation variés. Ou si elle a été écrite exclusivement pour le bénéfice de l’application d’un seul éditeur.

 

Premièrement, un domaine important de l’interopérabilité est l’échange d’information entre tableurs et bases de données relationnelles. De nombreux processus métiers sont définis autour de cette capacité, qui est fournie par la plupart des éditeurs de tableurs depuis plus de dix ans. Pourtant, OOXML n’ offre aucun moyen de représenter les dates antérieures à 1900, alors que les bases de données modernes ont des limites bien inférieures. DB2 d’IBM, par exemple, supporte les dates depuis l’an 1, et Oracle depuis 4712 av J.C. La spécification OOXML ne devrait pas empêcher un implémenteur potentiel d’utiliser des dates aussi anciennes qu’il le voudrait. Un éditeur d’application voudra naturellement appliquer la même étendue de dates à son tableur et à sa base de données. Pourquoi OOXML est-elle restreinte aux limitations de Microsoft Excel ? Cela malmène l’interopérabilité entre les tableurs et les bases de données.

 

Deuxièmement, OOXML définit un type ST_CF21, qui stocke les formats graphiques autorisés dans le presse-papier. Les valeurs autorisés pour ce type, EMF, WMF, etc., sont toutes des formats propriétaires Windows. Aucune extensibilité n’a été prévue pour l’utilisation par un autre système d’exploitation. Par exemple, sous Linux, les images sont typiquement copiées dans le presse-papier dans un format ouvert comme le PNG. Mais si un éditeur écrit “PNG” dans un enregistrement de ce type, le document sera invalide, et le document et l’application seront non-conformes à la spécification OOXML.

 

Troisièmement, la définition d’un algorithme de hachage du mot de passe dans SpreadsheetML est donnée par la copie de 5 pages de code source C22, probablement extrait d’ Excel. Cependant, les manipulations de bits de ce code sont intrinsèquement dépendants de la machine, et donneront des résultats différents selon l’architecture du processeur. Un document créé sur une machine peut être illisible sur une machine différente. OOXML n’a pas fourni une définition portable de cette fonction.

 

Quatrièmement, l’élément “optimizeForBrowser” de WordProcessingML23 a été défini d’une manière qui ignore l’existence des navigateurs web autres qu’Internet Explorer. Qu’en est-il de Firefox, Safari, Opera ? Aucun de ces trois-là ne peut être spécifié comme navigateur destinataire. Cette section d’OOXML demande que “tous les éléments qui ne peuvent pas être rendus dans le navigateur destinataire soient désactivés.” Que faire si je veux que mon application produise une sortie conforme aux standards ? C’est-à-dire accepte le PNG, le MathML, le SVG et refuse le VML ? Un implémenteur potentiel n’a pas la possibilité de spécifier cela avec OOXML tel qu’il est conçu.

 

Sixièmement, la fonctionnalité “Propriété de synchronization des transparents” de DrawingML24 fournit la possibilité pour une présentation de synchronizer son contenu de transparents avec un dépôt centralisé sur un serveur. C’est une fonctionnalité de Microsoft SharePoint et PowerPoint. Cependant, sa description dans OOXML manque de détails. Quel est le protocole de communication ? Le modèle de données ? Bien qu’il existe des standards pour décrire un protocole client-serveur de ce type, notamment les nombreuses variantes de Web Services, OOXML ne donne aucune information. Cela interdit des implémentations indépendantes et interopérables de cette fonction et la seule implémentation qui existe restera liée à SharePoint.

 

En résumé, là où OOXML référence d’autres technologies, c’est d’une façon qui le lie exclusivement aux technologies déjà supportées par Microsoft Office. Dans certains cas, des efforts extraordinaires sont faits pour intégrer dans OOXML d’autres spécifications comme VML. OOXML ne se contente pas d’ignorer les technologies alternatives, standardisées et ouvertes, elle empêche purement et simplement les autres éditeurs d’ajouter un support pour interopérer avec d’autres technologies. Même si chaque éditeur a le droit d’avoir ses propres priorités, et ses propres choix de conception, une norme ISO doit garantir les caractéristiques de portabilité et d’ interopérabilité, de sorte que chaque éditeur ait un même droit d’ implémenter ses choix. Les restrictions arbitraires d’ OOXML, uniquement compatibles avec les choix et plateformes de Microsoft, mais pas aux autres, rendent la spécification proposée inacceptable comme norme internationale.

 

5. Adaptabilité culturelle et linguistique

Puisque les caractéristiques d’OOXML dérivent de celles de Microsoft Office, il n’est pas surprenant de constater qu’elles reflètent mieux les besoins des pays développés, où Microsoft est le plus implantée. Cependant, une norme internationale doit adopter un point de vue plus large et garantir une interopérabilité culturelle et linguistique.

 

Un exemple de problème est fourni par la fonction de tableur NETWORKDAYS()25. Elle est donnée dans OOXML pour renvoyer le nombre de jours de travail entre deux dates, en excluant les week-ends de l’ intervalle. Dans certaines cultures, le week-end s’étends sur le samedi et le dimanche. Dans d’autres, ce sont soit le jeudi et le vendredi, soit le vendredi et le samedi. OOXML ne définit pas le “week-end” et ne prévoit aucune façon de le faire. La fonction telle qu’ implémentée dans Excel suppose que c’est forcément le samedi et le dimanche, c’est-à-dire qu’elle renvoie une réponse erronée pour plusieurs milliards d’utilisateurs potentiels sur le globe. OOXML n’a pas d’ adaptabilité culturelle. Comparez-le à la même fonction dans le format OpenDocument, où l’utilisateur peut passer un paramètre optionnel pour écraser la définition par défaut du week-end.

 

Deuxièmement, WordProcessingML a une caractéristique appelée “Styles de bordure”26 qui énumère un grand nombre de bordures graphiques utilisables pour les pages. C’est une liste fermée de noms conventionnels avec des images obligatoires. La figure 1 fournit un exemple de deux des bordures.

 

Figure 1: Bordure de pages

Ce sont les deux seules possibilités pour imprimer un globe sur une bordure de page, et aucune des deux ne montre l’ Asie. De même, on trouve des dessins de gâteaux d’ anniversaire, de Saint Valentin, d’ oeufs de Pâques peints, de bonshommes en pain d’épice, de citrouilles d’Halloween, et d’autres images typiques de la culture occidentale, mais d’utilité limitée partout ailleurs. Le problème ici est que la liste est fermée et corresponds exactement aux fonctionnalités de Microsoft Word. Un implémenteur potentiel ne peut pas étendre cette liste avec des images supplémentaires pour refléter la culture de ses clients, sans quoi les documents ne seraient pas valides pour OOXML et son application ne serait pas conforme. Comment OOXML s’adapte-t-il aux autres cultures ? Dans le cas des bordures de pages, elle ne s’adapte pas.

 

Troisièmement, comme mentionné plus haut, WordProcessingML définit un certain nombre de styles d’ énumération et de listes numérotées.27 Ces styles sont essentiellement nommés, mais pas définis. Mais surtout, ils constituent une liste fermée, là encore correspondant parfaitement aux capacités de Microsoft Word, mais non extensible par d’autres éditeurs. Pourtant, la liste des styles est incomplète, car il manque par exemple le support des énumérations arménienne, tamil, grec alphabétique, éthiopiennes et khmere, ainsi que de nombreux autres systèmes historiques utilisés par les universitaires. La solution préférée est une approche déclarative/générative, telle qu’ utilisée par le XSL:FO du W3C et le format OpenDocument. Cela autorise une liste ouverte de styles de numérotation, chacune auto-définie.

 

L’ adaptabilité culturelle et linguistique est limitée dans OOXML par la présence de listes fermées qui, bien que conformes aux capacités du Microsoft Office actuel, sont incapables d’ extension, à un degré inacceptable.

 

6. Résumé

 

Les normes suivent des normes. En évaluant la spécification OOXML proposée sur les critères fournis par l’ ISO pour une norme, ce document a montré en quoi OOXML est non conforme aux différents critères : précision, usage commun, degré optimal d’ordre, être incitatif, diffuser les meilleures pratiques, l’ interopérabilité, la portabilité et l’ adaptabilité culturelle et linguistique. Par de nombreux exemples, nous avons montré que le standard OOXML proposé est loin du compte. Loin de fournir un bénéfice optimal à la communauté, la proposition semble destinée au bénéfice d’une seule société.

 

Les attentes pour une norme de format de document sont exigeantes, comme il se doit. Un format respectant les critères mentionnés est essentiel pour la préservation à long terme de notre héritage numérique, pour un accès égal aux documents administratifs par tous les citoyens, et pour l’intégration économique et efficace des procédés métiers basés sur des documents entre des systèmes hétérogènes. OOXML, le format de fichiers de MS Office, ne fournit pas ces bénéfices, et n’est pas éligible comme norme ISO. Nous demandons donc à JTC1 de voter NON sur la proposition lors du vote.

 

 

  • Basé sur des contributions de Rob Weir d’IBM et d’autres.

  • Traduction française de The Case Against OOXML par Guillaume Allègre, <gallegre@april.org>, 23 juin 2007; relecture et corrections par Benjamin Henrion <bhenrion@ffii.org> et Alexandra Combes <alexandra.combes@ffii.fr>, 25 juin 2007.

1 ISO/IEC Guide 2:2004, definition 3.2. Plusieurs organismes de normalisation nationaux ont aussi adopté cette définition ISO, p. ex la DIN allemande.

2http://www.bsi-global.com/en/Standards-and-Publications/About-standards/What-is-a-standard/

3JTC1 Directives, 5th Edition, Version 3.0, Section 1.2

4Partie 4, Section 2.15.3.9 Toutes les références à OOXML se rapportent à la spécification Ecma 376 « Office Open XML » , disponible à http://www.ecma-international.org/publications/standards/Ecma-376.htm

5D’autres exemples : lineWrapLikeWord6, mwSmallCaps, shapeLayoutLikeWW8, supressTopSpacingWP, truncateFontHeightsLikeWP6, useWord2002TableStyleRules, wpJustification et wpSpaceWidth

6Partie 1, Introduction

7Partie 4, Section 2.18.66

8Partie 4, Section 3.3.1.69

9http://www.w3.org

10Partie 4, Section 6.1

11Partie 4, Section 3.17.4.1

12Database Language SQL—Part 2: Foundation (ISO/IEC 9075-2:1999), Section 4.7.3

13Partie 4, Section 7.4.2.4

14http://www.w3.org/International/questions/qa-controls

15Par exemple, Partie 4, Section 2.3.1.6; Partie 4, Section 2.4.51; Partie 4, Section 2.4.52; Partie 4, Section 2.4.7, etc.

16Partie 1, Section 15.2.14

17http://msdn2.microsoft.com/en-us/library/ms715246.aspx

18Par exemple à la Partie 4, Section 2.15.1.28

19http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf

20JTC1 Directives, 5th Edition, Version 3.0, Section 1.2

21Partie 4, Section 6.4.3.1

22Part 4, Section 3.2.29, pg. 1917

23Partie 4, Section 2.15.2.32

24Partie 4, Section 4.7.1

25Partie 4, Section 3.17.7.224

26Partie 4, Section 2.18.4

27Partie 4, Section 2.18.66

4 Réponses to “La guerre des formats”

  1. Vive la France ! « Discutons au comptoir du x86 bar Says:

    […] fait, je n’ai rien contre Microsoft sur ce coup là. Mais les arguments présentés contre la normalisation de ce format sont pertinents. Microsoft pourrait faire taire les critique en en […]

  2. peter Says:

    VML semble loin d’être mort !
    http://www.svg-vml.net/

  3. Vector Says:

    Cette phrase est étonnante!:
    « Microsoft a reconnu que VML était un mauvais standard pour le graphique vectoriel « .
    Pensez-vous vraiment qu’ils auraient garder ce format depuis 11ans rien que pour la forme ???
    VML natif n’est pas 100% Microsoft (on l’oublie souvent). Et si cette firme a décidé de garder ce merveilleux outil, c’est bien qu’il est très supérieur à son dérivé SVG qui est toujours en cours d’évolution et non encore admis totalement par tous les navigateurs. Alors que VML est optimisé depuis 1998 et seules quelques infimes évolutions lui furent nécessaires depuis.
    Il est aujourd’hui intégré dans la technologie Silverlight et continue sa route imperturbable…

    Réponse: Si VML est si excellent, pourquoi OOXML introduit un nouveau format de graphisme vectoriel ?
    D’autre part, le fait que VML n’ai pas été modifié depuis longtemps peut aussi être compris comme VML est un format à l’abandon… ça n’est pas vraiment un argument..

  4. Vector Says:

    « Si VML est si excellent, pourquoi OOXML introduit un nouveau format de graphisme vectoriel ? »
    …Mais VML est toujours présent dans OOXML…
    Ce format a été incontestablement « ignoré » (plus qu’abandonné). Je pense que le manque de valorisation par MS lui-même en est la conséquence.
    Mais le rejet du W3C au profit du SVG cassa sans doute cette objectivité. Microsoft conserva néanmoins VML (on ne pouvait tout de même pas mettre un outil pareil à la corbeille), et à l’époque Macromedia se tourna vers Flash avec succès ….en pensant sans aucun doute que SVG était une grosse erreur…


Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :