Office Open XML

Microsoft Office (suite bureautique réunissant entre autres Microsoft Word, Excel et PowerPoint) est devenu au cours des années 1990 le logiciel de bureautique le plus utilisé, au point de tenir une situation de quasi-monopole. Parallèlement, les formats de fichier utilisés par la suite bureautique (.doc, .xls, .ppt, etc.), binaires, propriétaires et non documentés^[2] sont devenus des standards de facto. Cet état de fait nourrissait la situation de monopole de la suite Microsoft Office : sans documentation de ces formats devenus standards, les logiciels concurrents de Microsoft Office ne pouvaient espérer en égaler toutes les spécifications secrètes.

L’adoption par l’ISO du format de fichier bureautique ouvert ODF en 2006^[3], et sa disponibilité sur de nombreuses plates-formes logicielles, a brutalement changé la donne en matière de format de bureautique. Une norme était proposée, là où n’existait qu’un standard de facto, non documenté et lié à un éditeur privé.

Face à l’exigence des utilisateurs de bénéficier d’un format de données XML, standardisé et documenté, Microsoft créa son propre format, concurrent de l’ODF : l’Office Open XML. Il imposa^[4] sa reconnaissance comme standard documenté par une organisation de standardisation informatique, l’ECMA, en décembre 2006, dans le but de le faire valider par l’ISO.

S’ouvrit alors une guerre des formats, aussi bien sur le plan technique que politique^[5], dont les enjeux stratégiques sont énormes^[6] : si Microsoft devait perdre l’avantage d’être propriétaire du format standard de bureautique, alors sa suite Microsoft Office se trouverait en concurrence directe et égale face à ses concurrents, notamment Libreoffice, OpenOffice.org et StarOffice .

Office Open XML (également abrégé OOXML ou plus communément Open XML) est la désignation d’usage d’un standard de l’ECMA dont l’appellation officielle est « ECMA-376 : Office Open XML File Format » définissant un format de données pour les documents d’applications bureautiques : traitements de texte, tableurs, présentations, diagrammes, dessins et formules mathématiques. Ce format est à l’instar du format ISO OpenDocument structuré en XML et Zip.

Originellement introduit par Microsoft, puis revu dans le cadre de sa standardisation par l’ECMA, ce format est structuré selon l’Open Packaging Convention^[7] qui définit un système de stockage des données flexible en utilisant une navigation logique à base de relations. La description sémantique des données se fait par l’ensemble des schémas XML normalisés.

Pour des raisons d’interopérabilité avec les anciens formats binaires d’Office, la partie réservée à la compatibilité de la spécification - partie entièrement optionnelle - mentionne néanmoins des éléments non-normalisés qui sont la propriété intellectuelle de Microsoft comme le WMF, la sauvegarde des données concernant le format d’impression et certains détails d’anciens logiciels édités par Microsoft. Dans ce cadre, Microsoft a publié un Covenant Not to Sue (ou CNS) s’engageant pour le futur à ne pas gêner les acteurs à utiliser le format, même si cela empiète sur la propriété intellectuelle de la firme. Une étude du cabinet d’expertise juridique anglais Baker & McKenzie, effectuée aux frais de Microsoft, décrit la validité et la portée juridique du contenu de ces documents en y engageant sa réputation. Dans la pratique, seule une jurisprudence pourrait donner une lecture certaine de ce document.

Ce format est présenté par l’auteur comme destiné à être utilisé par tous pour communiquer et aussi pour archiver les documents administratifs, culturels ou scientifiques et donc préserver une grande partie de notre patrimoine intellectuel ou historique, des enjeux techniques, économiques et de société.

Les pays membres de l’ISO ont discuté et revu techniquement le standard ECMA-376 dans le but de s’assurer de la cohérence et de l’intérêt du contenu de la spécification.

Le 19 juillet 2007, le processus de normalisation ISO de OpenXML a subi un revers, le comité technique V1 ayant refusé l’état « approuvé avec commentaires » (qui signifie accepté), et aussi l’état « désapprouvé avec commentaires » (qui implique une demande de modification pour un probable accord ultérieur). Le comité technique en question était pourtant passé de sept participants au 1^er janvier à vingt-six participants, les nouveaux entrants ayant majoritairement voté en faveur de l’adoption^[8].

Le 10 août 2007, le format Office Open XML fait l’objet d’un premier rejet à l’ISO : l’abstention de l’IEEE provoque la non-présentation du format à l’ISO^[9].

Le 4 septembre 2007, le vote du comité ISO, planifié pour la potentielle nomination de ce standard au statut de normes ISO, est négatif (le vote ne recueille que 53 % de votes positifs, alors qu’il est nécessaire de réunir plus de 66 % de votes positifs et moins de 25 % de votes négatifs). Le représentant de la France à l’ISO (l’association française de normalisation Afnor), qui possède une voix lors de ce vote, choisit de voter « non avec commentaires ».

La possibilité de reconnaître OpenXML comme norme internationale est/a été contestée lors de la procédure de normalisation ISO 29500, à la suite d'une série d’éléments tant juridiques que techniques qui pourraient rendre malaisée l’implémentation d’OpenXML. À la suite de ces contestations, l’ECMA a formulé un document de réponse^[10], destiné aux instances internationales, justifiant des choix techniques.

En plus des réponses apportées par l’ECMA, Microsoft a répondu à certains des points ambigus soulevés par les états dans un communiqué officiel^[11].

Le statut de norme pour Office Open XML est jugé tendancieux par de nombreuses associations promouvant le logiciel Libre^[12],[13].

Des entreprises comme IBM^[5] avancent que la norme est trop liée aux plates-formes du passé et désirent rompre avec cet état de fait. D'autres comme Google avancent que l'adoption d'un standard alternatif jouant le même rôle qu'un standard auparavant adopté (ODF) n'est pas bénéfique, et critiquent également la documentation qui est trop étendue pour être correctement revue : « ça prendrait 18 ans (6 576 jours pour 6 546 pages) pour aboutir à un niveau de revue comparable au standard ODF (871 jours pour 867 pages). »^[14]

L’ODF Alliance, promotrice de l’OpenDocument, propose une feuille de faits qui dénonce la difficulté à transposer Office Open XML à d’autres suites bureautiques, la taille du document de la spécification, la redondance avec les standards actuels.

Il existe déjà une norme ISO 26300 pour décrire les documents de bureautique. La proposition de normalisation d’OpenXML contredirait les normes ISO 8601 (représentation des dates et des périodes), ISO 639 (codes pour la représentation des noms et des langues) ou ISO/CEI 10118-3 (fonctions de hachage en cryptographie)^[15].

L'institut Fraunhofer de Berlin a réalisé une étude au sujet de l'interopérabilité entre ODF et OOXML. Le résultat est sans surprise : une incompatibilité entre les deux, imposant aux utilisateurs de soigneusement choisir l'un, sachant que leur choix les engage pour longtemps et qu'aucune conversion ne pourrait être parfaite^[16].

Microsoft a distribué, en plus de l’existant Open Specification Promise un document promettant de ne pas poursuivre^[17] les auteurs de l’utilisation de Office Open XML dans un autre logiciel que ceux de Microsoft. Cette promesse de non-poursuite elle-même laisse certains flous, notamment^[18] :

• s’appliquant à la norme ECMA en l’état, s’applique-t-elle à une éventuelle version finale de l’ISO ?
• s’applique-t-elle à tous les brevets logiciels nécessaires à la mise en œuvre de la norme ?
• s’applique-t-elle également aux extensions du format OOXML ?

La licence d’utilisation de OpenXML est incompatible avec les programmes sous la licence GPL^[19],[20].

Certaines associations d’industrie ont même écrit à l’ECMA pour faire valoir qu'OpenXML était « non conforme aux conditions fondamentales de l’ouverture » (à l’époque)^[21].

La possibilité et/ou facilité de transposition du format à d’autres suites bureautiques ou bibliothèques indépendantes de l’auteur original, a été remise en cause. Pourtant de nombreux produits implémentent le standard ECMA, en partenariat avec Microsoft (la version Novell de OpenOffice.org, NeoOffice, Corel WordPerfect, MindManager Mindmapping, Altova XMLSpy) ou non (Liste vide).

Plusieurs bibliothèques permettent aux développeurs/éditeurs de logiciels de créer des applications.

• Celle de Microsoft (espace de nom System.IO.Packaging pour .NET 3) est terminée.
• Une implémentation Libre pour la plate-forme Java sous licence BSD/Apache, OpenXML4J a été initiée par une entreprise française et reste en cours de développement.

L’ECMA a demandé l’examen de la proposition de norme OpenXML par l’ISO selon le mode rapide dit « fast track », mode qui demande que les éventuelles contestations soient formulées dans le délai d'un mois. Ce mode rapide est contesté par plusieurs organisations, en particulier au regard de la taille excessive de la proposition : plus de 6 000 pages, à comparer avec la taille habituelle (en moyenne 11 pages) des normes de l’ISO.

Malgré une majorité de votants contre l’adoption de cette procédure (14 négatifs, 5 neutres/mitigés et 1 pour), la procédure fut néanmoins acceptée par le bureau du TC1^[22] en fonction des prérogatives dévolues au président^[évasif].

Il est fait mention dans le document proposé de logiciels tel que « Word95 », or une norme ne peut citer de marque (élément alignAsWord95, autoSpaceLikeWord95, useWord97LineBreakRules)^[15].

Un responsable de Microsoft a indiqué vers le milieu de 2008 que l’ODF a clairement remporté la victoire face à l’OOXML^[23],[24]. S’il convient de prendre ces propos avec précaution et de ne pas trop spéculer sur la stratégie future de la firme, cela semble néanmoins marquer la fin de la rivalité entre formats.

Cela semble aller dans la même direction que le support de l’ODF prévu par Office dans le prochain service pack (avec possibilité d’utiliser ODF par défaut).

Le 29 mars 2008, le vote d’adoption d’Office Open XML comme norme internationale DIS 29500 est positif^[25], ce qui provoque une certaine polémique. L’Afnor, le représentant français, qui avait voté contre lors du premier vote, a décidé au dernier moment de s’abstenir. Alors que 80 % du comité norvégien voulait garder le « non » du premier vote, la Norvège se déclare finalement favorable à la normalisation de l’Office Open XML. La commission européenne décide d’ouvrir une enquête sur les conditions de ce vote^[26].

Le 6 juin 2008, quatre membres de l’ISO, le Brésil, l’Inde, l’Afrique du Sud et le Venezuela, ont fait appel contre l’approbation des formats OOXML comme standards internationaux ISO/CEI^[27].

Ces appels sont pris en considération par les secrétariats généraux de l’ISO et de la CEI, qui les ont soumis, avec commentaires, aux ISO Technical Management Board et IEC Standardization Management Board.

L'ISO et l'IEC (International Electrotechnical Commission) ont finalement rejeté le 17 aout 2008 les appels déposés et donné un feu vert définitif à la publication d'OOXML.

Cette décision a entrainé le fait historique d'une remise en cause affichée de la confiance portée à l'organisme de normalisation ISO de la part de six pays (Brésil, Afrique du Sud, Venezuela, Équateur, Cuba et Paraguay) dans un communiqué conjoint où l'on peut lire notamment :

« Il nous apparaît clairement maintenant que nous allons devoir, quoiqu'à contrecœur, ré-évaluer notre appréciation de l'ISO/IEC, en particulier en ce qui concerne sa pertinence vis-à-vis des différentes structures d'interopérabilité de nos gouvernements nationaux^[28]. »

En tout état de cause, l'ISO et la CEI ont successivement validé trois normes (dont la première, bien qu'elle n'ait jamais été mise en œuvre, a cependant conservé son statut de standard international) dans le domaine des formats de documents révisables, à savoir

• Open Document Architecture (ISO/CEI 8613) ;
• Open Document Format (ISO/CEI 26300) ;
• Office Open XML (ISO/CEI 29500).

Ces trois spécifications cohabitent sans que les organismes de normalisation aient pu, jusqu'à présent, établir clairement leur complémentarité, ce qui pose le problème de la cohérence et de la non-redondance de l'offre normative en vigueur dans ce domaine. Au-delà des qualités et des défauts techniques comparés de ces spécifications concurrentes, ce sont les objectifs et le mode de fonctionnement des organismes de normalisation qui suscitent désormais des réflexions critiques^[29].

Le format Office Open XML utilise une structure respectant l’Open Packaging Convention et définissant de façon simple et logique la structure interne de tous les documents Office Open XML. Selon cette convention, les documents sont des archives ZIP dont les différents éléments le constituant, appelés parties, sont reliées entre elles par des relations logiques. L’utilisation du ZIP permet outre de compresser les documents, de pouvoir stocker les données de façon totalement indépendante dans une architecture segmentée.

Cette architecture permet d’ailleurs de protéger les documents Office Open XML plus efficacement face à la corruption des données (si un élément est endommagé, les autres n’en seront pas affectés).

La notion de paquet définit l’archive ZIP en elle-même, c’est-à-dire le conteneur des données d’un document Office Open XML.

Une partie est un élément de l’archive ZIP, c’est-à-dire un fichier compressé et intégré dans la structure du ZIP. On distingue plusieurs types de parties : les parties de contenu et les parties de relations.

Les parties de contenu contiennent les données même du document, c’est-à-dire les informations qui définissent les données et la sémantique d’un document Office Open XML. Ces parties peuvent contenir du XML (par exemple le contenu d’un document de traitement de texte : paragraphes, runs, graphiques…) ou des données binaires (par exemple des images GIF, JPEG, etc. ou des objets OLE).

Les parties de relations contiennent une structure XML définie dans les schémas de référence du standard ECMA-376.

Une partie spécifique et unique dans le paquet est celle des types de contenu décrite plus en détail dans une prochaine partie.

Les relations sont définies dans les parties de relations et spécifient les liens entre le paquet ou une partie source et une partie cible.

 <?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
 <Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">
   <Relationship Id="rId3" Type="http://schemas.../metadata/core-properties" Target="docProps/core.xml" />
   <Relationship Id="rId2" Type="http://schemas.../metadata/thumbnail" Target="docProps/thumbnail.jpeg" />
   <Relationship Id="rId1" Type="http://schemas.../officeDocument" Target="word/document.xml" />
   <Relationship Id="rId4" Type="http://schemas.../extended-properties" Target="docProps/app.xml" /> 
 </Relationships>

Une relation possède un type de relation spécifiant la nature de la partie pointée, et l’URI relative à la partie ciblée.

Les parties de relations possèdent un nom, représenté par une URI, qui doit respecter une convention de nommage particulière. Cette syntaxe indiquée dans le standard est la suivante : <chemin hiérarchique>/_rels/<nom de la partie source>.rels.

Exemples :

• la partie de relation du paquet n’a pas de partie source, puisque celle-ci est située à la racine même du document (et est obligatoire), sa syntaxe est unique : /_rels/.rels
• la partie de relations de la partie principale de contenu d’un document WordprocessingML possède l’URI suivante : '/word/document.xml', par conséquent la partie de relation associée (qui permettra par exemple, au contenu de cibler une image insérée dans le document) devra posséder l’URI suivante : /word/_rels/document.xml.rels

Cette partie obligatoire porte un unique nom : [Content_Types].xml

Ce nom n’est pas compatible avec la syntaxe d’une URI : cela est un choix technique. Voici un exemple de contenu de la partie de types de contenu :

 <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> 
 <Types xmlns="http://schemas.openxmlformats.org/package/2006/content-types">
   <Override PartName="/ppt/slides/slide5.xml"
     ContentType="application/vnd.openxmlformats-officedocument.presentationml.slide+xml" />
   <Default Extension="png" ContentType="image/png" />
   <Default Extension="rels" ContentType="application/vnd.openxmlformats-package.relationships+xml" /> 
   <Default Extension="xml" ContentType="application/xml" />
   …
 </Types>

Cette définition de type définit deux types d’extension, celle par défaut qui spécifie que tous les éléments possédant l’extension indiquée sont du type défini, et celle qui surcharge l’extension définie par défaut en précisant un type spécifique pour une partie spécifique.

Tous les types de contenu doivent être compatibles avec la RFC 2616^[30] §3.7 (en tenant compte des règles du modèle d’empaquetage, le support des paramètres de type de contenu est proscrit).

L’objectif des parties de signature est d’assurer la sécurité des documents afin d’en garantir au moins l’intégrité et/où l’accès grâce à des certificats X.509.

Ces parties contiennent plusieurs informations qui sont détaillées dans une partie ultérieure.

• Format concurrent : OpenDocument (ISO 26300)
• Microsoft Office, OpenOffice.org, LibreOffice

• Standard ECMA-376 Office Open XML File Formats (en)
• Structure des fichiers OpenXML (fr)
• (en) « EOOXML objections », sur grokdoc.net via Wikiwix (consulté le 28 mars 2024)
• Procédure de Standardisation ISO/IEC CD 29500
• Ressources Techniques en français pour les développeurs sur MSDN
• (en) Site anglophone de ressources techniques pour les développeurs
• (en) Site anglophone pour les utilisateurs
• (en) Blog anglophone explicitant certains problèmes actuels d’interopérabilité d’OOXML et d’Office
• (en) Blog anglophone répondant aux principales objections faites à Office Open XML
• (en) Blog Microsoft anglophone du marketeer technique Office Open XML
• (en) Blog Microsoft anglophone du program manager Office Open XML

•   Portail de Microsoft
•   Portail de l’informatique